Resource Reservation Protocol for Traffic Engineering (RSVP-TE)

The Resource Reservation Protocol for Traffic Engineering (RSVP-TE) is utilized to distribute Multiprotocol Label Switching (MPLS) labels. This protocol enables steering traffic along defined paths while reserving the necessary bandwidth for them.

RSVP-TE is a signaling protocol for establishing Label Switched Paths (LSPs) with or without specific resource requirements, such as guaranteed bandwidth. RSVP-TE reserves resources along a predetermined path to ensure network performance for critical traffic. RSVP-TE is used for traffic engineering and fast reroute.

RSVP-TE consists of the following main messages:

  • Path: Sent by the headend router requesting the resources and is forwarded through the network from the headend towards the tailend router.
  • Resv: Sent by the tailend router in response to the Path message received, confirming the resource reservation and travels from the tailend towards the headend router.
  • Error Messages: PathErr (Path Error) and ResvErr (Resv Error). PathErrs flow from the error node towards the headend (in the opposite direction of Path messages), and ResvErrs flow from the error node towards the tailend (in the opposite direction of Resv messages).
  • Tear Messages: PathTear and ResvTear. These messages are used to clear the Path, or Resv states, from the network.

Each Resource Reservation Protocol message is composed of multiple objects that serve specific functions. For instance, a Path message contains objects such as SESSION and SENDER_TEMPLATE, and a Resv message includes objects such as SESSION and FILTER_SPEC.

RSVP-TE Path messages contain an explicit route object that specifies the IP addresses that the LSP must traverse to reach its destination.

All LSPs that have the same SESSION object are part of the same session. LSPs within the same session share resources, such as bandwidth (if using the Shared Explicit style, which is usually the case). Sessions generally correspond to a single tunnel created on the headend. Sessions are uniquely identified by the three values in the SESSION object, which include the destination IP address (or P2MP ID in the case of P2MP sessions), the tunnel-ID (which is just an allocated integer value), and the extended-tunnel-ID (which generally is set to the source IP address).

There are two objects required to uniquely identify an LSP within a session:

  • The SESSION object consists of the destination IP address, the tunnel ID, and the extended destination ID.
  • The LSP ID, which comes from the SENDER_TEMPLATE object for Path messages and the FILTER_SPEC object for Resv messages.
Sections in this chapter include: