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