oif nni: the roadmap to non-disruptive control plane interoperability

OIF NNI: The Roadmap to Non-Disruptive Control Plane

Interoperability

Dimitrios Pendarakisdpendarakis@tellium.com

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?