Internet Engineering Task Force (IETF) Z. Ali, Ed.
Request for Comments: 8390 Cisco Systems
Updates: 4874 G. Swallow, Ed.
Category: Standards Track SETC
ISSN: 2070-1721 F. Zhang, Ed.
Huawei
D. Beller, Ed.
Nokia
July 2018
Internet Engineering Task Force (IETF) Z. Ali, Ed.
Request for Comments: 8390 Cisco Systems
Updates: 4874 G. Swallow, Ed.
Category: Standards Track SETC
ISSN: 2070-1721 F. Zhang, Ed.
Huawei
D. Beller, Ed.
Nokia
July 2018
RSVP-TE Path Diversity Using Exclude Route
使用排除路由的RSVP-TE路径分集
Abstract
摘要
RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A typical LSP diversity use case is for protection, where two LSPs should follow different paths through the network in order to avoid single points of failure, thus greatly improving service availability. This document specifies an approach that can be used for network scenarios where the full path(s) is not necessarily known by use of an abstract identifier for the path. Three types of abstract identifiers are specified: client based, Path Computation Element (PCE) based, and network based. This document specifies two new diversity subobjects for the RSVP eXclude Route Object (XRO) and the Explicit Exclusion Route Subobject (EXRS).
RSVP-TE为标签交换路径（LSP）设置期间的排除信息通信提供支持。典型的LSP分集用例用于保护，其中两个LSP应在网络中遵循不同的路径，以避免单点故障，从而大大提高服务可用性。本文档规定了一种可用于网络场景的方法，其中不一定通过使用路径的抽象标识符来知道完整路径。指定了三种类型的抽象标识符：基于客户端、基于路径计算元素（PCE）和基于网络。本文档为RSVP排除路由对象（XRO）和显式排除路由子对象（EXRS）指定了两个新的多样性子对象。
For the protection use case, LSPs are typically created at a slow rate and exist for a long time so that it is reasonable to assume that a given (reference) path currently existing (with a well-known identifier) will continue to exist and can be used as a reference when creating the new diverse path. Re-routing of the existing (reference) LSP, before the new path is established, is not considered.
对于保护用例，LSP通常以较慢的速度创建并且存在很长时间，因此可以合理地假设当前存在的给定（参考）路径（具有已知标识符）将继续存在，并且可以在创建新的多样化路径时用作参考。在建立新路径之前，不考虑现有（参考）LSP的重新路由。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8390.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8390.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 6
1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 6
1.3. Client-Initiated Identifier . . . . . . . . . . . . . . . 7
1.4. PCE-Allocated Identifier . . . . . . . . . . . . . . . . 7
1.5. Network-Assigned Identifier . . . . . . . . . . . . . . . 9
2. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . 10
2.1. Diversity XRO Subobject . . . . . . . . . . . . . . . . . 10
2.2. Diversity EXRS Subobject . . . . . . . . . . . . . . . . 16
2.3. Processing Rules for the Diversity XRO and EXRS
Subobjects . . . . . . . . . . . . . . . . . . . . . . . 16
3. Security Considerations . . . . . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4.1. New XRO Subobject Types . . . . . . . . . . . . . . . . . 21
4.2. New EXRS Subobject Types . . . . . . . . . . . . . . . . 21
4.3. New RSVP Error Sub-codes . . . . . . . . . . . . . . . . 22
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Normative References . . . . . . . . . . . . . . . . . . 22
5.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 6
1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 6
1.3. Client-Initiated Identifier . . . . . . . . . . . . . . . 7
1.4. PCE-Allocated Identifier . . . . . . . . . . . . . . . . 7
1.5. Network-Assigned Identifier . . . . . . . . . . . . . . . 9
2. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . 10
2.1. Diversity XRO Subobject . . . . . . . . . . . . . . . . . 10
2.2. Diversity EXRS Subobject . . . . . . . . . . . . . . . . 16
2.3. Processing Rules for the Diversity XRO and EXRS
Subobjects . . . . . . . . . . . . . . . . . . . . . . . 16
3. Security Considerations . . . . . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4.1. New XRO Subobject Types . . . . . . . . . . . . . . . . . 21
4.2. New EXRS Subobject Types . . . . . . . . . . . . . . . . 21
4.3. New RSVP Error Sub-codes . . . . . . . . . . . . . . . . 22
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Normative References . . . . . . . . . . . . . . . . . . 22
5.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
Path diversity for multiple connections is a well-known operational requirement. Diversity constraints ensure that Label Switched Paths (LSPs) can be established without sharing network resources, thus greatly reducing the probability of simultaneous connection failures.
多个连接的路径多样性是众所周知的操作要求。分集约束确保可以在不共享网络资源的情况下建立标签交换路径（LSP），从而大大降低同时连接失败的概率。
The source node can compute diverse paths for LSPs when it has full knowledge of the network topology and is permitted to signal an Explicit Route Object (ERO). However, there are scenarios where different nodes perform path computations, and therefore there is a need for relevant diversity constraints to be signaled to those nodes. These include (but are not limited to):
当源节点完全了解网络拓扑并允许向显式路由对象（ERO）发送信号时，它可以计算LSP的不同路径。然而，存在不同节点执行路径计算的场景，因此需要向这些节点发送相关的多样性约束信号。这些包括（但不限于）：
o LSPs with loose hops in the Explicit Route Object, e.g., inter-domain LSPs; and
o 在显式路由对象中具有松散跳数的lsp，例如域间lsp；和
o Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI), where the core node may perform path computation [RFC4208].
o 通用多协议标签交换（GMPLS）用户网络接口（UNI），其中核心节点可执行路径计算[RFC4208]。
[RFC4874] introduced a means of specifying nodes and resources to be excluded from a route using the eXclude Route Object (XRO) and Explicit Exclusion Route Subobject (EXRS). It facilitates the calculation of diverse paths for LSPs based on known properties of those paths including addresses of links and nodes traversed and Shared Risk Link Groups (SRLGs) of traversed links. Employing these mechanisms requires that the source node that initiates signaling knows the relevant properties of the path(s) from which diversity is desired. However, there are circumstances under which this may not be possible or desirable, including (but not limited to):
[RFC4874]介绍了一种使用排除路由对象（XRO）和显式排除路由子对象（EXRS）指定要从路由中排除的节点和资源的方法。它有助于基于路径的已知属性计算LSP的不同路径，这些路径包括被穿越链路和节点的地址以及被穿越链路的共享风险链路组（SRLGs）。采用这些机制要求发起信令的源节点知道期望分集的路径的相关属性。但是，在某些情况下，这可能不可能或不可取，包括（但不限于）：
o Exclusion of a path that does not originate, terminate, or traverse the source node of the diverse LSP, in which case the addresses of links and SRLGs of the path from which diversity is required are unknown to the source node.
o 排除不发起、终止或穿过多样性LSP源节点的路径，在这种情况下，源节点不知道需要多样性的路径的链路和SRLGs的地址。
o Exclusion of a path that is known to the source node of the diverse LSP for which the node has incomplete or no path information, e.g., due to operator policy. In this case, the source node is aware of the existence of the reference path, but the information required to construct an XRO object to guarantee diversity from the reference path is not fully known. Inter-domain and GMPLS overlay networks can impose such restrictions.
o 排除不同LSP的源节点已知的路径，该路径的节点具有不完整或没有路径信息，例如，由于操作员策略。在这种情况下，源节点知道参考路径的存在，但是构造XRO对象以保证来自参考路径的多样性所需的信息并不完全已知。域间和GMPLS覆盖网络可以施加此类限制。
This is illustrated in Figure 1, where the overlay reference model from [RFC4208] is shown.
图1对此进行了说明，其中显示了[RFC4208]中的覆盖参考模型。
Overlay Overlay
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | UNI | | | | | | | | UNI | | | |
| -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- |
| | | | +--+--+ | | | | | | +---+-| | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
+---------+ | | | | | | | +---------+
| | | | | | |
+---------+ | | +--+--+ | +--+--+ | | +---------+
| +----+ | | | | | +-------+ +-----+ | +----+ |
| | +-+--+ | | CN4 +---------------+ CN5 | | | | | |
| -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
| | | | UNI | +-----+ +-----+ | UNI | | | |
| +----+ | | | | +----+ |
+---------+ +----------------------------------+ +---------+
Overlay Core Network Overlay
Network Network
Legend: EN - Edge Node
CN - Core Node
Overlay Overlay
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | UNI | | | | | | | | UNI | | | |
| -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- |
| | | | +--+--+ | | | | | | +---+-| | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
+---------+ | | | | | | | +---------+
| | | | | | |
+---------+ | | +--+--+ | +--+--+ | | +---------+
| +----+ | | | | | +-------+ +-----+ | +----+ |
| | +-+--+ | | CN4 +---------------+ CN5 | | | | | |
| -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
| | | | UNI | +-----+ +-----+ | UNI | | | |
| +----+ | | | | +----+ |
+---------+ +----------------------------------+ +---------+
Overlay Core Network Overlay
Network Network
Legend: EN - Edge Node
CN - Core Node
Figure 1: Overlay Reference Model [RFC4208]
图1：覆盖参考模型[RFC4208]
Figure 1 depicts two types of UNI connectivity: single-homed and dual-homed ENs (which also applies to higher-order multihomed connectivity). Single-homed EN devices are connected to a single CN device via a single UNI link. This single UNI link may constitute a single point of failure. UNI connection between EN1 and CN1 is an example of singled-homed UNI connectivity.
图1描述了两种类型的单宿连接：单宿和双宿ENs（这也适用于高阶多宿连接）。单宿EN设备通过单个UNI链路连接到单个CN设备。该单单链路可能构成单点故障。EN1和CN1之间的UNI连接是单宿UNI连接的一个示例。
Such a single point of failure can be avoided when the EN device is connected to two different CN devices, as depicted for EN2 in Figure 1. For the dual-homing case, it is possible to establish two different UNI connections from the same source EN device to the same destination EN device. For example, two connections from EN2 to EN3 may use the two UNI links EN2-CN1 and EN2-CN4. To avoid single points of failure within the provider network, it is necessary to also ensure path (LSP) diversity within the core network.
当EN设备连接到两个不同的CN设备时，可以避免这种单点故障，如图1中EN2所示。对于双归位情况，可以建立从同一源EN设备到同一目的EN设备的两个不同UNI连接。例如，从EN2到EN3的两个连接可以使用两个UNI链路EN2-CN1和EN2-CN4。为了避免提供商网络内的单点故障，还必须确保核心网络内的路径（LSP）多样性。
In a network providing a set of UNI interfaces between ENs and CNs such as that shown in Figure 1, the CNs typically perform path computation. Information sharing across the UNI boundary is restricted based on the policy rules imposed by the core network. Typically, the core network topology information as well as LSP path information is not exposed to the ENs. In the network shown in Figure 1, consider a use case where an LSP from EN2 to EN4 needs to be SRLG diverse from an LSP from EN1 to EN3. In this case, EN2 may
在如图1所示的在ENs和CNs之间提供一组UNI接口的网络中，CNs通常执行路径计算。基于核心网络实施的政策规则，跨UNI边界的信息共享受到限制。通常，核心网络拓扑信息以及LSP路径信息不向ENs公开。在图1所示的网络中，考虑一个用例，其中从En2到En4的LSP需要与从En1到En3的LSP不同的SRLG。在这种情况下，EN2可能
not know SRLG attributes of the EN1-EN3 LSP and hence cannot construct an XRO to exclude these SRLGs. In this example, EN2 cannot use the procedures described in [RFC4874]. Similarly, an LSP from EN2 to EN3 traversing CN1 needs to be diverse from an LSP from EN2 to EN3 going via CN4. Again, in this case, exclusions based on [RFC4874] cannot be used.
不知道EN1-EN3 LSP的SRLG属性，因此无法构建XRO来排除这些SRLG。在此示例中，EN2无法使用[RFC4874]中描述的程序。类似地，穿越CN1的从EN2到EN3的LSP需要与经由CN4的从EN2到EN3的LSP不同。同样，在这种情况下，不能使用基于[RFC4874]的排除。
This document addresses these diversity requirements by introducing an approach of excluding the path taken by these particular LSP(s). Each reference LSP or route from which diversity is required is identified by an abstract "identifier". The type of identifier to use is highly dependent on the core network operator's networking deployment scenario; it could be client initiated (provided by the EN), provided by a PCE, or allocated by the (core) network. This document defines three different types of identifiers corresponding to these three cases: a client-initiated identifier, a PCE-allocated identifier, and an identifier allocated by the CN ingress node (UNI-N), i.e., a network-assigned identifier.
本文件通过引入一种排除这些特定LSP所采用路径的方法来解决这些多样性要求。需要分集的每个参考LSP或路由由抽象的“标识符”标识。要使用的标识符类型高度依赖于核心网络运营商的网络部署场景；它可以由客户端发起（由EN提供）、由PCE提供或由（核心）网络分配。本文档定义了与这三种情况相对应的三种不同类型的标识符：客户端启动的标识符、PCE分配的标识符和由CN入口节点（UNI-N）分配的标识符，即网络分配的标识符。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Diverse LSP: A diverse Label Switched Path (LSP) is an LSP that has a path that does not have any link or SRLG in common with the path of a given LSP. Diverse LSPs are meaningful in the context of protection or restoration.
多样性LSP：多样性标签交换路径（LSP）是一种LSP，其路径与给定LSP的路径没有任何共同的链路或SRLG。不同的LSP在保护或恢复方面具有重要意义。
ERO: Explicit Route Object as defined in [RFC3209].
ERO:[RFC3209]中定义的显式路由对象。
EXRS: Explicit Exclusion Route Subobject as defined in [RFC4874].
EXRS:[RFC4874]中定义的显式排除路由子对象。
SRLG: Shared Risk Link Group as defined in [RFC4202].
SRLG:[RFC4202]中定义的共享风险链接组。
Reference Path: The reference path is the path of an existing LSP to which the path of a diverse LSP shall be diverse.
参考路径：参考路径是现有LSP的路径，不同LSP的路径应不同。
XRO: eXclude Route Object as defined in [RFC4874].
XRO:排除[RFC4874]中定义的路由对象。
The following fields MUST be used to represent the client-initiated identifier: IPv4/IPv6 tunnel sender address, IPv4/IPv6 tunnel endpoint address, Tunnel ID, and Extended Tunnel ID. Based on local policy, the client MAY also include the LSP ID to identify a specific LSP within the tunnel. These fields are defined in Sections 4.6.1.1 and 4.6.2.1 of [RFC3209].
必须使用以下字段来表示客户端启动的标识符：IPv4/IPv6隧道发送方地址、IPv4/IPv6隧道端点地址、隧道ID和扩展隧道ID。根据本地策略，客户端还可以包括LSP ID以标识隧道内的特定LSP。[RFC3209]第4.6.1.1节和第4.6.2.1节对这些字段进行了定义。
The usage of the client-initiated identifier is illustrated by Figure 1. Suppose an LSP from EN2 to EN4 needs to be diverse with respect to an LSP from EN1 to EN3.
图1说明了客户机启动标识符的用法。假设从EN2到EN4的LSP需要与从EN1到EN3的LSP不同。
The LSP identifier of the EN1-EN3 LSP is LSP-IDENTIFIER1, where LSP-IDENTIFIER1 is defined by the tuple
EN1-EN3 LSP的LSP标识符为LSP-IDENTIFIER1，其中LSP-IDENTIFIER1由元组定义
(tunnel-id = T1, LSP ID = L1, source address = EN1.RID (Route Identifier), destination address = EN3.RID, extended tunnel-id = EN1.RID).
（隧道id=T1，LSP id=L1，源地址=EN1.RID（路由标识符），目标地址=EN3.RID，扩展隧道id=EN1.RID）。
Similarly, the LSP identifier of the EN2-EN4 LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER2 is defined by the tuple
类似地，EN2-EN4 LSP的LSP标识符是LSP-IDENTIFIER2，其中LSP-IDENTIFIER2由元组定义
(tunnel-id = T2, LSP ID = L2, source address = EN2.RID, destination address = EN4.RID, extended tunnel-id = EN2.RID).
（隧道id=T2，LSP id=L2，源地址=EN2.RID，目标地址=EN4.RID，扩展隧道id=EN2.RID）。
The EN1-EN3 LSP is signaled with an exclusion requirement from LSP-IDENTIFIER2, and the EN2-EN4 LSP is signaled with an exclusion requirement from LSP-IDENTIFIER1. In order to maintain diversity between these two connections within the core network, the core network SHOULD implement crankback signaling extensions as defined in [RFC4920]. Note that crankback signaling is known to lead to slower setup times and suboptimal paths under some circumstances as described by [RFC4920].
EN1-EN3 LSP通过LSP-IDENTIFIER2发出排除要求信号，EN2-EN4 LSP通过LSP-IDENTIFIER1发出排除要求信号。为了保持核心网络内这两个连接之间的多样性，核心网络应实现[RFC4920]中定义的回退信令扩展。注意，已知在[RFC4920]所述的某些情况下，回退信号会导致较慢的设置时间和次优路径。
In scenarios where a PCE is deployed and used to perform path computation, typically the ingress node of the core network (e.g., node CN1 in Figure 1) could consult a PCE to allocate identifiers, which are used to signal path diversity constraints. In other deployment scenarios, a PCE is deployed at a network node(s) or it is
在PCE被部署并用于执行路径计算的场景中，通常核心网络的入口节点（例如，图1中的节点CN1）可以咨询PCE以分配标识符，该标识符用于向路径分集约束发送信号。在其他部署场景中，PCE部署在网络节点上，或者
part of a Network Management System (NMS). In all these cases, the PCE is consulted and the Path Key, as defined in [RFC5520], can be used in RSVP signaling as the identifier to ensure diversity.
网络管理系统（NMS）的一部分。在所有这些情况下，咨询PCE，并且[RFC5520]中定义的路径密钥可在RSVP信令中用作标识符，以确保分集。
An example of specifying LSP diversity using a Path Key is shown in Figure 2, where a simple network with two domains is shown. It is desired to set up a pair of path-disjoint LSPs from the source in Domain 1 to the destination in Domain 2, but the domains keep strict confidentiality about all path and topology information.
图2显示了使用路径键指定LSP分集的示例，其中显示了一个具有两个域的简单网络。希望从域1中的源到域2中的目标建立一对路径不相交的LSP，但域对所有路径和拓扑信息严格保密。
The first LSP is signaled by the source with ERO {A, B, loose Dst} and is set up with the path {Src, A, B, U, V, W, Dst}. However, when sending the Record Route Object (RRO) out of Domain 2, node U would normally strip the path and replace it with a loose hop to the destination. With this limited information, the source is unable to include enough detail in the ERO of the second LSP to avoid it taking, for example, the path {Src, C, D, X, V, W, Dst} for path-disjointness.
第一个LSP由源用ERO{A，B，loose Dst}发出信号，并用路径{Src，A，B，U，V，W，Dst}设置。然而，当从域2发送记录路由对象（RRO）时，节点U通常会剥离路径，并将其替换为到目的地的松散跃点。在这种有限信息的情况下，源无法在第二LSP的ERO中包含足够的细节，以避免它采用例如路径{Src，C，D，X，V，W，Dst}作为路径不相交性。
--------------------- -----------------------------
| Domain 1 | | Domain 2 |
| | | |
| --- --- | | --- --- --- |
| | A |--| B |--+--+--| U |--| V |---| W | |
| / --- --- | | --- --- --- \ |
| ---/ | | / / \--- |
| |Src| | | / / |Dst| |
| ---\ | | / / /--- |
| \ --- --- | | --- / --- / --- / |
| | C |--| D |--+--+--| X |---| Y |--| Z | |
| --- --- | | --- --- --- |
| | | |
--------------------- -----------------------------
--------------------- -----------------------------
| Domain 1 | | Domain 2 |
| | | |
| --- --- | | --- --- --- |
| | A |--| B |--+--+--| U |--| V |---| W | |
| / --- --- | | --- --- --- \ |
| ---/ | | / / \--- |
| |Src| | | / / |Dst| |
| ---\ | | / / /--- |
| \ --- --- | | --- / --- / --- / |
| | C |--| D |--+--+--| X |---| Y |--| Z | |
| --- --- | | --- --- --- |
| | | |
--------------------- -----------------------------
Figure 2: A Simple Multi-domain Network
图2：一个简单的多域网络
In order to support LSP diversity, node U consults the PCE and replaces the path segment {U, V, W} in the RRO with a Path Key subobject. The PCE function assigns an "identifier" and puts it into the Path Key field of the Path Key subobject. The PCE ID in the message indicates that this replacement operation was performed by node U.
为了支持LSP分集，节点U咨询PCE并用路径键子对象替换RRO中的路径段{U，V，W}。PCE函数分配一个“标识符”，并将其放入路径键子对象的路径键字段中。消息中的PCE ID表示此更换操作由节点U执行。
With this additional information, the source node is able to signal the subsequent LSPs with the ERO set to {C, D, exclude Path Key (signaled in the EXRS RSVP subobject), loose Dst}. When the signaling message reaches node X, it can consult the PCE function associated with node U to expand the Path Key in order to calculate a
有了这些附加信息，源节点能够向后续LSP发送ERO设置为{C，D，exclude Path Key（在EXRS RSVP子对象中发出信号），loose Dst}的信号。当信令消息到达节点X时，它可以参考与节点U相关联的PCE功能来扩展路径密钥以计算路径密钥
path that is diverse with respect to the first LSP. Alternatively, the source node could use an ERO of {C, D, loose Dst} and include an XRO containing the Path Key.
相对于第一个LSP不同的路径。或者，源节点可以使用{C，D，loose Dst}的ERO，并包括包含路径键的XRO。
This mechanism can work with all the Path Key resolution mechanisms, as detailed in Section 3.1 of [RFC5553]. A PCE, co-located or not, may be used to resolve the Path Key, but the node (i.e., a Label Switching Router (LSR)) can also use the Path Key information to index a path segment previously supplied to it by the entity that originated the Path Key (for example, the LSR that inserted the Path Key in the RRO or a management system).
该机制可与所有路径密钥解析机制一起使用，详见[RFC5553]第3.1节。PCE（无论是否位于同一位置）可用于解析路径密钥，但节点（即，标签交换路由器（LSR））也可使用路径密钥信息来索引先前由产生路径密钥的实体（例如，在RRO或管理系统中插入路径密钥的LSR）提供给它的路径段。
There are scenarios in which the network provides diversity-related information for a service that allows the client device to include this information in the signaling message. If the Shared Risk Link Group (SRLG) identifier information is both available and shareable (by policy) with the ENs, the procedure defined in [RFC8001] can be used to collect SRLG identifiers associated with an LSP (LSP1). When a second LSP (LSP2) needs to be diverse with respect to LSP1, the EN constructing the RSVP signaling message for setting up LSP2 can insert the SRLG identifiers associated with LSP1 as diversity constraints into the XRO using the procedure described in [RFC4874]. However, if the core network SRLG identifiers are either not available or not shareable with the ENs based on policies enforced by the core network, existing mechanisms cannot be used.
存在网络为允许客户端设备在信令消息中包括该信息的服务提供多样性相关信息的场景。如果共享风险链接组（SRLG）标识符信息可用且可与ENs共享（根据策略），则可使用[RFC8001]中定义的程序收集与LSP（LSP1）关联的SRLG标识符。当第二LSP（LSP2）需要相对于LSP1多样化时，构造用于设置LSP2的RSVP信令消息的EN可以使用[RFC4874]中描述的过程将与LSP1相关联的SRLG标识符作为多样性约束插入XRO中。但是，如果核心网络SRLG标识符不可用或无法根据核心网络实施的策略与ENs共享，则不能使用现有机制。
In this document, a signaling mechanism is defined where information signaled to the CN via the UNI does not require shared knowledge of core network SRLG information. For this purpose, the concept of a Path Affinity Set (PAS) is defined for abstracting SRLG information. The motive behind the introduction of the PAS is to minimize the exchange of diversity information between the core network (CNs) and the client devices (ENs). The PAS contains an abstract SRLG identifier associated with a given path rather than a detailed SRLG list. The PAS is a single identifier that can be used to request diversity and associate diversity. The means by which the processing node determines the path corresponding to the PAS is beyond the scope of this document.
在本文中，定义了一种信令机制，其中通过UNI向CN发送信令的信息不需要共享核心网络SRLG信息的知识。为此，定义了路径亲和集（PAS）的概念，用于抽象SRLG信息。引入PAS的动机是尽量减少核心网络（CNs）和客户端设备（EN）之间的多样性信息交换。PAS包含与给定路径关联的抽象SRLG标识符，而不是详细的SRLG列表。PAS是可用于请求分集和关联分集的单个标识符。处理节点确定与PAS对应的路径的方法超出了本文档的范围。
A CN on the core network boundary interprets the specific PAS identifier (e.g., "123") as meaning to exclude the core network SRLG information (or equivalent) that has been allocated by LSPs associated with this PAS identifier value. For example, if a path exists for the LSP with the PAS identifier "123", the CN would use local knowledge of the core network SRLGs associated with the LSPs tagged with PAS attribute "123" and use those SRLGs as constraints
核心网络边界上的CN将特定PAS标识符（例如，“123”）解释为排除与该PAS标识符值相关联的LSP分配的核心网络SRLG信息（或等效信息）。例如，如果存在具有PAS标识符“123”的LSP的路径，则CN将使用与标记有PAS属性“123”的LSP相关联的核心网络srlg的本地知识，并将这些srlg用作约束
for path computation. If a PAS identifier is used as an exclusion identifier in the connection request, the CN (UNI-N) in the core network is assumed to be able to determine the existing core network SRLG information and calculate a path that meets the determined diversity constraints.
用于路径计算。如果在连接请求中使用PAS标识符作为排除标识符，则假设核心网络中的CN（UNI-N）能够确定现有的核心网络SRLG信息并计算满足所确定的分集约束的路径。
When a CN satisfies a connection setup for an SRLG-diverse signaled path, the CN may optionally record the core network SRLG information for that connection in terms of CN-based parameters and associate that with the EN addresses in the Path message. Specifically, for Layer 1 Virtual Private Networks (L1VPNs), Port Information Tables (PITs) [RFC5251] can be leveraged to translate between client (EN) addresses and core network addresses.
当CN满足SRLG不同信号路径的连接设置时，CN可以可选地根据基于CN的参数记录该连接的核心网络SRLG信息，并将其与路径消息中的EN地址相关联。具体而言，对于第1层虚拟专用网络（L1VPN），可以利用端口信息表（PIT）[RFC5251]在客户端（EN）地址和核心网络地址之间进行转换。
The means to distribute the PAS information within the core network is beyond the scope of this document. For example, the PAS and the associated SRLG information can be distributed within the core network by an Interior Gateway Protocol (IGP) or by other means such as configuration. Regardless of means used to distribute the PAS information, the information is kept inside the core network and is not shared with the overlay network (see Figure 1).
在核心网络内分发PAS信息的方法超出了本文件的范围。例如，PAS和相关联的SRLG信息可以通过内部网关协议（IGP）或诸如配置之类的其他方式分布在核心网络内。无论采用何种方式分发PAS信息，信息都保存在核心网络内，不与覆盖网络共享（见图1）。
This section describes the signaling extensions required to address the aforementioned requirements and use cases.
本节描述了满足上述要求和用例所需的信令扩展。
New Diversity XRO subobjects are defined below for the IPv4 and IPv6 address families. Most of the fields in the IPv4 and IPv6 Diversity XRO subobjects are common and are described following the definition of the two subobjects.
下面为IPv4和IPv6地址系列定义了新的分集XRO子对象。IPv4和IPv6分集XRO子对象中的大多数字段都是公共字段，在这两个子对象的定义之后进行了描述。
The IPv4 Diversity XRO subobject is defined as follows:
IPv4分集XRO子对象定义如下：
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| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Similarly, the IPv6 Diversity XRO subobject is defined as follows:
类似地，IPv6分集XRO子对象定义如下：
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| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L flag is used in the same way as for the XRO subobjects defined in [RFC4874], that is:
L：L标志的使用方式与[RFC4874]中定义的XRO子对象相同，即：
0 indicates that the diversity constraints MUST be satisfied, and
0表示必须满足多样性约束，并且
1 indicates that the diversity constraints SHOULD be satisfied.
1表示应满足多样性约束。
XRO Type: The value is set to 38 for the IPv4 Diversity XRO subobject. The value is set to 39 for the IPv6 Diversity XRO subobject.
XRO类型：IPv4分集XRO子对象的值设置为38。IPv6分集XRO子对象的值设置为39。
Length: Per [RFC4874], the Length contains the total length of the IPv4/IPv6 subobject in bytes, including the XRO Type and Length fields. The Length is variable, depending on the Diversity Identifier Value.
长度：根据[RFC4874]，长度包含IPv4/IPv6子对象的总长度（以字节为单位），包括XRO类型和长度字段。长度是可变的，取决于分集标识符值。
Diversity Identifier Type (DI Type): Diversity Identifier Type (DI Type) indicates the way the reference LSP(s) or route(s) with which diversity is required is identified in the IPv4/IPv6 Diversity subobjects. The following three DI Type values are defined in this document:
分集标识符类型（DI类型）：分集标识符类型（DI类型）表示在IPv4/IPv6分集子对象中标识需要分集的参考LSP或路由的方式。本文件中定义了以下三个DI类型值：
DI Type value Definition
------------- --------------------------------
1 Client-Initiated Identifier
2 PCE-Allocated Identifier
3 Network-Assigned Identifier
DI Type value Definition
------------- --------------------------------
1 Client-Initiated Identifier
2 PCE-Allocated Identifier
3 Network-Assigned Identifier
Attribute Flags (A-Flags): The Attribute Flags (A-Flags) are used to communicate desirable attributes of the LSP being signaled in the IPv4/IPv6 Diversity subobjects. Each flag acts independently. Any combination of flags is permitted.
属性标志（A-标志）：属性标志（A-标志）用于传递IPv4/IPv6分集子对象中发送信号的LSP的期望属性。每面旗帜都独立运作。允许任何标志组合。
0x01 = Destination node exception Indicates that the exclusion does not apply to the destination node of the LSP being signaled.
0x01=目标节点异常表示排除不适用于发送信号的LSP的目标节点。
0x02 = Processing node exception Indicates that the exclusion does not apply to the node(s) performing ERO expansion for the LSP being signaled. An ingress UNI-N node is an example of such a node.
0x02=处理节点异常表示排除不适用于为发出信号的LSP执行ERO扩展的节点。入口UNI-N节点是此类节点的示例。
0x04 = Penultimate node exception Indicates that the penultimate node of the LSP being signaled MAY be shared with the excluded path even when this violates the exclusion flags. This flag is useful, for example, when an EN is not dual homed (like EN4 in Figure 1, where all LSPs have to go through CN5).
0x04=倒数第二个节点异常表示被发信号的LSP的倒数第二个节点可以与排除的路径共享，即使这违反了排除标志。例如，当EN不是双宿时（如图1中的EN4，其中所有LSP都必须通过CN5），此标志非常有用。
The "Penultimate node exception" flag is typically set when the destination node is single homed (e.g., EN1 or EN4 in Figure 2). In such a case, LSP diversity can only be accomplished inside the core network up to the egress node and the penultimate hop must be the same for the LSPs.
“倒数第二个节点异常”标志通常在目标节点为单宿时设置（例如，图2中的EN1或EN4）。在这种情况下，LSP分集只能在核心网络内部完成，直到出口节点，并且倒数第二跳必须与LSP相同。
0x08 = LSP ID to be ignored This flag is used to indicate tunnel-level exclusion. Specifically, this flag is used to indicate that if the diversity identifier contains an LSP ID field, then the LSP ID is to be ignored, and the exclusion applies to any LSP matching the rest of the diversity identifier.
0x08=要忽略的LSP ID此标志用于指示隧道级别排除。具体而言，该标志用于指示如果分集标识符包含LSP ID字段，则LSP ID将被忽略，并且排除适用于与分集标识符其余部分匹配的任何LSP。
Exclusion Flags (E-Flags): The Exclusion Flags are used to communicate the desired type(s) of exclusion requested in the IPv4/IPv6 Diversity subobjects. The following flags are defined. Any combination of these flags is permitted. Please note that the exclusion specified by these flags may be modified by the value of the A-Flags. For example, the node exclusion flag is ignored for the penultimate node if the "Penultimate node exception" flag of the A-Flags is set.
排除标志（E标志）：排除标志用于传达IPv4/IPv6分集子对象中请求的所需排除类型。定义了以下标志。允许这些标志的任何组合。请注意，这些标志指定的排除可能会被A标志的值修改。例如，如果设置了A标志的“倒数第二个节点例外”标志，则倒数第二个节点的节点排除标志将被忽略。
0x01 = SRLG exclusion Indicates that the path of the LSP being signaled is requested to be SRLG disjoint with respect to the excluded path specified by the IPv4/IPv6 Diversity XRO subobject.
0x01=SRLG EXCLUTION表示请求发送信号的LSP的路径与IPv4/IPv6分集XRO子对象指定的排除路径SRLG不相交。
0x02 = Node exclusion Indicates that the path of the LSP being signaled is requested to be "node diverse" from the excluded path specified by the IPv4/IPv6 Diversity XRO subobject.
0x02=节点排除表示请求发送信号的LSP路径与IPv4/IPv6分集XRO子对象指定的排除路径“节点不同”。
0x04 = Link exclusion Indicates that the path of the LSP being signaled is requested to be "link diverse" from the path specified by the IPv4/IPv6 Diversity XRO subobject.
0x04=链路排除表示请求发送信号的LSP的路径与IPv4/IPv6分集XRO子对象指定的路径“链路分集”。
0x08 = Reserved This flag is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt for both IPv4/IPv6 Diversity XRO subobjects.
0x08=保留此标志是保留的。对于IPv4/IPv6分集XRO子对象，在传输时必须将其设置为零，在接收时必须忽略。
Resvd: This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt for both IPv4/IPv6 Diversity XRO subobjects.
Resvd：此字段是保留的。对于IPv4/IPv6分集XRO子对象，在传输时必须将其设置为零，在接收时必须忽略。
IPv4/IPv6 Diversity Identifier Source Address: This field MUST be set to the IPv4/IPv6 address of the node that assigns the diversity identifier. Depending on the Diversity Identifier Type, the diversity identifier source may be a client node, PCE entity, or network node. Specifically:
IPv4/IPv6分集标识符源地址：此字段必须设置为分配分集标识符的节点的IPv4/IPv6地址。根据分集标识符类型，分集标识符源可以是客户端节点、PCE实体或网络节点。明确地：
* When the Diversity Identifier Type is set to the "Client-Initiated Identifier", the value MUST be set to IPv4/IPv6 tunnel sender address of the reference LSP against which diversity is desired. The IPv4/IPv6 tunnel sender address is as defined in [RFC3209].
* 当分集标识符类型设置为“客户端启动的标识符”时，该值必须设置为需要分集的参考LSP的IPv4/IPv6隧道发送方地址。IPv4/IPv6隧道发送方地址如[RFC3209]中所定义。
* When the Diversity Identifier Type is set to "PCE-Allocated Identifier", the value MUST be set to the IPv4/IPv6 address of the node that assigned the Path Key identifier and that can return an expansion of the Path Key or use the Path Key as exclusion in a path computation. The Path Key is defined in [RFC5553]. The PCE ID is carried in the Diversity Identifier Source Address field of the subobject.
* 当分集标识符类型设置为“PCE分配的标识符”时，该值必须设置为分配路径密钥标识符的节点的IPv4/IPv6地址，该节点可以返回路径密钥的扩展或在路径计算中将路径密钥用作排除。路径键在[RFC5553]中定义。PCE ID携带在子对象的分集标识符源地址字段中。
* When the Diversity Identifier Type is set to "Network-Assigned Identifier", the value MUST be set to the IPv4/IPv6 address of the node allocating the Path Affinity Set (PAS).
* 当分集标识符类型设置为“网络分配标识符”时，该值必须设置为分配路径关联集（PAS）的节点的IPv4/IPv6地址。
Diversity Identifier Value: Encoding for this field depends on the Diversity Identifier Type, as defined in the following.
分集标识符值：此字段的编码取决于分集标识符类型，如下所述。
When the Diversity Identifier Type is set to "Client-Initiated Identifier" in the IPv4 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded as follows:
当在IPv4分集XRO子对象中将分集标识符类型设置为“客户端启动的标识符”时，分集标识符值必须按如下方式编码：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 Tunnel Endpoint Address, Tunnel ID, Extended Tunnel ID, and LSP ID are as defined in [RFC3209].
IPv4隧道端点地址、隧道ID、扩展隧道ID和LSP ID如[RFC3209]中所定义。
When the Diversity Identifier Type is set to "Client-Initiated Identifier" in the IPv6 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded as follows:
当在IPv6分集XRO子对象中将分集标识符类型设置为“客户端启动的标识符”时，必须按照以下方式对分集标识符值进行编码：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Tunnel Endpoint Address, Tunnel ID, IPv6 Extended Tunnel ID, and LSP ID are as defined in [RFC3209].
IPv6隧道端点地址、隧道ID、IPv6扩展隧道ID和LSP ID如[RFC3209]中所定义。
When the Diversity Identifier Type is set to "PCE-Allocated Identifier" in the IPv4 or IPv6 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded as follows:
当在IPv4或IPv6分集XRO子对象中将分集标识符类型设置为“PCE分配标识符”时，分集标识符值必须按如下方式编码：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Key is defined in [RFC5553].
路径键在[RFC5553]中定义。
When the Diversity Identifier Type is set to "Network-Assigned Identifier" in the IPv4 or IPv6 Diversity XRO subobject, the Diversity Identifier Value MUST be encoded as follows:
当在IPv4或IPv6分集XRO子对象中将分集标识符类型设置为“网络分配标识符”时，分集标识符值必须按如下方式编码：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Affinity Set (PAS) Identifier field is a 32-bit value that is scoped by (i.e., is only meaningful when used in combination with) the Diversity Identifier Source Address field. There are no restrictions on how a node selects a PAS identifier value. Section 1.3 defines the PAS term and provides context on how values may be selected.
路径关联集（PAS）标识符字段是一个32位的值，其范围由分集标识符源地址字段限定（即，只有与分集标识符源地址字段结合使用时才有意义）。节点选择PAS标识符值的方式没有限制。第1.3节定义了PAS术语，并提供了如何选择值的上下文。
[RFC4874] defines the EXRS ERO subobject. An EXRS is used to identify abstract nodes or resources that must not or should not be used on the path between two inclusive abstract nodes or resources in the explicit route. An EXRS contains one or more subobjects of its own, called EXRS subobjects [RFC4874].
[RFC4874]定义EXRS ERO子对象。EXRS用于标识在显式路由中两个包含的抽象节点或资源之间的路径上不能或不应该使用的抽象节点或资源。EXRS包含自己的一个或多个子对象，称为EXRS子对象[RFC4874]。
An EXRS MAY include a Diversity subobject as specified in this document. The same type values 38 and 39 MUST be used.
EXRS可包括本文件规定的多样性子对象。必须使用相同的类型值38和39。
The procedure defined in [RFC4874] for processing the XRO and EXRS is not changed by this document. The processing rules for the Diversity XRO and EXRS subobjects are similar unless the differences are explicitly described. Similarly, IPv4 and IPv6 Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS subobjects follow the same processing rules.
[RFC4874]中定义的用于处理XRO和EXRS的程序不因本文件而改变。分集XRO和EXRS子对象的处理规则相似，除非明确说明差异。类似地，IPv4和IPv6分集XRO子对象以及IPv4和IPv6分集EXRS子对象遵循相同的处理规则。
If the processing node cannot recognize the Diversity XRO/EXRS subobject, the node is expected to follow the procedure defined in [RFC4874].
如果处理节点无法识别分集XRO/EXRS子对象，则该节点应遵循[RFC4874]中定义的过程。
An XRO/EXRS object MAY contain multiple Diversity subobjects of the same DI Type. For example, in order to exclude multiple Path Keys, a node MAY include multiple Diversity XRO subobjects, each with a different Path Key. Similarly, in order to exclude the routes taken by multiple LSPs, a node MAY include multiple Diversity XRO/EXRS subobjects, each with a different LSP identifier. Likewise, to exclude multiple PAS identifiers, a node MAY include multiple
XRO/EXRS对象可能包含相同DI类型的多个分集子对象。例如，为了排除多个路径键，节点可以包括多个分集XRO子对象，每个子对象具有不同的路径键。类似地，为了排除多个LSP采用的路由，节点可以包括多个分集XRO/EXRS子对象，每个子对象具有不同的LSP标识符。类似地，为了排除多个PAS标识符，节点可以包括多个PAS标识符
Diversity XRO/EXRS subobjects, each with a different PAS identifier. However, all Diversity subobjects in an XRO/EXRS MUST contain the same Diversity Identifier Type. If a Path message contains an XRO/ EXRS with multiple Diversity subobjects of different DI Types, the processing node MUST return a PathErr with the error code "Routing Problem" (24) and error sub-code "XRO/EXRS Too Complex" (68/69).
多样性XRO/EXRS子对象，每个子对象具有不同的PAS标识符。但是，XRO/EXRS中的所有分集子对象必须包含相同的分集标识符类型。如果路径消息包含具有不同DI类型的多个分集子对象的XRO/EXRS，则处理节点必须返回一个路径错误，错误代码为“路由问题”（24），错误子代码为“XRO/EXRS过于复杂”（68/69）。
If the processing node recognizes the Diversity XRO/EXRS subobject but does not support the DI Type, it MUST return a PathErr with the error code "Routing Problem" (24) and error sub-code "Unsupported Diversity Identifier Type" (36).
如果处理节点识别分集XRO/EXRS子对象，但不支持DI类型，则必须返回一个路径错误，错误代码为“路由问题”（24），错误子代码为“不支持的分集标识符类型”（36）。
In the case of DI Type "Client-Initiated Identifier", all nodes along the path SHOULD process the diversity information signaled in the XRO/EXRS Diversity subobjects to verify that the signaled diversity constraint is satisfied. If a diversity violation is detected, crankback signaling MAY be initiated.
在DI类型“客户机启动标识符”的情况下，路径上的所有节点都应处理XRO/EXRS分集子对象中发送的分集信息，以验证是否满足发送的分集约束。如果检测到分集冲突，则可启动回退信令。
In the case of DI Type "PCE-Allocated Identifier" and "Network-Assigned Identifier", the nodes in the domain that perform path computation SHOULD process the diversity information signaled in the XRO/EXRS Diversity subobjects as follows. In the PCE case, the ingress node of a domain sends a path computation request for a path from ingress node to egress node, including diversity constraints to a PCE. Or, in the PAS case, the ingress node is capable of calculating the path for the new LSP from ingress node to the egress node, taking the diversity constraints into account. The calculated path is then carried in the Explicit Route Object (ERO). Hence, the transit nodes in a domain and the domain egress node SHOULD NOT process the signaled diversity information unless path computation is performed.
在DI类型“PCE分配标识符”和“网络分配标识符”的情况下，域中执行路径计算的节点应处理XRO/EXRS分集子对象中发送的分集信息，如下所示。在PCE情况下，域的入口节点向PCE发送从入口节点到出口节点的路径的路径计算请求，包括分集约束。或者，在PAS情况下，入口节点能够计算新LSP从入口节点到出口节点的路径，同时考虑分集约束。然后在显式路由对象（ERO）中携带计算出的路径。因此，除非执行路径计算，否则域中的传输节点和域出口节点不应处理发信号的分集信息。
While processing the EXRS object, if a loose hop expansion results in the creation of another loose hop in the outgoing ERO, the processing node MAY include the EXRS in the newly created loose hop for further processing by downstream nodes.
在处理EXRS对象时，如果松散跃点扩展导致在传出ERO中创建另一个松散跃点，则处理节点可以在新创建的松散跃点中包括EXRS，以供下游节点进一步处理。
The A-Flags affect the processing of the Diversity XRO/EXRS subobject as follows:
A标志影响分集XRO/EXRS子对象的处理，如下所示：
o When the "Processing node exception" flag is set, the exclusion MUST be ignored for the node processing the XRO or EXRS subobject.
o 设置“处理节点异常”标志时，必须忽略处理XRO或EXRS子对象的节点的排除。
o When the "Destination node exception" flag is set, the exclusion MUST be ignored for the destination node in processing the XRO subobject. The destination node exception for the EXRS subobject applies to the explicit node identified by the ERO subobject that
o 设置“目标节点异常”标志时，在处理XRO子对象时，必须忽略目标节点的排除。EXRS子对象的目标节点例外适用于ERO子对象标识的显式节点，该子对象
identifies the next abstract node. When the "Destination node exception" flag is set in the EXRS subobject, exclusion MUST be ignored for said node (i.e., the next abstract node).
标识下一个抽象节点。当在EXRS子对象中设置“目标节点异常”标志时，必须忽略所述节点（即下一个抽象节点）的排除。
o When the "Penultimate node exception" flag is set in the XRO subobject, the exclusion MUST be ignored for the penultimate node on the path of the LSP being established.
o 当在XRO子对象中设置“倒数第二个节点异常”标志时，必须忽略正在建立的LSP路径上倒数第二个节点的排除。
The penultimate node exception for the EXRS subobject applies to the node before the explicit node identified by the ERO subobject that identifies the next abstract node. When the "Penultimate node exception" flag is set in the EXRS subobject, the exclusion MUST be ignored for said node (i.e., the node before the next abstract node).
EXRS子对象的倒数第二个节点例外适用于由标识下一个抽象节点的ERO子对象标识的显式节点之前的节点。当在EXRS子对象中设置“倒数第二个节点异常”标志时，必须忽略所述节点（即，下一个抽象节点之前的节点）的排除。
If the L-flag of the Diversity XRO subobject or Diversity EXRS subobject is not set, the processing node proceeds as follows.
如果未设置Diversity XRO子对象或Diversity EXRS子对象的L标志，则处理节点按如下步骤进行。
o If the Diversity Identifier Type is set to "Client-Initiated Identifier", the processing node MUST ensure that the path calculated/expanded for the signaled LSP is diverse from the route taken by the LSP identified in the Diversity Identifier Value field.
o 如果分集标识符类型设置为“客户端启动标识符”，则处理节点必须确保为发信号的LSP计算/扩展的路径不同于分集标识符值字段中标识的LSP所采用的路由。
o If the Diversity Identifier Type is set to "PCE-Allocated Identifier", the processing node MUST ensure that any path calculated for the signaled LSP is diverse from the route identified by the Path Key. The processing node MAY use the PCE identified by the Diversity Identifier Source Address in the subobject for route computation. The processing node MAY use the Path Key resolution mechanisms described in [RFC5553].
o 如果分集标识符类型设置为“PCE分配的标识符”，则处理节点必须确保为发信号的LSP计算的任何路径与路径键标识的路由不同。处理节点可以使用由子对象中的分集标识符源地址标识的PCE进行路由计算。处理节点可以使用[RFC5553]中描述的路径密钥解析机制。
o If the Diversity Identifier Type is set to "Network-Assigned Identifier", the processing node MUST ensure that the path calculated for the signaled LSP is diverse with respect to the values associated with the PAS Identifier and Diversity Identifier Source Address fields.
o 如果分集标识符类型设置为“网络分配标识符”，则处理节点必须确保为发信号的LSP计算的路径相对于与PAS标识符和分集标识符源地址字段相关联的值是不同的。
o Regardless of whether the path computation is performed locally or at a remote node (e.g., PCE), the processing node MUST ensure that any path calculated for the signaled LSP is diverse from the requested Exclusion Flags.
o 无论路径计算是在本地还是在远程节点（例如，PCE）上执行，处理节点必须确保为发信号的LSP计算的任何路径不同于请求的排除标志。
o If the excluded path referenced in the XRO subobject is unknown to the processing node, the processing node SHOULD ignore the Diversity XRO subobject and SHOULD proceed with the signaling request. After sending the Resv for the signaled LSP, the
o 如果处理节点不知道XRO子对象中引用的排除路径，则处理节点应忽略分集XRO子对象，并应继续发送信令请求。为发信号的LSP发送Resv后
processing node MUST return a PathErr with the error code "Notify Error" (25) and error sub-code "Route of XRO LSP identifier unknown" (14) for the signaled LSP.
对于发信号的LSP，处理节点必须返回一个路径错误，错误代码为“Notify error”（25），错误子代码为“Route of XRO LSP identifier unknown”（14）。
o If the processing node fails to find a path that meets the requested constraint, the processing node MUST return a PathErr with the error code "Routing Problem" (24) and error sub-code "Route blocked by Exclude Route" (67).
o 如果处理节点未能找到满足请求约束的路径，则处理节点必须返回一个路径错误，错误代码为“Routing Problem”（路由问题）（24），错误子代码为“Route blocked by Exclude Route”（67）。
If the L-flag of the Diversity XRO subobject or Diversity EXRS subobject is set, the processing node proceeds as follows:
如果设置了Diversity XRO子对象或Diversity EXRS子对象的L标志，则处理节点按如下方式进行：
o If the Diversity Identifier Type is set to "Client-Initiated Identifier", the processing node SHOULD ensure that the path calculated/expended for the signaled LSP is diverse from the route taken by the LSP identified in the Diversity Identifier Value field.
o 如果分集标识符类型设置为“客户端启动标识符”，则处理节点应确保为信号LSP计算/扩展的路径与分集标识符值字段中标识的LSP所采用的路由不同。
o If the Diversity Identifier Type is set to "PCE-Allocated Identifier", the processing node SHOULD ensure that the path calculated for the signaled LSP is diverse from the route identified by the Path Key.
o 如果分集标识符类型设置为“PCE分配标识符”，则处理节点应确保为发信号的LSP计算的路径与路径键标识的路由不同。
o If the Diversity Identifier Type is set to "Network-Assigned Identifier", the processing node SHOULD ensure that the path calculated for the signaled LSP is diverse with respect to the values associated with the PAS Identifier and Diversity Identifier Source Address fields.
o 如果分集标识符类型设置为“网络分配标识符”，则处理节点应确保为发信号的LSP计算的路径相对于与PAS标识符和分集标识符源地址字段相关联的值是不同的。
o If the processing node fails to find a path that meets the requested constraint, it SHOULD proceed with signaling using a suitable path that meets the constraint as far as possible. After sending the Resv for the signaled LSP, it MUST return a PathErr message with error code "Notify Error" (25) and error sub-code "Failed to satisfy Exclude Route" (15) to the source node.
o 如果处理节点未能找到满足所请求约束的路径，则应尽可能使用满足约束的适当路径继续发送信号。在为发信号的LSP发送Resv后，它必须向源节点返回一条PathErr消息，该消息包含错误代码“Notify error”（25）和错误子代码“Failed to Explude Route”（15）。
If, subsequent to the initial signaling of a diverse LSP, an excluded path referenced in the XRO subobject becomes known to the processing node or a change in the excluded path becomes known to the processing node, the processing node MUST re-evaluate the exclusion and diversity constraints requested by the diverse LSP to determine whether they are still satisfied.
如果在多样化LSP的初始信令之后，处理节点知道XRO子对象中引用的排除路径，或者处理节点知道排除路径中的变化，处理节点必须重新评估不同LSP请求的排除和多样性约束，以确定它们是否仍然得到满足。
o In the case where the L-flag was not set in the initial setup message, the exclusion and diversity constraints were satisfied at the time of the initial setup. If the processing node re-evaluating the exclusion and diversity constraints for a diverse LSP detects that the exclusion and diversity constraints are no
o 在初始设置消息中未设置L标志的情况下，在初始设置时满足排除和多样性约束。如果处理节点重新评估不同LSP的排除和多样性约束，则检测到排除和多样性约束为否
longer met, it MUST send a PathErr message for the diverse LSP with the error code "Routing Problem" (24) and error sub-code "Route blocked by Exclude Route" (67). The Path_State_Removed (PSR) flag [RFC3473] MUST NOT be set. A source node receiving a PathErr message with this error code and sub-code combination SHOULD take appropriate actions and move the diverse LSP to a new path that meets the original constraints.
如果满足的时间更长，它必须为不同的LSP发送PathErr消息，错误代码为“路由问题”（24），错误子代码为“路由被排除路由阻塞”（67）。不得设置路径状态移除（PSR）标志[RFC3473]。接收带有此错误代码和子代码组合的PathErr消息的源节点应采取适当的操作，并将不同的LSP移动到满足原始约束的新路径。
o In the case where the L-flag was set in the initial setup message, the exclusion and diversity constraints may or may not be satisfied at any given time. If the exclusion constraints for a diverse LSP were satisfied before, and if the processing node re-evaluating the exclusion and diversity constraints for a diverse LSP detects that exclusion and diversity constraints are no longer met, it MUST send a PathErr message for the diverse LSP with the error code "Notify Error" (25) and error sub-code "Failed to satisfy Exclude Route" (15). The PSR flag MUST NOT be set. The source node MAY take no consequent action and keep the LSP along the path that does not meet the original constraints. Similarly, if the exclusion constraints for a diverse LSP were not satisfied before, and if the processing node re-evaluating the exclusion and diversity constraints for a diverse LSP detects that the exclusion constraints are met, it MUST send a PathErr message for the diverse LSP with the error code "Notify Error" (25) and a new error sub-code "Compliant path exists" (16). The PSR flag MUST NOT be set. A source node receiving a PathErr message with this error code and sub-code combination MAY move the diverse LSP to a new path that meets the original constraints.
o 在初始设置消息中设置了L标志的情况下，排除和多样性约束在任何给定时间都可能得到满足，也可能得不到满足。如果以前满足了多样化LSP的排除约束，并且如果处理节点重新评估多样化LSP的排除和多样性约束时检测到不再满足排除和多样性约束，则它必须为多样化LSP发送一条PathErr消息，错误代码为“Notify error”（25）和错误子代码“未能满足排除路由”（15）。不得设置PSR标志。源节点可能不会采取后续操作，并沿不满足原始约束的路径保持LSP。类似地，如果以前未满足多样性LSP的排除约束，并且如果处理节点重新评估多样性LSP的排除和多样性约束，则检测到在满足排除约束时，它必须发送不同LSP的PathErr消息，错误代码为“Notify error”（25），新的错误子代码为“Compliant path exists”（16）。不得设置PSR标志。接收带有此错误代码和子代码组合的PathErr消息的源节点可能会将不同的LSP移动到满足原始约束的新路径。
This document does not introduce any additional security issues in addition to those identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC2747], [RFC4874], [RFC5520], and [RFC5553].
除[RFC5920]、[RFC2205]、[RFC3209]、[RFC3473]、[RFC2747]、[RFC4874]、[RFC5520]和[RFC5553]中确定的安全问题外，本文件不引入任何其他安全问题。
The diversity mechanisms defined in this document rely on the new diversity subobject that is carried in the XRO or EXRS, respectively. In Section 7 of [RFC4874], it is noted that some administrative boundaries may remove the XRO due to security concerns on explicit route information exchange. However, when the diversity subobjects specified in this document are used, removing at the administrative boundary an XRO containing these diversity subobjects would result in the request for diversity being dropped at the boundary, and path computation would be unlikely to produce the requested diverse path. As such, diversity subobjects MUST be retained in an XRO crossing an administrative boundary, even if other subobjects are removed. This
本文件中定义的多样性机制分别依赖于XRO或EXRS中携带的新多样性子对象。在[RFC4874]第7节中，需要注意的是，由于显式路线信息交换的安全问题，一些行政边界可能会删除XRO。但是，当使用本文档中指定的多样性子对象时，在管理边界处删除包含这些多样性子对象的XRO将导致在边界处丢弃多样性请求，并且路径计算不太可能生成请求的多样性路径。因此，多样性子对象必须保留在跨越管理边界的XRO中，即使删除了其他子对象。这
retention would be based on operator policy. The use of diversity subobjects is based on mutual agreement. This avoids the need to share the identity of network resources when supporting diversity.
保留将基于运营商政策。多样性子对象的使用基于相互约定。这避免了在支持多样性时需要共享网络资源的身份。
IANA has assigned new values defined in this document and summarized in this section.
IANA分配了本文件中定义的新值，并在本节中进行了总结。
In the IANA registry for RSVP parameters, under "Class Names, Class Numbers, and Class Types", this document defines two new subobjects for the EXCLUDE_ROUTE object [RFC4874], C-Type 1 (see "Class Types or C-Types - 232 EXCLUDE_ROUTE" on <https://www.iana.org/assignments/ rsvp-parameters>).
在RSVP参数的IANA注册表中，在“类名、类号和类类型”下，本文档为排除路由对象[RFC4874]C-Type 1定义了两个新的子对象（请参阅上的“类类型或C-Type-232排除路由”）<https://www.iana.org/assignments/ rsvp参数>）。
+----------------+-------+
| Description | Value |
+----------------+-------+
| IPv4 Diversity | 38 |
| IPv6 Diversity | 39 |
+----------------+-------+
+----------------+-------+
| Description | Value |
+----------------+-------+
| IPv4 Diversity | 38 |
| IPv6 Diversity | 39 |
+----------------+-------+
The Diversity XRO subobjects are also defined as new EXRS subobjects (see "Class Types or C-Types - 20 EXPLICIT_ROUTE" on <https://www.iana.org/assignments/rsvp-parameters>). The same numeric values have been assigned:
多样性XRO子对象也被定义为新的EXRS子对象（请参阅上的“类类型或C类型-20显式路径”）<https://www.iana.org/assignments/rsvp-parameters>). 已指定相同的数值：
+----------------+-------+
| Description | Value |
+----------------+-------+
| IPv4 Diversity | 38 |
| IPv6 Diversity | 39 |
+----------------+-------+
+----------------+-------+
| Description | Value |
+----------------+-------+
| IPv4 Diversity | 38 |
| IPv6 Diversity | 39 |
+----------------+-------+
In the IANA registry for RSVP parameters, under "Error Codes and Globally Defined Error Value Sub-Codes", for Error Code "Routing Problem" (24) (see [RFC3209]), the following sub-codes are defined (see "Sub-Codes - 24 Routing Problem" on <https://www.iana.org/assignments/rsvp-parameters>).
在RSVP参数的IANA注册表中，在“错误代码和全局定义的错误值子代码”下，对于错误代码“路由问题”（24）（参见[RFC3209]），定义了以下子代码（参见上的“子代码-24路由问题”）<https://www.iana.org/assignments/rsvp-parameters>).
+-------+---------------------------------------+-----------+
| Value | Description | Reference |
+-------+---------------------------------------+-----------+
| 36 | Unsupported Diversity Identifier Type | RFC 8390 |
+-------+---------------------------------------+-----------+
+-------+---------------------------------------+-----------+
| Value | Description | Reference |
+-------+---------------------------------------+-----------+
| 36 | Unsupported Diversity Identifier Type | RFC 8390 |
+-------+---------------------------------------+-----------+
For Error Code "Notify Error" (25) (see [RFC3209]), the following sub-codes are defined (see "Sub-Codes - 25 Notify Error" on <https://www.iana.org/assignments/rsvp-parameters>).
对于错误代码“Notify Error”（25）（参见[RFC3209]），定义了以下子代码（参见上的“子代码-25 Notify Error”）<https://www.iana.org/assignments/rsvp-parameters>).
+-------+-------------------------------------+-----------+
| Value | Description | Reference |
+-------+-------------------------------------+-----------+
| 14 | Route of XRO LSP identifier unknown | RFC 8390 |
| 15 | Failed to satisfy Exclude Route | RFC 8390 |
| 16 | Compliant path exists | RFC 8390 |
+-------+-------------------------------------+-----------+
+-------+-------------------------------------+-----------+
| Value | Description | Reference |
+-------+-------------------------------------+-----------+
| 14 | Route of XRO LSP identifier unknown | RFC 8390 |
| 15 | Failed to satisfy Exclude Route | RFC 8390 |
| 16 | Compliant path exists | RFC 8390 |
+-------+-------------------------------------+-----------+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, <https://www.rfc-editor.org/info/rfc2747>.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，DOI 10.17487/RFC2747，2000年1月<https://www.rfc-editor.org/info/rfc2747>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<https://www.rfc-editor.org/info/rfc3473>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <https://www.rfc-editor.org/info/rfc4202>.
[RFC4202]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，DOI 10.17487/RFC4202，2005年10月<https://www.rfc-editor.org/info/rfc4202>.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, April 2007, <https://www.rfc-editor.org/info/rfc4874>.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 4874，DOI 10.17487/RFC4874，2007年4月<https://www.rfc-editor.org/info/rfc4874>.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007, <https://www.rfc-editor.org/info/rfc4920>.
[RFC4920]Farrel，A.，Ed.，Satyanarayana，A.，Iwata，A.，Fujita，N.，和G.Ash，“MPLS和GMPLS RSVP-TE的回退信令扩展”，RFC 4920，DOI 10.17487/RFC4920，2007年7月<https://www.rfc-editor.org/info/rfc4920>.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource Reservation Protocol (RSVP) Extensions for Path Key Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, <https://www.rfc-editor.org/info/rfc5553>.
[RFC5553]Farrel，A.，Ed.，Bradford，R.，和JP。Vasseur，“路径密钥支持的资源预留协议（RSVP）扩展”，RFC 5553，DOI 10.17487/RFC5553，2009年5月<https://www.rfc-editor.org/info/rfc5553>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源保留协议（RSVP）——版本1功能规范”，RFC 2205，DOI 10.17487/RFC2205，1997年9月<https://www.rfc-editor.org/info/rfc2205>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, <https://www.rfc-editor.org/info/rfc4208>.
[RFC4208]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持”，RFC 4208，DOI 10.17487/RFC4208，2005年10月<https://www.rfc-editor.org/info/rfc4208>.
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, DOI 10.17487/RFC5251, July 2008, <https://www.rfc-editor.org/info/rfc5251>.
[RFC5251]Fedyk，D.，Ed.，Rekhter，Y.，Ed.，Papadimitriou，D.，Rabbat，R.，和L.Berger，“第1层VPN基本模式”，RFC 5251，DOI 10.17487/RFC5251，2008年7月<https://www.rfc-editor.org/info/rfc5251>.
[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, DOI 10.17487/RFC5520, April 2009, <https://www.rfc-editor.org/info/rfc5520>.
[RFC5520]Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，DOI 10.17487/RFC5520，2009年4月<https://www.rfc-editor.org/info/rfc5520>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
[RFC8001] Zhang, F., Ed., Gonzalez de Dios, O., Ed., Margaria, C., Hartley, M., and Z. Ali, "RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information", RFC 8001, DOI 10.17487/RFC8001, January 2017, <https://www.rfc-editor.org/info/rfc8001>.
[RFC8001]Zhang，F.，Ed.，Gonzalez de Dios，O.，Ed.，Margaria，C.，Hartley，M.，和Z.Ali，“收集共享风险链接组（SRLG）信息的RSVP-TE扩展”，RFC 8001，DOI 10.17487/RFC8001，2017年1月<https://www.rfc-editor.org/info/rfc8001>.
Acknowledgements
致谢
The authors would like to thank Xihua Fu for his contributions. The authors also would like to thank Luyuan Fang and Walid Wakim for their review and comments.
作者要感谢傅锡华的贡献。作者还要感谢方禄源和瓦利德·瓦金的评论和评论。
Contributors
贡献者
Igor Bryskin Huawei Technologies Email: Igor.Bryskin@huawei.com
Igor Bryskin华为技术公司电子邮件：Igor。Bryskin@huawei.com
Daniele Ceccarelli Ericsson Email: Daniele.Ceccarelli@ericsson.com
Daniele Ceccarelli Ericsson电子邮件：Daniele。Ceccarelli@ericsson.com
Dhruv Dhody Huawei Technologies Email: dhruv.ietf@gmail.com
Dhruv Dhody华为技术公司电子邮件：Dhruv。ietf@gmail.com
Don Fedyk Hewlett-Packard Enterprise Email: don.fedyk@hpe.com
Don Fedyk Hewlett-Packard企业电子邮件：Don。fedyk@hpe.com
Clarence Filsfils Cisco Systems, Inc. Email: cfilsfil@cisco.com
Clarence Filsfils Cisco Systems，Inc.电子邮件：cfilsfil@cisco.com
Gabriele Maria Galimberti Cisco Systems Email: ggalimbe@cisco.com
Gabriele Maria Galimberti Cisco Systems电子邮件：ggalimbe@cisco.com
Ori Gerstel SDN Solutions Ltd. Email: origerstel@gmail.com
Ori Gerstel SDN Solutions Ltd.电子邮件：origerstel@gmail.com
Oscar Gonzalez de Dios Telefonica I+D Email: ogondio@tid.es
Oscar Gonzalez de Dios Telefonica I+D电子邮件：ogondio@tid.es
Matt Hartley Cisco Systems Email: mhartley@cisco.com
Matt Hartley Cisco Systems电子邮件：mhartley@cisco.com
Kenji Kumaki KDDI Corporation Email: ke-kumaki@kddi.com
Kenji Kumaki KDDI公司电子邮件：ke-kumaki@kddi.com
Ruediger Kunze Deutsche Telekom AG Email: Ruediger.Kunze@telekom.de
Ruediger Kunze Deutsche Telekom AG电子邮件：Ruediger。Kunze@telekom.de
Lieven Levrau Nokia Email: Lieven.Levrau@nokia.com
Lieven Levrau诺基亚电子邮件：Lieven。Levrau@nokia.com
Cyril Margaria Email: cyril.margaria@gmail.com
西里尔·玛格丽亚电子邮件：西里尔。margaria@gmail.com
Julien Meuric France Telecom Orange Email: julien.meuric@orange.com
Julien Meuri法国电信橙色电子邮件：Julien。meuric@orange.com
Yuji Tochio Fujitsu Email: tochio@jp.fujitsu.com
Yuji Tochio Fujitsu电子邮件：tochio@jp.fujitsu.com
Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com
Xian Zhang华为技术电子邮件：Zhang。xian@huawei.com
Authors' Addresses
作者地址
Zafar Ali (editor) Cisco Systems.
Zafar Ali（编辑）思科系统公司。
Email: zali@cisco.com
Email: zali@cisco.com
George Swallow (editor) Southend Technical Center
George Swallow（编辑）Southend技术中心
Email: swallow.ietf@gmail.com
Email: swallow.ietf@gmail.com
Fatai Zhang (editor) Huawei Technologies
张法泰（编辑）华为技术
Email: zhangfatai@huawei.com
Email: zhangfatai@huawei.com
Dieter Beller (editor) Nokia
Dieter Beller（编辑）诺基亚
Email: Dieter.Beller@nokia.com
Email: Dieter.Beller@nokia.com