MPLS is an integration of Layer 2 and Layer 3 technologies. By making traditional Layer 2 features available to Layer 3, MPLS enables traffic engineering. Thus, you can offer in a one-tier network what can be achieved only by overlaying a Layer 3 network on a Layer 2 network.

Traffic engineering is essential for service provider and ISP backbones. Such backbones must support a high use of transmission capacity, and the networks must be resilient so that they can withstand link or node failures.

MPLS traffic engineering provides an integrated approach to traffic engineering. With MPLS, traffic engineering capabilities are integrated into Layer 3, which optimizes the routing of IP traffic, given the constraints imposed by backbone capacity and topology.

MPLS traffic engineering supports the following functionalities:

• Enhances standard Interior Gateway Protocols (IGPs), such as IS-IS or OSPF, to map packets to the appropriate traffic flows automatically.

• Transports traffic flows across a network using MPLS forwarding.

• Determines the routes for traffic flows across a network. This is based on the resources the traffic flow requires and the resources available in the network.

• Employs Constraint-based routing, in which the path for a traffic flow is the shortest path that meets the resource requirements (constraints) of the traffic flow. In MPLS traffic engineering, the traffic flow has bandwidth requirements, media requirements, a priority that is compared to the priority of other flows, and so forth.

• Recovers from link or node failures by adapting to the new constraints presented by the changed topology.

• Transports packets using MPLS forwarding across a multihop label-switched path (LSP).

• Uses the routing and signaling capability of LSPs across a backbone topology that:

  • Understands the backbone topology and available resources.

  • Accounts for link bandwidth and size of traffic flow when determining routes for LSPs across the backbone.

  • Has a dynamic adaptation mechanism that enables the backbone to be resilient to failures, even if several primary paths are precalculated offline.

  • Includes enhancements to the IGP (IS-IS or OSPF) shortest path first (SPF) calculations to automatically calculate which traffic should be sent over which LSPs.

A WAN connection is an expensive item in an ISP budget. Traffic engineering enables ISPs to route network traffic to offer the best service to their users in terms of throughput and delay. By making the service provider more efficient, traffic engineering reduces the cost of the network.

Currently, some ISPs base their services on an overlay model. In this model, transmission facilities are managed by Layer 2 switching. The routers see only a fully meshed virtual topology, making most destinations appear one hop away. If you use the explicit Layer 2 transit layer, you can precisely control how traffic uses the available bandwidth. However, the overlay model has numerous disadvantages. MPLS traffic engineering achieves the traffic engineering benefits of the overlay model without running a separate network, and without needing a nonscalable, full mesh of router interconnects.

MPLS TE automatically establishes and maintains LSPs across the backbone by using RSVP. The path that an LSP uses is determined by the LSP resource requirements and network resources, such as bandwidth.

Available resources are flooded by means of extensions to a link state-based IGP.

Traffic engineering tunnels are calculated at the LSP head, based on a fit between the required and available resources (constraint-based routing). The IGP automatically routes the traffic to these LSPs. Typically, a packet traveling across the MPLS TE backbone travels on a single LSP that connects the ingress point to the egress point.

MPLS traffic engineering is built on the following Cisco IOS mechanisms:

• IP tunnel interfaces

  From a Layer 2 standpoint, an MPLS tunnel interface represents the head of an LSP. It is configured with a set of resource requirements, such as bandwidth, media requirements, and priority.

  From a Layer 3 standpoint, an LSP tunnel interface is the headend of a unidirectional virtual link to the tunnel destination.

• MPLS traffic engineering path calculation module

  This calculation module operates at the LSP head. The module determines a path to use for an LSP. The path calculation uses a link-state database containing flooded topology and resource information.

• RSVP with traffic engineering extensions

  RSVP operates at each LSP hop and is used to signal and maintain LSPs based on the calculated path.

• MPLS traffic engineering link management module

  This module operates at each LSP hop. It enables link call admission on the RSVP signaling messages, and bookkeeping of topology and resource information to be flooded.

• Link-state IGP (IS-IS or OSPF, each with traffic engineering extensions)

  These IGPs are used to globally flood topology and resource information from the link management module.

• Enhancements to the SPF calculation used by the link-state IGP (IS-IS or OSPF)

  The IGP automatically routes traffic to the appropriate LSP tunnel based on tunnel destination. Static routes can also be used to direct traffic to LSP tunnels.

• Label switching forwarding

  This forwarding mechanism provides routers with a Layer 2-like ability to direct traffic across multiple hops of the LSP established by RSVP signaling.

One approach to engineering a backbone is to define a mesh of tunnels from every ingress device to every egress device. The MPLS TE path calculation and signaling modules determine the path taken by the LSPs for these tunnels, subject to resource availability and the dynamic state of the network. The IGP, operating in an ingress device, determines which traffic should go to which egress device, and steers that traffic into the tunnel from ingress to egress.

A flow from an ingress device to an egress device might be so large that it cannot fit over a single link. And it cannot be carried by a single tunnel. In such a scenario, multiple tunnels between a given ingress and egress can be configured, and the flow load can be shared among them.

This section describes how traffic is mapped to tunnels. It describes how conventional hop-by-hop link-state routing protocols interact with MPLS TE capabilities. This section describes how the shortest path first (SPF) algorithm, sometimes called a Dijkstra algorithm, is enhanced. This enhancement allows a link-state IGP to forward traffic automatically over tunnels that MPLS traffic engineering establishes.

Link-state protocols, such as integrated IS-IS or OSPF, use an SPF algorithm to compute a shortest path tree from the headend node to all the nodes in the network. Routing tables are derived from this shortest path tree. The routing tables contain ordered sets of destination and first-hop information. If a router does normal hop-by-hop routing, the first hop is over a physical interface attached to the router.

New traffic engineering algorithms calculate explicit routes to one or more nodes in the network. The originating router views these explicit routes as logical interfaces. In the context of this document, these explicit routes are represented by LSPs and referred to as traffic engineering tunnels (TE tunnels).

The following sections describe how link-state IGPs can use these shortcuts, and how they can install routes in the routing table that point to these TE tunnels. These tunnels use explicit routes. The path taken by a TE tunnel is controlled by the router that is the headend of the tunnel. In the absence of errors, TE tunnels are guaranteed to not loop, but routers must agree on how to use the TE tunnels. Otherwise, traffic might loop through two or more tunnels.

When specifying an explicit path for an MPLS TE tunnel, you can specify link or node addresses of the next-hop routers in an explicit path. You can also specify a mixture of link and node addresses. There are no restrictions when specifying a mixture of link and node addresses.

IS-IS, as specified in RFC 1142, includes extensions for MPLS TE. Running MPLS traffic engineering over IS-IS or taking advantage of these other extensions requires transitioning an IS-IS network to this new technology. This section describes these extensions. It discusses two ways in which to migrate an existing IS-IS network from the standard ISO 10589 protocol towards the version of IS-IS specified in RFC 1142. Running MPLS TE over an existing IS-IS network requires a transition to the version of IS-IS specified in RFC 1142. However, running MPLS TE over OSPF does not require any similar network transition.

Extensions for the IS-IS routing protocol serve the following purposes:

• Remove the 6-bit limit on link metrics.

• Allow interarea IP routes.

• Enable IS-IS to carry different kinds of information for traffic engineering. In the future, more extensions might be needed.

To serve these purposes, two new type, length, and value (TLV)objects have been defined:

• TLV 22 describes links (or adjacencies). It serves the same purpose as the IS neighbor option in ISO 10589 (TLV 2).

• TLV 135 describes reachable IP prefixes. It is similar to the IP neighbor options from RFC 1195 (TLVs 128 and 130).

Note	For ease of use, these two new TLVs, 22 and 135, are referred to as new-style TLVs and TLVs 2, 128, and 130 are referred to as old-style TLVs.

Both the new TLVs have a fixed length part, followed by optional sub-TLVs. The metric space in these new TLVs has been enhanced from 6 bits to 24 or 32 bits. The sub-TLVs allow you to add new properties to links and prefixes. Traffic engineering is the first technology to use this capability to add new properties to a link.

When you migrate from old-style TLVs towards new-style TLVs, you can advertise the same information twice—once in old-style TLVs and once in new-style TLVs. This ensures that all the devices can understand what is advertised.

There are three disadvantages to using that approach:

• Size of the LSPs: During the transition, the LSPs grow to about twice their original size. This might be a problem in networks where the LSP database (LSPDB) is large. An LSP database might be large because:

  • There are many devices, and therfore, many LSPs.

  • There are many neighbors or IP prefixes per router. A device that advertises lots of information causes the LSPs to be fragmented.

• Unpredictable results: In a large network, this approach can produce unpredictable results. A large network that is in transition pushes the limits with regard to LSP flooding and SPF scaling.

• Ambiguity: If a device encounters different information in the old-style TLVs and the new-style TLVs, it may not be clear what the device should do.

  • You can expect some extra network instability. At this time, you must not test how far you can push an implementation.

  • Traffic engineering extensions might cause LSPs to be reflooded frequently.

Most of these problems can be solved easily by using:

• All the information in the old-style and new-style TLVs in an LSP.

• The adjacency with the lowest link metric if an adjacency is advertised more than once.

The main benefit to advertising the same information twice is that network administrators can use new-style TLVs before all the devices in the network can understand them.

When transitioning from using IS-IS with old-style TLVs to new-style TLVs, perform the following actions:

• If all the devices run old software, advertise and use only old-style TLVs.

• Upgrade some devices to newer software.

• Configure some devices with new software to advertise both old-style and new-style TLVs. They accept both styles of TLVs. Configure other devices (with old software) to continue advertising and using only old-style TLVs.

• Test traffic engineering in parts of your network.

• If the whole network needs to migrate, upgrade and configure all the remaining devices to advertise and accept both styles of TLVs.

• Configure all the devices to advertise and accept only new-style TLVs.

• Configure metrics larger than 63.

Devices advertise only one style of TLVs at the same time, but can understand both types of TLVs during migration. There are two main benefits to this approach:

• LSPs stay approximately the same size during migration.

• There is no ambiguity when the same information is advertised twice inside one LSP.

This method is useful when you are transitioning the whole network (or a whole area) to use wider metrics (that is, you want a router running IS-IS to generate and accept only new-style TLVs).

The disadvantage is that all devices must understand the new-style TLVs before any router can start advertising new-style TLVs. It does not help the second problem, where network administrators want to use the new-style TLVs for traffic engineering, while some devices are capable of understanding only old-style TLVs.

If you use the second solution, you can perform the following actions:

• If all the devices run old software, advertise and use only old-style TLVs.

• Upgrade all the devices to newer software.

• Configure all the devices one-by-one to advertise old-style TLVs, but to accept both styles of TLVs.

• Configure all the devices one-by-one to advertise new-style TLVs, but to accept both styles of TLVs.

• Configure all the devices one-by-one to advertise and to accept only new-style TLVs.

• Configure metrics larger than 63.

You can use the metric-style command to configure the type of TLVs that are accepted by a device. When the device is in IS-IS configuration mode, you can configure the following keywords in the metric-style command.

• metric-style narrow : Enables the device to generate and accept only old-style TLVs

• metric-style transition : Enables the device to generate and accept both old-style and new-style TLVs

• metric-style wide : Enables the device to generate and accept only new-style TLVs

You can use either of the following transition schemes when you use the metric-style command:

• Narrow to transition to wide.

• Narrow to narrow transition to wide transition to wide.

Cisco IOS XE can implement both transition solutions. Network administrators can choose the solution that suits them best. For test networks, solution 1 is best (see Solution 1 for Transitioning an IS-IS Network to a New Technology). For a full transition, both solutions can be used. Solution 1 requires fewer steps and less configuration. Solution 2 is for the largest networks, where a risk of doubling the LSP database during transition exists (see Solution 2 for Transitioning an IS-IS Network to a New Technology).