RSVP-TE Protocol Deep Dive: Part 1

A while back, I wrote few articles on MPLS-TE primarily focused from a design perspective but I didn’t really covered much from a protocol perspective.

http://packetpushers.net/mpls-te-design-part-1/
http://packetpushers.net/mpls-te-design-part-2/
http://packetpushers.net/mpls-te-design-part-3/

So it’s time to fix that and we will try to take a deeper look into the RSVP-TE from a protocol perspective and my assumption here is that the reader already has some familiarity with the RSVP-TE Protocol.

It’s possible that you may think why the heck I am writing about RSVP-TE  when we already have SR-TE, and the reason is that RSVP-TE is already deployed in networks and is probably going to stay with us for sometime. The way we need to look at it is that both RSVP-TE and SR-TE are tools and it’s our job to pick the right tool for the right job.

RSVP-TE:

RSVP was originally designed to serve IntServ QOS model. It was used to signal traffic characteristics and requirements of the traffic flows and establish sessions. Later it was extended to signal MPLS LSPs. As you may already know that RSVP-TE is used for Traffic Engineering (Strategic/Tactical) and fast-reroute. Similar to LDP, RSVP-TE provides transport LSP to carry IP. Other mechanisms for establishing transport LSPs are IGP in the case of SR and BGP-LU. RSVP uses Downstream on Demand (DoD) with ordered control and conservative retention label allocation method. If you want to dig deeper on various Label allocation modes, take a peek here: http://packetpushers.net/back-basics-label-distribution-assignment-modes/

RSVP-TE  rides over IP (Protocol 46) and consists of following main messages:

• PATH: Sent by the Headend router requesting the resources and is forwarded through the network from Headend towards the Tail end router.
• RESV: Sent by the Tail end router in response to the PATH message received confirming the resource reservation and travels from Tail end towards the Headend router.
• Error Messages: PathErr (PATH Error) and ResvErr (RESV Error), These messages are used in the event of unavailability of the requested resource.
• Tear Messages:  PathTear and ResvTear, These messages are used to clear the PATH or RESV states from the network.

Each of these RSVP messages is actually made up of various objects which serves a specific function. For instance PATH message contains objects like SESSION and SENDER_TEMPLATE objects and RESV message contains FILTER_SPEC. We will dig deeper into a few of these messages and the objects they contain later.

LSP,LSP-PATH,RSVP-Session, Label, Path Definition:

Before we go any deeper lets clarify a few terms first.

• What is an LSP?: An LSP is a logical MPLS Tunnel. The source of the logical MPLS tunnel is the headend Router and destination is Tail end router. In a network one can have multiple LSPs and the way one can identify an LSP uniquely is by Source IP, Destination IP and Tunnel-ID which are encoded in the SESSION object of the PATH message during the setup of an LSP path. An LSP can have multiple LSP-Paths. For instance an Active and Standby LSP-Paths. In the below fig.1, The Blue line represents a Logical MPLS tunnel.
• What is an LSP-Path: An LSP-Path is the actual MPLS connection from the Headend to the Tail end Router. It is identified by the LSP-ID field encoded in the SENDER_TEMPLATE object and is composed of series of RSVP sessions on each hop along the path. It is an end-to-end representation of the RSVP sessions along each hop. In the below fig. 1, Green and Orange are two LSP-PATHS with Unique LSP-IDs and they both are part of the same logical LSP.
• What is an RSVP Session: An RSVP session is an MPLS label cross-connect. In each MPLS router, one RSVP session associates one ingress label and one egress label of the same LSP-Path. In the below fig. 1, Purple Lines indicate the RSVP session between each router. An RSVP session for an LSP contains:
  • A Pair of Labels: An ingress label distributed to the upstream router and an egress label received from the downstream router. Nothing new here.
  • A Pair of State Blocks: The Path State Block (PSB) maintains the relationship with the upstream router by constantly receiving PATH messages refreshing the session. The RESV State Block (RSB) maintains a relationship with the downstream router by constantly receiving reservation messages refreshing the session.
  • A Pair of Messages:  The Original PATH and RESV messages used to establish the RSVP sessions are stored in the router to validate the subsequent refreshing of PATH and RESV messages.
• What is a MPLS Label:  Well, you already know this :). If not, then this article isn’t going to make any sense anyway, so stop wasting your time.
• What is a Path: The path is a logical entity containing a list of IP hops. When an LSP is associated with a path, the path regulates the LSP as to which route it must take. A path can be associated with any LSPs to control their routes.

fig.1
RSVP-TE signaled LSP-Paths are explicit route LSP paths. It builds an explicit routing object (ERO) that contains all the interface IP addresses that the LSP-Path must pass through to reach its destination. When signaling the LSP-Path, RSVP-TE  PATH message follows the route specified by the ERO. An ERO can be strictly or Loose defined.

How do I Identify an Unique  LSP-Path in the Network:

In the RSVP domain, an LSP is identified by the tunnel-id (which is usually a number) and Extend-tunnel-id (which is usually the IP of Headend router) fields which are present in the SESSION Object. All LSPs that belong to the same LSP have the same SESSION object, therefore they have the same tunnel-id/extended-tunnel-id.

There are two objects required to uniquely identify an LSP-PATH within an LSP:

• Tunnel-ID: This is shared by all LSP-Paths belonging to the same LSP. Its part of SESSION Object.
• LSP-ID: Each individual LSP-Path has its own LSP-ID. The LSP-ID is located in the SENDER_TEMPLATE Object.

If the LSP-PATH uses MPLS FRR (one-to-one/Path Protection) backup, two sets of RSVP sessions belong to the same LSP-Path. One set belongs to the original protects LSP path and the other belongs to the Protection LSP. Both LSP-Paths will have the same Tunnel-ID but LSP-ID will be different in the SESSION_ATTRIBUTE object.

Below is an example of  Active and Standby LSP-Paths with the same SESSION Object but different LSP-ID’s. I also added captures in case you don’t believe me.

fig.2

Packet Capture:

Setting Up an LSP- Path:

So as you already know that before signaling the LSP-PATH, the Head End router runs a Constrained SPF and assuming it was able to find a PATH, it will come with a list IP Addresses (ERO’s) through which the path will be signaled. Then it sends a PATH message towards the Tail end router asking to reserve the resources and ask for the Labels. This PATH message gets propagated down the network all the way to the Tail end router.  All the intermediate hops looks at that PATH message and reserves the resource requested (if available) and then forwards it downstream towards the Tail end router. The RSVP PATH message has the Source IP of the Headend and Destination IP of the Tail-end router.

Hmm… Did I just contradicted myself? I just said that this PATH message is processed by all the intermediate hops, but I also said the RSVP PATH message has the Source and Destination of the Headend and Tail end router respectively. Well, turns out to be that both statements are true and the RSVP PATH message has Router Alert (RA) bit set which allow the intermediate hops to intercept/process and send a new PATH message towards the Tail end Router.

When the Tail End router receives the PATH message, it allocates a label and distributes it to the upstream router via RESV message. Since RSVP-TE is unidirectional, the Tail end router doesn’t need to reserve any resources. Each LSR along the path does not start resource reservation and label distribution toward the HE router until it receives a label from the downstream router (remember its Ordered Control). This process is performed by the LSR in every hop of the LSP toward the HE router. After the entire process finishes, the HE router has an  egress label for this LSP-Path. Each LSR router along the route has one ingress label and one egress label in the RSVP session. The Tail router has one ingress label. All required resources (for example, bandwidth) are reserved along the path.

Below is a sample of PATH message being sent from HE (R1) to Tail end (R5) Router. As you can see that the SRC/DST IP of the PATH message is of Head End and Tail end Router. PATH message has RA bit set which allows the intermediate hops to intercept and generate a new PATH message. Few things worth noticing is that how HOP field changes at every hop, indicating the outgoing interface IP, ERO List getting shrunk as it gets closer to the tail-end router and increasing RRO list capturing the outgoing interface IP address.

fig. 3
After receiving the PATH message, Tail-end Router will signal RESV message back to the Headend including the label assigned.

fig. 4

The RROs in the RESV messages contain both the IPv4 sub-object and the LABEL sub-object. The IPv4 sub object contains the router’s local egress interface IP address for the message. The LABEL sub-object also contains the label generated and distributed by the local router. As we had earlier mentioned RRO information from the RESV messages is used to calculate MPLS FRR paths.

Maintaining the LSP Path

RSVP-TE is a Soft state protocol, meaning it needs periodical exchanging of signaling messages between two peering routers to keep the state up. If the exchange of signaling messages stops, then RSVP adjacency times out after a timer (Refresh timer) expires. Which means, once the LSP-PATH has been established, it must be constantly refreshed to keep the operational state up and is achieved by sending a constant PATH and RESV messages. This refresh needs to happen at every hop between the adjacent routers along the LSP-Path. PATH messages are sent downstream and RESV messages are sent in the upstream direction. When the PATH messages are received, PSB is refreshed and RSB is refreshed when RESV messages are received.

One thing to note is that the content of these PATH and RESV messages (which are sent to refresh the RSVP sessions) has the same content as the original PATH and RESV messages.

Note: In the case of RSVP session refreshes, it doesn’t work in a Hello-ACK handshake manner, meaning  a RESV message isn’t generated in response to PATH message or vice versa. RSVP session will time out, If either side fails to receive more than three PATH or RESV message consecutively.

RSVP Refresh Mechanism: R,L and K Values

So in the case of routing protocols (e.g. IS-IS/OSPF/BGP) or signaling protocols (e.g. LDP), Keep-Alive or Hello messages constitute a very small portion of  the total traffic as you have a small number of adjacent neighbors, hence the number of adjacencies which needs to be maintained is limited. But in the case of RSVP-TE, you could have tens of thousands of RSVP sessions which need to be maintained at midpoint (an order of 10k-40K is normal and people have talked about scaling up to 200K). Which means the amount of an RSVP session refresh traffic (PATH and RESV messages for every RSVP session) can be significant. If all the RSVP session at a midpoint router requires refresh at the same time, then it can result into a decent volume of traffic and may end up in competing with customer traffic. If for some reason these refresh messages get lost, the RSVP session may time out, and the LSP-Path may be torn down. Hence, it’s important to make sure that not all RSVP sessions at midpoint are refreshed during the same short time period (a burst of traffic) — which is commonly known as refresh synchronization and it must be avoided. RSVP-TE uses the following timers to control the refresh interval to prevent refresh synchronization:

• R (Refresh Timer):   This is time the Router waits before sending a RSVP refresh message. This is passed to the adjacent router in the TIME_VALUE object in the PATH and RESV messages.
• L (Lifetime Timer):  The lifetime of the RSVP sessions states. When the L timer expires, the related PATH or RESV state expires and the RSVP session is cleared.
• K (Keep Alive Multiplexer):   The number of consecutive refresh messages that may be missed before the RSVP session times out.

If a router cannot receive the next refresh within K*R seconds, the state expires. If a PATH refresh message is missing from an upstream router then it causes the PATH state of the RSVP session to time out which results in sending a PathTear message towards the downstream routers. If a RESV message is missing from a downstream router then it causes the ResvTear message to be sent out in the upstream direction.

Tearing Down

When an LSP-Path is no longer needed, the Headend Router sends a PATH Tear message downstream to clear the RSVP session along the LSP to release the resource.

Next we will look at RSVP Hello and Refresh-reduction extensions in part 2…