idnits 2.17.1 draft-ietf-mpls-rsvp-lsp-tunnel-04.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 50 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 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 56 has weird spacing: '... routed away ...' == Line 206 has weird spacing: '... can be contr...' == Line 213 has weird spacing: '...traffic trave...' == Line 664 has weird spacing: '...e shown below...' == Line 665 has weird spacing: '... three possi...' == (41 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 1999) is 8989 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 1807 == Unused Reference: '6' is defined on line 2057, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-04 == Outdated reference: A later version (-01) exists of draft-ietf-mpls-traffic-eng-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-traffic-eng (ref. '3') == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-03 ** Obsolete normative reference: RFC 1349 (ref. '7') (Obsoleted by RFC 2474) Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Daniel O. Awduche 2 Internet Draft UUNET (MCI Worldcom), Inc. 3 Expiration Date: March 2000 4 Lou Berger 5 LabN Consulting 7 Der-Hwa Gan 8 Juniper Networks, Inc. 10 Tony Li 11 Procket Networks, Inc. 13 George Swallow 14 Cisco Systems, Inc. 16 Vijay Srinivasan 17 Torrent Networks, Inc. 19 September 1999 21 Extensions to RSVP for LSP Tunnels 23 draft-ietf-mpls-rsvp-lsp-tunnel-04.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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Abstract 46 This document describes the use of RSVP, including all the necessary 47 extensions, to establish label-switched paths (LSPs) in MPLS. Since 48 the flow along an LSP is completely identified by the label applied 49 at the ingress node of the path, these paths may be treated as 50 tunnels. A key application of LSP tunnels is traffic engineering 51 with MPLS as specified in [3]. 53 We propose several additional objects that extend RSVP, allowing the 54 establishment of explicitly routed label switched paths using RSVP as 55 a signaling protocol. The result is the instantiation of label- 56 switched tunnels which can be automatically routed away from network 57 failures, congestion, and bottlenecks. 59 Contents 61 1 Introduction and Background ............................ 5 62 1.1 Introduction ........................................... 5 63 1.2 Background ............................................. 6 64 2 Overview .............................................. 7 65 2.1 LSP Tunnels ............................................ 7 66 2.2 Operation of LSP Tunnels ............................... 8 67 2.3 Service Classes ........................................ 10 68 2.4 Reservation Styles ..................................... 10 69 2.4.1 Fixed Filter (FF) Style ................................ 10 70 2.4.2 Wildcard Filter (WF) Style ............................. 10 71 2.4.3 Shared Explicit (SE) Style ............................. 11 72 2.5 Rerouting LSP Tunnels .................................. 12 73 3 LSP Tunnel related Message Formats ..................... 13 74 3.1 Path Message ........................................... 14 75 3.2 Resv Message ........................................... 14 76 4 LSP Tunnel related Objects ............................. 15 77 4.1 Label Object ........................................... 15 78 4.1.1 Handling Label Objects in Resv messages ................ 16 79 4.1.2 Non-support of the Label Object ........................ 16 80 4.2 Label Request Object ................................... 17 81 4.2.1 Handling of LABEL_REQUEST .............................. 20 82 4.2.2 Non-support of the Label Request Object ................ 21 83 4.3 Explicit Route Object .................................. 21 84 4.3.1 Applicability .......................................... 22 85 4.3.2 Semantics of the Explicit Route Object ................. 22 86 4.3.3 Subobjects ............................................. 23 87 4.3.4 Processing of the Explicit Route Object ................ 27 88 4.3.5 Loops .................................................. 29 89 4.3.6 Non-support of the Explicit Route Object ............... 29 90 4.4 Record Route Object .................................... 29 91 4.4.1 Subobjects ............................................. 30 92 4.4.2 Applicability .......................................... 33 93 4.4.3 Handling RRO ........................................... 33 94 4.4.4 Loop Detection ......................................... 34 95 4.4.5 Non-support of RRO ..................................... 35 96 4.5 Error Codes for ERO and RRO ............................ 35 97 4.6 Session, Sender Template, and Filter Spec Objects ...... 36 98 4.6.1 Session Object ......................................... 37 99 4.6.2 Sender Template Object ................................. 37 100 4.6.3 Filter Specification Object ............................ 38 101 4.6.4 Reroute Procedure ...................................... 38 102 4.7 Session Attribute Object ............................... 39 103 4.8 Tspec and Flowspec Object for Class-of-Service Service ....42 104 5 Hello Extension ........................................ 43 105 5.1 Hello Message Format ................................... 44 106 5.2 HELLO Object ........................................... 45 107 5.3 Hello Message Usage .................................... 46 108 5.4 Multi-Link Considerations .............................. 47 109 5.5 Compatibility .......................................... 47 110 6 Security Considerations ................................ 47 111 7 Intellectual Property Considerations ................... 48 112 8 Acknowledgments ........................................ 48 113 9 References ............................................. 48 114 10 Authors' Addresses ..................................... 49 116 1. Introduction and Background 118 1.1. Introduction 120 Section 2.9 of the MPLS architecture [2] defines a label distribution 121 protocol as a set of procedures by which one Label Switched Router 122 (LSR) informs another of the meaning of labels used to forward 123 traffic between and through them. The MPLS architecture does not 124 assume a single label distribution protocol. This document is a 125 specification of extensions to RSVP for establishing label switched 126 paths (LSPs) in Multi-protocol Label Switching (MPLS) networks. 128 Several of the new features described in this document were motivated 129 by the requirements for traffic engineering over MPLS (see [3]). In 130 particular, the extended RSVP protocol supports the instantiation of 131 explicitly routed LSPs, with or without resource reservations. It 132 also supports smooth rerouting of LSPs, preemption, and loop 133 detection. 135 Since the traffic that flows along a label-switched path is defined 136 by the label applied at the ingress node of the LSP, these paths can 137 be treated as tunnels. When an LSP is used in this way we refer to 138 it as an LSP tunnel. 140 LSP tunnels allow the implementation of a variety of policies related 141 to network performance optimization. For example, LSP tunnels can be 142 automatically or manually routed away from network failures, 143 congestion, and bottlenecks. Furthermore, multiple parallel LSP 144 tunnels can be established between two nodes, and traffic between the 145 two nodes can be mapped onto the LSP tunnels according to local 146 policy. Although traffic engineering (that is, performance 147 optimization of operational networks) is expected to be an important 148 application of this specification, the extended RSVP protocol can be 149 used in a much wider context. 151 The purpose of this document is to describe the use of RSVP to 152 establish LSP tunnels. The intent is to fully describe all the 153 objects, packet formats, and procedures required to realize 154 interoperable implementations. A few new objects are also defined 155 that enhance management and diagnostics of LSP tunnels. 157 The document also describes a means of rapid node failure detection 158 via a new HELLO message. 160 All objects and messages described in this specification are optional 161 with respect to RSVP. This document discusses what happens when an 162 object described here is not supported by a node. 164 Throughout this document, the discussion will be restricted to 165 unicast label switched paths. Multicast LSPs are left for further 166 study. 168 1.2. Background 170 Hosts and routers that support both RSVP [1] and Multi-Protocol Label 171 Switching [2] can associate labels with RSVP flows. When MPLS and 172 RSVP are combined, the definition of a flow can be made more 173 flexible. Once a label switched path (LSP) is established, the 174 traffic through the path is defined by the label applied at the 175 ingress node of the LSP. The mapping of label to traffic can be 176 accomplished using a number of different criteria. The set of 177 packets that are assigned the same label value by a specific node are 178 said to belong to the same forwarding equivalence class (FEC) (see 179 [2]), and effectively define the "RSVP flow." When traffic is mapped 180 onto a label-switched path in this way, we call the LSP an "LSP 181 Tunnel". When labels are associated with traffic flows, it becomes 182 possible for a router to identify the appropriate reservation state 183 for a packet based on the packet's label value. 185 The signaling protocol model uses downstream-on-demand label 186 distribution. A request to bind labels to a specific LSP tunnel is 187 initiated by an ingress node through the RSVP Path message. For this 188 purpose, the RSVP Path message is augmented with a LABEL_REQUEST 189 object. Labels are allocated downstream and distributed (propagated 190 upstream) by means of the RSVP Resv message. For this purpose, the 191 RSVP Resv message is extended with a special LABEL object. Label 192 stacking is also supported. The procedures for label allocation, 193 distribution, binding, and stacking are described in subsequent 194 sections of this document. 196 The signaling protocol model also supports explicit routing 197 capability. This is accomplished by incorporating a simple 198 EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE 199 object encapsulates a concatenation of hops which constitutes the 200 explicitly routed path. Using this object, the paths taken by label- 201 switched RSVP-MPLS flows can be pre-determined, independent of 202 conventional IP routing. The explicitly routed path can be 203 administratively specified, or automatically computed by a suitable 204 entity based on QoS and policy requirements, taking into 205 consideration the prevailing network state. In general, path 206 computation can be control-driven or data-driven. The mechanisms, 207 processes, and algorithms used to compute explicitly routed paths are 208 beyond the scope of this specification. 210 One useful application of explicit routing is traffic engineering. 212 Using explicitly routed LSPs, a node at the ingress edge of an MPLS 213 domain can control the path through which traffic traverses from 214 itself, through the MPLS network, to an egress node. Explicit 215 routing can be used to optimize the utilization of network resources 216 and enhance traffic oriented performance characteristics. 218 The concept of explicitly routed label switched paths can be 219 generalized through the notion of abstract nodes. An abstract node is 220 a group of nodes whose internal topology is opaque to the ingress 221 node of the LSP. An abstract node is said to be trivial if it is a 222 singleton, that is if it contains only one physical node. Using this 223 concept of abstraction, an explicitly routed LSP can be specified as 224 a sequence of IP prefixes or a sequence of Autonomous Systems. 226 The signaling protocol model supports the specification of an 227 explicit path as a sequence of strict and loose routes. The 228 combination of abstract nodes, and strict and loose routes 229 significantly enhances the flexibility of path definitions. 231 An advantage of using RSVP to establish LSP tunnels is that it 232 enables the allocation of resources along the path. For example, 233 bandwidth can be allocated to an LSP tunnel using standard RSVP 234 reservations and Integrated Services service classes [4]. 236 While resource reservations are useful, they are not mandatory. 237 Indeed, an LSP can be instantiated without any resource reservations 238 whatsoever. Such LSPs without resource reservations can be used, for 239 example, to carry best effort traffic. They can also be used in many 240 other contexts, including implementation of fall-back and recovery 241 policies under fault conditions, and so forth. 243 2. Overview 245 2.1. LSP Tunnels 247 According to [1], "RSVP defines a 'session' to be a data flow with a 248 particular destination and transport-layer protocol." However, when 249 RSVP and MPLS are combined, a flow or session can be defined with 250 greater flexibility and generality. The ingress node of an LSP can 251 use a variety of means to determine which packets are assigned a 252 particular label. Once a label is assigned to a set of packets, the 253 label effectively defines the "flow" through the LSP. We refer to 254 such an LSP as an "LSP tunnel" because the traffic through it is 255 opaque to intermediate nodes along the label switched path. 257 A new RSVP SESSION object, called LSP_TUNNEL_IPv4, has been defined 258 to support the LSP tunnel feature. The semantics of this object, 259 from the perspective of a node along the label switched path, is that 260 traffic belonging to the LSP tunnel is identified solely on the basis 261 of packets arriving from the PHOP or "previous hop" (see [1]) with 262 the particular label value(s) assigned by this node to upstream 263 senders to the session. In fact, the IPv4 that appears in the object 264 name only denotes that the destination address is an IPv4 address. 266 2.2. Operation of LSP Tunnels 268 This section summarizes some of the features supported by RSVP as 269 extended by this document related to the operation of LSP tunnels. 270 These include: (1) the capability to establish LSP tunnels with or 271 without QoS requirements, (2) the capability to dynamically reroute 272 an established LSP tunnel, (3) the capability to observe the actual 273 route traversed by an established LSP tunnel, (4) the capability to 274 identify and diagnose LSP tunnels, (5) the capability to preempt an 275 established LSP tunnel under administrative policy control, and (6) 276 the capability to perform downstream-on-demand label allocation, 277 distribution, and binding. In the following paragraphs, these 278 features are briefly described. More detailed descriptions can be 279 found in subsequent sections of this document. 281 To create an LSP tunnel, the first MPLS node on the path -- that is, 282 the sender node with respect to the path -- creates an RSVP Path 283 message with a session type of LSP_Tunnel_IPv4 and inserts a 284 LABEL_REQUEST object into the Path message. The LABEL_REQUEST object 285 indicates that a label binding for this path is requested and also 286 provides an indication of the network layer protocol that is to be 287 carried over this path. The reason for this is that the network layer 288 protocol sent down an LSP cannot be assumed to be IPv4 and cannot be 289 deduced from the L2 header, which simply identifies the higher layer 290 protocol as MPLS. 292 If the sender node has knowledge of a route that has high likelihood 293 of meeting the tunnel's QoS requirements, or that makes efficient use 294 of network resources, or that satisfies some policy criteria, the 295 node can decide to use the route for some or all of its sessions. To 296 do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP 297 Path message. The EXPLICIT_ROUTE object specifies the route as a 298 sequence of abstract nodes. 300 If, after a session has been successfully established and the sender 301 node discovers a better route, the sender can dynamically reroute the 302 session by simply changing the EXPLICIT_ROUTE object. If problems 303 are encountered with an EXPLICIT_ROUTE object, either because it 304 causes a routing loop or because some intermediate routers do not 305 support it, the sender node is notified. 307 By adding a RECORD_ROUTE object to the Path message, the sender node 308 can receive information about the actual route that the LSP tunnel 309 traverses. The sender node can also use this object to request 310 notification from the network concerning changes to the routing path. 311 The RECORD_ROUTE object is analogous to a path vector, and hence can 312 be used for loop detection. 314 Finally, a SESSION_ATTRIBUTE object can be added to Path messages to 315 aid in session identification and diagnostics. Additional control 316 information, such as preemption, priority, and local-protection, are 317 also included in this object. 319 When the EXPLICIT_ROUTE object (ERO) is present, the Path message is 320 forwarded towards its destination along a path specified by the ERO. 321 Each node along the path records the ERO in its path state block. 322 Nodes may also modify the ERO before forwarding the Path message. In 323 this case the modified ERO SHOULD be stored in the path state block. 325 The LABEL_REQUEST object requests intermediate routers and receiver 326 nodes to provide a label binding for the session. If a node is 327 incapable of providing a label binding, it sends a PathErr message 328 with an "unknown object class" error. If the LABEL_REQUEST object is 329 not supported end to end, the sender node will be notified by the 330 first node which does not provide this support. 332 The destination node of a label-switched path responds to a 333 LABEL_REQUEST by including a LABEL object in its response RSVP Resv 334 message. The LABEL object is inserted in the filter spec list 335 immediately following the filter spec to which it pertains. 337 The Resv message is sent back upstream towards the sender, in a 338 direction opposite to that followed by the Path message. Each node 339 that receives a Resv message containing a LABEL object uses that 340 label for outgoing traffic associated with this LSP tunnel. If the 341 node is not the sender, it allocates a new label and places that 342 label in the corresponding LABEL object of the Resv message which it 343 sends upstream to the PHOP. The label sent upstream in the LABEL 344 object is the label which this node will use to identify incoming 345 traffic associated with this LSP tunnel. This label also serves as 346 shorthand for the Filter Spec. The node can now update its "Incoming 347 Label Map" (ILM), which is used to map incoming labeled packets to a 348 "Next Hop Label Forwarding Entry" (NHLFE), see [2]. 350 When the Resv message propagates upstream to the sender node, a 351 label-switched path is effectively established. 353 2.3. Service Classes 355 This document does not restrict the type of Integrated Service 356 requests for reservations. However, an implementation should support 357 the Controlled-Load service [4] and the Class-of-Service service, see 358 Section 4.8. 360 2.4. Reservation Styles 362 The receiver node can select from among a set of possible reservation 363 styles for each session, and each RSVP session must have a particular 364 style. Senders have no influence on the choice of reservation style. 365 The receiver can choose different reservation styles for different 366 LSPs. 368 An RSVP session can result in one or more LSPs, depending on the 369 reservation style chosen. 371 Some reservation styles, such as FF, dedicate a particular 372 reservation to an individual sender node. Other reservation styles, 373 such as WF and SE, can share a reservation among several sender 374 nodes. The following sections discuss the different reservation 375 styles and their advantages and disadvantages. A more detailed 376 discussion of reservation styles can be found in [1]. 378 2.4.1. Fixed Filter (FF) Style 380 The Fixed Filter (FF) reservation style creates a distinct 381 reservation for traffic from each sender that is not shared by other 382 senders. This style is common for applications in which traffic from 383 each sender is likely to be concurrent and independent. The total 384 amount of reserved bandwidth on a link for sessions using FF is the 385 sum of the reservations for the individual senders. 387 Because each sender has its own reservation, a unique label and a 388 separate label-switched-path can be assigned to each sender. This 389 can result in a point-to-point LSP between every sender/receiver 390 pair. 392 2.4.2. Wildcard Filter (WF) Style 394 With the Wildcard Filter (WF) reservation style, a single shared 395 reservation is used for all senders to a session. The total 396 reservation on a link remains the same regardless of the number of 397 senders. 399 A single multipoint-to-point label-switched-path is created for all 400 senders to the session. On links that senders to the session share, a 401 single label value is allocated to the session. If there is only one 402 sender, the LSP looks like a normal point-to-point connection. When 403 multiple senders are present, a multipoint-to-point LSP (a reversed 404 tree) is created. 406 This style is useful for applications in which not all senders send 407 traffic at the same time. A phone conference, for example, is an 408 application where not all speakers talk at the same time. If, 409 however, all senders send simultaneously, then there is no means of 410 getting the proper reservations made. Either the reserved bandwidth 411 on links close to the destination will be less than what is required 412 or then the reserved bandwidth on links close to some senders will be 413 greater than what is required. This restricts the applicability of 414 WF for traffic engineering purposes. 416 Furthermore, because of the merging rules of WF, EXPLICIT_ROUTE 417 objects cannot be used with WF reservations. As a result of this 418 issue and the lack of applicability to traffic engineering, use of WF 419 is not considered in this document. 421 2.4.3. Shared Explicit (SE) Style 423 The Shared Explicit (SE) style allows a receiver to explicitly 424 specify the senders to be included in a reservation. There is a 425 single reservation on a link for all the senders listed. Because 426 each sender is explicitly listed in the Resv message, different 427 labels may be assigned to different senders, thereby creating 428 separate LSPs. 430 SE style reservations can be provided using multipoint-to-point 431 label-switched-path or LSP per sender. Multipoint-to-point LSPs may 432 be used when path messages do not carry the EXPLICIT_ROUTE object, or 433 when Path messages have identical EXPLICIT_ROUTE objects. In either 434 of these cases a common label may be assigned. 436 Path messages from different senders can each carry their own ERO, 437 and the paths taken by the senders can converge and diverge at any 438 point in the network topology. When Path messages have differing 439 EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object 440 must be established. 442 2.5. Rerouting LSP Tunnels 444 One of the requirements for Traffic Engineering is the capability to 445 reroute an established LSP tunnel under a number of conditions, based 446 on administrative policy. For example, in some contexts, an 447 administrative policy may dictate that a given LSP tunnel is to be 448 rerouted when a more "optimal" route becomes available. Another 449 important context when LSP tunnel reroute is usually required is upon 450 failure of a resource along the tunnel's established path. Under 451 some policies, it may also be necessary to return the LSP tunnel to 452 its original path when the failed resource becomes re-activated. 454 In general, it is highly desirable not to disrupt traffic, or 455 adversely impact network operations while LSP tunnel rerouting is in 456 progress. This adaptive and smooth rerouting requirement 457 necessitates establishing a new LSP tunnel and transferring traffic 458 from the old LSP tunnel onto it before tearing down the old LSP 459 tunnel. This concept is called "make-before-break." A problem can 460 arise because the old and new LSP tunnels might compete with other 461 for resources on network segments which they have in common. 462 Depending on availability of resources, this competition can cause 463 Admission Control to prevent the new tunnel from being established. 464 An advantage of using RSVP to establish LSP tunnels is that it solves 465 this problem very elegantly. 467 To support make-before-break in a smooth fashion, it is necessary 468 that on links that are common to the old and new LSPs, resources used 469 by the old LSP tunnel should not be released before traffic is 470 transitioned to the new LSP tunnel, and reservations should not be 471 counted twice because this might cause Admission Control to reject 472 the new LSP tunnel. 474 The combination of the LSP_TUNNEL_IPv4 SESSION object and the SE 475 reservation style naturally achieves smooth transitions. The basic 476 idea is that the old and new LSP tunnels share resources along links 477 which they have in common. The LSP_TUNNEL_IPv4 SESSION object is used 478 to narrow the scope of the RSVP session to the particular tunnel in 479 question. To uniquely identify a tunnel, we use the combination of 480 the destination IP address (an address of the node which is the 481 egress of the tunnel), a Tunnel ID, and the tunnel ingress node's IP 482 address, which is placed in the Extended Tunnel ID field. 484 During the reroute operation, the tunnel ingress needs to appear as 485 two different senders to the RSVP session. This is achieved by the 486 inclusion of an "LSP ID", which is carried in the SENDER_TEMPLATE and 487 FILTER_SPEC objects. Since the semantics of these objects are 488 changed, a new C-Type is assigned. 490 To effect a reroute, the ingress node picks a new LSP ID and forms a 491 new SENDER_TEMPLATE. The ingress node then creates a new ERO to 492 define the new path. Thereafter the node sends a new Path Message 493 using the original SESSION object and the new SENDER_TEMPLATE and 494 ERO. It continues to use the old LSP and refresh the old Path 495 message. On links that are not held in common, the new Path message 496 is treated as a conventional new LSP tunnel setup. On links held in 497 common, the shared SESSION object and SE style allow the LSP to be 498 established sharing resources with the old LSP. Once the ingress 499 node receives a Resv message for the new LSP, it can transition 500 traffic to it and tear down the old LSP. 502 3. LSP Tunnel related Message Formats 504 Five new objects are defined in this section: 506 Object name Applicable RSVP messages 507 --------------- ------------------------ 508 LABEL_REQUEST Path 509 LABEL Resv 510 EXPLICIT_ROUTE Path 511 RECORD_ROUTE Path, Resv 512 SESSION_ATTRIBUTE Path 514 New C-Types are also assigned for the SESSION, SENDER_TEMPLATE, 515 FILTER_SPEC, FLOWSPEC objects. 517 Detailed descriptions of the new objects are given in later sections. 518 All new objects are OPTIONAL with respect to RSVP. An implementation 519 can choose to support a subset of objects. However, the 520 LABEL_REQUEST and LABEL objects are mandatory with respect to this 521 specification. 523 The LABEL and RECORD_ROUTE objects, are sender specific. They MUST 524 follow either the SENDER_TEMPLATE in Path messages, or the associated 525 FILTER_SPEC in Resv messages. In Resv messages they MUST appear 526 prior to any subsequent FILTER_SPEC. 528 The relative placement of EXPLICIT_ROUTE, LABEL_REQUEST, and 529 SESSION_ATTRIBUTE objects is simply a recommendation. The ordering 530 of these objects is not important, so an implementation MUST be 531 prepared to accept objects in any order. 533 3.1. Path Message 535 The format of the Path message is as follows: 537 ::= [ ] 538 539 540 [ ] 541 542 [ ] 543 [ ... ] 544 [ ] 546 ::= [ ] 547 [ ] 548 [ ] 550 3.2. Resv Message 552 The format of the Resv message is as follows: 554 ::= [ ] 555 556 557 [ ] [ ] 558 [ ... ] 559