(57)【要約】      （修正有）【課題】冗長化ネットワークについて最短経路での通信を可能にすることで帯域を有効活用し、通信負荷の軽減を図る。【解決手段】ＲＴブリッジ１−１、１−２、・・・は、端末間の通信をＦＤＢ４に基づき最短経路で中継する。このＦＤＢ４のエントリーは、ＭＡＣＲＩＢ６から得られる。このＭＡＣＲＩＢ６は、ルートパスベクトルＤＢ７とＭＡＣサブネットＤＢ８から合成される。この両ＤＢ７，８の構築時にはネイバーテーブル９が参照される。このネイバーテーブル９は、隣接ＲＴブリッジとの間でＲＴ−ＢＰＤＵ１０を交換する作成される。【選択図】図２
2020010102.tif 000002
【特許請求の範囲】
【請求項１】
冗長化されたネットワークにおいて端末間の通信を中継し、各端末への経路情報を格納する格納部を備えた中継装置であって、
前記経路情報には、前記各端末のＭＡＣアドレスと、
前記各端末を中継する中継装置をルートとしたルートパスベクトルと、
が対照に保持され、
前記経路情報に基づき前記端末間の通信を中継することを特徴とする中継装置。
【請求項２】
前記ルートパスベクトルが複数存在すれば、前記ルートへのルートパスコストが最小の前記ルートパスベクトルを選択し、
前記ルートパスコストの最小の前記ルートベクトルが複数存在すれば、任意に一つを選択することを特徴とする請求項１記載の中継装置。
【請求項３】
前記ルートに最も近いポートの番号が、前記ＭＡＣアドレスおよび前記ルートパスベクトルに対応付けられている
ことを特徴とする請求項１または２記載の中継装置。
【請求項４】
前記ルートパスベクトルが記述されたプロトコルデータユニットを隣接する前記中継装置間で送受信することにより、
前記ルートパスコストの最小の前記ルートパスベクトルが求められることを特徴とする請求項２記載の中継装置。
【請求項５】
前記データユニットの受信の有無に応じた前記ポート毎の識別情報と、前記ポートに接続された隣接する前記中継装置の情報とを対応付けて保存する第１の保存部と、
前記各中継装置の前記ポート毎に接続されている前記端末のＭＡＣアドレスを保存する第２の保存部と、
前記ルートパスベクトルが保存される第３の保存部と、をさらに備え、
前記第２の保存部の保存情報と第３保存部の保存情報とを作成する際には、前記第１の保存部の保存情報が参照される一方、
前記経路情報は、前記第２の保存部の保存情報と前記第３の保存部の保存情報とを合成して作成される
ことを特徴とする請求項４記載の中継装置。
【請求項６】
前記データユニットを隣接する前記中継装置との間で定期的に送信し、前記第１の保存部に保存されるデータを作成する一方、
前記データユニットには、送信元の前記中継装置をルートとする前記ルートベクトルが記述され、
前記データユニットを隣接する前記中継装置との間で送受信することで前記ルートパスコストが最小の前記ルートパスベクトルを求める
ことを特徴とする請求項４または５記載の中継装置。
【請求項７】
前記第２の保存部に前記ＭＡＣアドレスの情報をエントリーする際には、該エントリーにフラグを立てる一方、
前記データユニットの送信時に前記第１データベースを探索した結果、前記フラグを発見すれば、
前記データユニットに前記エントリーの情報を追記して送信し、該送信後に前記フラグを下げる
ことを特徴とする請求項５または６記載の中継装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上の端末間の通信を中継する中継装置に関する。
【背景技術】
【０００２】
ＳＴＰ（Ｓｐａｎｎｉｎｇ  Ｔｒｅｅ  Ｐｒｏｔｏｃｏｌ）は、ＩＥＥＥ８０２．１Ｄで標準化されたプロトコルであって、ループ状（円環状）に冗長化されたレイヤ２（以下、Ｌ２とする。）ネットワークで使用される。
【０００３】
このＳＴＰを有効にしていないネットワークでは、ループ状に接続された各ノード（ブリッジ）の全ポートがフレーム転送できる状態となる。一方、ＳＴＰが有効なネットワークでは、ノードの任意のポートが自動的にブロッキング状態になって特定のリンクが閉鎖され、障害発生時にだけ前記ポートが自動的に有効化される。なお、特許文献１には、ＳＴＰのノードに使用されるスイッチングハブが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１７１４６８
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＳＴＰは、Ｌ２ネットワークにおける伝送経路の制御に多く使用されているものの、閉鎖されたリンクが伝送に貢献しないため、伝送経路に無駄が生じ、却って通信負荷が増加するおそれがある。特にデータセンタなどの帯域消費率の高いネットワークにて前記無駄が問題視されている。
【０００６】
図１に基づき一例を説明する。ここでは１２台のノード１〜１２がループ状に接続され、時計の時刻位置に合わせてノード番号が付されている。この場合にＳＴＰを有効にすればループ上の一箇所が閉鎖される。
【０００７】
ここでは６時−７時間、即ちノード６，７間のリンクが閉鎖されているため、端末Ａ，Ｂが互いに通信するためにはノード６−７間ではなく、ノード６−５−４−・・・９−８−７と遠回りしなければならない。
【０００８】
そのため、ノード６−７間のリンクを通ればそれ以外のリンクに通信負荷がかからないものの、前記遠回りにより全リンクに通信負荷がかかり、また通信量が多ければ通信負荷の悪影響も大きくなってしまう。
【０００９】
本発明は、このような従来の問題を解決するためになされ、冗長化ネットワークについて最短経路での通信を可能にすることで帯域を有効活用し、通信負荷を軽減することを解決課題としている。
【課題を解決するための手段】
【００１０】
（１）本発明は、冗長化されたネットワークにおいて端末間の通信を中継し、各端末への経路情報を格納する格納部を備えた中継装置であって、
前記経路情報には、前記各端末のＭＡＣアドレスと、
前記各端末を中継する中継装置をルートとしたルートパスベクトルと、
が対照に保持され、
前記経路情報に基づき前記端末間の通信を中継することを特徴とする。
【００１１】
（２）本発明の一態様は、前記ルートパスベクトルが複数存在すれば、前記ルートへのルートパスコストが最小の前記ルートパスベクトルを選択し、
前記ルートパスコストの最小の前記ルートベクトルが複数存在すれば、任意に一つを選択することを特徴とする。
【００１２】
（３）本発明の他の態様は、前記ルートに最も近いポートの番号が前記ＭＡＣアドレスおよび前記ルートパスベクトルに対応付けられていることを特徴とする。
【００１３】
（４）本発明のさらに他の態様は、前記ルートパスベクトルが記述されたプロトコルデータユニットを隣接する前記中継装置間で送受信することにより、前記ルートパスコストの最小の前記ルートパスベクトルが求められる。
【００１４】
（５）本発明のさらに他の態様は、前記データユニットの受信の有無に応じた前記ポート毎の識別情報と、前記ポートに接続された隣接する前記中継装置の情報とを対応付けて保存する第１の保存部と、
前記各中継装置の前記ポート毎に接続されている前記端末のＭＡＣアドレスを保存する第２の保存部と、
前記ルートパスベクトルが保存される第３の保存部と、をさらに備え、
前記第２の保存部の保存情報と第３保存部の保存情報とを作成する際には、前記第１の保存部の保存情報が参照される一方、
前記経路情報は、前記第２の保存部の保存情報と前記第３の保存部の保存情報とを合成して作成されることを特徴とする。
【００１５】
（６）本発明のさらに他の態様は、前記データユニットを隣接する前記中継装置との間で定期的に送信し、前記第１の保存部に保存されるデータを作成する一方、
前記データユニットには、送信元の前記中継装置をルートとする前記ルートベクトルが記述され、
前記データユニットを隣接する前記中継装置との間で送受信することで前記ルートパスコストが最小の前記ルートパスベクトルを求めることを特徴とする。
【００１６】
（７）本発明のさらに他の態様は、前記第２の保存部に前記ＭＡＣアドレスの情報をエントリーする際には、該エントリーにフラグを立てる一方、
前記データユニットの送信時に前記第１データベースを探索した結果、前記フラグを発見すれば、
前記データユニットに前記エントリーの情報を追記して送信し、該送信後に前記フラグを下げることを特徴とする。
【発明の効果】
【００１７】
本発明によれば、最短経路での通信を可能にするため、帯域が有効活用でき、通信負荷を軽減することができる。
【図面の簡単な説明】
【００１８】
【図１】ループ接続を示すネットワーク構成図。
【図２】本発明の実施形態に係るＲＴブリッジの構成図。
【図３】（ａ）はＲＴ−ＢＰＤＵのエンコード例を示すデータ構成図、（ｂ）は（ａ）のエンドホスト広告のデータ構成図。
【図４】（ａ）は前記エンドホスト広告へのホスト追加広告の実装例、（ｂ）は同ホスト削除広告の実装例。
【図５】（ａ）は前記エンドホスト広告へのハッシュ広告の実装例、（ｂ）は同ハッシュ広告要求の実装例。
【図６】前記ＲＴブリッジ群のネットワーク構成図。
【図７】前記ＲＴブリッジの処理手順を示すチャート図。
【発明を実施するための形態】
【００１９】
以下、本発明の実施形態に係る中継装置を説明する。ここでは本発明の中継装置は、ループ状に冗長化されたＬ２ネットワークに使用されるルータライクブリッジ（以下、ＲＴブリッジとする。）に適用されている。
【００２０】
≪構成例≫
（１）まず、図２に基づき前記ＲＴブリッジの構成例を説明する。ここで図２中の１−１，１−２は、前記ネットワーク上で互いに隣接する前記ＲＴブリッジ１を示している。
【００２１】
具体的には前記ＲＴブリッジ１は、スイッチングハブ（以下、スイッチとする。）であって、一般的なスイッチと同様にスイッチエンジン３，ＦＤＢ（Ｆｏｒｗａｒｄｉｎｇ  Ｄａｔａｂａｓｅ）４，ＬＡＮポートＰに加えてプロトコル処理などを行う中央処理装置（ＣＰＵなど）２を備える。ここでは一例としてＬＡＮポートＰを８ポート構成で示したが、ポート数は任意に定めることができる。
【００２２】
また、ＭＡＣ層における経路の制御のために、ＭＡＣＲＩＢ６，ルートパスベクトルＤＢ７，ＭＡＣサブネットＤＢ８，ネイバーテーブル９の各データを保有する。これらのデータは、中央処理装置２で実行されるプロトコルによって維持管理されている。
【００２３】
ここではＦＤＢ４にエントリー（ＭＡＣアドレスと転送ポート番号の組み合わせ）を注入し、保持させることをデータ処理の最終目標とする。このＦＤＢ４へのエントリーは、ＭＡＣＲＩＢ６の保持情報から取得する。
【００２４】
このＭＡＣＲＩＢ６の保持情報は、ルートパスベクトルＤＢ７の格納情報とＭＡＣサブネットＤＢ８の格納情報とから合成されている。また、ネイバーテーブル９は、ルートパスベクトルＤＢ７およびＭＡＣサブネットＤＢ８の格納情報の構築時に参照されている。
【００２５】
さらに前記経路の計算に必要な経路情報は、隣接ブリッジ１−１，１−２間でＲＴ−ＢＰＤＵ(プロトコルデータユニット)１０を交換し、いわゆるバケツリレー的にネットワーク内に伝搬させて取得する。なお、図２中では、ＲＴブリッジ１−１，１−２のみが表されているが、ＲＴブリッジ１の個数は二台に限定されず、ｎ個（ＲＴブリッジ１−１，１−２，１−３・・・１−ｎ）でよいものとする。
【００２６】
（２）つぎに図３〜図５に基づきＲＴ−ＢＰＤＵ１０の構成例を説明する。この図３（ａ）は、ＲＴ−ＢＰＤＵ１０のエンコード例を示している。このエンコード例中、プロトコルＩＤ〜バージョン長１まではＩＥＥＥ８０２．１Ｄの定義に示すデータ構造を示し、該データ構造の末尾に前記経路の計算のためのエンドホスト広告フィールドが付加されている。
【００２７】
このフィールドは、一つまたは複数のデータセットから構成されている。この個々のデータセットは、図３（ｂ）に示すように、少なくとも（Ａ）データタイプ，（Ｂ）データサイズ／個数，（Ｃ）データ本体（可変長）を備えている。このとき広告自体の有効性確認のため、エンドホスト広告の先頭には、広告全長および広告全体のＣＲＣ３２（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙｋ：巡回冗長検査）を付加する。ここではＣＲＣ３２と記すものとする。
【００２８】
図４（ａ）はエンドホスト広告フィールドへのホスト追加広告を示し、図４（ｂ）は同ホスト削除広告を示している。ここではデータタイプ「０３」がホスト追加を示し、同「０４」がホスト削除を示し、追加／削除されるホストのポートＩＤおよびＭＡＣアドレスが記述されている。
【００２９】
図５（ａ）はエンドホスト広告フィールドのハッシュ広告を示し、図５（ｂ）は同ホスト広告要求を示している。ここではデータタイプ「０１」がハッシュ広告を示し、同「０２」がホスト広告要求を示し、それぞれポートＩＤとＣＲＣ３２が記述されている。なお、図３〜図５の書式は、ＲＴ−ＢＰＤＵ１０の一例を示しているにすぎず、他の書式を用いてもよいものとする。
【００３０】
≪基本動作≫
前記ＲＴブリッジ１の基本動作を以下に列挙する。
【００３１】
（１）ＩＰアドレスではなく、ＭＡＣアドレスをベースにフォワーディングを実施する。
【００３２】
（２）ＦＤＢ４がＦＩＢテーブル、即ちパケットの転送先を扱うテーブルとして使用される。ここで通常のＦＩＢテーブルは、ルーティング情報ベース（以下、ＲＩＢと省略する。）、即ち個々のネットワークへの宛先への経路の一覧を保持するテーブル状のデータツリー型のデータ構造から作成されている。この点につき前記ＲＴブリッジ１のＦＤＢ４は、前述のようにＭＡＣＲＩＢ６から作成されている。
【００３３】
（３）フラッディング（受信したフレームを受信ポート以外の全ポートに転送する）を行わない。
【００３４】
（４）ＳＴＰのルートブリッジ選抜を実施せずに各ＲＴブリッジ１のルートパスを計算する。ここではルーティングプロトコル（ＲＩＰ）相当の経路計算を行う。
【００３５】
（５）ＳＴＰの閉鎖ポートを使用しない。
【００３６】
（６）ローカルホストディスカバリー（後述）によるローカル／リモートホストの識別をし、該識別結果をＭＡＣサブネットＤＢ８に格納する。
【００３７】
（７）ブロードキャストは、スパニングツリー経由での配信、またはＦＤＢ４のＲＰＦ（Ｒｅｖｅｒｓｅ  Ｐａｔｈ  Ｆｏｒｗａｒｄｉｎｇ）に頼ったフラッディングを行う。
【００３８】
≪従来型スイッチとの比較≫
（１）従来のＬ２スイッチの動作
Ａ：従来のＬ２スイッチは、基本的にフラッディングする。
Ｂ：ただし、ユニキャストフレームについては、その転送先ポートが判明していれば、そのポートだけに転送する。この転送動作を「スイッチング」と呼ぶ。
Ｃ：ユニキャストフレームの転送先は、受信フレームの送信元ＭＡＣアドレスと受信ポートとを対応付けてＭＡＣアドレステーブル（ＦＤＢ４に相当）に登録することで学習される（自律的に学習される。）。
Ｄ：ＭＡＣアドレステーブルには、前記自律的学習の一環として学習したエントリーがエージング（寿命管理）される。すなわち、一度学習したとしても、後続のフレームが来なくなってから所定の時間が来たらエントリーを削除する処理が行わる。
【００３９】
（２）前記ＲＴブリッジ１の動作
ａ：前記ＲＴブリッジ１は、基本的にフラッディングを行わない。すなわち、転送先を学習していないユニキャストフレームは、ＬＡＮポートＰに転送せずに中央処理装置２のみに転送する。
ｂ：転送先がＦＤＢ４に学習されているユニキャストフレームは、従来型と同様にスイッチエンジン３によってスイッチングする。
ｃ：ユニキャストフレームの転送先は、ローカルホストディスカバリーの処理にて学習し、ＦＤＢ４による自立学習は禁止されている。
ｄ：ＦＤＢ４による自立学習が禁止されているため、そのエントリーのエージングはされない。
【００４０】
≪動作の詳細≫
以下、前記ＲＴブリッジ１の動作を詳述する。ここでは図６のネットワーク構成に基づき動作処理（処理ステップ）を説明するものとする。
【００４１】
図６中のＲＴブリッジ１〜２３は、それぞれ冗長化されたＬ２ネットワークに接続された前記ＲＴブリッジ１を示し、端末１０１〜１０４，１２１〜１２５間の通信を中継している。
【００４２】
また、１６桁の１６進数値「８０００：ＸＸＸＸＸＸ００００２１」〜「８０００：ＸＸＸＸＸＸ００００２５」は、前記ＲＴブリッジ１のブリッジＩＤを示し、小さい数値が高優先に設定されている。このブリッジＩＤの下位６バイトは、ＭＡＣアドレスを示し、該ＭＡＣアドレスの上位３バイト「ＸＸＸＸＸＸ」の値は、メーカのＯＵＩ（固有の識別番号）を示している。
【００４３】
（１）前記ＲＴブリッジ１の起動時
前記ＲＴブリッジ１の起動時、即ち初期状態を以下に列挙する。
Ａ：ＦＤＢ４には自身のエントリーのみが登録されている。
Ｂ：ＭＡＣＲＩＢ６，ルートパスベクトルＤＢ７，ＭＡＣサブネットＤＢ８，ネイバーテーブル９には何も記録・格納されていない。
Ｃ：宛先不明のユニキャストフレームをフラッディングすることなく、中央処理装置２に転送する（この設定は変更されない。）。
Ｄ：ブロードキャストフレームをフラッディングしない（初期状態では中央処理装置２のみ受信する。）。
Ｅ：ソース（送信元）ＭＡＣアドレスを学習していないフレームを中央処理装置２に転送する（この設定は変更されない。）
Ｆ：ＦＤＢ４は、アドレス学習を自律的に行わない（この設定は変更されない。）。
Ｇ：ＦＤＢ４は、アドレスのエージングを実行しない（この設定は変更されない。）
（２）ＦＤＢ４のエントリーの手順
図７に基づきＦＤＢ４のエントリーの手順（ステップ）を説明する。まず、ネイバーディスカバリー（Ｓ０１）により、隣接ＲＴブリッジ１の存在確認が実行される。このネイバーディスカバリーの結果は、ネイバーテーブル９に記録される。
【００４４】
つぎにネイバーテーブル９の記録情報を参照してローカルホストディスカバリー（Ｓ０２）が実行され、ホスト情報が探索される。ここで得られたホスト情報は、経路広告（Ｓ０３）に便乗してネットワーク内に頒布され、前記各ＲＴブリッジ１のＭＡＣサブネットＤＢ８が構成される（Ｓ０４）。
【００４５】
その後、前記経路広告＆計算（Ｓ０３）の結果を貯蔵することでルートパスベクトルＤＢ７が構成される（Ｓ０５）。この両データベース７，８の合成によりＭＡＣＲＩＢ６が得られる（Ｓ０６）。
【００４６】
このＭＡＣＲＩＢ６からＦＤＢ４のエントリーが得られてＦＤＢ４が設定される（Ｓ０７）。このＦＤＢ４の経路情報に基づき前記ＲＴブリッジ１は、端末間の通信を中継する。以下、各手順を説明する。
【００４７】
（３）ネイバーディスカバリー
まず、ネイバーディスカバリー（Ｓ０１）の詳細を説明する。すなわち、前記ＲＴブリッジ１は、すべての動作に先だってネイバーの存在を検出する。ここでネイバーとは、自身に直結された隣接の前記ＲＴブリッジ１と定義する。
【００４８】
このネイバー検出のため、ＲＴブリッジ１はすべてのＬＡＮポートＰからＲＴ−ＢＰＤＵ１０を定期的に送出する。このＲＴ−ＢＰＤＵ１０には、常に自身をルートとするルートパスベクトルを記述する。この点で自身よりも優先度の高いブリッジＩＤを検出すれば、自身をルートとするルートパスベクトルを広告しなくなる仕様の通常のＳＴＰと相違する。
【００４９】
つぎに隣接の前記ＲＴブリッジ１側では、ＲＴ−ＢＰＤＵ１０を受信したＬＡＮポートＰを「トランジットポート」とし、それ以外のＬＡＮポートＰを「エッジポート」として識別する。
【００５０】
また、ＲＴブリッジ１は、ネイバーからの「ＲＴ−ＢＰＤＵ１０」を受信した場合、即ちルートパスコスト＝１」の「ＲＴ−ＢＰＤＵ１０」を受信した場合には、該受信したＬＡＮポートＰの番号の欄に「ＲＴ−ＢＰＤＵ１０」に記述されたブリッジＩＤをネイバーテーブル９に登録する。
【００５１】
表１〜表５は、図６のネットワーク構成においてネイバーディスカバリー後の状態を示している。具体的には表１は前記ネイバーディスカバリー実施後の前記ＲＴブリッジ２１のネイバーテーブル９を示し、表２は同前記ＲＴブリッジ２２のネイバーテーブル９を示し、表３は同前記ＲＴブリッジ２３のネイバーテーブル９を示し、表４は同前記ＲＴブリッジ２４のネイバーテーブル９を示し、表５は同前記ＲＴブリッジ２５のネイバーテーブルを示している。
【００５２】
【表１】
2020010102.tif 000003
【００５３】
【表２】
2020010102.tif 000004
【００５４】
【表３】
2020010102.tif 000005
【００５５】
【表４】
2020010102.tif 000006
【００５６】
【表５】
2020010102.tif 000007
【００５７】
表１〜表５によれば、ＬＡＮポート番号毎に「トランジットポート／エッジポート」の識別と、ネイバーのブリッジＩＤとがネイバーテーブル９に登録されて保存されている。ここではＬＡＮポート番号「１〜３」のみが表されているが、ＬＡＮポート番号「４〜８」も同様に登録されるものとする。また、ネイバーのブリッジＩＤを、優先度を示す上位２バイトのみで省略しているが、実際には１６進数値のブリッジＩＤがネイバーテーブル９に記述される。
【００５８】
（４）ローカルホストディスカバリー
前記ＲＴブリッジ１は、ＬＡＮポートＰで受信するイーサネット（登録商標）フレームの送信元ＭＡＣアドレスを監視し、該ＭＡＣアドレスが未知のアドレスであればＭＡＣサブネットＤＢ８に登録する。この処理をローカルディスカバリー（Ｓ０２）と呼ぶ。
【００５９】
詳細を説明すれば、未知の送信元ＭＡＣアドレスのイーサネット（登録商標）フレームがＬＡＮポートＰに到着した場合にはスイッチエンジン３によって中央処理装置２に転送される（この機能は現代的なスイッチエンジン３であれば備わっている。）。
【００６０】
この転送を受けた中央処理装置２は、未知のＭＡＣアドレスを受信したＬＡＮポートＰの識別情報（表１〜５のエッジポート／トランジットポート）に応じてＭＡＣサブネットＤＢ８に登録する。以下、未知のＭＡＣアドレスＸ，受信ＬＡＮポートＰ１として処理内容を説明する。
【００６１】
（Ａ）受信ＬＡＮポートＰ１がエッジポートの場合
ＭＡＣサブネットＤＢ８のエントリーは、「ブリッジＩＤ：接続ポート」の形式で識別されている。ここで受信ＬＡＮポートＰ１が、エッジポートの場合にＭＡＣサブネットＤＢ８に「ブリッジＩＤ：ローカルポートＰ１」のエントリーが無ければ作成し、同エントリーに未知のＭＡＣアドレスＸを関連付ける。このように登録されたホストを「ローカルホスト」と呼ぶ。
【００６２】
（Ｂ）受信ＬＡＮポートＰ１がトランジットポートの場合
受信ＬＡＮポートＰ１が、トランジットポートの場合にＭＡＣサブネットＤＢ８に「ブリッジＩＤ：トランジットポートＰ１」のエントリーが無ければ作成し、同エントリーに未知のＭＡＣアドレスＸを関連付ける。このように登録されたホストを「トランジットホスト」と呼ぶ。
【００６３】
このトランジットポートで受信したフレームが実際には他の前記ＲＴブリッジ１を経由して転送されてきた場合、トランジットホストとしての登録は実態に即しておらず、誤りになる。しかし、ＲＴ−ＢＰＤＵ１０による経路広告においてローカルホスト広告をトランジット広告よりも高優先とすることにより自然に正しい登録に修正される。
【００６４】
表６〜表１０は、図６のネットワーク構成においてローカルディスカバリー実施後の状態を示している。具体的には表６は前記ローカルディスカバリー実施後の前記ＲＴブリッジ２１のＭＡＣサブネットＤＢ８を示し、表７は同前記ＲＴブリッジ２２のＭＡＣサブネットＤＢ８を示し、表８は同前記ＲＴブリッジ２３のＭＡＣサブネットＤＢ８を示し、表９は同前記ＲＴブリッジ２４のＭＡＣサブネットＤＢ８を示し、表１０は同前記ＲＴブリッジ２５のＭＡＣサブネットＤＢ８を示している。
【００６５】
【表６】
2020010102.tif 000008
【００６６】
【表７】
2020010102.tif 000009
【００６７】
【表８】
2020010102.tif 000010
【００６８】
【表９】
2020010102.tif 000011
【００６９】
【表１０】
2020010102.tif 000012
【００７０】
表６〜表１０では、「ブリッジＩＤ：接続ポート」を単位に未知のＭＡＣアドレスが登録されている。ただし、ローカルホストディスカバリー実施後の段階では、前記ＲＴブリッジ１は自身の発見したホストだけしかＭＡＣサブネットＤＢ８に登録されていない。
【００７１】
なお、後述するエンドホスト広告の処理により他の前記ＲＴブリッジ１で学習されたエントリーが前記各ＲＴブリッジ１に頒布される。これにより最終的にはネットワーク内の前記全ＲＴブリッジ１が、同じ内容のＭＡＣサブネットＤＢ８を保有する。
【００７２】
（５）経路広告＆計算
前述のように前記ＲＴブリッジ１は、ＬＡＮポートＰのすべてのポート（番号１〜５）からＲＴ−ＢＰＤＵ１０を定期的に送信する。
【００７３】
このときネイバーディスカバリー（Ｓ０１）においてはＲＴ−ＢＰＤＵ１０の送受信はネイバーの存在確認を目的とする。一方、ＲＴ−ＢＰＤＵ１０は、経路情報の頒布を主な役割とする。このＲＴ−ＢＰＤＵ１０の経路情報の頒布、即ち経路広告（Ｓ０３）の側面を説明する。
【００７４】
図３（ａ）に示したように、ＲＴ−ＢＰＤＵ１０の大半はＩＥＥＥ８０２．１Ｄの定めるＣＦＧ-ＢＰＤＵ，ＲＳＴ−ＢＰＤＵと同じ定義からなる。このフィールドには、「ルートパスベクトル」と呼ばれる距離ベクトル（距離情報）が記述される。これをネイバーとの間で授受しながらＳＴＰのスパニングツリーアルゴリズムを実行すると、ルートブリッジへの最短経路（ルートパスコストを最小とする経路）が求められる。
【００７５】
ただし、ＳＴＰでは、ブリッジＩＤの最小のブリッジ（最優先ブリッジ）がルートブリッジとして選択される。このルートブリッジへの最短経路のみが計算され、余剰なリンクをすべて閉鎖することでネットワーク内の閉路を撲滅する。
【００７６】
これに対して前記ＲＴブリッジ１においては、最優先ブリッジの選定を行わず、ネットワーク内のすべてのＲＴブリッジ１をそれぞれルートブリッジとみなし、個別にスパニングツリーアルゴリズムを実行し、さらにＲＴ−ＢＰＤＵ１０によりルートパスベクトル頒布を行う。これはＲＩＰなどにおける距離ベクトル型経路計算に相当する。
【００７７】
その結果、通常のＳＴＰでは各ブリッジが保持するルートパスベクトルは一つだけであるのに対して、前記各ＲＴブリッジ１ではＮ個のルートパスベクトルを保持する。ここでは「Ｎ≧ネットワーク内の前記ＲＴブリッジ１の台数」が成立している。ただし、マルチパスが全くない場合には「Ｎ＝ネットワーク内の前記ＲＴブリッジ１の台数」となる。
【００７８】
このとき一つのルートパスベクトルは、あるブリッジへの方向を指し示している。すなわち、「ルートポート」というパラメータで転送先ポートが求まるため、ネットワーク内のすべての前記ＲＴブリッジ１のルートパスベクトルを保有するということは、ネットワーク内のすべての前記ＲＴブリッジへの方向を把握できたことを意味する。
【００７９】
そして、最終的にはルートパスベクトル（Ｎ個）とＭＡＣサブネットＤＢ８の登録内容とを使って、エンドホストのＭＡＣアドレスの転送先をＦＤＢ４に登録する。ここでは主に経路広告の処理動作を中心に説明する。
【００８０】
（Ａ）エッジポートにおけるＲＴ−ＢＰＤＵ１０の送信
エッジポートの先にはネイバーが接続されていなく経路広告は不要なものの、後から前記ＲＴブリッジ１が接続される場合がある。そこで、自身のＲＴブリッジ１の存在アピールのため、定期的にＲＴ−ＢＰＤＵ１０を送信する。
【００８１】
ただし、エッジポートからは、そのＲＴブリッジ１０をルートとするルートベクトルを記述したＲＴ−ＢＰＤＵ１０のみを送信し、他の前記ＲＴブリッジ１をルートとするルートベクトルを記述されたＲＴ−ＢＰＤＵ１０を送信しないものとする。また、エッジポートから送信するＲＴ−ＢＰＤＵ１０には、エンドホスト広告を付加しないものとする。
【００８２】
（Ｂ）トランジットポートにおけるＲＴ−ＢＰＤＵ１０の送信
前記ＲＴブリッジ１は、自身をルートとするルートパスベクトルを記述したＲＴ−ＢＰＤＵ１０を定期的に送信する。ただし、すべてのホストを毎回広告することは負荷が大きく、また１個のＲＴ−ＢＰＤＵ１０にすべてを記述できないケースもある。そこで、エンドホスト広告への掲載は、エントリーの変更発生時に限定する。この送信モードを便宜的に「起点送信」と呼ぶ。
【００８３】
また、前記ＲＴブリッジ１は、他のＲＴブリッジ１をルートとするルートパスベクトルを記述したＲＴ−ＢＰＤＵ１０をネイバーから受信したときにスパニングツリーアルゴリズムを実行してルートパスベクトルを計算する。この計算結果をＲＴ−ＢＰＤＵ１０に記述してリーフ方向のネイバーに送信する。この送信モードを便宜的に「中継送信」と呼ぶ。
【００８４】
（Ｃ）ＲＴ−ＢＰＤＵ１０に付加するエンドホスト広告
ＲＴ−ＢＰＤＵ１０に図３（ｂ）のエンドホスト広告を付加（添付）する手法について説明する。
【００８５】
まず、ＲＴ−ＢＰＤＵ１０にエンドホスト広告を付加することができるのは、前述のように起点送信の場合に限られている。一方、中継送信の場合には、そのＲＴ−ＢＰＤＵ１０に起点送信した前記ＲＴブリッジ１のホスト広告が添付され、この状態のまま改変せずにネイバーに中継しなければならない。
【００８６】
つぎに前述のようにエンドホスト広告は、ローカルホストディスカバリー（Ｓ０２）によってホストの増減が生じた場合に限り添付される。すなわち、前記ＲＴブリッジ１がローカルホストディスカバリー（Ｓ０２）でホストを検出した場合、そのホスト（端末）のＭＡＣアドレスをＭＡＣサブネットＤＢ８に登録し、その登録のエントリーに「要広告フラグ」を立てる。
【００８７】
また、前記ＲＴブリッジ１は、次にＲＴ−ＢＰＤＵ１０を送信する際、ＭＡＣサブネットＤＢ８に要広告フラグが立っているエントリーを探索する。ここで要広告フラグが立っているエントリーを発見した場合には、該エントリーをエンドホスト広告フィールドに追記し、該エントリーの要広告フラグを取り下げる。このように前記ＲＴブリッジ１によれば、ホスト検出時／ホスト失踪時にだけエンドホスト広告フィールドにホスト広告（例えば図４（ａ）（ｂ））を追記することで帯域の消費の抑制を図っている。
【００８８】
ただし、ＲＴＢＰＤＵ１０がロスしたり、あるいは後から前記ＲＴブリッジ１が系に参入するなどエンドホスト広告を受け取れない前記ＲＴブリッジ１が生じる場合がある。そこで、前記ＲＴブリッジ１では、ホスト広告のハッシュ値によって同期させる手法を導入されている。
【００８９】
すなわち、起点送信するＲＴ−ＢＰＤＵ１０のエンドホスト広告フィールドに自身の前記ＲＴブリッジ１が広告している「ハッシュ広告（図５（ａ））」を掲載する。ここでのハッシュ値は、広告しているホストのＭＡＣアドレスを昇順にソートし、そのＣＲＣ３２を計算した値とする。
【００９０】
このときホスト広告の受け手側の前記ＲＴブリッジ１においても、広告されたＭＡＣアドレスのハッシュ値を算出し、送り手側の前記ＲＴブリッジ１の広告しているハッシュ値と比較することで同期を確認する。確認の結果、ハッシュ値が一致していれば同期がとれており、これ以上は何もしなくてよい。一方、ハッシュ値が不一致であれば同期を取りなおす必要がある。
【００９１】
このハッシュ値の不一致を確認検出した前記ＲＴブリッジ１は、そのホスト広告をいったんすべて破棄する。その後、次回のＲＴ−ＢＰＤＵ１０を起点送信する際にエンドホスト広告フィールドに「ホスト広告要求（図５（ｂ））」を掲載する。ここでＲＴ−ＢＰＤＵ１０は、ネットワーク内のすべての前記ＲＴブリッジ１が受信するので、該当する前記ＲＴブリッジが必ず受け取ることとなる。
【００９２】
このホスト広告要求を受け取った該当の前記ＲＴブリッジは、ＭＡＣサブネットＤＢ８に登録している自身のローカルホストおよびトランジットホストの全エントリーの要広告フラグを立てる。これにより該当の前記ＲＴブリッジ１が、次回にＲＴ−ＢＰＤＵ１０を起点送信する際にホスト広告が掲載される。
【００９３】
ここでホスト数が多すぎて一度にエンドホスト広告フィールドに掲載できない場合には、複数回の起点送信に分散してホスト広告を掲載し、ネットワーク上に頒布（拡散）させることができる。このホスト広告を受け取った前記ＲＴブリッジ１は、ホスト広告要求後は該当の前記ＲＴブリッジからのホスト広告が尽きるまで次のホスト広告要求を発行できないものとする。
【００９４】
なお、接続ポートがローカルポートの場合には、ポート番号の値は他の前記ＲＴブリッジ１にとって不要である。なぜならば他の前記ＲＴブリッジ１にとってはそのエンドホストがラストホップＲＴブリッジ１のどのポートに接続していても転送先が分からないからである。
【００９５】
そうすると処理負荷軽減のためには、むしろローカルポートのポートＩＤでホスト広告を分別しない方がよい。分別すると、その度にハッシュ同期が必要となり、無駄に負荷を高めることになる。この点につき前記ＲＴブリッジ１は、ローカルポートのポートＩＤによるホスト広告の分別は行わず、ローカルポートを表す疑似的なポート番号として「２５５（０ｘＦＦ）」を使用する。この疑似的なポートＩＤを広告することにより、ローカルポートの相違によるホスト広告の分別を回避している。
【００９６】
（６）ＭＡＣサブネットＤＢ８の構成
前述のようにローカルホストディスカバリー（Ｓ０２）で検出されたエンドホストは、ＲＴ−ＢＰＤＵ１０の末尾にエンドホスト広告（図３（ａ）（ｂ））の形式で付加掲載されて、ネットワーク内に頒布される。
【００９７】
このときＲＴ−ＢＰＤＵ１０を受信した前記ＲＴブリッジ１は、その末尾に付加掲載されたエンドホスト広告を参照し、自身にとって不知のエントリー変更を発見すれば自身のＭＡＣサブネットＤＢ８に追記／削除を施す。また、広告されたハッシュ値の不一致を確認検出した場合には、同期するためのホスト広告要求（図５（ｂ））を行うことも前述のとおりである。
【００９８】
このような処理を進めていけば、最終的にはホスト広告がネットワーク内に行き渡り、すべての前記ＲＴブリッジ１が同内容のＭＡＣサブネットＤＢ８を保持することとなる。
【００９９】
【表１１】
2020010102.tif 000013
【０１００】
表１１は、図６のネットワーク構成においてエンドホスト広告が収束した後のＭＡＣサブネットＤＢ８の保存内容を示している。ここでは「ブリッジＩＤ：接続ポート」を単位にエンドホストのＭＡＣアドレスが登録されて保存されている。
【０１０１】
（７）ルートパスベクトルＤＢ構成
前記各ＲＴブリッジ１は、前述のようにネットワーク内のすべての前記ＲＴブリッジ１についてルートパスベクトルを個別に計算する。ここで計算されたルートパスベクトルは、ＭＡＣＲＩＢ６を構成する際に使用されるため、常時参照可能にしなければならない。このルートパスベクトルの計算結果、即ち経路計算の結果に基づきルートパスベクトルＤＢ７が構成される（Ｓ０５）。
【０１０２】
表１２〜１６は、図６のネットワーク構成において経路計算収束後の状態を示している。具体的には表１２は前記経路計算収縮後の前記ＲＴブリッジ２１のルートパスベクトルＤＢ７を示し、表１３は同前記ＲＴブリッジ２２のルートパスベクトルＤＢ７を示し、表１４は同前記ＲＴブリッジ２３のルートパスベクトルＤＢ７を示し、表１５は同前記ＲＴブリッジ２４のルートパスベクトルＤＢ７を示し、表１６は同前記ＲＴブリッジ２５のＭＡＣサブネットＤＢ８を示している。
【０１０３】
【表１２】
2020010102.tif 000014
【０１０４】
【表１３】
2020010102.tif 000015
【０１０５】
【表１４】
2020010102.tif 000016
【０１０６】
【表１５】
2020010102.tif 000017
【０１０７】
【表１６】
2020010102.tif 000018
【０１０８】
表１２〜表１６では、便宜上、ルートパスベクトルのうちルートブリッジＩＤ，ルートパスコスト，代表ブリッジＩＤ，ルートポートのみを表記した。
【０１０９】
このルートブリッジＩＤには前記ＲＴブリッジ２１〜２５のブリッジＩＤが記録され、ルートパスコストには前記ＲＴブリッジ２１〜２５をルートブリッジとみなしたルートパスコストが記録され、代表ブリッジＩＤには該ルートブリッジまでの経路を代表する代表ブリッジＩＤが記録され、ルートポートには自身から前記ルートブリッジまで最短のＬＡＮポート番号を示すルートポートが記録されている。
【０１１０】
このブリッジＩＤは１６進数値を表記するとイメージし難いので名称表記とし、また簡易性のためすべてのポートパスコストを「１」とした。なお、ルートパスベクトルＤＢ７の保存情報は、前記各要素に限定されるものではなく、図３（ａ）に示すルートベクトルの他の要素も同様に記録できる。
【０１１１】
（８）ＭＡＣＲＩＢの合成
ルートパスベクトルＤＢ７には、前記各ＲＴブリッジ１が計算したすべてのルートパスベクトルが保存されている。したがって、ルートパスベクトルＤＢ７を参照すれば、ネットワーク内のすべての前記ＲＴブリッジ１への転送先ポートを知ることができる。また、ＭＡＣサブネットＤＢ８を参照すれば、ＭＡＣサブネットとそこに接続されたエンドホストを知ることができる。
【０１１２】
もっとも、ルートパスベクトルＤＢ７・ＭＡＣサブネットＤＢ８をそれぞれ単体で参照しただけでは、個々のエンドホストとその転送先ポートを得ることができない。そこで、経路情報としてＦＤＢ４にエントリーするため、ＭＡＣアドレスと転送先ポートの番号とを対照に保持するテーブルをＭＡＣＲＩＢ６として作成する。
【０１１３】
このＭＡＣＲＩＢ６では、ＭＡＣアドレスとルートパスベクトルとのペアで一つのエントリーを構成している。このルートパスベクトルに含まれるルートポートというパラメータが転送先を指し示し、ＭＡＣアドレスと転送先ポートとを対応付けることが可能となる。
【０１１４】
具体的にＭＡＣＲＩＢ６の合成は、以下の手順で行う。
（Ａ）ＭＡＣサブネットＤＢ８からエンドホストをすべて列挙する。
（Ｂ）前記手順（Ａ）で列挙されたエンドホストに対応するＭＡＣサブネット（ブリッジＩＤ：接続ポート）を列挙する。
（Ｃ）ＭＡＣサブネットのブリッジＩＤをルートとするルートパスベクトルをルートパスベクトルＤＢ７から読み出し、前記手順（Ａ）（Ｂ）の列挙情報と対応付ける。
（Ｄ）前記手順（Ｃ）にてＭＡＣアドレスとルートパスベクトルが「１：１」のエントリーの合成が完了する。ここで両者が「１：多」になった場合にはルートパスコストが最小のルートパスベクトルを選択するものとする。また、ルートパスコストが最小のルートパスベクトルが複数ある場合には、そのうちいずれかを選択するものとする。
【０１１５】
前記手順（Ａ）〜（Ｄ）のうち、手順（Ａ）（Ｂ）まではすべての前記ＲＴブリッジ１で同じ結果となる。一方、手順（Ｃ）以降は、前記ＲＴブリッジ１毎に異なる結果となる。なお、表１７〜表２１は、図６のネットとワーク構成における手順（Ａ）〜（Ｄ）の実行結果を示している。
【０１１６】
【表１７】
2020010102.tif 000019
【０１１７】
表１７は、前記手順（Ａ）（Ｂ）を実行した後の「ＭＡＣアドレスとＭＡＣサブネットとの対照表」を示し、すべての前記ＲＴブリッジ２１〜２５で同じ結果が得られる。
【０１１８】
【表１８】
2020010102.tif 000020
【０１１９】
表１８は、前記ＲＴブリッジ２１において前記手順（Ｃ）（Ｄ）を実施後の「ＭＡＣアドレスとルートパスベクトルとの対照表」を示している。この表１８によれば、ＭＡＣアドレス「端末１０１〜１０４」には複数のルートパスベクトルが対応している。
【０１２０】
【表１９】
2020010102.tif 000021
【０１２１】
表１９は、表１８の「ＭＡＣアドレスとルートパスベクトルとの対照表」をルートパスコストで絞り込んだ状態を示し、網掛け欄が脱落したルートパスベクトルを示している。
【０１２２】
これによりＭＡＣアドレス「端末１０３」以外については、すべて「１：１」に絞り込まれた。一方、ＭＡＣアドレス「端末１０３」の複数のルートパスベクトルは、等コストマルチパス（イコールコストマルチパス）なので、どちらを選択してもよい。
【０１２３】
この場合、ＳＴＰではブリッジＩＤの小さい方を選好するが、前記ＲＴブリッジ１ではそうする必要はない。むしろＭＡＣアドレスに何らかのハッシュ計算を施して選択を分散させれば、容易に負荷分散を実現できる。
【０１２４】
【表２０】
2020010102.tif 000022
【０１２５】
表２０は、表１９中のＭＡＣアドレス「端末１０３」について前記ＲＴブリッジ２２のルートベクトルを選択した状態を示し、前記ＲＴブリッジ２３に網掛けが追加されている。これによりすべてのＭＡＣアドレスについてルートパスベクトルが「１：１」に絞り込まれた。
【０１２６】
【表２１】
2020010102.tif 000023
【０１２７】
表２１は、表２０中から脱落したルートベクトル（網掛け欄）を除去し、ルートポートを別カラムで表示した状態を示している。ただし、自身に直結のホスト（ローカルホスト／トランジットホスト）の接続ポートは、ＭＡＣサブネットＤＢ８から読み出すものとする（自身をルートとするルートパスベクトルにはルートポートは含まれない）。このＭＡＣサブネットＤＢ８から読み出した接続ポートについては表２１中に「※」を付記した。
【０１２８】
（９）ＦＤＢ４の設定
表２１に示すようにＭＡＣＲＩＢ６の合成が完了すれば、ＭＡＣアドレスと転送先ポートとの関係が得られる。これをＦＤＢ４に反映（コピー）すれば、スイッチエンジン３がスイッチングし、エンドホスト間での通信が実現する。これにより以下の効果を得ることができる。
【０１２９】
（Ａ）閉鎖ポート無しでのフレームの閉路無限巡回を防止することができる。この点で帯域を有効活用することができる。また、フラッディングを使用しないため、帯域消費を防止することもできる。
【０１３０】
（Ｂ）どのエンドホスト間でも最短経路でフレームがスイッチングされ、ループ状の冗長化ネットワークの通信において無駄な遠回りが防止される。この点で帯域消費の防止および伝送遅延の低減などの効果が得られる。
【０１３１】
（Ｃ）表１９および表２０に示すように、等コストマルチパスのルートパスベクトルが存在する場合に任意のハッシュ計算等で経路分散が可能である。この点で通信負荷を分散することができる。
【０１３２】
（Ｄ）ネイバーテーブル９およびルートパスベクトルＤＢ７を参照することでＲＴブリッジ１の接続構成を容易に把握することができる。この点でメンテナンス性の向上などに貢献できる。
【０１３３】
（Ｅ）エンドホストの存在をプロトコル管理でき、この点でもメンテナンスおよびセキュリティ性が向上する。なお、タグ付けカプセル化なしにつきＭＴＵの問題が発生しなく、またスイッチエンジン３の機能異存が低い。この点でコストを低減できる（特殊な機能を持つチップは一般に効果）。
【符号の説明】
【０１３４】
１，２１〜２５…ＲＴブリッジ（中継装置）
２…中央処理装置
３…スイッチエンジン
４…ＦＤＢ（格納部）
６…ＭＡＣＲＩＢ（格納情報）
７…ルートパスベクトルＤＢ（第３の保存部）
８…ＭＡＣサブネットＤＢ（第２の保存部）
９…ネイバーテーブル（第１の保存部）
１０…ＲＴ−ＢＰＤＵ（プロトコルデータユニット）
１０１〜１０４，１２１〜１２５…端末
【図１】
2020010102.tif 000024
【図２】
2020010102.tif 000025
【図３】
2020010102.tif 000026
【図４】
2020010102.tif 000027
【図５】
2020010102.tif 000028
【図６】
2020010102.tif 000029
【図７】
2020010102.tif 000030