OIF NNI: The Roadmap to Non-Disruptive Control Plane Interoperability
description
Transcript of OIF NNI: The Roadmap to Non-Disruptive Control Plane Interoperability
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 2000 Jan 2001 May/June 2001
Oct. 2001
UNI 1.0 approved, NNI
req. work startsUNI Interop
EventFirst 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.
UNI and NNI: Definition and Placement
Controldomain
Client Network(IP, ATM, SDH)
Optical Transport Network
NNI
UNI
UNI
UNI - User to Network InterfaceNNI - Network to Network Interface
UNI
NNIControldomain
Controldomain
NNI
Switched Connection: initiated by clients over UNI interface
Soft Permanent Connection (SPC): initiated by management agent
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 CCORE METRO 2METRO 1
NNI NNI
NNINNI
UNI 1.0
UNI 1.0
UNI 1.0: Transport Network is a “Black Box”
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.0NNI
NNI
UNI 1.0UNI 1.0
I/F
NNI Topology
Management Agent
UNI 1.0
NNI
Basic OIF NNI Concepts
Demonstrated in OFC 2003 Interoperability Event
Options for NNI Domain Abstraction
Inter-domain links
Intra-domain links
Border Nodes + Abstract LinksNNI routing advertises border nodes,
intra-domain & inter-domain links
Abstract Node NNI routing advertises abstract node
& inter-domain links
Data Plane Representation
Inter-domain data linksIntra-domain (abstract) linksControl 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
SC
SC
RC SC
RC
Border Node
NNI Routing Controller
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
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
Explicit Route Computation Example
METRO 1Control Domain
CORE 1Control Domain
CORE 2Control Domain
METRO 2Control Domain
A B C D ETNA_destTNA_src
Path Path Path
ERO: [B:if_b, C:if_c, D:if_d, E:if_e]
if_a if_b if_c if_d if_e
ERO: [C:if_c, D:if_d, E:if_e] ERO: <E:if_e]
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
“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
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
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?