idnits 2.17.1 draft-ietf-mpls-rsvp-lsp-tunnel-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 75 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 54 has weird spacing: '... routed away ...' == Line 226 has weird spacing: '... can be contr...' == Line 232 has weird spacing: '...traffic trave...' == Line 312 has weird spacing: '...ow with a...' == Line 313 has weird spacing: '...ticular desti...' == (70 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2000) is 8686 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'M' on line 2240 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-06 ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. '3') == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-07 ** Obsolete normative reference: RFC 1349 (ref. '7') (Obsoleted by RFC 2474) ** Obsolete normative reference: RFC 2751 (ref. '9') (Obsoleted by RFC 3181) == Outdated reference: A later version (-02) exists of draft-ietf-mpls-rsvp-tunnel-applicability-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-rsvp-tunnel-applicability (ref. '10') Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Daniel O. Awduche 2 Internet Draft UUNET (MCI Worldcom), Inc. 3 Expiration Date: January 2001 4 Lou Berger 5 LabN Consulting, LLC 7 Der-Hwa Gan 8 Juniper Networks, Inc. 10 Tony Li 11 Procket Networks, Inc. 13 Vijay Srinivasan 14 Cosine Communications, Inc. 16 George Swallow 17 Cisco Systems, Inc. 19 July 2000 21 RSVP-TE: Extensions to RSVP for LSP Tunnels 23 draft-ietf-mpls-rsvp-lsp-tunnel-06.txt 25 Status of this Memo 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of Section 10 of RFC2026. Internet-Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its areas, 30 and its working groups. Note that other groups may also distribute 31 working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 To view the current status of any Internet-Draft, please check the 39 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 40 Directory, see http://www.ietf.org/shadow.html. 42 Abstract 44 This document describes the use of RSVP, including all the necessary 45 extensions, to establish label-switched paths (LSPs) in MPLS. Since 46 the flow along an LSP is completely identified by the label applied 47 at the ingress node of the path, these paths may be treated as 48 tunnels. A key application of LSP tunnels is traffic engineering 49 with MPLS as specified in [3]. 51 We propose several additional objects that extend RSVP, allowing the 52 establishment of explicitly routed label switched paths using RSVP as 53 a signaling protocol. The result is the instantiation of label- 54 switched tunnels which can be automatically routed away from network 55 failures, congestion, and bottlenecks. 57 Contents 59 1 Introduction .......................................... 5 60 1.1 Background ............................................. 6 61 1.2 Terminology ............................................ 7 62 2 Overview .............................................. 9 63 2.1 LSP Tunnels and Traffic Engineered Tunnels ............. 9 64 2.2 Operation of LSP Tunnels ............................... 9 65 2.3 Service Classes ........................................ 12 66 2.4 Reservation Styles ..................................... 12 67 2.4.1 Fixed Filter (FF) Style ................................ 12 68 2.4.2 Wildcard Filter (WF) Style ............................. 12 69 2.4.3 Shared Explicit (SE) Style ............................. 13 70 2.5 Rerouting Traffic Engineered Tunnels ................... 14 71 2.6 Path MTU ............................................... 15 72 3 LSP Tunnel related Message Formats ..................... 16 73 3.1 Path Message ........................................... 17 74 3.2 Resv Message ........................................... 17 75 4 LSP Tunnel related Objects ............................. 18 76 4.1 Label Object ........................................... 18 77 4.1.1 Handling Label Objects in Resv messages ................ 19 78 4.1.2 Non-support of the Label Object ........................ 20 79 4.2 Label Request Object ................................... 21 80 4.2.1 Label Request without Label Range ...................... 21 81 4.2.2 Label Request with ATM Label Range ..................... 21 82 4.2.3 Label Request with Frame Relay Label Range ............. 23 83 4.2.4 Handling of LABEL_REQUEST .............................. 24 84 4.2.5 Non-support of the Label Request Object ................ 24 85 4.3 Explicit Route Object .................................. 25 86 4.3.1 Applicability .......................................... 26 87 4.3.2 Semantics of the Explicit Route Object ................. 26 88 4.3.3 Subobjects ............................................. 27 89 4.3.4 Processing of the Explicit Route Object ................ 30 90 4.3.5 Loops .................................................. 32 91 4.3.6 Forward Compatibility .................................. 32 92 4.3.7 Non-support of the Explicit Route Object ............... 32 93 4.4 Record Route Object .................................... 33 94 4.4.1 Subobjects ............................................. 33 95 4.4.2 Applicability .......................................... 37 96 4.4.3 Handling RRO ........................................... 37 97 4.5 Processing RRO ......................................... 38 98 4.5.1 Loop Detection ......................................... 39 99 4.5.2 Forward Compatibility .................................. 39 100 4.5.3 Non-support of RRO ..................................... 40 101 4.6 Error Codes for ERO and RRO ............................ 40 102 4.7 Session, Sender Template, and Filter Spec Objects ...... 41 103 4.7.1 Session Object ......................................... 41 104 4.7.2 Sender Template Object ................................. 43 105 4.7.3 Filter Specification Object ............................ 44 106 4.7.4 Reroute and Bandwidth Increase Procedure ............... 45 107 4.8 Session Attribute Object ............................... 46 108 4.8.1 Format without resource affinities ..................... 46 109 4.8.2 Format with resource affinities ........................ 48 110 4.8.3 Procedures applying to both C-Types .................... 49 111 4.8.4 Resource Affinity Procedures .......................... 51 112 4.9 Tspec and Flowspec Object for Class-of-Service Service... 52 113 5 Hello Extension ........................................ 54 114 5.1 Hello Message Format ................................... 55 115 5.2 HELLO Object formats ................................... 55 116 5.2.1 HELLO REQUEST object ................................... 55 117 5.2.2 HELLO ACK object ....................................... 56 118 5.3 Hello Message Usage .................................... 56 119 5.4 Multi-Link Considerations .............................. 58 120 5.5 Compatibility .......................................... 58 121 6 Security Considerations ................................ 59 122 7 IANA Considerations .................................... 59 123 8 Intellectual Property Considerations ................... 59 124 9 Acknowledgments ........................................ 60 125 10 References ............................................. 60 126 11 Authors' Addresses ..................................... 61 128 1. Introduction 130 Section 2.9 of the MPLS architecture [2] defines a label distribution 131 protocol as a set of procedures by which one Label Switched Router 132 (LSR) informs another of the meaning of labels used to forward 133 traffic between and through them. The MPLS architecture does not 134 assume a single label distribution protocol. This document is a 135 specification of extensions to RSVP for establishing label switched 136 paths (LSPs) in Multi-protocol Label Switching (MPLS) networks. 138 Several of the new features described in this document were motivated 139 by the requirements for traffic engineering over MPLS (see [3]). In 140 particular, the extended RSVP protocol supports the instantiation of 141 explicitly routed LSPs, with or without resource reservations. It 142 also supports smooth rerouting of LSPs, preemption, and loop 143 detection. 145 The LSPs created with RSVP can be used to carry the "Traffic Trunks" 146 described in [3]. The LSP which carries a traffic trunk and a 147 traffic trunk are distinct though closely related concepts. For 148 example, two LSPs between the same source and destination could be 149 load shared to carry a single traffic trunk. Conversely several 150 traffic trunks could be carried in the same LSP if, for instance, the 151 LSP were capable of carrying several service classes. The 152 applicability of these extensions is discussed further in [10]. 154 Since the traffic that flows along a label-switched path is defined 155 by the label applied at the ingress node of the LSP, these paths can 156 be treated as tunnels, tunneling below normal IP routing and 157 filtering mechanisms. When an LSP is used in this way we refer to it 158 as an LSP tunnel. 160 LSP tunnels allow the implementation of a variety of policies related 161 to network performance optimization. For example, LSP tunnels can be 162 automatically or manually routed away from network failures, 163 congestion, and bottlenecks. Furthermore, multiple parallel LSP 164 tunnels can be established between two nodes, and traffic between the 165 two nodes can be mapped onto the LSP tunnels according to local 166 policy. Although traffic engineering (that is, performance 167 optimization of operational networks) is expected to be an important 168 application of this specification, the extended RSVP protocol can be 169 used in a much wider context. 171 The purpose of this document is to describe the use of RSVP to 172 establish LSP tunnels. The intent is to fully describe all the 173 objects, packet formats, and procedures required to realize 174 interoperable implementations. A few new objects are also defined 175 that enhance management and diagnostics of LSP tunnels. 177 The document also describes a means of rapid node failure detection 178 via a new HELLO message. 180 All objects and messages described in this specification are optional 181 with respect to RSVP. This document discusses what happens when an 182 object described here is not supported by a node. 184 Throughout this document, the discussion will be restricted to 185 unicast label switched paths. Multicast LSPs are left for further 186 study. 188 1.1. Background 190 Hosts and routers that support both RSVP [1] and Multi-Protocol Label 191 Switching [2] can associate labels with RSVP flows. When MPLS and 192 RSVP are combined, the definition of a flow can be made more 193 flexible. Once a label switched path (LSP) is established, the 194 traffic through the path is defined by the label applied at the 195 ingress node of the LSP. The mapping of label to traffic can be 196 accomplished using a number of different criteria. The set of 197 packets that are assigned the same label value by a specific node are 198 said to belong to the same forwarding equivalence class (FEC) (see 199 [2]), and effectively define the "RSVP flow." When traffic is mapped 200 onto a label-switched path in this way, we call the LSP an "LSP 201 Tunnel". When labels are associated with traffic flows, it becomes 202 possible for a router to identify the appropriate reservation state 203 for a packet based on the packet's label value. 205 The signaling protocol model uses downstream-on-demand label 206 distribution. A request to bind labels to a specific LSP tunnel is 207 initiated by an ingress node through the RSVP Path message. For this 208 purpose, the RSVP Path message is augmented with a LABEL_REQUEST 209 object. Labels are allocated downstream and distributed (propagated 210 upstream) by means of the RSVP Resv message. For this purpose, the 211 RSVP Resv message is extended with a special LABEL object. Label 212 stacking is also supported. The procedures for label allocation, 213 distribution, binding, and stacking are described in subsequent 214 sections of this document. 216 The signaling protocol model also supports explicit routing 217 capability. This is accomplished by incorporating a simple 218 EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE 219 object encapsulates a concatenation of hops which constitutes the 220 explicitly routed path. Using this object, the paths taken by label- 221 switched RSVP-MPLS flows can be pre-determined, independent of 222 conventional IP routing. The explicitly routed path can be 223 administratively specified, or automatically computed by a suitable 224 entity based on QoS and policy requirements, taking into 225 consideration the prevailing network state. In general, path 226 computation can be control-driven or data-driven. The mechanisms, 227 processes, and algorithms used to compute explicitly routed paths are 228 beyond the scope of this specification. 230 One useful application of explicit routing is traffic engineering. 231 Using explicitly routed LSPs, a node at the ingress edge of an MPLS 232 domain can control the path through which traffic traverses from 233 itself, through the MPLS network, to an egress node. Explicit 234 routing can be used to optimize the utilization of network resources 235 and enhance traffic oriented performance characteristics. 237 The concept of explicitly routed label switched paths can be 238 generalized through the notion of abstract nodes. An abstract node is 239 a group of nodes whose internal topology is opaque to the ingress 240 node of the LSP. An abstract node is said to be simple if it contains 241 only one physical node. Using this concept of abstraction, an 242 explicitly routed LSP can be specified as a sequence of IP prefixes 243 or a sequence of Autonomous Systems. 245 The signaling protocol model supports the specification of an 246 explicit path as a sequence of strict and loose routes. The 247 combination of abstract nodes, and strict and loose routes 248 significantly enhances the flexibility of path definitions. 250 An advantage of using RSVP to establish LSP tunnels is that it 251 enables the allocation of resources along the path. For example, 252 bandwidth can be allocated to an LSP tunnel using standard RSVP 253 reservations and Integrated Services service classes [4]. 255 While resource reservations are useful, they are not mandatory. 256 Indeed, an LSP can be instantiated without any resource reservations 257 whatsoever. Such LSPs without resource reservations can be used, for 258 example, to carry best effort traffic. They can also be used in many 259 other contexts, including implementation of fall-back and recovery 260 policies under fault conditions, and so forth. 262 1.2. Terminology 264 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 265 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 266 document are to be interpreted as described in RFC2119 [6]. 268 The reader is assumed to be familiar with the terminology in [1], [2] 269 and [3]. 271 Abstract Node 273 A group of nodes whose internal topology is opaque to the 274 ingress node of the LSP. An abstract node is said to be simple 275 if it contains only one physical node. 277 Explicitly Routed LSP 279 An LSP whose path is established by a means other than normal 280 IP routing. 282 Label Switched Path 284 The path created by the concatenation of one or more label 285 switched hops, allowing a packet to be forwarded by swapping 286 labels from an MPLS node to another MPLS node. For a more 287 precise definition see [2]. 289 LSP 290 A Label Switched Path 292 LSP Tunnel 294 An LSP which is used to tunnel below normal IP routing and/or 295 filtering mechanisms. 297 Traffic Engineered Tunnel (TE Tunnel) 299 An set of one or more LSP Tunnels which carries a traffic 300 trunk. 302 Traffic Trunk 304 An set of flows aggregated by their service class and then 305 placed on an LSP or set of LSPs called a traffic engineered 306 tunnel. For further discussion see [3]. 308 2. Overview 310 2.1. LSP Tunnels and Traffic Engineered Tunnels 312 According to [1], "RSVP defines a 'session' to be a data flow with a 313 particular destination and transport-layer protocol." However, when 314 RSVP and MPLS are combined, a flow or session can be defined with 315 greater flexibility and generality. The ingress node of an LSP can 316 use a variety of means to determine which packets are assigned a 317 particular label. Once a label is assigned to a set of packets, the 318 label effectively defines the "flow" through the LSP. We refer to 319 such an LSP as an "LSP tunnel" because the traffic through it is 320 opaque to intermediate nodes along the label switched path. 322 New RSVP SESSION, SENDER, and FILTER_SPEC objects, called 323 LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 have been defined to support the 324 LSP tunnel feature. The semantics of these objects, from the 325 perspective of a node along the label switched path, is that traffic 326 belonging to the LSP tunnel is identified solely on the basis of 327 packets arriving from the PHOP or "previous hop" (see [1]) with the 328 particular label value(s) assigned by this node to upstream senders 329 to the session. In fact, the IPv4(v6) that appears in the object 330 name only denotes that the destination address is an IPv4(v6) 331 address. When we refer to these objects generically, we use the 332 qualifier LSP_TUNNEL. 334 In some applications it is useful to associate sets of LSP tunnels. 335 This can be useful during reroute operations or to spread a traffic 336 trunk over multiple paths. In the traffic engineering application 337 such sets are called traffic engineered tunnels (TE tunnels). To 338 enable the identification and association of such LSP tunnels, two 339 identifiers are carried. A tunnel ID is part of the SESSION object. 340 The SESSION object uniquely defines a traffic engineered tunnel. The 341 SENDER and FILTER_SPEC objects carry an LSP ID. The SENDER (or 342 FILTER_SPEC) object together with the SESSION object uniquely 343 identifies an LSP tunnel 345 2.2. Operation of LSP Tunnels 347 This section summarizes some of the features supported by RSVP as 348 extended by this document related to the operation of LSP tunnels. 349 These include: (1) the capability to establish LSP tunnels with or 350 without QoS requirements, (2) the capability to dynamically reroute 351 an established LSP tunnel, (3) the capability to observe the actual 352 route traversed by an established LSP tunnel, (4) the capability to 353 identify and diagnose LSP tunnels, (5) the capability to preempt an 354 established LSP tunnel under administrative policy control, and (6) 355 the capability to perform downstream-on-demand label allocation, 356 distribution, and binding. In the following paragraphs, these 357 features are briefly described. More detailed descriptions can be 358 found in subsequent sections of this document. 360 To create an LSP tunnel, the first MPLS node on the path -- that is, 361 the sender node with respect to the path -- creates an RSVP Path 362 message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and 363 inserts a LABEL_REQUEST object into the Path message. The 364 LABEL_REQUEST object indicates that a label binding for this path is 365 requested and also provides an indication of the network layer 366 protocol that is to be carried over this path. The reason for this is 367 that the network layer protocol sent down an LSP cannot be assumed to 368 be IP and cannot be deduced from the L2 header, which simply 369 identifies the higher layer protocol as MPLS. 371 If the sender node has knowledge of a route that has high likelihood 372 of meeting the tunnel's QoS requirements, or that makes efficient use 373 of network resources, or that satisfies some policy criteria, the 374 node can decide to use the route for some or all of its sessions. To 375 do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP 376 Path message. The EXPLICIT_ROUTE object specifies the route as a 377 sequence of abstract nodes. 379 If, after a session has been successfully established and the sender 380 node discovers a better route, the sender can dynamically reroute the 381 session by simply changing the EXPLICIT_ROUTE object. If problems 382 are encountered with an EXPLICIT_ROUTE object, either because it 383 causes a routing loop or because some intermediate routers do not 384 support it, the sender node is notified. 386 By adding a RECORD_ROUTE object to the Path message, the sender node 387 can receive information about the actual route that the LSP tunnel 388 traverses. The sender node can also use this object to request 389 notification from the network concerning changes to the routing path. 390 The RECORD_ROUTE object is analogous to a path vector, and hence can 391 be used for loop detection. 393 Finally, a SESSION_ATTRIBUTE object can be added to Path messages to 394 aid in session identification and diagnostics. Additional control 395 information, such as setup and hold priorities, resource affinities 396 (see [3]), and local-protection, are also included in this object. 398 The setup and hold priorities may be used along with SENDER_TSPEC and 399 any POLICY_DATA objects contained in Path messages as input to their 400 policy control. For instance, in the traffic engineering 401 application, it is very useful to use the Path message as a means of 402 verifying that bandwidth exists at a particular priority along an 403 entire path before pre-empting any lower priority reservations. If a 404 Path message is allowed to progress when there are insufficient 405 resources, the there is a danger that lower priority reservations 406 downstream of this point will unnecessarily be pre-empted in a futile 407 attempt to service this request. 409 When the EXPLICIT_ROUTE object (ERO) is present, the Path message is 410 forwarded towards its destination along a path specified by the ERO. 411 Each node along the path records the ERO in its path state block. 412 Nodes may also modify the ERO before forwarding the Path message. In 413 this case the modified ERO SHOULD be stored in the path state block 414 in addition to the received ERO. 416 The LABEL_REQUEST object requests intermediate routers and receiver 417 nodes to provide a label binding for the session. If a node is 418 incapable of providing a label binding, it sends a PathErr message 419 with an "unknown object class" error. If the LABEL_REQUEST object is 420 not supported end to end, the sender node will be notified by the 421 first node which does not provide this support. 423 The destination node of a label-switched path responds to a 424 LABEL_REQUEST by including a LABEL object in its response RSVP Resv 425 message. The LABEL object is inserted in the filter spec list 426 immediately following the filter spec to which it pertains. 428 The Resv message is sent back upstream towards the sender, following 429 the path state created by the Path message, in reverse order. Note 430 that if the path state was created by use of an ERO, then the Resv 431 message will follow the reverse path of the ERO. 433 Each node that receives a Resv message containing a LABEL object uses 434 that label for outgoing traffic associated with this LSP tunnel. If 435 the node is not the sender, it allocates a new label and places that 436 label in the corresponding LABEL object of the Resv message which it 437 sends upstream to the PHOP. The label sent upstream in the LABEL 438 object is the label which this node will use to identify incoming 439 traffic associated with this LSP tunnel. This label also serves as 440 shorthand for the Filter Spec. The node can now update its "Incoming 441 Label Map" (ILM), which is used to map incoming labeled packets to a 442 "Next Hop Label Forwarding Entry" (NHLFE), see [2]. 444 When the Resv message propagates upstream to the sender node, a 445 label-switched path is effectively established. 447 2.3. Service Classes 449 This document does not restrict the type of Integrated Service 450 requests for reservations. However, an implementation should support 451 the Controlled-Load service [4] and the Class-of-Service service, see 452 Section 4.8. 454 2.4. Reservation Styles 456 The receiver node can select from among a set of possible reservation 457 styles for each session, and each RSVP session must have a particular 458 style. Senders have no influence on the choice of reservation style. 459 The receiver can choose different reservation styles for different 460 LSPs. 462 An RSVP session can result in one or more LSPs, depending on the 463 reservation style chosen. 465 Some reservation styles, such as FF, dedicate a particular 466 reservation to an individual sender node. Other reservation styles, 467 such as WF and SE, can share a reservation among several sender 468 nodes. The following sections discuss the different reservation 469 styles and their advantages and disadvantages. A more detailed 470 discussion of reservation styles can be found in [1]. 472 2.4.1. Fixed Filter (FF) Style 474 The Fixed Filter (FF) reservation style creates a distinct 475 reservation for traffic from each sender that is not shared by other 476 senders. This style is common for applications in which traffic from 477 each sender is likely to be concurrent and independent. The total 478 amount of reserved bandwidth on a link for sessions using FF is the 479 sum of the reservations for the individual senders. 481 Because each sender has its own reservation, a unique label is 482 assigned to each sender. This can result in a point-to-point LSP 483 between every sender/receiver pair. 485 2.4.2. Wildcard Filter (WF) Style 487 With the Wildcard Filter (WF) reservation style, a single shared 488 reservation is used for all senders to a session. The total 489 reservation on a link remains the same regardless of the number of 490 senders. 492 A single multipoint-to-point label-switched-path is created for all 493 senders to the session. On links that senders to the session share, a 494 single label value is allocated to the session. If there is only one 495 sender, the LSP looks like a normal point-to-point connection. When 496 multiple senders are present, a multipoint-to-point LSP (a reversed 497 tree) is created. 499 This style is useful for applications in which not all senders send 500 traffic at the same time. A phone conference, for example, is an 501 application where not all speakers talk at the same time. If, 502 however, all senders send simultaneously, then there is no means of 503 getting the proper reservations made. Either the reserved bandwidth 504 on links close to the destination will be less than what is required 505 or then the reserved bandwidth on links close to some senders will be 506 greater than what is required. This restricts the applicability of 507 WF for traffic engineering purposes. 509 Furthermore, because of the merging rules of WF, EXPLICIT_ROUTE 510 objects cannot be used with WF reservations. As a result of this 511 issue and the lack of applicability to traffic engineering, use of WF 512 is not considered in this document. 514 2.4.3. Shared Explicit (SE) Style 516 The Shared Explicit (SE) style allows a receiver to explicitly 517 specify the senders to be included in a reservation. There is a 518 single reservation on a link for all the senders listed. Because 519 each sender is explicitly listed in the Resv message, different 520 labels may be assigned to different senders, thereby creating 521 separate LSPs. 523 SE style reservations can be provided using multipoint-to-point 524 label-switched-path or LSP per sender. Multipoint-to-point LSPs may 525 be used when path messages do not carry the EXPLICIT_ROUTE object, or 526 when Path messages have identical EXPLICIT_ROUTE objects. In either 527 of these cases a common label may be assigned. 529 Path messages from different senders can each carry their own ERO, 530 and the paths taken by the senders can converge and diverge at any 531 point in the network topology. When Path messages have differing 532 EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object 533 must be established. 535 2.5. Rerouting Traffic Engineered Tunnels 537 One of the requirements for Traffic Engineering is the capability to 538 reroute an established TE tunnel under a number of conditions, based 539 on administrative policy. For example, in some contexts, an 540 administrative policy may dictate that a given TE tunnel is to be 541 rerouted when a more "optimal" route becomes available. Another 542 important context when TE tunnel reroute is usually required is upon 543 failure of a resource along the TE tunnel's established path. Under 544 some policies, it may also be necessary to return the TE tunnel to 545 its original path when the failed resource becomes re-activated. 547 In general, it is highly desirable not to disrupt traffic, or 548 adversely impact network operations while TE tunnel rerouting is in 549 progress. This adaptive and smooth rerouting requirement 550 necessitates establishing a new LSP tunnel and transferring traffic 551 from the old LSP tunnel onto it before tearing down the old LSP 552 tunnel. This concept is called "make-before-break." A problem can 553 arise because the old and new LSP tunnels might compete with other 554 for resources on network segments which they have in common. 555 Depending on availability of resources, this competition can cause 556 Admission Control to prevent the new LSP tunnel from being 557 established. An advantage of using RSVP to establish LSP tunnels is 558 that it solves this problem very elegantly. 560 To support make-before-break in a smooth fashion, it is necessary 561 that on links that are common to the old and new LSPs, resources used 562 by the old LSP tunnel should not be released before traffic is 563 transitioned to the new LSP tunnel, and reservations should not be 564 counted twice because this might cause Admission Control to reject 565 the new LSP tunnel. 567 A similar situation arises when one wants to increase the bandwidth 568 of a TE tunnel. The new reservation will be for the full amount 569 needed, but the actual allocation needed is only the delta between 570 the new and old bandwidth. 572 The combination of the LSP_TUNNEL SESSION object and the SE 573 reservation style naturally accommodates smooth transitions in 574 bandwidth and routing. The idea is that the old and new LSP tunnels 575 share resources along links which they have in common. The LSP_TUNNEL 576 SESSION object is used to narrow the scope of the RSVP session to the 577 particular TE tunnel in question. To uniquely identify a TE tunnel, 578 we use the combination of the destination IP address (an address of 579 the node which is the egress of the tunnel), a Tunnel ID, and the 580 tunnel ingress node's IP address, which is placed in the Extended 581 Tunnel ID field. 583 During the reroute or bandwidth-increase operation, the tunnel 584 ingress needs to appear as two different senders to the RSVP session. 585 This is achieved by the inclusion of the "LSP ID", which is carried 586 in the SENDER_TEMPLATE and FILTER_SPEC objects. Since the semantics 587 of these objects are changed, a new C-Types are assigned. 589 To effect a reroute, the ingress node picks a new LSP ID and forms a 590 new SENDER_TEMPLATE. The ingress node then creates a new ERO to 591 define the new path. Thereafter the node sends a new Path Message 592 using the original SESSION object and the new SENDER_TEMPLATE and 593 ERO. It continues to use the old LSP and refresh the old Path 594 message. On links that are not held in common, the new Path message 595 is treated as a conventional new LSP tunnel setup. On links held in 596 common, the shared SESSION object and SE style allow the LSP to be 597 established sharing resources with the old LSP. Once the ingress 598 node receives a Resv message for the new LSP, it can transition 599 traffic to it and tear down the old LSP. 601 To effect a bandwidth-increase, a new Path Message with a new LSP_ID 602 can be used to attempt a larger bandwidth reservation while the 603 current LSP_ID continues to be refreshed to ensure that the 604 reservation is not lost if the larger reservation fails. 606 2.6. Path MTU 608 Standard RSVP [1] and Int-Serv [11] provide the RSVP sender with the 609 minimum MTU available between the sender and the receiver. This path 610 MTU identification capability is also provided for LSPs established 611 via RSVP. 613 Path MTU information is carried, depending on which is present, in 614 the Integrated Services or Class-of-Service objects. When using 615 Integrated Services objects, path MTU is provided based on the 616 procedures defined in [11]. Path MTU identification when using 617 Class-of-Service objects is defined in Section 4.8. 619 With standard RSVP, the path MTU information is used by the sender to 620 check which IP packets exceed the path MTU. For packets that exceed 621 the path MTU, the sender either fragments the packets or, when the IP 622 datagram has the "Don't Fragment" bit set, issues an ICMP destination 623 unreachable message. This path MTU related handling is also required 624 for LSPs established via RSVP. 626 The following algorithm applies to all unlabeled IP datagrams and to 627 any labeled packets which the node knows to be IP datagrams, to which 628 labels need to be added before forwarding. For labeled packets the 629 bottom of stack is found, the IP header examined. 631 Using the terminology defined in [5], an LSR MUST execute the 632 following algorithm: 634 1. Let N be the number of bytes in the label stack (i.e, 4 times 635 the number of label stack entries) including labels to be added 636 by this node. 638 2. Let M be the smaller of the "Maximum Initially Labeled IP 639 Datagram Size" or of (Path MTU - N). 641 When the size of the datagram (without labels) exceeds the value 642 of M, 644 If the DF bit is not set in the IP header, then 646 (a) the datagram must be broken into fragments, each of whose 647 size is no greater than the value of the parameter, and 649 (b) each fragment must be labeled and then forwarded. 651 If the DF bit is set in the IP header, then 653 (a) the datagram MUST NOT be forwarded 655 (b) Create an ICMP Destination Unreachable Message: 656 i. set its Code field [12] to "Fragmentation Required 657 and DF Set", 658 ii. set its Next-Hop MTU field [13] to M 660 (c) If possible, transmit the ICMP Destination Unreachable 661 Message to the source of the of the discarded datagram. 663 3. LSP Tunnel related Message Formats 665 Five new objects are defined in this section: 667 Object name Applicable RSVP messages 668 --------------- ------------------------ 669 LABEL_REQUEST Path 670 LABEL Resv 671 EXPLICIT_ROUTE Path 672 RECORD_ROUTE Path, Resv 673 SESSION_ATTRIBUTE Path 675 New C-Types are also assigned for the SESSION, SENDER_TEMPLATE, 676 FILTER_SPEC, FLOWSPEC objects. 678 Detailed descriptions of the new objects are given in later sections. 679 All new objects are OPTIONAL with respect to RSVP. An implementation 680 can choose to support a subset of objects. However, the 681 LABEL_REQUEST and LABEL objects are mandatory with respect to this 682 specification. 684 The LABEL and RECORD_ROUTE objects, are sender specific. In Resv 685 messages they MUST appear after the associated FILTER_SPEC and prior 686 to any subsequent FILTER_SPEC. 688 The relative placement of EXPLICIT_ROUTE, LABEL_REQUEST, and 689 SESSION_ATTRIBUTE objects is simply a recommendation. The ordering 690 of these objects is not important, so an implementation MUST be 691 prepared to accept objects in any order. 693 3.1. Path Message 695 The format of the Path message is as follows: 697 ::= [ ] 698 699 [ ] 700 [ ] 701 702 [ ] 703 [ ... ] 704 706 ::= 707 [ ] 708 [ ] 710 3.2. Resv Message 712 The format of the Resv message is as follows: 714 ::= [ ] 715 716 [ ] 717 [ ] [ ] 718 [ ... ] 719