Implementation
Basic Implementation
A label edge router (LER) of a DiffServ domain sorts traffic into a small number of classes and marks class information in the Differentiated Service Code Point (DSCP) field of packets. When scheduling and forwarding packets, LSRs select Per-Hop Behaviors (PHBs) based on DSCP values.
The EXP field in the MPLS header carries DiffServ information. The key to implementing DS-TE is to map the DSCP value (with a maximum of 64 values) to the EXP field (with a maximum of 8 values). Relevant standards provide the following solutions:
- Label-Only-Inferred-PSC LSP (L-LSP): The discard priority is set in the EXP field, and the PHB type is determined by labels. During forwarding, labels determine the datagram forwarding path and allocate scheduling behaviors.
- EXP-Inferred-PSC LSP (E-LSP): The PHB type and the discard priority are set in the EXP field in an MPLS label. During forwarding, labels determine the datagram forwarding path, and the EXP field determines PHBs. E-LSPs are applicable to a network that supports no more than eight PHBs.
The NetEngine 8000 F supports E-LSPs. The mapping from the DSCP value to the EXP field complies with relevant standards. The mapping from the EXP field to the PHB is manually configured.
The class type (CT) is used in DS-TE to allocate resources based on the class of traffic. DS-TE maps traffic with the same PHB to one CT and allocates resources to each CT. Therefore, DS-TE LSPs are established based on CTs. Specifically, when DS-TE calculates an LSP, it needs to take CTs and obtainable bandwidth of each CT as constraints; when DS-TE reserves resources, it also needs to consider CTs and their bandwidth requirements.
IGP Extension
To support DS-TE, related standards extend an IGP by introducing an optional sub-TLV (Bandwidth Constraints sub-TLV) and redefining the original sub-TLV (Unreserved Bandwidth sub-TLV). This helps inform and collect information about reservable bandwidths of CTs with different priorities.
RSVP Extension
To implement IETF DS-TE, the IETF extends RSVP by defining a CLASSTYPE object for the Path message in related standards. For details about CLASSTYPE objects, see related standards.
After an LSR along an LSP receives an RSVP Path message carrying CT information, an LSP is established if resources are sufficient. After the LSP is successfully established, the LSR recalculates the reservable bandwidth of CTs with different priorities. The reservation information is sent to the IGP module to advertise to other nodes on the network.
BCM
Currently, the IETF defines the following bandwidth constraint models (BCMs):
Maximum Allocation Model (MAM): maps a BC to a CT. CTs do not share bandwidth resources. The BC mode ID of the MAM is 1.
Figure 1 MAM
In the MAM, the sum of CTi LSP bandwidths does not exceed BCi (0≤ i ≤7) bandwidth; the sum of bandwidths of all LSPs of all CTs does not exceed the maximum reservable bandwidth of the link.
Assume that a link with the bandwidth of 100 Mbit/s adopts the MAM and supports three CTs (CT0, CT1, and CT2). BC0 (20 Mbit/s) carries CT0 (BE flows); BC1 (50 Mbit/s) carries CT1 (AF flows); BC2 (30 Mbit/s) carries CT2 (EF flows). In this case, the total reserved LSP bandwidths that are used to transmit BE flows cannot exceed 20 Mbit/s; the total reserved LSP bandwidths that are used to transmit AF flows cannot exceed 50 Mbit/s; the total reserved LSP bandwidths that are used to transmit EF flows cannot exceed 30 Mbit/s.
In the MAM, bandwidth preemption between CTs does not occur but some bandwidth resources may be wasted.
Russian Dolls Model (RDM): allows CTs to share bandwidth resources. The BC mode ID of the RDM is 0.
The bandwidth of BC0 is less than or equal to maximum reservable bandwidth of the link. Nesting relationships exist among BCs. As shown in Figure 2, the bandwidth of BC7 is fixed; the bandwidth of BC6 nests the bandwidth of BC7; this relationship applies to the other BCs, and therefore the bandwidth of BC0 nests the bandwidth of all BCs. This model is similar to a Russian doll: A large doll nests a smaller doll and then this smaller doll nests a much smaller doll, and so on.
Assume that a link with the bandwidth of 100 Mbit/s adopts the RDM and supports three BCs. CT0, CT1, and CT2 are used to transmit BE flows, AF flows, and EF flows, respectively. The bandwidths of BC0, BC1, and BC2 are 100 Mbit/s, 50 Mbit/s, and 20 Mbit/s, respectively. In this case, the total LSP bandwidths that are used to transmit EF flows cannot exceed 20 Mbit/s; the total LSP bandwidths that are used to transmit EF flows and AF flows cannot exceed 50 Mbit/s; the total LSP bandwidths that are used to transmit BE, AF, and EF flows cannot exceed 100 Mbit/s.
The RDM allows bandwidth preemption among CTs. The preemption relationship among CTs is as follows: In the case of 0 ≤ m < n ≤7 and 0 ≤ i < j ≤ 7, CTi with the priority being m can preempt the bandwidth of CTi with priority n and the bandwidth of CTj with priority n. The total LSP bandwidths of CTi, however, cannot exceed the bandwidth of BCi.
In the RDM, bandwidth resources are used efficiently.
Differences Between the IETF Mode and Non-IETF Mode
If bandwidth constraints or CT or CT reserved bandwidth is configured for a tunnel, the IETF and non-IETF modes cannot be switched to each other.
DS-TE Mode |
Non-IETF Mode |
IETF Mode |
|---|---|---|
Bandwidth model |
N/A |
Supports the RDM and MAM. |
CT type |
Supports CT0. |
Supports CT0 through CT7. |
BC type |
Supports BC0. |
Supports BC0 through BC7. |
TE-class mapping table |
The TE-class mapping table can be configured but does not take effect. |
The TE-class mapping table can be configured and takes effect. |
IGP message |
The priority-based reservable bandwidth is carried in the Unreserved Bandwidth sub-TLV. |
The CT information is carried in the Unreserved Bandwidth sub-TLV and Bandwidth Constraints sub-TLV.
|
RSVP message |
The CT information is carried in the ADSPEC object. |
CT information is carried in the CLASSTYPE object. |