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 - May 2000Jan 2001May/June 2001 Oct. 2001 UNI 1.0 approved, NNI req. work starts UNI Interop Event First UNI 1.0 draft ballot Decision to focus initially on UNI Jan. 2002 First NNI proposals & Interim NNI Mar. 2003 UNI/NNI Interop. Jul. 2002 NNI routing & signaling baseline spec.

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

4. UNI & NNI: Comparison  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 Client C CORE METRO 2METRO 1 NNI UNI 1.0 UNI 1.0: Transport Network is a “Black Box”

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

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

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

8. Inter-domain data links Intra-domain (abstract) links Control Network (Ethernet for OFC) NNI Signaling Controller Control and Data Separation 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 RC SC RC SC RC Border Node NNI Routing Controller

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 METRO 1 Control Domain CORE 1 Control Domain CORE 2 Control Domain METRO 2 Control Domain A BCDE TNA_dest TNA_src Path ERO: [B:if_b, C:if_c, D:if_d, E:if_e] if_a if_b if_cif_dif_e ERO: [C:if_c, D:if_d, E:if_e]ERO: <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?