The Use of RSVP with IETF Integrated Services
Extracted elements (30)
Controlled-Load and Guaranteed services share a common Token Bucket TSpec (parameter 127, service 1) so that a single SENDER_TSPEC object suffices for both services; receivers learn which service they can use from the ADSPEC rather than from service-differentiated TSpecs.
SENDER_TSPEC and ADSPEC are kept as separate RSVP objects rather than combined into one downstream object because the distinction between data never modified in transit (SENDER_TSPEC) and data updated at each hop (ADSPEC) is useful to implementations in practice, even though the message format could technically accommodate both in a single object.
The ADSPEC accumulates a summary of path properties at each hop rather than sending separate per-node reports to receivers, keeping ADSPEC size roughly constant as it traverses the network and providing good scaling properties.
The ADSPEC uses variable-length, service-numbered fragments so that new QoS services can be deployed without immediately updating existing code; unknown fragments are skipped using the SVC_LENGTH field, with only the break bit set to indicate the service was not processed at that hop.
Override parameters within a service's ADSPEC data fragment carry parameter numbers from the general parameter number space (1-127) but appear inside service-specific data blocks (service_numbers 2-254), allowing quick detection by checking whether the fragment length exceeds the standard length for that service.
When a PATH message ADSPEC without a particular service fragment (Guaranteed or Controlled-Load) encounters a node implementing that service, the service module leaves the ADSPEC unchanged; the complete absence of a fragment is a signal from the sender that the service should not be used by receivers.
When an ADSPEC encounters a network element that does not recognize a per-service header, the element sets bit 23 (break bit) of that per-service header and skips the remainder of the fragment, enabling forward-compatible extension with future services without breaking existing routers.
All implementations must be prepared to receive and process service-specific override parameters in ADSPEC data fragments; while the presence of such parameters is optional, processing them is mandatory.
Data fragments must always appear in an ADSPEC in service_number order; in particular the default general parameters fragment (service_number=1) must always come first.
In RSVP Version 1, all receivers within a session are required to choose the same QoS control service, as the protocol cannot merge reservations requesting different services.
The [M] field in a receiver's FLOWSPEC should be set to the smallest PATH_MTU value learned from arriving ADSPEC objects; requesting [M] larger than the service modules along the path can support will cause the reservation to fail.
The Maximum Packet Size [M] must be equal to or larger than the Minimum Policed Unit [m] by definition.
The minimum policed unit parameter [m] in a TSpec must not be zero; a value of zero would indicate no data or IP headers are present, yielding infinite link-level overhead.
When an ADSPEC encountering a Guaranteed-service-capable node has only a header-only Guaranteed fragment, the node must expand it to the full data fragment with Ctot, Dtot, Csum, Dsum initialized to zero (preserving the break bit) before composing local values.
Break bits are per-service flags in ADSPEC per-service headers signaling a break in QoS coverage. The global break bit (service 1, bit 23) indicates a non-RSVP or non-IS hop exists; service-specific break bits indicate a particular service (Guaranteed or Controlled-Load) is unsupported at one or more hops, rendering that service's ADSPEC parameters unreliable.
Path MTU negotiation uses the PATH_MTU composed characterization parameter (param 10, service 1) accumulated in the ADSPEC as it flows from sender to receiver. Each receiver takes the minimum PATH_MTU across all arriving ADSPECs and uses it as [M] in its FLOWSPEC; the merged FLOWSPEC arriving at each sender carries the smallest MTU acceptable across all data paths.
Positive infinity for the peak rate [p] in a Token Bucket TSpec is represented as an IEEE single-precision floating-point number with an exponent of all ones (255) and a sign and mantissa of all zeros.
The RSVP ADSPEC object carries path property information generated at senders or intermediate network elements, flowing downstream toward receivers. It consists of a mandatory default general parameters fragment (service 1) plus optional per-service fragments for Guaranteed (service 2) and Controlled-Load (service 5), each updated by RSVP-aware nodes.
The RSVP FLOWSPEC object carries receiver-generated reservation requests upstream toward senders. For Controlled-Load it carries a Token Bucket TSpec (service_number=5); for Guaranteed service it carries both a TSpec and an RSpec (service_number=2).
The RSVP SENDER_TSPEC object carries the sending application's traffic specification (Token Bucket TSpec, service 1, parameter 127) downstream from senders to intermediate nodes and receivers via PATH messages. It is never modified by intermediate network elements within the network.
The use of RSVP objects to invoke enhanced QoS services introduces a security requirement to control and authenticate access to those services. Integrity of RSVP messages carrying SENDER_TSPEC, ADSPEC, and FLOWSPEC objects is addressed by RSVP cryptographic authentication (RFCRSVPMD5), discussed further in RFC 2205, RFC 2211, and RFC 2212.
The ADSPEC Controlled-Load Service fragment (service 5) is a minimum of 1 32-bit word (the per-service header alone with the break bit), since Controlled-Load requires no additional service-specific parameters. Service-specific override parameters for general parameters may optionally follow.
The ADSPEC Default General Parameters fragment (service 1) is 9 32-bit words carrying four parameters: IS hop count (param 4, 32-bit unsigned), path bandwidth estimate (param 6, IEEE float), minimum path latency (param 8, 32-bit int), and composed MTU (param 10, 32-bit unsigned). Bit 23 of word 1 is the global NON_IS_HOP break bit.
The ADSPEC Guaranteed Service fragment (service 2) carries four mandatory 32-bit integer parameters: end-to-end composed C [Ctot] (param 133), end-to-end composed D [Dtot] (param 134), since-last-reshaping-point composed C [Csum] (param 135), and since-last-reshaping-point composed D [Dsum] (param 136). A header-only 'empty' variant (length=0, break bit set) is also defined.
The Controlled-Load FLOWSPEC is 8 32-bit words identical in structure to the SENDER_TSPEC except that the per-service header carries service_number=5 (Controlled-Load). Fields are: [r], [b], [p] (IEEE floats), [m], [M] (32-bit ints) as parameter 127.
The Guaranteed Service FLOWSPEC is 11 32-bit words with service_number=2 in its per-service header. It carries a Token Bucket TSpec (parameter 127, words 3-8: [r], [b], [p], [m], [M]) plus a Guaranteed Service RSpec (parameter 130, words 9-11) containing Rate [R] (IEEE 32-bit float) and Slack Term [S] (32-bit int).
The overall message header is a single 32-bit XDR unsigned integer: bits 31-28 are version V (currently 0), bits 27-16 are unused, bits 15-0 are OVERALL LENGTH in 32-bit words not including the header word itself.
The Parameter Header is a 32-bit XDR unsigned integer: bits 31-24 are PARAM_NUM, bit 23 is the INVALID flag I (value not correctly processed at one or more hops), bits 22-16 are FLAGS (currently reserved, set to zero), and bits 15-0 are PARAM_LENGTH in 32-bit words not including the header.
The Per-Service Data Header is a 32-bit XDR unsigned integer: bits 31-24 are SVC_NUMBER, bit 23 is the break bit B (set if the service was unsupported or unrecognized at some network element), bits 22-16 are reserved, and bits 15-0 are SVC_LENGTH in 32-bit words not including the header word.
The SENDER_TSPEC object is 8 32-bit words: a version-0 message header, a service-1 sub-header (6 words of data), and a parameter-127 header followed by five data words encoding Token Bucket Rate [r] and Size [b] (IEEE 32-bit float each), Peak Data Rate [p] (IEEE 32-bit float), Minimum Policed Unit [m] (32-bit int), and Maximum Packet Size [M] (32-bit int).