No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE20E-S2 V800R010C10SPC500 Feature Description - MPLS 01

This is NE20E-S2 V800R010C10SPC500 Feature Description - MPLS
Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Implementation

Implementation

Implementation

A label edge router (LER) of an MPLS DiffServ domain sorts traffic into a small number of classes and marks class information in the Differentiated Service CodePoint (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 number of 64 values) to the EXP field (with a maximum number of eight 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, MPLS labels determine an LSP of datagrams and allocate scheduling behaviors to packets.
  • EXP-Inferred-PSC LSP (E-LSP): The PHB type and the discard priority are set in the EXP field in the MPLS label. During forwarding, the label determines the LSP of datagrams, and the EXP field determines PHBs. E-LSPs are applicable to a network with up to eight PHBs.

On the NE20E, E-LSPs are implemented. The mapping from the DSCP value to the EXP field complies with the definition of 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 for each CT. Therefore, a DS-TE LSP is set up based on the CT. That is, when DS-TE calculates an LSP, it needs to take CTs and obtainable bandwidth of each CT as constraints; when DS-TE reserves resources for the LSRs along an LSP, it needs to consider CTs and their bandwidth requirements.

IGP Extension

To support DS-TE, related standards extend an IGP by introducing the optional bandwidth constraints sub-TLV and redefining the original unreserved bandwidth sub-TLV. This helps inform and collect information about reservable bandwidths of CTs with different priorities on the link.

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 messages carrying CT information, an LSP is established if resources are sufficient. After the LSP is successfully established, the LSR recalculates the reservable bandwidth of each CT mapped toS to each priority. The reserved information is sent to the IGP module to advertise to other LSRs on the network.

BCM

Currently, the IETF defines the following 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 4-42 MAM

    In the MAM, the sum of CTi LSP bandwidths does not exceed BCi (i ranges from 0 to 7); the sum of bandwidths of all LSPs of all CTs does not exceed the maximum reservable bandwidth of the link.

    For example, assume that a link with the bandwidth of 100 Mbit/s uses the MAM and supports three CTs (CT0, CT1, and CT2). For example, assume that on a link, the bandwidth is 100 Mbit/s and the MAM is adopted. BC0, which is 20 Mbit/s, carries CT0 (BE flows); BC1, which is 50 Mbit/s, carries CT1 (AF flows); BC2, which is 30 Mbit/s, carries CT2 (EF flows). In this case, the total LSP bandwidths that are used to transmit BE flows cannot exceed 20 Mbit/s; the total LSP bandwidth value that is used to transmit AF flows cannot exceed 50 Mbit/s; the total LSP bandwidth value that is 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): permits CTs to share bandwidth resources. The BC mode ID of the RDM is 0.

    The bandwidth of BC0 is smaller than the maximum reservable bandwidth on a link. Nesting relationships exist among BCs. In Figure 4-43, the bandwidth of BC7 is fixed; the bandwidth of BC6 nests the bandwidth of BC7...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.

    Figure 4-43 RDM

    For example, assume that a link with the bandwidth of 100 Mbit/s adopts the RDM and supports 3 BC (CT0, CT1, and CT2). CT0, CT1, and CT2 are used to transmit BE flows, AF flows, and EF flows, respectively. BC0 is 100 Mbit/s; BC1 is 50 Mbit/s; BC2 is 20 Mbit/s. 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, does not exceed the bandwidth of BCi.

    In the RDM, bandwidth resources are used effectively.

Differences Between the IETF Mode and Non-IETF Mode

The NE20E supports either the IETF or non-IETF mode. Table 4-14 describes differences between the automatic and manual creation modes.
NOTE:
If bandwidth constraints are configured for a tunnel, the IETF and non-IETF modes cannot be switched to each other.
Table 4-14 Differences between IETF and non-IETF modes

DS-TE Mode

Non-IETF Mode

IETF Mode

Bandwidth model

N/A

Supports the RDM, MAM.

CT type

CT0 is supported.

CT0 through CP7 are supported.

BC type

BC0 is supported.

BC0 through BC7 are supported.

TE-class mapping table

The TE-class mapping table can be configured but cannot take effect.

The TE-class mapping table can be configured and take 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.

  • Unreserved Bandwidth Sub-TLV: carries unreserved bandwidth of eight TE-classes. The sub-TLV unit is bytes/second.
  • Bandwidth Constraints sub-TLV: carries BCM model information and BC bandwidth in RDM and MAM.

RSVP message

The CT information is carried in the CLASSTYPE object.

Single-CT: CT information is carried in the CLASSTYPE object.

Translation
Download
Updated: 2019-01-02

Document ID: EDOC1100055471

Views: 7195

Downloads: 6

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next