TSVWG WG James Polk
Internet-Draft Subha Dhesikan
Expires: September 4, 2009 Cisco Systems
Intended Status: Standards Track (PS) March 4, 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-00
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 September 4, 2009.
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 September 4, 2009 [Page 1]
Internet-Draft RSVP Multi-TSPEC March 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 in the same Resource Reservation Protocol (RSVPv1)
reservation. 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 Multi_TSPEC Solution . . . . . . . . . . . . 6
3. Multiple Sender and Receiver in Single TSPEC Modification . . 8
3.1 New Multiple_Token_Bucket_Tspec Parameter in TSPEC . . . 8
3.2 SENDER_TSPEC and FLOWSPEC for Controlled-Load service . . 9
3.3 FLOWSPEC for Guaranteed service . . . . . . . . . . . . . 12
4. Multiple Sender and Receiver in Dual TSPEC Modification . . . 13
4.1 New Multiple_Token_Bucket_Tspec Parameter in TSPEC . . . 15
4.2 SENDER_TSPEC and FLOWSPEC for Controlled-Load service . . 16
4.3 FLOWSPEC for Guaranteed service . . . . . . . . . . . . . 20
5. Rules of Usage . . . . . . . . . . . . . . . . . . . . . . . 21
6. Security considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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.
Polk & Dhesikan Expires September 4, 2009 [Page 2]
Internet-Draft RSVP Multi-TSPEC March 2009
1. Introduction
This document defines how Integrated Services (IntServ) [RFC2210]
includes multiple TSPECs in the same Resource Reservation Protocol
(RSVPv1) [RFC2205] message. 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. 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 TSPEC in the RESV
message is called the RECEIVER_TSPEC.
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 just by dropping
and adding layers, but also by reducing frame rates and resolution.
Thus the current mechanism of the Integrated Services, and therefore
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
Receiver_TSPEC in a RESV message, applications will either have to
Polk & Dhesikan Expires September 4, 2009 [Page 3]
Internet-Draft RSVP Multi-TSPEC March 2009
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
Receivers TSPEC, it does not prevent failures or multiple
roundtrips 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
recommended that the RESV generator use this object in determining
the RECEIVER_TSPEC.
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
reservation message permits multiple bandwidths to be chosen from by
the Called node, 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 September 4, 2009 [Page 4]
Internet-Draft RSVP Multi-TSPEC March 2009
Calling node Rtr-1 Rtr-2 Rtr-N Called node
| | | | |
| PATH (with a TSPEC & ADSPEC) |
|------------->|--------->|--------->|-------------->|
| | | | |
| RESV (with a TSPEC) |
|<-------------|<---------|<---------|<--------------|
| | | | |
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
RECEIVER_TSPEC, 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 TSPEC wanting 12Mbps) |
| | X <--------|<--------------|
| | | | |
| ResvErr (with Admission control Error=2) |
| | |--------->|-------------->|
| | | | |
Figure 2. Concept of RSVP Rejection due to Limited Bandwidth
The scenario above is where this 'multiple TSPEC' 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 video
for the three video codecs the Calling node supports.
This document will discuss a general overview of this multi-TSPEC
solution in section 2. The more detailed solutions are discussed in
sections 3 and 4 are alternate solutions based on 2 of the 3 options
discussed in section 2. WG discussions will result in one of the
two sections being removed. This is why there is some duplicate
Polk & Dhesikan Expires September 4, 2009 [Page 5]
Internet-Draft RSVP Multi-TSPEC March 2009
(i.e., copied) text in the two sections. Section 5 will cover
additional rules of usage of this IntServ extension, in addition to
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., TSPEC), meaning previous routers that accepted that
bandwidth, now have too much bandwidth reserved. This requires an
extension to RFC 4495 (RSVP Bandwidth Reduction) to cover
reservation establishment, as well as existing reservations.
Obviously, in a reservation with only one codec - where one
bandwidth is requested of the network, this mechanism is not
necessary.
2. Overview of the Multi_TSPEC Solution
Presently, this is the format of a PATH message [RFC2205]:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
^^^^^^^^^^^^
[ <ADSPEC> ]
The ADSPEC is optional in IntServ, therefore it may or may not be in
the RSVP PATH message. Presently, the SENDER_TSPEC can have one
bandwidth requested for this reservation. This is changed in this
extension to IntServ.
Given that the SENDER_TSPEC contains the bandwidth amount for this
reservation request, we have a choice when wanting to include more
than one bandwidth in the request:
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
for this same reservation.
or
Polk & Dhesikan Expires September 4, 2009 [Page 6]
Internet-Draft RSVP Multi-TSPEC March 2009
Option #3 - create the ability for the existing SENDER_TSPEC to
remain unchanged, but add an optional <MULTI_TSPEC>
object to the <sender descriptor> such as this:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <MULTI_TSPEC> ]
^^^^^^^^^^^
Option #3 is an optimization to Option #1 in that Option #3 is an
effectively a concatenation of Option #1 (i.e., instead of having
separate additional objects, make them one longer object).
Option #3 also have the advantage of being backwards compatible with
existing implementations of [RFC2205] and [RFC2210], as optional
objects do not need to be process, especially if they are not
understood.
Option #3 also applies to the RECEIVER_TSPEC(s) in the FLOWSPEC
contained in the RESV message.
NOTE: it is important to emphasize here that including more than one
TSPEC in the RESV message does not cause more than one TSPEC
to be granted. This Draft requires that the RESV generator
arrange these multiple TSPECs in the order of preference. The
benefit of this arrangement is that RSVP does not have to
process the rest of the TSPECs if it can admit the first one.
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.
Since there are multiple TSPECs 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 exists (from source to destination), when a
subsequent router cannot support a more preferred TSPECs contained
in that RESV. This document will extend the RFC 4495 defined error
to work for previous hops while a reservation is being established.
Polk & Dhesikan Expires September 4, 2009 [Page 7]
Internet-Draft RSVP Multi-TSPEC March 2009
3. Multiple Sender and Receiver in Single TSPEC Modification
Section 3 here discusses our solution from an Option #2 perspective
(i.e., this section 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 4 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 section specifies the
detailed contents and wire format of a TSPEC that has been modified
to allow multiple bandwidths, hence the term "Multiple TSPECs".
3.1 New Multiple_Token_Bucket_Tspec Parameter in TSPEC
This extension to Integrated Services allows <Service Number=1> to
use a new <parameter name>. This document creates the new
<parameter names> 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 September 4, 2009 [Page 8]
Internet-Draft RSVP Multi-TSPEC March 2009
3.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 3. 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 September 4, 2009 [Page 9]
Internet-Draft RSVP Multi-TSPEC March 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 4. 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)
(f) - Parameter 125 flags (none set)
Polk & Dhesikan Expires September 4, 2009 [Page 10]
Internet-Draft RSVP Multi-TSPEC March 2009
(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 4, 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
with a Policy Control Failure with Error code = 2 (Policy Control
Polk & Dhesikan Expires September 4, 2009 [Page 11]
Internet-Draft RSVP Multi-TSPEC March 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.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 5. 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
(e) - Parameter ID, parameter 127 (Token Bucket TSpec)
Polk & Dhesikan Expires September 4, 2009 [Page 12]
Internet-Draft RSVP Multi-TSPEC March 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 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].
[Editor's Note: the authors are currently unsure if there needs
to be a separate RSPEC for each TSPEC in the
Guarantee service. Feedback is necessary before
completing the Multi_TSPEC version of the above
format.
When the above is resolved, most of the same rules
below Figure 4 will be copied here, with the
special handling of the RSPEC added.]
4. Multiple Sender and Receiver in Dual TSPEC Modification
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 that such enhancements, such as this one,
be made in a way that is backward compatible.
For this extension to work, the minimal requirement is that both the
Path and the Resv generator are enhanced with this extension as they
will have to include the multiple TSPECs in the RSVP messages to
invoke this feature. Other than that, the authors do not wish to
impose any additional requirement on the RSVP-enabled routers along
the path while warning that this features benefit can only be
realized if the routers along the path are enhanced with this
extension.
In order to provide for backward compatibility, the Sender's TSPEC
and the RECEIVER_TSPEC are left untouched. This allows routers not
having the extension to be able to process the Path and the Resv
message. The additional TSPECs (MULTI_TSPEC] are included in the
Path and in the Resv message as new, additional (optional) objects.
Since these additional objects will have a class number of 11bbbbbb,
it will allow older routers to ignore the object and forward it
unexamined and unchanged, as defined in section 3.10 of [RFC 2205].
Section 4 here 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).
Section 3 discusses our solution from an Option #2 perspective
(i.e., this section 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)).
Polk & Dhesikan Expires September 4, 2009 [Page 13]
Internet-Draft RSVP Multi-TSPEC March 2009
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 section specifies the
detailed contents and wire format of a TSPEC that has been modified
to allow multiple bandwidths, hence the term "Multiple TSPECs".
For the Sender_descriptor with in the PATH message, the original
TSPEC remains where it is, and is untouched by this IntServ
extension. What is new is the <MULTI_TSPEC> object, shown here:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <MULTI_TSPEC> ]
^^^^^^^^^^^
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
- etc...
The flowspec composition depends upon the reservation style
requested in the Resv message. Therefore, the following shows the
inclusion of the MULTI_TSPEC object with each of the styles:
WF Style:
<flow descriptor list> ::= <WF flow descriptor>
<WF flow descriptor> ::= <FLOWSPEC> [MULTI-TSPEC]
FF style:
<flow descriptor list> ::=
<FLOWSPEC> <FILTER_SPEC> [MULTI-TSPEC] |
<flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::=
[ <FLOWSPEC> ] <FILTER_SPEC> [MULTI_TSPEC]
Polk & Dhesikan Expires September 4, 2009 [Page 14]
Internet-Draft RSVP Multi-TSPEC March 2009
SE style:
<flow descriptor list> ::= <SE flow descriptor>
<SE flow descriptor> ::=
<FLOWSPEC> <filter spec list> [MULTI-TSPEC]
<filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC>
This preferred order of TSPECs MUST be maintained within the
SENDER_TSPEC, within the RESV Generator, and within the
RECEIVER_TSPEC, with one exception:
- if one or more preferred TSPECs cannot be granted by a router, or
discovered during processing of the ADSPEC by the RESV Generator,
each TSPEC that cannot be granted MUST be removed from this
reservation establishment. The preferred order of the remaining
TSPECs MUST be kept intact.
If the recipient does not understand this extension, it ignores this
MULTI_TSPEC object, and operates normally for a node receiving this
RSVP message.
[Editor's note: Subsections 4.1, 4.2 and 4.3 are written as if
Option #3 were chosen by this document - therefore
there is some repetitive text that will be removed
from either section 3 (which focuses on Option #2)
or section 4 (which focuses on Option #3). This will
be done once the WG, if they take this on as a WG
item, decides which Option is best moving forward.]
4.1 New Multiple_Token_Bucket_Tspec Parameter in TSPEC
This extension to Integrated Services allows <Service Number=1> to
use a new <parameter name>. This document creates the new
<parameter names> 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]. The original SENDER_TSPEC and
RECEIVER_TSPEC maintain the <parameter name> of Token_Bucket_Tspec
with a parameter number of 127. The new <MULTI_TSPEC> object,
included in the Sender_Descriptor and FLOWSPEC has the parameter
number of 125.
When there is more than one TSPEC object, 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
Polk & Dhesikan Expires September 4, 2009 [Page 15]
Internet-Draft RSVP Multi-TSPEC March 2009
reservation request with 3 TSPECs. This optimization, for example
in a 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).
4.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 6. 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)
Polk & Dhesikan Expires September 4, 2009 [Page 16]
Internet-Draft RSVP Multi-TSPEC March 2009
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including per-service
header
For Option #3, Figure 3 is included in its original form for
backwards compatibility reasons, as if there were only 1 TSPEC in
the PATH or RESV. What is new when there are more than one TSPEC in
this reservation message is the new MULTI_TSPEC object in Figure 7
containing, for example, 3 (Multiple_Token_Bucket_Tspec) TSPECs when
requesting Controlled-Load service. 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.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Polk & Dhesikan Expires September 4, 2009 [Page 17]
Internet-Draft RSVP Multi-TSPEC March 2009
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 7. 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)
(f) - Parameter 125 flags (none set)
(g) - Parameter 125 length, 5 words not including per-service
header
This is for the 2nd through Nth preferred TSPEC in the PATH or RESV.
The message format (a) remains the same for a second TSPEC and
for more 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 4, 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.
Polk & Dhesikan Expires September 4, 2009 [Page 18]
Internet-Draft RSVP Multi-TSPEC March 2009
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
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.
Polk & Dhesikan Expires September 4, 2009 [Page 19]
Internet-Draft RSVP Multi-TSPEC March 2009
4.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 5. 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
(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].
[Editor's Note: the authors are currently unsure if there needs
to be a separate RSPEC for each TSPEC in the
Guarantee service. Feedback is necessary before
completing the Multi_TSPEC version of the above
format.
Polk & Dhesikan Expires September 4, 2009 [Page 20]
Internet-Draft RSVP Multi-TSPEC March 2009
When the above is resolved, most of the same rules
below Figure 4 will be copied here, with the
special handling of the RSPEC added.]
5. Rules of Usage
[Editor's Note: Most of the rules of usage right now are in the
Controlled Load section of this document (section
3.2). Once the issue wrt the RSPEC in the
Guaranteed Service FLOWSPEC is solved, most (if not
all) the globally applicable rules of usage will
move into this section 4.]
- 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
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 MAY 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.
- ...there is more coming here...
6. 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.
7. IANA considerations
This document IANA registers the following new parameter name in the
Integ-serv assignments at [IANA]:
Polk & Dhesikan Expires September 4, 2009 [Page 21]
Internet-Draft RSVP Multi-TSPEC March 2009
Registry Name: Parameter Names
Registry:
Value Description Reference
-------- -------------------------------------------- ---------
125 Multiple_Token_Bucket_Tspec [RFCXXXX]
Where RFCXXXX is replaced with the RFC number assigned to this
Document.
8. Acknowledgments
Your name here...
9. References
9.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
9.2. Informative References
[IANA] http://www.iana.org/assignments/integ-serv
Polk & Dhesikan Expires September 4, 2009 [Page 22]
Internet-Draft RSVP Multi-TSPEC March 2009
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
San Jose, CA 95134 USA
mailto: sdhesika@cisco.com
Polk & Dhesikan Expires September 4, 2009 [Page 23]