Connected: An Internet Encyclopedia
3.1.2 Object Formats

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2205
Up: 3. RSVP Functional Specification
Up: 3.1 RSVP Message Formats
Prev: 3.1.1 Common Header
Next: 3.1.3 Path Messages

3.1.2 Object Formats

3.1.2 Object Formats

Every object consists of one or more 32-bit words with a one- word header, with the following format:

                0             1              2             3
         |       Length (bytes)      |  Class-Num  |   C-Type    |
         |                                                       |
         //                  (Object contents)                   //
         |                                                       |

An object header has the following fields:


A 16-bit field containing the total object length in bytes. Must always be a multiple of 4, and at least 4.


Identifies the object class; values of this field are defined in Appendix A. Each object class has a name, which is always capitalized in this document. An RSVP implementation must recognize the following classes:


A NULL object has a Class-Num of zero, and its C-Type is ignored. Its length must be at least 4, but can be any multiple of 4. A NULL object may appear anywhere in a sequence of objects, and its contents will be ignored by the receiver.


Contains the IP destination address (DestAddress), the IP protocol id, and some form of generalized destination port, to define a specific session for the other objects that follow. Required in every RSVP message.


Carries the IP address of the RSVP-capable node that sent this message and a logical outgoing interface handle (LIH; see Section 3.3). This document refers to a RSVP_HOP object as a PHOP ("previous hop") object for downstream messages or as a NHOP (" next hop") object for upstream messages.


Contains the value for the refresh period R used by the creator of the message; see Section 3.7. Required in every Path and Resv message.


Defines the reservation style plus style-specific information that is not in FLOWSPEC or FILTER_SPEC objects. Required in every Resv message.


Defines a desired QoS, in a Resv message.


Defines a subset of session data packets that should receive the desired QoS (specified by a FLOWSPEC object), in a Resv message.


Contains a sender IP address and perhaps some additional demultiplexing information to identify a sender. Required in a Path message.


Defines the traffic characteristics of a sender's data flow. Required in a Path message.


Carries OPWA data, in a Path message.


Specifies an error in a PathErr, ResvErr, or a confirmation in a ResvConf message.


Carries information that will allow a local policy module to decide whether an associated reservation is administratively permitted. May appear in Path, Resv, PathErr, or ResvErr message.

The use of POLICY_DATA objects is not fully specified at this time; a future document will fill this gap.


Carries cryptographic data to authenticate the originating node and to verify the contents of this RSVP message. The use of the INTEGRITY object is described in [Baker96].


Carries an explicit list of sender hosts towards which the information in the message is to be forwarded. May appear in a Resv, ResvErr, or ResvTear message. See Section 3.4.


Carries the IP address of a receiver that requested a confirmation. May appear in a Resv or ResvConf message.


Object type, unique within Class-Num. Values are defined in Appendix A.

The maximum object content length is 65528 bytes. The Class- Num and C-Type fields may be used together as a 16-bit number to define a unique type for each object.

The high-order two bits of the Class-Num is used to determine what action a node should take if it does not recognize the Class-Num of an object; see Section 3.10.

Next: 3.1.3 Path Messages

Connected: An Internet Encyclopedia
3.1.2 Object Formats