Core Issue
One of the applications of Multiprotocol Label Switching (MPLS) is Traffic Engineering (TE), which is used for manipulating the traffic to fit a particular network. TE is important for service providers to efficiently use their backbones and provide high resiliency. MPLS TE provides an integrated approach to traffic engineering by combining the traffic engineering capabilities of ATM with the flexibility and Class of Service (CoS) differentiation of IP. The nature of MPLS TE avoids the problems associated with the overlay models, such as ATM or Frame Relay networks. Like ATM or Frame Relay Virtual Circuits (VCs), the Label Switched Path (LSP) automatically built by MPLS TE controls the path of traffic flow to a particular destination, rather than pure destination based forwarding.
MPLS TE builds unidirectional tunnels from a source to the destination in the form of LSPs, which is then used to forward traffic. The point where the tunnel begins is called the tunnel headend or tunnel source, and the node where the tunnel ends is called the tunnel tailend or tunnel destination. MPLS TE works by learning about the topology and resources available in a network using a link state routing protocol such as Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (IS-IS).
The Constraint-Based Shortest Path First (CSPF) algorithm that operates on the tunnel headend is used for finding the shortest path to a particular network that meets the resource requirements of traffic flow. Based on the information determined by the CSPF algorithm, Resource Reservation Protocol (RSVP) with TE extensions is used as the signaling protocol. This protocol reserves resources for traffic flow and establishes the LSP for traffic flow by exchanging labels.
Resolution
Prior to the MPLS TE interarea tunnels feature, an MPLS TE tunnel could span only a single OSPF area or IS-IS level. This required the tunnel headend and tailend to be present in the same area or level. Additionally, OSPF Area Border Routers (ABRs) and IS-IS Level 1 - Level 2 (L1L2) routers could not have MPLS TE configured for more than one area or level.
With the introduction of the MPLS TE interarea tunnel feature, an MPLS TE tunnel could span multiple areas. This allows the headend and tailend to be present in different areas. This feature also allows OSPF ABRs and IS-IS L1L2 routers to have MPLS TE configured in more than one area or level.
However, due to the nature of LSP flooding between areas or levels in OSPF and IS-IS, the headend router has complete information about topology and resources only within its own area or level, and not for the entire path toward the tailend.
To resolve this issue, proceed with these options:
- Configure an interarea tunnel from a headend in one area to a tailend in a different area by using these methods.
Configure multiple intra-area tunnels:
- Between the ABRs that belong to the same area, which connect to other areas
- One from the tunnel headend to its ABR
- One from the tunnel tailend to its ABR
All the intra-area tunnels together simulate a single interarea tunnel.
- Build an interarea tunnel by specifying an explicit path on the headend toward the tailend. However, this explicit path should use a loose Explicit Route Object (ERO) rather than the strict ERO normally used. RSVP uses ERO to specify a series of routers to be traversed from the headend to the tailend and build the LSP.
The strict ERO specifies a series of routers to be traversed in the same order from the headend to the tailend. In the case of interarea tunnels, because the headend router does not know the complete path toward the tailend, the strict ERO fails to build a tunnel.
On the other hand, the loose ERO can specify the series of ABRs to be traversed toward the tailend. When an ABR receives a loose ERO, it must resolve it to a strict ERO. This is done toward the next address in the ERO pointing to the next ABR. Thus, a series of routers in loose ERO is converted into a series of routers with strict ERO. LSP is then established.
For more information about this feature and the configuration, refer to MPLS Traffic Engineering (TE)--Interarea Tunnels.
For information on MPLS TE and the configuration, refer to these documents:
