Network Working Group CY. Lee
Request for Comments: 4874 A. Farrel
Updates: 3209, 3473 Old Dog Consulting
Category: Standards Track S. De Cnodder
Alcatel-Lucent
April 2007
Network Working Group CY. Lee
Request for Comments: 4874 A. Farrel
Updates: 3209, 3473 Old Dog Consulting
Category: Standards Track S. De Cnodder
Alcatel-Lucent
April 2007
Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
排除路由-资源预留协议流量工程（RSVP-TE）的扩展
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) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE).
本文档指定了使用资源预留协议流量工程（RSVP-TE）在路径设置期间通信路由排除的方法。
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.
RSVP-TE规范“RSVP-TE：LSP隧道RSVP的扩展”（RFC 3209）和RSVP-TE的GMPLS扩展，“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”（RFC 3473）允许在路径设置中显式包含抽象节点和资源，但不能被明确排除在外。
In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document.
在某些网络中，如果没有在前端计算精确的显式路径，则可以指定并通知要显式排除在路由之外的抽象节点和资源。这些排除可以应用于整个路径，或者应用于显式路径中指定的两个抽象节点之间的路径部分。本文件还规定了如何排除共享风险链接组（SRLGs）。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Scope of Exclude Routes ....................................4
1.3. Relationship to MPLS TE MIB ................................5
2. Shared Risk Link Groups .........................................6
2.1. SRLG Subobject .............................................6
3. Exclude Route List ..............................................7
3.1. EXCLUDE_ROUTE Object (XRO) .................................7
3.1.1. IPv4 Prefix Subobject ...............................8
3.1.2. IPv6 Prefix Subobject ...............................9
3.1.3. Unnumbered Interface ID Subobject ..................10
3.1.4. Autonomous System Number Subobject .................10
3.1.5. SRLG Subobject .....................................11
3.2. Processing Rules for the EXCLUDE_ROUTE Object (XRO) .......11
4. Explicit Exclusion Route .......................................13
4.1. Explicit Exclusion Route Subobject (EXRS) .................13
4.2. Processing Rules for the Explicit Exclusion Route
Subobject (EXRS) ..........................................15
5. Processing of XRO together with EXRS ...........................16
6. Minimum Compliance .............................................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................17
8.1. New ERO Subobject Type ....................................17
8.2. New RSVP-TE Class Numbers .................................18
8.3. New Error Codes ...........................................18
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. Applications ..........................................21
A.1. Inter-Area LSP Protection .................................21
A.2. Inter-AS LSP Protection ...................................22
A.3. Protection in the GMPLS Overlay Model .....................24
A.4. LSP Protection inside a Single Area .......................25
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Scope of Exclude Routes ....................................4
1.3. Relationship to MPLS TE MIB ................................5
2. Shared Risk Link Groups .........................................6
2.1. SRLG Subobject .............................................6
3. Exclude Route List ..............................................7
3.1. EXCLUDE_ROUTE Object (XRO) .................................7
3.1.1. IPv4 Prefix Subobject ...............................8
3.1.2. IPv6 Prefix Subobject ...............................9
3.1.3. Unnumbered Interface ID Subobject ..................10
3.1.4. Autonomous System Number Subobject .................10
3.1.5. SRLG Subobject .....................................11
3.2. Processing Rules for the EXCLUDE_ROUTE Object (XRO) .......11
4. Explicit Exclusion Route .......................................13
4.1. Explicit Exclusion Route Subobject (EXRS) .................13
4.2. Processing Rules for the Explicit Exclusion Route
Subobject (EXRS) ..........................................15
5. Processing of XRO together with EXRS ...........................16
6. Minimum Compliance .............................................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................17
8.1. New ERO Subobject Type ....................................17
8.2. New RSVP-TE Class Numbers .................................18
8.3. New Error Codes ...........................................18
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. Applications ..........................................21
A.1. Inter-Area LSP Protection .................................21
A.2. Inter-AS LSP Protection ...................................22
A.3. Protection in the GMPLS Overlay Model .....................24
A.4. LSP Protection inside a Single Area .......................25
The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] allow abstract nodes and resources to be explicitly included in a path setup, using the Explicit Route Object (ERO).
RSVP-TE规范[RFC3209]和GMPLS扩展[RFC3473]允许使用显式路由对象（ERO）将抽象节点和资源显式包含在路径设置中。
In some systems, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. This may be because loose hops or abstract nodes need to be prevented from selecting a route through a specific resource. This is a special case of distributed path calculation in the network.
在某些系统中，指定和通知要显式排除在路由之外的抽象节点和资源可能很有用。这可能是因为需要防止松散跃点或抽象节点通过特定资源选择路由。这是网络中分布式路径计算的一种特殊情况。
For example, route exclusion could be used in the case where two non-overlapping Label Switched Paths (LSPs) are required. In this case, one option might be to set up one path and collect its route using route recording, and then to exclude the routers on that first path from the setup for the second path. Another option might be to set up two parallel backbones, dual home the provider edge (PE) routers to both backbones, and then exclude the local router on backbone A the first time that you set up an LSP (to a particular distant PE), and exclude the local router on backbone B the second time that you set up an LSP.
例如，在需要两条非重叠标签交换路径（LSP）的情况下，可以使用路由排除。在这种情况下，一个选项可能是设置一条路径并使用路由记录收集其路由，然后从第二条路径的设置中排除第一条路径上的路由器。另一个选项可能是设置两个并行主干，将提供程序边缘（PE）路由器双归属于两个主干，然后在第一次设置LSP（到特定的远程PE）时排除主干A上的本地路由器，并在第二次设置LSP时排除主干B上的本地路由器。
Two types of exclusions are required:
需要两种类型的除外责任：
1. Exclusion of certain abstract nodes or resources on the whole path. This set of abstract nodes is referred to as the Exclude Route list.
1. 排除整个路径上的某些抽象节点或资源。这组抽象节点称为排除路由列表。
2. Exclusion of certain abstract nodes or resources between a specific pair of abstract nodes present in an ERO. Such specific exclusions are referred to as Explicit Exclusion Route.
2. 在ERO中存在的特定抽象节点对之间排除某些抽象节点或资源。此类特定排除被称为明确排除途径。
To convey these constructs within the signaling protocol, a new RSVP object and a new ERO subobject are introduced respectively.
为了在信令协议中传递这些构造，分别引入了一个新的RSVP对象和一个新的ERO子对象。
- A new RSVP-TE object is introduced to convey the Exclude Route list. This object is the EXCLUDE_ROUTE object (XRO).
- 引入一个新的RSVP-TE对象来传递排除路由列表。此对象是排除路由对象（XRO）。
- The second type of exclusion is achieved through a modification to the existing ERO. A new ERO subobject type the Explicit Exclusion Route Subobject (EXRS) is introduced to indicate an exclusion between a pair of included abstract nodes.
- 第二类排除是通过修改现有的能源监管局来实现的。引入了一种新的ERO子对象类型—显式排除路由子对象（EXRS），以指示一对包含的抽象节点之间的排除。
The knowledge of SRLGs, as defined in [RFC4216], may be used to compute diverse paths that can be used for protection. In systems where it is useful to signal exclusions, it may be useful to signal SRLGs to indicate groups of resources that should be excluded on the
[RFC4216]中定义的SRLGs知识可用于计算可用于保护的不同路径。在有助于发出排除信号的系统中，可能有助于向SRLGs发出信号，以指示应在服务器上排除的资源组
whole path or between two abstract nodes specified in an explicit path.
整个路径或在显式路径中指定的两个抽象节点之间。
This document introduces a subobject to indicate an SRLG to be signaled in either of the two exclusion methods described above. This document does not assume or preclude any other usage for this subobject. This subobject might also be appropriate for use within an Explicit Route object (ERO) or Record Route object (RRO), but this is outside the scope of this document.
本文档介绍了一个子对象，用于指示要以上述两种排除方法之一发出信号的SRLG。本文档不假定或排除此子对象的任何其他用途。此子对象也可能适合在显式路由对象（ERO）或记录路由对象（RRO）中使用，但这不在本文档的范围内。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document does not preclude a route exclusion from listing arbitrary nodes or network elements to avoid. The intent is, however, to indicate only the minimal number of subobjects to be explicitly avoided. For instance, it may be necessary to signal only the SRLGs (or Shared Risk Link Groups) to avoid. That is, the route exclusion is not intended to define the actual route by listing all of the choices to exclude at each hop, but rather to constrain the normal route selection process where loose hops or abstract nodes are to be expanded by listing certain elements to be avoided.
本文档不排除列出任意节点或网络元素以避免路由排除。但是，其目的是仅指示要显式避免的最小数量的子对象。例如，可能需要仅向SRLGs（或共享风险链接组）发出信号以避免。也就是说，路由排除的目的不是通过列出每个跃点上要排除的所有选择来定义实际路由，而是通过列出要避免的某些元素来限制正常路由选择过程，其中松散跃点或抽象节点将被扩展。
It is envisaged that most of the conventional inclusion subobjects are specified in the signaled ERO only for the area where they are pertinent. The number of subobjects to be avoided, specified in the signaled XRO, may be constant throughout the whole path setup, or the subobjects to be avoided may be removed from the XRO as they become irrelevant in the subsequent hops of the path setup.
可以设想，大多数常规包含子对象仅在信号ERO中指定为相关区域。在信号XRO中指定的要避免的子对象的数量在整个路径设置过程中可能是恒定的，或者要避免的子对象可以从XRO中删除，因为它们在路径设置的后续跃点中变得无关。
For example, consider an LSP that traverses multiple computation domains. A computation domain may be an area in the administrative or IGP sense, or may be an arbitrary division of the network for active management and path computational purposes. Let the primary path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where:
例如，考虑一个遍历多个计算域的LSP。计算域可以是行政或IGP意义上的区域，或者可以是用于主动管理和路径计算目的的网络的任意划分。假设主路径为（入口、A1、A2、AB1、B1、B2、BC1、C1、C2、出口），其中：
- Xn denotes a node in domain X, and
- Xn表示域X中的节点，并且
- XYn denotes a node on the border of domain X and domain Y.
- XYn表示域X和域Y边界上的节点。
Note that Ingress is a node in domain A, and Egress is a node in domain C. This is shown in Figure 1 where the domains correspond with areas.
注意，入口是域a中的一个节点，出口是域C中的一个节点。图1显示了这一点，其中域与区域相对应。
area A area B area C
<-------------------> <----------------> <------------------>
area A area B area C
<-------------------> <----------------> <------------------>
Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress
^ \ / | \ / | \ /
| \ / | \ / | \ /
| A3----------A4--AB2--B3--------B4--BC2--C3----------C4
| ^ ^
| | |
| | |
| | ERO: (C3-strict, C4-strict,
| | Egress-strict)
| | XRO: Not needed
| |
| ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose)
| XRO: (BC1, C1, C2)
|
ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose)
XRO: (AB1, B1, B2, BC1, C1, C2, Egress)
Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress
^ \ / | \ / | \ /
| \ / | \ / | \ /
| A3----------A4--AB2--B3--------B4--BC2--C3----------C4
| ^ ^
| | |
| | |
| | ERO: (C3-strict, C4-strict,
| | Egress-strict)
| | XRO: Not needed
| |
| ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose)
| XRO: (BC1, C1, C2)
|
ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose)
XRO: (AB1, B1, B2, BC1, C1, C2, Egress)
Figure 1: Domains Corresponding to IGP Areas
图1:IGP区域对应的域
Consider the establishment of a node-diverse protection path in the example above. The protection path must avoid all nodes on the primary path. The exclusions for area A are handled during Constrained Shortest Path First (CSPF) computation at Ingress, so the ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, AB2-strict, Egress-loose) and (AB1, B1, B2, BC1, C1, C2), respectively. At AB2, the ERO and XRO could be (B3-strict, B4- strict, BC2-strict, Egress-loose) and (BC1, C1, C2), respectively. At BC2, the ERO could be (C3-strict, C4-strict, Egress-strict) and an XRO is not needed from BC2 onwards.
在上面的示例中考虑建立节点多样性保护路径。保护路径必须避开主路径上的所有节点。区域A的排除在入口的受限最短路径优先（CSPF）计算期间处理，因此入口发出的ERO和XRO信号可能分别为（A3严格、A4严格、AB2严格、出口松散）和（AB1、B1、B2、BC1、C1、C2）。在AB2，ERO和XRO可能分别为（B3严格、B4严格、BC2严格、出口松动）和（BC1、C1、C2）。在BC2，ERO可能是（C3严格、C4严格、出口严格），并且从BC2开始不需要XRO。
In general, consideration SHOULD be given (as with explicit route) to the size of signaled data and the impact on the signaling protocol.
一般来说，应考虑（与显式路由一样）信号数据的大小以及对信令协议的影响。
[RFC3812] defines managed objects for managing and modeling MPLS-based traffic engineering. Included in [RFC3812] is a means to configure explicit routes for use on specific LSPs. This configuration allows the exclusion of certain resources.
[RFC3812]定义用于管理和建模基于MPLS的流量工程的托管对象。[RFC3812]中包含一种配置显式路由以在特定LSP上使用的方法。此配置允许排除某些资源。
In systems where the full explicit path is not computed at the ingress (or at a path computation site for use at the ingress), it may be necessary to signal those exclusions. This document offers a means of doing this signaling.
在未在入口处（或在入口处使用的路径计算站点处）计算完整显式路径的系统中，可能需要发出这些排除的信号。本文件提供了执行此信号的方法。
The identifier of an SRLG is defined as a 32-bit quantity in [RFC4202]. An SRLG subobject is introduced such that it can be used in the exclusion methods as described in the following sections. This document does not assume or preclude any other usage for this subobject. This subobject might also be appropriate for use within Explicit Route object (ERO) or Record Route object (RRO), but this is outside the scope of this document.
SRLG的标识符在[RFC4202]中定义为32位数量。引入了一个SRLG子对象，以便可以在排除方法中使用它，如以下各节所述。本文档不假定或排除此子对象的任何其他用途。此子对象可能也适合在显式路由对象（ERO）或记录路由对象（RRO）中使用，但这不在本文档的范围内。
The new SRLG subobject is defined by this document as follows. Its format is modeled on the ERO subobjects defined in [RFC3209].
新的SRLG子对象由本文档定义如下。其格式以[RFC3209]中定义的ERO子对象为模型。
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 | SRLG Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | SRLG Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route.
L位是子对象的一个属性。如果子对象表示显式路由中的松散跃点，则设置L位。如果未设置位，则子对象表示显式路由中的严格跃点。
For exclusions (as used by XRO and EXRS defined in this document), the L bit SHOULD be set to zero and ignored.
对于排除（如本文档中定义的XRO和EXRS所用），L位应设置为零并忽略。
Type The type of the subobject (34)
键入子对象的类型（34）
Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8.
长度长度包含子对象的总长度（字节），包括类型和长度字段。长度始终为8。
SRLG Id The 32-bit identifier of the SRLG.
SRLG Id—SRLG的32位标识符。
Reserved This field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
保留此字段为保留字段。传输时应将其设置为零，接收时必须忽略。
The exclude route identifies a list of abstract nodes that should not be traversed along the path of the LSP being established. It is RECOMMENDED that the size of the exclude route list be limited to a value local to the node originating the exclude route list.
exclude路由标识不应沿正在建立的LSP路径遍历的抽象节点列表。建议将排除路由列表的大小限制为发起排除路由列表的节点的本地值。
Abstract nodes to be excluded from the path are specified via the EXCLUDE_ROUTE object (XRO).
要从路径中排除的抽象节点通过EXCLUDE_ROUTE对象（XRO）指定。
Currently, one C_Type is defined, Type 1 EXCLUDE_ROUTE. The EXCLUDE_ROUTE object has the following format:
目前，定义了一种C_类型，类型1排除_路由。排除路径对象具有以下格式：
Class = 232, C_Type = 1
类别=232，C_类型=1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of an EXCLUDE_ROUTE object are a series of variable-length data items called subobjects. This specification adapts ERO subobjects as defined in [RFC3209], [RFC3473], and [RFC3477] for use in route exclusions. The SRLG subobject as defined in Section 2 of this document has not been defined before. The SRLG subobject is defined here for use with route exclusions.
排除路由对象的内容是一系列称为子对象的可变长度数据项。本规范适用于[RFC3209]、[RFC3473]和[RFC3477]中定义的ERO子对象，以用于路线排除。本文件第2节中定义的SRLG子对象以前从未定义过。此处定义的SRLG子对象用于管线排除。
The following subobject types are supported.
支持以下子对象类型。
Type Subobject
-------------+-------------------------------
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number
34 SRLG
Type Subobject
-------------+-------------------------------
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number
34 SRLG
The defined values for Type above are specified in [RFC3209] and in this document.
[RFC3209]和本文件中规定了上述类型的定义值。
The concept of loose or strict hops has no meaning in route exclusion. The L bit, defined for ERO subobjects in [RFC3209], is reused here to indicate that an abstract node MUST be excluded (value
松散跳数或严格跳数的概念在路由排除中没有意义。此处重用为[RFC3209]中的ERO子对象定义的L位，以指示必须排除抽象节点（值
0) or SHOULD be avoided (value 1). The distinction is that the path of an LSP must not traverse an abstract node listed in the XRO with the L bit clear, but may traverse one with the L bit set. A node responsible for routing an LSP (for example, for expanding a loose hop) should attempt to minimize the number of abstract nodes listed in the XRO with the L bit set that are traversed by the LSP according to local policy. A node generating XRO subobjects with the L bit set must be prepared to accept an LSP that traverses one, some, or all of the corresponding abstract nodes.
0) 或应避免使用（值1）。区别在于LSP的路径不能穿过XRO中列出的抽象节点（L位清除），但可以穿过设置了L位的抽象节点。负责路由LSP的节点（例如，用于扩展松散跃点）应尝试最小化XRO中列出的抽象节点的数量，该抽象节点的L位集由LSP根据本地策略遍历。生成具有L位集的XRO子对象的节点必须准备好接受遍历一个、一些或所有相应抽象节点的LSP。
Subobjects 1, 2, and 4 refer to an interface or a set of interfaces. An Attribute octet is introduced in these subobjects to indicate the attribute (e.g., interface, node, SRLG) associated with the interfaces that should be excluded from the path. For instance, the attribute node allows a whole node to be excluded from the path by specifying an interface of that node in the XRO subobject, in contrast to the attribute interface, which allows a specific interface (or multiple interfaces) to be excluded from the path without excluding the whole node. The attribute SRLG allows all SRLGs associated with an interface to be excluded from the path.
子对象1、2和4引用一个接口或一组接口。在这些子对象中引入属性八位组，以指示与应从路径中排除的接口相关联的属性（例如，接口、节点、SRLG）。例如，属性节点通过在XRO子对象中指定该节点的接口，允许从路径中排除整个节点，而属性接口则允许从路径中排除特定接口（或多个接口），而不排除整个节点。属性SRLG允许从路径中排除与接口关联的所有SRLG。
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 | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L 0 indicates that the attribute specified MUST be excluded. 1 indicates that the attribute specified SHOULD be avoided.
L 0表示必须排除指定的属性。1表示应避免指定的属性。
Attribute
属性
Interface attribute values 0 indicates that the interface or set of interfaces associated with the IPv4 prefix should be excluded or avoided.
接口属性值0表示应排除或避免与IPv4前缀关联的接口或接口集。
Node attribute value 1 indicates that the node or set of nodes associated with the IPv4 prefix should be excluded or avoided.
节点属性值1表示应排除或避免与IPv4前缀关联的节点或节点集。
SRLG attribute values 2 indicates that all the SRLGs associated with the IPv4 prefix should be excluded or avoided.
SRLG属性值2表示应排除或避免与IPv4前缀关联的所有SRLG。
The rest of the fields are as defined in [RFC3209].
其余字段的定义见[RFC3209]。
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 | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L 0 indicates that the attribute specified MUST be excluded. 1 indicates that the attribute specified SHOULD be avoided.
L 0表示必须排除指定的属性。1表示应避免指定的属性。
Attribute
属性
Interface attribute value 0 indicates that the interface or set of interfaces associated with the IPv6 prefix should be excluded or avoided.
接口属性值0表示应排除或避免与IPv6前缀关联的接口或接口集。
Node attribute value 1 indicates that the node or set of nodes associated with the IPv6 prefix should be excluded or avoided.
节点属性值1表示应排除或避免与IPv6前缀关联的节点或节点集。
SRLG attribute value 2 indicates that all the SRLGs associated with the IPv6 prefix should be excluded or avoided.
SRLG属性值2表示应排除或避免与IPv6前缀关联的所有SRLG。
The rest of the fields are as defined in [RFC3209].
其余字段的定义见[RFC3209]。
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 | Reserved | Attribute |
| | | |(must be zero) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved | Attribute |
| | | |(must be zero) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L 0 indicates that the attribute specified MUST be excluded. 1 indicates that the attribute specified SHOULD be avoided.
L 0表示必须排除指定的属性。1表示应避免指定的属性。
Attribute
属性
Interface attribute value 0 indicates that the Interface ID specified should be excluded or avoided.
接口属性值0表示应排除或避免指定的接口ID。
Node attribute value 1 indicates that the node with the Router ID should be excluded or avoided (this can be achieved using an IPv4/v6 subobject as well, but is included here because it may be convenient to use information from subobjects of an RRO, as defined in [RFC3477], in specifying the exclusions).
节点属性值1表示应排除或避免具有路由器ID的节点（这也可以通过使用IPv4/v6子对象来实现，但此处包括，因为在指定排除时，可以方便地使用[RFC3477]中定义的来自RRO子对象的信息）。
SRLG attribute value 2 indicates that all the SRLGs associated with the interface should be excluded or avoided.
SRLG属性值2表示应排除或避免与接口关联的所有SRLG。
Reserved This field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
保留此字段为保留字段。传输时应将其设置为零，接收时必须忽略。
The rest of the fields are as defined in [RFC3477].
其余字段的定义见[RFC3477]。
The meaning of the L bit is as follows: 0 indicates that the abstract node specified MUST be excluded. 1 indicates that the abstract node specified SHOULD be avoided.
L位的含义如下：0表示必须排除指定的抽象节点。1表示应避免指定的抽象节点。
The rest of the fields are as defined in [RFC3209]. There is no Attribute octet defined.
其余字段的定义见[RFC3209]。没有定义属性八位组。
The meaning of the L bit is as follows: 0 indicates that the SRLG specified MUST be excluded 1 indicates that the SRLG specified SHOULD be avoided
L位的含义如下：0表示必须排除指定的SRLG；1表示应避免指定的SRLG
The Attribute octet is not present. The rest of the fields are as defined in the "SRLG Subobject" section of this document.
属性八位字节不存在。其余字段的定义见本文档“SRLG子对象”部分。
The exclude route list is encoded as a series of subobjects contained in an EXCLUDE_ROUTE object. Each subobject identifies an abstract node in the exclude route list.
排除路由列表编码为包含在排除路由对象中的一系列子对象。每个子对象在排除路由列表中标识一个抽象节点。
Each abstract node may be a precisely specified IP address belonging to a node, or an IP address with prefix identifying interfaces of a group of nodes, an Autonomous System, or an SRLG.
每个抽象节点可以是属于节点的精确指定的IP地址，或者具有识别一组节点、自治系统或SRLG的接口的前缀的IP地址。
The Explicit Route and routing processing is unchanged from the description in [RFC3209] with the following additions:
显式路由和路由处理与[RFC3209]中的描述相同，但增加了以下内容：
1. When a Path message is received at a node, the node MUST check that it is not a member of any of the abstract nodes in the XRO if it is present in the Path message. If the node is a member of any of the abstract nodes in the XRO with the L-flag set to "exclude", it SHOULD return a PathErr with the error code "Routing Problem" and error value of "Local node in Exclude Route". If there are SRLGs in the XRO, the node SHOULD check that the resources the node uses are not part of any SRLG with the L-flag set to "exclude" that is specified in the XRO. If it is, it SHOULD return a PathErr with error code "Routing Problem" and error value of "Local node in Exclude Route".
1. 当在节点上接收到Path消息时，如果Path消息中存在Path消息，则节点必须检查它是否不是XRO中任何抽象节点的成员。如果该节点是XRO中L标志设置为“排除”的任何抽象节点的成员，则它应返回一个路径错误，错误代码为“路由问题”，错误值为“排除路由中的本地节点”。如果XRO中存在SRLG，则节点应检查该节点使用的资源是否不属于XRO中指定的L标志设置为“排除”的任何SRLG的一部分。如果是，它应该返回一个PathErr，错误代码为“Routing Problem”，错误值为“Exclude Route中的本地节点”。
2. Each subobject MUST be consistent. If a subobject is not consistent then the node SHOULD return a PathErr with error code "Routing Problem" and error value "Inconsistent Subobject". An example of an inconsistent subobject is an IPv4 Prefix subobject containing the IP address of a node and the attribute field is set to "interface" or "SRLG".
2. 每个子对象必须一致。如果子对象不一致，则节点应返回路径错误，错误代码为“路由问题”，错误值为“不一致的子对象”。不一致子对象的一个示例是包含节点IP地址的IPv4前缀子对象，属性字段设置为“接口”或“SRLG”。
3. The subobjects in the ERO and XRO SHOULD NOT contradict each other. If a Path message is received that contains contradicting ERO and XRO subobjects, then:
3. ERO和XRO中的子对象不应相互矛盾。如果收到包含相互矛盾的ERO和XRO子对象的路径消息，则：
- Subobjects in the XRO with the L flag not set (zero) MUST take precedence over the subobjects in the ERO -- that is, a mandatory exclusion expressed in the XRO MUST be honored and an
- 未设置L标志（零）的XRO中的子对象必须优先于ERO中的子对象——也就是说，必须遵守XRO中表示的强制排除，并且
implementation MUST reject such a Path message. This means that a PathErr with error code "Routing Problem" and error value of "Route blocked by Exclude Route" is returned.
实现必须拒绝这样的路径消息。这意味着返回错误代码为“Routing Problem”且错误值为“Route blocked by Exclude Route”的PathErr。
- Subobjects in the XRO with the L flag set do not take precedence over ERO subobjects -- that is, an implementation MAY choose to reject a Path message because of such a contradiction, but MAY continue and set up the LSP (ignoring the XRO subobjects that contradict the ERO subobjects).
- 设置了L标志的XRO中的子对象并不优先于ERO子对象——也就是说，实现可能会因为这种矛盾选择拒绝路径消息，但可能会继续并设置LSP（忽略与ERO子对象矛盾的XRO子对象）。
4. When choosing a next hop or expanding an explicit route to include additional subobjects, a node:
4. 选择下一个跃点或扩展显式路由以包含其他子对象时，节点：
a. MUST NOT introduce an explicit node or an abstract node that equals or is a member of any abstract node that is specified in the EXCLUDE_ROUTE object with the L-flag set to "exclude". The number of introduced explicit nodes or abstract nodes with the L flag set to "avoid", which indicates that it is not mandatory to be excluded but that it is less preferred, SHOULD be minimized in the computed path.
a. 不得引入与EXCLUDE_ROUTE对象中指定的L标志设置为“EXCLUDE”的任何抽象节点相等或是其成员的显式节点或抽象节点。引入的显式节点或抽象节点（L标志设置为“避免”）的数量应在计算路径中最小化，L标志设置为“避免”，表示不强制排除，但不太首选。
b. MUST NOT introduce links, nodes, or resources identified by the SRLG Id specified in the SRLG subobjects(s). The number of introduced SRLGs with the L flag set to "avoid" SHOULD be minimized.
b. 不得引入由SRLG子对象中指定的SRLG Id标识的链接、节点或资源。应尽量减少L标志设置为“避免”的引入SRLG的数量。
If these rules preclude further forwarding of the Path message, the node SHOULD return a PathErr with the error code "Routing Problem" and error value of "Route blocked by Exclude Route".
如果这些规则阻止进一步转发路径消息，则节点应返回一个PathErr，错误代码为“Routing Problem”，错误值为“Route blocked by Exclude Route”。
Note that the subobjects in the XRO is an unordered list of subobjects.
请注意，XRO中的子对象是无序的子对象列表。
A node receiving a Path message carrying an XRO MAY reject the message if the XRO is too large or complicated for the local implementation or the rules of local policy. In this case, the node MUST send a PathErr message with the error code "Routing Error" and error value "XRO Too Complex". An ingress LSR receiving this error code/value combination MAY reduce the complexity of the XRO or route around the node that rejected the XRO.
如果XRO对于本地实现或本地策略规则来说太大或太复杂，则接收到承载XRO的Path消息的节点可能会拒绝该消息。在这种情况下，节点必须发送带有错误代码“Routing error”和错误值“XRO To Complex”的PathErr消息。接收此错误代码/值组合的入口LSR可降低XRO的复杂性或拒绝XRO的节点周围的路由。
The XRO Class-Num is of the form 11bbbbbb so that nodes that do not support the XRO forward it uninspected and do not apply the extensions to ERO processing described above. This approach is chosen to allow route exclusion to traverse parts of the network that are not capable of parsing or handling the new function. Note that
XRO类Num的形式为11bbbbbb，因此不支持XRO的节点在未经检查的情况下转发它，并且不将扩展应用于上述ERO处理。选择此方法是为了允许路由排除遍历无法解析或处理新功能的网络部分。注意
Record Route may be used to allow computing nodes to observe violations of route exclusion and attempt to re-route the LSP accordingly.
记录路由可用于允许计算节点观察违反路由排除的情况，并尝试相应地重新路由LSP。
If a node supports the XRO, but not a particular subobject or part of that subobject, then that particular subobject is ignored. Examples of a part of a subobject that can be supported are: (1) only prefix 32 of the IPv4 prefix subobject could be supported, or (2) a particular subobject is supported but not the particular attribute field.
如果节点支持XRO，但不支持特定子对象或该子对象的一部分，则忽略该特定子对象。可以支持的子对象部分示例包括：（1）只能支持IPv4前缀子对象的前缀32，或者（2）支持特定子对象，但不支持特定属性字段。
When a node forwards a Path message, it can do the following three operations related to XRO besides the processing rules mentioned above:
节点转发路径消息时，除了上述处理规则外，还可以进行与XRO相关的以下三项操作：
1. If no XRO was present, an XRO may be included.
1. 如果没有XRO，则可能包括XRO。
2. If an XRO was present, it may remove the XRO if it is sure that the next nodes do not need this information anymore. An example is where a node can expand the ERO to a full strict path towards the destination. See Figure 1 where BC2 is removing the XRO from the Path message.
2. 如果存在XRO，如果确定下一个节点不再需要此信息，则可能会删除XRO。例如，节点可以将ERO扩展为指向目的地的完整严格路径。请参见图1，其中BC2正在从Path消息中删除XRO。
3. If an XRO was present, the content of the XRO can be modified. Subobjects can be added or removed. See Figure 1 for an example where AB2 is stripping off some subobjects.
3. 如果存在XRO，则可以修改XRO的内容。可以添加或删除子对象。如图1所示，AB2正在剥离一些子对象。
In any case, a node MUST NOT introduce any explicit or abstract node in the XRO (irrespective of the value of the L flag) that it also has introduced in the ERO.
在任何情况下，节点不得在XRO中引入其在ERO中也引入的任何显式或抽象节点（与L标志的值无关）。
The Explicit Exclusion Route defines abstract nodes or resources (such as links, unnumbered interfaces, or labels) that must not or should not be used on the path between two inclusive abstract nodes or resources in the explicit route.
显式排除路由定义了在显式路由中两个包含性抽象节点或资源之间的路径上不能或不应该使用的抽象节点或资源（如链接、未编号的接口或标签）。
A new ERO subobject type is defined. The Explicit Exclusion Route Subobject (EXRS) has type 33. Although the EXRS is an ERO subobject and the XRO is reusing the ERO subobject, an EXRS MUST NOT be present in an XRO. An EXRS is an ERO subobject that contains one or more subobjects of its own, called EXRS subobjects.
定义了新的ERO子对象类型。显式排除路由子对象（EXRS）的类型为33。尽管EXRS是ERO子对象，并且XRO正在重用ERO子对象，但XRO中不得存在EXRS。EXRS是包含自己的一个或多个子对象（称为EXRS子对象）的ERO子对象。
The format of the EXRS is as follows:
EXRS的格式如下：
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// one or more EXRS subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// one or more EXRS subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L It MUST be set to zero on transmission and MUST be ignored on receipt. (Note: The L bit in an EXRS subobject is as defined for the XRO subobjects.)
L传输时必须将其设置为零，接收时必须忽略。（注意：EXRS子对象中的L位与XRO子对象的定义相同。）
Type The type of the subobject (33).
键入子对象的类型（33）。
Reserved This field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
保留此字段为保留字段。传输时应将其设置为零，接收时必须忽略。
EXRS subobjects An EXRS subobject indicates the abstract node or resource to be excluded. The format of an EXRS subobject is exactly the same as the format of a subobject in the XRO. An EXRS may include all subobjects defined in this document for the XRO.
EXRS子对象EXRS子对象表示要排除的抽象节点或资源。EXRS子对象的格式与XRO中的子对象的格式完全相同。EXRS可能包括本文件中为XRO定义的所有子对象。
Thus, an EXRS for an IP hop may look as follows:
因此，IP跃点的EXRS可以如下所示：
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each EXRS may carry multiple exclusions. The exclusion is encoded exactly as for XRO subobjects and prefixed by an additional Type and Length.
每个EXR可能包含多个除外条款。排除编码与XRO子对象完全相同，并以附加类型和长度作为前缀。
The scope of the exclusion is the step between the previous ERO subobject that identifies an abstract node, and the subsequent ERO subobject that identifies an abstract node. The processing rules of the EXRS are the same as the processing rule of the XRO within this scope. Multiple exclusions may be present between any pair of abstract nodes.
排除范围是标识抽象节点的前一个ERO子对象与标识抽象节点的后续ERO子对象之间的步骤。在此范围内，EXRS的处理规则与XRO的处理规则相同。任何一对抽象节点之间可能存在多个排除。
Exclusions may indicate explicit nodes, abstract nodes, or Autonomous Systems that must not be traversed on the path to the next abstract node indicated in the ERO.
排除可能表示显式节点、抽象节点或自治系统，这些节点不得在ERO中指示的下一个抽象节点的路径上遍历。
Exclusions may also indicate resources (such as unnumbered interfaces, link ids, and labels) that must not be used on the path to the next abstract node indicated in the ERO.
排除也可能表示资源（如未编号的接口、链接ID和标签），这些资源不得用于ERO中指示的下一个抽象节点的路径。
SRLGs may also be indicated for exclusion from the path to the next abstract node in the ERO by the inclusion of an EXRS containing an SRLG subobject. If the L bit in the SRLG subobject is zero, the resources (nodes, links, etc.) identified by the SRLG MUST NOT be used on the path to the next abstract node indicated in the ERO. If the L bit is set, the resources identified by the SRLG SHOULD be avoided.
通过包含包含SRLG子对象的EXR，也可以指示SRLGs从ERO中的下一个抽象节点的路径中排除。如果SRLG子对象中的L位为零，则SRLG标识的资源（节点、链接等）不得用于ERO中指示的下一个抽象节点的路径。如果设置了L位，则应避免SRLG标识的资源。
If a node is called upon to process an EXRS and does not support handling of exclusions it will behave as described in [RFC3209] when an unrecognized ERO subobject is encountered. This means that this node will return a PathErr with error code "Routing Error" and error value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object included, truncated (on the left) to the offending EXRS.
如果某个节点被调用处理EXRS，并且不支持排除处理，则当遇到无法识别的ERO子对象时，该节点将按照[RFC3209]中所述的方式运行。这意味着此节点将返回一个PathErr，错误代码为“Routing error”，错误值为“Bad EXPLICIT_ROUTE object”，其中包含EXPLICIT_ROUTE对象，并将其截断（在左侧）到有问题的EXR。
If the presence of EXRS precludes further forwarding of the Path message, the node SHOULD return a PathErr with the error code "Routing Problem" and error value "Route Blocked by Exclude Route".
如果EXR的存在阻止了路径消息的进一步转发，则节点应返回一个路径错误，错误代码为“Routing Problem”，错误值为“Route Blocked by Exclude Route”。
A node MAY reject a Path message if the EXRS is too large or complicated for the local implementation or as governed by local policy. In this case, the node MUST send a PathErr message with the error code "Routing Error" and error value "EXRS Too Complex". An ingress LSR receiving this error code/value combination MAY reduce the complexity of the EXRS or route around the node that rejected the EXRS.
如果EXR对于本地实现来说太大或太复杂，或者受本地策略控制，则节点可能会拒绝Path消息。在这种情况下，节点必须发送一条PathErr消息，错误代码为“Routing error”，错误值为“EXRS To Complex”。接收此错误代码/值组合的入口LSR可降低EXR的复杂性或拒绝EXR的节点周围的路由。
When an LSR performs ERO expansion and finds both the XRO in the Path message and EXRS in the ERO, it MUST exclude all the SRLGs, nodes, links, and resources listed in both places. Where some elements appear in both lists, it MUST be handled according to the stricter exclusion request. That is, if one list says that an SRLG, node, link, or resource must be excluded, and the other says only that it should be avoided, then the element MUST be excluded.
当LSR执行ERO扩展并在路径消息中找到XRO和ERO中的EXR时，它必须排除在这两个位置列出的所有SRLGs、节点、链接和资源。如果某些元素出现在两个列表中，则必须根据更严格的排除请求进行处理。也就是说，如果一个列表表示必须排除SRLG、节点、链接或资源，而另一个列表仅表示应该避免，则必须排除该元素。
An implementation MUST be at least compliant with the following:
实施必须至少符合以下要求：
1. The XRO MUST be supported with the following restrictions:
1. XRO必须受到以下限制的支持：
- The IPv4 Prefix subobject MUST be supported with a prefix length of 32, and an attribute value of "interface" and "node". Other prefix values and attribute values MAY be supported.
- 必须支持前缀长度为32、属性值为“接口”和“节点”的IPv4前缀子对象。可能支持其他前缀值和属性值。
- The IPv6 Prefix subobject MUST be supported with a prefix length of 128, and an attribute value of "interface" and "node". Other prefix values and attribute values MAY be supported.
- IPv6前缀子对象必须受支持，前缀长度为128，属性值为“接口”和“节点”。可能支持其他前缀值和属性值。
2. The EXRS MAY be supported. If supported, the same restrictions as for the XRO apply. If not supported, an EXRS encountered during normal ERO processing MUST be rejected as an unknown ERO subobject as described in Section 4.2. Note that a node SHOULD NOT parse ahead into an ERO, and if it does, it MUST NOT reject the ERO if it discovers an EXRS that applies to another node.
2. 可能支持EXR。如果支持，则适用与XRO相同的限制。如果不支持，在正常ERO处理过程中遇到的EXRS必须作为未知ERO子对象拒绝，如第4.2节所述。请注意，节点不应提前解析为ERO，如果解析为ERO，则如果发现适用于其他节点的EXRS，则不得拒绝ERO。
3. If XRO or EXRS are supported, the implementation MUST be compliant with the processing rules of the supported, not supported, or partially supported subobjects as specified within this document.
3. 如果支持XRO或EXRS，则实现必须符合本文档中指定的受支持、不受支持或部分受支持子对象的处理规则。
Security considerations for MPLS-TE and GMPLS signaling are covered in [RFC3209] and [RFC3473]. This document does not introduce any new messages or any substantive new processing, and so those security considerations continue to apply.
[RFC3209]和[RFC3473]中介绍了MPLS-TE和GMPLS信令的安全注意事项。本文档没有引入任何新消息或任何实质性的新处理，因此这些安全考虑因素将继续适用。
Note that any security concerns that exist with explicit routes should be considered with regard to route exclusions. For example, some administrative boundaries may consider explicit routes to be security violations and may strip EROs from the Path messages that they process. In this case, the XRO should also be considered for removal from the Path message.
请注意，对于显式路由存在的任何安全问题，应考虑路由排除。例如，一些管理边界可能会考虑显式路由以违反安全性，并且可能会从它们所处理的路径消息中删除EOS。在这种情况下，还应考虑从Path消息中删除XRO。
It is possible that an arbitrarily complex XRO or EXRS sequence could be introduced as a form of denial-of-service attack since its presence will potentially cause additional processing at each node on the path of the LSP. It should be noted that such an attack assumes that an otherwise trusted LSR (i.e., one that has been authenticated by its neighbors) is misbehaving. A node that receives an XRO or EXRS sequence that it considers too complex according to its local policy may respond with a PathErr message carrying the error code "Routing Error" and error value "XRO Too Complex" or "EXRS Too Complex".
可能会引入任意复杂的XRO或EXRS序列作为拒绝服务攻击的一种形式，因为其存在可能会在LSP路径上的每个节点上造成额外的处理。应该注意的是，这种攻击假设其他受信任的LSR（即，已由其邻居验证的LSR）行为不正常。接收到根据其本地策略认为过于复杂的XRO或EXRS序列的节点可能会响应带有错误代码“路由错误”和错误值“XRO过于复杂”或“EXRS过于复杂”的PathErr消息。
It might be considered that an alternative approach would be to assign one of the bits of the ERO subobject type field (perhaps the top bit) to identify that a subobject is intended for inclusion rather than exclusion. However, [RFC3209] states that the type field (seven bits) should be assigned as 0 - 63 through IETF consensus action, 64 - 95 as first come first served, and 96 - 127 are reserved for private use. It would not be acceptable to disrupt existing implementations, so the only option would be to split the IETF consensus range leaving only 32 subobject types. It is felt that 32 would be an unacceptably small number for future expansion of the protocol.
可以认为，另一种方法是分配ERO子对象类型字段的一个位（可能是顶部位），以确定子对象旨在包含而不是排除。然而，[RFC3209]指出，类型字段（七位）应通过IETF一致行动分配为0-63，64-95为先到先得，96-127保留供私人使用。中断现有实现是不可接受的，因此唯一的选择是分割IETF共识范围，只留下32个子对象类型。有人认为，对于今后扩大议定书而言，32个将是一个不可接受的小数目。
IANA registry: RSVP PARAMETERS Subsection: Class Names, Class Numbers, and Class Types
IANA注册表：RSVP参数小节：类名、类号和类类型
A new subobject has been added to the existing entry for:
已将新的子对象添加到现有条目中，用于：
20 EXPLICIT_ROUTE
20号公路
The registry reads:
登记册内容如下：
33 Explicit Exclusion Route subobject (EXRS)
33显式排除路由子对象（EXRS）
The Explicit Exclusion Route subobject (EXRS) is defined in Section 4.1, "Explicit Exclusion Route Subobject (EXRS)". This subobject may be present in the Explicit Route Object, but not in the Route Record Object or in the new EXCLUDE_ROUTE object, and it should not be listed among the subobjects for those objects.
第4.1节“显式排除路由子对象（EXRS）”中定义了显式排除路由子对象（EXRS）。此子对象可能存在于显式管线对象中，但不存在于管线记录对象或新的EXCLUDE_管线对象中，并且不应在这些对象的子对象中列出。
IANA registry: RSVP PARAMETERS Subsection: Class Names, Class Numbers, and Class Types
IANA注册表：RSVP参数小节：类名、类号和类类型
A new class number has been added for EXCLUDE_ROUTE object (XRO) as defined in Section 3.1, "EXCLUDE_ROUTE Object (XRO)".
已为第3.1节“排除路由对象（XRO）”中定义的排除路由对象（XRO）添加了新的类号。
EXCLUDE_ROUTE Class-Num of type 11bbbbbb Value: 232 Defined CType: 1 (EXCLUDE_ROUTE)
排除类型11bbbbbb值为232的路由类编号定义的CType:1（排除路由）
Subobjects 1, 2, 4, and 32 are as defined for Explicit Route Object. An additional subobject has been registered as requested in Section 8.1, "New ERO Subobject Type". The text should appear as:
子对象1、2、4和32是为显式管线对象定义的。已按照第8.1节“新ERO子对象类型”的要求注册了另一个子对象。文本应显示为：
Sub-object type
1 IPv4 address [RFC3209]
2 IPv6 address [RFC3209]
4 Unnumbered Interface ID [RFC3477]
32 Autonomous system number [RFC3209]
33 Explicit Exclusion Route subobject (EXRS) [RFC4874]
34 SRLG [RFC4874]
Sub-object type
1 IPv4 address [RFC3209]
2 IPv6 address [RFC3209]
4 Unnumbered Interface ID [RFC3477]
32 Autonomous system number [RFC3209]
33 Explicit Exclusion Route subobject (EXRS) [RFC4874]
34 SRLG [RFC4874]
The SRLG subobject is defined in Section 3.1.5, "SRLG Subobject". The value 34 has been assigned.
第3.1.5节“SRLG子对象”中定义了SRLG子对象。已指定值34。
IANA registry: RSVP PARAMETERS Subsection: Error Codes and Globally-Defined Error Value Sub-Codes
IANA注册表：RSVP参数小节：错误代码和全局定义的错误值子代码
New Error Values sub-codes have been registered for the Error Code 'Routing Problem' (24).
已为错误代码“路由问题”（24）注册了新的错误值子代码。
64 = Unsupported Exclude Route Subobject Type 65 = Inconsistent Subobject 66 = Local Node in Exclude Route 67 = Route Blocked by Exclude Route 68 = XRO Too Complex 69 = EXRS Too Complex
64=不支持的排除路由子对象类型65=不一致的子对象66=排除路由中的本地节点67=排除路由阻塞的路由68=XRO太复杂69=EXRS太复杂
This document reuses text from [RFC3209] for the description of EXCLUDE_ROUTE.
本文档重用[RFC3209]中的文本来描述排除路径。
The authors would like to express their thanks to Lou Berger, Steffen Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and Richard Rabbat for their considered opinions on this document. Also thanks to Yakov Rekhter for reminding us about SRLGs!
作者感谢Lou Berger、Steffen Brockmann、Igor Bryskin、Dimitri Papadimitriou、Cristel Pelsser和Richard Rabbat对本文件的深思熟虑的意见。还感谢Yakov Rekhter提醒我们SRLGs！
Thanks to Eric Gray for providing GenArt review and to Ross Callon for his comments.
感谢Eric Gray提供GenArt评论，感谢Ross Callon的评论。
[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., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.和Y.Rekhter，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[CRANKBACK] Farrel, A., Satyanarayana, A., Iwata, A., Ash, G., and S. Marshall-Unitt, "Crankback Signaling Extensions for MPLS Signaling", Work in Progress, January 2007.
[CRANKBACK]Farrel，A.，Satyanarayana，A.，Iwata，A.，Ash，G.，和S.Marshall Unitt，“MPLS信令的回溯信令扩展”，正在进行的工作，2007年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月。
[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, October 2005.
[RFC4208]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持”，RFC 4208，2005年10月。
[RFC4216] Zhang, R. and JP. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]张，R.和JP。Vasseur，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC4216，2005年11月。
This section describes some applications that can make use of the XRO. The intention is to show that the XRO is not an application-specific object, but that it can be used for multiple purposes. In a few examples, other solutions might be possible for that particular case, but the intention is to show that a single object can be used for all the examples, hence making the XRO a rather generic object without having to define a solution and new objects for each new application.
本节介绍一些可以使用XRO的应用程序。其目的是表明XRO不是特定于应用程序的对象，而是可以用于多种用途。在一些示例中，其他解决方案可能适用于该特定情况，但目的是显示单个对象可用于所有示例，从而使XRO成为一个相当通用的对象，而无需为每个新应用程序定义解决方案和新对象。
One method to establish an inter-area LSP is where the ingress router selects an ABR, and then the ingress router computes a path towards this selected ABR such that the configured constraints of the LSP are fulfilled. In the example of Figure A.1, an LSP has to be established from node A in area 1 to node C in area 2. If no loose hops are configured, then the computed ERO at A could look as follows: (A1-strict, A2-strict, ABR1-strict, C-loose). When the Path message arrives at ABR1, then the ERO is (ABR1-strict, C-loose), and it can be expanded by ABR1 to (B1-strict, ABR3-strict, C-loose). Similarly, at ABR3 the received ERO is (ABR3-strict, C-loose), and it can be expanded to (C1-strict, C2-strict, C-strict). If a backup LSP also has to be established, then A takes another ABR (ABR2 in this case) and computes a path towards this ABR that fulfills the constraints of the LSP and that is disjoint from the path of the primary LSP. The ERO generated by A looks as follows for this example: (A3-strict, A4-strict, ABR2-strict, C-loose).
建立区域间LSP的一种方法是，入口路由器选择ABR，然后入口路由器计算朝向该选择的ABR的路径，从而满足LSP的配置约束。在图A.1的示例中，必须从区域1的节点A到区域2的节点C建立LSP。如果未配置松散跃点，则A处计算的ERO可能如下所示：（A1严格，A2严格，ABR1严格，C-松散）。当Path报文到达ABR1时，ERO为（ABR1严格，C-loose），可由ABR1扩展为（B1严格，ABR3严格，C-loose）。类似地，在ABR3，接收到的ERO是（ABR3严格，C-松散），并且它可以扩展为（C1严格，C2严格，C-严格）。如果还必须建立备份LSP，则a采用另一ABR（在本例中为ABR2）并计算到该ABR的路径，该路径满足LSP的约束并且与主LSP的路径不相交。对于本例，由A生成的ERO如下所示：（A3严格、A4严格、ABR2严格、C松散）。
In order to let ABR2 expand the ERO, it also needs to know the path of the primary LSP so that the ERO expansion is disjoint from the path of the primary LSP. Therefore, A also includes an XRO that at least contains (ABR1, B1, ABR3, C1, C2). Based on these constraints, ABR2 can expand the ERO such that it is disjoint from the primary LSP. In this example, the ERO computed by ABR2 would be (B2-strict, ABR4-strict, C-loose), and the XRO generated by B contains at least (ABR3, C1, C2). The latter information is needed for ABR4 to expand the ERO so that the path is disjoint from the primary LSP in area 2.
为了让ABR2扩展ERO，它还需要知道主LSP的路径，以便ERO扩展与主LSP的路径不相交。因此，A还包括至少包含（ABR1、B1、ABR3、C1、C2）的XRO。基于这些约束，ABR2可以扩展ERO，使其与主LSP不相交。在此示例中，由ABR2计算的ERO将是（B2严格，ABR4严格，C松散），由B生成的XRO至少包含（ABR3，C1，C2）。ABR4需要后一种信息来扩展ERO，以便路径与区域2中的主LSP不相交。
Area 1 Area 0 Area 2
<---------------><--------------><--------------->
Area 1 Area 0 Area 2
<---------------><--------------><--------------->
+---A1---A2----ABR1-----B1-----ABR3----C1---C2---+
| | | | |
| | | | |
A | | | C
| | | | |
| | | | |
+---A3---A4----ABR2-----B2-----ABR4----C3---C4---+
+---A1---A2----ABR1-----B1-----ABR3----C1---C2---+
| | | | |
| | | | |
A | | | C
| | | | |
| | | | |
+---A3---A4----ABR2-----B2-----ABR4----C3---C4---+
Figure A.1: Inter-area LSPs
图A.1：区域间LSP
In this example, a node performing the path computation first selects an ABR and then computes a strict path towards this ABR. For the backup LSP, all nodes of the primary LSP in the next areas have to be put in the XRO (with the exception of the destination node if node protection and no link protection is required). When an ABR computes the next path segment, i.e., the path over the next area, it may remove the nodes from the XRO that are located in that area with the exception of the ABR where the primary LSP is exiting the area. The latter information is still required because when the selected ABR (ABR4 in this example) further expands the ERO, it has to exclude the ABR on which the primary LSP is entering that area (ABR3 in this example). This means that when ABR2 generates an XRO, it may remove the nodes in area 0 from the XRO but not ABR3. Note that not doing this would not cause harm in this example because there is no path from ABR4 to C via ABR3 in area 2. If there is a link between ABR4- ABR3 and ABR3-C, then it is required to have ABR3 in the XRO generated by ABR2.
在该示例中，执行路径计算的节点首先选择ABR，然后计算朝向该ABR的严格路径。对于备份LSP，下一个区域中主LSP的所有节点都必须放在XRO中（如果需要节点保护且不需要链路保护，则目标节点除外）。当ABR计算下一个路径段（即下一个区域上的路径）时，它可以从XRO中移除位于该区域的节点，但主LSP退出该区域的ABR除外。后一种信息仍然是必需的，因为当所选ABR（本例中为ABR4）进一步扩展ERO时，它必须排除主LSP正在其上进入该区域的ABR（本例中为ABR3）。这意味着，当ABR2生成XRO时，它可以从XRO中移除区域0中的节点，但不能移除ABR3。注意，在本例中不这样做不会造成伤害，因为在区域2中没有从ABR4经由ABR3到C的路径。如果ABR4-ABR3和ABR3-C之间存在链路，则需要在ABR2生成的XRO中具有ABR3。
Discussion on the length of the XRO: When link or node protection is requested, the length of the XRO is bounded by the length of the RRO of the primary LSP. It can be made shorter by removing nodes by the ingress node and the ABRs. In the example above, the RRO of the primary LSP contains 8 subobjects, while the maximum XRO length can be bounded by 6 subobjects (nodes A1 and A2 do not have to be in the XRO). For SRLG protection, the XRO has to list all SRLGs that are crossed by the primary LSP.
关于XRO长度的讨论：当请求链路或节点保护时，XRO的长度以主LSP的RRO长度为界。通过由入口节点和abr移除节点，可以使其变短。在上面的示例中，主LSP的RRO包含8个子对象，而最大XRO长度可以由6个子对象限定（节点A1和A2不必位于XRO中）。对于SRLG保护，XRO必须列出主LSP穿过的所有SRLG。
When an inter-AS LSP (which has to be protected by a backup LSP to provide link or node protection) is established, the same method as for the inter-area LSP case can be used. The difference is when the backup LSP is not following the same AS-path as the primary LSP because then the XRO should always contain the full path of the primary LSP. In case the backup LSP is following the same AS-path
当建立内部AS LSP（必须由备份LSP保护以提供链路或节点保护）时，可以使用与区域间LSP情况相同的方法。不同之处在于，备份LSP的路径与主LSP的路径不同，因为XRO应该始终包含主LSP的完整路径。如果备份LSP遵循与路径相同的路径
(but with different ASBRs -- at least in case of node protection), it is similar to the inter-area case: ASBRs expanding the ERO over the next AS may remove the XRO subobjects located in that AS. Note that this can only be done by an ingress ASBR (the ASBR where the LSP is entering the AS).
（但对于不同的ASBR——至少在节点保护的情况下），这与区域间情况类似：ASBR在下一个AS上扩展ERO可能会删除位于该AS中的XRO子对象。请注意，这只能由入口ASBR（LSP进入AS的ASBR）完成。
Discussion on the length of the XRO: the XRO is bounded by the length of the RRO of the primary LSP.
关于XRO长度的讨论：XRO以主LSP的RRO长度为界。
Suppose that SRLG protection is required, and the ASs crossed by the main LSP use a consistent way of allocating SRLG-ids to the links (i.e., the ASs use a single SRLG space). In this case, the SRLG-ids of each link used by the main LSP can be recorded by means of the RRO; the SRLG-ids are then used by the XRO. If the SRLG-ids are only meaningful when local to the AS, putting SRLG-ids in the XRO crossing many ASs makes no sense. To provide SRLG protection for inter-AS LSPs the link IP address of the inter-AS link used by the primary LSP can be put into the XRO of the Path message of the detour LSP or bypass tunnel. The ASBR where the detour LSP or bypass tunnel is entering the AS can translate this into the list of SRLG-ids known to the local AS.
假设需要SRLG保护，并且主LSP交叉的ASs使用一致的方式将SRLG ID分配给链路（即，ASs使用单个SRLG空间）。在这种情况下，主LSP使用的每个链路的SRLG id可以通过RRO来记录；然后，XRO使用SRLG ID。如果SRLG ID仅在AS本地时才有意义，那么将SRLG ID放在XRO交叉口中是没有意义的。为了为AS间LSP提供SRLG保护，主LSP使用的AS间链路的链路IP地址可以放入迂回LSP或旁路隧道的路径消息的XRO中。绕行LSP或旁通隧道进入AS的ASBR可将其转换为本地AS已知的SRLG ID列表。
Discussion on the length of the XRO: the XRO only contains 1 subobject, which contains the IP address of the inter-AS link traversed by the primary LSP (assuming that the primary LSP and detour LSP or bypass tunnel are leaving the AS in the same area, and that they are also entering the next AS in the same area).
关于XRO长度的讨论：XRO仅包含1个子对象，其中包含主LSP穿过的AS间链路的IP地址（假设主LSP和迂回LSP或旁路隧道在同一区域离开AS，并且它们也在同一区域进入下一个AS）。
When an edge-node wants to establish an LSP towards another edge-node over an optical core network as described in [RFC4208] (see Figure A.2), the XRO can be used for multiple purposes.
如[RFC4208]（见图A.2）所述，当边缘节点希望通过光纤核心网络建立指向另一边缘节点的LSP时，XRO可用于多种用途。
Overlay Overlay
Network +--------------------------------+ Network
+----------+ | | +----------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | |
| --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- |
| | | | +--+--+ | | | | +---+--+ | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
| | | | | | | | | | |
+----------+ | | | | | | | +----------+
| | | | | | |
+----------+ | | | | | | | +----------+
| | | | +--+--+ | +--+--+ | | | |
| +----+ | | | | | +------+ | | | | +----+ |
| | +-+--+ | | CN4 +-------------+ CN5 | | +--+-+ | |
| --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +--------------------------------+ | |
+----------+ Core Network +----------+
Overlay Overlay
Network +--------------------------------+ Network
+----------+ | | +----------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | |
| --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- |
| | | | +--+--+ | | | | +---+--+ | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
| | | | | | | | | | |
+----------+ | | | | | | | +----------+
| | | | | | |
+----------+ | | | | | | | +----------+
| | | | +--+--+ | +--+--+ | | | |
| +----+ | | | | | +------+ | | | | +----+ |
| | +-+--+ | | CN4 +-------------+ CN5 | | +--+-+ | |
| --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- |
| | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ |
| | +--------------------------------+ | |
+----------+ Core Network +----------+
Overlay Overlay Network Network
网络覆盖
Legend: EN - Edge-Node CN - Core-Node
图例：EN-边缘节点CN-核心节点
Figure A.2
图A.2
A first application is where an edge-node wants to establish multiple LSPs towards the same destination edge-node, and these LSPs need to have few or no SRLGs in common. In this case EN1 could establish an LSP towards EN3, and then it can establish a second LSP listing all links used by the first LSP with the indication to avoid the SRLGs of these links. This information can be used by CN1 to compute a path for the second LSP. If the core network consists of multiple areas, then the SRLG-ids have to be listed in the XRO. The same example applies to nodes and links.
第一个应用是边缘节点想要向同一目标边缘节点建立多个LSP，并且这些LSP需要有几个或没有公共SRLGs。在这种情况下，EN1可以建立朝向EN3的LSP，然后它可以建立第二个LSP，列出第一个LSP使用的所有链路，并指示避免这些链路的SRLGs。CN1可以使用该信息来计算第二个LSP的路径。如果要在XRO中列出多个核心区域的SRLG ID。相同的示例适用于节点和链接。
Another application is where the edge-node wants to set up a backup LSP that is also protecting the links between the edge-nodes and core-nodes. For instance, when EN2 establishes an LSP to EN4, it sends a Path message to CN4, which computes a path towards EN4 over (for instance) CN5. When EN2 gets back the RRO of that LSP, it can signal a new LSP to CN1 with EN4 as the destination and the XRO computed based on the RRO of the first LSP. Based on this information, CN1 can compute a path that has the requested diversity properties (e.g., a path going over CN2 and CN3, and then to EN4).
另一个应用程序是边缘节点希望设置备份LSP，该LSP还保护边缘节点和核心节点之间的链路。例如，当EN2建立到EN4的LSP时，它向CN4发送路径消息，CN4通过（例如）CN5计算到EN4的路径。当EN2返回该LSP的RRO时，它可以向CN1发送一个新LSP信号，EN4作为目的地，XRO根据第一个LSP的RRO计算。基于该信息，CN1可以计算具有请求的分集属性的路径（例如，经过CN2和CN3，然后到达EN4的路径）。
It is clear that in these examples, the core-node may not alter the RRO in a Resv message to make its only contents be the subobjects from the egress core-node through the egress edge-node.
显然，在这些示例中，核心节点可能不会改变Resv消息中的RRO，以使其唯一内容是从出口核心节点到出口边缘节点的子对象。
The XRO can also be used inside a single area. Take for instance a network where the TE extensions of the IGPs as described in [RFC3630] and [RFC3784] are not used. Hence, each node has to select a next-hop and possibly crankback [CRANKBACK] has to be used when there is no viable next-hop. In this case, when signaling a backup LSP, the XRO can be put in the Path message to exclude the links, nodes, or SRLGs of the primary LSP. An alternative way to provide this functionality would be to indicate the following in the Path message of the backup LSP: the primary LSP and which type of protection is required. This latter solution would work for link and node protection, but not for SRLG protection.
XRO也可以在单个区域内使用。例如，不使用[RFC3630]和[RFC3784]中所述的IGP TE扩展的网络。因此，每个节点必须选择下一跳，并且在没有可行的下一跳时，可能必须使用crankback[crankback]。在这种情况下，当向备用LSP发送信号时，可以将XRO放入Path消息中，以排除主LSP的链路、节点或SRLGs。提供此功能的另一种方法是在备份LSP的路径消息中指示以下内容：主LSP以及需要哪种类型的保护。后一种解决方案适用于链路和节点保护，但不适用于SRLG保护。
When link or node protection is requested, the XRO is of the same length as the RRO of the primary LSP. For SRLG protection, the XRO has to list all SRLGs that are crossed by the primary LSP. Note that for SRLG protection, the link IP address to reference the SRLGs of that link cannot be used since the TE extensions of the IGPs are not used in this example. Hence, a node cannot translate any link IP address located in that area to its SRLGs.
当请求链路或节点保护时，XRO的长度与主LSP的RRO相同。对于SRLG保护，XRO必须列出主LSP穿过的所有SRLG。请注意，对于SRLG保护，无法使用引用该链路的SRLGs的链路IP地址，因为本示例中未使用IGPs的TE扩展。因此，节点无法将位于该区域的任何链路IP地址转换为其SRLGs。
Authors' Addresses
作者地址
Cheng-Yin Lee EMail: c.yin.lee@gmail.com
李政贤电邮：c.Yin。lee@gmail.com
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
阿德里安·法雷尔老狗咨询电话：+44（0）1978 860944电子邮件：adrian@olddog.co.uk
Stefaan De Cnodder Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 EMail: stefaan.de_cnodder@alcatel-lucent.be
Stefaan De Cnodder Alcatel-Lucent Copernicuslaan 50 B-2018比利时安特卫普电话：+32 3 240 85 15电子邮件：Stefaan.De_cnodder@alcatel-朗讯
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。