MPLS TE: RSVP Resource Reservation Protocol
Today I am going to talk about the other MPLS traffic Engineering protocol named as RSVP or stands for Resource Reservation Protocol. In my earlier article I talked about the CR-LDP protocol and i promised to discuss about the RSVP protocol. Lets talk about the RSVP protocol in details to understand.
Resource Reservation Protocol - Traffic Engineering RSVP is a separate protocol at the IP level. It uses IP datagrams (or UDP at the margins of the network) to communicate between LSR peers. It does not require the maintenance of TCP sessions, but as a consequence of this it must handle the loss of control messages
 |
| Fig 1.1- MPLS RSVP |
The Ingress LSR, LSR A, determines that it needs to set up a new LSP to LSR C. The traffic parameters required for the session or administrative policies for the network enable LSR A to determine that the route for the new LSP should go through LSR B, which might not be the same as the hop-by-hop route to LSR C. LSR A builds a Path message with an explicit route of (B,C) and details of the traffic parameters requested for the new route. LSR A then forwards the Path to LSR B as an IP datagram.
LSR B receives the Path request, determines that it is not the egress for this LSP, and forwards the request along the route specified in the request. It modifies the explicit route in the Path message and passes the message to LSR C.
LSR C determines that it is the egress for this new LSP, determines from the requested traffic parameters what bandwidth it needs to reserve and allocates the resources required. It selects a label for the new LSP and distributes the label to LSR B in a Resv message, which also contains actual details of the reservation required for the LSP.
LSR B receives the Resv message and matches it to the original request using the LSP ID contained in both the Path and Resv messages. It determines what resources to reserve from the details in the Resv message, allocates a label for the LSP, sets up the forwarding table, and passes the new label to LSR A in a Resv message.
The processing at LSR A is similar, but it does not have to allocate a new label and forward this to an upstream LSR because it is the ingress LSR for the new LSP.
The main differences between CR-LDP and RSVP is the reliability of the underlying transport protocol, whether the resource reservations are done in the forward or reverse direction. From these points come many of the other functional differences.
The table below summarizes the main technical similarities and differences between CR-LDP and RSVP for LSP Tunnels. The sections that follow explain in greater detail the implications of these technical differences between the protocols.
CR-LDP inherits any safety carried out to TCP. RSVP cannot use IPSEC however has its own authentication Multicast support is presently not defined for any of the existing label distribution protocols.
The maximum obvious distinction among CR-LDP and RSVP is the selection of delivery protocol used to distribute the label requests. RSVP uses connectionless raw IP (or UDP packets on the margins of the community). CR-LDP uses UDP to discover MPLS friends, and makes use of connection-orientated TCP classes to distribute label requests.
Many working systems are packaged with full IP stacks including UDP and TCP, but sometimes TCP isn't to be had. On some platforms get entry to raw IP is limited. a few current ATM switches might not already comprise an IP stack in any respect and one must be added to assist both CR-LDP or RSVP. the provision and accessibility of the transport protocols might also dictate which label distribution protocol is used, but is not likely to be a major factor in the preference made through most MPLS equipment providers.
RSVP calls for that each one acquired IP packets sporting RSVP messages are added to the RSVP protocol code without reference to the real destination IP address in the packet. this feature might also require a minor modification to the IP implementation.
