2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models
2.1. Label Forwarding Model for Diff-Serv LSRs
Since different Ordered Aggregates of a given FEC may be transported over different LSPs, the label swapping decision of a Diff-Serv LSR clearly depends on the forwarded packet's Behavior Aggregate. Also, since the IP DS field of a forwarded packet may not be directly visible to an LSR, the way to determine the PHB to be applied to a received packet and to encode the PHB into a transmitted packet, is different than a non-MPLS Diff-Serv Router.
Thus, in order to describe Label Forwarding by Diff-Serv LSRs, we model the LSR Diff-Serv label switching behavior, comprised of four stages:
-
Incoming PHB Determination (A)
-
Outgoing PHB Determination with Optional Traffic Conditioning(B)
-
Label Forwarding (C)
-
Encoding of Diff-Serv information into Encapsulation Layer (EXP, CLP, DE, User_Priority) (D)
Each stage is described in more detail in the following sections.
Obviously, to enforce the Diff-Serv service differentiation the LSR MUST also apply the forwarding treatment corresponding to the Outgoing PHB.
This model is illustrated below:
--Inc_label(s)(*)------------------------>I===I--Outg_label(s)(&)-->
\ I I \
\---->I===I I C I \-->I===I--Encaps->
I A I I===I--Outg_PHB->I===I I D I (&)
-Encaps->I===I--Inc_PHB->I B I \ /->I===I
(*) I===I \--------+
\----Forwarding-->
Treatment
(PHB)
"Encaps" designates the Diff-Serv related information encoded in the MPLS Encapsulation layer (e.g., EXP field, ATM CLP, Frame Relay DE, 802.1 User_Priority)
(*) when the LSR behaves as an MPLS ingress node, the incoming packet may be received unlabelled.
(&) when the LSR behaves as an MPLS egress node, the outgoing packet may be transmitted unlabelled.
This model is presented here to describe the functional operations of Diff-Serv LSRs and does not constrain actual implementation.
2.2. Incoming PHB Determination
This stage determines which Behavior Aggregate the received packet belongs to.
2.2.1. Incoming PHB Determination Considering a Label Stack Entry
Sections 3.3 and 4.3 provide the details on how to perform incoming PHB Determination considering a given received label stack entry and/or received incoming MPLS encapsulation information depending on the incoming LSP type and depending on the incoming MPLS encapsulation.
Section 2.6 provides the details of which label stack entry to consider for the Incoming PHB Determination depending on the supported Diff-Serv tunneling mode.
2.2.2. Incoming PHB Determination Considering IP Header
Section 2.6 provides the details of when the IP Header is to be considered for incoming PHB determination, depending on the supported Diff-Serv tunneling model. In those cases where the IP header is to be used, this stage operates exactly as with a non-MPLS IP Diff-Serv Router and uses the DS field to determine the incoming PHB.
2.3. Outgoing PHB Determination With Optional Traffic Conditioning
The traffic conditioning stage is optional and may be used on an LSR to perform traffic conditioning including Behavior Aggregate demotion or promotion. It is outside the scope of this specification. For the purpose of specifying Diff-Serv over MPLS forwarding, we simply note that the PHB to be actually enforced and conveyed to downstream LSRs by an LSR (referred to as "outgoing PHB"), may be different to the PHB which had been associated with the packet by the previous LSR (referred to as "incoming PHB").
When the traffic conditioning stage is not present, the "outgoing PHB" is simply identical to the "incoming PHB".
2.4. Label Forwarding
- [MPLS_ARCH] describes how label swapping is performed by LSRs on incoming labeled packets using an Incoming Label Map (ILM), where each incoming label is mapped to one or multiple NHLFEs. [MPLS_ARCH] also describes how label imposition is performed by LSRs on incoming unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each incoming FEC is mapped to one or multiple NHLFEs.
A Diff-Serv Context for a label is comprised of:
-
`LSP type (i.e., E-LSP or L-LSP)'
-
`supported PHBs'
-
`Encaps-->PHB mapping' for an incoming label
-
`Set of PHB-->Encaps mappings' for an outgoing label
The present specification defines that a Diff-Serv Context is stored in the ILM for each incoming label.
- [MPLS_ARCH] states that the `NHLFE may also contain any other information needed in order to properly dispose of the packet'. In accordance with this, the present specification defines that a Diff-Serv Context is stored in the NHLFE for each outgoing label that is swapped or pushed.
This Diff-Serv Context information is populated into the ILM and the FTN at label establishment time.
If the label corresponds to an E-LSP for which no EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the supported PHBs' is populated with the set of PHBs of 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 supported PHBs' is populated with the set of PHBs of the signaled `EXP<-->PHB mapping'.
If the label corresponds to an L-LSP, the `supported PHBs' is populated with the set of PHBs forming the PSC that is signaled at LSP set-up.
The details of how the Encaps-->PHB mapping' or Set of PHB-->Encaps mappings' are populated are defined below in sections 3 and 4.
- [MPLS_ARCH] also states that:
"If the ILM [respectively, FTN] maps a particular label to a set of NHLFEs that contain more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM [respectively, FTN] map a label [respectively, a FEC] to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths."
In accordance with this, the present specification allows that an incoming label [respectively FEC] may be mapped, for Diff-Serv purposes, to multiple NHLFEs (for instance where different NHLFEs correspond to egress labels supporting different sets of PHBs). When a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv LSR MUST choose one of the NHLFEs whose Diff-Serv Context indicates that it supports the Outgoing PHB of the forwarded packet.
When a label [respectively FEC] maps to multiple NHLFEs which support the Outgoing PHB, the procedure for choosing one among those is outside the scope of this document. This situation may be encountered where it is desired to do load balancing of a Behavior Aggregate over multiple LSPs. In such situations, in order to respect ordering constraints, all packets of a given microflow MUST be transported over the same LSP.
2.5. Encoding Diff-Serv Information Into Encapsulation Layer
This stage determines how to encode the fields which convey Diff-Serv information in the transmitted packet (e.g., MPLS Shim EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority).
2.5.1. Encoding Diff-Serv Information Into Transmitted Label Entry
Sections 3.5 and 4.5 provide the details on how to perform Diff-Serv information encoding into a given transmitted label stack entry and/or transmitted MPLS encapsulation information depending on the corresponding outgoing LSP type and depending on the MPLS encapsulation.
Section 2.6 provides the details in which label stack entry to perform Diff-Serv information encoding into depending on the supported Diff-Serv tunneling mode.
2.5.2. Encoding Diff-Serv Information Into Transmitted IP Header
To perform Diff-Serv Information Encoding into the transmitted packet IP header, this stage operates exactly as with a non-MPLS IP Diff-Serv Router and encodes the DSCP of the Outgoing PHB into the DS field.
Section 2.6 provides the details of when Diff-Serv Information Encoding is to be performed into transmitted IP header depending on the supported Diff-Serv tunneling mode.
2.6. Diff-Serv Tunneling Models over MPLS
2.6.1. Diff-Serv Tunneling Models
- [DIFF_TUNNEL] considers the interaction of Differentiated Services with IP tunnels of various forms. MPLS LSPs are not a form of "IP tunnels" since the MPLS encapsulating header does not contain an IP header and thus MPLS LSPs are not considered in [DIFF_TUNNEL]. However, although not a form of "IP tunnel", MPLS LSPs are a form of "tunnel".
From the Diff-Serv standpoint, LSPs share a number of common characteristics with IP Tunnels:
-
Intermediate nodes (i.e., Nodes somewhere along the LSP span) only see and operate on the "outer" Diff-Serv information.
-
LSPs are unidirectional.
-
The "outer" Diff-Serv information can be modified at any of the intermediate nodes.
However, from the Diff-Serv standpoint, LSPs also have a distinctive property compared to IP Tunnels:
- There is generally no behavior analogous to Penultimate Hop Popping (PHP) used with IP Tunnels. Furthermore, PHP results in the "outer" Diff-Serv information associated with the LSP not being visible to the LSP egress. In situations where this information is not meaningful at the LSP Egress, this is obviously not an issue at all. In situations where this information is meaningful at the LSP Egress, then it must somehow be carried in some other means.
The two conceptual models for Diff-Serv tunneling over IP Tunnels defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv over MPLS but their respective detailed operations is somewhat different over MPLS. These two models are the Pipe Model and the Uniform Model. Their operations over MPLS are specified in the following sections. Discussion and definition of alternative tunneling models are outside the scope of this specification.
2.6.2. Pipe Model
With the Pipe Model, MPLS tunnels (aka LSPs) are used to hide the intermediate MPLS nodes between LSP Ingress and Egress from the Diff-Serv perspective.
In this model, tunneled packets must convey two meaningful pieces of Diff-Serv information:
-
the Diff-Serv information which is meaningful to intermediate nodes along the LSP span including the LSP Egress (which we refer to as the "LSP Diff-Serv Information"). This LSP Diff-Serv Information is not meaningful beyond the LSP Egress: Whether Traffic Conditioning at intermediate nodes on the LSP span affects the LSP Diff-Serv information or not, this updated Diff-Serv information is not considered meaningful beyond the LSP Egress and is ignored.
-
the Diff-Serv information which is meaningful beyond the LSP Egress (which we refer to as the "Tunneled Diff-Serv Information"). This information is to be conveyed by the LSP Ingress to the LSP Egress. This Diff-Serv information is not meaningful to the intermediate nodes on the LSP span.
Operation of the Pipe Model without PHP is illustrated below:
========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E (M*)
(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" (*) The LSP Egress considers the LSP Diff-Serv information received in the outer header (i.e., before the pop) in order to apply its Diff-Serv forwarding treatment (i.e., actual PHB) I represents the LSP ingress node E represents the LSP egress node
With the Pipe Model, the "LSP Diff-Serv Information" needs to be conveyed to the LSP Egress so that it applies its forwarding treatment based on it. The "Tunneled Diff-Serv information" also needs to be conveyed to the LSP Egress so it can be conveyed further downstream.
Since both require that Diff-Serv information be conveyed to the LSP Egress, the Pipe Model operates only without PHP.
The Pipe Model is particularly appropriate for environments in which:
-
the cloud upstream of the incoming interface of the LSP Ingress and the cloud downstream of the outgoing interface of the LSP Egress are in Diff-Serv domains which use a common set of Diff-Serv service provisioning policies and PHB definitions, while the LSP spans one (or more) Diff-Serv domain(s) which use(s) a different set of Diff-Serv service provisioning policies and PHB definitions
-
the outgoing interface of the LSP Egress is in the (last) Diff-Serv domain spanned by the LSP.
As an example, consider the case where a service provider is offering an MPLS VPN service (see [MPLS_VPN] for an example of MPLS VPN architecture) including Diff-Serv differentiation. Say that a collection of sites is interconnected via such an MPLS VPN service. Now say that this collection of sites is managed under a common administration and is also supporting Diff-Serv service differentiation. If the VPN site administration and the Service Provider are not sharing the exact same Diff-Serv policy (for instance not supporting the same number of PHBs), then operation of Diff-Serv in the Pipe Model over the MPLS VPN service would allow the VPN Sites Diff-Serv policy to operate consistently throughout the ingress VPN Site and Egress VPN Site and transparently over the Service Provider Diff-Serv domain. It may be useful to view such LSPs as linking the Diff-Serv domains at their endpoints into a single Diff-Serv region by making these endpoints virtually contiguous even though they may be physically separated by intermediate network nodes.
The Pipe Model MUST be supported.
For support of the Pipe Model over a given LSP without PHP, an LSR performs the Incoming PHB Determination and the Diff-Serv information Encoding in the following manner:
-
when receiving an unlabelled packet, the LSR performs Incoming PHB Determination considering the received IP Header.
-
when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination BEFORE the pop.
-
when performing a push operation for the considered LSP, the LSR:
-
encodes Diff-Serv Information corresponding to the OUTGOING PHB in the transmitted label entry corresponding to the pushed label.
-
encodes Diff-Serv Information corresponding to the INCOMING PHB in the encapsulated header (swapped label entry or IP header).
-
-
when performing a swap-only operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry that contains the swapped label
-
when performing a pop operation for the considered LSP, the LSR does not perform Encoding of Diff-Serv Information into the header exposed by the pop operation (i.e., the LSR leaves the exposed header "as is").
2.6.2.1. Short Pipe Model
The Short Pipe Model is an optional variation of the Pipe Model described above. The only difference is that, with the Short Pipe Model, the Diff-Serv forwarding treatment at the LSP Egress is applied based on the "Tunneled Diff-Serv Information" (i.e., Diff-Serv information conveyed in the encapsulated header) rather than on the "LSP Diff-Serv information" (i.e., Diff-Serv information conveyed in the encapsulating header).
Operation of the Short Pipe Model without PHP is illustrated below:
========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E
(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" I represents the LSP ingress node E represents the LSP egress node
Since the LSP Egress applies its forwarding treatment based on the "Tunneled Diff-Serv Information", the "LSP Diff-Serv information" does not need to be conveyed by the penultimate node to the LSP Egress. Thus the Short Pipe Model can also operate with PHP.
Operation of the Short Pipe Model with PHP is illustrated below:
=========== LSP ============================>
---Swap--(M)--...--Swap------
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).............Pop-(m)--E--(m)-->
I (inner header) P (M*)
(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" (*) The Penultimate LSR considers the LSP Diff-Serv information received in the outer header (i.e., before the pop) in order to apply its Diff-Serv forwarding treatment (i.e., actual PHB) I represents the LSP ingress node P represents the LSP penultimate node E represents the LSP egress node
The Short Pipe Model is particularly appropriate for environments in which:
-
the cloud upstream of the incoming interface of the LSP Ingress and the cloud downstream of the outgoing interface of the LSP Egress are in Diff-Serv domains which use a common set of Diff-Serv service provisioning policies and PHB definitions, while the LSP spans one (or more) Diff-Serv domain(s) which use(s) a different set of Diff-Serv service provisioning policies and PHB definitions
-
the outgoing interface of the LSP Egress is in the same Diff-Serv domain as the cloud downstream of it.
Since each outgoing interface of the LSP Egress is in the same Diff-Serv domain as the cloud downstream of it, each outgoing interface may potentially be in a different Diff-Serv domain, and the LSP Egress needs to be configured with awareness of every corresponding Diff-Serv policy. This operational overhead is justified in some situations where the respective downstream Diff-Serv policies are better suited to offering service differentiation over each egress interface than the common Diff-Serv policy used on the LSP span. An example of such a situation is where a Service Provider offers an MPLS VPN service and where some VPN users request that their own VPN Diff-Serv policy be applied to control service differentiation on the dedicated link from the LSP Egress to the destination VPN site, rather than the Service Provider's Diff-Serv policy.
The Short Pipe Model MAY be supported.
For support of the Short Pipe Model over a given LSP without PHP, an LSR performs the Incoming PHB Determination and the Diff-Serv information Encoding in the same manner as with the Pipe Model with the following exception:
- when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the header (label entry or IP header) which is used to do the actual forwarding. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination AFTER the pop.
For support of the Short Pipe Model over a given LSP with PHP, an LSR performs Incoming PHB Determination and Diff-Serv information Encoding in the same manner as without PHP with the following exceptions:
- the Penultimate LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In other words, when a pop operation is to be performed for the considered LSP, the Penultimate LSR performs Incoming PHB Determination BEFORE the pop.
Note that the behavior of the Penultimate LSR in the Short Pipe Mode with PHP, is identical to the behavior of the LSP Egress in the Pipe Mode (necessarily without PHP).
2.6.3. Uniform Model
With the Uniform Model, MPLS tunnels (aka LSPs) are viewed as artifacts of the end-to-end path from the Diff-Serv standpoint. MPLS Tunnels may be used for forwarding purposes but have no significant impact on Diff-Serv. In this model, any packet contains exactly one piece of Diff-Serv information which is meaningful and is always encoded in the outer most label entry (or in the IP DSCP where the IP packet is transmitted unlabelled for instance at the egress of the LSP). Any Diff-Serv information encoded somewhere else (e.g., in deeper label entries) is of no significance to intermediate nodes or to the tunnel egress and is ignored. If Traffic Conditioning at intermediate nodes on the LSP span affects the "outer" Diff-Serv information, the updated Diff-Serv information is the one considered meaningful at the egress of the LSP.
Operation of the Uniform Model without PHP is illustrated below:
========== LSP =============================>
---Swap--(M)--...-Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(M)--Push...............(x).......................Pop--(M)->
I (inner header) E
(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node E represents the LSP egress node
Operation of the Uniform Model with PHP is illustrated below:
========== LSP =========================>
---Swap-(M)-...-Swap------
/ (outer header) \
(M) (M)
/ \
>--(M)--Push..............(x)............Pop-(M)--E--(M)->
I (inner header) P
(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node P represents the LSP penultimate node E represents the LSP egress node
The Uniform Model for Diff-Serv over MPLS is such that, from the Diff-Serv perspective, operations are exactly identical to the operations if MPLS was not used. In other words, MPLS is entirely transparent to the Diff-Serv operations.
Use of the Uniform Model allows LSPs to span Diff-Serv domain boundaries without any other measure in place than an inter-domain Traffic Conditioning Agreement at the physical boundary between the Diff-Serv domains and operating exclusively on the "outer" header, since the meaningful Diff-Serv information is always visible and modifiable in the outmost label entry.
The Uniform Model MAY be supported.
For support of the Uniform Model over a given LSP, an LSR performs Incoming PHB Determination and Diff-Serv information Encoding in the following manner:
-
when receiving an unlabelled packet, the LSR performs Incoming PHB Determination considering the received IP Header.
-
when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination BEFORE the pop.
-
when performing a push operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry corresponding to the pushed label. The Diff-Serv Information encoded in the encapsulated header (swapped label entry or IP Header) is of no importance.
-
when performing a swap-only operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry that contains the swapped label.
-
when PHP is used, the Penultimate LSR needs to be aware of the "Set of PHB-->Encaps mappings" for the label corresponding to the exposed header (or the `PHB-->DSCP mapping') in order to perform Diff-Serv Information Encoding. Methods for providing this mapping awareness are outside the scope of this specification. As an example, the "PHB-->DSCP mapping" may be locally configured. As another example, in some environments, it may be appropriate for the Penultimate LSR to assume that the "Set of PHB-->Encaps mappings" to be used for the outgoing label in the exposed header is the "Set of PHB-->Encaps mappings" that would be used by the LSR if the LSR was not doing PHP. Note also that this specification assumes that the Penultimate LSR does not perform label swapping over the label entry exposed by the pop operation (and in fact that it does not even look at the exposed label). Consequently, restrictions may apply to the Diff-Serv Information Encoding that can be performed by the Penultimate LSR. For example, this specification does not allow situations where the Penultimate LSR pops a label corresponding to an E-LSP supporting two PSCs, while the header exposed by the pop contains label values for two L-LSPs each supporting one PSC, since the Diff-Serv Information Encoding would require selecting one label or the other.
Note that LSR behaviors for the Pipe, the Short Pipe and the Uniform Model only differ when doing a push or a pop. Thus, Intermediate LSRs which perform swap only operations for an LSP, behave in exactly the same way, regardless of whether they are behaving in the Pipe, Short Pipe or the Uniform model. With a Diff-Serv implementation supporting multiple Tunneling Models, only LSRs behaving as LSP Ingress, Penultimate LSR or LSP Egress need to be configured to operate in a particular Model. Signaling to associate a Diff-Serv tunneling model on a per-LSP basis is not within the scope of this specification.
2.6.4. Hierarchy
Through the label stack mechanism, MPLS allows LSP tunneling to nest to any depth. We observe that with such nesting, the push of level N+1 takes place on a subsequent (or the same) LSR to the LSR doing the push for level N, while the pop of level N+1 takes place on a previous (or the same) LSR to the LSR doing the pop of level N. For a given level N LSP, the Ingress LSR doing the push and the LSR doing the pop (Penultimate LSR or LSP Egress) must operate in the same Tunneling Model (i.e., Pipe, Short Pipe or Uniform). However, there is no requirement for consistent tunneling models across levels so that LSPs at different levels may be operating in different Tunneling Models.
Hierarchical operations are illustrated below in the case of two levels of tunnels:
+--------Swap--...---+
/ (outmost header) \
/ \
Push(2).................(2)Pop
/ (outer header) \
/ \
>>---Push(1)........................(1)Pop-->>
(inner header)
(1) Tunneling Model 1 (2) Tunneling Model 2
Tunneling Model 2 may be the same as or may be different from Tunneling Model 1.
For a given LSP of level N, the LSR must perform the Incoming PHB Determination and the Diff-Serv information Encoding as specified in section 2.6.2, 2.6.2.1 and 2.6.3 according to the Tunneling Model of this level N LSP and independently of the Tunneling Model of other level LSPs.