Network Working Group A. Farrel, Ed.
Request for Comments: 5553 Old Dog Consulting
Category: Standards Track R. Bradford
JP. Vasseur
Cisco Systems, Inc.
May 2009
Network Working Group A. Farrel, Ed.
Request for Comments: 5553 Old Dog Consulting
Category: Standards Track R. Bradford
JP. Vasseur
Cisco Systems, Inc.
May 2009
Resource Reservation Protocol (RSVP) Extensions for Path Key Support
用于路径密钥支持的资源预留协议（RSVP）扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path.
多协议标签交换（MPLS）和广义MPLS（GMPLS）流量工程（TE）标签交换路径（LSP）所采用的路径可由路径计算元件（PCE）计算。在TE-LSP跨越多个域（例如自治系统（ase））的情况下，路径可以由多个pce计算，每个pce负责计算路径的一段。
To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation.
为了保护每个AS内拓扑的机密性，PCE支持一种机制，通过将内容编码为路径密钥子对象（PKS）来隐藏路径段（如穿过AS的路径段）的内容，称为机密路径段（CPS）并将该子对象嵌入到其路径计算结果中。
This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs.
本文档描述了如何在资源预留协议（RSVP）显式路由对象（ERO）和记录路由对象（RRO）中携带路径密钥子对象，以促进域间TE LSP信令的机密性。
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) are signaled using the TE extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209], [RFC3473]. The routes followed by MPLS and GMPLS TE LSPs may be computed by Path Computation Elements (PCEs) [RFC4655].
多协议标签交换（MPLS）和通用MPLS（GMPLS）流量工程（TE）标签交换路径（LSP）使用资源预留协议（RSVP-TE）[RFC3209]，[RFC3473]的TE扩展发送信号。MPLS和GMPLS TE LSP遵循的路由可由路径计算元件（PCE）计算[RFC4655]。
Where the TE LSP crosses multiple domains [RFC4726], such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology with each AS, the PCE Communications Protocol (PCEP) [RFC5440] supports a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) [RFC5520].
在TE LSP跨越多个域[RFC4726]的情况下，例如自治系统（as），路径可以由多个pce计算，每个pce负责计算路径的一段。为了保护每个AS拓扑的机密性，PCE通信协议（PCEP）[RFC5440]支持一种机制，通过将内容编码为路径密钥子对象（PKS）[RFC5520]来隐藏称为机密路径段（CPS）的路径段的内容。
This document defines RSVP-TE protocol extensions necessary to support the use of Path Key Subobjects in MPLS and GMPLS signaling by including them in Explicit Route Objects (EROs) and Record Route Object (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs.
本文档定义了支持MPLS和GMPLS信令中使用路径密钥子对象所需的RSVP-TE协议扩展，方法是将它们包括在显式路由对象（ERO）和记录路由对象（RRO）中，以便于域间TE LSP信令的机密性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Figure 1 shows a simple network constructed of two ASes. An LSP is desired from the ingress in AS-1 to the egress in AS-2. As described in [RFC4655], the ingress Label Switching Router (LSR) acts as a Path Computation Client (PCC) and sends a request to its PCE (PCE-1). PCE-1 can compute the path within AS-1 but has no visibility into AS-2. So PCE-1 cooperates with PCE-2 to complete the path computation.
图1显示了由两个ASE构成的简单网络。从AS-1的入口到AS-2的出口需要LSP。如[RFC4655]所述，入口标签交换路由器（LSR）充当路径计算客户端（PCC），并向其PCE（PCE-1）发送请求。PCE-1可以计算AS-1内的路径，但对AS-2没有可见性。因此，PCE-1与PCE-2合作完成路径计算。
However, PCE-2 does not want to share the information about the path across AS-2 with nodes outside the AS. So, as described in [RFC5520], PCE-2 reports the AS-2 path segment using a PKS rather than the explicit details of the path.
但是，PCE-2不希望与AS之外的节点共享有关AS-2路径的信息。因此，如[RFC5520]所述，PCE-2使用PKS报告as-2路径段，而不是路径的明确细节。
PCE-1 can now return the path to be signaled to the ingress LSR in a path computation response with the AS-2 segment still hidden as a PKS.
PCE-1现在可以在路径计算响应中返回要发送信号给入口LSR的路径，AS-2段仍然隐藏为PKS。
In order to set up the LSP, the ingress LSR signals using RSVP-TE and encodes the path reported by PCE-1 in the Explicit Route Object (ERO). This process is as normal for RSVP-TE but requires that the PKS is also included in the ERO, using the mechanisms defined in this document.
为了建立LSP，入口LSR使用RSVP-TE发出信号，并在显式路由对象（ERO）中对PCE-1报告的路径进行编码。该过程与RSVP-TE一样正常，但要求使用本文件中定义的机制将PKS也包括在ERO中。
When the signaling message (the RSVP-TE Path message) reaches ASBR-2 (Autonomous System Border Router), it consults PCE-2 to 'decode' the PKS and return the expanded explicit path segment to ASBR-2. (The information that PCE-2 uses to decode the PKS is encoded within the PKS itself.) The PKS is replaced in the ERO with the expanded information about the path.
当信令消息（RSVP-TE路径消息）到达ASBR-2（自主系统边界路由器）时，它会咨询PCE-2对PKS进行“解码”，并将扩展的显式路径段返回给ASBR-2。（PCE-2用于解码PKS的信息在PKS本身中进行编码。）ERO中的PKS被替换为关于路径的扩展信息。
----------------------------- ----------------------------
| AS-1 | | AS-2 |
| | | |
| ------- | | ------- |
| | PCE-1 |<---------------+--+-->| PCE-2 | |
| ------- | | ------- |
| ^ | | ^ |
| | | | | |
| v | | v |
| ------- ---- | | ---- |
| | PCC | - - |ASBR| | | |ASBR| - - ------ |
| |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| |
| ------- - - ----- | | ---- - - ------ |
| | | |
----------------------------- ----------------------------
----------------------------- ----------------------------
| AS-1 | | AS-2 |
| | | |
| ------- | | ------- |
| | PCE-1 |<---------------+--+-->| PCE-2 | |
| ------- | | ------- |
| ^ | | ^ |
| | | | | |
| v | | v |
| ------- ---- | | ---- |
| | PCC | - - |ASBR| | | |ASBR| - - ------ |
| |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| |
| ------- - - ----- | | ---- - - ------ |
| | | |
----------------------------- ----------------------------
Figure 1: A Simple Network to Demonstrate the Use of the PKS
图1：演示PKS使用的简单网络
Note that PCE-2 may in some case be co-located with ASBR-2.
请注意，PCE-2在某些情况下可能与ASBR-2位于同一位置。
CPS: Confidential Path Segment. A segment of a path that contains nodes and links that the AS policy requires to not be disclosed outside the AS.
CPS：机密路径段。包含AS策略要求不在AS外部公开的节点和链接的路径段。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：路径计算元素。能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
PKS: Path Key Subobject. A subobject of an Explicit Route Object that encodes a CPS so as to preserve confidentiality.
PKS:路径键子对象。显式路由对象的子对象，对CP进行编码以保持机密性。
The Path Key Subobject (PKS) may be carried in the Explicit Route Object (ERO) of an RSVP-TE Path message [RFC3209]. The PKS is a fixed-length subobject containing a Path Key and a PCE-ID. The Path Key is an identifier or token used to represent the CPS within the context of the PCE identified by the PCE-ID. The PCE-ID identifies the PCE that can decode the Path Key using a reachable IPv4 or IPv6 address of the PCE. In most cases, the decoding PCE is also the PCE that computed the Path Key and the associated path. Because of the IPv4 and IPv6 variants, two subobjects are defined as follows.
路径键子对象（PKS）可以携带在RSVP-TE路径消息[RFC3209]的显式路由对象（ERO）中。PKS是一个固定长度的子对象，包含路径密钥和PCE-ID。路径密钥是一个标识符或令牌，用于表示PCE-ID标识的PCE上下文中的CP。PCE-ID标识可以使用PCE的可访问IPv4或IPv6地址解码路径密钥的PCE。在大多数情况下，解码PCE也是计算路径密钥和相关路径的PCE。由于IPv4和IPv6的变体，两个子对象定义如下。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RSVP-TE Path Key Subobject using an IPv4 address for the PCE-ID
图2：使用PCE-ID的IPv4地址的RSVP-TE路径密钥子对象
L
L
The L bit SHOULD NOT be set, so that the subobject represents a strict hop in the explicit route.
不应设置L位，以便子对象表示显式路由中的严格跃点。
Type
类型
Subobject Type for a Path Key with a 32-bit PCE-ID as assigned by IANA.
具有IANA分配的32位PCE-ID的路径键的子对象类型。
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8.
长度包含子对象的总长度（字节），包括类型和长度字段。长度始终为8。
PCE-ID
PCE-ID
A 32-bit identifier of the PCE that can decode this key. The identifier MUST be unique within the scope of the domain that the CPS crosses and MUST be understood by the LSR that will act as PCC for the expansion of the PKS. The interpretation of the PCE-ID is subject to domain-local policy. It MAY be an IPv4 address of the PCE that is always reachable and MAY be an address that is restricted to the domain in which the LSR that is called upon to expand the CPS lies. Other values that have no meaning outside the domain (for example, the Router ID of the PCE) MAY be used to increase security or confidentiality.
可以解码此密钥的PCE的32位标识符。该标识符在CP跨越的域范围内必须是唯一的，并且必须被作为PKS扩展PCC的LSR理解。PCE-ID的解释受域本地政策的约束。它可以是始终可访问的PCE的IPv4地址，并且可以是被调用以扩展CPS的LSR所在的域的地址。域外没有意义的其他值（例如，PCE的路由器ID）可用于增加安全性或机密性。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE-ID (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE-ID (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RSVP-TE Path Key Subobject using an IPv6 address for the PCE-ID
图3：使用PCE-ID的IPv6地址的RSVP-TE路径密钥子对象
L
L
As above.
如上所述。
Type
类型
Subobject Type for a Path Key with a 128-bit PCE-ID as assigned by IANA.
IANA分配的具有128位PCE-ID的路径键的子对象类型。
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 20.
长度包含子对象的总长度（字节），包括类型和长度字段。长度始终为20。
PCE-ID
PCE-ID
A 128-bit identifier of the PCE that can decode this key. The identifier MUST be unique within the scope of the domain that the CPS crosses and MUST be understood by the LSR that will act as PCC for the expansion of the PKS. The interpretation of the PCE-ID is subject to domain-local policy. It MAY be an IPv6 address of the PCE that is always reachable, and MAY be an address that is restricted to the domain in which the LSR that is called upon to expand the CPS lies. Other values that have no meaning outside the domain (for example, the IPv6 TE Router ID) MAY be used to increase security (see Section 4).
可以解码此密钥的PCE的128位标识符。该标识符在CP跨越的域范围内必须是唯一的，并且必须被作为PKS扩展PCC的LSR理解。PCE-ID的解释受域本地政策的约束。它可以是始终可访问的PCE的IPv6地址，并且可以是受限于被调用以扩展CPS的LSR所在的域的地址。在域之外没有意义的其他值（例如，IPv6 TE路由器ID）可用于提高安全性（参见第4节）。
Note: The twins of these subobjects are carried in PCEP messages as defined in [RFC5520].
注：这些子对象的孪生体在[RFC5520]中定义的PCEP消息中携带。
The basic processing rules of an ERO are not altered. Refer to [RFC3209] for details. In particular, an LSR is not required to "look ahead" in the ERO beyond the first subobject that is non-local.
能源监管局的基本处理规则不会改变。有关详细信息，请参阅[RFC3209]。特别是，LSR不需要在ERO中“展望”第一个子对象以外的非本地子对象。
[RFC5520] requires that any path fragment generated by a PCE that contains a PKS be such that the PKS is immediately preceded by a subobject that identifies the head end of the PKS (for example, an incoming interface or a node ID). This rule is extended to the PKS in the ERO so that the following rules are defined.
[RFC5520]要求由包含PKS的PCE生成的任何路径片段的前面紧跟着一个子对象，该子对象标识PKS的前端（例如，传入接口或节点ID）。此规则扩展到ERO中的PKS，以便定义以下规则。
- If an LSR receives a Path message where the first subobject of the ERO is a PKS, it MUST respond with a PathErr message carrying the error code/value combination "Routing Problem" / "Bad initial subobject".
- 如果LSR接收到一条路径消息，其中ERO的第一个子对象是PKS，则它必须使用带有错误代码/值组合“路由问题”/“错误初始子对象”的PathErr消息进行响应。
- If an LSR strips all local subobjects from an ERO carried in a Path message (according to the procedures in [RFC3209]) and finds that the next subobject is a PKS, it MUST attempt to resolve the PKS to a CPS.
- 如果LSR从路径消息中携带的ERO中剥离所有本地子对象（根据[RFC3209]中的过程），并发现下一个子对象是PKS，则必须尝试将PKS解析为CPS。
Resolution of the PKS MAY take any of the following forms or use some other technique subject to local policy and network implementation.
PKS的解决可以采取以下任何形式，也可以根据本地政策和网络实施使用其他技术。
o The LSR can use the PCE-ID contained in the PKS to contact the identified PCE using PCEP [RFC5440] and request that the PKS be expanded.
o LSR可以使用PKS中包含的PCE-ID，使用PCEP[RFC5440]联系已识别的PCE，并请求扩展PKS。
o The LSR can contact any PCE using PCEP [RFC5440] to request that the PKS be expanded, relying on cooperation between the PCEs.
o LSR可以使用PCEP[RFC5440]联系任何PCE，请求扩展PKS，这取决于PCE之间的合作。
o The LSR can use the information in the PKS to index a CPS previously supplied to it by the PCE that originated the PKS.
o LSR可以使用PKS中的信息对发起PKS的PCE先前提供给它的CP进行索引。
If a CPS is derived, the path fragment SHOULD be inserted into the ERO of the Path message as a direct replacement for the PKS. Other processing of the CPS and ERO are permitted as described in [RFC3209].
如果派生了CPS，则应将路径片段插入path消息的ERO中，作为PKS的直接替换。如[RFC3209]所述，允许对CPS和ERO进行其他处理。
This processing can give rise to the following error cases:
此处理可能导致以下错误情况：
o PCE-ID cannot be matched to a PCE to decode the PKS.
o PCE-ID无法与解码PKS的PCE匹配。
The LSR sends a PathErr message with the error code "Routing Problem" and the new error value "Unknown PCE-ID for PKS expansion" (see Section 6.3).
LSR发送一条PathErr消息，错误代码为“路由问题”，新的错误值为“PKS扩展的未知PCE-ID”（见第6.3节）。
o PCE identified by the PCE-ID cannot be reached.
o 无法访问由PCE-ID标识的PCE。
The LSR sends a PathErr message with the error code "Routing Problem" and the new error value "Unreachable PCE for PKS expansion" (see Section 6.3).
LSR发送一条PathErr消息，错误代码为“路由问题”，新的错误值为“PKS扩展无法访问PCE”（见第6.3节）。
o The PCE is unable to decode the PKS, perhaps because the Path Key has expired.
o PCE无法解码PKS，可能是因为路径密钥已过期。
The LSR sends a PathErr message with the error code "Routing Problem" and the new error value "Unknown Path Key for PKS expansion" (see Section 6.3).
LSR发送一条PathErr消息，错误代码为“路由问题”，新的错误值为“PKS扩展的未知路径密钥”（参见第6.3节）。
o PKS cannot be decoded for policy reasons.
o 由于策略原因，无法解码PKS。
The LSR sends a PathErr message with the error code "Policy Control Failure" and the error value "Inter-domain policy failure".
LSR发送一条PathErr消息，错误代码为“策略控制失败”，错误值为“域间策略失败”。
o Addition of CPS to ERO causes Path message to become too large.
o 向ERO添加CP会导致路径消息变得太大。
The LSR MAY replace part of the ERO with loose hops [RFC3209] or with a further PKS, according to local policy, if the loss of specifics within the explicit path is acceptable. If the LSR is unable to take steps to reduce the size of the ERO, it MUST send a PathErr message with the error code "Routing Problem" and the new error value "ERO too large for MTU" (see Section 6.3).
根据当地政策，如果显式路径中的细节丢失是可接受的，则LSR可使用松散跃点[RFC3209]或进一步的PK替换部分ERO。如果LSR无法采取措施减小ERO的大小，则必须发送一条PathErr消息，其中包含错误代码“Routing Problem”和新的错误值“ERO对于MTU来说太大”（参见第6.3节）。
- An LSR that is called on to process a PKS within an ERO but that does not recognize the subobject, will react according to [RFC3209] and send a PathErr message with the error code/value combination "Routing Problem" / "Bad Explicit Route Object".
- 被调用以处理ERO内的PKS但不识别子对象的LSR将根据[RFC3209]作出反应，并发送带有错误代码/值组合“路由问题”/“错误显式路由对象”的PathErr消息。
The Record Route Object (RRO) is used in RSVP-TE to record the route traversed by an LSP. The RRO may be present on a Path message and on a Resv message. The intention of [RFC3209] is that an RRO on a Resv message that is received by an ingress LSR is suitable for use as an ERO on a Path message sent by that LSR to achieve an identical LSP.
记录路由对象（RRO）在RSVP-TE中用于记录LSP穿过的路由。RRO可能出现在Path消息和Resv消息上。[RFC3209]的意图是，入口LSR接收的Resv消息上的RRO适合用作该LSR发送的路径消息上的ERO，以实现相同的LSP。
The PKS offers an alternative that can be more useful to diagnostics. When the signaling message crosses a domain boundary, the path segment that needs to be hidden (that is, a CPS) MAY be replaced in the RRO with a PKS. In the case of an RRO on a Resv message, the PKS used SHOULD be the one originally signaled in the ERO of the Path message. On a Path message, the PKS SHOULD identify the LSR replacing the CPS and provide a Path Key that can be used to expand
PKS提供了一种对诊断更有用的替代方法。当信令消息跨越域边界时，需要隐藏的路径段（即CPS）可以在RRO中替换为PKS。对于Resv消息上的RRO，使用的PKS应该是路径消息的ERO中最初发出信号的PKS。在Path消息上，PKS应识别替换CP的LSR，并提供可用于扩展的路径密钥
the path segment. In the latter case, the Path Key and its expansion SHOULD be retained by the LSR that performs the substitution for at least the lifetime of the LSP. In both cases, the expansion of the PKS SHOULD be made available to diagnostic tools under the control of local policy.
路径段。在后一种情况下，执行替换的LSR应至少在LSP的生存期内保留路径密钥及其扩展。在这两种情况下，PKS的扩展应在当地政策的控制下提供给诊断工具。
The protocol interactions required by the mechanisms described in this document are point-to-point and can be authenticated and made secure as described in [RFC5440] and [RFC3209]. The protocol interactions for PCEP are listed in [RFC5520], while general considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can be found in [MPLS-SEC].
本文件中描述的机制所需的协议交互是点对点的，可以按照[RFC5440]和[RFC3209]中的描述进行身份验证和安全。[RFC5520]中列出了PCEP的协议交互，而在MPLS-TE和GMPLS网络中保护RSVP-TE的一般注意事项可在[MPLS-SEC]中找到。
Thus, security issues can be dealt with using standard techniques for securing and authenticating point-to-point communications. In addition, it is RECOMMENDED that the PCE providing a PKS expansion check that the LSR that issued the request for PKS expansion is the head end of the resulting CPS.
因此，可以使用用于保护和认证点到点通信的标准技术来处理安全问题。此外，建议提供PKS扩展的PCE检查发出PKS扩展请求的LSR是否为生成的CP的前端。
Further protection can be provided by using a PCE-ID to identify the decoding PCE that is only meaningful within the domain that contains the LSR at the head of the CPS. This may be either an IP address that is only reachable from within the domain or some non-address value. The former requires configuration of policy on the PCEs; the latter requires domain-wide policy.
通过使用PCE-ID来识别仅在包含CPS头部的LSR的域内有意义的解码PCE，可以提供进一步的保护。这可能是只能从域内访问的IP地址，也可能是某些非地址值。前者要求对个人消费品进行政策配置；后者需要域范围的策略。
The following specific security issues need to be considered.
需要考虑以下具体的安全问题。
- Confidentiality of the CPS. The question to be answered is whether other network elements can probe a PCE for the expansion of PKSs, possibly generating Path Keys at random. This can be protected against by only allowing PKS expansion to be successfully completed if requested by the LSR that is at the head end of the resulting CPS. Under specific circumstances, PKS expansion might also be allowed by configured management stations.
- CPS的保密性。需要回答的问题是，其他网元是否可以探测PCE以扩展PKS，可能随机生成路径密钥。只有在最终CP前端的LSR提出请求时，才允许成功完成PKS扩展，以防止出现这种情况。在特定情况下，配置的管理站也可能允许PKS扩展。
The CPS itself may be kept confidential as it is exchanged in the PCEP and RSVP-TE protocols using standard security mechanisms defined for those protocols.
CPS本身可以保密，因为它在PCEP和RSVP-TE协议中使用为这些协议定义的标准安全机制进行交换。
- Determination of information by probing. In addition to the probing described above, a node might deduce information from the error responses that are generated when PKS expansion fails as described in Section 3.1. Any LSR that determines that supplying one of the detailed error codes described in Section 3.1 might
- 通过探测确定信息。除了上述探测之外，节点还可以根据PKS扩展失败时生成的错误响应推断信息，如第3.1节所述。任何确定提供第3.1节所述详细错误代码之一的LSR可能
provide too much information that could be used as part of a
systematic attack MAY simply use the error code/value "Policy
Control Failure" / "Inter-domain policy failure" in all cases.
provide too much information that could be used as part of a
systematic attack MAY simply use the error code/value "Policy
Control Failure" / "Inter-domain policy failure" in all cases.
- Authenticity of the Path Key. A concern is that the Path Key in the PKS will be altered or faked, leading to erroneous Path Key expansion and use of the wrong CPS. The consequence would be a bad ERO in a Path message, causing the LSP to be set up incorrectly and resulting in incorrect network resource usage, diversion of traffic to where it can be intercepted, or failure to set up the LSP. These problems can be prevented by protecting the protocol exchanges in PCEP and RSVP-TE using the security techniques described in [RFC5440], [RFC3209], and [MPLS-SEC].
- 路径密钥的真实性。令人担忧的是，PKS中的路径密钥将被更改或伪造，从而导致错误的路径密钥扩展和使用错误的CP。其结果是路径消息中出现错误的ERO，导致LSP设置不正确，并导致网络资源使用不正确、流量转移到可拦截的位置或LSP设置失败。通过使用[RFC5440]、[RFC3209]和[MPLS-SEC]中描述的安全技术保护PCEP和RSVP-TE中的协议交换，可以防止这些问题。
- Resilience to denial-of-service (DoS) attacks. A PCE can be attacked through a flood of Path Key expansion requests -- this issue is addressed in [RFC5520] and is out of scope for this document. A further attack might consist of sending a flood of RSVP-TE Path messages with deliberately spurious PKSs. This attack is prevented by ensuring the integrity of the Path messages using standard RSVP-TE security mechanisms and by enforcing the RSVP-TE chain-of-trust security model.
- 对拒绝服务（DoS）攻击的恢复能力。PCE可能会受到大量路径密钥扩展请求的攻击——此问题在[RFC5520]中有说明，不在本文档的范围内。进一步的攻击可能包括使用故意伪造的PKS发送大量RSVP-TE Path消息。通过使用标准RSVP-TE安全机制确保路径消息的完整性，并通过强制实施RSVP-TE信任链安全模型，可以防止此攻击。
Policy forms an important part of the use of PKSs in EROs and RROs. There are local and domain-wide policies that SHOULD be available for configuration in an implementation.
政策是在ERO和RRO中使用PKS的重要组成部分。有一些本地和域范围的策略应可用于实现中的配置。
- Handling of an ERO containing a PKS. As described in Section 3.1, an LSR that receives a Path message containing a PKS can be configured to reject the Path message according to policy.
- 处理包含PKS的ERO。如第3.1节所述，接收包含PKS的路径消息的LSR可配置为根据策略拒绝路径消息。
- Handling of PKS requests at a PCE. As described in Section 3.1, in [RFC5520], and in [RFC5394], a PCE can be configured with policy regarding how it should handle requests for PKS expansion.
- 在PCE上处理PKS请求。如第3.1节、[RFC5520]和[RFC5394]中所述，PCE可以配置有关如何处理PKS扩展请求的策略。
- PKS expansion. Section 3.1 explains that the PKS can be expanded by the local LSR, the specific PCE identified in the PKS, any PCE acting as a proxy, or by some other method. The behavior of the LSR needs to be locally configurable but is subject to the domain-wide policy.
- PKS扩展。第3.1节解释了PKS可以通过本地LSR、PKS中标识的特定PCE、作为代理的任何PCE或其他方法进行扩展。LSR的行为需要在本地可配置，但受域范围策略的约束。
- Interpretation of PCE-ID. The interpretation of the PCE-ID component of PKSs is subject to domain-local policy and needs to be configurable as such. See Section 3 and Section 4 for the options.
- PCE-ID的解释。PKSs的PCE-ID组件的解释受域本地策略的约束，因此需要进行配置。有关选项，请参见第3节和第4节。
- ERO too large. The behavior of an LSR when it finds that adding a CPS to the ERO causes the Path message to be too large is an implementation choice. However, implementations may choose to provide configuration of behavior as described in Section 3.1.
- 太大了。LSR发现向ERO添加CPS会导致Path消息过大时的行为是一种实现选择。但是，实现可以选择提供第3.1节中描述的行为配置。
- Masking of RRO. As described in Section 3.2, a border router can choose to mask segments of the path by replacing them with PKSs. This behavior needs to be configurable, with the default being to not hide any part of the RRO.
- 掩盖错误。如第3.2节所述，边界路由器可以选择用PKS替换路径段来屏蔽路径段。此行为需要可配置，默认情况下不隐藏RRO的任何部分。
- Inspection / decoding of PKS by diagnostic tools. A PCE can allow access from management or diagnostic tools to request the expansion of a PKS. Note that this must be regulated with the security and confidentiality behavior described in Section 4.
- 通过诊断工具检查/解码PKS。PCE可允许管理或诊断工具访问，以请求扩展PKS。请注意，这必须按照第4节中描述的安全和保密行为进行管理。
- Hiding of reason codes. An LSR can support the configuration of local policy to hide reason codes associated with the failure to expand a PKS and, as described in Section 4, report all errors as policy failures.
- 隐藏原因代码。LSR可以支持本地策略的配置，以隐藏与扩展PKS失败相关的原因码，并如第4节所述，将所有错误报告为策略失败。
The treatment of a path segment as a CPS, and its substitution in a PCRep ERO with a PKS, is a PCE function and is described in [RFC5520].
将路径段处理为CP，并在PCRep ERO中将其替换为PKS，这是PCE功能，在[RFC5520]中进行了描述。
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Class Names, Class Numbers, and Class Types".
IANA维护一个名为“资源保留协议（RSVP）参数”的注册表，其中有一个子区域名为“类名、类号和类类型”。
Within this subregistry, there is a definition of the EXPLICIT_ROUTE object with Class Number 20. The object definition lists a number of acceptable subobjects for the Class Type 1.
在该子区域内，有一个类号为20的显式路由对象的定义。对象定义列出了类类型1的许多可接受的子对象。
IANA has allocated two further subobjects as described in Section 3. The resulting entry in the registry is as follows.
IANA已分配了另外两个子对象，如第3节所述。注册表中的结果项如下所示。
20 EXPLICIT_ROUTE [RFC3209]
Class Types or C-Types:
1 Type 1 Explicit Route [RFC3209]
Subobject type
64 Path Key with 32-bit PCE-ID [RFC5553]
65 Path Key with 128-bit PCE-ID [RFC5553]
20 EXPLICIT_ROUTE [RFC3209]
Class Types or C-Types:
1 Type 1 Explicit Route [RFC3209]
Subobject type
64 Path Key with 32-bit PCE-ID [RFC5553]
65 Path Key with 128-bit PCE-ID [RFC5553]
Note well: [RFC5520] defines the PKS for use in PCEP. IANA has assigned the same subobject numbers for use in RSVP-TE as are assigned for the PKS in PCEP. The numbers above are the same as in [RFC5520].
注：[RFC5520]定义了用于PCEP的PKS。IANA为RSVP-TE分配的子对象编号与为PCEP中的PKS分配的子对象编号相同。上述数字与[RFC5520]中的数字相同。
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Class Names, Class Numbers, and Class Types".
IANA维护一个名为“资源保留协议（RSVP）参数”的注册表，其中有一个子区域名为“类名、类号和类类型”。
Within this subregistry, there is a definition of the ROUTE_RECORD object (also known as the RECORD_ROUTE object) with Class Number 21. The object definition lists a number of acceptable subobjects for the Class Type 1.
在该子区域内，存在类别编号为21的ROUTE_记录对象（也称为RECORD_ROUTE对象）的定义。对象定义列出了类类型1的许多可接受的子对象。
IANA has allocated two further subobjects as described in Section 3. The resulting entry in the registry is as follows.
IANA已分配了另外两个子对象，如第3节所述。注册表中的结果项如下所示。
21 ROUTE_RECORD [RFC3209]
(also known as RECORD_ROUTE)
Class Types or C-Types:
1 Type 1 Route Record [RFC3209]
Subobject type
64 Path Key with 32-bit PCE-ID [RFC5553]
65 Path Key with 128-bit PCE-ID [RFC5553]
21 ROUTE_RECORD [RFC3209]
(also known as RECORD_ROUTE)
Class Types or C-Types:
1 Type 1 Route Record [RFC3209]
Subobject type
64 Path Key with 32-bit PCE-ID [RFC5553]
65 Path Key with 128-bit PCE-ID [RFC5553]
Note well: IANA is requested to use the same subobject numbers as are defined for the EXPLICIT_ROUTE object in Section 6.1.
注：请IANA使用第6.1节中为显式布线对象定义的相同子对象编号。
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes".
IANA维护一个名为“资源保留协议（RSVP）参数”的注册表，该注册表具有一个名为“错误代码和全局定义的错误值子代码”的子区域。
Within this subregistry, there is a definition of the "Routing Problem" error code with error code value 24. The definition lists a number of error values that may be used with this error code.
在该分区域内，有一个“路由问题”错误代码的定义，错误代码值为24。该定义列出了许多可能与此错误代码一起使用的错误值。
IANA has allocated further error values for use with this error code as described in Section 3.1. The resulting entry in the registry is as follows.
IANA已分配了更多错误值，用于第3.1节所述的该错误代码。注册表中的结果项如下所示。
24 Routing Problem [RFC3209]
24路由问题[RFC3209]
This Error Code has the following globally defined Error Value sub-codes:
此错误代码具有以下全局定义的错误值子代码：
31 = Unknown PCE-ID for PKS expansion [RFC5553]
32 = Unreachable PCE for PKS expansion [RFC5553]
33 = Unknown Path Key for PKS expansion [RFC5553]
34 = ERO too large for MTU [RFC5553]
31 = Unknown PCE-ID for PKS expansion [RFC5553]
32 = Unreachable PCE for PKS expansion [RFC5553]
33 = Unknown Path Key for PKS expansion [RFC5553]
34 = ERO too large for MTU [RFC5553]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.-P.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“策略启用路径计算框架”，RFC 53942008年12月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5520]Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，2009年4月。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, March 2009.
[MPLS-SEC]Fang，L.，编辑，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2009年3月。
Authors' Addresses
作者地址
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk
Rich Bradford Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA EMail: rbradfor@cisco.com
Rich Bradford Cisco Systems，Inc.马萨诸塞州Boxborough马萨诸塞大道1414号-美国01719电子邮件：rbradfor@cisco.com
Jean-Philippe Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France EMail: jpv@cisco.com
Jean-Philippe Vasseur Cisco Systems，Inc.，11号，亚特兰蒂斯大道92782 Issy Les Moulineaux法国电子邮件：jpv@cisco.com