[要約] RFC 5559は、Pre-Congestion Notification（PCN）アーキテクチャに関するものであり、ネットワークの過負荷を事前に通知するための仕組みを提供する。その目的は、ネットワークの適切なリソース管理と、品質の低下を防ぐことである。
Network Working Group P. Eardley, Ed.
Request for Comments: 5559 BT
Category: Informational June 2009
Pre-Congestion Notification (PCN) Architecture
前構成通知（PCN）アーキテクチャ
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain.
このドキュメントでは、単一のdiffservドメイン内の確立された非弾性フローのサービスの品質を保護するための、事前の化学情報に基づいた流れの入場と終了の一般的なアーキテクチャについて説明します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Overview of PCN ............................................3
1.2. Example Use Case for PCN ...................................4
1.3. Applicability of PCN .......................................7
1.4. Documents about PCN ........................................8
2. Terminology .....................................................9
3. High-Level Functional Architecture .............................11
3.1. Flow Admission ............................................13
3.2. Flow Termination ..........................................14
3.3. Flow Admission and/or Flow Termination When There Are Only
Two PCN Encoding States ...................................15
3.4. Information Transport .....................................16
3.5. PCN-Traffic ...............................................16
3.6. Backwards Compatibility ...................................17
4. Detailed Functional Architecture ...............................18
4.1. PCN-Interior-Node Functions ...............................19
4.2. PCN-Ingress-Node Functions ................................19
4.3. PCN-Egress-Node Functions .................................20
4.4. Admission Control Functions ...............................21
4.5. Flow Termination Functions ................................22
4.6. Addressing ................................................22
4.7. Tunnelling ................................................23
4.8. Fault Handling ............................................25
5. Operations and Management ......................................25
5.1. Fault Operations and Management ...........................25
5.2. Configuration Operations and Management ...................26
5.2.1. System Options .....................................27
5.2.2. Parameters .........................................28
5.3. Accounting Operations and Management ......................30
5.4. Performance and Provisioning Operations and Management ....30
5.5. Security Operations and Management ........................31
6. Applicability of PCN ...........................................32
6.1. Benefits ..................................................32
6.2. Deployment Scenarios ......................................33
6.3. Assumptions and Constraints on Scope ......................35
6.3.1. Assumption 1: Trust and Support of PCN -
Controlled Environment .............................36
6.3.2. Assumption 2: Real-Time Applications ...............36
6.3.3. Assumption 3: Many Flows and Additional Load .......37
6.3.4. Assumption 4: Emergency Use Out of Scope ...........37
6.4. Challenges ................................................37
7. Security Considerations ........................................40
8. Conclusions ....................................................41
9. Acknowledgements ...............................................41
10. References ....................................................42
10.1. Normative References .....................................42
10.2. Informative References ...................................42
Appendix A. Possible Future Work Items ...........................48
A.1. Probing .................................................50
A.1.1. Introduction ....................................50
A.1.2. Probing Functions ...............................50
A.1.3. Discussion of Rationale for Probing, Its
Downsides and Open Issues .......................51
The objective of Pre-Congestion Notification (PCN) 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 (in abnormal circumstances) flow termination, to decide whether to terminate some of the existing flows. 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 congestion occurs (hence, "Pre-Congestion Notification"). The level of marking allows boundary nodes to make decisions about whether to admit or terminate.
事前相関通知（PCN）の目的は、シンプルでスケーラブルで堅牢なファッションで、Diffservドメイン内の非弾性フローのサービス品質（QoS）を保護することです。2つのメカニズムが使用されています。入場制御、新しいフローリクエストを認めるかブロックするかを決定するか、（異常な状況で）フロー終了、既存のフローの一部を終了するかどうかを決定します。これを達成するために、PCNトラフィックの全体的なレートは、ドメイン内のすべてのリンクでメーター化され、特定の構成レートを超えるとPCNパケットが適切にマークされます。これらの構成されたレートはリンクのレートを下回るため、輻輳が発生する前に過負荷に関する境界ノードに通知を提供します（したがって、「前の通知」）。マーキングのレベルにより、境界ノードは、認めるか終了するかを決定することができます。
Within a PCN-domain, PCN-traffic is forwarded in a prioritised Diffserv traffic class. Every link in the PCN-domain is configured with two rates (PCN-threshold-rate and PCN-excess-rate). If the overall rate of PCN-traffic on a link exceeds a configured rate, then a PCN-interior-node marks PCN-packets appropriately. The PCN-egress-nodes use this information to make admission control and flow termination decisions. Flow admission control determines whether a new flow can be admitted without any impact, in normal circumstances, on the QoS of existing PCN-flows. However, in abnormal circumstances (for instance, a disaster affecting multiple nodes and causing traffic re-routes), the QoS on existing PCN-flows may degrade even though care was exercised when admitting those flows. The flow termination mechanism removes sufficient traffic in order to protect the QoS of the remaining PCN-flows. All PCN-boundary-nodes and PCN-interior-nodes are PCN-enabled and are trusted for correct PCN operation. PCN-ingress-nodes police arriving packets to check that they are part of an admitted PCN-flow that keeps within its agreed flowspec, and hence they maintain per-flow state. PCN-interior-nodes meter all PCN-traffic, and hence do not need to maintain any per-flow state. Decisions about flow admission and termination are made for a particular pair of PCN-boundary-nodes, and hence PCN-egress-nodes must be able to identify which PCN-ingress-node sent each PCN-packet.
PCNドメイン内では、PCNトラフィックは優先順位付けされたDiffServトラフィッククラスに転送されます。PCNドメイン内のすべてのリンクは、2つのレート（PCN-Threshold-rateおよびPCN-Excess-rate）で構成されています。リンク上のPCNトラフィックの全体的なレートが設定されたレートを超える場合、PCNインターフェートノードはPCNパケットを適切にマークします。PCN-Egress-Nodesは、この情報を使用して、入学制御およびフロー終了の決定を行います。フロー入場制御により、通常の状況では、既存のPCNフローのQOに影響を与えることなく、新しいフローを認めることができるかどうかが判断されます。ただし、異常な状況では（たとえば、複数のノードに影響を与え、トラフィックの再ルーティングを引き起こす災害）、既存のPCNフローのQoSは、それらのフローを認めたときに注意を払っていても劣化する場合があります。フロー終了メカニズムは、残りのPCNフローのQOを保護するために十分なトラフィックを除去します。すべてのPCN結合ノードとPCNインタレオンノードはPCN対応であり、正しいPCN操作に対して信頼されています。PCN-ingress-Nodes警察は、合意されたFlowsPec内に保管されている認められたPCN-Flowの一部であることを確認するために到着します。PCN-Interior-NodesはすべてのPCNトラフィックをメーターにするため、流量あたりの状態を維持する必要はありません。Flow入院と終了に関する決定は、特定のPCNバウンダリーノードのペアに対して行われるため、PCN-Egress-Nodesは、各PCNパケットを送信したPCN-Ingress-Nodeを特定できる必要があります。
This section outlines an end-to-end QoS scenario that uses the PCN mechanisms within one domain. The parts outside the PCN-domain are out of scope for PCN, but are included to help clarify how PCN could be used. Note that this section is only an example -- in particular, there are other possibilities (see Section 3) for how the PCN-boundary-nodes perform admission control and flow termination.
このセクションでは、1つのドメイン内でPCNメカニズムを使用するエンドツーエンドのQoSシナリオの概要を説明します。PCNドメインの外側の部品はPCNの範囲外ですが、PCNの使用方法を明確にするために含まれています。このセクションは単なる例であることに注意してください。特に、PCNバウンドリーノードが入学制御とフロー終了を実行する方法については、他の可能性（セクション3を参照）があります。
As a fundamental building block, each link of the PCN-domain operates the following. Please refer to [Eardley09] and Figure 1.
基本的なビルディングブロックとして、PCNドメインの各リンクが以下を動作させます。[eardley09]および図1を参照してください。
o A threshold meter and marker, which marks all PCN-packets if the rate of PCN-traffic is greater than a first configured rate, the PCN-threshold-rate. The admission control mechanism limits the PCN-traffic on each link to *roughly* its PCN-threshold-rate.
o PCNトラフィックのレートが最初の構成レートであるPCN-Threchold-rateよりも大きい場合、すべてのPCNパケットをマークするしきい値計とマーカー。入場制御メカニズムは、各リンクのPCNトラフィックを「ほぼ *そのPCN網状レート」に制限します。
o An excess-traffic meter and marker, which marks a proportion of PCN-packets such that the amount marked equals the traffic rate in excess of a second configured rate, the PCN-excess-rate. The flow termination mechanism limits the PCN-traffic on each link to *roughly* its PCN-excess-rate.
o マークされた量が2番目の構成レートを超えるトラフィックレートであるPCN-Excess-rateを超えるように、PCNパケットの割合をマークする過剰な交通メーターとマーカー。フロー終了メカニズムは、各リンクのPCNトラフィックを「ほぼ *そのPCN-Excess-rate」に制限します。
Overall, the aim is to give an "early warning" of potential congestion before there is any significant build-up of PCN-packets in the queue on the link; we term this "Pre-Congestion Notification" by analogy with ECN (Explicit Congestion Notification, [RFC3168]). Note that the link only meters the bulk PCN-traffic (and not per flow).
全体として、目的は、リンク上のキューにPCNパケットが大幅に蓄積する前に、潜在的な輻輳の「早期警告」を与えることです。ECNとの類推により、この「前の通知」と呼ばれます（明示的な輻輳通知、[RFC3168]）。リンクは、バルクPCNトラフィック（フローごとではない）を計算するだけであることに注意してください。
== Metering & ==
==Marking behaviour== ==PCN mechanisms==
^
Rate of ^
PCN-traffic on |
bottleneck link |
|
| Some pkts Terminate some
| excess-traffic-marked admitted flows
| & &
| Rest of pkts Block new flows
| threshold-marked
|
PCN-excess-rate -|------------------------------------------------
(=PCN-supportable-rate)|
| All pkts Block new flows
| threshold-marked
|
PCN-threshold-rate -|------------------------------------------------
(=PCN-admissible-rate)|
| No pkts Admit new flows
| PCN-marked
|
Figure 1: Example of how the PCN admission control and flow termination mechanisms operate as the rate of PCN-traffic increases.
図1：PCNトラフィックの速度が増加するにつれて、PCN入容式制御およびフロー終了メカニズムがどのように機能するかの例。
The two forms of PCN-marking are indicated by setting the ECN and DSCP (Differentiated Services Codepoint [RFC2474]) fields to known values, which are configured for the domain. Thus, the PCN-egress-nodes can monitor the PCN-markings in order to measure the severity of pre-congestion. In addition, the PCN-ingress-nodes need to set the ECN and DSCP fields to that configured for an unmarked PCN-packet, and the PCN-egress-nodes need to revert to values appropriate outside the PCN-domain.
PCNマークの2つの形式は、eCNおよびDSCP（Distemiated Services CodePoint [RFC2474]）フィールドを既知の値に設定することで示されます。これらはドメイン用に構成されています。したがって、PCN-Egressノードは、事前の発電の重症度を測定するためにPCNマークを監視できます。さらに、PCN-ingressノードは、マークのないPCNパケット用に構成されているECNおよびDSCPフィールドを設定する必要があり、PCN-Egress-NodesはPCNドメインの外側の適切な値に戻す必要があります。
For admission control, we assume end-to-end RSVP (Resource Reservation Protocol) [RFC2205]) signalling in this example. The PCN-domain is a single RSVP hop. The PCN-domain operates Diffserv, and we assume that PCN-traffic is scheduled with the expedited forwarding (EF) per-hop behaviour [RFC3246]. Hence, the overall solution is in line with the "IntServ over Diffserv" framework defined in [RFC2998], as shown in Figure 2.
入学制御のために、この例では、エンドツーエンドのRSVP（リソース予約プロトコル）[RFC2205]）シグナル伝達を想定しています。PCNドメインは単一のRSVPホップです。PCNドメインはdiffservを動作させ、PCNトラフィックが迅速な転送（EF）の行動（RFC3246]でスケジュールされていると仮定します。したがって、図2に示すように、全体的なソリューションは[RFC2998]で定義されている「diffserv over diffserv」フレームワークに沿っています。
___ ___ _______________________________________ ____ ___
| | | | | PCN- PCN- PCN- | | | | |
| | | | |ingress interior egress| | | | |
| | | | | -node -nodes -node | | | | |
| | | | |-------+ +-------+ +-------+ +------| | | | |
| | | | | | | PCN | | PCN | | | | | | |
| |..| |..|Ingress|..|meter &|..|meter &|..|Egress|..| |..| |
| |..| |..|Policer|..|marker |..|marker |..|Meter |..| |..| |
| | | | |-------+ +-------+ +-------+ +------| | | | |
| | | | | \ / | | | | |
| | | | | \ / | | | | |
| | | | | \ PCN-feedback-information / | | | | |
| | | | | \ (for admission control) / | | | | |
| | | | | --<-----<----<----<-----<-- | | | | |
| | | | | PCN-feedback-information | | | | |
| | | | | (for flow termination) | | | | |
|___| |___| |_______________________________________| |____| |___|
Sx Access PCN-domain Access Rx
End Network Network End
Host Host
<---- signalling across PCN-domain--->
(for admission control & flow termination)
<-------------------end-to-end QoS signalling protocol--------------->
Figure 2: Example of possible overall QoS architecture.
図2：QoSアーキテクチャ全体の可能性の例。
A source wanting to start a new QoS flow sends an RSVP PATH message. Normal hop-by-hop IntServ [RFC1633] is used outside the PCN-domain (we assume successfully). The PATH message travels across the PCN-domain; the PCN-egress-node reads the PHOP (previous RSVP hop) object to discover the specific PCN-ingress-node for this flow. The RESV message travels back from the receiver, and triggers the PCN-egress-node to check what fraction of the PCN-traffic from the relevant PCN-ingress-node is currently being threshold-marked. It adds an object with this information onto the RESV message, and hence the PCN-ingress-node learns about the level of pre-congestion on the path. If this level is below some threshold, then the PCN-ingress-node admits the new flow into the PCN-domain. The RSVP message triggers the PCN-ingress-node to install two normal IntServ items: five-tuple information, so that it can subsequently identify data packets that are part of a previously admitted PCN-flow, and a traffic profile, so that it can police the flow to within its reservation. Similarly, the RSVP message triggers the PCN-egress-node to install five-tuple and PHOP information so that it can identify packets as part of a flow from a specific PCN-ingress-node.
新しいQoSフローを起動したいソースは、RSVPパスメッセージを送信します。通常のホップバイホップintServ [RFC1633]は、PCNドメインの外で使用されます（正常に想定しています）。PATHメッセージはPCNドメインを横切って移動します。PCN-Egress-Nodeは、PHOP（前のRSVPホップ）オブジェクトを読み取り、このフローの特定のPCN-ingressノードを発見します。RESVメッセージは受信機から戻り、PCN-Egress-Nodeをトリガーして、関連するPCN-Ingress-NodeからのPCNトラフィックの割合が現在しきい値でマークされています。この情報がRESVメッセージにオブジェクトを追加するため、PCN-Ingress-Nodeはパス上の事前相関レベルについて学習します。このレベルが何らかのしきい値を下回っている場合、PCN-ingressノードはPCNドメインへの新しいフローを認めます。RSVPメッセージはPCN-ingress-Nodeをトリガーして、2つの通常のIntServアイテムの2つの通常の情報をインストールします。これにより、以前に認められたPCN-Flowの一部であるデータパケットとトラフィックプロファイルを識別できるため、その予約内の流れを警察します。同様に、RSVPメッセージはPCN-Egress-Nodeをトリガーして、特定のPCN-Ingress-Nodeからのフローの一部としてパケットを識別できるように、5タプルおよびPHOP情報をインストールします。
The flow termination mechanism may happen when some abnormal circumstance causes a link to become so pre-congested that it excess-traffic-marks (and perhaps also drops) PCN-packets. In this example, when a PCN-egress-node observes such a packet, it then, with some probability, terminates this PCN-flow; the probability is configured low enough to avoid over termination and high enough to ensure rapid termination of enough flows. It also informs the relevant PCN-ingress-node so that it can block any further traffic on the terminated flow.
フロー終了メカニズムは、異常な状況がリンクを事前に組み合わせてPCNパケットを過剰に（おそらくドロップする）ほど事前に発生させると発生する可能性があります。この例では、PCN-Egress-Nodeがそのようなパケットを観察すると、ある程度の確率でこのPCN-Flowを終了します。確率は、過度の終了を回避するのに十分なほど低く構成され、十分なフローの迅速な終了を確保するのに十分な高さになります。また、関連するPCN-ingress-Nodeに通知して、終了したフローのトラフィックをさらにブロックできるようにします。
Compared with alternative QoS mechanisms, PCN has certain advantages and disadvantages that will make it appropriate in particular scenarios. For example, compared with hop-by-hop IntServ [RFC1633], PCN only requires per-flow state at the PCN-ingress-nodes. Compared with the Diffserv architecture [RFC2475], an operator needs to be less accurate and/or conservative in its prediction of the traffic matrix. The Diffserv architecture's traffic-conditioning agreements are static and coarse; they are defined at subscription time and are used (for instance) to limit the total traffic at each ingress of the domain, regardless of the egress for the traffic. On the other hand, PCN firstly uses admission control based on measurements of the current conditions between the specific pair of PCN-boundary-nodes, and secondly, in case of a disaster, PCN protects the QoS of most flows by terminating a few selected ones.
代替QoSメカニズムと比較して、PCNには特定の利点と短所があり、特定のシナリオで適切になります。たとえば、Hop-by-Hop IntServ [RFC1633]と比較して、PCNはPCN-ingressノードでの流量ごとの状態のみを必要とします。diffservアーキテクチャ[RFC2475]と比較して、オペレーターはトラフィックマトリックスの予測において、より正確ではなく保守的である必要があります。Diffserv Architectureの交通条件付け契約は静的で粗いです。それらはサブスクリプション時に定義されており、トラフィックの出口に関係なく、ドメインの各侵入での合計トラフィックを制限するために（たとえば）使用されます。一方、PCNはまず、特定のPCNバウンダリーノードの間の現在の条件の測定に基づいて入学制御を使用し、第二に、災害の場合、PCNはいくつかの選択されたフローを終了することにより、ほとんどのフローのQOを保護します。。
PCN's admission control is a measurement-based mechanism. Hence, it assumes that the present is a reasonable prediction of the future: the network conditions are measured at the time of a new flow request, but the actual network performance must be acceptable during the call some time later. Hence, PCN is unsuitable in several circumstances:
PCNの入場制御は、測定ベースのメカニズムです。したがって、現在は将来の合理的な予測であると想定しています。ネットワーク条件は、新しいフロー要求の時点で測定されますが、実際のネットワークパフォーマンスは、しばらくしてからの電話中に受け入れられる必要があります。したがって、PCNはいくつかの状況では不適切です。
o If the source adapts its bit rate dependent on the level of pre-congestion, because then the aggregate traffic might become unstable. The assumption in this document is that PCN-packets come from real-time applications generating inelastic traffic, such as the Controlled Load Service [RFC2211].
o ソースが、総トラフィックが不安定になる可能性があるため、事前相関のレベルに依存するビットレートを適応させる場合。このドキュメントの仮定は、PCNパケットが制御された負荷サービス[RFC2211]などの非弾性トラフィックを生成するリアルタイムアプリケーションから得られることです。
o If a potential bottleneck link has capacity for only a few flows, because then a new flow can move a link directly from no pre-congestion to being so overloaded that it has to drop packets. The assumption in this document is that this isn't a problem.
o 潜在的なボトルネックリンクがいくつかのフローのみの容量を持っている場合、新しいフローはリンクを事前前から直接移動して、パケットをドロップする必要があるほど過負荷になっているためです。このドキュメントの仮定は、これが問題ではないということです。
o If there is the danger of a "flash crowd", in which many admission requests arrive within the reaction time of PCN's admission mechanism, because then they all might get admitted and so overload the network. The assumption in this document is that, if it is necessary, then flash crowds are limited in some fashion beyond the scope of this document, for instance by rate-limiting QoS requests.
o 「フラッシュクラウド」の危険がある場合、多くの入場リクエストがPCNの入場メカニズムの反応時間内に到着します。このドキュメントの仮定は、それが必要な場合、たとえばレート制限QoSリクエストにより、このドキュメントの範囲を超えて何らかの形でフラッシュクラウドが制限されるということです。
The applicability of PCN is discussed further in Section 6.
PCNの適用性については、セクション6でさらに説明します。
The purpose of this document is to describe a general architecture for flow admission and termination based on (pre-)congestion information in order to protect the quality of service of flows within a Diffserv domain. This document describes the PCN architecture at a high level (Section 3) and in more detail (Section 4). It also defines some terminology, and provides considerations about operations, management, and security. Section 6 considers the applicability of PCN in more detail, covering its benefits, deployment scenarios, assumptions, and potential challenges. The Appendix covers some potential future work items.
このドキュメントの目的は、Diffservドメイン内のフローのサービス品質を保護するために、（事前）混雑情報に基づいたフロー入場と終了の一般的なアーキテクチャを説明することです。このドキュメントでは、高レベル（セクション3）およびより詳細（セクション4）でのPCNアーキテクチャについて説明します。また、いくつかの用語を定義し、運用、管理、セキュリティに関する考慮事項を提供します。セクション6では、PCNの適用性をより詳細に検討し、その利点、展開シナリオ、仮定、および潜在的な課題をカバーします。付録は、将来の潜在的な作業項目をいくつかカバーしています。
Aspects of PCN are also documented elsewhere:
PCNの側面も他の場所で文書化されています。
o Metering and marking: [Eardley09] standardises threshold metering and marking and excess-traffic metering and marking. A PCN-packet may be marked, depending on the metering results.
o 計量とマーキング：[eardley09]標準化しきい値計測とマーキングと過剰なトラフィックメーターとマーキングを標準化します。計量結果に応じて、PCNパケットにマークされる場合があります。
o Encoding: the "baseline" encoding is described in [Moncaster09-1], which standardises two PCN encoding states (PCN-marked and not PCN-marked), whilst (experimental) extensions to the baseline encoding can provide three encoding states (threshold-marked, excess-traffic-marked, or not PCN-marked), for instance, see [Moncaster09-2]. (There may be further encoding states as suggested in [Westberg08].) Section 3.6 considers the backwards compatibility of PCN encoding with ECN.
o エンコーディング：「ベースライン」エンコードは[Moncaster09-1]で説明されています。これは、2つのPCNエンコード状態（PCNマーク化されており、PCNマーク化されていない）を標準化し、ベースラインエンコードの（実験的）拡張は3つのエンコーディング状態を提供できます（しきい値 - たとえば、[Moncaster09-2]を参照してください。（[Westberg08]で提案されているように、さらにエンコード状態がある場合があります。）セクション3.6では、ECNとのエンコードの後方互換性を考慮します。
o PCN-boundary-node behaviour: how the PCN-boundary-nodes convert the PCN-markings into decisions about flow admission and flow termination, as described in Informational documents such as [Taylor09] and [Charny07-2]. The concept is that the standardised metering and marking by PCN-nodes allows several possible PCN-boundary-node behaviours. A number of possibilities are outlined in this document; detailed descriptions and comparisons are in [Charny07-1] and [Menth09-2].
o PCNバウンダリーノードの動作：[Taylor09]や[charny07-2]などの情報ドキュメントで説明されているように、PCNバウンダリーノードがPCNマークをフロー入院とフロー終了に関する決定にどのように変換するか。概念は、PCNノードによる標準化された計量とマーキングにより、いくつかの可能なPCN結合ノードの動作が可能になるということです。このドキュメントでは、多くの可能性が概説されています。詳細な説明と比較は[charny07-1]および[menth09-2]にあります。
o Signalling between PCN-boundary-nodes: signalling is needed to transport PCN-feedback-information between the PCN-boundary-nodes (in the example above, this is the fraction of traffic, between the pair of PCN-boundary-nodes, that is PCN-marked). The exact details vary for different PCN-boundary-node behaviours, and so should be described in those documents. It may require an extension to the signalling protocol -- standardisation is out of scope of the PCN WG.
o PCNバウンダリーノード間のシグナル伝達：PCN-バウンドリーノード間のPCNフィードバック情報を輸送するためにシグナリングが必要です（上記の例では、これはPCNバウンドリーノードのペア間のトラフィックの割合です。PCNマーク）。正確な詳細は、PCNバウンダリーノードの異なる動作で異なるため、これらのドキュメントで説明する必要があります。シグナル伝達プロトコルの拡張が必要になる場合があります - 標準化はPCN WGの範囲外です。
o The interface by which the PCN-boundary-nodes learn identification information about the admitted flows: the exact requirements vary for different PCN-boundary-node behaviours and for different signalling protocols, and so should be described in those documents. They will be similar to those described in the example above -- a PCN-ingress-node needs to be able to identify that a packet is part of a previously admitted flow (typically from its five-tuple) and each PCN-boundary-node needs to be able to identify the other PCN-boundary-node for the flow.
o PCNバウンダリーノードが認められたフローに関する識別情報を学習するインターフェイス：正確な要件は、異なるPCNバウンダリーノードの動作と異なるシグナル伝達プロトコルに対して異なるため、これらのドキュメントで説明する必要があります。それらは上記の例で説明されているものと似ています - PCN-ingressノードは、パケットが以前に認められたフロー（通常は5タプルから）の一部であることを識別できる必要があります。フローの他のPCNバウンダリーノードを識別できる必要があります。
o PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled nodes that perform Diffserv scheduling [RFC2474]; the complete set of PCN-nodes that in principle can, through PCN-marking packets, influence decisions about flow admission and termination for the PCN-domain; includes the PCN-egress-nodes, which measure these PCN-marks, and the PCN-ingress-nodes.
o PCNドメイン：PCN対応ドメイン。DiffServスケジューリング[RFC2474]を実行するPCN対応ノードの連続的なセット。原則として、PCNマークパケットを介して、PCNドメインの流れの入院と終了に関する決定に影響を与えることができるPCNノードの完全なセット。これらのPCNマークを測定するPCN-Egress-NodesとPCN-Ingress-Nodesが含まれます。
o PCN-boundary-node: a PCN-node that connects one PCN-domain to a node either in another PCN-domain or in a non-PCN-domain.
o PCN-Boundary-Node：1つのPCNドメインを別のPCNドメインまたは非PCNドメインのいずれかのノードに接続するPCNノード。
o PCN-interior-node: a node in a PCN-domain that is not a PCN-boundary-node.
o PCN-Interior-Node：PCNバウンダリーノードではないPCNドメイン内のノード。
o PCN-node: a PCN-boundary-node or a PCN-interior-node.
o PCN-NODE：PCN-Boundary-NodeまたはPCN-Interior-Node。
o PCN-egress-node: a PCN-boundary-node in its role in handling traffic as it leaves a PCN-domain.
o PCN-Egress-Node：PCNドメインを離れる際のトラフィックの処理における役割におけるPCNバウンダリーノード。
o PCN-ingress-node: a PCN-boundary-node in its role in handling traffic as it enters a PCN-domain.
o PCN-INGRESS-NODE：PCNドメインに入るときのトラフィックの処理における役割におけるPCNバウンダリーノード。
o PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of different Diffserv behaviour aggregates (BAs) [RFC2474]. The PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the corresponding packets are PCN-packets. The same network will carry traffic of other Diffserv BAs. The PCN-BA is distinguished by a combination of the Diffserv codepoint (DSCP) and ECN fields.
o PCN-Traffic、PCN-Packets、PCN-BA：PCNドメインは、異なるDiffServ行動凝集体（BAS）のトラフィックを運びます[RFC2474]。PCN-BAはPCNメカニズムを使用してPCNトラフィックを運び、対応するパケットはPCNパケットです。同じネットワークは、他のdiffserv BASのトラフィックを運びます。PCN-BAは、DiffServ CodePoint（DSCP）とECNフィールドの組み合わせによって区別されます。
o PCN-flow: the unit of PCN-traffic that the PCN-boundary-node admits (or terminates); the unit could be a single microflow (as defined in [RFC2474]) or some identifiable collection of microflows.
o PCN-FLOW：PCNバウンドリーノードが認めた（または終了）PCNトラフィックの単位。ユニットは、単一のマイクロフロー（[RFC2474]で定義されている）またはマイクロフローの識別可能なコレクションである可能性があります。
o Pre-congestion: a condition of a link within a PCN-domain such that the PCN-node performs PCN-marking, in order to provide an "early warning" of potential congestion before there is any significant build-up of PCN-packets in the real queue. (Hence, by analogy with ECN, we call our mechanism Pre-Congestion Notification.)
o 事前相関：PCNノードがPCNマルキングを実行するようにPCNドメイン内のリンクの条件。本当のキュー。（したがって、ECNとの類似性により、メカニズムに事前の通知を呼び出します。）
o PCN-marking: the process of setting the header in a PCN-packet based on defined rules, in reaction to pre-congestion; either threshold-marking or excess-traffic-marking. Such a packet is then called PCN-marked.
o PCN-Marking：事前相関に反応して、定義されたルールに基づいてヘッダーをPCNパケットに設定するプロセス。しきい値マークまたは過剰なトラフィックマークのいずれか。そのようなパケットは、PCNマークと呼ばれます。
o Threshold-metering: a metering behaviour that, if the PCN-traffic exceeds the PCN-threshold-rate, indicates that all PCN-traffic is to be threshold-marked.
o しきい値計測：PCNトラフィックがPCN網状レートを超える場合、すべてのPCNトラフィックがしきい値マークであることを示します。
o PCN-threshold-rate: the reference rate of a threshold-meter, which is configured for each link in the PCN-domain and which is lower than the PCN-excess-rate.
o PCN-reshold-rate：PCNドメインの各リンクに対して構成され、PCN-Excess-rateよりも低いしきい値メーターの参照レート。
o Threshold-marking: the setting of the header in a PCN-packet to a specific encoding, based on indications from the threshold-meter. Such a packet is then called threshold-marked.
o しきい値マーク：しきい値メーターからの適応に基づいて、PCNパケット内の特定のエンコードへのヘッダーの設定。そのようなパケットは、しきい値マークと呼ばれます。
o Excess-traffic-metering: a metering behaviour that, if the PCN-traffic exceeds the PCN-excess-rate, indicates that the amount of PCN-traffic to be excess-traffic-marked is equal to the amount in excess of the PCN-excess-rate.
o 過剰な交通量メタリング：PCNトラフィックがPCNエクスケスレートを超える場合、過剰なトラフィックマークであるPCNトラフィックの量がPCNを超える量に等しいことを示します。過剰率。
o PCN-excess-rate: the reference rate of an excess-traffic-meter, which is a configured for each link in the PCN-domain and which is higher than the PCN-threshold-rate.
o PCN-EXCESS-RATE：PCNドメインの各リンクに構成された過剰な交通量メーターの参照レートで、PCN-Threshold-rateよりも高い。
o Excess-traffic-marking: the setting of the header in a PCN-packet to a specific encoding, based on indications from the excess-traffic-meter. Such a packet is then called excess-traffic-marked.
o 過剰な交通量のマーク：過剰なトラフィックメーターからの適応症に基づいて、PCNパケット内の特定のエンコードへのヘッダーの設定。このようなパケットは、過剰なトラフィックマークと呼ばれます。
o PCN-colouring: the process of setting the header in a PCN-packet by a PCN-boundary-node; performed by a PCN-ingress-node so that PCN-nodes can easily identify PCN-packets; performed by a PCN-egress-node so that the header is appropriate for nodes beyond the PCN-domain.
o PCN色：PCNバウンドリーノードによってPCNパケットにヘッダーを設定するプロセス。PCNノードがPCNパケットを簡単に識別できるように、PCN-ingressノードによって実行されます。ヘッダーがPCNドメインを超えたノードに適しているようにPCN-Egress-Nodeによって実行されます。
o Ingress-egress-aggregate: The collection of PCN-packets from all PCN-flows that travel in one direction between a specific pair of PCN-boundary-nodes.
o Ingress-Egress-Aggregate：特定のPCN結合ノードの間を一方向に移動するすべてのPCNフローからのPCNパケットのコレクション。
o PCN-feedback-information: information signalled by a PCN-egress-node to a PCN-ingress-node (or a central control node), which is needed for the flow admission and flow termination mechanisms.
o PCN-Feedback-Information：PCN-Egress-NodeによってPCN-Ingressノード（または中央制御ノード）に合図された情報。これは、流れの入場およびフロー終了メカニズムに必要です。
o PCN-admissible-rate: the rate of PCN-traffic on a link up to which PCN admission control should accept new PCN-flows.
o PCN-Missible-rate：PCN入学制御が新しいPCN-Flowsを受け入れるリンク上のPCNトラフィックのレート。
o PCN-supportable-rate: the rate of PCN-traffic on a link down to which PCN flow termination should, if necessary, terminate already admitted PCN-flows.
o PCN-Supportable-Rate：必要に応じて、PCNフロー終了が既に認められているPCNフローを終了するリンク上のPCNトラフィックのレート。
The high-level approach is to split functionality between:
高レベルのアプローチは、次の間の機能を分割することです。
o PCN-interior-nodes "inside" the PCN-domain, which monitor their own state of pre-congestion and mark PCN-packets as appropriate. They are not flow-aware, nor are they aware of ingress-egress-aggregates. The functionality is also done by PCN-ingress-nodes for their outgoing interfaces (ie, those "inside" the PCN-domain).
o PCNインタレオンノードは、PCNドメインの「内部」であり、必要に応じてPCNドメインを監視し、PCNパケットをマークします。彼らは流れを覚えておらず、侵入侵入と攻撃を認識していません。この機能は、発信インターフェイス（つまり、PCNドメインの「内部」）に対してPCN-ingress-Nodesによっても行われます。
o PCN-boundary-nodes at the edge of the PCN-domain, which control admission of new PCN-flows and termination of existing PCN-flows, based on information from PCN-interior-nodes. This information is in the form of the PCN-marked data packets (which are intercepted by the PCN-egress-nodes) and is not in signalling messages. Generally, PCN-ingress-nodes are flow-aware.
o PCNインターネールノードからの情報に基づいて、新しいPCNフローの入場と既存のPCNフローの終了を制御するPCNドメインの端にあるPCNバウンドリーノード。この情報は、PCNマークされたデータパケット（PCN-Egress-Nodesによって傍受されます）の形式であり、メッセージが表示されていません。一般的に、PCN-ingressノードはフローアウェアです。
The aim of this split is to keep the bulk of the network simple, scalable, and robust, whilst confining policy, application-level, and security interactions to the edge of the PCN-domain. For example, the lack of flow awareness means that the PCN-interior-nodes don't care about the flow information associated with PCN-packets, nor do the PCN-boundary-nodes care about which PCN-interior-nodes its ingress-egress-aggregates traverse.
この分割の目的は、ネットワークの大部分をシンプルでスケーラブルで堅牢に保つことでありながら、PCNドメインの端にポリシー、アプリケーションレベル、セキュリティの相互作用を制限することです。たとえば、流れの認識の欠如は、PCNインターリアノードがPCNパケットに関連付けられたフロー情報を気にしないことを意味します。また、PCNバウンダリーノードは、PCN-Interior-Nodeがその侵入術をどのPCNに侵入するかについて気にしません。 - トラバースを集めます。
In order to generate information about the current state of the PCN-domain, each PCN-node PCN-marks packets if it is "pre-congested". Exactly when a PCN-node decides if it is "pre-congested" (the algorithm) and exactly how packets are "PCN-marked" (the encoding) will be defined in separate Standards Track documents, but at a high level it is as follows: o the algorithms: a PCN-node meters the amount of PCN-traffic on each one of its outgoing (or incoming) links. The measurement is made as an aggregate of all PCN-packets, not per flow. There are two algorithms: one for threshold-metering and one for excess-traffic-metering. The meters trigger PCN-marking as necessary.
PCNドメインの現在の状態に関する情報を生成するために、各PCNノードPCNマークパケットが「事前に測定されている」場合。PCNノードが「事前に組み合わされた」（アルゴリズム）であるかどうか、およびパケットが「PCNマーク化」（エンコード）が別々の標準トラックドキュメントで定義されるかどうかを正確に決定したときに次のとおりです。Oアルゴリズム：A PCNノードメートルは、発信（または着信）リンクのそれぞれにPCNトラフィックの量を計算します。測定は、フローごとではなく、すべてのPCNパケットの集合体として作成されます。2つのアルゴリズムがあります。1つはしきい値計算用、もう1つは過剰な交通量を取得するためです。メーターは、必要に応じてPCNマークをトリガーします。
o the encoding(s): a PCN-node PCN-marks a PCN-packet by modifying a combination of the DSCP and ECN fields. In the "baseline" encoding [Moncaster09-1], the ECN field is set to 11 and the DSCP is not altered. Extension encodings may be defined that, at most, use a second DSCP (eg, as in [Moncaster09-2]) and/or set the ECN field to values other than 11 (eg, as in [Menth08-2]).
o エンコーディング（S）：PCNノードPCNは、DSCPとECNフィールドの組み合わせを変更することにより、PCNパケットをマークします。[Moncaster09-1]をコードする「ベースライン」では、ECNフィールドは11に設定され、DSCPは変更されません。拡張エンコーディングは、せいぜい2番目のDSCP（[Moncaster09-2]のように）を使用し、/またはECNフィールドを11以外の値（[Menth08-2]のように）以外の値に設定することを定義する場合があります。
In a PCN-domain, the operator may have two or three encoding states available. The baseline encoding provides two encoding states (not PCN-marked and PCN-marked), whilst extended encodings can provide three encoding states (not PCN-marked, threshold-marked, and excess-traffic-marked).
PCNドメインでは、オペレーターは2つまたは3つのエンコード状態を利用できる場合があります。ベースラインエンコーディングは、2つのエンコード状態（PCNマーク化およびPCNマーク化されていない）を提供しますが、拡張エンコーディングは3つのエンコード状態（PCNマーク、しきい値マーク、および過剰なトラフィックマークなし）を提供できます。
An operator may choose to deploy either admission control or flow termination or both. Although designed to work together, they are independent mechanisms, and the use of one does not require or prevent the use of the other. Three encoding states naturally allows both flow admission and flow termination. If there are only two encoding states, then there are several options -- see Section 3.3.
オペレーターは、入場制御またはフロー終了、またはその両方を展開することを選択できます。協力するように設計されていますが、それらは独立したメカニズムであり、一方の使用は他のメカニズムを必要としないか、防止しません。3つのエンコーディング状態は、自然に流れの入場とフロー終了の両方を可能にします。エンコード状態が2つしかない場合、いくつかのオプションがあります。セクション3.3を参照してください。
The PCN-boundary-nodes monitor the PCN-marked packets in order to extract information about the current state of the PCN-domain. Based on this monitoring, a distributed decision is made about whether to admit a prospective new flow or terminate existing flow(s). Sections 4.4 and 4.5 mention various possibilities for how the functionality could be distributed.
PCNバウンダリーノードは、PCNドメインの現在の状態に関する情報を抽出するために、PCNマークされたパケットを監視します。この監視に基づいて、将来の新しい流れを認めるか、既存の流れを終了するかについて、分散された決定が下されます。セクション4.4および4.5は、機能をどのように分散できるかについてのさまざまな可能性に言及しています。
PCN-metering and PCN-marking need to be configured on all (potentially pre-congested) links in the PCN-domain to ensure that the PCN mechanisms protect all links. The actual functionality can be configured on the outgoing or incoming interfaces of PCN-nodes -- or one algorithm could be configured on the outgoing interface and the other on the incoming interface. The important point is that a consistent choice is made across the PCN-domain to ensure that the PCN mechanisms protect all links. See [Eardley09] for further discussion.
PCNメタリングとPCNマークは、PCNドメインのすべての（潜在的に事前に事前に）リンクで構成する必要があります。実際の機能は、PCNノードの発信または着信インターフェイスで構成できます。または、1つのアルゴリズムを発信インターフェイスで、もう1つは着信インターフェイスで構成できます。重要な点は、PCNメカニズムがすべてのリンクを保護することを保証するために、PCNドメイン全体で一貫した選択が行われることです。詳細については、[eardley09]を参照してください。
The objective of threshold-marking, as triggered by the threshold-metering algorithm, is to threshold-mark all PCN-packets whenever the bit rate of PCN-packets is greater than some configured rate, the PCN-threshold-rate. The objective of excess-traffic-metering, as triggered by the excess-traffic-marking algorithm, is to excess- traffic-mark PCN-packets at a rate equal to the difference between the bit rate of PCN-packets and some configured rate, the PCN-excess-rate. Note that this description reflects the overall intent of the algorithms rather than their instantaneous behaviour, since the rate measured at a particular moment depends on the detailed algorithm, its implementation, and the traffic's variance as well as its rate (eg, marking may well continue after a recent overload, even after the instantaneous rate has dropped). The algorithms are specified in [Eardley09].
しきい値を取るアルゴリズムによってトリガーされるように、しきい値マークの目的は、PCNパケットのビットレートが構成されたレート、PCNスレッジレートよりも大きい場合、しきい値マークをすべてのPCNパケットにしきい値にマークすることです。過剰な人身売買アルゴリズムによってトリガーされるように、過剰な交通量計量の目的は、PCNパケットのビットレートと構成されたレートの差の差に等しいレートで過剰なトラフィックマークPCNパケットであることです。PCN-Excess-rate。特定の瞬間に測定されたレートは、詳細なアルゴリズム、その実装、トラフィックの分散、およびそのレートに依存するため、この説明は瞬間的な動作ではなく、アルゴリズムの全体的な意図を反映していることに注意してください（例えば、マークはよく続く場合があります最近の過負荷の後、瞬時の速度が低下した後でも）。アルゴリズムは[eardley09]で指定されています。
Admission and termination approaches are detailed and compared in [Charny07-1] and [Menth09-2]. The discussion below is just a brief summary. Sections 3.1 and 3.2 assume there are three encoding states available, whilst Section 3.3 assumes there are two encoding states available.
入院と終了のアプローチが詳細になり、[charny07-1]および[menth09-2]で比較されます。以下の議論は、簡単な要約です。セクション3.1および3.2は、利用可能な3つのエンコーディング状態があると仮定し、セクション3.3では、2つのエンコード状態が利用できると仮定しています。
From the perspective of the outside world, a PCN-domain essentially looks like a Diffserv domain, but without the Diffserv architecture's traffic-conditioning agreements. PCN-traffic is either transported across it transparently or policed at the PCN-ingress-node (ie, dropped or carried at a lower QoS). One difference is that PCN-traffic has better QoS guarantees than normal Diffserv traffic because the PCN mechanisms better protect the QoS of admitted flows. Another difference may occur in the rare circumstance when there is a failure: on the one hand, some PCN-flows may get terminated but, on the other hand, other flows will get their QoS restored. Non-PCN-traffic is treated transparently, ie, the PCN-domain is a normal Diffserv domain.
外の世界の観点から見ると、PCNドメインは本質的にDiffServドメインのように見えますが、DiffServ Architectureの交通条件付け契約はありません。PCNトラフィックは、透過的に輸送されるか、PCN-ingressノードでポリシングされます（つまり、低いQOでドロップまたは運ばれます）。1つの違いは、PCNメカニズムが認められたフローのQOをよりよく保護するため、PCNトラフィックは通常のDiffServトラフィックよりも優れたQoS保証を持っていることです。障害がある場合、まれな状況では別の違いが発生する可能性があります。一方では、一部のPCNフローが終了する場合がありますが、他方では、他のフローがQOを復元します。非PCNトラフィックは透過的に処理されます。つまり、PCNドメインは通常のDiffservドメインです。
The objective of PCN's flow admission control mechanism is to limit the PCN-traffic on each link in the PCN-domain to *roughly* its PCN-admissible-rate by admitting or blocking prospective new flows, in order to protect the QoS of existing PCN-flows. With three encoding states available, the PCN-threshold-rate is configured by the operator as equal to the PCN-admissible-rate on each link. It is set lower than the traffic rate at which the link becomes congested and the node drops packets.
PCNのフローアドミス制御メカニズムの目的は、既存のPCNのQOを保護するために、PCNドメインの各リンクのPCNトラフィックを「大まかに *そのPCN補給率」に制限することです。-流れ。3つのエンコーディング状態が利用可能で、PCN-sredhold-rateは、各リンクのPCN補給率に等しいとして演算子によって構成されます。リンクが混雑し、ノードがパケットをドロップするトラフィックレートよりも低く設定されています。
Exactly how the admission control decision is made will be defined separately in Informational documents. This document describes two approaches (others might be possible):
正確には、入場管理の決定が行われる方法は、情報文書で個別に定義されます。このドキュメントでは、2つのアプローチについて説明しています（他のアプローチが可能かもしれません）。
o The PCN-egress-node measures (possibly as a moving average) the fraction of the PCN-traffic that is threshold-marked. The fraction is measured for a specific ingress-egress-aggregate. If the fraction is below a threshold value, then the new flow is admitted; if the fraction is above the threshold value, then it is blocked. The fraction could be measured as an EWMA (exponentially weighted moving average), which has sometimes been called the "congestion level estimate".
o PCN-Egress-Nodeは（おそらく移動平均として）、しきい値がマークされているPCNトラフィックの割合を測定します。分数は、特定の侵入侵入攻撃に対して測定されます。画分がしきい値を下回っている場合、新しいフローが認められます。画分がしきい値を上回っている場合、ブロックされます。画分は、EWMA（指数関数的に重み付けされた移動平均）として測定できます。これは、「混雑レベルの推定」と呼ばれることがあります。
o The PCN-egress-node monitors PCN-traffic and if it receives one (or several) threshold-marked packets, then the new flow is blocked; otherwise, it is admitted. One possibility may be to react to the marking state of an initial flow-setup packet (eg, RSVP PATH). Another is that after one (or several) threshold-marks, all flows are blocked until after a specific period of no congestion.
o PCN-Egress-NodeはPCNトラフィックを監視し、1つ（または複数）のしきい値マーク付きパケットを受信した場合、新しいフローがブロックされます。そうでなければ、それは認められています。1つの可能性は、初期のフローセットアップパケットのマーキング状態（たとえば、RSVPパス）に反応することです。もう1つは、1つ（または複数の）しきい値マークの後、すべてのフローが渋滞のない特定の期間の後までブロックされることです。
Note that the admission control decision is made for a particular pair of PCN-boundary-nodes. So it is quite possible for a new flow to be admitted between one pair of PCN-boundary-nodes, whilst at the same time another admission request is blocked between a different pair of PCN-boundary-nodes.
特定のPCN結合ノードのペアについては、入場管理の決定が下されることに注意してください。したがって、1つのPCNバウンダリーノードの間で新しいフローを認めることは非常に可能ですが、同時に別の入場リクエストが異なるPCNバウンドリーノードの間でブロックされます。
The objective of PCN's flow termination mechanism is to limit the PCN-traffic on each link to *roughly* its PCN-supportable-rate, by terminating some existing PCN-flows, in order to protect the QoS of the remaining PCN-flows. With three encoding states available, the PCN-excess-rate is configured by the operator as equal to the PCN-supportable-rate on each link. It may be set lower than the traffic rate at which the link becomes congested and at which the node drops packets.
PCNのフロー終了メカニズムの目的は、残りのPCNフローのQoSを保護するために、既存のPCNフローを終了することにより、各リンクのPCNトラフィックを *大体 *そのPCNサポート可能レートに制限することです。3つのエンコーディング状態が利用可能で、PCN-Excess-rateは、各リンクのPCNサポート可能レートに等しいとして演算子によって構成されます。リンクが混雑し、ノードがパケットをドロップするトラフィックレートよりも低く設定される場合があります。
Exactly how the flow termination decision is made will be defined separately in Informational documents. This document describes several approaches (others might be possible):
フロー終了の決定が行われる方法は、情報文書で個別に定義されます。このドキュメントでは、いくつかのアプローチについて説明しています（他のアプローチが可能かもしれません）：
o In one approach, the PCN-egress-node measures the rate of PCN-traffic that is not excess-traffic-marked, which is the amount of PCN-traffic that can actually be supported, and communicates this to the PCN-ingress-node. Also, the PCN-ingress-node measures the rate of PCN-traffic that is destined for this specific PCN-egress-node. The difference represents the excess amount that should be terminated.
o 1つのアプローチでは、PCN-Egress-Nodeは、過剰なトラフィックマークされていないPCNトラフィックのレートを測定します。。また、PCN-ingress-Nodeは、この特定のPCN-Egress-Nodeに運命づけられているPCNトラフィックのレートを測定します。違いは、終了するべき過剰量を表します。
o Another approach instead measures the rate of excess-traffic-marked traffic and terminates this amount of traffic. This terminates less traffic than the previous approach, if some nodes are dropping PCN-traffic.
o 代わりに、別のアプローチは、交通量の多いトラフィックのレートを測定し、この量のトラフィックを終了します。これにより、一部のノードがPCNトラフィックをドロップしている場合、これにより以前のアプローチよりも少ないトラフィックが終了します。
o Another approach monitors PCN-packets and terminates some of the PCN-flows that have an excess-traffic-marked packet. (If all such flows were terminated, far too much traffic would be terminated, so a random selection needs to be made from those with an excess-traffic-marked packet [Menth08-1].)
o 別のアプローチは、PCNパケットを監視し、トラフィックマークされた過剰なパケットを持つPCN-Flowの一部を終了します。（そのようなフローがすべて終了した場合、あまりにも多くのトラフィックが終了するため、トラフィックマークの過剰なパケットを持つ人からランダムな選択を行う必要があります[Menth08-1]。）
Since flow termination is designed for "abnormal" circumstances, it is quite likely that some PCN-nodes are congested and, hence, that packets are being dropped and/or significantly queued. The flow termination mechanism must accommodate this.
フロー終了は「異常な」状況向けに設計されているため、一部のPCNノードが混雑しているため、パケットがドロップされており、著しくキューになっている可能性が非常に高いです。フロー終了メカニズムはこれに対応する必要があります。
Note also that the termination control decision is made for a particular pair of PCN-boundary-nodes. So it is quite possible for PCN-flows to be terminated between one pair of PCN-boundary-nodes, whilst at the same time none are terminated between a different pair of PCN-boundary-nodes.
また、特定のPCN結合ノードのペアに対して終了制御決定が行われることに注意してください。したがって、PCN-Flowsを1つのPCNバウンドリーノード間で終了することは非常に可能ですが、同時に、PCN結合ノードの異なるペア間で終了するものはありません。
If a PCN-domain has only two encoding states available (PCN-marked and not PCN-marked), ie, it is using the baseline encoding [Moncaster09-1], then an operator has three options (others might be possible):
PCNドメインには、利用可能な2つのエンコード状態（PCNマークとPCNマークではなく）のみがある場合、つまり、[Moncaster09-1]をエンコードするベースラインを使用している場合、演算子には3つのオプションがあります（他のものが可能かもしれません）。
o admission control only: PCN-marking means threshold-marking, ie, only the threshold-metering algorithm triggers PCN-marking. Only PCN admission control is available.
o 入場制御のみ：PCNマークは、しきい値マーク、つまり、しきい値を取得するアルゴリズムのみがPCNマークをトリガーすることを意味します。PCN入容策のみが利用可能です。
o flow termination only: PCN-marking means excess-traffic-marking, ie, only the excess-traffic-metering algorithm triggers PCN-marking. Only PCN termination control is available.
o フロー終了のみ：PCNマーキングとは、過剰な交通マーク、すなわち、過剰な交通量を取得するアルゴリズムのみがPCNマークをトリガーすることを意味します。PCN終了制御のみが利用可能です。
o both admission control and flow termination: only the excess-traffic-metering algorithm triggers PCN-marking; however, the configured rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as shown in Figure 3. [Charny07-2] describes how both admission control and flow termination can be triggered in this case and also gives some pros and cons of this approach. The main downside is that admission control is less accurate.
o 入学制御とフロー終了の両方：過剰な交通量を取得するアルゴリズムのみがPCNマークをトリガーします。ただし、図3に示すように、構成されたレート（PCN-Excess-rate）はPCN-Admissible-rateに等しく設定されています。このアプローチの長所と短所を提供します。主な欠点は、入学制御がそれほど正確ではないことです。
== Metering & ==
==Marking behaviour== ==PCN mechanisms==
^
Rate of ^
PCN-traffic on |
bottleneck link | Terminate some
| admitted flows
| &
| Block new flows
|
| Some pkts
U*PCN-excess-rate -| excess-traffic-marked -----------------
(=PCN-supportable-rate)|
| Block new flows
|
|
PCN-excess-rate -|------------------------------------------------
(=PCN-admissible-rate)|
| No pkts Admit new flows
| PCN-marked
|
Figure 3: Schematic of how the PCN admission control and flow termination mechanisms operate as the rate of PCN-traffic increases, for a PCN-domain with two encoding states and using the approach of [Charny07-2]. Note: U is a global parameter for all links in the PCN-domain.
図3：2つのエンコーディング状態を持つPCNドメインと[charny07-2]のアプローチを使用するPCNトラフィックの速度が増加するにつれて、PCN入容式制御およびフロー終了メカニズムがどのように機能するかの概略図。注：Uは、PCNドメインのすべてのリンクのグローバルパラメーターです。
The transport of pre-congestion information from a PCN-node to a PCN-egress-node is through PCN-markings in data packet headers, ie, "in-band"; no signalling protocol messaging is needed. Signalling is needed to transport PCN-feedback-information -- for example, to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node. Exactly what information needs to be transported will be described in future documents about possible boundary mechanisms. The signalling could be done by an extension of RSVP or NSIS (Next Steps in Signalling), for instance; [Lefaucheur06] describes the extensions needed for RSVP.
PCNノードからPCN-Egress-Nodeへの事前調節情報の輸送は、データパケットヘッダー、つまり「In-Band」のPCNマークスを介しています。シグナリングプロトコルメッセージは必要ありません。PCNフィードバック情報を輸送するには、たとえばPCNマークされたトラフィックの割合をPCN-Egress-Nodeから関連するPCN-Ingress-Nodeに伝達するために、シグナリングが必要です。正確に輸送する必要がある情報は、可能な境界メカニズムに関する将来の文書で説明されます。シグナリングは、たとえばRSVPまたはNSIS（シグナルの次のステップ）の拡張によって行うことができます。[lefaucheur06]は、RSVPに必要な拡張機能を説明しています。
The following are some high-level points about how PCN works:
以下は、PCNの仕組みに関するいくつかの高レベルのポイントです。
o There needs to be a way for a PCN-node to distinguish PCN-traffic from other traffic. This is through a combination of the DSCP field and/or ECN field.
o PCNノードがPCNトラフィックを他のトラフィックと区別する方法が必要です。これは、DSCPフィールドと/またはECNフィールドの組み合わせによるものです。
o It is not advised to have competing-non-PCN-traffic but, if there is such traffic, there needs to be a mechanism to limit it. "Competing-non-PCN-traffic" means traffic that shares a link with PCN-traffic and competes for its forwarding bandwidth. Hence, more competing-non-PCN-traffic results in poorer QoS for PCN. Further, the unpredictable amount of competing-non-PCN-traffic makes the PCN mechanisms less accurate and so reduces PCN's ability to protect the QoS of admitted PCN-flows.
o 競合することはありませんが、競合することはお勧めしませんが、そのようなトラフィックがある場合は、それを制限するメカニズムが必要です。「競合する非PCNトラフィック」とは、PCNトラフィックとリンクを共有し、転送帯域幅を競うトラフィックを意味します。したがって、PCNのQoSがより低いと、より競合する非PCNトラフィックの結果が得られます。さらに、予測不可能な量の競合している量の-PCNトラフィックにより、PCNメカニズムの精度が低下するため、入院したPCNフローのQoSを保護するPCNの能力が低下します。
o Two examples of such competing-non-PCN-traffic are:
o このような競合する非PCNトラフィックの2つの例は次のとおりです。
1. traffic that is priority scheduled over PCN (perhaps a particular application or an operator's control messages);
1. PCN（おそらく特定のアプリケーションまたはオペレーターのコントロールメッセージ）でスケジュールされる優先度のあるトラフィック。
2. traffic that is scheduled at the same priority as PCN (for example, if the Voice-Admit codepoint is used for PCN-traffic [Moncaster09-1] and there is non-PCN, voice-admit traffic in the PCN-domain).
2. PCNと同じ優先順位でスケジュールされるトラフィック（たとえば、Voice-Admit CodePointがPCNトラフィック[Moncaster09-1]に使用され、PCNドメインに非PCN、音声補助金トラフィックがある場合）。
o If there is such competing-non-PCN-traffic, then PCN's mechanisms should take account of it, in order to improve the accuracy of the decision about whether to admit (or terminate) a PCN-flow. For example, one mechanism is that such competing-non-PCN-traffic contributes to the PCN-meters (ie, is metered by the threshold-marking and excess-traffic-marking algorithms).
o そのような競合する非PCNトラフィックがある場合、PCNフローを認める（または終了する）かどうかについての決定の正確性を改善するために、PCNのメカニズムがそれを考慮する必要があります。たとえば、1つのメカニズムは、このような競合する非PCNトラフィックがPCNメートルに寄与することです（つまり、しきい値マークと過剰なトラフィックマークアルゴリズムによって計算されます）。
o There will be other non-PCN-traffic that doesn't compete for the same forwarding bandwidth as PCN-traffic, because it is forwarded at lower priority. Hence, it shouldn't contribute to the PCN-meters. Examples are best-effort and assured-forwarding traffic. However, a PCN-node should dedicate some capacity to lower-priority traffic so that it isn't starved.
o PCNトラフィックと同じ転送帯域幅を競わない他の非PCNトラフィックがあります。これは、より低い優先度で転送されるためです。したがって、PCNメートルに貢献するべきではありません。例は、ベストエフォルトで確実な装備のトラフィックです。ただし、PCNノードは、飢えていないように、より低い範囲のトラフィックに何らかの能力を捧げる必要があります。
o This document assumes that the PCN mechanisms are applied to a single behaviour aggregate in the PCN-domain. However, it would also be possible to apply them independently to more than one behaviour aggregate, which are distinguished by DSCP.
o このドキュメントは、PCNメカニズムがPCNドメインの単一の動作集合体に適用されることを前提としています。ただし、DSCPによって区別される複数の動作集合体に独立して適用することもできます。
PCN specifies semantics for the ECN field that differ from the default semantics of [RFC3168]. A particular PCN encoding scheme needs to describe how it meets the guidelines of BCP 124 [RFC4774] for specifying alternative semantics for the ECN field. In summary, the approach is to:
PCNは、[RFC3168]のデフォルトセマンティクスとは異なるECNフィールドのセマンティクスを指定します。特定のPCNエンコーディングスキームは、ECNフィールドの代替セマンティクスを指定するために、BCP 124 [RFC4774]のガイドラインをどのように満たすかを説明する必要があります。要約すると、アプローチは次のとおりです。
o use a DSCP to allow PCN-nodes to distinguish PCN-traffic that uses the alternative ECN semantics;
o DSCPを使用して、PCNノードが代替ECNセマンティクスを使用するPCNトラフィックを区別できるようにします。
o define these semantics for use within a controlled region, the PCN-domain;
o 制御された領域であるPCNドメイン内で使用するこれらのセマンティクスを定義します。
o take appropriate action if ECN-capable, non-PCN-traffic arrives at a PCN-ingress-node with the DSCP used by PCN.
o ECN対応の場合、非PCNトラフィックがPCNで使用されているDSCPを使用してPCN-ingress-Nodeに到着した場合は、適切なアクションを実行します。
For the baseline encoding [Moncaster09-1], the "appropriate action" is to block ECN-capable traffic that uses the same DSCP as PCN from entering the PCN-domain directly. "Blocking" means it is dropped or downgraded to a lower-priority behaviour aggregate, or alternatively such traffic may be tunnelled through the PCN-domain. The reason that "appropriate action" is needed is that the PCN-egress-node clears the ECN field to 00.
[Moncaster09-1]をコードするベースラインの場合、「適切なアクション」は、PCNと同じDSCPを使用するECN対応トラフィックをブロックすることです。「ブロッキング」とは、低程度の行動骨材にドロップまたはダウングレードされることを意味します。あるいは、そのようなトラフィックがPCNドメインを介してトンネルにされる場合があります。「適切なアクション」が必要である理由は、PCN-Egress-NodeがECNフィールドを00にクリアするためです。
Extended encoding schemes may need to take different "appropriate action".
拡張されたエンコードスキームは、異なる「適切なアクション」を取る必要がある場合があります。
This section is intended to provide a systematic summary of the new functional architecture in the PCN-domain. First, it describes functions needed at the three specific types of PCN-node; these are data plane functions and are in addition to the normal router functions for PCN-nodes. Then, it describes the further functionality needed for both flow admission control and flow termination; these are signalling and decision-making functions, and there are various possibilities for where the functions are physically located. The section is split into:
このセクションは、PCNドメインの新しい機能アーキテクチャの体系的な要約を提供することを目的としています。まず、3つの特定のタイプのPCNノードで必要な関数について説明します。これらはデータプレーン機能であり、PCNノードの通常のルーター関数に追加されます。次に、フロー入場制御とフロー終了の両方に必要なさらなる機能を説明します。これらはシグナル伝達と意思決定機能であり、機能が物理的に位置する場所にはさまざまな可能性があります。セクションは次のように分割されています。
1. functions needed at PCN-interior-nodes
1. PCNインタールノードで必要な関数
2. functions needed at PCN-ingress-nodes
2. PCN-Ingress-Nodesで必要な関数
3. functions needed at PCN-egress-nodes
3. PCN-Egress-Nodesで必要な関数
4. other functions needed for flow admission control
4. フロー入場制御に必要なその他の機能
5. other functions needed for flow termination control
5. フロー終了制御に必要な他の機能
Note: Probing is covered in the Appendix.
注：プロービングは付録に記載されています。
The section then discusses some other detailed topics:
次に、このセクションでは、他の詳細なトピックについて説明します。
1. addressing
1. アドレッシング
2. tunnelling
2. トンネリング
3. fault handling
3. 障害処理
Each link of the PCN-domain is configured with the following functionality:
PCNドメインの各リンクは、次の機能で構成されています。
o Behaviour aggregate classification - determine whether or not an incoming packet is a PCN-packet.
o 動作集約分類 - 着信パケットがPCNパケットであるかどうかを判断します。
o PCN-meter - measure the "amount of PCN-traffic". The measurement is made on the overall PCN-traffic, not per flow. Algorithms determine whether to indicate to the PCN-marking functionality that packets should be PCN-marked.
o PCN-Meter-「PCNトラフィックの量」を測定します。測定は、フローごとではなく、全体的なPCNトラフィックで行われます。アルゴリズムは、パケットをPCNマーク化する必要があることをPCNマーク機能に示すかどうかを決定します。
o PCN-mark - as triggered by indications from the PCN-meter functionality; if necessary, PCN-mark packets with the appropriate encoding.
o PCN-Mark- PCNメートル機能からの適応によってトリガーされた。必要に応じて、適切なエンコードを備えたPCNマークパケット。
o Drop - if the queue overflows, then naturally packets are dropped. In addition, the link may be configured with a maximum rate for PCN-traffic (below the physical link rate), above which PCN-packets are dropped.
o ドロップ - キューがオーバーフローする場合、自然にパケットがドロップされます。さらに、リンクは、PCNトラフィック（物理リンクレート以下）の最大レートで構成され、その上でPCNパケットが削除されます。
The functions are defined in [Eardley09] and the baseline encoding in [Moncaster09-1] (extended encodings are to be defined in other documents).
関数は[eardley09]で定義され、[moncaster09-1]でエンコードされるベースライン（拡張エンコーディングは他のドキュメントで定義されます）。
+---------+ Result
+->|Threshold|-------+
| | Meter | |
| +---------+ V
+----------+ +- - - - -+ | +------+
| BA | | | | | | Marked
Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet
Stream | | | | | | | Stream
+----------+ +- - - - -+ | +------+
| +---------+ ^
| | Excess | |
+->| Traffic |-------+
| Meter | Result
+---------+
Figure 4: Schematic of PCN-interior-node functionality.
図4：PCN-Interior-Node機能の概略図。
Each ingress link of the PCN-domain is configured with the following functionality: o Packet classification - determine whether an incoming packet is part of a previously admitted flow by using a filter spec (eg, DSCP, source and destination addresses, port numbers, and protocol).
PCNドメインの各イングレスリンクは、次の機能で構成されています。Oパケット分類 - 入ってくるパケットがフィルター仕様（DSCP、ソース、宛先番号、ポート番号、および宛先番号、および宛先番号、および宛先番号、および宛先番号、および宛先の一部を使用して、以前に入院したフローの一部であるかどうかを判断します。プロトコル）。
o Police - police, by dropping any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) Similarly, police packets that are part of a previously admitted flow, to check that the flow keeps to the agreed rate or flowspec (eg, see [RFC1633] for a microflow and its NSIS equivalent).
o 警察 - 警察、入院した流れに属さないPCN輸送を示すDSCPで受け取ったパケットをドロップすることにより。（拒否された将来のPCN-Flowは、より低優先順位の動作の集合体にブロックまたは認められる可能性があります。）同様に、以前に認められたフローの一部である警察パケットは、フローが合意されたレートまたはFlowsPecに維持されることを確認するために（例：、マイクロフローとそのNSIS相当について[RFC1633]を参照してください）。
o PCN-colour - set the DSCP and ECN fields appropriately for the PCN-domain, for example, as in [Moncaster09-1].
o PCN-Colour-[Moncaster09-1]のように、PCNドメインにDSCPおよびECNフィールドを適切に設定します。
o Meter - some approaches to flow termination require the PCN-ingress-node to measure the (aggregate) rate of PCN-traffic towards a particular PCN-egress-node.
o メーター - フロー終了へのアプローチでは、特定のPCN-Egress-Nodeに対するPCNトラフィックの（凝集）レートを測定するためにPCN-ingress-Nodeが必要です。
The first two are policing functions, needed to make sure that PCN-packets admitted into the PCN-domain belong to a flow that has been admitted and to ensure that the flow keeps to the flowspec agreed (eg, doesn't exceed an agreed maximum rate and is inelastic traffic). Installing the filter spec will typically be done by the signalling protocol, as will re-installing the filter, for example, after a re-route that changes the PCN-ingress-node (see [Briscoe06] for an example using RSVP). PCN-colouring allows the rest of the PCN-domain to recognise PCN-packets.
最初の2つはポリシング関数であり、PCNドメインに入院したPCNパケットが認められたフローに属し、フローが同意したフローが維持されるようにするために必要です（例えば、合意された最大値を超えませんレートで非弾性トラフィックです）。フィルター仕様のインストールは、通常、シグナリングプロトコルによって実行されます。たとえば、RSVPを使用した例については、PCN-ingressノードを変更する再ルーティングの後にフィルターを再インストールします。PCNカラーにより、PCNドメインの残りの部分がPCNパケットを認識できます。
Each egress link of the PCN-domain is configured with the following functionality:
PCNドメインの各出口リンクは、次の機能で構成されています。
o Packet classify - determine which PCN-ingress-node a PCN-packet has come from.
o Packet classify-どのPCN-ingress-nodeがPCNパケットから来たかを決定します。
o Meter - "measure PCN-traffic" or "monitor PCN-marks".
o メーター - 「PCNトラフィックを測定」または「PCN-Marksをモニター」します。
o PCN-colour - for PCN-packets, set the DSCP and ECN fields to the appropriate values for use outside the PCN-domain.
o PCN-COLOUR-PCNパケットの場合、DSCPおよびECNフィールドをPCNドメイン以外で使用するための適切な値に設定します。
The metering functionality, of course, depends on whether it is targeted at admission control or flow termination. Alternatives involve the PCN-egress-node "measuring", as an aggregate (ie, not per flow), all PCN-packets from a particular PCN-ingress-node, or "monitoring" the PCN-traffic and reacting to one (or several) PCN- marked packets. For PCN-colouring, [Moncaster09-1] specifies that the PCN-egress-node resets the ECN field to 00; other encodings may define different behaviour.
もちろん、計量機能は、入場制御またはフロー終了を標的とするかどうかに依存します。代替案には、総計（つまり、フローごとではなく）、特定のPCN-ingressノードからのすべてのPCNパケット、またはPCN-Trafficを「監視」して1つに反応する（または（または）PCN-Egress-Nodeの「測定」が含まれます。いくつか）PCN-マークされたパケット。PCN色の場合、[Moncaster09-1]は、PCN-Egress-NodeがECNフィールドを00にリセットすることを指定します。他のエンコーディングは、異なる動作を定義する場合があります。
As well as the functions covered above, other specific admission control functions need to be performed (others might be possible):
上記の関数と同様に、他の特定の入場制御機能を実行する必要があります（他のものが可能かもしれません）。
o Make decision about admission - based on the output of the PCN-egress-node's meter function. In the case where it "measures PCN-traffic", the measured traffic on the ingress-egress-aggregate is compared with some reference level. In the case where it "monitors PCN-marks", the decision is based on whether or not one (or several) packets are PCN-marked (eg, the RSVP PATH message). In either case, the admission decision also takes account of policy and application-layer requirements [RFC2753].
o PCN-Egress-Nodeのメーター関数の出力に基づいて、入場について決定します。「PCNトラフィックを測定する」場合、イングレス侵入攻撃の測定されたトラフィックを参照レベルと比較します。「PCN-Marksを監視する」場合、決定は、1つ（または複数の）パケットがPCNマーク化されているかどうかに基づいています（たとえば、RSVPパスメッセージ）。いずれの場合も、入学決定では、ポリシーとアプリケーション層の要件も考慮されています[RFC2753]。
o Communicate decision about admission - signal the decision to the node making the admission control request (which may be outside the PCN-domain) and to the policer (PCN-ingress-node function) for enforcement of the decision.
o 入場に関する決定を伝えます - 決定を施行するために、入場制御要求（PCNドメインの外側にある可能性がある）およびポリサー（PCN-ingress-Node関数）に決定を行うノードに決定を合図します。
There are various possibilities for how the functionality could be distributed (we assume the operator will configure which is used):
機能をどのように分散できるかにはさまざまな可能性があります（オペレーターが使用されるものを構成すると仮定します）：
o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node.
o 決定はPCN-Egress-Nodeで行われ、決定（ADMITまたはブロック）がPCN-ingress-Nodeに通知されます。
o The decision is recommended by the PCN-egress-node (admit or block), but the decision is definitively made by the PCN-ingress-node. The rationale is that the PCN-egress-node naturally has the necessary information about the amount of PCN-marks on the ingress-egress-aggregate, whereas the PCN-ingress-node is the policy enforcement point [RFC2753] that polices incoming traffic to ensure it is part of an admitted PCN-flow.
o この決定は、PCN-Egress-Node（ADMITまたはBLOCK）によって推奨されますが、決定はPCN-Ingress-Nodeによって決定的に行われます。理論的根拠は、PCN-Egress-Nodeには自然に、Ingress-Egress-AggregateのPCNマークの量に関する必要な情報があるのに対し、PCN-Ingress-Nodeはポリシー執行ポイント[RFC2753]であるということです。認められたPCN-Flowの一部であることを確認してください。
o The decision is made at the PCN-ingress-node, which requires that the PCN-egress-node signals PCN-feedback-information to the PCN-ingress-node. For example, it could signal the current fraction of PCN-traffic that is PCN-marked.
o この決定は、PCN-Egress-NodeがPCN-Ingress-NodeにPCN-Feedback-Informationを信号する必要があるPCN-Ingress-Nodeで行われます。たとえば、PCNマークであるPCNトラフィックの現在の割合を示すことができます。
o The decision is made at a centralised node (see Appendix).
o 決定は集中ノードで行われます（付録を参照）。
Note: Admission control functionality is not performed by normal PCN-interior-nodes.
注：中間制御機能は、通常のPCNインターリアノードによって実行されません。
As well as the functions covered above, other specific termination control functions need to be performed (others might be possible):
上記の関数と同様に、他の特定の終了制御関数を実行する必要があります（他のものが可能かもしれません）。
o PCN-meter at PCN-egress-node - similarly to flow admission, there are two types of possibilities: to "measure PCN-traffic" on the ingress-egress-aggregate, or to "monitor PCN-marks" and react to one (or several) PCN-marks.
o PCN-Egress-NodeのPCN-Meter-流れの入場と同様に、2つのタイプの可能性があります。Ingress-Egress-Aggregateで「PCNトラフィックを測定」するか、「PCN-Markを監視」して1つに反応する（またはいくつか）PCN-Marks。
o (if required) PCN-meter at PCN-ingress-node - make "measurements of PCN-traffic" being sent towards a particular PCN-egress-node; again, this is done for the ingress-egress-aggregate and not per flow.
o （必要に応じて）PCN-Ingress-NodeのPCN-Meter-特定のPCN-Egress-Nodeに送信される「PCNトラフィックの測定」を作成します。繰り返しますが、これは、フローごとではなく、イングレスエグレスアグレジェートに対して行われます。
o (if required) Communicate PCN-feedback-information to the node that makes the flow termination decision - for example, as in [Briscoe06], communicate the PCN-egress-node's measurements to the PCN-ingress-node.
o （必要に応じて）PCNフィードバック情報をノードに伝え、たとえば[briscoe06]のようにフロー終了決定を行うように、PCN-Egress-Nodeの測定値をPCN-Ingress-Nodeに伝えます。
o Make decision about flow termination - use the information from the PCN-meter(s) to decide which PCN-flow or PCN-flows to terminate. The decision takes account of policy and application-layer requirements [RFC2753].
o フロー終了について決定します - PCNメーターからの情報を使用して、終了するPCN-FlowまたはPCN-Flowを決定します。この決定は、ポリシーとアプリケーション層の要件を考慮しています[RFC2753]。
o Communicate decision about flow termination - signal the decision to the node that is able to terminate the flow (which may be outside the PCN-domain) and to the policer (PCN-ingress-node function) for enforcement of the decision.
o フロー終了に関する決定を伝えます - フロー（PCNドメインの外側にある可能性がある）を終了できるノードと、決定の執行のためのポリサー（PCN-ingress-Node関数）に決定を合図します。
There are various possibilities for how the functionality could be distributed, similar to those discussed above in Section 4.4.
セクション4.4で上記で説明したものと同様に、機能をどのように分散できるかにはさまざまな可能性があります。
Note: Flow termination functionality is not performed by normal PCN-interior-nodes.
注：フロー終了機能は、通常のPCNインタートゥノードによって実行されません。
PCN-nodes may need to know the address of other PCN-nodes. Note that PCN-interior-nodes don't need to know the address of other PCN-nodes (except their next-hop neighbours for routing purposes).
PCNノードは、他のPCNノードのアドレスを知る必要がある場合があります。PCN-Interior-Nodesは、他のPCNノードのアドレスを知る必要はないことに注意してください（ルーティングの目的で次のホップの隣人を除く）。
At a minimum, the PCN-egress-node needs to know the address of the PCN-ingress-node associated with a flow so that the PCN-ingress-node can be informed of the admission decision (and any flow termination decision) and enforce it through policing. There are various possibilities for how the PCN-egress-node can do this, ie, associate the received packet to the correct ingress-egress-aggregate. It is not the intention of this document to mandate a particular mechanism.
少なくとも、PCN-Egress-Nodeは、フローに関連付けられたPCN-ingress-Nodeのアドレスを知る必要があるため、PCN-ingress-Nodeに入学決定（およびフロー終了決定）を通知して施行できるようにする必要があります。それはポリシングを通して。PCN-Egress-Nodeがこれを行う方法、つまり、受信したパケットを正しいIngress-Egress-Aggregateに関連付ける方法には、さまざまな可能性があります。特定のメカニズムを義務付けることは、このドキュメントの意図ではありません。
o The addressing information can be gathered from signalling -- for example, through the regular processing of an RSVP PATH message, as the PCN-ingress-node is the previous RSVP hop (PHOP) ([Lefaucheur06]). Another option is that the PCN-ingress-node could signal its address to the PCN-egress-node.
o PCN-ingress-Nodeは以前のRSVPホップ（PHOP）（[lefaucheur06]）であるため、アドレス指定情報はシグナリングから収集できます。別のオプションは、PCN-ingress-NodeがそのアドレスをPCN-Egress-Nodeに通知できることです。
o Always tunnel PCN-traffic across the PCN-domain. Then the PCN-ingress-node's address is simply the source address of the outer packet header. The PCN-ingress-node needs to learn the address of the PCN-egress-node, either by manual configuration or by one of the automated tunnel endpoint discovery mechanisms (such as signalling or probing over the data route, interrogating routing, or using a centralised broker).
o 常にPCNドメイン全体でPCNトラフィックをトンネルしてください。次に、PCN-Ingress-Nodeのアドレスは、単に外側のパケットヘッダーのソースアドレスです。PCN-Ingress-Nodeは、手動構成または自動トンネルエンドポイント発見メカニズムのいずれかで、PCN-Egress-Nodeのアドレスを学習する必要があります（データルートのシグナリングまたはプローブ、ルーティングの尋問、または使用の使用、または集中ブローカー）。
Tunnels may originate and/or terminate within a PCN-domain (eg, IP over IP, IP over MPLS). It is important that the PCN-marking of any packet can potentially influence PCN's flow admission control and termination -- it shouldn't matter whether the packet happens to be tunnelled at the PCN-node that PCN-marks the packet, or indeed whether it's decapsulated or encapsulated by a subsequent PCN-node. This suggests that the "uniform conceptual model" described in [RFC2983] should be re-applied in the PCN context. In line with both this and the approach of [RFC4303] and [Briscoe09], the following rule is applied if encapsulation is done within the PCN-domain:
トンネルは、PCNドメイン内で発生および/または終了する場合があります（たとえば、IP経由IP、MPLSを超えるIP）。パケットのPCNマークがPCNのフロー入場制御と終了に潜在的に影響を与える可能性があることが重要です。パケットがPCNノードでパケットをマークすることがあるかどうか、または実際にパケットがPCNノードでトンネルに登録されているかどうかは関係ありません。後続のPCNノードによって脱カプセル化またはカプセル化されています。これは、[RFC2983]に記載されている「均一な概念モデル」をPCNコンテキストで再適用すべきであることを示唆しています。これと[RFC4303]と[briscoe09]のアプローチの両方に沿って、PCNドメイン内でカプセル化が行われる場合、次のルールが適用されます。
o Any PCN-marking is copied into the outer header.
o PCNマークは、外側のヘッダーにコピーされます。
Note: A tunnel will not provide this behaviour if it complies with [RFC3168] tunnelling in either mode, but it will if it complies with [RFC4301] IPsec tunnelling.
注：トンネルは、いずれかのモードで[RFC3168]トンネリングに準拠している場合、この動作を提供しませんが、[RFC4301] IPSECトンネルに準拠している場合にはなります。
Similarly, in line with the "uniform conceptual model" of [RFC2983], with the "full-functionality option" of [RFC3168], and with [RFC4301], the following rule is applied if decapsulation is done within the PCN-domain:
同様に、[RFC2983]の「均一な概念モデル」、[RFC3168]の「フル機能性オプション」、および[RFC4301]に沿って、PCNドメイン内で脱カプセル化が行われる場合、次のルールが適用される場合、次のルールが適用されます。
o If the outer header's marking state is more severe, then it is copied onto the inner header.
o 外側のヘッダーのマーキング状態がより深刻な場合、それは内側のヘッダーにコピーされます。
Note that the order of increasing severity is: not PCN-marked, threshold-marked, and excess-traffic-marked.
重大度の増加の順序は次のとおりです。PCNマーク、しきい値マーク、および過剰な交通マークではありません。
An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes. The PCN-marks shouldn't be visible outside the PCN-domain, which can be achieved by the PCN-egress-node doing the PCN-colouring function (Section 4.3) after all the other (PCN and tunnelling) functions. The potential reasons for doing such tunnelling are: the PCN-egress-node then automatically knows the address of the relevant PCN-ingress-node for a flow, and, even if ECMP (Equal Cost Multi-Path) is running, all PCN-packets on a particular ingress-egress-aggregate follow the same path (for more on ECMP, see Section 6.4). But such tunnelling also has drawbacks, for example, the additional overhead in terms of bandwidth and processing as well as the cost of setting up a mesh of tunnels between PCN-boundary-nodes (there is an N^2 scaling issue).
オペレーターは、PCN-ingress-NodesからPCN-Egress-NodesへのPCNトラフィックをトンネルしたい場合があります。PCN-Marksは、PCNドメインの外側に表示されるべきではありません。PCNドメインは、他のすべての（PCNおよびトンネリング）関数の後にPCN色関数（セクション4.3）を実行するPCN-Egress-Nodeによって達成できます。このようなトンネリングを行う潜在的な理由は次のとおりです。PCN-Egress-Nodeは、フローの関連するPCN-ingress-Nodeのアドレスを自動的に知っており、ECMP（等しいコストマルチパス）が実行されていても、すべてのPCN-特定の侵入侵入 - 攻撃のパケットは、同じパスに従います（ECMPの詳細については、セクション6.4を参照）。しかし、そのようなトンネルには欠点もあります。たとえば、帯域幅と処理の観点から追加のオーバーヘッド、およびPCNバウンドリーノード間のトンネルのメッシュをセットアップするコスト（n^2スケーリングの問題があります）。
Potential issues arise for a "partially PCN-capable tunnel", ie, where only one tunnel endpoint is in the PCN-domain:
「部分的にPCN対応トンネル」、つまり、PCNドメインにあるトンネルエンドポイントが1つしかない場合、潜在的な問題が発生します。
1. The tunnel originates outside a PCN-domain and ends inside it. If the packet arrives at the tunnel ingress with the same encoding as used within the PCN-domain to indicate PCN-marking, then this could lead the PCN-egress-node to falsely measure pre-congestion.
1. トンネルはPCNドメインの外側で発生し、その中で終わります。PCNドメイン内で使用されてPCNマークを示すのと同じエンコードでパケットがトンネルイングレスに到着した場合、これによりPCN-Egress-Nodeが誤ってプレコンシュを誤って測定する可能性があります。
2. The tunnel originates inside a PCN-domain and ends outside it. If the packet arrives at the tunnel ingress already PCN-marked, then it will still have the same encoding when it's decapsulated, which could potentially confuse nodes beyond the tunnel egress.
2. トンネルはPCNドメインの内部で発生し、外で終わります。パケットがすでにPCNマークされているトンネルイングレスに到着した場合、脱カプセル化しているときに同じエンコードがあり、トンネル出口を超えてノードを混乱させる可能性があります。
In line with the solution for partially capable Diffserv tunnels in [RFC2983], the following rules are applied:
[RFC2983]の部分的に有能なDiffServトンネルのソリューションに沿って、次のルールが適用されます。
o For case (1), the tunnel egress node clears any PCN-marking on the inner header. This rule is applied before the "copy on decapsulation" rule above.
o ケース（1）の場合、トンネル出力ノードは、内側のヘッダーにPCNマークをクリアします。このルールは、上記の「脱カプセル化に関するコピー」ルールの前に適用されます。
o For case (2), the tunnel ingress node clears any PCN-marking on the inner header. This rule is applied after the "copy on encapsulation" rule above.
o ケース（2）の場合、トンネルイングレスノードは、内側のヘッダーにPCNマークをクリアします。このルールは、上記の「カプセル化のコピー」ルールの後に適用されます。
Note that the above implies that one has to know, or determine, the characteristics of the other end of the tunnel as part of establishing it.
上記は、トンネルのもう一方の端の特性を、それを確立することの一環として、知っている、または決定しなければならないことを意味することに注意してください。
Tunnelling constraints were a major factor in the choice of the baseline encoding. As explained in [Moncaster09-1], with current tunnelling endpoints, only the 11 codepoint of the ECN field survives decapsulation, and hence the baseline encoding only uses the 11 codepoint to indicate PCN-marking. Extended encoding schemes need to explain their interactions with (or assumptions about) tunnelling. A lengthy discussion of all the issues associated with layered encapsulation of congestion notification (for ECN as well as PCN) is in [Briscoe09].
トンネルの制約は、ベースラインエンコーディングの選択における主要な要因でした。[Moncaster09-1]で説明されているように、現在のトンネリングエンドポイントがあるため、ECNフィールドの11コードポイントのみが脱カプセル化を耐えるため、ベースラインエンコードは11コードポイントのみを使用してPCNマークを示します。拡張されたエンコーディングスキームでは、トンネルとの相互作用（または仮定）を説明する必要があります。混雑通知の層状カプセル化に関連するすべての問題の長い議論（ECNおよびPCNの場合）は[briscoe09]にあります。
If a PCN-interior-node (or one of its links) fails, then lower-layer protection mechanisms or the regular IP routing protocol will eventually re-route around it. If the new route can carry all the admitted traffic, flows will gracefully continue. If instead this causes early warning of pre-congestion on the new route, then admission control based on Pre-Congestion Notification will ensure that new flows will not be admitted until enough existing flows have departed. Re-routing may result in heavy (pre-)congestion, which will cause the flow termination mechanism to kick in.
PCN-Interior-Node（またはそのリンクのいずれか）が失敗した場合、低層保護メカニズムまたは通常のIPルーティングプロトコルが最終的にそれを再ルーティングします。新しいルートが認められたすべてのトラフィックを運ぶことができる場合、フローは優雅に続きます。代わりに、これが新しいルートでの事前相関の早期警告を引き起こした場合、事前の通知に基づく入場制御により、十分な既存のフローが出発するまで新しいフローが認められないようになります。再ルーティングは、重い（前）輻輳をもたらす可能性があり、流れ終端メカニズムがキックインすることになります。
If a PCN-boundary-node fails, then we would like the regular QoS signalling protocol to be responsible for taking appropriate action. As an example, [Briscoe09] considers what happens if RSVP is the QoS signalling protocol.
PCNバウンダリーノードが失敗した場合、通常のQoSシグナリングプロトコルが適切なアクションを実行する責任を負わせたいと思います。例として、[briscoe09]は、RSVPがQoSシグナル伝達プロトコルである場合に何が起こるかを考慮します。
This section considers operations and management issues, under the FCAPS headings: Faults, Configuration, Accounting, Performance, and Security. Provisioning is discussed with performance.
このセクションでは、FCAPSの見出し、障害、構成、会計、パフォーマンス、セキュリティの下で、運用と管理の問題を検討します。プロビジョニングはパフォーマンスで議論されます。
Fault Operations and Management is about preventing faults, telling the management system (or manual operator) that the system has recovered (or not) from a failure, and about maintaining information to aid fault diagnosis.
障害操作と管理とは、障害を防止し、管理システム（または手動オペレーター）に、システムが障害から回復した（または障害から）、障害診断を支援するための情報を維持することについてのことです。
Admission blocking and, particularly, flow termination mechanisms should rarely be needed in practice. It would be unfortunate if they didn't work after an option had been accidentally disabled. Therefore, it will be necessary to regularly test that the live system works as intended (devising a meaningful test is left as an exercise for the operator).
入場ブロッキング、特にフロー終了メカニズムは、実際にはめったに必要ありません。オプションが誤って無効になった後に動作しなかった場合、残念です。したがって、ライブシステムが意図したとおりに機能することを定期的にテストする必要があります（意味のあるテストを考案することは、オペレーターの演習として残されています）。
Section 4 describes how the PCN architecture has been designed to ensure admitted flows continue gracefully after recovering automatically from link or node failures. The need to record and monitor re-routing events affecting signalling is unchanged by the addition of PCN to a Diffserv domain. Similarly, re-routing events within the PCN-domain will be recorded and monitored just as they would be without PCN.
セクション4では、リンクまたはノードの障害から自動的に回復した後、入院したフローが優雅に継続するようにPCNアーキテクチャがどのように設計されているかについて説明します。シグナル伝達に影響を与える再ルーティングイベントを記録および監視する必要性は、DiffServドメインにPCNを追加することで変化しません。同様に、PCNドメイン内の再ルーティングイベントは、PCNがないように記録および監視されます。
PCN-marking does make it possible to record "near-misses". For instance, at the PCN-egress-node a "reporting threshold" could be set to monitor how often -- and for how long -- the system comes close to triggering flow blocking without actually doing so. Similarly, bursts of flow termination marking could be recorded even if they are not sufficiently sustained to trigger flow termination. Such statistics could be correlated with per-queue counts of marking volume (Section 5.2) to upgrade resources in danger of causing service degradation or to trigger manual tracing of intermittent incipient errors that would otherwise have gone unnoticed.
PCNマーキングは、「ニアミス」を記録することを可能にします。たとえば、PCN-Egress-Nodeでは、「レポートのしきい値」を設定して、実際にそうすることなく、システムがフローブロックのトリガーに近づくかを監視することができます。同様に、フロー終了マーキングのバーストは、フロー終了をトリガーするのに十分に維持されていなくても、記録できます。このような統計は、サービスの劣化を引き起こす危険のあるリソースをアップグレードしたり、そうでなければ気付かれないであろう断続的な入射エラーのマニュアルトレースを引き起こしたりするために、マークボリュームのキューごとのカウント（セクション5.2）と相関する可能性があります。
Finally, of course, many faults are caused by failings in the management process ("human error"): a wrongly configured address in a node, a wrong address given in a signalling protocol, a wrongly configured parameter in a queueing algorithm, a node set into a different mode from other nodes, and so on. Generally, a clean design with few configurable options ensures this class of faults can be traced more easily and prevented more often. Sound management practice at run-time also helps. For instance, a management system should be used that constrains configuration changes within system rules (eg, preventing an option setting inconsistent with other nodes), configuration options should be recorded in an offline database, and regular automatic consistency checks between live systems and the database should be performed. PCN adds nothing specific to this class of problems.
最後に、もちろん、多くの障害は、管理プロセスの障害（「ヒューマンエラー」）によって引き起こされます：ノード内の誤って構成されたアドレス、シグナリングプロトコルで与えられた誤ったアドレス、キューイングアルゴリズムで誤って構成されたパラメーター、ノード他のノードとは別のモードに設定されます。一般的に、構成可能なオプションがほとんどないクリーンなデザインにより、このクラスの障害をより簡単に追跡し、より頻繁に防ぐことができます。実行時のサウンド管理の練習も役立ちます。たとえば、システムルール内の構成の変更を制約する管理システムを使用する必要があります（たとえば、他のノードと矛盾するオプション設定の防止）、構成オプションはオフラインデータベースに記録する必要があります。実行する必要があります。PCNは、このクラスの問題に固有のものを追加しません。
Threshold-metering and -marking and excess-traffic-metering and -marking are standardised in [Eardley09]. However, more diversity in PCN-boundary-node behaviours is expected, in order to interface with diverse industry architectures. It may be possible to have different PCN-boundary-node behaviours for different ingress-egress-aggregates within the same PCN-domain.
しきい値計算およびマーク、および過剰なトラフィックメタリングおよびマークは、[Aerdley09]で標準化されています。ただし、多様な業界アーキテクチャとのインターフェースを得るには、PCN結合ノードの動作の多様性が予想されます。同じPCNドメイン内の異なる侵入侵入と攻撃のために、異なるPCNバウンダリーノードの動作を持つことが可能かもしれません。
PCN-metering behaviour is enabled on either the egress or the ingress interfaces of PCN-nodes. A consistent choice must be made across the PCN-domain to ensure that the PCN mechanisms protect all links.
PCNノードの出力または侵入インターフェイスのいずれかで、PCNメタリング動作が有効になります。PCNメカニズムがすべてのリンクを保護するように、PCNドメイン全体で一貫した選択を行う必要があります。
PCN configuration control variables fall into the following categories:
PCN構成制御変数は、次のカテゴリに分類されます。
o system options (enabling or disabling behaviours)
o システムオプション（動作の有効化または無効化）
o parameters (setting levels, addresses, etc.)
o パラメーター（設定レベル、アドレスなど）
One possibility is that all configurable variables sit within an SNMP (Simple Network Management Protocol) management framework [RFC3411], being structured within a defined management information base (MIB) on each node, and being remotely readable and settable via a suitably secure management protocol (such as SNMPv3).
1つの可能性は、すべての構成可能な変数がSNMP（シンプルネットワーク管理プロトコル）管理フレームワーク[RFC3411]内にあることです。各ノードの定義された管理情報ベース（MIB）内で構成され、適切に安全な管理プロトコルを介してリモートで読み取り可能で設定可能であることです。（snmpv3など）。
Some configuration options and parameters have to be set once to "globally" control the whole PCN-domain. Where possible, these are identified below. This may affect operational complexity and the chances of interoperability problems between equipment from different vendors.
一部の構成オプションとパラメーターは、PCNドメイン全体を「グローバルに」制御するために1回設定する必要があります。可能であれば、これらを以下に特定します。これは、運用上の複雑さと、さまざまなベンダーからの機器間の相互運用性の問題の可能性に影響を与える可能性があります。
It may be possible for an operator to configure some PCN-interior-nodes so that they don't run the PCN mechanisms, if it knows that these links will never become (pre-)congested.
これらのリンクが（事前）混雑することはないことがわかっている場合、オペレーターがPCNメカニズムを実行しないようにPCNインターリアノードを構成することが可能かもしれません。
On PCN-interior-nodes there will be very few system options:
PCN-Interior-Nodesには、システムオプションがほとんどありません。
o Whether two PCN-markings (threshold-marked and excess-traffic-marked) are enabled or only one. Typically, all nodes throughout a PCN-domain will be configured the same in this respect. However, exceptions could be made. For example, if most PCN-nodes used both markings but some legacy hardware was incapable of running two algorithms, an operator might be willing to configure these legacy nodes solely for excess-traffic-marking to enable flow termination as a back-stop. It would be sensible to place such nodes where they could be provisioned with a greater leeway over expected traffic levels.
o 2つのPCNマーク（しきい値マークと過剰なトラフィックマーク化）が有効であるか、1つだけが有効になっていますか。通常、PCNドメイン全体のすべてのノードは、この点で同じように構成されます。ただし、例外を作成できます。たとえば、ほとんどのPCNノードが両方のマーキングを使用しているが、いくつかのレガシーハードウェアが2つのアルゴリズムを実行できない場合、オペレーターは、フローターミネーションをバックストップとして可能にするために、トラフィックの過剰マークを使用するためだけにこれらのレガシーノードを構成することをいとわない場合があります。予想されるトラフィックレベルよりも大きな余裕があるため、そのようなノードを配置することは賢明でしょう。
o In the case where only one PCN-marking is enabled, all nodes must be configured to generate PCN-marks from the same meter (ie, either the threshold meter or the excess-traffic meter).
o 1つのPCNマークのみが有効になっている場合、すべてのノードを同じメーターからPCNマークを生成するように構成する必要があります（つまり、しきい値計または過剰な交通メーターのいずれか）。
PCN-boundary-nodes (ingress and egress) will have more system options:
PCN-Boundary-Nodes（Ingress and Eutress）には、より多くのシステムオプションがあります。
o Which of admission and flow termination are enabled. If any PCN-interior-node is configured to generate a marking, all PCN-boundary-nodes must be able to interpret that marking (which includes understanding, in a PCN-domain that uses only one type of PCN-marking, whether they are generated by PCN-interior-nodes' threshold meters or their excess-traffic meters). Therefore, all PCN-boundary-nodes must be configured the same in this respect.
o どの入場とフロー終了が有効になっているか。Markingを生成するようにPCNインタレオンノードが構成されている場合、すべてのPCNバウンドリーノードは、そのマーキング（1つのタイプのPCNマークのみを使用するPCNドメインで、そのマーキングを解釈できる必要があります。PCN-Interior-Nodesのしきい値メーターまたはそれらの過剰な交通量メートルによって生成されます）。したがって、この点ですべてのPCN結合ノードを同じように構成する必要があります。
o Where flow admission and termination decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a centralised node, see Appendix). Theoretically, this configuration choice could be negotiated for each pair of PCN-boundary-nodes, but we cannot imagine why such complexity would be required, except perhaps in future inter-domain scenarios.
o 流れの入場と終了の決定が行われる場合：PCN-ingress-NodesまたはPCN-Egress-Nodes（または集中ノードでは、付録を参照）。理論的には、この構成の選択は、PCNバウンダリーノードの各ペアについて交渉することができますが、おそらく将来のドメイン間シナリオを除いて、なぜこのような複雑さが必要なのか想像できません。
o How PCN-markings are translated into admission control and flow termination decisions (see Sections 3.1 and 3.2).
o PCNマーキングが入学制御およびフロー終了の決定にどのように変換されるか（セクション3.1および3.2を参照）。
PCN-egress-nodes will have further system options:
PCN-Egress-Nodesには、さらにシステムオプションがあります。
o How the mapping should be established between each packet and its aggregate (eg, by MPLS label and by IP packet filter spec) and how to take account of ECMP.
o 各パケットとその集約の間にマッピングをどのように確立するか（例：MPLSラベルおよびIPパケットフィルター仕様による）、およびECMPを考慮する方法。
o If an equipment vendor provides a choice, there may be options for selecting which smoothing algorithm to use for measurements.
o 機器ベンダーが選択肢を提供する場合、測定に使用するスムージングアルゴリズムを選択するオプションがある場合があります。
Like any Diffserv domain, every node within a PCN-domain will need to be configured with the DSCP(s) used to identify PCN-packets. On each interior link, the main configuration parameters are the PCN-threshold-rate and PCN-excess-rate. A larger PCN-threshold-rate enables more PCN-traffic to be admitted on a link, hence improving capacity utilisation. A PCN-excess-rate set further above the PCN-threshold-rate allows greater increases in traffic (whether due to natural fluctuations or some unexpected event) before any flows are terminated, ie, minimises the chances of unnecessarily triggering the termination mechanism. For instance, an operator may want to design their network so that it can cope with a failure of any single PCN-node without terminating any flows.
他のdiffservドメインと同様に、PCNドメイン内のすべてのノードは、PCNパケットの識別に使用されるDSCPで構成する必要があります。各インテリアリンクでは、主な構成パラメーターはPCN-Threshold-rateとPCN-Excess-rateです。より大きなPCNの授与率のレートにより、より多くのPCNトラフィックをリンクで認めることができるため、容量の使用率が向上します。PCN-Excess-rateセットは、PCNの閾値レートをさらに上回ると、フローが終了する前にトラフィックの増加（自然の変動または予期しないイベントのため）の増加を可能にします。つまり、終了メカニズムを不必要にトリガーする可能性を最小限に抑えます。たとえば、オペレーターは、フローを終了せずに単一のPCNノードの障害に対処できるように、ネットワークを設計することをお勧めします。
Setting these rates on the first deployment of PCN will be very similar to the traditional process for sizing an admission-controlled network, depending on: the operator's requirements for minimising flow blocking (grade of service), the expected PCN-traffic load on each link and its statistical characteristics (the traffic matrix), contingency for re-routing the PCN-traffic matrix in the event of single or multiple failures, and the expected load from other classes relative to link capacities [Menth09-1]. But, once a domain is in operation, a PCN design goal is to be able to determine growth in these configured rates much more simply, by monitoring PCN-marking rates from actual rather than expected traffic (see Section 5.4 on Performance and Provisioning).
PCNの最初の展開にこれらのレートを設定することは、以下に応じて、入場制御ネットワークをサイジングするための従来のプロセスと非常に似ています。その統計的特性（トラフィックマトリックス）、単一または複数の障害が発生した場合のPCNトラフィックマトリックスの再ルーティングの偶発性、およびリンク容量に対する他のクラスからの予想される負荷[MentH09-1]。しかし、ドメインが動作すると、PCN設計目標は、予想されるトラフィックではなく実際のトラフィックからPCNマークレートを監視することにより、これらの構成レートの成長をはるかに簡単に決定できるようにすることです（パフォーマンスとプロビジョニングに関するセクション5.4を参照）。
Operators may also wish to configure a rate greater than the PCN-excess-rate that is the absolute maximum rate that a link allows for PCN-traffic. This may simply be the physical link rate, but some operators may wish to configure a logical limit to prevent starvation of other traffic classes during any brief period after PCN-traffic exceeds the PCN-excess-rate but before flow termination brings it back below this rate.
また、オペレーターは、リンクがPCNトラフィックを許可する絶対最大レートであるPCNエクスケスレートよりも大きなレートを構成することもできます。これは単に物理的なリンクレートかもしれませんが、一部のオペレーターは、PCNトラフィックがPCNエクスケスレートを超えた後、フロー終了がこれを下に戻す前に、他の交通クラスの飢vを防ぐために論理的な制限を構成することを望む場合があります。レート。
Threshold-metering requires a threshold token bucket depth to be configured, excess-traffic-metering requires a value for the MTU (maximum size of a PCN-packet on the link), and both require setting a maximum size of their token buckets. It is preferable to have rules that set defaults for these parameters but to then allow operators to change them -- for instance, if average traffic characteristics change over time.
しきい値計算では、しきい値トークンバケットの深さを構成する必要があり、過剰なトラフィックメタリングにはMTU（リンク上のPCNパケットの最大サイズ）の値が必要であり、両方ともトークンバケットの最大サイズを設定する必要があります。これらのパラメーターのデフォルトを設定するルールを持つことが望ましいですが、たとえば平均トラフィック特性が時間とともに変化した場合、オペレーターがそれらを変更できるようにすることが望ましいです。
The PCN-egress-node may allow configuration of:
PCN-Egress-Nodeは、次のような構成を許可する場合があります。
o how it smooths metering of PCN-markings (eg, EWMA parameters)
o PCNマークの計量をどのように滑らかにするか（例えば、EWMAパラメーター）
Whichever node makes admission and flow termination decisions will contain algorithms for converting PCN-marking levels into admission or flow termination decisions. These will also require configurable parameters, for instance:
どちらのノードが入場とフロー終了の決定を行う場合でも、PCNマークレベルを入学またはフロー終了の決定に変換するためのアルゴリズムが含まれます。これらには、たとえば、構成可能なパラメーターも必要です。
o An admission control algorithm that is based on the fraction of marked packets will at least require a marking threshold setting above which it denies admission to new flows.
o マークされたパケットの割合に基づいた入場制御アルゴリズムには、少なくとも新しいフローへの入場を拒否するマークしきい値設定が必要です。
o Flow termination algorithms will probably require a parameter to delay termination of any flows until it is more certain that an anomalous event is not transient.
o フロー終了アルゴリズムでは、異常なイベントが一時的でないことがより確実になるまで、フローの終了を遅らせるためのパラメーターがおそらく必要です。
o A parameter to control the trade-off between how quickly excess flows are terminated and over-termination.
o 過剰なフローがどれだけ速く終了して過剰に終了するかの間のトレードオフを制御するパラメーター。
One particular approach [Charny07-2] would require a global parameter to be defined on all PCN-nodes, but would only need one PCN-marking rate to be configured on each link. The global parameter is a scaling factor between admission and termination (the rate of PCN-traffic on a link up to which flows are admitted vs. the rate above which flows are terminated). [Charny07-2] discusses in full the impact of this particular approach on the operation of PCN.
1つの特定のアプローチ[charny07-2]では、すべてのPCNノードでグローバルパラメーターを定義する必要がありますが、各リンクで構成するには1つのPCNマークレートのみが必要です。グローバルパラメーターは、入場と終了の間のスケーリング係数です（フローが認められるリンクでのPCNトラフィックのレートと、上記のレートが終了するレート）。[charny07-2]は、この特定のアプローチがPCNの操作に与える影響について完全に議論しています。
Accounting is only done at trust boundaries so it is out of scope of this document, which is confined to intra-domain issues. Use of PCN internal to a domain makes no difference to the flow signalling events crossing trust boundaries outside the PCN-domain, which are typically used for accounting.
会計は信頼の境界でのみ行われるため、この文書の範囲外であり、ドメイン内の問題に限定されます。ドメイン内に内部のPCNを使用すると、通常、会計に使用されるPCNドメインの外側の信頼境界を横断するフローシグナル伝達イベントに違いはありません。
Monitoring of performance factors measurable from *outside* the PCN-domain will be no different with PCN than with any other packet-based, flow admission control system, both at the flow level (blocking probability, etc.) and the packet level (jitter [RFC3393], [Y.1541], loss rate [RFC4656], mean opinion score [P.800], etc.). The difference is that PCN is intentionally designed to indicate *internally* which exact resource(s) are the cause of performance problems and by how much.
PCNドメインから測定可能なパフォーマンスファクターの監視は、PCNドメインの場合、フローレベル（ブロッキング確率など）とパケットレベル（ジッターの両方で、他のパケットベースのフロー入学制御システムと同じように違いはありません。[RFC3393]、[Y.1541]、損失率[RFC4656]、平均意見スコア[p.800]など）。違いは、PCNは、パフォーマンスの問題の原因であり、どれだけの正確なリソースが *内部的に *を示すように意図的に設計されていることです。
Even better, PCN indicates which resources will probably cause problems if they are not upgraded soon. This can be achieved by the management system monitoring the total amount (in bytes) of PCN-marking generated by each queue over a period. Given possible long provisioning lead times, pre-congestion volume is the best metric to reveal whether sufficient persistent demand has occurred to warrant an upgrade because, even before utilisation becomes problematic, the statistical variability of traffic will cause occasional bursts of pre-congestion. This "early warning system" decouples the process of adding customers from the provisioning process. This should cut the time to add a customer when compared against admission control that is provided over native Diffserv [RFC2998] because it saves having to verify the capacity-planning process before adding each customer.
さらに良いことに、PCNは、すぐにアップグレードされない場合、どのリソースが問題を引き起こすかを示します。これは、各キューによって生成されたPCNマークの合計量（バイト）を期間にわたって監視することで実現できます。長いプロビジョニングのリードタイムの可能性を考えると、事前の化粧量は、アップグレードを保証するのに十分な持続的な需要が発生したかどうかを明らかにするのに最適なメトリックです。この「早期警告システム」は、プロビジョニングプロセスから顧客を追加するプロセスを切り離します。これにより、各顧客を追加する前に容量計画プロセスを検証する必要があるため、ネイティブDiffserv [RFC2998]を介して提供される入場制御と比較すると、顧客を追加する時間が短縮されるはずです。
Alternatively, before triggering an upgrade, the long-term pre-congestion volume on each link can be used to balance traffic load across the PCN-domain by adjusting the link weights of the routing system. When an upgrade to a link's configured PCN-rates is required, it may also be necessary to upgrade the physical capacity available to other classes. However, there will usually be sufficient physical capacity for the upgrade to go ahead as a simple configuration change. Alternatively, [Songhurst06] describes an adaptive rather than preconfigured system, where the configured PCN-threshold-rate is replaced with a high and low water mark and the marking algorithm automatically optimises how physical capacity is shared, using the relative loads from PCN and other traffic classes.
あるいは、アップグレードをトリガーする前に、各リンクの長期的な事前合成ボリュームを使用して、ルーティングシステムのリンク重みを調整することにより、PCNドメイン全体のトラフィック負荷のバランスをとることができます。リンクの構成されたPCN料金へのアップグレードが必要な場合、他のクラスで利用可能な物理能力をアップグレードする必要もあります。ただし、通常、アップグレードが単純な構成の変更として先に進むのに十分な物理能力があります。あるいは、[songhurst06]は、構成されたPCN-resshold-rateが高水マークと低水位に置き換えられ、マーキングアルゴリズムがPCNおよびその他の相対負荷を使用して物理容量の共有方法を自動的に最適化する先入観ではなく、適応型システムを説明しています。トラフィッククラス。
All the above processes require just three extra counters associated with each PCN queue: threshold-markings, excess-traffic-markings, and drops. Every time a PCN-packet is marked or dropped, its size in bytes should be added to the appropriate counter. Then the management system can read the counters at any time and subtract a previous reading to establish the incremental volume of each type of (pre-)congestion. Readings should be taken frequently so that anomalous events (eg, re-routes) can be distinguished from regular fluctuating demand, if required.
上記のすべてのプロセスでは、各PCNキューに関連付けられた3つの追加カウンターのみが必要です：しきい値マーク、過剰なトラフィックマーク、ドロップ。PCNパケットがマークまたはドロップされるたびに、そのサイズのサイズを適切なカウンターに追加する必要があります。その後、管理システムはいつでもカウンターを読み取り、以前の読み取り値を差し引くことができ、各タイプの（事前）混雑の増分体積を確立できます。必要に応じて、異常なイベント（たとえば、再ルート）を通常の変動需要と区別できるように、頻繁に測定する必要があります。
Security Operations and Management is about using secure operational practices as well as being able to track security breaches or near-misses at run-time. PCN adds few specifics to the general good practice required in this field [RFC4778]. The correct functions of the system should be monitored (Section 5.4) in multiple independent ways and correlated to detect possible security breaches. Persistent (pre-)congestion marking should raise an alarm (both on the node doing the marking and on the PCN-egress-node metering it). Similarly, persistently poor external QoS metrics (such as jitter or mean opinion score) should raise an alarm. The following are examples of symptoms that may be the result of innocent faults, rather than attacks; however, until diagnosed, they should be logged and should trigger a security alarm:
セキュリティオペレーションと管理とは、安全な運用慣行を使用するだけでなく、実行時にセキュリティ侵害または近い騒ぎを追跡できることです。PCNは、この分野で必要な一般的なグッドプラクティスにいくつかの詳細を追加します[RFC4778]。システムの正しい機能は、複数の独立した方法で監視され（セクション5.4）、可能なセキュリティ侵害を検出するために相関する必要があります。永続的な（前）輻輳マーキングはアラームを上げる必要があります（ノード上でマーキングを行う両方と、PCN-Egressノードをメーターにします）。同様に、外部のQoSメトリックが持続的に不十分な（ジッターや意見スコアなど）はアラームを上げるはずです。以下は、攻撃ではなく、罪のない欠点の結果である可能性のある症状の例です。ただし、診断されるまで、それらを記録する必要があり、セキュリティアラームをトリガーする必要があります。
o Anomalous patterns of non-conforming incoming signals and packets rejected at the PCN-ingress-nodes (eg, packets already marked PCN-capable or traffic persistently starving token bucket policers).
o PCN-ingressノードで拒否された、不適合な着信信号とパケットの異常なパターン（たとえば、すでにPCN対応とマークされているパケットまたは飢えたトークンバケットポリサーとのトラフィックがマークされています）。
o PCN-capable packets arriving at a PCN-egress-node with no associated state for mapping them to a valid ingress-egress-aggregate.
o 有効なイングレス侵入攻撃にマッピングするための関連状態のないPCN-Egress-Nodeに到着するPCN対応パケット。
o A PCN-ingress-node receiving feedback signals that are about the pre-congestion level on a non-existent aggregate or that are inconsistent with other signals (eg, unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion level, etc.).
o 存在しない集合体上の前発電レベルについてまたは他のシグナルと矛盾するPCN-ingressノード受信フィードバックシグナル（例えば、予期しないシーケンス番号、一貫性のないアドレス指定、プレコンション前レベルの矛盾する報告など。）。
o Pre-congestion marking arriving at a PCN-egress-node with (pre-)congestion markings focused on particular flows, rather than randomly distributed throughout the aggregate.
o PCN-Egress-Nodeに到着する前のマーキングは、（前）の混雑マーキングが、総計全体にランダムに分布するのではなく、特定のフローに焦点を合わせたものでした。
The key benefits of the PCN mechanisms are that they are simple, scalable, and robust, because:
PCNメカニズムの主な利点は、それらが単純で、スケーラブルで、堅牢であることです。
o Per-flow state is only required at the PCN-ingress-nodes ("stateless core"). This is required for policing purposes (to prevent non-admitted PCN-traffic from entering the PCN-domain) and so on. It is not generally required that other network entities are aware of individual flows (although they may be in particular deployment scenarios).
o 流量ごとの状態は、PCN-Ingress-Nodes（ "Stateless Core"）でのみ必要です。これは、ポリシングの目的で必要です（非付与されたPCNトラフィックがPCNドメインに入るのを防ぐため）などです。一般に、他のネットワークエンティティが個々のフローを認識していることは必須ではありません（特に展開シナリオである可能性があります）。
o Admission control is resilient: with PCN, QoS is decoupled from the routing system. Hence, in general, admitted flows can survive capacity, routing, or topology changes without additional signalling. The PCN-admissible-rate on each link can be chosen to be small enough that admitted traffic can still be carried after a re-routing in most failure cases [Menth09-1]. This is an important feature, as QoS violations in core networks due to link failures are more likely than QoS violations due to increased traffic volume [Iyer03].
o 入場制御は回復力があります。PCNを使用すると、QoSがルーティングシステムから切り離されています。したがって、一般的に、認められたフローは、追加のシグナルを追加せずに容量、ルーティング、またはトポロジの変化に耐えることができます。各リンクのPCN補給率は、ほとんどの障害の場合に再ルーティング後も受け入れられるトラフィックを運ぶことができるほど小さくなるように選択できます[MentH09-1]。これは重要な機能です。リンク障害によるコアネットワークのQoS違反は、トラフィック量の増加によりQoS違反よりも可能性が高いためです[IYER03]。
o The PCN-metering behaviours only operate on the overall PCN-traffic on the link, not per flow.
o PCNメーターの動作は、フローごとではなく、リンク上のPCNトラフィック全体でのみ動作します。
o The information of these measurements is signalled to the PCN-egress-nodes by the PCN-marks in the packet headers, ie, "in-band". No additional signalling protocol is required for transporting the PCN-marks. Therefore, no secure binding is required between data packets and separate congestion messages.
o これらの測定の情報は、パケットヘッダーのPCNマーク、すなわち「インバンド」によってPCN-Egressノードに合図されます。PCNマークの輸送には追加のシグナル伝達プロトコルは必要ありません。したがって、データパケットと個別の混雑メッセージの間には安全なバインディングは必要ありません。
o The PCN-egress-nodes make separate measurements, operating on the aggregate PCN-traffic from each PCN-ingress-node, ie, not per flow. Similarly, signalling by the PCN-egress-node of PCN-feedback-information (which is used for flow admission and termination decisions) is at the granularity of the ingress-egress-aggregate. An alternative approach is that the PCN-egress-nodes monitor the PCN-traffic and signal PCN-feedback-information (which is used for flow admission and termination decisions) at the granularity of one (or a few) PCN-marks.
o PCN-Egress-Nodesは、各PCN-Ingress-Node、つまりフローあたりではなく、各PCN-Trafficで動作する個別の測定を行います。同様に、PCNフィードバックインフォメーションのPCN-Egressノードによるシグナル（流れの入場および終了の決定に使用される）のシグナルは、侵入侵入攻撃の粒度にあります。別のアプローチは、PCN-Egress-Nodesが、PCNトラフィックおよびシグナルPCNフィードバックインフォメーション（フロー入場および終了の決定に使用される）を、1つ（または少数の）PCNマークの粒度で監視することです。
o The admitted PCN-load is controlled dynamically. Therefore, it adapts as the traffic matrix changes. It also adapts if the network topology changes (eg, after a link failure). Hence, an operator can be less conservative when deploying network capacity and less accurate in their prediction of the PCN-traffic matrix.
o 認められたPCNロードは動的に制御されます。したがって、トラフィックマトリックスが変化するにつれて適応します。また、ネットワークトポロジが変更された場合にも適応します（例：リンクの障害後）。したがって、ネットワーク容量を展開する際のオペレーターは、PCNトラフィックマトリックスの予測においてより正確ではない保守的ではありません。
o The termination mechanism complements admission control. It allows the network to recover from sudden unexpected surges of PCN-traffic on some links, thus restoring QoS to the remaining flows. Such scenarios are expected to be rare but not impossible. They can be caused by large network failures that redirect lots of admitted PCN-traffic to other links or by the malfunction of measurement-based admission control in the presence of admitted flows that send for a while with an atypically low rate and then increase their rates in a correlated way.
o 終了メカニズムは、入場制御を補完します。これにより、ネットワークはいくつかのリンクでPCNトラフィックの突然の予期しない急増から回復し、QoSが残りのフローに回復します。このようなシナリオはまれであると予想されますが、不可能ではありません。それらは、多くの入院したPCNトラフィックを他のリンクにリダイレクトする大きなネットワーク障害、または非定型的に低いレートでしばらく送信してレートを上げる入院フローの存在下での測定ベースの入場制御の誤動作によって引き起こされる可能性があります。相関する方法で。
o Flow termination can also enable an operator to be less conservative when deploying network capacity. It is an alternative to running links at low utilisation in order to protect against link or node failures. This is especially the case with SRLGs (shared risk link groups), which are links that share a resource, such as a fibre, whose failure affects all links in that group [RFC4216]). Fully protecting traffic against a single SRLG failure requires low utilisation (~10%) of the link bandwidth on some links before failure [Charny08].
o フロー終了により、ネットワーク容量を展開する際にオペレーターが保守的ではなくなる可能性があります。これは、リンクまたはノードの障害から保護するために、低使用率でリンクを実行することに代わるものです。これは特に、SRLGS（共有リスクリンクグループ）の場合に当てはまります。これは、そのグループのすべてのリンクに障害が影響する繊維などのリソースを共有するリンクです[RFC4216]）。単一のSRLG障害からトラフィックを完全に保護するには、障害前にいくつかのリンクのリンク帯域幅の使用率（〜10％）が必要です[charny08]。
o The PCN-supportable-rate may be set below the maximum rate that PCN-traffic can be transmitted on a link in order to trigger the termination of some PCN-flows before loss (or excessive delay) of PCN-packets occurs, or to keep the maximum PCN-load on a link below a level configured by the operator.
o PCN-サポート可能レートは、PCNパケットの損失（または過度の遅延）が発生する前に、PCNフローの終了をトリガーするために、PCNトラフィックをリンクに送信できる最大レートよりも下回る場合があります。演算子によって構成されたレベルの下のリンク上の最大PCNロード。
o Provisioning of the network is decoupled from the process of adding new customers. By contrast, with the Diffserv architecture [RFC2475], operators rely on subscription-time Service Level Agreements, which statically define the parameters of the traffic that will be accepted from a customer. This way, the operator has to verify that provision is sufficient each time a new customer is added to check that the Service Level Agreement can be fulfilled. A PCN-domain doesn't need such traffic conditioning.
o ネットワークのプロビジョニングは、新しい顧客を追加するプロセスから切り離されています。対照的に、DiffServアーキテクチャ[RFC2475]とは、オペレーターはサブスクリプション時間サービスレベル契約に依存しており、顧客から受け入れられるトラフィックのパラメーターを静的に定義しています。これにより、オペレーターは、新しい顧客が追加されるたびに、サービスレベルの契約が履行できることを確認するたびに、規定が十分であることを確認する必要があります。PCNドメインでは、このようなトラフィックコンディショニングは必要ありません。
Operators of networks will want to use the PCN mechanisms in various arrangements depending, for instance, on how they are performing admission control outside the PCN-domain (users after all are concerned about QoS end-to-end), what their particular goals and assumptions are, how many PCN encoding states are available, and so on.
ネットワークのオペレーターは、たとえば、PCNドメインの外でのアミズミコントロールの実行方法（結局ユーザーがQoSエンドツーエンドについて心配している）、特定の目標、およびどのように特定の目標を実行しているかに応じて、さまざまな配置でPCNメカニズムを使用したいと考えています。仮定は、利用可能なPCNエンコード状態の数などです。
A PCN-domain may have three encoding states (or pedantically, an operator may choose to use up three encoding states for PCN): not PCN-marked, threshold-marked, and excess-traffic-marked. This way, both PCN admission control and flow termination can be supported. As illustrated in Figure 1, admission control accepts new flows until the PCN-traffic rate on the bottleneck link rises above the PCN-threshold-rate, whilst, if necessary, the flow termination mechanism terminates flows down to the PCN-excess-rate on the bottleneck link.
PCNドメインには、3つのエンコード状態（またはペダントでは、オペレーターがPCNに3つのエンコード状態を使用することを選択できます）があります。このようにして、PCN入容策とフロー終了の両方をサポートできます。図1に示すように、入場制御は、ボトルネックリンクのPCNトラフィックレートがPCN授業料を上回るまで、新しいフローを受け入れますが、必要に応じてフロー終了メカニズムが終了します。ボトルネックリンク。
On the other hand, a PCN-domain may have two encoding states (as in [Moncaster09-1]) (or pedantically, an operator may choose to use up two encoding states for PCN): not PCN-marked and PCN-marked. This way, there are three possibilities, as discussed in the following paragraphs (see also Section 3.3).
一方、PCNドメインには2つのエンコード状態（[moncaster09-1]のように）（または、PEDANTICATINALでは、PCNマークなしおよびPCNマークなしではなく、オペレーターがPCNに2つのエンコード状態を使用することを選択できます）。これにより、次の段落で説明したように、3つの可能性があります（セクション3.3も参照）。
First, an operator could just use PCN's admission control, solving heavy congestion (caused by re-routing) by "just waiting" -- as sessions end, PCN-traffic naturally reduces; meanwhile, the admission control mechanism will prevent admission of new flows that use the affected links. So, the PCN-domain will naturally return to normal operation, but with reduced capacity. The drawback of this approach would be that, until sufficient sessions have ended to relieve the congestion, all PCN-flows as well as lower-priority services will be adversely affected.
第一に、オペレーターはPCNの入場制御を使用して、「Just Waiting」によって重い輻輳（再ルーティングによって引き起こされる）を解決することができます。一方、入場制御メカニズムは、影響を受けるリンクを使用する新しいフローの入院を防ぎます。したがって、PCNドメインは自然に通常の動作に戻りますが、容量は低下します。このアプローチの欠点は、輻輳を緩和するのに十分なセッションが終了するまで、すべてのPCNフローと低優先度サービスが悪影響を受けることです。
Second, an operator could just rely on statically provisioned capacity per PCN-ingress-node (regardless of the PCN-egress-node of a flow) for admission control, as is typical in the hose model of the Diffserv architecture [Kumar01]. Such traffic-conditioning agreements can lead to focused overload: many flows happen to focus on a particular link and then all flows through the congested link fail catastrophically. PCN's flow termination mechanism could then be used to counteract such a problem.
第二に、オペレーターは、Diffservアーキテクチャのホースモデル[kumar01]で典型的なように、入場制御のために、PCN-ingress-node（フローのPCN-egress-nodeに関係なく）ごとに静的にプロビジョニングされた容量に依存することができます。このような交通条件の契約は、集中的な過負荷につながる可能性があります。多くのフローは、特定のリンクに焦点を当て、混雑したリンクを介したすべてのフローが壊滅的に失敗します。その後、PCNのフロー終了メカニズムを使用して、そのような問題に対抗できます。
Third, both admission control and flow termination can be triggered from the single type of PCN-marking; the main downside here is that admission control is less accurate [Charny07-2]. This possibility is illustrated in Figure 3.
第三に、入場制御とフロー終了の両方を、単一のタイプのPCNマークからトリガーできます。ここでの主な欠点は、入場制御がより正確ではないことです[charny07-2]。この可能性を図3に示します。
Within the PCN-domain, there is some flexibility about how the decision-making functionality is distributed. These possibilities are outlined in Section 4.4 and are also discussed elsewhere, such as in [Menth09-2].
PCNドメイン内では、意思決定機能がどのように分散されるかについて、ある程度の柔軟性があります。これらの可能性はセクション4.4で概説されており、[Menth09-2]などの他の場所でも説明されています。
The flow admission and termination decisions need to be enforced through per-flow policing by the PCN-ingress-nodes. If there are several PCN-domains on the end-to-end path, then each needs to police at its PCN-ingress-nodes. One exception is if the operator runs both the access network (not a PCN-domain) and the core network (a PCN-domain); per-flow policing could be devolved to the access network and not be done at the PCN-ingress-node. Note that, to aid readability, the rest of this document assumes that policing is done by the PCN-ingress-nodes.
フロー入場および終了の決定は、PCN-insressノードによる流量あたりのポリシングを通じて実施する必要があります。エンドツーエンドのパスにいくつかのPCNドメインがある場合、それぞれがPCN-ingressノードで警察する必要があります。1つの例外は、オペレーターがアクセスネットワーク（PCNドメインではなく）とコアネットワーク（PCNドメイン）の両方を実行する場合です。流量あたりのポリシングは、アクセスネットワークに移すことができ、PCN-ingressノードでは行われません。読みやすさを支援するために、このドキュメントの残りの部分は、ポリシングがPCN-ingressノードによって行われることを前提としていることに注意してください。
PCN admission control has to fit with the overall approach to admission control. For instance, [Briscoe06] describes the case where RSVP signalling runs end-to-end. The PCN-domain is a single RSVP hop, ie, only the PCN-boundary-nodes process RSVP messages, with RSVP messages processed on each hop outside the PCN-domain, as in IntServ over Diffserv [RFC2998]. It would also be possible for the RSVP signalling to be originated and/or terminated by proxies, with application-layer signalling between the end user and the proxy (eg, SIP signalling with a home hub). A similar example would use NSIS (Next Steps in Signalling) [RFC3726] instead of RSVP.
PCN入場制御は、入学制御への全体的なアプローチに適合する必要があります。たとえば、[briscoe06]は、RSVPシグナル伝達がエンドツーエンドで実行される場合を説明しています。PCNドメインは、単一のRSVPホップ、つまりPCNバウンドリーノードのみがRSVPメッセージを処理し、RSVPメッセージはPCNドメインの外側の各ホップで処理されます。また、RSVPシグナル伝達をプロキシによって発信および/または終了する可能性があり、エンドユーザーとプロキシ（ホームハブを使用したSIPシグナル伝達）の間のアプリケーション層シグナルは可能です。同様の例では、RSVPの代わりにNSIS（シグナリングの次のステップ）[RFC3726]を使用します。
It is possible that a user wants its inelastic traffic to use the PCN mechanisms but also react to ECN markings outside the PCN-domain [Sarker08]. Two possible ways to do this are to tunnel all PCN-packets across the PCN-domain, so that the ECN marks are carried transparently across the PCN-domain, or to use an encoding like [Moncaster09-2]. Tunnelling is discussed further in Section 4.7.
ユーザーは、非弾性トラフィックにPCNメカニズムの使用を望んでいる可能性がありますが、PCNドメインの外側のECNマークにも反応します[Sarker08]。これを行う2つの考えられる方法は、PCNドメイン全体のすべてのPCNパケットをトンネルし、ECNマークがPCNドメイン全体に透過的に運ばれるか、[Moncaster09-2]のようなエンコードを使用することです。トンネリングについては、セクション4.7でさらに説明します。
Some further possible deployment models are outlined in the Appendix.
さらにいくつかの可能性のある展開モデルは、付録に概説されています。
The scope of this document is restricted by the following assumptions:
このドキュメントの範囲は、次の仮定によって制限されています。
1. These components are deployed in a single Diffserv domain, within which all PCN-nodes are PCN-enabled and are trusted for truthful PCN-marking and transport.
1. これらのコンポーネントは、すべてのPCNノードがPCN対応であり、真実のPCNマークとトランスポートに対して信頼されている単一のDiffservドメインに展開されます。
2. All flows handled by these mechanisms are inelastic and constrained to a known peak rate through policing or shaping.
2. これらのメカニズムによって処理されるすべてのフローは弾力的であり、ポリシングまたはシェーピングを通じて既知のピーク速度に制約されます。
3. The number of PCN-flows across any potential bottleneck link is sufficiently large that stateless, statistical mechanisms can be effective. To put it another way, the aggregate bit rate of PCN-traffic across any potential bottleneck link needs to be sufficiently large, relative to the maximum additional bit rate added by one flow. This is the basic assumption of measurement-based admission control.
3. 潜在的なボトルネックリンクにわたるPCN-Flowの数は十分に大きいため、ステートレスの統計メカニズムが効果的です。別の言い方をすれば、潜在的なボトルネックリンク全体にわたるPCNトラフィックの集合ビットレートは、1つのフローによって追加される最大追加ビットレートと比較して、十分に大きくする必要があります。これは、測定ベースの入場制御の基本的な仮定です。
4. PCN-flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS (Government Telecommunications Service), WPS (Wireless Priority Service), MLPP (Multilevel Precedence and Premption), etc.) is out of scope.
4. PCN-Flowsの優先順位は異なる場合がありますが、緊急使用のためのPCNメカニズムの適用可能性（911、GetS（政府の電気通信サービス）、WPS（ワイヤレス優先サービス）、MLPP（マルチレベルの優先順位とpremption）などはスコープ外です。。
It is assumed that the PCN-domain is a controlled environment, ie, all the nodes in a PCN-domain run PCN and are trusted. There are several reasons for this assumption:
PCNドメインは制御された環境、つまりPCNドメインの実行PCNのすべてのノードであり、信頼されていると想定されています。この仮定にはいくつかの理由があります：
o The PCN-domain has to be encircled by a ring of PCN-boundary-nodes; otherwise, traffic could enter a PCN-BA without being subject to admission control, which would potentially degrade the QoS of existing PCN-flows.
o PCNドメインは、PCN結合ノードのリングで囲まれている必要があります。それ以外の場合、トラフィックは入場制御の対象とせずにPCN-BAに入る可能性があり、既存のPCNフローのQOを潜在的に分解する可能性があります。
o Similarly, a PCN-boundary-node has to trust that all the PCN-nodes mark PCN-traffic consistently. A node not performing PCN-marking wouldn't be able to send an alert when it suffered pre-congestion, which potentially would lead to too many PCN-flows being admitted (or too few being terminated). Worse, a rogue node could perform various attacks, as discussed in Section 7.
o 同様に、PCNバウンダリーノードは、すべてのPCNノードがPCNトラフィックを一貫してマークすることを信頼する必要があります。PCNマーキングを実行しないノードは、事前発生に苦しんだときにアラートを送信することができません。さらに悪いことに、セクション7で説明したように、ローグノードはさまざまな攻撃を実行できます。
One way of assuring the above two points are in effect is to have the entire PCN-domain run by a single operator. Another way is to have several operators that trust each other in their handling of PCN-traffic.
上記の2つのポイントを保証する1つの方法は、有効なことです。PCNドメイン全体を単一のオペレーターによって実行することです。別の方法は、PCNトラフィックの取り扱いでお互いを信頼するいくつかのオペレーターを持つことです。
Note: All PCN-nodes need to be trustworthy. However, if it is known that an interface cannot become pre-congested, then it is not strictly necessary for it to be capable of PCN-marking, but this must be known even in unusual circumstances, eg, after the failure of some links.
注：すべてのPCNノードは信頼できる必要があります。ただし、インターフェイスが事前に組み合わされることができないことがわかっている場合、PCNマークが可能になることは厳密に必要ではありませんが、これは、例えば、いくつかのリンクの障害後でも異常な状況でも知られている必要があります。
It is assumed that any variation of source bit rate is independent of the level of pre-congestion. We assume that PCN-packets come from real-time applications generating inelastic traffic, ie, sending packets at the rate the codec produces them, regardless of the availability of capacity [RFC4594]. Examples of such real-time applications include voice and video requiring low delay, jitter, and packet loss, the Controlled Load Service [RFC2211], and the Telephony service class [RFC4594]. This assumption is to help focus the effort where it looks like PCN would be most useful, ie, the sorts of applications where per-flow QoS is a known requirement. In other words, we focus on PCN providing a benefit to inelastic traffic (PCN may or may not provide a benefit to other types of traffic).
ソースビットレートのバリエーションは、事前のレベルとは無関係であると想定されています。PCNパケットは、非弾性トラフィックを生成するリアルタイムアプリケーション、つまり、容量の可用性に関係なく、コーデックが生成する速度でパケットを送信することから得られると想定しています[RFC4594]。このようなリアルタイムアプリケーションの例には、低遅延、ジッター、パケット損失、制御された負荷サービス[RFC2211]、およびテレフォニーサービスクラス[RFC4594]を必要とする音声とビデオが含まれます。この仮定は、PCNが最も有用であるように見える努力、すなわち、流量あたりのQOSが既知の要件であるアプリケーションの種類に焦点を合わせることです。言い換えれば、私たちはPCNに焦点を当て、非弾性トラフィックに利益をもたらします（PCNは他のタイプのトラフィックに利益をもたらす場合とそうでない場合があります）。
As a consequence, it is assumed that PCN-metering and PCN-marking is being applied to traffic scheduled with an expedited forwarding per-hop behaviour [RFC3246] or with a per-hop behaviour with similar characteristics.
結果として、PCNメータリングとPCNマークは、迅速な転送ごとの動作[RFC3246]または同様の特性を持つホップごとの動作でスケジュールされたトラフィックに適用されていると想定されています。
It is assumed that there are many PCN-flows on any bottleneck link in the PCN-domain (or, to put it another way, the aggregate bit rate of PCN-traffic across any potential bottleneck link is sufficiently large, relative to the maximum additional bit rate added by one PCN-flow). Measurement-based admission control assumes that the present is a reasonable prediction of the future: the network conditions are measured at the time of a new flow request, but the actual network performance must be acceptable during the call some time later. One issue is that if there are only a few variable rate flows, then the aggregate traffic level may vary a lot, perhaps enough to cause some packets to get dropped. If there are many flows, then the aggregate traffic level should be statistically smoothed. How many flows is enough depends on a number of factors, such as the variation in each flow's rate, the total rate of PCN-traffic, and the size of the "safety margin" between the traffic level at which we start admission-marking and at which packets are dropped or significantly delayed.
PCNドメインのボトルネックリンクには多くのPCN-Flowsがあると想定されています（または、別の言い方をすれば、潜在的なボトルネックリンク全体のPCNトラフィックの集合ビットレートは、最大追加と比較して十分に大きいと想定されています。1つのPCN-Flowによって追加されたビットレート）。測定ベースの入場制御は、現在が将来の合理的な予測であると想定しています。ネットワーク条件は新しいフロー要求の時点で測定されますが、実際のネットワークパフォーマンスは、しばらくしてからコール中に受け入れられる必要があります。1つの問題は、いくつかの変動レートフローしかない場合、総トラフィックレベルが大きく異なる可能性があり、おそらく一部のパケットがドロップされるのに十分である可能性があることです。多くのフローがある場合、総トラフィックレベルは統計的に滑らかにする必要があります。フローの数は、各フローのレートの変動、PCNトラフィックの合計レート、および入学マーキングを開始するトラフィックレベルと「安全マージン」のサイズなど、多くの要因に依存します。パケットがドロップされるか、大幅に遅延します。
No explicit assumptions are made about how many PCN-flows are in each ingress-egress-aggregate. Performance-evaluation work may clarify whether it is necessary to make any additional assumptions on aggregation at the ingress-egress-aggregate level.
各侵入侵入攻撃と攻撃性のPCNフローの数について明示的な仮定は行われません。パフォーマンス評価作業は、イングレスエグレス - アグレジェートレベルでの集約に関する追加の仮定を行う必要があるかどうかを明確にする場合があります。
PCN-flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope for this document.
PCN-Flowsの優先順位は異なる場合がありますが、緊急使用のためのPCNメカニズムの適用可能性（911、GET、WPS、MLPPなど）は、このドキュメントの範囲外です。
Prior work on PCN and similar mechanisms has led to a number of considerations about PCN's design goals (things PCN should be good at) and some issues that have been hard to solve in a fully satisfactory manner. Taken as a whole, PCN represents a list of trade-offs (it is unlikely that they can all be 100% achieved) and perhaps a list of evaluation criteria to help an operator (or the IETF) decide between options.
PCNおよび同様のメカニズムに関する以前の作業により、PCNの設計目標（PCNは良いはずです）と、完全に満足のいく方法で解決するのが難しいいくつかの問題に関する多くの考慮事項が生じています。全体として、PCNはトレードオフのリスト（すべてが100％達成できる可能性は低い）と、おそらくオペレーター（またはIETF）がオプションを決定するのを支援する評価基準のリストを表します。
The following are open issues. They are mainly taken from [Briscoe06], which also describes some possible solutions. Note that some may be considered unimportant in general or in specific deployment scenarios, or by some operators.
以下は未解決の問題です。それらは主に[briscoe06]から取られており、これもいくつかの可能な解決策を説明しています。一部の人は、一般的に、または特定の展開シナリオで、または一部のオペレーターによって重要ではないと見なされる場合があることに注意してください。
Note: Potential solutions are out of scope for this document.
注：このドキュメントの潜在的なソリューションは範囲外です。
o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion is measured on a specific ingress-egress-aggregate. However, if the PCN-domain runs ECMP, then traffic on this ingress-egress-aggregate may follow several different paths -- some of the paths could be pre-congested whilst others are not. There are three potential problems:
o ECMP（等しいコストマルチパス）ルーティング：前もって特定の侵入侵入攻撃で測定されます。ただし、PCNドメインがECMPを実行している場合、この侵入侵入攻撃のトラフィックはいくつかの異なるパスをたどることができます - 一部のパスは事前に組み立てられる可能性がありますが、他のパスはそうではありません。潜在的な問題は3つあります。
1. over-admission: a new flow is admitted (because the pre-congestion level measured by the PCN-egress-node is sufficiently diluted by unmarked packets from non-congested paths that a new flow is admitted), but its packets travel through a pre-congested PCN-node.
1. 過剰承認：新しいフローが認められます（PCN-Egress-Nodeで測定された前発電レベルは、新しいフローが認められる非合成パスからのマークのないパケットによって十分に希釈されるため）が、そのパケットはPreを通過するためです）-Congested PCN-Node。
2. under-admission: a new flow is blocked (because the pre-congestion level measured by the PCN-egress-node is sufficiently increased by PCN-marked packets from pre-congested paths that a new flow is blocked), but its packets travel along an uncongested path.
2. 入場不足：新しいフローがブロックされます（PCN-Egress-Nodeで測定されたプレコンション前のレベルは、新しいフローがブロックされる事前に組み込まれたパスからPCNマークされたパケットによって十分に増加しているためです）が、そのパケットは沿って移動します）充実したパス。
3. ineffective termination: a flow is terminated but its path doesn't travel through the (pre-)congested router(s). Since flow termination is a "last resort", which protects the network should over-admission occur, this problem is probably more important to solve than the other two.
3. 効果のない終了：フローは終了しますが、その経路は（前）混雑したルーターを通過しません。フロー終了は「最後の手段」であり、過度に許可が発生した場合にネットワークを保護するため、この問題は他の2つよりも解決するためにおそらく重要です。
o ECMP and Signalling: It is possible that, in a PCN-domain running ECMP, the signalling packets (eg, RSVP, NSIS) follow a different path than the data packets, which could matter if the signalling packets are used as probes. Whether this is an issue depends on which fields the ECMP algorithm uses; if the ECMP algorithm is restricted to the source and destination IP addresses, then it will not be an issue. ECMP and signalling interactions are a specific instance of a general issue for non-traditional routing combined with resource management along a path [Hancock02].
o ECMPとシグナル伝達：ECMPを実行しているPCNドメインでは、シグナリングパケット（RSVP、NSISなど）がデータパケットとは異なるパスに従う可能性があります。これが問題であるかどうかは、ECMPアルゴリズムが使用するフィールドによって異なります。ECMPアルゴリズムがソースおよび宛先IPアドレスに制限されている場合、それは問題になりません。ECMPとシグナル伝達の相互作用は、パスに沿ったリソース管理と組み合わされた非伝統的なルーティングの一般的な問題の特定のインスタンスです[hancock02]。
o Tunnelling: There are scenarios where tunnelling makes it difficult to determine the path in the PCN-domain. The problem, its impact, and the potential solutions are similar to those for ECMP.
o トンネリング：トンネリングによりPCNドメインのパスを決定することが難しくなるシナリオがあります。問題、その影響、および潜在的なソリューションは、ECMPの問題と類似しています。
o Scenarios with only one tunnel endpoint in the PCN-domain: Such scenarios may make it harder for the PCN-egress-node to gather from the signalling messages (eg, RSVP, NSIS) the identity of the PCN-ingress-node.
o PCNドメインにトンネルエンドポイントが1つしかないシナリオ：そのようなシナリオは、PCN-Egress-Nodeがシグナリングメッセージ（RSVP、NSISなど）から収集することをより難しくする可能性があります。
o Bi-Directional Sessions: Many applications have bi-directional sessions -- hence, there are two microflows that should be admitted (or terminated) as a pair -- for instance, a bi-directional voice call only makes sense if microflows in both directions are admitted. However, the PCN mechanisms concern admission and termination of a single flow, and coordination of the decision for both flows is a matter for the signalling protocol and out of scope for PCN. One possible example would use SIP pre-conditions. However, there are others.
o 双方向セッション：多くのアプリケーションには双方向セッションがあります。したがって、2つのマイクロフローがペアとして認められる（または終了）する必要があります。認められています。ただし、PCNメカニズムは、単一のフローの入院と終了に関係し、両方のフローの決定の調整は、シグナル伝達プロトコルの問題であり、PCNの範囲外です。考えられる例の1つは、SIPの事前条件を使用します。しかし、他にもあります。
o Global Coordination: PCN makes its admission decision based on PCN-markings on a particular ingress-egress-aggregate. Decisions about flows through a different ingress-egress-aggregate are made independently. However, one can imagine network topologies and traffic matrices where, from a global perspective, it would be better to make a coordinated decision across all the ingress-egress-aggregates for the whole PCN-domain. For example, to block (or even terminate) flows on one ingress-egress-aggregate so that more important flows through a different ingress-egress-aggregate could be admitted. The problem may well be relatively insignificant.
o グローバルな調整：PCNは、特定の侵入侵入攻撃のPCNマークに基づいて入学決定を下します。異なる侵入侵入と攻撃の流れに関する決定は、独立して行われます。ただし、グローバルな観点から、PCNドメイン全体のすべての入り口と侵入攻撃にわたって調整された決定を下す方が良いと想像できます。たとえば、1つの入り口と込み録にフローをブロック（または終了する）して、異なる侵入侵入と攻撃を介してより重要な流れを認めることができます。問題は比較的重要ではないかもしれません。
o Aggregate Traffic Characteristics: Even when the number of flows is stable, the traffic level through the PCN-domain will vary because the sources vary their traffic rates. PCN works best when there is not too much variability in the total traffic level at a PCN-node's interface (ie, in the aggregate traffic from all sources). Too much variation means that a node may (at one moment) not be doing any PCN-marking and then (at another moment) drop packets because it is overloaded. This makes it hard to tune the admission control scheme to stop admitting new flows at the right time. Therefore, the problem is more likely with fewer, burstier flows.
o 集約交通特性：フローの数が安定している場合でも、ソースがトラフィックレートが異なるため、PCNドメインを通るトラフィックレベルは変化します。PCNは、PCNノードのインターフェイス（つまり、すべてのソースからの集計トラフィック）で、トラフィックレベルの合計にあまり変動性がない場合に最適に機能します。バリエーションが多すぎると、ノードが（ある時点で）PCNマークを実行していないことを意味し、それが過負荷になっているため（別の時点で）パケットをドロップすることができます。これにより、適切なタイミングで新しいフローを認めるのを止めるために、入場制御スキームを調整することが難しくなります。したがって、問題は、より少ない、バーティアな流れでより可能性が高くなります。
o Flash crowds and Speed of Reaction: PCN is a measurement-based mechanism and so there is an inherent delay between packet marking by PCN-interior-nodes and any admission control reaction at PCN-boundary-nodes. For example, if a big burst of admission requests potentially occurs in a very short space of time (eg, prompted by a televote), they could all get admitted before enough PCN-marks are seen to block new flows. In other words, any additional load offered within the reaction time of the mechanism must not move the PCN-domain directly from a no congestion state to overload. This "vulnerability period" may have an impact at the signalling level, for instance, QoS requests should be rate-limited to bound the number of requests able to arrive within the vulnerability period.
o フラッシュクラウドと反応の速度：PCNは測定ベースのメカニズムであるため、PCNインタートンノードによるパケットマーキングとPCN結合ノードでの入場制御反応の間には固有の遅延があります。たとえば、入場要求の大きなバーストが非常に短い時間で潜在的に発生する可能性がある場合（たとえば、テレビ声によって促されます）、十分なPCNマークが新しいフローをブロックするのが見られる前に、それらはすべて認められる可能性があります。言い換えれば、メカニズムの反応時間内に提供される追加の負荷は、PCNドメインを渋滞状態のない状態から過負荷に直接移動してはなりません。この「脆弱性期間」は、シグナリングレベルで影響を与える可能性があります。たとえば、QoSリクエストは、脆弱性期間内に到着できるリクエストの数をバインドするために料金制限する必要があります。
o Silent at Start: After a successful admission request, the source may wait some time before sending data (eg, waiting for the called party to answer). Then the risk is that, in some circumstances, PCN's measurements underestimate what the pre-congestion level will be when the source does start sending data.
o 開始時のサイレント：入場リクエストが成功した後、情報源はデータを送信する前にしばらく待つことがあります（例えば、呼び出されたパーティーが答えるのを待っています）。次に、状況によっては、PCNの測定値が、ソースがデータの送信を開始したときに事前のレベルが何であるかを過小評価しているというリスクがあります。
Security considerations essentially come from the Trust Assumption Section 6.3.1, ie, that all PCN-nodes are PCN-enabled and are trusted for truthful PCN-metering and PCN-marking. PCN splits functionality between PCN-interior-nodes and PCN-boundary-nodes, and the security considerations are somewhat different for each, mainly because PCN-boundary-nodes are flow-aware and PCN-interior-nodes are not.
セキュリティ上の考慮事項は、本質的に、すべてのPCNノードがPCN対応であり、真実のPCNメタリングとPCNマークに対して信頼されているというTrust Assuttionセクション6.3.1、つまり、つまり、本質的には発生しています。PCNは、PCNインターリオンノードとPCNバウンドリーノードの間で機能を分割します。これは、それぞれのセキュリティ上の考慮事項が多少異なります。これは、主にPCNバウンダリーノードがフローアウェアであり、PCNインタールノードはそうではないためです。
o Because PCN-boundary-nodes are flow-aware, they are trusted to use that awareness correctly. The degree of trust required depends on the kinds of decisions they have to make and the kinds of information they need to make them. There is nothing specific to PCN.
o PCNバウンダリーノードはフロー認識であるため、その認識を正しく使用すると信頼されています。必要な信頼の程度は、行わなければならない決定の種類と、それらを作成するために必要な情報の種類に依存します。PCNに固有のものはありません。
o The PCN-ingress-nodes police packets to ensure a PCN-flow sticks within its agreed limit, and to ensure that only PCN-flows that have been admitted contribute PCN-traffic into the PCN-domain. The policer must drop (or perhaps downgrade to a different DSCP) any PCN-packets received that are outside this remit. This is similar to the existing IntServ behaviour. Between them, the PCN-boundary-nodes must encircle the PCN-domain; otherwise, PCN-packets could enter the PCN-domain without being subject to admission control, which would potentially destroy the QoS of existing flows.
o PCN-ingressノードは、PCN-Flowが合意された制限内に固執することを保証し、認められたPCNフローのみがPCN型輸送業者にPCNドメインに寄与するようにします。ポリサーは、この権限の外にあるPCNパケットをドロップ（または別のDSCPにダウングレードする）必要があります。これは、既存のIntServの動作に似ています。それらの間で、PCNバウンドノードはPCNドメインを囲む必要があります。それ以外の場合、PCNパケットは、既存のフローのQOを破壊する可能性があるため、入場制御の対象となることなくPCNドメインに入る可能性があります。
o PCN-interior-nodes are not flow-aware. This prevents some security attacks where an attacker targets specific flows in the data plane -- for instance, for DoS or eavesdropping.
o PCNインタレオンノードはフロー認識ではありません。これにより、攻撃者がデータプレーン内の特定のフローをターゲットにするセキュリティ攻撃を防ぎます。たとえば、DOや盗聴の場合。
o The PCN-boundary-nodes rely on correct PCN-marking by the PCN-interior-nodes. For instance, a rogue PCN-interior-node could PCN-mark all packets so that no flows were admitted. Another possibility is that it doesn't PCN-mark any packets, even when it is pre-congested. More subtly, the rogue PCN-interior-node could perform these attacks selectively on particular flows, or it could PCN-mark the correct fraction overall but carefully choose which flows it marked.
o PCNバウンダリーノードは、PCNインタートゥノードによる正しいPCNマークに依存しています。たとえば、Rogue PCN-Interior-NodeはすべてのパケットをPCNマークすることができ、フローが認められないようにします。もう1つの可能性は、事前に組み合わされている場合でも、パケットをPCNマークしないことです。さらに微妙なことに、Rogue PCN-Interior-Nodeは、特定のフローでこれらの攻撃を選択的に実行するか、全体的に正しい割合をPCNマークする可能性がありますが、マークしたフローを慎重に選択することができます。
o The PCN-boundary-nodes should be able to deal with DoS attacks and state exhaustion attacks based on fast changes in per-flow signalling.
o PCN結合ノードは、流量ごとのシグナル伝達の急速な変化に基づいて、DOS攻撃と州の疲労攻撃に対処できるはずです。
o The signalling between the PCN-boundary-nodes must be protected from attacks. For example, the recipient needs to validate that the message is indeed from the node that claims to have sent it. Possible measures include digest authentication and protection against replay and man-in-the-middle attacks. For the RSVP protocol specifically, hop-by-hop authentication is in [RFC2747], and [Behringer09] may also be useful.
o PCNバウンダリーノード間の信号は、攻撃から保護する必要があります。たとえば、受信者は、メッセージが実際にそれを送信したと主張するノードからであることを検証する必要があります。考えられる手段には、消化認証とリプレイと中間の攻撃に対する保護が含まれます。RSVPプロトコルの場合、具体的には、ホップバイホップ認証が[RFC2747]にあり、[Behringer09]も有用かもしれません。
Operational security advice is given in Section 5.5.
運用上のセキュリティアドバイスは、セクション5.5に記載されています。
This document describes a general architecture for flow admission and termination based on pre-congestion information, in order to protect the quality of service of established, inelastic flows within a single Diffserv domain. The main topic is the functional architecture. This document also mentions other topics like the assumptions and open issues associated with the PCN architecture.
このドキュメントでは、単一のdiffservドメイン内の確立された非弾性フローのサービスの品質を保護するために、フロー入場と終了のための一般的なアーキテクチャについて説明します。主なトピックは機能アーキテクチャです。このドキュメントでは、PCNアーキテクチャに関連する仮定や未解決の問題などの他のトピックについても言及しています。
This document is a revised version of an earlier individual working draft authored by: P. Eardley, J. Babiarz, K. Chan, A. Charny, R. Geib, G. Karagiannis, M. Menth, and T. Tsou. They are therefore contributors to this document.
このドキュメントは、P。アーレイ、J。バビアルツ、K。チャン、A。チャーニー、R。ガイブ、G。カラギアンニス、M。メンタ、およびT.ツーが作成した以前の個々の作業ドラフトの改訂版です。したがって、彼らはこの文書への貢献者です。
Thanks to those who have made comments on this document: Lachlan Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake, Ron Bonica, Scott Bradner, Bob Briscoe, Ross Callon, Jason Canon, Ken Carlberg, Anna Charny, Joachim Charzinski, Andras Csaszar, Francis Dupont, Lars Eggert, Pasi Eronen, Adrian Farrel, Ruediger Geib, Wei Gengyu, Robert Hancock, Fortune Huang, Christian Hublet, Cullen Jennings, Ingemar Johansson, Georgios Karagiannis, Hein Mekkes, Michael Menth, Toby Moncaster, Dimitri Papadimitriou, Dan Romascanu, Daisuke Satoh, Ben Strulo, Tom Taylor, Hannes Tschofenig, Tina Tsou, David Ward, Lars Westberg, Magnus Westerlund, and Delei Yu. Thanks to Bob Briscoe who extensively revised the Operations and Management section.
この文書についてコメントしてくれた人たちに感謝します：ラクラン・アンドリュー、ジョー・バビアーズ、フレッド・ベイカー、デビッド・ブラック、スティーブン・ブレイク、ロン・ボニカ、スコット・ブラッドナー、ボブ・ブリスコー、ロスコロン、ジェイソン・キヤノン、ケン・カーールバーグ、アンナ・チャーニー、ヨアチム・チャージンスキー、アンドラス・クサスザール、フランシス・デュポン、ラース・エガート、パシ・エロネン、エイドリアン・ファレル、ルーディガー・ギブ、ウェイ・ジェンギュー、ロバート・ハンコック、フォーチュン・ファン、クリスチャン・ヘブレット、カレン・ジェニングス、インゲマール・ヨハンソン、ジョージズ・カラギアンニス、ヘイン・メークス、マイケル・メイクス、マイケル・メイクス、ダン・ロマスカヌ、サトー島、ベン・ストルロ、トム・テイラー、ハンヌ・ツコフェニグ、ティナ・ツァウ、デビッド・ウォード、ラース・ウェストバーグ、マグナス・ウェスターランド、デレイ・ユ。オペレーションと管理セクションを広範囲に改訂したボブブリスコに感謝します。
This document is the result of discussions in the PCN WG and forerunner activity in the TSVWG. A number of previous drafts were presented to TSVWG; their authors were: B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley, G. Karagiannis, A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G. Liu, and A. Bhargava.
このドキュメントは、TSVWGでのPCN WGおよび前官活動での議論の結果です。以前のドラフトの多くがTSVWGに提示されました。彼らの著者は、B。Briscoe、P。Eardley、D。Songhurst、F。LeFaucheur、A。Charny、J。Babiarz、K。Chan、S。Dudley、G。Karagiannis、A。Bader、L。Westberg、J JZhang、V。Liatsos、X-g。Liu、およびA. Bhargava。
The admission control mechanism evolved from the work led by Martin Karsten on the Guaranteed Stream Provider developed in the M3I project [Karsten02] [M3I], which in turn was based on the theoretical work of Gibbens and Kelly [Gibbens99].
M3Iプロジェクト[Karsten02] [M3I]で開発された保証されたストリームプロバイダーでMartin Karstenが率いる作業から進化した入学制御メカニズムは、GibbensとKelly [Gibbens99]の理論的研究に基づいていました。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[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.スティリアディス、 "迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633] Braden、B.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「政策ベースの入場管理の枠組み」、RFC 2753、2000年1月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[RFC2998] Bernet、Y.、Ford、P.、Yavatkar、R.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B.、Wroclawski、J。、およびEFelstaine、「Diffserv Networksを介した統合サービス操作のフレームワーク」、RFC 2998、2000年11月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」、RFC 3393、2002年11月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726] Brunner、M。、「シグナリングプロトコルの要件」、RFC 3726、2004年4月。
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216] Zhang、R。およびJ. Vasseur、「MPLS自律システム（AS）トラフィックエンジニアリング（TE）要件」、RFC 4216、2005年11月。
[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月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「Diffserv Service Classeの構成ガイドライン」、RFC 4594、2006年8月。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「一元配置活動測定プロトコル（OWAMP）」、RFC 4656、2006年9月。
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, November 2006.
[RFC4774] Floyd、S。、「明示的な混雑通知（ECN）フィールドの代替セマンティクスの指定」、BCP 124、RFC 4774、2006年11月。
[RFC4778] Kaeo, M., "Operational Security Current Practices in Internet Service Provider Environments", RFC 4778, January 2007.
[RFC4778] Kaeo、M。、「インターネットサービスプロバイダー環境における運用セキュリティ現在の慣行」、RFC 4778、2007年1月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129] Davie、B.、Briscoe、B。、およびJ. Tay、「MPLSでの明示的な渋滞マーク」、RFC 5129、2008年1月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462] Andersson、L。およびR. Asati、「Multiprotocol Label Switching（MPLS）ラベルスタックエントリ：「Exp」フィールド「トラフィッククラス」フィールドに改名された「RFC 5462」、2009年2月。
[P.800] "Methods for subjective determination of transmission quality", ITU-T Recommendation P.800, August 1996.
[P.800]「送信品質の主観的決定の方法」、ITU-T推奨p.800、1996年8月。
[Y.1541] "Network Performance Objectives for IP-based Services", ITU-T Recommendation Y.1541, February 2006.
[Y.1541]「IPベースのサービスのネットワークパフォーマンス目標」、ITU-T推奨Y.1541、2006年2月。
[Babiarz06] Babiarz, J., Chan, K., Karagiannis, G., and P. Eardley, "SIP Controlled Admission and Preemption", Work in Progress, October 2006.
[Babiarz06] Babiarz、J.、Chan、K.、Karagiannis、G。、およびP. Eardley、「SIP Controlled入学と先制」、2006年10月の作業。
[Behringer09] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, March 2009.
[Behringer09] Behringer、M。およびF. Le Faucheur、「RSVPセキュリティのためのキーイングメソッドの適用可能性」、2009年3月、進行中の作業。
[Briscoe06] Briscoe, B., Eardley, P., Songhurst, D., Le Faucheur, F., Charny, A., Babiarz, J., Chan, K., Dudley, S., Karagiannis, G., Bader, A., and L. Westberg, "An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a Diffserv Region", Work in Progress, October 2006.
[Briscoe06] Briscoe、B.、Eardley、P.、Songhurst、D.、Le Faucheur、F.、Charny、A.、Babiarz、J.、Chan、K.、Dudley、S.、Karagiannis、G.、Bader、A。、およびL. Westberg、「前もって前の通知のためのエッジとエッジの展開モデル：Diffserv地域の入場制御」、2006年10月、進行中の作業。
[Briscoe08] Briscoe, B., "Emulating Border Flow Policing using Re-PCN on Bulk Data", Work in Progress, September 2008.
[Briscoe08] Briscoe、B。、「バルクデータでRe-PCNを使用した境界線のポリシングをエミュレートする」、2008年9月、進行中の作業。
[Briscoe09] Briscoe, B., "Tunnelling of Explicit Congestion Notification", Work in Progress, March 2009.
[Briscoe09] Briscoe、B。、「明示的な混雑通知のトンネル」、2009年3月、作業中。
[Bryant08] Bryant, S., Davie, B., Martini, L., and E. Rosen, "Pseudowire Congestion Control Framework", Work in Progress, May 2008.
[Bryant08] Bryant、S.、Davie、B.、Martini、L。、およびE. Rosen、「Pseudowire commestion Control Framework」、2008年5月の作業。
[Charny07-1] Charny, A., Babiarz, J., Menth, M., and X. Zhang, "Comparison of Proposed PCN Approaches", Work in Progress, November 2007.
[Charny07-1] Charny、A.、Babiarz、J.、Menth、M。、およびX. Zhang、「提案されたPCNアプローチの比較」、2007年11月の作業。
[Charny07-2] Charny, A., Zhang, X., Le Faucheur, F., and V. Liatsos, "Pre-Congestion Notification Using Single Marking for Admission and Termination", Work in Progress, November 2007.
[Charny07-2] Charny、A.、Zhang、X.、Le Faucheur、F。、およびV. Liatsos、「入場と終了のための単一のマーキングを使用した前の通知」、2007年11月、作業。
[Charny07-3] Charny, A., "Email to PCN WG mailing list", November 2007, <http://www1.ietf.org/mail-archive/ web/pcn/current/msg00871.html>.
[Charny07-3] Charny、A。、「PCN WGメーリングリストへのメール」、2007年11月、<http://www1.ietf.org/mail-archive/ web/pcn/current/msg00871.html>。
[Charny08] Charny, A., "Email to PCN WG mailing list", March 2008, <http://www1.ietf.org/mail-archive/web/ pcn/current/msg01359.html>.
[Charny08] Charny、A。、「PCN WGメーリングリストへのメール」、2008年3月、<http://www1.ietf.org/mail-archive/web/ pcn/current/msg01359.html>。
[Eardley07] Eardley, P., "Email to PCN WG mailing list", October 2007, <http://www1.ietf.org/mail-archive/ web/pcn/current/msg00831.html>.
[Eardley07] Eardley、P。、「PCN WGメーリングリストへのメール」、2007年10月、<http://www1.ietf.org/mail-archive/ web/pcn/current/msg00831.html>。
[Eardley09] Eardley, P., "Metering and marking behaviour of PCN-nodes", Work in Progress, May 2009.
[Eardley09] Eardley、P。、「PCN-Nodesの測定およびマーキングの動作」、2009年5月、進行中の作業。
[Gibbens99] Gibbens, R. and F. Kelly, "Distributed connection acceptance control for a connectionless network", Proceedings International Teletraffic Congress (ITC16), Edinburgh, pp. 941-952, 1999.
[Gibbens99] Gibbens、R。and F. Kelly、「コネクションレスネットワークの配布された接続受け入れコントロール」、Proceedings International Teletraffic Congress（ITC16）、Edinburgh、pp。941-952、1999。
[Hancock02] Hancock, R. and E. Hepworth, "Slide 14 of 'NSIS: An Outline Framework for QoS Signalling'", May 2002, <h ttp://www-nrc.nokia.com/sua/nsis/interim/ nsis-framework-outline.ppt>.
[hancock02] Hancock、R。and E. Hepworth、「 'nsisのスライド14：qos信号の概要フレームワーク」、2002年5月、<h ttp：//www-nrc.nokia.com/sua/nsis/interim/ nsis-framework-outline.ppt>。
[Iyer03] Iyer, S., Bhattacharyya, S., Taft, N., and C. Diot, "An approach to alleviate link overload as observed on an IP backbone", IEEE INFOCOM, 2003, <http://www.ieee-infocom.org/2003/papers/10_04.pdf>.
[Iyer03] Iyer、S.、Bhattacharyya、S.、Taft、N。、およびC. Diot、「IPバックボーンで観察されたリンク過負荷を軽減するアプローチ」、IEEE Infocom、2003、<http：// www。IEEE-infocom.org/2003/papers/10_04.pdf>。
[Karsten02] Karsten, M. and J. Schmitt, "Admission Control Based on Packet Marking and Feedback Signalling -- Mechanisms, Implementation and Experiments", TU-Darmstadt Technical Report TR-KOM-2002-03, May 2002, <http://www.kom.e-technik.tu-darmstadt.de/ publications/abstracts/KS02-5.html>.
[Karsten02] Karsten、M。およびJ. Schmitt、「パケットマーキングとフィードバックシグナル伝達に基づく入場制御 - メカニズム、実装、実験」、Tu-DarmstadtテクニカルレポートTR-KOM-2002-03、2002年5月、<HTTP：//www.kom.e-technik.tu-darmstadt.de/ publications/abstracts/ks02-5.html>。
[Kumar01] Kumar, A., Rastogi, R., Silberschatz, A., and B. Yener, "Algorithms for Provisioning Virtual Private Networks in the Hose Model", Proceedings ACM SIGCOMM (ITC16), , 2001.
[Kumar01] Kumar、A.、Rastogi、R.、Silberschatz、A。、およびB. Yener、「ホースモデルに仮想プライベートネットワークをプロビジョニングするためのアルゴリズム」、Proceedings ACM SigComm（ITC16）、、2001。
[Lefaucheur06] Le Faucheur, F., Charny, A., Briscoe, B., Eardley, P., Babiarz, J., and K. Chan, "RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN)", Work in Progress, June 2006.
[Lefaucheur06] Le Faucheur、F.、Charny、A.、Briscoe、B.、Eardley、P.、Babiarz、J。、およびK. Chan、 "RSVP拡張事前測定通知（PCN）"、2006年6月、進行中の作業。
[M3I] "M3I - Market Managed Multiservice Internet", <http://www.m3iproject.org/>.
[M3I] "M3I -Market Managed Multiservice Internet"、<http://www.m3iproject.org/>。
[Menth08-1] Menth, M., Lehrieder, F., Eardley, P., Charny, A., and J. Babiarz, "Edge-Assisted Marked Flow Termination", Work in Progress, February 2008.
[Menth08-1] Menth、M.、Lehrideer、F.、Eardley、P.、Charny、A。、およびJ. Babiarz、「エッジアシストマークフロー終了」、2008年2月に進行中の作業。
[Menth08-2] Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, "PCN Encoding for Packet-Specific Dual Marking (PSDM)", Work in Progress, July 2008.
[Menth08-2] Menth、M.、Babiarz、J.、Moncaster、T。、およびB. Briscoe、「PCNエンコーディングパケット固有のデュアルマーキング（PSDM）」、2008年7月、作業。
[Menth09-1] Menth, M. and M. Hartmann, "Threshold Configuration and Routing Optimization for PCN-Based Resilient Admission Control", Computer Networks, 2009, <http://dx.doi.org/10.1016/j.comnet.2009.01.013>.
[Menth09-1] Menth、M。およびM. Hartmann、「PCNベースの回復力のある入場制御のしきい値構成とルーティング最適化」、Computer Networks、2009、<http://dx.doi.org/10.1016/j.comnet.2009.01.013>。
[Menth09-2] Menth, M., Lehrieder, F., Briscoe, B., Eardley, P., Moncaster, T., Babiarz, J., Chan, K., Charny, A., Karagiannis, G., Zhang, X., Taylor, T., Satoh, D., and R. Geib, "A Survey of PCN-Based Admission Control and Flow Termination", IEEE Communications Surveys and Tutorials, <http:// www3.informatik.uni-wuerzburg.de/staff/menth/ Publications/papers/Menth08-PCN-Overview.pdf>>.
[Menth09-2] Menth、M.、Lehrideer、F.、Briscoe、B.、Eardley、P.、Moncaster、T.、Babiarz、J.、Chan、K.、Charny、A.、Karagiannis、G。、Zhang、X.、Taylor、T.、Satoh、D。、およびR. Geib、「PCNベースの入場制御とフロー終了の調査」、IEEE通信調査およびチュートリアル、<http：// www3.informatik.uni-wuerzburg.de/staff/menth/ publications/papers/menth08-pcn-overview.pdf >>。
[Moncaster09-1] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", Work in Progress, May 2009.
[Moncaster09-1] Moncaster、T.、Briscoe、B。、およびM. Menth、「ベースラインのエンコードと事前の情報の輸送」、2009年5月、進行中の作業。
[Moncaster09-2] Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding using 2 DSCPs to provide 3 or more states", Work in Progress, April 2009.
[Moncaster09-2] Moncaster、T.、Briscoe、B。、およびM. Menth、「2つ以上のDSCPSを使用して3つ以上の状態を提供するPCN」、2009年4月、進行中の作業。
[Sarker08] Sarker, Z. and I. Johansson, "Usecases and Benefits of end to end ECN support in PCN Domains", Work in Progress, November 2008.
[Sarker08] Sarker、Z。およびI. Johansson、「PCNドメインでのEnd to End ECNサポートのUSECASESと利点」、2008年11月の作業。
[Songhurst06] Songhurst, DJ., Eardley, P., Briscoe, B., Di Cairano Gilfedder, C., and J. Tay, "Guaranteed QoS Synthesis for Admission Control with Shared Capacity", BT Technical Report TR-CXR9-2006-001, Feburary 2006, <http://www.cs.ucl.ac.uk/staff/ B.Briscoe/projects/ipe2eqos/gqs/papers/ GQS_shared_tr.pdf>.
[Songhurst06] Songhurst、DJ。、Eardley、P.、Briscoe、B.、Di Cairano Gilfedder、C。、およびJ. Tay、「共有能力を備えた入学制御のための保証QoS合成」、BTテクニカルレポートTR-CXR9-2006-001、Feburary 2006、<http://www.cs.ucl.ac.uk/staff/ b.briscoe/projects/ipe2eqos/gqs/gqs_shared_tr.pdf>。
[Taylor09] Charny, A., Huang, F., Menth, M., and T. Taylor, "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation", Work in Progress, March 2009.
[Taylor09] Charny、A.、Huang、F.、Menth、M。、およびT. Taylor、「制御荷重（CL）動作モードのPCN境界ノード動作」、2009年3月の作業。
[Tsou08] Tsou, T., Huang, F., and T. Taylor, "Applicability Statement for the Use of Pre-Congestion Notification in a Resource-Controlled Network", Work in Progress, November 2008.
[TSOU08] Tsou、T.、Huang、F。、およびT. Taylor、「リソース制御ネットワークでの事前発生通知を使用するためのアプリケーションステートメント」、2008年11月の作業。
[Westberg08] Westberg, L., Bhargava, A., Bader, A., Karagiannis, G., and H. Mekkes, "LC-PCN: The Load Control PCN Solution", Work in Progress, November 2008.
[Westberg08] Westberg、L.、Bhargava、A.、Bader、A.、Karagiannis、G。、およびH. Mekkes、「LC-PCN：The Load Control PCN Solution」、2008年11月の作業。
This section mentions some topics that are outside the PCN WG's current charter but that have been mentioned as areas of interest. They might be work items for the PCN WG after a future re-chartering, some other IETF WG, another standards body, or an operator-specific usage that is not standardised.
このセクションでは、PCN WGの現在の憲章の外側にあるが、関心のある領域として言及されているいくつかのトピックについて説明します。それらは、将来の再請求、他のIETF WG、別の標準団体、または標準化されていないオペレーター固有の使用の後、PCN WGの作業項目である可能性があります。
Note: It should be crystal clear that this section discusses possibilities only.
注：このセクションでは、可能性のみについてのみ説明していることは明確である必要があります。
The first set of possibilities relate to the restrictions described in Section 6.3:
可能性の最初のセットは、セクション6.3で説明されている制限に関連しています。
o A single PCN-domain encompasses several autonomous systems that do not trust each other. A possible solution is a mechanism like re-PCN [Briscoe08].
o 単一のPCNドメインには、お互いを信頼していないいくつかの自律システムが含まれます。可能な解決策は、Re-PCN [briscoe08]のようなメカニズムです。
o Not all the nodes run PCN. For example, the PCN-domain is a multi-site enterprise network. The sites are connected by a VPN tunnel; although PCN doesn't operate inside the tunnel, the PCN mechanisms still work properly because of the good QoS on the virtual link (the tunnel). Another example is that PCN is deployed on the general Internet (ie, widely but not universally deployed).
o すべてのノードがPCNを実行するわけではありません。たとえば、PCNドメインはマルチサイトエンタープライズネットワークです。サイトはVPNトンネルで接続されています。PCNはトンネル内で動作しませんが、仮想リンク（トンネル）の適切なQoSのため、PCNメカニズムは依然として適切に機能します。別の例は、PCNが一般的なインターネットに展開されていることです（すなわち、広く展開されていませんが、広く展開されていません）。
o Applying the PCN mechanisms to other types of traffic, ie, beyond inelastic traffic -- for instance, applying the PCN mechanisms to traffic scheduled with the Assured Forwarding per-hop behaviour. One example could be flow-rate adaptation by elastic applications that adapt according to the pre-congestion information.
o PCNメカニズムを他のタイプのトラフィックに適用します。つまり、非弾性トラフィックを超えて、たとえば、保証された転送ごとの動作でスケジュールされたトラフィックにPCNメカニズムを適用します。1つの例は、事前の情報に従って適応する弾性アプリケーションによるフローレート適応です。
o The aggregation assumption doesn't hold, because the link capacity is too low. Measurement-based admission control is less accurate, with a greater risk of over-admission for instance.
o リンク容量が低すぎるため、集約の仮定は成り立ちません。測定ベースの入場制御の精度は低く、たとえば過剰な許可のリスクが高くなります。
o The applicability of PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.).
o 緊急使用のためのPCNメカニズムの適用可能性（911、GET、WPS、MLPPなど）。
Other possibilities include:
その他の可能性には次のものがあります。
o Probing. This is discussed in Appendix A.1 below.
o 調査。これについては、以下の付録A.1で説明します。
o The PCN-domain extends to the end users. This scenario is described in [Babiarz06]. The end users need to be trusted to do their own policing. If there is sufficient traffic, then the aggregation assumption may hold. A variant is that the PCN-domain extends out as far as the LAN edge switch.
o PCNドメインはエンドユーザーに拡張されます。このシナリオは[babiarz06]で説明されています。エンドユーザーは、独自のポリシングを行うために信頼される必要があります。十分なトラフィックがある場合、集約の仮定が保持される場合があります。バリアントは、PCNドメインがLANエッジスイッチまで拡張されることです。
o Indicating pre-congestion through signalling messages rather than in-band (in the form of PCN-marked packets).
o インバンドではなく、シグナリングメッセージを介した事前相関を示します（PCNマークされたパケットの形式）。
o The decision-making functionality is at a centralised node rather than at the PCN-boundary-nodes. This requires that the PCN-egress-node signals PCN-feedback-information to the centralised node, and that the centralised node signals to the PCN-ingress-node the decision about admission (or termination). Such possibility may need the centralised node and the PCN-boundary-nodes to be configured with each other's addresses. The centralised case is described further in [Tsou08].
o 意思決定機能は、PCN結合ノードではなく集中ノードにあります。これには、PCN-Egress-Nodeが集中ノードにPCN-Feedback情報を信号すること、および集中型ノードがPCN-ingress-Nodeに入場に関する決定（または終了）を信号することが必要です。このような可能性には、集中ノードとPCNバウンドリーノードが互いのアドレスで構成される必要がある場合があります。集中症例については、[TSOU08]でさらに説明しています。
o Signalling extensions for specific protocols (eg, RSVP and NSIS) -- for example, the details of how the signalling protocol installs the flowspec at the PCN-ingress-node for an admitted PCN-flow, and how the signalling protocol carries the PCN-feedback-information. Perhaps also for other functions such as for coping with failure of a PCN-boundary-node ([Briscoe06] considers what happens if RSVP is the QoS signalling protocol) and for establishing a tunnel across the PCN-domain if it is necessary to carry ECN marks transparently.
o 特定のプロトコル（例：RSVPおよびNSIS）のシグナル伝達拡張 - たとえば、シグナリングプロトコルがPCN-ingress-NodeにFlowsPecをインストールする方法の詳細は、認められたPCNフローのために、およびシグナリングプロトコルがPCNを運ぶ方法の詳細フィードバック情報。おそらく、PCN結合ノードの障害に対処するための他の機能（[briscoe06]は、RSVPがQoSシグナル伝達プロトコルである場合に何が起こるかを考慮したり、ECNを運ぶ必要がある場合はPCNドメイン全体にトンネルを確立するために透過的にマーク。
o Policing by the PCN-ingress-node may not be needed if the PCN-domain can trust that the upstream network has already policed the traffic on its behalf.
o PCNドメインがアップストリームネットワークがすでにトラフィックを代表してポリシングしていることを信頼できる場合、PCN-ingress-Nodeによるポリシングは必要ない場合があります。
o PCN for Pseudowire. PCN may be used as a congestion avoidance mechanism for edge-to-edge pseudowire emulations [Bryant08].
o PSEUDOWIREのPCN。PCNは、エッジからエッジへの擬似具体的なエミュレーションの輻輳回避メカニズムとして使用される場合があります[Bryant08]。
o PCN for MPLS. [RFC3270] defines how to support the Diffserv architecture in MPLS (Multiprotocol Label Switching) networks. [RFC5129] describes how to add PCN for admission control of microflows into a set of MPLS aggregates. PCN-marking is done in MPLS's EXP field (which [RFC5462] re-names the Class of Service (CoS) field).
o MPLのPCN。[RFC3270]は、MPLS（Multiprotocol Label Switching）ネットワークのDiffservアーキテクチャをサポートする方法を定義します。[RFC5129]は、MPLS凝集体のセットにマイクロフローの入場制御のためにPCNを追加する方法について説明します。PCNマークは、MPLSのEXPフィールド（[RFC5462]がサービスのクラス（COS）フィールドを再名前化する）で行われます。
o PCN for Ethernet. Similarly, it may be possible to extend PCN into Ethernet networks, where PCN-marking is done in the Ethernet header. Note: Specific consideration of this extension is outside of the IETF's remit.
o イーサネット用PCN。同様に、PCNをイーサネットネットワークに拡張することが可能かもしれません。ここでは、PCNマークがイーサネットヘッダーで行われます。注：この拡張機能の具体的な考慮事項は、IETFの送金の外側にあります。
Probing is a potential mechanism to assist admission control.
調査は、入学制御を支援する潜在的なメカニズムです。
PCN's admission control, as described so far, is essentially a reactive mechanism where the PCN-egress-node monitors the pre-congestion level for traffic from each PCN-ingress-node; if the level rises, then it blocks new flows on that ingress-egress-aggregate. However, it's possible that an ingress-egress-aggregate carries no traffic, and so the PCN-egress-node can't make an admission decision using the usual method described earlier.
これまでに説明されているように、PCNの入場制御は、PCN-Egress-Nodeが各PCN-ingress-Nodeからのトラフィックの前状のレベルを監視する反応的なメカニズムです。レベルが上昇すると、その侵入侵入攻撃の新しいフローをブロックします。ただし、侵入侵入攻撃にはトラフィックがない可能性があるため、PCN-Egress-Nodeは前述の通常の方法を使用して入学決定を下すことができません。
One approach is to be "optimistic" and simply admit the new flow. However, it's possible to envisage a scenario where the traffic levels on other ingress-egress-aggregates are already so high that they're blocking new PCN-flows, and admitting a new flow onto this "empty" ingress-egress-aggregate adds extra traffic onto a link that is already pre-congested. This may 'tip the balance' so that PCN's flow termination mechanism is activated or some packets are dropped. This risk could be lessened by configuring, on each link, a sufficient 'safety margin' above the PCN-threshold-rate.
1つのアプローチは、「楽観的」であり、単に新しいフローを認めることです。ただし、他のイングレス侵入攻撃のトラフィックレベルがすでに非常に高いため、新しいPCNフローをブロックし、この「空の」Ingress-Egress-Aggregateに新しいフローを認めているシナリオを想像することができます。既に事前に行われているリンクへのトラフィック。これにより、PCNのフロー終了メカニズムがアクティブ化されるか、一部のパケットがドロップされるように、「バランスを傾ける」ことがあります。このリスクは、各リンクで、PCNスレッジレートの上に十分な「安全マージン」を構成することで減らすことができます。
An alternative approach is to make PCN a more proactive mechanism. The PCN-ingress-node explicitly determines, before admitting the prospective new flow, whether the ingress-egress-aggregate can support it. This can be seen as a "pessimistic" approach, in contrast to the "optimism" of the approach above. It involves probing: a PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level that the flow would experience.
別のアプローチは、PCNをより積極的なメカニズムにすることです。PCN-ingress-Nodeは、将来の新しい流れを認める前に、イングレス侵入攻撃がそれをサポートできるかどうかを明示的に決定します。これは、上記のアプローチの「楽観主義」とは対照的に、「悲観的な」アプローチと見なすことができます。プロービングが含まれます。PCN-ingress-Nodeは、流れが発生するプレコンション前のレベルをテストするために、プローブパケットを生成および送信します。
One possibility is that a probe packet is just a dummy data packet, generated by the PCN-ingress-node and addressed to the PCN-egress-node.
1つの可能性は、プローブパケットは、PCN-ingressノードによって生成され、PCN-Egress-Nodeに宛てられたダミーデータパケットであることです。
The probing functions are:
プロービング関数は次のとおりです。
o Make the decision that probing is needed. As described above, this is when the ingress-egress-aggregate (or the ECMP path -- see Section 6.4) carries no PCN-traffic. An alternative is to always probe, ie, probe before admitting any PCN-flow.
o 調査が必要であるという決定を下します。上記のように、これは、イングレス侵入攻撃（またはECMPパス - セクション6.4を参照）がPCNトラフィックを持たない場合です。別の方法は、PCN-Flowを認める前に、常にプローブ、つまりプローブすることです。
o (if required) Communicate the request that probing is needed; the PCN-egress-node signals to the PCN-ingress-node that probing is needed.
o （必要に応じて）プロービングが必要であるという要求を伝えます。PCN-Egress-Nodeは、PCN-Ingress-Nodeに信号を送信し、調査が必要であることを示します。
o (if required) Generate probe traffic; the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-metering algorithm; for example, an excess-traffic-metering algorithm triggers fewer PCN-marks than a threshold-metering algorithm, and so will need more probe packets.
o （必要に応じて）プローブトラフィックを生成します。PCN-ingressノードは、プローブトラフィックを生成します。プローブパケットの適切な数（またはレート）は、PCNメーターアルゴリズムに依存します。たとえば、過剰な交通量を取得するアルゴリズムは、しきい値計算アルゴリズムよりもPCNマークが少ないため、より多くのプローブパケットが必要になります。
o Forward probe packets; as far as PCN-interior-nodes are concerned, probe packets are handled the same as (ordinary data) PCN-packets in terms of routing, scheduling, and PCN-marking.
o フォワードプローブパケット。PCN-Interior-Nodesに関する限り、プローブパケットは、ルーティング、スケジューリング、およびPCNマークの点で（通常のデータ）PCNパケットと同じように処理されます。
o Consume probe packets; the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain.
o プローブパケットを消費します。PCN-Egress-Nodeはプローブパケットを消費して、PCNドメインを超えて移動しないようにします。
It is an unresolved question whether probing is really needed, but two viewpoints have been put forward as to why it is useful. The first is perhaps the most obvious: there is no PCN-traffic on the ingress-egress-aggregate. The second assumes that multipath routing (eg, ECMP) is running in the PCN-domain. We now consider each in turn.
調査が本当に必要かどうかは未解決の質問ですが、なぜそれが役立つのかについて2つの視点が提案されています。1つ目はおそらく最も明白です。Ingress-Egress-AggregateにPCNトラフィックはありません。2番目は、MultiPathルーティング（例えば、ECMP）がPCNドメインで実行されていると仮定しています。今、それぞれを順番に検討します。
The first viewpoint assumes the following:
最初の視点は次のとおりです。
o There is no PCN-traffic on the ingress-egress-aggregate (so a normal admission decision cannot be made).
o Ingress-Egress-AggregateにはPCNトラフィックはありません（したがって、通常の入院決定はできません）。
o Simply admitting the new flow has a significant risk of leading to overload: packets dropped or flows terminated.
o 単に新しいフローを認めるだけで、過負荷につながる大きなリスクがあります。パケットがドロップされるか、終了します。
On the former bullet, [Eardley07] suggests that, during the future busy hour of a national network with about 100 PCN-boundary-nodes, there are likely to be significant numbers of aggregates with very few flows under nearly all circumstances.
以前の弾丸では、[Eardley07]は、約100個のPCN結合ノードを持つ全国ネットワークの将来の忙しい時間に、ほぼすべての状況下で非常に少ないフローを持つ集合体がかなりの数がある可能性が高いことを示唆しています。
The latter bullet could occur if new flows start on many of the empty ingress-egress-aggregates, which together overload a link in the PCN-domain. To be a problem, this would probably have to happen in a short time period (flash crowd) because, after the reaction time of the system, other (non-empty) ingress-egress-aggregates that pass through the link will measure pre-congestion and so block new flows. Also, flows naturally end anyway.
後者の弾丸は、PCNドメインにリンクを過負荷にする空の侵入侵入攻撃の多くで新しいフローが起動すると発生する可能性があります。問題になるためには、システムの反応時間の後、リンクを通過する他の（空白の）侵入egress-攻撃の後、リンクを測定するため、これはおそらく短期間（フラッシュクラウド）で発生する必要があります。混雑と新しいフローをブロックします。また、とにかく自然に流れます。
The downsides of probing for this viewpoint are:
この視点の調査の欠点は次のとおりです。
o Probing adds delay to the admission control process.
o プロービングは、入場制御プロセスに遅延を追加します。
o Sufficient probing traffic has to be generated to test the pre-congestion level of the ingress-egress-aggregate. But the probing traffic itself may cause pre-congestion, causing other PCN-flows to be blocked or even terminated -- and, in the flash crowd scenario, there will be probing on many ingress-egress-aggregates.
o 入り込み込み録音の前レベルをテストするには、十分な調査トラフィックを生成する必要があります。しかし、トラフィックの調査自体が事前に発生し、他のPCNフローがブロックされたり終了したりする可能性があり、フラッシュクラウドのシナリオでは、多くの侵入侵入侵入攻撃の調査が行われます。
The second viewpoint applies in the case where there is multipath routing (eg, ECMP) in the PCN-domain. Note that ECMP is often used on core networks. There are two possibilities:
2番目の視点は、PCNドメインにマルチパスルーティング（ECMPなど）がある場合に適用されます。ECMPはコアネットワークでよく使用されることに注意してください。2つの可能性があります：
(1) If admission control is based on measurements of the ingress-egress-aggregate, then the viewpoint that probing is useful assumes:
(1) 入場制御が侵入侵入と攻撃の測定に基づいている場合、プロービングが有用であるという視点は次のとおりです。
* There's a significant chance that the traffic is unevenly balanced across the ECMP paths and, hence, there's a significant risk of admitting a flow that should be blocked (because it follows an ECMP path that is pre-congested) or of blocking a flow that should be admitted.
* ECMPパス全体でトラフィックが不均一にバランスが取れているため、ブロックされるべきフローを認めるという重大なリスクがある可能性があります（事前に組み込まれているECMPパスに従うため）またはフローをブロックすることができます。認められます。
Note: [Charny07-3] suggests unbalanced traffic is quite possible, even with quite a large number of flows on a PCN-link (eg, 1000), when Assumption 3 (aggregation) is likely to be satisfied.
注：[charny07-3]は、仮定3（集約）が満たされる可能性が高い場合、PCNリンク上の非常に多くのフロー（例えば、1000）でのフローがかなり多い場合でも、不均衡なトラフィックが非常に可能であることを示唆しています。
(2) If admission control is based on measurements of pre-congestion on specific ECMP paths, then the viewpoint that probing is useful assumes:
(2) 入学制御が特定のECMPパスでの事前相関の測定に基づいている場合、プロービングが有用であるという視点は次のとおりです。
* There is no PCN-traffic on the ECMP path on which to base an admission decision.
* ECMPパスには、入場決定の基礎となるPCNトラフィックはありません。
* Simply admitting the new flow has a significant risk of leading to overload.
* 単に新しいフローを認めるだけで、過負荷につながる大きなリスクがあります。
* The PCN-egress-node can match a packet to an ECMP path.
* PCN-Egress-Nodeは、パケットをECMPパスに一致させることができます。
Note: This is similar to the first viewpoint and so, similarly, could occur in a flash crowd if a new flow starts more or less simultaneously on many of the empty ECMP paths. Because there are several ECMP paths between each pair of PCN-boundary-nodes, it's presumably more likely that an ECMP path is "empty" than an ingress-egress-aggregate is. To constrain the number of ECMP paths, a few tunnels could be set up between each pair of PCN- boundary-nodes. Tunnelling also solves the issue in the point immediately above (which is otherwise hard to solve because an ECMP routing decision is made independently on each node).
注：これは最初の視点に似ているため、空のECMPパスの多くで新しいフローが多かれ少なかれ同時に起動する場合、フラッシュクラウドで同様に発生する可能性があります。PCN結合ノードの各ペアの間にいくつかのECMPパスがあるため、ECMPパスがイングレスエグレスアグゲートよりも「空」である可能性が高いと考えられます。ECMPパスの数を制約するために、PCN-境界ノードの各ペア間にいくつかのトンネルを設置できます。トンネリングは、上記のポイントの問題も解決します（それ以外の場合は、各ノードでECMPルーティングの決定が独立して行われるため、解決が困難です）。
The downsides of probing for this viewpoint are:
この視点の調査の欠点は次のとおりです。
o Probing adds delay to the admission control process.
o プロービングは、入場制御プロセスに遅延を追加します。
o Sufficient probing traffic has to be generated to test the pre-congestion level of the ECMP path. But there's the risk that the probing traffic itself may cause pre-congestion, causing other PCN-flows to be blocked or even terminated.
o ECMPパスの事前レベルをテストするには、十分な調査トラフィックを生成する必要があります。しかし、プロービングトラフィック自体が事前相関を引き起こし、他のPCNフローをブロックまたは終了する可能性があるというリスクがあります。
o The PCN-egress-node needs to consume the probe packets to ensure they don't travel beyond the PCN-domain, since they might confuse the destination end node. This is non-trivial, since probe packets are addressed to the destination end node in order to test the relevant ECMP path (ie, they are not addressed to the PCN-egress-node, unlike the first viewpoint above).
o PCN-Egressノードは、宛先エンドノードを混乱させる可能性があるため、PCNドメインを超えて移動しないようにプローブパケットを消費する必要があります。関連するECMPパスをテストするためにプローブパケットが宛先エンドノードにアドレス指定されるため、これは自明ではありません（つまり、上記の最初の視点とは異なり、PCN-Egress-Nodeにはアドレス指定されません）。
The open issues associated with these viewpoints include:
これらの視点に関連する未解決の問題は次のとおりです。
o What rate and pattern of probe packets does the PCN-ingress-node need to generate so that there's enough traffic to make the admission decision?
o PCN-Ingress-Nodeは、入学決定を下すのに十分なトラフィックがあるように、PCN-Ingress-Nodeを生成する必要がありますか？
o What difficulty does the delay (whilst probing is done), and possible packet drops, cause applications?
o 遅延（プロービングが行われている間）、および可能なパケットドロップがどのような困難を引き起こし、アプリケーションを引き起こしますか？
o Can the delay be alleviated by automatically and periodically probing on the ingress-egress-aggregate? Or does this add too much overhead?
o 遅延は、イングレス侵入攻撃を自動的かつ定期的に調査することで緩和できますか？それとも、頭上が多すぎますか？
o Are there other ways of dealing with the flash crowd scenario? For instance, by limiting the rate at which new flows are admitted, or perhaps by a PCN-egress-node blocking new flows on its empty ingress-egress-aggregates when its non-empty ones are pre-congested.
o フラッシュクラウドのシナリオを扱う他の方法はありますか？たとえば、新しいフローが認められる速度を制限するか、おそらく空の侵入 - 侵入 - 攻撃に新しいフローをブロックするPCN-egressノードによって、空の非在庫が事前に組み合わされている場合に制限することにより。
o (Second viewpoint only) How does the PCN-egress-node disambiguate probe packets from data packets (so it can consume the former)? The PCN-egress-node must match the characteristic setting of particular bits in the probe packet's header or body, but these bits must not be used by any PCN-interior-node's ECMP algorithm. In the general case, this isn't possible, but it should be possible for a typical ECMP algorithm (which examines the source and destination IP addresses and port numbers, the protocol ID, and the DSCP).
o （2番目の視点のみ）PCN-Egress-Nodeは、データパケットからプローブパケットをどのようにしていますか（前者を消費することができます）。PCN-Egress-Nodeは、プローブパケットのヘッダーまたはボディの特定のビットの特徴的な設定と一致する必要がありますが、これらのビットは、PCN-Interior-NodeのECMPアルゴリズムでは使用してはなりません。一般的なケースでは、これは不可能ですが、典型的なECMPアルゴリズム（ソースおよび宛先のIPアドレスとポート番号、プロトコルID、およびDSCPを調べる）では可能であるはずです。
Author's Address
著者の連絡先
Philip Eardley (editor) BT B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom
フィリップ・アードリー（編集者）BT B54/77、シリウス・ハウス・アダストラル・パーク・マーティルシャム・ヒース・イプスウィッチ、サフォークIP5 3REイギリス
EMail: philip.eardley@bt.com