DiffServ-Aware Traffic Engineering Configuration
DiffServ-Aware Traffic Engineering Introduction
Differentiated Services (DiffServ)-aware traffic engineering provides a way to guarantee a specified level of service over an MPLS network. The routers providing DiffServ-aware traffic engineering are part of a differentiated services network domain. All routers participating in a differentiated services domain must have DiffServ-aware traffic engineering enabled.
To help ensure that the specified service level is provided, it is necessary to ensure that no more than the amount of traffic specified is sent over the differentiated services domain. You can accomplish this goal by configuring a policer to police or rate-limit the volume of traffic transiting the differentiated service domain. For more information about how to configure policers for label-switched paths (LSPs), see Configuring Policers for LSPs.
This feature can help to improve the quality of Internet services such as voice over IP (VoIP). It also makes it possible to better emulate an Asynchronous Transfer Mode (ATM) circuit over an MPLS network.
DiffServ-Aware Traffic Engineering Terminology
Bandwidth model
The bandwidth model determines the values of the available bandwidth advertised by the interior gateway protocols (IGPs).
CAC
Call admission control (CAC) checks to ensure there is adequate bandwidth on the path before the LSP is established. If the bandwidth is insufficient, the LSP is not established and an error is reported.
Class type
A collection of traffic flows that is treated equivalently in a differentiated services domain. A class type maps to a queue and is much like a class-of-service (CoS) forwarding class in concept. It is also known as a traffic class.
Differentiated Services
Differentiated Services make it possible to give different treatment to traffic based on the EXP bits in the MPLS header. Traffic must be marked appropriately and CoS must be configured.
Differentiated Services domain
The routers in a network that have Differentiated Services enabled.
DiffServ-aware traffic engineering
A type of constraint-based routing. It can enforce different bandwidth constraints for different classes of traffic. It can also do CAC on each traffic engineering class when an LSP is established.
Multiclass LSP
A multiclass LSP functions like a standard LSP, but it also allows you to reserve bandwidth from multiple class types. The EXP bits of the MPLS header are used to distinguish between class types.
MAM
The maximum allocation bandwidth constraint model divides the available bandwidth between the different classes. Sharing of bandwidth between the class types is not allowed.
RDM
The Russian dolls bandwidth constraint model makes efficient use of bandwidth by allowing the class types to share bandwidth.
Traffic engineering class
A paired class type and priority.
Traffic engineering class map
A map between the class types, priorities, and traffic engineering classes. The traffic engineering class mapping must be consistent across the Differentiated Services domain.
DiffServ-Aware Traffic Engineering Features
DiffServ-aware traffic engineering provides the following features:
Traffic engineering at a per-class level rather than at an aggregate level
Different bandwidth constraints for different class types (traffic classes)
Different queuing behaviors per class, allowing the router to forward traffic based on the class type
In comparison, standard traffic engineering does not consider CoS, and it completes its work on an aggregate basis across all Differentiated Service classes.
DiffServ-aware traffic engineering provides the following advantages:
Traffic engineering can be performed on a specific class type instead of at the aggregate level.
Bandwidth constraints can be enforced on each specific class type.
It forwards traffic based on the EXP bits.
This makes it possible to guarantee service and bandwidth across an MPLS network. With DiffServ-aware traffic engineering, among other services, you can provide ATM circuit emulation, VoIP, and a guaranteed bandwidth service.
The following describes how the IGP, Constrained Shortest Path First (CSPF), and RSVP participate in DiffServ-aware traffic engineering:
The IGP can advertise the unreserved bandwidth for each traffic engineering class to the other members of the differentiated services domain. The traffic engineering database stores this information.
A CSPF calculation is performed considering the bandwidth constraints for each class type. If all the constraints are met, the CSPF calculation is considered successful.
When RSVP signals an LSP, it requests bandwidth for specified class types.
Configuring Link Down Notification for Optics Options Alarm or Warning
DiffServ-Aware Traffic Engineered LSPs Overview
A DiffServ-aware traffic engineered LSP is an LSP configured with a bandwidth reservation for a specific class type. This LSP can carry traffic for a single class type. On the packets, the class type is specified by the EXP bits (also known as the class-of-service bits) and the per-hop behavior (PHB) associated with the EXP bits. The mapping between the EXP bits and the PHB is static, rather than being signaled in RSVP.
The class type must be configured consistently across the Differentiated Services domain, meaning the class type configuration must be consistent from router to router in the network. You can unambiguously map a class type to a queue. On each node router, the class-of-service queue configuration for an interface translates to the available bandwidth for a particular class type on that link.
For more information about topics related to LSPs and DiffServ-aware traffic engineering, see the following:
For forwarding classes and class of service, see the Junos OS Class of Service User Guide for Routing Devices.
For EXP bits, see MPLS Label Allocation.
For differentiated services, see RFC 3270, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services.
For information about how the IGPs and RSVP have been modified to support Differentiated Services-aware MPLS traffic engineering, see RFC 4124, Protocol Extensions for Support of Differentiated-Service-Aware MPLS Traffic Engineering.
DiffServ-Aware Traffic Engineered LSPs Operation
When configuring a DiffServ-aware traffic engineered LSP, you specify the class type and the bandwidth associated with it. The following occurs when an LSP is established with bandwidth reservation from a specific class type:
The IGPs advertise how much unreserved bandwidth is available for the traffic engineering classes.
When calculating the path for an LSP, CSPF is used to ensure that the bandwidth constraints are met for the class type carried by the LSP at the specified priority level.
CSPF also checks to ensure that the bandwidth model is configured consistently on each router participating in the LSP. If the bandwidth model is inconsistent, CSPF does not compute the path (except for LSPs from class type ct0).
Once a path is found, RSVP signals the LSP using the Classtype object in the path message. At each node in the path, the available bandwidth for the class types is adjusted as the path is set up.
An LSP that requires bandwidth from a particular class (except class type ct0) cannot be established through routers that do not understand the Classtype object. Preventing the use of routers that do not understand the Classtype object helps to ensure consistency throughout the Differentiated Services domain by preventing the LSP from using a router that cannot support Differentiated Services.
By default, LSPs are signaled with setup priority 7 and holding priority 0. An LSP configured with these values cannot preempt another LSP at setup time and cannot be preempted.
It is possible to have both LSPs configured for DiffServ-aware traffic engineering and regular LSPs configured at the same time on the same physical interfaces. For this type of heterogeneous environment, regular LSPs carry best-effort traffic by default. Traffic carried in the regular LSPs must have the correct EXP settings (either by remarking the EXP settings or by assuming that the traffic arrived with the correct EXP settings from the upstream router).
Configuring Routers for DiffServ-Aware Traffic Engineering
To configure DiffServ-aware traffic engineering, include the diffserv-te statement:
diffserv-te { bandwidth-model { extended-mam; mam; rdm; } te-class-matrix { traffic-class { tenumber { priority priority; traffic-class ctnumber priority priority; } } } }
You can include this statement at the following hierarchy levels:
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]
You must include the diffserv-te statement in the
configuration on all routers participating in the Differentiated Services
domain. However, you are not required to configure the traffic engineering
class matrix (by including the te-class-matrix statement
at the [edit protocols mpls diffserv-te] or [edit
logical-systems logical-system-name protocols
mpls diffserv-te] hierarchy level).
To prevent the possibility of an incorrect configuration when migrating to Diffserv-aware traffic engineering, a policy control failure error might be triggered if there is conflict between the old LSPs and the newly configured TE-class matrix.
An old node might request an LSP with setup and hold priorities in such a way that the combination of the ct0 class and the priority does not match with the configured TE-class matrix. All LSPs on the router that are configured prior to configuring diffserv-aware traffic engineering are designated as being from class ct0.
The error appears in the RSVP tracing logs as a Session preempted error. For the router where the
error originates, the error could appear as follows:
Jun 17 16:35:59 RSVP error for session 10.255.245.6(port/tunnel ID 31133) Proto 0: (class ct0, priority 2) is not a valid TE-class Jun 17 16:35:59 RSVP originate PathErr 192.168.37.22->192.168.37.23 Session preempted
For the router receiving the error, the error can appear as follows:
Jun 17 16:37:51 RSVP recv PathErr 192.168.37.22->192.168.37.23 Session preempted LSP to-f(2/31133)
To configure DiffServ-aware traffic engineering, complete the procedures in the following sections:
- Configuring the Bandwidth Model
- Configuring Traffic Engineering Classes
- Configuring Class of Service for DiffServ-Aware Traffic Engineering
Configuring the Bandwidth Model
You must configure a bandwidth model on all routers participating in the Differentiated Services domain. The bandwidth models available are MAM, extended MAM, and RDM:
Maximum allocation bandwidth constraints model (MAM)—Defined in RFC 4125, Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering.
Extended MAM—A proprietary bandwidth model that behaves much like standard MAM. If you configure multiclass LSPs, you must configure the extended MAM bandwidth model.
Russian-dolls bandwidth allocation model (RDM)—Makes efficient use of bandwidth by allowing the class types to share bandwidth. RDM is defined in RFC 4127, Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering.
To configure a bandwidth model, include the bandwidth-model statement and specify one of the bandwidth model options:
bandwidth-model { extended-mam; mam; rdm; }
You can include this statement at the following hierarchy levels:
[edit protocols mpls diffserv-te][edit logical-systems logical-system-name protocols mpls diffserv-te]Note:If you change the bandwidth model on an ingress router, all the LSPs enabled on the router are taken down and resignaled.
Configuring Traffic Engineering Classes
Configuring traffic engineering classes is optional. Table 1 shows the default values for everything in the traffic engineering class matrix. The default mapping is expressed in terms of the default forwarding classes defined in the CoS configuration.
Traffic Engineering Class |
Class Type |
Queue |
Priority |
|---|---|---|---|
te0 |
ct0 |
0 |
7 |
te1 |
ct1 |
1 |
7 |
te2 |
ct2 |
2 |
7 |
te3 |
ct3 |
3 |
7 |
te4 |
ct0 |
0 |
0 |
te5 |
ct1 |
1 |
0 |
te6 |
ct2 |
2 |
0 |
te7 |
ct3 |
3 |
0 |
If you want to override the default mappings, you can configure traffic engineering classes 0 through 7. For each traffic engineering class, you configure a class type (or queue) from 0 through 3. For each class type, you configure a priority from 0 through 7.
To configure traffic engineering classes explicitly, include
the te-class-matrix statement:
te-class-matrix { tenumber { priority priority; traffic-class { ctnumber priority priority; } } }
You can include this statement at the following hierarchy levels:
[edit protocols mpls diffserv-te][edit logical-systems logical-system-name protocols mpls diffserv-te]
The following example shows how to configure traffic engineering
class te0 with class type ct1 and a priority of 4:
[edit protocols mpls diffserv-te]
te-class-matrix {
te0 traffic-class ct1 priority 4;
}
If you explicitly configure a value for one of the traffic engineering classes, all the default values in the traffic engineering class matrix are dropped.
When you explicitly configure traffic engineering classes, you must also configure a bandwidth model; otherwise, the configuration commit operation fails.
Requirements and Limitations for the Traffic Engineering Class Matrix
When you configure a traffic engineering class matrix, be aware of the following requirements and limitations:
A mapping configuration is local and affects only the router on which it is configured. It does not affect other systems participating in the differentiated services domain. However, for a Differentiated Services domain to function properly, you need to configure the same traffic engineering class matrix on all the routers participating in the same domain.
When explicitly configuring traffic engineering classes, you must configure the classes in sequence (
te0,te1,te2,te3, and so on); otherwise, the configuration commit operation fails.
The first traffic engineering class you configure must be te0; otherwise, the configuration commit operation fails.
Configuring Class of Service for DiffServ-Aware Traffic Engineering
To configure DiffServ-aware traffic engineering, you must also configure class of service. The following example illustrates a class-of-service configuration that would allocate 25 percent of the link bandwidth to each class:
class-of-service {
interfaces {
all {
scheduler-map simple-map;
}
}
scheduler-maps {
simple-map {
forwarding-class assured-forwarding scheduler simple_sched;
forwarding-class best-effort scheduler simple_sched;
forwarding-class network-control scheduler simple_sched;
forwarding-class expedited-forwarding scheduler simple_sched;
}
}
schedulers {
simple_sched {
transmit-rate percent 25;
buffer-size percent 25;
}
}
}
Configuring LSPs for DiffServ-Aware Traffic Engineering
You must configure the Differentiated Services domain (see Configuring Routers for DiffServ-Aware Traffic Engineering) before you can enable DiffServ-aware traffic engineering for LSPs. The Differentiated Services domain provides the underlying class types and corresponding traffic engineering classes that you reference in the LSP configuration. The traffic engineering classes must be configured consistently on each router participating in the Differentiated Services domain for the LSP to function properly.
You must configure either MAM or RDM as the bandwidth model when you configure DiffServ-aware traffic engineering for LSPs. See Configuring the Bandwidth Model.
The actual data transmitted over this Differentiated Services domain is carried by an LSP. Each LSP relies on the EXP bits of the MPLS packets to enable DiffServ-aware traffic engineering. Each LSP can carry traffic for a single class type.
All the routers participating in the LSP must be Juniper Networks routers running Junos OS Release 6.3 or later. The network can include routers from other vendors and Juniper Networks routers running earlier versions of the Junos OS. However, the DiffServ-aware traffic engineering LSP cannot traverse these routers.
You cannot simultaneously configure multiclass LSPs and DiffServ-aware traffic engineering LSPs on the same router.
To enable DiffServ-aware traffic engineering for LSPs, you need to configure the following:
- Configuring Class of Service for the Interfaces
- Configuring IGP
- Configuring Traffic-Engineered LSPs
- Configuring Policing for LSPs
- Configuring Fast Reroute for Traffic-Engineered LSPs
Configuring Class of Service for the Interfaces
The existing class-of-service (CoS) infrastructure ensures that traffic that is consistently marked receives the scheduling guarantees for its class. The classification, marking, and scheduling necessary to accomplish this are configured using the existing Junos OS CoS features.
The Junos OS does not support CoS on ATM interfaces.
For information about how to configure CoS, see the Junos OS Class of Service User Guide for Routing Devices.
Configuring IGP
You can configure either IS-IS or OSPF as the IGP. The IS-IS and OSPF configurations for routers supporting LSPs are standard. For information about how to configure these protocols, see the Junos OS Routing Protocols Library for Routing Devices.
Configuring Traffic-Engineered LSPs
You configure an LSP by using the standard LSP configuration
statements and procedures. To configure DiffServ-aware traffic engineering
for the LSP, specify a class type bandwidth constraint by including
the bandwidth statement:
label-switched-path lsp-name {
bandwidth {
ctnumber bps;
}
}
For a list of hierarchy levels at which you can include the bandwidth statement, see the statement summary sections for
this statement.
If you do not specify a bandwidth for a class type, ct0 is automatically specified as the queue for the LSP. You can configure
only one class type for each LSP, unlike multiclass LSPs.
The class type statements specify bandwidth (in bits per second) for the following classes:
ct0—Bandwidth reserved for class 0ct1—Bandwidth reserved for class 1ct2—Bandwidth reserved for class 2ct3—Bandwidth reserved for class 3
You can configure setup and holding priorities for an LSP, but the following restrictions apply:
The combination of class and priority must be one of the configured traffic engineering classes. The default setup priority is 7 and the default holding priority is 0.
Configuring an invalid combination of class type and priority causes the commit operation to fail.
Automatic bandwidth allocation is not supported. If you configure automatic bandwidth allocation, the commit operation fails.
LSPs configured with the
bandwidthstatement but without specifying a class type use the default class typect0.For migration issues, see Internet draft draft-ietf-tewg-diff-te-proto-07.txt.
Configuring Policing for LSPs
Policing allows you to control the amount of traffic forwarded through a particular LSP. Policing helps to ensure that the amount of traffic forwarded through an LSP never exceeds the requested bandwidth allocation. You can configure multiple policers for each LSP.
For information about how to configure a policer for an LSP, see Configuring Policers for LSPs.
Configuring Fast Reroute for Traffic-Engineered LSPs
You can configure fast reroute for traffic engineered LSPs (LSPs carrying a single class of traffic). It is also possible to reserve bandwidth on the detour path for the class of traffic when fast reroute is enabled. The same class type number is used for both the traffic engineered LSP and its detour.
If you configure the router to reserve bandwidth for the detour path, a check is made to ensure that the link is capable of handling DiffServ-aware traffic engineering and for CoS capability before accepting it as a potential detour path. Unsupported links are not used.
You can configure the amount of bandwidth to reserve for detours
using either the bandwidth statement or the bandwidth-percent statement. You can only configure one these statements at a time.
If you do not configure either the bandwidth statement
or the bandwidth-percent statement, the default setting
is to not reserve bandwidth for the detour path (the bandwidth guarantee
will be lost if traffic is switched to the detour).
When you configure the bandwidth statement, you can
specify the specific amount of bandwidth (in bits per second [bps])
you want to reserve for the detour path. For information, see Configuring Fast Reroute.
The bandwidth-percent statement allows you to specify
the bandwidth of the detour path as a percentage of the bandwidth
configured for the protected path. For example, if you configure 100
millions bps of bandwidth for the protected path and configure 20
for the bandwidth-percent statement, the detour path will
have 20 million bps of bandwidth reserved for its use.
To configure the percent of bandwidth used by the detour path
based on the bandwidth of the protected path, include the bandwidth-percent statement:
bandwidth-percent percentage;
You can include this statement at the following hierarchy levels:
[edit protocols mpls label-switched-path lsp-name fast-reroute][edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name fast-reroute]