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 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:

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 4 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 4: 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:

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;}

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. See Configuring Routers for DiffServ-Aware Traffic Engineering.

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;}}}

For more information on how to configure class of service, see the Junos Class of Service Configuration Guide.

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

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

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