RSVP is a signaling protocol for TE tunnels to ensure that link admissions happen at the interfaces of the Label Switched Routers (LSRs) that the TE tunnel crosses and for propagation of a label hop by hop that the traffic flowing on the TE tunnel can use.
RSVP uses PATH and RESV messages to signal a path. The TE head end router sends the PATH messages to the tail end router, whereas the RESV messages take the exact but opposite path back to the head end router. The head end router of a TE tunnel computes the best path that the TE tunnel should take from the TE database, considering bandwidth and other constraints.
The is defined by an explicit path option configured by the user on the tunnel interface. The head end router knows the exact path that the TE tunnel should take. Each hop (LSR) that the TE tunnel should cross is put into an Explicit Route object (ERO), which is basically an ordered list of interface IP addresses, with one IP address per LSR. The TE extensions for RSVP are detailed in RFC 3209.
Explicit Route object (ERO)
The Explicit Route object (ERO) details the hops that the RSVP PATH message must follow to signal the TE tunnel. The series of hops or path is the result of the path calculation on the head end router. At each hop, this PATH message temporarily reserves the bandwidth and requests a label.
Eventually, the PATH message gets to the tail end of the LSP, which returns a RESV message to the head end of the LSP. This RESV message then returns a label that the MPLS data plane can use to forward the packets of this MPLS TE tunnel along the LSP. The RESV message also tells the intermediate LSR to reserve the resources for the links that the TE LSP uses.
RSVP Path message
The PATH message is sent from the head end router to the next-hop router. This next-hop router removes his own IP address from the ERO, sees what the next IP address is, and sends the PATH message to that next hop. This continues until the tail end router of the TE tunnel receives the PATH message.
Upon receipt of the PATH message, the tail end router returns a RESV (or reservation) message along the same path that the PATH message took, but in the opposite direction. Only when the head end receives the RESV message without an RSVP error message is the path set up or signaled and is the TE tunnel up.
RSVP and Labels
RSVP signals the path for the TE tunnel, but it is also its task to carry the MPLS label so that the packets can be label-switched along the path of the TE tunnel. Look at the figure below to see the RSVP messages sent for the TE tunnel signaling.
The PATH messages carry a Label Request object. When the tail end router receives this Label Request object, it assigns a label to this TE tunnel LSP and advertises it to the upstream router (the penultimate hop router) in a Label object in the RESV message. This label is the incoming label in the LFIB of the tail end router.
The upstream router receives the label from the tail end router and puts this label as the outgoing label in the LFIB for this TE tunnel LSP. The router assigns a label from the global label table to this TE tunnel LSP and sends it in a Label object in the RESV message to its upstream router. This label becomes the incoming label in the LFIB for this TE tunnel LSP. It continues like this until the RESV message reaches the head end router of the TE tunnel LSP.
Another RSVP object is the Record Route object (RRO). PATH and RESV messages carry this object, which stores the IP addresses of the routers that the TE tunnel traversed. The path in the RSVP Path Info (Explicit Route) is usually the same as the path in the RRO, although it can differ. One example of it differing is when the TE LSP is rerouted temporarily onto a backup tunnel.
TE tunnel bandwidth requirement
The bandwidth requirement for the TE tunnel is the most important TE tunnel attribute. It is carried in the SENDER_TSPEC as average rate. Note that the value of the average rate is expressed in bytes per second.
The Session object holds the IPv4 address of the egress router, the tunnel ID, and the extended tunnel ID. Look at the figure below, which shows the format of the Session object.
The Session attribute holds the tunnel setup and holding priority and some flags. These flags can indicate that local protection is desired, for example. In addition to that, the Session attribute in an extended format can hold the resource affinity bits.
So far, this article has covered only PATH and RESV messages. However, TE can also use other RSVP messages. TE primarily uses these other messages to signal that a problem has occurred.
PathTear: A PathTear message is much like a PATH message, except it is sent when the head end router wants to signal that the TE LSP should be torn down (for instance, after an admin shut on the tunnel interface).
ResvTear: A ResvTear message is much like a RESV message, except it is sent by the tail end router in a response to the receipt of an PathTear message.
PathErr: A PathErr message is actually a message sent in the direction toward the head end router. The most common reason for this error message to be sent is that the link that was in use by a TE LSP has gone down. It could also be that an LSR received a PATH message with bogus information.
ResvErr: A ResvErr message is sent in the direction of the tail end router.