ASON/GMPLS Optical Control Plane Tutorial MUPBED Workshop at TNC2007, Copenhagen

1. ASON/GMPLS Optical Control Plane TutorialMUPBED Workshop at TNC2007, Copenhagen Acknowledgement: The author thanks all colleagues from the OIF for their work, which has been the basis for this tutorial The responsibility for the content of this tutorial is with the author Hans-Martin.Foisel, T-Systems / Deutsche Telekom OIF Carrier WG Chair, OIF Vice President www.oiforum.com

2. ASON/GMPLS Tutorial – Outline • Introduction • Requirements & Architecture • Signaling • Routing • Control Plane Management • OIF Interoperability Demonstrations • Control Plane Applications – Use Cases • Concluding remarks

3. Optical Control Plane Goals Management Plane • Offer real multi-vendor and multi-carrier inter-working • Enhance service offering with Ethernet and IP / Optical • Provide end-to-end service activation • Integrated cross-domain provisioning of switched connection services • Provide accurate inventory management TMF-814 E-1 DS-1 Metro Core Long-Haul Core Access Edge E-3 DS-3 ATM Optical Control Plane FR Optical Control Plane 10/100bT IP Optical Control Plane Ethernet OC-3/12/48/192 STM-1o/4/16/64 FC FICON

4. Realizing Optical Control Plane Goals Framework Elements • Robust and scalable transport infrastructure that facilitates carriage of desired services • Management plane that complements control plane in facilitating deployment and management of services • Control plane architecture spanning user and provider networks that supports multiple provider business models and user service requests • Control plane protocols based upon existing and emerging protocols of the data world • Robust Data Communications Network architecture and mechanisms that enable interaction of the protocols running at each node

5. Intelligent Transport Networks introduce ... A distributed “Control Plane” Signaling protocols for dynamic setup and teardown of connections Routing protocols for automatic routing Building on concepts/protocols from the data world

6. Key Concepts Derived from the Data World • Distributed processing/knowledge/storage • Directory services • E.g., DNS, X.500 • Open Distributed Processing • Standardized route determination and topology dissemination protocols • Routing information exchange mechanisms • E.g., RIP, OSPF, BGP, IS-IS/ES-IS • Flexibility in binding time decisions • Difference between provisioning and auto-discovery • Security based upon logical versus physical barriers • E.g., authentication, integrity, encryption • Differentiate between provisioning and more dynamic connection management • Survivability • Distributed restoration using signaling

7. Leveraging Existing Protocol SolutionsCaveats Commercialization of the Internet: • More Business Critical Infrastructure & Availability Requirements • Internet serving community of users with common goals and mutual trust: • Classical Internet architecture Transport business & operational requirements: • Control plane architecture enabling boundaries for policy and information sharing When taking protocol solutions developed for the classical Internet, they bring along associated underlying principles and architectural aspects

8. Optical Control Plane Capabilities Management System Optical Control plane (distributed intelligence) X Bandwidth request or release from clients Network failure Improved bandwidth usage/efficiency Scheduled/unscheduled BoD OSS simplification Autodiscovery Signalling Routing Discovery Control Plane

9. Related Standards Development Organizations RFCs ITU-T IETF Recommendations ASON Architecture & Requirements GMPLS Protocols Interop Results ASON/GMPLS E-NNI, UNI OIF Control Plane Mgmt. Implementation Agreements Use Cases Signalling for EthernetServices TMF Solution Sets Technical Specifications MEF Ethernet Services

10. Rec. Rec. IA IA IA IA IA IA RFC RFC RFC RFC RFC RFC RFC RFC Protocols and Architectures • Control Plane capabilities are implemented in protocols, whose elements can be combined to support different architectures/implementations • Different SDOs contribute various protocol elements and architectural components Control Plane Solutions ITU-T IETF OIF

11. Control Plane Specifications - Example IETF TMF ITU-T Requirements & Architecture TMF509 RFC 3495 G.8080 Auto- Discovery RFC 4204 RFC 4207 G.7714 G.7714.1 ENNI 2.0 ENNI 1.0 G.7713 G.7713.2 Signaling RFC 3474 RFC 3473 UNI 1.0 UNI 2.0 RFC 3946 RFC 4208 G.7715 G.7715.1 RFC 4202 E-NNI OSPF 1.0 OIF Routing G.7715.2 DCN/SCN G.7712 TMF GMPLS MIB RFCs Management G.7718 G.7718.1 TMF814

12. Optical Internetworking Forum (OIF) • Mission: To foster the development and deployment of interoperable products and services for data switching and routing using optical networking technologies • The OIF is the only industry group that brings together professionals from the data and optical worlds • Its 100+ member companies represent the entire industry ecosystem: • Carriers and network users • Component and systems vendors • Testing and software companies

13. OIF Technical Committee Working Groups

14. Optical Control PlaneImplement Agreement Status Draft Straw Ballot Letter Ballot Approved IA http://www.oiforum.com/public/impagreements.html

15. ASON/GMPLS Tutorial – Outline • Introduction • Requirements & Architecture • Signaling • Routing • Control Plane Management • OIF Interoperability Demonstrations • Control Plane Applications – Use Cases • Concluding remarks

16. Business deployment considerations

17. Optical Control Plane Business Deployment Considerations • Optical control plane viability depends upon supporting business as well as technical requirements • Service Provider business models • Commercial and operational practices • Services and network infrastructure heterogeneity • Control and management plane heterogeneity • Network and equipment interoperability • Forms foundation of fundamental optical control plane architecture principles

18. Service Provider Business Models • Internet Service Provider (ISP) • Delivers IP-based services • Owns all of its infrastructure (i.e., including fiber and duct to the customer premises) • Leases some of its fiber or transport capability from a third party • Classical Service Provider • Offers L1/L2/L3 services • Owns its transport network infrastructure • Sells services to customers who may resell to others • Carrier’s Carrier (Service Broker) • Provides optical networking services • May not own transport infrastructure(s) supporting those services (connection carried over third party networks) • Research networks (NRENs, GEANT2, Internet2)

19. Commercial & Operational Practices (1) • Enable protection of commercial business operating practices and resources from external scrutiny or control • An network operator is likely to support a number of user services networks; a trust relationship cannot be assumed between the network and these users (or among the various users) • A network operator will not relinquish control of its resources outside of its administrative boundaries, as “the network” is a prime asset • Support a “pay for service” commercial model • Network operators differentiate their services by defining their own “branded” bundles of functionality, service quality, support, and pricing plans • Provided value added services must be “verifiable” and “billable” in a value preserving way

20. Commercial & Operational Practices (2) • Protect security and reliability of optical transport network • Optical transport network connection persistence must not be affected failures of its control plane, including that of the control communications network • Signaling Communications Network (SCN) • The network must be safeguarded against attacks that may compromise its control plane, or seek unauthorized use of its resources • Control plane security

21. Services Heterogeneity • A wide range of services may be offered; e.g., • Classical data (e.g., best effort Internet, Frame Relay) • Ethernet (e.g., EPL, EVPL, EPLAN, EVPLAN) • L1/L2/L3 Virtual Private Network (VPN) • SONET/SDH switched connection (e.g., STS-n, VC-n) • OTH switched connection (e.g., ODU, OCh) • Many different service deployment scenarios; e.g., • All services interface at the IP level • Various services interface at L1, L2, and L3 • Various options for L1 and L2 topologies and re-configurability in access, metro, and core networks

22. Network Infrastructure Heterogeneity • Extremely diverse network of networks, with widely varying topologies, deployed technologies, services/applications supported • Support operator-specific criteria including cost, performance, and survivability characteristics • Breadth of existing and emerging data plane technologies • Choice of infrastructure granularity options • Flexible capacity adjustment schemes • Range of single- and multi-layer survivability strategies • Differing infrastructure evolution strategies

23. Control & Management Heterogeneity • Control plane-based subnetworks • Management plane-based subnetworks (with various operations support system environments) • Hybrid control plane / management plane scenarios; e.g., • Use of signaling protocols in combination with centralized route calculation • Mix of control plane and management plane based subnetworks E X A M P L E

24. Optical Control Plane Network Operator Deployment Observations • Optimal network layering, convergence choices, equipment selection dependent upon multiple factors • Network size, geography, projected growth • Service offerings portfolio, QoS committed in SLAs • Cost, performance, resiliency trade-offs • Operations support system environment • Whether services traverse multiple operator domains • Differing network operator transport infrastructure, control & management deployments and evolution strategies • Optical control plane architecture must support multi-dimensional heterogeneity

25. Heterogeneity & Research Projects NOBEL

26. Fundamental optical control plane architecture principles

27. Optical Control Plane Fundamental Architecture Principles (1) • Decouple services from service delivery mechanisms • Wide range of network infrastructure options • Network operator specific optimizations • Decouple QoS from realization mechanisms • Wide range of survivability options • Network operator specific approaches Introduce “call” construct, which reflects a service association that is distinct from infrastructure/realization mechanisms

28. Optical Control Plane Fundamental Architecture Principles (2) • Provide boundaries of policy and information sharing • Range of network operator business models • Varying trust relationships among users and providers, among users, among providers • Targeted solutions, scalability considerations (scope of information dissemination), etc. Establish modular architecture with interfaces at policy decision points

29. Optical Control Plane Fundamental Architecture Principles (3) • Provide for various distributions of control functionality among physical platforms • Different distributions of routing and signaling control • Fully centralized to fully distributed system designs • Decouple topology of the controlled network from that of the network supporting control plane communications (SCN) • The transmission medium may be different for control plane messages and transport plane data Identifiers to distinguish transport resources from, and among, signaling and routing control entities, and SCN addresses

30. ASON architecture and standards status

31. Optical Control PlaneITU-T ASON Recommendation Framework Rec. G.8080 Automatically Switched Optical Network (ASON) DCN/SCN Signaling Routing Mgmt. FW Autodisc G.7712 G.7713 G.7714 G.7715 initialization G.7716 G.7718 Protocol Neutral Recs. Info Model G.7718.1 Remote Path Query Link State G.7715.1 G.7715.2 G.7713.1 (PNNI-based) G.7714.1 (Discovery SDH/OTN) G.7713.2 (GMPLS-RSVP-TE) Protocol Specific Recs. G.7713.3 (GMPLS-CR-LDP)

32. Optical Control PlaneITU-T ASON Architecture • ITU-T G.8080/Y.1304, Architecture of the Automatically Switched Optical Network • First version Approved Nov.’01, several subsequent Amendments, first major revision Approved June 2006 • Subsumes and deprecates ITU-T Rec. G.807, Requirements for Automatically Switched Transport Networks, Approved July ’01 • Architecture considers business and operational aspects of real-world deployments • Call and connection separation, connection persistence, customer/network address space isolation, domain constructs, reference points and interfaces • Leverages transport layer network constructs utilized in all transport network architecture and equipment Recommendations • Applicable to all connection-oriented transport networks (whether circuit or packet)

33. ITU-T ASON ArchitectureCalls and Connections • Objective: Support ability to offer enhanced/new types of transport services facilitated by: • Automatic provisioning of transport network connections • Span one or more managerial/administrative domains • Involves both a Service and Connection perspective • Call : Support the provisioning of end-to-end services while preserving the independent nature of the various businesses involved • Connection : Automatically provision network connections (in support of a service) that span one or more managerial/administrative domains

34. ITU-T ASON ArchitectureDomains • ASON domains represent generalization of existing traditional concepts • Transport definitions of administrative/management domains • Internet administrative regions • Domains may express differing: • Administrative and/or managerial responsibilities • Trust relationships, addressing schemes • Distributions of control functionality • Infrastructure capabilities, survivability techniques, etc. • Domains are established by network operator policies

35. Service demarcation points are where call control is provided Inter-domain interfaces are service demarcation points ITU-T ASON ArchitectureInterfaces (1) • Design modularized around open interfaces at domain boundaries • UNI, E-NNI, I-NNI

36. ITU-T ASON ArchitectureInterfaces (2) UNI UNI E-NNI NE Provider A Provider B NE NE NE • UNI separates the concerns of the user and provider: • “3.6 Modularity is good. If you can keep things separate, do so.” - RFC 1548 • Objects referenced are User objects, and are named in User terms • UNI enables: • Client driven end-to-end service activation • Multi-vendor inter-working • Multi-client • IP, Ethernet, TDM, etc. • Multi-service • SONET/SDH, Ethernet, etc. • Service monitoring interface for SLA management

37. UNI UNI-C UNI-N UNI UNI-N UNI-C ITU-T ASON ArchitectureInterfaces (3) E-NNI NE Provider A Provider B NE NE NE • E-NNI enables: • End-to-end service activation • Multi-vendor inter-working • Multi-carrier inter-working • Independence of survivability schemes for each domain • I-NNI supports: • Intra-domain connection establishment • Explicit connection operations on individual switches

38. ITU-T ASON ArchitectureCall Control & Interfaces • Call state is maintained at network access points, and at key network transit points where it is necessary or desirable to apply policy • Calls that span multiple domains are comprised of call segments, with call control provided at service demarcation points (UNI/E-NNI) • One or more connections are established in support of individual call segments, with scope of connection control typically limited to a single call segment UNI Domain A Domain B UNI E-NNI NE NE NE NE CALL UNI Call Segment E-NNI Call Segment UNI Call Segment Domain A Call Segment Domain B Call Segment CONNECTIONS

39. Components of Control Plane enabled Network Domains Management plane CP MANAGEMENT DCN CONTROL PLANE Data plane

40. Optical Control Plane ServicePermanent Connection • All intra-/inter-domain calls and connections are provisioned by Management Plane actions C1 TN1 TN2 C2 Provisioned Provisioned Provisioned Permanent connection C: Client network domain TN:Transport Network provider domain

41. Optical Control Plane ServiceSoft Permanent Connection • Management plane of a transport network provider domain is initiating a call/connection SPC initiating domain C1 TN1 TN2 C2 E-NNI Permanent connection Switched connection Permanent connection Soft Permanent Connection (SPC) C: Client network domain TN:Transport network provider domain

42. Optical Control Plane ServiceSwitched Connection • Management plane of a client domain is initiating a call/connection SC initiating domain C1 TN1 TN2 C2 UNI E-NNI UNI Switched connection C: Client network domain TN:Transport Network provider domain

43. G.805 Transport Foundation

44. G.805 Foundation Elements – Transport Resources • Introduction of automated control doesn’t remove/change the attributes of transport resources • Control Plane needs to be able to configure the same attributes • Introduction of automated control doesn’t modify the functional components that exist within the transport plane

45. Transport Network/Equipment ArchitectureInformal Specification Approaches • Described in terms of network elements, facilities, and cross-connections • Facilities identified in terms of the physical layer characteristics • Cross-connections between constituents of facilities or “embedded facilities” DS1 Service example DS1 SONET SONET SONET DS3 DS1 X X X X X 3:3 DCS 3:1 DCS Regen 3:1 DCS 3:3 DCS

46. Transport Network/Equipment ArchitectureInformal Specification Approaches • Issues • Model specific to the technologies used in the NEs • Difficult to understand network topology without understanding details of the NEs • Subject to differing interpretations of equipment specifications/behaviors arising from natural language description • Usage of different terminology; e.g., in doing a functional decomposition, different specifiers may group functionality in different ways but use the same term to denote the functional block • Development of more formalized specification techniques initiated during 1988 time frame

47. Transport Network ConstructsFormal Specification Techniques • Recognize new challenges of emergent multi-carrier, multi-vendor telecommunications environment • Increasingly complex networks and behaviors, arising from deployment of multi-technology networks & equipment • No single network architecture, or single set of network elements, that suited all operators • Better support for multi-carrier/multi-vendor interoperability • Unambiguous specifications that don’t impose unnecessary architectural constraints • Network operator transport infrastructure technology deployment choices and evolution strategies • Network equipment provider innovation re equipment types

48. Transport Network ConstructsFormal Specification Techniques - G.805 • Describes the generic characteristics of networks using a common language • Transcends technology and physical architecture choices • Provides a view of functions or entities that may be distributed among a number of equipments • Defines elements that support the modeling of topological and functional concepts • Topology refers to how elements of the network are interconnected • Functions refer to how signals are transformed during their passage through the network • Defines small number of architectural components that may be interconnected to represent various network/equipment configurations

49. Transport Network ConstructsTopological – G.805 Layers • A layer is defined in terms of its set of signal properties - characteristic information • Networks can be represented in terms of a stack of client/server relationships • Helps manage the complexity created by the presence of different types of characteristic information in networks • Allows the management of each layer to be similar Divide and conquer

50. Transport Network ConstructsTopological – G.805 Example Vertical DS3 client carried over STM-N Signal