要約

  • DECは1986年のLANBridge 100で分散スパニングツリーを製品に組み込み、ループを避けながら余分なイーサネットリンクを予備として残せるようにした。
  • IEEE 802.1Dも同じ論理ツリーを計算したが、Helloのマルチキャスト形式はDECと異なった。移行用ブリッジはどちらか一つのモードを選んで動作した。規格が刊行されても既存機器が自動的に相互運用できたわけではない。

ブリッジが二つのイーサネット区間を接続すれば、端末からは一つのLANのように見える。ところが冗長な配線は閉じた経路を生み、ブロードキャストフレームが何度も複製される危険を持つ。余分な線をすべて撤去すればループは防げる一方、リンク障害への備えも失う。スパニングツリーはこの二択を避ける。物理的に接続されているリンクのうち、通常時にフレームを通す論理的な道筋を一つの木として選び、余った接続を待機させる。

Radia Perlmanの1985年の論文は、拡張LAN上のブリッジが分散計算で閉路のない全域部分網を求める方法を示した。各ブリッジはルートを選び、各LANの指定ブリッジを決定し、木に含まれない経路を転送から外す。論文の要旨は、収束時間がネットワークの直径に比例し、ブリッジごとのメモリ量と各LAN上の通信帯域は全ブリッジ数・全リンク数に依存しないと述べる。これはアルゴリズムの性質であり、製品の販売実績や普及率の証拠ではない。

DECでの製品化には実験と設計の段階があった。1986年9月のDigital Technical Journalによれば、Brooklyn Bridgeと呼ばれた初期試作機は研究所で動作したのち、マサチューセッツ州TewksburyでイーサネットとDigitalのEngineering Networkの間に設置された。Janusという製品開発計画がLANBridge 100につながった。設計者は無人でも正しく起動し、ループなど不都合な構成を見つけることを目指した。同時に、ネットワーク管理者が動作カウンターを観測し、一部のパラメーターを調整できる必要もあった。木を計算するだけでなく、アドレス学習、フレーム処理、管理、冗長時の待機動作まで製品として組み合わせた。

待機中のリンクは無駄な線ではなかった。橋やリンクが停止して構成が変われば、計算し直して別の経路を転送側に回せる。ただし、これはブリッジの転送トポロジーを制御する話であり、アプリケーションのデータが端末まで届いたことや、サービスに停止がなかったことを証明しない。

DECはこのアルゴリズムをIEEEに提案した。IEEE 802.1DはMACブリッジが同じ論理的な木を構成するための規則を定める。IEEEの記録では、理事会承認は1990年5月31日、ANSI承認は同年10月18日、刊行は1991年3月8日である。三つの日付は標準化手順の節目であり、ネットワークが一斉に切り替わった日ではない。

Digitalのブリッジ管理書は、運用上の差を詳しく残している。LANBridge 100とIEEE 802.1Dは同じ論理木になる一方、Helloのマルチキャスト宛先が異なった。一方のモードにあるブリッジは、もう一方のHelloを解釈できない。混在した拡張LANでは別々のツリーができる場合があり、配置や起動順によっては転送状態を予測できず、不安定になることもあった。同じ計算結果を目指すことと、制御メッセージが互換であることは別問題だった。

そこでDigitalは後続のLAN Bridge 150、200、DECbridge 500/600にAuto-Selectを用意した。これらはLANBridge 100の存在を検知して旧方式に切り替え、旧機器がなくなればIEEE方式へ移行できた。管理者がIEEE方式に固定する選択肢もあった。ブリッジは一度に一つのスパニングツリーモードしか実行しない。手引きには旧型機の位置を探すポーリング手順も記録されるが、導入企業が何社それを完遂したかは示していない。

この歴史は「標準が出れば互換性も揃う」という話ではない。分散アルゴリズム、製品としての実装、IEEE規格、そして二つのHello方式をつなぐ移行用ブリッジは、順番に必要になった。資料はその仕組みと移行経路を裏付けるが、全ネットワークでの普及や「STPがイーサネットを救った」という単一原因の物語までは裏付けない。

Sources