Internet Engineering Task Force (IETF) G. Karagiannis
Request for Comments: 6627 University of Twente
Category: Informational K. Chan
ISSN: 2070-1721 Consultant
T. Moncaster
University of Cambridge
M. Menth
University of Tuebingen
P. Eardley
B. Briscoe
BT
July 2012
Internet Engineering Task Force (IETF) G. Karagiannis
Request for Comments: 6627 University of Twente
Category: Informational K. Chan
ISSN: 2070-1721 Consultant
T. Moncaster
University of Cambridge
M. Menth
University of Tuebingen
P. Eardley
B. Briscoe
BT
July 2012
Overview of Pre-Congestion Notification Encoding
拥塞前通知编码综述
Abstract
摘要
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre-congestion.
预拥塞通知（PCN）的目的是保护区分服务域内非弹性流的服务质量（QoS）。在PCN域中的每个链路上，对PCN流量的总速率进行计量，当超过某些配置速率时，会适当标记PCN数据包。出口节点向决策点提供关于PCN数据包的PCN标记的信息，这些信息允许它们决定是否接纳或阻止新的流请求，并在严重的预拥塞期间终止一些已经接纳的流。
The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution.
PCN工作组探讨了将拥塞前信息编码到IP报头中的多种方法。本文档提供了这些方法的详细信息，并解释了适用于任何解决方案的约束。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6627.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6627.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. General PCN Encoding Requirements ...............................5
2.1. Metering and Marking Algorithms ............................5
2.2. Approaches for PCN-Based Admission Control and Flow
Termination ................................................5
2.2.1. Dual Marking (DM) ...................................5
2.2.2. Single Marking (SM) .................................6
2.2.3. Packet-Specific Dual Marking (PSDM) .................7
2.2.4. Preferential Packet Dropping ........................8
3. Encoding Constraints ............................................9
3.1. Structure of the DS Field ..................................9
3.2. Constraints from the DS Field ..............................9
3.2.1. General Scarcity of DSCPs ...........................9
3.2.2. Handling of the DSCP in Tunneling Rules ............10
3.2.3. Restoration of Original DSCPs at the Egress Node ...10
3.3. Constraints from the ECN Field ............................11
3.3.1. Structure and Use of the ECN Field .................11
3.3.2. Redefinition of the ECN Field ......................12
3.3.3. Handling of the ECN Field in Tunneling Rules .......12
3.3.3.1. Limited-Functionality Option ..............12
3.3.3.2. Full-Functionality Option .................13
3.3.3.3. Tunneling with IPSec ......................13
3.3.3.4. ECN Tunneling .............................13
3.3.4. Restoration of the Original ECN Field at
the PCN-Egress-Node ................................14
4. Comparison of Encoding Options .................................15
4.1. Baseline Encoding .........................................15
4.2. Encoding with 1 DSCP Providing 3 States ...................16
4.3. Encoding with 2 DSCPs Providing 3 or More States ..........16
4.4. Encoding for Packet-Specific Dual Marking (PSDM) ..........16
4.5. Standardized Encodings ....................................17
5. Conclusion .....................................................17
6. Security Implications ..........................................17
7. Acknowledgements ...............................................17
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................18
1. Introduction ....................................................4
2. General PCN Encoding Requirements ...............................5
2.1. Metering and Marking Algorithms ............................5
2.2. Approaches for PCN-Based Admission Control and Flow
Termination ................................................5
2.2.1. Dual Marking (DM) ...................................5
2.2.2. Single Marking (SM) .................................6
2.2.3. Packet-Specific Dual Marking (PSDM) .................7
2.2.4. Preferential Packet Dropping ........................8
3. Encoding Constraints ............................................9
3.1. Structure of the DS Field ..................................9
3.2. Constraints from the DS Field ..............................9
3.2.1. General Scarcity of DSCPs ...........................9
3.2.2. Handling of the DSCP in Tunneling Rules ............10
3.2.3. Restoration of Original DSCPs at the Egress Node ...10
3.3. Constraints from the ECN Field ............................11
3.3.1. Structure and Use of the ECN Field .................11
3.3.2. Redefinition of the ECN Field ......................12
3.3.3. Handling of the ECN Field in Tunneling Rules .......12
3.3.3.1. Limited-Functionality Option ..............12
3.3.3.2. Full-Functionality Option .................13
3.3.3.3. Tunneling with IPSec ......................13
3.3.3.4. ECN Tunneling .............................13
3.3.4. Restoration of the Original ECN Field at
the PCN-Egress-Node ................................14
4. Comparison of Encoding Options .................................15
4.1. Baseline Encoding .........................................15
4.2. Encoding with 1 DSCP Providing 3 States ...................16
4.3. Encoding with 2 DSCPs Providing 3 or More States ..........16
4.4. Encoding for Packet-Specific Dual Marking (PSDM) ..........16
4.5. Standardized Encodings ....................................17
5. Conclusion .....................................................17
6. Security Implications ..........................................17
7. Acknowledgements ...............................................17
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................18
The objective of Pre-Congestion Notification (PCN) [RFC5559] is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. Two mechanisms are used: admission control (AC), to decide whether to admit or block a new flow request, and flow termination (FT), to terminate some existing flows during serious pre-congestion. To achieve this, the overall rate of PCN-traffic is metered on every link in the domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. These configured rates are below the rate of the link. Thus, boundary nodes are notified of a potential overload before any real congestion occurs (hence "pre-congestion notification").
预拥塞通知（PCN）[RFC5559]的目标是以简单、可扩展和健壮的方式保护区分服务域内非弹性流的服务质量（QoS）。使用两种机制：接纳控制（AC）来决定是否接纳或阻止新的流请求，以及流终止（FT）来在严重预拥塞期间终止一些现有流。为了实现这一点，在域中的每个链路上测量PCN流量的总速率，并且当超过某些配置速率时，适当地标记PCN数据包。这些配置的速率低于链路速率。因此，在任何实际拥塞发生之前，边界节点会收到潜在过载的通知（因此称为“拥塞前通知”）。
[RFC5670] provides for two metering and marking functions that are configured with reference rates. Threshold-marking marks all PCN-packets once their traffic rate on a link exceeds the configured reference rate (PCN-threshold-rate). Excess-traffic-marking marks only those PCN-packets that exceed the configured reference rate (PCN-excess-rate).
[RFC5670]提供两种计量和标记功能，这些功能配置有参考速率。当链路上的通信速率超过配置的参考速率（PCN阈值速率）时，阈值标记将标记所有PCN数据包。过量流量标记仅标记超过配置的参考速率（PCN过量速率）的PCN数据包。
Egress nodes monitor the PCN-marks of received PCN-packets and provide information about the PCN-marks to the decision points that take decisions about the flow admission and termination on this basis [RFC6661] [RFC6662].
出口节点监控接收到的PCN数据包的PCN标记，并向决策点提供有关PCN标记的信息，决策点在此基础上决定流的接纳和终止[RFC6661][RFC6662]。
This PCN information has to be encoded into the IP header. This requires at least three different codepoints: one for PCN-traffic that has not been marked, one for traffic that has been marked by the threshold meter, and one for traffic that has been marked by the excess-traffic-meter.
此PCN信息必须编码到IP报头中。这至少需要三个不同的代码点：一个用于未标记的PCN流量，一个用于已由阈值表标记的流量，以及一个用于已由过量流量表标记的流量。
Since unused codepoints are not available for that purpose in the IP header (versions 4 and 6), already used codepoints must be reused, which imposes additional constraints on the design and applicability of PCN-based AC and FT. This document summarizes these issues as a record of the PCN working group discussions and for the benefit of the wider IETF community.
由于未使用的代码点在IP报头（版本4和版本6）中不可用，因此必须重用已使用的代码点，这对基于PCN的AC和FT的设计和适用性施加了额外的限制。本文件将这些问题总结为PCN工作组讨论的记录，以利于更广泛的IETF社区。
In Section 2, we briefly point out the PCN encoding requirement imposed by metering and marking algorithms, and by special packet drop strategies. The Differentiated Services field (6 bits -- see [RFC3260] updating [RFC2474] in this respect) and the Explicit Congestion Notification (ECN) field (2 bits) [RFC3168] have been selected to be reused for encoding of PCN-marks (PCN encoding). In Section 3, we briefly explain the constraints imposed by this decision. In Section 4, we review different PCN encodings considered
在第2节中，我们简要指出了计量和标记算法以及特殊丢包策略对PCN编码的要求。已选择将区分服务字段（6位——请参见[RFC3260]更新[RFC2474]）和显式拥塞通知（ECN）字段（2位）[RFC3168]重新用于PCN标记的编码（PCN编码）。在第3节中，我们简要解释了该决定施加的限制。在第4节中，我们回顾了所考虑的不同PCN编码
by the PCN working group that allow different implementations of PCN-based AC and FT, which have different pros and cons.
PCN工作组允许基于PCN的AC和FT的不同实现，这两种方式有不同的优缺点。
The choice of metering and marking algorithms and the way they are applied to PCN-based AC and FT impose certain requirements on PCN encoding.
计量和标记算法的选择及其应用于基于PCN的AC和FT的方式对PCN编码提出了一定的要求。
Two different metering and marking algorithms are defined in [RFC5670]: excess-traffic-marking and threshold-marking. They are both configured with reference rates that are termed PCN-excess-rate and PCN-threshold-rate, respectively. When traffic for PCN-flows enters a PCN-domain, the PCN-ingress-node sets a codepoint in the IP header indicating that the packet is subject to PCN-metering and PCN-marking and that it is not-marked (NM). The two metering and marking algorithms possibly re-mark PCN-packets as excess-traffic-marked (ETM) or threshold-marked (ThM).
[RFC5670]中定义了两种不同的计量和标记算法：超额流量标记和阈值标记。它们都配置了参考速率，分别称为PCN超额速率和PCN阈值速率。当PCN流的流量进入PCN域时，PCN入口节点在IP报头中设置一个代码点，指示该数据包受PCN计量和PCN标记的约束，并且未标记（NM）。这两种计量和标记算法可能将PCN数据包重新标记为过量流量标记（ETM）或阈值标记（ThM）。
Excess-traffic-marking ETM-marks all not-ETM-marked PCN-traffic that is in excess of the PCN-excess-rate. To that end, the algorithm needs to know whether a PCN-packet has already been marked with ETM or not. Threshold-marking re-marks all not-marked PCN-traffic to ThM when the rate of PCN-traffic exceeds the PCN-threshold-rate. Therefore, it does not need knowledge of the prior marking state of the packet for metering, but such knowledge is needed for packet re-marking.
超额流量标记ETM标记超过PCN超额率的所有未标记ETM的PCN流量。为此，算法需要知道PCN数据包是否已经用ETM标记。当PCN流量的速率超过PCN阈值速率时，阈值标记将所有未标记的PCN流量重新标记为ThM。因此，它不需要关于用于计量的分组的先前标记状态的知识，但是对于分组重新标记需要这种知识。
We briefly review three different approaches to implement PCN-based AC and FT and derive their requirements for PCN encoding.
我们简要回顾了实现基于PCN的AC和FT的三种不同方法，并推导了它们对PCN编码的要求。
The intuitive approach for PCN-based AC and FT requires that threshold and excess-traffic-marking are simultaneously activated on all links of a PCN-domain, and their reference rates are configured with the PCN-admissible-rate (AR) and the PCN-supportable-rate (SR), respectively. Threshold-marking meters all PCN-traffic, but re-marks only NM-traffic to ThM. Excess-traffic-marking meters only NM- and ThM-traffic and re-marks it to ETM. Thus, both meters and markers need to identify PCN-packets and their exact PCN codepoint. We call this marking behavior dual marking (DM) and Figure 1 illustrates all possible re-marking actions.
基于PCN的AC和FT的直观方法要求在PCN域的所有链路上同时激活阈值和过量流量标记，并且其参考速率分别配置为PCN允许速率（AR）和PCN支持速率（SR）。阈值标记测量所有PCN流量，但仅将NM流量重新标记为ThM。超额流量标记仅测量NM和ThM流量，并将其重新标记到ETM。因此，计量器和标记器都需要识别PCN数据包及其确切的PCN码点。我们称这种标记行为为双重标记（DM），图1说明了所有可能的重新标记操作。
NM -----------> ThM
\ /
\ /
\ /
> ETM <
NM -----------> ThM
\ /
\ /
\ /
> ETM <
Figure 1: PCN Codepoint Re-Marking Diagram for Dual Marking (DM)
图1：双重标记（DM）的PCN代码点重新标记图
Dual marking is used to support the Controlled-Load PCN (CL-PCN) edge behavior [RFC6661]. We briefly summarize the concept. All actions are performed on per-ingress-egress-aggregate basis. The egress node measures the rate of NM-, ThM-, and ETM-traffic in regular intervals and sends them as PCN egress reports to the AC and FT decision point.
双标记用于支持受控荷载PCN（CL-PCN）边缘行为[RFC6661]。我们简要总结一下这个概念。所有操作均基于每个入口-出口聚合执行。出口节点定期测量NM、ThM和ETM流量的速率，并将它们作为PCN出口报告发送给AC和FT决策点。
If the proportion of re-marked (ThM- and ETM-) PCN-traffic is larger than a defined threshold, called CLE-limit, the decision point blocks new flow requests until new PCN egress reports are received; otherwise, it admits them. With CL-PCN, AC is rather robust with regard to the value chosen for the CLE-limit. FT works as follows. If the ETM-traffic rate is positive, the decision point triggers the ingress node to send a newly measured rate of the sent PCN-traffic. The decision point calculates the rate of PCN-traffic that needs to be terminated by
如果重新标记的（ThM-和ETM-）PCN流量的比例大于定义的阈值（称为CLE限制），决策点将阻止新的流量请求，直到收到新的PCN出口报告；否则，它就会承认他们。对于CL-PCN，AC对于为CLE限值选择的值相当稳健。《金融时报》的工作如下。如果ETM通信速率为正，则决策点触发入口节点发送新测量的已发送PCN通信速率。决策点计算需要终止的PCN流量的速率
termination-rate = PCN-sent-rate - (rate-of-NM-traffic + rate-of-ThM-traffic)
终止速率=PCN发送速率-（NM通信速率+ThM通信速率）
and terminates an appropriate set of flows. CL-PCN is accurate enough for most application scenarios and its implementation complexity is acceptable, therefore, it is a preferred implementation option for PCN-based AC and FT.
并终止一组适当的流。CL-PCN对于大多数应用场景来说都足够精确，并且其实现复杂性是可以接受的，因此，它是基于PCN的AC和FT的首选实现选项。
Single marking uses only excess-traffic-marking whose reference rate is set to the PCN-admissible-rate (AR) on all links of the PCN-domain. Figure 2 illustrates all possible re-marking actions.
单一标记仅使用参考率设置为PCN域所有链路上的PCN容许率（AR）的多余交通标记。图2说明了所有可能的重新标记操作。
NM --------> ETM
NM --------> ETM
Figure 2: PCN Codepoint Re-Marking Diagram for Single Marking (SM)
图2：单个标记（SM）的PCN代码点重新标记图
Single marking is used to support the Single-Marking PCN (SM-PCN) edge behavior [RFC6662]. We briefly summarize the concept.
单标记用于支持单标记PCN（SM-PCN）边缘行为[RFC6662]。我们简要总结一下这个概念。
AC works essentially in the same way as with CL-PCN, but AC is sensitive to the value of the CLE-limit. Also FT works similarly to CL-PCN. The PCN-supportable-rate (SR) is not configured on any link, but is implicitly
AC的工作原理与CL-PCN基本相同，但AC对CLE限值敏感。此外，FT的工作原理与CL-PCN类似。PCN可支持速率（SR）未在任何链路上配置，而是隐式配置的
SR=u*AR
SR=u*AR
in the PCN-domain using a network-wide constant u. The decision point triggers FT only if the rate-of-NM-traffic * u < rate-of-NM-traffic + rate-of-ETM-traffic. Then it requests the PCN-sent-rate from the corresponding PCN-ingress-node and calculates the amount of PCN-traffic to be terminated by
在PCN域中，使用网络范围内的常数u。只有当NM流量率*u<NM流量率+ETM流量率时，决策点才会触发FT。然后，它从相应的PCN入口节点请求PCN发送速率，并计算要被终止的PCN通信量
termination-rate = PCN-sent-rate - rate-of-NM-traffic * u,
终止速率=PCN发送速率-NM流量速率*u，
and terminates an appropriate set of flows.
并终止一组适当的流。
SM-PCN requires only two PCN codepoints and only excess-traffic-marking is needed, which means that it might be earlier to the market than CL-PCN since some chipsets do not yet support threshold-marking.
SM-PCN只需要两个PCN代码点，并且只需要额外的流量标记，这意味着它可能比CL-PCN更早上市，因为一些芯片组还不支持阈值标记。
However, it only works well when ingress-egress-aggregates have a high PCN-packet rate, which is not always the case. Otherwise, over-admission and over-termination may occur [Menth12] [Menth10].
然而，它只有在入口-出口聚合具有高PCN分组速率时才能很好地工作，但情况并非总是如此。否则，可能会出现过度接纳和过度终止[Menth12][Menth10]。
Packet-specific dual marking (PSDM) uses threshold-marking and excess-traffic-marking, whose reference rates are configured with the PCN-admissible-rate (AR) and the PCN-supportable-rate (SR), respectively. There are two different types of not-marked packets: those that are subject to threshold-marking (not-ThM), and those that are subject to excess-traffic-marking (not-ETM). Both not-ThM and not-ETM are used for PCN-traffic that is not yet re-marked (like NM with single and dual marking), and their specific use is determined by higher-layer information (see below). Threshold-marking meters all PCN-traffic and re-marks only not-ThM packets to PCN-marked (PM). In contrast, excess-traffic-marking meters only not-ETM packets and possibly re-marks them to PM, too. Again, both meters and markers need to identify PCN-packets and their exact PCN codepoint. Figure 3 illustrates all possible re-marking actions.
分组特定双标记（PSDM）使用阈值标记和过量流量标记，其参考速率分别配置为PCN允许速率（AR）和PCN支持速率（SR）。有两种不同类型的未标记数据包：受阈值标记（非ThM）约束的数据包和受过量流量标记（非ETM）约束的数据包。not ThM和not ETM均用于尚未重新标记的PCN流量（如带有单标记和双标记的NM），其具体用途由更高层信息决定（见下文）。阈值标记测量所有PCN流量，仅将未标记的ThM数据包重新标记为PCN标记（PM）。相比之下，多余的流量标记仪表不仅不能标记ETM数据包，而且可能也会将它们重新标记到PM。同样，计量器和标记器都需要识别PCN数据包及其确切的PCN码点。图3说明了所有可能的重新标记操作。
not-ThM not-ETM
\ /
\ /
\ /
> PM <
not-ThM not-ETM
\ /
\ /
\ /
> PM <
Figure 3: PCN Codepoint Re-Marking Diagram for Packet-Specific Dual Marking (PSDM)
图3：包特定双重标记（PSDM）的PCN码点重新标记图
An edge behavior for PSDM has been presented in [Menth09] and [PCN-MS-AC]. We call it PSDM-PCN. In contrast to CL-PCN and SM-PCN, AC is realized by reusing initial signaling messages for probing purposes. The assumption is that admission requests are triggered by an external end-to-end signaling protocol, e.g., RSVP [RFC2205]. Signaling traffic for a flow is also labeled as PCN-traffic, and if an initial signaling message traverses the PCN-domain and is re-marked, then the corresponding admission request is blocked. This is a lightweight probing mechanism that does not generate extra traffic and does not introduce probing delay. In PSDM-PCN, PCN-ingress-nodes label initial signaling messages as not-ThM, and threshold-marking configured with admissible rates possibly re-marks them to PM. Data packets are labeled with not-ETM, and excess-traffic-marking configured with supportable rates possibly re-marks them to PM, too, so that the same algorithms for FT may be used as for CL-PCN and SM-PCN.
[Menth09]和[PCN-MS-AC]中介绍了PSDM的边缘特性。我们称之为PSDM-PCN。与CL-PCN和SM-PCN不同，AC是通过重用初始信令消息来实现探测目的的。假设接纳请求由外部端到端信令协议触发，例如RSVP[RFC2205]。流的信令通信量也被标记为PCN通信量，如果初始信令消息穿过PCN域并被重新标记，则相应的接纳请求被阻止。这是一种轻量级探测机制，不会产生额外流量，也不会引入探测延迟。在PSDM-PCN中，PCN入口节点将初始信令消息标记为非ThM，并且配置有容许速率的阈值标记可能将它们重新标记为PM。数据包用not ETM标记，配置有可支持速率的多余流量标记也可能将其重新标记为PM，因此FT的算法可能与CL-PCN和SM-PCN的算法相同。
PSDM has three major disadvantages. First, signalling traffic needs to be marked with a PCN-enabled DSCP so that it either shares the same queue as data traffic, which may not be desired by some operators, or multiple PCN-enabled DSCPs are needed, which is not a pragmatic solution. Second, reservations for PCN-flows need to be triggered by a path-coupled end-to-end signalling protocol, which restricts the choice of the signalling protocol. And third, the selected signalling protocols must be adapted to take advantage of PCN-marked signalling messages for admission decisions, which incurs some extra effort before PSDM can be used.
PSDM有三个主要缺点。首先，信令业务需要使用启用PCN的DSCP进行标记，以便它或者与数据业务共享同一队列（某些运营商可能不希望这样），或者需要多个启用PCN的DSCP，这不是一个实用的解决方案。其次，PCN流的保留需要由路径耦合的端到端信令协议触发，这限制了信令协议的选择。第三，所选择的信令协议必须进行调整，以利用带有PCN标记的信令消息来进行接纳决策，这需要在使用PSDM之前付出一些额外的努力。
The advantages are that the AC algorithm is more accurate than the one of CL-PCN and SM-PCN [Menth12], that often only a single DSCP is needed, and that the new tunneling rules in [RFC6040] are not needed for deployment (Section 3.3.3).
优点是AC算法比CL-PCN和SM-PCN[Menth12]算法更精确，通常只需要一个DSCP，部署时不需要[RFC6040]中的新隧道规则（第3.3.3节）。
The termination algorithms described in [RFC6661] and [RFC6662] require the preferential dropping of ETM-marked packets to avoid over-termination in the case of packet loss. An analysis explaining this phenomenon can be found in Section 4 of [Menth10].
[RFC6661]和[RFC6662]中描述的终止算法要求优先丢弃ETM标记的数据包，以避免在数据包丢失的情况下过度终止。解释这一现象的分析见[Menth10]第4节。
Thus, [RFC5670] recommends that ETM-marked packets "SHOULD be preferentially dropped". As a consequence, droppers must have access to the exact marking information of PCN-packets.
因此，[RFC5670]建议ETM标记的数据包“应优先丢弃”。因此，滴管必须能够访问PCN数据包的准确标记信息。
The PCN working group decided to use a combination of the 6-bit Differentiated Services (DS) field and the ECN field for the encoding of the PCN-marks (see [RFC6660]). This section describes the criteria that are used to compare the resulting encoding options described in Section 4.
PCN工作组决定使用6位区分服务（DS）字段和ECN字段的组合来编码PCN标记（参见[RFC6660]）。本节描述了用于比较第4节中描述的结果编码选项的标准。
Figure 4 shows the structure of the DS and ECN fields. [RFC0793] defined the 8-bit TOS octet and [RFC2474] redefined it as the DS field, including the two least significant bits as currently unused (CU). [RFC3168] assigned the two CU bits to ECN and [RFC3260] redefined the DS field as only the most significant 6-bits of the (former) IPv4 TOS octet, thus separating the two-bit ECN field from the DS field.
图4显示了DS和ECN字段的结构。[RFC0793]定义了8位TOS八位字节，[RFC2474]将其重新定义为DS字段，包括当前未使用的两个最低有效位（CU）。[RFC3168]将两个CU位分配给ECN，[RFC3260]将DS字段重新定义为（先前）IPv4 TOS八位字节中最重要的6位，从而将两位ECN字段与DS字段分离。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DS | ECN |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DS | ECN |
+---+---+---+---+---+---+---+---+
DS: Differentiated Services field [RFC2474], [RFC3260] ECN: ECN field [RFC3168]
DS:区分服务字段[RFC2474]，[RFC3260]ECN:ECN字段[RFC3168]
Figure 4: The Structure of the DS and ECN Fields
图4:DS和ECN字段的结构
The Differentiated Services Codepoint (DSCP) set in the DS field indicates the per-hop behavior (PHB), i.e., the treatment IP packets receive from nodes in a DS domain. Multiple DSCPs may indicate the same PHB. PCN-traffic is high-priority traffic, which uses a DSCP (or DSCPs) that indicates a PHB with preferred treatment.
DS字段中设置的区分服务代码点（DSCP）表示每跳行为（PHB），即从DS域中的节点接收的处理IP数据包。多个DSCP可能表示同一PHB。PCN流量是高优先级流量，它使用DSCP（或DSCP）表示具有首选治疗的PHB。
As the number of unused DSCPs is small, PCN encoding should use only one additional DSCP for each DSCP originally used to indicate the PHB and in any case should not use more than two. Therefore, the DSCP should be used to indicate that traffic is subject to PCN-metering and PCN-marking, but not to differentiate various PCN-markings.
由于未使用的DSCP数量较少，PCN编码应仅为最初用于指示PHB的每个DSCP使用一个额外的DSCP，并且在任何情况下都不应使用两个以上的DSCP。因此，DSCP应用于指示交通受PCN计量和PCN标记的影响，而不是用于区分各种PCN标记。
PCN encoding must be chosen in such a way that PCN-traffic can be tunneled within a PCN-domain without any impact on PCN-metering and re-marking. In the following, the "inner header" refers to the header of the encapsulated packet and the "outer header" refers to the encapsulating header.
PCN编码的选择必须确保PCN流量可以在PCN域内进行隧道传输，而不会对PCN计量和重新标记造成任何影响。在下文中，“内部报头”指的是封装包的报头，“外部报头”指的是封装报头。
[RFC2983] provides two tunneling modes for Differentiated Services networks. The uniform model copies the DSCP from the inner header to the outer header upon encapsulation, and it copies the DSCP from the outer header to the inner header upon decapsulation. This assures that changes applied to the DSCP field survive encapsulation and decapsulation. In contrast, the pipe model ignores the content of the DSCP field in the outer header upon decapsulation. Therefore, decapsulation erases changes applied to the DSCP along the tunnel. As a consequence, only the uniform model may be used for tunneling PCN-traffic within a PCN-domain, if PCN encoding uses more than a single DSCP.
[RFC2983]为区分服务网络提供两种隧道模式。统一模型在封装时将DSCP从内部标头复制到外部标头，在解除封装时将DSCP从外部标头复制到内部标头。这确保应用于DSCP字段的更改在封装和解除封装后仍然有效。相反，管道模型在解除封装时忽略外部标头中DSCP字段的内容。因此，解除封装将擦除沿隧道应用于DSCP的更改。因此，如果PCN编码使用多个DSCP，则只有统一模型可用于PCN域内的隧道PCN流量。
If PCN-marking does not alter the original DSCP, the traffic leaves the PCN-domain with its original DSCP. However, if the PCN-marking alters the DSCP, then some additional technique is needed to restore the original DSCP. A few possibilities are discussed:
如果PCN标记未改变原始DSCP，则通信量将与其原始DSCP一起离开PCN域。但是，如果PCN标记改变了DSCP，则需要一些附加技术来恢复原始DSCP。讨论了几种可能性：
1. Each Diffserv class using PCN uses a different set of DSCPs. Therefore, if there are M DSCPs using PCN and PCN encoding uses N different DSCPs, N*M DSCPs are needed. This solution may work well in IP networks. However, when PCN is applied to MPLS networks or other layers restricted to 8 QoS classes and codepoints, this solution fails due to the extreme shortage of available DSCPs.
1. 使用PCN的每个Diffserv类都使用一组不同的DSCP。因此，如果有M个使用PCN的DSCP，并且PCN编码使用N个不同的DSCP，则需要N*M个DSCP。此解决方案可能在IP网络中运行良好。然而，当PCN应用于MPLS网络或限制为8个QoS等级和代码点的其他层时，由于可用DSCP的极度短缺，该解决方案失败。
2. The original DSCP for the packets of a flow is signaled to the egress node. No suitable signaling protocol has been developed and, therefore, it is not clear whether this approach could work.
2. 流的分组的原始DSCP通过信号发送给出口节点。尚未开发出合适的信令协议，因此，不清楚这种方法是否可行。
3. PCN-traffic is tunneled across the PCN-domain. The pipe-tunneling model is applied, so the original DSCP is restored after decapsulation. However, tunneling across a PCN-domain adds an additional IP header and reduces the maximum transfer unit (MTU) from the perspective of the user. GRE, MPLS, or Ethernet using pseudowires are potential solutions that scale well in backbone networks.
3. PCN流量通过隧道穿越PCN域。采用管道隧道模型，因此在脱封后恢复原始DSCP。然而，从用户的角度来看，通过PCN域的隧道增加了额外的IP报头并减少了最大传输单元（MTU）。使用伪线的GRE、MPLS或以太网是在骨干网络中扩展良好的潜在解决方案。
The most appropriate option depends on the specific circumstances an operator faces.
最合适的选项取决于操作员面临的特定情况。
o Option 1 is most suitable unless there is a shortage of available DSCPs.
o 选项1最合适，除非可用DSCP短缺。
o Option 3 is suitable where the reduction of MTU is not liable to cause issues.
o 方案3适用于MTU的减少不易引起问题的情况。
This section briefly reviews the structure and use of the ECN field. The ECN field may be redefined, but certain constraints apply [RFC4774]. The impact on PCN deployment is discussed, as well as the constraints imposed by various tunneling rules on the persistence of PCN-marks after decapsulation and its impact on possible re-marking actions.
本节简要回顾了ECN字段的结构和使用。可以重新定义ECN字段，但某些约束适用[RFC4774]。讨论了对PCN部署的影响，以及各种隧道规则对脱封后PCN标记持续性的限制及其对可能的重新标记操作的影响。
Some transport protocols, like TCP, can typically use packet drops as an indication of congestion in the Internet. The idea of Explicit Congestion Notification (ECN) [RFC3168] is that routers provide a congestion indication for incipient congestion, where the notification can sometimes be through ECN-marking (and re-marking) packets rather than dropping them. Figure 5 summarizes the ECN codepoints defined [RFC3168].
一些传输协议，如TCP，通常可以使用丢包作为Internet拥塞的指示。显式拥塞通知（ECN）[RFC3168]的思想是路由器为初始拥塞提供拥塞指示，其中通知有时可以通过ECN标记（和重新标记）数据包，而不是丢弃数据包。图5总结了定义的ECN代码点[RFC3168]。
+-----+-----+
| ECN FIELD |
+-----+-----+
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
+-----+-----+
| ECN FIELD |
+-----+-----+
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Figure 5: ECN Codepoints within the ECN Field
图5:ECN字段中的ECN代码点
ECT stands for "ECN-capable transport" and indicates that the senders and receivers of a flow understand ECN semantics. Packets of other flows are labeled with Not-ECT. To indicate congestion to a receiver, routers may re-mark ECT(1) or ECT(0) labeled packets to CE, which stands for "congestion experienced". Two different ECT codepoints were introduced "to protect against accidental or malicious concealment of marked packets from the TCP sender", which may be the case with cheating receivers [RFC3540].
ECT代表“支持ECN的传输”，表示流的发送方和接收方理解ECN语义。其他流的数据包标有Not ECT。为了向接收器指示拥塞，路由器可以将标有ECT（1）或ECT（0）的数据包重新标记到CE，这表示“经历拥塞”。引入了两个不同的ECT代码点，“以防止TCP发送方意外或恶意隐藏标记的数据包”，欺骗接收方可能就是这种情况[RFC3540]。
The ECN field may be redefined for other purposes and [RFC4774] gives guidelines for that. Essentially, Not-ECT-marked packets must never be re-marked to ECT or CE because Not-ECT-capable end systems do not reduce their transmission rate when receiving CE-marked packets. This is a threat to the stability of the Internet.
ECN字段可以为其他目的重新定义，[RFC4774]为此提供了指南。本质上，非ECT标记的数据包决不能重新标记为ECT或CE，因为非ECT功能的终端系统在接收CE标记的数据包时不会降低其传输速率。这是对互联网稳定的威胁。
Moreover, CE-marked packets must not be re-marked to Not-ECT or ECT, because then ECN-capable end systems cannot reduce their transmission rate. The reuse of the ECN field for PCN encoding has some impact on the deployment of PCN. First, routers within a PCN-domain must not apply ECN re-marking when the ECN field has PCN semantics. Second, before a PCN-packet leaves the PCN-domain, the egress nodes must either: (A) reset the ECN field of the packet to the content it had when entering the PCN-domain or (B) reset its ECN field to Not-ECT. According to Section 3.3.3, tunneling ECN traffic through a PCN-domain may help to implement (A). When (B) applies, CE-marked packets must never become PCN-packets within a PCN-domain, as the egress node resets their ECN field to Not-ECT. The ingress node may drop such traffic instead.
此外，CE标记的数据包不能被重新标记为not ECT或ECT，因为这样，支持ECN的终端系统就不能降低它们的传输速率。将ECN字段重新用于PCN编码对PCN的部署有一定的影响。首先，当ECN字段具有PCN语义时，PCN域内的路由器不得应用ECN重新标记。其次，在PCN数据包离开PCN域之前，出口节点必须：（a）将数据包的ECN字段重置为其在进入PCN域时拥有的内容，或者（B）将其ECN字段重置为Not ECT。根据第3.3.3节，通过PCN域隧道传输ECN流量可能有助于实现（a）。当（B）适用时，CE标记的数据包决不能成为PCN域内的PCN数据包，因为出口节点将其ECN字段重置为Not ECT。入口节点可以丢弃这样的通信量。
When packets are encapsulated, the ECN field of the inner header may or may not be copied to the ECN field of the outer header; upon decapsulation, the ECN field of the outer header may or may not be copied from the ECN field of the outer header to the ECN field of the inner header. Various tunneling rules with different treatment of the ECN field exist. Two different modes are defined in [RFC3168] for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec tunnels. [RFC6040] updates both of these RFCs to rationalize them into one consistent approach.
当包被封装时，内部报头的ECN字段可以复制到外部报头的ECN字段，也可以不复制到外部报头的ECN字段；在解除封装后，外部报头的ECN字段可以从外部报头的ECN字段复制到内部报头的ECN字段，也可以不复制。ECN场的不同处理存在着不同的隧穿规律。[RFC3168]中为IP隧道中的IP定义了两种不同的模式，[RFC4301]中为IPsec隧道中的IP定义了第三种模式。[RFC6040]更新这两个RFC，使其合理化为一个一致的方法。
The limited-functionality option has been defined in [RFC3168]. Upon encapsulation, the ECN field of the outer header is generally set to Not-ECT. Upon decapsulation, the ECN field of the inner header remains unchanged.
有限功能选项已在[RFC3168]中定义。封装后，外部标头的ECN字段通常设置为Not ECT。解除封装后，内部收割台的ECN字段保持不变。
Since this tunneling mode loses information upon encapsulation and decapsulation, it cannot be used for tunneling PCN-traffic within a PCN-domain. However, the PCN ingress may use this mode to tunnel traffic with ECN semantics to the PCN egress to preserve the ECN field in the inner header while the ECN field of the outer header is used with PCN semantics within the PCN-domain.
由于此隧道模式在封装和解除封装时会丢失信息，因此不能用于在PCN域内对PCN流量进行隧道传输。然而，PCN入口可使用此模式将具有ECN语义的流量隧道至PCN出口，以在内部报头中保留ECN字段，而外部报头的ECN字段在PCN域中与PCN语义一起使用。
The full-functionality option has been defined in [RFC3168]. Upon encapsulation, the ECN field of the inner header is copied to the outer header unless the ECN field of the inner header carries CE. In that case, the ECN field of the outer header is set to ECT(0). This choice has been made for security reasons, to disable the ECN fields of the outer header as a covert channel. Upon decapsulation, the ECN field of the inner header remains unchanged unless the ECN field of the outer header carries CE. In that case, the ECN field of the inner header is also set to CE.
完整功能选项已在[RFC3168]中定义。封装后，内部标头的ECN字段复制到外部标头，除非内部标头的ECN字段带有CE。在这种情况下，外部标头的ECN字段设置为ECT（0）。出于安全原因，已做出此选择，以禁用外部标头的ECN字段作为隐蔽通道。解除封装后，内部收割台的ECN字段保持不变，除非外部收割台的ECN字段带有CE。在这种情况下，内部报头的ECN字段也设置为CE。
This mode imposes the following constraints on PCN-metering and PCN-marking. First, PCN must re-mark the ECN field only to CE, because any other information is not copied to the inner header upon decapsulation and will be lost. Second, CE information in encapsulated packet headers is invisible for routers along a tunnel. Threshold-marking does not require information about whether PCN-packets have already been marked and would work when CE denotes that packets are marked. In contrast, excess-traffic-marking requires information about already excess-traffic-marked packets and cannot be supported with this tunneling mode. Furthermore, this tunneling mode cannot be used when marked or not-marked packets should be preferentially dropped, because the PCN-marking information is possibly not visible in the outer header of a packet.
此模式对PCN计量和PCN标记施加以下约束。首先，PCN必须仅将ECN字段重新标记为CE，因为任何其他信息在解除封装后都不会复制到内部标头，并且将丢失。其次，封装的包头中的CE信息对于隧道沿线的路由器是不可见的。阈值标记不需要关于PCN数据包是否已经标记的信息，并且当CE表示数据包已标记时，阈值标记将起作用。相反，过量流量标记需要有关已过量流量标记的数据包的信息，此隧道模式不支持。此外，当应优先丢弃标记或未标记的分组时，不能使用该隧道模式，因为PCN标记信息可能在分组的外部报头中不可见。
Tunneling has been defined in Section 5.1.2.1 of [RFC4301]. Upon encapsulation, the ECN field of the inner header is copied to the ECN field of the outer header. Decapsulation works as for the full-functionality option described in Section 3.3.3.2. Tunneling with IPsec also requires that PCN re-mark the ECN field only to CE because any other information is not copied to the inner header upon decapsulation and is lost. In contrast to Section 3.3.3.2, with IPsec tunnels, CE marks of tunneled PCN-traffic remain visible for routers along the tunnel and to their meters, markers, and droppers.
隧洞工程已在[RFC4301]第5.1.2.1节中定义。封装后，将内部标头的ECN字段复制到外部标头的ECN字段。脱封与第3.3.3.2节所述的完整功能选项相同。使用IPsec进行隧道传输还要求PCN仅向CE重新标记ECN字段，因为任何其他信息在解除封装后都不会复制到内部标头，并且会丢失。与第3.3.3.2节不同，对于IPsec隧道，隧道PCN流量的CE标记对于隧道沿线的路由器及其仪表、标记和滴管仍然可见。
New tunneling rules for ECN are specified in [RFC6040], which updates [RFC3168] and [RFC4301]. These rules provide a consistent and rational approach to encapsulation and decapsulation.
[RFC6040]中规定了ECN的新隧道规则，更新了[RFC3168]和[RFC4301]。这些规则为封装和去封装提供了一致和合理的方法。
With the normal mode, the ECN field of the inner header is copied to the ECN field of the outer header on encapsulation. In compatibility mode, the ECN field of the outer header is reset to Not-ECT.
在正常模式下，封装时将内部标头的ECN字段复制到外部标头的ECN字段。在兼容模式下，外部标头的ECN字段重置为Not ECT。
Upon decapsulation, the scheme specified in [RFC6040] and shown in Figure 6 is applied. Thus, re-marking encapsulated Not-ECT packets to any other codepoint would not survive decapsulation. Therefore, Not-ECT cannot be used for PCN encoding. Furthermore, re-marking encapsulated ECT(0) packets to ECT(1) or CE survives decapsulation, but not vice-versa, and re-marking encapsulated ECT(1) packets to CE also survives decapsulation, but not vice-versa. Certain combinations of inner and outer ECN fields cannot result from any transition in any current or previous ECN tunneling specification. These currently unused (CU) combinations are indicated in Figure 6 by '(!!!)' or '(!)'; where '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous.
脱封后，采用[RFC6040]中规定的方案，如图6所示。因此，将封装的Not ECT数据包重新标记到任何其他代码点将无法在解除封装后存活。因此，Not ECT不能用于PCN编码。此外，将封装的ECT（0）数据包重新标记到ECT（1）或CE可以在去封装后存活，但反之亦然；将封装的ECT（1）数据包重新标记到CE也可以在去封装后存活，但反之亦然。内部和外部ECN字段的某些组合不能由任何当前或以前的ECN隧道规范中的任何转换产生。这些当前未使用的（CU）组合在图6中用“（！！！）”或“（！）”表示；其中，“（！！！）”表示组合为CU且始终具有潜在危险，而“（！”）表示组合为CU且可能存在危险。
+---------+------------------------------------------------+
|Arriving | Arriving Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
| Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
| ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE |
| CE | CE | CE | CE(!!!)| CE |
+---------+---------+------------+------------+------------+
+---------+------------------------------------------------+
|Arriving | Arriving Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
| Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
| ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE |
| CE | CE | CE | CE(!!!)| CE |
+---------+---------+------------+------------+------------+
The ECN field in the outgoing header is set to the codepoint at the intersection of the appropriate arriving inner header (row) and arriving outer header (column), or the packet is dropped where indicated. Currently unused combinations are indicated by '(!!!)' or '(!)'. ([RFC6040]; '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous.)
传出报头中的ECN字段设置为相应到达的内部报头（行）和到达的外部报头（列）交叉处的代码点，或者在指示的位置丢弃数据包。当前未使用的组合由“（！！！）”或“（！）”表示。（[RFC6040]；“（！！！）”表示组合为CU且始终具有潜在危险，而“（！”表示组合为CU且可能存在危险。）
Figure 6: New IP in IP Decapsulation Behavior (from [RFC6040])
图6:IP中的新IP去封装行为（来自[RFC6040]）
As ECN is an end-to-end service, it is desirable that the egress node of a PCN-domain restore the ECN field that a PCN-packet had at the ingress node. There are basically two options. PCN-traffic may be tunneled between ingress and egress node using limited functionality tunnels (see Section 3.3.3.1). Then, PCN-marking is applied only to the outer header, and the original ECN field is restored after decapsulation. However, this reduces the MTU from the perspective of the user. Another option is to use some intelligent encoding that preserves the ECN codepoints. However, a viable solution is not known.
由于ECN是端到端服务，因此期望PCN域的出口节点恢复PCN分组在入口节点处具有的ECN字段。基本上有两种选择。PCN流量可使用有限功能隧道在入口和出口节点之间进行隧道传输（见第3.3.3.1节）。然后，PCN标记仅应用于外部标题，并且在解除封装后恢复原始ECN字段。然而，这从用户的角度减少了MTU。另一种选择是使用一些保留ECN代码点的智能编码。然而，一个可行的解决方案尚不清楚。
The PCN working group has studied four different PCN encodings, which redefine the ECN field. Figure 7 summarizes these PCN encodings. One, or at most two, different DSCPs are used to indicate PCN-traffic, and, only for these DSCPs, the semantics of the ECN field are redefined within the PCN-domain.
PCN工作组研究了四种不同的PCN编码，它们重新定义了ECN字段。图7总结了这些PCN编码。一个或最多两个不同的DSCP用于指示PCN流量，并且仅对于这些DSCP，ECN字段的语义在PCN域中重新定义。
When a PCN-ingress-node classifies a packet as a PCN-packet, it sets its PCN-codepoint to not-marked (NM). Non-PCN-traffic can also use the PCN-specific DSCP by setting the Not-PCN codepoint. Special per-hop behavior, defined in [RFC5670], applies to PCN-traffic.
当PCN入口节点将数据包分类为PCN数据包时，它将其PCN代码点设置为未标记（NM）。通过设置非PCN代码点，非PCN通信也可以使用PCN特定的DSCP。[RFC5670]中定义的特殊每跳行为适用于PCN流量。
-----------------------------------------------------------------------
| ECN Bits || 00 | 10 | 01 | 11 || DSCP |
|==============++==========+==========+==========+==========++=========|
| RFC 3168 || Not-ECT | ECT(0) | ECT(1) | CE || Any |
|==============++==========+==========+==========+==========++=========|
| Baseline || Not-PCN | NM | EXP | PM || PCN-n |
|==============++==========+==========+==========+==========++=========|
| 3-In-1 || Not-PCN | NM | ThM | ETM || PCN-n |
|==============++==========+==========+==========+==========++=========|
| 3-In-2 || Not-PCN | NM | CU | ThM || PCN-n |
| ||----------+----------+----------+----------++---------|
| || Not-PCN | CU | CU | ETM || PCN-m |
|==============++==========+==========+==========+==========++=========|
| PSDM || Not-PCN | Not-ETM | Not-ThM | PM || PCN-n |
-----------------------------------------------------------------------
-----------------------------------------------------------------------
| ECN Bits || 00 | 10 | 01 | 11 || DSCP |
|==============++==========+==========+==========+==========++=========|
| RFC 3168 || Not-ECT | ECT(0) | ECT(1) | CE || Any |
|==============++==========+==========+==========+==========++=========|
| Baseline || Not-PCN | NM | EXP | PM || PCN-n |
|==============++==========+==========+==========+==========++=========|
| 3-In-1 || Not-PCN | NM | ThM | ETM || PCN-n |
|==============++==========+==========+==========+==========++=========|
| 3-In-2 || Not-PCN | NM | CU | ThM || PCN-n |
| ||----------+----------+----------+----------++---------|
| || Not-PCN | CU | CU | ETM || PCN-m |
|==============++==========+==========+==========+==========++=========|
| PSDM || Not-PCN | Not-ETM | Not-ThM | PM || PCN-n |
-----------------------------------------------------------------------
Notes: PCN-n, PCN-m under the DSCP column denotes PCN-compatible DSCPs, which may be chosen by the network operator. Not-PCN means that packets are not PCN-enabled. NM means not-marked. CU means currently unused.
注：DSCP列下的PCN-n、PCN-m表示与PCN兼容的DSCP，可由网络运营商选择。Not PCN表示数据包未启用PCN。NM表示未标记。CU表示当前未使用。
Figure 7: Semantics of the ECN Field for Various Encoding Types
图7：各种编码类型的ECN字段的语义
With baseline encoding [RFC5696], the NM codepoint can be re-marked only to PCN-marked (PM). Excess-traffic-marking uses PM as ETM, threshold-marking uses PM as ThM, and only one of the two marking schemes can be used. So, baseline encoding supports SM-PCN.
使用基线编码[RFC5696]，NM代码点只能重新标记为PCN标记（PM）。过量交通标记使用PM作为ETM，阈值标记使用PM作为ThM，并且只能使用两种标记方案中的一种。因此，基线编码支持SM-PCN。
The 01-codepoint is reserved for experimental purposes (EXP) and the other defined PCN encoding schemes can be seen as extensions of baseline encoding by appropriate redefinition of EXP. Baseline encoding [RFC5696] works well with IPsec tunnels (see Section 3.3.3.3).
01码点保留用于实验目的（EXP），其他定义的PCN编码方案可通过适当的EXP重新定义被视为基线编码的扩展。基线编码[RFC5696]可与IPsec隧道配合使用（见第3.3.3.3节）。
PCN 3-state encoding uses a single DSCP (3-in-1 encoding, [RFC6660]), extends the baseline encoding, and supports the simultaneous use of both excess-traffic-marking and threshold-marking. 3-in-1 encoding well supports the preferred CL-PCN and also SM-PCN.
PCN三状态编码使用单个DSCP（三合一编码[RFC6660]），扩展了基线编码，并支持同时使用过量流量标记和阈值标记。三合一编码很好地支持首选的CL-PCN和SM-PCN。
The problem with 3-in-1 encoding is that the 10-codepoint does not survive decapsulation with the tunneling options in Sections 3.3.3.1 - 3.3.3.3.
三合一编码的问题在于，10码点无法通过第3.3.3.1节-第3.3.3.3节中的隧道选项进行去封装。
Therefore, the full 3-in-1 encoding may only be used for PCN-domains implementing the new rules for ECN tunnelling [RFC6040] or for PCN-domains without tunnels. Currently, it is not clear how fast the new tunnelling rules will be deployed and this affects the applicability of the full 3-in-1 encoding. Where PCN-domains do contain legacy tunnel endpoints, a restricted subset of the full 3-in-1 encoding can be used that omits the '01' codepoint.
因此，完整的三合一编码只能用于实现ECN隧道新规则的PCN域[RFC6040]或不带隧道的PCN域。目前，尚不清楚新隧道规则的部署速度，这会影响完整的三合一编码的适用性。如果PCN域确实包含传统的隧道端点，则可以使用完整3合1编码的受限子集，该子集可以省略“01”码点。
PCN encoding using 2 DSCPs to provide 3 or more states (3-in-2 encoding, [PCN-3-in-2]) uses two different DSCPs to accommodate the three required codepoints NM, ThM, and ETM. It leaves some codepoints currently unused (CU), and also proposes a way to reuse them to store some information about the content of the ECN field before the packet enters the PCN-domain. 3-in-2 encoding works well with IPsec tunnels (see Section 3.3.3.3). This type of encoding can support both CL-PCN and SM-PCN schemes.
PCN编码使用2个DSCP提供3个或更多状态（3-in-2编码，[PCN-3-in-2]）使用两个不同的DSCP来容纳三个所需的码点NM、ThM和ETM。它保留了一些当前未使用的代码点（CU），并提出了一种在数据包进入PCN域之前重用这些代码点以存储有关ECN字段内容的一些信息的方法。三合二编码可以很好地用于IPsec隧道（参见第3.3.3.3节）。这种类型的编码可以支持CL-PCN和SM-PCN方案。
The disadvantage of 3-in-2 encoding is that it consumes two DSCPs. Further, if PCN is applied to more than one Diffserv traffic class, then two DSCPs are needed for each. Moreover, the direct application of this encoding scheme to other technologies like MPLS, where even fewer bits are available for the encoding of DSCPs, is more difficult.
三合二编码的缺点是它消耗两个DSCP。此外，如果PCN应用于多个Diffserv流量类别，则每个类别需要两个DSCP。此外，将此编码方案直接应用于其他技术（如MPLS）更为困难，因为MPLS中用于DSCP编码的比特更少。
PCN encoding for packet-specific dual marking (PSDM) is designed to support PSDM-PCN outlined in Section 2.2.3. It is the only proposal that supports PCN-based AC and FT with only a single DSCP [PCN-PSDM] in the presence of IPsec tunnels (see Section 3.3.3.3). PSDM encoding also supports SM-PCN.
包特定双重标记（PSDM）的PCN编码设计用于支持第2.2.3节中概述的PSDM-PCN。这是在存在IPsec隧道的情况下，支持基于PCN的AC和FT的唯一方案，仅支持单个DSCP[PCN-PSDM]（见第3.3.3.3节）。PSDM编码也支持SM-PCN。
The baseline encoding described in Section 4.1 is defined in
[RFC5696]. The intention was to allow for experimental encodings to
build upon this baseline. However, following the publication of
[RFC6040], the working group decided to change its approach and
instead standardize only one encoding (the 3-in-1 encoding [RFC6660]
described in Section 4.2). Rather than defining the 3-in-1 encoding
as a Standards Track extension to the existing baseline encoding
[RFC5696], it was agreed that it is best to define a new Standards
Track document that obsoletes [RFC5696].
The baseline encoding described in Section 4.1 is defined in
[RFC5696]. The intention was to allow for experimental encodings to
build upon this baseline. However, following the publication of
[RFC6040], the working group decided to change its approach and
instead standardize only one encoding (the 3-in-1 encoding [RFC6660]
described in Section 4.2). Rather than defining the 3-in-1 encoding
as a Standards Track extension to the existing baseline encoding
[RFC5696], it was agreed that it is best to define a new Standards
Track document that obsoletes [RFC5696].
This document summarizes the PCN working group's exploration of a number of approaches for encoding pre-congestion information into the IP header. It is presented as an informational archive. It provides details of those approaches along with an explanation of the constraints that apply. The working group has concluded that the "3-in-1" encoding should be published as a Standards Track RFC that obsoletes the encoding specified in [RFC5696].
本文件总结了PCN工作组对将拥塞前信息编码到IP报头中的多种方法的探索。它以信息档案的形式呈现。它提供了这些方法的详细信息，并解释了适用的约束条件。工作组得出结论，“三合一”编码应作为标准轨道RFC发布，以淘汰[RFC5696]中规定的编码。
The reasoning is as follows. During the early life of the working group, the working group decided on an approach of a standardized "baseline" encoding [RFC5696], plus a series of experimental encodings that would all build on the baseline encoding, each of which would be useful in specific circumstances. However, after the tunneling of ECN was standardized in [RFC6040], the PCN working group decided on a different approach -- to recommend just one encoding, the "3-in-1 encoding".
理由如下。在工作组成立初期，工作组决定采用一种标准化的“基线”编码方法[RFC5696]，再加上一系列以基线编码为基础的实验编码，每种编码在特定情况下都很有用。然而，在[RFC6040]中对ECN的隧道进行了标准化之后，PCN工作组决定采用一种不同的方法——只推荐一种编码，即“三合一编码”。
Although in theory "3-in-1" could be specified as a Standards Track extension to the "baseline" encoding, the working group decided that it would be cleaner to obsolete [RFC5696] and specify "3-in-1" encoding in a new, stand-alone RFC.
虽然理论上可以将“三合一”指定为“基线”编码的标准轨道扩展，但工作组决定，淘汰[RFC5696]并在新的、独立的RFC中指定“三合一”编码更为简洁。
[RFC5559] provides a general description of the security considerations for PCN. This memo does not introduce additional security considerations.
[RFC5559]提供了PCN安全注意事项的一般说明。本备忘录未介绍其他安全注意事项。
We would like to acknowledge the members of the PCN working group and Gorry Fairhust for the discussions that generated and improved the contents of this memo.
我们要感谢PCN工作组成员和Gorry Fairhust的讨论，这些讨论产生并改进了本备忘录的内容。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[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月。
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, November 2006.
[RFC4774]Floyd，S.，“为显式拥塞通知（ECN）字段指定替代语义”，BCP 124，RFC 4774，2006年11月。
[PCN-MS-AC] Menth, M. and R. Geib, "Admission Control Using PCN-Marked Signaling", Work in Progress, February 2011.
[PCN-MS-AC]Minth，M.和R.Geib，“使用PCN标记信号的准入控制”，正在进行的工作，2011年2月。
[PCN-3-in-2] Briscoe, B., Moncaster, T., and M. Menth, "A PCN Encoding Using 2 DSCPs to Provide 3 or More States", Work in Progress, March 2012.
[PCN-3-in-2]Briscoe，B.，Moncaster，T.，和M.Meth，“使用2个DSCP提供3个或更多状态的PCN编码”，正在进行的工作，2012年3月。
[PCN-PSDM] Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, "PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding)", Work in Progress, March 2012.
[PCN-PSDM]Minth，M.，Babiarz，J.，Moncaster，T.，和B.Briscoe，“包特定双重标记的PCN编码（PSDM编码）”，正在进行的工作，2012年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559]Eardley，P.，Ed.“拥塞前通知（PCN）体系结构”，RFC55559，2009年6月。
[RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670]Eardley，P.，Ed.“PCN节点的计量和标记行为”，RFC 56702009年11月。
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009.
[RFC5696]Moncaster，T.，Briscoe，B.，和M.Minth，“拥堵前信息的基线编码和传输”，RFC 56962009年11月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.
[RFC6040]Briscoe，B.，“明确拥塞通知的隧道挖掘”，RFC 60402010年11月。
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, July 2012.
[RFC6660]Briscoe，B.，Moncaster，T.，和M.Menth，“使用单个Diffserv码点（DSCP）在IP报头中编码三种拥塞前通知（PCN）状态”，RFC 66602012年7月。
[RFC6661] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation", RFC 6661, July 2012.
[RFC6661]Charny，A.，Huang，F.，Karagiannis，G.，Minth，M.，和T.Taylor，Ed.，“受控负载（CL）运行模式下的拥塞前通知（PCN）边界节点行为”，RFC 66612012年7月。
[RFC6662] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. Taylor, "Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation", RFC 6662, July 2012.
[RFC6662]Charny，A.，Zhang，J.，Karagiannis，G.，Minth，M.，和T.Taylor，“单一标记（SM）运行模式下的拥塞前通知（PCN）边界节点行为”，RFC 66622012年7月。
[Menth09] Menth, M., Babiarz, J., and P. Eardley, "Pre-Congestion Notification Using Packet-Specific Dual Marking", IEEE Proceedings of the International Workshop on the Network of the Future (Future-Net), Dresden/Germany, June 2009.
[Menth09]Minth，M.，Babiarz，J.，和P.Eardley，“使用数据包特定双重标记的拥塞前通知”，IEEE未来网络国际研讨会论文集（未来网络），德国德累斯顿，2009年6月。
[Menth12] Menth, M. and F. Lehrieder, "Performance of PCN-Based Admission Control under Challenging Conditions", IEEE/ACM Transactions on Networking, vol. 20, no. 2, April 2012.
[Menth12]Minth，M.和F.Lehrieder，“挑战性条件下基于PCN的准入控制的性能”，IEEE/ACM网络交易，第20卷，第2期，2012年4月。
[Menth10] Menth, M. and F. Lehrieder, "PCN-Based Measured Rate Termination", Computer Networks Journal, vol. 54, no. 3, Sept. 2010
[Menth10]Minth，M.和F.Lehrieder，“基于PCN的测量速率终止”，《计算机网络杂志》，第54卷，第3期，2010年9月
Authors' Addresses
作者地址
Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands EMail: g.karagiannis@utwente.nl
乔治斯卡拉基安尼斯屯特大学邮政信箱217 7500 AE恩斯赫德，荷兰电子邮件：G。karagiannis@utwente.nl
Kwok Ho Chan Consultant EMail: khchan.work@gmail.com
郭浩灿顾问电邮：khchan。work@gmail.com
Toby Moncaster University of Cambridge Computer Laboratory William Gates Building, J J Thomson Avenue Cambridge, CB3 0FD United Kingdom EMail: Toby.Moncaster@cl.cam.ac.uk
托比蒙卡斯特剑桥大学计算机实验室威廉盖茨大楼，J J汤姆逊大道剑桥，CB3 0FD英国电子邮件：托比。Moncaster@cl.cam.ac.uk
Michael Menth University of Tuebingen Sand 13 72076 Tuebingen Germany
米迦勒蒙特大学图宾根沙特13德国72076
Phone: +49-7071-2970505
EMail: menth@uni-tuebingen.de
Phone: +49-7071-2970505
EMail: menth@uni-tuebingen.de
Philip Eardley BT B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom EMail: philip.eardley@bt.com
Philip Eardley BT B54/77，天狼星之家阿达斯特拉尔公园，萨福克郡马特勒沙姆希思伊普斯维奇IP5 3RE英国电子邮件：Philip。eardley@bt.com
Bob Briscoe BT B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom EMail: bob.briscoe@bt.com
Bob Briscoe BT B54/77，天狼星之家Adastral Park Martlesham Heath Ipswich，萨福克IP5 3RE英国电子邮件：Bob。briscoe@bt.com