Definitive MPLS Network Designs [Electronic resources] نسخه متنی

DiffServ-Aware MPLS Traffic Engineering

Quality of Service in MPLS Networks," DiffServ (introduced in [DIFF-ARCH]) and MPLS DiffServ (covered in [MPLS-DIFF]) define QoS mechanisms in the data path (such as how to schedule different traffic streams in different queues) independently of how traffic is routed in the network. Conversely, MPLS TE defines how traffic aggregates may be routed into a network independently of the QoS mechanisms that may be deployed and hence how traffic may actually be scheduled at every hop. Consequently, although MPLS TE and DiffServ can be deployed simultaneously in a given network, they remain unaware of each other so that MPLS TE performs constraint-based routing and admission control on an aggregate basis across all DiffServ classes. DiffServ-aware MPLS Traffic Engineering (DS-TE) is an extension to MPLS TE to make it aware of DiffServ. It allows the benefits of constraint-based routing and admission control to be applied separately, and hence more accurately, to different classes of services (or to different sets of such classes with similar requirements).

With DS-TE, separate MPLS TE tunnels are established for different DiffServ classes of service (or for different sets of classes of service). Then, when performing constraint-based routing for these tunnels, the resources actually available to the corresponding class(es) of service can be taken into account (as opposed to the aggregate link bandwidth). Also, the specific attributes of the class(es) of service can be enforced (as opposed to attributes that are common to all the classes of service). It is also possible to enforce separate engineering constraints for the different classes of traffic. For example, one of the DS-TE requirements identified by service providers (see [DSTE-REQ]) for networks carrying a significant amount of voice over IP traffic is to be able to limit the total VoIP load below a certain percentage of the link bandwidth. This helps control the delay and jitter for this traffic while filling the rest of the link with traffic which is less delay- and jitter-sensitive.

Thus, the objective of DS-TE is to allow support of applications with very tight QoS requirements without relying on overengineering.

The next section reviews how DS-TE extends the MPLS TE components introduced earlier. Like TE, the DS-TE extensions are purely in the control plane. DS-TE relies on MPLS DiffServ in the data path (either E-LSPs or L-LSPs, as defined in the "Quality of Service in MPLS Networks" section) and does not introduce any additional QoS mechanisms.

Bandwidth Constraints Model

A key objective of DS-TE is to be able to enforce different bandwidth constraints on different types of traffic. We define a class type (CT) as the set of DS-TE LSPs that share the same set of bandwidth constraints. DS-TE supports up to eight CTs (CT0 to CT7).

A bandwidth constraints model defines the relationships between CTs and bandwidth constraints (BC0 to BC7). Three bandwidth constraints models are currently specified and supported by the DS-TE protocol extensions: the Russian Dolls Model (RDM) (see [DSTE-RDM]), the Maximum Allocation Model (MAM) (see [DSTE-MAM]), and the Maximum Allocation Model with Reservation (MAR) (see [DSTE-MAR]).

With RDM, the bandwidth constraints apply on CTs in a nested manner. For example, assuming that three CTs are in use:

All LSPs from CT2 use no more than BC2.

All LSPs from CT1 and CT2 together use no more than BC1.

All LSPs from CT0, CT1, and CT2 together use no more than BC0.

With MAM, each bandwidth constraint applies independently to each CT, whereas the MPLS TE maximum reservable bandwidth constitutes an aggregate bandwidth constraint across all CTs. For example, assuming again that three CTS are in use, with MAM:

All LSPs from CT2 use no more than BC2.

All LSPs from CT1 use no more than BC1.

All LSPs from CT0 use no more than BC0.

All LSPs from CT0, CT1, and CT2 together use no more than the maximum reservable bandwidth.

The RDM and MAM models are illustrated in Figure 2-17 with three class types.

A single bandwidth constraints model must be used everywhere in a given DS-TE cloud.

The nested bandwidth constraints of RDM in the control plane match well the commonly used DiffServ bandwidth allocation policy in the data path which schedules real-time class with absolute priority, and then allocates most of the remaining bandwidth to the next priority class, and then most of the remaining bandwidth to the next class, and so on. For this reason, RDM can achieve very high link utilization while simultaneously guaranteeing quality of service to the various DiffServ classes. Also, through the use of preemption, RDM can guarantee that each CT will be granted a desired amount of bandwidth. Thus, RDM is often the bandwidth constraints model of choice in DS-TE deployments.

MAM may be attractive when simpler administrative bandwidth allocation policies (such as individually limiting each CT) are sought or when multiple classes are scheduled independently with comparable priorities in bandwidth allocation. However, MAM generally cannot achieve very high link utilization while simultaneously guaranteeing quality of service to all classes.

MAR is based on MAM, but with extensions aimed at addressing the limitation of MAM that we just mentioned. To that end, with MAR, class types are actually allowed to exceed their bandwidth constraints in the absence of contention but revert to them when contention across class types occurs. However, MAR brings significant additional complexity, and its applicability is not yet well understood.

Extensions to the Traffic Engineering LSP Attribute

DS-TE adds one TE LSP attribute, which is the class type. In accordance with the bandwidth constraints model in use, this determines the bandwidth constraints that are applicable to that DS-TE LSP.

Extensions to TE LSP Path Computation

The exact same algorithm for path computation can be used for DS-TE. The only difference is that the algorithm needs to take into account the bandwidth available to the particular combination of the preemption level and the CT of the TE LSP under consideration.

Extensions to Traffic Engineering IGP Routing

With DS-TE each link can be configured with up to eight bandwidth constraints.

Recall that the IGP has been extended for MPLS TE to advertise up to eight values of available bandwidthone for each of the eight preemption levels. DS-TE simply generalizes these eight values as now advertising the available bandwidth for an arbitrary combination of preemption and class type. Thus, a given DS-TE network can only support a maximum of eight active combinations of preemption and CTs. For example, a DS-TE network may use eight CTs with one preemption level for each, or four CTs with two preemption levels for each, but it cannot use five CTs with two preemption levels for each.

Extensions to TE LSP Signaling

DS-TE specifies one additional RSVP object to convey the TE LSP class type during RSVP-TE signaling. In particular, this allows admission control to take into account the corresponding bandwidth constraints.

[DSTE-PROTO].

Note

All the DS-TE extensions are backward-compatible with regular TE, which behaves as a particular case of DS-TE in which a single CT is used with eight preemption levels. This allows smooth migration from regular TE deployments to DS-TE.

Routing onto DiffServ-Aware TE LSPs

As with TE LSPs, static routes and recursive static routes to BGP next hops can be used to steer traffic onto DS-TE LSPs. This can be done when traffic of different classes of service is destined for different prefix ranges. An example is when the voice traffic terminates in trunk voice gateways that are connected to dedicated LANs configured with specific prefix ranges.

For dynamic routing over DS-TE LSPs, the mechanism discussed earlier that dynamically routes traffic over TE LSPs needs to be extended to perform such routing on a per-class of service basis. It also must be able to take into account the suitability of tunnels to carry each class of service. For example, Cisco supports a CoS-Based Tunnel Selection (CBTS) feature that extends the autoroute feature to dynamically route and forward traffic to DS-TE tunnels on a per-prefix/per-class of service basis depending on the classes of service that tunnels are configured as eligible to carry.

Example of DS-TE Deployment

The canonical example of DS-TE deployment is where separate meshes of tunnels are built for voice and data traffic. The voice TE LSPs and data TE LSPs can then be engineered specifically against the respective quality of service requirements of voice and data traffic. For example, the operator may use the RDM model to ensure that the voice load stays below 50 percent of the link capacity (to control delay and jitter for voice and to ensure that the rest of the traffic is allocated sufficient bandwidth) while the aggregate load across both voice and data is limited to 100 percent of the link capacity. Also, the path for each voice TE LSP is computed by taking into account only the voice load. It may be optimized on a metric reflecting propagation delay, with a high preemption level to ensure that voice TE LSPs are as close as achievable to their shortest path and that they can be protected by Fast Reroute. As shown in Figure 2-18, such a DS-TE deployment ensures that, whenever possible, the voice traffic follows the path resulting in minimal delay (the upper path in the figure), while the data traffic follows the path offering the necessary bandwidth (the lower path in the figure).