F. Le Faucheur Cisco Systems Shahram Davari PMC-Sierra Inc. Ram Krishnan Nexabit Networks Pasi Vaananen Nokia B. Davie Cisco Systems IETF Internet Draft Expires: December, 1999 Document: draft-lefaucheur-mpls-diff-ppp-00.txt June, 1999 MPLS Support of Differentiated Services over PPP links 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 proposes a flexible solution for MPLS to support Differentiated Services (Diff-Serv) over PPP links. This solution allows the service provider to flexibly define how Diff-Serv Behavior Aggregates (BAs) are mapped onto LSPs so that he/she can best match the Diff-Serv and Traffic Engineering objectives within his/her particular network. For instance, this solution allows the service provider to decide whether 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 the Behavior Aggregate's scheduling treatment is inferred by the LSR from the packet's label value while the Behavior Le Faucheur, et. al 1 MPLS Support of DiffServ over PPP June 99 Aggregate's drop precedence is indicated in the EXP field of the MPLS PPP Header. - LSPs where both the Behavior Aggregate's scheduling treatment and drop precedence are conveyed to the LSR in the EXP field of the MPLS PPP Header. 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 proposes 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, where LSRs are interconnected via PPP links. 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 proposed in this document aims at allowing Service Providers the flexibility to select how Diff-Serv classes of service should be 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). Beside, the solution proposed in this document aims at maximizing label space usage and minimizing 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. Ordering Constraints, "Scheduling Aggregate (SA)" and "Per Hop Scheduling (PHS) " [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 Le Faucheur et. al 2 MPLS Support of DiffServ over PPP June 99 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 "Scheduling Aggregate_ (SA). The mechanisms described in this draft aim, in particular, to preserve the correct ordering relationships for packets that belong to a given SA. We refer to the set of one or more PHBs applied to the set of Behavior Aggregates forming a given SA, as a _Per Hop Scheduling_ (PHS). The PHBs currently specified are Default PHB (DF), Class Selector PHB group (CSx), Assured Forwarding PHB group (AFxy), Expedited Forwarding PHB (EF). 1.1.1 DF PHS The Default PHB is a single PHB specified in [DIFF_Header]. Thus, the corresponding PHS comprises a single PHB and thus coincides with the DF PHB. 1.1.2 CSn PHS [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 PHS corresponding to each CSn PHB. Each CSn PHS comprises a single PHB and thus coincides with this CSn PHB. 1.1.3 AFCn PHS 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 PHS. Each PHS comprises 3 PHBs and coincides with the AF Class. Those PHSs are thus referred to as AFCn, where 1 <= n <= 4. Le Faucheur et. al 3 MPLS Support of DiffServ over PPP June 99 1.1.4 EF PHS [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 PHS comprises a single PHB and thus coincides with the DF PHB. 1.1.5 Summary list of PHS The following PHSs have thus been identified: - DF - CSn , 1 <= i <= 8 - AFCn, 1 <= i <= 4 - EF 1.2 Label-Inferred-PHS LSPs (L-LSP) We propose below, in section 2, a method for Diff-Serv over MPLS over PPP where one LSP is established per pair between two PPP LSR neighbours. This method relies on explicit signaling of the PHS at label establishment time so that, after label establishment, the LSR can infer from the label value the PHS to be applied to a labeled packets. Drop Precedence to be applied by the LSR to the labeled packet is conveyed inside the packet MPLS Shim Header [MPLS_ENCAPS] using the EXP field. We refer to such LSPs as " Label-Inferred-PHS LSPs" (L-LSP). Detailed Operation of L-LSPs is specified in section 2 below. L-LSPs offer the following benefits: - they support any number of Behavior Aggregates allowed by the Diff-Serv architecture, and - they support separate routing/traffic-engineering of PHSs. L-LSPs have the following drawbacks: - they require the use of separate LSPs for support of different PHSs, and - they require more signaling operations to set up these L-LSPs. 1.3 EXP-Inferred-PHS LSPs (E-LSP) We propose below, in section 3, a method where up to eight BAs can be supported via a single LSP, regardless of how many SAs these BAs span. In this method, the DSCP value get entirely mapped into the EXP field of the MPLS Shim Header [MPLS_ENCAPS] at the Edge of the MPLS PPP Cloud (thus encoding both drop precedence and PHS/scheduling information). In other words, both PHS and Drop Le Faucheur et. al 4 MPLS Support of DiffServ over PPP June 99 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-PHS LSPs" (E-LSP). Detailed Operation of E-LSPs is specified in section 3 below. E-LSPs have the following benefits, where separate routing or separate traffic-engineering of PHSs is not required: - label space is conserved by "packing" 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 network). - label establishment signaling is 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 network) -the amount of forwarding state is 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 have the following drawbacks: - they only support up to eight BAs, and - they do not allow routing/traffic-engineering of individual PHSs. 1.4 Overall Approach We propose a flexible solution for Diff-Serv support by MPLS over PPP links where the Service Provider can use both E-LSPs and L-LSPs in the combination that best match his/her environment and objectives in terms of Diff-Serv support and Traffic Engineering. For instance, a Service Provider who: - supports fewer than eight BAs, and - does not perform traffic engineering or performs aggregate traffic engineering of all SAs jointly, may use a single E-LSP per FEC. A Service Provider who: - performs traffic engineering of each SA separately may use one L-LSP per . A Service Provider who - supports more than eight BAs, and Le Faucheur et. al 5 MPLS Support of DiffServ over PPP June 99 - does not perform traffic engineering or performs traffic engineering of traffic aggregates where one traffic aggregate comprises multiple SAs, may use: - a single E-LSP per FEC for supporting up to eight BAs (BAs corresponding to SAs that can be traffic engineered jointly) - one L-LSP per for supporting other. Those are just examples of how a Service Provider can use combinations of E-LSPs and L-LSPs to best match his/her environment. Clearly, other combinations could be used in the environments described above and other environments can also be supported. When selecting a combination of E-LSPs and L-LSPs to meet some specific Traffic Engineering goals, it is important to note that: - SAs supported by the same E-LSP can be Traffic Engineered jointly. A path is selected for the BAs of all the supported SAs (eg by Constraint Based Routing or by explicit configuration) and the corresponding E-LSP is then established along that path via RSVP or CR-LDP signaling; - SAs supported by the same E-LSP CANNOT be Traffic Engineered separately. Since the BAs of all the transported SAs are to be label switched via the same LSP, all these SAs follow a single path; - SAs supported by separate L-LSPs can be Traffic Engineered separately. A path is selected independently for each SA (eg by Constraint Based Routing or by explicit configuration) and the corresponding L-LSPs are then established independently via RSVP or CR-LDP signaling; - SAs supported by separate L-LSPs can be Traffic Engineered jointly. A path is selected for the aggregate of all the considered SAs and the L-LSPs are then established independently along the same common path via RSVP or CR-LDP signaling; 1.5 Explicit Congestion Notification Explicit Congestion Notification is described in [ECN] and is proposed as an Experimental extension to the IP protocol. Because ECN is still at the Experimental stage and its impact and interactions with Diff-Serv have not yet been specified, this Internet-Draft does not discuss ECN operations. Support for simultaneous Diff-Serv and ECN over MPLS is left for further study. 1.6 Label Forwarding Model for Diff-Serv LSRs In order to describe Label Forwarding by Diff-Serv LSRs, we propose to model a Diff-Serv label switching behavior as comprising three stages: -A- incoming PHB and FEC determination -B- Optional outgoing PHB determination via Local Policy and Traffic Conditioning -C- Outgoing EXP field and label determination Le Faucheur et. al 6 MPLS Support of DiffServ over PPP June 99 The Diff-Serv LSR SHALL apply the scheduling/dropping behavior corresponding to the _Outgoing PHB_ in compliance with the corresponding Diff-Serv PHB specification. With such a model, we expect that "Diff-Serv over MPLS" label forwarding can be specified (from the Diff-Serv viewpoint) separately for each method (eg. Diff-Serv over MPLS over PPP using L-LSPs, Diff-Serv over MPLS over PPP using E-LSPs, Diff-Serv over MPLS over ATM/FR) by specifying -A- and -C- for the considered method without having to specify the complete label switching behavior (A+B+C) for every possible incoming/outgoing combination. This model is used below for specifying LSR Label Forwarding over PPP links using L-LSPs and E-LSPs for Diff-Serv support over MPLS. 2. Detailed Operation of L-LSPs This section is based on [MPLS_DIFF_PPP]. 2.1 L-LSP Establishment Recognizing that: - MPLS over PPP links requires the use of a Shim Header which consists of a label stack with one or more entries [MPLS_ENCAPS]; - The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER], so that when more than 8 BAs are used , the DSCP field can not be mapped entirely into the 3-bit long EXP field of the MPLS label stack entry; - Some Service Providers have a requirement for fine grain Traffic Engineering (such as per SA Traffic Engineering) We propose that: - All packets belonging to a single SA 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-PHS" LSP or "L-LSP"; - Multiple BAs belonging to the same SA be granted different Drop Precedence (DP) values through appropriate coding of the EXP field of the top label entry of the shim header. MPLS specifies how LSPs can be established via multiple signaling protocols. Those include the Label Distribution Protocol (LDP), RSVP, BGP and PIM. This Internet-Draft proposes below, in section Le Faucheur et. al 7 MPLS Support of DiffServ over PPP June 99 2.5, the required extensions to LDP and RSVP to allow establishment of one L-LSP per pair over PPP MPLS. 2.2 Label Forwarding 2.2.1 Incoming PHB and FEC Determination On Ingress L-LSP When receiving a labeled packet over an L-LSP of an MPLS PPP ingress interface, the LSR: - determines the FEC based on the incoming label - determines the PHS from the incoming label among the set of LSPs established for that FEC - determines the incoming PHB from the PHS and the EXP field of the top level label entry in accordance with the PHS/EXP-->PHB mapping defined below in section 2.3. If the EXP field value of a packet received on an L-LSP is such that the PHS/EXP combination is not listed in the mapping of section 2.3, this PHS/EXP combination 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 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"). 2.2.3 Outgoing EXP 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 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/PHS mapping defined below in section 2.4. 2.2.4 Simplified Forwarding Le Faucheur et. al 8 MPLS Support of DiffServ over PPP June 99 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 PPP interface and is going out onto a L-LSP PPP interface, the Forwarding operation is simplified since: - the EXP field does not need to be modified - the outgoing label can be directly determined from the incoming label (ie as in non Diff-Serv capable LSRs) 2.3 PHS/EXP --> PHB Mapping The mapping from L-LSP PHS and from EXP field of the shim header into PHBs is as follows: EXP Field PHS PHB 000 DF -----> DF 000 CSn -----> CSn 000 AFCn -----> AFn1 001 AFCn -----> AFn2 010 AFCn -----> AFn3 000 EF -----> EF 2.4 PHB --> PHS/EXP Mapping The mapping from PHBs into the L-LSP PHS and the EXP field of the shim header is as follows: PHB EXP Field PHS DF -----> 000 DF CSn -----> 000 CSn AFn1 -----> 000 AFCn AFn2 -----> 001 AFCn AFn3 -----> 010 AFCn EF -----> 000 EF 2.5 L-LSP Establishment and Message Format 2.5.1 Signaling extension during L-LSP establishment To support Diff-Serv in MPLS over PPP using L-LSPs, the PHS must be signaled at label establishment time in the MPLS label request messages and MPLS label binding messages. The detailed format of the corresponding message extension is described below when the signaling protocol used is LDP or RSVP. The MPLS control application on each LSR along the L-LSP will process the new PHS attribute and install the corresponding scheduling behavior for that LSP (eg. map the LSP into an output queue associated with the PHS). Le Faucheur et. al 9 MPLS Support of DiffServ over PPP June 99 2.5.2 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 over PPP 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 PHS. Note that when L-LSPs merge, the bandwidth that is available for the PHS 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. 2.5.3 New RSVP Object Format This section defines a new RSVP object class and a new RSVP object within that class for support of Diff-Serv in MPLS over PPP when L-LSPs are established via RSVP [MPLS_RSVP]. The new object Class is defined as the "Class Of Service" Class (COS Class). Its Class-Num is [TBD]. The new RSVP DIFFSERV_PHS object is defined within the COS Class to carry the PHS of the traffic to be transported on the corresponding LSP. Its C-Type is 1. As described in [MPLS_RSVP], bandwidth information may also be signaled at LSP establishment time, for the purpose of Traffic Engineering, using the SENDER_TSPEC Object (in the Path message) and the FLOWSPEC Object (in the Resv message). DIFFSERV_PHS object Class = [TBD], C-Type = 1 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 = 4 | Class-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | PHS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We propose that the 16-bit PHS be encoded as specified in section 2 of [PHBID]. In particular, we propose that the encoding for a PHS be the smallest numerical value of the encodings for the various PHBs in the PHS. In turn, the encoding of a single PHB defined by standards action is the recommended DSCP value for this PHB, left- justified in the 16 bit field, with bits 6 through 15 set to zero. Le Faucheur et. al 10 MPLS Support of DiffServ over PPP June 99 For instance, the encoding of the AFC1 PHS is the encoding of the AF11 PHB. This object may be carried in a PATH message that contains the LABEL_REQUEST object to indicate the PHS for which a label is required. The object may also be carried in a RESV message that contains a LABEL object indicating the PHS for which the label is to be used. 2.5.4 New LDP TLV This section defines a new LDP TLV necessary for support of Diff- Serv in MPLS over PPP when L-LSPs are established via LDP [MPLS_LDP]. We define a new PHS TLV to signal the PHS in a label request or label binding 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type = PHS | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type of the TLV is [TBD]. Encoding of the PHS field is the same as encoding of the PHS in RSVP, as specified in 2.5.3. We propose that the COS TLV which was specified in [LDP_03] (and removed in later version of the LDP specifications) be reincorporated into LDP and used to encode the PHS TLV as a nested TLV (ie encode the PHS TLV in the COS value of the COS TLV). Encoding the PHS TLV as a nested TLV of the COS TLV is proposed for flexibility so that if additional TLVs need to be defined in the future for support of Diff-Serv over MPLS, those TLVs could be logically grouped inside the COS TLV. Alternatively, the PHS TLV could be included in the LDP messages as an independent TLV (ie not nested in the COS TLV). As described in [MPLS_CR_LDP], bandwidth information may also be signaled at LSP establishment time, for the purpose of Traffic Engineering, using the Traffic Parameters TLV. 3 Detailed Operations of E-LSPs 3.1 E-LSP establishment Recognizing that: Le Faucheur et. al 11 MPLS Support of DiffServ over PPP June 99 - MPLS over PPP links requires the use of a Shim Header which consists of a label stack with one or more entries [MPLS_ENCAPS]; - The Diff-Serv Code Point (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; - Some Service Providers do not have requirements for fine grain Traffic Engineering and want to traffic engineer all/multiple SAs jointly. We propose that: - One LSP be established per Forwarding Equivalent Class (FEC) for transport of up to eight BAs of that FEC; - all packets belonging to the same (FEC) and from the set of up to eight BAs (which can span multiple SAs) be sent down this LSP. Such an LSP is referred to as an "EXP-inferred-PHS" LSP or _E-LSP_; - Multiple BAs belonging to the same FEC and transported over the same E-LSP be granted different scheduling treatment and different drop precedence by the PPP MPLS LSR based on the EXP field which is appropriately encoded at label imposition time to reflect both the PHS 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 Internet-Draft specifies below, in section 3.5, how LDP and RSVP are to be used for establishment of an E-LSP over a PPP link for support of up to eight BAs. 3.2 Label Forwarding 3.2.1 Incoming PHB and FEC Determination On Ingress E-LSP When receiving a labelled packet over a E-LSP of an MPLS PPP 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 performing the EXP-->PHB mapping defined below in section 3.4. If the EXP field value of a packet received on an E-LSP is not listed in the mapping of 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. Le Faucheur et. al 12 MPLS Support of DiffServ over PPP June 99 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 by the previous LSR (referred to as "incoming PHB"). 3.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: - 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 performing the outgoing PHB-->EXP mapping defined below in section 3.3. 3.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 PPP interface and is going out onto a E-LSP PPP interface, the Forwarding operation is simplified since: - the EXP field does not need to be modified - the outgoing label can be directly determined from the incoming label (ie as in non Diff-Serv capable LSRs) 3.3 PHB-->EXP field mapping Like the mapping between PHBs and DSCPs in a Diff-Serv network, the mapping from PHB to EXP field is a local matter to be defined by the Service Provider and configured on every LSR. The requirements on this mapping are that: - each of the eight (or less) PHBs to be supported over the E- LSP must map to a different encoding of the 3-bit EXP field (so the mapping can be inverted back from EXP field to PHB at egress) - the mapping must be consistent at every PPP LSP hop throughout the Diff-Serv domain spanned by the LSP 3.4 EXP-->PHB mapping Similarly the mapping from EXP field to PHB is a local matter. The requirement on this mapping is that: Le Faucheur et. al 13 MPLS Support of DiffServ over PPP June 99 - it must be the exact inverse of the PHB to EXP field mapping - it must be consistent at every PPP LSP hop throughout the Diff-Serv domain spanned by the LSP 3.5 Signalling During E-LSP establishment To support Diff-Serv in MPLS over PPP using E-LSPs, the fact that the LSP is a E-LSP must be conveyed in the MPLS label request messages and MPLS label binding messages. The method to achieve this is described below when the signaling protocol used is RSVP or LDP. The MPLS control application on each PPP LSR along the E-LSP will notice that the LSP is a E-LSP and install the corresponding scheduling and drop behavior for that LSP based on the EXP<-->PHB mapping locally configured for E-LSP operations. 3.5.1 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 over PPP using E- LSPs is 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. 3.5.2 RSVP Signaling for E-LSPs A new DIFFSERV_PHS RSVP Object has been defined above in section 2.5.3 to explicitly signal that an LSP is a L-LSP and to indicate the PHS associated with the L-LSP. We propose that no new RSVP Object be defined for E-LSPs. Rather, we propose that the fact that the LSP is an E-LSP be implicitly conveyed by the absence of DIFFSERV_PHS RSVP Object in a PATH message containing a LABEL_REQUEST Object and in a RESV message containing the LABEL Object. 3.5.3 LDP Signaling for E-LSPs A new PHS TLV has been defined above in section 2.5.4 to explicitly signal that an LSP is an L-LSP and to indicate the PHS associated with the LSP. We propose that no new LDP TLV be defined for E-LSPs. Rather, we propose that the fact that the LSP is an E-LSP be implicitly conveyed by the absence of PHS TLV in a label request or label binding message. 4. Example Deployment Scenarios This section does not provide additional specification of the proposed approach and is only here to provide examples of how this Le Faucheur et. al 14 MPLS Support of DiffServ over PPP June 99 flexible approach for Diff-Serv support over MPLS over PPP may be deployed. Pros and cons of various deployment options for particular environments are beyond the scope of this document. 4.1 Scenario 1: 8 BAs, no Traffic Engineering A Service Provider running 8 (or less) BAs and not performing Traffic engineering in his/her network may elect to run Diff-Serv over MPLS over PPP links using a single E-LSP per FEC established via LDP. Operations can be summarized as follows: - the Service Provider configures at every PPP LSR the bi- directional mapping between each PHB and a value of the EXP field - PPP LSRs signal establishment of a single E-LSP per FEC using LDP in accordance with section 3.5.3 above (ie no PHS TLV in LDP label request and label binding messages to implicitly indicate that the LSP is a E-LSP) 4.2 Scenario 2: 8 BAs, no Traffic Engineering A Service Provider running 8 (or less) BAs and not performing Traffic engineering in his/her network may alternatively elect to run Diff-Serv over MPLS over PPP links using one L-LSP per established via LDP. Operations can be summarised as follows: - the Service Provider configures on every PPP LSR the parameters pertaining to the scheduling behavior that should be installed for the L-LSP by the control application for each PHS - PPP LSRs signal establishment of one L-LSP per using the LDP protocol and the LDP extension defined in section 2.5.4 above to signal the L-LSP PHS (ie PHS TLV in LDP label request and label binding messages). 4.3 Scenario 3: 8 BAs, Aggregate Traffic Engineering A Service Provider running 8 (or less) BAs and performing aggregate Traffic Engineering (ie performing a single common path selection for all BAs) in his/her network may elect to run Diff-Serv over MPLS over PPP links 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 PPP LSR the bidirectional mapping between each PHB and a value of the EXP field - PPP LSRs signal establishment of a single E-LSP per FEC using : * the RSVP protocol in accordance with section 3.5.2 above (ie no DIFFSERV_PHS RSVP Object in the PATH message containing the LABEL_REQUEST Object and in the RESV message containing the LABEL Object), OR Le Faucheur et. al 15 MPLS Support of DiffServ over PPP June 99 * using the CR-LDP protocol in accordance with section 2.5.3 above (ie no PHS TLV in LDP label request and label binding messages). 4.3 Scenario 3: per-SA Traffic Engineering Regardless of the number of BAs supported, a Service Provider performing per-SA Traffic Engineering (ie performing a separate path selection for each SA) in his/her network MUST run Diff-Serv over MPLS over PPP links using one L-LSP per pair established via RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE]. Operations can be summarised as follows: - the Service Provider configures on every PPP LSR the parameters pertaining to the scheduling behavior that should be installed for the L-LSP by the control application for each PHS - PPP LSRs signal establishment of one L-LSP per using: * the RSVP protocol and the RSVP extension defined in section 2.5.3 above to signal the L-LSP (ie DIFFSERV_PHS RSVP Object in the PATH message containing the LABEL_REQUEST Object and in the RESV message containing the LABEL Object), OR * using the CR-LDP protocol and the LDP extension defined in section 2.5.4 above to signal the L-LSP PHS (ie PHS TLV in LDP label request and label binding messages). 4.4 Scenario 4: More than 8 BAs, no Traffic Engineering A Service Provider running more than 8 BAs and not performing Traffic Engineering in his/her network may elect to run Diff-Serv over MPLS over PPP links using one L-LSP per pair established via LDP. Operations can be summarised as follows: - the Service Provider configures on every PPP LSR the parameters pertaining to the scheduling behavior that should be installed for the L-LSP by the control application for each PHS - PPP LSRs signal establishment of one L-LSP per using the LDP protocol and the LDP extension defined in section 2.5.4 above to signal the L-LSP PHS (ie PHS TLV in LDP label request and label binding messages). 4.5 Scenario 5: no Traffic Engineering on 8 BAs, per-SA Traffic Aggregate on other BAs. A Service Provider not performing Traffic Engineering on 8 (or less) BAs and performing per-SA Traffic Engineering on the other BAs (ie performing a separate path selection for each SA corresponding to the other BAs) in his/her network may elect to run Diff-Serv over MPLS over PPP links, using for each FEC: - one E-LSP established via LDP to support the set of 8 (or less) non-traffic engineered BAs, Le Faucheur et. al 16 MPLS Support of DiffServ over PPP June 99 AND - one L-LSP per pair established via RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] for support of the other BAs. Operations can be summarised as follows: - the Service Provider configures at every PPP LSR the bi- directional mapping between each PHB of the non-traffic-engineered BAs (supported by the E-LSP) and a value of the EXP field - the Service Provider configures on every PPP LSR the parameters pertaining to the scheduling behavior that should be installed for the L-LSP by the control application for each PHS - PPP LSRs signal establishment of a single E-LSP per FEC for the non-traffic engineered BAs using LDP in accordance with section 3.5.3 above (ie no PHS TLV in LDP label request and label binding messages to implicitly indicate that the LSP is a E-LSP) - PPP LSRs signal establishment of one L-LSP per for the traffic engineered BAs using: * the RSVP protocol and the RSVP extension defined in section 2.5.3 above to signal the L-LSP (ie DIFFSERV_PHS RSVP Object in the PATH message containing the LABEL_REQUEST Object and in the RESV message containing the LABEL Object), OR * using the CR-LDP protocol and the LDP extension defined in section 2.5.4 above to signal the L-LSP PHS (ie PHS TLV in LDP label request and label binding messages). 5. 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. 6. Acknowledgments This document has benefited from discussions with Dan Tappan, Yakov Rekhter, George Swallow, Kathleen Nichols and Brian Carpenter. 7. References [MPLS_ARCH] Rosen et al., "Multiprotocol label switching Architecture", work in progress, (draft-ietf-mpls-arch-04.txt), February 1999. [DIFF_ARCH] Blake et al., "An architecture for Differentiated Services", RFC-2475, December 1998. [MPLS_DIFF_PPP] Davari et al., "MPLS Support of Differentiated Services over PPP links", draft-davari-mpls-diff-ppp-00.txt, April 99. Le Faucheur et. al 17 MPLS Support of DiffServ over PPP June 99 [DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597, June 1999. [DIFF_EF] Heinanen et al., "An Expedited Forwarding PHB", RFC-2598, June 1999. [MPLS_ENCAPS] Rosen et al., "MPLS Label Stack Encoding", work in progress, (draft-ietf-mpls-label-encaps-03.txt), September 1998. [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. [LDP_03] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 03.txt, January 99 [LDP_04] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 04.txt, April 99 [RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999 [CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-01.txt, February 1999 [PHBID] Brim and Carpenter, "Per Hop Behavior Identification Codes", draft-brim-diffserv-phbid-00.txt, April 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 Shahram Davari PMC-Sierra Inc. 105-8555 Baxter Place Burnaby, BC V5A 4V7 Canada E-mail: Shahram_Davari@pmc-sierra.com Ram Krishnan Nexabit Networks 200 Nickerson Road, Marlboro, MA 01752 Le Faucheur et. al 18 MPLS Support of DiffServ over PPP June 99 USA E-mail: ram@nexabit.com Pasi Vanannen Nokia 3 Burlington Woods Drive, Suit 250 Burlington, MA 01803 USA Email: pasi.vaananen@ntc.nokia.com Bruce Davie Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824, USA Phone: (978)-244-8000 Email: bsd@cisco.com Le Faucheur et. al 19