Internet Engineering Task Force (IETF) D. Li
Request for Comments: 5818 H. Xu
Category: Standards Track Huawei
ISSN: 2070-1721 S. Bardalai
Fujitsu
J. Meuric
France Telecom
D. Caviglia
Ericsson
April 2010
Internet Engineering Task Force (IETF) D. Li
Request for Comments: 5818 H. Xu
Category: Standards Track Huawei
ISSN: 2070-1721 S. Bardalai
Fujitsu
J. Meuric
France Telecom
D. Caviglia
Ericsson
April 2010
Data Channel Status Confirmation Extensions for the Link Management Protocol
链路管理协议的数据通道状态确认扩展
Abstract
摘要
This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-Switching Routers (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature.
本文件定义了链路管理协议（LMP）的简单补充，以提供控制平面工具，通过允许相邻标签交换路由器（LSR）确认数据通道状态，并提供触发器，以便在发现任何差异时通知管理平面，从而帮助定位滞留资源。由于LMP已经用于验证数据平面连接，因此它被认为是支持此功能的合适候选者。
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/rfc5818.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5818.
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 ....................................................3
2. Specification of Requirements ...................................4
3. Problem Explanation .............................................4
3.1. Mismatch Caused by Manual Configuration ....................4
3.2. Mismatch Caused by LSP Deletion ............................5
3.3. Failed Resources ...........................................6
4. Motivation ......................................................6
5. Extensions to LMP ...............................................7
5.1. Confirm Data Channel Status Messages .......................7
5.1.1. ConfirmDataChannelStatus Messages ...................8
5.1.2. ConfirmDataChannelStatusAck Messages ................8
5.1.3. ConfirmDataChannelStatusNack Messages ...............8
5.2. Data Channel Status Subobject ..............................9
5.3. Message Construction ......................................10
5.4. Backward Compatibility ....................................10
6. Procedures .....................................................11
7. Security Considerations ........................................12
8. IANA Considerations ............................................12
8.1. LMP Message Types .........................................12
8.2. LMP Data Link Object Subobject ............................13
8.3. LMP Error_Code Class Type .................................13
9. Acknowledgments ................................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
Contributor's Address .............................................14
1. Introduction ....................................................3
2. Specification of Requirements ...................................4
3. Problem Explanation .............................................4
3.1. Mismatch Caused by Manual Configuration ....................4
3.2. Mismatch Caused by LSP Deletion ............................5
3.3. Failed Resources ...........................................6
4. Motivation ......................................................6
5. Extensions to LMP ...............................................7
5.1. Confirm Data Channel Status Messages .......................7
5.1.1. ConfirmDataChannelStatus Messages ...................8
5.1.2. ConfirmDataChannelStatusAck Messages ................8
5.1.3. ConfirmDataChannelStatusNack Messages ...............8
5.2. Data Channel Status Subobject ..............................9
5.3. Message Construction ......................................10
5.4. Backward Compatibility ....................................10
6. Procedures .....................................................11
7. Security Considerations ........................................12
8. IANA Considerations ............................................12
8.1. LMP Message Types .........................................12
8.2. LMP Data Link Object Subobject ............................13
8.3. LMP Error_Code Class Type .................................13
9. Acknowledgments ................................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
Contributor's Address .............................................14
Generalized Multiprotocol Label Switching (GMPLS) networks are constructed from Traffic Engineering (TE) links connecting Label Switching Routers (LSRs). The TE links are constructed from a set of data channels. In this context, a data channel corresponds to a resource label in a non-packet technology (such as a timeslot or a lambda).
广义多协议标签交换（GMPLS）网络由连接标签交换路由器（LSR）的流量工程（TE）链路构成。TE链路由一组数据通道构成。在此上下文中，数据信道对应于非分组技术（例如时隙或lambda）中的资源标签。
A data channel status mismatch exists if the LSR at one end of a TE link believes that the data channel is assigned to carry data, but the LSR at the other end does not. The term "ready to carry data" means cross-connected or bound to an end-point for the receipt or delivery of data.
如果TE链路一端的LSR认为数据信道被分配来承载数据，而另一端的LSR不相信，则存在数据信道状态不匹配。术语“准备携带数据”是指交叉连接或绑定到数据接收或交付的端点。
Data channel mismatches cannot be detected from the TE information advertised by the routing protocols [RFC4203], [RFC5307]. The existence of some data channel mismatch problems may be detected by a mismatch in the advertised bandwidths where bidirectional TE links and bidirectional services are in use. However, where unidirectional services exist, or where multiple data channel mismatches occur, it is not possible to detect such errors through the routing protocol-advertised TE information. In any case, there is no mechanism to isolate the mismatches by determining which data channels are at fault.
无法从路由协议[RFC4203]、[RFC5307]公布的TE信息中检测到数据信道不匹配。一些数据信道不匹配问题的存在可以通过在使用双向TE链路和双向服务的广告带宽中的不匹配来检测。然而，在存在单向服务的情况下，或者在发生多个数据信道不匹配的情况下，不可能通过路由协议来检测此类错误。在任何情况下，都没有通过确定哪些数据通道出现故障来隔离不匹配的机制。
If a data channel mismatch exists, any attempt to use the data channel for a new Label Switched Path (LSP) will fail. One end of the TE link may attempt to assign the TE link for use, but the other end will report the data channel as unavailable when the control plane or management plane attempts to assign it to an LSP.
如果存在数据通道不匹配，则将数据通道用于新标签交换路径（LSP）的任何尝试都将失败。TE链路的一端可尝试分配TE链路以供使用，但当控制平面或管理平面尝试将数据信道分配给LSP时，另一端将报告数据信道不可用。
Although such a situation can be resolved through the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], such a procedure is inefficient since it may require an additional signaling exchange for each LSP that is set up. When many LSPs are to be set up, and when there are many data channel mismatches, such inefficiencies become significant. It is desirable to avoid the additional signaling overhead, and to report the problems to the management plane so that they can be resolved to improve the efficiency of LSP setup.
尽管这种情况可以通过在GMPLS信令[RFC3473]中使用可接受的标签集对象来解决，但这样的过程是低效的，因为它可能需要为设置的每个LSP进行额外的信令交换。当要设置多个LSP时，并且当存在多个数据通道不匹配时，这种低效率变得显著。希望避免额外的信令开销，并将问题报告给管理平面，以便能够解决这些问题以提高LSP设置的效率。
Correspondingly, such a mismatch situation may give rise to misconnections in the data plane, especially when LSPs are set up using management plane operations.
相应地，这种不匹配情况可能导致数据平面中的错误连接，特别是当使用管理平面操作设置lsp时。
Resources (data channels) that are in a mismatched state are often described as "stranded resources". They are not in use for any LSP, but they cannot be assigned for use by a new LSP because they appear to be in use. Although it is theoretically possible for management plane applications to audit all network resources to locate stranded resources and to release them, this process is rarely performed because of the difficulty of coordinating different Element Management Systems (EMSs) and the associated risks of accidentally releasing in-use resources. It is desirable to have a control plane mechanism that detects and reports stranded resources.
处于不匹配状态的资源（数据通道）通常被描述为“搁浅资源”。它们未用于任何LSP，但无法分配给新LSP使用，因为它们似乎正在使用。尽管理论上管理平面应用程序可以审核所有网络资源以定位滞留资源并释放它们，但由于协调不同的元素管理系统（EMS）的困难以及意外释放使用中资源的相关风险，很少执行此过程。希望有一个控制平面机制来检测和报告滞留资源。
This document defines simple additions to the Link Management Protocol (LMP) [RFC4204] to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature.
本文件定义了链路管理协议（LMP）[RFC4204]的简单补充，以提供一个控制平面工具，该工具可通过允许相邻LSR确认数据信道状态来帮助定位搁浅资源，并提供触发器，以便在发现任何差异时通知管理平面。由于LMP已经用于验证数据平面连接，因此它被认为是支持此功能的合适候选者。
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]中所述进行解释。
Examples of data channel mismatches are described in the following three scenarios.
以下三种场景中描述了数据通道不匹配的示例。
In all of the scenarios, the specific channel resource of a data link will be unavailable because of the data channel status mismatch, and this channel resource will be wasted. Furthermore, a data channel status mismatch may reduce the possibility of successful LSP establishment, because a data channel status mismatch may result in failure when establishing an LSP.
在所有场景中，由于数据通道状态不匹配，数据链路的特定通道资源将不可用，并且该通道资源将被浪费。此外，数据信道状态不匹配可降低成功LSP建立的可能性，因为数据信道状态不匹配可导致在建立LSP时失败。
So it is desirable to confirm the data channel statuses as early as possible.
因此，希望尽早确认数据通道状态。
The operator may have configured a cross-connect at only one end of a TE link using an EMS. The resource at one end of the data channel is allocated, but the corresponding resource is still available at the other end of the same data channel. In this case, the data channel may appear to be available for use by the control plane when viewed from one end of the TE link but, will be considered to be unavailable
操作员可能已经使用EMS在TE链路的一端配置了交叉连接。数据通道一端的资源已分配，但相同数据通道另一端的相应资源仍然可用。在这种情况下，当从TE链路的一端观看时，数据信道可能看起来可供控制平面使用，但将被视为不可用
by the other end of the TE link. Alternatively, the available end of the data channel may be cross-connected by the management plane, and a misconnection may result from the fact that the other end of the data channel is already cross-connected.
在TE链路的另一端。或者，数据信道的可用端可以由管理平面交叉连接，并且错误连接可能由于数据信道的另一端已经交叉连接的事实而导致。
Figure 1 shows a data channel between nodes A and B. The resource at A's end of the TE link is allocated through manual configuration, while the resource at B's end of the TE link is available, so the data channel status is mismatched.
图1显示了节点a和B之间的数据通道。TE链路a端的资源通过手动配置分配，而TE链路B端的资源可用，因此数据通道状态不匹配。
allocated available
+-+------------+-+
A |x| | | B
+-+------------+-+
data channel
allocated available
+-+------------+-+
A |x| | | B
+-+------------+-+
data channel
Figure 1. Mismatch Caused by Manual Configuration
图1。手动配置导致的不匹配
The channel status of a data link may become mismatched during the LSP deletion process. If the LSP deletion process is aborted in the middle of the process (perhaps because of a temporary control plane failure), the cross-connect at the upstream node may be removed while the downstream node still keeps its cross-connect, if the LSP deletion was initiated by the source node.
在LSP删除过程中，数据链路的信道状态可能变得不匹配。如果在过程中间中止LSP删除过程（可能是由于临时控制平面故障），如果下游节点仍然保持交叉连接，则上游节点的交叉连接可以被移除，如果LSP删除是由源节点发起的。
For example, in Figure 2, an LSP traverses nodes A, B, and C. Node B resets abnormally when the LSP is being deleted. This results in the cross-connects of nodes A and C being removed, but the cross-connect of node B still being in use. So, the data channel statuses between nodes A and B, and between nodes B and C are both mismatched.
例如，在图2中，LSP遍历节点A、B和C。删除LSP时，节点B会异常重置。这导致节点A和C的交叉连接被移除，但节点B的交叉连接仍在使用中。因此，节点A和B之间以及节点B和C之间的数据通道状态都不匹配。
<---------LSP--------->
+-+-------+-+-------+-+
| | |X| | |
+-+-------+-+-------+-+
A B C
<---------LSP--------->
+-+-------+-+-------+-+
| | |X| | |
+-+-------+-+-------+-+
A B C
Figure 2. Mismatch Caused by LSP Deletion
图2。LSP删除导致的不匹配
In [RFC2205] and [RFC3209], a "soft state" mechanism was defined to prevent state discrepancies between LSRs. Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) restart processes ([RFC3473], [RFC5063]) have been defined: adjacent LSRs may resynchronize their control plane state to reinstate information about LSPs that have persisted in the data plane. Both mechanisms aim at keeping state consistency among nodes and allow LSRs to detect mismatched data
在[RFC2205]和[RFC3209]中，定义了“软状态”机制，以防止LSR之间的状态差异。已定义资源预留协议流量工程（RSVP-TE）重启过程（[RFC3473]、[RFC5063]）：相邻的LSR可能会重新同步其控制平面状态，以恢复数据平面中保留的LSP信息。这两种机制都旨在保持节点之间的状态一致性，并允许LSR检测不匹配的数据
plane states. The data plane handling of such mismatched states can be treated as a local policy decision. Some deployments may decide to automatically clean up the data plane state so it matches the control plane state, but others may choose to raise an alert to the management plane and leave the data plane untouched just in case it is in use.
飞机状态。这种不匹配状态的数据平面处理可以视为本地策略决策。某些部署可能会决定自动清理数据平面状态，使其与控制平面状态匹配，但其他部署可能会选择向管理平面发出警报，并保持数据平面不动，以防数据平面正在使用。
In such cases, data channel mismatches may arise after restart and might not be cleared up by the restart procedures.
在这种情况下，重新启动后可能会出现数据通道不匹配，并且可能无法通过重新启动过程清除。
Even if the situation is not common, it might happen that a termination point of a TE link is seen as failed by one end, while on the other end it is seen as OK. This problem may arise due to some failure either in the hardware or in the status detection of the termination point.
即使这种情况并不常见，也可能发生这样的情况：TE链路的终止点在一端被视为故障，而在另一端被视为正常。该问题可能是由于硬件或终端状态检测中的某些故障引起的。
This mismatch in the termination point status can lead to failure in the case of bidirectional LSP setup.
在双向LSP设置的情况下，终止点状态的这种不匹配可能导致失败。
Good Failed
+-+------------+-+
A | | |X| B
+-+------------+-+
data channel
Path Message with Upstream Label---->
Good Failed
+-+------------+-+
A | | |X| B
+-+------------+-+
data channel
Path Message with Upstream Label---->
Figure 3. Mismatch Caused by Resource Failure
图3。资源故障导致的不匹配
In this case, the upstream node chooses to use termination point A in order to receive traffic from the downstream node. From the upstream node's point of view, the resource is available and thus usable; however, in the downstream node, the corresponding termination point (resource B) is broken. This leads to a setup failure.
在这种情况下，上游节点选择使用终止点A以便从下游节点接收业务。从上游节点的角度来看，资源是可用的，因此是可用的；然而，在下游节点中，相应的终止点（资源B）断开。这会导致安装失败。
The requirement does not come from a lack in GMPLS specifications themselves but rather from operational concerns because, in most cases, GMPLS-controlled networks will co-exist with legacy networks and legacy procedures.
这一要求并非源于GMPLS规范本身的缺乏，而是源于运营问题，因为在大多数情况下，GMPLS控制的网络将与传统网络和传统程序共存。
The protocol extensions defined in this document are intended to detect data plane problems resulting from misuse or misconfigurations triggered by user error, or resulting from failure to clean up the data plane after control plane disconnection. It is anticipated that human mistakes are probably the major source of errors to deal with.
本文档中定义的协议扩展旨在检测由于用户错误触发的误用或错误配置，或由于控制平面断开连接后未能清理数据平面而导致的数据平面问题。预计人为错误可能是要处理的错误的主要来源。
This document is not intened to provide a protocol mechanism to deal with broken implementations.
本文档无意提供协议机制来处理中断的实现。
The procedures defined in this document are designed to be performed on a periodic or on-demand basis. It is NOT RECOMMENDED that the procedures be used to provide a continuous and on-line monitoring process.
本文件中定义的程序旨在定期或按需执行。不建议使用这些程序来提供连续的在线监测过程。
As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature.
由于LMP已经用于验证数据平面连接，因此它被认为是支持此功能的合适候选者。
A control plane tool to detect and isolate data channel mismatches is provided in this document by simple additions to the Link Management Protocol (LMP) [RFC4204]. It can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses.
本文件通过对链路管理协议（LMP）[RFC4204]的简单添加，提供了一种用于检测和隔离数据通道不匹配的控制平面工具。它可以通过允许相邻的LSR确认数据通道状态来帮助定位搁浅资源。
Outline procedures are described in this section. More detailed procedures are found in Section 6.
本节介绍了概述程序。更详细的程序见第6节。
The message formats in the subsections that follow use Backus-Naur Form (BNF) encoding as defined in [RFC5511].
以下小节中的消息格式使用[RFC5511]中定义的Backus Naur Form（BNF）编码。
Extensions to LMP to confirm a data channel status are described below. In order to confirm a data channel status, the new LMP messages are sent between adjacent nodes periodically or driven by some event (such as an operator command, a configurable timer, or the rejection of an LSP setup message because of an unavailable resource). The new LMP messages run over the control channel, encapsulated in UDP with an LMP port number and IP addressing as defined in "Link Management Protocol (LMP)" [RFC4204].
用于确认数据信道状态的LMP扩展如下所述。为了确认数据信道状态，新的LMP消息在相邻节点之间周期性地发送或由某些事件驱动（例如操作员命令、可配置定时器或由于不可用资源而拒绝LSP设置消息）。新的LMP消息在控制通道上运行，用UDP封装，带有“链路管理协议（LMP）”[RFC4204]中定义的LMP端口号和IP地址。
Three new messages are defined to check data channel status: ConfirmDataChannelStatus, ConfirmDataChannelStatusAck, and ConfirmDataChannelStatusNack. These messages are described in detail in the following subsections. Message Type numbers are found in Section 8.1.
定义了三条新消息来检查数据通道状态：ConfirmDataChannelStatus、ConfirmDataChannelStatusAck和ConfirmDataChannelStatusNack。以下小节将详细描述这些消息。消息类型编号见第8.1节。
The ConfirmDataChannelStatus message is used to provide the remote end of the data channel with the status of the local end of the data channel and to ask the remote end to report its data channel. The message may report on (and request information about) more than one data channel.
ConfirmDataChannelStatus消息用于向数据通道的远程端提供数据通道本地端的状态，并要求远程端报告其数据通道。该消息可以报告（并请求关于）多个数据信道的信息。
<ConfirmDataChannelStatus Message> ::= <Common Header>
<LOCAL_LINK_ID>
<MESSAGE_ID>
<DATA_LINK>[<DATA_LINK>...]
<ConfirmDataChannelStatus Message> ::= <Common Header>
<LOCAL_LINK_ID>
<MESSAGE_ID>
<DATA_LINK>[<DATA_LINK>...]
When a node receives the ConfirmDataChannelStatus message, and the data channel status confirmation procedure is supported at the node, the node compares its own data channel statuses with all of the data channel statuses sent by the remote end in the ConfirmDataChannelStatus message. If a data channel status mismatch is found, this mismatch result is expected to be reported to the management plane for further action. Management plane reporting procedures and actions are outside the scope of this document.
当节点接收到ConfirmDataChannelStatus消息，并且该节点支持数据通道状态确认过程时，该节点将自己的数据通道状态与ConfirmDataChannelStatus消息中远程端发送的所有数据通道状态进行比较。如果发现数据通道状态不匹配，则该不匹配结果将报告给管理平面，以便采取进一步措施。管理层报告程序和措施不在本文件范围内。
If the message is a Confirm Data Channel Status message, and the MESSAGE_ID value is less than the largest MESSAGE_ID value previously received from the sender for the specified TE link, then the message SHOULD be treated as being out-of-order.
如果消息是确认数据通道状态消息，且消息ID值小于先前从指定TE链路的发送方收到的最大消息ID值，则该消息应视为无序。
The ConfirmDataChannelStatusAck message is sent back to the node that originated the ConfirmDataChannelStatus message to return the requested data channel statuses.
ConfirmDataChannelStatusAck消息被发送回发出ConfirmDataChannelStatus消息的节点，以返回请求的数据通道状态。
When the ConfirmDataChannelStatusAck message is received, the node compares the received data channel statuses at the remote end with those at the local end (the same operation as performed by the receiver of the ConfirmDataChannelStatus message). If a data channel status mismatch is found, the mismatch result is expected to be reported to the management plane for further action.
当接收到ConfirmDataChannelStatusAck消息时，节点将远程端接收到的数据通道状态与本地端的数据通道状态进行比较（与ConfirmDataChannelStatus消息的接收器执行的操作相同）。如果发现数据通道状态不匹配，则应将不匹配结果报告给管理平面，以便采取进一步措施。
<ConfirmDataChannelStatusAck Message> ::= <Common Header>
<MESSAGE_ID_ACK>
<DATA_LINK>[<DATA_LINK>...]
<ConfirmDataChannelStatusAck Message> ::= <Common Header>
<MESSAGE_ID_ACK>
<DATA_LINK>[<DATA_LINK>...]
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ConfirmDataChannelStatus message being acknowledged.
消息\u ID\u ACK对象的内容必须从正在确认的ConfirmDataChannelStatus消息中获取。
Note that the ConfirmDataChannelStatusAck message is used both when the data channel statuses match and when they do not match.
请注意，当数据通道状态匹配或不匹配时，都会使用ConfirmDataChannelStatusAck消息。
When a node receives the ConfirmDataChannelStatus message, if the data channel status confirmation procedure is not supported but the message is recognized, a ConfirmDataChannelStatusNack message
当节点接收到ConfirmDataChannelStatus消息时，如果数据通道状态确认过程不受支持，但该消息已被识别，则会出现ConfirmDataChannelStatusNack消息
containing an ERROR_CODE indicating "Channel Status Confirmation Procedure not supported" MUST be sent.
必须发送包含指示“不支持通道状态确认程序”的错误代码。
If the data channel status confirmation procedure is supported, but the node is unable to begin the procedure, a ConfirmDataChannelStatusNack message containing an ERROR_CODE indicating "Unwilling to Confirm" MUST be sent. If a ConfirmDataChannelStatusNack message is received with such an ERROR_CODE, the node that originated the ConfirmDataChannelStatus message MAY schedule the ConfirmDataChannelStatus message retransmission after a configured time. A default value of 10 minutes is suggested for this timer.
如果支持数据通道状态确认过程，但节点无法开始该过程，则必须发送一条ConfirmDataChannelStatusNack消息，其中包含一个错误代码，指示“不愿意确认”。如果接收到带有此类错误代码的ConfirmDataChannelStatusNack消息，则发起ConfirmDataChannelStatus消息的节点可在配置的时间后安排ConfirmDataChannelStatus消息的重新传输。建议此计时器的默认值为10分钟。
<ConfirmDataChannelStatusNack Message> ::= <Common Header>
[<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK>
<ERROR_CODE>
<ConfirmDataChannelStatusNack Message> ::= <Common Header>
[<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK>
<ERROR_CODE>
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ConfirmDataChannelStatus message being rejected.
必须从被拒绝的ConfirmDataChannelStatus消息中获取消息\u ID\u ACK对象的内容。
The ERROR_CODE object in this message has a new Class Type (see Section 8.3), but is formed as the ERROR_CODE object defined in [RFC4204]. The following Error Codes are defined:
此消息中的错误代码对象有一个新的类类型（参见第8.3节），但其形式为[RFC4204]中定义的错误代码对象。定义了以下错误代码：
0x01 = Channel Status Confirmation Procedure not supported 0x02 = Unwilling to Confirm
0x01=不支持通道状态确认程序0x02=不愿意确认
A new Data Channel Status subobject type is introduced to the DATA LINK object to hold the Data Channel Status and Data Channel ID.
将向数据链接对象引入新的数据通道状态子对象类型，以保存数据通道状态和数据通道ID。
See Section 8.2 for the Subobject Type value.
有关子对象类型值，请参见第8.2节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Data Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Data Channel ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Data Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Data Channel ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Channel Status:
数据通道状态：
This is a series of bit flags to indicate the status of the data channel. The following values are defined.
这是一系列位标志，用于指示数据通道的状态。定义了以下值。
0x0000 : The channel is available/free. 0x0001 : The channel is unavailable/in-use.
0x0000：频道可用/免费。0x0001:频道不可用/正在使用中。
Data Channel ID
数据通道ID
This identifies the data channel. The length of this field can be deduced from the Length field in the subobject. Note that all subobjects must be padded to a four-byte boundary with trailing zeros.
这标识了数据通道。此字段的长度可以从子对象中的长度字段推断。请注意，所有子对象都必须填充到带有尾随零的四字节边界。
If such padding is required, the Length field MUST indicate the length of the subobject up to, but not including, the first byte of padding. Thus, the amount of padding is deduced and not represented in the Length field.
如果需要这种填充，则长度字段必须指示子对象的长度，直到但不包括填充的第一个字节。因此，将推导填充量，而不在长度字段中表示。
Note that the Data Channel ID is given in the context of the sender of the ConfirmChannelStatus message.
请注意，数据通道ID是在ConfirmChannelStatus消息的发送方上下文中给出的。
The Data Channel ID must be encoded as a label value. Based on the type of signal (e.g., Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Lambda, etc.), the encoding methodology used will be different. For SONET/SDH, the label value is encoded as per [RFC4606].
数据通道ID必须编码为标签值。根据信号类型（例如，同步光网络/同步数字体系（SONET/SDH）、Lambda等），使用的编码方法将有所不同。对于SONET/SDH，标签值按照[RFC4606]进行编码。
Data_Link Class (as defined in Section 13.12 of [RFC4204]) is included in ConfirmDataChannelStatus and ConfirmDataChannelStatusAck messages.
ConfirmDataChannelStatus和ConfirmDataChannelStatusAck消息中包含数据链路类别（如[RFC4204]第13.12节中的定义）。
The status of the TE link end MUST be carried by the Data Channel Status subobject, which is defined in Section 5.2 of this document. The new subobject MUST be part of Data_Link Class.
TE链路端的状态必须由本文件第5.2节中定义的数据通道状态子对象携带。新的子对象必须是数据链接类的一部分。
In the case of SONET/SDH, the Data Channel ID in the new subobject SHOULD be used to identify each timeslot of the data link.
对于SONET/SDH，应使用新子对象中的数据通道ID来标识数据链路的每个时隙。
Some nodes running in the network might only support the LMP Message Types, which are already defined in [RFC4204]. The three new types of LMP messages defined in this document cannot be recognized by these nodes. The behavior of an LMP node that receives an unknown
网络中运行的某些节点可能仅支持LMP消息类型，这些消息类型已在[RFC4204]中定义。这些节点无法识别本文档中定义的三种新类型的LMP消息。接收未知信息的LMP节点的行为
message is not specified in [RFC4204] and will be clarified in a separate document.
[RFC4204]中未规定信息，将在单独的文件中予以澄清。
Since the behavior of legacy nodes must be assumed to be unknown, this document assumes that a deployment intended to support the function described in this document will consist completely of nodes that support the protocol extensions also described in this document.
由于必须假定遗留节点的行为未知，因此本文档假定旨在支持本文档中所述功能的部署将完全由支持本文档中所述协议扩展的节点组成。
In the future, it may be the case that LMP will be extended to allow function support to be detected. In that case, it may become possible to deploy this function in a mixed environment.
将来，可能会扩展LMP以允许检测功能支持。在这种情况下，可以在混合环境中部署此功能。
Adjacent nodes MAY send data channel status confirmation-related LMP messages. Periodical timers or some other events requesting the confirmation of channel status for the data link may trigger these messages. It's a local policy decision to start the data channel status confirmation process. The procedure is described below:
相邻节点可以发送与数据信道状态确认相关的LMP消息。请求确认数据链路信道状态的定期定时器或一些其他事件可能触发这些消息。启动数据通道状态确认流程是本地政策决定。程序描述如下：
. Initially, the SENDER constructs a ConfirmDataChannelStatus message that MUST contain one or more DATA_LINK objects. The DATA_LINK object is defined in [RFC4204]. Each DATA_LINK object MUST contain one or more Data Channel Status subobjects. The Data Channel ID field in the Data Channel Status subobject MUST indicate which data channel needs to be confirmed, and MUST report the data channel status at the SENDER. The ConfirmDataChannelStatus message is sent to the RECEIVER.
. 最初，发送方构造一个ConfirmDataChannelStatus消息，该消息必须包含一个或多个数据链接对象。数据链接对象在[RFC4204]中定义。每个数据链接对象必须包含一个或多个数据通道状态子对象。数据通道状态子对象中的数据通道ID字段必须指示需要确认的数据通道，并且必须在发送方报告数据通道状态。ConfirmDataChannelStatus消息被发送到接收方。
. Upon receipt of a ConfirmDataChannelStatus message, the RECEIVER MUST extract the data channel statuses from the ConfirmDataChannelStatus message and SHOULD compare these with its data channel statuses for the reported data channels. If a data channel status mismatch is found, the mismatch result SHOULD be reported to the management plane for further action. The RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message, which MUST carry all the local end statuses of the requested data channels to the SENDER.
. 接收到ConfirmDataChannelStatus消息后，接收器必须从ConfirmDataChannelStatus消息中提取数据通道状态，并应将其与报告数据通道的数据通道状态进行比较。如果发现数据通道状态不匹配，则应将不匹配结果报告给管理平面，以便采取进一步措施。接收方还应向发送方发送ConfirmDataChannelStatusAck消息，该消息必须携带所请求数据通道的所有本地结束状态。
. If the RECEIVER is not able to support or to begin the confirmation procedure, the RECEIVER MUST send a ConfirmDataChannelStatusNack message containing the ERROR_CODE that indicates the reason for rejection.
. 如果接收器无法支持或开始确认程序，则接收器必须发送一条ConfirmDataChannelStatusNack消息，其中包含指示拒绝原因的错误代码。
. Upon receipt of a ConfirmDataChannelStatusAck message, the SENDER MUST compare the received data channel statuses at the remote end with the data channel statuses at the local end. If a data
. 收到ConfirmDataChannelStatusAck消息后，发送方必须将远程端接收到的数据通道状态与本地端的数据通道状态进行比较。如果一个数据
channel status mismatch is found, the mismatch result SHOULD be reported to the management plane for further action.
如果发现通道状态不匹配，则应将不匹配结果报告给管理平面以采取进一步措施。
The data channel status mismatch issue identified by LMP may be automatically resolved by RSVP restart. For example, the restarting node may also have damaged its data plane. This leaves the data channels mismatched. However, RSVP restart will re-install the data plane state in the restarting node. The issue may also be resolved via RSVP soft state timeout.
LMP识别的数据通道状态不匹配问题可通过RSVP重启自动解决。例如，重新启动节点也可能损坏了其数据平面。这使得数据通道不匹配。但是，RSVP restart将在重新启动节点中重新安装数据平面状态。该问题也可以通过RSVP软状态超时来解决。
If the ConfirmDataChannelStatus message is not recognized by the RECEIVER, the RECEIVER ignores this message and will not send out an acknowledgment message to the SENDER.
如果接收方无法识别ConfirmDataChannelStatus消息，则接收方将忽略此消息，并且不会向发送方发送确认消息。
Due to the message loss problem, the SENDER may not be able to receive the acknowledgment message.
由于消息丢失问题，发送方可能无法接收确认消息。
ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable transmission mechanisms. If, after the retry limit is reached, a ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack message is not received by the SENDER, the SENDER SHOULD terminate the data channel confirmation procedure and SHOULD raise an alert to the management plane.
应使用LMP[RFC4204]可靠传输机制发送ConfirmDataChannelStatus。如果在达到重试限制后，发送方未收到ConfirmDataChannelStatusAck消息或ConfirmDataChannelStatusNack消息，则发送方应终止数据通道确认过程，并应向管理层发出警报。
[RFC4204] describes how LMP messages between peers can be secured, and these measures are equally applicable to the new messages defined in this document.
[RFC4204]描述了如何保护对等点之间的LMP消息，这些措施同样适用于本文档中定义的新消息。
The operation of the procedures described in this document does not of itself constitute a security risk because it does not cause any change in network state. It would be possible, if the messages were intercepted or spoofed, to cause bogus alerts in the management plane, and so the use of LMP security measures described in [RFC4204] is RECOMMENDED.
本文件所述程序的操作本身并不构成安全风险，因为它不会导致网络状态发生任何变化。如果消息被截获或伪造，则可能在管理平面中引起虚假警报，因此建议使用[RFC4204]中描述的LMP安全措施。
Note that performing the procedures described in this document may provide a useful additional security measure to verify that data channels have not been illicitly modified.
请注意，执行本文档中描述的步骤可能会提供有用的附加安全措施，以验证数据通道是否未被非法修改。
IANA maintains the "Link Management Protocol (LMP)" registry, which has a subregistry called "LMP Message Type". IANA has made the following three new allocations from this registry.
IANA维护“链路管理协议（LMP）”注册表，该注册表有一个称为“LMP消息类型”的子区。IANA已从该注册表进行了以下三项新分配。
Value Description
------ ---------------------------------
32 ConfirmDataChannelStatus
33 ConfirmDataChannelStatusAck
34 ConfirmDataChannelStatusNack
Value Description
------ ---------------------------------
32 ConfirmDataChannelStatus
33 ConfirmDataChannelStatusAck
34 ConfirmDataChannelStatusNack
IANA maintains the "Link Management Protocol (LMP)" registry, which has a subregistry called "LMP Object Class name space and Class type (C-Type)". This subregistry has an entry for the DATA_LINK object, and there is a further embedded registry called "DATA_LINK Sub-object Class name space". IANA has made the following allocation from this embedded registry.
IANA维护“链路管理协议（LMP）”注册表，该注册表有一个子区，名为“LMP对象类名称空间和类类型（C-type）”。该子区域有一个数据链接对象的条目，还有一个名为“数据链接子对象类名称空间”的嵌入式注册表。IANA已从此嵌入式注册表进行了以下分配。
Value Description
------ ---------------------------------
9 Data Channel Status
Value Description
------ ---------------------------------
9 Data Channel Status
IANA maintains the "Link Management Protocol (LMP)" registry, which has a subregistry called "LMP Object Class name space and Class type (C-Type)". This subregistry has an entry for the ERROR_CODE object. IANA has allocated the following new value for an ERROR_CODE class type.
IANA维护“链路管理协议（LMP）”注册表，该注册表有一个子区，名为“LMP对象类名称空间和类类型（C-type）”。此子区域具有错误代码对象的条目。IANA已为错误代码类类型分配了以下新值。
C-Type Description Reference
------ ---------------------------- ---------
4 ConfirmDataChannelStatusNack [This RFC]
C-Type Description Reference
------ ---------------------------- ---------
4 ConfirmDataChannelStatusNack [This RFC]
The authors would like to thank Adrian Farrel, Dimitri Papadimitriou, and Lou Berger for their useful comments.
作者要感谢阿德里安·法雷尔、迪米特里·帕帕迪米特里欧和卢·伯杰的有用评论。
[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月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]Lang，J.，Ed.，“链路管理协议（LMP）”，RFC4204，2005年10月。
[RFC5511] Farrel, A., Ed., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511]Farrel，A.，Ed.“路由Backus-Naur形式（RBNF）：用于在各种路由协议规范中形成编码规则的语法”，RFC 5511，2009年4月。
[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月。
[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月。
[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月。
[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月。
[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月。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063]Satyanarayana，A.，Ed.，和R.Rahman，Ed.，“GMPLS资源预留协议（RSVP）优雅重启的扩展”，RFC 5063，2007年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月。
Contributor's Address
投稿人地址
Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 China
华为技术F3-5-B研发中心，华为总部深圳518129
Phone: +86 755-289-72912
EMail: zhangfatai@huawei.com
Phone: +86 755-289-72912
EMail: zhangfatai@huawei.com
Authors' Addresses
作者地址
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 China
中国深圳华为基地华为技术F3-5-B研发中心，邮编：518129
Phone: +86 755-289-70230
EMail: danli@huawei.com
Phone: +86 755-289-70230
EMail: danli@huawei.com
Huiying Xu Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 China
华为技术F3-5-B研发中心，华为总部深圳518129
Phone: +86 755-289-72910
EMail: xuhuiying@huawei.com
Phone: +86 755-289-72910
EMail: xuhuiying@huawei.com
Snigdho C. Bardalai Fujitsu Network Communications 2801 Telecom Parkway Richardson, Texas 75082, USA
Snigdho C.Bardalai Fujitsu Network Communications美国德克萨斯州理查森电信大道2801号，邮编75082
Phone: +1 972 479 2951
EMail: snigdho.bardalai@us.fujitsu.com
Phone: +1 972 479 2951
EMail: snigdho.bardalai@us.fujitsu.com
Julien Meuric France Telecom Orange Labs 2, avenue Pierre Marzin 22307 Lannion Cedex, France
Julien Meuria法国电信橙色实验室2号，皮埃尔马津大街22307号，法国拉尼翁塞德斯
Phone: +33 2 96 05 28 28
EMail: julien.meuric@orange-ftgroup.com
Phone: +33 2 96 05 28 28
EMail: julien.meuric@orange-ftgroup.com
Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy
Diego Caviglia Ericsson途经A.Negrone 1/A 16153意大利热那亚
Phone: +39 010 600 3736
EMail: diego.caviglia@ericsson.com
Phone: +39 010 600 3736
EMail: diego.caviglia@ericsson.com