Internet Draft MPLS & RSVP Working Groups Daniel Awduche Internet Draft UUNET Technologies, Inc. Expiration Date: February 1999 Der-Hwa Gan Juniper Networks, Inc. Tony Li Juniper Networks, Inc. George Swallow Cisco Systems, Inc. Vijay Srinivasan Torrent Networks, Inc. August 1998 Extensions to RSVP for Traffic Engineering draft-swallow-mpls-rsvp-trafeng-00.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes the use of RSVP, including all the necessary extensions, to support traffic engineering with MPLS as specified in [6]. Swallow, editor [Page 1] Internet Draft draft-swallow-mpls-rsvp-trafeng-00.txt August 1998 We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths (LSPs), using RSVP as a signaling protocol. The result is the instantiation of label-switched sessions which can be automatically routed away from network failures, congestion, and bottlenecks. Swallow, editor [Page 2] Internet Draft draft-swallow-mpls-rsvp-trafeng-00.txt August 1998 Contents 1 Introduction ........................................... 4 2 Overview of operation .................................. 5 2.1 Service Classes ........................................ 6 2.2 Reservation styles ..................................... 6 2.2.1 Fixed Filter (FF) style ................................ 7 2.2.2 Wildcard Filter (WF) style ............................. 7 2.2.3 Shared Explicit (SE) style ............................. 8 2.3 LSP Tunnels ............................................ 8 2.4 Rerouting LSP Tunnels .................................. 9 3 RSVP Message Formats ................................... 10 3.1 Path message ........................................... 10 3.2 Resv message ........................................... 11 4 Objects ................................................ 11 4.1 Label Object ........................................... 11 4.1.1 Handling Label Objects in Resv messages ................ 12 4.1.2 Non-support of the Label Object ........................ 13 4.2 Label Request Object ................................... 13 4.2.1 Handling of LABEL_REQUEST .............................. 14 4.2.2 Non-support of the Label Request Object ................ 14 4.3 Explicit Route Object .................................. 15 4.3.1 Subobjects ............................................. 15 4.3.2 Applicability .......................................... 16 4.3.3 Semantics of the Explicit Route Object ................. 16 4.3.4 Strict and Loose subobjects ............................ 17 4.3.5 Loops .................................................. 18 4.3.6 Subobject semantics .................................... 18 4.3.7 Processing of the Explicit Route Object ................ 20 4.3.8 Non-support of the Explicit Route Object ............... 21 4.4 Record Route Object .................................... 22 4.4.1 Subobjects ............................................. 22 4.4.2 Applicability .......................................... 24 4.4.3 Handling RRO ........................................... 25 4.4.4 Loop Detection ......................................... 26 4.4.5 Non-support of RRO ..................................... 26 4.5 Error subcodes for ERO and RRO ......................... 27 4.6 Session, Sender Template, and Filter Spec Objects ...... 27 4.6.1 Session Object ......................................... 27 4.6.2 Sender Template Object ................................. 28 4.6.3 Filter Specification Object ............................ 29 4.6.4 Reroute procedure ...................................... 29 4.7 Session Attribute Object ............................... 30 5 RSVP Aggregate Message ................................. 33 5.1 Aggregate Header ....................................... 33 5.2 Message Formats ........................................ 35 Swallow, editor [Page 3] Internet Draft draft-swallow-mpls-rsvp-trafeng-00.txt August 1998 5.3 Sending RSVP Aggregate Messages ........................ 35 5.4 Receiving RSVP Aggregate Messages ...................... 36 5.5 Forwarding RSVP Aggregate Messages ..................... 37 5.6 Aggregate-capable bit .................................. 37 6 Tear Confirm ........................................... 37 7 Security Considerations ................................ 39 8 Acknowledgments ........................................ 39 9 References ............................................. 39 1. Introduction For hosts and routers that support both RSVP [1] and Multi-Protocol Label Switching [2], it is possible to associate labels with RSVP flows [4]. The result is that a router can identify the appropriate reservation state for a packet based on its label value, thus greatly simplifying packet classification. This design also improves network performance because the same label lookup identifies forwarding information of the packet. Using RSVP to establish label switched paths (LSPs) clearly enables the allocation of resources to an LSP. For example, you can allocate bandwidth to an LSP using standard RSVP reservations and Integrated Services service classes [7]. While this is useful, reservations are not required. An LSP can also be established to carry best-effort traffic without a resource reservation. It is possible to add explicit routing capability on top of label- switched RSVP flows [3] [5] by adding a simple EXPLICIT_ROUTE object to RSVP. By using this object, the paths taken by label-switched RSVP flows can be predetermined, independent of conventional IP routing. The hops in the path can be manually configured, or computed automatically based on the QoS requirements of the flow and the current network load. The purpose of this document is to organize all the objects from [3], [4], and [5] into a single document that fully describes all the procedures and packet formats so that interoperable implementations are possible. A few new objects are also suggested for enhancing management and diagnostics of LSPs. All objects described are optional, and this document describes what happens when an object is not supported by a node. Finally, an RSVP aggregate message is proposed to help alleviate one of the RSVP scaling issues: how to efficiently handle large number of Swallow, editor [Page 4] Internet Draft draft-swallow-mpls-rsvp-trafeng-00.txt August 1998 RSVP messages that are periodically transmitted between neighbors. The document concentrates on unicast LSPs. Explicitly routed multicast LSPs are left for further study. 2. Overview of operation When an RSVP flow originates in or crosses an MPLS domain, the flow may be label switched. To initiate label switching, the first MPLS node inserts a LABEL_REQUEST object into the Path message. The LABEL_REQUEST object indicates that a label binding for this path is requested, and also provides an indication of the network layer protocol that is to be carried over this path. The reason for this is that the network layer protocol sent down an LSP cannot be assumed to be IPv4, and cannot be deduced from the L2 header, which simply identifies the higher layer protocol as being MPLS. If the sender node has prior knowledge of an alternative route that has better likelihood of meeting the flow's QoS requirement or that makes more efficient use of network resources, the node can decide to reroute some of its sessions. To do this, the node adds an EXPLICIT_ROUTE object to the Path message. If, during a session, the sender node finds a better route, the session can be rerouted on the fly by simply changing the EXPLICIT_ROUTE object. If there are problems with an EXPLICIT_ROUTE object, either because it causes a routing loop or some intermediate routers do not support it, the sender node is notified. If the RECORD_ROUTE object is added to Path messages, the sender node can receive information about the exact routing path and can prompt for notifications from the network if the routing path changes for any reason. Finally, a SESSION_ATTRIBUTE object can be added to Path messages for aiding in session identification and diagnostics. Additional control information, such as preemption, priority, and fast-reroute, is also included in this object. When the EXPLICIT_ROUTE object (ERO) is present, the Path message is forwarded towards its destination along a path specified by the ERO. Each node along the path records the ERO in its path state block. Nodes may also modify the ERO before forwarding the Path message, in which case the modified ERO should be stored in the path state block. The LABEL_REQUEST object requests intermediate routers and receiving Swallow, editor [Page 5] Internet Draft draft-swallow-mpls-rsvp-trafeng-00.txt August 1998 nodes to provide a label binding for the session. If a node is incapable of providing a label binding it sends a PathErr message with an "unknown object class" error. If the LABEL_REQUEST object is not supported end to end, the sender node will be notified by the first node which lacks the support. The destination node includes a LABEL object in its response Resv message. The LABEL object is inserted in the filter spec list immediately following the filter spec to which it pertains. When the LABEL object propagates upstream to the sender node, a label-switched path is already set up for use. The Resv message is sent back towards the sender. A node that receives a Resv message containing a label uses that label for outgoing traffic on this path. It also allocates a new label and places that label in the corresponding LABEL object of the Resv message before sending it upstream. This is the label that this node will use for incoming traffic on this path. This label now serves as shorthand for the Filter Spec. 2.1. Service Classes This document does not restrict the type of Integrated Service requested on a reservations. However, an implementation should always be ready to accept the Controlled-Load service [7]. An LSP may not need a bandwidth reservation or a QoS guarantee. Such LSPs can be used to deliver best-effort traffic, even if RSVP is used for setting up LSPs. When no resources need to be allocated to the LSP, the Sender_TSpec in the Path message can specify a token bucket rate of zero and a token bucket size of zero. The corresponding FLOWSPEC (in the Resv message) should carry a zero rate and size as well. LSPs with no bandwidth reservation are not subject to Admission Control and do not require traffic policing. 2.2. Reservation styles The receiver node can select from among a set of possible reservation styles for each session, and each RSVP session must have a particular style. Senders have no influence on the choice of reservation style. The receiver can choose different reservation styles for different LSPs. An RSVP session is identified by a unique (destination address, protocol, destination port) tuple. An RSVP session can create one or more LSPs, depending on the Swallow, editor [Page 6] Internet Draft draft-swallow-mpls-rsvp-trafeng-00.txt August 1998 reservation style chosen. Some reservation styles, such as FF, dedicate a particular reservation to an individual sender node. Other reservation styles, such as WF and SE, can share a reservation among several sender nodes. The following sections discuss the different reservation styles and their advantages and disadvantages. 2.2.1. Fixed Filter (FF) style The Fixed Filter (FF) reservation style creates a distinct reservation for traffic from each sender that is not shared by other senders. This style is common for applications in which traffic from each sender is likely to be concurrent and independent. The total amount of reserved bandwidth on a link for sessions using FF is the sum of the reservations for the individual senders. Because each sender has its own reservation, a unique label and a separate label-switched-path is assigned to each sender. This results in a point-to-point LSP between every sender/receiver pair. Because the network state overhead is proportional to the number of LSPs, having more LSPs means that more network resources are consumed. 2.2.2. Wildcard Filter (WF) style With the Wildcard Filter (WF) reservation style, a single shared reservation is used for all senders. The total reservation on a link remains the same regardless of the number of senders. This style is useful in applications in which not all senders send traffic at the same time. A phone conference, for example, is an application where not all speakers talk at the same time. A single label-switched-path is created for all senders, because all senders to the session are covered by the reservation. On links that senders share, a single label is allocated. If there is only one sender, the LSP looks like normal point-to-point connection. When multiple senders are present, a multipoint-to-point LSP (a reversed tree) is created. This has the advantage of minimizing the number of LSPs (and the memory and CPU resources used for each LSP), allowing the network to scale better. Because of the merging rules, EXPLICIT_ROUTE objects cannot be used with WF reservations. Hence, the use of the WF style should be discouraged in the presence of ERO. Swallow, editor [Page 7] Internet Draft draft-swallow-mpls-rsvp-trafeng-00.txt August 1998 2.2.3. Shared Explicit (SE) style Unlike the WF style, where any sender is allowed to share the reservation, the Shared Explicit (SE) style allows a receiver to explicitly specify the senders to be included. There is a single reservation on a link for all the senders listed. Only listed senders can join the reservation. Because each sender is explicitly listed in the Resv message, you can assign separate labels to each sender, therefore creating separate LSPs for each sender. [4] describes the reason why separate LSPs are needed. Having separate LSPs for each sender also eliminates the incompatibility with the EXPLICIT_ROUTE object. Path messages from different senders can carry their own ERO, and the paths taken by the senders can converge and diverge at any point. Unlike the FF style, all SE LSPs share the single reservation. Unlike the WF style, a separate LSP is created for each sender. 2.3. LSP Tunnels When LSPs are used to carry flows, it becomes possible to be more flexible in the definition of a flow. The first node in an LSP can use any of a variety of means to determine which packets will be assigned a particular label. Once that label is assigned, the label becomes the definition of the flow. We refer to such an LSP as an LSP Tunnel due to the opaque nature of the flow. In support of this, a new SESSION object, LSP_TUNNEL_IPv4 is defined. The semantics of this object are that the flow is defined solely on the basis of packets arriving from the PHOP with the particular label value(s) assigned by this node to senders to the session. In fact, the IPv4 appearing in the object name only denotes that the destination address is an IPv4 address. An application of particular interest is traffic engineering. By establishing ER-LSPs a node at the edge of an MPLS domain can control the path which traffic from this node will take through that domain. These capabilities can be used to optimize the utilization of network resources and enhance traffic oriented performance characteristics. Swallow, editor [Page 8] Internet Draft draft-swallow-mpls-rsvp-trafeng-00.txt August 1998 2.4. Rerouting LSP Tunnels One of the requirements for Traffic Engineering is the ability to have an LSP tunnel re-routed upon a failure of a resource along its current path. A further requirement is the ability to have the LSP tunnel return to its original path when the failed resource is restored. It is also desirable not to disrupt traffic while rerouting is in progress. The adaptive rerouting requirement calls for establishing a new LSP while keeping the old LSP intact. On links that old and new LSPs share, one wishes to (1) not release resources from the old LSP that one wants to use for the new LSP, and (2) not double-count reservations, because this might cause Admission Control to deny the new LSP. The combination of the LSP_TUNNEL_IPv4 SESSION object and the SE reservation style naturally achieves smooth transitions. The LSP_TUNNEL_IPv4 SESSION object is used to narrow the scope of the RSVP session to the particular tunnel in question. To uniquely identify a tunnel we use the combination of the destination IP address, a Tunnel ID, and the sender's IP address which is placed in the Extended Tunnel ID field. During the reroute operation, the source needs to be able to appear as two different sources to RSVP. This is achieved by the use of a "LSP ID", which is carried in the SENDER_TEMPLATE and FILTER_SPEC objects. Since the semantics of these objects is changed, a new C- Type is assigned. To effect a reroute, the source node picks a new LSP ID and forms a new SENDER_TEMPLATE. It creates a new ERO to define the new path. The node sends a new Path Message using the original SESSION object and the new SENDER_TEMPLATE and ERO. It continues to use the old LSP and refresh the old Path message. On links which are not in common, the new Path message is treated as any new LSP tunnel setup. On links held in common, the shared SESSION object and SE style allow the LSP to be established sharing the same resources. Once the sender receives a Resv message for the new LSP, it is free to begin using it and to tear down the old LSP. Also new C-Types are assigned for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects. Detailed descriptions of the new objects are given in later sections. All new objects are optional with respect to RSVP. An implementation Swallow, editor [Page 9] Internet Draft draft-swallow-mpls-rsvp-trafeng-00.txt August 1998 3. RSVP Message Formats Five new objects are defined in this document: Object name Applicable RSVP messages --------------- ------------------------ LABEL_REQUEST Path LABEL Resv EXPLICIT_ROUTE Path RECORD_ROUTE Path, Resv SESSION_ATTRIBUTE Path can choose to support some but not other objects. However, the LABEL_REQUEST and LABEL objects are mandatory with respect to this document. The LABEL and RECORD_ROUTE objects, are sender specific. They must immediately follow either the SENDER_TEMPLATE in Path messages, or the FILTER_SPEC in Resv messages. The placement of EXPLICIT_ROUTE, LABEL_REQUEST, and SESSION_ATTRIBUTE objects is simply a suggestion. While it is recommended that an implementation follow this format, the ordering of these objects is not important, so an implementation must be prepared to accept objects in any order. 3.1. Path message The format of the Path message is as follows:::= [ ] [ ] [ ] [ ... ] [ ] ::= [ ] [ ] [ ] Swallow, editor [Page 10] Internet Draft draft-swallow-mpls-rsvp-trafeng-00.txt August 1998 3.2. Resv message The format of the Resv message is as follows: ::= [ ] [ ] [ ] [ ... ]