The RSVP Message Format

THE RESOURCE RESERVATION PROTOCOL – TRAFFIC ENGINEERING 175

7.4.2 The RSVP-TE New Objects

The following five new objects have been introduced to support the functionality of RSVP-TE: • LABEL • LABEL REQUEST • EXPLICIT ROUTE • RECORD ROUTE • SESSION ATTRIBUTE Also, new C-Types have also been defined for the SESSION, SENDER TEMPLATE, and FILTER SPEC objects. We now proceed to examine the format of these new five objects. The LABEL object The LABEL object is used in the Resv message to advertise a label. For the FF and SE styles, a node allocates a separate label for each sender to be used by the previous hop node. The format of the LABEL object is shown in Figure 7.22. The LABEL object class given in the Class-num field is 16, the object type given in the C-Type field is C-Type 1, and the object contents is populated with a single label encoded in 4 bytes. A generic MPLS label and a frame relay label is encoded in four bytes. An ATM label is encoded with the VPI field in the bits 0 to 15 and the VCI field in the bits 16 to 31. A node can support multiple label spaces. For instance, it can associate a unique label space for each incoming interface. Labels received in Resv messages on different interfaces are always considered as being different even if the label value is the same. The LABEL REQUEST object The LABEL REQUEST object class Class-num field is 19, and there are three different object types C-Type field: C-Type 1, C-Type 2 and C-Type 3. C-Type 1 is a label request for generic labels, C-Type 2 is a label request for ATM labels, and C-Type 3 is a label request for frame relay labels. These three formats are shown in Figure 7.23. The object contents of the C-Type 1 consist of a 16-bit reserved field, and the 16-bit L3PID field which is populated with an identifier of the Layer 3 protocol using this path. The object contents of the C-type 2 consist of the following fields reserved fields are not listed: • L3PID : A 16-bit field that carries the identifier of the Layer 3 protocol that is using this path. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 1 Length bytes Label Class-num C-Type Figure 7.22 The LABEL object format. 176 LABEL DISTRIBUTION PROTOCOLS C_Type = 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 1 Reserved L3PID Length bytes Class-num C-Type C_Type = 2 Minimum VPI Minimum VCI Maximum VPI M Res Res Maximum VCI 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 1 L3PID Reserved Length bytes Class-num C-Type C_Type = 3 Minimum DLCI Maximum DLCI DLI 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 1 L3PID Reserved Reserved Reserved Length bytes Class-num C-Type Figure 7.23 The LABEL REQUEST object formats. • M : A 1-bit field that is used to indicate whether the node is capable of merging in the data plane. • Minimum VPI : A 12-bit field that gives a lower bound on the block of the VPI sup- ported values. • Minimum VCI : A 16-bit field that gives a lower bound on the block of the VCI sup- ported values. • Maximum VPI : A 12-bit field that gives an upper bound on the block of the VPI supported values. • Maximum VCI : A 16-bit field that gives an upper bound on the block of the VCI supported values. The object contents of the C-type 3 consist of the following fields reserved fields are not listed: • L3PID : A 16-bit field that carries the identifier of the Layer 3 protocol that is using this path. • DLCI length indicator DLI : A 2-bit field that indicates the length of the DLCI value. The following values are supported: 0 and 2. When DLI = 0, then the length of the DLCI is 10 bits. When it is set to 2, the length of the DLCI value is 23 bits. • Minimum DLCI : This 23-bit field gives the lower bound on the block of the supported DLCI values. THE RESOURCE RESERVATION PROTOCOL – TRAFFIC ENGINEERING 177 • Maximum DLCI : This 23-bit field give the upper bound on the block of the supported DLCI values. In order to establish an LSP, the sender creates a Path message with a LABEL REQUEST object. This object indicates that a label binding for this path is requested and it provides an indication of the network protocol layer that is to be carried over the path. This permits packets form non-IP network layer protocols to be sent down an LSP. This information is also useful in label allocation, because some reserved labels are protocol specific. A receiver that cannot support the protocol indicated in the L3PID field, sends a PathErr message back to the sender. The EXPLICIT ROUTE object ERO This object is used to specify the hops in the requested explicit route. Each hop could be a single node or a group of nodes, referred to as an abstract node. For simplicity, RSVP-TE refers to all of the hops as abstract nodes, with the understanding that an abstract node could consist of a single node. The EXPLICIT ROUTE object class is 20, and only one object type C-Type 1 has been defined. The object contents consists of a series of variable-length sub-objects, each of which contains an abstract node. The format of the sub-object is shown in Figure 7.24. The following fields have been defined: • L : A 1-bit field used to indicate whether the route through an abstract node is loose or strict. • Type : This 7-bit field is populated with a value that indicates the type of contents of the sub-object. The following values have been defined: 0 if the sub-object contains an IPv4 prefix, 1 if it contains an IPv6 prefix, and 32 if it contains an autonomous system number. • Length : This 8-bit field is populated with the length in bytes of the sub-object including the L, type, and length fields. The format of the sub-objects for the IPv4 and IPv6 is shown in Figure 7.25. The field IPv4 address respectively IPv6 address in the IPv4 IPv6 sub-object contains an IPv4 IPv6 prefix whose length is given in the prefix length field. The abstract node represented by this sub-object is the set of all nodes whose IPv4 IPv6 address has the prefix given in the IPv4 IPv6 address field. Note that a prefix length of 128 indicates a single node. The sub-object format for the autonomous system is the same as the one shown in Figure 7.24, with the sub-object contents consisting of a two-byte field populated with the autonomous system number. The abstract node represented by this sub-object is the set of all nodes belonging to the autonomous system. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Length L Type Sub-object contents Figure 7.24 The format of a sub-object.