idnits 2.17.1 draft-swallow-mpls-rsvp-trafeng-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 727: '...e and its prior node MUST include only...' RFC 2119 keyword, line 730: '...e and its prior node MAY include other...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 50 has weird spacing: '... routed away ...' == Line 1617 has weird spacing: '... and capab...' -- 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 (August 1998) is 9386 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: 'RFC 2113' on line 1563 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-00 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- No information found for draft-awduche-mpls-traffic-eng - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-01 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS & RSVP Working Groups Daniel Awduche 3 Internet Draft UUNET Technologies, Inc. 4 Expiration Date: February 1999 5 Der-Hwa Gan 6 Juniper Networks, Inc. 8 Tony Li 9 Juniper Networks, Inc. 11 George Swallow 12 Cisco Systems, Inc. 14 Vijay Srinivasan 15 Torrent Networks, Inc. 17 August 1998 19 Extensions to RSVP for Traffic Engineering 21 draft-swallow-mpls-rsvp-trafeng-00.txt 23 Status of this Memo 25 This document is an Internet-Draft. Internet-Drafts are working 26 documents of the Internet Engineering Task Force (IETF), its areas, 27 and its working groups. Note that other groups may also distribute 28 working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 To view the entire list of current Internet-Drafts, please check the 36 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 37 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 38 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 39 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 41 Abstract 43 This document describes the use of RSVP, including all the necessary 44 extensions, to support traffic engineering with MPLS as specified in 45 [6]. 47 We propose several additional objects that extend RSVP, allowing the 48 establishment of explicitly routed label switched paths (LSPs), using 49 RSVP as a signaling protocol. The result is the instantiation of 50 label-switched sessions which can be automatically routed away from 51 network failures, congestion, and bottlenecks. 53 Contents 55 1 Introduction ........................................... 4 56 2 Overview of operation .................................. 5 57 2.1 Service Classes ........................................ 6 58 2.2 Reservation styles ..................................... 6 59 2.2.1 Fixed Filter (FF) style ................................ 7 60 2.2.2 Wildcard Filter (WF) style ............................. 7 61 2.2.3 Shared Explicit (SE) style ............................. 8 62 2.3 LSP Tunnels ............................................ 8 63 2.4 Rerouting LSP Tunnels .................................. 9 64 3 RSVP Message Formats ................................... 10 65 3.1 Path message ........................................... 10 66 3.2 Resv message ........................................... 11 67 4 Objects ................................................ 11 68 4.1 Label Object ........................................... 11 69 4.1.1 Handling Label Objects in Resv messages ................ 12 70 4.1.2 Non-support of the Label Object ........................ 13 71 4.2 Label Request Object ................................... 13 72 4.2.1 Handling of LABEL_REQUEST .............................. 14 73 4.2.2 Non-support of the Label Request Object ................ 14 74 4.3 Explicit Route Object .................................. 15 75 4.3.1 Subobjects ............................................. 15 76 4.3.2 Applicability .......................................... 16 77 4.3.3 Semantics of the Explicit Route Object ................. 16 78 4.3.4 Strict and Loose subobjects ............................ 17 79 4.3.5 Loops .................................................. 18 80 4.3.6 Subobject semantics .................................... 18 81 4.3.7 Processing of the Explicit Route Object ................ 20 82 4.3.8 Non-support of the Explicit Route Object ............... 21 83 4.4 Record Route Object .................................... 22 84 4.4.1 Subobjects ............................................. 22 85 4.4.2 Applicability .......................................... 24 86 4.4.3 Handling RRO ........................................... 25 87 4.4.4 Loop Detection ......................................... 26 88 4.4.5 Non-support of RRO ..................................... 26 89 4.5 Error subcodes for ERO and RRO ......................... 27 90 4.6 Session, Sender Template, and Filter Spec Objects ...... 27 91 4.6.1 Session Object ......................................... 27 92 4.6.2 Sender Template Object ................................. 28 93 4.6.3 Filter Specification Object ............................ 29 94 4.6.4 Reroute procedure ...................................... 29 95 4.7 Session Attribute Object ............................... 30 96 5 RSVP Aggregate Message ................................. 33 97 5.1 Aggregate Header ....................................... 33 98 5.2 Message Formats ........................................ 35 99 5.3 Sending RSVP Aggregate Messages ........................ 35 100 5.4 Receiving RSVP Aggregate Messages ...................... 36 101 5.5 Forwarding RSVP Aggregate Messages ..................... 37 102 5.6 Aggregate-capable bit .................................. 37 103 6 Tear Confirm ........................................... 37 104 7 Security Considerations ................................ 39 105 8 Acknowledgments ........................................ 39 106 9 References ............................................. 39 108 1. Introduction 110 For hosts and routers that support both RSVP [1] and Multi-Protocol 111 Label Switching [2], it is possible to associate labels with RSVP 112 flows [4]. The result is that a router can identify the appropriate 113 reservation state for a packet based on its label value, thus greatly 114 simplifying packet classification. This design also improves network 115 performance because the same label lookup identifies forwarding 116 information of the packet. 118 Using RSVP to establish label switched paths (LSPs) clearly enables 119 the allocation of resources to an LSP. For example, you can allocate 120 bandwidth to an LSP using standard RSVP reservations and Integrated 121 Services service classes [7]. While this is useful, reservations are 122 not required. An LSP can also be established to carry best-effort 123 traffic without a resource reservation. 125 It is possible to add explicit routing capability on top of label- 126 switched RSVP flows [3] [5] by adding a simple EXPLICIT_ROUTE object 127 to RSVP. By using this object, the paths taken by label-switched 128 RSVP flows can be predetermined, independent of conventional IP 129 routing. The hops in the path can be manually configured, or 130 computed automatically based on the QoS requirements of the flow and 131 the current network load. 133 The purpose of this document is to organize all the objects from [3], 134 [4], and [5] into a single document that fully describes all the 135 procedures and packet formats so that interoperable implementations 136 are possible. A few new objects are also suggested for enhancing 137 management and diagnostics of LSPs. All objects described are 138 optional, and this document describes what happens when an object is 139 not supported by a node. 141 Finally, an RSVP aggregate message is proposed to help alleviate one 142 of the RSVP scaling issues: how to efficiently handle large number of 143 RSVP messages that are periodically transmitted between neighbors. 145 The document concentrates on unicast LSPs. Explicitly routed 146 multicast LSPs are left for further study. 148 2. Overview of operation 150 When an RSVP flow originates in or crosses an MPLS domain, the flow 151 may be label switched. To initiate label switching, the first MPLS 152 node inserts a LABEL_REQUEST object into the Path message. The 153 LABEL_REQUEST object indicates that a label binding for this path is 154 requested, and also provides an indication of the network layer 155 protocol that is to be carried over this path. The reason for this is 156 that the network layer protocol sent down an LSP cannot be assumed to 157 be IPv4, and cannot be deduced from the L2 header, which simply 158 identifies the higher layer protocol as being MPLS. 160 If the sender node has prior knowledge of an alternative route that 161 has better likelihood of meeting the flow's QoS requirement or that 162 makes more efficient use of network resources, the node can decide to 163 reroute some of its sessions. To do this, the node adds an 164 EXPLICIT_ROUTE object to the Path message. 166 If, during a session, the sender node finds a better route, the 167 session can be rerouted on the fly by simply changing the 168 EXPLICIT_ROUTE object. If there are problems with an EXPLICIT_ROUTE 169 object, either because it causes a routing loop or some intermediate 170 routers do not support it, the sender node is notified. 172 If the RECORD_ROUTE object is added to Path messages, the sender node 173 can receive information about the exact routing path and can prompt 174 for notifications from the network if the routing path changes for 175 any reason. 177 Finally, a SESSION_ATTRIBUTE object can be added to Path messages for 178 aiding in session identification and diagnostics. Additional control 179 information, such as preemption, priority, and fast-reroute, is also 180 included in this object. 182 When the EXPLICIT_ROUTE object (ERO) is present, the Path message is 183 forwarded towards its destination along a path specified by the ERO. 184 Each node along the path records the ERO in its path state block. 185 Nodes may also modify the ERO before forwarding the Path message, in 186 which case the modified ERO should be stored in the path state block. 188 The LABEL_REQUEST object requests intermediate routers and receiving 189 nodes to provide a label binding for the session. If a node is 190 incapable of providing a label binding it sends a PathErr message 191 with an "unknown object class" error. If the LABEL_REQUEST object is 192 not supported end to end, the sender node will be notified by the 193 first node which lacks the support. 195 The destination node includes a LABEL object in its response Resv 196 message. The LABEL object is inserted in the filter spec list 197 immediately following the filter spec to which it pertains. When the 198 LABEL object propagates upstream to the sender node, a label-switched 199 path is already set up for use. 201 The Resv message is sent back towards the sender. A node that 202 receives a Resv message containing a label uses that label for 203 outgoing traffic on this path. It also allocates a new label and 204 places that label in the corresponding LABEL object of the Resv 205 message before sending it upstream. This is the label that this node 206 will use for incoming traffic on this path. This label now serves as 207 shorthand for the Filter Spec. 209 2.1. Service Classes 211 This document does not restrict the type of Integrated Service 212 requested on a reservations. However, an implementation should 213 always be ready to accept the Controlled-Load service [7]. 215 An LSP may not need a bandwidth reservation or a QoS guarantee. Such 216 LSPs can be used to deliver best-effort traffic, even if RSVP is used 217 for setting up LSPs. When no resources need to be allocated to the 218 LSP, the Sender_TSpec in the Path message can specify a token bucket 219 rate of zero and a token bucket size of zero. The corresponding 220 FLOWSPEC (in the Resv message) should carry a zero rate and size as 221 well. LSPs with no bandwidth reservation are not subject to 222 Admission Control and do not require traffic policing. 224 2.2. Reservation styles 226 The receiver node can select from among a set of possible reservation 227 styles for each session, and each RSVP session must have a particular 228 style. Senders have no influence on the choice of reservation style. 229 The receiver can choose different reservation styles for different 230 LSPs. An RSVP session is identified by a unique (destination 231 address, protocol, destination port) tuple. 233 An RSVP session can create one or more LSPs, depending on the 234 reservation style chosen. 236 Some reservation styles, such as FF, dedicate a particular 237 reservation to an individual sender node. Other reservation styles, 238 such as WF and SE, can share a reservation among several sender 239 nodes. The following sections discuss the different reservation 240 styles and their advantages and disadvantages. 242 2.2.1. Fixed Filter (FF) style 244 The Fixed Filter (FF) reservation style creates a distinct 245 reservation for traffic from each sender that is not shared by other 246 senders. This style is common for applications in which traffic from 247 each sender is likely to be concurrent and independent. The total 248 amount of reserved bandwidth on a link for sessions using FF is the 249 sum of the reservations for the individual senders. 251 Because each sender has its own reservation, a unique label and a 252 separate label-switched-path is assigned to each sender. This 253 results in a point-to-point LSP between every sender/receiver pair. 255 Because the network state overhead is proportional to the number of 256 LSPs, having more LSPs means that more network resources are 257 consumed. 259 2.2.2. Wildcard Filter (WF) style 261 With the Wildcard Filter (WF) reservation style, a single shared 262 reservation is used for all senders. The total reservation on a link 263 remains the same regardless of the number of senders. This style is 264 useful in applications in which not all senders send traffic at the 265 same time. A phone conference, for example, is an application where 266 not all speakers talk at the same time. 268 A single label-switched-path is created for all senders, because all 269 senders to the session are covered by the reservation. On links that 270 senders share, a single label is allocated. If there is only one 271 sender, the LSP looks like normal point-to-point connection. When 272 multiple senders are present, a multipoint-to-point LSP (a reversed 273 tree) is created. This has the advantage of minimizing the number of 274 LSPs (and the memory and CPU resources used for each LSP), allowing 275 the network to scale better. 277 Because of the merging rules, EXPLICIT_ROUTE objects cannot be used 278 with WF reservations. Hence, the use of the WF style should be 279 discouraged in the presence of ERO. 281 2.2.3. Shared Explicit (SE) style 283 Unlike the WF style, where any sender is allowed to share the 284 reservation, the Shared Explicit (SE) style allows a receiver to 285 explicitly specify the senders to be included. There is a single 286 reservation on a link for all the senders listed. 288 Only listed senders can join the reservation. 290 Because each sender is explicitly listed in the Resv message, you can 291 assign separate labels to each sender, therefore creating separate 292 LSPs for each sender. [4] describes the reason why separate LSPs are 293 needed. 295 Having separate LSPs for each sender also eliminates the 296 incompatibility with the EXPLICIT_ROUTE object. Path messages from 297 different senders can carry their own ERO, and the paths taken by the 298 senders can converge and diverge at any point. 300 Unlike the FF style, all SE LSPs share the single reservation. 301 Unlike the WF style, a separate LSP is created for each sender. 303 2.3. LSP Tunnels 305 When LSPs are used to carry flows, it becomes possible to be more 306 flexible in the definition of a flow. The first node in an LSP can 307 use any of a variety of means to determine which packets will be 308 assigned a particular label. Once that label is assigned, the label 309 becomes the definition of the flow. We refer to such an LSP as an 310 LSP Tunnel due to the opaque nature of the flow. 312 In support of this, a new SESSION object, LSP_TUNNEL_IPv4 is defined. 313 The semantics of this object are that the flow is defined solely on 314 the basis of packets arriving from the PHOP with the particular label 315 value(s) assigned by this node to senders to the session. In fact, 316 the IPv4 appearing in the object name only denotes that the 317 destination address is an IPv4 address. 319 An application of particular interest is traffic engineering. By 320 establishing ER-LSPs a node at the edge of an MPLS domain can control 321 the path which traffic from this node will take through that domain. 322 These capabilities can be used to optimize the utilization of network 323 resources and enhance traffic oriented performance characteristics. 325 2.4. Rerouting LSP Tunnels 327 One of the requirements for Traffic Engineering is the ability to 328 have an LSP tunnel re-routed upon a failure of a resource along its 329 current path. A further requirement is the ability to have the LSP 330 tunnel return to its original path when the failed resource is 331 restored. 333 It is also desirable not to disrupt traffic while rerouting is in 334 progress. The adaptive rerouting requirement calls for establishing 335 a new LSP while keeping the old LSP intact. 337 On links that old and new LSPs share, one wishes to (1) not release 338 resources from the old LSP that one wants to use for the new LSP, and 339 (2) not double-count reservations, because this might cause Admission 340 Control to deny the new LSP. 342 The combination of the LSP_TUNNEL_IPv4 SESSION object and the SE 343 reservation style naturally achieves smooth transitions. The 344 LSP_TUNNEL_IPv4 SESSION object is used to narrow the scope of the 345 RSVP session to the particular tunnel in question. To uniquely 346 identify a tunnel we use the combination of the destination IP 347 address, a Tunnel ID, and the sender's IP address which is placed in 348 the Extended Tunnel ID field. 350 During the reroute operation, the source needs to be able to appear 351 as two different sources to RSVP. This is achieved by the use of a 352 "LSP ID", which is carried in the SENDER_TEMPLATE and FILTER_SPEC 353 objects. Since the semantics of these objects is changed, a new C- 354 Type is assigned. 356 To effect a reroute, the source node picks a new LSP ID and forms a 357 new SENDER_TEMPLATE. It creates a new ERO to define the new path. 358 The node sends a new Path Message using the original SESSION object 359 and the new SENDER_TEMPLATE and ERO. It continues to use the old LSP 360 and refresh the old Path message. On links which are not in common, 361 the new Path message is treated as any new LSP tunnel setup. On 362 links held in common, the shared SESSION object and SE style allow 363 the LSP to be established sharing the same resources. Once the 364 sender receives a Resv message for the new LSP, it is free to begin 365 using it and to tear down the old LSP. 367 Also new C-Types are assigned for the SESSION, SENDER_TEMPLATE, and 368 FILTER_SPEC objects. 370 Detailed descriptions of the new objects are given in later sections. 371 All new objects are optional with respect to RSVP. An implementation 373 3. RSVP Message Formats 375 Five new objects are defined in this document: 377 Object name Applicable RSVP messages 378 --------------- ------------------------ 379 LABEL_REQUEST Path 380 LABEL Resv 381 EXPLICIT_ROUTE Path 382 RECORD_ROUTE Path, Resv 383 SESSION_ATTRIBUTE Path 384 can choose to support some but not other objects. However, the 385 LABEL_REQUEST and LABEL objects are mandatory with respect to this 386 document. 388 The LABEL and RECORD_ROUTE objects, are sender specific. They must 389 immediately follow either the SENDER_TEMPLATE in Path messages, or 390 the FILTER_SPEC in Resv messages. 392 The placement of EXPLICIT_ROUTE, LABEL_REQUEST, and SESSION_ATTRIBUTE 393 objects is simply a suggestion. While it is recommended that an 394 implementation follow this format, the ordering of these objects is 395 not important, so an implementation must be prepared to accept 396 objects in any order. 398 3.1. Path message 400 The format of the Path message is as follows: 402 ::= [ ] 403 404 405 [ ] 406 407 [ ] 408 [ ... ] 409 [ ] 411 ::= [ ] 412 [ ] 413 [ ] 415 3.2. Resv message 417 The format of the Resv message is as follows: 419 ::= [ ] 420 421 422 [ ] [ ] 423 [ ... ] 424