[要約] RFC 8408は、PCE通信プロトコル（PCEP）メッセージでパスセットアップタイプを伝えるための仕様です。このRFCの目的は、PCEPメッセージにパスセットアップタイプを含めることで、ネットワークのパスセットアップに関する情報を効果的に伝達することです。
Internet Engineering Task Force (IETF) S. Sivabalan
Request for Comments: 8408 Cisco Systems, Inc.
Category: Standards Track J. Tantsura
ISSN: 2070-1721 Nuage Networks
I. Minei
Google, Inc.
R. Varga
Pantheon Technologies SRO
J. Hardwick
Metaswitch Networks
July 2018
Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages
PCE通信プロトコル（PCEP）メッセージでのパス設定タイプの伝達
Abstract
概要
A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session.
パス計算要素（PCE）は、ネットワークを介したトラフィックエンジニアリング（TE）パスを計算できます。これらのパスにはさまざまな制約があります。現在、TEパスは、RSVP-TEシグナリングプロトコルを使用してセットアップされるラベルスイッチドパス（LSP）です。ただし、PCEアーキテクチャ内で他のTEパスセットアップ方法が可能です。このドキュメントでは、PCE通信プロトコル（PCEP）の拡張機能を提案し、特定のPCEPセッションでさまざまなパス設定方法をサポートできるようにします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8408.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8408で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4
4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 6
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Manageability Considerations . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Additions to PCEP TLV Type Indicators Registry . . . . . 9
8.2. New PCEP Path Setup Types Registry . . . . . . . . . . . 9
8.3. Additions to PCEP-ERROR Object Error Types and Values
Registry . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
[RFC5440] describes the PCE Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a Path Computation Element (PCE) or between a PCE and a PCE. A PCC requests, from a PCE, a path subject to various constraints and optimization criteria. The PCE responds to the PCC with a hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the ERO to set up the path in the network.
[RFC5440]は、パス計算クライアント（PCC）とパス計算要素（PCE）の間、またはPCEとPCEの間の通信用のPCE通信プロトコル（PCEP）について説明しています。 PCCは、さまざまな制約と最適化基準の対象となるパスをPCEに要求します。 PCEは、明示的ルートオブジェクト（ERO）のホップバイホップパスでPCCに応答します。 PCCはEROを使用してネットワーク内のパスを設定します。
[RFC8231] specifies extensions to PCEP that allow a PCC to delegate its LSPs to a PCE. The PCE can then update the state of LSPs delegated to it. In particular, the PCE may modify the path of an LSP by sending a new ERO. The PCC uses this ERO to reroute the LSP in a make-before-break fashion. [RFC8281] specifies a mechanism that allows a PCE to dynamically instantiate an LSP on a PCC by sending the ERO and the characteristics of the LSP. The PCC creates the LSP using the ERO and other attributes sent by the PCE.
[RFC8231]は、PCCがLSPをPCEに委任できるようにするPCEPの拡張を指定します。 PCEは、委任されたLSPの状態を更新できます。特に、PCEは新しいEROを送信してLSPのパスを変更する場合があります。 PCCはこのEROを使用して、make-before-break方式でLSPを再ルーティングします。 [RFC8281]は、PCEがEROおよびLSPの特性を送信することにより、PCCでLSPを動的にインスタンス化できるようにするメカニズムを指定します。 PCCは、PCEから送信されたEROおよびその他の属性を使用してLSPを作成します。
So far, PCEP and its extensions have assumed that the TE paths are label switched and are established via the RSVP-TE signaling protocol. However, other methods of LSP setup are possible in the PCE architecture (see [RFC4655] and [RFC4657]). This document generalizes PCEP to allow other LSP setup methods to be used. It defines two new TLVs and specifies the base procedures to facilitate this:
これまでのところ、PCEPとその拡張は、TEパスがラベルスイッチされ、RSVP-TEシグナリングプロトコルを介して確立されると想定しています。ただし、PCEアーキテクチャではLSPセットアップの他の方法が可能です（[RFC4655]および[RFC4657]を参照）。このドキュメントでは、他のLSPセットアップ方法を使用できるようにPCEPを一般化しています。 2つの新しいTLVを定義し、これを容易にするための基本手順を指定します。
o The PATH-SETUP-TYPE-CAPABILITY TLV allows a PCEP speaker to announce which LSP setup methods it supports when the PCEP session is established.
o PATH-SETUP-TYPE-CAPABILITY TLVを使用すると、PCEPスピーカーは、PCEPセッションが確立されたときに、サポートするLSPセットアップ方法を通知できます。
o The PATH-SETUP-TYPE TLV allows a PCEP speaker to specify which setup method should be used for a given LSP. When multiple path setup types are deployed in a network, a given PCEP session may have to simultaneously support more than one path setup type. A PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate the intended path setup type in the appropriate PCEP messages, unless the path setup type is RSVP-TE (which is assumed to be the path setup type if no other setup type is indicated). This is so that both the PCC and the PCE can take the necessary steps to set up the path.
o PATH-SETUP-TYPE TLVを使用すると、PCEPスピーカーは、特定のLSPに使用するセットアップ方法を指定できます。ネットワークに複数のパス設定タイプが導入されている場合、特定のPCEPセッションで複数のパス設定タイプを同時にサポートする必要がある場合があります。 PCEPスピーカーは、PATH-SETUP-TYPE TLVを使用して、適切なPCEPメッセージで目的のパスセットアップタイプを明示的に示します。ただし、パスセットアップタイプがRSVP-TE（他のセットアップタイプがない場合はパスセットアップタイプであると見なされます）示されています）。これは、PCCとPCEの両方がパスをセットアップするために必要な手順を実行できるようにするためです。
This document defines a path setup type code for RSVP-TE. When a new path setup type (other than RSVP-TE) is introduced for setting up a path, a path setup type code and, optionally, a sub-TLV pertaining to the new path setup type will be defined by the document that specifies the new path setup type.
このドキュメントでは、RSVP-TEのパス設定タイプコードを定義しています。パスを設定するために新しいパス設定タイプ（RSVP-TE以外）が導入されると、パス設定タイプコード、およびオプションで、新しいパス設定タイプに関連するサブTLVが、新しいパス設定タイプ。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following terminology is used in this document:
このドキュメントでは、次の用語が使用されています。
ERO: Explicit Route Object
ERO：明示的なルートオブジェクト
PCC: Path Computation Client
PCC：パス計算クライアント
PCE: Path Computation Element
PCE：パス計算要素
PCEP: PCE Communication Protocol
PCEP：PCE通信プロトコル
PST: Path Setup Type
PST：パス設定タイプ
TLV: Type, Length, and Value
TLV：タイプ、長さ、値
A PCEP speaker indicates which PSTs it supports during the PCEP initialization phase using the following process. When the PCEP session is created, it sends an Open message with an OPEN object containing the PATH-SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows.
PCEPスピーカーは、次のプロセスを使用して、PCEP初期化フェーズ中にサポートするPSTを示します。 PCEPセッションが作成されると、PATH-SETUP-TYPE-CAPABILITY TLVを含むOPENオブジェクトを含むOpenメッセージが送信されます。このTLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (34) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num of PSTs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PST#1 | ... | PST#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV
図1：PATH-SETUP-TYPE-CAPABILITY TLV
The TLV Type is 34. Its Reserved field MUST be set to zero by the sender and MUST be ignored by the receiver. The other fields in the TLV are as follows.
TLVタイプは34です。その予約済みフィールドは送信者がゼロに設定する必要があり、受信者は無視する必要があります。 TLVの他のフィールドは次のとおりです。
Length: The total length in bytes of the remainder of the TLV, that is, excluding the Type and Length fields.
長さ：TLVの残りのバイトの長さの合計（タイプと長さフィールドを除く）。
Num of PSTs: The number of PSTs in the following list, excluding padding.
PSTの数：パディングを除く、以下のリストにあるPSTの数。
List of PSTs: A list of the PSTs that the PCEP speaker supports. Each PST is a single byte in length. Duplicate entries in this list MUST be ignored. The PCEP speaker MUST pad the list with zeros so that it is a multiple of four bytes in length. This document defines the following PST value:
PSTのリスト：PCEPスピーカーがサポートするPSTのリスト。各PSTの長さは1バイトです。このリストの重複するエントリは無視する必要があります。 PCEPスピーカーは、長さが4バイトの倍数になるように、リストにゼロを埋め込む必要があります。このドキュメントでは、次のPST値を定義しています。
* PST = 0: Path is set up using the RSVP-TE signaling protocol
* PST = 0：RSVP-TEシグナリングプロトコルを使用してパスが設定されます
Optional sub-TLVs: A list of sub-TLVs associated with the supported PSTs. Each PST has zero or one sub-TLVs associated with it, and each sub-TLV is associated with exactly one PST. Each sub-TLV MUST obey the rules for TLV formatting defined in [RFC5440]. That is, each sub-TLV is padded to a four-byte alignment, and the Length field of each sub-TLV does not include the padding bytes. This document does not define any sub-TLVs; an example sub-TLV can be found in [PCEP-EXTENSIONS].
オプションのサブTLV：サポートされているPSTに関連付けられているサブTLVのリスト。各PSTにはゼロまたは1つのサブTLVが関連付けられており、各サブTLVは1つのPSTに関連付けられています。各サブTLVは、[RFC5440]で定義されているTLVフォーマットのルールに従う必要があります。つまり、各サブTLVは4バイトアライメントまでパディングされ、各サブTLVの長さフィールドにはパディングバイトは含まれません。このドキュメントでは、サブTLVを定義していません。サブTLVの例は、[PCEP-EXTENSIONS]にあります。
A PCEP speaker MUST check that this TLV is correctly formatted, as follows.
PCEPスピーカーは、このTLVが次のように正しくフォーマットされていることを確認する必要があります。
o If there are no sub-TLVs, then the TLV Length field MUST be equal to four bytes plus the size of the PST list, excluding any padding bytes.
o サブTLVがない場合、TLV長さフィールドは、4バイトにPSTリストのサイズを加えたものに等しくなければなりません（パディングバイトを除く）。
o If there are sub-TLVs, then the TLV Length field MUST be equal to four bytes plus the size of the PST list (rounded up to the nearest multiple of four) plus the size of the appended sub-TLVs, excluding any padding bytes in the final sub-TLV.
o サブTLVがある場合、TLV長さフィールドは、4バイト+ PSTリストのサイズ（最も近い4の倍数に切り上げ）+追加されたサブTLVのサイズに等しくなければなりません。最後のサブTLV。
o The Num of PSTs field MUST be greater than zero.
o PSTフィールドの数はゼロより大きくなければなりません。
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV that violates these rules, then the PCEP speaker MUST send a PCErr message with Error-Type = 10 (Reception of an invalid object) and Error-value = 11 (Malformed object) and MUST close the PCEP session. The PCEP speaker MAY include the malformed OPEN object in the PCErr message as well.
PCEPスピーカーがこれらのルールに違反するPATH-SETUP-TYPE-CAPABILITY TLVを受信した場合、PCEPスピーカーは、Error-Type = 10（無効なオブジェクトの受信）およびError-value = 11（不正なオブジェクト）のPCErrメッセージを送信する必要があります。 ）、PCEPセッションを閉じる必要があります。 PCEPスピーカーは、PCErrメッセージに不正なOPENオブジェクトを含めることもできます（MAY）。
If a PCEP speaker receives an OPEN object with more than one PATH-SETUP-TYPE-CAPABILITY TLV, then it MUST ignore all but the first instance of this TLV.
PCEPスピーカーが複数のPATH-SETUP-TYPE-CAPABILITY TLVを持つOPENオブジェクトを受信した場合、このTLVの最初のインスタンス以外はすべて無視する必要があります。
The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a single PST value of 0 (Path is set up using the RSVP-TE signaling protocol) and no sub-TLVs. A PCEP speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST it supports is RSVP-TE. If a PCEP speaker supports other PSTs besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE-CAPABILITY TLV in its OPEN object.
OPENオブジェクトからのPATH-SETUP-TYPE-CAPABILITY TLVがないことは、0の単一のPST値を含むPATH-SETUP-TYPE-CAPABILITY TLVと同等であり（パスはRSVP-TEシグナリングプロトコルを使用してセットアップされます）、サブTLV。 PCEPスピーカーがサポートする唯一のPSTがRSVP-TEである場合、PATH-SETUP-TYPE-CAPABILITY TLVを省略してもよい（MAY）。 PCEPスピーカーがRSVP-TE以外のPSTをサポートしている場合、OPENオブジェクトにPATH-SETUP-TYPE-CAPABILITY TLVを含める必要があります。
If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY TLV, it will ignore the TLV in accordance with [RFC5440].
PCEPスピーカーがPATH-SETUP-TYPE-CAPABILITY TLVを認識しない場合、[RFC5440]に従ってTLVを無視します。
When a PCEP session is used to set up TE paths using different methods, the corresponding PCE and PCC must be aware of the path setup method used. This means that a PCE must be able to specify paths in the correct format, and a PCC must be able to take control-plane and forwarding-plane actions appropriate to the PST.
PCEPセッションを使用してさまざまな方法でTEパスを設定する場合、対応するPCEおよびPCCは、使用されるパス設定方法を認識している必要があります。これは、PCEがパスを正しい形式で指定できなければならず、PCCがPSTに適切なコントロールプレーンおよびフォワーディングプレーンアクションを実行できる必要があることを意味します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (28) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PATH-SETUP-TYPE TLV
図2：PATH-SETUP-TYPE TLV
The PATH-SETUP-TYPE TLV is an optional TLV associated with the Request Parameters (RP) [RFC5440] and the Stateful PCE Request Parameters (SRP) [RFC8231] objects. Its format is shown in Figure 2. The TLV type is 28. Its Reserved field MUST be set to zero. The one-byte PST field contains the PST as defined for the PATH-SETUP-TYPE-CAPABILITY TLV.
PATH-SETUP-TYPE TLVは、要求パラメーター（RP）[RFC5440]およびステートフルPCE要求パラメーター（SRP）[RFC8231]オブジェクトに関連付けられたオプションのTLVです。そのフォーマットを図2に示します。TLVタイプは28です。そのReservedフィールドはゼロに設定する必要があります。 1バイトのPSTフィールドには、PATH-SETUP-TYPE-CAPABILITY TLVに定義されているPSTが含まれています。
The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP-TYPE TLV with a PST value of 0 (Path is set up using the RSVP-TE signaling protocol). A PCEP speaker MAY omit the TLV if the PST is RSVP-TE. If the RP or SRP object contains more than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed, and the rest MUST be ignored.
PATH-SETUP-TYPE TLVがないことは、PST値が0のPATH-SETUP-TYPE TLVと同等です（パスは、RSVP-TEシグナリングプロトコルを使用してセットアップされます）。 PSTがRSVP-TEの場合、PCEPスピーカーはTLVを省略してもよい（MAY）。 RPまたはSRPオブジェクトに複数のPATH-SETUP-TYPE TLVが含まれている場合、最初のTLVのみが処理されなければならず、残りは無視されなければなりません（MUST）。
If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it will ignore the TLV in accordance with [RFC5440] and use RSVP-TE to set up the path.
PCEPスピーカーがPATH-SETUP-TYPE TLVを認識しない場合、[RFC5440]に従ってTLVを無視し、RSVP-TEを使用してパスを設定します。
During the PCEP initialization phase, if a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST assume that the peer supports only the PSTs listed in the TLV. If the PCEP speaker and its peer have no PSTs in common, then the PCEP speaker MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 2 (Mismatched path setup type) and close the PCEP session.
PCEP初期化フェーズ中に、PCEPスピーカーがそのピアからPATH-SETUP-TYPE-CAPABILITY TLVを受信した場合、ピアはTLVにリストされているPSTのみをサポートしていると想定する必要があります。 PCEPスピーカーとそのピアに共通のPSTがない場合、PCEPスピーカーは、エラータイプ= 21（無効なトラフィックエンジニアリングパスセットアップタイプ）およびエラー値= 2（不一致パスセットアップタイプ）のPCErrメッセージを送信して閉じる必要があります。 PCEPセッション。
If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP speaker MUST infer that the peer supports path setup using at least RSVP-TE. The PCEP speaker MAY also infer that the peer supports other path setup types, but the means of inference are outside the scope of this document.
ピアがPATH-SETUP-TYPE-CAPABILITY TLVを送信していない場合、PCEPスピーカーは、ピアが少なくともRSVP-TEを使用したパスセットアップをサポートしていると推測する必要があります。 PCEPスピーカーは、ピアが他のパス設定タイプをサポートしていると推測することもできますが、推測の手段はこのドキュメントの範囲外です。
When a PCC sends a PCReq message to a PCE [RFC5440], it MUST include the PATH-SETUP-TYPE TLV in the RP object, unless the intended PST is RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). If the PCE is capable of expressing the path in a format appropriate to the intended PST, it MUST use the appropriate ERO format in the PCRep message.
PCCがPCReqメッセージをPCE [RFC5440]に送信するとき、目的のPSTがRSVP-TEである場合を除いて、RPオブジェクトにPATH-SETUP-TYPE TLVを含める必要があります（この場合、PATH-SETUP-TYPEは省略できます） TLV）。 PCEが目的のPSTに適切な形式でパスを表現できる場合、PCRepメッセージで適切なERO形式を使用する必要があります。
When a PCE sends a PCRep message to a PCC [RFC5440], it MUST include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). If the PCE does not support the intended PST, it MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 1 (Unsupported path setup type) and close the PCEP session. If the PSTs corresponding to the PCReq and PCRep messages do not match, the PCC MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 2 (Mismatched path setup type) and close the PCEP session.
PCEがPCRepメッセージをPCC [RFC5440]に送信するとき、PSTがRSVP-TEでない限り、RPオブジェクトにPATH-SETUP-TYPE TLVを含める必要があります（この場合、PATH-SETUP-TYPE TLVを省略してもよいです） ）。 PCEが目的のPSTをサポートしていない場合は、Error-Type = 21（無効なトラフィックエンジニアリングパスセットアップタイプ）およびError-value = 1（サポートされていないパスセットアップタイプ）のPCErrメッセージを送信し、PCEPセッションを閉じる必要があります。 PCReqおよびPCRepメッセージに対応するPSTが一致しない場合、PCCは、Error-Type = 21（無効なトラフィックエンジニアリングパスセットアップタイプ）およびError-value = 2（ミスマッチパスセットアップタイプ）のPCErrメッセージを送信し、 PCEPセッション。
When a stateful PCE sends a PCUpd message [RFC8231] or a PCInitiate message [RFC8281] to a PCC, it MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the intended PST is RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). If the PCC does not support the PST associated with the PCUpd or PCInitiate message, it MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 1 (Unsupported path setup type) and close the PCEP session.
ステートフルPCEがPCUpdメッセージ[RFC8231]またはPCInitiateメッセージ[RFC8281]をPCCに送信する場合、目的のPSTがRSVP-TEである場合を除き、SRPオブジェクトにPATH-SETUP-TYPE TLVを含める必要があります（この場合、 PATH-SETUP-TYPE TLVは省略できます）。 PCCが、PCUpdまたはPCInitiateメッセージに関連付けられたPSTをサポートしていない場合は、Error-Type = 21（無効なトラフィックエンジニアリングパスセットアップタイプ）およびError-value = 1（サポートされていないパスセットアップタイプ）のPCErrメッセージを送信して閉じる必要があります。 PCEPセッション。
When a PCC sends a PCRpt message to a stateful PCE [RFC8231], it MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the PST is RSVP-TE (in which case it MAY omit the PATH-SETUP-TYPE TLV). The PCC MUST include the SRP object in the PCRpt message if the PST is not RSVP-TE, even when the SRP-ID-number is the reserved value of 0x00000000. If the PCRpt message is triggered by a PCUpd or PCInitiate message, then the PST that the PCC indicates in the PCRpt message MUST match the PST that the stateful PCE intended in the PCUpd or PCInitiate message. If it does not match, then the PCE MUST send a PCErr message with Error-Type = 21 (Invalid traffic engineering path setup type) and Error-value = 2 (Mismatched path setup type) and close the PCEP session.
PCCがPCRptメッセージをステートフルPCE [RFC8231]に送信するとき、PSTがRSVP-TEでない限り、SRPオブジェクトにPATH-SETUP-TYPE TLVを含める必要があります（この場合、PATH-SETUP-TYPEを省略してもよいです） TLV）。 SRP-ID-numberが0x00000000の予約値であっても、PSTがRSVP-TEでない場合、PCCはPCRptメッセージにSRPオブジェクトを含める必要があります。 PCRptメッセージがPCUpdまたはPCInitiateメッセージによってトリガーされる場合、PCCがPCRptメッセージで示すPSTは、ステートフルPCEがPCUpdまたはPCInitiateメッセージで意図したPSTと一致する必要があります。一致しない場合、PCEは、Error-Type = 21（無効なトラフィックエンジニアリングパスセットアップタイプ）およびError-value = 2（不一致パスセットアップタイプ）のPCErrメッセージを送信し、PCEPセッションを閉じる必要があります。
This document generalizes PCEP to allow path setup methods other than RSVP-TE to be used by the network (but does not define any new path setup types besides RSVP-TE). It is possible that, in a given network, multiple path setup methods will be used. It is also possible that not all devices will support the same set of path setup methods. Managing networks that combine multiple path setup methods may therefore raise some challenges from a configuration and observability point of view.
このドキュメントでは、PCEPを一般化して、RSVP-TE以外のパス設定方法をネットワークで使用できるようにしています（ただし、RSVP-TE以外の新しいパス設定タイプは定義していません）。特定のネットワークでは、複数のパス設定方法が使用される可能性があります。すべてのデバイスが同じパス設定方法のセットをサポートするわけではない可能性もあります。したがって、複数のパス設定方法を組み合わせたネットワークの管理では、構成と可観測性の観点からいくつかの課題が生じる可能性があります。
Each document that defines a new path setup type in the "PCEP Path Setup Types" registry (Section 8.2) must include a Manageability Considerations section. The Manageability Considerations section must explain how operators can manage PCEP with the new path setup type. It must address the following questions, which are generally applicable when working with multiple path setup types in PCEP.
「PCEPパスセットアップタイプ」レジストリ（セクション8.2）で新しいパスセットアップタイプを定義する各ドキュメントには、「管理性の考慮事項」セクションを含める必要があります。管理性の考慮事項セクションでは、オペレーターが新しいパス設定タイプでPCEPを管理する方法を説明する必要があります。 PCEPで複数のパス設定タイプを使用する場合に一般的に当てはまる次の質問に対処する必要があります。
o What are the criteria for when devices will use the new path setup type in PCEP, and how can the operator control this?
o PCEPでデバイスが新しいパス設定タイプを使用する基準は何ですか？また、オペレーターはこれをどのように制御できますか？
o How can the network be migrated to the new path setup type, and are there any backwards-compatibility issues that operators need to be aware of?
o ネットワークを新しいパスセットアップタイプに移行するにはどうすればよいですか。また、オペレーターが認識する必要がある下位互換性の問題はありますか？
o Are paths set up using the new path setup type intended to coexist with other paths over the long term, and if so, how is this situation managed with PCEP?
o パスは、長期にわたって他のパスと共存することを目的とした新しいパスセットアップタイプを使用してセットアップされていますか？そうであれば、この状況はPCEPでどのように管理されますか？
o How can operators verify the correct operation of PCEP in the network with respect to the new path setup type? Which fault conditions must be reported to the operators?
o オペレータは、新しいパス設定タイプに関して、ネットワークでのPCEPの正しい動作をどのように確認できますか？オペレーターに報告する必要があるのはどの故障状態ですか？
o Are there any existing management interfaces (such as YANG models) that must be extended to model the operation of PCEP in the network with respect to the new path setup type?
o 新しいパス設定タイプに関してネットワーク内のPCEPの動作をモデル化するために拡張する必要がある既存の管理インターフェース（YANGモデルなど）はありますか？
See [RFC5706] for further guidance on how to write Manageability Considerations sections in Standards Track documents.
スタンダードトラックドキュメントの管理性に関する考慮事項のセクションの記述方法に関する詳細なガイダンスについては、[RFC5706]を参照してください。
The security considerations described in [RFC5440] and [RFC8281] are applicable to this specification. No additional security measure is required.
[RFC5440]および[RFC8281]で説明されているセキュリティの考慮事項は、この仕様に適用されます。追加のセキュリティ対策は必要ありません。
Note that if the security mechanisms of [RFC5440] and [RFC8281] are not used, then the protocol described in this document could be attacked in the following new way. An attacker, using a TCP man-in-the-middle attack, could inject error messages into the PCEP session when a particular PST is (or is not) used. Doing this could potentially force the use of a specific PST, which may allow the attacker to subsequently attack a weakness in that PST.
[RFC5440]と[RFC8281]のセキュリティメカニズムが使用されていない場合、このドキュメントで説明されているプロトコルは、次の新しい方法で攻撃される可能性があることに注意してください。攻撃者は、TCP中間者攻撃を使用して、特定のPSTが使用されている（または使用されていない）ときに、PCEPセッションにエラーメッセージを挿入する可能性があります。これを行うと、特定のPSTの使用が強制される可能性があり、攻撃者はその後、そのPSTの弱点を攻撃する可能性があります。
IANA has allocated the following code points in the "PCEP TLV Type Indicators" registry.
IANAは、「PCEP TLV Type Indicators」レジストリに次のコードポイントを割り当てました。
Value Description Reference
----- -------------------------- ---------
28 PATH-SETUP-TYPE RFC 8408
34 PATH-SETUP-TYPE-CAPABILITY RFC 8408
IANA has created a new sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". The allocation policy for this new registry is IETF Review [RFC8126]. This new registry contains the following value:
IANAは、「パス計算要素プロトコル（PCEP）番号」レジストリ内に「PCEPパスセットアップタイプ」と呼ばれる新しいサブレジストリを作成しました。この新しいレジストリの割り当てポリシーはIETFレビュー[RFC8126]です。この新しいレジストリには、次の値が含まれています。
Value Description Reference
----- -------------------------- ---------
0 Path is set up using the RFC 8408
RSVP-TE signaling protocol
IANA has allocated the following code points in the "PCEP-ERROR Object Error Types and Values" registry.
IANAは、「PCEP-ERRORオブジェクトのエラータイプと値」レジストリに次のコードポイントを割り当てました。
Error-Type Meaning Reference
---------- ------------------------------------------- ---------
10 Reception of an invalid object RFC 5440
Error-value = 11: Malformed object RFC 8408
エラー値= 11：不正な形式のオブジェクトRFC 8408
21 Invalid traffic engineering path setup type RFC 8408
21無効なトラフィックエンジニアリングパスのセットアップタイプRFC 8408
Error-value = 0: Unassigned RFC 8408
Error-value = 1: Unsupported path setup type RFC 8408
Error-value = 2: Mismatched path setup type RFC 8408
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8231] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、< https://www.rfc-editor.org/info/rfc8231>。
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.
[RFC8281] Crabbe、E.、Minei、I.、Sivabalan、S。、およびR. Varga、「ステートフルPCEモデルでのPCEによって開始されるLSPセットアップのパス計算要素通信プロトコル（PCEP）拡張」、RFC 8281、DOI 10.17487 / RFC8281、2017年12月、<https://www.rfc-editor.org/info/rfc8281>。
[PCEP-EXTENSIONS] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", Work in Progress, draft-ietf-pce-segment-routing-12, June 2018.
[PCEP-EXTENSIONS] Sivabalan、S.、Filsfils、C.、Tantsura、J.、Henderickx、W.、J. Hardwick、 "PCEP Extensions for Segment Routing"、Work in Progress、draft-ietf-pce-segment- routing-12、2018年6月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：//www.rfc -editor.org/info/rfc4655>。
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC4657] Ash、J.、Ed。およびJ. Le Roux編、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、DOI 10.17487 / RFC4657、2006年9月、<https://www.rfc-editor.org/info/rfc4657> 。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>.
[RFC5706]ハリントン、D。、「新しいプロトコルとプロトコル拡張の操作と管理を考慮するためのガイドライン」、RFC 5706、DOI 10.17487 / RFC5706、2009年11月、<https://www.rfc-editor.org/info/rfc5706 >。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
Acknowledgements
謝辞
We would like to thank Marek Zavodsky for valuable comments.
貴重なコメントを寄せてくれたMarek Zavodskyに感謝します。
Contributors
貢献者
The following people contributed to this document:
以下の人々がこの文書に貢献しました：
- Jan Medved - Edward Crabbe
- Jan Medved-Edward Crabbe
Authors' Addresses
著者のアドレス
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Shiva Sivabalan Cisco Systems、Inc. ೨೦೦೦革新的なドライブドライブ、オンタリオQ1 A ೮カナダ
Email: msiva@cisco.com
Jeff Tantsura Nuage Networks 755 Ravendale Drive Mountain View, CA 94043 United States of America
Jeff Tantsura Nuage Networks 755 Ravendale Drive Mountain View、CA 94043アメリカ合衆国
Email: jefftant.ietf@gmail.com
Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Ina Minei Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: inaminei@google.com
Robert Varga Pantheon Technologies SRO Mlynske Nivy 56 Bratislava, 821 05 Slovakia
Robert Varga Pantheon Technologies SRO Mlynske Nivy 56ブラチスラバ、821 05スロバキア
Email: nite@hq.sk
Jon Hardwick Metaswitch Networks 100 Church Street Enfield, Middlesex United Kingdom
Jon Hardwick Metaswitch Networks 100 Church Street Enfield、ミドルセックスイギリス
Email: jonathan.hardwick@metaswitch.com