JP2003526277A

JP2003526277A - デュアル・モードによる仮想ネットワーク・アドレス指定方式

Info

Publication number: JP2003526277A
Application number: JP2001565582A
Authority: JP
Inventors: シー．ファン，ジェイソン; ピー．ジョガレカール，プラサド; ケー．バンナイ，ビナイ
Original assignee: ルミナスネットワークスインコーポレイテッド
Priority date: 2000-03-03
Filing date: 2001-03-02
Publication date: 2003-09-02
Also published as: ATE466445T1; AU2001245435A1; EP1445919B1; CN1437809A; EP1262038A2; EP1445919A3; DE60141987D1; US6717956B1; CA2401907A1; EP1445919A2; WO2001067676A3; WO2001067676A2

Abstract

(57)【要約】所定の仮想ネットワーク・トポロジの内側にあるソースまたは宛先を持つトラフィック用として、標準的なアドレス（ロング・アドレスと呼ばれる）の代わりに、縮減された長さのアドレス（ショート・アドレスと呼ばれる）を使用するデュアル・アドレス指定モードについて説明する。所定の仮想トポロジ用として使用されるショート・アドレスの求められる長さはトポロジ内で着信可能なデバイス数によって決められる。例えば、２５６個未満のアドレス可能なデバイスを備えた仮想トポロジの場合、８ビットのショート・アドレスを使用することができる。仮想ネットワーク内のノードは、パケットがヘッダ内に短い宛先アドレスを持っていることを知ると、そのアドレスが仮想ネットワーク内に在ることを理解し、それに応じてパケットの経路指定を行う。ソース・アドレスがショート・アドレスである場合、仮想ネットワークは仮想ネットワーク内でソースの特定を行うことができる。やはり仮想ネットワーク内に在る宛先を持つ、仮想ネットワーク内で発信されたパケットの場合、ソース・アドレスと宛先アドレスの双方をショート・アドレスとすることが可能である。このようにして、仮想ネットワーク・トポロジの内側のトラフィック・フロー、または、私設仮想ネットワークのトラフィック・フローにより、仮想ネットワーク・トポロジ内のデバイスのアドレス指定がデータ・リンク層および／またはネットワーク層上でデュアルな方法で可能となる。また、仮想ネットワーク内でソース・アドレスをデバイスに自動的に割り当てる技術についても説明する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は通信ネットワークに関し、特に、オーバーヘッドを縮減するためのネ
ットワーク用アドレス指定方式に関する。

【０００２】

【従来の技術】

アクセス・ネットワーク及びロング・ホール・ネットワークにおけるデータ輸
送容量はサービス・プロバイダにとって商品性（billable）のある商品である。
従来のネットワークは、これらのネットワーク内のデータ・リンク層及びネット
ワーク層デバイスに対して、３２ビット・インターネット・プロトコル（ＩＰ）
アドレスやギガビット・イーサネット（登録商標）内の４８ビット媒体アクセス
制御（ＭＡＣ）アドレスのような単一の静的アドレス指定モードを採用してきた
。ロング・アドレスを採用するモチベーションとして、世界中のすべてのネット
ワークを介してつながっているあらゆるデバイスに対して一意的データ・リンク
層アドレスおよび／またはネットワーク層アドレスの割り当てが可能となるとい
う点が挙げられる。この割当て方式によって、アドレスの２重化によるコンフリ
クトを伴うことなく、最少の管理上のオーバーヘッドでデバイスの十分な携帯性
が可能になる。しかし、これらのアドレスは、ネットワーク層やデータ・リンク
層でパケットに追加される、パケット・ヘッダのオーバーヘッドの大きな部分（
ギガビット・イーサネットの場合ほぼ６０％、また、ＩＰの場合ほぼ４０％）を
占めている。これらのアドレスの圧縮によりこのオーバーヘッドをいくらかでも
縮減すれば、このようなネットワークのデータ輸送容量が増えることになる。

【０００３】音声とデータとが統合化されたネットワーク・データ通信網では、ＩＰデータ
・パケットの平均的サイズはほぼ２５０バイトであり、パケットの５０％以上は
６４バイトにすぎない。サーキット・エミュレーションによる音声パケットの平
均的サイズ（１５０バイトを仮定）は、パケット化による遅延を最小限にするた
めにＩＰパケットの平均的サイズよりも通常小さくなっている。ＭＡＣ層アドレ
ス指定の１２バイトは、パケット・サイズ全体のかなりの部分（データの４％、
音声の７％）を占める。したがって、このアドレス指定をいくらかでも圧縮する
ことにより、イーサネット様ＭＡＣ層を用いる、実現されたアクセス・ネットワ
ークとロング・ホール・ネットワークの大幅な改善が得られることになる。この
圧縮により、このようなネットワークを所有するサービス・プロバイダの商品性
のある（billable）容量が直接追加されることになる。

【０００４】トポロジに対するネットワークの特定は、デュアル・モードによるアドレス指
定に関して本明細書で説明する発明に関連する。トポロジの再構成シナリオには
、ネットワークの初期化、デバイスの挿入、デバイスの削除、リンクが一対のデ
バイスを接続するリンク・ブレイクのような、デバイスの挿入や削除を伴わない
トポロジの変更、及び、動作中のネットワークの結合が含まれる。本明細書の文
脈では、ネットワークの初期化とは、デバイス自身を初期化するための、各デバ
イスが独立に利用する内部処理を意味するのではなく、ネットワーク・トポロジ
についての知識の確立に必要な相互接続デバイス間の通信と、ショート・アドレ
スのロング・アドレスへの再マッピングとを意味している。

【０００５】トポロジの再構成に利用するメカニズムが満たすべきいくつかの基本的な要件
が存在する。１．再構成を行っているネットワークの乱されていないデバイス間で現在進行中
のトラフィックは、そのようなトラフィック用として利用可能な複数のパスが存
在すると仮定してフローを継続すること。この再構成が、トラフィックのフロー
が行われる物理的ルートの一時的除去を伴う場合には、ＳＯＮＥＴベースの回線
のような標準的な保護切替えメカニズムや、パス切替えや、あるいはパケット交
換ネットワーク用の他のメカニズムを利用して、ノード間の、影響を受けていな
い物理的ルートへのトラフィックの一時的経路指定が行われる。２．このメカニズムはプラグ・アンド・プレイであること。例えばトポロジの変
更の決定は自動的に行われ、ネットワーク管理システムからの干渉を必要としな
いこと。３．デバイス間の通信メカニズムは、所定のデバイスによるトポロジの変更情報
の検出を可能にし、この情報を仮想ネットワーク上のすべての他のデバイスへ伝
播するようにすること。標準的トポロジ発見メカニズムを利用したり、他のメカ
ニズムを利用したりしてこの伝播を行うことができる。メカニズムの選択は個々
の仮想ネットワークの固有の要件に基づくことになる。

【０００６】ネットワーク内の各デバイスは、自分の隣接デバイスに関する、他のデバイス
からの受信情報に基づいてネットワーク・トポロジ自身のバージョンを構成し、
格納するという意味で、現在の多くのトポロジ発見メカニズムは配信される。上
記情報は本明細書では隣接状態メッセージと呼ばれる。このようなメカニズムの
好適な例として、ＯＳＰＦルーティング・プロトコルで使用されるトポロジの変
更を放送するためのリンク状態プロトコルがある。このリンク状態プロトコルに
ついてはRadia Perlman＆Addison Wesley著“相互接続、第２版”（ロングマン
社、２０００年刊）という文献に記載がある。本文献はその全体が本明細書に参
考文献として取り入れられている。このリンク状態プロトコルは、上記著者らが
知っている配信されたトポロジ発見プロトコルと共に、トポロジ情報と、メッセ
ージのソースへ戻されるトポロジ・メッセージを受信するデバイスから送られる
確認応答メッセージとからなる最新のものではないメカニズムとを利用する信頼
性の高い配信とに依拠する。

【０００７】最新のものではないメカニズムの利用とは、いずれかのデバイスに格納された
トポロジが構成可能な期間後に無効になることを意味する。このことは、たとえ
トポロジの切替えが生じなくてもネットワーク内のすべてのデバイスは隣接状態
メッセージの周期的送信を必要とすることを意味する。この周期的送信を必要性
は、各デバイスでの処理とネットワーク帯域の双方の点から見て非効率的である
。なぜならば、ネットワーク・トポロジの切替えは頻繁には生じないからである
。したがって、各デバイスがそのトポロジを最新のものではないものにする必要
性を取り除くメカニズムが有益なものとなる。

【０００８】各デバイスにおける、受信した確認応答メッセージの追跡による隣接状態メッ
セージの信頼性の高い配信を利用することにより、すべての伝送された隣接状態
メッセージの受信が保証され、したがってすべてのデバイスが正しいネットワー
ク・トポロジを構成する標準的アプローチであることが保証される。しかしなが
ら、デバイスのスイッチのオン／オフのような過渡的シナリオが残り、その結果
、デバイスの中には必ずしもすべてのメッセージが受信されないデバイスが生じ
、そのため、不正確なネットワーク・トポロジが構成されて、この不正確なネッ
トワーク・トポロジがネットワーク上の他のデバイスから見えなくなるという結
果を生じる可能性がある。パケット交換型データ・ネットワークでは、従来、信
頼性の高いサービスが行われる保証はなかった。したがって、各デバイスにおけ
る有効なネットワーク・トポロジの構成を保証する追加メカニズムが求められる
こともなかった。しかしながら、パケット交換ネットワークを介してＤＳ１また
はＤＳ３専用回線で遠距離通信用品質の音声をトランスポートするためには、非
常に高い信頼性が求められる。したがって、各デバイスにおいて構成されるトポ
ロジの有効性を検証するメカニズムが有用となる。

【０００９】デュアル・モードによるアドレス指定を使用するネットワーク内でトポロジを
再構成するための確定されたメカニズムは現在存在しない。デュアル・モードに
よるアドレス指定というコンセプトが、Jason Fanらによる“デュアル・モード
による仮想ネットワーク・アドレス指定”という表題の同時継続出願に記載され
ている。上記同時継続出願は本譲受人へ譲受されたものであり、本明細書に参考
文献として取り入れられている。このタイプのネットワークが必要とするものは
以下のようなメカニズムである。１．トポロジの再構成を可能にし、上述の一般的トポロジの再構成要件を満たす
ものであること。２．再構成により必要とされるデュアル・アドレス指定モード間の切替えに起因
して生じる、管理情報と制御情報（デバイス内部の供給用テーブルとルーティン
グ・テーブルなど）に対する変更を最小限にする（好適には必要としない）もの
であること。３．複数のネットワークが一体として結合されるとき、ショート・アドレスの２
重化が生じることがないことを保証するなどの、再構成の一部としてショート・
アドレスの再設定を可能にするものであること。

【００１０】

【発明が解決しようとする課題】

所定の仮想ネットワーク・トポロジの内側にあるソースまたは宛先を持つトラ
フィック用として、標準的なアドレス（ロング・アドレスと呼ばれる）の代わり
に、縮減された長さのアドレス（ショート・アドレスと呼ばれる）を使用するデ
ュアル・アドレス指定モードについて説明する。ロング・アドレスは地球的規模
で一意的なものであるが、これに対して、ショート・アドレスは、所定の仮想ネ
ットワークに対してローカルに一意的なものである。所定の仮想トポロジ用とし
て使用されるショート・アドレスの求められる長さはトポロジ内で着信可能なデ
バイス数によって決められる。例えば、２５６個未満のアドレス可能なデバイス
を備えた仮想トポロジの場合、８ビットのショート・アドレスを使用することが
できる。

【００１１】仮想ネットワーク内のノードは、パケットがヘッダ内に短い宛先アドレスを持
っていることを知ると、そのアドレスが仮想ネットワーク内に在ることを理解し
、それに応じてパケットの経路指定を行う。ノードは、トラフィックがリングを
出入りすることができるポイントとして確定される。ソース・アドレスがショー
ト・アドレスである場合、仮想ネットワークは仮想ネットワーク内でソースの特
定を行うことができる。やはり仮想ネットワーク内に在る宛先を持つ、仮想ネッ
トワーク内で発信されたパケットの場合、ソース・アドレスと宛先アドレスの双
方をショート・アドレスとすることが可能である。

【００１２】

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

ネットワークの外部とも接続された仮想ネットワーク内のノードは、オプショ
ンとして、ロング・ソース・アドレスと宛先アドレスとを持つパケットをネット
ワークの外部から受信し、ルックアップ・テーブルのメモリ内の宛先ノードの対
応するショート・アドレスを調べることもできる。次いで、ノードはロング・ア
ドレスをショート・アドレスに置き換え、仮想ネットワーク内の宛先ノードへパ
ケットの転送を行う。同様に、ネットワークの外側へパケットを伝送する仮想ネ
ットワーク内のノードは、仮想ネットワーク内でトラフィックの経路指定を行い
ながら、短いソース・アドレスを使用することが可能である。このようにして、
仮想ネットワーク・トポロジの内側のトラフィック・フロー、または、私設仮想
ネットワークのトラフィック・フローにより、仮想ネットワーク・トポロジ内の
デバイスのアドレス指定がデータ・リンク層および／またはネットワーク層上で
デュアルな方法で可能となる。

【００１３】本発明により、ギガビット・イーサネット様ＭＡＣヘッダの場合、ほぼ５０％
のオーバーヘッドの縮減、また、ＩＰヘッダの場合、３０％のオーバーヘッドの
縮減が結果として得られる。圧縮されたＭＡＣヘッダを使用することにより、例
えば、ＩＰパケットを運ぶイーサネット・ベースの大都市圏リングの場合、４％
のデータ輸送容量の平均的増加という結果が得られる。

【００１４】パケット・ヘッダ内のアドレス・タイプ・フィールドによって、送信装置と受
信装置により識別されるデュアル・アドレス・フォーマットが可能になり、それ
によって、パケットからパケットへ双方のフォーマットを交換可能にロバストな
方法で利用することが可能となる。

【００１５】また、ネットワーク内でのトポロジの変更を検出し、仮想ネットワーク内でソ
ース・アドレスをデバイスに自動的に割り当てる技術についても説明する。

【００１６】

【発明の実施の形態】

本明細書に記載の発明は、確定された仮想ネットワーク・トポロジ内のデバイ
スのための、適応性のあるデュアル・アドレス指定メカニズムを提供するもので
ある。仮想ネットワーク内の上記デバイスは、長短アドレスの変換メカニズムを
備えたルート指定用デバイス／多重デバイスであってもよい。長短アドレスの変
換メカニズムを備えたルート指定用デバイスまたは１組のルート指定用デバイス
によって外部の世界から隔離されているという意味で仮想ネットワーク全体は私
設のものであってもよい。したがって、“仮想ネットワーク”という用語は、例
えば、大都市圏の光ファイバ・リングや企業用ルータの背後に隔離されている私
企業のネットワークのノードにも同様に適用することも可能である。仮想ネット
ワークは、オプションとして、（残りの世界には不可視の）私設アドレス指定を
利用することが可能となる。例えば、このようなアドレスを含む固有ヘッダの使
用は、仮想ネットワーク内での利用に限定することができる。

【００１７】さらに、本明細書に記載の発明は、信頼性が高い一般的トポロジの発見メカニ
ズム（仮想ネットワークに固有のものではない）であって、変化が生じなければ
トポロジの再度の発見を行う必要のない一般的トポロジの発見メカニズムを提供
するものである。このメカニズムは、ネットワーク上で送信されるすべての隣接
状態メッセージでネットワーク内のデバイスが設けるセッションＩＤを利用する
ものである。すべてのデバイスは現在のセッション番号を格納し、ネットワーク
から受信するメッセージで使用されるセッション番号に基づいてこのセッション
番号の更新を行う。例えば近傍の状態情報の変化を検出するいずれのデバイスも
、その格納されたセッション番号を増分し、伝送された隣接状態メッセージの中
でその番号を使用する。増分されたセッション番号の検出は、トポロジの発見の
新しいラウンドが開始した旨をネットワーク上の他のデバイスへ信号で知らせる
。またこのメカニズムでは、無効トポロジの構成に対して保護を行うトポロジ検
証アルゴリズムが利用される。この検証が失敗しても、ノードに現在格納されて
いる有効なトポロジが乱される（perturbed）ことはない。このことは、遠距離
通信用のグレードの専用回線接続が不必要に衝撃を受けないことを保証するため
に非常に重要なことである。

【００１８】さらに本明細書に記載の発明は、トポロジの再構成シナリオにおけるデュアル
・モードによるネットワーク・アドレスの管理と割当てを行うためのメカニズム
を提供する。

【００１９】２つのタイプの仮想ネットワークの例が図１に示されている。大都市圏の光フ
ァイバ・リングあるいはさらに一般的には、高速ルート指定用デバイス／多重（
Ｒ／Ｍ）デバイスの相互接続を行う仮想ネットワーク２０が、ルート指定用デバ
イスの背後に隔離された私設仮想ネットワーク２１、２２と共に示されている。
私設仮想ネットワーク２１、２２はルート指定能力を備えたノードからなるリン
グであってもよい。３つの仮想ネットワーク２０〜２２は本発明を適用するため
の候補となる仮想ネットワークである。

【００２０】ネットワーク２０内のノード２４と２５はオープンな公衆インターネット２６
と２７とそれぞれ接続されている。インターネット２６と２７は大きな、絶えず
変化している、多数の独立したかつ多様なモジュールから構成されているため、
インターネット２６と２７は本発明にとって好適な候補ではない。

【００２１】単一の仮想ネットワーク２０〜２２内で通されるパケットは、圧縮されたアド
レス指定（ショート・アドレス）を用いてアドレス指定を行い、データ運搬効率
を上げることができる。仮想ネットワーク２０〜２２を出るパケットは自分の仮
想ネットワーク（短い）アドレスを取り除かれるか、外部で有効な（長い）アド
レスと置き換えられることになる。大都市圏の光ファイバ・リングの結合のよう
な仮想ネットワークの再構成が行われる場合、仮想ネットワーク内のデバイスは
、このようなネットワークの管理と再構成を容易にするために、ショート・アド
レスとロング・アドレスの双方を同時に理解できる必要がある。

【００２２】デュアル・アドレス指定仮想ネットワーク内の各デバイスに対してデュアル・アドレス指定を行う目的
は、このようなデバイス間を通過するトラフィック用のパケット・ヘッダのオー
バーヘッドのオプションの縮減を可能にすることである。具体的に述べると、仮
想ネットワーク内のノードは、或る条件下では或るクラスのトラフィック用ショ
ート・アドレスを、また、別の条件下では、同じクラスまたは別のクラスのトラ
フィック用ロング・アドレスを選択することができる。可能な１組のルールでは
、仮想ネットワーク・トポロジがある基準の下で安定しているとき、データ・パ
ケット用ショート・アドレスの使用を含み、また、すべての条件下で制御パケッ
ト用ロング・アドレスの使用を含み、仮想ネットワーク・トポロジが不安定な状
態にある場合にはデータ・パケット用ロング・アドレスの使用を含むことが可能
である。これに起因して、ロング・アドレスにより与えられる一意的デバイス・
アドレス指定をやめることなく仮想ネットワーク内のノード間を通過するパケッ
トの広大な大部分のオーバーヘッドの節減が生じる。したがって、仮想ネットワ
ーク内のいずれのデバイスも１パケットずつのベースでショート・アドレスとロ
ング・アドレスの識別が可能でなければならない。

【００２３】ビットで表わされるショート・アドレスの長さは、最大サイズの仮想ネットワ
ーク内の各デバイスに一意的ショート・アドレスを与えるために必要なビット数
により最も単純に決定される。例えば、２５６個までのデバイスを含む仮想ネッ
トワークでは、ショート・アドレスの長さとして８ビットあれば十分である。

【００２４】８ビットのショート・アドレスの使用から結果として得られるオーバーヘッド
の節減を以下の例を通じて示すことにする。データ・リンク層のロング・アドレ
ス・フォーマットとして、４８ビット・イーサネット・アドレスを仮定する。Ｉ
Ｐパケットの平均的長さはほぼ２５０バイトであり、サーキット・エミュレーシ
ョンによる音声パケットの平均的長さは１５０バイトと仮定する。ＩＰデータパ
ケットと音声パケットの配分は各々５０％であると仮定する。次いで、イーサネ
ット・フレーム内にカプセル化を行う前の平均的パケット長は２００バイトであ
る。イーサネット・フレーム内への各パケットのカプセル化により、ＩＰパケッ
トへの、最低１９バイトのＭＡＣ層オーバーヘッドの追加が結果として得られる
。４８ビットＭＡＣアドレスから８ビットＭＡＣアドレスへの変更により、ＭＡ
Ｃ層オーバーヘッドのほぼ５０％の縮減と、ほぼ４.５％のデータ輸送容量の平
均的増加とが結果として得られる。上記計算では、制御トラフィックは、ネット
ワークの総トラフィックの最低限のパーセントであると仮定されている。圧縮さ
れたＩＰアドレスについても同様のタイプの計算を容易に行うことができる。

【００２５】デュアル・アドレス指定のためのアルゴリズム及びパケット・ヘッダ１つの実施態様では、デュアル・アドレス指定をサポートする仮想ネットワー
クで使用されるパケット・ヘッダには、ソース・アドレスと宛先アドレスの各々
に先行するアドレス・タイプ・フィールドが含まれる。このアドレス・タイプ・
フィールドは長さを１ビットの短かさにすることが可能である。１つの実施態様
では、アドレス・タイプ・フィールドは１.５バイトであり、ソース・アドレス
と宛先アドレスの双方に先行する。

【００２６】図２は、仮想ネットワークの外側で生成されたパケットが仮想ネットワーク内
のデバイス宛てに宛先指定され、デュアル・アドレス指定能力を利用する場合に
とるステップを示すフローチャートである。４８ビットのロング・アドレスが仮
定されている。

【００２７】図２では、仮想ネットワークの外側のデバイスにより生成された原パケットに
は、４８ビットのソース・アドレスと４８ビットの宛先アドレスとを持つ従来方
式のヘッダが含まれている。

【００２８】デュアル・アドレス指定の変換が行われる、外部ネットワークと仮想ネットワ
ーク間のインタフェースで、インタフェース・ノード内のプロセッサは、インタ
ーネット２６と接続された図１のノード２４内のパケットプロセッサの場合のよ
うに、以下のタスクを実行する。このインタフェース・ノードは、私設仮想ネッ
トワーク２１と２２のいずれかと結合されたノードであってもよい。

【００２９】プロセッサは、ヘッダ内の長い宛先アドレスに対応するショート・アドレス（
例えば１バイトなど）をルックアップ・テーブルで調べる。対応するショート・
アドレスは、宛先デバイスがインタフェース・デバイスと関連する仮想ネットワ
ーク内にあることを意味する。プロセッサは長いソース・アドレスを対応するシ
ョート・アドレスと置き換えることもできる。しかし、長いソース・アドレスを
短いソース・アドレスと置き換えることにより、外部ネットワーク内のソース・
デバイスの特定が妨げられる。しかし、専らインタフェース・デバイスとしてソ
ースを知る必要があるにすぎないのであれば、短いソース・アドレスは長いソー
ス・アドレスを置き換えることができる。

【００３０】ルックアップ・テーブルで調べた後、パケット・ヘッダ内のロング・アドレス
は、対応するショート・アドレスにより置き換えられ、ヘッダ内の（長短の）ア
ドレス・タイプが特定される。それに応じて、ロング・ソースまたは宛先アドレ
スの６バイトがヘッダ内の単一バイトのアドレスにより置き換えられる。

【００３１】短縮されたヘッダを持つパケットは、次いで、ショート・アドレスを用いてバ
ーチャル・アドレス内の宛先ノードへ転送される。基本的に、短い宛先アドレス
がノードのショート・アドレスに一致する宛先ノードに着信するまで、仮想ネッ
トワーク内の各ノードによりパケットの転送が行われる。次いで、ノードはネッ
トワークからパケットを取り除く。言うまでもなく、ショート・アドレスの使用
が何らかの理由で適切でなければ、仮想ネットワークはロング・アドレスをショ
ート・アドレスと置き換えない。

【００３２】仮想ネットワークが、仮想ネットワークを介して一体的に結合された２つの外
部ネットワーク間の接続パスとして機能している場合、仮想ネットワークの中へ
入るイングレス・ノードは、必要に応じて、ロング・アドレスをショート・アド
レスへ変換することができ、仮想ネットワークのイグレス・ノードは、ショート
・アドレスを元のロング・アドレスへ変換して、仮想ネットワークの外側へ転送
することができる。

【００３３】図示のように、仮想ネットワーク内で伝送される、各パケットのビット数は減
少し、それによって仮想ネットワークにさらに大きな容量が与えられる。

【００３４】図３は、仮想ネットワークの内側で生成されたパケットが仮想ネットワークの
外側のデバイス宛てに宛先指定された場合にとるステップを示すフローチャート
である。この宛先指定は、パケットが、デュアル・アドレス指定能力を持つ異な
る仮想ネットワーク宛てに宛先指定された場合にも適用される。

【００３５】仮想ネットワーク内のノードで生成された原パケットにはロング・ソース・ア
ドレスと宛先アドレスとが含まれる。この原パケットは典型的にはノード内の従
属インタフェースカードから出力される。このノード内のパケットプロセッサは
、原パケットを受信し、ルックアップ・テーブルを用いて対応する短いソース・
アドレスを特定し、ヘッダ内の長いソース・アドレスをショート・アドレスと置
き換え、アドレス・タイプの特定を行う。この処理は、適切なものであれば宛先
アドレスを用いても行うことができる。次いで、ヘッダ内にショート・アドレス
を備えたパケットが、仮想ネットワークを介して外部ネットワークとインタフェ
ースするノードへ転送される。この時点で、仮想ネットワークの外側へパケット
を伝送する前にショート・アドレスをロング・アドレスに変換しなければならな
い。この目的のために、インタフェース・ノード内のパケットプロセッサは対応
するロング・アドレスを調べ、ショート・アドレスを含むヘッダをロング・アド
レスを含むヘッダと置き換える。

【００３６】次いで、この結果得られるパケットは仮想ネットワークの外側へ転送される。
このようにして、仮想ネットワークを介してパケットが伝送されている間、パケ
ット・サイズが縮減され、仮想ネットワークの容量が効果的に増加される。

【００３７】図４は、仮想ネットワークの内側で生成されたパケットが仮想ネットワーク内
のデバイス宛てに宛先指定された場合にとるステップのフローチャートである。
図４では、仮想ネットワークのノード内の従属インタフェースカードからの原パ
ケットには、従来方式のロング・ソース・アドレスと宛先アドレスとを持つヘッ
ダが典型的に含まれる。

【００３８】ノード内のパケットプロセッサは、ヘッダ内の各ロング・アドレス用ルックア
ップ・テーブル内の対応するショート・アドレス（ショート・アドレスが存在す
る場合）を特定し、パケット・ヘッダをショート・アドレスとアドレス・タイプ
とが含まれるヘッダと置き換える。このステップでソース・アドレスと宛先アド
レスの双方の縮減が可能となるので、約１０バイト分だけヘッダが縮減され、ギ
ガビット・イーサネット様ＭＡＣヘッダの場合、ほぼ５０％のオーバーヘッドの
縮減、また、ＩＰヘッダの場合３０％のオーバーヘッドの縮減という結果が得ら
れる。

【００３９】次いで、この短いヘッダを持つパケットは、仮想ネットワークの中で、ショー
ト・アドレスにより特定された宛先ノードへ転送される。次いで、ノードのショ
ート・アドレスまたはロング・アドレスが仮想ネットワーク・ヘッダ内の宛先ア
ドレスに一致すればパケットはノードによって使用される。仮想ネットワークを
介する伝送が放送モードになっていれば、各ノードによりパケットは使用され、
ノードのショート・アドレスまたはロング・アドレスが仮想ネットワーク・ヘッ
ダ内の宛先アドレスに一致すればノードによりパケットは転送される。ノードの
ショート・アドレスとロング・アドレスのいずれも仮想ネットワーク・ヘッダ内
の宛先アドレスに一致しなければ、ノードはノードを接続する電気的または光学
的リンクを介してパケットをその隣接ノードへ転送する。１つの実施態様では、
仮想ネットワークは、光ファイバまたは電気的ケーブルからなる時計回り方向に
伝送を行う１つのリングと、時計回りとは逆方向に伝送を行う別のリングとを利
用するノードからなるリングである。

【００４０】所定のデバイスにより、パケットを使用するおよび／またはパケットを転送す
るあるいはパケットを落すかどうかについて強い影響を与える別の判断基準を設
けてもよい。上記アルゴリズムは専らショート・アドレスとロング・アドレスの
使用のみを処理するものである。

【００４１】各ノードは仮想ネットワーク内のすべてのデバイスのテーブルを有し、このテ
ーブルには、各デバイスについて、少なくともそのロング・アドレスとそのショ
ート・アドレスとが含まれる。

【００４２】ハードウェアの説明図５は、図１の仮想ネットワーク内のノード２４のような、単一ノード内の関
連する機能ユニットを示す。リング内のこのようなノードは、図１の私設仮想ネ
ットワーク２１と２２の中にも見ることができる。各ノードは、リングインタフ
ェースカード３０と３２により隣接ノードと接続される。これらのリングインタ
フェースカードはケーブル３４と３６で着信する光信号を電気的デジタル信号に
変換し、この電気的デジタル信号を切替え用カード３８に印加する。

【００４３】図６は１つのリングインタフェースカード３２をさらに詳細に示す図であり、
光トランシーバ４０を示している。カード３２内の追加スイッチを用いて２枚の
切替え用カード間の切替えを行い信頼性を付加することができる。上記光トラン
シーバは、市販の１３００ｎｍレーザーを使用するギガビット・イーサネット用
光トランシーバであってもよい。

【００４４】光トランシーバ４０の直列出力は、シリアライザ／直・並列変換器（ＳＥＲＤ
ＥＳ）４２（図６）によって複数ビットからなる並列グループに変換される。１
つの例では、ＳＥＲＤＥＳ４２は、光トランシーバ４０から出力される一連の１
０ビットを８ビットからなる並列グループにテーブルを用いて変換する。８ビッ
ト・コードに対応するように選択された１０ビット・コードによって、１コード
につき１と０からなる数と、連続する１と０の最大数とが等しくなるようにバラ
ンスをとる判断基準が満たされ、改善されたパフォーマンスが得られる。例えば
、多数のシーケンシャルな論理１によって、１と０とを区別するために閾値とし
て受信機が使用する長期の平均電圧レベルのシフトであるベースライン・ワンダ
が作られる。バックプレーン上で１と０のバランスのとれた数を持つ１０ビット
・ワードを利用することによりベースライン・ワンダは大幅に縮減され、それに
よって、バックプレーンとカードとのさらに好適なＡＣ接続が可能になる。

【００４５】ＳＥＲＤＥＳ４２がリングインタフェースカード３２から直列１０ビット・デ
ータを受信したとき、ワードがテーブル内のワードの中の１つに一致しない場合
、ＳＥＲＤＥＳ４２は１０ビット・ワードの中のエラーの有無を検出することが
できる。次いで、ＳＥＲＤＥＳ４２はエラー信号を生成する。ＳＥＲＤＥＳ４２
はテーブルを利用して、切替え用カード３８からの８ビット・コードを１０ビッ
トの直列ストリームに変換し、リングインタフェースカード３２によるさらなる
処理を行う。ＳＥＲＤＥＳ４２は、Vitesse社製のモデルＶＳＣ７２１６あるい
は他の適切ないずれのタイプであってもよい。

【００４６】媒体アクセス・コントローラ（ＭＡＣ）４４はＳＥＲＤＥＳ４２によって検出
されたエラーの数のカウントを行い、これらのエラーは割込みの間、または、ポ
ーリング・メカニズムに従ってＣＰＵ４６へ伝送される。ＣＰＵ４６はモトロー
ラ社のＭＰＣ８６０ＤＴマイクロプロセッサであってもよい。またＭＡＣ４４は
、ＳＥＲＤＥＳにより転送されたいずれの制御用ワードも取り除き、ＭＡＣフレ
ームを構造化することにより特別のプロトコル用フォーマッティングをＯＳＩ層
２（データ・リンク）に与える。ＭＡＣは周知のものであり、文献Roger Freema
n著“電気通信システム工学”（第３版、John Wiley & Sons社、１９９６年）に
ＭＡＣに関する記載がある。上記文献はその全体が本明細書に参考文献として取
り入れられている。ＭＡＣ４４はフィールド・プログラマブル・ゲート・アレイ
であってもよい。

【００４７】パケットプロセッサ４８は、ＭＡＣ４４により伝送されたビットの各々をヘッ
ダ・フィールドやデータ・フィールドのようなパケット・フィールドと関連づけ
る。次いで、パケットプロセッサ４８は、ＭＡＣ４４により構造化されたパケッ
トのヘッダ・フィールドを検出し、さらに、ノード宛てに宛先指定されていない
パケット用ヘッダ内の情報の修正を行うこともできる。好適なパケットプロセッ
サ４８の例として、ＭＭＣネットワーク社製ＸＰＩＦ−３００ギガビット・ビッ
ト・ストリームプロセッサまたはＥＰＩＦ４−Ｌ３Ｃ１イーサネット・ポートＬ
３プロセッサがある。これらのプロセッサのデータ・シートは本明細書に参考文
献として取り入れられている。

【００４８】パケットプロセッサ４８は、その意図された宛先へデータの経路指定を行うた
めのルーティング情報を含む外部のサーチ・マシーン／メモリ４７（ルックアッ
プ・テーブル）とインタフェースしている。

【００４９】図６のメモリ４９はノード内の他のメモリを表す。但し、システムの必要な速
度要件及び機能要件を与えるために、分散型ＳＳＲＡＭ、ＳＤＲＡＭ、フラッシ
ュ・メモリ及びＥＥＰＲＯＭが設けられる場合もあることを理解されたい。

【００５０】パケットプロセッサ４８はスイッチ構造体５０のポートへパケットを出力し、
次いで、スイッチ構造体５０は、パケット・ヘッダに基づいて、スイッチ構造体
５０の適切なポートへパケットの経路指定を行う。パケット・ヘッダ内の宛先ア
ドレスがノード２４（図６に図示のノード）のアドレスに対応していれば、スイ
ッチ構造体５０は、指定されたノード２４従属インタフェースカード５２（図５
）による受信用として、スイッチ構造体５０の適切なポートへパケットの経路指
定を行う。パケット・ヘッダがノード２４以外の宛先アドレスを指示していれば
、スイッチ構造体５０は、適切なリングインタフェースカード３０または３２（
図５）を介してパケットの経路指定を行う。制御パケットはＣＰＵ４６へ経路指
定される。パケットがスイッチ構造体を介してとる必要があるパスの決定に利用
するこのようなスイッチング・ファブリックとルーティング技術は周知のものな
のでこれについての詳細な説明は不要である。

【００５１】１つの好適なパケット・スイッチとしてＭＭＣ社のネットワーク・モデルＮＰ
５４００パケットスイッチ・モジュールがあり、そのデータ・シートは本明細書
に参考文献として取り入れられている。１つの実施態様では、４つのこのような
スイッチがより高速なスループット用の各切替え用カードの中で接続される。こ
れらのスイッチは、パケット・バッファリング能力、マルチキャスト能力及び放
送能力と、４つのクラスのサービス優先順位と、厳しい優先順位すなわち重み付
きの公正なキューイングに基づくスケジューリングとを提供する。

【００５２】１以上の従属インタフェースカード（従属インタフェースカード５２など）と
関連づけられたパケットプロセッサ５４は従属インタフェースカード５２と関連
づけられた装置（ＬＡＮなど）宛てに宛先指定されたパケットをスイッチ構造体
５０から受信する。パケットプロセッサ５４はパケットプロセッサ４８の場合の
ように双方向である。パケットプロセッサ５４と４８は同じモデル・プロセッサ
であってもよい。一般に、パケットプロセッサ５４は、パケットプロセッサ５４
の中を通るデータの方向検出を行うのみならず、ルーティング・テーブル・メモ
リ５５にアクセスして、所望のヘッダ・フィールドの決定なかのいくつか並びに
リング上へ向かうパケット用の最適ルーティング・パスの決定を行い、さらに、
リングへ向かう、あるいは、リングから外れるパケット用の、スイッチの中を通
る所望のパスの検出を行う。パケットプロセッサ５４は、スイッチ構造体５０か
らパケットを受信すると、そのパケットを媒体アクセス制御（ＭＡＣ）ユニット
５６へ転送する。ユニット５６はＭＡＣ４４の機能と同様の機能を実行し、次い
で、該パケットをＳＥＲＤＥＳ５８へ転送してそのデータをシリアル化する。Ｓ
ＥＲＤＥＳ５８はＳＥＲＤＥＳ４２と類似のものである。

【００５３】パケットプロセッサ５４は、スイッチ構造体５０からパケットを受信すると、
もし何か存在する場合には、ヘッダ内のアドレス・タイプ・フィールドを特定し
、アドレスがショート・アドレスであれば、プロセッサ５４はメモリ５５（また
は異なるメモリ）内の対応するロング・アドレスを調べる。次いで、プロセッサ
５４はショート・アドレスをロング・アドレスと置き換え、そのパケットをＭＡ
Ｃユニット５６へ転送する。反対方向で、パケットプロセッサ５４は、１以上の
従属インタフェースカードから発信するパケットをＭＡＣ５６を介して受信する
。これらのパケットには長い宛先アドレスが含まれている。次いで、プロセッサ
５４はルックアップを実行して、ロング・アドレスを置き換えるために使用する
正しいショート・アドレスを決定する。このルックアップでハッシュ関数を利用
してルックアップのスピードを上げてもよい。他の理由のために、例えば従属イ
ンタフェースカード上のパケットプロセッサ５４とは別の同様のパケットプロセ
ッサとの間で負荷のバランスをとる必要がある場合、従属インタフェースカード
上に配置されているパケットプロセッサの中で、使用すべき正しいショート・ア
ドレスの決定を行うことも可能である。ＭＡＣ５６を介してパケットプロセッサ
５４が受信するすべてのトラフィックは、従属インタフェースカード上の１以上
のパケットプロセッサの中を通過する。パケットプロセッサ５４はプログラム可
能であるため、当業者であれば、プロセッサ５４を制御して本発明を実行するプ
ログラムを容易に書き込むことも可能である。

【００５４】パケットプロセッサ４８は、ロング・アドレスまたはショート・アドレスのい
ずれかに基づいてトラフィックの経路指定を行うようにプログラムされる。プロ
セッサ４８が、デュアル・アドレス指定の仮想ネットワークと外部ネットワーク
との間でインタフェースを行うノードの中にあれば、プロセッサ４８は前述した
ようにメモリ４７を用いてロング／ショート・アドレスの置き換えを行うように
プログラムされることになろう。

【００５５】別の実施態様では、プロセッサ４８はプロセッサ５４の代わりにすべてのロン
グ／ショート・アドレス変換を実行する。

【００５６】次いで、ＳＥＲＤＥＳ５８の出力が、バックプレーン５９と接続された図５の
従属インタフェースカード５２のような特別の従属インタフェースカードに適用
される。この従属インタフェースカードは、データのキューを行って、従属イン
タフェースカード５２の特定の出力ポートへのデータの経路指定を行うこともで
きる。上記従属インタフェースカードによるこのようなルート指定とキューイン
グは従来方式のものであってもよく、これについて詳細に説明する必要はない。
従属インタフェースカードの出力は、たとえば銅ケーブルを介して、電話交換機
、ルータ、ＬＡＮあるいはその他の装置のような任意のタイプの装置と電気的に
接続することができる。従属インタフェースカードは、外部インタフェースが光
学的なものである場合には、光トランシーバを利用して電気信号を光信号に変換
することも可能である。

【００５７】パケットプロセッサ５４は、ノード内の従属インタフェースカード５２の中の
１つから発信するパケットを受信すると、前述したようにメモリ５５を用いて適
切にロング・アドレスをショート・アドレスと置き換える。１つの実施態様では
、パケットプロセッサ５４は、ショート・アドレスを変換する前にロング・アド
レスを用いてルーティング・テーブル・メモリ５５の中でルートを最初に決定し
て、何らかの理由のためにショート・アドレスの変更が行われるとき、ルーティ
ング・テーブルの変更を余儀なくされることを回避する。

【００５８】１つの実施態様では、ＣＰＵ４６は、信頼性を考慮するのためにロング・アド
レスを持つ制御パケットにより常にアドレス指定される。ＣＰＵ４６は、もし仮
想ネットワークの変化が生じた場合、新しいアドレスの設定を行うなどのような
リング制御機能の管理を行う。

【００５９】例えば、複数のリングが結合されている場合、新しい仮想ショート・アドレス
の割り当てが必要となる。ノードの各々はそのフル・アドレスを周期的に隣接ノ
ードへ伝送する。ネットワークのトポロジの変更が生じた場合ノードはこの変更
を放送する。次いで、ネットワーク内のマスタＣＰＵ４６は、ネットワーク内の
すべてのノードに対してショート・アドレスの再割当てを行う。あるいは、各Ｃ
ＰＵ４６は分散方式に基づいてこの再割当てを行うことができる。次いで、すべ
てのノードは新しいトポロジ・アドレスを用いてそのノードのメモリの更新を行
う。

【００６０】さらに、ＣＰＵ４６は、現在進行中のトポロジの発見の一部として、現在のセ
ッション番号を用いて番号がふられたすべての受信された隣接状態メッセージと
共にセッション番号をメモリ内に格納する。ＣＰＵ４６は、セッション番号管理
とトポロジ検証を含む、トポロジの発見のすべての側面を管理するソフトウェア
・アプリケーションを実行する。

【００６１】システムコントローラ６２はノードから状態情報を取得し、ネットワーク管理
システムとインタフェースを行う。ノードのこの側面は本発明には関係しない。
システムコントローラはネットワークの種々のテストに関する報告を行うように
プログラムすることができる。

【００６２】１つの実施態様では上述のハードウェアは１Ｇｂｐｓ以上のレートで処理を行
う。

【００６３】図５と６のこのハードウェアについてのさらなる記載が、シリアル番号０９／
５１９，４４２、２０００年３月出願の本譲受人へ譲受されたRobert Kalmanら
による“動的に割り当てられたリング保護及び復元技術”という表題の同時継続
出願）の中にある。上記出願は本明細書に参考文献として取り入れられている。

【００６４】本発明の１つの実施態様の実現のために使用されるハードウェアに関する上記
記載は一般の当業者が本発明を構成するのに十分である。なぜならば、パケット
交換とルート指定を行うための一般的ハードウェアは周知のものであるからであ
る。当業者は、本明細書に記載のステップを実行するためにＭＡＣ、パケットプ
ロセッサ、ＣＰＵ４６及び他の機能ユニットを容易にプログラムすることも可能
である。本明細書に記載のステップを実行するためにファームウェアまたはソフ
トウェアを利用してもよい。

【００６５】トポロジの再構成シナリオにおけるデュアル・モードによるネットワークのアドレス割当てこのセクションでは、トポロジの再構成時に仮想ネットワーク内のデバイスに
ショート・アドレスを自動的に割り当てる方法について説明する。この方法はプ
ラグ・アンド・プレイと呼ばれている。

【００６６】仮想ネットワークにとって可視のすべての挿入デバイスを仮想ネットワークの
一部となるように意図することが仮定されている。そうでない場合、どのデバイ
スがデュアル・アドレス指定機能を利用すべきかを指示するために、デバイスの
再構成を行うか、デバイスが管理システムからのコマンドを利用するかしなけれ
ばならない。

【００６７】プラグ・アンド・プレイ技術の構成要素の若干には以下のものが含まれる。１．仮想ネットワーク内部の、または、私設仮想ネットワークのデータ・リンク
および／またはネットワーク層上の異なるタイプのネットワーク・トラフィック
にアドレス指定モードをマッピングするためのアルゴリズム２．各デバイス内の最小数の構成要素に対するアドレス情報の隔離を可能にし、
それによって、仮想ネットワーク・トポロジの変更に際して、ロング・アドレス
のショート・アドレスへの高速かつ単純な再マッピングを可能にするアドレス・
マッピング・メカニズム３．ネットワーク内の各デバイスからの状態メッセージに基づいて、各デバイス
におけるネットワーク・トポロジの構成を行うための効率的アルゴリズム４．仮想ネットワークの初期化のための自動的プラグ・アンド・プレイ・アルゴ
リズム５．仮想ネットワークへデバイスの挿入を行うための自動的プラグ・アンド・プ
レイアルゴリズム６．仮想ネットワークからデバイスの削除を行うための自動的プラグ・アンド・
プレイ・アルゴリズム７．デバイスの挿入あるいはネットワークからのデバイスの削除を伴わない仮想
ネットワーク・トポロジの変更を処理するための自動的プラグ・アンド・プレイ
・アルゴリズム８．予め割り当てられたショート・アドレスを持つデバイスが各々に含まれ、現
在進行中のトラフィック接続が含まれるネットワークの結合を行うための自動的
プラグ・アンド・プレイ・アルゴリズム

【００６８】上述の、仮想ネットワーク内でのデュアル・モードによるアドレス指定から、
１デバイスについて、ショート・アドレス指定モードのオプションを利用するこ
とにより、さらに大きいデータ輸送効率という利点が得られ、同時に一方で、ト
ポロジの再構成シナリオの管理を行う１デバイスについて地球的規模の一意的ロ
ング・アドレスの便宜が維持される。トポロジの再構成シナリオには、ネットワ
ークの初期化、デバイスの挿入、デバイスの削除、デバイスの挿入や削除を伴わ
ないトポロジの変更、及び、動作中のネットワークの結合が含まれる。本明細書
の文脈では、ネットワークの初期化とは、デバイス自身を初期化するための各デ
バイスが独立に利用する内部処理を意味するのではなく、ネットワーク・トポロ
ジについての知識の確立と、ショート・アドレスのロング・アドレスへの再マッ
ピングの確立とに必要な相互接続デバイス間の通信を意味している。

【００６９】トポロジの再構成を行うために利用するメカニズムが満たすべきいくつかの基
本的な要件が存在する。

【００７０】再構成を行っているネットワークの乱されていないノード間で現在進行中のト
ラフィックは、そのようなトラフィック用として利用可能な複数のパスが存在す
ると仮定してフローを継続すること。この再構成が、トラフィックのフローが行
われる物理的ルートの一時的除去を伴う場合には、ＳＯＮＥＴベースの回線のよ
うな標準的な保護切替えメカニズムや、パス切替えや、あるいはパケット交換ネ
ットワーク用の他のメカニズムを利用して、ノード間の、影響を受けていない物
理的ルートへのトラフィックの一時的経路指定が行われる。

【００７１】このメカニズムはプラグ・アンド・プレイであること。例えばトポロジの変更
の決定とその結果生じるショート・アドレスの変更とが自動的に行われ、ネット
ワーク管理システムからの干渉を必要としないこと。

【００７２】上記メカニズムは、再構成により必要とされる、デュアル・アドレス指定モー
ド間の切替えに起因して生じる、管理情報と制御情報（デバイス内部の供給用テ
ーブルとルーティング・テーブルなど）に対する変更を最小限にする（好適には
必要としない）ものであること。

【００７３】デバイス間の通信メカニズムは、所定のデバイスによるトポロジの変更情報の
検出を可能にし、この情報を仮想ネットワーク上のすべての他のデバイスへ伝播
するようにすべきである。ＯＳＰＦルーティング・プロトコルで使用されるトポ
ロジの変更を放送するためのリンク状態プロトコルのような標準的メカニズムを
利用したり、他のメカニズムを利用したりしてこの検出と伝播とを行うことがで
きる。メカニズムの選択は個々の仮想ネットワークの固有の要件に基づくことに
なる。

【００７４】必要なことは、トポロジの再構成を可能にし、複数のネットワークを一体とし
て結合するとき、ショート・アドレスの２重化を行う必要がないことを保証する
ための再構成の一部としてショート・アドレスの再設定を可能にするメカニズム
である。

【００７５】トポロジの再構成中ロバストなネットワークの挙動を保証するために、トポロ
ジ情報を含む制御メッセージが、ソース情報と宛先情報（制御メッセージの配信
）の双方に対してのみならずそのメッセージ内のトポロジ情報の参照に対しても
一意的ロング・アドレスを使用できることが重要である。動作中のネットワーク
に対してデバイスを挿入したとき、あるいは、複数の動作中のネットワークを結
合したとき、制御機能用のロング・アドレスの使用により、決してアドレスの２
重化が生じないことが保証される。制御メッセージは、通常のネットワーク動作
中総トラフィックのうちの小さな割合しか占めないので、最も単純でかつ最も信
頼性の高いアプローチは制御メッセージ用としてロング・アドレスを常時使用す
ることである。

【００７６】規則的なデータ配信を行うためには、ネットワーク・トポロジが安定せず、未
知である期間中はデータ配信用としてアドレス指定モードを設けることが重要で
ある。これらの期間は、トポロジの再安定化と、ショート・アドレスの再割当て
の保証に必要な待ち時間に対応する（トポロジの変更を示す制御メッセージがデ
バイスにより受信された後）。特に、動作中の２つのネットワークが結合され、
双方のネットワークにわたって使用される完全なセットのショート・アドレスの
中に何らかの２重化が生じた場合、ショート・アドレスの２重化が生じたノード
に対して少なくともショート・アドレスのロング・アドレスへのマッピングを再
び行うことが必要となる。ショート・アドレスの再マッピングの期間中データの
紛失や間違った宛先への配信が生じないことを保証するために、影響を受けたノ
ードからの、あるいは影響を受けたノードへのいずれのデータもデータ配信用の
ロング・アドレスの使用へ切替えを行う必要がある。この切替えの必要性は、分
散方式で（各デバイスで独立に）ショート・アドレスの再マッピングを行うか、
あるいは、地球的規模のマスタ・デバイスを設け、次いで、ネットワーク内のす
べての他のデバイスへ配信を行うようにするか否かとは無関係のケースである。
もしこのようなメカニズムが提供されなければ、遷移期間中いくつかのパケット
の紛失や間違った配信が生じることを避けることはできない。

【００７７】単純な実施構成のオプションとして、いずれかのトポロジの変更時に標準的ア
ルゴリズムに基づいてすべてのショート・アドレスのロング・アドレスへの再マ
ッピングを行うオプションがあり、以下のようなものとなる。（ショート・アド
レス１、ソートされたリスト内の最小のロング・アドレス）、（ショート・アド
レス２、ソートされたリスト内の２番目に最小のロング・アドレス）等。このア
プローチの欠点として、若干のネットワーク容量が一時的に紛失するという点が
挙げられる。なぜならば、短時間の間にネットワーク内のすべてのトラフィック
を４８ビット・アドレスへ切替えを行わなければならないからである。このアプ
ローチの利点は、任意のトポロジの変更後に同じアクション（ショート・アドレ
スの再マッピング）を行うことに起因するその単純さである。

【００７８】別の単純な実施構成のオプションとして、地球的規模のマスタ・デバイスでア
ドレス・マッピングを行うのではなく、分散方式に基づいて（各デバイスで）ア
ドレス・マッピングを行うオプションがある。このアプローチの欠点として、そ
の場合、すべてのネットワークがネットワーク・トポロジについての知識を持つ
必要があるという点が挙げられる。この必要性はＳＯＮＥＴネットワークの場合
必要ではないが、各ノードが最少コストのパス上で宛先へパケットの経路指定が
行われる容量効率の良いパケット交換ネットワークでは要求される。このアプロ
ーチの利点として、元の地球的規模のマスタがダウンした場合、新しい地球的規
模のマスタ・デバイスの選択を行う必要がないという点が挙げられる。

【００７９】デバイスでアドレス指定モードを変更する必要がある場合、（メモリ内のデー
タの変更という点から見て）強い影響を受ける独立した構成要素の数を最小限に
することが、信頼性という視点から強く望まれる。これは構成要素の数を最小限
にすることと同値である。１つの実施態様では、パケットプロセッサ５４（図６
）はメモリ５５のようなテーブルを用いてショート／ロング・アドレスの変換を
実行する。ロング・アドレスとショート・アドレスの入れ替えを可能にすること
に加えて、前述したルールに基づいてプログラマブル・パケットプロセッサの制
御を行うことが可能である。デバイスを出て、仮想ネットワーク上へ向かうパケ
ットの場合、パケットが制御パケットであるかデータ・パケットであるかに基づ
いて、さらに、ショート・アドレスがロング・アドレスへ再マッピングされるか
どうかに基づいて、（デバイス内のどこか別のところで仮想ネットワーク・ヘッ
ダを作成する際に使用される）ロング・アドレスをショート・アドレスへ変更す
るかどうかの決定が行われる。

【００８０】前述したルールに基づいて以下のようにパケットプロセッサ４８の制御が可能
である。仮想ネットワークからデバイスに入るパケットの場合、そのデバイスは
ショート・アドレスとロング・アドレスのいずれの有効な結合も認識する。例え
ば、上記デバイスは、ロング・アドレスを使用するものもあれば、ショート・ア
ドレスを使用するものもあるインタリーブされたデータ・パケットを同じソース
から途切れることなく受け入れることができなければならない。

【００８１】このパケットプロセッサ５４、パケットプロセッサ４８及びＣＰＵ４６以外の
デバイス内の他のエンティティはショート・アドレスについて何ら知識を持つ必
要がない。例えば、デバイス内に格納された構成／供給用テーブルとルーティン
グ・テーブルはロング・アドレスのみを使用して、トポロジの再構成の際に混乱
（perturbation）を排除するようにしなければならない。従属インタフェースカ
ードのパケットプロセッサにアクセス可能なメモリ内に格納された構成／供給用
テーブルが強い影響を受けないようにすることが重要である。なぜなら、このよ
うなテーブルのアドレス変更に起因して、ネットワーク・トラフィック接続の再
初期化という結果を生じ、それによって現在進行中のトラフィックの外乱が生じ
る可能性があるからである。他の実施態様では、従属インタフェースカードに配
置されたパケットプロセッサの中でロング・アドレスとショート・アドレスの入
れ替えを実行するように選択することも可能である。この入れ替えは、構成／供
給用テーブルとは無関係の別々のオペレーションで行ってもよい。

【００８２】トポロジ構成／再構成アルゴリズムネットワーク内のデバイスにより提供されるトポロジ状態情報を利用するトポ
ロジ構成／再構成アルゴリズムは、仮想ネットワーク内のすべてのデバイスのロ
ング・アドレスを決定して、トポロジが完全であるかどうかをチェックし、さら
に、トポロジ内のロング・アドレスの各々に対してショート・アドレスのマッピ
ングを行うことを求められる。すべてのケース（初期化、デバイスの挿入、デバ
イスの削除、スパンの状態変化及びネットワークの結合）を処理する本願発明者
による固有のアプローチは、以下のステップを有する。

【００８３】各デバイスは、各デバイスからその近傍の各々へ送信される制御パケットを介
して、その隣接デバイスの各々のロング・アドレスを見つけ出す。この近傍情報
パケットは、要求により（隣接要求パケットに応答して）周期的に送信を行うか
、近傍情報パケットの内容に強い影響を与えるトポロジの変更を検出した時に送
信を行うかのいずれかが可能である。各デバイスがイングレス近傍（例えばデバ
イスが受信データを送信する近傍）のみに関する報告を行う役割を果たすという
点に留意することが重要である。このデバイスは必ずしもその近傍と２方向の物
理的連結性を有するとはかぎらない。

【００８４】近傍からの要求パケットは少なくともメッセージ・タイプ、ソース・デバイス
・アドレス、宛先デバイス・アドレス及びＴＴＬ（time-to-live）ＩＤの表示を
含む必要がある。上記要求パケットは、どのソフトウェア・アプリケーションが
受信用アプリケーションであるかを示す表示と、メッセージの優先順位および／
またはクラスの表示と、エラー検出コードまたは誤り訂正コード（フレーム・エ
ラー・チェックサムなどの）と、アドレス・タイプ・フィールド（デュアル・モ
ードによるアドレス指定を使用するネットワーク用）と、ソース・デバイス・ア
ドレスとは別個のソース・ポート・アドレスと、宛先デバイス・アドレスとは別
個の宛先ポート・アドレスとをオプションとして含むものであってもよい（但し
これに限定されるものではない）。この情報は、制御メッセージ専用として使用
される包括的パケット・ヘッダの中に含めてもよいし、あるいは、ネットワーク
で伝送されるすべてのパケットに共通の包括的パケット・ヘッダの中に含めても
よいし、あるいはまた、包括的パケット・ヘッダに後続する制御メッセージ・ヘ
ッダの中に含めてもよい。近傍からの要求パケットは、送信時に、デバイスのす
べてのイグレス・インタフェースで包括して送出される場合もある。デバイスが
その近傍のデバイス・アドレスを認知していると仮定することはできないので、
ＴＴＬフィールドが非常に重要なものとなる。宛先デバイス・アドレスを包括的
放送アドレスに設定してもよいが、ＴＴＬのＩＤは単一ホップに設定されなけれ
ばならない。したがって、送信用デバイスの隣接する近傍を越えてパケットが転
送されることはない。

【００８５】近傍情報パケットがセッションＩＤと送信用デバイスのインタフェースＩＤと
をさらに含まなければならないという点を除いて、上記近傍情報パケットには近
傍からの要求パケットと同一の情報が含まれる。セッション番号が含まれること
により、新しく挿入されたデバイス（または故障からパワー・アップしたばかり
のデバイス）用メカニズムが提供され、次に説明する隣接状態メッセージで使用
する正しいセッションＩＤが見つけ出される。インタフェースＩＤが含まれるこ
とは、２デバイス・ネットワーク用のすべてのトポロジの変更シナリオの解決に
必要である。なぜなら、デバイス自体のアドレスは故障シナリオ中複数のインタ
フェースを識別できるほど十分ではないからである。上記についてのさらなる記
載として、本譲受人へ譲受されたRobert Kalmanらによる“動的に割り当てられ
たリング保護及び復元技術”という表題の同時継続出願に記載のシナリオがある
。上記出願は本明細書に参考文献として取り入れられている。近傍情報パケット
は、単一ホップに設定されたＴＴＬフィールドも必要とする。これは、デバイス
が近傍へのイグレス・インタフェースを備えてはいるが、近傍からのイングレス
・インタフェースを備えていない場合、デバイスは、当該デバイスのアドレスに
ついての知識を必ずしも持つことなく、近傍情報パケットを周期的に当該近傍へ
送信しなければならないという理由に因るものである。その場合、デバイスは、
近傍からの要求パケットに関する限り宛先デバイス・アドレスとして包括的放送
アドレスを利用することになる。

【００８６】近傍情報パケットからの情報の収集時に、各デバイスは隣接状態メッセージ内
の少なくとも以下の情報の放送が可能である。近傍情報パケットに含まれるすべ
ての情報、及び、各イングレス近傍について、当該近傍の４８ビット・アドレス
と、該近傍をデバイスと相互に接続する物理的スパンの状態。オプションとして
、隣接状態メッセージは、各イングレス近傍用のデバイス・アドレスとは別個の
ポート・アドレスを含むものであってもよい。ＴＴＬフィールドは構成可能値（
通常、ネットワークのサイズに対応して１よりもずっと大きな値）に設定される
。そのイングレス・インタフェースで同じメッセージをすでに送出したいずれか
のデバイスにより放送はネットワークから除去される。ＯＳＰＦルーティング・
プロトコルで使用されるものと同じアプローチを利用して上記放送の除去処理を
行うことができる。Wesley著“相互接続、第２版”（ロングマン社、２０００年
刊）という文献にこの除去処理についての記載がある。本文献はその全体が本明
細書に参考文献として取り入れられている。メッシュ・ネットワークでは、所定
のセッションに対する所定のソースからの隣接状態メッセージが当該インタフェ
ースで受信されたか、あるいは、当該インタフェースで伝送されたどうかを示す
各デバイス・インタフェースにおける状態に関して、（放送ストームが発生しな
いことを保証するために）放送の管理を行うことが可能である。リング・ネット
ワークでは、このような状態が用いられることはあまり重要なことではない。な
ぜなら、このようなメッセージの処理が冪等元である場合の２倍の２重化隣接状
態メッセージを受信することに不都合がないからである。

【００８７】トポロジの変更時に、別のノードからの受信メッセージに基づいてノードによ
り検出された最大のセッション番号よりも大きなセッション番号を持つ、以前に
伝送された隣接状態メッセージから情報を放送する必要がある。現在値以上のセ
ッション番号の増分は、トポロジの変更がデバイスにより新しく検出されたかど
うかを示すものである。隣接状態メッセージの中でセッション番号に割り当てら
れたバイトの数は、セッション番号のロールオーバを稀なものにするために少な
くとも２でなければならない。ロールオーバが生じたとき、ＯＳＰＦルーティン
グ・プロトコルで利用される、周知の循環シーケンス番号ラップアラウンド・ア
ルゴリズム（circular sequence number wraparound algorithm）を用いてこの
ロールオーバの処理を行うことが可能である。このアルゴリズムについてはWesl
ey著“相互接続、第２版”（ロングマン社、２０００年刊）という文献に記載が
ある。本文献はその全体が本明細書に参考文献として取り入れられている。この
状態は、スパンが“アップ”か“ダウン”のいずれであるかを示す数であるが、
また、スパン・ビットエラー比率のパフォーマンスの低下が存在する場合、その
ような低下を示すレベルでもある。

【００８８】この放送は、信頼性が高い場合もあれば、高くない場合もある。放送の信頼性
が高いことはあまり重要なことではない。なぜならば、受信されない放送がトポ
ロジ検証の一部として検出される場合もあるからである。これについてはこのセ
クションで後程説明する。応答スピードが非常に重要な状況（リンク故障の場合
のルート再選定シナリオ中などのような）の場合、複数回この放送を送信するこ
とも可能である。

【００８９】デバイスの現在のセッション番号より大きなセッション番号を持つ隣接状態メ
ッセージを受信した任意のデバイスは、その受信したセッション番号になるまで
そのセッション番号を増分し、その近傍状態情報の放送を行う。このセッション
番号が現在のセッション番号に等しくなれば、デバイスは放送を行わず、隣接状
態メッセージの受信の確認応答を送信することができる。このセッション番号が
現在のセッション番号より少ない場合、デバイスは何もしない場合もあれば、そ
のセッション番号が日付に由来するものである旨をソース・デバイスに通知する
場合もある。

【００９０】新しいセッション番号を持つ隣接状態メッセージの放送時または受信時に、デ
ュアル・モードによるアドレス指定を使用する場合、各デバイスはデータ用のロ
ング・アドレスの使用に切り替わる（デュアル・モードによるアドレス指定を使
用しない場合、各デバイスはすでにロング・アドレスを使用している）。実施構
成を簡略化するために、このステップはいずれのタイプのトポロジの変更の場合
にも生じる可能性がある。

【００９１】各デバイスは現在のセッションのすべての受信された隣接状態メッセージをバ
ッファする（しかし各デバイスは前回のセッションから構成された最新の完全な
トポロジをまだ破棄していない）。各デバイスは、デバイス自身の構成から始め
て、トポロジの内部ソフトウェア表現を構成する。生じる可能性のある多数の内
部表現が存在するが、その中の１つをここに示す。内部ソフトウェア表現の各エ
レメントには以下のフィールドが含まれる。原デバイスのロング・アドレス、各
イングレス・インタフェースでの隣接デバイスのロング・アドレス、各イングレ
ス・インタフェースでのイングレス・スパン状態、各近傍スパンでの原デバイス
から各隣接デバイスへのポインタ、ソース・デバイス（トポロジ構成を行うデバ
イス）から、上記エレメントの中に含まれるデバイスまでのイングレス距離、原
デバイスから、イングレス・スパンに原デバイスを備える各隣接デバイスへの逆
ポインタ、上記エレメントの中に含まれるデバイスからソース・デバイスまでの
エグレス距離。

【００９２】ネットワーク・トポロジの一例と、その完全なトポロジ表現とが図７と８にそ
れぞれ示されている。この表現は、メッシュ・トポロジのマッピングの形成に使
用できる一般的表現である。リング・ネットワークの場合、必ずしも何らかのポ
インタを必要とするとはかぎらない単純化された表現を用いて処理速度の最大化
を図ることが可能である。

【００９３】この内部ソフトウェア表現はソース・デバイス（Ａ）用エレメントから作成さ
れる。隣接状態メッセージに含まれるイングレス・スパンに基づいて、ソース・
デバイスの各イングレス近傍（Ｂ及びＣ）用エレメントは、ソースから各近傍へ
のポインタの作成と共に作成される。ネットワーク全体がマップされるまでＢと
Ｃの各イングレス・スパンについても同様の処理が後続する。ネットワーク全体
のマッピング時に、各イングレス・ポインタの逆方向を指す逆ポインタが割り当
てられる。

【００９４】当該セッション用メッセージの元の受信時から測定されるトポロジの発見のタ
イムアウト時にセッションの最終となるトポロジ表現が決定される。タイムアウ
トが生じるとトポロジの安定性のチェックが行われる。トポロジの安定性のため
の時間は、現在のセッションに対応する他のデバイスからの受信メッセージがな
かった（隣接状態メッセージなどが受信されず、いずれのリンク状態の変更の内
部通知もなかった）時間として定量化される。安定性のための時間が構成可能な
閾値を上回った場合、トポロジは収束したと考えられ、トポロジ検証が行われる
。（トポロジの安定性のための時間閾値は、トポロジの発見が正常な動作条件下
で早すぎて終了しないことを保証できるほど十分に大きく設定する必要があるこ
とは言うまでもない。）安定性のための時間が構成可能な閾値を上回らなかった
場合には、トポロジの発見タイマをリセットしてもよい。あるいは、ある最大ト
ポロジ発見時間を超過した場合、トポロジの発見は失敗したと考えることができ
る。

【００９５】トポロジ検証では以下のことが保証される。（ａ）メッセージが紛失しないこと。現在のセッションＩＤを持ついずれかの
隣接状態メッセージ、または、ノードが受信した近傍情報メッセージが、近傍も
しくはソースと述べるすべてのノードから隣接状態メッセージが受信されれば、
上記メッセージの紛失が生じないことが保証される。（ｂ）無効または不一致の
ノード・アドレスがトポロジの中に含まれないこと。トポロジ内の各対の隣接ノ
ードが近傍として互いを報告していることをチェックすることによりこれは容易
に決定される。単一のファイバ・リンクが隣接ノードを接続している場合、ファ
イバ・リンクの受信端のノードは近傍について報告しなければならない。また、
（報告された近傍アドレスに等しいアドレスを持つ）ファイバ・リンクの送信端
のノードは確定されていない近傍アドレスについて報告しなければならない。（
ｃ）トポロジが無効なものではないこと。複数のノードを持つ有効なトポロジ内
のノードは近傍が見えない旨を報告することはできない。これは、ノードが、ネ
ットワーク内のいずれかの他のノードからいずれのメッセージも受信できないこ
とを示す。トポロジ検証がパスすれば、トポロジが有効なものであることが決定
される。トポロジの最終段階に、Ｄｉｊｋｓｔｒａのアルゴリズムのような標準
的ルート指定アルゴリズムを用いてノード間の経路指定に対応する距離（または
さらに一般的には重み付けやコスト）の計算を行うことができる。ポインタ及び
逆ポインタはこのようなアルゴリズムの処理速度が最大となるようにレイアウト
される。再言するが、リング・ネットワーク用として、処理速度をさらに最大化
するもっと単純なアルゴリズムの利用が可能である。

【００９６】デュアル・モードによるアドレス指定を用いる場合、トポロジ内のすべてのノ
ードのロング・アドレスは昇順にソートされ、次いで、対応するショート・アド
レスの順にマップされる（放送用のようないずれかの予約されたショート・アド
レスを除く）。一旦このマッピングが完了すると、当該デバイスにより生成され
たデータ・パケットで各デバイスは新しいショート・アドレスの使用を開始する
。前述したように、実施構成の簡略化のために各トポロジの変更に対してこのマ
ッピングが再び行われる。ＣＰＵ４６からパケットプロセッサ５４への制御パス
に対する負荷を最小限にするという理由のために、必要な場合にショート・アド
レスのみの再マッピングを行って、２重化問題の解決を図ることが必要となる場
合もある。これには、２重化がどこで発生したを検出し、同一のショート・アド
レスを持つ１組のノードのうちのいずれがそれらのショート・アドレスの修正を
行うべきかを決定するためにＣＰＵ４６で実行する種々の付加機能を必要とする
。

【００９７】上記再マッピング技術は、前述したハードウェアを用いてソフトウェアまたは
ファームウェアで実行される。当業者であれば前述のハードウェアのプログラミ
ングについて知ることができる。

【００９８】図９〜１２は、トポロジの再構成の様々な段階中ＣＰＵ４６で実行されるソフ
トウェアにより行われるアクションを要約するフローチャートである。図９は隣
接状態メッセージを送出するアクティブ・デバイスへ通じるシナリオについて説
明するものである。ＣＰＵ４６は、ＭＡＣ４４（前述）によるエラー・カウント
に基づいて、または、イングレス・ファイバ３６に対する光強度の紛失の検出に
基づいて隣接デバイスからイングレス・リンクのモニタを行うことが可能である
。トランシーバのような種々の市販の光トランシーバ・ファミリによりこの検出
は行われる。（Ｉ２Ｃ回線などを介して）バックプレーンにわたる直接シグナリ
ングにより光強度条件の紛失をＣＰＵ４６へ報告し、ＣＰＵにおける割り込みま
たは低レベル・イベントを引き起こすことが可能である。ＣＰＵ４６はすべての
イングレス・インタフェースに関する最新の近傍情報を最新のセッション番号と
共にメモリ内に格納する。もし近傍情報および／またはリンク状態情報のいずれ
かに変更があれば、ＣＰＵ４６はセッション番号を増分し、隣接状態メッセージ
を生成してネットワークで放送を行う。

【００９９】図１０は、受信した隣接状態メッセージ用のセッション番号のシナリオを記述
するものである。図１０に含まれる情報については前述した。非常に重要なポイ
ントとして、ＣＰＵ４６が、現在のセッション番号が表わす、１デバイスずつの
ベースのすべての隣接状態メッセージ情報をメモリ内に格納するという点が挙げ
られる。メモリへのこの格納を実行する多くの周知の方法が存在するので本明細
書でそれらについて説明する必要はない。セッション番号が更新された場合、Ｃ
ＰＵ４６はメモリ内に現在格納されている情報を除去し、新しいセッション番号
のための情報収集を新しく開始する。各デバイス・インタフェースにおける状態
情報の管理を行うことにより放送ストームを防止するメカニズムの実施構成はパ
ケットプロセッサ４８でもっとも好適に管理されるという点に留意することが重
要である。その理由として、放送メッセージの転送に関与することをＣＰＵに求
めることは望ましくないということが挙げられる。

【０１００】図１１は、トポロジ発見用タイマが時間切れとなったとき、ＣＰＵソフトウェ
ア内で実行されるアクションを記述するものである。トポロジ発見用タイマは、
WindRiver Systems社製のＶｘＷＯＲＫＳなどのようなリアルタイム・オペレー
ティング・システムの基本機能として簡単に実現される。トポロジ発見用タイマ
が時間切れになると、トポロジの安定性のための時間が構成可能な閾値に対して
チェックされる。最後に受信した隣接状態メッセージのタイムまたはリンク状態
の変更についての内部通知を追跡することによりこの時間は容易に決定される。
次いでトポロジの構成と検証が実行される。このプロセス中、メモリ内に現在格
納されている有効なトポロジは乱されない。トポロジが有効であることが判定さ
れた場合、有効なトポロジに置き換えられる。トポロジが無効であることが決定
された場合、トポロジ発見の新しいラウンドが開始される。

【０１０１】図１２はトポロジ検証用ソフトウェア内のステップを詳述するものである。所
定のデバイスで実行されるトポロジ検証用ソフトウェアは各イングレス・インタ
フェース上の当該デバイスの近傍から始まる。このトポロジ検証用ソフトウェア
は、全トポロジが構成されるまで、深さ優先か幅優先方式のいずれかの方式でト
ポロジの中をイングレス・インタフェースに沿って進む。ソフトウェアは、トポ
ロジを構成するとき、無効トポロジであることを示す条件のチェックを行う。ス
テップ２は、受信メッセージを介して近傍が特定されないかぎり、単一ノード・
トポロジが有効なものであると考えられていることを示す。しかし、ソース・デ
バイスが近傍を持たないことを示す、受信された隣接状態メッセージは無効トポ
ロジの存在を信号で知らせる。ステップ３は、近傍が検出されないところにイン
タフェースがある場合はいつでも、これは容認可能な条件であることを示し、接
続された近傍が存在しないことを単に示す。ステップ４は、受信した隣接状態メ
ッセージの中にデバイスの近傍として近傍デバイス・アドレスが示された場合、
当該近傍からの隣接状態メッセージが存在しなければならない旨を示す。もしい
ずれのメッセージも受信されなければ、それはメッセージが紛失したこと、及び
、トポロジが無効であることを示す。ステップ５は、図８に図示のデータ構造の
ようなデータ構造を構成するために、各デバイスのすべてのデバイスとすべての
インタフェースの中を通ってトポロジ構成がループすることを示す。ステップ６
は上記ループが完了し、無効条件が発見されなかった場合、最終チェックを行う
ことができることを示す。ステップ７は、未使用の隣接状態メッセージ（いずれ
のデバイスともリンクされていないメモリ内に格納されているデバイス情報など
）がまだ存在する場合、メッセージが紛失し、トポロジが無効であることを示す
。ステップ８は、トポロジが有効となるためには、すべてのノード（デバイス）
が少なくとも１つのエグレス・インタフェースを備えていなければならないこと
を示す。これはネットワークに依存するオプションの条件である。これらのチェ
ックのすべてが完了すればトポロジは有効であると考えられる。

【０１０２】本発明の特定の実施態様について示し、説明したが、その広い局面において本
発明から逸脱することなく、変更及び修正を行うことも可能であることは当業者
には明らかであろう。したがって、添付の請求項は、本発明の真の精神と範囲に
属するものとして上記のようなすべての変更と修正をその範囲内に包含するもの
である。

【図面の簡単な説明】

【図１】インターネットとも接続された或るノードを備えた複数の相互接続された仮想
ネットワークを示す。

【図２】外部からのパケットが仮想ネットワーク内で伝送される場合のイベントのフロ
ーチャートである。使用されるアドレス長の値はイーサネット長のロング・アド
レスと１バイトのショート・アドレスとを表す。

【図３】仮想ネットワークの内側からのパケットが仮想ネットワークの外側へ伝送され
る場合のイベントのフローチャートである。

【図４】仮想ネットワークの内側からのパケットが仮想ネットワーク内のノード宛てに
宛先指定された場合のイベントのフローチャートである。

【図５】仮想ネットワークのノード内の関連する機能ユニットを示す。

【図６】図５の切替え用カードの追加の詳細を示す。

【図７】仮想ネットワーク・トポロジを示す。

【図８】図７のトポロジのソフトウェアによる表現である。

【図９】トポロジの発見を開始する隣接状態メッセージの放送へ通じるステップを示す
フローチャートである。

【図１０】隣接状態メッセージを受信したときにとるステップを示すフローチャートであ
る。

【図１１】トポロジ発見用タイマの時間が切れたときにとるステップを示すフローチャー
トである。

【図１２Ａ】トポロジの検証中にとるステップを示すフローチャートである。

【図１２Ｂ】トポロジの検証中にとるステップを示すフローチャートである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者バンナイ，ビナイケー．アメリカ合衆国、94041、カリフォルニア州、マウンテンビュー、ビラストリート 1600、アパートメント305 Ｆターム(参考） 5K030 GA03 HA08 HB28 HD09 KA05 LB05 LB15 【要約の続き】ドレスとすることが可能である。このようにして、仮想ネットワーク・トポロジの内側のトラフィック・フロー、または、私設仮想ネットワークのトラフィック・フローにより、仮想ネットワーク・トポロジ内のデバイスのアドレス指定がデータ・リンク層および／またはネットワーク層上でデュアルな方法で可能となる。また、仮想ネットワーク内でソース・アドレスをデバイスに自動的に割り当てる技術についても説明する。

Claims

【特許請求の範囲】

【請求項１】通信ネットワークにより実行される方法であって、前記ネッ
トワークは相互に接続されたノードを具備する方法において、前記ネットワークで伝送する対象データ用の宛先ノードを指定するために、ソ
ース・ノードにおいてＭビットの第１の宛先アドレスを生成するステップと、前記宛先ノード用のＮビットの第２の宛先アドレスを前記ネットワーク内の第
１のノードにおいて特定するステップであって、ＮはＭよりも著しく小さいステ
ップと、前記宛先ノードへ前記データを経路指定するための前記第２の宛先アドレスを
用いて前記データを前記ネットワーク内で伝送して、より少ない数のアドレス・
ビットを伝送することにより前記ネットワーク内のオーバーヘッドを縮減するよ
うになすステップと、を有することを特徴とする方法。
【請求項２】請求項１に記載の方法において、前記ソース・ノードと前記
第１のノードとが同じであることを特徴とする方法。
【請求項３】請求項１に記載の方法において、前記ソース・ノードが前記
ネットワークの外側にあり、さらに、前記特定ステップを実行するために前記第
１のノードが前記データを受信することを特徴とする方法。
【請求項４】請求項１に記載の方法において、Ｎが０．５Ｍ以下であるこ
とを特徴とする方法。
【請求項５】請求項４に記載の方法において、プロトコルに従って前記デ
ータがグループに組み立てられ、各グループは、前記宛先ノード用のアドレスを
含むヘッダを有することを特徴とする方法。
【請求項６】請求項５に記載の方法において、前記データはパケットの中
へパケット化され、各パケットは、前記宛先ノード用のアドレスを含むヘッダを
有することを特徴とする方法。
【請求項７】請求項６に記載の方法において、前記ヘッダが、前記宛先ノ
ードへ前記データを伝送するための前記第２の宛先アドレスを含むことを特徴と
する方法。
【請求項８】請求項１に記載の方法において、前記第１の宛先アドレスが
３２ビット・インターネット・プロトコル・アドレスを使用することを特徴とす
る方法。
【請求項９】請求項１に記載の方法において、前記第１の宛先アドレスが
４８ビット媒体アクセス制御アドレスを使用することを特徴とする方法。
【請求項１０】請求項１に記載の方法において、Ｎは１６ビット以下であ
ることを特徴とする方法。
【請求項１１】請求項１に記載の方法において、Ｎは８ビット以下である
ことを特徴とする方法。
【請求項１２】請求項１に記載の方法において、前記第１の宛先アドレス
または前記第２の宛先アドレスのいずれかとして宛先アドレスを特定するための
前記データと関連づけられたアドレス・タイプ・コードを伝送するステップをさ
らに有することを特徴とする方法。
【請求項１３】請求項１２に記載の方法において、前記アドレス・タイプ
・コードがパケットのヘッダ内に位置されることを特徴とする方法。
【請求項１４】請求項１３に記載の方法において、前記パケットの前記ヘ
ッダ内の前記アドレス・タイプ・コードは宛先アドレスに先行することを特徴と
する方法。
【請求項１５】請求項１に記載の方法において、前記第２の宛先アドレス
を特定する前記ステップが、前記第１のノードに位置するルックアップ・テーブ
ルの中で前記第２の宛先アドレスを調べるステップを有することを特徴とする方
法。
【請求項１６】請求項１に記載の方法において、或るイベントを検出するステップと、前記或るイベントを検出するステップに基づいて、前記第２の宛先アドレスを
使用する代わりに前記第１の宛先アドレスを用いて前記ネットワークにおいて前
記宛先ノードへデータを伝送するステップと、をさらに有することを特徴とする
方法。
【請求項１７】請求項１６に記載の方法において、前記或るイベントが、
前記ネットワークにおいてトポロジの変更の検出を含むことを特徴とする方法。
【請求項１８】請求項１に記載の方法において、前記ネットワークで伝送する対象データ用として前記ソース・ノードを指定す
るために、前記ソース・ノードにおいてＭビットの第１のソース・アドレスを生
成するステップと、前記ネットワーク内で前記第１のノードにおいて前記ソース・ノード用として
Ｎビットの第２のソース・アドレスを特定するステップであって、ＮはＭよりも
著しく小さいステップと、前記ソース・ノードを特定するために前記第２のソース・アドレスを使用する
前記データを前記ネットワーク内で伝送して、より少ない数のアドレス・ビット
を伝送することにより前記ネットワークでオーバーヘッドを縮減するようになす
ステップと、をさらに有することを特徴とする方法。
【請求項１９】請求項１８に記載の方法において、前記ソース・ノードと
前記第１のノードとが同じであることを特徴とする方法。
【請求項２０】請求項１に記載の方法において、前記ネットワークのトポロジの変更を前記ネットワークにより検出するステッ
プと、前記ネットワークにおいてＮビット・アドレス・コードを各ノードに割り当て
るステップにおいて、各ノードがＭビットの事前に割り当てられたアドレス・コ
ードも持つステップと、をさらに有することを特徴とする方法。
【請求項２１】請求項２０に記載の方法において、前記割り当てステップ
が各ノードにおいてルックアップ・テーブルを有することを特徴とする方法。
【請求項２２】請求項２０に記載の方法において、前記割り当てステップ
が、伝送用ノードを指定するＭビット・アドレス・コードを前記ネットワーク内の
各ノードにより前記伝送用ノードの少なくとも１つの近傍へ伝送するステップと
、各ノードにより隣接ノードの変更を検出するステップと、変更が検出された場合、前記ネットワーク内でノードにより前記変更をノード
の各々へ伝送するステップと、前記ネットワーク内の各ノードによって、Ｎビット・アドレス・コードを前記
ネットワーク内の少なくともいくつかのノードへ割り当て、前記変更を反映する
ようになすステップと、を有することを特徴とする方法。
【請求項２３】通信ネットワーク内のルーティング・スイッチであって、
前記ネットワークは相互に接続されたルーティング・スイッチを具備し、前記ル
ーティング・スイッチは、前記ネットワークで伝送する対象データ用として宛先ノードを指定するための
Ｍビットの第１の宛先アドレスを生成するステップと、前記宛先ノード用のＮビットの第２の宛先アドレスを特定するステップであっ
て、ＮはＭよりも著しく小さいステップと、前記宛先ノードへ前記データを経路指定するための前記第２の宛先アドレスを
用いて前記データを前記ネットワーク内で伝送して、より少ない数のアドレス・
ビットを伝送することにより前記ネットワークでオーバーヘッドを縮減するよう
になすステップと、を有する方法を実行するように構成される１以上の処理用エ
レメントを持つようになすルーティング・スイッチ。
【請求項２４】請求項２３に記載のルーティング・スイッチにおいて、Ｎ
が０．５Ｍ以下であることを特徴とするルーティング・スイッチ。
【請求項２５】請求項２４に記載のルーティング・スイッチにおいて、プ
ロトコルに従って前記データがグループに組み立てられ、各グループは、前記宛
先ノード用のアドレスを含むヘッダを有することを特徴とするルーティング・ス
イッチ。
【請求項２６】請求項２５に記載のルーティング・スイッチにおいて、前
記データはパケットの中へパケット化され、各パケットは、前記宛先ノード用の
アドレスを含むヘッダを有することを特徴とするルーティング・スイッチ。
【請求項２７】請求項２６に記載のルーティング・スイッチにおいて、前
記ヘッダが、前記宛先ノードへ前記データを伝送するための前記第２の宛先アド
レスを含むことを特徴とするルーティング・スイッチ。
【請求項２８】請求項２３に記載のルーティング・スイッチにおいて、前
記第１の宛先アドレスが３２ビット・インターネット・プロトコル・アドレスを
使用することを特徴とするルーティング・スイッチ。
【請求項２９】請求項２３に記載のルーティング・スイッチにおいて、前
記第１の宛先アドレスが４８ビット媒体アクセス制御アドレスを使用することを
特徴とするルーティング・スイッチ。
【請求項３０】請求項２３に記載のルーティング・スイッチにおいて、Ｎ
は１６ビット以下であることを特徴とするルーティング・スイッチ。
【請求項３１】請求項２３に記載のルーティング・スイッチにおいて、Ｎ
は８ビット以下であることを特徴とするルーティング・スイッチ。
【請求項３２】請求項２３に記載のルーティング・スイッチにおいて、前
記処理用エレメントは、前記第１の宛先アドレスまたは前記第２の宛先アドレスのいずれかとして宛先
アドレスを特定するための前記データと関連づけられたアドレス・タイプ・コー
ドを伝送するステップと、を有する方法を実行するようにさらに構成されること
を特徴とするルーティング・スイッチ。
【請求項３３】請求項３２に記載のルーティング・スイッチにおいて、前
記アドレス・タイプ・コードがパケットのヘッダ内に位置されることを特徴とす
るルーティング・スイッチ。
【請求項３４】請求項３３に記載のルーティング・スイッチにおいて、前
記パケットの前記ヘッダ内の前記アドレス・タイプ・コードは宛先アドレスに先
行することを特徴とするルーティング・スイッチ。
【請求項３５】請求項２３に記載のルーティング・スイッチにおいて、前
記第２の宛先アドレスを特定する前記ステップが、前記第１のノードに位置する
ルックアップ・テーブルの中で前記第２の宛先アドレスを調べるステップを有す
ることを特徴とするルーティング・スイッチ。
【請求項３６】請求項２３に記載のルーティング・スイッチにおいて、前
記処理用エレメントが、或るイベントを検出するステップと、前記或るイベントを検出するステップに基づいて、前記第２の宛先アドレスを
使用する代わりに前記第１の宛先アドレスを用いて前記ネットワークにおいて前
記宛先ノードへデータを伝送するステップと、を有する方法を実行するようにさ
らに構成されることを特徴とするルーティング・スイッチ。
【請求項３７】請求項３６に記載のルーティング・スイッチにおいて、前
記或るイベントが、前記ネットワークにおいてトポロジの変更の検出を有するこ
とを特徴とするルーティング・スイッチ。
【請求項３８】請求項２３に記載のルーティング・スイッチにおいて、前
記処理用エレメントが、前記ネットワークで伝送する対象データ用として前記ソース・ノードを指定す
るために、前記ソース・ノードにおいてＭビットの第１のソース・アドレスを生
成するステップと、前記ネットワーク内で前記第１のノードにおいて前記ソース・ノード用として
Ｎビットの第２のソース・アドレスを特定するステップであって、ＮはＭよりも
著しく小さいステップと、前記ソース・ノードを特定するために前記第２のソース・アドレスを使用する
前記データを前記ネットワーク内で伝送して、より少ない数のアドレス・ビット
を伝送することにより前記ネットワークでオーバーヘッドを縮減するようになす
ステップと、を有する方法を実行するようにさらに構成されることを特徴とする
ルーティング・スイッチ。
【請求項３９】請求項２３に記載のルーティング・スイッチにおいて、前
記処理用エレメントが、前記ネットワークにより前記ネットワークのトポロジの変更を検出するステッ
プと、前記ネットワークにおいてＮビット・アドレス・コードを各ノードに割り当て
るステップにおいて、各ノードがＭビットの事前に割り当てられたアドレス・コ
ードも持つステップと、を有する方法を実行するようにさらに構成されることを
特徴とするルーティング・スイッチ。
【請求項４０】請求項３９に記載のルーティング・スイッチにおいて、前
記割り当てステップが各ノードにおいてルックアップ・テーブルを有することを
特徴とするルーティング・スイッチ。
【請求項４１】請求項３９に記載のルーティング・スイッチにおいて、前
記を割り当てステップが、前記伝送用ノードの少なくとも１つの近傍へ、伝送用ノードを指定するＭビッ
ト・アドレス・コードを前記ネットワーク内の各ノードにより伝送するステップ
と、隣接ノードの変更を各ノードにより検出するステップと、変更が検出された場合、前記ネットワーク内のノードの各々へ前記変更をノー
ドにより伝送するステップと、前記ネットワーク内の少なくともいくつかのノードへ、前記ネットワーク内の
各ノードによりＮビット・アドレス・コードを割り当て、前記変更を反映するよ
うになすステップと、を有することを特徴とするルーティング・スイッチ。
【請求項４２】通信ネットワークにおいて使用するためのルーティング・
スイッチであって、前記ネットワークは通信リンクによって相互に接続されたル
ーティング・スイッチを具備し、前記ルーティング・スイッチは、隣接ノードにおいて１以上の他のルーティング・スイッチと関連するリンクと
接続する１以上の送受信装置と、前記１以上の送受信装置から得られるルーティング情報用のスイッチ構造体と
、１以上のプロセッサであって、前記ルーティング・スイッチを制御して、ネットワーク・トポロジを特定する、他のノードからのメッセージをモニタ
し、従前のメッセージから前記メッセージの変更を検出して、前記トポロジの変
更を特定するようになし、Ｎビットの第２のアドレスを前記ノード内のそれぞれのノードと関連づけ、
前記それぞれのノードも一意的Ｍビットの第１のアドレスを有し、ＮはＭよりも
著しく小さく、前記第１のアドレスの代わりに前記第２のアドレスを用いて前記ネットワー
ク内で前記それぞれのノードへデータを伝送して、より少ない数のアドレス・ビ
ットを伝送することにより前記ネットワークにおいてオーバーヘッドを縮減する
ように構成される前記１以上のプロセッサと、を具備することを特徴とするルー
ティング・スイッチ。
【請求項４３】通信ネットワークにより実行される方法であって、前記ネ
ットワークは、通信リンクによって相互に接続されたノードを具備し、各ノード
をＭビットの第１のアドレスと関連づける方法において、ネットワーク・トポロジを特定するメッセージであって、宛先ノードへ伝送す
るメッセージをモニタするステップと、従前のメッセージから前記メッセージの変更を検出して、前記トポロジの変更
を特定するようになし、Ｎビットの第２のアドレスを前記ノード内のそれぞれのノードと関連づけるス
テップであって、ＮはＭよりも著しく小さいステップと、前記第１のアドレスの代わりに前記第２のアドレスを用いて前記ネットワーク
内で前記それぞれのノードへデータを伝送して、より少ない数のアドレス・ビッ
トを伝送することにより前記ネットワークにおいてオーバーヘッドを縮減するよ
うになすステップと、を有することを特徴とする前記方法。
【請求項４４】通信ネットワークにおいて使用するためのルーティング・
スイッチであって、前記ネットワークは通信リンクによって相互に接続されたル
ーティング・スイッチを具備し、隣接ノードにおいて１以上の他のルーティング・スイッチと関連するリンクと
接続する１以上の送受信装置と、前記１以上の送受信装置から得られるルーティング情報用のスイッチ構造体と
、１以上のプロセッサであって、前記ルーティング・スイッチを制御して、前記隣接ノードの属性を特定する、隣接ノードからのメッセージをモニタし
、従前のメッセージから前記メッセージの変更を検出して、前記ネットワーク
におけるトポロジの変更に対応する、前記隣接ノードの属性の変更を特定するよ
うになし、前記トポロジの前記変更を前記ネットワーク内の他のノードへ伝達する、１以
上のプロセッサと、を具備することを特徴とする前記ルーティング・スイッチ。
【請求項４５】通信ネットワークにより実行される方法であって、前記ネ
ットワークは、相互に接続されたノードを具備するように構成される方法におい
て、隣接ノードからのメッセージであって、前記隣接ノードの属性を特定するメッ
セージを第１のノードによりモニタするステップと、従前のメッセージから前記メッセージの変更を検出して、前記ネットワークに
おけるトポロジの変更に対応する前記隣接ノードの属性の変更を特定するように
なすステップと、前記ネットワーク内の他のノードへ前記トポロジの前記変更を前記第１のノ
ードにより伝達するステップと、を有することを特徴とする前記方法。
【請求項４６】通信ネットワークにおいて使用するためのルーティング・
スイッチであって、前記ネットワークは通信リンクによって相互に接続されたル
ーティング・スイッチを具備し、隣接ノードにおいて１以上の他のルーティング・スイッチと関連するリンクと
接続する１以上の送受信装置と、前記１以上の送受信装置から得られるルーティング情報用のスイッチ構造体と
、１以上のプロセッサであって、前記ルーティング・スイッチを制御して、前記隣接ノードの属性を特定する、隣接ノードからのメッセージをモニタし
、従前のメッセージから前記メッセージの変更を検出して、前記ネットワーク
におけるトポロジの変更に対応する前記隣接ノードの属性の変更を特定するよう
になし、セッションスＩＤを増分するステップであって、各前記セッションＩＤは前
記ネットワークの異なるトポロジと関連づけられ、前記ネットワークの前記トポロジの前記変更を特定する情報と共に、増分さ
れたセッションＩＤを特定することにより、前記ネットワーク内の他のノードへ
前記トポロジの前記変更を伝達する１以上のプロセッサと、を具備することを特
徴とする前記ルーティング・スイッチ。
【請求項４７】請求項４６に記載のルーティング・スイッチにおいて、隣
接ノードからのメッセージをモニタするために前記ルーティング・スイッチを制
御するための前記１以上のプロセッサが、前記隣接ノードの一意的アドレスを検
出するための前記ルーティング・スイッチを制御する前記１以上のプロセッサを
具備することを特徴とするルーティング・スイッチ。
【請求項４８】請求項４６に記載のルーティング・スイッチにおいて、隣
接ノードからのメッセージをモニタするために前記ルーティング・スイッチを制
御するための前記１以上のプロセッサが、リンクの品質を検出するための前記ル
ーティング・スイッチを制御する前記１以上のプロセッサを具備することを特徴
とするルーティング・スイッチ。
【請求項４９】請求項４８に記載のルーティング・スイッチにおいて、ビ
ットエラー比率に基づいて前記リンクの前記品質が決定されることを特徴とする
ルーティング・スイッチ。
【請求項５０】請求項４６に記載のルーティング・スイッチにおいて、受
信された光強度に基づいて前記リンクの前記品質が決定されることを特徴とする
ルーティング・スイッチ。
【請求項５１】請求項４６に記載のルーティング・スイッチにおいて、従
前のメッセージから前記メッセージの変更を検出するために前記ルーティング・
スイッチを制御するための前記１以上のプロセッサが、前記隣接ノードが前記隣
接ノードの以前のアドレスと異なるアドレスを持っていることを検出するために
前記ルーティング・スイッチを制御する前記１以上のプロセッサを具備すること
を特徴とするルーティング・スイッチ。
【請求項５２】請求項４６に記載のルーティング・スイッチにおいて、前
記ルーティング・スイッチを制御するための前記１以上のプロセッサが、前記ネ
ットワークの前記トポロジの変更に基づいてルーティング・テーブル内で前記ル
ーティング・スイッチを更新するために前記ルーティング・スイッチを制御する
ことを特徴とするルーティング・スイッチ。
【請求項５３】請求項４６に記載のルーティング・スイッチにおいて、前
記トポロジの前記変更が上記ネットワークにおけるノードの追加または削除を含
むことを特徴とするルーティング・スイッチ。
【請求項５４】請求項４６に記載のルーティング・スイッチにおいて、前
記ルーティング・スイッチを制御するための前記１以上のプロセッサが、前記セ
ッションＩＤの変更の受信時に前記隣接ノードの状態に関する情報をメモリの中
に格納するための前記ルーティング・スイッチを制御することを特徴とするルー
ティング・スイッチ。
【請求項５５】請求項５４に記載のルーティング・スイッチにおいて、時
間の閾値期間に対して上記トポロジが安定した後にのみ、前記隣接ノードの状態
に関する前記情報が新しい状態情報と置き換えられることを特徴とするルーティ
ング・スイッチ。
【請求項５６】通信ネットワークにおいて使用するための１つのルーティ
ング・スイッチであって、前記ネットワークは通信リンクによって相互に接続さ
れた複数のルーティング・スイッチを具備し、前記１つのルーティング・スイッ
チは、隣接ノードにおいて１以上の他のルーティング・スイッチと関連するリンクと
接続する１以上の送受信装置と、前記１以上の送受信装置から得られるルーティング情報用のスイッチ構造体と
、１以上のプロセッサであって、前記ルーティング・スイッチを制御して、前記ネットワークのトポロジに関連するメッセージを前記ネットワーク内の
他のノードから検出し、前記メッセージはセッションＩＤを含み、各前記セッシ
ョンＩＤは前記ネットワークの異なるトポロジと関連づけられ、変更されたセッションＩＤを検出することにより前記トポロジの変更を検出
し、前記セッション番号が変った場合、前記トポロジの変更に基づいて前記ルー
ティング・テーブルを改訂する、１以上のプロセッサを具備することを特徴とす
るルーティング・スイッチ。
【請求項５７】通信ネットワークにより実行される方法であって、前記ネ
ットワークは、通信リンクによって相互に接続されたノードを具備する方法にお
いて、前記隣接ノードの属性を特定する、隣接ノードからのメッセージを各ノードに
よりモニタするステップと、従前のメッセージから前記メッセージの変更を第１のノードにより検出して、
前記ネットワークにおけるトポロジの変更に対応する前記隣接ノードの属性の変
更を特定するようになすステップと、セッションスＩＤを増分するステップであって、各前記セッションＩＤは前記
ネットワークの異なるトポロジと関連づけられるステップと、前記ネットワークの前記トポロジの前記変更を特定する情報と共に、増分され
たセッションＩＤを特定することにより、前記ネットワーク内の他のノードへ前
記トポロジの前記変更を伝達するステップと、を有することを特徴とする方法
。