idnits 2.17.1 draft-ietf-mpls-diff-ext-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 189: '...dered Aggregate, MUST be transported o...' RFC 2119 keyword, line 190: '...ersely, each LSP MUST be capable of su...' RFC 2119 keyword, line 239: '...arding treatment MUST be applied by th...' RFC 2119 keyword, line 240: '...ty of the BA and MUST be compliant wit...' RFC 2119 keyword, line 287: '... MUST also apply the forwarding trea...' (34 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1242 has weird spacing: '... on the appro...' == Line 1569 has weird spacing: '...mapping of th...' == Line 1577 has weird spacing: '...mapping of th...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RSVP' is mentioned on line 1863, but not defined ** Obsolete normative reference: RFC 2481 (ref. 'ECN') (Obsoleted by RFC 3168) == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-06 ** Obsolete normative reference: RFC 2836 (ref. 'PHBID') (Obsoleted by RFC 3140) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Francois Le Faucheur 2 Liwen Wu 3 Bruce Davie 4 Cisco Systems 6 Shahram Davari 7 PMC-Sierra Inc. 9 Pasi Vaananen 10 Nokia 12 Ram Krishnan 13 Nexabit Networks 15 Pierrick Cheval 16 Alcatel 18 Juha Heinanen 19 Telia Finland 21 IETF Internet Draft 22 Expires: December, 2000 23 Document: draft-ietf-mpls-diff-ext-05.txt June, 2000 25 MPLS Support of Differentiated Services 27 Status of this Memo 29 This document is an Internet-Draft and is in full conformance with 30 all provisions of Section 10 of RFC2026. Internet-Drafts are 31 Working documents of the Internet Engineering Task Force (IETF), its 32 areas, and its working groups. Note that other groups may also 33 distribute working documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Abstract 47 This document defines a flexible solution for support of 48 Differentiated Services (Diff-Serv) over Multi-Protocol Label 49 Switching (MPLS) networks. 51 Le Faucheur, et. al 1 52 This solution allows the MPLS network administrator to select how 53 Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched 54 Paths so that he/she can best match the Diff-Serv, Traffic 55 Engineering and Fast Restoration objectives within his/her 56 particular network. For instance, this solution allows the network 57 administrator to decide whether different sets of BAs are to be 58 mapped onto the same LSP or mapped onto separate LSPs. 60 This solution relies on combined use of two types of LSPs: 61 - LSPs which can transport multiple Ordered Aggregates, so that 62 the EXP field of the MPLS Shim Header conveys to the LSR the PHB 63 to be applied to the packet (covering both information about the 64 packet's scheduling treatment and its drop precedence). 65 - LSPs which only transport a single Ordered Aggregate, so that 66 the packet's scheduling treatment is inferred by the LSR 67 exclusively from the packet's label value while the packet's 68 drop precedence is conveyed in the EXP field of the MPLS Shim 69 Header or in the encapsulating link layer specific selective 70 drop mechanism (ATM, Frame Relay, 802.1). 72 1. Introduction 74 In an MPLS domain [MPLS_ARCH], when a stream of data traverses a 75 common path, a Label Switched Path (LSP) can be established using 76 MPLS signaling protocols. At the ingress Label Switch Router (LSR), 77 each packet is assigned a label and is transmitted downstream. At 78 each LSR along the LSP, the label is used to forward the packet to 79 the next hop. 81 In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the 82 IP packets crossing a link and requiring the same Diff-Serv behavior 83 are said to constitute a Behavior Aggregate (BA). At the ingress 84 node of the Diff-Serv domain the packets are classified and marked 85 with a Diff-Serv Code Point (DSCP) which corresponds to their 86 Behavior Aggregate. At each transit node, the DSCP is used to select 87 the Per Hop Behavior (PHB) that determines the scheduling treatment 88 and, in some cases, drop probability for each packet. 90 This document specifies a solution for supporting the Diff-Serv 91 Behavior Aggregates whose corresponding PHBs are currently defined 92 (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. This 93 solution also offers flexibility for easy support of PHBs that may 94 be defined in the future. 96 As mentioned in [DIFF_HEADER], "Service providers are not required 97 to use the same node mechanisms or configurations to enable service 98 differentiation within their networks, and are free to configure the 99 node parameters in whatever way that is appropriate for their 100 service offerings and traffic engineering objectives". Thus, the 101 solution defined in this document gives Service Providers 102 flexibility in selecting how Diff-Serv classes of service are Routed 104 Le Faucheur et. al 2 105 or Traffic Engineered within their domain (eg. separate classes of 106 services supported via separate LSPs and Routed separately, all 107 classes of service supported on the same LSP and Routed together). 108 Similarly, the solution gives Service Providers flexibility in how 109 Diff-Serv classes of service can be protected via MPLS Fast 110 Restoration (eg. some classes of service supported via LSPs which 111 are protected via MPLS Fast Restoration while some other classes of 112 service are supported via LSPs which are not protected). 114 Furthermore, the solution specified in this document achieves label 115 space conservation and reduces the volume of label set-up/tear-down 116 signaling where possible by only resorting to multiple LSPs for a 117 given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or 118 required. 120 This specification allows support of Differentiated Services for 121 both IPv4 and IPv6 traffic transported over an MPLS network. 122 This document only describes operations for unicast. Multicast 123 support is for future study. 125 1.1 Ordered Aggregate (OA) and PHB Scheduling Class (PSC) 127 The Diff-Serv model defines [DIFF_NEW] the set of Behavior 128 Aggregates which share an ordering constraint to constitute an 129 "Ordered Aggregate (OA)". It also defines the set of one or more 130 PHBs that are applied to this set of Behavior Aggregates to 131 constitute a "PHB Scheduling Class (PSC)". 133 1.2 EXP-Inferred-PSC LSPs (E-LSP) 135 A single LSP can be used to support up to eight BAs of a given FEC, 136 regardless of how many OAs these BAs span. With such LSPs, the EXP 137 field of the MPLS Shim Header [MPLS_ENCAPS] is used by the LSR to 138 determine the PHB to be applied to the packet. This includes both 139 the PSC and the drop preference. 141 We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the 142 PSC of a packet transported on this LSP depends on the EXP field 143 value for that packet. 145 The mapping from EXP field to PHB (ie to PSC and drop precedence) 146 for a given such LSP, is either explicitly signaled at label set-up 147 or relies on a pre-configured mapping. 149 Detailed operations of E-LSPs are specified in section 3 below. 151 1.3 Label-Only-Inferred-PSC LSPs (L-LSP) 153 A separate LSP can be established for a single pair. 154 With such LSPs, the PSC is explicitly signaled at label 155 establishment time so that, after label establishment, the LSR can 156 infer exclusively from the label value the PSC to be applied to a 158 Le Faucheur et. al 3 159 labeled packet. When the Shim Header is used, the Drop Precedence to 160 be applied by the LSR to the labeled packet, is conveyed inside the 161 labeled packet MPLS Shim Header using the EXP field [MPLS_ENCAPS]. 162 When the Shim Header is not used (eg. MPLS Over ATM), the Drop 163 Precedence to be applied by the LSR to the labeled packet is 164 conveyed inside the link layer header encapsulation using link layer 165 specific drop precedence fields (eg. ATM Cell Loss Priority). 167 We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP) 168 since the PSC can be fully inferred from the label without any other 169 information (eg. regardless of the EXP field value). Detailed 170 operations of L-LSPs are specified in section 4 below. 172 1.4 Overall Operations 174 For a given FEC, and unless media specific restrictions apply as 175 identified in the sections 7, 8, 9 and 10 below, this specification 176 allows any one of the following combinations within an MPLS Diff- 177 Serv domain: 178 - zero or any number of E-LSPs, and 179 - zero or any number of L-LSPs. 181 The network administrator selects the actual combination of LSPs 182 from the set of allowed combinations and selects how the Behavior 183 Aggregates are actually transported over this combination of LSPs, 184 in order to best match his/her environment and objectives in terms 185 of Diff-Serv support, Traffic Engineering and Fast Restoration. 186 Criteria for selecting such a combination are outside the scope of 187 this specification; However in order to respect ordering 188 constraints, all packets of a given microflow, possibly spanning 189 multiple BAs of a given Ordered Aggregate, MUST be transported over 190 the same LSP. Conversely, each LSP MUST be capable of supporting all 191 the (active) PHBs of a given PSC. 193 Examples of deployment scenarios are provided for information in 194 APPENPIX A. 196 1.5 Relationship between Label and FEC 198 [MPLS_ARCH] states in section `2.1. Overview' that: 199 `Some routers analyze a packet's network layer header not merely to 200 choose the packet's next hop, but also to determine a packet's 201 "precedence" or "class of service". They may then apply different 202 discard thresholds or scheduling disciplines to different packets. 203 MPLS allows (but does not require) the precedence or class of 204 service to be fully or partially inferred from the label. In this 205 case, one may say that the label represents the combination of a FEC 206 and a precedence or class of service.' 208 In line with this, we observe that: 209 - With E-LSPs, the label represents the combination of a FEC and 210 the set of Behavior Aggregates (BAs) transported over the E- 212 Le Faucheur et. al 4 213 LSP). Where all the supported BAs are transported over an E-LSP, 214 the label then represents the complete FEC. 215 - With L-LSPs, the label represents the combination of a FEC and 216 an Ordered Aggregate (OA). 218 1.6 Bandwidth Reservation for E-LSPs and L-LSPs 220 Regardless of which label binding protocol is used, E-LSPs and 221 L-LSPs may be established without bandwidth reservation or with 222 bandwidth reservation. 224 Establishing an E-LSP or L-LSP with bandwidth reservation means that 225 bandwidth requirements for the LSP are signaled at LSP establishment 226 time. Such signaled bandwidth requirements may be used by LSRs at 227 establishment time to perform admission control of the signaled LSP 228 over the Diff-Serv resources provisioned (e.g. via configuration, 229 SNMP or COPS) for the relevant PSC(s). Such signaled bandwidth 230 requirements may also be used by LSRs at establishment time to 231 perform adjustment to the Diff-Serv resources associated with the 232 relevant PSC(s) (e.g. adjust PSC scheduling weight). 234 Note that establishing an E-LSP or L-LSP with bandwidth reservation 235 does not mean that per-LSP scheduling is necessarily required. Since 236 E-LSPs and L-LSPs are specified in this document for support of 237 Differentiated Services, the required forwarding treatment 238 (scheduling and drop policy) is defined by the appropriate Diff-Serv 239 PHB. This forwarding treatment MUST be applied by the LSR at the 240 granularity of the BA and MUST be compliant with the relevant PHB 241 specification. 243 When bandwidth requirements are signaled at establishment of an 244 L-LSP, the signaled bandwidth is obviously associated with the 245 L-LSP's PSC. Thus, LSRs which use the signaled bandwidth to perform 246 admission control may perform admission control over Diff-Serv 247 resources which are dedicated to the PSC (e.g. over the bandwidth 248 guaranteed to the PSC through its scheduling weight). 250 When bandwidth requirements are signaled at establishment of an 251 E-LSP, the signaled bandwidth is associated collectively to the 252 whole LSP and therefore to the set of transported PSCs. Thus, LSRs 253 which use the signaled bandwidth to perform admission control may 254 perform admission control over global resources which are shared by 255 the set of PSCs (e.g. over the total bandwidth of the link). 257 Examples of scenarios where bandwidth reservation is not used and 258 scenarios where bandwidth reservation is used are provided for 259 information in APPENDIX B. 261 Le Faucheur et. al 5 262 2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models 264 2.1 Label Forwarding Model for Diff-Serv LSRs 266 Since different Ordered Aggregates of a given FEC may be transported 267 over different LSPs, the label swapping decision of a Diff-Serv LSR 268 clearly depends on the forwarded packet's Behavior Aggregate. Also, 269 since the IP DS field of a forwarded packet may not be directly 270 visible to an LSR, the way to determine the PHB to be applied to a 271 received packet and to encode the PHB into a transmitted packet is 272 different to a non-MPLS Diff-Serv Router. 274 Thus, in order to describe Label Forwarding by Diff-Serv LSRs, we 275 model the LSR Diff-Serv label switching behavior as comprising four 276 stages: 277 - Incoming PHB Determination (A) 278 - Optional Outgoing PHB Determination via Local Policy and Traffic 279 Conditioning (B) 280 - Label Swapping (C) 281 - Encoding of Diff-Serv information into Encapsulation Layer (EXP, 282 CLP, DE, User_Priority) (D) 284 Each stage is described in more details in the following sections. 286 Obviously, to enforce the Diff-Serv service differentiation the LSR 287 MUST also apply the forwarding treatment corresponding to the 288 Outgoing PHB. 290 This model is illustrated below: 292 --Inc_label(*)--------------------------->I===I---Outg_label (**)--> 293 \ I I \ 294 \---->I===I I C I \-->I===I--Encaps-> 295 I A I I===I--Outg_PHB->I===I I D I (**) 296 -Encaps->I===I--Inc_PHB->I B I \ /->I===I 297 (*) I===I \--------+ 298 \----Forwarding--> 299 Treatment 300 (PHB) 302 `Encaps' designates the Diff-Serv related information encoded in the 303 MPLS Encapsulation layer (eg EXP field, ATM CLP, Frame Relay DE, 304 802.1 User_Priority) 306 (*) when the LSR performs label imposition, the incoming packet is 307 received unlabelled. 309 (**) when the LSR performs label disposition, the outgoing packet is 310 transmitted unlabelled. 312 This model is presented here to describe the functional operations 313 of Diff-Serv LSRs and does not constrain actual implementation. 315 Le Faucheur et. al 6 316 2.2 Incoming PHB Determination 318 This stage determines which Behavior Aggregate the received packet 319 belongs to. 321 2.2.1 Incoming PHB Determination Considering a Label Stack Entry 323 Sections 3.3 and 4.3 provide the details on how to perform incoming 324 PHB Determination considering a given received label stack entry 325 and/or received incoming MPLS encapsulation information depending on 326 the incoming LSP type corresponding to the considered stack entry 327 and depending on the incoming MPLS encapsulation. 329 Section 2.6 provides the details of which label stack entry to 330 consider for the Incoming PHB Determination depending on the 331 supported Diff-Serv tunneling mode. 333 2.2.2 Incoming PHB Determination Considering IP Header 335 Section 2.6 provides the details of when the IP Header is to be 336 considered for incoming PHB determination depending on the supported 337 Diff-Serv tunneling mode. In those cases where the IP header is to 338 be used, this stage operates exactly as with a non-MPLS IP Diff-Serv 339 Router and uses the DS field to determine incoming PHB. 341 2.3 Optional Outgoing PHB Determination Via Local Policy And Traffic 342 Conditioning 344 This stage of Diff-Serv label switching is optional and may be used 345 on an LSR to perform traffic conditioning including Behavior 346 Aggregate demotion or promotion. It is outside the scope of this 347 specification. For the purpose of specifying Diff-Serv over MPLS 348 forwarding, we simply note that the PHB to be actually enforced, and 349 conveyed to downstream LSRs, by an LSR (referred to as "outgoing 350 PHB") may be different to the PHB which had been associated with the 351 packet by the previous LSR (referred to as "incoming PHB"). 352 When this stage is not present, the "outgoing PHB" is simply 353 identical to the "incoming PHB". 355 2.4 Label Swapping 357 [MPLS_ARCH] describes how label swapping is performed by LSRs on 358 incoming labeled packets using an Incoming Label Map (ILM), where 359 each incoming label is mapped to one or multiple NHLFEs. [MPLS_ARCH] 360 also describes how label imposition is performed by LSRs on incoming 361 unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each 362 incoming FEC is mapped to one or multiple NHLFEs. 364 A Diff-Serv Context for a label is defined as comprising: 365 - `LSP type (ie E-LSP or L-LSP)' 366 - `supported PHBs' 368 Le Faucheur et. al 7 369 - `Encaps-->PHB mapping' for an incoming label 370 - `Set of PHB-->Encaps mappings' for an outgoing label 372 The present specification defines that a Diff-Serv Context is stored 373 in the ILM for each incoming label. 375 [MPLS_ARCH] states that the `NHLFE may also contain any other 376 information needed in order to properly dispose of the packet'. In 377 accordance with this, the present specification defines that a Diff- 378 Serv Context is stored in the NHLFE for each outgoing label which is 379 swapped or pushed. 381 This Diff-Serv Context information is populated into the ILM and the 382 FTN at label establishment time. 384 If the label corresponds to an E-LSP for which no EXP<-->PHB mapping 385 has been explicitly signaled at LSP setup, the `supported PHBs' is 386 populated with the set of PHBs of the preconfigured 387 EXP<-->PHB Mapping, which is discussed below in section 3.2.1. 389 If the label corresponds to an E-LSP for which an EXP<-->PHB mapping 390 has been explicitly signaled at LSP setup, the `supported PHBs' is 391 populated with the set of PHBs of the signaled EXP<-->PHB mapping. 393 If the label corresponds to an L-LSP, the `supported PHBs' is 394 populated with the set of PHBs forming the PSC that is signaled at 395 LSP set-up. 397 The details of how the `Encaps-->PHB mapping' or `Set of 398 PHB-->Encaps mappings' are populated are defined below in sections 3 399 and 4. 401 [MPLS_ARCH] also states that: 402 "If the ILM [respectively, FTN] maps a particular label to a set of 403 NHLFEs that contains more than one element, exactly one element of 404 the set must be chosen before the packet is forwarded. The 405 procedures for choosing an element from the set are beyond the scope 406 of this document. Having the ILM [respectively, FTN] map a label 407 [respectively, a FEC] to a set containing more than one NHLFE may be 408 useful if, e.g., it is desired to do load balancing over multiple 409 equal-cost paths." 411 In accordance with this, the present specification allows that an 412 incoming label [respectively FEC] may be mapped, for Diff-Serv 413 purposes, to multiple NHLFEs (for instance where different NHLFEs 414 correspond to egress labels supporting different sets of PHBs). When 415 a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv 416 LSR MUST choose one of the NHLFEs whose Diff-Serv Context indicates 417 that it supports the Outgoing PHB of the forwarded packet. 419 When a label [respectively FEC] maps to multiple NHLFEs which 420 supports the Outgoing PHB, the procedure for choosing one among 422 Le Faucheur et. al 8 423 those is outside the scope of this document. This situation may be 424 encountered where it is desired to do load balancing of a Behavior 425 Aggregate over multiple LSPs. In such situations, in order to 426 respect ordering constraints, all packets of a given microflow MUST 427 be transported over the same LSP. 429 2.5 Encoding Diff-Serv Information Into Encapsulation Layer 431 This stage determines how to encode the fields which convey Diff- 432 Serv information in the transmitted packet (eg. MPLS Shim EXP, ATM 433 CLP, Frame Relay DE, 802.1 User_Priority). 435 2.5.1 Encoding Diff-Serv Information Into Transmitted Label Entry 437 Sections 3.5 and 4.5 provide the details on how to perform Diff-Serv 438 information encoding into a given transmitted label stack entry 439 and/or transmitted MPLS encapsulation information depending on the 440 corresponding outgoing LSP type and depending on the MPLS 441 encapsulation. 443 Section 2.6 provides the details of which label stack entry to 444 perform Diff-Serv information encoding into depending on the 445 supported Diff-Serv tunneling mode. 447 2.5.2 Encoding Diff-Serv Information Into Transmitted IP Header 449 This paragraph defines how to perform Diff-Serv Information Encoding 450 into the transmitted packet IP header. 452 To perform Diff-Serv Information Encoding into the transmitted 453 packet IP header, this stage operates exactly as with a non-MPLS IP 454 Diff-Serv Router and encodes the DSCP of the Outgoing PHB into the 455 DS field. 457 Section 2.6 provides the details of when Diff-Serv Information 458 Encoding is to be performed into transmitted IP header depending on 459 the supported Diff-Serv tunneling mode. 461 2.6 Diff-Serv Tunneling Models over MPLS 463 2.6.1 Terminology 465 As per [MPLS_ARCH], 466 "we can speak of the level m LSP for Packet P as the sequence of 467 routers: 469 1. which begins with an LSR (an "LSP Ingress") that pushes on a 470 level m label, 471 2. all of whose intermediate LSRs make their forwarding decision 472 by label Switching on a level m label, 473 3. which ends (at an "LSP Egress") when a forwarding decision is 474 made by label Switching on a level m-k label, where k>0, or when 476 Le Faucheur et. al 9 477 a forwarding decision is made by "ordinary", non-MPLS forwarding 478 procedures." 480 We note that if Penultimate Hop Popping (PHP) is used on the LSP, 481 the label pop for the LSP is not performed by the LSP Egress but 482 instead is performed by the Penultimate LSR. If PHP is not used, 483 then the label pop for the LSP is performed by the LSP Egress. 485 In all the figures below, (I) indicates "LSP Ingress", (P) indicates 486 "LSP Penultimate Hop" and (E) indicates "LSP Egress". 488 2.6.2 Diff-Serv Tunneling Models 490 [DIFF_TUNNEL] considers the interaction of Differentiated Services 491 with IP tunnels of various forms. MPLS LSPs are not a form of "IP 492 tunnels" since the MPLS encapsulating header does not contain an IP 493 header and MPLS LSPs are thus clearly out of the scope of 494 [DIFF_TUNNEL]. However, although not a form of "IP tunnel", MPLS 495 LSPs are a form of "tunnel". 497 From the Diff-Serv standpoint, LSPs share a lot of characteristics 498 with IP Tunnels: 499 - intermediate nodes (ie. Nodes somewhere along the LSP span) only 500 see and operate on the "outer" Diff-Serv information. 501 - LSPs are unidirectional 502 - the "outer" Diff-Serv information can be modified at any 503 intermediate nodes. 505 However, from the Diff-Serv standpoint, LSPs also have a number of 506 distinctive properties compared to IP Tunnels: 507 - There is no behavior analogous to Penultimate Hop Popping (PHP) 508 for IP Tunnels. Furthermore, PHP results in the "outer" 509 Diff-Serv information associated with the LSP not being visible 510 to the LSP egress. In situations where this information is not 511 meaningful at the LSP Egress, this is obviously not an issue at 512 all. In situations where this information is meaningful at the 513 LSP Egress, then it must somehow be carried in some other means. 514 - Two-level hierarchical LSPs with the two nested LSPs starting on 515 the same Ingress LSR and finishing on the same Egress LSR, are 516 expected to be commonplace in MPLS networks for applications 517 such as MPLS VPNs [MPLS_VPN]. 519 Based on these considerations, it is clear that the two important 520 conceptual models for Diff-Serv tunneling over IP Tunnels defined in 521 [DIFF_TUNNEL] are applicable and useful to Diff-Serv over MPLS and 522 that their respective detailed operations is somewhat different over 523 MPLS. These two models are the Uniform Model and the Pipe Model and 524 their operations over MPLS is described in the following sections. 526 2.6.3 Uniform Model 528 Le Faucheur et. al 10 529 With the Uniform Model, MPLS tunnels (aka LSPs) are viewed as 530 artifacts of the end-to-end path from the Diff-Serv standpoint. MPLS 531 Tunnels may be used for forwarding purposes but have no significant 532 impact on Diff-Serv. In this model, any packet contains exactly one 533 piece of Diff-Serv information which is meaningful and is always 534 encoded in the outer most label entry (or in the IP DSCP where the 535 IP packet is transmitted unlabelled for instance at the egress of 536 the LSP). Any Diff-Serv information encoded somewhere else (eg. in 537 deeper label entries) is of no significance to intermediate nodes or 538 to the tunnel egress and is ignored. If Traffic Conditioning at 539 intermediate nodes on the LSP span affects the "outer" Diff-Serv 540 information, the updated Diff-Serv information is the one considered 541 meaningful at the egress of the LSP. 543 With this Uniform Model: 544 - the LSP Ingress, when performing the push operation, encodes the 545 meaningful Diff-Serv information in the label entry 546 corresponding to the pushed label. 547 - Intermediate LSRs only consider and operate on the LSP Diff-Serv 548 Information encoded in the "outer" label entry (ie label entry 549 on which they perform the label swap). 550 - Penultimate Hop Popping (PHP) can be used. In that case, the 551 meaningful Diff-Serv information is conveyed by the Penultimate 552 LSR to the LSP Egress in the header that is exposed by the pop 553 operation (ie. in the header that will be used for actual 554 forwarding by the LSP Egress). 555 Note that to do so, the Penultimate LSR needs to be aware of the 556 "Set of PHB-->Encaps mappings" for the label corresponding to 557 the exposed header (or the PHB-->DSCP mapping). Methods for 558 providing this mapping awareness are outside the scope of this 559 specification. As an example, the "PHB-->DSCP mapping" may be 560 locally configured. As another example, in some environments, it 561 may be appropriate for the Penultimate LSR to assume that the 562 "Set of PHB-->Encaps mappings" to be used for the outgoing label 563 in the exposed header is the "Set of PHB-->Encaps mappings" that 564 would be used by the LSR if the LSR was not doing PHP. 565 Note also that this specification assumes that the Penultimate 566 LSR does not perform label swapping over the label entry exposed 567 by the pop operation (and in fact that it does not even look at 568 the exposed label). Consequently, restrictions may apply to the 569 Diff-Serv Information Encoding that can be performed by the 570 Penultimate LSR. For example, this specification does not allow 571 situations where the Penultimate LSR pops a label corresponding 572 to an E-LSP supporting two PSCs, while the header exposed by the 573 pop contains label values for two L-LSPs each supporting one 574 PSC, since the Diff-Serv Information Encoding would require 575 selecting one label or the other. 576 - It is also possible to not use PHP. In that case, the meaningful 577 Diff-Serv information is conveyed by the Penultimate LSR to the 578 LSP Egress in the "outer" label entry (which corresponds to the 579 LSP label). 581 Le Faucheur et. al 11 582 - When the pop operation is performed (ie. Penultimate hop with 583 PHP, LSP Egress without PHP), the incoming Diff-Serv information 584 contained in the outmost label entry before the pop is 585 considered as the meaningful information. 587 Operation of the Uniform Model with PHP is illustrated below : 589 ========== LSP ==========================> 591 +--Swap-(M)-...-Swap-(M)--+ 592 / (outer header) \ 593 (M) (M) 594 / \ 595 >--(M)--Push...............(x)............Pop-(M)--(E)--(M)-> 596 (I) (inner header) (P) 598 (M) represents the Meaningful Diff-Serv information encoded in the 599 corresponding header. 601 (x) represents non-meaningful Diff-Serv information. 603 Operation of the Uniform Model without PHP is illustrated below: 605 ========== LSP =============================> 607 +--Swap--(M)-...-Swap-(M)-swap--(M)--+ 608 / (outer header) (P) \ 609 (M) (M) 610 / \ 611 >--(M)--Push...............(x).......................Pop--(M)-> 612 (I) (inner header) (E) 614 (M) represents the Meaningful Diff-Serv information encoded in the 615 corresponding header. 617 (x) represents non-meaningful Diff-Serv information. 619 Use of the Uniform Model allows LSPs to span Diff-Serv domain 620 boundaries without any other measure in place than an inter-domain 621 Traffic Conditioning Agreement at the physical boundary between the 622 Diff-Serv domains and operating exclusively on the "outer" header, 623 since the meaningful Diff-Serv information is always visible and 624 modifiable in the outmost label entry. 626 The Uniform Model for Diff-Serv over MPLS is such that, from the 627 Diff-Serv perspective, operations are exactly identical to the 628 operations if MPLS was not used. In other words, MPLS is entirely 629 transparent to the Diff-Serv operations. For this reason, the 631 Le Faucheur et. al 12 632 Uniform Model has been selected in this specification as the base 633 mandatory mode of operations and thus MUST be supported. 635 For support of the Uniform Model over an LSP (with and without PHP), 636 an LSR performs the Incoming PHB Determination and the Diff-Serv 637 information Encoding in the following manner: 638 - when receiving an unlabelled packet, the LSR performs Incoming 639 PHB Determination considering the received IP Header. 640 - when receiving a labeled packet, the LSR performs Incoming PHB 641 Determination considering the outer label entry in the received 642 label stack. In particular, when a pop operation is to be 643 performed for the considered LSP, the LSR performs Incoming PHB 644 Determination BEFORE the pop. 645 - when performing a swap-only operation for an LSP, the LSR 646 encodes Diff-Serv Information in the transmitted label entry 647 corresponding to the swapped label 648 - when performing a push operation for an LSP, the LSR encodes 649 Diff-Serv Information in the transmitted label entry 650 corresponding to the pushed label. The Diff-Serv Information 651 encoded in the encapsulated header (swapped label entry or IP 652 Header) is of no importance. 654 2.6.4 Pipe Model 656 With the Pipe Model, MPLS tunnels (aka LSPs) are used to hide the 657 intermediate MPLS nodes between LSP Ingress and Egress from the 658 Diff-Serv perspective. In this model, the LSP Egress uses the Diff- 659 Serv information conveyed from the LSP Ingress inside the 660 encapsulated header (be it an IP Header or an MPLS Header) and 661 ignores the Diff-Serv information conveyed in the encapsulating 662 header. 664 In this model, tunneled packets must convey two meaningful pieces of 665 Diff-Serv information: 666 - the Diff-Serv information which is meaningful to intermediate 667 nodes along the LSP span (which we refer to as the "LSP Diff- 668 Serv Information"). This LSP Diff-Serv Information is not 669 meaningful at the LSP Egress: Whether Traffic Conditioning at 670 intermediate nodes on the LSP span affects the LSP Diff-Serv 671 information or not, this updated Diff-Serv information is not 672 considered meaningful at the LSP Egress and is ignored. 673 - the Diff-Serv information which is meaningful at the LSP Egress 674 (which we refer to as the "Tunneled Diff-Serv Information"). 675 This information is to be conveyed by the LSP Ingress to the LSP 676 Egress. This Diff-Serv information is not meaningful to the 677 intermediate nodes on the LSP span. 679 With this Pipe Model: 680 - the LSP Ingress, when performing the push operation, encodes the 681 LSP Diff-Serv information in the label entry that is pushed 682 ("outer label entry") and encodes the Tunneled Diff-Serv 684 Le Faucheur et. al 13 685 Information in the encapsulated header (IP header or swapped 686 label entry). 687 - Intermediate LSRs only consider and operate on the LSP Diff-Serv 688 Information encoded in the "outer" label entry (ie label entry 689 on which they perform the label swap). 690 - Penultimate Hop Popping (PHP) can be used. In that case, the LSP 691 Diff-Serv Information is simply not conveyed by the Penultimate 692 LSR to the LSP Egress. The Penultimate LSR conveys to the LSP 693 Egress the Tunneled Diff-Serv Information in the header that is 694 exposed by the pop operation (ie. in the header that will be 695 used for actual forwarding by the LSP Egress). However, since 696 the LSP Diff-Serv Information is the meaningful one over the 697 whole LSP including from the Penultimate LSR to the LSP Egress, 698 the Penultimate LSR performs Diff-Serv forwarding treatment (ie 699 PHB enforcement) based on the LSP Diff-Serv Information (even if 700 this information is not actually conveyed in the packet 701 transmitted to the LSP Egress). 702 - it is also possible to not use PHP. In that case, the LSP Diff- 703 Serv Information is conveyed by the Penultimate LSR to the LSP 704 Egress in the "outer" label entry (which corresponds to the LSP 705 label) where it will simply be ignored. 706 - When PHP is used, the LSP Egress directly uses the Diff-Serv 707 information received in the outer header (IP header or outer 708 label entry) since it carries the Tunneled Diff-Serv 709 Information. 710 - When PHP is not used, LSP Egress ignores the Diff-Serv 711 information contained in the label entry to be popped (since it 712 contains the LSP Diff-Serv information) and considers the Diff- 713 Serv information conveyed in the header (IP header or MPLS 714 header) which is used to do the actual forwarding (since it 715 contains the Tunneled LSP Diff-Serv information). In other 716 words, the LSP Egress considers the Diff-Serv information 717 conveyed in the header after the pop operation. 719 Operation of the Pipe Model with PHP is illustrated below: 721 ========== LSP ===========================> 723 +--Swap--(M)-...-Swap--(M)--+ 724 / (outer header) \ 725 (M) (M) 726 / \ 727 >--(m)-Push.................(m)............Pop-(m)-(E)-(m)--> 728 (I) (inner header) (P) (M*) 730 (M) represents the "LSP Diff-Serv information 732 (m) represents the "Tunneled Diff-Serv information" 734 Le Faucheur et. al 14 735 (*) The Penultimate LSR considers the LSP Diff-Serv information 736 received in the outer header (ie. before the pop) in order to apply 737 its Diff-Serv forwarding treatment (ie actual PHB) 739 Operation of the Pipe Model without PHP is illustrated below: 741 ========== LSP =============================> 743 +--Swap-(M)-...-Swap-(M)--Swap--(M)--+ 744 / (outer header) (P) \ 745 (M) (M) 746 / \ 747 >--(m)-Push.................(m).....................Pop--(m)--> 748 (I) (inner header) (E) 750 (M) represents the "LSP Diff-Serv information 752 (m) represents the "Tunneled Diff-Serv information" 754 The Pipe Model is particularly appropriate to environments in which 755 the incoming interface of the LSP Ingress and the outgoing interface 756 of the LSP Egress are in the same Diff-Serv domain while the LSP 757 spans another (other) Diff-Serv domain(s). 759 As an example, consider the case where a service provider is 760 offering an MPLS VPN service including Diff-Serv differentiation. 761 Say that a collection of sites are interconnected via such an MPLS 762 VPN service. Now say that this collection of sites are managed under 763 a common administration and are also supporting Diff-Serv service 764 differentiation. If the VPN site administration and the Service 765 Provider are not sharing the exact same Diff-Serv policy (for 766 instance not supporting the same number of PHBs), then operation of 767 Diff-Serv in the Pipe Model over the MPLS VPN service would allow 768 the VPN Sites Diff-Serv domain policy to operate consistently 769 throughout the ingress VPN Site and Egress VPN Site and 770 transparently over the Service Provider Diff-Serv domain. 772 Support of the Pipe Model is defined in this specification as a 773 recommended option and thus SHOULD be supported. 775 For support of the Pipe Model over an LSP without PHP, an LSR 776 performs the Incoming PHB Determination and the Diff-Serv 777 information Encoding in the following manner: 778 - when receiving an unlabelled packet, the LSR performs Incoming 779 PHB Determination considering the received IP Header. 780 - when receiving a labeled packet, the LSR performs Incoming PHB 781 Determination considering the header (label entry or IP header) 782 which is used to do the actual forwarding. In particular, when a 783 pop operation is to be performed for the considered LSP, the LSR 784 performs Incoming PHB Determination AFTER the pop. 786 Le Faucheur et. al 15 787 - when performing a swap-only operation for an LSP, the LSR 788 encodes Diff-Serv Information in the transmitted label entry 789 corresponding to the swapped label 790 - when performing a push operation for an LSP, the LSR: 791 o encodes Diff-Serv Information corresponding to the 792 OUTGOING PHB in the transmitted label entry corresponding 793 to the pushed label. 794 o encodes Diff-Serv Information corresponding to the 795 INCOMING PHB in the encapsulated header (swapped label 796 entry or IP header). 798 For support of the Pipe Model over an LSP with PHP, an LSR performs 799 Incoming PHB Determination and Diff-Serv information Encoding in the 800 same manner as without PHP with the following exception: 801 - the Penultimate LSR performs Incoming PHB Determination 802 considering the outer label entry in the received label stack. 803 In other words, when a pop operation is to be performed for the 804 considered LSP, the Penultimate LSR performs Incoming PHB 805 Determination BEFORE the pop. 806 - the Penultimate LSR does not perform Encoding of Diff-Serv 807 Information into the header exposed by the pop operation. 809 Note that LSR behaviors for the Uniform Model and for the Pipe Model 810 only differ when doing a push or a pop. Thus, Intermediate LSRs 811 which perform swap only operations for an LSP , behave exactly in 812 the same way regardless of whether they are behaving in the Uniform 813 Model or the Pipe model. With a Diff-Serv implementation supporting 814 both the Uniform Model and the Pipe Model, only LSRs behaving as LSP 815 Ingress, Penultimate LSR or LSP Egress need to be configured to 816 operate in a particular Model. 818 2.6.5 Other Models 820 Other Diff-Serv tunneling models are conceivable over MPLS for 821 support of more complex scenarios. For instance, the egress of an 822 LSP could conceivably make some complex Diff-Serv decision based on 823 both the Diff-Serv information conveyed in the encapsulating header 824 and in the encapsulated header. Models beyond the Uniform Model and 825 the Pipe Model are outside the scope of this specification and MAY 826 be supported as an option. 828 2.6.6 Hierarchy 830 Through the label stack mechanism, MPLS allows LSP tunneling to nest 831 to any depth. We observe that with such nesting, the push of level 832 N+1 takes place on a subsequent (or the same) LSR to the LSR doing 833 the push for level N, while the pop of level N+1 takes place on a 834 previous (or the same) LSR to the LSR doing the pop of level N. For 835 a given level N LSP, the Ingress LSR doing the push and the LSR 836 doing the pop (Penultimate LSR or LSP Egress) are expected to 837 operate in the same Tunneling Model (ie Uniform or Pipe). LSRs at 839 Le Faucheur et. al 16 840 different levels of LSPs are expected to operate in the same or in 841 different Tunneling Models. 843 Le Faucheur et. al 17 844 Hierarchical operations is illustrated below in the case of two 845 levels of tunnels: 846 +--------Swap--...---+ 847 / (outmost header) \ 848 / \ 849 Push(2).................(2)Pop 850 / (outer header) \ 851 / \ 852 >>---Push(1)........................(1)Pop-->> 853 (inner header) 855 (1) Tunneling Model 1 (either Uniform or Pipe) 857 (2) Tunneling Model 2 (same as Tunneling Model 1 or different Model) 859 For support of M levels of push in the Uniform Model: 860 - when performing multiple push operations, the LSR encodes Diff- 861 Serv Information in the transmitted label entry corresponding to 862 the LAST pushed label (ie the label pushed in the outer label 863 entry). The Diff-Serv Information encoded in the encapsulated 864 header (swapped label entry or IP Header) as well as the Diff- 865 Serv Information encoded in label entries for other pushed 866 labels are of no importance. 868 For support of M levels of pop in the Uniform Model: 869 - when performing multiple pop operations for an LSP, the LSR 870 performs Incoming PHB Determination considering the outmost 871 label entry in the received label stack. In other words, when 872 multiple pop operations are to be performed, the LSR performs 873 Incoming PHB Determination BEFORE ANY pop operations. 874 - when the multiple pop operations are performed by the 875 Penultimate LSR, note that to perform Encoding of Diff-Serv 876 Information, the Penultimate LSR needs to be aware of the "Set 877 of PHB-->Encaps mappings" for the label corresponding to the 878 exposed header after all the pop operations (or the PHB-->DSCP 879 mapping). Methods for providing this mapping awareness are 880 outside the scope of this specification. 881 - when the multiple pop operations are performed by the 882 Penultimate LSR, note also that this specification assumes that 883 the Penultimate LSR does not perform label swapping over the 884 label entry exposed after all the pop operations (and in fact 885 that it does not even look at the header exposed after the last 886 pop operations). Consequently, restrictions may apply to the 887 Diff-Serv Information Encoding that can be performed by the 888 Penultimate LSR. 890 For support of M levels of push in the Pipe Model: 891 - when performing multiple push operations, the LSR: 892 o encodes Diff-Serv Information corresponding to the 893 Outgoing PHB in the transmitted label entry corresponding 895 Le Faucheur et. al 18 896 to the LAST pushed label (ie the label pushed in the outer 897 label entry). 898 o encodes Diff-Serv Information corresponding to the 899 Incoming PHB in the encapsulated header (swapped label 900 entry or IP header) as well as in the label entries for 901 all the pushed labels (except the last pushed label). 903 For support of M levels of pop in the Pipe Model without PHP: 904 - when performing multiple pop operations for an LSP, the LSR 905 performs Incoming PHB Determination considering the header 906 (label entry or IP header) which is used to do the actual 907 forwarding. In other words, when a pop operation is to be 908 performed for the considered LSP, the LSR performs Incoming PHB 909 Determination AFTER ALL the pop operations. 911 For support of M levels of pop in the Pipe Model with PHP, the 912 Penultimate LSR: 913 - performs Incoming PHB Determination considering the outmost 914 label entry in the received label stack. In other words, when 915 multiple pop operations are to be performed for the considered 916 LSP, the LSR performs Incoming PHB Determination BEFORE ANY pop 917 operations. 918 - does not perform Encoding of Diff-Serv Information into the 919 header that is exposed after all the pop operations 921 3. Detailed Operations of E-LSPs 923 3.1 E-LSP Definition 925 Recognizing that: 926 - Certain MPLS encapsulations (such as PPP and LAN) make use of a 927 Shim Header which consists of a label stack with one or more 928 entries [MPLS_ENCAPS] each with a 3-bit EXP field; 929 - the Differentiated-Service (DS) field is 6-bit long 930 [DIFF_HEADER] potentially allowing support of up to 64 Behavior 931 Aggregates 932 - any subset of 8 (or less) DSCP values can be mapped entirely 933 into the 3-bit long EXP field of the MPLS label stack entry; 935 We define that: 936 - an LSP established for a given Forwarding Equivalent Class (FEC) 937 may be used for transport of up to eight BAs of that FEC; 938 - the set of transported BAs can span multiple OAs; 939 - for a given OA transported over the LSP, all supported BAs of 940 this OA are transported over the LSP; 941 - such an LSP is referred to as an "EXP-inferred-PSC" LSP or 942 "E-LSP" because the PSC to be applied to a labeled packet by the 943 LSR depends on the EXP field value in the MPLS Shim Header; 944 - packets belonging to this given FEC and from the corresponding 945 set of BAs are sent down this E-LSP. 947 Le Faucheur et. al 19 948 - multiple BAs belonging to the same FEC and transported over the 949 same E-LSP are granted different scheduling treatment and 950 different drop precedence by the LSR based on the EXP field 951 which is appropriately encoded to reflect both the PSC and the 952 drop precedence of the PHB corresponding to the packet's BA. 953 - the mapping between EXP field and PHB to be applied by the LSR 954 for a given E-LSP is either explicitly signaled at label set-up 955 or relies on a preconfigured mapping. 957 Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the 958 pre-configured mapping are capable of transporting the same common 959 set of 8, or fewer, BAs. Each of those E-LSPs may actually transport 960 this full set of BAs or any arbitrary subset of it. 962 For a given FEC, two given E-LSPs using signaled EXP<-->PHB mapping 963 can support the same or different sets of Ordered Aggregates. 965 For a given FEC, there may be more than one E-LSP carrying the same 966 OA, for example for purposes of load balancing of the OA. In that 967 case, in order to respect ordering constraints, all packets of a 968 given microflow must be transported over the same LSP. 970 MPLS specifies how LSPs can be established via multiple signaling 971 protocols. Those include the Label Distribution Protocol (LDP), 972 RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP 973 are to be used for establishment of E-LSPs. 975 3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP 977 This section defines how the `Encaps-->PHB mapping' of the Diff-Serv 978 Context is populated for an incoming E-LSP in order to allow 979 Incoming PHB determination. 981 The `Encaps-->PHB mapping' for an E-LSP is always of the form 982 `EXP-->PHB mapping'. 984 If the label corresponds to an E-LSP for which no EXP<-->PHB mapping 985 has been explicitly signaled at LSP setup, the `EXP-->PHB mapping' 986 is populated based on the Preconfigured EXP<-->PHB Mapping which is 987 discussed below in section 3.2.1. 989 If the label corresponds to an E-LSP for which an EXP<-->PHB mapping 990 has been explicitly signaled at LSP setup, the `EXP-->PHB mapping' 991 is populated as per the signaled EXP<-->PHB mapping. 993 3.2.1 Preconfigured EXP<-->PHB mapping 995 LSRs supporting E-LSPs which use the preconfigured EXP<-->PHB 996 mapping must allow local configuration of this EXP<-->PHB mapping. 997 This mapping applies to all the E-LSPs established on this LSR 998 without a mapping explicitly signaled at set-up time. 1000 Le Faucheur et. al 20 1001 The preconfigured EXP<-->PHB mapping must either be consistent at 1002 every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the 1003 LSP or appropriate remarking of the EXP field must be performed by 1004 the LSR whenever a different preconfigured mapping is used on the 1005 ingress and egress interfaces. 1007 3.3 Incoming PHB Determination On Incoming E-LSP 1009 This section defines how Incoming PHB Determination is carried out 1010 when the considered label entry in the received label stack 1011 corresponds to an E-LSP. This requires that the `Encaps-->PHB 1012 mapping' is populated as defined above in section 3.2. 1014 When considering a label entry corresponding to an incoming E-LSP 1015 for Incoming PHB Determination, the LSR: 1016 - determines the EXP-->PHB mapping by looking up the 1017 `Encaps-->PHB mapping' of the Diff-Serv Context associated in 1018 the ILM with the considered incoming E-LSP label. 1019 - determines the incoming PHB by looking up the EXP field of the 1020 considered label entry in the EXP-->PHB mapping table. 1022 3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP 1024 This section defines how the `Set of PHB-->Encaps mappings' of the 1025 Diff-Serv Context is populated for an outgoing E-LSP in order to 1026 allow Encoding of Diff-Serv information in the Encapsulation Layer. 1028 3.4.1 `PHB-->EXP mapping' 1030 An outgoing E-LSP must always have a `PHB-->EXP mapping' as part of 1031 the `Set of PHB-->Encaps mappings' of its Diff-Serv Context. 1033 If the label corresponds to an E-LSP for which no EXP<-->PHB mapping 1034 has been explicitly signaled at LSP setup, this `PHB-->EXP mapping' 1035 is populated based on the Preconfigured EXP<-->PHB Mapping which is 1036 discussed above in section 3.2.1. 1038 If the label corresponds to an E-LSP for which an EXP<-->PHB mapping 1039 has been explicitly signaled at LSP setup, the `PHB-->EXP mapping' 1040 is populated as per the signaled EXP<-->PHB mapping. 1042 3.4.2 `PHB-->CLP mapping' 1044 If the E-LSP is egressing over an ATM interface which is not label 1045 switching controlled, then one `PHB-->CLP mapping' is added at label 1046 setup to the `Set of PHB-->Encaps mappings' in the Diff-Serv Context 1047 for this outgoing E-LSP. This `PHB-->CLP mapping' is populated in 1048 the following way: 1049 - it is a function of the PHBs supported on this LSP, and may use 1050 the relevant mapping entries for these PHBs from the 1051 Default PHB-->CLP Mapping defined in section 3.4.2.1. Other 1052 mappings than the one defined in section 3.4.2.1 may be used. In 1054 Le Faucheur et. al 21 1055 particular, if a mapping from PHBs to CLP is standardized in the 1056 future for operations of Diff-Serv over ATM, such standardized 1057 mapping may then be used. 1059 For example if the outgoing label corresponds to an E-LSP supporting 1060 the AF1 PSC and the EF PHB and egressing over an ATM interface, then 1061 the `PHB-->CLP mapping' may be populated with: 1063 PHB CLP Field 1065 AF11 ----> 0 1066 AF12 ----> 1 1067 AF13 ----> 1 1068 EF ----> 0 1070 Notice that if the E-LSP is egressing over an ATM interface, then 1071 the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP 1072 mapping' and a `PHB-->CLP mapping'. 1074 3.4.2.1 Default PHB-->CLP Mapping 1076 PHB CLP Bit 1078 DF ----> 0 1079 CSn ----> 0 1080 AFn1 ----> 0 1081 AFn2 ----> 1 1082 AFn3 ----> 1 1083 EF ----> 0 1085 3.4.3 `PHB-->DE mapping' 1087 If the E-LSP is egressing over a Frame Relay interface which is not 1088 label switching controlled, one `PHB-->DE mapping' is added at label 1089 setup to the `Set of PHB-->Encaps mappings' in the Diff-Serv Context 1090 for this outgoing E-LSP and is populated in the following way: 1091 - it is a function of the PHBs supported on this LSP, and may use 1092 the relevant mapping entries for these PHBs from the Default 1093 PHB-->DE Mapping defined in section 3.4.3.1. Other mappings than 1094 the one defined in section 3.4.3.1 may be used. In particular, 1095 if a mapping from PHBs to DE is standardized in the future for 1096 operations of Diff-Serv over Frame Relay, such standardized 1097 mapping may then be used. 1099 Notice that if the E-LSP is egressing over a Frame Relay interface, 1100 then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP 1101 mapping' and a `PHB-->DE mapping'. 1103 3.4.3.1 Default PHB-->DE Mapping 1105 PHB DE Bit 1107 Le Faucheur et. al 22 1108 DF ----> 0 1109 CSn ----> 0 1110 AFn1 ----> 0 1111 AFn2 ----> 1 1112 AFn3 ----> 1 1113 EF ----> 0 1115 3.4.4 `PHB-->802.1 mapping' 1117 If the E-LSP is egressing over a LAN interface on which multiple 1118 802.1 Traffic Classes are supported as per [IEEE_802.1], then one 1119 `PHB-->802.1 mapping' is added at label setup to the `Set of 1120 PHB-->Encaps mappings' of the Diff-Serv Context for this outgoing 1121 E-LSP. This `PHB-->802.1 mapping' is populated in the following way: 1122 - it is a function of the PHBs supported on this LSP, an uses the 1123 relevant mapping entries for these PHBs from the Preconfigured 1124 PHB-->802.1 Mapping defined in section 3.4.4.1. 1126 Notice that the `Set of PHB-->Encaps mappings' then contains both a 1127 `PHB-->EXP mapping' and a `PHB-->802.1 mapping'. 1129 3.4.4.1 Preconfigured `PHB-->802.1 Mapping' 1131 At the time of producing this specification, there are no 1132 standardized mapping from PHBs to 802.1 Traffic Classes. 1133 Consequently, an LSR supporting multiple 802.1 Traffic Classes over 1134 LAN interfaces must allow local configuration of a `PHB-->802.1 1135 Mapping'. This mapping applies to all the outgoing LSPs established 1136 by the LSR on such LAN interfaces. 1138 3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing 1139 E-LSP 1141 This section defines how to encode Diff-Serv information into the 1142 MPLS encapsulation Layer for a given transmitted label entry 1143 corresponding to an outgoing E-LSP. This requires that the `Set of 1144 PHB-->Encaps mappings' is populated as defined above in section 3.4. 1146 The LSR first determines the `Set of PHB-->Encaps mappings' of the 1147 Diff-Serv Context associated with the corresponding label in the 1148 NHLFE. 1150 3.5.1 `PHB-->EXP mapping' 1152 The LSR: 1153 - determines the PHB-->EXP mapping by looking up the 1154 `Set of PHB-->Encaps mapping' of the Diff-Serv Context 1155 associated with the corresponding label in the NHLFE. 1156 - determines the value to be written in the EXP field of the 1157 corresponding level label entry by looking up the "outgoing PHB" 1158 in this PHB-->EXP mapping table. 1160 Le Faucheur et. al 23 1161 3.5.2 `PHB-->CLP mapping' 1163 If the `Set of PHB-->Encaps mappings' contains a mapping of the form 1164 `PHB-->CLP mapping', then the LSR: 1165 - determines the value to be written in the CLP field of the ATM 1166 encapsulation header, by looking up the "outgoing PHB" in this 1167 PHB-->CLP mapping table. 1169 3.5.3 `PHB-->DE mapping' 1171 If the `Set of PHB-->Encaps mappings' contains a mapping of the form 1172 `PHB-->DE mapping', then the LSR: 1173 - determines the value to be written in the DE field of the Frame 1174 Relay encapsulation header, by looking up the "outgoing PHB" in 1175 this PHB-->DE mapping table. 1177 3.5.4 `PHB-->802.1 mapping' 1179 If the `Set of PHB-->Encaps mappings' contains a mapping of the form 1180 `PHB-->802.1 mapping', then the LSR: 1181 - determines the value to be written in the User_Priority field of 1182 the Tag Control Information of the 802.1 encapsulation header 1183 [IEEE_802.1], by looking up the "outgoing PHB" in this 1184 PHB-->802.1 mapping table. 1186 3.6 E-LSP Merging 1188 In an MPLS domain, two or more LSPs can be merged into one LSP at 1189 one LSR. E-LSPs are compatible with LSP Merging under the following 1190 condition: 1192 E-LSPs can only be merged into one LSP if they support the 1193 exact same set of BAs. 1195 For E-LSPs using signaled EXP<-->PHB mapping, the above merge 1196 condition MUST be enforced by LSRs through explicit checking at 1197 label setup that the exact same set of PHBs is supported on the 1198 merged LSPs. 1200 For E-LSPs using the preconfigured EXP<-->PHB mapping, since the 1201 PHBs supported over an E-LSP is not signaled at establishment time, 1202 an LSR can not rely on signaling information to enforce the above 1203 merge. However all E-LSPs using the preconfigured EXP<-->PHB mapping 1204 are required to support the same set of Behavior Aggregates within a 1205 given MPLS Diff-Serv domain. Thus, merging of E-LSPs using the 1206 preconfigured EXP<-->PHB mapping is allowed within a given MPLS 1207 Diff-Serv domain. 1209 4. Detailed Operation of L-LSPs 1211 4.1 L-LSP Definition 1213 Le Faucheur et. al 24 1214 Recognizing that: 1216 - All currently defined MPLS encapsulation methods have a field of 1217 3 bits or less for Diff-Serv encoding (i.e., 3-bit EXP field in 1218 case of Shim Header and 1-bit CLP/DE bit in case of ATM/Frame 1219 Relay). 1220 - The Differentiated-Services (DS) field is 6-bit long 1221 [DIFF_HEADER] potentially allowing support of up to 64 Behavior 1222 Aggregates. So that when more than a certain number of BAs are 1223 used (i.e., more than 8 BAs in case of Shim Header and more than 1224 2 BAs in case of ATM/Frame Relay), the DS field can not be 1225 mapped entirely into the appropriate field of MPLS encapsulation 1226 header (i.e., EXP field in case of Shim Header and CLP/DE field 1227 in case of ATM/Frame Relay); 1229 We define that: 1231 - an LSP established for a given Forwarding Equivalent Class (FEC) 1232 may be used for transport of the BAs comprised in one Ordered 1233 Aggregate (OA) for that FEC; 1234 - all BAs of this OA can be transported over the LSP; 1235 - BAs from other OAs can not be transported over the LSP; 1236 - BAs from the OA transported over the LSP are given the 1237 appropriate scheduling treatment based on the PSC which is 1238 explicitly signaled at label set-up time. 1239 - Such an LSP is referred to as a "Label-Only-inferred-PSC" LSP or 1240 "L-LSP"; 1241 - Multiple BAs from the OA transported over the LSP are granted 1242 different drop precedence by the LSR based on the appropriately 1243 encoded relevant field of MPLS encapsulation header (EXP field 1244 of the top label entry for the shim header, CLP/DE bit in case 1245 of ATM/Frame Relay); The mapping between the relevant field of 1246 the MPLS encapsulation and the drop precedence is a well-known 1247 mapping. 1249 For a given FEC, there may be more than one L-LSP carrying the same 1250 OA, for example for purposes of load balancing of the OA. In that 1251 case, in order to respect ordering constraints, all packets of a 1252 given microflow must be transported over the same LSP. 1254 MPLS specifies how LSPs can be established via multiple signaling 1255 protocols. Those include the Label Distribution Protocol (LDP), 1256 RSVP, BGP and PIM. Sections 5 and 6 below specify how RSVP and LDP 1257 are to be used for establishment of L-LSPs. 1259 4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP 1261 This section defines how the `Encaps-->PHB mapping' of the Diff-Serv 1262 Context is populated for an incoming L-LSP in order to allow 1263 Incoming PHB determination. 1265 Le Faucheur et. al 25 1266 4.2.1 `EXP-->PHB mapping' 1268 If the LSR terminates the MPLS Shim Layer over this incoming L-LSP 1269 and the L-LSP ingresses on an interface which is not ATM nor Frame 1270 Relay, then the `Encaps-->PHB mapping' is populated at label setup 1271 in the following way: 1272 - it must actually be a `EXP-->PHB mapping' 1273 - this mapping is a function of the PSC which is carried on this 1274 LSP, and must use the relevant mapping entries for this PSC from 1275 the Mandatory EXP/PSC-->PHB Mapping defined in Section 4.2.1.1. 1277 For example if the incoming label corresponds to an L-LSP supporting 1278 the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with: 1280 EXP Field PHB 1282 000 ----> AF11 1283 001 ----> AF12 1284 010 ----> AF13 1286 An LSR supporting L-LSPs over PPP interfaces and LAN interfaces is 1287 an example of LSR terminating the Shim layer over ingress interfaces 1288 which are not ATM nor Frame Relay. 1290 If the LSR terminates the MPLS Shim Layer over this incoming L-LSP 1291 and the L-LSP ingresses on an ATM or Frame Relay interface, then the 1292 `Encaps-->PHB mapping' is populated at label setup in the following 1293 way: 1294 - it should actually be a `EXP-->PHB mapping'. Alternative 1295 optional ways of populating the `Encaps-->PHB mapping' might be 1296 defined in the future (e.g., using a 'CLP/EXP--> PHB mapping' or 1297 a 'DE/EXP-->PHB mapping') but are outside the scope of this 1298 document. 1299 - when the `Encaps-->PHB mapping' is an `EXP-->PHB mapping', this 1300 `EXP-->PHB mapping' mapping is a function of the PSC which is 1301 carried on the L-LSP, and must use the relevant mapping entries 1302 for this PSC from the Mandatory EXP/PSC-->PHB Mapping defined in 1303 Section 4.2.1.1. 1305 An Edge-LSR of an ATM-MPLS domain or of a FR-MPLS domain is an 1306 example of LSR terminating the shim layer over an ingress ATM/FR 1307 interface. 1309 4.2.1.1 Mandatory EXP/PSC --> PHB mapping 1311 EXP Field PSC PHB 1313 000 DF ----> DF 1314 000 CSn ----> CSn 1315 000 AFn ----> AFn1 1316 001 AFn ----> AFn2 1317 010 AFn ----> AFn3 1319 Le Faucheur et. al 26 1320 000 EF ----> EF 1322 4.2.2 `CLP-->PHB mapping' 1324 If the LSR does not terminate an MPLS Shim Layer over this incoming 1325 label and uses ATM encapsulation (i.e. it is an ATM-LSR), then the 1326 `Encaps-->PHB mapping' of the Diff-Serv Context for this incoming 1327 L-LSP is populated at label setup in the following way: 1328 - it is actually a `CLP-->PHB mapping' 1329 - the mapping is a function of the PSC which is carried on this 1330 LSP, and should use the relevant mapping entries for this PSC 1331 from the Default CLP/PSC-->PHB Mapping defined in Section 1332 4.2.2.1. 1334 For example if the incoming label corresponds to an L-LSP supporting 1335 the AF1 PSC, then the `Encaps-->PHB mapping' should be populated 1336 with: 1338 CLP Field PHB 1340 0 ----> AF11 1341 1 ----> AF12 1343 4.2.2.1 Default CLP/PSC --> PHB Mapping 1345 CLP Bit PSC PHB 1347 0 DF ----> DF 1348 0 CSn ----> CSn 1349 0 AFn ----> AFn1 1350 1 AFn ----> AFn2 1351 0 EF ----> EF 1353 4.2.3 `DE-->PHB mapping' 1355 If the LSR does not terminate an MPLS Shim Layer over this incoming 1356 label and uses Frame Relay encapsulation (i.e. it is a FR-LSR), then 1357 the `Encaps-->PHB mapping' of the Diff-Serv Context for this 1358 incoming L-LSP is populated at label setup in the following way: 1359 - it is actually a `DE-->PHB mapping' 1360 - the mapping is a function of the PSC which is carried on this 1361 LSP, and should use the relevant mapping entries for this PSC 1362 from the Default DE/PSC-->PHB Mapping defined in Section 1363 4.2.3.1. 1365 4.2.3.1 Default DE/PSC --> PHB Mapping 1367 DE Bit PSC PHB 1369 0 DF ----> DF 1370 0 CSn ----> CSn 1371 0 AFn ----> AFn1 1373 Le Faucheur et. al 27 1374 1 AFn ----> AFn2 1375 0 EF ----> EF 1377 4.3 Incoming PHB Determination On Incoming L-LSP 1379 This section defines how Incoming PHB determination is carried out 1380 when the considered label entry in the received label stack 1381 corresponds to an L-LSP. This requires that the `Encaps-->PHB 1382 mapping' is populated as defined above in section 4.2. 1384 When considering a label entry corresponding to an incoming L-LSP 1385 for Incoming PHB Determination, the LSR first determines the 1386 `Encaps-->PHB mapping' associated with the incoming top level label. 1388 4.3.1 `EXP-->PHB mapping' 1390 If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping', 1391 then the LSR: 1392 - determines the incoming PHB by looking at the EXP field of the 1393 considered label entry and by using the EXP-->PHB mapping. 1395 4.3.2 `CLP-->PHB mapping' 1397 If the `Encaps-->PHB mapping' is of the form `CLP-->PHB mapping', 1398 then the LSR: 1399 - determines the incoming PHB by looking at the CLP field of the 1400 ATM Layer encapsulation and by using the CLP-->PHB mapping. 1402 4.3.3 `DE-->PHB mapping' 1404 If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping', 1405 then the LSR: 1406 - determines the incoming PHB by looking at the DE field of the 1407 Frame Relay encapsulation and by using the DE-->PHB mapping. 1409 4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing L-LSP 1411 This section defines how the `Set of PHB-->Encaps mappings' of the 1412 Diff-Serv Context is populated for an outgoing L-LSP in order to 1413 allow Encoding of Diff-Serv Information. 1415 4.4.1 `PHB-->EXP mapping' 1417 If the LSR uses an MPLS Shim Layer over this outgoing L-LSP, then 1418 one `PHB-->EXP mapping' is added at label setup to the `Set of 1419 PHB-->Encaps mappings' in the Diff-Serv Context for this outgoing 1420 L-LSP. This `PHB-->EXP mapping' is populated in the following way: 1421 - it is a function of the PSC supported on this LSP, and must use 1422 the mapping entries relevant for this PSC from the Mandatory 1423 PHB-->EXP Mapping defined in section 4.4.1.1. 1425 Le Faucheur et. al 28 1426 For example if the outgoing label corresponds to an L-LSP supporting 1427 the AF1 PSC, then the following `PHB-->EXP mapping' is added into 1428 the `Set of PHB-->Encaps mappings': 1430 PHB EXP Field 1432 AF11 ----> 000 1433 AF12 ----> 001 1434 AF13 ----> 010 1436 4.4.1.1 Mandatory PHB-->EXP Mapping 1438 PHB EXP Field 1440 DF ----> 000 1441 CSn ----> 000 1442 AFn1 ----> 000 1443 AFn2 ----> 001 1444 AFn3 ----> 010 1445 EF ----> 000 1447 4.4.2 `PHB-->CLP mapping' 1449 If the L-LSP is egressing on an ATM interface (i.e. it is an ATM-LSR 1450 or it is a frame-based LSR sending packets on an LC-ATM interface or 1451 on an ATM interface which is not label switching controlled), then 1452 one `PHB-->CLP mapping' is added at label setup to the `Set of 1453 PHB-->Encaps mappings' in the Diff-Serv Context for this outgoing 1454 L-LSP. 1456 If the L-LSP is egressing over an LC-ATM interface, the `PHB-->CLP 1457 mapping' is populated in the following way: 1458 - it is a function of the PSC supported on this LSP, and should 1459 use the relevant mapping entries for this PSC from the Default 1460 PHB-->CLP Mapping defined in section 3.4.2.1. 1462 For example if the outgoing label corresponds to an L-LSP supporting 1463 the AF1 PSC, then the `PHB-->CLP mapping' should be populated with: 1465 PHB CLP Field 1467 AF11 ----> 0 1468 AF12 ----> 1 1469 AF13 ----> 1 1471 If the L-LSP is egressing over an ATM interface which is not label 1472 switching controlled, the `PHB-->CLP mapping' is populated in the 1473 following way: 1474 - it is a function of the PSC supported on this LSP, and may use 1475 the relevant mapping entries for this PSC from the Default 1476 PHB-->CLP Mapping defined in section 3.4.2.1. Other mappings 1477 than the one defined in section 3.4.2.1 may be used. In 1479 Le Faucheur et. al 29 1480 particular, if a mapping from PHBs to CLP is standardized in the 1481 future for operations of Diff-Serv over ATM, such standardized 1482 mapping may then be used. 1484 Notice that if the LSR is a frame-based LSR supporting an L-LSP 1485 egressing over an ATM interface, then the `Set of PHB-->Encaps 1486 mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP 1487 mapping'. If the LSR is an ATM-LSR supporting an L-LSP, then the 1488 `Set of PHB-->Encaps mappings' only contains a `PHB-->CLP mapping'. 1490 4.4.3 `PHB-->DE mapping' 1492 If the L-LSP is egressing over a Frame Relay interface (i.e. it is 1493 an LSR sending packets on an LC-FR interface or on a Frame Relay 1494 interface which is not label switching controlled), one `PHB-->DE 1495 mapping' is added at label setup to the `Set of PHB-->Encaps 1496 mappings' in the Diff-Serv Context for this outgoing L-LSP. 1498 If the L-LSP is egressing over an LC-FR interface, the `PHB-->DE 1499 mapping' is populated in the following way: 1500 - it is a function of the PSC supported on this LSP, and should 1501 use the relevant mapping entries for this PSC from the Default 1502 PHB-->DE Mapping defined in section 3.4.3.1. 1504 If the L-LSP is egressing over a FR interface which is not label 1505 switching controlled, the `PHB-->DE mapping' is populated in the 1506 following way: 1507 - it is a function of the PSC supported on this LSP, and may use 1508 the relevant mapping entries for this PSC from the Default 1509 PHB-->DE Mapping defined in section 3.4.3.1. Other mappings than 1510 the one defined in section 3.4.3.1 may be used. In particular, 1511 if a mapping from PHBs to DE is standardized in the future for 1512 operations of Diff-Serv over Frame Relay, such standardized 1513 mapping may then be used. 1515 Notice that if the LSR is an Edge-LSR supporting an L-LSP egressing 1516 over a LC-FR interface, then the `Set of PHB-->Encaps mappings' 1517 contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. If the 1518 LSR is a FR-LSR supporting an L-LSP, then the `Set of PHB-->Encaps 1519 mappings' only contains a `PHB-->DE mapping'. 1521 4.4.4 `PHB-->802.1 mapping' 1523 If the L-LSP is egressing over a LAN interface on which multiple 1524 802.1 Traffic Classes are supported as defined in [IEEE_802.1], then 1525 one `PHB-->802.1 mapping' is added at label setup to the `Set of 1526 PHB-->Encaps mappings' in the Diff-Serv Context for this outgoing 1527 L-LSP. This `PHB-->802.1 mapping' is populated in the following way: 1528 - it is a function of the PSC supported on this LSP, and uses the 1529 relevant mapping entries for this PSC from the Preconfigured 1530 `PHB-->802.1 mapping' defined above in section 3.4.4.1. 1532 Le Faucheur et. al 30 1533 Notice that if the LSR is supporting an L-LSP egressing over a LAN 1534 interface supporting multiple 802.1 Traffic Classes, then the `Set 1535 of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a 1536 `PHB-->802.1 mapping'. 1538 4.5 Encoding Diff-Serv Information into Encapsulation Layer on Outgoing 1539 L-LSP 1541 This section defines how to encode Diff-Serv information into the 1542 MPLS encapsulation Layer for a transmitted label entry corresponding 1543 to an outgoing L-LSP. This requires that the `Set of PHB-->Encaps 1544 mappings' is populated as defined above in section 4.4. 1546 The LSR first determines the `Set of PHB-->Encaps mappings' of the 1547 Diff-Serv Context associated with the corresponding label in the 1548 NHLFE. 1550 4.5.1 `PHB-->EXP mapping' 1552 If the `Set of PHB-->Encaps mappings' of the transmitted label 1553 contains a mapping of the form `PHB-->EXP mapping', then the LSR: 1554 - determines the value to be written in the EXP field of the 1555 corresponding level label entry by looking up the "outgoing PHB" 1556 in this PHB-->EXP mapping table. 1558 4.5.2 `PHB-->CLP mapping' 1560 If the `Set of PHB-->Encaps mappings' of the transmitted label 1561 contains a mapping of the form `PHB-->CLP mapping', then the LSR: 1562 - determines the value to be written in the CLP field of the ATM 1563 Layer encapsulation by looking up the "outgoing PHB" in this 1564 PHB-->CLP mapping table. 1566 4.5.3 `PHB-->DE mapping' 1568 If the `Set of PHB-->Encaps mappings' of the transmitted label 1569 contains a mapping of the form `PHB-->DE mapping', then the LSR: 1570 - determines the value to be written in the DE field of the Frame 1571 Relay encapsulation by looking up the "outgoing PHB" in this 1572 PHB-->DE mapping table. 1574 4.5.4 `PHB-->802.1 mapping' 1576 If the `Set of PHB-->Encaps mappings' of the transmitted label 1577 contains a mapping of the form `PHB-->802.1 mapping', then the LSR: 1578 - determines the value to be written in the User_Priority field of 1579 the Tag Control Information of the 802.1 encapsulation header 1580 [IEEE_802.1] by looking up the "outgoing PHB" in this 1581 PHB-->802.1 mapping table. 1583 4.6 L-LSP Merging 1585 Le Faucheur et. al 31 1586 In an MPLS domain, two or more LSPs can be merged into one LSP at 1587 one LSR. The proposed support of Diff-Serv in MPLS is compatible 1588 with LSP Merging under the following condition: 1590 L-LSPs can only be merged into one L-LSP if they support the 1591 same PSC. 1593 The above merge condition MUST be enforced by LSRs through explicit 1594 checking at label setup that the same PSC is supported on the merged 1595 LSPs. 1597 Note that when L-LSPs merge, the bandwidth that is available for the 1598 PSC downstream of the merge point must be sufficient to carry the 1599 sum of the merged traffic. This is particularly important in the 1600 case of EF traffic. This can be ensured in multiple ways (for 1601 instance via provisioning, or via bandwidth signaling and explicit 1602 admission control). 1604 5. RSVP Extension for Diff-Serv Support 1606 The MPLS architecture does not assume a single label distribution 1607 protocol. [RSVP_MPLS_TE] defines the extension to RSVP for 1608 establishing label switched paths (LSPs) in MPLS networks. This 1609 section specifies the extensions to RSVP, beyond those defined in 1610 [RSVP_MPLS_TE], to establish label switched path (LSPs) supporting 1611 Differentiated Services in MPLS networks. 1613 5.1 Diff-Serv related RSVP Messages Format 1615 One new RSVP Object is defined in this document: the DIFFSERV 1616 Object. Detailed description of this Object is provided below. This 1617 new Object is applicable to Path messages. This specification only 1618 defines the use of the DIFFSERV Object in Path messages used to 1619 establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus 1620 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 1621 and containing a LABEL_REQUEST object. 1623 Restrictions defined in [RSVP_MPLS_TE] for support of establishment 1624 of LSP Tunnels via RSVP are also applicable to the establishment of 1625 LSP Tunnels supporting Diff-Serv: for instance, only unicast LSPs 1626 are supported and Multicast LSPs are for further study. 1628 This new DIFFSERV object is optional with respect to RSVP so that 1629 general RSVP implementations not concerned with MPLS LSP set up do 1630 not have to support this object. 1632 The DIFFSERV Object is optional for support of LSP Tunnels as 1633 defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs 1634 using the preconfigured EXP<-->PHB mapping in compliance with this 1635 specification MAY support the DIFFSERV Object. A Diff-Serv capable 1636 LSR supporting E-LSPs using a signaled EXP<-->PHB mapping in 1638 Le Faucheur et. al 32 1639 compliance with this specification MUST support the DIFFSERV Object. 1640 A Diff-Serv capable LSR supporting L-LSPs in compliance with this 1641 specification MUST support the DIFFSERV Object. 1643 5.1.1 Path Message Format 1645 The format of the Path message is as follows: 1647 ::= [ ] 1648 1649 1650 [ ] 1651 1652 [ ] 1653 [ ] 1654 [ ... ] 1655 [ ] 1657 ::= [ ] 1658 [ ] 1659 [ ] 1661 5.2 DIFFSERV Object 1663 The DIFFSERV object formats are shown below. Currently there are two 1664 possible C_Types. Type 1 is a DIFFSERV object for an E-LSP. Type 2 1665 is a DIFFSERV object for an L-LSP. 1667 5.2.1. DIFFSERV object for an E-LSP: 1669 class = TBD, C_Type = 1 (need to get an official class num from the 1670 IANA with the form 0bbbbbbb) 1672 0 1 2 3 1673 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 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Reserved | MAPnb | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | MAP (1) | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | | 1680 // ... // 1681 | | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | MAP (MAPnb) | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 Reserved : 28 bits 1687 This field is reserved. It must be set to zero on transmission 1688 and must be ignored on receipt. 1690 MAPnb : 4 bits 1692 Le Faucheur et. al 33 1693 Indicates the number of MAP entries included in the DIFFSERV 1694 Object. This can be set to any value from 1 to 8. 1696 MAP : 32 bits 1697 Each MAP entry defines the mapping between one EXP field value 1698 and one PHB. The MAP entry has the following format: 1700 0 1 2 3 1701 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 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | Reserved | EXP | PHBID | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 Reserved : 13 bits 1707 This field is reserved. It must be set to zero on 1708 transmission and must be ignored on receipt. 1710 EXP : 3 bits 1711 This field contains the value of the EXP field for the 1712 EXP<-->PHB mapping defined in this MAP entry. 1714 PHBID : 16 bits 1715 This field contains the PHBID of the PHB for the 1716 EXP<-->PHB mapping defined in this MAP entry. The PHBID 1717 is encoded as specified in section 2 of [PHBID]. 1719 5.2.2 DIFFSERV object for an L-LSP: 1721 class = TBD, C_Type = 2 (class num is the same as DIFFSERV object 1722 for E-LSP)) 1724 0 1 2 3 1725 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 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | Reserved | PSC | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 Reserved : 16 bits 1731 This field is reserved. It must be set to zero on transmission 1732 and must be ignored on receipt. 1734 PSC : 16 bits 1735 The PSC indicates a PHB Scheduling Class to be supported by the 1736 LSP. The PSC is encoded as specified in section 2 of [PHBID]: 1737 - Where the PSC comprises a single PHB defined by standards 1738 action, the encoding for the PSC is the encoding for this 1739 single PHB. It is the recommended DSCP value for that PHB, 1740 left-justified in the 16-bit field, with bits 6 through 15 set 1741 to zero. 1742 - Where the PSC comprises multiple PHBs defined by standards 1743 action, the PSC encoding is the encoding for this set of PHB. 1744 It is the smallest numerical value of the recommended DSCP for 1746 Le Faucheur et. al 34 1747 the various PHBs in the PSC, left-justified in the 16 bit 1748 field, with bits 6 through 13 and bit 15 set to zero and with 1749 bit 14 set to one. 1751 For instance, the encoding of the EF PSC is : 1752 0 1 1753 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 |1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0| 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 For instance, the encoding of the AF1 PSC is : 1759 0 1 1760 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 |0 0 1 0 1 0|0 0 0 0 0 0 0 0 1 0| 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 5.3 Handling Diff-Serv Object 1767 To establish an LSP tunnel with RSVP, the sender creates a Path 1768 message with a session type of LSP_Tunnel_IPv4 and with a 1769 LABEL_REQUEST object as per [RSVP_MPLS_TE]. 1770 Where the sender supports Diff-Serv, to establish with RSVP an E-LSP 1771 tunnel which uses the Preconfigured EXP<-->PHB mapping, the sender 1772 creates a Path message: 1773 - with a session type of LSP_Tunnel_IPv4, 1774 - with the LABEL_REQUEST object, and 1775 - without the DIFFSERV object. 1777 Where the sender supports Diff-Serv, to establish with RSVP an E-LSP 1778 tunnel which uses a signaled EXP<-->PHB mapping, the sender creates 1779 a Path message : 1780 - with a session type of LSP_Tunnel_IPv4, 1781 - with the LABEL_REQUEST object, 1782 - with the DIFFSERV object for an E-LSP containing one MAP entry 1783 for each EXP value to be supported on this E-LSP. 1785 Where the sender supports Diff-Serv, to establish with RSVP an L-LSP 1786 tunnel, the sender creates a Path message: 1787 - with a session type of LSP_Tunnel_IPv4, 1788 - with the LABEL_REQUEST object, 1789 - with the DIFFSERV object for an L-LSP containing the PHB 1790 Scheduling Class (PSC) supported on this L-LSP. 1792 If a path message contains multiple DIFFSERV objects, only the first 1793 one is meaningful; subsequent DIFFSERV object(s) must be ignored and 1794 not forwarded. 1796 Each node along the path records the DIFFSERV object, when present, 1797 in its path state block. 1799 Le Faucheur et. al 35 1800 The destination node of an E-LSP or L-LSP responds to the Path 1801 message containing the LABEL_REQUEST object by sending a Resv 1802 message: 1803 - with the LABEL object 1804 - without a DIFFSERV object. 1806 Assuming the reservation is accepted and a label is associated with 1807 the reservation, the Diff-Serv LSRs (sender, destination, 1808 intermediate nodes) must: 1809 - update the Diff-Serv Context associated with the established 1810 LSPs in their ILM/FTN as specified in previous sections 1811 (incoming and outgoing label), 1812 - install the required Diff-Serv forwarding treatment (scheduling 1813 and dropping behavior) for this NHLFE (outgoing label). 1815 An RSVP router that does recognizes the DIFFSERV object and that 1816 receives a path message which contains the DIFFSERV object but which 1817 does not contain a LABEL_REQUEST object or which does not have a 1818 session type of LSP_Tunnel_IPv4, sends a PathErr towards the sender 1819 with the error code `Diff-Serv Error' and an error value of 1820 `Unexpected DIFFSERV object'. Those are defined below in section 1821 5.5. 1823 A node receiving a Path message with the DIFFSERV object for E-LSP, 1824 which recognizes the DIFFSERV object but does not support the 1825 particular PHB encoded in one, or more, of the MAP entries, sends a 1826 PathErr towards the sender with the error code `Diff-Serv Error' and 1827 an error value of `Unsupported PHB'. Those are defined below in 1828 section 5.5. 1830 A node receiving a Path message with the DIFFSERV object for E-LSP, 1831 which recognizes the DIFFSERV object but determines that the 1832 signaled EXP<-->PHB mapping is invalid, sends a PathErr towards the 1833 sender with the error code `Diff-Serv Error' and an error value of 1834 `Invalid EXP<-->PHB mapping'. Those are defined below in section 1835 5.5. The EXP<-->PHB mapping signaled in the DIFFSERV Object for an 1836 E-LSP is invalid when: 1837 - the MAPnb field is not within the range 1 to 8 or 1838 - a given EXP value appears in more than one MAP entry, or 1839 - the PHBID encoding is invalid. 1841 A node receiving a Path message with the DIFFSERV object for L-LSP, 1842 which recognizes the DIFFSERV object but does not support the 1843 particular PSC encoded in the PSC field, sends a PathErr towards the 1844 sender with the error code `Diff-Serv Error' and an error value of 1845 `Unsupported PSC'. Those are defined below in section 5.5. 1847 A Diff-Serv LSR MUST handle the situations where the reservation can 1848 not be accepted for other reasons than those already discussed in 1849 this section, in accordance with [RSVP_MPLS_TE] (eg. reservation 1850 rejected by admission control, a label can not be associated). 1852 Le Faucheur et. al 36 1853 5.4 Non-support of the Diff-Serv Object 1855 An RSVP router that does not recognize the DIFFSERV object Class-Num 1856 must behave in accordance with the procedures specified in [RSVP] 1857 for an unknown Class-Num whose format is 0bbbbbbb ie. it must send a 1858 PathErr with the error code `Unknown object class' toward the 1859 sender. 1861 An RSVP router that recognizes the DIFFSERV object Class-Num but 1862 does not recognize the DIFFSERV object C-Type, must behave in 1863 accordance with the procedures specified in [RSVP] for an unknown C- 1864 type ie. It must send a PathErr with the error code `Unknown object 1865 C-Type' toward the sender. 1867 In both situations, this causes the path set-up to fail. The sender 1868 should notify management that a L-LSP cannot be established and 1869 possibly take action to retry reservation establishment without the 1870 DIFFSERV object (eg. attempt to use E-LSPs with Preconfigured 1871 EXP<-->PHB mapping as a fall-back strategy). 1873 5.5 Error Codes For Diff-Serv 1875 In the procedures described above, certain errors must be reported 1876 as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error 1877 code is 26 (TBD). 1879 The following defines error values for the Diff-Serv Error: 1881 Value Error 1883 1 Unexpected DIFFSERV object 1884 2 Unsupported PHB 1885 3 Invalid EXP<-->PHB mapping 1886 4 Unsupported PSC 1888 5.6 Use of COS Service with E-LSPs and L-LSPs 1890 Both E-LSPs and L-LSPs can be established with bandwidth reservation 1891 or without bandwidth reservation. 1893 To establish an E-LSP or an L-LSP with bandwidth reservation, Int- 1894 Serv's Controlled Load service (or possibly Guaranteed Service) is 1895 used and the bandwidth is signaled in the SENDER_TSPEC (respectively 1896 FLOWSPEC) of the path (respectively Resv) message. 1898 To establish an E-LSP or an L-LSP without bandwidth reservation, the 1899 Class of Service service defined in [RSVP_MPLS_TE] is used. 1901 Note that this specification defines usage of E-LSPs and L-LSPs 1902 for support of the Diff-Serv service only. Regardless of whether the 1903 signaling messages actually indicate an Int-Serv service of COS, GS 1904 or CL and regardless of whether the signaling messages contain a 1906 Le Faucheur et. al 37 1907 signaled bandwidth reservation or not, E-LSPs and L-LSPs are defined 1908 here for support of Diff-Serv services. Support of Int-Serv services 1909 over an MPLS Diff-Serv backbone is outside the scope of this 1910 specification. 1912 A Path message containing a COS SENDER_TSPEC and not containing a 1913 DIFFSERV object indicates to a Diff-Serv capable LSR that the LSP to 1914 be established is an E-LSP using the Preconfigured mapping and 1915 without any bandwidth reservation. 1917 A Path message containing a COS SENDER_TSPEC and containing a 1918 DIFFSERV object for E-LSP indicates to a Diff-Serv capable LSR that 1919 the LSP to be established is an E-LSP using a signaled mapping and 1920 without any bandwidth reservation. 1922 A Path message containing a COS SENDER_TSPEC and containing a 1923 DIFFSERV object for L-LSP indicates to a Diff-Serv capable LSR that 1924 the LSP to be established is an L-LSP without any bandwidth 1925 reservation. 1927 The above is summarized in the following table: 1929 Path Message LSP type 1930 Service DIFFSERV 1931 Object 1933 GS/CL No E-LSP + preconf mapping + bandw reservation 1934 GS/CL Yes/E-LSP E-LSP + signaled mapping + bandw reservation 1935 GS/CL Yes/L-LSP L-LSP + bandw reservation 1936 COS No E-LSP + preconf mapping + no bandw reservation 1937 COS Yes/E-LSP E-LSP + signaled mapping + no band reservation 1938 COS Yes/L-LSP L-LSP + no bandw reservation 1940 Where: 1941 - GS stands for Guaranteed Service 1942 - CL stands for Controlled Load 1943 - COS stands for COS service 1945 When processing a path (respectively Resv) message for an E-LSP or 1946 an L-LSP using the COS service, a Diff-Serv capable LSR must ignore 1947 the value of the COS field within a COS SENDER_TSPEC (respectively a 1948 COS FLOWSPEC). 1950 6. LDP Extensions for Diff-Serv Support 1952 The MPLS architecture does not assume a single label distribution 1953 protocol. [LDP] defines the Label Distribution Protocol and its 1954 usage for establishment of label switched paths (LSPs) in MPLS 1955 networks. This section specifies the extensions to LDP to establish 1956 label switched path (LSPs) supporting Differentiated Services in 1957 MPLS networks. 1959 Le Faucheur et. al 38 1960 One new LDP TLV is defined in this document: 1961 - the Diff-Serv TLV 1962 Detailed description of this TLV is provided below. 1964 The new Diff-Serv TLV is optional with respect to LDP. A Diff-Serv 1965 capable LSR supporting E-LSPs which uses the Preconfigured 1966 EXP<-->PHB mapping in compliance with this specification MAY support 1967 the Diff-Serv TLV. A Diff-Serv capable LSR supporting E-LSPs which 1968 uses the signaled EXP<-->PHB mapping in compliance with this 1969 specification MUST support the Diff-Serv TLV. A Diff-Serv capable 1970 LSR supporting L-LSPs in compliance with this specification MUST 1971 support the Diff-Serv TLV. 1973 6.1 Diff-Serv TLV 1975 The Diff-Serv TLV has the following formats: 1976 Diff-Serv TLV for an E-LSP: 1978 0 1 2 3 1979 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 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 |U|F| Diff-Serv (0x901) | Length | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 |T| Reserved | MAPnb | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | MAP (1) | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 ... 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 | MAP (MAPnb) | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 T:1 bit 1994 LSP Type. This is set to 0 for an E-LSP 1996 Reserved : 27 bits 1997 This field is reserved. It must be set to zero on transmission 1998 and must be ignored on receipt. 2000 MAPnb : 4 bits 2001 Indicates the number of MAP entries included in the DIFFSERV 2002 Object. This can be set to any value from 1 to 8. 2004 MAP : 32 bits 2005 Each MAP entry defines the mapping between one EXP field value 2006 and one PHB. The MAP entry has the following format: 2008 0 1 2 3 2009 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 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 Le Faucheur et. al 39 2013 | Reserved | EXP | PHBID | 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 Reserved : 13 bits 2017 This field is reserved. It must be set to zero on 2018 transmission and must be ignored on receipt. 2020 EXP : 3 bits 2021 This field contains the value of the EXP field for the 2022 EXP<-->PHB mapping defined in this MAP entry. 2024 PHBID : 16 bits 2025 This field contains the PHBID of the PHB for the 2026 EXP<-->PHB mapping defined in this MAP entry. The PHBID 2027 is encoded as specified in section 2 of [PHBID]. 2029 Diff-Serv TLV for an L-LSP: 2031 0 1 2 3 2032 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 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 |U|F| Type = PSC (0x901) | Length | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 |T| Reserved | PSC | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 T:1 bit 2040 LSP Type. This is set to 1 for an L-LSP 2042 Reserved : 15 bits 2043 This field is reserved. It must be set to zero on transmission 2044 and must be ignored on receipt. 2046 PSC : 16 bits 2047 The PSC indicates a PHB Scheduling Class to be supported by the 2048 LSP. The PSC is encoded as specified in section 2 of [PHBID]: 2049 - Where the PSC comprises a single PHB defined by standards 2050 action, the encoding for the PSC is the encoding for this 2051 single PHB. It is the recommended DSCP value for that PHB, 2052 left-justified in the 16-bit field, with bits 6 through 15 set 2053 to zero. 2054 - Where the PSC comprises multiple PHBs defined by standards 2055 action, the PSC encoding is the encoding for this set of PHB. 2056 It is the smallest numerical value of the recommended DSCP for 2057 the various PHBs in the PSC, left-justified in the 16 bit 2058 field, with bits 6 through 13 and bit 15 set to zero and with 2059 bit 14 set to one. 2061 For instance, the encoding of the EF PSC is : 2062 0 1 2063 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2065 Le Faucheur et. al 40 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 |1 0 1 1 1 0|0 0 0 0 0 0 0 0 0 0| 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 For instance, the encoding of the AF1 PSC is : 2071 0 1 2072 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 |0 0 1 0 1 0|0 0 0 0 0 0 0 0 1 0| 2075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 6.2 Diff-Serv Status Code Values 2079 The following values are defined for the Status Code field of the 2080 Status TLV: 2082 Status Code E Status Data 2084 Unsupported PHB 0 0x00000016 2085 Invalid EXP<-->PHB mapping 0 0x00000017 2086 Unsupported PSC 0 0x00000018 2087 Unexpected Diff-Serv TLV 0 0x00000019 2089 6.3 Diff-Serv Related LDP Messages 2091 6.3.1 Label Request Message 2093 The format of the Label Request message is extended as follows, to 2094 optionally include the Diff-Serv TLV: 2096 0 1 2 3 2097 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 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 |0| Label Request (0x0401) | Message Length | 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | Message ID | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | FEC TLV | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | Diff-Serv TLV (optional) | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 6.3.2 Label Mapping Message 2110 The format of the Label Mapping message is extended as follows, to 2111 optionally include the Diff-Serv TLV: 2113 0 1 2 3 2114 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 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 |0| Label Mapping (0x0400) | Message Length | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 Le Faucheur et. al 41 2120 | Message ID | 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 | FEC TLV | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | Label TLV | 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 | Diff-Serv TLV (optional) | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 6.3.3 Label Release Message 2131 The format of the Label Release message is extended as follows, to 2132 optionally include the Status TLV: 2134 0 1 2 3 2135 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 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 |0| Label Release (0x0403) | Message Length | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 | Message ID | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | FEC TLV | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 | Label TLV (optional) | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 | Status TLV (optional) | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 6.3.4 Notification Message 2150 The format of the Notification message is extended as follows, to 2151 optionally include the Diff-Serv TLV: 2153 0 1 2 3 2154 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 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 |0| Notification (0x0001) | Message Length | 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | Message ID | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | Status TLV | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 | Optional Parameters | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | Diff-Serv TLV (optional) | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 6.4 Handling of the Diff-Serv TLV 2169 6.4.1 Handling of the Diff-Serv TLV in Downstream Unsolicited Mode 2171 Le Faucheur et. al 42 2172 This section describes operations when the Downstream Unsolicited 2173 Mode is used. 2175 When allocating a label for an E-LSP which is to use the 2176 preconfigured EXP<-->PHB mapping, a downstream Diff-Serv LSR issues 2177 a Label Mapping message without the Diff-Serv TLV. 2179 When allocating a label for an E-LSP which is to use a signaled 2180 EXP<-->PHB mapping, a downstream Diff-Serv LSR issues a Label 2181 Mapping message with the Diff-Serv TLV for an E-LSP which contains 2182 one MAP entry for each EXP value to be supported on this E-LSP. 2184 When allocating a label for an L-LSP, a downstream Diff-Serv LSR 2185 issues a Label Mapping message with the Diff-Serv TLV for an L-LSP 2186 which contains the PHB Scheduling Class (PSC) to be supported on 2187 this L-LSP. 2189 Assuming the label set-up is successful, the downstream and upstream 2190 LSRs must: 2191 - update the Diff-Serv Context associated with the established 2192 LSPs in their ILM/FTN as specified in previous sections 2193 (incoming and outgoing label), 2194 - install the required Diff-Serv forwarding treatment (scheduling 2195 and dropping behavior) for this NHLFE (outgoing label). 2197 An upstream Diff-Serv LSR receiving a Label Mapping message with 2198 multiple Diff-Serv TLVs only considers the first one as meaningful. 2199 The LSR must ignore and not forward the subsequent Diff-Serv TLV(s). 2200 An upstream Diff-Serv LSR which receives a Label Mapping message 2201 with the Diff-Serv TLV for an E-LSP and does not support the 2202 particular PHB encoded in one, or more, of the MAP entries, must 2203 reject the mapping by sending a Label Release message which includes 2204 the Label TLV and the Status TLV with a Status Code of `Unsupported 2205 PHB'. 2207 An upstream Diff-Serv LSR receiving a Label Mapping message with the 2208 Diff-Serv TLV for an E-LSP and determining that the signaled 2209 EXP<-->PHB mapping is invalid, must reject the mapping by sending a 2210 Label Release message which includes the Label TLV and the Status 2211 TLV with a Status Code of `Invalid EXP<-->PHB Mapping'. The 2212 EXP<-->PHB mapping signaled in the DIFFSERV Object for an E-LSP is 2213 invalid when: 2214 - the MAPnb field is not within the range 1 to 8, or 2215 - a given EXP value appears in more than one MAP entry, or 2216 - the PHBID encoding is invalid 2218 An upstream Diff-Serv LSR receiving a Label Mapping message with the 2219 Diff-Serv TLV for an L-LSP containing a PSC value which is not 2220 supported, must reject the mapping by sending a Label Release 2221 message which includes the Label TLV and the Status TLV with a 2222 Status Code of `Unsupported PSC'. 2224 Le Faucheur et. al 43 2225 6.4.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode 2227 This section describes operations when the Downstream on Demand Mode 2228 is used. 2230 When requesting a label for an E-LSP which is to use the 2231 preconfigured EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a 2232 Label Request message without the Diff-Serv TLV. 2234 When requesting a label for an E-LSP which is to use a signaled 2235 EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a Label Request 2236 message with the Diff-Serv TLV for an E-LSP which contains one MAP 2237 entry for each EXP value to be supported on this E-LSP. 2239 When requesting a label for an L-LSP, an upstream Diff-Serv LSR 2240 sends a Label Request message with the Diff-Serv TLV for an L-LSP 2241 which contains the PSC to be supported on this L-LSP. 2243 A downstream Diff-Serv LSR sending a Label Mapping message in 2244 response to a Label Request message for an E-LSP or an L-LSP must 2245 not include a Diff-Serv TLV in this Label Mapping message. 2246 Assuming the label set-up is successful, the downstream and upstream 2247 LSRs must: 2248 - update the Diff-Serv Context associated with the established 2249 LSPs in their ILM/FTN as specified in previous sections 2250 (incoming and outgoing label), 2251 - install the required Diff-Serv forwarding treatment (scheduling 2252 and dropping behavior) for this NHLFE (outgoing label). 2254 An upstream Diff-Serv LSR receiving a Label Mapping message 2255 containing a Diff-Serv TLV in response to its Label Request message, 2256 must reject the label mapping by sending a Label Release message 2257 which includes the Label TLV and the Status TLV with a Status Code 2258 of `Unexpected Diff-Serv TLV'. 2260 A downstream Diff-Serv LSR receiving a Label Request message with 2261 multiple Diff-Serv TLVs only considers the first one as meaningful. 2262 The LSR must ignore and not forward the subsequent Diff-Serv TLV(s). 2264 A downstream Diff-Serv LSR which receives a Label Request message 2265 with the Diff-Serv TLV for an E-LSP and does not support the 2266 particular PHB encoded in one (or more) of the MAP entries, must 2267 reject the request by sending a Notification message which includes 2268 the Status TLV with a Status Code of `Unsupported PHB'. 2270 A downstream Diff-Serv LSR receiving a Label Request message with 2271 the Diff-Serv TLV for an E-LSP and determining that the signaled 2272 EXP<-->PHB mapping is invalid, must reject the request by sending a 2273 Notification message which includes the Status TLV with a Status 2274 Code of `Invalid EXP<-->PHB Mapping'. The EXP<-->PHB mapping 2275 signaled in the DIFFSERV TLV for an E-LSP is invalid when: 2276 - the MAPnb field is not within the range 1 to 8, or 2278 Le Faucheur et. al 44 2279 - a given EXP value appears in more than one MAP entry, or 2280 - the PHBID encoding is invalid 2282 A downstream Diff-Serv LSR receiving a Label Request message with 2283 the Diff-Serv TLV for an L-LSP containing a PSC value which is not 2284 supported, must reject the request by sending a Notification message 2285 which includes the Status TLV with a Status Code of `Unsupported 2286 PSC'. 2288 A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in 2289 a Label Request message and supports the requested PSC but is not 2290 able to satisfy the label request for other reasons (eg. no label 2291 available), must send a Notification message in accordance with 2292 existing LDP procedures [LDP] (eg. with a `No Label Resource' Status 2293 Code). This Notification message must include the requested 2294 Diff-Serv TLV. 2296 6.5 Non-Handling of the Diff-Serv TLV 2298 An LSR that does not recognize the Diff-Serv TLV Type, on receipt of 2299 a Label Request message or a Label Mapping message containing the 2300 Diff-Serv TLV, must behave in accordance with the procedures 2301 specified in [LDP] for an unknown TLV whose U Bit and F Bit are set 2302 to 0 ie. it must ignore the message, return a Notification message 2303 with `Unknown TLV' Status. 2305 6.6 Bandwidth Information 2307 Bandwidth information may also be signaled at establishment time of 2308 E-LSP and L-LSP, for instance for the purpose of Traffic 2309 Engineering, using the Traffic Parameters TLV as described in 2310 [MPLS CR LDP]. 2312 7. MPLS Support of Diff-Serv over PPP interfaces 2314 The general operations for MPLS support of Diff-Serv, including 2315 label forwarding and LSP setup operations are specified in the 2316 previous sections. This section describes the specific operations 2317 required for MPLS support of Diff-Serv over PPP links. 2319 This document allows any of the following LSP combinations per FEC 2320 within an MPLS PPP Diff-Serv domain: 2322 - Zero or any number of E-LSP, and 2323 - Zero or any number of L-LSPs. 2325 7.1 LSR implementation with PPP interfaces 2327 A Diff-Serv capable LSR with PPP interfaces MUST support, over these 2328 PPP interfaces, E-LSPs which use the pre-configured EXP<-->PHB 2330 Le Faucheur et. al 45 2331 mapping, in compliance with all the material from this specification 2332 pertaining to those types of LSPs. 2334 A Diff-Serv capable LSR with PPP interfaces MAY support, over these 2335 PPP interfaces, E-LSPs which use a signaled EXP<-->PHB mapping. If a 2336 Diff-Serv LSR does support E-LSPs which use a signaled EXP<-->PHB 2337 mapping over PPP interfaces, then it MUST do so in compliance with 2338 all the material from this specification pertaining to those types 2339 of LSPs. 2341 A Diff-Serv capable LSR with PPP interfaces MAY support L-LSPs over 2342 these PPP interfaces. If a Diff-Serv LSR does support L-LSPs over 2343 PPP interfaces, then it MUST do so in compliance with all the 2344 material from this specification pertaining to L-LSPs. 2346 7.2 LSR implementation with non-LC ATM interfaces 2348 The E-LSP/L-LSP support requirements for an LSR running MPLS over a 2349 traditional ATM connection (ie. where the interface is not label 2350 switching controlled) are the same as those specified in section 7.1 2351 for an LSR with PPP interfaces. 2353 7.3 LSR implementation with non-LC FR interfaces 2355 The E-LSP/L-LSP support requirements for an LSR running MPLS over a 2356 traditional Frame Relay connection (ie. where the interface is not 2357 label switching controlled) are the same as those specified in 2358 section 7.1 for an LSR with PPP interfaces. 2360 8. MPLS Support of Diff-Serv over LC-ATM Interfaces 2362 The general operations for MPLS support of Diff-Serv, including 2363 label forwarding and LSP setup operations was specified in the 2364 previous sections. This section describes the specific operations 2365 required for MPLS support of Diff-Serv over label switching 2366 controlled ATM (LC-ATM) interfaces. 2368 This document allows any number of L-LSPs per FEC within an MPLS ATM 2369 Diff-Serv domain. E-LSPs are not supported over LC-ATM interfaces. 2371 8.1 Merging 2373 The use of merging is optional. In case that merging of ATM LSPs is 2374 used, procedures described in section 3.6 of this specification 2375 apply. Additionally, to avoid cell interleaving problems with AAL-5 2376 merging, procedures specified in [MPLS_ATM] MUST be followed. 2378 8.2 Use of ATM Traffic Classes and Traffic Management mechanisms 2380 The use of the ATM traffic classes as specified by ITU-T and ATM- 2381 Forum or of vendor specific ATM traffic classes is outside of the 2383 Le Faucheur et. al 46 2384 scope of this specification. The only requirement for compliant 2385 implementation is that the forwarding behavior experienced by a 2386 Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be 2387 compliant with the corresponding Diff-Serv PHB specifications. 2389 Since there is only one bit for encoding the PHB drop precedence 2390 value over ATM links, only two different drop precedence levels are 2391 supported in ATM LSRs. The behavior for AF MUST comply to procedures 2392 described in [DIFF_AF] for the case when only two drop precedence 2393 levels are supported. 2395 To avoid discarding parts of the packets, frame discard mechanisms, 2396 such as Early Packet Discard (EPD) SHOULD be enabled in the ATM-LSRs 2397 for all PHBs described in this document. 2399 8.3 LSR Implementation With LC-ATM Interfaces 2401 A Diff-Serv capable LSR with LC-ATM interfaces MUST support L-LSPs 2402 over these ATM interfaces in compliance with all the material from 2403 this specification pertaining to those types of LSPs. Additionally, 2404 procedures specified in [MPLS_ATM] MUST be followed by compliant 2405 implementation. 2407 This specification assumes that Edge-LSRs of the ATM-LSR domain use 2408 the "shim header" encapsulation method defined in [MPLS_ATM]. 2409 Operations without the "shim header" encapsulation is outside the 2410 scope of this specification. 2412 9. MPLS Support of Diff-Serv over LC-FR Interfaces 2414 The general operations for MPLS support of Diff-Serv, including 2415 label forwarding and LSP setup operations was specified in the 2416 previous sections. This section describes the specific operations 2417 required for MPLS support of Diff-Serv over label switching 2418 controlled Frame Relay (LC-FR) interfaces. 2420 This document allows any number of L-LSPs per FEC within an MPLS 2421 Frame Relay Diff-Serv domain. E-LSPs are not supported over LC-FR 2422 interfaces. 2424 9.1 Merging 2426 The use of merging is optional. In case that merging of Frame Relay 2427 LSPs is used, procedures described in section 3.6 of this 2428 specification apply as well as procedures in [MPLS_FR]. 2430 9.2 Use of Frame Relay Traffic parameters and Traffic Management 2431 mechanisms 2433 Le Faucheur et. al 47 2434 The use of the Frame Relay traffic parameters as specified by ITU-T 2435 and Frame Relay-Forum or of vendor specific Frame Relay traffic 2436 management mechanisms is outside of the scope of this specification. 2437 The only requirement for compliant implementation is that the 2438 forwarding behavior experienced by a Behavior Aggregate forwarded 2439 over an L-LSP by the Frame Relay LSR MUST be compliant with the 2440 corresponding Diff-Serv PHB specifications. 2442 Since there is only one bit for encoding the PHB drop precedence 2443 value over Frame Relay links, only two different drop precedence 2444 levels are supported in Frame Relay LSRs. The behavior for AF MUST 2445 comply to procedures described in [DIFF_AF] for the case when only 2446 two drop precedence levels are supported. 2448 9.3 LSR Implementation With LC-FR Interfaces 2450 A Diff-Serv capable LSR with LC-FR interfaces MUST support 2451 L-LSPs over these Frame Relay interfaces in compliance with all the 2452 material from this specification pertaining to those types of LSPs. 2453 Additionally, procedures specified in [MPLS_FR] MUST be followed by 2454 compliant implementation. 2456 This specification assumes that Edge-LSRs of the FR-LSR domain use 2457 the "generic encapsulation" method as recommended in [MPLS_FR]. 2458 Operations without the "generic encapsulation" is outside the scope 2459 of this specification. 2461 10. MPLS Support of Diff-Serv over LAN Interfaces 2463 The general operations for MPLS support of Diff-Serv, including 2464 label forwarding and LSP setup operations was specified in the 2465 previous sections. This section describes the specific operations 2466 required for MPLS support of Diff-Serv over LAN interfaces. 2468 This document allows the following set of LSP setup combinations per 2469 FEC over a LAN interface: 2471 - Zero or any number of E-LSP, and 2472 - Zero or any number of L-LSPs. 2474 10.1 LSR Implementation With LAN Interfaces 2476 A Diff-Serv capable LSR with LAN interfaces MUST support, over these 2477 LAN interfaces, E-LSPs which use the pre-configured EXP<-->PHB 2478 mapping, in compliance with all the material from this specification 2479 pertaining to those types of LSPs. 2481 A Diff-Serv capable LSR with LAN interfaces MAY support, over these 2482 LAN interfaces, E-LSPs which use a signaled EXP<-->PHB mapping. If a 2483 Diff-Serv LSR does support E-LSPs which use a signaled EXP<-->PHB 2484 mapping over LAN interfaces, then it MUST do so in compliance with 2486 Le Faucheur et. al 48 2487 all the material from this specification pertaining to those types 2488 of LSPs. 2490 A Diff-Serv capable LSR MAY support L-LSPs over LAN interfaces. If a 2491 Diff-Serv LSR does support L-LSPs over LAN interfaces, then it MUST 2492 do so in compliance with all the material from this specification 2493 pertaining to L-LSPs. 2495 11. Explicit Congestion Notification 2497 Explicit Congestion Notification is described in [ECN] and is 2498 proposed as an Experimental extension to the IP protocol. 2500 [MPLS_ECN] discusses deployment of ECN in an MPLS network using the 2501 Shim Header as the MPLS encapsulation. It demonstrates that, 2502 provided a given LSP is identified as ECN-capable or as non-ECN- 2503 capable (and consistently recognized as such by all the involved 2504 LSRs), then ECN can be supported in an MPLS domain where the Shim 2505 Header is used as the MPLS encapsulation via a single bit of the EXP 2506 field. 2508 The details of how a given LSP is to be identified as ECN-capable or 2509 non-ECN-capable (whether via extensions to the LSP establishment 2510 signaling and procedures, via configuration or via other means) are 2511 outside the scope of this specification. 2513 However, this specification recognizes that, within an ECN-capable 2514 MPLS domain where LSPs are identified as ECN-capable or not-ECN- 2515 capable: 2517 - Support of ECN does not require that any bit(s) from the EXP 2518 field be reserved for ECN operations across all LSPs even when 2519 those LSPs are not ECN-capable. Consequently, LSPs identified as 2520 non-ECN-capable (regardless of whether this is because at least 2521 one LSR on the LSP does not support ECN operations or whether 2522 this is because the network administrator does not wish to use 2523 ECN on this LSP) can make use of the full 3-bit EXP field for 2524 Diff-Serv purposes. Thus, non-ECN-capable E-LSPs and non-ECN- 2525 capable L-LSPs can operate as defined earlier in this document 2526 without any restriction imposed by the fact that the MPLS domain 2527 is ECN-capable. In particular, up to 8 BAs can still be 2528 transported over a non-ECN-capable E-LSP within an ECN-capable 2529 MPLS domain. Similarly, non-ECN-capable L-LSPs within an ECN- 2530 capable MPLS domain can support all the drop precedence levels 2531 of currently defined PSCs. Should a future PSC involve more than 2532 4 drop precedence levels, non-ECN-capable L-LSPs within an ECN- 2533 capable MPLS domain could still use the full 3-bit field EXP. 2535 - Because a single bit is required to encode the ECN information 2536 inside the ECN-capable MPLS domain, LSPs identified as ECN- 2537 capable can make use of two bits of the EXP field value for 2539 Le Faucheur et. al 49 2540 Diff-Serv purposes. In particular, up to 4 BAs can be 2541 transported over an ECN-capable E-LSP. Similarly, up to 4 drop 2542 precedence levels can be supported over an ECN-capable L-LSP; 2543 since all the PSCs corresponding to PHBs currently defined 2544 through standards action involve less than 4 drop precedence 2545 levels, ECN support does not currently restrict Diff-Serv 2546 operations over L-LSPs. Should a PSC corresponding to future 2547 PHBs defined by standards action or corresponding to local use 2548 or experimental PHBs, involve more than 4 drop precedence 2549 levels, then ECN support over the corresponding LSP would 2550 constrain the PSC to 4 drop precedence levels; relative benefits 2551 of additional precedence levels beyond 4, would then be weighted 2552 by the network administrator over the benefits of ECN, to 2553 determine whether it is preferable to support this PSC over an 2554 ECN-capable or non-ECN-capable LSP. 2556 11.1 MPLS ECN bit with Shim Header 2558 Where the Shim Header is used as the MPLS encapsulation, ECN 2559 information is to be encoded on ECN-capable LSPs in the first bit of 2560 the 3-bit EXP field in the following way: 2562 EXP field MPLS ECN Meaning 2564 0xx --> `ECT, not CE' 2565 1xx --> `not ECT, or ECT+CE' 2567 where ECT stands for `ECN Capable Transport' and `CE' stands for 2568 `Congestion experienced'. 2570 Detailed specification for usage of this MPLS ECN bit is outside the 2571 scope of this document. 2573 For ECN-capable LSPs, the mappings between EXP and PHB (be it the 2574 E-LSP Preconfigured Mapping specified in section 3.2.1, the E-LSP 2575 Signaled Mapping, the L-LSP Mappings defined in section 4.2.1.1 and 2576 4.4.1.1) are adjusted accordingly to only take into account the last 2577 2 bits of the 3-bit EXP field. 2579 Note that when the E-LSP signaled mapping is used on an ECN-capable 2580 E-LSP, the signaled mapping only needs to contain a single MAP entry 2581 for a given PHBID, which includes an EXP value with its first bit 2582 set to zero. 2584 For non-ECN-capable LSPs, the first bit of the 3-bit EXP field is 2585 NOT reserved for ECN and can be used to encode any Diff-Serv 2586 information. 2588 12. Security Considerations 2590 Le Faucheur et. al 50 2591 This document does not introduce any new security issues beyond 2592 those inherent in Diff-Serv, MPLS and RSVP, and may use the same 2593 mechanisms proposed for those technologies. 2595 13. Acknowledgments 2597 This document has benefited from discussions with K. K. 2598 Ramakrishnan, Eric Rosen, Angela Chiu and Carol Iturralde. It has 2599 also borrowed from the work done by D. Black regarding Diff-Serv and 2600 IP Tunnels interaction. 2602 APPENDIX A. Example Deployment Scenarios 2604 This section does not provide additional specification and is only 2605 here to provide examples of how this flexible approach for Diff-Serv 2606 support over MPLS may be deployed. Pros and cons of various 2607 deployment options for particular environments are beyond the scope 2608 of this document. 2610 A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no Fast 2611 Reroute 2613 A Service Provider running 8 (or fewer) BAs over MPLS, not 2614 performing Traffic engineering, not performing protection via Fast 2615 Reroute and using MPLS Shim Header encapsulation in his/her network, 2616 may elect to run Diff-Serv over MPLS using a single E-LSP per FEC 2617 established via LDP. Furthermore the Service Provider may elect to 2618 use the preconfigured EXP<-->PHB mapping. 2620 Operations can be summarized as follows: 2621 - the Service Provider configures at every LSR the bi-directional 2622 mapping between each PHB and a value of the EXP field 2623 (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) 2624 - the Service Provider configures at every LSR, and for every 2625 interface, the scheduling behavior for each PSC (eg bandwidth 2626 allocated to AF1) and the dropping behavior for each PHB (eg. 2627 drop profile for AF11, AF12, AF13) 2628 - LSRs signal establishment of a single E-LSP per FEC using LDP in 2629 accordance with the specification above (ie no Diff-Serv TLV in 2630 LDP Label Request/Label Mapping messages to implicitly indicate 2631 that the LSP is an E-LSP and that it uses the preconfigured 2632 mapping) 2634 A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no Fast 2635 Reroute 2637 A Service Provider running more than 8 BAs over MPLS, not performing 2638 Traffic Engineering and not performing protection via Fast Reroute 2640 Le Faucheur et. al 51 2641 and using MPLS Shim encapsulation in his/her network may elect to 2642 run Diff-Serv over MPLS using for each FEC: 2643 - one E-LSP established via LDP and using the preconfigured 2644 mapping to support a set of 8 (or less) BAs, AND 2645 - one L-LSP per established via LDP for support of the 2646 other BAs. 2648 Operations can be summarized as follows: 2649 - the Service Provider configures at every LSR the bi-directional 2650 mapping between each PHB and a value of the EXP field for the 2651 BAs transported over the E-LSP 2652 - the Service Provider configures at every LSR, and for every 2653 interface, the scheduling behavior for each PSC supported over 2654 the E-LSP and the dropping behavior for each corresponding PHB 2655 - the Service Provider configures at every LSR, and for every 2656 interface, the scheduling behavior for each PSC supported over 2657 the L-LSPs and the dropping behavior for each corresponding PHB 2658 - LSRs signal establishment of a single E-LSP per FEC for the set 2659 of E-LSP transported BAs using LDP as specified above (ie no 2660 Diff-Serv TLV in LDP Label Request/Label Mapping messages to 2661 implicitly indicate that the LSP is an E-LSP and that it uses 2662 the preconfigured mapping) 2663 - LSRs signal establishment of one L-LSP per for the 2664 other BAs using LDP as specified above (ie Diff-Serv TLV in LDP 2665 Label Request/Label Mapping messages to indicate the L-LSP's 2666 PSC). 2668 A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering, 2669 Aggregate Fast Reroute 2671 A Service Provider running 8 (or fewer) BAs over MPLS, performing 2672 aggregate Traffic Engineering (ie performing a single common path 2673 selection for all BAs), performing aggregate protection via Fast 2674 Reroute (ie performing Fast Reroute for all PSCs jointly) and using 2675 MPLS Shim Header encapsulation in his/her network, may elect to run 2676 Diff-Serv over MPLS using a single E-LSP per FEC established via 2677 RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] and using the 2678 preconfigured mapping. 2680 Operations can be summarized as follows: 2681 - the Service Provider configures at every LSR the bi-directional 2682 mapping between each PHB and a value of the EXP field 2683 (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) 2684 - the Service Provider configures at every LSR, and for every 2685 interface, the scheduling behavior for each PSC (eg bandwidth 2686 allocated to AF1) and the dropping behavior for each PHB (eg 2687 drop profile for AF11, AF12, AF13) 2688 - LSRs signal establishment of a single E-LSP per FEC which will 2689 use the preconfigured mapping: 2690 * using the RSVP protocol as specified above (ie no DIFFSERV 2691 RSVP Object in the PATH message containing the LABEL_REQUEST 2692 Object), OR 2694 Le Faucheur et. al 52 2695 * using the CR-LDP protocol as specified above (ie no Diff- 2696 Serv TLV in LDP Label Request/Label Mapping messages). 2698 A.4 Scenario 4: per-OA Traffic Engineering/Fast Reroute 2700 A Service Provider running any number of BAs over MPLS, performing 2701 per-OA Traffic Engineering (ie performing a separate path selection 2702 for each OA) and performing per-OA protection via Fast Reroute (ie 2703 performing protection with different Fast Reroute policies for the 2704 different OAs) in his/her network, may elect to run Diff-Serv over 2705 MPLS using one L-LSP per pair established via RSVP or 2706 CR-LDP. 2708 Operations can be summarized as follows: 2709 - the Service Provider configures at every LSR, and for every 2710 interface, the scheduling behavior for each PSC (eg bandwidth 2711 allocated to AF1) and the dropping behavior for each PHB (eg 2712 drop profile for AF11, AF12, AF13) 2713 - LSRs signal establishment of one L-LSP per : 2714 * using the RSVP as specified above to signal the 2715 L-LSP's PSC (ie DIFFSERV RSVP Object in the PATH message 2716 containing the LABEL_REQUEST), OR 2717 * using the CR-LDP protocol as specified above to 2718 signal the L-LSP PSC (ie Diff-Serv TLV in LDP Label 2719 Request/Label Mapping messages). 2721 A.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/Fast 2722 Reroute 2724 A Service Provider running 8 (or fewer) 8 BAs over MPLS, performing 2725 per-OA Traffic Engineering (ie performing a separate path selection 2726 for each OA) and performing per-OA protection via Fast Reroute (ie 2727 performing protection with different Fast Reroute policies for the 2728 different OAs) in his/her network, may elect to run Diff-Serv over 2729 MPLS using one E-LSP per pair established via RSVP or 2730 CR-LDP. Furthermore, the Service Provider may elect to use the 2731 preconfigured mapping on all the E-LSPs. 2733 Operations can be summarized as follows: 2734 - the Service Provider configures at every LSR the bi-directional 2735 mapping between each PHB and a value of the EXP field 2736 (eg. 000<-->AF11, 001<-->AF12, 010<-->AF13) 2737 - the Service Provider configures at every LSR, and for every 2738 interface, the scheduling behavior for each PSC (eg bandwidth 2739 allocated to AF1) and the dropping behavior for each PHB (eg 2740 drop profile for AF11, AF12, AF13) 2741 - LSRs signal establishment of one E-LSP per : 2742 * using the RSVP protocol as specified above to signal 2743 that the LSP is an E-LSP which uses the preconfigured mapping 2744 (ie no DIFFSERV RSVP Object in the PATH message containing the 2745 LABEL_REQUEST), OR 2747 Le Faucheur et. al 53 2748 * using the CR-LDP protocol as specified above to 2749 signal that the LSP is an E-LSP which uses the preconfigured 2750 mapping (ie no Diff-Serv TLV in LDP Label Request/Label Mapping 2751 messages) 2752 - the Service Provider configures, for each E-LSP, at the head-end 2753 of that E-LSP, a filtering/forwarding criteria so that only the 2754 packets belonging to a given OA are forwarded on the E-LSP 2755 established for the corresponding FEC and corresponding OA. 2757 A.6 Scenario 6: no Traffic Engineering/Fast Reroute on 8 BAs, per-OA 2758 Traffic Engineering/Fast Reroute on other BAs. 2760 A Service Provider not performing Traffic Engineering/Fast Reroute 2761 on 8 (or fewer) BAs, performing per-OA Traffic Engineering/Fast 2762 Reroute on the other BAs (ie performing a separate path selection 2763 for each OA corresponding to the other BAs and performing protection 2764 with a different policy for each of these OA) and using the MPLS 2765 Shim encapsulation in his/her network may elect to run Diff-Serv 2766 over MPLS, using for each FEC: 2767 - one E-LSP using the preconfigured mapping established via LDP to 2768 support the set of 8 (or fewer) non-traffic-engineered/non-fast- 2769 rerouted BAs, AND 2770 - one L-LSP per pair established via RSVP or CR-LDP for 2771 support of the other BAs. 2773 Operations can be summarized as follows: 2774 - the Service Provider configures at every LSR the bi-directional 2775 mapping between each PHB and a value of the EXP field for the 2776 BAs supported over the E-LSP 2777 - the Service Provider configures at every LSR, and for every 2778 interface, the scheduling behavior for each PSC supported over 2779 the E-LSP and the dropping behavior for each corresponding PHB 2780 - the Service Provider configures at every LSR, and for every 2781 interface, the scheduling behavior for each PSC supported over 2782 the L-LSPs and the dropping behavior for each corresponding PHB 2783 - LSRs signal establishment of a single E-LSP per FEC for the non- 2784 traffic engineered BAs using LDP as specified above (ie no Diff- 2785 Serv TLV in LDP Label Request/Label Mapping messages) 2786 - LSRs signal establishment of one L-LSP per for the 2787 other BAs: 2788 * using the RSVP protocol as specified above to signal 2789 the L-LSP PSC (ie DIFFSERV RSVP Object in the PATH message 2790 containing the LABEL_REQUEST Object), OR 2791 * using the CR-LDP protocol as specified above to 2792 signal the L-LSP PSC (ie Diff-Serv TLV in LDP Label 2793 Request/Label Mapping messages). 2795 A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no Fast 2796 Reroute 2798 A Service Provider running more than 8 BAs over MPLS, not performing 2799 Traffic engineering, not performing protection via Fast Reroute and 2801 Le Faucheur et. al 54 2802 using MPLS Shim Header encapsulation in his/her network, may elect 2803 to run Diff-Serv over MPLS using two E-LSPs per FEC established via 2804 LDP and using signaled EXP<-->PHB mapping. 2805 Operations can be summarized as follows: 2806 - the Service Provider configures at every LSR, and for every 2807 interface, the scheduling behavior for each PSC (eg bandwidth 2808 allocated to AF1) and the dropping behavior for each PHB (eg 2809 drop profile for AF11, AF12, AF13) 2810 - LSRs signal establishment of two E-LSPs per FEC using LDP in 2811 accordance with the specification above (ie Diff-Serv TLV in LDP 2812 Label Request/Label Mapping messages to explicitly indicate that 2813 the LSP is an E-LSP and its EXP<--> mapping). The signaled 2814 mapping will indicate the subset of 8 (or less) BAs to be 2815 transported on each E-LSP and what EXP values are mapped to each 2816 BA on each E-LSP. 2818 APPENDIX B. Example Bandwidth Reservation Scenarios 2820 B.1 Scenario 1: No Bandwidth Reservation 2822 Consider the case where a network administrator elects to: 2823 - have Diff-Serv resources entirely provisioned off-line (e.g. via 2824 Command Line Interface, via SNMP, via COPS,...) 2825 - have Shortest Path Routing used for all the Diff-Serv traffic. 2827 This is the closest model to provisioned Diff-Serv over non-MPLS IP. 2828 In that case, E-LSPs and/or L-LSPs would be established without 2829 signaled bandwidth. 2831 B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control 2833 Consider the case where a network administrator elects to: 2834 - have Diff-Serv resources entirely provisioned off-line (e.g. via 2835 Command Line Interface, via SNMP, via COPS,...) 2836 - use L-LSPs 2837 - have Constraint Based Routing performed separately for each PSC, 2838 where one of the constraints is availability of bandwidth from 2839 the bandwidth allocated to the relevant PSC. 2841 In that case, L-LSPs would be established with signaled bandwidth. 2842 The bandwidth signaled at L-LSP establishment would be used by LSRs 2843 to perform admission control at every hop to ensure that the 2844 constraint on availability of bandwidth for the relevant PSC is met. 2846 B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and 2847 per-PSC Resource Adjustment 2849 Consider the case where a network administrator elects to: 2850 - use L-LSPs 2852 Le Faucheur et. al 55 2853 - have Constraint Based Routing performed separately for each PSC, 2854 where one of the constraints is availability of bandwidth from 2855 the bandwidth allocated to the relevant PSC. 2856 - have Diff-Serv resources dynamically adjusted 2858 In that case, L-LSPs would be established with signaled bandwidth. 2859 The bandwidth signaled at L-LSP establishment would be used by LSRs 2860 to attempt to adjust the resources allocated to the relevant PSC 2861 (e.g. scheduling weight) and then perform admission control to 2862 ensure that the constraint on availability of bandwidth for the 2863 relevant PSC is met after the adjustment. 2865 References 2867 [MPLS_ARCH] Rosen et al., "Multiprotocol label switching 2868 Architecture", work in progress, (draft-ietf-mpls-arch-06.txt), 2869 August 1999. 2871 [MPLS_ATM] Davie et al., "MPLS using LDP and ATM VC Switching", work 2872 in progress, (draft-ietf-mpls-atm-03.txt), May 2000 2874 [MPLS_FR] Conta et al., "Use of Label Switching on Frame Relay 2875 Networks Specification", (draft-ietf-mpls-fr-04.txt), May 2000 2877 [DIFF_ARCH] Blake et al., "An architecture for Differentiated 2878 Services", RFC-2475, December 1998. 2880 [DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597, 2881 June 1999. 2883 [DIFF_EF] Jacobson et al., "An Expedited Forwarding PHB", RFC-2598, 2884 June 1999. 2886 [DIFF_HEADER] Nichols et al., "Definition of the Differentiated 2887 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474, 2888 December 1998. 2890 [ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion 2891 Notification (ECN) to IP", RFC-2481, January 1999. 2893 [MPLS_ECN] Ramakrishnan et al., "A Proposal to Incorporate ECN in 2894 MPLS", draft-ietf-mpls-ecn-00.txt, June 1999. 2896 [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 2897 06.txt, October 99 2899 [RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", 2900 draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, February 2000 2902 [CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using 2903 LDP", draft-ietf-mpls-cr-ldp-03.txt, October 1999 2905 Le Faucheur et. al 56 2907 [PHBID] Brim et al., "Per Hop Behavior Identification Codes" 2908 RFC 2836, May 2000 2910 [DIFF_NEW] Grossman, "New Terminology for Diffserv", draft-ietf- 2911 diffserv-new-terms-02.txt, November 99 2913 [IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 2914 Edition (Revision and redesignation of ISO/IEC 10038:98 2916 [ANSI/IEEE Std 802.1D, 1993 Edition], incorporating IEEE 2917 supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and 2918 P802.12e) 2920 [DIFF_TUNNEL] Black, "Differentiated Services and Tunnels", draft- 2921 ietf-diffserv-tunnels-00-txt, February 2000. 2923 [MPLS_VPN] Rosen et al., "BGP/MPLS VPNs", draft-rosen-rfc2547bis- 2924 00.txt, March 2000. 2926 Author's Addresses: 2928 Francois Le Faucheur 2929 Cisco Systems 2930 Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - 2931 France 2932 Phone: +33 4 92 96 75 64 2933 Email: flefauch@cisco.com 2935 Liwen Wu 2936 Cisco Systems 2937 250 Apollo Drive, Chelmsford, MA 01824, 2938 USA 2939 Phone: +1 (978) 244-3087 2940 Email: liwwu@cisco.com 2942 Bruce Davie 2943 Cisco Systems 2944 250 Apollo Drive, Chelmsford, MA 01824 2945 USA 2946 Phone: +1 (978) 244-8000 2947 Email: bsd@cisco.com 2949 Shahram Davari 2950 PMC-Sierra Inc. 2951 555 Legget drive, 2952 Suit 834, Tower B, 2953 Ottawa, ON K2K 2X3 2954 Canada 2955 Phone: +1 (613) 271-4018 2956 Email: shahram_davari@pmc-sierra.com 2958 Le Faucheur et. al 57 2959 Pasi Vaananen 2960 Nokia 2961 3 Burlington Woods Drive, Suit 250 2962 Burlington, MA 01803 2963 USA 2964 Phone +1 (781) 238-4981 2965 Email: pasi.vaananen@nokia.com 2967 Ram Krishnan 2968 Nexabit Networks 2969 200 Nickerson Road, 2970 Marlboro, MA 01752 2971 USA 2972 E-mail: ram@nexabit.com 2974 Pierrick Cheval 2975 Alcatel 2976 5 rue Noel-Pons 2977 92734 Nanterre Cedex 2978 France 2979 E-mail:pierrick.cheval@alcatel.fr 2981 Juha Heinanen 2982 Telia Finland 2983 E-mail: jh@lohi.eng.telia.fi 2985 Le Faucheur et. al 58