Network Working Group M. Foschiano
Request for Comments: 5171 Cisco Systems
Category: Informational April 2008
Cisco Systems UniDirectional Link Detection (UDLD) Protocol
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はインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、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.
この文書では生じ、例えば、それは、レイヤ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.
今日のイーサネットベースのスイッチドネットワークは、多くの場合に依存しているレイヤに基づいて送信元から宛先へのトラフィックを転送するために使用されるループフリートポロジを作成するために、[1] IEEE 802.1D規格で定義されたスパニングツリープロトコル（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.
誤配線またはハードウェア障害のために、通信経路が異常動作し、転送異常を生成するとき、問題が生じます。そのような異常の最も簡単な例は、1つの方向にトラフィックを渡すことを停止し、双方向リンクの場合であるため、ハイレベルのプロトコルは、典型的に依存する最も基本的な前提の一つ破壊：ピアとの間の信頼できる双方向通信。
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プロトコルの目的は、物理レイヤに固有802.3標準[2]適切に処理するための条件でIEEEによって定義されたメカニズムに依存しながら、レイヤ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セグメントに接続されているすべての可能なデバイスのIDをアドバタイズすると、レイヤ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).
間違ったパッチ適用が一つの隣接ポートと別に接続されたTX繊維ストランドに接続されたRX繊維ストランドを持つように、スイッチポートを起こしたときに大規模なファイバーケーブルの工場を持っているネットワークでは、問題が発生する可能性があります。それは、その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のスイッチで利用され、現在、多くのネットワーク設計のベストプラクティスの一環でいます。
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速度、タスク切り替え速度、イベント処理速度、等）の能力に制限要因であろう。 10Mbpsの速度（またはそれ以上）での伝送媒体の伝播遅延ではなく、無視できる要因と考えられます。
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検出プロトコルであることを意味しています。例えば、100BaseTXの/の1000BaseXインターフェイス用の100BaseFXインターフェイスの遠端障害表示（FEFI）機能とオートネゴシエーション機能は、伝送媒体が双方向であるかどうかを決定するために、標準的な物理レイヤ・メカニズムを表します。 （詳細については[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メッセージが受信されると、キャッシュエントリが古くなったとみなされ、エージアウトされた後、「ホールドタイム」または「生存時間」と呼ばれ、定義された時間間隔のために最大でキャッシュされ、メモリに保持されます。
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 SNAP形式：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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビット）：実装はType値を理解していない場合は、長さフィールドを使用して、それをスキップする必要があります。
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ビット）：0×01：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：Probeメッセージ0×02：エコーメッセージ0x03の：Flushメッセージ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のようなチェックサム。 NB（奇数長のメッセージの末尾に奇数バイトがかなり高い8ビットとしてよりも、余分なワードの下位8ビットとして使用される変更で）1の補数和の1の補数を取る：すべての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文字列のPort-ID TLV 0×0002 ASCII文字列エコーTLV IDのペアの0x0003一覧メッセージインターバル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は、すべての隣国からのポートで受信した有効なデバイスID / PORTIDのペアのリストが含まれています。ペアの識別子のいずれかが破損している場合は、メッセージは無視されます。このリストには、このTLVが送信されているのと同じインターフェイス上で受信し、キャッシュされたUDLDメッセージから抽出されただけDeviceIDsと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のカウンタは、シーケンス番号を追跡することになっています。それは、エコーメッセージシーケンスが開始されるたびに、またはリンクアップメッセージ列車がトリガされるたびに、例えば、一方から数えて再起動するように相転移が発生するたびに、それがリセットされます。
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ネイバーの状態変更0隣人の再同期要求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.
検出フェーズ中に、メッセージは、毎秒の最大可能速度で交換されます。プロトコルが安定状態に達し、リンクの「双方向性」に一定の決意を行うことができれば、その後、メッセージ間隔は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秒）または（現在の実装で15秒のデフォルトとMfastと90秒の間に）ユーザ設定値のいずれかであり得ます。
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.
シスコシステムズは、1999年以来、スイッチのその触媒ファミリの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]カッツ、D.、およびD.区、 "双方向フォワーディング検出"、進歩、2008年3月での作業。
Author's Address
著者のアドレス
Marco Foschiano Cisco Systems, Inc. Via Torri Bianche 7, 20059 Vimercate (Mi) Italy
マルコFoschianoシスコシステムズ社経由トッリビアンケ7、20059ヴィメルカーテ（MI）イタリア
EMail: foschia@cisco.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。