[要約] 要約： RFC 5520は、異なるドメイン間のパス計算において、パスキーに基づくメカニズムを使用してトポロジの機密性を保護するための標準を提案しています。目的： このRFCの目的は、異なるドメイン間のパス計算において、トポロジ情報の機密性を保護するための効果的なメカニズムを提供することです。
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.
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の法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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が自律システム（ASES）などの複数のドメインを通過する場合、パスは、それぞれがパスのセグメントを計算する責任を負う複数のPCEによって計算されます。ただし、場合によっては（たとえば、ASEが個別のサービスプロバイダーによって管理される場合）、PCEの機密性ルールを破り、別のドメインのPCEにパスセグメントを供給し、内部トポロジ情報を開示します。この問題は、ルーズホップを返すことと、TE LSPセットアップ中にドメイン境界ラベルスイッチングルーター（LSR）から新しいパス計算を呼び出すことにより、シグナリングメッセージが2番目のドメインに入ることで回避できますが、この手法には、の問題を含むいくつかの問題があります。パスの多様性を維持します。
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）明示的ルートオブジェクト内で信号を送信できるPath-Keyに置き換えられる場合があります。
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].
2つのパス計算シナリオは、ドメイン間TE LSPに使用できます。1つはドメインごとのパス計算（[RFC5152]で定義）を使用し、もう1つはPCE間の協力を伴うPCEベースのパス計算手法を使用します（[RFC4655で説明されています。]）。この2番目のケースでは、ドメイン間LSPのパスは、それぞれが1つのドメインを横切るパスのセグメントを計算する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).
ドメイン間で機密性が必要である場合（異なるサービスプロバイダーに属する自律システム（ASE）間で非常に可能性が高いなど）、協力PCESはパスセグメントを交換できない場合、または受信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].
CPSの機密性を維持するためのメカニズムの1つは、PCEが機密保持する必要があるセグメントの代わりにゆるいホップを含むパスを返すことです。TE LSPのルートに対するゆるい厳格なホップの概念は、[RFC3209]に記載されています。[RFC5440]で定義されているパス計算要素通信プロトコル（PCEP）は、ルーズホップを使用したパスの使用をサポートします。これは、Strict Hopsで完全に明示的なパスを返すか、ルーズホップを使用するかどうかは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 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].
CPSの代わりにゆるいホップを返すオプションは、PCEPまたはシグナリングプロトコルをさらに拡張せずに達成できます。ルーズホップを使用する場合、TE LSPは通常のように信号され（[RFC3209]）、明示的なルートでルースホップが発生した場合、セカンダリパス計算を実行して識別されるリソースまたはリソースのセットに到達することで解決されます。ルーズホップ。元のパスを計算する際のPCE間の協力の性質を考えると、この二次計算は、ドメイン境界（つまり、領域境界ルーター（ABR）またはAS Border Router）でラベルスイッチングルーター（LSR）に代わって発生します。ASBR））および[RFC5152]に記載されているように、パスが拡張されます。
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について独立して進行するため、LSRSがLSRSが入力するため、分離パスは保証できません。明示的なルートオブジェクト（ERO）を拡張する充電は同期されていません。したがって、ルーズホップテクニックがそれ以上拡張せずに使用されている場合、パスセグメントの機密性とパスの多様性は相互に互換性のない要件です。
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.
このドキュメントは、明示的なルートのパスセグメントを置き換えるトークンであるパスキーの概念を定義します。Path-Keyは、PCEP PATH COMPUTATION REPLYメッセージ（PCREP）（[RFC5440]）で返されたPath-Key Subobject（PKS）としてエンコードされます。計算されたパスを受信すると、PKSはシグナリング中にRSVP-TEパスメッセージ（RSVP-TE [RFC3209]および[RSVP-PK]）で運ばれます。
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：ASE間の1つ以上のリンクを介して、異なるまたは同じサービスプロバイダーのように別のまたは同じサービスプロバイダーに接続するために使用される自律システムのボーダールーター。
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.
Inter-as te lsp：境界を横切るte lsp。
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は、特定のドメインに関連するパスセグメントを計算し、PKSと呼ばれる1つ以上のサブオブジェクトを要求するPCC（または別のPCE）に報告されたパス内のCPSを置き換えます。各CPSのエントリ境界LSRは、CPSの直前の返されたパスのホップとしてTEルーターIDを使用して指定する必要があります。また、ホップの直前に他のサブオブジェクトが境界LSRを識別してリンクとラベルの選択を示すためにパスに含めることができます。。2つのPKSが介在するノードなしで順番に供給されている場合、2番目のCPSへのエントリノードは最初のCPSの一部であり、返されたパスに明示的に存在する必要はありません。CPSの出口ノードは、PKの直後に厳密なホップとして存在する場合があります。
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の計算パスに関連付けます。セクション3.1で定義されているPCE ID）とPKSのパスキーとともに、識別するサブオブジェクトの直後にリクエストPCCまたはPCCに返されたパスにPKSオブジェクトを挿入します（TEルーターIDを使用）PKを明示的なパスホップに拡張するLSR。これは通常、CPSの出発点であるLSRになります。PKSを生成するPCEは、計算されたパスセグメントとパスキーを後で検索するために保存する必要があります。ローカルポリシーを使用して、そのような保存された情報を保持する時間を決定し、以下に説明する手順を使用して質問された後に情報を破棄するかどうかを決定する必要があります。PCEがPKSを10分間保存することをお勧めします。
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は、PCEによって返されたパスを、リソース予約プロトコル（RSVP）パスメッセージに含まれる明示的なルートオブジェクト（ERO）に変換します。PCEによって返されるパスにPKSが含まれている場合、これはEROに含まれています。他のサブオブジェクトと同様に、PKはEROの最初のサブオブジェクトになるまで、ホップからホップまで透過的に渡されます。これは、CPSの開始時に発生します。これは通常、ドメイン境界になります。PKSの前に、PKを拡張する必要があるLSRを識別するEROサブオブジェクトが必要です。これは、（[RFC3209]に記載されているERO処理の規則に従って）PKSがPKSを正しく処理できるLSRによって処理されるまで、ERO処理でPKSが発生しないことを意味します。
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を取得し、[RFC5440]で定義されているPATH計算要求（PCREQ）メッセージをパスを含むPCE-IDで識別するPCEに送信します。 - キーオブジェクト。
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, 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.
図1は、それぞれのASのパス計算に関与するPCEを備えた単純な2つのASトポロジーを示しています。ingress LSRから、もう1つのASの出力LSRに関してLSPが要求されます。PCCとして機能するイングレスは、PCE-1にパス計算要求を送信します。PCE-1はエンドツーエンドパスを計算できず、PCE-2を呼び出します（おそらく[RFC5441]で説明されている手法を使用します）。PCE-2は、ASBR-2から出口へのパスセグメントを{ASBR-2、C、D、出口}として計算します。このパスセグメントを完全に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}.
ただし、パスを完全に指定している間、2番目のトポロジーの機密性を保護するために、PCE-2はPCE-1に{ASBR-2、PKS、出口}として表されるパスセグメントを送信する場合があります。このドキュメントで定義されているPath-Key Subobject。この場合、PCE-2は、セグメント{ASBR-2、C、D、出口}を機密パスセグメント（CPS）として特定しました。PCE-1は、責任があるパスセグメントを計算し、{ingress、a、b、asbr-1、asbr-2、pks}としてPCCへのフルパスを供給します。
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.
シグナリングは通常どおりに最初に進行しますが、パスメッセージがASBR-2に到達すると、次のホップはPKSであり、これはシグナリングがさらに進行する前に拡張する必要があります。ASBR-2はPKSの情報を使用してパスセグメントのPCE-2を要求すると、PCE-2はセグメント{ASBR-2、C、D、Egress}を返し、シグナリングがLSPを設定し続けることができます。
----------------------------- ----------------------------
| ------- | | ------- |
| | 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の使用を示す簡単なネットワーク
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メッセージで運ばれます。特に、Path-Keyは、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を含む固定長のサブオブジェクトです。Path-Keyは識別子である、またはPCE-IDによって識別されたPCEのコンテキスト内でCPSを表すために使用されるトークンです。PCE-IDは、PCEが提供するドメイン内で一意の識別子を使用してパスキーをデコードできるPCEを識別します。PCE-IDは、CPSの最初のノード（通常はドメイン境界ルーター）によってPCEの到達可能なIPv4またはIPv6アドレスにマッピングする必要があり、PCEはその到達可能なIPアドレスの1つをPCE-IDとして使用する場合があります。または、ドメインローカルポリシーに従って、より大きなセキュリティ（セクション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パスキーオブジェクトに存在する場合があります（セクション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
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 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が交差するドメインの範囲内で一意でなければならず、PKの拡張のためにPCCとして機能するLSRによって理解されなければなりません。PCE-IDの解釈は、ドメインローカルポリシーの対象となります。これは、常に到達可能なPCEのIPv4アドレスである可能性があり、CPSを拡張するために呼び出されるLSRがあるドメインに限定されているアドレスである可能性があります。ドメイン外に意味がない他の値（たとえば、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
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が交差するドメインの範囲内で一意でなければならず、PKの拡張のためにPCCとして機能するLSRによって理解されなければなりません。PCE-IDの解釈は、ドメインローカルポリシーの対象となります。これは、常に到達可能なPCEのIPv6アドレスである可能性がありますが、CPSを拡張するために呼び出されるLSRがあるドメインに制限されているアドレスである可能性があります。ドメイン外に意味がない他の値（たとえば、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がPKの拡張に関連していることを示すために新しいフラグが定義され、PCREQにPKを運ぶために新しいオブジェクトが定義されています。これらの結果、メッセージのBNFの更新が行われます。このドキュメントで使用されているBNFは、[RBNF]で説明されているとおりです。
[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.
Path-Key Bit：設定すると、要求するPCCには、パス計算要求のパスキーオブジェクトに配置されたPKに対応する機密パスセグメントの取得が必要です。パス計算要求が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を拡張するためにPath-Keyを拡張する必要がある場合、RSVP-TE EROのPKSで識別されたPCE（PCREQ）が処理されていることを発行します。PCCは、PCREQメッセージのパスキーオブジェクトに拡張されるPKSを提供します。
The PATH-KEY Object is defined as follows:
パスキーオブジェクトは次のように定義されています。
PATH-KEY Object-Class is 16.
Path-Keyオブジェクトクラスは16です。
Path-Key Object-Type is 1.
Path-Key Object-Typeは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.
パスキーオブジェクトには、少なくとも1つのパスキーサブオブジェクトを含める必要があります（セクション3.1を参照）。最初のPKは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を拡張するために、<quest>の定義は次のように変更されます。
<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メッセージにRPオブジェクトのパスキーオブジェクトとパスキービットを含める必要があることを除き、他のパス計算要求と違いはありません設定する必要があります。CPSを含むPCREPを受け取ったとき、要求するPCCは、ローカルポリシーに従って、CPSをEROに挿入する必要があります。
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.
受信PCEがPKSで運ばれたPCE IDによって識別されたと認識されない場合、ローカルポリシーに従ってPCREQメッセージを別のPCEに転送する場合があります。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はパスなしオブジェクトを含むPCREPメッセージを送信する必要があります。[RFC5440]に記載されているように、NO-PATH-VECTOR TLVを使用する必要があり、新しいビット番号（セクション7.4を参照）は、「PKを拡張できない」を示すために割り当てられます。
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).
- パスキーの信ity性（仲介者による変更への回復力、パスキーの偽の拡大に対する回復力）。
- 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応答
- 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リクエストと応答。Rogue LSRはEROを変更し、Path-Keysを挿入または変更できることに注意してください。これにより、LSR（EROの下流）がPCEにデコードリクエストを送信します。これは実際にはRSVPの大きな問題です。Rogue 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がPath-Keyの頭のLSRであることを確認できることに注意してください。これには、セキュリティの問題ではなく、DOSの以前の問題が主に含まれています。Rogue 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.
PCE IDを使用して、CPSのヘッドにLSRを含むドメイン内でのみ意味のあるデコードPCEを識別することにより、さらなる保護を提供できます。これは、ドメイン内からのみ到達可能なIPアドレス、または一部の非アドレス値です。前者はPCES上のポリシーの構成を必要とし、後者はドメイン全体のポリシーを必要とします。
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.
パスセグメントのCPSとしての処理、およびPKSを使用したPCREP EROでのその置換は、PCEが関数をサポートする場合のオペレーターとポリシーコントロールの下にある必要がある関数です。オペレーターには、どのパスセグメントを交換するか、どのような状況下で指定することができなければなりません。たとえば、オペレーターは、PCREQがドメインの外部から発行されたときに、オペレーターのドメインのすべてのパスセグメントがPKに置き換えることを示すポリシーを設定する場合があります。
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拡張機能の動作では、発行PCHEが発行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.
PCCが作成する各PKにPCE-ID値を設定して、PCCSがそれを正しく識別し、PCREQメッセージを送信してPKSをパスセグメントに拡張できるようにする必要があります。PCE実装により、値のオペレーターまたはポリシー制御がPCE-IDとして使用されるようにする必要があります。PCEがルーティング可能なアドレスを使用しないPCE-ID値を使用する場合、PCCSがPCC-IDからPCEのルーティング可能なアドレスにマッピングできるように、PCCSは（オペレーターまたはポリシーを使用して）構成可能でなければなりません。このようなマッピングは、アルゴリズム、手順（たとえば、IGPルーターIDに等しいPCE-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:
Path-Keysの検査を許可するために、新しい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.
- Path-Keyがまだ取得されているかどうか、もしそうなら、どの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を拡張しますが、ネットワークエンティティ間の新しい相互作用を導入しません。したがって、新しいlivenessの検出または監視は必要ありません。
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.
特定のCPSを置き換えるPKSを含むパスを与えられたヘッドエンド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-PK]で定義されているLSRS信号PKSが必要です。LSRの唯一の変更はPCCSにあることに注意してください。具体的には、エロにパスキーサブオブジェクトを含むRSVP-TEパスメッセージを構築するヘッドエンドLSRと、次のホップなどのサブオブジェクトを発見し、それらを拡張する必要があるLSRで変更が必要です。ネットワーク内の他のLSRは、たとえLSPの経路にあったとしても、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の使用によって対処されるセキュリティおよび機密性の側面に加えて、このドキュメントで説明されている手順に関連するいくつかのスケーリングの利点があるかもしれません。たとえば、明示的なルートの単一のPKは、多くのサブオブジェクトに代わるものであり、それに応じてメッセージ全体を減らすことができます。明示的なルートに各ホップの複数のサブオブジェクト（ノードID、TEリンクID、双方向LSPの各方向のコンポーネントリンクID、および双方向LSPの各方向の各方向のラベル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.
PCEは、シグナリングを通じてPKSを受け取るLSRがそれを処理できることを知らない限り、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]を備えたパスキー[RFC5520] 65 128ビットPCE ID [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パスキー1パスキー[RFC5520]
Subobjects This object may carry the following subobjects as defined for the ERO object.
サブオブジェクトこのオブジェクトは、EROオブジェクトに対して定義されているように、次のサブオブジェクトを運ぶ場合があります。
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 [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:
IANAは、[RFC5440]で定義されているように、PCEP RPオブジェクトに運ばれるビットフラグのレジストリを維持しています。IANAは次のように新しいビットフラグを割り当てました。
Bit Number Hex Name Reference
23 0x000017 Path-Key (P-bit) [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:
IANAは、[RFC5440]で定義されているように、PCEP No-PathオブジェクトのPCEP No-Path-Vector TLVで運ばれるビットフラグのレジストリを維持しています。IANAは次のように新しいビットフラグを割り当てました。
Bit Number Name Flag Reference
27 PKS expansion failure [RFC5520]
[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月。
[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月。
[PCEP-MIB] Koushik, K., and E. Stephan, "PCE Communication Protocol (PCEP) Management Information Base", Work in Progress, November 2008.
[PCEP-MIB] Koushik、K。、およびE. Stephan、「PCE Communication Protocol（PCEP）管理情報ベース」、2008年11月、進行中の作業。
[RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", Work in Progress, November 2008.
[RBNF] Farrel、A。、「さまざまなプロトコル仕様で使用される構文（RBNF）の縮小バックナウル形式（RBNF）、2008年11月、進行中の作業。
[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年。
[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] Le Roux、J.-L.、ed。、Vasseur、J.-P.、ed。、およびJ. Boyle、ed。、「A-A-Area MPLS Traffic Engineeringの要件」、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] Zhang、R.、ed。、およびJ.-P。Vasseur、ed。、「MPLS Inter-autonomous System（AS）Traffic Engineering（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] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（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。、ed。、Ayyangar、A.、ed。、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（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] Takeda、T.、Ed。、Farrel、A.、ed。、Ikejiri、Y。、およびJP。Vasseur、「ドメイン間標識スイッチ付きパス（LSP）回復の分析」、RFC 5298、2008年8月。
[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。、ed。、Zhang、R.、Bitar、N。、およびJl。Le Roux、「最短制約されたドメイン間トラフィックエンジニアリングラベルの切り替えパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、2009年4月。
[RSVP-PKS] Bradford, R., Vasseur, JP., and A. Farrel, "RSVP Extensions for Path Key Support", Work in Progress, February 2008.
[RSVP-PKS] Bradford、R.、Vasseur、JP。、およびA. Farrel、「Path Key Support for Path Key Support for RSVP拡張」、2008年2月の作業。
Acknowledgements
謝辞
The authors would like to thank Eiji Oki, Ben Campbell, and Ross Callon for their comments on this document.
著者は、この文書に関するコメントをしてくれたEiji Oki、Ben Campbell、Ross Callonに感謝したいと思います。
Authors' Addresses
著者のアドレス
Rich Bradford (Editor) 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
JP. Vasseur Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
JP。Vasseur Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA 01719 USAメール：jpv@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk