Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6002 LabN
Updates: 3471, 3473, 3945, 4202, 4203, 5307 D. Fedyk
Category: Standards Track Alcatel-Lucent
ISSN: 2070-1721 October 2010
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6002 LabN
Updates: 3471, 3473, 3945, 4202, 4203, 5307 D. Fedyk
Category: Standards Track Alcatel-Lucent
ISSN: 2070-1721 October 2010
Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions
通用MPLS（GMPLS）数据信道交换功能（DCSC）和信道集标签扩展
Abstract
摘要
This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP).
本文档描述了通用多协议标签交换（GMPLS）的两个独立于技术的扩展。第一个扩展定义了新的交换类型数据通道交换能力。支持数据通道切换的接口能够支持单通道接口上显示的整个数字通道的切换。第二个扩展定义了一种新类型的通用标签并更新相关对象。新标签称为广义通道集标签，允许作为标签交换路径（LSP）的一部分控制多个数据平面标签。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6002.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6002.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Data Channel Switching ..........................................3
2.1. Compatibility ..............................................4
3. Generalized Channel_Set Label Related Formats ...................4
3.1. Generalized Channel_Set LABEL_REQUEST Object ...............4
3.2. Generalized Channel_Set LABEL Object .......................4
3.3. Other Label-Related Objects ................................7
3.4. Compatibility ..............................................7
4. IANA Considerations .............................................8
4.1. Data Channel Switching Type ................................8
4.2. Generalized Channel_Set LABEL_REQUEST Object ...............8
4.3. Generalized Channel_Set LABEL Object .......................8
5. Security Considerations .........................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References ....................................10
Acknowledgments ...................................................10
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Data Channel Switching ..........................................3
2.1. Compatibility ..............................................4
3. Generalized Channel_Set Label Related Formats ...................4
3.1. Generalized Channel_Set LABEL_REQUEST Object ...............4
3.2. Generalized Channel_Set LABEL Object .......................4
3.3. Other Label-Related Objects ................................7
3.4. Compatibility ..............................................7
4. IANA Considerations .............................................8
4.1. Data Channel Switching Type ................................8
4.2. Generalized Channel_Set LABEL_REQUEST Object ...............8
4.3. Generalized Channel_Set LABEL Object .......................8
5. Security Considerations .........................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References ....................................10
Acknowledgments ...................................................10
This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). Both of these extensions were initially defined in the context of Ethernet services, see [RFC6004] and [RFC6005], but are generic in nature and may be useful to any switching technology controlled via GMPLS.
本文档描述了通用多协议标签交换（GMPLS）的两个独立于技术的扩展。这两个扩展最初都是在以太网服务的上下文中定义的，参见[RFC6004]和[RFC6005]，但本质上是通用的，可能对通过GMPLS控制的任何交换技术都有用。
The first extension defines a new switching type, which is called Data Channel Switching Capable (DCSC). DCSC interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of
第一个扩展定义了一种新的交换类型，称为数据通道交换能力（DCSC）。DCSC接口能够支持单通道接口上显示的整个数字通道的切换。第二个扩展定义了一种新的
generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a GMPLS Label Switched Path (LSP).
通用标签和更新相关对象。新标签被称为广义通道集标签，允许作为GMPLS标签交换路径（LSP）的一部分控制多个数据平面标签。
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]中所述进行解释。
Current GMPLS switching types are defined in [RFC3945] and [RFC3471] and support switching at the packet (PSC), frame (L2SC), time-slot (TDM), frequency (LSC), and fiber (FSC) granularities. Parallel definitions for these switching types are also made in [RFC4202], [RFC4203], and [RFC5307].
当前的GMPLS交换类型在[RFC3945]和[RFC3471]中定义，并支持分组（PSC）、帧（L2SC）、时隙（TDM）、频率（LSC）和光纤（FSC）粒度上的交换。[RFC4202]、[RFC4203]和[RFC5307]中也对这些开关类型进行了并行定义。
One type of switching that is not well represented in this current set is switching that occurs when all data received on an ingress port is switched through a network to an egress port. While there are similarities between this level of switching and the "opaque single wavelength" case, described in Section 3.5 of [RFC4202], such port-to-port switching is not limited to the optical switching technology implied by the LSC type. FSC is also similar, but it is restricted to fiber ports and also supports multiple data channels within a fiber port.
当前集合中没有很好地表示的一种交换类型是当在入口端口上接收的所有数据通过网络交换到出口端口时发生的交换。虽然这种级别的交换与[RFC4202]第3.5节中描述的“不透明单波长”情况有相似之处，但这种端口到端口交换并不限于LSC类型所暗示的光交换技术。FSC也类似，但它仅限于光纤端口，还支持光纤端口内的多个数据通道。
This document defines a new switching type called Data Channel Switching Capable (DCSC). Port switching seems a more intuitive name, but this naming collides with PSC so is not used. DCSC interfaces are able to support switching of the whole digital channel presented on single channel interfaces. Interfaces that inherently support multiple channels, e.g., Wavelength Division Multiplexing (WDM) and channelized TDM interfaces, are specifically excluded from this type. Any interface that can be represented as a single digital channel are included. Examples include concatenated TDM and line-encoded interfaces. Framed interfaces may also be included when they support switching on an interface granularity, for example Ethernet terminated at the physical (port) level and all traffic received on a port is switched to a physical port at the LSP egress.
本文档定义了一种新的交换类型，称为数据通道交换能力（DCSC）。端口交换似乎是一个更直观的名称，但此命名与PSC冲突，因此不使用。DCSC接口能够支持单通道接口上显示的整个数字通道的切换。本质上支持多个信道的接口，例如波分复用（WDM）和信道化TDM接口，被明确排除在此类接口之外。包括可表示为单个数字通道的任何接口。示例包括串联TDM和线路编码接口。当帧接口支持在接口粒度上切换时，也可以包括帧接口，例如在物理（端口）级别终止的以太网，并且在端口上接收的所有通信量都切换到LSP出口处的物理端口。
DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the value 125. The DCSC value is carried in routing protocols in the Interface Switching Capability Descriptor defined in [RFC4202], and used in OSPF [RFC4203] and IS-IS [RFC5307]. These documents are not otherwise modified by this document.
DCSC用GMPLS表示，请参见[RFC3471]和[RFC4202]，使用值125。DCSC值在[RFC4202]中定义的接口交换能力描述符的路由协议中携带，并在OSPF[RFC4203]和is-is[RFC5307]中使用。本文件不会对这些文件进行其他修改。
The DCSC Switching Type may be used with the Generalized Label Request object, [RFC3473], or the Generalized Channel_Set LABEL_REQUEST object defined below. Port labels, as defined in [RFC3471], SHOULD be used for LSPs signaled using the DCSC Switching Type.
DCSC切换类型可与通用标签请求对象[RFC3473]或下面定义的通用信道集标签请求对象一起使用。[RFC3471]中定义的端口标签应用于使用DCSC交换类型发送信号的LSP。
Transit and egress nodes that do not support the DCSC Switching Type when receiving a Path message with a Label Request containing the DCSC Switching Type will behave in the same way nodes generally handle the case of an unsupported Switching Type. Specifically, per [RFC3473], such nodes are required to generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication.
当接收到带有包含DCSC交换类型的标签请求的路径消息时，不支持DCSC交换类型的传输和出口节点的行为将与节点处理不支持的交换类型的情况的方式相同。具体而言，根据[RFC3473]，此类节点需要生成带有“路由问题/不支持的编码”指示的PathErr消息。
Ingress nodes initiating a Path message containing a Label Request containing the DCSC Switching Type, receiving such a PathErr messages, then notify the requesting application user as appropriate.
入口节点启动包含包含DCSC交换类型的标签请求的路径消息，接收此类PathErr消息，然后根据需要通知请求应用程序用户。
This section defines a new type of generalized label and updates related objects. This section updates the label-related definitions of [RFC3473]. The ability to communicate more than one label as part of the same LSP was motivated by the support for the communication of one or more VLAN IDs. Simple concatenation of labels as is done in [RFC4606] was deemed impractical given the large number of VLAN IDs (up to 4096) that may need to be communicated. The formats defined in this section are not technology specific and may be useful for other switching technologies. The LABEL_SET object defined in [RFC3473] serves as the foundation for the defined formats.
本节定义一种新类型的通用标签并更新相关对象。本节更新[RFC3473]的标签相关定义。将多个标签作为同一LSP的一部分进行通信的能力是由于支持一个或多个VLAN ID的通信。考虑到可能需要通信的大量VLAN ID（多达4096个），在[RFC4606]中进行的简单标签连接被认为是不切实际的。本节中定义的格式不是特定于技术的，可能对其他交换技术有用。在[RCFC333]中定义的LabelSySt对象是定义格式的基础。
The Generalized Channel_Set LABEL_REQUEST object is used to indicate that the Generalized Channel_Set LABEL object is to be used with the associated LSP. The format of the Generalized Channel_Set LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST object and uses a C-Type of 5.
广义通道集标签请求对象用于指示广义通道集标签对象将与相关LSP一起使用。广义通道集标签请求对象的格式与广义标签请求对象的格式相同，并使用C类型5。
The Generalized Channel_Set LABEL Object communicates one or more labels, all of which can be used equivalently in the data path associated with a single LSP. The format of the Generalized Channel_Set LABEL Object is based on the LABEL_SET object defined in [RFC3473]. It differs from the LABEL_SET object in that the full set may be represented in a single object rather than the multiple
通用通道集标签对象传递一个或多个标签，所有标签都可以在与单个LSP关联的数据路径中等效使用。通用通道集标签对象的格式基于[RFC3473]中定义的标签集对象。它与LABEL_SET对象的不同之处在于，完整的集合可以在单个对象中表示，而不是在多个对象中表示
objects required by the [RFC3473] LABEL_SET object. The object MUST be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST object. The object MUST be processed per [RFC3473]. Make-before-break procedures, see [RFC3209], SHOULD be used when modifying the Channel_Set LABEL object.
[RFC3473]标签集对象所需的对象。该对象必须在使用通用通道设置标签请求对象的LSP上使用。必须按照[RFC3473]处理对象。修改通道设置标签对象时，应使用先通后断程序，请参见[RFC3209]。
The format of the Generalized Channel_Set LABEL object is:
通用通道集标签对象的格式为：
o Generalized Channel_Set LABEL object: Class = 16, C-Type = 4
o 广义通道集标签对象：Class=16，C-Type=4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Set Subobject 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Set Subobject N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Set Subobject 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Set Subobject N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Channel_Set Subobject size is measured in bytes and MUST always be a multiple of 4, and at least 4, and has the following format:
Channel_Set子对象大小以字节为单位，必须始终是4的倍数，且至少为4，并且具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Num Subchannels | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
: : :
: : :
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Num Subchannels | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
: : :
: : :
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action: 8 bits
动作：8位
See [RFC3471] for definition of actions. Range actions SHOULD be used when possible to minimize the size of the Channel_Set LABEL Object.
有关操作的定义，请参见[RFC3471]。在可能的情况下，应使用范围操作来最小化通道集标签对象的大小。
Number of Subchannels: 10 bits
子通道数：10位
Indicates the number of subchannels carried in the subobject. When the number of subchannels required exceeds the limit of the field, i.e., 1024, multiple Channel_Set Subobjects MUST be used. Note that the size of the subobject may result in a Path message being larger than a single unfragmented IP packet. See Section 4.4 of [RFC6004] for an example of how this case may be handled.
指示子对象中携带的子通道数。当所需的子通道数超过字段限制（即1024个）时，必须使用多个通道集合子对象。注意，子对象的大小可能导致路径消息大于单个未分段的IP数据包。有关如何处理该案件的示例，请参见[RFC6004]第4.4节。
A value of zero (0) has special meaning and MAY be used in either the LABEL or UPSTREAM_LABEL object. A value of zero (0) is used in a LABEL or UPSTREAM_LABEL object to indicate that the subchannel(s) used in the corresponding (downstream or upstream) direction MUST match the subchannel(s) carried in the reverse directions label object. When value of zero (0) is used, no subchannels are included in the Channel_Set Subobject and only one Channel_Set Subobject may be present. The zero (0) value MUST NOT be used in both the LABEL and UPSTREAM_LABEL objects of the same LSP. Note that unacceptable label values continue to be handled according to [RFC3209] and [RFC3473], i.e., they result in PathErr or ResvErr messages with a "Routing problem/Unacceptable label value" indication. For example, in the case where a Resv message containing a zero (0) in both the LABEL and UPSTREAM_LABEL objects is received, the node would generate a ResvErr message.
零（0）值具有特殊含义，可用于标签或上游标签对象。标签或上游标签对象中使用的值为零（0），表示在相应（下游或上游）方向使用的子通道必须与反向标签对象中携带的子通道匹配。当使用零值（0）时，Channel_Set子对象中不包括任何子通道，并且只能存在一个Channel_Set子对象。同一LSP的LABEL和UPSTREAM_LABEL对象中不得同时使用零（0）值。请注意，不可接受的标签值将继续按照[RFC3209]和[RFC3473]进行处理，即，它们会导致PathErr或ResvErr消息带有“路由问题/不可接受的标签值”指示。例如，在接收到标签和上游_标签对象中都包含零（0）的Resv消息的情况下，节点将生成ResvErr消息。
Label Type: 14 bits
标签类型：14位
See [RFC3473] for a description of this field.
有关此字段的说明，请参见[RFC3473]。
Subchannel: Variable
子通道：可变
See [RFC3471] for a description of this field. Note that this field might not be 32-bit aligned.
有关此字段的说明，请参见[RFC3471]。请注意，此字段可能不是32位对齐的。
Padding: Variable
填充：变量
Padding is used to ensure that the length of a Channel_Set Subobject meets the multiple of 4 byte size requirement stated above. The field is only required when the Subchannel field is not 32-bit aligned and the number of included Subchannel fields result in the Subobject not being 32-bit aligned.
填充用于确保通道集子对象的长度满足上述4字节大小的倍数要求。仅当子通道字段未32位对齐且包含的子通道字段数导致子对象未32位对齐时，才需要该字段。
The Padding field MUST be included when the number of bits represented in all the Subchannel fields included in a Generalized Channel_Set Subobject result in the Subobject not being 32-bit aligned. When present, the Padding field MUST have a length that results in the Subobject being 32-bit aligned. When present, the Padding field MUST be set to a zero (0) value on transmission and MUST be ignored on receipt. These bits SHOULD be passed through unmodified by transit nodes.
当通用通道集子对象中包含的所有子通道字段中表示的位数导致子对象未对齐32位时，必须包含填充字段。存在时，填充字段的长度必须导致子对象32位对齐。如果存在，则在传输时必须将填充字段设置为零（0）值，并且在接收时必须忽略该字段。这些位应在传输节点未修改的情况下通过。
Note that the overall length of a Channel_Set Subobject is determined based on the value of the Num Subchannels field together with the size of each Subchannel field as well as any required padding. The size of the Subchannel field is uniquely identified by the Label Type field.
请注意，通道集合子对象的总长度是基于Num Subchannels字段的值、每个子通道字段的大小以及任何所需的填充来确定的。子通道字段的大小由标签类型字段唯一标识。
The previous section introduced a new LABEL object. As such the formats of the other label-related objects and subobjects are also impacted. Processing of these objects and subobjects is not modified and remains per their respective specifications. The other label related objects and subobjects are defined in [RFC3473] and include:
上一节介绍了一个新的标签对象。因此，其他标签相关对象和子对象的格式也会受到影响。这些对象和子对象的处理不会被修改，而是按照其各自的规范进行处理。[RFC3473]中定义了其他与标签相关的对象和子对象，包括：
- SUGGESTED_LABEL object - LABEL_SET object - ACCEPTABLE_LABEL_SET object - UPSTREAM_LABEL object - RECOVERY_LABEL object - Label ERO subobject - Label RRO subobject
- 建议的标签对象-标签集对象-可接受的标签集对象-上游标签对象-恢复标签对象-标签ERO子对象-标签RRO子对象
The label-related objects and subobjects each contain a Label field, all of which may carry any label type. As any label type may be carried, the introduction of a new label type means that the new label type may be carried in the Label field of each of the label-related objects and subobjects. No new definition needs to specified as their original specification is label-type agnostic.
与标签相关的对象和子对象都包含一个标签字段，所有这些字段都可以包含任何标签类型。由于可以携带任何标签类型，引入新标签类型意味着可以在每个标签相关对象和子对象的标签字段中携带新标签类型。不需要指定新定义，因为它们的原始规范与标签类型无关。
Transit and egress nodes that do not support the Generalized Channel_Set Label related formats will first receive a Path message containing Generalized Channel_Set LABEL_REQUEST object. When such a node receives the Path message, per [RFC3209], it will send a PathErr with the error code "Unknown object C_Type".
不支持广义通道集标签相关格式的传输和出口节点将首先接收包含广义通道集标签请求对象的路径消息。当此类节点按照[RFC3209]接收路径消息时，它将发送一个路径错误，错误代码为“未知对象C_类型”。
Ingress nodes initiating a Path message containing a Generalized Channel_Set LABEL_REQUEST object on receiving such a PathErr messages, then notify the requesting application user as appropriate.
入口节点在收到此类PathErr消息时启动包含通用通道设置标签请求对象的路径消息，然后根据需要通知请求应用程序用户。
IANA has assigned new values for namespaces defined in this document and summarized in this section. The registries are available from http://www.iana.org.
IANA已为本文档中定义的名称空间分配了新值，并在本节中进行了总结。登记处可从以下网址获得：http://www.iana.org.
IANA has made the following assignment in the "Switching Types" section of the "GMPLS Signaling Parameters" registry.
IANA在“GMPLS信令参数”注册表的“切换类型”部分进行了以下分配。
Value Type Reference
----- ------------------------------------ ---------
125 Data Channel Switching Capable (DCSC) [RFC6002]
Value Type Reference
----- ------------------------------------ ---------
125 Data Channel Switching Capable (DCSC) [RFC6002]
The assigned value is reflected in IANAGmplsSwitchingTypeTC of the IANA-GMPLS-TC-MIB available from http://www.iana.org.
分配的值反映在IANA-GMPLS-TC-MIB的IANAGMPLSSSwitchingTypeTC中，可从http://www.iana.org.
IANA has made the following assignment in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry.
IANA在“RSVP参数”注册表的“类名、类号和类类型”部分进行了以下赋值。
A new class type for the existing LABEL_REQUEST Object class number (19) with the following definition:
具有以下定义的现有标签请求对象类编号（19）的新类类型：
Class Types or C-Types:
类别类型或C类型：
5 Generalized Channel_Set [RFC6002]
5通用通道集[RFC6002]
IANA has made the following assignment in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry.
IANA在“RSVP参数”注册表的“类名、类号和类类型”部分进行了以下赋值。
A new class type for the existing RSVP_LABEL Object class number (16) with the following definition:
具有以下定义的现有RSVP_标签对象类编号（16）的新类类型：
Class Types or C-Types:
类别类型或C类型：
4 Generalized Channel_Set [RFC6002]
4通用通道集[RFC6002]
This document introduces new message object formats for use in GMPLS signaling [RFC3473]. It does not introduce any new signaling messages, nor change the relationship between LSRs that are adjacent in the control plane. As such, this document introduces no additional security considerations. See [RFC3473] for relevant security considerations. Additionally, the existing framework for MPLS and GMPLS security is documented in [RFC5920].
本文档介绍了GMPLS信令[RFC3473]中使用的新消息对象格式。它不会引入任何新的信令消息，也不会改变控制平面中相邻的LSR之间的关系。因此，本文档不引入其他安全注意事项。有关安全注意事项，请参见[RFC3473]。此外，现有的MPLS和GMPLS安全框架记录在[RFC5920]中。
[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月。
[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月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，2008年10月。
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4606]Mannie，E.和D.Papadimitriou，“同步光网络（SONET）和同步数字体系（SDH）控制的通用多协议标签交换（GMPLS）扩展”，RFC 4606，2006年8月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching", RFC 6004, October 2010.
[RFC6004]Berger，L.和D.Fedyk，“对城域以太网论坛和G.8011以太网服务交换的通用MPLS（GMPLS）支持”，RFC 60042010年10月。
[RFC6005] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI)", RFC 6005, October 2010.
[RFC6005]Berger，L.和D.Fedyk，“对城域以太网论坛和G.8011用户网络接口（UNI）的通用MPLS（GMPLS）支持”，RFC 60052010年10月。
Acknowledgments
致谢
Dimitri Papadimitriou provided substantial textual contributions to this document and coauthored earlier versions of this document.
Dimitri Papadimitriou为本文件提供了大量的文本贡献，并与他人共同编写了本文件的早期版本。
The authors would like to thank Evelyne Roch, Stephen Shew, and Adrian Farrel for their valuable comments.
作者要感谢伊芙琳·罗奇、斯蒂芬·休和阿德里安·法雷尔的宝贵评论。
Authors' Addresses
作者地址
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger LabN Consulting，L.L.C.电话：+1-301-468-9228电子邮件：lberger@labn.net
Don Fedyk Alcatel-Lucent Groton, MA, 01450 Phone: +1-978-467-5645 EMail: donald.fedyk@alcatel-lucent.com
唐·费迪克·阿尔卡特·朗讯·格罗顿，马萨诸塞州，01450电话：+1-978-467-5645电子邮件：唐纳德。fedyk@alcatel-朗讯网