[要約] 要約：RFC 5886は、PCEベースのアーキテクチャのための監視ツールのセットに関する情報を提供しています。 目的：このRFCの目的は、PCEベースのアーキテクチャでのパス計算要素の監視に役立つツールを提供することです。
Internet Engineering Task Force (IETF) JP. Vasseur, Ed.
Request for Comments: 5886 Cisco Systems, Inc.
Category: Standards Track JL. Le Roux
ISSN: 2070-1721 France Telecom
Y. Ikejiri
NTT Communications Corporation
June 2010
A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture
パス計算要素（PCE）ベースのアーキテクチャ用の一連の監視ツール
Abstract
概要
A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".
マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）ネットワークのトラフィックエンジニアリング（TE）ラベルスイッチ付きパス（LSP）の計算には、パス計算要素（PCE）ベースのアーキテクチャが指定されています。（ドメインは、インテリアゲートウェイプロトコル（IGP）領域や自律システムなどのアドレス管理またはパス計算責任の共通の領域内のネットワーク要素のコレクションを指します）。Path Computation Clients（PCCS）は、計算要求をPCESに送信します。これらは、「パス計算チェーン」を形成する他のPCESにリクエストを転送し、協力する場合があります。
In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information.
したがって、PCEベースの環境では、トラブルシューティングとパフォーマンス監視の目的でパス計算チェーンの状態を監視することが重要です。PCEチェーンに関与する各要素の責任（PCE）と潜在的なリソース競合状態と統計の検出に関与します。パス計算時間は、このような関心のあるメトリックの例です。このドキュメントは、そのような情報を収集するために、パス計算要素プロトコル（PCEP）への手順と拡張を指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5886.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5886で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Path Computation Monitoring Messages ............................6
3.1. Path Computation Monitoring Request (PCMonReq) Message .....6
3.2. Path Monitoring Reply (PCMonRep) Message ...................9
4. Path Computation Monitoring Objects ............................11
4.1. MONITORING Object .........................................11
4.2. PCC-ID-REQ Object .........................................13
4.3. PCE-ID Object .............................................14
4.4. PROC-TIME Object ..........................................15
4.5. OVERLOAD Object ...........................................17
5. Policy .........................................................18
6. Elements of Procedure ..........................................18
7. Manageability Considerations ...................................20
7.1. Control of Function and Policy ............................20
7.2. Information and Data Models ...............................20
7.3. Liveness Detection and Monitoring .........................20
7.4. Verify Correct Operations .................................20
7.5. Requirements on Other Protocols ...........................21
7.6. Impact on Network Operations ..............................21
8. Guidelines to Avoid Overload Thrashing .........................21
9. IANA Considerations ............................................22
9.1. New PCEP Message ..........................................22
9.2. New PCEP Objects ..........................................22
9.3. New Error-Values ..........................................23
9.4. MONITORING Object Flag Field ..............................23
9.5. PROC-TIME Object Flag Field ...............................24
9.6. OVERLOAD Object Flag Field ................................24
10. Security Considerations .......................................24
11. Acknowledgments ...............................................25
12. References ....................................................25
12.1. Normative References .....................................25
12.2. Informative References ...................................25
The Path Computation Element (PCE)-based architecture has been specified in [RFC4655] for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such Interior Gateway Protocol (IGP) areas and Autonomous Systems.
パス計算要素（PCE）ベースのアーキテクチャは、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）ネットワークのトラフィックエンジニアリング（TE）ラベルスイッチ付きパス（LSP）の計算のために[RFC4655]で[RFC4655]で指定されています。ドメインがアドレス管理またはパスの計算責任の共通の領域内のネットワーク要素のコレクションを指す単一または複数のドメイン。そのようなインテリアゲートウェイプロトコル（IGP）領域および自律システムなど。
Path Computation Clients (PCCs) send computation requests to PCEs using PCReq messages, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In the case of successful path computation, the computed paths are then provided to the requesting PCC using PCRep messages. The PCReq and PCRep messages are defined in [RFC5440].
Path Computation Clients（PCCS）は、PCREQメッセージを使用してPCESに計算要求を送信します。これらは、「パス計算チェーン」を形成する他のPCESにリクエストを転送し、協力する場合があります。パス計算が成功した場合、計算されたパスは、PCREPメッセージを使用して要求PCCに提供されます。PCREQおよびPCREPメッセージは[RFC5440]で定義されています。
In PCE-based environments, it is critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest.
PCEベースの環境では、トラブルシューティングとパフォーマンス監視の目的でパス計算チェーンの状態を監視することが重要です。PCEチェーンに関与する各要素の責任（PCE）とパスの観点から潜在的なリソース競合状態と統計の検出が重要です計算時間は、このような関心のある指標の例です。
As defined in [RFC4655], there are circumstances in which more than one PCE is involved in the computation of a TE LSP. A typical example is when the PCC requires the computation of a TE LSP where the head-end and the tail-end of the TE LSP do not reside in adjacent domains and there is no single PCE with the visibility of both the head-end and tail-end domain. We call the set of PCEs involved in the computation of a TE LSP a "path computation chain". As further discussed in Section 3.1, the path computation chain may either be static (pre-configured) or dynamically determined during the path computation process.
[RFC4655]で定義されているように、TE LSPの計算に複数のPCEが関与している状況があります。典型的な例は、PCCがTE LSPの計算を必要とする場合、TE LSPのヘッドエンドとテールエンドが隣接するドメインに存在し、ヘッドエンドとヘッドエンドの両方の可視性を持つ単一のPCEがない場合です。テールエンドドメイン。TE LSPの計算に関与するPCEのセットを「パス計算チェーン」と呼びます。セクション3.1でさらに説明したように、パス計算チェーンは、パス計算プロセス中に静的（事前構成）または動的に決定される場合があります。
As discussed in [RFC4655], a TE LSP may be computed by one PCE (referred to as single PCE path computation) or several PCEs (referred to as multiple PCE path computation). In the former case, the PCC may be able to use IGP extensions to check the liveness of the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive messages. In contrast, when multiple PCEs are involved in the path computation chain, an example of which is the Backward Recursive PCE-based Computation (BRPC) procedure defined in [RFC5441], the PCC's visibility may be limited to the first PCE involved in the path computation chain. Thus, it is critical to define mechanisms in order to monitor the state of the path computation chain.
[RFC4655]で説明したように、TE LSPは1つのPCE（単一PCEパス計算と呼ばれる）またはいくつかのPCE（複数のPCEパス計算と呼ばれる）によって計算される場合があります。前者の場合、PCCはIGP拡張機能を使用して、KeepAliveメッセージを使用してPCE（[RFC5088]および[RFC5089]を参照）またはPCEPを確認できる場合があります。対照的に、複数のPCEがパス計算チェーンに関与している場合、その例は[RFC5441]で定義されている後方再帰PCEベースの計算（BRPC）手順であるため、PCCの可視性は、パスに関与する最初のPCEに限定される場合があります。計算チェーン。したがって、パス計算チェーンの状態を監視するために、メカニズムを定義することが重要です。
This document specifies PCEP extensions in order to gather various state metrics along the path computation chain. In this document, we call a "state metric" a metric that characterizes a PCE state. For example, such a metric can have a form of a boolean (PCE is alive or not, PCE is congested or not) or a performance metric (path computation time at each PCE).
このドキュメントは、パス計算チェーンに沿ってさまざまな状態メトリックを収集するために、PCEP拡張機能を指定します。このドキュメントでは、「状態メトリック」をPCE状態を特徴付けるメトリックと呼びます。たとえば、このようなメトリックは、ブール値の形式（PCEは生きているかどうか、PCEは混雑しているかどうか）またはパフォーマンスメトリック（各PCEでのパス計算時間）を持つことができます。
PCE state metrics can be gathered in two different contexts: in band or out of band. By "in band" we refer to the situation whereby a PCC requests to gather metrics in the context of a path computation request. For example, a PCC may send a path computation request to a PCE and may want to know the processing time of that request in addition to the computed path. Conversely, if the request is "out of band", PCE state metric collection is performed as a standalone request (e.g., check the liveness of a specific path computation chain, collect the average processing time computed over the last 5-minute period on one or more PCEs).
PCE状態メトリックは、バンドまたはバンド外の2つの異なるコンテキストで収集できます。「バンド」とは、PCCがパス計算要求のコンテキストでメトリックを収集するようにPCCが要求する状況を指します。たとえば、PCCはPCHにパス計算要求を送信し、計算されたパスに加えてその要求の処理時間を知りたい場合があります。逆に、リクエストが「バンド外」である場合、PCE状態メトリックコレクションはスタンドアロン要求として実行されます（たとえば、特定のパス計算チェーンの活性を確認し、過去5分間に計算された平均処理時間を1つで計算しますまたはそれ以上のpce）。
In this document, we define two monitoring request types: general and specific. A general monitoring request relates to the collection of a PCE state metrics that is not coupled to a particular path computation request (e.g., average CPU load on a PCE). Conversely, a specific monitoring request relates to a particular path computation request (processing time to complete the path computation for a TE LSP).
このドキュメントでは、2つの監視要求タイプを定義します。一般的な監視要求は、特定のパス計算要求（PCEの平均CPU負荷など）と結合されていないPCE状態メトリックの収集に関連しています。逆に、特定の監視要求は、特定のパス計算要求（TE LSPのパス計算を完了する時間の処理時間）に関連しています。
This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) ([RFC5440]), including new objects and new PCEP messages, in order to monitor the path computation chain and gather various performance metrics.
このドキュメントは、パス計算チェーンを監視し、さまざまなパフォーマンスメトリックを収集するために、新しいオブジェクトや新しいPCEPメッセージを含む、パス計算要素プロトコル（PCEP）（[RFC5440]）への手順と拡張を指定します。
The message formats in this document are specified using Backus Naur Format (BNF) encoding as specified in [RFC5511].
このドキュメントのメッセージ形式は、[RFC5511]で指定されているように、Backus Naur形式（BNF）エンコードを使用して指定されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
PCC (Path Computation Client): any client application requesting a path computation to be performed by a Path Computation Element.
PCC（Path Computation Client）：パス計算要素によって実行されるパス計算を要求するクライアントアプリケーション。
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（PATH計算要素）：ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：トラフィックエンジニアリングラベルの切り替えパス。
As defined in [RFC5440], a PCEP message consists of a common header followed by a variable-length body made of a set of objects that can be either mandatory or optional. As a reminder, an object is said to be mandatory in a PCEP message when the object must be included for the message to be considered valid. The P flag (defined in [RFC5440]) is located in the common header of each PCEP object and can be set by a PCEP peer to require a PCE to take into account the related information during the path computation. Because the P flag exclusively relates to a path computation request, it MUST be cleared in the two PCEP messages (PCMonReq and PCMonRep message) defined in this document.
[RFC5440]で定義されているように、PCEPメッセージは、必須またはオプションのいずれかであるオブジェクトのセットで作られた可変長ボディが続く共通ヘッダーで構成されます。リマインダーとして、オブジェクトが有効と見なされるためにオブジェクトを含める必要がある場合、オブジェクトはPCEPメッセージに必須であると言われます。Pフラグ（[RFC5440]で定義）は、各PCEPオブジェクトの共通ヘッダーに位置し、PCEPピアによって設定して、パス計算中に関連情報を考慮に入れるPCEを要求できます。Pフラグはパス計算要求のみに関連しているため、このドキュメントで定義されている2つのPCEPメッセージ（PCMONREQおよびPCMONREPメッセージ）でクリアする必要があります。
For each PCEP message type, a set of rules is defined that specify the set of objects that the message can carry. An implementation MUST form the PCEP messages using the object ordering specified in this document.
各PCEPメッセージタイプについて、メッセージが伝えることができるオブジェクトのセットを指定するルールのセットが定義されています。実装は、このドキュメントで指定されたオブジェクト順序を使用してPCEPメッセージを形成する必要があります。
In this document, we define two PCEP messages referred to as the Path Computation Monitoring Request (PCMonReq) and Path Computation Monitoring Reply (PCMonRep) messages so as to handle out-of-band monitoring requests. The aim of the PCMonReq message sent by a PCC to a PCE is to gather one or more PCE state metrics on a set of PCEs involved in a path computation chain. The PCMonRep message sent by a PCE to a PCC is used to provide such data.
このドキュメントでは、パス計算監視要求（PCMONREQ）およびパス計算監視応答（PCMONREP）メッセージと呼ばれる2つのPCEPメッセージを定義して、バンド外の監視要求を処理します。PCCからPCCに送信されたPCMONREQメッセージの目的は、パス計算チェーンに関与する一連のPCEで1つ以上のPCE状態メトリックを収集することです。PCCからPCCに送信されたPCMONREPメッセージは、そのようなデータを提供するために使用されます。
The Message-Type field of the PCEP common header for the PCMonReq message is set to 8.
PCMONREQメッセージのPCEP共通ヘッダーのメッセージタイプフィールドは8に設定されています。
There is one mandatory object that MUST be included within a PCMonReq message: the MONITORING object (see Section 4.1). If the MONITORING object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING object missing). Other objects are optional.
PCMONREQメッセージに含める必要がある必須オブジェクトが1つあります：監視オブジェクト（セクション4.1を参照）。監視オブジェクトが欠落している場合、受信PCEはエラータイプ= 6（必須オブジェクトの欠落）およびエラー値= 4（監視オブジェクトが欠落）を使用してPCERRメッセージを送信する必要があります。他のオブジェクトはオプションです。
Format of a PCMonReq message (out-of-band request):
<PCMonReq Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<pce-list>]
[<svec-list>]
[<request-list>]
where:
ただし：
<pce-list>::=<PCE-ID>[<pce-list>]
<svec-list>::=<SVEC>
[<OF>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
[<XRO>]
<metric-list>::=<METRIC>[<metric-list>]
Format of a PCReq message with monitoring data requested (in-band
request):
<PCReq Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<pce-list>]
[<svec-list>]
<request-list>
where:
ただし：
<pce-list>::=<PCE-ID>[<pce-list>]
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
where:
ただし：
<metric-list>::=<METRIC>[<metric-list>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO, and LOAD-BALANCING objects are defined in [RFC5440]. The XRO object is defined in [RFC5521] and the OF object is defined in [RFC5541]. The PCC-ID-REQ object is defined in Section 4.2.
SVEC、RP、エンドポイント、LSPA、帯域幅、メトリック、RRO、IRO、および負荷分散オブジェクトは[RFC5440]で定義されています。XROオブジェクトは[RFC5521]で定義され、OFFICは[RFC5541]で定義されています。PCC-ID-REQオブジェクトは、セクション4.2で定義されています。
The PCMonReq message is used to gather various PCE state metrics along a path computation chain. The path computation chain may be determined by the PCC (in the form of a series of a series of PCE-ID objects defined in Section 4.3) according to policy specified on the PCC or alternatively may be determined by the path computation procedure. For example, if the BRPC procedure ([RFC5441]) is used to compute an inter-domain TE LSP, the path computation chain may be determined dynamically. In that case, the PCC sends a PCMonReq message that contains the PCEP objects that characterize the TE LSP attributes along with the MONITORING object (see Section 4.1) that lists the set of metrics of interest. If a list of PCEs is present in the monitoring request, it takes precedence over mechanisms used to dynamically determine the path computation chain. If a PCE receives a monitoring request that specifies a next-hop PCE in the PCE list that is unreachable, the request MUST be silently discarded.
PCMONREQメッセージは、パス計算チェーンに沿ってさまざまなPCE状態メトリックを収集するために使用されます。PATH計算チェーンは、PCCで指定されたポリシーに従ってPCC（セクション4.3で定義された一連のPCE-IDオブジェクトの形式で）によって決定される場合があります。たとえば、BRPC手順（[RFC5441]）を使用してドメイン間TE LSPを計算する場合、パス計算チェーンを動的に決定できます。その場合、PCCは、関心のあるメトリックのセットをリストする監視オブジェクト（セクション4.1を参照）とともにTE LSP属性を特徴付けるPCEPオブジェクトを含むPCMONREQメッセージを送信します。PCEのリストが監視要求に存在する場合、パス計算チェーンを動的に決定するために使用されるメカニズムよりも優先されます。PCEが、到達不可能なPCEリストに次のホップPCEを指定する監視要求を受信した場合、リクエストは静かに廃棄する必要があります。
Several PCE state metrics may be requested that are specified by a set of objects defined in Section 4. Note that this set of objects may be extended in the future.
セクション4で定義された一連のオブジェクトによって指定されたいくつかのPCE状態メトリックが要求される場合があります。このオブジェクトのセットは将来拡張される可能性があることに注意してください。
As pointed out in [RFC5440], several situations can arise in the form of:
[RFC5440]で指摘されているように、次の形でいくつかの状況が発生する可能性があります。
o a bundle of a set of independent and non-synchronized path computation requests,
o 独立した非同期パス計算要求のセットのバンドル、
o a bundle of a set of independent and synchronized path computation requests (SVEC object defined below required), or
o 独立した同期パス計算要求のセットのバンドル（以下で定義されているSVECオブジェクト）、または
o a bundle of a set of dependent and synchronized path computation requests (SVEC object defined below required).
o 依存および同期されたパス計算要求のセットのバンドル（以下に定義されているSVECオブジェクト）。
In the case of a bundle of a set of requests, the MONITORING object SHOULD only be present in the first PCReq or PCMonReq message, and the monitoring request applies to all the requests of the bundle, even in the case of dependent and/or synchronized requests sent using more than one PCReq or PCMonReq message.
一連のリクエストのバンドルの場合、監視オブジェクトは最初のPCREQまたはPCMONREQメッセージにのみ存在する必要があり、監視要求は、依存および/または同期の場合でもバンドルのすべてのリクエストに適用されます。複数のPCREQまたはPCMONREQメッセージを使用して送信されたリクエスト。
Examples of requests. For the sake of illustration, consider the three following examples:
リクエストの例。説明のために、次の3つの例を考えてみましょう。
Example 1 (out-of-band request): PCC1 makes a request to check the path computation chain that would be used should it request a path computation for a specific TE LSP named T1. A PCMonReq message is sent that contains a MONITORING object specifying a path computation check, along with the appropriate set of objects (e.g., RP, END-POINTS, etc.) that would be included in a PCReq message for T1.
例1（バンド外のリクエスト）：PCC1は、T1という名前の特定のTE LSPのパス計算を要求した場合に使用されるパス計算チェーンをチェックするリクエストを行います。T1のPCREQメッセージに含まれるオブジェクトの適切なセット（例：RP、エンドポイントなど）とともに、パス計算チェックを指定する監視オブジェクトを含むPCMONREQメッセージが送信されます。
Example 2 (in-band request): PCC1 requests a path computation for a TE LSP and also makes a request to gather the processing time along the path computation chain selected for the computation of T1. A PCReq message is sent that also contains a MONITORING object that specifies the performance metrics of interest.
例2（インバンドリクエスト）：PCC1は、TE LSPのパス計算を要求し、T1の計算用に選択されたパス計算チェーンに沿って処理時間を収集するリクエストも行います。関心のあるパフォーマンスメトリックを指定する監視オブジェクトも含まれるPCREQメッセージが送信されます。
Example 3 (out-of-band request): PCC2 requests to gather performance metrics along the specific path computation chain <pce1, pce2, pce3, pce7>. A PCMonReq message is sent to PCE1 that contains a MONITORING object and a sequence of PCE-ID objects that identify PCE1, PCE2, PCE3, and PCE7, respectively.
例3（バンド外のリクエスト）：PCC2は、特定のパス計算チェーン<PCE1、PCE2、PCE3、PCE7>に沿ってパフォーマンスメトリックを収集するよう要求します。監視オブジェクトとPCE1、PCE2、PCE3、およびPCE7をそれぞれ識別するPCE-IDオブジェクトのシーケンスを含むPCCE1に送信されます。
In all of the examples above, a PCRep message (in-band request) or PCMonReq message (out-of-band request) is sent in response to the request that reports the computed metrics.
上記のすべての例では、計算されたメトリックを報告するリクエストに応じて、PCREPメッセージ（インバンドリクエスト）またはPCMONREQメッセージ（バンド外リクエスト）が送信されます。
The PCMonRep message is used to provide PCE state metrics back to the requester for out-of-band monitoring requests. The Message-Type field of the PCEP common header for the PCMonRep message is set to 9.
PCMONREPメッセージは、帯域外監視要求のためにPCE状態メトリックを要求者に提供するために使用されます。PCMONREPメッセージのPCEP共通ヘッダーのメッセージタイプフィールドは9に設定されています。
There is one mandatory object that MUST be included within a PCMonRep message: the MONITORING object (see Section 4.1). If the MONITORING object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING object missing).
PCMONREPメッセージに含める必要がある必須オブジェクトが1つあります：監視オブジェクト（セクション4.1を参照）。監視オブジェクトが欠落している場合、受信PCEはエラータイプ= 6（必須オブジェクトの欠落）およびエラー値= 4（監視オブジェクトが欠落）を使用してPCERRメッセージを送信する必要があります。
Other objects are optional.
他のオブジェクトはオプションです。
Format of a PCMonRep (out-of-band request):
<PCMonRep Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<RP>]
[<metric-pce-list>]
where:
ただし：
<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce>::=<PCE-ID>
[<PROC-TIME>]
[<OVERLOAD>]
Format of a PCRep message with monitoring data (in band):
<PCRep Message> ::= <Common Header>
<response-list>
where:
ただし：
<response-list>::=<response>[<response-list>]
<response>::=<RP>
<MONITORING>
<PCC-ID-REQ>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
[<metric-pce-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
where:
ただし：
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-list>]
<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce>::=<PCE-ID>
[<PROC-TIME>]
[<OVERLOAD>]
The RP and the NO-PATH objects are defined in [RFC5440]. The PCC-ID-REQ object is defined in Section 4.2.
RPおよびNO-PATHオブジェクトは[RFC5440]で定義されています。PCC-ID-REQオブジェクトは、セクション4.2で定義されています。
If the path computation chain has been statically specified in the corresponding monitoring request using the series of a series of PCE-ID objects defined in Section 4.3, the monitoring request MUST use the same path computation chain (using the PCE list but in the reverse order).
パス計算チェーンが、セクション4.3で定義された一連のPCE-IDオブジェクトのシリーズを使用して対応する監視要求で静的に指定されている場合、監視要求は同じパス計算チェーンを使用する必要があります（PCEリストを使用しますが、逆の順序で）。
The PCEP objects defined in the document are compliant with the PCEP object format defined in [RFC5440]. The P flag and the I flag of the PCEP objects defined in this document SHOULD always be set to 0 on transmission and MUST be ignored on receipt since these flags are exclusively related to path computation requests.
ドキュメントで定義されているPCEPオブジェクトは、[RFC5440]で定義されているPCEPオブジェクト形式に準拠しています。このドキュメントで定義されているPCCEPオブジェクトのiフラグは、常に送信時に0に設定する必要があり、これらのフラグはパス計算要求にのみ関連しているため、受領時に無視する必要があります。
Several objects are defined in this section that can be carried within the PCEP PCReq or PCRep messages defined in [RFC5440] in the case of in-band monitoring requests (the PCC requests the computation of the TE LSP in addition to gathering PCE state metrics). In the case of out-of-band monitoring requests, the objects defined in this section are carried within PCMonReq and PCMonRep messages.
このセクションでは、インバンド監視要求の場合に[RFC5440]で定義されたPCEP PCREQまたはPCREPメッセージ内で運ばれるいくつかのオブジェクトが定義されています（PCCは、PCE州のメトリックを収集することに加えてTE LSPの計算を要求します）。バンド外の監視要求の場合、このセクションで定義されているオブジェクトは、PCMONREQおよびPCMONREPメッセージ内で運ばれます。
All TLVs carried in objects defined in this document have the TLV format defined in [RFC5440]:
このドキュメントで定義されているオブジェクトで運ばれるすべてのTLVには、[RFC5440]で定義されているTLV形式があります。
o Type: 2 bytes
o タイプ：2バイト
o Length: 2 bytes
o 長さ：2バイト
o Value: variable
o 値：変数
A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes specifying the TLV length, and a value field. The Length field defines the length of the value portion in bytes. The TLV is padded to 4-byte alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes). Unrecognized TLVs MUST be ignored.
PCEPオブジェクトTLVは、タイプの2バイト、TLVの長さを指定する2バイト、値フィールドで構成されています。長さフィールドは、バイト内の値部分の長さを定義します。TLVは、4バイトのアライメントにパッドで埋められています。パディングは長さフィールドには含まれていません（3バイトの値の長さは3ですが、TLVの合計サイズは8バイトです）。認識されていないTLVは無視する必要があります。
The MONITORING object MUST be present within PCMonReq and PCMonRep messages (out-of-band monitoring requests) and MAY be carried within PCRep and PCReq messages (in-band monitoring requests). There SHOULD NOT be more than one instance of the MONITORING object in a PCMonReq or PCMonRep message: if more than one instance of the MONITORING object is present, the recipient MUST process the first instance and MUST ignore other instances.
監視オブジェクトは、PCMONREQおよびPCMONREPメッセージ（バンド外の監視リクエスト）内に存在する必要があり、PCREPおよびPCREQメッセージ（インバンド監視要求）内に携帯することができます。PCMONREQまたはPCMONREPメッセージには、監視オブジェクトの1つ以上のインスタンスがあるはずです。監視オブジェクトの複数のインスタンスが存在する場合、受信者は最初のインスタンスを処理し、他のインスタンスを無視する必要があります。
The MONITORING object is used to specify the set of requested PCE state metrics.
監視オブジェクトは、要求されたPCE状態メトリックのセットを指定するために使用されます。
The MONITORING Object-Class (19) has been assigned by IANA.
監視オブジェクトクラス（19）はIANAによって割り当てられています。
The MONITORING Object-Type (1) has been assigned by IANA.
監視オブジェクトタイプ（1）はIANAによって割り当てられています。
The format of the MONITORING object body is as follows:
監視オブジェクト本体の形式は次のとおりです。
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 | Flags |I|C|P|G|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Monitoring-id-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 24 bits
フラグ：24ビット
The following flags are currently defined:
現在、次のフラグが定義されています。
L (Liveness) - 1 bit: when set, this indicates that the state metric of interest is the PCE's liveness and thus the PCE MUST include a PCE-ID object in the corresponding reply. The L bit MUST always be ignored in a PCMonRep or PCRep message.
l（livension）-1 bit：設定すると、これは目的の状態メトリックがPCEのlivenivesであることを示しているため、PCEには対応する応答にPCE -IDオブジェクトを含める必要があります。Lビットは、PCMONREPまたはPCREPメッセージで常に無視する必要があります。
G (General) - 1 bit: when set, this indicates that the monitoring request is a general monitoring request. When the requested performance metric is specific, the G bit MUST be cleared. The G bit MUST always be ignored in a PCMonRep or PCRep message.
G（一般）-1ビット：設定すると、これは監視要求が一般的な監視要求であることを示します。要求されたパフォーマンスメトリックが固有の場合、Gビットをクリアする必要があります。Gビットは、PCMONREPまたはPCREPメッセージで常に無視する必要があります。
P (Processing Time) - 1 bit: the P bit of the MONITORING object carried in a PCMonReq or a PCReq message is set to indicate that the processing times is a metric of interest. If allowed by policy, a PROC-TIME object MUST be inserted in the corresponding PCMonRep or PCRep message. The P bit MUST always be ignored in a PCMonRep or PCRep message.
P（処理時間）-1ビット：PCMONREQまたはPCREQメッセージで運ばれる監視オブジェクトのPビットは、処理時間が対象のメトリックであることを示すように設定されています。ポリシーで許可されている場合、対応するPCMONREPまたはPCREPメッセージにPROC-TIMEオブジェクトを挿入する必要があります。Pビットは、PCMONREPまたはPCREPメッセージで常に無視する必要があります。
C (Overload) - 1 bit: The C bit of the MONITORING object carried in a PCMonReq or a PCReq message is set to indicate that the overload status is a metric of interest, in which case an OVERLOAD object MUST be inserted in the corresponding PCMonRep or PCRep message. The C bit MUST always be ignored in a PCMonRep or PCRep message.
C（過負荷）-1ビット：PCMONREQまたはPCREQメッセージに携帯されている監視オブジェクトのCビットは、過負荷ステータスが対応するPCMONREPに過負荷オブジェクトを挿入する必要があることを示すように設定されています。またはpcrepメッセージ。Cビットは、PCMONREPまたはPCREPメッセージで常に無視する必要があります。
I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message and that message does not trigger any policy violation, but the PCE cannot provide any of the set of requested performance metrics for unspecified reasons, the PCE MUST set the I bit. The I bit has no meaning in a request and SHOULD be ignored on receipt.
I（不完全）-1ビット：PCEが受信したPCMONREQメッセージをサポートし、そのメッセージがポリシー違反をトリガーしない場合、PCEは不特定の理由で要求されたパフォーマンスメトリックのセットを提供できません。PCEはiビットを設定する必要があります。I Bitにはリクエストには意味がありません。受領時に無視する必要があります。
Monitoring-id-number (32 bits): The monitoring-id-number value combined with the PCC-REQ-ID identifying the requesting PCC uniquely identifies the monitoring request context. The monitoring-id-number MUST start at a non-zero value and MUST be incremented each time a new monitoring request is sent to a PCE. Each increment SHOULD have a value of 1 and may cause a wrap back to zero. If no reply to a monitoring request is received from the PCE, and the PCC wishes to resend its path computation monitoring request, the same monitoring-id-number MUST be used. Conversely, a different monitoring-id-number MUST be used for different requests sent to a PCE. A PCEP implementation SHOULD checkpoint the Monitoring-id-number of pending monitoring requests in case of restart thus avoiding the reuse of a Monitoring-id-number of an in-process monitoring request.
監視-ID-Number（32ビット）：PCC-REQ-IDと組み合わせた監視-ID-Number値は、要求PCCを識別し、監視要求のコンテキストを一意に識別します。監視-ID-Numberは、ゼロ以外の値で開始する必要があり、新しい監視要求がPCEに送信されるたびに増加する必要があります。各増分の値は1の値で、ラップをゼロに戻す可能性があります。PCEから監視要求への返信が受信されず、PCCがパス計算監視リクエストを再送信したい場合は、同じ監視-ID-Numberを使用する必要があります。逆に、PCEに送信された異なる要求には、別の監視ID-Numberを使用する必要があります。PCEPの実装は、再起動の場合に監視-ID保留中の監視要求の監視番号をチェックポイントする必要があります。
Unassigned bits are considered as reserved and MUST be set to zero on transmission and ignored on reception.
未割り当てのビットは予約されていると見なされ、送信時にゼロに設定し、受信で無視する必要があります。
No optional TLVs are currently defined.
現在、オプションのTLVは定義されていません。
The PCC-ID-REQ object is used to specify the IP address of the requesting PCC.
PCC-ID-REQオブジェクトは、要求するPCCのIPアドレスを指定するために使用されます。
The PCC-ID-REQ MUST be inserted within a PCReq or a PCMonReq message to specify the IP address of the requesting PCC.
PCC-ID-REQをPCREQまたはPCMONREQメッセージ内に挿入して、要求するPCCのIPアドレスを指定する必要があります。
Two PCC-ID-REQ objects (for IPv4 and IPv6) are defined. PCC-ID-REQ Object-Class (20) has been assigned by IANA. PCC-ID-REQ Object-Type (1 for IPv4 and 2 for IPv6) has been assigned by IANA.
2つのPCC-ID-REQオブジェクト（IPv4およびIPv6用）が定義されています。PCC-ID-REQオブジェクトクラス（20）はIANAによって割り当てられています。PCC-ID-REQオブジェクトタイプ（IPv4の場合は1、IPv6の場合は2）がIANAによって割り当てられています。
The format of the PCC-ID-REQ object body for IPv4 and IPv6 are as follows:
IPv4およびIPv6用のPCC-ID-REQオブジェクト本体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PCC-ID-REQ object body has a fixed length of 4 octets for IPv4 and 16 octets for IPv6.
PCC-ID-REQオブジェクト本体の固定長は、IPv4の4オクテット、IPv6で16オクテットです。
The PCE-ID object is used to specify a PCE's IP address. The PCE-ID object can either be used to specify the list of PCEs for which monitoring data is requested and to specify the IP address of the requesting PCC.
PCE-IDオブジェクトは、PCEのIPアドレスを指定するために使用されます。PCE-IDオブジェクトは、監視データが要求されるPCEのリストを指定し、要求するPCCのIPアドレスを指定するために使用できます。
A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq message to specify the PCE for which PCE state metrics are requested and in a PCMonRep or a PCRep message to record the IP address of the PCE reporting PCE state metrics or that was involved in the path computation chain.
PCE-IDオブジェクトのセットをPCREQまたはPCMONREQメッセージ内に挿入して、PCE状態メトリックが要求されるPCEとPCMONREPまたはPCREPメッセージでPCEREPまたはPCEレポートのIPアドレスを記録するPCREPメッセージまたはPCCREPメッセージを指定できます。パス計算チェーンに関与していました。
Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object-Class (25) has been assigned by IANA. PCE-ID Object-Type (1 for IPv4 and 2 for IPv6) has been assigned by IANA.
2つのPCE-IDオブジェクト（IPv4およびIPv6用）が定義されています。PCE-IDオブジェクトクラス（25）はIANAによって割り当てられています。PCE-IDオブジェクトタイプ（IPv4の場合は1、IPv6の場合は2）がIANAによって割り当てられています。
The format of the PCE-ID object body for IPv4 and IPv6 are as follows:
IPv4およびIPv6のPCE-IDオブジェクト本体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 octets for IPv6.
PCE-IDオブジェクト本体の固定長は、IPv4の4オクテット、IPv6で16オクテットです。
When a dynamic discovery mechanism is used for PCE discovery, a PCE advertises its PCE address in the PCE-ADDRESS sub-TLV defined in [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and PCMonReq messages and a PCE MUST also use this address in PCRep and PCMonRep messages.
動的発見メカニズムがPCE発見に使用される場合、PCEは[RFC5088]および[RFC5089]で定義されたPCE-AddressサブTLVでPCEアドレスを宣伝します。PCCはこのアドレスをPCREQおよびPCMONREQメッセージで使用する必要があり、PCEはこのアドレスもPCREPおよびPCMONREPメッセージで使用する必要があります。
If allowed by policy, the PCE includes a PROC-TIME object within a PCMonRep or a PCRep message if the P bit of the MONITORING object carried within the corresponding PCMonReq or PCReq message is set. The PROC-TIME object is used to report various processing time related metrics.
ポリシーで許可されている場合、PCEには、対応するPCMONREQまたはPCREQメッセージが設定されている監視オブジェクトのPビットが設定されている場合、PCMONREPまたはPCREPメッセージ内のPROC-TIMEオブジェクトが含まれます。Proc-Timeオブジェクトは、さまざまな処理時間関連メトリックを報告するために使用されます。
1) Case of general monitoring requests
1) 一般的な監視要求の場合
A PCC may request processing time metrics for general monitoring requests (e.g., the PCC may want to know the minimum, maximum, and average processing times on a particular PCE). In this case, general requests can only be made by using PCMonReq/PCMonRep messages. The Current-processing-time field (as explained below) is exclusively used for specific monitoring requests and MUST be cleared for general monitoring requests. The algorithms used by a PCE to compute the minimum, maximum, average, and variance of the processing times are out of the scope of this document (a PCE may decide to compute the minimum processing time over a period of time, for the last N path computation requests, etc.).
PCCは、一般的な監視要求の処理時間メトリックを要求する場合があります（たとえば、PCCは、特定のPCEの最小、最大、および平均処理時間を知りたい場合があります）。この場合、一般的な要求は、PCMONREQ/PCMONREPメッセージを使用することによってのみ行うことができます。現在の処理時間フィールド（以下で説明したように）は、特定の監視要求にのみ使用され、一般的な監視要求のためにクリアする必要があります。PCEが使用するアルゴリズムは、処理時間の最小、最大、平均、および分散を計算するためにこのドキュメントの範囲外です（PCEは、最後のnの期間にわたって最小処理時間を計算することを決定する場合があります。パス計算要求など）。
2) Case of specific monitoring requests
2) 特定の監視要求の場合
In the case of a specific request, the algorithms used by a PCE to compute the Processing-time metrics are out of the scope of this document, but a flag is specified that is used to indicate to the requester whether the processing time value was estimated or computed. The PCE may either (1) estimate the processing time without performing an actual path computation or (2) effectively perform the computation to report the processing time. In the former case, the E bit of the PROC-TIME object MUST be set. The G bit MUST be cleared and the Min-processing-time, Max-processing-time, Average-processing-time, and Variance-processing-time MUST be set to 0x00000000.
特定の要求の場合、PCEが処理時間メトリックを計算するために使用するアルゴリズムはこのドキュメントの範囲外ですが、処理時間値が推定されたかどうかを要求者に示すために使用されるフラグが指定されています。または計算されました。PCEは、（1）実際のパス計算を実行せずに処理時間を推定するか、（2）処理時間を報告するために計算を効果的に実行することができます。前者の場合、Proc-TimeオブジェクトのEビットを設定する必要があります。Gビットをクリアする必要があり、最小処理時間、最大処理時間、平均処理時間、分散処理時間を0x00000000に設定する必要があります。
When the processing time is requested in addition to a path computation (case where the MONITORING object is carried within a PCReq message), the PROC-TIME object always reports the actual processing time for that request and thus the E bit MUST be cleared.
PATH計算（監視オブジェクトがPCREQメッセージ内で運ばれる場合）に加えて処理時間が要求される場合、ProC-Timeオブジェクトは常にその要求の実際の処理時間を報告するため、Eビットをクリアする必要があります。
The PROC-TIME Object-Class (26) has been assigned by IANA.
Proc-Timeオブジェクトクラス（26）はIANAによって割り当てられています。
The PROC-TIME Object-Type (1) has been assigned by IANA.
Proc-Timeオブジェクトタイプ（1）はIANAによって割り当てられています。
The format of the PROC-TIME object body is as follows:
Proc-Timeオブジェクト本体の形式は次のとおりです。
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 | Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average-processing time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variance-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 16 bits - one flag is currently defined:
フラグ：16ビット-1つのフラグが現在定義されています：
E (Estimated) - 1 bit: when set, this indicates that the reported metric value is based on estimated processing time as opposed to actual computations.
E（推定）-1ビット：設定すると、これは報告されたメトリック値が実際の計算ではなく推定処理時間に基づいていることを示します。
Unassigned bits are considered as reserved and MUST be set to zero on transmission.
未割り当てのビットは予約されていると見なされ、伝送でゼロに設定する必要があります。
Current-processing-time: This field indicates, in milliseconds, the processing time for the path computation of interest characterized in the corresponding PCMonReq message.
現在の処理時間：このフィールドは、ミリ秒単位で、対応するPCMONREQメッセージに特徴付けられる関心のパス計算の処理時間を示しています。
Min-processing-time: This field indicates, in milliseconds, the minimum processing time.
最小加工時間：このフィールドは、ミリ秒単位で、最小処理時間を示します。
Max-processing-time: This field indicates, in milliseconds, the maximum processing time.
最大処理時間：このフィールドは、ミリ秒単位で、最大処理時間を示します。
Average-processing-time: This field indicates, in milliseconds, the average processing time.
平均処理時間：このフィールドは、ミリ秒単位で、平均処理時間を示しています。
Variance-processing-time: This field indicates, in milliseconds, the variance of the processing times.
分散処理時間：このフィールドは、ミリ秒単位で、処理時間の分散を示します。
Since the PCC may potentially use monitoring metrics as input to their PCE selection, it MAY be required to normalize how time metrics (along with others metrics described in further revision of this document) are computed to ensure consistency between the monitoring metrics computed by a set of PCEs.
PCCは、PCE選択への入力として監視メトリックを潜在的に使用する可能性があるため、時間メトリック（このドキュメントのさらなる改訂で説明されている他のメトリックとともに）を正規化する必要がある場合があります。pcesの。
The OVERLOAD object is used to report a PCE processing congestion state. Note that "overload" as indicated by this object refers to the processing state of the PCE and its ability to handle new PCEP requests. A PCE is overloaded when it has a backlog of PCEP requests such that it cannot immediately start to process a new request thus leading to waiting times. The overload duration is quantified as being the (estimated) time until the PCE expects to be able to immediately process a new PCEP request.
オーバーロードオブジェクトは、PCE処理の混雑状態を報告するために使用されます。このオブジェクトで示されるように「過負荷」とは、PCEの処理状態と新しいPCEP要求を処理する能力を指します。PCEは、PCEPリクエストのバックログがある場合に過負荷になり、すぐに新しいリクエストの処理を開始できないため、待ち時間につながります。過負荷期間は、PCEが新しいPCEP要求をすぐに処理できると予想されるまで、（推定）時間として定量化されます。
The OVERLOAD object MUST be present within a PCMonRep or a PCRep message if the C bit of the MONITORING object carried within the corresponding PCMonReq or PCReq message is set and the PCE is experiencing a congested state. The OVERLOAD Object-Class (27) has been assigned by IANA. The overload Object-Type (1) has been assigned by IANA.
対応するPCMONREQまたはPCREQメッセージが設定されており、PCEが混雑した状態が発生している場合、監視オブジェクトのCビットがPCMONREPまたはPCREPメッセージ内に存在する必要があります。オーバーロードオブジェクトクラス（27）はIANAによって割り当てられています。オーバーロードオブジェクトタイプ（1）はIANAによって割り当てられています。
The format of the CONGESTION object body is as follows:
輻輳オブジェクト本体の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Overload Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits - No flag is currently defined.
フラグ：8ビット - 現在、フラグは定義されていません。
Overload duration - 16 bits: This field indicates the amount of time, in seconds, that the responding PCE expects that it may continue to be overloaded from the time that the response message was generated. The receiver MAY use this value to decide whether or not to send further requests to the same PCE.
過負荷期間-16ビット：このフィールドは、秒単位での時間を示し、応答するPCEは、応答メッセージが生成された時点から過負荷になり続けることを期待しています。受信者は、この値を使用して、同じPCEにさらにリクエストを送信するかどうかを決定できます。
It is worth noting that a PCE along a path computation chain involved in the monitoring request may decide to learn from the overload information received by one of downstream PCEs in the chain.
監視要求に関与するパス計算チェーンに沿ったPCEが、チェーン内の下流のPCESの1つが受け取った過負荷情報から学習することを決定する可能性があることは注目に値します。
The receipt of a PCMonReq message may trigger a policy violation on some PCE; in which case, the PCE MUST send a PCErr message with Error-type=5 and Error-value=6.
PCMONREQメッセージの受領は、一部のPCEでポリシー違反をトリガーする場合があります。その場合、PCEはエラータイプ= 5およびエラー値= 6でPCERRメッセージを送信する必要があります。
I bit processing: as indicated in Section 4.1, if a PCE supports a received PCMonReq message and that message does not trigger any policy violation, but the PCE cannot provide any of the set of requested performance metrics for unspecified reasons, the PCE MUST set the I bit. Once set, the I bit MUST NOT be changed by a receiving PCE.
私は処理をビットします：セクション4.1で示されているように、PCEが受信したPCMONREQメッセージをサポートし、そのメッセージがポリシー違反をトリガーしない場合、PCEは不特定の理由で要求されたパフォーマンスメトリックのセットを提供できません。私は噛みつきます。設定したら、I BITを受信PCEによって変更してはなりません。
Upon receiving a PCMonReq message:
PCMONREQメッセージを受信すると：
1) As specified in [RFC5440], if the PCE does not support the PCMonReq message, the PCE peer MUST send a PCErr message with Error-value=2 (capability not supported). According to the procedure defined in Section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages at a rate equal of greater than specified rate, the PCC/PCE must send a PCEP CLOSE message with close value=5 "Reception of an unacceptable number of unrecognized PCEP messages". In this case, the PCC/PCE must also close the TCP session and must not send any further PCEP messages on the PCEP session.
1) [RFC5440]で指定されているように、PCEがPCMONREQメッセージをサポートしていない場合、PCE PEERはError-Value = 2（サポートされていない機能）でPCERRメッセージを送信する必要があります。[RFC5440]のセクション6.9で定義されている手順によれば、PCC/PCEが指定されたレートよりも大きいレートで認識されていないメッセージを受信する場合、PCC/PCEはPCEPの近接メッセージを閉じる値= 5 "の受信で送信する必要があります。受け入れられない数の認識されていないPCEPメッセージ」。この場合、PCC/PCEもTCPセッションを閉じる必要があり、PCEPセッションでさらにPCEPメッセージを送信してはなりません。
2) If the PCE supports the PCMonReq message but the monitoring request is prohibited by policy, the PCE must follow the procedure specified in Section 5. As pointed out in Section 4.3, a PCE may still partially satisfy a request, leaving out some of the required data if not allowed by policy.
2) PCEがPCMONREQメッセージをサポートしているが、監視要求がポリシーによって禁止されている場合、PCEはセクション5で指定された手順に従う必要があります。ポリシーで許可されていない場合。
3) If the PCE supports the PCMonReq and the monitoring request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain. If the PCE is not the last element of the path computation chain, the PCMonReq message is relayed to the next-hop PCE: such a next hop may be either specified by means of a PCE-ID object present in the PCMonReq message or dynamically determined by means of a procedure outside of the scope of this document. Conversely, if the PCE is the last PCE of the path computation chain, the PCE originates a PCMonRep message that contains the requested objects according to the set of requested PCE states metrics listed in the MONITORING object carried in the corresponding PCMonReq message.
3) PCEがPCMONREQをサポートし、監視要求がポリシーによって禁止されていない場合、受信PCEは最初にパス計算チェーンの最後のPCEであるかどうかを判断する必要があります。PCEがパス計算チェーンの最後の要素ではない場合、PCMONREQメッセージは次のホップPCEに中継されます。このような次のホップは、PCMONREQメッセージに存在するPCE-IDオブジェクトによって指定されるか、動的に決定された場合には、このドキュメントの範囲外の手順によって。逆に、PCEがパス計算チェーンの最後のPCEである場合、PCEは、対応するPCMONREQメッセージに掲載された監視オブジェクトにリストされている要求されたPCE状態メトリックのセットに従って要求されたオブジェクトを含むPCMONREPメッセージを発信します。
Upon receiving a PCReq message that carries a MONITORING and potentially other monitoring objects (e.g., PCE-ID object):
監視および潜在的に他の監視オブジェクト（PCE-IDオブジェクトなど）を搭載したPCREQメッセージを受信すると：
1) As specified in [RFC5440], if the PCE does not support (in-band) monitoring, the PCE peer MUST send a PCErr message with Error-value=2 (capability not supported). According to the procedure defined in Section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages at a rate equal or greater than a specified rate, the PCC/PCE must send a PCEP CLOSE message with close value=5 "Reception of an unacceptable number of unrecognized PCEP messages". In this case, the PCC/PCE must also close the TCP session and must not send any further PCEP messages on the PCEP session.
1) [RFC5440]で指定されているように、PCEが（インバンド）監視をサポートしていない場合、PCEピアはエラー値= 2（サポートされていない機能）でPCERRメッセージを送信する必要があります。[RFC5440]のセクション6.9で定義されている手順によれば、PCC/PCEが指定されたレートよりも等しいレートまたは大きいレートで認識されていないメッセージを受信する場合、PCC/PCEは、閉じる値= 5 "の受信でPCEP近接メッセージを送信する必要があります。受け入れられない数の認識されていないPCEPメッセージ」。この場合、PCC/PCEもTCPセッションを閉じる必要があり、PCEPセッションでさらにPCEPメッセージを送信してはなりません。
2) If the PCE supports the monitoring request but the monitoring request is prohibited by policy, the PCE must follow the procedure specified in Section 5. As pointed out in Section 4.3, a PCE may still partially satisfy a request, leaving out some of the required data if not allowed by policy.
2) PCEが監視要求をサポートしているが、監視要求がポリシーによって禁止されている場合、PCEはセクション5で指定された手順に従う必要があります。セクション4.3で指摘されているように、PCEは依然として要求を部分的に満たし、必要なデータの一部を除外することができます。ポリシーで許可されていない場合。
3) If the PCE supports the monitoring request and that request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain. If the PCE is not the last element of the path computation chain, the PCReq message (with the MONITORING object and potentially other monitoring objects such as the PCE-ID) is relayed to the next-hop PCE: such a next hop may be either specified by means of a PCE-ID object present in the PCReq message or dynamically determined by means of a procedure outside of the scope of this document.
3) PCEが監視要求をサポートし、その要求がポリシーによって禁止されていない場合、受信PCEは最初にパス計算チェーンの最後のPCEであるかどうかを判断する必要があります。PCEがパス計算チェーンの最後の要素ではない場合、PCREQメッセージ（監視オブジェクトとPCE-IDなどの潜在的に他の監視オブジェクトを使用）が次のホップPCEに中継されます。PCREQメッセージに存在するPCE-IDオブジェクトによって指定されているか、このドキュメントの範囲外の手順によって動的に決定されます。
Conversely, if the PCE is the last PCE of the path computation chain, the PCE originates a PCRep message that contains the requested objects according to the set of requested PCE states metrics listed in the MONITORING and potentially other monitoring objects carried in the corresponding PCReq message.
逆に、PCEがパス計算チェーンの最後のPCEである場合、PCEは、監視にリストされている要求されたPCE状態メトリックのセットに従って要求されたオブジェクトを含むPCREPメッセージを発信し、対応するPCREQメッセージに掲載される潜在的に他の監視オブジェクトが。
Upon receiving a PCMonRep message, the PCE processes the request, adds the relevant objects to the PCMonRep message and forwards the PCMonRep message to the upstream requesting PCE or PCC.
PCMONREPメッセージを受信すると、PCEはリクエストを処理し、関連するオブジェクトをPCMONREPメッセージに追加し、PCMONREPメッセージをアップストリームリクエストPCCまたはPCCに転送します。
Upon receiving a PCRep message that carries monitoring data, the message is processed, additional monitoring data is added according to this specification, and the message is forwarded upstream to the requesting PCE or PCC.
監視データを伝達するPCREPメッセージを受信すると、メッセージが処理され、追加の監視データがこの仕様に従って追加され、メッセージは要求のPCEまたはPCCに上流に転送されます。
It MUST be possible to configure the activation/deactivation of PCEP monitoring on a PCEP speaker. In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring on a PCE whether or not specific, generic, in-band and out-of-band monitoring requests are allowed. Also, a PCEP implementation SHOULD allow configuring on a PCE a list of authorized state metrics (aliveness, overload, processing time, etc.). This may apply to any session in which the PCEP speaker participates, to a specific session with a given PCEP peer or to a specific group of sessions with a specific group of PCEP peers, for instance, the PCEP peers of a neighbor AS.
PCEPスピーカーでのPCEPモニタリングの活性化/非アクティブ化を構成することが可能である必要があります。[RFC5440]のセクション8.1に既にリストされているパラメーターに加えて、PCEPの実装により、特定、汎用、帯域内、およびバンド外の監視要求が許可されているかどうかにかかわらず、PCEで設定できるようにする必要があります。また、PCEPの実装では、PCEで承認された状態メトリックのリスト（Alivension、過負荷、処理時間など）を構成できるようにする必要があります。これは、PCEPスピーカーが参加する任意のセッション、特定のPCEPピアとの特定のセッション、または特定のPCEPピアのグループ、たとえば隣人のPCEPピアとのセッションの特定のグループに適用される場合があります。
A new MIB Module may be defined that provides local PCE state metrics, as well as state metrics of other PCEs gathered using mechanisms defined in this document.
ローカルPCE状態メトリックを提供する新しいMIBモジュールと、このドキュメントで定義されたメカニズムを使用して収集された他のPCEの状態メトリックを提供する新しいMIBモジュールを定義できます。
This document provides mechanisms to monitor the liveliness and performances of a given path computation chain.
このドキュメントは、特定のパス計算チェーンの活気とパフォーマンスを監視するメカニズムを提供します。
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、新しい操作検証要件を意味するものではありません。
Mechanisms defined in this document do not imply any requirements on other protocols in addition to those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものに加えて、他のプロトコルの要件を意味するものではありません。
The frequency of PCMonReq messages may impact the operations of PCEs. An implementation SHOULD allow a limit to be placed on the rate of PCMonReq messages sent by a PCEP speaker and processed from a peer. It SHOULD also allow sending a notification when a rate threshold is reached. An implementation SHOULD allow handling PCReq messages with a higher priority than PCMonReq messages. An implementation SHOULD allow the configuration of a second limit for the PCReq message requesting monitoring data.
PCMONREQメッセージの頻度は、PCESの操作に影響を与える可能性があります。実装により、PCEPスピーカーから送信され、ピアから処理されるPCMONREQメッセージのレートに制限を設定できるようにする必要があります。また、レートのしきい値に達したときに通知を送信できるようにする必要があります。実装では、PCROMREQメッセージよりも優先度が高いPCREQメッセージを処理できるようにする必要があります。実装により、監視データを要求するPCREQメッセージの2番目の制限の構成を可能にする必要があります。
An important concern while processing overload information is to prevent the overload condition on one PCE simply being moved to another PCE. Indeed, there is a risk that the reaction to an indication of overload will act to increase the amount of overload within the network. Furthermore, this may lead to oscillations between PCEs if the overload information is not handled properly.
過負荷情報を処理する際の重要な懸念は、あるPCEの過負荷状態が単に別のPCEに移動するのを防ぐことです。実際、過負荷の兆候に対する反応が、ネットワーク内の過負荷の量を増やすために作用するというリスクがあります。さらに、これは、過負荷情報が適切に処理されない場合、PCE間の振動につながる可能性があります。
This section presents some brief guidance on how a PCC (which term includes a PCE making requests of another PCE) should react when it receives an indication that a PCE is overloaded.
このセクションでは、PCC（この用語には別のPCEのリクエストが含まれる）が、PCEが過負荷になっていることを示したときにどのように反応するかについての簡単なガイダンスを示します。
When an overload indication is received (on a PCRep message or on a PCMonRep message), it identifies that new PCReq messages sent to the PCE might be subject to a delay equal to the value in the Overload Duration field (when present).
過負荷の表示が受信されると（PCREPメッセージまたはPCMONREPメッセージ）、PCEに送信された新しいPCREQメッセージが、過負荷期間フィールドの値に等しい遅延（存在する場合）に等しい可能性があることを識別します。
It also indicates that PCReq messages already queued at the PCE might be subject to a delay. The PCC must decide how to handle new PCReq messages and what to do about PCReq messages already queued at the PCE.
また、PCEで既にキューに留められているPCREQメッセージが遅延の対象となる可能性があることも示しています。PCCは、新しいPCREQメッセージを処理する方法と、PCEですでにキューに留められているPCREQメッセージについて何をすべきかを決定する必要があります。
It is RECOMMENDED that a PCC does not cancel a queued PCReq and reissue it to another PCE because of the PCE being overloaded.
PCCがキュウーPCREQをキャンセルして、PCEが過負荷になっているため、別のPCEに再発行しないことをお勧めします。
Such behavior is likely to result in overload thrashing as multiple PCCs move the PCE queue to another PCE. This would simply introduce additional delay in the processing of all requests. A PCC MAY choose to cancel a queued PCE request if it is willing to sacrifice the request, maybe reissuing it later (after the overload condition has been determined to have cleared by use of a PCMonReq/Rep exchange).
このような動作は、複数のPCCがPCEキューを別のPCEに移動するため、過負荷のスラッシングをもたらす可能性があります。これにより、すべてのリクエストの処理に追加の遅延が導入されます。PCCは、リクエストを犠牲にする意思がある場合は、キューに囲まれたPCEリクエストをキャンセルすることを選択できます。後で再発行する可能性があります（過負荷状態がPCMONREQ/REP Exchangeを使用してクリアされたと判断された後）。
It is then RECOMMENDED to send the cancellation request with a higher priority in order for the overloaded PCE to detect the request cancellation before processing the related request.
その後、過負荷のPCEが関連するリクエストを処理する前に要求キャンセルを検出するために、より高い優先度でキャンセル要求を送信することをお勧めします。
A PCC that is aware of PCE overload at one PCE MAY select a different PCE to service its next PCReq message. In doing so, it is RECOMMENDED that the PCC consider whether the other PCE is overloaded or might be likely to become overloaded by other PCCs similarly directing new PCReq messages.
1つのPCEでのPCE過負荷を認識しているPCCは、次のPCREQメッセージにサービスを提供するために異なるPCEを選択できます。そうすることで、PCCは、他のPCCが他のPCCによって過負荷になっているかどうかを検討することをお勧めします。
Furthermore, should the second PCE be also overloaded, it is RECOMMENDED not to make any attempt to switch back to the other PCE without knowing that the first PCE is no longer overloaded.
さらに、2番目のPCEも過負荷になった場合、最初のPCEが過負荷にならないことを知らずに、他のPCEに切り替えようとしないことをお勧めします。
Each PCEP message has a message type value.
各PCEPメッセージにはメッセージタイプ値があります。
Two new PCEP (specified in [RFC5440]) messages are defined in this document:
2つの新しいPCEP（[RFC5440]で指定）メッセージは、このドキュメントで定義されています。
Value Description Reference 8 Path Computation Monitoring Request (PCMonReq) This document 9 Path Computation Monitoring Reply (PCMonRep) This document
値説明参照8パス計算監視要求（PCMONREQ）このドキュメント9パス計算監視応答（PCMONREP）このドキュメント
Each PCEP object has an Object-Class and an Object-Type. The following new PCEP objects are defined in this document:
各PCEPオブジェクトには、オブジェクトクラスとオブジェクトタイプがあります。次の新しいPCEPオブジェクトは、このドキュメントで定義されています。
Object-Class Value Name Object-Type Reference
オブジェクトクラス値名オブジェクトタイプリファレンス
19 MONITORING 1 This document
20 PCC-REQ-ID 1: IPv4 addresses This document 2: IPv6 addresses
20 PCC-REQ-ID 1：IPv4アドレスこのドキュメント2：IPv6アドレス
25 PCE-ID 1: IPv4 addresses This document 2: IPv6 addresses This document
25 PCE-ID 1：IPv4がこのドキュメントに対処する2：IPv6はこのドキュメントにアドレス指定します
26 PROC-TIME 1 This document
27 OVERLOAD 1: overload This document
A registry was created for the Error-type and Error-value of the PCEP Error Object.
PCEPエラーオブジェクトのエラータイプとエラー価値のレジストリが作成されました。
A new Error-value for the PCErr message Error-type=5 (Policy Violation) (see [RFC5440]) is defined in this document.
PCERRメッセージの新しいエラー価値エラータイプ= 5（ポリシー違反）（[RFC5440]を参照）は、このドキュメントで定義されています。
Error-type Meaning Error-value Reference
5 Policy violation 6: Monitoring message This document supported but rejected due to policy violation
5ポリシー違反6：監視メッセージこのドキュメントはサポートされていますが、ポリシー違反により拒否されました
A new Error-value for the PCErr message Error-type=6 (Mandatory object missing) (see [RFC5440]) is defined in this document.
PCERRメッセージの新しいエラー価値エラータイプ= 6（必須オブジェクトの欠落）（[RFC5440]を参照）は、このドキュメントで定義されています。
Error-type Meaning Error-value Reference
6 Mandatory Object 4: MONITORING object This document missing missing
6必須オブジェクト4：オブジェクトの監視このドキュメントがありません
IANA has created a registry to manage the Flag field of the MONITORING object.
IANAは、監視オブジェクトのフラグフィールドを管理するためのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit should be tracked with the following qualities:
新しいビット番号は、IETFレビューによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
o ビット番号（ビット0から最も重要なビットとしてカウント）
o Capability Description
o 機能の説明
o Defining RFC
o RFCの定義
Several bits are defined for the MONITORING Object flag field in this document:
このドキュメントの監視オブジェクトフラグフィールドには、いくつかのビットが定義されています。
Codespace of the Flag field (MONITORING Object)
Bit Description Reference
0-18 Unassigned
19 Incomplete This document
20 Overload This document
21 Processing Time This document
22 General This document
23 Liveness This document
IANA has created a registry to manage the Flag field of the PROC-TIME object.
IANAは、Proc-Timeオブジェクトのフラグフィールドを管理するためのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit should be tracked with the following qualities:
新しいビット番号は、IETFレビューによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
o ビット番号（ビット0から最も重要なビットとしてカウント）
o Capability Description
o 機能の説明
o Defining RFC
o RFCの定義
One bit is defined for the PROC-TIME Object flag field in this document:
このドキュメントのProc-Timeオブジェクトフラグフィールドでは、1ビットが定義されています。
Codespace of the Flag field (PROC-TIME Object)
Bit Description Reference
0-14 Unassigned
15 Estimated This document
IANA has created a registry to manage the Flag field of the OVERLOAD object.
IANAは、オーバーロードオブジェクトのフラグフィールドを管理するレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit should be tracked with the following qualities:
新しいビット番号は、IETFレビューによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
o Bit number (counting from bit 0 as the most significant bit)
o ビット番号（ビット0から最も重要なビットとしてカウント）
o Capability Description
o 機能の説明
o Defining RFC
o RFCの定義
No Flag is currently defined for the OVERLOAD Object flag field in this document.
このドキュメントのオーバーロードオブジェクトフラグフィールドのフラグは現在定義されていません。
Codespace of the Flag field (OVERLOAD Object) Bit Description Reference 0-7 Unassigned
フラグフィールドのコードスペース（オーバーロードオブジェクト）ビット説明リファレンス0-7割り当て
The use of monitoring data can be used for various attacks such as denial-of-service (DoS) attacks (for example, by setting the C bit and overload duration field of the OVERLOAD object to stop PCCs from using a PCE). Thus, it is recommended to make use of the security mechanisms discussed in [RFC5440] to secure a PCEP session (authenticity, integrity, privacy, and DoS protection, etc.) to secure the PCMonReq and PCMonRep messages and PCE state metric objects defined in this document. An implementation SHOULD allow limiting the rate at which PCMonReq or PCReq messages carrying monitoring requests received from a specific peer are processed (input shaping) as discussed in Section 10.7.2 of [RFC5440], or from another domain (see also Section 7.6).
監視データの使用は、サービス拒否（DOS）攻撃などのさまざまな攻撃に使用できます（たとえば、過負荷オブジェクトのCビットと過負荷期間フィールドを設定してPCCがPCCを使用しないようにすることにより）。したがって、[RFC5440]で説明されているセキュリティメカニズムを使用して、PCCEPセッション（信頼性、整合性、プライバシー、DOS保護など）を確保するために、PCMONREQおよびPCMONREPメッセージとPCE状態メトリックオブジェクトを保護することをお勧めします。このドキュメント。実装では、特定のピアから受信した監視要求を運ぶPCMONREQまたはPCREQメッセージが[RFC5440]のセクション10.7.2で説明されているように、または別のドメインから処理されるレートを制限することを可能にする必要があります（セクション7.6も参照）。
The authors would like to thank Eiji Oki, Mach Chen, Fabien Verhaeghe, Dimitri Papadimitriou, and Francis Dupont for their useful comments. Special thanks to Adrian Farrel for his detailed review.
著者は、Eiji Oki、Mach Chen、Fabien Verhaeghe、Dimitri Papadimitriou、およびFrancis Dupontの有用なコメントに感謝したいと思います。彼の詳細なレビューをしてくれたエイドリアン・ファレルに感謝します。
[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月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、Jp。、ed。、およびJl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、2009年3月。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511] Farrel、A。、「ルーティングバックスノーフォーム（RBNF）：さまざまなルーティングプロトコル仕様でエンコードルールを形成するために使用される構文」、RFC 5511、2009年4月。
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009.
[RFC5521] Oki、E.、Takeda、T。、およびA. Farrel、「ルート除外のパス計算要素通信プロトコル（PCEP）への拡張」、RFC 5521、2009年4月。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC5541] Le Roux、Jl。、Vasseur、Jp。、およびY. Lee、「パス計算要素通信プロトコル（PCEP）における目的関数のエンコード」、RFC 5541、2009年6月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088] Le Roux、Jl。、ed。、vasseur、Jp。、ed。、Ikejiri、Y.、およびR. Zhang、「Path Computation Element（PCE）DiscoveryのOSPFプロトコル拡張」、RFC 5088、2008年1月。
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5089] Le Roux、Jl。、ed。、Vasseur、JP。、Ed。、Ikejiri、Y.、およびR. Zhang、「IS-IS Path Computation Element（PCE）DiscoveryのIS-ISプロトコル拡張」、RFC 5089、1月2008年。
[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, April 2009.
[RFC5441] Vasseur、Jp。、ed。、Zhang、R.、Bitar、N。、およびJl。Le Roux、「最短制約されたドメイン間トラフィックエンジニアリングラベルの切り替えパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、2009年4月。
Authors' Addresses
著者のアドレス
JP. Vasseur (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP。Vasseur（編集者）Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: jpv@cisco.com
JL. Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion 22307 France
jl。Le Roux France Telecom 2、Avenue Pierre-Marzin Lannion 22307 France
EMail: jeanlouis.leroux@orange-ftgroup.com
Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Japan
Yuichi Ikejiri ntt Communications Corporation 1-1-6、Uchisaiwai-Cho、Chiyoda-Ku Tokyo 100-8019 Japan
EMail: y.ikejiri@ntt.com