Francois Le Faucheur
`Liwen Wu
`Bruce Davie
`Cisco Systems
`
`Shahram Davari
`PMC-Sierra Inc.
`
`Pasi Vaananen
`Nokia
`
`Ram Krishnan
`Nexabit Networks
`
`Pierrick Cheval
`Alcatel
`
`Juha Heinanen
`Telia Finland
`
`IETF Internet Draft
`Expires: October, 2000
`Document: draft-ietf-mpls-diff-ext-03.txt
`
`February, 2000
`
`MPLS Support of Differentiated Services
`
`Status of this Memo
`
` This document is an Internet-Draft and is in full conformance with
` all provisions of Section 10 of RFC2026. Internet-Drafts are
` Working documents of the Internet Engineering Task Force (IETF), its
` areas, and its working groups. Note that other groups may also
` distribute working documents as Internet-Drafts.
`
` Internet-Drafts are draft documents valid for a maximum of six
` months and may be updated, replaced, or obsoleted by other documents
` at any time. It is inappropriate to use Internet- Drafts as
` reference material or to cite them other than as "work in progress."
`
`The list of current Internet-Drafts can be accessed at
`http://www.ietf.org/ietf/1id-abstracts.txt
`
`The list of Internet-Draft Shadow Directories can be accessed at
`http://www.ietf.org/shadow.html.
`
`Abstract
`
` This document defines a flexible solution for support of
` Differentiated Services (Diff-Serv) over Multi-Protocol Label
` Switching (MPLS) networks.
`
`Le Faucheur, et. al
`
`1
`
`MPLS Support of Diff-Serv
`
`February 00
`
` This solution allows the MPLS network administrator to select how
` Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched
`
`Cloudflare - Exhibit 1017, page 1
`
`

`

` Paths so that he/she can best match the Diff-Serv, Traffic
` Engineering and Fast Restoration objectives within his/her
` particular network. For instance, this solution allows the network
` administrator to decide whether different sets of BAs are to be
` mapped onto the same LSP or mapped onto separate LSPs.
`
` This solution relies on combined use of two types of LSPs:
`- LSPs which can transport multiple Ordered Aggregates, so that
`the EXP field of the MPLS Shim Header conveys to the LSR the PHB
`to be applied to the packet (covering both information about the
`packet’s scheduling treatment and its drop precedence).
`- LSPs which only transport a single Ordered Aggregate, so that
`the packet’s scheduling treatment is inferred by the LSR
`exclusively from the packet’s label value while the packet’s
`drop precedence is conveyed in the EXP field of the MPLS Shim
`Header or in the encapsulating link layer specific selective
`drop mechanism (ATM, Frame Relay, 802.1).
`
`1. Introduction
`
` In an MPLS domain [MPLS_ARCH], when a stream of data traverses a
` common path, a Label Switched Path (LSP) can be established using
` MPLS signaling protocols. At the ingress Label Switch Router (LSR),
` each packet is assigned a label and is transmitted downstream. At
` each LSR along the LSP, the label is used to forward the packet to
` the next hop.
`
` In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the
` IP packets crossing a link and requiring the same Diff-Serv behavior
` are said to constitute a Behavior Aggregate (BA). At the ingress
` node of the Diff-Serv domain the packets are classified and marked
` with a Diff-Serv Code Point (DSCP) which corresponds to their
` Behavior Aggregate. At each transit node, the DSCP is used to select
` the Per Hop Behavior (PHB) that determines the scheduling treatment
` and, in some cases, drop probability for each packet.
`
` This document specifies a solution for supporting the Diff-Serv
` Behavior Aggregates whose corresponding PHBs are currently defined
` (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. This
` solution also offers flexibility for easy support of PHBs that may
` be defined in the future.
`
` As mentioned in [DIFF_HEADER], "Service providers are not required
` to use the same node mechanisms or configurations to enable service
` differentiation within their networks, and are free to configure the
` node parameters in whatever way that is appropriate for their
` service offerings and traffic engineering objectives". Thus, the
` solution defined in this document gives Service Providers
` flexibility in selecting how Diff-Serv classes of service are Routed
`
` Le Faucheur et. al
`
`2
`
`MPLS Support of Diff-Serv
`
`February 00
`
` or Traffic Engineered within their domain (eg. separate classes of
` services supported via separate LSPs and Routed separately, all
` classes of service supported on the same LSP and Routed together).
` Similarly, the solution gives Service Providers flexibility in how
` Diff-Serv classes of service can be protected via MPLS Fast
`
`Cloudflare - Exhibit 1017, page 2
`
`

`

` Restoration (eg. some classes of service supported via LSPs which
` are protected via MPLS Fast Restoration while some other classes of
` service are supported via LSPs which are not protected).
`
` Beside, the solution specified in this document achieves label space
` conservation and reduces the volume of label set-up/tear-down
` signaling where possible by only resorting to multiple LSPs for a
` given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or
` required.
`
` This specification allows support of Differentiated Services for
` both IPv4 and IPv6 traffic transported over an MPLS network.
`
` This document only describes operations for unicast. Multicast
` support is for future study
`
`1.1 Ordered Aggregate (OA) and PHB Scheduling Class (PSC)
`
` The Diff-Serv model defines [DIFF_NEW] the set of Behavior
` Aggregates which share an ordering constraint to constitute an
` "Ordered Aggregate (OA)". It also defines the set of one or more
` PHBs that are applied to this set of Behavior Aggregates to
` constitute a "PHB Scheduling Class (PSC)".
`
`1.2 EXP-Inferred-PSC LSPs (E-LSP)
`
` A single LSP can be used to support up to eight BAs of a given FEC,
` regardless of how many OAs these BAs span. With such LSPs, the EXP
` field of the MPLS Shim Header [MPLS_ENCAPS] is used by the LSR to
` determine the PHB to be applied to the packet. This includes both
` the PSC and the drop preference.
`
` We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the
` PSC of a packet transported on this LSP depends on the EXP field
` value for that packet.
`
` The mapping from EXP field to PHB (ie to PSC and drop precedence)
` for a given such LSP, is either explicitly signaled at label set-up
` or relying on a pre-configured mapping.
`
` Detailed operations of E-LSPs are specified in section 3 below.
`
`1.3 Label-Only-Inferred-PSC LSPs (L-LSP)
`
` A separate LSP can be established for a single <FEC, OA> pair.
`
` Le Faucheur et. al 3
`
` MPLS Support of Diff-Serv February 00
`
` With such LSPs, the PSC is explicitly signaled at label
` establishment time so that, after label establishment, the LSR can
` infer exclusively from the label value the PSC to be applied to a
` labeled packet. When the Shim Header is used, the Drop Precedence to
` be applied by the LSR to the labeled packet, is conveyed inside the
` labeled packet MPLS Shim Header using the EXP field [MPLS_ENCAPS].
` When the Shim Header is not used (eg. MPLS Over ATM), the Drop
` Precedence to be applied by the LSR to the labeled packet is
`
`Cloudflare - Exhibit 1017, page 3
`
`

`

` conveyed inside the link layer header encapsulation using link layer
` specific drop precedence fields (eg. ATM Cell Loss Priority).
`
` We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP)
` since the PSC can be fully inferred from the label without any other
` information (eg. regardless of the EXP field value). Detailed
` operations of L-LSPs are specified in section 4 below.
`
`1.4 Overall Operations
`
` For a given FEC, and unless media specific restrictions apply as
` identified in the sections 7, 8, 9 and 10 below, this specification
` allows any one of the following combinations within an MPLS Diff-
` Serv domain:
` - zero or any number of E-LSPs, and
` - zero or any number of L-LSPs.
`
` The network administrator selects the actual combination of LSPs
` from the set of allowed combinations and selects how the Behavior
` Aggregates are actually transported over this combination of LSPs,
` in order to best match his/her environment and objectives in terms
` of Diff-Serv support, Traffic Engineering and Fast Restoration.
` Criteria for selecting such a combination are outside the scope of
` this specification; However in order to respect ordering
` constraints, all packets of a given microflow, possibly spanning
` multiple BAs of a given Ordered Aggregate, MUST be transported over
` the same LSP. Conversely, each LSP MUST be capable of supporting all
` the (active) PHBs of a given PSC.
`
` Examples of deployment scenarios are provided for information in
` APPENPIX A.
`
`1.5 Relationship between Label and FEC
`
` [MPLS_ARCH] states in section ‘2.1. Overview’ that:
` ‘Some routers analyze a packet’s network layer header not merely to
` choose the packet’s next hop, but also to determine a packet’s
` "precedence" or "class of service". They may then apply different
` discard thresholds or scheduling disciplines to different packets.
` MPLS allows (but does not require) the precedence or class of
` service to be fully or partially inferred from the label. In this
` case, one may say that the label represents the combination of a FEC
` and a precedence or class of service.’
`
` Le Faucheur et. al 4
`
` MPLS Support of Diff-Serv February 00
`
` In line with this, we observe that:
` - With E-LSPs, the label represents the combination of a FEC and
` the set of Behavior Aggregates (BAs) transported over the E-
` LSP). Where all the supported BAs are transported over an E-LSP,
` the label then represents the complete FEC.
` - With L-LSPs, the label represents the combination of a FEC and
` an Ordered Aggregate (OA).
`
`2. Label Forwarding Model for Diff-Serv LSRs
`
`Cloudflare - Exhibit 1017, page 4
`
`

`

` Since different Ordered Aggregates of a given FEC may be transported
` over different LSPs, the label swapping decision of a Diff-Serv LSR
` clearly depends on the forwarded packet’s Behavior Aggregate. Also,
` since the IP DS field of a forwarded packet may not be directly
` visible to an LSR, the way to determine the PHB to be applied to a
` received packet and to encode the PHB into a transmitted packet is
` different to a non-MPLS Diff-Serv Router.
`
` In order to describe Label Forwarding by Diff-Serv LSRs, we model
` the LSR Diff-Serv label switching behavior as comprising four
` stages:
` - Incoming PHB Determination (A)
` - Optional Outgoing PHB Determination via Local Policy and Traffic
` Conditioning (B)
` - Label Swapping (C)
` - Encoding of Diff-Serv information into Encapsulation Layer
` (EXP,CLP,DE,User_Priority) (D)
`
` Obviously, to enforce the Diff-Serv service differentiation the LSR
` MUST also apply the forwarding treatment corresponding to the
` Outgoing PHB.
`
` This model is illustrated below:
`
` --Inc_label(*)--------------------------->I===I---Outg_label (**)-->
` \ I I \
` \---->I===I I C I \-->I===I--Encaps->
` I A I I===I--Outg_PHB->I===I I D I (**)
` -Encaps->I===I--Inc_PHB->I B I \ /->I===I
` (*) I===I \--------/
`
` ‘Encaps’ designates the Diff-Serv related information encoded in the
` MPLS Encapsulation layer (eg EXP field, ATM CLP, Frame Relay DE,
` 802.1 User_Priority)
`
` (*) when the LSR performs label imposition, the incoming packet is
` received unlabelled.
`
` Le Faucheur et. al 5
`
` MPLS Support of Diff-Serv February 00
`
` (**) when the LSR performs label disposition, the outgoing packet is
` transmitted unlabelled.
`
` This model is presented here to illustrate operations of Diff-Serv
` LSRs and does not constrain actual implementation.
`
`2.1 Incoming PHB Determination
`
` This stage determines which Behavior Aggregate the received packet
` belongs to.
`
` 2.1.1 Incoming PHB Determination for received labelled packets
`
` This specification defines one default method for this determination
`
`Cloudflare - Exhibit 1017, page 5
`
`

`

` which allows for regular support of Diff-Serv over MPLS. This method
` considers only the outer encapsulation (ie outer label entry or ATM
` encapsulation or Frame Relay encapsulation) and ignores other label
` entries which may be present in the stack. It combines:
` - the Diff-Serv context associated with the incoming label and
` stored in the Incoming Label Map (ILM). See section 2.3 below
` for details on information comprising the Diff-Serv context.
` - the Diff-Serv related information that is encoded in the
` corresponding encapsulation layer (ie in EXP field of MPLS Shim
` layer or in CLP/DE field of the link layer encapsulation) of the
` received label packet.
`
` The details of this method depend on the incoming LSP type and on
` the incoming MPLS encapsulation and are defined below in sections
` 3.3 and 4.3.
`
` Support for this default method is mandatory for compliance to this
` specification.
`
` Optionally, other methods for Incoming PHB Determination may also be
` supported. Other methods may take into account other information in
` addition to, or instead of, the information used by the mandatory
` method. For instance, other method could take into account the DS
` field of the encapsulated packet or the EXP field of a label header
` deeper in the label stack. Such methods are beyond the scope of this
` specification.
`
`2.1.2 Incoming PHB Determination for received unlabelled packets
`
` For packets received unlabelled, this stage operates exactly as with
` a non-MPLS IP Diff-Serv Router and uses the DS field.
`
`2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
`Conditioning
`
` This stage of Diff-Serv label switching is optional and may be used
` on an LSR to perform traffic conditioning including Behavior
` Aggregate demotion or promotion. It is outside the scope of this
`
` Le Faucheur et. al 6
`
` MPLS Support of Diff-Serv February 00
`
` specification. For the purpose of specifying Diff-Serv over MPLS
` forwarding, we simply note that the PHB to be actually enforced, and
` conveyed to downstream LSRs, by an LSR (referred to as "outgoing
` PHB") may be different to the PHB which had been associated with the
` packet by the previous LSR (referred to as "incoming PHB").
`
` When this stage is not present, the "outgoing PHB" is simply
` identical to the "incoming PHB".
`
` For packets received unlabelled, this stage operates as with a non-
` MPLS IP Diff-Serv Router.
`
`2.3 Label Swapping
`
` [MPLS_ARCH] describes how label swapping is performed by LSRs on
` incoming labeled packets using an Incoming Label Map (ILM), where
` each incoming label is mapped to one or multiple NHLFEs. [MPLS_ARCH]
`
`Cloudflare - Exhibit 1017, page 6
`
`

`

` also describes how label imposition is performed by LSRs on incoming
` unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each
` incoming FEC is mapped to one or multiple NHLFEs.
`
` A Diff-Serv Context for a label is defined as comprising:
` - ‘LSP type (ie E-LSP or L-LSP)’
` - ‘supported PHBs’
` - ‘Encaps-->PHB mapping’ for an incoming label
` - ‘Set of PHB-->Encaps mappings’ for an outgoing label
`
` The present specification defines that a Diff-Serv Context is stored
` in the ILM for each incoming label.
`
` [MPLS_ARCH] states that the ‘NHLFE may also contain any other
` information needed in order to properly dispose of the packet’. In
` accordance with this, the present specification defines that a Diff-
` Serv context is stored in the NHLFE for each outgoing label which is
` swapped or pushed.
`
` This Diff-Serv context information is populated into the ILM and the
` FTN at label establishment time.
`
` If the label corresponds to an E-LSP for which no EXP<-->PHB mapping
` has been explicitly signaled at LSP setup, the ‘supported PHBs’ is
` populated with the set of PHBs of the preconfigured
` EXP<-->PHB Mapping, which is discussed below in section 3.2.1.
`
` If the label corresponds to an E-LSP for which an EXP<-->PHB mapping
` has been explicitly signaled at LSP setup, the ‘supported PHBs’ is
` populated with the set of PHBs of the signaled EXP<-->PHB mapping.
`
` If the label corresponds to an L-LSP, the ‘supported PHBs’ is
` populated with the set of PHBs forming the PSC that is signaled at
` LSP set-up.
`
` Le Faucheur et. al 7
`
` MPLS Support of Diff-Serv February 00
`
` The details of how the ‘Encaps-->PHB mapping’ or ‘Set of
` PHB-->Encaps mappings’ are populated are defined below in sections 3
` and 4.
`
` [MPLS_ARCH] also states that:
` "If the ILM [respectively, FTN] maps a particular label to a set of
` NHLFEs that contains more than one element, exactly one element of
` the set must be chosen before the packet is forwarded. The
` procedures for choosing an element from the set are beyond the scope
` of this document. Having the ILM [respectively, FTN] map a label
` [respectively, a FEC] to a set containing more than one NHLFE may be
` useful if, e.g., it is desired to do load balancing over multiple
` equal-cost paths."
` In accordance with this, the present specification allows that an
` incoming label [respectively FEC] is mapped, for Diff-Serv purposes,
` to multiple NHLFEs (for instance where different NHLFEs correspond
` to egress labels supporting different sets of PHBs). When a label
` [respectively FEC] maps to multiple NHLFEs, the Diff-Serv LSR MUST
` choose one of the NHLFEs whose Diff-Serv context indicates that it
` supports the Outgoing PHB of the forwarded packet.
`
`Cloudflare - Exhibit 1017, page 7
`
`

`

` When a label [respectively FEC] maps to multiple NHLFEs which
` supports the Outgoing PHB, the procedure for choosing one among
` those is outside the scope of this document. This situation may be
` encountered where it is desired to do load balancing of a Behavior
` Aggregate over multiple LSPs. In such situations, in order to
` respect ordering constraints, all packets of a given microflow MUST
` be transported over the same LSP.
`
`2.4 Encoding Diff-Serv information into Encapsulation Layer
`
` This stage determines how to encode the fields of the MPLS
` encapsulation layer which convey Diff-Serv information (eg MPLS Shim
` EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority).
`
`2.4.1 Encoding Diff-Serv information for transmitted labeled packets
`
` This specification defines one default method for this encoding
` which allows regular support of Diff-Serv over MPLS. This method
` takes into account:
` - the Outgoing PHB
` - the Diff-Serv context associated with each swapped/pushed label
` of the selected NHLFE (‘Set of PHB-->Encaps mappings’).
`
` This method defines that the Outgoing PHB is reflected into:
` - the EXP field value of all the swapped or pushed label entries
` - the CLP/DE bit when the packet is encapsulated into ATM/Frame
` Relay,
` - the 802.1 User_Priority field of the 802.1 Tag Control
` Information when the packet is encapsulated into LAN interfaces
` supporting multiple Traffic Classes,
`
` Le Faucheur et. al 8
`
` MPLS Support of Diff-Serv February 00
`
` The details of this method depend on the outgoing LSP type and on
` the outgoing MPLS encapsulation and are defined below in sections
` 3.5 and 4.5.
`
` Support for this default method is mandatory for compliance to this
` specification.
`
` Optionally, other methods for encoding Diff-Serv information into
` the Encapsulation layer may also be supported to allow for more
` sophisticated Diff-Serv operations over MPLS. Other methods may
` affect encapsulation fields differently.
`
`2.4.2 Encoding Diff-Serv information for transmitted unlabelled packets
`
` This specification defines one default method for this encoding
` which allows regular support of Diff-Serv over MPLS.
`
` Support for this default method is mandatory for compliance to this
` specification.
`
` For packets transmitted unlabelled (ie LSR performing label
` disposition), the default encoding method writes the DSCP of the
` Outgoing PHB into the DS field.
`
`Cloudflare - Exhibit 1017, page 8
`
`

`

` Optionally, other encoding methods may also be supported to allow
` for more sophisticated Diff-Serv operations over MPLS. Other methods
` may affect the DS field differently. One example would be a method
` where the IP packet’s DS field is left unchanged regardless of the
` Outgoing PHB. Such a method would allow ‘MPLS Diff-Serv
` Transparency’ ie it would allow support of Differentiated Services
` in the MPLS backbone based on a Diff-Serv policy which is specific
` to the MPLS cloud (and different from the Diff-Serv policy applied
` in the non-MPLS clouds around the MPLS cloud) since the IP DS field
` would be transported transparently through the MPLS cloud. Details
` of such methods are outside the scope of this specification.
`
`3. Detailed Operations of E-LSPs
`
`3.1 E-LSP Definition
`
` Recognizing that:
`
` - Certain MPLS encapsulations (such as PPP and LAN) make use of a
` Shim Header which consists of a label stack with one or more
` entries [MPLS_ENCAPS] each with a 3-bit EXP field;
`
` - the Differentiated-Service (DS) field is 6-bit long
` [DIFF_HEADER] potentially allowing support of up to 64 Behavior
` Aggregates
`
` Le Faucheur et. al 9
`
` MPLS Support of Diff-Serv February 00
`
` - any subset of 8 (or less) DSCP values can be mapped entirely
` into the 3-bit long EXP field of the MPLS label stack entry;
`
` We define that:
`
` - an LSP established for a given Forwarding Equivalent Class (FEC)
` may be used for transport of up to eight BAs of that FEC;
`
` - the set of transported BAs can span multiple OAs;
`
` - for a given OA transported over the LSP, all supported BAs of
` this OA are transported over the LSP;
`
` - such an LSP is referred to as an "EXP-inferred-PSC" LSP or
` "E-LSP" because the PSC to be applied to a labeled packet by the
` LSR depends on the EXP field value in the MPLS Shim Header;
`
` - packets belonging to this given (FEC) and from the corresponding
` set of BAs are sent down this E-LSP.
`
` - multiple BAs belonging to the same FEC and transported over the
` same E-LSP are granted different scheduling treatment and
` different drop precedence by the MPLS LSR based on the EXP field
` which is appropriately encoded to reflect both the PSC and the
` drop precedence of the PHB corresponding to the packet’s BA.
`
`Cloudflare - Exhibit 1017, page 9
`
`

`

` - the mapping between EXP field and PHB to be applied by the LSR
` for a given E-LSP is either explicitly signaled at label set-up
` or relies on a preconfigured mapping.
`
` Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the
` pre-configured mapping are capable of transporting the same common
` set of 8, or less, BAs. Each of those E-LSPs may actually transport
` this full set of BAs or any arbitrary subset of it.
`
` For a given FEC, two given E-LSPs using signaled EXP<-->PHB mapping
` can support the same or different sets of Ordered Aggregates.
`
` For a given FEC, there may be more than one E-LSP carrying the same
` OA, for example for purposes of load balancing of the OA. In that
` case, in order to respect ordering constraints, all packets of a
` given microflow must be transported over the same LSP.
`
` MPLS specifies how LSPs can be established via multiple signaling
` protocols. Those include the Label Distribution Protocol (LDP),
` RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP
` are to be used for establishment of E-LSPs.
`
`3.2 Populating the ‘Encaps-->PHB mapping’ for an incoming E-LSP
`
` Le Faucheur et. al 10
`
` MPLS Support of Diff-Serv February 00
`
` This section defines how the ‘Encaps-->PHB mapping’ of the Diff-Serv
` context is populated for an incoming E-LSP in order to support the
` mandatory default method for Incoming PHB determination.
`
` The ‘Encaps-->PHB mapping’ is always of the form ‘EXP-->PHB
` mapping’.
`
` If the label corresponds to an E-LSP for which no EXP<-->PHB mapping
` has been explicitly signaled at LSP setup, the ‘EXP-->PHB mapping’
` is populated based on the Preconfigured EXP<-->PHB Mapping which is
` discussed below in section 3.2.1.
`
` If the label corresponds to an E-LSP for which an EXP<-->PHB mapping
` has been explicitly signaled at LSP setup, the ‘EXP-->PHB mapping’
` is populated as per the signaled EXP<-->PHB mapping.
`
`3.2.1 Preconfigured EXP<-->PHB mapping
`
` LSRs supporting E-LSPs which uses the preconfigured EXP<-->PHB
` mapping must allow local configuration of this EXP<-->PHB mapping.
` This mapping applies to all the E-LSPs established on this LSR
` without a mapping explicitly signaled at set-up time.
`
` The preconfigured EXP<-->PHB mapping must either be consistent at
` every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the
` LSP or appropriate remarking of the EXP field must be performed by
` the LSR whenever a different preconfigured mapping is used on the
` ingress and egress interfaces.
`
`Cloudflare - Exhibit 1017, page 10
`
`

`

`3.3 Incoming PHB Determination On Incoming E-LSP
`
` This section defines the mandatory default method for Incoming PHB
` determination for a labeled packet received on an E-LSP. This method
` requires that the ‘Encaps-->PHB mapping’ is populated as defined
` above in section 3.2.
`
` When receiving a labeled packet over an E-LSP of an MPLS ingress
` interface, the LSR:
`
` -determines the EXP-->PHB mapping by looking up the
` ‘Encaps-->PHB mapping’ of the Diff-Serv context associated with
` the incoming label in the ILM.
` - determines the incoming PHB by looking up the EXP field of the
` top level label entry into the EXP-->PHB mapping table.
`
` If the EXP field value of a packet received on an E-LSP is not
` included in the EXP-->PHB mapping associated with this LSP, this EXP
` value should be considered invalid. LSR behavior in such situation
` is a local matter and is outside the scope of this document.
`
`3.4 Populating the ‘Set of PHB-->Encaps mappings’ for an outgoing E-LSP
`
` Le Faucheur et. al 11
`
` MPLS Support of Diff-Serv February 00
`
` This section defines how the ‘Set of PHB-->Encaps mappings’ of the
` Diff-Serv context is populated for an outgoing E-LSP in order to
` support the mandatory default method for Encoding of Diff-Serv
` information in the Encapsulation Layer.
`
`3.4.1 ‘PHB-->EXP mapping’
`
` One ‘PHB-->EXP mapping’ is always added to the ‘Set of PHB-->Encaps
` mappings’ of the Diff-Serv context for an outgoing E-LSP.
`
` If the label corresponds to an E-LSP for which no EXP<-->PHB mapping
` has been explicitly signaled at LSP setup, this ‘PHB-->EXP mapping’
` is populated based on the Preconfigured EXP<-->PHB Mapping which is
` discussed above in section 3.2.1.
`
` If the label corresponds to an E-LSP for which an EXP<-->PHB mapping
` has been explicitly signaled at LSP setup, the ‘PHB-->EXP mapping’
` is populated as per the signaled EXP<-->PHB mapping.
`
`3.4.2 ‘PHB-->802.1 mapping’
`
` If the outgoing interface is a LAN interface on which multiple 802.1
` Traffic Classes are supported as per [IEEE_802.1], one ‘PHB-->802.1
` mapping’ is added to the ‘Set of PHB-->Encaps mappings’ of the Diff-
` Serv context for the outgoing E-LSP. This mapping is populated at
` label set-up based on the Preconfigured PHB-->802.1 mapping defined
` below in section 3.4.2.1.
`
` Notice that the ‘Set of PHB-->Encaps mappings’ then contains both a
` ‘PHB-->EXP mapping’ and a ‘PHB-->802.1 mapping’.
`
`3.4.2.1 Preconfigured ‘PHB-->802.1 Mapping’
`
`Cloudflare - Exhibit 1017, page 11
`
`

`

` At the time of producing this specification, there are no
` standardized mapping from PHBs to 802.1 Traffic Classes.
`
` Consequently, an LSR supporting multiple 802.1 Traffic Classes over
` LAN interfaces must allow local configuration of a ‘PHB-->802.1
` Mapping’. This mapping applies to all the outgoing LSPs established
` by the LSR on such LAN interfaces.
`
`3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing
`E-LSP
`
` This section defines the mandatory default method for encoding of
` Diff-Serv related information into the MPLS encapsulation Layer to
` be used when a packet is transmitted onto an E-LSP. This method
` requires that the ‘Set of PHB-->Encaps mappings’ is populated as
` defined above in section 3.4.
`
` The LSR first determines the ‘Set of PHB-->Encaps Mapping’
` associated with the outer label of the NHLFE.
`
` Le Faucheur et. al 12
`
` MPLS Support of Diff-Serv February 00
`
`3.5.1 ‘PHB-->EXP mapping’
`
` For all the labels which are swapped or pushed, the LSR:
` - determines the PHB-->EXP mapping by looking up the
` ‘Set of PHB-->Encaps mapping’ of the Diff-Serv context
` associated with the corresponding label in the NHLFE.
` - determines the value to be written in the EXP field of the
` corresponding level label entry by looking up the "outgoing PHB"
` in this PHB-->EXP mapping table.
`
`3.5.2 ‘PHB-->802.1 mapping’
`
` If the ‘Set of PHB-->Encaps mapping’ of the outer label contains a
` mapping of the form ‘PHB-->802.1 mapping’, then the LSR:
` - determines the value to be written in the User_Priority field of
` the Tag Control Information of the 802.1 encapsulation header
` [IEEE_802.1], by looking up the "outgoing PHB" in this PHB-->802.1
` mapping table.
`
`3.6 E-LSP Merging
`
` In an MPLS domain, two or more LSPs can be merged into one LSP at
` one LSR. E-LSPs are compatible with LSP Merging under the following
` condition:
`
` E-LSPs can only be merged into one LSP if they support the
` exact same set of BAs.
`
` For E-LSPs using signaled EXP<-->PHB mapping, the above merge
` condition MUST be enforced by LSRs through explicit checking at
` label setup that the exact same set of PHBs is supported on the
` merged LSPs.
`
` For E-LSPs using the preconfigured EXP<-->PHB mapping, since the
`
`Cloudflare - Exhibit 1017, page 12
`
`

`

` PHBs supported over an E-LSP is not signaled at establishment time,
` an LSR can not rely on signaling information to enforce the above
` merge. However all E-LSPs using the preconfigured EXP<-->PHB mapping
` are required to support the same set of Behavior Aggregates within a
` given MPLS Diff-Serv domain. Thus, merging of E-LSPs using the
` preconfigured EXP<-->PHB mapping is allowed within a given MPLS
` Diff-Serv domain.
`
`4. Detailed Operation of L-LSPs
`
`4.1 L-LSP Definition
`
` Recognizing that:
`
` - All currently defined MPLS encapsulation methods have a field of
` 3 bits or less for Diff-Serv encoding (i.e., 3-bit EXP field in
`
` Le Faucheur et. al 13
`
` MPLS Support of Diff-Serv February 00
`
` case of Shim Header and 1-bit CLP/DE bit in case of ATM/Frame
` Relay).
`
` - The Differentiated-Services (DS) field is 6-bit long
` [DIFF_HEADER] potentially allowing support of up to 64 Behavior
` Aggregates. So that when more than a certain number of BAs are
` used (i.e., more than 8 BAs in case of Shim Header and more than
` 2 BAs in case of ATM/Frame Relay), the DS field can not be
` mapped entirely into the appropriate field of MPLS encapsulation
` header (i.e., EXP field in case of Shim Header and CLP/DE field
` in case of ATM/Frame Relay);
`
` We define that:
`
` - an LSP established for a given Forwarding Equivalent Class (FEC)
` may be