Understanding Signaling in MPLS Networks

I wrote in the previous post about how the Resource Reservation Protocol with Traffic Engineering extensions (RSVP-TE), in addition to being an MPLS label distribution protocol, is also an MPLS signaling protocol. That is, an ingress LSR can use RSVP-TE to notify all LSRs along the path to the egress that it wants to set up an LSP.

As part of that process RSVP-TE can verify that the path is good and that the resources it wants to use are available before the LSP is established. It can also reserve the resources it needs – hence the name – for the LSP.

RSVP-TE uses two messages to accomplish this signaling: Path messages and Resv messages. Figure 1 shows how the signaling works. R1, the ingress LSR, wants to set up an LSP to R4, the egress (remember that LSPs are unidirectional). It sends a Path message requesting the LSP setup hop-by-hop along the path to R4, and each LSR along the path sets aside the resources requested. If the requested resources are not available at any LSR, that router sends a message back to the ingress; the ingress LSR must then either find another path or fail to establish the LSP. 

Assuming the path is good and the Path message reaches the egress LSR, that router responds by sending a Resv message back to the ingress. This message performs the label distribution function as described in the previous post.

Another way to look at all this is that RSVP-TE signaling flows downstream from the ingress to egress; label distribution flows upstream from egress to ingress.

There are quite a few resources that can be reserved by means of the Path message. The most easily understood is bandwidth: Each interface along the path can be asked to set aside some amount or percentage of its available bandwidth to be used exclusively by the signaled LSP. Other resources that can be reserved are functions, such as Fast Reroute (FRR), or capabilities such as the ability of the LSP to take resources away from another LSP, or the ability to resist having its resources taken away by another LSP.

Path and Resv messages carry information about the requested reservations, distributed labels, and so on by means of Objects within the messages.

One of the most essential RSVP-TE Objects, enabling RSVP to set up an LSP over some path other than what the local IGP determines to be the best path, is the Explicit Route Object (ERO). The ERO is a list of LSRs – specified by IP addresses – through which the path must pass.

Figure 2 shows how the ERO works. The ERO specifies that the LSP originating at LSR A must pass through LSRs B, E, G, and then terminate at H. That path is different than what the IGP considers the best (shortest) path, which is A-B-C-H.

The individual hops specified by the ERO can be either strict or loose. A strict hop means that the specified LSR must be directly connected to the previous hop. For example, in Figure 2 the hop to G is strict, so E and G must be directly connected and their connecting link must be used. A loose hop means that the path must pass through the specified LSR, but the LSR does not have to be directly connected to the last hop; any valid route between the two can be used. In Figure 2, E is a loose hop so the LSP could pass from B through D to E as shown, or it could pass from B through C to E.

As you might expect, the ingress LSR creates the ERO. But how does it know what LSRs to specify? One way is for you to configure the path manually at the ingress. You can equate that to the MPLS version of a static route. Like static routes, manually configured EROs are useful when you want explicit control; but also like static routes, they pose an administrative problem when you need to establish many paths.

A second way for the ingress LSR to determine the ERO is to dynamically calculate it. Just as OSPF and IS-IS use a Shortest Path First (SPF) algorithm to calculate a route, the ingress LSR can use a modification of the SPF algorithm called Constrained Shortest Path First (CSPF) to calculate an ERO.

In the next post we’ll look into CSPF and how it operates.

 Rocky Mountain IPv6 Summit

The Rocky Mountain IPv6 Task Force will be holding its first Rocky Mountain IPv6 Summit in Denver on April 9^th. We’re lining up a good group of speakers and a very informative agenda; if you’re in the Colorado-Wyoming-New Mexico region and want to know more about IPv6, I hope to see you there!

You can get more information, and sign up, at:

http://www.rmv6tf.org/SpringEvent.htm