[要約] RFC 5553は、Path KeyサポートのためのRSVP拡張に関する規格です。その目的は、ネットワークリソースの予約と制御を改善し、パスキーを使用してトラフィックを識別することです。
Network Working Group A. Farrel, Ed.
Request for Comments: 5553 Old Dog Consulting
Category: Standards Track R. Bradford
JP. Vasseur
Cisco Systems, Inc.
May 2009
Resource Reservation Protocol (RSVP) Extensions for Path Key Support
PATHキーサポート用のリソース予約プロトコル（RSVP）拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path.
マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）トラフィックエンジニアリング（TE）ラベルスイッチされたパス（LSP）によって採用されるパスは、パス計算要素（PCES）によって計算される場合があります。TE LSPが自律システム（ASES）などの複数のドメインを通過する場合、パスは、それぞれがパスのセグメントを計算する責任を負う複数のPCEによって計算されます。
To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation.
それぞれのAS内のトポロジーの機密性を維持するために、PCESは、パスのセグメントの内容（ASを横断するパスのセグメントなど）を隠すメカニズムをサポートし、機密パスセグメント（CPS）と呼ばれ、パスキーサブオブジェクト（PK）としての内容と、そのパス計算の結果にこのサブオブジェクトを埋め込みます。
This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs.
このドキュメントでは、ドメイン間TE LSPの信号の機密性を促進するために、リソース予約プロトコル（RSVP）明示的ルートオブジェクト（EROS）およびレコードルートオブジェクト（RRO）にPATHキーサブオブジェクトを運ぶ方法について説明します。
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) are signaled using the TE extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209], [RFC3473]. The routes followed by MPLS and GMPLS TE LSPs may be computed by Path Computation Elements (PCEs) [RFC4655].
マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）トラフィックエンジニアリング（TE）ラベルスイッチ付きパス（LSP）は、TE拡張機能を使用してリソース予約プロトコル（RSVP-TE）[RFC3209]、[RFC3473]を使用してシグナル伝達されます。それに続くMPLSおよびGMPLS TE LSPが続くルートは、パス計算要素（PCES）[RFC4655]によって計算される場合があります。
Where the TE LSP crosses multiple domains [RFC4726], such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology with each AS, the PCE Communications Protocol (PCEP) [RFC5440] supports a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) [RFC5520].
TE LSPが自律システム（ASES）などの複数のドメイン[RFC4726]を通過する場合、パスはそれぞれがパスのセグメントを計算する責任を負う複数のPCEによって計算されます。ASごとにトポロジの機密性を維持するために、PCE通信プロトコル（PCEP）[RFC5440]は、パスキーとして内容をエンコードすることにより、機密パスセグメント（CPS）と呼ばれるパスセグメント（CPS）と呼ばれるパスのセグメントの内容を隠すメカニズムをサポートします。Subobject（PKS）[RFC5520]。
This document defines RSVP-TE protocol extensions necessary to support the use of Path Key Subobjects in MPLS and GMPLS signaling by including them in Explicit Route Objects (EROs) and Record Route Object (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs.
このドキュメントでは、明示的なルートオブジェクト（EROS）およびレコードルートオブジェクト（RROS）にそれらを含めることにより、MPLSおよびGMPLSシグナル伝達のパスキーサブオブジェクトの使用をサポートするために必要なRSVP-TEプロトコル拡張を定義して、相互の信号の信号を促進するためにドメインte lsps。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Figure 1 shows a simple network constructed of two ASes. An LSP is desired from the ingress in AS-1 to the egress in AS-2. As described in [RFC4655], the ingress Label Switching Router (LSR) acts as a Path Computation Client (PCC) and sends a request to its PCE (PCE-1). PCE-1 can compute the path within AS-1 but has no visibility into AS-2. So PCE-1 cooperates with PCE-2 to complete the path computation.
図1は、2つのASEで構成された単純なネットワークを示しています。LSPは、AS-1の侵入からAS-2の出口に希望されます。[RFC4655]で説明されているように、イングレスラベルスイッチングルーター（LSR）はパス計算クライアント（PCC）として機能し、PCE（PCE-1）にリクエストを送信します。PCE-1はAS-1内のパスを計算できますが、AS-2には可視性がありません。したがって、PCE-1はPCE-2と協力してパス計算を完了します。
However, PCE-2 does not want to share the information about the path across AS-2 with nodes outside the AS. So, as described in [RFC5520], PCE-2 reports the AS-2 path segment using a PKS rather than the explicit details of the path.
ただし、PCE-2は、AS-A-2のパスに関する情報をASの外側のノードと共有したくありません。したがって、[RFC5520]で説明されているように、PCE-2は、パスの明示的な詳細ではなくPKSを使用してAS-2パスセグメントを報告します。
PCE-1 can now return the path to be signaled to the ingress LSR in a path computation response with the AS-2 segment still hidden as a PKS.
PCE-1は、PKSとしてまだ隠されているAS-2セグメントを使用して、パス計算応答でIngress LSRに信号を受けるパスを戻すことができます。
In order to set up the LSP, the ingress LSR signals using RSVP-TE and encodes the path reported by PCE-1 in the Explicit Route Object (ERO). This process is as normal for RSVP-TE but requires that the PKS is also included in the ERO, using the mechanisms defined in this document.
LSPをセットアップするために、RSVP-TEを使用してIngress LSR信号を設定し、明示的ルートオブジェクト（ERO）でPCE-1によって報告されたパスをエンコードします。このプロセスはRSVP-TEの場合も通常もありますが、このドキュメントで定義されているメカニズムを使用して、PKもEROに含まれる必要があります。
When the signaling message (the RSVP-TE Path message) reaches ASBR-2 (Autonomous System Border Router), it consults PCE-2 to 'decode' the PKS and return the expanded explicit path segment to ASBR-2. (The information that PCE-2 uses to decode the PKS is encoded within the PKS itself.) The PKS is replaced in the ERO with the expanded information about the path.
信号メッセージ（RSVP-TEパスメッセージ）がASBR-2（自律システムの境界ルーター）に到達すると、PCE-2を参照してPKSを「デコード」し、拡張された明示的なパスセグメントをASBR-2に戻します。（PCE-2がPKSをデコードするために使用する情報は、PKS自体内でエンコードされます。）PKSは、EROでパスに関する拡張情報に置き換えられます。
----------------------------- ----------------------------
| AS-1 | | AS-2 |
| | | |
| ------- | | ------- |
| | PCE-1 |<---------------+--+-->| PCE-2 | |
| ------- | | ------- |
| ^ | | ^ |
| | | | | |
| v | | v |
| ------- ---- | | ---- |
| | PCC | - - |ASBR| | | |ASBR| - - ------ |
| |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| |
| ------- - - ----- | | ---- - - ------ |
| | | |
----------------------------- ----------------------------
Figure 1: A Simple Network to Demonstrate the Use of the PKS
図1：PKの使用を示す簡単なネットワーク
Note that PCE-2 may in some case be co-located with ASBR-2.
PCE-2は、場合によってはASBR-2と協調している可能性があることに注意してください。
CPS: Confidential Path Segment. A segment of a path that contains nodes and links that the AS policy requires to not be disclosed outside the AS.
CPS：機密パスセグメント。ASポリシーがASの外側に開示されないことを要求するノードとリンクを含むパスのセグメント。
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：パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
PKS: Path Key Subobject. A subobject of an Explicit Route Object that encodes a CPS so as to preserve confidentiality.
PKS：PATHキーサブオブジェクト。機密性を維持するためにCPSをコードする明示的なルートオブジェクトのサブオブジェクト。
The Path Key Subobject (PKS) may be carried in the Explicit Route Object (ERO) of an RSVP-TE Path message [RFC3209]. The PKS is a fixed-length subobject containing a Path Key and a PCE-ID. The Path Key is an identifier or token used to represent the CPS within the context of the PCE identified by the PCE-ID. The PCE-ID identifies the PCE that can decode the Path Key using a reachable IPv4 or IPv6 address of the PCE. In most cases, the decoding PCE is also the PCE that computed the Path Key and the associated path. Because of the IPv4 and IPv6 variants, two subobjects are defined as follows.
PATHキーサブオブジェクト（PKS）は、RSVP-TEパスメッセージ[RFC3209]の明示的なルートオブジェクト（ERO）に運ばれる場合があります。PKSは、パスキーとPCE-IDを含む固定長のサブオブジェクトです。パスキーは、PCE-IDによって識別されたPCEのコンテキスト内でCPSを表すために使用される識別子またはトークンです。PCE-IDは、PCEの到達可能なIPv4またはIPv6アドレスを使用してパスキーをデコードできるPCEを識別します。ほとんどの場合、デコードPCEは、パスキーと関連するパスを計算したPCEでもあります。IPv4およびIPv6バリアントのため、2つのサブオブジェクトが次のように定義されています。
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 | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE-ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RSVP-TE Path Key Subobject using an IPv4 address for the PCE-ID
図2：PCE-IDのIPv4アドレスを使用したRSVP-TEパスキーサブオブジェクト
L
l
The L bit SHOULD NOT be set, so that the subobject represents a strict hop in the explicit route.
Subobjectが明示的なルートでの厳格なホップを表すように、Lビットを設定しないでください。
Type
タイプ
Subobject Type for a Path Key with a 32-bit PCE-ID as assigned by IANA.
IANAによって割り当てられた32ビットPCE-IDを備えたパスキーのサブオブジェクトタイプ。
Length
長さ
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8.
長さには、タイプと長さのフィールドを含む、バイト内のサブオブジェクトの全長が含まれます。長さは常に8です。
PCE-ID
pce-id
A 32-bit identifier of the PCE that can decode this key. The identifier MUST be unique within the scope of the domain that the CPS crosses and MUST be understood by the LSR that will act as PCC for the expansion of the PKS. The interpretation of the PCE-ID is subject to domain-local policy. It MAY be an IPv4 address of the PCE that is always reachable and MAY be an address that is restricted to the domain in which the LSR that is called upon to expand the CPS lies. Other values that have no meaning outside the domain (for example, the Router ID of the PCE) MAY be used to increase security or confidentiality.
このキーをデコードできるPCEの32ビット識別子。識別子は、CPSが交差するドメインの範囲内で一意でなければならず、PKの拡張のためにPCCとして機能するLSRによって理解されなければなりません。PCE-IDの解釈は、ドメインローカルポリシーの対象となります。これは、常に到達可能なPCEのIPv4アドレスである可能性があり、CPSを拡張するために呼び出されるLSRが存在するドメインに制限されているアドレスである可能性があります。ドメインの外側に意味がない他の値（たとえば、PCEのルーターID）を使用して、セキュリティまたは機密性を高めることができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE-ID (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RSVP-TE Path Key Subobject using an IPv6 address for the PCE-ID
図3：PCE-IDのIPv6アドレスを使用したRSVP-TEパスキーサブオブジェクト
L
l
As above.
上記のように。
Type
タイプ
Subobject Type for a Path Key with a 128-bit PCE-ID as assigned by IANA.
IANAによって割り当てられた128ビットPCE-IDを備えたパスキーのサブオブジェクトタイプ。
Length
長さ
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 20.
長さには、タイプと長さのフィールドを含む、バイト内のサブオブジェクトの全長が含まれます。長さは常に20です。
PCE-ID
pce-id
A 128-bit identifier of the PCE that can decode this key. The identifier MUST be unique within the scope of the domain that the CPS crosses and MUST be understood by the LSR that will act as PCC for the expansion of the PKS. The interpretation of the PCE-ID is subject to domain-local policy. It MAY be an IPv6 address of the PCE that is always reachable, and MAY be an address that is restricted to the domain in which the LSR that is called upon to expand the CPS lies. Other values that have no meaning outside the domain (for example, the IPv6 TE Router ID) MAY be used to increase security (see Section 4).
このキーをデコードできるPCEの128ビット識別子。識別子は、CPSが交差するドメインの範囲内で一意でなければならず、PKの拡張のためにPCCとして機能するLSRによって理解されなければなりません。PCE-IDの解釈は、ドメインローカルポリシーの対象となります。これは、常に到達可能なPCEのIPv6アドレスであり、CPSを拡張するために呼び出されるLSRが存在するドメインに制限されているアドレスである可能性があります。ドメインの外側に意味がない他の値（たとえば、IPv6 TEルーターID）を使用してセキュリティを増やすことができます（セクション4を参照）。
Note: The twins of these subobjects are carried in PCEP messages as defined in [RFC5520].
注：これらのサブオブジェクトの双子は、[RFC5520]で定義されているように、PCEPメッセージで運ばれます。
The basic processing rules of an ERO are not altered. Refer to [RFC3209] for details. In particular, an LSR is not required to "look ahead" in the ERO beyond the first subobject that is non-local.
EROの基本的な処理ルールは変更されません。詳細については、[RFC3209]を参照してください。特に、LSRは、非ローカルである最初のサブオブジェクトを超えてEROを「先に見」する必要はありません。
[RFC5520] requires that any path fragment generated by a PCE that contains a PKS be such that the PKS is immediately preceded by a subobject that identifies the head end of the PKS (for example, an incoming interface or a node ID). This rule is extended to the PKS in the ERO so that the following rules are defined.
[RFC5520] PKSを含むPCEによって生成されるパスフラグメントは、PKSの先端がすぐにPKSのヘッドエンドを識別するサブオブジェクト（たとえば、着信インターフェイスまたはノードID）が識別することを要求しています。このルールは、次のルールが定義されるように、EROのPKSに拡張されます。
- If an LSR receives a Path message where the first subobject of the ERO is a PKS, it MUST respond with a PathErr message carrying the error code/value combination "Routing Problem" / "Bad initial subobject".
- LSRがEROの最初のサブオブジェクトがPKSであるパスメッセージを受信する場合、エラーコード /値の組み合わせ「ルーティング問題」 /「悪い初期サブオブジェクト」を運ぶPatherメッセージで応答する必要があります。
- If an LSR strips all local subobjects from an ERO carried in a Path message (according to the procedures in [RFC3209]) and finds that the next subobject is a PKS, it MUST attempt to resolve the PKS to a CPS.
- LSRがパスメッセージ（[RFC3209]の手順に従って）に運ばれたEROからすべてのローカルサブオブジェクトをストリップし、次のサブオブジェクトがPKSであることを発見した場合、PKSをCPSに解決しようとする必要があります。
Resolution of the PKS MAY take any of the following forms or use some other technique subject to local policy and network implementation.
PKSの解決は、以下のフォームのいずれかをとるか、ローカルポリシーとネットワークの実装に従って他の手法を使用する場合があります。
o The LSR can use the PCE-ID contained in the PKS to contact the identified PCE using PCEP [RFC5440] and request that the PKS be expanded.
o LSRは、PKSに含まれるPCE-IDを使用して、PCEP [RFC5440]を使用して特定されたPCEに接触し、PKを拡張するように要求できます。
o The LSR can contact any PCE using PCEP [RFC5440] to request that the PKS be expanded, relying on cooperation between the PCEs.
o LSRは、PCEP [RFC5440]を使用してPCEを使用して任意のPCEに連絡して、PCS間の協力に依存してPKを拡張することを要求できます。
o The LSR can use the information in the PKS to index a CPS previously supplied to it by the PCE that originated the PKS.
o LSRは、PKSの情報を使用して、PKSを発信したPCEが以前に提供したCPSをインデックス化することができます。
If a CPS is derived, the path fragment SHOULD be inserted into the ERO of the Path message as a direct replacement for the PKS. Other processing of the CPS and ERO are permitted as described in [RFC3209].
CPSが導出される場合、PKSの直接置換としてパスメッセージのEROにパスフラグメントを挿入する必要があります。[RFC3209]に記載されているように、CPSおよびEROのその他の処理が許可されています。
This processing can give rise to the following error cases:
この処理は、次のエラーケースを引き起こす可能性があります。
o PCE-ID cannot be matched to a PCE to decode the PKS.
o PCE-IDをPCEに一致させることはできません。
The LSR sends a PathErr message with the error code "Routing Problem" and the new error value "Unknown PCE-ID for PKS expansion" (see Section 6.3).
LSRは、エラーコード「ルーティング問題」と新しいエラー値「PKS拡張用の不明なPCE-ID」を含むPatherRメッセージを送信します（セクション6.3を参照）。
o PCE identified by the PCE-ID cannot be reached.
o PCE-IDによって識別されるPCEに到達することはできません。
The LSR sends a PathErr message with the error code "Routing Problem" and the new error value "Unreachable PCE for PKS expansion" (see Section 6.3).
LSRは、エラーコード「ルーティング問題」と新しいエラー値「PKS拡張のための到達不可能なPCE」を含むPatherRメッセージを送信します（セクション6.3を参照）。
o The PCE is unable to decode the PKS, perhaps because the Path Key has expired.
o おそらくパスキーが期限切れになったため、PCEはPKSをデコードできません。
The LSR sends a PathErr message with the error code "Routing Problem" and the new error value "Unknown Path Key for PKS expansion" (see Section 6.3).
LSRは、エラーコード「ルーティング問題」と新しいエラー値「PKS拡張の不明なパスキー」を含むPatherRメッセージを送信します（セクション6.3を参照）。
o PKS cannot be decoded for policy reasons.
o PKSは、政策上の理由でデコードすることはできません。
The LSR sends a PathErr message with the error code "Policy Control Failure" and the error value "Inter-domain policy failure".
LSRは、エラーコード「ポリシー制御障害」とエラー値「ドメイン間ポリシーの障害」を含むPatherrメッセージを送信します。
o Addition of CPS to ERO causes Path message to become too large.
o EROにCPSを追加すると、パスメッセージが大きくなりすぎます。
The LSR MAY replace part of the ERO with loose hops [RFC3209] or with a further PKS, according to local policy, if the loss of specifics within the explicit path is acceptable. If the LSR is unable to take steps to reduce the size of the ERO, it MUST send a PathErr message with the error code "Routing Problem" and the new error value "ERO too large for MTU" (see Section 6.3).
LSRは、EROの一部を、明示的なパス内での詳細の損失が許容できる場合、ローカルポリシーに従って、ゆるいホップ[RFC3209]またはさらなるPKに置き換えることができます。LSRがEROのサイズを減らすための手順を実行できない場合、エラーコード「ルーティング問題」と新しいエラー値「EROがMTUには大きすぎる」を使用してPatherRメッセージを送信する必要があります（セクション6.3を参照）。
- An LSR that is called on to process a PKS within an ERO but that does not recognize the subobject, will react according to [RFC3209] and send a PathErr message with the error code/value combination "Routing Problem" / "Bad Explicit Route Object".
- ERO内のPKSを処理するために呼び出されるが、サブオブジェクトを認識しないLSRは[RFC3209]に従って反応し、エラーコード /値の組み合わせ「ルーティング問題」 /「悪い明示的ルートオブジェクトを含むPatherRメッセージを送信します「。
The Record Route Object (RRO) is used in RSVP-TE to record the route traversed by an LSP. The RRO may be present on a Path message and on a Resv message. The intention of [RFC3209] is that an RRO on a Resv message that is received by an ingress LSR is suitable for use as an ERO on a Path message sent by that LSR to achieve an identical LSP.
レコードルートオブジェクト（RRO）は、rsvp-teで使用され、LSPによって横断されるルートを記録します。RROは、パスメッセージとRESVメッセージに存在する場合があります。[RFC3209]の意図は、Ingress LSRによって受信されるRESVメッセージのRROが、同一のLSPを達成するためにそのLSRによって送信されたパスメッセージのEROとして使用するのに適していることです。
The PKS offers an alternative that can be more useful to diagnostics. When the signaling message crosses a domain boundary, the path segment that needs to be hidden (that is, a CPS) MAY be replaced in the RRO with a PKS. In the case of an RRO on a Resv message, the PKS used SHOULD be the one originally signaled in the ERO of the Path message. On a Path message, the PKS SHOULD identify the LSR replacing the CPS and provide a Path Key that can be used to expand the path segment. In the latter case, the Path Key and its expansion SHOULD be retained by the LSR that performs the substitution for at least the lifetime of the LSP. In both cases, the expansion of the PKS SHOULD be made available to diagnostic tools under the control of local policy.
PKSには、診断により便利な代替手段があります。信号メッセージがドメインの境界を越えると、非表示（つまり、CPS）を非表示にする必要があるパスセグメントがPKSで置き換えることができます。RESVメッセージのRROの場合、使用されるPKSは、パスメッセージのEROで元々通知されたものである必要があります。パスメッセージでは、PKSはCPSを置き換えるLSRを識別し、パスセグメントを拡張するために使用できるパスキーを提供する必要があります。後者の場合、PATHキーとその拡張は、少なくともLSPの寿命のために置換を実行するLSRによって保持されるべきです。どちらの場合も、ローカルポリシーの管理下にある診断ツールがPKSの拡張を利用できるようにする必要があります。
The protocol interactions required by the mechanisms described in this document are point-to-point and can be authenticated and made secure as described in [RFC5440] and [RFC3209]. The protocol interactions for PCEP are listed in [RFC5520], while general considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can be found in [MPLS-SEC].
このドキュメントで説明されているメカニズムで必要なプロトコルの相互作用は、ポイントツーポイントであり、[RFC5440]および[RFC3209]で説明されているように認証および安全にすることができます。PCEPのプロトコル相互作用は[RFC5520]にリストされていますが、MPLS-TEおよびGMPLSネットワークでRSVP-TEを保護するための一般的な考慮事項は[MPLS-SEC]にあります。
Thus, security issues can be dealt with using standard techniques for securing and authenticating point-to-point communications. In addition, it is RECOMMENDED that the PCE providing a PKS expansion check that the LSR that issued the request for PKS expansion is the head end of the resulting CPS.
したがって、セキュリティの問題は、ポイントツーポイント通信を確保および認証するための標準的な手法を使用することに対処できます。さらに、PKS拡張のリクエストを発行したLSRが結果のCPSのヘッドエンドであることをPKS拡張チェックを提供するPCEが推奨されます。
Further protection can be provided by using a PCE-ID to identify the decoding PCE that is only meaningful within the domain that contains the LSR at the head of the CPS. This may be either an IP address that is only reachable from within the domain or some non-address value. The former requires configuration of policy on the PCEs; the latter requires domain-wide policy.
PCE-IDを使用して、CPSのヘッドにLSRを含むドメイン内でのみ意味のあるデコードPCEを識別することにより、さらなる保護を提供できます。これは、ドメイン内からのみ到達可能なIPアドレスまたは非アドレス値のいずれかです。前者は、PCES上のポリシーの構成を必要とします。後者にはドメイン全体のポリシーが必要です。
The following specific security issues need to be considered.
以下の特定のセキュリティの問題を考慮する必要があります。
- Confidentiality of the CPS. The question to be answered is whether other network elements can probe a PCE for the expansion of PKSs, possibly generating Path Keys at random. This can be protected against by only allowing PKS expansion to be successfully completed if requested by the LSR that is at the head end of the resulting CPS. Under specific circumstances, PKS expansion might also be allowed by configured management stations.
- CPSの機密性。回答すべき問題は、他のネットワーク要素がPKSの拡張のためのPCEを調べることができ、おそらくパスキーをランダムに生成できるかどうかです。これは、結果のCPSのヘッドエンドにあるLSRから要求された場合にのみPKS拡張を正常に完了できるようにすることで保護できます。特定の状況では、PKS拡張は構成された管理ステーションによっても許可される場合があります。
The CPS itself may be kept confidential as it is exchanged in the PCEP and RSVP-TE protocols using standard security mechanisms defined for those protocols.
CPS自体は、PCEPおよびRSVP-TEプロトコルで交換されているため、これらのプロトコルに対して定義された標準セキュリティメカニズムを使用して機密に保つことができます。
- Determination of information by probing. In addition to the probing described above, a node might deduce information from the error responses that are generated when PKS expansion fails as described in Section 3.1. Any LSR that determines that supplying one of the detailed error codes described in Section 3.1 might provide too much information that could be used as part of a systematic attack MAY simply use the error code/value "Policy Control Failure" / "Inter-domain policy failure" in all cases.
- 調査による情報の決定。上記の調査に加えて、ノードは、セクション3.1で説明されているように、PKS拡張が失敗したときに生成されるエラー応答から情報を推定する場合があります。セクション3.1で説明されている詳細なエラーコードの1つを提供することを決定するLSRは、系統的攻撃の一部として使用できる情報が多すぎる可能性があると判断します。すべての場合において失敗」。
- Authenticity of the Path Key. A concern is that the Path Key in the PKS will be altered or faked, leading to erroneous Path Key expansion and use of the wrong CPS. The consequence would be a bad ERO in a Path message, causing the LSP to be set up incorrectly and resulting in incorrect network resource usage, diversion of traffic to where it can be intercepted, or failure to set up the LSP. These problems can be prevented by protecting the protocol exchanges in PCEP and RSVP-TE using the security techniques described in [RFC5440], [RFC3209], and [MPLS-SEC].
- パスキーの信頼性。懸念は、PKSのパスキーが変更または偽造され、誤ったパスキーの拡張と間違ったCPSの使用につながることです。結果は、パスメッセージの悪いEROであり、LSPを誤ってセットアップし、ネットワークリソースの使用、傍受できる場所へのトラフィックの転換、またはLSPのセットアップの失敗をもたらします。これらの問題は、[RFC5440]、[RFC3209]、および[MPLS-SEC]に記載されているセキュリティ手法を使用して、PCEPおよびRSVP-TEのプロトコル交換を保護することで防ぐことができます。
- Resilience to denial-of-service (DoS) attacks. A PCE can be attacked through a flood of Path Key expansion requests -- this issue is addressed in [RFC5520] and is out of scope for this document. A further attack might consist of sending a flood of RSVP-TE Path messages with deliberately spurious PKSs. This attack is prevented by ensuring the integrity of the Path messages using standard RSVP-TE security mechanisms and by enforcing the RSVP-TE chain-of-trust security model.
- サービス拒否（DOS）攻撃への回復力。PATHキー拡張要求のフラッシュでPCEを攻撃することができます。この問題は[RFC5520]で対処されており、このドキュメントの範囲外です。さらなる攻撃は、意図的に偽のPKSを使用してRSVP-TEパスメッセージの洪水を送信することで構成されている可能性があります。この攻撃は、標準のRSVP-TEセキュリティメカニズムを使用してパスメッセージの整合性を確保し、RSVP-TEチェーンオブトラストセキュリティモデルを実施することにより、防止されます。
Policy forms an important part of the use of PKSs in EROs and RROs. There are local and domain-wide policies that SHOULD be available for configuration in an implementation.
ポリシーは、EROSおよびRROSでのPKSの使用の重要な部分を形成します。実装で構成に利用できるはずのローカルおよびドメイン全体のポリシーがあります。
- Handling of an ERO containing a PKS. As described in Section 3.1, an LSR that receives a Path message containing a PKS can be configured to reject the Path message according to policy.
- PKを含むEROの取り扱い。セクション3.1で説明したように、PKSを含むパスメッセージを受信するLSRは、ポリシーに従ってパスメッセージを拒否するように構成できます。
- Handling of PKS requests at a PCE. As described in Section 3.1, in [RFC5520], and in [RFC5394], a PCE can be configured with policy regarding how it should handle requests for PKS expansion.
- PCSでのPKSリクエストの処理。セクション3.1、[RFC5520]、および[RFC5394]で説明されているように、PCS拡張の要求を処理する方法に関するポリシーでPCEを設定できます。
- PKS expansion. Section 3.1 explains that the PKS can be expanded by the local LSR, the specific PCE identified in the PKS, any PCE acting as a proxy, or by some other method. The behavior of the LSR needs to be locally configurable but is subject to the domain-wide policy.
- PKS拡張。セクション3.1は、PKSをローカルLSR、PKで特定した特定のPCE、プロキシとして機能するPCE、または他の方法によって拡張できることを説明しています。LSRの動作はローカルで構成可能である必要がありますが、ドメイン全体のポリシーの対象となります。
- Interpretation of PCE-ID. The interpretation of the PCE-ID component of PKSs is subject to domain-local policy and needs to be configurable as such. See Section 3 and Section 4 for the options.
- PCE-IDの解釈。PKSSのPCE-IDコンポーネントの解釈は、ドメインローカルポリシーの対象であり、そのように設定可能である必要があります。オプションについては、セクション3とセクション4を参照してください。
- ERO too large. The behavior of an LSR when it finds that adding a CPS to the ERO causes the Path message to be too large is an implementation choice. However, implementations may choose to provide configuration of behavior as described in Section 3.1.
- エロが大きすぎる。EROにCPSを追加すると、パスメッセージが大きすぎると実装の選択肢があることがわかった場合のLSRの動作は実装の選択です。ただし、実装は、セクション3.1で説明されているように、動作の構成を提供することを選択する場合があります。
- Masking of RRO. As described in Section 3.2, a border router can choose to mask segments of the path by replacing them with PKSs. This behavior needs to be configurable, with the default being to not hide any part of the RRO.
- RROのマスキング。セクション3.2で説明されているように、Border RouterはPKSSに置き換えることにより、パスのセグメントをマスクすることを選択できます。この動作は設定可能である必要があり、デフォルトではRROの一部を非表示にしないようにします。
- Inspection / decoding of PKS by diagnostic tools. A PCE can allow access from management or diagnostic tools to request the expansion of a PKS. Note that this must be regulated with the security and confidentiality behavior described in Section 4.
- 診断ツールによるPKの検査 /デコード。PCEは、管理や診断ツールからのアクセスを可能にして、PKの拡張を要求します。これは、セクション4で説明されているセキュリティおよび機密性の行動で規制する必要があることに注意してください。
- Hiding of reason codes. An LSR can support the configuration of local policy to hide reason codes associated with the failure to expand a PKS and, as described in Section 4, report all errors as policy failures.
- 理性コードの隠蔽。LSRは、ローカルポリシーの構成をサポートして、PKSの拡張の失敗に関連する理由コードを非表示にし、セクション4で説明したように、すべてのエラーをポリシーの障害として報告します。
The treatment of a path segment as a CPS, and its substitution in a PCRep ERO with a PKS, is a PCE function and is described in [RFC5520].
CPSとしてのパスセグメントの処理と、PKSを使用したPCREP EROでのその置換はPCE関数であり、[RFC5520]で説明されています。
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Class Names, Class Numbers, and Class Types".
IANAは、「クラス名、クラス番号、クラスタイプ」と呼ばれるサブレジストリを使用して、「リソース予約プロトコル（RSVP）パラメーター」と呼ばれるレジストリを維持しています。
Within this subregistry, there is a definition of the EXPLICIT_ROUTE object with Class Number 20. The object definition lists a number of acceptable subobjects for the Class Type 1.
このサブレジストリ内には、クラス番号20を持つliblicit_routeオブジェクトの定義があります。オブジェクト定義には、クラスタイプ1の許容可能なサブオブジェクトが多数リストされています。
IANA has allocated two further subobjects as described in Section 3. The resulting entry in the registry is as follows.
IANAは、セクション3で説明されているように、さらに2つのサブオブジェクトを割り当てました。レジストリへの結果のエントリは次のとおりです。
20 EXPLICIT_ROUTE [RFC3209]
Class Types or C-Types:
1 Type 1 Explicit Route [RFC3209]
Subobject type
64 Path Key with 32-bit PCE-ID [RFC5553]
65 Path Key with 128-bit PCE-ID [RFC5553]
Note well: [RFC5520] defines the PKS for use in PCEP. IANA has assigned the same subobject numbers for use in RSVP-TE as are assigned for the PKS in PCEP. The numbers above are the same as in [RFC5520].
注意事項：[RFC5520] PCEPで使用するPKを定義します。IANAは、PCEPのPKに割り当てられているRSVP-TEで使用するために同じサブオブジェクト番号を割り当てています。上記の数字は[RFC5520]と同じです。
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Class Names, Class Numbers, and Class Types".
IANAは、「クラス名、クラス番号、クラスタイプ」と呼ばれるサブレジストリを使用して、「リソース予約プロトコル（RSVP）パラメーター」と呼ばれるレジストリを維持しています。
Within this subregistry, there is a definition of the ROUTE_RECORD object (also known as the RECORD_ROUTE object) with Class Number 21. The object definition lists a number of acceptable subobjects for the Class Type 1.
このサブレジストリ内には、クラス番号21を持つroute_recordオブジェクト（record_routeオブジェクトとも呼ばれます）の定義があります。オブジェクト定義には、クラスタイプ1の許容可能なサブオブジェクトが多数リストされています。
IANA has allocated two further subobjects as described in Section 3. The resulting entry in the registry is as follows.
IANAは、セクション3で説明されているように、さらに2つのサブオブジェクトを割り当てました。レジストリへの結果のエントリは次のとおりです。
21 ROUTE_RECORD [RFC3209]
(also known as RECORD_ROUTE)
Class Types or C-Types:
1 Type 1 Route Record [RFC3209]
Subobject type
64 Path Key with 32-bit PCE-ID [RFC5553]
65 Path Key with 128-bit PCE-ID [RFC5553]
Note well: IANA is requested to use the same subobject numbers as are defined for the EXPLICIT_ROUTE object in Section 6.1.
注意よく：IANAは、セクション6.1のexpricit_routeオブジェクトに対して定義されているのと同じサブオブジェクト番号を使用するように要求されます。
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes".
IANAは、「エラーコードとグローバルに定義されたエラー値サブコード」と呼ばれるサブレジストリを使用して、「リソース予約プロトコル（RSVP）パラメーター」と呼ばれるレジストリを維持しています。
Within this subregistry, there is a definition of the "Routing Problem" error code with error code value 24. The definition lists a number of error values that may be used with this error code.
このサブレジストリ内には、エラーコード値24を持つ「ルーティング問題」エラーコードの定義があります。定義には、このエラーコードで使用できるエラー値の多くがリストされています。
IANA has allocated further error values for use with this error code as described in Section 3.1. The resulting entry in the registry is as follows.
IANAは、セクション3.1で説明されているように、このエラーコードで使用するためのさらなるエラー値を割り当てました。結果のレジストリ内のエントリは次のとおりです。
24 Routing Problem [RFC3209]
24ルーティングの問題[RFC3209]
This Error Code has the following globally defined Error Value sub-codes:
このエラーコードには、次のグローバルに定義されたエラー値サブコードがあります。
31 = Unknown PCE-ID for PKS expansion [RFC5553]
32 = Unreachable PCE for PKS expansion [RFC5553]
33 = Unknown Path Key for PKS expansion [RFC5553]
34 = ERO too large for MTU [RFC5553]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、2006年11月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「ポリシー対応パス計算フレームワーク」、RFC 5394、2008年12月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、Jp。、ed。、およびJl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、2009年3月。
[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, April 2009.
[RFC5520] Bradford、R.、ed。、vasseur、Jp。、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算のトポロジの機密性を保存」、RFC 5520、2009年4月。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, March 2009.
[MPLS-SEC] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2009年3月、進行中の作業。
Authors' Addresses
著者のアドレス
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk
Rich Bradford Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA EMail: rbradfor@cisco.com
Rich Bradford Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA -01719 USAメール：rbradfor@cisco.com
Jean-Philippe Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France EMail: jpv@cisco.com
Jean-Philippe Vasseur Cisco Systems、Inc 11、Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France Email：jpv@cisco.com