From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3209.txt | 3419 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3419 insertions(+) create mode 100644 doc/rfc/rfc3209.txt (limited to 'doc/rfc/rfc3209.txt') diff --git a/doc/rfc/rfc3209.txt b/doc/rfc/rfc3209.txt new file mode 100644 index 0000000..5575b57 --- /dev/null +++ b/doc/rfc/rfc3209.txt @@ -0,0 +1,3419 @@ + + + + + + +Network Working Group D. Awduche +Request for Comments: 3209 Movaz Networks, Inc. +Category: Standards Track L. Berger + D. Gan + Juniper Networks, Inc. + T. Li + Procket Networks, Inc. + V. Srinivasan + Cosine Communications, Inc. + G. Swallow + Cisco Systems, Inc. + December 2001 + + + RSVP-TE: Extensions to RSVP for LSP Tunnels + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document describes the use of RSVP (Resource Reservation + Protocol), including all the necessary extensions, to establish + label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). + Since 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 RFC 2702. + + 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. + + + + + + + + +Awduche, et al. Standards Track [Page 1] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + +Contents + + 1 Introduction .......................................... 3 + 1.1 Background ............................................. 4 + 1.2 Terminology ............................................ 6 + 2 Overview .............................................. 7 + 2.1 LSP Tunnels and Traffic Engineered Tunnels ............. 7 + 2.2 Operation of LSP Tunnels ............................... 8 + 2.3 Service Classes ........................................ 10 + 2.4 Reservation Styles ..................................... 10 + 2.4.1 Fixed Filter (FF) Style ................................ 10 + 2.4.2 Wildcard Filter (WF) Style ............................. 11 + 2.4.3 Shared Explicit (SE) Style ............................. 11 + 2.5 Rerouting Traffic Engineered Tunnels ................... 12 + 2.6 Path MTU ............................................... 13 + 3 LSP Tunnel related Message Formats ..................... 15 + 3.1 Path Message ........................................... 15 + 3.2 Resv Message ........................................... 16 + 4 LSP Tunnel related Objects ............................. 17 + 4.1 Label Object ........................................... 17 + 4.1.1 Handling Label Objects in Resv messages ................ 17 + 4.1.2 Non-support of the Label Object ........................ 19 + 4.2 Label Request Object ................................... 19 + 4.2.1 Label Request without Label Range ...................... 19 + 4.2.2 Label Request with ATM Label Range ..................... 20 + 4.2.3 Label Request with Frame Relay Label Range ............. 21 + 4.2.4 Handling of LABEL_REQUEST .............................. 22 + 4.2.5 Non-support of the Label Request Object ................ 23 + 4.3 Explicit Route Object .................................. 23 + 4.3.1 Applicability .......................................... 24 + 4.3.2 Semantics of the Explicit Route Object ................. 24 + 4.3.3 Subobjects ............................................. 25 + 4.3.4 Processing of the Explicit Route Object ................ 28 + 4.3.5 Loops .................................................. 30 + 4.3.6 Forward Compatibility .................................. 30 + 4.3.7 Non-support of the Explicit Route Object ............... 31 + 4.4 Record Route Object .................................... 31 + 4.4.1 Subobjects ............................................. 31 + 4.4.2 Applicability .......................................... 34 + 4.4.3 Processing RRO ......................................... 35 + 4.4.4 Loop Detection ......................................... 36 + 4.4.5 Forward Compatibility .................................. 37 + 4.4.6 Non-support of RRO ..................................... 37 + 4.5 Error Codes for ERO and RRO ............................ 37 + 4.6 Session, Sender Template, and Filter Spec Objects ...... 38 + 4.6.1 Session Object ......................................... 39 + 4.6.2 Sender Template Object ................................. 40 + 4.6.3 Filter Specification Object ............................ 42 + + + +Awduche, et al. Standards Track [Page 2] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + 4.6.4 Reroute and Bandwidth Increase Procedure ............... 42 + 4.7 Session Attribute Object ............................... 43 + 4.7.1 Format without resource affinities ..................... 43 + 4.7.2 Format with resource affinities ........................ 45 + 4.7.3 Procedures applying to both C-Types .................... 46 + 4.7.4 Resource Affinity Procedures .......................... 48 + 5 Hello Extension ........................................ 49 + 5.1 Hello Message Format ................................... 50 + 5.2 HELLO Object formats ................................... 51 + 5.2.1 HELLO REQUEST object ................................... 51 + 5.2.2 HELLO ACK object ....................................... 51 + 5.3 Hello Message Usage .................................... 52 + 5.4 Multi-Link Considerations .............................. 53 + 5.5 Compatibility .......................................... 54 + 6 Security Considerations ................................ 54 + 7 IANA Considerations .................................... 54 + 7.1 Message Types .......................................... 55 + 7.2 Class Numbers and C-Types .............................. 55 + 7.3 Error Codes and Globally-Defined Error Value Sub-Codes . 57 + 7.4 Subobject Definitions .................................. 57 + 8 Intellectual Property Considerations ................... 58 + 9 Acknowledgments ........................................ 58 + 10 References ............................................. 58 + 11 Authors' Addresses ..................................... 60 + 12 Full Copyright Statement ............................... 61 + +1. Introduction + + Section 2.9 of the MPLS architecture [2] defines a label distribution + protocol as a set of procedures by which one Label Switched Router + (LSR) informs another of the meaning of labels used to forward + traffic between and through them. The MPLS architecture does not + assume a single label distribution protocol. This document is a + specification of extensions to RSVP for establishing label switched + paths (LSPs) in 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, and loop + detection. + + The LSPs created with RSVP can be used to carry the "Traffic Trunks" + described in [3]. The LSP which carries a traffic trunk and a + traffic trunk are distinct though closely related concepts. For + example, two LSPs between the same source and destination could be + load shared to carry a single traffic trunk. Conversely several + + + +Awduche, et al. Standards Track [Page 3] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + traffic trunks could be carried in the same LSP if, for instance, the + LSP were capable of carrying several service classes. The + applicability of these extensions is discussed further in [10]. + + 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, tunneling below normal IP routing and + filtering mechanisms. 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. A few new objects are also defined + that enhance management and diagnostics of LSP tunnels. + + The document also describes a means of rapid node failure detection + via a new HELLO message. + + All objects and messages 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. + + Throughout this document, the discussion will be restricted to + unicast label switched paths. Multicast LSPs are left for further + study. + +1.1. 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 + + + +Awduche, et al. Standards Track [Page 4] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + 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. + + 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. The + procedures for label allocation, distribution, binding, and stacking + are described in subsequent 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 simple 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 or a sequence of Autonomous Systems. + + + + + + +Awduche, et al. Standards Track [Page 5] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + 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. + +1.2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC2119 [6]. + + The reader is assumed to be familiar with the terminology in [1], [2] + and [3]. + + Abstract Node + + A group of nodes whose internal topology is opaque to the ingress + node of the LSP. An abstract node is said to be simple if it + contains only one physical node. + + Explicitly Routed LSP + + An LSP whose path is established by a means other than normal IP + routing. + + Label Switched Path + + The path created by the concatenation of one or more label + switched hops, allowing a packet to be forwarded by swapping + labels from an MPLS node to another MPLS node. For a more precise + definition see [2]. + + LSP + + A Label Switched Path + + + + +Awduche, et al. Standards Track [Page 6] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + LSP Tunnel + + An LSP which is used to tunnel below normal IP routing and/or + filtering mechanisms. + + Traffic Engineered Tunnel (TE Tunnel) + + A set of one or more LSP Tunnels which carries a traffic trunk. + + Traffic Trunk + + A set of flows aggregated by their service class and then placed + on an LSP or set of LSPs called a traffic engineered tunnel. For + further discussion see [3]. + +2. Overview + +2.1. LSP Tunnels and Traffic Engineered 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. + + New RSVP SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects, called + LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 have been defined to support the + LSP tunnel feature. The semantics of these objects, 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(v6) that appears in the object + name only denotes that the destination address is an IPv4(v6) + address. When we refer to these objects generically, we use the + qualifier LSP_TUNNEL. + + In some applications it is useful to associate sets of LSP tunnels. + This can be useful during reroute operations or to spread a traffic + trunk over multiple paths. In the traffic engineering application + such sets are called traffic engineered tunnels (TE tunnels). To + enable the identification and association of such LSP tunnels, two + identifiers are carried. A tunnel ID is part of the SESSION object. + The SESSION object uniquely defines a traffic engineered tunnel. The + + + +Awduche, et al. Standards Track [Page 7] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The + SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION + object uniquely identifies an LSP tunnel + +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 or LSP_TUNNEL_IPv6 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 IP and cannot be deduced from the L2 header, which simply + identifies the higher layer 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, 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 + + + +Awduche, et al. Standards Track [Page 8] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + 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 setup and hold priorities, resource affinities + (see [3]), and local-protection, are also included in this object. + + Routers along the path may use the setup and hold priorities along + with SENDER_TSPEC and any POLICY_DATA objects contained in Path + messages as input to policy control. For instance, in the traffic + engineering application, it is very useful to use the Path message as + a means of verifying that bandwidth exists at a particular priority + along an entire path before preempting any lower priority + reservations. If a Path message is allowed to progress when there + are insufficient resources, then there is a danger that lower + priority reservations downstream of this point will unnecessarily be + preempted in a futile attempt to service this request. + + 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 + in addition to the received ERO. + + 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, following + the path state created by the Path message, in reverse order. Note + that if the path state was created by use of an ERO, then the Resv + message will follow the reverse path of the ERO. + + 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 + + + +Awduche, et al. Standards Track [Page 9] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + 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] and the Null Service [16]. + +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 + 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 is + assigned to each sender. This can result in a point-to-point LSP + between every sender/receiver pair. + + + + + +Awduche, et al. Standards Track [Page 10] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + +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, all senders send simultaneously, then there is no means of + getting the proper reservations made. Either the reserved bandwidth + on links close to the destination will be less than what is required + or then the reserved bandwidth on links close to some senders will 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. + +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, different + labels may be assigned to different senders, thereby creating + separate LSPs. + + SE style reservations can be provided using multipoint-to-point + label-switched-path or LSP per sender. Multipoint-to-point LSPs may + be used when path messages do not carry the EXPLICIT_ROUTE object, or + when Path messages have identical EXPLICIT_ROUTE objects. In either + of these cases a common label may be assigned. + + + + + + + + +Awduche, et al. Standards Track [Page 11] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + Path messages from different senders can each carry their own ERO, + and the paths taken by the senders can converge and diverge at any + point in the network topology. When Path messages have differing + EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object + must be established. + +2.5. Rerouting Traffic Engineered Tunnels + + One of the requirements for Traffic Engineering is the capability to + reroute an established TE tunnel under a number of conditions, based + on administrative policy. For example, in some contexts, an + administrative policy may dictate that a given TE tunnel is to be + rerouted when a more "optimal" route becomes available. Another + important context when TE tunnel reroute is usually required is upon + failure of a resource along the TE tunnel's established path. Under + some policies, it may also be necessary to return the TE 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 TE 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 each + 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 LSP 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. + + A similar situation can arise when one wants to increase the + bandwidth of a TE tunnel. The new reservation will be for the full + amount needed, but the actual allocation needed is only the delta + between the new and old bandwidth. If policy is being applied to + PATH messages by intermediate nodes, then a PATH message requesting + too much bandwidth will be rejected. In this situation simply + increasing the bandwidth request without changing the + SENDER_TEMPLATE, could result in a tunnel being torn down, depending + upon local policy. + + + + +Awduche, et al. Standards Track [Page 12] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + The combination of the LSP_TUNNEL SESSION object and the SE + reservation style naturally accommodates smooth transitions in + bandwidth and routing. The idea is that the old and new LSP tunnels + share resources along links which they have in common. The + LSP_TUNNEL SESSION object is used to narrow the scope of the RSVP + session to the particular TE tunnel in question. To uniquely + identify a TE tunnel, we use the combination of the destination IP + address (an address of the node which is the egress of the tunnel), a + Tunnel ID, and the tunnel ingress node's IP address, which is placed + in the Extended Tunnel ID field. + + During the reroute or bandwidth-increase operation, the tunnel + ingress needs to appear as two different senders to the RSVP session. + This is achieved by the inclusion of the "LSP ID", which is carried + in the SENDER_TEMPLATE and FILTER_SPEC objects. Since the semantics + of these objects are changed, a new C-Types are assigned. + + To effect a reroute, the ingress node picks a new LSP ID and forms a + new SENDER_TEMPLATE. The ingress 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 ingress + node receives a Resv message for the new LSP, it can transition + traffic to it and tear down the old LSP. + + To effect a bandwidth-increase, a new Path Message with a new LSP_ID + can be used to attempt a larger bandwidth reservation while the + current LSP_ID continues to be refreshed to ensure that the + reservation is not lost if the larger reservation fails. + +2.6. Path MTU + + Standard RSVP [1] and Int-Serv [11] provide the RSVP sender with the + minimum MTU available between the sender and the receiver. This path + MTU identification capability is also provided for LSPs established + via RSVP. + + Path MTU information is carried, depending on which is present, in + the Integrated Services or Null Service objects. When using + Integrated Services objects, path MTU is provided based on the + procedures defined in [11]. Path MTU identification when using Null + Service objects is defined in [16]. + + + + + +Awduche, et al. Standards Track [Page 13] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + With standard RSVP, the path MTU information is used by the sender to + check which IP packets exceed the path MTU. For packets that exceed + the path MTU, the sender either fragments the packets or, when the IP + datagram has the "Don't Fragment" bit set, issues an ICMP destination + unreachable message. This path MTU related handling is also required + for LSPs established via RSVP. + + The following algorithm applies to all unlabeled IP datagrams and to + any labeled packets which the node knows to be IP datagrams, to which + labels need to be added before forwarding. For labeled packets the + bottom of stack is found, the IP header examined. + + Using the terminology defined in [5], an LSR MUST execute the + following algorithm: + + 1. Let N be the number of bytes in the label stack (i.e, 4 times the + number of label stack entries) including labels to be added by + this node. + + 2. Let M be the smaller of the "Maximum Initially Labeled IP Datagram + Size" or of (Path MTU - N). + + When the size of an IPv4 datagram (without labels) exceeds the value + of M, + + If the DF bit is not set in the IPv4 header, then + + (a) the datagram MUST be broken into fragments, each of whose + size is no greater than M, and + + (b) each fragment MUST be labeled and then forwarded. + + If the DF bit is set in the IPv4 header, then + + (a) the datagram MUST NOT be forwarded + + (b) Create an ICMP Destination Unreachable Message: + + i. set its Code field [12] to "Fragmentation Required and + DF Set", + ii. set its Next-Hop MTU field [13] to M + + (c) If possible, transmit the ICMP Destination Unreachable + Message to the source of the of the discarded datagram. + + When the size of an IPv6 datagram (without labels) exceeds the + value of M, + + + + +Awduche, et al. Standards Track [Page 14] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + (a) the datagram MUST NOT be forwarded + + (b) Create an ICMP Packet too Big Message with the Next-Hop + link MTU field [14] set to M + + (c) If possible, transmit the ICMP Packet too Big Message to + the source of the of the discarded datagram. + +3. LSP Tunnel related Message Formats + + Five new objects are defined in this section: + + 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 + specification. + + The LABEL and RECORD_ROUTE objects, are sender specific. In Resv + messages they MUST appear after the associated FILTER_SPEC and prior + to any subsequent FILTER_SPEC. + + The relative 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: + + ::= [ ] + + + [ ] + + [ ] + + + +Awduche, et al. Standards Track [Page 15] + +RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 + + + [ ... ] + + + ::= + [ ] + [ ] + +3.2. Resv Message + + The format of the Resv message is as follows: + + ::= [ ] + + + [ ] [ ] + [ ... ] +