next up previous contents
Next: Making a Reservation using Up: Resource ReSerVation Protocol (RSVP) Previous: Processing and Propagation of

  
Adspec

The Adspec is an optional object descriptor that the sender may include in its generated Path messages in order to advertise to receivers the characteristics of the end to end communications path. This information can be used by receivers to determine the level of reservation required in order to achieve their desired end to end QOS. The

Adspec consists of a message header, a Default General Parameters part and at least one of the following; Guaranteed Service part, Controlled-Load Service part. Omission of either the Guaranteed or Controlled-Load Service part is an indication to receivers that the omitted service is not available. This feature can be used in a multicast Session to force all receivers to select the same service. At present RSVP does not accommodate heterogeneity of services between receivers within a given multicast Session, although, within the same service model, the parameters may differ for receivers in the same session, so the core objective of supporting heterogeneity is mainly met.

Default General Part

The Default General Parameters part includes the following fields which are updated at each RSVP-capable router along the path in order to present end-to-end values to the receivers.

Correct functioning of IETF Integrated Services requires that packets of a data flow are never fragmented. It might be possible to devise a scheme to support QoS for fragmented traffic, but the key problem of how loss of fragment results in loss of overall datagram is hard to work around!

This also means that the value of M in the Tspec of a reservation request must never exceed the MTU of any link to which the reservation request applies to. MTU Discovery can be employed to avoid this.

A receiver can ensure that this requirement is met by setting the value of M in the Tspec of it's reservation request to the minimum of the PathMTU values received in ``relevant'' Path messages. The value of M in each generated reservation request may be further reduced on the way to each sender if merging of Resv messages occurs(see section 2.9.2). The minimum value of M from the Tspec of each Resv message received by the sender should then be used by the sending application as the upper limit on the size of packets to receive special QOS. In this way fragmentation of these packets will never occur. In cases where the last hop to a sender is a shared medium LAN the sender may receive Resv messages across the same interface from multiple next hop routers.

The specification [#!rsvpandintserv!#] recommends that the value of M in the Sender Tspec, which has played no part in the above MTU negotiation process, should be set equal to the maximum packet size that the sender is capable of generating rather than what it is currently sending.

Guaranteed Service Part

The Guaranteed Service part of the Adspec includes the following fields which are updated at each RSVP-capable router along the path in order to present end-to-end values to the receivers.

Controlled Load part

The Controlled-Load Service part of the Adspec includes the following fields which are updated at each RSVP-capable router along the path in order to present end-to-end values to the receivers.


next up previous contents
Next: Making a Reservation using Up: Resource ReSerVation Protocol (RSVP) Previous: Processing and Propagation of
Jon CROWCROFT
1998-12-03