Internet Engineering Task Force (IETF) D. Papadimitriou
Request for Comments: 6001 M. Vigoureux
Updates: 4202, 4203, 4206, 4874, 4974, 5307 Alcatel-Lucent
Category: Standards Track K. Shiomoto
ISSN: 2070-1721 NTT
D. Brungard
ATT
JL. Le Roux
France Telecom
October 2010
Internet Engineering Task Force (IETF) D. Papadimitriou
Request for Comments: 6001 M. Vigoureux
Updates: 4202, 4203, 4206, 4874, 4974, 5307 Alcatel-Lucent
Category: Standards Track K. Shiomoto
ISSN: 2070-1721 NTT
D. Brungard
ATT
JL. Le Roux
France Telecom
October 2010
Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
多层多区域网络（MLN/MRN）的通用MPLS（GMPLS）协议扩展
Abstract
摘要
There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).
对于由标签交换路由器（LSR）组成的网络的支持有特定要求，这些路由器参与由单个通用多协议标签交换（GMPLS）控制平面实例控制的不同数据平面交换层，称为GMPLS多层网络/多区域网络（MLN/MRN）。
This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain.
本文件定义了GMPLS路由和信令协议的扩展，以支持GMPLS多层/多区域网络的运行。它涵盖单个GMPLS控制平面实例的元素，该实例控制单个流量工程（TE）域内的多标签交换路径（LSP）区域或层。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc6001.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6001.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Summary of the Requirements and Evaluation ......................4
3. Interface Adjustment Capability Descriptor (IACD) ...............5
3.1. Overview ...................................................5
3.2. Interface Adjustment Capability Descriptor (IACD) ..........6
4. Multi-Region Signaling ..........................................9
4.1. XRO Subobjects ............................................10
5. Virtual TE Link ................................................12
5.1. Edge-to-Edge Association ..................................13
5.2. Soft Forwarding Adjacency (Soft FA) .......................16
6. Backward Compatibility .........................................18
7. Security Considerations ........................................18
8. IANA Considerations ............................................18
8.1. RSVP ......................................................18
8.2. OSPF ......................................................20
8.3. IS-IS .....................................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................22
Acknowledgments....................................................23
Contributors ......................................................23
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Summary of the Requirements and Evaluation ......................4
3. Interface Adjustment Capability Descriptor (IACD) ...............5
3.1. Overview ...................................................5
3.2. Interface Adjustment Capability Descriptor (IACD) ..........6
4. Multi-Region Signaling ..........................................9
4.1. XRO Subobjects ............................................10
5. Virtual TE Link ................................................12
5.1. Edge-to-Edge Association ..................................13
5.2. Soft Forwarding Adjacency (Soft FA) .......................16
6. Backward Compatibility .........................................18
7. Security Considerations ........................................18
8. IANA Considerations ............................................18
8.1. RSVP ......................................................18
8.2. OSPF ......................................................20
8.3. IS-IS .....................................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................22
Acknowledgments....................................................23
Contributors ......................................................23
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends MPLS to handle multiple switching technologies: packet switching (PSC), Layer 2 switching (L2SC), Time-Division Multiplexing (TDM) Switching, wavelength switching (LSC) and fiber switching (FSC). A GMPLS switching type (PSC, TDM, etc.) describes the ability of a node to forward data of a particular data plane technology, and uniquely identifies a control plane LSP region. LSP regions are defined in [RFC4206]. A network comprised of multiple switching types (e.g., PSC and TDM) controlled by a single GMPLS control plane instance is called a Multi-Region Network (MRN).
通用多协议标签交换（GMPLS）[RFC3945]扩展了MPLS以处理多种交换技术：分组交换（PSC）、第二层交换（L2SC）、时分复用（TDM）交换、波长交换（LSC）和光纤交换（FSC）。GMPLS交换类型（PSC、TDM等）描述节点转发特定数据平面技术的数据的能力，并唯一标识控制平面LSP区域。LSP区域在[RFC4206]中定义。由单个GMPLS控制平面实例控制的多个交换类型（如PSC和TDM）组成的网络称为多区域网络（MRN）。
A data plane layer is a collection of network resources capable of terminating and/or switching data traffic of a particular format. For example, LSC, TDM VC-11, and TDM VC-4-64c represent three different layers. A network comprising transport nodes participating in different data plane switching layers controlled by a single GMPLS control plane instance is called a Multi-Layer Network (MLN).
数据平面层是能够终止和/或交换特定格式的数据通信的网络资源的集合。例如，LSC、TDM VC-11和TDM VC-4-64c代表三个不同的层。由参与由单个GMPLS控制平面实例控制的不同数据平面交换层的传输节点组成的网络称为多层网络（MLN）。
The applicability of GMPLS to multiple switching technologies provides the unified control and operations for both LSP provisioning and recovery. This document covers the elements of a single GMPLS control plane instance controlling multiple layers within a given TE domain. A TE domain is defined as group of Label Switching Routers (LSRs) that enforces a common TE policy. A Control Plane (CP) instance can serve one, two, or more layers. Other possible approaches, such as having multiple CP instances serving disjoint sets of layers, are outside the scope of this document.
GMPLS对多种交换技术的适用性为LSP供应和恢复提供了统一的控制和操作。本文档涵盖单个GMPLS控制平面实例的元素，该实例控制给定TE域内的多个层。TE域定义为实施公共TE策略的一组标签交换路由器（LSR）。控制平面（CP）实例可以服务于一层、两层或更多层。其他可能的方法，例如让多个CP实例服务于不相交的层集，不在本文档的范围之内。
The next sections provide the procedural aspects in terms of routing and signaling for such environments as well as the extensions required to instrument GMPLS to provide the capabilities for MLN/MRN unified control. The rationales and requirements for Multi-Layer/Region networks are set forth in [RFC5212]. These requirements are evaluated against GMPLS protocols in [RFC5339] and several areas where GMPLS protocol extensions are required are identified.
下一节提供了此类环境的路由和信令方面的程序方面，以及为装备GMPLS以提供MLN/MRN统一控制能力所需的扩展。[RFC5212]中阐述了多层/区域网络的原理和要求。这些要求根据[RFC5339]中的GMPLS协议进行评估，并确定了需要GMPLS协议扩展的几个领域。
This document defines GMPLS routing and signaling extensions so as to cover GMPLS MLN/MRN requirements.
本文件定义了GMPLS路由和信令扩展，以涵盖GMPLS MLN/MRN要求。
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]中所述进行解释。
In addition, the reader is assumed to be familiar with [RFC3945], [RFC3471], [RFC4201], [RFC4202], [RFC4203], [RFC4206], and [RFC5307].
此外，假定读者熟悉[RFC3945]、[RFC3471]、[RFC4201]、[RFC4202]、[RFC4203]、[RFC4206]和[RFC5307]。
As identified in [RFC5339], most MLN/MRN requirements rely on mechanisms and procedures (such as local procedures and policies, or specific TE mechanisms and algorithms) that are outside the scope of the GMPLS protocols, and thus do not require any GMPLS protocol extensions.
如[RFC5339]所述，大多数MLN/MRN需求依赖于超出GMPLS协议范围的机制和程序（如本地程序和策略，或特定TE机制和算法），因此不需要任何GMPLS协议扩展。
Four areas for extensions of GMPLS protocols and procedures have been identified in [RFC5339]:
[RFC5339]中确定了GMPLS协议和程序的四个扩展领域：
o GMPLS routing extensions for the advertisement of the internal adjustment capability of hybrid nodes. See Section 3.2.2 of [RFC5339].
o GMPLS路由扩展，用于宣传混合节点的内部调整能力。见[RFC5339]第3.2.2节。
o GMPLS signaling extensions for constrained multi-region signaling (Switching Capability inclusion/exclusion). See Section 3.2.1 of [RFC5339]. An additional eXclude Route Object (XRO) Label subobject is also defined since it was absent from [RFC4874].
o 用于受限多区域信令（交换能力包括/排除）的GMPLS信令扩展。见[RFC5339]第3.2.1节。由于[RFC4874]中不存在额外的排除管线对象（XRO）标签子对象，因此也定义了该子对象。
o GMPLS signaling extensions for the setup/deletion of virtual TE links (as well as exact trigger for its actual provisioning). See Section 3.1.1.2 of [RFC5339].
o 用于设置/删除虚拟TE链路的GMPLS信令扩展（以及用于实际供应的确切触发器）。见[RFC5339]第3.1.1.2节。
o GMPLS routing and signaling extensions for graceful TE link deletion. See Section 3.1.1.3 of [RFC5339].
o 用于删除TE链路的GMPLS路由和信令扩展。见[RFC5339]第3.1.1.3节。
The first three requirements are addressed in Sections 3, 4, and 5 of this document, respectively. The fourth requirement is addressed in [RFC5710] with additional context provided by [RFC5817].
本文件第3、4和5节分别阐述了前三项要求。第四个要求在[RFC5710]中进行了说明，并由[RFC5817]提供了额外的上下文。
In the MRN context, nodes that have at least one interface that supports more than one switching capability are called hybrid nodes [RFC5212]. The logical composition of a hybrid node contains at least two distinct switching elements that are interconnected by "internal links" to provide adjustment between the supported switching capabilities. These internal links have finite capacities that MUST be taken into account when computing the path of a multi-region TE-LSP. The advertisement of the internal adjustment capability is required as it provides critical information when performing multi-region path computation.
在MRN上下文中，具有至少一个支持多个交换能力的接口的节点称为混合节点[RFC5212]。混合节点的逻辑组成包含至少两个不同的交换元件，它们通过“内部链路”互连，以在支持的交换能力之间提供调整。这些内部链路具有有限的容量，在计算多区域TE-LSP的路径时必须考虑这些容量。需要公布内部调整能力，因为它在执行多区域路径计算时提供关键信息。
In an MRN environment, some LSRs could contain multiple switching capabilities, such as PSC and TDM or PSC and LSC, all under the control of a single GMPLS instance.
在MRN环境中，一些LSR可能包含多个交换功能，如PSC和TDM或PSC和LSC，所有这些都在单个GMPLS实例的控制下。
These nodes, hosting multiple Interface Switching Capabilities (ISCs) [RFC4202], are required to hold and advertise resource information on link states and topology, just like other nodes (hosting a single ISC). They may also have to consider some portions of internal node resources use to terminate hierarchical LSPs, since in circuit-switching technologies (such as TDM, LSC, and FSC) LSPs require the use of resources allocated in a discrete manner (as predetermined by the switching type). For example, a node with PSC+LSC hierarchical switching capability can switch a lambda LSP, but cannot terminate the Lambda LSP if there is no available (i.e., not already in use) adjustment capability between the LSC and the PSC switching components. Another example occurs when L2SC (Ethernet) switching can be adapted in the Link Access Procedure-SDH (LAPS) X.86 and
这些节点承载多个接口交换功能（ISC）[RFC4202]，需要像其他节点（承载单个ISC）一样，保存和公布链路状态和拓扑上的资源信息。它们还必须考虑使用内部节点资源的某些部分来终止分层LSP，因为在电路交换技术（如TDM、LSC和FSC）LSPS中需要使用以离散方式分配的资源（如由交换类型预先确定的）。例如，具有PSC+LSC分层交换能力的节点可以切换lambda LSP，但如果LSC和PSC交换组件之间没有可用（即，尚未使用）调整能力，则不能终止lambda LSP。当L2SC（以太网）交换可以在链路访问过程SDH（LAPS）X.86和
Generic Framing Procedure (GFP) for instance, before reaching the TDM switching matrix. Similar circumstances can occur, for example, if a switching fabric that supports both PSC and L2SC functionalities is assembled with LSC interfaces enabling "lambda" encoding. In the switching fabric, some interfaces can terminate Lambda LSPs and perform frame (or cell) switching whilst other interfaces can terminate Lambda LSPs and perform packet switching.
例如，在到达TDM切换矩阵之前，通用成帧过程（GFP）。例如，如果同时支持PSC和L2SC功能的交换结构与支持“lambda”编码的LSC接口组装在一起，则可能会出现类似的情况。在交换结构中，一些接口可以终止Lambda lsp并执行帧（或小区）交换，而其他接口可以终止Lambda lsp并执行分组交换。
Therefore, within multi-region networks, the advertisement of the so-called adjustment capability to terminate LSPs (not the interface capability since the latter can be inferred from the bandwidth available for each switching capability) provides the information to take into account when performing multi-region path computation. This concept enables a node to discriminate the remote nodes (and thus allows their selection during path computation) with respect to their adjustment capability, e.g., to terminate LSPs at the PSC or LSC level.
因此，在多区域网络内，所谓的终止lsp的调整能力（不是接口能力，因为后者可以从每个交换能力的可用带宽推断）的公布提供了在执行多区域路径计算时要考虑的信息。该概念使得节点能够区分远程节点（从而允许在路径计算期间选择它们）的调整能力，例如，在PSC或LSC级别终止lsp。
Hence, we introduce the capability of discriminating the (internal) adjustment capability from the (interface) switching capability by defining an Interface Adjustment Capability Descriptor (IACD).
因此，我们引入了通过定义接口调整能力描述符（IACD）来区分（内部）调整能力和（接口）切换能力的能力。
A more detailed problem statement can be found in [RFC5339].
更详细的问题说明可在[RFC5339]中找到。
The Interface Adjustment Capability Descriptor (IACD) provides the information for the forwarding/switching capability.
接口调整能力描述符（IACD）提供转发/交换能力的信息。
Note that the addition of the IACD as a TE link attribute does not modify the format of the Interface Switching Capability Descriptor (ISCD) defined in [RFC4202], and does not change how the ISCD sub-TLV is carried in the routing protocols or how it is processed when it is received [RFC4201], [RFC4203].
请注意，添加IACD作为TE链路属性不会修改[RFC4202]中定义的接口交换能力描述符（ISCD）的格式，也不会改变路由协议中ISCD子TLV的承载方式或接收时的处理方式[RFC4201]、[RFC4203]。
The receiving LSR uses its Link State Database to determine the IACD(s) of the far end of the link. Different Interface Adjustment Capabilities at two ends of a TE link are allowed.
接收LSR使用其链路状态数据库来确定链路远端的IACD。TE链路两端允许不同的接口调整功能。
In OSPF, the IACD sub-TLV is defined as an optional sub-TLV of the TE Link TLV (Type 2, see [RFC3630]), with Type 25 and variable length.
在OSPF中，IACD子TLV被定义为TE链路TLV（类型2，见[RFC3630]）的可选子TLV，类型25，长度可变。
The IACD sub-TLV format is defined as follows:
IACD子TLV格式定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower SC | Lower Encoding| Upper SC | Upper Encoding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjustment Capability-specific information |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower SC | Lower Encoding| Upper SC | Upper Encoding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjustment Capability-specific information |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lower Switching Capability (SC) field (byte 1) - 8 bits
低交换能力（SC）字段（字节1）-8位
Indicates the lower switching capability associated with the Lower Encoding field (byte 2). The value of the Lower Switching Capability field MUST be set to the value of Switching Capability of the ISCD sub-TLV advertised for this TE link. If multiple ISCD sub-TLVs are advertised for that TE link, the Lower Switching Capability (SC) value MUST be set to the value of SC to which the adjustment capacity is associated.
表示与较低编码字段（字节2）相关的较低切换能力。较低切换能力字段的值必须设置为为该TE链路播发的ISCD子TLV的切换能力值。如果为该TE链路播发多个ISCD子TLV，则必须将较低的开关容量（SC）值设置为与调整容量相关联的SC值。
Lower Encoding (byte 2) - 8 bits
低位编码（字节2）-8位
Contains one of the LSP Encoding Type values specified in Section 3.1.1 of [RFC3471] and updates.
包含[RFC3471]第3.1.1节和更新中规定的LSP编码类型值之一。
Upper Switching Capability (SC) field (byte 3) - 8 bits
上层交换能力（SC）字段（字节3）-8位
Indicates the upper switching capability. The Upper Switching Capability field MUST be set to one of the values defined in [RFC4202].
表示较高的切换能力。上限切换能力字段必须设置为[RFC4202]中定义的值之一。
Upper Encoding (byte 4) - 8 bits
高位编码（字节4）-8位
Set to the encoding of the available adjustment capacity and to 0xFF when the corresponding SC value has no access to the wire, i.e., there is no ISC sub-TLV for this upper switching capability. The adjustment capacity is the set of resources associated to the upper switching capability.
设置为可用调整容量的编码，并在相应的SC值无法访问导线时设置为0xFF，即，此上限开关容量没有ISC子TLV。调整容量是与较高交换容量相关联的一组资源。
Max LSP Bandwidth
最大LSP带宽
The Maximum LSP Bandwidth is encoded as a list of eight 4-octet fields in the IEEE floating point format [IEEE], with priority 0 first and priority 7 last. The units are bytes per second. Processing MUST follow the rules specified in [RFC4202].
最大LSP带宽编码为IEEE浮点格式[IEEE]中八个4-octet字段的列表，优先级为0，优先级为7。单位为每秒字节数。处理必须遵循[RFC4202]中指定的规则。
The Adjustment Capability-specific information - variable
调整能力特定信息-变量
This field is defined so as to leave the possibility for future addition of technology-specific information associated to the adjustment capability.
该字段的定义为将来添加与调整能力相关的技术特定信息留下了可能性。
Other fields MUST be processed as specified in [RFC4202] and [RFC4203].
其他字段必须按照[RFC4202]和[RFC4203]中的规定进行处理。
The bandwidth values provide an indication of the resources still available to perform insertion/extraction for a given adjustment at a given priority (resource pool concept: set of shareable available resources that can be assigned dynamically).
带宽值指示仍可用于在给定优先级下执行给定调整的插入/提取的资源（资源池概念：可动态分配的可共享可用资源集）。
Multiple IACD sub-TLVs MAY be present within a given TE Link TLV.
给定TE链路TLV内可能存在多个IACD子TLV。
The presence of the IACD sub-TLV as part of the TE Link TLV does not modify the format/messaging and the processing associated to the ISCD sub-TLV defined in [RFC4203].
作为TE链路TLV一部分的IACD子TLV的存在不会修改与[RFC4203]中定义的ISCD子TLV相关的格式/消息传递和处理。
In IS-IS, the IACD sub-TLV is an optional sub-TLV of the Extended IS Reachability TLV (see [RFC5305]) with Type 27.
在IS-IS中，IACD子TLV是扩展IS可达性TLV的可选子TLV（参见[RFC5305]），类型为27。
The IACD sub-TLV format is identical to the OSPF sub-TLV format defined in Section 3.2.1. The fields of the IACD sub-TLV have the same processing and interpretation rules as defined in Section 3.2.1.
IACD子TLV格式与第3.2.1节中定义的OSPF子TLV格式相同。IACD子TLV的字段具有第3.2.1节中定义的相同处理和解释规则。
Multiple IACD sub-TLVs MAY be present within a given extended IS reachability TLV.
在给定的扩展IS可达性TLV中可能存在多个IACD子TLV。
The presence of the IACD sub-TLV as part of the extended IS reachability TLV does not modify format/messaging and processing associated to the ISCD sub-TLV defined in [RFC5307].
作为扩展IS可达性TLV一部分的IACD子TLV的存在不会修改与[RFC5307]中定义的ISCD子TLV相关的格式/消息传递和处理。
Section 6.2 of [RFC4206] specifies that when a region boundary node receives a Path message, the node determines whether or not it is at the edge of an LSP region with respect to the Explicit Route Object (ERO) carried in the message. If the node is at the edge of a region, it must then determine the other edge of the region with respect to the Explicit Route Object (ERO), using the IGP database. The node then extracts from the ERO the sub-sequence of hops from itself to the other end of the region.
[RFC4206]第6.2节规定，当区域边界节点接收到路径消息时，该节点根据消息中携带的显式路由对象（ERO）确定其是否位于LSP区域的边缘。如果节点位于某个区域的边缘，则必须使用IGP数据库确定该区域相对于显式路由对象（ERO）的另一个边缘。然后，节点从ERO中提取从自身到区域另一端的跳的子序列。
The node then compares the sub-sequence of hops with all existing Forwarding Agency LSPs (FA-LSPs) originated by the node:
然后，该节点将跳的子序列与该节点发起的所有现有转发代理LSP（FA LSP）进行比较：
o If a match is found, that FA-LSP has enough unreserved bandwidth for the LSP being signaled, and the Generalized PID (G-PID) of the FA-LSP is compatible with the G-PID of the LSP being signaled, the node uses that FA-LSP as follows. The Path message for the original LSP is sent to the egress of the FA-LSP. The previous hop (PHOP) in the message is the address of the node at the head-end of the FA-LSP. Before sending the Path message, the ERO in that message is adjusted by removing the subsequence of the ERO that lies in the FA-LSP, and replacing it with just the endpoint of the FA-LSP.
o 如果找到匹配项，则FA-LSP具有足够的无保留带宽用于发送信号的LSP，并且FA-LSP的广义PID（G-PID）与发送信号的LSP的G-PID兼容，则节点使用该FA-LSP，如下所示。原始LSP的路径消息被发送到FA-LSP的出口。消息中的前一跳（PHOP）是FA-LSP前端节点的地址。在发送Path消息之前，通过移除FA-LSP中ERO的子序列，并将其替换为FA-LSP的端点来调整该消息中的ERO。
o If no existing FA-LSP is found, the node sets up a new FA-LSP. That is, it initiates a new LSP setup just for the FA-LSP.
o 如果未找到现有FA-LSP，则节点将设置新的FA-LSP。也就是说，它仅为FA-LSP启动新的LSP设置。
Note: compatible G-PID implies that traffic can be processed by both ends of the FA-LSP without dropping traffic after its establishment.
注：兼容G-PID意味着FA-LSP的两端可以处理流量，而不会在其建立后丢弃流量。
Applying the procedure of [RFC4206] in an MRN environment MAY lead to the setup of single-hop FA-LSPs between each pair of nodes. Therefore, considering that the path computation is able to take into account richness of information with regard to the SC available on given nodes belonging to the path, it is consistent to provide enough signaling information to indicate the SC to be used and over which link. Particularly, in case a TE link has multiple SCs advertised as part of its ISCD sub-TLVs, an ERO does not provide a mechanism to select a particular SC.
在MRN环境中应用[rfc40206]的过程可导致在每对节点之间建立单跳FA lsp。因此，考虑到路径计算能够考虑到关于属于该路径的给定节点上可用的SC的丰富信息，提供足够的信令信息来指示要使用的SC以及在哪个链路上使用SC是一致的。特别是，如果TE链路有多个SC作为其ISCD子TLV的一部分进行广告，则ERO不提供选择特定SC的机制。
In order to limit the modifications to existing RSVP-TE procedures ([RFC3473] and referenced), this document defines a new subobject of the eXclude Route Object (XRO), see [RFC4874], called the Switching Capability subobject. This subobject enables (when desired) the explicit identification of at least one switching capability to be excluded from the resource selection process described above.
为了限制对现有RSVP-TE程序的修改（[RFC3473]和参考文件），本文件定义了排除路由对象（XRO）的新子对象，请参见[RFC4874]，称为交换能力子对象。该子对象允许（在需要时）明确标识至少一个要从上述资源选择过程中排除的交换能力。
Including this subobject as part of the XRO that explicitly indicates which SCs have to be excluded (before initiating the procedure described here above) over a specified TE link, solves the ambiguous choice among SCs that are potentially used along a given path and give the possibility to optimize resource usage on a multi-region basis. Note that implicit SC inclusion is easily supported by explicitly excluding other SCs (e.g., to include LSC, it is required to exclude PSC, L2SC, TDM, and FSC).
将此子对象作为XRO的一部分，明确指出在指定TE链路上必须排除哪些SCs（在启动上述程序之前），解决了可能沿给定路径使用的SCs之间的模糊选择，并提供了在多区域基础上优化资源使用的可能性。请注意，通过明确排除其他SC（例如，要包括LSC，需要排除PSC、L2SC、TDM和FSC），可以很容易地支持隐式SC包含。
The approach followed here is to concentrate exclusions in XRO and inclusions in ERO. Indeed, the ERO specifies the topological characteristics of the path to be signaled. Usage of Explicit Exclusion Route Subobjects (EXRSs) would also lead in the exclusion over certain portions of the LSP during the FA-LSP setup. Thus, it is more suited to extend generality of the elements excluded by the XRO but also prevent complex consistency checks as well as transpositions between EXRS and XRO at FA-LSP head-ends.
此处采用的方法是集中XRO中的排除和ERO中的包含。实际上，ERO指定了要发送信号的路径的拓扑特征。在FA-LSP设置期间，使用显式排除路由子对象（EXRSs）也会导致LSP某些部分的排除。因此，它更适合扩展XRO排除的元素的通用性，但也可以防止复杂的一致性检查以及FA-LSP前端EXR和XRO之间的换位。
The contents of an EXCLUDE_ROUTE object defined in [RFC4874] are a series of variable-length data items called subobjects.
[RFC4874]中定义的排除路由对象的内容是一系列称为子对象的可变长度数据项。
This document defines the Switching Capability (SC) subobject of the XRO (Type 35), its encoding, and processing. It also complements the subobjects defined in [RFC4874] with a Label subobject (Type 3).
本文件定义了XRO（35型）的交换能力（SC）子对象及其编码和处理。它还使用标签子对象（类型3）来补充[RFC4874]中定义的子对象。
XRO subobject Type 35: Switching Capability
XRO子对象类型35：切换能力
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=35 | Length | Attribute | Switching Cap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=35 | Length | Attribute | Switching Cap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L (1 bit)
L（1位）
0 indicates that the attribute specified MUST be excluded.
0表示必须排除指定的属性。
1 indicates that the attribute specified SHOULD be avoided.
1表示应避免指定的属性。
Type (7 bits)
类型（7位）
The Type of the XRO SC subobject is 35.
XRO SC子对象的类型为35。
Length (8 bits)
长度（8位）
The total length of the subobject in bytes (including the Type and Length fields). The Length of the XRO SC subobject is 4.
子对象的总长度（以字节为单位）（包括类型和长度字段）。XRO SC子对象的长度为4。
Attribute (8 bits)
属性（8位）
0 reserved value.
0保留值。
1 indicates that the specified SC SHOULD be excluded or avoided with respect to the preceding numbered (Type 1 or Type 2) or unnumbered interface (Type) subobject.
1表示应排除或避免与前面编号（类型1或类型2）或未编号接口（类型）子对象相关的指定SC。
Switching Cap (8 bits)
开关帽（8位）
Switching Capability value to be excluded.
不包括开关能力值。
The Switching Capability subobject MUST follow the set of one or more numbered or unnumbered interface subobjects to which this subobject refers.
交换能力子对象必须跟随该子对象所引用的一个或多个编号或未编号接口子对象的集合。
In the case of a loose-hop ERO subobject, the XRO subobject MUST precede the loose-hop subobject identifying the tail-end node/interface of the traversed region(s).
对于loose-hop ERO子对象，XRO子对象必须位于loose-hop子对象之前，以标识遍历区域的尾端节点/接口。
The encoding of the XRO Label subobject is identical to the Label ERO subobject defined in [RFC3473] with the exception of the L bit. The XRO Label subobject is defined as follows:
XRO标签子对象的编码与[RFC3473]中定义的标签ERO子对象相同，但L位除外。XRO标签子对象定义如下：
XRO Subobject Type 3: Label Subobject
XRO子对象类型3：标签子对象
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=3 | Length |U| Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=3 | Length |U| Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L (1 bit)
L（1位）
0 indicates that the attribute specified MUST be excluded.
0表示必须排除指定的属性。
1 indicates that the attribute specified SHOULD be avoided.
1表示应避免指定的属性。
Type (7 bits)
类型（7位）
The Type of the XRO Label subobject is 3.
XRO标签子对象的类型为3。
Length (8 bits)
长度（8位）
The total length of the subobject in bytes (including the Type and Length fields). The Length is always divisible by 4.
子对象的总长度（以字节为单位）（包括类型和长度字段）。长度总是可以被4整除。
U (1 bit)
U（1位）
See [RFC3471].
参见[RFC3471]。
C-Type (8 bits)
C型（8位）
The C-Type of the included Label Object. Copied from the Label Object (see [RFC3471]).
包含的标签对象的C类型。从标签对象复制（请参见[RFC3471]）。
Label
标签
See [RFC3471].
参见[RFC3471]。
XRO Label subobjects MUST follow the numbered or unnumbered interface subobjects to which they refer, and, when present, MUST also follow the Switching Capability subobject.
XRO标签子对象必须位于其所引用的编号或未编号接口子对象之后，并且当存在时，还必须位于交换能力子对象之后。
When XRO Label subobjects are following the Switching Capability subobject, the corresponding label values MUST be compatible with the SC capability to be explicitly excluded.
当XRO标签子对象跟随切换能力子对象时，相应的标签值必须与要明确排除的SC能力兼容。
A virtual TE link is defined as a TE link between two upper-layer nodes that is not associated with a fully provisioned FA-LSP in a lower layer [RFC5212]. A virtual TE link is advertised as any TE link, following the rules in [RFC4206] defined for fully provisioned TE links. A virtual TE link represents thus the potentiality to set up an FA-LSP in the lower layer to support the TE link that has been advertised. In particular, the flooding scope of a virtual TE link is within an IGP area, as is the case for any TE link.
虚拟TE链路定义为两个上层节点之间的TE链路，该链路与下层中完全配置的FA-LSP不关联[RFC5212]。根据[RFC4206]中为完全配置的TE链路定义的规则，虚拟TE链路作为任何TE链路进行广告。因此，虚拟TE链路表示在较低层中建立FA-LSP以支持已公布的TE链路的潜力。特别地，虚拟TE链路的泛洪范围在IGP区域内，如同任何TE链路的情况一样。
Two techniques can be used for the setup, operation, and maintenance of virtual TE links. The corresponding GMPLS protocols extensions are described in this section. The procedures described in this section complement those defined in [RFC4206] and [HIER-BIS].
有两种技术可用于虚拟TE链路的设置、操作和维护。本节介绍了相应的GMPLS协议扩展。本节所述程序补充了[RFC4206]和[HIER-BIS]中定义的程序。
This approach, that does not require state maintenance on transit LSRs, relies on extensions to the GMPLS RSVP-TE Call procedure (see [RFC4974]). This technique consists of exchanging identification and TE attributes information directly between TE link endpoints through the establishment of a call between terminating LSRs. These TE link endpoints correspond to the LSP head-end and tail-end points of the LSPs that will be established. The endpoints MUST belong to the same (LSP) region.
这种方法不需要对运输LSR进行状态维护，它依赖于对GMPLS RSVP-TE调用过程的扩展（参见[RFC4974]）。该技术包括通过在终止的LSR之间建立调用，在TE链路端点之间直接交换标识和TE属性信息。这些TE链路端点对应于将要建立的LSP的LSP头端点和尾端点。端点必须属于同一（LSP）区域。
Once the call is established, the resulting association populates the local Traffic Engineering DataBase (TEDB) and the resulting virtual TE link is advertised as any other TE link. The latter can then be used to attract traffic. When an upper-layer/region LSP tries to make use of this virtual TE link, one or more FA LSPs MUST be established using the procedures defined in [RFC4206] to make the virtual TE link "real" and allow it to carry traffic by nesting the upper-layer/region LSP.
一旦建立了呼叫，产生的关联将填充本地流量工程数据库（TEDB），并且产生的虚拟TE链接将作为任何其他TE链接发布。后者可以用来吸引交通。当上层/区域LSP尝试使用该虚拟TE链路时，必须使用[RFC4206]中定义的程序建立一个或多个FA LSP，以使虚拟TE链路“真实”，并允许其通过嵌套上层/区域LSP承载流量。
In order to distinguish usage of such call from the call and associated procedures defined in [RFC4974], a CALL_ATTRIBUTES object is introduced.
为了区分此类调用与[RFC4974]中定义的调用和相关过程的使用，引入了call_ATTRIBUTES对象。
The CALL_ATTRIBUTES object is used to signal attributes required in support of a call, or to indicate the nature or use of a call. It is modeled on the LSP_ATTRIBUTES object defined in [RFC5420]. The CALL_ATTRIBUTES object MAY also be used to report call operational state on a Notify message.
CALL_ATTRIBUTES对象用于表示支持调用所需的属性，或指示调用的性质或使用。它以[RFC5420]中定义的LSP_属性对象为模型。CALL_ATTRIBUTES对象还可用于在Notify消息上报告调用操作状态。
The CALL_ATTRIBUTES object class is 202 of the form 11bbbbbb. This C-Num value (see [RFC2205], Section 3.10) ensures that LSRs that do not recognize the object pass it on transparently.
CALL_ATTRIBUTES对象类是形式为11bbbb的202。该C-Num值（参见[RFC2205]，第3.10节）确保不识别对象的LSR透明地传递对象。
One C-Type is defined, C-Type = 1 for Call Attributes. This object is OPTIONAL and MAY be placed on Notify messages to convey additional information about the desired attributes of the call.
定义了一个C-Type，调用属性的C-Type=1。此对象是可选的，可以放置在Notify消息上，以传递有关调用所需属性的附加信息。
CALL_ATTRIBUTES class = 202, C-Type = 1
调用属性类=202，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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Call Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Call Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Call Attributes TLVs are encoded as described in Section 5.1.3.
呼叫属性TLV的编码如第5.1.3节所述。
If an egress (or intermediate) LSR does not support the object, it forwards it unexamined and unchanged. This facilitates the exchange of attributes across legacy networks that do not support this new object.
如果出口（或中间）LSR不支持该对象，它将未经检查且未更改地转发该对象。这有助于在不支持此新对象的传统网络之间交换属性。
Attributes carried by the CALL_ATTRIBUTES object are encoded within TLVs named Call Attributes TLVs. One or more Call Attributes TLVs MAY be present in each object.
CALL_Attributes对象携带的属性在名为CALL Attributes TLV的TLV中编码。每个对象中可能存在一个或多个调用属性TLV。
There are no ordering rules for Call Attributes TLVs, and no interpretation SHOULD be placed on the order in which these TLVs are received.
呼叫属性TLV没有排序规则，并且不应对这些TLV的接收顺序进行解释。
Each Call Attributes TLV carried by the CALL_ATTRIBUTES object is encoded as follows:
Call_Attributes对象携带的每个Call Attributes TLV编码如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
The identifier of the TLV.
TLV的标识符。
Length
长
Indicates the total length of the TLV in octets. That is, the combined length of the Type, Length, and Value fields, i.e., four plus the length of the Value field in octets.
表示TLV的总长度（以八位字节为单位）。也就是说，类型、长度和值字段的组合长度，即四加上值字段的长度（以八位字节为单位）。
The entire TLV MUST be padded with between zero and three trailing zeros to make it four-octet aligned. The Length field does not count any padding.
整个TLV必须填充0到3个尾随零之间，以使其与4个八位组对齐。长度字段不计算任何填充。
Value
价值
The data field for the TLV padded as described above.
如上所述填充TLV的数据字段。
Assignment of Call Attributes TLV types MUST follow the rules specified in Section 8 (IANA Considerations).
调用属性TLV类型的分配必须遵循第8节（IANA注意事项）中指定的规则。
The Call Attributes TLV of Type 1 defines the Call Attributes Flags TLV. The Call Attributes Flags TLV MAY be present in a CALL_ATTRIBUTES object.
类型1的调用属性TLV定义调用属性标志TLV。调用属性标志TLV可能存在于调用属性对象中。
The Call Attributes Flags TLV value field is an array of units of 32 flags numbered from the most significant bit as bit zero. The Length field for this TLV MUST therefore always be a multiple of 4 bytes, regardless of the number of bits carried and no padding is required.
Call Attributes Flags TLV value（调用属性标志TLV值）字段是一个由32个标志组成的单元数组，这些标志从最高有效位开始编号为零位。因此，该TLV的长度字段必须始终是4字节的倍数，而不考虑所携带的位数，并且不需要填充。
Unassigned bits are considered reserved and MUST be set to zero on transmission by the originator of the object. Bits not contained in the Call Attributes Flags TLV MUST be assumed to be set to zero. If the Call Attributes Flags TLV is absent, either because it is not contained in the CALL_ATTRIBUTES object or because this object is itself absent, all processing MUST be performed as though the bits were present and set to zero. In other terms, assigned bits that are not present either because the Call Attributes Flags TLV is deliberately foreshortened or because the TLV is not included MUST be treated as though they are present and are set to zero.
未分配的位被认为是保留的，并且在对象的发起者传输时必须设置为零。必须假定调用属性标志TLV中不包含的位设置为零。如果由于Call_Attributes对象中不包含调用属性标志TLV，或者由于该对象本身不存在，因此不存在调用属性标志TLV，则必须执行所有处理，就像位存在并设置为零一样。换句话说，由于调用属性标志TLV被故意缩短或由于TLV未被包括而不存在的分配位必须被视为存在并设置为零。
This document introduces a specific Call Inheritance Flag at position bit 0 (most significant bit) in the Call Attributes Flags TLV. This flag indicates that the association initiated between the endpoints belonging to a call results into a (virtual) TE link advertisement.
本文档在调用属性标志TLV的第0位（最高有效位）引入了一个特定的调用继承标志。此标志表示属于调用的端点之间启动的关联将导致（虚拟）TE链接播发。
The Call Inheritance Flag MUST be set to 1 in order to indicate that the established association is to be translated into a TE link advertisement. The value of this flag SHALL by default be set to 1. Setting this flag to 0 results in a hidden TE link or in deleting the corresponding TE link advertisement (by setting the corresponding Opaque LSA Age to MaxAge) if the association had been established with this flag set to 1. In the latter case, the corresponding FA-LSP SHOULD also be torn down to prevent unused resources.
调用继承标志必须设置为1，以指示将建立的关联转换为TE链接播发。默认情况下，该标志的值应设置为1。将此标志设置为0会导致隐藏TE链接或删除相应的TE链接播发（通过将相应的不透明LSA年龄设置为MaxAge），前提是已建立关联并将此标志设置为1。在后一种情况下，还应拆除相应的FA-LSP，以防止未使用的资源。
The Notify message used for establishing the association is defined as per [RFC4974]. Additionally, the Notify message MUST carry an LSP_TUNNEL_INTERFACE_ID Object, that allows identifying unnumbered FA-LSPs ([RFC3477], [RFC4206], [HIER-BIS]) and numbered FA-LSPs ([RFC4206], [HIER-BIS]).
用于建立关联的通知消息按照[RFC4974]定义。此外，Notify消息必须携带LSP_TUNNEL_INTERFACE_ID对象，该对象允许识别未编号的FA LSP（[RFC3477]、[RFC4206]、[HIER-BIS]）和编号的FA LSP（[RFC4206]、[HIER-BIS]）。
The Soft Forwarding Adjacency (Soft FA) approach consists of setting up the FA LSP at the control plane level without actually committing resources in the data plane. This means that the corresponding LSP exists only in the control plane domain. Once such an FA is established, the corresponding TE link can be advertised following the procedures described in [RFC4206].
软转发邻接（Soft FA）方法包括在控制平面级别设置FA LSP，而不在数据平面中实际提交资源。这意味着相应的LSP仅存在于控制平面域中。一旦建立了这样一个FA，就可以按照[RFC4206]中描述的步骤通告相应的TE链路。
There are two techniques to set up Soft FAs:
设置软FAs有两种方法：
o The first one consists in setting up the FA LSP by precluding resource commitment during its establishment. These are known as pre-planned LSPs.
o 第一种是通过在建立FA LSP期间排除资源承诺来建立FA LSP。这些被称为预先计划的LSP。
o The second technique consists in making use of path-provisioned LSPs only. In this case, there is no associated resource demand during the LSP establishment. This can be considered as the RSVP-TE equivalent of the Null service type specified in [RFC2997].
o 第二种技术包括仅使用路径配置的LSP。在这种情况下，在LSP建立期间没有相关的资源需求。这可以被视为[RFC2997]中指定的空服务类型的RSVP-TE等价物。
The LSP ATTRIBUTES object and Attributes Flags TLV are defined in [RFC5420]. The present document defines a new flag, the Pre-Planned LSP flag, in the existing Attributes Flags TLV (numbered as Type 1).
LSP属性对象和属性标志TLV在[RFC5420]中定义。本文件在现有属性标志TLV（编号为类型1）中定义了一个新标志，即预先计划的LSP标志。
The position of this flag is bit 6 in accordance with IANA assignment. This flag, part of the Attributes Flags TLV, follows general processing of [RFC5420] for LSP_REQUIRED_ATTRIBUTE object. That is, LSRs that do not recognize the object reject the LSP setup effectively saying that they do not support the attributes requested. Indeed, the newly defined attribute requires examination at all transit LSRs along the LSP being established.
根据IANA分配，该标志的位置为第6位。该标志是属性标志TLV的一部分，遵循[RFC5420]对LSP_REQUIRED_属性对象的一般处理。也就是说，不识别对象的LSR会有效地拒绝LSP设置，说它们不支持请求的属性。事实上，新定义的属性需要在正在建立的LSP沿线的所有过境LSR处进行检查。
The Pre-Planned LSP flag can take one of the following values:
预先计划的LSP标志可以采用以下值之一：
o When set to 0, this means that the LSP MUST be fully provisioned. Absence of this flag (hence corresponding TLV) is therefore compliant with the signaling message processing per [RFC3473]).
o 当设置为0时，这意味着必须完全配置LSP。因此，缺少该标志（因此对应的TLV）符合[RFC3473]规定的信令消息处理。
o When set to 1, this means that the LSP MUST be provisioned in the control plane only.
o 当设置为1时，这意味着必须仅在控制平面中设置LSP。
If an LSP is established with the Pre-Planned flag set to 1, no resources are committed at the data plane level.
如果在预先计划标志设置为1的情况下建立LSP，则不会在数据平面级别提交任何资源。
The operation of committing data plane resources occurs by re-signaling the same LSP with the Pre-Planned flag set to 0. It is RECOMMENDED that no other modifications are made to other RSVP objects during this operation. That is each intermediate node, processing a flag transiting from 1 to 0 shall only be concerned with the commitment of data plane resources and no other modification of the LSP properties and/or attributes.
提交数据平面资源的操作是通过在预先计划的标志设置为0的情况下重新发送相同的LSP来进行的。建议在此操作期间不要对其他RSVP对象进行其他修改。也就是说，每个中间节点，处理从1到0的标志只应涉及数据平面资源的分配，而不涉及LSP属性和/或属性的其他修改。
If an LSP is established with the Pre-Planned flag set to 0, it MAY be re-signaled by setting the flag to 1.
如果在预先计划的标志设置为0的情况下建立LSP，则可通过将标志设置为1来重新通知LSP。
There is a difference between an LSP that is established with 0 bandwidth (path provisioning) and an LSP that is established with a certain bandwidth value not committed at the data plane level (i.e., pre-planned LSP).
使用0带宽（路径供应）建立的LSP与使用未在数据平面级别提交的特定带宽值（即预先计划的LSP）建立的LSP之间存在差异。
Mechanisms for provisioning (pre-planned or not) LSP with 0 bandwidth is straightforward for PSC LSP: in the SENDER_TSPEC/FLOWSPEC object, the Peak Data Rate field of IntServ objects (see [RFC2210]) MUST be set to 0. For L2SC LSP: the Committed Information Rate (CIR), Excess Information Rate (EIR), Committed Burst Size (CBS), and Excess Burst Size (EBS) values MUST be set to 0 in the Type 2 sub-TLV of the Ethernet Bandwidth Profile TLV. In both cases, upon LSP resource commitment, actual traffic parameter values are used to perform corresponding resource reservation.
对于PSC LSP，带宽为0的LSP配置（预先规划或非预先规划）机制非常简单：在SENDER_TSPEC/FLOWSPEC对象中，IntServ对象的峰值数据速率字段（请参见[RFC2210]）必须设置为0。对于L2SC LSP：在以太网带宽配置文件TLV的类型2子TLV中，提交信息速率（CIR）、过量信息速率（EIR）、提交突发大小（CBS）和过量突发大小（EBS）值必须设置为0。在这两种情况下，在LSP资源承诺时，使用实际的流量参数值来执行相应的资源预留。
However, mechanisms for provisioning (pre-planned or not) a TDM or LSC LSP with 0 bandwidth is currently not possible because the exchanged label value is tightly coupled with resource allocation during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP). For TDM and LSC LSP, a NULL Label value is used to prevent resource allocation at the data plane level. In these cases, upon LSP resource commitment, actual label value exchange is performed to commit allocation of timeslots/ wavelengths.
然而，由于交换的标签值在LSP信令期间与资源分配紧密耦合（例如，有关SONET/SDH LSP，请参阅[RFC4606]），因此目前不可能提供（预先规划或非预先规划）具有0带宽的TDM或LSC LSP的机制。对于TDM和LSC LSP，空标签值用于防止数据平面级别的资源分配。在这些情况下，在LSP资源承诺时，执行实际标签值交换以提交时隙/波长的分配。
New objects and procedures defined in this document are running within a given TE domain, defined as group of LSRs that enforces a common TE policy. Thus, the extensions defined in this document are expected to run in the context of a consistent TE policy. Specification of a consistent TE policy is outside the scope of this document.
本文档中定义的新对象和过程在给定的TE域中运行，该域定义为强制执行公共TE策略的LSR组。因此，本文档中定义的扩展预计将在一致TE策略的上下文中运行。一致TE政策的规范不在本文件的范围内。
In such TE domains, we distinguish between edge LSRs and intermediate LSRs. Edge LSRs MUST be able to process Call Attributes as defined in Section 5.1 if this is the method selected for creating edge-to-edge associations. In that domain, intermediate LSRs are by definition transparent to the Call processing.
在这样的TE域中，我们区分边缘LSR和中间LSR。如果选择此方法创建边到边关联，则边缘LSR必须能够处理第5.1节中定义的调用属性。在该域中，根据定义，中间LSR对呼叫处理是透明的。
In case the Soft FA method is used for the creation of virtual TE links, edge and intermediate LSRs MUST support processing of the LSP ATTRIBUTE object per Section 5.2.
如果软FA方法用于创建虚拟TE链接，则边缘和中间LSR必须支持根据第5.2节处理LSP属性对象。
This document does not introduce any new security considerations from the ones already detailed in [RFC5920] that describes the MPLS and GMPLS security threats, the related defensive techniques, and the mechanisms for detection and reporting. Indeed, the applicability of the proposed GMPLS extensions is limited to single TE domain. Such a domain is under the authority of a single administrative entity. In this context, multiple switching layers comprised within such TE domain are under the control of a single GMPLS control plane instance.
本文件未介绍[RFC5920]中已详细说明的任何新的安全注意事项，这些注意事项描述了MPLS和GMPLS安全威胁、相关防御技术以及检测和报告机制。事实上，建议的GMPLS扩展的适用性仅限于单个TE域。这样一个领域由一个单一的行政实体管理。在此上下文中，包含在此类TE域中的多个交换层在单个GMPLS控制平面实例的控制下。
Nevertheless, Call initiation, as depicted in Section 5.1, MUST strictly remain under control of the TE domain administrator. To prevent any abuse of Call setup, edge nodes MUST ensure isolation of their call controller (i.e., the latter is not reachable via external TE domains). To further prevent man-in-the-middle attacks, security associations MUST be established between edge nodes initiating and terminating calls. For this purpose, Internet Key Exchange (IKE) protocol [RFC5996] MUST be used for performing mutual authentication and establishing and maintaining these security associations.
然而，如第5.1节所述，呼叫发起必须严格受TE域管理员的控制。为了防止滥用呼叫设置，边缘节点必须确保其呼叫控制器的隔离（即，后者无法通过外部TE域访问）。为了进一步防止中间人攻击，必须在发起和终止呼叫的边缘节点之间建立安全关联。为此，必须使用Internet密钥交换（IKE）协议[RFC5996]执行相互身份验证，并建立和维护这些安全关联。
IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry available from http://www.iana.org.
IANA在“RSVP参数”注册表的“类名、类号和类类型”部分进行了以下赋值，可从http://www.iana.org.
This document introduces a new class named CALL_ATTRIBUTES, which has been created in the 11bbbbbb range with the following definition:
本文档介绍了一个名为CALL_ATTRIBUTES的新类，该类已在11bbbb范围内创建，定义如下：
Class Number Class Name Reference
------------ ----------------------- ---------
202 CALL ATTRIBUTES [RFC6001]
Class Number Class Name Reference
------------ ----------------------- ---------
202 CALL ATTRIBUTES [RFC6001]
Class Type (C-Type):
类别类型（C类）：
1 Call Attributes [RFC6001]
1呼叫属性[RFC6001]
IANA has established a "Call Attributes TLV" registry. The following types are defined:
IANA已经建立了“呼叫属性TLV”注册表。定义了以下类型：
TLV Value Name Reference
--------- ------------------------- ---------
0 Reserved [RFC6001]
1 Call Attributes Flags TLV [RFC6001]
TLV Value Name Reference
--------- ------------------------- ---------
0 Reserved [RFC6001]
1 Call Attributes Flags TLV [RFC6001]
The values should be allocated based on the following allocation policy as defined in [RFC5226].
应根据[RFC5226]中定义的以下分配策略分配值。
Range Registration Procedures
----- ------------------------
0-32767 RFC Required
32768-65535 Reserved for Private Use
Range Registration Procedures
----- ------------------------
0-32767 RFC Required
32768-65535 Reserved for Private Use
IANA has established a "Call Attributes Flags" registry. The following flags are defined:
IANA已经建立了一个“调用属性标志”注册表。定义了以下标志：
Bit Number 32-bit Value Name Reference
---------- ------------ --------------------- ---------
0 0x80000000 Call Inheritance Flag [RFC6001]
Bit Number 32-bit Value Name Reference
---------- ------------ --------------------- ---------
0 0x80000000 Call Inheritance Flag [RFC6001]
The values should be allocated based on the "RFC Required" policy as defined in [RFC5226].
应根据[RFC5226]中定义的“需要RFC”策略分配值。
This document introduces a new Flag in the Attributes Flags TLV defined in [RFC5420]:
本文档在[RFC5420]中定义的属性标志TLV中引入了一个新标志：
Bit Number Name Reference
---------- -------------------- ---------
6 Pre-Planned LSP Flag [RFC6001]
Bit Number Name Reference
---------- -------------------- ---------
6 Pre-Planned LSP Flag [RFC6001]
This document introduces two new subobjects for the EXCLUDE_ROUTE object [RFC4874], C-Type 1.
本文档介绍了EXCLUDE_ROUTE对象[RFC4874]的两个新子对象，即C-Type 1。
Subobject Type Subobject Description
-------------- -------------------------
3 Label
35 Switching Capability (SC)
Subobject Type Subobject Description
-------------- -------------------------
3 Label
35 Switching Capability (SC)
IANA maintains the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registries including the "Types for sub-TLVs of TE link TLV (Value 2)" registry.
IANA维护“开放最短路径优先（OSPF）流量工程TLV”注册表，包括“TE链路TLV子TLV类型（值2）”注册表。
This document defines the following sub-TLV of TE link TLV (Value 2).
本文件定义了TE link TLV的以下子TLV（值2）。
Value Sub-TLV
----- -------------------------------------------------
25 Interface Adjustment Capability Descriptor (IACD)
Value Sub-TLV
----- -------------------------------------------------
25 Interface Adjustment Capability Descriptor (IACD)
This document defines the following new sub-TLV type of top-level TLV 22 that has been reflected in the ISIS sub-TLV registry for TLV 22, 141, and 222:
本文件定义了顶级TLV 22的以下新子TLV类型，该类型已反映在TLV 22、141和222的ISIS子TLV注册表中：
Type Description Length
---- ------------------------------------------------- ------
27 Interface Adjustment Capability Descriptor (IACD) Var.
Type Description Length
---- ------------------------------------------------- ------
27 Interface Adjustment Capability Descriptor (IACD) Var.
[IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985.
[IEEE]IEEE，“二进制浮点运算的IEEE标准”，标准754-1985，1985。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[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月。
[RFC2997] Bernet, Y., Smith, A., and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[RFC2997]Bernet，Y.，Smith，A.，和B.Davie，“空服务类型的规范”，RFC 2997，2000年11月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[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月。
[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月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4606]Mannie，E.和D.Papadimitriou，“同步光网络（SONET）和同步数字体系（SDH）控制的通用多协议标签交换（GMPLS）扩展”，RFC 4606，2006年8月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 48742007年4月。
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007.
[RFC4974]Papadimitriou，D.和A.Farrel，“支持呼叫的通用MPLS（GMPLS）RSVP-TE信令扩展”，RFC 4974，2007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，2008年10月。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayyangarps，“使用资源预留协议流量工程（RSVP-TE）建立MPLS LSP的属性编码”，RFC 5420，2009年2月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[HIER-BIS] Shiomoto, K., Ed., and A. Farrel, "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", Work in Progress, February 2010.
[HIER-BIS]Shiomoto，K.，Ed.，和A.Farrel，“动态信号分层标签交换路径的程序”，正在进行的工作，2010年2月。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008.
[RFC5212]Shiomoto，K.，Papadimitriou，D.，Le Roux，JL.，Vigoureux，M.，和D.Brungard，“基于GMPLS的多区域和多层网络（MRN/MLN）的要求”，RFC 52122008年7月。
[RFC5339] Le Roux, JL., Ed., and D. Papadimitriou, Ed., "Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 5339, September 2008.
[RFC5339]Le Roux，JL.，Ed.，和D.Papadimitriou，Ed.，“针对多层和多区域网络（MLN/MRN）评估现有GMPLS协议”，RFC 5339，2008年9月。
[RFC5710] Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr Message Triggered MPLS and GMPLS LSP Reroutes", RFC 5710, January 2010.
[RFC5710]伯杰，L.，帕帕迪米特里奥，D.，和JP。Vasseur，“PathErr消息触发MPLS和GMPLS LSP重路由”，RFC 5710，2010年1月。
[RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", RFC 5817, April 2010.
[RFC5817]Ali，Z.，Vasseur，JP.，Zamfir，A.，和J.Newton，“MPLS和广义MPLS流量工程网络中的优雅关机”，RFC 58172010年4月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
Acknowledgments
致谢
The authors would like to thank Mr. Wataru Imajuku for the discussions on adjustment between regions.
作者谨感谢Wataru Imajuku先生就区域间调整问题进行的讨论。
Contributors
贡献者
Eiji Oki University of Electro-Communications 1-5-1 Chofugaoka Chofu, Tokyo 182-8585, Japan EMail: oki@ice.uec.ac.jp
爱智大学电子通信大学1-5-1 CHOUUGAKA CHOFU，东京182-85 85，日本电邮：oki@ice.uec.ac.jp
Ichiro Inoue NTT Network Service Systems Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585, Japan Phone: +81 422 596076 EMail: ichiro.inoue@lab.ntt.co.jp
井上一郎NTT网络服务系统实验室3-9-11 Midori cho Musashino shi，东京180-8585，日本电话：+81 422 596076电子邮件：Ichiro。inoue@lab.ntt.co.jp
Emmanuel Dotaro Alcatel-Lucent France Route de Villejust 91620 Nozay, France Phone: +33 1 69634723 EMail: emmanuel.dotaro@alcatel-lucent.fr
Emmanuel Dotaro Alcatel-Lucent法国维勒赫斯特路线91620法国诺扎伊电话：+33 1 69634723电子邮件：Emmanuel。dotaro@alcatel-朗讯
Gert Grammel Alcatel-Lucent SEL Lorenzstrasse, 10 70435 Stuttgart, Germany EMail: gert.grammel@alcatel-lucent.de
Gert Grammel Alcatel Lucent SEL Lorenzstrasse，10 70435斯图加特，德国电子邮件：Gert。grammel@alcatel-朗讯
Authors' Addresses
作者地址
Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel-lucent.com
Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan 50 B-2018比利时安特卫普电话：+32 3 2408491电子邮件：Dimitri。papadimitriou@alcatel-朗讯网
Martin Vigoureux Alcatel-Lucent Route de Villejust 91620 Nozay, France Phone: +33 1 30772669 EMail: martin.vigoureux@alcatel-lucent.fr
Martin Vigoureux Alcatel-Lucent Route de Villejust 91620 Nozay，法国电话：+33 1 30772669电子邮件：Martin。vigoureux@alcatel-朗讯
Kohei Shiomoto NTT 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585, Japan Phone: +81 422 594402 EMail: shiomoto.kohei@lab.ntt.co.jp
Kohei Shiomoto NTT 3-9-11 Midori cho Musashino shi，东京180-8585，日本电话：+81 422 594402电子邮件：Shiomoto。kohei@lab.ntt.co.jp
Deborah Brungard ATT Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 4201573 EMail: dbrungard@att.com
黛博拉·布伦加德，电话号码。D1-3C22-200美国新泽西州米德尔顿南劳雷尔大道07748号电话：+1732 4201573电子邮件：dbrungard@att.com
Jean-Louis Le Roux France Telecom Avenue Pierre Marzin 22300 Lannion, France Phone: +33 2 96053020 EMail: jean-louis.leroux@rd.francetelecom.com
Jean-Louis Le Roux法国电信大道Pierre Marzin 22300法国拉尼翁电话：+33 2 96053020电子邮件：Jean-Louis。leroux@rd.francetelecom.com