Network Working Group B. Davie
Request for Comments: 5129 Cisco Systems, Inc.
Category: Standards Track B. Briscoe
J. Tay
BT Research
January 2008
Network Working Group B. Davie
Request for Comments: 5129 Cisco Systems, Inc.
Category: Standards Track B. Briscoe
J. Tay
BT Research
January 2008
Explicit Congestion Marking in MPLS
MPLS中的显式拥塞标记
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）。本备忘录的分发不受限制。
Abstract
摘要
RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses.
RFC 3270定义了如何在MPLS网络中支持区分服务体系结构，包括如何在MPLS报头中编码区分服务代码点（DSCP）。DSCP可以在EXP字段中编码，而不排除该字段的其他用途。RFC 3270没有说明如何在MPLS报头中编码显式拥塞通知（ECN）标记。本文档定义了操作员如何为显式拥塞通知定义一些EXP代码点，而不排除其他用途。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 5
3. Per-Domain ECT Checking . . . . . . . . . . . . . . . . . . . 7
4. ECN-Enabled MPLS Domain . . . . . . . . . . . . . . . . . . . 8
4.1. Pushing (Adding) One or More Labels to an IP Packet . . . 8
4.2. Pushing One or More Labels onto an MPLS Labeled Packet . . 8
4.3. Congestion Experienced in an Interior MPLS Node . . . . . 8
4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 8
4.5. Popping an MPLS Label (Not the End of the Stack) . . . . . 9
4.6. Popping the Last MPLS Label in the Stack . . . . . . . . . 9
4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 10
5. ECN-Disabled MPLS Domain . . . . . . . . . . . . . . . . . . . 10
6. The Use of More Codepoints with E-LSPs and L-LSPs . . . . . . 10
7. Relationship to Tunnel Behavior in RFC 3168 . . . . . . . . . 11
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 11
8.1. Marking Non-ECN-Capable Packets . . . . . . . . . . . . . 11
8.2. Non-ECN-Capable Routers in an MPLS Domain . . . . . . . . 12
9. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. RFC 3168-Style ECN . . . . . . . . . . . . . . . . . . . . 13
9.2. ECN Co-Existence with Diffserv E-LSPs . . . . . . . . . . 13
9.3. Congestion-Feedback-Based Traffic Engineering . . . . . . 14
9.4. PCN Flow Admission Control and Flow Termination . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Extension to Pre-Congestion Notification . . . . . . 16
A.1. Label Push onto IP Packet . . . . . . . . . . . . . . . . . 16
A.2. Pushing Additional MPLS Labels . . . . . . . . . . . . . . 16
A.3. Admission Control or Flow Termination Marking Inside
MPLS Domain . . . . . . . . . . . . . . . . . . . . . . . . 17
A.4. Popping an MPLS Label (Not End of Stack) . . . . . . . . . 17
A.5. Popping the Last MPLS Label to Expose IP Header . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 5
3. Per-Domain ECT Checking . . . . . . . . . . . . . . . . . . . 7
4. ECN-Enabled MPLS Domain . . . . . . . . . . . . . . . . . . . 8
4.1. Pushing (Adding) One or More Labels to an IP Packet . . . 8
4.2. Pushing One or More Labels onto an MPLS Labeled Packet . . 8
4.3. Congestion Experienced in an Interior MPLS Node . . . . . 8
4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 8
4.5. Popping an MPLS Label (Not the End of the Stack) . . . . . 9
4.6. Popping the Last MPLS Label in the Stack . . . . . . . . . 9
4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 10
5. ECN-Disabled MPLS Domain . . . . . . . . . . . . . . . . . . . 10
6. The Use of More Codepoints with E-LSPs and L-LSPs . . . . . . 10
7. Relationship to Tunnel Behavior in RFC 3168 . . . . . . . . . 11
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 11
8.1. Marking Non-ECN-Capable Packets . . . . . . . . . . . . . 11
8.2. Non-ECN-Capable Routers in an MPLS Domain . . . . . . . . 12
9. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. RFC 3168-Style ECN . . . . . . . . . . . . . . . . . . . . 13
9.2. ECN Co-Existence with Diffserv E-LSPs . . . . . . . . . . 13
9.3. Congestion-Feedback-Based Traffic Engineering . . . . . . 14
9.4. PCN Flow Admission Control and Flow Termination . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Extension to Pre-Congestion Notification . . . . . . 16
A.1. Label Push onto IP Packet . . . . . . . . . . . . . . . . . 16
A.2. Pushing Additional MPLS Labels . . . . . . . . . . . . . . 16
A.3. Admission Control or Flow Termination Marking Inside
MPLS Domain . . . . . . . . . . . . . . . . . . . . . . . . 17
A.4. Popping an MPLS Label (Not End of Stack) . . . . . . . . . 17
A.5. Popping the Last MPLS Label to Expose IP Header . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . . . 18
[RFC3168] defines Explicit Congestion Notification (ECN) for IP. The primary purpose of ECN is to allow congestion to be signalled without dropping packets.
[RFC3168]定义IP的显式拥塞通知（ECN）。ECN的主要目的是允许在不丢弃数据包的情况下发出拥塞信号。
[RFC3270] defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header.
[RFC3270]定义了如何在MPLS网络中支持区分服务体系结构，包括如何在MPLS报头中编码区分服务代码点（DSCP）。DSCP可以在EXP字段中编码，而不排除该字段的其他用途。RFC 3270没有说明如何在MPLS报头中编码显式拥塞通知（ECN）标记。
This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. In parallel to the activity defining the addition of ECN to IP [RFC3168], two proposals were made to add ECN to MPLS [Floyd][Shayman]. These proposals, however, fell by the wayside. With ECN for IP now being a proposed standard, and developing interest in using pre-congestion notification (PCN) for admission control and flow termination [PCN], there is consequent interest in being able to support ECN across IP networks consisting of MPLS-enabled domains. Therefore, it is necessary to specify the protocol for including ECN in the MPLS shim header and the protocol behavior of edge MPLS nodes.
本文档定义了操作员如何为显式拥塞通知定义一些EXP代码点，而不排除其他用途。在定义将ECN添加到IP[RFC3168]的活动的同时，提出了将ECN添加到MPLS[Floyd][Shayman]的两项建议。然而，这些建议被搁置了。随着针对IP的ECN现在成为一个提议的标准，并且对使用拥塞前通知（PCN）进行准入控制和流终止[PCN]产生了兴趣，因此，能够在由支持MPLS的域组成的IP网络上支持ECN也成为了人们的兴趣所在。因此，有必要指定将ECN包含在MPLS垫片头中的协议以及边缘MPLS节点的协议行为。
We note that in [RFC3168], there are four codepoints used for ECN marking, which are encoded using two bits of the IP header. The MPLS EXP field is the logical place to encode ECN codepoints, but with only 3 bits (8 codepoints) available, and with the same field being used to convey DSCP information as well, there is a clear incentive to conserve the number of codepoints consumed for ECN purposes. Efficient use of the EXP field has been a focus of prior documents [Floyd] [Shayman], and we draw on those efforts in this document as well.
我们注意到在[RFC3168]中，有四个用于ECN标记的代码点，它们使用IP报头的两位进行编码。MPLS EXP字段是对ECN代码点进行编码的逻辑位置，但由于只有3位（8个代码点）可用，并且同一字段也用于传输DSCP信息，因此有一个明显的动机，即保存为ECN目的而消耗的代码点数量。EXP字段的有效使用一直是先前文件[Floyd][Shayman]的重点，我们在本文件中也借鉴了这些努力。
We also note that [RFC3168] defines default usage of the ECN field, but it allows for the possibility that some Diffserv Per Hop Behaviors (PHBs) might include different specifications on how the ECN field is to be used. This document seeks to preserve that capability.
我们还注意到，[RFC3168]定义了ECN字段的默认用法，但它允许一些区分服务每跳行为（PHB）可能包括关于如何使用ECN字段的不同规范。本文件旨在保持这种能力。
Our intent is to specify how the MPLS shim header [RFC3032] should denote ECN marking and how MPLS nodes should understand whether the transport for a packet will be ECN capable. We offer this as a building block, from which to build different congestion-notification systems. We do not intend to specify how the resulting congestion notification is fed back to an upstream node that can mitigate congestion. For instance, unlike [Shayman], we do not specify edge-to-edge MPLS domain feedback, but we also do not preclude it. Nonetheless, we do specify how the egress node of an MPLS domain should copy congestion notification from the MPLS shim into the encapsulated IP header if the ECN is to be carried onward towards the IP receiver; but we do *not* mandate that MPLS congestion notification must be copied into the IP header for onward transmission. This document aims to be generic for any use of congestion notification in MPLS. Support of [RFC3168] is our primary motivation; some additional potential applications to illustrate the flexibility of our approach are described in Section 9. In particular, we aim to support possible future schemes that may use more than one level of congestion marking.
我们的目的是指定MPLS垫片头[RFC3032]应如何表示ECN标记，以及MPLS节点应如何理解数据包的传输是否具有ECN能力。我们将此作为构建块提供，从中构建不同的拥塞通知系统。我们不打算指定如何将产生的拥塞通知反馈给可以缓解拥塞的上游节点。例如，与[Shayman]不同，我们不指定边到边MPLS域反馈，但也不排除它。尽管如此，我们确实指定了如果ECN要向IP接收器前进，MPLS域的出口节点应该如何将拥塞通知从MPLS垫片复制到封装的IP报头中；但我们并不要求MPLS拥塞通知必须复制到IP报头中进行转发。本文档旨在为MPLS中拥塞通知的任何使用提供通用性。支持[RFC3168]是我们的主要动机；第9节描述了一些其他可能的应用，以说明我们方法的灵活性。特别是，我们的目标是支持未来可能使用多个级别的拥塞标记的方案。
This document draws freely on the terminology of ECN [RFC3168] and MPLS [RFC3031]. For ease of reference, we have included some definitions here, but refer the reader to the references above for complete specifications of the relevant technologies:
本文件自由引用了ECN[RFC3168]和MPLS[RFC3031]的术语。为了便于参考，我们在这里包含了一些定义，但请读者参考上述参考资料，以了解相关技术的完整规范：
o CE: Congestion Experienced. One of the states with which a packet may be marked in a network supporting ECN. A packet is marked in this state by an ECN-capable router to indicate that this router was experiencing congestion at the time the packet arrived.
o 行政长官：交通挤塞。在支持ECN的网络中，数据包可以被标记的一种状态。在这种状态下，数据包由支持ECN的路由器进行标记，以表明该路由器在数据包到达时正在经历拥塞。
o ECT: ECN-capable Transport. One of the ECN states that a packet may be in when it is sent by an end system. An end system marks a packet with an ECT codepoint to indicate that the endpoints of the transport protocol are ECN-capable. A router may not mark a packet as CE unless the packet was marked ECT when it arrived.
o ECT：支持ECN的传输。其中一个ECN声明，当数据包由终端系统发送时，数据包可能处于状态。终端系统使用ECT代码点标记数据包，以指示传输协议的端点能够进行ECN。路由器不能将数据包标记为CE，除非数据包到达时标记为ECT。
o Not-ECT: Not ECN-capable transport. An end system marks a packet with this codepoint to indicate that the endpoints of the transport protocol are not ECN-capable. A congested router cannot mark such packets as CE, and thus it can only drop them to indicate congestion.
o 非ECT：不支持ECN传输。终端系统使用此代码点标记数据包，以指示传输协议的端点不支持ECN。拥塞的路由器不能将这些数据包标记为CE，因此它只能丢弃它们以表示拥塞。
o EXP field. A 3-bit field in the MPLS label header [RFC3032] that may be used to convey Diffserv information (and is also used in this document to carry ECN information).
o EXP字段。MPLS标签头[RFC3032]中的一个3位字段，可用于传递区分服务信息（在本文档中也用于携带ECN信息）。
o PHP. Penultimate Hop Popping. An MPLS operation in which the penultimate Label Switching Router (LSR) on a Label Switched Path (LSP) removes the top label from the packet before forwarding the packet to the final LSR on the LSP.
o PHP。倒数第二跳。一种MPLS操作，其中标签交换路径（LSP）上的倒数第二个标签交换路由器（LSR）在将数据包转发到LSP上的最后一个LSR之前，从数据包中删除顶部标签。
Requirements Language
需求语言
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]中所述进行解释。
We propose that LSRs configured for explicit congestion notification should use the EXP field in the MPLS shim header. However, [RFC3270] already defines use of codepoints in the EXP field for differentiated services. Although it does not preclude other compatible uses of the EXP field, this clearly seems to limit the space available for ECN, given the field is only 3 bits (8 codepoints).
我们建议，为显式拥塞通知配置的LSR应该使用MPLS填充头中的EXP字段。但是，[RFC3270]已经在EXP字段中定义了区分服务的代码点使用。尽管它并不排除EXP字段的其他兼容使用，但这显然限制了ECN的可用空间，因为该字段只有3位（8个码点）。
[RFC3270] defines two possible approaches for requesting differentiated service treatment from an LSR:
[RFC3270]定义了从LSR请求差异化服务处理的两种可能方法：
o In the EXP-Inferred-PSC LSP (E-LSP) approach, different codepoints of the EXP field in the MPLS shim header are used to indicate the packet's per hop behavior (PHB).
o 在EXP推断的PSC LSP（E-LSP）方法中，MPLS垫片报头中EXP字段的不同代码点用于指示分组的每跳行为（PHB）。
o In the Label-Only-Inferred-PSC LSP (L-LSP) approach, an MPLS label is assigned for each PHB scheduling class (PSC, as defined in [RFC3260], so that an LSR determines both its forwarding and its scheduling behavior from the label.
o 在仅标签推断的PSC LSP（L-LSP）方法中，为每个PHB调度类（PSC，如[RFC3260]中所定义）分配MPLS标签，以便LSR根据标签确定其转发和调度行为。
If an MPLS domain uses the L-LSP approach, there is likely to be space in the EXP field for ECN codepoint(s). Where the E-LSP approach is used, codepoint space in the EXP field is likely to be scarce. This document focuses on interworking ECN marking with the E-LSP approach, as it is the tougher problem. Consequently, the same approach can also be applied with L-LSPs.
如果MPLS域使用L-LSP方法，则EXP字段中可能有ECN码点的空间。在使用E-LSP方法的情况下，EXP字段中的码点空间可能很稀少。本文档重点介绍了ECN标记与E-LSP方法的相互作用，因为这是一个更棘手的问题。因此，同样的方法也适用于L-LSP。
We recommend that explicit congestion notification in MPLS should use codepoints instead of bits in the EXP field. Since not every PHB will necessarily require an associated ECN codepoint, it would be
我们建议MPLS中的显式拥塞通知应使用EXP字段中的码点而不是位。由于并非每个PHB都需要相关的ECN代码点，因此
wasteful to assign a dedicated bit for ECN. (There may also be cases where a given PHB might need more than one ECN-like codepoint; see Section 9.4 for an example).
为ECN分配一个专用位是浪费的。（在某些情况下，给定PHB可能需要多个类似ECN的代码点；示例见第9.4节）。
For each PHB that uses ECN marking, we assume one EXP codepoint will be defined as not congestion marked (Not-CM), and at least one other codepoint will be defined as congestion marked (CM). Therefore, each PHB that uses ECN marking will consume at least two EXP codepoints, but PHBs that do not use ECN marking will only consume one.
对于使用ECN标记的每个PHB，我们假设一个EXP码点将被定义为未标记拥塞（非CM），并且至少一个其他码点将被定义为标记拥塞（CM）。因此，使用ECN标记的每个PHB将消耗至少两个EXP代码点，但不使用ECN标记的PHB将只消耗一个EXP代码点。
Further, we wish to use minimal space in the MPLS shim header to tell interior LSRs whether each packet will be received by an ECN-capable transport (ECT). Nonetheless, we must ensure that an endpoint that would not understand an ECN mark will not receive one, otherwise it will not be able to respond to congestion as it should. In the past, three solutions to this problem have been proposed:
此外，我们希望在MPLS shim报头中使用最小的空间来告知内部lsr每个分组是否将由支持ECN的传输（ECT）接收。尽管如此，我们必须确保不理解ECN标记的端点不会收到ECN标记，否则它将无法对拥塞做出应有的响应。过去，针对这一问题提出了三种解决方案：
o One possible approach is for congested LSRs to mark the ECN field in the underlying IP header at the bottom of the label stack. Although many commercial LSRs routinely access the IP header for other reasons (equal cost multi-path - ECMP), there are numerous drawbacks to attempting to find an IP header beneath an MPLS label stack. Notably, there is the challenge of detecting the absence of an IP header when non-IP packets are carried on an LSP. Therefore, we will not consider this approach further.
o 一种可能的方法是让拥挤的LSR在标签堆栈底部的底层IP报头中标记ECN字段。尽管许多商业LSR出于其他原因（等成本多路径-ECMP）经常访问IP报头，但尝试在MPLS标签堆栈下查找IP报头有许多缺点。值得注意的是，当在LSP上承载非IP分组时，存在检测IP报头缺失的挑战。因此，我们不会进一步考虑这种方法。
o In the scheme suggested by [Floyd], ECT and CE are overloaded into one bit, so that a 0 means ECT while a 1 might either mean Not-ECT or it might mean CE. A packet that has been marked as having experienced congestion upstream, and then is picked out for marking at a second congested LSR, will be dropped by the second LSR since it cannot determine whether the packet has previously experienced congestion or if ECN is not supported by the transport.
o 在[Floyd]建议的方案中，ECT和CE重载为一位，因此0表示ECT，而1可能表示Not ECT，也可能表示CE。被标记为在上游经历了拥塞，然后被挑选出来在第二拥塞LSR处进行标记的分组将被第二LSR丢弃，因为第二LSR不能确定该分组之前是否经历了拥塞或者该传输是否不支持ECN。
While such an approach seemed potentially palatable, we do not recommend it here for the following reasons. In some cases, we wish to be able to use ECN marking long before actual congestion (e.g., pre-congestion notification). In these circumstances, marking rates at each LSR might be non-negligible most of the time, so the chances of a previously marked packet encountering an LSR that wants to mark it again will also be non-negligible. In the case where CE and not-ECT are indistinguishable to core routers, such a scenario could lead to unacceptable drop rates. If the typical marking rate at every router or LSR is p, and the typical diameter of the network of LSRs is d, then the probability that a marked packet will be chosen for marking more than once is
虽然这样一种方法似乎可能令人满意，但出于以下原因，我们不建议在这里使用。在某些情况下，我们希望能够在实际拥塞之前很久使用ECN标记（例如，拥塞前通知）。在这些情况下，每个LSR上的标记速率在大多数情况下都是不可忽略的，因此先前标记的数据包遇到想要再次标记它的LSR的可能性也是不可忽略的。在核心路由器无法区分CE和not ECT的情况下，这种情况可能导致无法接受的丢弃率。如果每个路由器或LSR的典型标记率为p，且LSR网络的典型直径为d，则选择标记的分组进行多次标记的概率为
1-[Pr(never marked) + Pr(marked at exactly one hop)] = 1- [(1-p)^d + dp(1-p)^(d-1)]. For instance, with 6 LSRs in a row, each marking ECN with 1% probability, the chances of a packet that is already marked being chosen for marking a second time is 0.15%. The bit-overloading scheme would therefore introduce a drop rate of 0.15% unnecessarily. Given that most modern core networks are sized to introduce near-zero packet drop, it may be unacceptable to drop over one in a thousand packets unnecessarily.
1-[Pr（从未标记）+Pr（恰好在一个跃点标记）]=1-[（1-p）^d+dp（1-p）^（d-1）]。例如，如果一行中有6个LSR，每个LSR以1%的概率标记ECN，则已标记的数据包被选择进行第二次标记的概率为0.15%。因此，位过载方案将不必要地引入0.15%的丢弃率。考虑到大多数现代核心网络的规模都接近于零丢包，不必要地丢包超过千分之一可能是不可接受的。
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节给出了该决定的理由。
For the purposes of this discussion, we define the egress nodes of an MPLS domain as the nodes that pop the last MPLS label from the label stack, exposing the IP (or, potentially non-IP) header. Note that such a node may be the ultimate or penultimate hop of an LSP, depending on whether penultimate hop popping (PHP) is employed.
出于本讨论的目的，我们将MPLS域的出口节点定义为从标签堆栈弹出最后一个MPLS标签的节点，公开IP（或可能非IP）报头。注意，这样的节点可以是LSP的最终跳或倒数第二跳，这取决于是否使用倒数第二跳弹出（PHP）。
In the per-domain ECT checking approach, the egress nodes take responsibility for checking whether the transport is ECN-capable. This document does not specify how these nodes should pass on congestion notification because different approaches are likely in different scenarios. However, if congestion notification in the MPLS header is copied into the IP header, the procedure MUST conform to the specification given here.
在每域ECT检查方法中，出口节点负责检查传输是否支持ECN。本文档未指定这些节点应如何传递拥塞通知，因为在不同的场景中可能有不同的方法。但是，如果将MPLS报头中的拥塞通知复制到IP报头中，则该过程必须符合此处给出的规范。
If congestion notification is passed to the transport without first passing it onward in the IP header, the approach used must take similar care to check that the transport is ECN-capable before passing it ECN markings. Specifically, if the transport for a particular congestion marked MPLS packet is found not to be ECN-capable, the packet MUST be dropped at this egress node.
如果拥塞通知未首先在IP报头中向前传递而传递给传输，则使用的方法必须同样小心，在传递ECN标记之前检查传输是否具有ECN能力。具体地说，如果发现特定拥塞标记MPLS分组的传输不支持ECN，则必须在该出口节点丢弃该分组。
In the per-domain ECT checking approach, only the egress nodes check whether an IP packet is destined for an ECN-capable transport. Therefore, any single LSR within an MPLS domain MUST NOT be
在每域ECT检查方法中，只有出口节点检查IP分组是否以支持ECN的传输为目的地。因此，MPLS域中的任何单个LSR都不能
configured to enable ECN marking unless all the egress LSRs surrounding it are already configured to handle ECN marking.
配置为启用ECN标记，除非其周围的所有出口LSR已配置为处理ECN标记。
We call a domain surrounded by ECN-capable egress LSRs an ECN-enabled MPLS domain. This term only implies that all the egress LSRs are ECN-enabled; some interior LSRs may not be ECN-enabled. For instance, it would be possible to use some legacy LSRs incapable of supporting ECN in the interior of an MPLS domain as long as all the egress LSRs were ECN-capable. Note that if PHP is used, the "penultimate hop" routers that perform the pop operation do need to be ECN-enabled since they are acting in this context as egress LSRs.
我们将由支持ECN的出口LSR包围的域称为支持ECN的MPLS域。该术语仅意味着所有出口lsr均已启用ECN；某些内部LSR可能未启用ECN。例如，只要所有出口lsr都支持ECN，就可以在MPLS域内部使用一些不能支持ECN的遗留lsr。请注意，如果使用PHP，执行pop操作的“倒数第二跳”路由器确实需要启用ECN，因为它们在此上下文中充当出口LSR。
In the following subsections, we describe various operations affecting the ECN marking of a packet that may be performed at MPLS-edge and core LSRs.
在以下小节中，我们描述了影响可在MPLS边缘和核心LSR处执行的分组的ECN标记的各种操作。
On encapsulating an IP packet with an MPLS label stack, the ECN field must be translated from the IP packet into the MPLS EXP field. The Not-CM (not congestion marked) state is set in the MPLS EXP field if the ECN status of the IP packet is Not-ECT or ECT(1) or ECT(0). The CM state is set if the ECN status of the IP packet is CE. If more than one label is pushed at one time, the same value should be placed in the EXP value of all label stack entries.
在使用MPLS标签堆栈封装IP数据包时，必须将ECN字段从IP数据包转换为MPLS EXP字段。如果IP数据包的ECN状态不是ECT或ECT（1）或ECT（0），则在MPLS EXP字段中设置Not CM（未标记拥塞）状态。如果IP数据包的ECN状态为CE，则设置CM状态。如果一次推送多个标签，则应在所有标签堆栈项的EXP值中放置相同的值。
The EXP field is copied directly from the topmost label before the push to the newly added outer label. If more than one label is being pushed, the same EXP value is copied to all label-stack entries.
EXP字段在推送到新添加的外部标签之前直接从最上面的标签复制。如果要推送多个标签，则会将相同的EXP值复制到所有标签堆栈项。
If the EXP codepoint of the packet maps to a PHB that uses ECN marking, and the marking algorithm requires the packet to be marked, the CM state is set (irrespective of whether it is already in the CM state).
如果数据包的EXP代码点映射到使用ECN标记的PHB，并且标记算法要求标记数据包，则设置CM状态（不管它是否已经处于CM状态）。
If the buffer is full, a packet is dropped.
如果缓冲区已满，则丢弃数据包。
If an MPLS-encapsulated packet crosses a Diffserv domain boundary, it may be the case that the two domains use different encodings of the same PHB in the EXP field. In such cases, the EXP field must be
如果MPLS封装的数据包跨越Diffserv域边界，则可能是两个域在EXP字段中使用相同PHB的不同编码。在这种情况下，EXP字段必须为
rewritten at the domain boundary. If the PHB is one that supports ECN, then the appropriate ECN marking should also be preserved when the EXP field is mapped at the boundary.
在域边界重写。如果PHB是支持ECN的PHB，则在边界映射EXP字段时，也应保留适当的ECN标记。
If an MPLS-encapsulated packet that is in the CM state crosses from a domain that is ECN-enabled (as defined in Section 3) to a domain that is not ECN-enabled, then it is necessary to perform the egress checking procedures at the egress LSR of the ECN-enabled domain. This means that if the encapsulated packet is not ECN-capable, the packet MUST be dropped. Note that this implies the egress LSR must be able to look beneath the MPLS header without popping the label stack.
如果处于CM状态的MPLS封装包从启用ECN的域（如第3节中定义）跨越到未启用ECN的域，则有必要在启用ECN的域的出口LSR处执行出口检查过程。这意味着，如果封装的数据包不支持ECN，则必须丢弃该数据包。注意，这意味着出口LSR必须能够在不弹出标签堆栈的情况下查看MPLS报头下方。
The related issue of Diffserv tunnel models is discussed in Section 4.7.
第4.7节讨论了Diffserv隧道模型的相关问题。
When a packet has more than one MPLS label in the stack and the top label is popped, another MPLS label is exposed. In this case, the ECN information should be transferred from the outer EXP field to the inner MPLS label in the following manner. If the inner EXP field is Not-CM, the inner EXP field is set to the same CM or Not-CM state as the outer EXP field. If the inner EXP field is CM, it remains unchanged whatever the outer EXP field. Note that an inner value of CM and an outer value of not-CM should be considered anomalous, and SHOULD be logged in some way by the LSR.
当一个数据包在堆栈中有多个MPLS标签且顶标签弹出时，另一个MPLS标签将被暴露。在这种情况下，应按照以下方式将ECN信息从外部EXP字段传输到内部MPLS标签。如果内部EXP字段不是CM，则内部EXP字段设置为与外部EXP字段相同的CM或非CM状态。如果内部EXP字段是CM，则无论外部EXP字段是什么，它都保持不变。请注意，内部值CM和外部值not CM应视为异常值，并应通过LSR以某种方式记录。
When the last MPLS label is popped from the packet, its payload is exposed. If that packet is not IP, and does not have any capability equivalent to ECT, it is assumed Not-ECT, and it is treated as such. That means that if the EXP value of the MPLS header is CM, the packet MUST be dropped.
当最后一个MPLS标签从数据包中弹出时，其有效负载将被暴露。如果该数据包不是IP，并且没有任何等效于ECT的能力，则假定它不是ECT，并将其视为ECT。这意味着，如果MPLS报头的EXP值为CM，则必须丢弃数据包。
Assuming an IP packet was exposed, we have to examine whether or not that packet is ECT. A Not-ECT packet MUST be dropped if the EXP field is CM.
假设一个IP数据包被暴露，我们必须检查该数据包是否为ECT。如果EXP字段为CM，则必须丢弃Not ECT数据包。
For the remainder of this section, we describe the behavior that is required if the ECN information is to be transferred from the MPLS header into the exposed IP header for onward transmission. As noted in Section 1.2, such behavior is not mandated by this document, but may be selected by an operator.
对于本节的其余部分，我们将描述如果要将ECN信息从MPLS报头传输到公开的IP报头以便向前传输，则需要的行为。如第1.2节所述，本文件不强制要求此类行为，但可由操作员选择。
If the inner IP packet is Not-ECT, its ECN field remains unchanged if the EXP field is Not-CM. If the ECN field of the inner packet is set to ECT(0), ECT(1), or CE, the ECN field remains unchanged if the EXP field is set to Not-CM. The ECN field is set to CE if the EXP field is CM. Note that an inner value of CE and an outer value of not-CM should be considered anomalous, and SHOULD be logged in some way by the LSR.
如果内部IP数据包不是ECT，如果EXP字段不是CM，则其ECN字段保持不变。如果内部数据包的ECN字段设置为ECT（0）、ECT（1）或CE，则如果EXP字段设置为Not CM，则ECN字段保持不变。如果EXP字段为CM，则ECN字段设置为CE。请注意，内部值CE和外部值not CM应视为异常值，并应以某种方式由LSR记录。
[RFC3270] describes three tunneling models for Diffserv support across MPLS Domains, referred to as the uniform, short pipe, and pipe models. The differences between these models lie in whether the Diffserv treatment that applies to a packet while it travels along a particular LSP is carried to the ingress of the last hop, to the egress of the last hop, or beyond the last hop. Depending on which mode is preferred by an operator, the EXP value or DSCP value of an exposed header following a label pop may or may not be dependent on the EXP value of the label that is removed by the pop operation. We believe that, in the case of ECN marking, the use of these models should only apply to the encoding of the Diffserv PHB in the EXP value, and that the choice of codepoint for ECN should always be made based on the procedures described above, independent of the tunneling model.
[RFC3270]描述了跨MPLS域的区分服务支持的三种隧道模型，称为统一、短管道和管道模型。这些模型之间的区别在于，当数据包沿着特定LSP移动时，应用于该数据包的区分服务处理是被带到最后一跳的入口、最后一跳的出口还是最后一跳之后。根据操作员首选的模式，标签pop后的暴露标头的EXP值或DSCP值可能取决于也可能不取决于pop操作移除的标签的EXP值。我们认为，在ECN标记的情况下，这些模型的使用应仅适用于EXP值中Diffserv PHB的编码，并且ECN的码点选择应始终基于上述过程，独立于隧道模型。
If ECN is not enabled on all the egress LSRs of a domain, ECN MUST NOT be enabled on any LSRs throughout the domain. If congestion is experienced on any LSR in an ECN-disabled MPLS domain, packets MUST be dropped; they MUST NOT be marked. The exact algorithm for deciding when to drop packets during congestion (e.g., tail-drop, RED, etc.) is a local matter for the operator of the domain.
如果未在域的所有出口LSR上启用ECN，则不得在整个域的任何LSR上启用ECN。如果在禁用ECN的MPLS域中的任何LSR上遇到拥塞，则必须丢弃数据包；它们不能被标记。在拥塞期间决定何时丢弃数据包（例如，尾部丢弃、RED等）的精确算法是域操作员的局部问题。
[RFC3270] gives different options with E-LSPs and L-LSPs, and some of those could potentially provide ample EXP codepoints for ECN. However, deploying L-LSPs vs. E-LSPs has many implications, such as platform support and operational complexity. The above ECN MPLS solution should provide some flexibility. If the operator has deployed one L-LSP per PHB scheduling class, then EXP space will be a non-issue, and it could be used to achieve more sophisticated ECN behavior if required. If the operator wants to stick to E-LSPs and uses a handful of EXP codepoints for Diffserv, it may be desirable to operate with a minimum number of extra ECN codepoints, even if this comes with some compromise on ECN optimality. See Section 9 for discussion of some possible deployment scenarios.
[RFC3270]提供了不同的E-LSP和L-LSP选项，其中一些可能为ECN提供充足的EXP代码点。然而，部署L-LSP与E-LSP相比有许多影响，例如平台支持和操作复杂性。上述ECN MPLS解决方案应提供一定的灵活性。如果运营商已为每个PHB调度类部署了一个L-LSP，则EXP空间将不会成为问题，如果需要，可以使用它来实现更复杂的ECN行为。如果运营商希望坚持使用E-LSP，并使用少量EXP码点进行区分服务，则可能需要使用最少数量的额外ECN码点进行操作，即使这会在ECN优化方面带来一些折衷。有关一些可能的部署场景的讨论，请参见第9节。
We note that in a network where L-LSPs are used, ECN marking SHOULD NOT cause packets from the same microflow, but with different ECN markings, to be sent on different LSPs. As discussed in [RFC3270], packets of a single microflow should always travel on the same LSP to avoid possible misordering. Thus, ECN marking of packets on L-LSPs SHOULD only affect the EXP value of the packets.
我们注意到，在使用L-LSP的网络中，ECN标记不应导致来自相同微流但具有不同ECN标记的数据包在不同LSP上发送。如[RFC3270]所述，单个微流的数据包应始终在同一LSP上传输，以避免可能的误序。因此，L-LSP上数据包的ECN标记应该只影响数据包的EXP值。
[RFC3168] defines two modes of encapsulating ECN-marked IP packets inside additional IP headers when tunnels are used. The two modes are the "full functionality" and "limited functionality" modes. In the full functionality mode, the ECT information from the inner header is copied to the outer header at the tunnel ingress, but the CE information is not. In the limited functionality mode, neither ECT nor CE information is copied to the outer header, and thus ECN cannot be applied to the encapsulated packet.
[RFC3168]定义了在使用隧道时，将ECN标记的IP数据包封装在附加IP报头中的两种模式。这两种模式是“完全功能”和“有限功能”模式。在全功能模式下，来自内部报头的ECT信息被复制到隧道入口的外部报头，但CE信息不被复制。在受限功能模式下，ECT和CE信息都不会复制到外部报头，因此ECN不能应用于封装的数据包。
The behavior that is specified in Section 4 of this document resembles the "full functionality" mode in the sense that it conveys some information from inner to outer header, and in the sense that it enables full ECN support along the MPLS LSP (which is analogous to an IP tunnel in this context). However it differs in one respect, which is that the CE information is conveyed from the inner header to the outer header. Our original reason for this different design choice was to give interior routers and LSRs more information about upstream marking in multi-bottleneck cases. For instance, the flow termination marking mechanism proposed for PCN works by only considering packets for marking that have not already been marked upstream. Unless existing flow termination marking is copied from the inner to the outer header at tunnel ingress, the mechanism doesn't terminate enough traffic in cases where anomalous events hit multiple domains at once. [RFC3168] does not give any reasons against conveying CE information from the inner header to the outer in the "full functionality" mode. Furthermore, [RFC4301] specifies that the ECN marking should be copied from inner header to outer header in IPSEC tunnels, consistent with the approach defined here. [BRISCOE-ECN] discusses this issue in more detail. In summary, the approach described in Section 4 appears to be both a sound technical choice and consistent with the current state of thinking in the IETF.
本文档第4节中规定的行为类似于“全功能”模式，因为它从内部到外部报头传递一些信息，并且在这个意义上，它支持沿着MPLS LSP的完全ECN支持（这类似于此上下文中的IP隧道）。然而，它在一个方面不同，即CE信息从内部报头传送到外部报头。我们选择这种不同设计的最初原因是为了在多瓶颈情况下为内部路由器和LSR提供更多关于上游标记的信息。例如，为PCN提出的流终止标记机制只考虑尚未在上游标记的标记数据包。除非在隧道入口将现有流量终止标记从内部头复制到外部头，否则在异常事件同时击中多个域的情况下，该机制不会终止足够的流量。[RFC3168]没有给出任何反对在“全功能”模式下将CE信息从内部标题传输到外部标题的理由。此外，[RFC4301]指定ECN标记应在IPSEC隧道中从内部头复制到外部头，与此处定义的方法一致。[BRISCOE-ECN]更详细地讨论了这个问题。总之，第4节中描述的方法似乎是一个合理的技术选择，并且与IETF中的当前思维状态一致。
What are the consequences of marking a packet that is not ECN-capable? Even if it will be dropped before leaving the domain, doesn't this consume resources unnecessarily?
标记不支持ECN的数据包会产生什么后果？即使在离开域之前将其删除，这是否会不必要地消耗资源？
The problem only arises if there is congestion downstream of an earlier congested queue in the same MPLS domain. Congested LSRs downstream might forward packets already marked, even though they will be dropped later when the inner IP header is found to be Not-ECT on decapsulation. Such packets might cause the downstream LSRs to mark (or drop) other packets that they would otherwise not have had to.
只有在同一MPLS域中较早拥塞队列的下游存在拥塞时，问题才会出现。拥塞的LSR下游可能会转发已经标记的数据包，即使稍后在解封时发现内部IP报头不是ECT时会丢弃这些数据包。这样的分组可能导致下游lsr标记（或丢弃）其他分组，否则它们就不必标记（或丢弃）其他分组。
We expect congestion will typically be rare in MPLS networks, but it might not be. The extra unnecessary load at downstream LSRs will not be more than the fraction of marked packets from upstream LSRs, even in the worst case where no transports are ECN-capable. Therefore, the amount of unnecessary marking (or drop) on an LSR will not be more than the product of its local marking rate and the marking rate due to upstream LSRs within the same domain -- typically the product of two small (often zero) probabilities.
我们预计在MPLS网络中拥塞通常很少见，但可能并非如此。即使在没有传输支持ECN的最坏情况下，下游LSR处的额外不必要负载也不会超过来自上游LSR的标记数据包的分数。因此，LSR上不必要的标记（或下降）的数量不会超过其本地标记率和同一领域内上游LSR导致的标记率的乘积——通常是两个小概率（通常为零）的乘积。
This is why we decided to use the per-domain ECT checking approach -- because the most likely effect would be a very slightly increased marking rate, which would result in very slightly higher drop only for non-ECN-capable transports. We chose not to use the [Floyd] alternative, which introduced a low but persistent level of unnecessary packet drop for all time, even for ECN-capable transports. Although that scheme did not carry traffic to the edge of the MPLS domain only to be dropped on decapsulation, we felt our minor inefficiency was a small price to pay; and it would get smaller still if ECN deployment widened.
这就是我们决定使用每域ECT检查方法的原因——因为最有可能的影响是标记率略微增加，这将导致只有不支持ECN的传输的标记率略微增加。我们选择不使用[Floyd]替代方案，该方案引入了低水平但持续的不必要数据包丢弃，即使对于支持ECN的传输也是如此。尽管该方案并没有将流量传输到MPLS域的边缘，只是在去封装时被丢弃，但我们觉得我们的低效率是一个很小的代价；如果ECN部署范围扩大，它将变得更小。
A partial solution would be to preferentially drop packets arriving at a congested router that were already marked. There is no solution to the problem of marking a packet when congestion is caused by another packet that should have been dropped. However, the chance of such an occurrence is very low, and the consequences are not significant. It merely causes an application to very occasionally slow down its rate when it did not have to.
部分解决方案是优先丢弃到达拥塞路由器且已标记的数据包。当拥塞是由另一个本应丢弃的数据包引起时，标记数据包的问题没有解决方案。然而，发生这种情况的可能性很低，后果也不严重。它只会导致应用程序在不必要时偶尔降低其速率。
What if an MPLS domain wants to use ECN, but not all legacy routers are able to support it?
如果MPLS域希望使用ECN，但并非所有传统路由器都能支持它，该怎么办？
If the legacy router(s) are used in the interior, this is not a problem. They will simply have to drop the packets if they are congested, rather than mark them, which is the standard behavior for IP routers that are not ECN-enabled.
如果在内部使用传统路由器，这不是问题。如果数据包拥挤，他们将不得不丢弃数据包，而不是标记它们，这是未启用ECN的IP路由器的标准行为。
If the legacy router were used as an egress router, it would not be able to check the ECN-capability of the transport correctly. An
如果传统路由器用作出口路由器，它将无法正确检查传输的ECN能力。一
operator in this position would not be able to use this solution and therefore MUST NOT enable ECN unless all egress routers are ECN-capable.
处于此位置的操作员将无法使用此解决方案，因此，除非所有出口路由器都支持ECN，否则不得启用ECN。
[RFC3168] proposes the use of ECN in TCP, and it introduces the use of ECN-Echo and Congestion Window Reduced (CWR) flags in the TCP header for initialization. The TCP sender responds accordingly (such as not increasing the congestion window) when it receives an ECN-Echo (ECE) ACK packet (that is, an ACK packet with ECN-Echo flag set in the TCP header), then the sender knows that congestion was encountered in the network on the path from the sender to the receiver.
[RFC3168]建议在TCP中使用ECN，并在TCP报头中引入ECN Echo和拥塞窗口缩减（CWR）标志用于初始化。当TCP发送方收到ECN Echo（ECE）ACK数据包（即TCP报头中设置了ECN Echo标志的ACK数据包）时，它会做出相应的响应（例如不增加拥塞窗口），然后发送方知道在从发送方到接收方的路径上的网络中遇到了拥塞。
It would be possible to enable ECN in an MPLS domain for Diffserv PHBs like AF and best efforts that are expected to be used by TCP and similar transports (e.g., DCCP [RFC4340]). Then, end-to-end congestion control in transports capable of understanding ECN would be able to respond to approaching congestion on LSRs without having to rely on packet discard to signal congestion.
可以在MPLS域中为区分服务PHB（如AF）和TCP和类似传输（如DCCP[RFC4340]）使用的最大努力启用ECN。然后，能够理解ECN的传输中的端到端拥塞控制将能够响应LSR上接近的拥塞，而不必依赖数据包丢弃来发出拥塞信号。
Many operators today have deployed Diffserv using the E-LSP approach of [RFC3270]. In many cases, the number of PHBs used is less than 8, and hence there remain available codepoints in the EXP space. If an operator wished to support ECN for a single PHB, this could be accomplished by simply allocating a second codepoint to the PHB for the CM state of that PHB and retaining the old codepoint for the not-CM state. An operator with only four deployed PHBs could, of course, enable ECN marking on all those PHBs. It is easy to imagine cases where some PHBs might benefit more from ECN than others -- for example, an operator might use ECN on a premium data service but not on a PHB used for best-effort Internet traffic.
如今，许多运营商已经使用[RFC3270]的E-LSP方法部署了Diffserv。在许多情况下，使用的PHB数量少于8，因此EXP空间中仍然存在可用的代码点。如果运营商希望为单个PHB支持ECN，可以通过简单地为PHB的CM状态分配第二个代码点并为非CM状态保留旧代码点来实现。当然，只有四个已部署PHB的操作员可以在所有这些PHB上启用ECN标记。很容易想象一些PHB可能比其他PHB从ECN中受益更多的情况——例如，运营商可能在高级数据服务上使用ECN，但在用于尽力而为的互联网流量的PHB上不使用ECN。
As an illustrative example of how the EXP field might be used in this case, consider the example of an operator who is using the aggregated service classes proposed in [TSVWG]. He may choose to support ECN only for the Assured Elastic Treatment Aggregate, using the EXP codepoint 010 for the not-CM state and 011 for the CM state. All other codepoints could be the same as in [TSVWG]. Of course, any other combination of EXP values can be used according to the specific set of PHBs and marking conventions used within that operator's network.
作为Exp字段在这种情况下可能如何使用的说明性示例，请考虑使用[tvsWG]中提出的聚合服务类的操作员的示例。他可以选择仅为保证弹性处理骨料支持ECN，对于非CM状态使用EXP代码点010，对于CM状态使用011。所有其他代码点可以与[TSVWG]中的相同。当然，EXP值的任何其他组合都可以根据该运营商网络中使用的特定PHB集和标记约定来使用。
Shayman's traffic engineering [Shayman] presents another example application of ECN feedback in an MPLS domain. Shayman proposed the use of ECN by an egress LSR feeding back congestion to an ingress LSR to mitigate congestion by employing dynamic traffic engineering techniques, such as shifting flows to an alternate path. It proposed a new Resource Reservation Protocol (RSVP) message, which was sent by the egress LSR to the ingress LSR (and ignored by transit LSRs) to indicate congestion along the path. Thus, rather than providing the same style of congestion notification to endpoints as defined in [RFC3168], [Shayman] limits its scope to the MPLS domain only. This application of ECN in an MPLS domain could make use of the ECN encoding in the MPLS header that is defined in this document.
Shayman的流量工程[Shayman]介绍了ECN反馈在MPLS域中的另一个示例应用。Shayman建议通过出口LSR将拥塞反馈给入口LSR来使用ECN，通过采用动态流量工程技术（例如将流量转移到备用路径）来缓解拥塞。它提出了一种新的资源预留协议（RSVP）消息，该消息由出口LSR发送到入口LSR（并被过境LSR忽略），以指示路径上的拥塞。因此，与[RFC3168]中定义的向端点提供相同类型的拥塞通知不同，[Shayman]将其范围仅限于MPLS域。在MPLS域中应用ECN可以利用本文档中定义的MPLS报头中的ECN编码。
[PCN] proposes using pre-congestion notification (PCN) on routers within an edge-to-edge Diffserv region to control admission of new flows to the region and, if necessary, to terminate existing flows in response to disasters and other anomalous routing events. In this approach, the current level of PCN marking is picked up by the signaling used to initiate each flow in order to inform the admission control decision for the whole region at once. For example, extensions to RSVP [LEFAUCHEUR] and Next Steps in Signaling (NSIS) [NSIS], [ARUMAITHURAI] have been proposed.
[PCN]建议在边缘到边缘区分服务区域内的路由器上使用拥塞前通知（PCN），以控制新流量进入该区域，并在必要时终止现有流量，以响应灾难和其他异常路由事件。在这种方法中，PCN标记的当前级别由用于启动每个流的信令拾取，以便立即通知整个区域的接纳控制决策。例如，提出了对RSVP[LEFAUCHEUR]的扩展和信令（NSIS）[NSIS]，[ARUMAITHURAI]的下一步。
If LSRs are able to mark packets to signify congestion in MPLS, PCN marking could be used for admission control and flow termination across a Diffserv region, irrespective of whether it contained pure IP routers, MPLS LSRs, or both. Indeed, the solution could be somewhat more efficient to implement if aggregates could identify themselves by their MPLS label. Appendix A describes the mechanisms by which the necessary markings for PCN could be carried in the MPLS header.
如果LSR能够标记数据包以表示MPLS中的拥塞，则PCN标记可用于跨区分服务区域的接纳控制和流终止，而不管它是否包含纯IP路由器、MPLS LSR或两者。事实上，如果聚合可以通过其MPLS标签识别自己，那么解决方案的实现可能会更高效。附录A描述了在MPLS报头中携带PCN必要标记的机制。
We believe no new vulnerabilities are introduced by this document.
我们认为本文件没有引入新的漏洞。
We have considered whether malicious sources might be able to exploit the fact that interior LSRs will mark packets that are Not-ECT, relying on their egress LSR to drop them. Although this might allow sources to engineer a situation where more traffic is carried across an MPLS domain than should be, we figured that even if we hadn't introduced this feature, these sources would have been able to prevent these LSRs dropping this traffic anyway, simply by setting ECT in the first place.
我们已经考虑了恶意源是否能够利用内部LSR将标记非ECT的数据包这一事实，依靠其出口LSR丢弃这些数据包。虽然这可能允许源代码设计一种情况，即在MPLS域中传输的流量比应该的多，但我们认为，即使我们没有引入此功能，这些源代码也能够防止这些LSR丢弃此流量，只需首先设置ECT即可。
An ECN sender can use the ECN nonce [RFC3540] to detect a misbehaving receiver. The ECN nonce works correctly across an MPLS domain without requiring any specific support from the proposal in this document. The nonce does not need to be present in the MPLS shim header to detect a misbehaving receiver. As long as the nonce is present in the IP header when the ECN information is copied from the last MPLS shim header, it will be overwritten if congestion has been experienced by an LSR. This is all that is necessary for the sender to detect a misbehaving receiver. If there were a need for an ECN nonce in the MPLS shim header (e.g., to detect if one LSR were erasing the markings of an upstream LSR in the same domain), we believe this proposal does not preclude the later addition of an ECN nonce capability for specific DSCPs, just as it does not preclude any other use of the EXP codepoints.
ECN发送方可以使用ECN nonce[RFC3540]来检测行为异常的接收方。ECN nonce在MPLS域中正常工作，无需本文档中提案的任何特定支持。不需要在MPLS垫片报头中出现nonce来检测行为异常的接收器。当从最后一个MPLS垫片头复制ECN信息时，只要在IP头中存在nonce，如果LSR经历了拥塞，它就会被覆盖。这是发送方检测行为不端的接收方所必需的全部。如果MPLS垫片报头中需要ECN nonce（例如，检测一个LSR是否正在擦除同一域中上游LSR的标记），我们认为该建议不排除以后为特定DSCP添加ECN nonce功能，正如它不排除EXP码点的任何其他使用一样。
Thanks to K.K. Ramakrishnan and Sally Floyd for getting us thinking about this in the first place and for providing advice on tunneling of ECN packets, and to Sally Floyd, Joe Babiarz, Ben Niven-Jenkins, Phil Eardley, Ruediger Geib, and Magnus Westerlund for their comments on the document.
感谢K.K.罗摩克里希南和萨利·弗洛伊德让我们首先思考这一点，并为ECN数据包的隧道传输提供建议，感谢萨利·弗洛伊德、乔·巴比亚兹、本·尼文·詹金斯、菲尔·埃德利、鲁迪格·盖布和马格纳斯·韦斯特隆德对该文件的评论。
This appendix describes how the mechanisms described in the body of the document can be extended to support PCN [PCN]. Our intent here is to show that the mechanisms are readily extended to more complex scenarios than ECN, particularly in the case where more codepoints are needed, but this appendix may be safely ignored if one is interested only in supporting ECN. Note that the PCN standards are still very much under development at the time of writing; hence, the precise details contained in this appendix may be subject to change, and we stress that this appendix is for illustrative purposes only.
本附录描述了如何扩展文档正文中描述的机制以支持PCN[PCN]。我们在这里的目的是表明，这些机制很容易扩展到比ECN更复杂的场景，特别是在需要更多代码点的情况下，但是如果只对支持ECN感兴趣，则可以安全地忽略本附录。请注意，在编写本报告时，PCN标准仍处于发展阶段；因此，本附录中包含的确切细节可能会发生变化，我们强调本附录仅用于说明目的。
The relevant aspects of PCN for the purposes of this discussion are:
在本次讨论中，PCN的相关方面包括：
o PCN uses 3 states rather than 2 for ECN -- these are referred to as admission marked (AM), termination marked (TM), and not marked (NM) states. (See Section 9.4 for further discussion of PCN and the possibility of using fewer codepoints).
o PCN对ECN使用3种状态，而不是2种——它们被称为准入标记（AM）、终止标记（TM）和未标记（NM）状态。（关于PCN的进一步讨论以及使用较少代码点的可能性，请参见第9.4节）。
o A packet can go from NM to AM, from NM to TM, or from AM to TM, but no other transition is possible.
o 数据包可以从NM到AM，从NM到TM，或从AM到TM，但不可能有其他转换。
o The determination of whether a packet is subject to PCN is based on the PHB of the packet.
o 根据分组的PHB来确定分组是否服从PCN。
Thus, to support PCN fully in an MPLS domain for a particular PHB, a total of 3 codepoints need to be allocated for that PHB. These 3 codepoints represent the admission marked (AM), termination marked (TM), and not marked (NM) states. The procedures described in Section 4 above need to be slightly modified to support this scenario. The following procedures are invoked when the topmost DSCP or EXP value indicates a PHB that supports PCN.
因此，为了在MPLS域中为特定PHB完全支持PCN，总共需要为该PHB分配3个代码点。这3个代码点表示允许标记（AM）、终止标记（TM）和未标记（NM）状态。需要稍微修改上文第4节中描述的程序以支持此场景。当最顶端的DSCP或EXP值指示支持PCN的PHB时，将调用以下过程。
If the IP packet header indicates AM, set the EXP value of all entries in the label stack to AM. If the IP packet header indicates TM, set the EXP value of all entries in the label stack to TM. For any other marking of the IP header, set the EXP value of all entries in the label stack to NM.
如果IP数据包头指示AM，则将标签堆栈中所有条目的EXP值设置为AM。如果IP数据包头指示TM，则将标签堆栈中所有条目的EXP值设置为TM。对于IP标头的任何其他标记，请将标签堆栈中所有条目的EXP值设置为NM。
The procedures of Section 4.2 apply.
第4.2节的程序适用。
The EXP value can be set to AM or TM according to the same procedures as described in [BRISCOE-CL]. For the purposes of this document, it does not matter exactly which algorithms are used to decide when to set AM or TM; all that matters is that if a router would have marked AM (or TM) in the IP header, it should set the EXP value in the MPLS header to the AM (or TM) codepoint.
EXP值可根据[BRISCOE-CL]中所述的相同程序设置为AM或TM。就本文件而言，决定何时设置AM或TM的算法并不重要；重要的是，如果路由器在IP报头中标记了AM（或TM），那么它应该将MPLS报头中的EXP值设置为AM（或TM）码点。
When popping an MPLS Label exposes another MPLS label, the AM or TM marking should be transferred to the exposed EXP field in the following manner:
当弹出一个MPLS标签暴露另一个MPLS标签时，AM或TM标记应按以下方式转移到暴露的EXP字段：
o If the inner EXP value is NM, then it should be set to the same marking state as the EXP value of the popped label stack entry.
o 如果内部EXP值为NM，则应将其设置为与弹出标签堆栈项的EXP值相同的标记状态。
o If the inner EXP value is AM, it should be unchanged if the popped EXP value was AM, and it should be set to TM if the popped EXP value was TM. If the popped EXP value was NM, this should be logged in some way, and the inner EXP value should be unchanged.
o 如果内部EXP值为AM，则如果弹出EXP值为AM，则应保持不变；如果弹出EXP值为TM，则应将其设置为TM。如果弹出的EXP值为NM，则应以某种方式记录，并且内部EXP值应保持不变。
o If the inner EXP value is TM, it should be unchanged whatever the popped EXP value was, but any EXP value other than TM should be logged.
o 如果内部EXP值为TM，则无论弹出的EXP值是什么，它都应保持不变，但应记录除TM以外的任何EXP值。
When popping the last MPLS Label exposes the IP header, there are two cases to consider:
当弹出最后一个MPLS标签以暴露IP头时，有两种情况需要考虑：
o the popping LSR is *not* the egress router of the PCN region, in which case AM or TM marking should be transferred to the exposed IP header field; or
o 弹出LSR*不是*PCN区域的出口路由器，在这种情况下，AM或TM标记应转移到公开的IP报头字段；或
o the popping LSR *is* the egress router of the PCN region.
o 弹出的LSR*是PCN区域的出口路由器。
In the latter case, the behavior of the egress LSR is defined in [PCN] and is beyond the scope of this document. In the former case, the marking should be transferred from the popped MPLS header to the exposed IP header as follows:
在后一种情况下，出口LSR的行为在[PCN]中定义，超出了本文件的范围。在前一种情况下，标记应从弹出的MPLS报头转移到公开的IP报头，如下所示：
o If the inner IP header value is neither AM nor TM, and the EXP value was NM, then the IP header should be unchanged. For any other EXP value, the IP header should be set to the same marking state as the EXP value of the popped label stack entry.
o 如果内部IP头值既不是AM也不是TM，EXP值是NM，则IP头应保持不变。对于任何其他EXP值，IP头应设置为与弹出标签堆栈项的EXP值相同的标记状态。
o If the inner IP header value is AM, it should be unchanged if the popped EXP value was AM, and it should be set to TM if the popped EXP value was TM. If the popped EXP value was NM, this should be logged in some way and the inner IP header value should be unchanged.
o 如果内部IP报头值为AM，则如果弹出的EXP值为AM，则应保持不变；如果弹出的EXP值为TM，则应将其设置为TM。如果弹出的EXP值为NM，则应以某种方式记录该值，并且内部IP头值应保持不变。
o If the IP header value is TM, it should be unchanged whatever the popped EXP value was, but any EXP value other than TM should be logged.
o 如果IP头的值是TM，那么无论弹出的EXP值是什么，它都应该保持不变，但是应该记录除TM以外的任何EXP值。
Normative References
规范性引用文件
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[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月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
Informative References
资料性引用
[ARUMAITHURAI] Arumaithurai, M., "NSIS PCN-QoSM: A Quality of Service Model for Pre-Congestion Notification (PCN)", Work in Progress, September 2007.
[ARUMAITHURAI]ARUMAITHURAI，M.，“NSIS PCN QoSM：拥塞前通知（PCN）的服务质量模型”，正在进行的工作，2007年9月。
[BRISCOE-CL] Briscoe, B., "Pre-Congestion Notification Marking", Work in Progress, October 2006.
[BRISCOE-CL]BRISCOE，B.，“拥堵前通知标记”，正在进行的工作，2006年10月。
[BRISCOE-ECN] Briscoe, B., "Layered Encapsulation of Congestion Notification", Work in Progress, July 2007.
[BRISCOE-ECN]BRISCOE，B.，“拥塞通知的分层封装”，正在进行的工作，2007年7月。
[Floyd] Ramakrishnan, K., Floyd, S., and B. Davie, "A Proposal to Incorporate ECN in MPLS", Work in Progress, June 1999.
[Floyd]Ramakrishnan，K.，Floyd，S.，和B.Davie，“将ECN纳入MPLS的提案”，正在进行的工作，1999年6月。
[LEFAUCHEUR] Faucheur, F., Charny, A., Briscoe, B., Eardley, P., Barbiaz, J., and K. Chan, "RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN)", Work in Progress, June 2006.
[LEFAUCHEUR]Faucheur，F.，Charny，A.，Briscoe，B.，Eardley，P.，Barbiaz，J.，和K.Chan，“使用拥塞前通知（PCN）的区分服务接入控制RSVP扩展”，正在进行中的工作，2006年6月。
[NSIS] Bader, A., Westberg, L., Karagiannis, G., Cornelia, C., and T. Phelan, "RMD-QOSM - The Resource Management in Diffserv QOS Model", Work in Progress, November 2007.
[NSIS]Bader，A.，Westberg，L.，Karagiannis，G.，Cornelia，C.，和T.Phelan，“RMD-QOSM-区分服务QOS模型中的资源管理”，正在进行的工作，2007年11月。
[PCN] Eardley, P., "Pre-Congestion Notification Architecture", Work in Progress, November 2007.
[PCN]Eardley，P.，“拥堵前通知体系结构”，正在进行的工作，2007年11月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]Grossman，D.“区分服务的新术语和澄清”，RFC 3260，2002年4月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[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月。
[TSVWG] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", Work in Progress, November 2007.
[TSVWG]Chan，K.，Babiarz，J.，和F.Baker，“区分服务类的聚合”，正在进行的工作，2007年11月。
Authors' Addresses
作者地址
Bruce Davie Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
布鲁斯·戴维斯思科系统公司，马萨诸塞州1414年。美国马萨诸塞州博克斯伯勒大道01719号
EMail: bsd@cisco.com
EMail: bsd@cisco.com
Bob Briscoe BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich Suffolk IP5 3RE United Kingdom
Bob Briscoe BT Research B54/77，天狼星之家Adastral Park Martlesham Heath Ipswich Suffolk IP5 3英国
EMail: bob.briscoe@bt.com
EMail: bob.briscoe@bt.com
June Tay BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich Suffolk IP5 3RE United Kingdom
英国电信研究院B54/77年6月，天狼星之家阿达斯特拉尔公园马特勒沙姆希思伊普斯维奇萨福克IP5 3RE英国
EMail: june.tay@bt.com
EMail: june.tay@bt.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.