Network Working Group P. Eardley, Ed.
Request for Comments: 5670 BT
Category: Standards Track November 2009
Metering and Marking Behaviour of PCN-Nodes
Abstract
抽象
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. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess-traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows.
前の輻輳通知（PCN）の目的は、簡単でスケーラブル、かつ堅牢なファッションでのDiffservドメイン内の非弾性フローのサービス品質（QoS）を保護することです。この文書は、二つの計量を定義し、PCN-ノードの挙動をマーキング。閾値計量及びPCNトラフィックの速度が設定速度（「PCN-閾値速度」）よりも大きい場合にマークを全てPCN-パケットを-marking。過剰トラフィック計量及び-markingは、マークされた量が設定速度（「PCN-過剰率」）の過剰でPCN-トラフィックの速度に等しくなるように、PCN-パケットの割合をマーク。マーキングのレベルは、PCN-境界ノードが認めるかPCN-フローを終了するか否かについての決定を行うことができます。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................4
1.1.1. Requirements Language ...............................5
2. Specified PCN-Metering and -Marking Behaviours ..................5
2.1. Behaviour Aggregate Classification Function ................5
2.2. Dropping Function ..........................................5
2.3. Threshold-Meter Function ...................................6
2.4. Excess-Traffic-Meter Function ..............................6
2.5. Marking Function ...........................................7
3. Security Considerations .........................................7
4. Acknowledgements ................................................8
5. References ......................................................8
5.1. Normative Reference ........................................8
5.2. Informative References .....................................8
Appendix A. Example Algorithms ...................................11
A.1. Threshold-Metering and -Marking ...........................11
A.2. Excess-Traffic-Metering and -Marking ......................12
Appendix B. Implementation Notes .................................13
B.1. Competing-Non-PCN-Traffic .................................13
B.2. Scope .....................................................14
B.3. Behaviour Aggregate Classification ........................15
B.4. Dropping ..................................................15
B.5. Threshold-Metering ........................................17
B.6. Excess-Traffic-Metering ...................................18
B.7. Marking ...................................................19
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. Within the domain, PCN-traffic is forwarded in a prioritised Diffserv traffic class [RFC2475].
前の輻輳通知（PCN）の目的は、簡単でスケーラブル、かつ堅牢なファッションでのDiffservドメイン内の非弾性フローのサービス品質（QoS）を保護することです。新しいフロー要求を認めるか、ブロックするかどうかを決定するためにアドミッション制御、及び（異常な状況で）既存のフローの一部を終了するかどうかを決定するために終端を流れ：二つのメカニズムが使用されます。これを達成するために、PCN-トラフィックの全体的な速度は、ドメイン内のすべてのリンクの上に計量され、そして特定の構成されたレートを超過した場合PCN-パケットが適切にマークされています。これらの構成割合は、このように任意の輻輳が（したがって、「プレ輻輳通知」）が発生する前にオーバーロードに関するノードを境界に通知を提供する、リンクの速度を下回っています。マーキングのレベルは、境界ノードが認めるか終了するかどうかについての決定を行うことができます。ドメイン内、PCN-トラフィックが優先Diffservのトラフィッククラス[RFC2475]に転送されます。
This document defines the two metering and marking behaviours of PCN-nodes. Their aim is to enable PCN-nodes to give an "early warning" of potential congestion before there is any significant build-up of PCN-packets in their queues. In summary, their objectives are:
この文書は、二つの計量を定義し、PCN-ノードの挙動をマーキング。彼らの目的は、そのキューにPCN-パケットのいずれかの重要なビルドアップがある前に、潜在的な輻輳の「早期警告」を与えることPCN-ノードを有効にすることです。要約すると、その目的は以下のとおりです。
o Threshold-metering and -marking: to mark all PCN-packets (with a "threshold-mark") when the bit rate of PCN-traffic is greater than its configured reference rate ("PCN-threshold-rate").
Oしきい値計量及び-marking：PCN-トラフィックのビットレートは、その構成された基準速度（「PCN-閾値速度」）よりも大きい場合（「閾値マーク」を有する）全てPCN-パケットをマークします。
o Excess-traffic-metering and -marking: when the bit rate of PCN-packets is greater than its configured reference rate ("PCN-excess-rate"), to mark PCN-packets (with an "excess-traffic-mark") at a rate equal to the difference between the rate of PCN-traffic and the PCN-excess-rate.
過剰トラフィック計量O及び-marking：PCN-パケットのビットレートは、「過剰トラフィックマーク」とPCN-パケットを（マークするために、その構成された基準速度（「PCN-過剰率」）よりも大きい場合）PCNトラフィックのレートとPCN過剰率との間の差に等しい速度で。
Note that although [RFC3168] defines a broadly RED-like (Random Early Detection) default congestion marking behaviour, it allows alternatives to be defined; this document defines such an alternative.
[RFC3168]は動作をマーキング広くRED状（ランダム早期検出）デフォルトの輻輳を定義しているが、それは選択肢が定義されることを可能にすることに留意されたいです。この文書では、このような代替手段を定義します。
Section 2 below describes the functions involved, which in outline (see Figure 1) are:
セクションの下2は、アウトラインに（図1参照）が関与する機能を、説明します。
o Behaviour aggregate (BA) classification: decide whether or not an incoming packet is a PCN-packet.
O動作の集合体（BA）分類：着信パケットがPCNパケットであるか否かを決定します。
o Dropping (optional): drop packets if the link is overloaded.
O（オプション）ドロップは：リンクが過負荷になっている場合は、パケットをドロップします。
o Threshold-meter: determine whether the bit rate of PCN-traffic exceeds its configured reference rate (PCN-threshold-rate). The meter operates on all PCN-packets on the link, and not on individual flows.
Oしきい値メーター：PCN-トラフィックのビットレートは、その構成された基準速度（PCN-閾値速度）を超えるかどうかを決定します。メーターは、リンク上ではなく、個々のフロー上のすべてのPCN-のパケット上で動作します。
o Excess-traffic-meter: measure by how much the bit rate of PCN-traffic exceeds its configured reference rate (PCN-excess-rate). The meter operates on all PCN-packets on the link, and not on individual flows.
PCNトラフィックのビットレートは、その構成された基準速度（PCN過剰率）を超えるどのくらいの算定：過剰トラフィックメートルO。メーターは、リンク上ではなく、個々のフロー上のすべてのPCN-のパケット上で動作します。
o PCN-mark: actually mark the PCN-packets, if the meter functions indicate to do so.
PCN-マーク○：メーターの機能がそうすることを示している場合、実際に、PCN-パケットをマーク。
+---------+ Result
+->|Threshold|-------+
| | Meter | |
| +---------+ V
+----------+ +- - - - -+ | +------+
| BA | | | | | | Marked
Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet
Stream | | | | | | | Stream
+----------+ +- - - - -+ | +------+
| +---------+ ^
| | Excess | |
+->| Traffic |-------+
| Meter | Result
+---------+
Figure 1: Schematic of PCN-interior-node functionality
図1：PCN-内部ノードの機能の概略
Appendix A gives an example of algorithms that fulfil the specification of Section 2, and Appendix B provides some explanations of and comments on Section 2. Both the Appendices are informative.
付録Aは、第2の仕様を満たすアルゴリズムの例を示し、付録Bは、セクション2に、いくつかの説明やコメントを提供両方の付録は有益です。
The general architecture for PCN is described in [RFC5559], whilst [Menth10] is an overview of PCN.
【Menth10】PCNの概要である一方PCNのための一般的なアーキテクチャは、[RFC5559]に記載されています。
In addition to the terminology defined in [RFC5559] and [RFC2474], the following terms are defined:
[RFC5559]及び[RFC2474]で定義された用語に加えて、以下の用語が定義されます。
o Competing-non-PCN-packet: a non-PCN-packet that shares a link with PCN-packets and competes with them for its forwarding bandwidth. Competing-non-PCN-packets MUST NOT be PCN-marked (only PCN-packets can be PCN-marked).
競合・非PCN-パケットO：PCN-パケットとのリンクを共有し、その転送帯域幅のためにそれらと競合する非PCNパケット。競合・非PCNは、パケットがPCN-マークされているはずがありません（唯一のPCN-パケットがPCN-マークすることができます）。
Note: In general, it is not advised to have any competing-non-PCN-traffic.
注意：一般的には、任意の競合する非PCN-トラフィックを持ってお勧めできません。
Note: There is likely to be traffic (such as best effort) that is forwarded at lower priority than PCN-traffic; although it shares the link with PCN-traffic, it doesn't compete for forwarding bandwidth, and hence it is not competing-non-PCN-traffic. See Appendix B.1 for further discussion about competing-non-PCN-traffic.
注意：PCN-のトラフィックよりも低い優先順位で転送されます（たとえば、ベストエフォートなど）のトラフィックをする可能性があります。それはPCN-トラフィックとリンクを共有するものの、それは転送帯域幅のために競合しない、ので、それは非PCN-トラフィックを競合されていません。競合する非PCN-トラフィックに関するさらなる議論については、付録B.1を参照してください。
o Metered-packet: a packet that is metered by the metering functions specified in Sections 2.3 and 2.4. A PCN-packet MUST be treated as a metered-packet (with the minor exception noted below in Section 2.4). A competing-non-PCN-packet MAY be treated as a metered-packet.
O従量制パケット：セクション2.3および2.4に指定された計量機能により計量されたパケット。 PCNパケット（セクション2.4で以下に記載マイナー除いて）定量パケットとして扱わなければなりません。競合する非PCN-パケットは、計量されたパケットとして処理することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This section defines the two PCN-metering and -marking behaviours. The descriptions are functional and are not intended to restrict the implementation. The informative Appendices supplement this section.
このセクションでは、2つのPCN計量及び-marking行動を定義します。説明は、機能的であり、実装を制限することを意図していません。有益な付録は、このセクションを補足します。
A PCN-node MUST classify a packet as a PCN-packet if the value of its Differentiated Services Code Point (DSCP) and Explicit Congestion Notification (ECN) fields correspond to a PCN-enabled codepoint, as defined in the encoding scheme applicable to the PCN-domain (for example, [RFC5696] defines the baseline encoding). Otherwise, the packet MUST NOT be classified as a PCN-packet.
に適用可能な符号化方式で定義されるように、その差別化サービスコードポイント（DSCP）の値と明示的輻輳通知（ECN）フィールドは、PCN対応コードポイントに対応する場合PCNノードはPCN-パケットとしてパケットを分類しなければなりませんPCNドメイン（例えば、[RFC5696]は、ベースライン符号化を定義します）。そうでない場合、パケットはPCN-パケットとして分類されてはなりません。
A PCN-node MUST classify a packet as a competing-non-PCN-packet if it is not a PCN-packet and it competes with PCN-packets for its forwarding bandwidth on a link.
それはPCN-パケットではない、それはリンク上の転送帯域幅のためのPCN-パケットと競合する場合PCN-ノードは、競合する非PCN-パケットとしてパケットを分類しなければなりません。
Note: If the PCN-node's queue overflows, then naturally packets are dropped. This section describes additional action.
注意：PCN-ノードのキューがオーバーフローした場合、自然にパケットが破棄されます。このセクションでは、追加のアクションを説明します。
On all links in the PCN-domain, dropping MAY be done by first metering all metered-packets to determine if the rate of metered-traffic on the link is greater than the rate allowed for such traffic; if the rate of metered-traffic is too high, then drop metered-packets.
PCN-ドメイン内のすべてのリンクでは、滴下は、最初に計量して、リンク上で計量されたトラフィックの割合は、このようなトラフィックに対して許容レートよりも大きいかどうかを決定するために、すべての計量のパケットを行うことができます。計量・トラフィックのレートが高すぎる場合は、計量パケットをドロップします。
If the PCN-node drops PCN-packets, then:
PCN-ノードはPCN-パケットを廃棄した場合は、次のようになります。
o PCN-packets that arrive at the PCN-node already excess-traffic-marked SHOULD be preferentially dropped.
O PCN-ノードに到着PCN-パケットすでに過剰トラフィック・マークは、優先的に廃棄されるべきです。
o the PCN-node's excess-traffic-meter SHOULD NOT meter the PCN-packets that it drops.
O PCN-ノードの過剰トラフィックメーター、メーター、それが下がるPCN-パケットをべきではありません。
A PCN-node MUST implement a threshold-meter that has behaviour functionally equivalent to the following.
PCNノードは、次のと機能的に同等の挙動を有する閾値メーターを実装しなければなりません。
The meter acts like a token bucket, which is sized in bits and has a configured reference rate (bits per second). The amount of tokens in the token bucket is termed F_tm. Tokens are added at the reference rate (PCN-threshold-rate), to a maximum value BS_tm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum F_tm = 0. (Explanation of abbreviations: F is short for Fill of the token bucket, BS for bucket size, and tm for threshold-meter.)
メータはビットでサイズおよび形状基準速度（bps単位）を有するトークンバケットのように作用します。トークンバケット内のトークンの量がF_tmと呼ばれています。トークンは最大値BS_tmに、基準速度（PCN-閾値速度）で添加されます。トークンは最小限に、計量されたパケットのビットにおけるサイズに等しい除去さF_tm = 0（略語の説明：Fが閾値メートルのトークンバケットの塗りつぶし、バケットサイズのBS、及びTMの略です）
The token bucket has a configured intermediate depth, termed threshold. If F_tm < threshold, then the meter indicates to the marking function that the packet is to be threshold-marked; otherwise, it does not.
トークンバケットは、構成された中間の深さを持っているしきい値と呼ばれます。 F_tm <しきい値は、その後、メーターはパケットがしきい値-マークするマーキング機能を示している場合は、そうでない場合、それはしていません。
A packet SHOULD NOT be metered (by this excess-traffic-meter function) in the following two cases:
パケットは、以下の2つのケースでは（この過剰トラフィックメーター機能によって）計量すべきではありません：
o if the PCN-packet is already excess-traffic-marked on arrival at the PCN-node.
O PCN-パケットはすでにPCN-ノードでの到着時に余分なトラフィック-マークされている場合。
o if this PCN-node drops the packet.
OこのPCN-ノードはパケットをドロップします。
Otherwise, the PCN-packet MUST be treated as a metered-packet -- that is, it is metered by the excess-traffic-meter.
それ以外の場合は、PCN-パケットは、計量されたパケットとして扱わなければならない - つまり、それは過剰トラフィックメーターにより計量されます。
A PCN-node MUST implement an excess-traffic-meter. The excess-traffic-meter SHOULD indicate packets to be excess-traffic-marked, independent of their size ("packet size independent marking"); if "packet size independent marking" is not implemented, then the excess-traffic-meter MUST use the "classic" metering behaviour.
PCN-ノードは、過剰なトラフィックメーターを実装しなければなりません。過剰トラフィックメーターは、そのサイズ（「パケットサイズの独立したマーキング」）とは無関係に、過剰トラフィックマーキングするパケットを示すべきです。 「独立したパケットサイズがマーキング」実装されていない場合は、超過トラフィックメーターは、「クラシック」計量動作を使用しなければなりません。
For the "classic" metering behaviour, the excess-traffic-meter has behaviour functionally equivalent to the following.
「クラシック」計量動作については、超過トラフィックメーターには、次のと機能的に同等の挙動を持っています。
The meter acts like a token bucket, which is sized in bits and has a configured reference rate (bits per second). The amount of tokens in the token bucket is termed F_etm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BS_etm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum
メータはビットでサイズおよび形状基準速度（bps単位）を有するトークンバケットのように作用します。トークンバケット内のトークンの量がF_etmと呼ばれています。トークンは最大値BS_etmに、基準速度（PCN過剰率）で添加されます。トークンは最小限に、計量されたパケットのビットにおけるサイズに等しい除去されます
F_etm = 0. If the token bucket is empty (F_etm = 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked. (Explanation of abbreviations: F is short for Fill of the token bucket, BS for bucket size, and etm for excess-traffic-meter.)
F_etm = 0トークンバケットが空である場合（F_etm = 0）、次いで計器は、パケットが過剰トラフィックマーキングするマーキング機能を示しています。 （略語の説明：Fは、過剰なトラフィックメーターのためのトークンバケットの塗りつぶし、バケツサイズのBS、およびETMの略です。）
For "packet size independent marking", the excess-traffic-meter has behaviour functionally equivalent to the following.
「マーキングの独立したパケットサイズ」は、過剰トラフィックメーターには、次のと機能的に同等の挙動を持っています。
The meter acts like a token bucket, which is sized in bits and has a configured reference rate (bits per second). The amount of tokens in the token bucket is termed F_etm. Tokens are added at the reference rate (PCN-excess-rate), to a maximum value BS_etm. If the token bucket is not negative, then tokens are removed equal to the size in bits of the metered-packet (and the meter does not indicate to the marking function that the packet is to be excess-traffic-marked). If the token bucket is negative (F_etm < 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked (and no tokens are removed). (Explanation of abbreviations: F is short for Fill of the token bucket, BS for bucket size, and etm for excess-traffic-meter.)
メータはビットでサイズおよび形状基準速度（bps単位）を有するトークンバケットのように作用します。トークンバケット内のトークンの量がF_etmと呼ばれています。トークンは最大値BS_etmに、基準速度（PCN過剰率）で添加されます。トークンバケットが負でない場合、トークンは、計量されたパケットのビットでサイズに等しい除去する（及び計器は、パケットが過剰トラフィックマーキングするマーキング機能を示すものではありません）。トークンバケットが負の場合（F_etmは<0）、そしてメーターは、パケットが過剰トラフィックマーキングするマーキング機能を示します（そして何のトークンは削除されません）。 （略語の説明：Fは、過剰なトラフィックメーターのためのトークンバケットの塗りつぶし、バケツサイズのBS、およびETMの略です。）
Otherwise, the meter MUST NOT indicate marking.
それ以外の場合は、メーターはマーキング示してはいけません。
A PCN-packet MUST be marked to reflect the metering results by setting its encoding state appropriately, as specified by the specific encoding scheme that applies in the PCN-domain. A consistent choice of encoding scheme MUST be made throughout a PCN-domain.
PCN-パケットがPCNドメインに適用される特定の符号化方式によって指定されるように、適切にその符号化状態を設定することにより、計量結果を反映するようにマークされなければなりません。符号化方式の一貫性の選択は、PCN-ドメイン全体なされなければなりません。
A PCN-node MUST NOT:
PCN-ノードはいけません。
o PCN-mark a packet that is not a PCN-packet;
PCN-パケットではないパケットをPCN-マークO;
o change a non-PCN-packet into a PCN-packet;
O PCN-パケットに非PCN-パケットを変更。
o change a PCN-packet into a non-PCN-packet.
O非PCN-パケットにPCN-パケットを変更します。
Note: Although competing-non-PCN-packets MAY be metered, they MUST NOT be PCN-marked.
注：競合する非PCN-パケットは計量してもよいが、彼らはPCN-マークされているはずがありません。
It is assumed that all PCN-nodes are PCN-enabled and are trusted for truthful PCN-metering and PCN-marking. If this isn't the case, then there are numerous potential attacks. 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.
すべてのPCN-ノードがPCNに対応しており、正直PCN-計量とPCN-マーキングのために信頼されているものとします。そうでない場合は、多数の潜在的な攻撃があります。例えば、不正PCN-内部ノードは、PCNマークができない流れが許可されなかったように、すべてのパケットを。別の可能性は、それが事前に混雑している場合でも、すべてのパケットをマークにPCNないということです。
Note that 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 Denial-of-Service (DoS) or eavesdropping.
PCN-インテリア・ノードが流れることを認識していないことに注意してください。例えば、のためのサービス拒否（DoS）又は盗聴 - これは、データプレーンにおける攻撃目標特定流れるいくつかのセキュリティ攻撃を防ぎます。
As regards Security Operations and Management, PCN adds few specifics to the general good practice required in this field [RFC4778]. For example, it may be sensible for a PCN-node to raise an alarm if it is persistently PCN-marking.
セキュリティの運用・管理については、PCNは、このフィールド[RFC4778]で必要な一般的な良い練習にいくつかの詳細を追加します。それは永続的である場合PCNマーキングPCNノードアラームを上げるために、例えば、それが賢明であり得ます。
Security considerations are further discussed in [RFC5559].
セキュリティの考慮事項は、さらに、[RFC5559]で議論されています。
This document is the result of extensive collaboration within the PCN WG. Amongst the most active other contributors to the development of the ideas specified in this document have been Jozef Babiarz, Bob Briscoe, Kwok-Ho Chan, Anna Charny, Georgios Karagiannis, Michael Menth, Toby Moncaster, Daisuke Satoh, and Joy Zhang. Appendix A is based on text from Michael Menth.
この文書では、PCN WG内の大規模なコラボレーションの結果です。この文書で指定されたアイデアの発展に最も活発な他の貢献者の中ヨゼフBabiarz、ボブ・ブリスコー、クォック・ホーちゃん、アンナCharny、ゲオルギオスKaragiannis、マイケルMenth、トビーMoncaster、大輔佐藤、そして喜び張されています。付録Aは、マイケル・Menthからのテキストに基づいています。
This document is a development of [Briscoe06-2]. Its authors are therefore also contributors to this document: Jozef Babiarz, Attila Bader, Bob Briscoe, Kwok-Ho Chan, Anna Charny, Stephen Dudley, Philip Eardley, Georgios Karagiannis, Francois Le Faucheur, Vassilis Liatsos, Dave Songhurst, and Lars Westberg.
この文書では、[Briscoe06-2]の開発です。ヨゼフBabiarz、アッティラバーダー、ボブ・ブリスコー、クォック・ホーちゃん、アンナCharny、スティーブン・ダドリー、フィリップEardley、ゲオルギオスKaragiannis、フランソワ・ルFaucheur、ヴァシリスLiatsos、デイブSonghurst、およびラースWestberg：その著者らはまた、そのため、この文書への貢献者です。
Thanks to those who've made comments on the document: Joe Babiarz, Fred Baker, David Black, Bob Briscoe, Ken Carlberg, Anna Charny, Ralph Droms, Mehmet Ersue, Adrian Farrel, Ruediger Geib, Wei Gengyu, Fortune Huang, Christian Hublet, Ingemar Johansson, Georgios Karagiannis, Alexey Melnikov, Michael Menth, Toby Moncaster, Dimitri Papadimitriou, Tim Polk, Daisuke Satoh, and Magnus Westerlund.
ジョーBabiarz、フレッド・ベイカー、デビッド・ブラック、ボブ・ブリスコー、ケン・カールバーグ、アンナCharny、ラルフDroms、メフメットErsue、エードリアンファレル、Ruediger Geib、魏Gengyu、フォーチュン黄、クリスチャンHublet：ドキュメントのコメントを作った人たちに感謝します、インゲマル・ヨハンソン、ゲオルギオスKaragiannis、アレクセイ・メルニコフ、マイケルMenth、トビーMoncaster、ディミトリPapadimitriou、ティムポーク、大輔佐藤、およびマグヌスウェスター。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Baker08] Baker, F., Polk, J., and M. Dolly, "DSCP for Capacity-Admitted Traffic", Work in Progress, November 2008.
【Baker08]ベーカー、F.、ポーク、J.、およびM.ドリー、 "容量-是認トラフィックのDSCP"、進歩、2008年11月ワーク。
[Briscoe06-1] 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-1】ブリスコー、B.、Eardley、P.、Songhurst、D.、ルFaucheur、F.、Charny、A.、Babiarz、J.、チャン、K.、ダドリー、S.、Karagiannis、G. 、ベイダー、A.、およびL. Westberg、「プリ輻輳通知の端から端まで展開モデル：DiffServの領域の上にアドミッション制御」、進歩、2006年10月に作業。
[Briscoe06-2] Briscoe, B., Eardley, P., Songhurst, D., Le Faucheur, F., Charny, A., Liatsos, V., Babiarz, J., Chan, K., Dudley, S., Karagiannis, G., Bader, A., and L. Westberg, "Pre-Congestion Notification marking", Work in Progress, October 2006.
【Briscoe06-2】ブリスコー、B.、Eardley、P.、Songhurst、D.、ルFaucheur、F.、Charny、A.、Liatsos、V.、Babiarz、J.、チャン、K.、ダドリー、S. 、Karagiannis、G.、ベイダー、A.、およびL. Westberg、 "マーキングプリ輻輳通知"、進歩、2006年10月に作業。
[Briscoe08] Briscoe, B., "Byte and Packet Congestion Notification", Work in Progress, August 2008.
[Briscoe08]ブリスコー、B.、「バイトおよびパケット輻輳通知」、進歩、2008年8月の作業。
[Charny07] Charny, A., Babiarz, J., Menth, M., and X. Zhang, "Comparison of Proposed PCN Approaches", Work in Progress, November 2007.
【Charny07] Charny、A.、Babiarz、J.、Menth、M.、およびX.張、 "提案PCNアプローチの比較"、進歩、2007年11月に働いています。
[Menth10] 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, 2010 (third issue), <http:// www3.informatik.uni-wuerzburg.de/staff/menth/ Publications/papers/Menth08-PCN-Overview.pdf>.
【Menth10] Menth、M.、Lehrieder、F.、ブリスコー、B.、Eardley、P.、Moncaster、T.、Babiarz、J.、チャン、K.、Charny、A.、Karagiannis、G.、張X.、テイラー、T.、佐藤、D.、およびR. Geib、 "PCNベースのアドミッション制御とフロー終端の調査"、IEEEコミュニケーションズ調査とチュートリアル、2010年（第3号）、<のhttp：// www3 .informatik.uni-wuerzburg.de /スタッフ/ menth /出版/新聞/ Menth08-PCN-Overview.pdf>。
[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月。
[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月。
[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月。
[RFC4778] Kaeo, M., "Operational Security Current Practices in Internet Service Provider Environments", RFC 4778, January 2007.
[RFC4778] Kaeoの、M.、 "インターネット・サービス・プロバイダー環境での運用セキュリティの現在のプラクティス"、RFC 4778、2007年1月。
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", RFC 5127, February 2008.
[RFC5127]チャン、K.、Babiarz、J.、およびF.ベイカー、 "DiffServのサービスクラスの集約"、RFC 5127、2008年2月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559] Eardley、P.、 "プリ輻輳通知（PCN）アーキテクチャ"、RFC 5559、2009年6月。
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009.
[RFC5696] Moncaster、T.、ブリスコー、B.、およびM. Menth、 "プレ輻輳情報のベースライン符号化及びトランスポート"、RFC 5696、2009年11月。
[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月に働いています。
Appendix A. Example Algorithms
付録A.例アルゴリズム
Note: This Appendix is informative, not normative. It is an example of algorithms that implement Section 2 and is based on [Charny07] and [Menth10].
注：この付録は規範的で、有益ではありません。これは、第2節を実装するアルゴリズムの一例であり、に基づいている[Charny07]及び[Menth10]。
There is no attempt to optimise the algorithms. The metering and marking functions are implemented together. It is assumed that three encoding states are available (one for threshold-marked, one for excess-traffic-marked, and one for not-marked). It is assumed that all metered-packets are PCN-packets and that the link is never overloaded. For excess-traffic-marking, "packet size independent marking" applies.
アルゴリズムを最適化する試みはありません。計量及びマーキング機能が一緒に実装されています。 3つのエンコード状態が（しきい値-マークのための1つの、過剰トラフィック・マークのための1つ、および、マークされていないため1）が利用可能であると仮定する。すべて定量パケットがPCN-パケットおよびリンクが過負荷されることはありませんということであると仮定する。過剰トラフィックのマーキングのために、「マーキングの独立したパケットのサイズは、」適用されます。
A.1. Threshold-Metering and -Marking
A.1。スレッショルド・メーターと-Marking
A token bucket with the following parameters:
次のパラメータを持つトークンバケット：
* PCN-threshold-rate: token rate of token bucket (bits/second)
* PCN-閾値速度：トークンバケットのトークンレート（ビット/秒）
* BS_tm: depth of token bucket (bits)
* BS_tm：トークンバケットの深さ（ビット）
* threshold: marking threshold of token bucket (bits)
*閾値：トークンバケットのマーキング閾値（ビット）
* lastUpdate: time the token bucket was last updated (seconds)
*最終更新日：時間トークンバケットが最後に更新されました（秒）
* F_tm: amount of tokens in token bucket (bits)
* F_tm：トークンバケット内のトークンの量（ビット）
A PCN-packet has the following parameters:
PCN-パケットには、以下のパラメータがあります。
* packet_size: the size of the PCN-packet (bits)
* PACKET_SIZE：PCNパケットのサイズ（ビット）
* packet_mark: the PCN encoding state of the packet
* packet_mark：パケットのPCNエンコーディング状態
In addition there is the parameter:
また、パラメータがあります：
now: the current time (seconds)
今：現在の時間（秒）
The following steps are performed when a PCN-packet arrives on a link:
PCN-パケットがリンクに到着したときに、以下のステップが実行されます。
* F_tm = min(BS_tm, F_tm + (now - lastUpdate) * PCN-threshold-rate); // add tokens to token bucket
* F_tm =分（BS_tm、F_tm +（今 - 最終更新日）* PCN-閾値レート）; //バケットをトークンにトークンを追加
* F_tm = max(0, F_tm - packet_size); // remove tokens from token bucket
* F_tm = MAX（0、F_tm - PACKET_SIZE）。 //トークンバケットからトークンを削除
* if ((F_tm < threshold) AND (packet_mark != excess-traffic-marked)) then packet_mark = threshold-marked; // do threshold-marking, but don't re-mark packets that are already excess-traffic-marked
*（！（F_tm <しきい値）AND（packet_mark =過剰トラフィック-マーク））であれば、その後packet_mark =しきい値マーク。 //しきい値マーキングんが、すでに過剰トラフィックにマークされたパケットマークの再ません
* lastUpdate = now // Note: 'now' has the same value as in step 1
*最終更新日=今//注：「今、」ステップ1と同じ値を持っています
A.2. Excess-Traffic-Metering and -Marking
A.2。過剰トラフィックメータリングおよび-Marking
A token bucket with the following parameters:
次のパラメータを持つトークンバケット：
* PCN-excess-rate: token rate of token bucket (bits/second)
* PCN過剰率：トークンバケットのトークンレート（ビット/秒）
* BS_etm: depth of TB in token bucket (bits)
* BS_etm：トークンバケット内のTBの深さ（ビット）
* lastUpdate: time the token bucket was last updated (seconds)
*最終更新日：時間トークンバケットが最後に更新されました（秒）
* F_etm: amount of tokens in token bucket (bits)
* F_etm：トークンバケット内のトークンの量（ビット）
A PCN-packet has the following parameters:
PCN-パケットには、以下のパラメータがあります。
* packet_size: the size of the PCN-packet (bits)
* PACKET_SIZE：PCNパケットのサイズ（ビット）
* packet_mark: the PCN encoding state of the packet
* packet_mark：パケットのPCNエンコーディング状態
In addition there is the parameter:
また、パラメータがあります：
* now: the current time (seconds)
*今：現在の時間（秒）
The following steps are performed when a PCN-packet arrives on a link:
PCN-パケットがリンクに到着したときに、以下のステップが実行されます。
* F_etm = min(BS_etm, F_etm + (now - lastUpdate) * PCN-excess-rate); // add tokens to token bucket
* F_etm =分（BS_etm、F_etm +（今 - 最終更新日）* PCN過剰率）。 //バケットをトークンにトークンを追加
* if (packet_mark != excess-traffic-marked) then // do not meter packets that are already excess-traffic-marked
*（packet_mark！=過剰トラフィック-マーク）そして//はすでに過剰トラフィックにマークされているメーターのパケットをいない場合
+ if (F_etm < 0) then packet_mark = excess-traffic-marked; // do excess-traffic-marking. The algorithm ensures this is independent of packet size
+ IF（F_etm <0）をpacket_mark =過剰トラフィックマーク。 //過剰トラフィックマーキングを行います。このアルゴリズムは、これは、パケットのサイズとは無関係である保証します
+ else F_etm = F_etm - packet_size; // remove tokens from token bucket if don't mark packet
+他のF_etm = F_etm - PACKET_SIZE。パケットをマークしていない場合は、//トークンバケットからトークンを削除
* lastUpdate = now // Note: 'now' has the same value as in step 1
*最終更新日=今//注：「今、」ステップ1と同じ値を持っています
Appendix B. Implementation Notes
付録B.実装ノート
Note: This Appendix is informative, not normative. It comments on Section 2, including reasoning about whether MUSTs or SHOULDs are required. For guidance on Operations and Management considerations, please see [RFC5559].
注：この付録は規範的で、有益ではありません。これは、マストまたはSHOULDsが必要とされているかどうかについての推論を含む、第2節にコメントしています。運用と管理の考慮事項に関するガイダンスについては、[RFC5559]を参照してください。
B.1. Competing-Non-PCN-Traffic
B.1。競合・非PCN-トラフィック
In general, it is not advised to have any competing-non-PCN-traffic, essentially because 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 [RFC5559]. But if there is competing-non-PCN-traffic, then:
競合する非PCN-トラフィックの予測不可能な量は、PCNメカニズムはそれほど正確になり、その入院PCN-のQoSを保護するPCNの能力を低下させるので、一般的には、基本的に、任意の競合する非PCN-トラフィックを持っているようにアドバイスされていません[RFC5559]を流れます。しかし、その後、競合する非PCNトラフィックがある場合：
* limit the rate at which competing-non-PCN-traffic can be
forwarded on each link in the PCN-domain. One method for
achieving this is to queue competing-non-PCN-packets
separately from PCN-packets and to limit the scheduling rate
of the former. Another method is to drop competing-non-PCN-
packets in excess of some rate.
* police competing-non-PCN-traffic at the PCN-ingress-nodes, as in the Diffserv architecture, for example. However, Diffserv's static traffic conditioning agreements risk a focused overload of traffic from several PCN-ingress-nodes onto one link.
*例えばDiffServアーキテクチャのように、PCN入ノードで警察競合する非PCN-トラフィック、。しかし、Diffservのの静的なトラフィック調整契約は、一方のリンク上に複数のPCN入ノードからのトラフィックの集中過負荷を危険にさらします。
* by design, it is known that the level of competing-non-PCN-traffic is always very small -- perhaps it consists of operator control messages only.
*デザインによって、競合する非PCNトラフィックのレベルは常に非常に小さいことが知られている - おそらくそれは、オペレータ制御メッセージのみで構成されています。
2. In general, PCN's mechanisms should take account of competing-non-PCN-traffic, in order to improve the accuracy of the decision about whether to admit (or terminate) a PCN-flow. For example:
一般的には2、PCNのメカニズムが認める（または終了）するかどうかについての決定PCN-フローの精度を向上させるためには、競合する非PCN-トラフィックのアカウントを取る必要があります。例えば：
* competing-non-PCN-traffic contributes to the PCN-meters;
competing-non-PCN-packets are treated as metered-packets.
* each PCN-node, on its links: (1) reduces the reference rates (PCN-threshold-rate and PCN-excess-rate), in order to allow 'headroom' for the competing-non-PCN-traffic; (2) limits the maximum forwarding rate of competing-non-PCN-traffic to be less than the 'headroom'. In this case, competing-non-PCN-packets are not treated as metered-packets.
*各PCNノードは、そのリンクに：（1）競合する非PCNトラフィックのための「ヘッドルーム」を可能にするために、参照レート（PCN-閾値速度およびPCN過剰率）を低下させます。 （2）競合する非PCNトラフィックの最大転送レートは「ヘッドルーム」未満に制限されます。この場合、競合する非PCN-パケットは、計量・パケットとして扱われません。
3. The operator should decide on appropriate action. Dropping is discussed further in Appendix B.4.
3.オペレータが適切な行動を決定してください。ドロップは、付録B.4にさらに議論されています。
One specific example of competing-non-PCN-traffic occurs if the PCN-compatible Diffserv codepoint is one of those that [Baker08] defines as suitable for use with admission control and there is such non-PCN-traffic in the PCN-domain. A similar example could occur for Diffserv codepoints of the Real-Time Treatment Aggregate [RFC5127]. In such cases, PCN-traffic and competing-non-PCN-traffic are distinguished by different values of the ECN field [RFC5696].
PCN互換のDiffservコードポイントが[Baker08】アドミッション制御で使用するためのような適切な定義しているものの一つであり、PCN-ドメインにおけるそのような非PCNトラフィックがある場合、競合する非PCNトラフィックの1つの具体例は起こります。同様の例は、リアルタイム処理集合[RFC5127]のDiffservのコードポイントのために起こり得ます。このような場合には、PCNトラフィックと競合する非PCNトラフィックがECNフィールドの異なる値[RFC5696]によって区別されます。
Another example would occur if there is more than one PCN-compatible Diffserv codepoint in a PCN-domain. For instance, suppose there are two PCN-BAs treated at different priorities. Then as far as the lower priority PCN-BA is concerned, the higher priority PCN-traffic needs to be treated as competing-non-PCN-traffic.
別の例は、PCN-ドメイン内の複数のPCN互換のDiffservコードポイントがある場合に発生します。例えば、異なる優先順位で扱わ2 PCN-BASがあるとします。そして、限り低い優先順位PCN-BAに関しては、優先度の高いPCN-トラフィックは、競合する非PCN-トラフィックとして扱われる必要があります。
B.2. Scope
B.2。範囲
It may be known, for instance by the design of the network topology, that some links can never be pre-congested (even in unusual circumstances, such as after the failure of some links). There is then no need to deploy the PCN-metering and -marking behaviour on those links.
いくつかのリンクは（たとえそのようないくつかのリンクの障害が発生した後のような異常な状況において）予め混雑することはできませんことを、ネットワークトポロジーの設計によって、例えば、知られていてもよいです。これらのリンク上のPCN-計量と-marking行動を展開する必要はその後、ありません。
The meters can be implemented on the ingoing or outgoing interface of a PCN-node. It may be that existing hardware can support only one meter per ingoing interface and one per outgoing interface. Then, for instance, threshold-metering could be run on all the ingoing interfaces and excess-traffic-metering on all the outgoing interfaces; note that the same choice must be made for all the links in a PCN-domain to ensure that the two metering behaviours are applied exactly once for all the links.
メーターは、入ってくる又はPCNノードの発信インターフェイス上で実現することができます。これは、既存のハードウェアが入ってくるインターフェイスと発信インターフェイスごとに1つあたりわずか1メートルをサポートできることかもしれません。次いで、例えば、閾値計量は、すべての発信インターフェイス上のすべての入ってくるインターフェースと過剰トラフィック計量上で実行することができます。同じ選択肢が2つの計量行動は、すべてのリンクのために一度だけ適用されることを保証するために、PCN-ドメイン内のすべてのリンクのために行われなければならないことに注意してください。
The baseline encoding [RFC5696] specifies only two encoding states (PCN-marked and not-marked). In this case, "excess-traffic-marked" means a packet that is PCN-marked as a result of the excess-traffic-meter function, and "threshold-marked" means a packet that is PCN-marked as a result of the threshold-meter function. As far as terminology is concerned, this interpretation is consistent with that defined in [RFC5559]. Note that a deployment needs to make a consistent choice throughout the PCN-domain whether PCN-marked is interpreted as excess-traffic-marked or threshold-marked.
ベースラインエンコーディング[RFC5696]は2つだけの符号化状態（PCN-マークと、マークされていない）を指定します。この場合、「過剰トラフィック・マーク」PCN-マーク過剰トラフィックメートルの関数の結果として、あるパケットを意味し、「しきい値-マークは」の結果として、PCN-マークされたパケットを意味し、しきい値メートルの機能。限り用語に関しては、この解釈は、[RFC5559]で定義されたものと一致しています。展開が過剰マーク・トラフィックやしきい値マークとして解釈されるPCN-マークするかどうかPCN-ドメイン全体で一貫性のある選択をする必要があることに注意してください。
Note that even if there are only two encoding states, it is still required that both the meters are implemented, in order to ease compatibility between equipment and to remove a configuration option and associated complexity. Hardware with limited availability of token buckets could be configured to run only one of the meters, but it must be possible to enable either meter. Although, in the scenario with two encoding states, indications from one of the meters are ignored by the marking function, they may be logged or acted upon in some other way, for example, by the management system or an explicit signalling protocol; such considerations are out of the scope of this document.
2つだけのコードの状態が存在する場合であっても、まだ機器間の互換性を容易にし、コンフィギュレーション・オプションと関連する複雑性を除去するために、計器の両方が実装されていることが必要であることに留意されたいです。トークンバケットの利用が限られたハードウェアはわずか1メートルのを実行するように設定することができますが、どちらかのメーターを有効にすることが可能でなければなりません。二つの符号化状態を有するシナリオでは、メートルのいずれかから指示マーキング機能によって無視されるが、それらは記録されることがあり、または管理システムまたは明示的シグナリングプロトコルによって、例えば、他の方法で作用します。そのような考慮は、この文書の範囲外です。
B.3. Behaviour Aggregate Classification
B.3。行動集計分類
Configuration of PCN-nodes will define what values of the DSCP and ECN fields indicate a PCN-packet in a particular PCN-domain. For instance, [RFC5696] defines the baseline encoding.
PCN-ノードの設定は、特定のPCN-ドメインのPCN-パケットを示すものをDSCPとECNフィールドの値を定義します。例えば、[RFC5696]は、ベースライン符号化を定義します。
Configuration will also define what values of the DSCP and ECN fields indicate a competing-non-PCN-packet in a particular PCN-domain.
構成は、DSCPとECNフィールドの値が特定のPCNドメインで競合する非PCN-パケットを示すかを定義します。
B.4. Dropping
B.4。下降
The objective of the dropping function is to minimise the queueing delay suffered by metered-traffic at a PCN-node, since PCN-traffic (and perhaps competing-non-PCN-traffic) is expected to be inelastic traffic generated by real-time applications. In practice, it would be defined as exceeding a specific traffic profile, typically based on a token bucket.
PCNトラフィック（およびおそらくは競合する非PCNトラフィック）がリアルタイムアプリケーションによって生成された非弾性トラフィックであると予想されるので、滴下機能の目的は、PCNノードで定量トラフィックが被るキューイング遅延を最小化することです。実際には、一般的にトークンバケットに基づいて、特定のトラフィックプロファイルを超えると定義されるだろう。
If there is no competing-non-PCN-traffic, then it is not expected that the dropping function is needed, since PCN's flow admission and termination mechanisms limit the amount of PCN-traffic. Even so, it still might be implemented as a back stop against misconfiguration of the PCN-domain, for instance.
無競合する非PCN-トラフィックが存在しない場合はPCNの流れの入場と終了のメカニズムは、PCN-トラフィックの量を制限するので、ドロップ機能が必要とされることが期待されていません。たとえそうだとしても、それはまだ、たとえば、PCN-ドメインの設定ミスに対するバックストップとして実装される可能性があります。
If there is competing-non-PCN-traffic, then the details of the dropping function will depend on how the router's implementation handles the two sorts of traffic:
競合する非PCN-トラフィックがある場合は、ドロップ機能の詳細については、ルータの実装は、トラフィックの2種類をどのように処理するかに依存します：
1. a common queue for PCN-traffic and competing-non-PCN-traffic, with a traffic conditioner for the competing-non-PCN-traffic; or
1.競合する非PCN-トラフィックのトラフィックコンディショナーとPCN-トラフィックと競合する非PCN-トラフィック用の共通キュー;または
2. separate queues, in which case the amount of competing-non-PCN-traffic can be limited by limiting the rate at which the scheduler (for the competing-non-PCN-traffic) forwards packets.
競合する非PCNトラフィックの量は、（競合する非PCNトラフィックのための）スケジューラがパケットを転送する速度を制限することによって制限することができ、その場合、2の別個のキュー。
(The discussion here is based on that in [Baker08].)
（ここでの議論は[Baker08]のものに基づいています。）
Note that only dropping of packets is allowed. Downgrading of packets to a lower priority BA is not allowed (see Appendix B.7), since it would lead to packet mis-ordering. Shaping ("the process of delaying packets" [RFC2475]) is not suitable if the traffic comes from real-time applications.
パケットのドロップのみが許可されることに注意してください。それは、パケットの誤発注につながるので、優先順位の低いBAへのパケットの格下げは、（付録B.7を参照）を許可されていません。トラフィックはリアルタイムアプリケーションから来ている場合（「パケットを遅らせるプロセス」[RFC2475]）シェーピングすることは適切ではありません。
Preferential dropping of competing-non-PCN-traffic: In general, it is reasonable for competing-non-PCN-traffic to get harsher treatment than PCN-traffic (that is, competing-non-PCN-packets are preferentially dropped) because PCN's flow admission and termination mechanisms are stronger than the mechanisms that are likely to be applied to the competing-non-PCN-traffic. The PCN mechanisms also mean that a dropper should not be needed for the PCN-traffic.
競合する非PCN-トラフィックの優先ドロップ：一般的には、PCN-のトラフィックよりも厳しい治療を取得するために、非PCN-トラフィックを競合するための合理的である（つまり、競合する非PCN-パケットを優先的に廃棄されます）PCNの理由フローアドミッションと終了のメカニズムは、競合する非PCN-トラフィックに適用される可能性のあるメカニズムよりも強いです。 PCN機構もまたドロッパーはPCN-トラフィックのために必要されるべきでないことを意味します。
Preferential dropping of excess-traffic-marked packets: Section 2.2 specifies, "If the PCN-node drops PCN-packets, then ... PCN-packets that arrive at the PCN-node already excess-traffic-marked SHOULD be preferentially dropped". In brief, the reason is that, with the "controlled load" edge behaviour [Taylor09], this avoids over-termination in the event of multiple bottlenecks in the PCN-domain [Charny07]. A fuller explanation is as follows. The optimal dropping behaviour depends on the particular edge behaviour [Menth10]. A single dropping behaviour is defined, as it is simpler to standardise, implement, and operate. The standardised dropping behaviour is at least adequate for all edge behaviours (and good for some), whereas others are not (for example, with tail dropping, far too much traffic may be terminated with the "controlled load" edge behaviour, in the event of multiple bottlenecks in the PCN-domain [Charny07]). The dropping behaviour is defined as a 'SHOULD', rather than a 'MUST', in recognition that other dropping behaviour may be preferred in particular circumstances, for example: (1) with the "marked flow" termination edge behaviour, preferential dropping of unmarked packets may be better [Menth10]; (2) tail dropping may make PCN-marking behaviour easier to implement on current routers.
過剰トラフィックマーキングされたパケットの優先ドロップ：2.2指定し、「PCN-ノードはPCN-パケットを廃棄した場合、その後... PCN-パケットPCN-ノードに到着、すでに過剰トラフィック-マーク優先的に廃棄されるべきです」 。簡単に言えば、その理由は、「制御された負荷」エッジ挙動[Taylor09]で、これは[Charny07] PCNドメイン内の複数のボトルネックが発生した場合にオーバー終了回避する、ということです。次のように充実した説明があります。最適な滴下挙動は、特定のエッジ挙動[Menth10]に依存します。標準実装、および操作が簡単であるように、単一の滴下動作は、定義されています。他はテールドロップで、例えば（ではないのに対し、標準化された廃棄動作は、あまりにも多くのトラフィックがイベントで、「制御負荷」エッジ行動で終了することができる、少なくともすべてのエッジの行動のための適切な（といくつかのために良い）ですPCNドメイン[Charny07]）で複数のボトルネック。滴下挙動は、例えば、他の滴下挙動は、特定の状況では好ましいかもしれないという認識で、むしろ「MUST」より、「SHOULD」として定義される：（1）「とマークフロー」終端エッジの動作と、優先滴下マークされていないパケットは、[Menth10】良好であってもよいです。 （2）テールドロップが現在のルータに実装が簡単PCN-マーキング動作させることがあります。
Exactly what "preferentially dropped" means is left to the implementation. It is also left to the implementation what to do if there are no excess-traffic-marked PCN-packets available at a particular instant.
まさに「優先的に低下した」とする実装に委ねられています。また、特定の時点で入手可能な余分なトラフィック・マークPCN-パケットが存在しない場合にどうするか、実装に任されています。
Section 2.2 also specifies, "the PCN-node's excess-traffic-meter SHOULD NOT meter the PCN-packets that it drops." This avoids over-termination [Menth10]. Effectively, it means that the dropping function (if present) should be done before the meter functions -- which is natural.
2.2節にも、「PCN-ノードの過剰トラフィックメートルメートル、それが下がるPCN-パケットをべきではありません。」、指定しますこれは、オーバー終了[Menth10]避けることができます。自然である - 実際には、それが落下関数は（存在する場合）メーター機能の前に行われるべきであることを意味しています。
B.5. Threshold-Metering
B.5。しきい値 - 測光
The description is in terms of a 'token bucket with threshold' (which [Briscoe06-1] views as a virtual queue). However, the description is not intended to standardise implementation.
説明は「閾値とトークンバケット」（仮想キューとして[Briscoe06-1】図）に関するものです。しかし、説明が実装を標準化するものではありません。
The reference rate of the threshold-meter (PCN-threshold-rate) is configured at less than the rate allocated to the PCN-traffic class. Also, the PCN-threshold-rate is less than, or possibly equal to, the PCN-excess-rate.
閾値メートル（PCN-閾値速度）の基準速度はPCNトラフィッククラスに割り当てられたレート未満で構成されています。また、PCN-閾値レートはより少ない、または、PCN過剰率におそらく等しいです。
Section 2.3 specifies, "If F_tm < threshold, then the meter indicates to the marking function that the packet is to be threshold-marked; otherwise, it does not." Note that a PCN-packet is marked without explicit additional bias for the packet's size.
2.3指定し、「F_tm <しきい値ならば、メーターはパケットがしきい値-マークするマーキング機能を示し、そうでない場合、それはしていません。」 PCN-パケットは、パケットのサイズを明示的に追加のバイアスなしでマークされていることに注意してください。
The behaviour must be functionally equivalent to the description in Section 2.3. "Functionally equivalent" means the observable 'black box' behaviour is the same or very similar, for example, if either precisely the same set of packets is marked or if the set is shifted by one packet. It is intended to allow implementation freedom over matters such as:
動作は、2.3節で説明と機能的に同等でなければなりません。 「機能的に等価」パケットの正確に同一のセットがマークされているいずれかの場合、またはセットは、1つのパケットだけシフトされた場合に観察可能な「ブラックボックス」行動は、例えば、同じ又は非常に類似していることを意味します。次のような事項について、実装の自由度を可能にすることを意図しています。
o whether tokens are added to the token bucket at regular time intervals or only when a packet is processed.
トークンは一定の時間間隔でトークンバケットに追加されているかどうか、パケットが処理されている場合にのみ、O。
o whether the new token bucket depth is calculated before or after it is decided whether to PCN-mark the packet. The effect of this is simply to shift the sequence of marks by one packet.
新しいトークンバケットの深さは前またはパケットをPCN-マークするかどうかを決定した後に計算されているかどうか、O。この効果は、1個のパケット分のマークのシーケンスをシフトするだけです。
o when the token bucket is very nearly empty and a packet arrives larger than F_tm, then the precise change in F_tm is up to the implementation. For instance:
トークンバケットは非常に近い空で、パケットがF_tmより大きい到着したとき、O、その後、F_tmで正確な変更は実装次第です。例えば：
* set F_tm = 0 and indicate threshold-mark to the marking function.
* F_tm = 0を設定して、マーキング機能にしきい値マークを示しています。
* check whether F_tm < threshold and if it is, then indicate threshold-mark to the marking function; then set F_tm = 0.
* F_tm <しきい値とそれがあるかのかどうかを確認し、その後、マーキング機能にしきい値マークを示しています。その後、F_tm = 0を設定してください。
* leave F_tm unaltered and indicate threshold-mark to the marking function.
*未変更F_tmを残し、マーキング機能にしきい値マークを示しています。
o similarly, when the token bucket is very nearly full and a packet arrives larger than (BS_tm - F_tm), then the precise change in F_tm is up to the implementation.
トークンバケットは非常にほぼ一杯になると、パケットが（BS_tm - F_tm）より大きい到着したときにO同様に、次いでF_tmにおける正確な変化は実装次第です。
Note that all PCN-packets, even if already marked, are metered by the threshold-meter function (unlike the excess-traffic-meter function), because all packets should contribute to the decision whether there is room for a new flow.
すべてのパケットが新しいフローの余地があるかどうかの決定に貢献する必要があるため、すべてのPCN-パケットは、すでにマークされていても、（過剰トラフィックメーター機能とは異なり）、閾値メートルの機能によって計量されていることに注意してください。
B.6. Excess-Traffic-Metering
B.6。過剰ベースのトラフィックメータ
The description is in terms of a token bucket, however the implementation is not standardised.
説明は、しかし、実装が標準化されていない、トークンバケットという点です。
The reference rate of the excess-traffic-meter (PCN-excess-rate) is configured at less than (or possibly equal to) the rate allocated to the PCN-traffic class. Also, the PCN-excess-rate is greater than, or possibly equal to, the PCN-threshold-rate.
過剰トラフィックメートル（PCN過剰率）の基準速度はPCNトラフィッククラスに割り当てられたレート（またはおそらくは等しい）未満で構成されています。また、PCN過剰率はより大きく、または、PCN-閾値速度におそらく等しいです。
As in Section B.5, "functionally equivalent" allows some implementation flexibility, for example, the exact algorithm when the token bucket is very nearly empty or very nearly full.
セクションB.5のように、「機能的に等価な」トークンバケットは非常にほぼ空または非常にほぼ満杯である場合、例えば、正確なアルゴリズムを、いくつかの実装の柔軟性を可能にします。
Section 2.4 specifies, "A packet SHOULD NOT be metered (by this excess-traffic-meter function) ... if the packet is already excess-traffic-marked on arrival at the PCN-node". This avoids over-termination (with some edge behaviours) in the event that the PCN-traffic passes through multiple bottlenecks in the PCN-domain [Charny07]. Note that an implementation could determine whether the packet is already excess-traffic-marked as an integral part of its BA classification function. The behaviour is defined as a 'SHOULD NOT', rather than a 'MUST NOT', because it may be slightly harder to implement than a metering function that is blind to previous packet markings.
2.4節を指定、「パケット（この過剰トラフィックメーター機能によって）計量されるべきではない...パケットがすでにPCN-ノードでの到着時に余分なトラフィック-マークされている場合」。これは、オーバー終了PCNトラフィックがPCNドメイン[Charny07]で複数のボトルネックを通過する場合には（いくつかのエッジ挙動で）回避されます。実装は、パケットがすでにそのBA分類機能の不可欠な部分として、過剰トラフィック-マークされているかどうかを決定することができることに注意してください。以前のパケットマーキングにブラインドで計量関数よりも実装がやや困難かもしれないので動作は、むしろ「MUST NOT」より、「SHOULD NOT」として定義されます。
Section 2.4 specifies, "A packet SHOULD NOT be metered (by this excess-traffic-meter function) ... if this PCN-node drops the packet." This avoids over-termination [Menth10]. (A similar statement could also be made for the threshold-meter function but is irrelevant, as a link that is overloaded will already be substantially pre-congested and hence threshold-marking all packets.) It seems natural to perform the dropping function before the metering functions, although for some equipment it may be harder to implement; hence, the behaviour is defined as a 'SHOULD NOT', rather than a 'MUST NOT'.
2.4節を指定し、「パケット（この過剰トラフィックメーター機能によって）計量されるべきではない...このPCN-ノードがパケットをドロップします。」これは、オーバー終了[Menth10]避けることができます。 （同様の文はまた、しきい値メートルの機能のために作ることができるが、オーバーロードされているリンクはすでに、したがって、実質的に事前に混雑し、しきい値マーキングすべてのパケットをされますよう、無関係です。）前に滴下機能を実行するために自然なようです計量機能、いくつかの機器のためにそれを実装する困難かもしれないが。したがって、動作は、むしろ「MUST NOT」よりも、「べきではない」と定義されます。
"Packet size independent marking" -- excess-traffic-marking that is independent of packet size -- is specified as a 'SHOULD' rather than a 'MUST' in Section 2.4 because it may be slightly harder for some equipment to implement, and the impact of not doing so is undesirable but moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated). With the "classic" excess-traffic-meter behaviour, large packets are more likely to be excess-traffic-marked than small packets (because packets are marked if the number of tokens in the token bucket is smaller than the packet size). This means that, with some edge behaviours, flows with large packets are more likely to be terminated than flows with small packets ([Briscoe08], [Menth10]). "Packet size independent marking" can be achieved by a small modification of the "classic" excess-traffic-meter. The number of tokens in the bucket can become negative; if this number is negative at a packet's arrival, the packet is marked; otherwise, the amount of tokens equal to the packet size is removed from the bucket. Note that with "packet size independent marking", either the packet is marked or tokens are removed -- never both. Hence, the token bucket cannot become more negative than the maximum packet size on the link. The algorithm described in Appendix A implements this behaviour.
「マーキングの独立したパケットサイズ」 - それを超過トラフィックマーキングは、パケットサイズとは独立している - いくつかの機器が実装するのは少し難しいかもしれないので、むしろ2.4節の「MUST」よりも「SHOULD」として指定され、そうではないの影響は望ましくないが、中程度である（十分なトラフィックが終了したが、大きなパケットが終了される可能性が高いとフロー）。 「古典的な」過剰トラフィックメートルの動作では、大きなパケットは、（トークンバケット内のトークン数がパケットサイズよりも小さい場合、パケットがマークされているので）小さいパケットよりも過剰トラフィック・マークである可能性が高いです。これは、小さなパケット（[Briscoe08]、[Menth10]）で流れるよりも終了される可能性が高いいくつかのエッジ挙動と、大きなパケットと流れることを意味します。 「独立したパケットサイズはマーキング」「クラシック」過剰トラフィックメートルの小さな変更によって達成することができます。バケット内のトークンの数がマイナスになることができます。この数は、パケットの到着時に負であれば、パケットがマークされています。そうでない場合は、パケットサイズに等しいトークンの量は、バケットから除去されます。決して両方を - のいずれかのパケットがマークされているか、トークンが削除されていない、「マーキングの独立したパケットサイズ」であることに注意してください。このため、トークンバケットは、リンク上の最大パケットサイズよりも負になることはできません。付録Aに記載されたアルゴリズムは、この動作を実装します。
Note that BS_etm is independent of BS_tm, F_etm is independent of F_tm (except in that a packet can change both), and the two configured rates (PCN-excess-rate and PCN-threshold-rate) are independent (except that PCN-excess-rate >= PCN-threshold-rate).
BS_etmはBS_tmとは無関係であることに注意してください、F_etm（すなわち除きパケットの両方を変更することができる）F_tmから独立していると、2つの構成割合（PCN過剰率およびPCN-閾値速度）が独立している（すなわちPCN過剰除き-rate> = PCN-閾値速度）。
B.7. Marking
B.7。マーキング
Section 2.5 defines, "A PCN-node MUST NOT ...change a PCN-packet into a non-PCN-packet". This means that a PCN-node is not allowed to downgrade a PCN-packet into a lower priority Diffserv BA (hence, downgrading is not allowed as an alternative to dropping).
セクション2.5定義は、「PCN-ノードが...非PCN-パケットにPCN-パケットを変更してはなりません」。これは、PCNノードが（したがって、格下げが落下に代わるものとして許可されていない）より低い優先度のDiffserv BAにPCNパケットをダウングレードすることができないことを意味します。
Section 2.5 defines, "A PCN-node MUST NOT ...PCN-mark a packet that is not a PCN-packet". This means that in the scenario where competing-non-PCN-packets are treated as metered-packets, a meter may indicate a packet is to be PCN-marked, but the marking function knows it cannot be marked. It is left open to the implementation exactly what to do in this case; one simple possibility is to mark the next PCN-packet. Note that unless the PCN-packets are a large fraction of all the metered-packets, the PCN mechanisms may not work well.
セクション2.5定義、「PCN-ノードは... PCN-パケットではないパケットをPCN-マークしてはなりません」。これは、パケットがPCN-マークされることですが、マーキング機能は、それがマークすることはできません知っている非PCN-パケットが競合する計量・パケットとして扱われるシナリオでは、メーターが示すかもしれないことを意味します。それは、まさにこのケースで行うには実装に開いたままになっています。 1つの簡単な可能性は次のPCN-パケットをマークすることです。 PCN-パケットはすべて定量パケットの大部分でない限り、PCNメカニズムがうまく機能しない可能性があることに注意してください。
Although the metering functions are described separately from the marking function, they can be implemented in an integrated fashion.
計量機能は、マーキング機能とは別に記載されているが、これらは一体的に実施することができます。
Author's Address
著者のアドレス
Philip Eardley (editor) BT Adastral Park, Martlesham Heath Ipswich IP5 3RE UK
フィリップEardley（エディタ）BT Adastral公園、MartleshamヒースイプスウィッチIP5 3RE英国
EMail: philip.eardley@bt.com
メールアドレス：philip.eardley@bt.com