Network Working Group R. Bradford, Ed.
Request for Comments: 5520 JP. Vasseur
Category: Standards Track Cisco Systems, Inc.
A. Farrel
Old Dog Consulting
April 2009
Preserving Topology Confidentiality in
Inter-Domain Path Computation Using a Path-Key-Based Mechanism
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
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. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.
マルチプロトコルラベルスイッチング（MPLS）と一般化MPLS（GMPLS）トラフィックエンジニアリング（TE）ラベルはパス（LSPの）経路計算要素（PCEの）によって計算することができるスイッチド。 TE LSPは、自律システム（のAS）など、複数のドメインを横切る場合、パスは、パスのセグメントを計算するため、各責任で、協力複数のPCEによって計算することができます。 PCEは、このようにAS-内部トポロジ情報を開示する、別のドメインのPCEに経路セグメントを供給するためしかし、いくつかのケースでは（例えば、のASが別のサービスプロバイダによって投与される場合）には、機密保持ルールを破ることになります。この問題は、ゆるいホップを返すことによって、シグナリングメッセージが第二のドメインを入力するようTE LSPのセットアップ時にルータ（LSR）をスイッチングドメイン境界ラベルから新しい経路計算を呼び出すことによって回避することができるが、この技術はの問題を含め、いくつかの問題を持っていますパスの多様性を維持します。
This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object.
この文書は、パスのセグメントの内容を非表示にするメカニズムを定義し、秘密のパスセグメント（CPS）と呼ばれます。 CPSは、PCE通信プロトコル（PCEP）に搬送し、リソース予約プロトコルTE（RSVP-TE）明示的経路オブジェクトに内シグナリングすることができるパスキーに置き換えることができます。
Table of contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Path-Key Solution ...............................................5
2.1. Mode of Operation ..........................................5
2.2. Example ....................................................6
3. PCEP Protocol Extensions ........................................7
3.1. Path-Keys in PCRep Messages ................................7
3.1.1. PKS with 32-Bit PCE ID ..............................8
3.1.2. PKS with 128-Bit PCE ID .............................9
3.2. Unlocking Path-Keys .......................................10
3.2.1. Path-Key Bit .......................................10
3.2.2. PATH-KEY Object ....................................10
3.2.3. Path Computation Request (PCReq) Message
with Path-Key ......................................11
4. PCEP Mode of Operation for Path-Key Expansion ..................12
5. Security Considerations ........................................12
6. Manageability Considerations ...................................13
6.1. Control of Function through Configuration and Policy ......13
6.2. Information and Data Models ...............................14
6.3. Liveness Detection and Monitoring .........................15
6.4. Verifying Correct Operation ...............................15
6.5. Requirements on Other Protocols and Functional
Components ................................................15
6.6. Impact on Network Operation ...............................16
7. IANA Considerations ............................................16
7.1. New Subobjects for the ERO Object .........................16
7.2. New PCEP Object ...........................................17
7.3. New RP Object Bit Flag ....................................17
7.4. New NO-PATH-VECTOR TLV Bit Flag ...........................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
Acknowledgements ..................................................19
Path computation techniques using the Path Computation Element (PCE) are described in [RFC4655] and allow for path computation of inter-domain Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs).
パス計算要素（PCE）を使用して経路計算技術は[RFC4655]に記載のドメイン間のマルチプロトコルラベルの経路計算を切り替えるための許可されている（MPLS）トラフィックエンジニアリング（TE）と一般化MPLS（GMPLS）ラベルスイッチパス（LSP）。
An important element of inter-domain TE is that TE information is not shared between domains for scalability and confidentiality reasons ([RFC4105] and [RFC4216]). Therefore, a single PCE is unlikely to be able to compute a full inter-domain path.
ドメイン間TEの重要な要素は、TE情報は、拡張性と機密性の理由（[RFC4105]及び[RFC4216]）のためのドメイン間で共有されていないことです。したがって、単一PCEは、完全なドメイン間パスを計算することができることはほとんどありません。
Two path computation scenarios can be used for inter-domain TE LSPs: one using per-domain path computation (defined in [RFC5152]), and the other using a PCE-based path computation technique with cooperation between PCEs (as described in [RFC4655]). In this second case, paths for inter-domain LSPs can be computed by cooperation between PCEs each of which computes a segment of the path across one domain. Such a path computation procedure is described in [RFC5441].
二つの経路計算シナリオは、ドメイン間のTE LSPのために使用することができる一のPCE間の協力（とPCEベースの経路計算技術を使用して（[RFC5152]で定義される）ごとのドメイン経路計算を使用して、およびその他に記載されているように[RFC4655 ]）。この第二の場合では、ドメイン間のLSPのためのパスは、一つのドメインを横切る経路のセグメントを計算しその各々のPCE間の協働によって計算することができます。そのような経路計算手順は、[RFC5441]に記載されています。
If confidentiality is required between domains (such as would very likely be the case between Autonomous Systems (ASes) belonging to different Service Providers), then cooperating PCEs cannot exchange path segments or else the receiving PCE and the Path Computation Client (PCC) will be able to see the individual hops through another domain thus breaking the confidentiality requirement stated in [RFC4105] and [RFC4216]. We define the part of the path that we wish to keep confidential as the Confidential Path Segment (CPS).
機密性は、（異なるサービスプロバイダに属するなど）のAS（可能性が非常に高い自律システム間の場合のように）ドメイン間で必要とされている場合は、のPCEを協働して、パスセグメントを交換することはできませんか、他の受信PCEとパス計算クライアント（PCC）となりますしたがって、[RFC4105]と[RFC4216]で述べた機密性の要件を破る別のドメインを介して個々のホップを見ることができます。私たちは、機密パスセグメント（CPS）などの機密保持したいパスの一部を定義します。
One mechanism for preserving the confidentiality of the CPS is for the PCE to return a path containing a loose hop in place of the segment that must be kept confidential. The concept of loose and strict hops for the route of a TE LSP is described in [RFC3209]. The Path Computation Element Communication Protocol (PCEP) defined in [RFC5440] supports the use of paths with loose hops, and it is a local policy decision at a PCE whether it returns a full explicit path with strict hops or uses loose hops. Note that a path computation request may request an explicit path with strict hops or may allow loose hops as detailed in [RFC5440].
PCEは秘密にしなければならないセグメントの代わりにゆるいホップを含むパスを返すようにするためにCPSの機密性を維持するための1つのメカニズムです。 TE LSPの経路のための緩いと厳密ホップの概念は、[RFC3209]に記載されています。 [RFC5440]で定義されたパス計算エレメント通信プロトコル（PCEP）はルーズホップを有するパスの使用をサポートし、それは厳密ホップとの完全な明示的なパスを返すか、ルーズホップを使用するかどうかPCEでローカルポリシー決定です。経路計算要求が厳しいホップとの明示的なパスを要求することができるか、[RFC5440]に詳述されるようにルーズホップを可能にすることができることに留意されたいです。
The option of returning a loose hop in place of the CPS can be achieved without further extensions to PCEP or the signaling protocol. If loose hops are used, the TE LSPs are signaled as normal ([RFC3209]), and when a loose hop is encountered in the explicit route, it is resolved by performing a secondary path computation to reach the resource or set of resources identified by the loose hop. Given the nature of the cooperation between PCEs in computing the original path, this secondary computation occurs at or on behalf of a
CPSの代わりにゆるいホップを返すオプションがPCEPまたはシグナリングプロトコルをさらに拡張することなく達成することができます。ルーズホップが使用される場合、TE LSPは、リソースに到達するために二次経路計算を行うことにより、通常のようにルーズホップを明示的経路に遭遇した場合、そして、それは（[RFC3209]）解決されるシグナリングまたはによって識別されたリソースのセットであります緩いホップ。元のパスを計算する際のPCE間の協力の性質を考えると、この二次計算はで、または代わって発生します
Label Switching Router (LSR) at a domain boundary (i.e., an Area Border Router (ABR) or an AS Border Router (ASBR)) and the path is expanded as described in [RFC5152].
[RFC5152]に記載されているように、ドメイン境界のルータ（LSR）をラベルスイッチング（すなわち、エリア境界ルータ（ABR）またはAS境界ルータ（ASBR））とパスが拡張されます。
The PCE-based computation model is particularly useful for determining mutually disjoint inter-domain paths such as might be required for service protection [RFC5298]. A single path computation request is used. However, if loose hops are returned, the path of each TE LSP must be recomputed at the domain boundaries as the TE LSPs are signaled, and since the TE LSP signaling proceeds independently for each TE LSP, disjoint paths cannot be guaranteed since the LSRs in charge of expanding the explicit route objects (EROs) are not synchronized. Therefore, if the loose hop technique is used without further extensions, path segment confidentiality and path diversity are mutually incompatible requirements.
PCEベースの計算モデルは、サービス保護[RFC5298]のために必要とされるかもしれないような互いに素ドメイン間の経路を決定するために特に有用です。シングルパス計算要求が使用されます。しかし、ルーズホップが返された場合、各TE LSPの経路がシグナリングされるTE LSPを、ドメイン境界で再計算されなければならない、そしてTE LSPは、各TE LSPに対して独立移行をシグナリングするため、ばらばらパスがでのLSRので保証できません明示的経路オブジェクトを拡大する電荷（エロス）が同期されません。ルーズホップ技術をさらに拡張することなく使用した場合従って、経路セグメント機密性とパスダイバーシチは、相互に互換性のない要件です。
This document defines the notion of a Path-Key that is a token that replaces a path segment in an explicit route. The Path-Key is encoded as a Path-Key Subobject (PKS) returned in the PCEP Path Computation Reply message (PCRep) ([RFC5440]). Upon receiving the computed path, the PKS will be carried in an RSVP-TE Path message (RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling.
この文書は、明示的なルートでパスセグメントを置き換えるトークンでパスキーの概念を定義します。パスキーサブオブジェクト（PKS）として符号化されたキーがパスPCEP経路計算応答メッセージ（PCRep）（[RFC5440]）に返されます。計算された経路を受信すると、PKSは、シグナリング中RSVP-TE Pathメッセージ（RSVP-TE [RFC3209]と[RSVP-PKS]）で実施されます。
The BNF in this document follows the format described in [RBNF].
この文書に記載されているBNFは[RBNF]に記載のフォーマットに従います。
Please note that the term "path-key" used in this document refers to an identifier allocated by a PCE to represent a segment of a computed path. This term has no relation to the term "cryptographic key" used in some documents that describe security mechanisms.
本書で使用される用語「パス・キー」が計算された経路セグメントを表すために、PCEによって割り当てられた識別子を指すことに注意してください。この用語は、セキュリティメカニズムを説明し、いくつかの文書で使用される用語「暗号鍵」とは関係ありません。
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]に記載されているように解釈されます。
This document makes use of the following terminology and acronyms.
このドキュメントでは、次の用語および頭字語を使用しています。
AS: Autonomous System.
AS：自律システム。
ASBR: Autonomous System Border Routers used to connect to another AS of a different or the same Service Provider via one or more links inter-connecting between ASes.
ASBR：自律システム境界ルータは異なる1つのまたは複数のリンクのAS間の相互接続を経由して、同じサービスプロバイダーのAS別に接続するために使用されます。
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の外に開示されないために必要なノードおよびリンクを含むパスのセグメント。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
インターAS TE LSP：TE LSP AS境界を越えます。
LSR: Label Switching Router.
LSR：ラベルスイッチングルータ。
LSP: Label Switched Path.
LSP：ラベルスイッチパス。
PCC: Path Computation Client: Any client application requesting a path computation to be performed by a Path Computation Element.
PCC：経路計算クライアント：経路計算を要求するクライアント・アプリケーションは、経路計算要素によって実行されます。
PCE: Path Computation Element: An entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：パス計算要素：エンティティ（コンポーネント、アプリケーション、またはネットワークノード）ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能です。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：トラフィックエンジニアリングラベルスイッチパス。
The Path-Key solution may be applied in the PCE-based path computation context as follows. A PCE computes a path segment related to a particular domain and replaces any CPS in the path reported to the requesting PCC (or another PCE) by one or more subobjects referred to as PKSes. The entry boundary LSR of each CPS SHOULD be specified using its TE Router Id as a hop in the returned path immediately preceding the CPS, and other subobjects MAY be included in the path immediately before the hop identifying the boundary LSR to indicate link and label choices. Where two PKSes are supplied in sequence with no intervening nodes, the entry node to the second CPS MAY be part of the first CPS and does not need to be explicitly present in the returned path. The exit node of a CPS MAY be present as a strict hop immediately following the PKS.
次のようにパスキーソリューションは、PCEベースの経路計算コンテキストに適用されてもよいです。 PCEは、特定のドメインに関連する経路セグメントを計算し、PKSesと称される一つ以上のサブオブジェクトによって要求PCC（または別のPCE）に報告されたパス内の任意のCPSを置き換えます。直ちにリンクとラベルの選択を示すために境界LSRを識別するホップする前に、パス内の各CPSのエントリ境界LSRは直ちにCPS先行返されたパスにおけるホップとしてのTEルータIDを使用して指定されるべきであり、他のサブオブジェクトが含まれるかもしれ。 2 PKSesはない介在ノードで順次供給される場合、第二のCPSへのエントリノードは、最初のCPSの一部であってもよいし、返されたパスに明示的に存在する必要はありません。 CPSの出口ノードは、直ちにPKSを以下厳密ホップとして存在してもよいです。
During path computation, when local policy dictates that confidentiality must be preserved for all or part of the path segment being computed or if explicitly requested by the path computation request, the PCE associates a path-key with the computed path for the CPS, places its own identifier (its PCE ID as defined in Section 3.1) along with the path-key in a PKS, and inserts the PKS object in the path returned to the requesting PCC or PCE immediately after the subobject that identifies (using the TE Router Id) the LSR that will expand the PKS into explicit path hops. This will usually be the LSR that is the starting point of the CPS. The PCE that generates a PKS SHOULD store the computed path segment and the path-key for later retrieval. A local policy SHOULD be used to determine for how long to retain such stored information, and whether to discard the information after it has been queried using the procedures described below. It is RECOMMENDED for a PCE to store the PKS for a period of 10 minutes.
ローカルポリシーは、機密性が計算されたパスセグメントの全部または一部を保存しなければならないか、または明示的に経路計算要求によって要求された場合、PCEがCPSのために計算された経路とパス・キーを関連付けるように指示したときに経路計算時には、そのを配置PKSにおけるパスキーとともに、パスにおけるPKSオブジェクトは直ちに識別（TEルータIDを使用して）サブオブジェクトの後に要求PCC又はPCEに返さ挿入自身の識別子（セクション3.1で定義されるように、そのPCEのID）明示的なパスにPKSを拡大するLSRはホップ。これは通常、CPSの出発点であるLSRになります。 PKSを生成PCEは、計算された経路セグメントおよび後の検索のためにパスキーを格納する必要があります。ローカルポリシーは、このような格納された情報を保持するためにどのくらいのために決定するために使用されるべきであり、それは下記の手順を使用して照会された後の情報を破棄するかどうか。これは、10分間PKSを格納するためのPCEをお勧めします。
A path-key value is scoped to the PCE that computed it as identified by the PCE-ID carried in the PKS. A PCE MUST NOT re-use a path-key value to represent a new CPS for at least 30 minutes after discarding the previous use of the same path-key. A PCE that is unable to retain information about previously used path-key values over a restart SHOULD use some other mechanism to guarantee uniqueness of path-key values such as embedding a timestamp or version number in the path-key.
パスキー値はPKSで運ばPCE-IDによって識別されるように計算されたPCEにスコープされています。 PCEは、同じパスキーの以前の使用を破棄した後、少なくとも30分間、新たなCPSを表現するためにパスキー値を再使用してはいけません。再起動の上に以前に使用されるパスキー値に関する情報を保持することができないPCEは、経路キーのタイムスタンプ又はバージョン番号を埋め込むように、パスキー値の一意性を保証するためにいくつかの他のメカニズムを使用すべきです。
A head-end LSR that is a PCC converts the path returned by a PCE into an explicit route object (ERO) that it includes in the Resource Reservation Protocol (RSVP) Path message. If the path returned by the PCE contains a PKS, this is included in the ERO. Like any other subobjects, the PKS is passed transparently from hop to hop, until it becomes the first subobject in the ERO. This will occur at the start of the CPS, which will usually be the domain boundary. The PKS MUST be preceded by an ERO subobject that identifies the LSR that must expand the PKS. This means that (following the rules for ERO processing set out in [RFC3209]) the PKS will not be encountered in ERO processing until the ERO is being processed by the LSR that is capable of correctly handling the PKS.
PCCであるヘッドエンドLSRは、リソース予約プロトコル（RSVP）Pathメッセージに含まれていることを明示的ルート・オブジェクト（ERO）にPCEによって返される経路を変換します。 PCEによって返されたパスがPKSが含まれている場合、これはEROに含まれています。それはEROの最初のサブオブジェクトになるまで、他のサブオブジェクトと同じように、PKSは、ホップするホップから透過的に渡されます。これは通常、ドメイン境界になりますCPSの開始時に発生します。 PKSは、PKSを展開しなければならないLSRを識別するEROサブオブジェクトが先行されなければなりません。これは、EROが正しくPKSを処理することが可能であることLSRによって処理されるまで（[RFC3209]に記載ERO処理のための規則に従う）PKSは、ERO処理において遭遇されないことを意味します。
An LSR that encounters a PKS when trying to identify the next hop retrieves the PCE-ID from the PKS and sends a Path Computation Request (PCReq) message as defined in [RFC5440] to the PCE identified by the PCE-ID that contains the path-key object .
次のホップを特定しようとするPKSを検出したLSRはPKSからPCE-IDを取得し、パスを含むPCE-IDによって識別されるPCEに[RFC5440]で定義されるように経路計算要求（PCReq）メッセージを送信します。 -keyオブジェクト。
Upon receiving the PCReq message, the PCE identifies the computed path segment using the supplied path-key, and returns the previously computed path segment in the form of explicit hops using an ERO object contained in the Path Computation Reply (PCRep) to the requesting node as defined in [RFC5440]. The requesting node inserts the explicit hops into the ERO and continues to process the TE LSP setup as per [RFC3209].
PCReqメッセージを受信すると、PCEは、供給されたパス・キーを使用して計算された経路セグメントを特定し、要求側ノードへの経路計算応答（PCRep）に含まれるEROオブジェクトを使用して明示的なホップの形で以前に計算された経路セグメントを返します[RFC5440]で定義されます。要求ノードはEROに明示的なホップを挿入し、[RFC3209]に従ってTE LSPセットアップを処理し続けます。
Figure 1 shows a simple two-AS topology with a PCE responsible for the path computations in each AS. An LSP is requested from the ingress LSR in one AS to the egress LSR in the other AS. The ingress, acting as the PCC, sends a path computation request to PCE-1. PCE-1 is unable to compute an end-to-end path and invokes PCE-2 (possibly using the techniques described in [RFC5441]). PCE-2 computes a path segment from ASBR-2 to the egress as {ASBR-2, C, D,
図1は、各AS内の経路計算を担当するPCEを持つ単純な二ASのトポロジーを示します。 LSPは、他のASで出口LSRにAS 1に入口LSRから要求されます。入口は、PCCとして作用する、PCE-1への経路計算リクエストを送信します。 PCE-1は、エンドツーエンド経路を計算することができず、（おそらく、[RFC5441]に記載された技術を用いて）PCE-2を呼び出します。 PCE-2は、{ASBR-2、C、Dとして出力するASBR-2から経路セグメントを計算します
Egress}. It could pass this path segment back to PCE-1 in full, or it could send back the path {ASBR-2, Egress} where the second hop is a loose hop.
出口}。それは完全にPCE-1に戻し、この経路セグメントを渡すことができ、またはそれは第2のホップが緩んホップであるパス{ASBR-2、退出}を送り返すことができました。
However, in order to protect the confidentiality of the topology in the second AS while still specifying the path in full, PCE-2 may send PCE-1 a path segment expressed as {ASBR-2, PKS, Egress} where the PKS is a Path-Key Subobject as defined in this document. In this case, PCE-2 has identified the segment {ASBR-2, C, D, Egress} as a Confidential Path Segment (CPS). PCE-1 will compute the path segment that it is responsible for, and will supply the full path to the PCC as {Ingress, A, B, ASBR-1, ASBR-2, PKS, Egress}.
PKSは、Aであるが、依然として完全、PCE-2のパスを指定してするPCE-1をパスセグメントを送信することができるように、第2トポロジの機密性を保護するために、{PKS、退出、ASBR-2}として表さパスキーサブオブジェクトは、このドキュメントで定義されています。この場合、PCE-2は、機密パスセグメント（CPS）としてセグメント{ASBR-2、C、D、退出}を同定しました。 PCE-1は、それが担当する経路セグメントを計算し、のようなPCC {進入、A、B、ASBR-1、ASBR-2、PKS、退出}への完全なパスを供給する。
Signaling proceeds in the first AS as normal, but when the Path message reaches ASBR-2, the next hop is the PKS, and this must be expanded before signaling can progress further. ASBR-2 uses the information in the PKS to request PCE-2 for a path segment, and PCE-2 will return the segment {ASBR-2, C, D, Egress} allowing signaling to continue to set up the LSP.
通常のように最初に移行シグナリングが、PathメッセージがASBR-2に到達したとき、次ホップはPKSであり、これはさらに進行させることができるシグナリング前に展開されなければなりません。 ASBR-2は、パスセグメントのPCE-2要求するPKSの情報を使用して、PCE-2は、LSPをセットアップするために継続するシグナリング可能セグメント{ASBR-2、C、D、退出}を返します。
----------------------------- ----------------------------
| ------- | | ------- |
| | 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の使用を実証するためのシンプルなネットワーク
Path-Keys are carried in PCReq and PCRep messages as part of the various objects that carry path definitions. In particular, a Path-Key is carried in the Explicit Route Object (ERO) on PCRep messages.
パスキーは、パス定義を運ぶ様々なオブジェクトの一部としてPCReqとPCRepメッセージで運ばれます。具体的には、パス・キーがPCRepメッセージに明示的なルートオブジェクト（ERO）で運ばれます。
In all cases, the Path-Key is carried in a Path-Key Subobject (PKS).
すべての場合において、パス・キーがパス・キーサブオブジェクト（PKS）で運ばれます。
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 an identifier that is unique within the domain that the PCE serves. The PCE-ID has to be mapped to a reachable IPv4 or IPv6 address of the PCE by the first node of the CPS (usually a domain border router) and a PCE MAY use one of its reachable IP addresses as its PCE-ID. Alternatively and to provide greater security (see Section 5) or increased confidentiality, according to domain-local policy, the PCE MAY use some other identifier that is scoped only within the domain.
PKSは、パスキーとPCE-IDを含む固定長のサブオブジェクトです。パスキー識別子であり、又はPCE-IDによって識別されるPCEのコンテキスト内CPSを表すために使用されるトークン。 PCE-IDは、PCEが機能するドメイン内で一意である識別子を使用してパスキーを復号することができるPCEを識別する。 PCE-IDは、CPSの最初のノード（通常、ドメイン境界ルータ）によってPCEの到達可能なIPv4またはIPv6アドレスにマッピングする必要があり、PCEは、PCE-IDとしての到達可能なIPアドレスの1つを使用することができます。あるいは、より大きなセキュリティ（セクション5を参照）または増加機密性を提供するために、ドメインローカルポリシーに従って、PCEは、ドメイン内にスコープされるいくつかの他の識別子を使用することができます。
To allow IPv4 and IPv6 addresses to be carried, two subobjects are defined in the following subsections.
IPv4およびIPv6を実施することにアドレスできるように、2つのサブオブジェクトは、以下のサブセクションで定義されています。
The Path-Key Subobject may be present in the PCEP ERO or the PCEP PATH-KEY object (see Section 3.2).
パスキーサブオブジェクトは、PCEP EROまたはPCEP PATH-KEYオブジェクト（セクション3.2を参照）に存在することができます。
The Subobject Type for the PKS with 32-bit PCE ID is 64. The format of this subobject is as follows:
32ビットのPCE IDを持つPKSのためのサブオブジェクトの種類は、以下のように、このサブオブジェクトの形式は64です。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 32-bit PCE ID (64).
32ビットのPCEのIDとパスキーのサブオブジェクトタイプ（64）。
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 path-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 (see Section 5).
このパス・キーを復号することができるPCEの32ビットの識別子。識別子は、CPSが交差する領域の範囲内で一意である必要があり、およびPKSの拡張のためにPCCとして機能するLSRによって理解されなければなりません。 PCE-IDの解釈は、ドメインローカルポリシーが適用されます。それは、常に到達可能であるPCEのIPv4アドレスであってもよく、LSRは、CPSの嘘を拡大するために呼び出されたドメインに制限されているアドレスであってもよいです。 （例えば、PCEのルータID）のドメイン外の意味を持たない他の値は、（第5節参照）、セキュリティや機密性を高めるために使用することができます。
The Subobject Type for the PKS with 128-bit PCE ID is 65. The format of the subobject is as follows.
128ビットのPCE IDを持つPKSのためのサブオブジェクトタイプは、次のようにサブオブジェクトの形式は65です。
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) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
ザ・
As above.
上記のように。
Type
タイプ
Subobject Type for a Path-Key with 128-bit PCE ID (65).
128ビットのPCEのIDとパス・キーのためのサブオブジェクトタイプ（65）。
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 path-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, but 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 5).
このパス・キーを復号することができるPCEの128ビットの識別子。識別子は、CPSが交差する領域の範囲内で一意である必要があり、およびPKSの拡張のためにPCCとして機能するLSRによって理解されなければなりません。 PCE-IDの解釈は、ドメインローカルポリシーが適用されます。それは、常に到達可能であるPCEのIPv6のアドレスであってもよいが、LSRは、CPSの嘘を拡大するために呼び出されたドメインに制限されているアドレスであってもよいです。 （例えば、IPv6のTEルータID）のドメイン外の意味を持たない他の値は、（第5節を参照）セキュリティを高めるために使用することができます。
When a network node needs to decode a Path-Key so that it can continue signaling for an LSP, it must send a PCReq to the designated PCE. The PCReq defined in [RFC5440] needs to be modified to support this usage, which differs from the normal path computation request. To that end, a new flag is defined to show that the PCReq relates to the expansion of a PKS, and a new object is defined to carry the PKS in the PCReq. These result in an update to the BNF for the message. The BNF used in this document is as described in [RBNF].
ネットワークノードは、それがLSPのためのシグナリングを継続できるように、パス・キーをデコードする必要がある場合、指定されたPCEにPCReqを送信する必要があります。 [RFC5440]で定義されたPCReqは、通常経路計算要求とは異なるこの使用法をサポートするように変更する必要があります。そのために、新しいフラグがPCReqは、PKSの拡大に関し、新しいオブジェクトがPCReqでPKSを運ぶために定義されていることを示すために定義されています。これらは、メッセージのためのBNFへの更新につながります。 【RBNF]で説明されるように本書で使用されるBNFです。
[RFC5440] defines the Request Parameters (RP) object that is used to specify various characteristics of the Path Computation Request (PCReq).
[RFC5440]は経路計算要求（PCReq）の様々な特性を指定するために使用される要求パラメータ（RP）オブジェクトを定義します。
In this document, we define a new bit named the Path-Key bit as follows. See Section 7.3 for the IANA assignment of the appropriate bit number.
この文書では、我々は次のように新しいビットがパス・キービットの名前を定義します。適切なビット数のIANAの割り当てについては、セクション7.3を参照してください。
Path-Key bit: When set, the requesting PCC requires the retrieval of a Confidential Path Segment that corresponds to the PKS carried in a PATH-KEY object in the path computation request. The Path-Key bit MUST be cleared when the path computation request is not related to a CPS retrieval.
パスキービット：設定、要求PCCは、経路計算要求にPATH-KEYオブジェクトで運ばPKSに対応する秘密のパスセグメントの検索を必要とします。経路計算要求はCPSの検索に関連していないときにパスキービットがクリアされなければなりません。
When a PCC needs to expand a path-key in order to expand a CPS, it issues a Path Computation Request (PCReq) to the PCE identified in the PKS in the RSVP-TE ERO that it is processing. The PCC supplies the PKS to be expanded in a PATH-KEY Object in the PCReq message.
PCCは、CPSを拡大するためにパスキーを展開する必要がある場合、それが処理しているRSVP-TE EROにPKSにおいて同定PCEへの経路計算要求（PCReq）を発行します。 PCCはPCReqメッセージ内PATH-KEYオブジェクトに展開するPKSを供給する。
The PATH-KEY Object is defined as follows:
次のようにPATH-KEYオブジェクトが定義されています。
PATH-KEY Object-Class is 16.
PATH-KEYオブジェクトクラスは16です。
Path-Key Object-Type is 1.
パス・キーオブジェクト型は1です。
The PATH-KEY Object MUST contain at least one Path-Key Subobject (see Section 3.1). The first PKS MUST be processed by the PCE. Subsequent subobjects SHOULD be ignored.
PATH-KEYオブジェクトは、少なくとも一つのパス・キーサブオブジェクトを（3.1節を参照）を含まなければなりません。最初のPKSは、PCEによって処理しなければなりません。後続のサブオブジェクトは無視されるべきです。
The format of a PCReq message including a PATH-KEY object is unchanged as follows:
次のようにPATH-KEYオブジェクトを含むPCReqメッセージのフォーマットは変わりません。
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
To support the use of the message to expand a PKS, the definition of <request> is modified as follows :
次のようにPKS、<要求>の定義を拡張するメッセージの使用をサポートするように修正されます。
<request>::= <RP>
<segment-computation> | <path-key-expansion>
where:
<segment-computation> ::= <END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
<path-key-expansion> ::= <PATH-KEY>
Thus, the format of the message for use in normal path computation is unmodified.
したがって、通常の経路計算に使用するためのメッセージのフォーマットは、未修飾です。
The retrieval of the explicit path (the CPS) associated with a PKS by a PCC is no different than any other path computation request with the exception that the PCReq message MUST contain a PATH-KEY object and the Path-Key bit of the RP object MUST be set. On receipt of a PCRep containing a CPS, the requesting PCC SHOULD insert the CPS into the ERO that it will signal, in accordance with local policy.
PCCによりPKSに関連付けられた明示的なパス（CPS）の検索は、PCReqメッセージがPATH-KEYオブジェクトおよびRPオブジェクトのパス・キーのビットを含まなければならないことを除いて、他の経路計算要求と違いはありません設定しなければなりません。 CPSを含むPCRepを受信すると、要求PCCは、ローカルポリシーに従って、信号を送るEROにCPSを挿入する必要があります。
If the receiving PCE does not recognize itself as identified by the PCE ID carried in the PKS, it MAY forward the PCReq message to another PCE according to local policy. If the PCE does not forward such a PCReq, it MUST respond with a PCRep message containing a NO-PATH object.
PKSで運ばPCEのIDによって識別される受信PCEは、それ自体を認識しない場合、それはローカルポリシーに従って別のPCEにPCReqメッセージを転送することができます。 PCEは、このようなPCReqを転送しない場合は、NO-PATHオブジェクトを含むPCRepメッセージで応じなければなりません。
If the receiving PCE recognizes itself, but cannot find the related CPS, or if the retrieval of the CPS is not allowed by policy, the PCE MUST send a PCRep message that contains a NO-PATH object. The NO-PATH-VECTOR TLV SHOULD be used as described in [RFC5440] and a new bit number (see Section 7.4) is assigned to indicate "Cannot expand PKS".
受信PCEは、それ自体を認識したが、関連CPSを見つけることができない、またはCPSの検索がポリシーによって許可されていない場合、PCEは、NO-PATHオブジェクトを含むPCRepメッセージを送信する必要がある場合。 [RFC5440]に記載されており、新たなビット数は（7.4節を参照）、「PKSを展開することはできません」を示すために割り当てられている。ようにNO-PATHベクターTLVが使用されてください
Upon receipt of a negative reply, the requesting LSR MUST fail the LSP setup and SHOULD use the procedures associated with loose hop expansion failure [RFC3209].
負の応答を受信すると、要求LSRは、LSPセットアップに失敗しなければならないとルーズホップ拡張障害[RFC3209]に関連した手順を使用すべきです。
This document describes tunneling confidential path information across an untrusted domain (such as an AS). There are many security considerations that apply to PCEP and RSVP-TE.
この文書は、（ASなど）信頼されていないドメイン間でトンネリング機密パス情報を記述します。 PCEPとRSVP-TEに適用する多くのセキュリティ上の考慮事項があります。
Issues include:
問題は、次のとおりです。
- Confidentiality of the CPS (can other network elements probe for expansion of path-keys, possibly at random?).
- CPSの機密性（他のネットワーク要素は、おそらくはランダムに、パスキーの拡張のためにプローブすることができますか？）。
- Authenticity of the path-key (resilience to alteration by intermediaries, resilience to fake expansion of path-keys).
- （パス・キーの偽膨張媒体によって変化、弾力の回復力）パスキーの真正。
- Resilience from Denial-of-Service (DoS) attacks (insertion of spurious path-keys; flooding of bogus path-key expansion requests).
- サービス拒否（DoS）攻撃（スプリアスパス・キーの挿入、偽のパス・キーの拡張要求の洪水）からの回復力。
Most of the interactions required by this extension are point to point, can be authenticated and made secure as described in [RFC5440] and [RFC3209]. These interactions include the:
この拡張によって必要とされる相互作用の大部分は、ポイントをポイントは、認証され、[RFC5440]及び[RFC3209]に記載されているようにセキュアにすることが可能です。これらの相互作用は、次のとおりです。
- PCC->PCE request
- PCC-> PCE要求
- PCE->PCE request(s)
- PCE-> PCE要求（単数または複数）
- PCE->PCE response(s)
- PCE-> PCE応答（S）
- PCE->PCC response
- PCE-> PCC応答
- LSR->LSR request and response. Note that a rogue LSR could modify the ERO and insert or modify Path-Keys. This would result in an LSR (which is downstream in the ERO) sending decode requests to a PCE. This is actually a larger problem with RSVP. The rogue LSR is an existing issue with RSVP and will not be addressed here.
- LSR-> LSR要求と応答。不正のLSRはEROを変更し、パス・キーを挿入したり、修正することができることに注意してください。これは、PCEに対してデコード要求を送信する（EROの下流である）LSRをもたらすであろう。これは実際にRSVPを持つ大きな問題です。不正LSRは、RSVPと、既存の問題であり、ここで扱われることはありません。
- LSR->PCE request. Note that the PCE can check that the LSR requesting the decode is the LSR at the head of the Path-Key. This largely contains the previous problem of DoS rather than a security issue. A rogue LSR can issue random decode requests, but these will amount only to DoS.
- LSR-> PCE要求。 PCEは、LSRがパス・キーの先頭にLSRをデコードしている要求していることを確認することもできます。これは主にDoS攻撃の前の問題ではなく、セキュリティ上の問題が含まれています。不正のLSRは、ランダムデコード要求を発行することができますが、これらは唯一のDoSに達するだろう。
- PCE->LSR response
- PCE-> LSR応答
Thus, the major 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 decode response should check that the LSR that issued the decode request is the head end of the decoded ERO segment.
したがって、主要なセキュリティ問題は、ポイントツーポイント通信を保護し、認証するための標準的な技術を用いて対応することができます。加えて、デコード応答を提供するPCEは、デコード要求を発行したLSRが復号EROセグメントのヘッドエンドであることを確認しなければならないことが推奨されます。
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 an IP address that is only reachable from within the domain, or some not-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 treatment of a path segment as a CPS, and its substitution in a PCRep ERO with a PKS, is a function that MUST be under operator and policy control where a PCE supports the function. The operator MUST be given the ability to specify which path segments are to be replaced and under what circumstances. For example, an operator might set a policy that states that every path segment for the operator's domain will be replaced by a PKS when the PCReq has been issued from outside the domain.
PKSとPCRep EROにおけるCPSとして経路セグメントの処置、およびその置換が、PCE機能をサポートオペレータおよびポリシー制御下にある必要があり関数です。オペレータは、セグメントを交換し、どのような状況の下でされるべきパスを指定する能力を与えられなければなりません。例えば、オペレータは、オペレータのドメインのすべてのパスセグメントがPCReqがドメイン外から発行されたPKSに置き換えられますことを述べてポリシーを設定することもできます。
The operation of the PKS extensions require that path-keys are retained by the issuing PCE to be available for retrieval by an LSR (acting as a PCC) at a later date. But it is possible that the retrieval request will never be made, so good housekeeping requires that a timer is run to discard unwanted path-keys. A default value for this timer is suggested in Section 2.1. Implementations SHOULD provide the ability for this value to be overridden through operator configuration or policy.
PKS拡張の動作は、パスキーを後日LSR（PCCとして作用する）による検索のために利用できるように発行PCEによって保持される必要。しかし、それは検索要求が行われることはありません可能性があり、とても良いハウスキーピングはタイマーが不要なパス・キーを破棄するために実行されている必要があります。このタイマーのデフォルト値は2.1で提案されています。実装は、この値は、オペレータの構成またはポリシーによってオーバーライドするための機能を提供すべきです。
After a PKS has been expanded in response to a retrieval request, it may be valuable to retain the path-key and CPS for debugging purposes. Such retention SHOULD NOT be the default behavior of an implementation, but MAY be available in response to operator request.
PKSは、検索要求に応答して拡張された後、デバッグするための経路の鍵とCPSを保持するのに貴重であり得ます。このような保持は、実装のデフォルト動作すべきではありませんが、オペレータの要求に応じて利用できます。
Once a path-key has been discarded, the path-key value SHOULD NOT be immediately available for re-use for a new CPS since this might lead to accidental misuse. A default timer value is suggested in Section 2.1. Implementations SHOULD provide the ability for this value to be overridden through operator configuration or policy.
パス・キーが破棄されたら、これは偶然の誤用につながるかもしれないので、パス・キーの値は、新たなCPSの再使用のためにすぐに利用すべきではありません。デフォルトのタイマー値は、2.1節で提案されます。実装は、この値は、オペレータの構成またはポリシーによってオーバーライドするための機能を提供すべきです。
A PCE must set a PCE-ID value in each PKS it creates so that PCCs can correctly identify it and send PCReq messages to expand the PKS to a path segment. A PCE implementation SHOULD allow operator or policy control of the value to be used as the PCE-ID. If the PCE allows PCE-ID values that are not routable addresses to be used, the PCCs MUST be configurable (by the operator or through policy) to allow the PCCs to map from the PCE-ID to a routable address of the PCE. Such mapping may be algorithmic, procedural (for example, mapping a PCE-ID equal to the IGP Router ID into a routable address), or configured through a local or remote mapping table.
PCEは、のPCCは、それを正しく識別し、パスセグメントにPKSを拡大するPCReqメッセージを送信できるように、それが作成各PKSにPCE-ID値を設定する必要があります。 PCEの実装は、PCE-IDとして使用する値のオペレータまたはポリシー制御を可能にすべきです。 PCEは、ルーティング可能なアドレスを使用すべきではないPCE-ID値を許可されている場合、のPCCはのPCCは、PCEのルーティング可能なアドレスにPCE-IDからマッピングできるように構成可能（オペレータまたはポリシーによって）でなければなりません。そのようなマッピングは、アルゴリズム（例えば、PCE-ID IGPルータIDに等しいルーティング可能なアドレスへのマッピング）手続き、またはローカルまたはリモートのマッピングテーブルを構成することができます。
A MIB module for PCEP is already defined in [PCEP-MIB]. The configurable items listed in Section 6.1 MUST be added as readable objects in the module and SHOULD be added as writable objects.
PCEPのためのMIBモジュールは、すでに[PCEP-MIB]で定義されています。セクション6.1に記載されている設定項目は、モジュール内可読オブジェクトとして追加する必要があり、書き込み可能オブジェクトとして追加されるべきです。
A new MIB module MUST be created to allow inspection of path-keys. For a given PCE, this MIB module MUST provide a mapping from path-key to path segment (that is, a list of hops), and MUST supply other information including:
新しいMIBモジュールは、パス・キーの検査を可能にするために作成する必要があります。与えられたPCEのために、このMIBモジュールは、経路セグメント（即ち、ホップのリストである）へのパスキーのマッピングを提供しなければなりません、とを含む他の情報を供給しなければなりません。
- The identity of the PCC that issued the original request that led to the creation of the path-key.
- パス・キーの創出につながっ元の要求を発行したPCCのアイデンティティ。
- The request ID of the original PCReq.
- 元PCReqの要求ID。
- Whether the path-key has been retrieved yet, and if so, by which PCC.
- パスキーがもしそうであれば、どのPCCによってまだ取り出され、そしてされているかどうか。
- How long until the path segment associated with the path-key will be discarded.
- どのように長いパス・キーに関連付けられたパスセグメントが破棄されますまで。
- How long until the path-key will be available for re-use.
- どのくらいまでのパス・キーが再使用できるようになります。
The procedures in this document extend PCEP, but do not introduce new interactions between network entities. Thus, no new liveness detection or monitoring is required.
このマニュアルの手順は、PCEPを拡張しますが、ネットワークエンティティ間の新たな相互作用を導入していません。このように、新たな生存性の検出や監視が必要とされません。
It is possible that a head-end LSR that has be given a path including PKSs replacing specific CPSs will want to know whether the path-keys are still valid (or have timed out). However, rather than introduce a mechanism to poll the PCE that is responsible for the PKS, it is considered pragmatic to simply signal the associated LSP.
のPKSは、特定のCPSSを交換するなど、パスが与えられたヘッドエンドLSRは、パス・キーがまだ有効である（またはタイムアウトした）をするかどうかを知りたいということも可能です。しかし、PKSを担当してPCEをポーリングする仕組みを導入するのではなく、単に関連するLSPを通知するために実用的と考えられています。
The procedures in this document extend PCEP, but do not introduce new interactions between network entities. Thus, no new tools for verifying correct operation are required.
このマニュアルの手順は、PCEPを拡張しますが、ネットワークエンティティ間の新たな相互作用を導入していません。このように、正しい動作を検証するための新しいツールは必要ありません。
A PCE SHOULD maintain counters and logs of the following events that might indicate incorrect operation (or might indicate security issues).
PCEは、間違った操作を示している可能性があります（またはセキュリティ上の問題を示す場合があります）次のイベントのカウンタやログを維持する必要があります。
- Attempts to expand an unknown path-key.
- 未知のパスキーを拡張しようとします。
- Attempts to expand an expired path-key.
- 期限切れのパス・キーを拡張しようとします。
- Duplicate attempts to expand the same path-key.
- 重複は、同じパスキーを拡張しようとします。
- Expiry of path-key without attempt to expand it.
- それを拡大しようとすることなく、パス・キーの有効期限。
The procedures described in this document require that the LSRs signal PKSs as defined in [RSVP-PKS]. Note that the only changes to LSRs are at the PCCs. Specifically, changes are only needed at the head-end LSRs that build RSVP-TE Path messages containing Path-Key Subobjects in their EROs, and the LSRs that discover such subobjects as next hops and must expand them. Other LSRs in the network, even if they are on the path of the LSP, will not be called upon to process the PKS.
この文書に記載された手順は、[RSVP-PKS]で定義されるのLSRがのPKSを知らせることを要求します。 LSRへの変更のみでのPCCであることに注意してください。具体的には、変更が唯一のRSVP-TEのパスpath-キー彼らのエロスでサブオブジェクトを含むメッセージ、およびネクストホップなどのサブオブジェクトを発見し、それらを展開する必要がありますのLSRを構築するヘッドエンドのLSRで必要とされています。彼らはLSPの経路上にある場合でも、ネットワーク内の他のLSRは、PKSを処理するために呼び出されることはありません。
As well as the security and confidentiality aspects addressed by the use of the PKS, there may be some scaling benefits associated with the procedures described in this document. For example, a single PKS in an explicit route may substitute for many subobjects and can reduce the overall message size correspondingly. In some circumstances, such as when the explicit route contains multiple subobjects for each hop (including node IDs, TE link IDs, component link IDs for each direction of a bidirectional LSP, and label IDs for each direction of a bidirectional LSP) or when the LSP is a point-to-multipoint LSP, this scaling improvement may be very significant.
同様に、セキュリティと機密性の側面がPKSの使用によって対処として、このドキュメントで説明する手順に関連したいくつかのスケーリングメリットがあるかもしれません。例えば、明示的経路における単一PKSは、多くのサブオブジェクトを置換することができ、それに対応し、メッセージ全体のサイズを小さくすることができます。そのような明示的な経路が（双方向LSPの各方向のためのノードID、TEリンクIDが、双方向LSPの各方向成分リンクID、ラベルIDを含む）各ホップのために複数のサブオブジェクトが含まれている場合などのいくつかの状況、または場合LSPがポイントツーマルチポイントLSPであり、このスケーリングの改善は非常に重要であり得ます。
Note that a PCE will not supply a PKS unless it knows that the LSR that will receive the PKS through signaling will be able to handle it. Furthermore, as noted in Section 6.5, only those LSRs specifically called upon to expand the PKS will be required to process the subobjects during signaling. Thus, the only backward compatibility issues associated with the procedures introduced in this document arise when a head-end LSR receives a PCRep with an ERO containing a PKS, and it does not know how to encode this into signaling.
それは、シグナリングを通じてPKSを受けるLSRはそれを処理できるようになることを知っていない限り、PCEは、PKSを供給しないことに注意してください。セクション6.5で述べたようにまた、具体的PKSを展開する際に呼び出さのみのLSRは、シグナリング中にサブオブジェクトを処理するために必要とされるであろう。したがって、ヘッドエンドLSRは、PKSを含むEROとPCRepを受信した場合、この文書に導入手順に関連する唯一の後方互換性の問題が生じ、それがシグナル伝達にこれをエンコードする方法を知りません。
Since the PCE that inserted the PKS is required to keep the CPS confidential, the legacy head-end LSR cannot be protected. It must either fail the LSP setup, or request a new path computation avoiding the domain that has supplied it with unknown subobjects.
PKSを挿入PCEが機密CPSを維持するために必要とされているので、従来のヘッドエンドLSRは保護できません。これは、LSPのセットアップに失敗、または未知のサブオブジェクトとそれを供給しているドメインを避け、新たな経路計算を要求する必要があります。
IANA assigns values to PCEP parameters in registries defined in [RFC5440]. IANA has made the following additional assignments.
IANAは[RFC5440]で定義されたレジストリにPCEPパラメータに値を割り当てます。 IANAは、次の追加割り当てを行っています。
IANA has previously assigned an Object-Class and Object-Type to the ERO carried in PCEP messages [RFC5440]. IANA also maintains a list of subobject types valid for inclusion in the ERO.
IANAは、以前のオブジェクトクラスを割り当てられ、オブジェクトタイプをPCEPメッセージ[RFC5440]で運ばEROにしています。 IANAはまた、EROに含めるための有効なサブオブジェクトタイプのリストを保持しています。
IANA assigned two new subobject types for inclusion in the ERO as follows:
次のようにIANAはEROに含めるための2つの新しいサブオブジェクトタイプを割り当てます：
Subobject Type Reference 64 Path-Key with 32-bit PCE ID [RFC5520] 65 Path-Key with 128-bit PCE ID [RFC5520]
サブオブジェクトタイプ参照64、32ビットのPCEのIDとパスキー[RFC5520] 128ビットのPCEのID 65パスキー[RFC5520]
IANA assigned a new object class in the registry of PCEP Objects as follows.
IANAは、次のようにPCEPオブジェクトのレジストリに新しいオブジェクトクラスを割り当てます。
Object Name Object Name Reference Class Type
オブジェクト名オブジェクト名リファレンスクラス型
16 PATH-KEY 1 Path-Key [RFC5520]
16 PATH-KEY 1つのパス・キー[RFC5520]
Subobjects
This object may carry the following subobjects as defined
for the ERO object.
64 Path-Key with 32-bit PCE ID [RFC5520]
65 Path-Key with 128-bit PCE ID [RFC5520]
IANA maintains a registry of bit flags carried in the PCEP RP object as defined in [RFC5440]. IANA assigned a new bit flag as follows:
[RFC5440]で定義されるようにIANAは、PCEPのRPオブジェクトで運ばビットフラグのレジストリを維持します。次のようにIANAは、新たなビットフラグを割り当てます：
Bit Number Hex Name Reference 23 0x000017 Path-Key (P-bit) [RFC5520]
ビット数六角名リファレンス23 0x000017パスキー（Pビット）[RFC5520]
IANA maintains a registry of bit flags carried in the PCEP NO-PATH-VECTOR TLV in the PCEP NO-PATH object as defined in [RFC5440]. IANA assigned a new bit flag as follows:
[RFC5440]で定義されるようにIANAは、PCEP NOパスオブジェクトにPCEP NO-PATHベクターTLVで搬送されるビットフラグのレジストリを維持します。次のようにIANAは、新たなビットフラグを割り当てます：
Bit Number Name Flag Reference 27 PKS expansion failure [RFC5520]
ビット番号名前旗リファレンス27のPKS拡張不全[RFC5520]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、編、およびJL。ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコル（PCEP）"、RFC 5440、2009年3月。
[PCEP-MIB] Koushik, K., and E. Stephan, "PCE Communication Protocol (PCEP) Management Information Base", Work in Progress, November 2008.
[PCEP-MIB]コウシク、K.、およびE.ステファン、 "PCE通信プロトコル（PCEP）管理情報ベース"、進歩、2008年11月の作業。
[RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", Work in Progress, November 2008.
[RBNF]ファレル、A.は、進歩、2008年11月の作業「バッカス記法（RBNF）各種プロトコル仕様書で使用される構文を削減します」。
[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。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]ル・ルー、J.-L.、エド。、Vasseur、J.-P.、エド。、およびJ.ボイル、エド。、 "エリア間MPLSトラフィックエンジニアリングのための要件"、RFC 4105、2005年6月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]張、R.、編、及びJ.-P. Vasseur、エド。、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（TE）の要件"、RFC 4216、2005年11月。
[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月。
[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, February 2008.
[RFC5152] Vasseur、JP。、エド。、Ayyangar、A.編、およびR.張は、 "ドメイン単位の経路計算方法のために確立するドメイン間トラフィックエンジニアリング（TE）ラベル（LSPを）パスの交換しました"、 RFC 5152、2008年2月。
[RFC5298] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP. Vasseur, "Analysis of Inter-Domain Label Switched Path (LSP) Recovery", RFC 5298, August 2008.
[RFC5298]武田、T.、エド。、ファレル、A.編、池尻、Y.、およびJP。 Vasseur、RFC 5298、2008年8月 "ドメイン間ラベルスイッチパス（LSP）の回復の分析"。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441] Vasseur、JP。、編、張、R.、ビタール、N.、およびJL。ル・ルー、RFC 5441、2009年4月「最短拘束ドメイン間トラフィックエンジニアリングラベルを計算するために下位再帰PCEベースの計算（BRPC）手順は、パスの交換しました」。
[RSVP-PKS] Bradford, R., Vasseur, JP., and A. Farrel, "RSVP Extensions for Path Key Support", Work in Progress, February 2008.
[RSVP-PKS]ブラッドフォード、R.、Vasseur、JP。、およびA.ファレル、 "パスキーのサポートのためのRSVP拡張機能"、進歩、2008年2月に作業。
Acknowledgements
謝辞
The authors would like to thank Eiji Oki, Ben Campbell, and Ross Callon for their comments on this document.
作者はこのドキュメントの彼らのコメントのために大木英司、ベン・キャンベル、およびロスCallonに感謝したいと思います。
Authors' Addresses
著者のアドレス
Rich Bradford (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: rbradfor@cisco.com
リッチブラッドフォード（編集）、シスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA Eメール：rbradfor@cisco.com
JP. Vasseur Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
JP。 Vasseurシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA Eメール：jpv@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk