--- 1/draft-ietf-mpls-diff-ext-05.txt 2006-02-05 00:38:11.000000000 +0100 +++ 2/draft-ietf-mpls-diff-ext-06.txt 2006-02-05 00:38:11.000000000 +0100 @@ -13,57 +13,60 @@ Ram Krishnan Nexabit Networks Pierrick Cheval Alcatel Juha Heinanen Telia Finland IETF Internet Draft -Expires: December, 2000 -Document: draft-ietf-mpls-diff-ext-05.txt June, 2000 +Expires: January, 2001 +Document: draft-ietf-mpls-diff-ext-06.txt July, 2000 MPLS Support of Differentiated Services Status of this Memo This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are - Working documents of the Internet Engineering Task Force (IETF), its - areas, and its working groups. Note that other groups may also - distribute working documents as Internet-Drafts. + 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. +Le Faucheur, et. al 1 + MPLS Support of Diff-Serv July 2000 + Abstract This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. -Le Faucheur, et. al 1 - MPLS Support of Diff-Serv June 2000 - This solution allows the MPLS network administrator to select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched - Paths so that he/she can best match the Diff-Serv, Traffic - Engineering and Fast Restoration objectives within his/her - particular network. For instance, this solution allows the network + Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic + Engineering and protection objectives within his/her particular + network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs. This solution relies on combined use of two types of LSPs: - LSPs which can transport multiple Ordered Aggregates, so that the EXP field of the MPLS Shim Header conveys to the LSR the PHB to be applied to the packet (covering both information about the packet's scheduling treatment and its drop precedence). - LSPs which only transport a single Ordered Aggregate, so that the packet's scheduling treatment is inferred by the LSR @@ -90,162 +93,253 @@ the Per Hop Behavior (PHB) that determines the scheduling treatment and, in some cases, drop probability for each packet. This document specifies a solution for supporting the Diff-Serv Behavior Aggregates whose corresponding PHBs are currently defined (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. This solution also offers flexibility for easy support of PHBs that may be defined in the future. As mentioned in [DIFF_HEADER], "Service providers are not required + + Le Faucheur et. al 2 + MPLS Support of Diff-Serv July 2000 + to use the same node mechanisms or configurations to enable service differentiation within their networks, and are free to configure the node parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives". Thus, the solution defined in this document gives Service Providers flexibility in selecting how Diff-Serv classes of service are Routed - - Le Faucheur et. al 2 - MPLS Support of Diff-Serv June 2000 - - or Traffic Engineered within their domain (eg. separate classes of + or Traffic Engineered within their domain (e.g. separate classes of services supported via separate LSPs and Routed separately, all classes of service supported on the same LSP and Routed together). - Similarly, the solution gives Service Providers flexibility in how - Diff-Serv classes of service can be protected via MPLS Fast - Restoration (eg. some classes of service supported via LSPs which - are protected via MPLS Fast Restoration while some other classes of - service are supported via LSPs which are not protected). + + Because MPLS is path-oriented it can potentially provide faster and + more predictable protection and restoration capabilities in the face + of topology changes than conventional hop by hop routed IP systems. + In this document we refer to such capabilities as "MPLS protection". + Although such capabilities and associated mechanisms are outside the + scope of this specification, we note that they may offer different + levels of protection to different LSPs. Since the solution presented + here allow Service Providers to choose how Diff-Serv classes of + services are mapped onto LSPs, the solution also gives Service + Providers flexibility in the level of protection provided to + different Diff-Serv classes of service (e.g. some classes of service + can be supported by LSPs which are protected while some other + classes of service are supported by LSPs which are not protected). Furthermore, the solution specified in this document achieves label space conservation and reduces the volume of label set-up/tear-down signaling where possible by only resorting to multiple LSPs for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or required. This specification allows support of Differentiated Services for both IPv4 and IPv6 traffic transported over an MPLS network. This document only describes operations for unicast. Multicast support is for future study. -1.1 Ordered Aggregate (OA) and PHB Scheduling Class (PSC) + The solution described in this document does not preclude the + signaled or configured use of the EXP bits to support Explicit + Congestion Notification [ECN] simultaneously with Diff-Serv over + MPLS. However, techniques for supporting ECN in an MPLS environment + are outside the scope of this document. - The Diff-Serv model defines [DIFF_NEW] the set of Behavior - Aggregates which share an ordering constraint to constitute an - "Ordered Aggregate (OA)". It also defines the set of one or more - PHBs that are applied to this set of Behavior Aggregates to - constitute a "PHB Scheduling Class (PSC)". +1.1 Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC 2119. + + The reader is assumed to be familiar with the terminology of + [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM] and [MPLS_FR] including the + following: + + EXP EXPerimental (bits) + + Le Faucheur et. al 3 + MPLS Support of Diff-Serv July 2000 + + FEC Forwarding Equivalency Class + + FTN FEC-To-NHLFE Map + + ILM Incoming Label Map + + LC-ATM Label Switching Controlled-ATM (interface) + + LC-FR Label Switching Controlled-Frame Relay (interface) + + LSP Label Switched Path + + LSR Label Switch Router + + MPLS Multi-Protocol Label Switching + + NHLFE Next Hop Label Forwarding Entry + + The reader is assumed to be familiar with the terminology of + [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF] and [DIFF_EF] including the + following: + + AF Assured Forwarding + + BA Behavior Aggregate + + CS Class Selector + + DF Default Forwarding + + DSCP Differentiated Services Code Point + + EF Expedited Forwarding + + PHB Per Hop Behavior + + The reader is assumed to be familiar with the terminology of + [DIFF_NEW] including the following: + + OA Ordered Aggregate. The set of Behavior Aggregates which + share an ordering constraint. + + PSC PHB Scheduling Class. The set of one or more PHB(s) that + are applied to the Behavior Aggregate(s) belonging to a + given OA. For example, AF1x is a PSC comprising the + AF11, AF12 and AF13 PHBs. EF is an example of PSC + comprising a single PHB, the EF PHB. + + The following acronyms are also used: + + CLP Cell Loss Priority + + Le Faucheur et. al 4 + MPLS Support of Diff-Serv July 2000 + + DE Discard Eligibility + + SNMP Simple Network Management Protocol + + Finally, the following acronyms are defined in this specification: + + E-LSP EXP-Inferred-PSC LSP + + L-LSP Label-Only-Inferred-PSC LSP 1.2 EXP-Inferred-PSC LSPs (E-LSP) A single LSP can be used to support up to eight BAs of a given FEC, regardless of how many OAs these BAs span. With such LSPs, the EXP - field of the MPLS Shim Header [MPLS_ENCAPS] is used by the LSR to - determine the PHB to be applied to the packet. This includes both - the PSC and the drop preference. + field of the MPLS Shim Header is used by the LSR to determine the + PHB to be applied to the packet. This includes both the PSC and the + drop preference. We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the PSC of a packet transported on this LSP depends on the EXP field value for that packet. The mapping from EXP field to PHB (ie to PSC and drop precedence) for a given such LSP, is either explicitly signaled at label set-up or relies on a pre-configured mapping. Detailed operations of E-LSPs are specified in section 3 below. 1.3 Label-Only-Inferred-PSC LSPs (L-LSP) A separate LSP can be established for a single pair. With such LSPs, the PSC is explicitly signaled at label establishment time so that, after label establishment, the LSR can infer exclusively from the label value the PSC to be applied to a - - Le Faucheur et. al 3 - MPLS Support of Diff-Serv June 2000 - labeled packet. When the Shim Header is used, the Drop Precedence to be applied by the LSR to the labeled packet, is conveyed inside the - labeled packet MPLS Shim Header using the EXP field [MPLS_ENCAPS]. - When the Shim Header is not used (eg. MPLS Over ATM), the Drop - Precedence to be applied by the LSR to the labeled packet is - conveyed inside the link layer header encapsulation using link layer - specific drop precedence fields (eg. ATM Cell Loss Priority). + labeled packet MPLS Shim Header using the EXP field. When the Shim + Header is not used (e.g. MPLS Over ATM), the Drop Precedence to be + applied by the LSR to the labeled packet is conveyed inside the link + layer header encapsulation using link layer specific drop precedence + fields (e.g. ATM CLP). We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP) since the PSC can be fully inferred from the label without any other - information (eg. regardless of the EXP field value). Detailed + information (e.g. regardless of the EXP field value). Detailed operations of L-LSPs are specified in section 4 below. 1.4 Overall Operations For a given FEC, and unless media specific restrictions apply as - identified in the sections 7, 8, 9 and 10 below, this specification + identified in the sections 7, 8 and 9 below, this specification + + Le Faucheur et. al 5 + MPLS Support of Diff-Serv July 2000 + allows any one of the following combinations within an MPLS Diff- Serv domain: - zero or any number of E-LSPs, and - zero or any number of L-LSPs. The network administrator selects the actual combination of LSPs from the set of allowed combinations and selects how the Behavior Aggregates are actually transported over this combination of LSPs, in order to best match his/her environment and objectives in terms - of Diff-Serv support, Traffic Engineering and Fast Restoration. + of Diff-Serv support, Traffic Engineering and MPLS Protection. Criteria for selecting such a combination are outside the scope of - this specification; However in order to respect ordering - constraints, all packets of a given microflow, possibly spanning - multiple BAs of a given Ordered Aggregate, MUST be transported over - the same LSP. Conversely, each LSP MUST be capable of supporting all - the (active) PHBs of a given PSC. + this specification. + + For a given FEC, there may be more than one LSP carrying the same + OA, for example for purposes of load balancing of the OA; However in + order to respect ordering constraints, all packets of a given + microflow, possibly spanning multiple BAs of a given Ordered + Aggregate, MUST be transported over the same LSP. Conversely, each + LSP MUST be capable of supporting all the (active) BAs of a given + OA. Examples of deployment scenarios are provided for information in APPENPIX A. 1.5 Relationship between Label and FEC [MPLS_ARCH] states in section `2.1. Overview' that: `Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label. In this case, one may say that the label represents the combination of a FEC and a precedence or class of service.' In line with this, we observe that: - With E-LSPs, the label represents the combination of a FEC and - the set of Behavior Aggregates (BAs) transported over the E- - - Le Faucheur et. al 4 - MPLS Support of Diff-Serv June 2000 - - LSP). Where all the supported BAs are transported over an E-LSP, - the label then represents the complete FEC. + the set of BAs transported over the E-LSP). Where all the + supported BAs are transported over an E-LSP, the label then + represents the complete FEC. - With L-LSPs, the label represents the combination of a FEC and - an Ordered Aggregate (OA). + an OA. 1.6 Bandwidth Reservation for E-LSPs and L-LSPs Regardless of which label binding protocol is used, E-LSPs and L-LSPs may be established without bandwidth reservation or with bandwidth reservation. Establishing an E-LSP or L-LSP with bandwidth reservation means that bandwidth requirements for the LSP are signaled at LSP establishment + + Le Faucheur et. al 6 + MPLS Support of Diff-Serv July 2000 + time. Such signaled bandwidth requirements may be used by LSRs at establishment time to perform admission control of the signaled LSP over the Diff-Serv resources provisioned (e.g. via configuration, - SNMP or COPS) for the relevant PSC(s). Such signaled bandwidth - requirements may also be used by LSRs at establishment time to - perform adjustment to the Diff-Serv resources associated with the - relevant PSC(s) (e.g. adjust PSC scheduling weight). + SNMP or policy protocols) for the relevant PSC(s). Such signaled + bandwidth requirements may also be used by LSRs at establishment + time to perform adjustment to the Diff-Serv resources associated + with the relevant PSC(s) (e.g. adjust PSC scheduling weight). Note that establishing an E-LSP or L-LSP with bandwidth reservation does not mean that per-LSP scheduling is necessarily required. Since E-LSPs and L-LSPs are specified in this document for support of Differentiated Services, the required forwarding treatment (scheduling and drop policy) is defined by the appropriate Diff-Serv PHB. This forwarding treatment MUST be applied by the LSR at the granularity of the BA and MUST be compliant with the relevant PHB specification. @@ -260,41 +354,41 @@ E-LSP, the signaled bandwidth is associated collectively to the whole LSP and therefore to the set of transported PSCs. Thus, LSRs which use the signaled bandwidth to perform admission control may perform admission control over global resources which are shared by the set of PSCs (e.g. over the total bandwidth of the link). Examples of scenarios where bandwidth reservation is not used and scenarios where bandwidth reservation is used are provided for information in APPENDIX B. - Le Faucheur et. al 5 - MPLS Support of Diff-Serv June 2000 - 2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models 2.1 Label Forwarding Model for Diff-Serv LSRs Since different Ordered Aggregates of a given FEC may be transported over different LSPs, the label swapping decision of a Diff-Serv LSR clearly depends on the forwarded packet's Behavior Aggregate. Also, since the IP DS field of a forwarded packet may not be directly visible to an LSR, the way to determine the PHB to be applied to a received packet and to encode the PHB into a transmitted packet is - different to a non-MPLS Diff-Serv Router. + different than a non-MPLS Diff-Serv Router. Thus, in order to describe Label Forwarding by Diff-Serv LSRs, we model the LSR Diff-Serv label switching behavior as comprising four stages: - Incoming PHB Determination (A) - - Optional Outgoing PHB Determination via Local Policy and Traffic - Conditioning (B) + + Le Faucheur et. al 7 + MPLS Support of Diff-Serv July 2000 + + - Outgoing PHB Determination with Optional Traffic Conditioning(B) - Label Swapping (C) - Encoding of Diff-Serv information into Encapsulation Layer (EXP, CLP, DE, User_Priority) (D) Each stage is described in more details in the following sections. Obviously, to enforce the Diff-Serv service differentiation the LSR MUST also apply the forwarding treatment corresponding to the Outgoing PHB. @@ -307,104 +401,104 @@ -Encaps->I===I--Inc_PHB->I B I \ /->I===I (*) I===I \--------+ \----Forwarding--> Treatment (PHB) `Encaps' designates the Diff-Serv related information encoded in the MPLS Encapsulation layer (eg EXP field, ATM CLP, Frame Relay DE, 802.1 User_Priority) - (*) when the LSR performs label imposition, the incoming packet is - received unlabelled. + (*) when the LSR behaves as an MPLS ingress node, the incoming + packet may be received unlabelled. - (**) when the LSR performs label disposition, the outgoing packet is - transmitted unlabelled. + (**) when the LSR behaves as an MPLS egress node, the outgoing + packet may be transmitted unlabelled. This model is presented here to describe the functional operations of Diff-Serv LSRs and does not constrain actual implementation. - Le Faucheur et. al 6 - MPLS Support of Diff-Serv June 2000 - 2.2 Incoming PHB Determination This stage determines which Behavior Aggregate the received packet belongs to. 2.2.1 Incoming PHB Determination Considering a Label Stack Entry Sections 3.3 and 4.3 provide the details on how to perform incoming PHB Determination considering a given received label stack entry and/or received incoming MPLS encapsulation information depending on - the incoming LSP type corresponding to the considered stack entry - and depending on the incoming MPLS encapsulation. + the incoming LSP type and depending on the incoming MPLS + encapsulation. Section 2.6 provides the details of which label stack entry to consider for the Incoming PHB Determination depending on the supported Diff-Serv tunneling mode. + Le Faucheur et. al 8 + MPLS Support of Diff-Serv July 2000 + 2.2.2 Incoming PHB Determination Considering IP Header Section 2.6 provides the details of when the IP Header is to be considered for incoming PHB determination depending on the supported - Diff-Serv tunneling mode. In those cases where the IP header is to + Diff-Serv tunneling model. In those cases where the IP header is to be used, this stage operates exactly as with a non-MPLS IP Diff-Serv Router and uses the DS field to determine incoming PHB. -2.3 Optional Outgoing PHB Determination Via Local Policy And Traffic -Conditioning +2.3 Outgoing PHB Determination With Optional Traffic Conditioning - This stage of Diff-Serv label switching is optional and may be used - on an LSR to perform traffic conditioning including Behavior - Aggregate demotion or promotion. It is outside the scope of this + The traffic conditioning stage is optional and may be used on an LSR + to perform traffic conditioning including Behavior Aggregate + demotion or promotion. It is outside the scope of this specification. For the purpose of specifying Diff-Serv over MPLS forwarding, we simply note that the PHB to be actually enforced, and conveyed to downstream LSRs, by an LSR (referred to as "outgoing PHB") may be different to the PHB which had been associated with the packet by the previous LSR (referred to as "incoming PHB"). - When this stage is not present, the "outgoing PHB" is simply - identical to the "incoming PHB". + + When the traffic conditioning stage is not present, the "outgoing + PHB" is simply identical to the "incoming PHB". 2.4 Label Swapping [MPLS_ARCH] describes how label swapping is performed by LSRs on incoming labeled packets using an Incoming Label Map (ILM), where each incoming label is mapped to one or multiple NHLFEs. [MPLS_ARCH] also describes how label imposition is performed by LSRs on incoming unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each incoming FEC is mapped to one or multiple NHLFEs. A Diff-Serv Context for a label is defined as comprising: - `LSP type (ie E-LSP or L-LSP)' - `supported PHBs' - - Le Faucheur et. al 7 - MPLS Support of Diff-Serv June 2000 - - `Encaps-->PHB mapping' for an incoming label - `Set of PHB-->Encaps mappings' for an outgoing label The present specification defines that a Diff-Serv Context is stored in the ILM for each incoming label. [MPLS_ARCH] states that the `NHLFE may also contain any other information needed in order to properly dispose of the packet'. In accordance with this, the present specification defines that a Diff- Serv Context is stored in the NHLFE for each outgoing label which is swapped or pushed. This Diff-Serv Context information is populated into the ILM and the FTN at label establishment time. If the label corresponds to an E-LSP for which no EXP<-->PHB mapping has been explicitly signaled at LSP setup, the `supported PHBs' is + + Le Faucheur et. al 9 + MPLS Support of Diff-Serv July 2000 + populated with the set of PHBs of the preconfigured EXP<-->PHB Mapping, which is discussed below in section 3.2.1. If the label corresponds to an E-LSP for which an EXP<-->PHB mapping has been explicitly signaled at LSP setup, the `supported PHBs' is populated with the set of PHBs of the signaled EXP<-->PHB mapping. If the label corresponds to an L-LSP, the `supported PHBs' is populated with the set of PHBs forming the PSC that is signaled at LSP set-up. @@ -426,264 +520,102 @@ In accordance with this, the present specification allows that an incoming label [respectively FEC] may be mapped, for Diff-Serv purposes, to multiple NHLFEs (for instance where different NHLFEs correspond to egress labels supporting different sets of PHBs). When a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv LSR MUST choose one of the NHLFEs whose Diff-Serv Context indicates that it supports the Outgoing PHB of the forwarded packet. When a label [respectively FEC] maps to multiple NHLFEs which supports the Outgoing PHB, the procedure for choosing one among - - Le Faucheur et. al 8 - MPLS Support of Diff-Serv June 2000 - those is outside the scope of this document. This situation may be encountered where it is desired to do load balancing of a Behavior Aggregate over multiple LSPs. In such situations, in order to respect ordering constraints, all packets of a given microflow MUST be transported over the same LSP. 2.5 Encoding Diff-Serv Information Into Encapsulation Layer This stage determines how to encode the fields which convey Diff- - Serv information in the transmitted packet (eg. MPLS Shim EXP, ATM + Serv information in the transmitted packet (e.g. MPLS Shim EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority). 2.5.1 Encoding Diff-Serv Information Into Transmitted Label Entry Sections 3.5 and 4.5 provide the details on how to perform Diff-Serv information encoding into a given transmitted label stack entry and/or transmitted MPLS encapsulation information depending on the + + Le Faucheur et. al 10 + MPLS Support of Diff-Serv July 2000 + corresponding outgoing LSP type and depending on the MPLS encapsulation. Section 2.6 provides the details of which label stack entry to perform Diff-Serv information encoding into depending on the supported Diff-Serv tunneling mode. 2.5.2 Encoding Diff-Serv Information Into Transmitted IP Header - This paragraph defines how to perform Diff-Serv Information Encoding - into the transmitted packet IP header. - To perform Diff-Serv Information Encoding into the transmitted packet IP header, this stage operates exactly as with a non-MPLS IP Diff-Serv Router and encodes the DSCP of the Outgoing PHB into the DS field. Section 2.6 provides the details of when Diff-Serv Information Encoding is to be performed into transmitted IP header depending on the supported Diff-Serv tunneling mode. 2.6 Diff-Serv Tunneling Models over MPLS -2.6.1 Terminology - - As per [MPLS_ARCH], - "we can speak of the level m LSP for Packet P as the sequence of - routers: - - 1. which begins with an LSR (an "LSP Ingress") that pushes on a - level m label, - 2. all of whose intermediate LSRs make their forwarding decision - by label Switching on a level m label, - 3. which ends (at an "LSP Egress") when a forwarding decision is - made by label Switching on a level m-k label, where k>0, or when - - Le Faucheur et. al 9 - MPLS Support of Diff-Serv June 2000 - - a forwarding decision is made by "ordinary", non-MPLS forwarding - procedures." - - We note that if Penultimate Hop Popping (PHP) is used on the LSP, - the label pop for the LSP is not performed by the LSP Egress but - instead is performed by the Penultimate LSR. If PHP is not used, - then the label pop for the LSP is performed by the LSP Egress. - - In all the figures below, (I) indicates "LSP Ingress", (P) indicates - "LSP Penultimate Hop" and (E) indicates "LSP Egress". - -2.6.2 Diff-Serv Tunneling Models +2.6.1 Diff-Serv Tunneling Models [DIFF_TUNNEL] considers the interaction of Differentiated Services with IP tunnels of various forms. MPLS LSPs are not a form of "IP tunnels" since the MPLS encapsulating header does not contain an IP - header and MPLS LSPs are thus clearly out of the scope of - [DIFF_TUNNEL]. However, although not a form of "IP tunnel", MPLS - LSPs are a form of "tunnel". + header and thus MPLS LSPs are not considered in [DIFF_TUNNEL]. + However, although not a form of "IP tunnel", MPLS LSPs are a form of + "tunnel". From the Diff-Serv standpoint, LSPs share a lot of characteristics with IP Tunnels: - - intermediate nodes (ie. Nodes somewhere along the LSP span) only - see and operate on the "outer" Diff-Serv information. - - LSPs are unidirectional - - the "outer" Diff-Serv information can be modified at any + - Intermediate nodes (i.e. Nodes somewhere along the LSP span) + only see and operate on the "outer" Diff-Serv information. + - LSPs are unidirectional. + - The "outer" Diff-Serv information can be modified at any intermediate nodes. - However, from the Diff-Serv standpoint, LSPs also have a number of - distinctive properties compared to IP Tunnels: - - There is no behavior analogous to Penultimate Hop Popping (PHP) - for IP Tunnels. Furthermore, PHP results in the "outer" - Diff-Serv information associated with the LSP not being visible - to the LSP egress. In situations where this information is not - meaningful at the LSP Egress, this is obviously not an issue at - all. In situations where this information is meaningful at the - LSP Egress, then it must somehow be carried in some other means. - - Two-level hierarchical LSPs with the two nested LSPs starting on - the same Ingress LSR and finishing on the same Egress LSR, are - expected to be commonplace in MPLS networks for applications - such as MPLS VPNs [MPLS_VPN]. - - Based on these considerations, it is clear that the two important - conceptual models for Diff-Serv tunneling over IP Tunnels defined in - [DIFF_TUNNEL] are applicable and useful to Diff-Serv over MPLS and - that their respective detailed operations is somewhat different over - MPLS. These two models are the Uniform Model and the Pipe Model and - their operations over MPLS is described in the following sections. - -2.6.3 Uniform Model - - Le Faucheur et. al 10 - MPLS Support of Diff-Serv June 2000 - - With the Uniform Model, MPLS tunnels (aka LSPs) are viewed as - artifacts of the end-to-end path from the Diff-Serv standpoint. MPLS - Tunnels may be used for forwarding purposes but have no significant - impact on Diff-Serv. In this model, any packet contains exactly one - piece of Diff-Serv information which is meaningful and is always - encoded in the outer most label entry (or in the IP DSCP where the - IP packet is transmitted unlabelled for instance at the egress of - the LSP). Any Diff-Serv information encoded somewhere else (eg. in - deeper label entries) is of no significance to intermediate nodes or - to the tunnel egress and is ignored. If Traffic Conditioning at - intermediate nodes on the LSP span affects the "outer" Diff-Serv - information, the updated Diff-Serv information is the one considered - meaningful at the egress of the LSP. + However, from the Diff-Serv standpoint, LSPs also have a + distinctive property compared to IP Tunnels: + - There is generally no behavior analogous to Penultimate Hop + Popping (PHP) used with IP Tunnels. Furthermore, PHP results in + the "outer" Diff-Serv information associated with the LSP not + being visible to the LSP egress. In situations where this + information is not meaningful at the LSP Egress, this is + obviously not an issue at all. In situations where this + information is meaningful at the LSP Egress, then it must + somehow be carried in some other means. - With this Uniform Model: - - the LSP Ingress, when performing the push operation, encodes the - meaningful Diff-Serv information in the label entry - corresponding to the pushed label. - - Intermediate LSRs only consider and operate on the LSP Diff-Serv - Information encoded in the "outer" label entry (ie label entry - on which they perform the label swap). - - Penultimate Hop Popping (PHP) can be used. In that case, the - meaningful Diff-Serv information is conveyed by the Penultimate - LSR to the LSP Egress in the header that is exposed by the pop - operation (ie. in the header that will be used for actual - forwarding by the LSP Egress). - Note that to do so, the Penultimate LSR needs to be aware of the - "Set of PHB-->Encaps mappings" for the label corresponding to - the exposed header (or the PHB-->DSCP mapping). Methods for - providing this mapping awareness are outside the scope of this - specification. As an example, the "PHB-->DSCP mapping" may be - locally configured. As another example, in some environments, it - may be appropriate for the Penultimate LSR to assume that the - "Set of PHB-->Encaps mappings" to be used for the outgoing label - in the exposed header is the "Set of PHB-->Encaps mappings" that - would be used by the LSR if the LSR was not doing PHP. - Note also that this specification assumes that the Penultimate - LSR does not perform label swapping over the label entry exposed - by the pop operation (and in fact that it does not even look at - the exposed label). Consequently, restrictions may apply to the - Diff-Serv Information Encoding that can be performed by the - Penultimate LSR. For example, this specification does not allow - situations where the Penultimate LSR pops a label corresponding - to an E-LSP supporting two PSCs, while the header exposed by the - pop contains label values for two L-LSPs each supporting one - PSC, since the Diff-Serv Information Encoding would require - selecting one label or the other. - - It is also possible to not use PHP. In that case, the meaningful - Diff-Serv information is conveyed by the Penultimate LSR to the - LSP Egress in the "outer" label entry (which corresponds to the - LSP label). + The two conceptual models for Diff-Serv tunneling over IP Tunnels + defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv over + MPLS but their respective detailed operations is somewhat different + over MPLS. These two models are the Pipe Model and the Uniform Le Faucheur et. al 11 - MPLS Support of Diff-Serv June 2000 - - - When the pop operation is performed (ie. Penultimate hop with - PHP, LSP Egress without PHP), the incoming Diff-Serv information - contained in the outmost label entry before the pop is - considered as the meaningful information. - - Operation of the Uniform Model with PHP is illustrated below : - - ========== LSP ==========================> - - +--Swap-(M)-...-Swap-(M)--+ - / (outer header) \ - (M) (M) - / \ - >--(M)--Push...............(x)............Pop-(M)--(E)--(M)-> - (I) (inner header) (P) - - (M) represents the Meaningful Diff-Serv information encoded in the - corresponding header. - - (x) represents non-meaningful Diff-Serv information. - - Operation of the Uniform Model without PHP is illustrated below: - - ========== LSP =============================> - - +--Swap--(M)-...-Swap-(M)-swap--(M)--+ - / (outer header) (P) \ - (M) (M) - / \ - >--(M)--Push...............(x).......................Pop--(M)-> - (I) (inner header) (E) - - (M) represents the Meaningful Diff-Serv information encoded in the - corresponding header. - - (x) represents non-meaningful Diff-Serv information. - - Use of the Uniform Model allows LSPs to span Diff-Serv domain - boundaries without any other measure in place than an inter-domain - Traffic Conditioning Agreement at the physical boundary between the - Diff-Serv domains and operating exclusively on the "outer" header, - since the meaningful Diff-Serv information is always visible and - modifiable in the outmost label entry. - - The Uniform Model for Diff-Serv over MPLS is such that, from the - Diff-Serv perspective, operations are exactly identical to the - operations if MPLS was not used. In other words, MPLS is entirely - transparent to the Diff-Serv operations. For this reason, the - - Le Faucheur et. al 12 - MPLS Support of Diff-Serv June 2000 - - Uniform Model has been selected in this specification as the base - mandatory mode of operations and thus MUST be supported. + MPLS Support of Diff-Serv July 2000 - For support of the Uniform Model over an LSP (with and without PHP), - an LSR performs the Incoming PHB Determination and the Diff-Serv - information Encoding in the following manner: - - when receiving an unlabelled packet, the LSR performs Incoming - PHB Determination considering the received IP Header. - - when receiving a labeled packet, the LSR performs Incoming PHB - Determination considering the outer label entry in the received - label stack. In particular, when a pop operation is to be - performed for the considered LSP, the LSR performs Incoming PHB - Determination BEFORE the pop. - - when performing a swap-only operation for an LSP, the LSR - encodes Diff-Serv Information in the transmitted label entry - corresponding to the swapped label - - when performing a push operation for an LSP, the LSR encodes - Diff-Serv Information in the transmitted label entry - corresponding to the pushed label. The Diff-Serv Information - encoded in the encapsulated header (swapped label entry or IP - Header) is of no importance. + Model. Their operations over MPLS are specified in the following + sections. Discussion and definition of alternative tunneling models + are outside the scope of this specification. -2.6.4 Pipe Model +2.6.2 Pipe Model With the Pipe Model, MPLS tunnels (aka LSPs) are used to hide the intermediate MPLS nodes between LSP Ingress and Egress from the Diff-Serv perspective. In this model, the LSP Egress uses the Diff- Serv information conveyed from the LSP Ingress inside the encapsulated header (be it an IP Header or an MPLS Header) and ignores the Diff-Serv information conveyed in the encapsulating header. In this model, tunneled packets must convey two meaningful pieces of @@ -694,330 +626,339 @@ meaningful at the LSP Egress: Whether Traffic Conditioning at intermediate nodes on the LSP span affects the LSP Diff-Serv information or not, this updated Diff-Serv information is not considered meaningful at the LSP Egress and is ignored. - the Diff-Serv information which is meaningful at the LSP Egress (which we refer to as the "Tunneled Diff-Serv Information"). This information is to be conveyed by the LSP Ingress to the LSP Egress. This Diff-Serv information is not meaningful to the intermediate nodes on the LSP span. - With this Pipe Model: - - the LSP Ingress, when performing the push operation, encodes the - LSP Diff-Serv information in the label entry that is pushed - ("outer label entry") and encodes the Tunneled Diff-Serv - - Le Faucheur et. al 13 - MPLS Support of Diff-Serv June 2000 - - Information in the encapsulated header (IP header or swapped - label entry). - - Intermediate LSRs only consider and operate on the LSP Diff-Serv - Information encoded in the "outer" label entry (ie label entry - on which they perform the label swap). - - Penultimate Hop Popping (PHP) can be used. In that case, the LSP - Diff-Serv Information is simply not conveyed by the Penultimate - LSR to the LSP Egress. The Penultimate LSR conveys to the LSP - Egress the Tunneled Diff-Serv Information in the header that is - exposed by the pop operation (ie. in the header that will be - used for actual forwarding by the LSP Egress). However, since - the LSP Diff-Serv Information is the meaningful one over the - whole LSP including from the Penultimate LSR to the LSP Egress, - the Penultimate LSR performs Diff-Serv forwarding treatment (ie - PHB enforcement) based on the LSP Diff-Serv Information (even if - this information is not actually conveyed in the packet - transmitted to the LSP Egress). - - it is also possible to not use PHP. In that case, the LSP Diff- - Serv Information is conveyed by the Penultimate LSR to the LSP - Egress in the "outer" label entry (which corresponds to the LSP - label) where it will simply be ignored. - - When PHP is used, the LSP Egress directly uses the Diff-Serv - information received in the outer header (IP header or outer - label entry) since it carries the Tunneled Diff-Serv - Information. - - When PHP is not used, LSP Egress ignores the Diff-Serv - information contained in the label entry to be popped (since it - contains the LSP Diff-Serv information) and considers the Diff- - Serv information conveyed in the header (IP header or MPLS - header) which is used to do the actual forwarding (since it - contains the Tunneled LSP Diff-Serv information). In other - words, the LSP Egress considers the Diff-Serv information - conveyed in the header after the pop operation. - - Operation of the Pipe Model with PHP is illustrated below: + Operation of the Pipe Model without PHP is illustrated below: - ========== LSP ===========================> + ========== LSP =============================> - +--Swap--(M)-...-Swap--(M)--+ + ---Swap--(M)--...--Swap--(M)--Swap---- / (outer header) \ (M) (M) / \ - >--(m)-Push.................(m)............Pop-(m)-(E)-(m)--> - (I) (inner header) (P) (M*) + >--(m)-Push.................(m).....................Pop--(m)--> + I (inner header) E (M) represents the "LSP Diff-Serv information - (m) represents the "Tunneled Diff-Serv information" + I represents the LSP ingress node + E represents the LSP egress node - Le Faucheur et. al 14 - MPLS Support of Diff-Serv June 2000 + Operation of the Pipe Model with PHP is illustrated below: - (*) The Penultimate LSR considers the LSP Diff-Serv information - received in the outer header (ie. before the pop) in order to apply - its Diff-Serv forwarding treatment (ie actual PHB) + =========== LSP ============================> - Operation of the Pipe Model without PHP is illustrated below: + ---Swap--(M)--...--Swap------ - ========== LSP =============================> + Le Faucheur et. al 12 + MPLS Support of Diff-Serv July 2000 - +--Swap-(M)-...-Swap-(M)--Swap--(M)--+ - / (outer header) (P) \ + / (outer header) \ (M) (M) / \ - >--(m)-Push.................(m).....................Pop--(m)--> - (I) (inner header) (E) + >--(m)-Push.................(m).............Pop-(m)--E--(m)--> + I (inner header) P (M*) (M) represents the "LSP Diff-Serv information - (m) represents the "Tunneled Diff-Serv information" + (*) The Penultimate LSR considers the LSP Diff-Serv information + received in the outer header (i.e. before the pop) in order to + apply its Diff-Serv forwarding treatment (ie actual PHB) + I represents the LSP ingress node + P represents the LSP penultimate node + E represents the LSP egress node The Pipe Model is particularly appropriate to environments in which the incoming interface of the LSP Ingress and the outgoing interface - of the LSP Egress are in the same Diff-Serv domain while the LSP - spans another (other) Diff-Serv domain(s). + of the LSP Egress are in Diff-Serv domains which use a common set of + Diff-Serv service provisioning policies and PHB definitions, while + the LSP spans one (or more) Diff-Serv domain(s) which use(s) a + different set of Diff-Serv service provisioning policies and PHB + definitions. As an example, consider the case where a service provider is - offering an MPLS VPN service including Diff-Serv differentiation. - Say that a collection of sites are interconnected via such an MPLS - VPN service. Now say that this collection of sites are managed under - a common administration and are also supporting Diff-Serv service + offering an MPLS VPN service (see [MPLS_VPN] for an example of MPLS + VPN architecture) including Diff-Serv differentiation. Say that a + collection of sites are interconnected via such an MPLS VPN service. + Now say that this collection of sites are managed under a common + administration and are also supporting Diff-Serv service differentiation. If the VPN site administration and the Service Provider are not sharing the exact same Diff-Serv policy (for instance not supporting the same number of PHBs), then operation of Diff-Serv in the Pipe Model over the MPLS VPN service would allow - the VPN Sites Diff-Serv domain policy to operate consistently - throughout the ingress VPN Site and Egress VPN Site and - transparently over the Service Provider Diff-Serv domain. + the VPN Sites Diff-Serv policy to operate consistently throughout + the ingress VPN Site and Egress VPN Site and transparently over the + Service Provider Diff-Serv domain. It may be useful to view such + LSPs as linking the Diff-Serv domains at their endpoints into a + single Diff-Serv region by making these endpoints virtually + contiguous even though they may be physically separated by + intermediate network nodes. - Support of the Pipe Model is defined in this specification as a - recommended option and thus SHOULD be supported. + The Pipe Model MUST be supported. - For support of the Pipe Model over an LSP without PHP, an LSR + For support of the Pipe Model over a given LSP without PHP, an LSR performs the Incoming PHB Determination and the Diff-Serv information Encoding in the following manner: - when receiving an unlabelled packet, the LSR performs Incoming PHB Determination considering the received IP Header. - when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the header (label entry or IP header) which is used to do the actual forwarding. In particular, when a - pop operation is to be performed for the considered LSP, the LSR - performs Incoming PHB Determination AFTER the pop. - Le Faucheur et. al 15 - MPLS Support of Diff-Serv June 2000 + Le Faucheur et. al 13 + MPLS Support of Diff-Serv July 2000 - - when performing a swap-only operation for an LSP, the LSR - encodes Diff-Serv Information in the transmitted label entry - corresponding to the swapped label - - when performing a push operation for an LSP, the LSR: + pop operation is to be performed for the considered LSP, the LSR + performs Incoming PHB Determination AFTER the pop. + - when performing a swap-only operation for the considered LSP, + the LSR encodes Diff-Serv Information in the transmitted label + entry corresponding to the swapped label + - when performing a push operation for the considered LSP, the + LSR: o encodes Diff-Serv Information corresponding to the OUTGOING PHB in the transmitted label entry corresponding to the pushed label. o encodes Diff-Serv Information corresponding to the INCOMING PHB in the encapsulated header (swapped label entry or IP header). - For support of the Pipe Model over an LSP with PHP, an LSR performs - Incoming PHB Determination and Diff-Serv information Encoding in the - same manner as without PHP with the following exception: + For support of the Pipe Model over a given LSP with PHP, an LSR + performs Incoming PHB Determination and Diff-Serv information + Encoding in the same manner as without PHP with the following + exceptions: - the Penultimate LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In other words, when a pop operation is to be performed for the considered LSP, the Penultimate LSR performs Incoming PHB Determination BEFORE the pop. - the Penultimate LSR does not perform Encoding of Diff-Serv - Information into the header exposed by the pop operation. + Information into the header exposed by the pop operation (i.e. + the LSR leaves the exposed header "as is"). - Note that LSR behaviors for the Uniform Model and for the Pipe Model - only differ when doing a push or a pop. Thus, Intermediate LSRs - which perform swap only operations for an LSP , behave exactly in - the same way regardless of whether they are behaving in the Uniform - Model or the Pipe model. With a Diff-Serv implementation supporting - both the Uniform Model and the Pipe Model, only LSRs behaving as LSP - Ingress, Penultimate LSR or LSP Egress need to be configured to - operate in a particular Model. +2.6.3 Uniform Model -2.6.5 Other Models + With the Uniform Model, MPLS tunnels (aka LSPs) are viewed as + artifacts of the end-to-end path from the Diff-Serv standpoint. MPLS + Tunnels may be used for forwarding purposes but have no significant + impact on Diff-Serv. In this model, any packet contains exactly one + piece of Diff-Serv information which is meaningful and is always + encoded in the outer most label entry (or in the IP DSCP where the + IP packet is transmitted unlabelled for instance at the egress of + the LSP). Any Diff-Serv information encoded somewhere else (e.g. in + deeper label entries) is of no significance to intermediate nodes or + to the tunnel egress and is ignored. If Traffic Conditioning at + intermediate nodes on the LSP span affects the "outer" Diff-Serv + information, the updated Diff-Serv information is the one considered + meaningful at the egress of the LSP. - Other Diff-Serv tunneling models are conceivable over MPLS for - support of more complex scenarios. For instance, the egress of an - LSP could conceivably make some complex Diff-Serv decision based on - both the Diff-Serv information conveyed in the encapsulating header - and in the encapsulated header. Models beyond the Uniform Model and - the Pipe Model are outside the scope of this specification and MAY - be supported as an option. + Operation of the Uniform Model without PHP is illustrated below: -2.6.6 Hierarchy + ========== LSP =============================> + + ---Swap--(M)--...-Swap--(M)--Swap---- + / (outer header) \ + (M) (M) + / \ + + Le Faucheur et. al 14 + MPLS Support of Diff-Serv July 2000 + + >--(M)--Push...............(x).......................Pop--(M)-> + I (inner header) E + + (M) represents the Meaningful Diff-Serv information encoded in the + corresponding header. + (x) represents non-meaningful Diff-Serv information. + I represents the LSP ingress node + E represents the LSP egress node + + Operation of the Uniform Model with PHP is illustrated below : + + ========== LSP =========================> + + ---Swap-(M)-...-Swap------ + / (outer header) \ + (M) (M) + / \ + >--(M)--Push..............(x)............Pop-(M)--E--(M)-> + I (inner header) P + + (M) represents the Meaningful Diff-Serv information encoded in the + corresponding header. + (x) represents non-meaningful Diff-Serv information. + I represents the LSP ingress node + P represents the LSP penultimate node + E represents the LSP egress node + + The Uniform Model for Diff-Serv over MPLS is such that, from the + Diff-Serv perspective, operations are exactly identical to the + operations if MPLS was not used. In other words, MPLS is entirely + transparent to the Diff-Serv operations. + + Use of the Uniform Model allows LSPs to span Diff-Serv domain + boundaries without any other measure in place than an inter-domain + Traffic Conditioning Agreement at the physical boundary between the + Diff-Serv domains and operating exclusively on the "outer" header, + since the meaningful Diff-Serv information is always visible and + modifiable in the outmost label entry. + + The Uniform Model MAY be supported. + + For support of the Uniform Model over a given LSP, an LSR performs + Incoming PHB Determination and Diff-Serv information Encoding in the + following manner: + - when receiving an unlabelled packet, the LSR performs Incoming + PHB Determination considering the received IP Header. + - when receiving a labeled packet, the LSR performs Incoming PHB + Determination considering the outer label entry in the received + label stack. In particular, when a pop operation is to be + + Le Faucheur et. al 15 + MPLS Support of Diff-Serv July 2000 + + performed for the considered LSP, the LSR performs Incoming PHB + Determination BEFORE the pop. + - when performing a push operation for the considered LSP, the LSR + encodes Diff-Serv Information in the transmitted label entry + corresponding to the pushed label. The Diff-Serv Information + encoded in the encapsulated header (swapped label entry or IP + Header) is of no importance. + - when performing a swap-only operation for the considered LSP, + the LSR encodes Diff-Serv Information in the transmitted label + entry corresponding to the swapped label. + - when PHP is used, the Penultimate LSR needs to be aware of the + "Set of PHB-->Encaps mappings" for the label corresponding to + the exposed header (or the PHB-->DSCP mapping) in order to + perform Diff-Serv Information Encoding. Methods for providing + this mapping awareness are outside the scope of this + specification. As an example, the "PHB-->DSCP mapping" may be + locally configured. As another example, in some environments, it + may be appropriate for the Penultimate LSR to assume that the + "Set of PHB-->Encaps mappings" to be used for the outgoing label + in the exposed header is the "Set of PHB-->Encaps mappings" that + would be used by the LSR if the LSR was not doing PHP. + Note also that this specification assumes that the Penultimate + LSR does not perform label swapping over the label entry exposed + by the pop operation (and in fact that it does not even look at + the exposed label). Consequently, restrictions may apply to the + Diff-Serv Information Encoding that can be performed by the + Penultimate LSR. For example, this specification does not allow + situations where the Penultimate LSR pops a label corresponding + to an E-LSP supporting two PSCs, while the header exposed by the + pop contains label values for two L-LSPs each supporting one + PSC, since the Diff-Serv Information Encoding would require + selecting one label or the other. + + Note that LSR behaviors for the Pipe Model and for the Uniform Model + only differ when doing a push or a pop. Thus, Intermediate LSRs + which perform swap only operations for an LSP , behave exactly in + the same way regardless of whether they are behaving in the Pipe + Model or the Uniform model. With a Diff-Serv implementation + supporting both the Pipe Model and the Uniform Model, only LSRs + behaving as LSP Ingress, Penultimate LSR or LSP Egress need to be + configured to operate in a particular Model. Signaling to associate + a Diff-Serv tunneling model on a per-LSP basis is out of the scope + of this specification. + +2.6.4 Hierarchy Through the label stack mechanism, MPLS allows LSP tunneling to nest to any depth. We observe that with such nesting, the push of level N+1 takes place on a subsequent (or the same) LSR to the LSR doing the push for level N, while the pop of level N+1 takes place on a previous (or the same) LSR to the LSR doing the pop of level N. For a given level N LSP, the Ingress LSR doing the push and the LSR - doing the pop (Penultimate LSR or LSP Egress) are expected to - operate in the same Tunneling Model (ie Uniform or Pipe). LSRs at Le Faucheur et. al 16 - MPLS Support of Diff-Serv June 2000 - - different levels of LSPs are expected to operate in the same or in - different Tunneling Models. + MPLS Support of Diff-Serv July 2000 - Le Faucheur et. al 17 - MPLS Support of Diff-Serv June 2000 + doing the pop (Penultimate LSR or LSP Egress) must operate in the + same Tunneling Model (i.e. Pipe or Uniform). However, there is no + requirement for consistent tunneling models across levels so that + LSPs at different levels may be operating in different Tunneling + Models. Hierarchical operations is illustrated below in the case of two levels of tunnels: + +--------Swap--...---+ / (outmost header) \ / \ Push(2).................(2)Pop / (outer header) \ / \ >>---Push(1)........................(1)Pop-->> (inner header) - (1) Tunneling Model 1 (either Uniform or Pipe) - - (2) Tunneling Model 2 (same as Tunneling Model 1 or different Model) - - For support of M levels of push in the Uniform Model: - - when performing multiple push operations, the LSR encodes Diff- - Serv Information in the transmitted label entry corresponding to - the LAST pushed label (ie the label pushed in the outer label - entry). The Diff-Serv Information encoded in the encapsulated - header (swapped label entry or IP Header) as well as the Diff- - Serv Information encoded in label entries for other pushed - labels are of no importance. - - For support of M levels of pop in the Uniform Model: - - when performing multiple pop operations for an LSP, the LSR - performs Incoming PHB Determination considering the outmost - label entry in the received label stack. In other words, when - multiple pop operations are to be performed, the LSR performs - Incoming PHB Determination BEFORE ANY pop operations. - - when the multiple pop operations are performed by the - Penultimate LSR, note that to perform Encoding of Diff-Serv - Information, the Penultimate LSR needs to be aware of the "Set - of PHB-->Encaps mappings" for the label corresponding to the - exposed header after all the pop operations (or the PHB-->DSCP - mapping). Methods for providing this mapping awareness are - outside the scope of this specification. - - when the multiple pop operations are performed by the - Penultimate LSR, note also that this specification assumes that - the Penultimate LSR does not perform label swapping over the - label entry exposed after all the pop operations (and in fact - that it does not even look at the header exposed after the last - pop operations). Consequently, restrictions may apply to the - Diff-Serv Information Encoding that can be performed by the - Penultimate LSR. + (1) Tunneling Model 1 + (2) Tunneling Model 2 + Tunneling Model 2 may be the same as or may be different to + Tunneling Model 1. For support of M levels of push in the Pipe Model: - when performing multiple push operations, the LSR: o encodes Diff-Serv Information corresponding to the Outgoing PHB in the transmitted label entry corresponding - - Le Faucheur et. al 18 - MPLS Support of Diff-Serv June 2000 - - to the LAST pushed label (ie the label pushed in the outer - label entry). + to the LAST pushed label (i.e. the label pushed in the + outer label entry). o encodes Diff-Serv Information corresponding to the Incoming PHB in the encapsulated header (swapped label entry or IP header) as well as in the label entries for all the pushed labels (except the last pushed label). - For support of M levels of pop in the Pipe Model without PHP: + For support of M levels of pop in the Pipe Model: - when performing multiple pop operations for an LSP, the LSR performs Incoming PHB Determination considering the header (label entry or IP header) which is used to do the actual forwarding. In other words, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination AFTER ALL the pop operations. - For support of M levels of pop in the Pipe Model with PHP, the - Penultimate LSR: - - performs Incoming PHB Determination considering the outmost + For support of M levels of push in the Uniform Model: + - when performing multiple push operations, the LSR encodes Diff- + Serv Information in the transmitted label entry corresponding to + the LAST pushed label (i.e. the label pushed in the outer label + entry). The Diff-Serv Information encoded in the encapsulated + header (swapped label entry or IP Header) as well as the Diff- + Serv Information encoded in label entries for other pushed + labels are of no importance. + + Le Faucheur et. al 17 + MPLS Support of Diff-Serv July 2000 + + For support of M levels of pop in the Uniform Model: + - when performing multiple pop operations for an LSP, the LSR + performs Incoming PHB Determination considering the outmost label entry in the received label stack. In other words, when - multiple pop operations are to be performed for the considered - LSP, the LSR performs Incoming PHB Determination BEFORE ANY pop - operations. - - does not perform Encoding of Diff-Serv Information into the - header that is exposed after all the pop operations + multiple pop operations are to be performed, the LSR performs + Incoming PHB Determination BEFORE ANY pop operations. 3. Detailed Operations of E-LSPs 3.1 E-LSP Definition - Recognizing that: - - Certain MPLS encapsulations (such as PPP and LAN) make use of a - Shim Header which consists of a label stack with one or more - entries [MPLS_ENCAPS] each with a 3-bit EXP field; - - the Differentiated-Service (DS) field is 6-bit long - [DIFF_HEADER] potentially allowing support of up to 64 Behavior - Aggregates - - any subset of 8 (or less) DSCP values can be mapped entirely - into the 3-bit long EXP field of the MPLS label stack entry; - - We define that: - - an LSP established for a given Forwarding Equivalent Class (FEC) - may be used for transport of up to eight BAs of that FEC; - - the set of transported BAs can span multiple OAs; - - for a given OA transported over the LSP, all supported BAs of - this OA are transported over the LSP; - - such an LSP is referred to as an "EXP-inferred-PSC" LSP or - "E-LSP" because the PSC to be applied to a labeled packet by the - LSR depends on the EXP field value in the MPLS Shim Header; - - packets belonging to this given FEC and from the corresponding - set of BAs are sent down this E-LSP. - - Le Faucheur et. al 19 - MPLS Support of Diff-Serv June 2000 - - - 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 LSR based on the EXP field - which is appropriately encoded to reflect both the PSC and the - drop precedence of the PHB corresponding to the packet's BA. - - the mapping between EXP field and PHB to be applied by the LSR - for a given E-LSP is either explicitly signaled at label set-up - or relies on a preconfigured mapping. + E-LSPs are defined in section 1.2. Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the pre-configured mapping are capable of transporting the same common set of 8, or fewer, BAs. Each of those E-LSPs may actually transport this full set of BAs or any arbitrary subset of it. For a given FEC, two given E-LSPs using signaled EXP<-->PHB mapping can support the same or different sets of Ordered Aggregates. - For a given FEC, there may be more than one E-LSP carrying the same - OA, for example for purposes of load balancing of the OA. In that - case, in order to respect ordering constraints, all packets of a - given microflow must be transported over the same LSP. - - MPLS specifies how LSPs can be established via multiple signaling - protocols. Those include the Label Distribution Protocol (LDP), - RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP - are to be used for establishment of E-LSPs. - 3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP This section defines how the `Encaps-->PHB mapping' of the Diff-Serv Context is populated for an incoming E-LSP in order to allow Incoming PHB determination. The `Encaps-->PHB mapping' for an E-LSP is always of the form `EXP-->PHB mapping'. If the label corresponds to an E-LSP for which no EXP<-->PHB mapping @@ -1029,148 +970,151 @@ has been explicitly signaled at LSP setup, the `EXP-->PHB mapping' is populated as per the signaled EXP<-->PHB mapping. 3.2.1 Preconfigured EXP<-->PHB mapping LSRs supporting E-LSPs which use the preconfigured EXP<-->PHB mapping must allow local configuration of this EXP<-->PHB mapping. This mapping applies to all the E-LSPs established on this LSR without a mapping explicitly signaled at set-up time. - Le Faucheur et. al 20 - MPLS Support of Diff-Serv June 2000 - The preconfigured EXP<-->PHB mapping must either be consistent at every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the LSP or appropriate remarking of the EXP field must be performed by the LSR whenever a different preconfigured mapping is used on the ingress and egress interfaces. + Le Faucheur et. al 18 + MPLS Support of Diff-Serv July 2000 + + In case, the preconfigured EXP<-->PHB mapping has not actually been + configured by the Network Administrator, the LSR should use a + default preconfigured EXP<-->PHB mapping which maps all EXP values + to the Default PHB. + 3.3 Incoming PHB Determination On Incoming E-LSP This section defines how Incoming PHB Determination is carried out when the considered label entry in the received label stack corresponds to an E-LSP. This requires that the `Encaps-->PHB - mapping' is populated as defined above in section 3.2. + mapping' is populated as defined in section 3.2. When considering a label entry corresponding to an incoming E-LSP for Incoming PHB Determination, the LSR: - determines the EXP-->PHB mapping by looking up the `Encaps-->PHB mapping' of the Diff-Serv Context associated in the ILM with the considered incoming E-LSP label. - determines the incoming PHB by looking up the EXP field of the considered label entry in the EXP-->PHB mapping table. 3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP This section defines how the `Set of PHB-->Encaps mappings' of the - Diff-Serv Context is populated for an outgoing E-LSP in order to - allow Encoding of Diff-Serv information in the Encapsulation Layer. + Diff-Serv Context is populated at label setup for an outgoing E-LSP + in order to allow Encoding of Diff-Serv information in the + Encapsulation Layer. 3.4.1 `PHB-->EXP mapping' An outgoing E-LSP must always have a `PHB-->EXP mapping' as part of the `Set of PHB-->Encaps mappings' of its Diff-Serv Context. If the label corresponds to an E-LSP for which no EXP<-->PHB mapping has been explicitly signaled at LSP setup, this `PHB-->EXP mapping' is populated based on the Preconfigured EXP<-->PHB Mapping which is discussed above in section 3.2.1. If the label corresponds to an E-LSP for which an EXP<-->PHB mapping has been explicitly signaled at LSP setup, the `PHB-->EXP mapping' is populated as per the signaled EXP<-->PHB mapping. 3.4.2 `PHB-->CLP mapping' - If the E-LSP is egressing over an ATM interface which is not label - switching controlled, then one `PHB-->CLP mapping' is added at label - setup to the `Set of PHB-->Encaps mappings' in the Diff-Serv Context - for this outgoing E-LSP. This `PHB-->CLP mapping' is populated in - the following way: + If the LSP is egressing over an ATM interface which is not label + switching controlled, then one `PHB-->CLP mapping' is added to the + `Set of PHB-->Encaps mappings' for this outgoing LSP. This + `PHB-->CLP mapping' is populated in the following way: - it is a function of the PHBs supported on this LSP, and may use the relevant mapping entries for these PHBs from the Default PHB-->CLP Mapping defined in section 3.4.2.1. Other mappings than the one defined in section 3.4.2.1 may be used. In - Le Faucheur et. al 21 - MPLS Support of Diff-Serv June 2000 + Le Faucheur et. al 19 + MPLS Support of Diff-Serv July 2000 particular, if a mapping from PHBs to CLP is standardized in the future for operations of Diff-Serv over ATM, such standardized mapping may then be used. - For example if the outgoing label corresponds to an E-LSP supporting - the AF1 PSC and the EF PHB and egressing over an ATM interface, then - the `PHB-->CLP mapping' may be populated with: + For example if the outgoing label corresponds to an LSP supporting + the AF1 PSC , then the `PHB-->CLP mapping' may be populated with: PHB CLP Field AF11 ----> 0 AF12 ----> 1 AF13 ----> 1 EF ----> 0 - Notice that if the E-LSP is egressing over an ATM interface, then - the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP - mapping' and a `PHB-->CLP mapping'. + Notice that in this case the `Set of PHB-->Encaps mappings' contains + both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'. 3.4.2.1 Default PHB-->CLP Mapping PHB CLP Bit DF ----> 0 CSn ----> 0 AFn1 ----> 0 AFn2 ----> 1 AFn3 ----> 1 EF ----> 0 3.4.3 `PHB-->DE mapping' - If the E-LSP is egressing over a Frame Relay interface which is not - label switching controlled, one `PHB-->DE mapping' is added at label - setup to the `Set of PHB-->Encaps mappings' in the Diff-Serv Context - for this outgoing E-LSP and is populated in the following way: + If the LSP is egressing over a Frame Relay interface which is not + label switching controlled, one `PHB-->DE mapping' is added to the + `Set of PHB-->Encaps mappings' for this outgoing LSP and is + populated in the following way: - it is a function of the PHBs supported on this LSP, and may use the relevant mapping entries for these PHBs from the Default PHB-->DE Mapping defined in section 3.4.3.1. Other mappings than the one defined in section 3.4.3.1 may be used. In particular, if a mapping from PHBs to DE is standardized in the future for operations of Diff-Serv over Frame Relay, such standardized mapping may then be used. - Notice that if the E-LSP is egressing over a Frame Relay interface, - then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP - mapping' and a `PHB-->DE mapping'. + Notice that in this case the `Set of PHB-->Encaps mappings' contains + both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. 3.4.3.1 Default PHB-->DE Mapping PHB DE Bit - Le Faucheur et. al 22 - MPLS Support of Diff-Serv June 2000 - DF ----> 0 CSn ----> 0 AFn1 ----> 0 + + Le Faucheur et. al 20 + MPLS Support of Diff-Serv July 2000 + AFn2 ----> 1 AFn3 ----> 1 EF ----> 0 3.4.4 `PHB-->802.1 mapping' - If the E-LSP is egressing over a LAN interface on which multiple - 802.1 Traffic Classes are supported as per [IEEE_802.1], then one - `PHB-->802.1 mapping' is added at label setup to the `Set of - PHB-->Encaps mappings' of the Diff-Serv Context for this outgoing - E-LSP. This `PHB-->802.1 mapping' is populated in the following way: + If the LSP is egressing over a LAN interface on which multiple 802.1 + Traffic Classes are supported as per [IEEE_802.1], then one + `PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings' + for this outgoing LSP. This `PHB-->802.1 mapping' is populated in + the following way: - it is a function of the PHBs supported on this LSP, an uses the relevant mapping entries for these PHBs from the Preconfigured PHB-->802.1 Mapping defined in section 3.4.4.1. Notice that the `Set of PHB-->Encaps mappings' then contains both a `PHB-->EXP mapping' and a `PHB-->802.1 mapping'. 3.4.4.1 Preconfigured `PHB-->802.1 Mapping' At the time of producing this specification, there are no @@ -1179,43 +1123,42 @@ LAN interfaces must allow local configuration of a `PHB-->802.1 Mapping'. This mapping applies to all the outgoing LSPs established by the LSR on such LAN interfaces. 3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing E-LSP This section defines how to encode Diff-Serv information into the MPLS encapsulation Layer for a given transmitted label entry corresponding to an outgoing E-LSP. This requires that the `Set of - PHB-->Encaps mappings' is populated as defined above in section 3.4. + PHB-->Encaps mappings' is populated as defined in section 3.4. The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the NHLFE. 3.5.1 `PHB-->EXP mapping' - The LSR: - - determines the PHB-->EXP mapping by looking up the - `Set of PHB-->Encaps mapping' of the Diff-Serv Context - associated with the corresponding label in the NHLFE. + If the `Set of PHB-->Encaps mappings' contains a mapping of the form + `PHB-->EXP mapping', then the LSR: - determines the value to be written in the EXP field of the corresponding level label entry by looking up the "outgoing PHB" in this PHB-->EXP mapping table. - Le Faucheur et. al 23 - MPLS Support of Diff-Serv June 2000 - 3.5.2 `PHB-->CLP mapping' If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->CLP mapping', then the LSR: + + Le Faucheur et. al 21 + MPLS Support of Diff-Serv July 2000 + - determines the value to be written in the CLP field of the ATM encapsulation header, by looking up the "outgoing PHB" in this PHB-->CLP mapping table. 3.5.3 `PHB-->DE mapping' If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->DE mapping', then the LSR: - determines the value to be written in the DE field of the Frame Relay encapsulation header, by looking up the "outgoing PHB" in @@ -1250,141 +1193,94 @@ merge. However all E-LSPs using the preconfigured EXP<-->PHB mapping are required to support the same set of Behavior Aggregates within a given MPLS Diff-Serv domain. Thus, merging of E-LSPs using the preconfigured EXP<-->PHB mapping is allowed within a given MPLS Diff-Serv domain. 4. Detailed Operation of L-LSPs 4.1 L-LSP Definition - Le Faucheur et. al 24 - MPLS Support of Diff-Serv June 2000 - - 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 Differentiated-Services (DS) field is 6-bit long - [DIFF_HEADER] potentially allowing support of up to 64 Behavior - Aggregates. So that when more than a certain number of BAs are - used (i.e., more than 8 BAs in case of Shim Header and more than - 2 BAs in case of ATM/Frame Relay), the DS field can not be - mapped entirely into the appropriate field of MPLS encapsulation - header (i.e., EXP field in case of Shim Header and CLP/DE field - in case of ATM/Frame Relay); - - We define that: - - - an LSP established for a given Forwarding Equivalent Class (FEC) - may be used for transport of the BAs comprised in one Ordered - Aggregate (OA) for that FEC; - - all BAs of this OA can be transported over the LSP; - - BAs from other OAs can not be transported over the LSP; - - BAs from the OA transported over the LSP are given the - appropriate scheduling treatment based on the PSC which is - explicitly signaled at label set-up time. - - Such an LSP is referred to as a "Label-Only-inferred-PSC" LSP or - "L-LSP"; - - Multiple BAs from the OA transported over the LSP are granted - different drop precedence by the LSR based on the appropriately - encoded relevant field of MPLS encapsulation header (EXP field - of the top label entry for the shim header, CLP/DE bit in case - of ATM/Frame Relay); The mapping between the relevant field of - the MPLS encapsulation and the drop precedence is a well-known - mapping. - - For a given FEC, there may be more than one L-LSP carrying the same - OA, for example for purposes of load balancing of the OA. In that - case, in order to respect ordering constraints, all packets of a - given microflow must be transported over the same LSP. - - MPLS specifies how LSPs can be established via multiple signaling - protocols. Those include the Label Distribution Protocol (LDP), - RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP - are to be used for establishment of L-LSPs. + L-LSPs are defined in section 1.3. 4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP - This section defines how the `Encaps-->PHB mapping' of the Diff-Serv - Context is populated for an incoming L-LSP in order to allow - Incoming PHB determination. + Le Faucheur et. al 22 + MPLS Support of Diff-Serv July 2000 - Le Faucheur et. al 25 - MPLS Support of Diff-Serv June 2000 + This section defines how the `Encaps-->PHB mapping' of the Diff-Serv + Context is populated at label setup for an incoming L-LSP in order + to allow Incoming PHB determination. 4.2.1 `EXP-->PHB mapping' If the LSR terminates the MPLS Shim Layer over this incoming L-LSP and the L-LSP ingresses on an interface which is not ATM nor Frame - Relay, then the `Encaps-->PHB mapping' is populated at label setup - in the following way: - - it must actually be a `EXP-->PHB mapping' + Relay, then the `Encaps-->PHB mapping' is populated in the following + way: + - it is actually a `EXP-->PHB mapping' - this mapping is a function of the PSC which is carried on this LSP, and must use the relevant mapping entries for this PSC from the Mandatory EXP/PSC-->PHB Mapping defined in Section 4.2.1.1. For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with: EXP Field PHB 000 ----> AF11 001 ----> AF12 010 ----> AF13 An LSR supporting L-LSPs over PPP interfaces and LAN interfaces is an example of LSR terminating the Shim layer over ingress interfaces which are not ATM nor Frame Relay. If the LSR terminates the MPLS Shim Layer over this incoming L-LSP and the L-LSP ingresses on an ATM or Frame Relay interface, then the - `Encaps-->PHB mapping' is populated at label setup in the following - way: + `Encaps-->PHB mapping' is populated in the following way: - it should actually be a `EXP-->PHB mapping'. Alternative optional ways of populating the `Encaps-->PHB mapping' might be defined in the future (e.g., using a 'CLP/EXP--> PHB mapping' or a 'DE/EXP-->PHB mapping') but are outside the scope of this document. - when the `Encaps-->PHB mapping' is an `EXP-->PHB mapping', this `EXP-->PHB mapping' mapping is a function of the PSC which is carried on the L-LSP, and must use the relevant mapping entries for this PSC from the Mandatory EXP/PSC-->PHB Mapping defined in Section 4.2.1.1. An Edge-LSR of an ATM-MPLS domain or of a FR-MPLS domain is an example of LSR terminating the shim layer over an ingress ATM/FR interface. 4.2.1.1 Mandatory EXP/PSC --> PHB mapping EXP Field PSC PHB 000 DF ----> DF + + Le Faucheur et. al 23 + MPLS Support of Diff-Serv July 2000 + 000 CSn ----> CSn 000 AFn ----> AFn1 001 AFn ----> AFn2 010 AFn ----> AFn3 - - Le Faucheur et. al 26 - MPLS Support of Diff-Serv June 2000 - 000 EF ----> EF 4.2.2 `CLP-->PHB mapping' If the LSR does not terminate an MPLS Shim Layer over this incoming label and uses ATM encapsulation (i.e. it is an ATM-LSR), then the - `Encaps-->PHB mapping' of the Diff-Serv Context for this incoming - L-LSP is populated at label setup in the following way: + `Encaps-->PHB mapping' for this incoming L-LSP is populated in the + following way: - it is actually a `CLP-->PHB mapping' - the mapping is a function of the PSC which is carried on this LSP, and should use the relevant mapping entries for this PSC from the Default CLP/PSC-->PHB Mapping defined in Section 4.2.2.1. For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' should be populated with: @@ -1400,52 +1296,51 @@ 0 DF ----> DF 0 CSn ----> CSn 0 AFn ----> AFn1 1 AFn ----> AFn2 0 EF ----> EF 4.2.3 `DE-->PHB mapping' If the LSR does not terminate an MPLS Shim Layer over this incoming label and uses Frame Relay encapsulation (i.e. it is a FR-LSR), then - the `Encaps-->PHB mapping' of the Diff-Serv Context for this - incoming L-LSP is populated at label setup in the following way: + the `Encaps-->PHB mapping' for this incoming L-LSP is populated in + the following way: - it is actually a `DE-->PHB mapping' - the mapping is a function of the PSC which is carried on this LSP, and should use the relevant mapping entries for this PSC from the Default DE/PSC-->PHB Mapping defined in Section 4.2.3.1. 4.2.3.1 Default DE/PSC --> PHB Mapping DE Bit PSC PHB + Le Faucheur et. al 24 + MPLS Support of Diff-Serv July 2000 + 0 DF ----> DF 0 CSn ----> CSn 0 AFn ----> AFn1 - - Le Faucheur et. al 27 - MPLS Support of Diff-Serv June 2000 - 1 AFn ----> AFn2 0 EF ----> EF 4.3 Incoming PHB Determination On Incoming L-LSP This section defines how Incoming PHB determination is carried out when the considered label entry in the received label stack corresponds to an L-LSP. This requires that the `Encaps-->PHB - mapping' is populated as defined above in section 4.2. + mapping' is populated as defined in section 4.2. When considering a label entry corresponding to an incoming L-LSP for Incoming PHB Determination, the LSR first determines the - `Encaps-->PHB mapping' associated with the incoming top level label. + `Encaps-->PHB mapping' associated with -corresponding label. 4.3.1 `EXP-->PHB mapping' If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping', then the LSR: - determines the incoming PHB by looking at the EXP field of the considered label entry and by using the EXP-->PHB mapping. 4.3.2 `CLP-->PHB mapping' @@ -1457,36 +1352,37 @@ 4.3.3 `DE-->PHB mapping' If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping', then the LSR: - determines the incoming PHB by looking at the DE field of the Frame Relay encapsulation and by using the DE-->PHB mapping. 4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing L-LSP This section defines how the `Set of PHB-->Encaps mappings' of the - Diff-Serv Context is populated for an outgoing L-LSP in order to - allow Encoding of Diff-Serv Information. + Diff-Serv Context is populated at label setup for an outgoing L-LSP + in order to allow Encoding of Diff-Serv Information. 4.4.1 `PHB-->EXP mapping' If the LSR uses an MPLS Shim Layer over this outgoing L-LSP, then - one `PHB-->EXP mapping' is added at label setup to the `Set of - PHB-->Encaps mappings' in the Diff-Serv Context for this outgoing + one `PHB-->EXP mapping' is added to the `Set of + PHB-->Encaps mappings' for this outgoing L-LSP. This `PHB-->EXP mapping' is populated in the following way: + + Le Faucheur et. al 25 + MPLS Support of Diff-Serv July 2000 + - it is a function of the PSC supported on this LSP, and must use the mapping entries relevant for this PSC from the Mandatory PHB-->EXP Mapping defined in section 4.4.1.1. - Le Faucheur et. al 28 - MPLS Support of Diff-Serv June 2000 - For example if the outgoing label corresponds to an L-LSP supporting the AF1 PSC, then the following `PHB-->EXP mapping' is added into the `Set of PHB-->Encaps mappings': PHB EXP Field AF11 ----> 000 AF12 ----> 001 AF13 ----> 010 @@ -1499,167 +1395,97 @@ AFn1 ----> 000 AFn2 ----> 001 AFn3 ----> 010 EF ----> 000 4.4.2 `PHB-->CLP mapping' If the L-LSP is egressing on an ATM interface (i.e. it is an ATM-LSR or it is a frame-based LSR sending packets on an LC-ATM interface or on an ATM interface which is not label switching controlled), then - one `PHB-->CLP mapping' is added at label setup to the `Set of - PHB-->Encaps mappings' in the Diff-Serv Context for this outgoing - L-LSP. + one `PHB-->CLP mapping' is added to the `Set of PHB-->Encaps + mappings' for this outgoing L-LSP. + + If the L-LSP is egressing over an ATM interface which is not label- + controlled, the `PHB-->CLP mapping' is populated as per section + 3.4.2. If the L-LSP is egressing over an LC-ATM interface, the `PHB-->CLP mapping' is populated in the following way: - it is a function of the PSC supported on this LSP, and should use the relevant mapping entries for this PSC from the Default PHB-->CLP Mapping defined in section 3.4.2.1. - For example if the outgoing label corresponds to an L-LSP supporting - the AF1 PSC, then the `PHB-->CLP mapping' should be populated with: - - PHB CLP Field - - AF11 ----> 0 - AF12 ----> 1 - AF13 ----> 1 - - If the L-LSP is egressing over an ATM interface which is not label - switching controlled, the `PHB-->CLP mapping' is populated in the - following way: - - it is a function of the PSC supported on this LSP, and may use - the relevant mapping entries for this PSC from the Default - PHB-->CLP Mapping defined in section 3.4.2.1. Other mappings - than the one defined in section 3.4.2.1 may be used. In - - Le Faucheur et. al 29 - MPLS Support of Diff-Serv June 2000 - - particular, if a mapping from PHBs to CLP is standardized in the - future for operations of Diff-Serv over ATM, such standardized - mapping may then be used. - Notice that if the LSR is a frame-based LSR supporting an L-LSP egressing over an ATM interface, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'. If the LSR is an ATM-LSR supporting an L-LSP, then the `Set of PHB-->Encaps mappings' only contains a `PHB-->CLP mapping'. 4.4.3 `PHB-->DE mapping' + Le Faucheur et. al 26 + MPLS Support of Diff-Serv July 2000 + If the L-LSP is egressing over a Frame Relay interface (i.e. it is an LSR sending packets on an LC-FR interface or on a Frame Relay interface which is not label switching controlled), one `PHB-->DE - mapping' is added at label setup to the `Set of PHB-->Encaps - mappings' in the Diff-Serv Context for this outgoing L-LSP. + mapping' is added to the `Set of PHB-->Encaps mappings' for this + outgoing L-LSP. + + If the L-LSP is egressing over a FR interface which is not label + switching controlled, the `PHB-->DE mapping' is populated as per + section 3.4.3. If the L-LSP is egressing over an LC-FR interface, the `PHB-->DE mapping' is populated in the following way: - it is a function of the PSC supported on this LSP, and should use the relevant mapping entries for this PSC from the Default PHB-->DE Mapping defined in section 3.4.3.1. - If the L-LSP is egressing over a FR interface which is not label - switching controlled, the `PHB-->DE mapping' is populated in the - following way: - - it is a function of the PSC supported on this LSP, and may use - the relevant mapping entries for this PSC from the Default - PHB-->DE Mapping defined in section 3.4.3.1. Other mappings than - the one defined in section 3.4.3.1 may be used. In particular, - if a mapping from PHBs to DE is standardized in the future for - operations of Diff-Serv over Frame Relay, such standardized - mapping may then be used. - Notice that if the LSR is an Edge-LSR supporting an L-LSP egressing over a LC-FR interface, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. If the LSR is a FR-LSR supporting an L-LSP, then the `Set of PHB-->Encaps mappings' only contains a `PHB-->DE mapping'. 4.4.4 `PHB-->802.1 mapping' - If the L-LSP is egressing over a LAN interface on which multiple - 802.1 Traffic Classes are supported as defined in [IEEE_802.1], then - one `PHB-->802.1 mapping' is added at label setup to the `Set of - PHB-->Encaps mappings' in the Diff-Serv Context for this outgoing - L-LSP. This `PHB-->802.1 mapping' is populated in the following way: - - it is a function of the PSC supported on this LSP, and uses the - relevant mapping entries for this PSC from the Preconfigured - `PHB-->802.1 mapping' defined above in section 3.4.4.1. - - Le Faucheur et. al 30 - MPLS Support of Diff-Serv June 2000 - - Notice that if the LSR is supporting an L-LSP egressing over a LAN - interface supporting multiple 802.1 Traffic Classes, then the `Set - of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a - `PHB-->802.1 mapping'. + If the LSP is egressing over a LAN interface on which multiple 802.1 + Traffic Classes are supported as defined in [IEEE_802.1], then one + `PHB-->802.1 mapping' is added as per section 3.4.4. 4.5 Encoding Diff-Serv Information into Encapsulation Layer on Outgoing L-LSP This section defines how to encode Diff-Serv information into the MPLS encapsulation Layer for a transmitted label entry corresponding to an outgoing L-LSP. This requires that the `Set of PHB-->Encaps - mappings' is populated as defined above in section 4.4. + mappings' is populated as defined in section 4.4. The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the - NHLFE. - -4.5.1 `PHB-->EXP mapping' - - If the `Set of PHB-->Encaps mappings' of the transmitted label - contains a mapping of the form `PHB-->EXP mapping', then the LSR: - - determines the value to be written in the EXP field of the - corresponding level label entry by looking up the "outgoing PHB" - in this PHB-->EXP mapping table. - -4.5.2 `PHB-->CLP mapping' - - If the `Set of PHB-->Encaps mappings' of the transmitted label - contains a mapping of the form `PHB-->CLP mapping', then the LSR: - - determines the value to be written in the CLP field of the ATM - Layer encapsulation by looking up the "outgoing PHB" in this - PHB-->CLP mapping table. - -4.5.3 `PHB-->DE mapping' - - If the `Set of PHB-->Encaps mappings' of the transmitted label - contains a mapping of the form `PHB-->DE mapping', then the LSR: - - determines the value to be written in the DE field of the Frame - Relay encapsulation by looking up the "outgoing PHB" in this - PHB-->DE mapping table. - -4.5.4 `PHB-->802.1 mapping' - - If the `Set of PHB-->Encaps mappings' of the transmitted label - contains a mapping of the form `PHB-->802.1 mapping', then the LSR: - - determines the value to be written in the User_Priority field of - the Tag Control Information of the 802.1 encapsulation header - [IEEE_802.1] by looking up the "outgoing PHB" in this - PHB-->802.1 mapping table. + NHLFE and then performs corresponding encoding as specified in + sections 3.5.1, 3.5.2, 3.5.3 and 3.5.4. 4.6 L-LSP Merging - Le Faucheur et. al 31 - MPLS Support of Diff-Serv June 2000 - 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: + one LSR. L-LSPs are compatible with LSP Merging under the following + condition: L-LSPs can only be merged into one L-LSP if they support the same PSC. + Le Faucheur et. al 27 + MPLS Support of Diff-Serv July 2000 + The above merge condition MUST be enforced by LSRs through explicit checking at label setup that the same PSC is supported on the merged LSPs. Note that when L-LSPs merge, the bandwidth that is available for the PSC downstream of the merge point must be sufficient to carry the sum of the merged traffic. This is particularly important in the case of EF traffic. This can be ensured in multiple ways (for instance via provisioning, or via bandwidth signaling and explicit admission control). @@ -1690,32 +1516,31 @@ This new DIFFSERV object is optional with respect to RSVP so that general RSVP implementations not concerned with MPLS LSP set up do not have to support this object. The DIFFSERV Object is optional for support of LSP Tunnels as defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs using the preconfigured EXP<-->PHB mapping in compliance with this specification MAY support the DIFFSERV Object. A Diff-Serv capable LSR supporting E-LSPs using a signaled EXP<-->PHB mapping in - - Le Faucheur et. al 32 - MPLS Support of Diff-Serv June 2000 - compliance with this specification MUST support the DIFFSERV Object. A Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST support the DIFFSERV Object. 5.1.1 Path Message Format The format of the Path message is as follows: + Le Faucheur et. al 28 + MPLS Support of Diff-Serv July 2000 + ::= [ ] [ ] [ ] [ ] [ ... ] [ ] @@ -1746,31 +1571,30 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAP (MAPnb) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 28 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. MAPnb : 4 bits - - Le Faucheur et. al 33 - MPLS Support of Diff-Serv June 2000 - Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 1 to 8. MAP : 32 bits Each MAP entry defines the mapping between one EXP field value and one PHB. The MAP entry has the following format: + Le Faucheur et. al 29 + MPLS Support of Diff-Serv July 2000 + 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | EXP | PHBID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 13 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. @@ -1802,192 +1626,198 @@ The PSC indicates a PHB Scheduling Class to be supported by the LSP. The PSC is encoded as specified in section 2 of [PHBID]: - Where the PSC comprises a single PHB defined by standards action, the encoding for the PSC is the encoding for this single PHB. It is the recommended DSCP value for that PHB, left-justified in the 16-bit field, with bits 6 through 15 set to zero. - Where the PSC comprises multiple PHBs defined by standards action, the PSC encoding is the encoding for this set of PHB. It is the smallest numerical value of the recommended DSCP for - - Le Faucheur et. al 34 - MPLS Support of Diff-Serv June 2000 - the various PHBs in the PSC, left-justified in the 16 bit field, with bits 6 through 13 and bit 15 set to zero and with bit 14 set to one. For instance, the encoding of the EF PSC is : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + + Le Faucheur et. al 30 + MPLS Support of Diff-Serv July 2000 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For instance, the encoding of the AF1 PSC is : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 1 0|0 0 0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -5.3 Handling Diff-Serv Object +5.3 Handling DIFFSERV Object To establish an LSP tunnel with RSVP, the sender creates a Path message with a session type of LSP_Tunnel_IPv4 and with a LABEL_REQUEST object as per [RSVP_MPLS_TE]. - Where the sender supports Diff-Serv, to establish with RSVP an E-LSP - tunnel which uses the Preconfigured EXP<-->PHB mapping, the sender - creates a Path message: + + To establish with RSVP an E-LSP tunnel which uses the Preconfigured + EXP<-->PHB mapping, the sender creates a Path message: - with a session type of LSP_Tunnel_IPv4, - with the LABEL_REQUEST object, and - without the DIFFSERV object. - Where the sender supports Diff-Serv, to establish with RSVP an E-LSP - tunnel which uses a signaled EXP<-->PHB mapping, the sender creates - a Path message : + To establish with RSVP an E-LSP tunnel which uses a signaled EXP<-- + >PHB mapping, the sender creates a Path message : - with a session type of LSP_Tunnel_IPv4, - with the LABEL_REQUEST object, - with the DIFFSERV object for an E-LSP containing one MAP entry for each EXP value to be supported on this E-LSP. - Where the sender supports Diff-Serv, to establish with RSVP an L-LSP - tunnel, the sender creates a Path message: + To establish with RSVP an L-LSP tunnel, the sender creates a Path + message: - with a session type of LSP_Tunnel_IPv4, - with the LABEL_REQUEST object, - with the DIFFSERV object for an L-LSP containing the PHB Scheduling Class (PSC) supported on this L-LSP. If a path message contains multiple DIFFSERV objects, only the first one is meaningful; subsequent DIFFSERV object(s) must be ignored and not forwarded. - Each node along the path records the DIFFSERV object, when present, + Each LSR along the path records the DIFFSERV object, when present, in its path state block. - Le Faucheur et. al 35 - MPLS Support of Diff-Serv June 2000 - - The destination node of an E-LSP or L-LSP responds to the Path + The destination LSR of an E-LSP or L-LSP responds to the Path message containing the LABEL_REQUEST object by sending a Resv message: - with the LABEL object - without a DIFFSERV object. - Assuming the reservation is accepted and a label is associated with - the reservation, the Diff-Serv LSRs (sender, destination, - intermediate nodes) must: + Assuming the label request is accepted and a label is allocated, the + Diff-Serv LSRs (sender, destination, intermediate nodes) must: + + Le Faucheur et. al 31 + MPLS Support of Diff-Serv July 2000 + - update the Diff-Serv Context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label), - install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label). - An RSVP router that does recognizes the DIFFSERV object and that - receives a path message which contains the DIFFSERV object but which - does not contain a LABEL_REQUEST object or which does not have a - session type of LSP_Tunnel_IPv4, sends a PathErr towards the sender - with the error code `Diff-Serv Error' and an error value of - `Unexpected DIFFSERV object'. Those are defined below in section - 5.5. + An LSR that recognizes the DIFFSERV object and that receives a path + message which contains the DIFFSERV object but which does not + contain a LABEL_REQUEST object or which does not have a session type + of LSP_Tunnel_IPv4, sends a PathErr towards the sender with the + error code `Diff-Serv Error' and an error value of `Unexpected + DIFFSERV object'. Those are defined below in section 5.5. - A node receiving a Path message with the DIFFSERV object for E-LSP, + An LSR receiving a Path message with the DIFFSERV object for E-LSP, which recognizes the DIFFSERV object but does not support the particular PHB encoded in one, or more, of the MAP entries, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unsupported PHB'. Those are defined below in section 5.5. - A node receiving a Path message with the DIFFSERV object for E-LSP, + An LSR receiving a Path message with the DIFFSERV object for E-LSP, which recognizes the DIFFSERV object but determines that the signaled EXP<-->PHB mapping is invalid, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Invalid EXP<-->PHB mapping'. Those are defined below in section 5.5. The EXP<-->PHB mapping signaled in the DIFFSERV Object for an E-LSP is invalid when: - the MAPnb field is not within the range 1 to 8 or - a given EXP value appears in more than one MAP entry, or - the PHBID encoding is invalid. - A node receiving a Path message with the DIFFSERV object for L-LSP, + An LSR receiving a Path message with the DIFFSERV object for L-LSP, which recognizes the DIFFSERV object but does not support the particular PSC encoded in the PSC field, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unsupported PSC'. Those are defined below in section 5.5. - A Diff-Serv LSR MUST handle the situations where the reservation can - not be accepted for other reasons than those already discussed in - this section, in accordance with [RSVP_MPLS_TE] (eg. reservation + An LSR receiving a Path message with the DIFFSERV object, which + recognizes the DIFFSERV object but that is unable to allocate the + required per-LSP Diff-Serv context sends a PathErr with the error + code "Diff-Serv Error" and the error value "Per-LSP context + allocation failure". Those are defined below in section 5.5. + + A Diff-Serv LSR MUST handle the situations where the label request + can not be accepted for other reasons than those already discussed + in this section, in accordance with [RSVP_MPLS_TE] (e.g. reservation rejected by admission control, a label can not be associated). - Le Faucheur et. al 36 - MPLS Support of Diff-Serv June 2000 +5.4 Non-support of the DIFFSERV Object -5.4 Non-support of the Diff-Serv Object + An LSR that does not recognize the DIFFSERV object Class-Num must + behave in accordance with the procedures specified in [RSVP] for an - An RSVP router that does not recognize the DIFFSERV object Class-Num - must behave in accordance with the procedures specified in [RSVP] - for an unknown Class-Num whose format is 0bbbbbbb ie. it must send a + Le Faucheur et. al 32 + MPLS Support of Diff-Serv July 2000 + + unknown Class-Num whose format is 0bbbbbbb i.e. it must send a PathErr with the error code `Unknown object class' toward the sender. - An RSVP router that recognizes the DIFFSERV object Class-Num but - does not recognize the DIFFSERV object C-Type, must behave in - accordance with the procedures specified in [RSVP] for an unknown C- - type ie. It must send a PathErr with the error code `Unknown object - C-Type' toward the sender. + An LSR that recognize the DIFFSERV object Class-Num but does not + recognize the DIFFSERV object C-Type, must behave in accordance with + the procedures specified in [RSVP] for an unknown C-type i.e. It + must send a PathErr with the error code `Unknown object C-Type' + toward the sender. In both situations, this causes the path set-up to fail. The sender should notify management that a L-LSP cannot be established and - possibly take action to retry reservation establishment without the - DIFFSERV object (eg. attempt to use E-LSPs with Preconfigured - EXP<-->PHB mapping as a fall-back strategy). + possibly take action to retry LSP establishment without the DIFFSERV + object (e.g. attempt to use E-LSPs with Preconfigured EXP<-->PHB + mapping as a fall-back strategy). 5.5 Error Codes For Diff-Serv In the procedures described above, certain errors must be reported as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error - code is 26 (TBD). + code is TBD (number to be allocated by IANA)). The following defines error values for the Diff-Serv Error: Value Error 1 Unexpected DIFFSERV object 2 Unsupported PHB 3 Invalid EXP<-->PHB mapping 4 Unsupported PSC + 5 Per-LSP context allocation failure 5.6 Use of COS Service with E-LSPs and L-LSPs Both E-LSPs and L-LSPs can be established with bandwidth reservation or without bandwidth reservation. To establish an E-LSP or an L-LSP with bandwidth reservation, Int- Serv's Controlled Load service (or possibly Guaranteed Service) is used and the bandwidth is signaled in the SENDER_TSPEC (respectively FLOWSPEC) of the path (respectively Resv) message. To establish an E-LSP or an L-LSP without bandwidth reservation, the Class of Service service defined in [RSVP_MPLS_TE] is used. Note that this specification defines usage of E-LSPs and L-LSPs for support of the Diff-Serv service only. Regardless of whether the signaling messages actually indicate an Int-Serv service of COS, GS or CL and regardless of whether the signaling messages contain a - - Le Faucheur et. al 37 - MPLS Support of Diff-Serv June 2000 - signaled bandwidth reservation or not, E-LSPs and L-LSPs are defined here for support of Diff-Serv services. Support of Int-Serv services + + Le Faucheur et. al 33 + MPLS Support of Diff-Serv July 2000 + over an MPLS Diff-Serv backbone is outside the scope of this specification. A Path message containing a COS SENDER_TSPEC and not containing a DIFFSERV object indicates to a Diff-Serv capable LSR that the LSP to be established is an E-LSP using the Preconfigured mapping and without any bandwidth reservation. A Path message containing a COS SENDER_TSPEC and containing a DIFFSERV object for E-LSP indicates to a Diff-Serv capable LSR that @@ -2024,24 +1854,25 @@ 6. LDP Extensions for Diff-Serv Support The MPLS architecture does not assume a single label distribution protocol. [LDP] defines the Label Distribution Protocol and its usage for establishment of label switched paths (LSPs) in MPLS networks. This section specifies the extensions to LDP to establish label switched path (LSPs) supporting Differentiated Services in MPLS networks. - Le Faucheur et. al 38 - MPLS Support of Diff-Serv June 2000 - One new LDP TLV is defined in this document: + + Le Faucheur et. al 34 + MPLS Support of Diff-Serv July 2000 + - the Diff-Serv TLV Detailed description of this TLV is provided below. The new Diff-Serv TLV is optional with respect to LDP. A Diff-Serv capable LSR supporting E-LSPs which uses the Preconfigured EXP<-->PHB mapping in compliance with this specification MAY support the Diff-Serv TLV. A Diff-Serv capable LSR supporting E-LSPs which uses the signaled EXP<-->PHB mapping in compliance with this specification MUST support the Diff-Serv TLV. A Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST @@ -2078,27 +1909,26 @@ Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 1 to 8. MAP : 32 bits Each MAP entry defines the mapping between one EXP field value and one PHB. The MAP entry has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Le Faucheur et. al 39 - MPLS Support of Diff-Serv June 2000 - | Reserved | EXP | PHBID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Le Faucheur et. al 35 + MPLS Support of Diff-Serv July 2000 + Reserved : 13 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. EXP : 3 bits This field contains the value of the EXP field for the EXP<-->PHB mapping defined in this MAP entry. PHBID : 16 bits This field contains the PHBID of the PHB for the @@ -2133,46 +1963,47 @@ - Where the PSC comprises multiple PHBs defined by standards action, the PSC encoding is the encoding for this set of PHB. It is the smallest numerical value of the recommended DSCP for the various PHBs in the PSC, left-justified in the 16 bit field, with bits 6 through 13 and bit 15 set to zero and with bit 14 set to one. For instance, the encoding of the EF PSC is : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - - Le Faucheur et. al 40 - MPLS Support of Diff-Serv June 2000 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0| + + Le Faucheur et. al 36 + MPLS Support of Diff-Serv July 2000 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For instance, the encoding of the AF1 PSC is : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 1 0|0 0 0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2 Diff-Serv Status Code Values The following values are defined for the Status Code field of the Status TLV: Status Code E Status Data - Unsupported PHB 0 0x00000016 - Invalid EXP<-->PHB mapping 0 0x00000017 - Unsupported PSC 0 0x00000018 - Unexpected Diff-Serv TLV 0 0x00000019 + Unexpected Diff-Serv TLV 0 0x01000001 + Unsupported PHB 0 0x01000002 + Invalid EXP<-->PHB mapping 0 0x01000003 + Unsupported PSC 0 0x01000004 + Per-LSP context allocation failure 0 0x01000005 6.3 Diff-Serv Related LDP Messages 6.3.1 Label Request Message The format of the Label Request message is extended as follows, to optionally include the Diff-Serv TLV: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -2189,25 +2020,25 @@ 6.3.2 Label Mapping Message The format of the Label Mapping message is extended as follows, to optionally include the Diff-Serv TLV: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ID | - Le Faucheur et. al 41 - MPLS Support of Diff-Serv June 2000 + Le Faucheur et. al 37 + MPLS Support of Diff-Serv July 2000 - | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3.3 Label Release Message @@ -2244,26 +2075,26 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.4 Handling of the Diff-Serv TLV 6.4.1 Handling of the Diff-Serv TLV in Downstream Unsolicited Mode - Le Faucheur et. al 42 - MPLS Support of Diff-Serv June 2000 - This section describes operations when the Downstream Unsolicited Mode is used. + Le Faucheur et. al 38 + MPLS Support of Diff-Serv July 2000 + When allocating a label for an E-LSP which is to use the preconfigured EXP<-->PHB mapping, a downstream Diff-Serv LSR issues a Label Mapping message without the Diff-Serv TLV. When allocating a label for an E-LSP which is to use a signaled EXP<-->PHB mapping, a downstream Diff-Serv LSR issues a Label Mapping message with the Diff-Serv TLV for an E-LSP which contains one MAP entry for each EXP value to be supported on this E-LSP. When allocating a label for an L-LSP, a downstream Diff-Serv LSR @@ -2299,25 +2130,25 @@ - the MAPnb field is not within the range 1 to 8, or - a given EXP value appears in more than one MAP entry, or - the PHBID encoding is invalid An upstream Diff-Serv LSR receiving a Label Mapping message with the Diff-Serv TLV for an L-LSP containing a PSC value which is not supported, must reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unsupported PSC'. - Le Faucheur et. al 43 - MPLS Support of Diff-Serv June 2000 - 6.4.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode + Le Faucheur et. al 39 + MPLS Support of Diff-Serv July 2000 + This section describes operations when the Downstream on Demand Mode is used. When requesting a label for an E-LSP which is to use the preconfigured EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a Label Request message without the Diff-Serv TLV. When requesting a label for an E-LSP which is to use a signaled EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a Label Request message with the Diff-Serv TLV for an E-LSP which contains one MAP @@ -2354,580 +2185,455 @@ reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Unsupported PHB'. A downstream Diff-Serv LSR receiving a Label Request message with the Diff-Serv TLV for an E-LSP and determining that the signaled EXP<-->PHB mapping is invalid, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Invalid EXP<-->PHB Mapping'. The EXP<-->PHB mapping signaled in the DIFFSERV TLV for an E-LSP is invalid when: - the MAPnb field is not within the range 1 to 8, or - - Le Faucheur et. al 44 - MPLS Support of Diff-Serv June 2000 - - a given EXP value appears in more than one MAP entry, or - the PHBID encoding is invalid + Le Faucheur et. al 40 + MPLS Support of Diff-Serv July 2000 + A downstream Diff-Serv LSR receiving a Label Request message with the Diff-Serv TLV for an L-LSP containing a PSC value which is not supported, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Unsupported PSC'. A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in + a Label Request message but is unable to allocate the required + per-LSP context information, must reject the request sending a + Notification message which includes the Status TLV with a Status + Code of `Per-LSP context allocation failure'. + + A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in a Label Request message and supports the requested PSC but is not - able to satisfy the label request for other reasons (eg. no label + able to satisfy the label request for other reasons (e.g. 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 + existing LDP procedures [LDP] (e.g. with a `No Label Resource' + Status Code). This Notification message must include the requested Diff-Serv TLV. 6.5 Non-Handling of the Diff-Serv TLV An LSR that does not recognize the Diff-Serv TLV Type, on receipt of a Label Request message or a Label Mapping message containing the Diff-Serv TLV, must behave in accordance with the procedures specified in [LDP] for an unknown TLV whose U Bit and F Bit are set - to 0 ie. it must ignore the message, return a Notification message + to 0 i.e. it must ignore the message, return a Notification message with `Unknown TLV' Status. 6.6 Bandwidth Information Bandwidth information may also be signaled at establishment time of E-LSP and L-LSP, for instance for the purpose of Traffic Engineering, using the Traffic Parameters TLV as described in [MPLS CR LDP]. -7. MPLS Support of Diff-Serv over PPP interfaces +7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and Non-LC-FR +Interfaces The general operations for MPLS support of Diff-Serv, including label forwarding and LSP setup operations are specified in the previous sections. This section describes the specific operations - required for MPLS support of Diff-Serv over PPP links. + required for MPLS support of Diff-Serv over PPP interfaces, LAN + interfaces, ATM Interfaces which are not label controlled and Frame + Relay interfaces which are not label controlled. - This document allows any of the following LSP combinations per FEC - within an MPLS PPP Diff-Serv domain: + On these interfaces, this specification allows any of the following + LSP combinations per FEC: - Zero or any number of E-LSP, and - - Zero or any number of L-LSPs. - -7.1 LSR implementation with PPP interfaces - A Diff-Serv capable LSR with PPP interfaces MUST support, over these - PPP interfaces, E-LSPs which use the pre-configured EXP<-->PHB - - Le Faucheur et. al 45 - MPLS Support of Diff-Serv June 2000 - - mapping, in compliance with all the material from this specification - pertaining to those types of LSPs. - - A Diff-Serv capable LSR with PPP interfaces MAY support, over these - PPP interfaces, E-LSPs which use a signaled EXP<-->PHB mapping. If a - Diff-Serv LSR does support E-LSPs which use a signaled EXP<-->PHB - mapping over PPP interfaces, then it MUST do so in compliance with - all the material from this specification pertaining to those types - of LSPs. - - A Diff-Serv capable LSR with PPP interfaces MAY support L-LSPs over - these PPP interfaces. If a Diff-Serv LSR does support L-LSPs over - PPP interfaces, then it MUST do so in compliance with all the - material from this specification pertaining to L-LSPs. - -7.2 LSR implementation with non-LC ATM interfaces + Le Faucheur et. al 41 + MPLS Support of Diff-Serv July 2000 - The E-LSP/L-LSP support requirements for an LSR running MPLS over a - traditional ATM connection (ie. where the interface is not label - switching controlled) are the same as those specified in section 7.1 - for an LSR with PPP interfaces. + - Zero or any number of L-LSPs. -7.3 LSR implementation with non-LC FR interfaces + A Diff-Serv capable LSR MUST support E-LSPs which use pre-configured + EXP<-->PHB mapping over these interfaces. - The E-LSP/L-LSP support requirements for an LSR running MPLS over a - traditional Frame Relay connection (ie. where the interface is not - label switching controlled) are the same as those specified in - section 7.1 for an LSR with PPP interfaces. + A Diff-Serv capable LSR MAY support E-LSPs which use signaled + EXP<-->PHB mapping and L-LSPs over these interfaces. 8. MPLS Support of Diff-Serv over LC-ATM Interfaces - 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 label switching - controlled ATM (LC-ATM) interfaces. + This section describes the specific operations required for MPLS + support of Diff-Serv over label switching controlled ATM (LC-ATM) + interfaces. This document allows any number of L-LSPs per FEC within an MPLS ATM Diff-Serv domain. E-LSPs are not supported over LC-ATM interfaces. -8.1 Merging - - The use of merging is optional. In case that merging of ATM LSPs is - used, procedures described in section 3.6 of this specification - apply. Additionally, to avoid cell interleaving problems with AAL-5 - merging, procedures specified in [MPLS_ATM] MUST be followed. - -8.2 Use of ATM Traffic Classes and Traffic Management mechanisms +8.1 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 - - Le Faucheur et. al 46 - MPLS Support of Diff-Serv June 2000 - scope of this specification. The only requirement for compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be compliant with the corresponding Diff-Serv PHB specifications. - Since there is only one bit for encoding the PHB drop precedence - value over ATM links, only two different drop precedence levels are - supported in ATM LSRs. The behavior for AF MUST comply to procedures - described in [DIFF_AF] for the case when only two drop precedence - levels are supported. + Since there is only one bit (CLP) for encoding the PHB drop + precedence value over ATM links, only two different drop precedence + levels are supported in ATM LSRs. Sections 4.2.2 and 4.4.2 define + how the three drop precedence levels of the AFn Ordered Aggregates + are mapped to these two ATM drop precedence levels. This mapping is + in accordance with the requirements specified in [DIFF_AF] for the + case when only two drop precedence levels are supported. To avoid discarding parts of the packets, frame discard mechanisms, such as Early Packet Discard (EPD) SHOULD be enabled in the ATM-LSRs for all PHBs described in this document. -8.3 LSR Implementation With LC-ATM Interfaces +8.2 LSR Implementation With LC-ATM Interfaces - A Diff-Serv capable LSR with LC-ATM interfaces MUST support L-LSPs - over these ATM interfaces in compliance with all the material from - this specification pertaining to those types of LSPs. Additionally, - procedures specified in [MPLS_ATM] MUST be followed by compliant - implementation. + A Diff-Serv capable LSR MUST support L-LSPs over LC-ATM interfaces. This specification assumes that Edge-LSRs of the ATM-LSR domain use the "shim header" encapsulation method defined in [MPLS_ATM]. Operations without the "shim header" encapsulation is outside the scope of this specification. 9. MPLS Support of Diff-Serv over LC-FR Interfaces - 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 label switching - controlled Frame Relay (LC-FR) interfaces. + Le Faucheur et. al 42 + MPLS Support of Diff-Serv July 2000 + + This section describes the specific operations required for MPLS + support of Diff-Serv over label switching controlled Frame Relay + (LC-FR) interfaces. This document allows any number of L-LSPs per FEC within an MPLS Frame Relay Diff-Serv domain. E-LSPs are not supported over LC-FR interfaces. -9.1 Merging - - The use of merging is optional. In case that merging of Frame Relay - LSPs is used, procedures described in section 3.6 of this - specification apply as well as procedures in [MPLS_FR]. - -9.2 Use of Frame Relay Traffic parameters and Traffic Management +9.1 Use of Frame Relay Traffic parameters and Traffic Management mechanisms - Le Faucheur et. al 47 - MPLS Support of Diff-Serv June 2000 - The use of the Frame Relay traffic parameters as specified by ITU-T and Frame Relay-Forum or of vendor specific Frame Relay traffic management mechanisms is outside of the scope of this specification. The only requirement for compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the Frame Relay LSR MUST be compliant with the corresponding Diff-Serv PHB specifications. - Since there is only one bit for encoding the PHB drop precedence - value over Frame Relay links, only two different drop precedence - levels are supported in Frame Relay LSRs. The behavior for AF MUST - comply to procedures described in [DIFF_AF] for the case when only - two drop precedence levels are supported. + Since there is only one bit (DE) for encoding the PHB drop + precedence value over Frame Relay links, only two different drop + precedence levels are supported in Frame Relay LSRs. Sections 4.2.3 + and 4.4.3 define how the three drop precedence levels of the AFn + Ordered Aggregates are mapped to these two Frame Relay drop + precedence levels. This mapping is in accordance with the + requirements specified in [DIFF_AF] for the case when only two drop + precedence levels are supported. -9.3 LSR Implementation With LC-FR Interfaces +9.2 LSR Implementation With LC-FR Interfaces - A Diff-Serv capable LSR with LC-FR interfaces MUST support - L-LSPs over these Frame Relay interfaces in compliance with all the - material from this specification pertaining to those types of LSPs. - Additionally, procedures specified in [MPLS_FR] MUST be followed by - compliant implementation. + A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay + interfaces. This specification assumes that Edge-LSRs of the FR-LSR domain use the "generic encapsulation" method as recommended in [MPLS_FR]. Operations without the "generic encapsulation" is outside the scope of this specification. -10. MPLS Support of Diff-Serv over LAN Interfaces - - 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 interfaces. - - This document allows the following set of LSP setup combinations per - FEC over a LAN interface: - - - Zero or any number of E-LSP, and - - Zero or any number of L-LSPs. - -10.1 LSR Implementation With LAN Interfaces - - A Diff-Serv capable LSR with LAN interfaces MUST support, over these - LAN interfaces, E-LSPs which use the pre-configured EXP<-->PHB - mapping, in compliance with all the material from this specification - pertaining to those types of LSPs. - - A Diff-Serv capable LSR with LAN interfaces MAY support, over these - LAN interfaces, E-LSPs which use a signaled EXP<-->PHB mapping. If a - Diff-Serv LSR does support E-LSPs which use a signaled EXP<-->PHB - mapping over LAN interfaces, then it MUST do so in compliance with - - Le Faucheur et. al 48 - MPLS Support of Diff-Serv June 2000 - - all the material from this specification pertaining to those types - of LSPs. - - A Diff-Serv capable LSR MAY support L-LSPs over LAN interfaces. If a - Diff-Serv LSR does support L-LSPs over LAN interfaces, then it MUST - do so in compliance with all the material from this specification - pertaining to L-LSPs. - -11. Explicit Congestion Notification - - Explicit Congestion Notification is described in [ECN] and is - proposed as an Experimental extension to the IP protocol. - - [MPLS_ECN] discusses deployment of ECN in an MPLS network using the - Shim Header as the MPLS encapsulation. It demonstrates that, - provided a given LSP is identified as ECN-capable or as non-ECN- - capable (and consistently recognized as such by all the involved - LSRs), then ECN can be supported in an MPLS domain where the Shim - Header is used as the MPLS encapsulation via a single bit of the EXP - field. - - The details of how a given LSP is to be identified as ECN-capable or - non-ECN-capable (whether via extensions to the LSP establishment - signaling and procedures, via configuration or via other means) are - outside the scope of this specification. - - However, this specification recognizes that, within an ECN-capable - MPLS domain where LSPs are identified as ECN-capable or not-ECN- - capable: - - - Support of ECN does not require that any bit(s) from the EXP - field be reserved for ECN operations across all LSPs even when - those LSPs are not ECN-capable. Consequently, LSPs identified as - non-ECN-capable (regardless of whether this is because at least - one LSR on the LSP does not support ECN operations or whether - this is because the network administrator does not wish to use - ECN on this LSP) can make use of the full 3-bit EXP field for - Diff-Serv purposes. Thus, non-ECN-capable E-LSPs and non-ECN- - capable L-LSPs can operate as defined earlier in this document - without any restriction imposed by the fact that the MPLS domain - is ECN-capable. In particular, up to 8 BAs can still be - transported over a non-ECN-capable E-LSP within an ECN-capable - MPLS domain. Similarly, non-ECN-capable L-LSPs within an ECN- - capable MPLS domain can support all the drop precedence levels - of currently defined PSCs. Should a future PSC involve more than - 4 drop precedence levels, non-ECN-capable L-LSPs within an ECN- - capable MPLS domain could still use the full 3-bit field EXP. - - - Because a single bit is required to encode the ECN information - inside the ECN-capable MPLS domain, LSPs identified as ECN- - capable can make use of two bits of the EXP field value for - - Le Faucheur et. al 49 - MPLS Support of Diff-Serv June 2000 - - Diff-Serv purposes. In particular, up to 4 BAs can be - transported over an ECN-capable E-LSP. Similarly, up to 4 drop - precedence levels can be supported over an ECN-capable L-LSP; - since all the PSCs corresponding to PHBs currently defined - through standards action involve less than 4 drop precedence - levels, ECN support does not currently restrict Diff-Serv - operations over L-LSPs. Should a PSC corresponding to future - PHBs defined by standards action or corresponding to local use - or experimental PHBs, involve more than 4 drop precedence - levels, then ECN support over the corresponding LSP would - constrain the PSC to 4 drop precedence levels; relative benefits - of additional precedence levels beyond 4, would then be weighted - by the network administrator over the benefits of ECN, to - determine whether it is preferable to support this PSC over an - ECN-capable or non-ECN-capable LSP. - -11.1 MPLS ECN bit with Shim Header - - Where the Shim Header is used as the MPLS encapsulation, ECN - information is to be encoded on ECN-capable LSPs in the first bit of - the 3-bit EXP field in the following way: - - EXP field MPLS ECN Meaning - - 0xx --> `ECT, not CE' - 1xx --> `not ECT, or ECT+CE' +10. IANA Considerations. - where ECT stands for `ECN Capable Transport' and `CE' stands for - `Congestion experienced'. + This document defines a number of objects with implications for + IANA. - Detailed specification for usage of this MPLS ECN bit is outside the - scope of this document. + This document defines in section 5.2 a new RSVP object, the Diffserv + object. This object requires a number to be assigned from the space + defined in [RSVP] for those objects which, if not understood, cause + the entire RSVP message to be rejected with an error code of + "Unknown Object Class". Such objects are identified by a zero in the + most significant bit of the class number. Within that space, this + object should be assigned a number from the "IETF Consensus" space. - For ECN-capable LSPs, the mappings between EXP and PHB (be it the - E-LSP Preconfigured Mapping specified in section 3.2.1, the E-LSP - Signaled Mapping, the L-LSP Mappings defined in section 4.2.1.1 and - 4.4.1.1) are adjusted accordingly to only take into account the last - 2 bits of the 3-bit EXP field. + Le Faucheur et. al 43 + MPLS Support of Diff-Serv July 2000 - Note that when the E-LSP signaled mapping is used on an ECN-capable - E-LSP, the signaled mapping only needs to contain a single MAP entry - for a given PHBID, which includes an EXP value with its first bit - set to zero. + This document defines in section 5.5 a new RSVP error code, + "Diffserv Error". This error code should be assigned by IANA. This + document defines values 1 through 5 of the value field to be used + within the ERROR_SPEC object for this error code. Future allocations + of values in this space should be handled by IANA using the First + Come First Served policy defined in [IANA]. - 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. + This document defines in section 6.1 a new LDP TLV, the Diffserv + TLV. The number for this TLV has been assigned by working group + consensus according to the policies defined in [LDP]. -12. Security Considerations + This document defines in section 6.2 five new LDP Status Code values + for Diffserv-related error conditions. The values for the Status + Code have been assigned by working group consensus according to the + policies defined in [LDP]. - Le Faucheur et. al 50 - MPLS Support of Diff-Serv June 2000 +11. 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 +12. Acknowledgments - This document has benefited from discussions with K. K. - Ramakrishnan, Eric Rosen, Angela Chiu and Carol Iturralde. It has - also borrowed from the work done by D. Black regarding Diff-Serv and - IP Tunnels interaction. + This document has benefited from discussions with Eric Rosen, Angela + Chiu and Carol Iturralde. It has also borrowed from the work done by + D. Black regarding Diff-Serv and IP Tunnels interaction. APPENDIX A. Example Deployment Scenarios This section does not provide additional specification and is only here to provide examples of how this flexible approach for Diff-Serv support over MPLS may be deployed. Pros and cons of various deployment options for particular environments are beyond the scope of this document. -A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no Fast -Reroute +A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS +Protection A Service Provider running 8 (or fewer) BAs over MPLS, not - performing Traffic engineering, not performing protection via Fast - Reroute and using MPLS Shim Header encapsulation in his/her network, - may elect to run Diff-Serv over MPLS using a single E-LSP per FEC - established via LDP. Furthermore the Service Provider may elect to - use the preconfigured EXP<-->PHB mapping. + performing Traffic engineering, not using MPLS protection and using + MPLS Shim Header encapsulation in his/her network, may elect to run + Diff-Serv over MPLS using a single E-LSP per FEC established via + LDP. Furthermore the Service Provider may elect to use the + preconfigured EXP<-->PHB mapping. Operations can be summarized as follows: + + Le Faucheur et. al 44 + MPLS Support of Diff-Serv July 2000 + - 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) + (e.g. 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. + allocated to AF1) and the dropping behavior for each PHB (e.g. drop profile for AF11, AF12, AF13) - LSRs signal establishment of a single E-LSP per FEC using LDP in - accordance with the specification above (ie no Diff-Serv TLV in - LDP Label Request/Label Mapping messages to implicitly indicate - that the LSP is an E-LSP and that it uses the preconfigured - mapping) + accordance with the specification above (i.e. no Diff-Serv TLV + in LDP Label Request/Label Mapping messages to implicitly + indicate that the LSP is an E-LSP and that it uses the + preconfigured mapping) -A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no Fast -Reroute +A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no MPLS +Protection A Service Provider running more than 8 BAs over MPLS, not performing - Traffic Engineering and not performing protection via Fast Reroute - - Le Faucheur et. al 51 - MPLS Support of Diff-Serv June 2000 - - and using MPLS Shim encapsulation in his/her network may elect to - run Diff-Serv over MPLS using for each FEC: + Traffic Engineering, not using MPLS protection and using MPLS Shim + encapsulation in his/her network may elect to run Diff-Serv over + MPLS using for each FEC: - one E-LSP established via LDP and using the preconfigured mapping to support a set of 8 (or less) BAs, AND - one L-LSP per established via LDP for support of the other BAs. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs transported over the E-LSP - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB - LSRs signal establishment of a single E-LSP per FEC for the set - of E-LSP transported BAs using LDP as specified above (ie no + of E-LSP transported BAs using LDP as specified above (i.e. no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping) - LSRs signal establishment of one L-LSP per for the - other BAs using LDP as specified above (ie Diff-Serv TLV in LDP - Label Request/Label Mapping messages to indicate the L-LSP's + other BAs using LDP as specified above (i.e. Diff-Serv TLV in + LDP Label Request/Label Mapping messages to indicate the L-LSP's PSC). A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering, -Aggregate Fast Reroute +Aggregate MPLS Protection A Service Provider running 8 (or fewer) BAs over MPLS, performing - aggregate Traffic Engineering (ie performing a single common path - selection for all BAs), performing aggregate protection via Fast - Reroute (ie performing Fast Reroute for all PSCs jointly) and using - MPLS Shim Header encapsulation in his/her network, may elect to run - Diff-Serv over MPLS using a single E-LSP per FEC established via - RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] and using the + aggregate Traffic Engineering (i.e. performing a single common path + selection for all BAs), using aggregate MPLS protection (i.e. + restoring service to all PSCs jointly) and using MPLS Shim Header + + Le Faucheur et. al 45 + MPLS Support of Diff-Serv July 2000 + + encapsulation in his/her network, may elect to run Diff-Serv over + MPLS using a single E-LSP per FEC established via RSVP + [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] and using the preconfigured mapping. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field - (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) + (e.g. 000<-->AF11, 001<-->AF12, 010<-->AF13) - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (eg bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) - LSRs signal establishment of a single E-LSP per FEC which will use the preconfigured mapping: - * using the RSVP protocol as specified above (ie no DIFFSERV - RSVP Object in the PATH message containing the LABEL_REQUEST - Object), OR - - Le Faucheur et. al 52 - MPLS Support of Diff-Serv June 2000 - - * using the CR-LDP protocol as specified above (ie no Diff- - Serv TLV in LDP Label Request/Label Mapping messages). + * using the RSVP protocol as specified above (i.e. no + DIFFSERV RSVP Object in the PATH message containing the + LABEL_REQUEST Object), OR + * using the CR-LDP protocol as specified above (i.e. no + Diff-Serv TLV in LDP Label Request/Label Mapping messages). + - protection is activated on all the E-LSPs in order to achieve + MPLS protection via mechanisms outside the scope of this + document. -A.4 Scenario 4: per-OA Traffic Engineering/Fast Reroute +A.4 Scenario 4: per-OA Traffic Engineering/MPLS Protection 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. + per-OA Traffic Engineering (i.e. performing a separate path + selection for each OA) and performing per-OA MPLS protection (i.e. + performing protection with potentially different levels of + protection for the different OAs) in his/her network, may elect to + run Diff-Serv over MPLS using one L-LSP per pair + established via RSVP or CR-LDP. Operations can be summarized as follows: - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (eg bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) - LSRs signal establishment of one L-LSP per : * using the RSVP as specified above to signal the - L-LSP's PSC (ie DIFFSERV RSVP Object in the PATH message + L-LSP's PSC (i.e. DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR * using the CR-LDP protocol as specified above to - signal the L-LSP PSC (ie Diff-Serv TLV in LDP Label + signal the L-LSP PSC (i.e. Diff-Serv TLV in LDP Label Request/Label Mapping messages). + - the appropriate level of protection is activated on the + different L-LSPs (potentially with a different level of + protection for each PSC)_via mechanisms outside the scope of + this document. -A.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/Fast -Reroute + Le Faucheur et. al 46 + MPLS Support of Diff-Serv July 2000 + +A.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/MPLS +Protection A Service Provider running 8 (or fewer) 8 BAs over MPLS, performing - per-OA Traffic Engineering (ie performing a separate path selection - for each OA) and performing per-OA protection via Fast Reroute (ie - performing protection with different Fast Reroute policies for the - different OAs) in his/her network, may elect to run Diff-Serv over - MPLS using one E-LSP per pair established via RSVP or - CR-LDP. Furthermore, the Service Provider may elect to use the - preconfigured mapping on all the E-LSPs. + per-OA Traffic Engineering (i.e. performing a separate path + selection for each OA) and performing per-OA MPLS protection (i.e. + performing protection with potentially different levels of + protection for the different OAs) in his/her network, may elect to + run Diff-Serv over MPLS using one E-LSP per pair + established via RSVP or CR-LDP. Furthermore, the Service Provider + may elect to use the preconfigured mapping on all the E-LSPs. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field - (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) + (e.g. 000<-->AF11, 001<-->AF12, 010<-->AF13) - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (eg bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) - LSRs signal establishment of one E-LSP per : * using the RSVP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping - (ie no DIFFSERV RSVP Object in the PATH message containing the + (i.e. no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR - - Le Faucheur et. al 53 - MPLS Support of Diff-Serv June 2000 - * using the CR-LDP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured - mapping (ie no Diff-Serv TLV in LDP Label Request/Label Mapping - messages) + mapping (i.e. no Diff-Serv TLV in LDP Label Request/Label + Mapping messages) - the Service Provider configures, for each E-LSP, at the head-end of that E-LSP, a filtering/forwarding criteria so that only the packets belonging to a given OA are forwarded on the E-LSP established for the corresponding FEC and corresponding OA. + - the appropriate level of protection is activated on the + different E-LSPs (potentially with a different level of + protection depending on the PSC actually transported over each + E-LSP)_via mechanisms outside the scope of this document. -A.6 Scenario 6: no Traffic Engineering/Fast Reroute on 8 BAs, per-OA -Traffic Engineering/Fast Reroute on other BAs. +A.6 Scenario 6: no Traffic Engineering/MPLS Protection on 8 BAs, per-OA +Traffic Engineering/MPLS Protection on other BAs. + + A Service Provider not performing Traffic Engineering/MPLS + Protection on 8 (or fewer) BAs, performing per-OA Traffic + Engineering/MPLS Protection on the other BAs (i.e. performing a + separate path selection for each OA corresponding to the other BAs + and performing MPLS Protection with a potentially 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: + + Le Faucheur et. al 47 + MPLS Support of Diff-Serv July 2000 - A Service Provider not performing Traffic Engineering/Fast Reroute - on 8 (or fewer) BAs, performing per-OA Traffic Engineering/Fast - Reroute on the other BAs (ie performing a separate path selection - for each OA corresponding to the other BAs and performing protection - with a different policy for each of these OA) and using the MPLS - Shim encapsulation in his/her network may elect to run Diff-Serv - over MPLS, using for each FEC: - one E-LSP using the preconfigured mapping established via LDP to - support the set of 8 (or fewer) non-traffic-engineered/non-fast- - rerouted BAs, AND + support the set of 8 (or fewer) non-traffic-engineered/non- + protected BAs, AND - one L-LSP per pair established via RSVP or CR-LDP for support of the other BAs. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs supported over the E-LSP - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB - LSRs signal establishment of a single E-LSP per FEC for the non- - traffic engineered BAs using LDP as specified above (ie no Diff- - Serv TLV in LDP Label Request/Label Mapping messages) + traffic engineered BAs using LDP as specified above (i.e. no + Diff-Serv TLV in LDP Label Request/Label Mapping messages) - LSRs signal establishment of one L-LSP per for the other BAs: * using the RSVP protocol as specified above to signal - the L-LSP PSC (ie DIFFSERV RSVP Object in the PATH message + the L-LSP PSC (i.e. DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR * using the CR-LDP protocol as specified above to - signal the L-LSP PSC (ie Diff-Serv TLV in LDP Label + signal the L-LSP PSC (i.e. Diff-Serv TLV in LDP Label Request/Label Mapping messages). + - protection is not activated on the E-LSPs. + - the appropriate level of protection is activated on the + different L-LSPs (potentially with a different level of + protection depending on the L-LSP's PSC)_via mechanisms outside + the scope of this document. -A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no Fast -Reroute +A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no MPLS +Protection A Service Provider running more than 8 BAs over MPLS, not performing - Traffic engineering, not performing protection via Fast Reroute and - - Le Faucheur et. al 54 - MPLS Support of Diff-Serv June 2000 - - using MPLS Shim Header encapsulation in his/her network, may elect - to run Diff-Serv over MPLS using two E-LSPs per FEC established via - LDP and using signaled EXP<-->PHB mapping. + Traffic engineering, not performing MPLS protection and using MPLS + Shim Header encapsulation in his/her network, may elect to run Diff- + Serv over MPLS using two E-LSPs per FEC established via LDP and + using signaled EXP<-->PHB mapping. Operations can be summarized as follows: - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (eg bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) - LSRs signal establishment of two E-LSPs per FEC using LDP in - accordance with the specification above (ie Diff-Serv TLV in LDP - Label Request/Label Mapping messages to explicitly indicate that - the LSP is an E-LSP and its EXP<--> mapping). The signaled + accordance with the specification above (i.e. Diff-Serv TLV in + LDP Label Request/Label Mapping messages to explicitly indicate + that the LSP is an E-LSP and its EXP<--> mapping). The signaled mapping will indicate the subset of 8 (or less) BAs to be + + Le Faucheur et. al 48 + MPLS Support of Diff-Serv July 2000 + transported on each E-LSP and what EXP values are mapped to each BA on each E-LSP. APPENDIX B. Example Bandwidth Reservation Scenarios B.1 Scenario 1: No Bandwidth Reservation Consider the case where a network administrator elects to: - have Diff-Serv resources entirely provisioned off-line (e.g. via Command Line Interface, via SNMP, via COPS,...) @@ -2950,99 +2656,106 @@ In that case, L-LSPs would be established with signaled bandwidth. The bandwidth signaled at L-LSP establishment would be used by LSRs to perform admission control at every hop to ensure that the constraint on availability of bandwidth for the relevant PSC is met. B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and per-PSC Resource Adjustment Consider the case where a network administrator elects to: - use L-LSPs - - Le Faucheur et. al 55 - MPLS Support of Diff-Serv June 2000 - - have Constraint Based Routing performed separately for each PSC, where one of the constraints is availability of bandwidth from the bandwidth allocated to the relevant PSC. - have Diff-Serv resources dynamically adjusted In that case, L-LSPs would be established with signaled bandwidth. The bandwidth signaled at L-LSP establishment would be used by LSRs to attempt to adjust the resources allocated to the relevant PSC (e.g. scheduling weight) and then perform admission control to ensure that the constraint on availability of bandwidth for the relevant PSC is met after the adjustment. References + Le Faucheur et. al 49 + MPLS Support of Diff-Serv July 2000 + [MPLS_ARCH] Rosen et al., "Multiprotocol label switching - Architecture", work in progress, (draft-ietf-mpls-arch-06.txt), - August 1999. + Architecture", work in progress, draft-ietf-mpls-arch-06.txt, August + 1999. + + [MPLS_ENCAPS] Rosen et al., "MPLS Label Stack Encoding, work in + progress, draft-ietf-mpls-label-encaps-07.txt, September 1999. [MPLS_ATM] Davie et al., "MPLS using LDP and ATM VC Switching", work - in progress, (draft-ietf-mpls-atm-03.txt), May 2000 + in progress, draft-ietf-mpls-atm-04.txt, June 2000. [MPLS_FR] Conta et al., "Use of Label Switching on Frame Relay - Networks Specification", (draft-ietf-mpls-fr-04.txt), May 2000 + Networks Specification", work in progress, draft-ietf-mpls-fr- + 06.txt, June 2000. [DIFF_ARCH] Blake et al., "An architecture for Differentiated Services", RFC-2475, December 1998. [DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597, June 1999. [DIFF_EF] Jacobson et al., "An Expedited Forwarding PHB", RFC-2598, June 1999. [DIFF_HEADER] Nichols et al., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474, December 1998. [ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC-2481, January 1999. - [MPLS_ECN] Ramakrishnan et al., "A Proposal to Incorporate ECN in - MPLS", draft-ietf-mpls-ecn-00.txt, June 1999. - - [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- - 06.txt, October 99 + [LDP] Andersson et al., "LDP Specification", work in progress, + draft-ietf-mpls-ldp-08.txt, June 2000 [RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", - draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, February 2000 + work in progress, draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, February + 2000 [CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using - LDP", draft-ietf-mpls-cr-ldp-03.txt, October 1999 - - Le Faucheur et. al 56 - MPLS Support of Diff-Serv June 2000 + LDP", work in progress, draft-ietf-mpls-cr-ldp-03.txt, October 1999 [PHBID] Brim et al., "Per Hop Behavior Identification Codes" RFC 2836, May 2000 - [DIFF_NEW] Grossman, "New Terminology for Diffserv", draft-ietf- - diffserv-new-terms-02.txt, November 99 + [DIFF_NEW] Grossman, "New Terminology for Diffserv", work in + progress, draft-ietf-diffserv-new-terms-02.txt, November 1999 [IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision and redesignation of ISO/IEC 10038:98 [ANSI/IEEE Std 802.1D, 1993 Edition], incorporating IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and P802.12e) - [DIFF_TUNNEL] Black, "Differentiated Services and Tunnels", draft- - ietf-diffserv-tunnels-00-txt, February 2000. + Le Faucheur et. al 50 + MPLS Support of Diff-Serv July 2000 - [MPLS_VPN] Rosen et al., "BGP/MPLS VPNs", draft-rosen-rfc2547bis- - 00.txt, March 2000. + [DIFF_TUNNEL] Black, "Differentiated Services and Tunnels", work in + progress, draft-ietf-diffserv-tunnels-01-txt, June 2000. -Author's Addresses: + [MPLS_VPN] Rosen et al., "BGP/MPLS VPNs", work in progress, draft- + rosen-rfc2547bis-01.txt, May 2000. + + [RSVP] Braden et al., "Resource ReSerVation Protocol (RSVP) - + Version 1 Functional Specification", RFC-2205, September 1997. + + [IANA] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", RFC 2434, October 1998. + +Authors' Address: 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 @@ -3060,40 +2773,69 @@ Shahram Davari PMC-Sierra Inc. 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3 Canada Phone: +1 (613) 271-4018 Email: shahram_davari@pmc-sierra.com - Le Faucheur et. al 57 - MPLS Support of Diff-Serv June 2000 - Pasi Vaananen Nokia 3 Burlington Woods Drive, Suit 250 Burlington, MA 01803 USA Phone +1 (781) 238-4981 + + Le Faucheur et. al 51 + MPLS Support of Diff-Serv July 2000 + 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 Juha Heinanen Telia Finland E-mail: jh@lohi.eng.telia.fi - Le Faucheur et. al 58 +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + + Le Faucheur et. al 52