OIF NNI: The Roadmap to Non-Disruptive Control Plane Interoperability

1. OIF NNI: The Roadmap to Non-Disruptive Control Plane Interoperability Dimitrios Pendarakis dpendarakis@tellium.com

2. OIF Interoperability Agreements: Timeline • Initial focus on UNI: signaling interface between optical network and clients • Emphasis on new service creation • Dynamic bandwidth provisioning between optical network and clients, as well as between clients • Integrated client/optical control plane • Integrated client-optical layer traffic engineering • Additionally, simpler than an NNI - Decision to focus initially on UNI UNI 1.0 approved, NNI req. work starts First NNI proposals & Interim NNI NNI routing & signaling baseline spec. First UNI 1.0 draft ballot UNI Interop Event UNI/NNI Interop. May 2000 Jan 2001 May/June 2001 Oct. 2001 Jan. 2002 Jul. 2002 Mar. 2003

3. UNI and NNI: Definition and Placement Switched Connection: initiated by clients over UNI interface Soft Permanent Connection (SPC): initiated by management agent Optical Transport Network Control domain UNI NNI UNI Client Network (IP, ATM, SDH) NNI Control domain NNI Control domain UNI UNI - User to Network Interface NNI - Network to Network Interface

4. NNI NNI NNI NNI METRO 1 METRO 2 CORE UNI & NNI: Comparison UNI 1.0: Transport Network is a “Black Box” • UNI 1.0 Components • Signaling: across two interfaces, ingress and egress, carries no path information • NNI Components • Signaling: across multiple interfaces (control domains), typically carries path information • Routing: abstracts and summarizes control domain topology and reachability information • Common: Neighbor & service discovery (optional) Client B Client A UNI 1.0 UNI 1.0 UNI 1.0 Client C

5. NNI Topology CORE DOMAIN 1 METRO 2 NNI Management Agent I/F Client 1 METRO 3 Client 3 UNI 1.0 UNI 1.0 Client 5 CORE DOMAIN 3 METRO 1 UNI 1.0 NNI Client 2 Client 4 UNI 1.0 CORE DOMAIN 2 NNI

6. Basic OIF NNI Concepts Demonstrated in OFC 2003 Interoperability Event

7. Options for NNI Domain Abstraction Data Plane Representation Abstract Node NNI routing advertises abstract node & inter-domain links Border Nodes + Abstract Links NNI routing advertises border nodes, intra-domain & inter-domain links Inter-domain links Intra-domain links

8. RC RC SC SC SC SC Control and Data Separation Inter-domain data links Intra-domain (abstract) links Control Network (Ethernet for OFC) Border Node NNI Signaling Controller RC NNI Routing Controller • Each domain has one or more signaling and routing controllers • Each inter-domain link associated with a SC and a RC • May or may not coincide • May or may not be collocated with border nodes • Same or different addresses with border nodes • NNI Signaling and Routing protocols allow for full flexibility in specifying all these different addresses

9. NNI Signaling Functionality • Signaling between domains • Two types of connections • Switched: initiated by clients over a UNI 1.0 interface • Requires forwarding of UNI requests & parameters into NNI end-to-end • Soft permanent: initiated by management plane (CIT/EMS/NMS) without involving client signaling • Requires appropriate management interface. Currently proprietary, company specific • Allows management plane to specify complete path • Similar to traditional management plane approach

10. NNI Signaling: Explicit Routes • Support for Explicit Routes • Path typically known at the source • Computed at or provided to ingress node • Required for diversity and protection • Explicit routes consist of sequence of inter- and intra-domain links • Strict in the sense that all links from source to destination are known. • But intra-domain links may be abstracted, so the explicit route may be expanded within a domain

11. Explicit Route Computation Example CORE 1 Control Domain METRO 2 Control Domain CORE 2 Control Domain METRO 1 Control Domain A B C D E TNA_src TNA_dest if_c if_d if_e if_b if_a Path Path Path ERO: [C:if_c, D:if_d, E:if_e] ERO: <E:if_e] ERO: [B:if_b, C:if_c, D:if_d, E:if_e]

12. NNI Signaling: “Carrier Grade” Operation • Control and data plane separation • Separation between signaling controllers and border nodes (data plane) • Support for multiple address spaces and types • Data plane robustness in the presence of control plane failures • If control plane fails, existing data connections should be unaffected - Signaling Restart Capability • Graceful deletion – deletion of connections does result in unnecessary generation of alarms • The problem: light travels faster than signaling • If source turns off data (light) destination may detect invalid data input before deletion signal received and declare fault

13. “Non-Disruptive” Interoperability • Concept of Control Domains minimizes the changes in existing equipment • Control and data separation and single/multiple signaling & routing controller options allow significant deployment flexibility • SPC availability allows gradual migration from centralized management plane solutions • Signaling sufficiently separated from routing protocols – allows gradual NNI deployment

14. Importance of OFC Interoperability Event • One of the first, if not the first, interoperability event combining distributed routing and signaling • (G)MPLS-based signaling (RSVP-TE) and routing (OSPF-TE) • Incorporates OIF and ITU extensions for operation in optical transport networks • Demonstrates feasibility of distributed control plane solutions • Allows us to uncover and clarify potential issues in GMPLS specifications

15. Some Open Issues • Multiple routing protocol proposals • Management & OAM&P interfaces • Configuration, monitoring, state information retrieval • Network element to EMS interfaces • SNMP MIBs, TL1, CORBA? • EMS to NMS extensions for integration with a multi-domain, multi-technology network • Multiple signaling protocols – translation? • Alignment with ITU (7713.x) and IETF • Interaction with restoration signaling?