RSVP Message Format

Each RSVP message consists of a common header and a body consisting of a variable number of objects that depend on the message type. The objects in the message provide the information necessary to make resource reservations. The format of the common header is shown in Figure 10.26.

The current protocol version is 1, and no flag bits are currently defined. The seven message types are Path, Resv, PathErr, ResvErr, PathTear, ResvTear, and ResvConf.

The RSVP checksum uses the 1s complement algorithm common in TCP/IP checksum computation. The Send_TTL represents the IP TTL value with which the message was sent. It can be used to detect a non-RSVP hop by comparing the Send_TTL value in the RSVP common header and the TTL value in the IP

0 4 8 16 31

Version

Flags

Message type

RSVP checksum

Send_TTL

Reserved

RSVP length

FIGURE 10.26 Format of common header

FIGURE 10.26 Format of common header header. The RSVP length field indicates the total length of the RSYP message in octets, including the common header.

The format of the objects that follow the common header is shown in Figure 10.27. The length field indicates the total object length in octets. The length must be a multiple of four.

The Class-Num field identifies the object class. The C-Type value identifies the subclass of the object. The following object classes are defined:

NULL: A NULL object is ignored by the receiver.

SESSION: A SESSION object specifies the session for the other objects that follow. It is indicated by the IP destination address, IP protocol number, and destination port number. The session object is required in every message.

RSVP_HOP: This object carries the IP address of the RSVP-capable router that sent this message. For downstream messages (e.g., Path from source to receiver), this object represents the previous hop; for upstream messages (e.g., Resv from receiver to source), this object represents the next hop.

TIME_VALUES: This object contains the value of the refresh period R.

STYLE: This object defines the reservation style information that is not in the flowspec or filterspec objects. This object is required in the Resv message.

FLOWSPEC: This object defines the desired QoS in a Resv message.

FILTER-SPEC: This object defines the set of packets that receive the desired QoS in a Resv message.

SENDER_TEMPLATE: This object provides the IP address of the sender in a Path message.

SENDER_TSPEC: This object defines the sender's traffic characteristics in a Path message.

ADSPEC: This object carries end-to-end path information (OPWA8) in a Path message.

ERROR_SPEC: This object specifies errors in PathErr and ResvErr, or errors in a confirmation in ResvConf.

POLICY_DATA: This object carries policy information that enables the policy module in a node to determine whether a request is allowed or not.

Was this article helpful?

0 0

Post a comment