Network Working Group L. Andersson
Request for Comments: 5462 Acreo AB
Updates: 3032, 3270, 3272, 3443, 3469, R. Asati
3564, 3985, 4182, 4364, 4379, Cisco Systems
4448, 4761, 5129 February 2009
Category: Standards Track
Network Working Group L. Andersson
Request for Comments: 5462 Acreo AB
Updates: 3032, 3270, 3272, 3443, 3469, R. Asati
3564, 3985, 4182, 4364, 4379, Cisco Systems
4448, 4761, 5129 February 2009
Category: Standards Track
Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field
多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“Traffic Class”字段
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
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".
早期的多协议标签交换（MPLS）文档定义了MPLS标签堆栈项的形式。这包括一个称为“EXP字段”的三位字段。这些文件并未对该领域的确切用途进行定义，只是说明该领域将“保留供实验使用”。
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.
尽管EXP字段的预期用途是作为“服务类别”（CoS）字段，但这些早期文档并未将其命名为CoS字段，因为此类CoS字段的使用未被充分定义。今天，许多标准文档将其定义为CoS字段。
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.
为了避免对如何使用此字段产生误解，越来越有必要重命名此字段。本文档将字段名称更改为“交通类别字段”（“TC字段”）。在此过程中，它还会更新定义EXP字段当前使用情况的文档。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Details of Change . . . . . . . . . . . . . . . . . . . . . . 3
2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. The Scope of This Change . . . . . . . . . . . . . . . . . 7
3. Use of the TC field . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Details of Change . . . . . . . . . . . . . . . . . . . . . . 3
2.1. RFC 3032 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. RFC 3270 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. RFC 5129 . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. The Scope of This Change . . . . . . . . . . . . . . . . . 7
3. Use of the TC field . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
The format of an MPLS label stack entry is defined by RFC 3032 [RFC3032] to include a three-bit field called the "EXP field". The exact use of this field is not defined by RFC 3032, except to state that it is to be "reserved for experimental use".
MPLS标签堆栈项的格式由RFC 3032[RFC3032]定义，包括一个称为“EXP字段”的三位字段。RFC 3032未定义该字段的确切用途，只是说明该字段“保留供实验使用”。
The EXP field, from the start, was intended to carry "Class of Service" (CoS) information. The field was actually called the "Class of Service field" in early versions of the working group document that was published as RFC 3032. However, at the time that RFC 3032 was published, the exact usage of this "Class of Service" field was not agreed upon and the field was designated as "experimental use"; hence, the name has since been the "EXP field".
EXP字段从一开始就是用来携带“服务类别”（CoS）信息的。在作为RFC 3032发布的工作组文档的早期版本中，该字段实际上被称为“服务类字段”。然而，在RFC 3032发布时，未就“服务类别”字段的确切用法达成一致，该字段被指定为“实验用途”；因此，该名称一直是“EXP字段”。
The designation "for experimental use" has led other Standards Development Organizations (SDOs) and implementors to assume that it is possible to use the field for other purposes. This document changes the name of the field to clearly indicate its use as a traffic classification field.
“实验性使用”的名称已导致其他标准开发组织（SDO）和实施者认为可以将该领域用于其他目的。本文档更改了字段的名称，以清楚地表明其作为流量分类字段的用途。
At first, we discussed using the original "CoS field" as the name for the field, but it has been pointed out that this name does not cover the following changes that have occurred with respect to its usage since RFC 3032 was published.
首先，我们讨论了使用原始的“CoS字段”作为字段的名称，但已经指出，该名称不包括自RFC 3032发布以来在其使用方面发生的以下更改。
1. The use of the EXP field was first defined in RFC 3270 [RFC3270], where a method to define a variant of Diffserv Label Switched Paths (LSP), called EXP-Inferred-PSC LSP (E-LSPs), was specified. PSC is a two-stage acronym that is expanded as PHB (Per Hop Behavior) Scheduling Class (PSC).
1. EXP字段的使用首先在RFC 3270[RFC3270]中定义，其中指定了一种定义区分服务标签交换路径（LSP）变体的方法，称为EXP推断PSC LSP（E-LSP）。PSC是两个阶段的首字母缩略词，扩展为PHB（每跳行为）调度类（PSC）。
2. The use of the EXP field as defined in RFC 3270 has been further extended in RFC 5129 [RFC5129], where methods for explicit congestion marking in MPLS are defined.
2. RFC 5129[RFC5129]进一步扩展了RFC 3270中定义的EXP字段的使用，其中定义了MPLS中显式拥塞标记的方法。
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 encapsulated packet or the IPv4 Precedence field relates to an IPv4 encapsulated packet.
因此，本文档使用了名称“Traffic Class field（TC field）”，这更好地涵盖了潜在用途。MPLS TC字段与MPLS封装数据包的关联方式与IPv6 TC字段与IPv6封装数据包或IPv4优先级字段与IPv4封装数据包的关联方式相同。
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 they update RFC 3032, and this fact was not captured in the RFC repository until after work on this document was started.
EXP字段如何使用的定义在RFC 3270和RFC 5129中非常清楚。但是，这些RFC并没有明确声明它们更新了RFC 3032，并且在开始处理此文档之前，RFC存储库中没有捕获到这一事实。
This document updates RFC 3032, RFC 3270, and RFC 5129 to clarify the intended usage of the TC field. The changes to these RFCs requires some changes to the actual text in those documents; Section 2 explains the changes.
本文件更新了RFC 3032、RFC 3270和RFC 5129，以澄清TC字段的预期用途。对这些RFC的更改需要对这些文件中的实际文本进行一些更改；第2节解释了这些变化。
This document also updates several other RFCs; see Section 2.4. For these documents, the change is limited to changing the name of the Label Stack entry field.
本文件还更新了其他几个RFC；见第2.4节。对于这些文档，更改仅限于更改标签堆栈条目字段的名称。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The three RFCs 3032, 3270, and 5129 are now updated according to the following.
三个RFC 3032、3270和5129现在根据以下内容进行更新。
RFC 3032 states on page 4:
RFC 3032第4页说明：
3. Experimental Use
3. 实验用途
This three-bit field is reserved for experimental use.
此三位字段保留供实验使用。
This paragraph is now changed to:
本段现改为：
3. Traffic Class (TC) field
3. 交通等级（TC）字段
This three-bit field is used to carry traffic class information, and the change of the name is applicable to all places it occurs in IETF RFCs and other IETF documents.
此三位字段用于承载流量类别信息，名称更改适用于IETF RFCs和其他IETF文档中出现的所有位置。
RFC 3270 and RFC 5129 update the definition of the TC field and describe how to use the field.
RFC 3270和RFC 5129更新TC字段的定义，并说明如何使用该字段。
In Figure 1 on page 3 in RFC 3032, the format of a label stack entry is specified as:
在RFC 3032第3页的图1中，标签堆栈条目的格式指定为：
0 1 2 3
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 | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
0 1 2 3
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 | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Label: Label Value, 20 bits Exp: Experimental Use, 3 bits S: Bottom of Stack, 1 bit TTL: Time to Live, 8 bits
标签：标签值，20位Exp：实验使用，3位S：堆栈底部，1位TTL：生存时间，8位
Figure 1
图1
Figure 1 in RFC 3032 is now changed to match the change of name to TC field:
RFC 3032中的图1现在更改为与名称更改为TC字段相匹配：
0 1 2 3
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 | TC |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
0 1 2 3
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 | TC |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Label: Label Value, 20 bits TC: Traffic Class field, 3 bits S: Bottom of Stack, 1 bit TTL: Time to Live, 8 bits
标签：标签值，20位TC：流量类字段，3位S：堆栈底部，1位TTL：生存时间，8位
Figure 1 (new)
图1（新）
Note: The designation of the picture above as "Figure 1 (new)" is introduced as a way to distinguish the figures in this document. It will still be "Figure 1" in RFC 3032.
注：将上述图片命名为“图1（新）”是为了区分本文件中的图片。在RFC 3032中仍然是“图1”。
RFC 3270 says on page 6:
RFC 3270在第6页上说：
1.2 EXP-Inferred-PSC LSPs (E-LSP)
1.2 EXP推断的PSC LSP（E-LSP）
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 OAs these BAs span. With such LSPs, the EXP field of the MPLS 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 preference.
单个LSP可用于支持一个或多个OA。这种LSP最多可以支持给定FEC的八个BAs，而不管这些BAs跨越多少个OA。对于这种lsp，LSR使用MPLS垫片报头的EXP字段来确定要应用于分组的PHB。这包括PSC和drop首选项。
We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the PSC of a packet transported on this LSP depends on the EXP field value for that packet.
我们将此类LSP称为“EXP推断的PSC LSP”（E-LSP），因为在此LSP上传输的数据包的PSC取决于该数据包的EXP字段值。
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 label set-up or relies on a pre-configured mapping.
对于给定的此类LSP，从EXP字段到PHB（即到PSC和drop优先级）的映射要么在标签设置时显式发出信号，要么依赖于预配置的映射。
Detailed operations of E-LSPs are specified in section 3 below.
下文第3节规定了电子LSP的详细操作。
RFC 3270 is now updated like this:
RFC 3270现在更新如下：
a. A new paragraph is added at the end of Section 1 "Introduction":
a. 在第1节“导言”末尾添加了一个新段落：
The EXP field has been renamed the TC field, and thus all references in RFC 3270 to the EXP field now refer to the TC field.
EXP字段已重命名为TC字段，因此RFC 3270中对EXP字段的所有引用现在都指向TC字段。
b. A new term is added to Section 1.1 "Terminology":
b. 第1.1节“术语”中增加了一个新术语：
TC Traffic Class (replaces the term EXP)
TC流量等级（取代术语EXP）
c. In Section 1.1 "Terminology", the acronym E-LSP is now understood to mean:
c. 在第1.1节“术语”中，首字母缩略词E-LSP现理解为：
E-LSP Explicitly TC-encoded-PSC LSP
E-LSP显式TC编码PSC LSP
Section 1.2 on page 6 in RFC 3270 is now changed to:
RFC 3270第6页第1.2节现在更改为：
1.2 Explicitly TC-encoded-PSC LSPs (E-LSP)
1.2 显式TC编码的PSC LSP（E-LSP）
The EXP field has been renamed to the TC field, and thus all references in RFC 3270 to EXP field now refer to the TC field. However, we retain the acronym E-LSP (Explicitly TC-encoded-PSC LSP) as the acronym is in widespread use.
EXP字段已重命名为TC字段，因此RFC 3270 to EXP字段中的所有引用现在都指向TC字段。然而，我们保留了首字母缩略词E-LSP（显式TC编码的PSC LSP），因为该首字母缩略词被广泛使用。
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 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 the packet. This includes both the PSC and the drop preference.
单个LSP可用于支持一个或多个OA。这种LSP最多可以支持给定FEC的八个BAs，而不管这些BAs跨越多少个OA。对于这种lsp，LSR使用MPLS垫片报头的TC字段来确定要应用于分组的PHB。这包括PSC和drop首选项。
We refer to such LSPs as "Explicitly TC-encoded-PSC LSPs" (E-LSPs), since the PSC of a packet transported on this LSP depends on the TC field (previously called the EXP field) value for that packet.
我们将此类LSP称为“显式TC编码的PSC LSP”（E-LSP），因为在此LSP上传输的数据包的PSC取决于该数据包的TC字段（以前称为EXP字段）值。
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 label set-up or relies on a pre-configured mapping.
对于给定的此类LSP，从TC字段到PHB（即到PSC和drop优先级）的映射要么在标签设置时显式发出信号，要么依赖于预先配置的映射。
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 (as a TC field). RFC 3270 has itself been updated by RFC 5129 [RFC5129].
这是对RFC 3032[RFC3032]的更新，符合MPLS垫片头中该字段应如何使用（作为TC字段）的原意。RFC 3270本身已由RFC 5129[RFC5129]更新。
Detailed operations of E-LSPs are specified in Section 3 of RFC 3270.
RFC 3270第3节规定了E-LSP的详细操作。
RFC 5129 is now updated like this:
RFC 5129现在更新如下：
A new paragraph is added at the end of Section 1.1 "Background":
在第1.1节“背景”末尾添加了一个新段落：
The EXP field has been renamed to the TC field, and thus all references in RFC 5129 to the EXP field now refer to the TC field.
EXP字段已重命名为TC字段，因此RFC 5129中对EXP字段的所有引用现在都指向TC字段。
Section 2 (bullet 5) on page 7 of RFC 5129 says:
RFC 5129第7页第2节（项目符号5）规定：
o A third possible approach was suggested by [Shayman]. In this scheme, interior LSRs assume that the endpoints are ECN-capable, 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 header, but the IP header says the endpoints are not ECN-capable, the edge router (or penultimate router, if using penultimate hop popping) drops the packet. We recommend this scheme, which we call `per-domain ECT checking', and define it more precisely in the following section. Its chief drawback is that it can cause packets to be forwarded after encountering congestion only to be dropped at the egress of the MPLS domain. The rationale for this decision is given in Section 8.1.
o [Shayman]提出了第三种可能的方法。在该方案中，内部LSR假设端点具有ECN能力，但在弹出最终标签时检查该假设。如果内部LSR在垫片头的EXP字段中标记了ECN，但IP头表示端点不支持ECN，则边缘路由器（或倒数第二路由器，如果使用倒数第二跳弹出）丢弃数据包。我们推荐这种方案，我们称之为“每域ECT检查”，并在下一节中对其进行更精确的定义。它的主要缺点是，它会导致在遇到拥塞后转发的数据包只能在MPLS域的出口处丢弃。第8.1节给出了该决定的理由。
Section 2 (bullet 5) of RFC 5129 is now updated to:
RFC 5129第2节（项目符号5）现更新为：
o A third possible approach was suggested by [Shayman]. In this scheme, interior LSRs assume that the endpoints are ECN-capable, 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, but the IP header says the endpoints are not TC-capable, the edge router (or penultimate router, if using penultimate hop popping) drops the packet. We recommend this scheme, which we call `per-domain ECT checking', and define it more precisely in the following section. Its chief drawback is that it can cause packets to be forwarded after encountering congestion only to be 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 3032 [RFC3032] and RFC 3270 [RFC3270].
o [Shayman]提出了第三种可能的方法。在该方案中，内部LSR假设端点具有ECN能力，但在弹出最终标签时检查该假设。如果内部LSR在shim报头的TC字段中标记了ECN，但IP报头表示端点不支持TC，则边缘路由器（或倒数第二路由器，如果使用倒数第二跳弹出）丢弃数据包。我们推荐这种方案，我们称之为“每域ECT检查”，并在下一节中对其进行更精确的定义。它的主要缺点是，它会导致在遇到拥塞后转发的数据包只能在MPLS域的出口处丢弃。第8.1节给出了该决定的理由。此方案是对RFC 3032[RFC3032]和RFC 3270[RFC3270]的更新。
There are several places in the RFCs that are explicitly updated by this document that reference the "Exp field", sometimes they refer to the field as "Exp bits", "EXP bits", or "EXP". In all those instances, the references now reference the TC field.
本文件明确更新的RFC中有几个地方引用了“Exp字段”，有时它们将字段称为“Exp位”、“Exp位”或“Exp”。在所有这些情况下，引用现在都引用TC字段。
There are also other RFCs (e.g., RFC 3272 [RFC3272], RFC 3443
[RFC3443], RFC 3469 [RFC3469], RFC 3564 [RFC3564], RFC 3985
[RFC3985], RFC 4182 [RFC4182], RFC 4364 [RFC4364], RFC 4379
[RFC4379], RFC 4448 [RFC4448], and RFC 4761 [RFC4761]) that reference
the "Exp field"; sometimes they refer to the field as "Exp bits",
"EXP bits", and "EXP". For all RFCs, including but not limited to
those mentioned in this paragraph, such references now reference the
TC field.
There are also other RFCs (e.g., RFC 3272 [RFC3272], RFC 3443
[RFC3443], RFC 3469 [RFC3469], RFC 3564 [RFC3564], RFC 3985
[RFC3985], RFC 4182 [RFC4182], RFC 4364 [RFC4364], RFC 4379
[RFC4379], RFC 4448 [RFC4448], and RFC 4761 [RFC4761]) that reference
the "Exp field"; sometimes they refer to the field as "Exp bits",
"EXP bits", and "EXP". For all RFCs, including but not limited to
those mentioned in this paragraph, such references now reference the
TC field.
Due to the limited number of bits in the TC field, their use for QoS and ECN (Explicit Congestion Notification) functions is intended to be flexible. These functions may rewrite all or some of the bits in the TC field.
由于TC字段中的比特数有限，它们用于QoS和ECN（显式拥塞通知）功能的目的是灵活的。这些函数可以重写TC字段中的全部或部分位。
Current implementations look at the TC field with and without label 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 label stack entries that are pushed onto an existing label stack having different TC fields from the rest of the label stack entries.
当前的实现查看带有和不带标签上下文的TC字段，并且TC字段可能会复制到推送到标签堆栈上的标签堆栈条目中。这样做是为了避免标签堆栈项被推送到现有标签堆栈上，该标签堆栈具有与其余标签堆栈项不同的TC字段。
This document only changes the name of one field in the MPLS shim header, and thus does not introduce any new security considerations.
本文档仅更改MPLS垫片头中一个字段的名称，因此不会引入任何新的安全注意事项。
The authors would like to thank Stewart Bryant, Bruce Davie, George Swallow, and Francois Le Faucheur for their input to and review of the current document.
作者要感谢Stewart Bryant、Bruce Davie、George Swallow和Francois Le Faucheur对当前文件的投入和审查。
The authors would also like to thank George Swallow, Khatri Paresh, and Phil Bedard for their help with grammar and spelling; a special thanks to Adrian Farrel for his careful review and help trawling the RFC-sea for RFCs that reference the EXP field.
作者还要感谢George Swallow、Khatri Paresh和Phil Bedard在语法和拼写方面的帮助；特别感谢阿德里安·法雷尔（Adrian Farrel）的仔细审查，并帮助拖网在RFC海中搜寻引用EXP字段的RFC。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[RFC3272]Awduche，D.，Chiu，A.，Elwalid，A.，Widjaja，I.，和X.Xiao，“互联网流量工程概述和原则”，RFC 3272，2002年5月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
[RFC3469] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[RFC3469]Sharma，V.和F.Hellstrand，“基于多协议标签交换（MPLS）的恢复框架”，RFC 3469，2003年2月。
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[RFC3564]Le Faucheur，F.和W.Lai，“支持区分服务的MPLS流量工程的要求”，RFC 3564，2003年7月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.和P.Pate，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005.
[RFC4182]Rosen，E.，“消除对MPLS显式NULL使用的限制”，RFC 41822005年9月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]Martini，L.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4761]Kompella，K.和Y.Rekhter，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，2007年1月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129]Davie，B.，Briscoe，B.，和J.Tay，“MPLS中的显式拥塞标记”，RFC 5129，2008年1月。
[Shayman] Shayman, M. and R. Jaeger, "Using ECN to Signal Congestion Within an MPLS Domain", Work in Progress, November 2000.
[Shayman]Shayman，M.和R.Jaeger，“使用ECN在MPLS域内发出拥塞信号”，正在进行的工作，2000年11月。
Authors' Addresses
作者地址
Loa Andersson Acreo AB
安德松·阿克雷奥律师事务所
EMail: loa@pi.nu
EMail: loa@pi.nu
Rajiv Asati Cisco Systems
拉吉夫·阿萨蒂思科系统公司
EMail: rajiva@cisco.com
EMail: rajiva@cisco.com