idnits 2.17.1 draft-ietf-mpls-cosfield-def-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 455. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3270, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3032, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3032, updated by this document, for RFC5378 checks: 1997-11-20) -- 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.) -- The document date (November 17, 2008) is 5640 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3272 (Obsoleted by RFC 9522) ** Downref: Normative reference to an Informational RFC: RFC 3469 ** Downref: Normative reference to an Informational RFC: RFC 3564 ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft Acreo AB 4 Updates: RFC 3032, RFC 3270, RFC R. Asati 5 5129, RFC 3272, RFC 3443, RFC Cisco Systems 6 3469, RFC 3564, RFC 3985, RFC November 17, 2008 7 4182, RFC 4364, RFC 4379, RFC 8 4448, RFC 4761 (if approved) 9 Intended status: Standards Track 10 Expires: May 21, 2009 12 "EXP field" renamed to "Traffic Class field" 13 draft-ietf-mpls-cosfield-def-06.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 21, 2009. 40 Abstract 42 The early MPLS documents defined the form of the MPLS Label Stack 43 entry. This include a three bit field called the "EXP field". The 44 exact use of this field was not defined by these documents, except to 45 state that it was to be "reserved for experimental use". 47 Although the intended use of the EXP field was as a "Class of 48 Service" field, it was not named the "Class of Service" (CoS) field 49 by these early documents because the use of such a CoS field was not 50 considered to be sufficiently defined. Today a number of standards 51 documents define its usage as a CoS field. . 53 To avoid misunderstanding about how this field may be used, it has 54 become increasingly necessary to rename this field. This document 55 changes the name of the field to the "Traffic Class field" ("TC 56 field".) In doing so it also updates documents that define the 57 current use of the EXP this field. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Details of change . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.4. The Scope of this Change . . . . . . . . . . . . . . . . . 8 67 3. Use of the TC field . . . . . . . . . . . . . . . . . . . . . 10 68 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 69 5. Security considerations . . . . . . . . . . . . . . . . . . . 12 70 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 73 7.2. Informative references . . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 75 Intellectual Property and Copyright Statements . . . . . . . . . . 17 77 1. Introduction 79 The format of a MPLS label stack entry is defined by RFC 3032 80 [RFC3032], include a three bit field called the "EXP field". The 81 exact use of this field is not defined by RFC 3032 leaves, except to 82 state that it is to be "reserved for experimental use". 84 The EXP field, from the start, was intended to carry "Class of 85 Service" information. The field was actually called the "Class of 86 Service field" in the early versions of the working group document 87 that was publshed as RFC 3032. However at the time that RFC 3032 was 88 published the exact usage of this "Class of Service" field was not 89 agreed and the field was designated as "Experimental use". 91 The designation "for Experimental use" has led other Standards 92 Development Organizations (SDO) and implementors to the assume that 93 it possible to use the field for other purposes. This document 94 changes the name of the field to clearly indicate its use as a 95 traffic classification field. 97 At first we discussed to use the original "CoS field" as the name for 98 the field, but it has been pointed that this name does not cover the 99 following changes wrt its usage, since RFC 3032 was published. 101 1. The use of the EXP field was first defined in RFC 3270 [RFC3270] 102 where a method to define a variant of DiffServ LSPs called EXP- 103 Inferred-PSC LSP (E-LSPs) was specified. 105 2. The use of the EXP field as defined in RFC 3270 has been further 106 extended in RFC 5129 [RFC5129], where methods for explicit 107 congestion marking in MPLS are defined. 109 This document, hence, uses the name "Traffic Class Field (TC Field)", 110 which better covers the potential use. The MPLS TC field relates to 111 an MPLS encapsulated packet the same way as the IPv6 TC field relates 112 to an IPv6 encapsulted packet or the IPv4 Precedence field relates to 113 an IPv4 encapsulated packet. 115 The defintions of how the EXP field are used are perfectly clear in 116 RFC 3270 and RFC 5129. However, these RFCs do not explicitly state 117 they update RFC 3032, and this fact is not captured in the RFC 118 respository. This document updates RFC 3032, RFC 3270 and RFC 5129 119 to clarify the intended usage of the TC field. Section 2 explains 120 the changes. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Details of change 128 The three RFCs are now updated according to the following. 130 2.1. RFC 3032 132 RFC 3032 states on page 4: 134 3. Experimental Use 136 This three-bit field is reserved for experimental use. 138 This paragraph is now changed to: 140 3. Traffic Class (TC) field 142 This three-bit field is used to carry Traffic Class information 143 and the change of the name is applicable to all places it occurs 144 in IETF RFCs and other IETF documents. 146 RFC 3270 and RFC 5129 updates the definition of the TC field and 147 describes how to use the field. 149 In Figure 1 on page 3 in RFC3032 the format of a label stack entry is 150 specified as: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 155 | Label | Exp |S| TTL | Stack 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 158 Label: Label Value, 20 bits 159 Exp: Experimental Use, 3 bits 160 S: Bottom of Stack, 1 bit 161 TTL: Time to Live, 8 bits 163 Figure 1 165 Figure 1 in RFC 3032 is now changed to match the change of name of 166 the TC field to: 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 171 | Label | TC |S| TTL | Stack 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 174 Label: Label Value, 20 bits 175 CoS: Traffic Class field, 3 bits 176 S: Bottom of Stack, 1 bit 177 TTL: Time to Live, 8 bits 179 Figure 1 181 2.2. RFC 3270 183 RFC 3270 says on page 6: 185 1.2 EXP-Inferred-PSC LSPs (E-LSP) 187 A single LSP can be used to support one or more OAs. Such LSPs 188 can support up to eight BAs of a given FEC, regardless of how many 189 OAs these BAs span. With such LSPs, the EXP field of the MPLS 190 Shim Header is used by the LSR to determine the PHB to be applied 191 to the packet. This includes both the PSC and the drop 192 preference. 194 We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since 195 the PSC of a packet transported on this LSP depends on the EXP 196 field value for that packet. 198 The mapping from the EXP field to the PHB (i.e., to PSC and drop 199 precedence) for a given such LSP, is either explicitly signaled at 200 label set-up or relies on a pre-configured mapping. 202 Detailed operations of E-LSPs are specified in section 3 below. 204 RFC 3270 is now updated like this: 206 a. A new paragraph is added at the end of section 1 "Introduction": 208 The EXP field has been renamed to the TC field, and thus all 209 references in RFC 3270 to EXP field SHOULD be taken to refer 210 to the TC field. 212 b. A new term is added to section 1.1 "Terminology": 214 TC Traffic Class (replaces the term EXP) 216 c. In section 1.1 "Terminology" the acronym E-LSP is now understood 217 to mean : 219 E-LSP Explicitly-Inferred-PSC LSP 221 Section 1.2 on page 5 in RFC 3270 is now changed to: 223 1.2 Explicitly-Inferred-PSC LSPs (E-LSP) 225 The EXP field has been renamed to the TC field, and thus all 226 references in RFC 3270 to EXP field SHOULD be taken to refer to 227 the TC field. However, we retain the acronym E-LSP (Explicitly- 228 Inferred-PSC LSP) as the acronym is in widespread use. 230 A single LSP can be used to support one or more OAs. Such LSPs 231 can support up to eight BAs of a given FEC, regardless of how many 232 OAs these BAs span. With such LSPs, the TC field of the MPLS Shim 233 Header is used by the LSR to determine the PHB to be applied to 234 the packet. This includes both the PSC and the drop preference. 236 We refer to such LSPs as "Explicitly-inferred-PSC LSPs" (E-LSP), 237 since the PSC of a packet transported on this LSP depends on the 238 TC field (previously called the EXP field) value for that packet. 240 The mapping from the TC field to the PHB (i.e., to PSC and drop 241 precedence) for a given such LSP, is either explicitly signaled at 242 label set-up or relies on a pre-configured mapping. 244 This is an update to RFC 3032 [RFC3032] in line with the original 245 intent of how this field in the MPLS Shim Header should be used 246 (as TC field). The RFC 3270 has itself been updated by RFC 5129 247 [RFC5129]. 249 Detailed operations of E-LSPs are specified in section 3 of 250 RFC3270. 252 2.3. RFC 5129 254 Section 2 (bullet 3) on page 6 of RFC 5129 says: 256 o A third possible approach was suggested by [Shayman]. In this 257 scheme, interior LSRs assume that the endpoints are ECN-capable, 258 but this assumption is checked when the final label is popped. If 259 an interior LSR has marked ECN in the EXP field of the shim 260 header, but the IP header says the endpoints are not ECN-capable, 261 the edge router (or penultimate router, if using penultimate hop 262 popping) drops the packet. We recommend this scheme, which we 263 call `per-domain ECT checking', and define it more precisely in 264 the following section. Its chief drawback is that it can cause 265 packets to be forwarded after encountering congestion only to be 266 dropped at the egress of the MPLS domain. The rationale for this 267 decision is given in Section 8.1. 269 RFC 5129 is now updated like this: 271 A new paragraph is added at the end of section 1.1 "Background": 273 The EXP field has been renamed to the TC field, and thus all 274 references in RFC 5129 to EXP field SHOULD be taken to refer to 275 the TC field. 277 Section 2 (bullet 3) on page 6 is now changed to: 279 o A third possible approach was suggested by [Shayman]. In this 280 scheme, interior LSRs assume that the endpoints are ECN-capable, 281 but this assumption is checked when the final label is popped. If 282 an interior LSR has marked ECN in the TC field of the shim header, 283 but the IP header says the endpoints are not TC-capable, the edge 284 router (or penultimate router, if using penultimate hop popping) 285 drops the packet. We recommend this scheme, which we call `per- 286 domain ECT checking', and define it more precisely in the 287 following section. Its chief drawback is that it can cause 288 packets to be forwarded after encountering congestion only to be 289 dropped at the egress of the MPLS domain. The rationale for this 290 decision is given in Section 8.1. This scheme is an update to RFC 291 3032 [RFC3032] and RFC 3270 [RFC3270]. 293 2.4. The Scope of this Change 295 There are several places in the RFCs that has explicitly updated by 296 this document that refrence the "Exp field", sometimes they refer to 297 the field as "Exp bits", "EXP bits" and "EXP". In all those 298 instances the references SHOULD be taken to reference the TC field. 300 There are also other RFCs, e.g. RFC 3272 [RFC3272], RFC 3443 301 [RFC3443], RFC 3469 [RFC3469], RFC 3564 [RFC3564], RFC 3985 302 [RFC3985], RFC 4182 [RFC4182], RFC 4364 [RFC4364], RFC 4379 303 [RFC4379], RFC 4448 [RFC4448] and RFC 4761 [RFC4761] that references 304 the "Exp field", sometimes they refer to the field as "Exp bits", 305 "EXP bits" and "EXP". For all RFCs, including but not limited to 306 those mentioned in this paragraph, such references SHOULD be taken to 307 reference the TC field. 309 3. Use of the TC field 311 Due to the limited number of bits in the TC field, their use for QoS 312 and ECN functions is intended to be flexible. These funtions may 313 rewrite all or some of the bits in the TC field. 315 Current implementations look at the TC field with and without label 316 context and the TC field may be copied to the label stack entries 317 that are pushed onto the label stack. This is done to avoid that 318 label stack entries that are pushed on to an existing label stack 319 have different TF fields from the rest of the label stack entries. 321 4. IANA considerations 323 There are no request for IANA allocation of code points in this 324 document. 326 5. Security considerations 328 This document only changes the name of one field in the MPLS Shim 329 Header and thus does not introduce any new security considerations. 331 6. Acknowledgments 333 The author would like to thank Stewart Bryant, Bruce Davie, George 334 Swallow, and Francois Le Faucheur for their input to and review of 335 the current document. 337 The author also like to thanks George Swallow, Khatri Paresh and Phil 338 Bedard for their help with grammar and spelling, and a special thanks 339 to Adrian Farrel for a careful review and help trawling the RFC-sea 340 for RFCs that references the EXP field. 342 7. References 344 7.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 350 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 351 Encoding", RFC 3032, January 2001. 353 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 354 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 355 Protocol Label Switching (MPLS) Support of Differentiated 356 Services", RFC 3270, May 2002. 358 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 359 Xiao, "Overview and Principles of Internet Traffic 360 Engineering", RFC 3272, May 2002. 362 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 363 in Multi-Protocol Label Switching (MPLS) Networks", 364 RFC 3443, January 2003. 366 [RFC3469] Sharma, V. and F. Hellstrand, "Framework for Multi- 367 Protocol Label Switching (MPLS)-based Recovery", RFC 3469, 368 February 2003. 370 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 371 Differentiated Services-aware MPLS Traffic Engineering", 372 RFC 3564, July 2003. 374 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 375 Edge (PWE3) Architecture", RFC 3985, March 2005. 377 [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS 378 Explicit NULL", RFC 4182, September 2005. 380 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 381 Networks (VPNs)", RFC 4364, February 2006. 383 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 384 Label Switched (MPLS) Data Plane Failures", RFC 4379, 385 February 2006. 387 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 388 "Encapsulation Methods for Transport of Ethernet over MPLS 389 Networks", RFC 4448, April 2006. 391 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 392 (VPLS) Using BGP for Auto-Discovery and Signaling", 393 RFC 4761, January 2007. 395 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 396 Marking in MPLS", RFC 5129, January 2008. 398 7.2. Informative references 400 [Shayman] Shayman, M. and R. Jaeger, University of Michigan, "Using 401 ECN to Signal Congestion Within an MPLS Domain", Work in 402 Progress, November 2000.", . 405 Authors' Addresses 407 Loa Andersson 408 Acreo AB 410 Email: loa@pi.nu 412 Rajiva Asati 413 Cisco Systems 415 Email: rajiva@cisco.com 417 Full Copyright Statement 419 Copyright (C) The IETF Trust (2008). 421 This document is subject to the rights, licenses and restrictions 422 contained in BCP 78, and except as set forth therein, the authors 423 retain all their rights. 425 This document and the information contained herein are provided on an 426 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 427 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 428 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 429 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 430 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 431 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 433 Intellectual Property 435 The IETF takes no position regarding the validity or scope of any 436 Intellectual Property Rights or other rights that might be claimed to 437 pertain to the implementation or use of the technology described in 438 this document or the extent to which any license under such rights 439 might or might not be available; nor does it represent that it has 440 made any independent effort to identify any such rights. Information 441 on the procedures with respect to rights in RFC documents can be 442 found in BCP 78 and BCP 79. 444 Copies of IPR disclosures made to the IETF Secretariat and any 445 assurances of licenses to be made available, or the result of an 446 attempt made to obtain a general license or permission for the use of 447 such proprietary rights by implementers or users of this 448 specification can be obtained from the IETF on-line IPR repository at 449 http://www.ietf.org/ipr. 451 The IETF invites any interested party to bring to its attention any 452 copyrights, patents or patent applications, or other proprietary 453 rights that may cover technology that may be required to implement 454 this standard. Please address the information to the IETF at 455 ietf-ipr@ietf.org.