Internet Engineering Task Force (IETF) B. Briscoe
Request for Comments: 6660 BT
Obsoletes: 5696 T. Moncaster
Category: Standards Track University of Cambridge
ISSN: 2070-1721 M. Menth
University of Tuebingen
July 2012
Internet Engineering Task Force (IETF) B. Briscoe
Request for Comments: 6660 BT
Obsoletes: 5696 T. Moncaster
Category: Standards Track University of Cambridge
ISSN: 2070-1721 M. Menth
University of Tuebingen
July 2012
Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)
使用单个Diffserv代码点（DSCP）在IP报头中编码三种拥塞前通知（PCN）状态
Abstract
摘要
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion.
预拥塞通知（PCN）的目的是保护区分服务域内非弹性流的服务质量（QoS）。在PCN域中的每个链路上测量PCN流量的总速率，当超过某些配置速率时，会适当标记PCN数据包。出口节点将有关这些PCN标记的信息传递给决策点，然后决策点决定在严重的预拥塞期间是接纳还是阻止新的流请求，还是终止一些已经接纳的流。
This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix. The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC 5696.
本文档规定了如何通过重用PCN域内的显式拥塞通知（ECN）代码点将PCN标记编码到IP报头中。非IP协议头的PCN wire协议需要在其他地方定义。尽管如此，本文件在信息性附录中澄清了MPLS的PCN编码。IP编码使用单个Diffserv代码点（DSCP）提供最多三种不同的PCN标记状态：未标记（NM）、阈值标记（ThM）和标记的过量流量（ETM）。因此，它被称为三合一PCN编码。本文件废除RFC 5696。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6660.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6660.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 5
3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 6
4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 7
4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 7
4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 7
4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 8
5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. PCN-Ingress-Node Behaviour . . . . . . . . . . . . . . . . 8
5.2. PCN-Interior-Node Behaviour . . . . . . . . . . . . . . . 11
5.2.1. Behaviour Common to All PCN-Interior-Nodes . . . . . . 11
5.2.2. Behaviour of PCN-Interior-Nodes Using Two
PCN-Markings . . . . . . . . . . . . . . . . . . . . . 11
5.2.3. Behaviour of PCN-Interior-Nodes Using One
PCN-Marking . . . . . . . . . . . . . . . . . . . . . 12
5.3. PCN-Egress-Node Behaviour . . . . . . . . . . . . . . . . 13
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13
6.2. Backward Compatibility with the Encoding in RFC 5696 . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 18
Appendix B. Coexistence of ECN and PCN . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 5
3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 6
4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 7
4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 7
4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 7
4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 8
5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. PCN-Ingress-Node Behaviour . . . . . . . . . . . . . . . . 8
5.2. PCN-Interior-Node Behaviour . . . . . . . . . . . . . . . 11
5.2.1. Behaviour Common to All PCN-Interior-Nodes . . . . . . 11
5.2.2. Behaviour of PCN-Interior-Nodes Using Two
PCN-Markings . . . . . . . . . . . . . . . . . . . . . 11
5.2.3. Behaviour of PCN-Interior-Nodes Using One
PCN-Marking . . . . . . . . . . . . . . . . . . . . . 12
5.3. PCN-Egress-Node Behaviour . . . . . . . . . . . . . . . . 13
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13
6.2. Backward Compatibility with the Encoding in RFC 5696 . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 18
Appendix B. Coexistence of ECN and PCN . . . . . . . . . . . . . 19
Appendix C. Example Mapping between Encoding of PCN-Marks in
IP and in MPLS Shim Headers . . . . . . . . . . . . . 22
Appendix D. Rationale for Difference between the Schemes
Using One PCN-Marking . . . . . . . . . . . . . . . . 23
Appendix C. Example Mapping between Encoding of PCN-Marks in
IP and in MPLS Shim Headers . . . . . . . . . . . . . 22
Appendix D. Rationale for Difference between the Schemes
Using One PCN-Marking . . . . . . . . . . . . . . . . 23
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, to decide whether to admit or block a new flow request, and flow termination 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 providing notification to boundary nodes about overloads before any real congestion occurs (hence "pre-congestion notification").
预拥塞通知（PCN）[RFC5559]的目标是以简单、可扩展和健壮的方式保护区分服务域内非弹性流的服务质量（QoS）。使用两种机制：接纳控制，用于决定是否接纳或阻止新的流请求；流终止，用于在严重预拥塞期间终止一些现有流。为了实现这一点，在域中的每个链路上测量PCN流量的总速率，并且当超过某些配置速率时，适当地标记PCN数据包。这些配置的速率低于链路速率，因此在任何实际拥塞发生之前向边界节点提供有关过载的通知（因此称为“拥塞前通知”）。
[RFC5670] provides for two metering and marking functions that are generally configured with different 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). The PCN-excess-rate is typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes monitor the PCN-marks of received PCN-packets and pass information about these PCN-marks to Decision Points that then decide whether to admit new flows or terminate existing flows [RFC6661] [RFC6662].
[RFC5670]提供两种计量和标记功能，这些功能通常配置为不同的参考速率。当链路上的通信速率超过配置的参考速率（PCN阈值速率）时，阈值标记将标记所有PCN数据包。过量流量标记仅标记超过配置的参考速率（PCN过量速率）的PCN数据包。PCN超额率通常大于PCN阈值率[RFC5559]。出口节点监视接收到的PCN包的PCN标记，并将有关这些PCN标记的信息传递给决策点，然后决策点决定是接纳新流还是终止现有流[RFC6661][RFC6662]。
The encoding defined in [RFC5696] described how two PCN marking states (not-marked and PCN-marked) could be encoded into the IP header using a single Diffserv codepoint. It defined '01' as an experimental codepoint (EXP), along with guidelines for its use. Two PCN marking states are sufficient for the Single Marking edge behaviour [RFC6662]. However, PCN-domains utilising the controlled load edge behaviour [RFC6661] require three PCN marking states. This document extends the encoding that originally appeared in RFC 5696 by redefining the experimental codepoint as a third PCN marking state in the IP header, but still using a single Diffserv codepoint. This encoding scheme is therefore called the "3-in-1 PCN encoding". It obsoletes the [RFC5696] encoding, which provides only a subset of the same capabilities.
[RFC5696]中定义的编码描述了如何使用单个Diffserv码点将两个PCN标记状态（未标记和PCN标记）编码到IP报头中。它将“01”定义为实验性代码点（EXP），并给出了使用指南。两种PCN标记状态足以满足单标记边缘行为[RFC6662]。但是，使用受控负载边缘行为[RFC6661]的PCN域需要三种PCN标记状态。本文档扩展了最初出现在RFC 5696中的编码，将实验代码点重新定义为IP报头中的第三个PCN标记状态，但仍然使用单个Diffserv代码点。因此，这种编码方案被称为“三合一PCN编码”。它淘汰了[RFC5696]编码，该编码只提供相同功能的一个子集。
The full version of the 3-in-1 encoding requires any tunnel endpoint within the PCN-domain to support the normal tunnelling rules defined in [RFC6040]. There is one limited exception to this constraint
3合1编码的完整版本要求PCN域内的任何隧道端点支持[RFC6040]中定义的正常隧道规则。此约束有一个有限的例外
where the PCN-domain only uses the excess-traffic-marking behaviour and where the threshold-marking behaviour is deactivated. This is discussed in Section 5.2.3.1.
其中，PCN域仅使用过量流量标记行为，并且阈值标记行为被停用。第5.2.3.1节对此进行了讨论。
This document only concerns the PCN wire protocol encoding for IP headers, whether IPv4 or IPv6. It makes no changes or recommendations concerning algorithms for congestion marking or congestion response. Other documents will define the PCN wire protocol for other header types. Appendix C discusses a possible mapping between IP and MPLS.
本文档仅涉及IP头的PCN有线协议编码，无论是IPv4还是IPv6。它不会对拥塞标记或拥塞响应的算法做出任何更改或建议。其他文件将为其他标题类型定义PCN wire协议。附录C讨论了IP和MPLS之间可能的映射。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node, PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets, and PCN-marking are used as defined in [RFC5559]. The following additional terms are defined in this document:
术语PCN域、PCN节点、PCN内部节点、PCN入口节点、PCN出口节点、PCN边界节点、PCN流量、PCN数据包和PCN标记的使用如[RFC5559]中所定义。本文件中定义了以下附加术语：
PCN encoding: mapping of PCN marking states to specific codepoints in the packet header.
PCN编码：将PCN标记状态映射到数据包头中的特定代码点。
PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating packets for which the ECN field carries PCN-markings rather than [RFC3168] markings. Note that an operator configures PCN-nodes to recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN-specific meaning to a node outside the PCN-domain.
PCN兼容区分服务代码点：一个区分服务代码点，指示ECN字段带有PCN标记而非[RFC3168]标记的数据包。请注意，运营商将PCN节点配置为识别与PCN兼容的DSCP，而同一DSCP对PCN域外的节点没有PCN特定的含义。
Threshold-marked codepoint: a codepoint that indicates a packet has been threshold-marked; that is, a packet that has been marked at a PCN-interior-node as a result of an indication from the threshold-metering function [RFC5670]. Abbreviated to ThM codepoint.
阈值标记的代码点：表示数据包已被阈值标记的代码点；也就是说，由于来自阈值计量功能[RFC5670]的指示而在PCN内部节点处标记的分组。缩写为ThM码点。
Excess-traffic-marked codepoint: a codepoint that indicates packets that have been marked at a PCN-interior-node as a result of an indication from the excess-traffic-metering function [RFC5670]. Abbreviated to ETM codepoint.
标记过多流量的代码点：一种代码点，表示由于来自过多流量计量功能的指示而在PCN内部节点上标记的数据包[RFC5670]。缩写为ETM代码点。
Not-marked codepoint: a codepoint that indicates PCN-packets that are not PCN-marked. Abbreviated to NM codepoint.
未标记代码点：表示未标记PCN的PCN数据包的代码点。缩写为NM码点。
Not-PCN codepoint: a codepoint that indicates packets that are not PCN-packets.
非PCN代码点：表示非PCN数据包的数据包的代码点。
The following abbreviations are used in this document:
本文件中使用了以下缩写：
o AF = Assured Forwarding [RFC2597]
o AF=保证转发[RFC2597]
o CE = Congestion Experienced [RFC3168]
o CE=经历的拥塞[RFC3168]
o CS = Class Selector [RFC2474]
o CS=类选择器[RFC2474]
o DSCP = Diffserv codepoint
o DSCP=区分服务代码点
o e2e = end-to-end
o e2e=端到端
o ECN = Explicit Congestion Notification [RFC3168]
o ECN=显式拥塞通知[RFC3168]
o ECT = ECN Capable Transport [RFC3168]
o ECT=支持ECN的传输[RFC3168]
o EF = Expedited Forwarding [RFC3246]
o EF=快速转发[RFC3246]
o ETM = excess-traffic-marked
o ETM=标记的超额流量
o EXP = Experimental
o EXP=实验性
o NM = not-marked
o NM=未标记
o PCN = Pre-Congestion Notification
o PCN=拥塞前通知
o PHB = Per-hop behaviour [RFC2474]
o PHB=每跳行为[RFC2474]
o ThM = threshold-marked
o ThM=标记的阈值
The 3-in-1 PCN encoding scheme supports networks that need three PCN-marking states to be encoded within the IP header, as well as those that need only two. The full encoding is shown in Figure 1.
三合一PCN编码方案支持需要在IP报头中编码三个PCN标记状态的网络，以及只需要两个PCN标记状态的网络。完整编码如图1所示。
+--------+----------------------------------------------------+
| | Codepoint in ECN field of IP header |
| DSCP | <RFC3168 codepoint name> |
| +--------------+-------------+-------------+---------+
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+
| DSCP n | not-PCN | NM | ThM | ETM |
+--------+--------------+-------------+-------------+---------+
+--------+----------------------------------------------------+
| | Codepoint in ECN field of IP header |
| DSCP | <RFC3168 codepoint name> |
| +--------------+-------------+-------------+---------+
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+
| DSCP n | not-PCN | NM | ThM | ETM |
+--------+--------------+-------------+-------------+---------+
Figure 1: 3-in-1 PCN Encoding
图1：三合一PCN编码
A PCN-node will be configured to recognise certain DSCPs as PCN-compatible. Appendix A discusses the choice of suitable DSCPs. In Figure 1, 'DSCP n' indicates such a PCN-compatible DSCP. In the PCN-domain, any packet carrying a PCN-compatible DSCP and with the ECN-field anything other than 00 (not-PCN) is a PCN-packet as defined in [RFC5559].
PCN节点将配置为将某些DSCP识别为与PCN兼容。附录A讨论了合适DSCP的选择。在图1中，“DSCP n”表示这样一个与PCN兼容的DSCP。在PCN域中，任何携带PCN兼容DSCP且ECN字段不是00（非PCN）的数据包都是[RFC5559]中定义的PCN数据包。
PCN-nodes MUST interpret the ECN field of a PCN-packet using the 3-in-1 PCN encoding, rather than [RFC3168]. This does not change the behaviour for any packet with a DSCP that is not PCN-compatible, or for any node outside a PCN-domain. In all such cases, the 3-in-1 encoding is not applicable, and so by default the node will interpret the ECN field using [RFC3168].
PCN节点必须使用三合一PCN编码而不是[RFC3168]来解释PCN数据包的ECN字段。这不会改变DSCP与PCN不兼容的任何数据包或PCN域之外的任何节点的行为。在所有这些情况下，三合一编码不适用，因此默认情况下，节点将使用[RFC3168]解释ECN字段。
When using the 3-in-1 encoding, the codepoints of the ECN field have the following meanings:
使用三合一编码时，ECN字段的代码点具有以下含义：
not-PCN: indicates a non-PCN-packet, i.e., a packet that uses a PCN-compatible DSCP but is not subject to PCN metering and marking.
非PCN：表示非PCN数据包，即使用PCN兼容DSCP但不受PCN计量和标记约束的数据包。
NM: not-marked. Indicates a PCN-packet that has not yet been marked by any PCN marker.
NM：未标记。表示尚未由任何PCN标记标记的PCN数据包。
ThM: threshold-marked. Indicates a PCN-packet that has been marked by a threshold-marker [RFC5670].
ThM：已标记阈值。表示已由阈值标记[RFC5670]标记的PCN数据包。
ETM: excess-traffic-marked. Indicates a PCN-packet that has been marked by an excess-traffic-marker [RFC5670].
ETM：标记了过量流量。表示已由过量流量标记[RFC5670]标记的PCN数据包。
In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes control packets entering a PCN-domain. Packets belonging to PCN-controlled flows are subject to PCN-metering and PCN-marking, and PCN-ingress-nodes mark them as not-marked (PCN-colouring). All nodes in the PCN-domain perform PCN-metering and PCN-mark PCN-packets if needed. There are two different metering and marking behaviours: threshold-marking and excess-traffic-marking [RFC5670]. Some edge behaviours require only a Single Marking behaviour [RFC6662], others require both [RFC6661]. In the latter case, three PCN marking states are needed: not-marked (NM) to indicate not-marked packets, threshold-marked (ThM) to indicate packets marked by the threshold-marker, and excess-traffic-marked (ETM) to indicate packets marked by the excess-traffic-marker [RFC5670]. Threshold-marking and excess-traffic-marking are configured to start marking packets at different load conditions, so one marking behaviour indicates more severe pre-congestion than the other. Therefore, a fourth PCN marking state indicating that a packet is marked by both markers is not needed. However, a fourth codepoint is required to indicate packets that use a PCN-compatible DSCP but do not use PCN-marking (the not-PCN codepoint).
根据PCN体系结构[RFC5559]，PCN入口节点控制进入PCN域的数据包。属于PCN控制流的数据包受PCN计量和PCN标记的约束，PCN入口节点将其标记为未标记（PCN着色）。PCN域中的所有节点执行PCN计量，如果需要，PCN标记PCN数据包。有两种不同的计量和标记行为：阈值标记和过量流量标记[RFC5670]。某些边缘行为只需要一个标记行为[RFC6662]，其他边缘行为则需要两个标记行为[RFC6661]。在后一种情况下，需要三种PCN标记状态：未标记（NM）表示未标记的数据包，阈值标记（ThM）表示由阈值标记标记的数据包，以及过量流量标记（ETM）表示由过量流量标记标记的数据包[RFC5670]。阈值标记和过量流量标记配置为在不同的负载条件下开始标记数据包，因此一种标记行为表明预拥塞比另一种更严重。因此，不需要指示分组由两个标记标记的第四PCN标记状态。但是，需要第四个代码点来指示使用PCN兼容DSCP但不使用PCN标记的数据包（非PCN代码点）。
In all current PCN edge behaviours that use two marking behaviours [RFC5559] [RFC6661], excess-traffic-marking is configured with a larger reference rate than threshold-marking. We take this as a rule and define excess-traffic-marked as a more severe PCN-mark than threshold-marked.
在使用两种标记行为[RFC5559][RFC6661]的所有当前PCN边缘行为中，过量交通标记配置为比阈值标记更大的参考速率。我们将此视为一条规则，并将多余流量定义为比阈值标记更严重的PCN标记。
[RFC6040] defines rules for the encapsulation and decapsulation of ECN markings within IP-in-IP tunnels. The publication of RFC 6040 removed the tunnelling constraints that existed when the encoding of [RFC5696] was written (see Section 3.3.2 of [RFC6627]).
[RFC6040]定义了IP隧道中IP内ECN标记的封装和去封装规则。RFC 6040的发布消除了编写[RFC5696]编码时存在的隧道约束（见[RFC6627]第3.3.2节）。
Nonetheless, there is still a problem if there are any legacy (pre-RFC6040) decapsulating tunnel endpoints within a PCN-domain. If a PCN-node Threshold-marks the outer header of a tunnelled packet that has a not-marked codepoint on the inner header, a legacy decapsulator will forward the packet as not-marked, losing the Threshold-marking. The rules on applicability in Section 4.3 below are designed to avoid this problem.
尽管如此，如果在PCN域中存在任何遗留（RFC6040之前）去封装隧道端点，仍然存在问题。如果PCN节点阈值标记了隧道数据包的外部报头，该数据包的内部报头上有一个未标记的代码点，则传统的去封装器会将该数据包转发为未标记，从而丢失阈值标记。下文第4.3节中的适用性规则旨在避免这一问题。
Even if an operator accidentally breaks these applicability rules, the order of severity of the 3-in-1 codepoints was chosen to protect other PCN or non-PCN traffic. Although legacy pre-RFC6040 tunnels did not propagate '01', all tunnels pre-RFC6040 and post-RFC6040 have always propagated '11' correctly. Therefore, '11' was chosen to signal the most severe pre-congestion (ETM), so it would act as a reliable fail-safe even if an overlooked legacy tunnel was suppressing '01' (ThM) signals.
即使操作员意外违反了这些适用性规则，也会选择三合一代码点的严重性顺序来保护其他PCN或非PCN流量。尽管传统RFC6040之前的隧道未传播“01”，但RFC6040之前和RFC6040之后的所有隧道始终正确传播“11”。因此，选择“11”作为最严重预拥塞（ETM）的信号，因此即使被忽略的传统隧道正在抑制“01”（ThM）信号，它也将作为可靠的故障保护。
The 3-in-1 encoding is applicable in situations where two marking behaviours are being used in the PCN-domain. The 3-in-1 encoding can also be used with only one marking behaviour, in which case one of the codepoints MUST NOT be used anywhere in the PCN-domain (see Section 5.2.3).
三合一编码适用于PCN域中使用两种标记行为的情况。三合一编码也可仅用于一种标记行为，在这种情况下，不得在PCN域的任何地方使用一个代码点（见第5.2.3节）。
With one exception (see next paragraph), any tunnel endpoints (IP-in-IP and IPsec) within the PCN-domain MUST comply with the ECN encapsulation and decapsulation rules set out in [RFC6040] (see Section 4.2).
除一个例外（见下一段），PCN域内的任何隧道端点（IP中的IP和IPsec）必须符合[RFC6040]中规定的ECN封装和去封装规则（见第4.2节）。
Operators may not be able to upgrade every pre-RFC6040 tunnel endpoint within a PCN-domain. In such circumstances, a limited version of the 3-in-1 encoding can still be used but only under the following stringent condition. If any pre-RFC6040 tunnel decapsulator exists within a PCN-domain, then every PCN-node in the PCN-domain MUST be configured so that it never sets the ThM codepoint. PCN-interior-nodes in this case MUST solely use the Excess-traffic-marking function, as defined in Section 5.2.3.1. In all other situations where legacy tunnel decapsulators might be present within the PCN-domain, the 3-in-1 encoding is not applicable.
运营商可能无法升级PCN域中每个RFC6040之前的隧道端点。在这种情况下，仍然可以使用3合1编码的有限版本，但只能在以下严格条件下使用。如果PCN域中存在任何RFC6040之前的隧道解封装器，则必须配置PCN域中的每个PCN节点，使其永远不会设置ThM码点。在这种情况下，PCN内部节点必须仅使用第5.2.3.1节中定义的多余交通标志功能。在PCN域内可能存在传统隧道去封装器的所有其他情况下，三合一编码不适用。
Any tunnel endpoint implementation on a PCN-node MUST comply with [RFC6040]. Since PCN is a new capability, this is considered a reasonable requirement.
PCN节点上的任何隧道端点实现必须符合[RFC6040]。由于PCN是一种新的能力，这被认为是一种合理的要求。
If packets arrive from another Diffserv domain, any re-mapping of Diffserv codepoints MUST happen before PCN-ingress processing.
如果数据包来自另一个Diffserv域，则必须在PCN进入处理之前重新映射Diffserv代码点。
At each logical ingress link into a PCN-domain, each PCN-ingress-node will apply the four functions described in Section 4.2 of [RFC5559] to arriving packets. These functions are applied in the following order: PCN-classify, PCN-police, PCN-colour, PCN-rate-meter. This
在进入PCN域的每个逻辑入口链路上，每个PCN入口节点将对到达的数据包应用[RFC5559]第4.2节中描述的四个功能。这些功能按以下顺序应用：PCN分类、PCN报警、PCN颜色、PCN速率计。这
section describes these four steps, but only the aspects relevant to packet encoding:
第节介绍这四个步骤，但仅介绍与数据包编码相关的方面：
1. PCN-classification: The PCN-ingress-node determines whether each packet matches the filter spec of an admitted flow. Packets that match are defined as PCN-packets.
1. PCN分类：PCN入口节点确定每个数据包是否与允许流的过滤器规格匹配。匹配的数据包被定义为PCN数据包。
1b. Extra step if ECN and PCN coexist: If a packet classified as a PCN-packet arrives with the ECN field already set to a value other than Not-ECT (i.e., it is from an ECN-capable transport), then to comply with BCP 124 [RFC4774] it MUST pass through one of the following preparatory steps before the PCN-policing and PCN-colouring steps. The choice between these four actions depends on local policy:
1b。如果ECN和PCN共存，则额外步骤：如果分类为PCN数据包的数据包到达时，ECN字段已设置为非ECT值（即，它来自支持ECN的传输），则为了符合BCP 124[RFC4774]，必须在PCN监控和PCN着色步骤之前通过以下准备步骤之一。这四种行动之间的选择取决于当地政策：
* Encapsulate ECN-capable PCN-packets across the PCN-domain:
* 在PCN域中封装支持ECN的PCN数据包：
+ either within another IP header using an RFC6040 tunnel;
+ 在使用RFC6040隧道的另一个IP报头内；
+ or within a lower-layer protocol capable of being PCN-marked, such as MPLS (see Appendix C).
+ 或者在能够被PCN标记的较低层协议内，例如MPLS（参见附录C）。
Encapsulation using either of these methods is the RECOMMENDED policy for ECN-capable PCN-packets, and implementations SHOULD use IP-in-IP tunnelling as the default.
对于支持ECN的PCN数据包，建议使用这两种方法中的任何一种进行封装，并且实现应使用IP-in-IP隧道作为默认策略。
If encapsulation is used, it MUST precede PCN-policing and PCN-colouring so that the encapsulator and decapsulator are logically outside the PCN-domain (see Appendix B and specifically Figure 2).
如果使用封装，则必须在PCN监控和PCN着色之前进行封装，以便封装器和去封装器在逻辑上位于PCN域之外（参见附录B和图2）。
If MPLS encapsulation is used, note that penultimate hop popping [RFC3031] is incompatible with PCN, unless the penultimate hop applies the PCN-egress-node behaviour before it pops the PCN-capable MPLS label.
如果使用MPLS封装，请注意倒数第二跳弹出[RFC3031]与PCN不兼容，除非倒数第二跳在弹出支持PCN的MPLS标签之前应用PCN出口节点行为。
* If some form of encapsulation is not possible, the PCN-ingress-node can allow through ECN-capable packets without encapsulation, but it MUST drop CE-marked packets at this stage. Failure to drop CE-marked packets would risk congestion collapse, because without encapsulation there is no mechanism to propagate the CE markings across the PCN-domain (see Appendix B).
* 如果不可能进行某种形式的封装，则PCN入口节点可以允许不进行封装的通过ECN的数据包，但在此阶段必须丢弃带有CE标记的数据包。未能丢弃CE标记的数据包将有拥塞崩溃的风险，因为没有封装，就没有机制在PCN域中传播CE标记（见附录B）。
This policy is NOT RECOMMENDED because there is no tunnel to protect the e2e ECN capability, which is otherwise disabled when the PCN-egress-node zeroes the ECN field.
不建议使用此策略，因为没有隧道来保护e2e ECN功能，否则当PCN出口节点将ECN字段归零时，该功能将被禁用。
* Drop the packet.
* 放下包。
This policy is also NOT RECOMMENDED, because it precludes the possibility that e2e ECN can coexist with PCN as a means of controlling congestion.
该政策也不推荐，因为它排除了e2e ECN与PCN共存作为控制拥塞的一种手段的可能性。
* Any other action that complies with [RFC4774] (see Appendix B for an example).
* 符合[RFC4774]的任何其他行动（示例见附录B）。
Appendix B provides more information about the coexistence of PCN and ECN.
附录B提供了关于PCN和ECN共存的更多信息。
2. PCN-policing: The PCN-policing function only allows appropriate packets into the PCN behaviour aggregate. Per-flow policing actions may be required to block rejected flows and to rate-police accepted flows, but these are specified in the relevant edge-behaviour document, e.g., [RFC6662] or [RFC6661].
2. PCN监控：PCN监控功能仅允许将适当的数据包放入PCN行为聚合。可能需要每流警务行动来阻止拒绝的流并对警察接受的流进行评级，但相关边缘行为文件中规定了这些行动，例如，[RFC6662]或[RFC6661]。
Here, we only specify packet-level PCN-policing, which prevents packets that are not PCN-packets from being forwarded into the PCN-domain if PCN-interior-nodes would otherwise mistake them for PCN-packets. A non-PCN-packet will be confused with a PCN-packet if on arrival it meets all three of the following conditions:
在这里，我们只指定数据包级别的PCN策略，如果PCN内部节点将其误认为是PCN数据包，则该策略可防止非PCN数据包的数据包被转发到PCN域。如果非PCN数据包在到达时满足以下三个条件，则会将其与PCN数据包混淆：
a) it is not classified as a PCN-packet;
a) 它不属于PCN数据包；
b) it already carries a PCN-compatible DSCP; and
b) 它已经携带了与PCN兼容的DSCP；和
c) its ECN field carries a codepoint other than Not-ECT.
c) 它的ECN字段携带一个非ECT的代码点。
The PCN-ingress-node MUST police packets that meet all three conditions (a-c) by subjecting them to one of the following treatments:
PCN入口节点必须通过对满足所有三个条件（a-c）的数据包进行以下处理之一来对其进行监控：
* re-mark the DSCP to a DSCP that is not PCN-compatible;
* 将DSCP重新标记为不兼容PCN的DSCP；
* tunnel the packet to the PCN-egress-node with a DSCP in the outer header that is not PCN-compatible; or
* 在外部报头中使用不兼容PCN的DSCP将分组隧道到PCN出口节点；或
* drop the packet (NOT RECOMMENDED -- see below).
* 丢弃数据包（不建议这样做，请参见下文）。
The choice between these actions depends on local policy. In the absence of any operator-specific configuration for this case, an implementation SHOULD re-mark the DSCP to zero (000000) by default.
这些行动之间的选择取决于当地政策。在没有针对这种情况的任何特定于操作员的配置的情况下，实现应在默认情况下将DSCP重新标记为零（000000）。
Whichever policing action is chosen, the PCN-ingress-node SHOULD log the event and MAY also raise an alarm. Alarms SHOULD be rate-limited so that the anomalous packets will not amplify into a flood of alarm messages.
无论选择哪种策略操作，PCN入口节点都应记录事件，并可能发出警报。警报应限制速率，以便异常数据包不会放大为大量警报消息。
Rationale: Traffic that meets all three of the above conditions (a-c) is not PCN-traffic; therefore, ideally a PCN-ingress ought not to interfere with it, but it has to do something to avoid ambiguous packet markings. Clearing the ECN field is not an appropriate policing action, because a network node ought not to interfere with an e2e signal. Even if such packets seem like an attack, drop would be overkill, because such an attack can be neutralised by just re-marking the DSCP. And DSCP re-marking in the network is legitimate, because the DSCP is not considered an e2e signal.
理由：满足上述三个条件（a-c）的流量不是PCN流量；因此，理想情况下，PCN入口不应干扰它，但它必须采取措施避免模棱两可的数据包标记。清除ECN字段不是适当的策略操作，因为网络节点不应该干扰e2e信号。即使这样的数据包看起来像是一种攻击，丢弃也会是一种过度杀伤力，因为这种攻击可以通过重新标记DSCP来抵消。由于DSCP不被视为e2e信号，因此网络中的DSCP重新标记是合法的。
3. PCN-colouring: If a packet has been classified as a PCN-packet, once it has been policed, the PCN-ingress-node:
3. PCN着色：如果数据包被分类为PCN数据包，一旦对其进行了策略，PCN入口节点：
* MUST set a PCN-compatible Diffserv codepoint on all PCN-packets. To conserve DSCPs, DSCPs SHOULD be chosen that are already defined for use with admission-controlled traffic. Appendix A gives guidance to implementors on suitable DSCPs.
* 必须在所有PCN数据包上设置与PCN兼容的Diffserv代码点。为了保护DSCP，应选择已定义用于准入控制流量的DSCP。附录A为实施者提供了适用DSCP的指南。
* MUST set the PCN codepoint of all PCN-packets to not-marked (NM).
* 必须将所有PCN数据包的PCN代码点设置为未标记（NM）。
4. PCN rate-metering: This fourth step may be necessary depending on the edge behaviour in force. It is listed for completeness, but it is not relevant to this encoding document.
4. PCN速率计量：第四步可能是必要的，取决于有效的边缘行为。列出它是为了完整，但它与此编码文档无关。
Interior nodes MUST NOT change not-PCN to any other codepoint.
内部节点不得将NOT PCN更改为任何其他代码点。
Interior nodes MUST NOT change NM to not-PCN.
内部节点不得将NM更改为NOT PCN。
Interior nodes MUST NOT change ThM to NM or not-PCN.
内部节点不得将ThM更改为NM或非PCN。
Interior nodes MUST NOT change ETM to any other codepoint.
内部节点不得将ETM更改为任何其他代码点。
If the threshold-meter function indicates a need to mark a packet, the PCN-interior-node MUST change NM to ThM.
如果阈值计功能指示需要标记数据包，则PCN内部节点必须将NM更改为ThM。
If the excess-traffic-meter function indicates a need to mark a packet:
如果过量流量表功能指示需要标记数据包：
o the PCN-interior-node MUST change NM to ETM;
o PCN内部节点必须将NM更改为ETM；
o the PCN-interior-node MUST change ThM to ETM.
o PCN内部节点必须将ThM更改为ETM。
If both the threshold meter and the excess-traffic meter indicate the need to mark a packet, the Excess-traffic-marking rules MUST take precedence.
如果阈值表和超额流量表都指示需要标记数据包，则超额流量标记规则必须优先。
Some PCN edge behaviours require only one PCN-marking within the PCN-domain. The Single Marking edge behaviour [RFC6662] requires PCN-interior-nodes to mark packets using the excess-traffic-meter function [RFC5670]. It is possible that future schemes may require only the threshold-meter function. Appendix D explains the rationale for the behaviours defined in this section.
某些PCN边缘行为只需要PCN域内的一个PCN标记。单标记边缘行为[RFC6662]要求PCN内部节点使用过量流量表功能[RFC5670]标记数据包。未来的方案可能只需要阈值计功能。附录D解释了本节中定义的行为的基本原理。
The threshold-traffic-meter function SHOULD be disabled and MUST NOT trigger any packet marking.
应禁用阈值流量表功能，且不得触发任何数据包标记。
The PCN-interior-node SHOULD raise a management alarm if it receives a ThM packet, but the frequency of such alarms SHOULD be limited.
如果PCN内部节点接收到ThM数据包，则应发出管理警报，但此类警报的频率应受到限制。
If the excess-traffic-meter function indicates a need to mark the packet:
如果过量流量表功能指示需要标记数据包：
o the PCN-interior-node MUST change NM to ETM;
o PCN内部节点必须将NM更改为ETM；
o the PCN-interior-node MUST change ThM to ETM. It SHOULD also raise an alarm as above.
o PCN内部节点必须将ThM更改为ETM。它还应如上所述发出警报。
The excess-traffic-meter function SHOULD be disabled and MUST NOT trigger any packet marking.
应禁用过量流量表功能，且不得触发任何数据包标记。
The PCN-interior-node SHOULD raise a management alarm if it receives an ETM packet, but the frequency of such alarms SHOULD be limited.
如果收到ETM数据包，PCN内部节点应发出管理警报，但此类警报的频率应受到限制。
If the threshold-meter function indicates a need to mark the packet:
如果阈值计功能指示需要标记数据包：
o the PCN-interior-node MUST change NM to ThM;
o PCN内部节点必须将NM更改为ThM；
o the PCN-interior-node MUST NOT change ETM to any other codepoint. It SHOULD raise an alarm as above if it encounters an ETM packet.
o PCN内部节点不得将ETM更改为任何其他代码点。如果遇到ETM数据包，应如上所述发出警报。
A PCN-egress-node SHOULD set the not-PCN ('00') codepoint on all packets it forwards out of the PCN-domain.
PCN出口节点应在其转发出PCN域的所有数据包上设置not PCN（“00”）码点。
The only exception to this is if the PCN-egress-node is certain that revealing other codepoints outside the PCN-domain won't contravene the guidance given in [RFC4774]. For instance, if the PCN-ingress-node has explicitly informed the PCN-egress-node that this flow is ECN-capable, then it might be safe to expose other ECN codepoints. Appendix B gives details of how such schemes might work, but such schemes are currently only tentative ideas.
唯一的例外情况是，如果PCN出口节点确定显示PCN域之外的其他代码点不会违反[RFC4774]中给出的指导。例如，如果PCN入口节点已明确通知PCN出口节点该流具有ECN能力，则公开其他ECN代码点可能是安全的。附录B详细说明了这些计划可能如何运作，但这些计划目前只是初步设想。
If the PCN-domain is configured to use only Excess-traffic-marking, the PCN-egress-node MUST treat ThM as ETM; if only threshold-marking is used, it SHOULD treat ETM as ThM. However, it SHOULD raise a management alarm in either case since this means there is some misconfiguration in the PCN-domain.
如果PCN域配置为仅使用过量流量标记，则PCN出口节点必须将ThM视为ETM；如果仅使用阈值标记，则应将ETM视为ThM。但是，无论哪种情况，它都应该引起管理警报，因为这意味着PCN域中存在一些错误配置。
BCP 124 [RFC4774] gives guidelines for specifying alternative semantics for the ECN field. It sets out a number of factors to be taken into consideration. It also suggests various techniques to allow the coexistence of default ECN and alternative ECN semantics. The encoding specified in this document uses one of those techniques; it defines PCN-compatible Diffserv codepoints as no longer supporting the default ECN semantics within a PCN-domain. As such, this document is compatible with BCP 124.
BCP 124[RFC4774]给出了为ECN字段指定替代语义的指南。它列出了一些需要考虑的因素。它还建议使用各种技术来允许默认ECN和备选ECN语义共存。本文件中规定的编码使用这些技术之一；它将PCN兼容的Diffserv代码点定义为不再支持PCN域中的默认ECN语义。因此，本文件与BCP 124兼容。
There is not enough space in one IP header for the 3-in-1 encoding to support both ECN marking end-to-end and PCN-marking within a PCN-domain. The non-normative Appendix B discusses possible ways to do this, e.g., by carrying e2e ECN across a PCN-domain within the inner header of an IP-in-IP tunnel. The normative text in Section 5.1 requires one of these methods to be configured at the PCN-ingress-node and recommends that implementations offer tunnelling as the default.
一个IP报头中没有足够的空间用于三合一编码，无法支持PCN域内的端到端ECN标记和PCN标记。非规范性附录B讨论了实现这一点的可能方法，例如，通过在IP-in-IP隧道的内部报头内跨PCN域携带e2e ECN。第5.1节中的规范性文本要求在PCN入口节点配置其中一种方法，并建议实施提供默认的隧道。
In any PCN deployment, traffic can only enter the PCN-domain through PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-nodes ensure that any packets entering the PCN-domain have the ECN field in their outermost IP header set to the appropriate codepoint.
在任何PCN部署中，流量只能通过PCN入口节点进入PCN域，并通过PCN出口节点离开。PCN入口节点确保任何进入PCN域的数据包都将其最外层IP报头中的ECN字段设置为适当的代码点。
PCN-egress-nodes then guarantee that the ECN field of any packet leaving the PCN-domain has appropriate ECN semantics. This prevents unintended leakage of ECN marks into or out of the PCN-domain, and thus reduces backward-compatibility issues.
然后，PCN出口节点保证离开PCN域的任何数据包的ECN字段具有适当的ECN语义。这可以防止ECN标记意外泄漏到PCN域或从PCN域泄漏出去，从而减少向后兼容性问题。
Section 5.1 of the PCN architecture [RFC5559] gives general guidance on fault detection and diagnosis, including management analysis of PCN markings arriving at PCN-egress-nodes to detect early signs of potential faults. Because the PCN encoding has gone through an obsoleted earlier stage [RFC5696], misconfiguration mistakes may be more likely. Therefore, extra monitoring, such as in the following example, may be necessary to detect and diagnose potential problems:
PCN体系结构[RFC5559]第5.1节给出了故障检测和诊断的一般指导，包括对到达PCN出口节点的PCN标记进行管理分析，以检测潜在故障的早期迹象。由于PCN编码经历了一个过时的早期阶段[RFC5696]，错误配置错误的可能性更大。因此，为了检测和诊断潜在问题，可能需要额外的监控，如以下示例中的监控：
Informational example: In a controlled-load edge-behaviour scenario it could be worth the PCN-egress-node detecting the onset of excess-traffic marking without any prior threshold-marking. This might indicate that an interior node has been wrongly configured to mark only ETM (which would have been correct for the single-marking edge behaviour).
信息示例：在受控负载边缘行为场景中，PCN出口节点在没有任何事先阈值标记的情况下检测过量流量标记的开始是值得的。这可能表明内部节点被错误配置为仅标记ETM（这对于单标记边缘行为是正确的）。
A PCN-node implemented to use the obsoleted encoding in RFC 5696 could conceivably have been configured so that the Threshold-meter function marked what is now defined as the ETM codepoint in the 3-in-1 encoding. However, there is no known deployment of this rather unlikely variant of RFC 5696 and no reason to believe that such an implementation would ever have been built. Therefore, it seems safe to ignore this issue.
可以想象，在RFC 5696中实现为使用过时的编码的PCN节点可以被配置为使得阈值计功能标记现在在3合1编码中定义为ETM码点的内容。然而，目前还没有已知的RFC 5696这种不太可能的变体的部署，也没有理由相信会构建这样的实现。因此，忽视这个问题似乎是安全的。
PCN-marking only carries a meaning within the confines of a PCN-domain. This encoding document is intended to stand independently of the architecture used to determine how specific packets are authorised to be PCN-marked, which will be described in separate documents on PCN-boundary-node behaviour.
PCN标记仅在PCN域范围内具有意义。本编码文件旨在独立于用于确定如何授权特定数据包进行PCN标记的体系结构，这将在关于PCN边界节点行为的单独文件中描述。
This document assumes the PCN-domain to be entirely under the control of a single operator, or a set of operators who trust each other. However, future extensions to PCN might include inter-domain versions where trust cannot be assumed between domains. If such schemes are proposed, they must ensure that they can operate securely despite the lack of trust. However, such considerations are beyond the scope of this document.
本文档假设PCN域完全由单个运营商或一组相互信任的运营商控制。然而，PCN的未来扩展可能包括域间版本，在这些版本中，域之间不能假定信任。如果提出这类计划，它们必须确保在缺乏信任的情况下能够安全运作。然而，此类考虑超出了本文件的范围。
One potential security concern is the injection of spurious PCN-marks into the PCN-domain. However, these can only enter the domain if a PCN-ingress-node is misconfigured. The precise impact of any such misconfiguration will depend on which of the proposed PCN-boundary-node behaviours is used; however, in general, spurious marks will lead to admitting fewer flows into the domain or potentially terminating too many flows. In either case, good management should be able to quickly spot the problem since the overall utilisation of the domain will rapidly fall.
一个潜在的安全问题是向PCN域中注入虚假的PCN标记。但是，只有当PCN入口节点配置错误时，这些节点才能进入域。任何此类错误配置的确切影响将取决于使用哪种拟定的PCN边界节点行为；但是，一般来说，虚假标记将导致允许较少的流进入域，或者可能终止过多的流。在这两种情况下，良好的管理应该能够迅速发现问题，因为该领域的整体利用率将迅速下降。
The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field to encode PCN-marks. One codepoint allows non-PCN traffic to be carried with the same PCN-compatible DSCP and three other codepoints support three PCN marking states with different levels of severity. In general, the use of this PCN encoding scheme presupposes that any tunnel endpoints within the PCN-domain comply with [RFC6040].
三合一PCN编码使用与PCN兼容的DSCP和ECN字段对PCN标记进行编码。一个代码点允许使用相同的PCN兼容DSCP承载非PCN流量，另外三个代码点支持三种严重程度不同的PCN标记状态。通常，使用此PCN编码方案的前提是PCN域内的任何隧道端点符合[RFC6040]。
Many thanks to Philip Eardley for providing extensive feedback, criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan, Ruediger Geib, Georgios Karagiannis, James Polk, Tom Taylor, Adrian Farrel, and everyone else who has commented on the document.
非常感谢Philip Eardley提供了广泛的反馈、批评和建议。还要感谢Teco Boot、郭浩灿、Ruediger Geib、Georgios Karagiannis、James Polk、Tom Taylor、Adrian Farrel以及所有对该文件发表评论的人。
[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月。
[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月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559]Eardley，P.，“拥塞前通知（PCN）体系结构”，RFC555592009年6月。
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670]Eardley，P.，“PCN节点的计量和标记行为”，RFC 56702009年11月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.
[RFC6040]Briscoe，B.，“明确拥塞通知的隧道挖掘”，RFC 60402010年11月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[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月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[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月。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 45942006年8月。
[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月。
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, February 2008.
[RFC5127]Chan，K.，Babiarz，J.，和F.Baker，“区分服务类的聚合”，RFC 5127，2008年2月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129]Davie，B.，Briscoe，B.，和J.Tay，“MPLS中的显式拥塞标记”，RFC 5129，2008年1月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[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月。
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010.
[RFC5865]Baker，F.，Polk，J.，和M.Dolly，“容量允许流量的区分服务代码点（DSCP）”，RFC 5865，2010年5月。
[RFC6627] Karagiannis, G., Chan, K., Moncaster, T., Menth, M., Eardley, P., and B. Briscoe, "Overview of Pre-Congestion Notification Encoding", RFC 6627, July 2012.
[RFC6627]Karagiannis，G.，Chan，K.，Moncaster，T.，Meth，M.，Eardley，P.，和B.Briscoe，“拥塞前通知编码概述”，RFC 6627，2012年7月。
[RFC6661] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-Node Behaviour 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, Ed., "Pre-Congestion Notification (PCN) Boundary-Node Behaviour for the Single Marking (SM) Mode of Operation", RFC 6662, July 2012.
[RFC6662]Charny，A.，Zhang，J.，Karagiannis，G.，Minth，M.，和T.Taylor，Ed.，“单标记（SM）运行模式下的拥塞前通知（PCN）边界节点行为”，RFC 6662，2012年7月。
This appendix is informative not normative.
本附录为资料性附录，非规范性附录。
A single DSCP has not been defined for use with PCN for several reasons. Firstly, the PCN mechanism is applicable to a variety of different traffic classes. Secondly, Standards Track DSCPs are in increasingly short supply. Thirdly, PCN is not a scheduling behaviour -- rather, it should be seen as being a marking behaviour similar to ECN but intended for inelastic traffic. The choice of which DSCP is most suitable for a given PCN-domain is dependent on the nature of the traffic entering that domain and the link rates of all the links making up that domain. In PCN-domains with sufficient aggregation, the appropriate DSCPs would currently be those for the Real-Time Treatment Aggregate [RFC5127]. It is suggested that admission control could be used for the following service classes (defined in [RFC4594] unless otherwise stated):
由于多种原因，尚未定义单个DSCP与PCN一起使用。首先，PCN机制适用于各种不同的流量类别。其次，标准轨道DSCP的供应日益短缺。第三，PCN不是一种调度行为——相反，它应该被视为一种类似于ECN的标记行为，但用于非弹性流量。选择哪个DSCP最适合给定PCN域取决于进入该域的流量的性质以及构成该域的所有链路的链路速率。在聚合充分的PCN域中，适当的DSCP当前将是用于实时处理聚合的DSCP[RFC5127]。建议允许控制可用于以下服务类别（在[RFC4594]中定义，除非另有说明）：
o Telephony (EF)
o 电话（EF）
o Real-time interactive (CS4)
o 实时交互（CS4）
o Broadcast Video (CS3)
o 广播视频（CS3）
o Multimedia Conferencing (AF4)
o 多媒体会议（AF4）
o the VOICE-ADMIT codepoint defined in [RFC5865].
o [RFC5865]中定义的语音识别码点。
CS5 is excluded from this list since PCN is not expected to be applied to signalling traffic.
CS5被排除在该列表之外，因为PCN预计不会应用于信令业务。
PCN-marking is intended to provide a scalable admission-control mechanism for traffic with a high degree of statistical multiplexing. PCN-marking would therefore be appropriate to apply to traffic in the above classes, but only within a PCN-domain containing sufficiently aggregated traffic. In such cases, the above service classes may well all be subject to a single forwarding treatment (treatment aggregate [RFC5127]). However, this does not imply all such IP traffic would necessarily be identified by one DSCP -- each service class might keep a distinct DSCP within the highly aggregated region [RFC5127].
PCN标记旨在为具有高度统计复用的流量提供可伸缩的接纳控制机制。因此，PCN标记适用于上述类别的流量，但仅适用于包含充分聚合流量的PCN域。在这种情况下，上述服务类别很可能全部接受单一转发处理（处理聚合[RFC5127]）。然而，这并不意味着所有此类IP流量都必须由一个DSCP标识——每个服务类可能在高度聚合的区域内保持一个不同的DSCP[RFC5127]。
Guidelines for conserving DSCPs by allowing non-admission-controlled-traffic to compete with PCN-traffic are given in Appendix B.1 of [RFC5670].
[RFC5670]的附录B.1中给出了通过允许非准入控制流量与PCN流量竞争来保护DSCP的指南。
Additional service classes may be defined for which admission control is appropriate, whether through some future standards action or through local use by certain operators, e.g., the Multimedia Streaming service class (AF3). This document does not preclude the use of PCN in more cases than those listed above.
可以通过一些未来的标准行动或通过某些运营商的本地使用（例如，多媒体流服务类（AF3））来定义允许控制适当的附加服务类。本文件不排除在比上述情况更多的情况下使用PCN。
Note: The above discussion is informative not normative, as operators are ultimately free to decide whether to use admission control for certain service classes and whether to use PCN as their mechanism of choice.
注：上述讨论是信息性的而非规范性的，因为运营商最终可以自由决定是否对某些服务类别使用准入控制，以及是否使用PCN作为其选择机制。
This appendix is informative not normative. It collects together material relevant to coexistence of ECN and PCN, including that spread throughout the body of this specification. If this results in any conflict or ambiguity, the normative text in the body of the specification takes precedence.
本附录为资料性附录，非规范性附录。它收集与ECN和PCN共存相关的材料，包括散布在本规范正文中的材料。如果这导致任何冲突或歧义，则以规范正文中的规范性文本为准。
ECN [RFC3168] is an e2e congestion notification mechanism. As such it is possible that some traffic entering the PCN-domain may also be ECN-capable. The PCN encoding described in this document reuses the bits of the ECN field in the IP header. Consequently, this disables ECN within the PCN-domain.
ECN[RFC3168]是一种e2e拥塞通知机制。因此，一些进入PCN域的流量也可能具有ECN能力。本文档中描述的PCN编码重用IP报头中ECN字段的位。因此，这将禁用PCN域内的ECN。
For the purposes of this appendix, we define two forms of traffic that might arrive at a PCN-ingress-node. These are admission-controlled traffic (PCN-traffic) and non-admission-controlled traffic (non-PCN-traffic).
在本附录中，我们定义了两种可能到达PCN入口节点的流量形式。这些是准入控制流量（PCN流量）和非准入控制流量（非PCN流量）。
Flow signalling identifies admission-controlled traffic, by associating a filter spec with the need for admission control (e.g., through RSVP or some equivalent message, such as from a SIP server to the ingress or from a logically centralised network control system). The PCN-ingress-node re-marks admission-controlled traffic matching that filter spec to a PCN-compatible DSCP. Note that the term "flow" need not imply just one microflow, but instead could match an aggregate and/or could depend on the incoming DSCP (see Appendix A).
流信令通过将过滤器规范与准入控制需求相关联（例如，通过RSVP或一些等效消息，例如从SIP服务器到入口或从逻辑集中的网络控制系统）来识别准入控制流量。PCN入口节点将符合筛选规范的准入控制流量重新标记为与PCN兼容的DSCP。请注意，术语“流量”不需要仅指一个微流量，而是可以匹配一个集合和/或取决于传入的DSCP（见附录A）。
All other traffic can be thought of as non-admission-controlled (and therefore outside the scope of PCN). However, such traffic may still need to share the same DSCP as the admission-controlled traffic. This may be due to policy (for instance, if it is high-priority voice traffic), or may be because there is a shortage of local DSCPs.
所有其他流量可被视为非准入控制（因此不在PCN范围内）。然而，这种业务可能仍然需要与准入控制业务共享相同的DSCP。这可能是由于政策（例如，如果是高优先级语音通信），也可能是因为本地DSCP不足。
Unless specified otherwise, for any of the cases in the list below, an IP-in-IP tunnel that complies with [RFC6040] can be used to preserve ECN markings across the PCN-domain. The tunnelling action
除非另有规定，对于以下列表中的任何情况，符合[RFC6040]的IP-in-IP隧道可用于在整个PCN域内保留ECN标记。隧道施工
should be applied wholly outside the PCN-domain as illustrated in Figure 2. Then, by the rules of RFC 6040, the tunnel egress propagates the ECN field from the inner header, because the PCN-egress will have zeroed the outer ECN field.
应完全应用于PCN领域之外，如图2所示。然后，根据RFC 6040的规则，隧道出口从内部报头传播ECN字段，因为PCN出口将使外部ECN字段归零。
. . . . . . PCN-domain . . . . . .
. ,---------. ,--------. .
. _| PCN- |___________________| PCN- |_ .
. / | ingress | | egress | \ .
.| `---------' `--------' |.
| . . . . . . . . . . . . . . .|
,---------. ,--------.
_____| Tunnel | | Tunnel |____
| Ingress | - - ECN preserved inside tunnel - - | Egress |
`---------' `--------'
. . . . . . PCN-domain . . . . . .
. ,---------. ,--------. .
. _| PCN- |___________________| PCN- |_ .
. / | ingress | | egress | \ .
.| `---------' `--------' |.
| . . . . . . . . . . . . . . .|
,---------. ,--------.
_____| Tunnel | | Tunnel |____
| Ingress | - - ECN preserved inside tunnel - - | Egress |
`---------' `--------'
Figure 2: Separation of Tunnelling and PCN Actions
图2：隧道开挖和PCN行动的分离
There are three cases for how e2e ECN traffic may wish to be treated while crossing a PCN-domain:
在穿越PCN域时，e2e ECN流量可能希望如何处理有三种情况：
a) Traffic that does not require PCN admission control: For example, traffic that does not match flow signalling being used for admission control. In this case, the e2e ECN traffic is not treated as PCN-traffic. There are two possible scenarios:
a) 不需要PCN准入控制的流量：例如，与用于准入控制的流量信号不匹配的流量。在这种情况下，e2e ECN流量不被视为PCN流量。有两种可能的情况：
* Arriving traffic does not carry a PCN-compatible DSCP: no action required.
* 到达的流量不携带与PCN兼容的DSCP：无需执行任何操作。
* Arriving traffic carries a DSCP that clashes with a PCN-compatible DSCP. There are two options:
* 到达的流量携带与PCN兼容的DSCP冲突的DSCP。有两种选择：
1. The ingress maps the DSCP to a local DSCP with the same scheduling PHB as the original DSCP, and the egress re-maps it to the original PCN-compatible DSCP.
1. 入口将DSCP映射到与原始DSCP具有相同调度PHB的本地DSCP，出口将其重新映射到与PCN兼容的原始DSCP。
2. The ingress tunnels the traffic, setting the DSCP in the outer header to a local DSCP with the same scheduling PHB as the original DSCP.
2. 入口通过隧道传输流量，将外部报头中的DSCP设置为与原始DSCP具有相同调度PHB的本地DSCP。
3. The ingress tunnels the traffic, using the original DSCP in the outer header but setting not-PCN in the outer header; note that this turns off ECN for this traffic within the PCN-domain.
3. 入口通过隧道传输流量，使用外部报头中的原始DSCP，但不在外部报头中设置PCN；请注意，这将关闭PCN域内此流量的ECN。
The first or second options are recommended unless the operator is short of local DSCPs.
建议使用第一个或第二个选项，除非操作员缺少本地DSCP。
b) Traffic that requires admission-control: In this case, the e2e ECN traffic is treated as PCN-traffic across the PCN-domain. There are two options.
b) 需要准入控制的流量：在这种情况下，e2e ECN流量被视为PCN域中的PCN流量。有两种选择。
* The PCN-ingress-node places this traffic in a tunnel with a PCN-compatible DSCP in the outer header. The PCN-egress zeroes the ECN-field before decapsulation.
* PCN入口节点将此流量放置在隧道中，外部报头中有一个与PCN兼容的DSCP。PCN出口在去封装前将ECN字段归零。
* The PCN-ingress-node drops CE-marked packets and otherwise sets the ECN-field to NM and sets the DSCP to a PCN-compatible DSCP. The PCN-egress zeroes the ECN field of all PCN packets; note that this turns off e2e ECN.
* PCN入口节点丢弃CE标记的数据包，否则将ECN字段设置为NM，并将DSCP设置为与PCN兼容的DSCP。PCN出口将所有PCN分组的ECN字段置零；请注意，这将关闭e2e ECN。
The second option is emphatically not recommended, unless perhaps as a last resort if tunnelling is not possible for some insurmountable reason.
第二种方案是不推荐的，除非可能是由于某些无法克服的原因而无法进行隧道挖掘的最后手段。
c) Traffic that requires PCN admission control where the endpoints ask to see PCN marks: Note that this scheme is currently only a tentative idea.
c) 端点要求查看PCN标记时需要PCN准入控制的流量：请注意，此方案目前只是一个初步设想。
For real-time data generated by an adaptive codec, schemes have been suggested where PCN marks may be leaked out of the PCN-domain so that end hosts can drop to a lower data-rate, thus deferring the need for admission control. Currently, such schemes require further study and the following is for guidance only.
对于由自适应编解码器生成的实时数据，已经提出了一些方案，其中PCN标记可能从PCN域泄漏出去，以便终端主机可以降低数据速率，从而推迟准入控制的需要。目前，此类计划需要进一步研究，以下仅供参考。
The PCN-ingress-node needs to tunnel the traffic as in Figure 2, taking care to comply with [RFC6040]. In this case, the PCN-egress does not zero the ECN field (contrary to the recommendation in Section 5.3), so that the [RFC6040] tunnel egress will preserve any PCN-marking. Note that a PCN-interior-node may change the ECN-field from '10' to '01' (NM to ThM), which would be interpreted by the e2e ECN as a change from ECT(0) into ECT(1). This would not be compatible with the (currently experimental) ECN nonce [RFC3540].
PCN入口节点需要如图2所示通过隧道传输流量，注意遵守[RFC6040]。在这种情况下，PCN出口不会将ECN字段归零（与第5.3节中的建议相反），因此[RFC6040]隧道出口将保留任何PCN标记。请注意，PCN内部节点可能会将ECN字段从“10”更改为“01”（NM更改为ThM），这将被e2e ECN解释为从ECT（0）更改为ECT（1）。这与（目前处于实验阶段的）ECN nonce[RFC3540]不兼容。
Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in MPLS Shim Headers
附录C.IP和MPLS垫片头中PCN标记编码之间的映射示例
This appendix is informative not normative.
本附录为资料性附录，非规范性附录。
The 6 bits of the DS field in the IP header provide for 64 codepoints. When encapsulating IP traffic in MPLS, it is useful to make the DS field information accessible in the MPLS header. However, the MPLS shim header has only a 3-bit traffic class (TC) field [RFC5462] providing for 8 codepoints. The operator has the freedom to define a site-local mapping of the 64 codepoints of the DS field onto the 8 codepoints in the TC field.
IP报头中DS字段的6位提供64个代码点。在MPLS中封装IP流量时，使DS字段信息可以在MPLS报头中访问是非常有用的。然而，MPLS垫片报头只有一个3位流量类别（TC）字段[RFC5462]，提供8个码点。操作员可以自由定义DS字段64个代码点到TC字段8个代码点的站点本地映射。
[RFC5129] describes how ECN markings in the IP header can also be mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129] gives an informative description of how to support PCN in MPLS by extending the way MPLS supports ECN. [RFC5129] was written while PCN specifications were in early draft stages. The following provides a clearer example of a mapping between PCN in IP and in MPLS using the PCN terminology and concepts that have since been specified.
[RFC5129]描述了如何将IP报头中的ECN标记也映射到MPLS TC字段中的代码点。[RFC5129]的附录A详细说明了如何通过扩展MPLS支持ECN的方式来支持MPLS中的PCN。[RFC5129]是在PCN规范处于早期起草阶段时编写的。下面提供了一个更清晰的示例，说明了IP中的PCN与MPLS中的PCN之间的映射，使用了此后指定的PCN术语和概念。
To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n') needs codepoints to be provided in the TC field for all the PCN-marks used. That means, when, for instance, only excess-traffic-marking is used for PCN purposes, the operator needs to define a site-local mapping to two codepoints in the MPLS TC field for IP headers with:
为了在MPLS域中支持PCN，与PCN兼容的DSCP（“DSCP n”）需要在TC字段中为所有使用的PCN标记提供代码点。这意味着，例如，当仅为PCN目的使用过量流量标记时，运营商需要在MPLS TC字段中为IP报头定义到两个代码点的站点本地映射，其中包括：
o DSCP n and NM
o dscpn和NM
o DSCP n and ETM
o DSCPN和ETM
If both excess-traffic-marking and threshold-marking are used, the operator needs to define a site-local mapping to codepoints in the MPLS TC field for IP headers with all three of the 3-in-1 codepoints:
如果使用了过量流量标记和阈值标记，则运营商需要在MPLS TC字段中为IP报头定义一个站点本地映射到所有三合一代码点：
o DSCP n and NM
o dscpn和NM
o DSCP n and ThM
o DSCP n和ThM
o DSCP n and ETM
o DSCPN和ETM
In either case, if the operator wishes to support the same Diffserv PHB but without PCN marking, it will also be necessary to define a site-local mapping to an MPLS TC codepoint for IP headers marked with:
在任何一种情况下，如果运营商希望支持相同的Diffserv PHB，但没有PCN标记，则还需要为标记为以下内容的IP报头定义到MPLS TC码点的站点本地映射：
o DSCP n and not-PCN
o DSCP n而非PCN
The above sets of codepoints are required for every PCN-compatible DSCP. Clearly, given so few TC codepoints are available, it may be necessary to compromise by merging together some capabilities. Guidelines for conserving TC codepoints by allowing non-admission-controlled-traffic to compete with PCN-traffic are given in Appendix B.1 of [RFC5670].
每个PCN兼容DSCP都需要上述代码点集。显然，考虑到可用的TC代码点太少，可能需要通过合并一些功能来折衷。[RFC5670]的附录B.1中给出了通过允许非准入控制流量与PCN流量竞争来保存TC码点的指南。
Appendix D. Rationale for Difference between the Schemes Using One PCN-Marking
附录D.使用一个PCN标记的方案之间差异的基本原理
Readers may notice a difference between the two behaviours in Sections 5.2.3.1 and 5.2.3.2. With only Excess-traffic-marking enabled, an unexpected ThM packet can be re-marked to ETM. However, with only Threshold-marking, an unexpected ETM packet cannot be re-marked to ThM.
读者可能会注意到第5.2.3.1节和第5.2.3.2节中两种行为之间的差异。仅启用过量流量标记时，意外ThM数据包可以重新标记为ETM。但是，仅使用阈值标记时，意外ETM数据包无法重新标记为ThM。
This apparent inconsistency is deliberate. The behaviour with only Threshold-marking keeps to the rule of Section 5.2.1 that ETM is more severe and must never be changed to ThM even though ETM is not a valid marking in this case. Otherwise, implementations would have to allow operators to configure an exception to this rule, which would not be safe practice and would require different code in the data plane compared to the common behaviour.
这种明显的不一致是故意的。只有阈值标记的行为符合第5.2.1节的规定，即ETM更为严重，即使ETM在这种情况下不是有效标记，也不得更改为ThM。否则，实现必须允许操作员配置此规则的异常，这不是安全的做法，并且与常见行为相比，需要在数据平面中使用不同的代码。
Authors' Addresses
作者地址
Bob Briscoe BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK
Bob Briscoe BT B54/77，英国阿达斯特拉尔公园马特勒沙姆希思伊普斯维奇IP5 3RE
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/
Toby Moncaster University of Cambridge Computer Laboratory William Gates Building, J J Thomson Avenue Cambridge CB3 0FD UK
托比蒙卡斯特剑桥大学计算机实验室威廉盖茨大楼J J汤姆逊大道剑桥CB3 0FD英国
EMail: toby.moncaster@cl.cam.ac.uk
EMail: toby.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