[an error occurred while processing this directive]

Multiprotocol Label Switching for VPNs (MPLS for VPNs)

Inter-Area Traffic Engineering

White Paper


Inter-Area Traffic Engineering



As Service Providers deploy Multiprotocol Label Switching (MPLS) widely, they need to provide end-to-end services in order to offer global reachability to their customers.

Service Providers do not always have the infrastructure to cover a particular area/country, so they partner with local/regional providers. The existing implementation does not provide a solution when this requires an MPLS traffic engineering label switched path (LSP) that crosses different Service Providers end-to-end. The partners do not share a single routing domain, and for security purposes very few providers will expose their network topology.

Service Providers that are running multiple area IGP backbones, which would like to limit the amount of flooded information, SPF calculation, will also require support for traffic engineering LSPs that spanning multiple IGPs.

Inter Area MPLS traffic engineering is an attempt to address the need of MPLS traffic engineering across different regions (mostly IGP areas). It involves the configuration of a single tunnel at the head-end, as opposed to stitching tunnels across each area that must be transversed.

This paper will present a brief description of the required functionalities to provide inter-area MPLS traffic engineering followed by examples of topologies in which inter-area TE is required. Lastly, it will provide deployment note related to supported Cisco IOS® Software features.

Technical Solution

The current MPLS Traffic Engineering capabilities enable traffic engineering LSP that is confined to a single IGP area/level to be established based on specified constraints such as bandwidth or resources class affinity attributes. The specified tunnel will be configured on the head-end. Based on resource requirements, the path calculation (PCAL) procedure will find the best path relaying on link information/resources flooded across the backbone by the IGP (OSPF, IS-IS). The traffic engineering LSP will be established using RSVP as the signaling mechanism throughout the backbone.

As designed, two restrictions apply to MPLS traffic engineering:

1. MPLS traffic engineering can only be configured within a single area


Note:    Note that the IGP area could be an OSPF area or IS-IS level, as those are the two IGPs that provide MPLS TE support


2. Traffic engineering LSP is confined within a single area

To be able to support Inter Area MPLS traffic engineering, the current design needs to be extended. Enhancements are required for the traffic engineering database, path calculation, maintenance, and protection/restoration.

The router, located between the two areas (resp. levels), is known as the ABR (resp. L1L2). The ABRs (or L1L2 if IS-IS) need to support multiple databases, one for each area. ABR should maintain two databases for the normal routing and TE information. As far as MPLS traffic engineering is concerned, ABR will have traffic engineering topology information pertaining to each of its areas. Unlike the routing area, there will be no traffic engineering information exchange between the areas.

Path calculation: in this topology, head-end is not the only LSR to perform a path calculation. In the inter area case, in which the tail-end is in different area, PCALC is just aware of the routing and TE topology of the area it belongs to. As such, the head-end cannot compute the path to the tail-end by itself. All the ABRs along the path will compute the path segment relative to the "downstream" area, as only the ABR knows the TE topology of the area it belongs to.

Path Computation and Signaling

In the single area traffic engineering, where tunnel source (head-end) and tunnel destination (tail-end) are in the same area, PCALC is used to find the "best path" from the head-end to the tail-end that obey the LSP constraints. It is run by the head-end taking into account routing and TE information/constraints flooded in the area.

In the inter-area case, PCALC is also used on the head-end. It will also run on every ABR along the path and on every LSR within an area receiving a Path message whose next-hop address is a loose sub-object.

This mode of operation assumes that PCALC will find the path to the next ABR and the rest of the ERO will then just be passed through and will be expended by the next ABR or LSR (this is known as ERO expand).

If no path can be found from the head-end to the next ABR, from one ABR to the next, or the n-1 ABR to the tail-end, a "no path" message will be return. As a result, the tunnel is seen as down (non-functional).


Figure 1
Path Calculation Inter-area Example

From a signaling perspective, inter-area MPLS traffic engineering, like MPLS traffic engineering confined to a single area, does use RSVP-TE as the signaling protocol. The main change is related to the handling of the ERO. When an LSR receives an RSVP Path message, if the next hop in the ERO is a loose sub-object, it should compute a path segment to that loose hop. Once a new path segment is computed (by PCALC), the LSR proceeds with signaling with the expanded ERO.


Note:    Once the ERO is fully expanded, it stays unchanged for the LSP's life duration i.e. until the TE LSP is torn down (behavior for phase I).


With regards to Figure 1, assume that one would like to set up an MPLS TE LSP from R0 to R12 with the explicit path {R4 loose, R10 loose}.

  • R0 computes a path segment from itself to R4 in area 1 (let's say path segment R0-R1-R4 resulting in an ERO= {R1 strict, R4 strict, R10 loose}.
  • R4 computes a path segment from itself to R10 in area 0
  • Example: path segment R4-R5-R9-R10 resulting in an ERO= {R1 strict, R4 strict, R5 strict, R9 strict, R10 strict}
  • R10 computes a path segment from itself to R12 in area 2
  • Full ERO for the MPLS TE LSP from R0 to R12 is fully defined

Figure 1 demonstrates that R3 and R4 are both ABRs connecting area 1 to area 0 in this topology. It would be preferable to automatically select the ABR that provides the "best path" and have a redundancy (node protection across ABR). For example, if R4 (current ABR in use) fails, then the path should switch to R3.

An automated ABR selection will assure that the LSP from head-end to tail-end will use the most optimal path. Currently, ABR selection is not possible, but several path options can be configured, which specify the preferred list of ABR to be used. Another approach (under study [1]) would be the use of a Path Computation Server (PCS), which has a full view of the traffic engineering network and can therefore compute the end-to-end path. In this case, the PCS would need to be able to "communicate" with the head-end via "some signaling protocol."

More complex approaches are under study as suggested by the draft [1].

Inter-area TE LSP Maintenance

When signaling fails in the head-end area, a path error message is sent to the head-end. The head-end then invalidates the current explicit path option for a defined period of time (hold-down timer) and will try to evaluate the next explicit path option if that one exists.

When signaling fails in other area, the ABR that performed ERO expansion for that area will try to compute an alternate path first within the area, a process known as crankback. If the alternate path exists, the ABR proceeds with the LSP signaling.

Coming back to the previous example, if the link between R5 and R9 fails, R5 sends a path error upstream. R4 computes then an alternate route R4-R5-R7- R9.... R4 continues with the signaling. This is an example of successful crankback.


Figure 2
Successful Crankback Example

If R4 is unable to find an alternate segment that satisfies the LSP requirements, a path error message is sent to the head-end.


Figure 3
Failed Crankback Example

Crankback algorithm is very complex and the number of crankbacks must be limited for better network performance. Generally speaking, increasing the crank back limit tends to increase the average number of hop per LSP.

Fast Reroute

Fast reroute is a feature that allows to reroute LSPs onto a preconfigured back-up tunnel around a link/node failure within 50ms. An inter-area LSP can be configured to be fast re-routable. When a protected link/node fails, the traffic is switched over to the backup tunnel. The node detecting the failure will also send RSVP path error message with the "reservation in place" bit set. The receipt of this message will trigger a reoptimization on the head-end.


Note:    In phase 1, RSVP path error was sent as non-reliable message, to ensure that users do not wait too long if the first RSVP path error was lost, the LSR upstream the LSR detecting the failed link was also asked to re-send the RSVP path error when seeing one. The support of RSVP reliable message allows to alleviate retransmitting the messages.


If the inter-area LSP is not configured to be fast re-routable and a link failure occurs within an area, the LSR to which the failed link is directly attached will generate an RSVP Path error and an RSVP tear messages to the head-end. The head end will then generate an RSVP path tear message. The corresponding path option will be marked as invalid for a certain amount of time and immediately the next path-option will be evaluated if exists.

Path Reoptimization

The LSP reoptimization for inter-area TE is significantly more complex than in the context of single area TE since path calculation involves the head-end as well as ABRs in the areas between the head-end and tail-end. Path reoptimization may occur on a per-area basis.

Work on this topic is still ongoing at the IETF.

For example, when reoptimization timer is elapsed, if the segment to be reoptimized is the head-end segment and if the head-end (PCALC running on head-end) detects a more optimal path to reach the next hop ABR, a new path message is sent by the head-end with a new ERO (from the head-end to the next-hop ABR). Similarly to intra-area TE, "make before break" is used.

More sophisticated re-optimization methods are suggested in [1].

Routing and Forwarding Onto an Inter-area TE LSP

Most of the techniques available for intra area LSP can be used here: static route, Policy based routing.

Currently, "autoroute announce" does not work for an inter-area LSP as the head-end does not know the prefixes reachable via the tail-end (head-end and tail-end being in different areas)

Topology for Inter-area TE

Two major topologies are available for inter-area MPLS traffic engineering.

The first topology occurs when a global Service Provider would like to provide services in area/region where it does not have its own infrastructure but need to relay on a regional service provided. In this case inter area MPLS TE will allow this provider to have an extended/virtual POP.


Figure 4
Extended/Virtual POP

The second case is in the context of MPLS VPN where, a global VPN customer using the services of two service providers may want to have TE (or DS-TE) tunnels between the PE routers.


Figure 5
Virtual Trunk

Deployment Note

Inter Area MPLS traffic engineering (phase I) has been available since Cisco IOS Software Release 12.0(19)ST. The following MPLS traffic engineering features are supported on inter area traffic engineering LSPs in this release:

  • Automatic bandwidth adjustment
  • Diff-Serve-aware traffic engineering
  • Fast reroute link protection
  • Policy-based routing
  • Static routing

Restrictions and work around/recommendation are listed in the below table.

Restrictions;
Release 12.0(19)ST
 
Workaround/Recommendation 
Dynamic Path option is not supported (tunnel mpls traffic-eng path-option x dynamic)

The dynamic path option feature for TE tunnels is not supported for inter-area tunnels. An explicit path identifying the ABRs is required.

 

When there are choices for the ABRs to be used, multiple explicit paths are recommended, each of which identifies a different sequence of ABRs.

MPLS TE AutoRoute feature not supported (tunnel mpls traffic-eng autoroute announce)

As the head-end and tail-end are in different areas, the head-end has any knowledge of the network topology behind the tail-end LSR.

Reoptimization is not supported, crank back not supported

If no path can be found by PCALC to reach the next ABR along the path, then a path error message is sent to the head-end.

 

Further, as crankback is not supported, any path error message sent by an LSR which is not in the same area as the head-end will be received by the head-end, instead of being processed by the ABR in that area. Once receiving an RSVP path error, the head-end will invalidate the corresponding path-option for a fix period of time (2 minutes) and will immediately try to evaluate the next-path option if defined.

FRR node protection not supported

 

Tunnel affinity (tunnel mpls traffic-eng affinity) is not supported

TE information from one area is not flooded into another area. As such, area 0 for example does not have any knowledge of the TE topology of area 1.

Release 12.0.(28)S will provide enhancement such as Node protection across ABR, Fast Reroute and better path calculation. This also known as inter-area phase II.

Configuration Example

The MPLS TE configuration on the router within a single area is the exact same as in the case of intra area MPLS TE. The following configuration example will only outline the differences.

On the ABR, support for both Traffic engineering within the 2 area they are connected to should be specified.

Consider the topology in Fig1, looking at the configuration on R4, assuming that Pos2/0 is the interface connecting R1-R4 (area 1) and Pos3/0 the interface connecting R4 -R5 (area 0)

OSPF-Traffic Engineering  IS-IS Traffic Engineering 

router ospf 1 network 200.2.0.2 0.0.0.0 area 0

network 145.10.0.0 0.0.255.255 area 1

network 155.10.0.0 0.0.255.255 area 0

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

mpls traffic-eng area 1

clns routing

interface POS2/0

ip router isis

interface POS3/0

ip router isis

router isis

metric-style wide

net 49.0000.2000.0200.0002

mpls traffic-eng router-id Loopback0

mpls traffic-eng level-1

mpls traffic-eng level-2

At the head-end, MPLS TE tunnel definition is like the following:

interface Tunnel1

ip unnumbered Loopback0

tunnel destination 20.0.0.20 (address of R12)

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng bandwidth 300

tunnel mpls traffic-eng path-option 1 explicit name path-tunnel1

ip explicit-path name path-tunnel1

next-address loose 200.2.0.2 (address of the first ABR i.e R4)

next-address loose 200.4.0.4 (address of the second ABR i.e. R10)

It is also possible to list in the explicit path the address of the tunnel destination.

As discussed previously, it is recommended to configure multiple loosely routed path options that specify different combinations of ABRs (for OSPF) or level-1-2 boundary routers (for IS-IS).

References

[1] Multi-area MPLS Traffic Engineering, Kompella, Vasseur, draft-kompella-mpls-multiarea-te-03.txt

[2] Release note of IOS 12.0(19) ST

[3] RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels

[4] RFC 2702, Requirements for Traffic Engineering Over MPLS



[an error occurred while processing this directive]