Network Working Group P. Eardley, Ed.
Request for Comments: 5559 BT
Category: Informational June 2009
Pre-Congestion Notification (PCN) Architecture
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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）を保護することです。二つのメカニズムが使用される：アドミッション制御を、既存のフローの一部を終了するかどうかを決定するために、終了フロー（異常な状況で）認める又は新しいフロー要求をブロックし、するかどうかを決定します。これを達成するために、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-しきい値レートとPCN-過剰率）で構成されています。リンク上PCN-トラフィックの全体的な速度が設定速度を超えた場合、その後、PCN-内部ノードは、適切PCN-パケットをマークします。 PCN-出口-ノードは、アドミッション制御を行い、終了の決定を流れるように、この情報を使用します。フローアドミッション制御新しいフローが既存のPCN-フローのQoSに、通常の状況では、影響を与えることなく認められることができるか否かを判断します。しかし、異常な状況（例えば、災害が複数のノードに影響を与えるとトラフィックの再ルートを引き起こす）で、既存のPCN-フローのQoSは、これらの流れを導入するときには注意が払われていても分解し得ます。フロー終了機構は、残りのPCN-フローのQoSを保護するために十分なトラフィックを除去します。すべてのPCN-境界ノードとPCN-インテリア・ノードは、PCNに対応しており、正しいPCN操作のために信頼されています。彼らは合意されたフロースペックの範囲内に保つ入院PCN-フローの一部であることを確認し、そのため彼らは、フローごとの状態を維持するために、パケット到着PCN入ノード警察。 PCN-インテリア・ノードメーターすべてのPCN-トラフィック、ひいては任意のフローごとの状態を維持する必要はありません。フローアドミッション及び終了に関する決定はPCN-境界ノードの特定の組のために作られ、したがってPCN-出口・ノードは、各PCNパケットを送信したPCN-入口ノードを識別することができなければなりません。
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.
このセクションでは、一つのドメイン内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.
PCNトラフィックのレートが最初に設定レート、PCN-閾値速度よりも大きい場合、すべてのPCN-パケットをマーク閾値計とマーカー、O。アドミッション制御機構は、*大体に各リンク上の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.
マークされた量が第2設定されたレート、PCN過剰率を超えるトラフィックレートと等しくなるようにPCN-パケットの割合をマーク過剰トラフィックメータとマーカー、O。フロー終了機構は、*略*そのPCN過剰率に各リンク上PCNトラフィックを制限します。
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マーキングの二つの形態は、ドメイン用に構成されている既知の値にECNとDSCP（差別化サービスコードポイント[RFC2474]）フィールドを設定することによって示されています。したがって、PCN-出口-ノードはプレ輻輳の重大度を測定するために、PCN-マーキングを監視することができます。また、PCN入ノードがマークされていないPCNパケットのために構成さとECNとDSCPフィールドを設定する必要があり、PCN-出口-ノードは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]で定義された「IntServの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 PATHメッセージを送信します。通常のホップバイホップイントサーブ[RFC1633]（我々が正常に仮定）PCN-ドメイン外に使用されています。 PATHメッセージはPCNドメインを横切って移動します。 PCN-出口ノードは、このフローのための特定のPCN-入口ノードを発見するPHOP（前のRSVPホップ）オブジェクトを読み出します。 RESVメッセージは、バック受信機からの移動、及び関連するPCN-入口ノードからPCN-トラフィックの割合を確認するPCN-出口ノードが現在しきい値マークされるトリガー。これは、RESVメッセージにこの情報を使用してオブジェクトを追加し、ひいてはPCN-入口ノードは、経路上のプレ輻輳のレベルについて学習します。このレベルがある閾値を下回っている場合には、PCN入ノードは、PCN-ドメインに新しい流れを認めています。それができるように、それは続いて以前に認めPCNフローの一部であるデータパケット、およびトラフィックプロファイルを識別できるように5タプル情報：RSVPメッセージは、2つの通常のIntServ項目をインストールするPCN-入口ノードをトリガその予約内への流れを取り締まります。同様に、RSVPメッセージは、特定のPCN-入口ノードからのフローの一部としてパケットを識別できるように、5タプルとPHOP情報をインストールするPCN-出口ノードをトリガします。
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-出口ノードがそのようなパケットを観察する場合、この例では、それは、次に、いくつかの確率で、このPCNフローを終了します。確率は十分な流れの迅速な終了を確実にするために、終了し、十分に高い上避けるために十分に低く設定されています。それが終了し、フロー上の任意のさらなるトラフィックをブロックすることができるようにそれはまた、関連するPCN入ノードに通知します。
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は、特定のシナリオでは、それが適切なようになりますいくつかの利点と欠点があります。例えば、ホップバイホップのIntServ [RFC1633]と比較して、PCNのみPCN入ノードにおけるフローごとの状態を必要とします。 DiffServアーキテクチャ[RFC2475]と比較して、オペレータは、トラフィック行列のその予測にそれほど正確で及び/又は保守的である必要があります。 DiffServアーキテクチャのトラフィックコンディショニング協定は、静的および粗いです。彼らは、加入時に定義されているにかかわらず、トラフィックのための出力の、ドメインの各入口での合計トラフィックを制限するために（例えば、）が使用されます。一方、PCNは、まず、PCN-境界ノードの固有の対の間の現在の状態の測定値に基づいてアドミッション制御を使用し、そして第二に、災害時に、PCNは、いくつかの選択されたものを終了する最もフローのQoSを保護します。
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-マークされた）を標準化し（閾値）過剰トラフィック・マーク、またはPCN-マークされていない、-marked、例えば、[Moncaster09-2]を参照してください。 （[Westberg08]で提案されているように、さらに符号化状態が存在してもよい。）セクション3.6 ECNとPCN符号化の下位互換性を考慮しています。
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境界ノードの動作：PCN-境界ノードはフローアドミッションの決定にPCN-マーキングを変換して、このような[Charny07-2] [Taylor09]となどの情報の文書に記載されているように、終端を流れ方法。概念は、PCN-ノードによって標準化された計量及びマーキングは、いくつかの可能PCN境界ノードの動作を可能にすることです。可能性の数は、この文書に概説されています。詳細な説明との比較は[Menth09-2] [Charny07-1]にしています。
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.
シグナリングは、PCN-境界ノードの対の間に、上記の例では、これは、トラフィックの割合である（PCN-境界ノード間のPCN-フィードバック情報を転送するために必要とされる、こと：PCN-境界ノード間シグナリングO 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.
正確な要件が異なるPCN境界ノードの動作のために、異なるシグナリングプロトコルのために変化し、したがってこれらの文献に記載されるべきである：PCN-境界ノードは許可されたフロー識別情報を知るそれによってインターフェースO。それらは、上記の例で説明したものと同様であろう - PCN-入口ノードは、パケットが（典型的には、その5タプルから）以前に認めフローの一部と各PCN境界ノードであることを識別できる必要がありますフローに対する他の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.
PCN-ドメインO：PCN可能なドメイン; Diffservのスケジューリング[RFC2474]を実行PCN対応ノードの隣接セット。原則的に、PCN-マーキングパケットを通じて、PCN-ドメインのためのフローアドミッションおよび終了に関する意思決定に影響を与えることができるPCN-ノードの完全なセット。これらPCNマークを測定PCN-出口・ノード、およびPCN入ノードを含みます。
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.
PCN境界ノードO：別のPCNドメインまたは非PCNドメインのいずれかでノード1つのPCNドメインを接続PCNノード。
o PCN-interior-node: a node in a PCN-domain that is not a PCN-boundary-node.
O PCN-内部ノード：PCN-境界ノードではありませんPCN-ドメイン内のノード。
o PCN-node: a PCN-boundary-node or a PCN-interior-node.
O PCNノード：PCN境界ノード又はPCN-内部ノード。
o PCN-egress-node: a PCN-boundary-node in its role in handling traffic as it leaves a PCN-domain.
PCN-出口ノードO：PCN-境界ノードのトラフィックを処理する際の役割で、それはPCN-ドメインを離れると。
o PCN-ingress-node: a PCN-boundary-node in its role in handling traffic as it enters a PCN-domain.
PCN入ノードO：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トラフィック、PCN-パケット、PCN-BA：PCN-ドメインは別のDiffserv挙動凝集（BAS）[RFC2474]のトラフィックを運びます。 PCN-BAはPCNトラフィックを運ぶためにPCNメカニズムを使用し、対応するパケットは、PCN-パケットです。同じネットワークは、他のDiffservのBAのトラフィックを伝送します。 PCN-BAはDiffservのコードポイント（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フロー：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はマーキングを実行するように、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マーキング：プレ輻輳に反応して、定義されたルールに基づいて、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-閾値速度：PCNドメイン内の各リンクのために構成されており、PCN過剰率よりも低い閾値メートルの基準速度。
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を超える量に等しいです。 -excessレート。
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過剰率：過剰トラフィックメートルの基準速度、PCN-閾値速度以上であるPCNドメインとの各リンク用に構成されています。
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-入口ノードによって実行されます。ヘッダはPCNドメインを越えたノードに対して適切であるように、PCN-出口ノードによって行わ。
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乗降凝集：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-フィードバック情報：フローアドミッションのために必要と終了メカニズムをフローでPCN-入口ノード（または中央制御ノード）にPCN-出口ノードによって通知情報。
o PCN-admissible-rate: the rate of PCN-traffic on a link up to which PCN admission control should accept new PCN-flows.
PCN-許容レートO：PCNアドミッション制御は新しいPCN-フローを受け入れるべきまでのリンク上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.
PCN-サポート可能レート（O）に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).
プレ輻輳の自分の状態を監視し、必要に応じてPCN-パケットをマークPCNドメイン「内部」PCN-インテリア・ノード、O。彼らは認識流れていない、また彼らは、入口・出口凝集体を認識しています。機能はまた、それらの発信インターフェイス（すなわち、これらの「内部」PCNドメイン）のためのPCN入ノードによって行われます。
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.
PCN-内部-ノードからの情報に基づいて、新たなPCN-フローおよび既存のPCN-フローの終了の承認を制御PCNドメインのエッジでPCN-境界ノード、O。この情報は、（PCN-出口・ノードによって傍受される）PCN-マークされたデータパケットの形式であり、シグナリングメッセージでありません。一般的に、PCN入ノードは、フロー認識しています。
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-パケットに関連付けられたフロー情報を気に、も行わないことを意味し-aggregatesトラバース。
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：PCNノードメーターその送信（または受信）リンクの各々にPCNトラフィックの量。測定ではなく、フローごとに、全てのPCN-パケットの集合体として構成されています。しきい値計量用と過剰トラフィック計量のための1：2つのアルゴリズムがあります。メーターは、必要に応じて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]).
PCNノードPCNマークPCNパケットDSCPおよびECNフィールドの組み合わせを変更して：符号化（S）O。 【Moncaster09-1】コード「ベースライン」において、ECNフィールドが11に設定され、DSCPは変更されません。拡張エンコーディングは、最大で、（例えば、[Menth08-2]におけるような）（[Moncaster09-2]のように、例えば、）および/または11以外の値にECNフィールドを設定された第2のDSCPを使用する、ことを定義することができます。
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つの符号化状態を用意してもよいです。拡張された符号化三の符号化状態（PCN-マークされていない、閾値マークされ、そして過剰なトラフィック・マーク）を提供することができる一方で、ベースライン符号化は、（PCN-マークされていないとPCN-マーク）は、2つのコードの状態を提供します。
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.
オペレータは、アドミッション制御やフロー終了のいずれか、または両方を展開することもできます。一緒に動作するように設計されていますが、彼らは独立した機構であり、1つの使用は、他の使用を必要とするか、または防ぐことはできません。三つのエンコード状態は当然の流れ入学と終了を流れの両方を可能にします。 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マーキング必要。実際の機能は、PCN-ノードの発信または着信インターフェイス上で設定することができる - または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-パケットをexcess-します、 PCN-過剰率。特定の瞬間に測定率が良く続けることがマーキング、例えばそのレート（だけでなく、詳細なアルゴリズム、その実装、およびトラフィックの分散に依存するので、この説明は、むしろその瞬間の行動よりもアルゴリズムの全体的な意図を反映していることに注意してください最近のオーバーロードした後、瞬時率）が低下した後でさえも。アルゴリズムは[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.
入院時および終了のアプローチが詳細かつ[Menth09-2] [Charny07-1]で、比較されます。以下の議論は、単なる要約です。 3.3節は、利用可能な2つのエンコード状態があると仮定しながら、セクション3.1および3.2には、可能な3つのエンコード状態があると仮定します。
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アーキテクチャのトラフィック・コンディショニング契約なし。 PCNトラフィック（すなわち、削除またはより低いQoSで搬送）透過それを横切って輸送又はPCN-入口ノードでポリシングされますか。一つの違いは、PCNのメカニズムがより良い許可されたフローのQoSを保護するため、PCN-トラフィックが通常のDiffservトラフィックよりも優れたQoS保証を持っていることです。障害が発生したとき、もう1つの違いはまれな状況で発生する可能性があります。一方で、いくつかのPCN-フローが終了しますかもしれないが、一方で、他のフローは、そのQoSが復元されます。非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のQoSを保護するために、将来の新しいフローを認めるか、遮断することにより、そのPCN-許容レート* *おおよそにPCN-ドメイン内の各リンクにPCN-トラフィックを制限することがあります-流れ。 3つのコードの状態が利用可能で、PCN-閾値レートは、各リンク上の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):
正確にアドミッション制御の決定がなされているか情報提供文書で個別に定義されます。この文書では、二つのアプローチ（他は可能かもしれないが）について説明します。
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".
PCN-出口ノード対策Oしきい値マークさ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-出口ノードは、PCNトラフィックを監視し、1つ（またはいくつかの）閾値マーキングされたパケットを受信した場合、その後、新たな流れが遮断されます。そうでない場合は、それが認められています。一つの可能性は、初期フローセットアップパケット（例えば、RSVPのPATH）のマーキング状態に反応することであってもよいです。別の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-境界ノードの特定のペアに対して行われることに留意されたいです。だから、同時に別の入場要求が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過剰率は、各リンク上の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-出口ノードは、実際に支持することができるPCNトラフィックの量が過剰トラフィックマークされていないPCNトラフィックの速度を測定し、PCN-ingress-にこれを通信しますノード。また、PCN入ノードは、この特定のPCN-出口ノード宛の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-フローの一部を終了します。 （このようなすべてのフローが終了した場合は、あまりにも多くのトラフィックが終了されますので、ランダムな選択は、過剰なトラフィック・マークパケット[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-境界ノードの異なる対の間で終端されている一方で、PCN-境界ノードの一組の間で終端するPCNは、フローのためにかなり可能です。
3.3. Flow Admission and/or Flow Termination When There Are Only Two PCN Encoding States
3.3. わずか2つの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-ドメインは、（PCN-マークとPCN-マークされていない）利用できる2つだけエンコードの状態を持っている場合、すなわち、それはベースラインのエンコーディングを使用している[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過剰率）、PCN-許容レートに等しく設定されている[Charny07-2]この場合もトリガすることができる方法の両方アドミッション制御及び終端を流れについて説明しこのアプローチのいくつかの長所と短所を示します。主な欠点は、アドミッション制御はあまり正確であることです。
== 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：方法PCNアドミッション制御の概略と終了メカニズムを流れは、2つの状態をコードし、[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ノードからプリ渋滞情報の転送は、データパケットヘッダでPCN-マーキングを介して行われ、すなわち、「インバンド」。何のシグナリングプロトコルメッセージは必要ありません。シグナリングは、PCN-フィードバック情報を転送するために必要とされている - 例えば、関連するPCN入ノードにPCN-出口ノードからPCN-マークされたトラフィックの割合を伝えるために。正確にどのような情報はでき境界メカニズムについての将来の文書に記載される輸送する必要があります。シグナリングは、例えば、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-トラフィックとのリンクを共有し、その転送帯域幅に対して競合するトラフィックを意味します。 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);
PCN（おそらく特定のアプリケーションまたはオペレータの制御メッセージ）を介してスケジュール優先で1トラフィック。
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).
PCNと同じ優先順位でスケジューリングされる2トラフィック（ボイス-認めるコードポイントが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).
こうした競合する非PCN-トラフィックがある場合は、O、その後、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 PCN-ノードは、代替のECN意味論を使用するPCNトラフィックを区別できるようにDSCPを使用します。
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.
ECN対応の場合は、O、適切な行動を取る、非PCN-トラフィックがPCNが使用するDSCPとPCN入ノードに到着します。
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ドメインに入るのPCNと同じDSCPを使用ECN-可能なトラフィックをブロックすることです。 「ブロッキング」が削除またはPCN-ドメインを介してトンネルすることができる優先度の低い動作集合体、あるいはそのようなトラフィックにダウングレードされています。 「適切な措置」が必要であることの理由は、PCN-出口ノード00にECNフィールドをクリアしていることです。
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-ドメインの新しい機能アーキテクチャの体系的な要約を提供することを意図しています。まず、それはPCN-ノードの3つの特定の種類に必要な機能について説明します。これらは、データプレーン機能であり、PCN-ノードの通常のルータ機能に加えています。そして、フローアドミッション制御およびフロー終了の両方のために必要な更なる機能を説明します。これらは、シグナリングおよび意思決定機能、及び機能が物理的に配置されている場所のための様々な可能性が存在しています。セクションはに分割されています。
Note: Probing is covered in the Appendix.
注意：プロービングは、付録で覆われています。
The section then discusses some other detailed topics:
セクションでは、その後、他のいくつかの詳細なトピックについて説明します。
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.
PCNメートルO - "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.
PCNマークO - 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-内部ノードの機能の概略図。
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ドメインの各入力リンクは、以下の機能で構成されている：パケット分類○ - 着信パケットがフィルタ仕様を使用して、以前に認めフローの一部であるかどうかを決定する（例えば、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-フローは、優先順位の低い行動の集計にブロックされるか、または入院することができます。）同様に、以前に入院流れの一部である警察のパケットは、フローが合意されたレートまたはフロースペック（例えばに維持していることを確認するには、マイクロそのNSIS相当）については[RFC1633]を参照。
o PCN-colour - set the DSCP and ECN fields appropriately for the PCN-domain, for example, as in [Moncaster09-1].
O PCN色 - [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-出口ノードに向かってPCNトラフィックの（集約）速度を測定するために、PCN-入口ノードを必要とします。
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.
最初の二つはPCN-ドメインに入院PCN-パケットが入院されていて、フローはフロースペックが合意に保つことを保証するために、流れに属していることを確認するために必要なポリシング機能、（例えば、合意された最大値を超えていません率と非弾性トラフィックです）。フィルタを再インストールされますように、フィルタ仕様をインストールは、典型的には、例えば、PCN-入口ノードを変更し、再ルート後（RSVPを使用して、例えば[Briscoe06]参照）、シグナリングプロトコルによって行われます。 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パケットが分類 - PCNパケットから来たPCN-入口ノード決定します。
o Meter - "measure PCN-traffic" or "monitor PCN-marks".
メーターO - "PCN-トラフィックを測定" または "PCN-マークを監視します"。
o PCN-colour - for PCN-packets, set the DSCP and ECN fields to the appropriate values for use outside the PCN-domain.
O PCN-色 - PCN-パケットに対して、PCNドメイン外の使用のために適切な値にDSCPとECNフィールドを設定します。
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-パケットが特定のPCN-入口ノードから、（すなわち、しないフローごと）骨材として、「測定」PCN-出口ノードを含む、またはPCNトラフィックを「監視」と一つに反応する（またはいくつかの）PCN-は、パケットをマーク。 PCN-着色のために、[Moncaster09-1] PCN-出口ノード00にECNフィールドをリセットすることを指定します。他のエンコーディングは異なる動作を定義することがあります。
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].
PCN-出口ノードのメーター機能の出力に基づいて - O入場についての決定を行います。この「測定PCNトラフィック」、乗降用凝集で測定トラフィックがある基準レベルと比較した場合には。それは、「PCN-マークを監視」の場合には、決定か否かが1つ（または複数の）に基づいてパケットが（例えば、RSVP PATHメッセージ）PCN-マークされています。いずれの場合も、入場料の決定は、ポリシーとアプリケーション層の要件[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-ドメイン外であってもよい）アドミッション制御要求を行うノードの決定を知らせます。
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-出口ノードで行われ、決定は、（認める又はブロック）PCN-入口ノードに通知されます。
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-出口ノード（認めるまたはブロック）によって推奨されるが、決定は決定的PCN-入口ノードによって行われます。理論的根拠は、PCN-入口ノードは、着信トラフィックをポリシングポリシー施行ポイント[RFC2753]であるのに対し、PCN-出口ノードは、天然、入口 - 出口凝集にPCNマークの量に関する必要な情報を有することですそれは認めPCN-フローの一部であることを確認してください。
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入ノードにおいて行われるPCN-入口ノードへPCN-出口ノード信号はPCN-フィードバック情報という。例えば、それは、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-出口ノードにおけるPCNメートル - 同様に入場を流れるように、可能性の2種類がある：乗降凝集体の「PCN-トラフィックを測定する」、又は「PCNマークをモニタ」と一つに反応します（または複数）PCNマーク。
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.
PCN-入口ノードにおけるPCNメートルを（必要な場合）O - 特にPCN-出口ノードに向けて送信される「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.
例えば、[Briscoe06]のように、PCN-入口ノードにPCN-出口ノードの測定値を伝える - O（必要な場合）、フロー終了判定を行うノードにPCN-フィードバック情報を通信します。
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-フローが終了するかを決定するためにPCNメートル（S）からの情報を使用します。決定は、ポリシーとアプリケーション層の要件[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-ドメイン外であってもよい）、フローを終了することができるノードの決定を知らせます。
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-インテリア・ノードは（ルーティング目的のためにそのネクストホップネイバーを除く）他の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-出口ノードは、PCN-入口ノードは、アドミッション決定（及び任意のフロー終了判定）を通知することができるように、フローに関連付けられたPCN-入口ノードのアドレスを知っていて、強制する必要がありますそれポリシングによる。 PCN-出口ノードが正しい乗降用骨材に受信したパケットを関連付ける、すなわち、これを行うことができる方法のための様々な可能性があります。特定のメカニズムを強制するには、このドキュメントの意図ではありません。
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.
PCN-入口ノードは、前のRSVPホップ（PHOP）（[Lefaucheur06]）であるように、例えば、RSVP PATHメッセージの定期的な処理を介して - ○アドレッシング情報は、シグナリングから収集することができます。別のオプションは、PCN入ノードがPCN-出口ノードにそのアドレスを知らせることができることです。
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).
PCN-ドメイン全体でO、必ずトンネルPCNトラフィック。次いで、PCN-入口ノードのアドレスは単に外側のパケットヘッダの送信元アドレスです。 PCN-入口ノードは、手動設定によって、または自動トンネルエンドポイントディスカバリメカニズムの一つ（例えばシグナリングまたはデータ経路上プロービング、ルーティングに問い合わせ、または使用するなどのいずれかによって、PCN-出口ノードのアドレスを学習する必要があります集中型のブローカー）。
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、IP上のMPLS）。 PCNはマーキング潜在的にPCNのフローアドミッション制御と終了に影響を与えることができる任意のパケットであることが重要である - パケットがPCN-ノードでトンネル化することを起こるかどうかは関係ないはずそのPCN-マークパケット、または実際にそれはですかデカプセル化または後続PCNノードによってカプセル化。これは、[RFC2983]に記載された「均一な概念モデルは、」PCNコンテキストに再適用されるべきであることを示唆しています。カプセル化はPCNドメイン内で行われた場合、これと[RFC4303]と[Briscoe09]のアプローチの両方に沿って、以下のルールが適用されます。
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:
デカプセル化がPCNドメイン内で行われた場合、同様にして、[RFC4301]と[RFC3168]の「フル機能のオプション」と[RFC2983]の「均一な概念モデル」に沿って、以下のルールが適用されます。
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-出口・ノードにPCN入ノードからトンネルPCN-トラフィックを望むかもしれません。 PCN-マークは、他のすべての（PCNとトンネリング）関数後PCN-出口ノードPCN-着色機能を行う（第4.3節）によって達成することができるPCNドメイン、外部表示されてはなりません。そのようなトンネリングを行うための潜在的な理由は以下のとおりです。ECMP（イコールコストマルチパス）が実行されている場合でも、PCN-出口ノードは自動的に、フローに関連するPCN入ノードのアドレスを知っている、そして、すべての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. 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-出口ノードを導く可能性があります。
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コードポイントは、デカプセル化を存続し、従ってベースライン符号化は、PCNマーキングを示すために11のコードポイントを使用します。拡張符号化方式は、トンネリング（約または仮定）との相互作用を説明する必要があります。 （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-内部ノード（またはそのリンクのいずれか）が失敗した場合、下層の保護メカニズムまたは通常の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-出口ノードで、「報告しきい値は、」どのくらいの頻度を監視するように設定することができ - とどのくらいのために - システムは、実際にはそうせずに流れブロッキングをトリガーに近づきます。同様に、マーキングフロー終了のバーストは、それらが十分に流れ終了をトリガするために持続されていない場合でも記録することができます。このような統計は、サービス低下を引き起こす危険にリソースをアップグレードするか、そうでなければ見過ごされていた断続的な初期エラーのマニュアルトレースをトリガするために、ボリューム（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.
閾値計量及び-markingと過剰トラフィック計量及び-markingは[Eardley09]で標準化されています。しかし、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).
一つの可能性は、すべての設定変数が各ノード上で定義された管理情報ベース（MIB）内に構成され、SNMP（簡易ネットワーク管理プロトコル）管理フレームワーク[RFC3411]内で座っていることであり、好適に安全な管理プロトコルを介して遠隔読み取り可能及び設定可能です（例えば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-ドメインを制御するために、一度設定する必要があります。可能であれば、これらは以下に特定されています。これは、運用上の複雑さと異なるベンダーの機器間の相互運用性の問題の可能性に影響を与える可能性があります。
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-インテリア・ノードで非常に少数のシステムの選択肢があるでしょう。
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-マーキング（しきい値-マークされ、過剰トラフィック-マーク）が有効になっているか、一つだけ。典型的には、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つのみPCNマーキングが有効になっている場合には、すべてのノードが同じメートル（すなわち、閾値計または過剰トラフィックメータのいずれか）からPCN-マークを生成するように構成されなければなりません。
PCN-boundary-nodes (ingress and egress) will have more system options:
PCN-境界ノード（入力および出力）は、より多くのシステムオプションがあります：
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入場およびフロー終了のどちらが有効になっています。任意PCN-内部ノードは、マーキングを生成するように構成されている場合、すべてのPCN-境界ノードは、それらがあるかどうか、PCNマーキングの一種類のみを使用しPCNドメインで、理解を含む（マーキングと解釈することができなければなりませんPCN-内部-ノードの閾値メートルまたはそれら過剰トラフィックメーター）によって生成されました。したがって、全ての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入ノードにおいて又はPCN-出口・ノードに（又は集中ノードで、付録を参照されたいです）。理論的には、この構成の選択は、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-出口-ノードは、さらに、システムのオプションがあります：
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（S）で構成する必要があります。各内部リンク上で、主な構成パラメータは、PCN-閾値速度およびPCN過剰率です。大きいPCN-閾値速度よりPCN-トラフィックしたがって稼働率を向上させること、リンク上で入院することを可能にします。任意のフローが終了される前に、さらにPCN-閾値速度以上に設定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の最初の展開にこれらのレートを設定すると、入場制御ネットワークのサイジングに依存するために、従来のプロセスに非常によく似ていますその統計的特性（トラフィック行列）、再ルーティング単一または複数の障害が発生した場合でPCN-トラフィック行列、及びリンク容量[Menth09-1]に対して他のクラスからの予想される負荷のために偶発。一度ドメインが動作している。しかし、PCN設計目標は、（パフォーマンスとプロビジョニングのセクション5.4を参照）、実際のではなく、予想されるトラフィックからPCN-マーキング速度を監視することで、はるかに簡単にこれらの構成された速度で成長を決定することができることです。
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-超過レートを超えたが、後に、いくつかの演算子は任意の短い期間の間、他のトラフィッククラスの飢餓を防ぐために、論理的な制限を設定することを望むかもしれません割合。
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-出口ノードは、構成を可能にすることができます。
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.
一つの特定のアプローチは、[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-閾値率が高く、ローウォーターマークに置き換えられマーキングアルゴリズムが自動的に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-出口ノードにやっノードの両方）アラームを発生させる必要がありますマーキング。同様に、永続的に貧しい外部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入ノードで拒否パケットを非準拠の異常パターンが（例えば、すでにPCN対応やトラフィックをマークされたパケットは、永続的にトークンバケットポリサーを飢え）。
o PCN-capable packets arriving at a PCN-egress-node with no associated state for mapping them to a valid ingress-egress-aggregate.
有効乗降凝集にそれらをマッピングするための関連した状態でPCN-出口ノードに到達PCN可能なパケットO。
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-入口ノード、等。）。
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-出口ノードに到達マーキング。
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入ノード（「ステートレスコア」）に必要とされます。これは、ように（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の違反が増加交通量[Iyer03]によるQoSの違反よりも可能性があり、これは、重要な機能です。
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-出口-ノードにシグナリングされます。追加のシグナリングプロトコルは、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-出口・ノードは、すなわちないフローごとに、各PCN-入口ノードから集約PCNトラフィック上で動作する、別個の測定を行います。同様に、（フローアドミッション及び終了の決定のために使用される）PCN-フィードバック情報のPCN-出口ノードによってシグナリング乗降凝集体の粒度です。別のアプローチは、1つ（または少数）の粒度でPCN-マーク（フローアドミッション及び終了の決定のために使用される）PCN-出口-ノードはPCN-フィードバック情報を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終了メカニズムは、アドミッション制御を補完します。したがって、残りのフローにQoSを復元、ネットワークはいくつかのリンクをPCN-トラフィックの突然の予期せぬサージから回復することができます。このようなシナリオはまれではあるが、不可能ではないことが予想されます。彼らは、異常に低い率でしばらくの間、送信許可されたフローの存在下で、他のリンクに入院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障害に対するトラフィックを保護することは、障害の前にいくつかのリンク[Charny08]上のリンク帯域幅の使用率が低い（〜10％）が必要です。
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.
PCN-サポート可能なレートは、PCNトラフィックが発生し、またはそれにPCN-パケットの損失（又は過度の遅延）の前に、いくつかのPCN-フローの終了をトリガするためにリンク上で送信できる最大レート以下に設定することができるoをオペレータによって設定されたレベル以下のリンクを最大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.
ネットワークのオペレータは、どのような彼らの特定の目標や（すべての後に、ユーザーがQoSエンドツーエンドを懸念している）例えば、それらがどのようにPCN-ドメイン外のアドミッション制御を実行している上、応じて様々なアレンジで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つのエンコードの状態を有することができる（またはpedantically、オペレータは、PCNのための3つのエンコード状態を使用することもできます）：、PCN-マークされていないしきい値-マーク、および過剰トラフィックが-マーク。この方法では、PCNアドミッション制御と終了フローの両方をサポートすることができます。図1に示すように、必要に応じて、フロー終了機構がオンPCN過剰率に流下を終了し、一方ボトルネックリンク上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-ドメイン（[Moncaster09-1]におけるような）は、2つのコードの状態を有していてもよい（又はpedantically、オペレータは、PCNのための2つのコードの状態を使用することを選択することができる）：PCN-マーク及びPCN-マークされていません。以下の段落で説明したようにこのように、三つの可能性がある（セクション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のアドミッション制御を使用することができます - セッションの終わりとして、PCN-トラフィックが自然に減少し;一方、アドミッション制御メカニズムは、影響を受けたリンクを使用し、新たなフローの入場を防ぐことができます。だから、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.
【Kumar01] DiffServアーキテクチャのホースモデルにおいて典型的であるように、第2、オペレータは単にアドミッション制御のためPCN-入口ノード（かかわらず、流れのPCN-出口ノードの）当たりの静的プロビジョニング能力に頼ることができます。このようなトラフィック・コンディショニング協定は、集束過負荷につながることができます：多くのフローが特定のリンクに焦点を当ててしまった後、混雑リンクを介してすべてのフローが破滅的に失敗します。 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入ノードによってフローごとのポリシングによって強制する必要があります。そのPCN入ノードでの警察へのいくつかのPCN-ドメインは、エンドツーエンドのパス上に存在する場合、それぞれのニーズ。オペレータは、アクセスネットワーク（PCNないドメイン）とコアネットワーク（PCNドメイン）の両方を実行する場合は、1つの例外があります。フローごとのポリシングは、アクセスネットワークに委譲することができ、PCN入ノードで行われていません。読みやすさを支援するために、なお、本文書の残りの部分は、ポリシングはPCN入ノードによって行われることを前提としています。
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ドメインはDiffservの上のIntServ [RFC2998]のように、PCN-ドメイン外の各ホップで処理RSVPメッセージで単一RSVPホップ、すなわち、唯一PCN-境界ノード処理RSVPメッセージです。それはまた、発信および/またはエンドユーザとプロキシ（例えば、ホーム・ハブとSIPシグナリング）の間のアプリケーション層シグナリングを用いて、プロキシによって終了するRSVPシグナリングのために可能であろう。同様の例は、NSIS（シグナリングにおける次のステップ）の代わりにRSVPの[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-ドメイン[Sarker08]外ECNマーキングに反応したいということも可能です。 ECNマークがPCNドメインを横切って透過的に実行される、または[Moncaster09-2]のような符号化を使用するようにこれを行うには2つの可能な方法は、トンネルにPCNドメイン全体のすべてのPCN-パケットです。トンネリングは、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-フローの数は、ステートレス、統計的メカニズムが有効であることが十分に大きいです。別の言い方をすると、任意の潜在的なボトルネックリンクを介しPCN-トラフィックの総ビットレートが一つのフローによって追加最大追加ビットレートに比べて、十分に大きくする必要があります。これは、測定ベースのアドミッション制御の基本的な前提です。
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-フローが異なる優先順位を持つかもしれないが、非常用PCNメカニズムの適用外れる（911は、（政府の電気通信サービス）、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-フローのQoSを劣化させるアドミッション制御、を受けることなくPCN-BAを入力することができます。
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-マーキング、それは潜在的に入院されている（または少なすぎるが終了している）、あまりにも多くの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点が有効である保証する一つの方法は、単一のオペレータによって実行全体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).
ソース・ビット・レートの任意の変形は、プレ輻輳のレベルとは無関係であると仮定されます。我々は関係なく、能力[RFC4594]の可用性の、コーデックは、それらを生成レートでパケットを送信する、すなわち、PCN-パケットは非弾性トラフィックを生成するリアルタイムアプリケーションから来ていることを前提としています。このようなリアルタイムアプリケーションの例としては、低遅延、ジッタ、パケット損失、制御されたロード・サービス[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-ドメイン内の任意のボトルネックリンク上のPCN-フロー（またはが存在すると仮定されます1 PCN-流によって付加ビットレート）。測定ベースのアドミッション制御は、現在、将来の妥当な予測であることを前提としていますネットワークの状態は、新しいフロー要求時に測定されるが、実際のネットワークのパフォーマンスは、いくつかの時間後、通話中に許容されなければなりません。 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-フローは、異なる優先順位を有することができるが、緊急用PCN機構の適用この文書の範囲外である（911は、WPS等MLPPは、GETS）。
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-出口ノードによって測定プレ輻輳レベルが十分に新しいフローが許可される非輻輳パスからマークされていないパケットによって希釈されるので）、新しいフローが許可されるが、そのパケットが通って移動前の混雑PCNノード。
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-出口ノードによって測定プレ輻輳レベルが十分に新しいフローが遮断される前輻輳パスから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.無効終了：フローが終了されるが、そのパスが（前）混雑ルータ（複数可）を通って移動していません。フロー終了が過入場起こるべきネットワークを保護し、「最後の」は、あるので、この問題は他の二つよりも解決するために、おそらくより重要です。
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ドメインで唯一のトンネルエンドポイントとシナリオ：そのようなシナリオは、それが困難PCN-出口ノードは、シグナリングメッセージ（例えば、RSVP、NSIS）からPCN-入口ノードのIDを収集するために作ることができます。
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の範囲外の問題です。一つの可能な例は、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.
グローバルコーディネーション○：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-マークが新しい流れを遮断するように見られる前に、例えば、入場要求の大きなバーストが潜在的に（televoteによって促さ例えば、）時間の非常に短いスペースで発生した場合、それらはすべて認めますがあります。換言すれば、機構の反応時間内で提供される任意の追加の負荷が過負荷にない輻輳状態から直接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-マーキングのために信頼されていること、すなわち、信託仮定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.
PCN-境界ノードはフローを意識しているため、O、彼らは正確にその意識を使用するために信頼されています。必要な信頼度は、彼らが行う必要があり意思決定の種類と、彼らはそれらを作るために必要な情報の種類に依存します。 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.
PCN入ノード警察パケットoを合意された限度内でPCN-流れスティックを確保するため、および入院されている唯一のPCN-フローはPCN-ドメインにPCN-トラフィックに貢献することを確実にするために。ポリサーは、任意のPCN-パケットはこの送金外にあるその受信ドロップ（または恐らく異なるDSCPにダウングレード）しなければなりません。これは、既存のIntServの動作に似ています。それらの間で、PCN-境界ノードは、PCN-ドメインを囲む必要があります。それ以外の場合は、PCN-パケットは、潜在的に既存のフローのQoSを破壊するアドミッション制御、を受けることなく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-インテリア・ノードは、流れを意識していません。例えば、DoS攻撃や盗聴のために - これは、攻撃者は、データプレーン内の特定のフローを対象に、いくつかのセキュリティ攻撃を防ぐことができます。
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.
PCN-境界ノードが正しいPCNマーキングPCN-内部-ノードによるに依存して、O。例えば、不正PCN-内部ノードは、PCNマークができない流れが許可されなかったように、すべてのパケットを。別の可能性は、それが事前に混雑している場合でも、すべてのパケットをマークにPCNないということです。より微妙に、不正なPCN-内部ノードは、特定のフローに選択的にこれらの攻撃を実行することができ、またはそれは、全体の正確な割合をマークし、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-境界ノード間のシグナリングは、攻撃から保護されなければなりません。例えば、受信者は、メッセージがそれを送信したと主張するノードから実際にあることを検証する必要があります。可能性のある措置がリプレイやman-in-the-middle攻撃に対する認証と保護をダイジェスト含まれています。具体的には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. Eardley、J. Babiarz、K.チャン、A. Charny、R. Geib、G. Karagiannis、M. Menth、及び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,
このドキュメントに関するコメント作られた人たちへの感謝：ラクランアンドリュー、ジョーBabiarz、フレッド・ベイカー、デビッド・ブラック、スティーブ・ブレイクを、ロンBonica、スコット・ブラッドナー、ボブ・ブリスコー、ロスCallon、ジェイソンキヤノン、ケン・カールバーグ、アンナCharny、ヨアヒムCharzinski、アンドラーシュCsaszar、フランシスデュポン、ラースEggertの、パシEronen、エードリアンファレル、Ruediger Geib、魏Gengyu、ロバート・ハンコック、フォーチュン黄、クリスチャンHublet、カレン・ジェニングス、インゲマル・ヨハンソン、ゲオルギオスKaragiannis、ハインMekkes、マイケルMenth、トビーMoncaster、ディミトリPapadimitriou 、ダンRomascanu、大輔佐藤、ベンStrulo、トム・テイラー、ハンネスTschofenig、ティナツオウ、
David Ward, Lars Westberg, Magnus Westerlund, and Delei Yu. Thanks to Bob Briscoe who extensively revised the Operations and Management section.
デビッド・ウォード、ラースWestberg、マグヌスウェスター、およびDeleiゆいます。広範囲に運用・管理のセクションを改訂ボブ・ブリスコーに感謝します。
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.ブリスコウ、P. Eardley、D. Songhurst、F.ルFaucheur、A. Charny、J. Babiarz、K.チャン、S.ダドリー、G. Karagiannis、A.ベイダー、L. Westberg、J 。張、V. Liatsos、XG。劉、およびA.バルガヴァ。
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].
アドミッション制御メカニズムは、順番にGibbensとケリー[Gibbens99]の理論的研究に基づいていたM3Iプロジェクト[Karsten02] [M3I]、で開発された保証ストリームのプロバイダーにマーティン・カルステン率いる仕事から進化しました。
[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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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.、Charny、A.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、 "緊急転送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]ブレーデン、B.、クラーク、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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、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.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、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.、フォード、P.、Yavatkar、R.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、およびE 。Felstaine、 "Diffservのネットワーク経由の統合サービス操作のための枠組み"、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.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、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]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（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]デミチェリス、C.およびP. Chimento、 "IPパフォーマンス・メトリックのためのIPパケット遅延変動メトリック（IPPM）"、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]ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]ブルナー、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]チャン、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]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（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.、チャン、K.、およびF.ベイカー、 "DiffServのサービスクラスの設定時の注意事項"、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.、カープ、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]フロイド、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]デイビー、B.、ブリスコー、B.、およびJ.テイ、 "MPLSマーキング明示的輻輳"、RFC 5129、2008年1月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]アンデション、L.およびR. Asatiは、 "マルチプロトコルラベルスイッチング（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]、ITU-T勧告Y. 1541、2006年2月 "IPベースのサービスのためのネットワークのパフォーマンス目標を"。
[Babiarz06] Babiarz, J., Chan, K., Karagiannis, G., and P. Eardley, "SIP Controlled Admission and Preemption", Work in Progress, October 2006.
[Babiarz06] Babiarz、J.、チャン、K.、Karagiannis、G.、およびP. Eardley、 "SIP制御入学とプリエンプション"、進歩、2006年10月に作業。
[Behringer09] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, March 2009.
[Behringer09]ベリンガー、M.とF.ル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】ブリスコー、B.、Eardley、P.、Songhurst、D.、ルFaucheur、F.、Charny、A.、Babiarz、J.、チャン、K.、ダドリー、S.、Karagiannis、G.、ベイダー、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]ブリスコー、B.、「バルクデータに再PCNを使用してエミュレートボーダー・フローポリシング」、進歩、2008年9月の作業。
[Briscoe09] Briscoe, B., "Tunnelling of Explicit Congestion Notification", Work in Progress, March 2009.
[Briscoe09]ブリスコー、B.、「明示的輻輳通知のトンネル」、進歩、2009年3月での作業。
[Bryant08] Bryant, S., Davie, B., Martini, L., and E. Rosen, "Pseudowire Congestion Control Framework", Work in Progress, May 2008.
【Bryant08]ブライアント、S.、デイビー、B.、マルティーニ、L.、およびE.ローゼン、 "疑似回線の輻輳制御フレームワーク"、進歩、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.張、 "提案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.、張、X.、ル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/ウェブ/ PCN /現在/ 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 /現在/ 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/ウェブ/ PCN /現在/ msg00831.html>。
[Eardley09] Eardley, P., "Metering and marking behaviour of PCN-nodes", Work in Progress, May 2009.
[Eardley09] Eardley、P.、 "メーターとPCN-ノードのマーキング行動"、進歩、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.及びF.ケリー、「コネクションレスネットワークにおける分散コネクション受付制御」、プロシーディングス国際トラヒック会議（ITC16）、エジンバラ、頁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]ハンコック、R.とE.ヘップワース、 " 'NSIS：QoSシグナリングのための概要フレームワーク' のスライド14"、2002年5月、<時間TTP：//www-nrc.nokia.com/sua/nsis/interim / NSISフレームワーク-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]アイヤル、S.、バッタチャリヤ、S.、タフト、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]カルステン、M.とJ.シュミット、 "パケットに基づいてアドミッション制御は、シグナリングマーキングとフィードバック - メカニズム、実装と実験"、TU-ダルムシュタット技術レポートTR-KOM-2002-03、2002年5月、<のhttp： //www.kom.e-technik.tu-darmstadt.de/出版/抄録/ 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]クマー、A.、Rastogi、R.、Silberschatz、A.、およびB. Yener、 "ホースモデルで仮想プライベートネットワークのプロビジョニングのためのアルゴリズム"、議事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】ルFaucheur、F.、Charny、A.、ブリスコー、B.、Eardley、P.、Babiarz、J.、およびK.チャン、「プレ輻輳通知を使用して、Diffservの上にアドミッション制御のためのRSVP拡張（PCN） 」、進歩、2006年6月に作業。
[M3I] "M3I - Market Managed Multiservice Internet", <http://www.m3iproject.org/>.
[私と一緒に] "私と一緒に - ソフトMmeltsrvkインターネット・マーケット"、<薪：//oo.mabergkh.arj/>。
[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.、Lehrieder、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] "パケット特有デュアルマーキング（PSDM）用PCNエンコーディング" Menth、M.、Babiarz、J.、Moncaster、T.、およびB.ブリスコウ、進歩、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.ハルトマン、「PCNベースの弾力性のアドミッション制御のためのしきい値の設定とルーティングの最適化」、コンピュータネットワーク、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.、Lehrieder、F.、ブリスコー、B.、Eardley、P.、Moncaster、T.、Babiarz、J.、チャン、K.、Charny、A.、Karagiannis、G.、張、X.、テイラー、T.、佐藤、D.、およびR. Geib、 "PCNベースのアドミッション制御とフロー終端の調査"、IEEEコミュニケーションズ調査とチュートリアル、<のhttp：// www3.informatik.uni -wuerzburg.de/staff/menth/出版/新聞/ 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.、ブリスコー、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.、ブリスコー、B.、およびM. Menth、 "3以上の状態を提供するために、2つのDSCPを使用して、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.ヨハンソン、「ユースケースとPCNドメインでECNサポートをエンドツーエンドの利点」、進歩、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.、ブリスコー、B.、ディカイラーノGilfedder、C.、およびJ.テイは、 "共有容量のアドミッション制御のためのQoSの合成を保証"、BT技術レポートTR-CXR9-2006 -001、2月2006、<http://www.cs.ucl.ac.uk/staff/ B.Briscoe /プロジェクト/ 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.、黄、F.、Menth、M.、およびT.テイラー、 "動作の制御負荷（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]ツオウ、T.、黄、F.、およびT.テイラー、「リソース・制御ネットワークにおける事前輻輳通知の使用のための適用性に関する声明」、進歩、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.、バルガヴァ、A.、ベイダー、A.、Karagiannis、G.、およびH. Mekkes、 "LC-PCN：ロードコントロールPCNソリューション"、進歩、2008年11月での作業。
Appendix A. Possible Future Work Items
付録A.可能な未来の作業項目
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:
可能性の第1のセットは、セクション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-ドメインは互いを信頼していないいくつかの自律システムを包含する。可能な解決策は、再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は、トンネル内で動作していないものの、PCNメカニズムがまだあるため、仮想リンク（トンネル）に良いQoSを正常に動作します。別の例は、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.
非弾性トラフィックを越えて他のタイプのトラフィック、すなわち、にPCNメカニズムを適用するO - 例えば、保証転送ホップ単位動作でスケジュールトラフィックにPCNのメカニズムを適用します。一例では、プレ輻輳情報に応じて適合させる弾性アプリケーションによって流量適応とすることができます。
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.).
緊急用PCN機構の適用O（911、WPS、MLPPなどGETS）。
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-出口ノードは、集中ノードにPCN-フィードバック情報を通知することを必要とし、そのPCN-入口ノードに集中ノード信号アドミッション（または終了）についての決定。そのような可能性は、互いのアドレスを設定する集中ノードと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.
シグナリングプロトコルは認めPCN-フローに対するPCN-入口ノードにおけるフロースペックをインストールする方法、およびシグナリングプロトコルはPCNを担持する方法の例については、詳細 - 特定のプロトコル（例えば、RSVPおよびNSIS）の拡張子をシグナリングO -feedback情報。おそらくまた、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.
PCN-ドメインは上流のネットワークはすでにその代わってトラフィックをポリシングしていることを信頼することができた場合、O PCN入ノードによってポリシングが必要とされないことがあります。
o PCN for Pseudowire. PCN may be used as a congestion avoidance mechanism for edge-to-edge pseudowire emulations [Bryant08].
擬似回線用PCN O。 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).
MPLS用O PCN。 [RFC3270]はMPLS（マルチプロトコルラベルスイッチング）ネットワークでDiffServアーキテクチャをサポートする方法を定義します。 [RFC5129]はMPLS凝集体のセットにマイクロフローのアドミッション制御のためにPCNを追加する方法について説明します。 PCN-マーキングは、（その[RFC5462]再名サービスクラス（CoS）のフィールド）MPLSのEXPフィールドで行われます。
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の任務の外にあります。
A.1. Probing
A.1。プロービング
A.1.1. Introduction
A.1.1。前書き
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-出口ノードが各PCN-入口ノードからのトラフィックのためのプレ輻輳レベルを監視する反応メカニズムです。その入口・出口・集計上のレベルが上昇した場合、それブロックの新しい流れ。しかし、それは、入口・出口-集合体はトラフィックを運ばない、ので、PCN-出口ノードは、前述の通常の方法を使用して入場判断を下すことができない可能性があります。
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.
一つのアプローチは、「楽観的」になることですし、単に新しいフローを認めます。しかし、それは他の進入・退出凝集体上のトラフィックレベルはすでに、彼らは新しいPCN-流れを遮断し、余分な追加されます。この「空」の乗降用骨材上に新しい流れを認めているほど高いシナリオを想定することが可能ですすでに事前に混雑しているリンクへのトラフィック。 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入ノードは、明示的に、入口・出口-集合体はそれをサポートできるかどうか、将来の新しい流れを認める前に、決定します。これは、上記のアプローチの「楽観」とは対照的に、「悲観的」アプローチとして見ることができます。これはプロービング含む：PCN-入口ノードが生成してフローが経験する前輻輳レベルをテストするためにプローブパケットを送信します。
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.
一つの可能性は、プローブパケットは単にダミーデータパケット、PCN-入口ノードによって生成され、PCN-出口ノード宛であることです。
A.1.2. Probing Functions
A.1.2。機能をプロービング
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-流れを認める前に、すなわち、プローブ、常に精査することです。
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-入口ノードへPCN-出口ノード信号。
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入ノードは、プローブのトラフィックを生成します。プローブパケットの適切な数（または割合）は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-内部-ノードが関係しているように、プローブパケットは、ルーティングの観点で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-出口ノードは、彼らがPCN-ドメインを超えて移動しないことを確実にするためにプローブパケットを消費します。
A.1.3. Discussion of Rationale for Probing, Its Downsides and Open Issues
A.1.3。プロービングのための理論的根拠の議論、そのマイナス面および未解決の問題
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.
それは、プロービングが本当に必要かどうかの未解決の問題であるが、二つの視点は、それが有用である理由として提唱されてきました。最初は、おそらく最も明白です：乗降用骨材にはPCN-トラフィックはありません。第二は、マルチパスルーティング（例えば、ECMP）はPCNドメインで実行されていることを前提としています。私たちは今、順番にそれぞれを検討します。
The first viewpoint assumes the following:
第1の視点は、次のことを前提としています。
o There is no PCN-traffic on the ingress-egress-aggregate (so a normal admission decision cannot be made).
O乗降用骨材には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-ドメイン内のリンクをオーバーロード空の進入・退出凝集体の多くに起動する場合、後者の弾丸が発生する可能性があります。問題があるために、これはおそらく、システムの反応時間後、リンクを通過する他の（非空）乗降用凝集体は、事前に測定されます、ので、短時間（フラッシュクラウド）で発生しなければなりません渋滞などの新しい流れを遮断します。また、とにかく終わる自然に流れています。
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:
第二の観点は、PCNドメインにおけるマルチパスルーティング（例えば、ECMP）がある場合に適用されます。 ECMPは、多くの場合、コアネットワーク上で使用されていることに注意してください。二つの可能性があります。
(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.
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]アンバランストラフィックもPCN-リンク上のフローのかなりの数が多い、かなり可能であることを示唆している（例えば、1000年）、仮定3（集約）を満たす可能性があるとき。
(2) If admission control is based on measurements of pre-congestion on specific ECMP paths, then the viewpoint that probing is useful assumes:
アドミッション制御は、特定のECMPパスのプレ輻輳の測定に基づいている場合（2）、次いで、プローブが有用であるという点が想定しています。
* There is no PCN-traffic on the ECMP path on which to base an
admission decision.
* 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-出口ノードは、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).
注：これは、第1の視点に類似しており、新たなフローが空の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).
PCN-出口ノードは、彼らが宛先エンドノードを混乱させる可能性があるため、彼らは、PCN-ドメインを超えて移動しないようにプローブパケットを消費する必要があり、O。プローブパケットは、関連するECMPパス（すなわち、それらは上記第1視点とは異なり、PCN-出口ノードにアドレス指定されていない）をテストするために、宛先エンドノードにアドレス指定されるので、これは、非自明です。
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入ノードは、入学決定を行うのに十分なトラフィックがありますように生成する必要があるのでしょうか？
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-出口ノードによっておそらく入院、またはされるレートを制限することにより、その空でないものは、予め輻輳している場合。
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（第二の視点のみ）データ・パケットからPCN-出口ノード明確にプローブパケットをどのように（それは、前者を消費することができますか）？ PCN-出口ノードは、プローブパケットのヘッダまたは本文中の特定のビットの特性設定と一致している必要があり、これらのビットは、任意のPCN-内部ノードのECMPアルゴリズムによって使用されてはなりません。一般的な場合では、これは不可能であるが、それは（送信元および宛先IPアドレスおよびポート番号、プロトコルIDを調べ、およびDSCP）の典型的なECMPアルゴリズムに可能であるべきです。
Author's Address
著者のアドレス
Philip Eardley (editor) BT B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom
フィリップEardley（エディタ）BT B54 / 77、シリウスハウスAdastral公園Martleshamヒースサフォーク州イプスウィッチIP5 3REイギリス
EMail: philip.eardley@bt.com
メールアドレス：philip.eardley@bt.com