draft-ietf-mpls-cosfield-def-01.txt   draft-ietf-mpls-cosfield-def-02.txt 
Network Working Group L. Andersson Network Working Group L. Andersson
Internet-Draft Acreo AB Internet-Draft Acreo AB
Intended status: Standards Track June 4, 2008 Intended status: Standards Track June 11, 2008
Expires: December 6, 2008 Expires: December 13, 2008
"EXP field" renamed to "CoS Field" "EXP field" renamed to "CoS Field"
draft-ietf-mpls-cosfield-def-01.txt draft-ietf-mpls-cosfield-def-02.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 34 skipping to change at page 1, line 34
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 December 6, 2008. This Internet-Draft will expire on December 13, 2008.
Abstract Abstract
The early MPLS documents defined the MPLS format, this definition The early MPLS documents defined the form of a the MPLS Label Stack
includes three bit field called "EXP field". The documentats leaves entry. This include a three bit field called the "EXP field". The
the exact description of how the EXP field should be used undefined, exact use of this field was not defined by these documents, except to
it is said said to be for "experimental use". state that it is to be "reserved for experimental use".
The EXP field has from the start been intended to be used for "Class Although the intended use of the EXP field was as a "Class of
of Service". At the time the documents were published the use of Service" field, it was not named the "Class of Service" (CoS) field
such a CoS field were considered not to be defined well enough and by these early documents because the use of such a CoS field was not
the field were left for "Experimental use". considered to be sufficiently defined. Today a number of standards
documents define its usage as a CoS field. .
To avoid misunderstanding about how this field may be used this To avoid misunderstanding about how this field may be used this
document re-introduces the name "CoS field" for this field. In doing document re-introduces the name "CoS field" for this field. In doing
so it also updates documents that defines and uses this field. so it also updates documents that define the current usee of the EXP
this field.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Details of change . . . . . . . . . . . . . . . . . . . . . . 4 2. Details of change . . . . . . . . . . . . . . . . . . . . . . 5
2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Use of the CoS field . . . . . . . . . . . . . . . . . . . . . 7 3. Use of the CoS field . . . . . . . . . . . . . . . . . . . . . 8
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security considerations . . . . . . . . . . . . . . . . . . . 9 5. Security considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Informative references . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Informative references . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
The format of the MPLS label is defined in RFC 3032 [RFC3032], that The format of a MPLS label stack entry is defined by RFC 3032
definition includes three bit field called "EXP field". RFC 3032 [RFC3032], includes three bit field called "EXP field". The exact
leaves the exact description of how the EXP field should be used use of this field is not defined by RFC 3032 leaves,, except to state
undefined, it is said to be for "experimental use". that it is to be "reserved for experimental use".
The EXP field has from the start been intended to be used for "Class The EXP field, from the start, was intended to carry "Class of
of Service", the field were actually called "Class of Service field" Service" information, the field was actually called the "Class of
in the early versions of the working group document that was publshed Service field" in the early versions of the working group document
as RFC 3032. However at the time that RFC 3032 were published the that was publshed as RFC 3032. However at the time that RFC 3032 was
"Class of Service" were considered not to be defined well enough and published the exact usage of this "Class of Service" field was not
the field were left for "Experimental use". agreed and the field was designated as "Experimental use".
Since the "for Experimental use" terminology has lead other Standards The designation "for Experimental use" has lead 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 that Class of Service it possible to use the field for other purposes than Class of
we now changes the name of the field to clearly indicate its use. Service. This document changes the name of the field to clearly
indicate its use.
The use of the EXP field was first defined in RFC 3270 [RFC3270] 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). Inferred-PSC LSP (E-LSPs) were specified.
The use of the EXP field as defined in RFC 3270 has been further The use of the EXP field as defined in RFC 3270 has been further
extended in RFC 5129 [RFC5129], where methods for explicit congestion extended in RFC 5129 [RFC5129], where methods for explicit congestion
marking in MPLS is defined. marking in MPLS are defined.
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 it is never explicitly stated that RFC 3270 and RFC 5129. However, these RFCs do not explicitly state
these RFCs updates RFC 3032, and it is not captured in the RFC they update 3032, and it is not captured in the RFC respository.
respository. This document changes RFC 3032, RFC 3270 and RFC 5129 This document updates RFC 3032, RFC 3270 and RFC 5129 to clarify the
to capture these updates. intended usage of the CoS field.
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
The RFC 3032 state on page 3: The RFC 3032 states on page 3:
3. Experimental Use 3. Experimental Use
This three-bit field is reserved for experimental use. This three-bit field is reserved for experimental use.
This paragraph is now changed to: This paragraph is now changed to:
3. Class of Service (CoS) field 3. Class of Service (CoS) field
This three-bit field is used to carry Class of Service information This three-bit field is used to carry Class of Service information
skipping to change at page 5, line 7 skipping to change at page 6, line 7
The mapping from the EXP field to the PHB (i.e., to PSC and drop The mapping from the EXP 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.
Detailed operations of E-LSPs are specified in section 3 below. Detailed operations of E-LSPs are specified in section 3 below.
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 EXP-Inferred-PSC LSPs (E-LSP)
The EXP field have been renamed to the CoS field, and thus all The EXP field has been renamed to the CoS 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 CoS field. However, we retain the term E-LSP (EXP-Inferred- the CoS field. However, we retain the term E-LSP (EXP-Inferred-
PSC LSP) as it is in widespread use. PSC LSP) as it 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 CoS field of the MPLS OAs these BAs span. With such LSPs, the CoS field of the MPLS
Shim Header is used by the LSR to determine the PHB to be applied Shim Header is used by the LSR to determine the PHB to be applied
to the packet. This includes both the PSC and the drop to the packet. This includes both the PSC and the drop
preference. preference.
skipping to change at page 6, line 7 skipping to change at page 7, line 7
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 5219 is now updated like this: RFC 5219 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 have been renamed to the CoS field, and thus all The EXP field has been renamed to the CoS field, and thus all
references in RFC 5219 to EXP field SHOULD be taken to refer to references in RFC 5219 to EXP field SHOULD be taken to refer to
the CoS field. the CoS field.
Section 2 (bullet 3) on page 6 ofis now changed to: Section 2 (bullet 3) on page 6 ofis 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 CoS field of the shim an interior LSR has marked ECN in the CoS field of the shim
header, but the IP header says the endpoints are not CoS-capable, header, but the IP header says the endpoints are not CoS-capable,
skipping to change at page 7, line 8 skipping to change at page 8, line 8
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. 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].
3. Use of the CoS field 3. Use of the CoS field
Due to the limited number of bits the particular use of the bits is Due to the limited number of bits the particular use of the bits is
intended to be flexible - including the defininition of various QoS intended to be flexible - including the definition of various QoS and
and ECN functions. ECN functions.
Current implementations look at the CoS field with and without label Current implementations look at the CoS field with and without label
context and the CoS field may be copied to the labels that are pushed context and the CoS field may be copied to the labels that are pushed
onto the laabel stack. This is to avoid that the pushed labels has a onto the label stack. This is to avoid the pushed labels having a
different CoS field. different CoS field.
CoS and ECN funtions may rewrite all or some of the bits. CoS and ECN funtions may rewrite all or some of the bits.
4. IANA considerations 4. IANA considerations
There are no request for IANA allocation of code points in this There are no request 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 do not introduce any new security considerations. Header and thus does not introduce any new security considerations.
6. References 6. Acknowledgments
6.1. Normative References The author would like to thank Stewart Bryant, Bruce Davie, George
Swallow, and Francois Le Faucheur for their input to and review of
the current document.
The author also like to thanks George Swallow, Khatri Paresh and Phil
Bedard for their help with grammar and spelling.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. Services", RFC 3270, May 2002.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008. Marking in MPLS", RFC 5129, January 2008.
6.2. Informative references 7.2. Informative references
[Shayman] Shayman, M. and R. Jaeger, University of Michigan, "Using [Shayman] Shayman, M. and R. Jaeger, University of Michigan, "Using
ECN to Signal Congestion Within an MPLS Domain", Work in ECN to Signal Congestion Within an MPLS Domain", Work in
Progress, November 2000.", <http://www.watersprings.org/ Progress, November 2000.", <http://www.watersprings.org/
pub/id/draft-shayman-mpls-ecn-00.txt/>. pub/id/draft-shayman-mpls-ecn-00.txt/>.
Author's Address Author's Address
Loa Andersson Loa Andersson
Acreo AB Acreo AB
 End of changes. 23 change blocks. 
55 lines changed or deleted 68 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/