Configuring Routers for DiffServ-Aware Traffic Engineering
To configure DiffServ-aware traffic engineering, include the diffserv-te statement:
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).
 | Note: 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
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:
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.
Table 1: Default Values for the Traffic Engineering Class Matrix
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:
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:
| Note: 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:
For more information on how to configure class of service, see the Junos OS Class of Service Configuration Guide.
