idnits 2.17.1 draft-polk-tsvwg-intserv-multiple-tspec-06.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 1103 has weird spacing: '...Subcode meani...' (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 14, 2011) is 4785 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2119' is mentioned on line 103, but not defined == Missing Reference: 'RFC 2205' is mentioned on line 1270, but not defined == Missing Reference: 'M' is mentioned on line 818, but not defined == Missing Reference: 'R' is mentioned on line 823, but not defined == Missing Reference: 'S' is mentioned on line 825, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1105, but not defined == Unused Reference: 'RFC2119' is defined on line 1118, 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 (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG WG James Polk 3 Internet-Draft Subha Dhesikan 4 Expires: September 14, 2011 Cisco Systems 5 Intended Status: Standards Track (PS) March 14, 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-polk-tsvwg-intserv-multiple-tspec-06 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 September 14, 2011. 55 Copyright Notice 57 Copyright (c) 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 1 | 0 (a) | Unused | 28 (b) | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 2 | 2 (c) |0| reserved | 27 (d) | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 3 | 125 (e) | 0 (f) | 5 (g) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 7 | Minimum Policed Unit [m] (32-bit integer) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 8 | Maximum Packet Size [M] (32-bit integer) | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 9 | 124 (h) | 0 (i) | 2 (j) | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 10 | Rate [R] (32-bit IEEE floating point number) | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 11 | Slack Term [S] (32-bit integer) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 12 | 125 (e) | 0 (f) | 5 (g) | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 13 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 14 | Token Bucket Size [b] (32-bit IEEE floating point number) | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 15 | Peak Data Rate [p] (32-bit IEEE floating point number) | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 16 | Minimum Policed Unit [m] (32-bit integer) | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 17 | Maximum Packet Size [M] (32-bit integer) | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 18 | 124 (h) | 0 (i) | 2 (j) | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 19 | Rate [R] (32-bit IEEE floating point number) | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 20 | Slack Term [S] (32-bit integer) | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 21 | 125 (e) | 0 (f) | 5 (g) | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 22 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 23 | Token Bucket Size [b] (32-bit IEEE floating point number) | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 24 | Peak Data Rate [p] (32-bit IEEE floating point number) | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 25 | Minimum Policed Unit [m] (32-bit integer) | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 26 | Maximum Packet Size [M] (32-bit integer) | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 27 | 124 (h) | 0 (i) | 2 (j) | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 28 | Rate [R] (32-bit IEEE floating point number) | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 29 | Slack Term [S] (32-bit integer) | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 Figure 7. Multiple FLOWSPECs for Guaranteed service 830 (a) - Message format version number (0) 831 (b) - Overall length (9 words not including header) 832 (c) - Service header, service number 2 (Guaranteed) 833 (d) - Length of per-service data, 9 words not including 834 per-service header 835 (e) - Parameter ID, parameter 125 (Token Bucket TSpec) 836 (f) - Parameter 125 flags (none set) 837 (g) - Parameter 125 length, 5 words not including parameter header 838 (h) - Parameter ID, parameter 124 (Guaranteed Service RSpec) 839 (i) - Parameter 124 flags (none set) 840 (j) - Parameter 124 length, 2 words not including parameter header 842 There MUST be 1 RSPEC per TSPEC for Guaranteed Service. Therefore, 843 there are 5 words for Receiver TSPEC and 3 words for the RSPEC. 844 Therefore, for Guaranteed Service, the TSPEC/RSPEC combination 845 occurs in increments of 8 words. 847 4. Rules of Usage 849 The following rules apply to nodes adhering to this specification: 851 4.1 Backward Compatibility 853 If the recipient does not understand this extension, it ignores this 854 MULTI_TSPEC object, and operates normally for a node receiving this 855 RSVP message. 857 4.2 Applies to Only a Single Session 859 When there is more than one TSPEC object or more than one FLOWSPEC 860 object, this MUST NOT be considered for more than one flow created. 861 These are OR choices for the same flow of data. In order to attain 862 three reservations between two endpoints, three different 863 reservation requests are required, not one reservation request with 864 3 TSPECs. 866 4.3 No Special Error Handling for PATH Message 868 If a problem occurs with the PATH message - regardless of this 869 extension, normal RSVP procedures apply (i.e., there is no new 870 PathErr code created within this extension document) - resulting in 871 a PathErr message being sent upstream towards the sender, as usual. 873 4.4 Preference Order to be Maintained 875 When more than one TSPEC is in a PATH message, the order of TSPECs 876 is decided by the Sender and MUST be maintained within the 877 SENDER_TSPEC. The same order MUST be carried to the FLOWSPECs by 878 the receiver. No additional TSPECS can be introduced by the receiver 879 or any router processing these new objects. The deletion of TSPECs 880 from a PATH message is not permitted. The deletion of the TSPECs 881 when forming the FLOWSPEC is allowed by the receiver in the 882 following cases: 884 - If one or more preferred TSPECs cannot be granted by a router as 885 discovered during processing of the ADSPEC by the receiver, then 886 they can be omitted when creating the FLOWSPEC(s) from the TSPECs. 888 - If one or more TSPECs arriving from the sender is not preferred by 889 the receiver, then the receiver MAY omit any while creating the 890 FLOWSPEC. A good reason to omit a TSPEC is if, for example, it 891 does not match a codec supported by the receiver's application(s). 893 The deletion of the TSPECs in the router during the processing of 894 this MULTI_FLOWSPEC object is allowed in the following cases: 896 - If the original FLOWSPEC cannot be granted by a router then the 897 router may discard that FLOWSPEC and replace it with the topmost 898 FLOWSPEC from the MULTI_FLOWSPEC project. This will cause the 899 topmost FLOWSPEC in the MULTI_FLOWSPEC object to be removed. The 900 next FLOWSPECs becomes the topmost FLOWSPEC. 902 - If the router merges multiple RESV into a single RESV message, 903 then the FLOWSPEC and the multiple FLOWSPEC may be affected 905 The preferred order of the remaining TSPECs or FLOWSPECs MUST be 906 kept intact both at the receiver as well as the router processing 907 these objects. 909 4.5 Bandwidth Reduction in Downstream Routers 911 If there are multiple FLOWSPECs in a single RESV message, it is 912 quite possible that a higher bandwidth is reserved at a previous 913 downstream device. Thus, any device that grants a reservation that 914 is not the highest will have to inform the previous downstream 915 routers to reduce the bandwidth reserved for this particular 916 session. 918 The bandwidth reduction RFC [RFC4495] has the ability to partially 919 preempt existing reservations. However, it does not address the need 920 that this draft addresses. RFC 4495 defines an ability to preempt 921 part of an existing reservation so as to admit a new incoming 922 reservation with a higher priority, in lieu of tearing down the 923 whole reservation with lower priority. It does not specify the 924 capability to reduce the bandwidth a RESV set up along the data path 925 before the reservation is realized (from source to destination), 926 when a subsequent router cannot support a more preferred FLOWSPEC 927 contained in that RESV. This document will extend the RFC 4495 928 defined error to work for previous hops while a reservation is being 929 established. 931 4.6 Merging Rules 933 RFC 2205 defines the rules for merging as combining more than one 934 FLOWSPEC into a single FLOWSPEC. In the case of MULTI_FLOWSPECs, 935 merging of the two (or more) MULTI_FLOWSPEC MUST be done to arrive 936 at a single MULTI_FLOWSPEC. The merged MULTI_FLOWSPEC will contain 937 all the flow specification components of the individual 938 MULTI_FLOWSPECs in descending orders of bandwidth. In other words, 939 the merged FLOWSPEC MUST maintain the relative order of each of the 940 individual FLOWSPECs. For example, if the individual FLOWSPEC order 941 is 1,2,3 and another FLOWSPEC is a,b,c, then this relative ordering 942 cannot be altered in the merged FLOWSPEC. 944 A byproduct of this is the ordering between the two individual 945 FLOWSPECs cannot be signaled with this extension. If two (or more) 946 FLOWSPECs have the same bandwidth, they are to be merged into one 947 FLOWSPEC using the rules defined in RFC 2205. It is RECOMMENDED 948 that the following rules are used for determining ordering (in TSPEC 949 and FLOWSPEC): 951 For Controlled Load - in descending order of BW based on the 952 Token Bucket Rate 'r' parameter value 954 For Guaranteed Service - in descending order of BW based on the 955 RSPEC Rate 'R' parameter value 957 The resultant FLOWSPEC is added to the MULTI_FLOWSPEC based on its 958 bandwidth in descending orders of bandwidth. 960 As a result of such merging, the number of FLOWSPECs in a 961 MULTI_FLOWSPEC object should be the sum of the number of FLOWSPECs 962 from individual MULTI_FLOWSPEC that have been merged *minus* the 963 number of duplicates. 965 4.7 Applicability to Multicast 967 An RSVP message with a MULTI_TSPEC works just as well in a multicast 968 scenario as it does in a unicast scenario. In a multicast scenario, 969 the bandwidth allotted in each hop is the lowest bandwidth that can 970 be admitted along the various path. For example: 972 +--------+ +----------+ +----------+ +------------+ 973 | sender |======>| Router-1 |=====>| Router-2 |=====>| Receiver-A | 974 +--------+ +----------+ +----------+ +------------+ 975 | | 976 | | 977 | V 978 | +------------+ 979 | | Receiver-C | 980 | +------------+ 981 | 982 V 983 +------------+ 984 | Receiver-B | 985 +------------+ 987 Figure 8. MULTI_TPSEC and Multicast 989 If the sender (in Figure 8) sends 3 TSPECs (i.e., 1 TSPEC Object, 990 and 2 in the MULTI_TSPEC Object) of 12Mbps, 5Mbps and 1.5Mbps. Let 991 us say the path from Receiver-B to Router-1 admitted 5Mbps, 992 Receiver-C to Router-2 admitted 1.5Mbps and Receiver-A to Router-2 993 admitted 12Mbps. 995 When the Resv message is send upstream from Router-2, the combining 996 of 1.5Mbps (to Receiver-C) and 12Mbps (to Receiver-A) will be 997 resolved to 1.5Mbps (lowest that can be admitted). Only a Resv with 998 1.5Mbps will be sent upstream from Router-2. Likewise, at Router-1, 999 the combining of 1.5Mbps (to Router-2) and 5Mbps (to Receiver-B) 1000 will be resolved to 1.5Mbps units. 1002 This is to allow the sender to transmit the flow at a rate that can 1003 be accepted by all devices along the path. Without this, if Router-2 1004 receives a flow of 12Mbps, it will not know how to create a flow of 1005 1.5Mbps down to Receiver-B. A differentiated reservation for the 1006 various paths along a multicast path is only possible with a 1007 Media-aware network device (MANE). The discussion of MANE and how it 1008 relates to admission control is outside the scope of this draft. 1010 4.8 MULTI_TSPEC Specific Error 1012 Since this mechanism is backward compatible, it is possible that a 1013 router without support for this MULTI_TSPEC extension will reject a 1014 reservation because the bandwidth indicated in the primary FLOWSPECs 1015 is not available. This means that an attempt with a lower bandwidth 1016 might have been successful, if one were included in a MULTI_TSPEC 1017 Object. Therefore, one should be able to differentiate between an 1018 admission control error where there is insufficient bandwidth when 1019 all the FLOWSPECs are considered and insufficient bandwidth when 1020 only the primary FLOWSPEC is considered. 1022 This requires the definition of an error code within the ERROR_SPEC 1023 Object. When a router does not have sufficient bandwidth even after 1024 considering all the FLOWSPEC provided, it issues a new "MULTI_TSPEC 1025 bandwidth unavailable " error. This will be an Admission Control 1026 Failure (error #1), with a subcode of 6. A router that does not 1027 support this MULTI_TSPEC extension will return the "requested 1028 bandwidth unavailable" error as defined in RFC 2205 as if there was 1029 no MULTI_TSPEC in the message. 1031 4.9 Other Considerations 1033 - RFC 4495 articulates why a ResvErr is more appropriate to use for 1034 reducing the bandwidth of an existing reservation vs. a ResvTear. 1036 - Refreshes only include the TSPECs that were accepted. One SHOULD 1037 be sent immediately upon the Sender receiving the RESV, to 1038 ensure all routers in this flow are synchronized with which TSPEC 1039 is in place. 1041 - Periodically, it might be appropriate to attempt to increase the 1042 bandwidth of an accepted reservation with one of the TSPECs that 1043 were not accepted by the network when the reservation was first 1044 installed. This SHOULD NOT occur too regularly. This document 1045 currently offers no guidance on the frequency of this bump request 1046 for a rejected TSPEC from the PATH. 1048 4.10 Known Open Issues 1050 Here are the know open issues within this document: 1052 o Both the idea of MULTI_RSPEC and MULTI_FLOWSPEC need to be 1053 fleshed out, and IANA registered. 1055 o Need to ensure the cap on the number of TSPECs and FLOWSPECs is 1056 viable, yet controlled. 1058 5. Security considerations 1060 The security considerations for this document do not exceed what is 1061 already in RFC 2205 (RESV) or RFC 2210 (IntServ), as nothing in 1062 either of those documents prevent a node from requesting a lot of 1063 bandwidth in a single TSPEC. This document merely reduces the 1064 signaling traffic load on the network by allowing many requests that 1065 fall under the same policy controls to be included in a single 1066 round-trip message exchange. 1068 Further, this document does not increase the security risk(s) to 1069 that defined in RFC 4495, where this document creates additional 1070 meaning to the RFC 4495 created error code 102. 1072 A misbehaving Sender can include too many TSPECs in the 1073 MULTI_TSPEC object, which can lead to an amplification attack. That 1074 said, a bad implementation can create a reservation for each TSPEC 1075 received from within the Resv message. The number of TSPECs in the 1076 new MULTI_TSPEC object is limited, and the spec clearly states that 1077 only a single reservation is to be set up per Resv message. 1079 6. IANA considerations 1081 This document IANA registers the following new parameter name in the 1082 Integ-serv assignments at [IANA]: 1084 Registry Name: Parameter Names 1085 Registry: 1086 Value Description Reference 1087 -------- -------------------------------------------- --------- 1088 125 Multiple_Token_Bucket_Tspec [RFCXXXX] 1089 124 Multiple_Guaranteed_Service_RSpec [RFCXXXX] 1091 Where RFCXXXX is replaced with the RFC number assigned to this 1092 Document. 1094 This document IANA registers the following new error subcode in the 1095 Error code section, under the Admission Control Failure (error=1), 1096 of the rsvp-parameters assignments at [IANA]: 1098 Registry Name: Error Codes and Globally-Defined Error Value 1099 Sub-Codes 1100 Registry: 1101 "Admission Control 1102 Failure" 1103 Error Subcode meaning Reference 1104 ------------- ----------------------------------------- --------- 1105 6 = MULTI_TSPEC bandwidth unavailable [RFCXXXX] 1107 7. Acknowledgments 1109 The authors wish to thank Fred Baker, Joe Touch, Bruce Davie, Dave 1110 Oran, Ashok Narayanan, Lou Berger, Lars Eggert, Arun Kudur and Janet 1111 Gunn for their helpful comments and guidance in this effort. 1113 And to Francois Le Faucheur, who provided text in this version. 1115 8. References 1116 8.1. Normative References 1118 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1119 Requirement Levels", RFC 2119, March 1997 1121 [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 1122 "Resource ReSerVation Protocol (RSVP) -- Version 1 1123 Functional Specification", RFC 2205, September 1997 1125 [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 1126 Services", RFC 2210, September 1997 1128 [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of 1129 Guaranteed Quality of Service", RFC 2212, September 1997 1131 [RFC2215] S. Shenker, J. Wroclawski, "General Characterization 1132 Parameters for Integrated Service Network Elements", 1133 RFC 2212, September 1997 1135 [RFC4495] J. Polk, S. Dhesikan, "A Resource Reservation Protocol 1136 (RSVP) Extension for the Reduction of Bandwidth of a 1137 Reservation Flow", RFC 4495, May 2006 1139 8.2. Informative References 1141 [IANA] http://www.iana.org/assignments/integ-serv 1143 Authors' Addresses 1145 James Polk 1146 3913 Treemont Circle 1147 Colleyville, Texas, USA 1148 +1.817.271.3552 1150 mailto: jmpolk@cisco.com 1152 Subha Dhesikan 1153 Cisco Systems 1154 170 W. Tasman Drive 1155 San Jose, CA 95134 USA 1157 mailto: sdhesika@cisco.com 1159 Appendix A: Alternatives for Sending Multiple TSPECs 1161 This appendix describes the discussion within the TSVWG of which 1162 approach best fits the requirements of sending multiple TSPECs 1163 within a single PATH or RESV message. There were 3 different 1164 options proposed, of which - 2 were insufficient or caused more harm 1165 than other options. 1167 Looking at the format of a PATH message [RFC2205] again: 1169 ::= [ ] 1171 1173 1175 [ ... ] 1177 [ ] 1179 ::= 1180 ^^^^^^^^^^^^ 1181 [ ] 1183 For the PATH message, the focus of this document is with what to do 1184 with respect to the above, highlighted by the '^^^^' 1185 characters. No other object within the PATH message will be affected 1186 by this IntServ extension. 1188 The ADSPEC is optional in IntServ; therefore it might or might not 1189 be in the RSVP PATH message. Presently, the SENDER_TSPEC is limited 1190 to one bandwidth associated with the session. This is changed in 1191 this extension to IntServ to multiple bandwidths for the same 1192 session. There are multiple options on how the additional bandwidths 1193 may be added: 1195 Option #1 - creating the ability to add one or more additional 1196 (and complete) SENDER_TSPECs, 1198 or 1200 Option #2 - create the ability for the one already allowed 1201 SENDER_TSPEC to carry more than one bandwidth amount 1202 for the same reservation. 1204 or 1206 Option #3 - create the ability for the existing SENDER_TSPEC to 1207 remain unchanged, but add an optional 1208 object to the such as this: 1210 ::= 1212 [ ] [ ] 1213 ^^^^^^^^^^^ 1215 Here is another way of looking at the option choices: 1217 +--------------------+----------------------+---------------------+ 1218 | Option#1 | Option#2 | Option#3 | 1219 | | | | 1220 | +----------+ | +---------------+ | +----------+ | 1221 | | TSPEC1 | | | MULTI_TSPEC | | | TSPEC1 | | 1222 | +----------+ | | Object | | +----------+ | 1223 | | | +--------+ | | | 1224 | +----------+ | | | TSPEC1 | | | +---------------+ | 1225 | | TSPEC2 | | | +--------+ | | | MULTI_TSPEC | | 1226 | +----------+ | | +--------+ | | | Object | | 1227 | | | | TSPEC2 | | | | +--------+ | | 1228 | +----------+ | | +--------+ | | | | TSPEC2 | | | 1229 | | TSPEC3 | | | +--------+ | | | +--------+ | | 1230 | +----------+ | | | TSPEC3 | | | | +--------+ | | 1231 | | | +--------+ | | | | TSPEC3 | | | 1232 | +----------+ | | | TSPEC4 | | | | +--------+ | | 1233 | | TSPEC4 | | | +--------+ | | | +--------+ | | 1234 | +----------+ | +---------------+ | | | TSPEC4 | | | 1235 | | | | +--------+ | | 1236 | | | +---------------+ | 1237 | | | | 1238 +--------------------+----------------------+---------------------+ 1240 Figure 3. Concept of Option Choice 1242 Option #1 and #2 do not allow for backward compatibility. If the 1243 currently used SENDER_TSPEC and FLOWSPEC objects are changed, then 1244 unless all the routers requiring RSVP processing are upgraded, this 1245 functionality cannot be realized. As it is unlikely that all routers 1246 along the path will have the necessary enhancements as per this 1247 extension at one given time, therefore, it is necessary this 1248 enhancement be made in a way that is backward compatible. Therefore, 1249 option #1 and option #2 has been discarded in favor of option #3, 1250 which had WG consensus in a recent IETF meeting. 1252 Option #3: This option has the advantage of being backwards 1253 compatible with existing implementations of [RFC2205] and [RFC2210], 1254 as the multiple TSPECs and FLOWSPECs are inserted as optional 1255 objects and such objects do not need to be processed, especially if 1256 they are not understood. 1258 Option#3 applies to the FLOWSPEC contained in the RESV message as 1259 well. In this option, the original SENDER_TSPEC and the FLOWSPEC are 1260 left untouched, allowing routers not supporting this extension to be 1261 able to process the PATH and the RESV message without issue. Two new 1262 additional objects are defined in this document. They are the 1263 MULTI_TSPEC and the MULTI_FLOWSPEC for the PATH and the RESV 1264 message, respectively. The additional TSPECs (in the new MULTI_TSPEC 1265 Object) are included in the PATH and the additional FLOWSPECS (in 1266 the new MULTI_FLOWSPEC Object) are included in the RESV message as 1267 new (optional) objects. These additional objects will have a class 1268 number of 11bbbbbb, allowing older routers to ignore the object(s) 1269 and forward each unexamined and unchanged, as defined in section 1270 3.10 of [RFC 2205]. 1272 We state in the document body that the top most FLOWSPEC of the new 1273 MULTI_FLOWSPEC Object in the RESV message replaces the existing 1274 FLOWSPEC when it is determined by the receiver (perhaps along 1275 with the ADSPEC) that the original FLOWSPEC cannot be granted. 1276 Therefore, the ordering of preference issue is solved with Option#3 1277 as well. 1279 NOTE: it is important to emphasize here that including more than 1280 one FLOWSPEC in the RESV message does not cause more than one 1281 FLOWSPEC to be granted. This document requires that the 1282 receiver arrange these multiple FLOWSPECs in the order of 1283 preference according to the order remaining from the 1284 MULTI_TSPECs in the PATH message. The benefit of this 1285 arrangement is that RSVP does not have to process the rest of 1286 the FLOWSPEC if it can admit the first one. 1288 Additional details of these options can be found in the 1289 draft-polk-tsvwg-...-01 version of this appendix (which includes the 1290 RSVP bit mapping of fields in the TSPECs, if the reader wishes to 1291 search for that doc.