Transcript Optical Control Plane Protocols

Optical Control Plane
Initiatives: GMPLS, G.ASON
and OIF UNI/NNI
Steve Cortez
Lyndon Ong
Ciena Corporation
7/21/2004 1:30 PM
Agenda
• What is a Control Plane
– Evolution from Telephony
– Evolution from Packet
– How it’s applied to Optical Networks
• Control Plane Protocols
– The different standards bodies and roles
– GMPLS – core protocols
– ASON extensions from ITU-T
– OIF Implementation Agreements and Testing
• Interoperability Demonstrations
• Conclusion
2
What is the Control Plane?
• Control planes are familiar ground for telephony
– DTMF tones/In-band signaling
– Signaling System 7/ISDN
– ATM Signaling
• Signaling supports connection control functions
– Connection address and characteristics
– Confirmation of setup and teardown
• Routing and Discovery added
3
Examples
• In-band signaling
– Control carried in the same data stream as data
– Examples: telephony tones/ring; IP control
applications such as SIP; MPLS control protocols
• Out-of-band signaling
– Control carried in a separate logical or physical
data stream
– Examples: SS7 – a physically separate control
network overlay for telephony network control
4
Routing and Discovery
• ATM PNNI
– PNNI – Private Network-Network Interface
• ATM Forum-defined signaling/routing protocol for ATM networks
• Completed circa 1996
– ATM PNNI extends traditional telephony protocols
• Adds link state routing protocol to distribute topology information
• Adds neighbor discovery mechanism
• Connection setup supports loose or strict explicit routes (Designated
Transit Lists)
– The routing protocol supports multi-level hierarchy
• Theoretical 104 levels of hierarchy
• Automated methods for topology summarization
5
Evolution from the Packet Side
• RSVP – Resource Reservation Protocol
– Original RFC 2205 from IETF
– Supports one-way reservation of router resources
– Path still utilizes IP routing tables
– Multipoint-to-multipoint capability through filtering
controls
6
RSVP Evolution
• MPLS
– RSVP protocol used to assign labels to a flow (going back to
Tag Switching)
• MPLS-TE
– RSVP protocol used with explicit source routing
• GMPLS
– Extensions to MPLS for circuit networks
• TDM (SONET/SDH) switching
• Lambda switching
• Fiber switching
– All lumped under the category of “optical” networks
7
Existing SONET/SDH/OTN Control
Functions
• Overhead Bytes
– Performance monitoring
– Fault notification/isolation
– Ring/linear protection signals
• Communications Channel
– DCC – for SONET/SDH
– GCC – for OTN
– One option for “signaling channel”, other is
external control network
8
Summary - Control Plane Functions for
Optical Networks
• Automatic Neighbor Discovery
– Allows a node to determine the identity of each
neighboring node and the set of links that connect
them.
• Routing, or topology dissemination
– Allows every node to automatically discover the
complete network topology and resources
• Signaling for Connection Provisioning
– Allows the establishment and restoration of a path
from one end of the connection
9
Sequence for Creating Connections
Inventory & Resource Management
2. Global Topology Dissemination
1. Neighbor Discovery
NETWORK
MGMT PLANE
User
User
OUNI
CONTROL PLANE
DATA PLANE
3. Connection Request
4. Path Calculation (NE-based or EMS-based)
Dynamic Provisioning
5. Establish Connection
10
Additional Functions
• Services
– Class of service
– VPN
• IP Integration
– Advertisement of topology to routers
– Common management view
11
Control Plane Protocols
Standards Bodies and Organizations
Charter: Global Telecom Architecture and
Standards
Membership Fee: minimum $18,900/yr (31,500 Swiss Fr.)
No. of Members: 189 Member States + 434 Sector Members
Member Organizations:
• Global Service Providers
• PTTs, ILECs, IXCs
• Telecom equipment vendors
• Governments (e.g., US State Department)
Charter: Evolution of the
Internet (IP) Architecture
Charter: Development of Optical
Networking Products and Services
Membership Fee: None
Membership: Individuals – community model
Membership Fee: $8000/yr
No. of Members: 312 Principal Members
Active Participants:
• ISPs
• Service Provider IP Divisions
• IP/Ethernet Vendors
Member Organizations:
• PTTs, ISPs, ILECs, IXCs
• Optical Networking Vendors
13
Standards Development Organizations
(SDO) Interaction
•
Evolution towards
convergence of requirements
& protocols, enabling
– Common/generic set of
base protocols, with
– Protocol extensions for
optical transport domain
application
ITU-T ASTN/ASON Umbrella
•
OIF
Implementation
Agreements
IETF GMPLS Umbrella
14
Liaisons between all three
SDOs on requirements and
protocol work
– IETF CCAMP and ITU-T joint
design team on routing
currently in progress
Optical Standards Efforts
• IETF
– GMPLS
• Extensions to MPLS control protocols to support generic label control,
including TDM, lambda and fiber “labels”
• ITU-T
– ASON
• Automatic control of transport networks (SONET/SDH, OTN) using
available control protocols
• OIF
– UNI and NNI Implementation Agreements
• Agreed profiles and usage of standards at boundary points between
and within carrier optical networks
15
GMPLS Overview
• GMPLS extends MPLS/MPLS-TE control plane
– Extensions primarily driven by characteristics of TDM,
Lambda and Fiber Switching
– GMPLS extends MPLS control planes to support ANY class
of interfaces (i.e. layers)
• PSC - Packet Switching Capable: IP/MPLS
• L2SC - Layer-2 Switching Capable: ATM, FR, Ethernet
• TDM - Time-Division Multiplexing: Sonet, SDH, G.709 ODUk
• LSC - Wavelength Switching: Lambda, G.709 OCh
• FSC - Fiber Switching
16
New Assumptions for GMPLS
• Separate the Control Plane and Data Plane
– MPLS
• LSR combines control and IP data forwarding functions
• Same port serves both data and control packets
– GMPLS
• LSR can be a switch with no IP (data plane) functions
• Different ports or logical channels support data and control
This is changed for GMPLS
17
Fully Out of Band Control Plane
• Control Plane for TDM, LSC and FSC devices
can be implemented in a separate network
– Example: Fast Ethernet
Control Plane
18
In-fiber Logically Separate Control Channel
• Assumption is a SONET/SDH capable device
• Recommendation is to use DCC (Data
Communication Channel) bytes within
SONET/SDH overhead
– Section (RS) DCC is bytes D1, D2 and D3 (total
192kbps)
– Line (MS) DCC is bytes D4-D12 (total 576kbps)
SONET/SDH
ADM
LSR
19
GMPLS Mechanisms
• GMPLS control plane architecture includes
several extended MPLS-TE building blocks
– Signalling Protocols: RSVP-TE and CR-LDP
– Routing Protocols: OSPF-TE, ISIS-TE
– New protocol for link management
• Link Management Protocol (LMP)
• LMP-WDM
– Associated MPLS MIBs
20
GMPLS Signalling
• Common signalling extensions
– Generalized Label Request including
• LSP Encoding Type
• Switching Type
• Payload Type (G-PID)
– Upstream Label: bi-directional LSP
– Label Set: tackle wavelength continuity in All Optical
Networks
– Suggested Label: to improve processing
• Technology dependent extensions: Traffic parameters
– TDM: SDH (ITU-T G.707) and Sonet (ANSI T1.105)
– OTN: G.709 OTN (ITU-T G.709) including Pre-OTN
21
RSVP – IP version
Source
Path message flow, addressed directly
to the unicast/multicast destination
Resv message flow, hop-by-hop
A
B
G
C
D
F
H
E
I
Receiver 1
Receiver 2
22
RSVP – GMPLS version
Source
Path message flow, sent hop-by-hop
to a single destination, with
ERO = {A; B; C; D}
A
Resv message flow, hop-by-hop
C
B
Point-to-point connection setup
Periodic refresh still required
Source assumed to know network topology
D
Receiver
23
Generalized Label Request
Length
LSP Enc. type
8 bits,
Encoding
Types =
packet,
Ethernet, PDH,
SONET/SDH,
DW, , Fiber,
FibreChannel
Class-Num
C-type
Switching Type
G-PID
8 bits, Types =
switching
capabilities from
routing (PSC,
L2SC, TDM, LSC,
FSC)
16 bits, Types = payload
identifiers of the client layer for
use by LSP end-point nodes.
Examples of types include
Asynch mapping of DS-1/T1, ,
FDDI, POS – Scrambled 16 bit
CRC
G-PID is normally only
examined at the egress
24
Bidirectional LSPs
• Why bidirectional LSP set-up?
– Reduces set-up latency, which could be significant for unidirectional
path set-up for restoration
– Reduces control messages (separate PATH and RESV for uni)
– Simplifies route selection, avoids race conditions
– Provides clean hop-by-hop paths for SONET/SDH-protected
equipment
• Presence of an Upstream label is trigger for bidirectional
path set-up
• Label contention resolved by local policy or Node with
higher ID
25
SDH/Sonet Traffic Parameters
Signal Type (8-bits)
RCC (8-bits)
NCC (16-bits)
NVC (16-bits)
Multiplier (16-bits)
Transparency (32-bits)
Profile (32 bits)
Signal Type
Number of components (timeslots)
•
Elementary Component
•
NCC: Contiguous concatenation
•
E.g., SONET STS-1, SDH VC-4
•
NVC: Virtual concatenation
Requested Contiguous Concatenation
(RCC)
•
Multiplier (multiple connections)
Transparency
Flag field
Profile (for further study)
26
SONET/SDH Label Definition
16
4
4
4
S
U
K
L
4
M
xN
STM-N
AUG
AU-4
VC-4
C-4
139.264 kbit/s E4
x3
TUG-3
x3
TU-3
VC-3
C-3
44736 kbit/s DS3/T3
34368 kbit/s E3
TU-2
VC-2
C-2
6312 kbit/s DS2/T2
TU-12
VC-12
C-12
2048 kbit/s E1
TU-11
VC-11
C-11
1544 kbit/s DS1/T1
x7
AU-3
VC-3
SDH
x7
TUG-2
x3
x4
S
U
K
L
M
xN
STS-N
44736kbit/s DS3/T3
SPE
x7
VT group
x2
SONET
x3
VT-6
SPE
6312 kbit/s DS2/T2
VT-3
SPE
3152 kbit/s DS1C
VT-2
SPE
2048 kbit/s E1
VT-1.5
SPE
1544 kbit/s DS1/T1
x4
S
L
U
S
U
27
L
M
M
Waveband Switching
Lowest  in the
band from sender’s
perspective
•
Generalized label:
Waveband ID – 32 bits
Start Label 32 bits
Highest  in the
band from sender’s
perspective
End Label 32 bits
•
Can optimize OXC switching
performance
•
Introduces another layer of hierarchy
28
Suggested Label
• Upstream node sends preference to downstream node
• Allows upstream node to start configuration
– Reduces set-up latency
– Faster restoration path set-up
– Optimization that may be overridden by downstream node
• Upstream node should not transmit data until downstream
node sends corresponding label upstream
29
Label Set
• Limits per-hop label choices
• Usage examples:
– Only certain range of s, or bands, can be transmitted
– No -conversion is available over certain hops or entire path
– -conversion must be limited to reduce optical impairments
– Link ends support different  ranges
, fiber, etc. available for allocation
Inclusive or exclusive list, or range
Action - 8 bits
Reserved - 10 bits
Label type - 14 bits
Subchannel 1
Subchannel N
30
GMPLS Signalling – Other
• Explicit Label Control – allows precise label control
• Protection information
– Protection and restoration now under study
• Administrative Status Information
– Reflect the object back
– Testing mode
– Administratively down
– Deletion in progress
31
GMPLS TE-Routing Extensions
• GMPLS based on IP routing and addressing models
• IPv4/v6 addresses used to identify PSC and non-PSC
interfaces
• Re-using of existing routing protocols enables:
– benefits from existing intra and inter domain trafficengineering extensions
– benefits from existing inter-domain policy
• Extend TE-Routing Attributes defined for MPLS-TE
• For SDH/Sonet, G.709 OTN transmission technology,
GMPLS-TE defines technology dependent TE extensions
32
Routing in GMPLS Networks
• OSPF-TE and ISIS-TE extensions for GMPLS
– Support for unnumbered links
– Link protection type
– Shared Risk Link Group Information
– Interface switching capability descriptor
– These extensions are additional sub-TLVs of:
• TE Link TLV in OSPF-TE
• Extended reachability TLV in ISIS-TE
33
Hierarchical LSPs
IP Routing Protocols
With Extensions
OSPF, ISIS
MPLS TE
RSVP TE
Unified Control Plane
GMPLS
Label Distribution Protocols
CR LDP, RSVP TE
An LSP must start and end on the
LSRs of the same type.
TE
LSP
Router
Router
PSC
Domain
Forwarding
Plane
Router
Router
TSC
Domain
OXC
 Switch
SONET
SDH NE
LSC
Domain
SONET
SDH NE
OXC
Fiber
Domain
 Switch
OXC
OTN
GMPLS Domain
LSP Packet
FA-PCS LSP FA-TDM LSP
Lambda
TDM
FA-LSC LSP
Fiber
34
SONET
SDH NE
 Switch
SONET
SDH NE
Router
Router
OXC
TE
LSP
Nested LSPs
 Switch
Router
Router
LSP Hierarchy
FA-LSP…Forwarding Adjacency LSP
Nested LSPs
LSP Packet
FA-PCS LSP FA-TDM LSP
Lambda
TDM
FA-LSC LSP
Fiber
•
Enables aggregation of GMPLS LSP tunnels
•
Accomplished by
–Inter-LSR LSP tunnel (FA-LSP) link is created
–Ingress LSR injects link (FA-LSP) into IGP database
–Other routers use the link in path calculation/setup
–Other LSP tunnels are nested inside FA-LSP
–FA LSP is policy driven
•
Advantages
–Fewer high-order labels (e.g.lambdas) consumed
–Nested LSPs can be of non-discrete bandwidth
–FA-LSP can “hide” topology
35
GMPLS TE-Routing Extensions
• Flooding (dissemination) process within an OSPF area.
• Link-state protocols use bundling capabilities, so Router
TLV provides the Node ID
• Technological hierarchies or LSP regions defined per
interface Switching Capability (for instance, LSC)
• Border and intermediate nodes can be multi-service
devices i.e. more than one switching capability (for
instance: Switching Capability = TDM and LSC)
36
IETF OSPF Routing
Router OSPF Hello
Local DB Synchronization
Link State Update
37
OSPF – GMPLS Version
OSPF Hello
DB Synchronization
Link state update
A
C
B
LSA contents:
-Link interface identifiers
-Link metric and color
-Link switching type
-Link available bandwidth
-Link protection type
-Link SRLG
D
38
Interface switching capability descriptor
• Interfaces at each end of a link may be different
• Interfaces on same node may be different
• Descriptor may include additional information
• Types:
Additional information
– PSC-1,2,3,4
min/max LSP bw, max MTU
– TDM
min/max LSP bw, signal type
– LSC
bw supported at given priority
• A TE link label tuple determines link’s capability
– [PSC, TDM] represents a TDM time slot
– [TDM, LSC] represents an OXC port
40
Link Bundling
Multiple
s
Multiple
fibers
Advertise every ?
OR
Advertise 1 Bundled Link!
Adds scalability
41
Unnumbered Links - Routing
• Local and remote interface identifiers are carried in sub-TLVs of the
Link TLV, types 11 and 12 in OSPF-TE, extended IS reachability TLV
in ISIS-TE
LSR 2 assigns
locally unique 32-bit
“local” identifier to
each link
LSR 2
LSR 3
42
LSR 3 assigns
locally unique 32-bit
“local” identifier to
each link
Link Management Protocol - LMP
• LMP Protocol provides:
– IP Control Channel dynamic configuration
– IP Control Channel maintenance (Hello Protocol)
• ultra-fast (bi-directional sequencing)
• reliable and robust
– Link Property Correlation (Link bundling - TE Link)
– Link Testing (optional)
– Fault Management (optional)
• detection (using LoS/LoL/etc.)
• localization/correlation (alarm suppression)
• reliable notification
43
LMP – Control Channel Maintenance
• LMP adjacency
– 1 or more Bi-directional CCs
– IPCC independent of TE links
– LMP Hello exchange
• Unless other underlying keep-alive mechanism
Hello (A1,P1)
T
P1
R
T
P2
Hello (A2, P2)
R
Hello Ack (A2, P2, A1, P1)
Hello Ack (A1, P1, A2, P2)
A1
A2
44
LMP – Verify Link Connectivity
• When using out of band control channel, need to test data bearing
channels
• Must be opaque (at least during the test!)
BeginVerify
(#, interval, data rate, etc.)
BeginVerifyAck (VerifyID)
A1
P1
P10
Test Messages (P1, VID)
P2
P11
P3
P12
TestStatusSuccess
(P1, P10, VID)
A2
45
TestStatusAck (VID)
GMPLS Recovery Mechanisms
• 4 Steps of Fault Management
• Fault detection
– Handle at the layer closest to failure
• LOL, OSNR, at optical layer
• BER, LOL at SONET/SDH layer
• Fault Localization
– Communication between nodes to “localize” failure (E.g. LMP, AIS)
• Fault Notification
– Communication between detecting node and node that institutes
recovery (E.g. RSVP-Notify)
• Fault Recovery
46
Path Protection & Restoration
X
C
B
D
A
Y
X
Pre-emptible
traffic
• Ingress node initiates recovery
• New path can be dynamic or pre-calculated
• Pre-calculated disjoint paths can use SRLG information
• Protection paths can be flagged as secondary paths and
used for pre-emptible traffic
47
Span Protection & Restoration
C
B
D
X
A
Y
X
• Can start restoration at an intermediate node
• New “segment” can be dynamic or pre-calculated
• Faster for large mesh networks
48
Notify Request Object and Notify Message in
RSVP-TE
Path Notify Request: LSR A
LSR A
X
Notify LSR A
•
Optional Notify request objects can be carried in Path and Resv
messages
•
Indicates address of the node to be notified of an LSP failure
•
Notify message serves to inform non-adjacent node of LSP-related
events
•
Includes:
– ERROR_SPEC defines error and IP address of failed link/detecting node
– MESSAGE_ID if refresh reduction is supported
49
ITU ASON
ITU-T ASON Family Tree
G.807
ASTN
G.8080
ASON
G.7712
DCN
G.7713
Signaling
G.7713.1
PNNI
version
G.7713.2
RSVP
version
G.7713.3
CR-LDP
version
G.7714
Discovery
G.7715
Routing
G.7714.1
SDH/OTN
Discovery
G.7715.1
Link State
Routing
Requirements
51
G.7718
Control Plane
Operation
ITU-T ASTN/ASON
Architecture Reference Framework
•
•
•
•
Goal: Support services through the
automatic provisioning of end-to-end
transport connections across one or
more managerial/administrative
domains.
Involves both a Service and Connection
perspective:
o
o
The Service (call*) perspective is to
support the provisioning of end-to-end
services while preserving the
independent nature of the various
businesses involved.
The Connection perspective is to
automatically provision “path layer”
connections (in support of a service)
that span one or more
managerial/administrative domains.
Reflected in reference points
between a user and a provider
domain (UNI), between domains (ENNI), and within a domain (I-NNI)
–
UNI: user-provider service
demarcation point
–
E-NNI: service demarcation point
supporting multi-domain connection
establishment
–
I-NNI: connection point supporting
intra-domain connection
establishment
UNI
User 1
E-NNI
Domain 1
Call control* is a signaling association between one or more user
applications and the network to control the setup, release,
modification and maintenance of sets of connections
52
UNI
Domain 2
User 2
Terminology
• Peer Model
– all network nodes (routers and switches) act as peers and exchange full
topology information
– GMPLS formerly assumed peer model. ASON accepts peer model only
as an internal domain method.
• Overlay Model
– a client system does not know network topology or routing
– only supports connection request signaling.
– GMPLS now accepts the overlay model as an option. ASON supports
overlay through UNI
• Domain Model
– networks are partitioned into domains with differing characteristics,
– interwork through an inter-domain interface.
– GMPLS has not yet accepted the domain model. ASON supports the
domain model through E-NNI.
53
Peer vs. Overlay vs. Domain Models
Peer Model
-- A:Setup (x,y,z,B)
B
z
A
x
y
Overlay Model
-- A:Setup (B)
Core
UNI
UNI
I-NNI
B
A
Core
UNI
E-NNI
Domain Model
Core
UNI
I-NNI
I-NNI
A
54
B
ITU-T ASTN/ASON
Architecture Reference Framework (cont.)
UNI
Domain 1
E-NNI
Domain 2
E-NNI
User 1
Domain 3
UNI
Connections
User 2
Connections
Connections
End-to-end call
Call segments
Connection
segments
Example of Call with multiple call and connection segments
•
Both the UNI and E-NNI are service
demarcation points; i.e., call control is
provided
–
•
Service demarcation points hold call
state, which is distinct from
connection state throughout the
network
55
E-NNI applications examples include:
–
The service is realized in different ways
within each domain
–
Separate address spaces are used
within each domain, especially when
separately administered
–
There is independence of survivability
(protection/restoration) for each domain
–
There is a trust boundary
Details: ASON Signaling
• G.7713.1
– PNNI-based signaling for ASON
– Extensions from PNNI signaling
– No equivalent in GMPLS
• G.7713.2
– RSVP-based signaling for ASON
– Extensions from GMPLS RSVP (RFC 3473)
– Codepoints documented by IETF as RFC 3474
• G.7713.3
– CR-LDP-based signaling for ASON
– Codepoints documented by IETF as RFC 3475
56
G.7713.2: Addressing Separation
•
Goal: separate internal network address space from client address
space
– Clients have no visibility into the network address space
•
Solution: Transport Network-assigned Address (TNA)
– IPv4, IPv6 or NSAP formats allowed
Core
UNI
I-NNI
UNI
A
X
A:Setup (B)
B
Z
Setup (B)
Y
Setup {(TNA=B);
ERO=(X;Y;Z)}
57
G.7713.2: Multi-session RSVP
Domain A
Client
E-NNI
Domain B
E-NNI
Domain C
Client
Connections
Call
Segment
UNI
Segment
Sub-network
Segment
E-NNI
Segment
RSVP-TE
Signaling
UNI
Session
I-NNI
Session
E-NNI
Session
I-NNI
Session
E-NNI
Session
I-NNI
Session
UNI
Session
Mixed
Signaling
RSVP-TE
UNI
Session
CR-LDP
Network
LSP
CR-LDP
E-NNI
LSP
PNNI
Network
Connection
RSVP-TE
E-NNI
Session
RSVP-TE
I-NNI
Session
RSVP-T E
UNI
Session
Sub-network
Segment
58
E-NNI
Segment
Sub-network
Segment
UNI
Segment
ITU-T ASTN/ASON Routing Work
• ITU-T Rec. G.7715 Approved July ’02
– Focus upon inter-domain routing
– Provides architecture, requirements, high-level attributes, messages,
and state diagrams from a protocol-neutral perspective
– Protocol neutral requirements include support for, e.g.,
•
Multiple hierarchical levels
•
Independence from intra-domain protocol and control distribution choices
•
Architectural evolution (levels, aggregation, segmentation)
– Encompasses different classes of protocols (e.g., link-state, path
vector)
• ITU-T Rec. G.7715.1 Approved Feb. ‘04
– Based upon ASON foundation Recommendations (G.8080, G.7715),
focusing upon link-state based routing
– Supports control domain constructs, support for multiple hierarchical
routing levels, realistic transport network deployment scenarios
• Facilitates analysis of protocol specific E-NNI routing
59
ITU-T Hierarchy Model
• OSPF provides an horizontal hierarchy (or
partitioning), aimed at making a given layer more
scalable and keeping the RDB size limited
ASON requires a vertical
hierarchy (or layering) of
the control plane. This can
be achieved by multiple
OSPF instances, each
corresponding to a routing
area of the control plane
hierarchy
60
Containment Model
• Containment model of hierarchy
– area boundaries bisect links, not nodes
= BR
SubArea
2.0.0.1
Cloud
Cloud
SubArea
2.0.0.2
SubArea
2.0.1.0
SubArea
2.0.0.0
SubArea
2.0.1.1
Cloud
Cloud
Cloud
SubArea
1.0.0.0
Cloud
SubArea
2.0.2.1
Cloud
Backbone
0.0.0.0
SubArea
1.0.0.1
Cloud
SubArea
2.0.2.0
Cloud
Cloud
SubArea
1.0.0.2
Cloud
Cloud
Cloud
SubArea
2.1.1.0
Cloud
SubArea
1.0.1.0
Cloud
SubArea
2.1.1.1
SubArea
1.0.1.1
Cloud
SubArea
1.0.1.2
SubArea
1.0.1.3
Joint Design Team effort underway with IETF CCAMP
61
ITU-T ASTN/ASON Activities
• Development underway of draft Rec. G.7718
– To address the management aspects of the ASON control
plane and the interactions between the OSS (NMS/EMS) and
the ASON control plane
– Work areas include
• ASON management requirements
• Use cases and scenarios
• ASON management classes, relationships, behavior
– Working relationships established among related standards
bodies and industry fora
• SG 4 – coupling with existing management Recommendations
• TMF MTMN – providing basis for TMF 814 optical control plane
extensions
• OIF – coupling re carrier requirements
62
OIF
Optical Internetworking Forum
• Launched in April of 1998 with an objective to foster
development of low-cost and scaleable internet using optical
technologies
• The only industry group bringing together professionals from
the data and optical worlds
• Open forum: 170+ member companies
– International
– Carriers
– Component and systems vendors
– Testing and software companies
• Mission
To foster the development and deployment of interoperable
products and services for data switching and routing using
optical networking technologies
64
Optical Internetworking Forum
• Focused on carrier requirements for optical
networking
– Carrier Working Group defines requirements
– Architecture/Signaling Group defines agreements
– Interop Group runs interop tests
• Recent “World Demo” ran at 7 carrier labs
65
OIF Optical UNI 1.0
• Work based on ITU-T G.7713.2 protocol plus IETF LMP
– UNI  client application only
– Signaling, but no Routing
• Modifies LMP for AutoDiscovery
– Neighbor discovery supported with DCC control channel
– Several functions not needed
• Modifies RSVP for Overlay/Domain model
– Separate client addressing space (TNA)
– Multi-session RSVP
– Code assignments documented also in IETF RFC 3476
• Now in Release 1.1
66
OIF UNI 2.0
• UNI 2.0 under development
– Project plan is oif2001.615, Draft specs. oif
2003.293 and oif2003.351
– Incorporates separation between call and
connection control
– Targets enhanced features for UNI such as
• Ethernet clients
• Call modification
• G.709 client-to-network interfaces
• Dual-Homing, Enhanced Protection
67
OIF E-NNI 1.0
• Incorporates NNI functionality
– Both Signaling and Routing
– Common inter-domain protocol
– Diverse interior domain protocol
• Standards-based
– G.7713.2-based signaling protocol (RSVP)
– G.7715.1-based routing
• Status
– E-NNI Signaling 1.0 approved 2/04
– Routing in progress
– Early implementations tested successfully
68
OIF Control Plane Activities
• OAM&P Activities
– Topics and requirements for the management plane support
of ASON, including management plane functional
requirements from a carrier’s perspective (oif2003.364.00)
– Control Plane Logging and Auditing with Syslog IA under
development (oif2003.119.03)
– OIF-SEP-01.1 – Security Extension for UNI and NNI
– OIF-SMI-01.0 – Security Management Interfaces to Network
Elements
– OIF-CDR-01.0 – Call Detail Records for OIF UNI 1.0 Billing
69
GMPLS/ASON Interoperability
Is the technology maturing…..
• Interoperability Tests
– OIF UNI Interop (SuperComm 2001)
– MPLS Forum GMPLS Interop (NGN 2002)
– OIF UNI/E-NNI Interop (OFC 2003)
– GMU MPLS/GMPLS Interop Test (2004)
– ISOCORE MPLS/GMPLS interop Test (2003/2004)
– OIF World Interoperability Demo (SuperComm 2004)
• Technology maturing, functional and being deployed
• However, some critical areas need to be addressed:
– Control/management plane interactions and specifications
– Extensions for E-NNI routing
– Issues related to support of enhanced functions
70
Interoperability Demos
What is the OIF World Interoperability
Demonstration?
Interoperability of Intelligent Optical Networks
–
Interfaces
•
O-UNI 1.0 (Optical User Network Interface)
•
E-NNI 1.0 (External Network to Network Interface)
– Interoperability
•
Network Topology Discovery
•
Provisioning and Support of Switched High Speed Circuits
Ethernet/SONET adaptation using Generic Framing Procedure
(GFP)
– Capabilities demonstrated
•
Fast Ethernet (100 Mb/s) on a mix of SONET/SDH payload options
•
Gigabit Ethernet (1Gb/s) on a mix of SONET/SDH payload options
72
Who is participating?
15 Vendors
7 Carriers in 3 continents
– ADVA
– Alcatel
Asia
– Avici Systems
– China Telecom
– CIENA Corp.
– KDDI Labs
– Cisco Systems
– NTT
– Fujitsu
– Lucent Technologies
Europe
– Mahi Networks
– Deutsche Telekom
– Marconi
– Telecom Italia
– NEC
North America
– Nortel Networks
– AT&T
– Siemens
– Verizon
– Sycamore Networks
– Tellabs
– Turin Networks
73
Opportunities enabled by interoperability
Interoperability of Intelligent Optical Networks
–
End-to-end automatic provisioning across networks
–
Optical VPNs and bandwidth on demand services
–
Bandwidth across network domains (national and global)
–
IP layer dynamically adjusts optical layer provided connectivity
Ethernet over SONET/SDH adaptation using Generic Framing Procedure
(GFP)
–
Interoperable Implementations
–
Bandwidth optimization
•
Map Ethernet efficiently to SONET/SDH payload options (according to usage)
•
Dynamic SONET/SDH bandwidth allocation according to Ethernet usage
74
ITU-T and OIF Collaboration
OIF
ITU-T
• Carrier Requirements
• ASON Recommendations for
Optical Signaling and Routing
• Interoperability Testing
• Transport Recommendations
for GFP, LCAS, VCat, Ethernet
• Protocol Specifications in
UNI Implementation
Agreement
• Adoption of ITU-T Reqs.
G.8080 – control plane
G.805 – bearer plane
Provider A
OIF UNI
Architecture
Provider C
Provider B
OIF E-NNI
OIF E-NNI
Client
OIF UNI
Client
OIF UNI/E-NNI Signaling
based on G.7713, G.7713.2,
G.7713.3
75
OIF ENNI routing based on
G.7715, G.7715.1
Significance of the Event
• Industry’s first time ever worldwide multi-carrier
interoperability testing
– Carriers’ close involvement and strong support are key
to the technology advancing towards industry adoption
• Control plane connectivity built out around the world
lays the foundation for future testing methodology and
infrastructure
• Successful control plane and data plane integration
validates OIF’s Implementation Agreements
• Participation of 15 industry leading vendors and 7
major carriers signifies the wide technology adoption
in industry
76
ISOCORE and GMPLS Testing

Washington DC area (Northern Virginia)

State-of-the art networking lab

Live peering with multiple carriers

What we do:
Interactive technical platform for service providers and vendors

Interoperability test and evaluation

Technology interworking test and evaluation

Standards maturity assessment

Contract testing services

Network design consulting
77
ISOCORE IP-Optical Pavilion Overview
• Demonstrate the state of next generation networking
technologies for IP and Optical networks
– Optical transport to showcase GMPLS-enabled core
– IP multi-service network to showcase MPLS enabled
applications on top of redundant core
• IP-Optical Integration defined
– Integrating multiple-layered networks through a common
control plane
– Enabling automated resource provisioning of transport and
data planes
– Automated setup of circuits in the transport layer using
GMPLS routing thus forming the intelligent optical core
• Allowing the usage of circuits at the IP layer
• Enabling MPLS/IP based multi-services on top of the
dynamically provisioned GMPLS links
78
ISOCORE IP-Optical Pavilion: IP/MPLS
79
ISOCORE IP-Optical Pavillion: Optical/GMPLS
Isocore IP-Optical
Pavilion
Booth 11142
Chiaro
Enstara
Avici
QSR
.1
30.2.58.x
.2
OC-12
.1
30.2.50.x
OC-12
.2
OC-12
OC-48
.2
.1
30.2.27.x
30.2.52.x
NEC-2
.2
.2
.1
OC-48
.2
Ciena- CI
.1
30.2.53.x
35.2.64.x
.1
NEC-1
OC-3
OC-12
.2
OC-12
30.2.42.x
OC-48
34.2.64.x
.1
33.2.62.x
2-OC-48
.1
30.2.38.x
.1
OC-48
Cisco
12406
OC-48
.1
OC-48
.2
.1
OC-48
30.2.37.x
.1
30.2.15.x
30.2.67.x
CP
OC-48
.2
.1
NTT Optical
Sw.
.2
OC-48
.2
.2
.2
SSB
I n t er n et b ac k b o n e r o u te r
OFFL IN E ON LIN E
OFFL IN E ON LIN E
RE0
NC
C
.1
List of Proposed LSPs
a. Cisco-Ciena-Sycamore-Juniper
All TE links are numbered
FSC Switching type
Link Speed: OC-48c
Capable of carrying data
With ERO
b. Cisco-Ciena-NTT_OXC-Juniper
All TE links are unnumbered
FSC Switching type
Link speed OC-48
Capable of carrying data
With ERO
c. NEC2 - Ciena -Fujitsu
All TE links are unnumbered
TDM-Switching Type
Control Plane LSP
Not capable of carrying data
With ERO
d. Cisco-Sycamore-Juniper (LAN PHY)
All TE links are numbered
FSC-Switching
Gigabit Ethernet
Capable of carrying data
With ERO
e. NTT_router-Ciena-Cisco
All TE links are numbered
TDM Switching type
OC-48c : Links speed
Not capable of carrying data
no ERO
f.NTT-Sycamore-Cisco
All TE links unnumbered
FSC Switching type
Gigabit Ethernet
No ERO
g. NEC2-NTT_OXC-Ciena-NEC1
All TE links are numbered
TDM Switching type
OC-48c : Links speed (1310 nm)
Not capable of carrying data
with ERO
31.2.67.x
NTT Router
.2
.1
.1
.2
.2
.2
30.2.5.x
L INK
ACTIVITY
30.2.1.x
2
1
0
MAJOR ALARM
MINOR AL ARM
MGMT
CON S OL E
C
NO
OFFL IN E ON LIN E
.2
.2
.2
30.2.48.x
Gige
30.2.69.x
Gige
OC-48
30.2.10.x
OC-48
CP
OC-48
OC-48
30.2.68.x
.1
.1
.1
.1
.2
.1
.2
30.2.34.x
.1
.1
.2
OC-48
Fujitsu
Flash 4500
Sycamore
SN16000
80
FPC2
NET WORKS
OC-48
30.2.2.x
PICS
3
A UX / MOD EM
30.2.16.x
.2
32.2.65.x
A C OL T
OC-48
.1
FPC0
FPC1
NO
NC
RE1
FPC3
Juniper
M20
Core GMPLS Network
Core GMPLS Network connects with client/user IP Routers
 Successful LSPs being demonstrated at IP-Optical Pavilion
~ Link type: unnumbered link or numbered link
~ Switching Type: TDM or FSC
~ Data Plane Connection or Control Plane Only
~ One-click operation to create connections.
 Applications carried:
~ VPN
~ VPLS
~ Voice/Video Over IP traffic
81
References
Control Plane-Related Standards &
Industry Fora

ITU-T SG13 and SG 15








Q10/13: Requirements for Automatically Switched Transport Networks
(G.807/Y.1301)
Q12/15: Architecture of the Automatically Switched Optical Network
(G.8080/Y.1304)
Q14/15: Distributed Call and Connection Management (DCM)
(G.7713/Y.1704); ASON protocol-neutral signaling requirements
Q14/15: DCM Signaling Protocol based P-NNI
(G.7713.1/ Y.1704.1)
Q14/15: DCM Signaling Protocol based upon GMPLS RSVP-TE
(G.7713.2/ Y.1704.2)
Q14.15: Generalized Automatic Discovery Techniques (G.7714/Y.1705 )
Q14.15: Protocol for Automatic Discovery in SDH and OTN Networks
(G.7714.1/ Y.1705.1)
Q14/15: Architecture and Requirements for Routing in the ASON
(G.7715/Y.1706)
83
Control Plane-Related Standards &
Industry Fora (cont.)

ITU-T SG 13 and SG 15 (cont.)

Q14/15: ASON Routing requirements for Link State Protocols
(G.7715.1/Y.1706.1)
 Q14/15: Framework for ASON Management (draft Rec. G.7718)
 Q14/15: Data Communications Network Architecture and Specification
(G.7712/Y.1703)

Optical Internetworking Forum - OIF







UNI 1.0 Signaling Specification (OIF-UNI-01.0)
UNI 1.0 Signaling Specification, Release 2 (OIF-UNI-01.0-R2: Common
Part)
Intra-Carrier E-NNI Signaling Specification (OIF-E-NNI-Sig-01.0)
Intra-Carrier E-NNI Routing – oif2003.259.02
UNI 2.0 Project - oif2003.351.00 doc and oif2003.293.02 doc
Security management Interfaces to Network Elements (OIF-SMI-01.0)
Call Detail Records for OIF UNI 1.0 Billing (OIF-CDR-01.0)
84
Control Plane-Related Standards &
Industry Fora (cont.)

IETF








Signalling Functional Description (RFC 3471)
Routing/Signalling extensions (RFC3473….)
Link Management (in the queue)
Protection/Restoration (work in progress)
MIBs (somewhere out there)
RFC 3474 codepoint allocation for G.7713.2
RFC 3475 codepoint allocation for G.7713.3
RFC 3476 codepoint allocation for OIF Optical UNI Signaling
85
Additional IETF References
• Current GMPLS internet drafts and RFCs
may be found at
http://www.ietf.org/html.charters/ccampcharter.html
86