TSVWG WG James Polk Internet-Draft Subha Dhesikan Expires: January 13, 2010 Cisco Systems Intended Status: Standards Track (PS) July 13, 2009 Updates: RFC 2205, 2210, 4495 (if published as an RFC) Integrated Services (IntServ) Extension to Allow Multiple TSPECs draft-polk-tsvwg-intserv-multiple-tspec-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your Polk & Dhesikan Expires January 13, 2010 [Page 1] Internet-Draft IntServ MULTI_Bandwidth July 2009 rights and restrictions with respect to this document. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Abstract This document defines how Integrated Services (IntServ) includes multiple TSPECs and RSPECs in the same Resource Reservation Protocol (RSVPv1) reservation message exchange. This ability to send multiple TSPECs during reservation set-up helps optimize an agreeable bandwidth through a network between endpoints in a single round trip. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of the Options for including multiple TSPECs and FLOWSPECs . . . . . . . . . . . . 6 3. Overview of the Multi_TSPEC and MULTI_FLOWSPEC Solution . . . 8 3.1 New MULTI_TSPEC and MULTI-RSPEC Parameters . . . . . . . 10 3.2 Multiple TSPEC in a PATH Message . . . . . . . . . . . . 10 3.3 Multiple FLOWSPEC for Controlled Load Service . . . . . . 12 3.4 Multiple FLOWSPEC for Guaranteed Service . . . . . . . . 15 4. Rules of Usage . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 Backward Compatibility . . . . . . . . . . . . . . . . . 18 4.2 Applies to Only a Single Session . . . . . . . . . . . . 18 4.3 No Special Error Handling for PATH Message . . . . . . . 18 4.4 Preference Order to be Maintained . . . . . . . . . . . 18 4.5 Bandwidth Reduction in Downstream Routers . . . . . . . 19 4.6 Merging Rules . . . . . . . . . . . . . . . . . . . . . 19 4.7 Other Considerations . . . . . . . . . . . . . . . . . . 19 5. Security considerations . . . . . . . . . . . . . . . . . . . 20 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Option#2 Discussion . . . . . . . . . . . . . . . 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Polk & Dhesikan Expires January 13, 2010 [Page 2] Internet-Draft IntServ MULTI_Bandwidth July 2009 document are to be interpreted as described in RFC 2119 [RFC 2119]. Calling node = PATH generator throughout this document. Called node = RESV Generator throughout this document. 1. Introduction This document defines how Integrated Services (IntServ) [RFC2210] includes multiple TSPECs and multiple FLOWSPECs in the same Resource Reservation Protocol (RSVPv1) [RFC2205] message. This ability to send multiple TSPECs and multiple FLOWSPECs during reservation set up helps optimize an agreeable bandwidth through a network between endpoints in a single round trip. There is a separation of function between the two specifications, in which RSVPv1 does not define the internal objects to establish controlled load or guarantee services. These are generally left to be opaque in RSVPv1. At the same time, IntServ does not require that RSVPv1 be the only reservation protocol for transporting both the controlled load or guaranteed service objects - but RSVP does often carry the objects anyway. This makes the two independent - yet related in usage, but are also frequently talked about as if they are one and the same. They are not. The TSPEC - for 'traffic specification' - contains the traffic characteristics of a sender's data flow and is a required object in a PATH message. The TSPEC is defined in RFC 2210 and is generally opaque to RSVP. The ADSPEC - for 'advertising specification' - is used to gather information along the downstream data path to aid the PATH receiver in the computation of QoS properties of this data path. The ADSPEC is also opaque to RSVP and is defined in RFC 2210. Both of these IntServ objects are part of the Sender Descriptor [RFC2205]. Once the Sender Descriptor is received at its destination node, after having traveled through the network of routers, the SENDER_TSPEC information is matched with the information gathered in the ADSPEC about the data path. Together, these two objects help the receiver build its FLOWSPEC for the RESV message. The RESV message establishes the reservation through the network of routers on the data path established by the PATH message. The SENDER_TSPEC is not changed in transit between endpoints (i.e., there are no bandwidth request adjustments along the way). However, the ADSPEC is changed, based on the conditions experienced through the network as the RSVP message travels hop-by-hop. Today, real-time applications have evolved such that they are able to dynamically adapt to available bandwidth, not only by dropping and adding layers, but also by reducing frame rates and resolution. Thus the current mechanism of the Integrated Services, and therefore Polk & Dhesikan Expires January 13, 2010 [Page 3] Internet-Draft IntServ MULTI_Bandwidth July 2009 RSVP, allowing the PATH generator to only provide one traffic specification and for the resulting RESV generator to only include one bandwidth request is limiting. With only one SENDER_TSPEC in a PATH message and only one FLOWSPEC in a RESV message (in Fixed Filter style of FLOWSPEC, there are multiple FLOWSPEC but only one per filterspec), applications will either have to accept the rejection or resort to multiple roundtrips to get the available bandwidth when its original request is not admitted. Since such real-time applications are time-sensitive, participating in multiple roundtrips for establishing bandwidth reservations is not a preferred option. The objective of this draft is to prevent such roundtrips as well as allow applications to successfully receive some level of bandwidth allotment that it can use for its sessions. While the ADSPEC provides an indication of the bandwidth available along the path and can be used by the RESV generator in creating the FLOWSPEC, it does not prevent failures or multiple round-trips as described above. The intermediary routers provide a best attempt estimate of available bandwidth in the ADSPEC object. However, it does not take into account external policy considerations (RFC 2215). In addition, the available bandwidth at the time of creating the ADSPEC may not be available at the time of an actual request in an RESV message. These reasons may cause the RESV message to be rejected. Therefore, the ADSPEC object cannot, by itself, satisfy the requirements of the current generations of real-time applications. It needs to be noted that the ADSPEC is unchanged by this new mechanism. If ADSPEC is included in the PATH message, it is suggested that the RESV generator use this object in determining the FLOWSPEC. This document creates a means for asking for more than one bandwidth within the same RSVP reservation set-up (both PATH and RESV) messages to optimize the determination of an agreed upon bandwidth for this reservation. Allowing multiple TSPECs within the same PATH message permits multiple bandwidths to be chosen from by the RECEIVER, when the received ADSPEC is processed. This optimizes reservation establishment. This allows the applications to dynamically adapt their data stream to available network resources. The concept of RSVP signaling is shown in a single direction below, in Figure 1. Although the TSPEC is opaque to RSVP, it is shown along with the RSVP messages for completeness. The RSVP messages themselves need not be the focus of the reader. Instead, the number of round trips it takes to establish a reservation is the focus here. Polk & Dhesikan Expires January 13, 2010 [Page 4] Internet-Draft IntServ MULTI_Bandwidth July 2009 Calling node Rtr-1 Rtr-2 ... Rtr-N Called node | | | | | | PATH (with a TSPEC & ADSPEC) | |------------->|--------->|----//--->|-------------->| | | | | | | RESV (with a FLOWSPEC) | |<-------------|<---------|<---//----|<--------------| | | | | | Figure 1. Concept of RSVP in a Single Direction Figure 1 shows a successful one-way reservation using RSVP and IntServ. Figure 2 shows a scenario where the RESV message, containing a FLOWSPEC, which is generated by the Called node, after considering both the Sender TSPEC and the ADSPEC, is rejected by an intermediary router. Calling node Rtr-1 Rtr-2 ... Rtr-N Called node | | | | | | PATH (with 1 TSPEC wanting 12Mbps) | |------------->|--------->|----//--->|-------------->| | | | | | | | RESV (with 1 FLOWSPEC wanting 12Mbps) | | | X <--//----|<--------------| | | | | | | ResvErr (with Admission control Error=2) | | | |----//--->|-------------->| | | | | | Figure 2. Concept of RSVP Rejection due to Limited Bandwidth The scenario above is where multiple TSPEC and multiple FLOWSPEC optimization helps. The Calling node may support multiple bandwidths for a given application (i.e., more than one codec for voice or video) and therefore might want to establish a reservation with the highest (or best) bandwidth that the network can provide for a particular codec. For example, bandwidths of: 12Mbps, 4Mbps, and 1.5Mbps for the three video codecs the Calling Node supports. This document will discuss the various options to include multiple TSPECs and FLOWSPECs as well as the preferred option in section 2. In section 3, the overview of the entire solution is provided. This Polk & Dhesikan Expires January 13, 2010 [Page 5] Internet-Draft IntServ MULTI_Bandwidth July 2009 section also contains the new parameters which are defined in this document. The multiple TSPECs in a PATH message and the multiple FLOWSPEC in a RESV message, both for controlled load and guaranteed service are described in this section. Section 4 will cover the rules of usage of this IntServ extension. This section contains how this document needs to extend the scenario of when a router in the middle of a reservation cannot accept a preferred bandwidth (i.e., FLOWSPEC), meaning previous routers that accepted that greater bandwidth now have too much bandwidth reserved. This requires an extension to RFC 4495 (RSVP Bandwidth Reduction) to cover reservations being established, as well as existing reservations. Section 4 also includes the merging rules. 2. Overview of the Options for Including Multiple TSPECs and FLOWSPECS Presently, this is the format of a PATH message [RFC2205]: ::= [ ] [ ... ] [ ] ::= ^^^^^^^^^^^^ [ ] For the PATH message, the focus of this document is with what to do with respect to the above, highlighted by the '^^^^' characters. No other object within the PATH message will be affected by this IntServ extension. The ADSPEC is optional in IntServ; therefore it might or might not be in the RSVP PATH message. Presently, the SENDER_TSPEC is limited to one bandwidth associated with the session. This is changed in this extension to IntServ to multiple bandwidths for the same session. There are multiple options on how the additional bandwidths may be added: Option #1 - creating the ability to add one or more additional (and complete) SENDER_TSPECs, or Option #2 - create the ability for the one already allowed SENDER_TSPEC to carry more than one bandwidth amount Polk & Dhesikan Expires January 13, 2010 [Page 6] Internet-Draft IntServ MULTI_Bandwidth July 2009 for the same reservation. or Option #3 - create the ability for the existing SENDER_TSPEC to remain unchanged, but add an optional object to the such as this: ::= [ ] [ ] ^^^^^^^^^^^ Here is another way of looking at the option choices: +--------------------+----------------------+---------------------+ | Option#1 | Option#2 | Option#3 | | | | | | +----------+ | +---------------+ | +----------+ | | | TSPEC1 | | | MULTI_TSPEC | | | TSPEC1 | | | +----------+ | | Object | | +----------+ | | | | +--------+ | | | | +----------+ | | | TSPEC1 | | | +---------------+ | | | TSPEC2 | | | +--------+ | | | MULTI_TSPEC | | | +----------+ | | +--------+ | | | Object | | | | | | TSPEC2 | | | | +--------+ | | | +----------+ | | +--------+ | | | | TSPEC2 | | | | | TSPEC3 | | | +--------+ | | | +--------+ | | | +----------+ | | | TSPEC3 | | | | +--------+ | | | | | +--------+ | | | | TSPEC3 | | | | +----------+ | | | TSPEC4 | | | | +--------+ | | | | TSPEC4 | | | +--------+ | | | +--------+ | | | +----------+ | +---------------+ | | | TSPEC4 | | | | | | | +--------+ | | | | | +---------------+ | | | | | +--------------------+----------------------+---------------------+ Figure 3. Concept of Option Choice Option #1 and #2 do not allow for backward compatibility. If the currently used SENDER_TSPEC and FLOWSPEC objects are changed, then unless all the routers requiring RSVP processing are upgraded, this functionality cannot be realized. As it is unlikely that all routers along the path will have the necessary enhancements as per this extension at one given time, therefore, it is necessary this enhancement be made in a way that is backward compatible. Therefore, option #1 and option #2 has been discarded in favor of option #3, which had WG consensus in a recent IETF meeting. Option #3: This option has the advantage of being backwards Polk & Dhesikan Expires January 13, 2010 [Page 7] Internet-Draft IntServ MULTI_Bandwidth July 2009 compatible with existing implementations of [RFC2205] and [RFC2210], as the multiple TSPECs and FLOWSPECs are inserted as optional objects and such objects do not need to be processed, especially if they are not understood. Option#3 applies to the FLOWSPEC contained in the RESV message as well. In this option, the original SENDER_TSPEC and the FLOWSPEC are left untouched, allowing routers not supporting this extension to be able to process the PATH and the RESV message without issue. Two new additional objects are defined in this document. They are the MULTI_TSPEC and the MULTI_FLOWSPEC for the PATH and the RESV message, respectively. The additional TSPECs (in the new MULTI_TSPEC Object) are included in the PATH and the additional FLOWSPECS (in the new MULTI_FLOWSPEC Object) are included in the RESV message as new (optional) objects. These additional objects will have a class number of 11bbbbbb, allowing older routers to ignore the object(s) and forward each unexamined and unchanged, as defined in section 3.10 of [RFC 2205]. We state later that the top most FLOWSPEC of the new MULTI_FLOWSPEC Object in the RESV message replaces the existing FLOWSPEC when it is determined by the called node (perhaps along with the ADSPEC) that the original FLOWSPEC cannot be granted. Therefore, the ordering of preference issue is solved with Option#3 as well. NOTE: it is important to emphasize here that including more than one FLOWSPEC in the RESV message does not cause more than one FLOWSPEC to be granted. This document requires that the RESV generator arrange these multiple FLOWSPECs in the order of preference according to the order remaining from the MULTI_TSPECs in the PATH message. The benefit of this arrangement is that RSVP does not have to process the rest of the FLOWSPEC if it can admit the first one. Additional Option #2 discussion (from the previous version of this document) has been moved to the Appendix. [Editor's Note: since section 2 has been expanded in greater detail explaining each of the options and the conclusion reached in the WG, is it necessary to have a complete discussion on an option the WG rejected? We are thinking not. In other words, should the option #2 discussion be left in the appendix, be brought in to the main part of the document, or just deleted?] 3. Overview of the Multi_TSPEC and MULTI_FLOWSPEC Solution This section discusses the MULTI_TSPEC and MULTI_FLOWSPEC solution. For the Sender Descriptor within the PATH message, the original TSPEC remains where it is, and is untouched by this IntServ extension. What is new is the object, which is shown Polk & Dhesikan Expires January 13, 2010 [Page 8] Internet-Draft IntServ MULTI_Bandwidth July 2009 here: ::= [ ] [ ] ^^^^^^^^^^^ The preferred order of TSPECs sent by the PATH generator is this: - preferred TSPEC is in the original SENDER_TSPEC - the next in line preferred TSPEC is the first TSPEC in the MULTI_TSPEC object - the next in line preferred TSPEC is the second TSPEC in the MULTI_TSPEC object - and so on... The FLOWSPEC composition depends upon the reservation style requested in the RESV message. Therefore, the following shows the inclusion of the MULTI_FLOWSPEC object with each of the styles: WF Style: ::= ::= [MULTI_FLOWSPEC] FF style: ::= [MULTI_FLOWSPEC] | ::= [ ] [MULTI_FLOWSPEC] SE style: ::= ::= [MULTI_FLOWSPEC] ::= | Polk & Dhesikan Expires January 13, 2010 [Page 9] Internet-Draft IntServ MULTI_Bandwidth July 2009 3.1 New MULTI_TSPEC and MULTI-RSPEC Parameters This extension to Integrated Services defines two new parameter names for . They are: 1. Multiple_Token_Bucket_Tspec, with a parameter number of 125. 2. Multiple_Guaranteed_Service_RSpec with a parameter name of 124 These are IANA registered in this document. The original SENDER_TSPEC and FLOWSPEC for Controlled Service maintain the of Token_Bucket_Tspec with a parameter number of 127. The original FLOWSPEC for Guaranteed Service maintains the of Guaranteed_Service_RSpec with a parameter number of 130. 3.2 Multiple TSPEC in a PATH Message Here is the object from [RFC2210]. It is used as a SENDER_TSPEC in a PATH message: 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | X (c) |0| reserved | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. SENDER_TSPEC in PATH (a) - Message format version number (0) (b) - Overall length (7 words not including header) (c) - Service header, service number - '1' (Generic information) if in a PATH message; (d) - Length of service data, 6 words not including per-service header Polk & Dhesikan Expires January 13, 2010 [Page 10] Internet-Draft IntServ MULTI_Bandwidth July 2009 (e) - Parameter ID, parameter 127 (Token Bucket TSpec) (f) - Parameter 127 flags (none set) (g) - Parameter 127 length, 5 words not including per-service header For Option #3, Figure 4 is included in its original form for backwards compatibility reasons, as if there were only 1 TSPEC in the PATH. What is new when there are more than one TSPEC in this reservation message is the new MULTI_TSPEC object in Figure 5 containing, for example, 3 (Multiple_Token_Bucket_Tspec) TSPECs in a PATH message. 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 19 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 5 (c) |0| reserved | 18 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 19 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Polk & Dhesikan Expires January 13, 2010 [Page 11] Internet-Draft IntServ MULTI_Bandwidth July 2009 20 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. MULTI_TSPEC Object (a) - Message format version number (0) (b) - Overall length (19 words not including header) (c) - Service header, service number 5 (Controlled-Load) (d) - Length of service data, 18 words not including per-service header (e) - Parameter ID, parameter 125 (Multiple Token Bucket TSpec) (f) - Parameter 125 flags (none set) (g) - Parameter 125 length, 5 words not including per-service header Figure 5 shows the 2nd through Nth TSPEC in the PATH in the preferred order. The message format (a) remains the same for a second TSPEC and for other additional TSPECs. The Overall Length (b) includes all the TSPECs within this object, plus the 2nd Word (containing fields (c) and (d)), which MUST NOT be repeated. The service header fields (e),(f) and(g) are repeated for each TSPEC. The Service header, here service number 5 (Controlled-Load) MUST remain the same. Each TSPEC is six 32-bit Words long (the per-service header plus the 5 values that are 1 Word each in length), therefore the length is in 6 Word increments for each additional TSPEC. Case in point, from the above Figure 5, Words 3-8 are the first TSPEC (2nd preferred), Words 9-14 are the next TSPEC (3rd preferred), and Words 15-20 are the final TSPEC (and 4th preferred) in this example of 3 TSPECs in this MULTI_TSPEC object. There is no limit placed on the number of TSPECs a MULTI_TSPEC object can have. However, it is RECOMMENDED to administratively limit the number of TSPECs in the MULTI_TSPEC object to 16 (making for a total of 17 in the PATH message). The TSPECS are included in the order of preference by the message generator (PATH) and MUST be maintained in that order all the way to the Called Node. The order of TSPECs that are still grantable, in conjunction with the ADSPEC at the Called Node, MUST retain that order in the FLOWSPEC and MULTI_FLOWSPEC objects. 3.3 Multiple FLOWSPEC for Controlled-Load service The format of an RSVP FLOWSPEC object requesting Controlled-Load service is the same as the one used for the SENDER_TSPEC given in Figure 4. The format of the new MULTI_FLOWSPEC object is given below: Polk & Dhesikan Expires January 13, 2010 [Page 12] Internet-Draft IntServ MULTI_Bandwidth July 2009 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 19 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 5 (c) |0| reserved | 18 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 19 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. Multiple FLOWSPEC for Controlled-Load service (a) - Message format version number (0) (b) - Overall length (19 words not including header) (c) - Service header, service number 5 (Controlled-Load) (d) - Length of controlled-load data, 18 words not including per-service header (e) - Parameter ID, parameter 125 (Multiple Token Bucket TSpec) (f) - Parameter 125 flags (none set) Polk & Dhesikan Expires January 13, 2010 [Page 13] Internet-Draft IntServ MULTI_Bandwidth July 2009 (g) - Parameter 125 length, 5 words not including per-service header This is for the 2nd through Nth TSPEC in the RESV, in the preferred order. The message format (a) remains the same for a second TSPEC and for additional TSPECs. The Overall Length (b) includes the TSPECs, plus the 2nd Word (fields (c) and (d)), which MUST NOT be repeated. The service header fields (e),(f) and(g), which are repeated for each TSPEC. The Service header, here service number 5 (Controlled-Load) MUST remain the same for the RESV message. The services, Controlled-Load and Guaranteed MUST NOT be mixed within the same RESV message. In other words, if one TSPEC is a Controlled Load service TSPEC, the remaining TSPECs MUST be Controlled Load service. This same rule also is true for Guaranteed Service - if one TSPEC is for Guaranteed Service, the rest of the TSPECs in this PATH or RESV MUST be for Guaranteed Service. The Length of controlled-load data (d) also increases to account for the additional TSPECs. Each FLOWSPEC is six 32-bit Words long (the per-service header plus the 5 values that are 1 Word each in length), therefore the length is in 6 Word increments for each additional TSPEC. Case in point, from the above Figure 5, Words 3-8 are the first TSPEC (2nd preferred), Words 9-14 are the next TSPEC (3rd preferred), and Words 15-20 are the final TSPEC (and 4th preferred) in this example of 3 TSPECs in this FLOWSPEC. There is no limit placed on the number of TSPECs a particular FLOWSPEC can have. Within the MULTI_FLOWSPEC, any SENDERS_TSPEC that cannot be reserved - based on the information gathered in the ADSPEC, is not placed in the RESV. Otherwise, the order in which the TSPECs were in the PATH message MUST be in the same order they are in the FLOWSPEC in the RESV. This is the order of preference of the PATH generator, and MUST be maintained throughout the reservation establishment, unless the ADSPEC indicates one or more TSPECs cannot be granted, or one or more routers along the RESV path cannot grant a particular TSPEC. At any router that a reservation cannot honor a TSPEC, this TSPEC MUST be removed from the RESV, or else another router along the RESV path might reserve that TSPEC. This rule ensures this cannot happen. Once one TSPEC has been removed from the RESV, the next in line TSPEC becomes the preferred TSPEC for that reservation. That router MUST generate a ResvErr message, containing an ERROR_SPEC object with a Policy Control Failure with Error code = 2 (Policy Control Polk & Dhesikan Expires January 13, 2010 [Page 14] Internet-Draft IntServ MULTI_Bandwidth July 2009 Failure), and an Error Value sub-code 102 (ERR_PARTIAL_PREEMPT) to the previous routers, clearing the now over allocation of bandwidth for this reservation. The difference between the previously accepted TSPEC bandwidth and the currently accepted TSPEC bandwidth is the amount this error identifies as the amount of bandwidth that is no longer required to be reserved. The ResvErr and the RESV messages are independent, and not normally sent by the same router. This aspect of this document is the extension to RFC 2205 (RSVPv1). If a RESV cannot grant the final TSPEC, normal RSVP rules apply with regard to the transmission of a particular ResvErr. 3.4 Multiple FLOWSPEC for Guaranteed service The FLOWSPEC object, which is used to request guaranteed service contains a TSpec and RSpec. Here is the FLOWSPEC object from [RFC2215] when requesting Guaranteed service: 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | Unused | 10 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 2 (c) |0| reserved | 9 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 130 (h) | 0 (i) | 2 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Rate [R] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Slack Term [S] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6. FLOWSPEC for Guaranteed service (a) - Message format version number (0) (b) - Overall length (9 words not including header) (c) - Service header, service number 2 (Guaranteed) (d) - Length of per-service data, 9 words not including per-service header (e) - Parameter ID, parameter 127 (Token Bucket TSpec) Polk & Dhesikan Expires January 13, 2010 [Page 15] Internet-Draft IntServ MULTI_Bandwidth July 2009 (f) - Parameter 127 flags (none set) (g) - Parameter 127 length, 5 words not including parameter header (h) - Parameter ID, parameter 130 (Guaranteed Service RSpec) (i) - Parameter xxx flags (none set) (j) - Parameter xxx length, 2 words not including parameter header The difference in structure between the Controlled-Load FLOWSPEC and Guaranteed FLOWSPEC is the RSPEC, defined in [RFC2212]. For Option #3, Figure 6 is included in its original form for backwards compatibility reasons, as if there were only 1 FLOWSPEC in the RESV. What is new when there is more than one TSPEC in the FLOWSPEC in a RESV message is the new MULTI_FLOWSPEC object in Figure 7 containing, for example, 3 FLOWSPECs requesting Guaranteed Service. 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | Unused | 28 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 2 (c) |0| reserved | 27 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 124 (h) | 0 (i) | 2 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Rate [R] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Slack Term [S] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Polk & Dhesikan Expires January 13, 2010 [Page 16] Internet-Draft IntServ MULTI_Bandwidth July 2009 18 | 124 (h) | 0 (i) | 2 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 19 | Rate [R] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | Slack Term [S] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 21 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 22 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 23 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 25 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 26 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 27 | 124 (h) | 0 (i) | 2 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28 | Rate [R] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 29 | Slack Term [S] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7. Multiple FLOWSPECs for Guaranteed service (a) - Message format version number (0) (b) - Overall length (9 words not including header) (c) - Service header, service number 2 (Guaranteed) (d) - Length of per-service data, 9 words not including per-service header (e) - Parameter ID, parameter 125 (Token Bucket TSpec) (f) - Parameter 125 flags (none set) (g) - Parameter 125 length, 5 words not including parameter header (h) - Parameter ID, parameter 124 (Guaranteed Service RSpec) (i) - Parameter 124 flags (none set) (j) - Parameter 124 length, 2 words not including parameter header There MUST be 1 RSPEC per TSPEC for Guaranteed Service. Therefore, there are 5 words for Receiver TSPEC and 3 words for the RSPEC. Therefore, for Guaranteed Service, the TSPEC/RSPEC combination occurs in increments of 8 words. 4. Rules of Usage The following rules apply to nodes adhering to this specification: Polk & Dhesikan Expires January 13, 2010 [Page 17] Internet-Draft IntServ MULTI_Bandwidth July 2009 4.1 Backward Compatibility If the recipient does not understand this extension, it ignores this MULTI_TSPEC object, and operates normally for a node receiving this RSVP message. 4.2 Applies to Only a Single Session When there is more than one TSPEC object or more than one FLOWSPEC object, this MUST NOT be considered for more than one flow created. These are OR choices for the same flow of data. In order to attain three reservations between two endpoints, three different reservation requests are required, not one reservation request with 3 TSPECs. 4.3 No Special Error Handling for PATH Message If a problem occurs with the PATH message - regardless of this extension, normal RSVP procedures apply (i.e., there is no new PathErr code created within this extension document) - resulting in a PathErr message being sent upstream towards the PATH originator, as usual. 4.4 Preference Order to be Maintained When more than one TSPEC is in a PATH message, the order of TSPECs is decided by the Calling Node and MUST be maintained within the SENDER_TSPEC. The same order MUST be carried to the FLOWSPECs by the RESV Generator. No additional TSPECS can be introduced by the Resv generator or the router processing these new objects. The deletion of TSPECs from a PATH message is not permitted. The deletion of the TSPECs when forming the FLOWSPEC is allowed by the Resv generator in the following cases: - If one or more preferred TSPECs cannot be granted by a router as discovered during processing of the ADSPEC by the RESV Generator, then they can be omitted when adding the TSPECs to the FLOWSPEC. - If one or more TSPECs arriving in the PATH message at the Called Node is not preferred by the Resv Generator, then it MAY omit them while creating the FLOWSPEC. The deletion of the TSPECs in the router during the processing of this MULTI_FLOWSPEC object is allowed in the following cases: - If the original FLOWSPEC cannot be granted by a router then the router may discard that FLOWSPEC and replace it with the topmost FLOWSPEC from the MULTI_FLOWSPEC project. This will cause the topmost FLOWSPEC in the MULTI_FLOWSPEC object to be removed. The Polk & Dhesikan Expires January 13, 2010 [Page 18] Internet-Draft IntServ MULTI_Bandwidth July 2009 next FLOWSPECs becomes the topmost FLOWSPEC. The preferred order of the remaining TSPECs MUST be kept intact both the Resv Generator as well as the router processing these objects. 4.5 Bandwidth Reduction in Downstream Routers If there are multiple FLOWSPECs in a single RESV message, it is quite possible that a higher bandwidth is reserved at a previous downstream device. Thus, any device that grants a reservation that is not the highest will have to inform the previous downstream routers to reduce the bandwidth reserved for this particular session. The bandwidth reduction RFC [RFC4495] has the ability to partially preempt existing reservations. However, it does not address the need that this draft addresses. RFC 4495 defines an ability to preempt part of an existing reservation so as to admit a new incoming reservation with a higher priority, in lieu of tearing down the whole reservation with lower priority. It does not specify the capability to reduce the bandwidth a RESV set up along the data path before the reservation is realized (from source to destination), when a subsequent router cannot support a more preferred FLOWSPEC contained in that RESV. This document will extend the RFC 4495 defined error to work for previous hops while a reservation is being established. 4.6 Merging Rules RFC 2205 defines the rules for merging two FLOWSPECs into a single FLOWSPEC. In the case of MULTI_FLOWSPECs, merging of the two or more MULTI-FLOWSPEC must be done to arrive at a single MULTI_FLOWSPEC. The merged MULTI_FLOWSPEC will contain all the flow specification components of the individual MULTI_FLOWSPECs in descending orders of bandwidth. If two FLOWSPECs have the same bandwidth, then they are to be merged into one FLOWSPEC using the rules defined in RFC 2205. The resultant FLOWSPEC is added to the MULTI_FLOWSPEC based on its bandwidth in descending orders of bandwidth. As a result of such merging, the number of FLOWSPECs in a MULTI_FLOWSPEC object should be the sum of the number of FLOWSPECs from individual MULTI_FLOWSPEC that have been merged. For each duplicate, the number of FLOWSPEC will be reduced by one. 4.7 Other Considerations - RFC 4495 articulates why a ResvErr is more appropriate to use for reducing the bandwidth of an existing reservation, vs. a ResvTear. - Refreshes only include the TSPECs that were accepted. One SHOULD Polk & Dhesikan Expires January 13, 2010 [Page 19] Internet-Draft IntServ MULTI_Bandwidth July 2009 be sent immediately upon the Calling node receiving the RESV, to ensure all routers in this flow are synchronized with which TSPEC is in place. - Periodically, it might be appropriate to attempt to increase the bandwidth of an accepted reservation with one of the TSPECs that were not accepted by the network when the reservation was first installed. This SHOULD NOT occur too regularly. This document currently offers no guidance on the frequency of this bump request for a rejected TSPEC from the PATH. 5. Security considerations The security considerations for this document do not exceed what is already in RFC 2205 (RESV) or RFC 2210 (IntServ), as nothing in either of those documents prevent a node from requesting a lot of bandwidth in a single TSPEC. This document merely reduces the signaling traffic load on the network by allowing many requests that fall under the same policy controls to be included in a single round-trip message exchange. Further, this document does not increase the security risk(s) to that defined in RFC 4495, where this document creates additional meaning to the RFC 4495 created error code 102. A misbehaving Calling Node can include too many TSPECs in the MULTI_TSPEC object, which can lead to an amplification attack. That said, a bad implementation can create a reservation for each TSPEC received from within the Resv message. The number of TSPECs in the new MULTI_TSPEC object is limited, and the spec clearly states that only a single reservation is to be set up per Resv message. 6. IANA considerations This document IANA registers the following new parameter name in the Integ-serv assignments at [IANA]: Registry Name: Parameter Names Registry: Value Description Reference -------- -------------------------------------------- --------- 125 Multiple_Token_Bucket_Tspec [RFCXXXX] 124 Multiple_Guaranteed_Service_RSpec [RFCXXXX] Where RFCXXXX is replaced with the RFC number assigned to this Document. Polk & Dhesikan Expires January 13, 2010 [Page 20] Internet-Draft IntServ MULTI_Bandwidth July 2009 7. Acknowledgments The authors wish to thank Francois Le Faucheur, Fred Baker, Joe Touch, Bruce Davie, Dave Oran, Ashok Narayanan, Lou Berger, Lars Eggert and Janet Gunn for their helpful comments and guidance in this effort. 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997 [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997 [RFC2215] S. Shenker, J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2212, September 1997 [RFC4495] J. Polk, S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006 8.2. Informative References [IANA] http://www.iana.org/assignments/integ-serv Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Subha Dhesikan Cisco Systems 170 W. Tasman Drive Polk & Dhesikan Expires January 13, 2010 [Page 21] Internet-Draft IntServ MULTI_Bandwidth July 2009 San Jose, CA 95134 USA mailto: sdhesika@cisco.com Appendix A: Multiple Sender and Receiver in Single TSPEC Modification Appendix A here discusses our solution from an Option #2 perspective (i.e., this appendix assumes there is a single group of TSPEC object, with multiple TSPECs within that object - for both SENDER_TSPECs (in a PATH) and RECEIVER_TSPECs (in a RESV)). See Section 3 for the Option #3 discussion of our solution involving more than one TSPEC object (i.e., the original TSPEC as defined in [RFC2210] plus the new MULTI_TSPEC object defined here). These TSPEC parameters are used by data senders to describe the traffic parameters of traffic it expects to generate, and by QoS control services to describe the parameters of traffic for which the reservation should apply [RFC 2215]. This appendix specifies the detailed contents and wire format of a TSPEC that has been modified to allow multiple bandwidths, hence the term "Multiple TSPECs". A.1 New Multiple_Token_Bucket_Tspec Parameter in TSPEC This extension to Integrated Services allows to use a new . This document creates the new Multiple_Token_Bucket_Tspec, with a parameter number of 125. This is IANA registered in this document. It is the combination of the two that indicates the type of object is proposed for this data flow, which is consistent with the rules established in [RF2210]. When there is more than one TSPEC, this MUST NOT be considered for more than one flow. These are OR choices for the same flow of data. In order to attain 3 reservations between two endpoints, 3 different reservation requests are required, not one reservation request with 3 TSPECs. This optimization, for example in a RESV FLOWSPEC, is to attain the available bandwidth in a single request, instead of a request-fail, (time wasted) another request-fail, (more time wasted) then finally a request-succeed. The above multiple roundtrips take longer than it needs to, and the purpose of this document is how to make this situation go away (for compliant nodes). Polk & Dhesikan Expires January 13, 2010 [Page 22] Internet-Draft IntServ MULTI_Bandwidth July 2009 A.2 SENDER_TSPEC and FLOWSPEC for Controlled-Load service Here is the object from [RFC2210]. It is used as a SENDER_TSPEC and as a RECEIVER_TSPEC (with one exception) requesting Controlled-Load service with different Service Headers: 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | X (c) |0| reserved | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A1. TSPEC (in SENDER_TSPEC in PATH and RECEIVER_TSPEC in RESV) (a) - Message format version number (0) (b) - Overall length (7 words not including header) (c) - Service header, service number - '1' (Generic information) if in a PATH message; - '5' (Controlled-Load) if in a RESV message (d) - Length of service data, 6 words not including per-service header (e) - Parameter ID, parameter 127 (Token Bucket TSPEC) (f) - Parameter 127 flags (none set) (g) - Parameter 127 length, 5 words not including per-service header Again, based on Option #2 - here is the new TSPEC object containing, for example, 3 (Multiple Token Bucket TSPEC) TSPECs when requesting Controlled-Load service. This is based on option #2 mentioned above. The SENDER_TSPEC with a Multiple_Token_Bucket_Tspec will differ in only one respect when this is inserted into the FLOWSPEC of the RESV. That difference is in the service number field (c), in which the SENDER_TSPEC has a '1', the FLOWSPEC has a '5' - indicating Controlled Load service. Both will have the new Parameter ID of 125, which is IANA registered with this document. Polk & Dhesikan Expires January 13, 2010 [Page 23] Internet-Draft IntServ MULTI_Bandwidth July 2009 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 19 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 5 (c) |0| reserved | 18 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15 | 125 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 19 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A2. Multiple TSPECs for Controlled-Load service (a) - Message format version number (0) (b) - Overall length (19 words not including header) (c) - Service header, service number 5 (Controlled-Load) (d) - Length of controlled-load data, 18 words not including per-service header (e) - Parameter ID, parameter 125 (Multiple Token Bucket TSPEC) Polk & Dhesikan Expires January 13, 2010 [Page 24] Internet-Draft IntServ MULTI_Bandwidth July 2009 (f) - Parameter 125 flags (none set) (g) - Parameter 125 length, 5 words not including per-service header The message format (a) remains the same for one TSPEC and multiple TSPECs. The Overall Length (b) increases to include the additional TSPECs only, plus the 2nd and 3rd Words - which also MUST NOT be repeated, which includes fields (c) and (d), and (e), (f) and (g), respectively. The Service header, here service number 5 (Controlled-Load) MUST remain the same. The services, Controlled-Load and Guaranteed MUST NOT be mixed within the same RESV message. In other words, if one TSPEC is a Controlled Load service TSPEC, the remaining TSPECs MUST be Controlled Load service. This same rule also is true for Guaranteed Service - if one TSPEC is for Guaranteed Service, the rest of the TSPECs in this PATH or RESV MUST be for Guaranteed Service. The Length of controlled-load data (d) also increases to account for the additional TSPECs. Each TSPEC is six 32-bit Words long (the per-service header plus the 5 values that are 1 Word each in length), therefore the length is in 6 Word increments for each additional TSPEC. Case in point, from the above Figure 5, Words 3-8 are the first TSPEC, Words 9-14 are the next TSPEC, and Words 15-20 are the final TSPEC in this example of 3 TSPECs in this FLOWSPEC. There is no limit placed on the number of TSPECs a particular FLOWSPEC can have. The TSPECS are included in the order of preference by the message generator (PATH and RESV) and MUST be maintained in that order. Within the Sender_Descriptor, any TSPEC that cannot be reserved - based on the information gathered in the ADSPEC, is not placed in the RESV. Otherwise, the order in which the TSPECs were in the PATH message MUST be in the same order they are in the FLOWSPEC in the RESV. This is the order of preference of the PATH generator, and MUST be maintained throughout the reservation establishment, unless the ADSPEC indicates one or more TSPECs cannot be granted, or one or more routers along the RESV path cannot grant a particular TSPEC. The ADSPEC directly affects which TSPEC(s) are placed in the RESV. At any router that a reservation cannot honor a TSPEC, this TSPEC MUST be removed from the RESV, or else another router along the RESV path might reserve that TSPEC. This rule ensures this cannot happen. Once one TSPEC has been removed from the RESV, the next in line TSPEC becomes the preferred TSPEC for that reservation. That router MUST generate a ResvErr message, containing an ERROR_SPEC object Polk & Dhesikan Expires January 13, 2010 [Page 25] Internet-Draft IntServ MULTI_Bandwidth July 2009 with a Policy Control Failure with Error code = 2 (Policy Control Failure), and an Error Value sub-code 102 (ERR_PARTIAL_PREEMPT) to the previous routers, clearing the now over allocation of bandwidth for this reservation. The difference between the previously accepted TSPEC bandwidth and the currently accepted TSPEC bandwidth is the amount this error identifies as the amount of bandwidth that is no longer required to be reserved. The ResvErr and the RESV messages are independent, and not normally sent by the same router. This aspect of this document is the extension to RFC 2205 (RSVPv1). If a RESV cannot grant the final TSPEC, normal RSVP rules apply with regard to the transmission of a particular ResvErr. A.3 FLOWSPEC for Guaranteed service Here is the FLOWSPEC object from [RFC2215] when requesting Guaranteed service: 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | Unused | 10 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 2 (c) |0| reserved | 9 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 130 (h) | 0 (i) | 2 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Rate [R] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Slack Term [S] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A3. Multiple TSPECs for Guaranteed service (a) - Message format version number (0) (b) - Overall length (9 words not including header) (c) - Service header, service number 2 (Guaranteed) (d) - Length of per-service data, 9 words not including per-service header Polk & Dhesikan Expires January 13, 2010 [Page 26] Internet-Draft IntServ MULTI_Bandwidth July 2009 (e) - Parameter ID, parameter 127 (Token Bucket TSpec) (f) - Parameter 127 flags (none set) (g) - Parameter 127 length, 5 words not including parameter header (h) - Parameter ID, parameter 130 (Guaranteed Service RSpec) (i) - Parameter 130 flags (none set) (j) - Parameter 130 length, 2 words not including parameter header The difference in structure between the Controlled-Load FLOWSPEC and Guaranteed FLOWSPEC is the RSPEC, defined in [RFC2212]. Polk & Dhesikan Expires January 13, 2010 [Page 27]