RFC2642 日本語訳
2642 Cabletron's VLS Protocol Specification. L. Kane. August 1999. (Format: TXT=204347 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Kane Request for Comments: 2642 Cabletron Systems Incorporated Category: Informational August 1999
コメントを求めるワーキンググループL.ケーン要求をネットワークでつないでください: 2642台のCabletronシステムがカテゴリを取り入れました: 情報の1999年8月
Cabletron's VLS Protocol Specification
CabletronのVLSプロトコル仕様
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
The Virtual LAN Link State Protocol (VLSP) is part of the InterSwitch Message Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. VLSP is used to determine and maintain a fully connected mesh topology graph of the switch fabric. Each switch maintains an identical database describing the topology. Call-originating switches use the topology database to determine the path over which to route a call connection.
バーチャルLAN Link州プロトコル(VLSP)は実行しているCabletronのSecureFast VLAN(SFVLAN)製品をスイッチのinterswitchコミュニケーションに供給するInterSwitch Messageプロトコル(ISMP)の一部です。 VLSPは、スイッチ骨組みの完全に接続されたメッシュトポロジーグラフを決定して、維持するのに使用されます。 各スイッチはトポロジーについて説明する同じデータベースを維持します。 呼び出しを溯源するスイッチは、呼び出し接続を発送する経路を決定するのにトポロジーデータベースを使用します。
VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic.
VLSPは位相的な変化に直面してすばやく等価コストマルチパスルーティング、およびrecalculatesルートのサポートを提供します、最小ルーティング・プロトコルトラフィックを利用して。
Table of Contents
目次
1. Introduction............................................ 3
1.1 Acknowledgments..................................... 3
1.2 Data Conventions.................................... 3
1.3 ISMP Overview....................................... 4
2. VLS Protocol Overview................................... 5
2.1 Definitions of Commonly Used Terms.................. 6
2.2 Differences Between VLSP and OSPF................... 7
2.2.1 Operation at the Physical Layer............... 8
2.2.2 All Links Treated as Point-to-Point........... 8
2.2.3 Routing Path Information...................... 9
2.2.4 Configurable Parameters....................... 9
2.2.5 Features Not supported........................ 9
2.3 Functional Summary.................................. 10
2.4 Protocol Packets.................................... 11
1. 序論… 3 1.1の承認… 3 1.2 データコンベンション… 3 1.3ISMP概要… 4 2. VLSは概要について議定書の中で述べます… 5 一般的に使用された期間の2.1の定義… 6 VLSPとOSPFの2.2の違い… 7 2.2 物理的な層での.1操作… 8 2.2 .2 すべてのリンクがポイントツーポイントを扱いました… 8 2.2 .3 ルート設定経路情報… 9 2.2 .4の構成可能なパラメタ… 9 2.2 Notがサポートした.5の特徴… 9 2.3の機能的な概要… 10 2.4 パケットについて議定書の中で述べてください… 11
Kane Informational [Page 1] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[1ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
2.5 Protocol Data Structures............................ 12
2.6 Basic Implementation Requirements................... 12
2.7 Organization of the Remainder of This Document...... 13
3. Interface Data Structure................................ 14
3.1 Interface States.................................... 16
3.2 Events Causing Interface State Changes.............. 18
3.3 Interface State Machine............................. 21
4. Neighbor Data Structure................................. 23
4.1 Neighbor States..................................... 25
4.2 Events Causing Neighbor State Changes............... 27
4.3 Neighbor State Machine.............................. 29
5. Area Data Structure..................................... 33
5.1 Adding and Deleting Link State Advertisements....... 34
5.2 Accessing Link State Advertisements................. 35
5.3 Best Path Lookup.................................... 35
6. Discovery Process....................................... 35
6.1 Neighbor Discovery.................................. 36
6.2 Bidirectional Communication......................... 37
6.3 Designated Switch................................... 38
6.3.1 Selecting the Designated Switch............... 39
6.4 Adjacencies......................................... 41
7. Synchronizing the Databases............................. 42
7.1 Link State Advertisements........................... 43
7.1.1 Determining Which
Link State Advertisement Is Newer............. 44
7.2 Database Exchange Process........................... 44
7.2.1 Database Description Packets.................. 44
7.2.2 Negotiating the Master/Slave Relationship..... 45
7.2.3 Exchanging Database Description Packets....... 46
7.3 Updating the Database............................... 48
7.4 An Example.......................................... 49
8. Maintaining the Databases............................... 51
8.1 Originating Link State Advertisements............... 52
8.1.1 Switch Link Advertisements.................... 52
8.1.2 Network Link Advertisements................... 55
8.2 Distributing Link State Advertisements.............. 56
8.2.1 Overview...................................... 57
8.2.2 Processing an
Incoming Link State Update Packet............. 58
8.2.3 Forwarding Link State Advertisements.......... 60
8.2.4 Installing Link
State Advertisements in the Database.......... 62
8.2.5 Retransmitting Link State Advertisements...... 63
8.2.6 Acknowledging Link State Advertisements....... 64
8.3 Aging the Link State Database....................... 66
8.3.1 Premature Aging of Advertisements............. 66
9. Calculating the Best Paths.............................. 67
10. Protocol Packets........................................ 67
2.5 データ構造について議定書の中で述べてください… 12 2.6 基本の実装要件… 12 2.7 このドキュメントの残りの組織… 13 3. データ構造を連結してください… 14 3.1 州を連結してください… 16 インタフェースを引き起こす3.2のイベントが変化を述べます… 18 3.3 州のマシンを連結してください… 21 4. 隣人データ構造… 23 4.1 隣人州… 25 隣人を引き起こす4.2のイベントが変化を述べます… 27 4.3隣人はマシンを述べます… 29 5. 領域データ構造… 33 5.1 付加と削除は州の広告をリンクします… 34 リンクにアクセスする5.2が広告を述べます… 35 5.3の最も良い経路ルックアップ… 35 6. 発見プロセス… 35 6.1 隣人発見… 36 6.2 双方向のコミュニケーション… 37 6.3はスイッチを指定しました… 38 6.3 .1 指定されたスイッチを選択します… 39 6.4の隣接番組… 41 7. データベースを同期させます… 42 7.1 州の広告をリンクしてください… 43 7.1 .1 どれが州の広告をリンクするかを決定するのは、より新しいです… 44 7.2データベース交換プロセス… 44 7.2 .1 データベース記述パケット… 44 7.2 .2 マスター/奴隷関係を交渉します… 45 7.2 .3 データベース記述パケットを交換します… 46 7.3 データベースをアップデートします… 48 7.4 例… 49 8. データベースを維持します… 51 8.1 リンクを溯源して、広告を述べてください… 52 8.1 .1 リンク広告を切り換えてください… 52 8.1 .2 リンク広告をネットワークでつないでください… 55 リンクを分配する8.2が広告を述べます… 56 8.2 .1概要… 57 8.2 .2 入って来るリンク状態を処理して、パケットをアップデートしてください… 58 8.2 リンクを進める.3が広告を述べます… 60 8.2 .4 リンクをインストールして、データベースにおける広告を述べてください… 62 8.2 .5 リンクを再送して、広告を述べてください… 63 8.2 リンクを承認する.6が広告を述べます… 64 8.3 リンクの年をとって、データベースを述べてください… 66 8.3 .1 広告の時期尚早な年をとること… 66 9. 最も良い経路について計算します… 67 10. パケットについて議定書の中で述べてください… 67
Kane Informational [Page 2] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[2ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
10.1 ISMP Packet Format................................. 68
10.1.1 Frame Header................................ 69
10.1.2 ISMP Packet Header.......................... 70
10.1.3 ISMP Message Body........................... 71
10.2 VLSP Packet Processing............................. 71
10.3 Network Layer Address Information.................. 72
10.4 VLSP Packet Header................................. 73
10.5 Options Field...................................... 75
10.6 Packet Formats..................................... 76
10.6.1 Hello Packets............................... 76
10.6.2 Database Description Packets................ 78
10.6.3 Link State Request Packets.................. 80
10.6.4 Link State Update Packets................... 82
10.6.5 Link State Acknowledgment Packets........... 83
11. Link State Advertisement Formats........................ 84
11.1 Link State Advertisement Headers................... 84
11.2 Switch Link Advertisements......................... 86
11.3 Network Link Advertisements........................ 89
12. Protocol Parameters..................................... 89
12.1 Architectural Constants............................ 90
12.2 Configurable Parameters............................ 91
13. End Notes............................................... 93
14. Security Considerations................................. 94
15. References.............................................. 94
16. Author's Address........................................ 94
17. Full Copyright Statement................................ 95
10.1 ISMPパケット・フォーマット… 68 10.1.1 ヘッダーを罪に陥れてください… 69 10.1.2 ISMPパケットのヘッダー… 70 10.1.3 ISMPメッセージボディー… 71 10.2 VLSPパケット処理… 71 10.3 ネットワーク層アドレス情報… 72 10.4 VLSPパケットのヘッダー… 73 10.5オプション分野… 75 10.6 パケット形式… 76 10.6.1、こんにちは、パケット… 76 10.6.2 データベース記述パケット… 78 10.6.3 州のリクエスト・パケットをリンクしてください… 80 10.6.4 州のアップデートパケットをリンクしてください… 82 10.6.5 州の確認応答パケットをリンクしてください… 83 11. 州の広告形式をリンクしてください… 84 11.1 州の広告ヘッダーをリンクしてください… 84 11.2 リンク広告を切り換えてください… 86 11.3 リンク広告をネットワークでつないでください… 89 12. パラメタについて議定書の中で述べてください… 89 12.1の建築定数… 90 12.2の構成可能なパラメタ… 91 13. 音を終わらせてください… 93 14. セキュリティ問題… 94 15. 参照… 94 16. 作者のアドレス… 94 17. 完全な著作権宣言文… 95
1. Introduction
1. 序論
This memo is being distributed to members of the Internet community in order to solicit reactions to the proposals contained herein. While the specification discussed here may not be directly relevant to the research problems of the Internet, it may be of interest to researchers and implementers.
このメモは、ここに含まれた提案への反応に請求するためにインターネットコミュニティのメンバーに配布されています。 ここで議論した仕様が直接インターネットの研究課題に関連していないかもしれない間、それは研究者とimplementersに興味があるかもしれません。
1.1 Acknowledgments
1.1 承認
VLSP is derived from the OSPF link-state routing protocol described in [RFC2328], written by John Moy, formerly of Proteon, Inc., Westborough, Massachusetts. Much of the current memo has been drawn from [RFC2328]. Therefore, this author wishes to acknowledge the contribution Mr. Moy has (unknowingly) made to this document.
以前ジョンMoyによって書かれた[RFC2328]でProteon Inc.、ウェストボーラフ、マサチューセッツについて説明されたOSPF LinkState方式プロトコルからVLSPを得ます。 [RFC2328]から現在のメモの多くを得ました。 したがって、この作者はMoyさんがこのドキュメントに(知らずに)した貢献を承諾したがっています。
1.2 Data Conventions
1.2 データコンベンション
The methods used in this memo to describe and picture data adhere to the standards of Internet Protocol documentation [RFC1700]. In particular:
説明するこのメモとピクチャ・データで使用されるメソッドはインターネットプロトコルドキュメンテーション[RFC1700]の規格を固く守ります。 特に:
Kane Informational [Page 3] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[3ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
The convention in the documentation of Internet Protocols is to
express numbers in decimal and to picture data in "big-endian"
order. That is, fields are described left to right, with the most
significant octet on the left and the least significant octet on
the right. The order of transmission of the header and data
described in this document is resolved to the octet level.
Whenever a diagram shows a group of octets, the order of
transmission of those octets is the normal order in which they are
read in English.
インターネットプロトコルのドキュメンテーションにおけるコンベンションは「ビッグエンディアン」オーダーに小数とピクチャ・データに数を表すことになっています。 すなわち、分野は左でまさしく言われます、権利における左の、そして、最も重要でない八重奏で最も重要な八重奏で。 本書では説明されたヘッダーとデータの伝達の注文を八重奏レベルに決議します。 ダイヤグラムが八重奏のグループを示しているときはいつも、それらの八重奏の送信の注文はそれらが英語で読まれる通常のオーダーです。
Whenever an octet represents a numeric quantity the left most bit
in the diagram is the high order or most significant bit. That
is, the bit labeled 0 is the most significant bit.
八重奏が数値量を表すときはいつも、ダイヤグラムで最も噛み付かれた左は、高位か最上位ビットです。 すなわち、0とラベルされたビットは最も重要なビットです。
Similarly, whenever a multi-octet field represents a numeric
quantity the left most bit of the whole field is the most
significant bit. When a multi-octet quantity is transmitted the
most significant octet is transmitted first.
同様に、マルチ八重奏分野が数値量を表すときはいつも、大部分が噛み付いた全体の分野の左は最も重要なビットです。 マルチ八重奏量が伝えられるとき、最も重要な八重奏は最初に、伝えられます。
1.3 ISMP Overview
1.3 ISMP概要
The InterSwitch Message Protocol (ISMP) provides a consistent method of encapsulating and transmitting control messages exchanged between switches running Cabletron's SecureFast VLAN (SFVLAN) product, as described in [IDsfvlan]. ISMP provides the following services:
InterSwitch Messageプロトコル(ISMP)はCabletronのSecureFast VLAN(SFVLAN)製品を動かしながらスイッチの間で交換されたコントロールメッセージをカプセル化して、送る一貫したメソッドを提供します、[IDsfvlan]で説明されるように。 ISMPは以下のサービスを提供します:
o Topology services. Each switch maintains a distributed topology
of the switch fabric by exchanging the following interswitch
control messages with other switches:
o トポロジーサービス。 各スイッチは以下のinterswitchコントロールメッセージを他のスイッチと交換することによって、スイッチ骨組みの分配されたトポロジーを維持します:
o Interswitch Keepalive messages are sent by each switch to announce
its existence to its neighboring switches and to establish the
topology of the switch fabric. (Interswitch Keepalive messages
are exchanged in accordance with Cabletron's VlanHello protocol,
described in [IDhello].)
o 各スイッチでInterswitch Keepaliveメッセージを送って、隣接しているスイッチに存在を発表して、スイッチ骨組みのトポロジーを設置します。 ([IDhello]で説明されたCabletronのVlanHelloプロトコルに応じて、Interswitch Keepaliveメッセージを交換します。)
o Interswitch Spanning Tree BPDU messages and Interswitch Remote
Blocking messages are used to determine and maintain a loop-free
flood path between all network switches in the fabric. This flood
o Interswitch Spanning Tree BPDUメッセージとInterswitch Remote Blockingメッセージは、骨組みのすべてのネットワークスイッチの間の無輪の洪水経路を決定して、維持するのに使用されます。 この洪水
path is used for all undirected interswitch messages -- that is,
messages that are (potentially) sent to all switches in the switch
fabric.
経路はすべてのundirected interswitchメッセージに使用されます--すなわち、(潜在的に)スイッチ骨組みのすべてのスイッチに送られるメッセージ。
o Interswitch Link State messages (VLS protocol) are used to
determine and maintain a fully connected mesh topology graph of
the switch fabric. Call-originating switches use the topology
graph to determine the path over which to route a call connection.
o Interswitch Link州メッセージ(VLSは議定書を作る)は、スイッチ骨組みの完全に接続されたメッシュトポロジーグラフを決定して、維持するのに使用されます。 呼び出しを溯源するスイッチは、呼び出し接続を発送する経路を決定するのにトポロジーグラフを使用します。
Kane Informational [Page 4] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[4ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o Address resolution services. Interswitch Resolve messages are
used to resolve a packet destination address when the packet
source and destination pair does not match a known connection.
Interswitch New User messages are used to provide end-station
address mobility between switches.
o 解決サービスを扱ってください。 Interswitch Resolveメッセージは、パケットソースと目的地組が知られている接続に合っていないとき、パケット送付先アドレスを決議するのに使用されます。 Interswitch New Userメッセージは、端ステーションアドレスの移動性をスイッチの間に供給するのに使用されます。
o Tag-based flooding. A tag-based broadcast method is used to
restrict the broadcast of unresolved packets to only those ports
within the fabric that belong to the same VLAN as the source.
o タグベースの氾濫。 タグベースの放送メソッドは、未定のパケットの放送を骨組みの中のソースと同じVLANに属すそれらのポートだけに制限するのに使用されます。
o Call tapping services. Interswitch Tap messages are used to
monitor traffic moving between two end stations. Traffic can be
monitored in one or both directions along the connection path.
o 叩きサービスに電話をしてください。 Interswitch Tapメッセージは、2つの端のステーションの間で移行するトラフィックをモニターするのに使用されます。 接続道に沿って1か方向の両方にトラフィックをモニターできます。
Note: Previous versions of VLSP treated all links as if they were broadcast (multi-access). Thus, if VLSP determines that a neighbor switch is running an older version of the protocol software (see Section 6.1), it will change the interface type to broadcast and begin exchanging Hello packets with the single neighbor switch.
以下に注意してください。 まるでそれらが放送されるかのように(マルチアクセス)扱われたVLSPの旧バージョンはすべてリンクされます。 したがって、VLSPが、隣人スイッチがプロトコル・ソフトウエアの旧式のバージョンを実行していることを決定すると(セクション6.1を見てください)、それは、放送して、単一の隣人スイッチとHelloパケットを交換し始めるためにインターフェース型を変えるでしょう。
2. VLS Protocol Overview
2. VLSプロトコル概要
VLSP is a dynamic routing protocol. It quickly detects topological changes in the switch fabric (such as, switch interface failures) and calculates new loop-free routes after a period of convergence. This period of convergence is short and involves a minimum of routing traffic.
VLSPはダイナミックルーティングプロトコルです。 それは、スイッチ骨組み(あれほどです、インタフェース失敗を切り換える)にすぐに位相的な変化を検出して、集合の一区切りの後に新しい無輪のルートを計算します。 この期間の集合は、短く、最小ルーティングトラフィックにかかわります。
All switches in the fabric run the same algorithm and maintain identical databases describing the switch fabric topology. This database contains each switch's local state, including its usable interfaces and reachable neighbors. Each switch distributes its local state throughout the switch fabric by flooding. From the topological database, each switch constructs a set of best path trees (using itself as the root) that specify routes to all other switches in the fabric.
骨組みのすべてのスイッチが、同じアルゴリズムを実行して、スイッチ骨組みのトポロジーについて説明する同じデータベースを維持します。 このデータベースはその使用可能なインタフェースと届いている隣人を含む各スイッチの地方の州を含んでいます。 各スイッチは氾濫でスイッチ骨組みに地方の状態を分配します。 位相的なデータベースから、各スイッチは骨組みの他のすべてのスイッチにルートを指定する1セットの最も良い経路木(根としてそれ自体を使用する)を組み立てます。
Kane Informational [Page 5] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[5ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
2.1 Definitions of Commonly Used Terms
2.1 一般的に使用された期間の定義
This section contains a collection of definitions for terms that have a specific meaning to the protocol and that are used throughout the text.
このセクションは特定の意味をプロトコルに持って、テキスト中で使用される用語のときに定義の収集を含みます。
Switch ID
スイッチID
A 10-octet value that uniquely identifies the switch within the
switch fabric. The value consists of the 6-octet base MAC address
of the switch, followed by 4 octets of zeroes.
スイッチ骨組みの中で唯一スイッチを特定する10八重奏の値。 値はゼロの4つの八重奏があとに続いたスイッチの6八重奏のベースMACアドレスから成ります。
Network link
ネットワークリンク
The physical connection between two switches. A link is
associated with a switch interface.
2の間の物理接続は切り替わります。 リンクはスイッチインタフェースに関連しています。
There are two physical types of network links supported by VLSP:
VLSPによって支えられた2つの物理的なタイプのネットワークリンクがあります:
o Point-to-point links that join a single pair of switches. A
serial line is an example of a point-to-point network link.
o 1組のスイッチを接合するポイントツーポイント接続。 シリアル・ラインは二地点間ネットワークリンクに関する例です。
o Multi-access broadcast links that support the attachment of
multiple switches, along with the capability to address a
single message to all the attached switches. An attached
ethernet is an example of a multi-access broadcast network
link.
o マルチアクセスは複数のスイッチの付属をサポートするリンクを放送しました、すべての付属スイッチにただ一つのメッセージを扱う能力と共に。 付属イーサネットはマルチアクセス放送網リンクに関する例です。
A single topology can contain both types of links. At startup,
all links are assumed to be point-to-point. A link is
determined to be multi-access when more than one neighboring
switch is discovered on the link.
単一のトポロジーは両方のタイプのリンクを含むことができます。 始動では、すべてのリンクが二地点間であると思われます。 リンクは1個以上の隣接しているスイッチがリンクの上に発見されるときのマルチアクセスであると決心しています。
Interface
インタフェース
The port over which a switch accesses one of its links.
Interfaces are identified by their interface ID, a 10-octet value
consisting of the 6-octet base MAC address of the switch, followed
by the 4-octet local port number of the interface.
スイッチがリンクの1つにアクセスするポート。 インタフェースはそれらのインタフェースIDによって特定されます、10八重奏の値がインタフェースの4八重奏の地方のポートナンバーがあとに続いたスイッチの6八重奏のベースMACアドレスから成って。
Neighboring switches
隣接しているスイッチ
Two switches attached to a common link.
2個のスイッチが普通リンクに付きました。
Kane Informational [Page 6] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[6ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Adjacency
隣接番組
A relationship formed between selected neighboring switches for
the purpose of exchanging routing information. Not every pair of
neighboring switches become adjacent.
関係はルーティング情報を交換する目的のために選択された隣接しているスイッチの間で形成されました。 すべての組のどんな隣接しているスイッチも隣接するようになりません。
Link state advertisement
リンク州の広告
Describes the local state of a switch or a link. Each link state
advertisement is flooded throughout the switch fabric. The
collected link state advertisements of all switches and links form
the protocol's topological database.
スイッチかリンクの地方の状態について説明します。 それぞれのリンク州の広告はスイッチ骨組みの間中水につかっています。 すべてのスイッチとリンクの集まっているリンク州の広告はプロトコルの位相的なデータベースを形成します。
Designated switch
スイッチに指定されます。
Each multi-access network link has a designated switch. The
designated switch generates a link state advertisement for the
link and has other special responsibilities in the running of the
protocol.
それぞれのマルチアクセスネットワークリンクには、指定されたスイッチがあります。 指定されたスイッチは、リンク州の広告をリンクに作って、プロトコルの稼働で他の特別な責任を持っています。
The use of a designated switch permits a reduction in the number
of adjacencies required on multi-access links. This in turn
reduces the amount of routing protocol traffic and the size of the
topological database.
指定されたスイッチの使用はマルチアクセスリンクの上に必要である隣接番組の数の減少を可能にします。 これはルーティング・プロトコルトラフィックの量と位相的なデータベースのサイズを順番に減少させます。
The designated switch is selected during the discovery process. A
designated switch is not selected for a point-to-point network
link.
指定されたスイッチは発見プロセスの間、選択されます。 指定されたスイッチは二地点間ネットワークリンクに選択されません。
Backup designated switch
スイッチに任命されたバックアップ
Each multi-access network link has a backup designated switch.
The backup designated switch maintains adjacencies with the same
switches on the link as the designated switch. This optimizes the
failover time when the backup designated switch must take over for
the (failed) designated switch.
それぞれのマルチアクセスネットワークリンクで、バックアップをスイッチに任命します。 指定されたスイッチとしてのリンクの上に同じスイッチがある状態で、スイッチに任命されたバックアップは隣接番組を維持します。 これはスイッチに任命されたバックアップが(失敗される)の指定されたスイッチのために引き継がなければならないフェイルオーバー時を最適化します。
The backup designated switch is selected during the Discovery
process. A backup designated switch is not selected for a point-
to-point network link.
スイッチに任命されたバックアップはディスカバリープロセスの間、選ばれます。 スイッチに任命されたバックアップはポイントへのポイントネットワークリンクに選ばれません。
2.2 Differences Between VLSP and OSPF
2.2 VLSPとOSPFの違い
The VLS protocol is derived from the OSPF link-state routing protocol described in [RFC2328].
[RFC2328]で説明されたOSPF LinkState方式プロトコルからVLSプロトコルを得ます。
Kane Informational [Page 7] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[7ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
2.2.1 Operation at the Physical Layer
2.2.1 物理的な層での操作
The primary differences between the VLS and OSPF protocols stem from the fact that OSPF runs over the IP layer, while VLSP runs at the physical MAC layer. This difference has the following repercussions:
VLSとOSPFプロトコルのプライマリ違いはOSPFがIP層をひくという事実によります、VLSPが物理的なMAC層で稼働していますが。 この違いに、以下の跳ね返りがあります:
o VLSP does not support features (such as fragmentation) that are
typically provided by network layer service providers.
o VLSPはネットワーク層サービスプロバイダーによって通常提供される特徴(断片化などの)をサポートしません。
o Due to the unrelated nature of MAC address assignments, VLSP
provides no summarization of the address space (such as, classical
IP subnet information) or level 2 routing (such as,
o MACアドレス課題の関係ない本質のため、VLSPがレベル2 (そのようで、古典的なIPサブネット情報)かルーティングをアドレス空間のどんな総括にも提供しない、(あれほどです。
IS-IS Phase V DECnet). Thus, VLSP does not support grouping
switches into areas. All switches exist in a single area. Since
a single domain exists within any switch fabric, there is no need
for VLSP to provide interdomain reachability.
-、フェーズV DECnet) したがって、VLSPは組分けスイッチを領域に支えません。 すべてのスイッチがただ一つの領域に存在しています。 単一領域がどんなスイッチ骨組みの中にも存在しているので、VLSPがinterdomainの可到達性を提供する必要は全くありません。
o As mentioned in Section 10.1.1, ISMP uses a single well-known
multicast address for all packets. However, parts of the VLS
protocol (as derived from OSPF) are dependent on certain network
layer addresses -- in particular, the AllSPFSwitches and
AllDSwitches multicast addresses that drive the distribution of
link state advertisements throughout the switch fabric. In order
to facilitate the implementation of the protocol at the physical
MAC layer, network layer address information is encapsulated in
the protocol packets (see Section 10.3). This information is
unbundled and packets are then processed as if they had been sent
or received on that multicast address.
o セクション10.1.1で言及されるように、ISMPはすべてのパケットにただ一つのよく知られるマルチキャストアドレスを使用します。 しかしながら、VLSプロトコル(OSPFから派生するように)の部分はあるネットワーク層アドレスに依存しています--特にリンク州の広告の分配をスイッチ骨組みに動かすAllSPFSwitchesとAllDSwitchesマルチキャストアドレス。 物理的なMAC層でプロトコルの実装を容易にするために、ネットワーク層アドレス情報はプロトコルパケットでカプセル化されます(セクション10.3を見てください)。 この情報は非添付されて、次に、パケットはまるでそのマルチキャストアドレスにそれらを送ったか、または受け取ったかのように処理されます。
2.2.2 All Links Treated as Point-to-Point
2.2.2 ポイントツーポイントとして扱われたすべてのリンク
When the switch first comes on line, VLSP assumes all network links are point-to-point and no more than one neighboring switch will be discovered on any one port. Therefore, at startup, VLSP does not send its own Hello packets over its network ports, but instead, relies on the VlanHello protocol [IDhello] for the discovery of its neighbor switches. If a second neighbor is detected on a link, the link is then deemed multi-access and the interface type is changed to broadcast. At that point, VLSP exchanges its own Hello packets with the switches on the link in order to select a designated switch and designated backup switch for the link.
スイッチが最初に系列をつくと、VLSPは、すべてのネットワークリンクが二地点間であると仮定します、そして、1個未満の隣接しているスイッチがどんなポートの上でも発見されるでしょう。 したがって、VLSPは始動では、それ自身のHelloパケットをネットワークポートの上に送るのではなく、代わりに送って、隣人スイッチの発見のために、VlanHelloプロトコル[IDhello]を当てにします。 リンクの上に2番目の隣人を検出するなら、マルチアクセスであるとリンクを考えます、そして、放送するためにインターフェース型を変えます。 その時、VLSPは、指定されたスイッチと指定されたバックアップスイッチをリンクに選択するためにリンクでそれ自身のHelloパケットをスイッチと交換します。
This method eliminates unnecessary duplication of message traffic and processing, thereby increasing the overall efficiency of the switch fabric.
このメソッドはメッセージトラフィックと処理の不要な複製を排除して、その結果、スイッチ骨組みの全体的効率を増強します。
Kane Informational [Page 8] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[8ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Note: Previous versions of VLSP treated all links as if they were broadcast (multi-access). Thus, if VLSP determines that a neighbor switch is running an older version of the protocol software (see Section 6.1), it will change the interface type to broadcast and begin exchanging Hello packets with the single neighbor switch.
以下に注意してください。 まるでそれらが放送されるかのように(マルチアクセス)扱われたVLSPの旧バージョンはすべてリンクされます。 したがって、VLSPが、隣人スイッチがプロトコル・ソフトウエアの旧式のバージョンを実行していることを決定すると(セクション6.1を見てください)、それは、放送して、単一の隣人スイッチとHelloパケットを交換し始めるためにインターフェース型を変えるでしょう。
2.2.3 Routing Path Information
2.2.3 ルート設定経路情報
Instead of providing the next hop to a destination, VLSP calculates and maintains complete end-to-end path information. On request, a list of individual port identifiers is generated describing a complete path from the source switch to the destination switch. If multiple equal-cost routes exist to a destination switch, up to three paths are calculated and returned.
次のホップを目的地に提供することの代わりに、VLSPは終わりから終わりへの経路完全な情報を計算して、保守します。 要求に応じて、ソーススイッチから目的地スイッチまで完全な経路について説明するのは個々のポート識別子のリストに生成されます。 複数の等しい費用ルートが目的地スイッチに存在しているなら、最大3つの経路を計算して、返します。
2.2.4 Configurable Parameters
2.2.4 構成可能なパラメタ
OSPF supports (and requires) configurable parameters. In fact, even the default OSPF configuration requires that IP address assignments be specified. On the other hand, no configuration information is ever required for the VLS protocol. Switches are uniquely identified by their base MAC addresses and ports are uniquely identified by the base MAC address of the switch and a port number.
OSPFがサポートする、(必要である、)、構成可能なパラメタ。 デフォルトOSPF構成さえ、IPアドレス課題が指定されるのを必要とします。 他方では、設定情報は全く今までに、VLSプロトコルに必要ではありません。 スイッチはそれらのベースMACアドレスによって唯一特定されます、そして、ポートはスイッチとポートナンバーのベースMACアドレスによって唯一特定されます。
While a developer is free to implement configurable parameters for the VLS protocol, the current version of VLSP supports configurable path metrics only. Note that this has the following repercussions:
開発者は自由にVLSプロトコルのための構成可能なパラメタを実装することができますが、VLSPの最新版は構成可能な経路測定基準だけをサポートします。 これには以下の跳ね返りがあることに注意してください:
o All switches are assigned a switch priority of 1. This forces the
selection of the designated switch to be based solely on base MAC
address.
o 1のスイッチ優先はすべてのスイッチに割り当てられます。 これによって、指定されたスイッチの選択はやむを得ず唯一ベースMACアドレスに基づきます。
o Authentication is not supported.
o 認証はサポートされません。
2.2.5 Features Not supported
2.2.5 Notがサポートした特徴
In addition to those features mentioned in the previous sections, the following OSPF features are not supported by the current version of VLSP:
前項で言及されたそれらの特徴に加えて、以下のOSPFの特徴はVLSPの最新版によってサポートされません:
o Periodic refresh of link state advertisements. (This optimizes
performance by eliminating unnecessary traffic between the
switches.)
o 周期的である、リンク州の広告をリフレッシュしてください。 (これはスイッチの間の不要なトラフィックを排除するのによる性能を最適化します。)
o Routing based on non-zero type of service (TOS).
o ルート設定はサービスの非ゼロタイプを基礎づけました(TOS)。
o Use of external routing information for destinations outside the
switch fabric.
o 外部のルーティング情報のスイッチ骨組みの外における目的地の使用。
Kane Informational [Page 9] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[9ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
2.3 Functional Summary
2.3 機能的な概要
There are essentially four operational stages of the VLS protocol.
本質的には、VLSプロトコルの4つの操作上のステージがあります。
o Discovery Process The discovery process involves two steps:
o 発見プロセスが2を伴うという発見Processは踏みます:
o Neighboring switches are detected by the VlanHello protocol
[IDhello] which then notifies VLSP of the neighbor.
o 次に隣人についてVLSPに通知するVlanHelloプロトコル[IDhello]によって隣接しているスイッチは検出されます。
o If more than one neighbor switch is detected on a single port,
the link is determined to be multi-access. VLSP then sends its
own Hello packets over the link in order to discover the full
set of neighbors on the link and select a designated switch and
designated backup switch for the link. Note that this
selection process is unnecessary on point-to-point links.
o 1個以上の隣人スイッチが単一のポートの上に検出されるなら、リンクはマルチアクセサリーであると決心しています。 そして、VLSPは、リンクの上に隣人のフルセットを発見して、指定されたスイッチと指定されたバックアップスイッチをリンクに選択するためにそれ自身のHelloパケットをリンクの上に送ります。 この選択プロセスがポイントツーポイント接続で不要であることに注意してください。
The discovery process is described in more detail in Section 6.
発見プロセスはさらに詳細にセクション6で説明されます。
o Synchronizing the Databases
o データベースを同期させます。
Adjacencies are used to simplify and speed up the process of
synchronizing the topological database (also known as the link
state database) maintained by each switch in the fabric. Each
switch is only required to synchronize its database with those
neighbors to which it is adjacent. This reduces the amount of
routing protocol traffic across the fabric, particularly for
multi-access links with multiple switches.
隣接番組は、骨組みの各スイッチによって維持された位相的なデータベース(また、リンク州のデータベースとして、知られている)を同期させるプロセスを簡素化して、加速するのに使用されます。 各スイッチが、それが隣接しているそれらの隣人とデータベースを同期させるのに必要であるだけです。 これは骨組みの向こう側にルーティング・プロトコルトラフィックの量を特に複数のスイッチとのマルチアクセスリンクに変えます。
The process of synchronizing the databases is described in more
detail in Section 7.
データベースを同期させるプロセスはさらに詳細にセクション7で説明されます。
o Maintaining the Databases
o データベースを維持します。
Each switch advertises its state (also known as its link state)
any time its link state changes. Link state advertisements are
distributed throughout the switch fabric using a reliable flooding
algorithm that ensures that all switches in the fabric are
notified of any link state changes.
各スイッチはリンク状態が変化する何時でも状態(また、リンク状態として、知られている)の広告を出します。 リンク州の広告は、スイッチ骨組みの間中骨組みのすべてのスイッチがどんなリンク州の変化についても通知されるのを確実にする信頼できる氾濫アルゴリズムを使用することで配布されます。
The process of maintaining the databases is described in more
detail in Section 8.
データベースを維持するプロセスはさらに詳細にセクション8で説明されます。
Kane Informational [Page 10] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[10ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o Calculating the Best Paths
o 最も良い経路について計算します。
The link state database consists of the collection of link state
advertisements received from each switch. Each switch uses its
link state database to calculate a set of best paths, using itself
as root, to all other switches in the fabric.
リンク州のデータベースは各スイッチから受け取られたリンク州の広告の収集から成ります。 各スイッチは1セットの最も良い経路について計算するのにリンク州のデータベースを使用します、根としてそれ自体を使用して、骨組みの他のすべてのスイッチに。
The process of recalculating the set of best paths is described in
more detail in Section 9.
最も良い経路のセットについて再計算するプロセスはさらに詳細にセクション9で説明されます。
2.4 Protocol Packets
2.4 プロトコルパケット
In addition to the frame header and the ISMP packet header described in Section 10.1, all VLS protocol packets share a common protocol header, described in Section 10.4.
セクション10.1で説明されたフレームヘッダーとISMPパケットのヘッダーに加えて、すべてのVLSプロトコルパケットがセクション10.4で説明された一般的なプロトコルヘッダーを共有します。
The VLSP packet types are listed below in Table 1. Their formats are described in Section 10.6.
VLSPパケットタイプはTable1に以下に記載されています。 それらの形式はセクション10.6で説明されます。
Type Packet Name Protocol Function
パケット名前プロトコル機能をタイプしてください。
1 Hello Select DS and Backup DS
2 Database Description Summarize database contents
3 Link State Request Database download
4 Link State Update Database update
5 Link State Ack Flooding acknowledgment
1 こんにちは、Select DS、Backup DS2Database記述Summarizeデータベースコンテンツ3Link州Request Databaseは4Link州Update Databaseアップデート5Link州Ack Flooding承認をダウンロードします。
Table 1: VLSP Packet Types
テーブル1: VLSPパケットタイプ
The Hello packets are used to select the designated switch and the backup designated switch on multi-access links. The Database Description and Link State Request packets are used to form adjacencies. Link State Update and Link State Acknowledgment packets are used to update the topological database.
Helloパケットは、マルチアクセスリンクの上のスイッチに任命された指定されたスイッチとバックアップを選ぶのに使用されます。 Database記述とLink州Requestパケットは、隣接番組を形成するのに使用されます。 リンク州UpdateとLink州Acknowledgmentパケットは、位相的なデータベースをアップデートするのに使用されます。
Each Link State Update packet carries a set of link state advertisements. A single Link State Update packet may contain the link state advertisements of several switches. There are two different types of link state advertisement, as shown below in Table 2.
それぞれのLink州Updateパケットは1セットのリンク州の広告を運びます。 単一のLink州Updateパケットは数個のスイッチのリンク州の広告を含むかもしれません。 リンク州の広告の2つの異なったタイプがTable2に以下に示されるようにあります。
Kane Informational [Page 11] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[11ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
LS Advertisement Advertisement Description
Type Name
LS広告広告記述型名
1 Switch link Originated by all switches. This
advertisements advertisement describes the collected
states of the switch's interfaces.
1 すべてによるスイッチリンクOriginatedは切り替わります。 この広告広告はスイッチのインタフェースの集まっている州について説明します。
2 Network link Originated by the designated switch.
advertisements This advertisement contains the list
of switches connected to the network
link.
指定されたスイッチでリンクOriginatedをネットワークでつないでください。2 広告がリストを含む広告Thisはネットワークリンクに接続されていた状態で切り替わります。
Table 2: VLSP Link State Advertisements
テーブル2: VLSPリンク州の広告
2.5 Protocol Data Structures
2.5 プロトコルデータ構造
The VLS protocol is described in this specification in terms of its operation on various protocol data structures. Table 3 lists the primary VLSP data structures, along with the section in which they are described in detail.
VLSプロトコルは様々なプロトコルデータ構造でこの仕様で操作で説明されます。 テーブル3はそれらが詳細に説明されるセクションに伴うプライマリVLSPデータ構造を記載します。
Structure Name Description
構造名前記述
Interface Data Structure Section 3
Neighbor Data Structure Section 4
Area Data Structure Section 5
インタフェースデータ構造部3 隣人データ構造部4 領域データ構造部5
Table 3: VLSP Data Structures
テーブル3: VLSPデータ構造
2.6 Basic Implementation Requirements
2.6 基本の実装要件
An implementation of the VLS protocol requires the following pieces of system support:
VLSプロトコルの実装は以下のシステム支援を必要とします:
Timers
タイマ
Two types of timer are required. The first type, known as a one-
shot timer, expires once and triggers an event. The second type,
known as an interval timer, expires at preset intervals. Interval
timers are used to trigger events at periodic intervals. The
granularity of both types of timers is one second.
タイマの2つのタイプが必要です。 1個のショットタイマとして知られている最初のタイプは、一度呼吸が絶えて、イベントの引き金となります。 インタバルタイマとして知られているタイプが呼吸が絶える2番目は間隔をあらかじめセットしました。 インタバルタイマは、周期的な間隔で、イベントの引き金となるのに使用されます。 両方のタイプのタイマの粒状は1秒です。
Interval timers should be implemented in such a way as to avoid
drift. In some switch implementations, packet processing can
affect timer execution. For example, on a multi-access link with
multiple switches, regular broadcasts can lead to undesirable
synchronization of routing packets unless the interval timers have
been implemented to avoid drift. If it is not possible to
インタバルタイマはドリフトを避けるほどそのような方法で実装されるべきです。 いくつかのスイッチ実装では、パケット処理はタイマ実行に影響できます。 例えば、インタバルタイマがドリフトを避けるために実装されていないなら、複数のスイッチとのマルチアクセスリンクの上では、定期的な放送はルーティングパケットの望ましくない同期につながることができます。 それは可能ではありません。
Kane Informational [Page 12] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[12ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
implement drift-free timers, small random amounts of time should
be added to or subtracted from the timer interval at each firing.
無ドリフトのタイマ、少無作為の量の時間がタイマ間隔から加えられるべきであるかそれぞれ撃つのに引き算されているべきである道具。
List manipulation primitives
リスト操作基関数
Much of the functionality of VLSP is described here in terms of
its operation on lists of link state advertisements. Any
particular advertisement may be on many such lists. Implementation
of VLSP must be able to manipulate these lists, adding and
deleting constituent advertisements as necessary.
VLSPの機能性の多くがリンク州の広告のリストでここで操作で説明されます。 どんな特定の広告もそのような多くのリストにあるかもしれません。 必要に応じて構成している広告を加えて、削除して、VLSPの実装はこれらのリストを操ることができなければなりません。
Tasking support
サポートに仕事を課します。
Certain procedures described in this specification invoke other
procedures. At times, these other procedures should be executed
in-line -- that is, before the current procedure has finished.
This is indicated in the text by instructions to "execute" a
procedure. At other times, the other procedures are to be
executed only when the current procedure has finished. This is
indicated by instructions to "schedule" a task. Implementation of
VLSP must provide these two types of tasking support.
この仕様で説明されたある手順は他の手順を呼び出します。 時には、すなわち、終わる前にこれらの他の手順はインラインで実行されるべきです。 これは、手順を「実行する」ためにテキストで指示で示されます。 他の手順は現在の手順が他の時に終わったときだけ、実行されることです。 これは、タスクの「計画をする」ように指示で示されます。 VLSPの実装はサポートに仕事を課すこれらの2つのタイプを提供しなければなりません。
2.7 Organization of the Remainder of This Document
2.7 このドキュメントの残りの組織
The remainder of this document is organized as follows:
このドキュメントの残りは以下の通り組織化されます:
o Section 3 through Section 5 describe the primary data structures
used by the protocol. Note that this specification is presented
in terms of these data structures in order to make explanations
more precise. Implementations of the protocol must support the
functionality described, but need not use the exact data
structures that appear in this specification.
o セクション5を通したセクション3はプロトコルによって使用されるプライマリデータ構造について説明します。 この仕様が説明をより正確にするようにこれらのデータ構造で提示されることに注意してください。 プロトコルの実装は、説明された機能性をサポートしなければなりませんが、この仕様に現れる正確なデータ構造を使用する必要はありません。
o Section 6 through Section 9 describe the four operational stages
of the protocol: the discovery process, synchronizing the
databases, maintaining the databases, and calculating the set of
best paths.
o セクション9を通したセクション6はプロトコルの4つの操作上のステージについて説明します: データベースを維持して、データベースを同期させる発見プロセスと、最も良い経路のセットについて計算すること。
o Section 10 describes the processing of VLSP packets and presents
detailed descriptions of their formats.
o セクション10は、VLSPパケットの処理について説明して、それらの形式の詳述を提示します。
o Section 11 presents detailed descriptions of link state
advertisements.
o セクション11はリンク州の広告の詳述を提示します。
o Section 12 summarizes the protocol parameters.
o セクション12はプロトコルパラメタをまとめます。
Kane Informational [Page 13] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[13ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
3. Interface Data Structure
3. インタフェースデータ構造
The port over which a switch accesses a network link is known as the link interface. Each switch maintains a separate interface data structure for each network link.
スイッチがネットワークリンクにアクセスするポートはリンクインタフェースとして知られています。 各スイッチはそれぞれのネットワークリンクに別々のインタフェースデータ構造を維持します。
The following data items are associated with each interface:
以下のデータ項目は各インタフェースに関連しています:
Type
タイプ
The type of network to which the interface is attached -- point-
to-point or broadcast (multi-access). This data item is
initialized to point-to-point when the interface becomes
operational. If a second neighbor is detected on the link after
the first neighbor has been discovered, the link interface type is
changed to broadcast. The type remains as broadcast until the
interface is declared down, at which time the type reverts to
point-to-point.
インタフェースが付けているネットワークのタイプ--ポイントで指すか、または(マルチアクセス)を放送してください。 インタフェースが操作上になるとき、このデータ項目はポイントツーポイントに初期化されます。 最初の隣人を発見した後にリンクの上に2番目の隣人を検出するなら、放送するためにリンクインターフェース型を変えます。 タイプはインタフェースがタイプがどの時にポイントツーポイントに先祖帰りをするかとき下がっていると宣言されるまで放送されるように残っています。
Note: Previous versions of VLSP treated all links as if they were multi-access. Thus, if VLSP determines that a neighbor switch is running an older version of the protocol software (see Section 6.1), it will change the interface type to broadcast.
以下に注意してください。 扱われたVLSPの旧バージョンはまるでそれらがマルチアクセサリーであるかのようにすべてリンクされます。 したがって、VLSPが、隣人スイッチがプロトコル・ソフトウエアの旧式のバージョンを実行していることを決定すると(セクション6.1を見てください)、それは、放送するためにインターフェース型を変えるでしょう。
State
状態
The functional level of the interface. The state of the interface
is included in all switch link advertisements generated by the
switch, and is also used to determine whether full adjacencies are
allowed on the interface. See Section 3.1 for a complete
description of interface states.
インタフェースの機能的なレベル。 インタフェースの状態は、スイッチによって作られたすべてのスイッチリンク広告に含まれていて、また、完全な隣接番組がインタフェースに許容されているかどうか決定するのに使用されます。 界面準位の完全な記述に関してセクション3.1を見てください。
Interface identifier
インタフェース識別子
A 10-octet value that uniquely identifies the interface. This
value consists of the 6-octet base MAC address of the neighbor
switch, followed by the 4-octet local port number of the
interface.
唯一インタフェースを特定する10八重奏の値。 この値はインタフェースの4八重奏の地方のポートナンバーがあとに続いた隣人スイッチの6八重奏のベースMACアドレスから成ります。
Area ID
領域ID
A 4-octet value identifying the area. Since VLSP does not support
multiple areas, the value here is always zero.
領域を特定する4八重奏の値。 VLSPが複数の領域をサポートしないので、いつもここの値はゼロです。
Kane Informational [Page 14] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[14ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
HelloInterval
HelloInterval
The interval, in seconds, at which the switch sends VLSP Hello
packets over the interface. This parameter is not used on point-
to-point links.
秒の間隔。(その時、スイッチはインタフェースの上でパケットをVLSP Helloに送ります)。 このパラメタはポイントへのポイントリンクの上に使用されません。
SwitchDeadInterval
SwitchDeadInterval
The length of time, in seconds, that neighboring switches will
wait before declaring the local switch dNeighboring switches
秒の隣接しているスイッチが地方のスイッチdNeighboringが切り替わると宣言する前に待っている時間の長さ
A list of the neighboring switches attached to this network link.
This list is created during the discovery process. Adjacencies are
formed to one or more of these neighbors. The set of adjacent
neighbors can be determined by examining the states of the
neighboring switches as shown in their link state advertisements.
隣接しているスイッチのリストはこのネットワークリンクに付きました。 このリストは発見プロセスの間、作成されます。 隣接番組はこれらの隣人のより多くのひとりに形成されます。 隣接している隣人のセットは彼らのリンク州の広告に示されるように調べるのによる近所付き合いの州が切り替わることを決定している場合があります。
Designated switch
スイッチに指定されます。
The designated switch selected for the multi-access network link.
(A designated switch is not selected for a point-to-point link.)
This data item is initialized to zero when the switch comes on-
line, indicating that no designated switch has been chosen for the
link.
マルチアクセスネットワークリンクに選択された指定されたスイッチ。 (指定されたスイッチはポイントツーポイント接続に選択されません。) スイッチがオンになるとき、立ち並んでいて、指定されたスイッチが全くリンクに選ばれていないのを示しながら、このデータ項目はゼロに初期化されます。
Backup designated switch
スイッチに任命されたバックアップ
The backup designated switch selected for the multi-access network
link. (A backup designated switch is not selected for a point-
to-point link.) This data item is initialized to zero when the
switch comes on-line, indicating that no backup designated switch
has been chosen for the link.
バックアップはマルチアクセスネットワークリンクに選択されたスイッチを指定しました。 (スイッチに任命されたバックアップはポイントへのポイントリンクに選ばれません。) スイッチがオンラインで来るとき、このデータ項目はゼロに初期化されます、スイッチに任命されなかったバックアップが全くリンクに選ばれたのを示して。
Interface output cost(s)
インタフェース製作費(s)
The cost of sending a packet over the interface. The link cost is
expressed in the link state metric and must be greater than zero.
インタフェースの上にパケットを送る費用。 リンク費用は、リンク状態でメートル法で言い表されて、ゼロ以上であるに違いありません。
RxmtInterval
RxmtInterval
The number of seconds between link state advertisement
retransmissions, for adjacencies belonging to this interface. This
value is also used to time the retransmission of Database
Description and Link State Request packets.
リンク州の広告「再-トランスミッション」の間のこのインタフェースに属す隣接番組の秒数。 また、この値は、Database記述とLink州Requestパケットの「再-トランスミッション」を調節するのに使用されます。
Kane Informational [Page 15] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[15ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
3.1 Interface States
3.1 インタフェース州
This section describes the various states of a switch interface. The states are listed in order of progressing functionality. For example, the inoperative state is listed first, followed by a list of the intermediate states through which the interface passes before attaining the final, fully functional state. The specification makes use of this ordering by references such as "those interfaces in state greater than X".
このセクションはスイッチインタフェースの様々な州について説明します。 機能性を進行することの順に州は記載されています。 例えば、操業していない状態は最終的で、完全に機能的な状態に達する前にインタフェースが通る中間的州のリストがいうことになった記載された1番目です。 仕様は「Xより大きい状態のそれらのインタフェース」などの参照でこの注文を利用します。
Figure 1 represents the interface state machine, showing the progression of interface state changes. The arrows on the graph represent the events causing each state change. These events are described in Section 3.2. The interface state machine is described in detail in Section 3.3.
界面準位変化の進行を示して、図1は界面準位マシンを表します。 グラフの矢はそれぞれの州の変化を引き起こすイベントを表します。 これらのイベントはセクション3.2で説明されます。 界面準位マシンはセクション3.3で詳細に説明されます。
Down
下に
This is the initial state of the interface. In this state, the
interface is unusable, and no protocol traffic is sent or received
on the interface. In this state, interface parameters are set to
their initial values, all interface timers are disabled, and no
adjacencies are associated with the interface.
これはインタフェースの初期状態です。 この状態では、インタフェースが使用不可能であり、インタフェースにプロトコルトラフィックを全く送りもしませんし、受け取りもしません。 この状態では、インタフェース・パラメータはそれらの初期の値に設定されます、そして、すべてのインタフェースタイマが障害があります、そして、どんな隣接番組もインタフェースに関連していません。
Kane Informational [Page 16] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[16ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
+-------+
| any | Interface +----------+ Unloop Ind +----------+
| state | -----------> | Down | <----------- | Loopback |
+-------+ Down +----------+ +----------+
| ^
| Interface Up |
+-------+ [pt-to-pt] | |
| Point |<------------type? Loop Ind |
| to | | |
| Point | | [broadcast] |
+-------+ V +-------+
+-----------+ | any |
| Waiting | | state |
+-----------+ +-------+
|
Backup Seen |
| Wait Timer
|
|
+----------+ Neighbor V Neighbor +----------+
| DS | <------------> [ ] <------------> | DS Other |
+----------+ Change ^ Change +----------+
|
|
Neighbor Change |
|
V
+----------+
| Backup |
+----------+
+-------+ | いくらか| インタフェース+----------+ Unloopインディアン座+----------+ | 状態| ----------->| 下に| <、-、-、-、-、-、-、-、-、-、--、| ループバック| +-------+ +に----------+ +----------+ | ^ | 上に連結してください。| +-------+ [PtからPt]| | | ポイント| <、-、-、-、-、-、-、-、-、-、-、--タイプしますか? 輪のインディアン座| | to| | | | ポイント| | [放送]| +-------+ +に対して-------+ +-----------+ | いくらか| | 待ち| | 状態| +-----------+ +-------+ | 見られたバックアップ| | 待ちタイマ| | +----------+ 隣人V隣人+----------+ | DS| <、-、-、-、-、-、-、-、-、-、-、-->[ ]<。------------>| DS他です。| +----------+ 変化^変化+----------+ | | 隣人変化| | +に対して----------+ | バックアップ| +----------+
Figure 1: Interface State Machine
図1: 界面準位マシン
Loopback
ループバック
In this state, the switch interface is looped back, either in
hardware or in software. The interface is unavailable for regular
data traffic.
この状態では、スイッチインタフェースは逆、ハードウェアまたはソフトウェアで輪にされます。 インタフェースは定期的なデータ通信量を入手できません。
Point-to-Point
ポイントツーポイント
In this state, the interface is operational and is connected to a
physical point-to-point link. On entering this state, the switch
attempts to form an adjacency with the neighboring switch.
この状態では、インタフェースは、操作上であり、物理的なポイントツーポイント接続に接続されます。 この状態に入ると、スイッチは、隣接しているスイッチで隣接番組を形成するのを試みます。
Kane Informational [Page 17] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[17ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Waiting
待ち
In this state, the switch is attempting to identify the backup
designated switch for the link by monitoring the Hello packets it
receives. The switch does not attempt to select a designated
switch or a backup designated switch until it changes out of this
state, thereby preventing unnecessary changes of the designated
switch and its backup.
この状態では、スイッチは、リンクのためにそれが受けるHelloパケットをモニターすることによってスイッチに任命されたバックアップを特定するのを試みています。 スイッチは、この状態から変化するまでスイッチに任命された指定されたスイッチかバックアップを選ぶのを試みません、その結果、指定されたスイッチとそのバックアップの不要な変化を防ぎます。
DS Other
DS他です。
In this state, the interface is operational and is connected to a
multi-access broadcast link on which other switches have been
selected as the designated switch and the backup designated
switch. On entering this state, the switch attempts to form
adjacencies with both the designated switch and the backup
designated switch.
この状態では、インタフェースは、操作上であり、指定されたスイッチとバックアップがスイッチを指定したので他のスイッチが選択されたマルチアクセス放送リンクに接続されます。 この状態に入ると、指定されたスイッチとバックアップの両方が任命されている状態で隣接番組を形成するスイッチ試みは切り替わります。
Backup
バックアップ
In this state, the switch itself is the backup designated switch
on the attached multi-access broadcast link. It will be promoted
to designated switch if the current designated switch fails. The
switch establishes adjacencies with all other switches attached to
the link. (See Section 6.3 for more information on the functions
performed by the backup designated switch.)
この状態では、スイッチ自体は付属マルチアクセス放送リンクの上のスイッチに任命されたバックアップです。 現在の指定されたスイッチが失敗するなら、それは指定されたスイッチに促進されるでしょう。 他のすべてのスイッチがリンクに取り付けられている状態で、スイッチは隣接番組を確立します。 (機能に関する詳しい情報のためのセクション6.3がスイッチに任命されたバックアップによって実行されるのを見てください。)
DS
DS
In this state, this switch itself is the designated switch on the
attached multi-access broadcast link. The switch establishes
adjacencies with all other switches attached to the link. The
switch is responsible for originating network link advertisements
for the link, containing link information for all switches
attached to the link, including the designated switch itself.
(See Section 6.3 for more information on the functions performed
by the designated switch.)
この状態では、このスイッチ自体は付属マルチアクセス放送リンクの上の指定されたスイッチです。 他のすべてのスイッチがリンクに取り付けられている状態で、スイッチは隣接番組を確立します。 スイッチはネットワークリンク広告をリンクに溯源するのに原因となります、リンクに取り付けられたすべてのスイッチのためのリンク情報を含んでいて、指定されたスイッチ自体を含んでいて。 (機能に関する詳しい情報のためのセクション6.3が指定されたスイッチによって実行されるのを見てください。)
3.2 Events Causing Interface State Changes
インタフェースを引き起こす3.2のイベントが変化を述べます。
The state of an interface changes due to an interface event. This section describes these events.
インタフェースの状態はインタフェースイベントのため変化します。 このセクションはこれらのイベントについて説明します。
Interface events are shown as arrows in Figure 1, the graphic representation of the interface state machine. For more information on the interface state machine, see Section 3.3.
インタフェースイベントは矢として図1、界面準位マシンのグラフィック表示で示されます。 界面準位マシンの詳しい情報に関しては、セクション3.3を見てください。
Kane Informational [Page 18] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[18ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Interface Up
上に連結してください。
This event is generated by the VlanHello protocol [IDhello] when
it discovers a neighbor switch on the interface. The interface is
now operational. This event causes the interface to change out of
the Down state. The state it enters is determined by the
interface type. If the interface type is broadcast (multi-
access), this event also causes the switch to begin sending
periodic Hello packets out over the interface.
インタフェースで隣人スイッチを発見すると、VlanHelloプロトコル[IDhello]によってこのイベントは生成されます。 インタフェースは現在、操作上です。 このイベントで、インタフェースはDown状態から変化します。 それが入る状態はインターフェース型によって決定されます。 また、インターフェース型が放送されるなら(マルチアクセス)、このイベントで、スイッチは周期的なHelloパケットをインタフェースの上に出し始めます。
Wait Timer
待ちタイマ
This event is generated when the one-shot Wait timer expires,
triggering the end of the required waiting period before the
switch can begin the process of selecting a designated switch and
a backup designated switch on a multi-access link.
1回限りのWaitタイマが期限が切れるとき、このイベントは発生しています、スイッチがマルチアクセスリンクの上のスイッチに任命された指定されたスイッチとバックアップを選ぶプロセスを開始できる前に必要な待ちの期間の終わりの引き金となって。
Backup Seen
見られたバックアップ
This event is generated when the switch has detected the existence
or non-existence of a backup designated switch for the link, as
determined in one of the following two ways:
スイッチがリンクのためにスイッチに任命されたバックアップの存在か非存在を検出したとき、このイベントは発生しています、以下の2つの方法の1つで決定するように:
o A Hello packet has been received from a neighbor that claims to
be the backup designated switch.
o スイッチに任命されたバックアップであると主張する隣人からHelloパケットを受け取りました。
o A Hello packet has been received from a neighbor that claims to
be the designated switch. In addition, the packet indicated
that there is no backup.
o 指定されたスイッチであると主張する隣人からHelloパケットを受け取りました。 さらに、パケットは、バックアップが全くないのを示しました。
In either case, the interface must have bidirectional communication with its neighbor -- that is, the local switch must be listed in the neighbor's Hello packet.
どちらの場合ではも、インタフェースは隣人との双方向のコミュニケーションを持たなければなりません--隣人のHelloパケットにすなわち、地方のスイッチを記載しなければなりません。
This event signals the end of the Waiting state.
このイベントはWaiting状態の端を示します。
Neighbor change
隣人変化
This event is generated when there has been one of the following
changes in the set of bidirectional neighbors associated with the
interface. (See Section 4.1 for information on neighbor states.)
インタフェースに関連している双方向の隣人のセットにおける以下の変化の1つがあったとき、このイベントは発生しています。 (隣人州の情報に関してセクション4.1を見てください。)
o Bidirectional communication has been established with a
neighbor -- the state of the neighbor has changed to 2-Way or
higher.
o 双方向のコミュニケーションは隣人と共に確立されました--隣人の状態は2方法か、より高く変化しました。
o Bidirectional communication with a neighbor has been lost --
the state of the neighbor has changed to Init or lower.
o 隣人との双方向のコミュニケーションは失われました--隣人の状態はInitか下側に変化しました。
Kane Informational [Page 19] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[19ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o A bidirectional neighbor has just declared itself to be either
the designated switch or the backup designated switch, as
detected by examination of that neighbor's Hello packets.
o 双方向の隣人は、それ自体がスイッチに任命された指定されたスイッチかバックアップのどちらかであるとちょうど宣言したところです、その隣人のHelloパケットの試験で検出されるように。
o A bidirectional neighbor is no longer declaring itself to be
either the designated switch or the backup designated switch,
as detected by examination of that neighbor's Hello packets.
o 双方向の隣人は、もうそれ自体がスイッチに任命された指定されたスイッチかバックアップのどちらかであると宣言していません、その隣人のHelloパケットの試験で検出されるように。
o The advertised switch priority of a bidirectional neighbor has
changed, as detected by examination of that neighbor's Hello
packets.
o 双方向の隣人の広告を出しているスイッチ優先権はその隣人のHelloパケットの試験で検出されるように変化しました。
When this event occurs, the designated switch and the backup
designated switch must be reselected.
このイベントが起こると、指定されたスイッチとスイッチに任命されたバックアップを再選択しなければなりません。
Loop Ind
輪のインディアン座
This event is generated when an interface enters the Loopback
state. This event can be generated by either the network
management service or by the lower-level protocols.
インタフェースがLoopback状態に入るとき、このイベントは発生しています。 ネットワーク管理サービスか低レベルプロトコルはこのイベントを生成することができます。
Unloop Ind
Unloopインディアン座
This event is generated when an interface leaves the Loopback
state. This event can be generated by either the network
management service or by the lower-level protocols.
インタフェースがLoopbackを状態に発つとき、このイベントは発生しています。 ネットワーク管理サービスか低レベルプロトコルはこのイベントを生成することができます。
Interface Down
インタフェースはダウンします。
This event is generated under the following two circumstances:
このイベントは以下の2つの状況で生成されます:
o The VlanHello [IDhello] protocol has determined that the
interface is no longer functional.
o VlanHello[IDhello]プロトコルは、インタフェースがもう機能的でないことを決定しました。
o The neighbor state machine has detected a second neighboring
switch on a link presumed to be of type point-to-point. In
addition to generating the Interface Down event, the
neighbor state machine changes the interface type to
broadcast.
o 隣人州のマシンはタイプポイントツーポイントがあえてあったリンクの上の2番目の隣接しているスイッチを検出しました。 Interface Downイベントを生成することに加えて、隣人州のマシンは、放送するためにインターフェース型を変えます。
In both instances, this event forces the interface state to Down.
However, when the event is generated by the neighbor state
machine, it is immediately followed by an Interface Up event.
(See Section 4.3.)
両方のインスタンスでは、このイベントはDownに界面準位を強制します。 しかしながら、イベントがすぐに隣人州のマシンによって生成されるとき、Interface Upイベントはそれのあとに続いています。 (セクション4.3を見てください。)
Kane Informational [Page 20] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[20ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
3.3 Interface State Machine
3.3 界面準位マシン
This section presents a detailed description of the interface state machine.
このセクションは界面準位マシンの詳述を提示します。
Interface states (see Section 3.1) change as the result of various events (see Section 3.2). However, the effect of each event can vary, depending on the current state of the interface. For this reason, the state machine described in this section is organized according to the current interface state and the occurring event. For each state/event pair, the new interface state is listed, along with a description of the required processing.
界面準位(セクション3.1を見る)は様々なイベントの結果として変化します(セクション3.2を見てください)。 しかしながら、インタフェースの現状のときによって、それぞれのイベントの効果は異なることができます。 この理由で、現在の界面準位と発生イベントに従って、このセクションで説明された州のマシンは組織化されます。 それぞれの状態/イベント組において、新しい界面準位は必要な処理の記述と共に記載されています。
Note that when the state of an interface changes, it may be necessary to originate a new switch link advertisement. See Section 8.1 for more information.
インタフェースの状態が変化するとき、新しいスイッチリンク広告を溯源するのが必要であるかもしれないことに注意してください。 詳しい情報に関してセクション8.1を見てください。
Some of the processing described here includes generating events for the neighbor state machine. For example, when an interface becomes inoperative, all neighbor connections associated with the interface must be destroyed. For more information on the neighbor state machine, see Section 4.3.
ここで説明された処理のいくつかが、隣人州のマシンのためにイベントを生成するのを含んでいます。 インタフェースが効力がなくなるとき、例えば、インタフェースに関連づけられたすべての隣人接続を滅ぼさなければなりません。 隣人州のマシンの詳しい情報に関しては、セクション4.3を見てください。
State(s): Down
Event: Interface Up
New state: Depends on action routine
Action:
If the interface is a point-to-point link, set the interface state
to Point-to-Point. Otherwise, start the Hello interval timer,
enabling the periodic sending of Hello packets over the interface.
If the switch is not eligible to become the designated switch,
change the interface state to DS Other. Otherwise, set the
interface state to Waiting and start the one-shot wait timer.
Create a new neighbor data structure for the neighbor switch,
initialize all neighbor parameters and set the stateof the
neighbor to Down.
州: イベントの下側に: Up New状態を連結してください: 動作の通常のActionによります: インタフェースがポイントツーポイント接続であるなら、指すPointに界面準位を設定してください。 さもなければ、インタフェースの上でHelloパケットの周期的な発信を可能にして、Helloインタバルタイマを始動してください。 スイッチが指定されたスイッチになるのが適任でないなら、界面準位をDS Otherに変えてください。 さもなければ、Waitingに界面準位を設定してください、そして、1回限りの待ちタイマを始動してください。 隣人スイッチのために新しい隣人データ構造を作成してください、そして、すべての隣人パラメタを初期化してください、そして、stateofを設定してください。Downへの隣人。
State(s): Waiting
Event: Backup Seen
New state: Depends on action routine
Action:
Select the designated switch and backup designated switch for the
attached link, as described in Section 6.3.1. As a result of this
selection, set the new state of the interface to either DS Other,
Backup or DS.
州: イベントを待っています: Seen New状態のバックアップをとってください: 動作の通常のActionによります: 付属リンクのためにセクション6.3.1で説明されるようにスイッチに任命された指定されたスイッチとバックアップを選んでください。 この選択の結果、DS Other、BackupかDSのどちらかにインタフェースの新しい状態を設定してください。
Kane Informational [Page 21] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[21ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
State(s): Waiting
Event: Wait Timer
New state: Depends on action routine
Action:
Select the designated switch and backup designated switch for the
attached link, as described in Section 6.3.1. As a result of this
selection, set the new state of the interface to either DS Other,
Backup or DS.
州: イベントを待っています: Timer New状態を待ってください: 動作の通常のActionによります: 付属リンクのためにセクション6.3.1で説明されるようにスイッチに任命された指定されたスイッチとバックアップを選んでください。 この選択の結果、DS Other、BackupかDSのどちらかにインタフェースの新しい状態を設定してください。
State(s): DS Other, Backup or DS
Event: Neighbor Change
New state: Depends on action routine
Action:
Reselect the designated switch and backup designated switch for
the attached link, as described in Section 6.3.1. As a result of
this selection, set the new state of the interface to either DS
Other, Backup or DS.
州: DSもう一方、バックアップまたはDSイベント: 隣人Change New州: 動作の通常のActionによります: 付属リンクのためにセクション6.3.1で説明されるようにスイッチに任命された指定されたスイッチとバックアップのReselect。 この選択の結果、DS Other、BackupかDSのどちらかにインタフェースの新しい状態を設定してください。
State(s): Any State
Event: Interface Down
New state: Down
Action:
Reset all variables in the interface data structure and disable
all timers. In addition, destroy all neighbor connections
associated with the interface by generating the KillNbr event on
all neighbors listed in the interface data structure.
州: どんな州のイベントも: Down New状態を連結してください: 動作の下側に: インタフェースデータ構造ですべての変数をリセットしてください、そして、すべてのタイマを損傷してください。 さらに、インタフェースデータ構造で記載されたすべての隣人の上でKillNbrイベントを生成することによって、インタフェースに関連づけられたすべての隣人接続を滅ぼしてください。
State(s): Any State
Event: Loop Ind
New state: Loopback
Action:
Reset all variables in the interface data structure and disable
all timers. In addition, destroy all neighbor connections
associated with the interface by generating the KillNbr event on
all neighbors listed in the interface data structure.
州: どんな州のイベントも: インディアン座New状態を輪にしてください: ループバック動作: インタフェースデータ構造ですべての変数をリセットしてください、そして、すべてのタイマを損傷してください。 さらに、インタフェースデータ構造で記載されたすべての隣人の上でKillNbrイベントを生成することによって、インタフェースに関連づけられたすべての隣人接続を滅ぼしてください。
State(s): Loopback
Event: Unloop Ind
New state: Down
Action:
No action is necessary beyond changing the interface state to Down
because the interface was reset on entering the Loopback state.
州: ループバックイベント: Unloopインディアン座New州: 動作の下側に: インタフェースがLoopback状態に入るときリセットされたので界面準位をDownに変えることを超えてどんな動作も必要ではありません。
Kane Informational [Page 22] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[22ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
4. Neighbor Data Structure
4. 隣人データ構造
Each switch conducts a conversation with its neighboring switches and each conversation is described by a neighbor data structure. A conversation is associated with a switch interface, and is identified by the neighboring switch ID.
各スイッチは隣接しているスイッチとの会話を行います、そして、各会話は隣人データ構造によって説明されます。 会話は、スイッチインタフェースに関連していて、隣接しているスイッチIDによって特定されます。
Note that if two switches have multiple attached links in common, multiple conversations ensue, each described by a unique neighbor data structure. Each separate conversation is treated as a separate neighbor.
一般的な倍数の会話における複数の付属リンクが2個のスイッチで続くなら、それに注意してください、とそれぞれがユニークな隣人データ構造で説明しました。 それぞれの別々の会話は別々の隣人として扱われます。
The neighbor data structure contains all information relevant to any adjacency formed between the two neighbors. Remember, however, that not all neighbors become adjacent. An adjacency can be thought of as a highly developed conversation between two switches.
隣人データ構造は2人の隣人の間で形成されたどんな隣接番組にも関連しているすべての情報を含んでいます。 しかしながら、すべての隣人が隣接するようになるというわけではないのを覚えていてください。 2個のスイッチでの高度な会話として隣接番組を考えることができます。
State
状態
The functional level of the neighbor conversation. See Section
4.1 for a complete description of neighbor states.
隣人の会話の機能的なレベル。 隣人州の完全な記述に関してセクション4.1を見てください。
Inactivity timer
不活発タイマ
A one-shot timer used to determine when to declare the neighbor
down if no Hello packet is received from this (multi-access)
neighbor. The length of the timer is SwitchDeadInterval seconds,
as contained in the neighbor's Hello packet. This timer is not
used on point-to-point links.
1回限りのタイマは、以前はよくこの(マルチアクセス)隣人からHelloパケットを全く受け取らないなら隣人がダウンするといつ宣言するかを決定していました。 タイマの長さは隣人のHelloパケットに含まれているようにSwitchDeadInterval秒です。 このタイマはポイントツーポイント接続の上で使用されません。
Master/slave flag
マスター/奴隷旗
A flag indicating whether the local switch is to act as the master
or the slave in the database exchange process (see Section 7.2).
The master/slave relationship is negotiated when the conversation
changes to the ExStart state.
地方のスイッチがマスターか奴隷としてデータベース交換プロセスで務めることになっているかどうかを(セクション7.2を見てください)示す旗。 会話がExStart状態に変化するとき、マスター/奴隷関係は交渉されます。
Sequence number
一連番号
A 4-octet number identifying individual Database Description
packets. When the neighbor state ExStart is entered and the
database exchange process is started, the sequence number is set
to a value not previously seen by the neighboring switch. (One
possible scheme is to use the switch's time of day counter.) The
sequence number is then incremented by the master with each new
Database Description packet sent. See Section 7.2 for more
information on the database exchange process.
個々のDatabase記述パケットを特定する4八重奏の数。 隣人州のExStartが入られて、データベース交換の過程が始められるとき、一連番号は以前に隣接しているスイッチによって見られなかった値に設定されます。 (1つの可能な計画はスイッチの時刻カウンタを使用することです。) そして、一連番号はそれぞれの新しいDatabase記述パケットを送ってマスターによって増加されます。 データベース交換の過程の詳しい情報に関してセクション7.2を見てください。
Kane Informational [Page 23] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[23ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Neighbor ID
隣人ID
The switch ID of the neighboring switch, as discovered by the
VlanHello protocol [IDhello] or contained in the neighbor's Hello
packets.
VlanHelloプロトコル[IDhello]によって発見されるか、または隣人のHelloパケットに含まれているような隣接しているスイッチのスイッチID。
Neighbor priority
隣人優先権
The switch priority of the neighboring switch, as contained in the
neighbor's Hello packets. Switch priorities are used when
selecting the designated switch for the attached multi-access
link. Priority is not used on point-to-point links.
隣人のHelloパケットに含まれているような隣接しているスイッチのスイッチ優先権。 付属マルチアクセスリンクに指定されたスイッチを選択するとき、スイッチプライオリティは使用されています。 優先権はポイントツーポイント接続の上で使用されません。
Interface identifier
インタフェース識別子
A 10-octet value that uniquely identifies the interface over which
this conversation is being held. This value consists of the 6-
octet base MAC address of the neighbor switch, followed by the 4-
octet local port number of the interface.
唯一、この会話が保持されているインタフェースを特定する10八重奏の値。 この値はインタフェースの4の八重奏の地方のポートナンバーがあとに続いた隣人スイッチの6八重奏ベースMACアドレスから成ります。
Neighbor's designated switch
隣人はスイッチに任命されました。
The switch ID identifying the neighbor's idea of the designated
switch, as contained in the neighbor's Hello packets. This value
is used in the local selection of the designated switch. It is
not used on point-to-point links.
隣人のHelloパケットに含まれているように指定されたスイッチに関する隣人の考えを特定するスイッチID。 この値は指定されたスイッチの局所的選択に使用されます。 それはポイントツーポイント接続の上で使用されません。
Neighbor's backup designated switch
スイッチに任命された隣人のバックアップ
The switch ID identifying the neighbor's idea of the backup
designated switch, as contained in the neighbor's Hello packets.
This value is used in the local selection of the backup designated
switch. It is not used on point-to-point links.
バックアップに関する隣人の考えを特定するスイッチIDは隣人のHelloパケットに含まれているようにスイッチを指定しました。 この値はスイッチに任命されたバックアップの局所的選択に使用されます。 それはポイントツーポイント接続の上で使用されません。
Link state retransmission list
リンク州の「再-トランスミッション」リスト
The list of link state advertisements that have been forwarded
over but not acknowledged on this adjacency. The local switch
retransmits these link state advertisements at periodic intervals
until they are acknowledged or until the adjacency is destroyed.
(For more information on retransmitting link state advertisements,
see Section 8.2.5.)
この隣接番組で進められましたが、承認されなかったリンク州の広告のリスト。 周期的なそれらが承認されるまでの間隔か隣接番組が破壊されるまで、地方のスイッチはこれらのリンク州の広告を再送します。 (リンク州の広告を再送する詳しい情報に関して、セクション8.2.5を見てください。)
Kane Informational [Page 24] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[24ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Database summary list
データベース概要リスト
The set of link state advertisement headers that summarize the
local link state database. When the conversation changes to the
Exchange state, this list is sent to the neighbor via Database
Description packets. (For more information on the synchronization
of databases, see Section 7.)
ローカルのリンク州のデータベースをまとめるリンク州の広告ヘッダーのセット。 会話がExchange状態に変化するとき、Database記述パケットを通してこのリストを隣人に送ります。 (データベースの同期の詳しい情報に関して、セクション7を見てください。)
Link state request list
リンク州の要求リスト
The list of link state advertisements that must be received in
order to synchronize with the neighbor switch's link state
database. This list is created as Database Description packets
are received, and is then sent to the neighbor in Link State
Request packets. (For more information on the synchronization of
databases, see Section 7.)
隣人スイッチのリンク州のデータベースに連動するように受け取らなければならないリンク州の広告のリスト。 このリストは、Database記述パケットが受け取られているので作成されて、Link州Requestパケットの隣人に送って、その時です。 (データベースの同期の詳しい情報に関して、セクション7を見てください。)
4.1 Neighbor States
4.1 隣人州
This section describes the various states of a conversation with a neighbor switch. The states are listed in order of progressing functionality. For example, the inoperative state is listed first, followed by a list of the intermediate states through which the conversation passes before attaining the final, fully functional state. The specification makes use of this ordering by references such as "those neighbors/adjacencies in state greater than X".
このセクションは隣人スイッチとの会話の様々な州について説明します。 機能性を進行することの順に州は記載されています。 例えば、操業していない状態は最終的で、完全に機能的な状態に達する前に会話が終わる中間的州のリストがいうことになった記載された1番目です。 仕様は「Xより大きい状態のそれらの隣人/隣接番組」などの参照でこの注文を利用します。
Figure 2 represents the neighbor state machine. The arrows on the graph represent the events causing each state change. These events are described in Section 4.2. The neighbor state machine is described in detail in Section 4.3.
図2は隣人州のマシンを表します。 グラフの矢はそれぞれの州の変化を引き起こす出来事を表します。 これらの出来事はセクション4.2で説明されます。 隣人州のマシンはセクション4.3で詳細に説明されます。
Down
下に
This is the initial state of a neighbor conversation.
これは隣人の会話の初期状態です。
Init
イニット
In this state, the neighbor has been discovered, but bidirectional
communication has not yet been established. All neighbors in this
state or higher are listed in the VLS Hello packets sent by the
local switch over the associated (multi-access) interface.
この状態では、隣人は発見されましたが、双方向のコミュニケーションはまだ確立されていません。 この状態か、より高いところのすべての隣人が関連している(マルチアクセスしている)インタフェースの上に地方のスイッチによって送られたVLS Helloパケットに記載されています。
Kane Informational [Page 25] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[25ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
+----------+ KillNbr, LLDown, +-----------+
| Down | <--------------------- | any state |
+----------+ or Inactivity Timer +-----------+
|
Hello |
Rcvd |
|
V
+-----< [pt-to-pt?]
| yes |
| | no
| V
| +----------+ 1-Way +----------+
| | Init | <-------- | >= 2-way |
| +----------+ +----------+
| |
| 2-Way |
| Rcvd | +-------+ AdjOK? +------------+
| +----------------> | 2-Way | <------- | >= ExStart |
| | (no adjacency) +-------+ no +------------+
| |
| V
| +---------+ Seq Number Mismatch +-------------+
+----> | ExStart | <--------------------- | >= Exchange |
+---------+ or BadLSReq +-------------+
|
Negotiation |
Done |
V
+----------+
| Exchange |
+----------+
|
Exchange | +--------+
Done +----------------------> | Full |
| (request list empty) +--------+
| ^
V |
+---------+ Loading Done |
| Loading | ----------------------->
+---------+
+----------+ KillNbr、LLDown、+-----------+ | 下に| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| どんな状態| +----------+か不活発タイマ+-----------+ | こんにちは| Rcvd| | +に対して-----<[PtからPt?] | はい| | | いいえ| V| +----------+ 1ウェイ+----------+ | | イニット| <、-、-、-、-、-、-、--、| >= 2ウェイ| | +----------+ +----------+ | | | 2ウェイ| | Rcvd| +-------+ AdjOK? +------------+ | +---------------->| 2ウェイ| <、-、-、-、-、-、--、| >= ExStart| | | (隣接番組がありません) +-------+ +がありません。------------+ | | | V| +---------+ Seq数のミスマッチ+-------------+ +---->| ExStart| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| >= 交換| +---------+かBadLSReq+-------------+ | 交渉| します。| +に対して----------+ | 交換| +----------+ | 交換| +--------+が行われた+---------------------->| 完全| | (要求リスト空)です。 +--------+ | ^V| +---------+ 行われたローディング| | ローディング| ----------------------->+---------+
Figure 2: Neighbor State Machine
図2: 隣人州のマシン
Kane Informational [Page 26] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[26ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
2-Way
2ウェイ
In this state, communication between the two switches is
bidirectional. This is the most advanced state short of beginning
to establish an adjacency. On a multi-access link, the designated
switch and the backup designated switch are selected from the set
of neighbors in state 2-Way or greater.
この状態では、2個のスイッチのコミュニケーションは双方向です。 これによる大部分が隣接番組を確立し始めるのに不足していた状態で状態を進めたということです。 マルチアクセスリンクでは、指定されたスイッチとスイッチに任命されたバックアップは、隣人のセットから2州の方法で選択されているか、または、より偉大です。
ExStart
ExStart
This state indicates that the two switches have begun to establish
an adjacency by determining which switch is the master, as well as
the initial sequence number for Database Descriptor packets.
Neighbor conversations in this state or greater are called
adjacencies.
この州は、どのスイッチがマスターであるかを決定することによって2個のスイッチが隣接番組を確立し始めたのを示します、Database Descriptorパケットの初期シーケンス番号と同様に。 この状態か、よりすばらしいところの隣人の会話は隣接番組と呼ばれます。
Exchange
交換
In this state, the switches are exchanging Database Description
packets. (See Section 7.2 for a complete description of this
process.) All adjacencies in the Exchange state or greater are
used by the distribution procedure (see Section 8.2), and are
capable of transmitting and receiving all types of VLSP routing
packets.
この状態では、スイッチはDatabase記述パケットを交換しています。 (この過程の完全な記述に関してセクション7.2を見てください。) Exchange状態か、よりすばらしいところのすべての隣接番組が、すべてのタイプのVLSPルーティングパケットを分配手順(セクション8.2を見る)で使用されて、送信して、受けることができます。
Loading
ローディング
In this state, the local switch is sending Link State Request
packets to the neighbor asking for the more recent advertisements
that were discovered in the Exchange state.
この状態では、地方のスイッチはExchange状態で発見されたより最近の広告を求める隣人への州RequestパケットをLinkに送ります。
Full
完全
In this state, the two switches are fully adjacent. These
adjacencies will now appear in switch link and network link
advertisements generated for the link.
この状態では、2個のスイッチが完全に隣接しています。 これらの隣接番組は今、リンクに作られたスイッチリンクとネットワークリンク広告に載るでしょう。
4.2 Events Causing Neighbor State Changes
隣人を引き起こす4.2回の出来事が変化を述べます。
The state of a neighbor conversation changes due to neighbor events. This section describes these events.
隣人の会話の状態は隣人出来事のため変化します。 このセクションはこれらの出来事について説明します。
Neighbor events are shown as arrows in Figure 2, the graphic representation of the neighbor state machine. For more information on the neighbor state machine, see Section 4.3.
隣人出来事は矢として図2、隣人州のマシンのグラフィック表示で示されます。 隣人州のマシンの詳しい情報に関しては、セクション4.3を見てください。
Kane Informational [Page 27] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[27ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Hello Received
こんにちは、受け取られている。
This event is generated when a Hello packet has been received from
a neighbor.
隣人からHelloパケットを受け取ったとき、この出来事を発生させます。
2-Way Received
2ウェイは受信されました。
This event is generated when the local switch sees its own switch
ID listed in the neighbor's Hello packet, indicating that
bidirectional communication has been established between the two
switches.
地方のスイッチが、それ自身のスイッチIDが隣人のHelloパケットに記載されているのを見ると、この出来事は発生します、双方向のコミュニケーションが2個のスイッチの間で確立されたのを示して。
Negotiation Done
行われた交渉
This event is generated when the master/slave relationship has
been successfully negotiated and initial packet sequence numbers
have been exchanged. This event signals the start of the database
exchange process (see Section 7.2).
首尾よくマスター/奴隷関係を交渉して、初期のパケット一連番号を交換したとき、この出来事を発生させます。 この出来事はデータベース交換の過程の始まりに合図します(セクション7.2を見てください)。
Exchange Done
行われた交換
This event is generated when the database exchange process is
complete and both switches have successfully transmitted a full
sequence of Database Description packets. (For more information
on the database exchange process, see Section 7.2.)
データベース交換の過程が完了していて、両方のスイッチが首尾よくDatabase記述パケットの完全な系列を伝えたとき、この出来事は発生します。 (データベース交換の過程の詳しい情報に関して、セクション7.2を見てください。)
BadLSReq
BadLSReq
This event is generated when a Link State Request has been
received for a link state advertisement that is not contained in
the database. This event indicates an error in the
synchronization process.
データベースに含まれていないリンク州の広告のためにLink州Requestを受け取ったとき、この出来事を発生させます。 この出来事は同期の過程における誤りを示します。
Loading Done
行われたローディング
This event is generated when all Link State Updates have been
received for all out-of-date portions of the database. (See
Section 7.3.)
すべてのLink州Updatesが日付のすべて外のためのデータベースの容認された部分であるときに、この出来事は発生します。 (セクション7.3を見てください。)
AdjOK?
AdjOK?
This event is generated when a decision must be made as to whether
an adjacency will be established or maintained with the neighbor.
This event will initiate some adjacencies and destroy others.
隣接番組が隣人と共に確立されるか、または維持されるかに関して決定をしなければならないとき、この出来事を発生させます。 この出来事は、いくつかの隣接番組を開始して、他のものを滅ぼすでしょう。
Kane Informational [Page 28] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[28ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Seq Number Mismatch
Seq数のミスマッチ
This event is generated when a Database Description packet has
been received with any of the following conditions:
以下の条件のどれかでDatabase記述パケットを受け取ったとき、この出来事を発生させます:
o The packet contains an unexpected sequence number.
o The packet (unexpectedly) has the Init bit set.
o The packet has a different Options field than was
previously seen.
o パケットは予期していなかった一連番号を含んでいます。○ パケットは(不意に)Initビットを設定します。○ パケットには、以前に見られたのと異なったOptions分野があります。
These conditions all indicate that an error has occurred during
the establishment of the adjacency.
これらの状態はすべて、誤りが隣接番組の設立の間発生しているのを示します。
1-Way
1ウェイ
This event is generated when bidirectional communication with the
neighbor has been lost. That is, a Hello packet has been received
from the neighbor in which the local switch is not listed.
隣人との双方向のコミュニケーションが失われたとき、この出来事は発生します。 地方のスイッチが記載されていない隣人からすなわち、Helloパケットを受け取りました。
KillNbr
KillNbr
This event is generated when further communication with the
neighbor is impossible.
隣人とのさらなるコミュニケーションが不可能であるときに、この出来事は発生します。
Inactivity Timer
不活発タイマ
This event is generated when the inactivity timer has expired,
indicating that no Hello packets have been received from the
neighbor in SwitchDeadInterval seconds. This timer is used only
on broadcast (multi-access) links.
不活発タイマが期限が切れたとき、この出来事は発生します、Helloパケットが全くSwitchDeadInterval秒に隣人から受け取られていないのを示して。 このタイマは放送(マルチアクセス)リンクだけの上に使用されます。
LLDown
LLDown
This event is generated by the lower-level switch discovery
protocols and indicates that the neighbor is now unreachable.
この出来事は、低レベルスイッチ発見プロトコルによって発生されて、隣人が現在手が届かないのを示します。
4.3 Neighbor State Machine
4.3 隣人州のマシン
This section presents a detailed description of the neighbor state machine.
このセクションは隣人州のマシンの詳述を提示します。
Neighbor states (see Section 4.1) change as the result of various events (see Section 4.2). However, the effect of each event can vary, depending on the current state of the conversation with the neighbor. For this reason, the state machine described in this section is organized according to the current neighbor state and the occurring event. For each state/event pair, the new neighbor state is listed, along with a description of the required processing.
隣人州(セクション4.1を見る)は様々な出来事の結果として変化します(セクション4.2を見てください)。 しかしながら、隣人との会話の現状のときによって、それぞれの出来事の効果は異なることができます。 この理由で、現在の隣人状態と発生出来事に従って、このセクションで説明された州のマシンは組織化されます。 それぞれの状態/イベント組において、新しい隣人状態は必要な処理の記述と共に記載されています。
Kane Informational [Page 29] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[29ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Note that when the neighbor state changes as a result of an interface Neighbor Change event (see Section 3.2), it may be necessary to rerun the designated switch selection algorithm. In addition, if the interface associated with the neighbor conversation is in the DS state (that is, the local switch is the designated switch), changes in the neighbor state may cause a new network link advertisement to be originated (see Section 8.1).
隣人がインタフェースNeighbor Change出来事の結果、変化を述べるとき(セクション3.2を見てください)、指定されたスイッチ選択アルゴリズムを再放送するのが必要であるかもしれないことに注意してください。 さらに、隣人の会話に関連しているインタフェースがDS状態にあるなら(すなわち、地方のスイッチは指定されたスイッチです)、隣人状態の変化で、新しいネットワークリンク広告を溯源するかもしれません(セクション8.1を見てください)。
When the neighbor state machine must invoke the interface state machine, it is invoked as a scheduled task. This simplifies processing, by ensuring that neither state machine executes recursively.
隣人州のマシンが界面準位マシンを呼び出さなければならないとき、それは予定されているタスクとして呼び出されます。 どちらも、マシンが再帰的に実行すると述べないのを確実にすることによって、これは処理を簡素化します。
State(s): Down
Event: Hello Received
New state: Depends on the interface type
Action:
If the interface type of the associated link is point-to-point,
change the neighbor state to ExStart. Otherwise, change the
neighbor state to Init and start the inactivity timer for the
neighbor. If the timer expires before another Hello packet is
received, the neighbor switch is declared dead.
州: 出来事の下側に: こんにちは、Received Newは述べます: インターフェース型Actionによります: 関連リンクのインターフェース型が二地点間であるなら、隣人状態をExStartに変えてください。 さもなければ、隣人状態をInitに変えてください、そして、隣人のために不活発タイマを始動してください。 別のHelloパケットが受け取られている前にタイマが期限が切れるなら、隣人スイッチは死んでいると申告されます。
State(s): Init or greater
Event: Hello Received
New state: No state change
Action:
If the interface type of the associated link is point-to-point,
determine whether this notification is for a different neighbor
than the one previously seen. If so, generate an Interface Down
event for the associated interface, reset the interface type to
broadcast and generate an Interface Up event.
州: イニットか、よりすばらしいEvent: こんにちは、Received Newは述べます: 州の変化Actionがありません: 関連リンクのインターフェース型が二地点間であるなら、この通知が以前に見られたものと異なった隣人のためのものであるか決定してください。 そうだとすれば、Interface Down出来事を関連インタフェースに発生させてください、そして、放送するためにインターフェース型をリセットしてください、そして、Interface Up出来事を発生させてください。
Note: This procedure of generating an Interface Down event and changing the interface type to broadcast is also executed if the neighbor for whom the notification was received is running an older version of the protocol software (see Section 6.1). In previous versions of the protocol, all interfaces were treated as if they were broadcast.
以下に注意してください。 また、通知が受け取られた隣人がプロトコル・ソフトウエアの旧式のバージョンを走らせているなら(セクション6.1を見てください)、Interface Down出来事を発生させて、放送するためにインターフェース型を変えるこの手順は実行されます。 プロトコルの旧バージョンでは、まるでそれらが放送されるかのようにすべてのインタフェースが扱われました。
If the interface type is broadcast, reset the inactivity timer for
the neighbor.
インターフェース型が放送されるなら、隣人のために不活発タイマをリセットしてください。
Kane Informational [Page 30] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[30ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
State(s): Init
Event: 2-Way Received
New state: Depends on action routine
Action:
Determine whether an adjacency will be formed with the neighbor
(see Section 6.4). If no adjacency is to be formed, change the
neighbor state to 2-Way.
州: イニット出来事: 2方法のReceived New州: 動作の通常のActionによります: 隣接番組が隣人と共に形成されるかどうか(セクション6.4を見てください)決定してください。 どんな隣接番組も形成されないことであるなら、隣人状態を2方法に変えてください。
Otherwise, change the neighbor state to ExStart. Initialize the
sequence number for this neighbor and declare the local switch to
be master for the database exchange process. (See Section 7.2.)
さもなければ、隣人状態をExStartに変えてください。 この隣人のために一連番号を初期化してください、そして、地方のスイッチがデータベース交換の過程のためのマスターであると宣言してください。 (セクション7.2を見てください。)
State(s): ExStart
Event: Negotiation Done
New state: Exchange
Action:
The Negotiation Done event signals the start of the database
exchange process. See Section 7.2 for a detailed description of
this process.
州: ExStart出来事: 交渉Done New州: 動作を交換してください: Negotiation Done出来事はデータベース交換の過程の始まりに合図します。 この過程の詳述に関してセクション7.2を見てください。
State(s): Exchange
Event: Exchange Done
New state: Depends on action routine
Action:
If the neighbor Link state request list is empty, change the
neighbor state to Full. This is the adjacency's final state.
州: 出来事を交換してください: Done New状態を交換してください: 動作の通常のActionによります: 隣人Link州の要求リストが空であるなら、隣人状態をFullに変えてください。 これは隣接番組の最終的な状態です。
Otherwise, change the neighbor state to Loading. Begin sending
Link State Request packets to the neighbor requesting the most
recent link state advertisements, as discovered during the
database exchange process. (See Section 7.2.) These
advertisements are listed in the link state request list
associated with the neighbor.
さもなければ、隣人状態をLoadingに変えてください。 最新のリンク州の広告を要求する隣人への州RequestパケットをLinkに送り始めてください、データベース交換の過程の間、発見されるように。 (セクション7.2を見てください。) これらの広告は隣人に関連しているリンク州の要求リストに記載されています。
State(s): Loading
Event: Loading Done
New state: Full
Action:
No action is required beyond changing the neighbor state to Full.
This is the adjacency's final state.
州: ローディング出来事: ローディングDone New州: 完全な動き: 隣人状態をFullに変えることを超えて動作は全く必要ではありません。 これは隣接番組の最終的な状態です。
Kane Informational [Page 31] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[31ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
State(s): 2-Way
Event: AdjOK?
New state: Depends on action routine
Action:
If no adjacency is to be formed with the neighboring switch (see
Section 6.4), retain the neighbor state at 2-Way. Otherwise,
change the neighbor state to ExStart. Initialize the sequence
number for this neighbor and declare the local switch to be master
for the database exchange process. (See Section 7.2.)
州: 2ウェイ出来事: AdjOK? 新しい州: 動作の通常のActionによります: どんな隣接番組も隣接しているスイッチで形成されない(セクション6.4を見てください)ことであるなら、2方法で隣人状態を保有してください。 さもなければ、隣人状態をExStartに変えてください。 この隣人のために一連番号を初期化してください、そして、地方のスイッチがデータベース交換の過程のためのマスターであると宣言してください。 (セクション7.2を見てください。)
State(s): ExStart or greater
Event: AdjOK?
New state: Depends on action routine
Action:
If an adjacency should still be formed with the neighboring switch
(see Section 6.4), no state change and no further action is
necessary. Otherwise, tear down the (possibly partially formed)
adjacency. Clear the link state retransmission list, database
summary list and link state request list and change the neighbor
state to 2-Way.
州: ExStartか、よりすばらしいEvent: AdjOK? 新しい州: 動作の通常のActionによります: 隣接番組が隣接しているスイッチでまだ形成されているべきであるか、そして、(セクション6.4を見てください)州の変化がなくてさらなるどんな動作も必要ではありません。 さもなければ、(ことによると部分的に形成されています)の隣接番組を取りこわしてください。 リンク州の「再-トランスミッション」リスト、データベース概要リスト、およびリンク州の要求リストをきれいにしてください、そして、隣人状態を2ように変えてください。
State(s): Exchange or greater
Event: Seq Number Mismatch
New state: ExStart
Action:
Tear down the (possibly partially formed) adjacency. Clear the
link state retransmission list, database summary list and link
state request list. Change the neighbor state to ExStart and make
another attempt to establish the adjacency.
州: 交換か、より大きいEvent: Seq Number Mismatch New州: ExStart動作: (ことによると部分的に形成されています)の隣接番組を取りこわしてください。 リンク州の「再-トランスミッション」リスト、データベース概要リスト、およびリンク州の要求リストをきれいにしてください。 隣人状態をExStartに変えてください、そして、隣接番組を確立する別の試みをしてください。
State(s): Exchange or greater
Event: BadLSReq
New state: ExStart
Action:
Tear down the (possibly partially formed) adjacency. Clear the
link state retransmission list, database summary list and link
state request list. Change the neighbor state to ExStart and make
another attempt to establish the adjacency.
州: 交換か、より大きいEvent: BadLSReq New州: ExStart動作: (ことによると部分的に形成されています)の隣接番組を取りこわしてください。 リンク州の「再-トランスミッション」リスト、データベース概要リスト、およびリンク州の要求リストをきれいにしてください。 隣人状態をExStartに変えてください、そして、隣接番組を確立する別の試みをしてください。
State(s): Any state
Event: KillNbr
New state: Down
Action:
Terminate the neighbor conversation. Disable the inactivity timer
and clear the link state retransmission list, database summary
list and link state request list.
州: どんな州のEventも: KillNbr New州: 動作の下側に: 隣人の会話を終えてください。 不活発タイマを損傷してください、そして、リンク州の「再-トランスミッション」リスト、データベース概要リスト、およびリンク州の要求リストをきれいにしてください。
Kane Informational [Page 32] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[32ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
State(s): Any state
Event: LLDown
New state: Down
Action:
Terminate the neighbor conversation. Disable the inactivity timer
and clear the link state retransmission list, database summary
list and link state request list.
州: どんな州のEventも: LLDown New州: 動作の下側に: 隣人の会話を終えてください。 不活発タイマを損傷してください、そして、リンク州の「再-トランスミッション」リスト、データベース概要リスト、およびリンク州の要求リストをきれいにしてください。
State(s): Any state
Event: Inactivity Timer
New state: Down
Action:
Terminate the neighbor conversation. Disable the inactivity timer
and clear the link state retransmission list, database summary
list and link state request list.
州: どんな州のEventも: 不活発Timer New州: 動作の下側に: 隣人の会話を終えてください。 不活発タイマを損傷してください、そして、リンク州の「再-トランスミッション」リスト、データベース概要リスト、およびリンク州の要求リストをきれいにしてください。
State(s): 2-Way or greater
Event: 1-Way Received
New state: Init
Action:
Tear down the adjacency between the switches, if any. Clear the
link state retransmission list, database summary list and link
state request list.
州: 2方法の、または、よりすばらしいEvent: 1方法のReceived New州: イニット動作: もしあればスイッチの間まで隣接番組を取りこわしてください。 リンク州の「再-トランスミッション」リスト、データベース概要リスト、およびリンク州の要求リストをきれいにしてください。
State(s): 2-Way or greater
Event: 2-Way received
New state: No state change
Action:
No action required.
州: 2方法の、または、よりすばらしいEvent: 2方法がNew状態を受けました: 州の変化Actionがありません: どんな動作も必要ではありません。
State(s): Init
Event: 1-Way received
New state: No state change
Action:
No action required.
州: イニット出来事: 1方法がNew状態を受けました: 州の変化Actionがありません: どんな動作も必要ではありません。
5. Area Data Structure
5. 領域データ構造
The area data structure contains all the information needed to run the basic routing algorithm. One of its components is the link state database -- the collection of all switch link and network link advertisements generated by the switches.
領域データ構造は基本的なルーティング・アルゴリズムを走らせるのに必要であるすべての情報を含んでいます。 コンポーネントの1つはリンク州のデータベースです--スイッチによって作られたすべてのスイッチリンクとネットワークリンク広告の収集。
The area data structure contains the following items:
領域データ構造は以下の項目を含んでいます:
Kane Informational [Page 33] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[33ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Area ID
領域ID
A 4-octet value identifying the area. Since VLSP does not support
multiple areas, the value here is always zero.
領域を特定する4八重奏の値。 VLSPが複数の領域を支持しないので、いつもここの値はゼロです。
Associated switch interfaces
関連スイッチインタフェース
A list of interface IDs of the local switch interfaces connected
to network links.
地方のスイッチインタフェースのインタフェースIDのリストはネットワークリンクに接続しました。
Link state database
リンク州のデータベース
The collection of all current link state advertisements for the
switch fabric. This collection consists of the following:
スイッチ織物のためのすべての現在のリンク州の広告の収集。 この収集は以下から成ります:
Switch link advertisements
スイッチリンク広告
A list of the switch link advertisements for all switches in the
fabric. Switch link advertisements describe the state of each
switch's interfaces.
すべてのためのスイッチリンク広告のリストは織物で切り替わります。 スイッチリンク広告は各スイッチのインタフェースの状態について説明します。
Network link advertisements
ネットワークリンク広告
A list of the network link advertisements for all multi-access
network links in the switch fabric. Network link advertisements
describe the set of switches currently connected to each link.
すべてのマルチアクセスネットワークのためのネットワークリンク広告のリストはスイッチ織物でリンクされます。 ネットワークリンク広告は、それぞれリンクするために現在接続されるスイッチのセットについて説明します。
Best path(s)
最も良い経路(s)
A set of end-to-end hop descriptions for all equal-cost best paths
from the local switch to every other switch in the fabric. Each
hop is specified by the interface ID of the next link in the path.
Best paths are derived from the collected switch link and network
link advertisements using the Dijkstra algorithm. [Perlman]
すべての地方のスイッチから他のあらゆるスイッチまでの等しい費用の織物で最も良い経路のための終わりから終わりへの1セットのホップ記述。 各ホップは経路で次のリンクのインタフェースIDによって指定されます。 集まっているスイッチリンクとネットワークリンク広告からダイクストラアルゴリズムを使用することで最も良い経路を得ます。 [パールマン]
5.1 Adding and Deleting Link State Advertisements
5.1 リンク州の広告を加えて、削除すること。
The link state database within the area data structure must contain, at most, a single instance of each link state advertisement. To keep the database current, a switch adds link state advertisements to the database under the following conditions:
領域データ構造の中のリンク州のデータベースは大部分にそれぞれのリンク州の広告のただ一つの例を含まなければなりません。 データベースを現在に保つために、スイッチはリンク州の広告を以下の条件でのデータベースに追加します:
o When a link state advertisement is received during the
distribution process
o 分配の過程の間リンク州の広告を受け取るとき
o When the switch itself generates a link state advertisement
o スイッチ自体がリンク州の広告を作る場合
Kane Informational [Page 34] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[34ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
(See Section 8.2.4 for information on installing link state advertisements.)
(インストールの情報のためのセクション8.2.4が州の広告をリンクするのを見てください。)
Likewise, a switch deletes link state advertisements from the database under the following conditions:
同様に、スイッチは以下の条件でのデータベースからリンク州の広告を削除します:
o When a link state advertisement has been superseded by a newer
instance during the flooding process
o リンク州の広告が氾濫の過程の間、より新しい例によって取って代わられているとき
o When the switch generates a newer instance of one of its self-
originated advertisements
o スイッチが自己の溯源された広告の1つの、より新しい例を発生させる場合
Note that when an advertisement is deleted from the link state database, it must also be removed from the link state retransmission list of all neighboring switches.
また、広告がリンク州のデータベースから削除されるときすべての隣接しているスイッチのリンク州の「再-トランスミッション」リストからそれを取り除かなければならないことに注意してください。
5.2 Accessing Link State Advertisements
5.2 リンク州の広告にアクセスすること。
An implementation of the VLS protocol must provide access to individual link state advertisements, based on the advertisement's type, link state identifier, and advertising switch [1]. This lookup function is invoked during the link state distribution procedure and during calculation of the set of best paths. In addition, a switch can use the function to determine whether it has originated a particular link state advertisement, and if so, with what sequence number.
VLSプロトコルの実現は個々のリンク州の広告へのアクセスを提供しなければなりません、広告のタイプ、リンク州の識別子、および広告スイッチ[1]に基づいて。 このルックアップ機能はリンク州の分配手順と最も良い経路のセットの計算の間、呼び出されます。 さらに、スイッチは、それが特定のリンク州の広告を溯源したかどうか決定するのに機能を使用して、そうだとすれば、どんな一連番号でそうすることができるか。
5.3 Best Path Lookup
5.3 最も良い経路ルックアップ
An implementation of the VLS protocol must provide access to multiple equal-cost best paths, based on the base MAC addresses of the source and destination switches. This lookup function should return up to three equal-cost paths. Paths should be returned as lists of end- to-end hop information, with each hop specified as a interface ID of the next link in the path -- the 6-octet base MAC address of the next switch and the 4-octet local port number of the link interface.
VLSプロトコルの実現はソースと目的地スイッチのベースMACアドレスに基づいて複数の等しい費用の最も良い経路へのアクセスを提供しなければなりません。 このルックアップ機能は最大3つの等しい費用経路を返すべきです。 終わりまでの終わりのホップ情報のリストとして経路を返すべきです、各ホップが次のリンクのインタフェースIDとして経路で指定されている状態で--次のスイッチの6八重奏のベースMACアドレスとリンクインタフェースの4八重奏の地方のポートナンバー。
6. Discovery Process
6. 発見の過程
The first operational stage of the VLS protocol is the discovery process. During this stage, each switch dynamically detects its neighboring switches and establishes a relationship with each of these neighbors. This process has the following component steps:
VLSプロトコルの最初の操作上のステージは発見の過程です。 このステージの間、各スイッチは、ダイナミックに隣接しているスイッチを検出して、これらの隣人各人との関係を確立します。 この過程に、以下のコンポーネントステップがあります:
Kane Informational [Page 35] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[35ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o Neighboring switches are detected on each functioning network
interface.
o 隣接しているスイッチはそれぞれの機能しているネットワーク・インターフェースに検出されます。
o Bidirectional communication is established with each neighbor
switch.
o 双方向のコミュニケーションはそれぞれの隣人スイッチで確立されます。
o A designated switch and backup designated switch are selected for
each multi-access network link.
o スイッチに任命された指定されたスイッチとバックアップはそれぞれのマルチアクセスネットワークリンクに選ばれます。
o An adjacent relationship is established with selected neighbors on
each link.
o 隣接している関係は各リンクの上の選択された隣人と共に確立されます。
6.1 Neighbor Discovery
6.1 隣人発見
When the switch first comes on line, VLSP assumes all network links are point-to-point and no more than one neighboring switch will be discovered on any one port. Therefore, at startup, VLSP relies on the VlanHello protocol [IDhello] for the discovery of its neighbor switches.
スイッチが最初に線をつくと、VLSPは、すべてのネットワークリンクが二地点間であると仮定します、そして、1個未満の隣接しているスイッチがどんなポートの上でも発見されるでしょう。 したがって、始動では、VLSPは隣人スイッチの発見のために、VlanHelloプロトコル[IDhello]を当てにします。
As each neighbor is detected, VlanHello triggers a Found Neighbor event, notifying VLSP that a new neighbor has been discovered. (See [IDhello] for a description of the Found Neighbor event and the information passed.) VLSP enters the neighbor switch ID in the list of known neighbors and creates a new neighbor data structure with a neighbor status of Down. A Hello Received neighbor event is then generated, which changes the neighbor state to ExStart.
各隣人が検出されるとき、新しい隣人が発見されたことをVLSPに通知して、VlanHelloはFound Neighbor出来事の引き金となります。 (Found Neighbor出来事と情報の記述のための[IDhello]が通過されるのを見てください。) VLSPは隣人スイッチIDに知られている隣人のリストに入って、Downの隣人状態で新しい隣人データ構造を作成します。 そして、Hello Received隣人出来事(隣人状態をExStartに変える)は発生します。
There are two circumstances under which VLSP will change the type of an interface to broadcast:
VLSPが放送するためにインタフェースのタイプを変える2つの事情があります:
o If VLSP receives a subsequent notification from VlanHello,
specifying a second (different) neighbor switch on the port., the
interface is then known to be multi-access. VLSP generates an
Interface Down event for the interface, resets the interface type
to broadcast, and then generates an Interface Up event.
o VLSPがVlanHelloからその後の通知を受け取るなら、ポートの上の2番目の(異なる)の隣人スイッチを指定する、そして、インタフェースはマルチアクセサリーであることが知られています。 VLSPはInterface Down出来事をインタフェースに発生させて、放送するためにインターフェース型をリセットして、次に、Interface Up出来事を発生させます。
o If the functional level of the neighbor switch is less than 2, the
neighbor is running a previous version of the VLSP software in
which all links were treated as broadcast links. VLSP immediately
changes the interface type to broadcast and generates an Interface
Up event.
o 隣人スイッチの機能的なレベルが2未満であるなら、隣人はすべてのリンクが放送リンクとして扱われたVLSPソフトウェアの旧バージョンを走らせています。 VLSPはすぐに、放送するためにインターフェース型を変えて、Interface Up出来事を発生させます。
In both cases, VLSP assumes control of communication over the
interface by exchanging its own VLSP Hello packets with the
neighbors on the link.
どちらの場合も、VLSPは、インタフェースの上でリンクでそれ自身のVLSP Helloパケットを隣人と交換することによって、コミュニケーションのコントロールを仮定します。
Kane Informational [Page 36] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[36ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Note: These Hello packets are in addition to the Interswitch Keepalive messages sent by VlanHello. VlanHello still continues to monitor the condition of the interface and notifies VLSP of any change.
以下に注意してください。 これらのHelloパケットはVlanHelloによって送られたInterswitch Keepaliveメッセージに加えています。 VlanHelloはまだインタフェースの状態をモニターしてい続けて、どんな変化についてもVLSPに通知します。
Each Hello packet contains the following data used during the discovery process on multi-access links:
それぞれのHelloパケットは発見の過程の間にマルチアクセスリンクの上に使用される以下のデータを含んでいます:
o The switch ID and priority of the sending switch
o 送付スイッチのスイッチIDと優先権
o Values specifying the interval timers to be used for sending Hello
packets and deciding whether to declare a neighbor switch Down.
o 送付Helloパケットに使用されるためにインタバルタイマを指定して、隣人を宣言するかどうか決める値がDownを切り換えます。
o The switch ID of the designated switch and the backup designated
switch for the link, as understood by the sending switch
o 指定されたスイッチとバックアップのスイッチIDはリンクにスイッチを指定しました、送付スイッチに解釈されるように
o A list of switch IDs of all neighboring switches seen so far on
the link
o 今までのところリンクの上に見られているすべての隣接しているスイッチのスイッチIDのリスト
For a detailed description of the Hello packet format, see Section 10.6.1.
Helloパケット・フォーマットの詳述に関しては、セクション10.6.1を見てください。
When VLSP receives a Hello packet (on a broadcast link), it first attempts to identify the sending switch by matching its switch ID to one of the known neighbors listed in the interface data structure. If this is the first Hello packet received from the switch, the switch ID is entered in the list of known neighbors and a new neighbor data structure is created with a neighbor status of Down.
VLSPがHelloパケット(放送リンクの)を受けるとき、それは、最初に、インタフェースデータ構造で記載された知られている隣人のひとりにスイッチIDを合わせることによって送付スイッチを特定するのを試みます。 これがスイッチから受け取られた、最初のHelloパケットであるなら、スイッチIDは知られている隣人のリストに入れられます、そして、新しい隣人データ構造はDownの隣人状態で作成されます。
At this point, the remainder of the Hello packet is examined and the appropriate interface and neighbor events are generated. In all cases, a neighbor Hello Received event is generated. Other events may also be generated, triggering further steps in the discovery process or other actions, as appropriate.
ここに、Helloパケットの残りは調べられます、そして、適切なインタフェースと隣人出来事は発生します。 すべての場合では、隣人Hello Received出来事は発生します。 また、他の出来事は発見の過程か他の動作におけるさらなるステップの引き金となって、適切な状態で発生するかもしれません。
For a detailed description of the interface state machine, see Section 3.3. For a detailed description of the neighbor state machine, see Section 4.3.
界面準位マシンの詳述に関しては、セクション3.3を見てください。 隣人州のマシンの詳述に関しては、セクション4.3を見てください。
6.2 Bidirectional Communication
6.2 双方向のコミュニケーション
Before a conversation can proceed with a neighbor switch, bidirectional communication must be established with that neighbor. Bidirectional communication is detected in one of two ways:
会話が隣人スイッチを続けることができる前に、その隣人と共に双方向のコミュニケーションを確立しなければなりません。 双方向のコミュニケーションは2つの方法の1つで検出されます:
Kane Informational [Page 37] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[37ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o On a point-to-point link, the VlanHello protocol sees its own
switch ID listed in an Interswitch Keepalive message it has
received from the neighbor.
o ポイントツーポイント接続の上では、VlanHelloプロトコルは、それ自身のスイッチIDがそれが隣人から受け取ったInterswitch Keepaliveメッセージに記載されているのを見ます。
o On a multi-access link, VLSP sees its own switch ID listed in a
VLSP Hello packet it has received from the neighbor.
o マルチアクセスリンクの上では、VLSPは、それ自身のスイッチIDがそれが隣人から受けたVLSP Helloパケットに記載されているのを見ます。
In either case, a neighbor 2-Way Received neighbor event is generated.
どちらの場合ではも、隣人の2方法のReceived隣人出来事は発生します。
Once bidirectional communication has been established with a neighbor, the local switch determines whether an adjacency will be formed with the neighbor. However, if the link is a multi-access link, a designated switch and a backup designated switch must first be selected for the link. The next section contains a description of the designated switch, the backup designated switch, and the selection process.
隣接番組が隣人と共に形成されるか否かに関係なく、地方のスイッチは、一度、双方向のコミュニケーションが隣人と共に確立されたことがあることを決定します。 しかしながら、リンクがマルチアクセスリンクであるなら、最初に、指定されたスイッチとスイッチに任命されたバックアップをリンクに選ばなければなりません。 次のセクションは指定されたスイッチ、スイッチに任命されたバックアップ、および選択の過程の記述を含みます。
6.3 Designated Switch
6.3 指定されたスイッチ
Every multi-access network link has a designated switch. The designated switch performs the following functions for the routing protocol:
あらゆるマルチアクセスネットワークリンクには、指定されたスイッチがあります。 指定されたスイッチはルーティング・プロトコルのために以下の機能を実行します:
o The designated switch originates a network link advertisement on
behalf of the link, listing the set of switches (including the
designated switch itself) currently attached to the link. For a
detailed description of network link advertisements, see Section
11.3.
o 指定されたスイッチはリンクを代表してネットワークリンク広告を溯源します、現在リンクに取り付けられているスイッチ(指定されたスイッチ自体を含んでいる)のセットを記載して。 ネットワークリンク広告の詳述に関しては、セクション11.3を見てください。
o The designated switch becomes adjacent to all other switches on
the link. Since the link state databases are synchronized across
adjacencies, the designated switch plays a central part in the
synchronization process. For a description of the synchronization
process, see Section 7.
o 指定されたスイッチはリンクの上の他のすべてのスイッチに隣接してなります。 リンク州のデータベースが隣接番組の向こう側に同期するので、指定されたスイッチは同期の過程で中央の役割を果たします。 同期の過程の記述に関しては、セクション7を見てください。
Each multi-access network link also has a backup designated switch. The primary function of the backup designated switch is to act as a standby for the designated switch. If the current designated switch fails, the backup designated switch becomes the designated switch.
また、それぞれのマルチアクセスネットワークリンクで、バックアップをスイッチに任命します。 スイッチに任命されたバックアップの第一の機能は指定されたスイッチのための予備として機能することです。 現在の指定されたスイッチが失敗するなら、スイッチに任命されたバックアップは指定されたスイッチになります。
To facilitate this transition, the backup designated switch forms an adjacency with every other switch on the link. Thus, when the backup designated switch must take over for the designated switch, its link state database is already synchronized with the databases of all other switches on the link.
この変遷を容易にするために、リンクの上に他のあらゆるスイッチがある状態で、スイッチに任命されたバックアップは隣接番組を形成します。 したがって、スイッチに任命されたバックアップが指定されたスイッチのために引き継がなければならないと、リンク州のデータベースは既にリンクの上の他のすべてのスイッチに関するデータベースと同期します。
Kane Informational [Page 38] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[38ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Note: Point-to-point network links have neither a designated switch or a backup designated switch.
以下に注意してください。 二地点間ネットワークリンクで、指定されたスイッチもバックアップもスイッチに任命しません。
6.3.1 Selecting the Designated Switch
6.3.1 指定されたスイッチを選択すること。
When a multi-access link interface first becomes functional, the switch sets a one-shot Wait timer (with a value of SwitchDeadInterval seconds) for the interface. The purpose of this timer is to ensure that all switches attached to the link have a chance to establish bidirectional communication before the designated switch and backup designated switch are selected for the link.
マルチアクセスリンクインタフェースが最初に機能的になると、スイッチは1回限りのWaitタイマ(SwitchDeadInterval秒の値がある)をインタフェースに設定します。 このタイマの目的はリンクに取り付けられたすべてのスイッチがスイッチに任命された指定されたスイッチとバックアップがリンクに選ばれる前に双方向のコミュニケーションを確立する機会を持っているのを保証することです。
When the Wait timer is set, the interface enters the Waiting state. During this state, the switch exchanges Hello packets with its neighbors attempting to establish bidirectional communication. The interface leaves the Waiting state under one of the following conditions:
Waitタイマが設定されるとき、インタフェースはWaiting状態に入ります。 この状態の間、スイッチは双方向のコミュニケーションを確立するのを試みる隣人とHelloパケットを交換します。 インタフェースは以下の条件の1つ未満にWaiting状態を出ます:
o The Wait timer expires.
o Waitタイマは期限が切れます。
o A Hello packet is received indicating that a designated switch or
a backup designated switch has already been specified for the
interface.
o 指定されたスイッチかスイッチに任命されたバックアップが既にインタフェースに指定されたのを示すのにおいてHelloパケットは受け取られています。
At this point, if the switch sees that a designated switch has already been selected for the link, the switch accepts that designated switch, regardless of its own switch priority and MAC address. This situation typically means the switch has come up late on a fully functioning link. Although this makes it harder to predict the identity of the designated switch on a particular link, it ensures that the designated switch does not change needlessly, necessitating a resynchronization of the databases.
ここに、スイッチが、指定されたスイッチが既にリンクに選択されたのがわかるなら、スイッチはスイッチに指定されたそれを受け入れます、それ自身のスイッチ優先権とMACアドレスにかかわらず。 この状況は、スイッチが遅く完全に機能しているリンクで上って来たことを通常意味します。 指定されたスイッチのアイデンティティを予測するのは特定のリンクの上にこれで、より困難になりますが、指定されたスイッチが不必要に変化しないのを確実にします、データベースの再同期を必要として。
If no designated switch is currently specified for the link, the switch begins the actual selection process. Note that this selection algorithm operates only on a list of neighbor switches that are eligible to become the designated switch. A neighbor is eligible to be the designated switch if it has a switch priority greater than zero and its neighbor state is 2-Way or greater. The local switch includes itself on the list of eligible switches as long as it has a switch priority greater than zero.
指定されたスイッチが全く現在リンクに指定されないなら、スイッチは実際の選択プロセスを開始します。 この選択アルゴリズムが指定されたスイッチになるのが適任の隣人スイッチのリストだけで作動することに注意してください。 スイッチ優先をゼロとその隣人状態が2方法か、より大きいというよりもすばらしくするなら、隣人は指定されたスイッチであることが適任です。 スイッチ優先をゼロよりすばらしくする限り、地方のスイッチは適任のスイッチのリストにそれ自体を含んでいます。
The selection process includes the following steps:
選択の過程は以下のステップを含んでいます:
1. The current values of the link's designated switch and backup
designated switch are saved for use in step 6.
1. スイッチに任命されたリンクの指定されたスイッチとバックアップの現行価値はステップ6における使用のために節約されます。
2. The new backup designated switch is selected as follows:
2. スイッチに任命された新しいバックアップは以下の通り選ばれます:
Kane Informational [Page 39] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[39ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
a) Eliminate from consideration those switches that have declared
themselves to be the designated switch.
a) 考慮から、指定されたスイッチであると自分たちで宣言したそれらのスイッチを排除してください。
b) If one or more of the remaining switches have declared
themselves to be the backup designated switch, eliminate from
consideration all other switches.
b) 1か残っているスイッチの以上が、自分たちがスイッチに任命されたバックアップであると宣言したなら、考慮から、他のすべてのスイッチを排除してください。
c) From the remaining list of eligible switches, select the switch
having the highest switch priority as the backup designated
switch. If multiple switches have the same (highest) priority,
select the switch with the highest switch ID as the backup
designated switch.
c) 適任のスイッチの残っているリストから、バックアップがスイッチを指定したとき持っている中でスイッチ優先度最も高いスイッチを選択してください。 複数のスイッチに同じ(最も高い)の優先権があるなら、バックアップがスイッチを指定したので、最も高いスイッチIDがあるスイッチを選択してください。
3. The new designated switch is selected as follows:
3. 新しい指定されたスイッチは以下の通り選択されます:
a) If one or more of the switches have declared themselves to be
the designated switch, eliminate from consideration all other
switches.
a) スイッチが指定されたスイッチであると1つかまだ自分たちで宣言しているなら、考慮から、他のすべてのスイッチを排除してください。
b) From the remaining list of eligible switches, select the switch
having the highest switch priority as the designated switch.
If multiple switches have the same (highest) priority, select
the switch with the highest switch ID as the designated switch.
b) 適任のスイッチの残っているリストから、指定されたスイッチとして持っている中でスイッチ優先度最も高いスイッチを選択してください。 複数のスイッチに同じ(最も高い)の優先権があるなら、指定されたスイッチとして最も高いスイッチIDがあるスイッチを選定してください。
4. If the local switch has been newly selected as either the
designated switch or the backup designated switch, or is now no
longer the designated switch or the backup designated switch,
repeat steps 2 and 3, above, and then proceed to step 5.
4. 地方のスイッチが指定されたスイッチかバックアップのどちらかが現在もうスイッチを指定するか、指定されたスイッチまたはスイッチに任命されたバックアップでないので新たに選択されたなら、上でステップ2と3を繰り返してください、そして、次に、ステップ5に進んでください。
If the local switch is now the designated switch, it will
eliminate itself from consideration at step 2a when the selection
of the backup designated switch is repeated. Likewise, if the
local switch is now the backup designated switch, it will
eliminate itself from consideration at step 3a when the selection
of the designated switch is repeated. This ensures that no switch
will select itself as both backup designated switch and designated
switch [2].
スイッチに任命されたバックアップの選択が繰り返されるとき、現在地方のスイッチが指定されたスイッチであるなら、それはステップ2aでの考慮からそれ自体を排除するでしょう。 指定されたスイッチの選択が繰り返されるとき、同様に、現在地方のスイッチがスイッチに任命されたバックアップであるなら、それはステップ3aでの考慮からそれ自体を排除するでしょう。 これは、両方が指定されたスイッチと指定されたスイッチ[2]のバックアップをとるときどんなスイッチもそれ自体を選択しないのを確実にします。
5. Set the interface state to the appropriate value, as follows:
5. 以下の通り適切な値に界面準位を設定してください:
o If the local switch is now the designated switch, set the
interface state to DS.
o 現在地方のスイッチが指定されたスイッチであるなら、DSに界面準位を設定してください。
o If the local switch is now the backup designated switch, set the
interface state to Backup.
o 現在地方のスイッチがスイッチに任命されたバックアップであるなら、Backupに界面準位を設定してください。
o Otherwise, set the interface state to DS Other.
o さもなければ、DS Otherに界面準位を設定してください。
Kane Informational [Page 40] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[40ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
6. If either the designated switch or backup designated switch has
now changed, the set of adjacencies associated with this link must
be modified. Some adjacencies may need to be formed, while others
may need to be broken. Generate the neighbor AdjOK? event for all
neighbors with a state of 2-Way or higher to trigger a
reexamination of adjacency eligibility.
6. 指定されたスイッチかスイッチに任命されたバックアップのどちらかが現在変化したなら、このリンクに関連している隣接番組のセットを変更しなければなりません。 いくつかの隣接番組が、形成される必要があるかもしれませんが、他のものは、壊れる必要があるかもしれません。 隣人AdjOKを発生させてください--隣接番組適任の再検討の引き金となるように2方法か、より高いことの状態をもっているすべての隣人のための出来事。
Caution: If VLSP is implemented with configurable parameters, care must be exercised in specifying the switch priorities. Note that if the local switch is not itself eligible to become the designated switch (i.e., it has a switch priority of 0), it is possible that neither a backup designated switch nor a designated switch will be selected by the above procedure. Note also that if the local switch is the only attached switch that is eligible to become the designated switch, it will select itself as designated switch and there will be no backup designated switch for the link. For this reason, it is advisable to specify a default switch priority of 1 for all switches.
警告: VLSPが構成可能なパラメタで実行されるなら、スイッチプライオリティを指定するのに注意を訓練しなければなりません。 地方のスイッチが指定されたスイッチになるのがそれ自体で適任でないなら(すなわち、それには、0のスイッチ優先があります)、スイッチに任命されたバックアップも指定されたスイッチも上の手順によって選択されないのが、可能であることに注意してください。 また、地方のスイッチが唯一の指定されたスイッチになるのが適任の付属スイッチであるなら、スイッチに指定されるようにそれ自体を選択して、リンクのためにスイッチに任命されたバックアップが全くないことに注意してください。 この理由で、1のデフォルトスイッチ優先をすべてのスイッチに指定するのは賢明です。
6.4 Adjacencies
6.4 隣接番組
VLSP creates adjacencies between neighboring switches for the purpose of exchanging routing information. Not every two neighboring switches will become adjacent. On a multi-access link, an adjacency is only formed between two switches if one of them is either the designated switch or the backup designated switch.
VLSPはルーティング情報を交換する目的のために隣接しているスイッチの間で隣接番組を作成します。 2個の隣接しているスイッチ毎は隣接するようにならないでしょう。 マルチアクセスリンクに、隣接番組はそれらの1つがスイッチに任命された指定されたスイッチかバックアップのどちらかである場合にだけ2個のスイッチの間で形成されます。
Note that an adjacency is bound to the network link that the two switches have in common. Therefore, if two switches have multiple links in common, they may also have multiple adjacencies between them.
隣接番組が2個のスイッチが共通であるネットワークリンクまで縛られることに注意してください。 したがって、また、2個のスイッチが複数のリンクが共通であるなら、それらの間には、複数の隣接番組があるかもしれません。
The decision to form an adjacency occurs in two places in the neighbor state machine:
隣接番組を形成するという決定は隣人州のマシンの2つの場所で起こります:
o When bidirectional communication is initially established with the
neighbor.
o 双方向のコミュニケーションが初めは隣人と共に確立されるとき。
o When the designated switch or backup designated switch on the
attached link changes.
o 指定されたスイッチかバックアップがいつ付属リンクの上のスイッチを指定したかは変化します。
The rules for establishing an adjacency between two neighboring switches are as follows:
2個の隣接しているスイッチの間の隣接番組を確立するための規則は以下の通りです:
o On a point-to-point link, the two neighboring switches always
establish an adjacency.
o ポイントツーポイント接続の上では、2個の隣接しているスイッチがいつも隣接番組を確立します。
o On a multi-access link, an adjacency is established with the
neighboring switch under one of the following conditions:
o マルチアクセスリンクの上では、隣接番組は以下の条件の1つの隣接しているスイッチで確立されます:
Kane Informational [Page 41] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[41ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o The local switch itself is the designated switch.
o The local switch itself is the backup designated switch.
o The neighboring switch is the designated switch.
o The neighboring switch is the backup designated switch.
o 地方のスイッチ自体は指定されたスイッチです。○ 地方のスイッチ自体はスイッチに任命されたバックアップです。○ 隣接しているスイッチは指定されたスイッチです。○ 隣接しているスイッチはスイッチに任命されたバックアップです。
If no adjacency is formed between two neighboring switches, the state of the neighbor conversation remains set to 2-Way.
隣接番組が全く2個の隣接しているスイッチの間で形成されないなら、隣人の会話の状態は2方法に設定されたままで残っています。
7. Synchronizing the Databases
7. データベースを同期させます。
In an SPF-based routing algorithm, it is important for the link state databases of all switches to stay synchronized. VLSP simplifies this process by requiring only adjacent switches to remain synchronized.
SPFベースのルーティング・アルゴリズムで、すべてのスイッチに関するリンク州のデータベースが連動していた状態で残っているのは、重要です。 隣接しているスイッチだけが連動したままで残っているのを必要とすることによって、VLSPはこの過程を簡素化します。
The synchronization process begins when the switches attempt to bring up the adjacency. Each switch in the adjacency describes its database by sending a sequence of Database Description packets to its neighbor. Each Database Description packet describes a set of link state advertisements belonging to the database. When the neighbor sees a link state advertisement that is more recent than its own database copy, it makes a note to request this newer advertisement.
スイッチが、隣接番組を持って来るのを試みるとき、同期の過程は始まります。 隣接番組における各スイッチは、Database記述パケットの系列を隣人に送ることによって、データベースについて説明します。 それぞれのDatabase記述パケットはデータベースに属す1セットのリンク州の広告について説明します。 隣人がそれ自身のデータベースコピーより最近のリンク州の広告を見るとき、それは、このより新しい広告を要求するためにメモを取ります。
During this exchange of Database Description packets (known as the database exchange process), the two switches form a master/slave relationship. Database Description packets sent by the master are known as polls, and each poll contains a sequence number. Polls are acknowledged by the slave by echoing the sequence number in the Database Description response packet.
Database記述パケット(データベース交換の過程として、知られている)のこの交換の間、2個のスイッチがマスター/奴隷関係を形成します。 マスターによって送られたデータベース記述パケットは投票として知られています、そして、各投票は一連番号を含んでいます。 投票は、Database記述応答パケットで一連番号を反響することによって、奴隷によって承諾されます。
When all Database Description packets have been sent and acknowledged, the database exchange process is completed. At this point, each switch in the exchange has a list of link state advertisements for which its neighbor has more recent instances. These advertisements are requested using Link State Request packets.
すべてのDatabase記述パケットが送られて、承認されたとき、データベース交換の過程は完了しています。 ここに、交換における各スイッチには、隣人が、より最近の例を持っているリンク州の広告のリストがあります。 これらの広告は、Link州Requestパケットを使用することで要求されています。
Once the database exchange process has completed and all Link State Requests have been satisfied, the databases are deemed synchronized and the neighbor states of the two switches are set to Full, indicating that the adjacency is fully functional. Fully functional adjacencies are advertised in the link state advertisements of the two switches [3].
過程が終了したデータベース交換とすべてのLink州Requestsがいったん満たされると、データベースは連動していると考えられます、そして、2個のスイッチの隣人州はFullに設定されます、隣接番組が完全に機能的であることを示して。 2個のスイッチ[3]のリンク州の広告に完全に機能的な隣接番組の広告を出します。
Kane Informational [Page 42] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[42ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
7.1 Link State Advertisements
7.1 リンク州の広告
Link state advertisements form the core of the database from which a switch calculates the set of best paths to the other switches in the fabric.
リンク州の広告はスイッチが織物で他のスイッチに最も良い経路のセットについて計算するデータベースのコアを形成します。
Each link state advertisement begins with a standard header. This header contains three data items that uniquely identify the link state advertisement.
それぞれのリンク州の広告は標準のヘッダーと共に始まります。 このヘッダーは唯一リンク州の広告を特定する3つのデータ項目を含んでいます。
o The link state type. Possible values are as follows:
o リンク州のタイプ。 可能な値は以下の通りです:
1 Switch link advertisement -- describes the collected states of
the switch's interfaces.
1 スイッチリンク広告--スイッチのインタフェースの集まっている州について説明します。
2 Network link advertisement -- describes the set of switches
attached to the network link.
2はリンク広告をネットワークでつなぎます--ネットワークリンクに取り付けられたスイッチのセットについて説明します。
o The link state ID, defined as follows:
o 以下の通り定義されたリンク州のID:
o For a switch link advertisement -- the switch ID of the
originating switch
o スイッチに関しては、広告をリンクしてください--由来のスイッチIDは切り替わります。
o For a network link advertisement -- the switch ID of the
designated switch for the link
o ネットワークには、広告をリンクしてください--指定のスイッチIDはリンクに切り替わります。
o The switch ID of the advertising switch -- the switch that
generated the advertisement
o 広告スイッチのスイッチID--広告を作ったスイッチ
The link state advertisement header also contains three data items that are used to determine which instance of a particular link state advertisement is the most current. (See Section 7.1.1 for a description of how to determine which instance of a link state advertisement is the most current.)
また、リンク州の広告ヘッダーは特定のリンク州の広告のどの例がよく最も見られるかを決定するのに使用される3つのデータ項目を含んでいます。 (リンク州の広告のどの例がよく最も見られるかをどう決定するかに関する記述に関してセクション7.1.1を見てください。)
o The link state sequence number
o リンク州の一連番号
o The link state age, stored in seconds
o 秒に格納されたリンク州の時代
o The link state checksum, a 16-bit unsigned value calculated for
the entire contents of the link state advertisement, with the
exception of the age field
o リンク州のチェックサム、16ビットの無記名の値はリンク州の広告の全体のコンテンツを予測しました、時代分野を除いて
The remainder of each link state advertisement contains data specific to the type of the advertisement. See Section 11 for a detailed description of the link state header, as well as the format of a switch link or network link advertisement.
それぞれのリンク州の広告の残りは広告のタイプに、特定のデータを含んでいます。 リンク州のヘッダーの詳述に関してセクション11を見てください、スイッチリンクかネットワークリンク広告の形式と同様に。
Kane Informational [Page 43] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[43ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
7.1.1 Determining Which Link State Advertisement Is Newer
7.1.1 どちらのリンク州の広告が、より新しいかを決定すること。
At various times while synchronizing or updating the link state database, a switch must determine which instance of a particular link state advertisement is the most current. This decision is made as follows:
いろいろな時に、リンク州のデータベースを連動するか、またはアップデートしている間、スイッチは、特定のリンク州の広告のどの例がよく最も見られるかを決定しなければなりません。 この決定を以下の通りにします:
o The advertisement having the greater sequence number is the most
current.
o より大きい一連番号を持っている広告はよく最も見られます。
o If both instances have the same sequence number, then:
o 次に、両方の例に同じ一連番号があるなら:
o If the two instances have different checksum values, then the
instance having the larger checksum is considered the most
current [4].
o 2つの例に異なったチェックサム値があるなら、より大きいチェックサムを持っている例は最も現在の[4]であると考えられます。
o If both instances have the same sequence number and the same
checksum value, then:
o そして、両方の例で同じ一連番号があるか、そして、同じチェックサムは以下を評価します。
o If one (and only one) of the instances is of age MaxAge, then
the instance of age MaxAge is considered the most current [5].
o 例の1つ(そして、1だけ)が時代MaxAgeのものであるなら、時代MaxAgeの例は最も現在の[5]であると考えられます。
o Else, if the ages of the two instances differ by more than
MaxAgeDiff, the instance having the smaller (younger) age is
considered the most current [6].
o ほかに、2つの例の時代がMaxAgeDiff以上で異なるなら、よりわずかな(より若い)時代を過す例は最も現在の[6]であると考えられます。
o Else, the two instances are considered identical.
o ほかに、2つの例が同じであると考えられます。
7.2 Database Exchange Process
7.2 データベース交換の過程
There are two stages to the database exchange process:
データベース交換の過程への2つのステージがあります:
o Negotiating the master/slave relationship o Exchanging database summary information
o マスター/奴隷関係o Exchangingデータベース概要情報を交渉します。
7.2.1 Database Description Packets
7.2.1 データベース記述パケット
Database Description packets are used to describe a switch's link state database during the database exchange process. Each Database Description packet contains a list of headers of the link state advertisements currently stored in the sending switch's database. (See Section 11.1 for a description of a link state advertisement header.)
データベース記述パケットは、データベース交換の過程の間、スイッチのリンク州のデータベースについて説明するのに使用されます。 それぞれのDatabase記述パケットは現在送付スイッチのデータベースに格納されているリンク州の広告のヘッダーのリストを含んでいます。 (リンク州の広告ヘッダーの記述に関してセクション11.1を見てください。)
In addition to the link state headers, each Database Description packet contains the following data items:
リンク州のヘッダーに加えて、それぞれのDatabase記述パケットは以下のデータ項目を含んでいます:
Kane Informational [Page 44] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[44ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o A flag (the M-bit) indicating whether or not more packets are to
follow. Depending on the size of the local database and the
maximum size of the packet, the list of headers in any particular
Database Description packet may be only a partial list of the
total database. When the M-bit is set, the list of headers is
only a partial list and more headers are to follow in subsequent
packets.
o より多くのパケットが続くことになっているかどうかを示す旗(M-ビット)。 ローカルのデータベースのサイズとパケットの最大サイズによって、どんな特定のDatabase記述パケットのヘッダーのリストも総データベースの部分的なリストであるにすぎないかもしれません。 M-ビットが設定されるとき、ヘッダーのリストは部分的なリストにすぎません、そして、より多くのヘッダーがその後のパケットで続くことになっています。
o A flag (the I-bit) indicating whether or not this is the first
Database Description packet sent for this execution of the
database exchange process.
o これが最初のDatabase記述パケットであるかどうかを示す旗(I-ビット)はデータベース交換の過程のこの実行のために発信しました。
o A flag (the MS-bit) indicating whether the sending switch thinks
it is the master or the slave in the database exchange process.
If the flag is set, the switch thinks it is the master.
o 送付スイッチがそれを考えるかどうかを示す旗(MS-ビット)は、データベース交換の過程でマスターか奴隷です。 旗が設定されるなら、スイッチは、それがマスターであると思います。
o A 4-octet sequence number for the packet.
o パケットのための4八重奏の一連番号。
While the switches are negotiating the master/slave relationship, they exchange "empty" Database Description packets. That is, packets that contain no link summary information. Instead, the flags and sequence number constitute the information required for the negotiation process.
スイッチがマスター/奴隷関係を交渉している間、それらは「空」のDatabase記述パケットを交換します。 すなわち、いいえを含むパケットが概要情報をリンクします。 代わりに、旗と一連番号は交渉の過程に必要である情報を構成します。
See Section 10.6.2 for a more detailed description of a Database Description packet.
Database記述パケットの、より詳細な記述に関してセクション10.6.2を見てください。
7.2.2 Negotiating the Master/Slave Relationship
7.2.2 マスター/奴隷関係を交渉すること。
Before two switches can begin the actual exchange of database information, they must decide between themselves who will be the master in the exchange process and who will be the slave. They must also agree on the starting sequence number for the Database Description packets.
2個のスイッチがデータベース情報の実際の交換を始めることができる前に、それらは自分たちの間でだれが交換の過程でマスターであるだろうか、そして、だれが奴隷になるかを決めなければなりません。 また、彼らはDatabase記述パケットのために始めの一連番号に同意しなければなりません。
Once a switch has decided to form an adjacency with a neighboring switch, it sets the neighbor state to ExStart and begins sending empty Database Description packets to its neighbor. These packets contain the starting sequence number the switch plans to use in the exchange process. Also, the I-bit and M-bit flags are set, as well as the MS-bit. Thus, each switch in the exchange begins by believing it will be the master.
スイッチが、隣接しているスイッチで隣接番組を形成するといったん決めると、それは、隣人状態をExStartに設定して、空のDatabase記述パケットを隣人に送り始めます。 これらのパケットはスイッチが交換の過程で使用するのを計画している始めの一連番号を含んでいます。 また、I-ビットとM-ビット旗はMS-ビットと同様に設定されます。 したがって、それがマスターであると信じていることによって、交換における各スイッチは始まります。
Empty Database Description packets are retransmitted every RxmtInterval seconds until the neighbor responds.
空のDatabase記述パケットは再送されます。隣人までの秒が反応させるあらゆるRxmtInterval。
Kane Informational [Page 45] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[45ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
When a switch receives an empty Database Description packet from its neighbor, it determines which switch will be the master by comparing the switch IDs. The switch with the highest switch ID becomes the master of the exchange. Based on this determination, the switch proceeds as follows:
スイッチが隣人から空のDatabase記述パケットを受けるとき、それは、スイッチIDを比較することによってどのスイッチがマスターであるかを決定します。 最も高いスイッチIDがあるスイッチは交換のマスターになります。 この決断に基づいて、スイッチは以下の通り続きます:
o If the switch is to be the slave of the database exchange process,
it acknowledges that it is the slave by sending another empty
Database Description packet to the master. This packet contains
the master's sequence number and has the MS-bit and the I-bit
cleared.
o スイッチによるデータベース交換の過程の奴隷であるつもりであるなら、それは、別の空のDatabase記述パケットをマスターに送るのによる奴隷であると認めます。 このパケットで、マスターの一連番号を含んでいて、MS-ビットとI-ビットをきれいにします。
o The switch then generates a neighbor event of Negotiation Done to
change its neighbor state to Exchange and waits for the first
non-empty Database Description packet from the master.
o スイッチは、次に、隣人状態をExchangeに変えるためにNegotiation Doneの隣人出来事を発生させて、マスターから最初の非空のDatabase記述パケットを待っています。
o If the switch is to be the master of the database exchange, it
waits to receive an acknowledgment from its neighbor -- that is,
an empty Database Description packet with the MS-bit and I-bit
cleared and containing the sequence number it (the master)
previously sent.
o スイッチによるデータベース交換のマスターであるつもりであるなら、隣人から承認を受けるのを待っています--すなわち、MS-ビットとI-ビットがクリアされて、それ(マスター)が以前に送った一連番号を含んでいる空のDatabase記述パケット。
o When it receives the acknowledgment, it generates a neighbor event
of Negotiation Done to change its neighbor state to Exchange and
begin the actual exchange of Database Description packets.
o 承認を受けるとき、それは、隣人状態をExchangeに変えて、Database記述パケットの実際の交換を始めるためにNegotiation Doneの隣人出来事を発生させます。
Note that during the negotiation process, the receipt of an inconsistent packet will result in a neighbor event of Seq Number Mismatch, terminating the process. See Section 4.3 for more information.
交渉の過程の間矛盾したパケットの領収書がSeq Number Mismatchの隣人出来事をもたらすことに注意してください、過程を終えて。 詳しい情報に関してセクション4.3を見てください。
7.2.3 Exchanging Database Description Packets
7.2.3 データベース記述パケットを交換すること。
Once the neighbor state changes to Exchange, the switches begin the exchange of Database Description packets containing link state summary data. The process proceeds as follows:
かつてのExchangeへの隣人州の変化、スイッチはリンク州の概要データを含むDatabase記述パケットの交換を始めます。 過程は以下の通り続きます:
1. The master sends a packet containing a list of link state headers.
If the packet contains only a portion of the unexchanged database
-- that is, more Database Description packets are to follow -- the
packet has the M-bit set. The MS-bit is set and the I-bit is
clear.
1. マスターはリンク州のヘッダーのリストを含むパケットを送ります。 パケットが非交換されたデータベースの部分だけを含んでいるなら(すなわち、より多くのDatabase記述パケットが続くことになっています)、パケットで、M-ビットを設定します。 MS-ビットは設定されます、そして、I-ビットは明確です。
If the slave does not acknowledge the packet within RxmtInterval
seconds, the master retransmits the packet.
奴隷がRxmtInterval秒以内にパケットを承認しないなら、マスターはパケットを再送します。
Kane Informational [Page 46] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[46ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
2. When the slave receives a packet, it first checks the sequence
number to see if the packet is a duplicate. If so, it simply
acknowledges the packet by clearing the MS-bit and returning the
packet to the master. (Note that the slave acknowledges all
Database Description packets that it receives, even those that are
duplicates.)
2. 奴隷がパケットを受けるとき、それは、最初に、パケットが写しであるかどうか確認するために一連番号をチェックします。 そうだとすれば、それは、MS-ビットをきれいにして、パケットをマスターに返すことによって、単にパケットを承認します。 (奴隷がそれが受けるDatabase記述パケット、写しであるすべてのそれらさえ承認することに注意してください。)
Otherwise, the slave processes the packet by doing the following:
さもなければ、奴隷は以下をすることによって、パケットを処理します:
o For each link state header listed in the packet, the slave
searches its own link state database to determine whether it
has an instance of the advertisement.
o パケットに記載されたそれぞれのリンク州のヘッダーに関しては、奴隷は、それには広告の例があるかどうか決定するためにそれ自身のリンク州のデータベースを捜します。
o If the slave does not have an instance of the link state
advertisement, or if the instance it does have is older than
the instance listed in the packet, it creates an entry in its
link state request list in the neighbor data structure. See
Section 7.1.1 for a description of how to determine which
instance of a link state advertisement is the newest.
o 奴隷にリンク州の広告の例がないか、またはそれが持っている例が例がパケットに記載したより古いなら、それは隣人データ構造でリンク州の要求リストにおけるエントリーを作成します。 リンク州の広告のどの例が最も新しいかをどう決定するかに関する記述に関してセクション7.1.1を見てください。
o When the slave has examined all headers, it acknowledges the
packet by turning the MS-bit off and returning the packet to
the master.
o 奴隷がすべてのヘッダーを調べたとき、それは、MS-ビットをオフにして、パケットをマスターに返すことによって、パケットを承認します。
3. When the master receives the first acknowledgment for a particular
Database Description packet, it processes the acknowledgment as
follows:
3. マスターが特定のDatabase記述パケットのための最初の承認を受けるとき、以下の承認を処理します:
o For each link state header listed in the packet, the master
checks to see if the slave has indicated it has an instance of
the link state advertisement that is newer than the instance
the master has in its own database. If so, the master creates
an entry in its link state request list in the neighbor data
structure.
o パケットに記載されたそれぞれのリンク州のヘッダーがないかどうかマスターは、奴隷が、それにはマスターがそれ自身のデータベースに持っている例より新しいリンク州の広告の例があるのを示したかどうかを見るためにチェックします。 そうだとすれば、マスターは隣人データ構造でリンク州の要求リストにおけるエントリーを作成します。
o The master then increments the sequence number and sends
another packet containing the next set of link state summary
information, if any.
o マスターは、次に、一連番号を増加して、もしあればリンク州の概要情報の次のセットを含む別のパケットを送ります。
Subsequent acknowledgments for the Database Description packet
(those with the same sequence number) are discarded.
Database記述パケット(同じ一連番号があるそれら)のためのその後の承認は捨てられます。
When the master sends the last portion of its database summary
information, it clears the M-bit in the packet to indicate that no
more packets are to be sent.
マスターがデータベース概要情報の語尾を送るとき、それは、それ以上のパケットを全く送ってはいけないのを示すためにパケットでM-ビットをきれいにします。
Kane Informational [Page 47] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[47ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
4. When the slave receives a Database Description packet with the M-
bit clear, it processes the packet, as described above in step 2.
After it has completed processing and has acknowledged the packet
to the master, it generates an Exchange Done neighbor event and
its neighbor state changes to Loading.
4. Mビットが明確な状態で奴隷がDatabase記述パケットを受けるとき、パケットを処理します、ステップ2で上で説明されるように。 処理するのを完了して、マスターにパケットを認めた後に、それは、Exchange Done隣人イベントとその隣人状態がLoadingへの変化であると生成します。
The database exchange process is now complete for the slave, and
it begins the process of requesting those link state
advertisements for which the master has more current instances
(see Section 7.3).
奴隷にとって、データベース交換プロセスは現在完了しています、そして、それはマスターが、より現在のインスタンスを持っているそれらのリンク州の広告を要求するプロセスを開始します(セクション7.3を見てください)。
5. When the master receives an acknowledgment for the final Database
Description packet, it processes the acknowledgment as described
above in step 3. Then it generates an Exchange Done neighbor
event and its neighbor state changes to Loading.
5. マスターが最終的なDatabase記述パケットのための承認を受けるとき、それはステップ3で上で説明されるように承認を処理します。 そして、それは、Exchange Done隣人イベントとその隣人状態がLoadingへの変化であると生成します。
The database exchange process is now complete for the master, and
it begins the process of requesting those link state
advertisements for which the slave has more current instances (see
Section 7.3).
マスターにおいて、データベース交換プロセスは現在完了しています、そして、それは奴隷が、より現在のインスタンスを持っているそれらのリンク州の広告を要求するプロセスを開始します(セクション7.3を見てください)。
Note that during this exchange, the receipt of an inconsistent packet will result in a neighbor event of Seq Number Mismatch, terminating the process. See Section 4.3 for more information.
この交換の間矛盾したパケットの領収書がSeq Number Mismatchの隣人イベントをもたらすことに注意してください、プロセスを終えて。 詳しい情報に関してセクション4.3を見てください。
7.3 Updating the Database
7.3 データベースをアップデートすること。
When either switch completes the database exchange process and its neighbor state changes to Loading, it has a list of link state advertisements for which the neighboring switch has a more recent instance. This list is stored in the neighbor data structure as the link state request list.
どちらのスイッチもデータベース交換の過程とLoadingへのその隣人州の変化を完了すると、それには、隣接しているスイッチにより最近のインスタンスがあるリンク州の広告のリストがあります。 このリストはリンク州の要求リストとして隣人データ構造で保存されます。
To complete the synchronization of its database with that of its neighbor, the switch must obtain the most current instances of those link state advertisements.
隣人のものとのデータベースの同期を終了するために、スイッチはそれらのリンク州の広告の最も現在のインスタンスを得なければなりません。
The switch requests these advertisements by sending its neighbor a Link State Request packet containing the description of one or more link state advertisement, as defined by the advertisement's type, link state ID, and advertising switch. (For a detailed description of the Link State Request packet, see Section 10.6.3.) The switch continues to retransmit this packet every RxmtInterval seconds until it receives a reply from the neighbor.
スイッチは、広告のタイプ、リンク州のID、および広告で定義されるように1つ以上のリンク州の広告の記述を含むLink州Requestパケットを隣人に送るのによるこれらの広告が切り替わるよう要求します。 (Link州Requestパケットの詳述に関して、セクション10.6.3を見てください。) スイッチは、隣人から回答を受け取るまであらゆるRxmtIntervalが後援するこのパケットを再送し続けています。
Kane Informational [Page 48] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[48ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
When the neighbor switch receives the Link State Request packet, it responds with a Link State Update packet containing its most current instance of each of the requested advertisements. (Note that the neighboring switch can be in any of the Exchange, Loading or Full neighbor states when it responds to a Link State Request packet.)
隣人スイッチがLink州Requestパケットを受けるとき、Link州Updateパケットがそれぞれの要求された広告の最も現在のインスタンスを含んでいて、それは応じます。 (隣接しているスイッチがExchangeのどれかにあることができることに注意してください、とLink州Requestパケットに応じるとき、LoadingかFull隣人が述べます。)
If the neighbor cannot locate a particular link state advertisement in its database, something has gone wrong with the synchronization process. The switch generates a BadLSReq neighbor event and the partially formed adjacency is torn down. See Section 4.3 for more information.
隣人がデータベースにおける特定のリンク州の広告の場所を見つけることができないなら、何かが同期プロセスで支障をきたしました。 スイッチはBadLSReq隣人イベントを生成します、そして、部分的に形成された隣接番組を取りこわします。 詳しい情報に関してセクション4.3を見てください。
Depending on the size of the link state request list, it may take more than one Link State Request packet to obtain all the necessary advertisements. Note, however, that there must at most one Link State Request packet outstanding at any one time.
リンク州の要求リストのサイズによって、すべての必要な広告を得るのに1つ以上のLink州Requestパケットを要するかもしれません。 しかしながら、いかなる時も州Requestパケット未払いのほとんどの1Linkでそれがそこでそうしなければならないことに注意してください。
7.4 An Example
7.4 例
Figure 3 shows an example of an adjacency being formed between two switches -- S1 and S2 -- connected to a network link. S2 is the designated switch for the link and has a higher switch ID than S1.
図3は、隣接番組に関する例がネットワークリンクに接続された2個のスイッチ(S1とS2)の間で形成されるのを示します。 S2はリンクへの指定されたスイッチであり、S1より高いスイッチIDを持っています。
The neighbor state changes that each switch goes through are listed on the sides of the figure.
各スイッチが直面している隣人州の変化は図の側面に記載されています。
Kane Informational [Page 49] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[49ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
+--------+ +--------+
| Switch | | Switch |
| S1 | | S2 |
+--------+ +--------+
Down Down
Hello (DS=0, seen=0)
------------------------------------->
Init
Hello (DS=S2, seen=...,S1)
<-------------------------------------
ExStart
DB Description (Seq=x, I, M, Master)
------------------------------------->
ExStart
DB Description (Seq=y, I, M, Master)
<-------------------------------------
xchange
DB Description (Seq=y, M, Slave)
------------------------------------->
Exchange
DB Description (Seq=y+1, M, Master)
<-------------------------------------
DB Description (Seq=y+1, M, Slave)
------------------------------------->
.
.
.
+--------+ +--------+ | スイッチ| | スイッチ| | S1| | S2| +--------+ +--------+ Down Hello(DS=0、見られた=0)の下側に-------------------------------------こんにちは、>イニット(DS=S2、目にふれている=、…S1)<。------------------------------------- ExStart DB記述(Seq=x、I、M、マスター)------------------------------------->ExStart DB記述(Seq=y、I、M、マスター)<。------------------------------------- xchange DB記述(Seq=y、M、Slave)------------------------------------->交換DB記述(+1(M)がマスタリングするSeq=y)<。------------------------------------- DB記述(Seq=y+1(M)は身を粉にして働きます)------------------------------------->…
DB Description (Seq=y+n, Master)
<-------------------------------------
DB Description (Seq=y+n, Slave)
------------------------------------->
Loading Full
Link State Request
<-------------------------------------
Link State Update
------------------------------------->
.
.
.
DB記述(Seq=y+n、マスター)<。------------------------------------- DB記述(Seq=y+n、奴隷)------------------------------------->のローディングの完全なリンク州の要求<。------------------------------------- リンク州のアップデート------------------------------------->…
Link State Request
<-------------------------------------
Link State Update
------------------------------------->
Full
リンク州の要求<。------------------------------------- リンク州のアップデート------------------------------------->満
Figure 3: An Example of Bringing Up an Adjacency
図3: 隣接番組を持って来る例
Kane Informational [Page 50] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[50ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
At the top of Figure 3, S1's interface to the link becomes operational, and S1 begins sending Hello packets over the interface. At this point, S1 does not yet know the identity of the designated switch or of any other neighboring switches. S2 receives the Hello packet from S1 and changes its neighbor state to Init. In its next Hello packet, S2 indicates that it is itself the designated switch and that it has received a Hello packet from S1. S1 receives the Hello packet and changes its state to ExStart, starting the process of bringing up the adjacency.
図3の先端では、リンクへのS1のインタフェースは操作上になります、そして、S1はインタフェースの上でパケットをHelloに送り始めます。 ここに、S1はまだ指定されたスイッチかいかなる他の隣接しているスイッチのアイデンティティも知っていません。 S2は隣人がInitに述べるS1と変化からHelloパケットを受けます。 次のHelloパケットでは、S2はそれがそれ自体で指定されたスイッチであり、S1からHelloパケットを受けたのを示します。 隣接番組を持って来るプロセスを始めて、S1はHelloパケットを受けて、状態をExStartに変えます。
S1 begins by asserting itself as the master. When it sees that S2 is indeed the master (because of S2's higher switch ID), S1 changes to slave and adopts S2's sequence number. Database Description packets are then exchanged, with polls coming from the master (S2) and acknowledgments from the slave (S1). This sequence of Database Description packets ends when both the poll and associated acknowledgment have the M-bit off.
S1は、マスターとしてそれ自体について断言することによって、始まります。 本当に、S2がマスター(S2の、より高いスイッチIDによる)であることが見るとき、S1は身を粉にして働くために変化して、S2の一連番号を採用します。 そして、投票がマスター(S2)と承認から奴隷(S1)から来ていて、データベース記述パケットを交換します。 投票と関連承認の両方がM-ビットを休みにすると、Database記述パケットのこの系列は終わります。
In this example, it is assumed that S2 has a completely up-to-date database and immediately changes to the Full state. S1 will change to the Full state after updating its database by sending Link State Request packets and receiving Link State Update packets in response.
この例では、S2が完全に最新のデータベースを持って、すぐにFull状態に変化すると思われます。 州RequestパケットをLinkに送って、応答でLink州Updateパケットを受けることによってデータベースをアップデートした後に、S1はFull状態に変化するでしょう。
Note that in this example, S1 has waited until all Database Description packets have been received from S2 before sending any Link State Request packets. However, this need not be the case. S1 could interleave the sending of Link State Request packets with the reception of Database Description packets.
この例では、S1が待ったことにどんなLink州Requestパケットも送る前にS2からすべてのDatabase記述パケットを受け取るまで注意してください。 しかしながら、これはそうである必要はありません。 S1はDatabase記述パケットのレセプションに伴うLink州Requestパケットの発信をはさみ込むことができました。
8. Maintaining the Databases
8. データベースを維持します。
Each switch advertises its state (also known as its link state) by originating switch link advertisements. In addition, the designated switch on each network link advertises the state of the link by originating network link advertisements.
各スイッチは、スイッチリンク広告を溯源することによって、状態(また、リンク状態として、知られている)の広告を出します。 さらに、それぞれのネットワークリンクの上の指定されたスイッチは、ネットワークリンク広告を溯源することによって、リンクの状態の広告を出します。
As described in Section 7.1, link state advertisements are uniquely identified by their type, link state ID, and advertising switch.
セクション7.1で説明されるように、リンク州の広告は彼らのタイプ、リンク州のID、および広告スイッチによって唯一特定されます。
Link state advertisements are distributed throughout the switch fabric using a reliable flooding algorithm that ensures that all switches in the fabric are notified of any link state changes.
リンク州の広告は、スイッチ骨組みの間中骨組みのすべてのスイッチがどんなリンク州の変化についても通知されるのを確実にする信頼できる氾濫アルゴリズムを使用することで配布されます。
Kane Informational [Page 51] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[51ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
8.1 Originating Link State Advertisements
8.1 リンク州の広告を溯源すること。
A new instance of each link state advertisement is originated any time the state of the switch or link changes. When a new instance of a link state advertisement is originated, its sequence number is incremented, its age is set to zero, and its checksum is calculated. The advertisement is then installed into the local link state database and forwarded out all fully operational interfaces (that is, those interfaces with a state greater than Waiting) for distribution throughout the switch fabric. See Section 8.2.4 for a description of the installation of the advertisement into the link state database and Section 8.2.5 for a description of how advertisements are forwarded.
それぞれのリンク州の広告の新しいインスタンスはスイッチかリンクの状態が変化する何時でも溯源されます。 リンク州の広告の新しいインスタンスが溯源されるとき、一連番号は増加されています、そして、時代はゼロに設定されます、そして、チェックサムは計算されます。 広告を次に、ローカルのリンク州のデータベースにインストールして、スイッチ骨組みの間中分配のためにすべての完全に操作上のインタフェース(すなわち、Waitingより大きい状態とのそれらのインタフェース)から転送します。 リンク州のデータベースへの広告のインストールの記述のためのセクション8.2.4とどう広告を転送するかに関する記述のためのセクション8.2.5を見てください。
A switch originates a new instance of a link state advertisement as a result of the following events:
スイッチは以下のイベントの結果、リンク州の広告の新しいインスタンスを溯源します:
o The state of one of the switch's interfaces changes such that the
contents of the associated switch link advertisement changes.
o スイッチのインタフェースの1つの状態が変化するので、関連スイッチの内容は広告変化をリンクします。
o The designated switch on any of the switch's attached network
links changes. The switch originates a new switch link
advertisement. Also, if the switch itself is now the designated
switch, it originates a new network link advertisement for the
link.
o スイッチの付属ネットワークのどれかの指定されたスイッチは変化をリンクします。 スイッチは新しいスイッチリンク広告を溯源します。 また、現在スイッチ自体が指定されたスイッチであるなら、それは新しいネットワークリンク広告をリンクに溯源します。
o One of the switch's neighbor states changes to or from Full. If
this changes the contents of the associated switch link
advertisement, a new instance is generated. Also, if the switch
is the designated switch for the attached network link, it
originates a new network link advertisement for the link.
o スイッチの隣人のひとりはFullかFullより変化を述べます。 これが関連スイッチリンク広告のコンテンツを変えるなら、新しいインスタンスは発生しています。 また、スイッチが付属ネットワークリンクへの指定されたスイッチであるなら、それは新しいネットワークリンク広告をリンクに溯源します。
Two instances of the same link state advertisement must not be originated within the time period MinLSInterval. Note that this may require that the generation of the second instance to be delayed up to MinLSInterval seconds.
期間のMinLSInterval中に同じリンク州の広告の2つのインスタンスを溯源してはいけません。 これが、2番目の遅らせるべきインスタンスの世代がMinLSInterval秒まで上昇するのを必要とするかもしれないことに注意してください。
8.1.1 Switch Link Advertisements
8.1.1 スイッチリンク広告
A switch link advertisement describes the collected states of all functioning links attached to the originating switch -- that is, all attached links with an interface state greater than Down. A switch originates an empty switch link advertisement when it first becomes functional. It then generates a new instance of the advertisement each time one of its interfaces reaches a fully functioning state (Point-to-Point or better).
スイッチリンク広告は起因するスイッチに取り付けられたすべての機能しているリンクの集まっている州について説明します--すなわち、Downより大きい界面準位とのリンクをすべて取り付けました。 最初に機能的になると、スイッチは空のスイッチリンク広告を溯源します。 そして、それは、広告の新しいインスタンスがインタフェースの1つが完全に機能している状態(指すポイントか、より良い)に達する各回であると生成します。
Kane Informational [Page 52] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[52ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Each link in the advertisement is assigned a type, based on the state of interface, as shown in Table 4.
広告における各リンクはTable4に示されるようにインタフェースの状態に基づくタイプに割り当てられます。
Interface state Link type Description
界面準位Linkは記述をタイプします。
Point-to-Point 1 Point-to-point link
DS Other* 2 Multi-access link
Backup* 2 Multi-access link
DS** 2 Multi-access link
2 1指すポイントPointからポイントへのリンクDS Other*2Multi-アクセスリンクBackup*Multi-アクセスリンクDS**2Multi-アクセスリンク
*If a full adjacency has been formed with the designated
switch.
*指定されたスイッチで完全な隣接番組を形成してあるなら。
**If a full adjacency has been formed with at least one
other switch on the link.
**少なくとも他方で完全な隣接番組を形成してあるなら、リンクのスイッチを入れてください。
Table 4: Link Types in a Switch Link Advertisement
テーブル4: スイッチリンク広告におけるリンク型
Each link in the advertisement is also assigned a link identifier based on its link type. In general, this value identifies another switch that also originates advertisements for the link, thereby providing a key for accessing other link state advertisements for the link. The relationship between link type and ID is shown in Table 5.
また、リンク型に基づくリンク識別子は広告における各リンクに割り当てられます。 一般に、この値はまた、リンクに広告を溯源する別のスイッチを特定します、その結果、他のリンク州の広告にリンクにアクセスするためのキーを提供します。 リンク型とIDとの関係はTable5に示されます。
Type Description Link ID
型記述リンクID
1 Point-to-point link Switch ID of neighbor switch
2 Multi-access link Switch ID of designated switch
1 指定されたスイッチの隣人スイッチ2Multi-アクセスリンクSwitch IDのポイントツーポイント接続Switch ID
Table 5: Link IDs in a Switch Link Advertisement
テーブル5: スイッチリンク広告におけるリンクID
In addition to a type and an identifier, the description of each link specifies the interface ID of the associated network link.
タイプと識別子に加えて、それぞれのリンクの記述は関連ネットワークリンクのインタフェースIDを指定します。
Finally, each link description includes the cost of sending a packet over the link. This output cost is expressed in the link state metric and must be greater than zero.
最終的に、それぞれのリンク記述はリンクの上にパケットを送る費用を含んでいます。 この製作費は、リンク状態でメートル法で言い表されて、ゼロ以上であるに違いありません。
To illustrate the format of a switch link advertisement, consider the switch fabric shown in Figure 4.
スイッチリンク広告の形式を例証するには、スイッチが図4で見せられた骨組みであると考えてください。
In this example, switch SW1 has 5 neighboring switches (shown as boxes) distributed over 3 network links (shown as lines). The base MAC address of each switch is also shown adjacent to each box. On switch SW1, ports 01 and 02 attach to point-to-point network links,
この例では、スイッチSW1は5個の隣接しているスイッチ(箱として、目立つ)を3個のネットワークリンクの上に分配させます(系列として、目立ちます)。 また、それぞれのスイッチのベースMACアドレスは各箱に隣接して示されます。 スイッチSW1では、ポート01と02は二地点間ネットワークリンクに付きます。
Kane Informational [Page 53] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[53ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
while port 03 attaches to a multi-access network link with three attached switches. The interface state of each port is shown next to the line representing the corresponding link.
ポート03がマルチアクセスネットワークに付いている間、3個の付属スイッチにリンクしてください。 それぞれのポートの界面準位は対応するリンクを表す系列の横で見せられます。
00-00-1d-22-23-c5
+-------+
| SW2 |
+-------+
|
| Point-to-Point
|
| 01
+-------+ Loopback +-------+
| SW3 |----------------| SW1 | 00-00-1d-1f-05-81
+-------+ 02 +-------+
00-00-1d-17-35-a4 | 03
|
| DS Other
|
+--------------------+--------------------+
| | |
| DS Other | Backup | DS
| | |
+-------+ +-------+ +-------+
| SW4 | | SW5 | | SW6 |
+-------+ +-------+ +-------+
00-00-1d-4a-26-b3 00-00-1d-4a-27-1c 00-00-1d-7e-84-2e
00-00-1 d-22-23-c5+-------+ | SW2| +-------+ | | ポイントツーポイント| | 01 +-------+ ループバック+-------+ | SW3|----------------| SW1| 00-00-1 d-1f-05-81+-------+ 02 +-------+ 00-00-1 d-17-35-a4| 03 | | DS他です。| +--------------------+--------------------+ | | | | DS他です。| バックアップ| DS| | | +-------+ +-------+ +-------+ | SW4| | SW5| | SW6| +-------+ +-------+ +-------+ 00-00-1 d-4a-26-b3 00-00-1d-4a-27-1c00-00-1d-7e-84-2e
Figure 4: Sample Switch Fabric
図4: サンプルスイッチ骨組み
The switch link advertisement generated by switch SW1 would contain the following data items:
スイッチSW1によって作られたスイッチリンク広告は以下のデータ項目を含んでいるでしょう:
; switch link advertisement for switch SW1
; スイッチSW1のためのスイッチリンク広告
LS age = 0 ; always true on origination
Options = (T-bit|E-bit) ; options
LS type = 1 ; this is a switch link advert
LSは=0に年をとらせます。 創作Options=(T-ビット| 電子ビット)でいつも本当。 オプションLSは=1をタイプします。 これはリンクが言及するスイッチです。
Kane Informational [Page 54] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[54ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
; SW1's switch ID
Link State ID = 00-00-1d-1f-05-81-00-00-00-00
Advertising switch = 00-00-1d-1f-05-81-00-00-00-00
# links = 2
; SW1のスイッチID Link州のID=00-00-1d-1f-05-81-00-00-00-00 Advertisingスイッチ=00-00-1d-1f-05-81-00-00-00-00#リンク=2
; link on interface port 1
Link ID = 00-00-1d-22-23-c5-00-00-00-00 ; switch ID
; 1Link ID=00-00-1d-22-23-c5-00-00-00-00をインタフェースポートにリンクしてください。 スイッチID
Link Data = 00-00-1d-1f-05-81-00-00-00-01 ; interface ID
Type = 1 ; pt-to-pt link
# other metrics = 0 ; TOS 0 only
TOS 0 metric = 1
リンクデータは00-00-1 d-1f-05-81-00-00-00-01と等しいです。 ID Type=1を連結してください。 PtからPtへのリンク#他の測定基準=0。 TOS0の唯一のTOS0のメートル法の=1
; link on interface port 2 is not fully functional
; インタフェースポート2の上のリンクは完全に機能的であるというわけではありません。
; link on interface port 3
Link ID = 00-00-1d-7e-84-2e-00-00-00-00 ; switch ID of DS
Link Data = 00-00-1d-1f-05-81-00-00-00-03 ; interface ID
Type = 2 ; multi-access
# other metrics = 0 ; TOS 0 only
TOS 0 metric = 2
; 3Link ID=00-00-1d-7e-84-2e-00-00-00-00をインタフェースポートにリンクしてください。 DS Link DataのスイッチIDは00-00-1 d-1f-05-81-00-00-00-03と等しいです。 ID Type=2を連結してください。 マルチアクセス#他の測定基準=0。 TOS0の唯一のTOS0のメートル法の=2
(See Section 11.2 for a detailed description of the format of a switch link advertisement.)
(スイッチの形式の詳述のためのセクション11.2が広告をリンクするのを見てください。)
8.1.2 Network Link Advertisements
8.1.2 ネットワークリンク広告
Network link advertisements are used to describe the switches attached to each multi-access network link.
ネットワークリンク広告は、それぞれのマルチアクセスネットワークリンクに取り付けられたスイッチについて説明するのに使用されます。
Note: Network link advertisements are not generated for point-to- point links.
以下に注意してください。 ネットワークリンク広告はポイントからポイントへのリンクに作られません。
A network link advertisement is originated by the designated switch for the associated multi-access link once the switch has established a full adjacency with at least one other switch on the link. Each advertisement lists the switch IDs of those switches that are fully adjacent to the designated switch. The designated switch includes itself in this list.
リンクの上に他の少なくとも1個のスイッチがある状態でスイッチがいったん完全な隣接番組を確立すると、ネットワークリンク広告は指定されたスイッチによって関連マルチアクセスリンクに溯源されます。 各広告は指定されたスイッチに隣接してそれらのスイッチのスイッチIDを完全に記載します。 指定されたスイッチはこのリストにそれ自体を含んでいます。
To illustrate the format of a network link advertisement, consider again the switch fabric shown in Figure 4. In this example, network link advertisements will be generated only by switch SW6, the designated switch of the multi-access network link between switches SW1 and switches SW4, SW5, and SW6.
ネットワークリンク広告の形式を例証するには、スイッチが図4で見せられた骨組みであるともう一度考えてください。 この例では、ネットワークリンク広告はスイッチSW6、スイッチのスイッチのSW1と、SW4と、SW5と、SW6とのマルチアクセスネットワークリンクの指定されたスイッチだけによって作られるでしょう。
The network link advertisement generated by switch SW6 would contain the following data items:
スイッチSW6によって作られたネットワークリンク広告は以下のデータ項目を含んでいるでしょう:
Kane Informational [Page 55] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[55ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
; network link advertisement for switch SW6
; スイッチSW6のためのネットワークリンク広告
LS age = 0 ; always true on origination
Options = (T-bit|E-bit) ; options
LS type = 2 ; this is a network link advert
LSは=0に年をとらせます。 創作Options=(T-ビット| 電子ビット)でいつも本当。 オプションLSは=2をタイプします。 これはリンクが言及するネットワークです。
; SW6's switch ID
Link State ID = 00-00-1d-73-84-2e-00-00-00-00
Advertising switch = 00-00-1d-73-84-2e-00-00-00-00
; SW6のスイッチID Link州ID=00-00-1d-73-84-2e-00-00-00-00 Advertisingスイッチは00-00-1 d-73-84-2e-00-00-00-00と等しいです。
Attached switch = 00-00-1d-7e-84-2e-00-00-00-00
Attached switch = 00-00-1d-4a-26-b3-00-00-00-00
Attached switch = 00-00-1d-1f-05-81-00-00-00-00
Attached switch = 00-00-1d-4a-27-1c-00-00-00-00
付属スイッチのスイッチ=00-00-1d-4a-26-b3-00-00-00-00 Attachedスイッチ=00-00-1d-1f-05-81-00-00-00-00 Attachedスイッチ=00-00-1d-7e-84-2e-00-00-00-00 Attached=00-00-1d-4a-27-1c-00-00-00-00
(See Section 11.3 for a detailed description of the format of a
network link advertisement.)
(ネットワークの形式の詳述のためのセクション11.3が広告をリンクするのを見てください。)
8.2 Distributing Link State Advertisements
8.2 リンク州の広告を配布すること。
Link state advertisements are distributed throughout the switch fabric encapsulated within Link State Update packets. A single Link State Update packet may contain several distinct advertisements.
リンク州の広告はLink州Updateパケットの中でカプセル化されたスイッチ骨組みの間中配布されます。 単一のLink州Updateパケットはいくつかの異なった広告を含むかもしれません。
To make the distribution process reliable, each advertisement must be explicitly acknowledged in a Link State Acknowledgment packet. Note, however, that multiple acknowledgments can be grouped together into a single Link State Acknowledgment packet. A sending switch retransmits unacknowledged Link State Update packets at regular intervals until they are acknowledged.
分配プロセスを信頼できるようにするように、Link州Acknowledgmentパケットで明らかに各広告を承諾しなければなりません。 しかしながら、複数の承認を単一のLink州Acknowledgmentパケットに一緒に分類できることに注意してください。 一定の間隔を置いてそれらが承認されるまで、送付スイッチは不承認のLink州Updateパケットを再送します。
The remainder of this section is structured as follows:
このセクションの残りは以下の通り構造化されます:
o Section 8.2.1 presents an overview of the distribution process.
o セクション8.2 .1 分配プロセスの概要を提示します。
o Section 8.2.2 describes how an incoming Link State Update packet
is processed.
o セクション8.2 .2 入って来るLink州Updateパケットがどう処理されるかを説明します。
o Section 8.2.3 describes how a Link State Packet is forwarded --
both by the originating switch and an intermediate receiving
switch.
o セクション8.2 .3 起因しているスイッチと中間的受信スイッチでどうLink州Packetを進めるかを説明します。
o Section 8.2.4 describes how advertisements are installed into the
local database.
o セクション8.2.4広告がどうインストールされるかをローカルのデータベースに説明します。
o Section 8.2.5 describes the retransmission of unacknowledged
advertisements.
o セクション8.2 .5 不承認の広告の「再-トランスミッション」について説明します。
Kane Informational [Page 56] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[56ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o Section 8.2.6 describes how advertisements are acknowledged.
o セクション8.2 .6 広告がどう承諾されるかを説明します。
8.2.1 Overview
8.2.1 概要
The philosophy behind the distribution of link state advertisements is based on the concept of adjacencies -- that is, each switch is only required to remain synchronized with its adjacent neighbors.
リンク州の広告の分配の後ろの哲学は隣接番組の概念に基づいています--すなわち各スイッチが、隣接している隣人に連動したままで残るのに必要であるだけです。
When a switch originates a new instance of a link state advertisement, it formats the advertisement into a Link State Update packet and floods the packet out each fully operational interface -- that is, each interface with a state greater than Waiting. However, only those neighbors that are adjacent to the sending switch need to process the packet.
スイッチがリンク州の広告の新しいインスタンスを溯源するとき、Link州Updateパケットに広告をフォーマットして、それぞれの完全に操作上のインタフェースからパケットをあふれさせます--Waitingより大きい状態とのすなわち各インタフェース。 しかしながら、送付スイッチに隣接していないそれらの隣人しか、パケットを処理する必要があります。
The sending switch indicates which of its neighbor switches should process the advertisement by specifying a particular multicast destination in the network layer address information (see Section 10.3). The sending switch sets the value of the network layer destination switch ID field according to the state of the interface over which the packet is sent:
送付スイッチは、隣人スイッチのどれがネットワーク層アドレス情報の特定のマルチキャストの目的地を指定することによって広告を処理するべきであるかを示します(セクション10.3を見てください)。 パケットが送られるインタフェースの状態に従って、送付スイッチはネットワーク層目的地スイッチID分野の値を設定します:
o If the interface state is Point-to-Point, DS, or Backup, the
switch is adjacent to all other switches on the link and all
neighboring switches must process the packet. Therefore, the
destination field is set to the multicast switch ID
AllSPFSwitches.
o 界面準位がPointからポイント、DS、またはBackupであるなら、スイッチはリンクの上の他のすべてのスイッチに隣接しています、そして、すべての隣接しているスイッチがパケットを処理しなければなりません。 したがって、あて先フィールドはマルチキャストスイッチID AllSPFSwitchesに設定されます。
o If the interface state is DS Other, the switch is only adjacent to
the designated switch and the backup designated switch and only
those two neighboring switches must process the packet.
Therefore, the destination field is set to the multicast switch ID
AllDSwitches.
o 界面準位がDS Otherであるなら、スイッチは単に指定されたスイッチとスイッチに任命されたバックアップに隣接しています、そして、それらの2個の隣接しているスイッチだけがパケットを処理しなければなりません。 したがって、あて先フィールドはマルチキャストスイッチID AllDSwitchesに設定されます。
A similar logic is used when a switch receives a Link State Update packet containing a new instance of a link state advertisement. After processing and acknowledging the packet, the receiving switch forwards the Link State Update packet as
スイッチがリンク州の広告の新しいインスタンスを含むLink州Updateパケットを受けるとき、同様の論理は使用されています。 処理とパケットを承認する受信のときにスイッチがLink州Updateパケットを進める後
o On the interface over which the original Link State Update packet
was received:
o オリジナルのLink州Updateパケットが受け取られたインタフェースに関して:
Kane Informational [Page 57] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[57ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o If the receiving switch is the designated switch for the
attached network link, the packet is forwarded to all other
switches on the link. (The destination field is set to
AllSPFSwitches.) The originating switch will recognize that it
was the advertisement originator and discard the packet.
o 受信スイッチが付属ネットワークリンクへの指定されたスイッチであるなら、リンクの上の他のすべてのスイッチにパケットを送ります。 (あて先フィールドはAllSPFSwitchesに設定されます。) 起因するスイッチは、それが広告創始者であったと認めて、パケットを捨てるでしょう。
o If the receiving switch is not the designated switch for the
attached network link, the packet is not sent back out the
interface over which it was received.
o 受信スイッチがそうでないなら、付属ネットワークリンク、パケットが送られないので、指定されたスイッチはそれが受け取られたインタフェースの手を引きます。
o On all other interfaces:
o 他のすべてのインタフェースに関して:
o If the receiving switch is the designated switch for the
attached network link, the packet is forwarded to all switches
on the link. (The destination field is set to AllSPFSwitches.)
o 受信スイッチが付属ネットワークリンクへの指定されたスイッチであるなら、リンクの上のすべてのスイッチにパケットを送ります。 (あて先フィールドはAllSPFSwitchesに設定されます。)
o If the receiving switch is neither the designated switch or the
backup designated switch for the attached network link, the
packet is forwarded only to the designated switch and the
backup designated switch. (The destination field is set to
AllDSwitches.)
o 受信スイッチが付属ネットワークリンクのためにスイッチに任命されなかった指定されたスイッチもバックアップであるのも、指定されたスイッチとスイッチに任命されたバックアップだけにパケットを送ります。 (あて先フィールドはAllDSwitchesに設定されます。)
Each Link State Update packet is forwarded and processed in this fashion until all switches in the fabric have received notification of the new instance of the link state advertisement.
こんなやり方で骨組みのすべてのスイッチがリンク州の広告の新しいインスタンスの通知を受け取るまで、それぞれのLink州Updateパケットは、進められて、処理されます。
8.2.2 Processing an Incoming Link State Update Packet
8.2.2 入って来るリンク州のアップデートパケットを処理すること。
When the a Link State Update packet is received, it is first subjected to a number of consistency checks. In particular, the Link State Update packet is associated with a specific neighbor. If the state of that neighbor is less than Exchange, the entire Link State Update packet is discarded.
a Link州Updateパケットが受け取られているとき、それは最初に、多くの一貫性チェックにかけられます。 Link州Updateパケットは特定の隣人に特に、関連しています。 その隣人の状態がExchange以下であるなら、全体のLink州Updateパケットは捨てられます。
Each link state advertisement contained in the packet is processed as follows:
パケットに含まれたそれぞれのリンク州の広告は以下の通り処理されます:
1. Validate the advertisement's link state checksum and type. If the
checksum is invalid or the type is unknown, discard the
advertisement without acknowledging it.
1. 広告のリンク州のチェックサムを有効にしてください、そして、タイプしてください。 チェックサムが無効であるか、またはタイプが未知であるなら、それを承認しないで、広告を捨ててください。
2. If the advertisement's age is equal to MaxAge and there is
currently no instance of the advertisement in the local link state
database, then do the following:
2. 広告の年令がMaxAgeと等しく、ローカルのリンク州のデータベースに広告のインスタンスが全く現在なければ、以下をしてください:
Kane Informational [Page 58] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[58ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
a) Acknowledge the advertisement by sending a Link State
Acknowledgment packet to the sending neighbor (see Section
8.2.6).
a) Link州Acknowledgmentパケットを送付隣人に送ることによって、広告を承諾してください(セクション8.2.6を見てください)。
b) Purge all outstanding requests for equal or previous instances
of the advertisement from the sending neighbor's Link State
Request list.
b) 送付隣人のLink州Requestリストからの広告の等しいか前のインスタンスを求めるすべての傑出している要求を掃除してください。
c) If the neighbor is Exchange or Loading, install the
advertisement in the link state database (see Section 8.2.4).
Otherwise, discard the advertisement.
c) 隣人がExchangeかLoadingであるなら、リンク州のデータベースに広告をインストールしてください(セクション8.2.4を見てください)。 さもなければ、広告を捨ててください。
3. If the advertisement's age is equal to MaxAge and there is an
instance of the advertisement in the local link state database,
then do the following:
3. 広告の年令がMaxAgeと等しく、ローカルのリンク州のデータベースに広告のインスタンスがあれば、以下をしてください:
a) If the advertisement is listed in the link state retransmission
list of any neighbor, remove the advertisement from the
retransmission list(s) and delete the database copy of the
advertisement.
a) 広告がどんな隣人のリンク州の「再-トランスミッション」リストにも記載されるなら、「再-トランスミッション」リストから広告を取り除いてください、そして、広告のデータベースコピーを削除してください。
b) Discard the received (MaxAge) advertisement without
acknowledging it.
b) それを承認しないで、受け取られていている(MaxAge)広告を捨ててください。
4. If the advertisement's age is less than MaxAge, attempt to locate
an instance of the advertisement in the local link state database.
If there is no database copy of this advertisement, or the
received advertisement is more recent than the database copy (see
Section 7.1.1), do the following:
4. 広告の時代がMaxAgeより少ないなら、ローカルのリンク州のデータベースにおける広告のインスタンスの場所を見つけるのを試みてください。 この広告のデータベースコピーが全くないか、または受け取られていている広告がデータベースコピーより最近なら(セクション7.1.1を見てください)、以下をしてください:
a) If there is already a database copy, and if the database copy
was installed less than MinLSInterval seconds ago, discard the
new advertisement without acknowledging it.
a) データベースコピーが既にあって、データベースコピーがMinLSInterval秒ほどインストールされなかった、前、それを承認しないで、新しい広告を捨ててください。
b) Otherwise, forward the new advertisement out some subset of the
local interfaces (see Section 8.2.3). Note whether the
advertisement was sent back out the receiving interface for
later use by the acknowledgment process.
b) さもなければ、局所界面の何らかの部分集合から新しい広告を転送してください(セクション8.2.3を見てください)。 広告を送ったか否かに関係なく、後の使用のために承認プロセスで受信インタフェースの手を引くように注意してください。
c) Remove the current database copy from the Link state
retransmission lists of all neighbors.
c) すべての隣人のLink州の「再-トランスミッション」リストから現在のデータベースコピーを取り外してください。
d) Install the new advertisement in the link state database,
replacing the current database copy. (Note that this may cause
the calculation of the set of best paths to be scheduled. See
Section 9.) Timestamp the new advertisement with the time that
it was received to prevent installation of another instance
within MinLSInterval seconds.
d) 現在のデータベースコピーを取り替えて、リンク州のデータベースに新しい広告をインストールしてください。 (これで最も良い経路のセットの計算を予定するかもしれないことに注意してください。 セクション9を見てください。) タイムスタンプ、MinLSInterval秒以内に別のインスタンスのインストールを防ぐためにそれを受け取った時間がある新しい広告。
Kane Informational [Page 59] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[59ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
e) Acknowledge the advertisement, if necessary, by sending a Link
State Acknowledgment packet back out the receiving interface.
(See Section 8.2.6.)
e) 広告を承諾してください、そして、必要なら、Link州Acknowledgmentパケットを送ることによって、受信インタフェースの手を引いてください。 (セクション8.2.6を見てください。)
f) If the link state advertisement was initially advertised by the
local switch itself, advance the advertisement sequence number
and issue a new instance of the advertisement. (Receipt of a
newer instance of an advertisement means that the local copy of
the advertisement is left over from before the last time the
switch was restarted.)
f) リンク州の広告が初めは地方のスイッチ自体によって広告に掲載されたなら、広告一連番号を進めてください、そして、広告の新しいインスタンスを発行してください。 (広告の、より新しいインスタンスの領収書は、スイッチが前回再開されたとき広告の地方のコピーが以前から残されることを意味します。)
5. If the received advertisement is the same instance as the database
copy (as determined by the algorithm described in Section 7.1.1),
do the following:
5. 受け取られていている広告がデータベースコピーと同じインスタンス(セクション7.1.1で説明されたアルゴリズムで決定するように)であるなら、以下をしてください:
a) If the advertisement is listed in the neighbor's link state
retransmission list, the local switch is expecting an
acknowledgment for this advertisement. Treat the received
advertisement as an implied acknowledgment, and remove the
advertisement from the link state retransmission list. Note
this implied acknowledgment for later use by the acknowledgment
process (Section 8.2.6).
a) 広告が隣人のリンク州の「再-トランスミッション」リストに記載されるなら、地方のスイッチはこの広告のための承認を予想しています。 暗示している承認として受け取られていている広告を扱ってください、そして、リンク州の「再-トランスミッション」リストから広告を移してください。 承認プロセス(セクション8.2.6)で後の使用のためのこの暗示している承認に注意してください。
b) Acknowledge the advertisement, if necessary, by sending a Link
State Acknowledgment packet back out the receiving interface.
(See Section 8.2.6.)
b) 広告を承諾してください、そして、必要なら、Link州Acknowledgmentパケットを送ることによって、受信インタフェースの手を引いてください。 (セクション8.2.6を見てください。)
If the database copy of the advertisement is more recent than the
instance just received, do the following:
広告のデータベースコピーがインスタンスがただ受信されたより最近なら、以下をしてください:
a) Determine whether the instance is listed in the neighbor link
state request list. If so, an error has occurred in the
database exchange process. Restart the database exchange
process by generating a neighbor BadLSReq event for the sending
neighbor and terminate processing of the Link State Update
packet.
a) インスタンスが隣人リンク州の要求リストに記載されているかどうか決定してください。 そうだとすれば、誤りはデータベース交換プロセスに発生しました。 送付隣人のために隣人BadLSReqイベントを生成することによって、データベース交換プロセスを再開してください、そして、Link州Updateパケットの処理を終えてください。
b) Otherwise, generate an unusual event to network management and
discard the advertisement.
b) さもなければ、珍しいイベントをネットワークマネージメントに生成してください、そして、広告を捨ててください。
8.2.3 Forwarding Link State Advertisements
8.2.3 推進リンク州の広告
When a new instance of an advertisement is originated or after an incoming advertisement has been processed, the switch must decide over which interfaces and to which neighbors the advertisement will be forwarded. In some instances, the switch may decide not to forward the advertisement over a particular interface because it is able to determine that the neighbors on that attached link have or
広告の新しいインスタンスが溯源されるとき、入って来る広告が処理された後にスイッチは、広告が転送されるとどのインタフェースの上と、そして、どの隣人に決めなければならないか。 またはある場合に、スイッチが、その付属リンクの上の隣人がそうしたことを決定できるので特定のインタフェースの上に広告を転送しないと決めるかもしれない。
Kane Informational [Page 60] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[60ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
will receive the advertisement from another switch on the link.
リンクの上の別のスイッチから広告を受け取るでしょう。
The decision of whether to forward an advertisement over each of the switch's interfaces is made as follows:
それぞれのスイッチのインタフェースの上に広告を転送するかどうかに関する決定を以下の通りにします:
1. Each neighboring switch attached to the interface is examined to
determine whether it should receive and process the new
advertisement. For each neighbor, the following steps are
executed:
1. インタフェースに取り付けられたそれぞれの隣接しているスイッチは、それが新しい広告を受け取って、処理するべきであるかどうか決定するために調べられます。 各隣人に関しては、以下のステップは実行されます:
a) If the neighbor state is less than Exchange, the neighbor need
not receive or process the new advertisement.
a) 隣人状態がExchange以下であるなら、隣人は、新しい広告を受け取る必要はありませんし、また処理する必要はありません。
b) If the neighbor state is Exchange or Loading, examine the link
state request list associated with the neighbor. If an
instance of the new advertisement is on the list, the
neighboring switch already has an instance of the
advertisement. Compare the new advertisement to the neighbor's
copy:
b) 隣人状態がExchangeかLoadingであるなら、隣人に関連しているリンク州の要求リストを調べてください。 新しい広告のインスタンスがリストにあるなら、隣接しているスイッチには、広告のインスタンスが既にあります。 新しい広告を隣人のコピーにたとえてください:
o If the new advertisement is less recent, the neighbor need
not receive or process the new advertisement.
o 新しい広告がそれほど最近でないなら、隣人は、新しい広告を受け取る必要はありませんし、また処理する必要はありません。
o If the two copies are the same instance, delete the
advertisement from the link state request list. The
neighbor need not receive or process the new advertisement
[7].
o コピー2部が同じインスタンスであるなら、リンク州の要求リストから広告を削除してください。 隣人は、新しい広告[7]を受け取る必要はありませんし、また処理する必要はありません。
o Otherwise, the new advertisement is more recent. Delete the
advertisement from the link state request list. The
neighbor may need to receive and process the new
advertisement.
o さもなければ、新しい広告は、より最近です。 リンク州の要求リストから広告を削除してください。 隣人は、新しい広告を受け取って、処理する必要があるかもしれません。
c) If the new advertisement was received from this neighbor, the
neighbor need not receive or process the advertisement.
c) この隣人から新しい広告を受け取ったなら、隣人は、広告を受け取る必要はありませんし、また処理する必要はありません。
d) Add the new advertisement to the link state retransmission list
for the neighbor.
d) 隣人のためにリンク州の「再-トランスミッション」リストに新しい広告を追加してください。
2. The switch must now decide whether to forward the new
advertisement out the interface.
2. スイッチは、現在、インタフェースから新しい広告を転送するかどうか決めなければなりません。
a) If the link state advertisement was not added to any of the
link state retransmission lists for neighbors attached to the
interface, there is no need to forward the advertisement out
the interface.
a) リンク州の広告がインタフェースに付けられた隣人のためにリンク州の「再-トランスミッション」リストのいずれにも追加されなかったなら、インタフェースから広告を転送する必要は全くありません。
Kane Informational [Page 61] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[61ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
b) If the new advertisement was received on this interface, and it
was received from either the designated switch or the backup
designated switch, there is no need to forward the
advertisement out the interface. Chances are all neighbors on
the attached network link have also received the advertisement
already.
b) このインタフェースに新しい広告を受け取って、スイッチに任命された指定されたスイッチかバックアップのどちらかからそれを受け取ったなら、インタフェースから広告を転送する必要は全くありません。 多分、また、付属ネットワークリンクの上のすべての隣人が既に広告を受け取りました。
c) If the new advertisement was received on this interface and the
state of the interface is Point-to-Point, there is no need to
forward the advertisement since the received advertisement was
originated by the neighbor switch.
c) インタフェースの状態がPointからこのインタフェースに新しい広告を受け取って、ポイントであるなら、受け取られていている広告が隣人スイッチによって溯源されたので広告を転送する必要は全くありません。
d) If the new advertisement was received on this interface, and
the interface state is Backup -- that is, the switch itself is
the backup designated switch -- there is no need to forward the
advertisement out the interface. The designated switch will
distribute advertisements on the attached network link.
d) --界面準位はBackupです--このインタフェースに新しい広告を受け取って、すなわち、スイッチ自体がスイッチに任命されたバックアップであるならインタフェースから広告を転送する必要は全くありません。 指定されたスイッチは付属ネットワークリンクに関する広告を配布するでしょう。
e) Otherwise, the advertisement must be forwarded out the
interface.
e) さもなければ、インタフェースから広告を転送しなければなりません。
To forward a link state advertisement, the switch first increments
the advertisement's age by InfTransDelay seconds to account for
the transmission time over the link. The switch then copies the
advertisement into a Link State Update packet
リンク州の広告、スイッチに最初に、増分を送るために、InfTransDelayによる広告の時代はトランスミッションタイム・オーバーのためにアカウントとリンクを後援します。 そして、スイッチはLink州Updateパケットに広告をコピーします。
Forwarded advertisements are sent to all adjacent switches
associated with the interface. If the interface state is Point-
to-Point, DS, or Backup, the destination switch ID field of the
network layer address information is set to the multicast switch
ID AllSPFSwitches. If the interface state is DS Other, the
destination switch ID field is set to the multicast switch ID
AllDSwitches.
インタフェースに関連しているすべての隣接しているスイッチに転送された広告を送ります。 界面準位がある程度Pointであるか、そして、DS、またはBackup、ネットワーク層アドレス情報の目的地スイッチID分野がマルチキャストスイッチID AllSPFSwitchesに用意ができています。 界面準位がDS Otherであるなら、目的地スイッチID分野はマルチキャストスイッチID AllDSwitchesに設定されます。
8.2.4 Installing Link State Advertisements in the Database
8.2.4 リンク州の広告をデータベースにインストールすること。
When a new link state advertisement is installed into the link state database, as the result of either originating or receiving a new instance of an advertisement, the switch must determine whether the best paths need to be recalculated. To make this determination, do the following:
新しいリンク州の広告が広告の新しいインスタンスを溯源するか、または受けるという結果としてリンク州のデータベースにインストールされるとき、スイッチは、最も良い経路が、再計算される必要であるかどうか決定しなければなりません。 この決断をするには、以下をしてください:
1. Compare the contents of the new instance with the contents of the
old instance (assuming the older instance is available). Note that
this comparison does not include any data from the link state
header. Differences in fields within the header (such as the
sequence number and checksum, which are guaranteed to be different
in different instances of an advertisement) are of no consequence
1. 古いインスタンスのコンテンツと新しいインスタンスのコンテンツを比べてください(より古いインスタンスを仮定するのは利用可能です)。 この比較がリンク州のヘッダーからの少しのデータも含んでいないことに注意してください。 ヘッダー(広告の異なったインスタンスにおいて異なるように保証される一連番号やチェックサムなどの)の中の分野の違いは結果の全くものではありません。
Kane Informational [Page 62] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[62ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
when deciding whether or not to recalculate the set of best paths.
最も良い経路のセットについて再計算するかどうか決めるとき。
2. If there are no differences in the contents of the two
advertisement instances, there is no need to recalculate the set
of best paths.
2. 2つの広告インスタンスのコンテンツの違いが全くなければ、最も良い経路のセットについて再計算する必要は全くありません。
3. Otherwise, the set of best paths must be recalculated.
3. さもなければ、最も良い経路のセットについて再計算しなければなりません。
Note also that the older instance of the advertisement must be removed from the link state database when the new advertisement is installed. The older instance must also be removed from the link state retransmission lists of all neighbors.
また、新しい広告がインストールされるとき、リンク州のデータベースから広告の、より古いインスタンスを取り除かなければならないことに注意してください。 また、すべての隣人のリンク州の「再-トランスミッション」リストから、より古いインスタンスを取り除かなければなりません。
8.2.5 Retransmitting Link State Advertisements
8.2.5 リンク州の広告を再送すること。
When a switch sends a link state advertisement to an adjacent neighbor, it records the advertisement in the neighbor's link state retransmission list. To ensure the reliability of the distribution process, the switch continues to periodically retransmit the advertisements specified in the list until they are acknowledged.
スイッチがリンク州の広告を隣接している隣人に送るとき、それは隣人のリンク州の「再-トランスミッション」リストに広告を記録します。 分配プロセスの信頼性を確実にするために、スイッチは、定期的にそれらが承認されるまでリストで指定された広告を再送し続けています。
The interval timer used to trigger retransmission of the advertisements is set to RxmtInterval seconds, as found in the interface data structure. Note that if this value is too low, needless retransmissions will ensue. If the value is too high, the speed with which the databases synchronize across adjacencies may be affected if there are lost packets.
広告の「再-トランスミッション」の引き金となるのに使用されるインタバルタイマはRxmtInterval秒に設定されます、インタフェースデータ構造で見つけられるように。 この値が低過ぎるなら、不必要な「再-トランスミッション」が続くことに注意してください。 値が高過ぎるなら、無くなっているパケットがあれば、データベースが隣接番組の向こう側に同期する速度は影響を受けるかもしれません。
When the interval timer expires, entries in the retransmission list are formatted into one or more Link State Update packets. (Remember that multiple advertisements can fit into a single Link State Update packet.) The age field of each advertisement is incremented by InfTransDelay, as found in the interface data structure, before the advertisement is copied into the outgoing packet.
インタバルタイマが期限が切れるとき、「再-トランスミッション」リストにおけるエントリーは1つ以上のLink州Updateパケットにフォーマットされます。 (多ページ広告が単一のLink州Updateパケットに収まることができるのを覚えていてください。) それぞれの広告の時代分野はInfTransDelayによって増加されます、インタフェースデータ構造で見つけられるように、広告が出発しているパケットにコピーされる前に。
Link State Update packets containing retransmitted advertisements are always sent directly to the adjacent switch. That is, the destination field of the network layer addressing information is set to the switch ID of the neighboring switch.
いつも再送された広告を含むリンク州Updateパケットを直接隣接しているスイッチに送ります。 すなわち、ネットワーク層アドレス指定情報のあて先フィールドは隣接しているスイッチのスイッチIDに設定されます。
If the adjacent switch goes down, retransmissions will continue until the switch failure is detected and the adjacency is torn down by the VLSP discovery process. When the adjacency is torn down, the link state retransmission list is cleared.
隣接しているスイッチが落ちると、「再-トランスミッション」はスイッチの故障を検出して、VLSP発見プロセスで隣接番組を取りこわすまで続くでしょう。 隣接番組を取りこわすと、リンク州の「再-トランスミッション」リストをきれいにします。
Kane Informational [Page 63] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[63ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
8.2.6 Acknowledging Link State Advertisements
8.2.6 リンク州の広告を承諾すること。
Each link state advertisement received by a switch must be acknowledged. In most cases, this is done by sending a Link State Acknowledgment packet. However, acknowledgments can also be done implicitly by sending Link State Update packets (see step 4a of Section 8.2.2).
スイッチによって受け取られたそれぞれのリンク州の広告を承諾しなければなりません。 多くの場合、Link州Acknowledgmentパケットを送ることによって、これをします。 しかしながら、また、州UpdateパケットをLinkに送ることによって、それとなく承認できます(セクション8.2.2のステップ4aを見てください)。
Multiple acknowledgments can be grouped together into a single Link State Acknowledgment packet.
複数の承認を単一のLink州Acknowledgmentパケットに一緒に分類できます。
Sending an acknowledgment
承認を送ります。
Link State Acknowledgment packets are sent back out the interface
over which the advertisement was received. The packet can be sent
immediately to the sending neighbor, or it can be delayed and sent
when an interval timer expires.
パケットが送られるリンク州Acknowledgmentは広告が受け取られたインタフェースの手を引きます。 すぐ送付隣人にパケットを送ることができるか、インタバルタイマが期限が切れるとき、それを遅らせて、送ることができます。
o Sending delayed acknowledgments facilitates the formatting of
multiple acknowledgments into a single packet. This enables a
single packet to send acknowledgments to several neighbors at
once by using a multicast switch ID in the destination field of
the network layer addressing information (see below). Delaying
acknowledgments also randomizes the acknowledgment packets sent
by the multiple switches attached to a multi-access network
link.
o 遅れた承認を送ると、複数の承認の形式は単一のパケットに容易にされます。 これは、単一のパケットがすぐにネットワーク層アドレス指定情報のあて先フィールドでマルチキャストスイッチIDを使用することによって数人の隣人に承認を送るのを可能にします(以下を見てください)。 また、承認を遅らせると、マルチアクセスネットワークリンクに取り付けられた複数のスイッチによって送られた確認応答パケットはランダマイズされます。
Note that the interval used to time delayed acknowledgments
must be short (less than RxmtInterval) or needless
retransmissions will ensue.
時間まで費やされた間隔が承認を遅らせたというメモが短いに違いありませんか(RxmtIntervalよりそれほど)、または不必要な「再-トランスミッション」は続くでしょう。
Delayed acknowledgments are sent to all adjacent switches
associated with the interface. If the interface state is
Point-to-Point, DS, or Backup, the destination field of the
network layer addressing information is set to the multicast
switch ID AllSPFSwitches. If the interface state is DS Other,
the destination field is set to the multicast switch ID
AllDSwitches.
インタフェースに関連しているすべての隣接しているスイッチに遅れた承認を送ります。 界面準位がPointからポイント、DS、またはBackupであるなら、ネットワーク層アドレス指定情報のあて先フィールドはマルチキャストスイッチID AllSPFSwitchesに設定されます。 界面準位がDS Otherであるなら、あて先フィールドはマルチキャストスイッチID AllDSwitchesに設定されます。
o Immediate acknowledgments are sent directly to a specific
neighbor in response to the receipt of duplicate link state
advertisements. These acknowledgments are sent immediately
when the duplicate is received.
o 写しリンク州の広告の領収書に対応して直接特定の隣人に即座の承認を送ります。 すぐ写しが受け取られているとき、これらの承認を送ります。
The method used to send a Link State Acknowledgment packet --
either delayed or immediate -- depends on the circumstances
surrounding the receipt of the advertisement, as shown in Table 6.
Note that switches with an interface state of Backup send
Link州Acknowledgmentパケットを送るのに使用されるメソッド(遅らせられるか、または即座である)を広告の領収書を囲む事情に依存します、Table6に示されるように。 Backupの界面準位があるスイッチが発信することに注意してください。
Kane Informational [Page 64] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[64ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
acknowledgments differently than other switches because they play
a slightly different role in the distribution process (see Section
8.2.3).
分配におけるわずかに異なった役割を果たすので、他のスイッチと異なった承認は処理されます(セクション8.2.3を見てください)。
Action taken in state
Circumstances Backup Other states
州のCircumstances Backup Other州で取られた行動
Advertisement was No ack sent No ack sent
forwarded back out
receiving interface
広告はackが外でインタフェースを受けながら考慮させるために送られなかったackを全く返送したノーでした。
Advertisement is Delayed ack sent Delayed ack
more recent than if advertisement sent
database copy, but received from DS,
was not forwarded else do nothing
back out receiving
interface
広告は広告が発信したなら、データベースがしかし、DSから受け取られていた状態でコピーして、ほかに転送されなかったより最近の送られたDelayed ackが外でインタフェースを受けない戻っているものは何でもするDelayed ackです。
Advertisement was a Delayed ack sent No ack sent
duplicate treated if advertisement
as an implied acknow- received from DS,
ledgment (step 4a of else do nothing
Section 8.2.2)
広告は送られたノーackが暗示しているacknowとしての広告がDSから受信されたなら扱われた写しを送ったDelayed ackでした、ledgment(ほかのステップ4aはセクション8.2.2を何にもしません)
Advertisement was a Immediate ack Immediate ack
duplicate not treated sent sent
as an implied acknow-
ledgment
広告は送った状態で扱われなかったImmediate ack Immediate ack写しが暗示しているacknow- ledgmentとして発信したということでした。
Advertisement age Immediate ack Immediate ack
equal to MaxAge and sent sent
no current instance
found in database
MaxAgeと等しい広告時代Immediate ack Immediate ackとデータベースで見つけられた送られた送られたノー現在のインスタンス
Table 6: Sending Link State Acknowledgments
テーブル6: 送付リンク州の承認
Receiving an acknowledgment
承認を受けます。
When the a Link State Acknowledgment packet is received, it is
first subjected to a number of consistency checks. In particular,
the packet is associated with a specific neighbor. If the state of
that neighbor is less than Exchange, the entire Link State
Acknowledgment packet is discarded.
a Link州Acknowledgmentパケットが受け取られているとき、それは最初に、多くの一貫性チェックにかけられます。 パケットは特定の隣人に特に、関連しています。 その隣人の状態がExchange以下であるなら、全体のLink州Acknowledgmentパケットは捨てられます。
Each acknowledgment contained in the packet is processed as
follows:
パケットに含まれた各承認は以下の通り処理されます:
Kane Informational [Page 65] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[65ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o If the advertisement being acknowledged has an instance in the
link state retransmission list for the sending neighbor, do the
following:
o 承諾される広告が送付隣人へのリンク州の「再-トランスミッション」リストのインスタンスを持っているなら、以下をしてください:
o If the acknowledgment is for the same instance as that
specified in the list (as determined by the procedure
described in Section 7.1.1), remove the instance from the
retransmission list.
o 承認がリストのそんなに指定されるのと同じインスタンスのためのもの(セクション7.1.1で説明された手順で決定するように)であるなら、「再-トランスミッション」リストからインスタンスを取り除いてください。
o Otherwise, log the acknowledgment as questionable.
o さもなければ、疑わしいとして承認を登録してください。
8.3 Aging the Link State Database
8.3 リンク州のデータベースの年をとること。
Each link state advertisement has an age field, containing the advertisement's age, expressed in seconds. When the advertisement is copied into a Link State Update packet for forwarding out a particular interface, the age is incremented by InfTransDelay seconds to account for the transmission time over the link. An advertisement's age is never incremented past the value MaxAge. Advertisements with an age of MaxAge are not used to calculate best paths.
それぞれのリンク州の広告には、秒に表された広告の時代を含んでいて、時代分野があります。 広告が推進のために特定のインタフェースからLink州Updateパケットにコピーされるとき、増加された時代はトランスミッションタイム・オーバーのためにInfTransDelayでアカウントとリンクを後援します。 広告の時代は値のMaxAgeの先で決して増加されません。 MaxAgeの時代がある広告は、最も良い経路について計算するのに使用されません。
If a link state advertisement's age reaches MaxAge, the switch flushes the advertisement from the switch fabric by doing the following:
リンク州の広告の時代がMaxAgeに達するなら、スイッチは以下をすることによって、スイッチ骨組みからの広告を洗い流します:
o Originate a new instance of the advertisement with the age field
set to MaxAge. The distribution process will eventually result in
the advertisement being removed from the retransmission lists of
all switches in the fabric.
o MaxAgeに設定された時代分野で広告の新しいインスタンスを溯源してください。 分配プロセスは結局、骨組みですべてのスイッチの「再-トランスミッション」リストから取り除かれる広告をもたらすでしょう。
o Once the advertisement is no longer contained in the link state
retransmission list of any neighbor and no neighbor is in a state
of Exchange or Loading, remove the advertisement from the local
link state database.
o いったん広告がもうどんな隣人のリンク州の「再-トランスミッション」リストにも含まれていなくて、また隣人が全くExchangeかLoadingの州にいない後、ローカルのリンク州のデータベースから広告を取り除いてください。
8.3.1 Premature Aging of Advertisements
8.3.1 広告の時期尚早な年をとること
A link state advertisement can be prematurely flushed from the switch fabric by forcing its age to MaxAge and redistributing the advertisement.
リンク州の広告は、早まって、スイッチ骨組みからMaxAgeに時代を強制することによって洗い流されて、広告を再配付することであることができます。
A switch that was previously the designated switch for a multi-access network link but has lost that status due to a failover to the backup designated switch prematurely ages the network link advertisements it originated for the link.
以前にマルチアクセスネットワークのための指定されたスイッチがリンクされるということでしたが、フェイルオーバーのため早まってスイッチに任命されたバックアップにその状態を失ったスイッチはそれがリンクに溯源したネットワークリンク広告に年をとらせます。
Kane Informational [Page 66] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[66ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Premature aging also occurs when an advertisement's sequence number must wrap -- that is, when the current advertisement instance has a sequence number of 0x7fffffff. In this circumstance, the advertisement is prematurely aged so that the next instance of the advertisement can be originated with a sequence number of 0x80000001 and be recognized as the most recent instance.
また、広告の一連番号が包装されなければならないとき、すなわち、現在の広告インスタンスに0x7fffffffの一連番号があるとき、時期尚早な年をとることは起こります。 この状況では、広告は、早まって、広告の次のインスタンスを0×80000001の一連番号に発して、最新のインスタンスとして認識できるように熟成します。
A switch may only prematurely age those link state advertisements for which it is the advertising switch.
スイッチは早まって、それが広告スイッチであるそれらのリンク州の広告に年をとらせるだけであるかもしれません。
9. Calculating the Best Paths
9. 最も良い経路について計算します。
Once an adjacency has been formed and the two switches have synchronized their databases, each switch in the adjacency calculates the best path(s) to all other switches in the fabric, using itself as the root of each path. In this context, "best" path means that path with the lowest total cost metric across all hops. If there are multiple paths with the same (lowest) total cost metric, they are all calculated. Best paths are stored in the area data structure.
いったん隣接番組を形成してあって、2個のスイッチがそれらのデータベースを同期させると、隣接番組における各スイッチは骨組みで他のすべてのスイッチに最も良い経路について計算します、それぞれの経路の根としてそれ自体を使用して。 このような関係においては、「最も良い」経路はすべてのホップの向こう側のメートル法の最も低い総費用があるその経路を意味します。 同じ(最も低い)の総費用がメートル法であることでの複数の経路があれば、それらはすべて計算されます。 最も良い経路は領域データ構造で保存されます。
Paths are calculated using the well-known Dijkstra algorithm. For a detailed description of this algorithm, the reader is referred to [Perlman], or any of a number of standard textbooks dealing with network routing.
経路は、よく知られるダイクストラアルゴリズムを使用することで計算されます。 このアルゴリズムの詳述について、読者は[パールマン]、またはネットワークルーティングに対処する多くの標準教科書のいずれも参照されます。
Note that whenever there is a change in an adjacency relationship, or any change that alters the topology of the switch fabric, the set of best paths must be recalculated.
隣接番組関係における変化、またはスイッチ骨組みのトポロジーを変更するいくらかの変化があるときはいつも、最も良い経路のセットについて再計算しなければならないことに注意してください。
10. Protocol Packets
10. プロトコルパケット
This section describes VLS protocol packets and link state advertisements.
このセクションはVLSプロトコルパケットとリンク州の広告について説明します。
Kane Informational [Page 67] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[67ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
There are five distinct VLSP packet types, as listed in Table 7.
5つの異なったVLSPパケットタイプがTable7に記載されているようにあります。
Type Packet Name Function Description
パケット名前機能記述をタイプしてください。
1 Hello Select DS/Backup DS Section 10.6.1
2 Database Summarize database
Description contents Section 10.6.2
3 LS Request Database download Section 10.6.3
4 LS Update Database update Section 10.6.4
5 LS Ack Flooding acknow-
ledgment Section 10.6.5
1、こんにちは、Select DS/バックアップDSセクション10.6.1 2Database Summarizeデータベース記述コンテンツセクション10.6.2 3LS Request Databaseはセクション10.6.3 4LS Update Databaseアップデートセクション10.6.4 5LS Ack Flooding acknow- ledgmentセクション10.6.5をダウンロードします。
Table 7: VLSP Packet Types
テーブル7: VLSPパケットタイプ
All VLSP packets are encapsulated within a standard ISMP packet, with the VLS packet carried in the ISMP message body. The ISMP packet is described in Section 10.1.
VLSパケットがISMPメッセージボディーで運ばれている状態で、すべてのVLSPパケットが標準のISMPパケットの中でカプセルに入れられます。 ISMPパケットはセクション10.1で説明されます。
Since it is important that the link state databases remain synchronized throughout the switch fabric, processing of both incoming and outgoing routing protocol packets should take priority over ordinary data packets. Section 10.2 describes packet processing.
リンク州のデータベースがスイッチ骨組みの間中連動したままで残っているのが、重要であるので、両方の送受信のルーティング・プロトコルパケットの処理は普通のデータ・パケットの上で優先するべきです。 セクション10.2はパケット処理について説明します。
All VLSP packets begin with network layer addressing information, described in Section 10.3, followed by a standard header, described in Section 10.4.
すべてのVLSPパケットが標準のヘッダーによって後をつけられたセクション10.4で説明されたセクション10.3で説明されたネットワーク層アドレス指定情報で始まります。
With the exception of Hello packets, all VLSP packets deal with lists of link state advertisements. The format of a link state advertisement is described in Section 11.
Helloパケットを除いて、すべてのVLSPパケットがリンク州の広告のリストに対処します。 リンク州の広告の形式はセクション11で説明されます。
10.1 ISMP Packet Format
10.1 ISMPパケット・フォーマット
All VLSP packets are encapsulated within a standard ISMP packet. ISMP packets are of variable length and have the following general structure:
すべてのVLSPパケットが標準のISMPパケットの中でカプセルに入れられます。 ISMPパケットには、可変長があって、以下の一般構造体があります:
o Frame header o ISMP packet header o ISMP message body
o フレームヘッダーo ISMPパケットのヘッダーo ISMPメッセージボディー
Kane Informational [Page 68] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[68ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
10.1.1 Frame Header
10.1.1 フレームヘッダー
ISMP packets are encapsulated within an IEEE 802-compliant frame using a standard header as shown below:
ISMPパケットはIEEEの802対応することのフレームの中に以下に示すように標準のヘッダーを使用することでカプセルに入れられます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
+ Destination address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source address +
08 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
16 | |
+ +
: :
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | + 目的地アドレス+++++++++++++++++04| | | +++++++++++++++++ソースアドレス+08| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | タイプ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16 | | + + : :
Destination address
送付先アドレス
This 6-octet field contains the Media Access Control (MAC) address
of the multicast channel over which all switches in the fabric
receive ISMP packets. The destination address of all ISMP packets
contain a value of 01-00-1D-00-00-00.
この6八重奏の分野は骨組みのすべてのスイッチがISMPパケットを受けるマルチキャストチャンネルのメディアAccess Control(MAC)アドレスを含んでいます。 すべてのISMPパケットの送付先アドレスは01-00-1 D-00-00-00の値を含んでいます。
Source address
ソースアドレス
This 6-octet field contains the physical (MAC) address of the
switch originating the ISMP packet.
この6八重奏の分野はISMPパケットを溯源するスイッチの物理的な(MAC)アドレスを含んでいます。
Type
タイプ
This 2-octet field identifies the type of data carried within the
frame. The type field of ISMP packets contains the value 0x81FD.
この2八重奏の分野はフレームの中に運ばれたデータのタイプを特定します。 ISMPパケットのタイプ分野は値の0x81FDを含んでいます。
Kane Informational [Page 69] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[69ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
10.1.2 ISMP Packet Header
10.1.2 ISMPパケットのヘッダー
The ISMP packet header consists of 6 octets, as shown below:
ISMPパケットのヘッダーは以下に示されるように6つの八重奏から成ります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 |///////////////////////////////////////////////////////////////|
://////// Frame header /////////////////////////////////////////:
+//////// (14 octets) /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |///////////////////////////////| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | ISMP message type | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | |
+ +
: :
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 |///////////////////////////////////////////////////////////////| :////////フレームヘッダー/////////////////////////////////////////: +////////(14の八重奏)/////////+++++++++++++++++12|///////////////////////////////| バージョン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | ISMPメッセージタイプ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | | + + : :
Frame header
フレームヘッダー
This 14-octet field contains the frame header.
この14八重奏の分野はフレームヘッダーを含んでいます。
Version
バージョン
This 2-octet field contains the version number of the InterSwitch
Message Protocol to which this ISMP packet adheres. This document
describes ISMP Version 2.0. ISMP message type
この2八重奏の分野はこのISMPパケットが固守されるInterSwitch Messageプロトコルのバージョン番号を含んでいます。 このドキュメントはISMPバージョン2.0について説明します。 ISMPメッセージタイプ
This 2-octet field contains a value indicating which type of ISMP
message is contained within the message body. Valid values are as
follows:
この2八重奏の分野はどのタイプに関するISMPメッセージがメッセージ本体の中に含まれているかを示す値を含んでいます。 有効値は以下の通りです:
1 (reserved)
2 Interswitch Keepalive messages
3 Interswitch Link State messages
4 Interswitch Spanning Tree BPDU messages and
Interswitch Remote Blocking messages
5 Interswitch Resolve and New User messages
6 (reserved)
7 Tag-Based Flood messages
8 Interswitch Tap messages
1 2つの(予約される)のInterswitch Keepaliveメッセージ3Interswitch Link州メッセージ4Interswitch Spanning Tree BPDUメッセージとInterswitch Remote Blockingメッセージ5Interswitch ResolveとNew Userメッセージ6(予約されます)7つのベースのTag Floodメッセージ8Interswitch Tapメッセージ
All VLS protocol messages have an ISMP message type of 3.
すべてのVLSプロトコルメッセージには、3人のISMPメッセージタイプがあります。
Kane Informational [Page 70] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[70ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Sequence number
一連番号
This 2-octet field contains an internally generated sequence
number used by the various protocol handlers for internal
synchronization of messages.
この2八重奏の分野はメッセージの内部の同期に様々なプロトコル操作者によって使用された内部的に生成している一連番号を含んでいます。
10.1.3 ISMP Message Body
10.1.3 ISMPメッセージボディー
The ISMP message body is a variable-length field containing the actual data of the ISMP message. The length and content of this field are determined by the value found in the message type field. VLSP packets are contained in the ISMP message body.
ISMPメッセージボディーはISMPメッセージの実際のデータを含む可変長の分野です。 この分野の長さと内容はメッセージタイプ野原で発見される値によって測定されます。 VLSPパケットはISMPメッセージボディーに含まれています。
10.2 VLSP Packet Processing
10.2 VLSPパケット処理
Note that with the exception of Hello packets, VLSP packets are sent only between adjacent neighbors. Therefore, all packets travel a single hop.
Helloパケットを除いて、VLSPパケットが隣接している隣人だけの間に送られることに注意してください。 したがって、すべてのパケットが単一のホップを旅行します。
VLSP does not support fragmentation and reassembly of packets. Therefore, packets containing lists of link state advertisements or advertisement headers must be formatted such that they contain only as many advertisements or headers as will fit within the size constraints of a standard ethernet frame.
VLSPはパケットの断片化と再アセンブリをサポートしません。 したがって、リンク州の広告か広告ヘッダーのリストを含むパケットをフォーマットしなければならないので、彼らは広告かせいぜい標準のイーサネットフレームのサイズ規制の中で合うくらいのヘッダーだけを含みます。
When a protocol packet is received by a switch, it must first pass the following criteria before being accepted for further processing:
スイッチでプロトコルパケットを受け取るとき、さらなる処理のために受け入れる前に最初に、以下の評価基準を通過しなければなりません:
o The checksum number must be correct.
o チェックサム番号は正しいに違いありません。
o The destination switch ID (as found in the network layer address
information) must be the switch ID of the receiving switch, or one
of the multicast switch IDs AllSPFSwitches or AllDSwitches.
o 目的地スイッチID(ネットワーク層アドレス情報で見つけられるように)は、スイッチの受信スイッチのID、またはマルチキャストスイッチID AllSPFSwitchesかAllDSwitchesの1つであるに違いありません。
If the destination switch ID is the multicast switch ID
AllDSwitches, the state of the receiving interface must be Point-
to-Point, DS, or Backup.
Pointがポイントであったなら、目的地スイッチIDはID AllDSwitches、受信インタフェースの状態がそうしなければならないマルチキャストスイッチであるか、そして、DS、またはBackup。
o The source switch ID (as found in the network layer address
information) must not be that of the receiving switch. (That is,
locally originated packets should be discarded.)
o ソーススイッチID(ネットワーク層アドレス情報で見つけられるように)は受信スイッチのものであるはずがありません。 (すなわち、局所的に溯源されたパケットは捨てられるべきです。)
At this point, if the packet is a Hello packet, it is accepted for further processing.
ここに、パケットがHelloパケットであるなら、さらなる処理のためにそれを受け入れます。
Kane Informational [Page 71] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[71ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Since all other packet types are only sent between adjacent neighbors, the packet must have been sent by one of the switch's active neighbors. If the source switch ID matches the switch ID of one of the receiving switch's active neighbors (as stored in the interface data structure associated with the inport interface), the packet is accepted for further processing. Otherwise, the packet is discarded.
他のすべてのパケットタイプを隣接している隣人の間に送るだけであるので、パケットはスイッチの活発な隣人のひとりによって送られたに違いありません。 ソーススイッチIDが受信スイッチの活発な隣人のひとりのスイッチIDに合っているなら(「不-ポート」インタフェースに関連しているインタフェースデータ構造で保存されるように)、さらなる処理のためにパケットを受け入れます。 さもなければ、パケットは捨てられます。
10.3 Network Layer Address Information
10.3 ネットワーク層アドレス情報
As mentioned in Section 2.2.1, portions of the VLS protocol (as derived from OSPF) are dependent on certain network layer addresses -- in particular, the AllSPFSwitches and AllDSwitches multicast addresses that drive the distribution of link state advertisements throughout the switch fabric. In order to facilitate the implementation of the protocol at the physical MAC layer, network layer address information is encapsulated in the VSLP packets. This information immediately follows the ISMP frame and packet header and immediately precedes the VLSP packet header, as shown below:
セクション2.2.1で言及されるように、VLSプロトコル(OSPFから派生するように)の部分はあるネットワーク層アドレスに依存しています--特にリンク州の広告の分配をスイッチ骨組みに動かすAllSPFSwitchesとAllDSwitchesマルチキャストアドレス。 物理的なMAC層でプロトコルの実装を容易にするために、ネットワーク層アドレス情報はVSLPパケットでカプセル化されます。 この情報は、以下に示されるようにすぐに、ISMPフレームとパケットのヘッダーに続いて、すぐに、VLSPパケットのヘッダーに先行します:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: frame header / ISMP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Unused (20 octets) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | |
+ Source switch ID +
24 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
32 | |
+ Destination switch ID +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | |
: VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ヘッダー/ISMPヘッダーを罪に陥れてください: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | : 未使用(20の八重奏): | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | | + ソーススイッチID+24| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 32 | | + 目的地スイッチID+36| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 40 | | : VLSPヘッダー: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kane Informational [Page 72] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[72ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Source switch ID
ソーススイッチID
This 10-octet field contains the switch ID of the sending switch.
この10八重奏の分野は送付スイッチのスイッチIDを含んでいます。
Destination switch ID
目的地スイッチID
This 10-octet field contains the switch ID of the packet
destination. The value here is set as follows:
この10八重奏の分野はパケットの目的地のスイッチIDを含んでいます。 ここの値は以下の通り設定されます:
o Hello packets are addressed to the multicast switch ID
AllSPFSwitches.
o こんにちは、パケットはそうです。マルチキャストスイッチID AllSPFSwitchesに扱われます。
o The designated switch and the backup designated switch address
initial Link State Update packets and Link State Acknowledgment
packets to the multicast switch ID AllSPFSwitches.
o 指定されたスイッチとバックアップはマルチキャストスイッチID AllSPFSwitchesへの初期のLink州UpdateパケットとLink州Acknowledgmentパケットにスイッチアドレスを指定しました。
o All other switches address initial Link State Update packets
and Link State Acknowledgment packets to the multicast switch
ID AllDSwitches.
o 他のすべてのスイッチが、初期のLink州がUpdateパケットとLink州AcknowledgmentパケットであるとマルチキャストスイッチID AllDSwitchesに扱います。
o Retransmissions of Link State Update packets are always
addressed directly to the nonresponding switch.
o Link州UpdateパケットのRetransmissionsはいつも直接「非-応じ」るスイッチに扱われます。
o Database Description packets and Link State Request are always
addressed directly to the other switch participating in the
database exchange process.
o データベース記述パケットとLink州Requestはいつも直接データベース交換プロセスに参加するもう片方のスイッチに扱われます。
VLSP header
VLSPヘッダー
This 30-octet field contains the VLSP standard header. See
Section 10.4.
この30八重奏の分野はVLSPの標準のヘッダーを含んでいます。 セクション10.4を見てください。
10.4 VLSP Packet Header
10.4 VLSPパケットのヘッダー
Every VLSP packet starts with a common 30-octet header. This header, along with the data found in the network layer address information, contains all the data necessary to determine whether the packet should be accepted for further processing. (See Section 10.1.)
あらゆるVLSPパケットが一般的な30八重奏のヘッダーから始めます。 このヘッダーはネットワーク層アドレス情報で見つけられたデータと共にパケットがさらなる処理のために受け入れられるべきであるかどうか決定するのに必要なすべてのデータを含んでいます。 (セクション10.1を見てください。)
The format of the VLSP header is shown below. Note that the header starts at offset 36 of the ISMP message body, following the network layer address information.
VLSPヘッダーの書式は以下に示されます。 ネットワーク層アドレス情報に従って、ヘッダーが36のISMPのオフセットメッセージボディーで始まることに注意してください。
Kane Informational [Page 73] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[73ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: frame header / ISMP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer address information :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | (unused) | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | |
+ Source switch ID +
48 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
52 | | Area ID . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 | Area ID . . . | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
60 | Autype | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication +
64 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
68 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ヘッダー/ISMPヘッダーを罪に陥れてください: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | : ネットワーク層アドレス情報: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 40 | (未使用)です。 | タイプ| パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 44 | | + ソーススイッチID+48| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 52 | | 領域ID…| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 56 | 領域ID…| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 60 | Autype| | +++++++++++++++++認証+64| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 68 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
This 1-octet field contains the packet type. Possible values are
as follows:
この1八重奏の分野はパケットタイプを含んでいます。 可能な値は以下の通りです:
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
こんにちは、2データベース記述3リンク州が、4リンク州のアップデート5がリンクするよう要求する1は承認を述べます。
Packet length
パケット長
This 2-octet field contains the length of the protocol packet, in
bytes, calculated from the start of the VLSP header, at offset 20
of the ISMP message body. If the packet length is not an integral
number of 16-bit words, the packet is padded with an octet of zero
(see the description of the checksum field, below).
この2八重奏の分野は20のISMPのオフセットメッセージボディーにVLSPヘッダーの始まりから計算されたバイトでプロトコルパケットの長さを含んでいます。 パケット長が整数の16ビットの単語でないなら、パケットはゼロ(以下でチェックサム分野の記述を見る)の八重奏で水増しされます。
Kane Informational [Page 74] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[74ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Switch ID
スイッチID
This 10-octet field contains the switch ID of the sending switch.
この10八重奏の分野は送付スイッチのスイッチIDを含んでいます。
Area ID
領域ID
This 4-octet field contains the area identifier. Since VLSP does
not support multiple areas, the value here is always zero.
この4八重奏の分野は領域識別子を含んでいます。 VLSPが複数の領域をサポートしないので、いつもここの値はゼロです。
Checksum
チェックサム
This 2-octet field contains the packet checksum value. The
checksum is calculated as the 16-bit one's complement of the one's
complement sum of all the 16-bit words in the packet, beginning
with the VLSP header, excluding the authentication field. If the
packet length is not an integral number of 16-bit words, the
packet is padded with an octet of zero before calculating the
checksum.
この2八重奏の分野はパケットチェックサム価値を含んでいます。 チェックサムはパケットでのすべての16ビットの単語の1の補数合計の16ビットの1の補数として計算されます、VLSPヘッダーと共に始まって、認証分野を除いて。 パケット長が整数の16ビットの単語でないなら、チェックサムについて計算する前に、パケットはゼロの八重奏で水増しされます。
AuType
AuType
This 2-octet field identifies the authentication scheme to be used
for the packet. Since authentication is not supported by this
version of VLSP, this field contains zero.
この2八重奏の分野は、パケットに使用されるために認証体系を特定します。 認証がVLSPのこのバージョンで後押しされていないので、この分野はゼロを含んでいます。
Authentication
認証
This 8-octet field is reserved for use by the authentication
scheme. Since authentication is not supported by this version of
VLSP, this field contains zeroes.
この8八重奏の分野は使用のために認証体系によって予約されます。 認証がVLSPのこのバージョンで後押しされていないので、この分野はゼロを含んでいます。
10.5 Options Field
10.5 オプション分野
Hello packets and Database Description packets, as well as link state advertisements, contain a 1-octet options field. Using this field, a switch can communicate its optional capabilities to other VLSP switches. The receiving switch can then choose whether or not to support those optional capabilities. Thus, switches of differing capabilities potentially can be mixed within a single VLSP routing domain.
こんにちは、記述パケット、およびリンク州の広告が含むパケットとDatabase。1八重奏のオプション分野。 この分野を使用して、スイッチは他のVLSPスイッチへの任意の能力を伝えることができます。 そして、受信スイッチは、それらが任意の能力であるとサポートするかどうかを選ぶことができます。 したがって、ただ一つのVLSP経路ドメインの中で潜在的に異なった能力のスイッチを混ぜることができます。
Two optional capabilities are currently defined in the options field: routing based on Type of Service (TOS) and support for external routing beyond the local switch fabric. These two capabilities are specified in the options field as shown below.
2つの任意の能力が現在、オプション分野で定義されます: 地方のスイッチ骨組みを超えた外部のルーティングのService(TOS)とサポートのTypeに基づいて、掘ります。 これらの2つの能力がオプション分野で以下に示すように指定されます。
Kane Informational [Page 75] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[75ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|E|T|
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|E|T| +-+-+-+-+-+-+-+-+
The options field
オプション分野
T-bit
T-ビット
The T-bit specifies the switch's Type of Service (TOS) capability.
If the T-bit is set, the switch supports routing based on nonzero
types of service.
T-ビットはスイッチのService(TOS)能力のTypeを指定します。 T-ビットが設定されるなら、スイッチはサービスの非零タイプに基づくルーティングをサポートします。
E-bit
電子ビット
The E-bit specifies the switch's external routing capability. If
the E-bit is set, the switch supports external routing.
E-ビットはスイッチの外部のルーティング能力を指定します。 E-ビットが設定されるなら、スイッチは外部のルーティングをサポートします。
Note: The current version of VLSP supports neither of these capabilities. Therefore, both the T-bit and the E-bit are clear and the options field contains a value of zero.
以下に注意してください。 VLSPの最新版はこれらの能力のどちらもサポートしません。 したがって、T-ビットとE-ビットの両方が明確です、そして、オプション分野はゼロの値を含んでいます。
10.6 Packet Formats
10.6 パケット形式
This section contains detailed descriptions of the five VLS protocol packets.
このセクションは5つのVLSプロトコルパケットの詳述を含みます。
10.6.1 Hello Packets
10.6.1、こんにちは、パケット
Hello packets are sent periodically over multi-access switch interfaces in order to discover and maintain neighbor relationships.
こんにちは、パケットはそうです。隣人関係を発見して、維持するために定期的にマルチアクセススイッチインタフェースを移動しました。
Note: Hello packets are not sent over point-to-point network links. For point-to-point links, the VLS protocol relies on the VlanHello protocol [IDhello] to notify it of neighboring switches.
以下に注意してください。 こんにちは、パケットはそうです。ポイントツーポイントネットワークリンクを移動しませんでした。 ポイントツーポイント接続に関しては、VLSプロトコルは、隣接しているスイッチについてそれに通知するために、VlanHelloプロトコル[IDhello]を当てにします。
Since all switches connected to a common network link must agree on certain interface parameters, these parameters are included in each Hello packet. A switch receiving a Hello packet that contains parameters inconsistent with its own view of the interface will not establish a neighbor relationship with the sending switch.
一般的なネットワークリンクに接続されたすべてのスイッチが、あるインタフェース・パラメータに同意しなければならないので、これらのパラメタはそれぞれのHelloパケットに含まれています。 それ自身のインタフェースの視点に反しているパラメタを含むHelloパケットを受けるスイッチは送付スイッチとの隣人関係を確立しないでしょう。
The format of a Hello packet is shown below.
Helloパケットの書式は以下に示されます。
Kane Informational [Page 76] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[76ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer addressing / VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | (unused -- must be 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
74 | HelloInt | Options | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
78 | DeadInt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
82 | |
+ Designated switch ID +
86 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
90 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
94 | |
+ Backup designated switch ID +
98 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
102 | |
+ +
: Neighbor 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | : ネットワーク層アドレシング/VLSPヘッダー: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | (未使用--、0でなければなりません)。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 74 | HelloInt| オプション| 優先権| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 | DeadInt| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | | + 指定されたスイッチID+86| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 94 | | + スイッチID+98に任命されたバックアップ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | | + + : 隣人は記載します: + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network layer addressing / VLSP header
ネットワーク層アドレシング/VLSPヘッダー
This 70-octet field contains the network layer addressing
information and the standard VLS protocol packet header. The
packet header type field contains a value of 1.
この70八重奏の分野は情報と標準のVLSプロトコルがパケットのヘッダーであると扱うネットワーク層を含んでいます。 パケットのヘッダータイプ分野は1の値を含んでいます。
HelloInt
HelloInt
This 2-octet field contains the interval, in seconds, at which
this switch sends Hello packets.
この2八重奏の分野は秒に間隔を含みます。(その時、このスイッチはパケットをHelloに送ります)。
Options
オプション
This 1-octet field contains the optional capabilities supported by
the switch, as described in Section 10.5.
この1八重奏の分野はセクション10.5で説明されるようにスイッチによってサポートされた任意の能力を含んでいます。
Kane Informational [Page 77] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[77ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Priority
優先権
This 1-octet field contains the switch priority used in selecting
the designated switch and backup designated switch (see Section
6.3.1). If the value here is zero, the switch is ineligible to
become the designated switch or the backup designated switch.
この1八重奏の分野はスイッチに任命された指定されたスイッチとバックアップを選ぶ際に使用されるスイッチ優先権を含んでいます(セクション6.3.1を見てください)。 ここの値がゼロであるなら、スイッチは指定されたスイッチかスイッチに任命されたバックアップになるのにおいて不適格です。
DeadInt
DeadInt
This 4-octet field contains the length of time, in seconds, that
neighboring switches will wait before declaring the interface down
once they stop receiving Hello packets over the interface. The
value here is equal to the value of SwitchDeadInterval, as found
in the interface data structure.
この4八重奏の分野は秒の隣接しているスイッチがHelloパケットをインタフェースの上に受けるのをいったん止めるとインタフェースが下であると宣言する前に待っている時間の長さを含んでいます。 ここの値はインタフェースデータ構造で見つけられるようにSwitchDeadIntervalの値と等しいです。
Designated switch
スイッチに指定されます。
This 10-octet field contains the switch ID of the designated
switch for this network link, as currently understood by the
sending switch. This value is set to zero if the designated
switch selection process has not yet begun.
この10八重奏の分野はこのネットワークリンクへの指定されたスイッチのスイッチIDを含んでいます、現在送付スイッチに解釈されるように。 指定されたスイッチ選択プロセスがまだ始まっていないなら、この値はゼロに設定されます。
Backup designated switch
スイッチに任命されたバックアップ
This 10-octet field contains the switch ID of the backup
designated switch for the network link, as currently understood by
the sending switch. This value is set to zero if the backup
designated switch selection process has not yet begun.
この10八重奏の分野はネットワークリンクのためにスイッチに任命されたバックアップのスイッチIDを含んでいます、現在送付スイッチに解釈されるように。 スイッチ選択プロセスに任命されたバックアップがまだ始まっていないなら、この値はゼロに設定されます。
Neighbor list
隣人リスト
This variable-length field contains a list of switch IDs of each
switch from which the sending switch has received a valid Hello
packet within the last SwitchDeadInterval seconds.
この可変長の分野は送付スイッチが最後のSwitchDeadInterval秒以内に有効なHelloパケットを受けたそれぞれのスイッチのスイッチIDのリストを含んでいます。
10.6.2 Database Description Packets
10.6.2 データベース記述パケット
Database Description packets are exchanged while an adjacency is being formed between two neighboring switches and are used to describe the contents of the topological database. For a complete description of the database exchange process, see Section 7.2.
データベース記述パケットは、隣接番組が2個の隣接しているスイッチの間で形成されている間、交換されて、位相的なデータベースのコンテンツについて説明するのにおいて使用されています。 データベース交換プロセスの完全な記述に関しては、セクション7.2を見てください。
The format of a Database Description packet is shown below.
Database記述パケットの書式は以下に示されます。
Kane Informational [Page 78] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[78ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer addressing / VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | (unused -- must be 0) | Options | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
74 | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
78 | |
+ +
: Link state advertisement headers :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | : ネットワーク層アドレシング/VLSPヘッダー: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | (未使用--、0でなければなりません)。 | オプション| 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 74 | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 | | + + : 州の広告ヘッダーをリンクしてください: + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network layer addressing / VLSP header
ネットワーク層アドレシング/VLSPヘッダー
This 70-octet field contains the network layer addressing
information and the standard VLS protocol packet header. The
packet header type field contains a value of 2.
この70八重奏の分野は情報と標準のVLSプロトコルがパケットのヘッダーであると扱うネットワーク層を含んでいます。 パケットのヘッダータイプ分野は2の値を含んでいます。
Options
オプション
This 1-octet field contains the optional capabilities supported by
the switch, as described in Section 10.5.
この1八重奏の分野はセクション10.5で説明されるようにスイッチによってサポートされた任意の能力を含んでいます。
Flags
旗
This 1-octet field contains a set of bit flags that are used to
coordinate the database exchange process. The format of this
octet is as follows:
この1八重奏の分野はデータベース交換プロセスを調整するのに使用される1セットの噛み付いている旗を含んでいます。 この八重奏の形式は以下の通りです:
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ |0|0|0|0|0|I|M|+++++++++さん
I-bit (Init)
I-ビット(イニット)
The I-bit is used to signal the start of the exchange. It is set
while the two switches negotiate the master/slave relationship and
the starting sequence number.
I-ビットは、交換の始まりに合図するのに使用されます。 2個のスイッチがマスター/奴隷関係と始めの一連番号を交渉している間、それは設定されます。
Kane Informational [Page 79] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[79ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
M-bit (More)
M-ビット(さらに)
The M-bit is set to indicate that more Database Description
packets to follow.
M-ビットが続くようにそんなにより多くのDatabase記述パケットを示すように設定されます。
MS-bit (Master/Slave)
MS-ビット(マスター/奴隷)
The MS-bit is used to indicate which switch is the master of the
exchange. If the bit is set, the sending switch is the master
during the database exchange process. If the bit is clear, the
switch is the slave.
MS-ビットは、どのスイッチが交換のマスターであるかを示すのに使用されます。 ビットが設定されるなら、データベース交換プロセスの間、送付スイッチはマスターです。 ビットが明確であるなら、スイッチは奴隷です。
Sequence number
一連番号
This 4-octet field is used to sequence the Database Description
packets during the database exchange process. The two switches
involved in the exchange process agree on the initial value of the
sequence number during the master/slave negotiation. The number
is then incremented for each Database Description packet in the
exchange.
この4八重奏の分野はデータベース交換の間のDatabase記述パケットが処理する系列に使用されます。 交換プロセスにかかわる2個のスイッチがマスター/奴隷交渉の間、一連番号の初期の値に同意します。 そして、数は交換におけるそれぞれのDatabase記述パケットのために増加されます。
To acknowledge each Database Description packet sent by the
master, the slave sends a Database Description packet that echoes
the sequence number of the packet being acknowledged.
マスターによって送られたそれぞれのDatabase記述パケットを承認するために、奴隷はパケットの一連番号を反響するDatabase記述パケットを承認させます。
Link state advertisement headers
リンク州の広告ヘッダー
This variable-length field contains a list of link state headers
that describe a portion of the master's topological database.
Each header uniquely identifies a link state advertisement and its
current instance. (See Section 11.1 for a detailed description of
a link state advertisement header.) The number of headers
included in the list is calculated implicitly from the length of
the packet, as stored in the VLSP packet header (see Section
10.4).
この可変長の分野はマスターの位相的なデータベースの部分について説明するリンク州のヘッダーのリストを含んでいます。 各ヘッダーは唯一リンク州の広告とその現在のインスタンスを特定します。 (リンク州の広告ヘッダーの詳述に関してセクション11.1を見てください。) リストにヘッダーを含む数はパケットの長さからそれとなく計算されます、VLSPパケットのヘッダーに保存されるように(セクション10.4を見てください)。
10.6.3 Link State Request Packets
10.6.3 リンク州のリクエスト・パケット
Link State Request packets are used to request those pieces of the neighbor's database that the sending switch has discovered (during the database exchange process) are more up-to-date than instances in its own database. Link State Request packets are sent as the last step in bringing up an adjacency. (See Section 7.3.)
リンク州Requestパケットは、送付スイッチが発見した(データベース交換プロセスの間)隣人のデータベースのそれらの断片がそれ自身のデータベースのインスタンスより最新であるよう要求するのに使用されます。 隣接番組を持って来ることにおける最後のステップとしてリンク州Requestパケットを送ります。 (セクション7.3を見てください。)
The format of a Link State Request packet is shown below.
Link州Requestパケットの書式は以下に示されます。
Kane Informational [Page 80] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[80ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer addressing / VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | Link state type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
74 | |
+ Link state ID +
88 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
82 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
86 | |
+ Advertising switch ID +
90 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
94 | |
: . . . :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | : ネットワーク層アドレシング/VLSPヘッダー: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | リンク州のタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 74 | | + リンク状態ID+88| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 86 | | + 広告スイッチID+90| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | | : . . . : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network layer addressing / VLSP header
ネットワーク層アドレシング/VLSPヘッダー
This 70-octet field contains the network layer addressing
information and the standard VLS protocol packet header. The
packet header type field contains a value of 3.
この70八重奏の分野は情報と標準のVLSプロトコルがパケットのヘッダーであると扱うネットワーク層を含んでいます。 パケットのヘッダータイプ分野は3の値を含んでいます。
Link state type
リンク州のタイプ
This 4-octet field contains the link state type of the requested
link state advertisement, as stored in the advertisement header.
この4八重奏の分野は広告ヘッダーに保存されるように要求されたリンク州の広告のリンク州のタイプを含んでいます。
Link state ID
リンク州のID
This 10-octet field contains the link state ID of the requested
link state advertisement, as stored in the advertisement header.
この10八重奏の分野は広告ヘッダーに保存されるように要求されたリンク州の広告のリンク州のIDを含んでいます。
Advertising switch
広告スイッチ
This 10-octet field contains the switch ID of advertising switch
for the requested link state advertisement, as stored in the
advertisement header.
この10八重奏の分野は要求されたリンク州の広告のための広告スイッチのスイッチIDを含んでいます、広告ヘッダーに保存されるように。
Kane Informational [Page 81] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[81ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Note that the last three fields uniquely identify the
advertisement, but not its instance. The receiving switch will
respond with its most recent instance of the specified
advertisement.
最後の3つの分野が唯一インスタンスではなく、広告を特定することに注意してください。 受信スイッチは指定された広告の最新のインスタンスで反応するでしょう。
Multiple link state advertisements can be requested in a single
Link State Request packet by repeating the link state type, ID,
and advertising switch for each requested advertisement. The
number of advertisements requested is calculated implicitly from
the length of the packet, as stored in the VLSP packet header.
それぞれが広告を要求したので、単一のLink州Requestパケットでリンク州のタイプ、ID、および広告スイッチを繰り返すことによって、複数のリンク州の広告を要求できます。 要求された広告の数はパケットの長さからそれとなく計算されます、VLSPパケットのヘッダーに保存されるように。
10.6.4 Link State Update Packets
10.6.4 リンク州のアップデートパケット
Link State Update packets are used to respond to a Link State Request packet or to advertise a new instance of one or more link state advertisements. Link State Update packets are acknowledged with Link State Acknowledgment packets. For more information on the use of Link State Update packets, see Section 7 and Section 8.
リンク州Updateパケットは、Link州Requestパケットに応じるか、または1つ以上のリンク州の広告の新しいインスタンスの広告を出すのに使用されます。 リンク州UpdateパケットはLink州Acknowledgmentパケットで承認されます。 Link州Updateパケットの使用の詳しい情報に関しては、セクション7とセクション8を見てください。
The format of a Link State Update packet is shown below.
Link州Updateパケットの書式は以下に示されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer addressing / VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | # advertisements |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
74 | |
+ +
: Link state advertisements :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | : ネットワーク層アドレシング/VLSPヘッダー: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | # 広告| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 74 | | + + : 州の広告をリンクしてください: + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network layer addressing / VLSP header
ネットワーク層アドレシング/VLSPヘッダー
This 70-octet field contains the network layer addressing
information and the standard VLS protocol packet header. The
packet header type field contains a value of 4.
この70八重奏の分野は情報と標準のVLSプロトコルがパケットのヘッダーであると扱うネットワーク層を含んでいます。 パケットのヘッダータイプ分野は4の値を含んでいます。
# advertisements
# 広告
This 4-octet field contains the number of link state
advertisements included in the packet.
パケットに広告を含んでいて、この4八重奏の分野はリンク状態の数を含んでいます。
Kane Informational [Page 82] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[82ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Link state advertisements
リンク州の広告
This variable-length field contains a list of link state
advertisements. For a detailed description of the different types
of link state advertisements, see Section 11.
この可変長の分野はリンク州の広告のリストを含んでいます。 異なったタイプのリンク州の広告の詳述に関しては、セクション11を見てください。
10.6.5 Link State Acknowledgment Packets
10.6.5 リンク州の確認応答パケット
Link State Acknowledgment Packets are used to explicitly acknowledge one or more Link State Update packets, thereby making the distribution of link state advertisements reliable. (See Section 8.2.6.)
リンク州Acknowledgment Packetsは明らかに1つ以上のLink州Updateパケットを承認するのに使用されます、その結果、リンク州の広告の分配を信頼できるようにします。 (セクション8.2.6を見てください。)
The format of a Link State Acknowledgment packet is shown below.
Link州Acknowledgmentパケットの書式は以下に示されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer addressing / VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | |
+ +
: Link state advertisement headers :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | : ネットワーク層アドレシング/VLSPヘッダー: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | | + + : 州の広告ヘッダーをリンクしてください: + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network layer addressing / VLSP header
ネットワーク層アドレシング/VLSPヘッダー
This 70-octet field contains the network layer addressing
information and the standard VLS protocol packet header. The
packet header type field contains a value of 5.
この70八重奏の分野は情報と標準のVLSプロトコルがパケットのヘッダーであると扱うネットワーク層を含んでいます。 パケットのヘッダータイプ分野は5の値を含んでいます。
Link state advertisement headers
リンク州の広告ヘッダー
This variable-length field contains a list of link state headers
that are being acknowledged by this packet. Each header uniquely
identifies a link state advertisement and its current instance.
(See Section 11.1 for a detailed description of a link state
advertisement header.) The number of headers included in the list
is calculated implicitly from the length of the packet, as stored
in the VLSP packet header (see Section 10.4).
この可変長の分野はこのパケットによって承認されているリンク州のヘッダーのリストを含んでいます。 各ヘッダーは唯一リンク州の広告とその現在のインスタンスを特定します。 (リンク州の広告ヘッダーの詳述に関してセクション11.1を見てください。) リストにヘッダーを含む数はパケットの長さからそれとなく計算されます、VLSPパケットのヘッダーに保存されるように(セクション10.4を見てください)。
Kane Informational [Page 83] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[83ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
11. Link State Advertisement Formats
11. リンク州の広告形式
Link state advertisements are used to describe various pieces of the routing topology within the switch fabric. Each switch in the fabric maintains a complete set of all link state advertisements generated throughout the fabric. (Section 8.1 describes the circumstances under which a link state advertisement is originated. Section 8.2 describes how advertisements are distributed throughout the switch fabric.) This collection of advertisements, known as the link state (or topological) database, is used to calculate a set of best paths to all other switches in the fabric.
リンク州の広告は、スイッチ骨組みの中でルーティングトポロジーの様々な断片について説明するのに使用されます。 骨組みの各スイッチは骨組みの間中作られたすべてのリンク州の広告の完全なセットを維持します。 (セクション8.1はリンク州の広告が溯源される事情について説明します。 セクション8.2は広告がスイッチ骨組みの間中どう配布されるかを説明します。) リンク状態の、そして、(位相的)のデータベースとして知られている広告のこの収集は、骨組みで1セットの最も良い経路について他のすべてのスイッチに計算するのに使用されます。
There are two types of link state advertisement, as listed in Table 8.
リンク州の広告の2つのタイプがTable8に記載されているようにあります。
Type Name Function Description
型名機能記述
1 Switch link Lists all network Section 11.2
advertisement linksattached to
a switch
1 スイッチリンクListsはすべて、スイッチにlinksattachedされたセクション11.2広告をネットワークでつなぎます。
2 Network link Lists all adjacen- Section 11.3
advertisement cies on a network
link
2 ネットワークリンクListsはすべて、ネットワークリンクの上のセクション11.3広告ciesをadjacenします。
Table 8: Link State Advertisement Types
テーブル8: リンク州の広告タイプ
Each link state advertisement begins with a standard header, described in Section 11.1.
それぞれのリンク州の広告はセクション11.1で説明された標準のヘッダーと共に始まります。
11.1 Link State Advertisement Headers
11.1 リンク州の広告ヘッダー
All link state advertisements begin with a common 32-octet header. This header contains information that uniquely identifies the advertisement -- its type, link state ID, and the switch ID of its advertising switch. Also, since multiple instances of a link state advertisement can exist concurrently in the switch fabric, the header contains information that permits a switch to determine which instance is the most recent -- the age, sequence number and checksum.
すべてのリンク州の広告が一般的な32八重奏のヘッダーと共に始まります。 このヘッダーは唯一広告を特定する情報を含んでいます--タイプ、リンク州のID、および広告スイッチのスイッチID。 また、リンク州の広告の複数のインスタンスが同時にスイッチ骨組みに存在できるので、ヘッダーはスイッチが、インスタンスがどれであるかを最新の状態で決定することを許可する情報を含んでいます--時代、一連番号、およびチェックサム。
The format of the link state advertisement header is shown below.
リンク州の広告ヘッダーの書式は以下に示されます。
Kane Informational [Page 84] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[84ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | Age | Options | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04 | |
+ Link state ID +
08 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
16 | |
+ Advertising switch ID +
20 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | 時代| オプション| LSはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 04 | | + リンク状態ID+08| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16 | | + 広告スイッチID+20| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28 | チェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Age
時代
This 2-octet field contains the time, in seconds, since this
instance of the link state advertisement was originated.
リンク州の広告のこのインスタンスが溯源されたので、この2八重奏の分野は秒に時間を含みます。
Options
オプション
This 1-octet field contains the optional capabilities supported by
the advertising switch, as described in Section 10.5.
この1八重奏の分野はセクション10.5で説明されるように広告スイッチによってサポートされた任意の能力を含んでいます。
LS type
LSはタイプします。
This 1-octet field contains the type of the link state
advertisement. Possible values are:
この1八重奏の分野はリンク州の広告のタイプを含んでいます。 可能な値は以下の通りです。
1 Switch link advertisement
2 Network link advertisement
1 スイッチリンク広告2Networkリンク広告
Link state ID
リンク州のID
This 10-octet field identifies the switch that originates
advertisements for the link. The content of this field depends on
the advertisement's type.
この10八重奏の分野はリンクに広告を溯源するスイッチを特定します。 この分野の内容は広告のタイプに頼っています。
o For a switch link advertisement, this field contains the switch
ID of the originating switch
o スイッチリンク広告のために、この分野は起因するスイッチのスイッチIDを含んでいます。
Kane Informational [Page 85] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[85ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
o For a network link advertisement, this field contains the
switch ID of the designated switch for the link
o ネットワークリンク広告のために、この分野はリンクへの指定されたスイッチのスイッチIDを含んでいます。
Note: In VLSP, the link state ID of an advertisement is always the same as the advertising switch. This level of redundancy results from the fact that OSPF uses additional types of link state advertisements for which the originating switch is not the advertising switch.
以下に注意してください。 VLSPでは、広告のリンク州のIDは広告スイッチといつも同じです。 このレベルの冗長はOSPFが起因するスイッチが広告スイッチでない追加タイプのリンク州の広告を使用するという事実から生じます。
Advertising switch
広告スイッチ
This 10-octet field contains the switch ID of the switch that
originated the link state advertisement.
この10八重奏の分野はリンク州の広告を溯源したスイッチのスイッチIDを含んでいます。
Sequence number
一連番号
This 4-octet field is used to sequence the instances of a
particular link state advertisement. The number is incremented
for each new instance.
この4八重奏の分野は系列に使用されて、特定のリンクのインスタンスが広告を述べるということです。 数はそれぞれの新しいインスタンスのために増加されます。
Checksum
チェックサム
This 2-octet field contains the checksum of the complete contents
of the link state advertisement, excluding the age field. The
checksum used is commonly referred to as the Fletcher checksum and
is documented in [RFC905]. Note that since this checksum is
calculated for each separate advertisement, a protocol packet
containing lists of advertisements or advertisement headers will
contain multiple checksum values.
時代分野を除いて、この2八重奏の分野はリンク州の広告の完全なコンテンツのチェックサムを含んでいます。 使用されるチェックサムは、一般的にフレッチャーチェックサムと呼ばれて、[RFC905]に記録されます。 このチェックサムがそれぞれの別々の広告のために計算されるので広告か広告ヘッダーのリストを含むプロトコルパケットが複数のチェックサム値を含むことに注意してください。
Length
長さ
This 2-octet field contains the total length, in octets, of the
link state advertisement, including the header.
この2八重奏の分野はヘッダーを含むリンク州の広告の八重奏に全長を含んでいます。
11.2 Switch Link Advertisements
11.2 スイッチリンク広告
A switch link advertisement is used to describe all functioning network links of a switch, including the cost of using each link.
スイッチリンク広告はスイッチのすべての機能しているネットワークリンクについて説明するのに使用されます、各リンクを使用する費用を含んでいて。
Each functioning switch in the fabric originates one, and only one, switch link advertisement -- all of the switch's links must be described in a single advertisement. A switch originates its first switch link advertisement (containing no links) when it first becomes functional. It then originates a new instance of the advertisement each time any of its neighbor states changes such that the contents of the advertisement changes. See Section 8.1 for details on originating a switch link advertisement.
骨組みのそれぞれの機能しているスイッチは1、および1つだけを溯源します、スイッチリンク広告--ただ一つの広告でスイッチのリンクのすべてについて説明しなければなりません。 最初に機能的になると、スイッチは最初のスイッチリンク広告(リンクを全く含んでいない)を溯源します。 そして、隣人のどれかが変化を述べるので広告のコンテンツが変化するたびにそれは広告の新しいインスタンスを溯源します。 スイッチを溯源することに関する詳細のためのセクション8.1が広告をリンクするのを見てください。
Kane Informational [Page 86] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[86ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
The format of a switch link advertisement is shown below.
スイッチリンク広告の書式は以下に示されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Link state header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | (unused -- must be 0) | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
36 | |
+ Link ID +
40 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
48 | |
+ Link data +
52 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 | Link type | # TOS | TOS 0 metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
60 | |
: . . . :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | : 州のヘッダーをリンクしてください: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 32 | (未使用--、0でなければなりません)。 | # リンク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 36 | | + リンクID+40| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 44 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 48 | | + リンクデータ+52| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 56 | リンク型| # TOS| TOS0メートル法です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 60 | | : . . . : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link state header
リンク州のヘッダー
This 32-octet field contains the standard link state advertisement
header. The type field contains a 1, and the link state ID field
contains the switch ID of the advertising switch.
この32八重奏の分野は標準のリンク州の広告ヘッダーを含んでいます。 タイプ分野は1を含んでいます、そして、リンク州のID分野は広告スイッチのスイッチIDを含んでいます。
# links
# リンク
This 2-octet field contains the number of links described by this
advertisement. This value must be equal to the total number of
functioning network links attached to the switch.
この2八重奏の分野はこの広告で説明されたリンクの数を含んでいます。 この値はスイッチに取り付けられた機能しているネットワークリンクの総数と等しいに違いありません。
Kane Informational [Page 87] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[87ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
Link ID
IDをリンクしてください。
This 10-octet field identifies the other switch that originates
link state advertisements for the link, providing a key for
accessing other link state advertisements for the link. The value
here is based on the link type, as follows:
この10八重奏の分野はリンク州の広告をリンクに溯源するもう片方のスイッチを特定します、他のリンク州の広告にリンクにアクセスするためのキーを提供して。 ここの値は以下の通りリンク型に基づいています:
o For point-to-point links, this field contains the switch ID of
the neighbor switch connected to the other end of the link.
o ポイントツーポイント接続に関しては、この分野はリンクのもう一方の端まで接続された隣人スイッチのスイッチIDを含んでいます。
o For multi-access links, this field contains the switch ID of
the designated switch for the link.
o マルチアクセスリンクに関しては、この分野はリンクへの指定されたスイッチのスイッチIDを含んでいます。
Link data
リンクデータ
This 10-octet field contains additional data necessary to
calculate the set of best paths. Typically, this field contains
the interface ID of the link.
この10八重奏の分野は最も良い経路のセットについて計算するのに必要な追加データを含んでいます。 通常、この分野はリンクのインタフェースIDを含んでいます。
Link type
リンク型
This 1-octet field contains the type of link being described.
Possible values are as follows:
この1八重奏の分野は説明されるリンクのタイプを含んでいます。 可能な値は以下の通りです:
1 Point-to-point link
2 Multi-access link
1 ポイントツーポイント接続2Multi-アクセスリンク
# TOS
# TOS
This 1-octet field contains the number of nonzero type of service
metrics specified for the link. Since the current version of VLSP
does not support routing based on nonzero types of service, this
field contains a value of zero.
この1八重奏の分野はリンクに指定されたサービス測定基準の非零タイプの数を含んでいます。 VLSPの最新版がサービスの非零タイプに基づくルーティングをサポートしないので、この分野はゼロの値を含んでいます。
TOS 0 metric
TOS0メートル法です。
This 2-octet field contains the cost of using this link for the
zero TOS. This value is expressed in the link state metric and
must be greater than zero.
分野がゼロにこのリンクを使用することで費用を含むこの2八重奏TOS。 この値は、リンク状態でメートル法で言い表されて、ゼロ以上でなければなりません。
Note that the last five fields are repeated for all functioning network links attached to the advertising switch. If the interface state of attached link changes, the switch must originate a new instance of the switch link advertisement.
最後の5つの分野が広告スイッチに取り付けられたすべての機能しているネットワークリンクに繰り返されることに注意してください。 付属リンクの界面準位が変化するなら、スイッチはスイッチリンク広告の新しいインスタンスを溯源しなければなりません。
Kane Informational [Page 88] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[88ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
11.3 Network Link Advertisements
11.3 ネットワークリンク広告
A network link advertisement is originated by the designated switch of each multi-access network link. The advertisement describes all switches attached to the link that are currently fully adjacent to the designated switch, including the designated switch itself. See Section 8.1 for details on originating a switch link advertisement.
ネットワークリンク広告はそれぞれのマルチアクセスネットワークリンクの指定されたスイッチによって溯源されます。 広告は現在指定されたスイッチに隣接してリンクに取り付けられたすべてのスイッチについて完全に説明します、指定されたスイッチ自体を含んでいて。 スイッチを溯源することに関する詳細のためのセクション8.1が広告をリンクするのを見てください。
Network link advertisements are not generated for point-to-point network links.
ネットワークリンク広告は二地点間ネットワークリンクに作られません。
The format of a network link advertisement is show below.
ネットワークリンク広告の形式は以下のショーです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Link state header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
36 | |
+ +
: Switch 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | | : 州のヘッダーをリンクしてください: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 32 | (未使用)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 36 | | + + : リストを切り換えてください: + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link state header
リンク州のヘッダー
This 32-octet field contains the standard link state advertisement
header. The type field contains a 2, and the link state ID field
contains the switch ID of the designated switch.
この32八重奏の分野は標準のリンク州の広告ヘッダーを含んでいます。 タイプ分野は2を含んでいます、そして、リンク州のID分野は指定されたスイッチのスイッチIDを含んでいます。
Switch list
行先式の並び
The switch IDs of all switches attached to the network link that
are currently fully adjacent to the designated switch. The
designated switch includes itself in this list.
スイッチが現在指定に隣接してネットワークリンクに完全に付けたすべてのスイッチIDは切り替わります。 指定されたスイッチはこのリストにそれ自体を含んでいます。
12. Protocol Parameters
12. プロトコルパラメタ
This section contains a compendium of the parameters used in the VLS protocol.
このセクションはVLSプロトコルに使用されるパラメタに関する概要を含みます。
Kane Informational [Page 89] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[89ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
12.1 Architectural Constants
12.1 建築定数
Several VLS protocol parameters have fixed architectural values. The name of each architectural constant follows, together with its value and a short description of its function.
いくつかのVLSプロトコルパラメタが建築的価値を修理しました。 それぞれの建築定数の名前は値と機能の短い記述と共に従います。
AllSPFSwitches
AllSPFSwitches
The multicast switch ID to which Hello packets and certain other
protocol packets are addressed, as specified in the destination
switch ID field of the network layer address information (see
Section 10.3). The value of AllSPFSwitches is E0-00-00-05-00-00-
00-00.
Helloパケットと他のあるプロトコルパケットがネットワーク層アドレス情報の目的地スイッチID分野で指定されるように扱われるマルチキャストスイッチID(セクション10.3を見ます)。 AllSPFSwitchesの値はE0-00-00-05-00-00- 00-00です。
AllDSwitches
AllDSwitches
The multicast switch ID to which Link State Update packets and
Link State Acknowledgment packets are addressed, as specified in
the destination switch ID field of the network layer address
information (see Section 10.3), when they are destined for the
designated switch or the backup designated switch of a network
link. The value of AllDSwitches is E0-00-00-06-00-00-00-00.
それらが指定されたスイッチかバックアップのために運命づけられているとき、Link州UpdateパケットとLink州Acknowledgmentパケットがネットワーク層アドレス情報(セクション10.3を見る)の目的地スイッチID分野で指定されるように扱われるマルチキャストスイッチIDはネットワークリンクのスイッチを指定しました。 AllDSwitchesの値はE0-00-00-06-00-00-00-00です。
LSRefreshTime
LSRefreshTime
The interval at which the set of best paths recalculated if no
other state changes have forced a recalculation. The value of
LSRefreshTime is set to 1800 seconds (30 minutes).
何か他のものが、変化が持っていると述べないなら、最も良い経路のセットが再計算された間隔は再計算を強制しました。 LSRefreshTimeの値は1800秒(30分)に設定されます。
MinLSInterval
MinLSInterval
The minimum time between distinct originations of any particular
link state advertisement. The value of MinLSInterval is set to 5
seconds.
どんな特定のリンク州の広告の異なった創作の間の最小の時間。 MinLSIntervalの値は5秒に設定されます。
MaxAge
MaxAge
The maximum age that a link state advertisement can attain. When
an advertisement's age reaches MaxAge, it is redistributed
throughout the switch fabric. When the originating switch
receives an acknowledgment for the advertisement, indicating that
the advertisement has been removed from all neighbor Link state
retransmission lists, the advertisement is removed from the
originating switch's database. Advertisements having age MaxAge
are not used to calculate the set of best paths. The value of
MaxAge must be greater than LSRefreshTime. The value of MaxAge is
set to 3600 seconds (1 hour).
リンク州の広告が達することができる最大の時代。 広告の時代がMaxAgeに達するとき、スイッチ骨組みの間中それを再配付します。 起因するスイッチが広告のための承認を受けるとき、広告がすべての隣人Link州の「再-トランスミッション」から取り除かれたのを示すのを記載して、起因するスイッチのデータベースから広告を取り除きます。 時代MaxAgeを持っている広告は、最も良い経路のセットについて計算するのに使用されません。 MaxAgeの値はLSRefreshTimeより大きいに違いありません。 MaxAgeの値は3600秒(1時間)に設定されます。
Kane Informational [Page 90] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[90ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
MaxAgeDiff
MaxAgeDiff
The maximum time disparity in ages that can occur for a single
link state instance as it is distributed throughout the switch
fabric. Most of this time is accounted for by the time the
advertisement sits on switch output queues (and therefore not
aging) during the distribution process. The value of MaxAgeDiff is
set to 900 seconds (15 minutes).
ただ一つのリンク州のインスタンスのためにそれとして起こることができる時代の最大の時間の不一致はスイッチ骨組みの間中分配されます。 広告がスイッチ出力キューに座っている時までに(したがって、年をとらないで)この時間の大部分は分配プロセスの間、説明されます。 MaxAgeDiffの値は900秒(15分)に設定されます。
LSInfinity
LSInfinity
The link state metric value indicating that the destination is
unreachable. It is defined to be a binary value of all ones.
目的地が手が届かないのを示すリンク州のメートル法の値。 それは、すべてのものの2進の値になるように定義されます。
12.2 Configurable Parameters
12.2 構成可能なパラメタ
Many of the switch interface parameters used by VLSP may be made configurable if the implementer so desires. These parameters are listed below. Sample default values are given for some of the parameters.
implementerがそう望んでいるならVLSPによって使用されたスイッチインタフェース・パラメータの多くを構成可能にするかもしれません。 これらのパラメタは以下にリストアップされています。 パラメタのいくつかのためにサンプルデフォルト値を与えます。
Note that some of these parameters specify properties of the individual interfaces and their attached network links. These parameters must be consistent across all the switches attached to that link.
これらのパラメタのいくつかが個々のインタフェースとそれらの付属ネットワークリンクの特性を指定することに注意してください。 これらのパラメタはそのリンクに取り付けられたすべてのスイッチの向こう側に一貫しているに違いありません。
Interface output cost(s)
インタフェース製作費(s)
The cost of sending a packet over the interface, expressed in the
link state metric. This is advertised as the link cost for this
interface in the switch's switch link advertisement. The interface
output cost must always be greater than zero.
リンク状態でメートル法で言い表されたインタフェースの上にパケットを送る費用。 スイッチのスイッチリンク広告におけるこのインタフェースへのリンク費用としてこれの広告を出します。 いつもインタフェース製作費はゼロ以上であるに違いありません。
RxmtInterval
RxmtInterval
The number of seconds between link state advertisement
retransmissions for adjacencies established on this interface.
This value is also used when retransmitting Database Description
packets and Link State Request packets. This value must be greater
than the expected round-trip delay between any two switches on the
attached link. However, the value should be conservative or
needless retransmissions will result. A typical value for a local
area network would be 5 seconds.
リンク州の広告「再-トランスミッション」の間のこれで確立された隣接番組の秒数は連結します。 また、Database記述パケットとLink州Requestパケットを再送するとき、この値は使用されます。 この値は付属リンクの上のどんな2個のスイッチの間の予想された往復の遅れより大きいに違いありません。 しかしながら、値が保守的であるべきですか、または不必要な「再-トランスミッション」は結果として生じるでしょう。 ローカル・エリア・ネットワークのための典型的な値は5秒でしょう。
Kane Informational [Page 91] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[91ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
InfTransDelay
InfTransDelay
The estimated number of seconds it takes to transmit a Link State
Update packet over this interface. Link state advertisements
contained in the Link State Update packet must have their age
incremented by this amount before transmission. This value must
take into account the transmission and propagation delays for the
interface and must be greater than zero. A typical value for a
local area network would be 1 second.
Link州Updateパケットをこれの上に伝えるのに要するおよそ秒数は連結します。 Link州Updateパケットに含まれたリンク州の広告で、トランスミッションの前にこの量で彼らの時代を増加しなければなりません。 この値は、トランスミッションと伝播遅延をインタフェースに考慮に入れなければならなくて、ゼロ以上でなければなりません。 ローカル・エリア・ネットワークのための典型的な値は1秒でしょう。
Switch priority
スイッチ優先権
An 8-bit unsigned integer. When two switches attached to the same
network link contend for selection as the designated switch, the
switch with the highest priority takes precedence. If both
switches have the same priority, the switch with the highest base
MAC address becomes the designated switch. A switch whose switch
priority is set to zero is ineligible to become the designated
switch on the attached link.
8ビットの符号のない整数。 同じネットワークリンクに取り付けられた2個のスイッチが指定されたスイッチとして選択を競争するとき、最優先があるスイッチは優先します。 両方のスイッチに同じ優先権があるなら、最も高いベースMACアドレスがあるスイッチは指定されたスイッチになります。 優先権がスイッチにゼロに合わせるように設定されるスイッチは付属リンクの上の指定されたスイッチになるのにおいて不適格です。
HelloInterval
HelloInterval
The length of time, in seconds, between the Hello packets that the
switch sends over the interface. This value is advertised in the
switch's Hello packets. It must be the same for all switches
attached to a common network link. The smaller this value is set,
the faster topological changes will be detected. However, a
smaller interval will also generate more routing traffic. A
typical value for a local area network would be 10 seconds.
スイッチがインタフェースの上で送るHelloパケットの間の秒の時間の長さ。 スイッチのHelloパケットにこの値の広告を出します。 一般的なネットワークリンクに取り付けられたすべてのスイッチに、それは同じであるに違いありません。 この値が、より小さく設定されれば設定するほど、位相的な変化は、より速く検出されるでしょう。 しかしながら、また、より小さい間隔は、より多くのルーティングがトラフィックであると生成するでしょう。 ローカル・エリア・ネットワークのための典型的な値は10秒でしょう。
SwitchDeadInterval
SwitchDeadInterval
The length of time, in seconds, that neighboring switches will
wait before declaring the interface down once they stop receiving
Hello packets over the interface. This value is advertised in the
switch's Hello packets. It must be the same for all switches
attached to a common network link and should be some multiple of
the HelloInterval parameter. A typical value would be 4 times
HelloInterval.
秒の隣接しているスイッチがHelloパケットをインタフェースの上に受けるのをいったん止めるとインタフェースが下であると宣言する前に待っている時間の長さ。 スイッチのHelloパケットにこの値の広告を出します。 それは、一般的なネットワークリンクに取り付けられたすべてのスイッチに同じでなければならなく、HelloIntervalパラメタの何らかの倍数であるべきです。 典型的な値は4回のHelloIntervalでしょう。
Kane Informational [Page 92] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[92ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
13. End Notes
13. 終わりの注意
[1] During calculation of the set of best paths, a network link advertisement must be located based solely on its link state ID. Note, however, that the lookup in this case is still well defined, since no two network advertisements can have the same link state ID.
[1] 最も良い経路のセットの計算の間、ネットワークリンク広告の唯一リンク州のIDに基づいた状態で見つけなければなりません。 しかしながら、この場合、ルックアップがまだよく定義されていて、どんな2以来も、同じリンクがネットワーク広告でIDを述べることができないことに注意してください。
[2] It is instructive to see what happens when the designated switch for a network link fails. Call the designated switch for the link S1 and the backup designated switch S2. If switch S1 fails (or its interface to the link goes down), the other switches on the link will detect S1's absence within SwitchDeadInterval seconds. All switches may not detect this condition at precisely the same time. The switches that detect S1's absence before S2 does will temporarily select S2 as both designated switch and backup designated switch. When S2 detects that S1 is down, it will move itself to designated switch. At this time, the remaining switch with the highest switch priority will be selected as the backup designated switch.
[2] ネットワークリンクへの指定されたスイッチが失敗すると何が起こるかわかるのはためになっています。 リンクS1とスイッチS2に任命されたバックアップのために指定されたスイッチに電話をしてください。 スイッチS1が失敗すると(リンクへのインタフェースは落ちます)、リンクの上の他のスイッチはSwitchDeadInterval秒以内にS1の不在を検出するでしょう。 すべてのスイッチは正確に同時にこの状態を検出しないかもしれません。 S2が検出する前にS1の不在を検出するスイッチはともにスイッチに任命されたスイッチとバックアップに指定されているとしての一時選んだS2がそうするでしょう。 S2がそれを検出するとき、S1が下がっている、それはそれ自体を指定されたスイッチに動かすでしょう。 バックアップがスイッチを指定したので、このとき、最も高いスイッチ優先度がある残っているスイッチは選択されるでしょう。
[3] Note that it is possible for a switch to resynchronize any of its fully established adjacencies by setting the neighbor state back to ExStart. This causes the switch on the other end of the adjacency to process a SeqNumberMismatch event and also revert to the ExStart state.
[3] スイッチが隣人状態をExStartに遅らせることによって完全に確立した隣接番組のどれかを再連動させるのが、可能であることに注意してください。 これは隣接番組のもう一方の端のスイッチがSeqNumberMismatch出来事を処理して、また、ExStart状態に戻ることを引き起こします。
[4] When two advertisements have different checksum values, they are assumed to be separate instances. This can occur when a switch restarts and loses track of its previous sequence number. In this case, since the two advertisements have the same sequence number, it is not possible to determine which advertisement is actually newer. If the wrong advertisement is accepted as newer, the originating switch will originate another instance.
[4] 2つの広告に異なったチェックサム値があると、それらは別々の例であると思われます。 スイッチが前の一連番号を再開して、見失うとき、これは起こることができます。 2つの広告には同じ一連番号があるので、この場合、どちらの広告が実際により新しいかを決定するのは可能ではありません。 間違った広告が、より新しいとして認められると、由来しているスイッチは別の例を溯源するでしょう。
[5] An instance of an advertisement is originated with an age of MaxAge only when it is to be flushed from the database. This is done either when the advertisement has naturally aged to MaxAge, or (more typically) when the sequence number must wrap. Therefore, a received instance with an age of MaxAge must be processed as the most recent in order to flush it properly from the database.
[5] 広告の例はそれがデータベースから洗い流されることになっているMaxAgeだけの時代で溯源されます。 これによる広告に一連番号がMaxAge、または(より典型的)いつまでの高年層のために自然にあるかとき、して、どちらかが包装されなければならないということです。 したがって、データベースからそれを適切に洗い流すために最新であるとしてMaxAgeの時代がある容認された例を処理しなければなりません。
[6] MaxAgeDiff is an architectural constant that defines the maximum disparity in ages, in seconds, that can occur for a single link state instance as it is distributed throughout the switch fabric. If two advertisements differ by more than this amount, they are assumed to be different instances of the same advertisement. This can occur when a switch restarts and loses track of its previous sequence number.
[6] MaxAgeDiffは時代、秒のそれがスイッチ織物の間中分配されるときただ一つのリンク州の例のために起こることができる最大の不一致を定義する建築定数です。 2つの広告がこの量以上で異なるなら、それらは同じ広告の異なった例であると思われます。 スイッチが前の一連番号を再開して、見失うとき、これは起こることができます。
Kane Informational [Page 93] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[93ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
[7] This is how the link state request list is emptied, causing the neighbor state to change to Full.
[7] これは隣人状態がFullに変化することを引き起こして、リンク州の要求リストがどう空にされているかということです。
14. Security Considerations
14. セキュリティ問題
Security concerns are not addressed in this document.
安全上の配慮は本書では記述されません。
15. References
15. 参照
[Perlman] Perlman, R., Interconnections: Bridges and Routers.
Addison-Wesley Publishing Company. 1992.
[パールマン]パールマン、R.、インタコネクト: 橋とルータ。 アディソン-ウエスリー出版社。 1992.
[RFC905] McKenzie, A., "ISO Transport Protocol specification ISO
DP 8073", RFC 905, April 1984.
[RFC905] マッケンジー、A.、「ISO Transportプロトコル仕様ISO DP8073」、RFC905、1984年4月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
[RFC1700] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[IDsfvlan] Ruffen, D., Len, T. and J. Yanacek, "Cabletron's
SecureFast VLAN Operational Model", RFC 2643, August
1999.
[IDsfvlan]RuffenとD.とレンとT.とJ.Yanacek、「CabletronのSecureFast VLANオペレーショナル・モデル」、RFC2643、1999年8月。
[IDhello] Hamilton, D. and D. Ruffen, "Cabletron's VlanHello
Protocol Specification", RFC 2641, August 1999.
[IDhello] ハミルトンとD.とD.Ruffen、「CabletronのVlanHelloプロトコル仕様」、RFC2641、1999年8月。
16. Author's Address
16. 作者のアドレス
Laura Kane Cabletron Systems, Inc. Post Office Box 5005 Rochester, NH 03866-5005
Inc.Post Office Box5005ロチェスター、ローラケーンCabletron Systemsニューハンプシャー03866-5005
Phone:(603) 332-9400 EMail: lkane@ctron.com
電話: (603) 332-9400 メールしてください: lkane@ctron.com
Kane Informational [Page 94] RFC 2642 Cabletron's VLS Protocol Specification August 1999
ケーン情報[94ページ]のRFC2642CabletronのVLSプロトコル仕様1999年8月
17. Full Copyright Statement
17. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kane Informational [Page 95]
ケーンInformationalです。[95ページ]
一覧
スポンサーリンク
