Internet Draft Network Working Group Daniel O. Awduche Internet Draft UUNET Worldcom, Inc. Expiration Date: May 1999 Lou Berger FORE Systems, Inc. Der-Hwa Gan Juniper Networks, Inc. Tony Li Juniper Networks, Inc. George Swallow Cisco Systems, Inc. Vijay Srinivasan Torrent Networks, Inc. November 1998 Extensions to RSVP for LSP Tunnels draft-ietf-mpls-rsvp-lsp-tunnel-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 establish label-switched paths (LSPs) in MPLS. Since Swallow, et al. [Page 1] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in [3]. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. Finally, we propose a number of mechanisms to reduce the refresh overhead of RSVP. The extensions can be used to reduce processing requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP message is lost and, when desired, eliminate the generation of refresh messages. An extension to support detection of when an RSVP neighbor resets its state is also presented. These extension present no backwards compatibility issues. Swallow, et al. [Page 2] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 Contents 1 Introduction and Background ............................ 5 1.1 Introduction ........................................... 5 1.2 Background ............................................. 6 2 Overview .............................................. 8 2.1 LSP Tunnels ............................................ 8 2.2 Operation of LSP Tunnels ............................... 8 2.3 Service Classes ........................................ 10 2.4 Reservation Styles ..................................... 10 2.4.1 Fixed Filter (FF) Style ................................ 11 2.4.2 Wildcard Filter (WF) Style ............................. 11 2.4.3 Shared Explicit (SE) Style ............................. 12 2.5 Rerouting LSP Tunnels .................................. 12 3 RSVP Message Formats ................................... 13 3.1 Path Message ........................................... 14 3.2 Resv Message ........................................... 14 4 Objects ................................................ 15 4.1 Label Object ........................................... 15 4.1.1 Handling Label Objects in Resv messages ................ 16 4.1.2 Non-support of the Label Object ........................ 16 4.2 Label Request Object ................................... 17 4.2.1 Handling of LABEL_REQUEST .............................. 20 4.2.2 Non-support of the Label Request Object ................ 21 4.3 Explicit Route Object .................................. 22 4.3.1 Applicability .......................................... 22 4.3.2 Semantics of the Explicit Route Object ................. 23 4.3.3 Subobjects ............................................. 24 4.3.4 Processing of the Explicit Route Object ................ 27 4.3.5 Loops .................................................. 29 4.3.6 Non-support of the Explicit Route Object ............... 29 4.4 Record Route Object .................................... 30 4.4.1 Subobjects ............................................. 30 4.4.2 Applicability .......................................... 32 4.4.3 Handling RRO ........................................... 33 4.4.4 Loop Detection ......................................... 34 4.4.5 Non-support of RRO ..................................... 34 4.5 Error Subcodes for ERO and RRO ......................... 35 4.6 Session, Sender Template, and Filter Spec Objects ...... 35 4.6.1 Session Object ......................................... 36 4.6.2 Sender Template Object ................................. 36 4.6.3 Filter Specification Object ............................ 37 4.6.4 Reroute Procedure ...................................... 37 4.7 Session Attribute Object ............................... 38 5 Refresh Related Extensions ............................. 41 5.1 RSVP Aggregate Message ................................. 42 Swallow, et al. [Page 3] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 5.1.1 Aggregate Header ....................................... 42 5.1.2 Message Formats ........................................ 43 5.1.3 Sending RSVP Aggregate Messages ........................ 43 5.1.4 Receiving RSVP Aggregate Messages ...................... 44 5.1.5 Forwarding RSVP Aggregate Messages ..................... 45 5.1.6 Aggregate-Capable Bit .................................. 45 5.2 MESSAGE_ID Extension ................................... 46 5.2.1 MESSAGE_ID Object ...................................... 47 5.2.2 Ack Message Format ..................................... 48 5.2.3 MESSAGE_ID Object Usage ................................ 49 5.2.4 MESSAGE_ID ACK Object Usage ............................ 50 5.2.5 Multicast Considerations ............................... 51 5.2.6 Compatibility .......................................... 52 5.3 Hello Extension ........................................ 52 5.3.1 Hello and Hello Ack Message Formats .................... 54 5.3.2 STATE_SET Object ....................................... 54 5.3.3 Hello Message Usage .................................... 55 5.3.4 Compatibility .......................................... 55 6 Acknowledgments ........................................ 56 7 References ............................................. 56 8 Authors' Addresses ..................................... 57 Swallow, et al. [Page 4] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 1. Introduction and Background 1.1. Introduction This document is a specification of extensions to RSVP for establishing label switched paths (LSPs) in Multi-protocol Label Switching (MPLS) networks. Several of the new features described in this document were motivated by the requirements for traffic engineering over MPLS (see [3]). In particular, the extended RSVP protocol supports the instantiation of explicitly routed LSPs, with or without resource reservations. It also supports smooth rerouting of LSPs, preemption, loop detection, and a fast reroute option to allow expedited service restoration under fault conditions. Since the traffic that flows along a label-switched path is defined by the label applied at the ingress node of the LSP, these paths can be treated as tunnels. When an LSP is used in this way we refer to it as an LSP tunnel. LSP tunnels allow the implementation of a variety of policies related to network performance optimization. For example, LSP tunnels can be automatically or manually routed away from network failures, congestion, and bottlenecks. Furthermore, multiple parallel LSP tunnels can be established between two nodes, and traffic between the two nodes can be mapped onto the LSP tunnels according to local policy. Although traffic engineering (that is, performance optimization of operational networks) is expected to be an important application of this specification, the extended RSVP protocol can be used in a much wider context. The purpose of this document is to describe the use of RSVP to establish LSP tunnels. The intent is to fully describe all the objects, packet formats, and procedures required to realize interoperable implementations. All objects described in this specification are optional with respect to RSVP. This document discusses what happens when an object described here is not supported by a node. Resilience and scalability are very important considerations in this specification. When an LSP tunnel fails, a significant amount of data can be lost. As a result, failure notification and service restoration should be fast and reliable. Accordingly, a number of features are provided to facilitate smooth reroute of LSP tunnels, fast reroute of LSP tunnels through intermediate detour paths under faults, and fast and reliable LSP tunnel teardown. A few new objects are also defined that enhance management and diagnostics of LSP tunnels. Swallow, et al. [Page 5] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 Several new RSVP objects and messages are used to reduced processing requirements related to RSVP refresh messages and address the latency and reliability of RSVP Signaling. First, an aggregate message is proposed to reduce the message handing load. Second tokens are added as a short hand method of identifying state. Third, procedures to suppress refreshes are defined. Last a Hello protocol is defined to detect loss of a neighbor's state. These extensions may be used in part in combination. They may be useful in other RSVP environments and may be supported independent of other MPLS related RSVP extensions. Throughout this document, the discussion will be restricted to unicast label switched paths. Multicast LSPs are left for further study. 1.2. Background Hosts and routers that support both RSVP [1] and Multi-Protocol Label Switching [2] can associate labels with RSVP flows. When MPLS and RSVP are combined, the definition of a flow can be made more flexible. Once a label switched path (LSP) is established, the traffic through the path is defined by the label applied at the ingress node of the LSP. The mapping of label to traffic can be accomplished using a number of different criteria. The set of packets that are assigned the same label value by a specific node are said to belong to the same forwarding equivalence class (FEC) (see [2]), and effectively define the "RSVP flow." When traffic is mapped onto a label-switched path in this way, we call the LSP an "LSP Tunnel". When labels are associated with traffic flows, it becomes possible for a router to identify the appropriate reservation state for a packet based on the packet's label value. This approach greatly simplifies packet classification and improves network performance because a single label lookup identifies both packet forwarding information and packet reservation state. The signaling protocol model uses downstream-on-demand label distribution. A request to bind labels to a specific LSP tunnel is initiated by an ingress node through the RSVP Path message. For this purpose, the RSVP Path message is augmented with a LABEL_REQUEST object. Labels are allocated downstream and distributed (propagated upstream) by means of the RSVP Resv message. For this purpose, the RSVP Resv message is extended with a special LABEL object. Label stacking is also supported. The procedures for label allocation, distribution, binding, and stacking are described in subsequent Swallow, et al. [Page 6] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 sections of this document. The signaling protocol model also supports explicit routing capability. This is accomplished by incorporating a simple EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE object encapsulates a concatenation of hops which constitutes the explicitly routed path. Using this object, the paths taken by label- switched RSVP-MPLS flows can be pre-determined, independent of conventional IP routing. The explicitly routed path can be administratively specified, or automatically computed by a suitable entity based on QoS and policy requirements, taking into consideration the prevailing network state. In general, path computation can be control-driven or data-driven. The mechanisms, processes, and algorithms used to compute explicitly routed paths are beyond the scope of this specification. One useful application of explicit routing is traffic engineering. Using explicitly routed LSPs, a node at the ingress edge of an MPLS domain can control the path through which traffic traverses from itself, through the MPLS network, to an egress node. Explicit routing can be used to optimize the utilization of network resources and enhance traffic oriented performance characteristics. The concept of explicitly routed label switched paths can be generalized through the notion of abstract nodes. An abstract node is a group of nodes whose internal topology is opaque to the ingress node of the LSP. An abstract node is said to be trivial if it is a singleton, that is if it contains only one physical node. Using this concept of abstraction, an explicitly routed LSP can be specified as a sequence of IP prefixes with subnet masks or a sequence of Autonomous Systems. The signaling protocol model supports the specification of an explicit path as a sequence of strict and loose routes. The combination of abstract nodes, and strict and loose routes significantly enhances the flexibility of path definitions. An advantage of using RSVP to establish LSP tunnels is that it enables the allocation of resources along the path. For example, bandwidth can be allocated to an LSP tunnel using standard RSVP reservations and Integrated Services service classes [4]. While resource reservations are useful, they are not mandatory. Indeed, an LSP can be instantiated without any resource reservations whatsoever. Such LSPs without resource reservations can be used, for example, to carry best effort traffic. They can also be used in many other contexts, including implementation of fall-back and recovery policies under fault conditions, and so forth. Swallow, et al. [Page 7] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 2. Overview 2.1. LSP Tunnels According to [1], "RSVP defines a 'session' to be a data flow with a particular destination and transport-layer protocol." However, when RSVP and MPLS are combined, a flow or session can be defined with greater flexibility and generality. The ingress node of an LSP can use a variety of means to determine which packets are assigned a particular label. Once a label is assigned to a set of packets, the label effectively defines the "flow" through the LSP. We refer to such an LSP as an "LSP tunnel" because the traffic through it is opaque to intermediate nodes along the label switched path. A new RSVP SESSION object, called LSP_TUNNEL_IPv4, has been defined to support the LSP tunnel feature. The semantics of this object, from the perspective of a node along the label switched path, is that traffic belonging to the LSP tunnel is identified solely on the basis of packets arriving from the PHOP or "previous hop" (see [1]) with the particular label value(s) assigned by this node to upstream senders to the session. In fact, the IPv4 that appears in the object name only denotes that the destination address is an IPv4 address. 2.2. Operation of LSP Tunnels This section summarizes some of the features supported by RSVP as extended by this document related to the operation of LSP tunnels. These include: (1) the capability to establish LSP tunnels with or without QoS requirements, (2) the capability to dynamically reroute an established LSP tunnel, (3) the capability to observe the actual route traversed by an established LSP tunnel, (4) the capability to identify and diagnose LSP tunnels, (5) the capability to preempt an established LSP tunnel under administrative policy control, and (6) the capability to perform downstream-on-demand label allocation, distribution, and binding. In the following paragraphs, these features are briefly described. More detailed descriptions can be found in subsequent sections of this document. To create an LSP tunnel, the first MPLS node on the path -- that is, the sender node with respect to the path -- creates an RSVP Path message with a session type of LSP_Tunnel_IPv4 and 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 Swallow, et al. [Page 8] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 protocol as MPLS. If the sender node has knowledge of a route that has high likelihood of meeting the tunnel's QoS requirements, or that makes efficient use of network resources, or that satisfies some policy criteria, the node can decide to use the route for some or all of its sessions. To do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP Path message. The EXPLICIT_ROUTE object specifies the route as a sequence of abstract nodes. If, after a session has been successfully established and the sender node discovers a better route, the sender can dynamically reroute the session by simply changing the EXPLICIT_ROUTE object. If problems are encountered with an EXPLICIT_ROUTE object, either because it causes a routing loop or because some intermediate routers do not support it, the sender node is notified. By adding a RECORD_ROUTE object to the Path message, the sender node can receive information about the actual route that the LSP tunnel traverses. The sender node can also use this object to request notification from the network concerning changes to the routing path. The RECORD_ROUTE object is analogous to a path vector, and hence can be used for loop detection. Finally, a SESSION_ATTRIBUTE object can be added to Path messages to aid in session identification and diagnostics. Additional control information, such as preemption, priority, and fast-reroute, are 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 this case the modified ERO should be stored in the path state block. The LABEL_REQUEST object requests intermediate routers and receiver 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 does not provide this support. The destination node of a label-switched path responds to a LABEL_REQUEST by including a LABEL object in its response RSVP Resv message. The LABEL object is inserted in the filter spec list immediately following the filter spec to which it pertains. The Resv message is sent back upstream towards the sender, in a Swallow, et al. [Page 9] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 direction opposite to that followed by the Path message. Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this LSP tunnel. If the node is not the sender, it allocates a new label and places that label in the corresponding LABEL object of the Resv message which it sends upstream to the PHOP. The label sent upstream in the LABEL object is the label which this node will use to identify incoming traffic associated with this LSP tunnel. This label also serves as shorthand for the Filter Spec. The node can now update its "Incoming Label Map" (ILM), which is used to map incoming labeled packets to a "Next Hop Label Forwarding Entry" (NHLFE), see [2]. When the Resv message propagates upstream to the sender node, a label-switched path is effectively established. 2.3. Service Classes This document does not restrict the type of Integrated Service requests for reservations. However, an implementation should support the Controlled-Load service [4]. An LSP may not need bandwidth reservations or QoS guarantees. Such LSPs can be used to deliver best-effort traffic, even if RSVP is used for setting up LSPs. When resources do not have 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.4. 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 can result in one or more LSPs, depending on the 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. A more detailed Swallow, et al. [Page 10] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 discussion of reservation styles can be found in [1]. 2.4.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 can be assigned to each sender. This can result in a point-to-point LSP between every sender/receiver pair. 2.4.2. Wildcard Filter (WF) Style With the Wildcard Filter (WF) reservation style, a single shared reservation is used for all senders to a session. The total reservation on a link remains the same regardless of the number of senders. A single multipoint-to-point label-switched-path is created for all senders to the session. On links that senders to the session share, a single label value is allocated to the session. If there is only one sender, the LSP looks like a normal point-to-point connection. When multiple senders are present, a multipoint-to-point LSP (a reversed tree) is created. This style is useful for 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. If, however, the reservation requested is greater than a single sender's requirements, then the reserved bandwidth on links close to the some senders may be greater than what is required. This restricts the applicability of WF for traffic engineering purposes. Furthermore, because of the merging rules of WF, EXPLICIT_ROUTE objects cannot be used with WF reservations. As a result of this issue and the lack of applicability to traffic engineering, use of WF is not considered in this document. Swallow, et al. [Page 11] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 2.4.3. Shared Explicit (SE) Style The Shared Explicit (SE) style allows a receiver to explicitly specify the senders to be included in a reservation. There is a single reservation on a link for all the senders listed. Because each sender is explicitly listed in the Resv message, separate labels may be assigned to each sender, thereby creating separate LSPs for each sender. Having separate LSPs for each sender ensures compatibility 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 in the network topology. 2.5. Rerouting LSP Tunnels One of the requirements for Traffic Engineering is the capability to reroute an established LSP tunnel under a number of conditions, based on administrative policy. For example, in some contexts, an administrative policy may dictate that a given LSP tunnel is to be rerouted when a more "optimal" route becomes available. Another important context when LSP tunnel reroute is usually required is upon failure of a resource along the tunnel's established path. Under some policies, it may also be necessary to return the LSP tunnel to its original path when the failed resource becomes re-activated. In general, it is highly desirable not to disrupt traffic, or adversely impact network operations while LSP tunnel rerouting is in progress. This adaptive and smooth rerouting requirement necessitates establishing a new LSP tunnel and transferring traffic from the old LSP tunnel onto it before tearing down the old LSP tunnel. This concept is called "make-before-break." A problem can arise because the old and new LSP tunnels might compete with other for resources on network segments which they have in common. Depending on availability of resources, this competition can cause Admission Control to prevent the new tunnel from being established. An advantage of using RSVP to establish LSP tunnels is that it solves this problem very elegantly. To support make-before-break in a smooth fashion, it is necessary that on links that are common to the old and new LSPs, resources used by the old LSP tunnel should not be released before traffic is transitioned to the new LSP tunnel, and reservations should not be counted twice because this might cause Admission Control to reject the new LSP tunnel. Swallow, et al. [Page 12] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 The combination of the LSP_TUNNEL_IPv4 SESSION object and the SE reservation style naturally achieves smooth transitions. The basic idea is that the old and new LSP tunnels share resources along links which they have in common. 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 appear as two different sources to RSVP. This is achieved by the inclusion of an "LSP ID", which is carried in the SENDER_TEMPLATE and FILTER_SPEC objects. Since the semantics of these objects are 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. The source node then creates a new ERO to define the new path. Thereafter 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 that are not held in common, the new Path message is treated as a conventional new LSP tunnel setup. On links held in common, the shared SESSION object and SE style allow the LSP to be established sharing resources with the old LSP. Once the sender receives a Resv message for the new LSP, it can transition traffic to it and tear down the old LSP. 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 New C-Types are also 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 can choose to support a subset of objects. However, the LABEL_REQUEST and LABEL objects are mandatory with respect to this Swallow, et al. [Page 13] Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-00.txt November 1998 specification. 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 recommendation. 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:::= [ ] [ ] [ ] [ ... ] [ ] ::= [ ] [ ] [ ] 3.2. Resv Message The format of the Resv message is as follows: ::= [ ] [ ] [ ] [ ... ]