Skip to main content

3. Detailed Operations of E-LSPs

3.1. E-LSP Definition​

E-LSPs are defined in section 1.2.

Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the pre-configured mapping are capable of transporting the same common set of 8, or fewer, BAs. Each of those E-LSPs may actually transport this full set of BAs or any arbitrary subset of it.

For a given FEC, two given E-LSPs using a signaled `EXP<-->PHB mapping' can support the same or different sets of Ordered Aggregates.

3.2. Populating the `Encaps-->PHB mapping' for an incoming E-LSP​

This section defines how the `Encaps-->PHB mapping' of the Diff-Serv Context is populated for an incoming E-LSP in order to allow Incoming PHB determination.

The Encaps-->PHB mapping' for an E-LSP is always of the form EXP-->PHB mapping'.

If the label corresponds to an E-LSP for which no EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the EXP-->PHB mapping' is populated based on the Preconfigured `EXP<-->PHB mapping' which is discussed below in section 3.2.1.

If the label corresponds to an E-LSP for which an EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the EXP-->PHB mapping' is populated as per the signaled `EXP<-->PHB mapping'.

3.2.1. Preconfigured `EXP<-->PHB mapping'​

LSRs supporting E-LSPs which use the preconfigured EXP<-->PHB mapping' must allow local configuration of this EXP<-->PHB mapping'. This mapping applies to all the E-LSPs established on this LSR without a mapping explicitly signaled at set-up time.

The preconfigured `EXP<-->PHB mapping' must either be consistent at every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the LSP or appropriate remarking of the EXP field must be performed by the LSR whenever a different preconfigured mapping is used on the ingress and egress interfaces.

In case, the preconfigured EXP<-->PHB mapping' has not actually been configured by the Network Administrator, the LSR should use a default preconfigured EXP<-->PHB mapping' which maps all EXP values to the Default PHB.

3.3. Incoming PHB Determination On Incoming E-LSP​

This section defines how Incoming PHB Determination is carried out when the considered label entry in the received label stack corresponds to an E-LSP. This requires that the `Encaps-->PHB mapping' is populated as defined in section 3.2.

When considering a label entry corresponding to an incoming E-LSP for Incoming PHB Determination, the LSR:

  • determines the EXP-->PHB mapping' by looking up the Encaps-->PHB mapping' of the Diff-Serv Context associated in the ILM with the considered incoming E-LSP label.

  • determines the incoming PHB by looking up the EXP field of the considered label entry in the `EXP-->PHB mapping' table.

3.4. Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP​

This section defines how the `Set of PHB-->Encaps mappings' of the Diff-Serv Context is populated at label setup for an outgoing E-LSP in order to allow Encoding of Diff-Serv information in the Encapsulation Layer.

3.4.1. `PHB-->EXP mapping'​

An outgoing E-LSP must always have a PHB-->EXP mapping' as part of the Set of PHB-->Encaps mappings' of its Diff-Serv Context.

If the label corresponds to an E-LSP for which no EXP<-->PHB mapping' has been explicitly signaled at LSP setup, this PHB-->EXP mapping' is populated based on the Preconfigured `EXP<-->PHB mapping' which is discussed above in section 3.2.1.

If the label corresponds to an E-LSP for which an EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the PHB-->EXP mapping' is populated as per the signaled `EXP<-->PHB mapping'.

3.4.2. `PHB-->CLP mapping'​

If the LSP is egressing over an ATM interface which is not label switching controlled, then one PHB-->CLP mapping' is added to the Set of PHB-->Encaps mappings' for this outgoing LSP. This `PHB-->CLP mapping' is populated in the following way:

  • it is a function of the PHBs supported on this LSP, and may use the relevant mapping entries for these PHBs from the Default `PHB-->CLP mapping' defined in section 3.4.2.1. Mappings other than the one defined in section 3.4.2.1 may be used. In particular, if a mapping from PHBs to CLP is standardized in the future for operations of Diff-Serv over ATM, such a standardized mapping may then be used.

For example if the outgoing label corresponds to an LSP supporting the AF1 PSC, then the `PHB-->CLP mapping' may be populated with:

         PHB                CLP Field

         AF11       ---->      0
         AF12       ---->      1
         AF13       ---->      1
         EF         ---->      0

Notice that in this case the Set of PHB-->Encaps mappings' contains both a PHB-->EXP mapping' and a `PHB-->CLP mapping'.

3.4.2.1. Default `PHB-->CLP mapping'​

         PHB                CLP Bit

         DF         ---->      0
         CSn        ---->      0
         AFn1       ---->      0
         AFn2       ---->      1
         AFn3       ---->      1
         EF         ---->      0

3.4.3. `PHB-->DE mapping'​

If the LSP is egressing over a Frame Relay interface which is not label switching controlled, one PHB-->DE mapping' is added to the Set of PHB-->Encaps mappings' for this outgoing LSP and is populated in the following way:

  • it is a function of the PHBs supported on this LSP, and may use the relevant mapping entries for these PHBs from the Default `PHB-->DE mapping' defined in section 3.4.3.1. Mappings other than the one defined in section 3.4.3.1 may be used. In particular, if a mapping from PHBs to DE is standardized in the future for operations of Diff-Serv over Frame Relay, such a standardized mapping may then be used.

Notice that in this case the Set of PHB-->Encaps mappings' contains both a PHB-->EXP mapping' and a `PHB-->DE mapping'.

3.4.3.1. `Default PHB-->DE mapping'​

         PHB                 DE Bit

          DF       ---->       0
          CSn      ---->       0
          AFn1     ---->       0
          AFn2     ---->       1
          AFn3     ---->       1
          EF       ---->       0

3.4.4. `PHB-->802.1 mapping'​

If the LSP is egressing over a LAN interface on which multiple 802.1 Traffic Classes are supported as per [IEEE_802.1], then one PHB-->802.1 mapping' is added to the Set of PHB-->Encaps mappings' for this outgoing LSP. This `PHB-->802.1 mapping' is populated in the following way:

  • it is a function of the PHBs supported on this LSP, and uses the relevant mapping entries for these PHBs from the Preconfigured `PHB-->802.1 mapping' defined in section 3.4.4.1.

Notice that the Set of PHB-->Encaps mappings' then contains both a PHB-->EXP mapping' and a `PHB-->802.1 mapping'.

3.4.4.1. Preconfigured `PHB-->802.1 Mapping'​

At the time of producing this specification, there are no standardized mapping from PHBs to 802.1 Traffic Classes. Consequently, an LSR supporting multiple 802.1 Traffic Classes over LAN interfaces must allow local configuration of a `PHB-->802.1 mapping'. This mapping applies to all the outgoing LSPs established by the LSR on such LAN interfaces.

3.5. Encoding Diff-Serv information into Encapsulation Layer On Outgoing E-LSP​

This section defines how to encode Diff-Serv information into the MPLS encapsulation Layer for a given transmitted label entry corresponding to an outgoing E-LSP. This requires that the `Set of PHB-->Encaps mappings' be populated as defined in section 3.4.

The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the NHLFE.

3.5.1. `PHB-->EXP mapping'​

If the Set of PHB-->Encaps mappings' contains a mapping of the form PHB-->EXP mapping', then the LSR:

  • determines the value to be written in the EXP field of the corresponding level label entry by looking up the "outgoing PHB" in this `PHB-->EXP mapping' table.

3.5.2. `PHB-->CLP mapping'​

If the Set of PHB-->Encaps mappings' contains a mapping of the form PHB-->CLP mapping', then the LSR:

  • determines the value to be written in the CLP field of the ATM encapsulation header, by looking up the "outgoing PHB" in this `PHB-->CLP mapping' table.

3.5.3. `PHB-->DE mapping'​

If the Set of PHB-->Encaps mappings' contains a mapping of the form PHB-->DE mapping', then the LSR:

  • determines the value to be written in the DE field of the Frame Relay encapsulation header, by looking up the "outgoing PHB" in this `PHB-->DE mapping' table.

3.5.4. `PHB-->802.1 mapping'​

If the Set of PHB-->Encaps mappings' contains a mapping of the form PHB-->802.1 mapping', then the LSR:

  • determines the value to be written in the User_Priority field of the Tag Control Information of the 802.1 encapsulation header [IEEE_802.1], by looking up the "outgoing PHB" in this 'PHB-->802.1 mapping' table.

3.6. E-LSP Merging​

In an MPLS domain, two or more LSPs can be merged into one LSP at one LSR. E-LSPs are compatible with LSP Merging under the following condition:

E-LSPs can only be merged into one LSP if they support the exact same set of BAs.

For E-LSPs using a signaled `EXP<-->PHB mapping', the above merge condition MUST be enforced by LSRs through explicit checking at label setup that the exact same set of PHBs is supported on the merged LSPs.

For E-LSPs using the preconfigured EXP<-->PHB mapping', since the PHBs supported over an E-LSP is not signaled at establishment time, an LSR can not rely on signaling information to enforce the above merge. However all E-LSPs using the preconfigured EXP<-->PHB mapping' are required to support the same set of Behavior Aggregates within a given MPLS Diff-Serv domain. Thus, merging of E-LSPs using the preconfigured `EXP<-->PHB mapping' is allowed within a given MPLS Diff-Serv domain.