RSVP-TE (Resource Reservation Protocol-Traffic Engineering) is the enhanced RSVP for MPLS (Multi Protocol Label Switching). RSVP-TE is not a real routing protocol, but it works with routing protocols. Here, we will focus on the theorical part of the protocol. But you can also check and learn RSVP-TE Configuration lesson.
For RSVP-TE, bidirectional flow is required. To provide this, there must be two RSVP sessions. Because RSVP-TE is unidirectional.
RSVP-TE brings some benefits to MPLS. These benefits are:
Table of Contents
As we talked about before in LDP lesson, there are also some main characteristics for RSVP-TE. Some of these characteristics are different than LDP. What are these characteristics? Let’s check:
Downstream on demand : LSPs signalled when requested. (This was unsolicited downstream in LDP, which send labels without any requests).
Ordered control : Label distribution process follows a hierarchical order (Same as LDP).
Conservative label retention : Labels are cleared if not needed. ( This was liberal label retention in LDP, which stores all the labels).
I am highlighting these characteristic in this article and in the past two articles, because I sometimes confused about the name od these characteristic. And you can be like me ;) So I tought that to make more emphasize, will help you.
RSVP-TE based LSP can have multiple associated LSP-Paths. One of these LSP-Paths must be Primary and other can be Secondary up to 7. One LSP-Path is active at any time.
To define an LSP there are some needs. These are minimum:
In RSVP-TE, PATH and RESV Messages are used to signal LSPs. Along the LSP, session states are maintained on all routers.
PATH Messages are used for label request through downstream direction.
RESV Messages are used to send labels through upstream direction.
For Path Definition, hops must be defined as “strict” or “loose”. Strict means that “exact hop”. In other words, “go through this hop”. It is directly connected. But Loose means that, path goes according to the routing protocol. It does not need to be directly connected.
If there is no hops defined in RSVP-TE, IGP forwarding table is used.
Paths are passive definitions. To become active it must be configured under an LSP.
When an LSP enable, PATH Messages are sent downstream, as an attemp to signal the LSP.
After receiving the PATH Message, egress router sends RESV Message to the upstream router. And this continues till it reaches to the ingress. This RESV Message contains Label in it. All routers throuhg the opposite direction of the LSP, send a label with RESV Message to its upstream router. This label says, “come to me with this label”.
Here, as we discussed, because of Downstream on Demand, the egress router only send RESV Message to the requested upstream peer. Not all of them like LDP.
Other RSVP messages :
If the LSP is shut downed administratively, PATH Tear Message is sent to clear the RSVP session.
RESV Tear Message is used to inform Ingress router about any failure to clear the RSVP session. Think about, if failure between two link, the last router before the failure link sends RESV Tear Message to the Ingress router. This prevent traffic being “black holed”.
PATH Error Message, send through upstream if a router can not forward the PATH message any further, because of destination unreachable or insufficient resource etc. When Ingress router get this message, it sends PATH Tear Message and clear RSVP session.
RESV Error Message is sent when a neighbour can not forward RESV Mssage anymore. Reservation failures and reservation status change can be the cause.
RSVP sessions must be constantly refreshed. PATH and RESV messages are exchanged between all RSVP neighbors at a periodic interval. If not, sessions time out. If session times out on a router due to missing PATH and RESV messages, router clears RSVP session. It sends PATH Tear Message to the downstream router and RESV Tear Message to the upstream router.
Refresh-time can be confgured and aplied to all RSVP sessions. Reducing this time to a low value can cause CPU overload. This must be balanced. The default refresh time is 30 seconds.
Refreshing all the RSVP sessions must be avoided. There is also a randomization mechanism for this.