Investigation of OTN Capabilities in the NREN Environment (JRA1 Task 1, GN 3) Anna Manolova Fagertun (DTU Fotonik) GN3 JRA1 T1&2 Workshop 2012, Copenhagen, 20-11-2012 connect • communicate • collaborate
Agenda Background – the task OTN introduction OTN architecture for NRENs OTN testing – results Discussion Summary 2 connect • communicate • collaborate
JRA1 Task 1: OTN and GMPLS The partners: NORDUnet, UNINETT and DTU Fotonik The vendors: ADVA, Ciena and Nokia Siemens Networks Time-line: finalized in April 2012 (Deliverable DJ1.1.2) Goal: To “learn” the technology – its advantages and limitations To investigate the maturity of existing platforms (not to compare!!) To evaluate the applicability of OTN within the NREN environment The assumptions: Seamless integration of digital and optical layers (standardized) Common platform for mapping ANY type of client signal – fits with the diversity of NRENs and supported service types Multi-granular switching and multi-level multiplexing for flexible high bit-rate flow handling Control-plane functionalities (GMPLS -compliant) 3 connect • communicate • collaborate
OTN introduction G.709 (ITU-T) – “standardized method for transparent transport of services over optical wavelengths in DWDM systems”. Interfaces and equipment Management aspects Architecture, mapping, G.873.1/873.2, G.874, G.806, G.709, G.798, structures G.870, G.872 G.808.1/808.2 G.798.1, G.959.1 Performance Control Plane G.8080,G.7712÷G.7716 G.8201, G.8251 STANDARD – mapping, mux-ing, switching, OAM, multi-domain Client OH Client Associated domain overhead Digital OH OPUk OH ODUk FEC OH OTUk Non-associated OCC OCC OCC OCC overhead OH OH OOS Optical Transport Module OSC 4 connect • communicate • collaborate
OTN benefits Flexible “all-client-type” mapping (ODU0 and HO ODUk ( ) Flow (VLAN) ODUflex ODUFlex) Phy Flow (VLAN) ODUflex HO ODUk ( ) Multi-level switching (any granularity) Phy ODUflex Phy ODUflex HO ODUk ( ) ODUj Phy HO ODUk ( ) Phy Physical Client Transport interface interface entity X X TCM – Tandem Connection Monitoring Client X X TCM6 TCM6 TCM6 TCM6 TCM6 TCM5 TCM5 TCM5 TCM5 TCM5 X Service provider TCM4 TCM4 TCM4 TCM4 TCM4 TCM3 TCM3 TCM3 TCM3 TCM3 Carrier TCM2 TCM2 TCM2 TCM2 TCM2 X TCM1 TCM1 TCM1 TCM1 TCM1 X A1 B1 C1 B2 C2 A2 X X C1 - C2 X Service provider B1 - B2 Client A1 - A2 5 connect • communicate • collaborate TCM OH field not in use TCM OH field in use TCMi TCMi
OTN benefits: cont. ODUk protection standardized Control Plane 1+1 SNCP GMPLS-compatible APS-based schemes (1:1; 1:n Automatic topology discovery shared protection, etc.) Automatic protection/restoration TCM-based SNCP(with sub- layer monitoring with SF/SD Bandwidth on demand conditions per TCM level) Vertical integration across layers OCH/OMS SPRing protection CAPEX and OPEX savings! Work in progress – survivability at the analogue layer!!!! The challenge – APS channel implementation – OOS – not standardized – IP packet format – use decoupled CP 6 connect • communicate • collaborate
OTN architecture for NRENs GMPLS Enabled GMPLS Enabled OTN Xchange Domain 2 OTN NORDUnet OTN OTN OTN Domain 4 OTN Domai 3 * GMPLS enabled WSS Common Operation based DWDM Node Standard E-NNI between domains – fast, seamless service establishment across borders Extended OAM across borders (end-to-end service monitoring) – SLA verification Advanced MUX and switching for traffic exchange at different levels 7 connect • communicate • collaborate Multi-level TCM – fast failure localization
OTN tests Client mapping and ODU switching ODU 0 and ODU Flex Multi-stage multiplexing, sub-flow switching Survivability Protection and Restoration GMPLS-assisted survivability Cross-domain OAM TCM TCM Delay measurements GMPLS control plane support Topology discovery Automatic service establishment/tear down Automated restoration 8 connect • communicate • collaborate
Test setups ADVA CIENA NSN 9 connect • communicate • collaborate
Test results Client signal mapping High-speed signal mapping – 10GE and 40 GE (GFP, GMP, BMP) ODU 0 – demonstrated ODU Flex – no vendor had it available (only a lab demo) ODU switching and multi-stage ODUk Mapping MUX path: ODU0-ODU1-ODU2-ODU3 ODU 0 – switched in the middle node Conclusions: – Functionalities according to standardization – The most promising feature (ODU Flex) is in the roadmaps – Very attractive features for support of high-bandwidth, dynamic cross-domain services. 10 connect • communicate • collaborate
Test results cont. Conclusions Survivability Standardized ODUk Many standardized schemes available survivability – 1+1 SNC/I – SD/SF at OTU Control-plane assisted overhead survivability – 1+1 SNC/N – SD/SF at PM field of Mesh-based recovery ODU overhead Explicit control of backup path via costs – 1+1 SNC/S – SD/SF at TCM level – Automatic – saves OPEX very attractive for multi-domain Combined schemes – great environments flexibility, novel service Control-plane assisted restoration opportunities – Dynamic control of the path via its cost – either administrative or based on delay measurements Hybrid Restoration/Protection – Pre-computed protection path – At time of failure, switch to the protection path and reactively compute a new protection path 11 connect • communicate • collaborate
Test results cont. TCM Client Provider Inter-provider link Results Very clear indication where the failure is No more “pointing fingers” – exact responsibility indicator Requires cooperative pre-planning, design and setup (complex and non-standardized procedure) Different vendors had different “views” of applicability! Multi-vendor interoperability can be problematic 12 connect • communicate • collaborate
Test results cont. GMPLS Via packet traces analysis – Topology discovery – via the OSPF-TE protocol – Automated provisioning and tear-down of connections – Automated restoration Standard implementations, with added proprietary features – May differentiate the vendors on the market – But provides for interoperability issues – Explicit GMPLS interoperability between different implementations is a must – Could be a GREAT tool for integrated, cross-layer/cross- domain control (operational intelligence) 13 connect • communicate • collaborate
Discussion Is OTN a relevant technology for your network? Why? Internally for the NREN itself With respect to serving current and future clients With respect to multi-NREN service delivery Which OTN functionalities are interesting for your organization, and which are irrelevant? Can you see any potential use for future services in you organization? Is OTN relevant for GEANT (as a backbone provider)? – interconnecting NRENs and facilitating guaranteed QoS across domains 14 connect • communicate • collaborate
Summary Highly scalable, future-proof technology Unprecedented client signal mapping Advanced OAM&P functionalities (GMPLS-ready) Excellent solution for multi-domain service provisioning Major vendors already offer advanced OTN functionalities 15 connect • communicate • collaborate
JRA1 Task 1 Contributors Contributors: Lars L. Bjørn – NORDUnet Kurosh Bozorgebrahimi – UNINETT Alberto Colmenero – NORDUnet (Task Leader) Rasmus Lund – NORDUnet Anna Manolova Fagertun – DTU Fotonik Please check the white paper and the final deliverable at the GN3 site 16 connect • communicate • collaborate
connect • communicate • collaborate Thank you for your attention 17
Recommend
More recommend
