| < draft-ietf-mpls-cosfield-def-07.txt | draft-ietf-mpls-cosfield-def-08.txt > | |||
|---|---|---|---|---|
| Network Working Group L. Andersson | Network Working Group L. Andersson | |||
| Internet-Draft Acreo AB | Internet-Draft Acreo AB | |||
| Updates: RFC 3032, RFC 3270, RFC R. Asati | Updates: RFC 3032, RFC 3270, RFC R. Asati | |||
| 5129, RFC 3272, RFC 3443, RFC Cisco Systems | 5129, RFC 3272, RFC 3443, RFC Cisco Systems | |||
| 3469, RFC 3564, RFC 3985, RFC November 17, 2008 | 3469, RFC 3564, RFC 3985, RFC December 5, 2008 | |||
| 4182, RFC 4364, RFC 4379, RFC | 4182, RFC 4364, RFC 4379, RFC | |||
| 4448, RFC 4761 (if approved) | 4448, RFC 4761 (if approved) | |||
| Intended status: Standards Track | Intended status: Standards Track | |||
| Expires: May 21, 2009 | Expires: June 8, 2009 | |||
| "EXP field" renamed to "Traffic Class field" | Multi-Protocol Label Switching (MPLS) label stack entry: "EXP" field | |||
| draft-ietf-mpls-cosfield-def-07.txt | renamed to "Traffic Class" field | |||
| draft-ietf-mpls-cosfield-def-08.txt | ||||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 39 ¶ | skipping to change at page 1, line 40 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on May 21, 2009. | This Internet-Draft will expire on June 8, 2009. | |||
| Abstract | Abstract | |||
| The early MPLS documents defined the form of the MPLS Label Stack | The early Multiprotocol Label Switching (MPLS) documents defined the | |||
| entry. This include a three bit field called the "EXP field". The | form of the MPLS Label Stack entry. This includes a three bit field | |||
| exact use of this field was not defined by these documents, except to | called the "EXP field". The exact use of this field was not defined | |||
| state that it was to be "reserved for experimental use". | by these documents, except to state that it was to be "reserved for | |||
| experimental use". | ||||
| Although the intended use of the EXP field was as a "Class of | Although the intended use of the EXP field was as a "Class of | |||
| Service" field, it was not named the "Class of Service" (CoS) field | Service" (CoS) field, it was not named the CoS field by these early | |||
| by these early documents because the use of such a CoS field was not | documents because the use of such a CoS field was not considered to | |||
| considered to be sufficiently defined. Today a number of standards | be sufficiently defined. Today a number of standards documents | |||
| documents define its usage as a CoS field. . | define its usage as a CoS field. . | |||
| To avoid misunderstanding about how this field may be used, it has | To avoid misunderstanding about how this field may be used, it has | |||
| become increasingly necessary to rename this field. This document | become increasingly necessary to rename this field. This document | |||
| changes the name of the field to the "Traffic Class field" ("TC | changes the name of the field to the "Traffic Class field" ("TC | |||
| field".) In doing so it also updates documents that define the | field".) In doing so it also updates documents that define the | |||
| current use of the EXP this field. | current use of the EXP this field. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Details of change . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Details of change . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 2.4. The Scope of this Change . . . . . . . . . . . . . . . . . 8 | 2.4. The Scope of this Change . . . . . . . . . . . . . . . . . 9 | |||
| 3. Use of the TC field . . . . . . . . . . . . . . . . . . . . . 10 | 3. Use of the TC field . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 | 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5. Security considerations . . . . . . . . . . . . . . . . . . . 12 | 5. Security considerations . . . . . . . . . . . . . . . . . . . 13 | |||
| 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | |||
| 7.2. Informative references . . . . . . . . . . . . . . . . . . 15 | 7.2. Informative references . . . . . . . . . . . . . . . . . . 16 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 17 | Intellectual Property and Copyright Statements . . . . . . . . . . 18 | |||
| 1. Introduction | 1. Introduction | |||
| The format of a MPLS label stack entry is defined by RFC 3032 | The format of a MPLS label stack entry is defined by RFC 3032 | |||
| [RFC3032], include a three bit field called the "EXP field". The | [RFC3032], include a three bit field called the "EXP field". The | |||
| exact use of this field is not defined by RFC 3032 leaves, except to | exact use of this field is not defined by RFC 3032 leaves, except to | |||
| state that it is to be "reserved for experimental use". | state that it is to be "reserved for experimental use". | |||
| The EXP field, from the start, was intended to carry "Class of | The EXP field, from the start, was intended to carry "Class of | |||
| Service" information. The field was actually called the "Class of | Service" (CoS) information. The field was actually called the "Class | |||
| Service field" in the early versions of the working group document | of Service field" in the early versions of the working group document | |||
| that was publshed as RFC 3032. However at the time that RFC 3032 was | that was published as RFC 3032. However at the time that RFC 3032 | |||
| published the exact usage of this "Class of Service" field was not | was published the exact usage of this "Class of Service" field was | |||
| agreed and the field was designated as "Experimental use". | not agreed and the field was designated as "Experimental use"; hence | |||
| the name has since then been the "EXP Field". | ||||
| The designation "for Experimental use" has led other Standards | The designation "for Experimental use" has led other Standards | |||
| Development Organizations (SDO) and implementors to the assume that | Development Organizations (SDO) and implementors to the assume that | |||
| it possible to use the field for other purposes. This document | it possible to use the field for other purposes. This document | |||
| changes the name of the field to clearly indicate its use as a | changes the name of the field to clearly indicate its use as a | |||
| traffic classification field. | traffic classification field. | |||
| At first we discussed to use the original "CoS field" as the name for | At first we discussed to use the original "CoS field" as the name for | |||
| the field, but it has been pointed that this name does not cover the | the field, but it has been pointed that this name does not cover the | |||
| following changes wrt its usage, since RFC 3032 was published. | following changes with respect to its usage, since RFC 3032 was | |||
| published. | ||||
| 1. The use of the EXP field was first defined in RFC 3270 [RFC3270] | 1. The use of the EXP field was first defined in RFC 3270 [RFC3270] | |||
| where a method to define a variant of DiffServ LSPs called EXP- | where a method to define a variant of DiffServ Label Switched | |||
| Inferred-PSC LSP (E-LSPs) was specified. | Paths (LSP) called EXP-Inferred-PSC LSP (E-LSPs) was specified. | |||
| The PSC is a two stage acroynym that is expanded as Per Hop | ||||
| Behavior (PHB) and PHB Scheduling Class (PSC). | ||||
| 2. The use of the EXP field as defined in RFC 3270 has been further | 2. The use of the EXP field as defined in RFC 3270 has been further | |||
| extended in RFC 5129 [RFC5129], where methods for explicit | extended in RFC 5129 [RFC5129], where methods for explicit | |||
| congestion marking in MPLS are defined. | congestion marking in MPLS are defined. | |||
| This document, hence, uses the name "Traffic Class Field (TC Field)", | This document, hence, uses the name "Traffic Class Field (TC Field)", | |||
| which better covers the potential use. The MPLS TC field relates to | which better covers the potential use. The MPLS TC field relates to | |||
| an MPLS encapsulated packet the same way as the IPv6 TC field relates | an MPLS encapsulated packet the same way as the IPv6 TC field relates | |||
| to an IPv6 encapsulted packet or the IPv4 Precedence field relates to | to an IPv6 encapsulted packet or the IPv4 Precedence field relates to | |||
| an IPv4 encapsulated packet. | an IPv4 encapsulated packet. | |||
| The defintions of how the EXP field are used are perfectly clear in | The definitions of how the EXP field is used are perfectly clear in | |||
| RFC 3270 and RFC 5129. However, these RFCs do not explicitly state | RFC 3270 and RFC 5129. However, these RFCs do not explicitly state | |||
| they update RFC 3032, and this fact is not captured in the RFC | they update RFC 3032, and this fact was not captured in the RFC | |||
| respository. This document updates RFC 3032, RFC 3270 and RFC 5129 | repository until after the work on this document were started. This | |||
| to clarify the intended usage of the TC field. Section 2 explains | document updates RFC 3032, RFC 3270 and RFC 5129 to clarify the | |||
| the changes. | intended usage of the TC field. Section 2 explains the changes. | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| 2. Details of change | 2. Details of change | |||
| The three RFCs are now updated according to the following. | The three RFCs are now updated according to the following. | |||
| 2.1. RFC 3032 | 2.1. RFC 3032 | |||
| skipping to change at page 6, line 16 ¶ | skipping to change at page 7, line 16 ¶ | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label | |||
| | Label | TC |S| TTL | Stack | | Label | TC |S| TTL | Stack | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry | |||
| Label: Label Value, 20 bits | Label: Label Value, 20 bits | |||
| CoS: Traffic Class field, 3 bits | CoS: Traffic Class field, 3 bits | |||
| S: Bottom of Stack, 1 bit | S: Bottom of Stack, 1 bit | |||
| TTL: Time to Live, 8 bits | TTL: Time to Live, 8 bits | |||
| Figure 1 | Figure 1 (new) | |||
| Note: The designation of the picture above as "Figure 1 new" is | ||||
| introduced as a way to distinguish the figures in this draft. It | ||||
| will still be "Figure 1." in RFC 3032. | ||||
| 2.2. RFC 3270 | 2.2. RFC 3270 | |||
| RFC 3270 says on page 6: | RFC 3270 says on page 6: | |||
| 1.2 EXP-Inferred-PSC LSPs (E-LSP) | 1.2 EXP-Inferred-PSC LSPs (E-LSP) | |||
| A single LSP can be used to support one or more OAs. Such LSPs | A single LSP can be used to support one or more OAs. Such LSPs | |||
| can support up to eight BAs of a given FEC, regardless of how many | can support up to eight BAs of a given FEC, regardless of how many | |||
| OAs these BAs span. With such LSPs, the EXP field of the MPLS | OAs these BAs span. With such LSPs, the EXP field of the MPLS | |||
| skipping to change at page 8, line 7 ¶ | skipping to change at page 9, line 7 ¶ | |||
| This is an update to RFC 3032 [RFC3032] in line with the original | This is an update to RFC 3032 [RFC3032] in line with the original | |||
| intent of how this field in the MPLS Shim Header should be used | intent of how this field in the MPLS Shim Header should be used | |||
| (as TC field). The RFC 3270 has itself been updated by RFC 5129 | (as TC field). The RFC 3270 has itself been updated by RFC 5129 | |||
| [RFC5129]. | [RFC5129]. | |||
| Detailed operations of E-LSPs are specified in section 3 of | Detailed operations of E-LSPs are specified in section 3 of | |||
| RFC3270. | RFC3270. | |||
| 2.3. RFC 5129 | 2.3. RFC 5129 | |||
| RFC 5129 is now updated like this: | ||||
| A new paragraph is added at the end of section 1.1 "Background": | ||||
| The EXP field has been renamed to the TC field, and thus all | ||||
| references in RFC 5129 to EXP field SHOULD be taken to refer to | ||||
| the TC field. | ||||
| Section 2 (bullet 3) on page 6 of RFC 5129 says: | Section 2 (bullet 3) on page 6 of RFC 5129 says: | |||
| o A third possible approach was suggested by [Shayman]. In this | o A third possible approach was suggested by [Shayman]. In this | |||
| scheme, interior LSRs assume that the endpoints are ECN-capable, | scheme, interior LSRs assume that the endpoints are ECN-capable, | |||
| but this assumption is checked when the final label is popped. If | but this assumption is checked when the final label is popped. If | |||
| an interior LSR has marked ECN in the EXP field of the shim | an interior LSR has marked ECN in the EXP field of the shim | |||
| header, but the IP header says the endpoints are not ECN-capable, | header, but the IP header says the endpoints are not ECN-capable, | |||
| the edge router (or penultimate router, if using penultimate hop | the edge router (or penultimate router, if using penultimate hop | |||
| popping) drops the packet. We recommend this scheme, which we | popping) drops the packet. We recommend this scheme, which we | |||
| call `per-domain ECT checking', and define it more precisely in | call `per-domain ECT checking', and define it more precisely in | |||
| the following section. Its chief drawback is that it can cause | the following section. Its chief drawback is that it can cause | |||
| packets to be forwarded after encountering congestion only to be | packets to be forwarded after encountering congestion only to be | |||
| dropped at the egress of the MPLS domain. The rationale for this | dropped at the egress of the MPLS domain. The rationale for this | |||
| decision is given in Section 8.1. | decision is given in Section 8.1. | |||
| RFC 5129 is now updated like this: | Section 2 (bullet 3) of RFC 5129 is now updated changed to: | |||
| A new paragraph is added at the end of section 1.1 "Background": | ||||
| The EXP field has been renamed to the TC field, and thus all | ||||
| references in RFC 5129 to EXP field SHOULD be taken to refer to | ||||
| the TC field. | ||||
| Section 2 (bullet 3) on page 6 is now changed to: | ||||
| o A third possible approach was suggested by [Shayman]. In this | o A third possible approach was suggested by [Shayman]. In this | |||
| scheme, interior LSRs assume that the endpoints are ECN-capable, | scheme, interior LSRs assume that the endpoints are ECN-capable, | |||
| but this assumption is checked when the final label is popped. If | but this assumption is checked when the final label is popped. If | |||
| an interior LSR has marked ECN in the TC field of the shim header, | an interior LSR has marked ECN in the TC field of the shim header, | |||
| but the IP header says the endpoints are not TC-capable, the edge | but the IP header says the endpoints are not TC-capable, the edge | |||
| router (or penultimate router, if using penultimate hop popping) | router (or penultimate router, if using penultimate hop popping) | |||
| drops the packet. We recommend this scheme, which we call `per- | drops the packet. We recommend this scheme, which we call `per- | |||
| domain ECT checking', and define it more precisely in the | domain ECT checking', and define it more precisely in the | |||
| following section. Its chief drawback is that it can cause | following section. Its chief drawback is that it can cause | |||
| packets to be forwarded after encountering congestion only to be | packets to be forwarded after encountering congestion only to be | |||
| dropped at the egress of the MPLS domain. The rationale for this | dropped at the egress of the MPLS domain. The rationale for this | |||
| decision is given in Section 8.1. This scheme is an update to RFC | decision is given in Section 8.1. This scheme is an update to RFC | |||
| 3032 [RFC3032] and RFC 3270 [RFC3270]. | 3032 [RFC3032] and RFC 3270 [RFC3270]. | |||
| 2.4. The Scope of this Change | 2.4. The Scope of this Change | |||
| There are several places in the RFCs that has explicitly updated by | There are several places in the RFCs that has explicitly updated by | |||
| this document that refrence the "Exp field", sometimes they refer to | this document that reference the "Exp field", sometimes they refer to | |||
| the field as "Exp bits", "EXP bits" and "EXP". In all those | the field as "Exp bits", "EXP bits" and "EXP". In all those | |||
| instances the references SHOULD be taken to reference the TC field. | instances the references SHOULD be taken to reference the TC field. | |||
| There are also other RFCs, e.g. RFC 3272 [RFC3272], RFC 3443 | There are also other RFCs, e.g. RFC 3272 [RFC3272], RFC 3443 | |||
| [RFC3443], RFC 3469 [RFC3469], RFC 3564 [RFC3564], RFC 3985 | [RFC3443], RFC 3469 [RFC3469], RFC 3564 [RFC3564], RFC 3985 | |||
| [RFC3985], RFC 4182 [RFC4182], RFC 4364 [RFC4364], RFC 4379 | [RFC3985], RFC 4182 [RFC4182], RFC 4364 [RFC4364], RFC 4379 | |||
| [RFC4379], RFC 4448 [RFC4448] and RFC 4761 [RFC4761] that references | [RFC4379], RFC 4448 [RFC4448] and RFC 4761 [RFC4761] that references | |||
| the "Exp field", sometimes they refer to the field as "Exp bits", | the "Exp field", sometimes they refer to the field as "Exp bits", | |||
| "EXP bits" and "EXP". For all RFCs, including but not limited to | "EXP bits" and "EXP". For all RFCs, including but not limited to | |||
| those mentioned in this paragraph, such references SHOULD be taken to | those mentioned in this paragraph, such references SHOULD be taken to | |||
| skipping to change at page 11, line 7 ¶ | skipping to change at page 12, line 7 ¶ | |||
| rewrite all or some of the bits in the TC field. | rewrite all or some of the bits in the TC field. | |||
| Current implementations look at the TC field with and without label | Current implementations look at the TC field with and without label | |||
| context and the TC field may be copied to the label stack entries | context and the TC field may be copied to the label stack entries | |||
| that are pushed onto the label stack. This is done to avoid that | that are pushed onto the label stack. This is done to avoid that | |||
| label stack entries that are pushed on to an existing label stack | label stack entries that are pushed on to an existing label stack | |||
| have different TF fields from the rest of the label stack entries. | have different TF fields from the rest of the label stack entries. | |||
| 4. IANA considerations | 4. IANA considerations | |||
| There are no request for IANA allocation of code points in this | There are no requests for IANA allocation of code points in this | |||
| document. | document. | |||
| 5. Security considerations | 5. Security considerations | |||
| This document only changes the name of one field in the MPLS Shim | This document only changes the name of one field in the MPLS Shim | |||
| Header and thus does not introduce any new security considerations. | Header and thus does not introduce any new security considerations. | |||
| 6. Acknowledgments | 6. Acknowledgments | |||
| The author would like to thank Stewart Bryant, Bruce Davie, George | The author would like to thank Stewart Bryant, Bruce Davie, George | |||
| End of changes. 17 change blocks. | ||||
| 52 lines changed or deleted | 62 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||