[要約] RFC 6627は、事前混雑通知エンコーディングの概要を提供し、ネットワークの混雑を事前に通知するための方法を定義しています。このRFCの目的は、ネットワークのパフォーマンスを向上させ、トラフィックの効率を高めることです。
Internet Engineering Task Force (IETF) G. Karagiannis
Request for Comments: 6627 University of Twente
Category: Informational K. Chan
ISSN: 2070-1721 Consultant
T. Moncaster
University of Cambridge
M. Menth
University of Tuebingen
P. Eardley
B. Briscoe
BT
July 2012
Overview of Pre-Congestion Notification Encoding
輻輳前通知エンコーディングの概要
Abstract
概要
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre-congestion.
事前輻輳通知（PCN）の目的は、Diffservドメイン内の非弾性フローのサービス品質（QoS）を保護することです。 PCNドメイン内のすべてのリンクで、PCNトラフィックの全体的なレートが測定され、特定の構成されたレートを超えると、PCNパケットが適切にマークされます。出力ノードは、PCNパケットのPCNマークに関する情報を決定ポイントに提供します。これにより、新しいフロー要求を許可するかブロックするかを決定し、深刻な事前輻輳時にいくつかのすでに許可されたフローを終了できます。
The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution.
PCNワーキンググループは、この輻輳前情報をIPヘッダーにエンコードするための多くのアプローチを検討しました。このドキュメントでは、これらのアプローチの詳細と、ソリューションに適用される制約について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6627.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6627で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
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 ....................................................4
2. General PCN Encoding Requirements ...............................5
2.1. Metering and Marking Algorithms ............................5
2.2. Approaches for PCN-Based Admission Control and Flow
Termination ................................................5
2.2.1. Dual Marking (DM) ...................................5
2.2.2. Single Marking (SM) .................................6
2.2.3. Packet-Specific Dual Marking (PSDM) .................7
2.2.4. Preferential Packet Dropping ........................8
3. Encoding Constraints ............................................9
3.1. Structure of the DS Field ..................................9
3.2. Constraints from the DS Field ..............................9
3.2.1. General Scarcity of DSCPs ...........................9
3.2.2. Handling of the DSCP in Tunneling Rules ............10
3.2.3. Restoration of Original DSCPs at the Egress Node ...10
3.3. Constraints from the ECN Field ............................11
3.3.1. Structure and Use of the ECN Field .................11
3.3.2. Redefinition of the ECN Field ......................12
3.3.3. Handling of the ECN Field in Tunneling Rules .......12
3.3.3.1. Limited-Functionality Option ..............12
3.3.3.2. Full-Functionality Option .................13
3.3.3.3. Tunneling with IPSec ......................13
3.3.3.4. ECN Tunneling .............................13
3.3.4. Restoration of the Original ECN Field at
the PCN-Egress-Node ................................14
4. Comparison of Encoding Options .................................15
4.1. Baseline Encoding .........................................15
4.2. Encoding with 1 DSCP Providing 3 States ...................16
4.3. Encoding with 2 DSCPs Providing 3 or More States ..........16
4.4. Encoding for Packet-Specific Dual Marking (PSDM) ..........16
4.5. Standardized Encodings ....................................17
5. Conclusion .....................................................17
6. Security Implications ..........................................17
7. Acknowledgements ...............................................17
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................18
The objective of Pre-Congestion Notification (PCN) [RFC5559] is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. Two mechanisms are used: admission control (AC), to decide whether to admit or block a new flow request, and flow termination (FT), to terminate some existing flows during serious pre-congestion. To achieve this, the overall rate of PCN-traffic is metered on every link in the domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. These configured rates are below the rate of the link. Thus, boundary nodes are notified of a potential overload before any real congestion occurs (hence "pre-congestion notification").
Pre-Congestion Notification（PCN）[RFC5559]の目的は、Diffservドメイン内の非弾性フローのサービス品質（QoS）をシンプルでスケーラブルで堅牢な方法で保護することです。 2つのメカニズムが使用されます。新しいフロー要求を許可するかブロックするかを決定するアドミッションコントロール（AC）と、深刻な事前輻輳時に既存のフローを終了するフロー終了（FT）です。これを実現するために、ドメイン内のすべてのリンクでPCNトラフィックの全体的なレートが計測され、特定の構成されたレートを超えたときにPCNパケットが適切にマークされます。これらの設定されたレートは、リンクのレートを下回っています。したがって、実際の輻輳が発生する前に境界ノードに潜在的な過負荷が通知されます（したがって「輻輳前通知」）。
[RFC5670] provides for two metering and marking functions that are configured with reference rates. Threshold-marking marks all PCN-packets once their traffic rate on a link exceeds the configured reference rate (PCN-threshold-rate). Excess-traffic-marking marks only those PCN-packets that exceed the configured reference rate (PCN-excess-rate).
[RFC5670]は、参照レートで構成された2つの計測およびマーキング機能を提供します。しきい値マーキングは、リンク上のトラフィックレートが設定された参照レート（PCN-threshold-rate）を超えると、すべてのPCNパケットにマークを付けます。超過トラフィックマーキングは、設定された参照レート（PCN-超過レート）を超えるPCNパケットだけにマークを付けます。
Egress nodes monitor the PCN-marks of received PCN-packets and provide information about the PCN-marks to the decision points that take decisions about the flow admission and termination on this basis [RFC6661] [RFC6662].
出口ノードは、受信したPCNパケットのPCNマークを監視し、これに基づいてフローのアドミッションとターミネーションに関する決定を行う決定ポイントにPCNマークに関する情報を提供します[RFC6661] [RFC6662]。
This PCN information has to be encoded into the IP header. This requires at least three different codepoints: one for PCN-traffic that has not been marked, one for traffic that has been marked by the threshold meter, and one for traffic that has been marked by the excess-traffic-meter.
このPCN情報は、IPヘッダーにエンコードする必要があります。これには、少なくとも3つの異なるコードポイントが必要です。1つはマークされていないPCNトラフィック用、もう1つはしきい値メーターでマークされたトラフィック用、および1つは超過トラフィックメーターでマークされたトラフィック用です。
Since unused codepoints are not available for that purpose in the IP header (versions 4 and 6), already used codepoints must be reused, which imposes additional constraints on the design and applicability of PCN-based AC and FT. This document summarizes these issues as a record of the PCN working group discussions and for the benefit of the wider IETF community.
未使用のコードポイントはIPヘッダー（バージョン4および6）でその目的に使用できないため、既に使用されているコードポイントを再利用する必要があり、PCNベースのACおよびFTの設計と適用性に追加の制約が課せられます。このドキュメントは、PCNワーキンググループディスカッションの記録として、そしてより広いIETFコミュニティの利益のために、これらの問題を要約しています。
In Section 2, we briefly point out the PCN encoding requirement imposed by metering and marking algorithms, and by special packet drop strategies. The Differentiated Services field (6 bits -- see [RFC3260] updating [RFC2474] in this respect) and the Explicit Congestion Notification (ECN) field (2 bits) [RFC3168] have been selected to be reused for encoding of PCN-marks (PCN encoding). In Section 3, we briefly explain the constraints imposed by this decision. In Section 4, we review different PCN encodings considered
セクション2では、メータリングとマーキングのアルゴリズム、および特別なパケットドロップ戦略によって課されるPCNエンコーディング要件を簡単に指摘します。 Differentiated Servicesフィールド（6ビット-この点については[RFC3260] [RFC2474]の更新を参照）とExplicit Congestion Notification（ECN）フィールド（2ビット）[RFC3168]は、PCNマークのエンコードに再利用するために選択されました（ PCNエンコーディング）。セクション3では、この決定によって課せられる制約について簡単に説明します。セクション4では、考慮されるさまざまなPCNエンコーディングを確認します。
by the PCN working group that allow different implementations of PCN-based AC and FT, which have different pros and cons.
PCNベースのACとFTのさまざまな実装を許可するPCNワーキンググループによるもので、長所と短所が異なります。
The choice of metering and marking algorithms and the way they are applied to PCN-based AC and FT impose certain requirements on PCN encoding.
メータリングとマーキングのアルゴリズムの選択、およびそれらをPCNベースのACおよびFTに適用する方法は、PCNエンコーディングに特定の要件を課します。
Two different metering and marking algorithms are defined in [RFC5670]: excess-traffic-marking and threshold-marking. They are both configured with reference rates that are termed PCN-excess-rate and PCN-threshold-rate, respectively. When traffic for PCN-flows enters a PCN-domain, the PCN-ingress-node sets a codepoint in the IP header indicating that the packet is subject to PCN-metering and PCN-marking and that it is not-marked (NM). The two metering and marking algorithms possibly re-mark PCN-packets as excess-traffic-marked (ETM) or threshold-marked (ThM).
[RFC5670]では、2つの異なる計測およびマーキングアルゴリズムが定義されています。過剰トラフィックマーキングとしきい値マーキングです。これらは両方とも、それぞれPCN-excess-rateおよびPCN-threshold-rateと呼ばれる参照レートで設定されます。 PCNフローのトラフィックがPCNドメインに入ると、PCN-ingress-nodeはIPヘッダーにコードポイントを設定し、パケットがPCNメータリングとPCNマーキングの対象であり、マーキングされていない（NM）ことを示します。 2つの測定アルゴリズムとマーキングアルゴリズムは、PCNパケットを過剰トラフィックマーキング済み（ETM）またはしきい値マーキング済み（ThM）として再マーキングする可能性があります。
Excess-traffic-marking ETM-marks all not-ETM-marked PCN-traffic that is in excess of the PCN-excess-rate. To that end, the algorithm needs to know whether a PCN-packet has already been marked with ETM or not. Threshold-marking re-marks all not-marked PCN-traffic to ThM when the rate of PCN-traffic exceeds the PCN-threshold-rate. Therefore, it does not need knowledge of the prior marking state of the packet for metering, but such knowledge is needed for packet re-marking.
超過トラフィックマーキングETMマークは、PCN超過レートを超える、ETMマークが付いていないすべてのPCNトラフィックをマークします。そのため、アルゴリズムはPCNパケットがすでにETMでマークされているかどうかを知る必要があります。 PCNトラフィックのレートがPCNしきい値レートを超えると、しきい値マーキングは、マークされていないすべてのPCNトラフィックをThMに再マーキングします。したがって、メータリングのためにパケットの以前のマーキング状態の知識は必要ありませんが、パケットの再マーキングにはそのような知識が必要です。
We briefly review three different approaches to implement PCN-based AC and FT and derive their requirements for PCN encoding.
PCNベースのACおよびFTを実装するための3つの異なるアプローチを簡単に確認し、PCNエンコーディングの要件を導き出します。
The intuitive approach for PCN-based AC and FT requires that threshold and excess-traffic-marking are simultaneously activated on all links of a PCN-domain, and their reference rates are configured with the PCN-admissible-rate (AR) and the PCN-supportable-rate (SR), respectively. Threshold-marking meters all PCN-traffic, but re-marks only NM-traffic to ThM. Excess-traffic-marking meters only NM- and ThM-traffic and re-marks it to ETM. Thus, both meters and markers need to identify PCN-packets and their exact PCN codepoint. We call this marking behavior dual marking (DM) and Figure 1 illustrates all possible re-marking actions.
PCNベースのACとFTの直感的なアプローチでは、PCNドメインのすべてのリンクでしきい値と超過トラフィックマーキングを同時にアクティブにし、それらの参照レートをPCN許容レート（AR）とPCNで構成する必要があります。 -supportable-rate（SR）、それぞれ。しきい値マーキングはすべてのPCNトラフィックを測定しますが、再マーキングするのはThMへのNMトラフィックのみです。過剰なトラフィックマーキングは、NMトラフィックとThMトラフィックのみを測定し、ETMに再マーキングします。したがって、メーターとマーカーの両方がPCNパケットと正確なPCNコードポイントを識別する必要があります。このマーキング動作をデュアルマーキング（DM）と呼びます。図1は、可能なすべての再マーキングアクションを示しています。
NM -----------> ThM
\ /
\ /
\ /
> ETM <
Figure 1: PCN Codepoint Re-Marking Diagram for Dual Marking (DM)
図1：デュアルマーキング（DM）のPCNコードポイントリマーキング図
Dual marking is used to support the Controlled-Load PCN (CL-PCN) edge behavior [RFC6661]. We briefly summarize the concept. All actions are performed on per-ingress-egress-aggregate basis. The egress node measures the rate of NM-, ThM-, and ETM-traffic in regular intervals and sends them as PCN egress reports to the AC and FT decision point.
デュアルマーキングは、Controlled-Load PCN（CL-PCN）エッジ動作をサポートするために使用されます[RFC6661]。コンセプトを簡単にまとめます。すべてのアクションは、ingress-egress-aggregateごとに実行されます。出力ノードは、NM-、ThM-、およびETMトラフィックのレートを定期的に測定し、それらをPCN出力レポートとしてACおよびFT決定ポイントに送信します。
If the proportion of re-marked (ThM- and ETM-) PCN-traffic is larger than a defined threshold, called CLE-limit, the decision point blocks new flow requests until new PCN egress reports are received; otherwise, it admits them. With CL-PCN, AC is rather robust with regard to the value chosen for the CLE-limit. FT works as follows. If the ETM-traffic rate is positive, the decision point triggers the ingress node to send a newly measured rate of the sent PCN-traffic. The decision point calculates the rate of PCN-traffic that needs to be terminated by
再マーキングされた（ThM-およびETM-）PCNトラフィックの比率がCLE-limitと呼ばれる定義済みのしきい値よりも大きい場合、ディシジョンポイントは、新しいPCN出力レポートが受信されるまで新しいフロー要求をブロックします。それ以外の場合は許可します。 CL-PCNでは、ACはCLE制限に選択された値に関してかなり堅牢です。 FTは次のように動作します。 ETMトラフィックレートが正の場合、ディシジョンポイントは入力ノードをトリガーして、送信されたPCNトラフィックの新しく測定されたレートを送信します。ディシジョンポイントは、終了する必要があるPCNトラフィックのレートを計算します。
termination-rate = PCN-sent-rate - (rate-of-NM-traffic + rate-of-ThM-traffic)
終了率= PCN送信率-（NMトラフィック率+ ThMトラフィック率）
and terminates an appropriate set of flows. CL-PCN is accurate enough for most application scenarios and its implementation complexity is acceptable, therefore, it is a preferred implementation option for PCN-based AC and FT.
そして、適切なフローのセットを終了します。 CL-PCNは、ほとんどのアプリケーションシナリオに対して十分正確であり、その実装の複雑さは許容範囲内であるため、PCNベースのACおよびFTの推奨実装オプションです。
Single marking uses only excess-traffic-marking whose reference rate is set to the PCN-admissible-rate (AR) on all links of the PCN-domain. Figure 2 illustrates all possible re-marking actions.
単一マーキングは、参照レートがPCNドメインのすべてのリンクのPCN許容レート（AR）に設定されている超過トラフィックマーキングのみを使用します。図2は、可能なすべての再マーキングアクションを示しています。
NM --------> ETM
Figure 2: PCN Codepoint Re-Marking Diagram for Single Marking (SM)
図2：シングルマーキング（SM）のPCNコードポイントリマーキング図
Single marking is used to support the Single-Marking PCN (SM-PCN) edge behavior [RFC6662]. We briefly summarize the concept.
シングルマーキングは、シングルマーキングPCN（SM-PCN）エッジ動作[RFC6662]をサポートするために使用されます。コンセプトを簡単にまとめます。
AC works essentially in the same way as with CL-PCN, but AC is sensitive to the value of the CLE-limit. Also FT works similarly to CL-PCN. The PCN-supportable-rate (SR) is not configured on any link, but is implicitly
ACは基本的にCL-PCNと同じように動作しますが、ACはCLE制限の値に影響されます。また、FTはCL-PCNと同様に機能します。 PCN-supportable-rate（SR）はどのリンクにも構成されていませんが、暗黙的に
SR=u*AR
SR = u * AR
in the PCN-domain using a network-wide constant u. The decision point triggers FT only if the rate-of-NM-traffic * u < rate-of-NM-traffic + rate-of-ETM-traffic. Then it requests the PCN-sent-rate from the corresponding PCN-ingress-node and calculates the amount of PCN-traffic to be terminated by
PCNドメインでは、ネットワーク全体の定数uを使用します。ディシジョンポイントは、NMトラフィックのレート* u <NMトラフィックのレート+ ETMトラフィックのレートの場合にのみFTをトリガーします。次に、対応するPCN-ingress-nodeからのPCN-sent-rateを要求し、終了するPCNトラフィックの量を計算します。
termination-rate = PCN-sent-rate - rate-of-NM-traffic * u,
終了率= PCN送信率-NMトラフィック率* u、
and terminates an appropriate set of flows.
そして、適切なフローのセットを終了します。
SM-PCN requires only two PCN codepoints and only excess-traffic-marking is needed, which means that it might be earlier to the market than CL-PCN since some chipsets do not yet support threshold-marking.
SM-PCNは2つのPCNコードポイントのみを必要とし、過剰なトラフィックマーキングのみが必要です。つまり、一部のチップセットはまだしきい値マーキングをサポートしていないため、CL-PCNよりも市場に早い可能性があります。
However, it only works well when ingress-egress-aggregates have a high PCN-packet rate, which is not always the case. Otherwise, over-admission and over-termination may occur [Menth12] [Menth10].
ただし、これは、ingress-egress-aggregatesのPCNパケットレートが高い場合にのみ機能しますが、常にそうであるとは限りません。そうしないと、過大な入場と終了が発生する可能性があります[Menth12] [Menth10]。
Packet-specific dual marking (PSDM) uses threshold-marking and excess-traffic-marking, whose reference rates are configured with the PCN-admissible-rate (AR) and the PCN-supportable-rate (SR), respectively. There are two different types of not-marked packets: those that are subject to threshold-marking (not-ThM), and those that are subject to excess-traffic-marking (not-ETM). Both not-ThM and not-ETM are used for PCN-traffic that is not yet re-marked (like NM with single and dual marking), and their specific use is determined by higher-layer information (see below). Threshold-marking meters all PCN-traffic and re-marks only not-ThM packets to PCN-marked (PM). In contrast, excess-traffic-marking meters only not-ETM packets and possibly re-marks them to PM, too. Again, both meters and markers need to identify PCN-packets and their exact PCN codepoint. Figure 3 illustrates all possible re-marking actions.
パケット固有のデュアルマーキング（PSDM）は、しきい値マーキングと超過トラフィックマーキングを使用します。これらのリファレンスレートは、それぞれPCN許容レート（AR）とPCNサポート可能レート（SR）で構成されます。マーキングされていないパケットには2つの異なるタイプがあります。しきい値マーキングの対象となるパケット（ThM以外）と、超過トラフィックマーキングの対象となるパケット（ETM以外）です。 not-ThMとnot-ETMの両方は、まだ再マーキングされていないPCNトラフィックに使用され（シングルマーキングとデュアルマーキングのNMのように）、それらの特定の使用は上位層の情報によって決定されます（以下を参照）。しきい値マーキングは、すべてのPCNトラフィックを測定し、ThMパケットのみを再マーキングして、PCNマーキング（PM）します。対照的に、超過トラフィックマーキングメーターは、ETMパケットだけではなく、PMに再マーキングする可能性もあります。ここでも、メーターとマーカーの両方がPCNパケットとその正確なPCNコードポイントを識別する必要があります。図3は、可能なすべての再マーキングアクションを示しています。
not-ThM not-ETM
\ /
\ /
\ /
> PM <
Figure 3: PCN Codepoint Re-Marking Diagram for Packet-Specific Dual Marking (PSDM)
図3：パケット固有のデュアルマーキング（PSDM）のPCNコードポイントリマーキング図
An edge behavior for PSDM has been presented in [Menth09] and [PCN-MS-AC]. We call it PSDM-PCN. In contrast to CL-PCN and SM-PCN, AC is realized by reusing initial signaling messages for probing purposes. The assumption is that admission requests are triggered by an external end-to-end signaling protocol, e.g., RSVP [RFC2205]. Signaling traffic for a flow is also labeled as PCN-traffic, and if an initial signaling message traverses the PCN-domain and is re-marked, then the corresponding admission request is blocked. This is a lightweight probing mechanism that does not generate extra traffic and does not introduce probing delay. In PSDM-PCN, PCN-ingress-nodes label initial signaling messages as not-ThM, and threshold-marking configured with admissible rates possibly re-marks them to PM. Data packets are labeled with not-ETM, and excess-traffic-marking configured with supportable rates possibly re-marks them to PM, too, so that the same algorithms for FT may be used as for CL-PCN and SM-PCN.
PSDMのエッジ動作は、[Menth09]および[PCN-MS-AC]に示されています。これをPSDM-PCNと呼びます。 CL-PCNおよびSM-PCNとは対照的に、ACはプローブ目的で初期シグナリングメッセージを再利用することで実現されます。承認要求は、外部エンドツーエンドシグナリングプロトコル、たとえばRSVP [RFC2205]によってトリガーされると想定されています。フローのシグナリングトラフィックもPCNトラフィックとしてラベル付けされ、最初のシグナリングメッセージがPCNドメインを通過して再度マークされると、対応するアドミッション要求がブロックされます。これは、余分なトラフィックを生成せず、プローブ遅延を発生させない軽量のプローブメカニズムです。 PSDM-PCNでは、PCN-ingress-nodesが初期シグナリングメッセージをnot-ThMとしてラベル付けし、許容レートで構成されたしきい値マーキングがそれらをPMに再マーキングする可能性があります。データパケットはnot-ETMでラベル付けされ、サポート可能なレートで設定された超過トラフィックマーキングはそれらをPMにも再マーキングする可能性があるため、CL-PCNおよびSM-PCNと同じFTのアルゴリズムを使用できます。
PSDM has three major disadvantages. First, signalling traffic needs to be marked with a PCN-enabled DSCP so that it either shares the same queue as data traffic, which may not be desired by some operators, or multiple PCN-enabled DSCPs are needed, which is not a pragmatic solution. Second, reservations for PCN-flows need to be triggered by a path-coupled end-to-end signalling protocol, which restricts the choice of the signalling protocol. And third, the selected signalling protocols must be adapted to take advantage of PCN-marked signalling messages for admission decisions, which incurs some extra effort before PSDM can be used.
PSDMには3つの主要な欠点があります。まず、シグナリングトラフィックをPCN対応のDSCPでマークして、データトラフィックと同じキューを共有する必要がある場合があります。これは、一部のオペレーターでは望ましくない場合があります。または、実用的なソリューションではない、複数のPCN対応のDSCPが必要です。 。第2に、PCNフローの予約は、パス結合のエンドツーエンドシグナリングプロトコルによってトリガーされる必要があり、シグナリングプロトコルの選択を制限します。 3番目に、選択したシグナリングプロトコルは、PSDMマーク付きのシグナリングメッセージを利用してアドミッションを決定する必要があるため、PSDMを使用する前に追加の作業が必要になります。
The advantages are that the AC algorithm is more accurate than the one of CL-PCN and SM-PCN [Menth12], that often only a single DSCP is needed, and that the new tunneling rules in [RFC6040] are not needed for deployment (Section 3.3.3).
利点は、ACアルゴリズムがCL-PCNおよびSM-PCN [Menth12]の1つよりも正確であり、多くの場合、単一のDSCPのみが必要であり、[RFC6040]の新しいトンネリングルールが展開に必要ないことです（セクション3.3.3）。
The termination algorithms described in [RFC6661] and [RFC6662] require the preferential dropping of ETM-marked packets to avoid over-termination in the case of packet loss. An analysis explaining this phenomenon can be found in Section 4 of [Menth10].
[RFC6661]と[RFC6662]で説明されている終了アルゴリズムでは、パケット損失の場合に過剰終了を回避するために、ETMマーク付きのパケットを優先的にドロップする必要があります。この現象を説明する分析は、[Menth10]のセクション4にあります。
Thus, [RFC5670] recommends that ETM-marked packets "SHOULD be preferentially dropped". As a consequence, droppers must have access to the exact marking information of PCN-packets.
したがって、[RFC5670]は、ETMでマークされたパケットを「優先的にドロップする必要がある」ことを推奨しています。結果として、ドロッパーはPCNパケットの正確なマーキング情報にアクセスできる必要があります。
The PCN working group decided to use a combination of the 6-bit Differentiated Services (DS) field and the ECN field for the encoding of the PCN-marks (see [RFC6660]). This section describes the criteria that are used to compare the resulting encoding options described in Section 4.
PCNワーキンググループは、PCNマークのエンコードに6ビットの差別化サービス（DS）フィールドとECNフィールドの組み合わせを使用することを決定しました（[RFC6660]を参照）。このセクションでは、セクション4で説明されているエンコードオプションを比較するために使用される基準について説明します。
Figure 4 shows the structure of the DS and ECN fields. [RFC0793] defined the 8-bit TOS octet and [RFC2474] redefined it as the DS field, including the two least significant bits as currently unused (CU). [RFC3168] assigned the two CU bits to ECN and [RFC3260] redefined the DS field as only the most significant 6-bits of the (former) IPv4 TOS octet, thus separating the two-bit ECN field from the DS field.
図4は、DSおよびECNフィールドの構造を示しています。 [RFC0793]は8ビットのTOSオクテットを定義し、[RFC2474]は現在未使用（CU）として最下位2ビットを含むDSフィールドとして再定義しました。 [RFC3168]は2つのCUビットをECNに割り当て、[RFC3260]はDSフィールドを（以前の）IPv4 TOSオクテットの最上位6ビットのみとして再定義し、2ビットのECNフィールドをDSフィールドから分離しました。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DS | ECN |
+---+---+---+---+---+---+---+---+
DS: Differentiated Services field [RFC2474], [RFC3260] ECN: ECN field [RFC3168]
DS：Differentiated Servicesフィールド[RFC2474]、[RFC3260] ECN：ECNフィールド[RFC3168]
Figure 4: The Structure of the DS and ECN Fields
図4：DSおよびECNフィールドの構造
The Differentiated Services Codepoint (DSCP) set in the DS field indicates the per-hop behavior (PHB), i.e., the treatment IP packets receive from nodes in a DS domain. Multiple DSCPs may indicate the same PHB. PCN-traffic is high-priority traffic, which uses a DSCP (or DSCPs) that indicates a PHB with preferred treatment.
DSフィールドに設定されたDiffServコードポイント（DSCP）は、ホップごとの動作（PHB）、つまりDSドメインのノードから受信したIPパケットの処理を示します。複数のDSCPが同じPHBを示す場合があります。 PCNトラフィックは優先度の高いトラフィックであり、優先処理のあるPHBを示すDSCP（またはDSCP）を使用します。
As the number of unused DSCPs is small, PCN encoding should use only one additional DSCP for each DSCP originally used to indicate the PHB and in any case should not use more than two. Therefore, the DSCP should be used to indicate that traffic is subject to PCN-metering and PCN-marking, but not to differentiate various PCN-markings.
未使用のDSCPの数は少ないので、PCNエンコーディングは、最初にPHBを示すために使用された各DSCPに対して1つの追加DSCPのみを使用し、いずれの場合も3つ以上を使用しないでください。したがって、DSCPは、トラフィックがPCNメータリングとPCNマーキングの対象であることを示すために使用する必要がありますが、さまざまなPCNマーキングを区別するためではありません。
PCN encoding must be chosen in such a way that PCN-traffic can be tunneled within a PCN-domain without any impact on PCN-metering and re-marking. In the following, the "inner header" refers to the header of the encapsulated packet and the "outer header" refers to the encapsulating header.
PCNエンコーディングは、PCNトラフィックがPCNドメイン内でトンネリングされ、PCNメータリングと再マーキングに影響を与えないように選択する必要があります。以下では、「内部ヘッダー」はカプセル化されたパケットのヘッダーを指し、「外部ヘッダー」はカプセル化ヘッダーを指します。
[RFC2983] provides two tunneling modes for Differentiated Services networks. The uniform model copies the DSCP from the inner header to the outer header upon encapsulation, and it copies the DSCP from the outer header to the inner header upon decapsulation. This assures that changes applied to the DSCP field survive encapsulation and decapsulation. In contrast, the pipe model ignores the content of the DSCP field in the outer header upon decapsulation. Therefore, decapsulation erases changes applied to the DSCP along the tunnel. As a consequence, only the uniform model may be used for tunneling PCN-traffic within a PCN-domain, if PCN encoding uses more than a single DSCP.
[RFC2983]は、差別化サービスネットワークに2つのトンネリングモードを提供します。ユニフォームモデルは、カプセル化時にDSCPを内部ヘッダーから外部ヘッダーにコピーし、カプセル化解除時にDSCPを外部ヘッダーから内部ヘッダーにコピーします。これにより、DSCPフィールドに適用された変更がカプセル化およびカプセル化解除に耐えることが保証されます。対照的に、パイプモデルはカプセル化解除時に外部ヘッダーのDSCPフィールドの内容を無視します。したがって、カプセル化を解除すると、トンネルに沿ってDSCPに適用された変更が消去されます。その結果、PCNエンコーディングが複数のDSCPを使用する場合、PCNドメイン内のPCNトラフィックのトンネリングに使用できるのは、統一モデルのみです。
If PCN-marking does not alter the original DSCP, the traffic leaves the PCN-domain with its original DSCP. However, if the PCN-marking alters the DSCP, then some additional technique is needed to restore the original DSCP. A few possibilities are discussed:
PCNマーキングが元のDSCPを変更しない場合、トラフィックは元のDSCPでPCNドメインを離れます。ただし、PCNマーキングによってDSCPが変更される場合は、元のDSCPを復元するために追加のテクニックが必要です。いくつかの可能性について説明します。
1. Each Diffserv class using PCN uses a different set of DSCPs. Therefore, if there are M DSCPs using PCN and PCN encoding uses N different DSCPs, N*M DSCPs are needed. This solution may work well in IP networks. However, when PCN is applied to MPLS networks or other layers restricted to 8 QoS classes and codepoints, this solution fails due to the extreme shortage of available DSCPs.
1. PCNを使用する各Diffservクラスは、異なるDSCPセットを使用します。したがって、PCNを使用するM DSCPがあり、PCNエンコーディングがN個の異なるDSCPを使用する場合、N * M DSCPが必要です。このソリューションは、IPネットワークでうまく機能する可能性があります。ただし、8つのQoSクラスとコードポイントに制限されたMPLSネットワークまたは他のレイヤーにPCNを適用すると、使用可能なDSCPが極端に不足するため、このソリューションは失敗します。
2. The original DSCP for the packets of a flow is signaled to the egress node. No suitable signaling protocol has been developed and, therefore, it is not clear whether this approach could work.
2. フローのパケットの元のDSCPは出力ノードに通知されます。適切なシグナリングプロトコルが開発されていないため、このアプローチが機能するかどうかは不明です。
3. PCN-traffic is tunneled across the PCN-domain. The pipe-tunneling model is applied, so the original DSCP is restored after decapsulation. However, tunneling across a PCN-domain adds an additional IP header and reduces the maximum transfer unit (MTU) from the perspective of the user. GRE, MPLS, or Ethernet using pseudowires are potential solutions that scale well in backbone networks.
3. PCNトラフィックは、PCNドメイン全体にトンネリングされます。パイプトンネリングモデルが適用されるため、カプセル化解除後に元のDSCPが復元されます。ただし、PCNドメインをトンネリングすると、追加のIPヘッダーが追加され、ユーザーの観点から最大転送単位（MTU）が減少します。疑似配線を使用するGRE、MPLS、またはイーサネットは、バックボーンネットワークで十分に拡張できる潜在的なソリューションです。
The most appropriate option depends on the specific circumstances an operator faces.
最も適切なオプションは、オペレーターが直面する特定の状況によって異なります。
o Option 1 is most suitable unless there is a shortage of available DSCPs.
o 利用可能なDSCPが不足していない限り、オプション1が最適です。
o Option 3 is suitable where the reduction of MTU is not liable to cause issues.
o オプション3は、MTUの削減が問題を引き起こしにくい場合に適しています。
This section briefly reviews the structure and use of the ECN field. The ECN field may be redefined, but certain constraints apply [RFC4774]. The impact on PCN deployment is discussed, as well as the constraints imposed by various tunneling rules on the persistence of PCN-marks after decapsulation and its impact on possible re-marking actions.
このセクションでは、ECNフィールドの構造と使用法について簡単に説明します。 ECNフィールドは再定義されるかもしれませんが、特定の制約が適用されます[RFC4774]。 PCN展開への影響、およびカプセル化解除後のPCNマークの持続性に関するさまざまなトンネリングルールによって課せられる制約と、可能な再マーキングアクションへの影響について説明します。
Some transport protocols, like TCP, can typically use packet drops as an indication of congestion in the Internet. The idea of Explicit Congestion Notification (ECN) [RFC3168] is that routers provide a congestion indication for incipient congestion, where the notification can sometimes be through ECN-marking (and re-marking) packets rather than dropping them. Figure 5 summarizes the ECN codepoints defined [RFC3168].
TCPなどの一部のトランスポートプロトコルは、通常、インターネットでの輻輳の指標としてパケットドロップを使用できます。明示的輻輳通知（ECN）[RFC3168]の考え方は、ルーターが初期の輻輳の輻輳表示を提供するというものです。通知は、パケットをドロップするのではなく、ECNマーキング（および再マーキング）パケットを通じて行われる場合があります。図5は、定義されたECNコードポイントをまとめたものです[RFC3168]。
+-----+-----+
| ECN FIELD |
+-----+-----+
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Figure 5: ECN Codepoints within the ECN Field
図5：ECNフィールド内のECNコードポイント
ECT stands for "ECN-capable transport" and indicates that the senders and receivers of a flow understand ECN semantics. Packets of other flows are labeled with Not-ECT. To indicate congestion to a receiver, routers may re-mark ECT(1) or ECT(0) labeled packets to CE, which stands for "congestion experienced". Two different ECT codepoints were introduced "to protect against accidental or malicious concealment of marked packets from the TCP sender", which may be the case with cheating receivers [RFC3540].
ECTは「ECN対応トランスポート」の略で、フローの送信者と受信者がECNセマンティクスを理解していることを示します。他のフローのパケットはNot-ECTでラベル付けされます。受信側に輻輳を示すために、ルーターはECT（1）またはECT（0）のラベルが付いたパケットをCEに再度マークします。これは「輻輳が発生した」ことを表します。 「TCP送信者からのマークされたパケットの偶発的または悪意のある隠蔽から保護するために」2つの異なるECTコードポイントが導入されました。これは、不正な受信者[RFC3540]の場合と同じです。
The ECN field may be redefined for other purposes and [RFC4774] gives guidelines for that. Essentially, Not-ECT-marked packets must never be re-marked to ECT or CE because Not-ECT-capable end systems do not reduce their transmission rate when receiving CE-marked packets. This is a threat to the stability of the Internet.
ECNフィールドは他の目的のために再定義されるかもしれません、そして[RFC4774]はそのためのガイドラインを与えます。基本的に、Not-ECT対応のエンドシステムはCEマーク付きのパケットを受信するときに伝送速度を低下させないため、Not-ECTマーク付きのパケットをECTまたはCEに再マークしないでください。これはインターネットの安定性に対する脅威です。
Moreover, CE-marked packets must not be re-marked to Not-ECT or ECT, because then ECN-capable end systems cannot reduce their transmission rate. The reuse of the ECN field for PCN encoding has some impact on the deployment of PCN. First, routers within a PCN-domain must not apply ECN re-marking when the ECN field has PCN semantics. Second, before a PCN-packet leaves the PCN-domain, the egress nodes must either: (A) reset the ECN field of the packet to the content it had when entering the PCN-domain or (B) reset its ECN field to Not-ECT. According to Section 3.3.3, tunneling ECN traffic through a PCN-domain may help to implement (A). When (B) applies, CE-marked packets must never become PCN-packets within a PCN-domain, as the egress node resets their ECN field to Not-ECT. The ingress node may drop such traffic instead.
さらに、ECN対応のエンドシステムでは伝送レートを下げることができないため、CEでマークされたパケットをNot-ECTまたはECTに再度マークすることはできません。 PCNエンコーディングのECNフィールドの再利用は、PCNの展開にいくらかの影響を与えます。まず、ECNフィールドにPCNセマンティクスがある場合、PCNドメイン内のルーターはECN再マーキングを適用しないでください。次に、PCNパケットがPCNドメインを離れる前に、出力ノードは次のいずれかを行う必要があります：（A）パケットのECNフィールドをPCNドメインに入るときに持っていたコンテンツにリセットするか、（B）ECNフィールドをNotにリセットする-ECT。セクション3.3.3によると、PCNドメインを介したECNトラフィックのトンネリングは、（A）の実装に役立つ可能性があります。 （B）が適用される場合、出口ノードがECNフィールドをNot-ECTにリセットするため、CEマーク付きのパケットがPCNドメイン内のPCNパケットになることはありません。入力ノードは代わりにそのようなトラフィックをドロップするかもしれません。
When packets are encapsulated, the ECN field of the inner header may or may not be copied to the ECN field of the outer header; upon decapsulation, the ECN field of the outer header may or may not be copied from the ECN field of the outer header to the ECN field of the inner header. Various tunneling rules with different treatment of the ECN field exist. Two different modes are defined in [RFC3168] for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec tunnels. [RFC6040] updates both of these RFCs to rationalize them into one consistent approach.
パケットがカプセル化されると、内部ヘッダーのECNフィールドが外部ヘッダーのECNフィールドにコピーされる場合とされない場合があります。カプセル化解除時に、外部ヘッダーのECNフィールドは、外部ヘッダーのECNフィールドから内部ヘッダーのECNフィールドにコピーされる場合とされない場合があります。 ECNフィールドの扱いが異なるさまざまなトンネリングルールが存在します。 IP-in-IPトンネル用に[RFC3168]で2つの異なるモードが定義され、IP-in-IPsecトンネル用に[RFC4301]で3つ目のモードが定義されています。 [RFC6040]は、これらの両方のRFCを更新して、それらを1つの一貫したアプローチに合理化します。
The limited-functionality option has been defined in [RFC3168]. Upon encapsulation, the ECN field of the outer header is generally set to Not-ECT. Upon decapsulation, the ECN field of the inner header remains unchanged.
機能制限オプションは[RFC3168]で定義されています。カプセル化すると、通常、外部ヘッダーのECNフィールドはNot-ECTに設定されます。カプセル化を解除すると、内部ヘッダーのECNフィールドは変更されません。
Since this tunneling mode loses information upon encapsulation and decapsulation, it cannot be used for tunneling PCN-traffic within a PCN-domain. However, the PCN ingress may use this mode to tunnel traffic with ECN semantics to the PCN egress to preserve the ECN field in the inner header while the ECN field of the outer header is used with PCN semantics within the PCN-domain.
このトンネリングモードはカプセル化およびカプセル化解除時に情報を失うため、PCNドメイン内のPCNトラフィックのトンネリングには使用できません。ただし、PCN入力はこのモードを使用して、ECNセマンティクスのトラフィックをPCN出力にトンネリングし、内部ヘッダーのECNフィールドを保持しながら、外部ヘッダーのECNフィールドがPCNドメイン内のPCNセマンティクスで使用される場合があります。
The full-functionality option has been defined in [RFC3168]. Upon encapsulation, the ECN field of the inner header is copied to the outer header unless the ECN field of the inner header carries CE. In that case, the ECN field of the outer header is set to ECT(0). This choice has been made for security reasons, to disable the ECN fields of the outer header as a covert channel. Upon decapsulation, the ECN field of the inner header remains unchanged unless the ECN field of the outer header carries CE. In that case, the ECN field of the inner header is also set to CE.
全機能オプションは[RFC3168]で定義されています。カプセル化時に、内部ヘッダーのECNフィールドにCEが含まれていない限り、内部ヘッダーのECNフィールドが外部ヘッダーにコピーされます。その場合、外部ヘッダーのECNフィールドはECT（0）に設定されます。この選択は、秘密のチャネルとして外部ヘッダーのECNフィールドを無効にするために、セキュリティ上の理由で行われました。カプセル化を解除すると、外部ヘッダーのECNフィールドがCEを伝送しない限り、内部ヘッダーのECNフィールドは変更されません。その場合、内部ヘッダーのECNフィールドもCEに設定されます。
This mode imposes the following constraints on PCN-metering and PCN-marking. First, PCN must re-mark the ECN field only to CE, because any other information is not copied to the inner header upon decapsulation and will be lost. Second, CE information in encapsulated packet headers is invisible for routers along a tunnel. Threshold-marking does not require information about whether PCN-packets have already been marked and would work when CE denotes that packets are marked. In contrast, excess-traffic-marking requires information about already excess-traffic-marked packets and cannot be supported with this tunneling mode. Furthermore, this tunneling mode cannot be used when marked or not-marked packets should be preferentially dropped, because the PCN-marking information is possibly not visible in the outer header of a packet.
このモードは、PCNメータリングとPCNマーキングに次の制約を課します。まず、PCNはECNフィールドをCEに対してのみ再マーク付けする必要があります。これは、他の情報はカプセル化解除時に内部ヘッダーにコピーされず、失われるためです。次に、カプセル化されたパケットヘッダーのCE情報は、トンネルに沿ったルーターからは見えません。しきい値マーキングは、PCNパケットがすでにマークされているかどうかに関する情報を必要とせず、CEがパケットがマークされていることを示しているときに機能します。対照的に、超過トラフィックマーキングには、すでに超過トラフィックマーキングされたパケットに関する情報が必要であり、このトンネリングモードではサポートできません。さらに、PCNマーキング情報がパケットの外部ヘッダーに表示されない可能性があるため、マーク付きまたはマークなしのパケットを優先的にドロップする必要がある場合、このトンネリングモードは使用できません。
Tunneling has been defined in Section 5.1.2.1 of [RFC4301]. Upon encapsulation, the ECN field of the inner header is copied to the ECN field of the outer header. Decapsulation works as for the full-functionality option described in Section 3.3.3.2. Tunneling with IPsec also requires that PCN re-mark the ECN field only to CE because any other information is not copied to the inner header upon decapsulation and is lost. In contrast to Section 3.3.3.2, with IPsec tunnels, CE marks of tunneled PCN-traffic remain visible for routers along the tunnel and to their meters, markers, and droppers.
トンネリングは、[RFC4301]のセクション5.1.2.1で定義されています。カプセル化すると、内部ヘッダーのECNフィールドが外部ヘッダーのECNフィールドにコピーされます。カプセル化解除は、セクション3.3.3.2で説明されている全機能オプションと同様に機能します。また、IPsecを使用したトンネリングでは、PCNがECNフィールドをCEにのみ再マーク付けする必要があります。これは、他の情報はカプセル化解除時に内部ヘッダーにコピーされず、失われるためです。セクション3.3.3.2とは異なり、IPsecトンネルでは、トンネルに沿ったPCNトラフィックのCEマークは、トンネルに沿ったルーターと、メーター、マーカー、ドロッパーから見えます。
New tunneling rules for ECN are specified in [RFC6040], which updates [RFC3168] and [RFC4301]. These rules provide a consistent and rational approach to encapsulation and decapsulation.
ECNの新しいトンネリング規則は[RFC6040]で指定されており、[RFC3168]と[RFC4301]を更新します。これらのルールは、カプセル化とカプセル化解除に一貫した合理的なアプローチを提供します。
With the normal mode, the ECN field of the inner header is copied to the ECN field of the outer header on encapsulation. In compatibility mode, the ECN field of the outer header is reset to Not-ECT.
通常モードでは、カプセル化時に内部ヘッダーのECNフィールドが外部ヘッダーのECNフィールドにコピーされます。互換モードでは、外部ヘッダーのECNフィールドはNot-ECTにリセットされます。
Upon decapsulation, the scheme specified in [RFC6040] and shown in Figure 6 is applied. Thus, re-marking encapsulated Not-ECT packets to any other codepoint would not survive decapsulation. Therefore, Not-ECT cannot be used for PCN encoding. Furthermore, re-marking encapsulated ECT(0) packets to ECT(1) or CE survives decapsulation, but not vice-versa, and re-marking encapsulated ECT(1) packets to CE also survives decapsulation, but not vice-versa. Certain combinations of inner and outer ECN fields cannot result from any transition in any current or previous ECN tunneling specification. These currently unused (CU) combinations are indicated in Figure 6 by '(!!!)' or '(!)'; where '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous.
カプセル化を解除すると、[RFC6040]で指定され、図6に示すスキームが適用されます。したがって、カプセル化されたNot-ECTパケットを他のコードポイントに再マーキングしても、カプセル化が解除されません。したがって、Not-ECTはPCNエンコードに使用できません。さらに、カプセル化されたECT（0）パケットをECT（1）またはCEに再マーキングしてもカプセル化は存続しますが、その逆はできません。カプセル化されたECT（1）パケットをCEに再マーキングしてもカプセル化は存続しますが、その逆は発生しません。内部および外部ECNフィールドの特定の組み合わせは、現在または以前のECNトンネリング仕様の遷移から発生することはありません。これらの現在使用されていない（CU）の組み合わせは、図6で「（!!!）」または「（！）」で示されています。ここで、「（!!!）」は組み合わせがCUで常に潜在的に危険であることを意味し、「（！）」はCUであり、おそらく危険であることを意味します。
+---------+------------------------------------------------+
|Arriving | Arriving Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
| Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
| ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE |
| CE | CE | CE | CE(!!!)| CE |
+---------+---------+------------+------------+------------+
The ECN field in the outgoing header is set to the codepoint at the intersection of the appropriate arriving inner header (row) and arriving outer header (column), or the packet is dropped where indicated. Currently unused combinations are indicated by '(!!!)' or '(!)'. ([RFC6040]; '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous.)
発信ヘッダーのECNフィールドは、適切な着信内部ヘッダー（行）と着信外部ヘッダー（列）の交点にあるコードポイントに設定されるか、指示された場所でパケットがドロップされます。現在使用されていない組み合わせは、「（!!!）」または「（！）」で示されます。 （[RFC6040]; '（!!!）'は、組み合わせがCUであり、常に潜在的に危険であることを意味しますが、 '（！）'は、CUであり、おそらく危険であることを意味します。）
Figure 6: New IP in IP Decapsulation Behavior (from [RFC6040])
図6：IPカプセル開放動作の新しいIP（[RFC6040]から）
As ECN is an end-to-end service, it is desirable that the egress node of a PCN-domain restore the ECN field that a PCN-packet had at the ingress node. There are basically two options. PCN-traffic may be tunneled between ingress and egress node using limited functionality tunnels (see Section 3.3.3.1). Then, PCN-marking is applied only to the outer header, and the original ECN field is restored after decapsulation. However, this reduces the MTU from the perspective of the user. Another option is to use some intelligent encoding that preserves the ECN codepoints. However, a viable solution is not known.
ECNはエンドツーエンドサービスであるため、PCNドメインの出力ノードは、PCNパケットが入力ノードで持っていたECNフィールドを復元することが望ましいです。基本的に2つのオプションがあります。 PCNトラフィックは、制限された機能のトンネルを使用して、入力ノードと出力ノード間でトンネルできます（セクション3.3.3.1を参照）。次に、PCNマーキングは外部ヘッダーのみに適用され、カプセル化解除後に元のECNフィールドが復元されます。ただし、これにより、ユーザーの観点からMTUが減少します。別のオプションは、ECNコードポイントを保持するインテリジェントなエンコーディングを使用することです。ただし、実行可能なソリューションは不明です。
The PCN working group has studied four different PCN encodings, which redefine the ECN field. Figure 7 summarizes these PCN encodings. One, or at most two, different DSCPs are used to indicate PCN-traffic, and, only for these DSCPs, the semantics of the ECN field are redefined within the PCN-domain.
PCNワーキンググループは、ECNフィールドを再定義する4つの異なるPCNエンコーディングを研究しました。図7は、これらのPCNエンコーディングをまとめたものです。 PCNトラフィックを示すために、1つまたは多くて2つの異なるDSCPが使用され、これらのDSCPについてのみ、ECNフィールドのセマンティクスがPCNドメイン内で再定義されます。
When a PCN-ingress-node classifies a packet as a PCN-packet, it sets its PCN-codepoint to not-marked (NM). Non-PCN-traffic can also use the PCN-specific DSCP by setting the Not-PCN codepoint. Special per-hop behavior, defined in [RFC5670], applies to PCN-traffic.
PCN-ingress-nodeがパケットをPCN-packetとして分類するとき、それはそのPCN-codepointをnot-marked（NM）に設定します。非PCNトラフィックは、Not-PCNコードポイントを設定することにより、PCN固有のDSCPを使用することもできます。 [RFC5670]で定義されている特別なホップごとの動作は、PCNトラフィックに適用されます。
-----------------------------------------------------------------------
| ECN Bits || 00 | 10 | 01 | 11 || DSCP |
|==============++==========+==========+==========+==========++=========|
| RFC 3168 || Not-ECT | ECT(0) | ECT(1) | CE || Any |
|==============++==========+==========+==========+==========++=========|
| Baseline || Not-PCN | NM | EXP | PM || PCN-n |
|==============++==========+==========+==========+==========++=========|
| 3-In-1 || Not-PCN | NM | ThM | ETM || PCN-n |
|==============++==========+==========+==========+==========++=========|
| 3-In-2 || Not-PCN | NM | CU | ThM || PCN-n |
| ||----------+----------+----------+----------++---------|
| || Not-PCN | CU | CU | ETM || PCN-m |
|==============++==========+==========+==========+==========++=========|
| PSDM || Not-PCN | Not-ETM | Not-ThM | PM || PCN-n |
-----------------------------------------------------------------------
Notes: PCN-n, PCN-m under the DSCP column denotes PCN-compatible DSCPs, which may be chosen by the network operator. Not-PCN means that packets are not PCN-enabled. NM means not-marked. CU means currently unused.
注：DSCP列のPCN-n、PCN-mは、ネットワークオペレーターが選択できるPCN互換のDSCPを示します。 Not-PCNは、パケットがPCN対応ではないことを意味します。 NMはマークされていないことを意味します。 CUは現在未使用を意味します。
Figure 7: Semantics of the ECN Field for Various Encoding Types
図7：さまざまなエンコーディングタイプのECNフィールドのセマンティクス
With baseline encoding [RFC5696], the NM codepoint can be re-marked only to PCN-marked (PM). Excess-traffic-marking uses PM as ETM, threshold-marking uses PM as ThM, and only one of the two marking schemes can be used. So, baseline encoding supports SM-PCN.
ベースラインエンコーディング[RFC5696]では、NMコードポイントをPCNマーク（PM）にのみ再マークできます。超過トラフィックマーキングではPMをETMとして使用し、しきい値マーキングではPMをThMとして使用します。2つのマーキングスキームのうち1つだけを使用できます。したがって、ベースラインエンコーディングはSM-PCNをサポートします。
The 01-codepoint is reserved for experimental purposes (EXP) and the other defined PCN encoding schemes can be seen as extensions of baseline encoding by appropriate redefinition of EXP. Baseline encoding [RFC5696] works well with IPsec tunnels (see Section 3.3.3.3).
01コードポイントは実験的な目的（EXP）のために予約されており、他の定義されたPCNエンコーディングスキームは、EXPの適切な再定義によるベースラインエンコーディングの拡張と見なすことができます。ベースラインエンコーディング[RFC5696]はIPsecトンネルで適切に機能します（セクション3.3.3.3を参照）。
PCN 3-state encoding uses a single DSCP (3-in-1 encoding, [RFC6660]), extends the baseline encoding, and supports the simultaneous use of both excess-traffic-marking and threshold-marking. 3-in-1 encoding well supports the preferred CL-PCN and also SM-PCN.
PCNトライステートエンコーディングは、単一のDSCP（3-in-1エンコーディング、[RFC6660]）を使用し、ベースラインエンコーディングを拡張し、超過トラフィックマーキングとしきい値マーキングの両方の同時使用をサポートします。 3-in-1エンコーディングは、優先されるCL-PCNおよびSM-PCNもサポートします。
The problem with 3-in-1 encoding is that the 10-codepoint does not survive decapsulation with the tunneling options in Sections 3.3.3.1 - 3.3.3.3.
3-in-1エンコーディングの問題は、セクション3.3.3.1から3.3.3.3のトンネリングオプションを使用すると、10コードポイントがカプセル化解除に耐えられないことです。
Therefore, the full 3-in-1 encoding may only be used for PCN-domains implementing the new rules for ECN tunnelling [RFC6040] or for PCN-domains without tunnels. Currently, it is not clear how fast the new tunnelling rules will be deployed and this affects the applicability of the full 3-in-1 encoding. Where PCN-domains do contain legacy tunnel endpoints, a restricted subset of the full 3-in-1 encoding can be used that omits the '01' codepoint.
したがって、完全な3-in-1エンコーディングは、ECNトンネリング[RFC6040]の新しいルールを実装するPCNドメインまたはトンネルのないPCNドメインにのみ使用できます。現在、新しいトンネリングルールがどれだけ速く展開されるかは明確ではなく、これは完全な3-in-1エンコーディングの適用性に影響します。 PCNドメインにレガシートンネルエンドポイントが含まれている場合、完全な3-in-1エンコーディングの制限されたサブセットを使用して、'01 'コードポイントを省略できます。
PCN encoding using 2 DSCPs to provide 3 or more states (3-in-2 encoding, [PCN-3-in-2]) uses two different DSCPs to accommodate the three required codepoints NM, ThM, and ETM. It leaves some codepoints currently unused (CU), and also proposes a way to reuse them to store some information about the content of the ECN field before the packet enters the PCN-domain. 3-in-2 encoding works well with IPsec tunnels (see Section 3.3.3.3). This type of encoding can support both CL-PCN and SM-PCN schemes.
2つのDSCPを使用して3つ以上の状態を提供するPCNエンコーディング（3-in-2エンコーディング、[PCN-3-in-2]）は、2つの異なるDSCPを使用して、3つの必要なコードポイントNM、ThM、およびETMに対応します。現在未使用のコードポイント（CU）がいくつか残っています。また、パケットがPCNドメインに入る前に、それらを再利用してECNフィールドの内容に関する情報を格納する方法も提案されています。 3-in-2エンコーディングはIPsecトンネルで適切に機能します（セクション3.3.3.3を参照）。このタイプのエンコーディングは、CL-PCNスキームとSM-PCNスキームの両方をサポートできます。
The disadvantage of 3-in-2 encoding is that it consumes two DSCPs. Further, if PCN is applied to more than one Diffserv traffic class, then two DSCPs are needed for each. Moreover, the direct application of this encoding scheme to other technologies like MPLS, where even fewer bits are available for the encoding of DSCPs, is more difficult.
3-in-2エンコーディングの欠点は、2つのDSCPを消費することです。さらに、PCNが複数のDiffservトラフィッククラスに適用される場合、それぞれに2つのDSCPが必要です。さらに、DSCPのエンコードに使用できるビットがさらに少ないMPLSなどの他のテクノロジーにこのエンコードスキームを直接適用することは、さらに困難です。
PCN encoding for packet-specific dual marking (PSDM) is designed to support PSDM-PCN outlined in Section 2.2.3. It is the only proposal that supports PCN-based AC and FT with only a single DSCP [PCN-PSDM] in the presence of IPsec tunnels (see Section 3.3.3.3). PSDM encoding also supports SM-PCN.
パケット固有デュアルマーキング（PSDM）のPCNエンコーディングは、セクション2.2.3で概説されているPSDM-PCNをサポートするように設計されています。これは、IPsecトンネルの存在下で単一のDSCP [PCN-PSDM]のみでPCNベースのACおよびFTをサポートする唯一の提案です（セクション3.3.3.3を参照）。 PSDMエンコーディングはSM-PCNもサポートします。
The baseline encoding described in Section 4.1 is defined in
[RFC5696]. The intention was to allow for experimental encodings to
build upon this baseline. However, following the publication of
[RFC6040], the working group decided to change its approach and
instead standardize only one encoding (the 3-in-1 encoding [RFC6660]
described in Section 4.2). Rather than defining the 3-in-1 encoding
as a Standards Track extension to the existing baseline encoding
[RFC5696], it was agreed that it is best to define a new Standards
Track document that obsoletes [RFC5696].
This document summarizes the PCN working group's exploration of a number of approaches for encoding pre-congestion information into the IP header. It is presented as an informational archive. It provides details of those approaches along with an explanation of the constraints that apply. The working group has concluded that the "3-in-1" encoding should be published as a Standards Track RFC that obsoletes the encoding specified in [RFC5696].
このドキュメントでは、PCNワーキンググループによる、輻輳前情報をIPヘッダーにエンコードするためのさまざまなアプローチの調査についてまとめています。情報アーカイブとして提供されます。適用される制約の説明とともに、それらのアプローチの詳細を提供します。ワーキンググループは、「3-in-1」エンコーディングは、[RFC5696]で指定されたエンコーディングを廃止するStandards Track RFCとして公開する必要があると結論付けました。
The reasoning is as follows. During the early life of the working group, the working group decided on an approach of a standardized "baseline" encoding [RFC5696], plus a series of experimental encodings that would all build on the baseline encoding, each of which would be useful in specific circumstances. However, after the tunneling of ECN was standardized in [RFC6040], the PCN working group decided on a different approach -- to recommend just one encoding, the "3-in-1 encoding".
その理由は次のとおりです。ワーキンググループの初期の頃、ワーキンググループは、標準化された「ベースライン」エンコーディング[RFC5696]のアプローチと、すべてがベースラインエンコーディングに基づいて構築される一連の実験的エンコーディングを決定しました。状況。ただし、ECNのトンネリングが[RFC6040]で標準化された後、PCNワーキンググループは別のアプローチを決定しました。1つのエンコーディング「3-in-1エンコーディング」のみを推奨することです。
Although in theory "3-in-1" could be specified as a Standards Track extension to the "baseline" encoding, the working group decided that it would be cleaner to obsolete [RFC5696] and specify "3-in-1" encoding in a new, stand-alone RFC.
理論的には「3-in-1」は「ベースライン」エンコーディングの標準トラック拡張として指定できますが、ワーキンググループは、廃止され[RFC5696]、「3-in-1」エンコーディングを新しいスタンドアロンRFC。
[RFC5559] provides a general description of the security considerations for PCN. This memo does not introduce additional security considerations.
[RFC5559]は、PCNのセキュリティに関する考慮事項の一般的な説明を提供します。このメモでは、セキュリティに関する追加の考慮事項は紹介されていません。
We would like to acknowledge the members of the PCN working group and Gorry Fairhust for the discussions that generated and improved the contents of this memo.
PCNワーキンググループのメンバーとGorry Fairhurstがこのメモの内容を生成し、改善した議論を行ったことを感謝します。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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月。
[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月。
[PCN-MS-AC] Menth, M. and R. Geib, "Admission Control Using PCN-Marked Signaling", Work in Progress, February 2011.
[PCN-MS-AC]メンス、M.、R。ガイブ、「PCNマーク付きシグナリングを使用したアドミッションコントロール」、進行中の作業、2011年2月。
[PCN-3-in-2] Briscoe, B., Moncaster, T., and M. Menth, "A PCN Encoding Using 2 DSCPs to Provide 3 or More States", Work in Progress, March 2012.
[PCN-3-in-2] Briscoe、B.、Moncaster、T。、およびM. Menth、「2つ以上のDSCPを使用して3つ以上の状態を提供するPCNエンコーディング」、作業中、2012年3月。
[PCN-PSDM] Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, "PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding)", Work in Progress, March 2012.
[PCN-PSDM] Menth、M.、Babiarz、J.、Moncaster、T。、およびB. Briscoe、「Packet-Specific Dual Marking（PSDM Encoding）のPCNエンコーディング」、作業中、2012年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、and S. Jamin、 "Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification"、RFC 2205、September 1997年
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「Differentiated Services and Tunnels」、RFC 2983、2000年10月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540] Spring、N.、Wetherall、D。、およびD. Ely、「Ronce Explicit Congestion Notification（ECN）Signaling with Nonces」、RFC 3540、2003年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559] Eardley、P。、編、「Pre-Congestion Notification（PCN）Architecture」、RFC 5559、2009年6月。
[RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670] Eardley、P。、編、「PCNノードの測定とマーキングの動作」、RFC 5670、2009年11月。
[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月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、2010年11月。
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, July 2012.
[RFC6660] Briscoe、B.、Moncaster、T。、およびM. Menth、「単一のDiffservコードポイント（DSCP）を使用したIPヘッダー内の3つの輻輳通知（PCN）状態のエンコード」、RFC 6660、2012年7月。
[RFC6661] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation", RFC 6661, July 2012.
[RFC6661] Charny、A.、Huang、F.、Karagiannis、G.、Meth、M。、およびT. Taylor、編、「制御負荷（CL）の事前輻輳通知（PCN）境界ノードの動作動作モード」、RFC 6661、2012年7月。
[RFC6662] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. Taylor, "Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation", RFC 6662, July 2012.
[RFC6662] Charny、A.、Zhang、J.、Karagiannis、G.、Meth、M。、およびT. Taylor、「シングルマーキング（SM）動作モードの事前輻輳通知（PCN）境界ノードの動作"、RFC 6662、2012年7月。
[Menth09] Menth, M., Babiarz, J., and P. Eardley, "Pre-Congestion Notification Using Packet-Specific Dual Marking", IEEE Proceedings of the International Workshop on the Network of the Future (Future-Net), Dresden/Germany, June 2009.
[Menth09] Menth、M.、Babiarz、J。、およびP. Eardley、「パケット固有のデュアルマーキングを使用した輻輳前通知」、IEEE Proceedings of the International Workshop on the Future of the Future（Future-Net）、ドレスデン/ドイツ、2009年6月。
[Menth12] Menth, M. and F. Lehrieder, "Performance of PCN-Based Admission Control under Challenging Conditions", IEEE/ACM Transactions on Networking, vol. 20, no. 2, April 2012.
[Menth12] Menth、M。、およびF. Lehrieder、「厳しい条件下でのPCNベースのアドミッションコントロールのパフォーマンス」、IEEE / ACM Transactions on Networking、vol。 20、いいえ。 2012年4月2日。
[Menth10] Menth, M. and F. Lehrieder, "PCN-Based Measured Rate Termination", Computer Networks Journal, vol. 54, no. 3, Sept. 2010
[Menth10] Menth、M。およびF. Lehrieder、「PCNベースの測定レート終了」、Computer Networks Journal、vol。 54、いいえ。 2010年9月3日
Authors' Addresses
著者のアドレス
Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands EMail: g.karagiannis@utwente.nl
ゲオルギオスカラギアニス大学トゥエンテP.O. Box 217 7500 AEオランダ、エンスヘーデEメール：g.karagiannis@utwente.nl
Kwok Ho Chan Consultant EMail: khchan.work@gmail.com
Kwak Ho Chanコンサルタントメール：khachan.work@gmail.com
Toby Moncaster University of Cambridge Computer Laboratory William Gates Building, J J Thomson Avenue Cambridge, CB3 0FD United Kingdom EMail: Toby.Moncaster@cl.cam.ac.uk
トビーモンカスターケンブリッジ大学コンピュータラボラトリーウィリアムゲイツビルディング、J Jトムソンアベニューケンブリッジ、CB3 0FDイギリスEメール：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
Philip Eardley BT B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom EMail: philip.eardley@bt.com
Philip Eardley BT B54 / 77、Sirius House Adastral Park Martlesham Heath Ipswich、Suffolk IP5 3REイギリスEメール：philip.eardley@bt.com
Bob Briscoe BT B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom EMail: bob.briscoe@bt.com
Bob Briscoe BT B54 / 77、Sirius House Adastral Park Martlesham Heath Ipswich、Suffolk IP5 3REイギリスEメール：bob.briscoe@bt.com