[要約] RFC 8233は、PCEPを拡張し、サービスに対応したLSP（ラベルスイッチパス）を計算するためのプロトコルです。その目的は、ネットワークリソースの最適な利用と、サービス品質の向上を実現することです。
Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 8233 Q. Wu
Category: Standards Track Huawei
ISSN: 2070-1721 V. Manral
Nano Sec Co
Z. Ali
Cisco Systems
K. Kumaki
KDDI Corporation
September 2017
Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)
サービス認識ラベルスイッチドパス（LSP）を計算するためのパス計算要素通信プロトコル（PCEP）の拡張
Abstract
概要
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.
金融情報ネットワーク（株式市場データプロバイダーなど）などの特定のネットワークでは、ネットワークパフォーマンス基準（レイテンシなど）が他のメトリックや制約と同様にデータパスの選択にとって重要になってきています。これらのメトリックは、顧客とサービスプロバイダー間のサービスレベルアグリーメント（SLA）に関連付けられています。リンク帯域幅の使用率（転送に実際に使用されているリンクの合計帯域幅）は、パスの計算時に考慮する必要があるもう1つの重要な要素です。
IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation.
IGPトラフィックエンジニアリング（TE）メトリック拡張は、ネットワークパフォーマンス情報がOSPFおよびIS-ISを介してそれぞれ配信されるメカニズムを記述します。パス計算要素通信プロトコル（PCEP）は、パス計算要素（PCE）がパス計算クライアント（PCC）要求に応答してパス計算を実行するためのメカニズムを提供します。このドキュメントでは、エンドツーエンドパス計算の制約として、遅延、遅延変動、パケット損失、およびリンク帯域幅使用率を伝送するためのPCEPの拡張について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8233.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8233で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Terminology .....................................................4
3. PCEP Extensions .................................................5
3.1. Extensions to METRIC Object ................................5
3.1.1. Path Delay Metric ...................................6
3.1.1.1. Path Delay Metric Value ....................7
3.1.2. Path Delay Variation Metric .........................7
3.1.2.1. Path Delay Variation Metric Value ..........8
3.1.3. Path Loss Metric ....................................8
3.1.3.1. Path Loss Metric Value .....................9
3.1.4. Non-Understanding / Non-Support of
Service-Aware Path Computation ......................9
3.1.5. Mode of Operation ..................................10
3.1.5.1. Examples ..................................11
3.1.6. Point-to-Multipoint (P2MP) .........................11
3.1.6.1. P2MP Path Delay Metric ....................11
3.1.6.2. P2MP Path Delay Variation Metric ..........12
3.1.6.3. P2MP Path Loss Metric .....................12
3.2. Bandwidth Utilization .....................................12
3.2.1. Link Bandwidth Utilization (LBU) ...................12
3.2.2. Link Reserved Bandwidth Utilization (LRBU) .........13
3.2.3. Bandwidth Utilization (BU) Object ..................13
3.2.3.1. Elements of Procedure .....................14
3.3. Objective Functions .......................................15
4. Stateful PCE and PCE Initiated LSPs ............................16
5. PCEP Message Extension .........................................17
5.1. The PCReq Message .........................................17
5.2. The PCRep Message .........................................18
5.3. The PCRpt Message .........................................19
6. Other Considerations ...........................................20
6.1. Inter-domain Path Computation .............................20
6.1.1. Inter-AS Links .....................................20
6.1.2. Inter-Layer Path Computation .......................20
6.2. Reoptimizing Paths ........................................21
7. IANA Considerations ............................................21
7.1. METRIC Types ..............................................21
7.2. New PCEP Object ...........................................22
7.3. BU Object .................................................22
7.4. OF Codes ..................................................22
7.5. New Error-Values ..........................................23
8. Security Considerations ........................................23
9. Manageability Considerations ...................................24
9.1. Control of Function and Policy ............................24
9.2. Information and Data Models ...............................24
9.3. Liveness Detection and Monitoring .........................24
9.4. Verify Correct Operations .................................24
9.5. Requirements on Other Protocols ...........................24
9.6. Impact on Network Operations ..............................24
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................26
Appendix A. PCEP Requirements .....................................28
Acknowledgments ...................................................29
Contributors ......................................................30
Authors' Addresses ................................................31
Real-time network performance information is becoming critical in the path computation in some networks. Mechanisms to measure latency, delay variation, and packet loss in an MPLS network are described in [RFC6374]. It is important that latency, delay variation, and packet loss are considered during the path selection process, even before the Label Switched Path (LSP) is set up.
一部のネットワークのパス計算では、リアルタイムのネットワークパフォーマンス情報が重要になってきています。 MPLSネットワークでの待ち時間、遅延変動、およびパケット損失を測定するメカニズムは、[RFC6374]で説明されています。ラベルスイッチドパス（LSP）が設定される前であっても、パス選択プロセスでは、遅延、遅延変動、およびパケット損失を考慮することが重要です。
Link bandwidth utilization based on real-time traffic along the path is also becoming critical during path computation in some networks. Thus, it is important that the link bandwidth utilization is factored in during the path computation.
一部のネットワークでは、パスに沿ったリアルタイムトラフィックに基づくリンク帯域幅の使用率も、パスの計算中に重要になります。したがって、パスの計算中にリンク帯域幅の使用率を考慮に入れることが重要です。
The Traffic Engineering Database (TED) is populated with network performance information like link latency, delay variation, packet loss, as well as parameters related to bandwidth (residual bandwidth, available bandwidth, and utilized bandwidth) via TE Metric Extensions in OSPF [RFC7471] or IS-IS [RFC7810] or via a management system. [RFC7823] describes how a Path Computation Element (PCE) [RFC4655] can use that information for path selection for explicitly routed LSPs.
トラフィックエンジニアリングデータベース（TED）には、OSPFのTEメトリック拡張機能を介して、リンク遅延、遅延変動、パケット損失、および帯域幅（残留帯域幅、使用可能な帯域幅、使用帯域幅）に関連するパラメーターなどのネットワークパフォーマンス情報が入力されます[RFC7471]またはIS-IS [RFC7810]または管理システム経由。 [RFC7823]は、パス計算要素（PCE）[RFC4655]が明示的にルーティングされたLSPのパス選択にその情報をどのように使用できるかを説明しています。
A Path Computation Client (PCC) can request a PCE to provide a path meeting end-to-end network performance criteria. This document extends the Path Computation Element Communication Protocol (PCEP) [RFC5440] to handle network performance constraints that include any combination of latency, delay variation, packet loss, and bandwidth utilization constraints.
パス計算クライアント（PCC）は、エンドツーエンドのネットワークパフォーマンス基準を満たすパスを提供するようにPCEに要求できます。このドキュメントは、経路計算要素通信プロトコル（PCEP）[RFC5440]を拡張して、遅延、遅延変動、パケット損失、および帯域幅使用率の制約の任意の組み合わせを含むネットワークパフォーマンスの制約を処理します。
[RFC7471] and [RFC7810] describe various considerations regarding:
[RFC7471]および[RFC7810]は、以下に関するさまざまな考慮事項について説明しています。
o Announcement thresholds and filters
o 通知のしきい値とフィルター
o Announcement suppression
o アナウンス抑制
o Announcement periodicity and network stability
o アナウンスの周期性とネットワークの安定性
The first two provide configurable mechanisms to bound the number of re-advertisements in IGP. The third provides a way to throttle announcements. Section 1.2 of [RFC7823] also describes the oscillation and stability considerations while advertising and considering service-aware information.
最初の2つは、IGPの再アドバタイズメントの数を制限する構成可能なメカニズムを提供します。 3つ目は、アナウンスを抑制する方法を提供します。 [RFC7823]のセクション1.2では、サービス認識情報をアドバタイズおよび検討する際の振動と安定性に関する考慮事項についても説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following terminology is used in this document.
このドキュメントでは、次の用語が使用されています。
IGP: Interior Gateway Protocol; either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).
IGP：Interior Gateway Protocol; 2つのルーティングプロトコル、Open Shortest Path First（OSPF）またはIntermediate System to Intermediate System（IS-IS）のいずれか。
IS-IS: Intermediate System to Intermediate System
IS-IS：中間システムから中間システム
LBU: Link Bandwidth Utilization (see Section 3.2.1)
LBU：リンク帯域幅使用率（セクション3.2.1を参照）
LRBU: Link Reserved Bandwidth Utilization (see Section 3.2.2)
LRBU：リンク予約帯域幅使用率（セクション3.2.2を参照）
MPLP: Minimum Packet Loss Path (see Section 3.3)
MPLP：最小パケット損失パス（セクション3.3を参照）
MRUP: Maximum Reserved Under-Utilized Path (see Section 3.3)
MRUP：予約済みの十分に活用されていないパスの最大数（セクション3.3を参照）
MUP: Maximum Under-Utilized Path (see Section 3.3)
MUP：十分に活用されていない最大パス（セクション3.3を参照）
OF: Objective Function; a set of one or more optimization criteria used for the computation of a single path (e.g., path cost minimization) or for the synchronized computation of a set of paths (e.g., aggregate bandwidth consumption minimization, etc.). (See [RFC5541].)
OF：目的関数;単一のパスの計算（パスコストの最小化など）、またはパスのセットの同期計算（帯域幅の総消費量の最小化など）に使用される1つ以上の最適化基準のセット。 （[RFC5541]を参照してください。）
OSPF: Open Shortest Path First
OSPF：Open Shortest Path First
PCC: Path Computation Client; any client application requesting a path computation to be performed by a Path Computation Element.
PCC：パス計算クライアント。パス計算要素によって実行されるパス計算を要求するクライアントアプリケーション。
PCE: Path Computation Element; an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
RSVP: Resource Reservation Protocol
RSVP：リソース予約プロトコル
TE: Traffic Engineering
て： Ｔらっふぃｃ えんぎねえりんｇ
TED: Traffic Engineering Database
TED：交通工学データベース
This section defines PCEP extensions (see [RFC5440]) for requirements outlined in Appendix A. The proposed solution is used to support network performance and service-aware path computation.
このセクションでは、付録Aで概説されている要件のPCEP拡張（[RFC5440]を参照）を定義します。提案されたソリューションは、ネットワークパフォーマンスとサービス認識パス計算をサポートするために使用されます。
The METRIC object is defined in Section 7.8 of [RFC5440], comprising metric-value and metric-type (T field), and a flags field, comprising a number of bit flags (B bit and P bit). This document defines the following types for the METRIC object.
METRICオブジェクトは、[RFC5440]のセクション7.8で定義されており、メトリック値とメトリックタイプ（Tフィールド）、およびいくつかのビットフラグ（BビットとPビット）で構成されるフラグフィールドで構成されています。このドキュメントでは、METRICオブジェクトの次のタイプを定義しています。
o T=12: Path Delay metric (Section 3.1.1)
o T = 12：パス遅延メトリック（セクション3.1.1）
o T=13: Path Delay Variation metric (Section 3.1.2)
o T = 13：パス遅延変動メトリック（セクション3.1.2）
o T=14: Path Loss metric (Section 3.1.3)
o T = 14：パス損失メトリック（セクション3.1.3）
o T=15: P2MP Path Delay metric (Section 3.1.6.1)
o T = 15：P2MPパス遅延メトリック（セクション3.1.6.1）
o T=16: P2MP Path Delay Variation metric (Section 3.1.6.2)
o T = 16：P2MPパス遅延変動メトリック（セクション3.1.6.2）
o T=17: P2MP Path Loss metric (Section 3.1.6.3)
o T = 17：P2MPパス損失メトリック（セクション3.1.6.3）
The following terminology is used and expanded along the way.
次の用語が使用され、その過程で拡張されます。
o A network comprises of a set of N links {Li, (i=1...N)}.
o ネットワークは、N個のリンクのセット{Li、（i = 1 ... N）}で構成されます。
o A path P of a point-to-point (P2P) LSP is a list of K links {Lpi,(i=1...K)}.
o ポイントツーポイント（P2P）LSPのパスPは、Kリンクのリスト{Lpi、（i = 1 ... K）}です。
The Link Delay metric is defined in [RFC7471] and [RFC7810] as "Unidirectional Link Delay". The Path Delay metric type of the METRIC object in PCEP represents the sum of the Link Delay metric of all links along a P2P path. Specifically, extending on the above-mentioned terminology:
リンク遅延メトリックは、[RFC7471]および[RFC7810]で「単方向リンク遅延」として定義されています。 PCEPのMETRICオブジェクトのパス遅延メトリックタイプは、P2Pパスに沿ったすべてのリンクのリンク遅延メトリックの合計を表します。具体的には、上記の用語を拡張します。
o A Link Delay metric of link L is denoted D(L).
o リンクLのリンク遅延メトリックは、D（L）で示されます。
o A Path Delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}.
o P2Pパスのパス遅延メトリックP = Sum {D（Lpi）、（i = 1 ... K）}。
This is as per the sum of means composition function (Section 4.2.5 of [RFC6049]). Section 1.2 of [RFC7823] describes oscillation and stability considerations, and Section 2.1 of [RFC7823] describes the calculation of the end-to-end Path Delay metric. Further, Section 4.2.9 of [RFC6049] states when this composition function may fail.
これは、平均合成関数の合計によるものです（[RFC6049]のセクション4.2.5）。 [RFC7823]のセクション1.2は、発振と安定性の考慮事項について説明し、[RFC7823]のセクション2.1は、エンドツーエンドのパス遅延メトリックの計算について説明しています。さらに、[RFC6049]のセクション4.2.9には、この合成機能が失敗する可能性がある場合が記載されています。
Metric Type T=12: Path Delay metric
メトリックタイプT = 12：パス遅延メトリック
A PCC MAY use the Path Delay metric in a Path Computation Request (PCReq) message to request a path meeting the end-to-end latency requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path Delay metric that must not be exceeded for the PCC to consider the computed path as acceptable. The Path Delay metric must be less than or equal to the value specified in the metric-value field.
PCCは、パス計算要求（PCReq）メッセージのパス遅延メトリックを使用して、エンドツーエンドの遅延要件を満たすパスを要求できます（MAY）。この場合、Bビットは、PCCが計算されたパスを受け入れ可能と見なすために超えてはならないパス遅延メトリックの境界（最大）を示唆するように設定する必要があります。パス遅延メトリックは、メトリック値フィールドで指定された値以下でなければなりません。
A PCC can also use this metric to ask PCE to optimize the path delay during path computation. In this case, the B bit MUST be cleared.
PCCはこのメトリックを使用して、パス計算中のパス遅延を最適化するようPCEに要求することもできます。この場合、Bビットをクリアする必要があります。
A PCE MAY use the Path Delay metric in a Path Computation Reply (PCRep) message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed Path Delay metric to the PCC.
PCEがこの制約を満たすパスを計算できない場合、PCEは、パス計算応答（PCRep）メッセージのパス遅延メトリックをNO-PATHオブジェクトとともに使用できます（MAY）。 PCEはこのメトリックを使用して、計算されたパス遅延メトリックをPCCに送信することもできます。
[RFC7471] and [RFC7810] define "Unidirectional Link Delay Sub-TLV" to advertise the link delay in microseconds in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). Consequently, the encoding for the Path Delay metric value is quantified in units of microseconds and encoded in IEEE floating point format. The conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision.
[RFC7471]と[RFC7810]は、「単一方向リンク遅延サブTLV」を定義して、24ビットフィールドでリンク遅延をマイクロ秒単位でアドバタイズします。 [RFC5440]は、IEEE浮動小数点形式でエンコードされた32ビットのメトリック値でMETRICオブジェクトを定義します（[IEEE.754]を参照）。その結果、パス遅延メトリック値のエンコーディングはマイクロ秒単位で定量化され、IEEE浮動小数点形式でエンコードされます。 24ビット整数から32ビットIEEE浮動小数点に変換すると、精度がいくらか失われる可能性があります。
The Link Delay Variation metric is defined in [RFC7471] and [RFC7810] as "Unidirectional Delay Variation". The Path Delay Variation metric type of the METRIC object in PCEP encodes the sum of the Link Delay Variation metric of all links along the path. Specifically, extending on the above-mentioned terminology:
リンク遅延変動メトリックは、[RFC7471]および[RFC7810]で「単方向遅延変動」として定義されています。 PCEPのMETRICオブジェクトのパス遅延変動メトリックタイプは、パスに沿ったすべてのリンクのリンク遅延変動メトリックの合計をエンコードします。具体的には、上記の用語を拡張します。
o A delay variation of link L is denoted DV(L) (average delay variation for link L).
o リンクLの遅延変動は、DV（L）（リンクLの平均遅延変動）で表されます。
o A Path Delay Variation metric for the P2P path P = Sum {DV(Lpi), (i=1...K)}.
o P2Pパスのパス遅延変動メトリックP = Sum {DV（Lpi）、（i = 1 ... K）}。
Section 1.2 of [RFC7823] describes oscillation and stability considerations, and Section 2.1 of [RFC7823] describes the calculation of the end-to-end Path Delay Variation metric. Further, Section 4.2.9 of [RFC6049] states when this composition function may fail.
[RFC7823]のセクション1.2は、発振と安定性に関する考慮事項を説明し、[RFC7823]のセクション2.1は、エンドツーエンドのパス遅延変動メトリックの計算について説明します。さらに、[RFC6049]のセクション4.2.9には、この合成機能が失敗する可能性がある場合が記載されています。
Note that the IGP advertisement for link attributes includes the average delay variation over a period of time. An implementation, therefore, MAY use the sum of the average delay variation of links along a path to derive the delay variation of the path. An end-to-end bound on delay variation is typically used as constraint in the path computation. An implementation MAY also use some enhanced composition function for computing the delay variation of a path with better accuracy.
リンク属性のIGPアドバタイズには、一定期間の平均遅延変動が含まれることに注意してください。したがって、実装では、パスに沿ったリンクの平均遅延変動の合計を使用して、パスの遅延変動を導出してもよい（MAY）。遅延変動のエンドツーエンドの境界は、通常、パス計算の制約として使用されます。実装は、パスの遅延変動をより正確に計算するために、いくつかの強化された合成関数を使用してもよい（MAY）。
Metric Type T=13: Path Delay Variation metric
メトリックタイプT = 13：パス遅延変動メトリック
A PCC MAY use the Path Delay Variation metric in a PCReq message to request a path meeting the path delay variation requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path Delay Variation metric that must not be exceeded for the PCC to consider the computed path as acceptable. The path delay variation must be less than or equal to the value specified in the metric-value field.
PCCは、PCReqメッセージのパス遅延変動メトリックを使用して、パス遅延変動要件を満たすパスを要求できます。この場合、Bビットは、PCCが計算されたパスを許容可能と見なすために超えてはならないパス遅延変動メトリックの境界（最大）を示唆するように設定する必要があります。パス遅延変動は、metric-valueフィールドで指定された値以下でなければなりません。
A PCC can also use this metric to ask the PCE to optimize the path delay variation during path computation. In this case, the B flag MUST be cleared.
PCCはこのメトリックを使用して、パス計算中にパス遅延変動を最適化するようPCEに要求することもできます。この場合、Bフラグをクリアする必要があります。
A PCE MAY use the Path Delay Variation metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end-to-end Path Delay Variation metric to the PCC.
PCEがこの制約を満たすパスを計算できない場合は、PCEがPCRepメッセージのパス遅延変動メトリックをNO-PATHオブジェクトとともに使用する場合があります。 PCEはこのメトリックを使用して、計算されたエンドツーエンドのパス遅延変動メトリックをPCCに送信することもできます。
[RFC7471] and [RFC7810] define "Unidirectional Delay Variation Sub-TLV" to advertise the link delay variation in microseconds in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). Consequently, the encoding for the Path Delay Variation metric value is quantified in units of microseconds and encoded in IEEE floating point format. The conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision.
[RFC7471]と[RFC7810]は、24ビットフィールドでマイクロ秒単位のリンク遅延変動をアドバタイズする「単方向遅延変動サブTLV」を定義しています。 [RFC5440]は、IEEE浮動小数点形式でエンコードされた32ビットのメトリック値でMETRICオブジェクトを定義します（[IEEE.754]を参照）。その結果、パス遅延変動メトリック値のエンコーディングはマイクロ秒単位で定量化され、IEEE浮動小数点形式でエンコードされます。 24ビット整数から32ビットIEEE浮動小数点に変換すると、精度がいくらか失われる可能性があります。
[RFC7471] and [RFC7810] define "Unidirectional Link Loss". The Path Loss (as a packet percentage) metric type of the METRIC object in PCEP encodes a function of the unidirectional loss metrics of all links along a P2P path. The end-to-end packet loss for the path is represented by this metric. Specifically, extending on the above mentioned terminology:
[RFC7471]と[RFC7810]は、「単方向リンク損失」を定義しています。 PCEPのMETRICオブジェクトのパス損失（パケットパーセンテージ）メトリックタイプは、P2Pパスに沿ったすべてのリンクの単方向損失メトリックの関数をエンコードします。パスのエンドツーエンドのパケット損失は、このメトリックによって表されます。具体的には、上記の用語を拡張します。
o The percentage link loss of link L is denoted PL(L).
o リンクLのリンク損失パーセンテージはPL（L）で表されます。
o The fractional link loss of link L is denoted FL(L) = PL(L)/100.
o リンクLの部分的なリンク損失は、FL（L）= PL（L）/ 100で表されます。
o The percentage Path Loss metric for the P2P path P = (1 - ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100 for a path P with links Lp1 to LpK.
o P2Pパスのパーセントパス損失メトリックP =（1-（（1-FL（Lp1））*（1-FL（Lp2））* .. *（1-FL（LpK）））* 100の場合Lp1からLpKへのリンクを持つパスP。
This is as per the composition function described in Section 5.1.5 of [RFC6049].
これは、[RFC6049]のセクション5.1.5で説明されている合成関数によるものです。
Metric Type T=14: Path Loss metric
メトリックタイプT = 14：パス損失メトリック
A PCC MAY use the Path Loss metric in a PCReq message to request a path meeting the end-to-end packet loss requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path Loss metric that must not be exceeded for the PCC to consider the computed path as acceptable. The Path Loss metric must be less than or equal to the value specified in the metric-value field.
PCCは、PCReqメッセージのPath Lossメトリックを使用して、エンドツーエンドのパケット損失要件を満たすパスを要求できます。この場合、Bビットは、PCCが計算されたパスを許容可能と見なすために超えてはならないパス損失メトリックの境界（最大）を示唆するように設定する必要があります。 Path Lossメトリックは、metric-valueフィールドで指定された値以下である必要があります。
A PCC can also use this metric to ask the PCE to optimize the path loss during path computation. In this case, the B flag MUST be cleared.
PCCはこのメトリックを使用して、パス計算中にパス損失を最適化するようPCEに要求することもできます。この場合、Bフラグをクリアする必要があります。
A PCE MAY use the Path Loss metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end-to-end Path Loss metric to the PCC.
PCEがこの制約を満たすパスを計算できない場合は、PCEがPCRepメッセージのパス損失メトリックをNO-PATHオブジェクトとともに使用する場合があります。 PCEはこのメトリックを使用して、計算されたエンドツーエンドのパス損失メトリックをPCCに送信することもできます。
[RFC7471] and [RFC7810] define "Unidirectional Link Loss Sub-TLV" to advertise the link loss in percentage in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). Consequently, the encoding for the Path Loss metric value is quantified as a percentage and encoded in IEEE floating point format.
[RFC7471]および[RFC7810]は、「単一方向リンク損失サブTLV」を定義して、24ビットフィールドでリンク損失をパーセンテージでアドバタイズします。 [RFC5440]は、IEEE浮動小数点形式でエンコードされた32ビットのメトリック値でMETRICオブジェクトを定義します（[IEEE.754]を参照）。その結果、パス損失メトリック値のエンコーディングは、パーセンテージとして定量化され、IEEE浮動小数点形式でエンコードされます。
3.1.4. Non-Understanding / Non-Support of Service-Aware Path Computation
3.1.4. サービス認識パス計算の非理解/非サポート
If a PCE receives a PCReq message containing a METRIC object with a type defined in this document, and the PCE does not understand or support that metric type, and the P bit is clear in the METRIC object header, then the PCE SHOULD simply ignore the METRIC object as per the processing specified in [RFC5440].
PCEがこのドキュメントで定義されたタイプのMETRICオブジェクトを含むPCReqメッセージを受信し、PCEがそのメトリックタイプを理解またはサポートしておらず、METRICオブジェクトヘッダーのPビットがクリアされている場合、PCEは単に[RFC5440]で指定されている処理ごとのMETRICオブジェクト。
If the PCE does not understand the new METRIC type, and the P bit is set in the METRIC object header, then the PCE MUST send a PCEP Error (PCErr) message containing a PCEP-ERROR Object with Error-Type = 4 (Not supported object) and Error-value = 4 (Unsupported parameter) [RFC5440][RFC5441].
PCEが新しいMETRICタイプを理解せず、PビットがMETRICオブジェクトヘッダーで設定されている場合、PCEは、Error-Type = 4（サポートされていない）PCEP-ERRORオブジェクトを含むPCEPエラー（PCErr）メッセージを送信する必要があります。オブジェクト）およびエラー値= 4（サポートされていないパラメーター）[RFC5440] [RFC5441]。
If the PCE understands but does not support the new METRIC type, and the P bit is set in the METRIC object header, then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 4 (Not supported object) with Error-value = 5 (Unsupported network performance constraint). The path computation request MUST then be canceled.
PCEは新しいMETRICタイプを理解しているがサポートしていない場合、PビットがMETRICオブジェクトヘッダーに設定されていると、PCEはError-Type = 4（サポートされていないオブジェクト）のPCEP-ERRORオブジェクトを含むPCErrメッセージを送信する必要があります。エラー値= 5（サポートされていないネットワークパフォーマンスの制約）。次に、パス計算要求をキャンセルする必要があります。
If the PCE understands the new METRIC type, but the local policy has been configured on the PCE to not allow network performance constraint, and the P bit is set in the METRIC object header, then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 5 (Policy violation) with Error-value = 8 (Not allowed network performance constraint). The path computation request MUST then be canceled.
PCEが新しいMETRICタイプを理解しているが、ネットワークパフォーマンスの制約を許可しないようにローカルポリシーがPCEで構成されており、PビットがMETRICオブジェクトヘッダーに設定されている場合、PCEはPCEP-を含むPCErrメッセージを送信する必要があります。 Error-Type = 5（ポリシー違反）のERRORオブジェクトとError-value = 8（ネットワークパフォーマンスの制約は許可されていません）。次に、パス計算要求をキャンセルする必要があります。
As explained in [RFC5440], the METRIC object is optional and can be used for several purposes. In a PCReq message, a PCC MAY insert one or more METRIC objects:
[RFC5440]で説明されているように、METRICオブジェクトはオプションであり、いくつかの目的に使用できます。 PCReqメッセージでは、PCCは1つ以上のMETRICオブジェクトを挿入できます（MAY）。
o To indicate the metric that MUST be optimized by the path computation algorithm (path delay, path delay variation, or path loss).
o パス計算アルゴリズム（パス遅延、パス遅延変動、またはパス損失）によって最適化する必要があるメトリックを示すため。
o To indicate a bound on the METRIC (path delay, path delay variation, or path loss) that MUST NOT be exceeded for the path to be considered as acceptable by the PCC.
o PCCがパスを受け入れ可能と見なすために超えてはならないMETRIC（パス遅延、パス遅延変動、またはパス損失）の境界を示すため。
In a PCRep message, the PCE MAY insert the METRIC object with an Explicit Route Object (ERO) so as to provide the METRIC (path delay, path delay variation, or path loss) for the computed path. The PCE MAY also insert the METRIC object with a NO-PATH object to indicate that the metric constraint could not be satisfied.
PCRepメッセージでは、PCEはMETRICオブジェクトを明示的ルートオブジェクト（ERO）とともに挿入して、計算されたパスのMETRIC（パス遅延、パス遅延変動、またはパス損失）を提供できます（MAY）。 PCEは、メトリック制約が満たされなかったことを示すために、METRICオブジェクトをNO-PATHオブジェクトとともに挿入してもよい（MAY）。
The path computation algorithmic aspects used by the PCE to optimize a path with respect to a specific metric are outside the scope of this document.
PCEが特定のメトリックに関してパスを最適化するために使用するパス計算アルゴリズムの側面は、このドキュメントの範囲外です。
All the rules of processing the METRIC object as explained in [RFC5440] are applicable to the new metric types as well.
[RFC5440]で説明されているMETRICオブジェクトの処理のすべてのルールは、新しいメトリックタイプにも適用できます。
If a PCC sends a path computation request to a PCE where the metric to optimize is the path delay and the path loss must not exceed the value of M, then two METRIC objects are inserted in the PCReq message:
PCCがパス計算要求をPCEに送信する場合、最適化するメトリックはパス遅延であり、パス損失はMの値を超えてはならない場合、2つのMETRICオブジェクトがPCReqメッセージに挿入されます。
o First METRIC object with B=0, T=12, C=1, metric-value=0x0000
o B = 0、T = 12、C = 1、metric-value = 0x0000の最初のMETRICオブジェクト
o Second METRIC object with B=1, T=14, metric-value=M
o B = 1、T = 14、metric-value = Mの2番目のMETRICオブジェクト
As per [RFC5440], if a path satisfying the set of constraints can be found by the PCE and there is no policy that prevents the return of the computed metric, then the PCE inserts one METRIC object with B=0, T=12, metric-value= computed path delay. Additionally, the PCE MAY insert a second METRIC object with B=1, T=14, metric-value=computed path loss.
[RFC5440]によると、PCEが一連の制約を満たすパスを見つけることができ、計算されたメトリックが返されないようにするポリシーがない場合、PCEはB = 0、T = 12、 metric-value =計算されたパス遅延。さらに、PCEは、B = 1、T = 14、metric-value = computed path lossを持つ2番目のMETRICオブジェクトを挿入する場合があります（MAY）。
This section defines the following types for the METRIC object to be used for the P2MP TE LSPs.
このセクションでは、P2MP TE LSPに使用されるMETRICオブジェクトの次のタイプを定義します。
The P2MP Path Delay metric type of the METRIC object in PCEP encodes the Path Delay metric for the destination that observes the worst delay metric among all destinations of the P2MP tree. Specifically, extending on the above-mentioned terminology:
PCEPのMETRICオブジェクトのP2MPパス遅延メトリックタイプは、P2MPツリーのすべての宛先間で最悪の遅延メトリックを監視する宛先のパス遅延メトリックをエンコードします。具体的には、上記の用語を拡張します。
o A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)}.
o P2MPツリーTは、1組のM宛先{Dest_j、（j = 1 ... M）}で構成されます。
o The P2P Path Delay metric of the path to destination Dest_j is denoted by PDM(Dest_j).
o 宛先Dest_jへのパスのP2Pパス遅延メトリックは、PDM（Dest_j）で表されます。
o The P2MP Path Delay metric for the P2MP tree T = Maximum {PDM(Dest_j), (j=1...M)}.
o P2MPツリーのP2MPパス遅延メトリックT =最大{PDM（Dest_j）、（j = 1 ... M）}。
The value for the P2MP Path Delay metric type (T) = 15.
P2MPパス遅延メトリックタイプの値（T）= 15。
The P2MP Path Delay Variation metric type of the METRIC object in PCEP encodes the Path Delay Variation metric for the destination that observes the worst delay variation metric among all destinations of the P2MP tree. Specifically, extending on the above-mentioned terminology:
PCEPのMETRICオブジェクトのP2MPパス遅延変動メトリックタイプは、P2MPツリーのすべての宛先間で最悪の遅延変動メトリックを観察する宛先のパス遅延変動メトリックをエンコードします。具体的には、上記の用語を拡張します。
o A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)}.
o P2MPツリーTは、1組のM宛先{Dest_j、（j = 1 ... M）}で構成されます。
o The P2P Path Delay Variation metric of the path to the destination Dest_j is denoted by PDVM(Dest_j).
o 宛先Dest_jへのパスのP2Pパス遅延変動メトリックは、PDVM（Dest_j）で表されます。
o The P2MP Path Delay Variation metric for the P2MP tree T = Maximum {PDVM(Dest_j), (j=1...M)}.
o P2MPツリーのP2MPパス遅延変動メトリックT =最大{PDVM（Dest_j）、（j = 1 ... M）}。
The value for the P2MP Path Delay Variation metric type (T) = 16.
P2MPパス遅延変動メトリックタイプの値（T）= 16。
The P2MP Path Loss metric type of the METRIC object in PCEP encodes the path packet loss metric for the destination that observes the worst packet loss metric among all destinations of the P2MP tree. Specifically, extending on the above-mentioned terminology:
PCEPのMETRICオブジェクトのP2MPパス損失メトリックタイプは、P2MPツリーのすべての宛先間で最悪のパケット損失メトリックを監視する宛先のパスパケット損失メトリックをエンコードします。具体的には、上記の用語を拡張します。
o A P2MP tree T comprises of a set of M destinations {Dest_j, (j=1...M)}.
o P2MPツリーTは、M個の宛先のセット{Dest_j、（j = 1 ... M）}で構成されます。
o The P2P Path Loss metric of the path to destination Dest_j is denoted by PLM(Dest_j).
o 宛先Dest_jへのパスのP2Pパス損失メトリックは、PLM（Dest_j）で表されます。
o The P2MP Path Loss metric for the P2MP tree T = Maximum {PLM(Dest_j), (j=1...M)}.
o P2MPツリーのP2MPパス損失メトリックT =最大{PLM（Dest_j）、（j = 1 ... M）}。
The value for the P2MP Path Loss metric type (T) = 17.
P2MPパス損失メトリックタイプの値（T）= 17。
The LBU on a link, forwarding adjacency, or bundled link is populated in the TED ("Unidirectional Utilized Bandwidth Sub-TLV" in [RFC7471] and [RFC7810]). For a link or forwarding adjacency, the bandwidth utilization represents the actual utilization of the link (i.e., as measured in the router). For a bundled link, the bandwidth utilization is defined to be the sum of the component link bandwidth utilization. This includes traffic for both RSVP-TE and non-RSVP-TE label switched path packets.
リンク、転送隣接、またはバンドルされたリンク上のLBUがTEDに入力されます（[RFC7471]および[RFC7810]の「Unidirectional Utilized Bandwidth Sub-TLV」）。リンクまたは転送隣接の場合、帯域幅使用率はリンクの実際の使用率を表します（つまり、ルーターで測定）。バンドルされたリンクの場合、帯域幅使用率は、コンポーネントリンクの帯域幅使用率の合計として定義されます。これには、RSVP-TEと非RSVP-TEの両方のラベルスイッチドパスパケットのトラフィックが含まれます。
The LBU in percentage is described as the (utilized bandwidth / maximum bandwidth) * 100.
LBUのパーセンテージは、（使用帯域幅/最大帯域幅）* 100として表されます。
The "maximum bandwidth" is defined in [RFC3630] and [RFC5305] and "utilized bandwidth" in [RFC7471] and [RFC7810].
「最大帯域幅」は[RFC3630]と[RFC5305]で定義され、「使用帯域幅」は[RFC7471]と[RFC7810]で定義されています。
The LRBU on a link, forwarding adjacency, or bundled link can be calculated from the TED. The utilized bandwidth includes traffic for both RSVP-TE and non-RSVP-TE LSPs; the reserved bandwidth utilization considers only the RSVP-TE LSPs.
リンク上のLRBU、転送隣接、またはバンドルされたリンクは、TEDから計算できます。使用される帯域幅には、RSVP-TEおよび非RSVP-TE LSPの両方のトラフィックが含まれます。予約済みの帯域幅使用率は、RSVP-TE LSPのみを考慮します。
The reserved bandwidth utilization can be calculated by using the residual bandwidth, available bandwidth, and utilized bandwidth described in [RFC7471] and [RFC7810]. The actual bandwidth by non-RSVP-TE traffic can be calculated by subtracting the available bandwidth from the residual bandwidth ([RFC7471] and [RFC7810]), which is further deducted from utilized bandwidth to get the reserved bandwidth utilization. Thus,
[RFC7471]と[RFC7810]で説明されている残りの帯域幅、使用可能な帯域幅、および利用された帯域幅を使用して、予約済み帯域幅の使用率を計算できます。非RSVP-TEトラフィックによる実際の帯域幅は、残余帯域幅（[RFC7471]および[RFC7810]）から利用可能な帯域幅を差し引くことで計算できます。残余帯域幅は、利用帯域幅からさらに差し引かれ、予約済み帯域幅の利用率を取得します。したがって、
reserved bandwidth utilization = utilized bandwidth - (residual bandwidth - available bandwidth)
予約済み帯域幅使用率=使用済み帯域幅-（残りの帯域幅-使用可能な帯域幅）
The LRBU in percentage is described as the (reserved bandwidth utilization / maximum reservable bandwidth) * 100.
LRBUのパーセンテージは、（予約済み帯域幅使用率/最大予約可能帯域幅）* 100として表されます。
The "maximum reservable bandwidth" is defined in [RFC3630] and [RFC5305]. The "utilized bandwidth", "residual bandwidth", and "available bandwidth" are defined in [RFC7471] and [RFC7810].
「予約可能な最大帯域幅」は、[RFC3630]と[RFC5305]で定義されています。 「利用帯域幅」、「余剰帯域幅」、「利用可能帯域幅」は[RFC7471]と[RFC7810]で定義されています。
The BU object is used to indicate the upper limit of the acceptable link bandwidth utilization percentage.
BUオブジェクトは、許容可能なリンク帯域幅使用率の上限を示すために使用されます。
The BU object MAY be carried within the PCReq message and PCRep messages.
BUオブジェクトはPCReqメッセージとPCRepメッセージ内で運ばれるかもしれません。
BU Object-Class is 35.
BUオブジェクトクラスは35です。
BU Object-Type is 1.
BUオブジェクトタイプは1です。
The format of the BU object body is as follows:
BUオブジェクト本体の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BU Object Body Format
BUオブジェクトボディフォーマット
Reserved (24 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約済み（24ビット）：このフィールドは送信時にゼロに設定する必要があり、受信時には無視する必要があります。
Type (8 bits): Represents the bandwidth utilization type. Two values are currently defined.
タイプ（8ビット）：帯域幅使用タイプを表します。現在、2つの値が定義されています。
* Type 1 is LBU (Link Bandwidth Utilization)
* タイプ1はLBU（リンク帯域幅使用率）です。
* Type 2 is LRBU (Link Residual Bandwidth Utilization)
* タイプ2はLRBU（Link Residual Bandwidth Utilization）です。
Bandwidth Utilization (32 bits): Represents the bandwidth utilization quantified as a percentage (as described in Sections 3.2.1 and 3.2.2) and encoded in IEEE floating point format (see [IEEE.754]).
帯域幅使用率（32ビット）：帯域幅使用率をパーセンテージで定量化し（セクション3.2.1および3.2.2で説明）、IEEE浮動小数点形式でエンコードします（[IEEE.754]を参照）。
The BU object body has a fixed length of 8 bytes.
BUオブジェクトの本体は8バイトの固定長です。
A PCC that wants the PCE to factor in the bandwidth utilization during path computation includes a BU object in the PCReq message. A PCE that supports this object MUST ensure that no link on the computed path has the LBU or LRBU percentage exceeding the given value.
PCEがパス計算中に帯域幅使用率を考慮に入れることを望むPCCは、PCReqメッセージにBUオブジェクトを含めます。このオブジェクトをサポートするPCEは、計算されたパス上のリンクが、指定された値を超えるLBUまたはLRBUパーセンテージを持たないことを確認する必要があります。
A PCReq or PCRep message MAY contain multiple BU objects so long as each is for a different bandwidth utilization type. If a message contains more than one BU object with the same bandwidth utilization type, the first MUST be processed by the receiver and subsequent instances MUST be ignored.
PCReqまたはPCRepメッセージには、それぞれが異なる帯域幅使用タイプのものである限り、複数のBUオブジェクトが含まれる場合があります。メッセージに同じ帯域幅使用タイプの複数のBUオブジェクトが含まれている場合、最初のオブジェクトは受信者によって処理される必要があり、その後のインスタンスは無視されなければなりません（MUST）。
If the BU object is unknown/unsupported, the PCE is expected to follow procedures defined in [RFC5440]. That is, if the P bit is set, the PCE sends a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 1 or 2 (unknown / unsupported object class / object type), and the related path computation request will be discarded. If the P bit is cleared, the PCE is free to ignore the object.
BUオブジェクトが不明/サポートされていない場合、PCEは[RFC5440]で定義されている手順に従うことが期待されます。つまり、Pビットが設定されている場合、PCEはエラータイプ3または4（不明/サポートされていないオブジェクト）およびエラー値1または2（不明/サポートされていないオブジェクトクラス/オブジェクトタイプ）、および関連するパスを含むPCErrメッセージを送信します計算リクエストは破棄されます。 Pビットがクリアされている場合、PCEはオブジェクトを無視できます。
If the PCE understands but does not support path computation requests using the BU object, and the P bit is set in the BU object header, then the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 4 (Not supported object) with Error-value = 5 (Unsupported network performance constraint), and the related path computation request MUST be discarded.
PCEがBUオブジェクトを使用したパス計算要求を理解しているがサポートしていない場合、PオブジェクトがBUオブジェクトヘッダーに設定されていると、PCEはPCEP-ERRORオブジェクトError-Type = 4（サポートされていない）を含むPCErrメッセージを送信する必要があります。オブジェクト）、エラー値= 5（サポートされていないネットワークパフォーマンスの制約）、および関連するパス計算要求は破棄する必要があります。
If the PCE understands the BU object but the local policy has been configured on the PCE to not allow network performance constraint, and the P bit is set in the BU object header, then the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 5 (Policy violation) with Error-value = 8 (Not allowed network performance constraint). The path computation request MUST then be canceled.
PCEがBUオブジェクトを理解しているが、ネットワークパフォーマンスの制約を許可しないようにローカルポリシーがPCEで構成されており、BUオブジェクトヘッダーにPビットが設定されている場合、PCEはPCEP-ERRORオブジェクトを含むPCErrメッセージを送信する必要がありますError-Type = 5（ポリシー違反）、Error-value = 8（許可されていないネットワークパフォーマンスの制約）。次に、パス計算要求をキャンセルする必要があります。
If path computation is unsuccessful, then a PCE MAY insert a BU object (along with a NO-PATH object) into a PCRep message to indicate the constraints that could not be satisfied.
パス計算が失敗した場合、PCEは、BUepオブジェクト（およびNO-PATHオブジェクト）をPCRepメッセージに挿入して、満たすことができなかった制約を示すことができます（MAY）。
Usage of the BU object for P2MP LSPs is outside the scope of this document.
P2MP LSPのBUオブジェクトの使用は、このドキュメントの範囲外です。
[RFC5541] defines a mechanism to specify an objective function that is used by a PCE when it computes a path. The new metric types for path delay and path delay variation can continue to use the existing objective function -- Minimum Cost Path (MCP) [RFC5541]. For path loss, the following new OF is defined.
[RFC5541]は、PCEがパスを計算するときにPCEが使用する目的関数を指定するメカニズムを定義します。パス遅延とパス遅延変動の新しいメトリックタイプは、既存の目的関数である最小コストパス（MCP）[RFC5541]を引き続き使用できます。パス損失については、次の新しいOFが定義されています。
o A network comprises a set of N links {Li, (i=1...N)}.
o ネットワークは、N個のリンクのセット{Li、（i = 1 ... N）}で構成されます。
o A path P is a list of K links {Lpi,(i=1...K)}.
o パスPは、K個のリンクのリスト{Lpi、（i = 1 ... K）}です。
o The percentage link loss of link L is denoted PL(L).
o リンクLのリンク損失パーセンテージはPL（L）で表されます。
o The fractional link loss of link L is denoted FL(L) = PL(L) / 100.
o リンクLの部分的なリンク損失は、FL（L）= PL（L）/ 100で表されます。
o The percentage path loss of a path P is denoted PL(P), where PL(P) = (1 - ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100.
o パスPのパス損失のパーセンテージはPL（P）で表され、PL（P）=（1-（（1-FL（Lp1））*（1-FL（Lp2））* .. *（1-FL （LpK））））* 100。
Objective Function Code: 9 Name: Minimum Packet Loss Path (MPLP) Description: Find a path P such that PL(P) is minimized.
目的関数コード：9名前：最小パケット損失パス（MPLP）説明：PL（P）が最小になるようなパスPを見つけます。
Two additional objective functions -- namely, the Maximum Under-Utilized Path (MUP) and the Maximum Reserved Under-Utilized Path (MRUP) are needed to optimize bandwidth utilization. These two new objective function codes are defined below.
帯域幅の使用率を最適化するには、2つの追加の目的関数、つまり最大使用率が低いパス（MUP）と最大予約済み使用率が低いパス（MRUP）が必要です。これら2つの新しい目的関数コードを以下に定義します。
These objective functions are formulated using the following additional terminology:
これらの目的関数は、次の追加の用語を使用して定式化されます。
o The bandwidth utilization on link L is denoted u(L).
o リンクLの帯域幅使用率はu（L）で表されます。
o The reserved bandwidth utilization on link L is denoted ru(L).
o リンクLで予約されている帯域幅の使用率は、ru（L）で表されます。
o The maximum bandwidth on link L is denoted M(L).
o リンクLの最大帯域幅はM（L）で表されます。
o The maximum reservable bandwidth on link L is denoted R(L).
o リンクLで予約可能な最大帯域幅はR（L）で表されます。
The description of the two new objective functions is as follows.
2つの新しい目的関数の説明は次のとおりです。
Objective Function Code: 10 Name: Maximum Under-Utilized Path (MUP) Description: Find a path P such that (Min {(M(Lpi)- u(Lpi)) / M(Lpi), i=1...K } ) is maximized.
目的関数コード：10名前：十分に活用されていない最大パス（MUP）説明：（最小{（M（Lpi）-u（Lpi））/ M（Lpi）、i = 1 ... K }）は最大化されます。
Objective Function Code: 11 Name: Maximum Reserved Under-Utilized Path (MRUP) Description: Find a path P such that (Min {(R(Lpi)- ru(Lpi)) / R(Lpi), i=1...K } ) is maximized.
目的関数コード：11名前：最大予約済み未使用パス（MRUP）説明：（最小{（R（Lpi）-ru（Lpi））/ R（Lpi）、i = 1 ... K}）が最大化されます。
These new objective functions are used to optimize paths based on the bandwidth utilization as the optimization criteria.
これらの新しい目的関数は、最適化基準としての帯域幅使用率に基づいてパスを最適化するために使用されます。
If the objective functions defined in this document are unknown/ unsupported by a PCE, then the procedure as defined in Section 3.1.1 of [RFC5541] is followed.
このドキュメントで定義されている目的関数が不明/ PCEでサポートされていない場合は、[RFC5541]のセクション3.1.1で定義されている手順に従います。
[RFC8231] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP and the maintaining of these LSPs at the stateful PCE. It further distinguishes between an active and a passive stateful PCE. A passive stateful PCE uses LSP state information learned from PCCs to optimize path computations but does not actively update LSP state. In contrast, an active stateful PCE utilizes the LSP delegation mechanism to update LSP parameters in those PCCs that delegated control over their LSPs to the PCE. [PCE-INITIATED] describes the setup, maintenance, and teardown of
[RFC8231]は、PCEPを介したMPLS-TEおよびGMPLS LSPのステートフル制御を可能にし、ステートフルPCEでこれらのLSPを維持できるようにするPCEPの拡張セットを指定します。さらに、アクティブとパッシブのステートフルPCEを区別します。パッシブステートフルPCEは、PCCから学習したLSP状態情報を使用してパス計算を最適化しますが、LSP状態をアクティブに更新しません。対照的に、アクティブなステートフルPCEは、LSP委任メカニズムを利用して、LSPの制御をPCEに委任したPCCのLSPパラメーターを更新します。 [PCE-INITIATED]は、のセットアップ、メンテナンス、および分解について説明しています
PCE-initiated LSPs under the stateful PCE model. The document defines the PCInitiate message that is used by a PCE to request a PCC to set up a new LSP.
ステートフルPCEモデルでのPCEによって開始されたLSP。このドキュメントでは、PCEがPCCに新しいLSPのセットアップを要求するために使用するPCInitiateメッセージを定義します。
The new metric type and objective functions defined in this document can also be used with the stateful PCE extensions. The format of PCEP messages described in [RFC8231] and [PCE-INITIATED] uses <intended-attribute-list> and <attribute-list>, respectively, (where the <intended-attribute-list> is the attribute-list defined in Section 6.5 of [RFC5440] and extended in Section 5.2 of this document) for the purpose of including the service-aware parameters.
このドキュメントで定義されている新しいメトリックタイプと目的関数は、ステートフルPCE拡張機能でも使用できます。 [RFC8231]と[PCE-INITIATED]で説明されているPCEPメッセージの形式は、それぞれ<intended-attribute-list>と<attribute-list>を使用します（<intended-attribute-list>は、 [RFC5440]のセクション6.5、およびこのドキュメントのセクション5.2で拡張））は、サービス認識パラメータを含めることを目的としています。
The stateful PCE implementation MAY use the extension of PCReq and PCRep messages as defined in Sections 5.1 and 5.2 to enable the use of service-aware parameters during passive stateful operations.
ステートフルPCE実装は、セクション5.1および5.2で定義されているPCReqおよびPCRepメッセージの拡張を使用して、パッシブステートフル操作中にサービス認識パラメーターを使用できるようにする場合があります。
Message formats in this document are expressed using Routing Backus-Naur Form (RBNF) as used in [RFC5440] and defined in [RFC5511].
このドキュメントのメッセージ形式は、[RFC5440]で使用され、[RFC5511]で定義されているRouting Backus-Naur Form（RBNF）を使用して表現されています。
The extensions to the PCReq message are:
PCReqメッセージの拡張は次のとおりです。
o new metric types using existing METRIC object
o 既存のMETRICオブジェクトを使用した新しいメトリックタイプ
o a new optional BU object
o 新しいオプションのBUオブジェクト
o new objective functions using existing OF object [RFC5541] The format of the PCReq message (with [RFC5541] and [RFC8231] as a base) is updated as follows:
o既存のOFオブジェクトを使用した新しい目的関数[RFC5541] PCReqメッセージのフォーマット（[RFC5541]および[RFC8231]をベースとして）は、次のように更新されます。
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<bu-list>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
and where:
<bu-list>::=<BU>[<bu-list>]
<metric-list> ::= <METRIC>[<metric-list>]
The extensions to the PCRep message are:
PCRepメッセージの拡張は次のとおりです。
o new metric types using existing METRIC object
o 既存のMETRICオブジェクトを使用した新しいメトリックタイプ
o a new optional BU object (during unsuccessful path computation, to indicate the bandwidth utilization as a reason for failure)
o 新しいオプションのBUオブジェクト（パス計算の失敗時、帯域幅使用率を失敗の理由として示すため）
o new objective functions using existing OF object [RFC5541] The format of the PCRep message (with [RFC5541] and [RFC8231] as a base) is updated as follows:
o既存のOFオブジェクトを使用した新しい目的関数[RFC5541] PCRepメッセージのフォーマット（[RFC5541]および[RFC8231]をベースとして）は、次のように更新されます。
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
where:
ただし：
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<LSP>]
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
and where:
そして、どこ：
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<bu-list>]
[<metric-list>]
[<IRO>]
<bu-list>::=<BU>[<bu-list>]
<metric-list> ::= <METRIC> [<metric-list>]
A Path Computation LSP State Report message (also referred to as PCRpt message) is a PCEP message sent by a PCC to a PCE to report the current state or delegate control of an LSP. The BU object in a PCRpt message specifies the upper limit set at the PCC at the time of LSP delegation to an active stateful PCE.
パス計算LSP状態レポートメッセージ（PCRptメッセージとも呼ばれる）は、PCCからPCEに送信されて、現在の状態を報告したり、LSPの制御を委任したりするPCEPメッセージです。 PCRptメッセージ内のBUオブジェクトは、アクティブなステートフルPCEへのLSP委任時にPCCで設定された上限を指定します。
The format of the PCRpt message is described in [RFC8231], which uses the <intended-attribute-list>, which is the attribute-list defined in Section 6.5 of [RFC5440] and extended by PCEP extensions.
PCRptメッセージの形式は、[RFC5440]のセクション6.5で定義され、PCEP拡張によって拡張された属性リストである<intended-attribute-list>を使用する[RFC8231]で説明されています。
The PCRpt message can use the updated <attribute-list> (as extended in Section 5.2) for the purpose of including the BU object.
PCRptメッセージは、BUオブジェクトを含めるために、更新された<attribute-list>（セクション5.2で拡張）を使用できます。
[RFC5441] describes the Backward Recursive PCE-Based Computation (BRPC) procedure to compute an end-to-end optimized inter-domain path by cooperating PCEs. The new metric types defined in this document can be applied to end-to-end path computation, in a similar manner to the existing IGP or TE metrics. The new BU object defined in this document can be applied to end-to-end path computation, in a similar manner to a METRIC object with its B bit set to 1.
[RFC5441]は、PCEを協調させることによってエンドツーエンドの最適化されたドメイン間パスを計算するための、後方再帰PCEベースの計算（BRPC）手順について説明しています。このドキュメントで定義されている新しいメトリックタイプは、既存のIGPまたはTEメトリックと同様の方法で、エンドツーエンドのパス計算に適用できます。このドキュメントで定義されている新しいBUオブジェクトは、Bビットが1に設定されたMETRICオブジェクトと同様の方法で、エンドツーエンドのパス計算に適用できます。
All domains should have the same understanding of the METRIC (path delay variation, etc.) and the BU object for end-to-end inter-domain path computation to make sense. Otherwise, some form of metric normalization as described in [RFC5441] MUST be applied.
すべてのドメインは、METRIC（パス遅延変動など）およびBUオブジェクトを同じように理解して、エンドツーエンドのドメイン間パス計算を意味のあるものにする必要があります。それ以外の場合は、[RFC5441]で説明されている何らかの形式のメトリック正規化を適用する必要があります。
The IGP in each neighbor domain can advertise its inter-domain TE link capabilities. This has been described in [RFC5316] (IS-IS) and [RFC5392] (OSPF). The network performance link properties are described in [RFC7471] and [RFC7810]. The same properties must be advertised using the mechanism described in [RFC5392] (OSPF) and [RFC5316] (IS-IS).
各ネイバードメインのIGPは、そのドメイン間TEリンク機能をアドバタイズできます。これは[RFC5316]（IS-IS）および[RFC5392]（OSPF）で説明されています。ネットワークパフォーマンスリンクのプロパティは、[RFC7471]および[RFC7810]で説明されています。 [RFC5392]（OSPF）および[RFC5316]（IS-IS）で説明されているメカニズムを使用して、同じプロパティをアドバタイズする必要があります。
[RFC5623] provides a framework for PCE-based inter-layer MPLS and GMPLS traffic engineering. Lower-layer LSPs that are advertised as TE links into the higher-layer network form a Virtual Network Topology (VNT). The advertisement into the higher-layer network should include network performance link properties based on the end-to-end metric of the lower-layer LSP. Note that the new metrics defined in this document are applied to end-to-end path computation, even though the path may cross multiple layers.
[RFC5623]は、PCEベースのレイヤ間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワークを提供します。上位層ネットワークへのTEリンクとしてアドバタイズされる下位層LSPは、仮想ネットワークトポロジ（VNT）を形成します。上位層ネットワークへのアドバタイズには、下位層LSPのエンドツーエンドメトリックに基づくネットワークパフォーマンスリンクプロパティを含める必要があります。このドキュメントで定義されている新しいメトリックは、パスが複数のレイヤーにまたがっていても、エンドツーエンドのパス計算に適用されることに注意してください。
[RFC6374] defines the measurement of loss, delay, and related metrics over LSPs. A PCC can utilize these measurement techniques. In case it detects a degradation of network performance parameters relative to the value of the constraint it gave when the path was set up, or relative to an implementation-specific threshold, it MAY ask the PCE to reoptimize the path by sending a PCReq with the R bit set in the RP object, as per [RFC5440].
[RFC6374]は、LSP上の損失、遅延、および関連するメトリックの測定を定義します。 PCCはこれらの測定手法を利用できます。パスの設定時に指定した制約の値に関連して、または実装固有のしきい値に関連して、ネットワークパフォーマンスパラメーターの低下を検出した場合、PCEにPCReqを送信してパスを再最適化するように依頼する場合があります。 [RFC5440]に従って、RPオブジェクトでRビットを設定。
A PCC may also detect the degradation of an LSP without making any direct measurements, by monitoring the TED (as populated by the IGP) for changes in the network performance parameters of the links that carry its LSPs. The PCC can issue a reoptimization request for any impacted LSPs. For example, a PCC can monitor the link bandwidth utilization along the path by monitoring changes in the bandwidth utilization parameters of one or more links on the path in the TED. If the bandwidth utilization percentage of any of the links in the path changes to a value less than that required when the path was set up, or otherwise less than an implementation-specific threshold, then the PCC can issue a reoptimization request to a PCE.
PCCは、LSPを伝送するリンクのネットワークパフォーマンスパラメータの変化についてTED（IGPによって入力されたもの）を監視することにより、直接測定を行わずにLSPの劣化を検出することもできます。 PCCは、影響を受けるすべてのLSPに対して再最適化要求を発行できます。たとえば、PCCは、TED内のパス上の1つ以上のリンクの帯域幅使用率パラメーターの変化を監視することにより、パスに沿ったリンク帯域幅使用率を監視できます。パス内のいずれかのリンクの帯域幅使用率が、パスのセットアップ時に必要な値よりも小さい値に変化した場合、または実装固有のしきい値よりも小さい場合、PCCはPCEに再最適化要求を発行できます。
A stateful PCE can also determine which LSPs should be reoptimized based on network events or triggers from external monitoring systems. For example, when a particular link deteriorates and its loss increases, this can trigger the stateful PCE to automatically determine which LSPs are impacted and should be reoptimized.
ステートフルPCEは、ネットワークイベントまたは外部監視システムからのトリガーに基づいて、どのLSPを再最適化するかを決定することもできます。たとえば、特定のリンクが劣化し、その損失が増加すると、これによりステートフルPCEがトリガーされ、影響を受けるLSPが自動的に判断され、再最適化する必要があります。
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry at <http://www.iana.org/assignments/pcep>. Within this registry, IANA maintains a subregistry for "METRIC Object T Field". Six new metric types are defined in this document for the METRIC object (specified in [RFC5440]).
IANAは、<http://www.iana.org/assignments/pcep>で「パス計算要素プロトコル（PCEP）番号」レジストリを維持しています。このレジストリ内で、IANAは「METRIC Object T Field」のサブレジストリを維持しています。このドキュメントでは、METRICオブジェクト（[RFC5440]で指定）に対して6つの新しいメトリックタイプが定義されています。
IANA has made the following allocations:
IANAは次の割り当てを行いました。
Value Description Reference
----------------------------------------------------------
12 Path Delay metric RFC 8233
13 Path Delay Variation metric RFC 8233
14 Path Loss metric RFC 8233
15 P2MP Path Delay metric RFC 8233
16 P2MP Path Delay variation metric RFC 8233
17 P2MP Path Loss metric RFC 8233
IANA maintains Object-Types within the "PCEP Objects" registry. IANA has made the following allocation:
IANAは、「PCEPオブジェクト」レジストリ内にオブジェクトタイプを保持しています。 IANAは次の割り当てを行いました。
Object Object Name Reference
Class Type
------------------------------------------------------
35 0 Reserved RFC 8233
1 BU RFC 8233
IANA has created a new subregistry, named "BU Object Type Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Type field of the BU object. New values are to be assigned by Standards Action [RFC8126]. Each value should be tracked with the following qualities:
IANAは、「パス計算要素プロトコル（PCEP）番号」レジストリ内に「BUオブジェクトタイプフィールド」という名前の新しいサブレジストリを作成して、BUオブジェクトのタイプフィールドを管理します。新しい値は、標準アクション[RFC8126]によって割り当てられます。各値は、次の品質で追跡する必要があります。
o Type
o タイプ
o Name
o 名前
o Reference
o 参照
The following values are defined in this document:
このドキュメントでは、次の値が定義されています。
Type Name Reference
---------------------------------------------------------------
0 Reserved RFC 8233
1 LBU (Link Bandwidth Utilization) RFC 8233
1 LBU（Link Bandwidth Utilization）RFC 8233
2 LRBU (Link Residual Bandwidth Utilization) RFC 8233
2 LRBU（Link Residual Bandwidth Utilization）RFC 8233
IANA maintains the "Objective Function" subregistry (described in [RFC5541]) within the "Path Computation Element Protocol (PCEP) Numbers" registry. Three new objective functions have been defined in this document.
IANAは、「パス計算要素プロトコル（PCEP）番号」レジストリ内に（[RFC5541]で説明されている）「目的関数」サブレジストリを保持しています。このドキュメントでは、3つの新しい目的関数が定義されています。
IANA has made the following allocations:
IANAは次の割り当てを行いました。
Code Name Reference
Point
-----------------------------------------------------------------
9 Minimum Packet Loss Path (MPLP) RFC 8233
10 Maximum Under-Utilized Path (MUP) RFC 8233
10最大利用パス（MUP）RFC 8233
11 Maximum Reserved Under-Utilized Path (MRUP) RFC 8233
11最大予約済み未使用パス（MRUP）RFC 8233
IANA maintains a registry of Error-Types and Error-values for use in PCEP messages. This is maintained as the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANAは、PCEPメッセージで使用するためのエラータイプとエラー値のレジストリを保持しています。これは、「パス計算要素プロトコル（PCEP）番号」レジストリの「PCEP-ERRORオブジェクトエラータイプと値」サブレジストリとして維持されます。
IANA has made the following allocations:
IANAは次の割り当てを行いました。
Two new Error-values are defined for the Error-Type "Not supported object" (type 4) and "Policy violation" (type 5).
エラータイプ「サポートされていないオブジェクト」（タイプ4）および「ポリシー違反」（タイプ5）に対して、2つの新しいエラー値が定義されています。
Error-Type Meaning and error values Reference
-------------------------------------------------------------
4 Not supported object
Error-value 5: Unsupported network RFC 8233 performance constraint
エラー値5：サポートされていないネットワークRFC 8233パフォーマンス制約
5 Policy violation
5ポリシー違反
Error-value 8: Not allowed network RFC 8233 performance constraint
エラー値8：許可されていないネットワークRFC 8233パフォーマンス制約
This document defines new METRIC types, a new BU object, and new OF codes that do not add any new security concerns beyond those discussed in [RFC5440] and [RFC5541] in itself. Some deployments may find the service-aware information like delay and packet loss to be extra sensitive and could be used to influence path computation and setup with adverse effect. Additionally, snooping of PCEP messages with such data or using PCEP messages for network reconnaissance may give an attacker sensitive information about the operations of the network. Thus, such deployment should employ suitable PCEP security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or [PCEPS]. The procedure based on Transport Layer Security (TLS) in [PCEPS] is considered a security enhancement and thus is much better suited for the sensitive service-aware information.
このドキュメントは、[RFC5440]と[RFC5541]自体で説明されているものを超える新しいセキュリティ上の懸念を追加しない新しいMETRICタイプ、新しいBUオブジェクト、および新しいOFコードを定義します。一部の展開では、遅延やパケット損失などのサービス認識情報が非常に敏感であり、パスの計算とセットアップに影響を及ぼし、悪影響を与える可能性があります。さらに、このようなデータを含むPCEPメッセージをスヌーピングしたり、ネットワークの偵察にPCEPメッセージを使用したりすると、攻撃者にネットワークの操作に関する機密情報が提供される可能性があります。したがって、このような展開では、TCP認証オプション（TCP-AO）[RFC5925]または[PCEPS]などの適切なPCEPセキュリティメカニズムを採用する必要があります。 [PCEPS]のトランスポート層セキュリティ（TLS）に基づく手順は、セキュリティ強化と見なされているため、サービスを意識する機密情報に非常に適しています。
The only configurable item is the support of the new constraints on a PCE, which MAY be controlled by a policy module on an individual basis. If the new constraint is not supported/allowed on a PCE, it MUST send a PCErr message accordingly.
構成可能な唯一の項目は、PCEの新しい制約のサポートであり、ポリシーモジュールによって個別に制御される場合があります。 PCEで新しい制約がサポート/許可されていない場合は、それに応じてPCErrメッセージを送信する必要があります。
[RFC7420] describes the PCEP MIB. There are no new MIB Objects for this document.
[RFC7420]はPCEP MIBについて説明しています。このドキュメントの新しいMIBオブジェクトはありません。
The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、新しい活性検出と監視の要件を意味しません。
The mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、新しい動作検証要件を意味するものではありません。
The PCE requires the TED to be populated with network performance information like link latency, delay variation, packet loss, and utilized bandwidth. This mechanism is described in [RFC7471] and [RFC7810].
PCEでは、TEDにリンク遅延、遅延変動、パケット損失、使用帯域幅などのネットワークパフォーマンス情報を入力する必要があります。このメカニズムは、[RFC7471]と[RFC7810]で説明されています。
The mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているメカニズムに加えて、ネットワーク操作に影響を与えません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K.、D。Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc -editor.org/info/rfc3630>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<https://www.rfc-editor.org/info/rfc5305> 。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux、編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511] Farrel、A。、「Routing Backus-Naur Form（RBNF）：A Syntax Using Forming Encoding Rules in Various Routing Protocol Specifications」、RFC 5511、DOI 10.17487 / RFC5511、2009年4月、<https：// www。 rfc-editor.org/info/rfc5511>。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>.
[RFC5541] Le Roux、JL。、Vasseur、JP。、およびY. Lee、「Encoding of Objective Functions in the Path Computation Element Communication Protocol（PCEP）」、RFC 5541、DOI 10.17487 / RFC5541、2009年6月、<https： //www.rfc-editor.org/info/rfc5541>。
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.
[RFC7471] Giacalone、S.、Ward、D.、Drake、J.、Atlas、A。、およびS. Previdi、「OSPF Traffic Engineering（TE）Metric Extensions」、RFC 7471、DOI 10.17487 / RFC7471、2015年3月、 <https://www.rfc-editor.org/info/rfc7471>。
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, <https://www.rfc-editor.org/info/rfc7810>.
[RFC7810] Previdi、S.、Ed。、Giacalone、S.、Ward、D.、Drake、J.、and Q. Wu、 "IS-IS Traffic Engineering（TE）Metric Extensions"、RFC 7810、DOI 10.17487 / RFC7810、2016年5月、<https://www.rfc-editor.org/info/rfc7810>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <http://www.rfc-editor.org/info/rfc8231>.
[RFC8231] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、< http://www.rfc-editor.org/info/rfc8231>。
[IEEE.754] IEEE, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754-2008, DOI 10.1109/IEEESTD.2008.4610935, August 2008.
[IEEE.754] IEEE、「Standard for Binary Floating-Point Arithmetic」、IEEE Standard 754-2008、DOI 10.1109 / IEEESTD.2008.4610935、2008年8月。
[PCE-INITIATED] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Work in Progress, draft-ietf-pce-pce-initiated-lsp-10, June 2017.
[PCE-INITIATED] Crabbe、E.、Minei、I.、Sivabalan、S。、およびR. Varga、「ステートフルPCEモデルでのPCEによって開始されるLSPセットアップのPCEP拡張機能」、作業中、draft-ietf-pce -pce-initiated-lsp-10、2017年6月。
[PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-16, September 2017.
[PCEPS] Lopez、D.、Dios、O.、Wu、W。、およびD. Dhody、「Secure Transport for PCEP」、Work in Progress、draft-ietf-pce-pceps-16、2017年9月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：//www.rfc -editor.org/info/rfc4655>。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[RFC5316] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするISIS拡張機能」、RFC 5316、DOI 10.17487 / RFC5316、2008年12月、< https://www.rfc-editor.org/info/rfc5316>。
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, <https://www.rfc-editor.org/info/rfc5392>.
[RFC5392] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするOSPF拡張機能」、RFC 5392、DOI 10.17487 / RFC5392、2009年1月、< https://www.rfc-editor.org/info/rfc5392>。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, <https://www.rfc-editor.org/info/rfc5441>.
[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、DOI 10.17487 / RFC5441、2009年4月、<https：//www.rfc- editor.org/info/rfc5441>。
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC5623]沖E.、武田T.、ルルーJL、およびA.ファレル、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、RFC 5623、DOI 10.17487 / RFC5623、2009年9月、<https://www.rfc-editor.org/info/rfc5623>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info / rfc5925>。
[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-editor.org/info/rfc6049>.
[RFC6049] Morton、A。およびE. Stephan、「メトリックの空間構成」、RFC 6049、DOI 10.17487 / RFC6049、2011年1月、<https://www.rfc-editor.org/info/rfc6049>。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.
[RFC6374] Frost、D。およびS. Bryant、「MPLSネットワークのパケット損失と遅延測定」、RFC 6374、DOI 10.17487 / RFC6374、2011年9月、<https://www.rfc-editor.org/info/rfc6374 >。
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420] Koushik、A.、Stephan、E.、Zhao、Q.、King、D。、およびJ. Hardwick、「Path Computation Element Communication Protocol（PCEP）Management Information Base（MIB）Module」、RFC 7420、DOI 10.17487 / RFC7420、2014年12月、<https://www.rfc-editor.org/info/rfc7420>。
[RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, "Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions", RFC 7823, DOI 10.17487/RFC7823, May 2016, <https://www.rfc-editor.org/info/rfc7823>.
[RFC7823] Atlas、A.、Drake、J.、Giacarone、S。、およびS. Previdi、「TEメトリック拡張を使用した明示的にルーティングされるラベルスイッチドパス（LSP）のパフォーマンスベースのパス選択」、RFC 7823、DOI 10.17487 / RFC7823、2016年5月、<https://www.rfc-editor.org/info/rfc7823>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
End-to-end service optimization based on latency, delay variation, packet loss, and link bandwidth utilization are key requirements for service providers. The following associated key requirements are identified for PCEP:
遅延、遅延変動、パケット損失、およびリンク帯域幅の使用率に基づくエンドツーエンドのサービス最適化は、サービスプロバイダーの主要な要件です。 PCEPには、次の関連する主要な要件が特定されています。
1. A PCE supporting this specification MUST have the capability to compute end-to-end paths with latency, delay variation, packet loss, and bandwidth utilization constraints. It MUST also support the combination of network performance constraints (latency, delay variation, loss,...) with existing constraints (cost, hop-limit,...).
1. この仕様をサポートするPCEは、遅延、遅延変動、パケット損失、および帯域幅使用率の制約があるエンドツーエンドパスを計算する機能を備えている必要があります。また、ネットワークパフォーマンスの制約（遅延、遅延変動、損失など）と既存の制約（コスト、ホップ制限など）の組み合わせもサポートする必要があります。
2. A PCC MUST be able to specify any network performance constraint in a PCReq message to be applied during the path computation.
2. PCCは、パス計算中に適用されるPCReqメッセージ内のネットワークパフォーマンス制約を指定できなければなりません（MUST）。
3. A PCC MUST be able to request that a PCE optimizes a path using any network performance criteria.
3. PCCは、PCEが任意のネットワークパフォーマンス基準を使用してパスを最適化するよう要求できる必要があります。
4. A PCE that supports this specification is not required to provide service-aware path computation to any PCC at any time.
4. この仕様をサポートするPCEは、いつでもPCCへのサービス認識パス計算を提供する必要はありません。
Therefore, it MUST be possible for a PCE to reject a PCReq message with a reason code that indicates service-aware path computation is not supported. Furthermore, a PCE that does not support this specification will either ignore or reject such requests using pre-existing mechanisms; therefore, the requests MUST be identifiable to legacy PCEs, and rejections by legacy PCEs MUST be acceptable within this specification.
したがって、PCEが、サービス認識パス計算がサポートされていないことを示す理由コードを含むPCReqメッセージを拒否できるようにする必要があります。さらに、この仕様をサポートしないPCEは、既存のメカニズムを使用してそのような要求を無視または拒否します。したがって、要求はレガシーPCEで識別可能である必要があり、レガシーPCEによる拒否は、この仕様内で許容可能である必要があります。
5. A PCE SHOULD be able to return end-to-end network performance information of the computed path in a PCRep message.
5. PCEは、PCRepメッセージで計算されたパスのエンドツーエンドのネットワークパフォーマンス情報を返すことができる必要があります（SHOULD）。
6. A PCE SHOULD be able to compute multi-domain (e.g., Inter-AS, Inter-Area, or Multi-Layer) service-aware paths.
6. PCEは、マルチドメイン（Inter-AS、Inter-Area、またはMulti-Layerなど）のサービス対応パスを計算できる必要があります（SHOULD）。
Such constraints are only meaningful if used consistently: for instance, if the delay of a computed path segment is exchanged between two PCEs residing in different domains, a consistent way of defining the delay must be used.
このような制約は、一貫して使用される場合にのみ意味があります。たとえば、計算されたパスセグメントの遅延が異なるドメインにある2つのPCE間で交換される場合、遅延を定義する一貫した方法を使用する必要があります。
Acknowledgments
謝辞
We would like to thank Alia Atlas, John E. Drake, David Ward, Young Lee, Venugopal Reddy, Reeja Paul, Sandeep Kumar Boina, Suresh Babu, Quintin Zhao, Chen Huaimo, Avantika, and Adrian Farrel for their useful comments and suggestions.
Alia Atlas、John E. Drake、David Ward、Young Lee、Venugopal Reddy、Reeja Paul、Sandeep Kumar Boina、Suresh Babu、Quintin Zhao、Chen Huaimo、Avantika、およびAdrian Farrelの有益なコメントと提案に感謝します。
Also, the authors gratefully acknowledge reviews and feedback provided by Qin Wu, Alfred Morton, and Paul Aitken during performance directorate review.
また、執筆者は、パフォーマンス部門のレビュー中にQin Wu、Alfred Morton、およびPaul Aitkenによって提供されたレビューとフィードバックに感謝します。
Thanks to Jonathan Hardwick for shepherding this document and providing valuable comments. His help in fixing the editorial and grammatical issues is also appreciated.
このドキュメントを作成して貴重なコメントを提供してくれたJonathan Hardwickに感謝します。編集上および文法上の問題の修正における彼の助力も高く評価されています。
Thanks to Christian Hopps for the routing directorate review.
ルーティング総局のレビューをしてくれたChristian Hoppsに感謝します。
Thanks to Jouni Korhonen and Alfred Morton for the operational directorate review.
運用部門のレビューを行ってくれたJouni KorhonenとAlfred Mortonに感謝します。
Thanks to Christian Huitema for the security directorate review.
セキュリティ総局のレビューをしてくれたChristian Huitemaに感謝します。
Thanks to Deborah Brungard for being the responsible AD.
責任あるADであるDeborah Brungardに感謝します。
Thanks to Ben Campbell, Joel Jaeggli, Stephen Farrell, Kathleen Moriarty, Spencer Dawkins, Mirja Kuehlewind, Jari Arkko, and Alia Atlas for the IESG reviews.
IESGのレビューを提供してくれたBen Campbell、Joel Jaeggli、Stephen Farrell、Kathleen Moriarty、Spencer Dawkins、Mirja Kuehlewind、Jari Arkko、Alia Atlasに感謝します。
Contributors
貢献者
Clarence Filsfils Cisco Systems Email: cfilsfil@cisco.com
クラレンスフィルスフィルスシスコシステムズEメール：cfilsfil@cisco.com
Siva Sivabalan Cisco Systems Email: msiva@cisco.com
Shiva Sivabalanシスコシステムズメール：masiva@scisco.com
George Swallow Cisco Systems Email: swallow@cisco.com
ジョージスワローシスコシステムズEメール：swallow@cisco.com
Stefano Previdi Cisco Systems, Inc Via Del Serafico 200 Rome 00191 Italy Email: sprevidi@cisco.com
Stefano Previdi Cisco Systems、Inc Via Del Serafico 200 Rome 00191 Italyメール：sprevidi@cisco.com
Udayasree Palle Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: udayasree.palle@huawei.com
Udayasari Palle Huawei Technologies Divyashree Techno Park、Whitfield Bangalore、Karnataka 560066 India Email：udayasri.pale@huawei.com
Avantika Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: avantika.sushilkumar@huawei.com
Avantika Huawei Technologies Divyashree Techno Park、Whitfield Bangalore、Karnataka、560066 India Email：avantika.sushilkumar@huawei.com
Xian Zhang Huawei Technologies F3-1-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen, Guangdong 518129 China Email: zhang.xian@huawei.com
X Ian Zhang hu AはテクノロジーF3-1-br＆Dセンターであり、hu Aは基本禁止日であり、Long Gangの地区は非常に現実的です。GUCase Building G 518129中国の電子メール：Zhang。Xian@Huawei.com
Authors' Addresses
著者のアドレス
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Dhruv Dhodai Huawei Technologies Divyashari Techno Park、Wheatfished Bangalore、Karnataka 2008インド
Email: dhruv.ietf@gmail.com
Qin Wu Huawei Technologies 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Wuhu AのQはテクノロジー101のソフトウェアアベニュー、Y Uは地区NaN京、江蘇210012中国
Email: bill.wu@huawei.com
Vishwas Manral Nano Sec Co 3350 Thomas Rd. Santa Clara, CA United States of America
3350トーマス・パリーからビスワスミネラルNno Sec。サンタクララはアメリカのアメリカ合衆国です
Email: vishwas@nanosec.io
Zafar Ali Cisco Systems
Zafar Ali Cisco Systems
Email: zali@cisco.com
Kenji Kumaki KDDI Corporation
けんじ くまき Ｋっぢ こｒぽらちおん
Email: ke-kumaki@kddi.com