(57)【要約】本発明は、異種ネットワーク、特に、ＩＳ−ＩＳルーティングドメインにおける自動トンネリングに関する。好ましい実施例によれば、ＣＬＮＰ、ＩＰｖ４或いはＩＰｖ６のような互換性のないネットワークレイヤプロトコルをサポートするネットワークノードが、例えば、ＩＳ−ＩＳレベル−１エリア或いはレベル−２サブドメインのような単一のルーティングドメインに存在することを可能にさせるルーティング装置が得られる。ルーティング装置は、ルーティングドメイン内の全てのノードがＩＳ−ＩＳ若しくは統合ＩＳ−ＩＳルーティングプロトコルをサポートする場合に、ノードが必要に応じて別のネットワークレイヤプロトコルを超えて一つのネットワークレイヤプロトコルを自動的にトンネルすることを可能にさせる。ルーティング装置は、必ずしもデータパケットをその宛先ノードへルーティングをしようとするとは限らず、必要に応じて、宛先ノードへのパス内のノードへトンネルでデータパケットを送信する。
2004515165.tif 000002
【特許請求の範囲】
【請求項１】
各ノードが一つ以上のプロトコルの複数のセットのうちの一つ以上のセットをサポートするように構成されている複数のノードを含むネットワークにおいてデータパケットのルーティングを行う装置であって、
使用時に、第１のプロトコルセット及び一つ以上の他のプロトコルセットをサポートする第１のネットワークノードに収容され、
該第１のネットワークノードで該第１のプロトコルセットに適合したデータパケットを受信したとき、該受信したデータパケットが該第１のネットワークノードへ向けられているかどうかを判定するように構成され、
更に、該受信したデータパケットが該第１のネットワークノードへ向けられていないと判定したとき、データパケットの宛先ノードへのパス内で、該第１のプロトコルセット及び少なくとも一つの該他のプロトコルセットをサポートする第２のネットワークノードを識別するように構成され、
該データパケットを、該少なくとも一つの他のプロトコルセットに適合し、かつ、該第２のネットワークノードに対応した宛先アドレスを有するデータパケット内にカプセル化し、カプセル化されたデータパケットを該第２のネットワークノードへ転送させるように構成されている、
装置。
【請求項２】
宛先ノードへのパス内で近隣ネットワークノードによってサポートされているプロトコルセットを判定することにより、該少なくとも一つの他のプロトコルセットを選択するように構成されている、請求項１記載の装置。
【請求項３】
当該装置は近接ネットワークノードによってサポートされている第２のプロトコルセットを識別するように構成され、
該第２のプロトコルセットは該第１のネットワークノードによってサポートされている該一つ以上のほかのプロトコルセットに収容され、
当該装置は、該第２のネットワークノードとして、宛先ノードへのパス内で該第１のプロトコルセット及び該第２のプロトコルセットをサポートするネットワークノードを選択するように構成されている、
請求項２記載の装置。
【請求項４】
該受信したデータパケットが該第１のネットワークノードへ向けられていることを判定したとき、当該装置は、該受信したデータパケットが該第１のプロトコルセット内にカプセル化された別のプロトコルセットに適合したデータを収容しているかどうかを判定し、収容していると判定されたとき、該受信したデータパケットのカプセルを解くように構成され、
当該装置は、更に、カプセルを解かれたデータパケットが該第１のネットワークノードに向けられているかどうかを検査するように構成されている、
請求項１記載の装置。
【請求項５】
各プロトコルセットはネットワークレイヤプロトコルを含む、請求項１乃至４のうち何れか一項記載の装置。
【請求項６】
該プロトコルセットは、ＯＳＩプロトコルとＩＰプロトコルのうちの少なくとも一方を含む、請求項１乃至５のうち何れか一項記載の装置。
【請求項７】
該ＯＳＩプロトコルは、ＣＬＮＳ（コネクションレス・モード・ネットワーク・サービス）及びＣＬＮＰ（コネクションレス・モード・ネットワーク・プロトコル）を含み、
該ＩＰプロトコルは、ＩＰｖ４とＩＰｖ６のうちの少なくとも一方を含む、
請求項６記載の装置。
【請求項８】
ネットワーク内の各近隣ノードに関して情報を集めるように構成され、
この情報は、対応した近隣ノードによってサポートされているプロトコルセットの識別情報を含む、
請求項１乃至７のうち何れか一項記載の装置。
【請求項９】
該情報は、各近隣ノードによって使用時に分散させられた対応したルーティング用データパケットに含まれる情報を検査することにより集められる、請求項８記載の装置。
【請求項１０】
当該装置は、ネットワーク内の他のノード毎に、該他のノードへのパス内で、該他のノードと共通した少なくとも二つのプロトコルセットをサポートする一つ以上のネットワークノードを識別する情報を集めるように更に構成され、
該第２のネットワークノードは、該一つ以上のネットワークノードから選択される、
請求項１乃至９のうち何れか一項記載の装置。
【請求項１１】
該他のノードへの対応したパスは、ルーティングアルゴリズムによって判定されるような最短パスである、請求項１０記載の装置。
【請求項１２】
該第２のネットワークノードとして、宛先ノードへのパス内で、次の、又は、最近接の適切なネットワークノードを選択するように構成されている、請求項１０又は１１記載の装置。
【請求項１３】
各ネットワークノードによって、使用時に、分散させられたルーティング用データパケットに格納されている情報を評価することにより、該情報を集めるように構成されている、請求項１０乃至１２のうち何れか一項記載の装置。
【請求項１４】
請求項１乃至１３のうち何れか一項記載の装置を含むネットワークノード。
【請求項１５】
当該ネットワークノードは一つ以上のリンク状態プロトコルをサポートするように構成され、
該ルーティング用データパケットはリンク状態パケットを含む、
請求項１４記載のネットワークノード。
【請求項１６】
当該ネットワークはＩＳ−ＩＳプロトコルをサポートするように構成され、
リンク状態パケットはＩＳ−ＩＳのＨｅｌｌｏパケットを含む、
請求項１５記載のネットワークノード。
【請求項１７】
当該ネットワークは、ＩＳ−ＩＳプロトコルと統合ＩＳ−ＩＳプロトコルのうちの少なくとも一方をサポートするように構成され、
リンク状態パケットはリンク状態ＰＤＵ（プロトコル・データ・ユニット）（ＬＳＰ）を含む、
請求項１６記載のネットワークノード。
【請求項１８】
該情報は、統合ＩＳ−ＩＳのＬＳＰのサポートプロトコル・フィールドから集められる、請求項１７記載のネットワークノード。
【請求項１９】
該ルーティング用データパケットは、ルーティング用データパケットを送出する対応したネットワークノードのデータトンネリング能力を識別する情報を伝達するように構成されている、請求項１４乃至１８のうち何れか一項記載のネットワークノード。
【請求項２０】
ネットワーク内の各ノードは、対応したルーティング用データパケットで、ネットワークノードのトンネリング能力に応じて、一つ以上のダミーネットワークノードへの近隣性を示すように構成されている、請求項１９記載のネットワークノード。
【請求項２１】
ネットワーク内の他のノード毎に集められた情報を記憶する手段を更に有する請求項１４乃至２０のうち何れか一項記載のネットワークノード。
【請求項２２】
該記憶する手段は、ＩＳ−ＩＳ及び統合ＩＳ−ＩＳによって提供されるＰＡＴＨＳデータベースを含む、請求項２１記載のネットワークノード。
【請求項２３】
ルーティングを行う装置は、ネットワーク内の他のノード毎に、一つ以上の適切な第２のネットワークノードの対応した識別子を該記憶する手段に記憶するように構成されている、請求項２１又は２２記載のネットワークノード。
【請求項２４】
ルーティングを行う装置は、ネットワークノードと対応した他のネットワークノードによって共通してサポートされているプロトコルセットの各対に関して、適切な第２のネットワークノードの対応した識別子を記憶するように構成されている、請求項２３記載のネットワークノード。
【請求項２５】
当該ネットワークノードは、他のネットワークノードへの対応したパス内で次の、又は、最近接である適切な第２のネットワークノードの識別子を記憶するように構成されている、請求項２３又は２４記載のネットワークノード。
【請求項２６】
レベル−１のルータとして動作するように構成されている、請求項１４乃至２５のうち何れか一項記載のネットワークノード。
【請求項２７】
レベル−２のルータとして動作するように構成されている、請求項１４乃至２６のうち何れか一項記載のネットワークノード。
【請求項２８】
請求項１４乃至２７のうち何れか一項記載のネットワークノードを含むネットワーク。
【請求項２９】
各ノードが一つ以上のプロトコルの複数のセットのうちの一つ以上のセットをサポートするように構成されている複数のノードを含むネットワークにおいてデータパケットのルーティングを行う方法であって、
第１のプロトコルセット及び一つ以上の他のプロトコルセットをサポートし、装置が収容されている第１のネットワークノードで、該第１のプロトコルセットに適合したデータパケットを受信し、
受信したデータパケットが該第１のネットワークノードへ向けられているかどうかを判定し、
該受信したデータパケットが該第１のネットワークノードへ向けられていないと判定されたとき、該データパケットの宛先ノードへのパス内で、該第１のプロトコルセット及び少なくとも一つの該他のプロトコルセットをサポートする第２のネットワークノードを識別し、
該少なくとも一つの他のプロトコルセットに適合し、かつ、該第２のネットワークノードに対応した宛先アドレスを有するデータパケット内に該データパケットをカプセル化し、
該カプセル化されたデータパケットを該第２のネットワークノードへ転送する、
方法。
【請求項３０】
ネットワークノードに請求項２９記載の方法を実施させるコンピュータ使用可能命令を含むコンピュータプログラム。
【請求項３１】
請求項１乃至１３のうち何れか一項記載の装置を全部若しくは部分的に実施するためのコンピュータ使用可能な命令を含むコンピュータプログラム。
【発明の詳細な説明】
【０００１】
〔発明の分野〕
本発明は、異種ネットワークにおけるデータパケットのルーティングに関する。特に、本発明は、異種ネットワーク、特に、ＩＳ−ＩＳルーティングドメインにおける自動トンネリングに関する。
【０００２】
〔背景〕
統合ＩＳ−ＩＳ（中間システム間）ルーティングプロトコルは、
ＩＰ（インターネット・プロトコル）トラフィック、並びに、ＯＳＩ（オープン・システム・インターコネクション）トラフィックをルーティングすることができるようにＩＳ−ＩＳルーティングプロトコルの拡張として発明された。
【０００３】
統合中間システムは、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｃｃ１１９５．ｔｘｔから入手できるＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）標準ＲＦＣ１１９５に記載されている。ＩＳ−ＩＳは、ｈｔｔｐ：／／ｗｗｗ．ｉｓｏ．ｃｈから入手できるＩＳＯ（国際標準化機構）１０５８９に記載されている。
【０００４】
統合ＩＳ−ＩＳは、ＩＰバージョン６（ＩＰｖ６）をルーティングするためにも拡張されている。この拡張は、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｉｓｉｓ−ｉｐｖ６−０１．ｔｅｘｔ、及び、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｉｓｉｓ−ｉｐｖ６−０２．ｔｅｘｔの公開文書に記載されている。更に、ＩＳ−ＩＳから派生したものが、デジタル・イクイップメント社のＤＥＣｎｅｔ　フェーズ　Ｖプロトコルをルーティングするため使用される。
【０００５】
統合ＩＳ−ＩＳは、通常、ＩＳＩ若しくはＩＰプロトコルに同時に適合するデータパケットをルーティングするため使用されるが、以下の規則に拘束される。
【０００６】
ＲＦＣ１１９５からの抜粋：「二重ルータがＩＰパケットをＯＳＩ専用ルータへ転送するか、若しくは、ＯＳＩパケットをＩＰ専用ルータへ転送しなければならないときが起こり得る。その場合、パケットは廃棄しなければならない。」、並びに、「同様に、エラーに起因して、ある種の場合に、ＩＰ専用ルータはＩＰパケットをＯＳＩ専用ルータへ転送しなければならない。パケットは、上述のように廃棄しなければならない。このような状況は、ＩＰ専用ルータとＯＳＩ専用ルータが同じエリアに出現するというコンフィギュレーション上のエラーの場合に限り起こり得る。」。
【０００７】
即ち、ＩＰ専用ルータ及びＯＳＩ専用ルータは、同じＩＳ−ＩＳレベル−１ネットワークエリア、若しくは、同じレベル−２サブドメインに現れることが許可されない。この理由のため、ＲＦＣ１１９５［１］は、統合ＩＳ−ＩＳによってルーティングされるネットワークに、全てのノードがＩＳＩトラフィック及びＯＳＩトラフィックの両方が存在するエリアにおいてＩＰネットワークレイヤプロトコルとＯＳＩネットワークレイヤプロトコルの両方をサポートしなければならない、という位相的な制約を課す。その結果として、ＲＦＣ１１９５［１］によれば、一つのノードがＩＰをサポートするためアップグレードされた場合、レベル−１エリア若しくはレベル−２サブドメインの全ての他のノードもアップグレードしなければならない。
【０００８】
ＩＰデータパケットを超えてＯＳＩデータパケットのトンネルを行ない、逆に、ＯＳＩデータパケットを超えてＩＰデータパケットのトンネルを行う製品が市販されている。これらの製品は、トンネルの手動設定（コンフィギュレーション）に頼っており、同じＩＳ−ＩＳエリア若しくはサブドメインに出現するＩＰ専用ルータとＯＳＩ専用ルータに関する上記の規則を破ることがない。更に、手動設定は、多数の規定を必要とするので、望ましくないと考えられる。
【０００９】
また、従来のトンネリング技術の場合、トンネルは、通常、所与のデータパケットの宛先にアドレス指定される端点若しくは宛先ノードへ向けてセットアップされる。しかし、この技術は、トンネルの出発点と宛先ノードの間の全てのネットワークノードが少なくとも一つの共通したプロトコルをサポートする場合に限り巧く作用する。さもなければ、トンネリングされたデータパケットは、宛先ノードへ到着する前に廃棄される。したがって、従来のトンネリング技術を異種ネットワークに適用しようとした場合、即ち、ネットワークノードが必ずしも同じプロトコルをサポートしないので、ネットワークが少なくとも一つの共通したプロトコルをサポートするとは限らないネットワークに適用しようとした場合に問題が生ずる。
【００１０】
ＩＰｖ６を通過してＩＰｖ４のトンネルを行う方法も存在するが、これらの方法は、ＩＰｖ４互換のＩＰｖ６アドレスを使用すること、若しくは、ＩＰｖ４アドレスをＩＰｖ６プリフィックス内に埋め込むことに基づいている。しかし、本発明は、これらの制限に基づいていない。
【００１１】
尚、用語「ルータ」は、データルータとして動作するように構成されたネットワーク素子、或いは、ネットワークノード（又は、それらの一部）を包含することを意図して使用されている。
【００１２】
更に、用語「プロトコル」は、セット（若しくはスタック）は１個以上のプロトコルを含む場合に、プロトコルセット、又は、プロトコルスタックを包含することを意図して使用されている。例えば、ＯＳＩ及びＩＰの各々は、対応したプロトコルのセットにより構成されていると考えられるが、以下の説明では、ＯＳＩプロトコル、或いは、ＩＰプロトコルのように指定される。
【００１３】
本発明は、ＯＳＩプロトコル及びＩＰプロトコルに関連しているが、これらに限られることはなく、対応したＩＳＯ標準及びＲＦＣ標準は、夫々、ｗｗｗ．ｉｓｏ．ｃｈ及びｗｗｗ．ｉｅｔｆ．ｏｒｇから入手され、以下の用語が使用される。ＩＰ専用ノードは、本来的に、ＯＳＩパケットではなく、特に、ＯＳＩネットワークレイヤプロトコルであるＣＬＮＰ（コネクションレス・モード・ネットワーク・プロトコル）パケットではなく、ＩＰパケットのルーティングを行うノードである。ＣＬＮＰは、ＣＬＮＳ（コネクションレス・モード・ネットワーク・サービス）を行うため使用されるデータパケット若しくはＰＤＵ（プロトコル・データ・ユニット）のタイプに与えられた名前である。ＣＬＮＳは、ＯＳＩプロトコルスタックのネットワークレイヤによってスタックの上位レイヤへ提供されるサービスである。ＣＬＮＳサービスを準備することによって、ＣＬＮＰパケット若しくはＰＤＵは、スタックの下位レイヤへ渡される。ＯＳＩ専用ノードは、本来的に、ＩＰパケットではなく、ＯＳＩパケット、特に、ＣＬＮＰパケットのルーティングを行うノードである。ＩＰ可能ノードは、ＩＰパケットのルーティングを行うことが可能であり、ＯＳＩパケットのルーティングを行うことが可能であるかもしれないノードである。ＯＳＩ可能ノードは、ＯＳＩパケットのルーティングを行うことが可能であり、ＩＰパケットのルーティングを行うことが可能であるか、若しくは、可能ではないノードである。二重ノード、即ち、二種併用型ノードは、本来的に、二つのプロトコル、特に、二つのネットワークレイヤプロトコルのうちの一方若しくは両方のルーティングを行うことができるノードである。この用語は、ＣＬＮＳ／ＣＬＮＰとＩＰｖ４の両方のルーティングを行うノード、又は、ＩＰｖ４とＩＰｖ６の両方のルーティングを行うノードの何れかのノードを指定するため使用される。多種併用型ノードは、本来的に、二つ以上のプロトコル、特に、二つ以上のネットワークレイヤプロトコルのうちの一つ若しくは多数のプロトコルのルーティングを行うことができるノードである。
【００１４】
近隣ネットワークノードは、到達可能な近傍ノードである。用語「近隣性（ａｄｊａｃｅｎｃｙ）」は、ＩＳＯ／ＩＥＣ　１０５８９のセクション３．６．３に規定され、以下の説明では、到達可能な近傍ノードを示すため使用される。物理的な近傍ノードは、必ずしも有効な近隣性があるとは限らない。なぜならば、物理的な近傍ノードは、異なるネットワークエリア又は異なるネットワークレベルに収容されているかもしれないからである。かくして、近隣性は、物理的な近傍ノードではノード間で維持される。
【００１５】
〔発明の概要〕
本発明の第１の局面によれば、各ノードが一つ以上のプロトコルの複数のセットのうちの一つ以上のセットをサポートするように構成されている複数のノードを含むネットワークにおいてデータパケットのルーティングを行う装置が提供される。この装置は、使用時に、第１のプロトコルセット及び一つ以上の他のプロトコルセットをサポートする第１のネットワークノードに収容され、この装置は、第１のネットワークノードで第１のプロトコルセットに適合したデータパケットを受信したとき、受信したデータパケットが第１のネットワークノードへ向けられているかどうかを判定するように構成され、更に、この装置は、受信したデータパケットが第１のネットワークノードへ向けられていないと判定したとき、データパケットの宛先ノードへのパス内で、第１のプロトコルセット及び少なくとも一つの他のプロトコルセットをサポートする第２のネットワークノードを識別するように構成され、この装置は、データパケットを、上記少なくとも一つの他のプロトコルセットに適合し、かつ、第２のノードに対応した宛先アドレスを有するデータパケット内にカプセル化し、カプセル化されたデータパケットを第２のネットワークノードへ転送させるように構成されている。
【００１６】
第１のネットワークノードと第２のネットワークノードの間の任意の他のネットワークノードは、カプセル化によって作成されたデータチャネルをサポートする少なくとも一つの他のプロトコルセットをサポートするように構成されている。
【００１７】
好ましくは、各プロトコルセットは、ネットワークレイヤプロトコルを含む。この場合、装置は、主として、元のデータパケットが適合するネットワークレイヤプロトコル、及び、第１のノードによってサポートされる更なるネットワークレイヤプロトコルをサポートするノードを、第２のノードとして識別する、
好ましい実施例において、プロトコルセットは、ＣＬＮＳ及びＣＬＮＰのようなＯＳＩプロトコルと、ＩＰｖ４及び／又はＩＰｖ６のようなＩＰプロトコルのうちの一方若しくは両方を含む。
【００１８】
好ましくは、他のノードへの各パスは、ＳＰＦ（ショーティスト・パス・ファースト（最短パス優先））ルーティングアルゴリズムのようなルーティングアルゴリズムによって決定されるような最短パスである。
【００１９】
好ましくは、装置は、宛先ノードへのパス内で次の、若しくは、最近接の適切なネットワークノードを、第２のネットワークノードとして選択するように構成される。
【００２０】
本発明の第２の局面によれば、本発明の第１の局面による装置を含むネットワークノードが提供される。
【００２１】
好ましい実施例において、ネットワークノードは、ＩＳ−ＩＳ及び／又は統合ＩＳ−ＩＳのような一つ以上のリンク状態プロトコルをサポートするように構成される。
【００２２】
他の実施例では、ネットワークノードは、データパケットが発生した夫々のネットワークノードのデータトンネリング能力を識別する情報を伝達するルーティングデータパケットを分散させるように構成される。この構成は、統合ＩＳ−ＩＳを含むリンク状態プロトコルと共に使用する方が有利であり、その場合、フィールドは、ＩＳ−ＩＳ　ＬＰＳにＴＬＶ符号化可変長フィールドを含むのが好都合であり、ＯＳＰＦ（オープン・ショーティスト・パス・ファースト）と共に使用する方が有利であり、その場合、フィールドは、ＯＳＰＦ　ＬＳＡ（リンク状態広告）に収容される。トンネリング能力情報は、ネットワークノードがデータトンネルを終端させ得るかどうか、ネットワークノードによってサポートされているトンネリングプロトコルの種類、及び、上記トンネルにカプセル化されるプロトコルを含む。或いは、上記のトンネリング能力情報は、上記データパケットによって間接的に伝達される。例えば、データトンネリング能力を備えた各ネットワークノードは、当該ネットワークノードが、データトンネリング能力に依存して一つ以上のダミーネットワークアドレスに対し近隣性を有することを示すデータパケットを、好都合なことには、ＬＳＰ若しくはＬＤＡを生成するように構成され、ここで、一つ以上の各ダミーアドレスは、対応したトンネリング能力を表すために使用される。
【００２３】
更に別の実施例では、ネットワーク内の各ノードは、対応したネットワークノードのトンネリング能力に応じて、夫々のルーティングデータパケットで、一つ以上のダミーネットワークノードへの近隣性を示すように構成される。
【００２４】
好ましい実施例によれば、ネットワークノードは、レベル−１ルータ、及び／又は、レベル−２ルータの機能を果たすように構成される。
【００２５】
本発明の第３の局面によれば、本発明の第２の局面による一つ以上のネットワークノードを含むネットワークが提供される。
【００２６】
本発明の第４の局面によれば、各ノードが一つ以上のプロトコルの複数のセットのうちの一つ以上のセットをサポートするように構成されている複数のノードを含むネットワークにおいてデータパケットのルーティングを行う方法が提供される。この方法は、第１のプロトコルセット及び一つ以上の他のプロトコルセットをサポートし、装置が収容されている第１のネットワークノードで、第１のプロトコルセットに適合したデータパケットを受信し、受信したデータパケットが第１のネットワークノードへ向けられているかどうかを判定し、受信したデータパケットが第１のネットワークノードへ向けられていないと判定されたとき、データパケットの宛先ノードへのパス内で、第１のプロトコルセット及び少なくとも一つの他のプロトコルセットをサポートする第２のネットワークノードを識別し、データパケットを、少なくとも一つの他のプロトコルセットに適合し、かつ、第２のノードに対応した宛先アドレスを有するデータパケット内にカプセル化し、カプセル化されたデータパケットを第２のネットワークノードへ転送する。
【００２７】
本発明の第５の局面によれば、ネットワークノードに本発明の第４の局面による方法を実施させるコンピュータ使用可能命令を含むコンピュータプログラムが提供される。
【００２８】
本発明の第６の局面によれば、本発明の第５の局面の装置を、全部若しくは一部だけ実施するコンピュータプログラムが提供される。
【００２９】
本発明の好ましい特徴は、従属した請求項に記載されている。
【００３０】
好ましい実施例によれば、本発明は、ＣＬＮＰ、ＩＰｖ４、又は、ＩＰｖ６のような異種の互換性のないネットワークレイヤプロトコルのルーティングをサポートするノードが、例えば、ＩＳ−ＩＳレベル−１エリア若しくはレベル−２サブドメインのような単一のルーティングドメインに存在することを可能にさせ、ルーティングドメインの全てのノードがＩＳ−ＩＳ及び／又は統合ＩＳ−ＩＳルーティングプロトコルをサポートするならば、必要に応じて一つのネットワークレイヤプロトコルを別のプロトコルを介して自動的にトンネルさせるノードを提供する。これにより、特に、ＩＰｖ４専用、ＩＰｖ６専用、及び、ＯＳＩ専用のルータが同じＩＳ−ＩＳのレベル−１のエリア若しくはレベル−２のドメインで使用できるようになり、ここで、統合ＩＳ−ＩＳは、ネットワーク中のルートを計算するため使用される。
【００３１】
本発明は、ＩＰ専用若しくはＯＳＩ専用ルータの複雑さに影響を与えないが、多種併用型ルータ、特に、二重、二種併用型、若しくは、三種併用型ルータに機能性を追加する。
【００３２】
本発明によれば、二種併用型若しくは多種併用型ルータは、該当するパケットタイプをサポートしないネットワークの一部分を介して、データパケットを、元のデータパケットを再生し、最終的な宛先へ転送することができる別の二種併用型若しくは多種併用型ルータへ自動的かつ動的に転送するように構成される。本発明によるデータパケットの転送は、ルータが必要に応じて他のルータへのトンネルをセットアップし、トンネルが常時存在するわけではないという点で動的であるといってよい。更に、二つのルータ間のトンネルは、各機会におけるネットワークの状態に依存して、連続的な機会に異なるパスに沿ってセットアップされることがある。
【００３３】
注目すべきことは、二種併用型、若しくは、多種併用型ルータは、必ずしも、データパケットを宛先ノードへルーティングしようとしない。むしろ、二種併用型、若しくは、多種併用型ルータは、宛先ノードへのパスに沿って、受信データパケットのプロトコルをサポートし、二種併用型若しくは多種併用型ルータ自体と共通した別のプロトコルをサポートする第２のルータ（好ましくは、次、若しくは、最近接のルータ）を識別するように構成される。二種併用型若しくは多種併用型ルータは、上記の別のプロトコルを使用して、データパケットを識別された第２のルータへトンネルさせる。
【００３４】
必要な場合に限りトンネルをセットアップすることにより、二種併用型若しくは多種併用型ルータは、宛先ノードへの完全なパスを知る必要がなくなり、主要な関心事は、トンネルをカプセルから出すことができる最近接ネットワークノードへのパスである。かくして、宛先ノードへのパス内の各ノードが共通プロトコルをサポートしないかどうかは問題にならない。
【００３５】
以下の本発明の好ましい実施例の説明から明らかであるように、ＳＰＦ（最短パス優先）のような従来のＩＳ−ＩＳルータ用のルーティングアルゴリズムは、上記の第２のノードを識別し、かつ、トンネルをセットアップ可能であるかどうかを検査し、データパケットをカプセル化し、第２のノードへ転送させるため、容易に修正することが可能である。アルゴリズムがこの最近接ノードを発見するために必要な情報は、好都合なことに、Ｈｅｌｌｏパケット及びＬＳＰパケットのような従来の統合ＩＳ−ＩＳルーティングデータパケットに含まれている。
【００３６】
本発明は、ＯＳＩとＩＰのノード若しくはネットワークを混合するとき、或いは、ＯＳＩとＩＰの間で移動する場合に特に有益である。本発明は、特に、ＩＰｖ４とＩＰｖ６の間で移動する場合に有益である。本発明は、ＩＳ−ＩＳエリア内の全ルータがエリア内に存在する全てのプロトコルをサポートしなければならない、というＲＦＣ１１９５で認知されている弱点を緩和する。本発明は、互換性のないノードの向こう側へデータパケットをトンネルさせることができる。データパケットは、宛先へ向けて移動するときに、多数のデータトンネルを出入りしてもよく、或いは、トンネル内で更にトンネルしてもよい。
【００３７】
本発明は、ネットワークノードが自分で、宛先ノードへのパス内で、トンネルをセットアップするために適切である更なる（好ましくは、最近接、若しくは、次の）二種併用型若しくは多種併用型ノードを判定し、必要に応じてトンネルをセットアップするという点で、自動トンネリングを提供する。ノードは、相互のネットワークノードによってネットワーク全域に流されたルーティングデータパケット（特に、ＬＳＰ）で受信された情報を評価することにより、自動トンネリングを達成する。
【００３８】
本発明の他の局面は、以下の具体的な実施例の説明と添付図面を参照することによって、当業者に明白になるであろう。
【００３９】
〔詳細な説明〕
最初に図１を参照すると、複数のネットワークノード又はネットワーク素子（図１において１から９の番号が付されている）を含むネットワーク１０、又は、ルーティングドメインが示されている。ネットワークノードは、ネットワーク１０の全域でデータパケット（図示せず）のルーティングを行うように構成されている。各ネットワークノードは、マルチプレクサ若しくはクロスコネクトのような１台以上のネットワーク機器を含むが、ネットワーク１０においてデータパケットのルーティングが行えるようにするルーティング装置を備えている。本発明は、特に、データパケットのルーティングに関係するので、ノード（１から９）、特に、ノードに収容されたルーティング装置を、ルータと呼ぶ。以下の説明から明らかになるように、ルータは、一体として、レベル１のＩＳ−ＩＳネットワークエリア、又は、レベル−２のサブドメインを形成し、或いは、二つ以上のレベル１のネットワークエリアに分離される。例示の目的のため、以下の説明では、ネットワーク１０は、レベル１のネットワークエリアであると考える。
【００４０】
ネットワーク１０は、ネットワーク１０の各ルータが必ずしも共通プロトコル、特に、ＣＬＮＰ（ＩＳＯ８４７３−４を参照のこと）、ＩＰｖ４（ＲＦＣ７９１を参照のこと）、又は、ＩＰｖ６（ＲＦＣ２４６０を参照のこと）のようなネットワークレイヤプロトコルをサポートしない、という点で異種であると考えられる。
【００４１】
本発明は、ルータ１、２、３、８及び９が、プロトコルＡを実行する標準的なＩＳ−ＩＳ若しくは統合ＩＳ−ＩＳルータであるとする。ここで、Ａは、例えば、ＯＳＩ、ＩＰｖ４、ＩＰｖ６、又は、ＩＳ−ＩＳ若しくは統合ＩＳ−ＩＳを使用するその他のプロトコルの中の何れのプロトコルでもよい。
【００４２】
ルータ５及び６は、プロトコルＢを実行する標準的なＩＳ−ＩＳ若しくは統合ＩＳ−ＩＳルータであるとする。ここで、Ｂは、ＯＳＩ、ＩＰｖ４、ＩＰｖ６、又は、ＩＳ−ＩＳ若しくは統合ＩＳ−ＩＳを使用するその他のプロトコルの中でＡとは異なるプロトコルである。
【００４３】
ルータ４及び７は、統合ＩＳ−ＩＳを実行し、かつ、ＡとＢの両方のプロトコルのルーティングを行うことができる二種併用型、即ち、二重ルータであるとする。
【００４４】
本発明によれば、ルータ４及び７は、ネットワークノードとその動作の一部分を例示する図２及び３を参照して説明される以下の新規な動きを示す。特に、図２及び３は、データパケットのルーティングに関するノードの一部分、即ち、ルーティング装置を示している。
【００４５】
ルータ４が、例えば、ルータ２若しくは３から、タイプＡのパケット（即ち、プロトコルＡに適合したデータパケット）を受信したとき、ルータ４は、データパケットがルータ４自体に向けられているかどうか、或いは、パケットを転送すべきであるかどうかを判定する（図２のブロック２０）。ルータ４が、データパケットは転送すべきであると判定した場合、ルータ４は、従来通りに、パケットの宛先アドレス（即ち、ルータ８若しくは８である宛先ノードのアドレス）を調べ、パケットの送信先の近隣若しくは近傍ネットワークノードを転送テーブル（図２のブロック２４、２６、２８の転送データベース）内で探すように整えられる。
【００４６】
図２に示されているように、ルータは、サポートしている各プロトコルに関して、対応した転送テーブル２４、２６、２８、又は、データベースを含む。本例の場合、ルータ４は、プロトコルＡ用とプロトコルＢ用の２個の転送テーブル２４及び２６を保持する。第３の転送テーブル２８は、第３のプロトコル、即ち、プロトコルＣをサポートするノードによって必要とされる。ここで、Ｃは、ＯＳＩ、ＩＰｖ４、ＩＰｖ６、又は、ＩＳ−ＩＳ若しくは統合ＩＳ−ＩＳを使用するその他のプロトコルの中の異なるプロトコルである。
【００４７】
ルータ４は、データパケットがどのタイプ（Ａ、Ｂ又はＣ）のパケットであるかを判定し得ることが必要であり、そのため、ルータ４は、プロトコルを識別する従来のプロトコル判別モジュール２２を具備する。尚、この時点でのデータパケットは、他の一つ以上のプロトコル内にカプセル化された一つのプロトコルを備えていても、備えていなくてもよく、プロトコル弁別器２２は、最外層のカプセル化用プロトコルがどのプロトコルであるかを判定する必要がある。
【００４８】
データパケットのプロトコル（本例では、プロトコルＡ）が確定された後、ルータ４は、確定されたプロトコルに相応しい転送テーブル（本例の場合には、テーブル２４）を参照する。パケットを次のホップ（即ち、選択された近隣若しくは近傍ルータ）へ送信する前に、ルータ４は、次のホップがパケットをルーティングすることができるか、又は、パケットを処理することができるかを検査するよう整えられる。都合よく、ルータ４は、近傍ルータ若しくは近接からのＨｅｌｌｏパケットを調べることによって、特に、次のホップがタイプＡのプロトコルをサポートするかどうかを確定するため、Ｈｅｌｌｏパケット内の「サポートプロトコル」のフィールドを調べることによって（図３のブロック３０）、この検査を行う。このため、ルータ４は、近傍ノード若しくは近隣がサポートするプロトコルのリストを格納するテーブル、データベース、又は、他の記憶手段（図３のブロック３２）を含み、テーブル３２は、近傍若しくは近隣から受信したＨｅｌｌｏパケットに収容された情報を使用して作成され、更新される。Ｈｅｌｌｏパケットが、「サポートプロトコル」のフィールドを持たない場合、好ましい実施例によれば、ルータは、当該近傍ノードがＯＳＩ専用ルータである、とみなす。Ｈｅｌｌｏパケットは、従来のＩＳ−ＩＳルーティングプロトコルに従って、各ノード若しくはルータによって、近傍ノードへ分散される標準的なルーティングデータパケットである。或いは、ルータは、各ノードによってネットワーク全域に分散された他のルーティングデータパケットで伝達される情報を検査することにより、サポートされているプロトコルに関する情報を収集することが可能である。例えば、統合ＩＳ−ＩＳに従ってノードによって分散されたリンク状態（ステート）ＰＤＵ（ＬＳＰ）は、「サポートプロトコル」のフィールドを含み、この目的のため使用される。
【００４９】
次のホップがプロトコルＡをサポートしない場合、ルータ４は、従来通りに、データトンネリングを用いること無く、データパケットを次のホップへ転送する（図３のブロック３３）。
【００５０】
次のホップがプロトコルＡをサポートしないが、プロトコルＢをサポートする場合（図３のブロック３４）、ルータ４は、非限定的な例として、ＧＲＥ（ＲＦＣ１７０１（ＲＦＣ２７８４へ更新）、ＲＦＣ１７０２及びＲＦＣ３１４７に記載されている汎用ルーティング・カプセル化）のようなタイプＡの元のパケットをタイプＢの新しいパケット内にカプセル化するように整えられる（図３のステップ３５）。新しいカプセル化用パケットは、本例の場合、プロトコルＢ（典型的にはネットワークレイヤプロトコル）に適合し、元のデータパケットをカプセル化するため、宛先アドレスと送信元アドレスとを含む。新しいパケットのネットワークレイヤプロトコルは、次のホップから受信されたＨｅｌｌｏ（若しくは他の）ＰＤＵの「サポートプロトコル」ＴＬＶによって規定されるように、次のホップによってサポートされるプロトコルである。新しいパケットの宛先アドレスは、元の宛先への最短パスに沿った次のノードのアイデンティティ（識別情報）に対応し、この次のノードは、元のパケットが適合するネットワークレイヤプロトコルと、（次のホップから受信したＨｅｌｌｏ　ＰＤＵの「サポートプロトコル」ＴＬＶにより定義されるように）新しいホップによってサポートされているネットワークレイヤプロトコルの両方のタイプをサポートする（図３のブロック４２）。好ましくは、これは、宛先へのパス内の全てのノードから受信したＬＳＰの「サポートプロトコル」ＴＬＶを検査し、上述の要件を満たす最初のノードを識別することによって達成される。新しいパケットの送信元アドレスは、新しいカプセル化パケットを構築するノードのアイデンティティと一致する。
【００５１】
尚、一つのパケットを別のパケット内にカプセル化すると、新しいパケットが得られ、この新しいパケットのサイズは、新しいパケットを転送するために使用するリンクのＭＴＵ（最大伝送単位）サイズよりも短い。新しいカプセル化パケット（例えば、ＲＦＣ１７０２若しくはＲＦＣ３４１７を使用してカプセル化されたパケット）は廃棄してはならないので、パケットは、ＩＰパケットである場合には、「フラグメント化禁止」ビットがセットされるべきではなく、ＣＬＮＰパケットである場合には、「セグメンテーション許可」フラグがセットされるべきである。得られたカプセル化パケットは、そのパケットの長さがリンクのＭＴＵ限界よりも長い場合には、転送前にフラグメント化される。
【００５２】
ルータ４が同時にプロトコルＣをサポートする場合、ルータ４は、ブロック３６へ進み、近隣がプロトコルＣをサポートするかどうかを検査する（これは、ルータ４がプロトコルＢをサポートしない場合、又は、近隣がプロトコルＢをサポートしないと判定された場合の何れかの場合に行われる。）。近隣がプロトコルＡ、Ｂ又はＣをサポートしない場合、エラーが通知される（ブロック３７）。
【００５３】
本例では、ルータ４が、宛先ノードへのパス上の次のホップ、若しくは、近隣（例えば、ノード６）が（プロトコルＡではなく）プロトコルＢをサポートする場合、（好ましい実施例によれば）ルータ４は、パス内で、プロトコルＡとプロトコルＢの両方をサポートする第１の、即ち、最近接若しくは次のネットワークノード（本例では、例えば、ルータ７）を識別する。ルータ４は、タイプＡのデータパケットをプロトコルＢ内にカプセル化し、ルータ７へ送信することによって、互換性のない近隣（ルータ６）を通過させてタイプＡのデータパケットのトンネリングを行うことが可能である。これが可能である理由は、ルータ７が二種併用型であり、データパケット（Ａ）のプロトコルをサポートし、ルータ４と共通したプロトコル、即ち、プロトコルＢを更にサポートするからである。ルータ７は、従って、トンネルを解くことが可能である。尚、互換性のない近隣（ルータ６）は、トンネルを伝達することができるように、上記の付加的な共通にサポートされているプロトコル（本例の場合、プロトコルＢ）をサポートしなければならない。
【００５４】
したがって、ルータ４は、宛先ノードへのパス上で次の適切な二種併用型ルータを識別することが必要である。これは、ＩＳＯ　１０５８９標準及びＲＦＣ　１１９５標準に記載されているＳＰＦ（最短パス優先）ルーティングアルゴリズムに関して後述するように、ルータ４によって実行されるルーティングアルゴリズムを修正することによって実現される。
【００５５】
ルータ４がＩＳ−ＩＳによって典型的に使用されるＳＰＦアルゴリズムを実行するとき、ルータ４は、本発明による特別な新規の機能を実行する。
【００５６】
ネットワークノード、又は、ルータがＳＰＦを実行するとき、ネットワークノードは、ネットワークの全域で他の各ネットワークノードへの考え得るあらゆるパスを検査し、そのネットワークノードへの最適パス、即ち、最短パスを決定する。ネットワークノードは、各ネットワークノードによってネットワークの全域に流され、かつ、ＩＳ−ＩＳ及び統合ＩＳ−ＩＳに従って各ネットワークノードによって収集されたリンク状態ＰＤＳ（ＬＰＳ）に格納されている情報を評価することによって、最短パスを決定する。最短パスが識別されたとき、ルータは、最短パスを用いて所与の宛先ノードへ到達するため、データパケットが送信されるべき近傍ノード、若しくは、近隣の識別情報を、一般的にＰＡＴＨＳとして知られているデータベースに格納する。典型的に、ＰＡＴＨＳデータベースには各ネットワークノードのためのエントリーが設けられ、各エントリーは、当該ノードの識別子と、適切な近隣の識別子と、コスト（メトリック）の識別子と荷より構成される。
【００５７】
本発明によれば、ルータ４が計算若しくは評価するあらゆるパス毎に、ルータ４は、プロトコルＡとプロトコルＢの両方のプロトコルをサポートするパスに沿って別のルータを探すように構成される。ルータ４は、パスに沿った各ルータから受信した対応したＬＳＰを調べることによって、別のルータを探索することができる。ＬＳＰが「サポートプロトコル」フィールドを含む場合、そのフィールドは、そのＬＳＰを送信したルータがサポートするプロトコルを示す。好ましい実施例によれば、ルータは、パス内で最初の（即ち、次の、若しくは、最近接の）適切なルータを探す。
【００５８】
（通常の形式のＳＰＦアルゴリズムによって決定されるような）各最短パスに対して、ルータ４は、パスに沿ってプロトコルＡとプロトコルＢの両方のプロトコルをサポートする最初のルータの識別情報を記憶するように構成される。この情報を記憶するために好都合の場所は、ＲＦＣ　１１９５及びＩＳＯ　１０５８９に規定されているようにＰＡＴＨＳデータベースの中であり、この情報を記憶するため、例えば、付加的なフィールドが当該ノード（ルータ）のためのエントリーに追加され、このフィールドは、最初の、即ち、次の、二種併用型若しくは多種併用型ルータの識別子を含む。
【００５９】
ルータ４は、プロトコルＡとプロトコルＢの両方の形式で表現された宛先アドレスの形式で、上記の次の二種併用型若しくは多種併用型ルータの識別情報を記憶してもよく、或いは、ルータ４は、その識別情報を唯一のフォーマットで記憶してもよく、若しくは、他のフォーマットで記憶し、フォーマットＡ若しくはフォーマットＢの宛先アドレスを獲得するため、必要に応じて別の変換テーブル（図示せず）を使用してもよい。好ましい解決法は、プロトコルＡ及びＢをサポートする最初のルータ、プロトコルＡ及びＣをサポートする最初のルータ、並びに、プロトコルＢ及びＣをサポートする最初のルータを識別し、それらを統合ＩＳ−ＩＳ　ＳＰＦ計算で使用されるフォーマットの識別子として表現するため、必要な個数の付加的な列若しくはフィールドをＰＡＴＨＳデータベースに追加することである。これは、付加的な列の個数がルータによってサポートされるプロトコルの個数に依存していることを意味する。例えば、ＡとＢをサポートするパスに沿った最初のルータがプロトコルＣもサポートする場合、そのルータの識別情報は、ＰＡＴＨＳデータベースのＡ−Ｂ列と、Ａ−Ｃ列と、Ｂ−Ｃ列に現れる。プロトコルＡとプロトコルＢだけをサポートするルータ４の場合、ＰＡＴＨＳデータベースは、ＡとＢをサポートする次のルータを識別するための付加的なフィールドだけが必要であり、Ａ−Ｃに対するフィールド内のエントリーは不要である。なぜならば、ルータ４は、Ｃをサポートしていないからである。ルータは、サポートしていないプロトコルに関係する受信ＬＳＰ内の情報を無視するように都合よく構成される。
【００６０】
好ましい実施例によれば、二種併用型若しくは多種併用型の各ルータは、ネットワーク内の他のノードへの最短パスに関して、情報を集め、（都合よくＰＡＴＨＳデータベースに）記憶する。この情報は、最短パスにおいて、当該ルータと共通の少なくとも二つのプロトコルをサポートする次の二種併用型若しくは多種併用型のルータを識別する。ルータが３種以上のプロトコルをサポートする場合、ルータは、サポートする各プロトコルに関して、サポートする他のプロトコルと対にされた識別情報を記憶する。例えば、ルータがプロトコルＡ、Ｂ及びＣをサポートする場合、ルータは、最短パス毎に、Ａ及びＢをサポートする次のノード、Ａ及びＣをサポートする次のノード、並びに、Ｂ及びＣをサポートする次のノードを識別する情報を記憶する。ネットワークの構造に依存するので、各パスに各タイプが一つずつ存在するとは限らないことは明らかである。
【００６１】
尚、ルータ若しくはノードは、必ずしも、カプセル化されたデータパケットを、宛先ノードへのパス内の最初の、若しくは、次の適切なノードに転送しなくてもよい。例えば、次の適切なノードが輻輳している場合、ルータは、カプセル化されたデータパケットを、宛先ノードへのパス上の別の適切なネットワークへ転送することを選択してもよい。このように、ルータは、好ましくは、宛先ノードへのパス上で、このルータと共通した少なくとも２個のプロトコルをサポートする一つ以上の他のノードを識別する情報を、ＰＡＴＨＳデータベースに都合よく格納するように構成される。
【００６２】
ＬＳＰ、修正ＳＰＦアルゴリズム、及び、修正ＰＡＴＨＳデータベースは、夫々、図３にブロック３８、ブロック３９及びブロック４０によって表現されている。尚、次の適切な二種併用型若しくは多種併用型ルータを識別する情報は、必ずしもＰＡＴＨＳデータベースに格納しなくてもよく、他の都合のよい記憶手段に格納しても構わない。更に、ルータは、サポートしている個別のプロトコルに対して、別個の転送テーブル（図示せず）、又は、等価的な記憶手段を具備しても構わない。これにより、ある宛先に関して１個の特定のプロトコル用の転送テーブルに自動的に出現するトンネルインタフェースを得ることができ、これに対し、異なる全ての宛先に関して別のプロトコル用の転送テーブルに、異なるトンネルインタフェースが出現するか、或いは、トンネルインタフェースが出現しない可能性がある。
【００６３】
再度、図３の特にブロック４１を参照すると、ルータ４は、ＡとＢの両方のプロトコルをサポートするパスに沿って次のルータの識別情報を判定するため、修正若しくは拡張ＰＡＴＨＳデータベースを調べるように整えられている。次のルータの識別情報が判定されたとき、ルータ４は、次のルータのアドレスを、Ｂタイプの次のパケットの宛先アドレスとして使用し（図３のブロック４２）、その後、カプセル化されたデータパケットを次のホップへ送信する（図３のブロック３３）。上述の通り、ルータは、第１のテーブル（ＰＡＴＨＳデータベース）で表現されたルータの識別情報をＢタイプのプロトコルに適切な宛先アドレスを表現するフォーマットに変換するため、別のテーブルを参照しなければならない。
【００６４】
図３のブロック４３を参照すると、好ましい一実施例によれば、ルータは、Ａ及びＢをサポートするパスに実際に次のノードが存在するかどうかを検査し、次のノードが存在しない場合、近隣がプロトコルＣをサポートするかどうかを検査する（図３のブロック３６）。これは、ルータ４がプロトコルＣをサポートする場合に、ルータ４のための関連したオプションに過ぎない。
【００６５】
図３において、プロトコルＡ及びＣのためのブロック４５、４６、４７及び４８は、プロトコルＡ及びＢのためのブロック４３、３５、４２及び４１と対応している。
【００６６】
同様に、図４及び５は、実質的に図３と対応しているが、図４及び５は、受信データパケットがＢタイプである場合、及び、Ｃタイプである場合に夫々対応している。
【００６７】
ルータ７、又は、２個以上のプロトコルをサポートするＩＳ−ＩＳエリア（若しくは、レベル−２のサブドメイン）内の他のルータは、逆方向に、或いは、同様の方式で前方へパケットを送信するため同様の機能を備えている。
【００６８】
本例の場合、ルータ４は、ルータ８若しくはルータ９の何れかのためのパスに沿って、プロトコルＡとプロトコルＢの両方をサポートする次のルータとしてルータ７を識別する。したがって、ルータ４と関連したＰＡＴＨＳデータベースにおいて、ルータ８用とルータ９用の対応したエントリーは、個別にフィールドを含み、そのフィールドで、ルータ７は、次の適切な二種併用型ルータとして識別されている。
【００６９】
ルータ４は、ルータ８若しくはルータ９へ向けられたＡタイプのパケットを、宛先アドレスとしてルータ７の識別情報がセットされたＢタイプの新しいパケット内にカプセル化して送信する。
【００７０】
ルータ７は、これらのカプセル化パケットを受信し、以下の新規の動きを行うように構成されている。
【００７１】
ルータ７は、宛先アドレスとしてルータ７がセットされた着信パケットを検査或いは調査する（尚、この宛先アドレスは、図３のブロック４２でルータ４によってセットされるような宛先アドレスであり、元のデータパケットの最終的な宛先ノードのアドレスと一致している必要はない。）。ルータ７に向けられたパケットであるかどうかは、図２のブロック２０で判定される。このデータパケットがルータ７へアドレス指定されている場合、ルータ７は、このデータパケットがカプセル化された別のデータパケットを格納しているかどうかを調べる（図２のブロック２１）。別のデータパケットが格納されている場合、ルータ７は、従来通りの方法で内部のパケットのカプセルを解き（図２のブロック２３）、ルータ７によって受信された直後のパケットと同じように、カプセルを解かれたパケットを再処理する（図２のブロック２０）。別のデータパケットが格納されていない場合、ルータ７は、このデータパケットを、従来通りの方法で、例外パケットとして取り扱う（図２のブロック２５）。
【００７２】
このようにして、ルータ８若しくは９へ向けられ、Ｂタイプのパケットの内部にカプセル化されたデータパケットは、ルータ７によってカプセルから取り出され、処理され、通常のＡタイプのパケットとして転送される。
【００７３】
ルータ４、又は、２個以上のプロトコルをサポートするＩＳ−ＩＳエリア（若しくは、レベル−２のサブドメイン）内の他のルータは、逆方向にデータパケットを受信するための同様の機能を備えている。
【００７４】
図２乃至５に例示され、記述されているように、本発明の好ましい実施例は、ルーティング装置として説明され、特に、ＳＰＦアルゴリズム及びＰＡＴＨＳデータベースの修正によって都合よく実現される。以下では、このルーティング装置の実現方法の一例を説明する。ＳＰＦアルゴリズムの一部分として、各ノードは、あらゆる宛先ノードに対して一つ以上のパスを識別し、対応したパスエントリーをＴＥＮＴテーブルと呼ばれるテーブル若しくはデータベースに保持する。宛先ノード毎に、ＴＥＮＴのパスエントリーはＰＡＴＨＳのエントリーと比較される。これらの二つのパスのうちの最短パスに対応したエントリーは、ＰＡＴＨＳに収容され、最長パスは削除される。ＴＥＮＴが空であるとき、ＳＰＦアルゴリズムは終了である。この段階で、あらゆる宛先ノードは、ＰＡＴＨＳ内に対応したエントリーが設けられ、このエントリーはノードから宛先ノードまでの完全な最短パスを記述する。尚、２本以上のパスに同じコストがかかることがわかっている場合、ＰＡＴＨＳは、宛先ノードに対する二つ以上の最短パスエントリーでも構わない。
【００７５】
通常、ノードの後の各パス内の最初のＳＩＤ（システム識別子）は、次のホップであるため、各宛先ノード用の転送テーブル（ＩＰアドレスへのパスである場合には、ＩＰ転送テーブル、ＯＳＩ　Ｅｎｄシステムへのパスの場合には、ＯＳＩ転送テーブル）に取り込まれる。
【００７６】
本発明を実施するため、アルゴリズムは、ＰＡＴＨＳ内の最終エントリー毎に全てのノードに沿ってジャンプし、パス毎に、パスに沿って各ノードのＬＳＰを獲得し、ノードが、（当該ノードから受信したＩＳ−ＩＳ　Ｈｅｌｌｏ　ＰＤＵ（若しくはＬＳＰ）に存在する「サポートプロトコル」ＴＬＶに規定されているように）宛先アドレスであるタイプのネットワークレイヤプロトコルと、次のホップによってサポートされているタイプのネットワークレイヤプロトコルの両方をサポートするかどうかを検査するように修正される。この要件を満たすことが判明したパスに沿った最初のノードは、最終的な宛先への最短パスに沿った次の二重ノードとして選択される。この要件を満たすパスに沿って最初のノードが検出された後、処理は、そのパスのため停止する。
【００７７】
この付加的な処理が必要になるのは、次のホップがそのパスの宛先アドレスに対応するタイプのネットワークレイヤプロトコルをサポートしないときに限られる。次のホップが（当該ノードから受信したＩＳ−ＩＳ　Ｈｅｌｌｏ　ＰＤＵ（又はＬＳＰ）に存在する「サポートプロトコル」ＴＬＶに規定されているように）そのタイプのネットワークレイヤプロトコルをサポートしない場合、その宛先へのパケットは、本来的に転送され、放っておくだけでよく、そのパスに沿って次の二重ノードを探索することは必要ではない。
【００７８】
このアルゴリズムは、パスの宛先アドレスがＯＳＩ　Ｅｎｄシステムである場合に、次の二重ノードのＩＰアドレスを識別するように構成され、パスの宛先アドレスがＩＰアドレスである場合には、この次の二重ノードのＯＳＩアドレスを識別しなければならない。
【００７９】
次のホップを超えるためにカプセル化を要求するＩＰ宛先毎に、ノードは、ＩＰ転送テーブルにマークを付けることが可能である。このマークは、そのアドレスへ向けられた全てのＩＰパケットをカプセル化するため使用しなければならないＯＳＩ宛先アドレスを示すマークである。
【００８０】
次のホップを超えるためにカプセル化を要求するＯＳＩ宛先毎に、ノードは、ＯＳＩ転送テーブルにマークを付けることが可能である。このマークは、そのアドレスへ向けられた全てのＯＳＩパケットをカプセル化するため使用しなければならないＩＰ宛先アドレスを示すマークである。
【００８１】
ＩＰｖ４、ＩＰｖ６及びＯＳＩをサポートするノードは、カプセル化のため使用できる２個のアドレス（例えば、ＩＰｖ４アドレスとＩＰｖ６アドレス）を見つける。この場合、ノードは、（当該ノードから受信したＩＳ−ＩＳ　Ｈｅｌｌｏ　ＰＤＵ（ＬＳＰ）に存在する「サポートプロトコル」ＴＬＶに指定されているように）次のホップがサポートするネットワークレイヤプロトコルのタイプのパケットが得られる限り、どちらのアドレスを選定してもよい。
【００８２】
好ましい実施例において、ネットワーク１０及びネットワークノードは、ＩＳ−ＩＳ並びに統合ＩＳ−ＩＳに適合するため以下の特徴を示す。
【００８３】
ＯＳＩ専用ノードはＩＳＯ／ＩＥＣ　１０５８９に適合し、ＩＰ専用ノードはＲＦＣ　１１９５に適合する。
【００８４】
レベル−１のルーティングを実行するＩＳ−ＩＳルータ又は統合ＩＳ−ＩＳルータは、その固有のＩＳ−ＩＳエリアの外部の他のルータからのＬＳＰを知ることができない。したがって、レベル−１及びレベル−２のルータとして動くルータは、そのＩＳ−ＩＳエリアに存在する全てのネットワークレイヤプロトコルをサポートしなければならない。このことは、このような境界の両側のルータに当てはまる。好ましい実施例によれば、二種併用型若しくは多種併用型ルータは、転送を要求するデータパケットのプロトコル及び動的トンネルを与えるプロトコルをサポートするパスに沿って最初のルータを見つけ、トンネリングを要求する全てのパケットをそのルータへ送信するので、このメカニズムによって生じる動的トンネルは、レベル−１とレベル−２のルーティングをサポートするルータを過ぎて延びることを保証することができる。したがって、レベル−１のエリアとレベル−２のサブドメインの間の境界を通過する他のパケットをカプセル化するパケットは存在しない。したがって、レベル−１のＬＳＰがエリア境界を通過しないことは問題にならない。また、レベル−２のＬＳＰがレベル−２のサブドメインの外へ出ないことも問題にならない。
【００８５】
統合ＩＳ−ＩＳを動かし、２個以上のプロトコル（特に、２個以上のネットワークレイヤプロトコル）をサポートするＩＳ−ＩＳエリア内の全てのルータは、ルータ４及びルータ７の例に関して説明したように、本発明を導入することが要求される。
【００８６】
レベル−２のドメインでは、全てのルータが存在する全てのネットワークレイヤプロトコルをサポートするか、又は、２個以上のプロトコル（特に、２個以上のネットワークレイヤプロトコル）をサポートする全てのルータが本発明を導入することが要求される。
【００８７】
データパケットの損失を防止するため、ルータは、共通したプロトコル、特に、ネットワークレイヤプロトコルを一つもサポートしていない他のルータに直結されるべきではない。即ち、例えば、ＯＳＩ専用ルータは、ＩＰ専用ルータに直接的に接続されるべきではない。ＯＳＩ専用ルータとＩＰ専用ルータの間でデータパスが要求される場合、二種併用型若しくは多種併用型のＩＰルータ及びＯＳＩルータがＯＳＩ専用ルータとＩＰ専用ルータの間に取り付けられるべきである。ＬＡＮ（ローカル・エリア・ネットワーク）は直接的な接続である。ＬＡＮにＩＰ専用ノードとＯＳＩ専用ノードの両方が存在しない場合、ＩＰ専用ノードは、ＯＳＩ専用ノードとの近隣性を形成すべきでない。このため、ＬＡＮ上で２個の別々の疑似ノード選択処理が行われる。ＬＡＮ上の二種併用型（二重ノード）（即ち、ＯＳＩ及びＩＰ）ルータは、両方の疑似ノード選択処理に参加することが可能である。ＯＳＩ専用ルータとＩＰ専用ルータが直接的に連結されないことを保証する一つの方法は、それらのルータが、別々のレイヤ−２のプロトコル、例えば、ＯＳＩ専用ルータ用のＬＡＰＤ（リンク・アクセス・プロシージャＤ）と、ＩＰ専用ルータ用のＰＰＰ（ポイント・ツー・ポイント・プロトコル）で動作するように設定することである。この場合、二種併用型又は多種併用型のルータは、ＬＡＰＤとＰＰＰの両方を実行するように設定される。或いは、各統合ＩＳ−ＩＳノードは、その近傍ノードが、そのノード自体がサポートするネットワークレイヤプロトコルをサポートするかどうかを検査するように要求される。近傍ノードとの間に共通したネットワークレイヤプロトコルが存在しない場合、ノードは近隣性を拒絶する。
【００８８】
好ましい実施例において、本発明を導入しているノードは、近傍ノードから受信したＨｅｌｌｏ　ＰＤＵ（若しくはＬＳＰ）の「サポートププロトコル」を検査するように構成され、そのノード自体がサポートするネットワークレイヤプロトコルがリストアップされない場合、ノードは近隣性を拒絶する。
【００８９】
ＲＦＣ　１１９５に適合し、本発明を導入していないノードは、以下の制約条件の下で、混合したレベル−１のエリア又はレベル−２のサブドメインで使用される。１個のネットワークレイヤプロトコルだけをサポートし、本発明と適合しない統合ＩＳ−ＩＳノードは、レベル−１のエリア又はレベル−２のサブドメインで使用し続けてもよいが、このようなノードは、このノードがサポートしていないパケットをこのノードへ転送する可能性のある他のノードと近隣性を持たないことが保証されるべきである。これは、例えば、ネットワーク管理者（図示せず）によって手動で行われ、或いは、ネットワークノード自体によって自動的に行われる。例えば、一部のＲＦＣ　１１９５準拠式ルータは、不適切な近隣性を拒絶するように構成されている。
【００９０】
２個以上のネットワークレイヤプロトコルをサポートし、本発明と適合しない統合ＩＳ−ＩＳノード（又は、ノードのクラスタ）は、近隣ノードの全てが同じネットワークレイヤプロトコルを共通してサポートする場合、２個以上のネットワークレイヤプロトコルの中の一つだけをサポートする他のノードとの近隣性だけを持つとき、レベル−１のエリア又はレベル−２のサブドメインで使用され続けることがある。２個以上のネットワークレイヤプロトコルをサポートし、本発明と適合しない統合ＩＳ−ＩＳノード（又は、ノードのクラスタ）は、本発明に適合した全ての近隣で他の二重ノードによって囲まれたとき、レベル−１のエリア又はレベル−２のサブドメインで使用され続けることがある。
【００９１】
ルータは、Ａ、Ｂ及びＣの三種のプロトコルをサポートすることが可能である。
【００９２】
このようなルータは、プロトコルＣをサポートする他のルータに直結されていない場合でも、Ａを通過するＣのトンネル、Ｂを通過するＣのトンネルを終端することが可能である。ルータは、ネットワーク内で、一方の方向でＡタイプをサポートする他のルータへ接続され、別の方向でＢタイプをサポートする他のルータへ接続されている場所に置かれることがある。この場合、ルータは、このルータがタイプＡ、Ｂ及びＣをサポートしていることをタイプＡの他のルータに広告し、タイプＡ、Ｂ及びＣをサポートしていることをタイプＢのルータに広告する。本例の場合、このルータは、タイプＡ内にカプセル化されたタイプＣのパケットを含む動的トンネルを終端し、タイプＣのパケットの前方へのルーティングを行うことが可能である。ルータは、タイプＣのパケットをもう一度カプセル化することもあるが、今回は、タイプＢのパケット内にカプセル化する。
【００９３】
この状況は図６の例に示されている。
【００９４】
ネットワーク１は、プロトコルＣだけをサポートするルータのネットワークである。ネットワーク２は、プロトコルＡだけをサポートするルータのネットワークである。ネットワーク３は、プロトコルＢだけをサポートするルータのネットワークである。同図に示されるように、ルータ５１、５２及び５３は、ネットワーク１、２、３及び４の間の境界上にある二種併用型若しくは多種併用型のルータである。
【００９５】
ルータ５１がプロトコルＡ及びＣをサポートし、ルータ５２がプロトコルＡ、Ｂ及びＣをサポートし、ルータ５３がプロトコルＢ及びＣをサポートする場合、ルータ５１は、ルータ５２からＬＳＰを受信し、ルータ５２がプロトコルＡ及びＣをルーティングする能力を備えていることを認識する。ルータ５３は、ルータ５２からＬＳＰを受信し、ルータ５２がプロトコルＡ、Ｂ及びＣをルーティングする能力を備えていることを認識する。
【００９６】
ネットワーク１内のノードがプロトコルタイプＣのパケットをネットワーク４内のノードへ送信したいとき、ネットワークのレイアウトによって、ルータ５１を介してパケットを送信するように強制される。ルータ５１は、最短パスに沿ってプロトコルＡ及びＣをサポートする次のルータを探す。このようにして、ルータ５１はルータ５２を見つける。ルータ５１は、プロトコルタイプＣのパケットを、プロトコルタイプＡのパケットの内部にカプセル化し、それをルータ５２へ送信する。
【００９７】
ルータ５２は、プロトコルタイプＡのパケットを受信し、その内部を調べ、他の場所が宛先とされているプロトコルタイプＣの別のパケットを見つける。
【００９８】
ルータ５２は、Ｃタイプの直接的なコネクションを具備していないにもかかわらず、プロトコルタイプＣのパケットをルーティングする能力を備えているので、プロトコルタイプＣのパケットのルーティングを行う。
【００９９】
ルータ５２は、最短パスに沿ってＢ及びＣをサポートする次のルータを探す。ルータ５２はルータ５３を見つける。ルータ５２は、プロトコルタイプＣのパケットをプロトコルタイプＢのパケットの内部にカプセル化し、ルータ５３へ送信する。ルータ５３は、プロトコルタイプＢのパケットを受信し、その内部を調べ、他の場所が宛先とされているプロトコルタイプＣの別のパケットを見つける。
【０１００】
ルータ５３は、次に、プロトコルタイプＣの元のパケットを、プロトコルＣをサポートしているネットワーク４へ転送する。プロトコルタイプＣの元のパケットは通常の方法で宛先ノードに到達する。
【０１０１】
別のシナリオの場合、ルータ５１はプロトコルＡ及びＣをサポートし、ルータ５２はプロトコルＡ及びＢをサポートし、ルータ５３はプロトコルＡ、Ｂ及びＣをサポートするルータである。
【０１０２】
ネットワーク１内のノードがプロトコルタイプＣのパケットをネットワーク４内のノードへ送信したいとき、ネットワークのレイアウトによって、ルータ５１を介してパケットを送信するように強制される。ルータ５１は、最短パスに沿って、プロトコルＡ及びＣをサポートする次のルータを探す。ルータ５１はルータ５３を見つける。ルータ５１は、プロトコルタイプＣのパケットを、プロトコルタイプＡのパケットの内部にカプセル化し、それをルータ５３へ送信する。
【０１０３】
ネットワークレイアウトの制約のため、内部にＣタイプのパケットを含むＡタイプのパケットは、ルータ５２に到達する。
【０１０４】
パケットの宛先アドレスは、ルータ５２ではなく、ルータ５３にセットされているので、ルータ５２は、他のＡタイプのパケットと同じように、パケットの内部を調べること無く、パケットを前方へ転送する。ルータ５２は、最短パスに沿ってＡ及びＢをサポートする次のルータを探す。ルータ５２はルータ５３を見つける。ルータ５２は、プロトコルタイプＡのパケットをプロトコルタイプＢのパケットの内部にカプセル化し、それをルータ５３へ送信する。ルータ５３は、プロトコルタイプＢのパケットを受信し、その内部を調べ、ルータ５３が宛先とされているプロトコルタイプＡの別のパケットを見つける。
【０１０５】
ルータ５３は、プロトコルタイプＡのパケットの内部を調べ、他の場所が宛先とされているプロトコルタイプＣの別のパケットを見つける。
【０１０６】
ルータ５３は、次に、プロトコルタイプＣの元のパケットを、プロトコルＣをサポートしているネットワーク４へ転送する。プロトコルタイプＣの元のパケットは通常の方法で宛先ノードに到達する。
【０１０７】
次に、図７を参照して、一例として、トラフィック（データパケット）が異種ネットワークにおいて、ＩＳ−ＩＳエリアの間の境界を渡る状況を説明する。
【０１０８】
ルータ８１、８２、８３及び８４は、プロトコルＡだけをサポートすることにする。
【０１０９】
ルータ７１、７２、７３、７４、９１及び９２は、プロトコルＢだけをサポートすることにする。
【０１１０】
ルータ６１、６２、６３、６４、６５及び６６は、プロトコルＡ及びＢの両方をサポートすることにする。
【０１１１】
ルータ６２、６３、６４及び６５は、レベル−１のルータ及びレベル−２のルータとして動作するように構成される。
【０１１２】
ルータ６２、６３、６４及び６５は、ルータ６２、６３、６４、６５、９１及び９２により形成されたレベル−２のサブドメインを越えてＩＳ−ＩＳエリア１とＩＳ−ＩＳエリア２を一体的に連結するため、通常のＩＳ−ＩＳの場合と同じように、レベル−１のルーティングとレベル−２のルーティングを行うことが要求される。
【０１１３】
上記の要件によれば、ルータ６２、６３、６４及び６５は、レベル−１のルータであり、かつ、レベル−２のルータであるため、ＩＳ−ＩＳエリアに存在する全てのプロトコルをサポートすることが要求される。
【０１１４】
ルータ８１がプロトコルＡのパケットをルータ８３へ送信する場合、このパケットはルータ６１を通過しなければならない。
【０１１５】
ルータ６１は、ルータ７１とルータ７２がどちらもプロトコルＡをサポートしていないことを判定するので、Ｂタイプのパケット内部にカプセル化されたパケットを前方のネットワークへ送信することを強制される。
【０１１６】
ルータ６１は、プロトコルＡとプロトコルＢの両方をサポートするルータを見つけるまで、最短パスに沿って探索する。ルータ６２若しくはルータ６３の何れかが必ず見つけられる。本例の目的のため、ルータ６２が最短パス上にあることにする。
【０１１７】
ルータ６２は、カプセル化されたパケットを受信し、カプセルを取外し、Ａタイプの元のパケットを再生する。
【０１１８】
上記の要件に従って、レベル−１とレベル−２の全てのルータは、ＩＳ−ＩＳエリアに存在する全てのプロトコルのルーティングを行えることが必要である。したがって、ルータ６１とルータ６２の両方は、プロトコルＡとＢの両方をサポートしなければならない。
【０１１９】
これにより、上述のように、パケットがルータ６１若しくは６２に到着したとき、全てのカプセル化が解かれることが保証される。
【０１２０】
ルータ６２は、ＩＳ−ＩＳエリア２内にあるレベル−２のルータへの最短パスを見つける。これは、ルータ９１を経由したルータ６４である。ルータ９１はプロトコルＡをサポートしないので、ルータ６２は、パスに沿って、プロトコルＡをサポートする次のルータを探す。ルータ６２は、ルータ９１がルーティングを行えるＢタイプのパケット内にカプセル化されたパケットをルータ６４へ送信する。
【０１２１】
ルータ６４は、カプセル化されたパケットを受信し、元のＡタイプのパケットをカプセルから取り出す。ルータ６４は、パケットをルータ８３へ向かう前方のエリアへ送信する。ルータ６４は、プロトコルＡをサポートしていないルータ７３を通過させるためパケットをカプセル化する。
【０１２２】
尚、ルータがレベル−１のルータとしての機能を果たすとき、ルータは、レベル−１のタイプのＬＳＰを生成し、分散するように構成される。これに対して、レベル−２のルータとしての機能を果たすルータは、レベル−２のＬＳＰを生成し、分散するように構成される。
【０１２３】
上述の実施例において、ルータは、ネットワーク内の他のルータによってサポートされているプロトコルを判定するため、統合ＩＳ−ＩＳ（ＲＦＣ　１１９５）に従って生成されたＬＳＰの「サポートプロトコル」フィールドを使用する。この方式は都合がよい。なぜならば、「サポートプロトコル」フィールドは、通常、統合ＩＳ−ＩＳのＬＳＰに収容され、標準的なＬＳＰに修正を加える必要がないからである。しかし、このアプローチが巧く機能するためには、前提として、ルータが「サポートプロトコル」フィールドを用いて、例えば、プロトコルＡとＢをサポートし得ることを広告した場合、ルータは、プロトコルＢ内にカプセル化されたプロトコルＡにより構成されたデータトンネルと、反対にプロトコルＡ内にカプセル化されたプロトコルＢにより構成されたデータトンネルと、を作成し、終了し、或いは、処理することができる。即ち、ルータは、データトンネルを処理するために必要なコンポーネント（例えば、ＧＲＥカプセル化及びカプセル解除のソフトウェア）を具備していることが前提である。
【０１２４】
しかし、ルータは、他のルータのトンネリング能力を判定するため、「サポートプロトコル」フィールド以外の手段を使用することが可能である。一つのオプションは、特に、ＬＳＰを発行したルータのトンネリング能力に関する情報を伝達するためＬＳＰに新しいフィールドを作成若しくは定義することである。このようにして、ルータは、例えば、当該ルータがトンネルを終端し得ること、当該ルータがサポートするトンネリングプロトコルのタイプ、並びに、トンネル内にカプセル化されるプロトコルを、他のルータへ広告するため、新しいＬＳＰフィールドを使用することが可能である。
【０１２５】
新しい「トンネリング能力」フィールドの追加は、新しいＴＬＶ符号化（タイプ・長さ・値符号化）可変長フィールドを定義することにより、統合ＩＳ−ＩＳにおいて都合よく実現される。
【０１２６】
更に、「トンネリング能力」フィールドを設けることは、統合ＩＳ−ＩＳとの共用に限定されない。オープン最短パス優先（ＯＳＰＦ）のような他のリンク状態プロトコルも、ルータ間での通信を可能にさせるため、リンク状態ＰＤＳ（ＯＳＰＦの場合には、リンク状態広告（ＬＳＡ）として知られている）を使用する。したがって、本発明は、特に、トンネリング能力情報を伝搬するためのフィールドを組み込むため、ＬＳＰ、又は、等価的なデータパケットを修正することができるリンク状態プロトコルと共に使用するために好適である。
【０１２７】
以上の説明からわかるように、カプセル化及びトンネリングは、ルータによって必要であると考えられたときに限り行われるので、トンネルは自動的に作成され、動的である。トンネルは維持する必要がなく、データパケットがトンネルを必要とするときに限り存在する。好ましい実施例において、パケットは最短パスに沿ってネットワークを行き来し続け、全てのノードは共通した基本ルーティングプロトコルを備えているので、ＩＳ−ＩＳパケットはこれらのトンネルを通る必要がなく、ＩＰトラフィックとＣＬＮＳ／ＣＬＮＰトラフィックだけがカプセル化される。
【０１２８】
したがって、本発明は、統合ＩＳ−ＩＳとの共用に限定されないことがわかるであろう。例えば、本発明は、ＯＳＰＦを用いて、ＩＰｖ４を越えてＩＰｖ６のトンネルを行ない、ＩＰｖ６を越えてＩＰｖ４のトンネルを行うために使用できる。
【０１２９】
更に別の形として、ルータは他のルータに、一つ以上のダミーアドレスへの広告用近隣性を用いて、当該ルータのトンネリング能力を広告する。例えば、特定のタイプのトンネルを終端する能力を備えたルータは、所定のダミーアドレスへの近隣性を持つことを生成したＬＳＰで示すことによって、その旨を広告する。かくして、特定のタイプのトンネルを開始することを要求したルータは、所定のダミーアドレスに対する近隣性を広告した別のルータに関するＬＳＰデータベースを探すであろう。この方法は、標準的なＬＳＰを修正する必要がない、という利点がある。トンネルをセットアップする各ルータは、ダミーアドレスを認識し、ダミーアドレスを対応したトンネリング能力と関連付けることができるだけで十分である。このアプローチは、統合ＩＳ−ＩＳ若しくはＯＳＰＦのようなリンク状態プロトコルと共に使用する場合に特に好適である。
【０１３０】
本発明は、上記の実施例に限定されることはなく、実施例は、本発明の範囲から逸脱することなく、修正若しくは変更を加えられる。
【０１３１】
以下の標準は、上述の説明と関連しており、参考のため引用される。
【０１３２】
ｉＳＯ／ＩＥＣ　１０５８９は、ＳＰＦをＯＳＩのルーティングに適用する方式を記載し、ＩＳ−ＩＳであるルーティングプロトコルを規定し、ＰＡＴＨＳデータベースとＩＳ−ＩＳのＬＳＰについても記載している。
【０１３３】
ＲＦＣ　１１９５は、標準的なＩＳＯ　１０５８９がＩＰ（特に、ＩＰｖ４）とＯＳＩのルーティングを行うため拡張される方式を記載し、更に、統合ＩＳ−ＩＳ（二重ＩＳ−ＩＳとも呼ばれる）でああるルーティングプロトコルを指定するために必要なＰＡＴＨＳデータベースとＩＳ−ＩＳのＬＳＰへの拡張を記載している。
【０１３４】
ＲＦＣ　１７０１及びアップデート版ＲＦＣ　２７８４は、ＧＲＥを記述し、ＲＦＣ　１７０２及びＲＦＣ　３１４７は、ＧＲＥカプセル化されたデータパケットに関係する。
【０１３５】
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｉｓｉｓ−ｉｐｖ６−０１．ｔｅｘｔ、及び、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｉｓｉｓ−ｉｐｖ６−０２．ｔｅｘｔは、ＩＰｖ６をサポートするため統合ＩＳ−ＩＳを修正する方法を説明する草案である。
【図面の簡単な説明】
【図１】
複数のネットワークノードを含むネットワーク若しくはルーティングドメインの概要図である。
【図２】
ネットワークノードとその動作の一部を説明するブロック図である。
【図３】
本発明によって構成されたネットワークノードとその動作の一部を説明するブロック図である。
【図４】
本発明によって構成されたネットワークノードとその動作の一部を説明するブロック図である。
【図５】
本発明によって構成されたネットワークノードとその動作の一部を説明するブロック図である。
【図６】
本発明によって構成されたネットワークノードにより連結された４個のネットワークエリアの概要図である。
【図７】
本発明によって構成されたネットワークノードを含む二つのレベル−１ネットワークエリアの概要図である。
【図２】
2004515165.tif 000003
【図３】
2004515165.tif 000004
【図４】
2004515165.tif 000005
【図５】
2004515165.tif 000006
【図６】
2004515165.tif 000007
【図７】
2004515165.tif 000008
【国際公開パンフレット】
2004515165.tif 000009
2004515165.tif 000010
2004515165.tif 000011
2004515165.tif 000012
2004515165.tif 000013
2004515165.tif 000014
2004515165.tif 000015
2004515165.tif 000016
2004515165.tif 000017
2004515165.tif 000018
2004515165.tif 000019
2004515165.tif 000020
2004515165.tif 000021
2004515165.tif 000022
2004515165.tif 000023
2004515165.tif 000024
2004515165.tif 000025
2004515165.tif 000026
2004515165.tif 000027
2004515165.tif 000028
2004515165.tif 000029
2004515165.tif 000030
2004515165.tif 000031
2004515165.tif 000032
2004515165.tif 000033
2004515165.tif 000034
2004515165.tif 000035
2004515165.tif 000036
2004515165.tif 000037
2004515165.tif 000038
2004515165.tif 000039
2004515165.tif 000040
2004515165.tif 000041
2004515165.tif 000042
2004515165.tif 000043
2004515165.tif 000044
2004515165.tif 000045
2004515165.tif 000046
2004515165.tif 000047
2004515165.tif 000048
2004515165.tif 000049
2004515165.tif 000050
2004515165.tif 000051
2004515165.tif 000052
2004515165.tif 000053
2004515165.tif 000054
2004515165.tif 000055
2004515165.tif 000056
2004515165.tif 000057
2004515165.tif 000058
2004515165.tif 000059
2004515165.tif 000060
2004515165.tif 000061
2004515165.tif 000062
【国際公開パンフレット（コレクトバージョン）】
2004515165.tif 000063
2004515165.tif 000064
【国際公開パンフレット（コレクトバージョン）】
2004515165.tif 000065
2004515165.tif 000066
【手続補正書】
【提出日】平成14年6月28日(2002.6.28)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
各ノードが一つ以上のプロトコルの複数のセットのうちの一つ以上のセットをサポートするように構成されている複数のノードを含むネットワークにおいてデータパケットのルーティングを行う装置であって、
使用時に、第１のプロトコルセット及び一つ以上の他のプロトコルセットをサポートする第１のネットワークノードに収容され、
該第１のネットワークノードで該第１のプロトコルセットに適合したデータパケットを受信したとき、該受信したデータパケットが該第１のネットワークノードへ向けられているかどうかを判定するように構成され、
更に、該受信したデータパケットが該第１のネットワークノードへ向けられていないと判定したとき、データパケットの宛先ノードへのパス内で、該第１のプロトコルセット及び少なくとも一つの該他のプロトコルセットをサポートする第２のネットワークノードを識別するように構成され、
該データパケットを、該少なくとも一つの他のプロトコルセットに適合し、かつ、該第２のネットワークノードに対応した宛先アドレスを有するデータパケット内にカプセル化し、カプセル化されたデータパケットを該第２のネットワークノードへ転送させるように構成されている、
装置。
【請求項２】
宛先ノードへのパス内で近隣ネットワークノードによってサポートされているプロトコルセットを判定することにより、該少なくとも一つの他のプロトコルセットを選択するように構成されている、請求項１記載の装置。
【請求項３】
当該装置は近接ネットワークノードによってサポートされている第２のプロトコルセットを識別するように構成され、
該第２のプロトコルセットは該第１のネットワークノードによってサポートされている該一つ以上のほかのプロトコルセットに収容され、
当該装置は、該第２のネットワークノードとして、宛先ノードへのパス内で該第１のプロトコルセット及び該第２のプロトコルセットをサポートするネットワークノードを選択するように構成されている、
請求項２記載の装置。
【請求項４】
該受信したデータパケットが該第１のネットワークノードへ向けられていることを判定したとき、当該装置は、該受信したデータパケットが該第１のプロトコルセット内にカプセル化された別のプロトコルセットに適合したデータを収容しているかどうかを判定し、収容していると判定されたとき、該受信したデータパケットのカプセルを解くように構成され、
当該装置は、更に、カプセルを解かれたデータパケットが該第１のネットワークノードに向けられているかどうかを検査するように構成されている、
請求項１記載の装置。
【請求項５】
各プロトコルセットはネットワークレイヤプロトコルを含む、請求項１乃至４のうち何れか一項記載の装置。
【請求項６】
該プロトコルセットは、ＯＳＩプロトコルとＩＰプロトコルのうちの少なくとも一方を含む、請求項１乃至５のうち何れか一項記載の装置。
【請求項７】
該ＯＳＩプロトコルは、ＣＬＮＳ（コネクションレス・モード・ネットワーク・サービス）及びＣＬＮＰ（コネクションレス・モード・ネットワーク・プロトコル）を含み、
該ＩＰプロトコルは、ＩＰｖ４とＩＰｖ６のうちの少なくとも一方を含む、
請求項６記載の装置。
【請求項８】
ネットワーク内の各近隣ノードに関して情報を集めるように構成され、
この情報は、対応した近隣ノードによってサポートされているプロトコルセットの識別情報を含む、
請求項１乃至７のうち何れか一項記載の装置。
【請求項９】
該情報は、各近隣ノードによって使用時に分散させられた対応したルーティング用データパケットに含まれる情報を検査することにより集められる、請求項８記載の装置。
【請求項１０】
当該装置は、ネットワーク内の他のノード毎に、該他のノードへのパス内で、該他のノードと共通した少なくとも二つのプロトコルセットをサポートする一つ以上のネットワークノードを識別する情報を集めるように更に構成され、
該第２のネットワークノードは、該一つ以上のネットワークノードから選択される、
請求項１乃至９のうち何れか一項記載の装置。
【請求項１１】
該他のノードへの対応したパスは、ルーティングアルゴリズムによって判定されるような最短パスである、請求項１０記載の装置。
【請求項１２】
該第２のネットワークノードとして、宛先ノードへのパス内で、次の、又は、最近接の適切なネットワークノードを選択するように構成されている、請求項１０又は１１記載の装置。
【請求項１３】
各ネットワークノードによって、使用時に、分散させられたルーティング用データパケットに格納されている情報を評価することにより、該情報を集めるように構成されている、請求項１０乃至１２のうち何れか一項記載の装置。
【請求項１４】
請求項１乃至１３のうち何れか一項記載の装置を含むネットワークノード。
【請求項１５】
当該ネットワークノードは一つ以上のリンク状態プロトコルをサポートするように構成され、
該ルーティング用データパケットはリンク状態パケットを含む、
請求項１４記載のネットワークノード。
【請求項１６】
当該ネットワークはＩＳ−ＩＳプロトコルをサポートするように構成され、
リンク状態パケットはＩＳ−ＩＳのＨｅｌｌｏパケットを含む、
請求項１５記載のネットワークノード。
【請求項１７】
当該ネットワークは、ＩＳ−ＩＳプロトコルと統合ＩＳ−ＩＳプロトコルのうちの少なくとも一方をサポートするように構成され、
リンク状態パケットはリンク状態ＰＤＵ（プロトコル・データ・ユニット）（ＬＳＰ）を含む、
請求項１６記載のネットワークノード。
【請求項１８】
該情報は、統合ＩＳ−ＩＳのＬＳＰのサポートプロトコル・フィールドから集められる、請求項１７記載のネットワークノード。
【請求項１９】
該ルーティング用データパケットは、ルーティング用データパケットを送出する対応したネットワークノードのデータトンネリング能力を識別する情報を伝達するように構成されている、請求項１４乃至１８のうち何れか一項記載のネットワークノード。
【請求項２０】
ネットワーク内の各ノードは、対応したルーティング用データパケットで、ネットワークノードのトンネリング能力に応じて、一つ以上のダミーネットワークノードへの近隣性を示すように構成されている、請求項１９記載のネットワークノード。
【請求項２１】
ネットワーク内の他のノード毎に集められた情報を記憶する手段を更に有する請求項１４乃至２０のうち何れか一項記載のネットワークノード。
【請求項２２】
該記憶する手段は、ＩＳ−ＩＳ及び統合ＩＳ−ＩＳによって提供されるＰＡＴＨＳデータベースを含む、請求項２１記載のネットワークノード。
【請求項２３】
ルーティングを行う装置は、ネットワーク内の他のノード毎に、一つ以上の適切な第２のネットワークノードの対応した識別子を該記憶する手段に記憶するように構成されている、請求項２１又は２２記載のネットワークノード。
【請求項２４】
ルーティングを行う装置は、ネットワークノードと対応した他のネットワークノードによって共通してサポートされているプロトコルセットの各対に関して、適切な第２のネットワークノードの対応した識別子を記憶するように構成されている、請求項２３記載のネットワークノード。
【請求項２５】
当該ネットワークノードは、他のネットワークノードへの対応したパス内で次の、又は、最近接である適切な第２のネットワークノードの識別子を記憶するように構成されている、請求項２３又は２４記載のネットワークノード。
【請求項２６】
レベル−１のルータとして動作するように構成されている、請求項１４乃至２５のうち何れか一項記載のネットワークノード。
【請求項２７】
レベル−２のルータとして動作するように構成されている、請求項１４乃至２６のうち何れか一項記載のネットワークノード。
【請求項２８】
請求項１４乃至２７のうち何れか一項記載のネットワークノードを含むネットワーク。
【請求項２９】
各ノードが一つ以上のプロトコルの複数のセットのうちの一つ以上のセットをサポートするように構成されている複数のノードを含むネットワークにおいてデータパケットのルーティングを行う方法であって、
第１のプロトコルセット及び一つ以上の他のプロトコルセットをサポートし、装置が収容されている第１のネットワークノードで、該第１のプロトコルセットに適合したデータパケットを受信し、
受信したデータパケットが該第１のネットワークノードへ向けられているかどうかを判定し、
該受信したデータパケットが該第１のネットワークノードへ向けられていないと判定されたとき、該データパケットの宛先ノードへのパス内で、該第１のプロトコルセット及び少なくとも一つの該他のプロトコルセットをサポートする第２のネットワークノードを識別し、
該少なくとも一つの他のプロトコルセットに適合し、かつ、該第２のネットワークノードに対応した宛先アドレスを有するデータパケット内に該データパケットをカプセル化し、
該カプセル化されたデータパケットを該第２のネットワークノードへ転送する、
方法。
【請求項３０】
ネットワークノードに請求項２９記載の方法を実施させるコンピュータ使用可能命令を含むコンピュータプログラム。
【請求項３１】
請求項１乃至１３のうち何れか一項記載の装置を全部若しくは部分的に実施するためのコンピュータ使用可能な命令を含むコンピュータプログラム。
【請求項３２】
各ノードが一つ以上のプロトコルの複数のセットのうちの一つ以上のセットをサポートするように構成されている複数のノードを含むネットワークであって、
各ネットワークノードは、
第１のプロトコルセット及び一つ以上の他のプロトコルセットをサポートするように構成され、データパケットのルーティングを行う装置と、
上記装置にデータトンネルを処理させるために必要なコンポーネントと、
を具備している、
ネットワーク。
【請求項３３】
データパケットをルーティングする各装置は、
第１のネットワークノードで該第１のプロトコルセットに適合したデータパケットを受信したとき、該受信したデータパケットが該第１のネットワークノードへ向けられているかどうかを判定するように構成され、
更に、該受信したデータパケットが該第１のネットワークノードへ向けられていないと判定したとき、該データパケットの宛先ノードへのパス内で、該第１のプロトコルセット及び少なくとも一つの該他のプロトコルセットをサポートする第２のネットワークノードを識別するように構成され、
該データパケットを、該少なくとも一つの他のプロトコルセットに適合し、かつ、該第２のネットワークノードに対応した宛先アドレスを有するデータパケット内にカプセル化し、カプセル化されたデータパケットを該第２のネットワークノードへ転送させるように構成されている、
請求項３２記載のネットワーク。
【請求項３４】
必要なコンポーネントは、ＧＲＥカプセル化及びカプセル化解除のためのソフトウェアを含む、請求項３２記載のネットワーク。
【請求項３５】
各装置は、リンク状態プロトコルフィールドを用いて当該装置のカプセル化能力を示す、請求項３２記載のネットワーク。
【請求項３６】
リンク状態プロトコルフィールドは、統合ＩＳ−ＩＳプロトコルのタイプ・長さ・値（ＴＬＶ）符号化可変長フィールドである、請求項３２記載のネットワーク。
【請求項３７】
複数のネットワークノードを含むネットワークの使用時に準備され、データパケットのルーティングを行う装置であって、
第１のネットワークノードで第１のプロトコルセットに適合したデータパケットを受信したとき、該受信したデータパケットが該第１のネットワークノードへ向けられているかどうかを判定するように構成され、
更に、該受信したデータパケットが該第１のネットワークノードへ向けられていないと判定したとき、データパケットの宛先ノードへのパス内で、該第１のプロトコルセット及び少なくとも一つの他のプロトコルセットをサポートする第２のネットワークノードを識別するように構成され、
該データパケットを、該少なくとも一つの他のプロトコルセットに適合し、かつ、該第２のネットワークノードに対応した宛先アドレスを有するデータパケット内にカプセル化し、カプセル化されたデータパケットを該第２のネットワークノードへ転送させるように構成され、
リンク状態プロトコルフィールドを用いて当該装置のカプセル化能力を示すように構成されている、
装置。
【請求項３８】
リンク状態プロトコルフィールドは、統合ＩＳ−ＩＳプロトコルのタイプ・長さ・値（ＴＬＶ）符号化可変長フィールドである、請求項３７記載の装置。
【国際調査報告】
2004515165.tif 000067
2004515165.tif 000068