idnits 2.17.1 draft-ietf-tsvwg-intserv-multiple-tspec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2210, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2205, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 15 has weird spacing: '...llowing multi...' == Line 1100 has weird spacing: '...Subcode meani...' == Unrecognized Status in 'Intended Status: Standards Track (PS)', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) (Using the creation date from RFC2205, updated by this document, for RFC5378 checks: 1997-09-01) (Using the creation date from RFC2210, updated by this document, for RFC5378 checks: 1996-08-16) -- 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 (March 12, 2012) is 4426 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) == Missing Reference: 'RFC 2119' is mentioned on line 86, but not defined == Missing Reference: 'RFC 2205' is mentioned on line 1274, but not defined == Missing Reference: 'M' is mentioned on line 801, but not defined == Missing Reference: 'R' is mentioned on line 805, but not defined == Missing Reference: 'S' is mentioned on line 807, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1102, but not defined == Unused Reference: 'RFC2119' is defined on line 1116, but no explicit reference was found in the text -- Duplicate reference: RFC2212, mentioned in 'RFC2215', was also mentioned in 'RFC2212'. Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network WG James Polk 3 Internet-Draft Subha Dhesikan 4 Expires: September 12, 2012 Cisco Systems 5 Intended Status: Standards Track (PS) March 12, 2012 6 Updates: RFC 2205, 2210, & 4495 (if published as an RFC) 8 Integrated Services (IntServ) Extension to Allow Signaling of Multiple 9 Traffic Specifications and Multiple Flow Specifications in RSVPv1 10 draft-ietf-tsvwg-intserv-multiple-tspec-01 12 Abstract 14 This document defines extensions to Integrated Services (IntServ) 15 allowing multiple traffic specifications and multiple flow 16 specifications to be conveyed in the same Resource Reservation 17 Protocol (RSVPv1) reservation message exchange. This ability helps 18 optimize an agreeable bandwidth through a network between endpoints 19 in a single round trip. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on Sept 12, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview of the Proposal for including multiple TSPECs and 57 FLOWSPECs . . . . . . . . . . . . 6 58 3. Multi_TSPEC and MULTI_FLOWSPEC Solution . . . . . . . . . . . 8 59 3.1 New MULTI_TSPEC and MULTI-RSPEC Parameters . . . . . . . 9 60 3.2 Multiple TSPEC in a PATH Message . . . . . . . . . . . . 9 61 3.3 Multiple FLOWSPEC for Controlled Load Service . . . . . . 12 62 3.4 Multiple FLOWSPEC for Guaranteed Service . . . . . . . . 14 63 4. Rules of Usage . . . . . . . . . . . . . . . . . . . . . . . 17 64 4.1 Backward Compatibility . . . . . . . . . . . . . . . . . 17 65 4.2 Applies to Only a Single Session . . . . . . . . . . . . 17 66 4.3 No Special Error Handling for PATH Message . . . . . . . 17 67 4.4 Preference Order to be Maintained . . . . . . . . . . . 18 68 4.5 Bandwidth Reduction in Downstream Routers . . . . . . . 18 69 4.6 Merging Rules . . . . . . . . . . . . . . . . . . . . . 19 70 4.7 Applicability to Multicast . . . . . . . . . . . . . . . 19 71 4.8 MULTI_TSPEC Specific Error . . . . . . . . . . . . . . . 20 72 4.9 Other Considerations . . . . . . . . . . . . . . . . . . 20 73 4.10 Known Open Issues . . . . . . . . . . . . . . . . . . . 21 74 5. Security considerations . . . . . . . . . . . . . . . . . . . 21 75 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 79 8.2. Informative References . . . . . . . . . . . . . . . . . 23 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 81 Appendix A. Alternatives for Sending Multiple TSPECs. . . . . 23 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC 2119]. 87 1. Introduction 89 This document defines how Integrated Services (IntServ) [RFC2210] 90 includes multiple traffic specifications and multiple flow 91 specifications in the same Resource Reservation Protocol (RSVPv1) 92 [RFC2205] message. This ability helps optimize an agreeable 93 bandwidth through a network between endpoints in a single round 94 trip. 96 There is a separation of function between RSVP and IntServ, in 97 which RSVP does not define the internal objects to establish 98 controlled load or guarantee services. These are generally left to 99 be opaque in RSVP. At the same time, IntServ does not require 100 that RSVP be the only reservation protocol for transporting both 101 the controlled load or guaranteed service objects - but RSVP does 102 often carry the objects anyway. This makes the two independent - 103 yet related in usage, but are also frequently talked about as if 104 they are one and the same. They are not. 106 The 'traffic specification' contains the traffic characteristics of 107 a sender's data flow and is a required object in a PATH message. The 108 TSPEC object is defined in RFC 2210 to convey the traffic 109 specification from the sender and is opaque to RSVP. The ADSPEC 110 object - for 'advertising specification' - is used to gather 111 information along the downstream data path to aid the receiver in 112 the computation of QoS properties of this data path. The ADSPEC is 113 also opaque to RSVP and is defined in RFC 2210. Both of these 114 IntServ objects are part of the Sender Descriptor [RFC2205]. 116 Once the Sender Descriptor is received at its destination node, 117 after having traveled through the network of routers, the 118 SENDER_TSPEC information is matched with the information gathered in 119 the ADSPEC, if present, about the data path. Together, these two 120 objects help the receiver build its flow specification (encoded in 121 the FLOWSPEC object) for the RESV message. The RESV message 122 establishes the reservation through the network of routers on the 123 data path established by the PATH message. If the ADSPEC is not 124 present in the Sender_Descriptor, it cannot aid the receiver in 125 building the flow specification. 127 The SENDER_TSPEC is not changed in transit between endpoints (i.e., 128 there are no bandwidth request adjustments along the way). However, 129 the ADSPEC is changed, based on the conditions experienced through 130 the network (i.e., bandwidth availability within each router) as the 131 RSVP message travels hop-by-hop. 133 Today, real-time applications have evolved such that they are able 134 to dynamically adapt to available bandwidth, not only by dropping 135 and adding layers, but also by reducing frame rates and resolution. 136 It is therefore limiting to have a single bandwidth request in 137 Integrated Services, and by extension, RSVP. 139 With only one traffic specification in a PATH message and only one 140 flow specification in a RESV message (with some styles of 141 reservations a RESV message may actually contain multiple flow 142 specifications, but then there is only one per sender), applications 143 will either have to give up altogether on session establishment in 144 case of failure of the reservation establishment for the highest 145 "bandwidth or will have to resort to multiple successive RSVP 146 signaling attempts in a trial-and-error manner until they finally 147 establish the reservation a lower "bandwidth". These multiple 148 signaling round-trip would affect the session establishment time and 149 in turn would negatively impact the end user experience. 151 The objective of this document is to avoid such roundtrips as well 152 as allow applications to successfully receive some level of 153 bandwidth allotment that it can use for its sessions. 155 While the ADSPEC provides an indication of the bandwidth available 156 along the path and can be used by the receiver in creating the 157 FLOWSPEC, it does not prevent failures or multiple round-trips as 158 described above. The intermediary routers provide a best attempt 159 estimate of available bandwidth in the ADSPEC object. However, it 160 does not take into account external policy considerations 161 (RFC 2215). In addition, the available bandwidth at the time of 162 creating the ADSPEC may not be available at the time of an actual 163 request in an RESV message. These reasons may cause the RESV message 164 to be rejected. Therefore, the ADSPEC object cannot, by itself, 165 satisfy the requirements of the current generations of real-time 166 applications. 168 It needs to be noted that the ADSPEC is unchanged by this new 169 mechanism. If ADSPEC is included in the PATH message, it is 170 suggested that the receiver use this object in determining 171 the flow specification. 173 This document creates a means for conveying more than one 174 "bandwidth" within the same RSVP reservation set-up (both PATH and 175 RESV) messages to optimize the determination of an agreed upon 176 bandwidth for this reservation. Allowing multiple traffic 177 specifications within the same PATH message allows the sender to 178 communicate to the receiver multiple "bandwidths" that match the 179 different sending rates that the sender is capable of transmitting 180 at. This allows the receiver to convey this multiple "bandwidths" 181 in the RESV so those can be considered when RSVP makes the actual 182 reservation admission into the network. This allows the applications 183 to dynamically adapt their data stream to available network 184 resources. 186 The concept of RSVP signaling is shown in a single direction below, 187 in Figure 1. Although the TSPEC is opaque to RSVP, it is shown 188 along with the RSVP messages for completeness. The RSVP messages 189 themselves need not be the focus of the reader. Instead, the 190 number of round trips it takes to establish a reservation is the 191 focus here. 193 Sender Rtr-1 Rtr-2 ... Rtr-N Receiver 194 | | | | | 195 | PATH (with a TSPEC & ADSPEC) | 196 |------------->|--------->|----//--->|-------------->| 197 | | | | | 198 | RESV (with a FLOWSPEC) | 199 |<-------------|<---------|<---//----|<--------------| 200 | | | | | 202 Figure 1. Concept of RSVP in a Single Direction 204 Figure 1 shows a successful one-way reservation using RSVP and 205 IntServ. 207 Figure 2 shows a scenario where the RESV message, containing a 208 FLOWSPEC, which is generated by the Receiver, after considering 209 both the Sender TSPEC and the ADSPEC, is rejected by an intermediary 210 router. 212 Sender Rtr-1 Rtr-2 ... Rtr-N Receiver 213 | | | | | 214 | PATH (with 1 TSPEC wanting 12Mbps) | 215 |------------->|--------->|----//--->|-------------->| 216 | | | | | 217 | RESV (with 1 FLOWSPEC wanting 12Mbps) | 218 | | X <--//----|<--------------| 219 | | | | | 220 | ResvErr (with Admission control Error=2) | 221 | | |----//--->|-------------->| 222 | | | | | 224 Figure 2. Concept of RSVP Rejection due to Limited Bandwidth 226 The scenario above is where multiple TSPEC and multiple FLOWSPEC 227 optimization helps. The Sender may support multiple bandwidths 228 for a given application (i.e., more than one codec for voice or 229 video) and therefore might want to establish a reservation with the 230 highest (or best) bandwidth that the network can provide for a 231 particular codec. 233 For example, bandwidths of: 235 12Mbps, 236 4Mbps, and 237 1.5Mbps 239 for the three video codecs the Sender supports. 241 This document will discuss the overview of the proposal to include 242 multiple TSPECs and FLOWSPECs RSVP in section 2. In section 3, the 243 overview of the entire solution is provided. This section also 244 contains the new parameters which are defined in this document. The 245 multiple TSPECs in a PATH message and the multiple FLOWSPEC in a 246 RESV message, both for controlled load and guaranteed service are 247 described in this section. Section 4 will cover the rules of usage 248 of this IntServ extension. This section contains how this document 249 needs to extend the scenario of when a router in the middle of a 250 reservation cannot accept a preferred bandwidth (i.e., FLOWSPEC), 251 meaning previous routers that accepted that greater bandwidth now 252 have too much bandwidth reserved. This requires an extension to RFC 253 4495 (RSVP Bandwidth Reduction) to cover reservations being 254 established, as well as existing reservations. Section 4 also 255 includes the merging rules. 257 2. Overview of Proposal for Including Multiple TSPECs and FLOWSPECS 259 Presently, this is the format of a PATH message [RFC2205]: 261 ::= [ ] 263 265 267 [ ... ] 269 [ ] 271 ::= 272 ^^^^^^^^^^^^ 273 [ ] 275 where the SENDER_TSPEC object contains a single traffic 276 specification. 278 For the PATH message, the focus of this document is to modify the 279 in such a way to include more than one traffic 280 specification. This solution does this by retaining the existing 281 SENDER_TSPEC object above, highlighted by the '^^^^' characters, and 282 complementing it with a new optional MULTI_TSPEC object to convey 283 additional traffic specifications in this PATH message. No other 284 object within the PATH message is affected by this IntServ 285 extension. 287 This extension modifies the sender descriptor by specifically 288 augmenting it to allow an optional object after the 289 optional , as shown below. 291 ::= 293 [ ] [ ] 294 ^^^^^^^^^^^ 296 As can be seen above, the MULTI_TSPEC is in addition to the 297 SENDER_TSPEC - and is only to be used, per this extension, when 298 more than one TSPEC is to be included in the PATH message. 300 Here is another way of looking at the proposal choices: 302 +---------------------+ 303 | Existing TSPEC | 304 | | 305 | +----------+ | 306 | | TSPEC1 | | 307 | +----------+ | 308 | | 309 +---------------------+ 311 +---------------------+ 312 | Additional TSPECs | 313 | | 314 | +---------------+ | 315 | | MULTI_TSPEC | | 316 | | Object | | 317 | | +--------+ | | 318 | | | TSPEC2 | | | 319 | | +--------+ | | 320 | | +--------+ | | 321 | | | TSPEC3 | | | 322 | | +--------+ | | 323 | | +--------+ | | 324 | | | TSPEC4 | | | 325 | | +--------+ | | 326 | +---------------+ | 327 | | 328 +---------------------+ 330 Figure 3. Encoding of Multiple Traffic Specifications in 331 the TSPEC and MULTI_TSPEC objects 333 This solution is backwards compatible with existing implementations 334 of [RFC2205] and [RFC2210], as the multiple TSPECs and FLOWSPECs are 335 inserted as optional objects and such objects do not need to be 336 processed, especially if they are not understood. 338 This solution defines a similar approach for encoding multiple flow 339 specifications in the RESV message. Flow specifications beyond the 340 first one can be encoded in a new "MULTI_FLOWSPEC" object contained 341 in the RESV message. 343 In this proposal, the original SENDER_TSPEC and the FLOWSPEC are 344 left untouched, allowing routers not supporting this extension to 345 process the PATH and the RESV message without issue. Two new 346 additional objects are defined in this document. They are the 347 MULTI_TSPEC and the MULTI_FLOWSPEC for the PATH and the RESV 348 message, respectively. The additional TSPECs (in the new MULTI_TSPEC 349 Object) are included in the PATH and the additional FLOWSPECS (in 350 the new MULTI_FLOWSPEC Object) are included in the RESV message as 351 new (optional) objects. These additional objects will have a class 352 number of 11bbbbbb, allowing older routers to ignore the object(s) 353 and forward each unexamined and unchanged, as defined in section 354 3.10 of [RFC 2205]. 356 NOTE: it is important to emphasize here that including more than 357 one FLOWSPEC in the RESV message does not cause more than one 358 FLOWSPEC to be granted. This document requires that the 359 receiver arrange these multiple FLOWSPECs in the order of 360 preference according to the order remaining from the 361 MULTI_TSPECs in the PATH message. The benefit of this 362 arrangement is that RSVP does not have to process the rest of 363 the FLOWSPEC if it can admit the first one. 365 3. Multi_TSPEC and MULTI_FLOWSPEC Solution 367 For the Sender Descriptor within the PATH message, the original 368 TSPEC remains where it is, and is untouched by this IntServ 369 extension. What is new is the use of a new object 370 inside the sender descriptor as shown here: 372 ::= 374 [ ] [ ] 375 ^^^^^^^^^^^ 377 The preferred order of TSPECs sent by the sender is this: 379 - preferred TSPEC is in the original SENDER_TSPEC 381 - the next in line preferred TSPEC is the first TSPEC in the 382 MULTI_TSPEC object 384 - the next in line preferred TSPEC is the second TSPEC in the 385 MULTI_TSPEC object 387 - and so on... 389 The composition of the flow descriptor list in a Resv message 390 depends upon the reservation style. Therefore, the following shows 391 the inclusion of the MULTI_FLOWSPEC object with each of the styles: 393 WF Style: 394 ::= 396 ::= [MULTI_FLOWSPEC] 398 FF style: 399 ::= 401 [MULTI_FLOWSPEC] | 403 405 ::= 407 [ ] [MULTI_FLOWSPEC] 409 SE style: 410 ::= 412 ::= 414 [MULTI_FLOWSPEC] 416 ::= 418 | 420 3.1 New MULTI_TSPEC and MULTI-RSPEC Parameters 422 This extension to Integrated Services defines two new parameters 423 They are: 425 1. Multiple_Token_Bucket_Tspec, with a parameter 426 number of 125. 428 2. Multiple_Guaranteed_Service_RSpec with a 429 parameter number of 124 431 These are IANA registered in this document. 433 The original SENDER_TSPEC and FLOWSPEC for Controlled Service 434 maintain the of Token_Bucket_Tspec with a parameter 435 number of 127. The original FLOWSPEC for Guaranteed Service 436 maintains the of Guaranteed_Service_RSpec with a 437 parameter number of 130. 439 3.2 Multiple TSPEC in a PATH Message 440 Here is the object from [RFC2210]. It is used as a SENDER_TSPEC in a 441 PATH message: 443 31 24 23 16 15 8 7 0 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 1 | 0 (a) | reserved | 7 (b) | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 2 | X (c) |0| reserved | 6 (d) | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 3 | 127 (e) | 0 (f) | 5 (g) | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 7 | Minimum Policed Unit [m] (32-bit integer) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 8 | Maximum Packet Size [M] (32-bit integer) | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Figure 4. SENDER_TSPEC in PATH 464 (a) - Message format version number (0) 465 (b) - Overall length (7 words not including header) 466 (c) - Service header, service number 467 - '1' (Generic information) if in a PATH message; 468 (d) - Length of service data, 6 words not including 469 per-service header 470 (e) - Parameter ID, parameter 127 (Token Bucket TSpec) 471 (f) - Parameter 127 flags (none set) 472 (g) - Parameter 127 length, 5 words not including per-service 473 header 475 For completeness, Figure 4 is included in its original form for 476 backwards compatibility reasons, as if there were only 1 TSPEC in 477 the PATH. What is new when there are more than one TSPEC in 478 this reservation message is the new MULTI_TSPEC object in Figure 5 479 containing, for example, 3 (Multiple_Token_Bucket_Tspec) TSPECs in a 480 PATH message. 482 31 24 23 16 15 8 7 0 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 1 | 0 (a) | reserved | 19 (b) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 2 | 5 (c) |0| reserved | 18 (d) | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 3 | 125 (e) | 0 (f) | 5 (g) | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 7 | Minimum Policed Unit [m] (32-bit integer) | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 8 | Maximum Packet Size [M] (32-bit integer) | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 9 | 125 (e) | 0 (f) | 5 (g) | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 10 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 11 | Token Bucket Size [b] (32-bit IEEE floating point number) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 12 | Peak Data Rate [p] (32-bit IEEE floating point number) | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 13 | Minimum Policed Unit [m] (32-bit integer) | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 14 | Maximum Packet Size [M] (32-bit integer) | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 15 | 125 (e) | 0 (f) | 5 (g) | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 16 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 17 | Token Bucket Size [b] (32-bit IEEE floating point number) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 18 | Peak Data Rate [p] (32-bit IEEE floating point number) | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 19 | Minimum Policed Unit [m] (32-bit integer) | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 20 | Maximum Packet Size [M] (32-bit integer) | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Figure 5. MULTI_TSPEC Object 528 (a) - Message format version number (0) 529 (b) - Overall length (19 words not including header) 530 (c) - Service header, service number 5 (Controlled-Load) 531 (d) - Length of service data, 18 words not including 532 per-service header 533 (e) - Parameter ID, parameter 125 (Multiple Token Bucket TSpec) 534 (f) - Parameter 125 flags (none set) 535 (g) - Parameter 125 length, 5 words not including per-service 536 header 538 Figure 5 shows the 2nd through Nth TSPEC in the PATH in the 539 preferred order. The message format (a) remains the same for a 540 second TSPEC and for other additional TSPECs. 542 The Overall Length (b) includes all the TSPECs within this object, 543 plus the 2nd Word (containing fields (c) and (d)), which MUST NOT be 544 repeated. The service header fields (e),(f) and(g) are repeated for 545 each TSPEC. 547 The Service header, here service number 5 (Controlled-Load) MUST 548 remain the same. 550 Each TSPEC is six 32-bit Words long (the per-service header plus the 551 5 values that are 1 Word each in length), therefore the length is in 552 6 Word increments for each additional TSPEC. Case in point, from 553 the above Figure 5, Words 3-8 are the first TSPEC (2nd preferred), 554 Words 9-14 are the next TSPEC (3rd preferred), and Words 15-20 are 555 the final TSPEC (and 4th preferred) in this example of 3 TSPECs in 556 this MULTI_TSPEC object. There is no limit placed on the number of 557 TSPECs a MULTI_TSPEC object can have. However, it is RECOMMENDED to 558 administratively limit the number of TSPECs in the MULTI_TSPEC 559 object to 9 (making for a total of 10 in the PATH message). 561 The TSPECS are included in the order of preference by the message 562 generator (PATH) and MUST be maintained in that order all the way to 563 the Receiver. The order of TSPECs that are still grantable, in 564 conjunction with the ADSPEC at the Receiver, MUST retain that 565 order in the FLOWSPEC and MULTI_FLOWSPEC objects. 567 3.3 Multiple FLOWSPEC for Controlled-Load service 569 The format of an RSVP FLOWSPEC object requesting Controlled-Load 570 service is the same as the one used for the SENDER_TSPEC given in 571 Figure 4. 573 The format of the new MULTI_FLOWSPEC object is given below: 575 31 24 23 16 15 8 7 0 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 1 | 0 (a) | reserved | 19 (b) | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 2 | 5 (c) |0| reserved | 18 (d) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 3 | 125 (e) | 0 (f) | 5 (g) | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 7 | Minimum Policed Unit [m] (32-bit integer) | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 8 | Maximum Packet Size [M] (32-bit integer) | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 9 | 125 (e) | 0 (f) | 5 (g) | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 10 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 11 | Token Bucket Size [b] (32-bit IEEE floating point number) | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 12 | Peak Data Rate [p] (32-bit IEEE floating point number) | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 13 | Minimum Policed Unit [m] (32-bit integer) | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 14 | Maximum Packet Size [M] (32-bit integer) | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 15 | 125 (e) | 0 (f) | 5 (g) | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 16 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 17 | Token Bucket Size [b] (32-bit IEEE floating point number) | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 18 | Peak Data Rate [p] (32-bit IEEE floating point number) | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 19 | Minimum Policed Unit [m] (32-bit integer) | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 20 | Maximum Packet Size [M] (32-bit integer) | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 Figure 5. Multiple FLOWSPEC for Controlled-Load service 621 (a) - Message format version number (0) 622 (b) - Overall length (19 words not including header) 623 (c) - Service header, service number 5 (Controlled-Load) 624 (d) - Length of controlled-load data, 18 words not including 625 per-service header 626 (e) - Parameter ID, parameter 125 (Multiple Token Bucket TSpec) 627 (f) - Parameter 125 flags (none set) 628 (g) - Parameter 125 length, 5 words not including per-service 629 header 631 This is for the 2nd through Nth TSPEC in the RESV, in the 632 preferred order. 634 The message format (a) remains the same for a second TSPEC and 635 for additional TSPECs. 637 The Overall Length (b) includes the TSPECs, plus the 2nd Word 638 (fields (c) and (d)), which MUST NOT be repeated. The service header 639 fields (e),(f) and(g), which are repeated for each TSPEC. 641 The Service header, here service number 5 (Controlled-Load) MUST 642 remain the same for the RESV message. The services, Controlled-Load 643 and Guaranteed MUST NOT be mixed within the same RESV message. In 644 other words, if one TSPEC is a Controlled Load service TSPEC, the 645 remaining TSPECs MUST be Controlled Load service. This same rule 646 also is true for Guaranteed Service - if one TSPEC is for Guaranteed 647 Service, the rest of the TSPECs in this PATH or RESV MUST be for 648 Guaranteed Service. 650 The Length of controlled-load data (d) also increases to account for 651 the additional TSPECs. 653 Each FLOWSPEC is six 32-bit Words long (the per-service header plus 654 the 5 values that are 1 Word each in length), therefore the length 655 is in 6 Word increments for each additional TSPEC. Case in point, 656 from the above Figure 5, Words 3-8 are the first TSPEC (2nd 657 preferred), Words 9-14 are the next TSPEC (3rd preferred), and Words 658 15-20 are the final TSPEC (and 4th preferred) in this example of 3 659 TSPECs in this FLOWSPEC. There is no limit placed on the number of 660 TSPECs a particular FLOWSPEC can have. 662 Within the MULTI_FLOWSPEC, any SENDER_TSPEC that cannot be reserved 663 - based on the information gathered in the ADSPEC, is not placed in 664 the RESV or based on other information available to the receiver. 665 Otherwise, the order in which the TSPECs were in the PATH message 666 MUST be in the same order they are in the FLOWSPEC in the RESV. 667 This is the order of preference of the sender, and MUST be 668 maintained throughout the reservation establishment, unless the 669 ADSPEC indicates one or more TSPECs cannot be granted, or the 670 receiver cannot include any TSPEC due to technical or administrative 671 constraints or one or more routers along the RESV path cannot grant 672 a particular TSPEC. At any router that a reservation cannot honor a 673 TSPEC, this TSPEC MUST be removed from the RESV, or else another 674 router along the RESV path might reserve that TSPEC. This rule 675 ensures this cannot happen. 677 Once one TSPEC has been removed from the RESV, the next in line 678 TSPEC becomes the preferred TSPEC for that reservation. That router 679 MUST generate a ResvErr message, containing an ERROR_SPEC object 680 with a Policy Control Failure with Error code = 2 (Policy Control 681 Failure), and an Error Value sub-code 102 (ERR_PARTIAL_PREEMPT) to 682 the previous routers, clearing the now over allocation of bandwidth 683 for this reservation. The difference between the previously 684 accepted TSPEC bandwidth and the currently accepted TSPEC bandwidth 685 is the amount this error identifies as the amount of bandwidth that 686 is no longer required to be reserved. The ResvErr and the RESV 687 messages are independent, and not normally sent by the same router. 688 This aspect of this document is the extension to RFC 2205 (RSVP). 690 If a RESV cannot grant the final TSPEC, normal RSVP rules apply with 691 regard to the transmission of a particular ResvErr. 693 3.4 Multiple FLOWSPEC for Guaranteed service 695 The FLOWSPEC object, which is used to request guaranteed service 696 contains a TSPEC and RSpec. Here is the FLOWSPEC object from 697 [RFC2215] when requesting Guaranteed service: 699 31 24 23 16 15 8 7 0 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 1 | 0 (a) | Unused | 10 (b) | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 2 | 2 (c) |0| reserved | 9 (d) | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 3 | 127 (e) | 0 (f) | 5 (g) | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 7 | Minimum Policed Unit [m] (32-bit integer) | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 8 | Maximum Packet Size [M] (32-bit integer) | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 9 | 130 (h) | 0 (i) | 2 (j) | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 10 | Rate [R] (32-bit IEEE floating point number) | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 11 | Slack Term [S] (32-bit integer) | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 Figure 6. FLOWSPEC for Guaranteed service 726 (a) - Message format version number (0) 727 (b) - Overall length (9 words not including header) 728 (c) - Service header, service number 2 (Guaranteed) 729 (d) - Length of per-service data, 9 words not including 730 per-service header 731 (e) - Parameter ID, parameter 127 (Token Bucket TSpec) 732 (f) - Parameter 127 flags (none set) 733 (g) - Parameter 127 length, 5 words not including parameter header 734 (h) - Parameter ID, parameter 130 (Guaranteed Service RSpec) 735 (i) - Parameter xxx flags (none set) 736 (j) - Parameter xxx length, 2 words not including parameter header 738 The difference in structure between the Controlled-Load FLOWSPEC and 739 Guaranteed FLOWSPEC is the RSPEC, defined in [RFC2212]. 741 For completeness, Figure 6 is included in its original form for 742 backwards compatibility reasons, as if there were only 1 FLOWSPEC in 743 the RESV. What is new when there is more than one TSPEC in the 744 FLOWSPEC in a RESV message is the new MULTI_FLOWSPEC object in 745 Figure 7 containing, for example, 3 FLOWSPECs requesting Guaranteed 746 Service. 748 31 24 23 16 15 8 7 0 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 1 | 0 (a) | Unused | 28 (b) | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 2 | 2 (c) |0| reserved | 27 (d) | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 3 | 125 (e) | 0 (f) | 5 (g) | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 7 | Minimum Policed Unit [m] (32-bit integer) | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 8 | Maximum Packet Size [M] (32-bit integer) | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 9 | 124 (h) | 0 (i) | 2 (j) | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 10 | Rate [R] (32-bit IEEE floating point number) | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 11 | Slack Term [S] (32-bit integer) | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 12 | 125 (e) | 0 (f) | 5 (g) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 13 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 14 | Token Bucket Size [b] (32-bit IEEE floating point number) | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 15 | Peak Data Rate [p] (32-bit IEEE floating point number) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 16 | Minimum Policed Unit [m] (32-bit integer) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 17 | Maximum Packet Size [M] (32-bit integer) | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 18 | 124 (h) | 0 (i) | 2 (j) | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 19 | Rate [R] (32-bit IEEE floating point number) | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 20 | Slack Term [S] (32-bit integer) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 21 | 125 (e) | 0 (f) | 5 (g) | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 22 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 23 | Token Bucket Size [b] (32-bit IEEE floating point number) | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 24 | Peak Data Rate [p] (32-bit IEEE floating point number) | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 25 | Minimum Policed Unit [m] (32-bit integer) | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 26 | Maximum Packet Size [M] (32-bit integer) | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 27 | 124 (h) | 0 (i) | 2 (j) | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 28 | Rate [R] (32-bit IEEE floating point number) | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 29 | Slack Term [S] (32-bit integer) | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Figure 7. Multiple FLOWSPECs for Guaranteed service 812 (a) - Message format version number (0) 813 (b) - Overall length (9 words not including header) 814 (c) - Service header, service number 2 (Guaranteed) 815 (d) - Length of per-service data, 9 words not including 816 per-service header 817 (e) - Parameter ID, parameter 125 (Token Bucket TSpec) 818 (f) - Parameter 125 flags (none set) 819 (g) - Parameter 125 length, 5 words not including parameter header 820 (h) - Parameter ID, parameter 124 (Guaranteed Service RSpec) 821 (i) - Parameter 124 flags (none set) 822 (j) - Parameter 124 length, 2 words not including parameter header 824 There MUST be 1 RSPEC per TSPEC for Guaranteed Service. Therefore, 825 there are 5 words for Receiver TSPEC and 3 words for the RSPEC. 826 Therefore, for Guaranteed Service, the TSPEC/RSPEC combination 827 occurs in increments of 8 words. 829 4. Rules of Usage 831 The following rules apply to nodes adhering to this specification: 833 4.1 Backward Compatibility 835 If the recipient does not understand this extension, it ignores this 836 MULTI_TSPEC object, and operates normally for a node receiving this 837 RSVP message. 839 4.2 Applies to Only a Single Session 841 When there is more than one TSPEC object or more than one FLOWSPEC 842 object, this MUST NOT be considered for more than one flow created. 843 These are OR choices for the same flow of data. In order to attain 844 three reservations between two endpoints, three different 845 reservation requests are required, not one reservation request with 846 3 TSPECs. 848 4.3 No Special Error Handling for PATH Message 850 If a problem occurs with the PATH message - regardless of this 851 extension, normal RSVP procedures apply (i.e., there is no new 852 PathErr code created within this extension document) - resulting in 853 a PathErr message being sent upstream towards the sender, as usual. 855 4.4 Preference Order to be Maintained 857 When more than one TSPEC is in a PATH message, the order of TSPECs 858 is decided by the Sender and MUST be maintained within the 859 SENDER_TSPEC. The same order MUST be carried to the FLOWSPECs by 860 the receiver. No additional TSPECS can be introduced by the receiver 861 or any router processing these new objects. The deletion of TSPECs 862 from a PATH message is not permitted. The deletion of the TSPECs 863 when forming the FLOWSPEC is allowed by the receiver in the 864 following cases: 866 - If one or more preferred TSPECs cannot be granted by a router as 867 discovered during processing of the ADSPEC by the receiver, then 868 they can be omitted when creating the FLOWSPEC(s) from the TSPECs. 870 - If one or more TSPECs arriving from the sender is not preferred by 871 the receiver, then the receiver MAY omit any while creating the 872 FLOWSPEC. A good reason to omit a TSPEC is if, for example, it 873 does not match a codec supported by the receiver's application(s). 875 The deletion of the TSPECs in the router during the processing of 876 this MULTI_FLOWSPEC object is allowed in the following cases: 878 - If the original FLOWSPEC cannot be granted by a router then the 879 router may discard that FLOWSPEC and replace it with the topmost 880 FLOWSPEC from the MULTI_FLOWSPEC project. This will cause the 881 topmost FLOWSPEC in the MULTI_FLOWSPEC object to be removed. The 882 next FLOWSPECs becomes the topmost FLOWSPEC. 884 - If the router merges multiple RESV into a single RESV message, 885 then the FLOWSPEC and the multiple FLOWSPEC may be affected 887 The preferred order of the remaining TSPECs or FLOWSPECs MUST be 888 kept intact both at the receiver as well as the router processing 889 these objects. 891 4.5 Bandwidth Reduction in Downstream Routers 893 If there are multiple FLOWSPECs in a single RESV message, it is 894 quite possible that a higher bandwidth is reserved at a previous 895 downstream device. Thus, any device that grants a reservation that 896 is not the highest will have to inform the previous downstream 897 routers to reduce the bandwidth reserved for this particular 898 session. 900 The bandwidth reduction RFC [RFC4495] does not address the need that 901 this document addresses. RFC 4495 defines an ability to preempt 902 part of an existing reservation so as to admit a new incoming 903 reservation with a higher priority, in lieu of tearing down the 904 whole reservation having a lower priority. It does not specify the 905 capability to reduce the bandwidth a RESV set up along the data path 906 before the reservation is realized (from source to destination), 907 when a subsequent router cannot support a more preferred FLOWSPEC 908 contained in that RESV. This document extends the RFC 4495 defined 909 partial teardown error to reduce bandwidth from previous downstream 910 hops while a reservation is being established. 912 For example, if a 12Mbps TSPEC were granted for a reservation on 913 previous hops, but could not be granted at the current hop, while 914 the 4Mbps TSPEC could be granted (provided there is a MULTI_TSPEC 915 with a 4Mbps TSPEC), this modification to the bandwidth reduction 916 function would work by having the 4Mbps granting node send a 917 reduction error to the downstream routers that installed 12Mbps for 918 this reservation, thus clearing bandwidth that is now unnecessarily 919 installed for a 4Mbps reservation. 921 4.6 Merging Rules 923 RFC 2205 defines the rules for merging as combining more than one 924 FLOWSPEC into a single FLOWSPEC. In the case of MULTI_FLOWSPECs, 925 merging of the two (or more) MULTI_FLOWSPEC MUST be done to arrive 926 at a single MULTI_FLOWSPEC. The merged MULTI_FLOWSPEC will contain 927 all the flow specification components of the individual 928 MULTI_FLOWSPECs in descending orders of bandwidth. In other words, 929 the merged FLOWSPEC MUST maintain the relative order of each of the 930 individual FLOWSPECs. For example, if the individual FLOWSPEC order 931 is 1,2,3 and another FLOWSPEC is a,b,c, then this relative ordering 932 cannot be altered in the merged FLOWSPEC. 934 A byproduct of this is the ordering between the two individual 935 FLOWSPECs cannot be signaled with this extension. If two (or more) 936 FLOWSPECs have the same bandwidth, they are to be merged into one 937 FLOWSPEC using the rules defined in RFC 2205. It is RECOMMENDED 938 that the following rules are used for determining ordering (in TSPEC 939 and FLOWSPEC): 941 For Controlled Load - in descending order of BW based on the 942 Token Bucket Rate 'r' parameter value 944 For Guaranteed Service - in descending order of BW based on the 945 RSPEC Rate 'R' parameter value 947 The resultant FLOWSPEC is added to the MULTI_FLOWSPEC based on its 948 bandwidth in descending orders of bandwidth. 950 As a result of such merging, the number of FLOWSPECs in a 951 MULTI_FLOWSPEC object should be the sum of the number of FLOWSPECs 952 from individual MULTI_FLOWSPEC that have been merged *minus* the 953 number of duplicates. 955 4.7 Applicability to Multicast 957 An RSVP message with a MULTI_TSPEC works just as well in a multicast 958 scenario as it does in a unicast scenario. In a multicast scenario, 959 the bandwidth allotted in each hop is the lowest bandwidth that can 960 be admitted along the various path. For example: 962 +--------+ +----------+ +----------+ +------------+ 963 | sender |======>| Router-1 |=====>| Router-2 |=====>| Receiver-A | 964 +--------+ +----------+ +----------+ +------------+ 965 | | 966 | | 967 | V 968 | +------------+ 969 | | Receiver-C | 970 | +------------+ 971 | 972 V 973 +------------+ 974 | Receiver-B | 975 +------------+ 977 Figure 8. MULTI_TPSEC and Multicast 979 If the sender (in Figure 8) sends 3 TSPECs (i.e., 1 TSPEC Object, 980 and 2 in the MULTI_TSPEC Object) of 12Mbps, 5Mbps and 1.5Mbps. Let 981 us say the path from Receiver-B to Router-1 admitted 5Mbps, 982 Receiver-C to Router-2 admitted 1.5Mbps and Receiver-A to Router-2 983 admitted 12Mbps. 985 When the Resv message is send upstream from Router-2, the combining 986 of 1.5Mbps (to Receiver-C) and 12Mbps (to Receiver-A) will be 987 resolved to 1.5Mbps (lowest that can be admitted). Only a Resv with 988 1.5Mbps will be sent upstream from Router-2. Likewise, at Router-1, 989 the combining of 1.5Mbps (to Router-2) and 5Mbps (to Receiver-B) 990 will be resolved to 1.5Mbps units. 992 This is to allow the sender to transmit the flow at a rate that can 993 be accepted by all devices along the path. Without this, if Router-2 994 receives a flow of 12Mbps, it will not know how to create a flow of 995 1.5Mbps down to Receiver-B. A differentiated reservation for the 996 various paths along a multicast path is only possible with a 997 Media-aware network device (MANE). The discussion of MANE and how it 998 relates to admission control is outside the scope of this draft. 1000 4.8 MULTI_TSPEC Specific Error 1002 Since this mechanism is backward compatible, it is possible that a 1003 router without support for this MULTI_TSPEC extension will reject a 1004 reservation because the bandwidth indicated in the primary FLOWSPECs 1005 is not available. This means that an attempt with a lower bandwidth 1006 might have been successful, if one were included in a MULTI_TSPEC 1007 Object. Therefore, one should be able to differentiate between an 1008 admission control error where there is insufficient bandwidth when 1009 all the FLOWSPECs are considered and insufficient bandwidth when 1010 only the primary FLOWSPEC is considered. 1012 This requires the definition of an error code within the ERROR_SPEC 1013 Object. When a router does not have sufficient bandwidth even after 1014 considering all the FLOWSPEC provided, it issues a new "MULTI_TSPEC 1015 bandwidth unavailable " error. This will be an Admission Control 1016 Failure (error #1), with a subcode of 6. A router that does not 1017 support this MULTI_TSPEC extension will return the "requested 1018 bandwidth unavailable" error as defined in RFC 2205 as if there was 1019 no MULTI_TSPEC in the message. 1021 4.9 Other Considerations 1023 - RFC 4495 articulates why a ResvErr is more appropriate to use for 1024 reducing the bandwidth of an existing reservation vs. a ResvTear. 1026 - Refreshes only include the TSPECs that were accepted. One SHOULD 1027 be sent immediately upon the Sender receiving the RESV, to 1028 ensure all routers in this flow are synchronized with which TSPEC 1029 is in place. 1031 - Periodically, it might be appropriate to attempt to increase the 1032 bandwidth of an accepted reservation with one of the TSPECs that 1033 were not accepted by the network when the reservation was first 1034 installed. This SHOULD NOT occur too regularly. This document 1035 currently offers no guidance on the frequency of this bump request 1036 for a rejected TSPEC from the PATH. 1038 4.10 Known Open Issues 1040 Here are the know open issues within this document: 1042 o Both the idea of MULTI_RSPEC and MULTI_FLOWSPEC need to be 1043 fleshed out, and IANA registered. 1045 o Need to ensure the cap on the number of TSPECs and FLOWSPECs is 1046 viable, yet controlled. 1048 5. Security considerations 1050 The security considerations for this document do not exceed what is 1051 already in RFC 2205 (RESV) or RFC 2210 (IntServ), as nothing in 1052 either of those documents prevent a node from requesting a lot of 1053 bandwidth in a single TSPEC. This document merely reduces the 1054 signaling traffic load on the network by allowing many requests that 1055 fall under the same policy controls to be included in a single 1056 round-trip message exchange. 1058 Further, this document does not increase the security risk(s) to 1059 that defined in RFC 4495, where this document creates additional 1060 meaning to the RFC 4495 created error code 102. 1062 A misbehaving Sender can include too many TSPECs in the 1063 MULTI_TSPEC object, which can lead to an amplification attack. That 1064 said, a bad implementation can create a reservation for each TSPEC 1065 received from within the Resv message. The number of TSPECs in the 1066 new MULTI_TSPEC object is limited, and the spec clearly states that 1067 only a single reservation is to be set up per Resv message. 1069 To ensure the integrity of RSVP, the RSVP Authentication mechanisms 1070 defined in [RFC2747] and [RFC3097] SHOULD be used. Those protect 1071 RSVP message integrity hop-by-hop and provide node authentication as 1072 well as replay protection, thereby protecting against corruption and 1073 spoofing of RSVP messages. 1075 6. IANA considerations 1077 This document IANA registers the following new parameter name in the 1078 Integ-serv assignments at [IANA]: 1080 Registry Name: Parameter Names 1081 Registry: 1082 Value Description Reference 1083 -------- -------------------------------------------- --------- 1084 125 Multiple_Token_Bucket_Tspec [RFCXXXX] 1085 124 Multiple_Guaranteed_Service_RSpec [RFCXXXX] 1087 Where RFCXXXX is replaced with the RFC number assigned to this 1088 Document. 1090 This document IANA registers the following new error subcode in the 1091 Error code section, under the Admission Control Failure (error=1), 1092 of the rsvp-parameters assignments at [IANA]: 1094 Registry Name: Error Codes and Globally-Defined Error Value 1095 Sub-Codes 1096 Registry: 1097 "Admission Control 1098 Failure" 1100 Error Subcode meaning Reference 1101 ------------- ----------------------------------------- --------- 1102 6 = MULTI_TSPEC bandwidth unavailable [RFCXXXX] 1104 7. Acknowledgments 1106 The authors wish to thank Fred Baker, Joe Touch, Bruce Davie, Dave 1107 Oran, Ashok Narayanan, Lou Berger, Lars Eggert, Arun Kudur and Janet 1108 Gunn for their helpful comments and guidance in this effort. 1110 And to Francois Le Faucheur, who provided text in this version. 1112 8. References 1114 8.1. Normative References 1116 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1117 Requirement Levels", RFC 2119, March 1997 1119 [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 1120 "Resource ReSerVation Protocol (RSVP) -- Version 1 1121 Functional Specification", RFC 2205, September 1997 1123 [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 1124 Services", RFC 2210, September 1997 1126 [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of 1127 Guaranteed Quality of Service", RFC 2212, September 1997 1129 [RFC2215] S. Shenker, J. Wroclawski, "General Characterization 1130 Parameters for Integrated Service Network Elements", 1131 RFC 2212, September 1997 1133 [RFC2747] F. Baker, B. Lindell, M. Talwar, " RSVP Cryptographic 1134 Authentication", RFC2747, January 2000 1136 [RFC3097] R. Braden, L. Zhang, "RSVP Cryptographic Authentication -- 1137 Updated Message Type Value", RFC 3097, April 2001 1139 [RFC4495] J. Polk, S. Dhesikan, "A Resource Reservation Protocol 1140 (RSVP) Extension for the Reduction of Bandwidth of a 1141 Reservation Flow", RFC 4495, May 2006 1143 8.2. Informative References 1145 [IANA] http://www.iana.org/assignments/integ-serv 1147 Authors' Addresses 1149 James Polk 1150 3913 Treemont Circle 1151 Colleyville, Texas, USA 1152 +1.817.271.3552 1154 mailto: jmpolk@cisco.com 1156 Subha Dhesikan 1157 Cisco Systems 1158 170 W. Tasman Drive 1159 San Jose, CA 95134 USA 1161 mailto: sdhesika@cisco.com 1163 Appendix A: Alternatives for Sending Multiple TSPECs 1165 This appendix describes the discussion within the TSVWG of which 1166 approach best fits the requirements of sending multiple TSPECs 1167 within a single PATH or RESV message. There were 3 different 1168 options proposed, of which - 2 were insufficient or caused more harm 1169 than other options. 1171 Looking at the format of a PATH message [RFC2205] again: 1173 ::= [ ] 1175 1177 1179 [ ... ] 1181 [ ] 1183 ::= 1184 ^^^^^^^^^^^^ 1185 [ ] 1187 For the PATH message, the focus of this document is with what to do 1188 with respect to the above, highlighted by the '^^^^' 1189 characters. No other object within the PATH message will be affected 1190 by this IntServ extension. 1192 The ADSPEC is optional in IntServ; therefore it might or might not 1193 be in the RSVP PATH message. Presently, the SENDER_TSPEC is limited 1194 to one bandwidth associated with the session. This is changed in 1195 this extension to IntServ to multiple bandwidths for the same 1196 session. There are multiple options on how the additional bandwidths 1197 may be added: 1199 Option #1 - creating the ability to add one or more additional 1200 (and complete) SENDER_TSPECs, 1202 or 1204 Option #2 - create the ability for the one already allowed 1205 SENDER_TSPEC to carry more than one bandwidth amount 1206 for the same reservation. 1208 or 1210 Option #3 - create the ability for the existing SENDER_TSPEC to 1211 remain unchanged, but add an optional 1212 object to the such as this: 1214 ::= 1216 [ ] [ ] 1217 ^^^^^^^^^^^ 1219 Here is another way of looking at the option choices: 1221 +--------------------+----------------------+---------------------+ 1222 | Option#1 | Option#2 | Option#3 | 1223 | | | | 1224 | +----------+ | +---------------+ | +----------+ | 1225 | | TSPEC1 | | | MULTI_TSPEC | | | TSPEC1 | | 1226 | +----------+ | | Object | | +----------+ | 1227 | | | +--------+ | | | 1228 | +----------+ | | | TSPEC1 | | | +---------------+ | 1229 | | TSPEC2 | | | +--------+ | | | MULTI_TSPEC | | 1230 | +----------+ | | +--------+ | | | Object | | 1231 | | | | TSPEC2 | | | | +--------+ | | 1232 | +----------+ | | +--------+ | | | | TSPEC2 | | | 1233 | | TSPEC3 | | | +--------+ | | | +--------+ | | 1234 | +----------+ | | | TSPEC3 | | | | +--------+ | | 1235 | | | +--------+ | | | | TSPEC3 | | | 1236 | +----------+ | | | TSPEC4 | | | | +--------+ | | 1237 | | TSPEC4 | | | +--------+ | | | +--------+ | | 1238 | +----------+ | +---------------+ | | | TSPEC4 | | | 1239 | | | | +--------+ | | 1240 | | | +---------------+ | 1241 | | | | 1242 +--------------------+----------------------+---------------------+ 1244 Figure 3. Concept of Option Choice 1246 Option #1 and #2 do not allow for backward compatibility. If the 1247 currently used SENDER_TSPEC and FLOWSPEC objects are changed, then 1248 unless all the routers requiring RSVP processing are upgraded, this 1249 functionality cannot be realized. As it is unlikely that all routers 1250 along the path will have the necessary enhancements as per this 1251 extension at one given time, therefore, it is necessary this 1252 enhancement be made in a way that is backward compatible. Therefore, 1253 option #1 and option #2 has been discarded in favor of option #3, 1254 which had WG consensus in a recent IETF meeting. 1256 Option #3: This option has the advantage of being backwards 1257 compatible with existing implementations of [RFC2205] and [RFC2210], 1258 as the multiple TSPECs and FLOWSPECs are inserted as optional 1259 objects and such objects do not need to be processed, especially if 1260 they are not understood. 1262 Option#3 applies to the FLOWSPEC contained in the RESV message as 1263 well. In this option, the original SENDER_TSPEC and the FLOWSPEC are 1264 left untouched, allowing routers not supporting this extension to be 1265 able to process the PATH and the RESV message without issue. Two new 1266 additional objects are defined in this document. They are the 1267 MULTI_TSPEC and the MULTI_FLOWSPEC for the PATH and the RESV 1268 message, respectively. The additional TSPECs (in the new MULTI_TSPEC 1269 Object) are included in the PATH and the additional FLOWSPECS (in 1270 the new MULTI_FLOWSPEC Object) are included in the RESV message as 1271 new (optional) objects. These additional objects will have a class 1272 number of 11bbbbbb, allowing older routers to ignore the object(s) 1273 and forward each unexamined and unchanged, as defined in section 1274 3.10 of [RFC 2205]. 1276 We state in the document body that the top most FLOWSPEC of the new 1277 MULTI_FLOWSPEC Object in the RESV message replaces the existing 1278 FLOWSPEC when it is determined by the receiver (perhaps along 1279 with the ADSPEC) that the original FLOWSPEC cannot be granted. 1280 Therefore, the ordering of preference issue is solved with Option#3 1281 as well. 1283 NOTE: it is important to emphasize here that including more than 1284 one FLOWSPEC in the RESV message does not cause more than one 1285 FLOWSPEC to be granted. This document requires that the 1286 receiver arrange these multiple FLOWSPECs in the order of 1287 preference according to the order remaining from the 1288 MULTI_TSPECs in the PATH message. The benefit of this 1289 arrangement is that RSVP does not have to process the rest of 1290 the FLOWSPEC if it can admit the first one. 1292 Additional details of these options can be found in the 1293 draft-polk-tsvwg-...-01 version of this appendix (which includes the 1294 RSVP bit mapping of fields in the TSPECs, if the reader wishes to 1295 search for that doc.