MPLS: Traffic Engineering with RSVP-TE

Luis Bueno – System Test Analyst and Tatiane Figueiredo – Training Instructor

MPLS... four letters that are increasingly present in the world of ISPs whose implementation aims at greater flexibility in connectivity, with maximum security for end customers. With this set of protocols it is possible to guarantee high performance for different traffic and applications, in addition to offering services in an uninterrupted way and with scalability.

There are many discussions about the MPLS – Multiprotocol Label Switching theme, and one of them is about its use and its benefits, and thinking about it, in another article on our blog, you can observe these points, check it out: 5 reasons to use MPLS your provider.

But, back to the subject, MPLS is defined as a technology and not a protocol, which aims to promote greater flexibility and added value to the simplest operating infrastructures. The services offered by a transport network based on MPLS allow connecting with simplicity, reliability and security several geographically distant locations.

MPLS was developed by the IETF and defined by RFC 3031, which provides the combination of the routing process with switching over layer 2. According to the OSI reference model – Open Systems Interconnection and the IP over MPLS architecture, it aims to offer greater traffic management and engineering, scalability, better performance and administration, in addition to reduced complexity compared to layer 2 technologies.

The purpose of an MPLS network is not to connect directly to end systems, but to a transit network, transporting packets between entry and exit points.

Within the MPLS infrastructure, for the generation of the LSP – Label Switch Path we have two very important protocols, the first, the LDP – Label Distribution Protocol which proposes the simplicity of network configuration and the RSVP – Resource reSerVation Protocol which aims to analyze the width bandwidth and rapid convergence in the event of failure.

Here, in this article, we will address the issue of traffic engineering or traffic engineering (TE) in MPLS, known as MPLS-TE and defined through RFC 2702. The objective is to demonstrate its operation based on a better use of routing, avoiding the overload of links and better distribution of traffic on the network.

MPLS-TE has benefits for all applications and services, including those that require bandwidth, less delay or jitter variations. Its application does not reduce the problems of lack of resources on the network, but improves the mapping of your resources. We also highlight:

  • Ability to establish an LSP different from the path defined by the routing protocol;
  • Resources within the network can be reserved and changed dynamically, as the LSPs are established or when there are changes in their flows;
  • Rapid recovery mechanism in case of failure with the indication of backup LSPs.

The RSVP with the TE extension is defined through RFC 3209, which incorporates the permission to establish LSPs in MPLS to the protocol, in addition to performing the signaling, this protocol found a better application in the MPLS-TE. Some advantages of its use are:

  • Establishment of LSP tunnels with or without considering QoS parameters – Quality of Service;
  • Dynamic re-routing of the established LSP tunnel;
  • Real monitoring of the route corresponding to the LSP tunnel;
  • Identification and diagnosis of LSP tunnels;
  • Performing preemption in LSP tunnels established under policy control.

After this review of concepts, let's go to the practical questions?


Why Traffic Engineering?

One of the characteristics of routing protocols is that they use links with higher bandwidth, which causes traffic or greater use of these links, leaving others idle.

Using an IGP – Interior Gateway Protocol like OSPF, the path chosen between two points will always be the path with the lowest cost. In the scenario below, considering that all links have the same cost, packages originating from R1 and destination R5 will always take the shortest path 1 (R1-R2-R5).

Even if path 1 is saturated, it will be used for all traffic between R1 and R5, and path 2 will be underused. If the costs of the links are changed to force traffic to path 2, all traffic will automatically pass through this path, leaving it saturated and path 1 underused. The problem simply changes places, but it is not solved.

One of the advantages of using RSVP-TE for this scenario is the distribution of traffic between the available links, ensuring that the load is divided. Here, it is possible to create different tunnels that use different paths and associate them with separate VPNs – Virtual Private Network for each client.

Depending on the amount of bandwidth used or traffic characteristics, certain customers can be configured to use one tunnel, while others can be configured to use another. This action optimizes the network and avoids the need to expand the ISP's infrastructure, either by purchasing more equipment or by contracting an increase in the bandwidth.

RSVP-TE also allows you to associate different paths with a tunnel. If the primary path fails, others can be used, thus providing redundancy.


What are the criteria for establishing tunnels with RSVP-TE?

There are two ways to establish the path used by a tunnel by RSVP-TE: Explicit-Path or Affinity attributes. Shall we meet them?

Explicit-Path: As the name says, it is necessary to define the tunnel path explicitly, that is, clear, evident, ordered, literal, there are several synonyms involved. In fact, we will inform the addresses of the routers and interfaces by which this path will be established. If changes are made to the topology, it will be necessary to reconfigure the tunnel paths, generating greater operational work.

The parameters available in the Explict-Path definition are: strict routes with the declaration of the path to be followed, configuring hop-by-hop, making the LSP fixed and not obeying the path proposed by the routing. The loose routes option, where it is not necessary to determine all hops from source to destination, but only a few to form the path in conjunction with the routing table.

Affinity: These are attributes defined in the form of values ​​configured in the interfaces associated with the RSVP-TE. These values ​​are expressed in hexadecimal (0x0 – 0xffffffff). The paths used by the tunnels can be configured to be established by links that have a specific affinity value or that avoid links with certain affinity values. This way, it is not necessary to manually configure the addresses by which the tunnels must be formed, making the configuration process less laborious.

Three parameters can be used to define a path using the affinity attributes: include-any, include-all and exclude-any.

For the include-any parameter, it is necessary to match at least one of the bits. For example, if the include-any value for the Path attribute is 0x00000002 and a link attribute has a value of 0x00000006, the match will occur in the second bit, as highlighted in red, thus allowing this link to be used in this path definition.

If the parameter chosen is the include-all, it is necessary to match all the bits in the path. For a path attribute set to 0x00000005 and an attribute link with a value of 0x00000006, we will observe that there will not be a match in all bits, only the third bit will have the same value, however, the link will not be used for this path.

Exclude-any will exclude the selection of the link that matches any of the bits, behaving in an inverse way to include-any.

The attributes are defined by the network administrator himself, according to the characteristics of his links. Below, we use the “High Capacity”, “Low Capacity” and “High Latency” criteria as their respective values to classify the links that we will use in the examples.


What are the settings involved for using RSVP-TE in DmOS?

The topology that we will use as a reference for the settings and the classification of each link can be seen below.

Initially, the VLANs involved in the network infrastructure must be configured, with their respective IP addresses on the l3 (layer 3) interfaces and the creation of a loopback interface.

On all switches, within the OSPF configuration, associate the MPLS-TE option to the loopback interface, in addition to the traditional configuration and good practices involved.

The l3 (layer 3) interfaces must be associated with the MPLS RSVP and have their affinity attributes informed within the MPLS TRAFFIC-ENG option, as in the following example.

Between the DmOS-A and DmOS-E equipment, a VPN will be configured through which traffic destined for voice will pass. The priority path will be formed only by signaled links with high capacity, that is, with affinity information 0x1. The paths that contain the high latency signaling will be excluded and cannot be part of backup tunnels for this service.

Based on the above premises, RSVP-TE will automatically create a tunnel with path A-B-D-E as the main tunnel, in the event of a failure, an alternative path will be used.

As we are using the affinity attributes, it is not necessary to specify the hop-to-hop path. Only the declaration of the characteristics for the path selection needs to be informed, as shown below. From there, the “magic” happens.

Note that in the configuration above we detail which attribute is the match.

If a link falls that prevents the establishment of this path only by links with the high capacity attribute, there is the possibility of a second path (path option 2) with lower priority that will use both high and low capacity links. This path will also exclude links flagged as high latency. It is also important to note that, for example, in case of simultaneous failure in the segments formed by A-B and A-C, the “affinity-flags exclude-any 0x4” configuration will prevent the segment formed by A-D from being used and the tunnel will be unavailable.

The creation of the tunnel is unidirectional, so it is necessary to perform the same configuration on the other VPN neighbor (DmOS-E for DmOS-A).

When simulating a link failure between the DmOS-A and DmOS-B equipment (main tunnel path), the convergence will be established by the path A-C-E, as shown below.

In the event of a second failure, between the DmOS-C and DmOS-E equipment, the backup path will follow the direction A-C-B-D-E. The A-C-B-E path would have a lower cost, but the B-E link is signaled as high latency, thus, it was excluded from the options for establishing the tunnel.

Note that, using affinity attributes, RSVP-TE was able to establish the tunnel through different path options, always obeying the restrictions added by the network administrator to the configuration, thus making the operation more flexible, autonomous and effective.

You checked in this article, that the use of MPLS-TE combined with RSVP-TE brings a better use of the resources of your network, through the analysis and the establishment of attributes that facilitate the management.

The features seen in this document are available in DmOS as of version 5.6. For more details regarding the configuration of MPLS-TE and RSVP-TE in DmOS, see our documentation available on the support self-service portal.

Always remembering that Datacom has a complete structure in its headquarters, where face-to-face training is offered. In the training, it will be possible to manipulate the equipment, perform configurations of various topologies and application scenarios in a complete laboratory environment, in addition to being able to count on the help of our professionals in a series of good practices that will greatly assist in the operation of your network.

Subscribe to our YouTube channel, check for notifications and also share the link on your social networks. For questions and request for proposal, contact Datacom's commercial team: sales@datacom.com.br or (+55) 51 3933 3000.

If you have questions about these applications, do not hesitate to contact our suporte.prevendas@datacom.com.br team. We are available to assist you in choosing the product that best suits your needs.