HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 05:34:49 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 04 Feb 2000 17:07:26 GMT ETag: "2e6a47-1bcdf-389b074e" Accept-Ranges: bytes Content-Length: 113887 Connection: close Content-Type: text/plain Francois Le Faucheur Liwen Wu Bruce Davie Cisco Systems Shahram Davari PMC-Sierra Inc. Pasi Vaananen Nokia Ram Krishnan Nexabit Networks Pierrick Cheval Alcatel Juha Heinanen Telia Finland IETF Internet Draft Expires: October, 2000 Document: draft-ietf-mpls-diff-ext-03.txt February, 2000 MPLS Support of Differentiated Services Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are Working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. Le Faucheur, et. al 1 MPLS Support of Diff-Serv February 00 This solution allows the MPLS network administrator to select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Paths so that he/she can best match the Diff-Serv, Traffic Engineering and Fast Restoration objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs. This solution relies on combined use of two types of LSPs: - LSPs which can transport multiple Ordered Aggregates, so that the EXP field of the MPLS Shim Header conveys to the LSR the PHB to be applied to the packet (covering both information about the packet's scheduling treatment and its drop precedence). - LSPs which only transport a single Ordered Aggregate, so that the packet's scheduling treatment is inferred by the LSR exclusively from the packet's label value while the packet's drop precedence is conveyed in the EXP field of the MPLS Shim Header or in the encapsulating link layer specific selective drop mechanism (ATM, Frame Relay, 802.1). 1. Introduction In an MPLS domain [MPLS_ARCH], when a stream of data traverses a common path, a Label Switched Path (LSP) can be established using MPLS signaling protocols. At the ingress Label Switch Router (LSR), each packet is assigned a label and is transmitted downstream. At each LSR along the LSP, the label is used to forward the packet to the next hop. In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the IP packets crossing a link and requiring the same Diff-Serv behavior are said to constitute a Behavior Aggregate (BA). At the ingress node of the Diff-Serv domain the packets are classified and marked with a Diff-Serv Code Point (DSCP) which corresponds to their Behavior Aggregate. At each transit node, the DSCP is used to select the Per Hop Behavior (PHB) that determines the scheduling treatment and, in some cases, drop probability for each packet. This document specifies a solution for supporting the Diff-Serv Behavior Aggregates whose corresponding PHBs are currently defined (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. This solution also offers flexibility for easy support of PHBs that may be defined in the future. As mentioned in [DIFF_HEADER], "Service providers are not required to use the same node mechanisms or configurations to enable service differentiation within their networks, and are free to configure the node parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives". Thus, the solution defined in this document gives Service Providers flexibility in selecting how Diff-Serv classes of service are Routed Le Faucheur et. al 2 MPLS Support of Diff-Serv February 00 or Traffic Engineered within their domain (eg. separate classes of services supported via separate LSPs and Routed separately, all classes of service supported on the same LSP and Routed together). Similarly, the solution gives Service Providers flexibility in how Diff-Serv classes of service can be protected via MPLS Fast Restoration (eg. some classes of service supported via LSPs which are protected via MPLS Fast Restoration while some other classes of service are supported via LSPs which are not protected). Beside, the solution specified in this document achieves label space conservation and reduces the volume of label set-up/tear-down signaling where possible by only resorting to multiple LSPs for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or required. This specification allows support of Differentiated Services for both IPv4 and IPv6 traffic transported over an MPLS network. This document only describes operations for unicast. Multicast support is for future study 1.1 Ordered Aggregate (OA) and PHB Scheduling Class (PSC) The Diff-Serv model defines [DIFF_NEW] the set of Behavior Aggregates which share an ordering constraint to constitute an "Ordered Aggregate (OA)". It also defines the set of one or more PHBs that are applied to this set of Behavior Aggregates to constitute a "PHB Scheduling Class (PSC)". 1.2 EXP-Inferred-PSC LSPs (E-LSP) A single LSP can be used to support up to eight BAs of a given FEC, regardless of how many OAs these BAs span. With such LSPs, the EXP field of the MPLS Shim Header [MPLS_ENCAPS] is used by the LSR to determine the PHB to be applied to the packet. This includes both the PSC and the drop preference. We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the PSC of a packet transported on this LSP depends on the EXP field value for that packet. The mapping from EXP field to PHB (ie to PSC and drop precedence) for a given such LSP, is either explicitly signaled at label set-up or relying on a pre-configured mapping. Detailed operations of E-LSPs are specified in section 3 below. 1.3 Label-Only-Inferred-PSC LSPs (L-LSP) A separate LSP can be established for a single pair. Le Faucheur et. al 3 MPLS Support of Diff-Serv February 00 With such LSPs, the PSC is explicitly signaled at label establishment time so that, after label establishment, the LSR can infer exclusively from the label value the PSC to be applied to a labeled packet. When the Shim Header is used, the Drop Precedence to be applied by the LSR to the labeled packet, is conveyed inside the labeled packet MPLS Shim Header using the EXP field [MPLS_ENCAPS]. When the Shim Header is not used (eg. MPLS Over ATM), the Drop Precedence to be applied by the LSR to the labeled packet is conveyed inside the link layer header encapsulation using link layer specific drop precedence fields (eg. ATM Cell Loss Priority). We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP) since the PSC can be fully inferred from the label without any other information (eg. regardless of the EXP field value). Detailed operations of L-LSPs are specified in section 4 below. 1.4 Overall Operations For a given FEC, and unless media specific restrictions apply as identified in the sections 7, 8, 9 and 10 below, this specification allows any one of the following combinations within an MPLS Diff- Serv domain: - zero or any number of E-LSPs, and - zero or any number of L-LSPs. The network administrator selects the actual combination of LSPs from the set of allowed combinations and selects how the Behavior Aggregates are actually transported over this combination of LSPs, in order to best match his/her environment and objectives in terms of Diff-Serv support, Traffic Engineering and Fast Restoration. Criteria for selecting such a combination are outside the scope of this specification; However in order to respect ordering constraints, all packets of a given microflow, possibly spanning multiple BAs of a given Ordered Aggregate, MUST be transported over the same LSP. Conversely, each LSP MUST be capable of supporting all the (active) PHBs of a given PSC. Examples of deployment scenarios are provided for information in APPENPIX A. 1.5 Relationship between Label and FEC [MPLS_ARCH] states in section `2.1. Overview' that: `Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label. In this case, one may say that the label represents the combination of a FEC and a precedence or class of service.' Le Faucheur et. al 4 MPLS Support of Diff-Serv February 00 In line with this, we observe that: - With E-LSPs, the label represents the combination of a FEC and the set of Behavior Aggregates (BAs) transported over the E- LSP). Where all the supported BAs are transported over an E-LSP, the label then represents the complete FEC. - With L-LSPs, the label represents the combination of a FEC and an Ordered Aggregate (OA). 2. 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 to a non-MPLS Diff-Serv Router. In order to describe Label Forwarding by Diff-Serv LSRs, we model the LSR Diff-Serv label switching behavior as comprising four stages: - Incoming PHB Determination (A) - Optional Outgoing PHB Determination via Local Policy and Traffic Conditioning (B) - Label Swapping (C) - Encoding of Diff-Serv information into Encapsulation Layer (EXP,CLP,DE,User_Priority) (D) 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(*)--------------------------->I===I---Outg_label (**)--> \ 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 \--------/ `Encaps' designates the Diff-Serv related information encoded in the MPLS Encapsulation layer (eg EXP field, ATM CLP, Frame Relay DE, 802.1 User_Priority) (*) when the LSR performs label imposition, the incoming packet is received unlabelled. Le Faucheur et. al 5 MPLS Support of Diff-Serv February 00 (**) when the LSR performs label disposition, the outgoing packet is transmitted unlabelled. This model is presented here to illustrate operations of Diff-Serv LSRs and does not constrain actual implementation. 2.1 Incoming PHB Determination This stage determines which Behavior Aggregate the received packet belongs to. 2.1.1 Incoming PHB Determination for received labelled packets This specification defines one default method for this determination which allows for regular support of Diff-Serv over MPLS. This method considers only the outer encapsulation (ie outer label entry or ATM encapsulation or Frame Relay encapsulation) and ignores other label entries which may be present in the stack. It combines: - the Diff-Serv context associated with the incoming label and stored in the Incoming Label Map (ILM). See section 2.3 below for details on information comprising the Diff-Serv context. - the Diff-Serv related information that is encoded in the corresponding encapsulation layer (ie in EXP field of MPLS Shim layer or in CLP/DE field of the link layer encapsulation) of the received label packet. The details of this method depend on the incoming LSP type and on the incoming MPLS encapsulation and are defined below in sections 3.3 and 4.3. Support for this default method is mandatory for compliance to this specification. Optionally, other methods for Incoming PHB Determination may also be supported. Other methods may take into account other information in addition to, or instead of, the information used by the mandatory method. For instance, other method could take into account the DS field of the encapsulated packet or the EXP field of a label header deeper in the label stack. Such methods are beyond the scope of this specification. 2.1.2 Incoming PHB Determination for received unlabelled packets For packets received unlabelled, this stage operates exactly as with a non-MPLS IP Diff-Serv Router and uses the DS field. 2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic Conditioning This stage of Diff-Serv label switching 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 Le Faucheur et. al 6 MPLS Support of Diff-Serv February 00 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 this stage is not present, the "outgoing PHB" is simply identical to the "incoming PHB". For packets received unlabelled, this stage operates as with a non- MPLS IP Diff-Serv Router. 2.3 Label Swapping [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 defined as comprising: - `LSP type (ie 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 which 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. Le Faucheur et. al 7 MPLS Support of Diff-Serv February 00 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 contains 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] is 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 supports 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.4 Encoding Diff-Serv information into Encapsulation Layer This stage determines how to encode the fields of the MPLS encapsulation layer which convey Diff-Serv information (eg MPLS Shim EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority). 2.4.1 Encoding Diff-Serv information for transmitted labeled packets This specification defines one default method for this encoding which allows regular support of Diff-Serv over MPLS. This method takes into account: - the Outgoing PHB - the Diff-Serv context associated with each swapped/pushed label of the selected NHLFE (`Set of PHB-->Encaps mappings'). This method defines that the Outgoing PHB is reflected into: - the EXP field value of all the swapped or pushed label entries - the CLP/DE bit when the packet is encapsulated into ATM/Frame Relay, - the 802.1 User_Priority field of the 802.1 Tag Control Information when the packet is encapsulated into LAN interfaces supporting multiple Traffic Classes, Le Faucheur et. al 8 MPLS Support of Diff-Serv February 00 The details of this method depend on the outgoing LSP type and on the outgoing MPLS encapsulation and are defined below in sections 3.5 and 4.5. Support for this default method is mandatory for compliance to this specification. Optionally, other methods for encoding Diff-Serv information into the Encapsulation layer may also be supported to allow for more sophisticated Diff-Serv operations over MPLS. Other methods may affect encapsulation fields differently. 2.4.2 Encoding Diff-Serv information for transmitted unlabelled packets This specification defines one default method for this encoding which allows regular support of Diff-Serv over MPLS. Support for this default method is mandatory for compliance to this specification. For packets transmitted unlabelled (ie LSR performing label disposition), the default encoding method writes the DSCP of the Outgoing PHB into the DS field. Optionally, other encoding methods may also be supported to allow for more sophisticated Diff-Serv operations over MPLS. Other methods may affect the DS field differently. One example would be a method where the IP packet's DS field is left unchanged regardless of the Outgoing PHB. Such a method would allow `MPLS Diff-Serv Transparency' ie it would allow support of Differentiated Services in the MPLS backbone based on a Diff-Serv policy which is specific to the MPLS cloud (and different from the Diff-Serv policy applied in the non-MPLS clouds around the MPLS cloud) since the IP DS field would be transported transparently through the MPLS cloud. Details of such methods are outside the scope of this specification. 3. Detailed Operations of E-LSPs 3.1 E-LSP Definition Recognizing that: - Certain MPLS encapsulations (such as PPP and LAN) make use of a Shim Header which consists of a label stack with one or more entries [MPLS_ENCAPS] each with a 3-bit EXP field; - the Differentiated-Service (DS) field is 6-bit long [DIFF_HEADER] potentially allowing support of up to 64 Behavior Aggregates Le Faucheur et. al 9 MPLS Support of Diff-Serv February 00 - any subset of 8 (or less) DSCP values can be mapped entirely into the 3-bit long EXP field of the MPLS label stack entry; We define that: - an LSP established for a given Forwarding Equivalent Class (FEC) may be used for transport of up to eight BAs of that FEC; - the set of transported BAs can span multiple OAs; - for a given OA transported over the LSP, all supported BAs of this OA are transported over the LSP; - such an LSP is referred to as an "EXP-inferred-PSC" LSP or "E-LSP" because the PSC to be applied to a labeled packet by the LSR depends on the EXP field value in the MPLS Shim Header; - packets belonging to this given (FEC) and from the corresponding set of BAs are sent down this E-LSP. - multiple BAs belonging to the same FEC and transported over the same E-LSP are granted different scheduling treatment and different drop precedence by the MPLS LSR based on the EXP field which is appropriately encoded to reflect both the PSC and the drop precedence of the PHB corresponding to the packet's BA. - the mapping between EXP field and PHB to be applied by the LSR for a given E-LSP is either explicitly signaled at label set-up or relies on a preconfigured mapping. 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 less, 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 signaled EXP<-->PHB mapping can support the same or different sets of Ordered Aggregates. For a given FEC, there may be more than one E-LSP carrying the same OA, for example for purposes of load balancing of the OA. In that case, in order to respect ordering constraints, all packets of a given microflow must be transported over the same LSP. MPLS specifies how LSPs can be established via multiple signaling protocols. Those include the Label Distribution Protocol (LDP), RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP are to be used for establishment of E-LSPs. 3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP Le Faucheur et. al 10 MPLS Support of Diff-Serv February 00 This section defines how the `Encaps-->PHB mapping' of the Diff-Serv context is populated for an incoming E-LSP in order to support the mandatory default method for Incoming PHB determination. The `Encaps-->PHB mapping' 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 uses 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. 3.3 Incoming PHB Determination On Incoming E-LSP This section defines the mandatory default method for Incoming PHB determination for a labeled packet received on an E-LSP. This method requires that the `Encaps-->PHB mapping' is populated as defined above in section 3.2. When receiving a labeled packet over an E-LSP of an MPLS ingress interface, the LSR: -determines the EXP-->PHB mapping by looking up the `Encaps-->PHB mapping' of the Diff-Serv context associated with the incoming label in the ILM. - determines the incoming PHB by looking up the EXP field of the top level label entry into the EXP-->PHB mapping table. If the EXP field value of a packet received on an E-LSP is not included in the EXP-->PHB mapping associated with this LSP, this EXP value should be considered invalid. LSR behavior in such situation is a local matter and is outside the scope of this document. 3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP Le Faucheur et. al 11 MPLS Support of Diff-Serv February 00 This section defines how the `Set of PHB-->Encaps mappings' of the Diff-Serv context is populated for an outgoing E-LSP in order to support the mandatory default method for Encoding of Diff-Serv information in the Encapsulation Layer. 3.4.1 `PHB-->EXP mapping' One `PHB-->EXP mapping' is always added to the `Set of PHB-->Encaps mappings' of the Diff-Serv context for an outgoing E-LSP. 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-->802.1 mapping' If the outgoing interface is a LAN interface on which multiple 802.1 Traffic Classes are supported as per [IEEE_802.1], one `PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings' of the Diff- Serv context for the outgoing E-LSP. This mapping is populated at label set-up based on the Preconfigured PHB-->802.1 mapping defined below in section 3.4.2.1. Notice that the `Set of PHB-->Encaps mappings' then contains both a `PHB-->EXP mapping' and a `PHB-->802.1 mapping'. 3.4.2.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 the mandatory default method for encoding of Diff-Serv related information into the MPLS encapsulation Layer to be used when a packet is transmitted onto an E-LSP. This method requires that the `Set of PHB-->Encaps mappings' is populated as defined above in section 3.4. The LSR first determines the `Set of PHB-->Encaps Mapping' associated with the outer label of the NHLFE. Le Faucheur et. al 12 MPLS Support of Diff-Serv February 00 3.5.1 `PHB-->EXP mapping' For all the labels which are swapped or pushed, the LSR: - determines the PHB-->EXP mapping by looking up the `Set of PHB-->Encaps mapping' of the Diff-Serv context associated with the corresponding label in the NHLFE. - 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-->802.1 mapping' If the `Set of PHB-->Encaps mapping' of the outer label 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 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. 4. Detailed Operation of L-LSPs 4.1 L-LSP Definition Recognizing that: - All currently defined MPLS encapsulation methods have a field of 3 bits or less for Diff-Serv encoding (i.e., 3-bit EXP field in Le Faucheur et. al 13 MPLS Support of Diff-Serv February 00 case of Shim Header and 1-bit CLP/DE bit in case of ATM/Frame Relay). - The Differentiated-Services (DS) field is 6-bit long [DIFF_HEADER] potentially allowing support of up to 64 Behavior Aggregates. So that when more than a certain number of BAs are used (i.e., more than 8 BAs in case of Shim Header and more than 2 BAs in case of ATM/Frame Relay), the DS field can not be mapped entirely into the appropriate field of MPLS encapsulation header (i.e., EXP field in case of Shim Header and CLP/DE field in case of ATM/Frame Relay); We define that: - an LSP established for a given Forwarding Equivalent Class (FEC) may be used for transport of the BAs comprised in one Ordered Aggregate (OA) for that FEC; - all BAs of this OA can be transported over the LSP; - BAs from other OAs can not transported over the LSP; - BAs from the OA transported over the LSP are given the appropriate scheduling treatment based on the PSC which is explicitly signaled at label set-up time. - Such an LSP is referred to as a "Label-Only-inferred-PSC" LSP or "L-LSP"; - Multiple BAs from OA transported over the LSP are granted different drop precedence by the MPLS LSR based on the appropriately encoded relevant field of MPLS encapsulation header (EXP field of the top label entry for the shim header, CLP/DE bit in case of ATM/Frame Relay); The mapping between the relevant field of the MPLS encapsulation and the drop precedence is a well-known mapping. For a given FEC, there may be more than one L-LSP carrying the same OA, for example for purposes of load balancing of the OA. In that case, in order to respect ordering constraints, all packets of a given microflow must be transported over the same LSP. MPLS specifies how LSPs can be established via multiple signaling protocols. Those include the Label Distribution Protocol (LDP), RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP are to be used for establishment of L-LSPs. 4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP This section defines how the `Encaps-->PHB mapping' of the Diff-Serv context is populated for an incoming L-LSP for support of the mandatory default method for Incoming PHB determination. Le Faucheur et. al 14 MPLS Support of Diff-Serv February 00 4.2.1 `EXP-->PHB mapping' If the LSR terminates the MPLS Shim Layer (i.e. it is not an ATM-LSR or FR-LSR as defined in [MPLS ATM][MPLS FR], and it does not receive packets without an MPLS shim layer on an LC-ATM or LC-FR interface) then the `Encaps-->PHB mapping' is populated at label setup in the following way: - it is actually a `EXP-->PHB mapping' - the mapping is a function of the PSC which is carried on this LSP, and uses the relevant `EXP->PHB mapping' for this PSC as defined in Section 4.2.1.1 below. For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with: EXP Field PHB 000 ----> AF11 001 ----> AF12 010 ----> AF13 4.2.1.1 EXP/PSC --> PHB mapping In order to populate the `Encaps-->PHB mapping', the mapping from the L-LSP PSCs and the EXP field of the shim header into PHBs is specified as follows: EXP Field PSC PHB 000 DF <----> DF 000 CSn <----> CSn 000 AFn <----> AFn1 001 AFn <----> AFn2 010 AFn <----> AFn3 000 EF <----> EF 4.2.2 `CLP-->PHB mapping' If the LSR does not terminate an MPLS Shim Layer over this incoming label and uses ATM encapsulation (i.e. it is an ATM-LSR or it receives packets without a shim on an LC-ATM interface), then the `Encaps-->PHB mapping' of the Diff-Serv context for this incoming L-LSP is populated at label setup in the following way: - it is actually a `CLP-->PHB mapping' - the mapping is a function of the PSC which is carried on this LSP, and uses the relevant `CLP-->PHB mapping' for this PSC as defined in Section 4.2.2.1 below. For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with: Le Faucheur et. al 15 MPLS Support of Diff-Serv February 00 CLP Field PHB 0 ----> AF11 1 ----> AF12 4.2.2.1 CLP/PSC --> PHB mapping In order to populate the `Encaps-->PHB mapping', the mapping from the L-LSP PSCs and the CLP bit of the ATM cell header into PHBs is specified as follows: CLP Bit PSC PHB 0 DF ----> DF 0 CSn ----> CSn 0 AFn ----> AFn1 1 AFn ----> AFn2 0 EF ----> EF 4.2.3 `DE-->PHB mapping' If the LSR does not terminate an MPLS Shim Layer over this incoming label and uses Frame Relay encapsulation(i.e. it is a FR-LSR or it receives packets without a shim on an LC-FR interface), then the `Encaps-->PHB mapping' of the Diff-Serv context for this incoming L-LSP is populated at label setup in the following way: - it is actually a `DE-->PHB mapping' - the mapping is a function of the PSC which is carried on this LSP, and uses the relevant `DE-->PHB mapping' for this PSC as defined in Section 4.2.3.1 below. 4.2.3.1 DE/PSC --> PHB mapping In order to populate the `Encaps-->PHB mapping', the mapping from the L-LSP PSCs and the DE bit of the Frame Relay header into PHBs is specified as follows: DE Bit PSC PHB 0 DF ----> DF 0 CSn ----> CSn 0 AFn ----> AFn1 1 AFn ----> AFn2 0 EF ----> EF 4.3 Incoming PHB Determination On Incoming L-LSP This section defines the mandatory default method for Incoming PHB determination for a labeled packet received on an L-LSP. This method requires that the `Encaps-->PHB mapping' is populated as defined above in section 4.2. Le Faucheur et. al 16 MPLS Support of Diff-Serv February 00 When receiving a labeled packet over an L-LSP of an MPLS ingress interface, the LSR first determines the `Encaps-->PHB mapping' associated with the incoming label. 4.3.1 `EXP-->PHB mapping' If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping', then the LSR: - determines the incoming PHB by looking at the EXP field of the top level label entry and by using the EXP-->PHB mapping. If the received EXP field value is not included in the EXP-->PHB mapping, this EXP value should be considered invalid. LSR behavior in such situation is a local matter and is outside the scope of this document. 4.3.2 `CLP-->PHB mapping' If the `Encaps-->PHB mapping' is of the form `CLP-->PHB mapping', then the LSR: - determines the incoming PHB by looking at the CLP field of the ATM Layer encapsulation and by using the CLP-->PHB mapping. If the received CLP field value is not included in the CLP-->PHB mapping, this CLP value should be considered invalid. LSR behavior in such situation is a local matter and is outside the scope of this document. 4.3.3 `DE-->PHB mapping' If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping', then the LSR: - determines the incoming PHB by looking at the DE field of the Frame Relay encapsulation and by using the DE-->PHB mapping. If the received DE field value is not included in the DE-->PHB mapping, this DE value should be considered invalid. LSR behavior in such situation is a local matter and is outside the scope of this document. 4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing L-LSP This section defines how the `Set of PHB-->Encaps mappings' of the Diff-Serv context is populated for an outgoing L-LSP for support of the mandatory default method for Encoding Diff-Serv Information into Encapsulation on Outgoing L-LSP. 4.4.1 `PHB-->EXP mapping' If the LSR uses an MPLS Shim Layer over this outgoing label (i.e. it is not an ATM-LSR or FR-LSR and it does not transmit packets without an MPLS Shim Layer on a LC-ATM or LC-FR interface), then one Le Faucheur et. al 17 MPLS Support of Diff-Serv February 00 `PHB-->EXP mapping' is added at label setup to the `Set of PHB-->Encaps mapping' in the Diff-Serv context for this outgoing L-LSP. This `PHB-->EXP mapping' is populated in the following way: - it is a function of the PSC supported on this LSP, and uses the relevant `PHB-->EXP mapping' for this PSC as defined in section 4.4.1.1 below. For example if the outgoing label corresponds to an L-LSP supporting the AF1 PSC, then the following `PHB-->EXP mapping' is added into the `Set of PHB-->Encaps mappings': PHB EXP Field AF11 ----> 000 AF12 ----> 001 AF13 ----> 010 4.4.1.1 PHB-->PSC/EXP mapping In order to populate the `Set of PHB-->Encaps mappings', the mapping from the PHBs into the L-LSP PSC and the EXP field of the shim header is specified as follows: PHB PSC EXP Field DF ----> DF 000 CSn ----> CSn 000 AFn1 ----> AFn 000 AFn2 ----> AFn 001 AFn3 ----> AFn 010 EF ----> EF 000 4.4.2 `PHB-->CLP mapping' If the LSR uses ATM encapsulation (i.e. it is an ATM-LSR or sends packets on an LC-ATM interface), then one `PHB-->CLP mapping' is added at label setup to the `Set of PHB-->Encaps mappings' in the Diff-Serv context for this outgoing L-LSP. This `PHB-->CLP mapping' is populated in the following way: - it is a function of the PSC supported on this LSP, and uses the relevant `PHB-->CLP mapping' for this PSC as defined below in section 4.4.2.1. For example if the outgoing label corresponds to an L-LSP supporting the AF1 PSC, then the `PHB-->Encaps mapping' will be populated with: PHB CLP Field AF11 ----> 0 AF12 ----> 1 AF13 ----> 1 Le Faucheur et. al 18 MPLS Support of Diff-Serv February 00 Notice that the if the LSR is transmitting packets over a LC-ATM interface using the MPLS Shim Header, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'. 4.4.2.1 PHB-->PSC/CLP mapping In order to populate the `Set of PHB-->Encaps mappings', the mapping from the PHBs into the L-LSP PSC and the CLP bit of the ATM cell header is specified as follows: PHB PSC CLP Bit DF ----> DF 0 CSn ----> CSn 0 AFn1 ----> AFn 0 AFn2 ----> AFn 1 AFn3 ----> AFn 1 EF ----> EF 0 4.4.3 `PHB-->DE mapping' If the LSR uses Frame Relay encapsulation (i.e. it is a FR-LSR or sends packets on an LC-FR interface), one `PHB-->DE mapping' is added at label setup to the `Set of PHB-->Encaps mapping' in the Diff-Serv context for this outgoing L-LSP and is populated in the following way: - it is a function of the PSC supported on this LSP, and uses the relevant `PHB-->DE mapping' for this PSC as defined below in section 4.4.3.1. Notice that if the LSR is sending packets over a LC-FR interfaces using the MPLS Shim Header, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. 4.4.3.1 PHB-->PSC/DE mapping In order to populate the `Set of PHB-->Encaps mappings', the mapping from the PHBs into the L-LSP PSC and the DE bit of the Frame Relay header is specified as follows: PHB PSC DE Bit DF ----> DF 0 CSn ----> CSn 0 AFn1 ----> AFn 0 AFn2 ----> AFn 1 AFn3 ----> AFn 1 EF ----> EF 0 4.4.4 `PHB-->802.1 mapping' Le Faucheur et. al 19 MPLS Support of Diff-Serv February 00 If the outgoing interface is a LAN interface on which multiple Traffic Classes are supported as defined in [IEEE_802.1], then one `PHB-->802.1 mapping' is added at label setup to the `Set of PHB-->Encaps mappings' in the Diff-Serv context for this outgoing L-LSP. This `PHB-->802.1 mapping' is populated in the following way: - it is a function of the PSC supported on this LSP, and uses the relevant `PHB-->802.1 mapping' for this PSC from the Preconfigured `PHB-->802.1 mapping' defined above in section 3.4.2.1. Notice that if the LSR is transmitting packets over a LAN interface supporting multiple 802.1 Traffic Classes, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->802.1 mapping'. 4.5 Encoding Diff-Serv Information into Encapsulation on Outgoing L-LSP This section defines the mandatory default method for encoding of Diff-Serv related information into the MPLS encapsulation Layer to be used when a packet is transmitted onto an L-LSP. This method requires that the `Set of PHB-->Encaps mappings' is populated as defined above in section 4.4. The LSR first determines the `Set of PHB-->Encaps mapping' associated with the outer label of the NHLFE. 4.5.1 `PHB-->EXP mapping' If the `Set of PHB-->Encaps mapping' of the outer label contains a mapping of the form `PHB-->EXP mapping', then, for all the labels which are swapped or pushed, the LSR: - determines the PHB-->EXP mapping by looking up the `PHB-->Encaps mapping' of the Diff-Serv context associated with the corresponding label in the NHLFE. - 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. 4.5.2 `PHB-->CLP mapping' If the `Set of PHB-->Encaps mapping' of the outer label 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 Layer encapsulation by looking up the "outgoing PHB" in this PHB-->CLP mapping table. 4.5.3 `PHB-->DE mapping' If the `Set of PHB-->Encaps mapping' of the outer label contains a mapping of the form `PHB-->DE mapping', then the LSR: Le Faucheur et. al 20 MPLS Support of Diff-Serv February 00 - determines the value to be written in the DE field of the Frame Relay encapsulation by looking up the "outgoing PHB" in this PHB-->DE mapping table. 4.5.4 `PHB-->802.1 mapping' If the `Set of PHB-->Encaps mapping' of the outer label 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. 4.6 L-LSP Merging In an MPLS domain, two or more LSPs can be merged into one LSP at one LSR. The proposed support of Diff-Serv in MPLS is compatible with LSP Merging under the following condition: L-LSPs can only be merged into one L-LSP if they support the same PSC. The above merge condition MUST be enforced by LSRs through explicit checking at label setup that the same PSC is supported on the merged LSPs. Note that when L-LSPs merge, the bandwidth that is available for the PSC downstream of the merge point must be sufficient to carry the sum of the merged traffic. This is particularly important in the case of EF traffic. This can be ensured in multiple ways (for instance via provisioning, or via bandwidth signaling and explicit admission control). 5. RSVP Extension for Diff-Serv Support The MPLS architecture does not assume a single label distribution protocol. [RSVP_MPLS_TE] defines the extension to RSVP for establishing label switched paths (LSPs) in MPLS networks. This section specifies the extensions to RSVP, beyond those defined in [RSVP_MPLS_TE], to establish label switched path (LSPs) supporting Differentiated Services in MPLS networks. 5.1 Diff-Serv related RSVP Messages Format One new RSVP Object is defined in this document: the DIFFSERV Object. Detailed description of this Object is provided below. This new Object is applicable to Path messages. This specification only defines the use of the DIFFSERV Object in Path messages used to establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 and containing a LABEL_REQUEST object. Le Faucheur et. al 21 MPLS Support of Diff-Serv February 00 Restrictions defined in [RSVP_MPLS_TE] for support of establishment of LSP Tunnels via RSVP are also applicable to the establishment of LSP Tunnels supporting Diff-Serv: for instance, only unicast LSPs are supported and Multicast LSPs are for further study. This new DIFFSERV object is optional with respect to RSVP so that general RSVP implementations not concerned with MPLS LSP set up do not have to support this object. The DIFFSERV Object is optional for support of LSP Tunnels as defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs using the preconfigured EXP<-->PHB mapping in compliance with this specification MAY support the DIFFSERV Object. A Diff-Serv capable LSR supporting E-LSPs using a signaled EXP<-->PHB mapping in compliance with this specification MUST support the DIFFSERV Object. A Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST support the DIFFSERV Object. 5.1.1 Path Message Format The format of the Path message is as follows: ::= [ ] [ ] [ ] [ ] [ ... ] [ ] ::= [ ] [ ] [ ] 5.2 DIFFSERV Object The DIFFSERV object formats are shown below. Currently there are two possible C_Types. Type 1 is a DIFFSERV object for an E-LSP. Type 2 is a DIFFSERV object for an L-LSP. 5.2.1. DIFFSERV object for an E-LSP: class = TBD, C_Type = 1 (need to get an official class num from the IANA with the form 0bbbbbbb) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | MAPnb | Le Faucheur et. al 22 MPLS Support of Diff-Serv February 00 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAP (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // ... // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAP (MAPnb) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 28 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 1 to 8 (decimal). MAP : 32 bits Each MAP entry defines the mapping between one EXP field value and one PHB. The MAP entry has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | EXP | PHBID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 13 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. EXP : 3 bits This field contains the value of the EXP field for the EXP<-->PHB mapping defined in this MAP entry. PHBID : 16 bits This field contains the PHBID of the PHB for the EXP<-->PHB mapping defined in this MAP entry. The PHBID is encoded as specified in section 2 of [PHBID]. 5.2.2 DIFFSERV object for an L-LSP: class = TBD, C_Type = 2 (class num is the same as DIFFSERV object for E-LSP)) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | PSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Le Faucheur et. al 23 MPLS Support of Diff-Serv February 00 Reserved : 16 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. PSC : 16 bits The PSC indicates a PHB Scheduling Class to be supported by the LSP. The PSC is encoded as specified in section 2 of [PHBID]: - Where the PSC comprises a single PHB defined by standards action, the encoding for the PSC is the encoding for this single PHB. It is the recommended DSCP value for that PHB, left-justified in the 16-bit field, with bits 6 through 15 set to zero. - Where the PSC comprises multiple PHBs defined by standards action, the PSC encoding is the encoding for this set of PHB. It is the smallest numerical value of the recommended DSCP for the various PHBs in the PSC, left-justified in the 16 bit field, with bits 6 through 13 and bit 15 set to zero and with bit 14 set to one. For instance, the encoding of the EF PSC is : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For instance, the encoding of the AF1 PSC is : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 1 0|0 0 0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3 Handling Diff-Serv Object To establish an LSP tunnel with RSVP, the sender creates a Path message with a session type of LSP_Tunnel_IPv4 and with a LABEL_REQUEST object as per [RSVP_MPLS_TE]. Where the sender supports Diff-Serv, to establish with RSVP an E-LSP tunnel which uses the Preconfigured EXP<-->PHB mapping, the sender creates a Path message: - with a session type of LSP_Tunnel_IPv4, - with the LABEL_REQUEST object, and - without the DIFFSERV object. Where the sender supports Diff-Serv, to establish with RSVP an E-LSP tunnel which uses a signaled EXP<-->PHB mapping, the sender creates a Path message : - with a session type of LSP_Tunnel_IPv4, - with the LABEL_REQUEST object, Le Faucheur et. al 24 MPLS Support of Diff-Serv February 00 - with the DIFFSERV object for an E-LSP containing one MAP entry for each EXP value to be supported on this E-LSP. Where the sender supports Diff-Serv, to establish with RSVP an L-LSP tunnel, the sender creates a Path message: - with a session type of LSP_Tunnel_IPv4, - with the LABEL_REQUEST object, - with the DIFFSERV object for an L-LSP containing the PHB Scheduling Class (PSC) supported on this L-LSP. If a path message contains multiple DIFFSERV objects, only the first one is meaningful; subsequent DIFFSERV object(s) must be ignored and not forwarded. Each node along the path records the DIFFSERV object, when present, in its path state block. The destination node of an E-LSP or L-LSP responds to the Path message containing the LABEL_REQUEST object by sending a Resv message: - with the LABEL object - without a DIFFSERV object. Assuming the reservation is accepted and a label is associated with the reservation, the Diff-Serv LSRs (sender, destination, intermediate nodes) must: - update the Diff-Serv context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label), - install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label). An RSVP router that does recognizes the DIFFSERV object and that receives a path message which contains the DIFFSERV object but which does not contain a LABEL_REQUEST object or which does not have a session type of LSP_Tunnel_IPv4, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unexpected DIFFSERV object'. Those are defined below in section 5.5. A node receiving a Path message with the DIFFSERV object for E-LSP, which recognizes the DIFFSERV object but does not support the particular PHB encoded in one, or more, of the MAP entries, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unsupported PHB'. Those are defined below in section 5.5. A node receiving a Path message with the DIFFSERV object for E-LSP, which recognizes the DIFFSERV object but determines that the signaled EXP<-->PHB mapping is invalid, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Invalid EXP<-->PHB mapping'. Those are defined below in section Le Faucheur et. al 25 MPLS Support of Diff-Serv February 00 5.5. The EXP<-->PHB mapping signaled in the DIFFSERV Object for an E-LSP is invalid when: - the MAPnb field is not within the range 1 to 8 decimal, or - a given EXP value appears in more than one MAP entry, or - the PHBID encoding is invalid A node receiving a Path message with the DIFFSERV object for L-LSP, which recognizes the DIFFSERV object but does not support the particular PSC encoded in the PSC field, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unsupported PSC'. Those are defined below in section 5.5. A Diff-Serv LSR MUST handle the situations where the reservation can not be accepted for other reasons than those already discussed in this section, in accordance with [RSVP_MPLS_TE] (eg. reservation rejected by admission control, a label can not be associated). 5.4 Non-support of the Diff-Serv Object An RSVP router that does not recognize the DIFFSERV object Class-Num must behave in accordance with the procedures specified in [RSVP] for an unknown Class-Num whose format is 0bbbbbbb ie. it must send a PathErr with the error code `Unknown object class' toward the sender. An RSVP router that recognizes the DIFFSERV object Class-Num but does not recognize the DIFFSERV object C-Type, must behave in accordance with the procedures specified in [RSVP] for an unknown C- type ie. It must send a PathErr with the error code `Unknown object C-Type' toward the sender. In both situations, this causes the path set-up to fail. The sender should notify management that a L-LSP cannot be established and possibly take action to retry reservation establishment without the DIFFSERV object (eg. attempt to use E-LSPs with Preconfigured EXP<-->PHB mapping as a fall-back strategy). 5.5 Error Codes For Diff-Serv In the procedures described above, certain errors must be reported as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error code is 26 (TBD). The following defines error values for the Diff-Serv Error: Value Error 1 Unexpected DIFFSERV object 2 Unsupported PHB 3 Invalid EXP<-->PHB mapping 4 Unsupported PSC Le Faucheur et. al 26 MPLS Support of Diff-Serv February 00 5.6 Use of COS Service with E-LSPs and L-LSPs Both E-LSPs and L-LSPs can be established with bandwidth reservation or without bandwidth reservation. To establish an E-LSP or an L-LSP with bandwidth reservation, Int- Serv's Controlled Load service (or possibly Guaranteed Service) is used and the bandwidth is signaled in the SENDER_TSPEC (respectively FLOWSPEC) of the path (respectively Resv) message. To establish an E-LSP or an L-LSP without bandwidth reservation, the Class of Service service defined in [RSVP_MPLS_TE] is used. A Path message containing a COS SENDER_TSPEC and not containing a DIFFSERV object indicates to a Diff-Serv capable LSR that the LSP to be established in an E-LSP using the Preconfigured mapping and without any bandwidth reservation. A Path message containing a COS SENDER_TSPEC and containing a DIFFSERV object for E-LSP indicates to a Diff-Serv capable LSR that the LSP to be established in an E-LSP using a signaled mapping and without any bandwidth reservation. A Path message containing a COS SENDER_TSPEC and containing a DIFFSERV object for LSP indicates to a Diff-Serv capable LSR that the LSP to be established in an L-LSP without any bandwidth reservation. The above is summarized in the following table: Path Message LSP type Service DIFFSERV Object GS/CL No E-LSP + preconf mapping + bandw reservation GS/CL Yes/E-LSP E-LSP + signaled mapping + bandw reservation GS/CL Yes/L-LSP L-LSP + bandw reservation COS No E-LSP + preconf mapping + no bandw reservation COS Yes/E-LSP E-LSP + signaled mapping + no band reservation COS Yes/L-LSP L-LSP + no bandw reservation Where: - GS stands for Guaranteed Service - CL stands for Controlled Load - COS stands for COS service When processing a path (respectively Resv) message for an E-LSP or an L-LSP using the COS service, a Diff-Serv capable LSR must ignore the value of the COS field within a COS SENDER_TSPEC (respectively a COS FLOWSPEC). Le Faucheur et. al 27 MPLS Support of Diff-Serv February 00 6. LDP Extensions for Diff-Serv Support The MPLS architecture does not assume a single label distribution protocol. [LDP] defines the Label Distribution Protocol and its usage for establishment of label switched paths (LSPs) in MPLS networks. This section specifies the extensions to LDP to establish label switched path (LSPs) supporting Differentiated Services in MPLS networks. One new LDP TLV is defined in this document: - the Diff-Serv TLV Detailed description of this TLV is provided below. The new Diff-Serv TLV is optional with respect to LDP. A Diff-Serv capable LSR supporting E-LSPs which uses the Preconfigured EXP<-->PHB mapping in compliance with this specification MAY support the Diff-Serv TLV. A Diff-Serv capable LSR supporting E-LSPs which uses the signaled EXP<-->PHB mapping in compliance with this specification MUST support the Diff-Serv TLV. A Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST support the Diff-Serv TLV. 6.1 Diff-Serv TLV The Diff-Serv TLV has the following formats: Diff-Serv TLV for an E-LSP: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type = PSC (0x901) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Reserved | MAPnb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAP (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAP (MAPnb) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T:1 bit LSP Type. This is set to 0 for an E-LSP Reserved : 28 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. MAPnb : 4 bits Le Faucheur et. al 28 MPLS Support of Diff-Serv February 00 Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 1 to 8 (decimal). MAP : 32 bits Each MAP entry defines the mapping between one EXP field value and one PHB. The MAP entry has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | EXP | PHBID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 13 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. EXP : 3 bits This field contains the value of the EXP field for the EXP<-->PHB mapping defined in this MAP entry. PHBID : 16 bits This field contains the PHBID of the PHB for the EXP<-->PHB mapping defined in this MAP entry. The PHBID is encoded as specified in section 2 of [PHBID]. Diff-Serv TLV for an L-LSP: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type = PSC (0x901) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Reserved | PSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T:1 bit LSP Type. This is set to 1 for an L-LSP Reserved : 16 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. PSC : 16 bits The PSC indicates a PHB Scheduling Class to be supported by the LSP. The PSC is encoded as specified in section 2 of [PHBID]: - Where the PSC comprises a single PHB defined by standards action, the encoding for the PSC is the encoding for this single PHB. It is the recommended DSCP value for that PHB, left-justified in the 16-bit field, with bits 6 through 15 set to zero. Le Faucheur et. al 29 MPLS Support of Diff-Serv February 00 - Where the PSC comprises multiple PHBs defined by standards action, the PSC encoding is the encoding for this set of PHB. It is the smallest numerical value of the recommended DSCP for the various PHBs in the PSC, left-justified in the 16 bit field, with bits 6 through 13 and bit 15 set to zero and with bit 14 set to one. For instance, the encoding of the EF PSC is : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For instance, the encoding of the AF1 PSC is : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 1 0|0 0 0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2 Diff-Serv Status Code Values The following values are defined for the Status Code field of the Status TLV: Status Code E Status Data Unsupported PHB 0 0x00000016 Invalid EXP<-->PHB mapping 0 0x00000017 Unsupported PSC 0 0x00000018 Unexpected Diff-Serv TLV 0 0x00000019 6.3 Diff-Serv Related LDP Messages 6.3.1 Label Request Message The format of the Label Request message is extended as follows, to optionally include the Diff-Serv TLV: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Le Faucheur et. al 30 MPLS Support of Diff-Serv February 00 6.3.2 Label Mapping Message The format of the Label Mapping message is extended as follows, to optionally include the Diff-Serv TLV: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.3 Label Release Message The format of the Label Release message is extended as follows, to optionally include the Status TLV: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Release (0x0403) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.4 Notification Message The format of the Notification message is extended as follows, to optionally include the Diff-Serv TLV: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Le Faucheur et. al 31 MPLS Support of Diff-Serv February 00 | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4 Handling of the Diff-Serv TLV 6.3.1 Handling of the Diff-Serv TLV in Downstream Unsolicited Mode This section describes operations when the Downstream Unsolicited Mode is used. When allocating a label for an E-LSP which is to use the preconfigured EXP<-->PHB mapping, a downstream Diff-Serv LSR issues a Label Mapping message without the Diff-Serv TLV. When allocating a label for an E-LSP which is to use a signaled EXP<-->PHB mapping, a downstream Diff-Serv LSR issues a Label Mapping message with the Diff-Serv TLV for an E-LSP which contains one MAP entry for each EXP value to be supported on this E-LSP. When allocating a label for an L-LSP, a downstream Diff-Serv LSR issues a Label Mapping message with the Diff-Serv TLV for an L-LSP which contains the PHB Scheduling Class (PSC) to be supported on this L-LSP. Assuming the label set-up is successful, the downstream and upstream LSRs must: - update the Diff-Serv context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label), - install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label). An upstream Diff-Serv LSR receiving a Label Mapping message with multiple Diff-Serv TLVs only considers the first one as meaningful. The LSR must ignore and not forward the subsequent Diff-Serv TLV(s). An upstream Diff-Serv LSR which receives a Label Mapping message with the Diff-Serv TLV for an E-LSP and does not support the particular PHB encoded in one, or more, of the MAP entries, must reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unsupported PHB'. An upstream Diff-Serv LSR receiving a Label Mapping message with the Diff-Serv TLV for an E-LSP and determining that the signaled EXP<-->PHB mapping is invalid, must reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Invalid EXP<-->PHB Mapping'. The EXP<-->PHB mapping signaled in the DIFFSERV Object for an E-LSP is invalid when: Le Faucheur et. al 32 MPLS Support of Diff-Serv February 00 - the MAPnb field is not within the range 1 to 8 decimal, or - a given EXP value appears in more than one MAP entry, or - the PHBID encoding is invalid An upstream Diff-Serv LSR receiving a Label Mapping message with the Diff-Serv TLV for an L-LSP containing a PSC value which is not supported, must reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unsupported PSC'. 6.3.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode This section describes operations when the Downstream on Demand Mode is used. When requesting a label for an E-LSP which is to use the preconfigured EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a Label Request message without the Diff-Serv TLV. When requesting a label for an E-LSP which is to use a signaled EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a Label Request message with the Diff-Serv TLV for an E-LSP which contains one MAP entry for each EXP value to be supported on this E-LSP. When requesting a label for an L-LSP, an upstream Diff-Serv LSR sends a Label Request message with the Diff-Serv TLV for an L-LSP which contains the PSC to be supported on this L-LSP. A downstream Diff-Serv LSR sending a Label Mapping message in response to a Label Request message for an E-LSP or an L-LSP must not include a Diff-Serv TLV in this Label Mapping message. Assuming the label set-up is successful, the downstream and upstream LSRs must: - update the Diff-Serv context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label), - install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label). An upstream Diff-Serv LSR receiving a Label Mapping message containing a Diff-Serv TLV in response to its Label Request message, must reject the label mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unexpected Diff-Serv TLV'. A downstream Diff-Serv LSR receiving a Label Request message with multiple Diff-Serv TLVs only considers the first one as meaningful. The LSR must ignore and not forward the subsequent Diff-Serv TLV(s). A downstream Diff-Serv LSR which receives a Label Request message with the Diff-Serv TLV for an E-LSP and does not support the Le Faucheur et. al 33 MPLS Support of Diff-Serv February 00 particular PHB encoded in one (or more) of the MAP entries, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Unsupported PHB'. A downstream Diff-Serv LSR receiving a Label Request message with the Diff-Serv TLV for an E-LSP and determining that the signaled EXP<-->PHB mapping is invalid, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Invalid EXP<-->PHB Mapping'. The EXP<-->PHB mapping signaled in the DIFFSERV TLV for an E-LSP is invalid when: - the MAPnb field is not within the range 1 to 8 decimal, or - a given EXP value appears in more than one MAP entry, or - the PHBID encoding is invalid A downstream Diff-Serv LSR receiving a Label Request message with the Diff-Serv TLV for an L-LSP containing a PSC value which is not supported, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Unsupported PSC'. A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in a Label Request message and supports the requested PSC but is not able to satisfy the label request for other reasons (eg. no label available), must send a Notification message in accordance with existing LDP procedures [LDP] (eg. with a `No Label Resource' Status Code). This Notification message must include the requested Diff-Serv TLV. 6.4 Non-Handling of the Diff-Serv TLV An LSR that does not recognize the Diff-Serv TLV Type, on receipt of a Label Request message or a Label Mapping message containing the Diff-Serv TLV, must behave in accordance with the procedures specified in [LDP] for an unknown TLV whose U Bit and F Bit are set to 0 ie. it must ignore the message, return a Notification message with `Unknown TLV' Status. 6.5 Bandwidth Information Bandwidth information may also be signaled at establishment time of E-LSP and L-LSP, for instance for the purpose of Traffic Engineering, using the Traffic Parameters TLV as described in [MPLS CR LDP]. 7. MPLS Support of Diff-Serv over PPP The general operations for MPLS support of Diff-Serv, including label forwarding and LSP setup operations are specified in the previous sections. This section describes the specific operations required for MPLS support of Diff-Serv over PPP links. While Le Faucheur et. al 34 MPLS Support of Diff-Serv February 00 sections 8, 9 and 10 focus on other media specific operations, namely ATM, Frame Relay and LAN respectively. This document allows any of the following LSP combinations per FEC within an MPLS PPP Diff-Serv domain: - Zero or any number of E-LSP, and - Zero or any number of L-LSPs. 7.1 LSR implementation with PPP interfaces A Diff-Serv capable LSR with PPP interfaces MUST support, over these PPP interfaces, E-LSPs which use the pre-configured EXP<-->PHB mapping, in compliance with all the material from this specification pertaining to those types of LSPs. A Diff-Serv capable LSR with PPP interfaces MAY support, over these PPP interfaces, E-LSPs which use a signaled EXP<-->PHB mapping. If a Diff-Serv LSR does support E-LSPs which use a signaled EXP<-->PHB mapping over PPP interfaces, then it MUST do so in compliance with all the material from this specification pertaining to those types of LSPs. A Diff-Serv capable LSR with PPP interfaces MAY support L-LSPs over these PPP interfaces. If a Diff-Serv LSR does support L-LSPs over PPP interfaces, then it MUST do so in compliance with all the material from this specification pertaining to L-LSPs. An LSR running MPLS over PPP over a traditional ATM connection (ie. where the ATM switches do not participate in MPLS and where the ATM connection VPI/VCI values have not been established via any label distribution protocol) is to be considered as an LSR with PPP interfaces from the point of view of compliance to this specification. Similarly, an LSR running MPLS over PPP over a traditional Frame Relay connection (ie. where the Frame Relay switches do not participate in MPLS and where the Frame Relay connection DLCI values have not been established via any label distribution protocol) is to be considered as an LSR with PPP interfaces from the point of view of compliance to this specification. 8. MPLS Support of Diff-Serv by ATM LSRs The general operations for MPLS support of Diff-Serv, including label forwarding and LSP setup operations was specified in the previous sections. This section describes the specific operations required for MPLS support of Diff-Serv over ATM links. This document allows the following set of LSP combinations per FEC within an MPLS ATM Diff-Serv domain: Le Faucheur et. al 35 MPLS Support of Diff-Serv February 00 - any number of L-LSPs. 8.1 Merging The use of merging is optional. In case that merging of ATM LSPs is used, procedures described in section 3.6 of this specification apply. Additionally, to avoid cell interleaving problems with AAL-5 merging, procedures specified in [MPLS ATM] MUST be followed. 8.2 Use of ATM Traffic Classes and Traffic Management mechanisms The use of the ATM traffic classes as specified by ITU-T and ATM- Forum or of vendor specific ATM traffic classes is outside of the scope of this specification. The only requirement for compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be compliant with the corresponding Diff-Serv PHB specifications. Since there is only one bit for encoding the PHB drop precedence value over ATM links, only two different drop precedence levels are supported in ATM LSRs. The behavior for AF MUST comply to procedures described in [DIFF_AF] for the case when only two drop precedence levels are supported. To avoid discarding parts of the packets, frame discard mechanisms, such as Early Packet Discard (EPD) SHOULD be enabled in the ATM-LSRs for all PHBs described in this document. 8.3 LSR Implementation With ATM Interfaces A Diff-Serv capable LSR with ATM interfaces MUST support L-LSPs over these ATM interfaces in compliance with all the material from this specification pertaining to those types of LSPs. Additionally, procedures specified in [MPLS ATM] MUST be followed by compliant implementation. Support of E-LSPs over ATM interfaces running native ATM MPLS by an LSR implementation is not allowed. 9. MPLS Support of Diff-Serv by Frame Relay LSRs The general operations for MPLS support of Diff-Serv, including label forwarding and LSP setup operations was specified in the previous sections. This section describes the specific operations required for MPLS support of Diff-Serv over Frame Relay links. This document allows the following set of LSP combinations per FEC within an MPLS Frame Relay Diff-Serv domain: - any number of L-LSPs. 9.1 Merging Le Faucheur et. al 36 MPLS Support of Diff-Serv February 00 The use of merging is optional. In case that merging of Frame Relay LSPs is used, procedures described in section 3.6 of this specification apply as well as procedures in [MPLS FR]. 9.2 Use of Frame Relay Traffic parameters and Traffic Management mechanisms The use of the Frame Relay traffic parameters as specified by ITU-T and Frame Relay-Forum or of vendor specific Frame Relay traffic management mechanisms is outside of the scope of this specification. The only requirement for compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the Frame Relay LSR MUST be compliant with the corresponding Diff-Serv PHB specifications. Since there is only one bit for encoding the PHB drop precedence value over Frame Relay links, only two different drop precedence levels are supported in Frame Relay LSRs. The behavior for AF MUST comply to procedures described in [DIFF_AF] for the case when only two drop precedence levels are supported. 9.3 LSR Implementation With Frame Relay Interfaces A Diff-Serv capable LSR with Frame Relay interfaces MUST support L-LSPs over these Frame Relay interfaces in compliance with all the material from this specification pertaining to those types of LSPs. Support of E-LSPs over Frame Relay interfaces running native Frame Relay MPLS by an LSR implementation is not allowed. 10. MPLS Support of Diff-Serv over LAN Media The general operations for MPLS support of Diff-Serv, including label forwarding and LSP setup operations was specified in the previous sections. This section describes the specific operations required for MPLS support of Diff-Serv over LAN. This document allows the following set of LSP setup combinations per FEC over an MPLS link: - Zero or any number of E-LSP, and - Zero or any number of L-LSPs. 10.1 LSR Implementation With LAN Interfaces A Diff-Serv capable LSR with LAN interfaces MUST support, over these LAN interfaces, E-LSPs which use the pre-configured EXP<-->PHB mapping, in compliance with all the material from this specification pertaining to those types of LSPs. Le Faucheur et. al 37 MPLS Support of Diff-Serv February 00 A Diff-Serv capable LSR with LAN interfaces MAY support, over these LAN interfaces, E-LSPs which use a signaled EXP<-->PHB mapping. If a Diff-Serv LSR does support E-LSPs which use a signaled EXP<-->PHB mapping over LAN interfaces, then it MUST do so in compliance with all the material from this specification pertaining to those types of LSPs. A Diff-Serv capable LSR MAY support L-LSPs over LAN interfaces. If a Diff-Serv LSR does support L-LSPs over LAN interfaces, then it MUST do so in compliance with all the material from this specification pertaining to L-LSPs. 11. Explicit Congestion Notification Explicit Congestion Notification is described in [ECN] and is proposed as an Experimental extension to the IP protocol. [MPLS_ECN] discusses deployment of ECN in an MPLS network using the Shim Header as the MPLS encapsulation. It demonstrates that, provided a given LSP is identified as ECN-capable or as non-ECN- capable (and consistently recognized as such by all the involved LSRs), then ECN can be supported in an MPLS domain where the Shim Header is used as the MPLS encapsulation via a single bit of the EXP field. The details of how a given LSP is to be identified as ECN-capable or non-ECN-capable (whether via extensions to the LSP establishment signaling and procedures, via configuration or via other means) are outside the scope of this specification. However, this specification recognizes that, within an ECN-capable MPLS domain where LSPs are identified as ECN-capable or not-ECN- capable: - Support of ECN does not require that any bit(s) from the EXP field be reserved for ECN operations across all LSPs even when those LSPs are not ECN-capable. Consequently, LSPs identified as non-ECN-capable (regardless of whether this is because at least one LSR on the LSP does not support ECN operations or whether this is because the network administrator does not wish to use ECN on this LSP) can make use of the full 3-bit EXP field for Diff-Serv purposes. Thus, non-ECN-capable E-LSPs and non-ECN- capable L-LSPs can operate as defined earlier in this document without any restriction imposed by the fact that the MPLS domain is ECN-capable. In particular, up to 8 BAs can still be transported over a non-ECN-capable E-LSP within an ECN-capable MPLS domain. Similarly, non-ECN-capable L-LSPs within an ECN- capable MPLS domain can support all the drop precedence levels of currently defined PSCs. Should a future PSC involve more than 4 drop precedence levels, non-ECN-capable L-LSPs within an ECN- Le Faucheur et. al 38 MPLS Support of Diff-Serv February 00 capable MPLS domain could still use the full 3-bit field EXP. - Because a single bit is required to encode the ECN information inside the ECN-capable MPLS domain, LSPs identified as ECN- capable can make use of two bits of the EXP field value for Diff-Serv purposes. In particular, up to 4 BAs can be transported over an ECN-capable E-LSP. Similarly, up to 4 drop precedence levels can be supported over an ECN-capable L-LSP; since all the PSCs corresponding to PHBs currently defined through standards action involve less than 4 drop precedence levels, ECN support does not currently restrict Diff-Serv operations over L-LSPs. Should a PSC corresponding to future PHBs defined by standards action or corresponding to local use or experimental PHBs, involve more than 4 drop precedence levels, then ECN support over the corresponding LSP would constrain the PSC to 4 drop precedence levels; relative benefits of additional precedence levels beyond 4, would then be weighted by the network administrator over the benefits of ECN, to determine whether it is preferable to support this PSC over an ECN-capable or non-ECN-capable LSP. 11.1 MPLS ECN bit with Shim Header Where the Shim Header is used as the MPLS encapsulation, ECN information is to be encoded on ECN-capable LSPs in the first bit of the 3-bit EXP field in the following way: EXP field MPLS ECN Meaning 0xx --> `ECT, not CE' 1xx --> `not ECT, or ECT+CE' where ECT stands for `ECN Capable Transport' and `CE' stands for `Congestion experienced'. Detailed specification for usage of this MPLS ECN bit is outside the scope of this document. For ECN-capable E-LSPs using preconfigured mapping, the Preconfigured EXP<-->PHB mapping defined above in section 3.2.1 is only operating over the last 2 bits of the 3-bit EXP field. For ECN- capable E-LSPs using signaled mapping, the signaled EXP<-->PHB mapping is only operating over the last 2 bits of the 3-bit EXP field. Thus it has the following format: EXP Field PHB e00 <-----> a given PHB e01 <-----> a given PHB e10 <-----> a given PHB e11 <-----> a given PHB Le Faucheur et. al 39 MPLS Support of Diff-Serv February 00 where `e' is the MPLS ECN bit and can take the value zero or one depending on ECN operations. For ECN-capable L-LSPs, the `EXP/PSC-->PHB mapping' defined above in section 4.2.1.1 is only operating over the last 2 bits of the 3-bit EXP field and is the following: EXP Field PSC PHB e00 DF -----> DF e00 CSn -----> CSn e00 AFn -----> AFn1 e01 AFn -----> AFn2 e10 AFn -----> AFn3 e00 EF -----> EF where `e' is the MPLS ECN bit and can take the value zero or one depending on ECN operations. For ECN-capable L-LSPs, the `PHB--> PSC/EXP mapping' defined above in the section 4.4.1.1 is only operating over the last 2 bits of the 3-bit EXP field and is the following: PHB EXP Field PSC DF -----> e00 DF CSn -----> e00 CSn AFn1 -----> e00 AFn AFn2 -----> e01 AFn AFn3 -----> e10 AFn EF -----> e00 EF where `e' is the MPLS ECN bit and can take the value zero or one depending on ECN operations. For non-ECN-capable LSPs, the first bit of the 3-bit EXP field is NOT reserved for ECN and can be used to encode any Diff-Serv information. In particular, for non-ECN-capable E-LSPs, the EXP<-->PHB mapping defined in the section titled `EXP<-->PHB Field Mapping' and configured on the LSR is operating over the 3 bits of the EXP field. 12. Security Considerations This document does not introduce any new security issues beyond those inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms proposed for those technologies. 13. Acknowledgments Le Faucheur et. al 40 MPLS Support of Diff-Serv February 00 This document has benefited from discussions with K. K. Ramakrishnan, Eric Rosen, Angela Chiu and Carol Iturralde. APPENDIX A. Example Deployment Scenarios This section does not provide additional specification and is only here to provide examples of how this flexible approach for Diff-Serv support over MPLS may be deployed. Pros and cons of various deployment options for particular environments are beyond the scope of this document. A.1 Scenario 1: 8 (or less) BAs, no Traffic Engineering, no Fast Reroute A Service Provider running 8 (or less) BAs over MPLS, not performing Traffic engineering, not performing protection via Fast Reroute and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using a single E-LSP per FEC established via LDP. Furthermore the Service Provider may elect to use the preconfigured EXP<-->PHB mapping. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (eg bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) - LSRs signal establishment of a single E-LSP per FEC using LDP in accordance with the specification above (ie no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping) A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no Fast Reroute A Service Provider running more than 8 BAs over MPLS, not performing Traffic Engineering and not performing protection via Fast Reroute and using MPLS Shim encapsulation in his/her network may elect to run Diff-Serv over MPLS using for each FEC: - one E-LSP established via LDP and using the preconfigured mapping to support a set of 8 (or less) BAs, AND - one L-LSP per established via LDP for support of the other BAs. Operations can be summarized as follows: Le Faucheur et. al 41 MPLS Support of Diff-Serv February 00 - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs transported over the E-LSP - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB - LSRs signal establishment of a single E-LSP per FEC for the set of E-LSP transported BAs using LDP as specified above (ie no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping) - LSRs signal establishment of one L-LSP per for the other BAs using LDP as specified above (ie Diff-Serv TLV in LDP Label Request/Label Mapping messages to indicate the L-LSP's PSC). A.3 Scenario 3: 8 BAs, Aggregate Traffic Engineering, Aggregate Fast Reroute A Service Provider running 8 (or less) BAs over MPLS, performing aggregate Traffic Engineering (ie performing a single common path selection for all BAs), performing aggregate protection via Fast Reroute (ie performing Fast Reroute for all PSCs jointly) and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using a single E-LSP per FEC established via RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] and using the preconfigured mapping. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (eg bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) - LSRs signal establishment of a single E-LSP per FEC which will use the preconfigured mapping: * using the RSVP protocol as specified above (ie no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR * using the CR-LDP protocol as specified above (ie no Diff- Serv TLV in LDP Label Request/Label Mapping messages). A.4 Scenario 4: per-OA Traffic Engineering/Fast Reroute A Service Provider running any number of BAs over MPLS, performing per-OA Traffic Engineering (ie performing a separate path selection for each OA) and performing per-OA protection via Fast Reroute (ie Le Faucheur et. al 42 MPLS Support of Diff-Serv February 00 performing protection with different Fast Reroute policies for the different OAs) in his/her network, may elect to run Diff-Serv over MPLS using one L-LSP per pair established via RSVP or CR-LDP. Operations can be summarized as follows: - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (eg bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) - LSRs signal establishment of one L-LSP per : * using the RSVP as specified above to signal the L-LSP's PSC (ie DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR * using the CR-LDP protocol as specified above to signal the L-LSP PSC (ie Diff-Serv TLV in LDP Label Request/Label Mapping messages). A.5 Scenario 5: 8 (or less) BAs, per-OA Traffic Engineering/Fast Reroute A Service Provider running 8 (or less) 8 BAs over MPLS, performing per-OA Traffic Engineering (ie performing a separate path selection for each OA) and performing per-OA protection via Fast Reroute (ie performing protection with different Fast Reroute policies for the different OAs) in his/her network, may elect to run Diff-Serv over MPLS using one E-LSP per pair established via RSVP or CR-LDP. Furthermore, the Service Provider may elect to use the preconfigured mapping on all the E-LSPs. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (eg bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) - LSRs signal establishment of one E-LSP per : * using the RSVP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping (ie no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR * using the CR-LDP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping (ie no Diff-Serv TLV in LDP Label Request/Label Mapping messages) - the Service Provider configures, for each E-LSP, at the head-end of that E-LSP, a filtering/forwarding criteria so that only the packets belonging to a given OA are forwarded on the E-LSP established for the corresponding FEC and corresponding OA. Le Faucheur et. al 43 MPLS Support of Diff-Serv February 00 A.6 Scenario 6: no Traffic Engineering/Fast Reroute on 8 BAs, per-OA Traffic Engineering/Fast Reroute on other BAs. A Service Provider not performing Traffic Engineering/Fast Reroute on 8 (or less) BAs, performing per-OA Traffic Engineering/Fast Reroute on the other BAs (ie performing a separate path selection for each OA corresponding to the other BAs and performing protection with a different policy for each of these OA) and using the MPLS Shim encapsulation in his/her network may elect to run Diff-Serv over MPLS, using for each FEC: - one E-LSP using the preconfigured mapping established via LDP to support the set of 8 (or less) non-traffic-engineered/non-fast- rerouted BAs, AND - one L-LSP per pair established via RSVP or CR-LDP for support of the other BAs. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs supported over the E-LSP - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB - LSRs signal establishment of a single E-LSP per FEC for the non- traffic engineered BAs using LDP as specified above (ie no Diff- Serv TLV in LDP Label Request/Label Mapping messages) - LSRs signal establishment of one L-LSP per for the other BAs: * using the RSVP protocol as specified above to signal the L-LSP PSC (ie DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR * using the CR-LDP protocol as specified above to signal the L-LSP PSC (ie Diff-Serv TLV in LDP Label Request/Label Mapping messages). A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no Fast Reroute A Service Provider running more than 8 BAs over MPLS, not performing Traffic engineering, not performing protection via Fast Reroute and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using two E-LSPs per FEC established via LDP and using signaled EXP<-->PHB mapping. Operations can be summarized as follows: - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (eg bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) Le Faucheur et. al 44 MPLS Support of Diff-Serv February 00 - LSRs signal establishment of two E-LSPs per FEC using LDP in accordance with the specification above (ie Diff-Serv TLV in LDP Label Request/Label Mapping messages to explicitly indicate that the LSP is an E-LSP and its EXP<--> mapping). The signaled mapping will indicate the subset of 8 (or less) BAs to be transported on each E-LSP and what EXP values are mapped to each BA on each E-LSP. References [MPLS_ARCH] Rosen et al., "Multiprotocol label switching Architecture", work in progress, (draft-ietf-mpls-arch-06.txt), August 1999. [MPLS ATM] Davie et al., _MPLS using LDP and ATM VC Switching_, work in progress, (draft-ietf-mpls-atm-02.txt), April 1999 [MPLS FR] Conta et al., _Use of Label Switching on Frame Relay Networks Specification_, (draft-ietf-mpls-fr-03.txt), November 1998 [DIFF_ARCH] Blake et al., "An architecture for Differentiated Services", RFC-2475, December 1998. [DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597, June 1999. [DIFF_EF] Jacobson et al., "An Expedited Forwarding PHB", RFC-2598, June 1999. [DIFF_HEADER] Nichols et al., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474, December 1998. [ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC-2481, January 1999. [MPLS_ECN] Ramakrishnan et al., "A Proposal to Incorporate ECN in MPLS", draft-ietf-mpls-ecn-00.txt, June 1999. [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 05.txt, June 99 [RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-03.txt, September 1999 [CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-03.txt, October 1999 [PHBID] Brim et al., "Per Hop Behavior Identification Codes draft-ietf-diffserv-phbid-00.txt, October 99 Le Faucheur et. al 45 MPLS Support of Diff-Serv February 00 [DIFF_NEW] Grossman, _New Terminology for Diffserv_, draft-ietf- diffserv-new-terms-02.txt, November 99 [IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision and redesignation of ISO/IEC 10038:98 [ANSI/IEEE Std 802.1D, 1993 Edition], incorporating IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and P802.12e) Author's Addresses: Francois Le Faucheur Cisco Systems Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France Phone: +33 4 92 96 75 64 Email: flefauch@cisco.com Liwen Wu Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824, USA Phone: +1 (978) 244-3087 Email: liwwu@cisco.com Bruce Davie Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824 USA Phone: +1 (978) 244-8000 Email: bsd@cisco.com Shahram Davari PMC-Sierra Inc. 105-8555 Baxter Place Burnaby, BC V5A 4V7 Canada E-mail: Shahram_Davari@pmc-sierra.com Pasi Vaananen Nokia 3 Burlington Woods Drive, Suit 250 Burlington, MA 01803 USA Phone +1 (781) 238-4981 Email: pasi.vaananen@nokia.com Ram Krishnan Nexabit Networks 200 Nickerson Road, Marlboro, MA 01752 Le Faucheur et. al 46 MPLS Support of Diff-Serv February 00 USA E-mail: ram@nexabit.com Pierrick Cheval Alcatel 5 rue Noel-Pons 92734 Nanterre Cedex France E-mail: pierrick.cheval@alcatel.fr Juha Heinanen Telia Finland E-mail: jh@lohi.eng.telia.fi Le Faucheur et. al 47