idnits 2.17.1 draft-lefaucheur-mpls-diff-ppp-00.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 ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** 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 138: '...ector Codepoints SHOULD be independent...' RFC 2119 keyword, line 140: '... Codepoints MAY be re-ordered". Thus...' RFC 2119 keyword, line 330: '...he Diff-Serv LSR SHALL apply the sched...' RFC 2119 keyword, line 824: '... his/her network MUST run Diff-Serv ov...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: 'TBD' is mentioned on line 566, but not defined ** Obsolete normative reference: RFC 2481 (ref. 'ECN') (Obsoleted by RFC 3168) -- Possible downref: Normative reference to a draft: ref. 'PHBID' Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 F. Le Faucheur 2 Cisco Systems 3 Shahram Davari 4 PMC-Sierra Inc. 5 Ram Krishnan 6 Nexabit Networks 7 Pasi Vaananen 8 Nokia 9 B. Davie 10 Cisco Systems 11 IETF Internet Draft 12 Expires: December, 1999 13 Document: draft-lefaucheur-mpls-diff-ppp-00.txt June, 1999 15 MPLS Support of Differentiated Services over PPP links 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are 21 Working documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet- Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document proposes a flexible solution for MPLS to support 39 Differentiated Services (Diff-Serv) over PPP links. 41 This solution allows the service provider to flexibly define how 42 Diff-Serv Behavior Aggregates (BAs) are mapped onto LSPs so that 43 he/she can best match the Diff-Serv and Traffic Engineering 44 objectives within his/her particular network. For instance, this 45 solution allows the service provider to decide whether sets of BAs 46 are to be mapped onto the same LSP or mapped onto separate LSPs. 48 This solution relies on combined use of two types of LSPs: 49 - LSPs where the Behavior Aggregate's scheduling treatment is 50 inferred by the LSR from the packet's label value while the Behavior 52 Le Faucheur, et. al 1 53 MPLS Support of DiffServ over PPP June 99 55 Aggregate's drop precedence is indicated in the EXP field of the 56 MPLS PPP Header. 57 - LSPs where both the Behavior Aggregate's scheduling treatment 58 and drop precedence are conveyed to the LSR in the EXP field of the 59 MPLS PPP Header. 61 1. Introduction 63 In an MPLS domain [MPLS_ARCH], when a stream of data traverses a 64 common path, a Label Switched Path (LSP) can be established using 65 MPLS signaling protocols. At the ingress Label Switch Router (LSR), 66 each packet is assigned a label and is transmitted downstream. At 67 each LSR along the LSP, the label is used to forward the packet to 68 the next hop. 70 In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the 71 IP packets crossing a link and requiring the same Diff-Serv behavior 72 are said to constitute a Behavior Aggregate (BA). At the ingress 73 node of the Diff-Serv domain the packets are classified and marked 74 with a Diff-Serv Code Point (DSCP) which corresponds to their 75 Behavior Aggregate. At each transit node, the DSCP is used to select 76 the Per Hop Behavior (PHB) that determines the scheduling treatment 77 and, in some cases, drop probability for each packet. 79 This document proposes a solution for supporting the Diff-Serv 80 Behavior Aggregates whose corresponding PHBs are currently defined 81 (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network, where 82 LSRs are interconnected via PPP links. 84 As mentioned in [DIFF_HEADER], "Service providers are not required 85 to use the same node mechanisms or configurations to enable service 86 differentiation within their networks, and are free to configure the 87 node parameters in whatever way that is appropriate for their 88 service offerings and traffic engineering objectives". Thus, the 89 solution proposed in this document aims at allowing Service 90 Providers the flexibility to select how Diff-Serv classes of service 91 should be Routed or Traffic Engineered within their domain (eg. 92 separate classes of services supported via separate LSPs and 93 Routed separately, all classes of service supported on the same LSP 94 and Routed or Traffic Engineered together). 96 Beside, the solution proposed in this document aims at maximizing 97 label space usage and minimizing the volume of label set-up/tear- 98 down signaling where possible by only mandating set-up of multiple 99 LSPs for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when 100 useful or required. 102 1.1. Ordering Constraints, "Scheduling Aggregate (SA)" and "Per Hop 103 Scheduling (PHS) " 105 [DIFF_AF] states that "a DS node does not reorder IP packets of the 106 same microflow if they belong to the same AF class" (even if 108 Le Faucheur et. al 2 109 MPLS Support of DiffServ over PPP June 99 111 different packets of the microflow contain different AF codepoints 112 of the same AF class). 114 For the sake of generality, we define a set of Behavior Aggregates 115 which share such an ordering constraint to constitute a "Scheduling 116 Aggregate_ (SA). The mechanisms described in this draft aim, in 117 particular, to preserve the correct ordering relationships for 118 packets that belong to a given SA. 120 We refer to the set of one or more PHBs applied to the set of 121 Behavior Aggregates forming a given SA, as a _Per Hop Scheduling_ 122 (PHS). 124 The PHBs currently specified are Default PHB (DF), Class Selector 125 PHB group (CSx), Assured Forwarding PHB group (AFxy), Expedited 126 Forwarding PHB (EF). 128 1.1.1 DF PHS 130 The Default PHB is a single PHB specified in [DIFF_Header]. Thus, 131 the corresponding PHS comprises a single PHB and thus coincides with 132 the DF PHB. 134 1.1.2 CSn PHS 136 [DIFF_HEADER] defines up to 8 CS Codepoints referred to as CSn, 137 where 1 <= i <= 8. [DIFF_HEADER] states that "... PHBs selected by 138 distinct Class Selector Codepoints SHOULD be independently 139 forwarded; that is, packets marked with different Class Selector 140 Codepoints MAY be re-ordered". Thus, there is one PHS corresponding 141 to each CSn PHB. Each CSn PHS comprises a single PHB and thus 142 coincides with this CSn PHB. 144 1.1.3 AFCn PHS 146 As described in [DIFF_AF], the Assured Forwarding (AF) PHB group 147 provides forwarding of IP packets in N independent AF classes. 148 Within each AF class, an IP packet is assigned one of M different 149 levels of drop precedence. An IP packet that belongs to an AF class 150 i and has drop precedence j is marked with the AF codepoint AFij, 151 where 1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4) 152 with three levels of drop precedence in each class (M=3) are 153 defined for general use. 155 [DIFF_AF] states that "a DS node does not reorder IP packets of the 156 same microflow if they belong to the same AF class" (even if 157 different packets of the microflow contain different AF codepoints 158 of the same AF class). As noted above, each AF class in the AF PHB 159 group is the primary example of a PHS. Each PHS comprises 3 PHBs and 160 coincides with the AF Class. Those PHSs are thus referred to as 161 AFCn, where 1 <= n <= 4. 163 Le Faucheur et. al 3 164 MPLS Support of DiffServ over PPP June 99 166 1.1.4 EF PHS 168 [DIFF_EF] defines the Expedited Forwarding (EF) PHB for traffic 169 requiring forwarding with low loss, low latency, low jitter. 170 [DIFF_EF] defines a single PHB. Thus, the corresponding PHS 171 comprises a single PHB and thus coincides with the DF PHB. 173 1.1.5 Summary list of PHS 175 The following PHSs have thus been identified: 176 - DF 177 - CSn , 1 <= i <= 8 178 - AFCn, 1 <= i <= 4 179 - EF 181 1.2 Label-Inferred-PHS LSPs (L-LSP) 183 We propose below, in section 2, a method for Diff-Serv over MPLS 184 over PPP where one LSP is established per pair between two 185 PPP LSR neighbours. 187 This method relies on explicit signaling of the PHS at label 188 establishment time so that, after label establishment, the LSR can 189 infer from the label value the PHS to be applied to a labeled 190 packets. Drop Precedence to be applied by the LSR to the labeled 191 packet is conveyed inside the packet MPLS Shim Header [MPLS_ENCAPS] 192 using the EXP field. 194 We refer to such LSPs as " Label-Inferred-PHS LSPs" (L-LSP). 195 Detailed Operation of L-LSPs is specified in section 2 below. 197 L-LSPs offer the following benefits: 198 - they support any number of Behavior Aggregates allowed by the 199 Diff-Serv architecture, and 200 - they support separate routing/traffic-engineering of PHSs. 202 L-LSPs have the following drawbacks: 203 - they require the use of separate LSPs for support of 204 different PHSs, and 205 - they require more signaling operations to set up these 206 L-LSPs. 208 1.3 EXP-Inferred-PHS LSPs (E-LSP) 210 We propose below, in section 3, a method where up to eight BAs can 211 be supported via a single LSP, regardless of how many SAs these BAs 212 span. In this method, the DSCP value get entirely mapped into the 213 EXP field of the MPLS Shim Header [MPLS_ENCAPS] at the Edge of the 214 MPLS PPP Cloud (thus encoding both drop precedence and 215 PHS/scheduling information). In other words, both PHS and Drop 217 Le Faucheur et. al 4 218 MPLS Support of DiffServ over PPP June 99 220 Precedence are conveyed in each labeled packet using the EXP field 221 of the MPLS Shim Header [MPLS_ENCAPS]. 223 We refer to such LSPs as "EXP-inferred-PHS LSPs" (E-LSP). Detailed 224 Operation of E-LSPs is specified in section 3 below. 226 E-LSPs have the following benefits, where separate routing or 227 separate traffic-engineering of PHSs is not required: 228 - label space is conserved by "packing" up to eight BAs per 229 label (eg. when there are fewer than eight BAs in the network, this 230 method maintains the same label space as in a non Diff-Serv capable 231 network). 232 - label establishment signaling is reduced since a single LSP 233 is established for up to eight BAs (eg. when there are fewer than 234 eight BAs in the network, this method maintains the same level of 235 signaling as in a non-Diff-Serv capable network) 236 -the amount of forwarding state is reduced, as a single 237 forwarding entry can support up to 8 BAs. 238 - operation of Diff-Serv MPLS over E-LSPs is analogous to 239 operations of Diff-Serv in non-MPLS networks in the sense that the 240 Diff-Serv PHB is triggered exclusively by a field explicitly encoded 241 in every packet based on locally configured PHB mapping. This is 242 expected to facilitate migration from non-MPLS Diff-Serv to MPLS 243 Diff-Serv operations in some networks. 244 - some early implementations of E-LSPs exist today and 245 experiments have confirmed proper operations and usefulness. 247 E-LSPs have the following drawbacks: 248 - they only support up to eight BAs, and 249 - they do not allow routing/traffic-engineering of individual 250 PHSs. 252 1.4 Overall Approach 254 We propose a flexible solution for Diff-Serv support by MPLS over 255 PPP links where the Service Provider can use both E-LSPs and L-LSPs 256 in the combination that best match his/her environment and 257 objectives in terms of Diff-Serv support and Traffic Engineering. 259 For instance, a Service Provider who: 260 - supports fewer than eight BAs, and 261 - does not perform traffic engineering or performs aggregate 262 traffic engineering of all SAs jointly, 263 may use a single E-LSP per FEC. 265 A Service Provider who: 266 - performs traffic engineering of each SA separately 267 may use one L-LSP per . 269 A Service Provider who 270 - supports more than eight BAs, and 272 Le Faucheur et. al 5 273 MPLS Support of DiffServ over PPP June 99 275 - does not perform traffic engineering or performs traffic 276 engineering of traffic aggregates where one traffic aggregate 277 comprises multiple SAs, 278 may use: 279 - a single E-LSP per FEC for supporting up to eight BAs (BAs 280 corresponding to SAs that can be traffic engineered jointly) 281 - one L-LSP per for supporting other. 283 Those are just examples of how a Service Provider can use 284 combinations of E-LSPs and L-LSPs to best match his/her environment. 285 Clearly, other combinations could be used in the environments 286 described above and other environments can also be supported. 288 When selecting a combination of E-LSPs and L-LSPs to meet some 289 specific Traffic Engineering goals, it is important to note that: 290 - SAs supported by the same E-LSP can be Traffic Engineered 291 jointly. A path is selected for the BAs of all the supported SAs (eg 292 by Constraint Based Routing or by explicit configuration) and the 293 corresponding E-LSP is then established along that path via RSVP or 294 CR-LDP signaling; 295 - SAs supported by the same E-LSP CANNOT be Traffic Engineered 296 separately. Since the BAs of all the transported SAs are to be label 297 switched via the same LSP, all these SAs follow a single path; 298 - SAs supported by separate L-LSPs can be Traffic Engineered 299 separately. A path is selected independently for each SA (eg by 300 Constraint Based Routing or by explicit configuration) and the 301 corresponding L-LSPs are then established independently via RSVP or 302 CR-LDP signaling; 303 - SAs supported by separate L-LSPs can be Traffic Engineered 304 jointly. A path is selected for the aggregate of all the considered 305 SAs and the L-LSPs are then established independently along the same 306 common path via RSVP or CR-LDP signaling; 308 1.5 Explicit Congestion Notification 310 Explicit Congestion Notification is described in [ECN] and is 311 proposed as an Experimental extension to the IP protocol. Because 312 ECN is still at the Experimental stage and its impact and 313 interactions with Diff-Serv have not yet been specified, this 314 Internet-Draft does not discuss ECN operations. Support for 315 simultaneous Diff-Serv and ECN over MPLS is left for further study. 317 1.6 Label Forwarding Model for Diff-Serv LSRs 319 In order to describe Label Forwarding by Diff-Serv LSRs, we propose 320 to model a Diff-Serv label switching behavior as comprising three 321 stages: 322 -A- incoming PHB and FEC determination 323 -B- Optional outgoing PHB determination via Local Policy and 324 Traffic Conditioning 325 -C- Outgoing EXP field and label determination 327 Le Faucheur et. al 6 328 MPLS Support of DiffServ over PPP June 99 330 The Diff-Serv LSR SHALL apply the scheduling/dropping behavior 331 corresponding to the _Outgoing PHB_ in compliance with the 332 corresponding Diff-Serv PHB specification. 334 With such a model, we expect that "Diff-Serv over MPLS" label 335 forwarding can be specified (from the Diff-Serv viewpoint) 336 separately for each method (eg. Diff-Serv over MPLS over PPP using 337 L-LSPs, Diff-Serv over MPLS over PPP using E-LSPs, Diff-Serv over 338 MPLS over ATM/FR) by specifying -A- and -C- for the considered 339 method without having to specify the complete label switching 340 behavior (A+B+C) for every possible incoming/outgoing combination. 342 This model is used below for specifying LSR Label Forwarding over 343 PPP links using L-LSPs and E-LSPs for Diff-Serv support over MPLS. 345 2. Detailed Operation of L-LSPs 347 This section is based on [MPLS_DIFF_PPP]. 349 2.1 L-LSP Establishment 351 Recognizing that: 353 - MPLS over PPP links requires the use of a Shim Header which 354 consists of a label stack with one or more entries [MPLS_ENCAPS]; 356 - The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER], so 357 that when more than 8 BAs are used , the DSCP field can not be 358 mapped entirely into the 3-bit long EXP field of the MPLS label 359 stack entry; 361 - Some Service Providers have a requirement for fine grain 362 Traffic Engineering (such as per SA Traffic Engineering) 364 We propose that: 366 - All packets belonging to a single SA and the same Forwarding 367 Equivalent Class (FEC) be sent down a single LSP; 369 - One LSP be established per pair (rather than simply 370 one LSP per FEC as in an MPLS network that does not support Diff- 371 Serv). Such an LSP is referred to as a "Label-inferred-PHS" LSP or 372 "L-LSP"; 374 - Multiple BAs belonging to the same SA be granted different Drop 375 Precedence (DP) values through appropriate coding of the EXP field 376 of the top label entry of the shim header. 378 MPLS specifies how LSPs can be established via multiple signaling 379 protocols. Those include the Label Distribution Protocol (LDP), 380 RSVP, BGP and PIM. This Internet-Draft proposes below, in section 382 Le Faucheur et. al 7 383 MPLS Support of DiffServ over PPP June 99 385 2.5, the required extensions to LDP and RSVP to allow establishment 386 of one L-LSP per pair over PPP MPLS. 388 2.2 Label Forwarding 390 2.2.1 Incoming PHB and FEC Determination On Ingress L-LSP 392 When receiving a labeled packet over an L-LSP of an MPLS PPP ingress 393 interface, the LSR: 394 - determines the FEC based on the incoming label 395 - determines the PHS from the incoming label among the set of 396 LSPs established for that FEC 397 - determines the incoming PHB from the PHS and the EXP field of 398 the top level label entry in accordance with the PHS/EXP-->PHB 399 mapping defined below in section 2.3. 401 If the EXP field value of a packet received on an L-LSP is such that 402 the PHS/EXP combination is not listed in the mapping of section 2.3, 403 this PHS/EXP combination should be considered invalid. LSR behavior 404 in such situation is a local matter and is outside the scope of this 405 document. 407 2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic 408 Conditioning 410 This stage of Diff-Serv label switching is independent of the 411 ingress/egress interface media type and method used for MPLS Diff- 412 Serv support. It is optional and may be used on an LSR to perform 413 Behavior Aggregate demotion or promotion inside an MPLS Diff-Serv 414 domain. For the purpose of specifying a Diff-Serv over MPLS method, 415 we simply note that the PHB to be actually enforced by an LSR 416 (referred to as "outgoing PHB") may be different to the PHB which 417 had been associated with the packet at the previous LSR (referred to 418 as "incoming PHB"). 420 2.2.3 Outgoing EXP Field and Label Determination on Egress L-LSP 422 Once the outgoing PHB has been determined by the LSR as a function 423 of the incoming PHB and of the optional Local Policy and Traffic 424 Conditioning, the LSR: 425 - determines via local configuration that the outgoing PHB is 426 one of the PHBs supported by a L-LSP and determines the egress 427 L-LSP label for the packet's FEC 428 - determines the value to be written in the EXP field of the 429 top level label entry (and possibly of other level label entries in 430 the case of a hierarchical tunnel entry) by performing the outgoing 431 PHB-->EXP/PHS mapping defined below in section 2.4. 433 2.2.4 Simplified Forwarding 435 Le Faucheur et. al 8 436 MPLS Support of DiffServ over PPP June 99 438 When Local Policy and Traffic Conditioning are not to be performed 439 by the LSR, and when the labeled packet is received on a L-LSP PPP 440 interface and is going out onto a L-LSP PPP interface, the 441 Forwarding operation is simplified since: 442 - the EXP field does not need to be modified 443 - the outgoing label can be directly determined from the 444 incoming label (ie as in non Diff-Serv capable LSRs) 446 2.3 PHS/EXP --> PHB Mapping 448 The mapping from L-LSP PHS and from EXP field of the shim header 449 into PHBs is as follows: 451 EXP Field PHS PHB 453 000 DF -----> DF 454 000 CSn -----> CSn 455 000 AFCn -----> AFn1 456 001 AFCn -----> AFn2 457 010 AFCn -----> AFn3 458 000 EF -----> EF 460 2.4 PHB --> PHS/EXP Mapping 462 The mapping from PHBs into the L-LSP PHS and the EXP field of the 463 shim header is as follows: 465 PHB EXP Field PHS 467 DF -----> 000 DF 468 CSn -----> 000 CSn 469 AFn1 -----> 000 AFCn 470 AFn2 -----> 001 AFCn 471 AFn3 -----> 010 AFCn 472 EF -----> 000 EF 474 2.5 L-LSP Establishment and Message Format 476 2.5.1 Signaling extension during L-LSP establishment 478 To support Diff-Serv in MPLS over PPP using L-LSPs, the PHS must be 479 signaled at label establishment time in the MPLS label request 480 messages and MPLS label binding messages. The detailed format of the 481 corresponding message extension is described below when the 482 signaling protocol used is LDP or RSVP. The MPLS control application 483 on each LSR along the L-LSP will process the new PHS attribute and 484 install the corresponding scheduling behavior for that LSP (eg. map 485 the LSP into an output queue associated with the PHS). 487 Le Faucheur et. al 9 488 MPLS Support of DiffServ over PPP June 99 490 2.5.2 Merging 492 In an MPLS domain, two or more LSPs can be merged into one LSP at 493 one LSR. The proposed support of Diff-Serv in MPLS over PPP is 494 compatible with LSP Merging under the following condition: 496 L-LSPs can only be merged into one L-LSP if they are associated with 497 the same PHS. 499 Note that when L-LSPs merge, the bandwidth that is available for the 500 PHS downstream of the merge point must be sufficient to carry the 501 sum of the merged traffic. This is particularly important in the 502 case of EF traffic. 504 2.5.3 New RSVP Object Format 506 This section defines a new RSVP object class and a new RSVP object 507 within that class for support of Diff-Serv in MPLS over PPP when 508 L-LSPs are established via RSVP [MPLS_RSVP]. 510 The new object Class is defined as the "Class Of Service" Class (COS 511 Class). Its Class-Num is [TBD]. 513 The new RSVP DIFFSERV_PHS object is defined within the COS Class to 514 carry the PHS of the traffic to be transported on the corresponding 515 LSP. Its C-Type is 1. 517 As described in [MPLS_RSVP], bandwidth information may also be 518 signaled at LSP establishment time, for the purpose of Traffic 519 Engineering, using the SENDER_TSPEC Object (in the Path message) and 520 the FLOWSPEC Object (in the Resv message). 522 DIFFSERV_PHS object Class = [TBD], C-Type = 1 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Length = 4 | Class-Num | C-Type | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Reserved | PHS | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 We propose that the 16-bit PHS be encoded as specified in section 2 533 of [PHBID]. In particular, we propose that the encoding for a PHS be 534 the smallest numerical value of the encodings for the various PHBs 535 in the PHS. In turn, the encoding of a single PHB defined by 536 standards action is the recommended DSCP value for this PHB, left- 537 justified in the 16 bit field, with bits 6 through 15 set to zero. 539 Le Faucheur et. al 10 540 MPLS Support of DiffServ over PPP June 99 542 For instance, the encoding of the AFC1 PHS is the encoding of the 543 AF11 PHB. 545 This object may be carried in a PATH message that contains the 546 LABEL_REQUEST object to indicate the PHS for which a label is 547 required. The object may also be carried in a RESV message that 548 contains a LABEL object indicating the PHS for which the label is to 549 be used. 551 2.5.4 New LDP TLV 553 This section defines a new LDP TLV necessary for support of Diff- 554 Serv in MPLS over PPP when L-LSPs are established via LDP 555 [MPLS_LDP]. We define a new PHS TLV to signal the PHS in a label 556 request or label binding as follows: 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 |U|F| Type = PHS | Length = 2 | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | PHS | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 The Type of the TLV is [TBD]. 568 Encoding of the PHS field is the same as encoding of the PHS in 569 RSVP, as specified in 2.5.3. 571 We propose that the COS TLV which was specified in [LDP_03] (and 572 removed in later version of the LDP specifications) be 573 reincorporated into LDP and used to encode the PHS TLV as a nested 574 TLV (ie encode the PHS TLV in the COS value of the COS TLV). 575 Encoding the PHS TLV as a nested TLV of the COS TLV is proposed for 576 flexibility so that if additional TLVs need to be defined in the 577 future for support of Diff-Serv over MPLS, those TLVs could be 578 logically grouped inside the COS TLV. 580 Alternatively, the PHS TLV could be included in the LDP messages as 581 an independent TLV (ie not nested in the COS TLV). 583 As described in [MPLS_CR_LDP], bandwidth information may also be 584 signaled at LSP establishment time, for the purpose of Traffic 585 Engineering, using the Traffic Parameters TLV. 587 3 Detailed Operations of E-LSPs 589 3.1 E-LSP establishment 591 Recognizing that: 593 Le Faucheur et. al 11 594 MPLS Support of DiffServ over PPP June 99 596 - MPLS over PPP links requires the use of a Shim Header which 597 consists of a label stack with one or more entries [MPLS_ENCAPS]; 599 - The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER] but 600 when 8 (or less) BAs are used, the DSCP values can be mapped 601 entirely into the 3-bit long EXP field of the MPLS label stack 602 entry; 604 - Some Service Providers do not have requirements for fine 605 grain Traffic Engineering and want to traffic engineer all/multiple 606 SAs jointly. 608 We propose that: 610 - One LSP be established per Forwarding Equivalent Class (FEC) 611 for transport of up to eight BAs of that FEC; 613 - all packets belonging to the same (FEC) and from the set of up 614 to eight BAs (which can span multiple SAs) be sent down this LSP. 615 Such an LSP is referred to as an "EXP-inferred-PHS" LSP or _E-LSP_; 617 - Multiple BAs belonging to the same FEC and transported over the 618 same E-LSP be granted different scheduling treatment and different 619 drop precedence by the PPP MPLS LSR based on the EXP field which is 620 appropriately encoded at label imposition time to reflect both the 621 PHS and the drop precedence of the PHB corresponding to the packet's 622 BA. 624 MPLS specifies how LSPs can be established via multiple signaling 625 protocols. Those include the Label Distribution Protocol (LDP), 626 RSVP, BGP and PIM. This Internet-Draft specifies below, in section 627 3.5, how LDP and RSVP are to be used for establishment of an E-LSP 628 over a PPP link for support of up to eight BAs. 630 3.2 Label Forwarding 632 3.2.1 Incoming PHB and FEC Determination On Ingress E-LSP 634 When receiving a labelled packet over a E-LSP of an MPLS PPP ingress 635 interface, the LSR: 636 - determines the FEC based on the incoming label 637 - determines the incoming PHB by looking at the EXP field of 638 the top level label entry and performing the EXP-->PHB mapping 639 defined below in section 3.4. 641 If the EXP field value of a packet received on an E-LSP is not 642 listed in the mapping of section 2.3, this EXP value should be 643 considered invalid. LSR behavior in such situation is a local matter 644 and is outside the scope of this document. 646 Le Faucheur et. al 12 647 MPLS Support of DiffServ over PPP June 99 649 3.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic 650 Conditioning 652 This stage of Diff-Serv label switching is independent of the 653 ingress/egress interface media type and method used for MPLS Diff- 654 Serv support. It is optional and may be used on an LSR to perform 655 Behavior Aggregate demotion or Promotion inside an MPLS Diff-Serv 656 domain. For the purpose of specifying a Diff-Serv over MPLS method, 657 we simply note that the PHB to be actually enforced by an LSR 658 (referred to as "outgoing PHB") may be different to the PHB which 659 had been associated with the packet by the previous LSR (referred to 660 as "incoming PHB"). 662 3.2.3 Outgoing EXP Field And Label Determination On Egress E-LSP 664 Once the outgoing PHB has been determined by the LSR as a function 665 of the incoming PHB and of the optional Local Policy and Traffic 666 Conditioning, the LSR: 667 - determines via local configuration that the outgoing PHB is 668 one of the PHBs supported by the E-LSP and determines the egress E- 669 LSP label for the packet's FEC 670 - determines the value to be written in the EXP field of the 671 top level label entry (and possibly of other level label entries in 672 the case of a hierarchical tunnel entry) by performing the outgoing 673 PHB-->EXP mapping defined below in section 3.3. 675 3.2.4 Simplified Forwarding 677 When Local Policy and Traffic Conditioning are not to be performed 678 by the LSR and the labeled packet is received on a E-LSP PPP 679 interface and is going out onto a E-LSP PPP interface, the 680 Forwarding operation is simplified since: 681 - the EXP field does not need to be modified 682 - the outgoing label can be directly determined from the 683 incoming label (ie as in non Diff-Serv capable LSRs) 685 3.3 PHB-->EXP field mapping 687 Like the mapping between PHBs and DSCPs in a Diff-Serv network, the 688 mapping from PHB to EXP field is a local matter to be defined by the 689 Service Provider and configured on every LSR. The requirements on 690 this mapping are that: 691 - each of the eight (or less) PHBs to be supported over the E- 692 LSP must map to a different encoding of the 3-bit EXP field (so the 693 mapping can be inverted back from EXP field to PHB at egress) 694 - the mapping must be consistent at every PPP LSP hop 695 throughout the Diff-Serv domain spanned by the LSP 697 3.4 EXP-->PHB mapping 699 Similarly the mapping from EXP field to PHB is a local matter. The 700 requirement on this mapping is that: 702 Le Faucheur et. al 13 703 MPLS Support of DiffServ over PPP June 99 705 - it must be the exact inverse of the PHB to EXP field mapping 706 - it must be consistent at every PPP LSP hop throughout the 707 Diff-Serv domain spanned by the LSP 709 3.5 Signalling During E-LSP establishment 711 To support Diff-Serv in MPLS over PPP using E-LSPs, the fact that 712 the LSP is a E-LSP must be conveyed in the MPLS label request 713 messages and MPLS label binding messages. The method to achieve this 714 is described below when the signaling protocol used is RSVP or LDP. 715 The MPLS control application on each PPP LSR along the E-LSP will 716 notice that the LSP is a E-LSP and install the corresponding 717 scheduling and drop behavior for that LSP based on the EXP<-->PHB 718 mapping locally configured for E-LSP operations. 720 3.5.1 Merging 722 In an MPLS domain, two or more LSPs can be merged into one LSP at 723 one LSR. The proposed support of Diff-Serv in MPLS over PPP using E- 724 LSPs is compatible with LSP Merging under the following condition: 726 E-LSPs can only be merged into one LSP if they support the exact 727 same set of BAs. 729 3.5.2 RSVP Signaling for E-LSPs 731 A new DIFFSERV_PHS RSVP Object has been defined above in section 732 2.5.3 to explicitly signal that an LSP is a L-LSP and to indicate 733 the PHS associated with the L-LSP. 735 We propose that no new RSVP Object be defined for E-LSPs. Rather, we 736 propose that the fact that the LSP is an E-LSP be implicitly 737 conveyed by the absence of DIFFSERV_PHS RSVP Object in a PATH 738 message containing a LABEL_REQUEST Object and in a RESV message 739 containing the LABEL Object. 741 3.5.3 LDP Signaling for E-LSPs 743 A new PHS TLV has been defined above in section 2.5.4 to explicitly 744 signal that an LSP is an L-LSP and to indicate the PHS associated 745 with the LSP. 747 We propose that no new LDP TLV be defined for E-LSPs. Rather, we 748 propose that the fact that the LSP is an E-LSP be implicitly 749 conveyed by the absence of PHS TLV in a label request or label 750 binding message. 752 4. Example Deployment Scenarios 754 This section does not provide additional specification of the 755 proposed approach and is only here to provide examples of how this 757 Le Faucheur et. al 14 758 MPLS Support of DiffServ over PPP June 99 760 flexible approach for Diff-Serv support over MPLS over PPP may be 761 deployed. Pros and cons of various deployment options for particular 762 environments are beyond the scope of this document. 764 4.1 Scenario 1: 8 BAs, no Traffic Engineering 766 A Service Provider running 8 (or less) BAs and not performing 767 Traffic engineering in his/her network may elect to run Diff-Serv 768 over MPLS over PPP links using a single E-LSP per FEC established 769 via LDP. 771 Operations can be summarized as follows: 772 - the Service Provider configures at every PPP LSR the bi- 773 directional mapping between each PHB and a value of the EXP field 774 - PPP LSRs signal establishment of a single E-LSP per FEC using 775 LDP in accordance with section 3.5.3 above (ie no PHS TLV in LDP 776 label request and label binding messages to implicitly indicate that 777 the LSP is a E-LSP) 779 4.2 Scenario 2: 8 BAs, no Traffic Engineering 781 A Service Provider running 8 (or less) BAs and not performing 782 Traffic engineering in his/her network may alternatively elect to 783 run Diff-Serv over MPLS over PPP links using one L-LSP per 784 established via LDP. 786 Operations can be summarised as follows: 787 - the Service Provider configures on every PPP LSR the 788 parameters pertaining to the scheduling behavior that should be 789 installed for the L-LSP by the control application for each PHS 790 - PPP LSRs signal establishment of one L-LSP per using 791 the LDP protocol and the LDP extension defined in section 2.5.4 792 above to signal the L-LSP PHS (ie PHS TLV in LDP label request and 793 label binding messages). 795 4.3 Scenario 3: 8 BAs, Aggregate Traffic Engineering 797 A Service Provider running 8 (or less) BAs and performing aggregate 798 Traffic Engineering (ie performing a single common path selection 799 for all BAs) in his/her network may elect to run Diff-Serv over MPLS 800 over PPP links using a single E-LSP per FEC established via RSVP 801 [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE]. 803 Operations can be summarized as follows: 804 - the Service Provider configures at every PPP LSR the 805 bidirectional mapping between each PHB and a value of the EXP field 806 - PPP LSRs signal establishment of a single E-LSP per FEC using 807 : 808 * the RSVP protocol in accordance with section 3.5.2 above 809 (ie no DIFFSERV_PHS RSVP Object in the PATH message containing the 810 LABEL_REQUEST Object and in the RESV message containing the LABEL 811 Object), OR 813 Le Faucheur et. al 15 814 MPLS Support of DiffServ over PPP June 99 816 * using the CR-LDP protocol in accordance with section 817 2.5.3 above (ie no PHS TLV in LDP label request and label binding 818 messages). 820 4.3 Scenario 3: per-SA Traffic Engineering 822 Regardless of the number of BAs supported, a Service Provider 823 performing per-SA Traffic Engineering (ie performing a separate path 824 selection for each SA) in his/her network MUST run Diff-Serv over 825 MPLS over PPP links using one L-LSP per pair established 826 via RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE]. 828 Operations can be summarised as follows: 829 - the Service Provider configures on every PPP LSR the 830 parameters pertaining to the scheduling behavior that should be 831 installed for the L-LSP by the control application for each PHS 832 - PPP LSRs signal establishment of one L-LSP per 833 using: 834 * the RSVP protocol and the RSVP extension defined in 835 section 2.5.3 above to signal the L-LSP (ie DIFFSERV_PHS RSVP Object 836 in the PATH message containing the LABEL_REQUEST Object and in the 837 RESV message containing the LABEL Object), OR 838 * using the CR-LDP protocol and the LDP extension 839 defined in section 2.5.4 above to signal the L-LSP PHS (ie PHS TLV 840 in LDP label request and label binding messages). 842 4.4 Scenario 4: More than 8 BAs, no Traffic Engineering 844 A Service Provider running more than 8 BAs and not performing 845 Traffic Engineering in his/her network may elect to run Diff-Serv 846 over MPLS over PPP links using one L-LSP per pair 847 established via LDP. 849 Operations can be summarised as follows: 850 - the Service Provider configures on every PPP LSR the 851 parameters pertaining to the scheduling behavior that should be 852 installed for the L-LSP by the control application for each PHS 853 - PPP LSRs signal establishment of one L-LSP per using 854 the LDP protocol and the LDP extension defined in section 2.5.4 855 above to signal the L-LSP PHS (ie PHS TLV in LDP label request and 856 label binding messages). 858 4.5 Scenario 5: no Traffic Engineering on 8 BAs, per-SA Traffic 859 Aggregate on other BAs. 861 A Service Provider not performing Traffic Engineering on 8 (or less) 862 BAs and performing per-SA Traffic Engineering on the other BAs (ie 863 performing a separate path selection for each SA corresponding to 864 the other BAs) in his/her network may elect to run Diff-Serv over 865 MPLS over PPP links, using for each FEC: 866 - one E-LSP established via LDP to support the set of 8 (or 867 less) non-traffic engineered BAs, 869 Le Faucheur et. al 16 870 MPLS Support of DiffServ over PPP June 99 872 AND 873 - one L-LSP per pair established via RSVP 874 [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] for support of the other 875 BAs. 877 Operations can be summarised as follows: 878 - the Service Provider configures at every PPP LSR the bi- 879 directional mapping between each PHB of the non-traffic-engineered 880 BAs (supported by the E-LSP) and a value of the EXP field 881 - the Service Provider configures on every PPP LSR the 882 parameters pertaining to the scheduling behavior that should be 883 installed for the L-LSP by the control application for each PHS 884 - PPP LSRs signal establishment of a single E-LSP per FEC for 885 the non-traffic engineered BAs using LDP in accordance with section 886 3.5.3 above (ie no PHS TLV in LDP label request and label binding 887 messages to implicitly indicate that the LSP is a E-LSP) 888 - PPP LSRs signal establishment of one L-LSP per for 889 the traffic engineered BAs using: 890 * the RSVP protocol and the RSVP extension defined in 891 section 2.5.3 above to signal the L-LSP (ie DIFFSERV_PHS RSVP Object 892 in the PATH message containing the LABEL_REQUEST Object and in the 893 RESV message containing the LABEL Object), OR 894 * using the CR-LDP protocol and the LDP extension 895 defined in section 2.5.4 above to signal the L-LSP PHS (ie PHS TLV 896 in LDP label request and label binding messages). 898 5. Security Considerations 900 This document does not introduce any new security issues beyond 901 those inherent in Diff-Serv, MPLS and RSVP, and may use the same 902 mechanisms proposed for those technologies. 904 6. Acknowledgments 906 This document has benefited from discussions with Dan Tappan, Yakov 907 Rekhter, George Swallow, Kathleen Nichols and Brian Carpenter. 909 7. References 911 [MPLS_ARCH] Rosen et al., "Multiprotocol label switching 912 Architecture", work in progress, (draft-ietf-mpls-arch-04.txt), 913 February 1999. 915 [DIFF_ARCH] Blake et al., "An architecture for Differentiated 916 Services", RFC-2475, December 1998. 918 [MPLS_DIFF_PPP] Davari et al., "MPLS Support of Differentiated 919 Services over PPP links", draft-davari-mpls-diff-ppp-00.txt, April 920 99. 922 Le Faucheur et. al 17 923 MPLS Support of DiffServ over PPP June 99 925 [DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597, 926 June 1999. 928 [DIFF_EF] Heinanen et al., "An Expedited Forwarding PHB", RFC-2598, 929 June 1999. 931 [MPLS_ENCAPS] Rosen et al., "MPLS Label Stack Encoding", work in 932 progress, (draft-ietf-mpls-label-encaps-03.txt), September 1998. 934 [DIFF_HEADER] Nichols et al., "Definition of the Differentiated 935 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474, 936 December 1998. 938 [ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion 939 Notification (ECN) to IP", RFC-2481, January 1999. 941 [LDP_03] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 942 03.txt, January 99 944 [LDP_04] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 945 04.txt, April 99 947 [RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", 948 draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999 950 [CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using 951 LDP", draft-ietf-mpls-cr-ldp-01.txt, February 1999 953 [PHBID] Brim and Carpenter, "Per Hop Behavior Identification Codes", 954 draft-brim-diffserv-phbid-00.txt, April 99 956 Author's Addresses: 958 Francois Le Faucheur 959 Cisco Systems 960 Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - 961 France 962 Phone: +33 4 92 96 75 64 963 Email: flefauch@cisco.com 965 Shahram Davari 966 PMC-Sierra Inc. 967 105-8555 Baxter Place 968 Burnaby, BC V5A 4V7 969 Canada 970 E-mail: Shahram_Davari@pmc-sierra.com 972 Ram Krishnan 973 Nexabit Networks 974 200 Nickerson Road, 975 Marlboro, MA 01752 977 Le Faucheur et. al 18 978 MPLS Support of DiffServ over PPP June 99 980 USA 981 E-mail: ram@nexabit.com 983 Pasi Vanannen 984 Nokia 985 3 Burlington Woods Drive, Suit 250 986 Burlington, MA 01803 987 USA 988 Email: pasi.vaananen@ntc.nokia.com 990 Bruce Davie 991 Cisco Systems 992 250 Apollo Drive, Chelmsford, MA 01824, USA 993 Phone: (978)-244-8000 994 Email: bsd@cisco.com 996 Le Faucheur et. al 19