[要約] RFC 7897は、PCEP（Path Computation Element Communication Protocol）のドメインサブオブジェクトに関する規格です。このRFCの目的は、PCEPメッセージ内のドメイン情報を効果的に伝達するための仕組みを提供することです。
Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 7897 U. Palle
Category: Experimental Huawei Technologies
ISSN: 2070-1721 R. Casellas
CTTC
June 2016
Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)
パス計算要素通信プロトコル（PCEP）のドメインサブオブジェクト
Abstract
概要
The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains. This document also defines new subobjects to be used to encode domain identifiers.
複数のドメインにまたがるマルチプロトコルラベルスイッチング（MPLS）および汎用MPLS（GMPLS）ネットワークで、最短の制約付きトラフィックエンジニアリングラベルスイッチドパス（TE LSP）を計算する機能は、主要な要件として特定されています。このコンテキストでは、ドメインは、アドレス管理の共通の領域内のネットワーク要素の集まり、またはインテリアゲートウェイプロトコル（IGP）エリアや自律システム（AS）などのパス計算責任です。このドキュメントは、ドメインシーケンスの表現とエンコーディングを指定します。ドメインシーケンスは、パス計算要素（PCE）が所定のシーケンスのドメイン間制約付き最短パスを計算するために使用する宛先ドメインに到達するために通過するドメインの順序付きシーケンスとして定義されます。ドメイン。このドキュメントでは、ドメイン識別子のエンコードに使用される新しいサブオブジェクトも定義しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 http://www.rfc-editor.org/info/rfc7897.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7897で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Detail Description . . . . . . . . . . . . . . . . . . . . . 6
3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Domain Sequence . . . . . . . . . . . . . . . . . . . . . 6
3.3. Domain Sequence Representation . . . . . . . . . . . . . 7
3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 8
3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 8
3.4.1.1. Autonomous System . . . . . . . . . . . . . . . . 8
3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Update in IRO Specification . . . . . . . . . . . . . 10
3.4.3. IRO for Domain Sequence . . . . . . . . . . . . . . . 11
3.4.3.1. PCC Procedures . . . . . . . . . . . . . . . . . 11
3.4.3.2. PCE Procedures . . . . . . . . . . . . . . . . . 11
3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 13
3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 13
3.5.1.1. Autonomous System . . . . . . . . . . . . . . . . 14
3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 14
3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 16
3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 16
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 17
4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 19
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22
4.3. Boundary Node and Inter-AS Link . . . . . . . . . . . . . 25
4.4. PCE Serving Multiple Domains . . . . . . . . . . . . . . 25
4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 27
5. Other Considerations . . . . . . . . . . . . . . . . . . . . 27
5.1. Relationship to PCE Sequence . . . . . . . . . . . . . . 27
5.2. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Manageability Considerations . . . . . . . . . . . . . . . . 29
8.1. Control of Function and Policy . . . . . . . . . . . . . 29
8.2. Information and Data Models . . . . . . . . . . . . . . . 29
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 30
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 30
8.5. Requirements on Other Protocols . . . . . . . . . . . . . 30
8.6. Impact on Network Operations . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
A Path Computation Element (PCE) may be used to compute end-to-end paths across multi-domain environments using a per-domain path computation technique [RFC5152]. The Backward-Recursive PCE-Based Computation (BRPC) mechanism [RFC5441] also defines a PCE-based path computation procedure to compute an inter-domain constrained path for (G)MPLS TE LSPs. However, both per-domain and BRPC techniques assume that the sequence of domains to be crossed from source to destination is known and is either fixed by the network operator or obtained by other means. Also, for inter-domain point-to-multipoint (P2MP) tree computation, it is assumed per [RFC7334] that the domain tree is known a priori.
パス計算要素（PCE）は、ドメインごとのパス計算手法[RFC5152]を使用して、マルチドメイン環境全体のエンドツーエンドパスを計算するために使用できます。後方再帰PCEベースの計算（BRPC）メカニズム[RFC5441]も、（G）MPLS TE LSPのドメイン間制約パスを計算するためのPCEベースのパス計算手順を定義しています。ただし、ドメインごとの手法とBRPC手法の両方で、送信元から宛先に渡る一連のドメインは既知であり、ネットワークオペレーターによって固定されるか、他の方法で取得されると想定しています。また、ドメイン間ポイントツーマルチポイント（P2MP）ツリー計算では、[RFC7334]に従って、ドメインツリーがアプリオリに知られていると想定されています。
The list of domains (domain sequence) in point-to-point (P2P) or a domain tree in P2MP is usually a constraint in inter-domain path computation procedure.
ポイントツーポイント（P2P）のドメイン（ドメインシーケンス）のリストまたはP2MPのドメインツリーは、通常、ドメイン間パス計算手順の制約です。
The domain sequence (the set of domains traversed to reach the destination domain) is either administratively predetermined or discovered by some means like Hierarchical PCE (H-PCE).
ドメインシーケンス（宛先ドメインに到達するために通過する一連のドメイン）は、管理上事前に決定されているか、階層PCE（H-PCE）などの手段によって検出されます。
[RFC5440] defines the Include Route Object (IRO) and the Explicit Route Object (ERO). [RFC5521] defines the Exclude Route Object (XRO) and the Explicit Exclusion Route subobject (EXRS). The use of an Autonomous System (albeit with a 2-byte AS number) as an abstract node representing a domain is defined in [RFC3209]. In the current document, we specify new subobjects to include or exclude domains including an IGP area or an AS (4 bytes as per [RFC6793]).
[RFC5440]は、Include Route Object（IRO）とExplicit Route Object（ERO）を定義しています。 [RFC5521]は、除外ルートオブジェクト（XRO）と明示的除外ルートサブオブジェクト（EXRS）を定義しています。ドメインを表す抽象ノードとしての自律システム（AS番号は2バイトですが）の使用は、[RFC3209]で定義されています。現在のドキュメントでは、IGPエリアまたはAS（[RFC6793]による4バイト）を含むドメインを含めるまたは除外する新しいサブオブジェクトを指定しています。
Further, the domain identifier may simply act as a delimiter to specify where the domain boundary starts and ends in some cases.
さらに、ドメイン識別子は、場合によってはドメイン境界がどこで始まりどこで終わるかを指定するための区切り文字として機能するだけかもしれません。
This is a companion document to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions for the domain identifiers [RFC7898].
これは、ドメイン識別子[RFC7898]のリソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）拡張機能の関連ドキュメントです。
The procedures described in this document are experimental. The experiment is intended to enable research for the usage of the domain sequence at the PCEs for inter-domain paths. For this purpose, this document specifies new domain subobjects as well as how they incorporate with existing subobjects to represent a domain sequence.
このドキュメントで説明されている手順は実験的なものです。この実験は、ドメイン間パスのPCEでドメインシーケンスを使用するための調査を可能にすることを目的としています。この目的のために、このドキュメントでは、新しいドメインサブオブジェクトと、それらがドメインシーケンスを表すために既存のサブオブジェクトとどのように統合されるかについて説明します。
The experiment will end two years after the RFC is published. At that point, the RFC authors will attempt to determine how widely this has been implemented and deployed.
実験はRFCが公開されてから2年後に終了します。その時点で、RFCの作成者は、これがどの程度広く実装および展開されているかを判断しようとします。
This document does not change the procedures for handling existing subobjects in the PCE Communication Protocol (PCEP).
このドキュメントは、PCE通信プロトコル（PCEP）で既存のサブオブジェクトを処理する手順を変更しません。
The new subobjects introduced by this document will not be understood by legacy implementations. If a legacy implementation receives one of the subobjects that it does not understand in a PCEP object, the legacy implementation will behave according to the rules for a malformed object as per [RFC5440]. Therefore, it is assumed that this experiment will be conducted only when both the PCE and the Path Computation Client (PCC) form part of the experiment. It is possible that a PCC or PCE can operate with peers, some of which form part of the experiment and some that do not. In this case, since no capabilities exchange is used to identify which nodes can use these extensions, manual configuration should be used to determine which peerings form part of the experiment.
このドキュメントで紹介されている新しいサブオブジェクトは、従来の実装では理解されません。レガシー実装が、PCEPオブジェクトで理解できないサブオブジェクトの1つを受け取った場合、レガシー実装は、[RFC5440]の不正なオブジェクトのルールに従って動作します。したがって、この実験は、PCEとパス計算クライアント（PCC）の両方が実験の一部である場合にのみ実行されると想定されています。 PCCまたはPCEがピアで動作する可能性があります。ピアの一部は実験の一部を形成し、一部はそうではありません。この場合、どのノードがこれらの拡張機能を使用できるかを識別するための機能交換は使用されないため、実験の一部を形成するピアリングを決定するために手動構成を使用する必要があります。
When the results of implementation and deployment are available, this document will be updated and refined, and then it could be moved from Experimental to Standards Track.
実装と展開の結果が利用可能になった時点で、このドキュメントは更新および改良され、その後、実験から標準トラックに移動できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The following terminology is used in this document.
このドキュメントでは、次の用語が使用されています。
ABR: Area Border Router. Routers used to connect two IGP areas (Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).
ABR：エリアボーダールーター。 2つのIGPエリア（Open Shortest Path First（OSPF）またはIntermediate System to Intermediate System（IS-IS））を接続するために使用されるルーター。
AS: Autonomous System
AS：自律システム
ASBR: Autonomous System Border Router
ASBR：Autonomous System Border Router
BN: Boundary node; can be an ABR or ASBR.
BN：境界ノード。 ABRまたはASBRにすることができます。
BRPC: Backward-Recursive PCE-Based Computation
BRPC：後方再帰PCEベースの計算
Domain: As per [RFC4655], any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include IGP area and AS.
ドメイン：[RFC4655]に従い、アドレス管理またはパス計算の責任の共通の領域内のネットワーク要素のコレクション。ドメインの例には、IGPエリアおよびASが含まれます。
Domain Sequence: An ordered sequence of domains traversed to reach the destination domain.
ドメインシーケンス：宛先ドメインに到達するために通過するドメインの順序付けられたシーケンス。
ERO: Explicit Route Object
ERO：明示的なルートオブジェクト
H-PCE: Hierarchical PCE
H-PCE：階層PCE
IGP: Interior Gateway Protocol. Either of the two routing protocols: OSPF or IS-IS.
IGP：Interior Gateway Protocol。 OSPFまたはIS-ISの2つのルーティングプロトコルのいずれか。
IRO: Include Route Object
いろ： いんｃぅで ろうて おｂじぇｃｔ
IS-IS: Intermediate System to Intermediate System
IS-IS：中間システムから中間システム
OSPF: Open Shortest Path First
OSPF：Open Shortest Path First
PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
PCC：パス計算クライアント。パス計算要素によって実行されるパス計算を要求するクライアントアプリケーション。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
P2MP: Point-to-Multipoint
P2MP：ポイントツーマルチポイント
P2P: Point-to-Point RSVP: Resource Reservation Protocol
P2P：ポイントツーポイントRSVP：リソース予約プロトコル
TE LSP: Traffic Engineering Label Switched Path
TE LSP：トラフィックエンジニアリングラベルスイッチドパス
XRO: Exclude Route Object
XRO：ルートオブジェクトを除外
[RFC4726] and [RFC4655] define a domain as a separate administrative or geographic environment within the network. A domain could be further defined as a zone of routing or computational ability. Under these definitions, a domain might be categorized as an AS or an IGP area. Each AS can be made of several IGP areas. In order to encode a domain sequence, it is required to uniquely identify a domain in the domain sequence. A domain can be uniquely identified by an area-id, AS number, or both.
[RFC4726]および[RFC4655]は、ドメインをネットワーク内の別個の管理環境または地理的環境として定義します。ドメインは、ルーティングまたは計算能力のゾーンとしてさらに定義できます。これらの定義では、ドメインはASまたはIGPエリアとして分類される場合があります。各ASは、いくつかのIGPエリアで構成できます。ドメインシーケンスをエンコードするには、ドメインシーケンス内のドメインを一意に識別する必要があります。ドメインは、エリアID、AS番号、またはその両方によって一意に識別できます。
A domain sequence is an ordered sequence of domains traversed to reach the destination domain.
ドメインシーケンスは、宛先ドメインに到達するために通過するドメインの順序付けられたシーケンスです。
A domain sequence can be applied as a constraint and carried in a path computation request to a PCE(s). A domain sequence can also be the result of a path computation. For example, in the case of H-PCE [RFC6805], a parent PCE could send the domain sequence as a result in a path computation reply.
ドメインシーケンスは制約として適用でき、PCEへのパス計算リクエストに含めることができます。ドメインシーケンスは、パス計算の結果にもなります。たとえば、H-PCE [RFC6805]の場合、親PCEはドメインシーケンスを送信して、パス計算応答を返すことができます。
In a P2P path, the domains listed appear in the order that they are crossed. In a P2MP path, the domain tree is represented as a list of domain sequences.
P2Pパスでは、リストされたドメインは交差する順序で表示されます。 P2MPパスでは、ドメインツリーはドメインシーケンスのリストとして表されます。
A domain sequence enables a PCE to select the next domain and the PCE serving that domain to forward the path computation request based on the domain information.
ドメインシーケンスにより、PCEは次のドメインを選択し、そのドメインにサービスを提供するPCEは、ドメイン情報に基づいてパス計算要求を転送できます。
A domain sequence can include boundary nodes (ABR or ASBR) or border links (inter-AS links) to be traversed as an additional constraint.
ドメインシーケンスには、追加の制約としてトラバースされる境界ノード（ABRまたはASBR）または境界リンク（AS間リンク）を含めることができます。
Thus, a domain sequence can be made up of one or more of the following:
したがって、ドメインシーケンスは次の1つ以上で構成できます。
o AS Number
o AS番号
o Area ID
o エリアID
o Boundary Node ID
o 境界ノードID
o Inter-AS Link Address
o AS間リンクアドレス
These are encoded in the new subobjects defined in this document as well as in the existing subobjects that represent a domain sequence.
これらは、このドキュメントで定義されている新しいサブオブジェクトと、ドメインシーケンスを表す既存のサブオブジェクトでエンコードされます。
Consequently, a domain sequence can be used by:
したがって、ドメインシーケンスは次のユーザーが使用できます。
1. a PCE in order to discover or select the next PCE in a collaborative path computation, such as in BRPC [RFC5441];
1. BRPC [RFC5441]などの協調パス計算で次のPCEを検出または選択するためのPCE。
2. the parent PCE to return the domain sequence when unknown; this can then be an input to the BRPC procedure [RFC6805];
2. 不明な場合にドメインシーケンスを返す親PCE。これはBRPCプロシージャ[RFC6805]への入力となります。
3. a PCC or a PCE to constrain the domains used in inter-domain path computation, explicitly specifying which domains to be expanded or excluded; and
3. PCCまたはPCEは、ドメイン間パスの計算で使用されるドメインを制約し、拡張または除外するドメインを明示的に指定します。そして
4. a PCE in the per-domain path computation model [RFC5152] to identify the next domain.
4. ドメインごとのパス計算モデル[RFC5152]のPCEを使用して、次のドメインを識別します。
A domain sequence appears in PCEP messages, notably in:
ドメインシーケンスは、PCEPメッセージ、特に次の場所に表示されます。
o Include Route Object (IRO): As per [RFC5440], IRO can be used to specify a set of network elements to be traversed to reach the destination, which includes subobjects used to specify the domain sequence.
o Include Route Object（IRO）：[RFC5440]に従い、IROを使用して、宛先に到達するために通過するネットワーク要素のセットを指定できます。これには、ドメインシーケンスの指定に使用されるサブオブジェクトが含まれます。
o Exclude Route Object (XRO): As per [RFC5521], XRO can be used to specify certain abstract nodes, to be excluded from the whole path, which include subobjects used to specify the domain sequence.
o 除外ルートオブジェクト（XRO）：[RFC5521]に従って、XROを使用して、ドメインシーケンスの指定に使用されるサブオブジェクトを含む、パス全体から除外する特定の抽象ノードを指定できます。
o Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], EXRS can be used to specify exclusion of certain abstract nodes (including domains) between a specific pair of nodes. EXRS is a subobject inside the IRO.
o 明示的除外ルートサブオブジェクト（EXRS）：[RFC5521]に従い、EXRSを使用して、特定のノードのペア間の特定の抽象ノード（ドメインを含む）の除外を指定できます。 EXRSはIRO内のサブオブジェクトです。
o Explicit Route Object (ERO): As per [RFC5440], ERO can be used to specify a computed path in the network. For example, in the case of H-PCE [RFC6805], a parent PCE can send the domain sequence as a result in a path computation reply using ERO.
o 明示的ルートオブジェクト（ERO）：[RFC5440]に従って、EROを使用してネットワーク内の計算されたパスを指定できます。たとえば、H-PCE [RFC6805]の場合、親PCEはEROを使用してパス計算応答の結果としてドメインシーケンスを送信できます。
As per [RFC5440], IRO can be used to specify that the computed path needs to traverse a set of specified network elements or abstract nodes.
[RFC5440]に従い、IROを使用して、計算されたパスが指定されたネットワーク要素または抽象ノードのセットを通過する必要があることを指定できます。
Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477], and [RFC4874], but new subobjects related to domain sequence are needed.
一部のサブオブジェクトは[RFC3209]、[RFC3473]、[RFC3477]、および[RFC4874]で定義されていますが、ドメインシーケンスに関連する新しいサブオブジェクトが必要です。
This document extends the support for 4-byte AS numbers and IGP areas.
このドキュメントは、4バイトのAS番号とIGPエリアのサポートを拡張します。
Value Description
----- ----------------
5 4-byte AS number
6 OSPF Area ID
7 IS-IS Area ID
Note: Identical subobjects are carried in RSVP-TE messages as defined in [RFC7898].
注：[RFC7898]で定義されているように、同一のサブオブジェクトがRSVP-TEメッセージで伝達されます。
[RFC3209] already defines 2-byte AS numbers.
[RFC3209]はすでに2バイトのAS番号を定義しています。
To support 4-byte AS numbers as per [RFC6793], the following subobject is defined:
[RFC6793]に従って4バイトのAS番号をサポートするために、次のサブオブジェクトが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L bit is an attribute of the subobject as defined in [RFC3209], and its usage in the IRO subobject is defined in [RFC7896].
L：Lビットは[RFC3209]で定義されているサブオブジェクトの属性であり、IROサブオブジェクトでのその使用は[RFC7896]で定義されています。
Type: 5 (indicating a 4-byte AS number).
タイプ：5（4バイトのAS番号を示す）。
Length: 8 (total length of the subobject in bytes).
長さ：8（バイト単位のサブオブジェクトの全長）。
Reserved: Zero at transmission; ignored at receipt.
予約済み：送信時にゼロ。受領時に無視されました。
AS Number: The 4-byte AS number. Note that if 2-byte AS numbers are in use, the low-order bits (16 through 31) MUST be used, and the high-order bits (0 through 15) MUST be set to zero.
AS番号：4バイトのAS番号。 2バイトのAS番号が使用されている場合は、下位ビット（16〜31）を使用する必要があり、上位ビット（0〜15）をゼロに設定する必要があることに注意してください。
Since the length and format of Area ID is different for OSPF and IS-IS, the following two subobjects are defined below:
エリアIDの長さと形式はOSPFとIS-ISで異なるため、次の2つのサブオブジェクトを以下に定義します。
For OSPF, the Area ID is a 32-bit number. The subobject is encoded as follows:
OSPFの場合、エリアIDは32ビットの数値です。サブオブジェクトは次のようにエンコードされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L bit is an attribute of the subobject as defined in [RFC3209], and its usage in the IRO subobject is defined in [RFC7896].
L：Lビットは[RFC3209]で定義されているサブオブジェクトの属性であり、IROサブオブジェクトでのその使用は[RFC7896]で定義されています。
Type: 6 (indicating a 4-byte OSPF Area ID).
タイプ：6（4バイトのOSPFエリアIDを示す）。
Length: 8 (total length of the subobject in bytes).
長さ：8（バイト単位のサブオブジェクトの全長）。
Reserved: Zero at transmission; ignored at receipt.
予約済み：送信時にゼロ。受領時に無視されました。
OSPF Area ID: The 4-byte OSPF Area ID.
OSPFエリアID：4バイトのOSPFエリアID。
For IS-IS, the Area ID is of variable length; thus, the length of the subobject is variable. The Area ID is as described in IS-IS by the ISO standard [ISO10589]. The subobject is encoded as follows:
IS-ISの場合、エリアIDは可変長です。したがって、サブオブジェクトの長さは可変です。エリアIDは、ISO標準[ISO10589]によってIS-ISに記述されているとおりです。サブオブジェクトは次のようにエンコードされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Area-Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IS-IS Area ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L bit is an attribute of the subobject as defined in [RFC3209], and its usage in the IRO subobject is defined in [RFC7896].
L：Lビットは[RFC3209]で定義されているサブオブジェクトの属性であり、IROサブオブジェクトでのその使用は[RFC7896]で定義されています。
Type: 7 (indicating the IS-IS Area ID).
タイプ：7（IS-ISエリアIDを示す）。
Length: Variable. The length MUST be at least 8 and MUST be a multiple of 4.
長さ：可変。長さは少なくとも8でなければならず、4の倍数でなければなりません。
Area-Len: Variable (length of the actual (non-padded) IS-IS area identifier in octets; valid values are from 1 to 13, inclusive).
Area-Len：変数（実際の（パディングされていない）IS-ISエリア識別子の長さ（オクテット）。有効な値は1〜13です）。
Reserved: Zero at transmission; ignored at receipt.
予約済み：送信時にゼロ。受領時に無視されました。
IS-IS Area ID: The variable-length IS-IS area identifier. Padded with trailing zeroes to a 4-byte boundary.
IS-ISエリアID：可変長のIS-ISエリアID。末尾のゼロで4バイト境界まで埋め込まれます。
[RFC5440] describes IRO as an optional object used to specify network elements to be traversed by the computed path. It further states that the L bit of such subobject has no meaning within an IRO. It also does not mention if IRO is an ordered or unordered list of subobjects.
[RFC5440]は、計算されたパスが通過するネットワーク要素を指定するために使用されるオプションのオブジェクトとしてIROを説明しています。さらに、そのようなサブオブジェクトのLビットはIRO内では意味がないと述べています。 IROがサブオブジェクトの順序付きリストまたは順序なしリストであるかどうかについても触れられていません。
An update to the IRO specification [RFC7896] makes IRO as an ordered list and includes support for the L bit.
IRO仕様[RFC7896]の更新により、IROが順序付きリストになり、Lビットのサポートが含まれます。
The use of IRO for the domain sequence assumes the updated specification is being used for IRO, as per [RFC7896].
ドメインシーケンスにIROを使用する場合、[RFC7896]のように、更新された仕様がIROに使用されていることを前提としています。
The subobject type for IPv4, IPv6, and unnumbered Interface IDs can be used to specify boundary nodes (ABR/ASBR) and inter-AS links. The subobject type for the AS Number (2 or 4 bytes) and the IGP area are used to specify the domain identifiers in the domain sequence.
IPv4、IPv6、および番号なしインターフェースIDのサブオブジェクトタイプを使用して、境界ノード（ABR / ASBR）およびAS間リンクを指定できます。 AS番号のサブオブジェクトタイプ（2または4バイト）およびIGPエリアは、ドメインシーケンスでドメイン識別子を指定するために使用されます。
The IRO can incorporate the new domain subobjects with the existing subobjects in a sequence of traversal.
IROは、新しいドメインサブオブジェクトを既存のサブオブジェクトと一連の走査で組み込むことができます。
Thus, an IRO, comprising subobjects, that represents a domain sequence defines the domains involved in an inter-domain path computation, typically involving two or more collaborative PCEs.
したがって、ドメインシーケンスを表すサブオブジェクトを含むIROは、ドメイン間パスの計算に関与するドメインを定義します。これには、通常、2つ以上の協調PCEが関与します。
A domain sequence can have varying degrees of granularity. It is possible to have a domain sequence composed of, uniquely, AS identifiers. It is also possible to list the involved IGP areas for a given AS.
ドメインシーケンスの粒度はさまざまです。一意にAS識別子で構成されるドメインシーケンスを持つことが可能です。特定のASに関連するIGPエリアをリストすることもできます。
In any case, the mapping between domains and responsible PCEs is not defined in this document. It is assumed that a PCE that needs to obtain a "next PCE" from a domain sequence is able to do so (e.g., via administrative configuration or discovery).
いずれの場合でも、ドメインと責任のあるPCE間のマッピングは、このドキュメントでは定義されていません。ドメインシーケンスから「次のPCE」を取得する必要があるPCEは、（たとえば、管理構成または検出を介して）取得できると想定されています。
A PCC builds an IRO to encode the domain sequence, so that the cooperating PCEs could compute an inter-domain shortest constrained path across the specified sequence of domains.
PCCはIROを構築してドメインシーケンスをエンコードし、協調するPCEが指定されたドメインシーケンス全体のドメイン間最短制約パスを計算できるようにします。
A PCC may intersperse area and AS subobjects with other subobjects without change to the previously specified processing of those subobjects in the IRO.
PCCは、IROで以前に指定されたサブオブジェクトの処理を変更せずに、エリアおよびASサブオブジェクトを他のサブオブジェクトに散在させることができます。
If a PCE receives an IRO in a Path Computation Request (PCReq) message that contains the subobjects defined in this document that it does not recognize, it will respond according to the rules for a malformed object as per [RFC5440]. The PCE MAY also include the IRO in the PCEP Error (PCErr) message as per [RFC5440].
PCEが、このドキュメントで定義されているサブオブジェクトを含むPath Computation Request（PCReq）メッセージでIROを受信すると、それが認識しない場合、[RFC5440]の不正なオブジェクトのルールに従って応答します。 PCEは、[RFC5440]に従って、PCEPエラー（PCErr）メッセージにIROを含めることもできます（MAY）。
The interpretation of the L bit is as per Section 4.3.3.1 of [RFC3209] (as per [RFC7896]).
Lビットの解釈は、[RFC3209]のセクション4.3.3.1に従います（[RFC7896]に従います）。
In a Path Computation Reply (PCRep), PCE MAY also supply IRO (with domain sequence information) with the NO-PATH object indicating that the set of elements (domains) of the request's IRO prevented the PCEs from finding a path.
パス計算応答（PCRep）では、PCEはIRO（ドメインシーケンス情報を含む）にNO-PATHオブジェクトを提供して、要求のIROの要素（ドメイン）のセットがPCEによるパスの検出を妨げたことを示します。
The following processing rules apply for a domain sequence in IRO:
IROのドメインシーケンスには、次の処理ルールが適用されます。
o When a PCE parses an IRO, it interprets each subobject according to the AS number associated with the preceding subobject. We call this the "current AS". Certain subobjects modify the current AS, as follows.
o PCEはIROを解析するときに、先行するサブオブジェクトに関連付けられているAS番号に従って各サブオブジェクトを解釈します。これを「現在のAS」と呼びます。特定のサブオブジェクトは、次のように現在のASを変更します。
* The current AS is initialized to the AS number of the PCC.
* 現在のASは、PCCのAS番号に初期化されます。
* If the PCE encounters an AS subobject, then it updates the current AS to this new AS number.
* PCEがASサブオブジェクトを検出すると、現在のASをこの新しいAS番号に更新します。
* If the PCE encounters an area subobject, then it assumes that the area belongs to the current AS.
* PCEがエリアサブオブジェクトを検出すると、そのエリアは現在のASに属していると見なされます。
* If the PCE encounters an IP address that is globally routable, then it updates the current AS to the AS that owns this IP address. This document does not define how the PCE learns which AS owns the IP address.
* PCEは、グローバルにルーティング可能なIPアドレスを検出すると、現在のASを、このIPアドレスを所有するASに更新します。このドキュメントでは、PCEがIPアドレスを所有するASを学習する方法を定義していません。
* If the PCE encounters an IP address that is not globally routable, then it assumes that it belongs to the current AS.
* PCEは、グローバルにルーティングできないIPアドレスを検出すると、現在のASに属していると見なします。
* If the PCE encounters an unnumbered link, then it assumes that it belongs to the current AS.
* PCEが番号なしリンクを検出した場合、PCEは現在のASに属していると見なします。
o When a PCE parses an IRO, it interprets each subobject according to the Area ID associated with the preceding subobject. We call this the "current area". Certain subobjects modify the current area, as follows.
o PCEはIROを解析するときに、前のサブオブジェクトに関連付けられているエリアIDに従って各サブオブジェクトを解釈します。これを「現在のエリア」と呼びます。特定のサブオブジェクトは、次のように現在の領域を変更します。
* The current area is initialized to the Area ID of the PCC.
* 現在の領域は、PCCの領域IDに初期化されます。
* If the current AS is changed, the current area is reset and needs to be determined again by a current or subsequent subobject.
* 現在のASが変更された場合、現在の領域はリセットされ、現在または後続のサブオブジェクトによって再度決定される必要があります。
* If the PCE encounters an area subobject, then it updates the current area to this new Area ID.
* PCEがエリアサブオブジェクトを検出すると、現在のエリアをこの新しいエリアIDに更新します。
* If the PCE encounters an IP address that belongs to a different area, then it updates the current area to the area that has this IP address. This document does not define how the PCE learns which area has the IP address.
* PCEが別のエリアに属するIPアドレスを検出すると、現在のエリアをこのIPアドレスを持つエリアに更新します。このドキュメントでは、PCEがIPアドレスを持つエリアを学習する方法を定義していません。
* If the PCE encounters an unnumbered link that belongs to a different area, then it updates the current Area to the area that has this link.
* PCEが別のエリアに属する番号なしのリンクを検出した場合、PCEは現在のエリアをこのリンクのあるエリアに更新します。
* Otherwise, it assumes that the subobject belongs to the current area.
* それ以外の場合は、サブオブジェクトが現在の領域に属していると想定します。
o In case the current PCE is not responsible for the path computation in the current AS or area, then the PCE selects the "next PCE" in the domain sequence based on the current AS and area.
o 現在のPCEが現在のASまたはエリアでのパス計算を担当しない場合、PCEは現在のASおよびエリアに基づいてドメインシーケンスの「次のPCE」を選択します。
Note that it is advised that PCC should use AS and area subobjects while building the domain sequence in IRO and avoid using other mechanisms to change the "current AS" and "current area" as described above.
PCCはIROでドメインシーケンスを構築するときにASおよびエリアサブオブジェクトを使用し、他のメカニズムを使用して上記の「現在のAS」および「現在のエリア」を変更しないようにすることをお勧めします。
XRO [RFC5521] is an optional object used to specify exclusion of certain abstract nodes or resources from the whole path.
XRO [RFC5521]は、特定の抽象ノードまたはリソースをパス全体から除外することを指定するために使用されるオプションのオブジェクトです。
Some subobjects are to be used in XRO as defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5520], but new subobjects related to domain sequence are needed.
[RFC3209]、[RFC3477]、[RFC4874]、および[RFC5520]で定義されているように、いくつかのサブオブジェクトがXROで使用されますが、ドメインシーケンスに関連する新しいサブオブジェクトが必要です。
This document extends the support for 4-byte AS numbers and IGP areas.
このドキュメントは、4バイトのAS番号とIGPエリアのサポートを拡張します。
Value Description
----- ----------------
5 4-byte AS number
6 OSPF Area ID
7 IS-IS Area ID
Note: Identical subobjects are carried in RSVP-TE messages as defined in [RFC7898].
注：[RFC7898]で定義されているように、同一のサブオブジェクトがRSVP-TEメッセージで伝達されます。
The new subobjects to support 4-byte AS numbers and the IGP (OSPF/IS-IS) area MAY also be used in the XRO to specify exclusion of certain domains in the path computation procedure.
4バイトのAS番号とIGP（OSPF / IS-IS）領域をサポートする新しいサブオブジェクトは、XROでも使用して、パス計算手順で特定のドメインの除外を指定できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The X-bit indicates whether the exclusion is mandatory or desired.
Xビットは、除外が必須か望ましいかを示します。
0: indicates that the AS specified MUST be excluded from the path computed by the PCE(s).
0：指定されたASがPCEによって計算されたパスから除外されなければならないことを示します。
1: indicates that the AS specified SHOULD be avoided from the inter-domain path computed by the PCE(s), but it MAY be included subject to PCE policy and the absence of a viable path that meets the other constraints.
1：指定されたASは、PCEによって計算されたドメイン間パスから回避する必要があることを示しますが、PCEポリシーおよび他の制約を満たす実行可能なパスがないことを条件として含めることができます。
All other fields are consistent with the definition in Section 3.4.
他のすべてのフィールドは、セクション3.4の定義と一致しています。
Since the length and format of the Area ID is different for OSPF and IS-IS, the following two subobjects are defined:
エリアIDの長さと形式はOSPFとIS-ISで異なるため、次の2つのサブオブジェクトが定義されています。
For OSPF, the Area ID is a 32-bit number. The subobject is encoded as follows:
OSPFの場合、エリアIDは32ビットの数値です。サブオブジェクトは次のようにエンコードされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The X-bit indicates whether the exclusion is mandatory or desired.
Xビットは、除外が必須か望ましいかを示します。
0: indicates that the OSPF area specified MUST be excluded from the path computed by the PCE(s).
0：指定されたOSPFエリアがPCEによって計算されたパスから除外されなければならないことを示します。
1: indicates that the OSPF area specified SHOULD be avoided from the inter-domain path computed by the PCE(s), but it MAY be included subject to PCE policy and the absence of a viable path that meets the other constraints.
1：指定されたOSPFエリアは、PCEによって計算されたドメイン間パスから回避する必要があることを示しますが、PCEポリシーおよび他の制約を満たす実行可能なパスがないことを条件として含めることができます（MAY）。
All other fields are consistent with the definition in Section 3.4.
他のすべてのフィールドは、セクション3.4の定義と一致しています。
For IS-IS, the Area ID is of variable length; thus, the length of the subobject is variable. The Area ID is as described in IS-IS by the ISO standard [ISO10589]. The subobject is encoded as follows:
IS-ISの場合、エリアIDは可変長です。したがって、サブオブジェクトの長さは可変です。エリアIDは、ISO標準[ISO10589]によってIS-ISに記述されているとおりです。サブオブジェクトは次のようにエンコードされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type | Length | Area-Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IS-IS Area ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The X-bit indicates whether the exclusion is mandatory or desired.
Xビットは、除外が必須か望ましいかを示します。
0: indicates that the IS-IS area specified MUST be excluded from the path computed by the PCE(s).
0：指定されたIS-ISエリアがPCEによって計算されたパスから除外されなければならないことを示します。
1: indicates that the IS-IS area specified SHOULD be avoided from the inter-domain path computed by the PCE(s), but it MAY be included subject to PCE policy and the absence of a viable path that meets the other constraints.
1：指定されたIS-ISエリアは、PCEによって計算されたドメイン間パスから回避する必要があることを示しますが、PCEポリシーおよび他の制約を満たす実行可能なパスがないことを条件に含めることができます。
All other fields are consistent with the definition in Section 3.4.
他のすべてのフィールドは、セクション3.4の定義と一致しています。
All the processing rules are as per [RFC5521].
すべての処理ルールは[RFC5521]に準拠しています。
Note that if a PCE receives an XRO in a PCReq message that contains subobjects defined in this document that it does not recognize, it will respond according to the rules for a malformed object as per [RFC5440].
PCEが、このドキュメントで定義されているサブオブジェクトを含むPCReqメッセージでXROを受信した場合、認識されない場合、[RFC5440]の不正なオブジェクトのルールに従って応答します。
IGP area subobjects in the XRO are local to the current AS. In case multi-AS path computation excludes an IGP area in a different AS, the IGP area subobject should be part of EXRS in the IRO to specify the AS in which the IGP area is to be excluded. Further, policy may be applied to prune/ignore area subobjects in XRO after a "current AS" change during path computation.
XROのIGPエリアサブオブジェクトは、現在のASに対してローカルです。マルチASパス計算が別のASのIGPエリアを除外する場合、IGPエリアが除外されるASを指定するには、IGPエリアサブオブジェクトをIROのEXRSの一部にする必要があります。さらに、パスの計算中に「現在のAS」が変更された後、XROのエリアサブオブジェクトをプルーニング/無視するポリシーを適用できます。
The EXRS [RFC5521] is used to specify exclusion of certain abstract nodes between a specific pair of nodes.
EXRS [RFC5521]は、特定のノードのペア間の特定の抽象ノードの除外を指定するために使用されます。
The EXRS can carry any of the subobjects defined for inclusion in the XRO; thus, the new subobjects to support 4-byte AS numbers and the IGP (OSPF / IS-IS) area can also be used in the EXRS. The meanings of the fields of the new XRO subobjects are unchanged when the subobjects are included in an EXRS, except that the scope of the exclusion is limited to the single hop between the previous and subsequent elements in the IRO.
EXRSは、XROに含めるために定義されたサブオブジェクトを運ぶことができます。したがって、4バイトのAS番号とIGP（OSPF / IS-IS）領域をサポートする新しいサブオブジェクトも、EXRSで使用できます。サブオブジェクトがEXRSに含まれている場合、新しいXROサブオブジェクトのフィールドの意味は変わりませんが、除外の範囲はIROの前の要素と後続の要素の間の単一ホップに制限されます。
The EXRS should be interpreted in the context of the current AS and current area of the preceding subobject in the IRO. The EXRS does not change the current AS or current area. All other processing rules are as per [RFC5521].
EXRSは、IROの前のサブオブジェクトの現在のASおよび現在の領域のコンテキストで解釈される必要があります。 EXRSは、現在のASまたは現在のエリアを変更しません。他のすべての処理ルールは[RFC5521]と同じです。
Note that if a PCE that supports the EXRS in an IRO parses an IRO, and encounters an EXRS that contains subobjects defined in this document that it does not recognize, it will act according to the setting of the X-bit in the subobject as per [RFC5521].
IROでEXRSをサポートするPCEがIROを解析し、このドキュメントで定義されているサブオブジェクトを含むEXRSが認識されない場合、サブオブジェクトのXビットの設定に従って動作します。 [RFC5521]。
ERO [RFC5440] is used to specify a computed path in the network. PCEP ERO subobject types correspond to RSVP-TE ERO subobject types as defined in [RFC3209], [RFC3473], [RFC3477], [RFC4873], [RFC4874], and [RFC5520]. The subobjects related to the domain sequence are further defined in [RFC7898].
ERO [RFC5440]は、ネットワークで計算されたパスを指定するために使用されます。 PCEP EROサブオブジェクトタイプは、[RFC3209]、[RFC3473]、[RFC3477]、[RFC4873]、[RFC4874]、および[RFC5520]で定義されているRSVP-TE EROサブオブジェクトタイプに対応しています。ドメインシーケンスに関連するサブオブジェクトは、[RFC7898]でさらに定義されています。
The new subobjects to support 4-byte AS numbers and the IGP (OSPF/IS-IS) area can also be used in the ERO to specify an abstract node (a group of nodes whose internal topology is opaque to the ingress node of the LSP). Using this concept of abstraction, an explicitly routed LSP can be specified as a sequence of domains.
4バイトのAS番号とIGP（OSPF / IS-IS）エリアをサポートする新しいサブオブジェクトをEROで使用して、抽象ノード（LSPの入力ノードに対して内部トポロジが不透明なノードのグループ）を指定することもできます。 ）。この抽象化の概念を使用すると、明示的にルーティングされたLSPを一連のドメインとして指定できます。
In case of H-PCE [RFC6805], a parent PCE can be requested to find the domain sequence. Refer to the example in Section 4.6 of this document. The ERO in reply from the parent PCE can then be used in per-domain path computation or BRPC.
H-PCE [RFC6805]の場合、親PCEにドメインシーケンスの検索を要求できます。このドキュメントのセクション4.6の例を参照してください。親PCEからのEROは、ドメインごとのパス計算またはBRPCで使用できます。
If a PCC receives an ERO in a PCRep message that contains a subobject defined in this document that it does not recognize, it will respond according to the rules for a malformed object as per [RFC5440].
PCCが、このドキュメントで定義されていないサブオブジェクトを含むPCRepメッセージでEROを受信した場合、PCCが認識しないと、[RFC5440]の不正なオブジェクトのルールに従って応答します。
The examples in this section are for illustration purposes only to highlight how the new subobjects could be encoded. They are not meant to be an exhaustive list of all possible use cases and combinations.
このセクションの例は、新しいサブオブジェクトをエンコードする方法を強調するための説明のみを目的としています。これらは、考えられるすべての使用例と組み合わせの完全なリストであることを意味していません。
In an inter-area path computation where the ingress and the egress nodes belong to different IGP areas within the same AS, the domain sequence could be represented using an ordered list of area subobjects.
入力ノードと出力ノードが同じAS内の異なるIGPエリアに属しているエリア間パス計算では、ドメインシーケンスは、エリアサブオブジェクトの順序付きリストを使用して表すことができます。
----------------- -----------------
| | | |
| +--+ | | +--+ |
| +--+ | | | | | | |
| | | +--+ | | +--+ +--+ |
| +--+ | | | | |
| | | +--+ |
| +--+ | | |
| | | | | +--+ |
| +--+ | | | | |
| | -------------------------- | +--+ |
| +--+ +--+ |
| | | +--+ | | |
|Area 2 +--+ | | +--+ Area 4 |
----------------- | +--+ | -----------------
| |
| +--+ |
| +--+ | | |
| | | +--+ |
| +--+ |
| |
| |
| |
| |
| +--+ |
| | | |
| +--+ |
----------------- | | ------------------
| +--+ +--+ |
| | | | | |
| +--+ Area 0 +--+ |
| | -------------------------- | +--+ |
| +--+ | | | | |
| | | | | +--+ |
| +--+ +--+ | | |
| | | | | +--+ |
| +--+ | | | | |
| | | +--+ |
| +--+ | | |
| | | | | +--+ |
| +--+ | | | | |
| | | +--+ |
| | | |
| Area 1 | | Area 5 |
----------------- ------------------
Figure 1: Inter-Area Path Computation
図1：エリア間パスの計算
The AS Number is 100.
AS番号は100です。
If the ingress is in area 2, the egress is in area 4, and transit is through area 0, here are some possible ways a PCC can encode the IRO:
入口がエリア2にあり、出口がエリア4にあり、通過がエリア0を経由する場合、PCCがIROをエンコードできるいくつかの可能な方法を次に示します。
+---------+ +---------+ +---------+
|IRO | |Sub- | |Sub- |
|Object | |object | |object |
|Header | |Area 0 | |Area 4 |
| | | | | |
| | | | | |
+---------+ +---------+ +---------+
or
または
+---------+ +---------+ +---------+ +---------+
|IRO | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object |
|Header | |Area 2 | |Area 0 | |Area 4 |
| | | | | | | |
| | | | | | | |
+---------+ +---------+ +---------+ +---------+
or
または
+---------+ +---------+ +---------+ +---------+ +---------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object AS| |object | |object | |object |
|Header | |100 | |Area 2 | |Area 0 | |Area 4 |
| | | | | | | | | |
| | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+
The domain sequence can further include encompassing AS information in the AS subobject.
ドメインシーケンスには、ASサブオブジェクトにAS情報を含めることができます。
In inter-AS path computation, where the ingress and egress belong to different ASes, the domain sequence could be represented using an ordered list of AS subobjects. The domain sequence can further include decomposed area information in the area subobject.
入力と出力が異なるASに属するAS間パス計算では、ドメインシーケンスは、ASサブオブジェクトの順序付きリストを使用して表すことができます。ドメインシーケンスはさらに、エリアサブオブジェクトに分解エリア情報を含めることができます。
As shown in Figure 2, where AS has a single area, the AS subobject in the domain sequence can uniquely identify the next domain and PCE.
図2に示すように、ASに単一の領域がある場合、ドメインシーケンスのASサブオブジェクトは、次のドメインとPCEを一意に識別できます。
AS A AS E AS C
<-------------> <----------> <------------->
A4----------E1---E2---E3---------C4
/ / \
/ / \
/ / AS B \
/ / <----------> \
Ingress------A1---A2------B1---B2---B3------C1---C2------Egress
\ / /
\ / /
\ / /
\ / /
A3----------D1---D2---D3---------C3
<---------->
AS D
* All ASes have one area (area 0)
* すべてのASには1つのエリア（エリア0）があります
Figure 2: Inter-AS Path Computation
図2：AS間パスの計算
If the ingress is in AS A, the egress is in AS C, and transit is through AS B, here are some possible ways a PCC can encode the IRO:
入力がAS Aにあり、出力がAS Cにあり、トランジットがAS Bを経由する場合、PCCがIROをエンコードできるいくつかの可能な方法を次に示します。
+-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- |
|Object | |object | |object |
|Header | |AS B | |AS C |
| | | | | |
+-------+ +-------+ +-------+
or
または
+-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object |
|Header | |AS A | |AS B | |AS C |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
or
または
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object | |object | |object | |object |
|Header | |AS A | |Area 0 | |AS B | |Area 0 | |AS C | |Area 0 |
| | | | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
Note that to get a domain disjoint path, the ingress could also request the backup path with:
ドメインのばらばらのパスを取得するために、イングレスは次のコマンドでバックアップパスをリクエストすることもできます。
+-------+ +-------+
|XRO | |Sub |
|Object | |Object |
|Header | |AS B |
| | | |
+-------+ +-------+
As described in Section 3.4.3, a domain subobject in IRO changes the
domain information associated with the next set of subobjects till
you encounter a subobject that changes the domain too. Consider the
following IRO:
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object | |object | |object |
|Header | |AS B | |IP | |IP | |AS C | |IP |
| | | | |B1 | |B3 | | | |C1 |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
On processing subobject "AS B", it changes the AS of the subsequent subobjects till we encounter another subobject "AS C" that changes the AS for its subsequent subobjects.
サブオブジェクト「AS B」の処理では、後続のサブオブジェクトのASを変更する別のサブオブジェクト「AS C」に遭遇するまで、後続のサブオブジェクトのASを変更します。
Consider another IRO:
別のIROを検討してください。
+-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object | |object |
|Header | |AS D | |IP | |IP | |IP |
| | | | |D1 | |D3 | |C3 |
+-------+ +-------+ +-------+ +-------+ +-------+
Here as well, on processing "AS D", it changes the AS of the subsequent subobjects till you encounter another subobject "C3" that belongs in another AS and changes the AS for its subsequent subobjects.
ここでも、「AS D」の処理時に、別のASに属する別のサブオブジェクト「C3」に出会うまで、後続のサブオブジェクトのASを変更し、後続のサブオブジェクトのASを変更します。
Further description for the boundary node and inter-AS link can be found in Section 4.3.
境界ノードとAS間リンクの詳細については、セクション4.3を参照してください。
In Figure 3, AS 200 is made up of multiple areas.
図3では、AS 200は複数のエリアで構成されています。
|
| +-------------+ +----------------+
| |Area 2 | |Area 4 |
| | +--+| | +--+ |
| | | || | | B| |
| | +--+ +--+| | +--+ +--+ |
| | | | | | | | |
| | +--+ | | +--+ |
| | +--+ | | +--+ |
| | | | | | | | |
| | +--+ | | +--+ +--+ |
| | +--+ |+--------------+| | | |
| | | | +--+ +--+ +--+ |
+-------------+| | +--+ | | | | |
| || | +--+ +--+ |
| +--+|| +-------------+| |+----------------+
| | ||| | +--+ |
| +--+|| | | | |
| +--+ || | +--+ |
| | | +---+ +--+ |
| +--+ | |----------------| | |
| +---+ Inter-AS +--+ +--+ |
|+--+ || Links | | | |
||A | +---+ +--+ +--+ |
|+--+ | |----------------| | |
| +---+ +--+ +--+ |
| +--+ || +------------+ | | | |+----------------+
| | | || |Area 3 +--+ +--+ +--+ Area 5 |
| +--+ || | | | | | |
| || | +--+ +--+ |
| +--+|| | +--+ | | Area 0 || +--+ |
| | ||| | | | | +--------------+| | | |
| +--+|| | +--+ | | +--+ |
| || | | | +--+ |
|Area 0 || | +--+ | | +--+ | | |
+-------------+| | | | | | | | +--+ |
| | +--+ +--+ | +--+ |
| | | | | |
| | +--+ | +--+ |
| | +--+ | | | C| |
| | | | | | +--+ |
| | +--+ | | |
| | | | |
| +------------+ +----------------+
|
AS 100 | AS 200
|
Figure 3: Inter-AS Path Computation
For LSP (A-B), where ingress A is in (AS 100, area 0), egress B is in (AS 200, area 4), and transit is through (AS 200, area 0), here are some possible ways a PCC can encode the IRO:
入力Aが（AS 100、エリア0）にあり、出力Bが（AS 200、エリア4）にあり、トランジットが（AS 200、エリア0）を通過するLSP（AB）の場合、PCCにはいくつかの可能な方法がありますIROをエンコードできます：
+-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object |
|Header | |AS 200 | |Area 0 | |Area 4 |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
or
または
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object | |object | |object |
|Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 4 |
| | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
For LSP (A-C), where ingress A is in (AS 100, area 0), egress C is in (AS 200, area 5), and transit is through (AS 200, area 0), here are some possible ways a PCC can encode the IRO:
入力Aが（AS 100、エリア0）にあり、出力Cが（AS 200、エリア5）にあり、トランジットが（AS 200、エリア0）を通過するLSP（AC）の場合、PCCにはいくつかの可能な方法がありますIROをエンコードできます：
+-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object |
|Header | |AS 200 | |Area 0 | |Area 5 |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
or
または
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object | |object | |object |
|Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 5 |
| | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
A PCC or PCE can include additional constraints covering which boundary nodes (ABR or ASBR) or border links (inter-AS link) to be traversed while defining a domain sequence. In which case, the boundary node or link can be encoded as a part of the domain sequence.
PCCまたはPCEには、ドメインシーケンスの定義中に通過する境界ノード（ABRまたはASBR）または境界リンク（inter-ASリンク）をカバーする追加の制約を含めることができます。その場合、境界ノードまたはリンクをドメインシーケンスの一部としてエンコードできます。
Boundary nodes (ABR/ASBR) can be encoded using the IPv4 or IPv6 prefix subobjects, usually with a loopback address of 32 and a prefix length of 128, respectively. An inter-AS link can be encoded using the IPv4 or IPv6 prefix subobjects or unnumbered interface subobjects.
境界ノード（ABR / ASBR）は、IPv4またはIPv6プレフィックスサブオブジェクトを使用してエンコードできます。通常、それぞれループバックアドレスは32で、プレフィックス長は128です。 AS間リンクは、IPv4またはIPv6プレフィックスサブオブジェクトまたは番号なしインターフェイスサブオブジェクトを使用してエンコードできます。
For Figure 1, an ABR (say, 203.0.113.1) to be traversed can be specified in IRO as:
図1の場合、トラバースされるABR（たとえば、203.0.113.1）はIROで次のように指定できます。
+---------+ +---------+ +---------++---------+ +---------+
|IRO | |Sub- | |Sub- ||Sub- | |Sub- |
|Object | |object | |object ||object | |object |
|Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 |
| | | | |203.0. || | | |
| | | | |112.1 || | | |
+---------+ +---------+ +---------++---------+ +---------+
For Figure 3, an inter-AS link (say, 198.51.100.1 - 198.51.100.2) to be traversed can be specified as:
図3の場合、トラバースされるAS間リンク（たとえば、198.51.100.1-198.51.100.2）は、次のように指定できます。
+---------+ +---------+ +---------+ +---------+
|IRO | |Sub- | |Sub- | |Sub- |
|Object | |object AS| |object | |object AS|
|Header | |100 | |IPv4 | |200 |
| | | | |198.51. | | |
| | | | |100.2 | | |
+---------+ +---------+ +---------+ +---------+
A single PCE can be responsible for multiple domains; for example, PCE function deployed on an ABR could be responsible for multiple areas. A PCE that can support adjacent domains can internally handle those domains in the domain sequence without any impact on the other domains in the domain sequence.
1つのPCEが複数のドメインを担当できます。たとえば、ABRに展開されたPCE機能は、複数の領域を担当する可能性があります。隣接ドメインをサポートできるPCEは、ドメインシーケンス内の他のドメインに影響を与えることなく、ドメインシーケンス内のそれらのドメインを内部的に処理できます。
[RFC7334] describes an experimental inter-domain P2MP path computation mechanism where the path domain tree is described as a series of domain sequences; an example is shown in the figure below:
[RFC7334]は、パスドメインツリーが一連のドメインシーケンスとして記述される、実験的なドメイン間P2MPパス計算メカニズムを記述しています。下の図に例を示します。
+----------------+
| |Domain D1
| R |
| |
| A |
| |
+-B------------C-+
/ \
/ \
/ \
Domain D2 / \ Domain D3
+-------------D--+ +-----E----------+
| | | |
| F | | |
| G | | H |
| | | |
| | | |
+-I--------------+ +-J------------K-+
/\ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ Domain D4 \ Domain D5 / Domain D6 \
+-L-------------W+ +------P---------+ +-----------T----+
| | | | | |
| | | Q | | U |
| M O | | S | | |
| | | | | V |
| N | | R | | |
+----------------+ +----------------+ +----------------+
Figure 4: Domain Tree Example
図4：ドメインツリーの例
The domain tree can be represented as a series of domain sequences:
ドメインツリーは一連のドメインシーケンスとして表すことができます。
o Domain D1, Domain D3, Domain D6
o ドメインD1、ドメインD3、ドメインD6
o Domain D1, Domain D3, Domain D5
o ドメインD1、ドメインD3、ドメインD5
o Domain D1, Domain D2, Domain D4 The domain sequence handling described in this document could be applied to the P2MP path domain tree.
oドメインD1、ドメインD2、ドメインD4このドキュメントで説明されているドメインシーケンス処理は、P2MPパスドメインツリーに適用できます。
In case of H-PCE [RFC6805], the parent PCE can be requested to determine the domain sequence and return it in the path computation reply, using the ERO. For the example in Section 4.6 of [RFC6805], the domain sequence can possibly appear as:
H-PCE [RFC6805]の場合、EROを使用して、ドメインシーケンスを決定し、それをパス計算応答で返すように親PCEに要求できます。 [RFC6805]のセクション4.6の例では、ドメインシーケンスは次のように表示される可能性があります。
+---------+ +---------+ +---------+ +---------+
|ERO | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object |
|Header | |Domain 1 | |Domain 2 | |Domain 3 |
| | | | | | | |
| | | | | | | |
+---------+ +---------+ +---------+ +---------+
or
または
+---------+ +---------+ +---------+
|ERO | |Sub- | |Sub- |
|Object | |object | |object |
|Header | |BN 21 | |Domain 3 |
| | | | | |
| | | | | |
+---------+ +---------+ +---------+
Instead of a domain sequence, a sequence of PCEs MAY be enforced by policy on the PCC, and this constraint can be carried in the PCReq message (as defined in [RFC5886]).
ドメインシーケンスの代わりに、PCEのシーケンスがPCCのポリシーによって適用される場合があり、この制約はPCReqメッセージで伝達できます（[RFC5886]で定義されています）。
Note that PCE Sequence can be used along with domain sequence, in which case PCE Sequence MUST have higher precedence in selecting the next PCE in the inter-domain path computation procedures.
PCEシーケンスはドメインシーケンスと一緒に使用できることに注意してください。この場合、ドメイン間パス計算手順で次のPCEを選択する際にPCEシーケンスを優先する必要があります。
[RFC3209] already describes the notion of abstract nodes, where an abstract node is a group of nodes whose internal topology is opaque to the ingress node of the LSP. It further defines a subobject for AS but with a 2-byte AS number.
[RFC3209]は抽象ノードの概念をすでに説明しています。抽象ノードは、LSPの入力ノードに対して内部トポロジが不透明なノードのグループです。さらに、ASのサブオブジェクトを定義しますが、AS番号は2バイトです。
[RFC7898] extends the notion of abstract nodes by adding new subobjects for IGP areas and 4-byte AS numbers. These subobjects can be included in ERO, XRO, or EXRS in RSVP-TE.
[RFC7898]は、IGPエリアと4バイトのAS番号の新しいサブオブジェクトを追加することにより、抽象ノードの概念を拡張します。これらのサブオブジェクトは、RSVP-TEのERO、XRO、またはEXRSに含めることができます。
In any case, subobject types defined in RSVP-TE are identical to the subobject types defined in the related documents in PCEP.
いずれの場合でも、RSVP-TEで定義されているサブオブジェクトタイプは、PCEPの関連ドキュメントで定義されているサブオブジェクトタイプと同じです。
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry at <http://www.iana.org/assignments/pcep>. Within this registry, IANA maintains two sub-registries:
IANAは、<http://www.iana.org/assignments/pcep>で「パス計算要素プロトコル（PCEP）番号」レジストリを維持しています。このレジストリ内で、IANAは2つのサブレジストリを保持しています。
o IRO Subobjects
o いろ すぼｂじぇｃｔｓ
o XRO Subobjects
o XROサブオブジェクト
IANA has made identical additions to those registries as follows:
IANAは、これらのレジストリに次のように同じ追加を行いました。
Value Description Reference
----- ---------------- -------------------
5 4-byte AS number RFC 7897, [RFC7898]
6 OSPF Area ID RFC 7897, [RFC7898]
7 IS-IS Area ID RFC 7897, [RFC7898]
Further, IANA has added a reference to this document to the new RSVP numbers that are registered by [RFC7898], as shown on <http://www.iana.org/assignments/rsvp-parameters>.
さらに、<http://www.iana.org/assignments/rsvp-parameters>に示されているように、IANAはこのドキュメントへの参照を[RFC7898]によって登録された新しいRSVP番号に追加しました。
The protocol extensions defined in this document do not substantially change the nature of PCEP. Therefore, the security considerations set out in [RFC5440] apply unchanged. Note that further security considerations for the use of PCEP over TCP are presented in [RFC6952].
このドキュメントで定義されているプロトコル拡張は、PCEPの性質を実質的に変更しません。したがって、[RFC5440]で説明されているセキュリティの考慮事項は変更されずに適用されます。 PCEP over TCPの使用に関するさらなるセキュリティの考慮事項が[RFC6952]に提示されていることに注意してください。
This document specifies a representation of the domain sequence and new subobjects, which could be used in inter-domain PCE scenarios as explained in [RFC5152], [RFC5441], [RFC6805], [RFC7334], etc. The security considerations set out in each of these mechanisms remain unchanged by the new subobjects and domain sequence representation in this document.
このドキュメントは、[RFC5152]、[RFC5441]、[RFC6805]、[RFC7334]などで説明されているドメイン間PCEシナリオで使用できるドメインシーケンスと新しいサブオブジェクトの表現を指定します。これらの各メカニズムは、このドキュメントの新しいサブオブジェクトとドメインシーケンス表現によって変更されません。
But the new subobjects do allow finer and more specific control of the path computed by a cooperating PCE(s). Such control increases the risk if a PCEP message is intercepted, modified, or spoofed because it allows the attacker to exert control over the path that the PCE will compute or to make the path computation impossible. Consequently, it is important that implementations conform to the relevant security requirements of [RFC5440]. These mechanisms include:
ただし、新しいサブオブジェクトでは、協力するPCEによって計算されたパスをより細かく、より具体的に制御できます。このような制御により、PCEPメッセージが傍受、変更、またはスプーフィングされた場合にリスクが高まります。これにより、PCEが計算するパスを攻撃者が制御したり、パス計算を不可能にしたりできるためです。したがって、実装は[RFC5440]の関連するセキュリティ要件に準拠することが重要です。これらのメカニズムは次のとおりです。
o Securing the PCEP session messages using TCP security techniques (Section 10.2 of [RFC5440]). PCEP implementations SHOULD also consider the additional security provided by the TCP Authentication Option (TCP-AO) [RFC5925] or Transport Layer Security (TLS) [PCEPS].
o TCPセキュリティ技術を使用してPCEPセッションメッセージを保護する（[RFC5440]のセクション10.2）。 PCEP実装は、TCP認証オプション（TCP-AO）[RFC5925]またはトランスポート層セキュリティ（TLS）[PCEPS]によって提供される追加のセキュリティも考慮する必要があります（SHOULD）。
o Authenticating the PCEP messages to ensure the messages are intact and sent from an authorized node (Section 10.3 of [RFC5440]).
o PCEPメッセージを認証して、メッセージが損なわれておらず、承認済みノードから送信されていることを確認します（[RFC5440]のセクション10.3）。
o PCEP operates over TCP, so it is also important to secure the PCE and PCC against TCP denial-of-service attacks. Section 10.7.1 of [RFC5440] outlines a number of mechanisms for minimizing the risk of TCP-based denial-of-service attacks against PCEs and PCCs.
o PCEPはTCPを介して動作するため、TCPサービス拒否攻撃からPCEおよびPCCを保護することも重要です。 [RFC5440]のセクション10.7.1は、PCEおよびPCCに対するTCPベースのサービス拒否攻撃のリスクを最小限に抑えるためのいくつかのメカニズムを概説しています。
o In inter-AS scenarios, attacks may be particularly significant with commercial- as well as service-level implications.
o AS間シナリオでは、商用レベルおよびサービスレベルの影響がある場合、攻撃が特に重大になる可能性があります。
Note, however, that the domain sequence mechanisms also provide the operator with the ability to route around vulnerable parts of the network and may be used to increase overall network security.
ただし、ドメインシーケンスメカニズムは、オペレーターにネットワークの脆弱な部分を迂回する機能も提供し、ネットワーク全体のセキュリティを強化するために使用できることに注意してください。
The exact behavior with regards to desired inclusion and exclusion of domains MUST be available for examination by an operator and MAY be configurable. Manual configurations are needed to identify which PCEP peers understand the new domain subobjects defined in this document.
必要なドメインの包含と除外に関する正確な動作は、オペレーターによる検査に利用できなければならず、構成可能である場合があります。このドキュメントで定義されている新しいドメインサブオブジェクトを理解するPCEPピアを特定するには、手動設定が必要です。
A MIB module for management of the PCEP is being specified in a separate document [RFC7420]. This document does not imply any new extension to the current MIB module.
PCEPの管理用のMIBモジュールは、別のドキュメント[RFC7420]で指定されています。このドキュメントは、現在のMIBモジュールに対する新しい拡張を意味するものではありません。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements aside from those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものを除いて、新しい活性検出および監視の要件を意味しません。
Mechanisms defined in this document do not imply any new operation verification requirements aside from those already listed in [RFC5440].
このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものを除いて、新しい動作検証要件を意味するものではありません。
In case of per-domain path computation [RFC5152], where the full path of an inter-domain TE LSP cannot be determined (or is not determined) at the ingress node, a signaling message can use the domain identifiers. The subobjects defined in this document SHOULD be supported by RSVP-TE. [RFC7898] extends the notion of abstract nodes by adding new subobjects for IGP areas and 4-byte AS numbers.
ドメインごとのパス計算[RFC5152]の場合、ドメイン間TE LSPのフルパスが入口ノードで決定できない（または決定されない）場合、シグナリングメッセージはドメイン識別子を使用できます。このドキュメントで定義されているサブオブジェクトは、RSVP-TEでサポートされる必要があります（SHOULD）。 [RFC7898]は、IGPエリアと4バイトのAS番号の新しいサブオブジェクトを追加することにより、抽象ノードの概念を拡張します。
Apart from this, mechanisms defined in this document do not imply any requirements on other protocols aside from those already listed in [RFC5440].
これとは別に、このドキュメントで定義されているメカニズムは、[RFC5440]にすでにリストされているものを除いて、他のプロトコルに対する要件を意味するものではありません。
The mechanisms described in this document can provide the operator with the ability to exert finer and more specific control of the path computation by inclusion or exclusion of domain subobjects. There may be some scaling benefit when a single domain subobject may substitute for many subobjects and can reduce the overall message size and processing.
このドキュメントで説明されているメカニズムは、ドメインサブオブジェクトの包含または除外により、パス計算をより細かく、より具体的に制御する能力をオペレーターに提供できます。単一のドメインサブオブジェクトが多くのサブオブジェクトの代わりになり、全体的なメッセージサイズと処理を減らすことができる場合、スケーリングの利点がいくらかあります。
Backward compatibility issues associated with the new subobjects arise when a PCE does not recognize them, in which case PCE responds according to the rules for a malformed object as per [RFC5440]. For successful operations, the PCEs in the network would need to be upgraded.
新しいサブオブジェクトに関連する下位互換性の問題は、PCEがそれらを認識しない場合に発生します。この場合、PCEは、[RFC5440]の不正なオブジェクトのルールに従って応答します。運用を成功させるには、ネットワーク内のPCEをアップグレードする必要があります。
[ISO10589] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002.
[ISO10589]国際標準化機構、「情報技術-システム間の通信と情報交換-コネクションレスモードのネットワークサービス（ISOを提供するためのプロトコルと組み合わせて使用するための中間システムから中間システムのドメイン内ルーティング情報交換プロトコル8473）」、ISO / IEC 10589：2002、Second Edition、2002。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<http： //www.rfc-editor.org/info/rfc3473>。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, <http://www.rfc-editor.org/info/rfc3477>.
[RFC3477] Kompella、K。、およびY. Rekhter、「Resource ReSerVation Protocol-Traffic Engineering（RSVP-TE）での番号なしリンクのシグナリング」、RFC 3477、DOI 10.17487 / RFC3477、2003年1月、<http：//www.rfc- editor.org/info/rfc3477>。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://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月、<http://www.rfc-editor.org/info/rfc5440>。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, <http://www.rfc-editor.org/info/rfc5441>.
[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、DOI 10.17487 / RFC5441、2009年4月、<http：//www.rfc- editor.org/info/rfc5441>。
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 2009, <http://www.rfc-editor.org/info/rfc5521>.
[RFC5521] Oki、E.、Takeda、T。、およびA. Farrel、「Extensions to the Path Computation Element Communication Protocol（PCEP）for Route Exclusions」、RFC 5521、DOI 10.17487 / RFC5521、2009年4月、<http：/ /www.rfc-editor.org/info/rfc5521>。
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, <http://www.rfc-editor.org/info/rfc6805>.
[RFC6805]キング、D。、エド。およびA.ファレル編、「MPLSおよびGMPLSのドメインシーケンスの決定へのパス計算要素アーキテクチャの適用」、RFC 6805、DOI 10.17487 / RFC6805、2012年11月、<http：//www.rfc -editor.org/info/rfc6805>。
[RFC7896] Dhody, D., "Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)", RFC 7896, DOI 10.17487/RFC7896, June 2016, <http://www.rfc-editor.org/info/rfc7896>.
[RFC7896] Dhody、D。、「経路計算要素通信プロトコル（PCEP）のインクルードルートオブジェクト（IRO）仕様の更新」、RFC 7896、DOI 10.17487 / RFC7896、2016年6月、<http：//www.rfc -editor.org/info/rfc7896>。
[RFC7898] Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, "Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE)", RFC 7898, DOI 10.17487/RFC7898, June 2016, <http://www.rfc-editor.org/info/rfc7898>.
[RFC7898] Dhody、D.、Palle、U.、Kondreddy、V。、およびR. Casellas、「リソース予約プロトコルのドメインサブオブジェクト-トラフィックエンジニアリング（RSVP-TE）」、RFC 7898、DOI 10.17487 / RFC7898、2016年6月、<http://www.rfc-editor.org/info/rfc7898>。
[PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-09, November 2015.
[PCEPS] Lopez、D.、Dios、O.、Wu、W。、およびD. Dhody、「Secure Transport for PCEP」、Work in Progress、draft-ietf-pce-pceps-09、2015年11月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://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月、<http：//www.rfc -editor.org/info/rfc4655>。
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, DOI 10.17487/RFC4726, November 2006, <http://www.rfc-editor.org/info/rfc4726>.
[RFC4726] Farrel、A.、Vasseur、J。、およびA. Ayyangar、「A Framework for Inter-domain Multiprotocol Label Switching Traffic Engineering」、RFC 4726、DOI 10.17487 / RFC4726、2006年11月、<http：// www。 rfc-editor.org/info/rfc4726>。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <http://www.rfc-editor.org/info/rfc4873>.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「GMPLS Segment Recovery」、RFC 4873、DOI 10.17487 / RFC4873、2007年5月、<http：//www.rfc-editor .org / info / rfc4873>。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, April 2007, <http://www.rfc-editor.org/info/rfc4874>.
[RFC4874] Lee、CY。、Farrel、A。、およびS. De Cnodder、「Exclude Routes-Extension to Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）」、RFC 4874、DOI 10.17487 / RFC4874、2007年4月、< http://www.rfc-editor.org/info/rfc4874>。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>.
[RFC5152] Vasseur、JP。、編、Ayyangar、A。、編、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、 RFC 5152、DOI 10.17487 / RFC5152、2008年2月、<http://www.rfc-editor.org/info/rfc5152>。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009, <http://www.rfc-editor.org/info/rfc5520>.
[RFC5520] Bradford、R。、編、Vasseur、JP、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算におけるトポロジー機密性の保持」、RFC 5520、DOI 10.17487 / RFC5520、4月2009、<http://www.rfc-editor.org/info/rfc5520>。
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, <http://www.rfc-editor.org/info/rfc5886>.
[RFC5886] Vasseur、JP。、Ed。、Le Roux、JL。、and Y. Ikejiri、 "A Set Monitoring Tools for Path Computation Element（PCE）-Based Architecture"、RFC 5886、DOI 10.17487 / RFC5886、June 2010 、<http://www.rfc-editor.org/info/rfc5886>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<http://www.rfc-editor.org/info / rfc5925>。
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.
[RFC6793] Vohra、Q。およびE. Chen、「BGP Support for Four-Octet Autonomous System（AS）Number Space」、RFC 6793、DOI 10.17487 / RFC6793、2012年12月、<http：//www.rfc-editor。 org / info / rfc6793>。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドによるBGP、LDP、PCEP、およびMSDPの問題の分析」、RFC 6952、DOI 10.17487 / RFC6952、2013年5月、<http://www.rfc-editor.org/info/rfc6952>。
[RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, "PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths", RFC 7334, DOI 10.17487/RFC7334, August 2014, <http://www.rfc-editor.org/info/rfc7334>.
[RFC7334] Zhao、Q.、Dhody、D.、King、D.、Ali、Z。、およびR. Casellas、「最短の制約付きポイントツーマルチポイント（P2MP）ドメイン間トラフィックを計算するためのPCEベースの計算手順Engineering Label Switched Paths」、RFC 7334、DOI 10.17487 / RFC7334、2014年8月、<http://www.rfc-editor.org/info/rfc7334>。
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <http://www.rfc-editor.org/info/rfc7420>.
[RFC7420] Koushik、A.、Stephan、E.、Zhao、Q.、King、D。、およびJ. Hardwick、「Path Computation Element Communication Protocol（PCEP）Management Information Base（MIB）Module」、RFC 7420、DOI 10.17487 / RFC7420、2014年12月、<http://www.rfc-editor.org/info/rfc7420>。
Acknowledgments
謝辞
The authors would like to especially thank Adrian Farrel for his detailed reviews as well as providing text to be included in the document.
著者は、彼の詳細なレビューとドキュメントに含まれるテキストを提供してくれたAdrian Farrelに特に感謝します。
Further, we would like to thank Pradeep Shastry, Suresh Babu, Quintin Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika Sergio Belotti, and Jonathan Hardwick for their useful comments and suggestions.
さらに、プラディープシャストリー、スレシュバブ、クインティンチャオ、ファタイチャン、ダニエルキング、オスカーゴンザレス、チェンファイモ、ヴェヌゴパールレディ、リージャポール、サンディープボイナ、アヴァンティカセルジオベロッティ、ジョナサンハードウィックの有益なコメントと提案に感謝します。 。
Thanks to Jonathan Hardwick for shepherding this document.
このドキュメントを作成してくれたJonathan Hardwickに感謝します。
Thanks to Deborah Brungard for being the responsible AD.
責任あるADであるDeborah Brungardに感謝します。
Thanks to Amanda Baber for the IANA review.
IANAレビューを提供してくれたAmanda Baberに感謝します。
Thanks to Joel Halpern for the Gen-ART review.
Gen-ARTレビューのJoel Halpernに感謝します。
Thanks to Klaas Wierenga for the SecDir review.
SecDirレビューをありがとうKlaas Wierengaに感謝します。
Thanks to Spencer Dawkins and Barry Leiba for comments during the IESG review.
IESGレビュー中のコメントについて、Spencer DawkinsとBarry Leibaに感謝します。
Authors' Addresses
著者のアドレス
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Dhruv Dhodai Huawei Technologies Divyashari Techno Park、Wheatfished Bangalore、Karnataka 2008インド
Email: dhruv.ietf@gmail.com
Udayasree Palle Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Udayasari Palle Huawei Technologies Divyashree Techno Park、Whitfield Bangalore、Karnataka 560066 India
Email: udayasree.palle@huawei.com
Ramon Casellas CTTC Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain
ラモンカセラスCTTC Av。カールフリードリヒガウスn7カステルデフェルス、バルセロナ08860スペイン
Email: ramon.casellas@cttc.es