174 LABEL DISTRIBUTION PROTOCOLS
The receiver, i.e., the egress LSR of the LSP, responds with an Resv message. A new object called the LABEL object, is inserted in the message which is sent back upstream
towards the sender, i.e., the ingress node, following the inverse path traversed by the Path message. Each node that receives the Resv message with a LABEL object uses that
label for outgoing traffic associated with the LSP. It allocates a new label, places it in the LABEL object of the Resv message and sends it upstream to the previous hop node.
The LSP is established when the sender receives the Resv message. As we can see, in RSVP-TE an LSP is established using the ordered LSP control scheme.
RSVP-TE enables the reservation of resources along the LSP. For example, bandwidth can be allocated to an LSP using standard RSVP reservations together with intserv service
classes. Resource reservation is optional, and LSPs can be set up without reserving any resources. Such LSPs can be used, for instance, to carry best effort traffic and implement
backup paths.
Other features of RSVP-TE include setup and hold priorities for an LSP, and dynamic reroute of an established LSP. Also, by adding a RECORD ROUTE object to the Path
message, the sender can receive information about the actual route that the LSP traverses.
7.4.1 Service Classes and Reservation Styles
There is no restriction in RSVP-TE as to which intserv service classes should be supported. RSVP-TE, however, should support the controlled-load service and the null service. The
controlled-load service class was described in the previous section. The null service class is a newer service class that was introduced in RSVP in order to support RSVP signaling in
the differentiated service diffserv architecture. In the null service, an application does not request a resource reservation on each node along the path from the sender to the receiver.
Instead, a QoS policy agent in each node provides the appropriate QoS parameters to the application, as determined by a network administrator.
In the previous section, we defined the three RSVP reservation styles: wildcard-filter WF, fixed-filter FF
, and shared explicit SE. Of these three reservation styles, the wildcard-filter is not used in RSVP-TE. The receiver node can use the FF or SE style for
an LSP, and it can chose different styles for different LSPs. When using the FF style, each LSP has its own reservation on each node along the
path, and each node allocates a unique label for each sender. For instance, if an explicit route is set up using the FF style, then each node will reserve resources to the LSP
and a unique label that the previous hop node has to use when transmitting packets in this specific LSP. Consider the case where an LSP is set up using the next hop
information from the routing table. In this case, if there are multiple senders, a multipoint- to-point inverse tree will be formed. Each sender has its own path to the receiver, which
is independent of the paths from the other receivers. A node in this inverse tree that handles several such paths reserves separate resources to each path and allocates a different
label for each path to be used by the previous hop node. As a result, this inverse tree consists of multiple point-to-point independent LSPs. This also means that the same
previous hop node can use different labels to transmit traffic to the same receiver from different senders.
The SE style allows a receiver to explicitly specify the senders to be included in a reservation. There is a single reservation on each node for all senders whose path to the
receiver pass through that node. Different labels are assigned to different senders, thereby creating separate LSPs.
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.
