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

OIF NNI: The Roadmap to NonDisruptive Control Plane
Interoperability
Dimitrios Pendarakis
[email protected]
OIF Interoperability Agreements:
Timeline
Decision to
focus initially
on UNI
First UNI 1.0
draft ballot
May 2000

Jan 2001
UNI Interop
Event
UNI 1.0
approved, NNI
req. work starts
First NNI
proposals &
Interim NNI
NNI routing &
signaling
baseline spec.
May/June
2001
Oct. 2001
Jan. 2002
Jul. 2002
UNI/NNI
Interop.
Mar. 2003
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 -
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 - User to Network Interface
NNI - Network to Network Interface
UNI
UNI & NNI: Comparison
UNI 1.0: Transport Network is a “Black Box”
Client B
NNI
NNI
Client A
UNI 1.0
UNI 1.0
NNI
METRO 1
UNI 1.0
NNI
CORE
METRO 2
Client C

UNI 1.0 Components
•

NNI Components
•
•

Signaling: across two interfaces, ingress and egress, carries no path
information
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)
NNI Topology
CORE DOMAIN 1
METRO 2
NNI
Management
Agent
I/F
Client 1
METRO 3
UNI 1.0
Client 3
UNI 1.0
Client 5
UNI 1.0
Client 2
CORE DOMAIN 3
METRO 1
NNI
Client 4
UNI 1.0
CORE DOMAIN 2
NNI
Basic OIF NNI Concepts
Demonstrated in OFC 2003 Interoperability Event
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
Control and Data Separation
SC
RC
Inter-domain data links
Intra-domain (abstract) links
SC
Control Network (Ethernet for OFC)
Border Node
SC
RC
SC
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
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 interand 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
CORE 1
Control Domain
METRO 2
Control Domain
CORE 2
Control Domain
METRO 1
Control Domain
A
B
TNA_src
C
D
E
TNA_dest
if_a
Path
ERO: [B:if_b, C:if_c, D:if_d, E:if_e]
if_c
if_b
Path
ERO: [C:if_c, D:if_d, E:if_e]
if_d
if_e
Path
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 multidomain, multi-technology network
Multiple signaling protocols – translation?
Alignment with ITU (7713.x) and IETF
Interaction with restoration signaling?