Network Working Group D. Papadimitriou, Ed.
Request for Comments: 4328 Alcatel
Updates: 3471 January 2006
Category: Standards Track
Network Working Group D. Papadimitriou, Ed.
Request for Comments: 4328 Alcatel
Updates: 3471 January 2006
Category: Standards Track
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control
用于G.709光传输网络控制的通用多协议标签交换（GMPLS）信令扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments.
本文件是通用多协议标签交换（GMPLS）信令文件的配套文件。它描述了将GMPLS信令扩展到控制光传输网络（OTN）所需的技术特定信息；它还包括所谓的OTN前开发。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. GMPLS Extensions for G.709 - Overview ...........................3
3. Generalized Label Request .......................................4
3.1. Common Part ................................................5
3.1.1. LSP Encoding Type ...................................5
3.1.2. Switching Type ......................................6
3.1.3. Generalized-PID (G-PID) .............................6
3.2. G.709 Traffic Parameters ...................................8
3.2.1. Signal Type (ST) ....................................8
3.2.2. Number of Multiplexed Components (NMC) ..............9
3.2.3. Number of Virtual Components (NVC) .................10
3.2.4. Multiplier (MT) ....................................10
3.2.5. Reserved Fields ....................................10
4. Generalized Label ..............................................10
4.1. ODUk Label Space ..........................................11
4.2. Label Distribution Rules ..................................13
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. GMPLS Extensions for G.709 - Overview ...........................3
3. Generalized Label Request .......................................4
3.1. Common Part ................................................5
3.1.1. LSP Encoding Type ...................................5
3.1.2. Switching Type ......................................6
3.1.3. Generalized-PID (G-PID) .............................6
3.2. G.709 Traffic Parameters ...................................8
3.2.1. Signal Type (ST) ....................................8
3.2.2. Number of Multiplexed Components (NMC) ..............9
3.2.3. Number of Virtual Components (NVC) .................10
3.2.4. Multiplier (MT) ....................................10
3.2.5. Reserved Fields ....................................10
4. Generalized Label ..............................................10
4.1. ODUk Label Space ..........................................11
4.2. Label Distribution Rules ..................................13
4.3. Optical Channel Label Space ...............................14
5. Examples .......................................................14
6. RSVP-TE Signaling Protocol Extensions ..........................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................16
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
11. Contributors ..................................................19
Appendix A. Abbreviations .........................................21
Appendix B. G.709 Indexes .........................................22
4.3. Optical Channel Label Space ...............................14
5. Examples .......................................................14
6. RSVP-TE Signaling Protocol Extensions ..........................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................16
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
11. Contributors ..................................................19
Appendix A. Abbreviations .........................................21
Appendix B. G.709 Indexes .........................................22
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends MPLS from supporting Packet Switching Capable (PSC) interfaces and switching to include support of four new classes of interfaces and switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM), Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional description of the extensions to MPLS signaling that are needed to support these new classes of interfaces and switching is provided in [RFC3471]. [RFC3473] describes the RSVP-TE-specific formats and mechanisms needed to support all four classes of interfaces.
通用多协议标签交换（GMPLS）[RFC3945]将MPLS从支持分组交换功能（PSC）接口和交换扩展到支持四类新的接口和交换：第二层交换（L2SC）、时分复用（TDM）、Lambda交换（LSC）和光纤交换（FSC）。[RFC3471]中提供了支持这些新型接口和交换所需的MPLS信令扩展的功能描述。[RFC3473]描述了支持所有四类接口所需的RSVP TE特定格式和机制。
This document presents the technology details that are specific to G.709 Optical Transport Networks (OTN) as specified in the ITU-T G.709 recommendation [ITUT-G709] (and referenced documents), including pre-OTN developments. Per [RFC3471], G.709 technology-specific parameters are carried through the signaling protocol in dedicated traffic parameter objects.
本文件介绍了ITU-T G.709建议[ITUT-G709]（和参考文件）中规定的G.709光传输网络（OTN）特有的技术细节，包括OTN前的开发。根据[RFC3471]，G.709技术特定参数通过专用流量参数对象中的信令协议进行传输。
The G.709 traffic parameters defined hereafter (see Section 3.2) MUST be used when the label is encoded as defined in this document. Moreover, the label MUST be encoded as defined in Section 4 when these G.709 traffic parameters are used.
当标签按照本文件规定进行编码时，必须使用下文规定的G.709交通参数（见第3.2节）。此外，当使用这些G.709交通参数时，标签必须按照第4节中的定义进行编码。
In the context of this memo, by pre-OTN developments, one refers to Optical Channel, Digital Wrapper and Forward Error Correction (FEC) solutions that are not fully G.709 compliant. Details concerning pre-OTN Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) based solutions including Section/Regenerator Section overhead (SOH/RSOH) and Line/Multiplex Section overhead (LOH/MSOH) transparency are covered in [RFC3946].
在本备忘录的上下文中，根据OTN之前的开发，一个是指不完全符合G.709的光信道、数字包装器和前向纠错（FEC）解决方案。[RFC3946]中介绍了有关基于OTN前同步光网络（SONET）/同步数字体系（SDH）的解决方案的详细信息，包括区段/再生器区段开销（SOH/RSOH）和线路/多路复用区段开销（LOH/MSOH）透明度。
*** Note on ITU-T G.709 Recommendation ***
*** Note on ITU-T G.709 Recommendation ***
The views on the ITU-T G.709 OTN Recommendation presented in this document are intentionally restricted to the GMPLS perspective within the IETF CCAMP WG context. Hence, the objective of this document is not to replicate the content of the ITU-T OTN recommendations. Therefore, readers interested in more details concerning the corresponding technologies are strongly invited to consult the corresponding ITU-T documents (also referenced in this memo).
本文件中提出的关于ITU-T G.709 OTN建议的观点有意局限于IETF CCAMP工作组背景下的GMPLS观点。因此，本文件的目的不是复制ITU-T OTN建议的内容。因此，强烈邀请对有关相应技术的更多细节感兴趣的读者参考相应的ITU-T文件（也在本备忘录中引用）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In addition, the reader is assumed to be familiar with the terminology used in ITU-T [ITUT-G709], as well as [RFC3471] and [RFC3473]. Abbreviations used in this document are detailed in Appendix 1.
此外，假定读者熟悉ITU-T[ITUT-G709]以及[RFC3471]和[RFC3473]中使用的术语。本文件中使用的缩略语详见附录1。
[ITUT-G709] defines several networking layers constituting the optical transport hierarchy:
[ITUT-G709]定义了构成光传输层次结构的几个网络层：
- with full functionality: . Optical Transmission Section (OTS) . Optical Multiplex Section (OMS) . Optical Channel (OCh) - with reduced functionality: . Optical Physical Section (OPS) . Optical Channel with reduced functionality (OChr)
- 具有完整功能：。光传输部分（OTS）。光多路复用部分（OMS）。光通道（OCh）-功能减少：。光学物理科（OPS）。功能降低的光信道（OChr）
It also defines two layers constituting the digital transport hierarchy:
它还定义了构成数字传输层次结构的两个层：
- Optical Channel Transport Unit (OTUk) - Optical Channel Data Unit (ODUk)
- 光信道传输单元（OTUk）-光信道数据单元（ODUk）
However, only the OCh and the ODUk layers are defined as switching layers. Both OCh (but not OChr) and ODUk layers include the overhead for supervision and management. The OCh overhead is transported in a non-associated manner (also referred to as the non-associated overhead naOH) in the Optical Transport Module (OTM) Overhead Signal (OOS), together with the OTS and OMS non-associated overhead. The OOS is transported via a dedicated wavelength, referred to as the Optical Supervisory Channel (OSC). It should be noticed that the
然而，只有OCh和ODUk层被定义为交换层。OCh（但不是OChr）和ODUk层都包括监督和管理的开销。在光传输模块（OTM）开销信号（OOS）中以非关联方式（也称为非关联开销naOH）传输OCh开销，以及OTS和OMS非关联开销。OOS通过专用波长传输，称为光监控信道（OSC）。应该注意的是
naOH is only functionally specified and as such, it is open to vendor-specific solutions. The ODUk overhead is transported in an associated manner as part of the digital ODUk frame.
naOH仅在功能上指定，因此，它对供应商特定的解决方案开放。ODUk开销作为数字ODUk帧的一部分以相关方式传输。
As described in [ITUT-G709], in addition to the support of ODUk mapping into OTUk (k = 1, 2, 3), G.709 supports ODUk multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into an ODUk (k > j) signal, in particular:
如[ITUT-G709]所述，除了支持ODUk映射到OTUk（k=1,2,3）之外，G.709还支持ODUk多路复用。它是指将ODUj（j＝1，2）复用成ODUk（k＞j）信号，具体而言：
- ODU1 into ODU2 multiplexing - ODU1 into ODU3 multiplexing - ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing
- ODU1到ODU2多路复用-ODU1到ODU3多路复用-ODU2到ODU3多路复用-ODU1和ODU2到ODU3多路复用
Adapting GMPLS to control G.709 OTN can be achieved by creating:
通过创建以下内容，使GMPLS适应控制G.709 OTN：
- a Digital Path layer, by extending the previously defined "Digital Wrapper" in [RFC3471] corresponding to the ODUk (digital) path layer. - an Optical Path layer, by extending the "Lambda" concept (defined in [RFC3471]) to the OCh (optical) path layer. - a label space structure, by considering a tree whose root is an OTUk signal and leaves the ODUj signals (k >= j); enabling the identification of the exact position of a particular ODUj signal in an ODUk multiplexing structure.
- 数字路径层，通过扩展[RFC3471]中先前定义的与ODUk（数字）路径层对应的“数字包装器”。-通过将“Lambda”概念（在[RFC3471]中定义）扩展到OCh（光）路径层，形成光路径层。-标签空间结构，通过考虑其根为OTUk信号且离开ODUj信号的树（k>=j）；能够识别ODUk复用结构中特定ODUj信号的准确位置。
Thus, the GMPLS signaling extensions for G.709 need to cover the Generalized Label Request, the Generalized Label as well as the specific technology dependent objects included in the so-called traffic parameters as specified in [RFC3946] for SONET/SDH networks. Moreover, because multiplexing in the digital domain (such as ODUk multiplexing) has been specified in the amended version of the G.709 ITU-T recommendation (October 2001), this document also proposes a label space definition suitable for that purpose. Notice also that one uses the G.709 ODUk (i.e., Digital Path) and OCh (i.e., Optical Path) layers directly in order to define the corresponding label spaces.
因此，G.709的GMPLS信令扩展需要涵盖通用标签请求、通用标签以及SONET/SDH网络[RFC3946]中规定的所谓业务参数中包含的特定技术相关对象。此外，由于G.709 ITU-T建议（2001年10月）的修订版中规定了数字域中的多路复用（如ODUk多路复用），因此本文件还提出了适用于该目的的标签空间定义。还请注意，直接使用G.709 ODUk（即数字路径）和OCh（即光路径）层来定义相应的标签空间。
The Generalized Label Request, as defined in [RFC3471], includes a common part (i.e., used for any switching technology) and a technology dependent part (i.e., the traffic parameters). In this section, both parts are extended to accommodate GMPLS Signaling to the G.709 transport plane recommendation (see [ITUT-G709]).
[RFC3471]中定义的通用标签请求包括公共部分（即用于任何交换技术）和技术相关部分（即业务参数）。在本节中，这两部分都进行了扩展，以适应G.709运输机建议的GMPLS信号（见[ITUT-G709]）。
As defined in [RFC3471], the LSP Encoding Type, the Switching Type and the Generalized Protocol Identifier (Generalized-PID) constitute the common part of the Generalized Label Request. The encoding of the RSVP-TE GENERALIZED_LABEL_REQUEST object is specified in [RFC3473] Section 2.1.
如[RFC3471]中所定义，LSP编码类型、切换类型和通用协议标识符（通用PID）构成通用标签请求的公共部分。[RFC3473]第2.1节规定了RSVP-TE通用标签请求对象的编码。
As mentioned above, this document extends the LSP Encoding Type, the Switching Type, and G-PID (Generalized-PID) values to accommodate G.709 Recommendation [ITUT-G709].
如上所述，本文件扩展了LSP编码类型、切换类型和G-PID（通用PID）值，以适应G.709建议[ITUT-G709]。
Because G.709 Recommendation defines two networking layers (ODUk layers and OCh layer), the LSP Encoding Type code-points can reflect these two layers defined in [RFC3471] Section 3.1 as "Digital Wrapper" and "Lambda" code. The LSP Encoding Type is specified per networking layer or, more precisely, per group of functional networking layers: the ODUk layers and the OCh layer.
由于G.709建议定义了两个网络层（ODUk层和OCh层），因此LSP编码类型代码点可以反映[RFC3471]第3.1节中定义为“数字包装器”和“Lambda”代码的这两个层。LSP编码类型是按网络层指定的，更准确地说，是按功能网络层组指定的：ODUk层和OCh层。
Therefore, an additional LSP Encoding Type code-point for the G.709 Digital Path layer is defined; it enlarges the existing "Digital Wrapper" code-point defined in [RFC3471]. The former MUST be generated when the interface or tunnel on which the traffic will be transmitted supports G.709 compliant Digital Path layer encoding. The latter MUST only be used for non-G.709 compliant Digital Wrapper layer(s) encoding. A transit or an egress node (receiving a Path message containing a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication, if the requested LSP Encoding Type cannot be supported on the corresponding incoming interface.
因此，定义了用于G.709数字路径层的附加LSP编码类型码点；它放大了[RFC3471]中定义的现有“数字包装器”代码点。前者必须在传输流量的接口或隧道支持G.709兼容的数字路径层编码时生成。后者只能用于非G.709兼容的数字包装层编码。如果相应的传入接口上不支持请求的LSP编码类型，则传输或出口节点（接收包含通用\u标签\u请求对象的路径消息）必须生成带有“路由问题/不支持的编码”指示的PathErr消息。
In the same way, an additional LSP Encoding Type code-point for the G.709 Optical Channel layer is defined; it enlarges the existing "Lambda" code-point defined in [RFC3471]. The former MUST be generated when the interface or tunnel on which the traffic will be transmitted supports G.709-compliant Optical Channel layer encoding. The latter MUST only be used for non-G.709 compliant Lambda layer(s) encoding. A transit or an egress node (receiving a Path message that contains a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr message with a "Routing problem/Unsupported Encoding" indication, if the requested LSP Encoding Type cannot be supported on the corresponding incoming interface.
以相同方式，定义用于G.709光信道层的附加LSP编码类型码点；它放大了[RFC3471]中定义的现有“Lambda”代码点。前者必须在传输业务的接口或隧道支持G.709兼容的光信道层编码时生成。后者只能用于非G.709兼容的Lambda层编码。如果相应的传入接口上不支持请求的LSP编码类型，则传输或出口节点（接收包含通用\u标签\u请求对象的路径消息）必须生成带有“路由问题/不支持的编码”指示的PathErr消息。
Consequently, the following additional code-points for the LSP Encoding Type are defined:
因此，定义了LSP编码类型的以下附加代码点：
Value Type
----- ----
12 G.709 ODUk (Digital Path)
13 G.709 Optical Channel
Value Type
----- ----
12 G.709 ODUk (Digital Path)
13 G.709 Optical Channel
Moreover, the code-point for the G.709 Optical Channel (OCh) layer will indicate the requested capability of an end-system to use the G.709 non-associated overhead (naOH), i.e., the OTM Overhead Signal (OOS) multiplexed into the OTM-n.m interface signal.
此外，G.709光信道（OCh）层的码点将指示终端系统使用G.709非相关开销（naOH）的请求能力，即复用到OTM-n.m接口信号中的OTM开销信号（OOS）。
The Switching Type indicates the type of switching that should be performed at the termination of a particular link (see [RFC4202]).
切换类型表示应在特定链路终止时执行的切换类型（参见[RFC4202]）。
No additional Switching Type values are to be considered in order to accommodate G.709 switching types, because an ODUk switching (and thus LSPs) belongs to the TDM class, while an OCh switching (and thus LSPs) belong to the Lambda class (i.e., LSC).
为了适应G.709切换类型，不考虑其他切换类型值，因为ODUk切换（因此LSP）属于TDM类，而OCh切换（因此LSP）属于Lambda类（即LSC）。
Intermediate and egress nodes MUST verify that the value indicated in the Switching Type field is supported on the corresponding incoming interface. If the requested value can not be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication.
中间节点和出口节点必须验证相应的输入接口是否支持交换类型字段中指示的值。如果请求的值不受支持，则节点必须生成带有“路由问题/切换类型”指示的PathErr消息。
The G-PID (16 bits field), as defined in [RFC3471], identifies the payload carried by an LSP, i.e., an identifier of the client layer of that LSP. This identifier is used by the endpoints of the G.709 LSP.
[RFC3471]中定义的G-PID（16位字段）标识LSP承载的有效载荷，即该LSP的客户端层的标识符。该标识符由G.709 LSP的端点使用。
The G-PID can take one of the following values when the client payload is transported over the Digital Path layer, in addition to the payload identifiers defined in [RFC3471]:
除了[RFC3471]中定义的有效负载标识符外，当通过数字路径层传输客户端有效负载时，G-PID可以采用以下值之一：
- CBRa: asynchronous Constant Bit Rate (i.e., mapping of STM-16/OC-48, STM-64/OC-192 and STM-256/OC-768) - CBRb: bit synchronous Constant Bit Rate (i.e., mapping of STM-16/OC-48, STM-64/OC-192 and STM-256/OC-768) - ATM: mapping at 2.5, 10 and 40 Gbps - BSOT: non-specific client Bit Stream with Octet Timing (i.e., Mapping of 2.5, 10 and 40 Gbps Bit Stream) - BSNT: non-specific client Bit Stream without Octet Timing (i.e., Mapping of 2.5, 10 and 40 Gbps Bit Stream)
- CBRa：异步恒定比特率（即STM-16/OC-48、STM-64/OC-192和STM-256/OC-768的映射）-CBRb：比特同步恒定比特率（即STM-16/OC-48、STM-64/OC-192和STM-256/OC-768的映射）-ATM：2.5、10和40 Gbps的映射-BSOT：具有八位字节定时的非特定客户端比特流（即2.5、10和40 Gbps比特流的映射）-BSNT：无八位字节定时的非特定客户端比特流（即2.5、10和40 Gbps比特流的映射）
- ODUk: transport of Digital Paths at 2.5, 10 and 40 Gbps - ESCON: Enterprise Systems Connection - FICON: Fiber Connection
- ODUk：以2.5、10和40 Gbps传输数字路径-ESCON：企业系统连接-FICON：光纤连接
The G-PID can take one of the following values when the client payload is transported over the Optical Channel layer, in addition to the payload identifiers defined in [RFC3471]:
除了[RFC3471]中定义的有效负载标识符外，当客户端有效负载通过光信道层传输时，G-PID可以采用以下值之一：
- CBR: Constant Bit Rate (i.e., mapping of STM-16/OC-48, STM-64/OC-192 and STM-256/OC-768) - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps
- CBR：恒定比特率（即STM-16/OC-48、STM-64/OC-192和STM-256/OC-768的映射）-OTUk/OTUkV：以2.5、10和40 Gbps传输数字段
Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are encapsulated through the Generic Framing Procedure (GFP), as described in ITU-T G.7041, dedicated G-PID values are defined.
此外，如ITU-T G.7041所述，当通过通用成帧过程（GFP）封装以太网MAC/PHY和IP/PPP等客户端有效负载时，定义了专用的G-PID值。
In order to include pre-OTN developments, the G-PID field can take one of the values (currently defined in [RFC3471]) when the following client payloads are transported over a so-called lambda LSP:
为了包括OTN前的开发，当通过所谓的lambda LSP传输以下客户有效载荷时，G-PID字段可以采用其中一个值（当前在[RFC3471]中定义）：
- Ethernet PHY (1 Gbps and 10 Gbps) - Fiber Channel
- 以太网物理层（1 Gbps和10 Gbps）-光纤通道
The following table summarizes the G-PID with respect to the LSP Encoding Type:
下表总结了与LSP编码类型相关的G-PID：
Value G-PID Type LSP Encoding Type
----- ---------- -----------------
47 G.709 ODUj G.709 ODUk (with k > j)
48 G.709 OTUk(v) G.709 OCh
ODUk mapped into OTUk(v)
49 CBR/CBRa G.709 ODUk, G.709 OCh
50 CBRb G.709 ODUk
51 BSOT G.709 ODUk
52 BSNT G.709 ODUk
53 IP/PPP (GFP) G.709 ODUk (and SDH)
54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH)
55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH)
56 ESCON G.709 ODUk, Lambda, Fiber
57 FICON G.709 ODUk, Lambda, Fiber
58 Fiber Channel G.709 ODUk, Lambda, Fiber
Value G-PID Type LSP Encoding Type
----- ---------- -----------------
47 G.709 ODUj G.709 ODUk (with k > j)
48 G.709 OTUk(v) G.709 OCh
ODUk mapped into OTUk(v)
49 CBR/CBRa G.709 ODUk, G.709 OCh
50 CBRb G.709 ODUk
51 BSOT G.709 ODUk
52 BSNT G.709 ODUk
53 IP/PPP (GFP) G.709 ODUk (and SDH)
54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH)
55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH)
56 ESCON G.709 ODUk, Lambda, Fiber
57 FICON G.709 ODUk, Lambda, Fiber
58 Fiber Channel G.709 ODUk, Lambda, Fiber
Note: Values 49 and 50 include mapping of SDH.
注：值49和50包括SDH映射。
The following table summarizes the update of the G-PID values defined in [RFC3471]:
下表总结了[RFC3471]中定义的G-PID值的更新：
Value G-PID Type LSP Encoding Type
----- ---------- -----------------
32 ATM Mapping SDH, G.709 ODUk
33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber
34 Sonet/SDH G.709 OCh, Lambda, Fiber
35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber
Value G-PID Type LSP Encoding Type
----- ---------- -----------------
32 ATM Mapping SDH, G.709 ODUk
33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber
34 Sonet/SDH G.709 OCh, Lambda, Fiber
35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber
When G.709 Digital Path Layer or G.709 Optical Channel Layer is specified in the LSP Encoding Type field, the information referred to as technology dependent (or simply traffic parameters) is carried additionally to the one included in the Generalized Label Request.
当在LSP编码类型字段中指定G.709数字路径层或G.709光信道层时，被称为技术相关的信息（或简单的业务参数）被附加到包括在通用标签请求中的信息。
The G.709 traffic parameters are defined as follows:
G.709交通参数定义如下：
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 | NMC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | NMC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this frame, NMC stands for Number of Multiplexed Components, NVC for Number of Virtual Components, and MT for Multiplier. Each of these fields is tailored to support G.709 LSP requests.
在此帧中，NMC表示多路复用组件的数量，NVC表示虚拟组件的数量，MT表示乘法器。这些字段中的每一个都是为支持G.709 LSP请求而定制的。
The RSVP-TE encoding of the G.709 traffic-parameters is detailed in Section 6.
G.709交通参数的RSVP-TE编码详见第6节。
This field (8 bits) indicates the type of G.709 Elementary Signal that comprises the requested LSP. The permitted values are:
该字段（8位）表示组成所请求LSP的G.709基本信号的类型。允许值为：
Value Type
----- ----
0 Not significant
1 ODU1 (i.e., 2.5 Gbps)
2 ODU2 (i.e., 10 Gbps)
3 ODU3 (i.e., 40 Gbps)
4 Reserved (for future use)
Value Type
----- ----
0 Not significant
1 ODU1 (i.e., 2.5 Gbps)
2 ODU2 (i.e., 10 Gbps)
3 ODU3 (i.e., 40 Gbps)
4 Reserved (for future use)
5 Reserved (for future use) 6 OCh at 2.5 Gbps 7 OCh at 10 Gbps 8 OCh at 40 Gbps 9-255 Reserved (for future use)
5预留（供将来使用）2.5 Gbps的6 OCh 10 Gbps的7 OCh 40 Gbps的8 OCh 9-255预留（供将来使用）
The value of the Signal Type field depends on LSP Encoding Type value defined in Section 3.1.1 and [RFC3471]:
信号类型字段的值取决于第3.1.1节和[RFC3471]中定义的LSP编码类型值：
- if the LSP Encoding Type value is the G.709 Digital Path layer, then the valid values are the ODUk signals (k = 1, 2 or 3). - if the LSP Encoding Type value is the G.709 Optical Channel layer, then the valid values are the OCh at 2.5, 10, or 40 Gbps. - if the LSP Encoding Type is "Lambda" (which includes the pre-OTN Optical Channel layer) then the valid value is irrelevant (Signal Type = 0). - if the LSP Encoding Type is "Digital Wrapper", then the valid value is irrelevant (Signal Type = 0).
- 如果LSP编码类型值为G.709数字路径层，则有效值为ODUk信号（k=1、2或3）。-如果LSP编码类型值为G.709光信道层，则有效值为2.5、10或40 Gbps的OCh。-如果LSP编码类型为“Lambda”（包括OTN前光信道层），则有效值不相关（信号类型=0）。-如果LSP编码类型为“数字包装器”，则有效值不相关（信号类型=0）。
Several transforms can be sequentially applied on the Elementary Signal to build the Final Signal that is actually requested for the LSP. Each transform application is optional and must be ignored if zero; this does not include the Multiplier (MT), which cannot be zero and must be ignored if equal to one. Transforms must be applied strictly in the following order:
可以对基本信号顺序应用若干变换，以构建实际为LSP请求的最终信号。每个变换应用程序都是可选的，如果为零，则必须忽略；这不包括乘数（MT），它不能为零，如果等于1，则必须忽略。必须严格按照以下顺序应用变换：
- First, virtual concatenation (by using the NVC field) can be optionally applied directly on the Elementary Signal to form a Composed Signal - Second, a multiplication (by using the Multiplier field) can be optionally applied, either directly on the Elementary Signal, or on the virtually concatenated signal obtained from the first phase. The resulting signal is referred to as Final Signal.
- 首先，虚拟级联（通过使用NVC字段）可选择性地直接应用于基本信号以形成合成信号-其次，乘法（通过使用乘法器字段）可选择性地应用于基本信号或从第一相位获得的虚拟级联信号。产生的信号称为最终信号。
The NMC field (16 bits) indicates the number of ODU tributary slots used by an ODUj when multiplexed into an ODUk (k > j) for the requested LSP. This field is not applicable when an ODUk is mapped into an OTUk and irrelevant at the Optical Channel layer. In both cases, it MUST be set to zero (NMC = 0) when sent and should be ignored when received.
NMC字段（16位）表示当为请求的LSP多路复用到ODUk（k>j）中时，ODUj使用的ODU分支插槽的数量。当ODUk映射到OTUk且在光信道层不相关时，此字段不适用。在这两种情况下，发送时必须将其设置为零（NMC=0），接收时应忽略。
When applied at the Digital Path layer, in particular for ODU2 connections multiplexed into one ODU3 payload, the NMC field specifies the number of individual tributary slots (NMC = 4) that constitute the requested connection. These components are still processed within the context of a single connection entity. For all
当在数字路径层应用时，特别是对于多路复用到一个ODU3有效负载中的ODU2连接，NMC字段指定构成请求连接的各个分支时隙（NMC=4）的数量。这些组件仍然在单个连接实体的上下文中处理。总的来说
other currently defined multiplexing cases (see Section 2), the NMC field is set to 1.
在其他当前定义的多路复用情况下（参见第2节），NMC字段设置为1。
The NVC field (16 bits) is dedicated to ODUk virtual concatenation (i.e., ODUk Inverse Multiplexing) purposes. It indicates the number of ODU1, ODU2, or ODU3 Elementary Signals that are requested to be virtually concatenated to form an ODUk-Xv signal. By definition, these signals MUST be of the same type.
NVC字段（16位）专用于ODUk虚拟级联（即ODUk反向多路复用）目的。它表示请求虚拟连接以形成ODUk Xv信号的ODU1、ODU2或ODU3基本信号的数量。根据定义，这些信号必须是相同类型的。
This field is set to 0 (default value) to indicate that no virtual concatenation is requested.
此字段设置为0（默认值），表示未请求虚拟连接。
Note that the current usage of this field only applies for G.709 ODUk LSPs, i.e., values greater than zero, are only acceptable for ODUk Signal Types. Therefore, it MUST be set to zero (NVC = 0), and should be ignored when received, when a G.709 OCh LSP is requested.
请注意，该字段的当前用法仅适用于G.709 ODUk LSP，即大于零的值仅适用于ODUk信号类型。因此，当请求G.709 OCh LSP时，必须将其设置为零（NVC=0），并在收到时忽略。
The Multiplier field (16 bits) indicates the number of identical Elementary Signals or Composed Signals that are requested for the LSP, i.e., that form the Final Signal. A Composed Signal is the resulting signal from the application of the NMC and NVC fields to an elementary Signal Type. GMPLS signaling currently implies that all the Composed Signals must be part of the same LSP.
乘法器字段（16位）指示为LSP请求的相同基本信号或合成信号的数量，即形成最终信号的数量。合成信号是将NMC和NVC字段应用于基本信号类型的结果信号。GMPLS信令目前意味着所有合成信号必须是同一LSP的一部分。
This field is set to one (default value) to indicate that exactly one instance of a signal is being requested. Intermediate and egress nodes MUST verify that the node itself and the interfaces on which the LSP will be established can support the requested multiplier value. If the requested values cannot be supported, the receiver node MUST generate a PathErr message (see Section 6).
此字段设置为一（默认值），以指示正请求一个信号的一个实例。中间和出口节点必须验证节点本身和将在其上建立LSP的接口是否能够支持请求的乘数值。如果请求的值不受支持，则接收方节点必须生成PathErr消息（请参阅第6节）。
Zero is an invalid value for the MT field. If received, the node MUST generate a PathErr message (see Section 6).
零是MT字段的无效值。如果收到，节点必须生成PathErr消息（请参阅第6节）。
The reserved fields (8 bits in row 1 and 32 bits in row 3) are dedicated for future use. Reserved bits SHOULD be set to zero when sent and MUST be ignored when received.
保留字段（第1行中的8位和第3行中的32位）专用于将来使用。保留位在发送时应设置为零，在接收时必须忽略。
This section describes the Generalized Label value space for Digital Paths and Optical Channels. The Generalized Label is defined in
本节介绍数字路径和光信道的通用标签值空间。通用标签在中定义
[RFC3471]. The format of the corresponding RSVP-TE GENERALIZED_LABEL object is specified in [RFC3473] Section 2.3.
[RFC3471]。[RFC3473]第2.3节规定了相应RSVP-TE广义_标签对象的格式。
The label distribution rules detailed in Section 4.2 follow (when applicable) the ones defined in [RFC3946].
第4.2节详述的标签分配规则遵循[RFC3946]中定义的规则（如适用）。
At the Digital Path layer (i.e., ODUk layers), G.709 defines three different client payload bit rates. An Optical Data Unit (ODU) frame has been defined for each of these bit rates. ODUk refers to the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps), or 3 (for 40 Gbps).
在数字路径层（即ODUk层），G.709定义了三种不同的客户端有效负载比特率。已经为这些比特率中的每一个定义了光数据单元（ODU）帧。ODUk指比特率为k的帧，其中k=1（对于2.5 Gbps）、2（对于10 Gbps）或3（对于40 Gbps）。
In addition to the support of ODUk mapping into OTUk, the G.709 label space supports the sub-levels of ODUk multiplexing. ODUk multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk (k > j), in particular:
除了支持ODUk映射到OTUk之外，G.709标签空间还支持ODUk复用的子级别。ODUk多路复用是指将ODUj（j=1，2）多路复用到ODUk（k>j）中，具体而言：
- ODU1 into ODU2 multiplexing - ODU1 into ODU3 multiplexing - ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing
- ODU1到ODU2多路复用-ODU1到ODU3多路复用-ODU2到ODU3多路复用-ODU1和ODU2到ODU3多路复用
More precisely, ODUj into ODUk multiplexing (k > j) is defined when an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e., an ODTUG constituted by ODU tributary slots) that is mapped into an OPUk. The resulting OPUk is mapped into an ODUk, and the ODUk is mapped into an OTUk.
更准确地说，当ODUj被复用到映射到OPUk的ODUk分支单元组（即，由ODU分支时隙构成的ODTUG）中时，定义ODUj到ODUk复用（k>j）。生成的OPUk映射到ODUk，ODUk映射到OTUk。
Therefore, the label space structure is a tree whose root is an OTUk signal and whose leaves are the ODUj signals (k >= j) that can be transported via the tributary slots and switched between these slots. A G.709 Digital Path layer label identifies the exact position of a particular ODUj signal in an ODUk multiplexing structure.
因此，标签空间结构是一棵树，其根是OTUk信号，其叶是ODUj信号（k>=j），可以通过分支时隙传输并在这些时隙之间切换。G.709数字路径层标签标识特定ODUj信号在ODUk复用结构中的确切位置。
The G.709 Digital Path Layer label or ODUk label has the following format:
G.709数字路径层标签或ODUk标签的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | t3 | t2 |t1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | t3 | t2 |t1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits MUST be set to zero when sent and SHOULD be ignored when received.
发送时保留位必须设置为零，接收时应忽略保留位。
The specification of the fields t1, t2, and t3 self-consistently characterizes the ODUk label space. The value space for the t1, t2, and t3 fields is defined as follows:
字段t1、t2和t3的规范自洽地描述了ODUk标签空间。t1、t2和t3字段的值空间定义如下：
1. t1 (1-bit): - t1=1 indicates an ODU1 signal. - t1 is not significant for the other ODUk signal types (i.e., t1 value MUST be set to 0 and ignored).
1. t1（1位）：-t1=1表示ODU1信号。-t1对于其他ODUk信号类型不重要（即，t1值必须设置为0并忽略）。
2. t2 (3-bit): - t2=1 indicates an ODU2 signal that is not further sub-divided. - t2=[2..5] indicates the tributary slot (t2th-2) used by the ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). - t2 is not significant for an ODU3 (i.e., t2 value MUST be set to 0 and ignored).
2. t2（3位）：-t2=1表示未进一步细分的ODU2信号t2=[2..5]表示ODTUG2中的ODU1使用的分支插槽（t2th-2），该插槽映射到ODU2（通过OPU2）。-t2对于ODU3不重要（即t2值必须设置为0并忽略）。
3. t3 (6-bit): - t3=1 indicates an ODU3 signal that is not further sub-divided. - t3=[2..17] indicates the tributary slot (t3th-1) used by the ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). - t3=[18..33] indicates the tributary slot (t3th-17) used by the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3).
3. t3（6位）：-t3=1表示未进一步细分的ODU3信号。-t3=[2..17]表示ODTUG3中的ODU1使用的分支插槽（t3th-1）映射到ODU3（通过OPU3）。-t3=[18..33]表示映射到ODU3（通过OPU3）的ODTUG3中的ODU2使用的分支插槽（t3th-17）。
Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required to identify the 4 tributary slots used by the ODU2; these tributary time slots have to be allocated in ascending order.
注：在ODU2到ODU3复用的情况下，需要4个标签来标识ODU2使用的4个分支插槽；这些支路时隙必须按升序分配。
If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j > i), the corresponding ODUk signal ODU[i] is directly mapped into the corresponding OTUk signal (k=i). This is referred to as the mapping of an ODUk signal into an OTUk of the same order. Therefore, the numbering starts at 1; zero is used to indicate a non-significant field. A label field equal to zero is an invalid value.
如果标签子字段值t[i]=1（i，j=1、2或3）和t[j]=0（j>i），则对应的ODUk信号ODU[i]直接映射到对应的OTUk信号（k=i）。这被称为将ODUk信号映射到相同顺序的OTUk。因此，编号从1开始；零用于表示非有效字段。等于零的标签字段是无效值。
Examples:
示例：
- t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1 - t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 - t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3 - t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 - t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3
- t3=0，t2=0，t1=1表示映射到OTU1的ODU1-t3=0，t2=1，t1=0表示映射到OTU2的ODU2-t3=1，t2=0，t1=0表示映射到OTU3的ODU3-t3=0，t2=3，t1=0表示映射到OTU2的ODU2（通过OPU2）的第二个分支槽中的ODU1，映射到OTU2-t3=5，t2=0，t1=0表示映射到OTU3的ODTUG3的第四个分支插槽中的ODU1（通过OPU3）映射到OTU3
In case of ODUk in OTUk mapping, only one label can appear in the Generalized Label. The unique label is encoded as a single 32-bit label value (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2).
对于OTUk映射中的ODUk，通用标签中只能出现一个标签。唯一标签编码为通用_标签对象（类别Num=16，C类型=2）的单个32位标签值（如第4.1节中所定义）。
In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered list of the labels in the multiplex is given (this list can be restricted to only one label when NMC = 1). Each label indicates a component (ODUj tributary slot) of the multiplexed signal. The order of the labels must reflect the order of the ODUj into the multiplex (not the physical order of tributary slots). This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2).
在ODUk（k>j）多路复用中的ODUj的情况下，给出了多路复用中标签的显式有序列表（当NMC=1时，该列表只能限制为一个标签）。每个标签表示多路复用信号的一个分量（ODUj支路插槽）。标签的顺序必须反映多路复用中ODUj的顺序（而不是支路插槽的物理顺序）。该有序标签列表编码为广义_标签对象（类别Num=16，C-Type=2）的32位标签值序列（定义见第4.1节）。
In case of ODUk virtual concatenation, the explicit ordered list of all labels in the concatenation is given. Each label indicates a component of the virtually concatenated signal. The order of the labels must reflect the order of the ODUk to concatenate (not the physical order of time-slots). This representation limits virtual concatenation to remain within a single (component) link. In case of multiplexed virtually concatenated signals, the first set of labels indicates the components (ODUj tributary slots) of the first virtually concatenated signal, the second set of labels indicates the components (ODUj tributary slots) of the second virtually concatenated signal, and so on. This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of ODUk virtual concatenation, the number of label values is determined by the NVC value. Multiplexed ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size).
在ODUk虚拟连接的情况下，给出了连接中所有标签的显式有序列表。每个标签表示虚拟连接信号的一个分量。标签的顺序必须反映ODUk连接的顺序（而不是时隙的物理顺序）。此表示法将虚拟连接限制为保留在单个（组件）链接中。在多路复用虚拟级联信号的情况下，第一组标签指示第一虚拟级联信号的分量（ODUj分支时隙），第二组标签指示第二虚拟级联信号的分量（ODUj分支时隙），依此类推。该有序标签列表编码为广义_标签对象（类别Num=16，C-Type=2）的32位标签值序列（定义见第4.1节）。在ODUk虚拟连接的情况下，标签值的数量由NVC值确定。多路复用ODUk虚拟连接还使用NMC值来确定每组标签的数量（大小相等）。
In case of multiplication (i.e., when using the MT field), the explicit ordered list of all labels taking part in the composed signal is given. The above representation limits multiplication to remain within a single (component) link. In case of multiplication of multiplexed virtually concatenated signals, the first set of labels indicates the components of the first multiplexed virtually concatenated signal, the second set of labels indicates components of the second multiplexed virtually concatenated signal, and so on. This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of multiplication of (equal) ODUk virtual concatenated signals, the number of label values per signal is determined by the NVC value. Multiplication of multiplexed
在乘法的情况下（即，当使用MT字段时），给出参与合成信号的所有标签的显式有序列表。上述表示法将乘法限制在单个（组件）链接内。在复用虚拟级联信号的乘法的情况下，第一组标签指示第一复用虚拟级联信号的分量，第二组标签指示第二复用虚拟级联信号的分量，依此类推。该有序标签列表编码为广义_标签对象（类别Num=16，C-Type=2）的32位标签值序列（定义见第4.1节）。在（相等）ODUk虚拟级联信号相乘的情况下，每个信号的标签值数量由NVC值确定。多路复用的乘法
(equal) ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size).
（相等）ODUk虚拟连接还使用NMC值来确定每组标签的数量（大小相等）。
At the Optical Channel layer, the label space must be consistently defined as a flat space whose values reflect the local assignment of OCh identifiers that correspond to the OTM-n.m sub-interface signals (m = 1, 2 or 3). Note that these identifiers do not cover OChr because the corresponding Connection Function (OChr-CF) between OTM-nr.m/OTM-0r.m is not defined in [ITUT-G798].
在光信道层，标签空间必须一致地定义为平坦空间，其值反映对应于OTM-n.m子接口信号（m＝1、2或3）的OCh标识符的本地分配。请注意，这些标识符不包括OChr，因为[ITUT-G798]中未定义OTM-nr.m/OTM-0r.m之间的相应连接功能（OChr CF）。
The OCh label space values are defined by either absolute values (i.e., channel identifiers or Channel ID, also referred to as wavelength identifiers) or relative values (channel spacing, also referred to as inter-wavelength spacing). The latter is strictly confined to a per-port label space, whereas the former could be defined as a local or a global (per node) label space. Such an OCh label space is applicable to both OTN Optical Channel layer and pre-OTN Optical Channel layer.
OCh标签空间值由绝对值（即信道标识符或信道ID，也称为波长标识符）或相对值（信道间隔，也称为波长间间隔）定义。后者严格限定于每端口标签空间，而前者可以定义为局部或全局（每节点）标签空间。这种OCh标签空间适用于OTN光信道层和前OTN光信道层。
Optical Channel label encoding (and distribution) rules are defined in [RFC3471]. They MUST be used for the Upstream Label, the Suggested Label, and the Generalized Label.
[RFC3471]中定义了光信道标签编码（和分配）规则。它们必须用于上游标签、建议标签和通用标签。
The following examples are given in order to illustrate the processing described in the previous sections of this document.
为了说明本文件前面章节中描述的处理过程，给出了以下示例。
1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is directly transported in an OTU1 (OTU2 or OTU3), the upstream node requests results simply in an ODU1 (ODU2 or ODU3) signal request.
1. OTUk映射中的ODUk：当一个ODU1（ODU2或ODU3）信号直接在OTU1（OTU2或OTU3）中传输时，上游节点请求只会导致ODU1（ODU2或ODU3）信号请求。
In such conditions, the downstream node has to return a unique label because the ODU1 (ODU2 or ODU3) is directly mapped into the corresponding OTU1 (OTU2 or OTU3). Because a single ODUk signal is requested (Signal Type = 1, 2 or 3), the downstream node has to return a single ODUk label, which can be, for instance, one of the following when the Signal Type = 1:
在这种情况下，下游节点必须返回唯一的标签，因为ODU1（ODU2或ODU3）直接映射到相应的OTU1（OTU2或OTU3）。由于请求单个ODUk信号（信号类型=1、2或3），下游节点必须返回单个ODUk标签，例如，当信号类型=1时，该标签可以是以下之一：
- t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 - t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2 - t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3
- t3=0，t2=0，t1=1表示映射到OTU1的单个ODU1-t3=0，t2=1，t1=0表示映射到OTU2的单个ODU2-t3=1，t2=0，t1=0表示映射到OTU3的单个ODU3
2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed into the payload of a structured ODU2 (or ODU3), the upstream node requests results simply in an ODU1 signal request.
2. ODU1到ODUk多路复用（k>1）：当一个ODU1被多路复用到结构化ODU2（或ODU3）的有效负载中时，上游节点请求仅导致ODU1信号请求。
In such conditions, the downstream node has to return a unique label because the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or OPU3) and then mapped into the corresponding OTU2 (or OTU3). Because a single ODU1 multiplexed signal is requested (Signal Type = 1 and NMC = 1), the downstream node has to return a single ODU1 label, which can take, for instance, one of the following values:
在这种情况下，下游节点必须返回唯一的标签，因为ODU1被多路复用到一个ODTUG2（或ODTUG3）中。然后，后者通过OPU2（或OPU3）映射到ODU2（或ODU3），然后映射到相应的OTU2（或OTU3）。由于请求单个ODU1多路复用信号（信号类型=1和NMC=1），下游节点必须返回单个ODU1标签，该标签可以采用以下值之一：
- t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2 - t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3 - t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3
- t3=0，t2=4，t1=0表示ODTUG2的第三个TS中的ODU1-t3=2，t2=0，t1=0表示ODTUG3的第一个TS中的ODU1-t3=7，t2=0，t1=0表示ODTUG3的第六个TS中的ODU1
3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is multiplexed into the payload of a structured ODU3, the upstream node requests results simply in an ODU2 signal request.
3. ODU2到ODU3多路复用：当一个非结构化ODU2多路复用到结构化ODU3的有效负载中时，上游节点请求只会导致ODU2信号请求。
In such conditions, the downstream node has to return four labels since the ODU2 is multiplexed into one ODTUG3. The latter is mapped into an ODU3 (via OPU3) and then mapped into an OTU3. Since an ODU2 multiplexed signal is requested (Signal Type = 2, and NMC = 4), the downstream node has to return four ODU labels which can take for instance the following values:
在这种情况下，下游节点必须返回四个标签，因为ODU2被多路复用到一个ODTUG3中。后者被映射到ODU3（通过OPU3），然后映射到OTU3。由于请求了ODU2多路复用信号（信号类型=2，NMC=4），因此下游节点必须返回四个ODU标签，这些标签可以取以下值：
- t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3) - t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3) - t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3) - t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3)
- t3=18，t2=0，t1=0（ODTUG3第一个TS中ODU2的第一部分）-t3=22，t2=0，t1=0（ODTUG3第五个TS中ODU2的第二部分）-t3=23，t2=0，t1=0（ODTUG3第六个TS中ODU2的第三部分）-t3=26，t2=0，t1=0（ODTUG3第九个TS中ODU2的第四部分）
4. When a single OCh signal of 40 Gbps is requested (Signal Type = 8), the downstream node must return a single wavelength label as specified in [RFC3471].
4. 当请求40 Gbps的单个OCh信号时（信号类型=8），下游节点必须返回[RFC3471]中规定的单个波长标签。
5. When requesting multiple ODUk LSP (i.e., with a multiplier (MT) value > 1), an explicit list of labels is returned to the requestor node.
5. 当请求多个ODUk LSP（即，乘数（MT）值大于1）时，标签的显式列表将返回给请求者节点。
When the downstream node receives a request for a 4 x ODU1 signal (Signal Type = 1, NMC = 1 and MT = 4) multiplexed into an ODU3, it returns an ordered list of four labels to the upstream node: the first ODU1 label corresponds to the first signal of the LSP, the second ODU1 label corresponds to the second signal of the LSP, etc. For instance, the corresponding labels can take the following values:
当下游节点接收到对复用到ODU3中的4 x ODU1信号（信号类型=1、NMC=1和MT=4）的请求时，它向上游节点返回四个标签的有序列表：第一个ODU1标签对应于LSP的第一个信号，第二个ODU1标签对应于LSP的第二个信号，等等，相应的标签可以采用以下值：
- First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3) - Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3) - Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3) - Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3)
- 第一个ODU1:t3=2，t2=0，t1=0（在ODTUG3的第一个TS中）-第二个ODU1:t3=10，t2=0，t1=0（在ODTUG3的第九个TS中）-第三个ODU1:t3=7，t2=0，t1=0（在ODTUG3的第六个TS中）-第四个ODU1:t3=6，t2=0，t1=0（在ODTUG3的第五个TS中）
This section specifies the [RFC3473] protocol extensions needed to accommodate G.709 traffic parameters.
本节规定了适应G.709流量参数所需的[RFC3473]协议扩展。
The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC and FLOWSPEC objects. The same format is used both for SENDER_TSPEC object and FLOWSPEC objects. The content of the objects is defined above in Section 3.2. The objects have the following class and type for G.709:
G.709流量参数包含在G.709 SENDER_TSPEC和FLOWSPEC对象中。SENDER_TSPEC对象和FLOWSPEC对象使用相同的格式。上述第3.2节定义了对象的内容。对于G.709，对象具有以下类别和类型：
- G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5 - G.709 FLOWSPEC Object: Class = 9, C-Type = 5
- G.709发送方规格对象：类别=12，C型=5-G.709流程规格对象：类别=9，C型=5
There is no Adspec associated with the G.709 SENDER_TSPEC. Either the Adspec is omitted or an Int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment is used, see [RFC2210].
没有与G.709发送方相关联的Adspec。要么省略Adspec，要么使用具有默认通用特征参数和保证服务片段的Int-serv Adspec，请参见[RFC2210]。
For a particular sender in a session, the contents of the FLOWSPEC object received in a Resv message SHOULD be identical to the contents of the 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 SHOULD be generated.
对于会话中的特定发送方，在Resv消息中接收的FLOWSPEC对象的内容应与在相应Path消息中接收的发送方_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, NMC, and NVC values (as defined in Section 3.2). 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的接口是否能够支持请求的信号类型、NMC和NVC值（如第3.2节所定义）。如果请求的值不受支持，则接收方节点必须生成带有“流量控制错误/服务不受支持”指示的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]）。
This document introduces no new security considerations to [RFC3473].
本文档未向[RFC3473]引入新的安全注意事项。
Two values have been defined by IANA for this document:
IANA为本文件定义了两个值：
Two RSVP C-Types in registry:
注册表中的两个RSVP C类型：
http://www.iana.org/assignments/rsvp-parameters
http://www.iana.org/assignments/rsvp-parameters
- A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 - see Section 6.
- G.709发送方对象：类别=12，C类型=5-见第6节。
- A G.709 FLOWSPEC object: Class = 9, C-Type = 5 - see Section 6.
- A G.709 FLOWSPEC对象：类别=9，C型=5-见第6节。
IANA will also track the code-point spaces extended and/or updated by
this document. For this purpose, the following new registry entries
have been added in the newly requested registry entry:
http://www.iana.org/assignments/gmpls-sig-parameters
IANA will also track the code-point spaces extended and/or updated by
this document. For this purpose, the following new registry entries
have been added in the newly requested registry entry:
http://www.iana.org/assignments/gmpls-sig-parameters
- LSP Encoding Type: Name: LSP Encoding Type Format: 8-bit number Values: [1..11] defined in [RFC3471] 12 defined in Section 3.1.1 13 defined in Section 3.1.1 Allocation Policy: [0..239] Assigned by IANA via IETF Standards Track RFC Action. [240..255] Assigned temporarily for Experimental Usage. These will not be registered with IANA
- LSP编码类型：名称：LSP编码类型格式：在[RFC3471]中定义的8位数字值：[1..11]在第3.1.1节中定义的12在第3.1.1节中定义的13分配策略中定义的[0..239]由IANA通过IETF标准分配跟踪RFC动作。[240..255]临时分配用于实验用途。这些将不会在IANA注册
- Switching Type: Name: Switching Type Format: 8-bit number Values: defined in [RFC3471] Allocation Policy: [0..255] Assigned by IANA via IETF Standards Track RFC Action.
- 切换类型：名称：切换类型格式：8位数字值：在IANA通过IETF标准分配的[RFC3471]分配策略[0..255]中定义，跟踪RFC动作。
- Generalized PID (G-PID): Name: G-PID Format: 16-bit number Values: [0..31] defined in [RFC3471] [32..35] defined in [RFC3471] and updated by Section 3.1.3 [36..46] defined in [RFC3471] [47..58] defined in Section 3.1.3 Allocation Policy: [0..31743] Assigned by IANA via IETF Standards Track RFC Action. [31744..32767] Assigned temporarily for Experimental Usage
- 通用PID（G-PID）：名称：G-PID格式：IANA通过IETF标准分配的16位数字值：[0..31]在[RFC3471][32..35]中定义，并由第3.1.3节[RFC3471][47..58]中定义的第3.1.3[36..46]节更新，第3.1.3节中定义的分配策略：[0..31743]中定义。[31744..32767]临时分配用于实验用途
[32768..65535] Not assigned. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.
[32768..65535]未分配。在此范围内进行任何分配之前，必须有一个标准跟踪RFC，指定涵盖所分配范围的IANA注意事项。
Note: per [RFC3471], Section 3.1.1, standard Ethertype values are used as G-PIDs for packet and Ethernet LSPs.
注：根据[RFC3471]第3.1.1节，标准Ethertype值用作分组和以太网LSP的G-PID。
The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, Massimo Canali, Germano Gasparini, and Fong Liaw for their constructive comments and inputs as well as James Fu, Siva Sankaranarayanan, and Yangguang Xu for their useful feedback. Many thanks to Adrian Farrel for having thoroughly reviewed this document.
作者要感谢Jean Loup Ferrant、Mathieu Garnot、Massimo Canali、Germano Gasparini和Fong Liaw的建设性意见和投入，以及James Fu、Siva Sankaranarayanan和杨光Xu的有用反馈。非常感谢Adrian Farrel对本文件进行了全面审查。
This document incorporates (upon agreement) material and ideas from a work in progress, "Common Label and Label Request Specification for Automatic Switched Transport Network", by Zhi Lin.
本文件包含（经同意）正在进行的工作中的材料和想法，“自动交换传输网络的通用标签和标签请求规范”，由志林撰写。
[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., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3946] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004.
[RFC3946]Mannie，E.和D.Papadimitriou，“同步光网络（SONET）和同步数字体系（SDH）控制的通用多协议标签交换（GMPLS）扩展”，RFC 3946，2004年10月。
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, September 2005.
[RFC4202]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年9月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
For information on the availability of the following documents, please see http://www.itu.int
有关下列文件的可用性信息，请参见http://www.itu.int
[ITUT-G709] ITU-T, "Interface for the Optical Transport Network (OTN)," G.709 Recommendation (and Amendment 1), February 2001 (October 2001).
[ITUT-G709]ITU-T，“光传输网络（OTN）接口”，G.709建议（和修正案1），2001年2月（2001年10月）。
[ITUT-G798] ITU-T, "Characteristics of Optical Transport Network Hierarchy Equipment Functional Blocks," G.798 Recommendation, October 2001.
[ITUT-G798]ITU-T，“光传输网络层次结构设备功能块的特征”，G.798建议，2001年10月。
Alberto Bellato (Alcatel) Via Trento 30, I-20059 Vimercate, Italy EMail: alberto.bellato@alcatel.it
阿尔贝托·贝拉托（阿尔卡特）通过意大利维梅卡特州特伦托30号I-20059电子邮件：阿尔贝托。bellato@alcatel.it
Sudheer Dharanikota (Consult) EMail: sudheer@ieee.org
Sudheer Dharanikota（咨询）电子邮件：sudheer@ieee.org
Michele Fontana (Alcatel) Via Trento 30, I-20059 Vimercate, Italy EMail: michele.fontana@alcatel.it
Michele Fontana（阿尔卡特）通过意大利维梅卡特市特伦托30号I-20059电子邮件：Michele。fontana@alcatel.it
Nasir Ghani (Sorrento Networks) 9990 Mesa Rim Road, San Diego, CA 92121, USA EMail: nghani@sorrentonet.com
Nasir Ghani（Sorrento Networks）美国加利福尼亚州圣地亚哥梅萨林路9990号，邮编92121电子邮件：nghani@sorrentonet.com
Gert Grammel (Alcatel) Lorenzstrasse, 10, 70435 Stuttgart, Germany EMail: gert.grammel@alcatel.de
Gert Grammel（阿尔卡特）Lorenzstrasse，1070435斯图加特，德国电子邮件：Gert。grammel@alcatel.de
Dan Guo (Turin Networks) 1415 N. McDowell Blvd, Petaluma, CA 94954, USA EMail: dguo@turinnetworks.com
Dan Guo（都灵网络）美国加利福尼亚州佩塔卢马市麦克道尔大道北1415号，邮编94954电子邮件：dguo@turinnetworks.com
Juergen Heiles (Siemens) Hofmannstr. 51, D-81379 Munich, Germany EMail: juergen.heiles@siemens.com
Juergen Heiles（西门子）Hofmannstr。51，D-81379，德国慕尼黑电子邮件：juergen。heiles@siemens.com
Jim Jones (Alcatel) 3400 W. Plano Parkway, Plano, TX 75075, USA EMail: jim.d.jones@alcatel.com
吉姆·琼斯（阿尔卡特）美国德克萨斯州普莱诺市普莱诺大道西3400号，邮编75075电子邮件：Jim.d。jones@alcatel.com
Zhi-Wei Lin (Lucent) 101 Crawfords Corner Rd, Rm 3C-512 Holmdel, New Jersey 07733-3030, USA EMail: zwlin@lucent.com
林志伟（朗讯）美国新泽西州霍姆德尔市克劳福德角路101号3C-512室07733-3030电子邮件：zwlin@lucent.com
Eric Mannie (Consult) EMail: eric_mannie@hotmail.com
Eric Mannie（咨询）电子邮件：Eric_mannie@hotmail.com
Maarten Vissers (Alcatel) Lorenzstrasse, 10, 70435 Stuttgart, Germany EMail: maarten.vissers@alcalel.de
Maarten Vissers（阿尔卡特）Lorenzstrasse，1070435斯图加特，德国电子邮件：Maarten。vissers@alcalel.de
Yong Xue (WorldCom) 22001 Loudoun County Parkway, Ashburn, VA 20147, USA EMail: yong.xue@wcom.com
永雪（世通）美国弗吉尼亚州阿什本市娄敦县公园路22001号，邮编：20147，电子邮件：Yong。xue@wcom.com
BSNT Bit Stream without Octet Timing BSOT Bit Stream with Octet Timing CBR Constant Bit Rate ESCON Enterprise Systems Connection FC Fiber Channel FEC Forward Error Correction FICON Fiber Connection FSC Fiber Switch Capable GCC General Communication Channel GFP Generic Framing Procedure LSC Lambda Switch Capable LSP Label Switched Path MS Multiplex Section naOH non-associated Overhead NMC Number of Multiplexed Components NVC Number of Virtual Components OCC Optical Channel Carrier OCG Optical Carrier Group OCh Optical Channel (with full functionality) OChr Optical Channel (with reduced functionality) ODTUG Optical Date Tributary Unit Group ODU Optical Channel Data Unit OH Overhead OMS Optical Multiplex Section OMU Optical Multiplex Unit OOS OTM Overhead Signal OPS Optical Physical Section OPU Optical Channel Payload Unit OSC Optical Supervisory Channel OTH Optical Transport Hierarchy OTM Optical Transport Module OTN Optical Transport Network OTS Optical Transmission Section OTU Optical Channel Transport Unit OTUkV Functionally Standardized OTUk PPP Point to Point Protocol PSC Packet Switch Capable RES Reserved RS Regenerator Section TTI Trail Trace Identifier TDM Time Division Multiplex
不带八位定时的BSNT比特流带八位定时的BSOT比特流CBR恒定比特率ESCON企业系统连接FC光纤通道FEC前向纠错FICON光纤连接FSC光纤交换机支持GCC通用通信通道GFP通用成帧过程LSC Lambda交换机支持LSP标签交换路径MS多路复用分段naOH非相关开销NMC复用组件数NVC虚拟组件数OCC光信道载波OCG光载波组OCh光信道（具有完整功能）OChr光信道（具有缩减功能）ODTUG光数据支路单元组ODU光信道数据单元OH开销OMS光复用段OMU光复用单元OOS OTM开销信号OPS光物理段OPU光信道有效载荷单元OSC光监控信道OTH光传输层次OTM光传输模块OTN光传输网络OTS光传输部分OTU光信道传输单元OTUkV功能标准化OTUk PPP点对点协议PSC分组交换机支持RES保留RS再生器部分TTI跟踪标识符TDM时分复用
- Index k: The index "k" is used to represent a supported bit rate and the different versions of OPUk, ODUk and OTUk. k=1 represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s and k = 4 an approximate bit rate of 160 Gbit/s (under definition). The exact bit-rate values are in kbits/s:
- 索引k：索引“k”用于表示支持的比特率以及OPUk、ODUk和OTUk的不同版本。k=1表示2.5 Gbit/s的近似比特率，k=2表示10 Gbit/s的近似比特率，k=3表示40 Gbit/s的近似比特率，k=4表示160 Gbit/s的近似比特率（根据定义）。准确的比特率值以kbits/s为单位：
. OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322
. OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322
. ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983
. ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983
. OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559
. OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559
- Index m: The index "m" is used to represent the bit rate or set of bit rates supported on the interface. This is a one or more digit "k", where each "k" represents a particular bit rate. The valid values for m are (1, 2, 3, 12, 23, 123).
- 索引m：索引“m”用于表示接口上支持的比特率或比特率集。这是一个或多个数字“k”，其中每个“k”表示特定的比特率。m的有效值为（1、2、3、12、23、123）。
- Index n: The index "n" is used to represent the order of the OTM, OTS, OMS, OPS, OCG and OMU. This index represents the maximum number of wavelengths that can be supported at the lowest bit rate supported on the wavelength. It is possible that a reduced number of higher bit rate wavelengths are supported. The case n=0 represents a single channel without a specific wavelength assigned to the channel.
- 索引n：索引“n”用于表示OTM、OTS、OMS、OPS、OCG和OMU的顺序。此索引表示在波长上支持的最低比特率下可以支持的最大波长数。可能支持更少的更高比特率波长。情况n＝0表示没有指定给信道的特定波长的单个信道。
- Index r: The index "r", if present, is used to indicate a reduced functionality OTM, OCG, OCC and OCh (non-associated overhead is not supported). Note that for n=0 the index r is not required as it implies always reduced functionality.
- 索引r：索引“r”（如果存在）用于表示OTM、OCG、OCC和OCh功能降低（不支持非相关开销）。注意，对于n=0，不需要索引r，因为它意味着功能总是减少的。
Editor's Address
编辑地址
Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium
Dimitri Papadimitriou（阿尔卡特）Francis Wellesplein 1，B-2018比利时安特卫普
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。