PCE – OAM Handler in ABNO:
a use case of code adaptation in
flex grid networks
Francesco Paolucci
TeCIP, Scuola Superiore Sant’Anna,
Pisa, Italy
PACE Workshop on “New uses of Path Computation Elements”
Vilanova y la Geltru , Spain, June 16th 2014
Control <-> Management
• Control plane
–
–
–
–
Discovery and Routing
Path computation
Signaling
Failure recovery
• Management plane
– Network Status and Monitoring
– Operation and Administration Maintenance (OAM)
– SLA verification
• Interaction between planes
– Historical separation or limited interaction (not automatic)
– New target: pro-active control automatically driven by OAM
events/ conditions
– Active Stateful Path Computation Element in ABNO candidate
object
ABNO architecture
• Active Stateful PCE
– Access to TED and LSP-DB
– Stateful computation
• Shared protection
computation
• Effective restoration
– Active behaviour
•
•
•
•
Delegated LSP control
LSP resize, modification
LSP instantiation
Optimization Action Chain
• OAM Handler
– Network status supervisor
– Monitoring correlations
• Databases
– TED, LSP-DB
Application-Based Network Operation (ABNO)
framework.
“A PCE-based Architecture for Application-based
Network Operations”
draft-farrkingel-pce-abno-architecture
PCE in Flexible optical networks
• Next flexible transponders will support multiple
configurable signal generation @given bitrate
• PCE outputs
–
–
–
–
Suggested frequency slots (n: central frequency, m: width )
Suggested modulation format (e.g., DP-QPSK, DP-16QAM)
Suggested FEC / code
Single/multi carrier: type and number of sub-carriers
• Hitless flexible operations driven by active PCE
– Defragmentation (change n)
– Elastic operations (change m)
– Dynamic adaptation (change the code)
• Advanced Action Chain
PCEP Server
Active Solver
PCEP
PCReq
-new LSP
-elastic operation
load
PCRep
-reply to PCReq
TED
request
– E.g. Defrag + Elastic expand
update
LSP-DB
action
list
action queue
Action Handler
PCUpd
-active LSP adaptation
PCRpt
-LSP adaptation
outcome
PCNtfy
-TE updates
-QoT degradation
-failure events
Chain Example: Shift & Expand
1
PCReq (LSP 1: Elastic bit rate increase)
2
PCUpd (LSP 2: Shift)
3
LSP 2 shift
4
PCRpt (LSP 2: Shift OK)
5
PCRep (LSP 1: Elastic increase)
6
LSP 1 elastic increase
7
PCNtf (LSP 1: Elastic incresae OK)
LSP 2
LSP 1
1
Frequency
PCReq message
PCUpd message
3
RSVP make before break
PCRpt message
5
7
PCNtf message
2
4
5
PCRep message
6
RSVP elastic increase
Code adaptation for flexi Terabit
• Terabit transmission based on Time Frequency Packing
– LDPC coding applied to data
– Narrow-filtered subcarriers (faster-than-Nyquist)
– Coherent detection and DSP
• Scenario 1
– 7 subcarriers @ 160Gb/s
– 200 GHz width
– 8/9 coding
– 1.12 Tb/s bitrate -> 1Tb/s info rate
• Scenario 2
– More robust transmission needed
– 1 subcarrier added
– 4/5 coding
– 237.5 GHz width
– 1.28 Tb/s bit rate -> 1Tb/s info rate
QoT monitoring and forecast
• Quality of Transmission is monitored at the receiver
– Post-FEC BER
– Variance of acquired data samples
• Event Forecasting
– The variance indicates whether a working limit condition is
approaching
– FORECASTING post-FEC errors before they occur
– Threshold-based alarm event
0,1
• QoT monitor
0,08
Variance
– Responsible of monitoring
– Responsible of event ntf
– Responsible of alarms
0,06
"3/4"
0,04
"4/5"
0,02
3/4
4/5
"8/9"
8/9
0
12
14
16
OSNR (dB)
18
Validation Testbed (PCEP+RSVP)
2 – PCUpd (LDPC rate adaptation + spectral
expansion)
Active
Stateful
PCE
1 - PCNtfy (QoT degradation)
10 – PCRpt
eth
PCC
3 –Path
Controller
PCC
RSVP-TE
Controller
8 –Resv
eth
9 –LDPC rate
adaptation
odd IQ-modulators
Q
I
ch.
even
ch.
I
Controller
USB
5 –filter shape
(expand)
USB
couplers
SSS
OOK
Rx
SSS
Q
PolMux
Link1
Tunable
carrier
comb
RSVP-TE
6 –Resv
7 –filter shape
(expand)
PolMux
PCC
4 –Path
Configurable
Tx
Electrical
Data generation
OOK
Tx
BVT Tx
Link2
X
ADC+Processing
QoT monitor
BVT Rx
PCE-driven code adaptation
• Impairment-aware PCE computes a new code rate:
– Extended PCUpd message
– The ERO specifies the code to be applied at ingress/egress node
– LDPC code rate TLV
• Alarm triggered by PCEP:
– Novel QoT notify msg
– PCE computes the code
QoT object
– First implementation
– PCEP not suitable for OAM
UPDATE (PCUpd) MESSAGE
REPORT (PCRpt) MESSAGE
-Receiver transponder id: 1
QoT object
-LSP ownership: 10.0.0.1
-Event type: excessive BER value (1)
– Path rerouting is the last option
LSP id: 1; src IP: 10.0.0.1
UPDATE (PCUpd) MESSAGE
LSP object
-ERO subTLV
LDPC code rate: 3/4 (adaptation)
-Flexgrid label
ERO object
n: -44 -> f=192.825THz
m: 19 -> width=237.5GHz (expansion)
Hitless data plane operations
• To apply the new coding
– Configurable electrical encoder at transmitter, triggered upon RSVPTE session is finished
– In the overhead, a preamble of each data block includes a 3-bit
field to communicate the code to be applied to the next block
– Receiver processes next incoming data block with the new coding
– Code adaptation performed with no traffic disruption
7
0.1
Spectral Efficiency
0.09
6
Variance
0.08
0.07
5
0.06
4
0.05
3
0.04
0.03
0
5
10
15
2
20
OAM infrastructure
• OAM Agent located at the receiver
OAM Handler
– OAM session per LSP (per receiver card)
• Hierarchical OAM Agent
– Local Agent (node, link, network device…)
– Aggregation Agent (area, domain…)
– Local correlations when applicable
– Scalable design
L
A
L
A
A
L L
L
L
L
L
L
• Proposed OAM protocol: NETCONF
– Support of Asynchronous Notifications (RFC 5277)
– TCP connection assures reliability
– Hierarchical architecture reduces number of connections at Handler
– Native solution for OAM YANG modeling development
PCE driven by OAM
2 – PCUpd (LDPC rate adaptation + spectral
expansion)
Active
Stateful
PCE
OAM
Handler
10 – PCRpt
PCC
3 –Path
Controller
4 –Path
RSVP-TE
Controller
RSVP-TE
eth
Local OAM
Agent
Controller
8 –Resv
eth
6 –Resv
9 –LDPC rate
adaptation
odd IQ-modulators
Q
I
ch.
even
ch.
I
7 –filter shape
(expand)
PolMux
5 –filter shape
(expand)
USB
couplers
SSS
OOK
Rx
SSS
Q
PolMux
Link1
Tunable
carrier
comb
USB
Configurable
Tx
Electrical
Data generation
OOK
Tx
BVT Tx
Link2
X
ADC+Processing
QoT monitor
BVT Rx
OAM Handler <-> PCE interaction
• OAM Database instance ->Augmented TED / LSP-DB
• OAM LSP-DB: <BER>, <coherent receiver variance>,< ……
• OAM TED : <power><amp_gain><…
• Direct PCE<->OAM Handler interface needed?
R
Main Instance
TED
LSP-DB
PCEP
PCE
OAM Instance
OAM
TED
OAM
LSP-DB
R only
(OAM-aware
path computation)
R/W
1) Through ABNO controller
2) PCEP (OAM:PCC)
3) Dedicated protocol
4) Internal API (if co-located)
OAM
Handler
NETCONF
Conclusions
• Proactive PCE
– Fast reaction in presence of network degradations
– Computation and dynamic update of additional parameters
• Presented use case
– Hitless code rate adaptation in next generation transponders
– Active PCE in charge of computing the most suitable adaptation
– Advanced monitoring functions
• ABNO boxes interaction
– Close relationship between OAM Handler and PCE
– Proposed Hierarchical OAM infrastructure with NETCONF
– Dedicated database extensions/sessions populated by OAM
– Shared handling of the ABNO database sessions
Thank you
• Francesco Paolucci, Scuola Superiore
Sant’Anna
• fr.paolucci@sssup.it
ACKNOWLEDGMENTS
-collaboration with IDEALIST project
Questions are welcome