Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 7139 Huawei
Updates: 4328 G. Zhang
Category: Standards Track CATR
ISSN: 2070-1721 S. Belotti
Alcatel-Lucent
D. Ceccarelli
Ericsson
K. Pithewan
Infinera
March 2014
Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 7139 Huawei
Updates: 4328 G. Zhang
Category: Standards Track CATR
ISSN: 2070-1721 S. Belotti
Alcatel-Lucent
D. Ceccarelli
Ericsson
K. Pithewan
Infinera
March 2014
GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks
用于控制演进中的G.709光传输网络的GMPLS信令扩展
Abstract
摘要
ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.
ITU-T建议G.709[G709-2012]引入了新的光信道数据单元（ODU）容器（ODU0、ODU4、ODU2e和ODUflex）和增强的光传输网络（OTN）灵活性。
This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.
本文档更新了RFC 4328中与ODU相关的部分，以提供对GMPLS信令的扩展，以控制全套OTN功能，包括ODU0、ODU4、ODU2e和ODUflex。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7139.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7139.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. GMPLS Extensions for the Evolving G.709 -- Overview .............3
4. Generalized Label Request .......................................4
5. Extensions for Traffic Parameters for Evolving G.709 OTNs .......7
5.1. Usage of ODUflex(CBR) Traffic Parameters ...................8
5.2. Usage of ODUflex(GFP) Traffic Parameters ..................10
5.3. Notification on Errors of OTN-TDM Traffic Parameters ......11
6. Generalized Label ..............................................12
6.1. OTN-TDM Switching Type Generalized Label ..................12
6.2. Procedures ................................................14
6.2.1. Notification on Label Error ........................16
6.3. Supporting Virtual Concatenation and Multiplication .......17
6.4. Examples ..................................................17
7. Supporting Hitless Adjustment of ODUflex(GFP) ..................19
8. Operations, Administration, and Maintenance (OAM)
Considerations .................................................20
9. Control-Plane Backward-Compatibility Considerations ............20
10. Security Considerations .......................................21
11. IANA Considerations ...........................................21
12. References ....................................................23
12.1. Normative References .....................................23
12.2. Informative References ...................................24
13. Contributors ..................................................25
14. Acknowledgments ...............................................26
1. Introduction ....................................................3
2. Terminology .....................................................3
3. GMPLS Extensions for the Evolving G.709 -- Overview .............3
4. Generalized Label Request .......................................4
5. Extensions for Traffic Parameters for Evolving G.709 OTNs .......7
5.1. Usage of ODUflex(CBR) Traffic Parameters ...................8
5.2. Usage of ODUflex(GFP) Traffic Parameters ..................10
5.3. Notification on Errors of OTN-TDM Traffic Parameters ......11
6. Generalized Label ..............................................12
6.1. OTN-TDM Switching Type Generalized Label ..................12
6.2. Procedures ................................................14
6.2.1. Notification on Label Error ........................16
6.3. Supporting Virtual Concatenation and Multiplication .......17
6.4. Examples ..................................................17
7. Supporting Hitless Adjustment of ODUflex(GFP) ..................19
8. Operations, Administration, and Maintenance (OAM)
Considerations .................................................20
9. Control-Plane Backward-Compatibility Considerations ............20
10. Security Considerations .......................................21
11. IANA Considerations ...........................................21
12. References ....................................................23
12.1. Normative References .....................................23
12.2. Informative References ...................................24
13. Contributors ..................................................25
14. Acknowledgments ...............................................26
With the evolution and deployment of Optical Transport Network (OTN) technology, it is necessary that appropriate enhanced control technology support be provided for [G709-2012].
随着光传输网络（OTN）技术的发展和部署，有必要为[G709-2012]提供适当的增强控制技术支持。
[RFC7062] provides a framework to allow the development of protocol extensions to support GMPLS and Path Computation Element (PCE) control of OTN as specified in [G709-2012]. Based on this framework, [RFC7096] evaluates the information needed by the routing and signaling process in OTNs to support GMPLS control of OTN.
[RFC7062]提供了一个框架，允许开发协议扩展，以支持[G709-2012]中规定的OTN的GMPLS和路径计算元素（PCE）控制。基于此框架，[RFC7096]评估OTN中路由和信令过程所需的信息，以支持OTN的GMPLS控制。
[RFC4328] describes the control technology details that are specific to the 2001 revision of the G.709 specification. This document updates the ODU-related portions of [RFC4328] to provide Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions to support control for [G709-2012].
[RFC4328]描述了特定于2001版G.709规范的控制技术细节。本文件更新了[RFC4328]中与ODU相关的部分，以提供资源预留协议-流量工程（RSVP-TE）扩展，以支持[G709-2012]的控制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
New features for the evolving OTN, for example, new ODU0, ODU2e, ODU4, and ODUflex containers, are specified in [G709-2012]. The corresponding new Signal Types are summarized below:
[G709-2012]中规定了不断发展的OTN的新功能，例如新的ODU0、ODU2e、ODU4和ODUflex容器。相应的新信号类型总结如下：
- Optical channel Transport Unit (OTUk): o OTU4
- 光信道传输单元（OTUk）：o OTU4
- Optical channel Data Unit (ODUk): o ODU0 o ODU2e o ODU4 o ODUflex
- 光信道数据单元（ODUk）：o ODU0 o ODU2e o ODU4 o ODUflex
A new tributary slot granularity (i.e., 1.25 Gbps) is also described in [G709-2012]. Thus, there are now two tributary slot (TS) granularities for the foundation OTN ODU1, ODU2, and ODU3 containers. The TS granularity at 2.5 Gbps is used on the legacy interfaces while the new 1.25 Gbps is used on the new interfaces.
[G709-2012]中还描述了一种新的分支时隙粒度（即1.25 Gbps）。因此，现在有两个支路槽（TS）粒度为基础OTN ODU1、ODU2和ODU3容器。传统接口使用2.5 Gbps的TS粒度，而新接口使用1.25 Gbps的TS粒度。
In addition to the support of ODUk mapping into OTUk (k = 1, 2, 3, 4), [G709-2012] encompasses the multiplexing of ODUj (j = 0, 1, 2, 2e, 3, flex) into an ODUk (k > j), as described in Section 3.1.2 of [RFC7062].
除了支持ODUk映射到OTUk（k=1,2,3,4），[G709-2012]还包括将ODUj（j=0,1,2,2e,3,flex）复用到ODUk（k>j），如[RFC7062]第3.1.2节所述。
Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk) (OPUk-Xv, k = 1/2/3, X = 1...256) is also supported by [G709-2012]. Note that VCAT of OPU0 / OPU2e / OPU4 / OPUflex is not supported per [G709-2012].
[G709-2012]还支持光信道有效负载单元k（OPUk）（OPUk Xv，k=1/2/3，X=1…256）的虚拟级联（VCAT）。请注意，[G709-2012]不支持OPU0/OPU2e/OPU4/OPUflex的VCAT。
[RFC4328] describes GMPLS signaling extensions to support the control for the 2001 revision of the G.709 specification. However, [RFC7096] does not provide the means to signal all the new Signal Types and related mapping and multiplexing functionalities. Moreover, it supports only the deprecated auto-MSI (Multiframe Structure Identifier) mode, which assumes that the Tributary Port Number (TPN) is automatically assigned in the transmit direction and not checked in the receive direction.
[RFC4328]描述了GMPLS信令扩展，以支持对2001版G.709规范的控制。然而，[RFC7096]并未提供向所有新信号类型和相关映射及多路复用功能发送信号的方法。此外，它仅支持不推荐使用的自动MSI（多帧结构标识符）模式，该模式假定支路端口号（TPN）在传输方向自动分配，而在接收方向不检查。
This document extends the G.709 Traffic Parameters described in [RFC4328] and presents a new flexible and scalable OTN-TDM Generalized Label format. (Here, TDM refers to Time-Division Multiplexing.) Additionally, procedures about Tributary Port Number assignment through the control plane are also provided in this document.
本文件扩展了[RFC4328]中描述的G.709流量参数，并提出了一种新的灵活、可扩展的OTN-TDM通用标签格式。（这里，TDM指的是时分多路复用。）此外，本文件还提供了通过控制平面分配支路端口号的程序。
The GENERALIZED_LABEL_REQUEST object, as described in [RFC3471], carries the Label Switched Path (LSP) Encoding Type, the Switching Type, and the Generalized Protocol Identifier (G-PID).
如[RFC3471]中所述，通用_标签_请求对象携带标签交换路径（LSP）编码类型、交换类型和通用协议标识符（G-PID）。
[RFC4328] extends the GENERALIZED_LABEL_REQUEST object, introducing two new code-points for the LSP Encoding Type (i.e., G.709 ODUk (Digital Path) and G.709 Optical Channel) and adding a list of G-PID values in order to accommodate the 2001 revision of the G.709 specification.
[RFC4328]扩展了广义的_标签_请求对象，引入了LSP编码类型的两个新代码点（即G.709 ODUk（数字路径）和G.709光通道），并添加了G-PID值列表，以适应2001年修订的G.709规范。
This document follows these extensions and introduces a new Switching Type to indicate the ODUk Switching Capability [G709-2012] in order to support backward compatibility with [RFC4328], as described in [RFC7062]. The new Switching Type (OTN-TDM Switching Type) is defined in [RFC7138].
本文档遵循这些扩展，并引入了一种新的交换类型，以指示ODUk交换能力[G709-2012]，以支持与[RFC4328]的向后兼容性，如[RFC7062]所述。[RFC7138]中定义了新的切换类型（OTN-TDM切换类型）。
This document also updates the G-PID values defined in [RFC4328]:
本文件还更新了[RFC4328]中定义的G-PID值：
Value G-PID Type
----- ----------
Value G-PID Type
----- ----------
47 Type field updated from "G.709 ODUj" to "ODU-2.5G" to indicate transport of Digital Paths (e.g., at 2.5, 10, and 40 Gbps) via 2.5 Gbps TS granularity.
47类型字段从“G.709 ODUj”更新为“ODU-2.5G”，以指示通过2.5 Gbps TS粒度传输的数字路径（例如，2.5、10和40 Gbps）。
56 Type field updated from "ESCON" to "SBCON/ESCON" to align with [G709-2012] payload type 0x1A.
56类型字段从“ESCON”更新为“SBCON/ESCON”，以与[G709-2012]有效负载类型0x1A对齐。
Note: Value 47 includes mapping of Synchronous Digital Hierarchy (SDH).
注：值47包括同步数字体系（SDH）的映射。
In the case of ODU multiplexing, the Lower Order ODU (LO ODU) (i.e., the client signal) may be multiplexed into a Higher Order ODU (HO ODU) via 1.25G TS granularity, 2.5G TS granularity, or ODU-any. Since the G-PID type "ODUk" defined in [RFC4328] is only used for 2.5 Gbps TS granularity, two new G-PID types are defined as follows:
在ODU复用的情况下，低阶ODU（LO-ODU）（即，客户机信号）可以经由1.25G TS粒度、2.5G TS粒度或ODU任意被复用成高阶ODU（HO-ODU）。由于[RFC4328]中定义的G-PID类型“ODUk”仅用于2.5 Gbps TS粒度，因此定义了两种新的G-PID类型，如下所示：
- ODU-1.25G: Transport of Digital Paths at 1.25, 2.5, 10, 40, and 100 Gbps via 1.25 Gbps TS granularity.
- ODU-1.25G：通过1.25 Gbps TS粒度以1.25、2.5、10、40和100 Gbps传输数字路径。
- ODU-any: Transport of Digital Paths at 1.25, 2.5, 10, 40, and 100 Gbps via 1.25 or 2.5 Gbps TS granularity (i.e., the fallback procedure is enabled and the default value of 1.25 Gbps TS granularity can fall back to 2.5 Gbps if needed).
- ODU any：通过1.25或2.5 Gbps TS粒度以1.25、2.5、10、40和100 Gbps的速度传输数字路径（即，启用回退过程，如果需要，1.25 Gbps TS粒度的默认值可以回退到2.5 Gbps）。
The full list of payload types defined in [G709-2012] and their mapping to existing and new G-PID types are as follows:
[G709-2012]中定义的有效载荷类型的完整列表及其与现有和新G-PID类型的映射如下：
G.709
Payload
Type G-PID Type/Comment LSP Encoding
==== ===== ===================== ===================
0x01 No standard value
0x02 49 CBRa G.709 ODUk
0x03 50 CBRb G.709 ODUk
0x04 32 ATM G.709 ODUk
0x05 59 Framed GFP G.709 ODUk
54 Ethernet MAC (framed GFP) G.709 ODUk
70 64B/66B GFP-F Ethernet G.709 ODUk (k=2)
0x06 Not signaled
0x07 55 Ethernet PHY G.709 ODUk (k=0,3,4)
(transparent GFP)
0x08 58 Fiber Channel G.709 ODUk (k=2e)
G.709
Payload
Type G-PID Type/Comment LSP Encoding
==== ===== ===================== ===================
0x01 No standard value
0x02 49 CBRa G.709 ODUk
0x03 50 CBRb G.709 ODUk
0x04 32 ATM G.709 ODUk
0x05 59 Framed GFP G.709 ODUk
54 Ethernet MAC (framed GFP) G.709 ODUk
70 64B/66B GFP-F Ethernet G.709 ODUk (k=2)
0x06 Not signaled
0x07 55 Ethernet PHY G.709 ODUk (k=0,3,4)
(transparent GFP)
0x08 58 Fiber Channel G.709 ODUk (k=2e)
0x09 59 Framed GFP G.709 ODUk (k=2) 70 64B/66B GFP-F Ethernet G.709 ODUk (k=2) 0x0A 60 STM-1 G.709 ODUk (k=0) 0x0B 61 STM-4 G.709 ODUk (k=0) 0x0C 58 Fiber Channel G.709 ODUk (k=0) 0x0D 58 Fiber Channel G.709 ODUk (k=1) 0x0E 58 Fiber Channel G.709 ODUflex 0x0F 58 Fiber Channel G.709 ODUflex 0x10 51 BSOT G.709 ODUk 0x11 52 BSNT G.709 ODUk 0x12 62 InfiniBand G.709 ODUflex 0x13 62 InfiniBand G.709 ODUflex 0x14 62 InfiniBand G.709 ODUflex 0x15 63 Serial Digital Interface G.709 ODUk (k=0) 0x16 64 SDI/1.001 G.709 ODUk (k=1) 0x17 63 Serial Digital Interface G.709 ODUk (k=1) 0x18 64 SDI/1.001 G.709 ODUflex 0x19 63 Serial Digital Interface G.709 ODUflex 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) 0x1B 65 DVB_ASI G.709 ODUk (k=0) 0x1C 58 Fiber Channel G.709 ODUk 0x20 47 G.709 ODU-2.5G G.709 ODUk (k=2,3) 66 G.709 ODU-1.25G G.709 ODUk (k=1) 0x21 66 G.709 ODU-1.25G G.709 ODUk (k=2,3,4) 67 G.709 ODU-any G.709 ODUk (k=2,3) 0x55 No standard value 0x66 No standard value 0x80-0x8F No standard value 0xFD 68 Null Test G.709 ODUk 0xFE 69 Random Test G.709 ODUk 0xFF No standard value
0x09 59帧GFP G.709 ODUk（k=2）70 64B/66B GFP-F以太网G.709 ODUk（k=2）0x0A 60 STM-1 G.709 ODUk（k=0）0x0B 61 STM-4 G.709 ODUk（k=0）0x0C 58光纤通道G.709 ODUk（k=0）0x0D 58光纤通道G.709 ODUk（k=1）0x0E 58光纤通道G.709 ODUflex 0x0F 58光纤通道G.709 ODUflex 0x10 51 BSOT G.709 ODUk 0x11 52 BSNT G.709 ODUk 0x12 62 InfiniBand G.709 ODUflex 0x13 62 InfiniBand G.709 ODUflex 0x14 62 InfiniBand G.709 ODUk 0x15 63串行数字接口G.709 ODUk（k=0）0x16 64 SDI/1.001 G.709 ODUk（k=1）0x17 63串行数字接口G.709 ODUk（k=1）0x18 64 SDI/1.001 G.709 ODUflex 0x19 63串行数字接口G.709 ODUflex 0x1A 56 SBCON/ESCON G.709 ODUk（k=0）0x1B 65 DVB_ASI G.709 ODUk（k=0）0x1C58光纤通道G.709 ODUk 0x20 47 G.709 ODU-2.5G.709 ODUk（k=2,3）66 G.709 ODU-1.25G.709 ODUk（k=1）0x21 G.709 ODU-1.25G ODU-1.709 ODUk=2.709 ODUk=2.67 ODUk=3.67 ODUk=2,9 ODUk0x55无标准值0x66无标准值0x80-0x8F无标准值0xFD 68零测试G.709 ODUk 0xFE 69随机测试G.709 ODUk 0xFF无标准值
Note: Values 59 and 70 include mapping of SDH.
注：值59和70包括SDH映射。
Note that the mapping types for ODUj into OPUk are unambiguously per Table 7-10 of [G709-2012], so there is no need to carry mapping type information in the signaling.
注意，ODUj到OPUk的映射类型根据[G709-2012]的表7-10明确，因此不需要在信令中携带映射类型信息。
Note also that additional information on G.709 client mapping can be found in [G7041].
还请注意，有关G.709客户端映射的其他信息可在[G7041]中找到。
The Traffic Parameters for the OTN-TDM-capable Switching Type are carried in the OTN-TDM SENDER_TSPEC object in the Path message and the OTN-TDM FLOWSPEC object in the Resv message. The objects have the following class and type:
Path消息中的OTN-TDM SENDER_TSPEC对象和Resv消息中的OTN-TDM FLOWSPEC对象中携带了支持OTN TDM的交换类型的流量参数。对象具有以下类别和类型：
- OTN-TDM SENDER_TSPEC object: Class = 12, C-Type = 7 - OTN-TDM FLOWSPEC object: Class = 9, C-Type = 7
- OTN-TDM发送器\u TSPEC对象：类=12，C型=7-OTN-TDM FLOWSPEC对象：类=9，C型=7
The format of Traffic Parameters in these two objects is defined as follows:
这两个对象中交通参数的格式定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit_Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit_Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signal Type: 8 bits
信号类型：8位
As defined in Section 3.2.1 of [RFC4328], with the following additional values:
如[RFC4328]第3.2.1节所定义，具有以下附加值：
Value Type
----- ----
4 ODU4 (i.e., 100 Gbps)
9 OCh at 100 Gbps
10 ODU0 (i.e., 1.25 Gbps)
11 ODU2e (i.e., 10 Gbps for FC1200 and GE LAN)
12-19 Reserved (for future use)
20 ODUflex(CBR) (i.e., 1.25*N Gbps)
21 ODUflex(GFP-F), resizable (i.e., 1.25*N Gbps)
22 ODUflex(GFP-F), non-resizable (i.e., 1.25*N Gbps)
23-255 Reserved (for future use)
Value Type
----- ----
4 ODU4 (i.e., 100 Gbps)
9 OCh at 100 Gbps
10 ODU0 (i.e., 1.25 Gbps)
11 ODU2e (i.e., 10 Gbps for FC1200 and GE LAN)
12-19 Reserved (for future use)
20 ODUflex(CBR) (i.e., 1.25*N Gbps)
21 ODUflex(GFP-F), resizable (i.e., 1.25*N Gbps)
22 ODUflex(GFP-F), non-resizable (i.e., 1.25*N Gbps)
23-255 Reserved (for future use)
Note: Above, CBR stands for Constant Bit Rate, and GFP-F stands for Generic Framing Procedure - Framed.
注：如上所述，CBR代表恒定比特率，GFP-F代表通用成帧过程-成帧。
NVC (Number of Virtual Components): 16 bits
NVC（虚拟组件数）：16位
As defined in Section 3.2.3 of [RFC4328]. This field MUST be set to 0 for ODUflex Signal Types.
如[RFC4328]第3.2.3节所定义。对于ODUflex信号类型，此字段必须设置为0。
Multiplier (MT): 16 bits
乘法器（MT）：16位
As defined in Section 3.2.4 of [RFC4328]. This field MUST be set to 1 for ODUflex Signal Types.
如[RFC4328]第3.2.4节所定义。对于ODUflex信号类型，此字段必须设置为1。
Bit_Rate: 32 bits
比特率：32位
In the case of ODUflex, including ODUflex(CBR) and ODUflex(GFP) Signal Types, this field indicates the nominal bit rate of ODUflex expressed in bytes per second, encoded as a 32-bit IEEE single-precision floating-point number (referring to [RFC4506] and [IEEE]). For other Signal Types, this field MUST be set to zero on transmission, MUST be ignored on receipt, and SHOULD be passed unmodified by transit nodes.
对于ODUflex，包括ODUflex（CBR）和ODUflex（GFP）信号类型，此字段表示ODUflex的标称比特率，以字节/秒表示，编码为32位IEEE单精度浮点数（参考[RFC4506]和[IEEE]）。对于其他信号类型，此字段在传输时必须设置为零，在接收时必须忽略，并且应在传输节点未修改的情况下传递。
In the case of ODUflex(CBR), the Bit_Rate information carried in the ODUflex Traffic Parameters MUST be used to determine the actual bandwidth of ODUflex(CBR) (i.e., Bit_Rate * (1 +/- Tolerance)). Therefore, the total number of tributary slots N in the HO ODUk link can be reserved correctly. Where:
在ODUflex（CBR）的情况下，必须使用ODUflex流量参数中携带的比特率信息来确定ODUflex（CBR）的实际带宽（即比特率*（1+/-容差））。因此，可以正确地保留HO-ODUk链路中的分支时隙N的总数。哪里：
N = Ceiling of
N = Ceiling of
ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance)
---------------------------------------------------------------------
ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance)
---------------------------------------------------------------------
ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
In this formula, the ODUflex(CBR) nominal bit rate is the bit rate of the ODUflex(CBR) on the line side, i.e., the client signal bit rate after applying the 239/238 factor (according to Clause 7.3, Table 7-2 of [G709-2012]) and the transcoding factor T (if needed) on the CBR client. According to Clauses 17.7.3, 17.7.4, and 17.7.5 of [G709-2012]:
在该公式中，ODUflex（CBR）标称比特率是线路侧ODUflex（CBR）的比特率，即应用239/238因子（根据[G709-2012]表7-2第7.3条）和CBR客户端上的转码因子T（如果需要）后的客户端信号比特率。根据[G709-2012]第17.7.3、17.7.4和17.7.5条：
ODUflex(CBR) nominal bit rate = CBR client bit rate * (239/238) / T
ODUflex(CBR) nominal bit rate = CBR client bit rate * (239/238) / T
The ODTUk.ts (Optical channel Data Tributary Unit k with ts tributary slots) nominal bit rate is the nominal bit rate of the tributary slot of ODUk, as shown in Table 1 (referring to Table 7-7 of [G709-2012]).
ODTUk.ts（带ts支路槽的光信道数据支路单元k）标称比特率是ODUk支路槽的标称比特率，如表1所示（参考[G709-2012]的表7-7]）。
ODUk.ts Minimum Nominal Maximum
-----------------------------------------------------------
ODU2.ts 1,249,384.632 1,249,409.620 1,249,434.608
ODU3.ts 1,254,678.635 1,254,703.729 1,254,728.823
ODU4.ts 1,301,683.217 1,301,709.251 1,301,735.285
ODUk.ts Minimum Nominal Maximum
-----------------------------------------------------------
ODU2.ts 1,249,384.632 1,249,409.620 1,249,434.608
ODU3.ts 1,254,678.635 1,254,703.729 1,254,728.823
ODU4.ts 1,301,683.217 1,301,709.251 1,301,735.285
Table 1: Actual TS Bit Rate of ODUk (in Kbps)
表1:ODUk的实际TS比特率（以Kbps为单位）
Note that:
请注意：
Minimum bit rate of ODUTk.ts = ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
ODUTk.ts的最小比特率=ODTUk.ts标称比特率*（1-HO OPUk比特率容差）
Maximum bit rate of ODTUk.ts = ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance)
ODTUk.ts的最大比特率=ODTUk.ts标称比特率*（1+HO OPUk比特率容差）
Where: HO OPUk bit rate tolerance = 20 ppm (parts per million)
式中：HO OPUk比特率公差=20 ppm（百万分之几）
Note that the bit rate tolerance is implicit in Signal Type and the ODUflex(CBR) bit rate tolerance is fixed and it is equal to 100 ppm as described in Table 7-2 of [G709-2012].
请注意，比特率容差隐含在信号类型中，ODUflex（CBR）比特率容差是固定的，等于[G709-2012]表7-2中所述的100 ppm。
Therefore, a node receiving a Path message containing an ODUflex(CBR) nominal bit rate can allocate a precise number of tributary slots and set up the cross-connection for the ODUflex service.
因此，接收包含ODUflex（CBR）标称比特率的路径消息的节点可以分配精确数量的分支时隙，并为ODUflex服务建立交叉连接。
Note that for different ODUk, the bit rates of the tributary slots are different, so the total number of tributary slots to be reserved for the ODUflex(CBR) may not be the same on different HO ODUk links.
注意，对于不同的ODUk，支路时隙的比特率是不同的，因此在不同的HO ODUk链路上为ODUflex（CBR）保留的支路时隙总数可能不同。
An example is given below to illustrate the usage of ODUflex(CBR) Traffic Parameters.
下面给出一个示例来说明ODUflex（CBR）流量参数的用法。
+-----+ +---------+ +-----+
| +-------------+ +-----+ +-------------+ |
| +=============+\| ODU |/+=============+ |
| +=============+/| flex+-+=============+ |
| +-------------+ | |\+=============+ |
| +-------------+ +-----+ +-------------+ |
| | | | | |
| | ....... | | ....... | |
| A +-------------+ B +-------------+ C |
+-----+ HO ODU4 +---------+ HO ODU2 +-----+
+-----+ +---------+ +-----+
| +-------------+ +-----+ +-------------+ |
| +=============+\| ODU |/+=============+ |
| +=============+/| flex+-+=============+ |
| +-------------+ | |\+=============+ |
| +-------------+ +-----+ +-------------+ |
| | | | | |
| | ....... | | ....... | |
| A +-------------+ B +-------------+ C |
+-----+ HO ODU4 +---------+ HO ODU2 +-----+
=========: TSs occupied by ODUflex
---------: available TSs
=========: TSs occupied by ODUflex
---------: available TSs
Figure 1: Example of ODUflex(CBR) Traffic Parameters
图1:ODUflex（CBR）流量参数示例
As shown in Figure 1, assume there is an ODUflex(CBR) service requesting a bandwidth of 2.5 Gbps from node A to node C.
如图1所示，假设有一个ODUflex（CBR）服务请求从节点a到节点C的带宽为2.5 Gbps。
In other words, the ODUflex Traffic Parameters indicate that Signal Type is 20 (ODUflex(CBR)) and Bit_Rate is 2.5 Gbps (note that the tolerance is not signaled as explained above).
换句话说，ODUflex业务参数指示信号类型为20（ODUflex（CBR）），比特率为2.5 Gbps（注意，如上所述，不发送信号表示容差）。
- On the HO ODU4 link between node A and B:
- 在节点A和B之间的HO ODU4链路上：
The maximum bit rate of the ODUflex(CBR) equals 2.5 Gbps * (1 + 100 ppm), and the minimum bit rate of the tributary slot of ODU4 equals 1,301,683.217 Kbps, so the total number of tributary slots N1 to be reserved on this link is:
ODUflex（CBR）的最大比特率等于2.5 Gbps*（1+100 ppm），ODU4的分支插槽的最小比特率等于1301683.217 Kbps，因此在该链路上保留的分支插槽N1的总数为：
N1 = ceiling (2.5 Gbps * (1 + 100 ppm) / 1,301,683.217 Kbps) = 2
N1 = ceiling (2.5 Gbps * (1 + 100 ppm) / 1,301,683.217 Kbps) = 2
- On the HO ODU2 link between node B and C:
- 在节点B和C之间的HO ODU2链路上：
The maximum bit rate of the ODUflex equals 2.5 Gbps * (1 + 100 ppm), and the minimum bit rate of the tributary slot of ODU2 equals 1,249,384.632 Kbps, so the total number of tributary slots N2 to be reserved on this link is:
ODUflex的最大比特率等于2.5 Gbps*（1+100 ppm），ODU2的分支插槽的最小比特率等于1249384.632 Kbps，因此在该链路上保留的分支插槽N2总数为：
N2 = ceiling (2.5 Gbps * (1 + 100 ppm) / 1,249,384.632 Kbps) = 3
N2 = ceiling (2.5 Gbps * (1 + 100 ppm) / 1,249,384.632 Kbps) = 3
[G709-2012] recommends that the ODUflex(GFP) fill an integral number of tributary slots of the smallest HO ODUk path over which the ODUflex(GFP) may be carried, as shown in Table 2.
[G709-2012]建议ODUflex（GFP）在可承载ODUflex（GFP）的最小HO-ODUk路径上填充整数个分支槽，如表2所示。
ODU Type | Nominal Bit Rate | Tolerance
---------------------------------+------------------+-----------
ODUflex(GFP) of n TSs, 1<=n<=8 | n * ODU2.ts | +/-100 ppm
ODUflex(GFP) of n TSs, 9<=n<=32 | n * ODU3.ts | +/-100 ppm
ODUflex(GFP) of n TSs, 33<=n<=80 | n * ODU4.ts | +/-100 ppm
ODU Type | Nominal Bit Rate | Tolerance
---------------------------------+------------------+-----------
ODUflex(GFP) of n TSs, 1<=n<=8 | n * ODU2.ts | +/-100 ppm
ODUflex(GFP) of n TSs, 9<=n<=32 | n * ODU3.ts | +/-100 ppm
ODUflex(GFP) of n TSs, 33<=n<=80 | n * ODU4.ts | +/-100 ppm
Table 2: Recommended ODUflex(GFP) Bit Rates and Tolerance
表2：建议的ODUflex（GFP）比特率和容差
According to this table, the Bit_Rate field for ODUflex(GFP) MUST be equal to one of the 80 values listed below:
根据此表，ODUflex（GFP）的比特率字段必须等于下面列出的80个值之一：
1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts;
9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts;
33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts.
1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts;
9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts;
33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts.
In this way, the number of required tributary slots for the ODUflex(GFP) (i.e., the value of "n" in Table 2) can be deduced from the Bit_Rate field.
通过这种方式，可以从比特率字段推导出ODUflex（GFP）所需的支路时隙数（即表2中的“n”值）。
There is no Adspec associated with the OTN-TDM SENDER_TSPEC object. Either the Adspec is omitted or an Int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment is used (see [RFC2210]).
没有与OTN-TDM发送方\u TSPEC对象关联的Adspec。要么省略Adspec，要么使用具有默认通用特征参数和保证服务片段的Int-serv Adspec（请参见[RFC2210]）。
For a particular sender in a session, the contents of the OTN-TDM FLOWSPEC object received in a Resv message SHOULD be identical to the contents of the OTN-TDM SENDER_TSPEC object received in the corresponding Path message. If the objects do not match, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error MUST be generated.
对于会话中的特定发送方，在Resv消息中接收的OTN-TDM FLOWSPEC对象的内容应与在相应路径消息中接收的OTN-TDM发送方\u TSPEC对象的内容相同。如果对象不匹配，则必须生成带有“交通控制错误/错误的Flowspec值”错误的ResvErr消息。
Intermediate and egress nodes MUST verify that the node itself, and the interfaces on which the LSP will be established, can support the requested Signal Type, NVC, and Bit_Rate values. If the requested value(s) cannot be supported, the receiver node MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]).
中间和出口节点必须验证节点本身以及将建立LSP的接口是否能够支持请求的信号类型、NVC和比特率值。如果请求的值不受支持，则接收方节点必须生成带有“流量控制错误/服务不受支持”指示的PathErr消息（请参阅[RFC2205]）。
In addition, if the MT field is received with a zero value, the node MUST generate a PathErr message with a "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]).
此外，如果收到的MT字段值为零值，则节点必须生成带有“流量控制错误/错误Tspec值”指示的PathErr消息（请参阅[RFC2205]）。
Further, if the Signal Type is not ODU1, ODU2, or ODU3, and the NVC field is not 0, the node MUST generate a PathErr message with a "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]).
此外，如果信号类型不是ODU1、ODU2或ODU3，且NVC字段不是0，则节点必须生成带有“流量控制错误/错误Tspec值”指示的PathErr消息（参见[RFC2205]）。
This section defines the format of the OTN-TDM Generalized Label.
本节定义了OTN-TDM通用标签的格式。
The following is the GENERALIZED_LABEL object format that MUST be used with the OTN-TDM Switching Type:
以下是OTN-TDM交换类型必须使用的通用_标签对象格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bit Map ...... ~
~ ...... | Padding Bits ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bit Map ...... ~
~ ...... | Padding Bits ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OTN-TDM GENERALIZED_LABEL object is used to indicate how the LO ODUj signal is multiplexed into the HO ODUk link. Note that the LO OUDj Signal Type is indicated by Traffic Parameters, while the type of HO ODUk link is identified by the selected interface carried in the IF_ID RSVP_HOP object.
OTN-TDM广义_标签对象用于指示LO ODUj信号如何多路复用到HO ODUk链路中。请注意，LO OUDj信号类型由流量参数指示，而HO ODUk链路的类型由IF_ID RSVP_HOP对象中携带的所选接口标识。
TPN: 12 bits
TPN:12位
Indicates the TPN for the assigned tributary slot(s).
指示分配的分支插槽的TPN。
- In the case of an LO ODUj multiplexed into an HO ODU1/ODU2/ODU3, only the lower 6 bits of the TPN field are significant; the other bits of the TPN field MUST be set to 0.
- 在将LO-ODUj复用到HO-ODU1/ODU2/ODU3的情况下，只有TPN字段的低6位是有效的；TPN字段的其他位必须设置为0。
- In the case of an LO ODUj multiplexed into an HO ODU4, only the lower 7 bits of the TPN field are significant; the other bits of the TPN field MUST be set to 0.
- 在将LO-ODUj复用到HO-ODU4的情况下，只有TPN字段的低7位是有效的；TPN字段的其他位必须设置为0。
- In the case of ODUj mapped into OTUk (j=k), the TPN is not needed, and this field MUST be set to 0.
- 如果ODUj映射到OTUk（j=k），则不需要TPN，并且该字段必须设置为0。
Per [G709-2012], the TPN is used to allow for correct demultiplexing in the data plane. When an LO ODUj is multiplexed into an HO ODUk occupying one or more TSs, a new TPN value is configured at the two ends of the HO ODUk link and is put into the related MSI byte(s) in the OPUk overhead at the (traffic) ingress end of the link, so that the other end of the link can learn which TS(s) is/are used by the LO ODUj in the data plane.
根据[G709-2012]，TPN用于允许数据平面中的正确解复用。当LO-ODUj多路复用到占用一个或多个TSs的HO-ODUk中时，在HO-ODUk链路的两端配置新的TPN值，并将其放入链路的（业务）入口端的OPUk开销中的相关MSI字节中，以便链路的另一端可以了解LO-ODUj在数据平面中使用了哪些TS。
According to [G709-2012], the TPN field MUST be set according to the following tables:
根据[G709-2012]，必须根据下表设置TPN字段：
+-------+-------+----+-------------------------------------------+
|HO ODUk|LO ODUj|TPN | TPN Assignment Rules |
+-------+-------+----+-------------------------------------------+
| ODU2 | ODU1 |1-4 |Fixed, = TS# occupied by ODU1 |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-16|Fixed, = TS# occupied by ODU1 |
| ODU3 +-------+----+-------------------------------------------+
| | ODU2 |1-4 |Flexible, != other existing LO ODU2s' TPNs |
+-------+-------+----+-------------------------------------------+
+-------+-------+----+-------------------------------------------+
|HO ODUk|LO ODUj|TPN | TPN Assignment Rules |
+-------+-------+----+-------------------------------------------+
| ODU2 | ODU1 |1-4 |Fixed, = TS# occupied by ODU1 |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-16|Fixed, = TS# occupied by ODU1 |
| ODU3 +-------+----+-------------------------------------------+
| | ODU2 |1-4 |Flexible, != other existing LO ODU2s' TPNs |
+-------+-------+----+-------------------------------------------+
Table 3: TPN Assignment Rules (2.5 Gbps TS Granularity)
表3:TPN分配规则（2.5 Gbps TS粒度）
+-------+-------+----+-------------------------------------------+
|HO ODUk|LO ODUj|TPN | TPN Assignment Rules |
+-------+-------+----+-------------------------------------------+
| ODU1 | ODU0 |1-2 |Fixed, = TS# occupied by ODU0 |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-4 |Flexible, != other existing LO ODU1s' TPNs |
| ODU2 +-------+----+-------------------------------------------+
| |ODU0 & |1-8 |Flexible, != other existing LO ODU0s and |
| |ODUflex| |ODUflexes' TPNs |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-16|Flexible, != other existing LO ODU1s' TPNs |
| +-------+----+-------------------------------------------+
| | ODU2 |1-4 |Flexible, != other existing LO ODU2s' TPNs |
| ODU3 +-------+----+-------------------------------------------+
| |ODU0 & | |Flexible, != other existing LO ODU0s and |
| |ODU2e &|1-32|ODU2s and ODUflexes' TPNs |
| |ODUflex| | |
+-------+-------+----+-------------------------------------------+
| ODU4 |Any ODU|1-80|Flexible, != ANY other existing LO ODUs' |
| | | |TPNs |
+-------+-------+----+-------------------------------------------+
+-------+-------+----+-------------------------------------------+
|HO ODUk|LO ODUj|TPN | TPN Assignment Rules |
+-------+-------+----+-------------------------------------------+
| ODU1 | ODU0 |1-2 |Fixed, = TS# occupied by ODU0 |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-4 |Flexible, != other existing LO ODU1s' TPNs |
| ODU2 +-------+----+-------------------------------------------+
| |ODU0 & |1-8 |Flexible, != other existing LO ODU0s and |
| |ODUflex| |ODUflexes' TPNs |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-16|Flexible, != other existing LO ODU1s' TPNs |
| +-------+----+-------------------------------------------+
| | ODU2 |1-4 |Flexible, != other existing LO ODU2s' TPNs |
| ODU3 +-------+----+-------------------------------------------+
| |ODU0 & | |Flexible, != other existing LO ODU0s and |
| |ODU2e &|1-32|ODU2s and ODUflexes' TPNs |
| |ODUflex| | |
+-------+-------+----+-------------------------------------------+
| ODU4 |Any ODU|1-80|Flexible, != ANY other existing LO ODUs' |
| | | |TPNs |
+-------+-------+----+-------------------------------------------+
Table 4: TPN Assignment Rules (1.25 Gbps TS Granularity)
表4:TPN分配规则（1.25 Gbps TS粒度）
Note that in the case of "Flexible", the value of TPN MAY not correspond to the TS number as per [G709-2012].
注意，在“灵活”的情况下，TPN的值可能与[G709-2012]规定的TS编号不一致。
Length: 12 bits
长度：12位
Indicates the number of bits of the Bit Map field, i.e., the total number of TSs in the HO ODUk link. The TS granularity, 1.25 Gbps or 2.5 Gbps, may be derived by dividing the HO ODUk link's rate by
指示位图字段的位数，即HO ODUk链路中TSs的总数。TS粒度（1.25 Gbps或2.5 Gbps）可通过将HO ODUk链路的速率除以
the value of the Length field. In the context of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5 Gbps, and the values 2, 8, 32, and 80 indicate a TS granularity of 1.25 Gbps.
长度字段的值。在[G709-2012]的上下文中，值4和16表示TS粒度为2.5 Gbps，值2、8、32和80表示TS粒度为1.25 Gbps。
In the case of an ODUk mapped into OTUk, there is no need to indicate which tributary slots will be used, so the Length field MUST be set to 0.
对于映射到OTUk的ODUk，不需要指示将使用哪个分支插槽，因此长度字段必须设置为0。
Bit Map: variable
位图：变量
Indicates which tributary slots in the HO ODUk that the LO ODUj will be multiplexed into. The sequence of the Bit Map is consistent with the sequence of the tributary slots in the HO ODUk. Each bit in the bit map represents the corresponding tributary slot in the HO ODUk with a value of 1 or 0 indicating whether the tributary slot will be used by the LO ODUj or not.
指示LO ODUj将多路复用到HO ODUk中的哪个分支插槽。位图的序列与HO ODUk中的支路时隙的序列一致。位图中的每一位表示HO ODUk中相应的支路时隙，值为1或0表示LO ODUj是否将使用支路时隙。
Padding Bits
填充位
Are added after the Bit Map to make the whole label a multiple of four bytes if necessary. Padding bits MUST be set to 0 and MUST be ignored on receipt.
如有必要，在位图之后添加，以使整个标签成为四个字节的倍数。填充位必须设置为0，并且在接收时必须忽略。
The ingress node MUST generate a Path message and specify the OTN-TDM Switching Type and corresponding G-PID in the GENERALIZED_LABEL_REQUEST object, which MUST be processed as defined in [RFC3473].
入口节点必须生成路径消息，并在通用标签请求对象中指定OTN-TDM切换类型和相应的G-PID，必须按照[RFC3473]中的定义进行处理。
The ingress node of an LSP MAY include a Label ERO (Explicit Route Object) subobject to indicate the label in each hop along the path. Note that the TPN in the Label ERO subobject need not be assigned by the ingress node. When the TPN is assigned by a node, the node MUST assign a valid TPN value and then put this value into the TPN field of the GENERALIZED_LABEL object when receiving a Path message.
LSP的入口节点可以包括标签ERO（显式路由对象）子对象，以指示沿路径的每个跳中的标签。注意，标签ERO子对象中的TPN不需要由入口节点分配。当TPN由节点分配时，节点必须分配一个有效的TPN值，然后在接收路径消息时将该值放入广义_标签对象的TPN字段中。
In order to create bidirectional LSP, the ingress node and upstream node MUST generate an UPSTREAM_LABEL object on the outgoing interface to indicate the reserved TSs of ODUk and the assigned TPN value in the upstream direction. This UPSTREAM_LABEL object is sent to the downstream node via a Path massage for upstream resource reservation.
为了创建双向LSP，入口节点和上游节点必须在输出接口上生成上游_标签对象，以指示ODUk的保留TSs和上游方向上分配的TPN值。此上游_标签对象通过用于上游资源预留的路径消息发送到下游节点。
The ingress node or upstream node MAY generate a LABEL_SET object to indicate which labels on the outgoing interface in the downstream direction are acceptable. The downstream node will restrict its choice of labels, i.e., TS resource and TPN value, to one that is in the LABEL_SET object.
入口节点或上游节点可以生成LABEL_SET对象，以指示下游方向的输出接口上的哪些标签是可接受的。下游节点将限制其标签的选择，即TS资源和TPN值，限制为标签集合对象中的标签。
The ingress node or upstream node MAY also generate a SUGGESTED_LABEL object to indicate the preference of TS resource and TPN value on the outgoing interface in the downstream direction. The downstream node is not required to use the suggested labels; it may use another label based on local decision and send it to the upstream node, as described in [RFC3473].
入口节点或上游节点还可以生成建议的_标签对象，以指示下游方向上的输出接口上的TS资源和TPN值的偏好。下游节点不需要使用建议的标签；它可以根据本地决定使用另一个标签，并将其发送到上游节点，如[RFC3473]中所述。
When an upstream node receives a Resv message containing a GENERALIZED_LABEL object with an OTN-TDM label, it MUST first identify which ODU Signal Type is multiplexed or mapped into which ODU Signal Type according to the Traffic Parameters and the IF_ID RSVP_HOP object in the received message.
当上游节点接收到包含具有OTN-TDM标签的通用_标签对象的Resv消息时，它必须首先根据所接收消息中的业务参数和IF_ID RSVP_HOP对象识别哪个ODU信号类型被复用或映射到哪个ODU信号类型。
- In the case of ODUj-to-ODUk multiplexing, the node MUST retrieve the reserved tributary slots in the ODUk by its downstream neighbor node according to the position of the bits that are set to 1 in the Bit Map field. The node determines the TS granularity (according to the total TS number of the ODUk or pre-configured TS granularity), so that the node can multiplex the ODUj into the ODUk based on the TS granularity. The node MUST also retrieve the TPN value assigned by its downstream neighbor node from the label and fill the TPN into the related MSI byte(s) in the OPUk overhead in the data plane, so that the downstream neighbor node can check whether the TPN received from the data plane is consistent with the Expected MSI (ExMSI) and determine whether there is any mismatch defect.
- 在ODUj到ODUk多路复用的情况下，节点必须根据位映射字段中设置为1的位的位置，由其下游邻居节点检索ODUk中保留的分支时隙。节点确定TS粒度（根据ODUk的总TS数或预先配置的TS粒度），以便节点可以基于TS粒度将ODUj复用到ODUk中。节点还必须从标签中检索其下游邻居节点分配的TPN值，并将TPN填入数据平面中OPUk开销中的相关MSI字节，以便下游邻居节点可以检查从数据平面接收的TPN是否与预期MSI（ExMSI）一致并确定是否存在任何不匹配缺陷。
- In the case of ODUk-to-OTUk mapping, the size of the Bit Map field MUST be 0, and no additional procedure is needed.
- 在ODUk到OTUk映射的情况下，位图字段的大小必须为0，并且不需要额外的过程。
When a downstream node or egress node receives a Path message containing a GENERALIZED_LABEL_REQUEST object for setting up an ODUj LSP from its upstream neighbor node, the node MUST generate an OTN-TDM label according to the Signal Type of the requested LSP and the available resources (i.e., available tributary slots of ODUk) that will be reserved for the LSP and send the label to its upstream neighbor node.
当下游节点或出口节点从其上游邻居节点接收到包含用于设置ODUj LSP的通用_标签_请求对象的路径消息时，该节点必须根据所请求LSP的信号类型和可用资源（即，ODUk的可用分支时隙）生成OTN-TDM标签这将为LSP保留，并将标签发送到其上游邻居节点。
- In the case of ODUj-to-ODUk multiplexing, the node MUST first determine the size of the Bit Map field according to the Signal Type and the tributary slot type of ODUk and then set the bits to 1 in the Bit Map field corresponding to the reserved tributary slots. The node MUST also assign a valid TPN, which MUST NOT collide with other TPN values used by existing LO ODU connections in the selected HO ODU link, and configure the Expected MSI (ExMSI) using this TPN. Then, the assigned TPN MUST be filled into the label.
- 在ODUj到ODUk复用的情况下，节点必须首先根据ODUk的信号类型和支路时隙类型确定位图字段的大小，然后在对应于保留支路时隙的位图字段中将位设置为1。节点还必须分配有效的TPN，该TPN不得与所选HO ODU链路中现有LO ODU连接使用的其他TPN值冲突，并使用该TPN配置预期的MSI（ExMSI）。然后，必须将指定的TPN填入标签中。
- In the case of ODUk-to-OTUk mapping, the TPN field MUST be set to 0. Bit Map information is not required and MUST NOT be included, so the Length field MUST be set to 0 as well.
- 在ODUk到OTUk映射的情况下，TPN字段必须设置为0。位图信息不是必需的，也不能包含在内，因此长度字段也必须设置为0。
When an upstream node receives a Resv message containing a GENERALIZED_LABEL object with an OTN-TDM label, the node MUST verify if the label is acceptable. If the label is not acceptable, the node MUST generate a ResvErr message with a "Routing problem/Unacceptable label value" indication. Per [RFC3473], the generated ResvErr message MAY include an ACCEPTABLE_LABEL_SET object. With the exception of label semantics, a downstream node processing a received ResvErr message and ACCEPTABLE_LABEL_SET object is not modified by this document.
当上游节点接收到包含带有OTN-TDM标签的广义_标签对象的Resv消息时，该节点必须验证标签是否可接受。如果标签不可接受，则节点必须生成带有“路由问题/不可接受标签值”指示的ResvErr消息。根据[RFC3473]，生成的ResvErr消息可能包括可接受的标签集对象。除了标签语义之外，处理接收到的ResvErr消息和可接受的\u label\u SET对象的下游节点不会被本文档修改。
Similarly, when a downstream node receives a Path message containing an UPSTREAM_LABEL object with an OTN-TDM label, the node MUST verify if the label is acceptable. If the label is not acceptable, the node MUST generate a PathErr message with a "Routing problem/Unacceptable label value" indication. Per [RFC3473], the generated PathErr message MAY include an ACCEPTABLE_LABEL_SET object. With the exception of label semantics, the upstream nodes processing a received PathErr message and ACCEPTABLE_LABEL_SET object are not modified by this document.
类似地，当下游节点接收到包含带有OTN-TDM标签的上游标签对象的路径消息时，该节点必须验证标签是否可接受。如果标签不可接受，则节点必须生成带有“路由问题/不可接受标签值”指示的PathErr消息。根据[RFC3473]，生成的PathErr消息可能包括可接受的\u标签\u集对象。除标签语义外，处理接收到的PathErr消息和可接受的\u label\u SET对象的上游节点不受本文档的修改。
A received label SHALL be considered unacceptable when one of the following cases occurs:
当出现下列情况之一时，收到的标签应视为不可接受：
- The received label doesn't conform to local policy;
- 收到的标签不符合当地政策；
- An invalid value appears in the Length field;
- 长度字段中出现无效值；
- The selected link only supports 2.5 Gbps TS granularity while the Length field in the label along with ODUk Signal Type indicates the 1.25 Gbps TS granularity;
- 所选链路仅支持2.5 Gbps TS粒度，标签中的长度字段以及ODUk信号类型表示1.25 Gbps TS粒度；
- The label includes an invalid TPN value that breaks the TPN assignment rules; and
- 标签包含一个无效的TPN值，该值违反TPN分配规则；和
- The indicated resources (i.e., the number of "1"s in the Bit Map field) are inconsistent with the Traffic Parameters.
- 指示的资源（即位图字段中“1”的数量）与流量参数不一致。
Per [RFC6344], the Virtual Concatenation Groups (VCGs) can be created using the One LSP approach or the Multiple LSPs approach.
根据[RFC6344]，可以使用一个LSP方法或多个LSP方法创建虚拟连接组（VCG）。
In the case of the One LSP approach, the explicit ordered list of all labels MUST reflect the order of VCG members, which is similar to [RFC4328]. In the case of multiplexed virtually concatenated signals (NVC > 1), the first label MUST indicate the components of the first virtually concatenated signal; the second label MUST indicate the components of the second virtually concatenated signal; and so on. In the case of multiplication of multiplexed virtually concatenated signals (MT > 1), the first label MUST indicate the components of the first multiplexed virtually concatenated signal; the second label MUST indicate components of the second multiplexed virtually concatenated signal; and so on.
对于一个LSP方法，所有标签的显式有序列表必须反映VCG成员的顺序，这类似于[RFC4328]。在多路复用虚拟级联信号（NVC>1）的情况下，第一标签必须指示第一虚拟级联信号的分量；第二标签必须指示第二虚拟级联信号的分量；等等在复用虚拟级联信号（MT>1）的乘法的情况下，第一标签必须指示第一复用虚拟级联信号的分量；第二标签必须指示第二复用虚拟级联信号的分量；等等
Support for Virtual Concatenation of ODU1, ODU2, and ODU3 Signal Types, as defined by [RFC6344], is not modified by this document. Virtual Concatenation of other Signal Types is not supported by [G709-2012].
本文档未修改对[RFC6344]定义的ODU1、ODU2和ODU3信号类型的虚拟串联的支持。[G709-2012]不支持其他信号类型的虚拟级联。
Multiplier (MT) usage is as defined in [RFC6344] and [RFC4328].
乘数（MT）的使用如[RFC6344]和[RFC4328]中所定义。
The following examples are given in order to illustrate the label format described in Section 6.1 of this document.
以下示例旨在说明本文件第6.1节中所述的标签格式。
(1) ODUk-to-OTUk Mapping:
(1) ODUk到OTUk映射：
In this scenario, the downstream node along an LSP returns a label indicating that the ODUk (k=1, 2, 3, 4) is directly mapped into the corresponding OTUk. The following example label indicates an ODU1 mapped into OTU1.
在该场景中，沿着LSP的下游节点返回一个标签，指示ODUk（k＝1、2、3、4）直接映射到相应的OTUk。下面的示例标签表示映射到OTU1的ODU1。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 0 | Reserved | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 0 | Reserved | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(2) ODUj-to-ODUk Multiplexing:
(2) ODUj到ODUk多路复用：
In this scenario, this label indicates that an ODUj is multiplexed into several tributary slots of OPUk and then mapped into OTUk. Some instances are shown as follows:
在这个场景中，这个标签表示ODUj被多路复用到OPUk的几个分支插槽中，然后映射到OTUk。一些实例如下所示：
- ODU0-to-ODU2 Multiplexing:
- ODU0到ODU2多路复用：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 2 | Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 2 | Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The label above indicates an ODU0 multiplexed into the second tributary slot of ODU2, wherein there are 8 TSs in ODU2 (i.e., the type of the tributary slot is 1.25 Gbps), and the TPN value is 2.
上面的标签表示复用到ODU2的第二支路时隙中的ODU0，其中ODU2中有8个TSs（即支路时隙的类型为1.25 Gbps），TPN值为2。
- ODU1-to-ODU2 Multiplexing with 1.25 Gbps TS Granularity:
- 具有1.25 Gbps TS粒度的ODU1到ODU2多路复用：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 1 | Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 1 | Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The label above indicates an ODU1 multiplexed into the 2nd and the 4th tributary slots of ODU2, wherein there are 8 TSs in ODU2 (i.e., the type of the tributary slot is 1.25 Gbps), and the TPN value is 1.
上面的标签表示复用到ODU2的第二和第四支路时隙中的ODU1，其中ODU2中有8个TSs（即支路时隙的类型为1.25 Gbps），TPN值为1。
- ODU2 into ODU3 Multiplexing with 2.5 Gbps TS Granularity:
- 采用2.5 Gbps TS粒度的ODU2到ODU3多路复用：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 1 | Reserved | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 1 | Reserved | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The label above indicates an ODU2 multiplexed into the 2nd, 3rd, 5th, and 7th tributary slots of ODU3, wherein there are 16 TSs in ODU3 (i.e., the type of the tributary slot is 2.5 Gbps), and the TPN value is 1.
上面的标签表示多路复用到ODU3的第2、第3、第5和第7支路插槽中的ODU2，其中ODU3中有16个TSs（即支路插槽的类型为2.5 Gbps），TPN值为1。
[G7044] describes the procedure of ODUflex(GFP) hitless resizing using the Link Connection Resize (LCR) and Bandwidth Resize (BWR) protocols in the OTN data plane.
[G7044]描述了在OTN数据平面中使用链路连接调整大小（LCR）和带宽调整大小（BWR）协议进行ODUflex（GFP）无故障调整大小的过程。
For the control plane, signaling messages are REQUIRED to initiate the adjustment procedure. Sections 2.5 and 4.6.4 of [RFC3209] describe how the Shared Explicit (SE) style is used in the Traffic Engineering (TE) network for bandwidth increasing and decreasing, which is still applicable for triggering the ODUflex(GFP) adjustment procedure in the data plane.
对于控制平面，需要信令消息来启动调整程序。[RFC3209]的第2.5节和第4.6.4节描述了如何在流量工程（TE）网络中使用共享显式（SE）样式来增加和减少带宽，这仍然适用于触发数据平面中的ODUflex（GFP）调整过程。
Note that the SE style MUST be used at the beginning when creating a resizable ODUflex connection (Signal Type = 21). Otherwise an error with Error Code "Conflicting reservation style" MUST be generated when performing bandwidth adjustment.
请注意，在创建可调整大小的ODUflex连接（信号类型=21）时，必须在开始时使用SE样式。否则，在执行带宽调整时，必须生成错误代码为“冲突保留样式”的错误。
- Bandwidth Increasing
- 带宽增加
For the ingress node, in order to increase the bandwidth of an ODUflex(GFP) connection, a Path message with SE style (keeping Tunnel ID unchanged and assigning a new LSP ID) MUST be sent along the path.
对于入口节点，为了增加ODUflex（GFP）连接的带宽，必须沿路径发送SE样式的路径消息（保持隧道ID不变并分配新的LSP ID）。
The ingress node will trigger the BWR protocol when successful completion of LCR protocols on every hop after the Resv message is processed. On success of BWR, the ingress node SHOULD send a PathTear message to delete the old control state (i.e., the control state of the ODUflex(GFP) before resizing) on the control plane.
在处理Resv消息后，当在每个跃点上成功完成LCR协议时，入口节点将触发BWR协议。BWR成功后，入口节点应发送Path催泪消息，以删除控制平面上的旧控制状态（即，调整大小之前的ODUflex（GFP）控制状态）。
A downstream node receiving a Path message with SE style compares the old Traffic Parameters (stored locally) with the new one carried in the Path message to determine the number of TSs to be added. After choosing and reserving new available TS(s), the downstream node MUST send back a Resv message carrying both the old and new GENERALIZED_LABEL objects in the SE flow descriptor.
接收SE样式的路径消息的下游节点将旧流量参数（本地存储）与路径消息中携带的新流量参数进行比较，以确定要添加的TSs的数量。在选择并保留新的可用TS之后，下游节点必须发送回Resv消息，该消息携带SE流描述符中的新旧通用_标签对象。
An upstream neighbor receiving a Resv message with an SE flow descriptor MUST determine which TS(s) is/are added and trigger the LCR protocol between itself and its downstream neighbor node.
接收带有SE流描述符的Resv消息的上游邻居必须确定添加了哪些TS，并触发其自身与其下游邻居节点之间的LCR协议。
- Bandwidth Decreasing
- 带宽减少
For the ingress node, a Path message with SE style SHOULD also be sent for decreasing the ODUflex bandwidth.
对于入口节点，还应发送SE样式的路径消息，以减少ODUflex带宽。
The ingress node will trigger the BWR protocol when successful completion of LCR handshake on every hop after Resv message is processed. On success of BWR, the second step of LCR, i.e., link connection decrease procedure will be started on every hop of the connection. After decreasing the bandwidth, the ingress node SHOULD send a ResvErr message to tear down the old control state.
在处理Resv消息后，当成功完成每个跃点上的LCR握手时，入口节点将触发BWR协议。BWR成功后，LCR的第二步，即链路连接减少过程将在连接的每个跃点上启动。在降低带宽后，入口节点应发送ResvErr消息以解除旧的控制状态。
A downstream node receiving a Path message with SE style compares the old Traffic Parameters with the new one carried in the Path message to determine the number of TSs to be decreased. After choosing TSs to be decreased, the downstream node MUST send back a Resv message carrying both the old and new GENERALIZED_LABEL objects in the SE flow descriptor.
接收SE样式的路径消息的下游节点将旧业务参数与路径消息中携带的新业务参数进行比较，以确定要减少的TSs的数量。选择要减少的TSs后，下游节点必须发回一条Resv消息，其中包含SE流描述符中的新旧通用_标签对象。
An upstream neighbor receiving a Resv message with an SE flow descriptor MUST determine which TS(s) is/are decreased and trigger the first step of the LCR protocol (i.e., LCR handshake) between itself and its downstream neighbor node.
接收带有SE流描述符的Resv消息的上游邻居必须确定减少了哪些TS，并触发其自身与其下游邻居节点之间的LCR协议的第一步（即LCR握手）。
OTN OAM configuration could be done through either Network Management Systems (NMSs) or the GMPLS control plane as defined in [TDM-OAM]. [RFC4783] SHOULD be used for communication of alarm information in GMPLS-based OTN.
OTN OAM配置可以通过网络管理系统（NMS）或[TDM-OAM]中定义的GMPLS控制平面完成。[RFC4783]应用于基于GMPLS的OTN中的报警信息通信。
Management Information Bases (MIBs) may need be extended to read new information (e.g., OTN-TDM Generalized Label and OTN-TDM SENDER_TSPEC / FLOWSPEC) from the OTN devices. This is outside the scope of this document.
可能需要扩展管理信息库（MIB）以从OTN设备读取新信息（例如，OTN-TDM通用标签和OTN-TDM发送者_TSPEC/FLOWSPEC）。这超出了本文件的范围。
More information about the management aspects for GMPLS-based OTN, refer to Section 5.7 of [RFC7062].
有关基于GMPLS的OTN管理方面的更多信息，请参阅[RFC7062]第5.7节。
As described in [RFC7062], since [RFC4328] has been deployed in the network for the nodes that support the 2001 revision of the G.709 specification, control-plane backward compatibility SHOULD be taken into consideration. More specifically:
如[RFC7062]所述，由于[RFC4328]已部署在网络中，用于支持2001版G.709规范的节点，因此应考虑控制平面向后兼容性。更具体地说：
o Nodes supporting this document SHOULD support [RFC7138].
o 支持此文档的节点应支持[RFC7138]。
o Nodes supporting this document MAY support [RFC4328] signaling.
o 支持本文档的节点可能支持[RFC4328]信令。
o A node supporting both sets of procedures (i.e., [RFC4328] and this document) is not required to signal an LSP using both procedures, i.e., to act as a signaling version translator.
o 支持两组过程（即[RFC4328]和本文档）的节点不需要使用这两个过程向LSP发送信号，即充当信号版本转换器。
o Ingress nodes that support both sets of procedures MAY select which set of procedures to follow based on routing information or local policy.
o 支持这两组过程的入口节点可以基于路由信息或本地策略选择要遵循的过程集。
o Per [RFC3473], nodes that do not support this document will generate a PathErr message, with a "Routing problem/Switching Type" indication.
o 根据[RFC3473]，不支持此文档的节点将生成一条PathErr消息，并带有“路由问题/切换类型”指示。
This document is a modification to [RFC3473] and [RFC4328]; it only differs in specific information communicated. As such, this document introduces no new security considerations to the existing GMPLS signaling protocols. Refer to [RFC3473] and [RFC4328] for further details of the specific security measures. Additionally, [RFC5920] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane.
本文件是对[RFC3473]和[RFC4328]的修改；它只是在传达的具体信息上有所不同。因此，本文件没有对现有的GMPLS信令协议引入新的安全注意事项。有关具体安全措施的更多详细信息，请参阅[RFC3473]和[RFC4328]。此外，[RFC5920]概述了GMPLS控制平面的安全漏洞和保护机制。
IANA has made the following assignments in the "Class Types or C-Types - 9 FLOWSPEC" and "Class Types or C-Types - 12 SENDER_TSPEC" section of the "Resource Reservation Protocol (RSVP) Parameters" registry located at <http://www.iana.org/assignments/ rsvp-parameters>.
IANA已在“资源保留协议（RSVP）参数”注册表的“类别类型或C类型-9流程规范”和“类别类型或C类型-12发送者_TSPEC”部分进行了以下分配，位于<http://www.iana.org/assignments/ rsvp参数>。
Value Description Reference 7 OTN-TDM [RFC7139]
值说明参考7 OTN-TDM[RFC7139]
IANA maintains the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry (see <http://www.iana.org/assignments/gmpls-sig-parameters>). The "Generalized PIDs (G-PID)" subregistry is included in this registry, which is extended and updated by this document as detailed below.
IANA维护“通用多协议标签交换（GMPLS）信令参数”注册表（参见<http://www.iana.org/assignments/gmpls-sig-parameters>). “广义PID（G-PID）”子区域包含在本登记册中，本文件对其进行了扩展和更新，详情如下。
Value Type Technology Reference
===== ====================== ========== =========
47 G.709 ODU-2.5G G.709 ODUk [RFC4328]
(IANA updated the Type field) [RFC7139]
56 SBCON/ESCON G.709 ODUk, [RFC4328]
(IANA updated the Type field) Lambda, Fiber [RFC7139]
59 Framed GFP G.709 ODUk [RFC7139]
60 STM-1 G.709 ODUk [RFC7139]
61 STM-4 G.709 ODUk [RFC7139]
62 InfiniBand G.709 ODUflex [RFC7139]
63 SDI (Serial Digital Interface) G.709 ODUk [RFC7139]
64 SDI/1.001 G.709 ODUk [RFC7139]
65 DVB_ASI G.709 ODUk [RFC7139]
66 G.709 ODU-1.25G G.709 ODUk [RFC7139]
67 G.709 ODU-any G.709 ODUk [RFC7139]
68 Null Test G.709 ODUk [RFC7139]
69 Random Test G.709 ODUk [RFC7139]
70 64B/66B GFP-F Ethernet G.709 ODUk [RFC7139]
Value Type Technology Reference
===== ====================== ========== =========
47 G.709 ODU-2.5G G.709 ODUk [RFC4328]
(IANA updated the Type field) [RFC7139]
56 SBCON/ESCON G.709 ODUk, [RFC4328]
(IANA updated the Type field) Lambda, Fiber [RFC7139]
59 Framed GFP G.709 ODUk [RFC7139]
60 STM-1 G.709 ODUk [RFC7139]
61 STM-4 G.709 ODUk [RFC7139]
62 InfiniBand G.709 ODUflex [RFC7139]
63 SDI (Serial Digital Interface) G.709 ODUk [RFC7139]
64 SDI/1.001 G.709 ODUk [RFC7139]
65 DVB_ASI G.709 ODUk [RFC7139]
66 G.709 ODU-1.25G G.709 ODUk [RFC7139]
67 G.709 ODU-any G.709 ODUk [RFC7139]
68 Null Test G.709 ODUk [RFC7139]
69 Random Test G.709 ODUk [RFC7139]
70 64B/66B GFP-F Ethernet G.709 ODUk [RFC7139]
The new G-PIDs are shown in the TC MIB managed by IANA at <https://www.iana.org/assignments/ianagmplstc-mib> as follows:
新的G-PID显示在IANA管理的TC MIB中<https://www.iana.org/assignments/ianagmplstc-mib>详情如下:
g709FramedGFP(59), g709STM1(60), g709STM4(61), g709InfiniBand(62), g709SDI(63), g709SDI1point001(64), g709DVBASI(65), g709ODU1point25G(66), g709ODUAny(67), g709NullTest(68), g709RandomTest(69), g709GFPFEthernet(70)
g709FramedGFP（59）、g709STM1（60）、g709STM4（61）、g709InfiniBand（62）、g709SDI（63）、g709SDI1point001（64）、g709DVBASI（65）、g709ODU1point25G（66）、g709ODUAny（67）、g709NullTest（68）、g709RandomTest（69）、g709GFPFEthernet（70）
Note that IANA has not changed the names of the objects in this MIB module with the values 47 and 56.
请注意，IANA没有使用值47和56更改此MIB模块中对象的名称。
IANA has defined an "OTN Signal Type" subregistry to the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry:
IANA已在“通用多协议标签交换（GMPLS）信令参数”注册表中定义了“OTN信号类型”子区域：
Value Signal Type Reference
----- ----------- ---------
0 Not significant [RFC4328]
1 ODU1 (i.e., 2.5 Gbps) [RFC4328]
2 ODU2 (i.e., 10 Gbps) [RFC4328]
3 ODU3 (i.e., 40 Gbps) [RFC4328]
4 ODU4 (i.e., 100 Gbps) [RFC7139]
5 Unassigned [RFC4328]
6 Och at 2.5 Gbps [RFC4328]
7 OCh at 10 Gbps [RFC4328]
8 OCh at 40 Gbps [RFC4328]
9 OCh at 100 Gbps [RFC7139]
10 ODU0 (i.e., 1.25 Gbps) [RFC7139]
11 ODU2e (i.e., 10 Gbps for FC1200 [RFC7139]
and GE LAN)
12-19 Unassigned [RFC7139]
20 ODUflex(CBR) (i.e., 1.25*N Gbps) [RFC7139]
21 ODUflex(GFP-F), resizable [RFC7139]
(i.e., 1.25*N Gbps)
22 ODUflex(GFP-F), non-resizable [RFC7139]
(i.e., 1.25*N Gbps)
23-255 Unassigned [RFC7139]
Value Signal Type Reference
----- ----------- ---------
0 Not significant [RFC4328]
1 ODU1 (i.e., 2.5 Gbps) [RFC4328]
2 ODU2 (i.e., 10 Gbps) [RFC4328]
3 ODU3 (i.e., 40 Gbps) [RFC4328]
4 ODU4 (i.e., 100 Gbps) [RFC7139]
5 Unassigned [RFC4328]
6 Och at 2.5 Gbps [RFC4328]
7 OCh at 10 Gbps [RFC4328]
8 OCh at 40 Gbps [RFC4328]
9 OCh at 100 Gbps [RFC7139]
10 ODU0 (i.e., 1.25 Gbps) [RFC7139]
11 ODU2e (i.e., 10 Gbps for FC1200 [RFC7139]
and GE LAN)
12-19 Unassigned [RFC7139]
20 ODUflex(CBR) (i.e., 1.25*N Gbps) [RFC7139]
21 ODUflex(GFP-F), resizable [RFC7139]
(i.e., 1.25*N Gbps)
22 ODUflex(GFP-F), non-resizable [RFC7139]
(i.e., 1.25*N Gbps)
23-255 Unassigned [RFC7139]
New values are to be assigned via Standards Action as defined in [RFC5226].
通过[RFC5226]中定义的标准行动分配新值。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[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月。
[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月。
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[RFC4506]艾斯勒，M.，编辑，“XDR：外部数据表示标准”，STD 67，RFC 4506，2006年5月。
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.
[RFC4783]Berger，L.，Ed.“GMPLS-报警信息的通信”，RFC 4783，2006年12月。
[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月。
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and J. Drake, "Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks", RFC 7138, March 2014.
[RFC7138]Ceccarelli，D.，Ed.，Zhang，F.，Belotti，S.，Rao，R.，和J.Drake，“用于GMPLS控制不断发展的G.709光传输网络的OSPF流量工程扩展”，RFC 7138，2014年3月。
[G709-2012] ITU-T, "Interfaces for the Optical Transport Network (OTN)", G.709/Y.1331 Recommendation, February 2012.
[G709-2012]ITU-T，“光传输网络（OTN）接口”，G.709/Y.1331建议，2012年2月。
[G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347, October 2011.
[G7044]ITU-T，“ODUflex的无故障调整”，G.7044/Y.1347，2011年10月。
[G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April 2011.
[G7041]ITU-T，“通用成帧程序”，G.7041/Y.1303，2011年4月。
[IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, Institute of Electrical and Electronics Engineers, August 1985.
[IEEE]“二进制浮点运算的IEEE标准”，ANSI/IEEE标准754-1985，电气和电子工程师协会，1985年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", RFC 7062, November 2013.
[RFC7062]Zhang，F.，Ed.，Li，D.，Li，H.，Belotti，S.，和D.Ceccarelli，“G.709光传输网络的GMPLS和PCE控制框架”，RFC 7062，2013年11月。
[RFC7096] Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed., Caviglia, D., Zhang, F., and D. Li, "Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)", RFC 7096, January 2014.
[RFC7096]Belotti，S.，Ed.，Grandi，P.，Ceccarelli，D.，Ed.，Caviglia，D.，Zhang，F.，和D.Li，“根据G.709v3光传输网络（OTN）评估现有GMPLS编码”，RFC 7096，2014年1月。
[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月。
Yi Lin Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28972914 EMail: yi.lin@huawei.com
易林华为技术F3-5-B研发中心，华为总部深圳市龙岗区坂田518129电话：+86-755-28972914电子邮件：易。lin@huawei.com
Yunbin Xu China Academy of Telecommunication Research of MII 11 Yue Tan Nan Jie Beijing P.R. China Phone: +86-10-68094134 EMail: xuyunbin@mail.ritt.com.cn
徐云斌信息产业部电信研究院11月坛南街中国北京电话：+86-10-68094134电子邮件：xuyunbin@mail.ritt.com.cn
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-朗讯
Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy EMail: diego.caviglia@ericsson.com
Diego Caviglia Ericsson通过A.Negrone 1/A Genova-Sestri Ponente Italy电子邮件：Diego。caviglia@ericsson.com
Rajan Rao Infinera Corporation 169, Java Drive Sunnyvale, CA 94089 USA EMail: rrao@infinera.com
Rajan Rao Infinera Corporation 169，加利福尼亚州森尼维尔Java Drive 94089美国电子邮件：rrao@infinera.com
John E Drake Juniper EMail: jdrake@juniper.net
John E Drake Juniper电子邮件：jdrake@juniper.net
Igor Bryskin Adva Optical EMail: IBryskin@advaoptical.com
Igor Bryskin Adva光学电子邮件：IBryskin@advaoptical.com
Jonathan Sadler, Tellabs EMail: jonathan.sadler@tellabs.com
Jonathan Sadler，Tellabs电子邮件：Jonathan。sadler@tellabs.com
Kam LAM, Alcatel-Lucent EMail: kam.lam@alcatel-lucent.com
金林，阿尔卡特朗讯电子邮件：Kam。lam@alcatel-朗讯网
Francesco Fondelli, Ericsson EMail: francesco.fondelli@ericsson.com
Francesco Fondelli，爱立信电子邮件：Francesco。fondelli@ericsson.com
Lyndon Ong, Ciena EMail: lyong@ciena.com
Lyndon Ong，Ciena电子邮件：lyong@ciena.com
Biao Lu, infinera EMail: blu@infinera.com
刘彪，infinera电子邮件：blu@infinera.com
The authors would like to thank Lou Berger, Deborah Brungard, and Xiaobing Zi for their useful comments regarding this document.
作者要感谢Lou Berger、Deborah Brungard和Xiao Bing Zi对本文件的有用评论。
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
Guoying Zhang China Academy of Telecommunication Research of MII 11 Yue Tan Nan Jie Beijing P.R. China Phone: +86-10-68094272 EMail: zhangguoying@mail.ritt.com.cn
张国英信息产业部电信研究院11月坛南街中国北京电话：+86-10-68094272电子邮件：zhangguoying@mail.ritt.com.cn
Sergio Belotti Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate Milano Italy Phone: +39 039 6863033 EMail: sergio.belotti@alcatel-lucent.it
塞尔吉奥·贝洛蒂·阿尔卡特·朗讯光学首席技术官，电话号码：30 20059意大利米兰维美卡特电话：+39 039 6863033电子邮件：塞尔吉奥。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
Khuzema Pithewan Infinera Corporation 169, Java Drive Sunnyvale, CA 94089 USA EMail: kpithewan@infinera.com
Khuzema Pithewan Infinera Corporation 169，加利福尼亚州桑尼维尔市爪哇大道，邮编94089美国电子邮件：kpithewan@infinera.com