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
        

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".

経路計算エレメント(PCE)ベースのアーキテクチャは、トラフィックエンジニアリングの計算のために指定されている(TE)ラベルは、単一または複数のドメインの文脈で(MPLS)と一般化MPLS(GMPLS)ネットワークをマルチプロトコルラベルスイッチングのパス(LSPを)交換しました(ここで、ドメインは、内部ゲートウェイプロトコル(IGP)領域と自律システム、アドレス管理や経路計算責任の共通球体内のネットワーク要素の集合を意味します)。経路計算クライアント(のPCCは)のPCEに計算要求を送信し、これらはに要求を転送し、他のPCEは、「経路計算チェーン」を形成することに協力することができます。

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.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.

著作権(C)2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(http://trustee.ietf.org/license-info)に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
        
1. Introduction
1. はじめに

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)ベースのアーキテクチャは、トラフィックエンジニアリングの計算のために[RFC4655]で指定されている(TE)ラベルのコンテキストで(MPLS)と一般化MPLS(GMPLS)ネットワークをマルチプロトコルラベルスイッチングのパス(LSPを)交換しましたドメインは、アドレス管理や経路計算責任そのようなインテリアゲートウェイプロトコル(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].

経路計算クライアント(のPCC)はPCReqメッセージを使用してのPCEに計算要求を送信し、これらはに要求を転送し、他のPCEは、「経路計算チェーン」を形成することに協力することができます。成功した経路計算の場合には、計算されたパスは、次に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]で定義されるように、複数のPCEがTE LSPの計算に関与している状況があります。 PCCは、ヘッドエンドとTE LSPの末尾に隣接するドメインに存在しないとヘッドエンドの両方の視認性とは、単一のPCEがないTE LSPの計算を必要とするときの典型的な例でありますテールエンドのドメイン。私たちは、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は、一のPCE(単一PCEの経路計算と呼ばれる)、またはいくつかのPCE(のような複数のPCEの経路計算と呼ぶ)によって計算することができます。前者の場合、PCCは、PCEの生存性をチェックするためにIGP拡張機能を使用することができる場合がキープアライブメッセージを使用するか、PCEP([RFC5088]及び[RFC5089]を参照)。対照的に、複数の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の状態メトリックは、二つの異なるコンテキストで収集することができます:バンドまたはアウトオブバンド。 「バンド内」とは、PCCの要求が経路計算要求のコンテキストでメトリックを収集することにより、状況を参照してください。例えば、PCCは、PCEへの経路計算リクエストを送信してもよいし、計算された経路に加えて、その要求の処理時間を知りたいことができます。逆に、PCE状態メトリック収集がスタンドアロン要求(例えば、特定の経路計算チェーンの生存性をチェックし、として実行され、要求は「帯域外」である場合、1つの最後の5分の期間にわたって計算された平均処理時間を収集します以上の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]で指定されるように、この文書に記載されているメッセージ形式は、バッカス正規形式(BNF)エンコーディングを使用して指定されます。

1.1. Requirements Language
1.1. 要件言語

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]に記載されているように解釈されます。

2. Terminology
2.用語

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(パス計算エレメント):エンティティ(コンポーネント、アプリケーション、またはネットワークノード)ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能です。

TE LSP: Traffic Engineering Label Switched Path.

TE LSP:トラフィックエンジニアリングラベルスイッチパス。

3. Path Computation Monitoring Messages
3.経路計算の監視メッセージ

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メッセージに必須であると言われています。 ([RFC5440]で定義された)Pフラグは各PCEPオブジェクトの共通ヘッダに位置し、経路計算中にアカウントに関連する情報を取得するPCEを要求するPCEPピアによって設定することができます。 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のメッセージを定義します。 PCEにPCCによって送らPCMonReqメッセージの目的は、経路計算チェーンに関与するのPCEのセット上の一つ以上のPCEの状態メトリックを収集することです。 PCCとPCEによって送信されたPCMonRepメッセージは、そのようなデータを提供するために使用されます。

3.1. Path Computation Monitoring Request (PCMonReq) Message
3.1. 経路計算の監視要求(PCMonReq)メッセージ

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.

監視オブジェクト(セクション4.1を参照してください):PCMonReqメッセージ内に含まれなければならない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]で定義されたオブジェクトの[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の状態メトリックを収集するために使用されます。経路計算鎖はPCCで指定又は代替経路計算手順によって決定することができるポリシーに従って(セクション4.3で定義されたPCE-IDのオブジェクトの一連のシリーズの形で)PCCによって決定することができます。 BRPC手順([RFC5441])がドメイン間TE LSPを計算するために使用される場合、例えば、経路計算チェーンを動的に決定することができます。その場合、PCCは、TE LSPは、関心のメトリックのセットを一覧表示し、監視対象(セクション4.1を参照)に沿って属性特徴付ける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.

いくつかのPCE状態メトリックは、オブジェクトのこのセットは、将来的に拡張することができることを第4項注で定義されたオブジェクトのセットによって規定されていることを要請することができます。

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

独立した同期パス計算要求(必要な以下に定義SVECオブジェクト)のセットの束O、又は

o a bundle of a set of dependent and synchronized path computation requests (SVEC object defined below required).

依存と同期経路計算要求(必要な以下に定義SVECオブジェクト)の集合束O。

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のためのパス計算を要求すべき使用される経路計算チェーンを確認する要求を行います。 PCMonReqメッセージは、T1用PCReqメッセージに含まれることになるオブジェクトの適切なセット(例えば、RP、エンドポイント、等)と一緒に、経路計算チェックを指定する監視対象が含まれて送信されます。

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>。 PCMonReqメッセージは監視対象それぞれ、PCE1、PCE2、PCE3、及びPCE7を識別PCE-IDオブジェクトの配列を含むPCE1に送られます。

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メッセージ(帯域外要求)計算指標を報告要求に応答して送信されます。

3.2. Path Monitoring Reply (PCMonRep) Message
3.2. パス監視返信(PCMonRep)メッセージ

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).

監視オブジェクト(セクション4.1を参照してください):PCMonRepメッセージ内に含まれなければならない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のリストを使用して(同じ経路計算チェーンを使用するが、逆の順序でなければなりません)。

4. Path Computation Monitoring Objects
4.経路計算の監視オブジェクト

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オブジェクトフォーマットに準拠しています。 Pフラグと、この文書で定義されたPCEPオブジェクトの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バイト、及び値フィールドから構成されています。 Lengthフィールドは、バイト単位の値部分の長さを規定します。 TLVは4バイトアライメントにパディングされます。パディングは、長さフィールド(SO 3バイトの値が3の長さを有するであろうが、TLVの合計サイズが8つのバイトであろう)には含まれません。認識されないのTLVを無視しなければなりません。

4.1. MONITORING Object
4.1. 監視オブジェクト

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メッセージにおける監視対象物の複数のインスタンスがあってはならない:監視対象の複数のインスタンスが存在する場合、受信者は最初のインスタンスを処理しなければならないし、他のインスタンスを無視しなければなりません。

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(ライブネス) - 1ビット:セット、これは、対象の状態メトリックがPCEのライブネスであり、したがって、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ビットが処理時間は、関心のメトリックであることを示すように設定されています。ポリシーで許可されている場合、PROC-TIMEオブジェクトは、対応するPCMonRep又はPCRepメッセージに挿入されなければなりません。 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.

私は(不完全) - 1ビット:PCEは、受信PCMonReqメッセージをサポートし、そのメッセージは、任意のポリシー違反をトリガしませんが、PCEは、不特定の理由で要求されたパフォーマンスメトリックのセットのいずれかを提供することができない場合は、PCEは、Iビットを設定しなければなりません。 Iビットは、要求には意味を持たない、領収書の上で無視されるべきです。

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番号(32ビット):要求PCCを識別するPCC-REQ-IDと組み合わせ監視-ID番号の値が一意に監視要求コンテキストを識別する。モニタリング-ID番号がゼロ以外の値で開始しなければならないし、新しい監視要求をPCEに送信されるたびにインクリメントされなければなりません。各増分は1の値を持つ必要がありますし、ゼロに戻ってラップを引き起こす可能性があります。監視要求への応答がPCEから受信されず、PCCは、その経路計算監視要求を再送信することを望む場合、同じ監視ID番号を使用しなければなりません。逆に、異なる監視-ID番号がPCEに送信された異なる要求のために使用されなければなりません。 PCEPの実装では、このように、プロセス監視要求の監視-ID番号の再利用を回避再起動する場合に、保留中の監視要求の監視-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は、現在定義されていません。

4.2. PCC-ID-REQ Object
4.2. PCC-ID-REQオブジェクト

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は、要求PCCのIPアドレスを指定するPCReq又はPCMonReqメッセージ内に挿入されなければなりません。

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.

(IPv4とIPv6のための)二PCC-ID-REQオブジェクトが定義されています。 PCC-ID-REQオブジェクトクラス(20)IANAによって割り当てられています。 PCC-ID-REQオブジェクトタイプ(IPv6のIPv4の1及び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オクテットの固定長を有します。

4.3. PCE-ID Object
4.3. PCE-IDオブジェクト

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又はPCE状態メトリックが要求されるPCEを指定するPCMonReqメッセージ内及びPCMonRep又はPCE報告PCE状態メトリックのまたはそのIPアドレスを記録するPCRepメッセージに挿入することができます経路計算チェーンに関与していました。

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.

(IPv4とIPv6のための)二PCE-IDのオブジェクトが定義されています。 PCE-IDオブジェクトクラス(25)は、IANAによって割り当てられています。 PCE-IDのオブジェクトタイプ(IPv6のIPv4の1及び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は、PCEアドレスサブTLV [RFC5088]及び[RFC5089]で定義におけるそのPCEアドレスをアドバタイズ。 PCCはPCReqとPCMonReqメッセージにこのアドレスを使用しなければならなくて、PCEもPCRepとPCMonRepメッセージにこのアドレスを使用する必要があります。

4.4. PROC-TIME Object
4.4. PROC-TIMEオブジェクト

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はPCMonRepまたは対応するPCMonReq又はPCReqメッセージ内で運ば監視対象のPビットが設定されている場合に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.

処理時間は、経路計算(監視対象を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選択への入力として監視メトリクスを使用することができるので、(この文書の別のリビジョンに記載の他の測定基準と共に)時間メトリックがセットによって計算監視メトリックの間の一貫性を保証するために計算される方法を正規化するために必要とされ得ますPCEの。

4.5. OVERLOAD Object
4.5. OVERLOADオブジェクト

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要求を処理する能力をいいます。それはすぐにこのように待ち時間につながる新しい要求を処理するために開始することができないようにPCEP要求のバックログを持っているとき、PCEが過負荷になっています。 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メッセージ内で運ば監視対象のCビットがセットされ、PCEが輻輳状態が発生している場合に過負荷オブジェクトはPCMonRep又はPCRepメッセージ内に存在していなければなりません。 OVERLOADオブジェクトクラス(27)は、IANAによって割り当てられています。過負荷オブジェクトタイプ(1)は、IANAによって割り当てられています。

The format of the CONGESTION object body is as follows:

次のようにCONGESTION対象体の形式は次のとおりです。

    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は、チェーンにおける下流のPCEのいずれかにより受信された過負荷情報から学習することを決定することができることは注目に値します。

5. Policy
5.ポリシー

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メッセージを送らなければなりません。

6. Elements of Procedure
手順6.要素

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.

私は、処理ビット:PCEは、受信しPCMonReqメッセージをサポートしている場合は、4.1節で示され、そのメッセージは、任意のポリシー違反をトリガしませんが、PCEは、不特定の理由で要求されたパフォーマンスメトリックのセットのいずれかを提供することができないとして、PCEが設定しなければなりません私は少し。一度設定すると、Iビットは、受信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.

PCEはPCMonReqメッセージをサポートしていない場合1)[RFC5440]で指定されるように、PCEピアはエラー値= 2(機能サポートされていない)とPCErrメッセージを送らなければなりません。 [RFC5440]のセクション6.9で定義された手順に従って、PCC / PCEは、指定されたレートよりも大きい、等しい割合で認識されていないメッセージを受信した場合、PCC / PCEは=近い値PCEP CLOSEメッセージを送信しなければならないANの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は4.3節で指摘したように、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.

PCEはPCMonReqをサポートし、監視要求がポリシーによって禁止されていない場合3)、受信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.

PCEは、(帯域内)モニタリングをサポートしていない場合1)[RFC5440]で指定されるように、PCEピアはエラー値= 2(機能サポートされていない)とPCErrメッセージを送らなければなりません。 [RFC5440]のセクション6.9で定義された手順に従って、PCC / PCEは、指定されたレートよりも同等以上の速度で認識されていないメッセージを受信した場合、PCC / PCEは近い値= 5「レセプションPCEP CLOSEメッセージを送信する必要があります認識できない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は4.3節で指摘したように、PCEはまだ一部の一部を残して、要求を満たすことがあり、セクション5で指定された手順に従わなければなりませんポリシーで許可されていない場合、データを必要としていました。

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.

PCEは、監視要求をサポートし、その要求がポリシーによって禁止されていない場合3)、受信PCEは、最初に、経路計算チェーンの最後のPCEであるかどうかを決定しなければなりません。 PCEは、経路計算チェーンの最後の要素ではない場合、(監視対象及びそのようなPCE-IDなどの潜在的に他の監視オブジェクトと)PCReqメッセージをネクストホップ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は、対応PCReqメッセージで運ばMONITORINGに記載されている要求されたPCE状態メトリック及び潜在的には他の監視オブジェクトのセットに応じて要求されたオブジェクトが含まPCRepメッセージを発信します。

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メッセージに関連オブジェクトが追加され、上流の要求PCEまたはPCCにPCMonRepメッセージを転送します。

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の上流に転送されます。

7. Manageability Considerations
7.管理性の考慮事項
7.1. Control of Function and Policy
7.1. 機能とポリシーの管理

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に許可状態メトリック(稼働状態、過負荷、処理時間、等)のリストを設定可能にすべきです。これは、近隣のPCEPピアはAS、例えば、所与のPCEPピアまたはピアPCEPの特定のグループとのセッションの特定のグループに特定のセッションに、PCEPスピーカーが参加している任意のセッションに適用することができます。

7.2. Information and Data Models
7.2. 情報とデータモデル

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.

新しいMIBモジュールは、ローカルPCEの状態メトリック、ならびに本書で定義されたメカニズムを使用して収集し、他のPCEの状態メトリックを提供するように定義されてもよいです。

7.3. Liveness Detection and Monitoring
7.3. 生体検知とモニタリング

This document provides mechanisms to monitor the liveliness and performances of a given path computation chain.

この文書は、指定された経路計算チェーンの活気と性能を監視するためのメカニズムを提供します。

7.4. Verify Correct Operations
7.4. 正しい操作を確認します

Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].

この文書で定義されたメカニズムは、すでに[RFC5440]に記載されているものに加えて、新たな動作確認の要件を意味するものではありません。

7.5. Requirements on Other Protocols
7.5. その他のプロトコル上の要件

Mechanisms defined in this document do not imply any requirements on other protocols in addition to those already listed in [RFC5440].

この文書で定義されたメカニズムは、すでに[RFC5440]に記載されているものに加えて他のプロトコル上の任意の要件を意味するものではありません。

7.6. Impact on Network Operations
7.6. ネットワークオペレーションへの影響

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メッセージの頻度は、のPCEの動作に影響を与えることができます。実装は限界がPCEPスピーカによって送信されたピアから処理PCMonReqメッセージの速度に配置することが可能にすべきです。また、レートしきい値に達したときに通知を送信できるようにすべきです。実装はPCMonReqメッセージよりも高い優先度でPCReqメッセージを処理できるようにすべきです。実装は、監視データを要求PCReqメッセージの第二制限の設定を可能にすべきです。

8. Guidelines to Avoid Overload Thrashing
過負荷スラッシングを避けるために8ガイドライン

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.

過負荷情報を処理しながら、重要な問題は、1つの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.

このセクションでは、PCEが過負荷になっているという指示を受信したときに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 /議員交換を使用してクリアしたと判断された後に)後でそれを再発行するかもしれません。

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が、他のPCEが過負荷になったりも同様に新しいPCReqメッセージを向ける他の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にスイッチバックする試みをしないように推奨されます。

9. IANA Considerations
9. IANAの考慮事項
9.1. New PCEP Message
9.1. 新PCEPメッセージ

Each PCEP message has a message type value.

各PCEPメッセージは、メッセージタイプ値を有します。

Two new PCEP (specified in [RFC5440]) messages are defined in this document:

メッセージ([RFC5440]で指定された)二つの新しいPCEPは、この文書で定義されています。

Value Description Reference 8 Path Computation Monitoring Request (PCMonReq) This document 9 Path Computation Monitoring Reply (PCMonRep) This document

値説明リファレンス8パス計算監視要求(PCMonReq)この文書で9パス計算監視返信(PCMonRep)この文書

9.2. New PCEP Objects
9.2. 新PCEPオブジェクト

Each PCEP object has an Object-Class and an Object-Type. The following new PCEP objects are defined in this document:

各PCEPオブジェクトは、Objectクラスとオブジェクト型を持っています。次の新しいPCEPのオブジェクトは、この文書で定義されています。

Object-Class Value Name Object-Type Reference

オブジェクトクラス値の名前オブジェクト・タイプリファレンス

19 MONITORING 1 This document

このドキュメント1 19 MONITORING

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

26 PROC-TIME 1本ドキュメント

27 OVERLOAD 1: overload This document

27 OVERLOAD 1:この文書をオーバーロード

9.3. New Error-Values
9.3. 新しいエラー-値

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:監視オブジェクトこのドキュメントは、行方不明行方不明

9.4. MONITORING Object Flag Field
9.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

フラグフィールドのコードスペース(監視対象)ビット説明リファレンス0-18未割り当て19不完全この文書20過負荷この文書21処理時間この文書22の一般この文書23のライブネスこのドキュメント

9.5. PROC-TIME Object Flag Field
9.5. PROC-TIMEオブジェクトのフラグ・フィールド

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:

1ビットは、この文書のPROC-TIMEオブジェクトフラグフィールドのために定義されています。

Codespace of the Flag field (PROC-TIME Object) Bit Description Reference 0-14 Unassigned 15 Estimated This document

フラグフィールドのコードスペース(PROC-TIMEオブジェクト)ビット説明リファレンス0-14未割り当て15この文書は、推定

9.6. OVERLOAD Object Flag Field
9.6. OVERLOADオブジェクトのフラグ・フィールド

IANA has created a registry to manage the Flag field of the OVERLOAD object.

IANAは、OVERLOADオブジェクトのフラグフィールドを管理するために、レジストリを作成しました。

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.

何旗は現在、このドキュメントのOVERLOADオブジェクトフラグフィールドのために定義されていません。

Codespace of the Flag field (OVERLOAD Object) Bit Description Reference 0-7 Unassigned

フラグフィールド(OVERLOADオブジェクト)ビット説明リファレンス0-7未割り当てのコードスペース

10. Security Considerations
10.セキュリティの考慮事項

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).

モニタリングデータの使用は、(例えば、PCEを使用してからのPCCを停止する過負荷オブジェクトのCビットと過負荷継続時間フィールドを設定することにより)サービス拒否(DoS)攻撃などの様々な攻撃のために使用することができます。したがって、[RFC5440]で説明したセキュリティメカニズムの使用PCEPセッション(信憑性、完全性、プライバシー、およびDoS攻撃防御、など)を確保するために定義されてPCMonReqとPCMonRepメッセージやPCE状態メトリックオブジェクトを確保するためにすることをお勧めしますこのドキュメント。実装は、特定のピアから受信した監視要求を搬送PCMonReqまたはPCReqメッセージは、[RFC5440]のセクション10.7.2で説明したように(入力シェーピング)処理、または別のドメインから(セクション7.6を参照)される速度を制限可能にすべきです。

11. Acknowledgments
11.謝辞

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.

作者は彼らの役に立つコメントを大木英司、マッハチェン、ファビアンVerhaeghe、ディミトリPapadimitriou、フランシスデュポンに感謝したいと思います。彼の詳細なレビューのためのエードリアンファレルに感謝します。

12. References
12.参考文献
12.1. Normative References
12.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.

[RFC5440] Vasseur、JP。、編、およびJL。ル・ルー、エド。、 "パス計算要素(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]ファレル、A.、「ルーティングバッカス記法(RBNF):さまざまなルーティングプロトコル仕様に符号化規則を形成するのに使用される構文」を2009年4月、RFC 5511を。

[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]沖、E.、武田、T.、およびA.ファレル、 "ルートの除外のためにパス計算要素通信プロトコル(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]ル・ルー、JL。、Vasseur、JP。、およびY.リー、 "パス計算要素通信プロトコル(PCEP)における目的関数のエンコーディング"、RFC 5541、2009年6月。

12.2. Informative References
12.2. 参考文献

[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.

[RFC4655]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素(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]ル・ルー、JL。、エド。、Vasseur、JP。、エド。、池尻、Y.、およびR.張、 "OSPFプロトコル拡張パスの計算要素(PCE)ディスカバリー"、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]ル・ルー、JL。、エド。、Vasseur、JP。、エド。、池尻、Y.、およびR.張は、 "IS-ISプロトコル拡張経路計算エレメント(PCE)の発見について"、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。、編、張、R.、ビタール、N.、およびJL。ル・ルー、RFC 5441、2009年4月「最短拘束ドメイン間トラフィックエンジニアリングラベルを計算するために下位再帰PCEベースの計算(BRPC)手順は、パスの交換しました」。

Authors' Addresses

著者のアドレス

JP. Vasseur (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA

JP。 Vasseur(エディタ)シスコ・システムズ・インク1414年マサチューセッツアベニューボックスボロー、MA 01719 USA

EMail: jpv@cisco.com

メールアドレス:jpv@cisco.com

JL. Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion 22307 France

JL。ル・ルーフランステレコム2、アベニューピエールMarzin 22307ラニオンフランス

EMail: jeanlouis.leroux@orange-ftgroup.com

メールアドレス:jeanlouis.leroux@orange-ftgroup.com

Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Japan

ゆいち いけじり んっt こっむにかちおんs こrぽらちおん 1ー1ー6、 うちさいわいーちょ、 ちよだーく ときょ 100ー8019 じゃぱん

EMail: y.ikejiri@ntt.com

メールアドレス:y.ikejiri@ntt.com