idnits 2.17.1 draft-ietf-mpls-cosfield-def-05.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 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 463. 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 (October 15, 2008) is 5665 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 October 15, 2008 7 4182, RFC 4364, RFC 4379, RFC 8 4448, RFC 4761 (if approved) 9 Intended status: Standards Track 10 Expires: April 18, 2009 12 "EXP field" renamed to "Traffic Class field" 13 draft-ietf-mpls-cosfield-def-05.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 April 18, 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 . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.4. The Scope of this Change . . . . . . . . . . . . . . . . . 9 67 3. Use of the TC field . . . . . . . . . . . . . . . . . . . . . 11 68 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 69 5. Security considerations . . . . . . . . . . . . . . . . . . . 13 70 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 73 7.2. Informative references . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Intellectual Property and Copyright Statements . . . . . . . . . . 18 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 orignal "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. 112 The defintions of how the EXP field are used are perfectly clear in 113 RFC 3270 and RFC 5129. However, these RFCs do not explicitly state 114 they update RFC 3032, and this fact is not captured in the RFC 115 respository. This document updates RFC 3032, RFC 3270 and RFC 5129 116 to clarify the intended usage of the TC field. Section 2 explains 117 the changes. 119 This document, hence, uses the name "Traffic Class Field (TC Field)", 120 which better covers the potential use. The MPLS TC field relates to 121 an MPLS encapsulated packet the same way as the IPv6 TC field relates 122 to an IPv6 encapsulted packet or the IPv4 Precedence field relates to 123 an IPv4 encapsulated packet. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Details of change 131 The three RFCs are now updated according to the following. 133 2.1. RFC 3032 135 RFC 3032 states on page 4: 137 3. Experimental Use 139 This three-bit field is reserved for experimental use. 141 This paragraph is now changed to: 143 3. Traffic Class (TC) field 145 This three-bit field is used to carry Traffic Class information 146 and the change of the name is applicable to all places it occurs 147 in IETF RFCs and other IETF documents. 149 RFC 3270 and RFC 5129 updates the definition of the TC field and 150 describes how to use the field. 152 In Figure 1 on page 3 in RFC3032 the format of a label stack entry is 153 specified as: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 158 | Label | Exp |S| TTL | Stack 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 161 Label: Label Value, 20 bits 162 Exp: Experimental Use, 3 bits 163 S: Bottom of Stack, 1 bit 164 TTL: Time to Live, 8 bits 166 Figure 1 168 Figure 1 in RFC 3032 is now changed to match the change of name of 169 the TC field to: 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 174 | Label | TC |S| TTL | Stack 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 177 Label: Label Value, 20 bits 178 CoS: Traffic Class field, 3 bits 179 S: Bottom of Stack, 1 bit 180 TTL: Time to Live, 8 bits 182 Figure 1 184 2.2. RFC 3270 186 RFC 3270 says on page 6: 188 1.2 EXP-Inferred-PSC LSPs (E-LSP) 190 A single LSP can be used to support one or more OAs. Such LSPs 191 can support up to eight BAs of a given FEC, regardless of how many 192 OAs these BAs span. With such LSPs, the EXP field of the MPLS 193 Shim Header is used by the LSR to determine the PHB to be applied 194 to the packet. This includes both the PSC and the drop 195 preference. 197 We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since 198 the PSC of a packet transported on this LSP depends on the EXP 199 field value for that packet. 201 The mapping from the EXP field to the PHB (i.e., to PSC and drop 202 precedence) for a given such LSP, is either explicitly signaled at 203 label set-up or relies on a pre-configured mapping. 205 Detailed operations of E-LSPs are specified in section 3 below. 207 RFC 3270 is now updated like this: 209 a. A new paragraph is added at the end of section 1 "Introduction": 211 The EXP field has been renamed to the TC field, and thus all 212 references in RFC 3270 to EXP field SHOULD be taken to refer 213 to the TC field. 215 b. A new term is added to section 1.1 "Terminology": 217 TC Traffic Class (replaces the term EXP) 219 c. A new acronym is added at the end of section 1.1 "Terminology": 221 T-LSP TC-Inferred-PSC LSP (future replacement of the term 222 E-LSP) 224 Section 1.2 on page 5 in RFC 3270 is now changed to: 226 1.2 EXP-Inferred-PSC LSPs (E-LSP) 228 The EXP field has been renamed to the TC field, and thus all 229 references in RFC 3270 to EXP field SHOULD be taken to refer to 230 the TC field. However, we retain the term E-LSP (EXP-Inferred-PSC 231 LSP) as it is in widespread use. 233 A single LSP can be used to support one or more OAs. Such LSPs 234 can support up to eight BAs of a given FEC, regardless of how many 235 OAs these BAs span. With such LSPs, the TC field of the MPLS Shim 236 Header is used by the LSR to determine the PHB to be applied to 237 the packet. This includes both the PSC and the drop preference. 239 We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since 240 the PSC of a packet transported on this LSP depends on the TC 241 field (previously called the EXP field) value for that packet. 243 In future documents the term "TC-inferred-PSC LSPs" (T-LSP) may be 244 be used to refer to such LSPs as , since the PSC of a packet 245 transported on this LSP depends on the TC field value for that 246 packet. The meaning of E-SLP and T-LSP is the same. 248 The mapping from the TC field to the PHB (i.e., to PSC and drop 249 precedence) for a given such LSP, is either explicitly signaled at 250 label set-up or relies on a pre-configured mapping. 252 This is an update to RFC 3032 [RFC3032] in line with the original 253 intent of how this field in the MPLS Shim Header should be used 254 (as TC field). The RFC 3270 has itself been updated by RFC 5129 255 [RFC5129]. 257 Detailed operations of E-LSPs are specified in section 3 of 258 RFC3270. 260 2.3. RFC 5129 262 Section 2 (bullet 3) on page 6 of RFC 5129 says: 264 o A third possible approach was suggested by [Shayman]. In this 265 scheme, interior LSRs assume that the endpoints are ECN-capable, 266 but this assumption is checked when the final label is popped. If 267 an interior LSR has marked ECN in the EXP field of the shim 268 header, but the IP header says the endpoints are not ECN-capable, 269 the edge router (or penultimate router, if using penultimate hop 270 popping) drops the packet. We recommend this scheme, which we 271 call `per-domain ECT checking', and define it more precisely in 272 the following section. Its chief drawback is that it can cause 273 packets to be forwarded after encountering congestion only to be 274 dropped at the egress of the MPLS domain. The rationale for this 275 decision is given in Section 8.1. 277 RFC 5129 is now updated like this: 279 A new paragraph is added at the end of section 1.1 "Background": 281 The EXP field has been renamed to the TC field, and thus all 282 references in RFC 5129 to EXP field SHOULD be taken to refer to 283 the TC field. 285 Section 2 (bullet 3) on page 6 ofis now changed to: 287 o A third possible approach was suggested by [Shayman]. In this 288 scheme, interior LSRs assume that the endpoints are ECN-capable, 289 but this assumption is checked when the final label is popped. If 290 an interior LSR has marked ECN in the TC field of the shim header, 291 but the IP header says the endpoints are not TC-capable, the edge 292 router (or penultimate router, if using penultimate hop popping) 293 drops the packet. We recommend this scheme, which we call `per- 294 domain ECT checking', and define it more precisely in the 295 following section. Its chief drawback is that it can cause 296 packets to be forwarded after encountering congestion only to be 297 dropped at the egress of the MPLS domain. The rationale for this 298 decision is given in Section 8.1. This scheme is an update to RFC 299 3032 [RFC3032] and RFC 3270 [RFC3270]. 301 2.4. The Scope of this Change 303 There are several places in the RFCs that has explicitly updated by 304 this document that refrence the "Exp field", sometimes they refer to 305 the field as "Exp bits", "EXP bits" and "EXP". In all those 306 instances the references SHOULD be taken to reference the TC field. 308 There are also other RFCs, e.g. RFC 3272 [RFC3272], RFC 3443 309 [RFC3443], RFC 3469 [RFC3469], RFC 3564 [RFC3564], RFC 3985 310 [RFC3985], RFC 4182 [RFC4182], RFC 4364 [RFC4364], RFC 4379 311 [RFC4379], RFC 4448 [RFC4448] and RFC 4761 [RFC4761] that references 312 the "Exp field", sometimes they refer to the field as "Exp bits", 313 "EXP bits" and "EXP". For all RFCs, including but not limited to 314 those mentioned in this paragraph, such references SHOULD be taken to 315 reference the TC field. 317 3. Use of the TC field 319 Due to the limited number of bits in the TC field, their use for QoS 320 and ECN functions is intended to be flexible. These funtions may 321 rewrite all or some of the bits in the TC field. 323 Current implementations look at the TC field with and without label 324 context and the TC field may be copied to the label stack entries 325 that are pushed onto the label stack. This is done to avoid that 326 label stack entries that are pushed on to an existing label stack 327 have different TF fields from the rest of the label stack entries. 329 4. IANA considerations 331 There are no request for IANA allocation of code points in this 332 document. 334 5. Security considerations 336 This document only changes the name of one field in the MPLS Shim 337 Header and thus does not introduce any new security considerations. 339 6. Acknowledgments 341 The author would like to thank Stewart Bryant, Bruce Davie, George 342 Swallow, Rajiv Asati and Francois Le Faucheur for their input to and 343 review of the current document. 345 The author also like to thanks George Swallow, Khatri Paresh and Phil 346 Bedard for their help with grammar and spelling, and a special thanks 347 to Adrian Farrel for a careful review and help trawling the RFC-sea 348 for RFCs that references the EXP field. 350 7. References 352 7.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 358 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 359 Encoding", RFC 3032, January 2001. 361 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 362 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 363 Protocol Label Switching (MPLS) Support of Differentiated 364 Services", RFC 3270, May 2002. 366 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 367 Xiao, "Overview and Principles of Internet Traffic 368 Engineering", RFC 3272, May 2002. 370 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 371 in Multi-Protocol Label Switching (MPLS) Networks", 372 RFC 3443, January 2003. 374 [RFC3469] Sharma, V. and F. Hellstrand, "Framework for Multi- 375 Protocol Label Switching (MPLS)-based Recovery", RFC 3469, 376 February 2003. 378 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 379 Differentiated Services-aware MPLS Traffic Engineering", 380 RFC 3564, July 2003. 382 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 383 Edge (PWE3) Architecture", RFC 3985, March 2005. 385 [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS 386 Explicit NULL", RFC 4182, September 2005. 388 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 389 Networks (VPNs)", RFC 4364, February 2006. 391 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 392 Label Switched (MPLS) Data Plane Failures", RFC 4379, 393 February 2006. 395 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 396 "Encapsulation Methods for Transport of Ethernet over MPLS 397 Networks", RFC 4448, April 2006. 399 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 400 (VPLS) Using BGP for Auto-Discovery and Signaling", 401 RFC 4761, January 2007. 403 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 404 Marking in MPLS", RFC 5129, January 2008. 406 7.2. Informative references 408 [Shayman] Shayman, M. and R. Jaeger, University of Michigan, "Using 409 ECN to Signal Congestion Within an MPLS Domain", Work in 410 Progress, November 2000.", . 413 Authors' Addresses 415 Loa Andersson 416 Acreo AB 418 Email: loa@pi.nu 420 Rajiva Asati 421 Cisco Systems 423 Email: rajiva@cisco.com 425 Full Copyright Statement 427 Copyright (C) The IETF Trust (2008). 429 This document is subject to the rights, licenses and restrictions 430 contained in BCP 78, and except as set forth therein, the authors 431 retain all their rights. 433 This document and the information contained herein are provided on an 434 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 435 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 436 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 437 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 438 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 439 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 441 Intellectual Property 443 The IETF takes no position regarding the validity or scope of any 444 Intellectual Property Rights or other rights that might be claimed to 445 pertain to the implementation or use of the technology described in 446 this document or the extent to which any license under such rights 447 might or might not be available; nor does it represent that it has 448 made any independent effort to identify any such rights. Information 449 on the procedures with respect to rights in RFC documents can be 450 found in BCP 78 and BCP 79. 452 Copies of IPR disclosures made to the IETF Secretariat and any 453 assurances of licenses to be made available, or the result of an 454 attempt made to obtain a general license or permission for the use of 455 such proprietary rights by implementers or users of this 456 specification can be obtained from the IETF on-line IPR repository at 457 http://www.ietf.org/ipr. 459 The IETF invites any interested party to bring to its attention any 460 copyrights, patents or patent applications, or other proprietary 461 rights that may cover technology that may be required to implement 462 this standard. Please address the information to the IETF at 463 ietf-ipr@ietf.org.