idnits 2.17.1 draft-ietf-mpls-cosfield-def-04.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 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 420. 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 (July 7, 2008) is 5765 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 July 7, 2008 5 5129, RFC 3272, RFC 3443, RFC 6 3469, RFC 3564, RFC 3985, RFC 7 4182, RFC 4364, RFC 4379, RFC 8 4448, RFC 4761 (if approved) 9 Intended status: Standards Track 10 Expires: January 8, 2009 12 "EXP field" renamed to "CoS Field" 13 draft-ietf-mpls-cosfield-def-04.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 January 8, 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, this 54 document changes the name of the field to the "CoS field". In doing 55 so it also updates documents that define the current use of the EXP 56 this field. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Details of change . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.4. The Scope of this Change . . . . . . . . . . . . . . . . . 8 66 3. Use of the CoS field . . . . . . . . . . . . . . . . . . . . . 9 67 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 68 5. Security considerations . . . . . . . . . . . . . . . . . . . 11 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 72 7.2. Informative references . . . . . . . . . . . . . . . . . . 14 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Intellectual Property and Copyright Statements . . . . . . . . . . 16 76 1. Introduction 78 The format of a MPLS label stack entry is defined by RFC 3032 79 [RFC3032], include a three bit field called the "EXP field". The 80 exact use of this field is not defined by RFC 3032 leaves, except to 81 state that it is to be "reserved for experimental use". 83 The EXP field, from the start, was intended to carry "Class of 84 Service" information. The field was actually called the "Class of 85 Service field" in the early versions of the working group document 86 that was publshed as RFC 3032. However at the time that RFC 3032 was 87 published the exact usage of this "Class of Service" field was not 88 agreed and the field was designated as "Experimental use". 90 The designation "for Experimental use" has led other Standards 91 Development Organizations (SDO) and implementors to the assume that 92 it possible to use the field for other purposes than Class of 93 Service. This document changes the name of the field to clearly 94 indicate its use. 96 The use of the EXP field was first defined in RFC 3270 [RFC3270] 97 where a method to define a variant of DiffServ LSPs called EXP- 98 Inferred-PSC LSP (E-LSPs) were specified. 100 The use of the EXP field as defined in RFC 3270 has been further 101 extended in RFC 5129 [RFC5129], where methods for explicit congestion 102 marking in MPLS are defined. 104 The defintions of how the EXP field are used are perfectly clear in 105 RFC 3270 and RFC 5129. However, these RFCs do not explicitly state 106 they update RFC 3032, and this fact is not captured in the RFC 107 respository. This document updates RFC 3032, RFC 3270 and RFC 5129 108 to clarify the intended usage of the CoS field. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Details of change 116 The three RFCs are now updated according to the following. 118 2.1. RFC 3032 120 RFC 3032 states on page 4: 122 3. Experimental Use 124 This three-bit field is reserved for experimental use. 126 This paragraph is now changed to: 128 3. Class of Service (CoS) field 130 This three-bit field is used to carry Class of Service information 131 and the change of the name is applicable to all places it occurs 132 in IETF RFCs and other IETF documents. 134 The definition of how to use the CoS field has been updated by RFC 135 3270 and RFC 5129. 137 In Figure 1 on page 3 in RFC3032 the format of a label stack entry is 138 specified as: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 143 | Label | Exp |S| TTL | Stack 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 146 Label: Label Value, 20 bits 147 Exp: Experimental Use, 3 bits 148 S: Bottom of Stack, 1 bit 149 TTL: Time to Live, 8 bits 151 Figure 1 153 Figure 1 in RFC 3032 is now changed to match the change of name of 154 the Cos field to: 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label 159 | Label | CoS |S| TTL | Stack 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry 162 Label: Label Value, 20 bits 163 CoS: Class of Service field, 3 bits 164 S: Bottom of Stack, 1 bit 165 TTL: Time to Live, 8 bits 167 Figure 1 169 2.2. RFC 3270 171 RFC 3270 says on page 6: 173 1.2 EXP-Inferred-PSC LSPs (E-LSP) 175 A single LSP can be used to support one or more OAs. Such LSPs 176 can support up to eight BAs of a given FEC, regardless of how many 177 OAs these BAs span. With such LSPs, the EXP field of the MPLS 178 Shim Header is used by the LSR to determine the PHB to be applied 179 to the packet. This includes both the PSC and the drop 180 preference. 182 We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since 183 the PSC of a packet transported on this LSP depends on the EXP 184 field value for that packet. 186 The mapping from the EXP field to the PHB (i.e., to PSC and drop 187 precedence) for a given such LSP, is either explicitly signaled at 188 label set-up or relies on a pre-configured mapping. 190 Detailed operations of E-LSPs are specified in section 3 below. 192 Section 1.2 on page 5 in RFC 3270 is now changed to: 194 1.2 EXP-Inferred-PSC LSPs (E-LSP) 195 The EXP field has been renamed to the CoS field, and thus all 196 references in RFC 3270 to EXP field SHOULD be taken to refer to 197 the CoS field. However, we retain the term E-LSP (EXP-Inferred- 198 PSC LSP) as it is in widespread use. 200 A single LSP can be used to support one or more OAs. Such LSPs 201 can support up to eight BAs of a given FEC, regardless of how many 202 OAs these BAs span. With such LSPs, the CoS field of the MPLS 203 Shim Header is used by the LSR to determine the PHB to be applied 204 to the packet. This includes both the PSC and the drop 205 preference. 207 We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since 208 the PSC of a packet transported on this LSP depends on the CoS 209 field (previously called the EXP field) value for that packet. 211 The mapping from the CoS field to the PHB (i.e., to PSC and drop 212 precedence) for a given such LSP, is either explicitly signaled at 213 label set-up or relies on a pre-configured mapping. 215 This is an update to RFC 3032 [RFC3032] in line with the original 216 intent of how this field in the MPLS Shim Header should be used 217 (as CoS field). The RFC 3270 has itself been updated by RFC 5129 218 [RFC5129]. 220 Detailed operations of E-LSPs are specified in section 3 of 221 RFC3270. 223 2.3. RFC 5129 225 Section 2 (bullet 3) on page 6 of RFC 5129 says: 227 o A third possible approach was suggested by [Shayman]. In this 228 scheme, interior LSRs assume that the endpoints are ECN-capable, 229 but this assumption is checked when the final label is popped. If 230 an interior LSR has marked ECN in the EXP field of the shim 231 header, but the IP header says the endpoints are not ECN-capable, 232 the edge router (or penultimate router, if using penultimate hop 233 popping) drops the packet. We recommend this scheme, which we 234 call `per-domain ECT checking', and define it more precisely in 235 the following section. Its chief drawback is that it can cause 236 packets to be forwarded after encountering congestion only to be 237 dropped at the egress of the MPLS domain. The rationale for this 238 decision is given in Section 8.1. 240 RFC 5219 is now updated like this: 242 A new paragraph is added at the end of section 1.1 "Background": 244 The EXP field has been renamed to the CoS field, and thus all 245 references in RFC 5219 to EXP field SHOULD be taken to refer to 246 the CoS field. 248 Section 2 (bullet 3) on page 6 ofis now changed to: 250 o A third possible approach was suggested by [Shayman]. In this 251 scheme, interior LSRs assume that the endpoints are ECN-capable, 252 but this assumption is checked when the final label is popped. If 253 an interior LSR has marked ECN in the CoS field of the shim 254 header, but the IP header says the endpoints are not CoS-capable, 255 the edge router (or penultimate router, if using penultimate hop 256 popping) drops the packet. We recommend this scheme, which we 257 call `per-domain ECT checking', and define it more precisely in 258 the following section. Its chief drawback is that it can cause 259 packets to be forwarded after encountering congestion only to be 260 dropped at the egress of the MPLS domain. The rationale for this 261 decision is given in Section 8.1. This scheme is an update to RFC 262 3032 [RFC3032] and RFC 3270 [RFC3270]. 264 2.4. The Scope of this Change 266 There are several places in the RFCs that has explicitly updated by 267 this document that refrence the "Exp field", sometimes they refer to 268 the field as "Exp bits", "EXP bits" and "EXP". In all those 269 instances the references SHOULD be taken to reference the CoS field. 271 There are also other RFCs, e.g. RFC 3272 [RFC3272], RFC 3443 272 [RFC3443], RFC 3469 [RFC3469], RFC 3564 [RFC3564], RFC 3985 273 [RFC3985], RFC 4182 [RFC4182], RFC 4364 [RFC4364], RFC 4379 274 [RFC4379], RFC 4448 [RFC4448] and RFC 4761 [RFC4761] that references 275 the "Exp field", sometimes they refer to the field as "Exp bits", 276 "EXP bits" and "EXP". For all RFCs, including but not limited to 277 those mentioned in this paragraph, such references SHOULD be taken to 278 reference the CoS field. 280 3. Use of the CoS field 282 Due to the limited number of bits in the CoS field, their use for QoS 283 and ECN functions is intended to be flexible. These funtions may 284 rewrite all or some of the bits in the CoS field. 286 Current implementations look at the CoS field with and without label 287 context and the CoS field may be copied to the label stack entries 288 that are pushed onto the label stack. This is to avoid the pushed 289 label stack entries having a different CoS field. 291 4. IANA considerations 293 There are no request for IANA allocation of code points in this 294 document. 296 5. Security considerations 298 This document only changes the name of one field in the MPLS Shim 299 Header and thus does not introduce any new security considerations. 301 6. Acknowledgments 303 The author would like to thank Stewart Bryant, Bruce Davie, George 304 Swallow, Rajiv Asatiand Francois Le Faucheur for their input to and 305 review of the current document. 307 The author also like to thanks George Swallow, Khatri Paresh and Phil 308 Bedard for their help with grammar and spelling, and a special thanks 309 to Adrian Farrel for a careful review and help trawling the RFC-sea 310 for RFCs that references the EXP field. 312 7. References 314 7.1. Normative References 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 320 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 321 Encoding", RFC 3032, January 2001. 323 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 324 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 325 Protocol Label Switching (MPLS) Support of Differentiated 326 Services", RFC 3270, May 2002. 328 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 329 Xiao, "Overview and Principles of Internet Traffic 330 Engineering", RFC 3272, May 2002. 332 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 333 in Multi-Protocol Label Switching (MPLS) Networks", 334 RFC 3443, January 2003. 336 [RFC3469] Sharma, V. and F. Hellstrand, "Framework for Multi- 337 Protocol Label Switching (MPLS)-based Recovery", RFC 3469, 338 February 2003. 340 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 341 Differentiated Services-aware MPLS Traffic Engineering", 342 RFC 3564, July 2003. 344 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 345 Edge (PWE3) Architecture", RFC 3985, March 2005. 347 [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS 348 Explicit NULL", RFC 4182, September 2005. 350 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 351 Networks (VPNs)", RFC 4364, February 2006. 353 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 354 Label Switched (MPLS) Data Plane Failures", RFC 4379, 355 February 2006. 357 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 358 "Encapsulation Methods for Transport of Ethernet over MPLS 359 Networks", RFC 4448, April 2006. 361 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 362 (VPLS) Using BGP for Auto-Discovery and Signaling", 363 RFC 4761, January 2007. 365 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 366 Marking in MPLS", RFC 5129, January 2008. 368 7.2. Informative references 370 [Shayman] Shayman, M. and R. Jaeger, University of Michigan, "Using 371 ECN to Signal Congestion Within an MPLS Domain", Work in 372 Progress, November 2000.", . 375 Author's Address 377 Loa Andersson 378 Acreo AB 380 Email: loa@pi.nu 382 Full Copyright Statement 384 Copyright (C) The IETF Trust (2008). 386 This document is subject to the rights, licenses and restrictions 387 contained in BCP 78, and except as set forth therein, the authors 388 retain all their rights. 390 This document and the information contained herein are provided on an 391 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 392 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 393 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 394 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 395 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 396 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 398 Intellectual Property 400 The IETF takes no position regarding the validity or scope of any 401 Intellectual Property Rights or other rights that might be claimed to 402 pertain to the implementation or use of the technology described in 403 this document or the extent to which any license under such rights 404 might or might not be available; nor does it represent that it has 405 made any independent effort to identify any such rights. Information 406 on the procedures with respect to rights in RFC documents can be 407 found in BCP 78 and BCP 79. 409 Copies of IPR disclosures made to the IETF Secretariat and any 410 assurances of licenses to be made available, or the result of an 411 attempt made to obtain a general license or permission for the use of 412 such proprietary rights by implementers or users of this 413 specification can be obtained from the IETF on-line IPR repository at 414 http://www.ietf.org/ipr. 416 The IETF invites any interested party to bring to its attention any 417 copyrights, patents or patent applications, or other proprietary 418 rights that may cover technology that may be required to implement 419 this standard. Please address the information to the IETF at 420 ietf-ipr@ietf.org.