Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 7898 U. Palle
Category: Experimental V. Kondreddy
ISSN: 2070-1721 Huawei Technologies
R. Casellas
CTTC
June 2016
Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 7898 U. Palle
Category: Experimental V. Kondreddy
ISSN: 2070-1721 Huawei Technologies
R. Casellas
CTTC
June 2016
Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
资源保留协议的域子对象-流量工程（RSVP-TE）
Abstract
摘要
The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup.
资源预留协议-流量工程（RSVP-TE）规范和RSVP-TE的通用多协议标签交换（GMPLS）扩展允许在路径设置中显式包含抽象节点和资源。此外，RSVP-TE的排除路由扩展允许在路径设置中明确排除抽象节点和资源。
This document specifies new subobjects to include or exclude Autonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup.
本文档指定了要包括或排除自治系统（ASE）的新子对象（ASE）以及路径设置期间的内部网关协议（IGP）区域，自治系统（ASE）由4字节的数字标识。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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 http://www.rfc-editor.org/info/rfc7898.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7898.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Subobjects for Domains . . . . . . . . . . . . . . . . . . . 5
3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Explicit Route Object (ERO) Subobjects . . . . . . . . . 6
3.2.1. Autonomous System . . . . . . . . . . . . . . . . . . 6
3.2.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Mode of Operation . . . . . . . . . . . . . . . . . . 8
3.3. Exclude Route Object (XRO) Subobjects . . . . . . . . . . 9
3.3.1. Autonomous System . . . . . . . . . . . . . . . . . . 9
3.3.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Mode of Operation . . . . . . . . . . . . . . . . . . 10
3.4. Explicit Exclusion Route Subobject . . . . . . . . . . . 10
4. Interaction with Path Computation Element (PCE) . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
A.1. Inter-Area LSP Path Setup . . . . . . . . . . . . . . . . 14
A.2. Inter-AS LSP Path Setup . . . . . . . . . . . . . . . . . 15
A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 15
A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Subobjects for Domains . . . . . . . . . . . . . . . . . . . 5
3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Explicit Route Object (ERO) Subobjects . . . . . . . . . 6
3.2.1. Autonomous System . . . . . . . . . . . . . . . . . . 6
3.2.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Mode of Operation . . . . . . . . . . . . . . . . . . 8
3.3. Exclude Route Object (XRO) Subobjects . . . . . . . . . . 9
3.3.1. Autonomous System . . . . . . . . . . . . . . . . . . 9
3.3.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Mode of Operation . . . . . . . . . . . . . . . . . . 10
3.4. Explicit Exclusion Route Subobject . . . . . . . . . . . 10
4. Interaction with Path Computation Element (PCE) . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
A.1. Inter-Area LSP Path Setup . . . . . . . . . . . . . . . . 14
A.2. Inter-AS LSP Path Setup . . . . . . . . . . . . . . . . . 15
A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 15
A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
The RSVP-TE specification [RFC3209] and the GMPLS extensions to RSVP-TE [RFC3473] allow abstract nodes and resources to be explicitly included in a path setup using the Explicit Route Object (ERO). Further, Exclude Route extensions [RFC4874] allow abstract nodes or resources to be excluded from the whole path using the Exclude Route Object (XRO). To exclude certain abstract nodes or resources between a specific pair of abstract nodes present in an ERO, an Explicit Exclusion Route subobject (EXRS) is used.
RSVP-TE规范[RFC3209]和RSVP-TE[RFC3473]的GMPLS扩展允许使用显式路由对象（ERO）在路径设置中显式包含抽象节点和资源。此外，排除路由扩展[RFC4874]允许使用排除路由对象（XRO）从整个路径中排除抽象节点或资源。要在ERO中存在的特定抽象节点对之间排除某些抽象节点或资源，请使用显式排除路由子对象（EXRS）。
[RFC3209] already describes the notion of abstract nodes, where an abstract node is a group of nodes whose internal topology is opaque to the ingress node of the Label Switched Path (LSP). It further defines a subobject for AS, but with a 2-byte AS number only.
[RFC3209]已经描述了抽象节点的概念，其中抽象节点是一组节点，其内部拓扑对标签交换路径（LSP）的入口节点是不透明的。它还为AS定义了一个子对象，但仅以2字节作为数字。
This document extends the notion of abstract nodes by adding new subobjects for IGP areas and 4-byte AS numbers (as per [RFC6793]). These subobjects can be included in ERO, XRO, or EXRS.
本文档扩展了抽象节点的概念，为IGP区域添加了新的子对象，并将4字节作为数字（根据[RFC6793]）。这些子对象可以包含在ERO、XRO或EXR中。
In case of per-domain path computation [RFC5152], where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node, the signaling message could use domain identifiers. The use of these new subobjects is illustrated in Appendix A.
在每域路径计算[RFC5152]的情况下，其中在入口节点处不能或不确定域间TE LSP的完整路径，信令消息可以使用域标识符。这些新子对象的使用如附录A所示。
Further, the domain identifier could simply act as a delimiter to specify where the domain boundary starts and ends.
此外，域标识符可以简单地充当分隔符，以指定域边界的起点和终点。
This is a companion document to Path Computation Element Protocol (PCEP) extensions for the domain sequence [RFC7897].
这是域序列[RFC7897]的路径计算元素协议（PCEP）扩展的配套文档。
The procedures described in this document are experimental. The experiment is intended to enable research for the usage of domain subobjects for inter-domain path setup. For this purpose, this document specifies new domain subobjects as well as how they incorporate with existing subobjects.
本文件中描述的程序是实验性的。该实验旨在研究域间路径设置中域子对象的使用。为此，本文档指定了新的域子对象以及它们如何与现有子对象合并。
The experiment will end two years after the RFC is published. At that point, the RFC authors will attempt to determine how widely this has been implemented and deployed.
实验将在RFC出版两年后结束。到那时，RFC作者将试图确定这项技术的实施和部署范围有多广。
This document does not change the procedures for handling subobjects in RSVP-TE.
本文档不会更改RSVP-TE中处理子对象的过程。
The new subobjects introduced by this document will not be understood by legacy implementations. If a legacy implementation receives one of the subobjects that it does not understand in an RSVP-TE object, the legacy implementation will behave as described in [RFC3209] and [RFC4874]. Therefore, it is assumed that this experiment will be conducted only when all nodes processing the new subobject form part of the experiment.
本文档引入的新子对象不会被遗留实现所理解。如果传统实现接收到它在RSVP-TE对象中不理解的子对象之一，则传统实现的行为将如[RFC3209]和[RFC4874]中所述。因此，假设仅当处理新子对象的所有节点构成实验的一部分时，才会进行此实验。
When the result of implementation and deployment are available, this document will be updated and refined, and then it will be moved from Experimental to Standards Track.
当实现和部署的结果可用时，将更新和完善本文档，然后将其从实验性转移到标准轨道。
It should be noted that there are other ways such as the use of a boundary node to identify the domain (instead of a domain identifier); the mechanism defined in this document is just another tool in the toolkit for the operator.
应该注意，还有其他方法，例如使用边界节点来标识域（而不是域标识符）；本文档中定义的机制只是操作员工具箱中的另一个工具。
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]中所述进行解释。
The following terminology is used in this document.
本文件使用以下术语。
AS: Autonomous System
AS：自治系统
Domain: As per [RFC4655], any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include IGP areas and ASes.
域：根据[RFC4655]，在地址管理或路径计算责任的公共范围内的任何网络元素集合。域的示例包括IGP区域和ASE。
ERO: Explicit Route Object
显式路由对象
EXRS: Explicit Exclusion Route subobject
EXRS：显式排除路由子对象
IGP: Interior Gateway Protocol. Either of the two routing protocols: Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).
IGP：内部网关协议。两种路由协议之一：开放最短路径优先（OSPF）或中间系统到中间系统（IS-IS）。
IS-IS: Intermediate System to Intermediate System
IS-IS：中间系统至中间系统
OSPF: Open Shortest Path First
开放最短路径优先
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：路径计算元素。能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
PCEP: Path Computation Element Protocol
路径计算元素协议
RSVP: Resource Reservation Protocol
资源预留协议
TE LSP: Traffic Engineering Label Switched Path
TE LSP：流量工程标签交换路径
XRO: Exclude Route Object
XRO:排除路由对象
[RFC4726] and [RFC4655] define domain as a separate administrative or geographic environment within the network. A domain could be further defined as a zone of routing or computational ability. Under these definitions, a domain might be categorized as an AS or an IGP area.
[RFC4726]和[RFC4655]将域定义为网络内单独的管理或地理环境。域可以进一步定义为路由或计算能力区域。根据这些定义，域可能被分类为as或IGP区域。
As per [RFC3209], an abstract node is a group of nodes whose internal topology is opaque to the ingress node of the LSP. Using this concept of abstraction, an explicitly routed LSP can be specified as a sequence of IP prefixes or a sequence of ASes. In this document, we extend the notion to include the IGP area and 4-byte AS number.
根据[RFC3209]，抽象节点是一组内部拓扑对LSP的入口节点不透明的节点。使用这种抽象概念，可以将显式路由LSP指定为IP前缀序列或ASE序列。在本文中，我们扩展了这个概念，将IGP区域和4字节作为数字包含在内。
These subobjects appear in RSVP-TE, notably in:
这些子对象出现在RSVP-TE中，尤其是：
o Explicit Route Object (ERO): As per [RFC3209], an explicit route is a particular path in the network topology including abstract nodes (including domains).
o 显式路由对象（ERO）：根据[RFC3209]，显式路由是网络拓扑中的特定路径，包括抽象节点（包括域）。
o Exclude Route Object (XRO): As per [RFC4874], an Exclude Route identifies a list of abstract nodes (including domains) that should not be traversed along the path of the LSP being established.
o 排除路由对象（XRO）：根据[RFC4874]，排除路由标识不应沿正在建立的LSP路径遍历的抽象节点（包括域）列表。
o Explicit Exclusion Route Subobject (EXRS): As per [RFC4874], used to specify exclusion of certain abstract nodes between a specific pair of nodes. EXRS is a subobject carried inside the ERO. These subobjects can be used to specify the domains to be excluded between two abstract nodes.
o 显式排除路由子对象（EXRS）：根据[RFC4874]，用于指定特定节点对之间某些抽象节点的排除。EXRS是ERO内部的子对象。这些子对象可用于指定要在两个抽象节点之间排除的域。
As stated in [RFC3209], an explicit route is a particular path in the network topology. In addition to the ability to identify specific nodes along the path, an explicit route can identify a group of nodes (abstract nodes) to be traversed along the path.
如[RFC3209]所述，显式路由是网络拓扑中的特定路径。除了能够识别路径上的特定节点外，显式路由还可以识别要沿着路径遍历的一组节点（抽象节点）。
Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477], [RFC4874], and [RFC5553], but new subobjects related to domains are needed.
[RFC3209]、[RFC3473]、[RFC3477]、[RFC4874]和[RFC5553]中定义了一些子对象，但需要与域相关的新子对象。
This document extends the support for 4-byte AS numbers and IGP areas.
本文档扩展了对4字节AS数字和IGP区域的支持。
Value Description
----- ---------
5 4-byte AS number
6 OSPF Area ID
7 IS-IS Area ID
Value Description
----- ---------
5 4-byte AS number
6 OSPF Area ID
7 IS-IS Area ID
[RFC3209] already defines 2-byte AS numbers.
[RFC3209]已将2字节定义为数字。
To support 4-byte AS numbers as per [RFC6793], the following subobject is defined:
根据[RFC6793]，为支持4字节AS编号，定义了以下子对象：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L bit is an attribute of the subobject as defined in [RFC3209], i.e., it's 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位是[RFC3209]中定义的子对象的属性，即，如果子对象表示显式路由中的松散跃点，则设置该位。如果未设置位，则子对象表示显式路由中的严格跃点。
Type: 5 (indicating a 4-byte AS number).
类型：5（表示4字节作为数字）。
Length: 8 (total length of the subobject in bytes).
长度：8（子对象的总长度（字节）。
Reserved: Zero at transmission; ignored at receipt.
保留：传输时为零；收到时忽略。
AS Number: The 4-byte AS number. Note that if 2-byte AS numbers are in use, the low-order bits (16 through 31) MUST be used, and the high-order bits (0 through 15) MUST be set to zero. For the purpose of this experiment, it is advised to use a 4-byte AS number subobject as the default.
AS编号：4字节AS编号。请注意，如果使用2字节AS数字，则必须使用低位（16到31），高位（0到15）必须设置为零。在本实验中，建议使用4字节作为数字子对象作为默认值。
Since the length and format of Area ID is different for OSPF and IS-IS, the following two subobjects are defined:
由于OSPF和is-is的区域ID的长度和格式不同，因此定义了以下两个子对象：
For OSPF, the Area ID is a 32-bit number. The subobject is encoded as follows:
对于OSPF，区域ID是32位数字。子对象的编码如下所示：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L bit is an attribute of the subobject as defined in [RFC3209].
L：L位是[RFC3209]中定义的子对象的属性。
Type: 6 (indicating a 4-byte OSPF Area ID).
类型：6（表示一个4字节的OSPF区域ID）。
Length: 8 (total length of the subobject in bytes).
长度：8（子对象的总长度（字节）。
Reserved: Zero at transmission; ignored at receipt.
保留：传输时为零；收到时忽略。
OSPF Area ID: The 4-byte OSPF Area ID.
OSPF区域ID：4字节的OSPF区域ID。
For IS-IS, the Area ID is of variable length; thus, the length of the subobject is variable. The Area ID is as described in IS-IS by the ISO standard [ISO10589]. The subobject is encoded as follows:
对于IS-IS，区域ID具有可变长度；因此，子对象的长度是可变的。区域ID如ISO标准[ISO10589]is-is中所述。子对象的编码如下所示：
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 | Area-Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IS-IS Area ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Area-Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IS-IS Area ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L bit is an attribute of the subobject as defined in [RFC3209].
L：L位是[RFC3209]中定义的子对象的属性。
Type: 7 (indicating the IS-IS Area ID).
类型：7（表示IS-IS区域ID）。
Length: Variable. The length MUST be at least 8 and MUST be a multiple of 4.
长度：可变。长度必须至少为8，并且必须是4的倍数。
Area-Len: Variable (length of the actual (non-padded) IS-IS area identifier in octets; valid values are from 1 to 13, inclusive).
Area Len：变量（实际（非填充）IS-IS区域标识符的长度，以八位字节为单位；有效值为1到13，包括在内）。
Reserved: Zero at transmission; ignored at receipt.
保留：传输时为零；收到时忽略。
IS-IS Area ID: The variable-length IS-IS area identifier. Padded with trailing zeroes to a 4-byte boundary.
IS-IS区域ID：可变长度IS-IS区域标识符。用尾随零填充到4字节边界。
The new subobjects to support 4-byte AS numbers and the IGP (OSPF / IS-IS) area could be used in the ERO to specify an abstract node (a group of nodes whose internal topology is opaque to the ingress node of the LSP).
支持4字节作为数字的新子对象和IGP（OSPF/IS-IS）区域可在ERO中用于指定抽象节点（其内部拓扑对LSP的入口节点不透明的一组节点）。
All the rules of processing (for example, next-hop selection, L bit processing, unrecognized subobjects, etc.) are as per the [RFC3209]. Note that if a node is called upon to process subobjects defined in this document that it does not recognize, 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 subobject.
所有处理规则（例如，下一跳选择、L位处理、无法识别的子对象等）均符合[RFC3209]。请注意，如果调用某个节点来处理本文档中定义的它无法识别的子对象，则当遇到无法识别的ERO子对象时，该节点的行为将如[RFC3209]中所述。这意味着此节点将返回一个PathErr，错误代码为“Routing error”，错误值为“Bad EXPLICIT_ROUTE object”，包含显式_ROUTE对象，并将其截断（在左侧）到有问题的子对象。
As stated in [RFC4874], the Exclude Route identifies a list of abstract nodes to exclude (not be traversed) along the path of the LSP being established.
如[RFC4874]中所述，排除路由标识要沿正在建立的LSP路径排除（不被遍历）的抽象节点列表。
Some subobjects are defined in [RFC3209], [RFC3477], [RFC4874], and [RFC6001], but new subobjects related to domains are needed.
[RFC3209]、[RFC3477]、[RFC4874]和[RFC6001]中定义了一些子对象，但需要与域相关的新子对象。
This document extends the support for 4-byte AS numbers and IGP areas.
本文档扩展了对4字节AS数字和IGP区域的支持。
Value Description
----- ---------
5 4-byte AS number
6 OSPF Area ID
7 IS-IS Area ID
Value Description
----- ---------
5 4-byte AS number
6 OSPF Area ID
7 IS-IS Area ID
[RFC3209] and [RFC4874] already define a 2-byte AS number.
[RFC3209]和[RFC4874]已将2字节定义为数字。
To support 4-byte AS numbers as per [RFC6793], a subobject has the same format as defined in Section 3.2.1 with the following difference:
为了支持[RFC6793]中规定的4字节AS数字，子对象的格式与第3.2.1节中定义的格式相同，但有以下区别：
The meaning of the L bit is as per [RFC4874], where:
L位的含义符合[RFC4874]，其中：
0: indicates that the abstract node specified MUST be excluded.
0:表示必须排除指定的抽象节点。
1: indicates that the abstract node specified SHOULD be avoided.
1：表示应避免指定的抽象节点。
Since the length and format of Area ID is different for OSPF and IS-IS, the following two subobjects are defined:
由于OSPF和is-is的区域ID的长度和格式不同，因此定义了以下两个子对象：
For OSPF, the Area ID is a 32-bit number. Subobjects for OSPF and IS-IS are of the same format as defined in Section 3.2.2 with the following difference:
对于OSPF，区域ID是32位数字。OSPF和IS-IS的子对象的格式与第3.2.2节中定义的格式相同，但有以下区别：
The meaning of the L bit is as per [RFC4874].
L位的含义符合[RFC4874]。
The new subobjects to support 4-byte AS numbers and the IGP (OSPF / IS-IS) area could also be used in the XRO to specify exclusion of an abstract node (a group of nodes whose internal topology is opaque to the ingress node of the LSP).
支持4字节作为数字的新子对象和IGP（OSPF/IS-IS）区域也可在XRO中用于指定排除抽象节点（其内部拓扑对LSP的入口节点不透明的一组节点）。
All the rules of processing are as per [RFC4874].
所有处理规则均符合[RFC4874]。
Note that if a node is called upon to process a subobject defined in this document that it does not recognize, it will behave as described in [RFC4874] when an unrecognized XRO subobject is encountered, i.e., ignore it. In this case, the desired exclusion will not be carried out.
请注意，如果节点被调用来处理本文档中定义的它无法识别的子对象，则当遇到无法识别的XRO子对象时，它将按照[RFC4874]中所述的方式运行，即忽略它。在这种情况下，将不执行所需的排除。
IGP area subobjects in the XRO are local to the current AS. In case of multi-AS path computation that excludes an IGP area in a different AS, an IGP area subobject should be part of EXRS in the ERO to specify the AS in which the IGP area is to be excluded. Further, policy may be applied to prune/ignore area subobjects in XRO at the AS boundary.
XRO中的IGP区域子对象是当前AS的局部对象。如果多AS路径计算排除了不同AS中的IGP区域，则IGP区域子对象应是ERO中EXR的一部分，以指定要排除IGP区域的AS。此外，可以应用策略修剪/忽略AS边界处XRO中的面积子对象。
As per [RFC4874], the Explicit Exclusion Route is used to specify exclusion of certain abstract nodes between a specific pair of nodes or resources in the explicit route. EXRS is an ERO subobject that contains one or more subobjects of its own, called EXRS subobjects.
根据[RFC4874]，显式排除路由用于指定在显式路由中特定的一对节点或资源之间排除某些抽象节点。EXRS是一个ERO子对象，它包含自己的一个或多个子对象，称为EXRS子对象。
The EXRS subobject could carry any of the subobjects defined for XRO; thus, the new subobjects to support 4-byte AS numbers and the IGP (OSPF / IS-IS) area can also be used in the EXRS. The meanings of the fields of the new XRO subobjects are unchanged when the subobjects are included in an EXRS, except that the scope of the exclusion is limited to the single hop between the previous and subsequent elements in the ERO.
EXRS子对象可以包含为XRO定义的任何子对象；因此，支持4字节AS数字和IGP（OSPF/IS-IS）区域的新子对象也可以在EXRS中使用。当子对象包含在EXRS中时，新XRO子对象字段的含义不变，但排除范围仅限于ERO中先前和后续元素之间的单跳。
All the rules of processing are as per [RFC4874].
所有处理规则均符合[RFC4874]。
The domain subobjects to be used in PCEP are referred to in [RFC7897]. Note that the new domain subobjects follow the principle that subobjects used in PCEP [RFC5440] are identical to the subobjects used in RSVP-TE and thus are interchangeable between PCEP and RSVP-TE.
[RFC7897]中提到了PCEP中使用的域子对象。请注意，新的域子对象遵循PCEP[RFC5440]中使用的子对象与RSVP-TE中使用的子对象相同的原则，因此在PCEP和RSVP-TE之间可以互换。
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry at <http://www.iana.org/assignments/rsvp-parameters>. Within this registry, IANA maintains two sub-registries:
IANA在以下位置维护“资源保留协议（RSVP）参数”注册表：<http://www.iana.org/assignments/rsvp-parameters>. 在该注册中心内，IANA拥有两个子注册中心：
o EXPLICIT_ROUTE subobjects (see "Sub-object type - 20 EXPLICIT_ROUTE - Type 1 Explicit Route")
o 显式布线子对象（请参见“子对象类型-20显式布线-类型1显式布线”）
o EXCLUDE_ROUTE subobjects (see "Sub-object types of Class Types or C-Types - 232 EXCLUDE_ROUTE")
o 排除路由子对象（请参见“类类型或C类型的子对象类型-232排除路由”）
IANA has made identical additions to these registries as follows, in sync with [RFC7897]:
IANA与[RFC7897]同步，向这些注册中心添加了如下内容：
Value Description Reference
----- ---------------- -------------------
5 4-byte AS number [RFC7897], RFC 7898
6 OSPF Area ID [RFC7897], RFC 7898
7 IS-IS Area ID [RFC7897], RFC 7898
Value Description Reference
----- ---------------- -------------------
5 4-byte AS number [RFC7897], RFC 7898
6 OSPF Area ID [RFC7897], RFC 7898
7 IS-IS Area ID [RFC7897], RFC 7898
Further, IANA has added a reference to this document to the new PCEP numbers that are registered by [RFC7897], as shown on <http://www.iana.org/assignments/pcep>.
此外，IANA在[RFC7897]注册的新PCEP编号中添加了对本文件的引用，如所示<http://www.iana.org/assignments/pcep>.
Security considerations for RSVP-TE and GMPLS signaling RSVP-TE extensions are covered in [RFC3209] and [RFC3473]. This document does not introduce any new messages or any substantive new processing, so those security considerations continue to apply. Further, general considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can be found in [RFC5920]. Section 8 of [RFC5920] describes the inter-provider security considerations, which continue to apply.
[RFC3209]和[RFC3473]介绍了RSVP-TE和GMPLS信令RSVP-TE扩展的安全注意事项。本文档不会引入任何新消息或任何实质性的新处理，因此这些安全考虑因素将继续适用。此外，在MPLS-TE和GMPLS网络中保护RSVP-TE的一般注意事项见[RFC5920]。[RFC5920]第8节描述了继续适用的提供商间安全注意事项。
The route exclusion security considerations are covered in [RFC4874] and continue to apply.
[RFC4874]中介绍了路线排除安全注意事项，并将继续适用。
[ISO10589] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]国际标准化组织，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，ISO/IEC 10589:2002，第二版，2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, <http://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月<http://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, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, <http://www.rfc-editor.org/info/rfc3477>.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，DOI 10.17487/RFC3477，2003年1月<http://www.rfc-editor.org/info/rfc3477>.
[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, <http://www.rfc-editor.org/info/rfc4874>.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 4874，DOI 10.17487/RFC4874，2007年4月<http://www.rfc-editor.org/info/rfc4874>.
[RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016, <http://www.rfc-editor.org/info/rfc7897>.
[RFC7897]Dhody，D.，Palle，U.，和R.Casellas，“路径计算元素通信协议（PCEP）的域子对象”，RFC 7897，DOI 10.17487/RFC7897，2016年6月<http://www.rfc-editor.org/info/rfc7897>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<http://www.rfc-editor.org/info/rfc4655>.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, DOI 10.17487/RFC4726, November 2006, <http://www.rfc-editor.org/info/rfc4726>.
[RFC4726]Farrel，A.，Vasseur，J.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，DOI 10.17487/RFC4726，2006年11月<http://www.rfc-editor.org/info/rfc4726>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，DOI 10.17487/RFC5152，2008年2月<http://www.rfc-editor.org/info/rfc5152>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<http://www.rfc-editor.org/info/rfc5440>.
[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, <http://www.rfc-editor.org/info/rfc5553>.
[RFC5553]Farrel，A.，Ed.，Bradford，R.，和JP。Vasseur，“路径密钥支持的资源预留协议（RSVP）扩展”，RFC 5553，DOI 10.17487/RFC5553，2009年5月<http://www.rfc-editor.org/info/rfc5553>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<http://www.rfc-editor.org/info/rfc5920>.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/ MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, <http://www.rfc-editor.org/info/rfc6001>.
[RFC6001]Papadimitriou，D.，Vigoureux，M.，Shiomoto，K.，Brungard，D.，和JL。Le Roux，“多层和多区域网络（MLN/MRN）的通用MPLS（GMPLS）协议扩展”，RFC 6001，DOI 10.17487/RFC6001，2010年10月<http://www.rfc-editor.org/info/rfc6001>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.
[RFC6793]Vohra，Q.和E.Chen，“BGP对四个八位组自治系统（AS）数字空间的支持”，RFC 6793，DOI 10.17487/RFC6793，2012年12月<http://www.rfc-editor.org/info/rfc6793>.
These examples are for illustration purposes only to show how the new subobjects could be encoded. They are not meant to be an exhaustive list of all possible use cases and combinations.
这些示例仅用于说明如何对新子对象进行编码。它们并不意味着是所有可能用例和组合的详尽列表。
In an inter-area LSP path setup where the ingress and the egress belong to different IGP areas within the same AS, the domain subobjects could be represented using an ordered list of IGP area subobjects in an ERO.
在区域间LSP路径设置中，其中入口和出口属于同一区域内的不同IGP区域，域子对象可以使用ERO中的IGP区域子对象的有序列表来表示。
D2 Area D
|
|
D1
|
|
********BD1******
* | *
* | * Area C
Area A * | *
* | *
Ingress------A1-----ABF1------B1------BC1------C1------Egress
/ * | *
/ * | *
/ * Area | B *
F1 * | *
/ ********BE1******
/ |
/ |
F2 E1
|
Area F |
E2 Area E
D2 Area D
|
|
D1
|
|
********BD1******
* | *
* | * Area C
Area A * | *
* | *
Ingress------A1-----ABF1------B1------BC1------C1------Egress
/ * | *
/ * | *
/ * Area | B *
F1 * | *
/ ********BE1******
/ |
/ |
F2 E1
|
Area F |
E2 Area E
* All IGP areas in one AS (AS 100)
* 一个AS（AS 100）中的所有IGP区域
Figure 1: Domain Corresponding to IGP Area
图1:IGP区域对应的域
As per Figure 1, the signaling at the ingress could be:
如图1所示，入口处的信令可以是：
ERO:(A1, ABF1, area B, area C, egress)
能源监管局：（A1、ABF1、B区、C区、出口）
It should be noted that there are other ways to achieve the desired signaling; the area subobject provides another tool in the toolkit and can have operational benefits when:
应该注意的是，有其他方法来实现期望的信令；“区域”子对象在工具箱中提供了另一个工具，并且在以下情况下具有操作优势：
o Use of PCEP-like domain sequence [RFC7897] configurations in the explicit path is such that area subobjects can be used to signal the loose path.
o 在显式路径中使用类似PCEP的域序列[RFC7897]配置，使得区域子对象可用于向松散路径发送信号。
o Alignment of subobjects and registries is between PCEP and RSVP-TE, thus allowing easier interworking between path computation and signaling, i.e., subobjects are able to switch between signaling and path computation (if need be).
o 子对象和注册表的对齐在PCEP和RSVP-TE之间，因此允许路径计算和信令之间更容易的互通，即子对象能够在信令和路径计算之间切换（如果需要）。
In an inter-AS LSP path setup where the ingress and the egress belong to a different AS, the domain subobjects (ASes) could be used in an ERO.
在入口和出口属于不同AS的AS间LSP路径设置中，可以在ERO中使用域子对象（ASE）。
AS A AS E AS C
<-------------> <----------> <------------->
AS A AS E AS C
<-------------> <----------> <------------->
A4----------E1---E2---E3---------C4
/ / \
/ / \
/ / AS B \
/ / <----------> \
Ingress------A1---A2------B1---B2---B3------C1---C2------Egress
\ / /
\ / /
\ / /
\ / /
A3----------D1---D2---D3---------C3
A4----------E1---E2---E3---------C4
/ / \
/ / \
/ / AS B \
/ / <----------> \
Ingress------A1---A2------B1---B2---B3------C1---C2------Egress
\ / /
\ / /
\ / /
\ / /
A3----------D1---D2---D3---------C3
<---------->
AS D
<---------->
AS D
* All ASes have one area (area 0)
* 所有ASE都有一个区域（区域0）
Figure 2: Domain Corresponding to AS
图2:AS对应的域
As per Figure 2, the signaling at the ingress could be:
如图2所示，入口处的信令可以是：
ERO:(A1, A2, AS B, AS C, egress); or
ERO：（A1、A2、AS B、AS C、出口）；或
ERO:(A1, A2, AS B, area 0, AS C, area 0, egress).
ERO：（A1、A2、AS B、0区、AS C、0区、出口）。
Each AS has a single IGP area (area 0); the area subobject is optional.
每个AS有一个IGP区域（区域0）；区域子对象是可选的。
Note that to get a domain disjoint path, the ingress could also signal the backup path with:
请注意，为了获得域不相交路径，入口还可以用以下信息向备份路径发送信号：
XRO:(AS B)
XRO：（作为B）
As shown in Figure 3, where AS 200 is made up of multiple areas, the signaling can include both an AS and area subobject to uniquely identify a domain.
如图3所示，其中As 200由多个区域组成，信令可包括As和区域子对象以唯一标识域。
Ingress *
| *
| *
| *
X1 *
\\ *
\ \ *
\ \* Inter-AS
AS 100 \* \ Link
* \ \
* \ \
* \ \
\ \ D2 Area D
AS 200 \ \ |
\ \ |
Inter- \ \ D1
AS \ \ |
Link \ \|
\ ********BD1******
\ * | *
\ * | * Area C
Area A \ * | *
\* | *
A2------A1------AB1------B1------BC1------C1------Egress
* | *
* | *
* | *
* Area | B *
********BE1******
|
|
E1
|
|
E2 Area E
Ingress *
| *
| *
| *
X1 *
\\ *
\ \ *
\ \* Inter-AS
AS 100 \* \ Link
* \ \
* \ \
* \ \
\ \ D2 Area D
AS 200 \ \ |
\ \ |
Inter- \ \ D1
AS \ \ |
Link \ \|
\ ********BD1******
\ * | *
\ * | * Area C
Area A \ * | *
\* | *
A2------A1------AB1------B1------BC1------C1------Egress
* | *
* | *
* | *
* Area | B *
********BE1******
|
|
E1
|
|
E2 Area E
Figure 3: Domain Corresponding to AS and Area
图3：对应于AS和Area的域
As per Figure 3, the signaling at the ingress could be:
如图3所示，入口处的信令可以是：
ERO:(X1, AS 200, area B, area C, egress).
ERO：（X1，AS 200，B区，C区，出口）。
Acknowledgments
致谢
We would like to thank Adrian Farrel, Lou Berger, George Swallow, Chirag Shah, Reeja Paul, Sandeep Boina, and Avantika for their useful comments and suggestions.
我们要感谢阿德里安·法雷尔、卢·伯杰、乔治·斯沃恩、希拉格·沙阿、里贾·保罗、桑德普·博伊纳和阿凡提卡，感谢他们提出的有用意见和建议。
Thanks to Vishnu Pavan Beeram for shepherding this document.
感谢毗瑟奴·帕万·比拉姆对本文件的指导。
Thanks to Deborah Brungard for being the responsible AD.
感谢Deborah Brungard作为负责任的广告。
Thanks to Amanda Baber for the IANA review.
感谢阿曼达·巴伯的IANA评论。
Thanks to Brian Carpenter for the Gen-ART review.
感谢Brian Carpenter的Gen艺术评论。
Thanks to Liang Xia (Frank) for the SecDir review.
感谢梁霞（弗兰克）的SecDir审查。
Thanks to Spencer Dawkins and Barry Leiba for comments during the IESG review.
感谢Spencer Dawkins和Barry Leiba在IESG审查期间的评论。
Authors' Addresses
作者地址
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
印度卡纳塔克邦班加罗尔Whitefield Bangalore Dhruv Dhody华为技术分部，邮编560066
Email: dhruv.ietf@gmail.com
Email: dhruv.ietf@gmail.com
Udayasree Palle Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Udayasree Palle华为技术分公司位于印度卡纳塔克邦Whitefield Bangalore的HREE技术园，邮编560066
Email: udayasree.palle@huawei.com
Email: udayasree.palle@huawei.com
Venugopal Reddy Kondreddy Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
印度卡纳塔克邦怀特菲尔德班加罗尔维努戈帕尔Reddy Kondreddy Huawei Technologies Divyashree Techno Park，邮编560066
Email: venugopalreddyk@huawei.com
Email: venugopalreddyk@huawei.com
Ramon Casellas CTTC Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain
拉蒙·卡塞拉斯CTTC Av。Carl Friedrich Gauss n7 Castelldefels，巴塞罗那08860西班牙
Email: ramon.casellas@cttc.es
Email: ramon.casellas@cttc.es