2. June 4, 2003Carleton University & EIONGMPLS - 1 GMPLS Generalized Multiprotocol Label Switching Vijay Mahendran Sumita Ponnuchamy Christy Gnanapragasam

3. June 4, 2003Carleton University & EIONGMPLS - 2 Outline Background –Terminology –MPLS GMPLS Signaling

4. June 4, 2003Carleton University & EIONGMPLS - 3 Terminology MPLS – Multi-Protocol Label Switching GMPLS – Generalized MPLS LSR – Label Switched Router LER – Label Edge Router LSP – Label Switched Path RSVP-TE – Resource Reservation Protocol with Engineering CR-LDP – Constraint Based Label Distribution OSPF – Open Shortest Path First IS-IS – Intermediate System to Intermediate UNI – User-Network Interface NNI – Network-Network Interface DWDM – Dense Wavelength Division Multiplexing OXC – Optical Cross-Connect LMP – Link Management Protocol

5. June 4, 2003Carleton University & EIONGMPLS - 4 ? Optical Network Architectures Overlay model –Two independent control planes Optical domain & IP/MPLS routing –Router is client of optical domain –Optical topology invisible to routers Peer model –Single integrated control plane –Router and optical switches are peers –Optical topology is visible to routers Hybrid model –Multi admin domain support (overlay) –Multiple technologies within domain (peer) UNI Peer

6. June 4, 2003Carleton University & EIONGMPLS - 5 MPLS Speed of Layer 2 switching in Layer 3 AIM : Establish the Forwarding Table –Link state routing protocols Exchange network topology information for path selection OSPF-TE, IS-IS-TE –Signaling/Label distribution protocols: Set up LSP (Label Switched Path) LDP, RSVP-TE, CR-LDP Control: IP Router Software Control: IP Router Software Forwarding: Longest-match Lookup Control: ATM Forum Software Forwarding: Label Swapping IP Router MPLS ATM Switch Forwarding: Label Swapping

7. June 4, 2003Carleton University & EIONGMPLS - 6 1a. Routing protocols (e.g. OSPF-TE, IS-IS-TE) exchange reachability to destination networks 1b. Label Distribution Protocol (LDP) establishes label mappings to destination network 2. Ingress LER receives packet and “label”s packets IP 10 3. LSR forwards packets using label swapping IP 20 IP 40 4. LER at egress removes label and delivers packet IP MPLS Operation

8. June 4, 2003Carleton University & EIONGMPLS - 7 GMPLS Extend MPLS to cover the Optical Domain –Packet Switch Capable (PSC) –Layer 2 Switch Capable (L2SC) –Time Division Multiplexing Capable (TDMC) –Lambda Switch Capable (LSC) –Fiber Switch Capable (FSC) A common control plane –Support multiple types of traffic (ATM, IP, SONET and etc.) –Support both peer and overlay models –Support multi-vendors –Perform fast provisioning

9. June 4, 2003Carleton University & EIONGMPLS - 8 GMPLS is deployed from MPLS –Apply MPLS control plane techniques to optical switches and IP routing algorithms to manage light paths in an optical network GMPLS made some modifications on MPLS –Separation of Control and Data planes –Support multiple interface –Enable nesting of different interfaces FSC LSC TDMC PSC

10. June 4, 2003Carleton University & EIONGMPLS - 9 Key Extension To MPLS Label encoded as timeslots, wavelengths, position in real world LSP start & end on similar interfaces Suggested Labels by upstream node Label restrictions Bi-directional LSPs Support rapid failure notification BW allocation in discrete time Extended payload encoding

11. June 4, 2003Carleton University & EIONGMPLS - 10 GMPLS Control Plane Extension of MPLS control plane – GMPLS extends OSPF-TE and IS-IS-TE for routing – GMPLS extends RSVP-TE and CR-LDP for signaling – Control Channels in-band or out-of-band – LMP- Link Management Protocol Extension to MPLS-TE

12. June 4, 2003Carleton University & EIONGMPLS - 11 GMPLS Scalability Unnumbered Links –No IP –Specify unnumbered links: local ID Exchange local ID (signaling protocol) –Carry TE info about unnumbered links new sub-TLVs

13. June 4, 2003Carleton University & EIONGMPLS - 12 Bundled Link 1 Bundled Link 2 Multiple parallel links between nodes can be advertised as a single link into the IGP –Enhances IGP and traffic engineering scalability Component links must have the same –Link type –Traffic engineering metric –Set of resource classes –Link multiplex capability (packet, TDM, λ, port) (Max bandwidth request)  (bandwidth of a component link) Link granularity can be as small as a λ Link Bundling

14. June 4, 2003Carleton University & EIONGMPLS - 13 Link Management Procedures between LSRs: –Management –Verification –Property Correlation –Fault Management

15. June 4, 2003Carleton University & EIONGMPLS - 14 Generalized Signaling GMPLS Signaling –CR-LDP and RSVP-TE Extends based functions Add functionalities Impacts: –label requests and communications –Unidirectional LSPs –Error propagation –Ingress/Egress Synchronization

16. June 4, 2003Carleton University & EIONGMPLS - 15 CR-LDP Vs. LDP Explicit Route TLV Traffic Parameters TLV –Peak data rate, peak burst size, committed data rate, committed burst size, excess burst size, frequency, weight Preemption TLV (with Setup and Holding priorities) LSPID TLV (used for “make-before-break” modification) Route Pinning TLV (allow or prevent route optimization) Resource Class TLV (take or avoid links with certain attributes)

17. June 4, 2003Carleton University & EIONGMPLS - 16 Classical RSVP Designed in early 90’s Makes QoS reservations between hosts –for example, between a server and a workstation Has no concept of labels and LSPs –packets assumed to travel unlabelled No explicit route concept; reservations made along shortest path

18. June 4, 2003Carleton University & EIONGMPLS - 17 RSVP-TE Vs. RSVP Concept of labels and LSPs Explicit routes LSP attributes (including Setup and Holding priorities) “make-before-break” modification Record route record the route of an LSP set up with loose hops

19. June 4, 2003Carleton University & EIONGMPLS - 18 GMPLS Features New generic label request format Labels for TDM/LSC/FSC interfaces Specific traffic parameters per technology Bi-directional LSP establishments Explicit routing with explicit Label Control

20. June 4, 2003Carleton University & EIONGMPLS - 19 LSP Request Send PATH/Label Request downstream –Type of LSP –Payload type –BW encoding SENDER_TSPEC: RSVP-TE Traffic Parameter TLV: CR-LDP –Protection –Bi-directional LSP support Specify upstream label –Suggested labels

21. June 4, 2003Carleton University & EIONGMPLS - 20 Response for LSP Request Resv/Label Mapping message sent by the downstream LSR –Generalized Label object Several Generalized Labels –List of labels: SONET/SDH

22. June 4, 2003Carleton University & EIONGMPLS - 21 GMPLS - Signaling Suggested Label –Label suggestion from upstream node –Reduction in setup latency –Important for restoration Bi-directional LSP –There have been numerous requests for bidirectional LSPs especially in support of TDM and Lambda switching. –Both directions have same traffic engineering requirements Notification –Notify message has been added to RSVP-TE for GMPLS messages –This message can be targeted in the case of a degraded link

23. June 4, 2003Carleton University & EIONGMPLS - 22 GMPLS Signaling: RSVP and CR-LDP Nested LSPs allows the system to scale by building a forward hierarchy. At the top of this hierarchy are FSC interfaces, followed by LSC-, TDM-, and PSC interfaces. –The MPLS label property of being hierarchical is no longer valid! Generalized Label Request includes –the encoding of label requested, and –the type of switching required. Generalized Label: In addition to representing a packet, a label can represent a number of time slots, a wavelength or a set of contiguous wavelengths (waveband).

24. June 4, 2003Carleton University & EIONGMPLS - 23 GMPLS - Signaling

25. June 4, 2003Carleton University & EIONGMPLS - 24 GMPLS - Signaling

26. June 4, 2003Carleton University & EIONGMPLS - 25 GMPLS Signaling: RSVP and CR-LDP Suggested label: the upstream node suggests the label to the downstream node and at the same time can start configuring its hardware so that the set-up latency gets reduced. Label set: to provide upstream node with control over chosen labels. Used to limit the choice of labels to the downstream node. Support bi-directional paths Support label explicit route Protection: Includes protection information in a new object, specifying the LSP is the primary or secondary one, and the desired protection type.

27. June 4, 2003Carleton University & EIONGMPLS - 26 RSVP-TE Vs. CR-LDP RSVP-TE uses raw IP, while CR-LDP uses TCP to distribute labels and UDP to discover neighbors. RSVP-TE is a soft state protocol, needing periodically refreshing. High Availability: –RSVP-TE lends itself well to a system that must survive hardware failure or online software updates. –CR-LDP assumes reliable delivery of messages and so is not well placed to survive failover. Failure notification: only RSVP-TE provides failure notification, not CR-LDP!

28. June 4, 2003Carleton University & EIONGMPLS - 27 RSVP-TE Vs. CR-LDP Recovery when control channel is separated from data channel. –In case of a failure, when control channel information is lost between two nodes and then restored, both RSVP-TE and CR-LDP allow verifying that the state synchronization between the nodes runs correctly. –After a node has restarted when only its control channel communication is lost (but its data forwarding still remains), both RSVP-TE and CR-LDP allow its upstream and downstream nodes to help it for re-initialization. Policy Control: –RSVP is specified to allow the Path and Resv messages to carry a policy object with opaque content. –CR-LDP currently only carries implicit policy data (the destination addresses, the administrative resource class) in the traffic parameters.

29. June 4, 2003Carleton University & EIONGMPLS - 28 TIME NODE A NODE B NODE A NODE B RSVP LDP/CR-LDP REQUESTPATH MAPPING RESV THAT’S ALL!! FOREVER !! RSVP Vs. CR-LDP

30. June 4, 2003Carleton University & EIONGMPLS - 29 RSVP-TE:Refresh reduction Each Path and Resv message must be refreshed In a network with many LSPs, this requires lots of messages Hence the Refresh Reduction Extension This allows a router to send a single compact message that refreshes lots of LSPs at once

31. June 4, 2003Carleton University & EIONGMPLS - 30 RSVP-TE details RSVP-TE is an extension of “classical” RSVP Runs directly over IP Uses Path messages (= Label Request) and Resv messages (= Label Mapping) Extends classical RSVP with new objects (= (Type,length,value) TLVs) for these messages Explicit Route Object (ERO) contains hops

32. June 4, 2003Carleton University & EIONGMPLS - 31 CR-LDP details CR-LDP is an extension to LDP Like LDP, runs over TCP Uses existing LDP messages, but defines additional TLVs for the messages LSR Discovery –Multicast HELLO to well-known UDP port on “all routers on this subnet” multicast group –Can also send to configured IP addresses –Make TCP connection upon response

33. June 4, 2003Carleton University & EIONGMPLS - 32 POP 10.1.1. 1 10.1.1. 4 10.1.1. 3 Explicit route 10.1.1.7 strict 10.1.1.6 strict 10.1.1.2 loose 10.1.1.1 loose Strict hop LSP takes direct route to 10.1.1.7 Loose hop LSP takes shortest path to 10.1.1.2 10.1.1. 2 10.1.1. 6 10.1.1. 7 10.1.1. 5 Explicit route example

34. June 4, 2003Carleton University & EIONGMPLS - 33 Common features Operate in (Downstream-on-Demand, Conservative, Ordered) mode Features: –Explicit route –QoS specification –LSP preemption –LSP modification LDP sets up LSPs automatically, while CR- LDP and RSVP-TE typically require some sort of external intervention

35. June 4, 2003Carleton University & EIONGMPLS - 34 CR-LDP and RSVP-TE: Uses Used to set up point-to-point LSPs LSPs can follow any path Can specify QoS parameters for LSP Useful for: –Traffic Engineering of Public Internet traffic –Traffic Engineering of VPN tunnels –Automatic Setup of Light Paths in Automatically Switched Optical Networks (ASON)

36. June 4, 2003Carleton University & EIONGMPLS - 35 CR-LDP and RSVP-TE CR-LDP = “Constraint-Routed LDP” RSVP-TE = “RSVP with Traffic Engineering Extensions” From a user’s prospective, these two protocols provide essentially the same function