Network Working Group M. Foschiano
Request for Comments: 5171 Cisco Systems
Category: Informational April 2008
Network Working Group M. Foschiano
Request for Comments: 5171 Cisco Systems
Category: Informational April 2008
Cisco Systems UniDirectional Link Detection (UDLD) Protocol
Cisco系统单向链路检测（UDLD）协议
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅RFC 3932。
Abstract
摘要
This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms.
本文档描述了Cisco Systems协议，该协议可用于检测和禁用单向以太网光纤或铜缆链路，例如，由光纤束布线错误、接口故障、媒体转换器故障等引起的链路。该协议与IEEE 802.3现有的第1层故障检测机制一起在第2层运行。
This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization.
本文档解释了协议目标和应用，说明了协议所基于的特定前提，并描述了协议体系结构和相关部署问题，以作为未来标准化的可能基础。
Table of Contents
目录
1. Introduction ....................................................2
2. Protocol Objectives and Applications ............................3
3. Protocol Design Premises ........................................4
4. Protocol Background .............................................4
5. Protocol Architecture ...........................................5
5.1. The Basics .................................................5
5.2. Neighbor Database Maintenance ..............................5
5.3. Event-driven Detection and Echoing .........................6
5.4. Event-based versus Event-less Detection ....................6
6. Packet Format ...................................................7
6.1. TLV Description ............................................9
7. Protocol Logic .................................................10
7.1. Protocol Timers ...........................................10
8. Comparison with Bidirectional Forwarding Detection .............11
9. Security Considerations ........................................11
10. Deployment Considerations .....................................11
11. Normative References ..........................................12
12. Informative Reference .........................................12
1. Introduction ....................................................2
2. Protocol Objectives and Applications ............................3
3. Protocol Design Premises ........................................4
4. Protocol Background .............................................4
5. Protocol Architecture ...........................................5
5.1. The Basics .................................................5
5.2. Neighbor Database Maintenance ..............................5
5.3. Event-driven Detection and Echoing .........................6
5.4. Event-based versus Event-less Detection ....................6
6. Packet Format ...................................................7
6.1. TLV Description ............................................9
7. Protocol Logic .................................................10
7.1. Protocol Timers ...........................................10
8. Comparison with Bidirectional Forwarding Detection .............11
9. Security Considerations ........................................11
10. Deployment Considerations .....................................11
11. Normative References ..........................................12
12. Informative Reference .........................................12
Today's Ethernet-based switched networks often rely on the Spanning Tree Protocol (STP) defined in the IEEE 802.1D standard [1] to create a loop-free topology that is used to forward the traffic from a source to a destination based on the Layer 2 packet information learned by the switches and on the knowledge of the status of the physical links along the path.
今天基于以太网的交换网络通常依赖于IEEE 802.1D标准[1]中定义的生成树协议（STP）创建一个无环路拓扑，该拓扑用于根据交换机学习到的第2层数据包信息以及对路径上物理链路状态的了解，将流量从源转发到目的地。
Issues arise when, due to mis-wirings or to hardware faults, the communication path behaves abnormally and generates forwarding anomalies. The simplest example of such anomalies is the case of a bidirectional link that stops passing traffic in one direction and therefore breaks one of the most basic assumptions that high-level protocols typically depend upon: reliable two-way communication between peers.
当由于接线错误或硬件故障，通信路径行为异常并产生转发异常时，会出现问题。这种异常现象最简单的例子是双向链路停止在一个方向上传递流量，因此打破了高级协议通常依赖的最基本假设之一：对等方之间的可靠双向通信。
The purpose of the UDLD protocol is to detect the presence of anomalous conditions in the Layer 2 communication channel, while relying on the mechanisms defined by the IEEE in the 802.3 standard [2] to properly handle conditions inherent to the physical layer.
UDLD协议的目的是检测第2层通信信道中是否存在异常条件，同时依靠IEEE在802.3标准[2]中定义的机制来正确处理物理层固有的条件。
The UniDirectional Link Detection protocol (often referred to in short as "UDLD") is a lightweight protocol that can be used to detect and disable one-way connections before they create dangerous situations such as Spanning Tree loops or other protocol malfunctions.
单向链路检测协议（通常简称为“UDLD”）是一种轻量级协议，可用于在单向连接造成危险情况（如生成树循环或其他协议故障）之前检测和禁用单向连接。
The protocol's main goal is to advertise the identities of all the capable devices attached to the same LAN segment and to collect the information received on the ports of each device to determine if the Layer 2 communication is happening in the appropriate fashion.
该协议的主要目标是公布连接到同一LAN段的所有有能力设备的身份，并收集每个设备端口上接收到的信息，以确定第2层通信是否以适当的方式进行。
In a network that has an extensive fiber cabling plant, problems may arise when incorrect patching causes a switch port to have its RX fiber strand connected to one neighbor port and its TX fiber strand connected to another. In these cases, a port may be deemed active if it is receiving an optical signal on its RX strand. However, the problem is that this link does not provide a valid communication path at Layer 2 (and above).
在具有广泛光纤布线设备的网络中，如果不正确的配线导致交换机端口将其RX光纤串连接到一个相邻端口，将其TX光纤串连接到另一个端口，则可能会出现问题。在这些情况下，如果某个端口在其RX串上接收到光信号，则该端口可能被视为处于活动状态。但是，问题是该链路在第2层（及以上）没有提供有效的通信路径。
If this scenario of wrongly connected fiber strands is applied to multiple ports to create a fiber loop, each device in the loop could directly send packets to a neighbor but would not be able to receive from that neighbor.
如果将这种错误连接的光纤绞线应用于多个端口以创建光纤环路，环路中的每个设备都可以直接向邻居发送数据包，但无法从该邻居接收数据包。
Albeit the above scenario is rather extreme, it exemplifies how the lack of mutual identification of the neighbors can bring protocols to the wrong assumption that during a transmission the sender and the receiver are always properly matched. Another equally dangerous incorrect assumption is that the lack of reception of protocol messages on a port unmistakably indicates the absence of transmitting protocol entities at the other end of the link.
尽管上述场景相当极端，但它举例说明了缺乏邻居的相互识别如何导致协议错误地假设在传输过程中发送方和接收方始终正确匹配。另一个同样危险的错误假设是，端口上没有接收到协议消息，这无疑表明链路另一端没有传输协议实体。
The UDLD protocol was implemented to help correct certain assumptions made by other protocols, and in particular to help the Spanning Tree Protocol to function properly so as to avoid the creation of dangerous Layer 2 loops. It has been available on most Cisco Systems switches for several years and is now part of numerous network design best practices.
UDLD协议的实施有助于纠正其他协议做出的某些假设，尤其是帮助生成树协议正常运行，从而避免创建危险的第2层循环。它已经在大多数Cisco系统交换机上使用了好几年，现在是众多网络设计最佳实践的一部分。
The current implementation of UDLD is based on the following considerations/presuppositions:
UDLD的当前实施基于以下考虑/前提：
o The protocol would have to be run in the control plane of a network device to be flexible enough to support upgrades and bug fixes. The control plane speed would ultimately be the limiting factor to the capability of fast fault detection of the protocol (CPU speed, task switching speed, event processing speed, etc.). The transmission medium's propagation delay at 10 Mbps speed (or higher) would instead be considered a negligible factor.
o 该协议必须在网络设备的控制平面上运行，才能足够灵活地支持升级和错误修复。控制平面速度最终将成为协议快速故障检测能力的限制因素（CPU速度、任务切换速度、事件处理速度等）。传输介质在10 Mbps（或更高）速度下的传播延迟将被视为可忽略的因素。
o Network events typically do not happen with optimal timing, but rather at the speed determined by the software/firmware infrastructure that controls them. (For psychological and practical reasons, developers tend to choose round timer values rather than determine the optimal value for the specific software architecture in use. Also, software bugs, coding oversights, slow process switching, implementation overhead can all affect the control plane responsiveness and event timings.) Hence it was deemed necessary to adopt a conservative protocol design to minimize false positives during the detection process.
o 网络事件通常不会以最佳时间发生，而是以控制它们的软件/固件基础结构确定的速度发生。（出于心理和实际原因，开发人员倾向于选择循环计时器值，而不是确定所使用的特定软件体系结构的最佳值。此外，软件缺陷、编码失误、缓慢的进程切换、实现开销都会影响控制平面的响应性和事件计时。）因此，有必要采用保守的协议设计，以尽量减少检测过程中的误报。
o If a fault were discovered, it was assumed that the user would want to keep the faulty port down for a predetermined amount of time to avoid unnecessary port state flapping. For that reason, a time-based fault recovery mechanism was provided (although alternative recovery mechanisms are not implicitly precluded by the protocol itself).
o 如果发现故障，则假定用户希望将故障端口关闭预定时间，以避免不必要的端口状态摆动。为此，提供了一种基于时间的故障恢复机制（尽管协议本身并未隐含排除替代恢复机制）。
UDLD is meant to be a Layer 2 detection protocol that works on top of the existing Layer 1 detection mechanisms defined by the IEEE standards. For example, the Far End Fault Indication (FEFI) function for 100BaseFX interfaces and the Auto-Negotiation function for 100BaseTX/1000BaseX interfaces represent standard physical-layer mechanisms to determine if the transmission media is bidirectional. (Please see sections 24.3.2.1 and 28.2.3.5 of [2] for more details.) The typical case of a Layer 1 "fault" indication is the "loss of light" indication.
UDLD是一种第2层检测协议，它在IEEE标准定义的现有第1层检测机制之上工作。例如，100BaseFX接口的远端故障指示（FEFI）功能和100BaseTX/1000BaseX接口的自动协商功能代表标准物理层机制，用于确定传输介质是否为双向的。（有关更多详细信息，请参见[2]第24.3.2.1节和第28.2.3.5节。）第1层“故障”指示的典型情况是“失光”指示。
UDLD differs from the above-mentioned mechanisms insofar as it performs mutual neighbor identification; in addition, it performs neighbor acknowledgement on top of the Logical Link Control (LLC)
UDLD不同于上述机制，因为它执行相互邻居识别；此外，它在逻辑链路控制（LLC）的基础上执行邻居确认
layer and thus is able to discover logical one-way miscommunication between neighbors even when either one of the said PHY layer mechanisms has deemed the transmission medium bidirectional.
因此，即使当所述PHY层机制之一认为传输介质是双向的时，也能够发现邻居之间的逻辑单向错误通信。
UDLD uses two basic mechanisms:
UDLD使用两种基本机制：
a. It advertises a port's identity and learns about its neighbors on a specific LAN segment; it keeps the acquired information on the neighbors in a cache table.
a. 它宣传端口的身份，并了解其在特定LAN段上的邻居；它将获取的邻居信息保存在缓存表中。
b. It sends a train of echo messages in certain circumstances that require fast notifications or fast resynchronization of the cached information.
b. 在需要快速通知或快速重新同步缓存信息的特定情况下，它会发送一系列回显消息。
Because of the above, the algorithm run by UDLD requires that all the devices connected to the same LAN segment be running the protocol in order for a potential misconfiguration to be detected and for a prompt corrective action to be taken.
由于上述原因，UDLD运行的算法要求连接到同一LAN段的所有设备都运行该协议，以便检测到潜在的错误配置并及时采取纠正措施。
UDLD sends periodical "hello" packets (also called "advertisements" or "probes") on every active interface to keep each device informed about its neighbors. When a hello message is received, it is cached and kept in memory at most for a defined time interval, called "holdtime" or "time-to-live", after which the cache entry is considered stale and is aged out.
UDLD在每个活动接口上定期发送“hello”数据包（也称为“广告”或“探测”），以使每个设备了解其邻居。当接收到hello消息时，它将被缓存并最多在内存中保留一个定义的时间间隔，称为“holdtime”或“生存时间”，在此时间间隔之后，缓存项将被视为过时并过期。
If a new hello message is received when a correspondent old cache entry has not been aged out yet, then the old entry is dropped and is replaced by the new one with a reset time-to-live timer. Whenever an interface gets disabled and UDLD is running, or whenever UDLD is disabled on an interface, or whenever the device is reset, all existing cache entries for the interfaces affected by the configuration change are cleared, and UDLD sends at least one message to inform the neighbors to flush the part of their caches also affected by the status change. This mechanism is meant to keep the caches coherent on all the connected devices.
如果在对应的旧缓存条目尚未过期时收到新的hello消息，则旧条目将被丢弃，并由具有重置生存时间计时器的新条目替换。当接口被禁用且UDLD正在运行时，或当接口上的UDLD被禁用时，或当设备被重置时，受配置更改影响的接口的所有现有缓存项都将被清除，UDLD发送至少一条消息，通知邻居刷新其缓存中也受状态更改影响的部分。此机制旨在保持所有连接设备上的缓存一致。
The echoing mechanism is the base of UDLD's detection algorithm: whenever a UDLD device learns about a new neighbor or receives a resynchronization request from an out-of-synch neighbor, it (re)starts the detection process on its side of the connection and sends N echo messages in reply. (This mechanism implicitly assumes that N packets are sufficient to get through a link and reach the other end, even though some of them might get dropped during the transmission.)
回显机制是UDLD检测算法的基础：每当UDLD设备了解到新邻居或接收到来自不同步邻居的重新同步请求时，它（重新）在其连接端启动检测过程，并发送N条回显消息作为响应。（该机制隐含地假设N个数据包足以通过链路到达另一端，即使其中一些数据包可能在传输过程中丢失。）
Since this behavior must be the same on all the neighbors, the sender of the echoes expects to receive (after some time) an echo in reply. If the detection process ends without the proper echo information being received, and under specific conditions, the link is considered to be unidirectional.
由于所有邻居的行为都必须相同，因此回音的发送者希望（在一段时间后）收到回音作为回应。如果检测过程在没有接收到正确的回波信息的情况下结束，并且在特定条件下，链路被认为是单向的。
UDLD can function in two modes: normal mode and aggressive mode.
UDLD可以在两种模式下工作：正常模式和攻击模式。
In normal mode, a protocol determination at the end of the detection process is always based on information received in UDLD messages: whether it's the information about the exchange of proper neighbor identifications or the information about the absence of such proper identifications. Hence, albeit bound by a timer, normal mode determinations are always based on gleaned information, and as such are "event-based". If no such information can be obtained (e.g., because of a bidirectional loss of connectivity), UDLD follows a conservative approach based on the considerations in Section 3 and deems a port to be in "undetermined" state. In other words, normal mode will shut down a port only if it can explicitly determine that the associated link is faulty for an extended period of time.
在正常模式下，检测过程结束时的协议确定始终基于UDLD消息中接收到的信息：是关于正确邻居标识交换的信息，还是关于缺少此类正确标识的信息。因此，尽管受到计时器的限制，正常模式确定始终基于收集的信息，因此是“基于事件的”。如果无法获得此类信息（例如，由于双向连接丢失），UDLD将根据第3节中的考虑采用保守方法，并将端口视为处于“待定”状态。换句话说，只有当正常模式能够明确地确定相关链路在较长时间内出现故障时，它才会关闭端口。
In contrast, in aggressive mode, UDLD will also shut down a port if it loses bidirectional connectivity with the neighbor for the same extended period of time mentioned above and subsequently fails repeated last-resort attempts to re-establish communication with the other end of the link. This mode of operation assumes that loss of communication with the neighbor is a meaningful network event in itself and is a symptom of a serious connectivity problem. Because this type of detection can be event-less, and lack of information cannot always be associated to an actual malfunction of the link, this mode is optional and is recommended only in certain scenarios (typically only on point-to-point links where no communication failure between two neighbors is admissible).
相反，在主动模式下，如果UDLD在上述相同的延长时间内失去与邻居的双向连接，并且随后失败了与链路另一端重新建立通信的重复最后尝试，UDLD也将关闭端口。此操作模式假定与邻居失去通信本身就是一个有意义的网络事件，是严重连接问题的症状。因为这种类型的检测可以是无事件的，并且信息的缺乏并不总是与链路的实际故障相关联，所以这种模式是可选的，并且仅在某些情况下推荐使用（通常仅在两个邻居之间不允许通信故障的点对点链路上）。
The UDLD protocol runs on top of the LLC sub-layer of the data link layer of the OSI model. It uses a specially assigned multicast destination MAC address and encapsulates its messages using the standard Subnetwork Access Protocol (SNAP) format as described in the following:
UDLD协议运行在OSI模型数据链路层的LLC子层之上。它使用专门分配的多播目标MAC地址，并使用标准子网访问协议（SNAP）格式封装其消息，如下所述：
Destination MAC address 01-00-0C-CC-CC-CC
目标MAC地址01-00-0C-CC-CC-CC
UDLD SNAP format: LLC value 0xAAAA03 Org Id 0x00000C HDLC protocol type 0x0111
UDLD快照格式：LLC值0xAAAA03组织Id 0x00000C HDLC协议类型0x0111
UDLD's Protocol Data Unit (PDU) format is as follows:
UDLD的协议数据单元（PDU）格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Opcode | Flags | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of TLVs (variable length list) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Opcode | Flags | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of TLVs (variable length list) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV format is the basic one described below:
TLV格式是如下所述的基本格式：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16 bits): If an implementation does not understand a Type value, it should skip over it using the length field.
类型（16位）：如果实现不理解类型值，它应该使用长度字段跳过它。
Length (16 bits): Length in bytes of the Type, Length, and Value fields. In order for this field value to be valid, it should be greater than or equal to the minimum allowed length, 4 bytes. If the value is less than the minimum, the whole packet is to be considered corrupted and therefore it must be discarded right away during the parsing process. TLVs should not be split across packet boundaries.
长度（16位）：类型、长度和值字段的长度（字节）。为使此字段值有效，它应大于或等于允许的最小长度4字节。如果该值小于最小值，则认为整个数据包已损坏，因此必须在解析过程中立即丢弃该数据包。TLV不应跨数据包边界拆分。
Value (variable length): Object contained in the TLV.
值（可变长度）：TLV中包含的对象。
The protocol header fields are defined as follows:
协议头字段定义如下：
Ver (3 bits): 0x01: UDLD PDU version number
版本（3位）：0x01:UDLD PDU版本号
Opcode (5 bits): 0x00: Reserved 0x01: Probe message 0x02: Echo message 0x03: Flush message 0x04-0x1F: Reserved for future use
操作码（5位）：0x00:保留0x01:探测消息0x02:回显消息0x03:刷新消息0x04-0x1F:保留供将来使用
Flags (8 bits): bit 0: Recommended timeout flag (RT) bit 1: ReSynch flag (RSY) bit 2-7: Reserved for future use
标志（8位）：位0：建议的超时标志（RT）位1：重新同步标志（RSY）位2-7：保留供将来使用
PDU Checksum (16 bits): IP-like checksum. Take the one's complement of the one's complement sum (with the modification that the odd byte at the end of an odd length message is used as the low 8 bits of an extra word, rather than as the high 8 bits.) NB: All UDLD implementations must comply with this specification.
PDU校验和（16位）：类似IP的校验和。取1的补码和1的补码（修改为奇数长度消息末尾的奇数字节用作额外字的低8位，而不是高8位。）NB：所有UDLD实现必须符合本规范。
The list of currently defined TLVs comprises:
当前定义的TLV列表包括：
Name Type Value format
名称类型值格式
Device-ID TLV 0x0001 ASCII character string Port-ID TLV 0x0002 ASCII character string Echo TLV 0x0003 List of ID pairs Message Interval TLV 0x0004 8-bit unsigned integer Timeout Interval TLV 0x0005 8-bit unsigned integer Device Name TLV 0x0006 ASCII character string Sequence Number TLV 0x0007 32-bit unsigned integer Reserved TLVs > 0x0007 Format unknown. To be skipped by parsing routine.
设备ID TLV 0x0001 ASCII字符串端口ID TLV 0x0002 ASCII字符串回显TLV 0x0003 ID对列表消息间隔TLV 0x0004 8位无符号整数超时间隔TLV 0x0005 8位无符号整数设备名称TLV 0x0006 ASCII字符串序列号TLV 0x0007 32位无符号整数保留TLV>0x0007格式未知的将被解析例程跳过。
Device-ID TLV:
设备ID TLV:
This TLV uniquely identifies the device that is sending the UDLD packet. The TLV length field determines the length of the carried identifier and must be greater than zero. In version 1 of the protocol, the lack of this ID is considered a symptom of packet corruption that implies that the message is invalid and must be discarded.
此TLV唯一标识发送UDLD数据包的设备。TLV长度字段确定所携带标识符的长度，并且必须大于零。在协议的版本1中，缺少此ID被视为数据包损坏的症状，这意味着消息无效，必须丢弃。
Port-ID TLV:
端口ID TLV：
This TLV uniquely identifies the physical port the UDLD packet is sent on. The TLV length field determines the length of the carried identifier and must be greater than zero. In version 1 of the protocol, the lack of this ID is considered a symptom of packet corruption that implies that the message is invalid and must be discarded.
此TLV唯一标识发送UDLD数据包的物理端口。TLV长度字段确定所携带标识符的长度，并且必须大于零。在协议的版本1中，缺少此ID被视为数据包损坏的症状，这意味着消息无效，必须丢弃。
Echo TLV:
回波TLV：
This TLV contains the list of valid DeviceID/PortID pairs received by a port from all its neighbors. If either one of the identifiers in a pair is corrupted, the message will be ignored. This list includes only DeviceIDs and PortIDs extracted from UDLD messages received and cached on the same interface on which this TLV is sent. If no UDLD messages are received, then this TLV is sent containing zero pairs. Despite its name, this TLV must be present in both probe and echo messages, whereas in flush messages it's not required.
此TLV包含端口从其所有邻居接收的有效DeviceID/PortID对的列表。如果一对中的任何一个标识符损坏，消息将被忽略。此列表仅包括从发送此TLV的同一接口上接收和缓存的UDLD消息中提取的DeviceID和PortID。如果未收到UDLD消息，则发送此TLV时包含零对。尽管名称不同，该TLV必须同时出现在探测和回送消息中，而在刷新消息中则不需要。
Message Interval TLV:
消息间隔TLV：
This required TLV contains the 8-bit time interval value used by a neighbor to send UDLD probes after the linkup or detection phases. Its time unit is 1 second. The holdtime of a cache item for a received message is calculated as (advertised-message-interval x R), where R is a constant called "TTL to message interval ratio".
此所需TLV包含8位时间间隔值，邻居用于在连接或检测阶段后发送UDLD探测。它的时间单位是1秒。已接收消息的缓存项的保持时间计算为（播发消息间隔x R），其中R是一个称为“TTL与消息间隔比率”的常数。
Timeout Interval TLV:
超时间隔TLV：
This optional TLV contains the 8-bit timeout interval value (T) used by UDLD to decide the basic length of the detection phase. Its time unit is 1 second. If it's not present in an advertisement, T is assumed to be a hard-coded constant.
此可选TLV包含UDLD用于确定检测阶段基本长度的8位超时间隔值（T）。它的时间单位是1秒。如果它在广告中不存在，则假定T为硬编码常数。
Device Name TLV:
设备名称TLV:
This required TLV is meant to be used by the CLI or SNMP and typically contains the user-readable device name string.
此必需的TLV用于CLI或SNMP，通常包含用户可读的设备名称字符串。
Sequence Number TLV:
序列号TLV：
The purpose of this optional TLV is to inform the neighbors of the sequence number of the current message being transmitted. A counter from 1 to 2^32-1 is supposed to keep track of the sequence number; it is reset whenever a transition of phase occurs so that it will restart counting from one, for instance, whenever an echo message sequence is initiated, or whenever a linkup message train is triggered.
此可选TLV的目的是通知邻居当前正在传输的消息的序列号。一个从1到2^32-1的计数器用来跟踪序列号；无论何时发生相位转换，它都会重置，以便从一开始重新开始计数，例如，无论何时启动回声消息序列，还是无论何时触发链接消息序列。
No wraparound of the counter is supposed to happen.
不应该对计数器进行概括。
The zero value is reserved and can be used as a representation of a missing or invalid sequence number by the user interface. Therefore, the TLV should never contain zero. (NB: The use of this TLV is currently limited only to informational purposes.)
零值是保留的，用户界面可以将其用作缺失或无效序列号的表示。因此，TLV不应包含零。（注意：本TLV的使用目前仅限于提供信息。）
UDLD's protocol logic relies on specific internal timers and is sensitive to certain network events.
UDLD的协议逻辑依赖于特定的内部计时器，并且对某些网络事件敏感。
The type of messages that UDLD transmits and the timing intervals that it uses are dependent upon the internal state of the protocol, which changes based on network events such as:
UDLD传输的消息类型及其使用的时间间隔取决于协议的内部状态，该状态根据网络事件而变化，例如：
o Link up o Link down o Protocol enabled o Protocol disabled o New neighbor discovery o Neighbor state change o Neighbor resynchronization requests
o 上链o下链o协议启用o协议禁用o新邻居发现o邻居状态更改o邻居重新同步请求
UDLD timer values could vary within certain "safety" ranges based on the considerations in Section 3. However, in practice, in the current implementation, timers use only certain values verified during testing. Their time unit is one second.
根据第3节中的注意事项，UDLD定时器值可能在某些“安全”范围内变化。然而，在实践中，在当前的实现中，计时器仅使用在测试期间验证的特定值。他们的时间单位是一秒。
During the detection phase, messages are exchanged at the maximum possible rate of one per second. After that, if the protocol reaches
在检测阶段，消息以每秒一个的最大可能速率交换。之后，如果协议达到
a stable state and can make a certain determination on the "bidirectionality" of the link, the message interval is increased to a configurable value based on a curve known as M1(t), a time-based function.
一种稳定状态，并且可以对链路的“双向性”做出一定的确定，消息间隔增加到基于称为M1（t）的曲线（一种基于时间的函数）的可配置值。
In case the link is deemed anything other than bidirectional at the end of the detection, this curve is a flat line with a fixed value of Mfast (7 seconds in the current implementation).
如果在检测结束时认为链路不是双向的，则该曲线是具有固定值Mfast（在当前实现中为7秒）的平坦线。
In case the link is instead deemed bidirectional, the curve will use Mfast for the first 4 subsequent message transmissions and then will transition to an Mslow value for all other steady-state transmissions. Mslow can be either a fixed value (60 seconds in some obsolete implementations) or a user-configurable value (between Mfast and 90 seconds with a default of 15 seconds in the current implementations).
如果该链路被认为是双向的，则该曲线将在随后的前4次消息传输中使用Mfast，然后将在所有其他稳态传输中转换为Mslow值。Mslow可以是一个固定值（在某些过时的实现中为60秒），也可以是一个用户可配置的值（在Mfast和90秒之间，在当前实现中为默认值15秒）。
Similarly to UDLD, the Bidirectional Forwarding Detection (BFD) [3] protocol is intended to detect faults in the path between two network nodes. However, BFD is supposed to operate independently of media, data protocols, and routing protocols. There is no address discovery mechanism in BFD, which is left to the application to determine.
与UDLD类似，双向转发检测（BFD）[3]协议旨在检测两个网络节点之间路径中的故障。然而，BFD应该独立于媒体、数据协议和路由协议运行。BFD中没有地址发现机制，由应用程序决定。
On the other hand, UDLD works exclusively on top of a L2 transport supporting the SNAP encapsulation and operates independently of the other bridge protocols (UDLD's main "applications"), with which it has limited interaction. It also performs full neighbor discovery on point-to-point and point-to-multipoint media.
另一方面，UDLD只在支持SNAP封装的L2传输之上工作，并且独立于其他网桥协议（UDLD的主要“应用程序”）运行，它与其他网桥协议的交互有限。它还可以在点对点和点对多点介质上执行完全邻居发现。
In a heterogeneous Layer 2 network that is built with different models of network devices or with devices running different software images, the UDLD protocol should be supported and configured on all ports interconnecting said devices in order to achieve a complete coverage of its detection process. Note that UDLD is not supposed to be used on ports connected to untrusted devices or incapable devices; hence, it should be disabled on such ports.
在使用不同型号的网络设备或运行不同软件映像的设备构建的异构第2层网络中，UDLD协议应在连接所述设备的所有端口上得到支持和配置，以实现其检测过程的完全覆盖。请注意，UDLD不应用于连接到不受信任的设备或无能力设备的端口；因此，应在此类端口上禁用它。
Cisco Systems has supported the UDLD protocol in its Catalyst family of switches since 1999.
自1999年以来，Cisco Systems在其Catalyst系列交换机中支持UDLD协议。
[1] IEEE 802.1D-2004 Standard -- Media access control (MAC) Bridges
[1] IEEE 802.1D-2004标准——媒体访问控制（MAC）网桥
[2] IEEE 802.3-2002 IEEE Standard -- Local and metropolitan area networks Specific requirements--Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications
[2] IEEE 802.3-2002 IEEE标准局域网和城域网特定要求第3部分：带冲突检测的载波侦听多址（CSMA/CD）接入方法和物理层规范
[3] Katz, D., and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, March 2008.
[3] Katz，D.和D.Ward，“双向转发检测”，正在进行的工作，2008年3月。
Author's Address
作者地址
Marco Foschiano Cisco Systems, Inc. Via Torri Bianche 7, 20059 Vimercate (Mi) Italy
Marco Foschiano Cisco Systems，Inc.通过Torri Bianche 7，20059 Vimercate（密歇根州）意大利
EMail: foschia@cisco.com
EMail: foschia@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和http://www.rfc-editor.org/copyright.html，除本协议另有规定外，提交人保留其所有权利。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.