Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 7062 D. Li
Category: Informational Huawei
ISSN: 2070-1721 H. Li
CMCC
S. Belotti
Alcatel-Lucent
D. Ceccarelli
Ericsson
November 2013
Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 7062 D. Li
Category: Informational Huawei
ISSN: 2070-1721 H. Li
CMCC
S. Belotti
Alcatel-Lucent
D. Ceccarelli
Ericsson
November 2013
Framework for GMPLS and PCE Control of G.709 Optical Transport Networks
G.709光传输网络的GMPLS和PCE控制框架
Abstract
摘要
This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012.
本文件提供了一个框架，允许开发协议扩展，以支持2012年发布的ITU-T建议G.709中规定的光传输网络（OTN）的通用多协议标签交换（GMPLS）和路径计算元件（PCE）控制。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7062.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7062.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. G.709 Optical Transport Network .................................4
3.1. OTN Layer Network ..........................................5
3.1.1. Client Signal Mapping ...............................6
3.1.2. Multiplexing ODUj onto Links ........................7
3.1.2.1. Structure of MSI Information ...............9
4. Connection Management in OTN ...................................10
4.1. Connection Management of the ODU ..........................11
5. GMPLS/PCE Implications .........................................13
5.1. Implications for Label Switched Path (LSP) Hierarchy ......13
5.2. Implications for GMPLS Signaling ..........................14
5.3. Implications for GMPLS Routing ............................16
5.4. Implications for Link Management Protocol .................18
5.5. Implications for Control-Plane Backward Compatibility .....19
5.6. Implications for Path Computation Elements ................20
5.7. Implications for Management of GMPLS Networks .............20
6. Data-Plane Backward Compatibility Considerations ...............21
7. Security Considerations ........................................21
8. Acknowledgments ................................................22
9. Contributors ...................................................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................24
1. Introduction ....................................................3
2. Terminology .....................................................3
3. G.709 Optical Transport Network .................................4
3.1. OTN Layer Network ..........................................5
3.1.1. Client Signal Mapping ...............................6
3.1.2. Multiplexing ODUj onto Links ........................7
3.1.2.1. Structure of MSI Information ...............9
4. Connection Management in OTN ...................................10
4.1. Connection Management of the ODU ..........................11
5. GMPLS/PCE Implications .........................................13
5.1. Implications for Label Switched Path (LSP) Hierarchy ......13
5.2. Implications for GMPLS Signaling ..........................14
5.3. Implications for GMPLS Routing ............................16
5.4. Implications for Link Management Protocol .................18
5.5. Implications for Control-Plane Backward Compatibility .....19
5.6. Implications for Path Computation Elements ................20
5.7. Implications for Management of GMPLS Networks .............20
6. Data-Plane Backward Compatibility Considerations ...............21
7. Security Considerations ........................................21
8. Acknowledgments ................................................22
9. Contributors ...................................................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................24
Optical Transport Networks (OTNs) have become a mainstream layer 1 technology for the transport network. Operators want to introduce control-plane capabilities based on GMPLS to OTN to realize the benefits associated with a high-function control plane (e.g., improved network resiliency, resource usage efficiency, etc.).
光传输网络（OTN）已成为传输网络的主流第1层技术。运营商希望将基于GMPLS的控制平面功能引入OTN，以实现与高功能控制平面相关的好处（例如，提高网络弹性、资源使用效率等）。
GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass Time Division Multiplexing (TDM) networks (e.g., Synchronous Optical NETwork (SONET) / Synchronous Digital Hierarchy (SDH), Plesiochronous Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching optical networks, and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The GMPLS architecture is provided in [RFC3945], signaling function and Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC3473], routing and Open Shortest Path First (OSPF) extensions are described in [RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is described in [RFC4204].
GMPLS将多协议标签交换（MPLS）扩展到包括时分复用（TDM）网络（例如，同步光网络（SONET）/同步数字体系（SDH）、准同步数字体系（PDH）和g.709子lambda）、lambda交换光网络和空间交换（例如，输入端口或光纤到输出端口或光纤）。GMPLS体系结构在[RFC3945]中提供，[RFC3471]和[RFC3473]中描述了信令功能和资源预留协议-流量工程（RSVP-TE）扩展，[RFC4202]和[RFC4203]中描述了路由和开放最短路径优先（OSPF）扩展[RFC4204]中描述了链路管理协议（LMP）。
The GMPLS signaling extensions defined in [RFC4328] provide the mechanisms for basic GMPLS control of OTN based on the 2001 revision of the G.709 specification. The 2012 revision of the G.709 specification, [G709-2012], includes new features, for example, various multiplexing structures, two types of Tributary Slots (TSs) (i.e., 1.25 Gbps and 2.5G bps), and extension of the Optical channel Data Unit-j (ODUj) definition to include the ODUflex function.
[RFC4328]中定义的GMPLS信令扩展提供了基于2001年G.709规范修订版的OTN基本GMPLS控制机制。G.709规范的2012年修订版[G709-2012]包括新功能，例如，各种多路复用结构、两种类型的分支插槽（TSs）（即1.25 Gbps和2.5G bps），以及扩展光信道数据单元-j（ODUj）定义以包括ODUflex功能。
This document reviews relevant aspects of OTN technology evolution that affect the GMPLS control-plane protocols and examines why and how to update the mechanisms described in [RFC4328]. This document additionally provides a framework for GMPLS control of OTN and includes a discussion of the implications for the use of the PCE [RFC4655].
本文件回顾了影响GMPLS控制平面协议的OTN技术发展的相关方面，并探讨了为什么以及如何更新[RFC4328]中描述的机制。本文件还提供了OTN的GMPLS控制框架，并包括对PCE使用影响的讨论[RFC4655]。
For the purposes of the control plane, the OTN can be considered to be comprised of ODU and wavelength (Optical Channel (OCh)) layers. This document focuses on the control of the ODU layer, with control of the wavelength layer considered out of the scope. Please refer to [RFC6163] for further information about the wavelength layer.
出于控制平面的目的，可以认为OTN由ODU和波长（光信道（OCh））层组成。本文档重点关注ODU层的控制，波长层的控制被认为超出了范围。有关波长层的更多信息，请参考[RFC6163]。
OTN: Optical Transport Network
光传输网
OPU: Optical Channel Payload Unit
OPU：光信道有效负载单元
ODU: Optical Channel Data Unit
光通道数据单元
OTU: Optical Channel Transport Unit
光信道传输单元
OMS: Optical Multiplex Section
光多路复用部分
MSI: Multiplex Structure Identifier
多路复用结构标识符
TPN: Tributary Port Number
TPN：支路端口号
LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, or flex) represents the container transporting a client of the OTN that is either directly mapped into an OTUk (k = j) or multiplexed into a server HO ODUk (k > j) container.
LO ODU：低阶ODU。LO ODUj（j可以是0、1、2、2e、3、4或flex）表示运输OTN的客户端的容器，该客户端或者直接映射到OTUk（k＝j）中，或者复用到服务器HO ODUk（k＞j）容器中。
HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, or 4) represents the entity transporting a multiplex of LO ODUj tributary signals in its OPUk area.
高阶ODU。HO ODUk（k可以是1、2、2e、3或4）表示在其OPUk区域传输LO ODUj支路信号多路复用的实体。
ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a bit rate tolerance of +/-100 ppm (parts per million).
ODUflex：灵活的ODU。灵活的ODUk可以具有任何比特率和+/-100 ppm（百万分之一）的比特率容差。
In general, throughout this document, "ODUj" is used to refer to ODU entities acting as an LO ODU, and "ODUk" is used to refer to ODU entities being used as an HO ODU.
一般而言，在本文件中，“ODUj”用于指代作为LO ODU的ODU实体，“ODUk”用于指代作为HO ODU的ODU实体。
This section provides an informative overview of the aspects of the OTN impacting control-plane protocols. This overview is based on the ITU-T Recommendations that contain the normative definition of the OTN. Technical details regarding OTN architecture and interfaces are provided in the relevant ITU-T Recommendations.
本节提供了OTN影响控制平面协议方面的信息性概述。本概述基于包含OTN规范性定义的ITU-T建议。有关OTN体系结构和接口的技术细节见相关ITU-T建议。
Specifically, [G872-2012] describes the functional architecture of optical transport networks providing optical signal transmission, multiplexing, routing, supervision, performance assessment, and network survivability. The legacy OTN referenced by [RFC4328] defines the interfaces of the optical transport network to be used within and between subnetworks of the optical network. With the evolution and deployment of OTN technology, many new features have been specified in ITU-T recommendations, including, for example, new ODU0, ODU2e, ODU4, and ODUflex containers as described in [G709-2012].
具体而言，[G872-2012]描述了提供光信号传输、多路复用、路由、监控、性能评估和网络生存能力的光传输网络的功能架构。[RFC4328]引用的传统OTN定义了光网络子网内部和子网之间使用的光传输网络接口。随着OTN技术的发展和部署，ITU-T建议中规定了许多新功能，包括[G709-2012]中所述的新ODU0、ODU2e、ODU4和ODUflex容器。
The simplified signal hierarchy of OTN is shown in Figure 1, which illustrates the layers that are of interest to the control plane. Other layers below OCh (e.g., Optical Transmission Section (OTS)) are not included in this figure. The full signal hierarchy is provided in [G709-2012].
OTN的简化信号层次如图1所示，图1显示了控制平面感兴趣的层。OCh下的其他层（如光传输段（OTS））不包括在本图中。完整的信号层次结构见[G709-2012]。
Client signal | ODUj | OTU/OCh OMS
客户信号| ODUj | OTU/OCh OMS
Figure 1: Basic OTN Signal Hierarchy
图1：基本OTN信号层次结构
Client signals are mapped into ODUj containers. These ODUj containers are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are combined in the OMS using Wavelength Division Multiplexing (WDM), and this aggregated signal provides the link between the nodes.
客户端信号映射到ODUj容器中。这些ODUj容器被多路复用到OTU/OCh上。各个OTU/OCh信号在OMS中使用波分复用（WDM）进行组合，该聚合信号提供节点之间的链路。
The client signals are mapped into an LO ODUj. The current values of j defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, and flex. The approximate bit rates of these signals are defined in [G709-2012] and are reproduced in Tables 1 and 2.
客户机信号被映射到LO ODUj中。[G709-2012]中定义的j的当前值为：0、1、2、2e、3、4和flex。这些信号的近似比特率在[G709-2012]中定义，并在表1和表2中再现。
+-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate |
+-----------------------+-----------------------------------+
| ODU0 | 1,244,160 Kbps |
| ODU1 | 239/238 x 2,488,320 Kbps |
| ODU2 | 239/237 x 9,953,280 Kbps |
| ODU3 | 239/236 x 39,813,120 Kbps |
| ODU4 | 239/227 x 99,532,800 Kbps |
| ODU2e | 239/237 x 10,312,500 Kbps |
| | |
| ODUflex for | |
|Constant Bit Rate (CBR)| 239/238 x client signal bit rate |
| Client signals | |
| | |
| ODUflex for Generic | |
| Framing Procedure | Configured bit rate |
| - Framed (GFP-F) | |
| Mapped client signal | |
+-----------------------+-----------------------------------+
+-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate |
+-----------------------+-----------------------------------+
| ODU0 | 1,244,160 Kbps |
| ODU1 | 239/238 x 2,488,320 Kbps |
| ODU2 | 239/237 x 9,953,280 Kbps |
| ODU3 | 239/236 x 39,813,120 Kbps |
| ODU4 | 239/227 x 99,532,800 Kbps |
| ODU2e | 239/237 x 10,312,500 Kbps |
| | |
| ODUflex for | |
|Constant Bit Rate (CBR)| 239/238 x client signal bit rate |
| Client signals | |
| | |
| ODUflex for Generic | |
| Framing Procedure | Configured bit rate |
| - Framed (GFP-F) | |
| Mapped client signal | |
+-----------------------+-----------------------------------+
Table 1: ODU Types and Bit Rates
表1：ODU类型和比特率
NOTE: The nominal ODUk rates are approximately: 2,498,775.126 Kbps (ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3), 104,794,445.815 Kbps (ODU4), and 10,399,525.316 Kbps (ODU2e).
注：名义ODUk速率约为：2498775.126 Kbps（ODU1）、10037273.924 Kbps（ODU2）、40319218.983 Kbps（ODU3）、104794445.815 Kbps（ODU4）和10399525.316 Kbps（ODU2e）。
+-----------------------+-----------------------------------+
| ODU Type | ODU bit rate tolerance |
+-----------------------+-----------------------------------+
| ODU0 | +/-20 ppm |
| ODU1 | +/-20 ppm |
| ODU2 | +/-20 ppm |
| ODU3 | +/-20 ppm |
| ODU4 | +/-20 ppm |
| ODU2e | +/-100 ppm |
| | |
| ODUflex for CBR | |
| Client signals | +/-100 ppm |
| | |
| ODUflex for GFP-F | |
| Mapped client signal | +/-100 ppm |
+-----------------------+-----------------------------------+
+-----------------------+-----------------------------------+
| ODU Type | ODU bit rate tolerance |
+-----------------------+-----------------------------------+
| ODU0 | +/-20 ppm |
| ODU1 | +/-20 ppm |
| ODU2 | +/-20 ppm |
| ODU3 | +/-20 ppm |
| ODU4 | +/-20 ppm |
| ODU2e | +/-100 ppm |
| | |
| ODUflex for CBR | |
| Client signals | +/-100 ppm |
| | |
| ODUflex for GFP-F | |
| Mapped client signal | +/-100 ppm |
+-----------------------+-----------------------------------+
Table 2: ODU Types and Tolerance
表2：ODU类型和公差
One of two options is for mapping client signals into ODUflex depending on the client signal type:
两个选项之一是根据客户机信号类型将客户机信号映射到ODUflex：
- Circuit clients are proportionally wrapped. Thus, the bit rate is defined by the client signal, and the tolerance is fixed to +/-100 ppm.
- 电路客户端按比例包装。因此，比特率由客户机信号定义，容差固定为+/-100 ppm。
- Packet clients are mapped using the Generic Framing Procedure (GFP). [G709-2012] recommends that the ODUflex(GFP) will fill an integral number of tributary slots of the smallest HO ODUk path over which the ODUflex(GFP) may be carried, and the tolerance should be +/-100 ppm.
- 使用通用帧过程（GFP）映射数据包客户端。[G709-2012]建议ODUflex（GFP）将填充可承载ODUflex（GFP）的最小HO-ODUk路径的完整数量的支流槽，公差应为+/-100 ppm。
Note that additional information on G.709 client mapping can be found in [G7041].
请注意，有关G.709客户端映射的其他信息可在[G7041]中找到。
The links between the switching nodes are provided by one or more wavelengths. Each wavelength carries one OCh, which carries one OTU, which carries one ODU. Since all of these signals have a 1:1:1 relationship, we only refer to the OTU for clarity. The ODUjs are mapped into the TSs (Tributary Slots) of the OPUk. Note that in the case where j=k, the ODUj is mapped into the OTU/OCh without multiplexing.
交换节点之间的链路由一个或多个波长提供。每个波长携带一个OCh，它携带一个OTU，它携带一个ODU。由于所有这些信号都具有1:1:1的关系，因此为了清楚起见，我们仅参考OTU。ODUJ映射到OPUk的TSs（分支插槽）。注意，在j＝k的情况下，ODUj被映射到OTU/OCh而不进行复用。
The initial versions of G.709 referenced by [RFC4328] only provided a single TS granularity, nominally 2.5 Gbps. [G709-2012] added an additional TS granularity, nominally 1.25 Gbps. The number and type of TS provided by each of the currently identified OTUk are provided below:
[RFC4328]引用的G.709的初始版本仅提供单一TS粒度，名义上为2.5 Gbps。[G709-2012]增加了额外的TS粒度，名义上为1.25 Gbps。每个当前确定的OTUk提供的TS数量和类型如下所示：
Tributary Slot Granularity 2.5 Gbps 1.25 Gbps Nominal Bit Rate OTU1 1 2 2.5 Gbps OTU2 4 8 10 Gbps OTU3 16 32 40 Gbps OTU4 -- 80 100 Gbps
支路时隙粒度2.5 Gbps 1.25 Gbps标称比特率OTU1 12.5 Gbps OTU2 4 8 10 Gbps OTU3 16 32 40 Gbps OTU4--80 100 Gbps
To maintain backward compatibility while providing the ability to interconnect nodes that support a 1.25 Gbps TS at one end of a link and a 2.5 Gbps TS at the other, [G709-2012] requires 'new' equipment to fall back to the use of a 2.5 Gbps TS when connected to legacy equipment. This information is carried in band by the payload type.
为了保持向后兼容性，同时提供互连节点的能力，这些节点在链路一端支持1.25 Gbps TS，在另一端支持2.5 Gbps TS，[G709-2012]要求“新”设备在连接到传统设备时退回到使用2.5 Gbps TS。该信息由有效负载类型在频带内传送。
The actual bit rate of the TS in an OTUk depends on the value of k. Thus, the number of TSs occupied by an ODUj may vary depending on the values of j and k. For example, an ODU2e uses 9 TSs in an OTU3 but only 8 in an OTU4. Examples of the number of TSs used for various cases are provided below (referring to Tables 7-9 of [G709-2012]):
OTUk中TS的实际比特率取决于k的值。因此，由ODUj占用的TSs的数量可以根据j和k的值而变化。例如，ODU2e在OTU3中使用9个TSs，但在OTU4中仅使用8个TSs。各种情况下使用的TSs数量示例如下（参考[G709-2012]表7-9）：
- ODU0 into ODU1, ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS granularity o ODU0 occupies 1 of the 2, 8, 32, or 80 TSs for ODU1, ODU2, ODU3, or ODU4
- ODU0到ODU1、ODU2、ODU3或ODU4的复用具有1.25 Gbps TS粒度。ODU0占用ODU1、ODU2、ODU3或ODU4的2、8、32或80个TSs中的1个
- ODU1 into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS granularity o ODU1 occupies 2 of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4
- ODU1到ODU2、ODU3或ODU4的复用具有1.25 Gbps TS粒度。对于ODU2、ODU3或ODU4，ODU1占用8、32或80个TSs中的2个
- ODU1 into ODU2 or ODU3 multiplexing with 2.5 Gbps TS granularity o ODU1 occupies 1 of the 4 or 16 TSs for ODU2 or ODU3
- ODU1到ODU2或ODU3的复用具有2.5 Gbps TS粒度。ODU1占用ODU2或ODU3的4个或16个TS中的1个
- ODU2 into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity o ODU2 occupies 8 of the 32 or 80 TSs for ODU3 or ODU4
- ODU2到ODU3或ODU4的复用具有1.25 Gbps的TS粒度。对于ODU3或ODU4，ODU2占用32或80个TS中的8个
- ODU2 into ODU3 multiplexing with 2.5 Gbps TS granularity o ODU2 occupies 4 of the 16 TSs for ODU3
- ODU2到ODU3的复用具有2.5 Gbps的TS粒度。ODU2占用ODU3的16个TS中的4个
- ODU3 into ODU4 multiplexing with 1.25 Gbps TS granularity o ODU3 occupies 31 of the 80 TSs for ODU4
- ODU3到ODU4的复用具有1.25 Gbps的TS粒度。ODU3占用ODU4的80个TS中的31个
- ODUflex into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS granularity o ODUflex occupies n of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4 (n <= Total TS number of ODUk)
- ODUflex到ODU2、ODU3或ODU4的多路复用具有1.25 Gbps TS粒度o ODUflex占用ODU2、ODU3或ODU4的8、32或80个TS中的n个（n<=ODUk的总TS数）
- ODU2e into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity o ODU2e occupies 9 of the 32 TSs for ODU3 or 8 of the 80 TSs for ODU4
- ODU2e到ODU3或ODU4多路复用的粒度为1.25 Gbps，ODU2e占用ODU3的32个TSs中的9个或ODU4的80个TSs中的8个
In general, the mapping of an ODUj (including ODUflex) into a specific OTUk TS is determined locally, and it can also be explicitly controlled by a specific entity (e.g., head end or Network Management System (NMS)) through Explicit Label Control [RFC3473].
通常，ODUj（包括ODUflex）到特定OTUk TS的映射在本地确定，并且它也可以通过显式标签控制由特定实体（例如，前端或网络管理系统（NMS））显式控制[RFC3473]。
When multiplexing an ODUj into an HO ODUk (k>j), G.709 specifies the information that has to be transported in-band in order to allow for correct demultiplexing. This information, known as MSI, is transported in the OPUk overhead and is local to each link. In case of bidirectional paths, the association between the TPN and TS must be the same in both directions.
当将ODUj复用到HO ODUk（k>j）中时，G.709规定了必须在频带内传输的信息，以便允许正确的解复用。该信息称为MSI，在OPUk开销中传输，并且是每个链路的本地信息。在双向路径的情况下，TPN和TS之间的关联在两个方向上必须相同。
The MSI information is organized as a set of entries, with one entry for each HO ODUj TS. The information carried by each entry is:
MSI信息被组织为一组条目，每个HO ODUj TS有一个条目。每个条目携带的信息为：
- Payload Type: the type of the transported payload.
- 有效负载类型：传输的有效负载的类型。
- TPN: the port number of the ODUj transported by the HO ODUk. The TPN is the same for all the TSs assigned to the transport of the same ODUj instance.
- TPN：由HO ODUk运输的ODUj的端口号。TPN对于分配给同一ODUj实例的传输的所有TSs是相同的。
For example, an ODU2 carried by an HO ODU3 is described by 4 entries in the OPU3 overhead when the TS granularity is 2.5 Gbps, and by 8 entries when the TS granularity is 1.25 Gbps.
例如，当TS粒度为2.5 Gbps时，由HO ODU3承载的ODU2由OPU3开销中的4个条目描述，当TS粒度为1.25 Gbps时，由8个条目描述。
On each node and on every link, two MSI values have to be provisioned (referring to [G798]):
在每个节点和每个链路上，必须设置两个MSI值（参考[G798]）：
- The Transmitted MSI (TxMSI) information inserted in OPU (e.g., OPU3) overhead by the source of the HO ODUk trail.
- 由HO ODUk trail的源在OPU（例如，OPU3）开销中插入的传输MSI（TxMSI）信息。
- The Expected MSI (ExMSI) information that is used to check the Accepted MSI (AcMSI) information. The AcMSI information is the MSI valued received in-band, after a three-frame integration.
- 用于检查接受的MSI（AcMSI）信息的预期MSI（ExMSI）信息。AcMSI信息是经过三帧积分后在频带内接收的MSI值。
As described in [G798], the sink of the HO ODU trail checks the complete content of the AcMSI information against the ExMSI. If the AcMSI is different from the ExMSI, then the traffic is dropped, and a payload mismatch alarm is generated.
如[G798]所述，HO ODU跟踪的接收器根据ExMSI检查AcMSI信息的完整内容。如果AcMSI与ExMSI不同，则会丢弃通信量，并生成有效负载不匹配警报。
Provisioning of TPN can be performed by either a network management system or control plane. In the last case, the control plane is also responsible for negotiating the provisioned values on a link-by-link basis.
TPN的供应可由网络管理系统或控制平面执行。在最后一种情况下，控制平面还负责逐个链路协商所提供的值。
OTN-based connection management is concerned with controlling the connectivity of ODU paths and OCh. This document focuses on the connection management of ODU paths. The management of OCh paths is described in [RFC6163].
基于OTN的连接管理涉及控制ODU路径和OCh的连接。本文档重点介绍ODU路径的连接管理。[RFC6163]中描述了OCh路径的管理。
While [G872-2001] considered the ODU to be a set of layers in the same way as SDH has been modeled, recent ITU-T OTN architecture progress [G872-2012] includes an agreement to model the ODU as a single-layer network with the bit rate as a parameter of links and connections. This allows the links and nodes to be viewed in a single topology as a common set of resources that are available to provide ODUj connections independent of the value of j. Note that when the bit rate of ODUj is less than the server bit rate, ODUj connections are supported by HO ODU (which has a one-to-one relationship with the OTU).
虽然[G872-2001]认为ODU是一组层，其建模方式与SDH相同，但最近的ITU-T OTN架构进展[G872-2012]包括一项协议，将ODU建模为单层网络，比特率作为链路和连接的参数。这允许在单个拓扑中将链接和节点视为一组公共资源，这些资源可用于提供独立于j值的ODUj连接。请注意，当ODUj的比特率小于服务器比特率时，HO ODU支持ODUj连接（它与OTU有一对一的关系）。
From an ITU-T perspective, the ODU connection topology is represented by that of the OTU link layer, which has the same topology as that of the OCh layer (independent of whether the OTU supports an HO ODU, where multiplexing is utilized, or an LO ODU in the case of direct mapping).
从ITU-T的角度来看，ODU连接拓扑由OTU链路层的拓扑表示，OTU链路层的拓扑与OCh层的拓扑相同（独立于OTU是否支持HO ODU，其中使用多路复用，或者在直接映射的情况下支持LO ODU）。
Thus, the OTU and OCh layers should be visible in a single topological representation of the network, and from a logical perspective, the OTU and OCh may be considered as the same logical, switchable entity.
因此，OTU和OCh层应在网络的单个拓扑表示中可见，并且从逻辑角度来看，OTU和OCh可被视为相同的逻辑、可切换实体。
Note that the OTU link-layer topology may be provided via various infrastructure alternatives, including point-to-point optical connections, optical connections fully in the optical domain, and optical connections involving hybrid sub-lambda/lambda nodes involving 3R, etc. See [RFC6163] for additional information.
注意，OTU链路层拓扑可以通过各种基础设施备选方案提供，包括点到点光连接、完全在光域中的光连接以及涉及3R的混合子lambda/lambda节点的光连接等。有关更多信息，请参阅[RFC6163]。
An LO ODUj can be either mapped into the OTUk signal (j = k) or multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is mapped into an OCh.
LO-ODUj可以映射到OTUk信号（j＝k）或与其他LO-ODUj复用到OTUk（j＜k），并且OTUk映射到OCh。
From the perspective of the control plane, there are two kinds of network topology to be considered.
从控制平面的角度来看，有两种网络拓扑需要考虑。
(1) ODU layer
(1) ODU层
In this case, the ODU links are presented between adjacent OTN nodes, as illustrated in Figure 2. In this layer, there are ODU links with a variety of TSs available, and nodes that are Optical Digital Cross Connects (ODXCs). LO ODU connections can be set up based on the network topology.
在这种情况下，ODU链路出现在相邻OTN节点之间，如图2所示。在这一层中，有各种可用TSs的ODU链路，以及光数字交叉连接（ODXC）节点。可以根据网络拓扑设置LO ODU连接。
Link #5 +--+---+--+ Link #4
+--------------------------| |--------------------------+
| | ODXC | |
| +---------+ |
| Node E |
| |
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
| |Link #1 | |Link #2 | |Link #3 | |
| |--------| |--------| |--------| |
| ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node D
Link #5 +--+---+--+ Link #4
+--------------------------| |--------------------------+
| | ODXC | |
| +---------+ |
| Node E |
| |
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
| |Link #1 | |Link #2 | |Link #3 | |
| |--------| |--------| |--------| |
| ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node D
Figure 2: Example Topology for LO ODU Connection Management
图2：LO ODU连接管理的示例拓扑
If an ODUj connection is requested between Node C and Node E, routing/path computation must select a path that has the required number of TSs available and that offers the lowest cost. Signaling is then invoked to set up the path and to provide the information (e.g., selected TSs) required by each transit node to allow the configuration of the ODUj-to-OTUk mapping (j = k) or multiplexing (j < k) and demapping (j = k) or demultiplexing (j < k).
如果在节点C和节点E之间请求ODUj连接，则路由/路径计算必须选择具有所需可用TSs数量且成本最低的路径。然后调用信令来设置路径并提供每个传输节点所需的信息（例如，所选的TSs），以允许配置ODUj到OTUk映射（j＝k）或复用（j＜k）和解映射（j＝k）或解复用（j＜k）。
(2) ODU layer with OCh switching capability
(2) 具有OCh交换能力的ODU层
In this case, the OTN nodes interconnect with wavelength switched nodes (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM) or Optical Cross-Connect (OXC)) that are capable of OCh switching; this is illustrated in Figures 3 and 4. There are the ODU layer and the OCh layer, so it is simply a Multi-Layer Network (MLN) (see
在这种情况下，OTN节点与能够进行OCh交换的波长交换节点（例如，可重构光分插复用器（ROADM）或光交叉连接（OXC））互连；图3和图4对此进行了说明。有ODU层和OCh层，因此它只是一个多层网络（MLN）（参见
[RFC6001]). OCh connections may be created on demand, which is described in Section 5.1.
[RFC6001]）。OCh连接可根据需要创建，如第5.1节所述。
In this case, an operator may choose to allow the underlying OCh layer to be visible to the ODU routing/path computation process, in which case the topology would be as shown in Figure 4. In Figure 3, however, a cloud representing OCh-capable switching nodes is represented. In Figure 3, the operator choice is to hide the real OCh-layer network topology.
在这种情况下，操作员可以选择允许ODU路由/路径计算过程可以看到底层OCh层，在这种情况下，拓扑将如图4所示。然而，在图3中，表示具有OCh能力的交换节点的云被表示。在图3中，运营商的选择是隐藏真实的OCh层网络拓扑。
Node E
Link #5 +--------+ Link #4
+------------------------| |------------------------+
| ------ |
| // \\ |
| || || |
| | OCh domain | |
+-+-----+ +------ || || ------+ +-----+-+
| | | \\ // | | |
| |Link #1 | -------- |Link #3 | |
| +--------+ | | +--------+ +
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+Link #2 +---------+ +-------+
Node A Node B Node C Node D
Node E
Link #5 +--------+ Link #4
+------------------------| |------------------------+
| ------ |
| // \\ |
| || || |
| | OCh domain | |
+-+-----+ +------ || || ------+ +-----+-+
| | | \\ // | | |
| |Link #1 | -------- |Link #3 | |
| +--------+ | | +--------+ +
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+Link #2 +---------+ +-------+
Node A Node B Node C Node D
Figure 3: OCh Hidden Topology for LO ODU Connection Management
图3:LO ODU连接管理的OCh隐藏拓扑
Link #5 +---------+ Link #4
+------------------------| |-----------------------+
| +----| ODXC |----+ |
| +-++ +---------+ ++-+ |
| Node f | | Node E | | Node g |
| +-++ ++-+ |
| | +--+ | |
+-+-----+ +----+----+--| |--+-----+---+ +-----+-+
| |Link #1 | | +--+ | |Link #3 | |
| +--------+ | Node h | +--------+ |
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+ Link #2+---------+ +-------+
Node A Node B Node C Node D
Link #5 +---------+ Link #4
+------------------------| |-----------------------+
| +----| ODXC |----+ |
| +-++ +---------+ ++-+ |
| Node f | | Node E | | Node g |
| +-++ ++-+ |
| | +--+ | |
+-+-----+ +----+----+--| |--+-----+---+ +-----+-+
| |Link #1 | | +--+ | |Link #3 | |
| +--------+ | Node h | +--------+ |
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+ Link #2+---------+ +-------+
Node A Node B Node C Node D
Figure 4: OCh Visible Topology for LO ODUj Connection Management
图4:LO ODUj连接管理的OCh可见拓扑
In Figure 4, the cloud in the previous figure is substituted by the real topology. The nodes f, g, and h are nodes with OCh switching capability.
在图4中，上图中的云被实际拓扑所替代。节点f、g和h是具有OCh切换能力的节点。
In the examples (i.e., Figures 3 and 4), we have considered the case in which LO ODUj connections are supported by an OCh connection and the case in which the supporting underlying connection can also be made by a combination of HO ODU/OCh connections.
在示例（即图3和图4）中，我们考虑了LO ODUj连接由OCh连接支持的情况，以及支持基础连接也可以由HO ODU/OCh连接的组合进行的情况。
In this case, the ODU routing/path selection process will request an HO ODU/OCh connection between node C and node E from the OCh domain. The connection will appear at the ODU level as a Forwarding Adjacency, which will be used to create the ODU connection.
在这种情况下，ODU路由/路径选择过程将从OCh域请求节点C和节点E之间的HO ODU/OCh连接。该连接将在ODU级别显示为转发邻接，用于创建ODU连接。
The purpose of this section is to provide a set of requirements to be evaluated for extensions of the current GMPLS protocol suite and the PCE applications and protocols to encompass OTN enhancements and connection management.
本节的目的是提供一组需要评估的需求，以扩展当前的GMPLS协议套件和PCE应用程序和协议，包括OTN增强和连接管理。
The path computation for an ODU connection request is based on the topology of the ODU layer.
ODU连接请求的路径计算基于ODU层的拓扑。
The OTN path computation can be divided into two layers. One layer is OCh/OTUk; the other is ODUj. [RFC4206] and [RFC6107] define the mechanisms to accomplish creating the hierarchy of LSPs. The LSP management of multiple layers in OTN can follow the procedures defined in [RFC4206], [RFC6001], and [RFC6107].
OTN路径计算可分为两层。一层为OCh/OTUk；另一个是ODUj。[RFC4206]和[RFC6107]定义了完成创建LSP层次结构的机制。OTN中多层的LSP管理可以遵循[RFC4206]、[RFC6001]和[RFC6107]中定义的程序。
As discussed in Section 4, the route path computation for OCh is in the scope of the Wavelength Switched Optical Network (WSON) [RFC6163]. Therefore, this document only considers the ODU layer for an ODU connection request.
如第4节所述，OCh的路由路径计算在波长交换光网络（WSON）[RFC6163]的范围内。因此，本文档仅考虑ODU连接请求的ODU层。
The LSP hierarchy can also be applied within the ODU layers. One of the typical scenarios for ODU layer hierarchy is to maintain compatibility with introducing new [G709-2012] services (e.g., ODU0 and ODUflex) into a legacy network configuration (i.e., the legacy OTN referenced by [RFC4328]). In this scenario, it may be necessary to consider introducing hierarchical multiplexing capability in specific network transition scenarios. One method for enabling multiplexing hierarchy is by introducing dedicated boards in a few specific places in the network and tunneling these new services through the legacy containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade every network element to [G709-2012] capabilities.
LSP层次结构也可以应用于ODU层中。ODU层层次结构的典型场景之一是保持与将新的[G709-2012]服务（如ODU0和ODUflex）引入传统网络配置（即[RFC4328]引用的传统OTN）的兼容性。在这种情况下，可能需要考虑在特定的网络过渡场景中引入分层复用能力。启用多路复用层次结构的一种方法是，在网络中的几个特定位置引入专用板，并通过遗留容器（ODU1、ODU2、ODU3）对这些新服务进行隧道传输，从而推迟将每个网元升级到[G709-2012]功能的需要。
In such cases, one ODUj connection can be nested into another ODUk (j<k) connection, which forms the LSP hierarchy in the ODU layer. The creation of the outer ODUk connection can be triggered via network planning or by the signaling of the inner ODUj connection. For the former case, the outer ODUk connection can be created in advance based on network planning. For the latter case, the multi-layer network signaling described in [RFC4206], [RFC6107], and [RFC6001] (including related modifications, if needed) is relevant to create the ODU connections with multiplexing hierarchy. In both cases, the outer ODUk connection is advertised as a Forwarding Adjacency (FA).
在这种情况下，一个ODUj连接可以嵌套到另一个ODUk（j<k）连接中，这在ODU层中形成了LSP层次结构。外部ODUk连接的创建可以通过网络规划或内部ODUj连接的信令触发。对于前一种情况，可以根据网络规划提前创建外部ODUk连接。对于后一种情况，[RFC4206]、[RFC6107]和[RFC6001]中描述的多层网络信令（包括相关修改，如果需要）与创建具有复用层次结构的ODU连接相关。在这两种情况下，外部ODUk连接都被广告为转发邻接（FA）。
The signaling function and RSVP-TE extensions are described in [RFC3471] and [RFC3473]. For OTN-specific control, [RFC4328] defines signaling extensions to support control for the legacy G.709 Optical Transport Networks.
[RFC3471]和[RFC3473]中描述了信令功能和RSVP-TE扩展。对于OTN特定的控制，[RFC4328]定义了信令扩展，以支持对传统G.709光传输网络的控制。
As described in Section 3, [G709-2012] introduced some new features that include the ODU0, ODU2e, ODU4, and ODUflex containers. The mechanisms defined in [RFC4328] do not support such new OTN features, and protocol extensions will be necessary to allow them to be controlled by a GMPLS control plane.
如第3节所述，[G709-2012]引入了一些新功能，包括ODU0、ODU2e、ODU4和ODUflex容器。[RFC4328]中定义的机制不支持此类新的OTN功能，协议扩展将是必要的，以允许它们由GMPLS控制平面控制。
[RFC4328] defines the LSP Encoding Type, the Switching Type, and the Generalized Protocol Identifier (Generalized-PID) constituting the common part of the Generalized Label Request. The G.709 traffic parameters are also defined in [RFC4328]. In addition, the following signaling aspects not included in [RFC4328] should be considered:
[RFC4328]定义LSP编码类型、切换类型和通用协议标识符（通用PID），构成通用标签请求的公共部分。[RFC4328]中还定义了G.709流量参数。此外，应考虑[RFC4328]中未包括的以下信令方面：
- Support for specifying new signal types and related traffic information
- 支持指定新信号类型和相关交通信息
The traffic parameters should be extended in a signaling message to support the new ODUj, including:
应在信令消息中扩展业务参数，以支持新的ODUj，包括：
- ODU0 - ODU2e - ODU4 - ODUflex
- ODU0-ODU2e-ODU4-ODUflex
For the ODUflex signal type, the bit rate must be carried additionally in the traffic parameter to set up an ODUflex connection.
对于ODUflex信号类型，必须在流量参数中额外携带比特率，以建立ODUflex连接。
For other ODU signal types, the bit rates and tolerances are fixed and can be deduced from the signal types.
对于其他ODU信号类型，比特率和公差是固定的，并且可以从信号类型中推导出来。
- Support for LSP setup using different TS granularity
- 支持使用不同TS粒度的LSP设置
The signaling protocol should be able to identify the TS granularity (i.e., the 2.5 Gbps TS granularity and the new 1.25 Gbps TS granularity) to be used for establishing a Hierarchical LSP that will be used to carry service LSP(s) requiring a specific TS granularity.
信令协议应该能够识别用于建立将用于承载需要特定TS粒度的服务LSP的分层LSP的TS粒度（即，2.5 Gbps TS粒度和新的1.25 Gbps TS粒度）。
- Support for LSP setup of new ODUk/ODUflex containers with related mapping and multiplexing capabilities
- 支持新ODUk/ODUflex容器的LSP设置，并具有相关的映射和多路复用功能
A new label format must be defined to carry the exact TS's allocation information related to the extended mapping and multiplexing hierarchy (for example, ODU0 into ODU2 multiplexing (with 1.25 Gbps TS granularity)), in order to set up the ODU connection.
为了建立ODU连接，必须定义新的标签格式，以携带与扩展映射和复用层次结构（例如，ODU0到ODU2复用（具有1.25 Gbps TS粒度））相关的确切TS分配信息。
- Support for TPN allocation and negotiation
- 支持TPN分配和协商
TPN needs to be configured as part of the MSI information (see more information in Section 3.1.2.1). A signaling mechanism must be identified to carry TPN information if the control plane is used to configure MSI information.
TPN需要配置为MSI信息的一部分（参见第3.1.2.1节中的更多信息）。如果控制平面用于配置MSI信息，则必须识别一个信令机制以承载TPN信息。
- Support for ODU Virtual Concatenation (VCAT) and Link Capacity Adjustment Scheme (LCAS)
- 支持ODU虚拟连接（VCAT）和链路容量调整方案（LCAS）
GMPLS signaling should support the creation of Virtual Concatenation of an ODUk signal with k=1, 2, 3. The signaling should also support the control of dynamic capacity changing of a VCAT container using LCAS ([G7042]). [RFC6344] has a clear description of VCAT and LCAS control in SONET/SDH and OTN.
GMPLS信令应支持创建k=1、2、3的ODUk信号的虚拟级联。信号还应支持使用LCA（[G7042]）控制VCAT容器的动态容量变化。[RFC6344]清楚地描述了SONET/SDH和OTN中的VCAT和LCAS控制。
- Support for Control of Hitless Adjustment of ODUflex (GFP)
- 支持控制ODUflex（GFP）的无故障调整
[G7044] has been created in ITU-T to specify hitless adjustment of ODUflex (GFP) (HAO) that is used to increase or decrease the bandwidth of an ODUflex (GFP) that is transported in an OTN.
[G7044]已在ITU-T中创建，用于指定ODUflex（GFP）（HAO）的无故障调整，用于增加或减少OTN中传输的ODUflex（GFP）的带宽。
The procedure of ODUflex (GFP) adjustment requires the participation of every node along the path. Therefore, it is recommended to use control-plane signaling to initiate the adjustment procedure in order to avoid manual configuration at each node along the path.
ODUflex（GFP）调整过程需要路径上的每个节点参与。因此，建议使用控制平面信令来启动调整程序，以避免在路径上的每个节点处进行手动配置。
From the perspective of the control plane, control of ODUflex resizing is similar to control of bandwidth increasing and decreasing as described in [RFC3209]. Therefore, the Shared Explicit (SE) style can be used for control of HAO.
从控制平面的角度来看，ODUflex大小调整的控制类似于[RFC3209]中描述的带宽增加和减少的控制。因此，共享显式（SE）样式可用于控制HAO。
All the extensions above should consider the extensibility to match future evolvement of OTN.
以上所有扩展都应考虑可扩展性以匹配OTN未来的演进。
The path computation process needs to select a suitable route for an ODUj connection request. In order to perform the path computation, it needs to evaluate the available bandwidth on each candidate link. The routing protocol should be extended to convey sufficient information to represent ODU Traffic Engineering (TE) topology.
路径计算过程需要为ODUj连接请求选择合适的路由。为了执行路径计算，它需要评估每个候选链路上的可用带宽。路由协议应该扩展，以传递足够的信息来表示ODU流量工程（TE）拓扑。
The Interface Switching Capability Descriptors defined in [RFC4202] present a new constraint for LSP path computation. [RFC4203] defines the Switching Capability, related Maximum LSP Bandwidth, and Switching Capability specific information. When the Switching Capability field is TDM, the Switching Capability specific information field includes Minimum LSP Bandwidth, an indication whether the interface supports Standard or Arbitrary SONET/SDH, and padding. Hence, a new Switching Capability value needs to be defined for [G709-2012] ODU switching in order to allow the definition of a new Switching Capability specific information field. The following requirements should be considered:
[RFC4202]中定义的接口交换能力描述符为LSP路径计算提供了新的约束。[RFC4203]定义交换能力、相关最大LSP带宽和交换能力特定信息。当交换能力字段为TDM时，交换能力特定信息字段包括最小LSP带宽、接口是否支持标准或任意SONET/SDH的指示以及填充。因此，需要为[G709-2012]ODU交换定义新的交换能力值，以允许定义新的交换能力特定信息字段。应考虑以下要求：
- Support for carrying the link multiplexing capability
- 支持承载链路多路复用功能
As discussed in Section 3.1.2, many different types of ODUj can be multiplexed into the same OTUk. For example, both ODU0 and ODU1 may be multiplexed into ODU2. An OTU link may support one or more types of ODUj signals. The routing protocol should be capable of carrying this multiplexing capability.
如第3.1.2节所述，许多不同类型的ODUj可以复用到同一个OTUk中。例如，ODU0和ODU1都可以复用到ODU2中。OTU链路可支持一种或多种类型的ODUj信号。路由协议应该能够承载这种多路复用能力。
- Support any ODU and ODUflex
- 支持任何ODU和ODUflex
The bit rate (i.e., bandwidth) of each TS is dependent on the TS granularity and the signal type of the link. For example, the bandwidth of a 1.25 Gbps TS in an OTU2 is about 1.249409620 Gbps, while the bandwidth of a 1.25 Gbps TS in an OTU3 is about 1.254703729 Gbps.
每个TS的比特率（即带宽）取决于TS粒度和链路的信号类型。例如，OTU2中1.25 Gbps TS的带宽约为1.249409620 Gbps，而OTU3中1.25 Gbps TS的带宽约为1.254703729 Gbps。
One LO ODU may need a different number of TSs when multiplexed into different HO ODUs. For example, for ODU2e, 9 TSs are needed when multiplexed into an ODU3, while only 8 TSs are needed when
当多路复用到不同的HO ODU时，一个LO ODU可能需要不同数量的TSs。例如，对于ODU2e，当多路复用到ODU3中时需要9个TSs，而当多路复用到ODU3中时只需要8个TSs
multiplexed into an ODU4. For ODUflex, the total number of TSs to be reserved in an HO ODU equals the maximum of [bandwidth of ODUflex / bandwidth of TS of the HO ODU].
多路复用成一个ODU4。对于ODUflex，HO ODU中保留的TSs总数等于[ODUflex带宽/HO ODU TS带宽]的最大值。
Therefore, the routing protocol should be capable of carrying the necessary link bandwidth information for performing accurate route computation for any of the fixed rate ODUs as well as ODUflex.
因此，路由协议应该能够承载必要的链路带宽信息，以便为任何固定速率ODU以及ODUflex执行准确的路由计算。
- Support for differentiating between terminating and switching capability
- 支持区分端接和交换功能
Due to internal constraints and/or limitations, the type of signal being advertised by an interface could be restricted to switched (i.e., forwarded to switching matrix without multiplexing/demultiplexing actions), restricted to terminated (demuxed), or both. The capability advertised by an interface needs further distinction in order to separate termination and switching capabilities.
由于内部约束和/或限制，由接口播发的信号类型可限制为交换（即，转发到交换矩阵而不进行多路复用/解复用操作）、限制为终止（解复用）或两者兼而有之。接口公布的功能需要进一步区分，以便分离终端和交换功能。
Therefore, to allow the required flexibility, the routing protocol should clearly distinguish the terminating and switching capability.
因此，为了允许所需的灵活性，路由协议应该清楚地区分终止和交换能力。
- Support for Tributary Slot Granularity advertisement
- 支持分支插槽粒度广告
[G709-2012] defines two types of TSs, but each link can only support a single type at a given time. In order to perform a correct path computation (i.e., the LSP endpoints have matching Tributary Slot Granularity values) the Tributary Slot Granularity needs to be advertised.
[G709-2012]定义了两种类型的TSs，但每个链路在给定时间只能支持一种类型。为了执行正确的路径计算（即，LSP端点具有匹配的支路时隙粒度值），需要公布支路时隙粒度。
- Support different priorities for resource reservation
- 支持资源预留的不同优先级
How many priority levels should be supported depends on the operator's policy. Therefore, the routing protocol should be capable of supporting up to 8 priority levels as defined in [RFC4202].
应支持多少优先级取决于运营商的策略。因此，路由协议应能够支持[RFC4202]中定义的多达8个优先级。
- Support link bundling
- 支持链接绑定
As described in [RFC4201], link bundling can improve routing scalability by reducing the number of TE links that have to be handled by the routing protocol. The routing protocol should be capable of supporting the bundling of multiple OTU links, at the same line rate and muxing hierarchy, between a pair of nodes that a TE link does. Note that link bundling is optional and is implementation dependent.
如[RFC4201]所述，链路捆绑可以通过减少必须由路由协议处理的TE链路的数量来提高路由可伸缩性。路由协议应该能够支持在TE链路所做的一对节点之间以相同的线速率和复用层次结构捆绑多个OTU链路。请注意，链接绑定是可选的，并且依赖于实现。
- Support for Control of Hitless Adjustment of ODUflex (GFP)
- 支持控制ODUflex（GFP）的无故障调整
The control plane should support hitless adjustment of ODUflex, so the routing protocol should be capable of differentiating whether or not an ODU link can support hitless adjustment of ODUflex (GFP) and how many resources can be used for resizing. This can be achieved by introducing a new signal type "ODUflex(GFP-F), resizable" that implies the support for hitless adjustment of ODUflex (GFP) by that link.
控制平面应该支持ODUflex的无故障调整，因此路由协议应该能够区分ODU链路是否支持ODUflex的无故障调整（GFP），以及可以使用多少资源来调整大小。这可以通过引入新的信号类型“ODUflex（GFP-F），可调整大小”来实现，这意味着支持通过该链接对ODUflex（GFP）进行无损伤调整。
As mentioned in Section 5.1, one method of enabling multiplexing hierarchy is via usage of dedicated boards to allow tunneling of new services through legacy ODU1, ODU2, and ODU3 containers. Such dedicated boards may have some constraints with respect to switching matrix access; detection and representation of such constraints is for further study.
如第5.1节所述，启用多路复用层次结构的一种方法是通过使用专用板，允许通过传统ODU1、ODU2和ODU3容器对新服务进行隧道传输。这种专用板在交换矩阵访问方面可能有一些限制；这些约束的检测和表示有待进一步研究。
As discussed in Section 5.3, path computation needs to know the interface switching capability of links. The switching capability of two ends of the link may be different, so the link capability of two ends should be correlated.
如第5.3节所述，路径计算需要知道链路的接口交换能力。链路两端的交换能力可能不同，因此两端的链路能力应该相互关联。
LMP [RFC4204] provides a control-plane protocol for exchanging and correlating link capabilities.
LMP[RFC4204]提供了用于交换和关联链路能力的控制平面协议。
Note that LO ODU type information can be, in principle, discovered by routing. Since in certain cases, routing is not present (e.g., in the case of a User-Network Interface (UNI)), we need to extend link management protocol capabilities to cover this aspect. If routing is present, discovery via LMP could also be optional.
注意，LO ODU类型信息原则上可以通过路由发现。由于在某些情况下，不存在路由（例如，在用户网络接口（UNI）的情况下），因此我们需要扩展链路管理协议功能以涵盖这一方面。如果存在路由，通过LMP的发现也可以是可选的。
- Correlating the granularity of the TS
- 关联TS的粒度
As discussed in Section 3.1.2, the two ends of a link may support different TS granularity. In order to allow interconnection, the node with 1.25 Gbps granularity should fall back to 2.5 Gbps granularity.
如第3.1.2节所述，链路的两端可能支持不同的TS粒度。为了允许互连，粒度为1.25 Gbps的节点应回落到2.5 Gbps。
Therefore, it is necessary for the two ends of a link to correlate the granularity of the TS. This ensures the correct use of the TE link.
因此，链路两端有必要关联TS的粒度。这确保了TE链路的正确使用。
- Correlating the supported LO ODU signal types and multiplexing hierarchy capability
- 关联支持的LO ODU信号类型和多路复用层次能力
Many new ODU signal types have been introduced in [G709-2012], such as ODU0, ODU4, ODU2e, and ODUflex. It is possible that equipment does not support all the LO ODU signal types introduced by new standards or documents. Furthermore, since multiplexing hierarchy may not be supported by the legacy OTNs, it is possible that only one end of an ODU link can support multiplexing hierarchy capability or that the two ends of the link support different multiplexing hierarchy capabilities (e.g., one end of the link supports ODU0 into ODU1 into ODU3 multiplexing while the other end supports ODU0 into ODU2 into ODU3 multiplexing).
[G709-2012]中引入了许多新的ODU信号类型，如ODU0、ODU4、ODU2e和ODUflex。设备可能不支持新标准或文件引入的所有LO ODU信号类型。此外，由于传统otn可能不支持复用层次，因此可能只有ODU链路的一端可以支持复用层次能力，或者链路的两端支持不同的复用层次能力（例如，链路的一端支持ODU0到ODU1到ODU3的多路复用，而另一端支持ODU0到ODU2到ODU3的多路复用）。
For control and management consideration, it is necessary for the two ends of an HO ODU link to correlate the types of LO ODU that can be supported and the multiplexing hierarchy capabilities that can be provided by the other end.
出于控制和管理考虑，HO-ODU链路的两端需要关联可支持的LO-ODU类型和可由另一端提供的复用层次结构能力。
With the introduction of [G709-2012], there may be OTN composed of a mixture of nodes, some of which support the legacy OTN and run the control-plane protocols defined in [RFC4328], while others support [G709-2012] and the new OTN control plane characterized in this document. Note that a third case, for the sake of completeness, consists of nodes supporting the legacy OTN referenced by [RFC4328] with a new OTN control plane, but such nodes can be considered new nodes with limited capabilities.
随着[G709-2012]的引入，可能存在由混合节点组成的OTN，其中一些节点支持传统OTN并运行[RFC4328]中定义的控制平面协议，而其他节点支持[G709-2012]和本文档中描述的新OTN控制平面。注意，为了完整性起见，第三种情况包括支持[RFC4328]所引用的传统OTN的节点以及新的OTN控制平面，但是这些节点可以被视为具有有限能力的新节点。
This section discusses the compatibility of nodes implementing the control-plane procedures defined in [RFC4328] in support of the legacy OTN and the control-plane procedures defined to support [G709-2012] as outlined by this document.
本节讨论了实现[RFC4328]中定义的控制平面程序以支持传统OTN的节点的兼容性，以及为支持本文件概述的[G709-2012]而定义的控制平面程序的节点的兼容性。
Compatibility needs to be considered only when controlling an ODU1, ODU2, or ODU3 connection because the legacy OTN only supports these three ODU signal types. In such cases, there are several possible options, including:
只有在控制ODU1、ODU2或ODU3连接时才需要考虑兼容性，因为传统OTN仅支持这三种ODU信号类型。在这种情况下，有几种可能的选择，包括：
- A node supporting [G709-2012] could support only the control-plane procedures related to [G709-2012], in which case both types of nodes would be unable to jointly control an LSP for an ODU type that both nodes support in the data plane.
- 支持[G709-2012]的节点只能支持与[G709-2012]相关的控制平面程序，在这种情况下，两种类型的节点将无法共同控制数据平面中两个节点都支持的ODU类型的LSP。
- A node supporting [G709-2012] could support both the control plane related to [G709-2012] and the control plane defined in [RFC4328].
- 支持[G709-2012]的节点可以同时支持与[G709-2012]相关的控制平面和[RFC4328]中定义的控制平面。
o Such a node could identify which set of procedures to follow when initiating an LSP based on the Switching Capability value advertised in routing.
o 这样的节点可以根据路由中公布的交换能力值来确定在启动LSP时要遵循哪一组过程。
o Such a node could follow the set of procedures based on the Switching Type received in signaling messages from an upstream node.
o 这样的节点可以遵循基于在来自上游节点的信令消息中接收的交换类型的一组过程。
o Such a node, when processing a transit LSP, could select which signaling procedures to follow based on the Switching Capability value advertised in routing by the next-hop node.
o 这样的节点在处理传输LSP时，可以基于下一跳节点在路由中通告的交换能力值来选择要遵循的信令过程。
[RFC7025] describes the requirements for GMPLS applications of PCE in order to establish GMPLS LSP. PCE needs to consider the GMPLS TE attributes appropriately once a Path Computation Client (PCC) or another PCE requests a path computation. The TE attributes that can be contained in the path calculation request message from the PCC or the PCE defined in [RFC5440] include switching capability, encoding type, signal type, etc.
[RFC7025]描述了建立GMPLS LSP对PCE的GMPLS应用的要求。PCE需要适当考虑GMPLS TE属性，一旦路径计算客户端（PCC）或另一PCE请求路径计算。可包含在来自PCC或[RFC5440]中定义的PCE的路径计算请求消息中的TE属性包括切换能力、编码类型、信号类型等。
As described in Section 5.2, new signal types and new signals with variable bandwidth information need to be carried in the extended signaling message of path setup. For the same consideration, the PCE Communication Protocol (PCECP) also has a desire to be extended to carry the new signal type and related variable bandwidth information when a PCC requests a path computation.
如第5.2节所述，路径设置的扩展信令消息中需要携带新的信号类型和具有可变带宽信息的新信号。出于同样的考虑，PCE通信协议（PCECP）还希望被扩展以在PCC请求路径计算时携带新的信号类型和相关可变带宽信息。
From the management perspective, the management function should be capable of managing not only the legacy OTN referenced by [RFC4328], but also new management functions introduced by the new features as specified in [G709-2012] (for more information, see Sections 3 and 4). OTN Operations, Administration, and Maintenance (OAM) configuration could be done through either Network Management Systems (NMS) or the GMPLS control plane as defined in [TDM-OAM]. For further details on management aspects for GMPLS networks, refer to [RFC3945].
从管理角度来看，管理功能不仅应能够管理[RFC4328]引用的传统OTN，还应能够管理[G709-2012]中规定的新功能引入的新管理功能（有关更多信息，请参阅第3节和第4节）。OTN操作、管理和维护（OAM）配置可通过网络管理系统（NMS）或[TDM-OAM]中定义的GMPLS控制平面完成。有关GMPLS网络管理方面的更多详细信息，请参阅[RFC3945]。
In case PCE is used to perform path computation in OTN, the PCE manageability should be considered (for more information, see Section 8 of [RFC5440]).
如果使用PCE在OTN中执行路径计算，则应考虑PCE的可管理性（有关更多信息，请参阅[RFC5440]第8节）。
If MI AUTOpayloadtype is activated (see [G798]), a node supporting 1.25 Gbps TS can interwork with the other nodes that support 2.5 Gbps TS by combining specific TSs together in the data plane. The control plane must support this TS combination.
如果激活MI AUTOpayloadtype（参见[G798]），则支持1.25 Gbps TS的节点可以通过在数据平面中将特定的TS组合在一起，与支持2.5 Gbps TS的其他节点互通。控制平面必须支持此TS组合。
Path
+----------+ ------------> +----------+
| TS1==|===========\--------+--TS1 |
| TS2==|=========\--\-------+--TS2 |
| TS3==|=======\--\--\------+--TS3 |
| TS4==|=====\--\--\--\-----+--TS4 |
| | \ \ \ \----+--TS5 |
| | \ \ \------+--TS6 |
| | \ \--------+--TS7 |
| | \----------+--TS8 |
+----------+ <------------ +----------+
node A Resv node B
Path
+----------+ ------------> +----------+
| TS1==|===========\--------+--TS1 |
| TS2==|=========\--\-------+--TS2 |
| TS3==|=======\--\--\------+--TS3 |
| TS4==|=====\--\--\--\-----+--TS4 |
| | \ \ \ \----+--TS5 |
| | \ \ \------+--TS6 |
| | \ \--------+--TS7 |
| | \----------+--TS8 |
+----------+ <------------ +----------+
node A Resv node B
Figure 5: Interworking between 1.25 Gbps TS and 2.5 Gbps TS
图5：1.25 Gbps TS和2.5 Gbps TS之间的互通
Take Figure 5 as an example. Assume that there is an ODU2 link between node A and B, where node A only supports the 2.5 Gbps TS while node B supports the 1.25 Gbps TS. In this case, the TS#i and TS#i+4 (where i<=4) of node B are combined together. When creating an ODU1 service in this ODU2 link, node B reserves the TS#i and TS#i+4 with the granularity of 1.25 Gbps. But in the label sent from B to A, it is indicated that the TS#i with the granularity of 2.5 Gbps is reserved.
以图5为例。假设节点A和B之间存在ODU2链路，其中节点A仅支持2.5 Gbps TS，而节点B支持1.25 Gbps TS。在这种情况下，节点B的TS#i和TS#i+4（其中i<=4）组合在一起。在该ODU2链路中创建ODU1服务时，节点B保留粒度为1.25 Gbps的TS#i和TS#i+4。但是在从B发送到A的标签中，指示保留了粒度为2.5gbps的TS#i。
In the opposite direction, when receiving a label from node A indicating that the TS#i with the granularity of 2.5 Gbps is reserved, node B will reserve the TS#i and TS#i+4 with the granularity of 1.25 Gbps in its data plane.
相反，当从节点a接收到指示保留粒度为2.5 Gbps的TS#i的标签时，节点B将在其数据平面中保留粒度为1.25 Gbps的TS#i和TS#i+4。
The use of control-plane protocols for signaling, routing, and path computation opens an OTN to security threats through attacks on those protocols. However, this is not greater than the risks presented by the existing OTN control plane as defined by [RFC4203] and [RFC4328]. Meanwhile, the Data Communication Network (DCN) for OTN GMPLS control-plane protocols is likely to be in the in-fiber overhead, which, together with access lists at the network edges, provides a significant security feature. For further details of specific security measures, refer to the documents that define the protocols
使用控制平面协议进行信令、路由和路径计算会通过对这些协议的攻击使OTN面临安全威胁。然而，这并不大于[RFC4203]和[RFC4328]定义的现有OTN控制平面所带来的风险。同时，OTN GMPLS控制平面协议的数据通信网络（DCN）可能位于光纤内开销中，这与网络边缘的访问列表一起提供了重要的安全特性。有关特定安全措施的更多详细信息，请参阅定义协议的文档
([RFC3473], [RFC4203], [RFC5307], [RFC4204], and [RFC5440]). [RFC5920] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane.
（[RFC3473]、[RFC4203]、[RFC5307]、[RFC4204]和[RFC5440]）。[RFC5920]概述了GMPLS控制平面的安全漏洞和保护机制。
We would like to thank Maarten Vissers and Lou Berger for their reviews and useful comments.
我们要感谢Maarten Vissers和Lou Berger的评论和有用的评论。
Jianrui Han Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28972913 EMail: hanjianrui@huawei.com
韩建瑞华为技术有限公司深圳市龙岗区华为基地坂田F3-5-B研发中心邮编：518129电话：+86-755-28972913电子邮件：hanjianrui@huawei.com
Malcolm Betts EMail: malcolm.betts@rogers.com
Malcolm Betts电子邮件：Malcolm。betts@rogers.com
Pietro Grandi Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy Phone: +39 039 6864930 EMail: pietro_vittorio.grandi@alcatel-lucent.it
Pietro Grandi Alcatel-Lucent Optics首席技术官Vimercate（米兰）意大利电话：+39 039 6864930电子邮件：Pietro_vittorio。grandi@alcatel-朗讯
Eve Varma Alcatel-Lucent 1A-261, 600-700 Mountain Av PO Box 636 Murray Hill, NJ 07974-0636 USA EMail: eve.varma@alcatel-lucent.com
Eve Varma Alcatel-Lucent 1A-261600-700 Mountain Av美国新泽西州默里山636号邮政信箱07974-0636电子邮件：Eve。varma@alcatel-朗讯网
[G709-2012] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709/Y.1331 Recommendation, February 2012.
[G709-2012]ITU-T，“光传输网络（OTN）接口”，G.709/Y.1331建议，2012年2月。
[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月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]Lang，J.，Ed.，“链路管理协议（LMP）”，RFC4204，2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006.
[RFC4328]Papadimitriou，D.，编辑，“G.709光传输网络控制的通用多协议标签交换（GMPLS）信令扩展”，RFC 4328，2006年1月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，2008年10月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010.
[RFC6001]Papadimitriou，D.，Vigoureux，M.，Shiomoto，K.，Brungard，D.，和JL。Le Roux，“多层和多区域网络（MLN/MRN）的通用MPLS（GMPLS）协议扩展”，RFC 60012010年。
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011.
[RFC6107]Shiomoto，K.，Ed.，和A.Farrel，Ed.“动态信号分层标签交换路径的程序”，RFC 61072011年2月。
[RFC6344] Bernstein, G., Ed., Caviglia, D., Rabbat, R., and H. van Helvoort, "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", RFC 6344, August 2011.
[RFC6344]Bernstein，G.，Ed.，Caviglia，D.，Rabbat，R.，和H.van Helvoort，“操作虚拟连接（VCAT）和带有通用多协议标签交换（GMPLS）的链路容量调整方案（LCAS）”，RFC 63442011年8月。
[G798] ITU-T, "Characteristics of optical transport network hierarchy equipment functional blocks", G.798 Recommendation, December 2012.
[G798]ITU-T，“光传输网络层次结构设备功能块的特征”，G.798建议，2012年12月。
[G872-2001] ITU-T, "Architecture of optical transport networks", G.872 Recommendation, November 2001.
[G872-2001]ITU-T，“光传输网络体系结构”，G.872建议，2001年11月。
[G872-2012] ITU-T, "Architecture of optical transport networks", G.872 Recommendation, October 2012.
[G872-2012]ITU-T，“光传输网络体系结构”，G.872建议，2012年10月。
[G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April 2011.
[G7041]ITU-T，“通用成帧程序”，G.7041/Y.1303，2011年4月。
[G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for virtual concatenated signals", G.7042/Y.1305, March 2006.
[G7042]ITU-T，“虚拟级联信号的链路容量调整方案（LCAS）”，G.7042/Y.13052006年3月。
[G7044] ITU-T, "Hitless adjustment of ODUflex (HAO)", G.7044/Y.1347, October 2011.
[G7044]ITU-T，“ODUflex（HAO）的无故障调整”，G.7044/Y.1347，2011年10月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, April 2011.
[RFC6163]Lee，Y.，Ed.，Bernstein，G.，Ed.，和W.Imajuku，“波长交换光网络（WSON）的GMPLS和路径计算元件（PCE）控制框架”，RFC 61632011年4月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. Margaria, "Requirements for GMPLS Applications of PCE", RFC 7025, September 2013.
[RFC7025]Otani，T.，Ogaki，K.，Caviglia，D.，Zhang，F.，和C.Margaria，“PCE的GMPLS应用要求”，RFC 70252013年9月。
[TDM-OAM] Kern, A., and A. Takacs, "GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration", Work in Progress, November 2013.
[TDM-OAM]Kern，A.和A.Takacs，“SONET/SDH和OTN OAM配置的GMPLS RSVP-TE扩展”，正在进行的工作，2013年11月。
Authors' Addresses
作者地址
Fatai Zhang (editor) Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28972912 EMail: zhangfatai@huawei.com
张法泰（编辑）华为技术F3-5-B研发中心，华为总部深圳市龙岗区坂田518129电话：+86-755-28972912电子邮件：zhangfatai@huawei.com
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28973237 EMail: huawei.danli@huawei.com
中国深圳市龙岗区半天华为基地华为技术F3-5-B研发中心李丹电话：+86-755-28973237电子邮件：华为。danli@huawei.com
Han Li China Mobile Communications Corporation 53 A Xibianmennei Ave. Xuanwu District Beijing 100053 P.R. China Phone: +86-10-66006688 EMail: lihan@chinamobile.com
中国移动通信股份有限公司北京市宣武区西边门内大街53号A座，邮编100053电话：+86-10-66006688电子邮件：lihan@chinamobile.com
Sergio Belotti Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy Phone: +39 039 6863033 EMail: sergio.belotti@alcatel-lucent.it
Sergio Belotti Alcatel-Lucent Optics首席技术官通过Trento 30 20059 Vimercate（米兰）意大利电话：+39 039 6863033电子邮件：Sergio。belotti@alcatel-朗讯
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy EMail: daniele.ceccarelli@ericsson.com
Daniele Ceccarelli Ericsson通过A.Negrone 1/A Genova-Sestri Ponente Italy电子邮件：Daniele。ceccarelli@ericsson.com