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).
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 Class of Service Configuration Guide.
