Network Working Group E. Mannie, Ed.
Request for Comments: 3945 October 2004
Category: Standards Track
Network Working Group E. Mannie, Ed.
Request for Comments: 3945 October 2004
Category: Standards Track
Generalized Multi-Protocol Label Switching (GMPLS) Architecture
通用多协议标签交换（GMPLS）体系结构
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.
未来的数据和传输网络将由路由器、交换机、密集波分复用（DWDM）系统、分插复用器（ADM）、光子交叉连接（PXC）、光学交叉连接（OXC）等元件组成，这些元件将使用通用多协议标签交换（GMPLS）使用保护和恢复技术动态提供资源并提供网络生存能力。
This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane.
本文档描述了GMPLS的体系结构。GMPLS将MPLS扩展到包括时分（例如SONET/SDH、PDH、g.709）、波长（lambdas）和空间交换（例如，输入端口或光纤到输出端口或光纤）。GMPLS的重点是这些不同层的控制平面，因为每个层都可以使用物理上不同的数据或转发平面。目的是覆盖该控制平面的信令和路由部分。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acronyms & Abbreviations. . . . . . . . . . . . . . . . 4
1.2. Multiple Types of Switching and Forwarding Hierarchies. 5
1.3. Extension of the MPLS Control Plane . . . . . . . . . . 7
1.4. GMPLS Key Extensions to MPLS-TE . . . . . . . . . . . . 10
2. Routing and Addressing Model. . . . . . . . . . . . . . . . . 11
2.1. Addressing of PSC and non-PSC layers. . . . . . . . . . 13
2.2. GMPLS Scalability Enhancements. . . . . . . . . . . . . 13
2.3. TE Extensions to IP Routing Protocols . . . . . . . . . 14
3. Unnumbered Links. . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Unnumbered Forwarding Adjacencies . . . . . . . . . . . 16
4. Link Bundling . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Restrictions on Bundling. . . . . . . . . . . . . . . . 17
4.2. Routing Considerations for Bundling . . . . . . . . . . 17
4.3. Signaling Considerations. . . . . . . . . . . . . . . . 18
4.3.1. Mechanism 1: Implicit Indication. . . . . . . . 18
4.3.2. Mechanism 2: Explicit Indication by Numbered
Interface ID. . . . . . . . . . . . . . . . . . 19
4.3.3. Mechanism 3: Explicit Indication by Unnumbered
Interface ID. . . . . . . . . . . . . . . . . . 19
4.4. Unnumbered Bundled Link . . . . . . . . . . . . . . . . 19
4.5. Forming Bundled Links . . . . . . . . . . . . . . . . . 20
5. Relationship with the UNI . . . . . . . . . . . . . . . . . . 20
5.1. Relationship with the OIF UNI . . . . . . . . . . . . . 21
5.2. Reachability across the UNI . . . . . . . . . . . . . . 21
6. Link Management . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Control Channel and Control Channel Management. . . . . 23
6.2. Link Property Correlation . . . . . . . . . . . . . . . 24
6.3. Link Connectivity Verification. . . . . . . . . . . . . 24
6.4. Fault Management. . . . . . . . . . . . . . . . . . . . 25
6.5. LMP for DWDM Optical Line Systems (OLSs). . . . . . . . 26
7. Generalized Signaling . . . . . . . . . . . . . . . . . . . . 27
7.1. Overview: How to Request an LSP . . . . . . . . . . . . 29
7.2. Generalized Label Request . . . . . . . . . . . . . . . 30
7.3. SONET/SDH Traffic Parameters. . . . . . . . . . . . . . 31
7.4. G.709 Traffic Parameters. . . . . . . . . . . . . . . . 32
7.5. Bandwidth Encoding. . . . . . . . . . . . . . . . . . . 33
7.6. Generalized Label . . . . . . . . . . . . . . . . . . . 34
7.7. Waveband Switching. . . . . . . . . . . . . . . . . . . 34
7.8. Label Suggestion by the Upstream. . . . . . . . . . . . 35
7.9. Label Restriction by the Upstream . . . . . . . . . . . 35
7.10. Bi-directional LSP. . . . . . . . . . . . . . . . . . . 36
7.11. Bi-directional LSP Contention Resolution. . . . . . . . 37
7.12. Rapid Notification of Failure . . . . . . . . . . . . . 37
7.13. Link Protection . . . . . . . . . . . . . . . . . . . . 38
7.14. Explicit Routing and Explicit Label Control . . . . . . 39
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acronyms & Abbreviations. . . . . . . . . . . . . . . . 4
1.2. Multiple Types of Switching and Forwarding Hierarchies. 5
1.3. Extension of the MPLS Control Plane . . . . . . . . . . 7
1.4. GMPLS Key Extensions to MPLS-TE . . . . . . . . . . . . 10
2. Routing and Addressing Model. . . . . . . . . . . . . . . . . 11
2.1. Addressing of PSC and non-PSC layers. . . . . . . . . . 13
2.2. GMPLS Scalability Enhancements. . . . . . . . . . . . . 13
2.3. TE Extensions to IP Routing Protocols . . . . . . . . . 14
3. Unnumbered Links. . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Unnumbered Forwarding Adjacencies . . . . . . . . . . . 16
4. Link Bundling . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Restrictions on Bundling. . . . . . . . . . . . . . . . 17
4.2. Routing Considerations for Bundling . . . . . . . . . . 17
4.3. Signaling Considerations. . . . . . . . . . . . . . . . 18
4.3.1. Mechanism 1: Implicit Indication. . . . . . . . 18
4.3.2. Mechanism 2: Explicit Indication by Numbered
Interface ID. . . . . . . . . . . . . . . . . . 19
4.3.3. Mechanism 3: Explicit Indication by Unnumbered
Interface ID. . . . . . . . . . . . . . . . . . 19
4.4. Unnumbered Bundled Link . . . . . . . . . . . . . . . . 19
4.5. Forming Bundled Links . . . . . . . . . . . . . . . . . 20
5. Relationship with the UNI . . . . . . . . . . . . . . . . . . 20
5.1. Relationship with the OIF UNI . . . . . . . . . . . . . 21
5.2. Reachability across the UNI . . . . . . . . . . . . . . 21
6. Link Management . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Control Channel and Control Channel Management. . . . . 23
6.2. Link Property Correlation . . . . . . . . . . . . . . . 24
6.3. Link Connectivity Verification. . . . . . . . . . . . . 24
6.4. Fault Management. . . . . . . . . . . . . . . . . . . . 25
6.5. LMP for DWDM Optical Line Systems (OLSs). . . . . . . . 26
7. Generalized Signaling . . . . . . . . . . . . . . . . . . . . 27
7.1. Overview: How to Request an LSP . . . . . . . . . . . . 29
7.2. Generalized Label Request . . . . . . . . . . . . . . . 30
7.3. SONET/SDH Traffic Parameters. . . . . . . . . . . . . . 31
7.4. G.709 Traffic Parameters. . . . . . . . . . . . . . . . 32
7.5. Bandwidth Encoding. . . . . . . . . . . . . . . . . . . 33
7.6. Generalized Label . . . . . . . . . . . . . . . . . . . 34
7.7. Waveband Switching. . . . . . . . . . . . . . . . . . . 34
7.8. Label Suggestion by the Upstream. . . . . . . . . . . . 35
7.9. Label Restriction by the Upstream . . . . . . . . . . . 35
7.10. Bi-directional LSP. . . . . . . . . . . . . . . . . . . 36
7.11. Bi-directional LSP Contention Resolution. . . . . . . . 37
7.12. Rapid Notification of Failure . . . . . . . . . . . . . 37
7.13. Link Protection . . . . . . . . . . . . . . . . . . . . 38
7.14. Explicit Routing and Explicit Label Control . . . . . . 39
7.15. Route Recording . . . . . . . . . . . . . . . . . . . . 40
7.16. LSP Modification and LSP Re-routing . . . . . . . . . . 40
7.17. LSP Administrative Status Handling. . . . . . . . . . . 41
7.18. Control Channel Separation. . . . . . . . . . . . . . . 42
8. Forwarding Adjacencies (FA) . . . . . . . . . . . . . . . . . 43
8.1. Routing and Forwarding Adjacencies. . . . . . . . . . . 43
8.2. Signaling Aspects . . . . . . . . . . . . . . . . . . . 44
8.3. Cascading of Forwarding Adjacencies . . . . . . . . . . 44
9. Routing and Signaling Adjacencies . . . . . . . . . . . . . . 45
10. Control Plane Fault Handling. . . . . . . . . . . . . . . . . 46
11. LSP Protection and Restoration. . . . . . . . . . . . . . . . 47
11.1. Protection Escalation across Domains and Layers . . . . 48
11.2. Mapping of Services to P&R Resources. . . . . . . . . . 49
11.3. Classification of P&R Mechanism Characteristics . . . . 49
11.4. Different Stages in P&R . . . . . . . . . . . . . . . . 50
11.5. Recovery Strategies . . . . . . . . . . . . . . . . . . 50
11.6. Recovery mechanisms: Protection schemes . . . . . . . . 51
11.7. Recovery mechanisms: Restoration schemes. . . . . . . . 52
11.8. Schema Selection Criteria . . . . . . . . . . . . . . . 53
12. Network Management. . . . . . . . . . . . . . . . . . . . . . 54
12.1. Network Management Systems (NMS). . . . . . . . . . . . 55
12.2. Management Information Base (MIB) . . . . . . . . . . . 55
12.3. Tools . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.4. Fault Correlation Between Multiple Layers . . . . . . . 56
13. Security Considerations . . . . . . . . . . . . . . . . . . . 57
14. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
15. References. . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.1. Normative References. . . . . . . . . . . . . . . . . . 58
15.2. Informative References. . . . . . . . . . . . . . . . . 59
16. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 63
17. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 68
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 69
7.15. Route Recording . . . . . . . . . . . . . . . . . . . . 40
7.16. LSP Modification and LSP Re-routing . . . . . . . . . . 40
7.17. LSP Administrative Status Handling. . . . . . . . . . . 41
7.18. Control Channel Separation. . . . . . . . . . . . . . . 42
8. Forwarding Adjacencies (FA) . . . . . . . . . . . . . . . . . 43
8.1. Routing and Forwarding Adjacencies. . . . . . . . . . . 43
8.2. Signaling Aspects . . . . . . . . . . . . . . . . . . . 44
8.3. Cascading of Forwarding Adjacencies . . . . . . . . . . 44
9. Routing and Signaling Adjacencies . . . . . . . . . . . . . . 45
10. Control Plane Fault Handling. . . . . . . . . . . . . . . . . 46
11. LSP Protection and Restoration. . . . . . . . . . . . . . . . 47
11.1. Protection Escalation across Domains and Layers . . . . 48
11.2. Mapping of Services to P&R Resources. . . . . . . . . . 49
11.3. Classification of P&R Mechanism Characteristics . . . . 49
11.4. Different Stages in P&R . . . . . . . . . . . . . . . . 50
11.5. Recovery Strategies . . . . . . . . . . . . . . . . . . 50
11.6. Recovery mechanisms: Protection schemes . . . . . . . . 51
11.7. Recovery mechanisms: Restoration schemes. . . . . . . . 52
11.8. Schema Selection Criteria . . . . . . . . . . . . . . . 53
12. Network Management. . . . . . . . . . . . . . . . . . . . . . 54
12.1. Network Management Systems (NMS). . . . . . . . . . . . 55
12.2. Management Information Base (MIB) . . . . . . . . . . . 55
12.3. Tools . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.4. Fault Correlation Between Multiple Layers . . . . . . . 56
13. Security Considerations . . . . . . . . . . . . . . . . . . . 57
14. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
15. References. . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.1. Normative References. . . . . . . . . . . . . . . . . . 58
15.2. Informative References. . . . . . . . . . . . . . . . . 59
16. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 63
17. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 68
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 69
The architecture described in this document covers the main building blocks needed to build a consistent control plane for multiple switching layers. It does not restrict the way that these layers work together. Different models can be applied, e.g., overlay, augmented or integrated. Moreover, each pair of contiguous layers may collaborate in different ways, resulting in a number of possible combinations, at the discretion of manufacturers and operators.
本文档中描述的体系结构涵盖了为多个交换层构建一致控制平面所需的主要构建块。它不限制这些层一起工作的方式。可以应用不同的模型，例如叠加、增强或集成。此外，制造商和运营商可自行决定每对相邻层以不同方式协作，从而产生许多可能的组合。
This architecture clearly separates the control plane and the forwarding plane. In addition, it also clearly separates the control plane in two parts, the signaling plane containing the signaling protocols and the routing plane containing the routing protocols.
该体系结构清楚地将控制平面和转发平面分开。此外，它还将控制平面清楚地分为两部分，包含信令协议的信令平面和包含路由协议的路由平面。
This document is a generalization of the Multi-Protocol Label Switching (MPLS) architecture [RFC3031], and in some cases may differ slightly from that architecture since non packet-based forwarding planes are now considered. It is not the intention of this document to describe concepts already described in the current MPLS architecture. The goal is to describe specific concepts of Generalized MPLS (GMPLS).
本文档是多协议标签交换（MPLS）体系结构[RFC3031]的概括，在某些情况下可能与该体系结构略有不同，因为现在考虑了非基于分组的转发平面。本文档无意描述当前MPLS体系结构中已经描述的概念。目的是描述广义MPLS（GMPLS）的具体概念。
However, some of the concepts explained hereafter are not part of the current MPLS architecture and are applicable to both MPLS and GMPLS (i.e., link bundling, unnumbered links, and LSP hierarchy). Since these concepts were introduced together with GMPLS and since they are of paramount importance for an operational GMPLS network, they will be discussed here.
然而，下文解释的一些概念不是当前MPLS体系结构的一部分，并且适用于MPLS和GMPLS（即链路捆绑、无编号链路和LSP层次结构）。由于这些概念是与GMPLS一起介绍的，并且它们对于运行的GMPLS网络至关重要，因此将在这里讨论这些概念。
The organization of the remainder of this document is as follows. We begin with an introduction of GMPLS. We then present the specific GMPLS building blocks and explain how they can be combined together to build an operational GMPLS network. Specific details of the separate building blocks can be found in the corresponding documents.
本文件其余部分的组织结构如下。我们首先介绍GMPLS。然后，我们介绍具体的GMPLS构建块，并解释如何将它们组合在一起以构建可操作的GMPLS网络。单独构建块的具体细节可在相应文件中找到。
AS Autonomous System BGP Border Gateway Protocol CR-LDP Constraint-based Routing LDP CSPF Constraint-based Shortest Path First DWDM Dense Wavelength Division Multiplexing FA Forwarding Adjacency GMPLS Generalized Multi-Protocol Label Switching IGP Interior Gateway Protocol LDP Label Distribution Protocol LMP Link Management Protocol
AS自治系统BGP边界网关协议CR-LDP约束路由LDP CSPF约束最短路径优先DWDM密集波分复用FA转发邻接GMPLS广义多协议标签交换IGP内部网关协议LDP标签分配协议LMP链路管理协议
LSA Link State Advertisement LSR Label Switching Router LSP Label Switched Path MIB Management Information Base MPLS Multi-Protocol Label Switching NMS Network Management System OXC Optical Cross-Connect PXC Photonic Cross-Connect RSVP ReSource reserVation Protocol SDH Synchronous Digital Hierarchy SONET Synchronous Optical Networks STM(-N) Synchronous Transport Module (-N) STS(-N) Synchronous Transport Signal-Level N (SONET) TDM Time Division Multiplexing TE Traffic Engineering
LSA链路状态播发LSR标签交换路由器LSP标签交换路径MIB管理信息库MPLS多协议标签交换NMS网络管理系统OXC光交叉连接PXC光交叉连接RSVP资源预留协议SDH同步数字体系SONET同步光网络STM（-N）同步传输模块（-N）STS（-N）同步传输信号电平N（SONET）TDM时分复用TE业务工程
Generalized MPLS (GMPLS) differs from traditional MPLS in that it supports multiple types of switching, i.e., the addition of support for TDM, lambda, and fiber (port) switching. The support for the additional types of switching has driven GMPLS to extend certain base functions of traditional MPLS and, in some cases, to add functionality. These changes and additions impact basic LSP properties: how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress LSRs.
广义MPLS（GMPLS）与传统MPLS的不同之处在于它支持多种类型的交换，即增加了对TDM、lambda和光纤（端口）交换的支持。对附加交换类型的支持促使GMPLS扩展了传统MPLS的某些基本功能，并在某些情况下增加了功能。这些更改和添加影响基本LSP属性：标签的请求和通信方式、LSP的单向性、错误的传播方式以及为同步入口和出口LSR提供的信息。
The MPLS architecture [RFC3031] was defined to support the forwarding of data based on a label. In this architecture, Label Switching Routers (LSRs) were assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers (for LSRs capable of recognizing packet boundaries) or cell headers (for LSRs capable of recognizing cell boundaries).
MPLS体系结构[RFC3031]被定义为支持基于标签的数据转发。在该架构中，假设标签交换路由器（lsr）具有能够（a）识别分组或小区边界的转发平面，以及（b）能够处理分组报头（对于能够识别分组边界的lsr）或小区报头（对于能够识别小区边界的lsr）。
The original MPLS architecture is here being extended to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, cannot forward data based on the information carried in either packet or cell headers. Specifically, such LSRs include devices where the switching decision is based on time slots, wavelengths, or physical ports. So, the new set of LSRs, or more precisely interfaces on these LSRs, can be subdivided into the following classes:
原始MPLS架构在此被扩展以包括lsr，其转发平面既不识别分组也不识别小区边界，因此不能基于分组或小区报头中携带的信息转发数据。具体地说，此类lsr包括切换决策基于时隙、波长或物理端口的设备。因此，新的一组LSR，或者更准确地说，这些LSR上的接口可以细分为以下几类：
1. Packet Switch Capable (PSC) interfaces:
1. 支持分组交换（PSC）的接口：
Interfaces that recognize packet boundaries and can forward data based on the content of the packet header. Examples include interfaces on routers that forward data based on the content of the IP header and interfaces on routers that switch data based on the content of the MPLS "shim" header.
识别数据包边界并可根据数据包头的内容转发数据的接口。示例包括基于IP报头内容转发数据的路由器上的接口和基于MPLS“shim”报头内容交换数据的路由器上的接口。
2. Layer-2 Switch Capable (L2SC) interfaces:
2. 第2层交换机功能（L2SC）接口：
Interfaces that recognize frame/cell boundaries and can switch data based on the content of the frame/cell header. Examples include interfaces on Ethernet bridges that switch data based on the content of the MAC header and interfaces on ATM-LSRs that forward data based on the ATM VPI/VCI.
识别帧/单元格边界并可根据帧/单元格标题内容切换数据的接口。示例包括以太网网桥上基于MAC报头内容交换数据的接口和ATM LSR上基于ATM VPI/VCI转发数据的接口。
3. Time-Division Multiplex Capable (TDM) interfaces:
3. 支持时分多路复用（TDM）的接口：
Interfaces that switch data based on the data's time slot in a repeating cycle. An example of such an interface is that of a SONET/SDH Cross-Connect (XC), Terminal Multiplexer (TM), or Add-Drop Multiplexer (ADM). Other examples include interfaces providing G.709 TDM capabilities (the "digital wrapper") and PDH interfaces.
根据重复周期中数据的时隙切换数据的接口。这种接口的一个例子是SONET/SDH交叉连接（XC）、终端多路复用器（TM）或分插多路复用器（ADM）。其他示例包括提供G.709 TDM功能的接口（“数字包装器”）和PDH接口。
4. Lambda Switch Capable (LSC) interfaces:
4. 支持Lambda交换机（LSC）的接口：
Interfaces that switch data based on the wavelength on which the data is received. An example of such an interface is that of a Photonic Cross-Connect (PXC) or Optical Cross-Connect (OXC) that can operate at the level of an individual wavelength. Additional examples include PXC interfaces that can operate at the level of a group of wavelengths, i.e., a waveband and G.709 interfaces providing optical capabilities.
根据接收数据的波长切换数据的接口。这种接口的一个例子是光子交叉连接（PXC）或光学交叉连接（OXC），其可以在单个波长的水平上工作。其他示例包括可在一组波长（即波段）水平上运行的PXC接口和提供光学功能的G.709接口。
5. Fiber-Switch Capable (FSC) interfaces:
5. 支持光纤交换机（FSC）的接口：
Interfaces that switch data based on a position of the data in the (real world) physical spaces. An example of such an interface is that of a PXC or OXC that can operate at the level of a single or multiple fibers.
根据数据在（真实世界）物理空间中的位置切换数据的接口。这种接口的一个例子是PXC或OXC接口，它可以在单个或多个光纤的级别上运行。
A circuit can be established only between, or through, interfaces of the same type. Depending on the particular technology being used for each interface, different circuit names can be used, e.g., SDH circuit, optical trail, light-path, etc. In the context of GMPLS, all these circuits are referenced by a common name: Label Switched Path (LSP).
只能在相同类型的接口之间或通过相同类型的接口建立电路。根据每个接口使用的特定技术，可以使用不同的电路名称，例如SDH电路、光路、光路等。在GMPLS的上下文中，所有这些电路都由一个通用名称引用：标签交换路径（LSP）。
The concept of nested LSP (LSP within LSP), already available in the traditional MPLS, facilitates building a forwarding hierarchy, i.e., a hierarchy of LSPs. This hierarchy of LSPs can occur on the same interface, or between different interfaces.
传统MPLS中已有的嵌套LSP（LSP中的LSP）概念有助于构建转发层次结构，即LSP层次结构。LSP的这种层次结构可以发生在同一接口上，也可以发生在不同接口之间。
For example, a hierarchy can be built if an interface is capable of multiplexing several LSPs from the same technology (layer), e.g., a lower order SONET/SDH LSP (e.g., VT2/VC-12) nested in a higher order SONET/SDH LSP (e.g., STS-3c/VC-4). Several levels of signal (LSP) nesting are defined in the SONET/SDH multiplexing hierarchy.
例如，如果接口能够复用来自同一技术（层）的多个LSP，例如嵌套在高阶SONET/SDH LSP（例如STS-3c/VC-4）中的低阶SONET/SDH LSP（例如VT2/VC-12），则可以建立层次结构。SONET/SDH多路复用层次结构中定义了几种级别的信号（LSP）嵌套。
The nesting can also occur between interface types. At the top of the hierarchy are FSC interfaces, followed by LSC interfaces, followed by TDM interfaces, followed by L2SC, and followed by PSC interfaces. This way, an LSP that starts and ends on a PSC interface can be nested (together with other LSPs) into an LSP that starts and ends on a L2SC interface. This LSP, in turn, can be nested (together with other LSPs) into an LSP that starts and ends on a TDM interface. In turn, this LSP can be nested (together with other LSPs) into an LSP that starts and ends on a LSC interface, which in turn can be nested (together with other LSPs) into an LSP that starts and ends on a FSC interface.
嵌套也可以发生在接口类型之间。在层次结构的顶部是FSC接口，接着是LSC接口，接着是TDM接口，接着是L2SC，接着是PSC接口。这样，可以将在PSC接口上开始和结束的LSP（与其他LSP一起）嵌套到在L2SC接口上开始和结束的LSP中。反过来，该LSP可以（与其他LSP一起）嵌套到在TDM接口上开始和结束的LSP中。反过来，此LSP可以（与其他LSP一起）嵌套到LSC接口上开始和结束的LSP中，而LSP又可以（与其他LSP一起）嵌套到FSC接口上开始和结束的LSP中。
The establishment of LSPs that span only Packet Switch Capable (PSC) or Layer-2 Switch Capable (L2SC) interfaces is defined for the original MPLS and/or MPLS-TE control planes. GMPLS extends these control planes to support each of the five classes of interfaces (i.e., layers) defined in the previous section.
为原始MPLS和/或MPLS-TE控制平面定义了仅跨支持分组交换（PSC）或支持第二层交换（L2SC）接口的LSP的建立。GMPLS扩展了这些控制平面，以支持上一节中定义的五类接口（即层）中的每一类。
Note that the GMPLS control plane supports an overlay model, an augmented model, and a peer (integrated) model. In the near term, GMPLS appears to be very suitable for controlling each layer independently. This elegant approach will facilitate the future deployment of other models.
请注意，GMPLS控制平面支持覆盖模型、增强模型和对等（集成）模型。在短期内，GMPLS似乎非常适合独立控制每一层。这种优雅的方法将促进其他模型的未来部署。
The GMPLS control plane is made of several building blocks as described in more details in the following sections. These building blocks are based on well-known signaling and routing protocols that have been extended and/or modified to support GMPLS. They use IPv4 and/or IPv6 addresses. Only one new specialized protocol is required to support the operations of GMPLS, a signaling protocol for link management [LMP].
GMPLS控制平面由多个构建块组成，详见以下章节。这些构建块基于众所周知的信令和路由协议，这些协议已被扩展和/或修改以支持GMPLS。它们使用IPv4和/或IPv6地址。只需要一个新的专用协议来支持GMPLS的操作，GMPLS是一种用于链路管理[LMP]的信令协议。
GMPLS is indeed based on the Traffic Engineering (TE) extensions to MPLS, a.k.a. MPLS-TE [RFC2702]. This, because most of the technologies that can be used below the PSC level requires some
GMPLS确实基于MPLS的流量工程（TE）扩展，也称为MPLS-TE[RFC2702]。这是因为大多数可在PSC级别以下使用的技术都需要一些
traffic engineering. The placement of LSPs at these levels needs in general to consider several constraints (such as framing, bandwidth, protection capability, etc) and to bypass the legacy Shortest-Path First (SPF) algorithm. Note, however, that this is not mandatory and that in some cases SPF routing can be applied.
交通工程。在这些级别上放置LSP一般需要考虑几个约束（如帧、带宽、保护能力等），并绕过传统最短路径优先（SPF）算法。但是，请注意，这不是强制性的，在某些情况下，可以应用SPF路由。
In order to facilitate constrained-based SPF routing of LSPs, nodes that perform LSP establishment need more information about the links in the network than standard intra-domain routing protocols provide. These TE attributes are distributed using the transport mechanisms already available in IGPs (e.g., flooding) and taken into consideration by the LSP routing algorithm. Optimization of the LSP routes may also require some external simulations using heuristics that serve as input for the actual path calculation and LSP establishment process.
为了促进LSP的基于约束的SPF路由，执行LSP建立的节点需要比标准域内路由协议提供的更多关于网络中链路的信息。这些TE属性使用IGP中已有的传输机制（例如，泛洪）进行分布，并由LSP路由算法加以考虑。LSP路线的优化可能还需要一些使用启发式的外部模拟，作为实际路径计算和LSP建立过程的输入。
By definition, a TE link is a representation in the IS-IS/OSPF Link State advertisements and in the link state database of certain physical resources, and their properties, between two GMPLS nodes. TE Links are used by the GMPLS control plane (routing and signaling) for establishing LSPs.
根据定义，TE链路是两个GMPLS节点之间的is-is/OSPF链路状态公告和特定物理资源及其属性的链路状态数据库中的表示。TE链路由GMPLS控制平面（路由和信令）用于建立LSP。
Extensions to traditional routing protocols and algorithms are needed to uniformly encode and carry TE link information, and explicit routes (e.g., source routes) are required in the signaling. In addition, the signaling must now be capable of transporting the required circuit (LSP) parameters such as the bandwidth, the type of signal, the desired protection and/or restoration, the position in a particular multiplex, etc. Most of these extensions have already been defined for PSC and L2SC traffic engineering with MPLS. GMPLS primarily defines additional extensions for TDM, LSC, and FSC traffic engineering. A very few elements are technology specific.
需要对传统路由协议和算法进行扩展，以统一编码和携带TE链路信息，并且在信令中需要显式路由（例如，源路由）。此外，信令现在必须能够传输所需的电路（LSP）参数，例如带宽、信号类型、所需的保护和/或恢复、在特定多路复用中的位置等。这些扩展中的大多数已经为具有MPLS的PSC和L2SC流量工程定义。GMPLS主要定义TDM、LSC和FSC流量工程的附加扩展。只有极少数元素是特定于技术的。
Thus, GMPLS extends the two signaling protocols defined for MPLS-TE signaling, i.e., RSVP-TE [RFC3209] and CR-LDP [RFC3212]. However, GMPLS does not specify which one of these two signaling protocols must be used. It is the role of manufacturers and operators to evaluate the two possible solutions for their own interest.
因此，GMPLS扩展了为MPLS-TE信令定义的两个信令协议，即RSVP-TE[RFC3209]和CR-LDP[RFC3212]。但是，GMPLS没有指定必须使用这两种信令协议中的哪一种。制造商和运营商应根据自身利益评估两种可能的解决方案。
Since GMPLS signaling is based on RSVP-TE and CR-LDP, it mandates a downstream-on-demand label allocation and distribution, with ingress initiated ordered control. Liberal label retention is normally used, but conservative label retention mode could also be used.
由于GMPLS信令基于RSVP-TE和CR-LDP，它要求下游按需标签分配和分发，并由入口发起有序控制。通常使用自由标签保留，但也可以使用保守标签保留模式。
Furthermore, there is no restriction on the label allocation strategy, it can be request/signaling driven (obvious for circuit switching technologies), traffic/data driven, or even topology driven. There is also no restriction on the route selection; explicit routing is normally used (strict or loose) but hop-by-hop routing could be used as well.
此外，标签分配策略没有限制，它可以是请求/信令驱动的（对于电路交换技术来说很明显）、流量/数据驱动的，甚至是拓扑驱动的。路线选择也没有限制；通常使用显式路由（严格或松散），但也可以使用逐跳路由。
GMPLS also extends two traditional intra-domain link-state routing protocols already extended for TE purposes, i.e., OSPF-TE [OSPF-TE] and IS-IS-TE [ISIS-TE]. However, if explicit (source) routing is used, the routing algorithms used by these protocols no longer need to be standardized. Extensions for inter-domain routing (e.g., BGP) are for further study.
GMPLS还扩展了两个已经扩展用于TE目的的传统域内链路状态路由协议，即OSPF-TE[OSPF-TE]和IS-IS-TE[ISIS-TE]。但是，如果使用显式（源）路由，则这些协议使用的路由算法不再需要标准化。域间路由（如BGP）的扩展有待进一步研究。
The use of technologies like DWDM (Dense Wavelength Division Multiplexing) implies that we can now have a very large number of parallel links between two directly adjacent nodes (hundreds of wavelengths, or even thousands of wavelengths if multiple fibers are used). Such a large number of links was not originally considered for an IP or MPLS control plane, although it could be done. Some slight adaptations of that control plane are thus required if we want to better reuse it in the GMPLS context.
使用DWDM（密集波分复用）等技术意味着我们现在可以在两个直接相邻的节点之间拥有大量并行链路（数百个波长，如果使用多个光纤，甚至数千个波长）。IP或MPLS控制平面最初并不考虑如此大量的链路，尽管这是可以做到的。因此，如果我们想在GMPLS上下文中更好地重用它，就需要对该控制平面进行一些轻微的修改。
For instance, the traditional IP routing model assumes the establishment of a routing adjacency over each link connecting two adjacent nodes. Having such a large number of adjacencies does not scale well. Each node needs to maintain each of its adjacencies one by one, and link state routing information must be flooded throughout the network.
例如，传统的IP路由模型假设在连接两个相邻节点的每个链路上建立路由邻接。拥有如此多的邻接关系并不能很好地扩展。每个节点都需要一个接一个地维护其每个邻接，链路状态路由信息必须遍布整个网络。
To solve this issue the concept of link bundling was introduced. Moreover, the manual configuration and control of these links, even if they are unnumbered, becomes impractical. The Link Management Protocol (LMP) was specified to solve these issues.
为了解决这个问题，引入了链路捆绑的概念。此外，手动配置和控制这些链路，即使它们没有编号，也变得不切实际。链路管理协议（LMP）被指定用来解决这些问题。
LMP runs between data plane adjacent nodes and is used to manage TE links. Specifically, LMP provides mechanisms to maintain control channel connectivity (IP Control Channel Maintenance), verify the physical connectivity of the data-bearing links (Link Verification), correlate the link property information (Link Property Correlation), and manage link failures (Fault Localization and Fault Notification). A unique feature of LMP is that it is able to localize faults in both opaque and transparent networks (i.e., independent of the encoding scheme and bit rate used for the data).
LMP在数据平面相邻节点之间运行，用于管理TE链路。具体而言，LMP提供了维护控制信道连接（IP控制信道维护）、验证数据承载链路的物理连接（链路验证）、关联链路属性信息（链路属性关联）和管理链路故障（故障定位和故障通知）的机制。LMP的一个独特特性是，它能够在不透明和透明网络中定位故障（即，独立于用于数据的编码方案和比特率）。
LMP is defined in the context of GMPLS, but is specified independently of the GMPLS signaling specification since it is a local protocol running between data-plane adjacent nodes.
LMP在GMPLS的上下文中定义，但独立于GMPLS信令规范指定，因为它是在数据平面相邻节点之间运行的本地协议。
Consequently, LMP can be used in other contexts with non-GMPLS signaling protocols.
因此，LMP可以在具有非GMPLS信令协议的其他上下文中使用。
MPLS signaling and routing protocols require at least one bi-directional control channel to communicate even if two adjacent nodes are connected by unidirectional links. Several control channels can be used. LMP can be used to establish, maintain and manage these control channels.
MPLS信令和路由协议需要至少一个双向控制信道来通信，即使两个相邻节点通过单向链路连接。可以使用多个控制通道。LMP可用于建立、维护和管理这些控制通道。
GMPLS does not specify how these control channels must be implemented, but GMPLS requires IP to transport the signaling and routing protocols over them. Control channels can be either in-band or out-of-band, and several solutions can be used to carry IP. Note also that one type of LMP message (the Test message) is used in-band in the data plane and may not be transported over IP, but this is a particular case, needed to verify connectivity in the data plane.
GMPLS没有规定必须如何实现这些控制信道，但GMPLS要求IP通过它们传输信令和路由协议。控制通道可以是带内或带外，并且可以使用几种解决方案来承载IP。还请注意，一种类型的LMP消息（测试消息）在数据平面的频带中使用，并且可能不会通过IP传输，但这是一种特殊情况，需要验证数据平面中的连接性。
Some key extensions brought by GMPLS to MPLS-TE are highlighted in the following. Some of them are key advantages of GMPLS to control TDM, LSC and FSC layers.
GMPLS为MPLS-TE带来的一些关键扩展如下所示。其中一些是GMPLS控制TDM、LSC和FSC层的关键优势。
- In MPLS-TE, links traversed by an LSP can include an intermix of links with heterogeneous label encoding (e.g., links between routers, links between routers and ATM-LSRs, and links between ATM-LSRs. GMPLS extends this by including links where the label is encoded as a time slot, or a wavelength, or a position in the (real world) physical space.
- 在MPLS-TE中，LSP所穿越的链路可以包括具有异构标签编码的链路的混合（例如，路由器之间的链路、路由器和ATM LSR之间的链路以及ATM LSR之间的链路）。GMPLS通过包括将标签编码为时隙、波长或（真实世界）物理空间中的位置的链路来扩展这一点。
- In MPLS-TE, an LSP that carries IP has to start and end on a router. GMPLS extends this by requiring an LSP to start and end on similar type of interfaces.
- 在MPLS-TE中，承载IP的LSP必须在路由器上开始和结束。GMPLS通过要求LSP在类似类型的接口上开始和结束来扩展这一点。
- The type of a payload that can be carried in GMPLS by an LSP is extended to allow such payloads as SONET/SDH, G.709, 1Gb or 10Gb Ethernet, etc.
- LSP可以在GMPLS中承载的有效负载类型被扩展，以允许SONET/SDH、G.709、1Gb或10Gb以太网等有效负载。
- The use of Forwarding Adjacencies (FA) provides a mechanism that can improve bandwidth utilization, when bandwidth allocation can be performed only in discrete units. It offers also a mechanism to aggregate forwarding state, thus allowing the number of required labels to be reduced.
- 当带宽分配只能在离散单元中执行时，转发邻接（FA）的使用提供了一种可以提高带宽利用率的机制。它还提供了一种聚合转发状态的机制，从而允许减少所需标签的数量。
- GMPLS allows suggesting a label by an upstream node to reduce the setup latency. This suggestion may be overridden by a downstream node but in some cases, at the cost of higher LSP setup time.
- GMPLS允许上游节点建议标签，以减少设置延迟。此建议可能会被下游节点覆盖，但在某些情况下，以较高的LSP设置时间为代价。
- GMPLS extends on the notion of restricting the range of labels that may be selected by a downstream node. In GMPLS, an upstream node may restrict the labels for an LSP along either a single hop or the entire LSP path. This feature is useful in photonic networks where wavelength conversion may not be available.
- GMPLS扩展了限制下游节点可以选择的标签范围的概念。在GMPLS中，上游节点可以沿单个跳或整个LSP路径限制LSP的标签。此功能在波长转换可能不可用的光子网络中非常有用。
- While traditional TE-based (and even LDP-based) LSPs are unidirectional, GMPLS supports the establishment of bi-directional LSPs.
- 虽然传统的基于TE（甚至基于LDP）的LSP是单向的，但GMPLS支持建立双向LSP。
- GMPLS supports the termination of an LSP on a specific egress port, i.e., the port selection at the destination side.
- GMPLS支持在特定出口端口上终止LSP，即在目的地侧选择端口。
- GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid failure notification.
- 带有RSVP-TE的GMPLS支持特定于RSVP的快速故障通知机制。
Note also some other key differences between MPLS-TE and GMPLS:
还要注意MPLS-TE和GMPLS之间的一些其他关键区别：
- For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP can be performed only in discrete units.
- 对于TDM、LSC和FSC接口，LSP的带宽分配只能在离散单元中执行。
- It is expected to have (much) fewer labels on TDM, LSC or FSC links than on PSC or L2SC links, because the former are physical labels instead of logical labels.
- 预计TDM、LSC或FSC链路上的标签将（远）少于PSC或L2SC链路上的标签，因为前者是物理标签而不是逻辑标签。
GMPLS is based on the IP routing and addressing models. This assumes that IPv4 and/or IPv6 addresses are used to identify interfaces but also that traditional (distributed) IP routing protocols are reused. Indeed, the discovery of the topology and the resource state of all links in a routing domain is achieved via these routing protocols.
GMPLS基于IP路由和寻址模型。这假定IPv4和/或IPv6地址用于标识接口，但也假定重用传统（分布式）IP路由协议。实际上，通过这些路由协议可以发现路由域中所有链路的拓扑和资源状态。
Since control and data planes are de-coupled in GMPLS, control-plane neighbors (i.e., IGP-learnt neighbors) may not be data-plane neighbors. Hence, mechanisms like LMP are needed to associate TE links with neighboring nodes.
由于控制平面和数据平面在GMPLS中解耦，因此控制平面邻居（即IGP学习邻居）可能不是数据平面邻居。因此，需要像LMP这样的机制将TE链路与相邻节点相关联。
IP addresses are not used only to identify interfaces of IP hosts and routers, but more generally to identify any PSC and non-PSC interfaces. Similarly, IP routing protocols are used to find routes for IP datagrams with a SPF algorithm; they are also used to find routes for non-PSC circuits by using a CSPF algorithm.
IP地址不仅用于标识IP主机和路由器的接口，而且通常用于标识任何PSC和非PSC接口。类似地，IP路由协议使用SPF算法查找IP数据报的路由；通过使用CSPF算法，它们还可用于查找非PSC电路的路由。
However, some additional mechanisms are needed to increase the scalability of these models and to deal with specific traffic engineering requirements of non-PSC layers. These mechanisms will be introduced in the following.
然而，需要一些额外的机制来提高这些模型的可伸缩性，并处理非PSC层的特定流量工程需求。以下将介绍这些机制。
Re-using existing IP routing protocols allows for non-PSC layers taking advantage of all the valuable developments that took place since years for IP routing, in particular, in the context of intra-domain routing (link-state routing) and inter-domain routing (policy routing).
重新使用现有IP路由协议允许非PSC层利用多年来IP路由的所有有价值的发展，特别是在域内路由（链路状态路由）和域间路由（策略路由）的上下文中。
In an overlay model, each particular non-PSC layer can be seen as a set of Autonomous Systems (ASs) interconnected in an arbitrary way. Similarly to the traditional IP routing, each AS is managed by a single administrative authority. For instance, an AS can be an SONET/SDH network operated by a given carrier. The set of interconnected ASs can be viewed as SONET/SDH internetworks.
在叠加模型中，每个特定的非PSC层都可以看作是一组以任意方式互连的自治系统（ASs）。与传统的IP路由类似，每个AS都由一个管理机构管理。例如，AS可以是由给定载波操作的SONET/SDH网络。可将互连的ASs集视为SONET/SDH互联网络。
Exchange of routing information between ASs can be done via an inter-domain routing protocol like BGP-4. There is obviously a huge value of re-using well-known policy routing facilities provided by BGP in a non-PSC context. Extensions for BGP traffic engineering (BGP-TE) in the context of non-PSC layers are left for further study.
ASs之间的路由信息交换可以通过域间路由协议（如BGP-4）完成。显然，在非PSC上下文中重新使用BGP提供的著名策略路由工具具有巨大的价值。非PSC层背景下BGP流量工程（BGP-TE）的扩展有待进一步研究。
Each AS can be sub-divided in different routing domains, and each can run a different intra-domain routing protocol. In turn, each routing-domain can be divided in areas.
每个AS都可以分为不同的路由域，并且每个AS都可以运行不同的域内路由协议。反过来，每个路由域可以划分为多个区域。
A routing domain is made of GMPLS enabled nodes (i.e., a network device including a GMPLS entity). These nodes can be either edge nodes (i.e., hosts, ingress LSRs or egress LSRs), or internal LSRs. An example of non-PSC host is an SONET/SDH Terminal Multiplexer (TM). Another example is an SONET/SDH interface card within an IP router or ATM switch.
路由域由启用GMPLS的节点（即，包括GMPLS实体的网络设备）组成。这些节点可以是边缘节点（即主机、入口LSR或出口LSR）或内部LSR。非PSC主机的一个示例是SONET/SDH终端多路复用器（TM）。另一个例子是IP路由器或ATM交换机内的SONET/SDH接口卡。
Note that traffic engineering in the intra-domain requires the use of link-state routing protocols like OSPF or IS-IS.
请注意，域内的流量工程需要使用链路状态路由协议，如OSPF或IS-IS。
GMPLS defines extensions to these protocols. These extensions are needed to disseminate specific TDM, LSC and FSC static and dynamic characteristics related to nodes and links. The current focus is on
GMPLS定义了这些协议的扩展。需要这些扩展来传播与节点和链路相关的特定TDM、LSC和FSC静态和动态特性。目前的重点是
intra-area traffic engineering. However, inter-area traffic engineering is also under investigation.
区域内交通工程。然而，区域间交通工程也在调查中。
The fact that IPv4 and/or IPv6 addresses are used does not imply at all that they should be allocated in the same addressing space than public IPv4 and/or IPv6 addresses used for the Internet. Private IP addresses can be used if they do not require to be exchanged with any other operator; public IP addresses are otherwise required. Of course, if an integrated model is used, two layers could share the same addressing space. Finally, TE links may be "unnumbered" i.e., not have any IP addresses, in case IP addresses are not available, or the overhead of managing them is considered too high.
使用IPv4和/或IPv6地址并不意味着它们应分配在与Internet使用的公共IPv4和/或IPv6地址相同的寻址空间中。如果不需要与任何其他运营商交换，则可以使用专用IP地址；否则需要公共IP地址。当然，如果使用集成模型，两个层可以共享相同的寻址空间。最后，如果IP地址不可用，或者管理它们的开销被认为过高，TE链路可能是“未编号的”，即没有任何IP地址。
Note that there is a benefit of using public IPv4 and/or IPv6 Internet addresses for non-PSC layers if an integrated model with the IP layer is foreseen.
请注意，如果预见到与IP层集成的模型，则为非PSC层使用公共IPv4和/或IPv6 Internet地址会带来好处。
If we consider the scalability enhancements proposed in the next section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing spaces are both more than sufficient to accommodate any non-PSC layer. We can reasonably expect to have much less non-PSC devices (e.g., SONET/SDH nodes) than we have today IP hosts and routers.
如果我们考虑在下一节中提出的可扩展性增强，IPv4（32位）和IPv6（128位）寻址空间都足以容纳任何非PSC层。我们可以合理地预期，非PSC设备（例如SONET/SDH节点）比我们现在的IP主机和路由器少得多。
TDM, LSC and FSC layers introduce new constraints on the IP addressing and routing models since several hundreds of parallel physical links (e.g., wavelengths) can now connect two nodes. Most of the carriers already have today several tens of wavelengths per fiber between two nodes. New generation of DWDM systems will allow several hundreds of wavelengths per fiber.
TDM、LSC和FSC层对IP寻址和路由模型引入了新的约束，因为数百条并行物理链路（例如波长）现在可以连接两个节点。如今，大多数运营商在两个节点之间的每根光纤上都有几十个波长。新一代DWDM系统将允许每根光纤具有数百个波长。
It becomes rather impractical to associate an IP address with each end of each physical link, to represent each link as a separate routing adjacency, and to advertise and to maintain link states for each of these links. For that purpose, GMPLS enhances the MPLS routing and addressing models to increase their scalability.
将IP地址与每个物理链路的每一端相关联、将每个链路表示为单独的路由邻接、公布和维护这些链路中的每个链路的链路状态变得相当不切实际。为此，GMPLS增强了MPLS路由和寻址模型，以提高其可扩展性。
Two optional mechanisms can be used to increase the scalability of the addressing and the routing: unnumbered links and link bundling. These two mechanisms can also be combined. They require extensions to signaling (RSVP-TE and CR-LDP) and routing (OSPF-TE and IS-IS-TE) protocols.
可以使用两种可选机制来提高寻址和路由的可伸缩性：未编号链接和链接绑定。这两种机制也可以结合使用。它们需要扩展信令（RSVP-TE和CR-LDP）和路由（OSPF-TE和IS-IS-TE）协议。
Traditionally, a TE link is advertised as an adjunct to a "regular" OSPF or IS-IS link, i.e., an adjacency is brought up on the link. When the link is up, both the regular IGP properties of the link (basically, the SPF metric) and the TE properties of the link are then advertised.
传统上，TE链路被广告为“常规”OSPF或is-is链路的附件，即，在链路上产生邻接。当链路启动时，链路的常规IGP属性（基本上是SPF度量）和链路的TE属性都会被公布。
However, GMPLS challenges this notion in three ways:
然而，GMPLS在三个方面挑战了这一概念：
- First, links that are non-PSC may yet have TE properties; however, an OSPF adjacency could not be brought up directly on such links.
- 首先，非PSC的链路可能仍然具有TE属性；然而，OSPF邻接不能直接在这种链路上进行。
- Second, an LSP can be advertised as a point-to-point TE link in the routing protocol, i.e., as a Forwarding Adjacency (FA); thus, an advertised TE link need no longer be between two OSPF direct neighbors. Forwarding Adjacencies (FA) are further described in Section 8.
- 第二，LSP可以作为路由协议中的点对点TE链路进行广告，即，作为转发邻接（FA）；因此，广告TE链路不再需要位于两个OSPF直接邻居之间。转发邻接（FA）在第8节中进一步描述。
- Third, a number of links may be advertised as a single TE link (e.g., for improved scalability), so again, there is no longer a one-to-one association of a regular adjacency and a TE link.
- 第三，可以将多个链路广告为单个TE链路（例如，为了提高可伸缩性），因此再次，不再存在规则邻接和TE链路的一对一关联。
Thus, we have a more general notion of a TE link. A TE link is a logical link that has TE properties. Some of these properties may be configured on the advertising LSR, others may be obtained from other LSRs by means of some protocol, and yet others may be deduced from the component(s) of the TE link.
因此，我们对TE链接有一个更一般的概念。TE链接是具有TE属性的逻辑链接。这些属性中的一些可以在广告LSR上配置，其他属性可以通过一些协议从其他LSR获得，还有其他属性可以从TE链路的组件推断。
An important TE property of a TE link is related to the bandwidth accounting for that link. GMPLS will define different accounting rules for different non-PSC layers. Generic bandwidth attributes are however defined by the TE routing extensions and by GMPLS, such as the unreserved bandwidth, the maximum reservable bandwidth and the maximum LSP bandwidth.
TE链路的一个重要TE属性与该链路的带宽有关。GMPLS将为不同的非PSC层定义不同的会计规则。但是，通用带宽属性由TE路由扩展和GMPLS定义，例如无保留带宽、最大可保留带宽和最大LSP带宽。
It is expected in a dynamic environment to have frequent changes of bandwidth accounting information. A flexible policy for triggering link state updates based on bandwidth thresholds and link-dampening mechanism can be implemented.
人们期望在动态环境中，带宽计费信息会频繁变化。可以实现基于带宽阈值和链路抑制机制的灵活的链路状态更新触发策略。
TE properties associated with a link should also capture protection and restoration related characteristics. For instance, shared protection can be elegantly combined with bundling. Protection and restoration are mainly generic mechanisms also applicable to MPLS. It is expected that they will first be developed for MPLS and later on generalized to GMPLS.
与链路相关的TE属性还应捕获与保护和恢复相关的特征。例如，共享保护可以与捆绑完美结合。保护和恢复主要是通用机制，也适用于MPLS。预计它们将首先为MPLS开发，然后推广到GMPLS。
A TE link between a pair of LSRs does not imply the existence of an IGP adjacency between these LSRs. A TE link must also have some means by which the advertising LSR can know of its liveness (e.g., by using LMP hellos). When an LSR knows that a TE link is up, and can determine the TE link's TE properties, the LSR may then advertise that link to its GMPLS enhanced OSPF or IS-IS neighbors using the TE objects/TLVs. We call the interfaces over which GMPLS enhanced OSPF or IS-IS adjacencies are established "control channels".
一对LSR之间的TE链路并不意味着这些LSR之间存在IGP邻接。TE链接还必须有一些方法，通过这些方法，广告LSR可以了解其活跃性（例如，通过使用LMP hellos）。当LSR知道TE链路已启动并且可以确定TE链路的TE属性时，LSR随后可以使用TE对象/TLV将该链路通告到其GMPLS增强的OSPF或is-is邻居。我们将建立GMPLS增强OSPF或IS-IS邻接的接口称为“控制通道”。
Unnumbered links (or interfaces) are links (or interfaces) that do not have IP addresses. Using such links involves two capabilities: the ability to specify unnumbered links in MPLS TE signaling, and the ability to carry (TE) information about unnumbered links in IGP TE extensions of IS-IS-TE and OSPF-TE.
未编号的链接（或接口）是没有IP地址的链接（或接口）。使用此类链路涉及两种能力：在MPLS TE信令中指定未编号链路的能力，以及在IS-IS-TE和OSPF-TE的IGP TE扩展中携带（TE）有关未编号链路的信息的能力。
A. The ability to specify unnumbered links in MPLS TE signaling requires extensions to RSVP-TE [RFC3477] and CR-LDP [RFC3480]. The MPLS-TE signaling does not provide support for unnumbered links, because it does not provide a way to indicate an unnumbered link in its Explicit Route Object/TLV and in its Record Route Object (there is no such TLV for CR-LDP). GMPLS defines simple extensions to indicate an unnumbered link in these two Objects/TLVs, using a new Unnumbered Interface ID sub-object/sub-TLV.
A.在MPLS TE信令中指定未编号链路的能力需要扩展到RSVP-TE[RFC3477]和CR-LDP[RFC3480]。MPLS-TE信令不支持未编号的链路，因为它不提供在其显式路由对象/TLV及其记录路由对象中指示未编号链路的方法（CR-LDP没有此类TLV）。GMPLS定义了简单的扩展，使用新的未编号接口ID子对象/子TLV来指示这两个对象/TLV中的未编号链接。
Since unnumbered links are not identified by an IP address, then for the purpose of MPLS TE each end need some other identifier, local to the LSR to which the link belongs. LSRs at the two end-points of an unnumbered link exchange with each other the identifiers they assign to the link. Exchanging the identifiers may be accomplished by configuration, by means of a protocol such as LMP ([LMP]), by means of RSVP-TE/CR-LDP (especially in the case where a link is a Forwarding Adjacency, see below), or by means of IS-IS or OSPF extensions ([ISIS-TE-GMPLS], [OSPF-TE-GMPLS]).
由于未编号的链路不由IP地址标识，因此出于MPLS的目的，每一端都需要一些其他标识符，该标识符位于链路所属的LSR的本地。未编号链路两端的LSR相互交换分配给链路的标识符。可通过配置、借助诸如LMP（[LMP]）、借助RSVP-TE/CR-LDP（尤其是在链路是转发邻接的情况下，参见下文）或借助is-is或OSPF扩展（[ISIS-TE-GMPLS]、[OSPF-TE-GMPLS]）来完成标识符的交换。
Consider an (unnumbered) link between LSRs A and B. LSR A chooses an identifier for that link. So does LSR B. From A's perspective we refer to the identifier that A assigned to the link as the "link local identifier" (or just "local identifier"), and to the identifier that B assigned to the link as the "link remote identifier" (or just "remote identifier"). Likewise, from B's perspective the identifier that B assigned to the link is the local identifier, and the identifier that A assigned to the link is the remote identifier.
考虑LSR A和B之间的（未编号）链路，LSR A选择该链路的标识符。LSR B也是如此。从A的角度来看，我们将A分配给链路的标识符称为“链路本地标识符”（或简称“本地标识符”），将B分配给链路的标识符称为“链路远程标识符”（或简称“远程标识符”）。同样，从B的角度来看，B分配给链路的标识符是本地标识符，A分配给链路的标识符是远程标识符。
The new Unnumbered Interface ID sub-object/sub-TLV for the ER Object/TLV contains the Router ID of the LSR at the upstream end of the unnumbered link and the link local identifier with respect to that upstream LSR.
ER对象/TLV的新的未编号接口ID子对象/sub TLV包含未编号链路上游端的LSR的路由器ID和关于该上游LSR的链路本地标识符。
The new Unnumbered Interface ID sub-object for the RR Object contains the link local identifier with respect to the LSR that adds it in the RR Object.
RR对象的新的未编号接口ID子对象包含与将其添加到RR对象中的LSR相关的链接本地标识符。
B. The ability to carry (TE) information about unnumbered links in IGP TE extensions requires new sub-TLVs for the extended IS reachability TLV defined in IS-IS-TE and for the TE LSA (which is an opaque LSA) defined in OSPF-TE. A Link Local Identifier sub-TLV and a Link Remote Identifier sub-TLV are defined.
B.在IGP TE扩展中携带关于未编号链路的（TE）信息的能力需要IS-IS-TE中定义的扩展IS可达性TLV和OSPF-TE中定义的TE LSA（不透明LSA）的新子TLV。定义了链路本地标识符子TLV和链路远程标识符子TLV。
If an LSR that originates an LSP advertises this LSP as an unnumbered FA in IS-IS or OSPF, or the LSR uses this FA as an unnumbered component link of a bundled link, the LSR must allocate an Interface ID to that FA. If the LSP is bi-directional, the tail end does the same and allocates an Interface ID to the reverse FA.
如果发起LSP的LSR在IS-IS或OSPF中将此LSP作为未编号的FA播发，或者LSR将此FA用作捆绑链路的未编号组件链路，则LSR必须为该FA分配接口ID。如果LSP是双向的，那么后端也会这样做，并将接口ID分配给反向FA。
Signaling has been enhanced to carry the Interface ID of a FA in the new LSP Tunnel Interface ID object/TLV. This object/TLV contains the Router ID (of the LSR that generates it) and the Interface ID. It is called the Forward Interface ID when it appears in a Path/REQUEST message, and it is called the Reverse Interface ID when it appears in the Resv/MAPPING message.
信令已得到增强，以在新的LSP隧道接口ID对象/TLV中承载FA的接口ID。此对象/TLV包含路由器ID（生成它的LSR的ID）和接口ID。当它出现在路径/请求消息中时称为转发接口ID，当它出现在Resv/映射消息中时称为反向接口ID。
The concept of link bundling is essential in certain networks employing the GMPLS control plane as is defined in [BUNDLE]. A typical example is an optical meshed network where adjacent optical cross-connects (LSRs) are connected by several hundreds of parallel wavelengths. In this network, consider the application of link state routing protocols, like OSPF or IS-IS, with suitable extensions for resource discovery and dynamic route computation. Each wavelength must be advertised separately to be used, except if link bundling is used.
链路捆绑的概念在采用[BUNDLE]中定义的GMPLS控制平面的某些网络中至关重要。一个典型的例子是光网状网络，其中相邻的光交叉连接（LSR）由数百个平行波长连接。在这个网络中，考虑链路状态路由协议（如OSPF或IS-IS）的应用，并适当地扩展资源发现和动态路由计算。每个波长必须单独公布才能使用，除非使用链接捆绑。
When a pair of LSRs is connected by multiple links, it is possible to advertise several (or all) of these links as a single link into OSPF and/or IS-IS. This process is called link bundling, or just bundling. The resulting logical link is called a bundled link as its physical links are called component links (and are identified by interface indexes).
当一对LSR通过多个链路连接时，可以将这些链路中的多个（或全部）作为单个链路发布到OSPF和/或is-is中。这个过程被称为链接绑定，或者只是绑定。产生的逻辑链接称为捆绑链接，因为其物理链接称为组件链接（并由接口索引标识）。
The result is that a combination of three identifiers ((bundled) link identifier, component link identifier, label) is sufficient to unambiguously identify the appropriate resources used by an LSP.
结果是三个标识符（（捆绑）链路标识符、组件链路标识符、标签）的组合足以明确标识LSP使用的适当资源。
The purpose of link bundling is to improve routing scalability by reducing the amount of information that has to be handled by OSPF and/or IS-IS. This reduction is accomplished by performing information aggregation/abstraction. As with any other information aggregation/abstraction, this results in losing some of the information. To limit the amount of losses one need to restrict the type of the information that can be aggregated/abstracted.
链路绑定的目的是通过减少OSPF和/或is-is必须处理的信息量来提高路由可伸缩性。这种简化是通过执行信息聚合/抽象来实现的。与任何其他信息聚合/抽象一样，这会导致丢失一些信息。为了限制损失量，需要限制可聚合/抽象的信息类型。
The following restrictions are required for bundling links. All component links in a bundle must begin and end on the same pair of LSRs; and share some common characteristics or properties defined in [OSPF-TE] and [ISIS-TE], i.e., they must have the same:
捆绑链接需要以下限制。捆绑包中的所有组件链接必须在同一对LSR上开始和结束；并共享[OSPF-TE]和[ISIS-TE]中定义的一些共同特征或属性，即它们必须具有相同的：
- Link Type (i.e., point-to-point or multi-access), - TE Metric (i.e., an administrative cost), - Set of Resource Classes at each end of the links (i.e., colors).
- 链路类型（即，点到点或多址访问），-TE度量（即，管理成本），-链路两端的资源类集合（即，颜色）。
Note that a FA may also be a component link. In fact, a bundle can consist of a mix of point-to-point links and FAs, but all sharing some common properties.
请注意，FA也可以是组件链接。事实上，bundle可以由点到点链接和FAs组成，但都共享一些公共属性。
A bundled link is just another kind of TE link such as those defined by [GMPLS-ROUTING]. The liveness of the bundled link is determined by the liveness of each its component links. A bundled link is alive when at least one of its component links is alive. The liveness of a component link can be determined by any of several means: IS-IS or OSPF hellos over the component link, or RSVP Hello (hop local), or LMP hellos (link local), or from layer 1 or layer 2 indications.
捆绑链路只是另一种TE链路，如[GMPLS-ROUTING]定义的那种。捆绑链接的活跃度由其每个组件链接的活跃度决定。当捆绑链接的至少一个组件链接处于活动状态时，捆绑链接处于活动状态。组件链路的活跃度可以通过以下几种方式中的任何一种来确定：组件链路上的IS-IS或OSPF hellos，或RSVP Hello（hop local），或LMP hellos（链路local），或第1层或第2层指示。
Note that (according to the RSVP-TE specification [RFC3209]) the RSVP Hello mechanism is intended to be used when notification of link layer failures is not available and unnumbered links are not used, or when the failure detection mechanisms provided by the link layer are not sufficient for timely node failure detection.
注意（根据RSVP-TE规范[RFC3209]）RSVP Hello机制旨在当链路层故障通知不可用且未使用未编号的链路时，或者当链路层提供的故障检测机制不足以及时检测节点故障时使用。
Once a bundled link is determined to be alive, it can be advertised as a TE link and the TE information can be flooded. If IS-IS/OSPF hellos are run over the component links, IS-IS/OSPF flooding can be restricted to just one of the component links.
一旦捆绑链接被确定为活动链接，它就可以作为TE链接进行广告，并且TE信息可以被淹没。如果IS-IS/OSPF HELLO在组件链路上运行，则IS-IS/OSPF洪泛可以仅限于其中一个组件链路。
Note that advertising a (bundled) TE link between a pair of LSRs does not imply that there is an IGP adjacency between these LSRs that is associated with just that link. In fact, in certain cases a TE link between a pair of LSRs could be advertised even if there is no IGP adjacency at all between the LSR (e.g., when the TE link is an FA).
注意，在一对lsr之间宣传（捆绑）TE链路并不意味着这些lsr之间存在仅与该链路相关联的IGP邻接。事实上，在某些情况下，即使LSR之间根本不存在IGP邻接（例如，当TE链路是FA时），也可以通告一对LSR之间的TE链路。
Forming a bundled link consist in aggregating the identical TE parameters of each individual component link to produce aggregated TE parameters. A TE link as defined by [GMPLS-ROUTING] has many parameters; adequate aggregation rules must be defined for each one.
形成捆绑链路包括聚合每个单独组件链路的相同TE参数以生成聚合TE参数。由[GMPLS-ROUTING]定义的TE链路具有许多参数；必须为每个规则定义足够的聚合规则。
Some parameters can be sums of component characteristics such as the unreserved bandwidth and the maximum reservable bandwidth. Bandwidth information is an important part of a bundle advertisement and it must be clearly defined since an abstraction is done.
某些参数可以是组件特性的总和，例如未保留带宽和最大可保留带宽。带宽信息是捆绑广告的一个重要组成部分，由于进行了抽象，因此必须明确定义带宽信息。
A GMPLS node with bundled links must apply admission control on a per-component link basis.
具有捆绑链路的GMPLS节点必须基于每个组件链路应用准入控制。
Typically, an LSP's explicit route (e.g., contained in an explicit route Object/TLV) will choose the bundled link to be used for the LSP, but not the component link(s). This because information about the bundled link is flooded but information about the component links is not.
通常，LSP的显式路由（例如，包含在显式路由对象/TLV中）将选择要用于LSP的捆绑链路，而不是组件链路。这是因为有关捆绑链接的信息被淹没，而有关组件链接的信息则不被淹没。
The choice of the component link to use is always made by an upstream node. If the LSP is bi-directional, the upstream node chooses a component link in each direction.
始终由上游节点选择要使用的组件链接。如果LSP是双向的，则上游节点在每个方向上选择组件链路。
Three mechanisms for indicating this choice to the downstream node are possible.
可以使用三种机制向下游节点指示此选择。
This mechanism requires that each component link has a dedicated signaling channel (e.g., the link is a Sonet/SDH link using the DCC for in-band signaling). The upstream node tells the receiver which component link to use by sending the message over the chosen component link's dedicated signaling channel. Note that this signaling channel can be in-band or out-of-band. In this last case, the association between the signaling channel and that component link need to be explicitly configured.
该机制要求每个组件链路具有专用信令信道（例如，该链路是使用DCC进行带内信令的Sonet/SDH链路）。上游节点通过在所选组件链路的专用信令信道上发送消息来告诉接收器要使用哪个组件链路。请注意，此信令信道可以是带内或带外。在最后一种情况下，需要显式地配置信令信道和该组件链路之间的关联。
This mechanism requires that the component link has a unique remote IP address. The upstream node indicates the choice of the component link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying either an IPv4 or an IPv6 address in the Path/Label Request message (see [RFC3473]/[RFC3472], respectively). For a bi-directional LSP, a component link is provided for each direction by the upstream node.
此机制要求组件链接具有唯一的远程IP地址。上游节点通过在路径/标签请求消息中包含新的IF_ID RSVP_HOP对象/IF_ID TLV来指示组件链路的选择（分别参见[RFC3473]/[RFC3472]）。对于双向LSP，上游节点为每个方向提供组件链路。
This mechanism does not require each component link to have its own control channel. In fact, it does not even require the whole (bundled) link to have its own control channel.
此机制不要求每个组件链接都有自己的控制通道。事实上，它甚至不需要整个（捆绑）链路拥有自己的控制通道。
With this mechanism, each component link that is unnumbered is assigned a unique Interface Identifier (32 bits value). The upstream node indicates the choice of the component link by including a new IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message (see [RFC3473]/[RFC3472], respectively).
通过这种机制，每个未编号的组件链接被分配一个唯一的接口标识符（32位值）。上游节点通过在路径/标签请求消息中包含新的IF_ID RSVP_HOP object/IF_ID TLV来指示组件链接的选择（分别参见[RFC3473]/[RFC3472]）。
This object/TLV carries the component interface ID in the downstream direction for a unidirectional LSP, and in addition, the component interface ID in the upstream direction for a bi-directional LSP.
对于单向LSP，该对象/TLV在下游方向携带组件接口ID，此外，对于双向LSP，该对象/TLV在上游方向携带组件接口ID。
The two LSRs at each end of the bundled link exchange these identifiers. Exchanging the identifiers may be accomplished by configuration, by means of a protocol such as LMP (preferred solution), by means of RSVP-TE/CR-LDP (especially in the case where a component link is a Forwarding Adjacency), or by means of IS-IS or OSPF extensions.
捆绑链路两端的两个LSR交换这些标识符。可通过配置、借助诸如LMP（优选解决方案）的协议、借助RSVP-TE/CR-LDP（特别是在组件链路是转发邻接的情况下）或借助is-is或OSPF扩展来完成标识符的交换。
This mechanism does not require each component link to have its own control channel. In fact, it does not even require the whole (bundled) link to have its own control channel.
此机制不要求每个组件链接都有自己的控制通道。事实上，它甚至不需要整个（捆绑）链路拥有自己的控制通道。
A bundled link may itself be numbered or unnumbered independent of whether the component links are numbered or not. This affects how the bundled link is advertised in IS-IS/OSPF and the format of LSP EROs that traverse the bundled link. Furthermore, unnumbered Interface Identifiers for all unnumbered outgoing links of a given LSR (whether component links, Forwarding Adjacencies or bundled links) must be unique in the context of that LSR.
捆绑链接本身可以编号或不编号，这与组件链接是否编号无关。这会影响在is-is/OSPF中播发捆绑链路的方式以及穿过捆绑链路的LSP ERO的格式。此外，给定LSR的所有未编号传出链接（无论是组件链接、转发邻接还是捆绑链接）的未编号接口标识符在该LSR的上下文中必须是唯一的。
The generic rule for bundling component links is to place those links that are correlated in some manner in the same bundle. If links may be correlated based on multiple properties then the bundling may be applied sequentially based on these properties. For instance, links may be first grouped based on the first property. Each of these groups may be then divided into smaller groups based on the second property and so on. The main principle followed in this process is that the properties of the resulting bundles should be concisely summarizable. Link bundling may be done automatically or by configuration. Automatic link bundling can apply bundling rules sequentially to produce bundles.
捆绑组件链接的一般规则是将那些以某种方式相关的链接放在同一个捆绑包中。如果可以基于多个属性关联链接，则可以基于这些属性顺序应用捆绑。例如，可以首先基于第一个属性对链接进行分组。然后，可以基于第二属性等将这些组中的每一个划分为更小的组。在这个过程中遵循的主要原则是，生成的bundle的属性应该简明地概括。链接绑定可以自动完成，也可以通过配置完成。自动链接绑定可以按顺序应用绑定规则以生成绑定。
For instance, the first property on which component links may be correlated could be the Interface Switching Capability [GMPLS-ROUTING], the second property could be the Encoding [GMPLS-ROUTING], the third property could be the Administrative Weight (cost), the fourth property could be the Resource Classes and finally links may be correlated based on other metrics such as SRLG (Shared Risk Link Groups).
例如，组件链路相关的第一个属性可以是接口交换能力[GMPLS-ROUTING]，第二个属性可以是编码[GMPLS-ROUTING]，第三个属性可以是管理权重（成本），第四个属性可以是资源类，最后链接可以基于其他指标（如SRLG（共享风险链接组））进行关联。
When routing an alternate path for protection purposes, the general principle followed is that the alternate path is not routed over any link belonging to an SRLG that belongs to some link of the primary path. Thus, the rule to be followed is to group links belonging to exactly the same set of SRLGs.
为保护目的路由备用路径时，遵循的一般原则是，备用路径不会路由到属于SRLG（属于主路径的某个链路）的任何链路上。因此，要遵循的规则是将属于同一组SRLGs的链接分组。
This type of sequential sub-division may result in a number of bundles between two adjacent nodes. In practice, however, the link properties may not be very heterogeneous among component links between two adjacent nodes. Thus, the number of bundles in practice may not be large.
这种类型的顺序子划分可能会导致两个相邻节点之间出现许多束。然而，在实践中，两个相邻节点之间的组件链路之间的链路属性可能不是很异构。因此，实际上捆绑的数量可能并不多。
The interface between an edge GMPLS node and a GMPLS LSR on the network side may be referred to as a User to Network Interface (UNI), while the interface between two-network side LSRs may be referred to as a Network to Network Interface (NNI).
边缘GMPLS节点和网络侧的GMPLS LSR之间的接口可以称为用户到网络接口（UNI），而两个网络侧LSR之间的接口可以称为网络到网络接口（NNI）。
GMPLS does not specify separately a UNI and an NNI. Edge nodes are connected to LSRs on the network side, and these LSRs are in turn connected between them. Of course, the behavior of an edge node is not exactly the same as the behavior of an LSR on the network side. Note also, that an edge node may run a routing protocol, however it is expected that in most of the cases it will not (see also section 5.2 and the section about signaling with an explicit route).
GMPLS未单独指定UNI和NNI。边缘节点连接到网络侧的LSR，而这些LSR又在它们之间连接。当然，边缘节点的行为与网络端LSR的行为并不完全相同。还要注意的是，边缘节点可以运行路由协议，但是在大多数情况下，它不会运行路由协议（另请参见第5.2节和关于显式路由信令的章节）。
Conceptually, a difference between UNI and NNI make sense either if both interface uses completely different protocols, or if they use the same protocols but with some outstanding differences. In the first case, separate protocols are often defined successively, with more or less success.
从概念上讲，如果两个接口使用完全不同的协议，或者如果它们使用相同的协议但存在一些显著的差异，那么UNI和NNI之间的差异是有意义的。在第一种情况下，通常会连续定义单独的协议，或多或少会成功。
The GMPLS approach consisted in building a consistent model from day one, considering both the UNI and NNI interfaces at the same time [GMPLS-OVERLAY]. For that purpose, a very few specific UNI particularities have been ignored in a first time. GMPLS has been enhanced to support such particularities at the UNI by some other standardization bodies (see hereafter).
GMPLS方法包括从第一天开始建立一致的模型，同时考虑UNI和NNI接口[GMPLS-OVERLAY]。为此目的，极少数具体的单一性首次被忽视。一些其他标准化机构已增强GMPLS，以支持UNI的此类特殊性（见下文）。
This section is only given for reference to the OIF work related to GMPLS. The current OIF UNI specification [OIF-UNI] defines an interface between a client SONET/SDH equipment and an SONET/SDH network, each belonging to a distinct administrative authority. It is designed for an overlay model. The OIF UNI defines additional mechanisms on the top of GMPLS for the UNI.
本节仅供参考与GMPLS相关的OIF工作。当前的OIF UNI规范[OIF-UNI]定义了客户端SONET/SDH设备和SONET/SDH网络之间的接口，每个设备都属于不同的管理机构。它是为覆盖模型设计的。OIF UNI在UNI的GMPLS顶部定义了其他机制。
For instance, the OIF service discovery procedure is a precursor to obtaining UNI services. Service discovery allows a client to determine the static parameters of the interconnection with the network, including the UNI signaling protocol, the type of concatenation, the transparency level as well as the type of diversity (node, link, SRLG) supported by the network.
例如，OIF服务发现过程是获得UNI服务的先决条件。服务发现允许客户端确定与网络互连的静态参数，包括UNI信令协议、连接类型、透明度级别以及网络支持的分集类型（节点、链路、SRLG）。
Since the current OIF UNI interface does not cover photonic networks, G.709 Digital Wrapper, etc, it is from that perspective a subset of the GMPLS Architecture at the UNI.
由于目前的OIF UNI接口不包括光子网络、G.709数字包装器等，因此从这个角度来看，它是UNI的GMPLS体系结构的一个子集。
This section discusses the selection of an explicit route by an edge node. The selection of the first LSR by an edge node connected to multiple LSRs is part of that problem.
本节讨论由边节点选择显式管线。连接到多个LSR的边缘节点选择第一个LSR是该问题的一部分。
An edge node (host or LSR) can participate more or less deeply in the GMPLS routing. Four different routing models can be supported at the UNI: configuration based, partial peering, silent listening and full peering.
边缘节点（主机或LSR）可以或多或少深入地参与GMPLS路由。UNI支持四种不同的路由模型：基于配置、部分对等、静默侦听和完全对等。
- Configuration based: this routing model requires the manual or automatic configuration of an edge node with a list of neighbor LSRs sorted by preference order. Automatic configuration can be achieved using DHCP for instance. No routing information is
- 基于配置：此路由模型需要手动或自动配置边缘节点，并按优先顺序排序相邻LSR的列表。例如，可以使用DHCP实现自动配置。没有路由信息
exchanged at the UNI, except maybe the ordered list of LSRs. The only routing information used by the edge node is that list. The edge node sends by default an LSP request to the preferred LSR. ICMP redirects could be send by this LSR to redirect some LSP requests to another LSR connected to the edge node. GMPLS does not preclude that model.
在UNI交换，除了LSR的有序列表。边缘节点使用的唯一路由信息是该列表。默认情况下，边缘节点向首选LSR发送LSP请求。此LSR可以发送ICMP重定向，以将一些LSP请求重定向到连接到边缘节点的另一个LSR。GMPLS并不排除该模型。
- Partial peering: limited routing information (mainly reachability) can be exchanged across the UNI using some extensions in the signaling plane. The reachability information exchanged at the UNI may be used to initiate edge node specific routing decision over the network. GMPLS does not have any capability to support this model today.
- 部分对等：有限的路由信息（主要是可达性）可以使用信令平面中的一些扩展在UNI之间交换。在UNI处交换的可达性信息可用于在网络上发起特定于边缘节点的路由决策。GMPLS目前没有任何能力支持此模型。
- Silent listening: the edge node can silently listen to routing protocols and take routing decisions based on the information obtained. An edge node receives the full routing information, including traffic engineering extensions. One LSR should forward transparently all routing PDUs to the edge node. An edge node can now compute a complete explicit route taking into consideration all the end-to-end routing information. GMPLS does not preclude this model.
- 静默侦听：边缘节点可以静默侦听路由协议，并根据获得的信息做出路由决策。边缘节点接收完整的路由信息，包括流量工程扩展。一个LSR应该透明地将所有路由PDU转发到边缘节点。边缘节点现在可以在考虑所有端到端路由信息的情况下计算完整的显式路由。GMPLS不排除该模型。
- Full peering: in addition to silent listening, the edge node participates within the routing, establish adjacencies with its neighbors and advertises LSAs. This is useful only if there are benefits for edge nodes to advertise themselves traffic engineering information. GMPLS does not preclude this model.
- 完全对等：除了静默侦听之外，边缘节点还参与路由，与其邻居建立邻接并播发LSA。只有当边缘节点宣传自己的流量工程信息有好处时，这才有用。GMPLS不排除该模型。
In the context of GMPLS, a pair of nodes (e.g., a photonic switch) may be connected by tens of fibers, and each fiber may be used to transmit hundreds of wavelengths if DWDM is used. Multiple fibers and/or multiple wavelengths may also be combined into one or more bundled links for routing purposes. Furthermore, to enable communication between nodes for routing, signaling, and link management, control channels must be established between a node pair.
在GMPLS的上下文中，一对节点（例如，光子开关）可由数十根光纤连接，并且如果使用DWDM，则每根光纤可用于传输数百个波长。出于路由目的，多个光纤和/或多个波长也可以组合成一个或多个捆绑链路。此外，为了实现节点之间的通信以进行路由、信令和链路管理，必须在节点对之间建立控制信道。
Link management is a collection of useful procedures between adjacent nodes that provide local services such as control channel management, link connectivity verification, link property correlation, and fault management. The Link Management Protocol (LMP) [LMP] has been defined to fulfill these operations. LMP has been initiated in the context of GMPLS but is a generic toolbox that can be also used in other contexts.
链路管理是提供本地服务（如控制通道管理、链路连接验证、链路属性关联和故障管理）的相邻节点之间的有用过程的集合。链路管理协议（LMP）[LMP]已被定义为实现这些操作。LMP已经在GMPLS的上下文中启动，但它是一个通用工具箱，也可以在其他上下文中使用。
In GMPLS, the control channels between two adjacent nodes are no longer required to use the same physical medium as the data links between those nodes. Moreover, the control channels that are used to exchange the GMPLS control-plane information exist independently of the links they manage. Hence, LMP was designed to manage the data links, independently of the termination capabilities of those data links.
在GMPLS中，两个相邻节点之间的控制信道不再需要使用与这些节点之间的数据链路相同的物理介质。此外，用于交换GMPLS控制平面信息的控制通道独立于它们所管理的链路而存在。因此，LMP设计用于管理数据链路，独立于这些数据链路的终止能力。
Control channel management and link property correlation procedures are mandatory per LMP. Link connectivity verification and fault management procedures are optional.
根据LMP，控制信道管理和链路属性关联程序是强制性的。链路连接验证和故障管理程序是可选的。
LMP control channel management is used to establish and maintain control channels between nodes. Control channels exist independently of TE links, and can be used to exchange MPLS control-plane information such as signaling, routing, and link management information.
LMP控制信道管理用于建立和维护节点之间的控制信道。控制信道独立于TE链路存在，可用于交换MPLS控制平面信息，如信令、路由和链路管理信息。
An "LMP adjacency" is formed between two nodes that support the same LMP capabilities. Multiple control channels may be active simultaneously for each adjacency. A control channel can be either explicitly configured or automatically selected, however, LMP currently assume that control channels are explicitly configured while the configuration of the control channel capabilities can be dynamically negotiated.
在支持相同LMP能力的两个节点之间形成“LMP邻接”。对于每个邻接，多个控制信道可以同时激活。控制信道可以是显式配置或自动选择的，然而，LMP当前假定控制信道是显式配置的，而控制信道能力的配置可以动态协商。
For the purposes of LMP, the exact implementation of the control channel is left unspecified. The control channel(s) between two adjacent nodes is no longer required to use the same physical medium as the data-bearing links between those nodes. For example, a control channel could use a separate wavelength or fiber, an Ethernet link, or an IP tunnel through a separate management network.
出于LMP的目的，控制信道的精确实现未指定。两个相邻节点之间的控制信道不再需要使用与这些节点之间的数据承载链路相同的物理介质。例如，控制通道可以通过单独的管理网络使用单独的波长或光纤、以太网链路或IP隧道。
A consequence of allowing the control channel(s) between two nodes to be physically diverse from the associated data-bearing links is that the health of a control channel does not necessarily correlate to the health of the data-bearing links, and vice-versa. Therefore, new mechanisms have been developed in LMP to manage links, both in terms of link provisioning and fault isolation.
允许两个节点之间的控制信道与相关联的数据承载链路在物理上不同的结果是，控制信道的健康不一定与数据承载链路的健康相关，反之亦然。因此，在LMP中开发了新的机制来管理链路，包括链路供应和故障隔离。
LMP does not specify the signaling transport mechanism used in the control channel, however it states that messages transported over a control channel must be IP encoded. Furthermore, since the messages are IP encoded, the link level encoding is not part of LMP. A 32-bit non-zero integer Control Channel Identifier (CCId) is assigned to each direction of a control channel.
LMP没有指定控制信道中使用的信令传输机制，但是它声明通过控制信道传输的消息必须是IP编码的。此外，由于消息是IP编码的，因此链路级编码不是LMP的一部分。将32位非零整数控制信道标识符（CCId）分配给控制信道的每个方向。
Each control channel individually negotiates its control channel parameters and maintains connectivity using a fast Hello protocol. The latter is required if lower-level mechanisms are not available to detect link failures.
每个控制通道单独协商其控制通道参数，并使用快速Hello协议保持连接。如果无法使用较低级别的机制来检测链路故障，则需要后者。
The Hello protocol of LMP is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly so that IGP Hellos are not lost and the associated link-state adjacencies are not removed uselessly.
LMP的Hello协议旨在成为一种轻量级的保持活动机制，该机制将对控制信道故障做出快速反应，以便IGP Hello不会丢失，并且相关的链路状态邻接不会被无用地删除。
The Hello protocol consists of two phases: a negotiation phase and a keep-alive phase. The negotiation phase allows negotiation of some basic Hello protocol parameters, like the Hello frequency. The keep-alive phase consists of a fast lightweight bi-directional Hello message exchange.
Hello协议包括两个阶段：协商阶段和保持活动阶段。协商阶段允许协商一些基本的Hello协议参数，如Hello频率。保持活动状态阶段包括快速、轻量级的双向Hello消息交换。
If a group of control channels share a common node pair and support the same LMP capabilities, then LMP control channel messages (except Configuration messages, and Hello's) may be transmitted over any of the active control channels without coordination between the local and remote nodes.
如果一组控制信道共享公共节点对并且支持相同的LMP能力，则LMP控制信道消息（配置消息和Hello消息除外）可以在本地和远程节点之间不进行协调的情况下通过任何活动控制信道来传输。
For LMP, it is essential that at least one control channel is always available. In case of control channel failure, it may be possible to use an alternate active control channel without coordination.
对于LMP，至少有一个控制信道始终可用是至关重要的。在控制通道故障的情况下，可以在不进行协调的情况下使用备用主动控制通道。
As part of LMP, a link property correlation exchange is defined. The exchange is used to aggregate multiple data-bearing links (i.e., component links) into a bundled link and exchange, correlate, or change TE link parameters. The link property correlation exchange may be done at any time a link is up and not in the Verification process (see next section).
作为LMP的一部分，定义了链路特性相关交换。交换用于将多个数据承载链路（即组件链路）聚合为捆绑链路，并交换、关联或更改TE链路参数。链路属性相关性交换可以在链路启动时进行，而不是在验证过程中（参见下一节）。
It allows, for instance, the addition of component links to a link bundle, change of a link's minimum/maximum reservable bandwidth, change of port identifiers, or change of component identifiers in a bundle. This mechanism is supported by an exchange of link summary messages.
例如，它允许将组件链接添加到链接束中、更改链接的最小/最大可保留带宽、更改端口标识符或更改包中的组件标识符。链接摘要消息的交换支持此机制。
Link connectivity verification is an optional procedure that may be used to verify the physical connectivity of data-bearing links as well as to exchange the link identifiers that are used in the GMPLS signaling.
链路连接验证是一个可选程序，可用于验证数据承载链路的物理连接以及交换GMPLS信令中使用的链路标识符。
This procedure should be performed initially when a data-bearing link is first established, and subsequently, on a periodic basis for all unallocated (free) data-bearing links.
首先应在建立数据承载链路时执行此程序，然后定期执行所有未分配（空闲）数据承载链路。
The verification procedure consists of sending Test messages in-band over the data-bearing links. This requires that the unallocated links must be opaque; however, multiple degrees of opaqueness (e.g., examining overhead bytes, terminating the payload, etc.), and hence different mechanisms to transport the Test messages, are specified. Note that the Test message is the only LMP message that is transmitted over the data-bearing link, and that Hello messages continue to be exchanged over the control channel during the link verification process. Data-bearing links are tested in the transmit direction as they are unidirectional. As such, it is possible for LMP neighboring nodes to exchange the Test messages simultaneously in both directions.
验证程序包括通过数据承载链路在频带内发送测试消息。这要求未分配的链接必须是不透明的；然而，规定了多个不透明程度（例如，检查开销字节、终止有效负载等），以及因此传输测试消息的不同机制。注意，测试消息是通过数据承载链路传输的唯一LMP消息，并且在链路验证过程中，Hello消息继续通过控制信道交换。数据承载链路在传输方向进行测试，因为它们是单向的。因此，LMP相邻节点可以在两个方向上同时交换测试消息。
To initiate the link verification procedure, a node must first notify the adjacent node that it will begin sending Test messages over a particular data-bearing link, or over the component links of a particular bundled link. The node must also indicate the number of data-bearing links that are to be verified; the interval at which the test messages will be sent; the encoding scheme, the transport mechanisms that are supported, the data rate for Test messages; and, in the case where the data-bearing links correspond to fibers, the wavelength over which the Test messages will be transmitted. Furthermore, the local and remote bundled link identifiers are transmitted at this time to perform the component link association with the bundled link identifiers.
为了启动链路验证过程，节点必须首先通知相邻节点它将开始通过特定数据承载链路或特定捆绑链路的组件链路发送测试消息。该节点还必须指示要验证的数据承载链路的数量；发送测试消息的时间间隔；编码方案、支持的传输机制、测试消息的数据速率；以及，在数据承载链路对应于光纤的情况下，测试消息将在其上传输的波长。此外，此时发送本地和远程捆绑链路标识符，以执行与捆绑链路标识符的组件链路关联。
Fault management is an important requirement from the operational point of view. Fault management includes usually: fault detection, fault localization and fault notification. When a failure occurs and is detected (fault detection), an operator needs to know exactly where it happened (fault localization) and a source node may need to be notified in order to take some actions (fault notification).
从操作角度来看，故障管理是一项重要要求。故障管理通常包括：故障检测、故障定位和故障通知。当故障发生并被检测到（故障检测）时，操作员需要确切地知道故障发生的位置（故障定位），并且可能需要通知源节点以采取某些措施（故障通知）。
Note that fault localization can also be used to support some specific (local) protection/restoration mechanisms.
请注意，故障定位还可用于支持某些特定（本地）保护/恢复机制。
In new technologies such as transparent photonic switching currently no method is defined to locate a fault, and the mechanism by which the fault information is propagated must be sent "out of band" (via the control plane).
在透明光子交换等新技术中，目前没有定义定位故障的方法，故障信息传播的机制必须“带外”（通过控制平面）发送。
LMP provides a fault localization procedure that can be used to rapidly localize link failures, by notifying a fault up to the node upstream of that fault (i.e., through a fault notification procedure).
LMP提供了一种故障定位程序，可用于快速定位链路故障，方法是将故障通知到故障上游的节点（即，通过故障通知程序）。
A downstream LMP neighbor that detects data link failures will send an LMP message to its upstream neighbor notifying it of the failure. When an upstream node receives a failure notification, it can correlate the failure with the corresponding input ports to determine if the failure is between the two nodes. Once the failure has been localized, the signaling protocols can be used to initiate link or path protection/restoration procedures.
检测到数据链路故障的下游LMP邻居将向其上游邻居发送LMP消息，通知其故障。当上游节点收到故障通知时，它可以将故障与相应的输入端口关联起来，以确定故障是否在两个节点之间。故障定位后，可以使用信令协议启动链路或路径保护/恢复程序。
In an all-optical environment, LMP focuses on peer communications (e.g., OXC-to-OXC). A great deal of information about a link between two OXCs is known by the OLS (Optical Line System or WDM Terminal multiplexer). Exposing this information to the control plane can improve network usability by further reducing required manual configuration, and by greatly enhancing fault detection and recovery.
在全光环境中，LMP侧重于对等通信（例如，OXC到OXC）。OLS（光线路系统或WDM终端多路复用器）知道关于两个OXC之间链路的大量信息。将此信息公开给控制平面可以进一步减少所需的手动配置，并大大增强故障检测和恢复，从而提高网络可用性。
LMP-WDM [LMP-WDM] defines extensions to LMP for use between an OXC and an OLS. These extensions are intended to satisfy the Optical Link Interface Requirements described in [OLI-REQ].
LMP-WDM[LMP-WDM]定义了LMP的扩展，供OXC和OLS之间使用。这些扩展旨在满足[OLI-REQ]中描述的光链路接口要求。
Fault detection is particularly an issue when the network is using all-optical photonic switches (PXC). Once a connection is established, PXCs have only limited visibility into the health of the connection. Although the PXC is all-optical, long-haul OLSs typically terminate channels electrically and regenerate them optically. This provides an opportunity to monitor the health of a channel between PXCs. LMP-WDM can then be used by the OLS to provide this information to the PXC.
当网络使用全光光子开关（PXC）时，故障检测尤其是一个问题。一旦建立了连接，PXC对连接运行状况的可见性就很有限。尽管PXC是全光的，但长距离OLS通常以电气方式终止通道，并以光学方式重新生成通道。这为监控PXC之间通道的运行状况提供了机会。然后，OLS可以使用LMP-WDM向PXC提供该信息。
In addition to the link information known to the OLS that is exchanged through LMP-WDM, some information known to the OXC may also be exchanged with the OLS through LMP-WDM. This information is useful for alarm management and link monitoring (e.g., trace monitoring). Alarm management is important because the administrative state of a connection, known to the OXC (e.g., this information may be learned through the Admin Status object of GMPLS signaling [RFC3471]), can be used to suppress spurious alarms. For example, the OXC may know that a connection is "up", "down", in a "testing" mode, or being deleted ("deletion-in-progress"). The OXC can use this information to inhibit alarm reporting from the OLS when a connection is "down", "testing", or being deleted.
除了通过LMP-WDM交换的OLS已知的链路信息之外，OXC已知的一些信息也可以通过LMP-WDM与OLS交换。此信息对于报警管理和链路监控（例如跟踪监控）非常有用。报警管理很重要，因为OXC已知的连接管理状态（例如，可通过GMPLS信令[RFC3471]的管理状态对象了解该信息）可用于抑制虚假报警。例如，OXC可能知道连接处于“上”、“下”、处于“测试”模式或正在被删除（“删除中”）。当连接“关闭”、“测试”或被删除时，OXC可以使用此信息禁止OLS的报警报告。
It is important to note that an OXC may peer with one or more OLSs and an OLS may peer with one or more OXCs. Although there are many similarities between an OXC-OXC LMP session and an OXC-OLS LMP session, particularly for control management and link verification, there are some differences as well. These differences can primarily be attributed to the nature of an OXC-OLS link, and the purpose of OXC-OLS LMP sessions. The OXC-OXC links can be used to provide the basis for GMPLS signaling and routing at the optical layer. The information exchanged over LMP-WDM sessions is used to augment knowledge about the links between OXCs.
需要注意的是，OXC可以与一个或多个OLS对等，而OLS可以与一个或多个OXC对等。虽然OXC-OXC LMP会话和OXC-OLS LMP会话之间有许多相似之处，特别是在控制管理和链路验证方面，但也存在一些差异。这些差异主要归因于OXC-OLS链接的性质以及OXC-OLS LMP会话的目的。OXC-OXC链路可用于为光层的GMPLS信令和路由提供基础。通过LMP-WDM会话交换的信息用于增加有关OXC之间链路的知识。
In order for the information exchanged over the OXC-OLS LMP sessions to be used by the OXC-OXC session, the information must be coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP sessions are run independently and must be maintained separately. One critical requirement when running an OXC-OLS LMP session is the ability of the OLS to make a data link transparent when not doing the verification procedure. This is because the same data link may be verified between OXC-OLS and between OXC-OXC. The verification procedure of LMP is used to coordinate the Test procedure (and hence the transparency/opaqueness of the data links). To maintain independence between the sessions, it must be possible for the LMP sessions to come up in any order. In particular, it must be possible for an OXC-OXC LMP session to come up without an OXC-OLS LMP session being brought up, and vice-versa.
为了让OXC-OXC会话使用通过OXC-OLS LMP会话交换的信息，OXC必须协调这些信息。但是，OXC-OXC和OXC-OLS LMP会话是独立运行的，必须单独维护。运行OXC-OLS LMP会话时的一个关键要求是OLS在不执行验证程序时使数据链路透明的能力。这是因为可以在OXC-OLS之间和OXC-OXC之间验证相同的数据链路。LMP的验证程序用于协调测试程序（以及数据链路的透明度/不透明性）。为了保持会话之间的独立性，LMP会话必须能够以任何顺序出现。特别是，OXC-OXC LMP会话必须能够在不启动OXC-OLS LMP会话的情况下启动，反之亦然。
The GMPLS signaling extends certain base functions of the RSVP-TE and CR-LDP signaling and, in some cases, adds functionality. These changes and additions impact basic LSP properties: how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress.
GMPLS信令扩展了RSVP-TE和CR-LDP信令的某些基本功能，并且在某些情况下增加了功能。这些更改和添加会影响基本LSP属性：标签的请求和通信方式、LSP的单向性、错误的传播方式以及为同步入口和出口提供的信息。
The core GMPLS signaling specification is available in three parts:
核心GMPLS信令规范分为三部分：
1. A signaling functional description [RFC3471]. 2. RSVP-TE extensions [RFC3473]. 3. CR-LDP extensions [RFC3472].
1. 信令功能描述[RFC3471]。2.RSVP-TE扩展[RFC3473]。3.CR-LDP扩展[RFC3472]。
In addition, independent parts are available per technology:
此外，每种技术均提供独立部件：
1. GMPLS extensions for SONET and SDH control [RFC3946]. 2. GMPLS extensions for G.709 control [GMPLS-G709].
1. SONET和SDH控制的GMPLS扩展[RFC3946]。2.G.709控制的GMPLS扩展[GMPLS-G709]。
The following MPLS profile expressed in terms of MPLS features [RFC3031] applies to GMPLS:
以下以MPLS特性[RFC3031]表示的MPLS配置文件适用于GMPLS：
- Downstream-on-demand label allocation and distribution.
- 下游按需标签分配和分发。
- Ingress initiated ordered control.
- 入口启动有序控制。
- Liberal (typical), or conservative (could) label retention mode.
- 自由（典型）或保守（可能）标签保留模式。
- Request, traffic/data, or topology driven label allocation strategy.
- 请求、流量/数据或拓扑驱动的标签分配策略。
- Explicit routing (typical), or hop-by-hop routing.
- 显式路由（典型），或逐跳路由。
The GMPLS signaling defines the following new building blocks on the top of MPLS-TE:
GMPLS信令在MPLS-TE的顶部定义了以下新的构建块：
1. A new generic label request format. 2. Labels for TDM, LSC and FSC interfaces, generically known as Generalized Label. 3. Waveband switching support. 4. Label suggestion by the upstream for optimization purposes (e.g., latency). 5. Label restriction by the upstream to support some optical constraints. 6. Bi-directional LSP establishment with contention resolution. 7. Rapid failure notification extensions. 8. Protection information currently focusing on link protection, plus primary and secondary LSP indication. 9. Explicit routing with explicit label control for a fine degree of control. 10. Specific traffic parameters per technology. 11. LSP administrative status handling. 12. Control channel separation.
1. 一种新的通用标签请求格式。2.TDM、LSC和FSC接口的标签，一般称为通用标签。3.波段切换支持。4.为优化目的（例如，延迟）标记上游的建议。5.标签由上游限制，以支持某些光学约束。6.具有争用解决方案的双向LSP建立。7.快速故障通知扩展。8.保护信息目前主要集中在链路保护，以及主要和次要LSP指示。9带有显式标签控件的显式路由具有良好的控制程度。10每种技术的特定流量参数。11LSP管理状态处理。12控制通道分离。
These building blocks will be described in more details in the following. A complete specification can be found in the corresponding documents.
下面将更详细地描述这些构建块。在相应的文件中可以找到完整的规范。
Note that GMPLS is highly generic and has many options. Only building blocks 1, 2 and 10 are mandatory, and only within the specific format that is needed. Typically, building blocks 6 and 9 should be implemented. Building blocks 3, 4, 5, 7, 8, 11 and 12 are optional.
请注意，GMPLS是高度通用的，有许多选项。只有构建块1、2和10是必需的，并且仅在所需的特定格式内。通常，应实现构建块6和9。构建块3、4、5、7、8、11和12是可选的。
A typical SONET/SDH switching network would implement building blocks: 1, 2 (the SONET/SDH label), 6, 9, 10 and 11. Building blocks 7 and 8 are optional since the protection can be achieved using SONET/SDH overhead bytes.
典型的SONET/SDH交换网络将实现构建块：1、2（SONET/SDH标签）、6、9、10和11。构建块7和8是可选的，因为可以使用SONET/SDH开销字节实现保护。
A typical wavelength switching network would implement building blocks: 1, 2 (the generic format), 4, 5, 6, 7, 8, 9 and 11. Building block 3 is only needed in the particular case of waveband switching.
一个典型的波长交换网络将实现构建块：1、2（通用格式）、4、5、6、7、8、9和11。构建块3仅在波段切换的特殊情况下需要。
A typical fiber switching network would implement building blocks: 1, 2 (the generic format), 6, 7, 8, 9 and 11.
典型的光纤交换网络将实现构建块：1、2（通用格式）、6、7、8、9和11。
A typical MPLS-IP network would not implement any of these building blocks, since the absence of building block 1 would indicate regular MPLS-IP. Note however that building block 1 and 8 can be used to signal MPLS-IP as well. In that case, the MPLS-IP network can benefit from the link protection type (not available in CR-LDP, some very basic form being available in RSVP-TE). Building block 2 is here a regular MPLS label and no new label format is required.
典型的MPLS-IP网络不会实现这些构建块中的任何一个，因为缺少构建块1表示常规MPLS-IP。但是请注意，构建块1和8也可用于向MPLS-IP发送信号。在这种情况下，MPLS-IP网络可以受益于链路保护类型（CR-LDP中不可用，RSVP-TE中有一些非常基本的形式可用）。构建块2在这里是一个常规的MPLS标签，不需要新的标签格式。
GMPLS does not specify any profile for RSVP-TE and CR-LDP implementations that have to support GMPLS - except for what is directly related to GMPLS procedures. It is to the manufacturer to decide which are the optional elements and procedures of RSVP-TE and CR-LDP that need to be implemented. Some optional MPLS-TE elements can be useful for TDM, LSC and FSC layers, for instance the setup and holding priorities that are inherited from MPLS-TE.
GMPLS没有为必须支持GMPLS的RSVP-TE和CR-LDP实现指定任何配置文件-与GMPLS程序直接相关的除外。由制造商决定需要实施的RSVP-TE和CR-LDP的可选元件和程序。一些可选的MPLS-TE元素可用于TDM、LSC和FSC层，例如从MPLS-TE继承的设置和保持优先级。
A TDM, LSC or FSC LSP is established by sending a PATH/Label Request message downstream to the destination. This message contains a Generalized Label Request with the type of LSP (i.e., the layer concerned), and its payload type. An Explicit Route Object (ERO) is also normally added to the message, but this can be added and/or completed by the first/default LSR.
TDM、LSC或FSC LSP通过向目的地下游发送路径/标签请求消息来建立。此消息包含具有LSP类型（即相关层）及其有效负载类型的通用标签请求。显式路由对象（ERO）通常也会添加到消息中，但这可以由第一个/默认LSR添加和/或完成。
The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC object, or in the CR-LDP Traffic Parameters TLV. Specific parameters for a given technology are given in these traffic parameters, such as the type of signal, concatenation and/or transparency for a SONET/SDH LSP. For some other technology there be could just one bandwidth parameter indicating the bandwidth as a floating-point value.
请求的带宽编码在RSVP-TE发送方_TSPEC对象或CR-LDP流量参数TLV中。这些业务参数中给出了给定技术的特定参数，例如SONET/SDH LSP的信号类型、级联和/或透明度。对于其他一些技术，可能只有一个带宽参数将带宽表示为浮点值。
The requested local protection per link may be requested using the Protection Information Object/TLV. The end-to-end LSP protection is for further study and is introduced LSP protection/restoration section (see after).
可以使用保护信息对象/TLV请求每个链路请求的本地保护。端到端LSP保护用于进一步研究，并在LSP保护/恢复部分介绍（见下文）。
If the LSP is a bi-directional LSP, an Upstream Label is also specified in the Path/Label Request message. This label will be the one to use in the upstream direction.
如果LSP是双向LSP，则还将在路径/标签请求消息中指定上游标签。该标签将在上游方向使用。
Additionally, a Suggested Label, a Label Set and a Waveband Label can also be included in the message. Other operations are defined in MPLS-TE.
此外，消息中还可以包括建议的标签、标签集和波段标签。其他操作在MPLS-TE中定义。
The downstream node will send back a Resv/Label Mapping message including one Generalized Label object/TLV that can contain several Generalized Labels. For instance, if a concatenated SONET/SDH signal is requested, several labels can be returned.
下游节点将发回一条Resv/标签映射消息，其中包括一个可包含多个通用标签的通用标签对象/TLV。例如，如果请求连接SONET/SDH信号，则可以返回多个标签。
In case of SONET/SDH virtual concatenation, a list of labels is returned. Each label identifying one element of the virtual concatenated signal. This limits virtual concatenation to remain within a single (component) link.
在SONET/SDH虚拟连接的情况下，返回标签列表。标识虚拟级联信号的一个元素的每个标签。这将虚拟连接限制为保留在单个（组件）链接中。
In case of any type of SONET/SDH contiguous concatenation, only one label is returned. That label is the lowest signal of the contiguous concatenated signal (given an order specified in [RFC3946]).
对于任何类型的SONET/SDH连续级联，只返回一个标签。该标签是连续级联信号的最低信号（给定[RFC3946]中指定的顺序）。
In case of SONET/SDH "multiplication", i.e., co-routing of circuits of the same type but without concatenation but all belonging to the same LSP, the explicit ordered list of all signals that take part in the LSP is returned.
在SONET/SDH“乘法”的情况下，即相同类型但没有串联但都属于同一LSP的电路的共同路由，将返回参与LSP的所有信号的显式有序列表。
The Generalized Label Request is a new object/TLV to be added in an RSVP-TE Path message instead of the regular Label Request, or in a CR-LDP Request message in addition to the already existing TLVs. Only one label request can be used per message, so a single LSP can be requested at a time per signaling message.
通用标签请求是要添加到RSVP-TE路径消息中的新对象/TLV，而不是常规标签请求，或添加到CR-LDP请求消息中的现有TLV之外的新对象/TLV。每个消息只能使用一个标签请求，因此每个信令消息一次只能请求一个LSP。
The Generalized Label Request gives three major characteristics (parameters) required to support the LSP being requested: the LSP Encoding Type, the Switching Type that must be used and the LSP payload type called Generalized PID (G-PID).
通用标签请求提供了支持所请求的LSP所需的三个主要特征（参数）：LSP编码类型、必须使用的切换类型和称为通用PID（G-PID）的LSP有效负载类型。
The LSP Encoding Type indicates the encoding type that will be used with the data associated with the LSP, i.e., the type of technology being considered. For instance, it can be SDH, SONET, Ethernet, ANSI PDH, etc. It represents the nature of the LSP, and not the nature of the links that the LSP traverses. This is used hop-by-hop by each node.
LSP编码类型指示将与LSP相关联的数据一起使用的编码类型，即所考虑的技术类型。例如，它可以是SDH、SONET、以太网、ANSI PDH等。它代表LSP的性质，而不是LSP所经过链路的性质。每个节点都会逐跳使用它。
A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats. The Switching Type indicates then the type of switching that should be performed on a particular link for that LSP. This information is needed for links that advertise more than one type of switching capability.
链路可以支持一组编码格式，其中支持意味着链路能够携带和切换这些编码格式中的一种或多种的信号。切换类型指示应在该LSP的特定链路上执行的切换类型。对于宣传多种类型交换能力的链路，需要此信息。
Nodes must verify that the type indicated in the Switching Type is supported on the corresponding incoming interface; otherwise, the node must generate a notification message with a "Routing problem/Switching Type" indication.
节点必须验证交换类型中指示的类型在相应的传入接口上受支持；否则，节点必须生成带有“路由问题/交换类型”指示的通知消息。
The LSP payload type (G-PID) identifies the payload carried by the LSP, i.e., an identifier of the client layer of that LSP. For some technologies, it also indicates the mapping used by the client layer, e.g., byte synchronous mapping of E1. This must be interpreted according to the LSP encoding type and is used by the nodes at the endpoints of the LSP to know to which client layer a request is destined, and in some cases by the penultimate hop.
LSP有效负载类型（G-PID）标识LSP承载的有效负载，即该LSP的客户端层的标识符。对于某些技术，它还指示客户端层使用的映射，例如E1的字节同步映射。这必须根据LSP编码类型进行解释，并由LSP端点处的节点使用，以了解请求将发送到哪个客户机层，在某些情况下，还可由倒数第二个跃点使用。
Other technology specific parameters are not transported in the Generalized Label Request but in technology specific traffic parameters as explained hereafter. Currently, two set of traffic parameters are defined, one for SONET/SDH and one for G.709.
其他特定于技术的参数不在通用标签请求中传输，而是在特定于技术的流量参数中传输，如下所述。目前，定义了两组流量参数，一组用于SONET/SDH，另一组用于G.709。
Note that it is expected than specific traffic parameters will be defined in the future for photonic (all optical) switching.
请注意，预计未来将为光子（全光）交换定义特定的业务参数。
The GMPLS SONET/SDH traffic parameters [RFC3946] specify a powerful set of capabilities for SONET [ANSI-T1.105] and SDH [ITUT-G.707].
GMPLS SONET/SDH流量参数[RFC3946]为SONET[ANSI-T1.105]和SDH[ITUT-G.707]指定了一组强大的功能。
The first traffic parameter specifies the type of the elementary SONET/SDH signal that comprises the requested LSP, e.g., VC-11, VT6, VC-4, STS-3c, etc. Several transforms can then be applied successively on the elementary Signal to build the final signal being actually requested for the LSP.
第一个业务参数指定基本SONET/SDH信号的类型，该信号包括所请求的LSP，例如VC-11、VT6、VC-4、STS-3c等。然后，可以在基本信号上连续应用若干变换，以构建实际为LSP请求的最终信号。
These transforms are the contiguous concatenation, the virtual concatenation, the transparency and the multiplication. Each one is optional. They must be applied strictly in the following order:
这些变换是连续连接、虚拟连接、透明和乘法。每一个都是可选的。必须严格按照以下顺序进行应用：
- First, contiguous concatenation can be optionally applied on the Elementary Signal, resulting in a contiguously concatenated signal.
- 首先，可以选择性地对基本信号应用连续级联，从而产生连续级联信号。
- Second, virtual concatenation can be optionally applied either directly on the elementary Signal, or on the contiguously concatenated signal obtained from the previous phase.
- 第二，虚拟级联可以选择性地直接应用于基本信号，或者应用于从前一相位获得的连续级联信号。
- Third, some transparency can be optionally specified when requesting a frame as signal rather than a container. Several transparency packages are defined.
- 第三，当请求帧作为信号而不是容器时，可以选择指定一些透明度。定义了几个透明包。
- Fourth, a multiplication can be optionally applied either directly on the elementary Signal, or on the contiguously concatenated signal obtained from the first phase, or on the virtually concatenated signal obtained from the second phase, or on these signals combined with some transparency.
- 第四，乘法可以选择性地直接应用于基本信号，或者应用于从第一相位获得的连续级联信号，或者应用于从第二相位获得的虚拟级联信号，或者应用于结合了某种透明度的这些信号。
For RSVP-TE, the SONET/SDH traffic parameters are carried in a new SENDER_TSPEC and FLOWSPEC. The same format is used for both. There is no Adspec associated with the SENDER_TSPEC, it is omitted or a default value is used. The content of the FLOWSPEC object received in a Resv message should be identical to the content of the SENDER_TSPEC of the corresponding Path message. In other words, the receiver is normally not allowed to change the values of the traffic parameters. However, some level of negotiation may be achieved as explained in [RFC3946].
对于RSVP-TE，SONET/SDH流量参数在新的发送方规范和流量规范中进行传输。两者使用相同的格式。没有与发送方\u TSPEC关联的Adspec，将忽略它或使用默认值。在Resv消息中接收的FLOWSPEC对象的内容应与相应路径消息的发送方_TSPEC的内容相同。换句话说，通常不允许接收器更改流量参数的值。但是，如[RFC3946]中所述，可以实现某种程度的协商。
For CR-LDP, the SONET/SDH traffic parameters are simply carried in a new TLV.
对于CR-LDP，SONET/SDH业务参数仅在新的TLV中携带。
Note that a general discussion on SONET/SDH and GMPLS can be found in [SONET-SDH-GMPLS-FRM].
请注意，有关SONET/SDH和GMPLS的一般性讨论可在[SONET-SDH-GMPLS-FRM]中找到。
Simply said, an [ITUT-G.709] based network is decomposed in two major layers: an optical layer (i.e., made of wavelengths) and a digital layer. These two layers are divided into sub-layers and switching occurs at two specific sub-layers: at the OCh (Optical Channel) optical layer and at the ODU (Optical channel Data Unit) electrical layer. The ODUk notation is used to denote ODUs at different bandwidths.
简单地说，基于[ITUT-G.709]的网络分为两个主要层：光学层（即，由波长组成）和数字层。这两个层被划分为子层，交换发生在两个特定的子层：OCh（光信道）光层和ODU（光信道数据单元）电层。ODUk符号用于表示不同带宽的ODU。
The GMPLS G.709 traffic parameters [GMPLS-G709] specify a powerful set of capabilities for ITU-T G.709 networks.
GMPLS G.709流量参数[GMPLS-G709]为ITU-T G.709网络指定了一组强大的功能。
The first traffic parameter specifies the type of the elementary G.709 signal that comprises the requested LSP, e.g., ODU1, OCh at 40 Gbps, etc. Several transforms can then be applied successively on the elementary Signal to build the final signal being actually requested for the LSP.
第一个业务参数指定基本G.709信号的类型，该信号包括所请求的LSP，例如ODU1、40 Gbps的OCh等。然后可以对基本信号连续应用多个变换，以构建实际为LSP请求的最终信号。
These transforms are the virtual concatenation and the multiplication. Each one of these transforms is optional. They must be applied strictly in the following order:
这些变换是虚拟级联和乘法。这些转换中的每一个都是可选的。必须严格按照以下顺序进行应用：
- First, virtual concatenation can be optionally applied directly on the elementary Signal,
- 首先，虚拟级联可以选择性地直接应用于基本信号，
- Second, a multiplication can be optionally applied, either directly on the elementary Signal, or on the virtually concatenated signal obtained from the first phase.
- 第二，乘法可以选择性地应用，或者直接应用于基本信号，或者应用于从第一相位获得的虚拟级联信号。
Additional ODUk Multiplexing traffic parameters allow indicating an ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request. G.709 supports the following multiplexing capabilities: ODUj into ODUk (k > j) and ODU1 with ODU2 multiplexing into ODU3.
附加的ODUk多路复用流量参数允许为ODUk多路复用LSP请求指示ODUk映射（ODUj到ODUk）。G.709支持以下多路复用功能：ODUj到ODUk（k>j）和ODU1与ODU2多路复用到ODU3。
For RSVP-TE, the G.709 traffic parameters are carried in a new SENDER-TSPEC and FLOWSPEC. The same format is used for both. There is no Adspec associated with the SENDER_TSPEC, it is omitted or a default value is used. The content of the FLOWSPEC object received in a Resv message should be identical to the content of the SENDER_TSPEC of the corresponding Path message.
对于RSVP-TE，G.709流量参数在新的SENDER-TSPEC和FLOWSPEC中携带。两者使用相同的格式。没有与发送方\u TSPEC关联的Adspec，将忽略它或使用默认值。在Resv消息中接收的FLOWSPEC对象的内容应与相应路径消息的发送方_TSPEC的内容相同。
For CR-LDP, the G.709 traffic parameters are simply carried in a new TLV.
对于CR-LDP，G.709流量参数仅在新的TLV中携带。
Some technologies that do not have (yet) specific traffic parameters just require a bandwidth encoding transported in a generic form. Bandwidth is carried in 32-bit number in IEEE floating-point format (the unit is bytes per second). Values are carried in a per protocol specific manner. For non-packet LSPs, it is useful to define discrete values to identify the bandwidth of the LSP.
一些没有（尚未）特定流量参数的技术只需要以通用形式传输带宽编码。带宽以32位的IEEE浮点格式传输（单位为字节/秒）。值按照协议特定的方式进行传输。对于非分组LSP，定义离散值以识别LSP的带宽是有用的。
It should be noted that this bandwidth encoding do not apply to SONET/SDH and G.709, for which the traffic parameters fully define the requested SONET/SDH or G.709 signal.
应该注意，这种带宽编码不适用于SONET/SDH和G.709，对于它们，业务参数完全定义了请求的SONET/SDH或G.709信号。
The bandwidth is coded in the Peak Data Rate field of Int-Serv objects for RSVP-TE in the SENDER_TSPEC and FLOWSPEC objects and in the Peak and Committed Data Rate fields of the CR-LDP Traffic Parameters TLV.
带宽编码在发送方_TSPEC和FLOWSPEC对象中RSVP-TE的Int Serv对象的峰值数据速率字段中，以及CR-LDP流量参数TLV的峰值和提交数据速率字段中。
The Generalized Label extends the traditional MPLS label by allowing the representation of not only labels that travel in-band with associated data packets, but also (virtual) labels that identify time-slots, wavelengths, or space division multiplexed positions.
通用标签扩展了传统的MPLS标签，它不仅允许表示与相关数据分组一起在频带中传输的标签，而且还允许表示标识时隙、波长或空分复用位置的（虚拟）标签。
For example, the Generalized Label may identify (a) a single fiber in a bundle, (b) a single waveband within fiber, (c) a single wavelength within a waveband (or fiber), or (d) a set of time-slots within a wavelength (or fiber). It may also be a generic MPLS label, a Frame Relay label, or an ATM label (VCI/VPI). The format of a label can be as simple as an integer value such as a wavelength label or can be more elaborated such as an SONET/SDH or a G.709 label.
例如，通用标签可识别（a）束中的单个光纤，（b）光纤中的单个波段，（c）波段（或光纤）中的单个波长，或（d）波长（或光纤）中的一组时隙。它也可以是通用MPLS标签、帧中继标签或ATM标签（VCI/VPI）。标签的格式可以简单到整数值，如波长标签，也可以更详细，如SONET/SDH或G.709标签。
SDH and SONET define each a multiplexing structure. These multiplexing structures will be used as naming trees to create unique labels. Such a label will identify the exact position (times-lot(s)) of a signal in a multiplexing structure. Since the SONET multiplexing structure may be seen as a subset of the SDH multiplexing structure, the same format of label is used for SDH and SONET. A similar concept is applied to build a label at the G.709 ODU layer.
SDH和SONET各自定义了一种多路复用结构。这些多路复用结构将用作命名树，以创建唯一的标签。这样的标签将识别复用结构中信号的准确位置（时隙）。由于SONET复用结构可视为SDH复用结构的子集，因此SDH和SONET使用相同格式的标签。在G.709 ODU层构建标签时采用了类似的概念。
Since the nodes sending and receiving the Generalized Label know what kinds of link they are using, the Generalized Label does not identify its type. Instead, the nodes are expected to know from the context what type of label to expect.
由于发送和接收通用标签的节点知道它们使用的链接类型，因此通用标签不标识其类型。相反，节点应该从上下文中知道所期望的标签类型。
A Generalized Label only carries a single level of label i.e., it is non-hierarchical. When multiple levels of labels (LSPs within LSPs) are required, each LSP must be established separately.
通用标签只包含一个标签级别，即它是非层次的。当需要多个级别的标签（LSP中的LSP）时，必须分别建立每个LSP。
A special case of wavelength switching is waveband switching. A waveband represents a set of contiguous wavelengths, which can be switched together to a new waveband. For optimization reasons, it may be desirable for a photonic cross-connect to optically switch multiple wavelengths as a unit. This may reduce the distortion on the individual wavelengths and may allow tighter separation of the individual wavelengths. A Waveband label is defined to support this special case.
波长切换的一种特殊情况是波段切换。一个波段代表一组连续的波长，这些波长可以一起切换到一个新的波段。出于优化原因，可能希望光子交叉连接以光学方式切换多个波长作为一个单元。这可以减少各个波长上的失真，并且可以允许更紧密地分离各个波长。定义了一个波段标签来支持这种特殊情况。
Waveband switching naturally introduces another level of label hierarchy and as such the waveband is treated the same way, all other upper layer labels are treated. As far as the MPLS protocols are concerned, there is little difference between a waveband label and a
波段切换自然引入了标签层次的另一个层次，因此，波段的处理方式与所有其他上层标签的处理方式相同。就MPLS协议而言，波段标签和标签之间几乎没有区别
wavelength label. Exception is that semantically the waveband can be subdivided into wavelengths whereas the wavelength can only be subdivided into time or statistically multiplexed labels.
波长标签。例外情况是，在语义上，波段可以细分为波长，而波长只能细分为时间或统计复用标签。
In the context of waveband switching, the generalized label used to indicate a waveband contains three fields, a waveband ID, a Start Label and an End Label. The Start and End Labels are channel identifiers from the sender perspective that identify respectively, the lowest value wavelength and the highest value wavelength making up the waveband.
在波段切换的上下文中，用于指示波段的通用标签包含三个字段：波段ID、开始标签和结束标签。开始和结束标签是从发送方的角度来看的信道标识符，分别标识构成波段的最低值波长和最高值波长。
GMPLS allows for a label to be optionally suggested by an upstream node. This suggestion may be overridden by a downstream node but in some cases, at the cost of higher LSP setup time. The suggested label is valuable when establishing LSPs through certain kinds of optical equipment where there may be a lengthy (in electrical terms) delay in configuring the switching fabric. For example, micro mirrors may have to be elevated or moved, and this physical motion and subsequent damping takes time. If the labels and hence switching fabric are configured in the reverse direction (the norm), the Resv/MAPPING message may need to be delayed by 10's of milliseconds per hop in order to establish a usable forwarding path. It can be important for restoration purposes where alternate LSPs may need to be rapidly established as a result of network failures.
GMPLS允许上游节点选择性地建议标签。此建议可能会被下游节点覆盖，但在某些情况下，以较高的LSP设置时间为代价。当通过某些类型的光学设备建立LSP时，建议的标签很有价值，因为在配置交换结构时可能会有很长的（电气方面的）延迟。例如，微镜可能必须升高或移动，而这种物理运动和随后的阻尼需要时间。如果标签和交换结构以相反的方向（标准）配置，则Resv/MAPPING消息可能需要每跳延迟10毫秒，以便建立可用的转发路径。这对于恢复目的非常重要，因为由于网络故障，可能需要快速建立备用LSP。
An upstream node can optionally restrict (limit) the choice of label of a downstream node to a set of acceptable labels. Giving lists and/or ranges of inclusive (acceptable) or exclusive (unacceptable) labels in a Label Set provides this restriction. If not applied, all labels from the valid label range may be used. There are at least four cases where a label restriction is useful in the "optical" domain.
上游节点可以选择性地将下游节点的标签选择限制（限制）为一组可接受的标签。在标签集中给出包含（可接受）或排除（不可接受）标签的列表和/或范围提供了此限制。如果未应用，则可以使用有效标签范围内的所有标签。至少有四种情况下，标签限制在“光学”领域中有用。
Case 1: the end equipment is only capable of transmitting and receiving on a small specific set of wavelengths/wavebands.
情况1：终端设备只能在一小组特定的波长/波段上进行发射和接收。
Case 2: there is a sequence of interfaces, which cannot support wavelength conversion and require the same wavelength be used end-to-end over a sequence of hops, or even an entire path.
情况2：存在一系列接口，这些接口不支持波长转换，并且要求在一系列跃点上，甚至在整个路径上，端到端使用相同的波长。
Case 3: it is desirable to limit the amount of wavelength conversion being performed to reduce the distortion on the optical signals.
情况3：希望限制正在执行的波长转换量以减少光信号上的失真。
Case 4: two ends of a link support different sets of wavelengths.
情况4：链路的两端支持不同的波长组。
The receiver of a Label Set must restrict its choice of labels to one that is in the Label Set. A Label Set may be present across multiple hops. In this case, each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities. This case is expected to be the norm for nodes with conversion incapable interfaces.
标签集的接收者必须将其标签选择限制为标签集中的标签。标签集可以跨多个跃点出现。在这种情况下，每个节点生成自己的传出标签集，可能基于传入标签集和节点的硬件功能。这种情况预计将成为具有无法转换接口的节点的标准情况。
GMPLS allows establishment of bi-directional symmetric LSPs (not of asymmetric LSPs). A symmetric bi-directional LSP has the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, and resource requirements (e.g., latency and jitter) in each direction.
GMPLS允许建立双向对称LSP（而不是不对称LSP）。对称双向LSP具有相同的流量工程需求，包括命运共享、保护和恢复、LSR以及每个方向上的资源需求（例如延迟和抖动）。
In the remainder of this section, the term "initiator" is used to refer to a node that starts the establishment of an LSP; the term "terminator" is used to refer to the node that is the target of the LSP. For a bi-directional LSPs, there is only one initiator and one terminator.
在本节的其余部分中，术语“发起方”用于指开始建立LSP的节点；术语“终止符”用于指作为LSP的目标的节点。对于双向LSP，只有一个启动器和一个终止器。
Normally to establish a bi-directional LSP when using RSVP-TE [RFC3209] or CR-LDP [RFC3212] two unidirectional paths must be independently established. This approach has the following disadvantages:
通常，在使用RSVP-TE[RFC3209]或CR-LDP[RFC3212]时，为了建立双向LSP，必须独立地建立两条单向路径。这种方法有以下缺点：
1. The latency to establish the bi-directional LSP is equal to one round trip signaling time plus one initiator-terminator signaling transit delay. This not only extends the setup latency for successful LSP establishment, but it extends the worst-case latency for discovering an unsuccessful LSP to as much as two times the initiator-terminator transit delay. These delays are particularly significant for LSPs that are established for restoration purposes.
1. 建立双向LSP的延迟等于一个往返信令时间加上一个启动器终止器信令传输延迟。这不仅延长了成功建立LSP的设置延迟，而且还将发现不成功LSP的最坏情况延迟延长到启动器-终止器传输延迟的两倍。这些延迟对于为恢复目的而建立的LSP尤其重要。
2. The control overhead is twice that of a unidirectional LSP. This is because separate control messages (e.g., Path and Resv) must be generated for both segments of the bi-directional LSP.
2. 控制开销是单向LSP的两倍。这是因为必须为双向LSP的两个段生成单独的控制消息（例如，Path和Resv）。
3. Because the resources are established in separate segments, route selection is complicated. There is also additional potential race for conditions in assignment of resources, which decreases the overall probability of successfully establishing the bi-directional connection.
3. 由于资源建立在不同的路段上，因此路线选择非常复杂。在资源分配中，还存在其他潜在的条件竞争，这降低了成功建立双向连接的总体概率。
4. It is more difficult to provide a clean interface for SONET/SDH equipment that may rely on bi-directional hop-by-hop paths for protection switching. Note that existing SONET/SDH equipment transmits the control information in-band with the data.
4. 为SONET/SDH设备提供干净的接口更加困难，因为SONET/SDH设备可能依赖双向逐跳路径进行保护切换。请注意，现有SONET/SDH设备在带内与数据一起传输控制信息。
5. Bi-directional optical LSPs (or lightpaths) are seen as a requirement for many optical networking service providers.
5. 双向光LSP（或光路）被视为许多光网络服务提供商的需求。
With bi-directional LSPs both the downstream and upstream data paths, i.e., from initiator to terminator and terminator to initiator, are established using a single set of signaling messages. This reduces the setup latency to essentially one initiator-terminator round trip time plus processing time, and limits the control overhead to the same number of messages as a unidirectional LSP.
使用双向LSP，使用一组信令消息建立下游和上游数据路径，即从启动器到终端以及终端到启动器。这将设置延迟减少到一个启动器-终止器往返时间加上处理时间，并将控制开销限制为与单向LSP相同的消息数。
For bi-directional LSPs, two labels must be allocated. Bi-directional LSP setup is indicated by the presence of an Upstream Label in the appropriate signaling message.
对于双向LSP，必须分配两个标签。双向LSP设置通过在适当的信令消息中存在上游标签来指示。
Contention for labels may occur between two bi-directional LSP setup requests traveling in opposite directions. This contention occurs when both sides allocate the same resources (ports) at effectively the same time. GMPLS signaling defines a procedure to resolve that contention: the node with the higher node ID will win the contention. To reduce the probability of contention, some mechanisms are also suggested.
标签争用可能发生在两个相反方向的双向LSP设置请求之间。当双方同时有效地分配相同的资源（端口）时，就会发生这种争用。GMPLS信令定义了一个解决争用的过程：具有较高节点ID的节点将赢得争用。为了降低争用概率，还提出了一些机制。
GMPLS defines several signaling extensions that enable expedited notification of failures and other events to nodes responsible for restoring failed LSPs, and error handling.
GMPLS定义了几个信令扩展，可以向负责恢复故障LSP和错误处理的节点快速通知故障和其他事件。
1. Acceptable Label Set for notification on Label Error:
1. 标签错误通知的可接受标签集：
There are cases in traditional MPLS and in GMPLS that result in an error message containing an "Unacceptable label value" indication. When these cases occur, it can useful for the node generating the error message to indicate which labels would be acceptable. To cover this case, GMPLS introduces the ability to convey such information via the "Acceptable Label Set". An Acceptable Label Set is carried in appropriate protocol specific error messages. The format of an Acceptable Label Set is identical to a Label Set.
在传统的MPLS和GMPLS中存在导致错误消息包含“不可接受的标签值”指示的情况。当出现这些情况时，生成错误消息的节点可以指示哪些标签是可接受的。为了解决这种情况，GMPLS引入了通过“可接受标签集”传达此类信息的能力。可接受的标签集包含在相应的特定于协议的错误消息中。可接受标签集的格式与标签集的格式相同。
2. Expedited notification:
2. 加急通知：
Extensions to RSVP-TE enable expedited notification of failures and other events to determined nodes. For CR-LDP, there is not currently a similar mechanism. The first extension identifies where event notifications are to be sent. The second provides for general expedited event notification with a Notify message. Such extensions can be used by fast restoration mechanisms. Notifications may be requested in both the upstream and downstream directions.
对RSVP-TE的扩展支持向确定的节点快速通知故障和其他事件。对于CR-LDP，目前还没有类似的机制。第一个扩展标识要发送事件通知的位置。第二种方法提供带有通知消息的一般快速事件通知。快速恢复机制可以使用这种扩展。可在上游和下游方向请求通知。
The Notify message is a generalized notification mechanism that differs from the currently defined error messages in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor. The Notify message does not replace existing error messages. The Notify message may be sent either (a) normally, where non-target nodes just forward the Notify message to the target node, similar to ResvConf processing in [RFC2205]; or (b) encapsulated in a new IP header whose destination is equal to the target IP address.
Notify消息是一种通用的通知机制，与当前定义的错误消息不同，它可以“定向”到除直接上游或下游邻居之外的节点。通知消息不会替换现有的错误消息。通知消息可以（a）正常发送，其中非目标节点只是将通知消息转发给目标节点，类似于[RFC2205]中的ResvConf处理；或者（b）封装在目的地等于目标IP地址的新IP报头中。
3. Faster removal of intermediate states:
3. 更快地消除中间状态：
A specific RSVP optimization allowing in some cases the faster removal of intermediate states. This extension is used to deal with specific RSVP mechanisms.
特定的RSVP优化，在某些情况下允许更快地去除中间状态。此扩展用于处理特定的RSVP机制。
Protection information is carried in the new optional Protection Information Object/TLV. It currently indicates the desired link protection for each link of an LSP. If a particular protection type, i.e., 1+1, or 1:N, is requested, then a connection request is processed only if the desired protection type can be honored. Note that GMPLS advertises the protection capabilities of a link in the routing protocols. Path computation algorithms may consider this information when computing paths for setting up LSPs.
保护信息携带在新的可选保护信息对象/TLV中。它当前指示LSP的每个链路所需的链路保护。如果请求特定的保护类型，即1+1或1:N，则仅当可以满足所需的保护类型时，才会处理连接请求。注意，GMPLS在路由协议中宣传链路的保护能力。路径计算算法可以在计算用于建立LSP的路径时考虑此信息。
Protection information also indicates if the LSP is a primary or secondary LSP. A secondary LSP is a backup to a primary LSP. The resources of a secondary LSP are normally not used until the primary LSP fails, but they may be used by other LSPs until the primary LSP fails over the secondary LSP. At that point, any LSP that is using the resources for the secondary LSP must be preempted.
保护信息还指示LSP是主LSP还是辅助LSP。辅助LSP是主LSP的备份。辅助LSP的资源通常在主LSP发生故障之前不使用，但在主LSP通过辅助LSP发生故障之前，其他LSP可能会使用这些资源。此时，任何正在使用辅助LSP资源的LSP都必须被抢占。
Six link protection types are currently defined as individual flags and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared, unprotected, extra traffic. See [RFC3471] section 7.1 for a precise definition of each.
目前有六种链路保护类型被定义为单独的标志，可以组合使用：增强型、专用1+1、专用1:1、共享型、无保护型、额外流量。请参见[RFC3471]第7.1节，了解每种类型的精确定义。
By using an explicit route, the path taken by an LSP can be controlled more or less precisely. Typically, the node at the head-end of an LSP finds an explicit route and builds an Explicit Route Object (ERO)/ Explicit Route (ER) TLV that contains that route. Possibly, the edge node does not build any explicit route, and just transmit a signaling request to a default neighbor LSR (as IP/MPLS hosts would). For instance, an explicit route could be added to a signaling message by the first switching node, on behalf of the edge node. Note also that an explicit route is altered by intermediate LSRs during its progression towards the destination.
通过使用显式路由，可以或多或少精确地控制LSP所采用的路径。通常，LSP前端的节点查找显式路由，并构建包含该路由的显式路由对象（ERO）/显式路由（ER）TLV。边缘节点可能不构建任何显式路由，而只是将信令请求发送到默认的邻居LSR（就像IP/MPLS主机那样）。例如，第一交换节点可以代表边缘节点向信令消息添加显式路由。还要注意的是，在向目的地行进的过程中，中间LSR会改变显式路由。
The explicit route is originally defined by MPLS-TE as a list of abstract nodes (i.e., groups of nodes) along the explicit route. Each abstract node can be an IPv4 address prefix, an IPv6 address prefix, or an AS number. This capability allows the generator of the explicit route to have incomplete information about the details of the path. In the simplest case, an abstract node can be a full IP address (32 bits) that identifies a specific node (called a simple abstract node).
显式路由最初由MPLS-TE定义为沿着显式路由的抽象节点（即节点组）列表。每个抽象节点可以是IPv4地址前缀、IPv6地址前缀或AS编号。此功能允许显式路由的生成器具有关于路径详细信息的不完整信息。在最简单的情况下，抽象节点可以是标识特定节点（称为简单抽象节点）的完整IP地址（32位）。
MPLS-TE allows strict and loose abstract nodes. The path between a strict node and its preceding node must include only network nodes from the strict node and its preceding abstract node. The path between a loose node and its preceding abstract node may include other network nodes that are not part of the loose node or its preceding abstract node.
MPLS-TE允许严格和松散的抽象节点。严格节点及其前一个节点之间的路径必须仅包括严格节点及其前一个抽象节点中的网络节点。松散节点与其先前抽象节点之间的路径可以包括不属于松散节点或其先前抽象节点的其他网络节点。
This explicit route was extended to include interface numbers as abstract nodes to support unnumbered interfaces; and further extended by GMPLS to include labels as abstract nodes. Having labels in an explicit route is an important feature that allows controlling the placement of an LSP with a very fine granularity. This is more likely to be used for TDM, LSC and FSC links.
该显式路由被扩展为包括作为抽象节点的接口编号，以支持未编号的接口；GMPLS进一步扩展，将标签作为抽象节点。在显式路由中具有标签是一项重要功能，它允许以非常精细的粒度控制LSP的放置。这更可能用于TDM、LSC和FSC链路。
In particular, the explicit label control in the explicit route allows terminating an LSP on a particular outgoing port of an egress node. Indeed, a label sub-object/TLV must follow a sub-object/TLV containing the IP address, or the interface identifier (in case of unnumbered interface), associated with the link on which it is to be used.
具体而言，显式路由中的显式标签控制允许在出口节点的特定出站端口上终止LSP。事实上，标签子对象/TLV必须跟在包含IP地址或接口标识符（在接口未编号的情况下）的子对象/TLV后面，该标识符与要使用它的链接相关联。
This can also be used when it is desirable to "splice" two LSPs together, i.e., where the tail of the first LSP would be "spliced" into the head of the second LSP.
当希望将两个LSP“拼接”在一起时，也可以使用该方法，即，第一个LSP的尾部将“拼接”到第二个LSP的头部。
When used together with an optimization algorithm, it can provide very detailed explicit routes, including the label (timeslot) to use on a link, in order to minimize the fragmentation of the SONET/SDH multiplex on the corresponding interface.
当与优化算法一起使用时，它可以提供非常详细的显式路由，包括要在链路上使用的标签（时隙），以最小化相应接口上SONET/SDH多路复用的碎片。
In order to improve the reliability and the manageability of the LSP being established, the concept of the route recording was introduced in RSVP-TE to function as:
为了提高正在建立的LSP的可靠性和可管理性，RSVP-TE中引入了路由记录的概念，其功能如下：
- First, a loop detection mechanism to discover L3 routing loops, or loops inherent in the explicit route (this mechanism is strictly exclusive with the use of explicit routing objects).
- 首先，一种循环检测机制，用于发现L3路由循环，或显式路由中固有的循环（该机制严格排除使用显式路由对象）。
- Second, a route recording mechanism collects up-to-date detailed path information on a hop-by-hop basis during the LSP setup process. This mechanism provides valuable information to the source and destination nodes. Any intermediate routing change at setup time, in case of loose explicit routing, will be reported.
- 其次，路由记录机制在LSP设置过程中逐跳收集最新的详细路径信息。此机制为源节点和目标节点提供有价值的信息。如果显式路由松散，将报告设置时的任何中间路由更改。
- Third, a recorded route can be used as input for an explicit route. This is useful if a source node receives the recorded route from a destination node and applies it as an explicit route in order to "pin down the path".
- 第三，记录的路由可以用作显式路由的输入。如果源节点从目标节点接收到记录的路由，并将其作为显式路由应用，以便“锁定路径”，则此功能非常有用。
Within the GMPLS architecture, only the second and third functions are mainly applicable for TDM, LSC and FSC layers.
在GMPLS架构中，只有第二和第三个功能主要适用于TDM、LSC和FSC层。
LSP modification and re-routing are two features already available in MPLS-TE. GMPLS does not add anything new. Elegant re-routing is possible with the concept of "make-before-break" whereby an old path is still used while a new path is set up by avoiding double reservation of resources. Then, the node performing the re-routing can swap on the new path and close the old path. This feature is supported with RSVP-TE (using shared explicit filters) and CR-LDP (using the action indicator flag).
LSP修改和重路由是MPLS-TE中已有的两个功能。GMPLS没有添加任何新内容。通过“先通后断”的概念，优雅的重新路由是可能的，即旧路径仍在使用，而新路径通过避免资源的双重保留而建立。然后，执行重新路由的节点可以在新路径上交换并关闭旧路径。RSVP-TE（使用共享显式过滤器）和CR-LDP（使用动作指示器标志）支持此功能。
LSP modification consists in changing some LSP parameters, but normally without changing the route. It is supported using the same mechanism as re-routing. However, the semantic of LSP modification will differ from one technology to the other. For instance, further
LSP修改包括更改某些LSP参数，但通常不更改路由。使用与重新路由相同的机制来支持它。然而，LSP修改的语义在不同的技术中会有所不同。例如，进一步
studies are required to understand the impact of dynamically changing some SONET/SDH circuit characteristics such as the bandwidth, the protection type, the transparency, the concatenation, etc.
需要研究动态改变某些SONET/SDH电路特性的影响，如带宽、保护类型、透明度、级联等。
GMPLS provides the optional capability to indicate the administrative status of an LSP by using a new Admin Status object/TLV. Administrative Status information is currently used in two ways.
GMPLS提供可选功能，通过使用新的管理状态对象/TLV指示LSP的管理状态。管理状态信息目前有两种使用方式。
In the first usage, the Admin Status object/TLV is carried in a Path/Label Request or Resv/Label Mapping message to indicate the administrative state of an LSP. In this usage, Administrative Status information indicates the state of the LSP, which include "up" or "down", if it in a "testing" mode, and if deletion is in progress.
在第一种用法中，Admin Status对象/TLV携带在路径/标签请求或Resv/标签映射消息中，以指示LSP的管理状态。在这种用法中，管理状态信息指示LSP的状态，其中包括“向上”或“向下”，如果它处于“测试”模式，并且如果正在删除。
Based on that administrative status, a node can take local decisions, like inhibit alarm reporting when an LSP is in "down" or "testing" states, or report alarms associated with the connection at a priority equal to or less than "Non service affecting".
基于该管理状态，节点可以作出本地决定，例如当LSP处于“关闭”或“测试”状态时禁止报警报告，或者以等于或小于“不影响服务”的优先级报告与连接相关的报警。
It is possible that some nodes along an LSP will not support the Admin Status Object/TLV. In the case of a non-supporting transit node, the object will pass through the node unmodified and normal processing can continue.
LSP上的某些节点可能不支持Admin Status对象/TLV。在不支持传输节点的情况下，对象将在未修改的情况下通过该节点，并且可以继续正常处理。
In some circumstances, particularly optical networks, it is useful to set the administrative status of an LSP to "being deleted" before tearing it down in order to avoid non-useful generation of alarms. The ingress LSR precedes an LSP deletion by inserting an appropriate Admin Status Object/TLV in a Path/Label Request (with the modification action indicator flag set to modify) message. Transit LSRs process the Admin Status Object/TLV and forward it. The egress LSR answers in a Resv/Label Mapping (with the modification action indicator flag set to modify) message with the Admin Status object. Upon receiving this message and object, the ingress node sends a PathTear/Release message downstream to remove the LSP and normal RSVP-TE/CR-LDP processing takes place.
在某些情况下，尤其是在光纤网络中，在拆卸LSP之前将其管理状态设置为“正在删除”是很有用的，以避免产生无用的警报。入口LSR通过在路径/标签请求（修改操作指示器标志设置为修改）消息中插入适当的管理状态对象/TLV，先于LSP删除。传输LSR处理管理状态对象/TLV并转发它。出口LSR在带有Admin Status对象的Resv/标签映射（修改操作指示器标志设置为modify）消息中应答。在接收到该消息和对象后，入口节点向下游发送Path撕裂/释放消息以移除LSP，并进行正常的RSVP-TE/CR-LDP处理。
In the second usage, the Admin Status object/TLV is carried in a Notification/Label Mapping (with the modification action indicator flag set to modify) message to request that the ingress node change the administrative state of an LSP. This allows intermediate and egress nodes triggering the setting of administrative status. In particular, this allows intermediate or egress LSRs requesting a release of an LSP initiated by the ingress node.
在第二种用法中，在通知/标签映射（修改操作指示符标志设置为modify）消息中携带管理状态对象/TLV，以请求入口节点更改LSP的管理状态。这允许中间和出口节点触发管理状态的设置。具体而言，这允许中间或出口lsr请求由入口节点发起的LSP的释放。
In GMPLS, a control channel be separated from the data channel. Indeed, the control channel can be implemented completely out-of-band for various reason, e.g., when the data channel cannot carry in-band control information. This issue was even originally introduced to MPLS in the context of link bundling.
在GMPLS中，控制通道必须与数据通道分开。实际上，由于各种原因，例如，当数据信道不能携带带内控制信息时，控制信道可以完全在带外实现。这个问题甚至最初是在链接绑定的上下文中引入MPLS的。
In traditional MPLS, there is an implicit one-to-one association of a control channel to a data channel. When such an association is present, no additional or special information is required to associate a particular LSP setup transaction with a particular data channel.
在传统的MPLS中，存在控制信道与数据信道的隐式一对一关联。当存在这种关联时，将特定LSP设置事务与特定数据通道关联不需要额外或特殊信息。
Otherwise, it is necessary to convey additional information in signaling to identify the particular data channel being controlled. GMPLS supports explicit data channel identification by providing interface identification information. GMPLS allows the use of a number of interface identification schemes including IPv4 or IPv6 addresses, interface indexes (for unnumbered interfaces) and component interfaces (for bundled interfaces), unnumbered bundled interfaces are also supported.
否则，有必要在信令中传送附加信息以识别被控制的特定数据信道。GMPLS通过提供接口标识信息支持显式数据通道标识。GMPLS允许使用多种接口标识方案，包括IPv4或IPv6地址、接口索引（对于未编号的接口）和组件接口（对于捆绑接口），也支持未编号的捆绑接口。
The choice of the data interface to use is always made by the sender of the Path/Label Request message, and indicated by including the data channel's interface identifier in the message using a new RSVP_HOP object sub-type/Interface TLV.
要使用的数据接口的选择始终由路径/标签请求消息的发送方进行，并通过使用新的RSVP_-HOP对象子类型/接口TLV在消息中包括数据通道的接口标识符来指示。
For bi-directional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the Path/Label Request sender explicitly identifies the component interface used in each direction. The new object/TLV is used in Resv/Label Mapping message to indicate the downstream node's usage of the indicated interface(s).
对于双向LSP，发送方选择每个方向的数据接口。在除捆绑之外的所有情况下，上游接口由下游接口暗示。对于捆绑，路径/标签请求发送方明确标识每个方向上使用的组件接口。在Resv/Label映射消息中使用新对象/TLV来指示下游节点对所指示接口的使用。
The new object/TLV can contain a list of embedded TLVs, each embedded TLV can be an IPv4 address, and IPv6 address, an interface index, a downstream component interface ID or an upstream component interface ID. In the last three cases, the embedded TLV contains itself an IP address plus an Interface ID, the IP address being used to identify the interface ID (it can be the router ID for instance).
新对象/TLV可以包含嵌入式TLV的列表，每个嵌入式TLV可以是IPv4地址、IPv6地址、接口索引、下游组件接口ID或上游组件接口ID。在最后三种情况下，嵌入式TLV本身包含一个IP地址和一个接口ID，用于标识接口ID的IP地址（例如，它可以是路由器ID）。
There are cases where it is useful to indicate a specific interface associated with an error. To support these cases the IF_ID ERROR_SPEC RSVP Objects are defined.
在某些情况下，指示与错误关联的特定接口很有用。为了支持这些情况，定义了IF_ID ERROR_SPEC RSVP对象。
To improve scalability of MPLS TE (and thus GMPLS) it may be useful to aggregate multiple TE LSPs inside a bigger TE LSP. Intermediate nodes see the external LSP only. They do not have to maintain forwarding states for each internal LSP, less signaling messages need to be exchanged and the external LSP can be somehow protected instead (or in addition) to the internal LSPs. This can considerably increase the scalability of the signaling.
为了提高MPLS-TE（以及GMPLS）的可伸缩性，可以在更大的TE-LSP中聚合多个TE-LSP。中间节点只能看到外部LSP。它们不必为每个内部LSP维护转发状态，需要交换的信令消息更少，并且外部LSP可以以某种方式被保护，而不是（或附加）到内部LSP。这可以显著增加信令的可伸缩性。
The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency out of that LSP (advertising this LSP as a Traffic Engineering (TE) link into IS-IS/OSPF), (c) allowing other LSRs to use forwarding adjacencies for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (e.g., by using the label stack construct in the case of IP).
通过（a）LSR创建TE-LSP，（b）LSR从该LSP形成转发邻接（将该LSP作为流量工程（TE）链路宣传到is-is/OSPF），（c）允许其他LSR使用转发邻接进行路径计算，以及（d）将其他LSR发起的LSP嵌套到该LSP中，来完成聚合（例如，在IP的情况下，通过使用标签堆栈构造）。
ISIS/OSPF floods the information about "Forwarding Adjacencies" FAs just as it floods the information about any other links. Consequently to this flooding, an LSR has in its TE link state database the information about not just conventional links, but FAs as well.
ISIS/OSPF将“转发邻接”信息大量发送给FAs，就像它将任何其他链路的信息大量发送给FAs一样。因此，对于这种泛洪，LSR在其TE链路状态数据库中不仅包含常规链路的信息，还包含FAs的信息。
An LSR, when performing path computation, uses not just conventional links, but FAs as well. Once a path is computed, the LSR uses RSVP-TE/CR-LDP for establishing label binding along the path. FAs need simple extensions to signaling and routing protocols.
LSR在执行路径计算时，不仅使用常规链路，还使用FAs。一旦计算出路径，LSR使用RSVP-TE/CR-LDP沿路径建立标签绑定。FAs需要对信令和路由协议进行简单的扩展。
Forwarding adjacencies may be represented as either unnumbered or numbered links. A FA can also be a bundle of LSPs between two nodes.
转发邻接可以表示为未编号或编号的链路。FA也可以是两个节点之间的LSP束。
FAs are advertised as GMPLS TE links such as defined in [HIERARCHY]. GMPLS TE links are advertised in OSPF and IS-IS such as defined in [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. These last two specifications enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link.
FAs被宣传为GMPLS TE链接，如[HIERARCHY]中定义的链接。GMPLS TE链路在OSPF和IS-IS中进行广告，如[OSPF-TE-GMPLS]和[ISIS-TE-GMPLS]中的定义。最后两个规范增强了定义基本TE链路的[OSPF-TE]和[ISIS-TE]。
When a FA is created dynamically, its TE attributes are inherited from the FA-LSP that induced its creation. [HIERARCHY] specifies how each TE parameter of the FA is inherited from the FA-LSP. Note that the bandwidth of the FA must be at least as big as the FA-LSP that induced it, but may be bigger if only discrete bandwidths are available for the FA-LSP. In general, for dynamically provisioned forwarding adjacencies, a policy-based mechanism may be needed to associate attributes to forwarding adjacencies.
动态创建FA时，其TE属性将从导致其创建的FA-LSP继承。[HIERARCHY]指定如何从FA-LSP继承FA的每个TE参数。请注意，FA的带宽必须至少与诱发它的FA-LSP一样大，但如果FA-LSP只有离散带宽可用，则可能更大。通常，对于动态配置的转发邻接，可能需要基于策略的机制将属性与转发邻接相关联。
A FA advertisement could contain the information about the path taken by the FA-LSP associated with that FA. Other LSRs may use this information for path computation. This information is carried in a new OSPF and IS-IS TLV called the Path TLV.
FA广告可以包含与该FA相关联的FA-LSP所采用的路径的信息。其他LSR可将该信息用于路径计算。该信息在新的OSPF和is-is TLV（路径TLV）中传输。
It is possible that the underlying path information might change over time, via configuration updates, or dynamic route modifications, resulting in the change of that TLV.
底层路径信息可能会随着时间的推移，通过配置更新或动态路由修改而改变，从而导致TLV的改变。
If forwarding adjacencies are bundled (via link bundling), and if the resulting bundled link carries a Path TLV, the underlying path followed by each of the FA-LSPs that form the component links must be the same.
如果转发邻接被捆绑（通过链路捆绑），并且如果生成的捆绑链路携带路径TLV，则构成组件链路的每个FA LSP后面的基础路径必须相同。
It is expected that forwarding adjacencies will not be used for establishing IS-IS/OSPF peering relation between the routers at the ends of the adjacency.
预计转发邻接将不会用于在邻接末端的路由器之间建立is-is/OSPF对等关系。
LSP hierarchy could exist both with the peer and with the overlay models. With the peer model, the LSP hierarchy is realized via FAs and an LSP is both created and used as a TE link by exactly the same instance of the control plane. Creating LSP hierarchies with overlays does not involve the concept of FA. With the overlay model an LSP created (and maintained) by one instance of the GMPLS control plane is used as a TE link by another instance of the GMPLS control plane. Moreover, the nodes using a TE link are expected to have a routing and signaling adjacency.
LSP层次结构可以同时存在于对等模型和覆盖模型中。在对等模型中，LSP层次通过FAs实现，LSP由完全相同的控制平面实例创建并用作TE链路。使用覆盖创建LSP层次结构不涉及FA的概念。对于覆盖模型，由GMPLS控制平面的一个实例创建（和维护）的LSP被另一个GMPLS控制平面实例用作TE链路。此外，使用TE链路的节点预期具有路由和信令邻接。
For the purpose of processing the explicit route in a Path/Request message of an LSP that is to be tunneled over a forwarding adjacency, an LSR at the head-end of the FA-LSP views the LSR at the tail of that FA-LSP as adjacent (one IP hop away).
为了处理要通过转发邻接进行隧道传输的LSP的路径/请求消息中的显式路由，FA-LSP的前端的LSR将该FA-LSP的尾部的LSR视为相邻（一个IP跳）。
With an integrated model, several layers are controlled using the same routing and signaling protocols. A network may then have links with different multiplexing/demultiplexing capabilities. For example, a node may be able to multiplex/demultiplex individual packets on a given link, and may be able to multiplex/demultiplex channels within a SONET payload on other links.
通过集成模型，使用相同的路由和信令协议控制多个层。然后，网络可以具有具有不同复用/解复用能力的链路。例如，节点可以在给定链路上复用/解复用单个分组，并且可以在其他链路上复用/解复用SONET有效载荷内的信道。
A new OSPF and IS-IS sub-TLV has been defined to advertise the multiplexing capability of each interface: PSC, L2SC, TDM, LSC or FSC. This sub-TLV is called the Interface Switching Capability Descriptor sub-TLV, which complements the sub-TLVs defined in
定义了一个新的OSPF和IS-IS子TLV，以宣传每个接口的复用能力：PSC、L2SC、TDM、LSC或FSC。此子TLV称为接口交换能力描述符子TLV，它补充了中定义的子TLV
[OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. The information carried in this sub-TLV is used to construct LSP regions, and determine region's boundaries.
[OSPF-TE-GMPLS]和[ISIS-TE-GMPLS]。该子TLV中携带的信息用于构造LSP区域，并确定区域边界。
Path computation may take into account region boundaries when computing a path for an LSP. For example, path computation may restrict the path taken by an LSP to only the links whose multiplexing/demultiplexing capability is PSC. When an LSP need to cross a region boundary, it can trigger the establishment of an FA at the underlying layer (i.e., the L2SC layer). This can trigger a cascading of FAs between layers with the following obvious order: L2SC, then TDM, then LSC, and then finally FSC.
当计算LSP的路径时，路径计算可以考虑区域边界。例如，路径计算可以将LSP采用的路径限制为仅复用/解复用能力为PSC的链路。当LSP需要跨越区域边界时，它可以触发在底层（即L2SC层）建立FA。这可以触发层之间的FAs级联，顺序如下：L2SC，然后是TDM，然后是LSC，最后是FSC。
By definition, two nodes have a routing (IS-IS/OSPF) adjacency if they are neighbors in the IS-IS/OSPF sense.
根据定义，如果两个节点是IS-IS/OSPF意义上的邻居，则它们具有路由（IS-IS/OSPF）邻接。
By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency if they are neighbors in the RSVP-TE/CR-LDP sense. Nodes A and B are RSVP-TE neighbors if they directly exchange RSVP-TE messages (Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of [HIERARCHY]). The neighbor relationship includes exchanging RSVP-TE Hellos.
根据定义，如果两个节点是RSVP-TE/CR-LDP意义上的邻居，则它们具有信令（RSVP-TE/CR-LDP）邻接。如果节点A和B直接交换RSVP-TE消息（路径/Resv）（例如，如[层次结构]第7.1.1节和第7.1.2节所述），则它们是RSVP-TE邻居。邻居关系包括交换RSVP-TE Hello。
By definition, a Forwarding Adjacency (FA) is a TE Link between two GMPLS nodes whose path transits one or more other (G)MPLS nodes in the same instance of the (G)MPLS control plane. If two nodes have one or more non-FA TE Links between them, these two nodes are expected (although not required) to have a routing adjacency. If two nodes do not have any non-FA TE Links between them, it is expected (although not required) that these two nodes would not have a routing adjacency. To state the obvious, if the TE links between two nodes are to be used for establishing LSPs, the two nodes must have a signaling adjacency.
根据定义，转发邻接（FA）是两个GMPLS节点之间的TE链路，其路径通过（G）MPLS控制平面的同一实例中的一个或多个其他（G）MPLS节点。如果两个节点之间有一个或多个非fate链路，则这两个节点预期（尽管不是必需的）具有路由邻接。如果两个节点之间没有任何非fate链路，则预期（尽管不是必需的）这两个节点将没有路由邻接。显而易见，如果两个节点之间的TE链路用于建立lsp，则两个节点必须具有信令邻接。
If one wants to establish routing and/or signaling adjacency between two nodes, there must be an IP path between them. This IP path can be, for example, a TE Link with an interface switching capability of PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a (bi-directional) LSP that with an interface switching capability of PSC).
如果要在两个节点之间建立路由和/或信令邻接，它们之间必须有一条IP路径。例如，该IP路径可以是具有PSC接口交换能力的TE链路，任何看起来像IP链路的东西（例如，GRE隧道，或具有PSC接口交换能力的（双向）LSP）。
A TE link may not be capable of being used directly for maintaining routing and/or signaling adjacencies. This is because GMPLS routing and signaling adjacencies requires exchanging data on a per frame/ packet basis, and a TE link (e.g., a link between OXCs) may not be capable of exchanging data on a per packet basis. In this case, the
TE链路可能不能直接用于维持路由和/或信令邻接。这是因为GMPLS路由和信令邻接需要在每帧/分组的基础上交换数据，并且TE链路（例如，OXCs之间的链路）可能无法在每分组的基础上交换数据。在这种情况下
routing and signaling adjacencies are maintained via a set of one or more control channels (see [LMP]).
路由和信令邻接通过一组一个或多个控制信道来维持（参见[LMP]）。
Two nodes may have a TE link between them even if they do not have a routing adjacency. Naturally, each node must run OSPF/IS-IS with GMPLS extensions in order for that TE link to be advertised. More precisely, the node needs to run GMPLS extensions for TE Links with an interface switching capability (see [GMPLS-ROUTING]) other than PSC. Moreover, this node needs to run either GMPLS or MPLS extensions for TE links with an interface switching capability of PSC.
两个节点之间可能有TE链路，即使它们没有路由邻接。当然，每个节点都必须运行带有GMPLS扩展的OSPF/IS-IS，以便公布TE链路。更准确地说，节点需要为具有接口交换能力（参见[GMPLS-ROUTING]）而非PSC的TE链路运行GMPLS扩展。此外，该节点需要为具有PSC接口交换能力的TE链路运行GMPLS或MPLS扩展。
The mechanisms for Control Channel Separation [RFC3471] should be used (even if the IP path between two nodes is a TE link). I.e., RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object to specify a particular TE link when establishing an LSP.
应使用控制信道分离机制[RFC3471]（即使两个节点之间的IP路径是TE链路）。即，在建立LSP时，RSVP-TE/CR-LDP信令应使用接口ID（IF ID）对象来指定特定TE链路。
The IP path could consist of multiple IP hops. In this case, the mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used (in addition to Control Channel Separation).
IP路径可以由多个IP跃点组成。在这种情况下，应使用[层次结构]第7.1.1节和第7.1.2节的机制（除控制通道分离外）。
Two major types of faults can impact a control plane. The first, referred to as control channel fault, relates to the case where control communication is lost between two neighboring nodes. If the control channel is embedded with the data channel, data channel recovery procedure should solve the problem. If the control channel is independent of the data channel, additional procedures are required to recover from that problem.
两种主要类型的故障会影响控制平面。第一种称为控制信道故障，涉及两个相邻节点之间的控制通信丢失的情况。如果控制通道嵌入数据通道，则数据通道恢复程序应解决该问题。如果控制通道独立于数据通道，则需要额外的程序来从该问题中恢复。
The second, referred to as nodal faults, relates to the case where node loses its control state (e.g., after a restart) but does not loose its data forwarding state.
第二种情况称为节点故障，与节点失去控制状态（例如，重启后）但未失去数据转发状态的情况有关。
In transport networks, such types of control plane faults should not have service impact on the existing connections. Under such circumstances, a mechanism must exist to detect a control communication failure and a recovery procedure must guarantee connection integrity at both ends of the control channel.
在运输网络中，此类控制平面故障不应对现有连接产生服务影响。在这种情况下，必须存在检测控制通信故障的机制，并且恢复过程必须保证控制通道两端的连接完整性。
For a control channel fault, once communication is restored routing protocols are naturally able to recover but the underlying signaling protocols must indicate that the nodes have maintained their state through the failure. The signaling protocol must also ensure that any state changes that were instantiated during the failure are synchronized between the nodes.
对于控制信道故障，一旦通信恢复，路由协议自然能够恢复，但底层信令协议必须指示节点在故障期间保持了其状态。信令协议还必须确保在故障期间实例化的任何状态更改在节点之间同步。
For a nodal fault, a node's control plane restarts and loses most of its state information. In this case, both upstream and downstream nodes must synchronize their state information with the restarted node. In order for any resynchronization to occur the node undergoing the restart will need to preserve some information, such as it's mappings of incoming to outgoing labels.
对于节点故障，节点的控制平面将重新启动并丢失其大部分状态信息。在这种情况下，上游和下游节点都必须将其状态信息与重新启动的节点同步。为了进行任何重新同步，正在重新启动的节点需要保留一些信息，例如传入到传出标签的映射。
These issues are addressed in protocol specific fashions, see [RFC3473], [RFC3472], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. Note that these cases only apply when there are mechanisms to detect data channel failures independent of control channel failures.
这些问题以特定于协议的方式解决，请参见[RFC3473]、[RFC3472]、[OSPF-TE-GMPLS]和[ISIS-TE-GMPLS]。请注意，这些情况仅适用于存在独立于控制通道故障检测数据通道故障的机制的情况。
The LDP Fault tolerance (see [RFC3479]) specifies the procedures to recover from a control channel failure. [RFC3473] specifies how to recover from both a control channel failure and a node failure.
LDP容错（参见[RFC3479]）规定了从控制信道故障中恢复的程序。[RFC3473]指定如何从控制通道故障和节点故障中恢复。
This section discusses Protection and Restoration (P&R) issues for GMPLS LSPs. It is driven by the requirements outlined in [RFC3386] and some of the principles outlined in [RFC3469]. It will be enhanced, as more GMPLS P&R mechanisms are defined. The scope of this section is clarified hereafter:
本节讨论GMPLS LSP的保护和恢复（P&R）问题。它由[RFC3386]中概述的要求和[RFC3469]中概述的一些原则驱动。随着更多GMPLS P&R机制的定义，它将得到加强。本节的范围如下所述：
- This section is only applicable when a fault impacting LSP(s) happens in the data/transport plane. Section 10 deals with control plane fault handling for nodal and control channel faults.
- 本节仅适用于数据/传输平面中发生影响LSP的故障时。第10节涉及节点和控制通道故障的控制平面故障处理。
- This section focuses on P&R at the TDM, LSC and FSC layers. There are specific P&R requirements at these layers not present at the PSC layer.
- 本节重点介绍TDM、LSC和FSC层的P&R。PSC层中不存在这些层的特定P&R要求。
- This section focuses on intra-area P&R as opposed to inter-area P&R and even inter-domain P&R. Note that P&R can even be more restricted, e.g., to a collection of like customer equipment, or a collection of equipment of like capabilities, in one single routing area.
- 本节侧重于区域内P&R，而不是区域间P&R，甚至是域间P&R。请注意，P&R甚至可能受到更大的限制，例如，在一个路由区域中，类似客户设备的集合或具有类似功能的设备的集合。
- This section focuses on intra-layer P&R (horizontal hierarchy as defined in [RFC3386]) as opposed to the inter-layer P&R (vertical hierarchy).
- 本节重点介绍层内P&R（如[RFC3386]中定义的水平层次），而不是层间P&R（垂直层次）。
- P&R mechanisms are in general designed to handle single failures, which makes SRLG diversity a necessity. Recovery from multiple failures requires further study.
- P&R机制通常设计用于处理单一故障，这使得SRLG多样性成为必要。从多个故障中恢复需要进一步研究。
- Both mesh and ring-like topologies are supported.
- 支持网状拓扑和环形拓扑。
In the following, we assume that:
在下文中，我们假设：
- TDM, LSC and FSC devices are more generally committing recovery resources in a non-best effort way. Recovery resources are either allocated (thus used) or at least logically reserved (whether used or not by preemptable extra traffic but unavailable anyway for regular working traffic).
- TDM、LSC和FSC设备通常以非尽力而为的方式提交恢复资源。恢复资源要么被分配（因此被使用），要么至少在逻辑上被保留（无论是否被可抢占的额外流量使用，但对于常规工作流量无论如何都不可用）。
- Shared P&R mechanisms are valuable to operators in order to maximize their network utilization.
- 共享P&R机制对于运营商来说很有价值，以便最大限度地提高其网络利用率。
- Sending preemptable excess traffic on recovery resources is a valuable feature for operators.
- 对运营商来说，在恢复资源上发送可抢占的多余流量是一项很有价值的功能。
To describe the P&R architecture, one must consider two dimensions of hierarchy [RFC3386]:
为了描述P＆R体系结构，必须考虑层次结构的两个维度[RFC338 6]：
- A horizontal hierarchy consisting of multiple P&R domains, which is important in an LSP based protection scheme. The scope of P&R may extend over a link (or span), an administrative domain or sub-network, an entire LSP.
- 由多个P&R域组成的水平层次结构，这在基于LSP的保护方案中很重要。P&R的范围可以扩展到链路（或跨度）、管理域或子网、整个LSP。
An administrative domain may consist of a single P&R domain or as a concatenation of several smaller P&R domains. The operator can configure P&R domains, based on customers' requirements, and on network topology and traffic engineering constraints.
管理域可以由单个P&R域组成，也可以由几个较小的P&R域串联而成。运营商可以根据客户需求以及网络拓扑和流量工程约束配置P&R域。
- A vertical hierarchy consisting of multiple layers of P&R with varying granularities (packet flows, STS trails, lightpaths, fibers, etc).
- 由具有不同粒度（数据包流、STS路径、光路、光纤等）的多层P&R组成的垂直层次结构。
In the absence of adequate P&R coordination, a fault may propagate from one level to the next within a P&R hierarchy. It can lead to "collisions" and simultaneous recovery actions may lead to race conditions, reduced resource utilization, or instabilities [MANCHESTER]. Thus, a consistent escalation strategy is needed to coordinate recovery across domains and layers. The fact that GMPLS can be used at different layers could simplify this coordination.
在缺乏充分的P&R协调的情况下，故障可能会在P&R层次结构中从一个级别传播到下一个级别。它可能导致“冲突”，同时的恢复操作可能导致竞争条件、资源利用率降低或不稳定[MANCHESTER]。因此，需要一致的升级策略来协调跨域和跨层的恢复。GMPLS可以在不同的层上使用，这一事实可以简化这种协调。
There are two types of escalation strategies: bottom-up and top-down. The bottom-up approach assumes that "lower-level" recovery schemes are more expedient. Therefore we can inhibit or hold off
有两种升级策略：自下而上和自上而下。自下而上的方法假定“较低级别”的恢复方案更为方便。因此，我们可以抑制或延缓
higher-level P&R. The Top-down approach attempts service P&R at the higher levels before invoking "lower level" P&R. Higher-layer P&R is service selective, and permits "per-CoS" or "per-LSP" re-routing.
较高级别的P&R。自上而下的方法在调用“较低级别”P&R之前尝试在较高级别上进行服务P&R。较高级别的P&R具有服务选择性，并允许“每CoS”或“每LSP”重新路由。
Service Level Agreements (SLAs) between network operators and their clients are needed to determine the necessary time scales for P&R at each layer and at each domain.
需要网络运营商与其客户之间的服务水平协议（SLA）来确定各层和各域P&R的必要时间尺度。
The choice of a P&R scheme is a tradeoff between network utilization (cost) and service interruption time. In light of this tradeoff, network service providers are expected to support a range of different service offerings or service levels.
P&R方案的选择是网络利用率（成本）和服务中断时间之间的权衡。鉴于这一权衡，网络服务提供商预计将支持一系列不同的服务产品或服务级别。
One can classify LSPs into one of a small set of service levels. Among other things, these service levels define the reliability characteristics of the LSP. The service level associated with a given LSP is mapped to one or more P&R schemes during LSP establishment. An advantage that mapping is that an LSP may use different P&E schemes in different segments of a network (e.g., some links may be span protected, whilst other segments of the LSP may utilize ring protection). These details are likely to be service provider specific.
可以将LSP划分为一小组服务级别中的一个。除其他外，这些服务级别定义了LSP的可靠性特征。在LSP建立期间，与给定LSP关联的服务级别映射到一个或多个P&R方案。映射的一个优点是，LSP可以在网络的不同段中使用不同的P&E方案（例如，一些链路可以是跨度保护的，而LSP的其他段可以使用环保护）。这些详细信息可能是特定于服务提供商的。
An alternative to using service levels is for an application to specify the set of specific P&R mechanisms to be used when establishing the LSP. This allows greater flexibility in using different mechanisms to meet the application requirements.
使用服务级别的另一种方法是，应用程序指定在建立LSP时要使用的一组特定P&R机制。这使得使用不同的机制来满足应用程序需求具有更大的灵活性。
A differentiator between these service levels is service interruption time in case of network failures, which is defined as the length of time between when a failure occurs and when connectivity is re-established. The choice of service level (or P&R scheme) should be dictated by the service requirements of different applications.
这些服务级别之间的一个区别是网络故障时的服务中断时间，它定义为故障发生和重新建立连接之间的时间长度。服务级别（或P&R方案）的选择应根据不同应用的服务要求而定。
The following figure provides a classification of the possible provisioning types of recovery LSPs, and of the levels of overbooking that is possible for them.
下图提供了恢复LSP的可能调配类型的分类，以及它们可能的超售级别。
+-Computed on +-Established +-Resources pre-
| demand | on demand | allocated
| | |
Recovery LSP | | |
Provisioning -+-Pre computed +-Pre established +-Resources allocated
on demand
+-Computed on +-Established +-Resources pre-
| demand | on demand | allocated
| | |
Recovery LSP | | |
Provisioning -+-Pre computed +-Pre established +-Resources allocated
on demand
+--- Dedicated (1:1, 1+1)
|
|
+--- Shared (1:N, Ring, Shared mesh)
|
Level of |
Overbooking ---+--- Best effort
+--- Dedicated (1:1, 1+1)
|
|
+--- Shared (1:N, Ring, Shared mesh)
|
Level of |
Overbooking ---+--- Best effort
Recovery from a network fault or impairment takes place in several stages as discussed in [RFC3469], including fault detection, fault localization, notification, recovery (i.e., the P&R itself) and reversion of traffic (i.e., returning the traffic to the original working LSP or to a new one).
如[RFC3469]所述，从网络故障或损坏中恢复分为几个阶段，包括故障检测、故障定位、通知、恢复（即P&R本身）和流量恢复（即将流量恢复到原始工作LSP或新LSP）。
- Fault detection is technology and implementation dependent. In general, failures are detected by lower layer mechanisms (e.g., SONET/SDH, Loss-of-Light (LOL)). When a node detects a failure, an alarm may be passed up to a GMPLS entity, which will take appropriate actions, or the alarm may be propagated at the lower layer (e.g., SONET/SDH AIS).
- 故障检测取决于技术和实现。通常，故障是通过较低层机制（例如SONET/SDH、失光（LOL））检测到的。当节点检测到故障时，警报可能会传递给GMPLS实体，该实体将采取适当的措施，或者警报可能会在较低层传播（例如SONET/SDH AIS）。
- Fault localization can be done with the help of GMPLS, e.g., using LMP for fault localization (see section 6.4).
- 可以借助GMPLS进行故障定位，例如，使用LMP进行故障定位（见第6.4节）。
- Fault notification can also be achieved through GMPLS, e.g., using GMPLS RSVP-TE/CR-LDP notification (see section 7.12).
- 故障通知也可以通过GMPLS实现，例如，使用GMPLS RSVP-TE/CR-LDP通知（见第7.12节）。
- This section focuses on the different mechanisms available for recovery and reversion of traffic once fault detection, localization and notification have taken place.
- 本节重点介绍一旦发生故障检测、定位和通知，可用于恢复和恢复流量的不同机制。
Network P&R techniques can be divided into Protection and Restoration. In protection, resources between the protection endpoints are established before failure, and connectivity after failure is achieved simply by switching performed at the protection end-points. In contrast, restoration uses signaling after failure to allocate resources along the recovery path.
网络P&R技术可分为保护技术和恢复技术。在保护中，保护端点之间的资源在故障前建立，故障后的连接只需通过在保护端点执行切换即可实现。相反，恢复在失败后使用信令沿恢复路径分配资源。
- Protection aims at extremely fast reaction times and may rely on the use of overhead control fields for achieving end-point coordination. Protection for SONET/SDH networks is described in [ITUT-G.841] and [ANSI-T1.105]. Protection mechanisms can be further classified by the level of redundancy and sharing.
- 保护旨在实现极快的反应时间，并可能依赖于使用架空控制场来实现端点协调。SONET/SDH网络的保护在[ITUT-G.841]和[ANSI-T1.105]中有描述。保护机制可以根据冗余和共享级别进一步分类。
- Restoration mechanisms rely on signaling protocols to coordinate switching actions during recovery, and may involve simple re-provisioning, i.e., signaling only at the time of recovery; or pre-signaling, i.e., signaling prior to recovery.
- 恢复机制依赖于信令协议来协调恢复期间的切换操作，并且可能涉及简单的重新配置，即，仅在恢复时发送信令；或预发信号，即恢复前发信号。
In addition, P&R can be applied on a local or end-to-end basis. In the local approach, P&R is focused on the local proximity of the fault in order to reduce delay in restoring service. In the end-to-end approach, the LSP originating and terminating nodes control recovery.
此外，P&R可在本地或端到端基础上应用。在局部方法中，P&R关注故障的局部邻近性，以减少恢复服务的延迟。在端到端方法中，LSP发起和终止节点控制恢复。
Using these strategies, the following recovery mechanisms can be defined.
使用这些策略，可以定义以下恢复机制。
Note that protection schemes are usually defined in technology specific ways, but this does not preclude other solutions.
请注意，保护方案通常以特定于技术的方式定义，但这并不排除其他解决方案。
- 1+1 Link Protection: Two pre-provisioned resources are used in parallel. For example, data is transmitted simultaneously on two parallel links and a selector is used at the receiving node to choose the best source (see also [GMPLS-FUNCT]).
- 1+1链路保护：两个预配置的资源并行使用。例如，数据在两个并行链路上同时传输，接收节点使用选择器选择最佳源（另请参见[GMPLS-FUNCT]）。
- 1:N Link Protection: Working and protecting resources (N working, 1 backup) are pre-provisioned. If a working resource fails, the data is switched to the protecting resource, using a coordination mechanism (e.g., in overhead bytes). More generally, N working and M protecting resources can be assigned for M:N link protection (see also [GMPLS-FUNCT]).
- 1:N链路保护：工作和保护资源（N个工作，1个备份）是预先配置的。如果工作资源出现故障，则使用协调机制（例如，以开销字节为单位）将数据切换到保护资源。更一般地，可以为M:N链路保护分配N个工作和M个保护资源（另请参见[GMPLS-FUNCT]）。
- Enhanced Protection: Various mechanisms such as protection rings can be used to enhance the level of protection beyond single link failures to include the ability to switch around a node failure or multiple link failures within a span, based on a pre-established topology of protection resources (note: no reference available at publication time).
- 增强保护：可以使用各种机制（如保护环）来增强单链路故障以外的保护级别，以包括根据预先建立的保护资源拓扑在一个范围内切换节点故障或多个链路故障的能力（注：发布时无参考）。
- 1+1 LSP Protection: Simultaneous data transmission on working and protecting LSPs and tail-end selection can be applied (see also [GMPLS-FUNCT]).
- 1+1 LSP保护：可应用工作和保护LSP的同时数据传输和尾端选择（另见[GMPLS-FUNCT]）。
Thanks to the use of a distributed control plane like GMPLS, restoration is possible in multiple of tenths of milliseconds. It is much harder to achieve when only an NMS is used and can only be done in that case in a multiple of seconds.
由于使用了像GMPLS这样的分布式控制平面，恢复可能需要十分之一毫秒的倍数。当只使用NMS时，要实现这一点要困难得多，而且只能在几秒钟内完成。
- End-to-end LSP restoration with re-provisioning: an end-to-end restoration path is established after failure. The restoration path may be dynamically calculated after failure, or pre-calculated before failure (often during LSP establishment). Importantly, no signaling is used along the restoration path before failure, and no restoration bandwidth is reserved. Consequently, there is no guarantee that a given restoration path is available when a failure occurs. Thus, one may have to crankback to search for an available path.
- 带重新配置的端到端LSP恢复：故障后建立端到端恢复路径。恢复路径可以在故障后动态计算，也可以在故障前预先计算（通常在LSP建立期间）。重要的是，在发生故障之前，恢复路径上没有使用信令，也没有保留恢复带宽。因此，无法保证在发生故障时给定的恢复路径可用。因此，您可能必须回过头来搜索可用路径。
- End-to-end LSP restoration with pre-signaled recovery bandwidth reservation and no label pre-selection: an end-to-end restoration path is pre-calculated before failure and a signaling message is sent along this pre-selected path to reserve bandwidth, but labels are not selected (see also [GMPLS-FUNCT]).
- 端到端LSP恢复，带有预发信号的恢复带宽保留和无标签预选：在故障发生之前预先计算端到端恢复路径，并沿此预选路径发送信令消息以保留带宽，但未选择标签（另请参见[GMPLS-FUNCT]）。
The resources reserved on each link of a restoration path may be shared across different working LSPs that are not expected to fail simultaneously. Local node policies can be applied to define the degree to which capacity is shared across independent failures. Upon failure detection, LSP signaling is initiated along the restoration path to select labels, and to initiate the appropriate cross-connections.
恢复路径的每个链路上保留的资源可以在不同的工作LSP之间共享，这些LSP预计不会同时发生故障。可以应用本地节点策略来定义跨独立故障共享容量的程度。一旦检测到故障，LSP信令将沿着恢复路径启动，以选择标签，并启动适当的交叉连接。
- End-to-end LSP restoration with pre-signaled recovery bandwidth reservation and label pre-selection: An end-to-end restoration path is pre-calculated before failure and a signaling procedure is initiated along this pre-selected path on which bandwidth is reserved and labels are selected (see also [GMPLS-FUNCT]).
- 端到端LSP恢复，带有预发信号的恢复带宽保留和标签预选：在故障发生之前预先计算端到端恢复路径，并沿着预先选择的路径启动一个信令过程，在该路径上保留带宽并选择标签（另请参见[GMPLS-FUNCT]）。
The resources reserved on each link may be shared across different working LSPs that are not expected to fail simultaneously. In networks based on TDM, LSC and FSC technology, LSP signaling is used after failure detection to establish cross-connections at the intermediate switches on the restoration path using the pre-selected labels.
每个链路上保留的资源可以在不希望同时发生故障的不同工作LSP之间共享。在基于TDM、LSC和FSC技术的网络中，LSP信令在故障检测后使用，以使用预先选择的标签在恢复路径上的中间交换机处建立交叉连接。
- Local LSP restoration: the above approaches can be applied on a local basis rather than end-to-end, in order to reduce recovery time (note: no reference available at publication time).
- 本地LSP恢复：可以在本地而不是端到端的基础上应用上述方法，以缩短恢复时间（注：发布时无参考资料）。
This section discusses criteria that could be used by the operator in order to make a choice among the various P&R mechanisms.
本节讨论运营商可用于在各种P&R机制中做出选择的标准。
- Robustness: In general, the less pre-planning of the restoration path, the more robust the restoration scheme is to a variety of failures, provided that adequate resources are available. Restoration schemes with pre-planned paths will not be able to recover from network failures that simultaneously affect both the working and restoration paths. Thus, these paths should ideally be chosen to be as disjoint as possible (i.e., SRLG and node disjoint), so that any single failure event will not affect both paths. The risk of simultaneous failure of the two paths can be reduced by recalculating the restoration path whenever a failure occurs along it.
- 鲁棒性：一般来说，恢复路径的预规划越少，恢复方案对各种故障的鲁棒性就越强，前提是有足够的资源可用。具有预先规划路径的恢复方案将无法从同时影响工作路径和恢复路径的网络故障中恢复。因此，理想情况下，应选择尽可能不相交的路径（即SRLG和节点不相交），以便任何单一故障事件不会影响两条路径。只要沿恢复路径发生故障，就可以通过重新计算恢复路径来降低两条路径同时发生故障的风险。
The pre-selection of a label gives less flexibility for multiple failure scenarios than no label pre-selection. If failures occur that affect two LSPs that are sharing a label at a common node along their restoration routes, then only one of these LSPs can be recovered, unless the label assignment is changed.
与无标签预选相比，标签预选对多个故障场景的灵活性更小。如果发生的故障影响到两个LSP，这两个LSP沿其恢复路由在公共节点上共享标签，则只能恢复其中一个LSP，除非更改标签分配。
The robustness of a restoration scheme is also determined by the amount of reserved restoration bandwidth - as the amount of restoration bandwidth sharing increases (reserved bandwidth decreases), the restoration scheme becomes less robust to failures. Restoration schemes with pre-signaled bandwidth reservation (with or without label pre-selection) can reserve adequate bandwidth to ensure recovery from any specific set of failure events, such as any single SRLG failure, any two SRLG failures etc. Clearly, more restoration capacity is allocated if a greater degree of failure recovery is required. Thus, the degree to which the network is protected is determined by the policy that defines the amount of reserved restoration bandwidth.
恢复方案的鲁棒性还取决于保留恢复带宽的数量——随着恢复带宽共享量的增加（保留带宽减少），恢复方案对故障的鲁棒性降低。具有预信号带宽预留（带或不带标签预选）的恢复方案可以预留足够的带宽，以确保从任何特定故障事件集恢复，例如任何单个SRLG故障、任何两个SRLG故障等，如果需要更大程度的故障恢复，则会分配更多的恢复容量。因此，网络的保护程度由定义保留恢复带宽量的策略确定。
- Recovery time: In general, the more pre-planning of the restoration route, the more rapid the P&R scheme. Protection schemes generally recover faster than restoration schemes. Restoration with pre-signaled bandwidth reservation are likely to be (significantly) faster than path restoration with re-provisioning, especially because of the elimination of any crankback. Local restoration will generally be faster than end-to-end schemes.
- 恢复时间：一般来说，恢复路线的预先规划越多，P&R方案的速度就越快。保护方案通常比恢复方案恢复得更快。使用预发信号带宽保留的恢复可能（显著）比使用重新配置的路径恢复快，特别是因为消除了任何回退。本地恢复通常比端到端方案更快。
Recovery time objectives for SONET/SDH protection switching (not including time to detect failure) are specified in [ITUT-G.841] at 50 ms, taking into account constraints on distance, number of connections involved, and in the case of ring enhanced protection, number of nodes in the ring.
SONET/SDH保护切换的恢复时间目标（不包括检测故障的时间）在[ITUT-G.841]中规定为50 ms，考虑到距离、涉及的连接数量以及环增强保护情况下环中节点数量的限制。
Recovery time objectives for restoration mechanisms are being defined through a separate effort [RFC3386].
恢复机制的恢复时间目标是通过单独的工作定义的[RFC3386]。
- Resource Sharing: 1+1 and 1:N link and LSP protection require dedicated recovery paths with limited ability to share resources: 1+1 allows no sharing, 1:N allows some sharing of protection resources and support of extra (pre-emptable) traffic. Flexibility is limited because of topology restrictions, e.g., fixed ring topology for traditional enhanced protection schemes.
- 资源共享：1+1和1:N链路和LSP保护需要专用的恢复路径，但共享资源的能力有限：1+1不允许共享，1:N允许部分共享保护资源，并支持额外（可抢占）流量。由于拓扑限制，灵活性受到限制，例如，传统增强型保护方案的固定环拓扑。
The degree to which restoration schemes allow sharing amongst multiple independent failures is directly dictated by the size of the restoration pool. In restoration schemes with re-provisioning, a pool of restoration capacity can be defined from which all restoration routes are selected after failure. Thus, the degree of sharing is defined by the amount of available restoration capacity. In restoration with pre-signaled bandwidth reservation, the amount of reserved restoration capacity is determined by the local bandwidth reservation policies. In all restoration schemes, pre-emptable resources can use spare restoration capacity when that capacity is not being used for failure recovery.
恢复方案允许在多个独立故障之间共享的程度直接取决于恢复池的大小。在具有重新配置的恢复方案中，可以定义一个恢复容量池，故障后从中选择所有恢复路由。因此，共享程度由可用恢复容量的大小来定义。在使用预发信号带宽保留的恢复中，保留的恢复容量由本地带宽保留策略决定。在所有恢复方案中，当备用恢复容量不用于故障恢复时，可抢占资源可以使用备用恢复容量。
Service Providers (SPs) use network management extensively to configure, monitor or provision various devices in their network. It is important to note that a SP's equipment may be distributed across geographically separate sites thus making distributed management even more important. The service provider should utilize an NMS system and standard management protocols such as SNMP (see [RFC3410], [RFC3411] and [RFC3416]) and the relevant MIB modules as standard interfaces to configure, monitor and provision devices at various locations. The service provider may also wish to use the command line interface (CLI) provided by vendors with their devices. However, this is not a standard or recommended solution because there is no standard CLI language or interface, which results in N different CLIs in a network with devices from N different vendors. In the context of GMPLS, it is extremely important for standard interfaces to the SP's devices (e.g., SNMP) to exist due to the nature of the technology itself. Since GMPLS comprises many different layers of control-plane
服务提供商（SP）广泛使用网络管理来配置、监视或提供其网络中的各种设备。需要注意的是，SP的设备可能分布在地理位置不同的站点上，因此分布式管理更加重要。服务提供商应使用NMS系统和标准管理协议，如SNMP（参见[RFC3410]、[RFC3411]和[RFC3416]）以及相关MIB模块作为标准接口，以配置、监控和提供不同位置的设备。服务提供商还可能希望在其设备中使用供应商提供的命令行界面（CLI）。但是，这不是一个标准的或推荐的解决方案，因为没有标准的CLI语言或接口，这会导致网络中有N个不同的CLI，其中包含N个不同供应商的设备。在GMPLS环境中，由于技术本身的性质，SP设备的标准接口（如SNMP）的存在极为重要。由于GMPLS包含许多不同的控制平面层
and data-plane technology, it is important for management interfaces in this area to be flexible enough to allow the manager to manage GMPLS easily, and in a standard way.
以及数据平面技术，这一领域的管理界面必须足够灵活，以允许管理者以标准方式轻松管理GMPLS。
The NMS system should maintain the collective information about each device within the system. Note that the NMS system may actually be comprised of several distributed applications (i.e., alarm aggregators, configuration consoles, polling applications, etc.) that collectively comprises the SP's NMS. In this way, it can make provisioning and maintenance decisions with the full knowledge of the entire SP's network. Configuration or provisioning information (i.e., requests for new services) could be entered into the NMS and subsequently distributed via SNMP to the remote devices. Thus, making the SP's task of managing the network much more compact and effortless rather than having to manage each device individually (i.e., via CLI).
NMS系统应维护系统内每个设备的集合信息。请注意，NMS系统实际上可能由几个分布式应用程序（即报警聚合器、配置控制台、轮询应用程序等）组成，这些应用程序共同构成SP的NMS。这样，it就可以在完全了解整个SP网络的情况下做出资源调配和维护决策。配置或供应信息（即，新服务请求）可以输入NMS，然后通过SNMP分发到远程设备。因此，使SP管理网络的任务更加紧凑和轻松，而不必单独管理每个设备（即通过CLI）。
Security and access control can be achieved using the SNMPv3 User-based Security Model (USM) [RFC3414] and the View-based Access Control Model (VACM) [RFC3415]. This approach can be very effectively used within a SP's network, since the SP has access to and control over all devices within its domain. Standardized MIBs will need to be developed before this approach can be used ubiquitously to provision, configure and monitor devices in non-heterogeneous networks or across SP's network boundaries.
可以使用SNMPv3基于用户的安全模型（USM）[RFC3414]和基于视图的访问控制模型（VACM）[RFC3415]实现安全和访问控制。这种方法可以在SP的网络中非常有效地使用，因为SP可以访问和控制其域内的所有设备。需要开发标准化的MIB，然后才能普遍使用此方法在非异构网络中或跨SP的网络边界提供、配置和监控设备。
In the context of GMPLS, it is extremely important for standard interfaces to devices to exist due to the nature of the technology itself. Since GMPLS comprises many different layers of control-plane technology, it is important for SNMP MIB modules in this area to be flexible enough to allow the manager to manage the entire control plane. This should be done using MIB modules that may cooperate (i.e., coordinated row-creation on the agent) or through more generalized MIB modules that aggregate some of the desired actions to be taken and push those details down to the devices. It is important to note that in certain circumstances, it may be necessary to duplicate some small subset of manageable objects in new MIB modules for management convenience. Control of some parts of GMPLS may also be achieved using existing MIB interfaces (i.e., existing SONET MIB) or using separate ones, which are yet to be defined. MIB modules may have been previously defined in the IETF or ITU. Current MIB modules may need to be extended to facilitate some of the new functionality
在GMPLS环境中，由于技术本身的性质，设备的标准接口的存在极其重要。由于GMPLS包含许多不同的控制平面技术层，因此该领域的SNMP MIB模块必须足够灵活，以允许管理器管理整个控制平面。这应该使用可以协作的MIB模块（即，在代理上协调行创建）或通过更通用的MIB模块来完成，MIB模块聚合要采取的一些所需操作，并将这些细节下推到设备上。需要注意的是，在某些情况下，为了便于管理，可能需要在新的MIB模块中复制一些小的可管理对象子集。还可以使用现有MIB接口（即现有SONET MIB）或使用尚未定义的单独接口来控制GMPLS的某些部分。MIB模块之前可能已在IETF或ITU中定义。当前的MIB模块可能需要扩展以促进某些新功能
desired by GMPLS. In these cases, the working group should work on new versions of these MIB modules so that these extensions can be added.
GMPLS要求的。在这些情况下，工作组应该研究这些MIB模块的新版本，以便可以添加这些扩展。
As in traditional networks, standard tools such as traceroute [RFC1393] and ping [RFC2151] are needed for debugging and performance monitoring of GMPLS networks, and mainly for the control plane topology, that will mimic the data plane topology. Furthermore, such tools provide network reachability information. The GMPLS control protocols will need to expose certain pieces of information in order for these tools to function properly and to provide information germane to GMPLS. These tools should be made available via the CLI. These tools should also be made available for remote invocation via the SNMP interface [RFC2925].
与传统网络一样，需要traceroute[RFC1393]和ping[RFC2151]等标准工具对GMPLS网络进行调试和性能监控，主要用于模拟数据平面拓扑的控制平面拓扑。此外，此类工具还提供网络可达性信息。GMPLS控制协议需要公开某些信息，以便这些工具正常运行并提供与GMPLS密切相关的信息。这些工具应通过CLI提供。这些工具还应可通过SNMP接口[RFC2925]进行远程调用。
Due to the nature of GMPLS, and that potential layers may be involved in the control and transmission of GMPLS data and control information, it is required that a fault in one layer be passed to the adjacent higher and lower layers to notify them of the fault. However, due to nature of these many layers, it is possible and even probable, that hundreds or even thousands of notifications may need to transpire between layers. This is undesirable for several reasons. First, these notifications will overwhelm the device. Second, if the device(s) are programmed to emit SNMP Notifications [RFC3417] then the large number of notifications the device may attempt to emit may overwhelm the network with a storm of notifications. Furthermore, even if the device emits the notifications, the NMS that must process these notifications either will be overwhelmed or will be processing redundant information. That is, if 1000 interfaces at layer B are stacked above a single interface below it at layer A, and the interface at A goes down, the interfaces at layer B should not emit notifications. Instead, the interface at layer A should emit a single notification. The NMS receiving this notification should be able to correlate the fact that this interface has many others stacked above it and take appropriate action, if necessary.
由于GMPLS的性质，以及潜在层可能参与GMPLS数据和控制信息的控制和传输，要求将一层中的故障传递给相邻的高层和下层，以通知他们该故障。然而，由于这些层的性质，可能甚至可能需要在层之间传输数百甚至数千个通知。这是不可取的，原因有几个。首先，这些通知将淹没设备。第二，如果设备被编程为发出SNMP通知[RFC3417]，那么设备可能试图发出的大量通知可能会以大量通知淹没网络。此外，即使设备发出通知，必须处理这些通知的NMS也将被淹没或处理冗余信息。也就是说，如果B层的1000个接口堆叠在a层的单个接口之上，而a层的接口向下，则B层的接口不应发出通知。相反，层A的接口应该发出一个通知。接收此通知的NMS应能够关联此接口上堆叠了许多其他接口的事实，并在必要时采取适当的措施。
Devices that support GMPLS should provide mechanisms for aggregating, summarizing, enabling and disabling of inter-layer notifications for the reasons described above. In the context of SNMP MIB modules, all MIB modules that are used by GMPLS must provide enable/disable objects for all notification objects. Furthermore, these MIBs must also provide notification summarization objects or functionality (as described above) as well. NMS systems and standard tools which
出于上述原因，支持GMPLS的设备应提供聚合、汇总、启用和禁用层间通知的机制。在SNMP MIB模块的上下文中，GMPLS使用的所有MIB模块必须为所有通知对象提供启用/禁用对象。此外，这些MIB还必须提供通知摘要对象或功能（如上所述）。NMS系统和标准工具
process notifications or keep track of the many layers on any given devices must be capable of processing the vast amount of information which may potentially be emitted by network devices running GMPLS at any point in time.
处理通知或跟踪任何给定设备上的许多层必须能够处理在任何时间点运行GMPLS的网络设备可能发出的大量信息。
GMPLS defines a control plane architecture for multiple technologies and types of network elements. In general, since LSPs established using GMPLS may carry high volumes of data and consume significant network resources, security mechanisms are required to safeguard the underlying network against attacks on the control plane and/or unauthorized usage of data transport resources. The GMPLS control plane should therefore include mechanisms that prevent or minimize the risk of attackers being able to inject and/or snoop on control traffic. These risks depend on the level of trust between nodes that exchange GMPLS control messages, as well as the realization and physical characteristics of the control channel. For example, an in-band, in-fiber control channel over SONET/SDH overhead bytes is, in general, considered less vulnerable than a control channel realized over an out-of-band IP network.
GMPLS为多种技术和类型的网元定义了一个控制平面架构。一般来说，由于使用GMPLS建立的LSP可能携带大量数据并消耗大量网络资源，因此需要安全机制来保护底层网络免受控制平面上的攻击和/或未经授权使用数据传输资源。因此，GMPLS控制平面应包括防止或最小化攻击者能够注入和/或窥探控制流量的风险的机制。这些风险取决于交换GMPLS控制消息的节点之间的信任级别，以及控制通道的实现和物理特性。例如，通常认为，通过SONET/SDH开销字节的带内、光纤控制信道比通过带外IP网络实现的控制信道更容易受到攻击。
Security mechanisms can provide authentication and confidentiality. Authentication can provide origin verification, message integrity and replay protection, while confidentiality ensures that a third party cannot decipher the contents of a message. In situations where GMPLS deployment requires primarily authentication, the respective authentication mechanisms of the GMPLS component protocols may be used (see [RFC2747], [RFC3036], [RFC2385] and [LMP]). Additionally, the IPsec suite of protocols (see [RFC2402], [RFC2406] and [RFC2409]) may be used to provide authentication, confidentiality or both, for a GMPLS control channel. IPsec thus offers the benefits of combined protection for all GMPLS component protocols as well as key management.
安全机制可以提供身份验证和机密性。身份验证可以提供来源验证、消息完整性和重播保护，而机密性可以确保第三方无法破译消息内容。在GMPLS部署主要需要认证的情况下，可以使用GMPLS组件协议的相应认证机制（参见[RFC2747]、[RFC3036]、[RFC2385]和[LMP]）。此外，IPsec协议套件（参见[RFC2402]、[RFC2406]和[RFC2409]）可用于为GMPLS控制信道提供认证、机密性或两者。因此，IPsec为所有GMPLS组件协议以及密钥管理提供了组合保护的好处。
A related issue is that of the authorization of requests for resources by GMPLS-capable nodes. Authorization determines whether a given party, presumable already authenticated, has a right to access the requested resources. This determination is typically a matter of local policy control [RFC2753], for example by setting limits on the total bandwidth available to some party in the presence of resource contention. Such policies may become quite complex as the number of users, types of resources and sophistication of authorization rules increases.
一个相关的问题是GMPLS节点对资源请求的授权。授权确定假定已通过身份验证的给定方是否有权访问请求的资源。此确定通常是本地策略控制[RFC2753]的问题，例如，通过在存在资源争用的情况下设置对某一方可用的总带宽的限制。随着用户数量、资源类型和授权规则复杂性的增加，此类策略可能变得相当复杂。
After authenticating requests, control elements should match them against the local authorization policy. These control elements must be capable of making decisions based on the identity of the
验证请求后，控制元素应根据本地授权策略对其进行匹配。这些控制元件必须能够根据用户的身份做出决策
requester, as verified cryptographically and/or topologically. For example, decisions may depend on whether the interface through which the request is made is an inter- or intra-domain one. The use of appropriate local authorization policies may help in limiting the impact of security breaches in remote parts of a network.
请求者，经加密和/或拓扑验证。例如，决策可能取决于发出请求的接口是域间接口还是域内接口。使用适当的本地授权策略可能有助于限制网络远程部分中安全漏洞的影响。
Finally, it should be noted that GMPLS itself introduces no new security considerations to the current MPLS-TE signaling (RSVP-TE, CR-LDP), routing protocols (OSPF-TE, IS-IS-TE) or network management protocols (SNMP).
最后，应该注意的是，GMPLS本身没有对当前的MPLS-TE信令（RSVP-TE、CR-LDP）、路由协议（OSPF-TE、IS-IS-TE）或网络管理协议（SNMP）引入新的安全考虑。
This document is the work of numerous authors and consists of a composition of a number of previous documents in this area.
本文件是众多作者的作品，由该领域以前的许多文件组成。
Many thanks to Ben Mack-Crane (Tellabs) for all the useful SONET/SDH discussions we had together. Thanks also to Pedro Falcao, Alexandre Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from Ebone for their SONET/SDH and optical technical advice and support. Finally, many thanks also to Krishna Mitra (Consultant), Curtis Villamizar (Avici), Ron Bonica (WorldCom), and Bert Wijnen (Lucent) for their revision effort on Section 12.
非常感谢Ben Mack Crane（Tellabs）与我们一起进行的所有有用的SONET/SDH讨论。还要感谢来自埃伯恩的Pedro Falcao、Alexandre Geyssens、Michael Moelants、Xavier Neerdaels和Philippe Noel为SONET/SDH和光学技术提供的建议和支持。最后，还要感谢Krishna Mitra（顾问）、Curtis Villamizar（Avici）、Ron Bonica（世界通信公司）和Bert Wijnen（朗讯公司）对第12节的修订工作。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212]Jamoussi，B.，Andersson，L.，Callon，R.，Dantu，R.，Wu，L.，Doolan，P.，Worster，T.，Feldman，N.，Fredette，A.，Girish，M.，Gray，E.，Heinanen，J.，Kilty，T.，和A.Malis，“使用LDP的基于约束的LSP设置”，RFC 3212，2002年1月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472]Ashwood Smith，P.和L.Berger，“基于广义多协议标签交换（GMPLS）信令约束的路由标签分发协议（CR-LDP）扩展”，RFC 3472，2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[ANSI-T1.105] "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, And Formats," ANSI T1.105, 2000.
[ANSI-T1.105]“同步光网络（SONET）：基本描述，包括多路复用结构、速率和格式”，ANSI T1.105，2000年。
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[BUNDLE]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程中的链路捆绑”，正在进行中。
[GMPLS-FUNCT] Lang, J.P., Ed. and B. Rajagopalan, Ed., "Generalized MPLS Recovery Functional Specification", Work in Progress.
[GMPLS-FUNCT]Lang，J.P.，Ed.和B.Rajagopalan，Ed.，“通用MPLS恢复功能规范”，正在进行的工作。
[GMPLS-G709] Papadimitriou, D., Ed., "GMPLS Signaling Extensions for G.709 Optical Transport Networks Control", Work in Progress.
[GMPLS-G709]Papadimitriou，D.，编辑，“G.709光传输网络控制的GMPLS信令扩展”，正在进行的工作。
[GMPLS-OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "GMPLS UNI: RSVP Support for the Overlay Model", Work in Progress.
[GMPLS-OVERLAY]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“覆盖模型的GMPLS UNI:RSVP支持”，工作正在进行中。
[GMPLS-ROUTING] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", Work in Progress.
[GMPLS-ROUTING]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换的路由扩展”，正在进行中。
[RFC3946] Mannie, E., Ed. and Papadimitriou D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004.
[RFC3946]Mannie，E.，Ed.和Papadimitriou D.，Ed.，“同步光网络（SONET）和同步数字体系（SDH）控制的通用多协议标签交换（GMPLS）扩展”，RFC 3946，2004年10月。
[HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", Work in Progress.
[HIERARCHY]Kompella，K.和Y.Rekhter，“具有广义MPLS TE的LSP层次结构”，正在进行中。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[ISIS-TE-GMPLS] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching", Work in Progress.
[ISIS-TE-GMPLS]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换的IS-IS扩展”，正在进行中。
[ITUT-G.707] ITU-T, "Network Node Interface for the Synchronous Digital Hierarchy", Recommendation G.707, October 2000.
[ITUT-G.707]ITU-T，“同步数字体系的网络节点接口”，建议G.707，2000年10月。
[ITUT-G.709] ITU-T, "Interface for the Optical Transport Network (OTN)," Recommendation G.709 version 1.0 (and Amendment 1), February 2001 (and October 2001).
[ITUT-G.709]ITU-T，“光传输网络（OTN）接口”，建议G.709第1.0版（和修正案1），2001年2月（和2001年10月）。
[ITUT-G.841] ITU-T, "Types and Characteristics of SDH Network Protection Architectures," Recommendation G.841, October 1998.
[ITUT-G.841]ITU-T，“SDH网络保护体系结构的类型和特征”，建议G.841，1998年10月。
[LMP] Lang, J., Ed., "Link Management Protocol (LMP)", Work in Progress.
[LMP]Lang，J.，Ed.，“链路管理协议（LMP）”，正在进行中。
[LMP-WDM] Fredette, A., Ed. and J. Lang Ed., "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", Work in Progress.
[LMP-WDM]Fredette，A.，Ed.和J.Lang Ed，“密集波分复用（DWDM）光纤线路系统的链路管理协议（LMP）”，正在进行中。
[MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The Evolution of Transport Network Survivability," IEEE Communications Magazine, August 1999.
[曼彻斯特]J.MANCHESTER，P.Bonenfant和C.Newton，“传输网络生存能力的演变”，IEEE通信杂志，1999年8月。
[OIF-UNI] The Optical Internetworking Forum, "User Network Interface (UNI) 1.0 Signaling Specification - Implementation Agreement OIF-UNI-01.0," October 2001.
[OIF-UNI]光互连论坛，“用户网络接口（UNI）1.0信令规范-实施协议OIF-UNI-01.0”，2001年10月。
[OLI-REQ] Fredette, A., Ed., "Optical Link Interface Requirements," Work in Progress.
[OLI-REQ]Fredette，A.，Ed.“光链路接口要求”，正在进行的工作。
[OSPF-TE-GMPLS] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching", Work in Progress.
[OSPF-TE-GMPLS]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换的OSPF扩展”，正在进行中。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393]Malkin，G.“使用IP选项的跟踪路由”，RFC 1393，1993年1月。
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", RFC 2151, June 1997.
[RFC2151]Kessler，G.和S.Shepard，“互联网和TCP/IP工具和实用程序入门”，RFC 2151，1997年6月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753]Yavatkar，R.，Pendarakis，D.，和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[RFC2925] White, K., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 2925, September 2000.
[RFC2925]White，K.，“远程Ping、跟踪路由和查找操作的托管对象定义”，RFC 29252000年9月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.
[RFC3386]Lai，W.和D.McDysan，“网络层次结构和多层生存能力”，RFC 3386，2002年11月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）版本3的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415]Wijnen，B.，Presuhn，R.，和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416]Presohn，R.，“简单网络管理协议（SNMP）协议操作的第2版”，STD 62，RFC 3416，2002年12月。
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417]Presohn，R.，“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月。
[RFC3469] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[RFC3469]Sharma，V.和F.Hellstrand，“基于多协议标签交换（MPLS）的恢复框架”，RFC 3469，2003年2月。
[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月。
[RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479]Farrel，A.，“标签分发协议（LDP）的容错”，RFC 3479，2003年2月。
[RFC3480] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.
[RFC3480]Kompella，K.，Rekhter，Y.，和A.Kullberg，“CR-LDP（约束路由标签分发协议）中的无编号链路信令”，RFC 3480，2003年2月。
[SONET-SDH-GMPLS-FRM] Bernstein, G., Mannie, E., and V. Sharma, "Framework for GMPLS-based Control of SDH/SONET Networks", Work in Progress.
[SONET-SDH-GMPLS-FRM]Bernstein，G.，Mannie，E.和V.Sharma，“基于GMPLS的SDH/SONET网络控制框架”，正在进行中。
Peter Ashwood-Smith Nortel P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7, Canada
Peter Ashwood Smith Nortel邮政信箱3511加拿大渥太华C站K1Y 4H7
EMail: petera@nortelnetworks.com
EMail: petera@nortelnetworks.com
Eric Mannie Consult Phone: +32 2 648-5023 Mobile: +32 (0)495-221775
Eric Mannie咨询电话：+32 2 648-5023手机：+32（0）495-221775
EMail: eric_mannie@hotmail.com
EMail: eric_mannie@hotmail.com
Daniel O. Awduche Consult
丹尼尔·奥杜什咨询公司
EMail: awduche@awduche.com
EMail: awduche@awduche.com
Thomas D. Nadeau Cisco 250 Apollo Drive Chelmsford, MA 01824, USA
美国马萨诸塞州切姆斯福德阿波罗大道250号托马斯D.纳多思科01824
EMail: tnadeau@cisco.com
EMail: tnadeau@cisco.com
Ayan Banerjee Calient 5853 Rue Ferrari San Jose, CA 95138, USA
美国加利福尼亚州圣何塞法拉利街5853号，邮编95138
EMail: abanerjee@calient.net
EMail: abanerjee@calient.net
Lyndon Ong Ciena 10480 Ridgeview Ct Cupertino, CA 95014, USA
林登·翁·西纳10480里吉维尤Ct库珀蒂诺，加利福尼亚州95014，美国
EMail: lyong@ciena.com
EMail: lyong@ciena.com
Debashis Basak Accelight 70 Abele Road, Bldg.1200 Bridgeville, PA 15017, USA
美国宾夕法尼亚州布里奇维尔市亚伯路70号楼Debashis Basak Acceleright，邮编：15017
EMail: dbasak@accelight.com
EMail: dbasak@accelight.com
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
迪米特里·帕帕迪米特里奥·阿尔卡特·弗朗西斯·韦勒斯普林，1 B-2018比利时安特卫普
EMail: dimitri.papadimitriou@alcatel.be
EMail: dimitri.papadimitriou@alcatel.be
Lou Berger Movaz 7926 Jones Branch Drive MCLean VA, 22102, USA
Lou Berger Movaz 7926 Jones Branch Drive MCLean VA，美国22102
EMail: lberger@movaz.com
EMail: lberger@movaz.com
Dimitrios Pendarakis Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Dimitrios Pendarakis Tellium 2 Crescent Place，美国新泽西州海港901号邮政信箱07757-0901
EMail: dpendarakis@tellium.com
EMail: dpendarakis@tellium.com
Greg Bernstein Grotto
格雷格·伯恩斯坦石窟
EMail: gregb@grotto-networking.com
EMail: gregb@grotto-networking.com
Bala Rajagopalan Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
美国新泽西州Oceanport 901号邮政信箱新月广场2号巴拉·拉贾戈帕兰Tellium 07757-0901
EMail: braja@tellium.com
EMail: braja@tellium.com
Sudheer Dharanikota Consult
苏德尔·达兰尼科塔咨询公司
EMail: sudheer@ieee.org
EMail: sudheer@ieee.org
Yakov Rekhter Juniper 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
美国加利福尼亚州桑尼维尔马蒂尔达大道北1194号亚科夫·雷克特·朱尼珀，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
John Drake Calient 5853 Rue Ferrari San Jose, CA 95138, USA
美国加利福尼亚州圣何塞法拉利街5853号，邮编95138
EMail: jdrake@calient.net
EMail: jdrake@calient.net
Debanjan Saha Tellium 2 Crescent Place Oceanport, NJ 07757-0901, USA
Debanjan Saha Tellium 2 Crescent Place Oceanport，NJ 07757-0901，美国
EMail: dsaha@tellium.com
EMail: dsaha@tellium.com
Yanhe Fan Axiowave 200 Nickerson Road Marlborough, MA 01752, USA
美国马萨诸塞州马尔伯勒尼克森路200号延河Fan Axiowave邮编01752
EMail: yfan@axiowave.com
EMail: yfan@axiowave.com
Hal Sandick Shepard M.S. 2401 Dakota Street Durham, NC 27705, USA
美国北卡罗来纳州达勒姆市达科他街2401号Hal Sandick Shepard M.S.邮编：27705
EMail: sandick@nc.rr.com
EMail: sandick@nc.rr.com
Don Fedyk Nortel 600 Technology Park Drive Billerica, MA 01821, USA
Don Fedyk Nortel 600科技园大道Billerica，马萨诸塞州01821
EMail: dwfedyk@nortelnetworks.com
EMail: dwfedyk@nortelnetworks.com
Vishal Sharma Metanoia 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA
Vishal Sharma Metanoia美国加利福尼亚州山景城352单元别墅街1600号，邮编94041
EMail: v.sharma@ieee.org
EMail: v.sharma@ieee.org
Gert Grammel Alcatel Lorenzstrasse, 10 70435 Stuttgart, Germany
Gert Grammel Alcatel Lorenzstrasse，10 70435斯图加特，德国
EMail: gert.grammel@alcatel.de
EMail: gert.grammel@alcatel.de
George Swallow Cisco 250 Apollo Drive Chelmsford, MA 01824, USA
美国马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Dan Guo Turin 1415 N. McDowell Blvd, Petaluma, CA 95454, USA
Dan Guo都灵美国加利福尼亚州佩塔卢马市麦克道尔大道北1415号，邮编95454
EMail: dguo@turinnetworks.com
EMail: dguo@turinnetworks.com
Z. Bo Tang Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Z.Bo Tang Tellium 2 Crescent Place，美国新泽西州海港901号邮政信箱07757-0901
EMail: btang@tellium.com
EMail: btang@tellium.com
Kireeti Kompella Juniper 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
Kireeti Kompella Juniper 1194 N.Mathilda Ave.Sunnyvale，加利福尼亚州94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Jennifer Yates AT&T 180 Park Avenue Florham Park, NJ 07932, USA
Jennifer Yates AT&T美国新泽西州弗洛勒姆公园公园大道180号，邮编07932
EMail: jyates@research.att.com
EMail: jyates@research.att.com
Alan Kullberg NetPlane 888 Washington St.Dedham, MA 02026, USA
Alan Kullberg网络飞机888华盛顿圣德汉姆，马萨诸塞州02026
EMail: akullber@netplane.com
EMail: akullber@netplane.com
George R. Young Edgeflow 329 March Road Ottawa, Ontario, K2K 2E1, Canada
加拿大安大略省渥太华三月路329号，K2K 2E1，George R.Young Edgeflow
EMail: george.young@edgeflow.com
EMail: george.young@edgeflow.com
Jonathan P. Lang Rincon Networks
Jonathan P.Lang Rincon网络公司
EMail: jplang@ieee.org
EMail: jplang@ieee.org
John Yu Hammerhead Systems 640 Clyde Court Mountain View, CA 94043, USA
John Yu Hammerhead Systems 640 Clyde Court Mountain View，加利福尼亚州94043，美国
EMail: john@hammerheadsystems.com
EMail: john@hammerheadsystems.com
Fong Liaw Solas Research Solas Research, LLC
Fong Liaw Solas Research Solas Research有限责任公司
EMail: fongliaw@yahoo.com
EMail: fongliaw@yahoo.com
Alex Zinin Alcatel 1420 North McDowell Ave Petaluma, CA 94954, USA
美国加利福尼亚州佩塔卢马北麦克道尔大道1420号亚历克斯·齐宁阿尔卡特，邮编94954
EMail: alex.zinin@alcatel.com
EMail: alex.zinin@alcatel.com
Eric Mannie (Consultant) Avenue de la Folle Chanson, 2 B-1050 Brussels, Belgium Phone: +32 2 648-5023 Mobile: +32 (0)495-221775
Eric Mannie（顾问）de la Folle Chanson大道2号B-1050比利时布鲁塞尔电话：+32 2 648-5023手机：+32（0）495-221775
EMail: eric_mannie@hotmail.com
EMail: eric_mannie@hotmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。