[要約] RFC 5670は、PCNノードの計測およびマーキングの動作に関する標準仕様です。このRFCの目的は、PCNネットワークでのトラフィック制御と品質保証を向上させるためのガイドラインを提供することです。
Network Working Group P. Eardley, Ed.
Request for Comments: 5670 BT
Category: Standards Track November 2009
Metering and Marking Behaviour of PCN-Nodes
PCNノードの計量およびマーキング動作
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ノードの2つのメーターとマークの動作を定義します。PCNトラフィックのレートが構成レート（「PCN-Threchold-rate」）よりも大きい場合、しきい値計算およびマークマークはすべてのPCNパケットをマークします。過剰な交通量とマークのマークは、PCNパケットの割合をマークし、マークされた量は、構成されたレート（「PCN-Excess-rate」）を超える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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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）を保護することです。2つのメカニズムが使用されています。新しいフロー要求を認めるかブロックするかを決定するための入場制御、および（異常な状況で）フロー終了を決定して、既存のフローの一部を終了するかどうかを決定します。これを達成するために、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ノードの2つのメーターとマークの動作を定義します。彼らの目的は、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 しきい値計算とマーク：PCNトラフィックのビットレートが構成された参照レート（「PCN-Threshold-rate」）よりも大きい場合、すべての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 過剰なトラフィックメタリングとマーク：PCNパケットのビットレートが設定された参照レート（「PCN-Excess-rate」）よりも大きい場合、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]は広く赤色のような（ランダムな早期検出）デフォルトの混雑マーキング動作を定義しているが、代替案を定義できることに注意してください。このドキュメントは、そのような代替案を定義しています。
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-Threshold-rate）を超えるかどうかを判断します。メーターは、個々のフローではなく、リンク上のすべての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.
o 過剰なトラフィックメーター：PCNトラフィックのビットレートが構成された参照レート（PCN-Excess-rate）をどれだけ超えているかで測定します。メーターは、個々のフローではなく、リンク上のすべてのPCNパケットで動作します。
o PCN-mark: actually mark the PCN-packets, if the meter functions indicate to do so.
o PCN-Mark：メーター機能がそうすることを示している場合は、実際に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-Interior-Node機能の概略図
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.
PCNの一般的なアーキテクチャは[RFC5559]で説明されていますが、[MentH10]はPCNの概要です。
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).
o 競合しているノン-PCNパケット：PCNパケットとリンクを共有し、転送帯域幅のためにそれらと競合する非PCNパケット。競合している-Non-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トラフィックに関する詳細については、付録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メタリングとマークの動作を定義します。説明は機能的であり、実装を制限することを意図していません。有益な付録はこのセクションを補完します。
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.
PCNノードは、差別化されたサービスコードポイント（DSCP）の値と明示的なうっ血通知（ECN）フィールドの値が、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.)
メーターはトークンバケットのように機能します。トークンバケットはビットのサイズで、設定された参照レート（1秒あたりのビット）を備えています。トークンバケットのトークンの量はf_tmと呼ばれます。トークンは、参照レート（PCN-reshold-rate）で最大値BS_TMに追加されます。トークンは、メーターパケットのビットのサイズ、最小の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 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.)
メーターはトークンバケットのように機能します。トークンバケットはビットのサイズで、設定された参照レート（1秒あたりのビット）を備えています。トークンバケットのトークンの量はf_etmと呼ばれます。トークンは、参照レート（PCN-Excess-rate）で最大値BS_ETMに追加されます。トークンは、メーターパケットのビットのサイズ、最小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.)
メーターはトークンバケットのように機能します。トークンバケットはビットのサイズで、設定された参照レート（1秒あたりのビット）を備えています。トークンバケットのトークンの量はf_etmと呼ばれます。トークンは、参照レート（PCN-Excess-rate）で最大値BS_ETMに追加されます。トークンバケットが負でない場合、トークンはメーターパケットのビットのサイズに等しく削除されます（メーターは、パケットが過剰なトラフィックマークであることをマーキング関数に示しません）。トークンバケットが負（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パケットをマークする必要があります。Encodingスキームの一貫した選択は、PCNドメイン全体で行う必要があります。
A PCN-node MUST NOT:
PCNノードはしてはいけません。
o PCN-mark a packet that is not a PCN-packet;
o PCNマークPCNパケットではないパケット。
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.
注：競合している-Non-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マークに対して信頼されていると想定されています。そうでない場合、多くの潜在的な攻撃があります。たとえば、Rogue PCN-InteriorノードはすべてのパケットをPCNマークすることができ、フローが認められないようにします。もう1つの可能性は、事前に合成されている場合でも、パケットを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内の広範なコラボレーションの結果です。この文書で指定されたアイデアの開発に最も活発な他の貢献者の中には、ジョゼフ・バビアルツ、ボブ・ブリスコー、クウォック・ホ・チャン、アンナ・チャーニー、ジョージオス・カラギアンニス、マイケル・メンタ、トビー・モンカスター、ジャイ・サトー、ジョイ・チャンがありました。付録Aは、Michael 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]の開発です。したがって、その著者は、この文書にも貢献しています：Jozef Babiarz、Attila Bader、Bob Briscoe、Kwok-Ho Chan、Anna Charny、Stephen Dudley、Philip Aeardley、Georgios Karagiannis、Francois Le Faucheur、Vassilis Liatsos、Dave Songhurst、およびLars 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.
ドキュメントについてコメントしてくれた人たちに感謝します：ジョー・バビアーズ、フレッド・ベイカー、デビッド・ブラック、ボブ・ブリスコー、ケン・カールバーグ、アンナ・チャーニー、ラルフ・ドロムス、メフメット・エルセ、エイドリアン・ファレル、ルーデガー・ゲイブ、ウェイ・ジェンギュー、フォーチュン・フン、クリスチャン・ハブレット、インゲマー・ヨハンソン、ゲオルギオス・カラギアンニス、アレクセイ・メルニコフ、マイケル・メンタ、トビー・モンカスター、ディミトリ・パパジミトリウ、ティム・ポーク、大suke、マグナス・ウェスターランド。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[Baker08] Baker, F., Polk, J., and M. Dolly, "DSCP for Capacity-Admitted Traffic", Work in Progress, November 2008.
[Baker08] Baker、F.、Polk、J。、およびM. Dolly、「容量採用トラフィックの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] Briscoe、B.、Eardley、P.、Songhurst、D.、Le Faucheur、F.、Charny、A.、Babiarz、J.、Chan、K.、Dudley、S.、Karagiannis、G。、Bader、A。、およびL. Westberg、「前構成前の通知のためのエッジツーエッジの展開モデル：Diffserv地域の入場制御」、2006年10月、進行中の作業。
[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] Briscoe、B.、Eardley、P.、Songhurst、D.、Le Faucheur、F.、Charny、A.、Liatsos、V.、Babiarz、J.、Chan、K.、Dudley、S。、Karagiannis、G.、Bader、A。、およびL. Westberg、「事前相関通知マーキング」、2006年10月、進行中の作業。
[Briscoe08] Briscoe, B., "Byte and Packet Congestion Notification", Work in Progress, August 2008.
[briscoe08] Briscoe、B。、「Byte and Packet commestion notification」、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. Zhang、「提案された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.、Lehrideer、F.、Briscoe、B.、Eardley、P.、Moncaster、T.、Babiarz、J.、Chan、K.、Charny、A.、Karagiannis、G.、Zhang、X.、Taylor、T.、Satoh、D。、およびR. Geib、「PCNベースの入場制御とフロー終了の調査」、IEEE通信調査およびチュートリアル、2010年（第3号）、<http：// www3.informatik.uni-wuerzburg.de/staff/menth/publications/papers/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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、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] Chan、K.、Babiarz、J。、およびF. Baker、「Diffserv Service Classeの集約」、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.、Briscoe、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.、Huang、F.、Menth、M。、およびT. Taylor、「制御荷重（CL）動作モードのPCN境界ノード動作」、2009年3月の作業。
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つはマークされていない場合は1つ）と想定されています。すべてのメーターパケットはPCNパケットであり、リンクが過負荷になることはないと想定されています。過剰な交通量のマークには、「パケットサイズの独立マーキング」が適用されます。
A token bucket with the following parameters:
次のパラメーターを備えたトークンバケット：
* PCN-threshold-rate: token rate of token bucket (bits/second)
* PCN-wreshold-rate：トークンバケットのトークンレート（ビット/秒）
* 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)
* LastUpdate：トークンバケットが最後に更新された時間（秒）
* 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 = min（bs_tm、f_tm（now-lastupdate） * pcn-threshold-rate）;//トークンにトークンをバケツに追加します
* 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
* if（（f_tm <threshold）and（packet_mark！= expres-traffic-marked））then packet_mark = threshold-marked;//しきい値マークをしますが、すでに過剰なトラフィックマークされているパケットを再マークしないでください
* lastUpdate = now // Note: 'now' has the same value as in step 1
* lastupdate = now //注： 'now'はステップ1と同じ値を持っています
A token bucket with the following parameters:
次のパラメーターを備えたトークンバケット：
* PCN-excess-rate: token rate of token bucket (bits/second)
* PCN-Excess-rate：トークンバケットのトークンレート（ビット/秒）
* BS_etm: depth of TB in token bucket (bits)
* BS_ETM：トークンバケット（ビット）のTBの深さ
* lastUpdate: time the token bucket was last updated (seconds)
* LastUpdate：トークンバケットが最後に更新された時間（秒）
* 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 = min（bs_etm、f_etm（now-lastupdate） * pcn-excess-rate）;//トークンにトークンをバケツに追加します
* if (packet_mark != excess-traffic-marked) then // do not meter packets that are already excess-traffic-marked
* if（packet_mark！= exped-traffic-marked）then //既に過剰なトラフィックマークであるパケットをメーターにしないでください
+ 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）then packet_mark = exprach-traffic-marked;//過剰なトラフィックマーキングを行います。アルゴリズムは、これがパケットサイズに依存しないことを保証します
+ else F_etm = F_etm - packet_size; // remove tokens from token bucket if don't mark packet
+ else f_etm = f_etm -packet_size;//パケットをマークしない場合、トークンバケットからトークンを削除します
* lastUpdate = now // Note: 'now' has the same value as in step 1
* lastupdate = now //注： 'now'はステップ1と同じ値を持っています
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].
注：この付録は有益であり、規範的ではありません。セクション2にコメントします。これには、必須またはサフスが必要かどうかについての推論が含まれます。運用および管理上の考慮事項に関するガイダンスについては、[RFC5559]を参照してください。
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メカニズムの精度が低下し、入院したPCNのQoSを保護するPCNの能力が低下するため流れ[RFC5559]。しかし、競合している場合は、pcn-trafficがあります。
1. There should be a mechanism to limit it, for example:
1. たとえば、それを制限するメカニズムがあるはずです。
* 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.
* PCNドメインの各リンクに競合するノン-PCNトラフィックを転送できるレートを制限します。これを達成するための1つの方法は、PCNパケットとは別に競合している競合していないパケットをキューにし、前者のスケジューリングレートを制限することです。もう1つの方法は、競合する競合しないレートを超えてドロップすることです。
* 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-ingress-nodesで競合する警察。ただし、DiffServの静的トラフィックコンディショニング契約は、複数のPCN炎症ノードから1つのリンクへのトラフィックの集中的な過負荷を危険にさらしています。
* 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-Flowを認める（または終了する）かどうかについての決定の精度を向上させるために、競合する非PCNトラフィックを考慮する必要があります。例えば：
* competing-non-PCN-traffic contributes to the PCN-meters; competing-non-PCN-packets are treated as metered-packets.
* 競合する非PCNトラフィックは、PCNメートルに貢献します。競合する非PCNパケットは、メーターパケットとして扱われます。
* 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-reshold-rateおよびPCN-Excess-rate）を削減します。（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トラフィックの1つの具体的な例は、PCN互換のdiffserv CodePointが[Baker08]が入院制御での使用に適していると定義しており、PCNドメインにそのような非PCNトラフィックがあると定義している場合の1つである場合に発生します。同様の例が、リアルタイム治療凝集[RFC5127]のDiffServ CodePointで発生する可能性があります。そのような場合、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 CodePointがある場合、別の例が発生します。たとえば、異なる優先順位で2つのPCN-BAが処理されているとします。その後、優先度の低いPCN-BAに関する限り、優先度の高いPCNトラフィックを競合する非PCNトラフィックとして扱う必要があります。
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メタリングおよびマークの動作を展開する必要はありません。
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ノードのIngoingまたは発信インターフェイスに実装できます。既存のハードウェアは、インターフングインターフェイスごとに1メートルのメートルと、発信インターフェイスごとに1メートルしかサポートできない可能性があります。たとえば、すべてのインゴイングインターフェイスと、すべての発信インターフェイスでの過剰なトラフィックメタリングでしきい値計算を実行できます。PCNドメイン内のすべてのリンクに対して同じ選択を行う必要があることに注意して、すべてのリンクに2つの計量動作が正確に適用されることを確認する必要があります。
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つだけを実行するように構成できますが、いずれかのメーターを有効にすることができなければなりません。2つのエンコード状態を持つシナリオでは、メーターの1つからの兆候はマーキング関数によって無視されますが、たとえば管理システムまたは明示的なシグナル伝達プロトコルなど、他の方法で記録または行動することができます。このような考慮事項は、このドキュメントの範囲外です。
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ノードの構成は、DSCPおよびECNフィールドの値が特定のPCNドメインのPCNパケットを示すものを定義します。たとえば、[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パケットを示していることも定義します。
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:
競合しているNon-PCN-Trafficがある場合、ドロップ機能の詳細は、ルーターの実装が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トラフィックの共通のキュー。また
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.
2. この場合、競合する非PCNトラフィックの量は、スケジューラ（競合する非PCNトラフィック用）がパケットを転送する速度を制限することで制限できます。
(The discussion here is based on that in [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.
（ここでの議論は、[Baker08]のそれに基づいています。）パケットのドロップのみが許可されていることに注意してください。優先度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トラフィックにドロッパーを必要としないことを意味します。
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]により、PCNドメインで複数のボトルネックが発生した場合の過剰終了を回避するためです[charny07]。より詳細な説明は次のとおりです。最適なドロップ挙動は、特定のエッジの動作に依存します[MentH10]。標準化、実装、および操作がより簡単であるため、単一のドロップ動作が定義されます。標準化されたドロップ動作は、少なくともすべてのエッジの動作に適しています（そして一部の人にとっては良いことです）が、他の動作はそうではありません（たとえば、テールの落下では、イベントでは「制御された負荷」エッジの動作でトラフィックが終了する可能性があります。PCNドメインの複数のボトルネックの[charny07]）。ドロップする動作は、他のドロップする動作が特定の状況で好まれる可能性があることを認識して、「マスト」ではなく「必須」として定義されます。たとえば、（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]。事実上、それはメーター機能の前にドロップ機能（存在する場合）を実行する必要があることを意味します - これは自然なことです。
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-reshold-rate）の参照レートは、PCNトラフィッククラスに割り当てられた速度未満で構成されています。また、PCN-wreshold-rateは、PCN-Excess-rateよりも少ない、または等しい場合があります。
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.
o 新しいトークンバケットの深さが、パケットをPCNマークするかどうかが決定される前または後に計算されるかどうか。これの効果は、単にマークのシーケンスを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:
o トークンバケットが非常に空で、パケットがF_TMよりも大きく到着すると、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.
o 同様に、トークンバケットが非常にいっぱいになり、パケットが（BS_TM -F_TM）よりも大きい場合、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パケットは、既にマークされていても、すべてのパケットが新しいフローの余地があるかどうかを決定に寄与する必要があるため、しきい値メートル関数とは異なります（過剰な交通量メートル関数とは異なります）に注意してください。
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-Excess-rate）の参照レートは、PCNトラフィッククラスに割り当てられたレートよりも1未満（または等しい）で構成されています。また、PCN-Excess-rateは、PCN-Threshold-rateよりも大きい、またはおそらく等しい場合があります。
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ドメインの複数のボトルネックを通過した場合、これにより（一部のエッジの動作を伴う）、（一部のエッジの動作があります）。実装により、パケットがBA分類関数の不可欠な部分として既に過剰なトラフィックマークが既にマークされているかどうかを判断できることに注意してください。動作は、以前のパケットマーキングを盲目にする計量関数よりも実装するのがわずかに難しい場合があるため、「必要ではない」ではなく、「必要はない」と定義されます。
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]。（しきい値メートル関数に対しても同様のステートメントを作成できますが、過負荷になっているリンクはすでに実質的に事前に行われるため、しきい値をマークしているため、すべてのパケットをマークするため、同様のステートメントは無関係です。）ドロップ関数を実行する前に実行するのは自然なことです。メーター機能は、一部の機器では実装が難しい場合があります。したがって、動作は、「そうでない」ではなく、「すべきではない」と定義されます。
"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の「必須」ではなく「必要」として指定されています。そうしないことの影響は望ましくありませんが、中程度です（十分なトラフィックが終了しますが、大きなパケットを使用したフローは終了する可能性が高くなります）。「クラシックな」過剰なトラフィックメーターの動作により、大きなパケットは、小さなパケットよりも過剰なトラフィックマークが付いている可能性が高くなります（トークンバケットのトークンの数がパケットサイズよりも小さい場合、パケットはマークされているため）。これは、いくつかのエッジの動作により、大きなパケットを備えたフローは、小さなパケットを使用したフローよりも終了する可能性が高いことを意味します（[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（パケットが両方を変更できることを除いて）に依存しないことに注意してください。-rate> = pcn-threshold-rate）。
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ノードがPCNパケットをより低い優先度のDiffserv BAにダウングレードすることを許可されていないことを意味します（したがって、格下げはドロップの代替として許可されていません）。
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
フィリップ・アードリー（編集者）BTアダストラルパーク、マーティルシャムヒースイプスウィッチIP5 3RE UK
EMail: philip.eardley@bt.com