rfc-5462

Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field

L. Andersson, R. Asati

date2009-02 streamIETF areartg wgmpls statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc5462 doi10.17487/RFC5462 errataview

The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined 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 Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not 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, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]

updates

rfc-3032 — MPLS Label Stack Encoding
rfc-3270 — Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
rfc-3272 — Overview and Principles of Internet Traffic Engineering
rfc-3443 — Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks
rfc-3469 — Framework for Multi-Protocol Label Switching (MPLS)-based Recovery
rfc-3564 — Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering
rfc-3985 — Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
rfc-4182 — Removing a Restriction on the use of MPLS Explicit NULL
rfc-4364 — BGP/MPLS IP Virtual Private Networks (VPNs)
rfc-4379 — Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
rfc-4448 — Encapsulation Methods for Transport of Ethernet over MPLS Networks
rfc-4761 — Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
rfc-5129 — Explicit Congestion Marking in MPLS

Extracted elements (13)

design-rationale §1

The name 'Traffic Class field' (TC field) was chosen over the original 'Class of Service field' because the field's use had evolved beyond simple CoS: RFC 3270 defined EXP-Inferred-PSC LSPs and RFC 5129 extended it to carry explicit congestion marking (ECN) information. The broader name better covers all potential uses.

mpls, qos, ecn, diffserv

design-rationale §1

The TC field in MPLS relates to an MPLS-encapsulated packet the same way the IPv6 TC field relates to an IPv6 packet, or the IPv4 Precedence field relates to an IPv4 packet, providing a consistent cross-protocol analogy for traffic classification.

mpls, ip, qos, diffserv

design-rationale §1

The three-bit field in the MPLS label stack entry was originally named 'EXP' (experimental use) in RFC 3032 because the exact use as a Class of Service field was not agreed upon at publication time. The 'experimental use' designation led other SDOs and implementors to assume the field could be used for arbitrary purposes, necessitating the rename.

mpls, qos, diffserv

interoperability-note §3

Current implementations look at the TC field with and without label context. The TC field may be copied to label stack entries pushed onto the label stack to avoid inconsistency where newly pushed entries would have different TC values from the rest of the stack.

mpls, qos

interoperability-note §1

RFC 3270 and RFC 5129 did not explicitly state they updated RFC 3032, and this relationship was not captured in the RFC repository until work on RFC 5462 began. RFC 5462 corrects this by formally noting the update relationships.

mpls, process

interoperability-note §2.4

The rename from EXP to TC applies to all places the field is referenced in IETF RFCs and other IETF documents. This includes all uses of 'Exp field', 'Exp bits', 'EXP bits', or 'EXP' in the 13 RFCs explicitly updated: 3032, 3270, 3272, 3443, 3469, 3564, 3985, 4182, 4364, 4379, 4448, 4761, and 5129.

mpls, qos

normative-requirement §2.2 MUST NOT

All references in RFC 3270 to the EXP field now refer to the TC field, and the term E-LSP is retained (now meaning 'Explicitly TC-encoded-PSC LSP') since the acronym is in widespread use.

mpls, qos, diffserv

normative-requirement §2.3 RECOMMENDED

All references in RFC 5129 to the EXP field now refer to the TC field. In the per-domain ECT checking scheme, if an interior LSR has marked ECN in the TC field of the shim header but the IP header says endpoints are not ECN-capable, the edge or penultimate router drops the packet.

mpls, ecn, qos

protocol-element §2.2

E-LSP is redefined from 'EXP-Inferred-PSC LSP' to 'Explicitly TC-encoded-PSC LSP'. The TC field of the MPLS Shim Header is used by the LSR to determine the PHB (Per Hop Behavior) to be applied to the packet, including both the PSC and the drop preference.

mpls, qos, diffserv

protocol-element §3

The TC field's use for QoS and ECN functions is intended to be flexible due to the limited number of bits (3). These functions may rewrite all or some of the bits in the TC field.

mpls, qos, ecn

protocol-element §2.1

The Traffic Class (TC) field is a three-bit field in the MPLS label stack entry used to carry traffic class information. It supersedes the 'EXP field' name in all IETF RFCs and documents; RFC 3270 and RFC 5129 define how to use the field.

mpls, qos, diffserv

security-consideration §4

RFC 5462 only changes the name of one field in the MPLS shim header and thus does not introduce any new security considerations.

mpls, security

wire-format §2.1

The MPLS label stack entry is a 32-bit field containing: Label (20 bits), TC/Traffic Class field (3 bits, formerly EXP), S/Bottom of Stack (1 bit), and TTL/Time to Live (8 bits). The three-bit TC field replaces the previously named 'EXP' field in Figure 1 of RFC 3032.

mpls, qos, diffserv