特許 6042549 コンピュータネットワークを稼働する方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6042549

(24)【登録日】2016年11月18日

(45)【発行日】2016年12月14日

(54)【発明の名称】コンピュータネットワークを稼働する方法

(51)【国際特許分類】

   H04L 12/437 20060101AFI20161206BHJP

   H04L 12/705 20130101ALI20161206BHJP

【ＦＩ】

   H04L12/437 S

   H04L12/705

【請求項の数】17

【全頁数】9

(21)【出願番号】特願2015-532308(P2015-532308)

(86)(22)【出願日】2012年9月19日

(65)【公表番号】特表2015-534758(P2015-534758A)

(43)【公表日】2015年12月3日

(86)【国際出願番号】EP2012068416

(87)【国際公開番号】WO2014044303

(87)【国際公開日】20140327

【審査請求日】2015年5月18日

(73)【特許権者】

【識別番号】390023711

【氏名又は名称】ローベルト ボツシユ ゲゼルシヤフト ミツト ベシユレンクテル ハフツング

【氏名又は名称原語表記】ＲＯＢＥＲＴ ＢＯＳＣＨ ＧＭＢＨ

(74)【代理人】

【識別番号】100114890

【弁理士】

【氏名又は名称】アインゼル・フェリックス＝ラインハルト

(74)【代理人】

【識別番号】100099483

【弁理士】

【氏名又は名称】久野 琢也

(72)【発明者】

【氏名】マルク スマーク

(72)【発明者】

【氏名】マルセル フェルステーク

(72)【発明者】

【氏名】トム デ ブラウヴァー

(72)【発明者】

【氏名】ステファン ファン ティーネン

【審査官】 速水 雄太

(56)【参考文献】

【文献】 米国特許出願公開第２００７／０１５９９８８（ＵＳ，Ａ１）

【文献】 特開平１１−０１７７２４（ＪＰ，Ａ）

【文献】 特表２０１０−５２５６９３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／４３７

Ｈ０４Ｌ １２／７０５

(57)【特許請求の範囲】

【請求項1】

第１のイーサネットブリッジ（３４）および第２のイーサネットブリッジ（３６）と、前記第１のイーサネットブリッジ（３４）と前記第２のイーサネットブリッジ（３６）との間にデイジーチェーン接続されたループに配置された複数のデバイス（３２）とを備えているコンピュータネットワーク（３０）を稼働するための方法であって、
前記各デバイス（３２）は、少なくとも３つのポートを有するブリッジを備えており、前記コンピュータネットワーク（３０）の稼働中には、前記各デバイス（３２）は、ループを回避するために異なる状態をとり、リブートする場合には、前記複数のデバイス（３２）のうちの少なくとも１つのデバイスの前記ポートは、現在のポートの状態を維持する、方法において、
前記第１のイーサネットブリッジ（３４）または前記第２のイーサネットブリッジ（３６）は、前記複数のデバイス（３２）のうちのいずれのデバイスもルートブリッジとならないように、前記複数のデバイス（３２）のうちのいずれのデバイスよりも低い優先度を有するように構成されている、方法。

【請求項2】

前記デバイス（３２）がフォワーディング状態にある、請求項１記載の方法。

【請求項3】

前記デバイス（３２）がディスカーディング状態にある、請求項１記載の方法。

【請求項4】

前記デバイス（３２）は、ネットワークトポロジの変更メッセージを受信した後、直ちに、前記ポートの状態をアップデートする、請求項１から３のいずれか一項記載の方法。

【請求項5】

前記複数のデバイス（３２）は、ｚ秒ごとに、該複数のデバイスが存在することを互いに通知し、ｚは、前記デバイスのブート時間の１／２に相当する、請求項１から４のいずれか一項記載の方法。

【請求項6】

前記複数のデバイス（３２）は、ハロータイムをｘ秒に設定するように構成され、ｘは、リブートの後に、ラピッドスパニングツリープロトコル（ＲＳＴＰ）を立ち上げて、稼働させるために要する最長時間ｙから計算され、ｘ＞ｙ／２である、請求項１から５のいずれか一項記載の方法。

【請求項7】

前記複数のデバイス（３２）は、ハロータイムをｘ秒に設定するように構成され、ｘは、リブートの後に、ラピッドスパニングツリープロトコル（ＲＳＴＰ）を立ち上げて、稼働させるために要する最長時間ｙから計算され、ｘ＞ｙ／３である、請求項１から５のいずれか一項記載の方法。

【請求項8】

第１のイーサネットブリッジ（３４）および第２のイーサネットブリッジ（３６）と、前記第１のイーサネットブリッジ（３４）と前記第２のイーサネットブリッジ（３６）との間にデイジーチェーン接続されたループに配置された複数のデバイス（３２）とを備えているコンピュータネットワークであって、
前記各デバイス（３２）は、少なくとも３つのポートを有するブリッジを備えており、前記コンピュータネットワーク（３０）の稼働中には、前記各デバイス（３２）は、ループを回避するために異なる状態をとり、リブートする場合には、前記複数のデバイス（３２）のうちの少なくとも１つのデバイスの前記ポートは、現在のポートの状態を維持する、コンピュータネットワークにおいて、
前記第１のイーサネットブリッジ（３４）または前記第２のイーサネットブリッジ（３６）は、前記複数のデバイス（３２）のうちのいずれのデバイスもルートブリッジとならないように、前記複数のデバイス（３２）のうちのいずれのデバイスよりも低い優先度を有するように構成されている、コンピュータネットワーク。

【請求項9】

前記デバイス（３２）がフォワーディング状態にある、請求項８記載のコンピュータネットワーク。

【請求項10】

前記デバイス（３２）がディスカーディング状態にある、請求項８記載のコンピュータネットワーク。

【請求項11】

前記デバイス（３２）は、ネットワークトポロジの変更メッセージを受信した後、直ちに、前記ポートの状態をアップデートする、請求項８から１０のいずれか一項記載のコンピュータネットワーク。

【請求項12】

前記複数のデバイス（３２）は、ｚ秒ごとに、該複数のデバイスが存在することを互いに通知し、ｚは、前記デバイスのブート時間の１／２に相当する、請求項８から１１のいずれか一項記載のコンピュータネットワーク。

【請求項13】

前記複数のデバイス（３２）は、ハロータイムをｘ秒に設定するように構成され、ｘは、リブートの後に、ラピッドスパニングツリープロトコル（ＲＳＴＰ）を立ち上げて、稼働させるために要する最長時間ｙから計算され、ｘ＞ｙ／２である、請求項８から１２のいずれか一項記載のコンピュータネットワーク。

【請求項14】

前記複数のデバイス（３２）は、ハロータイムをｘ秒に設定するように構成され、ｘは、リブートの後に、ラピッドスパニングツリープロトコル（ＲＳＴＰ）を立ち上げて、稼働させるために要する最長時間ｙから計算され、ｘ＞ｙ／３である、請求項８から１２のいずれか一項記載のコンピュータネットワーク。

【請求項15】

前記コンピュータネットワーク（３０）がイーサネットネットワーク（１０）である、請求項８から１４のいずれか一項記載のコンピュータネットワーク。

【請求項16】

前記複数のデバイス（３２）がオーディオネットワークのエンドデバイスである、請求項８から１５のいずれか一項記載のコンピュータネットワーク。

【請求項17】

前記各デバイス（３２）が、ループを回避するために、任意の収束に反応することを保証するメカニズムを有する、請求項８から１６のいずれか一項記載のコンピュータネットワーク。

【発明の詳細な説明】

【技術分野】

【0001】

技術分野
本発明は、コンピュータネットワークを稼働する方法、特に、デイジーチェーン接続された安定したイーサネットループを開発する方法と、このようなループを提供するための構成とを提供する。さらに、本発明は、このようなコンピュータネットワークを提供する。

【背景技術】

【0002】

背景技術
コンピュータネットワークは、通信チャネルによって相互接続された複数のコンピュータと他のコンポーネントとの集合である。これらのチャネルは、リソースおよび情報を共有することを可能にする。コンピュータネットワークは、使用される媒体、通信プロトコル、スケール、トポロジ、および、組織的範囲などの種々の特徴に従って分類される。

【0003】

国際公開第ＷＯ２０１０／０８８９６５Ａ１号公報（特許文献１）は、ストリームを受信および送信するための複数のポートをそれぞれが有している複数のブリッジを備えているコンピュータネットワークを使用する方法を示している。ストリームは、関心を示したブリッジのポートを介して、ルータから少なくとも１つの受信機に送信され、ここで、リンク障害が起きている場合には、少なくとも１つの受信機は、メッセージをルータに送り返す。この方法は、いわゆるイーサネットネットワークにおいて使用される。

【0004】

イーサネットネットワークは、ローカルエリアネットワークのための、フレームベースのコンピュータネットワークである。イーサネットネットワークは、複数のループを処理できないことに留意されたい。ループが形成された場合、そのループを介して、パケットが連続的に通信される。標準的なプロトコルは、ループを検出し、そのループの両端部を分離するように開発される。ネットワークトポロジが変化したとき、ネットワークの接続されていない部分または新たなループの形成を回避するために、検出が再開される。

【0005】

ループは、通常、イーサネットブリッジを用いて、ケーブルおよび設備の冗長部に形成される。デバイスは、通常、ブリッジにスター配線される。

【0006】

ループが検出されるまでにはいくぶん時間を要する。パケットを循環させることによるネットワークの過負荷を回避するために、ループ検出プロトコルにおけるデフォルト状態には、リンクがない。このことは、ネットワークトポロジが正しく検出されるまで通信が行われないことを意味している。公知の最良のプロトコルは、スパニングツリープロトコルおよびラピッドスパニングツリープロトコルである。

【0007】

スパニングツリープロトコル（ＳＴＰ）は、ブリッジイーサネットネットワークのためのループフリーなトポロジを保証するネットワークプロトコルである。ＳＴＰは、ブリッジループおよびブロードキャストラジエーション（ｂｒｏａｄｃａｓｔ ｒａｄｉａｔｉｏｎ）を防ぐように適合されている。このために、ＳＴＰは、２つのブリッジレイヤが接続された（例えば、イーサネットブリッジ）メッシュネットワーク内にスパニングツリーを形成し、スパニングツリーの一部分ではないリンクを無効にして、任意の２つのネットワークノード間の単一のアクティブパスを分離する。

【0008】

ラピッドスパニングツリープロトコル（ＲＳＴＰ）は、トポロジ変化後の有意に速いスパニングツリー収束を提供し、新たな収束挙動およびブリッジポートルールを導入する。

【0009】

物理的リンク障害の場合、ＳＴＰは、新たなネットワークトポロジの再形成に３０秒を超える時間を要し、ＲＳＴＰは２秒以下を要する。

【0010】

オーディオネットワークは、そのエンドデバイスのためのデイジーチェーン接続の解決法を必要とする。これは、少なくとも３つのポートを有するイーサネットブリッジを各デバイスに追加することによって、標準的なやり方で解決される。典型的に、オーディオネットワークにおいて、デイジーチェーン接続されているデバイスの数は多いと特定されている（例えば、２０個）。冗長部は、オーディオネットワークの重要な特徴である。結果として、２０個のデバイスのチェーンでループを形成することが可能である。オーディオネットワーク内の各デバイスはエンドデバイス（例えば、ラウドスピーカ）である。

【0011】

デイジーチェーンは、複数のデバイスが、順序良く、または、１つの輪になるように一緒に配線される配線方式である。ネットワークデバイスは、各々、１つの上流ポートと、１つの下流ポートとを含み、各ポートはケーブルに結合されている。各デバイスの３番目のポートは、ネットワークからトラフィックを受信し、そのネットワークへトラフィックを送信するように構成されている。

【0012】

欧州特許出願公開第ＥＰ１７２０２９３Ａ１号公報（特許文献２）は、デイジーチェーンのローカルエリアネットワーク内に冗長部を提供する方法を示している。この方法は、各ネットワークデバイス内に単一の受動経路を形成するステップと、通常使用されるカテゴリー５のツイストテッドペアケーブルに関連付けられた上流ポートのピンを、通常使用されないカテゴリー５のツイステッドペアケーブルに関連付けられた下流ポートのピンと接続するステップと、ターミナルネットワークデバイスにおいてループバック接続を形成するステップと、ローカルエリアネットワークを介して、単一の能動経路を定義するために、ネットワークデバイスのそれぞれにおいて、スパニングツリープロトコルを実行するステップとを含む。

【先行技術文献】

【特許文献】

【0013】

【特許文献1】国際公開第ＷＯ２０１０／０８８９６５Ａ１号公報

【特許文献2】欧州特許出願公開第ＥＰ１７２０２９３Ａ１号公報

【発明の概要】

【課題を解決するための手段】

【0014】

発明の開示
本発明によれば、請求項１に記載の方法は、コンピュータネットワーク、特にイーサネットネットワークを稼働する方法であり、このコンピュータネットワークは、デイジーチェーン接続された安定したループに配置された複数のデバイスを備えている。各デバイスは、少なくとも３つのポートを有するブリッジを備えている。第３のポートは、このコンピュータネットワークからトラフィックを受信し、トラフィックをコンピュータネットワークに送信するように構成されている。

【0015】

各デバイスのポートは、コンピュータネットワークの稼働中、異なるポート状態（例えば、フォワーディング状態およびディスカーディング状態）をとる。リブート中、デバイスは、ＲＳＴＰを稼働させないことがあることに留意されたい。この期間の間、リブート前のポート状態を維持する。リブート前にはデバイスが正しい状態であったと想定される。デバイスのブリッジは、ＲＳＴＰステートマシンが再び稼働するまで、この状態に維持される。このことは、リブート中には、ブリッジが、リセットも再初期化もされないことを意味している。それ故、通信経路は、リブート中には中断されない。

【0016】

ブリッジ間の通信に対しては、いわゆるブリッジプロトコルが使用される。プロトコルのパケットは、ブリッジプロトコルデータユニット（ＢＰＤＵ）である。各ブリッジが十分な情報を有することを保証するために、ＢＰＤＵが使用される。ブリッジは、ポート自体の固有のＭＡＣアドレスをソースアドレスとして使用することによってＢＰＤＵフレームを送信する。

【0017】

ＲＳＴＰポート状態は以下のとおりである。
ディスカーディング：ユーザデータは送信されず、ＢＰＤＵ以外で受信されたデータは放棄される。受信されたＢＰＤＵは処理される。
ラーニング：ポートが、入ってくるデータのソースアドレスを学習する。
フォワーディング：ポートがデータを送受信する。
ディセーブルド：ネットワーク管理者によって実行可能である。

【図面の簡単な説明】

【0018】

【図1】図１は、冗長なループを有する複数のブリッジを備えているイーサネットネットワークである。

【図2】図２は、デイジーチェーン接続された安定したループに配置された複数のオーディオネットワークデバイスである。

【図3】図３は、ハロータイムのタイムアウトを示すＢＰＤＵを描く図である。

【発明を実施するための形態】

【0019】

上述した特徴および以下で説明される特徴は、本発明の範囲から逸脱することなしに、具体的に特定された組み合わせだけでなく、他の組み合わせにおいて、または、単独で使用され得ることが理解される。

【0020】

本発明は、例として、実施形態を用いて、図面に、概略的に図示され、以下で図面を参照しながら詳細に説明される。以下の説明は、本発明の範囲を如何様にも制限するものではなく、本発明の実施形態の単なる例示であることが理解される。

【0021】

実施形態の説明
図１は、冗長なループを有する複数のブリッジを備えているイーサネットネットワーク１０を示している。イーサネットネットワーク１０は、通信チャネル２４で接続されている、ブリッジＡ １２、ブリッジＢ １４、ブリッジＣ １６、ブリッジＤ １８、ブリッジＥ ２０、および、ブリッジＦ ２２を備えている。示されたネットワーク１０もまた複数のループを備えている。

【0022】

ループが検出されるまでにはいくぶん時間を要する。パケットを循環させることによるネットワークの過負荷を回避するために、ループ検出プロトコルにおけるデフォルト状態には、リンクが存在しない。このことは、ネットワークトポロジが正しく検出されるまで、通信が行われないことを意味している。もっとも良く知られているプロトコルは、スパニングツリープロトコルおよびラピッドスパニングツリープロトコルである。ＳＴＰは、ネットワークトポロジを再形成するために３０秒を超える時間を要し、ＲＳＴＰは、２秒未満でこれを行う。

【0023】

図２は、コンピュータネットワーク３０（この場合は、オーディオネットワーク）を示しており、このコンピュータネットワーク３０は、ＲＳＴＰをサポートする第１のイーサネットブリッジ３４と第２のイーサネットブリッジ３６との間にデイジーチェーン接続されたループに配置された複数のデバイス３２を備えている。各デバイス３２は、３つのポートを有するブリッジを備えている。

【0024】

デバイス３２内のブリッジは、ＲＳＴＰをサポートする必要がない。しかしながら、デバイスがＲＳＴＰをサポートしていない場合、ネットワークが完全に構成されるまでに数十秒を要する。複数のデバイス３２のうちの任意のデバイス間のケーブルが中断されている場合、ネットワークが再構成されるまで、典型的には、再び、ハロータイムの３倍の時間を要する。リトライメカニズムが適切な位置に存在しないので、音声は通信損失を非常に受けやすい。このことは、音声の損失が、ネットワーク再構成時間と等価であることを意味する。

【0025】

ブリッジ３４および３６はルートブリッジになり得る。デバイス３２内のブリッジ３２はルートブリッジになり得ない。ルートブリッジが故障した場合、新たなルートブリッジが選ばれるまでに最長６秒を要する。それ故、デバイス３２内のブリッジは、ルートブリッジにならない。ルートブリッジは、常に、最低の優先度を有するブリッジである。ブリッジの優先度は、ルートブリッジになることを防ぐために、デフォルト状態よりも明確に高くなるように設定される。

【0026】

各デバイス３２内でＲＳＴＰアルゴリズムを稼働することによって、ネットワーク再構成時間が、１秒未満に低減される。このことは、問題点の多くを解決するが、時々、デバイスはリブートする、または、ファームウェアアップデートモードにスイッチする。これらの状況においては、ＲＳＴＰアルゴリズムが再び安定状態になるまでに約１６秒を要する。

【0027】

この過程で、ネットワークトポロジは通常、変更されないので、結果として、リブート前の状態が依然として有効である。このことは、トポロジの変更、および、その結果として、音声およびデータの中断を回避する。

【0028】

ループを回避するために、デバイスは、常に、ブロックされているイーサネットポートで開始する。ＲＳＴＰメッセージの通信後にのみ、ポートは、フォワーディング状態になる。デバイスが電力損失なしでリブートする場合、ポート状態はおそらく正しいままである。それ故、ＲＳＴＰアルゴリズムが完全に立ち上がり、再度稼働するまで、この状態が永続的に維持される。ＲＳＴＰアルゴリズムが立ち上がり、稼働するまで、リブートデバイスは、ＢＰＤＵを送信しない。もう１つのデバイスが、この間に、トポロジ変更を検出することを回避するために、デフォルト状態のＢＰＤＵのハロータイムは、デフォルト状態の２秒からｘ秒（例えば、１０秒）まで増加される。

【0029】

ＲＳＴＰを立ち上げ、稼働させるために要する時間がｙであり、ハロータイムがｘである場合、以下の制約が保持されなければならない：リセットされる前に、デバイスに、ハローＢＰＤＵを送信させない場合、ｙ≦２ｘであり、リセットされる前に、デバイスに、ハローＢＰＤＵを送信させる場合、ｙ≦３ｘである。デバイスが、ＲＳＴＰを終了させ、稼働するために約１６秒を要するので、９秒のハロータイムが目下使用される。

【0030】

デバイス３２は、互いにその存在をｚ秒ごとに通知し、ここで、ｚは、デバイスのブート時間の１／２に相当する。さらに、各デバイス３２は、ループを回避するために任意の収束に反応することを保証するメカニズムを有している。

【0031】

図３は、イーサネットネットワーク内の通信を例示する図を示している。参照数字５０は、ＲＳＴＰをサポートするイーサネットブリッジを表し、参照数字５２は、本発明に従う方法をサポートするデバイスを表す。細い破線／点線は、ＢＰＤＵの交換を示している。太い二重線と二重破線との間で、デバイスがリブートする。実線は、デバイスのリブートに起因して送信されないＢＰＤＵを示している。左側の表示１０は、１０秒を表す。双方向矢印５４は、１５秒を表す。

【0032】

ハロータイムは、ブリッジから送信されたＢＰＤＵ間の時間間隔である。これは、もう１つのブリッジに「ｈｅｌｌｏ Ｉ ａｍ ｈｅｒｅ」を通知するために使用される。３つのＢＰＤＵを逃した場合、１０秒のハロータイムであれば３０秒を要しており、もう１つのブリッジがディスカーディングモードに再び切り替わる。ハロータイムは、ネットワークが収束した後にのみ使用される。フォワーディング状態のポートは、ハロータイムの秒数毎にＢＰＤＵを送信し、ディスカーディング状態のポートが、ハロータイムの秒数毎に入ってくるＢＰＤＵを予測する。このことは、ネットワークが依然として収束していることを意味している。

【0033】

ＲＳＴＰの仕様によれば、デバイスが３つのＢＰＤＵを逃した場合、デバイスは、トポロジ変更を発する。最悪のケースのシナリオでは、リブートデバイスがリブートするときに、ＢＰＤＵを送信するところだったことである。このことは、ＲＳＴＰが、リブート後に、ハロータイムの２倍の秒数以内に立ち上がり、稼働しなければならないことを意味する。代替的に、デバイスは、リブートが通常のように計画されてから初めてリブートするときにＢＰＤＵを送信する。このことは、リブート時間を、ハロータイムの秒数の３倍まで増加させる。

【0034】

デバイスのブートアップ後、ＲＳＴＰのステートマシンが開始される。最初に、ステートマシンが、全てのポートをディスカーディング状態にし、その後、ラーニング状態にする。ブートデバイスの近傍のデバイスがリセットされていない場合には、近傍のデバイスがブートデバイスによって送信されたＢＰＤＵに素早く反応する。ブートデバイスのポートは、その後、速やかにフォワーディング状態に移行する。

【0035】

しかしながら、近傍のデバイスもまた、リセットされていて、起動される場合には、近傍のデバイスが応答するまでより長い時間を要する。ポートがより長い期間ラーニング状態に留まり、正規のトラフィックは依然としてラーニング状態では転送されないため、このことは、チェーンの中断を引き起こす。この問題を解決するために、フォワーディング状態にあったポートは、ＲＳＴＰアルゴリズムが、これらのポートがディスカーディング状態またはラーニング状態になるべきであることを示す場合でさえも、フォワーディング状態に維持される。このルールに対する唯一の例外は、トポロジ変更ＢＰＤＵがポートで受信された、すなわち、近傍のデバイスが新たなネットワーク収束を開始した場合だけである。この場合、実際のＲＳＴＰポート状態が、トポロジ変更の肯定応答が戻される前に、ポートに推し進められる。結果として、ループが妨害される。

【0036】

デバイスがリブートするときにトポロジ変更が存在する場合には、ルートブリッジが、ループを壊すことが依然として可能である。しかしながら、このことは、数１０秒の通信損失をもたらす。（ルート）イーサネットブリッジもまた、このｘ秒のハロータイムを有するように構成されていることが重要である。

【図1】

【図2】

【図3】