Download (direct link):
3. Shared explicit (SE) style: A list of senders is explicitly stated, and there is a single shared reservation for all of their flows.
7.3.2 Soft State
RSVP takes a soft state approach to managing the reservation state in the routers and hosts. That is, the state information in each router and host has to be periodically refreshed by
LABEL DISTRIBUTION PROTOCOLS
Path and Resv messages. The state of a reservation is deleted if no matching refreshing messages arrive before a cleanup timeout interval. State can also be deleted by an explicit teardown message.
When a route changes, the next Path message will initialize the path state on the routers along the new route and the Resv message will establish a reservation on each of these routers. The state of the unused route will time out.
RSVP sends its messages as IP datagrams with no guarantee that they will get delivered. An RSVP message might never get delivered due to transmission errors or buffer overflows. This situation is taken care by the periodic refresh messages. Sending refresh messages increases the load on the network, but it eliminates the need to use a reliable protocol such as TCP which guarantees the reliable delivery of RSVP messages.
7.3.3 The RSVP Message Format
An RSVP message consists of a common header followed by a variable number of objects. Each object contains a group of related parameters and it has a variable length. The common header format is shown in Figure 7.20. The following fields have been defined:
Vers: A 4-bit field used to indicate the protocol version number.
Flags: A 4-bit field used for flags; no flags have been specified.
MsgType: The message type is specified by a number carried in this 8-bit field. The following message types and numbers have been specified:
? 1 - Path
? 2 - Resv
? 3 - PathErr
? 4 - ResvErr
? 5 - PathTear
? 6 - ResvTear
? 7 - ResvConf
RSVP checksum: A 16-bit checksum calculated on the entire message.
Send_TTL: An 8-bit field that contains the IP time to live value.
RSVP length: The total length in bytes is stored in this 8-bit field. The length includes the common header and all of the objects that follow.
The object format is shown in Figure 7.21. The following fields have been defined:
Length: A 16-bit field used to indicate the total length in bytes of the object. It must be a multiple of four, and at least equal to four.
Class-num: An 8-bit field used to identify the object class.
C-Type: An 8-bit field used to define the object type.
4 Bits 4 Bits 8 Bits 16 Bits
Vers Flags MsgType RSVP checksum
d L Reserved RSVP length
Figure 7.20 The common header format.
THE RESOURCE RESERVATION PROTOCOL (RSVP)
1 Byte 1 Byte
Figure 7.21 The object format.
The following object classes have been defined:
NULL: The contents of a NULL object are ignored by the receiver.
SESSION: Contains the IP destination address, the IP protocol id, and optionally a destination port. This object is required in every RSVP message.
RSVP HOP: Carries the IP address of the RSVP-capable router that sent this message. For messages sent from the sender to the receiver, the RSVPHOP object is referred to as the previous hop (PHOP) object; for messages sent from the receiver to the sender, it is referred to as the next hop (NHOP) object.
TIME VALUES: Contains the value for the refresh period used by the creator of the message. It is required in every Path and Resv message.
STYLE: Defines the reservation style plus style-specific information. It is required in every Resv message.
FLOWSPEC: Carries the necessary information in an Resv message to make a reservation in a router.
FILTER SPEC: Defines which data packets should receive the QoS specified in the FLOWSPEC object. It is required in a Resv message.
SENDER TEMPLATE: Defines the senders IP address and perhaps some additional demultiplexing information, such as a port number. It is required in a Path message.
SENDER TSPEC: Contains the traffic characteristics of the senders data flow. It is required in a Path message.
ADSPEC: Carries the one-pass with advertising (OPWA) information. As discussed above, this information is gathered at each node along the path that is followed by the Path message. This information is delivered to the receiver, who can then use it to construct a reservation request or adjust an existing reservation appropriately.
ERROR SPEC: Specifies an error in a PathErr, ResvErr, or a confirmation in a Resv-Conf message.
POLICY DATA: Carries information that allows a router to decide whether a reservation is administratively permitted. It can appear in a Path, Resv, PathErr, or ResvErr message. One or more POLICY DATA objects can be used.