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
リソース予約プロトコル（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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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を）パスのスイッチがパス計算要素（のPCE）によって計算することができます。 TE LSPは、自律システム（のAS）など、複数のドメインを横切る場合、パスは、パスのセグメントを計算するため、各責任で、協力複数の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内トポロジーの機密性を維持するために、のPCEは、経路のセグメントの内容を非表示にするメカニズムをサポートする（例えば、ASを横断する経路セグメントとして）符号化することによって、秘密のパスセグメント（CPS）と呼ばれますパスキーのサブオブジェクト（PKS）およびその経路計算の結果内のこのサブオブジェクトを埋め込むなどのコンテンツ。
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）明示的経路オブジェクト（エロス）とレコードルートオブジェクト（RROs）にパスキーサブオブジェクトを運ぶ方法について説明します。
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の）リソース予約プロトコル（RSVP-TE）[RFC3209]、[RFC3473]にTE拡張機能を使用して合図しているスイッチド。 MPLSとGMPLS TE LSPを続くルートはパス計算要素（のPCE）[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は、自律システム（のAS）など、複数のドメイン[RFC4726]を、交差する場合、パスは、パスのセグメントを計算するため、各責任で、協力複数のPCEによって計算することができます。各ASとトポロジーの機密性を維持するために、PCE通信プロトコル（PCEP）[RFC5440]は、パスのセグメントの内容を非表示にするメカニズムをサポートし、パスキーとしてコンテンツを符号化することによって、秘密のパスセグメント（CPS）と呼ばれますサブオブジェクト（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.
この文書では、相互のシグナリングに機密性を容易にするように明示的経路オブジェクト（エロス）とレコードルートオブジェクト（RROs）に含めることにより、MPLSとGMPLSシグナリングにおけるパスキーサブオブジェクトの使用をサポートするために必要なRSVP-TEプロトコルの拡張機能を定義しますドメインTEのLSP。
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つのASから構成される単純なネットワークを示しています。 LSPは、AS-2の出口にAS-1における入口から望まれています。 [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外のノードとAS-2間のパスについての情報を共有することを望んでいません。だから、[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セグメントと経路計算応答に入口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を設定するために、入口LSR信号は、明示的ルート・オブジェクト（ERO）でPCE-1によって報告されたパスをRSVP-TEを用いて符号化します。このプロセスは、RSVP-TEのような正常であるが、PKSはまた、本文書で定義されたメカニズムを使用して、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 Pathメッセージ）がASBR-2（自律システム境界ルータ）に達すると、それはPKS「復号」にPCE-2を参照し、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：PKSの使用を実証するために、簡易ネットワーク
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：パスキーサブオブジェクト。機密性を保持するように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.
パスキーのサブオブジェクト（PKS）は、RSVP-TE Pathメッセージ[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
L
ザ・
The L bit SHOULD NOT be set, so that the subobject represents a strict hop in the explicit route.
サブオブジェクトは、明示的な経路に厳密ホップを表すように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が交差しPKSの拡張のためにPCCとして機能するLSRによって理解されなければならない領域の範囲内で一意でなければなりません。 PCE-IDの解釈は、ドメインローカルポリシーが適用されます。それは、常に到達可能であるとLSRは、CPSの嘘を拡大するために呼び出されたドメインに制限されているアドレスであってもよいPCEのIPv4のアドレスであってもよいです。 （例えば、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
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が交差しPKSの拡張のためにPCCとして機能するLSRによって理解されなければならない領域の範囲内で一意でなければなりません。 PCE-IDの解釈は、ドメインローカルポリシーが適用されます。それは、常に到達可能であるPCEのIPv6アドレスであってもよく、LSRは、CPSの嘘を拡大するために呼び出されたドメインに制限されているアドレスであってもよいです。 （例えば、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であるPathメッセージを受信した場合、それはエラーコード/値の組み合わせを、「ルーティング問題」/「悪い初期のサブオブジェクトを」運ぶのPathErrメッセージで応じなければなりません。
- 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]の手順に従って）Pathメッセージで運ばEROからすべてのローカルサブオブジェクトを取り除き、次のサブオブジェクトは、PKSであることを発見した場合は、CPSにPKSを解決しようとしなければなりません。
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は、PCEP [RFC5440]を使用して同定PCEに接触するPKSに含まPCE-IDを使用して、PKSを拡大することを要求することができます。
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はのPCE間の協力に依存する、PKSを拡張することを要求するPCEP [RFC5440]を使用して任意のPCEと接触することができます。
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は、CPSは、以前PKSを発信PCEによってそれに供給された指数PKS内の情報を使用することができます。
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の直接置き換えとしてPathメッセージの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は、PKSをデコードする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.
PCE-IDで識別されるOの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」（6.3節を参照）とのPathErrメッセージを送信します。
o The PCE is unable to decode the PKS, perhaps because the Path Key has expired.
PCE Oパスキーの有効期限が切れているかもしれないので、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の拡大のため不明なパスキー」（6.3節を参照）とのPathErrメッセージを送信します。
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の添加はPathメッセージが大きくなりすぎるようになります。
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は、ローカルポリシーに従って、ルーズホップ[RFC3209]またはさらにPKSとEROの一部に取って代わることができます。 LSRがEROのサイズを小さくするための措置をとることができない場合は、エラーコード「ルーティング問題」と新しいエラー値「MTUに対して大きすぎERO」との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）はLSPによってトラバース経路を記録するために、RSVP-TEで使用されています。 RROは、Pathメッセージに及びResvメッセージ上に存在してもよいです。 [RFC3209]の意図は、入口LSRによって受信されるResvメッセージにRROが同じLSPを達成するために、そのLSRによって送信されたPathメッセージに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とRROに置き換えてもよいです。 ResvメッセージにRROの場合には、使用されるPKSは、もともとPathメッセージのEROでシグナリングものでなければなりません。 Pathメッセージに、PKSは、CPSを交換LSRを識別し、経路セグメントを展開するために使用することができるパスキーを提供しなければなりません。後者の場合には、パスのキーとその膨張は、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]に記載されているように、セキュアにすることができます。 MPLS-TEやGMPLSネットワークにおけるRSVP-TEを確保するための一般的な考察は[MPLS-SEC]に見出すことができるがPCEPのプロトコル相互作用は、[RFC5520]に記載されています。
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.
これにより、セキュリティ上の問題は、ポイントツーポイント通信を保護し、認証するための標準的な技術を用いて対応することができます。加えて、PCEは、PKSの拡張のための要求を発行したLSRは、得られたCPSのヘッドエンドであることPKS拡張チェックを提供することが推奨されます。
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.
さらに保護はCPSの先頭にLSRを含むドメイン内でのみ意味のある復号PCEを識別するためのPCE-IDを使用して提供することができます。これは、ドメインまたはいくつかの非アドレス値内からのみ到達可能なIPアドレスのいずれであってもよいです。前者はのPCEのポリシーの設定が必要です。後者は、ドメイン全体のポリシーが必要です。
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.
それはPCEP及びそれらのプロトコルに対して定義された標準のセキュリティ・メカニズムを使用して、RSVP-TEプロトコルで交換されるようにCPS自体が秘密にしてもよいです。
- 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
- プロービングによる情報の決意。上記プロービングに加えて、ノードは、セクション3.1で説明したようにPKS拡張が失敗したときに生成されるエラー応答から情報を推論するかもしれません。セクション3.1かもしれないに記載の詳細なエラーコードのいずれかを供給することを決定する任意のLSR
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.
体系的な攻撃の一部として使用することができ、あまりにも多くの情報を提供することは、単純にすべてのケースで、「ポリシー制御の失敗」/「ドメイン間ポリシーの失敗」のエラーコード/値を使用するかもしれません。
- 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の使用につながる、変更または偽造されるということです。その結果は、間違って設定されるようにLSPを引き起こし、それが傍受、またはLSPを設定するために失敗することができますどこに不適切なネットワークリソースの使用状況、交通の転換が生じ、Pathメッセージで悪いEROだろう。これらの問題は、PCEPでプロトコル交換を保護することにより防止とRSVP-TEを[RFC5440]に記載されているセキュリティ技術を使用して、[RFC3209]、および[MPLS-SEC]することができます。
- 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）攻撃に対する回復力。この問題は、[RFC5520]で対処されており、この文書の範囲外である - PCEはパスキー拡張要求の洪水によって攻撃することができます。さらに攻撃が故意に偽のPKSでRSVP-TEのPathメッセージの洪水を送信する構成されます。この攻撃は、標準のRSVP-TEのセキュリティメカニズムを使用してPathメッセージの整合性を確保することによって、および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.
ポリシーは、エロスと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.
- PKSを含むEROの取り扱い。セクション3.1で説明したように、PKSを含むPathメッセージを受信したLSRは、ポリシーに応じてPathメッセージを拒否するように構成することができます。
- 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.
- PKSの取扱いはPCEに要求します。 、および[RFC5394]の[RFC5520]に、セクション3.1で説明したように、PCEは、それがPKS拡張の要求を処理する方法に関するポリシーを使用して構成することができます。
- 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、PKSに識別された特定の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の解釈。 PKSの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大きすぎます。それはEROにCPSを追加すると、Pathメッセージが大きすぎることを引き起こすことを発見したとき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で説明したように、ボーダールータはのPKSに置き換えることにより、経路のセグメントをマスクするために選択することができます。この動作は、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.
- 診断ツールによってPKSの検査/復号化。 PCEは、PKSの拡大を要求するために、管理や診断ツールからのアクセスを許可することができます。これは第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は、ポリシー障害としてすべてのエラーを報告し、セクション4で説明したように、PKSを拡大する障害に関連付けられていると理由コードを隠すために、ローカルポリシーの設定をサポートすることができます。
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とEXPLICIT_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]
20 EXPLICIT_ROUTE [RFC3209]クラス型またはC-型：1型を持つ32ビットのPCE-ID [RFC5553] 65パスキーで1明示的経路[RFC3209]サブオブジェクトタイプ64パスキー128ビット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における使用のためのPKSを定義します。 IANAは、PCEPでPKSのために割り当てられているとして、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.
この副登録内、ROUTE_RECORDオブジェクトの定義は、オブジェクト定義は、クラスタイプ1のために許容されるサブオブジェクトの数を示しクラス番号21と（またRECORD_ROUTEオブジェクトとして知られている）があります。
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]
21 ROUTE_RECORD（またRECORD_ROUTEとして知られている）[RFC3209]クラスタイプまたはCタイプ：1つのタイプ128ビットと32ビットのPCE-ID [RFC5553] 65パスキーで1ルートレコード[RFC3209]サブオブジェクトタイプ64パスキー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節でEXPLICIT_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.
セクション3.1で説明したようにIANAは、このエラーコードで使用するための更なる誤差値を割り当てました。次のようにレジストリ内の結果のエントリがあります。
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]
31は=不明PCE-ID PKS拡張のための[RFC5553] PKS拡張のため32 =未到達PCE [RFC5553] PKS拡張のため33 =不明パスキーMTUため[RFC5553] 34 = ERO大きすぎる[RFC5553]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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]ファレル、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.、バーガー、L.、およびJ.アッシュ、 "政策対応の経路計算フレームワーク"、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。、編、およびJL。ル・ルー、エド。、 "パス計算要素（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]ブラッドフォード、R.、エド。、Vasseur、JP。、およびA.ファレル、「パス・キー・ベースのメカニズムを使用したドメイン間の経路計算で保存トポロジ機密性」、RFC 5520、2009年4月。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, March 2009.
[MPLS-SEC]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク" が進歩、2009年3月での作業。
Authors' Addresses
著者のアドレス
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk
Rich Bradford Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA EMail: rbradfor@cisco.com
リッチブラッドフォードシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、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
ジャン=フィリップVasseurシスコシステムズ社11、ルーカミーユ・デムーランアトランティス92782イシレムリノーフランスEメール：jpv@cisco.com