Download (direct link):
To set up an LSP, the ingress node sends a Path message with a LABEL REQUEST object. This is a new object and it indicates that a label binding for the path is requested. If an explicit route is requested, then the EXPLICIT ROUTE object will be inserted in the Path message. If the LSP is set up using the next hop information in the routing table, then the EXPLICIT ROUTE object is not used.
The Path message is forwarded to the next hop indicated in the routing table for the particular IP destination address of the receiver, or the next hop indicated in the EXPLICIT ROUTE object. A node incapable of accepting the new requested LSP sends back a PathErr message.
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 RECORDROUTE 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
7.4.2 The RSVP-TE New Objects
The following five new objects have been introduced to support the functionality of RSVP-TE:
• SES SIONATTRIB UTE
Also, new Ñ-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