Francois Le Faucheur Liwen Wu Bruce Davie Cisco Systems Shahram Davari PMC-Sierra Inc. Pasi Vaananen Nokia Ram Krishnan Nexabit Networks Pierrick Cheval Alcatel IETF Internet Draft Expires: April, 2000 Document: draft-ietf-mpls-diff-ext-02.txt October, 1999 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. This solution allows the MPLS network administrator to flexibly define how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Paths so that he/she can best match the Diff-Serv, Traffic Le Faucheur, et. al 1 MPLS Support of Diff-Serv October 99 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 where both the Behavior Aggregate's scheduling treatment and its drop precedence are conveyed to the LSR in the EXP field of the MPLS Shim Header. - LSPs where the Behavior Aggregate's scheduling treatment is inferred by the LSR from the packet's label value while the Behavior Aggregate's drop precedence is indicated 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. 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 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 or Traffic Engineered 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 Le Faucheur et. al 2 MPLS Support of Diff-Serv October 99 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 mandating set-up of multiple LSPs for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or required. 1.1 Ordered Aggregate (OA) and PHB Scheduling Class (PSC) The Diff-Serv model defines [APPENDIX A] 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 applied to the set of Behavior Aggregates forming a given OA, as a "PHB Scheduling Class (PSC)". 1.2 EXP-Inferred-PSC LSPs (E-LSP) Section 2 below specifies how a single LSP can be used to support up to eight BAs, regardless of how many OAs these BAs span. With such LSPs, the packet DSCP value gets entirely mapped into the EXP field of the MPLS Shim Header [MPLS_ENCAPS] at the Edge of the MPLS Diff- Serv Cloud (thus encoding both drop precedence and PSC/scheduling information). In other words, both PSC and Drop Precedence are conveyed in each labeled packet using the EXP field of the MPLS Shim Header [MPLS_ENCAPS]. We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP). Detailed operations of E-LSPs are specified in section 2 below. E-LSPs have the following benefits: - label space is conserved by allowing "packing" of up to eight BAs per label (eg. when there are fewer than eight BAs in the network, this method maintains the same label space as in a non Diff-Serv capable MPLS network). - label establishment signaling is then reduced since a single LSP is established for up to eight BAs (eg. when there are fewer than eight BAs in the network, this method maintains the same level of signaling as in a non-Diff-Serv capable MPLS network) - the amount of forwarding state is also reduced, as a single forwarding entry can support up to 8 BAs. - operation of Diff-Serv MPLS over E-LSPs is analogous to operations of Diff-Serv in non-MPLS networks in the sense that the Diff-Serv PHB is triggered exclusively by a field explicitly encoded in every packet based on locally configured PHB mapping. This is expected to facilitate migration from non-MPLS Diff-Serv to MPLS Diff-Serv operations in some networks. - some early implementations of E-LSPs exist today and experiments have confirmed proper operations and usefulness. E-LSPs only allow support of eight BAs or less. Le Faucheur et. al 3 MPLS Support of Diff-Serv October 99 1.3 Label-Inferred-PSC LSPs (L-LSP) Section 3 below specifies how a separate LSP can be established for each pair between two LSR neighbors. With such LSPs, the PSC is explicitly signaled at label establishment time so that, after label establishment, the LSR can infer 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 encapsulating the labeled packet using link layer specific drop precedence (eg. Cell Loss Priority). We refer to such LSPs as "Label-Inferred-PSC LSPs" (L-LSP). Detailed operations of L-LSPs are specified in section 3 below. L-LSPs allow support of any number of Behavior Aggregates. L-LSPs have the following drawbacks: - they require the use of a separate label for support of each PSC, and - they require more signaling operations to set up the corresponding L-LSPs. 1.4 Overall Operations For a given FEC, and unless media specific restrictions apply as identified in the corresponding sections below (eg. `MPLS Support of Diff-Serv by ATM LSRs'), this specification allows any one of the following set of 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 from the set of allowed combinations in order to best match his/her environment and objectives in terms of Diff-Serv support, Traffic Engineering and Fast Restoration. Examples of deployment scenarios are provided for information in APPENPIX B. 1.5 Label Forwarding Model for Diff-Serv LSRs In order to describe Label Forwarding by Diff-Serv LSRs, we model the LSR Diff-Serv label switching behavior as comprising three stages: -A- incoming PHB and FEC determination Le Faucheur et. al 4 MPLS Support of Diff-Serv October 99 -B- Optional outgoing PHB determination via Local Policy and Traffic Conditioning -C- Outgoing EXP(and possibly CLP/DE) and label determination, enforcement of outgoing PHB's forwarding behavior This model is used below for specifying LSR Label Forwarding using L-LSPs and E-LSPs for Diff-Serv support over MPLS. 1.6 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.' In line with this, we observe that: - With E-LSPs, the label represents the combination of a FEC and the set of E-LSP transported Behavior Aggregates (BAs). Where all the MPLS supported BAs are transported over E-LSPs, the label then represents the complete FEC. - With L-LSPs, the label represents the combination of a FEC and an Ordered Aggregate (OA). 2. Detailed Operations of E-LSPs 2.1 E-LSP Establishment 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]; - the Diff-Serv Code Point field (DSCP) is 6-bit long [DIFF_HEADER] but when 8 (or less) BAs are used, the DSCP values can be mapped entirely into the 3-bit long EXP field of the MPLS label stack entry; We define that: - one LSP established for a given Forwarding Equivalent Class (FEC) may be used for transport of up to eight BAs of that FEC; - 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 is inferred from the EXP field of the MPLS Shim Header; Le Faucheur et. al 5 MPLS Support of Diff-Serv October 99 - the set of transported BAs can span one or multiple OAs; - 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. MPLS specifies how LSPs can be established via multiple signaling protocols. Those include the Label Distribution Protocol (LDP), RSVP, BGP and PIM. This document specifies below, respectively in section 4 and section 5, how RSVP and LDP are to be used for establishment of E-LSPs. 2.2 Label Forwarding 2.2.1 Incoming PHB and FEC Determination On Ingress E-LSP When receiving a labeled packet over a E-LSP of an MPLS ingress interface, the LSR: - determines the FEC based on the incoming label - determines the incoming PHB by looking at the EXP field of the top level label entry and then by looking up the PHB<-->EXP mapping defined below in section 2.3. If the EXP field value of a packet received on an E-LSP is not listed in the mapping defined in section 2.3, this EXP value should be considered invalid. LSR behavior in such situation is a local matter and is outside the scope of this document. 2.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 Behavior Aggregate demotion or promotion inside an MPLS Diff-Serv domain. 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"). 2.2.3 Outgoing EXP Field And Label Determination On Egress E-LSP Once the outgoing PHB has been determined by the LSR as a function of the incoming PHB and of the optional Local Policy and Traffic Conditioning, the LSR: Le Faucheur et. al 6 MPLS Support of Diff-Serv October 99 - determines via local configuration that the outgoing PHB is one of the PHBs supported by the E-LSP and determines the egress E- LSP label for the packet's FEC - determines the value to be written in the EXP field of the top level label entry (and possibly of other level label entries in the case of a hierarchical tunnel entry) by looking up the PHB<-->EXP mapping defined below in section 2.3 for the outgoing PHB. - SHALL apply the scheduling/dropping behavior corresponding to the Outgoing PHB in compliance with the corresponding Diff-Serv PHB specification. 2.2.4 Simplified Forwarding When Local Policy and Traffic Conditioning are not to be performed by the LSR and the labeled packet is received on a E-LSP and is forwarded onto an E-LSP, the Forwarding operation is simplified since: - the EXP field does not need to be modified - the outgoing label determination depends exclusively on the incoming label (ie does not depend on Local Policy and Traffic Conditioning). The outgoing label is determined from the Incoming Label Map (ILM) using the same procedures as with non Diff-Serv LSPs (ie the incoming label is used as the index into the ILM to identify the NHLFE independently of the Diff-Serv operations) - the scheduling/dropping behavior to be applied is determined exclusively from the unmodified EXP field value. 2.3 PHB<-->EXP field mapping Like the mapping between PHBs and DSCPs in a Diff-Serv network, the mapping between PHB and EXP field is a local matter to be defined by the Service Provider and configured on every LSR. LSRs supporting E-LSPs must allow configuration of PHB<-->EXP mapping. This mapping applies to all the E-LSPs established on this LSR (over interfaces belonging to a given MPLS Diff-Serv domain). The PHB<-->EXP mapping must be consistent at every LSP hop throughout the MPLS Diff-Serv domain spanned by the LSP. This is achieved via consistent configuration by the network operator within the MPLS Diff-Serv domain. Clearly, if different Behavior Aggregates transported over an E-LSP are to be treated differently in the MPLS Diff-Serv cloud, different values of the EXP field are to configured in the PHB<-->EXP mapping for the corresponding PHBs. 2.4 E-LSP Merging Le Faucheur et. al 7 MPLS Support of Diff-Serv October 99 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. Since the BAs/PHBs supported over an E-LSP is not signalled at establishment time, an LSR can not rely on signaling information to enforce the above merge condition (ie that merged LSPs do support the exact same set of BAs). However all E-LSPs are to use the same PHB<-->EXP mapping, and transport the same set of Behavior Aggregates, within a given MPLS Diff-Serv domain. Thus, E-LSP merging is allowed within a given MPLS Diff-Serv domain. E-LSP Merging at a boundary between two MPLS Diff-Serv domains is for further study. 3. Detailed Operation of L-LSPs 3.1 L-LSP Establishment 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 case of Shim Header and 1-bit CLP/DE bit in case of ATM/Frame Relay). - The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER]. 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); - Some Service Providers have a requirement for fine grain Traffic Engineering (such as per OA Traffic Engineering) We propose that: - All packets belonging to a single OA and the same Forwarding Equivalent Class (FEC) be sent down a single LSP; - One LSP be established per pair (rather than simply one LSP per FEC as in an MPLS network that does not support Diff- Serv). Such an LSP is referred to as a "Label-inferred-PSC" LSP or "L-LSP"; - Multiple BAs belonging to the same OA be granted different Drop Precedence (DP) values through appropriate coding of the relevant Le Faucheur et. al 8 MPLS Support of Diff-Serv October 99 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). MPLS specifies how LSPs can be established via multiple signaling protocols. Those include the Label Distribution Protocol (LDP), RSVP, BGP and PIM. This document specifies, respectively in section 4 and section 5, how RSVP and LDP are to be used for establishment of L-LSPs. 3.2 Label Forwarding 3.2.1 Incoming PHB and FEC Determination On Ingress L-LSP When receiving a labeled packet over an L-LSP of an MPLS ingress interface, the LSR: - determines the FEC based on the incoming label - determines the PSC from the incoming label among the set of LSPs established for that FEC - determines the incoming PHB from the PSC and the EXP/CLP/DLE field of the top level label entry in accordance with the PSC/EXP(resp PSC/CLP, PSC/DE) -->PHB mappings defined below in sections 6.3 (resp 7.2 and 8.2). 3.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic Conditioning This stage of Diff-Serv label switching is independent of the ingress/egress interface media type and method used for MPLS Diff- Serv support. It is optional and may be used on an LSR to perform Behavior Aggregate demotion or promotion inside an MPLS Diff-Serv domain. For the purpose of specifying a Diff-Serv over MPLS method, we simply note that the PHB to be actually enforced by an LSR (referred to as "outgoing PHB") may be different to the PHB which had been associated with the packet at the previous LSR (referred to as "incoming PHB"). 3.2.3 Outgoing EXP/CLP/DE Field and Label Determination on Egress L- LSP Once the outgoing PHB has been determined by the LSR as a function of the incoming PHB and of the optional Local Policy and Traffic Conditioning, the LSR: - determines via local configuration that the outgoing PHB is one of the PHBs supported by a L-LSP and determines the egress L-LSP label for the packet's FEC - determines the value to be written in the EXP/CLP/DLE field of the top level label entry (and possibly of other level label entries in the case of a hierarchical tunnel entry) by performing the outgoing PHB-->EXP/PSC (resp CLP/PSC, DE/PSC) mapping defined in sections 6.4 (resp 7.3 and 8.3). Le Faucheur et. al 9 MPLS Support of Diff-Serv October 99 - SHALL apply the scheduling/dropping behavior corresponding to the "Outgoing PHB" in compliance with the corresponding Diff-Serv PHB specification. 3.2.4 Simplified Forwarding When Local Policy and Traffic Conditioning are not to be performed by the LSR, and when the labeled packet is received on a L-LSP on the ingress interface and is going out onto a L-LSP on an egress interface of the same type, the Forwarding operation is simplified since: - the EXP/CLP/DE field does not need to be modified - the outgoing label determination depends exclusively on the incoming label (ie does not depend on Local Policy and Traffic Conditioning). The outgoing label is determined from the Incoming Label Map (ILM) using the same procedures as with non Diff-Serv LSPs (ie the incoming label is used as the index into the ILM to identify the NHLFE independently of the Diff-Serv operations) - the scheduling behavior to be applied is determined exclusively from the Diff-Serv information stored in the NHLFE for the incoming label - the dropping behavior to be applied is determined exclusively from the Diff-Serv information stored in the NHLFE for the incoming label and from the incoming EXP/CLP/DE field More information is provided below in the sections titled `RSVP extensions for Diff-Serv Support' and `LDP extensions for Diff-Serv Support' on what is the Diff-Serv information stored in NHLFEs. 3.3 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 are associated with the same PSC. 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). 4. 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 Le Faucheur et. al 10 MPLS Support of Diff-Serv October 99 [RSVP_MPLS_TE], to establish label switched path (LSPs) supporting Differentiated Services in MPLS networks. 4.1 Diff-Serv related RSVP Messages Format One new RSVP Object is defined in this document: the DIFFSERV_PSC 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_PSC 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. 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_PSC 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_PSC Object is optional for support of LSP Tunnels as defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs in compliance with this specification MAY support the DIFFSERV_PSC Object. A Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST support the DIFFSERV_PSC Object. 4.1.1 Path Message Format The format of the Path message is as follows: ::= [ ] [ ] [ ] [ ] [ ... ] [ ] ::= [ ] [ ] [ ] 4.2 DIFFSERV_PSC Object As stated earlier, the PHB Scheduling Class associated with an L-LSP is to be specified through a new DIFFSERV_PSC object in RSVP Path messages. The DIFFSERV_PSC object has the following format : Le Faucheur et. al 11 MPLS Support of Diff-Serv October 99 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | T |PSCnb| PSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length This is set to 4. Class-Num The Class-Num for a DIFFSERV_PSC object is [TBD] and identifies a new object Class called the "Class Of Service" Class (COS Class). (The Class-Num is to be allocated by IANA with the form 0bbbbbbb) C-Type The C-Type for a DIFFSERV_PSC object is 1. Reserved This field is set to all zeros T This indicates the `LSP Type'. The following values are specified: T Value LSP type 00 E-LSP 01 L-LSP PSCnb Indicates the number of PSC values included in the PSC object. This is set to 001. PSC The PSC indicates the PHB Scheduling Class to be supported by the L-LSP. The 16-bit 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 12 MPLS Support of Diff-Serv October 99 - 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 0 1 0 1 0| 0 0 0 0 0 0 0 0 1 0| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4.3 Handling Diff-Serv_PSC 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 using E-LSPs, to establish an E-LSP tunnel with RSVP, the sender creates a Path message with a session type of LSP_Tunnel_IPv4, with the LABEL_REQUEST object and without the DIFFSERV_PSC object. Optionally, to establish an E-LSP over which a single Ordered Aggregate is going to be transported, the sender MAY create a Path message which contains a session type of LSP_Tunnel_IPv4, contains the LABEL_REQUEST object and contains the DIFFSERV_PSC object with its LSP-Type field set to `E-LSP' and its PSC field set to the value of the PSC to be supported on the E-LSP. The destination node of an E-LSP responds to the Path message containing the LABEL_REQUEST object by sending a Resv message containing the LABEL object and no DIFFSERV_PSC object. When receiving a Resv message containing a LABEL object and associated with a Path message which contained a LABEL_REQUEST object and no DIFFSERV_PSC object (or which contained the DIFFSERV_PSC object with its LSP-Type set to E-LSP), assuming the reservation can be accepted and a label can be associated with the reservation, a Diff-Serv E-LSP capable LSR must: - update its Incoming Label Map (ILM) [MPLS_ARCH] to store the necessary Diff-Serv information. This includes the fact that the Next Hop Label Forwarding Entry (NHLFE) corresponds to an E-LSP. This is in accordance with [MPLS_ARCH] which states that the `NHLFE Le Faucheur et. al 13 MPLS Support of Diff-Serv October 99 may also contain any other information needed in order to properly dispose of the packet'. - install the required scheduling and dropping behavior for this NHLFE in order to support Diff-Serv label forwarding as specified for E-LSPs in section 2.2. Where the sender supports Diff-Serv using L-LSPs, to establish an L-LSP tunnel with RSVP, the sender creates a Path message with a session type of LSP_Tunnel_IPv4, with the LABEL_REQUEST object and with the DIFFSERV_PSC object. The DIFFSERV_PSC object has its LSP- Type set to L-LSP and its the PSC value indicating the PHB Scheduling Class to be supported by the L-LSP. An RSVP router that does recognizes the DIFFSERV_PSC object and that receives a path message which contains the DIFFSERV_PSC 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_PSC object'. Those are defined below in the section titled `Diff-Serv Errors'. A node receiving a Path message with the DIFFSERV_PSC object, which recognizes the DIFFSERV_PSC 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 Value'. Those are defined below in the section titled `Diff-Serv Errors'. If a path message contains multiple DIFFSERV_PSC objects, only the first one is meaningful; subsequent DIFFSERV_PSC object(s) must be ignored and not forwarded. Each node along the path records the DIFFSERV_PSC object, when present, in its path state block. The destination node of an L-LSP responds to the Path message containing the LABEL_REQUEST object and the DIFFSERV_PSC object by sending a Resv message containing the LABEL object and no DIFFSERV_PSC object. When receiving a Resv message containing a LABEL object and associated with a Path message which contained a LABEL_REQUEST object and the DIFFSERV_PSC object with its LSP-Type set to L-LSP, assuming the reservation can be accepted and a label can be associated with the reservation, a Diff-Serv L-LSP capable LSR must: - update its ILM to store the necessary Diff-Serv information. This includes the fact that the NHLFE corresponds to an L-LSP and its PSC. - install the required scheduling and dropping behavior for this NHLFE to support Diff-Serv label forwarding as specified for L- LSPs in section 3.2. Le Faucheur et. al 14 MPLS Support of Diff-Serv October 99 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). [RSVP_MPLS_TE] identifies the conditions where LSPs can be merged to constitute a multipoint-to-point LSP. When the LSPs to be merged are L-LSPs, those can only be merged if an additional condition is met: the DIFFSERV_PSC object in their respective path messages must all be strictly identical. 4.4 Non-support of the Diff-Serv_PSC Object An RSVP router that does not recognize the COS Class's Class-Num sends a PathErr with the error code "Unknown object class" toward the sender. An RSVP router that recognizes the COS Class's Class-Num but does not recognize the DIFFSERV_PSC object C-Type, sends a PathErr with the error code "Unknown object C-Type" toward the sender. 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_PSC object (eg. attempt use of E-LSPs as a back-up strategy). 4.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 Unsupported PSC value 2 Unexpected DIFFSERV_PSC object 4.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. Le Faucheur et. al 15 MPLS Support of Diff-Serv October 99 A Path message containing a COS SENDER_TSPEC and not containing a DIFFSERV_PSC object indicates to a Diff-Serv capable LSR that the LSP to be established in an E-LSP without any bandwidth reservation. A Path message containing a COS SENDER_TSPEC and containing a DIFFSERV_PSC object with its LSP-Type set to E-LSP indicates to a Diff-Serv capable LSR that the LSP to be established in an E-LSP without any bandwidth reservation. A Path message containing a COS SENDER_TSPEC and containing a DIFFSERV_PSC object with its LSP-Type set to L-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_PSC LSP Object Type GS/CL No E-LSP with bandwidth reservation GS/CL Yes E-LSP E-LSP with bandwidth reservation GS/CL Yes L-LSP L-LSP with bandwidth reservation COS No E-LSP without bandwidth reservation COS Yes E-LSP E-LSP without bandwidth reservation COS Yes L-LSP L-LSP without bandwidth 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). 5. 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. Two new LDP TLVs are defined in this document: - the `DIFF-SERV_PSC' TLV - the `Release Status' TLV Detailed descriptions of these TLV are provided below. Le Faucheur et. al 16 MPLS Support of Diff-Serv October 99 As described in [LDP], there are two modes for label distribution: Downstream Unsolicited and Downstream on Demand. When an E-LSP is established using Downstream on Demand mode, the Label Request message and the Label Mapping message usually do not include the new Diff-Serv_PSC. In the case where, a single Ordered Aggregate is to be transported over the E-LSP, the Label Request message and the Label Mapping message may optionally include the new Diff-Serv_PSC (with its LSP-type defined below set to `E-LSP'). When an E-LSP is established using Downstream Unsolicited mode, the new Diff-Serv_PSC MUST not be carried in the Label Request message nor in the Label Mapping message. When an L-LSP is established using Downstream on Demand mode, the new DIFF-SERV_PSC TLV MUST be carried in the Label Request Message to indicate the PHB Scheduling Class (PSC) of the LSP and may optionaly be carried in the Label Mapping message. When an L-LSP is established using Downstream Unsolicited mode, the new DIFF-SERV_PSC TLV MUST be carried in the Label Mapping Message to indicate the PHB Scheduling Class (PSC) of the LSP. The Release Status TLV is to be used to include diagnostic information in Label Release messages when handling Diff-Serv related errors. The new Diff-Serv_PSC and Release Status TLVs are optional with respect to LDP. A Diff-Serv capable LSR supporting E-LSPs in compliance with this specification MAY support the Diff-Serv_PSC TLV and the Release Status TLV. A Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST support the Diff- Serv_PSC TLV and the Release Status TLV. 5.1 Diff-Serv related TLVs 5.1.1 Diff-Serv_PSC TLV As stated earlier, the PHB Scheduling Class associated with an L-LSP is to be specified through a new Diff-Serv_PSC TLV in LDP messages. The Diff-Serv_PSC TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type = PSC (0x901) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | T |PSCnb| PSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U BIT =0 Le Faucheur et. al 17 MPLS Support of Diff-Serv October 99 If this new TLV is unknown to the LSR, the LSR must reject the whole message and return a notification F BIT = 0 If this TLV is unknown to a LSR, this new TLV is NOT forwarded. Type The Type of the PSC TLV is: 0x901. Length This is set to 4. Reserved This field is set to all zeros T This indicates the `LSP Type'. The following values are specified: T Value LSP type 00 E-LSP 01 L-LSP PSCnb Indicates the number of PSC values included in the TSC TLV. This is set to 001 PSC Value Encoding of the PSC field is as specified in section 4.2. 5.1.2 Release Status TLV As stated earlier, error codes are to specified through a new Release Status TLV in LDP Label Release messages when E-LSP or L-LSP set-up fails. The Release Status TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type = PSC (0x304) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Le Faucheur et. al 18 MPLS Support of Diff-Serv October 99 U BIT =0 If this new TLV is unknown to the LSR, the LSR must reject the whole message and return a notification F BIT = 0 If this TLV is unknown to a LSR, this new TLV is NOT forwarded. Type The Type of the PSC TLV is: 0x304. Status Code Indicates the reason why the label was released. This field uses the same encoding and values as the `Status Code' word defined for the Notification message. Additional values are defined below, in the section titled `Status Code Values', for this Status Code field in addition to the values currently defined in [LDP]. 5.1.3 Status Code Values The following values are defined for the Status Code field which is used in Notification message and may be used in Label Release messages: Status Code E Status Data Unsupported PSC value 0 0x00000016 Unexpected PSC value 0 0x00000017 Unexpected PSC TLV 0 0x00000018 Unexpected LSP-Type 0 0x00000019 5.2 Diff-Serv Related LDP Messages 5.2.1 Label Request Message In Downstream on Demand mode, the Diff-Serv capable LSR requesting a label for an L-LSP includes the new Diff-Serv_PSC TLV in the Label Request message to signal that the LSP is an L-LSP and to indicate the PSC associated with the LSP. The format of the Label Request message for an L-LSP in Downstream on Demand mode, is as follows: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Le Faucheur et. al 19 MPLS Support of Diff-Serv October 99 | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2.2 Label Mapping Message In Downstream Unsolicited mode, the Diff-Serv capable LSR allocating a label for an L-LSP includes the Diff-Serv_PSC TLV in the Label Mapping message to signal that the LSP is an L-LSP and to indicate the PSC associated with the LSP. The format of the Label Mapping message for an L-LSP in Downstream Unsolicited mode, is as follows: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In Downstream on Demand mode, the Diff-Serv capable LSR allocating a label for an L-LSP in response to a Label Request message containing the Diff-Serv_PSC TLV, may optionally include the same Diff-Serv_PSC TLV in the Label Mapping message to confirm the PSC associated with the LSP. The format of the Label Mapping message for an L-LSP in Downstream Unsolicited mode, is as follows: 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 | Le Faucheur et. al 20 MPLS Support of Diff-Serv October 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSC TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2.3 Label Release Message [LDP] specifies that `an LSR sends a Label Release message to an LDP peer to signal the peer that the LSR no longer needs specific FEC- label mappings previously requested of and/or advertised by the peer.' This specification extends the use of the Label Release message so that, when an LSR cannot accept a label mapping for an E-LSP or an L-LSP, the LSR should send a Label Release message to the LDP Peer to signal the peer that the LSR cannot accept the label mapping. This specification also extends the encoding of the Label Release message so that the new Release Status TLV can optionally be included in the message. Thus the encoding of the Label Release message is: 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Release Status TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2.4 Notification Message This specification allows inclusion of the Diff-Serv_PSC TLV in the Notification. Thus the encoding of the Notification message is: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | Le Faucheur et. al 21 MPLS Support of Diff-Serv October 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv_PSC TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3 Handling of the Diff-Serv_PSC TLV 5.3.1 Handling of the Diff-Serv_PSC TLV in Downstream Unsolicited Mode This section describes operations when the Downstream Unsolicited Mode is used. When allocating a label for an E-LSP, a Diff-Serv capable LSR issues a Label Mapping message without the Diff-Serv_PSC TLV. A Diff-Serv capable LSR receiving a Label Mapping message without the Diff-Serv_PSC TLV, must: - update its Incoming Label Map (ILM) [MPLS_ARCH] to store the necessary Diff-Serv information. This includes the fact that the Next Hop Label Forwarding Entry (NHLFE) corresponds to an E-LSP. - install the required scheduling and dropping behavior for this NHLFE to support Diff-Serv forwarding as specified for E-LSPs in section 2.2. When allocating a label for an L-LSP, a Diff-Serv capable LSR issues a Label Mapping message which contains the Diff-Serv_PSC TLV with its PSC field indicating the PSC of the L-LSP. A Diff-Serv capable LSR receiving a Label Mapping message containing the Diff-Serv_PSC TLV, must: - update its ILM to store the necessary Diff-Serv information. This includes the fact that the NHLFE corresponds to an L-LSP and its PSC. - install the required scheduling and dropping behavior for this LSP to support Diff-Serv forwarding as specified for L-LSPs in section 3.2. A Diff-Serv capable LSR receiving a Label Mapping message with the Diff-Serv_PSC TLV 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 Release Status TLV with a Status Code of `Unsupported PSC Value'. A Diff-Serv capable LSR receiving a Label Mapping message with multiple Diff-Serv_PSC TLVs only considers the first one as meaningful. The LSR must ignore and not forward the subsequent Diff- Serv_PSC TLV(s). 5.3.2 Handling of the Diff-Serv_PSC TLV in Downstream on Demand Mode This section describes operations when the Downstream on Demand Mode is used. Le Faucheur et. al 22 MPLS Support of Diff-Serv October 99 When requesting a label for an E-LSP, a Diff-Serv capable LSR sends a Label Request message without the Diff-Serv_PSC TLV. Optionally, when requesting a lebel for an E-LSP over which a single Ordered Aggregate is to going to be transported, the Diff-Serv capable LSR may send a Label Request message containing the Diff- Serv_PSC TLV with its LSP type set to E-LSP and its PSC field set to the value of the PSC to be supported on the E-LSP. A Diff-Serv capable LSR sending a Label Mapping message in response to a Label Request message which did not contain the Diff-Serv_PSC TLV, must not include Diff-Serv_PSC TLV in this Label Mapping message. A Diff-Serv capable LSR sending a Label Mapping message in response to a Label Request message which contained the Diff-Serv_PSC TLV with its E-LSP type set to E-LSP, may send this Label Mapping message without the Diff-Serv_PSC TLV. Optionally, the LSR may send this Label Mapping message with the Diff-Serv_PSC TLV with its LSP- Type set to E-LSP and its PSC field set to the same value as the one received in the Label Request message. A Diff-Serv capable LSR receiving a Label Mapping message without the Diff-Serv_PSC TLV in response to its Label Request message for an E-LSP, must: - update its ILM to store the necessary Diff-Serv information. This includes the fact that the NHLFE corresponds to an E-LSP. - install the required scheduling and dropping behavior for this NHLFE to support Diff-Serv forwarding as specified for E-LSPs in section 2.2. A Diff-Serv capable LSR receiving a Label Mapping message containing the Diff-Serv_PSC TLV in response to its Label Request message for an E-LSP which did not contain the Diff-Serv_PSC TLV, must reject the label mapping by sending a Label Release message which includes the Label TLV and the Release Status TLV with a Status Code of `Unexpected PSC TLV'. A Diff-Serv capable LSR receiving a Label Mapping message containing the Diff-Serv_PSC TLV in response to its Label Request message for an E-LSP which contained the Diff-Serv_PSC TLV, must compare the received and sent Diff-Serv_PSC TLVs. If those are equal, the LSR must: - update its ILM to store the necessary Diff-Serv information. This includes the fact that the NHLFE corresponds to an E-LSP. - install the required scheduling and dropping behavior for this NHLFE to support Diff-Serv forwarding as specified for E-LSPs in section 2.2. Le Faucheur et. al 23 MPLS Support of Diff-Serv October 99 If those are not equal because they have a different LSP-Type, the LSR must reject the Label Mapping by sending a Label Release message which includes the Label TLV and the Release Status TLV with a Status Code of `Unexpected LSP-Type'. If those are not equal because they have a different PSC value, the LSR must reject the Label Mapping by sending a Label Release message which includes the Label TLV and the Release Status TLV with a Status Code of `Unexpected PSC Value'. When requesting a label for an L-LSP, a Diff-Serv capable LSR sends a Label Request message with the Diff-Serv_PSC TLV which indicates the PSC of the L-LSP. A Diff-Serv capable LSR receiving a Label Request message with the Diff-Serv_PSC TLV containing a PSC value which is not supported or for which no EXP/PSC<-->PHB mapping is configured, must send a Notification message with a Status Code of `Unsupported PSC Value'. A Diff-Serv capable LSR that recognizes the Diff-Serv_PSC 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_PSC TLV. A Diff-Serv capable LSR sending a Label Mapping message in response to a Label Request message which contained the Diff-Serv_PSC TLV, may optionally include the exact same Diff-Serv_PSC TLV in this Label Mapping message. A Diff-Serv capable LSR receiving a Label Mapping message without the Diff-Serv_PSC TLV in response to its Label Request message for an L-LSP, must: - update its ILM to store the necessary Diff-Serv information. This includes the fact that the NHLFE corresponds to an L-LSP and its PSC. - install the required scheduling and dropping behavior for this NHLFE to support Diff-Serv forwarding as specified for L-LSPs in section 3.2. A Diff-Serv capable LSR receiving a Label Mapping message with the Diff-Serv_PSC TLV in response to its Label Request message for an L- LSP, must verify that the Diff-Serv_PSC TLV received in the Label Mapping message is equal to the Diff-Serv_PSC TLV sent in the Label Request message. If those are equal, the LSR must: - update its ILM to store the necessary Diff-Serv information. This includes the fact that the NHLFE corresponds to an L-LSP and its PSC Le Faucheur et. al 24 MPLS Support of Diff-Serv October 99 - install the required scheduling and dropping behavior for this NHLFE to support Diff-Serv forwarding as specified for L-LSPs in section 3.2. If those are not equal because they have a different LSP-Type, the LSR must reject the Label Mapping by sending a Label Release message which includes the Label TLV and the Release Status TLV with a Status Code of `Unexpected LSP-Type'. If those are not equal because they have a different PSC value, the LSR must reject the Label Mapping by sending a Label Release message which includes the Label TLV and the Release Status TLV with a Status Code of `Unexpected PSC Value'. A Diff-Serv capable LSR receiving a Label Mapping message with multiple Diff-Serv_PSC TLVs only considers the first one as meaningful. The LSR must ignore and not forward the subsequent Diff- Serv_PSC TLV(s). 5.4 Non-Handling of the Diff-Serv_PSC TLV An LSR that does not recognize the Diff-Serv_PSC TLV Type, on receipt of a Label Request message or a Label Mapping message containing the Diff-Serv_PSC TLV, must ignore the message and return a Notification message with _Unknown TLV_ Status. 5.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]. 6. MPLS Support of Diff-Serv over PPP 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 PPP links. While sections 7, 8 and 9 focus on other media specific operations, namely ATM, Frame Relay and LAN respectively. This document allows the following set of LSP setup 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. 6.1. E-LSP Operations over PPP Le Faucheur et. al 25 MPLS Support of Diff-Serv October 99 Since MPLS uses the Shim Header for encapuslation over PPP, E-LSPs are supported over PPP. The E-LSP setup, label forwarding and merging operations over PPP follows exactly the procedures defined in section 2. No additional PPP specific procedures are defined for E-LSPs. 6.2 L-LSP Operations over PPP L-LSPs are also supported over PPP. The L-LSP operations over PPP follows the general procedures of section 3. However, the following PPP specific procedures are also defined for L-LSP operations over PPP : - An MPLS PPP ingress interface determines the incoming PHB from the PSC and the EXP field of the top level label entry in accordance with the PSC/EXP -->PHB mappings defined below in section 6.3. - If the EXP field value of a packet received on an L-LSP is such that the PSC/EXP combination is not listed in the mapping of section 6.3, this PSC/EXP combination should be considered invalid. LSR behavior in such situation is a local matter and is outside the scope of this document. - An MPLS PPP egress interface determines the value to be written in the EXP field of the top level label entry (and possibly of other level label entries in the case of a hierarchical tunnel entry) by performing the outgoing PHB-->EXP/PSC mapping defined below in section 6.4. 6.3 PSC/EXP --> PHB mapping The mapping from the L-LSP PSC and the EXP field of the shim header into PHBs is as follows: EXP Field PSC PHB 000 DF -----> DF 000 CSn -----> CSn 000 AFCn -----> AFn1 001 AFCn -----> AFn2 010 AFCn -----> AFn3 000 EF -----> EF 6.4 PHB --> PSC/EXP mapping The mapping from PHBs into the L-LSP PSC and the EXP field of the shim header is as follows: PHB EXP Field PSC DF -----> 000 DF Le Faucheur et. al 26 MPLS Support of Diff-Serv October 99 CSn -----> 000 CSn AFn1 -----> 000 AFCn AFn2 -----> 001 AFCn AFn3 -----> 010 AFCn EF -----> 000 EF 6.5 LSR implementation with PPP interfaces For an LSR implementation with PPP interfaces, support of E-LSPs over the PPP interfaces is mandatory with respect to this specification. A Diff-Serv capable LSR with PPP interfaces MUST support E-LSPs over these PPP interfaces in compliance with this specification. Support of L-LSPs over PPP interfaces by an LSR implementation is optional. A Diff-Serv capable LSR MAY support L-LSPs over PPP interfaces. However, 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 Realy 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. 7. 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 setup combinations per FEC within an MPLS ATM Diff-Serv domain: - any number of L-LSPs. 7.1 L-LSP Operations over ATM The L-LSP operations over ATM follows the general procedures of section 3. However, the following ATM specific procedures are also defined for L-LSP operations over ATM links : Le Faucheur et. al 27 MPLS Support of Diff-Serv October 99 - An MPLS ATM ingress interface determines the incoming PHB from the PSC and the ATM Cell Loss Probability (CLP) bit in accordance with the incoming PSC/CLP-->PHB mapping defined below in section 7.2; - If the CLP value of a packet received on an L-LSP is such that the PSC/CLP combination is not listed in the mapping of section 7.2, this PSC/CLP combination should be considered invalid. LSR behavior in such situation is a local matter and is outside the scope of this document. - An MPLS ATM egress interface determines the value to be written in the ATM Cell Loss Probability (CLP) bit by performing the outgoing PHB-->PSC/CLP mapping defined below in section 7.3. This is performed by an LSR on the Edge of the ATM Diff-Serv MPLS Cloud and is performed by an ATM LSR in the middle of the ATM Diff-Serv MPLS cloud when doing optional Local Policy and Traffic Conditioning. When not doing optional Local Policy and Traffic Conditioning, an LSR in the middle of the ATM Diff-Serv MPLS cloud may simply leave the CLP bit untouched; - when packet is segmented to cells on edge LSR, all cells of the packet SHOULD be encoded with the same CLP bit value. 7.2 PSC/CLP --> PHB mapping The mapping from L-LSP PSC and CLP bit of the ATM cell header into PHBs is as follows: CLP Bit PSC PHB 0 DF -----> DF 0 CSn -----> CSn 0 AFCn -----> AFn1 1 AFCn -----> AFn2 / AFn3 0 EF -----> EF 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 behaviour for AF MUST comply to procedures described in [DIFF_AF] for the case when only two drop precedence levels are supported. 7.3 PHB --> PSC/CLP mapping The mapping from PHBs into the L-LSP PSC and the CLP bit of the ATM cell header is as follows: PHB CLP Bit PSC Le Faucheur et. al 28 MPLS Support of Diff-Serv October 99 DF -----> 0 DF CSn -----> 0 CSn AFn1 -----> 0 AFCn AFn2 -----> 1 AFCn AFn3 -----> 1 AFCn EF -----> 0 EF 7.4 Merging The use of merging is optional. In case that merging of ATM LSPs is used, procedures described in section 3.5. of this specification apply. Additionally, to avoid cell interleaving problems with AAL-5 merging, procedures specified in [MPLS ATM] MUST be followed. 7.5 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 behaviour experienced by a Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be compliant with the corresponding Diff-Serv PHB specifications. 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. 7.6 LSR Implementation With ATM Interfaces For an LSR implementation with ATM interfaces running native ATM MPLS, support of L-LSPs over the ATM interfaces is mandatory with respect to this specification. A Diff-Serv capable LSR with ATM interfaces MUST support L-LSPs over these ATM interfaces in compliance with this specification. 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. 8. 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 setup combinations per FEC within an MPLS Frame Relay Diff-Serv domain: - any number of L-LSPs. Le Faucheur et. al 29 MPLS Support of Diff-Serv October 99 8.1 L-LSP Operations over Frame Relay The L-LSP operations over Frame Relay follows the general procedures of section 3. However, the following Frame Relay specific procedures are also defined for L-LSP operations over Frame Relay links : - An MPLS Frame Relay ingress interface determines the incoming PHB from the PSC and the Frame Relay Discard Eligible(DE) bit in accordance with the incoming PSC/CLP-->PHB mapping defined below in section 8.2; - If the DE value of a packet received on an L-LSP is such that the PSC/DE combination is not listed in the mapping of section 8.2, this PSC/DE combination should be considered invalid. LSR behavior in such situation is a local matter and is outside the scope of this document. - An MPLS Frame Relay egress interface determines the value to be written in the Frame Relay Discard Eligible (DE) bit by performing the outgoing PHB-->PSC/DE mapping defined below in section 8.3. This is performed by an LSR on the Edge of the Frame Relay Diff-Serv MPLS Cloud and is performed by an Frame Relay LSR in the middle of the Frame Relay Diff-Serv MPLS cloud when doing optional Local Policy and Traffic Conditioning. When not doing optional Local Policy and Traffic Conditioning, an LSR in the middle of the Frame Relay Diff-Serv MPLS cloud may simply leave the DE bit untouched; 8.2 PSC/DE --> PHB mapping The mapping from L-LSP PSC and DE bit of the Frame Relay header into PHBs is as follows: DE Bit PSC PHB 0 DF -----> DF 0 CSn -----> CSn 0 AFCn -----> AFn1 1 AFCn -----> AFn2 / AFn3 0 EF -----> EF 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 behaviour for AF MUST comply to procedures described in [DIFF_AF] for the case when only two drop precedence levels are supported. 8.3 PHB --> PSC/DE mapping The mapping from PHBs into the L-LSP PSC and the DE bit of the Frame Relay header is as follows: Le Faucheur et. al 30 MPLS Support of Diff-Serv October 99 PHB DE Bit PSC DF -----> 0 DF CSn -----> 0 CSn AFn1 -----> 0 AFCn AFn2 -----> 1 AFCn AFn3 -----> 1 AFCn EF -----> 0 EF 8.4 Merging The use of merging is optional. In case that merging of Frame Relay LSPs is used, procedures described in section 3.5. of this specification apply as well as procedures in [MPLS FR]. 8.5 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. 8.6 LSR Implementation With Frame Relay Interfaces For an LSR implementation with Frame Relay interfaces running native Frame Relay MPLS, support of L-LSPs over the Frame Relay interfaces is mandatory with respect to this specification. A Diff-Serv capable LSR with Frame Relay interfaces MUST support L-LSPs over these Frame Relay interfaces in compliance with this specification. Support of E-LSPs over Frame Relay interfaces running native Frame Relay MPLS by an LSR implementation is not allowed. 9. 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. Le Faucheur et. al 31 MPLS Support of Diff-Serv October 99 9.1. E-LSP Operations over PPP Text to be written (in particular regarding use of 802.1 COS field). 9.2 L-LSP Operations over PPP Text to be written (in particular regarding use of 802.1 COS field). 9.3 LSR Implementation With LAN Interfaces For an LSR implementation with LAN interfaces, support of E-LSPs over the LAN interfaces is mandatory with respect to this specification. A Diff-Serv capable LSR with LAN interfaces MUST support E-LSPs over these LAN interfaces in compliance with this specification. Support of L-LSPs over LAN interfaces by an LSR implementation is optional. A Diff-Serv capable LSR MAY support L-LSPs over LAN interfaces. However, 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. 10. Operations at MPLS Diff-Serv Boundaries 10.1 Operations at E-LSP/L-LSP Boundary Within Single MPLS Diff-Serv Domain Text to be added 10.2 Operations At Boundary across Diff-Serv domains Text to be added 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. Le Faucheur et. al 32 MPLS Support of Diff-Serv October 99 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-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. 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'. Le Faucheur et. al 33 MPLS Support of Diff-Serv October 99 Detailed specification for usage of this MPLS ECN bit is outside the scope of this specification. For ECN-capable E-LSPs, the PHB<-->EXP mapping defined above in the section titled `PHB<-->EXP Field Mapping' and configured on the LSR 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 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 PSC/EXP-->PHB mapping defined above in the section titled `PSC/EXP-->PHB 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 AFCn -----> AFn1 e01 AFCn -----> AFn2 e10 AFCn -----> 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 titled `PHB--> PSC/EXP Mapping' 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 AFCn AFn2 -----> e01 AFCn AFn3 -----> e10 AFCn EF -----> e00 EF where `e' is the MPLS ECN bit and can take the value zero or one depending on ECN operations. Le Faucheur et. al 34 MPLS Support of Diff-Serv October 99 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 PHB<-->EXP mapping defined in the section titled `PHB<-->EXP 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 This document has benefited from discussions with K. K. Ramakrishnan, Eric Rosen, Angela Chiu and Carol Iturralde. APPENDIX A. Ordered Aggregate (OA) and PHB Scheduling Class (PSC) This Appendix contains the definition of two Diff-Serv concepts: - the Ordered Aggregate (OA) - the PHB Scheduling Class (PSC) In the future, it is expected that these definitions will be incorporated in new versions of the Diff-Serv specifications. A.1 Ordered Aggregate (OA) [DIFF_AF] states that "a DS node does not reorder IP packets of the same microflow if they belong to the same AF class" (even if different packets of the microflow contain different AF codepoints of the same AF class). For the sake of generality, we define a set of Behavior Aggregates which share such an ordering constraint to constitute a "Ordered Aggregate" (OA). A.2 PHB Scheduling Class (PSC) We refer to the set of one or more PHBs applied to the set of Behavior Aggregates forming a given OA, as a "PHB Scheduling Class" (PSC). The PHBs currently specified are Default PHB (DF), Class Selector PHB group (CSx), Assured Forwarding PHB group (AFxy), Expedited Forwarding PHB (EF). Le Faucheur et. al 35 MPLS Support of Diff-Serv October 99 A.2.1 DF PSC The Default PHB is a single PHB specified in [DIFF_Header]. Thus, the corresponding PSC comprises a single PHB and thus coincides with the DF PHB. A.2.2 CSn PSC [DIFF_HEADER] defines up to 8 CS Codepoints referred to as CSn, where 1 <= i <= 8. [DIFF_HEADER] states that "... PHBs selected by distinct Class Selector Codepoints SHOULD be independently forwarded; that is, packets marked with different Class Selector Codepoints MAY be re-ordered". Thus, there is one PSC corresponding to each CSn PHB. Each CSn PSC comprises a single PHB and thus coincides with this CSn PHB. A.2.3 AFn PSC As described in [DIFF_AF], the Assured Forwarding (AF) PHB group provides forwarding of IP packets in N independent AF classes. Within each AF class, an IP packet is assigned one of M different levels of drop precedence. An IP packet that belongs to an AF class i and has drop precedence j is marked with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4) with three levels of drop precedence in each class (M=3) are defined for general use. [DIFF_AF] states that "a DS node does not reorder IP packets of the same microflow if they belong to the same AF class" (even if different packets of the microflow contain different AF codepoints of the same AF class). As noted above, each AF class in the AF PHB group is the primary example of a PSC. Each PSC comprises 3 PHBs and coincides with the AF Class. Those PSCs are thus referred to as AFn, where 1 <= n <= 4. A.2.4 EF PSC [DIFF_EF] defines the Expedited Forwarding (EF) PHB for traffic requiring forwarding with low loss, low latency, low jitter. [DIFF_EF] defines a single PHB. Thus, the corresponding PSC comprises a single PHB and thus coincides with the DF PHB. A.2.5 Summary list of PSC The following PSCs have thus been identified: - DF - CSn , 1 <= i <= 8 - AFn, 1 <= i <= 4 - EF APPENDIX B. Example Deployment Scenarios Le Faucheur et. al 36 MPLS Support of Diff-Serv October 99 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. B.1 Scenario 1: 8 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. 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 bandwdith 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_PSC TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP) B.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 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: - 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 Le Faucheur et. al 37 MPLS Support of Diff-Serv October 99 - 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_PSC TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP) - LSRs signal establishment of one L-LSP per for the other BAs using LDP as specified above (ie Diff-Serv_PSC TLV in LDP Label Request/Label Mapping messages to indicate the L-LSP's PSC). B.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]. Operations can be summarized as follows: - the Service Provider configures at every LSR the bidirectional 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 the RSVP protocol as specified above (ie no DIFFSERV_PSC RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR * using the CR-LDP protocol as specified above (ie no Diff- Serv_PSC TLV in LDP Label Request/Label Mapping messages). B.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 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 : Le Faucheur et. al 38 MPLS Support of Diff-Serv October 99 * using the RSVP as specified above to signal the L-LSP's PSC (ie DIFFSERV_PSC 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_PSC TLV in LDP Label Request/Label Mapping messages). B.5 Scenario 5: less than 8 BAs, per-OA Traffic Engineering/Fast Reroute A Service Provider running less than 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. Operations can be summarized as follows: - the Service Provider configures at every LSR the bidirectional 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 L-LSP per : * using the RSVP protocol as specified above to signal that the LSP is an E-LSP (ie no DIFFSERV_PSC 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 (ie no Diff-Serv_PSC 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 packets belonging to a given OA are forwarded on the E-LSP established for the corresponding FEC and corresponding OA. B.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 established via LDP to support the set of 8 (or less) non-traffic-engineered/non-fast-rerouted BAs, AND Le Faucheur et. al 39 MPLS Support of Diff-Serv October 99 - 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_PSC 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_PSC 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_PSC TLV in LDP Label Request/Label Mapping messages). 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. Le Faucheur et. al 40 MPLS Support of Diff-Serv October 99 [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 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: (978)-244-3087 Email: liwwu@cisco.com Bruce Davie Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824 USA Phone: (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 Le Faucheur et. al 41 MPLS Support of Diff-Serv October 99 USA Phone +1 (781) 238-4981 Email: pasi.vaananen@nokia.com Ram Krishnan Nexabit Networks 200 Nickerson Road, Marlboro, MA 01752 USA E-mail: ram@nexabit.com Pierrick Cheval Alcatel 5 rue Noel-Pons 92734 Nanterre Cedex France E-mail: pierrick.cheval@alcatel.fr Le Faucheur et. al 42