Network Working Group J. Lang
Request for Comments: 4207 Sonos, Inc.
Category: Standards Track D. Papadimitriou
Alcatel
October 2005
Network Working Group J. Lang
Request for Comments: 4207 Sonos, Inc.
Category: Standards Track D. Papadimitriou
Alcatel
October 2005
Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages
链路管理协议（LMP）测试消息的同步光网络（SONET）/同步数字体系（SDH）编码
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages.
本文档详细说明了发送链路管理协议（LMP）测试消息时所需的同步光网络（SONET）/同步数字体系（SDH）技术特定信息。
For scalability purposes, multiple physical resources that interconnect Label Switching Routers (LSRs) can be combined to form a single traffic engineering (TE) link for the purposes of path computation and signaling. These resources may represent one or more physical links that connect the LSRs, or they may represent a Label Switched Path (LSP) if LSP hierarchy [RFC4206] is used. The management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques.
出于可伸缩性的目的，可以组合互连标签交换路由器（lsr）的多个物理资源以形成用于路径计算和信令的单个流量工程（TE）链路。这些资源可以表示连接lsr的一个或多个物理链路，或者如果使用LSP层次结构[RFC4206]，它们可以表示标签交换路径（LSP）。TE链路的管理不限于带内消息传递，而是可以使用带外技术来完成。
The Link Management Protocol (LMP) [RFC4204] has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage TE links. LMP currently consists of four main procedures, of which the first two are mandatory and the last two are optional:
链路管理协议（LMP）[RFC4204]是作为通用MPLS（GMPLS）协议套件的一部分开发的，用于管理TE链路。LMP目前包括四个主要程序，其中前两个是强制性的，后两个是可选的：
1. Control channel management 2. Link property correlation 3. Link verification 4. Fault management
1. 控制通道管理2。链接属性相关性3。链接验证4。故障管理
Control channel management is used to establish and maintain control channel connectivity between adjacent nodes. This is done using a Config message exchange followed by a lightweight keep-alive message exchange. Link property correlation is used to aggregate multiple data links into a single TE Link and to synchronize the link properties. Link verification is used to verify the physical connectivity of the data links and to exchange the Interface_Ids of the data links. Fault management is primarily used to suppress alarms and to localize failures in both opaque and transparent networks. When LMP is used with SONET/SDH, however, the fault management procedures may not be needed as existing SONET/SDH mechanisms can be used.
控制通道管理用于建立和维护相邻节点之间的控制通道连接。这是使用配置消息交换和轻量级保持活动消息交换来完成的。链接属性关联用于将多个数据链接聚合为单个TE链接，并同步链接属性。链路验证用于验证数据链路的物理连接，并交换数据链路的接口ID。故障管理主要用于在不透明和透明网络中抑制报警和定位故障。但是，当LMP与SONET/SDH一起使用时，可能不需要故障管理程序，因为可以使用现有SONET/SDH机制。
In this document, the SONET/SDH technology-specific information for LMP is defined. Specifically, the SONET/SDH test procedures used for link verification and link property correlation are detailed. These procedures include the trace correlation transport mechanism (defined for J0, J1, J2) that supports a separation of the transport and control plane identifiers. The latter procedure requires a new trace monitoring function that is discussed in this document. Once the data links have been verified, they can be grouped to form TE links.
在本文件中，定义了LMP的SONET/SDH技术特定信息。具体而言，详细介绍了用于链路验证和链路特性关联的SONET/SDH测试程序。这些过程包括跟踪相关传输机制（为J0、J1、J2定义），该机制支持传输和控制平面标识符的分离。后一个过程需要一个新的跟踪监视功能，本文将对此进行讨论。验证数据链路后，可以将其分组以形成TE链路。
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]中所述进行解释。
The reader is assumed to be familiar with the terminology in [RFC4204], [G.707], and [T1.105]. The following abbreviations are used in this document:
假定读者熟悉[RFC4204]、[G.707]和[T1.105]中的术语。本文件中使用了以下缩写：
CRC-N: Cyclic Redundancy Check-N. DCC: Data communications channel. LOVC: Lower-order virtual container. HOVC: Higher-order virtual container. MS: Multiplex section. MSOH: Multiplex section overhead. POH: Path overhead. RS: Regenerator section. RSOH: Regenerator section overhead. SDH: Synchronous digital hierarchy. SOH: Section overhead.
CRC-N：循环冗余校验-N。DCC：数据通信信道。LOVC：低阶虚拟容器。高阶虚拟容器。MS：多路复用部分。MSOH：多路复用段开销。路径开销。RS：再生器部分。RSOH：再生器段顶置。SDH：同步数字体系。SOH：部分开销。
SONET: Synchronous Optical Network. STM(-N): Synchronous Transport Module (-N) (SDH). STS(-N): Synchronous Transport Signal-Level N (SONET). VC-n: Virtual Container-n (SDH). VTn: Virtual Tributary-n (SONET).
同步光网络。STM（-N）：同步传输模块（-N）（SDH）。STS（-N）：同步传输信号电平N（SONET）。VC-n：虚拟容器n（SDH）。虚拟支路-n（SONET）。
In [RFC4204], a link verification procedure is defined whereby Test messages are transmitted in-band over the data links. This is used for data plane discovery, Interface_Id exchange (Interface_Ids are used in GMPLS signaling, either as port labels [RFC3471] or component link identifiers [RFC4201], depending on the configuration), and physical connectivity verification. Multiple data links can be verified using a single verification procedure; the correlation is done using the Verify_Id that is assigned to the procedure.
在[RFC4204]中，定义了链路验证程序，其中测试消息通过数据链路在频带内传输。这用于数据平面发现、接口Id交换（接口Id在GMPLS信令中用作端口标签[RFC3471]或组件链接标识符[RFC4201]，具体取决于配置）和物理连接验证。可以使用单个验证程序验证多个数据链路；使用分配给程序的验证Id进行关联。
As part of the link verification procedure, a BeginVerify message exchange is used to agree upon parameters for the Test procedure. This can be initiated by sending a BeginVerify message over the control channel. This message includes a BEGIN_VERIFY object that contains a number of fields specifying, among other things, the transmission (bit) rate, encoding type, and transport mechanisms for the Test Messages. If the remote node receives a BeginVerify message and is ready to begin the procedure, it sends a BeginVerifyAck message specifying the desired transport mechanism for the Test messages. The remote node also assigns a Verify_Id to the procedure and includes it in the BeginVerifyAck message.
作为链路验证程序的一部分，BeginVerify消息交换用于商定测试程序的参数。这可以通过在控制通道上发送BeginVerify消息来启动。该消息包括一个BEGIN_VERIFY对象，该对象包含多个字段，其中指定测试消息的传输（比特）速率、编码类型和传输机制。如果远程节点收到BeginVerify消息并准备开始该过程，则会发送BeginVerifyAck消息，指定测试消息所需的传输机制。远程节点还为过程分配验证Id，并将其包含在BeginVerifyAck消息中。
The transmission rate of the data link over which the Test Messages will be transmitted is represented in IEEE floating-point format using a 32-bit number field and expressed in bytes per second. See [RFC3471] for values defined for SONET/SDH.
将在其上传输测试消息的数据链路的传输速率使用32位数字字段以IEEE浮点格式表示，并以字节/秒表示。有关SONET/SDH的定义值，请参见[RFC3471]。
The encoding type identifies the encoding supported by an interface. The defined encoding is consistent with the LSP Encoding Type as defined in [RFC3471]. For SONET/SDH, this value must equal the value given for "SDH ITU-T G.707/SONET ANSI T1.105".
编码类型标识接口支持的编码。定义的编码与[RFC3471]中定义的LSP编码类型一致。对于SONET/SDH，该值必须等于“SDH ITU-T G.707/SONET ANSI T1.105”的给定值。
The transport mechanism is defined using the Verify Transport Mechanism bit mask. The scope of this bit mask is restricted to the link encoding type. Multiple bits may be set when this field is included in the BeginVerify message; however, only one bit may be set when it is included in the BeginVerifyAck message.
传输机制是使用验证传输机制位掩码定义的。此位掩码的范围仅限于链接编码类型。当该字段包含在BeginVerify消息中时，可以设置多个位；但是，当BeginVerifyAck消息中包含一位时，只能设置一位。
In the following subsection, the various options for Verify Transport Mechanism are defined when the encoding is SONET/SDH. The trace correlation transport mechanism (defined for J0, J1, J2) supports a separation of the transport and control plane identifiers.
在下一小节中，当编码为SONET/SDH时，定义了验证传输机制的各种选项。跟踪相关传输机制（为J0、J1、J2定义）支持传输和控制平面标识符的分离。
This field is 16 bits in length.
此字段的长度为16位。
In this document, the flags for SONET/SDH encoding are defined. Note that all values are defined in network byte order (i.e., big-endian byte order).
在本文件中，定义了SONET/SDH编码的标志。请注意，所有值都是以网络字节顺序（即大端字节顺序）定义的。
0x0001: Reserved
0x0001：保留
0x0002 DCCS: Test Message over the Section/RS DCC
0x0002 DCCS：通过段/RS DCC的测试消息
Capable of transmitting Test Messages using the DCC Section/RS Overhead bytes with bit-oriented High-Level Data Link Control (HDLC) framing format [RFC1662].
能够使用DCC段/RS开销字节和面向位的高级数据链路控制（HDLC）帧格式[RFC1662]传输测试消息。
The Test Message is sent as defined in [RFC4204].
按照[RFC4204]中的定义发送测试消息。
0x0004 DCCL: Test Message over the Line/MS DCC
0x0004 DCCL：线路上的测试消息/MS DCC
Capable of transmitting Test Messages using the DCC Line/MS Overhead bytes with bit-oriented HDLC framing format [RFC1662].
能够使用DCC Line/MS开销字节和面向位的HDLC帧格式[RFC1662]传输测试消息。
The Test Message is sent as defined in [RFC4204].
按照[RFC4204]中的定义发送测试消息。
0x0008 J0-trace: J0 Section Trace Correlation
0x0008 J0跟踪：J0节跟踪相关性
Capable of transmitting SONET/SDH Section/RS trace over J0 Section/RS overhead byte as defined in [T1.105] and [G.707].
能够通过[T1.105]和[G.707]中定义的J0段/RS开销字节传输SONET/SDH段/RS跟踪。
The Test Message is not transmitted using the J0 bytes (i.e., over the data link), but is sent over the control channel and correlated for consistency to the received J0 pattern.
测试消息不使用J0字节（即，通过数据链路）传输，而是通过控制信道发送，并与接收到的J0模式一致。
In order to get the mapping between the Interface_Id over which the J0 Test Message is sent and the J0 pattern sent in-band, the transmitting node must provide the correlation between this pattern and the J0 Test Message. This correlation is done using the TRACE object as defined in Section 4.
为了获得发送J0测试消息的接口_Id与带内发送的J0模式之间的映射，传输节点必须提供此模式与J0测试消息之间的相关性。这种关联是使用第4节中定义的跟踪对象完成的。
The format of the Test Message is as follows:
测试消息的格式如下所示：
<Test Message> ::=<Common Header> <LOCAL_INTERFACE_ID>
<VERIFY_ID> <TRACE>
<Test Message> ::=<Common Header> <LOCAL_INTERFACE_ID>
<VERIFY_ID> <TRACE>
0x0010: Reserved
0x0010：保留
0x0020: Reserved
0x0020:保留
0x0040 J1-trace: J1 Path Trace Correlation
0x0040 J1记录道：J1路径记录道相关性
Capable of transmitting SONET/SDH STS SPE/HOVC Path trace over J1 Path overhead byte as defined in [T1.105] and [G.707].
能够通过[T1.105]和[G.707]中定义的J1路径开销字节传输SONET/SDH STS SPE/HOVC路径跟踪。
The Test Message is not transmitted using the J1 bytes (i.e., over the data link), but is sent over the control channel and correlated for consistency to the received J1 pattern.
测试消息不使用J1字节（即通过数据链路）传输，而是通过控制信道发送，并与接收到的J1模式一致。
In order to get the mapping between the Interface_Id over which the J1 Test Message is sent and the J1 pattern sent in-band, the transmitting node must provide the correlation between this pattern and the J1 Test Message. This correlation is done using the TRACE object as defined in Section 4.
为了获得发送J1测试消息的接口_Id与频带内发送的J1模式之间的映射，传输节点必须提供该模式与J1测试消息之间的相关性。这种关联是使用第4节中定义的跟踪对象完成的。
The Test Message format is identical to that defined above in J0-trace.
测试消息格式与上面在J0跟踪中定义的相同。
0x0080 J2-trace: J2 Path Trace Correlation
0x0080 J2跟踪：J2路径跟踪相关性
Capable of transmitting SONET/SDH VT SPE/LOVC Path trace over J2 Path overhead byte as defined in [T1.105] and [G.707].
能够通过[T1.105]和[G.707]中定义的J2路径开销字节传输SONET/SDH VT SPE/LOVC路径跟踪。
The Test Message is not transmitted using the J2 bytes (i.e., over the data link), but is sent over the control channel and correlated for consistency to the received J2 pattern.
测试消息不使用J2字节（即通过数据链路）传输，而是通过控制信道发送，并与接收到的J2模式一致。
In order to get the mapping between the Interface_Id over which the J2 Test Message is sent and the J2 pattern sent in-band, the transmitting node must provide the correlation between this pattern and the J2 Test Message. This correlation is done using the TRACE object as defined in Section 4.
为了获得发送J2测试消息的接口_Id与频带内发送的J2模式之间的映射，传输节点必须提供该模式与J2测试消息之间的相关性。这种关联是使用第4节中定义的跟踪对象完成的。
The Test Message format is identical to that defined above in J0-trace.
测试消息格式与上面在J0跟踪中定义的相同。
The trace monitoring features described in this section allow a node to do trace monitoring by using the SONET/SDH capabilities.
本节中描述的跟踪监视功能允许节点使用SONET/SDH功能进行跟踪监视。
o A node may request its neighbor (the remote node) to monitor a link for a specific pattern in the overhead using the TraceMonitor Message. An example of this overhead is the SONET Section Trace message transmitted in the J0 byte. If the actual trace message does not match the expected trace message, the remote node MUST report the mismatch condition.
o 节点可以使用TraceMonitor消息请求其邻居（远程节点）监视开销中特定模式的链路。这种开销的一个例子是以J0字节传输的SONET段跟踪消息。如果实际跟踪消息与预期跟踪消息不匹配，则远程节点必须报告不匹配情况。
o A node may request the value of the current trace message on a given data link using the TraceReq Message.
o 节点可以使用TraceReq消息请求给定数据链路上的当前跟踪消息的值。
o A node may request a remote node to send a specific trace message over a data link using the InsertTrace Message.
o 节点可以使用InsertTrace消息请求远程节点通过数据链路发送特定跟踪消息。
The TraceMonitor message (Message Type 21) is sent over the control channel and is used to request the remote node to monitor a data link for a specific trace value. This value is inserted in the <TRACE> object. The format of the TraceMonitor message is as follows:
TraceMonitor消息（消息类型21）通过控制通道发送，用于请求远程节点监控数据链路以获取特定的跟踪值。此值插入到<TRACE>对象中。TraceMonitor消息的格式如下：
<TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
<TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The remote node MUST respond to a TraceMonitor message with either a TraceMonitorAck or TraceMonitorNack Message.
远程节点必须使用TraceMonitorAck或TraceMonitorAck消息响应TraceMonitor消息。
Class = 21
Class = 21
o C-Type = 1, Trace
o C-Type=1，跟踪
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | Trace Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Trace Message //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | Trace Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Trace Message //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trace Type: 16 bits
跟踪类型：16位
The type of the trace message. The following values are defined. All other values are reserved.
跟踪消息的类型。定义了以下值。所有其他值均保留。
1 = SONET Section Trace (J0 Byte) 2 = SONET Path Trace (J1 Byte) 3 = SONET Path Trace (J2 Byte) 4 = SDH Section Trace (J0 Byte) 5 = SDH Path Trace (J1 Byte) 6 = SDH Path Trace (J2 Byte)
1=SONET段跟踪（J0字节）2=SONET路径跟踪（J1字节）3=SONET路径跟踪（J2字节）4=SDH段跟踪（J0字节）5=SDH路径跟踪（J1字节）6=SDH路径跟踪（J2字节）
Trace Length: 16 bits
记录道长度：16位
This is the length in bytes of the trace message (as specified by the Trace Type).
这是跟踪消息的字节长度（由跟踪类型指定）。
Trace Message:
跟踪消息：
This is the value of the expected message to be received in-band. The valid length and value combinations are determined by the specific technology: for SONET see [T1.105] and for SDH see [G.707]. The message MUST be padded with zeros to a 32-bit boundary, if necessary. Trace Length does not include padding zeroes.
这是预期在频带内接收的消息的值。有效长度和值组合由特定技术确定：SONET见[T1.105]，SDH见[G.707]。如有必要，消息必须用零填充到32位边界。跟踪长度不包括填充零。
This object is nonnegotiable.
这个目标是不可谈判的。
The TraceMonitorAck message (Message Type 22) is used to acknowledge receipt of the TraceMonitor message and indicate that all of the TRACE Objects in the TraceMonitor message have been received and processed correctly (i.e., no Trace Mismatch).
TraceMonitorAck消息（消息类型22）用于确认收到TraceMonitor消息，并指示TraceMonitor消息中的所有跟踪对象都已正确接收和处理（即，没有跟踪不匹配）。
The format is as follows:
格式如下:
<TraceMonitorAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<TraceMonitorAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TraceMonitor message being acknowledged.
[RFC4204]中定义了消息\u ID\u ACK对象。必须从正在确认的TraceMonitor消息中获取消息\u ID\u ACK对象的内容。
The TraceMonitorNack message (Message Type 23) is used to acknowledge receipt of the TraceMonitor message and indicate that the TRACE Object in the TraceMonitor message was not processed correctly. This could be because the trace monitoring requested is not supported or there was an error in the TRACE object value(s).
TraceMonitorNack消息（消息类型23）用于确认收到TraceMonitor消息，并指示TraceMonitor消息中的跟踪对象未正确处理。这可能是因为不支持请求的跟踪监视，或者跟踪对象值中存在错误。
The format is as follows:
格式如下:
<TraceMonitorNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
<TraceMonitorNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TraceMonitor message being acknowledged.
[RFC4204]中定义了消息\u ID\u ACK和错误\u CODE对象。必须从正在确认的TraceMonitor消息中获取消息\u ID\u ACK对象的内容。
If the Trace type is not supported, the ERROR_CODE MUST indicate "Unsupported Trace Type" defined in Section 4.1.3.1.
如果不支持跟踪类型，则错误代码必须指示第4.1.3.1节中定义的“不支持的跟踪类型”。
If the TRACE object was not equal to the value seen in the trace, the TraceMonitorNack message MUST include the ERROR_CODE indicating "Invalid Trace Message". The TraceMismatch message (see Section 4.1.4) SHOULD NOT be sent as a result of the mismatch.
如果跟踪对象不等于跟踪中看到的值，则TraceMonitorNack消息必须包含指示“无效跟踪消息”的错误代码。不应因不匹配而发送TraceMissMatch消息（见第4.1.4节）。
The TraceMonitorNack message uses a new ERROR_CODE C-Type defined in Section 4.1.3.1.
TraceMonitorNack消息使用第4.1.3.1节中定义的新错误代码C-Type。
C-Type = 3, TRACE_ERROR
C-Type=3，跟踪错误
The following new error code bit-values are defined:
定义了以下新的错误代码位值：
0x01 = Unsupported Trace Type 0x02 = Invalid Trace Message
0x01=不支持的跟踪类型0x02=无效的跟踪消息
All other values are Reserved.
所有其他值均保留。
Multiple bits may be set to indicate multiple errors.
可以设置多个位以指示多个错误。
This Object is nonnegotiable.
这个目标是不可谈判的。
The TraceMismatch message (Message Type 24) is sent over the control channel and is used to report a trace mismatch on a data link for which trace monitoring was requested. The format is as follows:
TraceMismatch消息（消息类型24）通过控制通道发送，用于报告请求跟踪监视的数据链路上的跟踪不匹配。格式如下:
<TraceMismatch message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID>
[<LOCAL_INTERFACE_ID> ...]
<TraceMismatch message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID>
[<LOCAL_INTERFACE_ID> ...]
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
A neighboring node that receives a TraceMismatch message MUST respond with a TraceMismatchAck message.
接收TraceMismatch消息的相邻节点必须使用TraceMismatchAck消息进行响应。
The LOCAL_INTERFACE_ID object is defined in [RFC4204]. The LOCAL_INTERFACE_ID in this message is the local Interface Id of the data link that has a trace mismatch. A trace mismatch for multiple LOCAL_INTERFACE_IDs may be reported in the same message.
本地接口ID对象在[RFC4204]中定义。此消息中的本地接口ID是具有跟踪不匹配的数据链路的本地接口ID。多个本地接口ID的跟踪不匹配可能会在同一消息中报告。
The TraceMismatchAck message (Message Type 25) is used to acknowledge receipt of a TraceMismatch message. The format is as follows:
TraceMismatchAck消息（消息类型25）用于确认收到TraceMismatch消息。格式如下:
<TraceMismatchAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<TraceMismatchAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TraceMismatch message being acknowledged.
[RFC4204]中定义了消息\u ID\u ACK对象。消息\u ID\u ACK对象的内容必须从正在确认的TraceMiatch消息中获取。
The TraceReq message (Message Type 26) is sent over the control channel and is used to request the current trace value of a data link.
TraceReq消息（消息类型26）通过控制信道发送，用于请求数据链路的当前跟踪值。
<TraceReq Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE_REQ>
<TraceReq Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE_REQ>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The format of the TRACE_REQ object is as follows:
TRACE_REQ对象的格式如下：
Class = 22
Class = 22
O C-Type = 1, TraceReq
O C型=1，示踪物
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trace Type: 16 bits
跟踪类型：16位
Defined in Section 4.1.1.1.
定义见第4.1.1.1节。
Reserved: 16 bits
保留：16位
This field MUST be set to zero when sent and ignored when received
此字段在发送时必须设置为零，在接收时必须忽略
The TraceReport message (Message Type 27) is sent over the control channel after receiving a TraceReq message.
TraceReport消息（消息类型27）在接收到TraceReq消息后通过控制信道发送。
<TraceReport Message> ::= <Common Header> <MESSAGE_ID_ACK> <TRACE>
<TraceReport Message> ::= <Common Header> <MESSAGE_ID_ACK> <TRACE>
The TraceReport message MUST include a TRACE Object (as described in Section 4.1.1.1) for the requested data link.
TraceReport消息必须包括请求数据链路的跟踪对象（如第4.1.1.1节所述）。
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TraceReq message being acknowledged.
[RFC4204]中定义了消息\u ID\u ACK对象。消息\u ID\u ACK对象的内容必须从正在确认的TraceReq消息中获取。
The TraceReqNack message (Message Type 28) is sent over the control channel after receiving a TraceReq message.
TraceReqNack消息（消息类型28）在接收到TraceReq消息后通过控制信道发送。
<TraceReqNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
<TraceReqNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TraceReq message being acknowledged.
[RFC4204]中定义了消息\u ID\u ACK对象。消息\u ID\u ACK对象的内容必须从正在确认的TraceReq消息中获取。
The TraceReqNack message MUST include an ERROR_CODE Object (as defined in Section 4.1.3.1) for the requested data link.
TraceReqNack消息必须包含请求数据链路的错误代码对象（如第4.1.3.1节所定义）。
The InsertTrace message (Message Type 29) is sent over the control channel and is used to request a remote node to send a specific trace message over a data link (this assumes that the remote knows the mapping between the local and remote interface_Ids before fulfilling such request).
InsertTrace消息（消息类型29）通过控制通道发送，用于请求远程节点通过数据链路发送特定的跟踪消息（这假设远程节点在完成此类请求之前知道本地和远程接口ID之间的映射）。
The format is as follows:
格式如下:
<InsertTrace Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
<InsertTrace Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
A node that receives an InsertTrace message MUST respond with either an InsertTraceAck or an InsertTraceNack Message.
接收InsertTrace消息的节点必须使用InsertTraceAck或InsertTraceNack消息进行响应。
Once the InsertTraceAck message is received, the TraceMismatch message (see Section 4.1.4) is used to indicate a trace mismatch has occurred.
收到InsertTraceAck消息后，TraceMissMatch消息（见第4.1.4节）用于指示发生了跟踪不匹配。
The MESSAGE_ID_object is defined in [RFC4204].
[RFC4204]中定义了消息\u ID\u对象。
The InsertTraceAck message (Message Type 30) is used to acknowledge receipt of the InsertTrace message and indicate that the TRACE Object in the InsertTrace message has been received and processed correctly (i.e., no Trace Mismatch). The format is as follows:
InsertTraceAck消息（消息类型30）用于确认收到InsertTrace消息，并指示已正确接收和处理InsertTrace消息中的跟踪对象（即，没有跟踪不匹配）。格式如下:
<InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the InsertTrace message being acknowledged.
[RFC4204]中定义了消息\u ID\u ACK对象。消息\u ID\u ACK对象的内容必须从正在确认的InsertTrace消息中获取。
The InsertTraceNack message (Message Type 31) is used to acknowledge receipt of the InsertTrace message and to indicate that the TRACE Object in the InsertTrace message was not processed correctly. This could be because the trace monitoring requested is not supported or there was an error in the value.
InsertTraceNack消息（消息类型31）用于确认收到InsertTrace消息，并指示未正确处理InsertTrace消息中的跟踪对象。这可能是因为请求的跟踪监视不受支持或值中存在错误。
The format is as follows:
格式如下:
<InsertTraceNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
<InsertTraceNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The MESSAGE_ID_ACK object is defined in [RFC4204].
[RFC4204]中定义了消息\u ID\u ACK对象。
The InsertTraceNack message MUST include an ERROR_CODE Object (as defined in Section 4.1.3.1) for the requested data link.
InsertTraceNack消息必须包含请求数据链路的错误代码对象（如第4.1.3.1节所定义）。
LMP message security uses IPsec as described in [RFC4204]. This document introduces no other new security considerations not covered in [RFC4204].
LMP消息安全性使用IPsec，如[RFC4204]所述。本文档不介绍[RFC4204]中未涉及的其他新安全注意事项。
LMP [RFC4204] defines the following name spaces and how IANA can make assignments in those namespaces:
LMP[RFC4204]定义了以下名称空间以及IANA如何在这些名称空间中进行分配：
- LMP Message Type. - LMP Object Class. - LMP Object Class type (C-Type) unique within the Object Class. - LMP Sub-object Class type (Type) unique within the Object Class.
- LMP消息类型。-LMP对象类LMP对象类类型（C-type）在对象类中是唯一的。-LMP子对象类类型（类型）在对象类中是唯一的。
This memo introduces the following new assignments:
本备忘录介绍了以下新任务：
LMP Message Type:
LMP消息类型：
o TraceMonitor message (Message type = 21) o TraceMonitorAck message (Message type = 22)
o TraceMonitor消息（消息类型=21）o TraceMonitorAck消息（消息类型=22）
o TraceMonitorNack message (Message type = 23) o TraceMismatch message (Message type = 24) o TraceMismatchAck message (Message type = 25)
o TraceMonitorNack消息（消息类型=23）o TraceMismatch消息（消息类型=24）o TraceMismatch消息（消息类型=25）
o TraceReq message (Message type = 26) o TraceReport message (Message type = 27) o TraceReqNack message (Message type = 28)
o TraceReq消息（消息类型=26）o TracerReport消息（消息类型=27）o TraceReqNack消息（消息类型=28）
o InsertTrace message (Message type = 29) o InsertTraceAck message (Message type = 30) o InsertTraceNack message (Message type = 31)
o InsertTrace消息（消息类型=29）o InsertTraceAck消息（消息类型=30）o InsertTraceAck消息（消息类型=31）
LMP Object Class name space and Class type (C-Type):
LMP对象类名称空间和类类型（C类型）：
o TRACE Class name (21) - Type 1 (C-Type = 1)
o 跟踪类名（21）-类型1（C-Type=1）
o TRACE REQ Class name (22) - Type 1 (C-Type = 1)
o 跟踪请求类名（22）-类型1（C-Type=1）
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[G.707] ITU-T Recommendation G.707, "Network node interface for the synchronous digital hierarchy (SDH)," October 2000.
[G.707]ITU-T建议G.707，“同步数字体系（SDH）的网络节点接口”，2000年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]Lang，J.，Ed.，“链路管理协议（LMP）”，RFC4204，2005年10月。
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662]辛普森，W，“HDLC类框架中的PPP”，标准51，RFC1662，1994年7月。
[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月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[T1.105] T1.105, "Revised Draft T105 SONET Base Standard," January 2001.
[T1.105]T1.105，“T105 SONET基础标准修订草案”，2001年1月。
[RFC4206] Kompella, K., and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert Grammel, Jim Jones, Stefan Ansorge, John Drake, and James Scott for their many contributions to this document.
作者要感谢Bernard Sales、Emmanuel Desmet、Gert Grammel、Jim Jones、Stefan Ansorge、John Drake和James Scott对本文件的贡献。
We would also like to thank Greg Bernstein and Michiel van Everdingen for their insightful comments and for acting with a strong combination of toughness, professionalism, and courtesy.
我们还要感谢格雷格·伯恩斯坦（Greg Bernstein）和米切尔·范·埃弗丁根（Michiel van Everdingen），感谢他们富有洞察力的评论，感谢他们将强硬、专业和礼貌紧密结合在一起。
Authors' Addresses
作者地址
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101
Jonathan P.Lang Sonos，Inc.加利福尼亚州圣巴巴拉市东格拉街223号，邮编93101
EMail: jplang@ieee.org
EMail: jplang@ieee.org
Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen, Belgium
迪米特里·帕帕迪米特里奥·阿尔卡特弗朗西斯·韦勒斯普林1 B-2018比利时安特卫普
EMail: dimitri.papadimitriou@alcatel.be
EMail: dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。