Optical Core Networks ASON, ASTN and GMPLS basics

1. Optical Core NetworksASON, ASTN and GMPLS basics Piero Castoldi, Scuola Superiore Sant’Anna, castoldi@sssup.it

2. Outline • ASON/ASTN architecture • Data plane • Control plane • Management plane • GMPLS – Introduction • GMPLS Protocol suite • Routing protocol • Signaling protocol • Link Management protocol

3. ASON/ASTN Data Plane Management Plane Control Plane

4. ASON/ASTN architecture • It comprises Data Plane, Management Plane and Control Plane NMI-A = Network Management Interface (ASON) NMI-T = Network Management Interface (Transport) UNI-C = User to Network Interface (Control) UNI-T =User to Network Interface (Transport)) Management Plane (MP) NMS = Network Management System EMS = Element Management System CLIENT = Client network OXC = Optical Cross Connect NMS Corba/Q3 EMS NMI-T(TL-1, SNMP, Q3) Control plane (CP) UNI-C UNI-C CCI UNI-T OXC CLIENT OXC CLIENT UNI-T OXC Data plane (DP) OXC

5. Data plane - Basics • Pure transport of data • In electrical networks it is strictly coupled with the control plane (e.g. router) • Nodes: “network elements” that may terminate lightpaths or cannot “read” data flowing (e.g. OXC in transparent networks) • Links: bundle of fibers (typically) that may support WDM transmission • ASON data plane is a special case of ASTN data plane (ASTN may include electrical transmission at the “data plane” level) • Reference: • ITU-T Rec. G.8080/Y.1304, Architecture for Automatically switched optical network (ASON), November 2001. • ITU-T Rec. G.807/Y.1302, Requirements for automatic switched transport networks (ASTN), July 2001.

6. Data planeNetwork Structure and Terminology C3 C9 Node or Network Element (NE) C2 C4 C10 C1 C8 End system A C6 C7 B3 B2 Subnetwork A B4 B1 End system Z B8 B6 Link B7 Network Subnetwork B

7. Data planeConnection Structure and Terminology C3 C9 Link Connection C2 C4 Subnetwork connection C10 C1 C8 End system A C6 C7 B3 B2 Subnetwork connection B4 B1 End system Z B8 B6 B7 Network connection

8. Control plane and management planeMotivation • The purpose of the management and control plane for optical networks is to provide for the efficient delivery of highly available, highly reliable communication services. • These services consist of a variety of different types of connections between end users of the optical network.

9. Network Management definition • Network management is a service that employs a variety of tools, applications, and devices to assist human network managers in the control and maintenance of a network. • Network management includes the deployment, integration and coordination of the hardware, software and human elements to monitor, test, poll, configure, analyze, evaluate the network resources to meet the real-time, operational performance and QoS requirements at a reasonable cost. • The combination of hardware and software used to monitor and administer a network is called Network Management System (NMS)

10. Layered Network Management NMS Core EMS O3 O9 EMS 1 EMS 2 O2 O4 O10 O1 O8 O6 M5 O7 M4 M1 M2 Core Network M6 M3 Metro SubNetwork 2 Metro SubNetwork 1

11. How do we manage all this? Divide and Conquer! • Multiple layers of management • Management functionality in each network element and support on each communications link • Element management system (EMS): Manages a subnetwork of the network elements (e.g., OLTs, OADMs, OXCs, etc) • EMSs have communication interfaces (and software agents) to communicate with. • EMSs in a network are interconnected with a data communication network (e.g., the OSC can be used for that). • Network management system (NMS): talks to the EMSs to get the overall view of the network.

12. OTN’s Embedded Management Functionality

13. Management plane - Information model • EMSs operate on information models (IM). • IMs are usually implemented in an object oriented language, since they have an object-oriented representation themselves. • Inheritance plays an important role. • Connection trails are IMs for example that can represent lightpaths.

14. Management plane - Management protocols (1) • Most management systems are master-slave based with “get” and “set” operations over IMs. • Additionally, messages can be slave initiated (exception reports, or alarms, traps) • The most well-known IP based management protocol is SNMP. The IM in SNMP is called MIB (management information base) • Yet most carriers still rely on TL-1 (Transaction Language-1). TL-1 is a simple ASCII command language.

15. Management plane - Management protocols (2) • The most common management framework is: TMN (Telecommunications Management Network). • TMN’s hierarchical management protocol is called: CMIP (Common Management Information Protocol). CMIP runs over OSI but has also been defined for TCP/IP. • In order to be able to manage a network with equipment from various vendors, a common interface is needed. CORBA (common object request broker) can be used to enable communication of software agents.

16. ASON/ASTN Control Plane

17. Need for the control planeA few unanswered questions… • Inventory and resource management • Neighbor discovery: How do I know who is on the other end of a link? • Global topology dissemination, i.e. how do I know what equipment is in my network? (Links and switching nodes) • Dynamic provisioning • Connection request, path calculation, connection establishment: how do I control (set up and tear down) lots of connections efficiently? Previously manually configured!

18. Control Plane • It is a parallel network devoted to the transport of routing and signalling messages (e.g. adjacencies information exchange) • Each data plane element has a control plane controller Functional tasks: • Automatic Neighbor Discovery • Allows a node to determine the identity of each neighboring node and the set of links that connect them. • Topology and resource status dissemination • Allows every node to automatically discover the complete network topology and resources • Signaling for Connection Provisioning • Allows the establishment and teardown of a path from one end of the connection

19. Management and control • Management systems have significant functionality not addressed in the control plane • For example performance monitoring • New control plane functionality supplements but does not replace important management functions. • Management systems can make use of discovered neighbor and topology information • Parts of connection processing can be off loaded to the control system.

20. Networks used by MP and CP • So-called “Data Communication Network” (DCN) • A means for the nodes to communicate for executing control and management protocols • Maybe a completely separate communications network, or use in-band dedicated channels, or a combination of the two… • Administrative Framework • Uniform addressing scheme for controlled entities • Policy enforcement pertaining to provisioning and restoration

21. Control Plane technology standardsStandard Bodies and Organizations • Charter: Global Telecom Architecture and • Standards • Member Organizations: • Global Service Providers • PTTs, ILECs, IXCs • Telecom equipment vendors • Governments • Charter: Evolution of the • Internet (IP) Architecture • Active Participants: • ISPs • Service Provider IP Divisions • IP/Ethernet Vendors • Charter: Development of Optical • Networking Products and Services • Member Organizations: • PTTs, ISPs, ILECs, IXCs • Optical Networking Vendors • Charter: Network Management • Over 350 members including • Service providers • Equipment vendors • Software vendors

22. ITU-T, International Telecommunications Union – Telecommunications Sector • Defines architectures and models • Architecture, Requirements, Models • G.807: Requirements for ASTN • G.8080: ASON Architecture • G.7712: Data Communication Network Arch. • Discovery • G.7714: General process and model • G.7714.1: Discovery for SONET/SDH and Optical Transport Network (OTN) • Signaling: • G.7713: Distributed Connection Management model • G.7713.1, G.7713.2, G.7713.3 Signaling protocols • Routing • G.7715: Routing architecture and requirements • G.7715.1: Link state routing requirements

23. IETF, Internet Engineering Task Force • Extends MPLS/IP protocols based on generalized interface requirements • Architecture • GMPLS Architecture (draft) • Generalized Multi-Protocol Label Switching Architectural Extensions • Link Management • Link Management Protocol (draft) • Signaling • RFC 3471: GMPLS Signaling Functional Spec. • RFC 3473: GMPLS-RSVP-TE • RFC 3472: GMPLS-CR-LDP • Routing • GMPLS extensions for OSPF-TE (draft)

24. OIF, Optical Internetworking Forum • Focuses on application of IETF protocols in an overlay model • Generates implementation agreements • Signaling/Interface Standards • UNI version 1.0 release 2 • External intra-carrier NNI 1.0 (signaling) • Security specifications for the above. • In progress routing • Interoperability Events! • Physical Layer Standards • A very successful set of inter-chip specifications (not in our scope here).

25. TMF, Telemanagement Forum • An number of activities beyond our scope… • MTNM (Multi Technology Network Management) • Business Agreement - TMF513 (requirements) • Information Agreement - TMF608 (technology independent info models for management purpose) • Solution Sets - TMF814 (CORBA), XML to come • Currently working on management of control plane

26. GMPLS Generalized Multiprotocol Label Switching Introduction

27. MPLS Network Label Switching Routers Edge Label Switching Routers

28. GMPLS Rationale • Need somecontrol plane for OXCs • Similarities between optical channels and traffic engineered LSPs suggest to use MPLS principles for OXCs • MPLS control plane is standard and IP-centric and the label switching concept is very powerful • Support traffic engineering functions • Idea of MPLS can be extended to more than just streams of packets. • Therefore, a concept has been developed called “Generalized MPLS” • Interoperability among diverse devices (routers, switches, ADMs, OXCs etc.) • Provide standards based, multi-vendor interoperability within an optical transport network

29. LSR/OXC and LSP/lambda commonalities • LSR/OXC: • Data plane driven by a switching table • LSR: (input interface, ingress label)  (output interface, egress label) • OXC: (input interface, ingress )  (output interface, egress ) • Switching independent of switching unit payload • LSR & OXC switch based on Label or Lambda • do label swapping in MPLS, while do not need to recognise packet boundaries or process packet headers in the case of OXC • LSP/lambda: • unidirectional and point-to-point • Same label/lambda cannot be allocated twice on an interface

30. From MPLS to GMPLS Use case example • Each switching element (OXC) is the equivalent of a LSR • Lightpaths are considered the equivalent of LSPs • Wavelengths and switch ports are considered equivalent to labels and router ports • Optical circuit provisioning similar to MPLS traffic engineering via Explicit routing

31. GMPLS Network Lambda Switching Router Lambda Switching Router OLSR Lambda Switching Edge Router Lambda Switching Edge Router Lambda Switching Router Lambda Switching Router Lambda Switching Router Lambda Switching Edge Router MPL(ambda)S Domain Fiber with WDM

32. Optical Label Switch Router (OLSR) IP Routing and Signaling IP Routing and Signaling OCP OXC DWDM DWDM • tightly-coupled OCP and OXC creates an Optical Label Switch Router • runs IP and MPLS protocols - MPLaS, GMPLS • switches at Fiber and Lambda Level

33. Three classes of OXCs F-OXC Fiber-to-fiber Wavelength routing WR-OXC Wavelength translating WT-OXC

34. MPLS has been extended to include other LSR types whose forwarding decisions are not based on packets rather are times slots, wavelengths or physical port numbers. Hence the notion of LSP has been generalized to: FSC (fiber switch capable) LSP, LSC (Lambda Switch Capable) LSP, TDM LSP. LSP must start and end on LSR of the same type New forms of labels are required (also called generalized label) characterized by (see also next slide): link protection type, LSP encoding, LSP payload. GMPLS: General features

35. G-MPLS Label Request • Exampleshown is carried in RSVP PATH message • Link Prot. (Protection) Type • desired protection scheme of link • e.g. 1+1, 1:N, ring, etc. • LSP Encoding Type • encoding of LSP • e.g. GE, Lambda, SONET, etc.

36. G-MPLS Label • Example shown is carried in RSVP RESV message • Link ID • identifies which component link (out of several possible) that label will be allocated on • Label • different formats for fiber, waveband, lambda, TDM and packet

37. Some G-MPLS Label Formats SDH Wavelength Waveband

38. Interfaces in a GMPLS LSR (1) • Packet switch capable (PSC) interfaces • They recognize IP packets, ATM cells, Frame Relay frames, Ethernet frames, MPLS frames and can do the forwarding based on the content of the packet/cell header • Time division multiplex capable (TDM) interfaces • They forward data based on the data’s time slot that repeats in a frame. This interface is used in SONET/SDH cross connects

39. Interfaces in a GMPLS LSR (2) • Lambda (wavelength) switch capable (LSC) interfaces • They forward data from an incoming wavelength to an outgoing wavelength. This interface is used in OXCs. • Fiber switch capable (FSC) interfaces • They forward data from one or more incoming fibers to one (or more) outgoing fibers. They are used in an OXC that can operate at the level of one or more fibers.

40. GMPLS Issues & Resolutions(1) • Data forwarding is now not limited to that of merely packet forwarding. • The general solution must be able to retain the simplicity of forwarding using a label for a variety of devices that switch in time or wavelength, or space (physical ports). => Generalized Label

41. GMPLS Issues & Resolutions(2) • Not every type of network is capable of looking into the contents of the received data and of extracting a label. • For instance, packet networks are able to parse the headers of the packets, check the label, and carry out decisions for the output interface (forwarding path) that they have to use. • This is not the case for TDM or optical networks. The equipments in these types of networks are not designed to have the ability to examine the content of the data that is fed into them. => Allows the data plane & control plane to be physically or logically separated.

42. GMPLS Issues & Resolutions(3) • Unlike packet networks, in TDM, LSC, and FSC interfaces, bandwidth allocation for an LSP can be performed only in discrete units. • For example, a packet-based network may have flows of 1 Mbps to 10 or 100 Mbps. • However, an optical network will use links that have fixed bandwidths: optical carrier (OC)-3, OC-12, OC-48, etc. When a 10 Mbps LSP is initiated by a PSC device and must be carried by optical connections with fixed bandwidths-e.g., an OC-12 line-it would not make sense to allocate an entire 622M line for a 10M flow. => Hierarchical LSPs

43. GMPLS Issues & Resolutions(4) • Scalability is an important issue in designing large networks to accommodate changes in the network quickly and gracefully. • The resources that must be managed in a TDM or optical network are expected to be much larger in scope than in a packet-based network. • For optical networks, it is expected that hundreds to thousands of wavelengths (lambdas) will be transporting user data on hundreds of fibers. => Forwarding Adjacency - LSP (FA), i.e. a TE link between two GMPLS nodes whose path transits zero or more (G)MPLS nodes.

44. GMPLS Issues & Resolutions(5) • Configuring the switching fabric in electronic or optical switches may be a time-consuming process. • Latency in setting up an LSP within these types of networks could have a cumulative delaying effect in setting up an end-to-end flow. => Suggested Label & Bidirectional LSP

45. GMPLS Issues & Resolutions(6) • SONET/SDH networks have the inherent ability to perform a fast switchover from a failed path to a working one (50 milliseconds). • GMPLS' control plane must be able to accommodate this and other levels of protection granularity. • It also needs to provide restoration of failed paths via static (pre-allocated) or dynamic reroute, depending on the required class of service (CoS). => Reliability - Fault Management

46. GMPLS Control plane

47. GMPLS Protocol Suite

48. GMPLS Protocol Suite • Consists of a family of three different kinds of protocols: • Routing protocol with traffic engineering extensions • Signaling protocol with traffic engineering extensions • Link Management protocol

49. GMPLS Protocol Suite Routing protocol • uses link-state routing protocol between switches to report on link status, characteristics & constraints • note, below the IP layer • can do path determination with routing protocol or using explicit routing • can use OSPF or IS-IS with TE extensions. Most vendors use OSPF-TE • Routing protocols for the auto-discovery of network topology, advertise resource availability (e.g., bandwidth or protection type). The major enhancements are: • Advertising link-protection type • Implementing derived links (forwarding adjacency) for improved scalability • Route discovery for back-up path

50. GMPLS Protocol SuiteSignaling protocol (1) • Extended the signaling (RSVP-TE, CR-LDP) to accommodate the characteristics of TDM/SONET & WDM optical networks. • most vendors use RSVP-TE • Signaling protocols for the establishment of traffic-engineered generalized LSPs. The major enhancements are as follows: • Label exchange to include non-packet networks (generalized labels) • Signaling for the establishment of a back-up path (protection Information) • Expediting label assignment via suggested label • Waveband switching support - set of contiguous wavelengths switched together