draft-ietf-mpls-cosfield-def-05.txt   draft-ietf-mpls-cosfield-def-06.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 October 15, 2008 3469, RFC 3564, RFC 3985, RFC November 17, 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: April 18, 2009 Expires: May 21, 2009
"EXP field" renamed to "Traffic Class field" "EXP field" renamed to "Traffic Class field"
draft-ietf-mpls-cosfield-def-05.txt draft-ietf-mpls-cosfield-def-06.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 39
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 April 18, 2009. This Internet-Draft will expire on May 21, 2009.
Abstract Abstract
The early MPLS documents defined the form of the MPLS Label Stack The early MPLS documents defined the form of the MPLS Label Stack
entry. This include a three bit field called the "EXP field". The entry. This include a three bit field called the "EXP field". The
exact use of this field was not defined by these documents, except to exact use of this field was not defined by these documents, except to
state that it was to be "reserved for experimental use". 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" field, it was not named the "Class of Service" (CoS) field
skipping to change at page 3, line 8 skipping to change at page 3, line 8
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 . . . . . . . . . . . . . . . . . . . . . . 6 2. Details of change . . . . . . . . . . . . . . . . . . . . . . 5
2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. The Scope of this Change . . . . . . . . . . . . . . . . . 9 2.4. The Scope of this Change . . . . . . . . . . . . . . . . . 8
3. Use of the TC field . . . . . . . . . . . . . . . . . . . . . 11 3. Use of the TC field . . . . . . . . . . . . . . . . . . . . . 10
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security considerations . . . . . . . . . . . . . . . . . . . 13 5. Security considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative references . . . . . . . . . . . . . . . . . . 16 7.2. Informative references . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 17
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" information. The field was actually called the "Class of
skipping to change at page 4, line 25 skipping to change at page 4, line 25
that was publshed as RFC 3032. However at the time that RFC 3032 was that was publshed as RFC 3032. However at the time that RFC 3032 was
published the exact usage of this "Class of Service" field was not published the exact usage of this "Class of Service" field was not
agreed and the field was designated as "Experimental use". agreed and the field was designated as "Experimental use".
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 orignal "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 wrt 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 LSPs called EXP-
Inferred-PSC LSP (E-LSPs) was specified. Inferred-PSC LSP (E-LSPs) was specified.
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. 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
to an IPv6 encapsulted packet or the IPv4 Precedence field relates to
an IPv4 encapsulated packet.
The defintions of how the EXP field are used are perfectly clear in The defintions of how the EXP field are 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 is not captured in the RFC
respository. This document updates RFC 3032, RFC 3270 and RFC 5129 respository. This document updates RFC 3032, RFC 3270 and RFC 5129
to clarify the intended usage of the TC field. Section 2 explains to clarify the intended usage of the TC field. Section 2 explains
the changes. the changes.
This document, hence, uses the name "Traffic Class Field (TC Field)",
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
to an IPv6 encapsulted packet or the IPv4 Precedence field relates to
an IPv4 encapsulated packet.
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 8, line 13 skipping to change at page 7, line 13
a. A new paragraph is added at the end of section 1 "Introduction": a. A new paragraph is added at the end of section 1 "Introduction":
The EXP field has been renamed to the TC field, and thus all The EXP field has been renamed to the TC field, and thus all
references in RFC 3270 to EXP field SHOULD be taken to refer references in RFC 3270 to EXP field SHOULD be taken to refer
to the TC field. to the TC field.
b. A new term is added to section 1.1 "Terminology": b. A new term is added to section 1.1 "Terminology":
TC Traffic Class (replaces the term EXP) TC Traffic Class (replaces the term EXP)
c. A new acronym is added at the end of section 1.1 "Terminology": c. In section 1.1 "Terminology" the acronym E-LSP is now understood
to mean :
T-LSP TC-Inferred-PSC LSP (future replacement of the term E-LSP Explicitly-Inferred-PSC LSP
E-LSP)
Section 1.2 on page 5 in RFC 3270 is now changed to: Section 1.2 on page 5 in RFC 3270 is now changed to:
1.2 EXP-Inferred-PSC LSPs (E-LSP) 1.2 Explicitly-Inferred-PSC LSPs (E-LSP)
The EXP field has been renamed to the TC field, and thus all The EXP field has been renamed to the TC field, and thus all
references in RFC 3270 to EXP field SHOULD be taken to refer to references in RFC 3270 to EXP field SHOULD be taken to refer to
the TC field. However, we retain the term E-LSP (EXP-Inferred-PSC the TC field. However, we retain the acronym E-LSP (Explicitly-
LSP) as it is in widespread use. Inferred-PSC LSP) as the acronym is in widespread use.
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 TC field of the MPLS Shim OAs these BAs span. With such LSPs, the TC field of the MPLS Shim
Header is used by the LSR to determine the PHB to be applied to Header is used by the LSR to determine the PHB to be applied to
the packet. This includes both the PSC and the drop preference. the packet. This includes both the PSC and the drop preference.
We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since We refer to such LSPs as "Explicitly-inferred-PSC LSPs" (E-LSP),
the PSC of a packet transported on this LSP depends on the TC since the PSC of a packet transported on this LSP depends on the
field (previously called the EXP field) value for that packet. TC field (previously called the EXP field) value for that packet.
In future documents the term "TC-inferred-PSC LSPs" (T-LSP) may be
be used to refer to such LSPs as , since the PSC of a packet
transported on this LSP depends on the TC field value for that
packet. The meaning of E-SLP and T-LSP is the same.
The mapping from the TC field to the PHB (i.e., to PSC and drop The mapping from the TC field to the PHB (i.e., to PSC and drop
precedence) for a given such LSP, is either explicitly signaled at precedence) for a given such LSP, is either explicitly signaled at
label set-up or relies on a pre-configured mapping. label set-up or relies on a pre-configured mapping.
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].
skipping to change at page 9, line 30 skipping to change at page 8, line 30
decision is given in Section 8.1. decision is given in Section 8.1.
RFC 5129 is now updated like this: RFC 5129 is now updated like this:
A new paragraph is added at the end of section 1.1 "Background": 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 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 references in RFC 5129 to EXP field SHOULD be taken to refer to
the TC field. the TC field.
Section 2 (bullet 3) on page 6 ofis now changed to: 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
skipping to change at page 14, line 8 skipping to change at page 13, line 8
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
Swallow, Rajiv Asati and Francois Le Faucheur for their input to and Swallow, and Francois Le Faucheur for their input to and review of
review of the current document. the current document.
The author also like to thanks George Swallow, Khatri Paresh and Phil The author also like to thanks George Swallow, Khatri Paresh and Phil
Bedard for their help with grammar and spelling, and a special thanks Bedard for their help with grammar and spelling, and a special thanks
to Adrian Farrel for a careful review and help trawling the RFC-sea to Adrian Farrel for a careful review and help trawling the RFC-sea
for RFCs that references the EXP field. for RFCs that references the EXP field.
7. References 7. References
7.1. Normative References 7.1. Normative References
 End of changes. 15 change blocks. 
43 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/