RFC5171 日本語訳

Network Working Group                                       M. Foschiano
Request for Comments: 5171                                 Cisco Systems
Category: Informational                                       April 2008

Foschianoがコメントのために要求するワーキンググループM.をネットワークでつないでください: 5171年のシスコシステムズカテゴリ: 情報の2008年4月

      Cisco Systems UniDirectional Link Detection (UDLD) Protocol

シスコシステムズの単方向のリンク検出(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はインターネットStandardのどんなレベルの候補ではありません。 IETFは配備されたプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実現と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。

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.

このドキュメントは単方向のイーサネットファイバーを検出して、無能にするのに使用できるシスコシステムズプロトコルか例えばファイバーストランド、インタフェース不調、メディアコンバータのせいなどの誤配線によって引き起こされた銅のリンクについて説明します。 それはLayer2でIEEE802.3の既存のLayer1欠点検出メカニズムに関連して作動します。

   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.

このドキュメントは、プロトコル目的とアプリケーションについて説明して、プロトコルが基づいた特定の構内を例証して、今後の標準化のための可能なベースとして役立つプロトコル構造と関連する展開問題について説明します。

Foschiano                    Informational                      [Page 1]

RFC 5171                          UDLD                        April 2008

[1ページ]RFC5171UDLD2008年4月の情報のFoschiano

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. 序論…2 2. 目的とアプリケーションについて議定書の中で述べてください…3 3. デザイン構内について議定書の中で述べてください…4 4. バックグラウンドについて議定書の中で述べてください…4 5. 構造について議定書の中で述べてください…5 5.1. 基礎…5 5.2. 隣人データベース維持…5 5.3. イベントドリブン検出であって反響すること…6 5.4. イベントなしの検出に対するイベントベース…6 6. パケット形式…7 6.1. TLV記述…9 7. 論理について議定書の中で述べてください…10 7.1. タイマについて議定書の中で述べてください…10 8. 双方向の推進検出との比較…11 9. セキュリティ問題…11 10. 展開問題…11 11. 標準の参照…12 12. 有益な参照…12

1.  Introduction

1. 序論

   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.

今日のイーサネットベースの交換網はしばしばソースから経路に沿ってスイッチの近くと、そして、知識の上で学習された物理的なリンクの状態のLayer2パケット情報に基づく目的地までの交通を進めるのに使用される無輪のトポロジーを作成するためにIEEE 802.1D規格[1]で定義されたSpanning Treeプロトコル(STP)を当てにします。

   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によって定義されたメカニズムを当てにしている間、Layer2通信チャネルによる変則的な状態の存在を検出することです。

Foschiano                    Informational                      [Page 2]

RFC 5171                          UDLD                        April 2008

[2ページ]RFC5171UDLD2008年4月の情報のFoschiano

2.  Protocol Objectives and Applications

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.

UniDirectional Link Detectionプロトコル(要するに、"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セグメントに取り付けられたすべてのできる装置のアイデンティティの広告を出して、Layer2コミュニケーションが適切なファッションで起こっているかどうか決定するためにそれぞれの装置のポートの上に受け取られた情報を集めることになっています。

   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ファイバーストランドを1つの隣人ポートに接続させるスイッチポートとそのテキサスファイバーストランドが別のものに接続した原因を修理しながら、起こるかもしれません。 これらの場合では、RXストランドの上の光学信号を受信しているなら、ポートはアクティブであると考えられるかもしれません。 しかしながら、問題はこのリンクがLayer2(and above)で有効な通信路を提供しないということです。

   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プロトコルはある仮定が危険なLayer2輪の創造を避けるために適切に機能するようにSpanning Treeプロトコルを他のプロトコルと、特に助けにしたのが正しい助けに実行されました。 それは、ほとんどのシスコシステムズスイッチで数年に利用可能であり、現在、最善が練習する多数のネットワークデザインの一部です。

Foschiano                    Informational                      [Page 3]

RFC 5171                          UDLD                        April 2008

[3ページ]RFC5171UDLD2008年4月の情報のFoschiano

3.  Protocol Design Premises

3. プロトコルデザイン構内

   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 欠点が発見されたなら、ユーザが不要なポート州のばたつくことを避ける予定された時間不完全なポートを抑えたがっていると思われました。 その理由で、時間ベースの欠点回収機構を提供しました(代替の回収機構はプロトコル自体によってそれとなく排除されませんが)。

4.  Protocol Background

4. プロトコルバックグラウンド

   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はLayer1検出メカニズムがIEEE規格で定義した存在の上で働いているLayer2検出プロトコルであることが意味されます。 例えば、100BaseFXインタフェースと100BaseTX/1000BaseXインタフェースへのAuto-交渉機能がトランスミッションメディアであるなら決定する標準の物理的な層のメカニズムを表すので、Far End Fault Indication(FEFI)機能は双方向です。 そして、(セクション24.3.2を見てください、.1、28.2 .3 .5 その他の詳細のための[2]について) Layer1「欠点」指示の典型的なケースは「光の損失」指示です。

   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は上記のメカニズムと異なっています。 さらに、それはLogical Link Controlの上で隣人承認を実行します。(LLC)

Foschiano                    Informational                      [Page 4]

RFC 5171                          UDLD                        April 2008

[4ページ]RFC5171UDLD2008年4月の情報のFoschiano

   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層のメカニズムのどちらかが、トランスミッション媒体が双方向であると考えたときさえ、隣人の論理的な片道伝達不良を発見できます。

5.  Protocol Architecture

5. プロトコル構造

5.1.  The Basics

5.1. 基礎

   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セグメントに接続されたすべての装置がプロトコルを走ることにさせるのであることを潜在的misconfigurationは検出して、早期是正措置を取るために必要とします。

5.2.  Neighbor Database Maintenance

5.2. 隣人データベース維持

   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は、隣人に関して各装置を知らせ続けるために、定期刊行の「こんにちは」パケット(また、「広告か徹底的調査」と呼ばれる)をあらゆるアクティブなインタフェースに送ります。 こんにちはときに、メッセージが受信されていて、それは、高々メモリで"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.

a新しい、こんにちは、通信員の古いキャッシュエントリーが外でまだ熟成していないとき、メッセージが受信されていて、次に、古いエントリーを落として、リセット生きる時間タイマで新しい方に取り替えます。 インタフェースが障害があるようになって、UDLDが走っているときはいつも、UDLDがインタフェースで無効にされるときはいつも、装置がリセットされるときはいつも、構成変更で影響を受けるインタフェースのためのすべての既存のキャッシュエントリーがクリアされます、そして、UDLDはまた、状態変化で影響を受ける彼らのキャッシュの部分を洗い流すために隣人に知らせる少なくとも1つのメッセージを送ります。 このメカニズムはすべての接続装置に一貫性を持っているようにキャッシュを保つことになっています。

Foschiano                    Informational                      [Page 5]

RFC 5171                          UDLD                        April 2008

[5ページ]RFC5171UDLD2008年4月の情報のFoschiano

5.3.  Event-driven Detection and Echoing

5.3. イベントドリブン検出と反響

   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装置が同時性で出かけている隣人から新しい隣人に関して学ぶか、または再同期要求を受け取るときはいつも、それ(re)は、検出の過程を接続の側面に始めて、回答で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.

この振舞いがすべての隣人と同じであるに違いないので、エコーの送付者は、回答におけるエコーを受ける(いつか後に)と予想します。 検出の過程が受け取られる適切なエコー情報なしで一定の条件の下で終わるなら、リンクは単方向であると考えられます。

5.4.  Event-based versus Event-less Detection

5.4. イベントなしの検出に対してイベントベースです。

   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人の隣人の間の通信障害がないのが容認できるポイントツーポイント接続だけの)だけでお勧めです。

Foschiano                    Informational                      [Page 6]

RFC 5171                          UDLD                        April 2008

[6ページ]RFC5171UDLD2008年4月の情報のFoschiano

6.  Packet Format

6. パケット・フォーマット

   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アドレスを使用して、以下で説明されるように標準のSubnetwork Accessプロトコル(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 Org Id 0x00000C HDLCプロトコルタイプ0x0111

   UDLD's Protocol Data Unit (PDU) format is as follows:

UDLDのプロトコルData Unit(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| 旗| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs(可変長リスト)のリスト| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 (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ビット): バイトのType、Length、およびValue分野の長さ。 この分野値が有効であるように、最小限は長さをより許容しました、4バイトということであるべきです。 値が最小限より少なくて、全体のパケットが崩壊していると考えられることになっていて、したがって、すぐ構文解析の過程の間、それを捨てなければならないということであるなら。 パケット境界の向こう側にTLVsを分割するべきではありません。

Foschiano                    Informational                      [Page 7]

RFC 5171                          UDLD                        April 2008

[7ページ]RFC5171UDLD2008年4月の情報のFoschiano

   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ビット): 0×01: UDLD PDUバージョン番号

   Opcode (5 bits):
         0x00: Reserved
         0x01: Probe message
         0x02: Echo message
         0x03: Flush message
         0x04-0x1F: Reserved for future use

Opcode(5ビット): 0×00: 予約された0×01: メッセージ0x02を調べてください: メッセージ0x03を反映してください: 0×04メッセージ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に噛み付きました: ReSynchは(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 Checksum(16ビット): IPのようなチェックサム。 1の補数合計の1の補数を取ってください、(変更、それ、余分な単語の低8ビットむしろ高い8ビットより使用される変な長さのメッセージの終わりの奇数バイト)。 ネブラスカ: すべてのUDLD実現がこの仕様に従わなければなりません。

   The list of currently defined TLVs comprises:

現在定義されたTLVsのリストは以下を包括します。

      Name                   Type      Value format

名前Type Value形式

      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 TLV0×0001ASCII文字列Port-ID TLV0x0002ASCII文字はID組Message Interval TLV0x0004の8ビットの符号のない整数Timeout Interval TLV0x0005 8ビットの符号のない整数Device Name TLV0x0006のASCII文字ストリングSequence Number TLV0x0007の32ビットの符号のない整数Reserved TLVs>0x0007Format未知のEcho TLV0×0003Listを結びます。 構文解析ルーチンでスキップされるために。

Foschiano                    Informational                      [Page 8]

RFC 5171                          UDLD                        April 2008

[8ページ]RFC5171UDLD2008年4月の情報のFoschiano

6.1.  TLV Description

6.1. TLV記述

   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組のリストを含んでいます。 1組の識別子のどちらかが崩壊すると、メッセージは無視されるでしょう。 このリストはこの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秒です。 受信されたメッセージのためのキャッシュ項目のholdtimeは(広告を出しているメッセージ間隔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は一生懸命コード化された定数であると思われます。

Foschiano                    Informational                      [Page 9]

RFC 5171                          UDLD                        April 2008

[9ページ]RFC5171UDLD2008年4月の情報のFoschiano

   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は一連番号の動向をおさえるべきです。 例えば、エコーメッセージ系列が開始されるときはいつも、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の使用は現在、情報の目的だけに制限されます。)

7.  Protocol Logic

7. プロトコル論理

   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 Neighbor州の変化o Neighbor resynchronizationプロトコルoプロトコル身体障害者o New隣人発見o要求の下側にo Linkをリンクしてください。

7.1.  Protocol Timers

7.1. プロトコルタイマ

   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

検出段階の間、1秒あたり1つの最大の可能なレートでメッセージを交換します。 プロトコルにその後達します。

Foschiano                    Informational                     [Page 10]

RFC 5171                          UDLD                        April 2008

[10ページ]RFC5171UDLD2008年4月の情報のFoschiano

   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秒の間で)。

8.  Comparison with Bidirectional Forwarding Detection

8. 双方向の推進検出との比較

   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に、Bidirectional Forwarding Detection(BFD)[3]プロトコルが2つのネットワーク・ノードの間の経路における欠点を検出することを意図します。 しかしながら、BFDはメディア、データプロトコル、およびルーティング・プロトコルの如何にかかわらず作動するべきです。 アドレス発見メカニズムが全く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の主な「アプリケーション」)の如何にかかわらず作動します。それはプロトコルで相互作用を制限しました。 また、それはポイントツーポイントとポイントツーマルチポイントメディアに完全な隣人発見を実行します。

9.  Security Considerations

9. セキュリティ問題

   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.

ネットワークデバイスの異なったモデルかデバイスが異なったソフトウェアイメージを実行している状態で造られる異種のLayer2ネットワークでは、UDLDプロトコルは、検出プロセスの徹底した報道を達成するために前述のデバイスとインタコネクトしながら、すべてのポートの上でサポートされて、構成されるべきです。 信頼されていないデバイスか不可能なデバイスにつなげられたポートの上でUDLDが使用されるべきでないことに注意してください。 したがって、それはそのようなポートの上で無効にされるべきです。

10.  Deployment Considerations

10. 展開問題

   Cisco Systems has supported the UDLD protocol in its Catalyst family
   of switches since 1999.

1999年以来シスコシステムズはスイッチのCatalystファミリーでUDLDプロトコルをサポートしています。

Foschiano                    Informational                     [Page 11]

RFC 5171                          UDLD                        April 2008

[11ページ]RFC5171UDLD2008年4月の情報のFoschiano

11.  Normative References

11. 引用規格

   [1]  IEEE 802.1D-2004 Standard -- Media access control (MAC) Bridges

[1]IEEE 802.1D-2004 Standard--メディアアクセス制御(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] IEEE802.3-2002IEEE Standard--地方とメトロポリタンエリアネットワークSpecific要件--パート3: 衝突検出型搬送波検知多重アクセス(CSMA/CD)アクセス法と物理的な層の仕様

12.  Informative Reference

12. 有益な参照

   [3]  Katz, D., and D. Ward, "Bidirectional Forwarding Detection",
        Work in Progress, March 2008.

2008年3月のキャッツ、D.とD.区、「双方向の推進検出」が進行中で扱う[3]。

Author's Address

作者のアドレス

   Marco Foschiano
   Cisco Systems, Inc.
   Via Torri Bianche 7,
   20059 Vimercate (Mi)
   Italy

トッリBianche7、20059Vimercate(ミ)イタリア経由でマルコFoschianoシスコシステムズInc.

   EMail: foschia@cisco.com

メール: foschia@cisco.com

Foschiano                    Informational                     [Page 12]

RFC 5171                          UDLD                        April 2008

[12ページ]RFC5171UDLD2008年4月の情報のFoschiano

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78と 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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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に情報を扱ってください。

Foschiano                    Informational                     [Page 13]

Foschiano情報です。[13ページ]