TE Applications and Examples

So far you have learned how TE tunnels are signaled and how they can be placed in the network via explicit routing. Although TE tunnels specify tunnel bandwidth, there is no rule that says that each node must police the amount of traffic to ensure compliance to the bandwidth associated with the tunnel. This is done by design; the tunnel bandwidth value used in the control plane is only a means to perform admission control and allow the setup of TE tunnels on the nonshortest paths. In this section, we discuss the requirements for QoS and how TE tunnels help or do not help in QoS in the network.

TE tunnels can be used in full mesh or used sparingly to route traffic around choke points in the network. For example, if only a few links are congested in the network, a TE tunnel can be explicitly placed around the choke points without enabling MPLS TE in the entire network.

Because most networks today are either multiarea or multiarea and multi-autonomous systems, support of TE tunnels across the areas or autonomous systems is beneficial. How TE tunnels are set up across areas and how they work are discussed in the sections that follow.

Intra-Area TE

We stated earlier that MPLS TE requires IGP extensions to flood available bandwidth information, such that network elements can compute available paths for the setup of TE tunnels. Because the IGP information is not flooded across areas or IS-IS levels, the head end node does not have any visibility of the entire path. Hence, the head end node cannot compute the entire path. The TE tunnel information is therefore loosely specified, and the head end node does not have "strict" knowledge of hops beyond its area.

To set up the TE tunnels across the areas, the TE tunnels must be set up from the head end to the area boundary router (ABR) and then from the ABR to the destination or the tail end. A feature called loose explicit provides the ability to set up loose route to the ABR and then let the ABR set up the rest of the tunnel to the tail end. MPLS TE signaling extensions enable the setup of tunnels via the ABR.

More details regarding Inter-Area TE can be found in Traffic Engineering with MPLS.

Inter-Autonomous System TE

Inter-autonomous system (Inter-AS) traffic engineering with MPLS can be performed in a manner similar to the inter-area TE. In this case, the TE tunnel is set up from the head end to the autonomous system boundary router (ASBR) and then from the ASBR to the tail end. There are two modes in Inter-AS TE:

• One flat IGP across the ASes Both ASes have the same IGP with no hierarchy areas or levels. All IGP information from one AS is redistributed and flooded into the other AS. Nodes learn the bandwidth and topology information, and TE tunnels can be set up between nodes whether they are in the same or different AS.

• Different IGP areas in different ASes In this case, there might be no IGP connectivity between ASBRs. The ASBRs might connect only via BGP. This is the most common case of ASBR peering, when the ASBRs are directly connected to each other. In such cases, the IGP information must be force-flooded so the head end gets the information about other nodes whether they are in the same or different AS.

The signaling methodology is the same as inter-area, in which a loose route is specified at the head end with ASBRs and the ASBRs in turn expand the route information and signal to the tail of tunnel.

Due to a separation of areas and ASes, the topology change information is sent across areas or ASes. Thus, reoptimization cannot be triggered at the head end when changes occur in the tail end area or AS. To handle this case, a technique called loose path reoptimization is used where the ASBR informs the head end of a better available path in the tail end area or AS. The head then decides to reoptimize the tunnel.

Inter-AS TE is useful in building a scenario called Virtual POP. Imagine that a service provider wants to establish a remote POP in a different geographical location to serve its customers. This location might be in a different country or region where this service provider does not have connectivity or facilities access. However, in this geographic location, the service provider has an agreement to transport traffic through the local provider's network. In this case, the SP is AS1 and the local provider's network is AS2. The TE tunnels must be set up through the local provider network to the co-located equipment of the service provider. Hence, the TE tunnels in this case must span AS1 and AS2 from head to tail.

Remember that both inter-area TE and Inter-AS TE signaling extensions of loose hop reoptimization and forced flooding are useful when the dynamic bandwidth control of the TE tunnels is used. An offline tool can also be used to recompute paths and the placement of TE tunnels across the areas. Offline tools provide a global view of the network and can provide better reoptimization. However, offline tools are more static and cannot react to network changes dynamically, though they do provide immense control of the network. As a decision-maker, you must evaluate whether the explicit control and the global network optimization is worth the complexity. In your network and topology, dynamic control might be capable of providing good optimization and reacting to network/topology changes quickly enough that offline tools might not be required.

Quality of Service and TE

So far, we have not specified anything about data plane policing or controlling incoming traffic mapped onto the TE tunnels. This is done by design because the MPLS TE specification does not define any data plane interaction and does not specify any bandwidth reservation. A data plane can be set up for quality of service (QoS) in the same way as DiffServ, whereas a control plane sets up the TE tunnels on links that meet bandwidth constraints. The available bandwidth information is useful in computing available paths to a destination, although that information does not result in queue allocation or scheduler bandwidth change at any given hop.

Traffic Handling of Delay-Sensitive Traffic

By considering link delays as a constraint, TE tunnels for low-delay traffic can be steered onto specific low-delay paths.

The topic of QoS is discussed at length in Chapter 9, "Quality of Service." For the purpose of this chapter, we specify that TE tunnel setup is independent of data plane policing, queuing, and marking. However, packets with specific markings can be mapped to specific tunnels using class-based tunnel selection (CBTS) for routing voice traffic or by delaying sensitive traffic onto specific tunnels bound for a specific destination.

When traffic is mapped to a TE tunnel, based on TE tunnel bandwidth, a policer can be set up to police the incoming traffic and ensure it does not exceed traffic contract (in this case, tunnel bandwidth). Queuing and weighted random early discard (WRED) can be enabled on the head end and mid point nodes so that marked packets get the needed per-hop behavior to ensure the correct delivery of traffic.

Inter-AS TE can also be a means of signaling bandwidth requirements across ASes between providers. By ensuring the appropriate policing of traffic and checking the tunnel counters, providers can determine how much traffic is flowing between autonomous systems and between specific source and destination routers (in this case, the tunnel head and the tail). For example, out-of-contract traffic can be either rejected by the policer or marked as nonconforming to be dropped by WRED thresholds should congestion occur. More details on this and how DiffServ can be used with traffic engineering can be found in Chapter 9.