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