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
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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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跨越多个域（例如自治系统（ase））的情况下，路径可以由多个pce计算，每个pce负责计算路径的一段。然而，在某些情况下（例如，当ASE由单独的服务提供商管理时），PCE向另一个域中的PCE提供路径段将违反保密规则，从而作为内部拓扑信息公开。当信令消息进入第二域时，通过返回一个松散跳数和在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
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).
[RFC4655]中描述了使用路径计算元素（PCE）的路径计算技术，允许域间多协议标签交换（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的一个重要元素是，由于可伸缩性和机密性原因（[RFC4105]和[RFC4216]），TE信息不在域之间共享。因此，单个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可使用两种路径计算方案：一种使用每域路径计算（在[RFC5152]中定义），另一种使用基于PCE的路径计算技术并在PCE之间协作（如[RFC4655]中所述）。在第二种情况下，域间lsp的路径可以通过pce之间的协作来计算，每个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）之间很可能存在这种情况），则合作的PCE不能交换路径段，或者接收PCE和路径计算客户端（PCC）将能够通过另一个域查看单个跃点，从而打破[RFC4105]和[RFC4216]中规定的保密要求。我们将路径中希望保密的部分定义为机密路径段（CP）。
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].
保护CP机密性的一种机制是PCE返回一个包含松散跃点的路径来代替必须保密的段。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
在不进一步扩展PCEP或信令协议的情况下，可以实现返回一个松散跃点代替CPS的选项。如果使用松散跃点，则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].
在域边界（即区域边界路由器（ABR）或AS边界路由器（ASBR））处标记交换路由器（LSR），并按照[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独立地进行，因此无法保证不相交的路径，因为负责扩展显式路由对象（ero）的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.
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.translate error, please retry
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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之间的一个或多个链接连接到不同或相同服务提供商的另一个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：跨越AS边界的TE LSP。
LSR: Label Switching Router.
标签交换路由器。
LSP: Label Switched Path.
标签交换路径。
PCC: Path Computation Client: Any client application requesting a path computation to be performed by a Path Computation Element.
路径计算客户端：任何请求路径计算元素执行路径计算的客户端应用程序。
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计算与特定域相关的路径段，并用称为PKSE的一个或多个子对象替换报告给请求PCC（或另一PCE）的路径中的任何CP。每个CP的入口边界LSR应使用其TE路由器Id作为CPS前面的返回路径中的一个跃点来指定，其他子对象可包括在识别边界LSR的跃点之前的路径中，以指示链路和标签选择。在顺序提供两个pkse且没有中间节点的情况下，第二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
在路径计算期间，当本地策略规定必须为正在计算的全部或部分路径段保留机密性时，或者如果路径计算请求明确请求，则PCE将路径密钥与CP的计算路径相关联，放置其自己的标识符（其PCE ID如第3.1节所定义）与PKS中的路径密钥一起，并在返回到请求PCC或PCE的路径中插入PKS对象，该路径紧随子对象之后，该子对象标识（使用TE路由器Id）将PKS扩展为显式路径跃点的LSR。这通常是作为CPS起点的LSR。生成PKS的PCE应存储计算出的路径段和路径密钥，以供以后检索。应使用本地策略来确定保存此类文件的时间
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将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分钟内重复使用路径密钥值来表示新CP。在重启过程中无法保留有关先前使用的路径键值的信息的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中。与任何其他子对象一样，PKS从一个跃点透明地传递到另一个跃点，直到它成为ERO中的第一个子对象。这将发生在CPS的开始，通常是域边界。PKS前面必须有一个ERO子对象，该子对象标识必须扩展PKS的LSR。这意味着（遵循[RFC3209]中规定的ERO处理规则）在ERO处理过程中不会遇到PKS，直到能够正确处理PKS的LSR处理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，并将[RFC5440]中定义的路径计算请求（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,
图1显示了一个简单的双AS拓扑，其中一个PCE负责每个AS中的路径计算。从一个AS中的入口LSR向另一个AS中的出口LSR请求LSP。入口作为PCC向PCE-1发送路径计算请求。PCE-1无法计算端到端路径并调用PCE-2（可能使用[RFC5441]中描述的技术）。PCE-2将从ASBR-2到出口的路径段计算为{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.
出口}。它可以将此路径段完整地传递回PCE-1，也可以将路径{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}.
然而，为了保护第二AS中拓扑的机密性，同时仍然完整地指定路径，PCE-2可以向PCE-1发送表示为{ASBR-2，PKS，express}的路径段，其中PKS是本文档中定义的路径键子对象。在这种情况下，PCE-2将段{ASBR-2，C，D，出口}标识为机密路径段（CPS）。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使用PKS中的信息请求PCE-2获取路径段，PCE-2将返回段{ASBR-2，C，D，出口}，允许信令继续设置LSP。
----------------------------- ----------------------------
| ------- | | ------- |
| | PCE-1 |<---------------+--+-->| PCE-2 | |
| ------- | | ------- |
| ^ | | ^ |
| | | | | |
| v | | v |
| ------- ---- | | ---- |
| | PCC | - - |ASBR| | | |ASBR| - - ------ |
| |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| |
| ------- - - ----- | | ---- - - ------ |
| | | |
----------------------------- ----------------------------
----------------------------- ----------------------------
| ------- | | ------- |
| | 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上下文中的CP。PCE-ID标识可以使用PCE服务的域中唯一的标识符解码路径键的PCE。PCE-ID必须由CPS的第一个节点（通常是域边界路由器）映射到PCE的可访问IPv4或IPv6地址，PCE可以使用其可访问IP地址之一作为其PCE-ID。或者，根据域本地策略，并提供更高的安全性（见第5节）或更高的机密性，PCE可以使用仅在域内限定范围的某些其他标识符。
To allow IPv4 and IPv6 addresses to be carried, two subobjects are defined in the following subsections.
为了允许携带IPv4和IPv6地址，在以下小节中定义了两个子对象。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
不应设置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位标识符。该标识符在CP跨越的域范围内必须是唯一的，并且必须被作为PKS扩展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) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
可以解码此路径密钥的PCE的128位标识符。该标识符必须在CP跨越的域范围内是唯一的，并且必须被该域的LSR理解
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).
将作为PKS扩建的PCC。PCE-ID的解释受域本地政策的约束。它可以是始终可访问的PCE的IPv6地址，但也可以是被调用以扩展CP的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与PKS的扩展相关，并定义了一个新的对象以在PCReq中携带PKS。这些将导致消息的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.
路径密钥位：设置后，请求PCC需要检索与路径计算请求中路径密钥对象中携带的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.
路径键对象类为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.
路径键对象必须至少包含一个路径键子对象（请参见第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>
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<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>的定义修改如下：
<request>::= <RP>
<segment-computation> | <path-key-expansion>
<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>
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识别自身，但无法找到相关CP，或者如果策略不允许检索CP，则PCE必须发送包含NO-PATH对象的PCRep消息。应按照[RFC5440]中的说明使用无路径向量TLV，并分配一个新的位号（见第7.4节）以指示“无法扩展PKS”。
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?).
- CP的机密性（其他网元是否可以探测路径密钥的扩展，可能是随机的？）。
- 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响应
- 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并插入或修改路径键。这将导致LSR（位于ERO的下游）向PCE发送解码请求。这实际上是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可以发出随机解码请求，但这些请求只相当于拒绝服务。
- 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地址，或者某些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.
将路径段作为CP处理，并在PCRep ERO中用PKS替换路径段，这是一项必须由操作员和策略控制的功能，其中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扩展的操作要求发行PCE保留路径密钥，以便LSR（充当PCC）在以后检索。但是可能永远不会发出检索请求，因此良好的内务管理需要运行计时器来丢弃不需要的路径键。第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被扩展以响应检索请求后，保留路径键和CP以进行调试可能是有价值的。这种保留不应该是实现的默认行为，但可以在响应操作员请求时使用。
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.
一旦路径密钥被丢弃，路径密钥值不应立即可用于新CP，因为这可能会导致意外误用。第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必须在其创建的每个PK中设置PCE-ID值，以便PCC能够正确识别它并发送PCReq消息以将PK扩展到路径段。PCE实施应允许操作员或策略控制用作PCE-ID的值。如果PCE允许使用非可路由地址的PCE-ID值，则PCC必须可配置（由操作员或通过策略）以允许PCC从PCE-ID映射到PCE的可路由地址。这种映射可以是算法的、程序的（例如，将等于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:
必须创建新的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.
有可能，已被赋予包含替换特定CP的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.
本文件中描述的程序要求LSRs信号PKS符合[RSVP-PKS]中的定义。请注意，对LSR的唯一更改是在PCC。具体地说，只需要在头端LSR处进行更改，该头端LSR在其ERO中构建包含路径键子对象的RSVP-TE路径消息，以及在下一跳中发现此类子对象并必须展开这些子对象的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，除非它知道通过信令接收PKS的LSR能够处理它。此外，如第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中，如下所示：
Subobject Type Reference 64 Path-Key with 32-bit PCE ID [RFC5520] 65 Path-Key with 128-bit PCE ID [RFC5520]
具有32位PCE ID的子对象类型参考64路径键[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路径键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]
具有32位PCE ID的64路径键[RFC5520]具有128位PCE ID的65路径键[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]
位号十六进制名称参考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:
IANA维护[RFC5440]中定义的PCEP NO-PATH对象中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]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 54402009年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通信协议（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）语法”，正在进行的工作，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，2001年12月。
[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.，“区域间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]Zhang，R.，Ed.，和J.-P.Vasseur，Ed.，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年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 46552006年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 54412009年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，“路径键支持的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号邮编01719电子邮件：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号邮编01719电子邮件：jpv@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk