RSVP-TE requests resources for simplex (unidirectional) flows. Therefore, RSVP-TE treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. Duplex flows require two LSPs, to carry traffic in each direction.
RSVP-TE is a signaling protocol, not a routing protocol. RSVP-TE operates with unicast and multicast routing protocols. Routing protocols determine where packets are forwarded. RSVP-TE consults local routing tables to relay RSVP-TE messages.
RSVP-TE uses two message types to set up LSPs, PATH and RESV. Figure: Establishing LSPs depicts the process to establish an LSP.
The sender (the ingress LER (iLER)) sends PATH messages toward the receiver, (the egress LER (eLER)) to indicate the forwarding equivalence class (FEC) for which label bindings are desired. PATH messages are used to signal and request the label bindings required to establish the LSP from ingress to egress. Each router along the path observes the traffic type.
PATH messages facilitate the routers along the path to make the necessary bandwidth reservations and distribute the label binding to the router upstream.
The eLER sends label binding information in the RESV messages in response to PATH messages received.
The LSP is considered operational when the iLER receives the label binding information.
Figure: LSP Using RSVP-TE Path Setup displays an example of an LSP path set up using RSVP-TE. The ingress label edge router (iLER 1) transmits an RSVP-TE PATH message (path: 30.30.30.1) downstream to the egress label edge router (eLER 4). The PATH message contains a label request object that requests intermediate LSRs and the eLER to provide a label binding for this path.
In addition to the label request object, an RSVP-TE PATH message can also contain a number of optional objects:
explicit route object (ERO) — forces the RSVP-TE PATH message to follow the path specified by the ERO (independent of the IGP shortest path)
record route object (RRO) — allows the iLER to receive a listing of the LSRs that the LSP tunnel actually traverses
session attribute object — controls the path setup priority, holding priority, and local rerouting features
Upon receiving a PATH message containing a label request object, the eLER transmits an RESV message that contains a label object. The label object contains the label binding that the downstream LSR communicates to its upstream neighbor. The RESV message is sent upstream towards the iLER, in a direction opposite to that followed by the PATH message. Each LSR that processes the RESV message carrying a label object uses the received label for outgoing traffic associated with the specific LSP. When the RESV message arrives at the ingress LSR, the LSP is established.