Optical Control Plane Initiatives GMPLS G ASON and

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: SS 7 – a physically separate control network overlay for telephony network control 4

Routing and Discovery • ATM 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 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 • L 2 SC - 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 D 1, D 2 and D 3 (total 192 kbps) – Line (MS) DCC is bytes D 4 -D 12 (total 576 kbps) 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 T 1. 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 Class-Num C-type LSP Enc. type Switching Type G-PID 8 bits, Encoding Types = packet, Ethernet, PDH, SONET/SDH, DW, , Fiber, Fibre. Channel 8 bits, Types = switching capabilities from routing (PSC, L 2 SC, 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/T 1, , 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) • Flag field Multiplier (multiple connections) Transparency Profile (for further study) 26

SONET/SDH Label Definition 16 4 4 S U K L M U S U 27

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 • IPv 4/v 6 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 PSC Domain Forwarding Plane Router SONET SDH NE TSC Domain OXC Switch LSC Domain SONET SDH NE Switch OXC Fiber Domain Switch OXC OTN GMPLS Domain LSP Packet FA-PCS LSP FA-TDM LSP Lambda TDM FA-LSC LSP Fiber 34 Switch SONET SDH NE Router OXC TE LSP Nested LSPs SONET SDH NE 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 Lo. S/Lo. L/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 (A 1, P 1) P 1 T T R R A 1 P 2 Hello Ack (A 2, P 2, A 1, P 1) A 2 44 Hello (A 2, P 2) Hello Ack (A 1, P 1, A 2, P 2)

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!) Begin. Verify (#, interval, data rate, etc. ) Begin. Verify. Ack (Verify. ID) P 1 Test Messages (P 1, VID) P 2 P 11 P 3 A 1 P 10 P 12 Test. Status. Success (P 1, P 10, VID) A 2 45 Test. Status. Ack (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 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 51

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 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 The Service (call*) perspective is to support the provisioning of end-to-end services while preserving the independent nature of the various businesses involved. – I-NNI: connection point supporting intra-domain connection establishment The Connection perspective is to automatically provision “path layer” connections (in support of a service) that span one or more managerial/administrative domains. 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

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 I-NNI B A Core UNI E-NNI Core I-NNI A 54 Domain Model UNI B

ITU-T ASTN/ASON Architecture Reference Framework (cont. ) UNI Domain 1 E-NNI Domain 2 User 1 E-NNI Domain 3 UNI Connections User 2 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 • 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 state, which is distinct from connection state throughout the network – There is independence of survivability (protection/restoration) for each domain – There is a trust boundary 55

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) – IPv 4, IPv 6 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 58

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 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 Auto. Discovery – 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 oif 2001. 615, Draft specs. oif 2003. 293 and oif 2003. 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 (oif 2003. 364. 00) – Control Plane Logging and Auditing with Syslog IA under development (oif 2003. 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 (Super. Comm 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 (Super. Comm 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 (1 Gb/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 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 80

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 h ITU-T SG 13 and SG 15 ü ü ü ü Q 10/13: Requirements for Automatically Switched Transport Networks (G. 807/Y. 1301) Q 12/15: Architecture of the Automatically Switched Optical Network (G. 8080/Y. 1304) Q 14/15: Distributed Call and Connection Management (DCM) (G. 7713/Y. 1704); ASON protocol-neutral signaling requirements Q 14/15: DCM Signaling Protocol based P-NNI (G. 7713. 1/ Y. 1704. 1) Q 14/15: DCM Signaling Protocol based upon GMPLS RSVP-TE (G. 7713. 2/ Y. 1704. 2) Q 14. 15: Generalized Automatic Discovery Techniques (G. 7714/Y. 1705 ) Q 14. 15: Protocol for Automatic Discovery in SDH and OTN Networks (G. 7714. 1/ Y. 1705. 1) Q 14/15: Architecture and Requirements for Routing in the ASON (G. 7715/Y. 1706) 83

Control Plane-Related Standards & Industry Fora (cont. ) h ITU-T SG 13 and SG 15 (cont. ) Q 14/15: ASON Routing requirements for Link State Protocols (G. 7715. 1/Y. 1706. 1) ü Q 14/15: Framework for ASON Management (draft Rec. G. 7718) ü Q 14/15: Data Communications Network Architecture and Specification (G. 7712/Y. 1703) ü h Optical Internetworking Forum - OIF ü ü ü ü UNI 1. 0 Signaling Specification (OIF-UNI-01. 0) UNI 1. 0 Signaling Specification, Release 2 (OIF-UNI-01. 0 -R 2: Common Part) Intra-Carrier E-NNI Signaling Specification (OIF-E-NNI-Sig-01. 0) Intra-Carrier E-NNI Routing – oif 2003. 259. 02 UNI 2. 0 Project - oif 2003. 351. 00 doc and oif 2003. 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. ) h IETF ü ü ü ü Signalling Functional Description (RFC 3471) Routing/Signalling extensions (RFC 3473…. ) 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