Skip to content

MPLS-TE simulation

MPLS-TE tunnels are a common mechanism to enable finer IP traffic engineering. An MPLS-TE tunnel is a unidirectional path across the IP network, that when up, is available to the IP routing process for forwarding IP packets.

ENP precisely models the behavior of multiple settings and flavors of traffic engineering with MPLS-TE tunnels. The user is able to:

ENP simulation of MPLS-TE includes:

  • Bandwidth reservation policies and tunnel priorities. Accurate representation of the bandwidth reservation mechanisms, considering also the MPLS-TE preemption policies based on tunnel priorities.
  • Path computation and network recovery mechanisms. Accurate representation of the tunnel path computation forms: dynamic CSPF-based computations (for dynamic MPLS restoration), path-option lists (for pre-determined MPLS restoration), and Fast-ReRoute path protection (for MPLS protection).
  • IP routing settings over the tunnels. Simulation of the IP/IGP/BGP and MPLS-TE interactions, for both Autoroute-based and Forwarding-adjacency-based tunnels.

MPLS-TE information per IP interface

The user can define the following information per IP interface, that configure the MPLS-TE behavior:

  • MPLS-TE enabled. IP interfaces can be enabled or not for carrying MPLS-TE tunnels. Disabled IP interfaces are not eligible as part of the path of MPLS-TE tunnels.
  • Total reservable bandwidth by traversing MPLS-TE tunnels. The user can specify for each IP interface the total bandwidth that is allowed to be reserved in the interface for traversing MPLS-TE tunnels.
  • Reservable bandwidth per traversing MPLS-TE tunnels. The user can specify for each IP interface the maximum bandwidth that is allowed to be reserved in the link for each individual traversing MPLS-TE tunnel.
  • Administrative weight. The user can specify for each IP interface the so-called administrative weight. This is a 32-bit unsigned int that is propagated by the IGP when it floods traffic engineering information for building tunnels. Typically it is the same number as the IGP (although you have 32 bits here). When a tunnel path is dynamically computed using CSPF, the link administrative weight is used as the default link cost. However, the user can individually decide for each tunnel, whether to use the administrative weight or the IGP metric in these calculations.

MPLS-TE information per tunnel

The user can define the following information per MPLS-TE tunnel, to configure the MPLS-TE behavior:

  • Private/non-private tunnel. If the user selects the tunnel as private, it can only be used to carry traffic of the user-defined private demands. This option permits easily defining e.g. VPNs based on MPLS-TE tunnels carrying traffic of specific demands. Tunnels not declared as private operate as regular MPLS-TE tunnels and are involved in the regular forwarding of the IGP.
  • QoS class. This is the QoS tagging for the traffic in the tunnel. All the tunnel’s traffic is assigned to this user-defined QoS class, and the queues in the traversing links deal with it appropriately.
  • Tunnel reserved bandwidth. This is the amount of bandwidth that, at the control plane, the tunnel is reserving. As in real MPLS-TE tunnels, this may or may not be equal to the traffic that the tunnel actually carries. The reserved bandwidth has implications just in the control plane reservations. In particular, a tunnel path is affected by this value, since e.g. the sum of the reserved bandwidths of the traversed tunnels, cannot exceed the maximum IP link reservable bandwidth assigned to MPLS-TE tunnels.
  • Load sharing between tunnels. If more than one tunnel to a destination exists, and only MPLS-TE tunnels are used to forward traffic to that destination, the traffic through each tunnel is proportional to the tunnel reservable bandwidth, or to a user-defined equivalent capacity value.
  • Tunnel setup priority and holding priority. These are the equivalent values defined for MPLS-TE tunnels. The MPLS control plane utilizes this information to potentially pre-empt existing tunnels in the path computation process. If the setup priority of a tunnel is lower (better) than the holding priority of other tunnels, it will pre-empt it if necessary if there is not enough control-plane reservable bandwidth for both.

Note

Note that according to the standard, holding priority should always be lower (better) than setup priority.

  • Autoroute / forwarding adjacency (FA) tunnels. MPLS-TE tunnels can be of the autoroute of FA type. In the former, the tunnel is not announced as a forwarding adjacency in the IGP, while FA tunnels (that must be bidirectional, with one tunnel in each direction) are announced. Being announced means that they appear in the IGP shortest path computations of other nodes. In contrast, autoroute tunnels only appear in the IGP shortest path calculations of their origin node.
  • Path computation options, FRR, and path option lists. The user can select different options for defining the tunnel paths:
    • CSPF dynamic calculation. In this option, the tunnel path is dynamically recomputed emulating the CSPF (Constrained SPF) algorithm. The tunnel can or not (user-defined) use the IGP weights or the administrative weights for CSPF calculations.
    • Path-option lists. In this option, the user can define an ordered set of paths for the tunnel. Only one of the paths is control-plane active, thus reserving resources at the control plane level. Dynamic CSPF computation can be or is not chosen as a default last option.
    • Path-option list with FRR. The difference with the previous case is that the tunnel bandwidth is reserved in all the paths assigned to the tunnels, even the ones inactive.

Creating an MPLS-TE tunnel

It is possible to add MPLS-TE tunnels in the topology panel (clicking origin and destination nodes), or in the MPLS-TE table, in this right-click option.