[要約] RFC 6660は、IPヘッダー内の1つのDiffservコードポイント（DSCP）を使用して、3つのPre-Congestion Notification（PCN）状態をエンコードする方法について説明しています。このRFCの目的は、ネットワークの混雑状態を通知するための効果的な方法を提供することです。
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ヘッダー内の3つの輻輳前通知（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）の目的は、Diffservドメイン内の非弾性フローのサービス品質（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ワイヤプロトコルは、他の場所で定義する必要があります。それにもかかわらず、このドキュメントでは、情報付録でMPLSのPCNエンコーディングを明確にしています。 IPのエンコーディングは、単一のDiffservコードポイント（DSCP）を使用して、最大3つの異なるPCNマーキング状態を提供します：マークなし（NM）、しきい値マーク（ThM）、および超過トラフィックマーク（ETM）。したがって、3-in-1 PCNエンコーディングと呼ばれます。このドキュメントはRFC 5696を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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").
Pre-Congestion Notification（PCN）[RFC5559]の目的は、Diffservドメイン内の非弾性フローのサービス品質（QoS）をシンプルでスケーラブルで堅牢な方法で保護することです。 2つのメカニズムが使用されます。新しいフロー要求を許可するかブロックするかを決定するアドミッション制御と、深刻な事前輻輳時に既存のフローを終了するフロー終了です。これを実現するために、ドメイン内のすべてのリンクで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]は、一般に異なる参照レートで構成されている2つの計測およびマーキング機能を提供します。しきい値マーキングは、リンク上のトラフィックレートが設定された参照レート（PCN-threshold-rate）を超えると、すべてのPCNパケットにマークを付けます。 Excess-traffic-markingは、設定された参照レート（PCN-excess-rate）を超える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]で定義されたエンコーディングは、2つのPCNマーキング状態（マークなしとPCNマーク付き）を単一のDiffservコードポイントを使用してIPヘッダーにエンコードする方法を説明しました。それは、'01 'を実験的なコードポイント（EXP）として定義し、その使用に関するガイドラインも示しました。単一のマーキングエッジ動作[RFC6662]には、2つのPCNマーキング状態で十分です。ただし、制御された負荷エッジ動作[RFC6661]を利用するPCNドメインには、3つのPCNマーキング状態が必要です。このドキュメントは、RFC 5696で最初に出現したエンコーディングを拡張して、実験的なコードポイントをIPヘッダーの3番目のPCNマーキング状態として再定義しますが、単一のDiffservコードポイントを使用します。したがって、このエンコード方式は「3-in-1 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 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.
3-in-1エンコーディングのフルバージョンでは、[RFC6040]で定義されている通常のトンネリングルールをサポートするために、PCNドメイン内のトンネルエンドポイントが必要です。 PCNドメインが超過トラフィックマーキング動作のみを使用し、しきい値マーキング動作が非アクティブ化されている場合、この制約には1つの限定的な例外があります。これについては、セクション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.
このドキュメントは、IPv4であれIPv6であれ、IPヘッダーのPCNワイヤプロトコルエンコーディングのみに関係しています。輻輳マーキングまたは輻輳応答のアルゴリズムに関する変更や推奨は行いません。他のドキュメントでは、他のヘッダータイプのPCNワイヤプロトコルを定義します。付録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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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互換のDiffservコードポイント：ECNフィールドが[RFC3168]マーキングではなくPCNマーキングを運ぶパケットを示すDiffservコードポイント。オペレーターは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.
超過トラフィックマーク付きコードポイント：超過トラフィックメータリング機能[RFC5670]からの指示の結果として、PCN内部ノードでマークされたパケットを示すコードポイント。 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 = Diffservコードポイント
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.
3-in-1 PCNエンコーディングスキームは、IPヘッダー内で3つのPCNマーキング状態をエンコードする必要があるネットワークと、2つだけが必要なネットワークをサポートします。完全なエンコードを図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 |
+--------+--------------+-------------+-------------+---------+
Figure 1: 3-in-1 PCN Encoding
図1：3-in-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ノードは、[RFC3168]ではなく、3-in-1 PCNエンコーディングを使用してPCNパケットのECNフィールドを解釈する必要があります。これにより、PCN互換ではないDSCPを持つパケット、またはPCNドメイン外のノードの動作は変更されません。このような場合はすべて、3-in-1エンコーディングは適用されないため、デフォルトでは、ノードは[RFC3168]を使用してECNフィールドを解釈します。
When using the 3-in-1 encoding, the codepoints of the ECN field have the following meanings:
3-in-1エンコーディングを使用する場合、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.
not-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-ingress-nodesはPCNドメインに入るパケットを制御します。 PCN制御フローに属するパケットは、PCNメータリングとPCNマーキングの対象となり、PCN-ingress-nodeはそれらを非マーキング（PCN-カラーリング）としてマークします。 PCNドメイン内のすべてのノードは、必要に応じてPCNメータリングとPCNマークPCNパケットを実行します。計測とマーキングの動作には、しきい値マーキングと過剰トラフィックマーキングの2種類があります[RFC5670]。エッジの動作には、シングルマーキング動作のみが必要なもの[RFC6662]と、両方が必要なもの[RFC6661]があります。後者の場合、3つのPCNマーキング状態が必要です。マークされていないパケットを示す非マーク（NM）、しきい値マーカーによってマークされたパケットを示すしきい値マーク（ThM）、および超過トラフィックマーク（ETM）超過トラフィックマーカー[RFC5670]によってマークされたパケットを示します。しきい値マーキングと超過トラフィックマーキングは、異なる負荷条件でパケットのマーキングを開始するように設定されているため、1つのマーキング動作が他のマーキング動作よりも深刻な事前輻輳を示しています。したがって、パケットが両方のマーカーによってマークされていることを示す4番目のPCNマーキング状態は必要ありません。ただし、PCN互換のDSCPを使用するが、PCNマーキングを使用しないパケット（非PCNコードポイント）を示すには、4番目のコードポイントが必要です。
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.
2つのマーキング動作[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-in-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トラフィックを保護するために、3-in-1コードポイントの重大度の順序が選択されました。従来のRFC6040以前のトンネルは「01」を伝播しませんでしたが、RFC6040以前およびRFC6040以降のすべてのトンネルは常に「11」を正しく伝播していました。したがって、最も深刻な事前輻輳（ETM）を通知するために「11」が選択されたため、見落とされたレガシートンネルが「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).
3-in-1エンコーディングは、PCNドメインで2つのマーキング動作が使用されている状況に適用できます。 3-in-1エンコーディングは、1つのマーキング動作のみで使用することもできます。その場合、コードポイントの1つを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).
1つの例外（次の段落を参照）を除き、PCNドメイン内のトンネルエンドポイント（IP-in-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-in-1エンコーディングの限定バージョンは引き続き使用できますが、次の厳しい条件下でのみ使用できます。 RFC6040より前のトンネルカプセル化解除装置がPCNドメイン内に存在する場合、PCNドメイン内のすべてのPCNノードは、ThMコードポイントを設定しないように構成する必要があります。この場合のPCN-interior-nodeは、セクション5.2.3.1で定義されているように、Excess-traffic-marking関数のみを使用する必要があります。 PCNドメイン内にレガシートンネルカプセル化解除装置が存在する可能性がある他のすべての状況では、3-in-1エンコーディングは適用されません。
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ドメインから到着する場合、Diffservコードポイントの再マッピングは、PCN入力処理の前に行わなければなりません（MUST）。
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 section describes these four steps, but only the aspects relevant to packet encoding:
PCNドメインへの各論理入力リンクで、各PCN-ingress-nodeは[RFC5559]のセクション4.2で説明されている4つの機能を到着パケットに適用します。これらの関数は、PCN分類、PCNポリス、PCNカラー、PCNレートメーターの順に適用されます。このセクションでは、これらの4つのステップについて説明しますが、パケットエンコーディングに関連する側面のみを説明します。
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-ingress-nodeは、各パケットが許可されたフローのフィルター仕様と一致するかどうかを決定します。一致するパケットは、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フィールドがNot-ECT以外の値に既に設定されている場合（つまり、ECN対応のトランスポートからのもの）、BCPに準拠する124 [RFC4774] PCNポリシングおよびPCNカラーリングのステップの前に、次の準備ステップの1つを通過する必要があります。これらの4つのアクションの選択は、ローカルポリシーによって異なります。
* 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).
+ または、MPLSなどのPCNマークを付けることができる下位層プロトコル内（付録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トンネリングを使用する必要があります（SHOULD）。
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カプセル化が使用されている場合、最後から2番目のホップのポップ[RFC3031]は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-ingress-nodeはカプセル化なしでECN対応パケットを許可できますが、この段階ではCEマーク付きパケットをドロップする必要があります。カプセル化なしでは、PCNドメイン全体にCEマーキングを伝播するメカニズムがないため、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.
PCN-egress-nodeがECNフィールドをゼロにするとe2e 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パケットは、到着時に次の3つの条件をすべて満たす場合、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フィールドには、Not-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-ingress-nodeは、次のいずれかの処理を行うことにより、3つの条件すべて（a-c）を満たすパケットをポリシングする必要があります。
* re-mark the DSCP to a DSCP that is not PCN-compatible;
* PCN互換ではないDSCPに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-egress-nodeにトンネルします。または
* 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-ingress-nodeはイベントをログに記録する必要があり（SHOULD）、アラームも発生させることができます（MAY）。異常なパケットが大量のアラームメッセージに増幅されないように、アラームはレート制限する必要があります。
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.
根拠：上記の3つの条件（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-ingress-node：
* 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を選択する必要があります（SHOULD）。付録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レートメータリング：この4番目のステップは、有効なエッジの動作に応じて必要になる場合があります。完全を期すためにリストされていますが、このエンコーディングドキュメントには関係ありません。
Interior nodes MUST NOT change not-PCN to any other codepoint.
内部ノードはnot-PCNを他のコードポイントに変更してはなりません（MUST NOT）。
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またはnot-PCNに変更してはなりません。
Interior nodes MUST NOT change ETM to any other codepoint.
内部ノードはETMを他のコードポイントに変更してはなりません（MUST NOT）。
If the threshold-meter function indicates a need to mark a packet, the PCN-interior-node MUST change NM to ThM.
しきい値メーター機能がパケットをマークする必要があることを示す場合、PCN-interior-nodeは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-interior-nodeはNMをETMに変更する必要があります。
o the PCN-interior-node MUST change ThM to ETM.
o PCN-interior-nodeは、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ドメイン内で1つのPCNマーキングのみが必要です。単一のマーキングエッジ動作[RFC6662]では、超過トラフィックメーター機能[RFC5670]を使用してパケットをマークするためにPCN内部ノードが必要です。将来のスキームでは、しきい値メーター機能のみが必要になる可能性があります。付録Dでは、このセクションで定義されている動作の根拠について説明します。
The threshold-traffic-meter function SHOULD be disabled and MUST NOT trigger any packet marking.
しきい値トラフィックメーター機能は無効にする必要があり（SHOULD）、パケットマーキングをトリガーしてはなりません（MUST NOT）。
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パケットを受信した場合に管理アラームを発生させる必要があります（SHOULD）が、そのようなアラームの頻度は制限する必要があります（SHOULD）。
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-interior-nodeはNMをETMに変更する必要があります。
o the PCN-interior-node MUST change ThM to ETM. It SHOULD also raise an alarm as above.
o PCN-interior-nodeは、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.
PCN内部ノードは、ETMパケットを受信した場合に管理アラームを発生させる必要があります（SHOULD）が、そのようなアラームの頻度は制限する必要があります（SHOULD）。
If the threshold-meter function indicates a need to mark the packet:
しきい値メーター機能がパケットをマークする必要があることを示している場合：
o the PCN-interior-node MUST change NM to ThM;
o PCN-interior-nodeは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-interior-nodeはETMを他のコードポイントに変更してはなりません（MUST NOT）。 ETMパケットに遭遇した場合、上記のようにアラームを発生させる必要があります。
A PCN-egress-node SHOULD set the not-PCN ('00') codepoint on all packets it forwards out of the PCN-domain.
PCN-egress-nodeは、PCNドメインから転送するすべてのパケットにnot-PCN（ '00'）コードポイントを設定する必要があります（SHOULD）。
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-egress-nodeがPCNドメインの外部の他のコードポイントを明らかにしても[RFC4774]で提供されているガイダンスに違反しないことが確実な場合です。たとえば、PCN-ingress-nodeがこのフローがECN対応であることをPCN-egress-nodeに明示的に通知した場合、他の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-egress-nodeはThMをETMとして扱う必要があります。しきい値マーキングのみを使用する場合は、ETMをThMとして扱う必要があります（SHOULD）。ただし、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セマンティクスの共存を可能にするさまざまな手法も提案しています。このドキュメントで指定されているエンコーディングは、これらの手法の1つを使用しています。 PCNドメイン内のデフォルトのECNセマンティクスをサポートしないため、PCN互換のDiffservコードポイントを定義します。そのため、このドキュメントは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.
PCNドメイン内のECNマーキングのエンドツーエンドマーキングとPCNマーキングの両方をサポートするために、3-in-1エンコーディング用の1つのIPヘッダーに十分なスペースがありません。非規範的な付録Bでは、たとえば、IP-in-IPトンネルの内部ヘッダー内のPCNドメイン全体でe2e ECNを伝送することによって、これを行うための可能な方法について説明します。セクション5.1の規範的なテキストでは、これらの方法のいずれかをPCN-ingress-nodeで構成する必要があり、実装がデフォルトとしてトンネリングを提供することを推奨しています。
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-ingress-nodesを介してのみPCN-domainに入り、PCN-egress-nodesを介して去ることができます。 PCN-ingress-nodesは、PCN-domainに入るすべてのパケットが、適切なコードポイントに設定された最も外側の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-egress-nodesは、PCNドメインを出るパケットのECNフィールドが適切なECNセマンティクスを持つことを保証します。これにより、PCNドメインへの、またはPCNドメインからのECNマークの意図しない漏洩が防止され、下位互換性の問題が軽減されます。
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アーキテクチャのセクション5.1 [RFC5559]は、潜在的な障害の初期兆候を検出するために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-in-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.
セキュリティに関する潜在的な懸念の1つは、PCNドメインへの偽のPCNマークの挿入です。ただし、これらは、PCN-ingress-nodeが正しく構成されていない場合にのみドメインに入ることができます。このような構成ミスの正確な影響は、提案されている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].
3-in-1 PCNエンコードでは、PCN互換のDSCPとECNフィールドを使用してPCNマークをエンコードします。 1つのコードポイントにより、非PCNトラフィックを同じPCN互換のDSCPで伝送することができ、他の3つのコードポイントは、重大度のレベルが異なる3つの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、Kwok Ho Chan、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、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、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]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559] Eardley、P。、「Pre-Congestion Notification（PCN）Architecture」、RFC 5559、2009年6月。
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670] Eardley、P。、「PCNノードの測定とマーキングの動作」、RFC 5670、2009年11月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、2010年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、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年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]デイビー、B、チャーニー、A、ベネット、J、ベンソン、K、ルブーデック、J、コートニー、W、ダヴァリ、S、フィロイ、V、およびDスティリアディス、 Expedited Forwarding PHB（Per-Hop Behavior）」、RFC 3246、2002年3月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540] Spring、N.、Wetherall、D。、およびD. Ely、「Ronce Explicit Congestion Notification（ECN）Signaling with Nonces」、RFC 3540、2003年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、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、2006年8月。
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, November 2006.
[RFC4774]フロイド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、「Aggregation of Diffserv Service Classs」、RFC 5127、2008年2月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129]デイビー、B。、ブリスコー、B。、およびJ.テイ、「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、「Multiprotocol Label Switching（MPLS）Label Stack Entry： "EXP" Renamed to "Traffic Class" Field」、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]モンカスター、T。、ブリスコー、B。、およびM.メンス、「ベースラインエンコーディングと事前輻輳情報の転送」、RFC 5696、2009年11月。
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010.
[RFC5865]ベイカー、F。、ポーク、J。、およびM.ドリー、「Capacity-Admitted TrafficのDiffServコードポイント（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、「Over-Pre-Congestion Notification Encoding」、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.、Meth、M。、およびT. Taylor、編、「制御負荷（CL）の事前輻輳通知（PCN）境界ノードの動作動作モード」、RFC 6661、2012年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.、Meth、M。、およびT. Taylor、編、「シングルマーキング（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メカニズムはさまざまな異なるトラフィッククラスに適用できます。第二に、Standards Track DSCPはますます不足しています。第3に、PCNはスケジューリング動作ではありません。むしろ、ECNと同様のマーキング動作と見なされますが、非弾性トラフィックを対象としています。特定のPCNドメインに最も適したDSCPの選択は、そのドメインに入るトラフィックの性質と、そのドメインを構成するすべてのリンクのリンク速度に依存します。十分な集約があるPCNドメインでは、適切な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]で定義されたVOICE-ADMITコードポイント。
CS5 is excluded from this list since PCN is not expected to be applied to signalling traffic.
PCNはシグナリングトラフィックに適用されないため、CS5はこのリストから除外されています。
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トラフィックが1つのDSCPによって必ず識別されることを意味するわけではありません。各サービスクラスは、高度に集約された領域[RFC5127]内に異なるDSCPを保持する可能性があります。
Guidelines for conserving DSCPs by allowing non-admission-controlled-traffic to compete with PCN-traffic are given in Appendix B.1 of [RFC5670].
アドミッション制御されていないトラフィックをPCNトラフィックと競合させることによってDSCPを節約するためのガイドラインは、[RFC5670]の付録B.1に記載されています。
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-ingress-nodeに到着する可能性のある2つの形式のトラフィックを定義します。これらは、アドミッション制御トラフィック（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).
フローシグナリングは、フィルター仕様をアドミッション制御の必要性に関連付けることにより、アドミッション制御トラフィックを識別します（たとえば、SIPサーバーから入力への、または論理的に集中化されたネットワーク制御システムからのRSVPまたは同等のメッセージを介して）。 PCN-ingress-nodeは、フィルター仕様をPCN互換のDSCPに一致させるアドミッション制御トラフィックを再マーキングします。 「フロー」という用語は、1つのマイクロフローだけを意味する必要はありませんが、代わりに集合体と一致したり、着信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 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.
特に明記されていない限り、以下のリストのいずれの場合でも、[RFC6040]に準拠するIP-in-IPトンネルを使用して、PCNドメイン全体でECNマーキングを保持できます。図2に示すように、トンネリングアクションは完全にPCNドメインの外側に適用する必要があります。その後、RFC 6040のルールにより、PCN出力が外部ECNをゼロにしたため、トンネル出力は内部ヘッダーからECNフィールドを伝播しますフィールド。
. . . . . . 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トラフィックをどのように処理するかについては、3つの場合があります。
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トラフィックとして扱われません。次の2つのシナリオが考えられます。
* 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を伝送します。 2つのオプションがあります。
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を使用してトラフィックをトンネリングしますが、外部ヘッダーにnot-PCNを設定します。これにより、PCNドメイン内のこのトラフィックのECNがオフになることに注意してください。
The first or second options are recommended unless the operator is short of local DSCPs.
オペレーターがローカルDSCPに不足していない限り、最初または2番目のオプションをお勧めします。
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トラフィックとして扱われます。 2つのオプションがあります。
* 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-ingress-nodeはこのトラフィックを、外部ヘッダーに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-ingress-nodeは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.
2番目のオプションは、おそらく克服できない理由でトンネリングが不可能である場合の最後の手段としてでない限り、強く推奨されません。
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-ingress-nodeは、[RFC6040]に準拠するように注意しながら、図2のようにトラフィックをトンネリングする必要があります。この場合、PCN-egressはECNフィールドをゼロにしないため（セクション5.3の推奨とは異なり）、[RFC6040]トンネル出力はPCNマーキングを保持します。 PCN-interior-nodeは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 Shimヘッダーの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トラフィックをカプセル化する場合、MPLSヘッダーでDSフィールド情報にアクセスできるようにすると便利です。ただし、MPLSシムヘッダーには、8つのコードポイントを提供する3ビットのトラフィッククラス（TC）フィールド[RFC5462]しかありません。オペレーターは、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仕様が草案の初期段階にある間に作成されました。以下は、PCNの用語と概念が指定されて以来、IPとMPLSの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'）で、使用するすべてのPCNマークのTCフィールドにコードポイントを指定する必要があります。つまり、たとえば、PCNの目的で過剰トラフィックマーキングのみが使用されている場合、オペレーターは、IPヘッダーのMPLS TCフィールドの2つのコードポイントへのサイトローカルマッピングを定義する必要があります。
o DSCP n and NM
o DSCP nおよびNM
o DSCP n and ETM
o DSCP nおよび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:
過剰トラフィックマーキングとしきい値マーキングの両方を使用する場合、オペレーターは、3つの1つの3つのコードポイントすべてを持つIPヘッダーのMPLS TCフィールドのコードポイントへのサイトローカルマッピングを定義する必要があります。
o DSCP n and NM
o DSCP nおよびNM
o DSCP n and ThM
o DSCP nおよびThM
o DSCP n and ETM
o DSCP nおよび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 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].
o DSCP nおよびnot-PCN上記のコードポイントのセットは、すべてのPCN互換のDSCPに必要です。明らかに、使用可能なTCコードポイントがほとんどないため、いくつかの機能をマージして妥協する必要がある場合があります。アドミッション制御されていないトラフィックがPCNトラフィックと競合できるようにすることでTCコードポイントを節約するためのガイドラインは、[RFC5670]の付録B.1に記載されています。
Appendix D. Rationale for Difference between the Schemes Using One PCN-Marking
付録D. 1つの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の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.
この明らかな矛盾は意図的なものです。しきい値マーキングのみの場合の動作は、ETMがより深刻であり、この場合ETMが有効なマーキングではない場合でも、ThMに変更してはならないというセクション5.2.1の規則に従います。そうでない場合、実装では、オペレーターがこのルールの例外を構成できるようにする必要があります。これは安全な方法ではなく、一般的な動作と比較してデータプレーンに異なるコードが必要になります。
Authors' Addresses
著者のアドレス
Bob Briscoe BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK
Bob Briscoe BT B54 / 77、Adastral Park Martlesham Heath Ipswich IP5 3RE UK
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 UK
EMail: toby.moncaster@cl.cam.ac.uk
Michael Menth University of Tuebingen Sand 13 72076 Tuebingen Germany
Michael Menth University of Tuebingen Sand 13 72076チュービンゲンドイツ
Phone: +49-7071-2970505
EMail: menth@uni-tuebingen.de