[要約] 要約：RFC 6661は、制御された負荷（CL）モードの動作のためのPre-Congestion Notification（PCN）境界ノードの振る舞いについて説明しています。 目的：このRFCの目的は、PCNを使用してネットワークの事前過負荷状態を通知し、トラフィック制御を行うための境界ノードの動作を定義することです。
Internet Engineering Task Force (IETF) A. Charny
Request for Comments: 6661
Category: Experimental F. Huang
ISSN: 2070-1721 Huawei Technologies
G. Karagiannis
University of Twente
M. Menth
University of Tuebingen
T. Taylor, Ed.
Huawei Technologies
July 2012
Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation
制御負荷（CL）動作モードの輻輳前通知（PCN）境界ノードの動作
Abstract
概要
Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using three PCN marking states: not-marked, threshold-marked, and excess-traffic-marked. This behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior.
事前輻輳通知（PCN）は、Diffservドメインに許可された非弾性トラフィックのサービス品質を保護するための手段です。全体的なPCNアーキテクチャはRFC 5559で説明されています。このメモは、PCNドメインで可能な境界ノードの動作を説明するシリーズの1つです。ここで説明する動作は、3つのPCNマーキング状態を使用した測定ベースの負荷制御の形式（not-marked、threshold-marked、excess-traffic-marked）です。この動作は、非公式には制御された負荷（CL）PCN境界ノード動作として知られています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6661.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6661で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. [CL-Specific] Assumed Core Network Behavior for CL . . . . . . 8
3. Node Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Behavior of the PCN-Egress-Node . . . . . . . . . . . . . 10
3.2.1. Data Collection . . . . . . . . . . . . . . . . . . . 10
3.2.2. Reporting the PCN Data . . . . . . . . . . . . . . . . 11
3.2.3. Optional Report Suppression . . . . . . . . . . . . . 11
3.3. Behavior at the Decision Point . . . . . . . . . . . . . . 12
3.3.1. Flow Admission . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Flow Termination . . . . . . . . . . . . . . . . . . . 13
3.3.3. Decision Point Action for Missing
PCN-Boundary-Node Reports . . . . . . . . . . . . . . 15
3.4. Behavior of the Ingress Node . . . . . . . . . . . . . . . 16
3.5. Summary of Timers and Associated Configurable Durations . 16
3.5.1. Recommended Values for the Configurable Durations . . 18
4. Specification of Diffserv Per-Domain Behavior . . . . . . . . 18
4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Technical Specification . . . . . . . . . . . . . . . . . 19
4.2.1. Classification and Traffic Conditioning . . . . . . . 19
4.2.2. PHB Configuration . . . . . . . . . . . . . . . . . . 19
4.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 20
4.6. Example Uses . . . . . . . . . . . . . . . . . . . . . . . 20
4.7. Environmental Concerns . . . . . . . . . . . . . . . . . . 20
4.8. Security Considerations . . . . . . . . . . . . . . . . . 20
5. Operational and Management Considerations . . . . . . . . . . 20
5.1. Deployment of the CL Edge Behavior . . . . . . . . . . . . 20
5.1.1. Selection of Deployment Options and Global
Parameters . . . . . . . . . . . . . . . . . . . . . . 20
5.1.2. Specification of Node- and Link-Specific Parameters . 22
5.1.3. Installation of Parameters and Policies . . . . . . . 23
5.1.4. Activation and Verification of All Behaviors . . . . . 24
5.2. Management Considerations . . . . . . . . . . . . . . . . 25
5.2.1. Event Logging in the PCN-Domain . . . . . . . . . . . 25
5.2.1.1. Logging Loss and Restoration of Contact . . . . . 25
5.2.1.2. Logging Flow Termination Events . . . . . . . . . 27
5.2.2. Provision and Use of Counters . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . . 32
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 PCN-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 PCN-boundary-nodes about incipient overloads before any congestion occurs (hence the "pre" part of "pre-congestion notification"). The level of marking allows decisions to be made about whether to admit or terminate PCN-flows. For more details, see [RFC5559].
事前輻輳通知（PCN）の目的は、Diffservドメイン内の非弾性フローのサービス品質（QoS）を、シンプルでスケーラブルで堅牢な方法で保護することです。 2つのメカニズムが使用されます。新しいフロー要求を許可するかブロックするかを決定するアドミッション制御と、異常な状況では、既存のフローの一部を終了するかどうかを決定するフロー終了。これを達成するために、PCNトラフィックの全体的なレートがPCNドメイン内のすべてのリンクで計測され、特定の構成されたレートを超えたときにPCNパケットが適切にマークされます。これらの構成されたレートはリンクのレートを下回るため、輻輳が発生する前に初期過負荷についてPCN境界ノードに通知されます（そのため、「事前輻輳通知」の「事前」部分）。マーキングのレベルにより、PCNフローを許可するか終了するかを決定できます。詳細については、[RFC5559]を参照してください。
This document describes an experimental edge-node behavior to implement PCN in a network. The experiment may be run in a network in which a substantial proportion of the traffic carried is in the form of inelastic flows and where admission control of micro-flows is applied at the edge. For the effects of PCN to be observable, the committed bandwidth (i.e., level of non-best-effort traffic) on at least some links of the network should be near or at link capacity. The amount of effort required to prepare the network for the experiment (see Section 5.1) may constrain the size of network to which it is applied. The purposes of the experiment are:
このドキュメントでは、ネットワークにPCNを実装するための実験的なエッジノードの動作について説明します。実験は、伝送されるトラフィックのかなりの部分が非弾性フローの形式であり、マイクロフローのアドミッション制御がエッジで適用されるネットワークで実行できます。 PCNの影響を観察できるようにするには、ネットワークの少なくとも一部のリンクの認定帯域幅（つまり、非ベストエフォートトラフィックのレベル）がリンク容量に近いか、リンク容量にある必要があります。実験のためにネットワークを準備するために必要な労力（セクション5.1を参照）は、それが適用されるネットワークのサイズを制限する場合があります。実験の目的は次のとおりです。
o to validate the specification of the CL edge behavior;
o CLエッジの動作の仕様を検証します。
o to evaluate the effectiveness of the CL edge behavior in preserving quality of service for admitted flows; and
o 許可されたフローのサービス品質の維持におけるCLエッジ動作の有効性を評価するため。そして
o to evaluate PCN's potential for reducing the amount of capital and operational costs in comparison to alternative methods of assuring quality of service.
o サービスの品質を保証する別の方法と比較して、資本および運用コストを削減するPCNの可能性を評価する。
For the first two objectives, the experiment should run long enough for the network to experience sharp peaks of traffic in at least some directions. It would also be desirable to observe PCN performance in the face of failures in the network. A period on the order of a month or two in busy season may be enough. The third objective is more difficult and could require observation over a period long enough for traffic demand to grow to the point where additional capacity must be provisioned at some points in the network.
最初の2つの目的では、ネットワークが少なくともいくつかの方向でトラフィックの鋭いピークを経験するのに十分な時間、実験を実行する必要があります。また、ネットワークで障害が発生した場合にPCNのパフォーマンスを観察することも望まれます。繁忙期には1〜2ヶ月程度の期間で十分かもしれません。 3番目の目的はより困難であり、ネットワークの一部のポイントで追加の容量をプロビジョニングする必要があるポイントまでトラフィックの需要が増大するのに十分な期間にわたって観察する必要があります。
Section 3 of this document specifies a detailed set of algorithms and procedures used to implement the PCN mechanisms for the CL mode of operation. Since the algorithms depend on specific metering and marking behavior at the interior nodes, it is also necessary to specify the assumptions made about PCN-interior-node behavior (Section 2). Finally, because PCN uses Diffserv codepoint (DSCP) values to carry its markings, a specification of PCN-boundary-node behavior must include the per-domain behavior (PDB) template specified in [RFC3086], filled out with the appropriate content (Section 4).
このドキュメントのセクション3では、CL動作モードのPCNメカニズムを実装するために使用されるアルゴリズムと手順の詳細なセットを指定しています。アルゴリズムは内部ノードでの特定の計測とマーキングの動作に依存するため、PCN内部ノードの動作（セクション2）に関する仮定を指定することも必要です。最後に、PCNはDiffservコードポイント（DSCP）値を使用してマーキングを実行するため、PCN境界ノードの動作の仕様には、[RFC3086]で指定されているドメインごとの動作（PDB）テンプレートを含め、適切なコンテンツ（セクション4）。
Note that the terms "block" or "terminate" actually translate to one or more of several possible courses of action, as discussed in Section 3.6 of [RFC5559]. The choice of which action to take for blocked or terminated flows is a matter of local policy.
「ブロック」または「終了」という用語は、[RFC5559]のセクション3.6で説明されているように、実際にはいくつかの可能な一連のアクションの1つ以上に変換されることに注意してください。ブロックされたフローまたは終了したフローに対して実行するアクションの選択は、ローカルポリシーの問題です。
A companion document [RFC6662] specifies the Single Marking (SM) PCN-boundary-node behavior. This document and [RFC6662] have a great deal of text in common. To simplify the task of the reader, the text in the present document that is specific to the CL PCN-boundary-node behavior is preceded by the phrase "[CL-specific]". A similar distinction for SM-specific text is made in [RFC6662].
関連ドキュメント[RFC6662]は、シングルマーキング（SM）PCN-boundary-node動作を指定しています。このドキュメントと[RFC6662]には、共通する多くのテキストがあります。読者のタスクを簡略化するために、CL PCN-boundary-node動作に固有の現在のドキュメントのテキストの前には、「[CL-specific]」という語句が付けられています。 SM固有のテキストに対する同様の区別は、[RFC6662]で行われます。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses the following terms defined in Section 2 of [RFC5559]:
このドキュメントでは、[RFC5559]のセクション2で定義されている次の用語を使用しています。
o PCN-domain
o PCNドメイン
o PCN-ingress-node
o PCN入力ノード
o PCN-egress-node
o ＰＣんーえｇれっｓーので
o PCN-interior-node
o ＰＣんーいんてりおｒーので
o PCN-boundary-node
o ＰＣんーぼうんだｒｙーので
o PCN-flow
o PCN-flow
o ingress-egress-aggregate
o 入力-出力-集約
o [CL-specific] PCN-threshold-rate
o [CL固有] PCNしきい値レート
o PCN-excess-rate
o PCN超過率
o PCN-admissible-rate
o PCN許容レート
o PCN-supportable-rate
o PCNサポート可能レート
o PCN-marked
o PCN市場
o [CL-specific] threshold-marked
o [CL固有]しきい値マーク
o excess-traffic-marked
o 過剰交通マーク
It also uses the terms PCN-traffic and PCN-packet, for which the definition is repeated from [RFC5559] because of their importance to the understanding of the text that follows:
また、PCN-trafficおよびPCN-packetという用語も使用します。これらの定義は、[RFC5559]から繰り返されています。これは、続くテキストの理解に重要であるためです。
PCN-traffic, PCN-packets, PCN-BA A PCN-domain carries traffic of different Diffserv behavior aggregates (BAs) [RFC2474]. The PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the corresponding packets are PCN-packets. The same network will carry traffic of other Diffserv BAs. The PCN-BA is distinguished by a combination of the Diffserv codepoint and the ECN field.
PCNトラフィック、PCNパケット、PCN-BA PCNドメインは、さまざまなDiffserv動作集約（BA）のトラフィックを伝送します[RFC2474]。 PCN-BAはPCNメカニズムを使用してPCNトラフィックを伝送し、対応するパケットはPCNパケットです。同じネットワークが他のDiffserv BAのトラフィックを伝送します。 PCN-BAは、DiffservコードポイントとECNフィールドの組み合わせによって区別されます。
This document uses the following terms from [RFC5670]:
このドキュメントでは、[RFC5670]の次の用語を使用しています。
o [CL-specific] threshold-meter;
o [CL固有]しきい値メーター。
o excess-traffic-meter.
o 超過トラフィックメーター。
To complete the list of borrowed terms, this document reuses the following terms and abbreviations defined in Section 2 of [RFC6660]:
借用された用語のリストを完成させるために、このドキュメントでは、[RFC6660]のセクション2で定義されている次の用語と略語を再利用します。
o not-PCN codepoint;
o 非PCNコードポイント。
o not-marked (NM) codepoint;
o マークされていない（NM）コードポイント。
o [CL-specific] threshold-marked (ThM) codepoint;
o [CL固有]しきい値マーク（ThM）コードポイント。
o excess-traffic-marked (ETM) codepoint.
o 超過トラフィックマーク（ETM）コードポイント。
This document defines the following additional terms:
このドキュメントでは、次の追加の用語を定義しています。
Decision Point The node that makes the decision about which flows to admit and to terminate. In a given network deployment, this can be the PCN-ingress-node or a centralized control node. In either case, the PCN-ingress-node is the point where the decisions are enforced.
Decision Point許可するフローと終了するフローを決定するノード。特定のネットワーク配置では、これはPCN入力ノードまたは集中制御ノードにすることができます。どちらの場合も、PCN-ingress-nodeが決定が実施されるポイントです。
NM-rate The rate of not-marked PCN-traffic received at a PCN-egress-node for a given ingress-egress-aggregate in octets per second. For further details, see Section 3.2.1.
NM-rate特定のingress-egress-aggregateのPCN-egress-nodeで受信された、マークされていないPCNトラフィックのオクテット/秒のレート。詳細については、セクション3.2.1を参照してください。
[CL-specific] ThM-rate The rate of threshold-marked PCN-traffic received at a PCN-egress-node for a given ingress-egress-aggregate in octets per second. For further details, see Section 3.2.1.
[CL固有] ThM-rate指定されたingress-egress-aggregateのPCN-egress-nodeで受信された、しきい値でマークされたPCNトラフィックのオクテット/秒のレート。詳細については、セクション3.2.1を参照してください。
ETM-rate The rate of excess-traffic-marked PCN-traffic received at a PCN-egress-node for a given ingress-egress-aggregate in octets per second. For further details, see Section 3.2.1.
ETM-rate指定されたingress-egress-aggregateのPCN-egress-nodeで受信された超過トラフィックマーク付きPCN-trafficのオクテット/秒のレート。詳細については、セクション3.2.1を参照してください。
PCN-sent-rate The rate of PCN-traffic received at a PCN-ingress-node and destined for a given ingress-egress-aggregate in octets per second. For further details, see Section 3.4.
PCN-sent-rate PCN-ingress-nodeで受信され、特定のingress-egress-aggregateを宛先とするPCNトラフィックのオクテット/秒のレート。詳細については、セクション3.4を参照してください。
Congestion level estimate (CLE) The ratio of PCN-marked to total PCN-traffic (measured in octets) received for a given ingress-egress-aggregate during a given measurement period. The CLE is used to derive the PCN-admission-state (Section 3.3.1) and is also used by the report suppression procedure (Section 3.2.3) if report suppression is activated.
輻輳レベル推定（CLE）特定の測定期間中に特定の入力-出力-集約で受信されたPCNトラフィックの合計（オクテットで測定）に対するPCNマークの比率。 CLEはPCN-admission-state（セクション3.3.1）を導出するために使用され、レポート抑制がアクティブ化されている場合はレポート抑制手順（セクション3.2.3）でも使用されます。
PCN-admission-state The state ("admit" or "block") derived by the Decision Point for a given ingress-egress-aggregate based on statistics about PCN-packet marking. The Decision Point decides to admit or block new flows offered to the aggregate based on the current value of the PCN-admission-state. For further details, see Section 3.3.1.
PCN-admission-state PCNパケットマーキングに関する統計に基づいて、特定の入力-出力-集約の決定ポイントによって導出された状態（「許可」または「ブロック」）。ディシジョンポイントは、PCN-admission-stateの現在の値に基づいて、集約に提供される新しいフローを許可するかブロックするかを決定します。詳細については、セクション3.3.1を参照してください。
Sustainable aggregate rate (SAR) The estimated maximum rate of PCN-traffic that can be carried in a given ingress-egress-aggregate at a given moment without risking degradation of quality of service for the admitted flows. The intention is that if the PCN-sent-rate of every ingress-egress-aggregate passing through a given link is limited to its sustainable aggregate rate, the total rate of PCN-traffic flowing through the link will be limited to the PCN-supportable-rate for that link. An estimate of the sustainable aggregate rate for a given ingress-egress-aggregate is derived as part of the flow termination procedure and is used to determine how much PCN-traffic needs to be terminated. For further details, see Section 3.3.2.
Sustainable Aggregate Rate（SAR）許可されたフローのサービス品質の低下の危険を冒すことなく、特定の瞬間に特定のIngress-Egress-Aggregateで伝送できるPCNトラフィックの推定最大レート。意図は、特定のリンクを通過するすべてのイングレス-エグレス-アグリゲートのPCN-sent-rateがその持続可能なアグリゲートレートに制限されている場合、リンクを通過するPCNトラフィックの合計レートは、PCN-supportableに制限されることです。 -そのリンクのレート。特定の入力-出力-集約の持続可能な集約レートの推定値は、フロー終了手順の一部として導出され、終了する必要があるPCNトラフィックの量を決定するために使用されます。詳細については、セクション3.3.2を参照してください。
CLE-reporting-threshold A configurable value against which the CLE is compared as part of the report suppression procedure. For further details, see Section 3.2.3.
CLE-reporting-threshold CLEがレポート抑制手順の一部として比較される構成可能な値。詳細については、セクション3.2.3を参照してください。
CLE-limit A configurable value against which the CLE is compared to determine the PCN-admission-state for a given ingress-egress-aggregate. For further details, see Section 3.3.1.
CLE-limit CLEと比較して、特定の入力-出力-集約のPCN-admission-stateを決定する構成可能な値。詳細については、セクション3.3.1を参照してください。
T_meas A configurable time interval that defines the measurement period over which the PCN-egress-node collects statistics relating to PCN-traffic marking. At the end of the interval, the PCN-egress-node calculates the values NM-rate, [CL-specific] ThM-rate, and ETM-rate as defined above and sends a report to the Decision Point, subject to the operation of the report suppression feature. For further details, see Section 3.2.
T_meas PCN出口ノードがPCNトラフィックマーキングに関連する統計を収集する測定期間を定義する構成可能な時間間隔。間隔の最後に、PCN-egress-nodeは、上記で定義された値NM-rate、[CL-specific] ThM-rate、およびETM-rateを計算し、以下の操作に従ってレポートを決定ポイントに送信しますレポート抑制機能。詳細については、セクション3.2を参照してください。
T_maxsuppress A configurable time interval after which the PCN-egress-node MUST send a report to the Decision Point for a given ingress-egress-aggregate regardless of the most recent values of the CLE. This mechanism provides the Decision Point with a periodic confirmation of liveness when report suppression is activated. For further details, see Section 3.2.3.
T_maxsuppress PCN-egress-nodeが、CLEの最新の値に関係なく、特定のingress-egress-aggregateのレポートをDecision Pointに送信する必要がある設定可能な時間間隔。このメカニズムは、レポート抑制がアクティブ化されているときに、Decision Pointに活性の定期的な確認を提供します。詳細については、セクション3.2.3を参照してください。
T_fail An interval after which the Decision Point concludes that communication from a given PCN-egress-node has failed if it has received no reports from the PCN-egress-node during that interval. For further details, see Section 3.3.3.
T_failその間隔の間にPCN-egress-nodeからのレポートを受信しなかった場合、特定のPCN-egress-nodeからの通信が失敗したとDecision Pointが結論付ける間隔。詳細については、セクション3.3.3を参照してください。
T_crit A configurable interval used in the calculation of T_fail. For further details, see Section 3.3.3.
T_crit T_failの計算に使用される構成可能な間隔。詳細については、セクション3.3.3を参照してください。
This section describes the assumed behavior for PCN-interior-nodes in the PCN-domain. The CL mode of operation assumes that:
このセクションでは、PCNドメインのPCN内部ノードの想定される動作について説明します。 CL動作モードは、以下を前提としています。
o PCN-interior-nodes perform both threshold-marking and excess-traffic-marking of PCN-packets, according to the rules specified in [RFC5670];
o PCN-interior-nodesは、[RFC5670]で指定されたルールに従って、PCNパケットのしきい値マーキングと過剰トラフィックマーキングの両方を実行します。
o For IP transport, threshold-marking of PCN-packets uses the ThM codepoint defined in [RFC6660]; for MPLS transport, an equivalent marking is used as discussed in Appendix C of [RFC6660];
o IPトランスポートの場合、PCNパケットのしきい値マーキングは、[RFC6660]で定義されているThMコードポイントを使用します。 MPLSトランスポートの場合、[RFC6660]の付録Cで説明されているように、同等のマーキングが使用されます。
o For IP transport, excess-traffic-marking of PCN-packets uses the ETM codepoint defined in [RFC6660]; for MPLS transport, an equivalent marking is used as discussed in Appendix C of [RFC6660];
o IPトランスポートの場合、PCNパケットの過剰トラフィックマーキングは、[RFC6660]で定義されているETMコードポイントを使用します。 MPLSトランスポートの場合、[RFC6660]の付録Cで説明されているように、同等のマーキングが使用されます。
o On each link, the reference rate for the threshold-meter is configured to be equal to the PCN-admissible-rate for the link;
o 各リンクで、しきい値メーターの参照レートは、リンクのPCN許容レートと等しくなるように構成されます。
o On each link, the reference rate for the excess-traffic-meter is configured to be equal to the PCN-supportable-rate for the link;
o 各リンクで、超過トラフィックメーターの参照レートは、リンクのPCNサポート可能レートと等しくなるように設定されます。
o The set of valid codepoint transitions is as shown in Sections 5.2.1 and 5.2.2 of [RFC6660].
o 有効なコードポイント遷移のセットは、[RFC6660]のセクション5.2.1および5.2.2に示すとおりです。
This section describes the behavior of the PCN-ingress-node, PCN-egress-node, and the Decision Point (which MAY be collocated with the PCN-ingress-node).
このセクションでは、PCN-ingress-node、PCN-egress-node、およびDecision Point（PCN-ingress-nodeと同じ場所に配置される場合があります）の動作について説明します。
The PCN-egress-node collects the rates of not-marked, [CL-specific] threshold-marked, and excess-traffic-marked PCN-traffic for each ingress-egress-aggregate and reports them to the Decision Point. [CL-specific] It MAY also identify and report PCN-flows that have experienced excess-traffic-marking. For a detailed description, see Section 3.2.
PCN-egress-nodeは、各ingress-egress-aggregateについて、マークされていない、[CL固有]しきい値がマークされた、および超過トラフィックがマークされたPCNトラフィックのレートを収集し、それらをDecision Pointに報告します。 [CL固有]また、過剰なトラフィックマーキングが発生したPCNフローを識別して報告する場合があります。詳細については、セクション3.2を参照してください。
The PCN-ingress-node enforces flow admission and termination decisions. It also reports the rate of PCN-traffic sent to a given ingress-egress-aggregate when requested by the Decision Point. For details, see Section 3.4.
PCN-ingress-nodeは、フローアドミッションと終了の決定を実施します。また、ディシジョンポイントによって要求されたときに、指定された入力-出力-集約に送信されるPCNトラフィックのレートも報告します。詳細については、3.4項を参照してください。
Finally, the Decision Point makes flow admission decisions and selects flows to terminate based on the information provided by the PCN-ingress-node and PCN-egress-node for a given ingress-egress-aggregate. For details, see Section 3.3.
最後に、Decision Pointはフローアドミッションの決定を行い、特定のingress-egress-aggregateのPCN-ingress-nodeとPCN-egress-nodeによって提供される情報に基づいて終了するフローを選択します。詳細については、3.3項を参照してください。
Specification of a signaling protocol to report rates to the Decision Point is out of scope of this document. If the PCN-ingress-node is chosen as the Decision Point, [RSVP-PCN] specifies an appropriate signaling protocol.
レートをディシジョンポイントに報告するためのシグナリングプロトコルの仕様は、このドキュメントの範囲外です。 PCN-ingress-nodeが決定点として選択されている場合、[RSVP-PCN]は適切なシグナリングプロトコルを指定します。
Section 5.1.2 describes how to derive the filters by means of which PCN-ingress-nodes and PCN-egress-nodes are able to classify incoming packets into ingress-egress-aggregates.
セクション5.1.2では、PCN-ingress-nodeとPCN-egress-nodeが着信パケットをingress-egress-aggregatesに分類できるようにすることでフィルターを導出する方法について説明します。
The PCN-egress-node needs to meter the PCN-traffic it receives in order to calculate the following rates for each ingress-egress-aggregate passing through it. These rates SHOULD be calculated at the end of each measurement period based on the PCN-traffic observed during that measurement period. The duration of a measurement period is equal to the configurable value T_meas. For further information, see Section 3.5.
PCN-egress-nodeは、通過する各ingress-egress-aggregateの以下のレートを計算するために、受信するPCNトラフィックを測定する必要があります。これらのレートは、各測定期間の終わりに、その測定期間中に観測されたPCNトラフィックに基づいて計算する必要があります（SHOULD）。測定期間の継続時間は、構成可能な値T_measと同じです。詳細については、セクション3.5を参照してください。
o NM-rate: octets per second of PCN-traffic in PCN-packets that are not-marked (i.e., marked with the NM codepoint);
o NM-rate：マークされていない（つまり、NMコードポイントでマークされている）PCNパケット内のPCNトラフィックの1秒あたりのオクテット数。
o [CL-specific] ThM-rate: octets per second of PCN-traffic in PCN-packets that are threshold-marked (i.e., marked with the ThM codepoint);
o [CL固有] ThMレート：しきい値でマークされた（つまり、ThMコードポイントでマークされた）PCNパケット内のPCNトラフィックのオクテット/秒。
o ETM-rate: octets per second of PCN-traffic in PCN-packets that are excess-traffic-marked (i.e., marked with the ETM codepoint).
o ETMレート：超過トラフィックがマークされている（つまり、ETMコードポイントでマークされている）PCNパケット内のPCNトラフィックの1秒あたりのオクテット。
Note: metering the PCN-traffic continuously and using equal-length measurement intervals minimizes the statistical variance introduced by the measurement process itself. On the other hand, the operation of PCN is not affected if the starting and ending times of the measurement intervals for different ingress-egress-aggregates are different.
注：PCNトラフィックを継続的に測定し、同じ長さの測定間隔を使用すると、測定プロセス自体によって導入される統計的変動を最小限に抑えることができます。一方、異なる入力-出力-集約の測定間隔の開始時刻と終了時刻が異なる場合、PCNの動作は影響を受けません。
[CL-specific] As a configurable option, the PCN-egress-node MAY record flow identifiers of the PCN-flows for which excess-traffic-marked packets have been observed during this measurement interval. If this set is large (e.g., more than 20 flows), the PCN-egress-node MAY record only the most recently excess-traffic-marked PCN-flow identifiers rather than the complete set.
[CL固有]構成可能なオプションとして、PCN-egress-nodeは、この測定間隔中に過剰なトラフィックマークが付けられたパケットが観測されたPCNフローのフロー識別子を記録できます（MAY）。このセットが大きい場合（たとえば、20を超えるフロー）、PCN-egress-nodeは、完全なセットではなく、最新の超過トラフィックマーク付きのPCNフロー識別子のみを記録できます（MAY）。
These can be used by the Decision Point when it selects flows for termination. In networks using multipath routing, it is possible that congestion is not occurring on all paths carrying a given ingress-egress-aggregate. Assuming that specific PCN-flows are routed via specific paths, identifying the PCN-flows that are experiencing excess-traffic-marking helps to avoid termination of PCN-flows not contributing to congestion.
これらは、終了するフローを選択するときに、ディシジョンポイントで使用できます。マルチパスルーティングを使用するネットワークでは、特定の入力-出力-集約を伝送するすべてのパスで輻輳が発生していない可能性があります。特定のPCNフローが特定のパスを介してルーティングされると仮定して、過剰なトラフィックマーキングが発生しているPCNフローを特定すると、輻輳の原因ではないPCNフローの終了を回避できます。
Unless the report suppression option described in Section 3.2.3 is activated, the PCN-egress-node MUST report the latest values of NM-rate, [CL-specific] ThM-rate, and ETM-rate to the Decision Point each time that it calculates them.
セクション3.2.3で説明されているレポート抑制オプションがアクティブ化されていない限り、PCN-egress-nodeは、そのたびに決定ポイントにNM-rate、[CL-specific] ThM-rate、およびETM-rateの最新の値を報告する必要がありますそれはそれらを計算します。
[CL-specific] If the PCN-egress-node recorded a set of flow identifiers of PCN-flows for which excess-traffic-marking was observed in the most recent measurement interval, then it MUST also include these identifiers in the report.
[CL固有] PCN-egress-nodeが、最新の測定間隔で超過トラフィックマーキングが観察されたPCNフローのフロー識別子のセットを記録した場合、これらの識別子もレポートに含める必要があります。
Report suppression MUST be provided as a configurable option, along with two configurable parameters, the CLE-reporting-threshold and the maximum report suppression interval T_maxsuppress. The default value of the CLE-reporting-threshold is zero. The CLE-reporting-threshold MUST NOT exceed the CLE-limit configured at the Decision Point. For further information on T_maxsuppress, see Section 3.5.
レポート抑制は、CLE-reporting-thresholdと最大レポート抑制間隔T_maxsuppressの2つの設定可能なパラメーターとともに、設定可能なオプションとして提供する必要があります。 CLE-reporting-thresholdのデフォルト値はゼロです。 CLE-reporting-thresholdは、決定点で構成されたCLE制限を超えてはなりません（MUST NOT）。 T_maxsuppressの詳細については、セクション3.5を参照してください。
If the report suppression option is enabled, the PCN-egress-node MUST apply the following procedure to decide whether to send a report to the Decision Point, rather than sending a report automatically at the end of each measurement interval.
レポート抑制オプションが有効になっている場合、PCN-egress-nodeは次の手順を適用して、各測定間隔の終わりにレポートを自動的に送信するのではなく、決定点にレポートを送信するかどうかを決定する必要があります。
1. As well as the quantities NM-rate, [CL-specific] ThM-rate, and ETM-rate, the PCN-egress-node MUST calculate the congestion level estimate (CLE) for each measurement interval. The CLE is computed as:
1. NMレート、[CL固有] ThMレート、およびETMレートの量に加えて、PCN-egress-nodeは各測定間隔の輻輳レベル推定（CLE）を計算する必要があります。 CLEは次のように計算されます。
[CL-specific]
CLE = (ThM-rate + ETM-rate) / (NM-rate + ThM-rate + ETM-rate)
if any PCN-traffic was observed, or CLE = 0 if all the rates are zero.
PCNトラフィックが観察された場合、またはすべてのレートがゼロの場合CLE = 0。
2. If the CLE calculated for the latest measurement interval is greater than the CLE-reporting-threshold and/or the CLE calculated for the immediately previous interval was greater than the CLE-reporting-threshold, then the PCN-egress-node MUST send a report to the Decision Point. The contents of the report are described below.
2. 最新の測定間隔に対して計算されたCLEがCLE-reporting-thresholdより大きいか、直前の間隔に対して計算されたCLEがCLE-reporting-thresholdより大きい場合、PCN-egress-nodeはレポートを送信する必要があります決定ポイントへ。レポートの内容は以下のとおりです。
The reason for taking into account the CLE of the previous interval is to ensure that the Decision Point gets immediate feedback if the CLE has dropped below CLE-reporting-threshold. This is essential if the Decision Point is running the flow termination procedure and observing whether (further) flow termination is needed. See Section 3.3.2.
前の間隔のCLEを考慮する理由は、CLEがCLE-reporting-thresholdを下回った場合に決定点が即座にフィードバックを受け取るようにするためです。ディシジョンポイントがフロー終了手順を実行していて、（さらに）フロー終了が必要かどうかを監視している場合、これは不可欠です。セクション3.3.2を参照してください。
3. If an interval T_maxsuppress has elapsed since the last report was sent to the Decision Point, then the PCN-egress-node MUST send a report to the Decision Point regardless of the CLE value.
3. 最後のレポートがディシジョンポイントに送信されてから間隔T_maxsuppressが経過した場合、PCN-egress-nodeはCLE値に関係なくレポートをディシジョンポイントに送信する必要があります。
4. If neither of the preceding conditions holds, the PCN-egress-node MUST NOT send a report for the latest measurement interval.
4. 上記のいずれの条件も満たさない場合、PCN-egress-nodeは最新の測定間隔のレポートを送信してはなりません（MUST NOT）。
Each report sent to the Decision Point when report suppression has been activated MUST contain the values of NM-rate, [CL-specific] ThM-rate, ETM-rate, and CLE that were calculated for the most recent measurement interval. [CL-specific] If the PCN-egress-node recorded a set of flow identifiers of PCN-flows for which excess-traffic-marking was observed in the most recent measurement interval, then it MUST also include these identifiers in the report.
レポート抑制がアクティブ化されているときにディシジョンポイントに送信される各レポートには、最新の測定間隔に対して計算されたNMレート、[CL固有] ThMレート、ETMレート、およびCLEの値が含まれている必要があります。 [CL固有] PCN-egress-nodeが、最新の測定間隔で超過トラフィックマーキングが観察されたPCNフローのフロー識別子のセットを記録した場合、これらの識別子もレポートに含める必要があります。
The above procedure ensures that at least one report is sent per interval (T_maxsuppress + T_meas). This demonstrates to the Decision Point that both the PCN-egress-node and the communication path between that node and the Decision Point are in operation.
上記の手順により、間隔ごとに少なくとも1つのレポートが送信されます（T_maxsuppress + T_meas）。これは、PCN-egress-nodeと、そのノードとDecision Pointの間の通信パスの両方が動作していることをDecision Pointに示しています。
Operators can choose to use PCN procedures just for flow admission, or just for flow termination, or for both. Decision Points MUST implement both mechanisms, but configurable options MUST be provided to activate or deactivate PCN-based flow admission and flow termination independently of each other at a given Decision Point.
オペレーターは、フローアドミッションのみ、またはフロー終了のみ、またはその両方にPCNプロシージャを使用することを選択できます。デシジョンポイントは両方のメカニズムを実装する必要がありますが、PCNベースのフローアドミッションとフロー終了を特定のデシジョンポイントで互いに独立してアクティブまたは非アクティブにするための構成可能なオプションを提供する必要があります。
If PCN-based flow termination is enabled but PCN-based flow admission is not, flow termination operates as specified in this document.
PCNベースのフロー終了が有効になっているが、PCNベースのフローアドミッションが有効になっていない場合、フロー終了はこのドキュメントの指定どおりに動作します。
Logically, some other system of flow admission control is in operation, but the description of such a system is out of scope of this document and depends on local arrangements.
論理的には、フローアドミッション制御の他のシステムが動作していますが、そのようなシステムの説明はこのドキュメントの範囲外であり、ローカルの配置に依存します。
The Decision Point determines the PCN-admission-state for a given ingress-egress-aggregate each time it receives a report from the egress node. It makes this determination on the basis of the congestion level estimate (CLE). If the CLE is provided in the egress-node report, the Decision Point SHOULD use the reported value. If the CLE was not provided in the report, the Decision Point MUST calculate it based on the other values provided in the report, using the formula:
Decision Pointは、出力ノードからレポートを受信するたびに、特定のingress-egress-aggregateのPCN-admission-stateを決定します。輻輳レベルの推定（CLE）に基づいてこの決定を行います。 CLEが出力ノードレポートで提供されている場合、Decision Pointは報告された値を使用する必要があります（SHOULD）。 CLEがレポートで提供されなかった場合、ディシジョンポイントは、次の式を使用して、レポートで提供された他の値に基づいて計算する必要があります。
[CL-specific]
CLE = (ThM-rate + ETM-rate) / (NM-rate + ThM-rate + ETM-rate)
if any PCN-traffic was observed, or CLE = 0 if all the rates are zero.
PCNトラフィックが観察された場合、またはすべてのレートがゼロの場合CLE = 0。
The Decision Point MUST compare the reported or calculated CLE to a configurable value, the CLE-limit. If the CLE is less than the CLE-limit, the PCN-admission-state for that aggregate MUST be set to "admit"; otherwise, it MUST be set to "block".
Decision Pointは、報告または計算されたCLEを構成可能な値であるCLE-limitと比較する必要があります。 CLEがCLE制限よりも小さい場合、その集約のPCN-admission-stateを「許可」に設定する必要があります。それ以外の場合は、「block」に設定する必要があります。
If the PCN-admission-state for a given ingress-egress-aggregate is "admit", the Decision Point SHOULD allow new flows to be admitted to that aggregate. If the PCN-admission-state for a given ingress-egress-aggregate is "block", the Decision Point SHOULD NOT allow new flows to be admitted to that aggregate. These actions MAY be modified by policy in specific cases, but such policy intervention risks defeating the purpose of using PCN.
特定のingress-egress-aggregateのPCN-admission-stateが「admit」の場合、Decision Pointは新しいフローがそのアグリゲートに許可されることを許可する必要があります（SHOULD）。特定のingress-egress-aggregateのPCN-admission-stateが「block」の場合、Decision Pointは新しいフローがその集合体に許可されることを許可してはいけません（SHOULD NOT）。これらのアクションは特定のケースでポリシーによって変更される場合がありますが、そのようなポリシー介入はPCNを使用する目的を無効にする危険性があります。
A performance study of this admission control method is presented in [MeLe12].
このアドミッションコントロール方法のパフォーマンス調査は、[MeLe12]に示されています。
[CL-specific] When the report from the PCN-egress-node includes a non-zero value of the ETM-rate for some ingress-egress-aggregate, the Decision Point MUST request the PCN-ingress-node to provide an estimate of the rate (PCN-sent-rate) at which the PCN-ingress-node is receiving PCN-traffic that is destined for the given ingress-egress-aggregate.
[CL固有] PCN-egress-nodeからのレポートに一部のingress-egress-aggregateのETMレートのゼロ以外の値が含まれている場合、Decision PointはPCN-ingress-nodeに見積もりの提供を要求する必要がありますPCN-ingress-nodeが特定のingress-egress-aggregate宛てのPCNトラフィックを受信しているレート（PCN-sent-rate）。
If the Decision Point is collocated with the PCN-ingress-node, the request and response are internal operations.
Decision PointがPCN-ingress-nodeと連結されている場合、要求と応答は内部操作です。
The Decision Point MUST then wait, for both the requested rate from the PCN-ingress-node and the next report from the PCN-egress-node for the ingress-egress-aggregate concerned. If this next egress-node report also includes a non-zero value for the ETM-rate, the Decision Point MUST determine the amount of PCN-traffic to terminate using the following steps: 1. [CL-specific] The sustainable aggregate rate (SAR) for the given ingress-egress-aggregate is estimated by the sum:
次に、ディシジョンポイントは、PCN-ingress-nodeからの要求されたレートと、関係するingress-egress-aggregateに関するPCN-egress-nodeからの次のレポートの両方を待機する必要があります。この次の出力ノードレポートにETMレートのゼロ以外の値も含まれている場合、ディシジョンポイントは、次の手順を使用して終了するPCNトラフィックの量を決定する必要があります。1. [CL固有]持続可能な総レート（ SAR）は、指定されたingress-egress-aggregateの合計で推定されます。
SAR = NM-rate + ThM-rate
SAR = NMレート+ ThMレート
for the latest reported interval.
最新の報告間隔。
2. The amount of traffic to be terminated is the difference:
2. 終了するトラフィックの量が異なります。
PCN-sent-rate - SAR,
PCN送信レート-SAR、
where PCN-sent-rate is the value provided by the PCN-ingress-node.
ここで、PCN-sent-rateは、PCN-ingress-nodeによって提供される値です。
See Section 3.3.3 for a discussion of appropriate actions if the Decision Point fails to receive a timely response to its request for the PCN-sent-rate.
決定ポイントがPCN送信レートの要求に対するタイムリーな応答を受信できない場合の適切なアクションについては、セクション3.3.3を参照してください。
If the difference calculated in the second step is positive (traffic rate to be terminated), the Decision Point SHOULD select PCN-flows for termination. To that end, the Decision Point MAY use upper rate limits for individual PCN-flows (known, e.g., from resource signaling used to establish the PCN-flows) and select a set of PCN-flows whose sum of upper rate limits is up to the traffic rate to be terminated. Then, these PCN-flows are terminated. The use of upper limits on PCN-flow rates avoids over-termination.
2番目のステップで計算された差が正（終了するトラフィックレート）である場合、決定ポイントは終了するPCNフローを選択する必要があります（SHOULD）。そのために、ディシジョンポイントは個々のPCNフローに上限レートを使用でき（たとえば、PCNフローの確立に使用されるリソースシグナリングから既知）、上限レートの合計が最大であるPCNフローのセットを選択できます（MAY）。終了するトラフィックレート。次に、これらのPCNフローは終了します。 PCNフローレートの上限を使用すると、過剰終了を回避できます。
Termination may be continuously needed after consecutive measurement intervals for various reasons, e.g., if the used upper rate limits overestimate the actual flow rates. For such cases it is RECOMMENDED that enough time elapses between successive termination events to allow the effects of previous termination events to be reflected in the measurements upon which the termination decisions are based; otherwise, over-termination may occur. See [Satoh10] and Sections 4.2 and 4.3 of [MeLe10].
使用された上限レートが実際の流量を過大評価している場合など、さまざまな理由により、連続的な測定間隔の後に終了が継続的に必要になる場合があります。このような場合、連続する終了イベントの間に十分な時間が経過して、以前の終了イベントの影響が終了決定の基になる測定に反映されるようにすることをお勧めします。そうしないと、過剰終了が発生する可能性があります。 [Satoh10]および[MeLe10]のセクション4.2および4.3を参照してください。
In general, the selection of flows for termination MAY be guided by policy. [CL-specific] If the egress node has supplied a list of identifiers of PCN-flows that experienced excess-traffic-marking (Section 3.2), the Decision Point SHOULD first consider terminating PCN-flows in that list.
一般に、終了のためのフローの選択はポリシーによって導かれる場合があります。 [CL固有]出力ノードが過剰なトラフィックマーキング（セクション3.2）を経験したPCNフローの識別子のリストを提供した場合、決定ポイントは最初にそのリスト内のPCNフローの終了を検討する必要があります（SHOULD）。
The Decision Point SHOULD log each round of termination as described in Section 5.2.1.2.
決定ポイントは、セクション5.2.1.2で説明されているように、終了の各ラウンドを記録する必要があります（SHOULD）。
The Decision Point SHOULD start a timer t_recvFail when it receives a report from the PCN-egress-node. t_recvFail is reset each time a new report is received from the PCN-egress-node. t_recvFail expires if it reaches the value T_fail. T_fail is calculated according to the following logic:
Decision Pointは、PCN-egress-nodeからレポートを受信すると、タイマーt_recvFailを開始する必要があります（SHOULD）。 t_recvFailは、PCN-egress-nodeから新しいレポートを受信するたびにリセットされます。 t_recvFailは、値T_failに達すると期限切れになります。 T_failは、次のロジックに従って計算されます。
a. T_fail = the configurable duration T_crit, if report suppression is not deployed;
a. T_fail =レポート抑制が展開されていない場合、構成可能な期間T_crit。
b. T_fail = T_crit also if report suppression is deployed and the last report received from the PCN-egress-node contained a CLE value greater than CLE-reporting-threshold (Section 3.2.3);
b. T_fail = T_critは、レポート抑制が展開され、PCN-egress-nodeから受信した最後のレポートに、CLE-reporting-threshold（セクション3.2.3）より大きいCLE値が含まれていた場合も同様です。
c. T_fail = 3 * T_maxsuppress (Section 3.2.3) if report suppression is deployed and the last report received from the PCN-egress-node contained a CLE value less than or equal to CLE-reporting-threshold.
c. T_fail = 3 * T_maxsuppress（セクション3.2.3）。レポート抑制が展開され、PCN-egress-nodeから受信した最後のレポートに、CLE-reporting-threshold以下のCLE値が含まれていた場合。
If timer t_recvFail expires for a given PCN-egress-node, the Decision Point SHOULD notify management. A log format is defined for that purpose in Section 5.2.1.1. Other actions depend on local policy, but MAY include blocking of new flows destined for the PCN-egress-node concerned until another report is received from it. Termination of already admitted flows is also possible, but could be triggered by "Destination unreachable" messages received at the PCN-ingress-node.
タイマーt_recvFailが特定のPCN-egress-nodeで期限切れになると、Decision Pointは管理に通知する必要があります（SHOULD）。ログフォーマットは、セクション5.2.1.1でその目的のために定義されています。他のアクションはローカルポリシーに依存しますが、別のレポートが受信されるまで、関係するPCN-egress-node宛ての新しいフローのブロックを含めることができます。すでに許可されたフローの終了も可能ですが、PCN-ingress-nodeで受信された「Destination unreachable」メッセージによってトリガーされる可能性があります。
If a centralized Decision Point sends a request for the estimated value of PCN-sent-rate to a given PCN-ingress-node and fails to receive a response in a reasonable amount of time, the Decision Point SHOULD repeat the request once. [CL-specific] While waiting after sending this second request, the Decision Point MAY begin selecting flows to terminate, using ETM-rate as an estimate of the amount of traffic to be terminated in place of the quantity specified in Section 3.3.2:
一元化されたディシジョンポイントが、PCN-sent-rateの推定値の要求を特定のPCN-ingress-nodeに送信し、妥当な時間内に応答を受信できない場合、ディシジョンポイントは要求を1回繰り返す必要があります（SHOULD）。 [CL固有]この2番目のリクエストを送信してから待機している間、ディシジョンポイントは、セクション3.3.2で指定された量の代わりにETMレートを終了するトラフィック量の見積もりとして使用して、終了するフローの選択を開始できます（MAY）。
PCN-sent-rate - SAR
PCN送信レート-SAR
Because ETM-rate will over-estimate the amount of traffic to be terminated due to dropping of PCN-packets by interior nodes, the Decision Point SHOULD terminate less than the full amount ETM-rate in the first pass and recalculate the additional amount to terminate in additional passes based on subsequent reports from the PCN-egress-node. If the second request to the PCN-ingress-node also fails, the Decision Point MUST select flows to terminate based on the ETM-rate approximation as just described and SHOULD notify management. The log format described in Section 5.2.1.1 is also suitable for this purpose.
内部ノードによるPCNパケットのドロップが原因でETMレートが終了するトラフィックの量を過大評価するため、Decision Pointは最初のパスでETMレートの全量よりも少なく終了し、終了する追加の量を再計算する必要があります（SHOULD） PCN-egress-nodeからの後続のレポートに基づく追加のパス。 PCN-ingress-nodeへの2番目の要求も失敗した場合、Decision Pointは、前述のETMレート概算に基づいて終了するフローを選択する必要があり、管理に通知する必要があります（SHOULD）。セクション5.2.1.1で説明されているログ形式も、この目的に適しています。
The response timer t_sndFail with upper bound T_crit is specified in Section 3.5. The use of T_crit is an approximation. A more precise limit would be on the order of two round-trip times, plus an allowance for processing at each end, plus an allowance for variance in these values.
上限T_critを持つ応答タイマーt_sndFailは、セクション3.5で指定されています。 T_critの使用は概算です。より正確な制限は、およそ2つの往復時間に加えて、両端での処理の許容値に加えて、これらの値の変動の許容値になります。
See Section 3.5 for suggested values of the configurable durations T_crit and T_maxsuppress.
構成可能な期間T_critおよびT_maxsuppressの推奨値については、セクション3.5を参照してください。
The PCN-ingress-node MUST provide the estimated current rate of PCN-traffic received at that node and destined for a given ingress-egress-aggregate in octets per second (the PCN-sent-rate) when the Decision Point requests it. The way this rate estimate is derived is a matter of implementation.
PCN-ingress-nodeは、そのノードで受信され、Decision Pointが要求したときに、オクテット/秒（PCN-sent-rate）で指定されたingress-egress-aggregate宛のPCNトラフィックの推定現在のレートを提供する必要があります。このレート推定値の導出方法は、実装の問題です。
For example, the rate that the PCN-ingress-node supplies can be based on a quick sample taken at the time the information is required.
たとえば、PCN入力ノードが供給するレートは、情報が必要なときに取得された迅速なサンプルに基づくことができます。
Here is a summary of the timers used in the procedures just described:
以下は、今説明した手順で使用されるタイマーの要約です。
t_meas
t_meas
Where used: PCN-egress-node.
使用場所：PCN-egress-node。
Used in procedure: data collection (Section 3.2.1).
手順で使用：データ収集（セクション3.2.1）。
Incidence: one per ingress-egress-aggregate.
発生率：ingress-egress-aggregateごとに1つ。
Reset: immediately on expiry.
リセット：期限切れ直後。
Expiry: when it reaches the configurable duration T_meas.
有効期限：構成可能な期間T_measに達したとき。
Action on expiry: calculate NM-rate, [CL-specific] ThM-rate, and ETM-rate and proceed to the applicable reporting procedure (Section 3.2.2 or Section 3.2.3).
満了時のアクション：NMレート、[CL固有] ThMレート、およびETMレートを計算し、該当するレポート手順（セクション3.2.2またはセクション3.2.3）に進みます。
t_maxsuppress
t_maxsuppress
Where used: PCN-egress-node.
使用場所：PCN-egress-node。
Used in procedure: report suppression (Section 3.2.3).
手順で使用：レポート抑制（セクション3.2.3）。
Incidence: one per ingress-egress-aggregate.
発生率：ingress-egress-aggregateごとに1つ。
Reset: when the next report is sent, either after expiry or because the CLE has exceeded the reporting threshold.
リセット：有効期限が切れた後、またはCLEがレポートのしきい値を超えたために、次のレポートが送信されたとき。
Expiry: when it reaches the configurable duration T_maxsuppress.
有効期限：構成可能な期間T_maxsuppressに達したとき。
Action on expiry: send a report to the Decision Point the next time the reporting procedure (Section 3.2.3) is invoked, regardless of the value of CLE.
満了時のアクション：CLEの値に関係なく、次にレポート手順（セクション3.2.3）が呼び出されたときに、ディシジョンポイントにレポートを送信します。
t_recvFail
t_recvFail
Where used: Decision Point.
使用場所：決定点。
Used in procedure: failure detection (Section 3.3.3).
手順で使用：障害検出（セクション3.3.3）。
Incidence: one per ingress-egress-aggregate.
発生率：ingress-egress-aggregateごとに1つ。
Reset: when a report is received for the ingress-egress-aggregate.
リセット：ingress-egress-aggregateのレポートを受信したとき。
Expiry: when it reaches the calculated duration T_fail. As described in Section 3.3.3, T_fail is equal either to the configured duration T_crit or to the calculated value 3 * T_maxsuppress, where T_maxsuppress is a configured duration.
有効期限：計算された期間T_failに達したとき。セクション3.3.3で説明したように、T_failは、構成された期間T_critまたは計算値3 * T_maxsuppressのいずれかに等しくなります。T_maxsuppressは構成された期間です。
Action on expiry: notify management, and possibly other actions.
失効時のアクション：管理に通知し、場合によっては他のアクションも通知します。
t_sndFail
t_sndFail
Where used: centralized Decision Point.
使用場所：一元化された決定点。
Used in procedure: failure detection (Section 3.3.3).
手順で使用：障害検出（セクション3.3.3）。
Incidence: only as required, one per outstanding request to a PCN-ingress-node.
発生率：必要な場合のみ、PCN-ingress-nodeへの未解決の要求ごとに1つ。
Started: when a request for the value of PCN-sent-traffic for a given ingress-egress-aggregate is sent to the PCN-ingress-node.
開始：特定のingress-egress-aggregateのPCN-sent-trafficの値の要求がPCN-ingress-nodeに送信されたとき。
Terminated without action: when a response is received before expiry.
アクションなしで終了：有効期限が切れる前に応答が受信されたとき。
Expiry: when it reaches the configured duration T_crit.
有効期限：構成された期間T_critに達したとき。
Action on expiry: as described in Section 3.3.3.
満了時のアクション：セクション3.3.3で説明されています。
The timers just described depend on three configurable durations, T_meas, T_maxsuppress, and T_crit. The recommendations given below for the values of these durations are all related to the intended PCN reaction time of 1 to 3 seconds. However, they are based on judgement rather than operational experience or mathematical derivation.
今説明したタイマーは、T_meas、T_maxsuppress、およびT_critの3つの構成可能な期間に依存します。これらの継続時間の値に関する以下の推奨事項はすべて、1〜3秒の目的のPCN反応時間に関連しています。ただし、これらは運用上の経験や数学的導出ではなく、判断に基づいています。
The value of T_meas is RECOMMENDED to be on the order of 100 to 500 ms to provide a reasonable trade-off between demands on network resources (PCN-egress-node and Decision Point processing, network bandwidth) and the time taken to react to impending congestion.
T_measの値は、ネットワークリソース（PCN-egress-nodeとDecision Point処理、ネットワーク帯域幅）の需要と差し迫った状態に反応するのにかかる時間の間の妥当なトレードオフを提供するために、100〜500 msのオーダーであることが推奨されます。混雑。
The value of T_maxsuppress is RECOMMENDED to be on the order of 3 to 6 seconds, for similar reasons to those for the choice of T_meas.
T_maxsuppressの値は、T_measを選択した理由と同様の理由で、3〜6秒程度にすることをお勧めします。
The value of T_crit SHOULD NOT be less than 3 * T_meas. Otherwise, it could cause too many management notifications due to transient conditions in the PCN-egress-node or along the signaling path. A reasonable upper bound on T_crit is on the order of 3 seconds.
T_critの値は3 * T_meas未満であってはなりません（SHOULD NOT）。そうしないと、PCN-egress-node内または信号パスに沿った一時的な状態が原因で、管理通知が多すぎる可能性があります。 T_critの妥当な上限は、約3秒です。
This section provides the specification required by [RFC3086] for a per-domain behavior.
このセクションは、ドメインごとの振る舞いのために[RFC3086]が要求する仕様を提供します。
This section quotes [RFC5559].
このセクションは[RFC5559]を引用しています。
The PCN CL boundary node behavior specified in this document is applicable to inelastic traffic (particularly video and voice) where quality of service for admitted flows is protected primarily by admission control at the ingress to the domain.
このドキュメントで指定されているPCN CL境界ノードの動作は、承認されたフローのサービス品質が主にドメインへの入口での承認制御によって保護されている非弾性トラフィック（特にビデオと音声）に適用されます。
In exceptional circumstances (e.g., due to rerouting as a result of network failures) already admitted flows may be terminated to protect the quality of service of the remaining flows. [CL-specific] The performance results in, e.g., [MeLe10], indicate that the CL boundary node behavior provides better service outcomes under such circumstances than the SM boundary node behavior described in [RFC6662], because CL is less likely to terminate PCN-flows unnecessarily.
例外的な状況（ネットワーク障害の結果としての再ルーティングなど）で、残りのフローのサービス品質を保護するために、すでに許可されたフローが終了される場合があります。 [CL固有] [MeLe10]などのパフォーマンス結果は、CLがPCNを終了する可能性が低いため、CL境界ノードの動作が[RFC6662]で説明されているSM境界ノードの動作よりもこのような状況下でより良いサービス結果を提供することを示します。 -不必要に流れます。
Packet classification and treatment at the PCN-ingress-node is described in Section 5.1 of [RFC6660].
PCN-ingress-nodeでのパケットの分類と処理は、[RFC6660]のセクション5.1で説明されています。
PCN packets are further classified as belonging or not belonging to an admitted flow. PCN packets not belonging to an admitted flow are "blocked". (See Section 1 for an understanding of how this term is interpreted.) Packets belonging to an admitted flow are policed to ensure that they adhere to the rate or flowspec that was negotiated during flow admission.
PCNパケットはさらに、許可されたフローに属するものと属さないものに分類されます。許可されたフローに属していないPCNパケットは「ブロック」されます。 （この用語の解釈については、セクション1を参照してください。）許可されたフローに属するパケットは、フローの許可中にネゴシエートされたレートまたはフロー仕様に準拠するようにポリシングされます。
The PCN CL boundary node behavior is a metering and marking behavior rather than a scheduling behavior. As a result, while the encoding uses a single DSCP value, that value can vary from one deployment to another. The PCN working group suggests using admission control for the following service classes (defined in [RFC4594]):
PCN CL境界ノードの動作は、スケジューリング動作ではなく、メータリングおよびマーキング動作です。その結果、エンコーディングは単一のDSCP値を使用しますが、その値はデプロイメントごとに異なる可能性があります。 PCNワーキンググループは、次のサービスクラス（[RFC4594]で定義）のアドミッションコントロールの使用を提案しています。
o Telephony (EF)
o テレフォニー（EF）
o Real-time interactive (CS4)
o リアルタイムインタラクティブ（CS4）
o Broadcast Video (CS3)
o ブロードキャストビデオ（CS3）
o Multimedia Conferencing (AF4)
o マルチメディア会議（AF4）
For a fuller discussion, see Appendix A of [RFC6660].
詳細については、[RFC6660]の付録Aをご覧ください。
The purpose of this per-domain behavior is to achieve low loss and jitter for the target class of traffic. The design requirement for PCN was that recovery from overloads through the use of flow termination should happen within 1-3 seconds. PCN probably performs better than that.
このドメインごとの動作の目的は、ターゲットクラスのトラフィックの損失とジッターを低く抑えることです。 PCNの設計要件は、フロー終了の使用による過負荷からの回復が1〜3秒以内に発生することでした。 PCNはおそらくそれよりもパフォーマンスが優れています。
The set of parameters that needs to be configured at each PCN-node and at the Decision Point is described in Section 5.1.
各PCNノードおよび決定点で構成する必要があるパラメーターのセットについては、セクション5.1で説明します。
It is assumed that a specific portion of link capacity has been reserved for PCN-traffic.
リンク容量の特定の部分がPCNトラフィック用に予約されていると想定されています。
The PCN CL behavior may be used to carry real-time traffic, particularly voice and video.
PCN CLの動作は、リアルタイムのトラフィック、特に音声とビデオの伝送に使用できます。
The PCN CL per-domain behavior could theoretically interfere with the use of end-to-end ECN due to reuse of ECN bits for PCN marking. Section 5.1 of [RFC6660] describes the actions that can be taken to protect ECN signaling. Appendix B of that document provides further discussion of how ECN and PCN can coexist.
PCN CLドメインごとの動作は、PCNマーキングにECNビットを再利用するため、理論的にはエンドツーエンドのECNの使用を妨げる可能性があります。 [RFC6660]のセクション5.1は、ECNシグナリングを保護するために実行できるアクションについて説明しています。そのドキュメントの付録Bは、ECNとPCNがどのように共存できるかについてさらに説明しています。
Please see the security considerations in [RFC5559] as well as those in [RFC2474] and [RFC2475].
[RFC5559]および[RFC2474]と[RFC2475]のセキュリティに関する考慮事項を参照してください。
Deployment of the PCN Controlled Load edge behavior requires the following steps:
PCN制御ロードエッジ動作の展開には、次の手順が必要です。
o selection of deployment options and global parameter values;
o 展開オプションとグローバルパラメータ値の選択。
o derivation of per-node and per-link information;
o ノードごとおよびリンクごとの情報の導出。
o installation, but not activation, of parameters and policies at all of the nodes in the PCN-domain;
o PCNドメイン内のすべてのノードでのパラメーターとポリシーのインストール（アクティブ化ではない）。
o activation and verification of all behaviors.
o すべての動作のアクティブ化と検証。
The first set of decisions affects the operation of the network as a whole. To begin with, the operator needs to make basic design decisions such as whether the Decision Point is centralized or collocated with the PCN-ingress-nodes, and whether per-flow and aggregate resource signaling as described in [RSVP-PCN] is deployed in the network. After that, the operator needs to decide: o whether PCN packets will be forwarded unencapsulated or in tunnels between the PCN-ingress-node and the PCN-egress-node. Encapsulation preserves incoming ECN settings and simplifies the PCN-egress-node's job when it comes to relating incoming packets to specific ingress-egress-aggregates, but lowers the path MTU and imposes the extra labor of encapsulation/decapsulation on the PCN-edge-nodes.
最初の一連の決定は、ネットワーク全体の運用に影響を与えます。まず、オペレーターは、決定点がPCN-ingress-nodeと集中化されているか、同じ場所に配置されているか、[RSVP-PCN]で説明されているフローごとの集約リソースシグナリングが展開されているかなど、基本的な設計決定を行う必要があります。ネットワーク。その後、オペレーターは次のことを決定する必要があります。o PCNパケットをカプセル化せずに転送するか、PCN-ingress-nodeとPCN-egress-node間のトンネルで転送するか。カプセル化は、着信ECN設定を保持し、着信パケットを特定の入力-出力-集約に関連付ける際に、PCN-出力ノードのジョブを簡素化しますが、パスMTUを下げ、PCN-エッジノードにカプセル化/カプセル化解除の余分な労力を課します。
o which service classes will be subject to PCN control and what DSCP will be used for each. (See [RFC6660] Appendix A for advice on this topic.)
o PCN制御の対象となるサービスクラスと、それぞれに使用されるDSCP。 （このトピックに関するアドバイスについては、[RFC6660]付録Aをご覧ください）。
o the markings to be used at all nodes in the PCN-domain to indicate not-marked (NM), [CL-specific] threshold-marked (ThM), and excess-traffic-marked (ETM) PCN packets;
o マークされていない（NM）、[CL固有]しきい値マークされた（ThM）、および超過トラフィックマークされた（ETM）PCNパケットを示すためにPCNドメインのすべてのノードで使用されるマーキング。
o the marking rules for re-marking PCN-traffic leaving the PCN-domain;
o PCNドメインを離れるPCNトラフィックを再マーキングするためのマーキングルール。
o whether PCN-based flow admission is enabled;
o PCNベースのフローアドミッションが有効かどうか。
o whether PCN-based flow termination is enabled.
o PCNベースのフロー終了が有効かどうか。
The following parameters affect the operation of PCN itself. The operator needs to choose:
以下のパラメーターは、PCN自体の操作に影響します。オペレーターは以下を選択する必要があります。
o the value of CLE-limit if PCN-based flow admission is enabled. [CL-specific] In practice, the operation of flow admission is not very sensitive to the value of the CLE-limit, because when threshold-marking occurs it tends to persist long enough that threshold-marked traffic becomes a large proportion of the received traffic in a given interval.
o PCNベースのフローアドミッションが有効な場合のCLE-limitの値。 [CL固有]実際には、フローアドミッションの操作はCLE-limitの値にあまり敏感ではありません。しきい値マーキングが発生すると、しきい値マーキングされたトラフィックが受信の大部分になるほど長く持続する傾向があるためです。特定の間隔のトラフィック。
o the value of the collection interval T_meas. For a recommended range of values, see Section 3.5.1 above.
o 収集間隔T_measの値。推奨される値の範囲については、上記の3.5.1項を参照してください。
o whether report suppression is to be enabled at the PCN-egress-nodes and if so, the values of CLE-reporting-threshold and T_maxsuppress. It is reasonable to leave CLE-reporting-threshold at its default value (zero, as specified in Section 3.2.3). For a recommended range of values of T_maxsuppress, see Section 3.5.1 above.
o PCN-egress-nodeでレポート抑制を有効にするかどうか、有効にする場合は、CLE-reporting-thresholdおよびT_maxsuppressの値。 CLE-reporting-thresholdをデフォルト値（セクション3.2.3で指定されているゼロ）のままにしておくのが妥当です。 T_maxsuppressの推奨値の範囲については、上記のセクション3.5.1を参照してください。
o the value of the duration T_crit, which the Decision Point uses in deciding whether communications with a given PCN-edge-node have failed. For a recommended range of values of T_crit, see Section 3.5.1 above.
o 特定のPCNエッジノードとの通信が失敗したかどうかを決定するために決定ポイントが使用する期間T_critの値。 T_critの推奨値の範囲については、上記のセクション3.5.1を参照してください。
o [CL-specific] Activation/deactivation of recording of individual flow identifiers when excess-traffic-marked PCN-traffic is observed. Reporting these identifiers has value only if PCN-based flow termination is activated and Equal Cost Multi-Path (ECMP) routing is enabled in the PCN-domain.
o [CL固有]過剰トラフィックがマークされたPCNトラフィックが観察された場合の、個々のフロー識別子の記録のアクティブ化/非アクティブ化。これらの識別子の報告に価値があるのは、PCNベースのフロー終了がアクティブで、PCNドメインで等コストマルチパス（ECMP）ルーティングが有効になっている場合のみです。
Filters are required at both the PCN-ingress-node and the PCN-egress-node to classify incoming PCN packets by ingress-egress-aggregate. Because of the potential use of multipath routing in domains upstream of the PCN-domain, it is impossible to do such classification reliably at the PCN-egress-node based on the packet header contents as originally received at the PCN-ingress-node. (Packets with the same header contents could enter the PCN-domain at multiple PCN-ingress-nodes.) As a result, the only way to construct such filters reliably is to tunnel the packets from the PCN-ingress-node to the PCN-egress-node.
PCN-ingress-nodeとPCN-egress-nodeの両方でフィルターを使用して、ingress-egress-aggregateで着信PCNパケットを分類する必要があります。 PCNドメインの上流のドメインでマルチパスルーティングを使用する可能性があるため、PCN入力ノードで最初に受信したパケットヘッダーの内容に基づいて、PCN出力ノードでそのような分類を確実に行うことは不可能です。 （同じヘッダー内容のパケットは、複数のPCN-ingress-nodeでPCNドメインに入る可能性があります。）その結果、そのようなフィルターを確実に構築する唯一の方法は、PCN-ingress-nodeからPCN-出力ノード。
The PCN-ingress-node needs filters in order to place PCN packets into the right tunnel in the first instance, and also to satisfy requests from the Decision Point for admission rates into specific ingress-egress-aggregates. These filters select the PCN-egress-node, but not necessarily a specific path through the network to that node. As a result, they are likely to be stable even in the face of failures in the network, except when the PCN-egress-node itself becomes unreachable. If all PCN packets will be tunneled, the PCN-ingress-node also needs to know the address of the peer PCN-egress-node associated with each filter.
PCN-ingress-nodeは、最初のインスタンスでPCNパケットを正しいトンネルに配置するため、および特定のingress-egress-aggregatesへの許可率の決定ポイントからの要求を満たすために、フィルターを必要とします。これらのフィルターはPCN-egress-nodeを選択しますが、必ずしもネットワークからそのノードへの特定のパスである必要はありません。その結果、PCN-egress-node自体が到達不能になった場合を除いて、ネットワークで障害が発生した場合でも、それらは安定している可能性があります。すべてのPCNパケットがトンネリングされる場合、PCN-ingress-nodeは、各フィルターに関連付けられたピアPCN-egress-nodeのアドレスも知る必要があります。
Operators may wish to give some thought to the provisioning of alternate egress points for some or all ingress-egress-aggregates in case of failure of the PCN-egress-node. This could require the setting up of standby tunnels to these alternate egress points.
オペレーターは、PCN-egress-nodeに障害が発生した場合に備えて、一部またはすべてのingress-egress-aggregatesの代替出力ポイントのプロビジョニングを検討する必要があります。これには、これらの代替出力ポイントへのスタンバイトンネルの設定が必要になる場合があります。
Each PCN-egress-node needs filters to classify incoming PCN packets by ingress-egress-aggregate, in order to gather measurements on a per-aggregate basis. If tunneling is used, these filters are constructed on the basis of the identifier of the tunnel from which the incoming packet has emerged (e.g., the source address in the outer header if IP encapsulation is used). The PCN-egress-node also needs to know the address of the Decision Point to which it sends reports for each ingress-egress-aggregate.
各PCN-egress-nodeには、集約ごとに測定値を収集するために、ingress-egress-aggregateによって着信PCNパケットを分類するフィルターが必要です。トンネリングが使用されている場合、これらのフィルターは、着信パケットが発生したトンネルの識別子（たとえば、IPカプセル化が使用されている場合の外部ヘッダーの送信元アドレス）に基づいて構築されます。 PCN-egress-nodeは、各ingress-egress-aggregateのレポートの送信先となるDecision Pointのアドレスも知っている必要があります。
A centralized Decision Point needs to have the address of the PCN-ingress-node corresponding to each ingress-egress-aggregate. Security considerations require that information also be prepared for a centralized Decision Point and each PCN-edge-node to allow them to authenticate each other.
一元化された決定ポイントには、各ingress-egress-aggregateに対応するPCN-ingress-nodeのアドレスが必要です。セキュリティの考慮事項では、中央の決定ポイントと各PCNエッジノードが相互に認証できるように、それらの情報も準備する必要があります。
Turning to link-specific parameters, the operator needs to derive values for the PCN-admissible-rate and [CL-specific] PCN-supportable-rate on each link in the network. The first two paragraphs of Section 5.2.2 of [RFC5559] discuss how these values may be derived.
リンク固有のパラメーターに目を向けると、オペレーターは、ネットワーク内の各リンクのPCN許容レートと[CL固有] PCNサポート可能レートの値を導出する必要があります。 [RFC5559]のセクション5.2.2の最初の2つの段落では、これらの値がどのように導出されるかについて説明しています。
As discussed in the previous two sections, every PCN node needs to be provisioned with a number of parameters and policies relating to its behavior in processing incoming packets. The Diffserv MIB [RFC3289] can be useful for this purpose, although it needs to be extended in some cases. This MIB covers packet classification, metering, counting, policing, dropping, and marking. The required extensions specifically include an encapsulation action following reclassification by ingress-egress-aggregate. In addition, the MIB has to be extended to include objects for marking the ECN field in the outer header at the PCN-ingress-node and an extension to the classifiers to include the ECN field at PCN-interior and PCN-egress-nodes. Finally, new objects may need to be defined at the PCN-interior-nodes to represent the metering algorithms for threshold-marking and packet-size-independent excess-traffic-marking.
前の2つのセクションで説明したように、すべてのPCNノードは、着信パケットの処理におけるその動作に関連するいくつかのパラメーターとポリシーをプロビジョニングする必要があります。 Diffserv MIB [RFC3289]はこの目的に役立ちますが、場合によっては拡張する必要があります。このMIBは、パケットの分類、メータリング、カウント、ポリシング、ドロップ、およびマーキングをカバーしています。必要な拡張には、ingress-egress-aggregateによる再分類後のカプセル化アクションが含まれています。さらに、PCN-ingress-nodeの外部ヘッダーにECNフィールドをマークするためのオブジェクトを含むようにMIBを拡張し、PCN-interiorおよびPCN-egress-nodeにECNフィールドを含めるように分類子を拡張する必要があります。最後に、しきい値マーキングおよびパケットサイズに依存しない超過トラフィックマーキングの計測アルゴリズムを表すために、PCN内部ノードで新しいオブジェクトを定義する必要がある場合があります。
Values for the PCN-admissible-rate and [CL-specific] PCN-supportable-rate on each link on a node appear as metering parameters. Operators should take note of the need to deploy meters of a given type (threshold or excess-traffic) either on the ingress or the egress side of each interior link, but not both (Appendix B.2 of [RFC5670].
ノード上の各リンクのPCN許容レートと[CL固有] PCNサポート可能レートの値は、メータリングパラメータとして表示されます。オペレーターは、各内部リンクの入口側または出口側のいずれかにではなく、特定のタイプ（しきい値または超過トラフィック）のメーターを配備する必要があることに注意する必要があります（[RFC5670]の付録B.2）。
The following additional information has to be configured by other means (e.g., additional MIBs, NETCONF models).
以下の追加情報は、他の手段（追加のMIB、NETCONFモデルなど）で構成する必要があります。
At the PCN-egress-node:
PCN-egress-nodeで：
o the measurement interval T_meas (units of ms, range 50 to 1000);
o 測定間隔T_meas（msの単位、50〜1000の範囲）。
o [CL-specific] whether specific flow identifiers must be captured when excess-traffic-marked packets are observed;
o [CL固有]トラフィックが過剰にマーキングされたパケットが観察されたときに、特定のフロー識別子をキャプチャする必要があるかどうか。
o whether report suppression is to be applied;
o レポート抑制を適用するかどうか。
o if so, the interval T_maxsuppress (units of 100 ms, range 1 to 100) and the CLE-reporting-threshold (units of tenths of one percent, range 0 to 1000, default value 0);
o その場合、間隔T_maxsuppress（100 msの単位、1〜100の範囲）およびCLE-reporting-threshold（1/10の単位、0〜1000の範囲、デフォルト値0）。
o the address of the PCN-ingress-node for each ingress-egress-aggregate, if the Decision Point is collocated with the PCN-ingress-node and [RSVP-PCN] is not deployed;
o ディシジョンポイントがPCN-ingress-nodeと併置されており、[RSVP-PCN]が展開されていない場合、各ingress-egress-aggregateのPCN-ingress-nodeのアドレス。
o the address of the centralized Decision Point to which it sends its reports, if there is one.
o レポートがある場合は、レポートの送信先となる集中決定ポイントのアドレス。
At the Decision Point:
決定ポイントで：
o whether PCN-based flow admission is enabled;
o PCNベースのフローアドミッションが有効かどうか。
o whether PCN-based flow termination is enabled;
o PCNベースのフロー終了が有効かどうか。
o the value of CLE-limit (units of tenths of one percent, range 0 to 1000);
o CLE-limitの値（1/10の単位、0から1000の範囲）;
o the value of the interval T_crit (units of 100 ms, range 1 to 100);
o 間隔T_critの値（100 msの単位、範囲1〜100）。
o whether report suppression is to be applied;
o レポート抑制を適用するかどうか。
o if so, the interval T_maxsuppress (units of 100 ms, range 1 to 100) and the CLE-reporting-threshold (units of tenths of one percent, range 0 to 1000, default value 0). These MUST be the same values that are provisioned in the PCN-egress-nodes;
o その場合、間隔T_maxsuppress（100 msの単位、1〜100の範囲）およびCLE-reporting-threshold（1％の10分の1の単位、0〜1000の範囲、デフォルト値0）。これらは、PCN-egress-nodesでプロビジョニングされるものと同じ値である必要があります。
o if the Decision Point is centralized, the address of the PCN-ingress-node (and any other information needed to establish a security association) for each ingress-egress-aggregate.
o Decision Pointが集中化されている場合、各ingress-egress-aggregateのPCN-ingress-nodeのアドレス（およびセキュリティアソシエーションを確立するために必要なその他の情報）。
Depending on the testing strategy, it may be necessary to install the new configuration data in stages. This is discussed further below.
テスト戦略によっては、新しい構成データを段階的にインストールする必要がある場合があります。これについては、以下でさらに説明します。
It is certainly not within the scope of this document to advise on testing strategy, which operators undoubtedly have well in hand. Quite possibly an operator will prefer an incremental approach to activation and testing. Implementing the PCN marking scheme at PCN-ingress-nodes, corresponding scheduling behavior in downstream nodes, and re-marking at the PCN-egress-nodes is a large enough step in itself to require thorough testing before going further.
オペレーターが疑いなく手に持っているテスト戦略について助言することは確かにこのドキュメントの範囲外です。かなり可能性のあるオペレーターは、アクティベーションとテストに対して段階的なアプローチを好むでしょう。 PCN-ingress-nodeでのPCNマーキングスキームの実装、ダウンストリームノードでの対応するスケジューリング動作、およびPCN-egress-nodeでの再マーキングは、さらに進む前に徹底的なテストを必要とするのに十分な大きなステップです。
Testing will probably involve the injection of packets at individual nodes and tracking of how the node processes them. This work can make use of the counter capabilities included in the Diffserv MIB. The application of these capabilities to the management of PCN is discussed in the next section.
テストには、おそらく、個々のノードでのパケットの注入と、ノードがパケットを処理する方法の追跡が含まれます。この作業では、Diffserv MIBに含まれているカウンター機能を利用できます。これらの機能をPCNの管理に適用する方法については、次のセクションで説明します。
This section focuses on the use of event logging and the use of counters supported by the Diffserv MIB [RFC3289] for the various monitoring tasks involved in management of a PCN network.
このセクションでは、PCNネットワークの管理に関連するさまざまな監視タスクについて、イベントログの使用とDiffserv MIB [RFC3289]でサポートされているカウンターの使用に焦点を当てています。
It is anticipated that event logging using SYSLOG [RFC5424] will be needed for fault management and potentially for capacity management. Implementations MUST be capable of generating logs for the following events:
SYSLOG [RFC5424]を使用したイベントログは、障害管理や、場合によっては容量管理に必要になると予想されます。実装は、次のイベントのログを生成できる必要があります。
o detection of loss of contact between a Decision Point and a PCN-edge-node, as described in Section 3.3.3;
o セクション3.3.3で説明されているように、ディシジョンポイントとPCNエッジノード間の接触の喪失の検出。
o successful receipt of a report from a PCN-egress-node, following detection of loss of contact with that node;
o PCN出口ノードからのレポートの受信に成功し、そのノードとの接続が失われたことが検出された。
o flow termination events.
o フロー終了イベント。
All of these logs are generated by the Decision Point. There is a strong likelihood in the first and third cases that the events are correlated with network failures at a lower level. This has implications for how often specific event types should be reported, so as not to contribute unnecessarily to log buffer overflow. Recommendations on this topic follow for each event report type.
これらのログはすべて、ディシジョンポイントによって生成されます。最初のケースと3番目のケースでは、イベントが下位レベルのネットワーク障害と相関している可能性が高くなります。これは、ログバッファオーバーフローに不必要に寄与しないように、特定のイベントタイプが報告される頻度に影響を与えます。このトピックに関する推奨事項は、イベントレポートタイプごとに続きます。
The field names (e.g., HOSTNAME, STRUCTURED-DATA) used in the following subsections are defined in [RFC5424].
以下のサブセクションで使用されるフィールド名（例：HOSTNAME、STRUCTURED-DATA）は、[RFC5424]で定義されています。
Section 3.3.3 describes the circumstances under which the Decision Point may determine that it has lost contact, either with a PCN-ingress-node or a PCN-egress-node, due to failure to receive an expected report. Loss of contact with a PCN-ingress-node is a case primarily applicable when the Decision Point is in a separate node. However, implementations MAY implement logging in the collocated case if the implementation is such that non-response to a request from the Decision Point function can occasionally occur due to processor load or other reasons.
3.3.3項では、予想されるレポートの受信に失敗したために、PCN-ingress-nodeまたはPCN-egress-nodeとの接続が失われたとDecision Pointが判断する状況について説明します。 PCN-ingress-nodeとの接続が失われるのは、主にDecision Pointが別のノードにある場合に該当します。ただし、プロセッサの負荷やその他の理由により、Decision Point関数からの要求に対する応答が時々発生するような実装の場合、実装は連結されたケースでロギングを実装できます（MAY）。
The log reporting the loss of contact with a PCN-ingress-node or PCN-egress-node MUST include the following content:
PCN-ingress-nodeまたはPCN-egress-nodeとの接続が失われたことを報告するログには、次の内容を含める必要があります。
o The HOSTNAME field MUST identify the Decision Point issuing the log.
o HOSTNAMEフィールドは、ログを発行するディシジョンポイントを特定する必要があります。
o A STRUCTURED-DATA element MUST be present, containing parameters identifying the node for which an expected report has not been received and the type of report lost (ingress or egress). It is RECOMMENDED that the SD-ID for the STRUCTURED-DATA element have the form "PCNNode" (without the quotes), which has been registered with IANA. The node identifier PARAM-NAME is RECOMMENDED to be "ID" (without the quotes). The identifier itself is subject to the preferences expressed in Section 6.2.4 of [RFC5424] for the HOSTNAME field. The report type PARAM-NAME is RECOMMENDED to be "RTyp" (without the quotes). The PARAM-VALUE for the RTyp field MUST be either "ingr" or "egr".
o STRUCTURED-DATA要素が存在しなければならず、予期されるレポートが受信されなかったノードと失われたレポートのタイプ（入力または出力）を識別するパラメーターを含みます。 STRUCTURED-DATA要素のSD-IDは、IANAに登録されている「PCNNode」の形式（引用符なし）にすることをお勧めします。ノード識別子PARAM-NAMEは "ID"（引用符なし）にすることをお勧めします。識別子自体は、[RFC5424]のセクション6.2.4に記載されているHOSTNAMEフィールドの設定の影響を受けます。レポートタイプPARAM-NAMEは "RTyp"（引用符なし）にすることをお勧めします。 RTypフィールドのPARAM-VALUEは、「ingr」または「egr」のいずれかでなければなりません。
The following values are also RECOMMENDED for the indicated fields in this log, subject to local practice:
次の値も、ローカルの慣例に従って、このログの示されたフィールドに推奨されます。
o PRI initially set to 115, representing a Facility value of (14) "log alert" and a Severity level of (3) "Error Condition". Note that loss of contact with a PCN-egress-node implies that no new flows will be admitted to one or more ingress-egress-aggregates until contact is restored. The reason a higher severity level (lower value) is not proposed for the initial log is because any corrective action would probably be based on alerts at a lower subsystem level.
o PRIは最初は115に設定され、（14）「ログアラート」のファシリティ値と（3）「エラー状態」の重大度レベルを表します。 PCN-egress-nodeとの接続が失われると、接続が復元されるまで、1つ以上のingress-egress-aggregatesに新しいフローが許可されないことを意味します。高い重大度レベル（低い値）が初期ログに提案されない理由は、修正アクションはおそらく低いサブシステムレベルのアラートに基づいているためです。
o APPNAME set to "PCN" (without the quotes).
o APPNAMEは "PCN"（引用符なし）に設定されています。
o MSGID set to "LOST" (without the quotes).
o MSGIDは "LOST"（引用符なし）に設定されています。
If contact is not regained with a PCN-egress-node in a reasonable period of time (say, one minute), the log SHOULD be repeated, this time with a PRI value of 113, implying a Facility value of (14) "log alert" and a Severity value of (1) "Alert: action must be taken immediately". The reasoning is that by this time, any more general conditions should have been cleared, and the problem lies specifically with the PCN-egress-node concerned and the PCN application in particular.
妥当な期間（たとえば1分）内にPCN-egress-nodeとの接触が回復しない場合は、ログを繰り返す必要があります。今回はPRI値が113であり、ファシリティ値が（14） "logアラート」および「1」の重大度値「アラート：アクションはすぐに実行する必要があります」その理由は、この時点までに、より一般的な条件はすべてクリアされているはずであり、問題は特に、関係するPCN-egress-nodeと、特にPCNアプリケーションにあるということです。
Whenever a loss-of-contact log is generated for a PCN-egress-node, a log indicating recovery SHOULD be generated when the Decision Point next receives a report from the node concerned. The log SHOULD have the same content as just described for the loss-of-contact log, with the following differences: o PRI changes to 117, indicating a Facility value of (14) "log alert" and a Severity of (5) "Notice: normal but significant condition".
PCN-egress-nodeのコンタクト喪失ログが生成されるときはいつでも、Decision Pointが次に関係するノードからレポートを受け取ったときに、リカバリーを示すログが生成されるべきです（SHOULD）。ログは、以下の違いを除いて、連絡先喪失ログについて説明したのと同じ内容を持つ必要があります。oPRIが117に変更され、ファシリティ値が（14）「ログアラート」、重大度が（5）であることを示します。通知：正常ですが重大な状態です。」
o MSGID changes to "RECVD" (without the quotes).
o MSGIDは "RECVD"に変更されます（引用符なし）。
Section 3.3.2 describes the process whereby the Decision Point decides that flow termination is required for a given ingress-egress-aggregate, calculates how much flow to terminate, and selects flows for termination. This section describes a log that SHOULD be generated each time such an event occurs. (In the case where termination occurs in multiple rounds, one log SHOULD be generated per round.) The log may be useful in fault management, to indicate the service impact of a fault occurring in a lower-level subsystem. In the absence of network failures, it may also be used as an indication of an urgent need to review capacity utilization along the path of the ingress-egress-aggregate concerned.
セクション3.3.2では、特定のingress-egress-aggregateにフローの終了が必要であるとディシジョンポイントが判断し、終了するフローの量を計算し、終了するフローを選択するプロセスについて説明します。このセクションでは、そのようなイベントが発生するたびに生成される必要があるログについて説明します。 （終了が複数のラウンドで発生する場合、1ラウンドにつき1つのログが生成される必要があります。）ログは、下位レベルのサブシステムで発生する障害のサービスへの影響を示すために、障害管理に役立つ場合があります。ネットワーク障害がない場合は、関連する入出力集約のパスに沿って容量使用率を確認する緊急の必要性を示すものとして使用することもできます。
The log reporting a flow termination event MUST include the following content:
フロー終了イベントを報告するログには、次のコンテンツを含める必要があります。
o The HOSTNAME field MUST identify the Decision Point issuing the log.
o HOSTNAMEフィールドは、ログを発行するディシジョンポイントを特定する必要があります。
o A STRUCTURED-DATA element MUST be present, containing parameters identifying the ingress and egress nodes for the ingress-egress-aggregate concerned, indicating the total amount of flow being terminated, and giving the number of flows terminated to achieve that objective.
o STRUCTURED-DATA要素が存在しなければならず、関係するingress-egress-aggregateの入口ノードと出口ノードを識別するパラメーターを含み、終了するフローの合計量を示し、その目的を達成するために終了したフローの数を示します。
It is RECOMMENDED that the SD-ID for the STRUCTURED-DATA element have the form: "PCNTerm" (without the quotes), which has been registered with IANA. The parameter identifying the ingress node for the ingress-egress-aggregate is RECOMMENDED to have PARAM-NAME "IngrID" (without the quotes). The parameter identifying the egress node for the ingress-egress-aggregate is RECOMMENDED to have PARAM-NAME "EgrID" (without the quotes). Both identifiers are subject to the preferences expressed in Section 6.2.4 of [RFC5424] for the HOSTNAME field.
STRUCTURED-DATA要素のSD-IDは、IANAに登録されている「PCNTerm」（引用符なし）の形式にすることをお勧めします。 ingress-egress-aggregateの入力ノードを識別するパラメーターは、PARAM-NAME "IngrID"（引用符なし）にすることをお勧めします。 ingress-egress-aggregateの出力ノードを識別するパラメーターは、PARA-NAME "EgrID"（引用符なし）にすることをお勧めします。どちらの識別子も、[RFC5424]のセクション6.2.4に記載されているHOSTNAMEフィールドの設定の影響を受けます。
The parameter giving the total amount of flow being terminated is RECOMMENDED to have PARAM-NAME "TermRate" (without the quotes). The PARAM-VALUE MUST be the target rate as calculated according to the procedures of Section 3.3.2, as an integer value in thousands of octets per second. The parameter giving the number of flows selected for termination is RECOMMENDED to have PARAM-NAME "FCnt" (without the quotes). The PARAM-VALUE for this parameter MUST be an integer, the number of flows selected.
終了するフローの総量を指定するパラメーターは、PARAM-NAME "TermRate"（引用符なし）にすることをお勧めします。 PARAM-VALUEは、セクション3.3.2の手順に従って計算されたターゲットレートである必要があります（1秒あたり数千オクテットの整数値）。終了用に選択されたフローの数を示すパラメーターは、PARAM-NAME "FCnt"（引用符なし）を持つことをお勧めします。このパラメーターのPARAM-VALUEは、選択されたフローの数である整数でなければなりません。
The following values are also RECOMMENDED for the indicated fields in this log, subject to local practice:
次の値も、ローカルの慣例に従って、このログの示されたフィールドに推奨されます。
o PRI initially set to 116, representing a Facility value of (14) "log alert" and a Severity level of (4) "Warning: warning conditions".
o PRIの初期設定は116で、ファシリティ値は（14）「ログアラート」、重大度レベルは（4）「警告：警告状態」を表しています。
o APPNAME set to "PCN" (without the quotes).
o APPNAMEは "PCN"（引用符なし）に設定されています。
o MSGID set to "TERM" (without the quotes).
o MSGIDは "TERM"（引用符なし）に設定されています。
The Diffserv MIB [RFC3289] allows for the provision of counters along the various possible processing paths associated with an interface and flow direction. It is RECOMMENDED that the PCN-nodes be instrumented as described below. It is assumed that the cumulative counts so obtained will be collected periodically for use in debugging, fault management, and capacity management.
Diffserv MIB [RFC3289]では、インターフェースとフロー方向に関連するさまざまな可能な処理パスに沿ってカウンターをプロビジョニングできます。以下に説明するように、PCNノードをインスツルメントすることをお勧めします。このようにして取得された累積カウントは、デバッグ、障害管理、および容量管理で使用するために定期的に収集されることが想定されています。
PCN-ingress-nodes SHOULD provide the following counts for each ingress-egress-aggregate. Since the Diffserv MIB installs counters by interface and direction, aggregation of counts over multiple interfaces may be necessary to obtain total counts by ingress-egress-aggregate. It is expected that such aggregation will be performed by a central system rather than at the PCN-ingress-node.
PCN-ingress-nodesは、各ingress-egress-aggregateに対して以下のカウントを提供する必要があります（SHOULD）。 Diffserv MIBはインターフェースと方向ごとにカウンターをインストールするため、ingress-egress-aggregateで合計数を取得するには、複数のインターフェースでの数の集計が必要になる場合があります。このような集約は、PCN-ingress-nodeではなく、中央システムによって実行されることが予想されます。
o total PCN packets and octets that were received for that ingress-egress-aggregate but were dropped;
o そのingress-egress-aggregateで受信されたがドロップされたPCNパケットとオクテットの合計。
o total PCN packets and octets admitted to that aggregate.
o その集約に許可されたPCNパケットとオクテットの合計。
PCN-interior-nodes SHOULD provide the following counts for each interface, noting that a given packet MUST NOT be counted more than once as it passes through the node:
PCN-interior-nodesは、各インターフェイスに対して次のカウントを提供する必要があります（SHOULD）。ノードを通過するとき、特定のパケットは複数回カウントされてはならないことに注意してください。
o total PCN packets and octets dropped;
o ドロップされたPCNパケットとオクテットの合計。
o total PCN packets and octets forwarded without re-marking;
o 再マーキングなしで転送されたPCNパケットとオクテットの合計。
o [CL-specific] total PCN packets and octets re-marked to threshold-marked;
o [CL固有]再マーキングされたPCNパケットとオクテットの合計がしきい値マーキングされました。
o total PCN packets and octets re-marked to excess-traffic-marked.
o 再マーキングされたPCNパケットとオクテットの合計が過剰トラフィックマーキングされました。
PCN-egress-nodes SHOULD provide the following counts for each ingress-egress-aggregate. As with the PCN-ingress-node, so with the PCN-egress-node it is expected that any necessary aggregation over multiple interfaces will be done by a central system.
PCN-egress-nodesは、各ingress-egress-aggregateに対して次のカウントを提供する必要があります（SHOULD）。 PCN-ingress-nodeの場合と同様に、PCN-egress-nodeの場合、複数のインターフェースで必要な集約は、中央システムによって行われることが期待されます。
o total not-marked PCN packets and octets received;
o マークされていないPCNパケットと受信したオクテットの合計。
o [CL-specific] total threshold-marked PCN packets and octets received;
o [CL固有]しきい値がマークされたPCNパケットと受信オクテットの合計。
o total excess-traffic-marked PCN packets and octets received.
o 受信した超過トラフィックマーク付きのPCNパケットとオクテットの合計。
The following continuously cumulative counters SHOULD be provided as indicated, but require new MIBs to be defined. If the Decision Point is not collocated with the PCN-ingress-node, the latter SHOULD provide a count of the number of requests for PCN-sent-rate received from the Decision Point and the number of responses returned to the Decision Point. The PCN-egress-node SHOULD provide a count of the number of reports sent to each Decision Point. Each Decision Point SHOULD provide the following:
次の継続的に累積するカウンターは、示されているとおりに提供する必要がありますが、新しいMIBを定義する必要があります。ディシジョンポイントがPCN-ingress-nodeと併置されていない場合、後者は、ディシジョンポイントから受信したPCN-sent-rateのリクエスト数と、ディシジョンポイントに返された応答数をカウントする必要があります（SHOULD）。 PCN-egress-nodeは、各決定点に送信されたレポートの数のカウントを提供する必要があります（SHOULD）。各ディシジョンポイントは以下を提供する必要があります。
o total number of requests for PCN-sent-rate sent to each PCN-ingress-node with which it is not collocated;
o 併置されていない各PCN-ingress-nodeに送信されたPCN-sent-rateのリクエストの総数。
o total number of reports received from each PCN-egress-node;
o 各PCN出力ノードから受信したレポートの総数。
o total number of loss-of-contact events detected for each PCN-boundary-node;
o 各PCN境界ノードで検出された接触喪失イベントの総数。
o total cumulative duration of "block" state in hundreds of milliseconds for each ingress-egress-aggregate;
o 各ingress-egress-aggregateの「ブロック」状態の合計累積期間（数百ミリ秒）。
o total number of rounds of flow termination exercised for each ingress-egress-aggregate.
o 各ingress-egress-aggregateに対して実行されたフロー終了のラウンドの総数。
[RFC5559] provides a general description of the security considerations for PCN. This memo introduces one new consideration, related to the use of a centralized Decision Point. The Decision Point itself is a trusted entity. However, its use implies the existence of an interface on the PCN-ingress-node through which communication of policy decisions takes place. That interface is a point of vulnerability that must be protected from denial-of-service attacks.
[RFC5559]は、PCNのセキュリティに関する考慮事項の一般的な説明を提供します。このメモは、集中化されたディシジョンポイントの使用に関連する1つの新しい考慮事項を紹介します。ディシジョンポイント自体は信頼できるエンティティです。ただし、その使用は、ポリシー決定の通信が行われるPCN-ingress-node上のインターフェースの存在を意味します。そのインターフェースは、サービス拒否攻撃から保護する必要がある脆弱性のポイントです。
IANA has added the following entries to the "syslog Structured Data ID Values" registry.
IANAは、「syslog構造化データID値」レジストリに次のエントリを追加しました。
Structured Data ID: PCNNode OPTIONAL
構造化データID：PCNNode OPTIONAL
Structured Data Parameter: ID MANDATORY
構造化データパラメータ：ID必須
Structured Data Parameter: Rtyp MANDATORY
構造化データパラメータ：Rtyp MANDATORY
Reference: RFC 6661
リファレンス：RFC 6661
Structured Data ID: PCNTerm OPTIONAL
構造化データID：PCNTerm OPTIONAL
Structured Data Parameter: IngrID MANDATORY
構造化データパラメータ：IngrID MANDATORY
Structured Data Parameter: EgrID MANDATORY
構造化データパラメータ：EgrID MANDATORY
Structured Data Parameter: TermRate MANDATORY
構造化データパラメータ：TermRate MANDATORY
Structured Data Parameter: FCnt MANDATORY
構造化データパラメータ：FCnt MANDATORY
Reference: RFC 6661
リファレンス：RFC 6661
The content of this memo bears a family resemblance to [Briscoe-CL]. The authors of that document were Bob Briscoe, Philip Eardley, and Dave Songhurst of BT, Anna Charny and Francois Le Faucheur of Cisco, Jozef Babiarz, Kwok Ho Chan, and Stephen Dudley of Nortel, Giorgios Karagiannis of U. Twente and Ericsson, and Attila Bader and Lars Westberg of Ericsson.
このメモの内容は、[Briscoe-CL]に家族に似ています。このドキュメントの作成者は、BTのボブブリスコー、フィリップヤードリー、デイブソングハースト、シスコのアンナチャーニーとフランソワルフォシェール、ノーテルのジョゼフバビアーズ、クックホチャン、ノーテルのスティーブンダドリー、U。トゥエンテとエリクソンのジョルギオスカラギアニス、そしてエリクソンのアッティラ・バーダーとラース・ウェストバーグ。
Ruediger Geib, Philip Eardley, and Bob Briscoe have helped to shape the present document with their comments. Toby Moncaster gave a careful review to get it into shape for Working Group Last Call.
Ruediger Geib、Philip Eardley、およびBob Briscoeは、現在の文書をコメントで形作るのに役立ちました。 Toby Moncasterは、Working Group Last Callのためにそれを具体化するために注意深いレビューを行いました。
Amongst the authors, Michael Menth deserves special mention for his constant and careful attention to both the technical content of this document and the manner in which it was expressed.
著者の中で、Michael Menth氏は、このドキュメントの技術的な内容とそれが表現された方法の両方に常に注意深く注意を払っていることを特筆に値します。
David Harrington's careful AD review resulted not only in necessary changes throughout the document, but also the addition of the operations and management considerations (Section 5).
David Harringtonによる慎重なADレビューの結果、ドキュメント全体に必要な変更が加えられただけでなく、運用と管理に関する考慮事項が追加されました（セクション5）。
As part of the broader review process, the document saw further improvements as a result of comments by Joel Halpern, Brian Carpenter, Stephen Farrell, Sean Turner, and Pete Resnick.
広範なレビュープロセスの一環として、Joel Halpern、Brian Carpenter、Stephen Farrell、Sean Turner、およびPete Resnickによるコメントの結果として、ドキュメントはさらに改善されました。
[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月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、RFC 2474、1998年12月。
[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、「An Architecture for Differentiated Services」、RFC 2475、1998年12月。
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3086] Nichols、K.およびB. Carpenter、「Definition of Differentiated Services Per Domain Behavior Behaviors and Rules for their Specification」、RFC 3086、2001年4月。
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
[RFC3289]ベイカー、F。、チャン、K。、およびA.スミス、「差別化サービスアーキテクチャの管理情報ベース」、RFC 3289、2002年5月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslogプロトコル」、RFC 5424、2009年3月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559] Eardley、P。、「Pre-Congestion Notification（PCN）Architecture」、RFC 5559、2009年6月。
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670] Eardley、P。、「PCNノードの測定とマーキングの動作」、RFC 5670、2009年11月。
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, July 2012.
[RFC6660] Briscoe、B.、Moncaster、T。、およびM. Menth、「単一のDiffservコードポイント（DSCP）を使用したIPヘッダー内の3つの輻輳通知（PCN）状態のエンコード」、RFC 6660、2012年7月。
[Briscoe-CL] 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.
[Briscoe-CL] 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月。
[MeLe10] Menth, M. and F. Lehrieder, "PCN-Based Measured Rate Termination", Computer Networks Journal (Elsevier) vol. 54, no. 13, pp. 2099-2116, September 2010.
[MeLe10] Menth、M.、F。Lehrieder、「PCNベースの測定レート終了」、Computer Networks Journal（Elsevier）vol。 54、いいえ。 13、pp.2099-2116、2010年9月。
[MeLe12] Menth, M. and F. Lehrieder, "Performance of PCN-Based Admission Control under Challenging Conditions", IEEE/ ACM Transactions on Networking, vol. 20, no. 2, April 2012.
[MeLe12] Menth、M。、およびF. Lehrieder、「厳しい条件下でのPCNベースのアドミッションコントロールのパフォーマンス」、IEEE / ACM Transactions on Networking、vol。 20、いいえ。 2012年4月2日。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、2006年8月。
[RFC6662] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary Node Behavior for the Single Marking (SM) Mode of Operation", RFC 6662, July 2012.
[RFC6662] Charny、A.、Zhang、J.、Karagiannis、G.、Meth、M。、およびT. Taylor、編、「シングルマーキング（SM）モードの事前輻輳通知（PCN）境界ノードの動作of Operation」、RFC 6662、2012年7月。
[RSVP-PCN] Karagiannis, G. and A. Bhargava, "Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains", Work in Progress, July 2012.
[RSVP-PCN] Karagiannis、G。およびA. Bhargava、「PCNドメインを介したIPv4およびIPv6の予約のためのリソース再予約プロトコル（RSVP）の汎用集約」、作業中、2012年7月。
[Satoh10] Satoh, D. and H. Ueno, "Cause and Countermeasure of Overtermination for PCN-Based Flow Termination", Proceedings of IEEE Symposium on Computers and Communications (ISCC '10), pp. 155-161, Riccione, Italy, June 2010.
[Satoh10]佐藤D.と上野H。、「PCNベースのフロー終了のオーバーターミネーションの原因と対策」、IEEE Symposium on Computers and Communications（ISCC '10）の議事録、pp。155-161、リッチョーネ、イタリア、 2010年6月。
Authors' Addresses
著者のアドレス
Anna Charny USA
アンナ・チャーニーUSA
EMail: anna@mwsm.com
Fortune Huang Huawei Technologies Section F, Huawei Industrial Base, Bantian Longgang, Shenzhen 518129 P.R. China
フォーチュンHuang hu AはテクノロジーセクションF、hu Aは工業基地、Bは日によって長く、Sは非常にリアルです518129 P.R.中国
Phone: +86 15013838060
EMail: huangfuqing@huawei.com
Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands
ゲオルギオスカラギアニス大学トゥエンテP.O. Box 217 7500 AEエンスヘーデ、オランダ
Phone: +31 53 4894099
EMail: g.karagiannis@utwente.nl
Michael Menth University of Tuebingen Sand 13 72076 Tuebingen Germany
Michael Menth University of Tuebingen Sand 13 72076チュービンゲンドイツ
Phone: +49-7071-2970505
EMail: menth@uni-tuebingen.de
Tom Taylor (editor) Huawei Technologies Ottawa Canada
Tom Taylor（編集者）Huawei Technologiesオタワカナダ
EMail: tom.taylor.stds@gmail.com