jsharma

MPLS RSVP-TE Shared Explicit (SE) Reservation Style and Make-Before-Break (MBB)

Discussion created by jsharma Employee on Oct 5, 2016

MPLS RSVP-TE Shared Explicit (SE) Reservation Style and Make-Before-Break (MBB)

 

 

-   A typical traffic engineered MPLS tunnel is created with an initial committed bandwidth to cater to the current load of services (read number of Pseudo-Wires or actual traffic carried) and at the maximum to leave some room for near future expansions. Having said that, there can always be a need to dynamically increase the tunnel BW as more services get added on top of it.

-   Similarly, the path taken by the tunnel when it gets first established may have been the optimal path available at that point of time given the constraints, but more optimal path can later become available because of deletion and create of other tunnels in the network and if resources get freed up. Another reason can be addition of more physical links/nodes in the network, which make the current tunnel path sub-optimal.

 

In both the above scenarios, there is a need to re-route the particular tunnel in picture and while re-routing traffic engineered tunnels, because of a need to dynamically increase/decrease the tunnel’s BW or to change the tunnel path to make it optimal, minimizing the traffic disruption and minimizing adverse impact on network operations is highly desirable. Fortunately, RSVP-TE provides constructs to achieve this re-routing with minimal or no traffic hit. This concept is called "make-before-break” or in short, MBB. This adaptive and smooth rerouting requirement necessitates establishing a new LSP tunnel and transferring traffic from the old LSP tunnel onto it before tearing down the old LSP tunnel, hence the name make-before-break.

 

 

Now, if the new LSP is kept totally independent of the existing one, they are bound to compete for the resources on the network segments which are common to both of them. Depending on the free resource availability, this competition can prevent CAC (Admission control) to allow establishment of the new LSP at all. RSVP-TE SE (shared explicit) reservation style comes to your rescue here and relate the two LSPs in picture to each other to give them a sense of awareness that they are not totally independent of each other and they will have to share the resources on common segments.  To support make-before-break in a smooth fashion, it is necessary that on links that are common to the old and new LSPs, resources used by the old LSP tunnel should not be released before traffic is shifted to the new LSP tunnel, and reservations should not be counted twice because this might cause Admission Control to reject the new LSP tunnel. So, on the segments which are exclusive to the new LSP, new reservations are made, but on segments which are common between new and old LSP, only additional (in addition to what already reserved by old LSP) resources are demanded and reserved.

 

The reservation styles define how reservations for different senders within the same session are treated and how senders are selected. As RSVP protocol was initially defined for flow level reservations in INT-SERV networks and later extended for MPLS traffic engineering signalling, terminology sender and receiver corresponds to tunnel HEAD end and TAIL end respectively. To give you a background on RSVP reservation styles, RSVP supports three types of reservation styles:

 

-   Fixed Filter (FF) Style – Distinct reservations among explicit senders (can be used, and also suitable, in MPLS TE networks if no MBB like re-routing is required)

-   Shared Explicit (SE) Style – Shared reservations among explicit senders (This type of reservation reserves bandwidth for any and all senders, and propagates upstream toward all senders, automatically extending to new senders as they appear. More on this below)

-   Wildcard Filter (WF) Style – This reservation style consists of shared reservations among wildcard senders. Not appropriate for MPLS applications.

 

As you remember from my previous post on differentiation among a “Tunnel” and an “LSP” (https://community.ciena.com/thread/1171), so here we are fooling the protocol by pretending that there are 2 senders for a single tunnel by changing only the LSP id and keeping all the other tuples (Tunnel Source, Tunnel Destination, Tunnel Id and Extended Tunnel Id) in the identification objects as same for both the new and old LSP, hence forcing the resource sharing.

 

Now, how to co-ordinate traffic switch between HEAD and TAIL node, once the new LSP is UP, is left to implementations. This is a two-step process, first control plane co-ordinates the switchover actions between two PEs and secondly control plane uses appropriate data plane methods to swap traffic on old LSP to new LSP. One way for co-ordination can be based on implementing Protection State Co-ordination (PSC) FSM (https://tools.ietf.org/html/rfc6378). In current SAOS implementation, PSC is not implemented, rather “RSVP notify” is used to co-ordinate the switchover. The sequence of actions and events follows as below once the new MBB LSP is established and is ready to carry the traffic:

 

HEAD to TAIL (RSVP Notify “Switchover Request” with ACK requested Flag)

TAIL to HEAD (RSVP Notify ACK)

TAIL to HEAD ((RSVP Notify “Switchover Response” with ACK requested Flag))

HEAD to TAIL (RSVP Notify ACK)

Now, here traffic can be switched and old LSP can be torn down.

 

Additional implementation related details can be found in related SAOS Functional Specifications.

 

 

This is a very short explanation to a vast topic, but I would be happy to provide more insights if you feel so.

Outcomes