[要約] RFC 5171は、Cisco SystemsのUniDirectional Link Detection（UDLD）プロトコルに関する規格です。UDLDは、ネットワーク上の単方向リンクを検出し、問題を解決するために設計されています。
Network Working Group M. Foschiano
Request for Comments: 5171 Cisco Systems
Category: Informational April 2008
Cisco Systems UniDirectional Link Detection (UDLD) Protocol
Cisco Systems単方向リンク検出（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システムプロトコルについて説明します。レイヤー2で動作します。IEEE 802.3の既存のレイヤー1障害検出メカニズムと結合します。
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
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通信チャネル内の異常な条件の存在を検出することですが、802.3標準[2]でIEEEによって定義されたメカニズムに依存して、物理層に固有の条件を適切に処理します。
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 Systems Switchesで数年間利用可能であり、現在では多数のネットワークデザインのベストプラクティスの一部です。
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は、IEEE標準で定義された既存のレイヤー1検出メカニズムの上で機能するレイヤー2検出プロトコルであることを意図しています。たとえば、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) 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.
UDLDは、相互の隣人の識別を実行する限り、上記のメカニズムとは異なります。さらに、論理リンクコントロール（LLC）レイヤーの上に近隣の承認を実行するため、PHY層のメカニズムのいずれかが透過媒体の双方向とみなされた場合でも、隣人間の論理的な一方向の誤解を発見することができます。
UDLD uses two basic mechanisms:
UDLDは2つの基本的なメカニズムを使用します。
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」または「Time Time」と呼ばれる定義された時間間隔で、キャッシュされてメモリに保持されます。その後、キャッシュエントリは古く見なされ、老化します。
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は少なくとも1つのメッセージを送信します。隣人は、ステータスの変化の影響を受けたキャッシュの一部を洗い流します。このメカニズムは、接続されたすべてのデバイスにキャッシュを首尾一貫させることを目的としています。
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は、通常モードとアグレッシブモードの2つのモードで機能します。
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は、上記の同じ長期間にわたって隣人との双方向接続性を失い、その後、繰り返しリゾートの試みを繰り返し回復させようとする場合、ポートをシャットダウンします。リンク。この操作モードは、隣人との通信の喪失はそれ自体が意味のあるネットワークイベントであり、深刻な接続性の問題の症状であると想定しています。このタイプの検出はイベントなしであり、情報の不足が常にリンクの実際の誤動作に関連付けられるとは限らないため、このモードはオプションであり、特定のシナリオでのみ推奨されます（通常はポイントツーポイントリンクでのみ、2人の隣人間のコミュニケーションの障害は許容されます）。
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'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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Ver（3ビット）：0x01：UDLD PDUバージョン番号
Opcode (5 bits): 0x00: Reserved 0x01: Probe message 0x02: Echo message 0x03: Flush message 0x04-0x1F: Reserved for future use
opcode（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のようなチェックサム。補完的な合計を補完します（奇数の長さのメッセージの終わりにある奇妙なバイトが、高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.
Device-ID TLV:
Device-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とPORTIDSのみが含まれます。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には、リンクアップまたは検出フェーズの後にUDLDプローブを送信するために近隣が使用する8ビット時間間隔値が含まれています。その時間単位は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のカウンターは、シーケンス番号を追跡することになっています。たとえば、エコーメッセージシーケンスが開始されるたびに、またはLinkupメッセージトレインがトリガーされるたびにカウントを再起動するように、位相の遷移が発生するたびにリセットされます。
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にゼロを含めることはできません。（NB：この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.
UDLDタイマーの値は、セクション3の考慮事項に基づいて、特定の「安全」範囲内で異なる場合があります。ただし、実際には、現在の実装では、タイマーはテスト中に確認された特定の値のみを使用します。彼らの時間単位は1秒です。
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.
検出段階では、メッセージは1秒あたり1秒の最大レートで交換されます。その後、プロトコルが安定した状態に到達し、リンクの「双方向性」を特定の決定を行うことができる場合、メッセージ間隔は、時間ベースの関数である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]プロトコルは、2つのネットワークノード間のパスの障害を検出することを目的としています。ただし、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.
Cisco Systemsは、1999年以来、触媒スイッチファミリーでUDLDプロトコルをサポートしています。
[1] IEEE 802.1D-2004 Standard -- Media access control (MAC) Bridges
[1] IEEE 802.1D-2004 Standard-Media Access Control（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。
EMail: foschia@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。