Network Working Group T. Moncaster
Request for Comments: 5696 B. Briscoe
Category: Standards Track BT
M. Menth
University of Wuerzburg
November 2009
Network Working Group T. Moncaster
Request for Comments: 5696 B. Briscoe
Category: Standards Track BT
M. Menth
University of Wuerzburg
November 2009
Baseline Encoding and Transport of Pre-Congestion Information
拥塞前信息的基线编码和传输
Abstract
摘要
The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity.
预拥塞通知（PCN）体系结构的目标是保护区分服务域内非弹性流的服务质量（QoS）。它通过在域中的链路上，当通信速率超过某些配置的阈值时，标记属于PCN流的数据包来实现这一点。然后，可以对这些标记进行评估，以确定域距离拥塞有多近。本文档通过重新定义此类域中的显式拥塞通知（ECN）代码点，指定如何将此类标记编码到IP报头中。这里描述的基线编码只提供两种PCN编码状态：未标记和PCN标记。未来可能需要对此编码进行扩展，以提供一个以上级别的标记严重性。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 4
4. Encoding Two PCN States in IP . . . . . . . . . . . . . . . . 4
4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 5
4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 6
4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 7
4.4. PCN-Compatible Diffserv Codepoints . . . . . . . . . . . . 7
4.4.1. Co-Existence of PCN and Not-PCN Traffic . . . . . . . 8
5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 8
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. PCN Deployment Considerations (Informative) . . . . . 11
A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 11
A.2. Rationale for Using ECT(0) for Not-Marked . . . . . . . . 12
Appendix B. Co-Existence of PCN and ECN (Informative) . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 4
4. Encoding Two PCN States in IP . . . . . . . . . . . . . . . . 4
4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 5
4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 6
4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 7
4.4. PCN-Compatible Diffserv Codepoints . . . . . . . . . . . . 7
4.4.1. Co-Existence of PCN and Not-PCN Traffic . . . . . . . 8
5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 8
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. PCN Deployment Considerations (Informative) . . . . . 11
A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 11
A.2. Rationale for Using ECT(0) for Not-Marked . . . . . . . . 12
Appendix B. Co-Existence of PCN and ECN (Informative) . . . . . . 13
The objective of the Pre-Congestion Notification (PCN) architecture [RFC5559] is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. 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. These configured rates are below the rate of the link, thus providing notification before any congestion occurs (hence "Pre-Congestion Notification"). The level of marking allows the boundary nodes to make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows.
预拥塞通知（PCN）体系结构[RFC5559]的目标是以简单、可扩展和健壮的方式保护Diffserv域内非弹性流的服务质量（QoS）。在PCN域中的每个链路上测量PCN流量的总速率，当超过某些配置速率时，会适当标记PCN数据包。这些配置的速率低于链路速率，因此在发生任何拥塞之前提供通知（因此称为“拥塞前通知”）。标记级别允许边界节点决定是否接纳或阻止新的流请求，以及（在异常情况下）是否终止一些现有流，从而保护先前接纳流的QoS。
This document specifies how these PCN-marks are encoded into the IP header by reusing the bits of the Explicit Congestion Notification (ECN) field [RFC3168]. It also describes how packets are identified as belonging to a PCN-flow. Some deployment models require two PCN encoding states, others require more. The baseline encoding described here only provides for two PCN encoding states. However, the encoding can be easily extended to provide more states. Rules for such extensions are given in Section 5.
本文档规定了如何通过重用显式拥塞通知（ECN）字段[RFC3168]的位将这些PCN标记编码到IP报头中。它还描述了如何将数据包标识为属于PCN流。一些部署模型需要两种PCN编码状态，而另一些则需要更多。这里描述的基线编码仅提供两种PCN编码状态。然而，编码可以很容易地扩展以提供更多的状态。第5节给出了此类扩展的规则。
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-capable, 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数据包和PCN标记的使用如[RFC5559]中所定义。本文件中定义了以下附加术语：
o PCN-compatible Diffserv codepoint - a Diffserv codepoint indicating packets for which the ECN field is used to carry PCN-markings rather than [RFC3168] markings.
o PCN兼容区分服务码点-一个区分服务码点，指示ECN字段用于携带PCN标记而非[RFC3168]标记的数据包。
o PCN-marked codepoint - a codepoint that indicates packets that have been marked at a PCN-interior-node using some PCN-marking behaviour [RFC5670]. Abbreviated to PM.
o PCN标记的代码点-一种代码点，表示已使用某些PCN标记行为在PCN内部节点上标记的数据包[RFC5670]。缩写为PM。
o Not-marked codepoint - a codepoint that indicates packets that are PCN-capable but that are not PCN-marked. Abbreviated to NM.
o 未标记的代码点-表示支持PCN但未标记PCN的数据包的代码点。缩写为NM。
o not-PCN codepoint - a codepoint that indicates packets that are not PCN-capable.
o 非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 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 EXP = Experimental
o EXP=实验性
o NM = Not-marked
o NM=未标记
o PCN = Pre-Congestion Notification
o PCN=拥塞前通知
o PM = PCN-marked
o PM=标记的PCN
The PCN encoding states are defined using a combination of the DSCP and ECN fields within the IP header. The baseline PCN encoding closely follows the semantics of ECN [RFC3168]. It allows the encoding of two PCN states: Not-marked and PCN-marked. It also allows for traffic that is not PCN-capable to be marked as such (not-PCN). Given the scarcity of codepoints within the IP header, the baseline encoding leaves one codepoint free for experimental use. The following table defines how to encode these states in IP:
PCN编码状态是使用IP报头中的DSCP和ECN字段的组合来定义的。基线PCN编码严格遵循ECN[RFC3168]的语义。它允许对两种PCN状态进行编码：未标记和PCN标记。它还允许不能标记为PCN（非PCN）的流量。考虑到IP报头中缺少码点，基线编码使一个码点可供实验使用。下表定义了如何在IP中对这些状态进行编码：
+---------------+-------------+-------------+-------------+---------+
| ECN codepoint | Not-ECT | ECT(0) (10) | ECT(1) (01) | CE (11) |
| | (00) | | | |
+---------------+-------------+-------------+-------------+---------+
| DSCP n | not-PCN | NM | EXP | PM |
+---------------+-------------+-------------+-------------+---------+
+---------------+-------------+-------------+-------------+---------+
| ECN codepoint | Not-ECT | ECT(0) (10) | ECT(1) (01) | CE (11) |
| | (00) | | | |
+---------------+-------------+-------------+-------------+---------+
| DSCP n | not-PCN | NM | EXP | PM |
+---------------+-------------+-------------+-------------+---------+
Table 1: Encoding PCN in IP
表1：在IP中编码PCN
In the table above, DSCP n is a PCN-compatible Diffserv codepoint (see Section 4.4) and EXP means available for Experimental use. N.B. we deliberately reserve this codepoint for experimental use only (and not local use) to prevent future compatibility issues.
在上表中，DSCP n是一个PCN兼容的Diffserv码点（见第4.4节）和EXP方法，可供实验使用。注意：我们特意将此代码点保留为实验使用（而非本地使用），以防止将来出现兼容性问题。
The following rules apply to all PCN-traffic:
以下规则适用于所有PCN流量：
o PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint. To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are already defined for use with admission-controlled traffic. Appendix A.1 gives guidance to implementors on suitable DSCPs. Guidelines for mixing traffic types within a PCN-domain are given in [RFC5670].
o PCN流量必须使用与PCN兼容的Diffserv代码点进行标记。为了节省DSCP，应选择已定义用于准入控制流量的Diffserv码点。附录A.1为实施者提供了适用DSCP的指南。[RFC5670]中给出了PCN域内混合流量类型的指南。
o Any packet arriving at the PCN-ingress-node that shares a PCN-compatible DSCP and is not a PCN-packet MUST be marked as not-PCN within the PCN-domain.
o 到达PCN入口节点且共享PCN兼容DSCP且不是PCN数据包的任何数据包必须在PCN域内标记为not PCN。
o If a packet arrives at the PCN-ingress-node with its ECN field already set to a value other than not-ECT, then appropriate action MUST be taken to meet the requirements of [RFC3168]. The simplest appropriate action is to just drop such packets. However, this is a drastic action that an operator may feel is undesirable. Appendix B provides more information and summarises other alternative actions that might be taken.
o 如果数据包到达PCN入口节点时其ECN字段已设置为not ECT以外的值，则必须采取适当措施以满足[RFC3168]的要求。最简单的适当操作就是丢弃这样的数据包。然而，这是一个剧烈的动作，操作员可能会觉得这是不可取的。附录B提供了更多信息，并总结了可能采取的其他替代行动。
[RFC5670] states that any encoding scheme document must specify the required action to take if one of the marking algorithms indicates that a packet needs to be marked. For the baseline encoding scheme, the required action is simply as follows:
[RFC5670]指出，任何编码方案文件都必须指定在其中一种标记算法指示需要标记数据包时所需采取的操作。对于基线编码方案，所需操作如下：
o If a marking algorithm indicates the need to mark a PCN-packet, then that packet MUST have its PCN codepoint set to 11, PCN-marked.
o 如果标记算法指示需要标记PCN数据包，则该数据包的PCN代码点必须设置为11，PCN标记。
A PCN-ingress-node MUST set the Not-marked (10) codepoint on any arriving packet that belongs to a PCN-flow. It MUST set the not-PCN (00) codepoint on all other packets sharing a PCN-compatible Diffserv codepoint.
PCN入口节点必须在属于PCN流的任何到达数据包上设置未标记（10）码点。它必须在共享PCN兼容Diffserv码点的所有其他数据包上设置not PCN（00）码点。
The only valid codepoint transitions within a PCN-interior-node are from NM to PM (which should occur if either meter indicates a need to PCN-mark a packet [RFC5670]) and from EXP to PM. PCN-nodes that only implement the baseline encoding MUST be able to PCN-mark packets that arrive with the EXP codepoint. This should ease the design of experimental schemes that want to allow partial deployment of experimental nodes alongside nodes that only implement the baseline encoding. The following table gives the full set of valid and invalid codepoint transitions.
PCN内部节点内唯一有效的代码点转换是从NM到PM（如果任一仪表指示需要PCN标记数据包[RFC5670]）以及从EXP到PM。仅实现基线编码的PCN节点必须能够对使用EXP码点到达的数据包进行PCN标记。这将简化实验方案的设计，这些方案希望允许在仅实现基线编码的节点旁边部分部署实验节点。下表给出了一整套有效和无效的代码点转换。
+-------------------------------------------------+
| Codepoint Out |
+--------------+-------------+-----------+-----------+-----------+
| Codepoint in | not-PCN(00) | NM(10) | EXP(01) | PM(11) |
+--------------+-------------+-----------+-----------+-----------+
| not-PCN(00) | Valid | Not valid | Not valid | Not valid |
+--------------+-------------+-----------+-----------+-----------+
| NM(10) | Not valid | Valid | Not valid | Valid |
+--------------+-------------+-----------+-----------+-----------+
| EXP(01)* | Not valid | Not valid | Valid | Valid |
+--------------+-------------+-----------+-----------+-----------+
| PM(11) | Not valid | Not valid | Not valid | Valid |
+--------------+-------------+-----------+-----------+-----------+
* This MAY cause an alarm to be raised at a management layer.
See paragraph above for an explanation of this transition.
+-------------------------------------------------+
| Codepoint Out |
+--------------+-------------+-----------+-----------+-----------+
| Codepoint in | not-PCN(00) | NM(10) | EXP(01) | PM(11) |
+--------------+-------------+-----------+-----------+-----------+
| not-PCN(00) | Valid | Not valid | Not valid | Not valid |
+--------------+-------------+-----------+-----------+-----------+
| NM(10) | Not valid | Valid | Not valid | Valid |
+--------------+-------------+-----------+-----------+-----------+
| EXP(01)* | Not valid | Not valid | Valid | Valid |
+--------------+-------------+-----------+-----------+-----------+
| PM(11) | Not valid | Not valid | Not valid | Valid |
+--------------+-------------+-----------+-----------+-----------+
* This MAY cause an alarm to be raised at a management layer.
See paragraph above for an explanation of this transition.
Table 2: Valid and Invalid Codepoint Transitions for PCN-Packets at PCN-Interior-Nodes
表2:PCN内部节点上PCN数据包的有效和无效码点转换
The codepoint transition constraints given here apply only to the baseline encoding scheme. Constraints on codepoint transitions for future experimental schemes are discussed in Section 5.
此处给出的代码点转换约束仅适用于基线编码方案。第5节讨论了未来实验方案的码点转换约束。
A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all packets it forwards out of the PCN-domain. 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 codepoints.
PCN出口节点应在其转发出PCN域的所有数据包上设置not PCN（00）码点。唯一的例外情况是，如果PCN出口节点确定显示PCN域之外的其他代码点不会违反[RFC4774]中给出的指导。例如，如果PCN入口节点已明确通知PCN出口节点该流具有ECN能力，则公开其他代码点可能是安全的。
The exact choice of encoding was dictated by the constraints imposed by existing IETF RFCs, in particular [RFC3168], [RFC4301], and [RFC4774]. One of the tightest constraints was the need for any PCN encoding to survive being tunnelled through either an IP-in-IP tunnel or an IPsec Tunnel. [ECN-TUN] explains this in more detail. The main effect of this constraint is that any PCN-marking has to carry the 11 codepoint in the ECN field since this is the only codepoint that is guaranteed to be copied down into the forwarded header upon decapsulation. An additional constraint is the need to minimise the use of Diffserv codepoints because there is a limited supply of Standards Track codepoints remaining. Section 4.4 explains how we have minimised this still further by reusing pre-existing Diffserv codepoint(s) such that non-PCN-traffic can still be distinguished from PCN-traffic.
编码的确切选择取决于现有IETF RFC施加的约束，特别是[RFC3168]、[RFC4301]和[RFC4774]。最严格的限制之一是，任何PCN编码都需要通过IP-in-IP隧道或IPsec隧道进行隧道传输，才能生存下来。[ECN-TUN]对此进行了更详细的解释。该约束的主要影响是，任何PCN标记都必须在ECN字段中携带11个码点，因为这是唯一保证在解除封装后复制到转发报头中的码点。另一个限制是需要尽量减少Diffserv码点的使用，因为剩余的标准跟踪码点供应有限。第4.4节解释了我们是如何通过重用预先存在的Diffserv码点来进一步减少这种情况的，这样非PCN流量仍然可以与PCN流量区分开来。
There are a number of factors that were considered before choosing to set 10 as the NM state instead of 01. These included similarity to ECN, presence of tunnels within the domain, leakage into and out of the PCN-domain, and incremental deployment (see Appendix A.2).
在选择将10设置为NM状态而不是01之前，考虑了许多因素。这些包括与ECN的相似性、域内隧道的存在、流入和流出PCN域的泄漏以及增量部署（见附录A.2）。
The encoding scheme above seems to meet all these constraints and ends up looking very similar to ECN. This is perhaps not surprising given the similarity in architectural intent between PCN and ECN.
上面的编码方案似乎满足所有这些约束条件，最终看起来与ECN非常相似。考虑到PCN和ECN在架构意图上的相似性，这也许并不奇怪。
Equipment complying with the baseline PCN encoding MUST allow PCN to be enabled for certain Diffserv codepoints. This document defines the term "PCN-compatible Diffserv codepoint" for such a DSCP. To be clear, any packets with such a DSCP will be PCN-enabled only if they are within a PCN-domain and have their ECN field set to indicate a codepoint other than not-PCN.
符合基线PCN编码的设备必须允许对某些区分服务代码点启用PCN。本文件为此类DSCP定义了术语“PCN兼容区分服务代码点”。需要明确的是，任何具有此类DSCP的数据包只有在其位于PCN域内且其ECN字段设置为指示非PCN的代码点时，才会启用PCN。
Enabling PCN-marking behaviour for a specific DSCP disables any other marking behaviour (e.g., enabling PCN replaces the default ECN marking behaviour introduced in [RFC3168]) with the PCN-metering and -marking behaviours described in [RFC5670]). This ensures compliance with the Best Current Practice (BCP) guidance set out in [RFC4774].
为特定DSCP启用PCN标记行为将禁用任何其他标记行为（例如，启用PCN将[RFC3168]中引入的默认ECN标记行为替换为[RFC5670]中描述的PCN计量和标记行为）。这确保符合[RFC4774]中规定的最佳现行做法（BCP）指南。
The PCN working group has chosen not to define a single DSCP 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
PCN工作组出于几个原因选择不定义一个DSCP用于PCN。首先，PCN机制适用于各种不同的流量类别。其次，标准轨道DSCP的供应日益短缺。第三，PCN不是一种调度行为——相反，它应该被视为
essentially a marking behaviour similar to ECN but intended for inelastic traffic. More details are given in the informational Appendix A.1.
本质上是一种类似于ECN的标记行为，但用于非弹性交通。更多详情见信息性附录A.1。
The scarcity of pool 1 DSCPs, coupled with the fact that PCN is envisaged as a marking behaviour that could be applied to a number of different DSCPs, makes it essential that we provide a not-PCN state. As stated above (and expanded in Appendix A.1), the aim is for PCN to re-use existing DSCPs. Because PCN redefines the meaning of the ECN field for such DSCPs, it is important to allow an operator to still use the DSCP for non-PCN-traffic. This is achieved by providing a not-PCN state within the encoding scheme. Section 3.5 of [RFC5559] discusses how competing-non-PCN-traffic should be handled.
池1 DSCP的稀缺性，加上PCN被设想为一种可应用于许多不同DSCP的标记行为，使得我们必须提供一个非PCN状态。如上所述（并在附录A.1中扩展），PCN的目标是重新使用现有的DSCP。由于PCN重新定义了此类DSCP的ECN字段的含义，因此允许运营商仍将DSCP用于非PCN流量是很重要的。这是通过在编码方案中提供not PCN状态来实现的。[RFC5559]第3.5节讨论了如何处理竞争性非PCN流量。
Any experimental encoding scheme MUST follow these rules to ensure backward compatibility with this baseline scheme:
任何实验性编码方案必须遵循以下规则，以确保与此基线方案向后兼容：
o All PCN-interior-nodes within a PCN-domain MUST interpret the 00 codepoint in the ECN field as not-PCN and MUST NOT change it to another value. Therefore, a PCN-ingress-node wishing to disable PCN-marking for a packet with a PCN-compatible Diffserv codepoint MUST set the ECN field to 00.
o PCN域中的所有PCN内部节点必须将ECN字段中的00代码点解释为非PCN，并且不得将其更改为其他值。因此，PCN入口节点希望对具有PCN兼容Diffserv代码点的数据包禁用PCN标记，必须将ECN字段设置为00。
o The 11 codepoint in the ECN field MUST indicate that the packet has been PCN-marked as the result of one or both of the meters indicating a need to PCN-mark a packet [RFC5670]. The experimental scheme MUST define which meter(s) trigger this marking.
o ECN字段中的11代码点必须表明，数据包已被PCN标记为一个或两个仪表的结果，表明需要对数据包进行PCN标记[RFC5670]。实验方案必须定义触发该标记的仪表。
o The 01 Experimental codepoint in the ECN field MAY mean PCN-marked or it MAY carry some other meaning. However, any experimental scheme MUST define its meaning in the context of that experiment.
o ECN字段中的01实验代码点可能意味着标记了PCN，也可能具有其他含义。然而，任何实验方案都必须在该实验的背景下定义其含义。
o If both the 01 and 11 codepoints are being used to indicate PCN-marked, then the 11 codepoint MUST be taken to be the more severe marking and the choice of which meter sets which mark MUST be defined.
o 如果01和11个代码点都用于指示标记的PCN，则必须将11个代码点视为更严重的标记，并且必须定义哪个仪表设置哪个标记。
o Once set, the 11 codepoint in the ECN field MUST NOT be changed to any other codepoint.
o 一旦设置，ECN字段中的11码点不得更改为任何其他码点。
o Any experimental scheme MUST include details of all valid and invalid codepoint transitions at any PCN-nodes.
o 任何实验方案都必须包括任何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 co-existence of default ECN and alternative ECN semantics. The baseline encoding specified in this document defines PCN-compatible Diffserv codepoints as no longer supporting the default ECN semantics. As such, this document is compatible with BCP 124.
BCP 124[RFC4774]给出了为ECN字段指定替代语义的指南。它列出了一些需要考虑的因素。它还建议使用各种技术来允许默认ECN和备选ECN语义共存。本文档中指定的基线编码将PCN兼容的Diffserv代码点定义为不再支持默认ECN语义。因此，本文件与BCP 124兼容。
On its own, this baseline encoding cannot support both ECN marking end-to-end (e2e) and PCN-marking within a PCN-domain. It is possible to do this by carrying e2e ECN across a PCN-domain within the inner header of an IP-in-IP tunnel, or by using a richer encoding such as the proposed experimental scheme in [PCN-ENC].
就其自身而言，此基线编码不能同时支持PCN域内的端到端（e2e）ECN标记和PCN标记。可以通过在IP-in-IP隧道的内部报头内跨PCN域携带e2e ECN，或者通过使用更丰富的编码（如[PCN-ENC]中提出的实验方案）来实现这一点。
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 PCN codepoint. PCN-egress-nodes then guarantee that the ECN field of any packet leaving the PCN-domain has the correct ECN semantics. This prevents unintended leakage of ECN marks into or out of the PCN-domain, and thus reduces backward-compatibility issues.
在任何PCN部署中，流量只能通过PCN入口节点进入PCN域，并通过PCN出口节点离开。PCN入口节点确保进入PCN域的任何数据包的最外层IP报头中的ECN字段设置为相应的PCN码点。然后，PCN出口节点保证离开PCN域的任何数据包的ECN字段具有正确的ECN语义。这可以防止ECN标记意外泄漏到PCN域或从PCN域泄漏出去，从而减少向后兼容性问题。
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 behaviour schemes is used, but 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
一个潜在的安全问题是向PCN域中注入虚假的PCN标记。但是，只有当PCN入口节点配置错误时，这些节点才能进入域。任何此类错误配置的确切影响将取决于使用了哪种建议的PCN边界节点行为方案，但一般而言，虚假标记将导致允许较少的流进入域或可能终止过多的流。在任何一种情况下，良好的管理都应该
be able to quickly spot the problem since the overall utilisation of the domain will rapidly fall.
能够快速发现问题，因为该领域的整体利用率将迅速下降。
This document defines the baseline PCN encoding, utilising a combination of a PCN-compatible DSCP and the ECN field in the IP header. This baseline encoding allows the existence of two PCN encoding states: Not-marked and PCN-marked. It also allows for the co-existence of competing traffic within the same DSCP, so long as that traffic does not require ECN support within the PCN-domain. The encoding scheme is conformant with [RFC4774]. The working group has chosen not to define a single DSCP for use with PCN. The rationale for this decision along with advice relating to the choice of suitable DSCPs can be found in Appendix A.1.
本文档使用PCN兼容DSCP和IP报头中的ECN字段的组合来定义基准PCN编码。此基线编码允许存在两种PCN编码状态：未标记和PCN标记。它还允许同一DSCP内竞争流量共存，只要该流量不需要PCN域内的ECN支持。编码方案符合[RFC4774]。工作组选择不定义用于PCN的单一DSCP。该决定的理由以及与选择合适的DSCP相关的建议见附录A.1。
This document builds extensively on work done in the PCN working group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Anna Charny, Joe Babiarz, and others. Thanks to Ruediger Geib and Gorry Fairhurst for providing detailed comments on this document.
本文件以郭浩灿、乔治奥斯·卡拉吉安尼斯、菲利普·埃尔德利、安娜·查尼、乔·巴比亚兹和其他人在PCN工作组中所做的工作为基础。感谢Ruediger Geib和Gorry Fairhurst对本文件的详细评论。
[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月。
[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月。
[RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670]Eardley，P.，Ed.“PCN节点的计量和标记行为”，RFC 56702009年11月。
[ECN-TUN] Briscoe, B., "Tunnelling of Explicit Congestion Notification", Work in Progress, July 2009.
[ECN-TUN]Briscoe，B.，“明确拥塞通知的隧道挖掘”，正在进行的工作，2009年7月。
[PCN-ENC] Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding using 2 DSCPs to provide 3 or more states", Work in Progress, April 2009.
[PCN-ENC]Moncaster，T.，Briscoe，B.，和M.Minth，“使用2个DSCP提供3个或更多状态的PCN编码”，正在进行的工作，2009年4月。
[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月。
[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月。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[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月。
[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月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559]Eardley，P.，“拥塞前通知（PCN）体系结构”，RFC555592009年6月。
Appendix A. PCN Deployment Considerations (Informative)
附录A.PCN部署注意事项（资料性）
The PCN working group chose not to define a single DSCP 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]. The PCN working group suggests using admission control for the following service classes (defined in [RFC4594]):
PCN工作组出于几个原因选择不定义一个DSCP用于PCN。首先，PCN机制适用于各种不同的流量类别。其次，标准轨道DSCP的供应日益短缺。第三，PCN不是一种调度行为——相反，它应该被视为一种类似于ECN的标记行为，但用于非弹性流量。选择哪个DSCP最适合给定PCN域取决于进入该域的流量的性质以及构成该域的所有链路的链路速率。在聚合充分的PCN域中，适当的DSCP当前将是用于实时处理聚合的DSCP[RFC5127]。PCN工作组建议对以下服务类别（定义见[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）
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]。
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作为其选择机制。
The choice of which ECT codepoint to use for the Not-marked state was based on the following considerations:
选择用于未标记状态的ECT代码点基于以下考虑：
o [RFC3168] full-functionality tunnel within the PCN-domain: Either ECT is safe.
o [RFC3168]PCN域内的全功能隧道：任一ECT都是安全的。
o Leakage of traffic into PCN-domain: Because of the lack of take-up of the ECN nonce [RFC3540], leakage of ECT(1) is less likely to occur and so might be considered safer.
o 流入PCN域的流量泄漏：由于ECN nonce[RFC3540]的占用不足，ECT（1）的泄漏不太可能发生，因此可能被认为更安全。
o Leakage of traffic out of PCN-domain: Either ECT is equally unsafe (since this would incorrectly indicate the traffic was ECN-capable outside the controlled PCN-domain).
o 从PCN域泄漏流量：任何一个ECT都同样不安全（因为这将错误地表明流量在受控PCN域之外具有ECN能力）。
o Incremental deployment: Either codepoint is suitable, providing that the codepoints are used consistently.
o 增量部署：任何一个代码点都是合适的，只要代码点的使用是一致的。
o Conceptual consistency with other schemes: ECT(0) is conceptually consistent with [RFC3168].
o 与其他方案的概念一致性：ECT（0）在概念上与[RFC3168]一致。
Overall, this seemed to suggest that ECT(0) was most appropriate to use.
总的来说，这似乎表明ECT（0）最适合使用。
Appendix B. Co-Existence of PCN and ECN (Informative)
附录B.PCN和ECN共存（资料性）
This baseline encoding scheme redefines the ECN codepoints within the PCN-domain. As packets with a PCN-compatible DSCP leave the PCN-domain, their ECN field is reset to not-ECT (00). This is a problem for the operator if packets with a PCN-compatible DSCP arrive at the PCN-domain with any ECN codepoint other than not-ECN. If the ECN-codepoint is ECT(0) (10) or ECT(1) (01), resetting the ECN field to 00 effectively turns off end-to-end ECN. This is undesirable as it removes the benefits of ECN, but [RFC3168] states that it is no worse than dropping the packet. However, if a packet was marked with CE (11), resetting the ECN field to 00 at the PCN egress node violates the rule that CE-marks must never be lost except as a result of packet drop [RFC3168].
此基线编码方案重新定义PCN域内的ECN码点。当具有PCN兼容DSCP的数据包离开PCN域时，其ECN字段将重置为not ECT（00）。如果带有PCN兼容DSCP的数据包到达PCN域时带有除ECN以外的任何ECN码点，这对运营商来说是一个问题。如果ECN代码点为ECT（0）（10）或ECT（1）（01），则将ECN字段重置为00将有效关闭端到端ECN。这是不可取的，因为它消除了ECN的好处，但[RFC3168]指出，这并不比丢弃数据包更糟糕。但是，如果数据包被标记为CE（11），则在PCN出口节点处将ECN字段重置为00违反了CE标记不得丢失的规则，除非由于数据包丢失[RFC3168]。
A number of options exist to overcome this issue. The most appropriate option will depend on the circumstances and has to be a decision for the operator. The definition of the action is beyond the scope of this document, but we briefly explain the four broad categories of solution below: tunnelling the packets, using an extended encoding scheme, signalling to the end systems to stop using ECN, or re-marking packets to a different DSCP.
为了克服这个问题，有许多选择。最合适的选择取决于具体情况，必须由运营商决定。该操作的定义超出了本文档的范围，但我们在下面简要解释了四大类解决方案：隧道传输数据包、使用扩展编码方案、向终端系统发送停止使用ECN的信号，或将数据包重新标记到不同的DSCP。
o Tunnelling the packets across the PCN-domain (for instance, in an IP-in-IP tunnel from the PCN-ingress-node to the PCN-egress-node) preserves the original ECN marking on the inner header.
o 通过PCN域隧道传输数据包（例如，在从PCN入口节点到PCN出口节点的IP-in-IP隧道中）保留内部报头上的原始ECN标记。
o An extended encoding scheme can be designed that preserves the original ECN codepoints. For instance, if the PCN-egress-node can determine from the PCN codepoint what the original ECN codepoint was, then it can reset the packet to that codepoint. [PCN-ENC] partially achieves this but is unable to recover ECN markings if the packet is PCN-marked in the PCN-domain.
o 可以设计一种保留原始ECN码点的扩展编码方案。例如，如果PCN出口节点可以从PCN码点确定原始ECN码点是什么，那么它可以将数据包重置为该码点。[PCN-ENC]部分实现了这一点，但如果数据包在PCN域中有PCN标记，则无法恢复ECN标记。
o Explicit signalling to the end systems can indicate to the source that ECN cannot be used on this path (because it does not support ECN and PCN at the same time). Dropping the packet can be thought of as a form of silent signal to the source, as it will see any ECT-marked packets it sends being dropped.
o 到终端系统的显式信令可以向源指示ECN不能在此路径上使用（因为它不同时支持ECN和PCN）。丢弃数据包可以被认为是发送给源的静默信号的一种形式，因为它将看到它发送的任何带有ECT标记的数据包被丢弃。
o Packets that are not part of a PCN-flow but which share a PCN-compatible DSCP can be re-marked to a different local-use DSCP at the PCN-ingress-node with the original DSCP restored at the PCN-egress. This preserves the ECN codepoint on these packets but relies on there being spare local-use DSCPs within the PCN-domain.
o 不属于PCN流但共享PCN兼容DSCP的数据包可以在PCN入口节点处重新标记为不同的本地使用DSCP，并在PCN出口处恢复原始DSCP。这保留了这些数据包上的ECN码点，但依赖于PCN域中存在备用的本地使用DSCP。
Authors' Addresses
作者地址
Toby Moncaster BT B54/70, Adastral Park Martlesham Heath Ipswich IP5 3RE UK
托比·蒙卡斯特BT B54/70，英国阿达斯特拉尔公园马特勒沙姆希思伊普斯维奇IP5 3RE
Phone: +44 7918 901170
EMail: toby.moncaster@bt.com
Phone: +44 7918 901170
EMail: toby.moncaster@bt.com
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
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
Michael Menth University of Wuerzburg Institute of Computer Science Am Hubland Wuerzburg D-97074 Germany
维尔茨堡米迦勒大学蒙特大学计算机科学研究院维尔茨堡分校D—97074德国
Phone: +49 931 318 6644
EMail: menth@informatik.uni-wuerzburg.de
Phone: +49 931 318 6644
EMail: menth@informatik.uni-wuerzburg.de