As per Relevance of the word guaranteed, we have this rfc below:
Network Working Group J.
Request for Comments: 2210 MIT
Category: Standards Track September 1997
The Use of RSVP with IETF Integrated
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This note describes the use of the RSVP resource reservation
with the Controlled-Load and Guaranteed QoS control services.
RSVP protocol defines several data objects which carry
reservation information but are opaque to RSVP itself. The usage
data format of those objects is given here
1.
The Internet integrated services framework provides the ability
applications to choose among multiple, controlled levels of
service for their data packets. To support this capability,
things are required
- Individual network elements (subnets and IP routers) along
path followed by an application's data packets must
mechanisms to control the quality of service delivered to
packets
- A way to communicate the application's requirements to
elements along the path and to convey QoS management
between network elements and the application must be provided
In the integrated services framework the first function is
by QoS control services such as Controlled-Load [RFC 2211]
Guaranteed [RFC 2212]. The second function may be provided in
number of ways, but is frequently implemented by a
reservation setup protocol such as RSVP [RFC 2205].
Wroclawski Standards Track [Page 1]
RFC 2210 RSVP with INTSERV September 1997
Because RSVP is designed to be used with a variety of QoS
services, and because the QoS control services are designed to
used with a variety of setup mechanisms, a logical separation
between the two specifications. The RSVP specification does
define the internal format of those RSVP protocol fields, or objects
which are related to invoking QoS control services. Rather,
treats these objects as opaque. The objects can carry
information to meet different application and QoS control
requirements
Similarly, interfaces to the QoS control services are defined in
general format, so that the services can be used with a variety
setup mechanisms
This RFC provides the information required to use RSVP and
integrated service framework's QoS control services together.
defines the usage and contents of three RSVP protocol objects,
FLOWSPEC, ADSPEC, and SENDER_TSPEC, in an environment supporting
Controlled-Load and/or Guaranteed QoS control services. If
services or capabilities are added to the integrated
framework, this note will be revised as required
2. Use of
Several types of data must be transported between applications
network elements to correctly invoke QoS control services
NOTE: In addition to the data used to directly invoke QoS
services, RSVP carries authentication, accounting, and
information needed to manage the use of these services. This
is concerned only with the RSVP objects needed to actually
QoS control services, and does not discuss accounting or
objects
This data includes
- Information generated by each receiver describing the
control service desired, a description of the traffic flow
which the resource reservation should apply (the Receiver TSpec),
and whatever parameters are required to invoke the service (
Receiver RSpec). This information is carried from the receivers
intermediate network elements and the sender(s) by RSVP
objects. The information being carried in a FLOWSPEC object
change at intermediate points in the network due to
merging and other factors
Wroclawski Standards Track [Page 2]
RFC 2210 RSVP with INTSERV September 1997
- Information generated at each sender describing the data
generated by that sender (the Sender TSpec). This information
carried from the sender to intermediate network elements and
receiver(s) by RSVP, but is never modified by
elements within the network. This information is carried in
SENDER_TSPEC objects
- Information generated or modified within the network and used
the receivers to make reservation decisions. This
might include available services, delay and bandwidth estimates
and operating parameters used by specific QoS control services
this information is collected from network elements and
towards receivers in RSVP ADSPEC objects. Rather than
information from each intermediate node separately to
receivers, the information in the ADSPEC represents a summary
computed as the ADSPEC passes each hop. The size of this
remains (roughly) constant as the ADSPEC flows through
network, giving good scaling properties
From the point of view of RSVP objects, the breakdown is as follows
- The RSVP SENDER_TSPEC object carries the traffic
(sender TSpec) generated by each data source within an
session. It is transported unchanged through the network,
delivered to both intermediate nodes and receiving applications
- The RSVP ADSPEC object carries information which is generated
either data sources or intermediate network elements, is
downstream towards receivers, and may be used and updated
the network before being delivered to receiving applications
This information includes both parameters describing
properties of the data path, including the availability
specific QoS control services, and parameters required by
QoS control services to operate correctly
- The RSVP FLOWSPEC object carries reservation
(Receiver_TSpec and RSpec) information generated by
receivers. The information in the FLOWSPEC flows upstream
data sources. It may be used or updated at intermediate
elements before arriving at the sending application
NOTE: The existence of both SENDER_TSPEC and ADSPEC RSVP
is somewhat historical. Using the message format described
this note it would be possible to place all of the
control information carried "downstream" by RSVP in the
object. However, the distinction between data which is
updated within the network (in the SENDER_TSPEC object) and
which is updated within the network (in the ADSPEC object)
Wroclawski Standards Track [Page 3]
RFC 2210 RSVP with INTSERV September 1997
be useful to an implementation in practice, and is
retained
2.1 Summary of
Operation proceeds as follows
An application instance participating in an RSVP session as a
sender registers with RSVP. One piece of information provided by
application instance is the Sender TSpec describing the traffic
application expects to generate. This information is used
construct an RSVP SENDER_TSPEC object, which is included in RSVP
messages generated for the application
The sending application also constructs an initial RSVP
object. This adspec carries information about the QoS
capabilities and requirements of the sending application itself,
forms the starting point for the accumulation of path
described below. The ADSPEC is added to the RSVP PATH message
at the sender
NOTE: For the convenience of application programmers, a host
implementation may allow the sending application not to provide
initial adspec, instead supplying its own default. This usage
most likely when the application sender does not
participate in the end-to-end QoS control process (by
scheduling CPU usage and similar means) and does not itself
which QoS control service is selected by the receivers
Typically the default ADSPEC supplied by the host RSVP in
case would support all QoS control services known to the host
However, the exact behavior of this mechanism is
dependent
The ADSPEC is modified by subsequent network elements as the
PATH message moves from sender to receiver(s). At each
element, the ADSPEC is passed from RSVP to the traffic
module. The traffic control module updates the ADSPEC, which
contain data for several QoS control services, by identifying
services mentioned in the ADSPEC and calling each such service
update its portion of the ADSPEC. If the traffic control
discovers a QoS control service mentioned in the ADSPEC but
implemented by the network element, a flag is set to report this
the receiver. The updated ADSPEC is then returned to RSVP
delivery to the next hop along the path
Wroclawski Standards Track [Page 4]
RFC 2210 RSVP with INTSERV September 1997
Upon arrival of the PATH message at an application receiver, the
in the SENDER_TSPEC and ADSPEC objects is passed across the RSVP
to the application. The application (perhaps with the help of
library of common resource-reservation functions) interprets
arriving data, and uses it to guide the selection of
reservation parameters. Examples of this include use of the
"PATH_MTU" composed characterization parameter [RFC 2215]
determine the maximum packet size parameter in the
request and use of the arriving Guaranteed service "C" and "D
parameters [RFC 2212] to calculate a mathematical bound on
packet delay when using the Guaranteed service
An application receiver wishing to make a resource
supplies its local RSVP with the necessary reservation parameters
Among these are the QoS control service desired (Guaranteed
Controlled-Load), the traffic specifier (TSpec) describing the
of traffic for which resources should be reserved, and, if needed
the selected QoS control service, an RSpec describing the level
service desired. These parameters are composed into an RSVP
object and transmitted upstream by RSVP
At each RSVP-aware point in the network, the SENDER_TSPECs
in PATH messages and the FLOWSPECs arriving in RESV messages are
to request an appropriate resource reservation from the desired
control service. State merging, message forwarding, and
handling proceed according to the rules of the RSVP protocol
Finally, the merged FLOWSPEC object arriving at each of an
session's data senders is delivered to the application to inform
sender of the merged reservation request and properties of the
path
2.2. RSVP support for multiple QoS control
The design described in this note supports RSVP sessions in which
receivers choose a QoS control service at runtime
To make this possible, a receiver must have all the
needed to choose a particular service before it makes the choice
This means that the RSVP SENDER_TSPEC and ADSPEC objects must
the receivers with information for all services which might
chosen
The Sender TSpec used by the two currently defined QoS
services is identical. This simplifies the RSVP SENDER_TSPEC object
which need carry only a single TSpec data structure in this
format. This common SENDER_TSPEC can be used with either
or Controlled-Load service
Wroclawski Standards Track [Page 5]
RFC 2210 RSVP with INTSERV September 1997
The RSVP ADSPEC carries information needed by receivers to choose
service and determine the reservation parameters. This includes
- Whether or not there is a non-RSVP hop along the path. If
is a non-RSVP hop, the application's traffic will
reservationless best-effort service at at least one point on
path
- Whether or not a specific QoS control service is implemented
every hop along the path. For example, a receiver might learn
at least one integrated-services aware hop along the path
the Controlled-Load service but not the Guaranteed service
- Default or global values for the general
parameters described in [RFC 2215]. These values
properties of the path itself, irrespective of the selected
control service. A value reported in this section of the
applies to all services unless a different, service-specific
is also present in the ADSPEC
- A service-specific value for one or more
characterization parameters, if the service-specific value
from the default value
- Values of the per-service characterization parameters defined
each supported service
Data in the ADSPEC is divided into blocks or fragments, each of
is associated with a specific service. This allows the adspec
carry information about multiple services, allows new services to
deployed in the future without immediately updating existing code
and allows an application which will never use a particular
to omit the ADSPEC data for that service. The structure of
ADSPEC is described in detail in Section 3.3.
A sender may indicate that a specific QoS control service
*not* be used by the receivers within an RSVP session. This is
by omitting all mention of that service from the ADSPEC, as
in Section 3.3. Upon arrival at a receiver, the complete absence
an ADSPEC fragment for a specific service indicates to receivers
the service should not be used
NOTE: In RSVP Version 1, all receivers within a session
required to choose the same QoS control service. This
is imposed by the difficulty of merging reservations
different QoS control services, and the current lack of a
service replacement mechanism. The restriction may be
in the future
Wroclawski Standards Track [Page 6]
RFC 2210 RSVP with INTSERV September 1997
Considering this restriction, it may be useful to coordinate
receivers' selection of a QoS control service by having
sender(s) offer only one choice, using the ADSPEC
mentioned above. All receivers must then select the same service
Alternatively, the coordination might be accomplished by using
higher-level session announcement and setup mechanism to
the receivers of the QoS control service in use, by
configuration of the receivers, or by an agreement
running among the session receivers themselves
As with the ADSPEC, the FLOWSPEC and SENDER_TSPEC object
described in Section 3 are capable of carrying TSpecs and
for more than one QoS control service in separate data fragments
Currently, use of a FLOWSPEC or SENDER_TSPEC containing
for more than one QoS control service is not supported. In
future, this capability may be used to implement a more
service request and replacement scheme, allowing applications
obtain useful end-to-end QoS control when not all
nodes support the same set of QoS services. RSVP-application
should be designed to support passing SENDER_TSPEC, FLOWSPEC,
ADSPEC objects of variable size and containing information
multiple QoS control services between RSVP and its clients
2.3. Use of ADSPEC
This section gives some details about setting reservation
and the use of information conveyed by the RSVP ADSPEC object
2.3.1. Determining the availability of a QoS control
The RSVP ADSPEC carries flag bits telling the application
whether or not a completely reservation-capable path exists
each sender and the receiver. These bits are called "break bits",
because they indicate breaks in the QoS control along a network path
Break bits are carried within the header which begins each per
service data fragment of an RSVP ADSPEC
Service number 1 is used within the ADSPEC to identify a
carrying information about global parameter values that apply to
services (see [RFC 2215] for more details). The break bit in
1's per-service header is used to tell the receiver(s) whether all
the network elements along the path from sender to receiver
RSVP and integrated services. If a receiver finds this bit set,
least one network element along the data transmission path
the ADSPEC's sender and the receiver can not provide QoS
services at all. This bit corresponds to the global NON_IS_
characterization parameter defined in [RFC 2215].
Wroclawski Standards Track [Page 7]
RFC 2210 RSVP with INTSERV September 1997
NOTE: If this bit is set, the values of all other parameters
the ADSPEC are unreliable. The bit being set indicates that
least one node along the sender-receiver path did not
process the ADSPEC
Service-specific break bits tell the receiver(s) whether all of
network elements along the path from sender to receiver support
particular QoS control service. The break bit for each service
carried within the ADSPEC's per-service header for that service.
a bit is set at the receiver, at least one network element along
data transmission path supports RSVP but does not support the
control service corresponding to the per-service header. These
correspond to the service-specific NON_IS_HOP
parameters defined in [RFC 2215].
Section 3 gives more information about break bits
2.3.2. Determining Path
Both Guaranteed and Controlled-Load QoS control services place
upper bound on packet size, and require that the application
the maximum size of packets subject to resource reservation. For
services, the desired maximum packet size is a parameter of
reservation request, and the service will reject (with an
control error) reservation requests specifying a packet size
than that supported by the service
Since RSVP reservation requests are made by receivers, this
that the *receivers* in an RSVP session, as well as the senders,
to know the MTU supported by the QoS control services along a
path. Further, in some unusual cases the MTU supported by a
control service may differ from that supported by the same
when providing best effort service
A scalable form of MTU negotiation is used to address these problems
MTU negotiation in an RSVP system works as follows
- Each sending application joining an RSVP session fills in the
(maximum packet size) parameter in its generated Sender_
(carried from senders to receivers in a SENDER_TSPEC object)
the maximum packet size it wishes to send covered by
reservation
- Each RSVP PATH message from a sending application also
an ADSPEC object containing at least one PATH_MTU
parameter. When it arrives at the receiver, this parameter
the minimum MTU at any point along the path from sender
receiver. Generally, only the "global" PATH_MTU
Wroclawski Standards Track [Page 8]
RFC 2210 RSVP with INTSERV September 1997
(service 1, parameter 9) will be present, in which case its
is a legal MTU for all reservation requests. If a service
PATH_MTU parameter is present, its value will be smaller than
of the global parameter, and should be used for
requests for that service
- Each receiver takes the minimum of all the PATH_MTU values (
the desired QoS control service) arriving in ADSPEC messages
different senders and uses that value as the MTU in
reservation requests. This value is used to fill in the
parameter of the TSpec created at the receiver. In the case of
FF style reservation, a receiver may also choose to use the
derived from each sender's ADSPEC in the FLOWSPEC generated
that sender, if the receiver is concerned about obtaining
maximum MTU on each data path. To accomodate changes in the
path, the receiver may continue to watch the arriving ADSPECS,
modify the reservation if a newly arriving ADSPEC indicates
smaller MTU than is currently in use
- As reservation requests (RESV messages) move from receivers
senders, reservation parameters are merged at intermediate nodes
As part of this merging, the smaller of two M parameters
at a merge point will be forwarded in the upstream RESV message
- As reservation requests arrive at intermediate RSVPs,
minimum of the receivers' requested TSpec and the sum of
sender TSpecs is taken, and a reservation for the resulting
is made. The reservation will use the smaller of the actual
MTU value computed by the receivers and the largest maximum
size declared by any of the sender(s). (The TSpec sum()
result's M parameter is the max of the summed TSpec M parameters).
- When the completely merged RESV message arrives at each sender
the MTU value (M parameter) in the merged FLOWSPEC object
have been set to the smallest acceptable MTU of the data
from that sender to any session receiver. This MTU should be
by the sending application to size its packets. Any packets
than this MTU may be delivered as best-effort rather than
covered by the session's resource reservation
Note that senders do *not* adjust the value of
Sender_TSpec's M field to match the actual packet size selected
this step. The value of M represents the largest packet the
could send, not the largest packet the sender is
sending
Wroclawski Standards Track [Page 9]
RFC 2210 RSVP with INTSERV September 1997
Note that the scheme above will allow each sender in a session to
the largest MTU appropriate for that sender, in cases where
data paths or receivers have different acceptable MTU's
3. RSVP Object
This section specifies the detailed contents and wire format of
SENDER_TSPEC, ADSPEC, and FLOWSPEC objects for use with
Guaranteed and Controlled-Load QoS control services. The
formats specified here are based on the general message
rules given in Appendix 1.
3.1. RSVP SENDER_TSPEC
The RSVP SENDER_TSPEC object carries information about a
source's generated traffic. The required RSVP SENDER_TSPEC
contains a global Token_Bucket_TSpec parameter (service_number 1,
parameter 127, as defined in [RFC 2215]). This TSpec carries
information usable by either the Guaranteed or Controlled-Load
control services
Wroclawski Standards Track [Page 10]
RFC 2210 RSVP with INTSERV September 1997
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header
(c) - Service header, service number 1 (default/global information
(d) - Length of service 1 data, 6 words not including
(e) - Parameter ID, parameter 127 (Token_Bucket_TSpec
(f) - Parameter 127 flags (none set
(g) - Parameter 127 length, 5 words not including
In this TSpec, the parameters [r] and [b] are set to reflect
sender's view of its generated traffic. The peak rate parameter [p
may be set to the sender's peak traffic generation rate (if known
controlled), the physical interface line rate (if known), or
infinity (if no better value is available). Positive infinity
represented as an IEEE single-precision floating-point number with
exponent of all ones (255) and a sign and mantissa of all zeros.
format of IEEE floating-point numbers is further summarized in [
1832].
The minimum policed unit parameter [m] should generally be set
to the size of the smallest packet generated by the application.
packet size includes the application data and all protocol headers
or above the IP level (IP, TCP, UDP, RTP, etc.). The size given
not include any link-level headers, because these headers will
as the packet crosses different portions of the internetwork
Wroclawski Standards Track [Page 11]
RFC 2210 RSVP with INTSERV September 1997
The [m] parameter is used by nodes within the network to compute
maximum bandwidth overhead needed to carry a flow's packets over
particular link-level technology, based on the ratio of [m] to
link-level header size. This allows the correct amount of
to be allocated to the flow at each point in the net. Note
smaller values of this parameter lead to increased
estimates, and thus increased likelyhood of a reservation
being rejected by the node. In some cases, an
transmitting a low percentage of very small packets may
choose to set the value of [m] larger than the actual
transmitted packet size. This will increase the likelyhood of
reservation succeeding, at the expense of policing packets of
less than [m] as if they were of size [m].
Note that the an [m] value of zero is illegal. A value of zero
indicate that no data or IP headers are present, and would give
infinite amount of link-level overhead
The maximum packet size parameter [M] should be set to the size
the largest packet the application might wish to generate,
described in Section 2.3.2. This value must, by definition, be
to or larger than the value of [m].
3.2. RSVP FLOWSPEC
The RSVP FLOWSPEC object carries information necessary to
reservation requests from the receiver(s) into the network.
includes an indication of which QoS control service is
requested, and the parameters needed for that service
The QoS control service requested is indicated by the service_
in the FLOWSPEC's per-service header
3.2.1 FLOWSPEC object when requesting Controlled-Load
The format of an RSVP FLOWSPEC object originating at a
requesting Controlled-Load service is shown below. Each of the
fields is represented using the preferred concrete
specified in the 'Invocation Information' section of [RFC 2211].
value of 5 in the per-service header (field (c), below)
that Controlled-Load service is being requested
Wroclawski Standards Track [Page 12]
RFC 2210 RSVP with INTSERV September 1997
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 5 (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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header
(c) - Service header, service number 5 (Controlled-Load
(d) - Length of controlled-load data, 6 words not
per-service
(e) - Parameter ID, parameter 127 (Token Bucket TSpec
(f) - Parameter 127 flags (none set
(g) - Parameter 127 length, 5 words not including per-
In this object, the TSpec parameters [r], [b], and [p] are set
reflect the traffic parameters of the receiver's desired
(the Reservation TSpec). The meaning of these fields is
fully in [RFC 2211]. Note that it is unlikely to make sense for
[p] term to be smaller than the [r] term
The maximum packet size parameter [M] should be set to the value
the smallest path MTU, which the receiver learns from information
arriving RSVP ADSPEC objects. Alternatively, if the
application has built-in knowledge of the maximum packet size in
within the RSVP session, and this value is smaller than the
path MTU, [M] may be set to this value. Note that requesting a
of [M] larger than the service modules along the data path
support will cause the reservation to fail. See section 2.3.2
further discussion of the MTU value
Wroclawski Standards Track [Page 13]
RFC 2210 RSVP with INTSERV September 1997
The value of [m] can be chosen in several ways. Recall that when
resource reservation is installed at each intermediate node,
value used for [m] is the smaller of the receiver's request and
values in each sender's SENDER_TSPEC
If the application has a fixed, known minimum packet size, than
value should be used for [m]. This is the most desirable case
For a shared reservation style, the receiver may choose between
options, or pick some intermediate point between them
- if the receiver chooses a large value for [m], then
reservation will allocate less overhead for link-level headers
However, if a new sender with a smaller SENDER_TSPEC [m] joins
session later, an already-installed reservation may fail at
time
- if the receiver chooses a value of [m] equal to the
value which might be used by any sender, then the reservation
be forced to allocate more overhead for link-level headers
However it will not fail later if a new sender with a
SENDER_TSPEC [m] joins the session
For a FF reservation style, if no application-specific value is
the receiver should simply use the value of [m] arriving in
sender's SENDER_TSPEC for its reservation request to that sender
3.2.2. FLOWSPEC Object when Requesting Guaranteed
The format of an RSVP FLOWSPEC object originating at a
requesting Guaranteed service is shown below. The flowspec
used to request guaranteed service carries a TSpec and
specifying the traffic parameters of the flow desired by
receiver
Each of the TSpec and RSpec fields is represented using the
concrete representation specified in the 'Invocation Information
section of [RFC 2212]. The value of 2 for the service
identifier (field (c) in the picture below) indicates that
service is being requested
Wroclawski Standards Track [Page 14]
RFC 2210 RSVP with INTSERV September 1997
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(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-
(e) - Parameter ID, parameter 127 (Token Bucket TSpec
(f) - Parameter 127 flags (none set
(g) - Parameter 127 length, 5 words not including parameter
(h) - Parameter ID, parameter 130 (Guaranteed Service RSpec
(i) - Parameter 130 flags (none set
(j) - Parameter 130 length, 2 words not including parameter
In this object, the TSpec parameters [r], [b], and [p] are set
reflect the traffic parameters of the receiver's desired
(the Reservation TSpec). The meaning of these fields is
fully in [RFC 2212]. Note that it is unlikely to make sense for
[p] term to be smaller than the [r] term
The RSpec terms [R] and [S] are selected to obtain the
bandwidth and delay guarantees. This selection is described in [
2212].
Wroclawski Standards Track [Page 15]
RFC 2210 RSVP with INTSERV September 1997
The [m] and [M] parameters are set identically to those for
Controlled-Load service FLOWSPEC, described in the previous section
3.3. RSVP ADSPEC
An RSVP ADSPEC object is constructed from data fragments
by each service which might be used by the application. The
begins with an overall message header, followed by a fragment for
default general parameters, followed by fragments for every
control service which may be selected by application receivers.
size of the ADSPEC varies depending on the number and size of per
service data fragments present and the presence of non-
general parameters (described in Section 3.3.5).
The complete absence of a data fragment for a particular
means that the application sender does not know or care about
service, and is a signal to intermediate nodes not to add or
information about that service to the ADSPEC. It is also a signal
application receivers that they should not select that service
making reservations
Each fragment present is identified by a per-service data header
Each header contains a field identifying the service, a break bit
and a length field
The length field allows the ADSPEC information for a service to
skipped over by a network elements which does not recognize
implement the service. When an element does this, it sets the
bit, indicating that the service's ADSPEC data was not updated at
least one hop. Note that a service's break bit can be set
otherwise supporting the service in any way. In all cases, a
element encountering a per-service data header it does not
simply sets bit 23 to report that the service is not supported,
skips over the rest of the fragment
Data fragments must always appear in an ADSPEC in service_
order. In particular, the default general parameters
(service_number 1) always comes first
Within a data fragment, the service-specific data must alway
first, followed by any non-default general parameters which may
present, ordered by parameter_number. The size and structure of
service-specific data is fixed by the service definition, and
not require run-time parsing. The remainder of the fragment,
carries non-default general parameters, varies in size and
depending on which, if any, of these parameters are present.
part of the fragment must be parsed by examining the per-
headers
Wroclawski Standards Track [Page 16]
RFC 2210 RSVP with INTSERV September 1997
Since the overall size of each data fragment is variable, it
always necessary to examine the length field to find the end of
fragment, rather than assuming a fixed-size structure
3.3.1. RSVP ADSPEC
The basic ADSPEC format is shown below. The message header and
default general parameters fragment are always present. The
for Guaranteed or Controlled-Load service may be omitted if
service is not to be used by the RSVP session. Additional
fragments will be added if new services are defined
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (a) | reserved | Msg length - 1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Default General Parameters fragment (Service 1) (c) |
| (Always Present) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Guaranteed Service Fragment (Service 2) (d) |
| (Present if application might use Guaranteed Service) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Controlled-Load Service Fragment (Service 5) (e) |
| (Present if application might use Controlled-Load Service) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall message length not including header
(c, d, e) - Data
3.3.2. Default General Characterization Parameters ADSPEC data
All RSVP ADSPECs carry the general characterization
defined in [RFC 2215]. Values for global or default
parameters (values which apply to the all services or the
itself) are carried in the per-service data fragment for
number 1, as shown in the picture above. This fragment is
present, and always first in the message
Wroclawski Standards Track [Page 17]
RFC 2210 RSVP with INTSERV September 1997
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 1 (c) |x| reserved | 8 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 4 (e) | (f) | 1 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | IS hop cnt (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | 6 (h) | (i) | 1 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | 8 (k) | (l) | 1 (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 10 (n) | (o) | 1 (p) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Composed MTU (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(c) - Per-Service header, service number 1 (Default
Parameters
(d) - Global Break bit ([RFC 2215], Parameter 2) (marked x)
length of General Parameters data block
(e) - Parameter ID, parameter 4 (Number-of-IS-hops param
[RFC 2215])
(f) - Parameter 4 flag
(g) - Parameter 4 length, 1 word not including
(h) - Parameter ID, parameter 6 (Path-BW param from [RFC 2215])
(i) - Parameter 6 flag
(j) - Parameter 6 length, 1 word not including
(k) - Parameter ID, parameter 8 (minimum path latency from [
2215])
(l) - Parameter 8 flag
(m) - Parameter 8 length, 1 word not including
(n) - Parameter ID, parameter 10 (composed path MTU from [RFC 2215])
(o) - Parameter 10 flag
(p) - Parameter 10 length, 1 word not including
Rules for composing general parameters appear in [RFC 2215].
In the above fragment, the global break bit (bit 23 of word 1,
with (x) in the picture) is used to indicate the existence of
network element not supporting QoS control services somewhere in
data path. This bit is cleared when the ADSPEC is created, and
to one if a network element which does not support RSVP or
Wroclawski Standards Track [Page 18]
RFC 2210 RSVP with INTSERV September 1997
services is encountered. An ADSPEC arriving at a receiver with
bit set indicates that all other parameters in the ADSPEC may
invalid, since not all network elements along the path
updating of the ADSPEC
The general parameters are updated at every network node
supports RSVP
- When a PATH message ADSPEC encounters a network
implementing integrated services, the portion of the
associated with service number 1 is passed to the
implementing general parameters. This module updates the
general parameters
- When a PATH message ADSPEC encounters a network element
does *not* support RSVP or implement integrated services,
break bit in the general parameters service header must be set.
practice, this bit will usually be set by another network
which supports RSVP, but has been made aware of the gap
integrated services coverage
- In either case, the ADSPEC is passed back to RSVP for
to the next hop along the path
3.3.3. Guaranteed Service ADSPEC data
The Guaranteed service uses the RSVP ADSPEC to carry data needed
compute the C and D terms passed from the network to the application
The minimum size of a non-empty guaranteed service data fragment is 8
32-bit words. The ADSPEC fragment for Guaranteed service has
following format
Wroclawski Standards Track [Page 19]
RFC 2210 RSVP with INTSERV September 1997
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 2 (a) |x| reserved | N-1 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 133 (c) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | End-to-end composed value for C [Ctot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | 134 (f) | (g) | 1 (h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | End-to-end composed value for D [Dtot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | 135 (i) | (j) | 1 (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Since-last-reshaping point composed C [Csum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 136 (l) | (m) | 1 (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Service-specific general parameter headers/values, if present |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 2 (Guaranteed
(b) - Break bit and Length of per-service data in 32-
words not including header word
(c) - Parameter ID, parameter 133 (Composed Ctot
(d) - Parameter 133 flag
(e) - Parameter 133 length, 1 word not including
(f) - Parameter ID, parameter 134 (Composed Dtot
(g) - Parameter 134 flag
(h) - Parameter 134 length, 1 word not including
(i) - Parameter ID, parameter 135 (Composed Csum).
(j) - Parameter 135 flag
(k) - Parameter 135 length, 1 word not including
(l) - Parameter ID, parameter 136 (Composed Dsum).
(m) - Parameter 136 flag
(n) - Parameter 136 length, 1 word not including
When a node which actually implements guaranteed service creates
guaranteed service adspec fragment, the parameter values are set
the local values for each parameter. When an application or
Wroclawski Standards Track [Page 20]
RFC 2210 RSVP with INTSERV September 1997
element which does not itself implement guaranteed service creates
guaranteed service adspec fragment, it should set the values of
parameter to zero, and set the break bit to indicate that the
is not actually implemented at the node
An application or host RSVP which is creating a guaranteed
adspec fragment but does not itself implement the guaranteed
may create a truncated "empty" guaranteed adspec fragment
of only a header word
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 2 (a) |1| (b) | 0 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 2 (Guaranteed
(b) - Break bit (set, service not implemented
(c) - Length of per-service data in 32-bit words
including header word
This might occur if the sending application or host does not
resource reservation iself, but still wants the network to do so
Note that in this case the break bit will always be set, since
creator of the adspec fragment does not itself implement
service
When a PATH message ADSPEC containing a per-service header
Guaranteed service encounters a network element
Guaranteed service, the guaranteed service data fragment is updated
- If the data block in the ADSPEC is an empty (header-only)
the header-only fragment must first be expanded into the
data fragment described above, with initial values of Ctot, Dtot
Csum, and Dsum set to zero. An empty fragment can be
quickly by checking for a size field of zero. The value of
break bit in the header is preserved when the
Guaranteed service data is added. The overall message length
the guaranteed-service data fragment size (field (b) in
pictures above) are changed to reflect the increased
length
The values of Ctot, Csum, Dtot, and Dsum in the ADSPEC
fragment are then composed with the local values exported by
network element according to the composition functions defined
[RFC 2212].
Wroclawski Standards Track [Page 21]
RFC 2210 RSVP with INTSERV September 1997
- When a PATH message ADSPEC with a Guaranteed service
encounters a network element that supports RSVP but does *not
implement Guaranteed service, the network element sets the
bit in the Guaranteed service header
- The new values are placed in the correct fields of the ADSPEC
and the ADSPEC is passed back to RSVP for delivery to the next
along the path
When a PATH message ADSPEC containing a Guaranteed service
fragment encounters a network element that supports RSVP but
*not* implement Guaranteed service, the network element sets
break bit in the Guaranteed service header
When a PATH message ADSPEC *without* a Guaranteed service
encounters a network element implementing Guaranteed service,
Guaranteed service module of the network element leaves the
unchanged. The absence of a Guaranteed service per-service header
the ADSPEC indicates that the application does not care
Guaranteed service
3.3.4. Controlled-Load Service ADSPEC data
Unlike the Guaranteed service, the Controlled-Load service does
require extra ADSPEC data to function correctly. The only ADSPEC
specific to the Controlled-Load service is the Controlled-Load
bit. Therefore the usual Controlled-Load service data block
no extra information. The minimum size of the controlled-load
data fragment is 1 32-bit word
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 5 (a) |x| (b) | N-1 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Service-specific general parameter headers/values, if present |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 5 (Controlled-Load
(b) - Break
(c) - Length of per-service data in 32 bit words not
header word
Wroclawski Standards Track [Page 22]
RFC 2210 RSVP with INTSERV September 1997
The Controlled-Load portion of the ADSPEC is processed according
the following rules
- When a PATH message ADSPEC with a Controlled-Load service
encounters a network element implementing Controlled-Load service
the network element makes no changes to the service header
- When a PATH message ADSPEC with a Controlled-Load service
encounters a network element that supports RSVP but does *not
implement Controlled-Load service, the network element sets
break bit in the Controlled-Load service header
- In either case, the ADSPEC is passed back to RSVP for
to the next hop along the path
3.3.5. Overriding Global ADSPEC Data with Service-Specific
In some cases, the default values for the general parameters are
correct for a particular service. For example, an implementation
Guaranteed service may accept only packets with a smaller
size than the link MTU, or the percentage of outgoing link
made available to the Controlled-Load service at a network
may be administratively limited to less than the overall bandwidth
In these cases, a service-specific value, as well as the
value, is reported to the receiver receiving the ADSPEC. Service
specific information which overrides general information is
by a parameter with the same name as the general parameter,
within the data fragment of the QoS control service to which
applies. These service-specific values are referred to as override
service-specific general parameters
For example, the following Controlled-Load ADSPEC fragment
information overriding the global path bandwidth estimate with
different value
Wroclawski Standards Track [Page 23]
RFC 2210 RSVP with INTSERV September 1997
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 5 (a) |x| (b) | 2 (c) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 6 (d) | 0 (d) | 1 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Path b/w estimate for C-L service (32b IEEE FP number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Per-Service header, service number 5 (Controlled-Load
(b) - Break
(c) - Length of per-service data, two words not including
(c) - Parameter ID, parameter 6
(AVAILABLE_PATH_BANDWIDTH general parameter from [RFC 2215])
(d) - Parameter 6 flags (none set
(e) - Parameter 6 length, one word not including
The presence of override parameters in a data fragment can be
detected by examining the fragment's length field, which will
larger than the "standard" length for the fragment.
override parameters can be easily identified by examining
parameter headers, because they have parameter_number's from
general parameter portion of the number space (1-127), but are
in service-specific data blocks (those with service_numbers between 2
and 254 in the per_service header field).
The presence of override parameters in a data fragment is optional.
parameter header/value pair is added only when a
application or QoS control service wishes to override the
value of a general parameter with a service-specific value
As with IP options, it is only the use of these override
that is optional. All implementations must be prepared to receive
process override parameters
The basic principle for handling override parameters is to use
override value (local or adspec) if it exists, and to use the
value otherwise. If a local node exports an override value for
general parameter, but there is no override value in the
adspec, the local node adds it. The following pseudo-code
gives more detail
Wroclawski Standards Track [Page 24]
RFC 2210 RSVP with INTSERV September 1997
/* Adspec parameter processing rules *
for ( fragment in the ADSPEC> ) {
if ( ) {
} else {
for ( parameter in the data fragment for service N> ) {
if ( < the local service N supplies a value for the parameter> ) {
} else {
/* Must be a general parameter, or service N would
* supplied a value..
*/
and update the adspec
}
}
for ( parameters supplied by the local service
implementation but not found in the adspec> ) {
/*
* Must be an override value for a general parameter
* or the adspec would have contained a value..
*/
value (from the service 1 data fragment) and add the
to the adspec's service N fragment in parameter_number order
}
}
}
In practice, the two 'for' loops can be combined. Since
parameters within a service's fragment are transmitted in
order, it is possible to determine whether a parameter is
without scanning the entire fragment. Also, because the
fragments are ordered by service_number, the default values
general parameters will always be read before they might be needed
update local override values in the second for loop
3.3.6.
The picture below shows the complete adspec for an application
can use either controlled-load or guaranteed service. In the example
Wroclawski Standards Track [Page 25]
RFC 2210 RSVP with INTSERV September 1997
data fragments are present for general parameters, guaranteed,
controlled-load services. All fragments are of standard size,
there are no override parameters present
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | Unused | 19 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |x| reserved (d)| 8 (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 4 (f) | (g) | 1 (h) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | zero extension of .. IS hop cnt (16-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | 6 (i) | (j) | 1 (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Path b/w estimate (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | 8 (l) | (m) | 1 (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Minimum path latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 10 (o) | (p) | 1 (q) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | zero extension of .. composed MTU (16-bit unsigned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | 2 (r) |x| reserved (s)| 8 (t) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | 133 (u) | (v) | 1 (w) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
13 | End-to-end composed value for C [Ctot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
14 | 134 (x) | (y) | 1 (z) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
15 | End-to-end composed value for D [Dtot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | 135 (aa | (bb | 1 (cc) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17 | Since-last-reshaping point composed C [Csum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18 | 136 (dd) | (ee) | 1 (ff) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19 | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | 5 (gg |x 0 (hh) | 0 (ii) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wroclawski Standards Track [Page 26]
RFC 2210 RSVP with INTSERV September 1997
Word 1: Message Header
(a) - Message header and version
(b) - Message length - 19 words not including
Words 2-7: Default general characterization
(c) - Per-Service header, service number 1
(Default General Parameters
(d) - Global Break bit (NON_IS_HOP general parameter 2) (marked x
(e) - Length of General Parameters data block (8 words
(f) - Parameter ID, parameter 4 (NUMBER_OF_IS_
general parameter
(g) - Parameter 4 flag
(h) - Parameter 4 length, 1 word not including
(i) - Parameter ID, parameter 6 (AVAILABLE_PATH_
general parameter
(j) - Parameter 6 flag
(k) - Parameter 6 length, 1 word not including
(l) - Parameter ID, parameter 8 (MINIMUM_PATH_
general parameter
(m) - Parameter 8 flag
(n) - Parameter 8 length, 1 word not including
(o) - Parameter ID, parameter 10 (PATH_MTU general parameter
(p) - Parameter 10 flag
(q) - Parameter 10 length, 1 word not including
Words 11-19: Guaranteed service
(r) - Per-Service header, service number 2 (Guaranteed
(s) - Break
(t) - Length of per-service data, 8 words not including
(u) - Parameter ID, parameter 133 (Composed Ctot
(v) - Composed Ctot flag
(w) - Composed Ctot length, 1 word not including
(x) - Parameter ID, parameter 134 (Composed Dtot
(y) - Composed Dtot flag
(z) - Composed Dtot length, 1 word not including
(aa)- Parameter ID, 