PCE – OAM Handler in ABNO: a use case of code adaptation in flex grid networks

1. 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

2. 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

3. 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

4. PCE in Flexible optical networks • Nextflexibletransponderswillsupport multiple configurablesignal generation @givenbitrate • 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 • E.g. Defrag + Elastic expand

5. Chain Example: Shift & Expand 1 PCReq (LSP 1: Elastic bit rate increase) 2 PCUpd (LSP 2: Shift) 4 PCRpt (LSP 2: Shift OK) Frequency LSP 2 LSP 1 5 PCRep (LSP 1: Elastic increase) 7 PCNtf (LSP 1: Elastic incresae OK) 3 6 LSP 2 shift LSP 1 elastic increase 1 PCReq message 2 PCUpd message 3 RSVP make before break 4 PCRpt message 5 PCRep message 6 RSVP elastic increase 7 PCNtf message

6. 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

7. 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 • QoT monitor • Responsible of monitoring • Responsible of event ntf • Responsible of alarms

8. Validation Testbed (PCEP+RSVP)

9. 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 • First implementation • PCEP notsuitablefor OAM • Pathreroutingis the last option

10. Hitless data plane operations • To apply the new coding • Configurable electrical encoder at transmitter, triggered upon RSVP-TE 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

11. OAM infrastructure • OAM Agent located at the receiver • 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 • 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 OAM Handler A A A L L L L L L L L L

12. PCE driven by OAM

13. 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? PCE PCEP R Main Instance OAM Instance R only (OAM-aware path computation) 1) Through ABNO controller 2) PCEP (OAM:PCC) 3) Dedicated protocol 4) Internal API (if co-located) OAM TED TED OAM Handler NETCONF OAM LSP-DB LSP-DB R/W

14. 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

15. Thank you • Francesco Paolucci, Scuola Superiore Sant’Anna • fr.paolucci@sssup.it ACKNOWLEDGMENTS -collaboration with IDEALIST project Questions are welcome