specific to the Controlled-Load service is the Controlled-Load break
bit. Therefore the usual Controlled-Load service data block contains
no extra information. The minimum size of the controlled-load service
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 bit
(c) - Length of per-service data in 32 bit words not including
header word.
The Controlled-Load portion of the ADSPEC is processed according to
the following rules:
- When a PATH message ADSPEC with a Controlled-Load service header
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 header
encounters a network element that supports RSVP but does *not*
implement Controlled-Load service, the network element sets the
break bit in the Controlled-Load service header.
- In either case, the ADSPEC is passed back to RSVP for delivery
to the next hop along the path.
3.3.5. Overriding Global ADSPEC Data with Service-Specific Information
In some cases, the default values for the general parameters are not
correct for a particular service. For example, an implementation of
Guaranteed service may accept only packets with a smaller maximum
size than the link MTU, or the percentage of outgoing link bandwidth
made available to the Controlled-Load service at a network element
may be administratively limited to less than the overall bandwidth.
In these cases, a service-specific value, as well as the default
value, is reported to the receiver receiving the ADSPEC. Service-
specific information which overrides general information is carried
by a parameter with the same name as the general parameter, placed
within the data fragment of the QoS control service to which it
applies. These service-specific values are referred to as override or
service-specific general parameters.
For example, the following Controlled-Load ADSPEC fragment carries
information overriding the global path bandwidth estimate with a
different value:
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 bit
(c) - Length of per-service data, two words not including header
(c) - Parameter ID, parameter 6
(AVAILABLE_PATH_BANDWIDTH general parameter from [RFC2215])
(d) - Parameter 6 flags (none set)
(e) - Parameter 6 length, one word not including header
The presence of override parameters in a data fragment can be quickly
detected by examining the fragment's length field, which will be
larger than the "standard" length for the fragment. Specific
override parameters can be easily identified by examining the
parameter headers, because they have parameter_number's from the
general parameter portion of the number space (1-127), but are found
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. A
parameter header/value pair is added only when a particular
application or QoS control service wishes to override the global
value of a general parameter with a service-specific value.
As with IP options, it is only the use of these override parameters
that is optional. All implementations must be prepared to receive and
process override parameters.
The basic principle for handling override parameters is to use the
override value (local or adspec) if it exists, and to use the default
value otherwise. If a local node exports an override value for a
general parameter, but there is no override value in the arriving
adspec, the local node adds it. The following pseudo-code fragment
gives more detail:
/* Adspec parameter processing rules *
<get arriving ADSPEC from RSVP>
for ( <each service number N with a fragment in the ADSPEC> ) {
if ( <the local node does not support the service> ) {
<set the break bit in the service header>
} else {
for ( <each parameter in the data fragment for service N> ) {
if ( < the local service N supplies a value for the parameter> ) {
<compose the arriving and values and update the adspec>
} else {
/* Must be a general parameter, or service N would have
* supplied a value..
*/
<compose the arriving value with the local default value
and update the adspec>
}
}
for ( <any parameters supplied by the local service N
implementation but not found in the adspec> ) {
/*
* Must be an override value for a general parameter,
* or the adspec would have contained a value..
*/
<compose the local override value with the arriving default
value (from the service 1 data fragment) and add the parameter
to the adspec's service N fragment in parameter_number order>
}
}
}
<pass updated ADSPEC back to RSVP>
In practice, the two 'for' loops can be combined. Since override
parameters within a service's fragment are transmitted in numerical
order, it is possible to determine whether a parameter is present
without scanning the entire fragment. Also, because the data
fragments are ordered by service_number, the default values for
general parameters will always be read before they might be needed to
update local override values in the second for loop.
3.3.6. Example
The picture below shows the complete adspec for an application which
can use either controlled-load or guaranteed service. In the example,
data fragments are present for general parameters, guaranteed, and
controlled-load services. All fragments are of standard size, and
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Word 1: Message Header:
(a) - Message header and version number
(b) - Message length - 19 words not including header
Words 2-7: Default general characterization parameters
(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_HOPS
general parameter)
(g) - Parameter 4 flag byte
(h) - Parameter 4 length, 1 word not including header
(i) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH
general parameter)
(j) - Parameter 6 flag byte
(k) - Parameter 6 length, 1 word not including header
(l) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY
general parameter)
(m) - Parameter 8 flag byte
(n) - Parameter 8 length, 1 word not including header
(o) - Parameter ID, parameter 10 (PATH_MTU general parameter)
(p) - Parameter 10 flag byte
(q) - Parameter 10 length, 1 word not including header
Words 11-19: Guaranteed service parameters
(r) - Per-Service header, service number 2 (Guaranteed)
(s) - Break bit
(t) - Length of per-service data, 8 words not including header
(u) - Parameter ID, parameter 133 (Composed Ctot)
(v) - Composed Ctot flag byte
(w) - Composed Ctot length, 1 word not including header
(x) - Parameter ID, parameter 134 (Composed Dtot)
(y) - Composed Dtot flag byte
(z) - Composed Dtot length, 1 word not including header
(aa)- Parameter ID, parameter 135 (Composed Csum).
(bb)- Composed Csum flag byte
(cc)- Composed Csum length, 1 word not including header
(dd)- Parameter ID, parameter 136 (Composed Dsum).
(ee)- Composed Dsum flag byte
(ff)- Composed Dsum length, 1 word not including header
Word 20: Controlled-Load parameters
(gg - Per-Service header, service number 5 (Controlled-Load)
(hh)- Break bit
(ii)- Length of controlled-load data, 0 words not including header
4. Security Considerations
The message formatting and usage rules described in this note raise
no security issues. The overall use of these rules to implement
multiple qualities of service using RSVP and integrated services
scheduling modules introduces a new security requirement; the need to
control and authenticate access to enhanced qualities of service.
This requirement is discussed further in [RFC2205], [RFC2212], and
[RFC2211]. [RFCRSVPMD5] describes the mechanism used to protect the
integrity of RSVP messages carrying the information described here.
Appendix 1: Message construction rules
This section gives the rule used to generate the object formats of
Section 3. It is a general wire format for encoding integrated
services data objects within setup and management protocol messages.
The format has a three-level structure:
- An overall message header carries a version number and message
length. Providing this header in a standard format allows the
same code library to handle data objects carried by multiple setup
protocols.
- Per-service fragments carry information about a specific QoS
control service, such as guaranteed [RFC2212] or controlled load
[RFC2211]. Each per-service fragment carries one or more
parameters. The set of parameters present in a fragment is
determined by the needs of the protocol in use. Examples are given
in Section 2.
- Parameters are the actual data used to control or monitor a
service. A parameter may be a single quantity such as an integer,
or a composite data structure such as a TSpec. The parameters
specific to a service are defined by the service specification.
The available general parameters, with definitions shared by many
services, are defined by [RFC2215].
A1.1. Message Header
The 32-bit message header specifies the message format version number
and total length of the message. The overall message must be aligned
to a 32-bit boundary within the transport protocol's data packet.
The message length is measured in 32-bit words *not including the
word containing the header*. This is to lower the probability of an
accidentally cleared word resulting in an infinite loop in the
message parser.
The Message Header is represented by a 32-bit bitfield laid out as
shown below and then encoded as an XDR unsigned integer. Encoding as
an XDR unsigned integer is equivalent to converting the bitfield from
the machine's native format to big-endian network byte order.
Message Header
MSB LSB
31 28 27 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Unused | OVERALL LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V - Message format version; currently 0
OVERALL LENGTH - Message length in 32-bit words not including header
A1.2. Per-Service Data Header
The message header is followed by one or more service-specific data
blocks, each containing the data associated with a specific QoS
control service. Each service-specific data block begins with an
identifying header. This 32-bit header contains the service number, a
one-bit flag (the "break bit", because it indicates a break in the
QoS control path) and a length field. The length field specifies the
number of 32-bit words used to hold data specific to this service as
a count of 32-bit words *not including the word containing the
header*.
The break bit, if set, indicates that the service specified by the
header was unsupported or unrecognized at some point in the message's
path through the network. This bit corresponds to the general
parameter NON_IS_HOP defined in [RFC2215]. It is cleared when a
message is first generated, and set whenever the message passes
through an element that does not recognize the service_number in the
per-service header.
The Per-Service Data Header is represented by a 32-bit bitfield laid
out as shown below and then encoded as an XDR unsigned integer.
Per-Service Data Header
MSB LSB
31 24 23 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SVC_NUMBER |B| Reserved | SVC_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SVC_NUMBER - Service ID number (defined in service specification).
B - Break bit - service unsupported/break in path.
SVC_LENGTH - Service-specific data length in 32-bit words,
not including header.
A1.3. Parameter Header
The per-service header is followed by one or more service parameter
blocks, each identified by a Parameter Header. This header contains
the parameter identifier (parameter number), the length of the data
carrying the parameter's value, and a flag field. The data field(s)
of the parameter follow. The parameter number, as well as the
meaning and format of the data words following the header, are given
by the specification which defines the parameter.
The Parameter Header is represented by a 32-bit bitfield laid out as
shown below and then encoded as an XDR unsigned integer.
Parameter Header
MSB LSB
31 24 23 16 15 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PARAM_NUM |I FLAGS | PARAM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PARAM_NUM - Parameter number (defined in service specification)
FLAGS - Per-parameter flags
PARAM_LENGTH - Length of per-parameter data in 32-bit words, not
including the header word.
The following flags are currently defined in the FLAGS field:
I (bit 23) - INVALID
This flag indicates that the parameter value was
not correctly processed at one or more network
elements along a data path. It is intended for use
in a possible future service composition scheme.
Other bits in the FLAGS field of the parameter header are currently
reserved, and should be set to zero.
A1.4. Parameter Data
Following the Parameter Header is the actual data representing the
parameter value. Parameter values are encoded into one or more 32-bit
words using the XDR external data representation described in [RFC
1832], and the resulting words are placed in the message.
The document defining a parameter should provide an XDR description
of the parameter's data fields. If it does not, a description should
be provided in this note.
References
[RFC2205] Braden, B., Ed., et. al., "Resource Reservation Protocol
(RSVP) - Version 1 Functional Specification", RFC2205, September
1997.
[RFC2216] Shenker, S., and J. Wroclawski. "Network Element QoS
Control Service Specification Template", RFC2216, September 1997.
[RFC2212] Shenker, S., Partridge, C., and R Guerin, "Specification
of Guaranteed Quality of Service", RFC2212, September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled Load
Quality of Service", RFC2211, September 1997.
[RFC2215] Shenker, S., and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC2215,
September 1997.
[RFCRSVPMD5] Baker, F., "RSVP Cryptographic Authentication", Work in
Progress.
[RFC1832] Srinivansan, R., "XDR: External Data Representation
Standard", RFC1832, August 1995.
Author's Address
John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139
Phone: 617-253-7885
Fax: 617-253-2673 (FAX)
EMail: jtw@lcs.mit.edu