Self-Driving MPLS Rings

Self-Driving MPLS Rings are here! Want to see them in action? Talk to us at the MPLS World Congress 2017.

Brief overview of what we are planning to demonstrate there

Rings are a very common topology in access and aggregation networks. It is the most efficient way of connecting N number of nodes with minimum number of interconnects to get resiliency. However, MPLS resiliency in a ring is far from efficient. Most important, it is very complex to operate MPLS in a ring for following reasons. First, Ring needs N squared LSPs to connect N nodes. Second, fast reroute is not very efficient and it mostly uses twice the bandwidth on some links. Third, Packets loops are very prevalent specially in LDP networks. Finally, the configuration is too intensive for RSVP-TE LSPs.​

Self-Driving MPLS Rings as you would expect address most of the problems that exist today of running MPLS in Rings. The main highlights of Self-Driving MPLS Rings are –

(1) Self-discover the Ring

(2) Self-signal RSVP-TE LSPs in the Ring

(3) Improve MPLS resiliency

(4) Self-manage RSVP-TE LSP bandwidth and

(5) Self-establish LSP hierarchy in the network ​​

Self-Discover Ring

The goal here is to provision rings with the absolute minimum configuration. The ring is auto-discovered using IGP protocol such as OSPF or ISIS. The ring links are auto-discovered and auto-bundled. Each ring node knows its clockwise (CW) and anti-clockwise (AC) neighbor. Node insertion and removal in a Ring is handled seamlessly, avoiding configuration changes on the neighbor nodes.

Self-Signal LSPs in the Ring

After the ring discovery, each ring node acting as egress signals a clockwise (CW) and anti-clockwise (AC) ring LSP to itself in CW and AC direction respectively. Each transit node that receives the path message or label mapping message signals this LSP further in same direction by using the ring topology information from IGP discovery. In addition, it also adds a transit and ingress route for this LSP. In other words, each LSP is a multi-point to point LSP. So this is very different from regular P2P RSVP-TE LSPs. The multi-point nature of the LSP drastically reduces the number of LSPs from N square to 2N, reducing the number of hardware states. Once signaling is complete, every node in a ring should have two counter rotating LSPs in CW and AC direction to reach every other node on the ring. For instance, following figure depicts a ring of 10 nodes. R1 signals two LSPs to itself to receive traffic from every other node in the ring in CW and AC direction.

Figure 1

Improve MPLS resiliency

Since every node in a ring establishes two counter-rotating LSP in CW and AC direction to itself, there are two paths from every node to every other node in the ring. Thus, the protection happens naturally on a ring - no need of special bypass LSPs, various flavors of loop free alternates (LFA) etc. This further reduces the number of LSPs signaled in a Ring. For example, consider a ring in Figure 2.

Figure 2

Suppose N7 is sending traffic to N1 on purple CW LSP. If the link between N8 and N9 fails, N8 switches that traffic on an AC LSP to N1 within sub-50 milliseconds.

Self-Manage Bandwidth

​

Figure 3 explains how Ring LSPs self-manage bandwidth. Ring LSP colored purple starts with zero bandwidth. As and when services are provisioned over the LSP, their bandwidths are added to the LSP from where they enter the ring to the egress node i.e. the destination node.

Figure 3

When a 2G pseudowire is provisioned on R5, the purple LSP attempts to increase the bandwidth from node R5 to R1. If successful, the service is accepted. Similarly, for a 1G PW from node R6 to R1, the purple LSP attempts to increase the bandwidth from R6 to R1. Thus, the resulting signaled bandwidth in the CW direction for this LSP is zero from R1 to R5, 2G from R5 to R6, and 3G from R6 to R1.

Self-Establish LSP hierarchy

When does the ring decide to do self-hierarchy of LSPs? Whenever services on one of the node needs it. For instance, when services on N6 need to reach R12, N6 dynamically establishes a tLDP session to ring 17 master node N1 and N10. Further, suppose it only learns IPv4 and IPv6 FECs only over this tldp sessions. In order to reach N12, N6 uses top label as RMR LSP label to N1 and inner label as N12's FEC label received over tLDP session to N1.

Figure 4

Thus, Self-Driving MPLS rings make it very easy for the service providers to extend MPLS to access and aggregation networks. Hence, these networks can get all the traditional benefits of MPLS, which they lack today, along with ease of not only configuration but also operation.

Do you have questions? Write a comment. Want to see the live demonstration? Come to Juniper exhibition booth at the MPLS World Congress in Paris!

We're working on the config, but the goal is to make it very simple, with reasonable defaults for all the params you don't specify. You're right, it doesn't need a PCEP controller; however, the PCEP (or similar) controller can help set the load balancing weights -- in the simplest case, there are two ways to go from R6 to R1 in Figure 1, so should the traffic be split 50-50, or some other ratio? The Controller, with its global view of traffic patterns on the ring, is in a good position to decide.

Love to break things apart since I can remember. Had a fantastic hands-on experimentation time during my MSc in Telecommunications and Electrical Engineering (MSEE); moved to the European space industry and discovered critical systems and operations for ground segment communications. Became professional services consulting engineer supporting carriers in their designs and providing expert support.
Currently living the Juniper lifestyle to bring ideas to practice and taking difficult customer questions as interesting challenges. Enjoy jogging and playing the guitar.

I am currently a member of the EMEA Professional Services team and have been working for the (inter)networking industry for several years. I love this job because it offers us the tremendous challenge to be able to learn something new every day: from the technology itself, from customers, from peers, from other colleagues, from many mistakes and lessons learned... This is the ongoing challenge with an ongoing learning opportunity.
Prior to joining Juniper in June 2005, I worked in various technical positions for system integrators and service providers, so I have also been on the 'other side'.
Apart from all this, I am father of 2 and live in the outskirts of Madrid. I like listening to world, jazz and celtic music, and I pretend to be an amateur photographer and MTBiker, whenever I have some spare time.