JPH10510415A - 拡張アドレス空間の互換転送のためのネットワーク・アドレシング構造 - Google Patents

Abstract

(57)【要約】 ネットワーク・アドレシング構造の改良でネットワーク層ヘッダのフォーマットとコンピュータ・ネットワークに接続されたノードのアドレス空間の両方を、ネットワークの異るドメインにあるノード間でのルーティングを効率的に拡張するような方法で拡張する。さらに詳しくは、新規な構造では慣用の階層化ネットワーク層アドレスに新規のエレメントを提供しそのアドレスの既存のエレメントすなわち宛先ネットワーク及びソケット番号を変更して改良型ネットワーク層ヘッダを効率的に作成する。

Description

【発明の詳細な説明】 拡張アドレス空間の互換転送のためのネットワーク・アドレシング構造 発明の分野 本発明は一般にコンピュータ・ネットワークに関し、さらに詳しくは、コンピ ュータ・ネットワークに接続されたノードのアドレス空間の拡張に関する。 発明の背景 コンピュータ・ネットワークはコンピュータなどのノード間でデータを伝送す るために相互接続されている通信リンクの地域的に分散した集合体である。ロー カル・エリア・ネットワーク（ＬＡＮ）から広域ネットワーク（ＷＡＮ）まで、 多くの種類のコンピュータ・ネットワークが利用可能になっている。ＬＡＮはた とえば同軸ケーブルやツイステッドペア線などの伝送媒体で構成されることの多 い限定領域内のネットワークで、ＷＡＮは通信リンクを用いて広範囲に分散した ノードを相互接続する公衆または専用の電気通信設備である。これらのノードは 所定のプロトコルにしたがってデータの独立した「パケット」を交換することに より通信するのが代表的である。この状況で、プロトコルはノード同士がどのよ うに相互作用するかを定義した一組のルールから構成されている。 コンピュータ・ネットワークはルータとよばれる中間ノードによりさらに相互 接続されてそれぞれのネットワークの実効的「サイズ」を拡張できる。相互接続 されたコンピュータ・ネットワークの大きなシステムの管理は厄介になることが あるので、コンピュータ・ネットワークの小さいグループを自律的なシステムま たはドメインとして維持し、ドメイン内のネットワークを慣用の「イントラ・ド メイン」ルータにより相互に接続するのが代表的である。データ交換が可能なノ ード数を増加するのがさらに望ましいことがあり、この場合、ドメイン間のルー ティング・プロトコルを用いてドメインのノード間の相互作用が出来るよう にする。 設計の複雑さを減らすため、多くのネットワークは各ノード内部で一連のハー ドウェアとソフトウェアのレベル、または「レイヤ（層）」として構成される。 これらの層が相互作用して、たとえばネットワーク上で通信するソースノードと 宛先ノードの間の転送用にデータをフォーマットする。さらに詳しくは、データ が各レイヤを通過するとそのデータに対して所定のサービスが実行され、レイヤ 同士が所定のプロトコルにしたがって通信する。このように階層化した設計によ り、各レイヤはサービスの実際の実施詳細からレイヤを遮蔽する標準化インタフ ェースを用いて、他のレイヤへ選択されたサービスを提供できる。 ネットワーク・アーキテクチャ、即ちネットワーク内で使用されるレイヤとプ ロトコルの組を標準化しようとする試みにおいて、国際標準化機構（ＩＳＯ）に より一般化したモデルが提案された。このモデルはＯＳＩ(Open Systems Interc onnection)参照モデルと呼ばれ、他のシステムとの通信に「オープンな」システ ムの相互接続を指向したものである。提案されているＯＳＩモデルは７層からな り、下からの順番で物理層、データリンク層、ネットワーク層、トランスポート 層、セッション層、プレゼンテーション層、アプリケーション層と呼ばれる。こ れらのレイヤはネットワークの各ノードで「プロトコルスタック」を形成するよ うに構成されている。 図１はコンピュータ・ネットワーク１００のソースノード１１０と宛先(desti nation)ノード１５０の間でデータを送信するためにそれぞれ使用される従来技 術のプロトコルスタック１２５、１７５の模式的ブロック図を示したものである 。各プロトコルスタックはＯＳＩ７層モデルに従った構成になっており、各スタ ックはレイヤ毎に１つづつのプロトコル集合を含む。理解されるように、プロト コルスタック１２５および１７５は物理層１２４および１６４で通信チャンネル を介して物理的に接続される。説明を簡単にするため、プロトコルスタック１２ ５について説明する。 大まかに言うと、物理層１２４は通信チャンネル１８０上に生データ・ビット ストリームを送信し、一方データリンク層はビットストリームを操作し送信エラ ーの見られないデータストリームに変換する。後者のタスクは送信データをフ レームに分割し、フレームを順次送信することで達成され、エラーの検出または 訂正のためのエラー訂正メカニズムが伴う。ネットワーク層１２０は物理ネット ワークを通る多くの代替パスの１つを選択することによってソースノードから宛 先ノードへデータ・パケットをルーティングする。トランスポート層１１８はセ ッション層１１６からのデータストリームを受け取り、（必要なら）もっと小さ い単位に細分して細分したユニットをネットワーク層１２０へ渡し、全てのユニ ットが宛先に正しく到着することを保証する適当なメカニズムを提供する。 セッション層１１６はソースおよび宛先ノード上のソフトウェア・プロセス間 にデータ転送「セッション」を確立し併せて順序だった当該セッションの管理を 行なう。つまり、セッションはノード間の通常のデータ転送を行なえるようにす る以外に、何らかのアプリケーションに拡張サービスを提供する。プレゼンテー ション層１１４は送信データのプレゼンテーションに関連して、標準フォーマッ トへのデータ符号化を含め頻繁に要求される機能を実行し、アプリケーション層 １１２はノード上で実行中のプロセスで一般に必要とされる各種のプロトコルを 含んでいる。 つまりネットワーク１００上のデータ送信はたとえばソースノード１１０上で 実行されている送信プロセス１０４でデータを一般化し、そのデータをアプリケ ーション層１１２へ渡し、さらにプロトコルスタック１２５の各層を下向きに通 り、ビットとしてチャンネル１８０へ供給するパケットの形にデータが順次フォ ーマットされる。これらのパケット・ビットが宛先ノード１５０のプロトコルス タック１７５へ向けて送信され、宛先ノードではスタックを上り受信プロセス１ ７４へ渡される。データフローは実線矢印で模式的に図示してある。 実際のデータ送信はスタックを縦方向に通過するが、各層は送信が水平方向に 通るようにプログラムされている。つまり、ソースノード１００の各層は宛先ノ ード１５０でこれに対応する層へ、模式的に破線矢印で示したように、データを 送信するようにプログラムされている。これを行なえるようにするには、パケッ トがスタックを下降する際に、ソースノード１１０内のプロトコルスタック１２ ５の各層が送信プロセスにより生成されたデータ・パケットへ（ヘッダ・フィー ルドの形で）情報を追加するのが一般的である。宛先ノード１５０では、 受信プロセスに到着するまでパケットがスタック１７５の層を上へ伝わる際に、 各種ヘッダが１つづつ取り除かれる。 前述のように、ＯＳＩモデルにおける各層の顕著な機能は他の層へのサービス を提供することである。各層で提供される２種類のサービスが「コネクション指 向(connection-oriented)」および「コネクションレス」ネットワーク・サービ スである。接続指向サービスでは、ソースノードが宛先ノードとの接続を確立し 、パケットの送信後、接続を終了する。接続を確立することに伴うオーバヘッド は効率的通信性能を要求するノードでは不要である。この場合、各々の送信パケ ットがネットワーク経由で宛先の完全なアドレスを伝送するような完全コネクシ ョンレス・サービスが望ましい。 ネットワーク層プロトコルはコネクションレス・ネットワーク・サービスを実 施するために用いられるのが一般的で、このサービスが主としてパケット・フォ ーマットを定義している。ネットワーク層がネットワーク上への送信のためにト ランスポート層からパケットを受信すると、特にソース・アドレスと宛先アドレ スを含むヘッダを（パケットに）追加する。ネットワーク層プロトコルの例とし ては、ＩＳＯにより定義されているコネクションレス・ネットワーク層プロトコ ル（ＣＬＮＰ）、インターネット（ＩＰ）ネットワーク層プロトコル、インター ネット・パケット交換（ＩＰＸ）プロトコルが挙げられる。 ネットワーク層サービスにより定義されるヘッダ・フィールドは、主に各パケ ットに同じ情報が代表的に含まれるため一般に同一である。例えば、こうしたヘ ッダの大部分は、ネットワークに接続された比較的多数のノードに対応できるよ うに構成された固定長階層化アドレスを含む。ＩＰＸヘッダの場合、ソース及び 宛先アドレスは階層化されており４バイトのネットワーク番号、６バイトのノー ド番号、及び２バイトのソケット番号を含む複数のエレメントから構成される。 例外としてはＣＬＮＰヘッダがあり、これは潜在的に広範囲のネットワーク層ア ドレスを取り扱うように構成されている。しかし、これらのヘッダ全部のアドレ ス拡張は、アドレスフィールドのほぼ固定されたフォーマットからなり同時にこ れによって大幅に制約される。 ＣＬＮＰ及びＩＰヘッダの全体的なパケット・フォーマットはヘッダ内部に 含まれるオプション・フィールドを用いて追加機能に対応するように拡張できる 。これらのフィールドでサポートされるオプションの種類としては、代表的にソ ース・ルーティング、プライオリティおよび保安仕様情報(securityspecific in formation)が含まれる。しかし、従来のＩＰＸヘッダ・フォーマットは一般にパ ケットの残りのフィールドと互換性がある方法で追加フィールドに対応するよう に設計されなかったため一般に拡張不可能である。 発明の概要 本発明はコンピュータ・ネットワークに接続されたノードのアドレス空間を、 当該ネットワークの異るドメインのノード間ルーティングを効率的に拡張するよ うな方法で、拡張するためのネットワーク・アドレシング構造の改良を含む。つ まり、新規の構造は、従来の階層化ネットワーク層アドレスに新規のエレメント を提供し既存のエレメントすなわちそのアドレスの宛先ネットワーク及びソケッ ト番号を変更して改良されたネットワーク層ヘッダを効率的に作成することによ りネットワーク・アドレシングを改善するものである。 さらに、ネットワーク・アドレシング構造では、インタードメイン・ルータす なわち対応するドメイン内部にあってネットワークを横断して他のドメインに到 達することの出来るルータの能力を最大限に発揮させる改良されたネットワーク 層ヘッダの拡張ヘッダ・フィールド・フォーマットが可能になり、同時に従来の ドメイン内ルータが慣用のネットワーク層ヘッダを構成するフィールド内容に対 して障害なく動作を継続することを保証できる。 さらに詳しくは、本発明の構造はインタードメイン・ルータを一意的に識別す る特別のネットワーク値を提供して従来のネットワーク・アドレスの宛先ネット ワーク番号をその値に置き換える。宛先ソケット番号に対して特別なソケット値 がさらに提供され、特別なソケット値がヘッダのソース・アドレス・フィールド の後の追加拡張ヘッダ情報の提供を表わす。さらに、本構造は適当な宛先及びソ ース・ドメインを識別する新規なドメイン番号を提供する。前述のように、ドメ イン番号は従来のネットワーク・アドレスに追加され、ネットワーク層ヘッダ がほぼ固定フォーマットであるため、拡張ヘッダ・フィールドに格納される。 本発明の代表的実施例において、各インタードメイン・ルータはこれの対応す るドメインをバックボーン・ネットワークに接続する。動作的には、ソースノー ドが異なるドメイン内部の宛先ノードへパケットを送出する前にこれらの特別な 値に宛先ネットワーク及びソケット番号をセットする。実際の宛先ネットワーク 及びソケット番号は、新規な宛先ドメイン番号といっしょに、パケットの拡張ヘ ッダ・フィールド内に格納される。この後パケットはネットワーク上に送信され 、挿入された宛先ネットワーク値がインタードメイン・ルータを一意的に識別す るため、従来のドメイン内ルータはこの値に基づいてパケットを適当なインター ドメイン・ルータへ単にフォワーディングする。 インタードメイン・ルータに到達すると、パケットがネットワーク宛先アドレ スの特別なソケット値にしたがって分析される。すなわち、ルータは拡張ヘッダ ・フィールドの内容を調べてこれに対応する宛先ドメイン番号がパケットで指定 されているか判定する。インタードメイン・ルータが指定されたルータではない 場合、パケットはそのドメイン番号に基づいてさらにルーティングされる。パケ ットが所望の宛先ドメインに接続する適当なインタードメイン・ルータへ到達す ると、そのルータは特別な値を実際の宛先ネットワーク及びソケット番号に置き 換え、パケットを適当な宛先ノードへルーティングする。 有利にも、本発明は従来のインタードメイン・ルータのアップグレードを回避 するような方法で見かけ上不変なパケット・フォーマットからネットワーク・ア ドレスを拡張するための技術を提供する。本発明のアドレシング構造を解釈する ようにインタードメイン・ルータだけを構成すれば良いので、本技術は既存のル ータと互換性を有する。 さらに、本発明はネットワーク層アドレスの異なるセクションに基づいてルー ティングを容易にする。これは多くのルータがパケット・フォワーディングの前 にネットワーク層ヘッダの指定された部分、すなわち４バイトの宛先ネットワー ク番号フィールドを検証するだけで済むので、ネットワーク・アドレシングの効 率を向上することが出来る。インタードメイン・ルータだけはアドレシング情報 の残りの部分を検証する必要がある。 図面の簡単な説明 本発明の上記の及びそれ以外の利点は添付の図面との関連において以下の説明 を参照することにより、一層良く理解されよう。図面においては同じ参照番号で 類似の要素を表わしており、 図１はコンピュータ・ネットワークのソースノードと宛先ノードの間でデータ を転送するために使用される従来技術のプロトコルスタックの模式的ブロック図 である。 図２は複数のノードに接続されたコンピュータ・ネットワークの集合を含むコ ンピュータ・ネットワーク・ドメインのブロック図である。 図３Ａ〜図３Ｃは本発明による新規なネットワーク・アドレシング構造に関す る情報を記憶するためのオプション・フィールドを備える慣用のネットワーク層 ヘッダのフォーマットを示す略図である。 図４は従来のＩＰＸネットワーク層ヘッダのフォーマットを示す模式図である 。 図５は新規なネットワーク・アドレシング構造に基づく図４のＩＰＸネットワ ーク層ヘッダの改良フォーマットを示す模式図である。 図６はバックボーン・ネットワークに接続された複数のドメインを含み本発明 の新規なネットワーク・アドレシング構造を有利に使用できるような相互接続さ れたコンピュータ・ネットワークのシステムの略ブロック図である。 代表的実施例の詳細な説明 図２は複数のノードに接続されたコンピュータ・ネットワークの集合を含むネ ットワーク・システム２００のブロック図である。ノードはソースノードＳ、末 端ノードＮ、宛先ノードＤ、複数の中間ノードＲ１〜Ｒ２からなる汎用コンピュ ータが代表的である。各ノードは代表的には、システムバス２１０で相互接続さ れている中央演算処理ユニット（ＣＰＵ）２０２、メモリ・ユニット２０４、お よび少なくとも１個のネットワーク・アダプタ２０６を含む。メモ リ・ユニット２０４はランダム・アクセス・メモリ（ＲＡＭ）デバイスから構成 されるのが代表的な記憶ロケーションを含み、ＣＰＵ２０２およびネットワーク ・アダプタ２０６からアドレス可能である。代表的には一部がメモリに常駐して ＣＰＵにより実行されるオペレーティング・システムは、特にＣＰＵで実行する プロセスのサポートにおいてネットワーク動作を実行することにより、機能的に ノードを構成する。 ネットワーク・システム２００内部に含まれるコンピュータ・ネットワークは 中間ノードＲ１及びＲ２により相互接続されたローカル・エリア・ネットワーク （ＬＡＮ）１〜３である。ＬＡＮに接続されたノード間の通信は代表的には例え ばソースと宛先ノードのアドレスを指定する独立したデータ「パケット」を交換 することにより行われる。本システムは相互接続されたＬＡＮの比較的少数のグ ループを含むことから、自律的ドメインとして維持されるのが望ましい。中間ノ ードは正しい受信ノードへパケットをルーティングすることでドメイン２００全 体のデータ・パケットのフローを容易にするように構成されたインタードメイン ・ルータが望ましい。 一般に、ソースノードがＬＡＮ１上にパケットを送信する際に、パケットはそ のＬＡＮ上にある全ノードに送信される。意図しているパケット受け手がＬＡＮ ３に接続されている場合、パケットはルータＲ１を通りＬＡＮ２へまたＲ２を通 ってＬＡＮ３へルーティングされる。ルータの重要な機能はパケットが送信され る次のノードを決定することで、このルーティング機能は各ノード内部のプロト コル・スタック２５０のネットワーク層２６０で行われるのが望ましい。代表的 には、パケットは２種類の宛先アドレスを含む。最終的な宛先ノードのアドレス と、ルートに沿った次のノードのアドレスである。最終的宛先アドレスはパケッ トがネットワークを横断しても一定のままだが、次の宛先アドレスは、ネットワ ークを通るルートに沿ったノードからノードへパケットが移動すると変化する。 さらに詳しくは、ソースノードＳは宛先ノードＤへ、すなわち最終宛先アドレ スへパケットを送出する場合、パケットをＬＡＮ１へ送信し、次の宛先アドレス でルータＲ１のアドレスを指定する。パケット内に埋め込まれてプロトコルス タック２５０の高層部ソフトウェアにより処理されるアドレス情報はパケットの 最終宛先をノードＤに指定する。この情報に基づいて、Ｒ１はルートに沿った次 のノードがルータＲ２であることを判定し、そのノードが受信できるようにＬＡ Ｎ２へパケットを渡す。ルータＲ２は次のノードが最終宛先ノードＤであると判 定し、パケットをＬＡＮ３上でノードＤへ送信する。 ルータＲ１及びＲ２をドメイン２００で使用するには相互接続されたネットワ ークが同一のネットワーク層プロトコルを共有する必要があり、また高次のプロ トコル・スタック層で互換性がある必要がある。しかしＬＡＮ１をＬＡＮ２に接 続するＲ１のプロトコルスタック２５０に模式的に図示してあるようにネットワ ークはデータリンク層２６２と物理層２６４では異っている。ルータはコネクシ ョンレス・ネットワーク層プロトコル（ＣＬＮＰ）やインターネット（ＩＰ）ネ ットワーク層プロトコル等のネットワーク層プロトコルで動作できるが、本明細 書で説明している代表的実施例において、ネットワーク層プロトコルはインター ネット・パケット交換（ＩＰＸ）プロトコルが望ましい。 前述のように、ネットワーク層２６０がネットワーク上への送信のためにトラ ンスポート層２５８からパケットを受信すると、ネットワーク層ヘッダを追加す る。このようなヘッダ・フィールドのフォーマットは主として各パケットに代表 的に同じ情報が含まれることから、すべてのネットワーク層サービスの間で一般 に同一である。図３Ａ及び図３ＢはそれぞれＩＰ及びＣＬＮＰネットワーク層パ ケット３１０と３５０のフォーマットを示す。これらのパケットは両方ともヘッ ダ３１２及び３５２（例えばバージョン番号フィールド３１４及び３５４）に同 様の情報を含むことが分かる。さらに詳しく説明すると、各ヘッダは追加される 機能に対応するためのオプション・フィールド３２６及び３６６を含む。これら のフィールドでサポートされるオプションの種類としては、ソース・ルーティン グ、プライオリティ、保安仕様情報が含まれる。図３Ｃは、オプション・フィー ルド３８０の内容の一般フォーマットを示したもので、これにはオプションの種 類を一意的に定義する１オクテット（１バイト）のオプション・コード・フィー ルド３８２、オプションの長さをバイト数で表わす１バイト長フィールド３８４ 、および可変例えば０〜２５４バイトの値フィールド３８６を含む。 図４は約３０バイトのネットワーク層ヘッダを有する従来のＩＰＸパケット４ ００のフォーマットを示す略図である。さらに詳しくは、ヘッダは２バイトのチ ェックサム・フィールド４０２、２バイトのパケット長フィールド４０４、１バ イトのホップ（ｈｏｐ）・カウント・フィールド４０６および１バイトのパケッ トタイプ・フィールド４０８を含む。ヘッダが多くのネットワーク層サービスで 定義されている場合では、ＩＰＸヘッダは固定長で階層化した宛先及びソース・ アドレスを含み、そのそれぞれが複数のアドレス・エレメントを含む。つまり、 宛先アドレス４１０はパケットが伝送される特定のネットワークを表わす４バイ トの宛先ネットワーク・フィールド４１２、ネットワーク上の受信ノードのデー タリンク層アドレスを識別する６バイトの宛先ノード・フィールド４１４、およ び受信ノードにおける受信プロセスを指定する２バイトの宛先ソケット・フィー ルド４１６を含む。同様に、ソース・アドレス４２０は４バイトのソース・ネッ トワーク・フィールド４２２、６バイトのソースノード・フィールド４２４、お よび２バイトのソース・ソケット・フィールド４２６を含む。データ・フィール ド４３０はソース・アドレス・フィールド４２０の直後にヘッダに追加される。 前述したような従来の階層化アドレスは従来のドメイン内ルータＲ１及びＲ２を 用いてドメイン２００のコンピュータ・ネットワークに接続されているノード間 のデータのルーティングに対応するのに十分である。しかしインタードメイン・ ルータ、すなわち対応するドメイン内部でネットワークを横断して他のドメイン に到達することの出来るルータにより、各種ドメインを相互接続することでデー タ交換出来るノード数を増加させるのが望ましい。これには各ドメインに接続さ れたノードのアドレス空間を拡張する必要がある。しかし、ＩＰＸヘッダ（及び 多くのネットワーク層ヘッダ）でのアドレス拡張はアドレス・フィールドの固定 フォーマットのために通常は制限されている。さらに、従来のＩＰＸパケット４ ００の固定フォーマットは、パケットの残りのフィールド、例えばデータ・フィ ールド４３０と互換性のある方法で拡張ヘッダ・フィールドに対応するような拡 張が出来ない。 本発明によれば、ネットワークの異なるドメイン間でのルーティングを効率的 に拡張するような方法で、コンピュータ・ネットワークに接続されたノードのア ドレス空間を拡張する新規な構造が提供される。さらに詳しくは、この構造は従 来の階層化ネットワーク・アドレスにドメイン・エレメントを追加することでネ ットワーク・アドレシングを改良するものである。ＩＰＸプロトコルの場合、ネ ットワーク・アドレシングは従来のアドレスの宛先ネットワーク及びソケット・ エレメントを変更して改良ネットワーク層ヘッダを効率的に作成することで改良 され、一方でＩＰ及びＣＬＮＰプロトコルでは、新規のドメイン・エレメントを オプションとして含むことが出来る。このような改良で新しい情報を解読するよ うに構成したインタードメイン・ルータの能力を最大限に発揮させ、同時に従来 のドメイン内ルータは慣用のネットワーク層ヘッダを構成する情報フィールドの 内容について動作し続けるように保証する。 図５は改良されたネットワーク層ヘッダ５００のフォーマットを示す模式図で ある。新規な構造によれば、インタードメイン・ルータを一意的に識別する特別 なネットワーク値５５２が提供される。ＩＰＸヘッダの場合、主としてルーティ ングは宛先ネットワーク番号に基づくため、ソースノードが慣用のネットワーク 層宛先アドレス４１０（図４）の４バイト宛先ネットワーク・フィールド４１２ 内部の実際の宛先ネットワーク番号をこの特別なネットワーク値に置き換える。 しかしＩＰ及びＣＬＮＰヘッダでは、特別な宛先アドレス値で実際の宛先アドレ ス３２４および３６２（図３Ａ及び図３Ｂ）を置き換えることが出来る。 さらに、この構造は既存のルータ及び宛先ノードと互換性の取れるような方法 で固定長アドレスを有するネットワーク層ヘッダのフォーマット拡張を提供する 。ＩＰＸヘッダの場合、ソースノードは従来のアドレスの２バイト宛先ソケット ・フィールド４１６内部の実際の宛先ソケット番号を特別なソケット値５５６に 置き換える。望ましくは、特別なソケット値はパケットのソースアドレス・フィ ールドの後に追加のヘッダ情報の提供を表わす。さらに詳しくは、特別なソケッ ト値がパケットをネットワーク上にフォワーディングする前に拡張ヘッダ・フィ ールド５６０の内容を検証するようにインタードメイン・ルータに指示する。そ の他のネットワーク層ヘッダ、例えばＩＰやＣＬＮＰでは、ヘッダ拡張はバージ ョン・フィールド（図３Ａ及び図３Ｂのそれぞれ参照番号３１４及び３５４を参 照）またはタイプ・フィールド（３１６及び３５６で図示してある） のどちらかで特別な値により表わされる。 さらに、本発明の構造は相互接続ドメインを一意的に識別するための新規なド メイン番号を提供する。前述のように、これらのドメイン番号はＩＰ及びＣＬＮ Ｐパケット３１０及び３５０のそれぞれのヘッダ・オプション・フィールド３２ ６及び３６６でオプションとして提供できる。図３Ｃを参照すると、新規のオプ ション種別はドメインについて定義され、オプション種別は特にソース及び宛先 ドメインを一意的に指定しフィールド３８２に格納されるオプション・コード例 えば「ＤＯＭＡＩＮ」を含む。 しかしＩＰＸネットワーク層ヘッダ５００の通常は固定されているフォーマッ トのため、ドメイン番号はそのヘッダの拡張ヘッダ・フィールド５６０に格納さ れる。さらに詳しくは、宛先ドメイン番号５６２が宛先ノードのドメインを指定 し、ソースドメイン番号５６４でパケットを生成するソースノードのドメインを 識別する。このような拡張ヘッダ・フィールド内には実際の宛先ソケット番号５ ６６及び実際の宛先ネットワーク番号５６８も含まれている。 本発明によれば、インタードメイン・ルータはヘッダ５００の拡張フィールド ５６０内部の補助情報を解読しこれに基づいて機能するように構成され、従来の ドメイン内ルータは拡張アドレシングを実装するように構成されていないので、 ネットワークの動作を妨害することなくこの情報を単純に無視することが出来る 。この互換性の特徴は、パケットの宛先アドレス４１０のネットワーク・フィー ルド４１２内部に含まれる特別なネットワーク値５５２がインタードメイン・ル ータを一意的に識別するため可能であり、パケットを受信したドメイン内ルータ はヘッダの宛先ネットワーク・フィールドの内容だけに基づいて適当なインター ドメイン・ルータへそのパケットを単純にフォワーディングする。 拡張ヘッダ・フィールドは可変サイズとして追加の特徴に対応できるのが望ま しい。例えば、新規の拡張ヘッダ・フォーマットでは中間ルータの幾つかまたは 全部が本発明の構造を実現するように構成されていればソースノードがある程度 の最適化を利用できる。これらの最適化には、特定パケットの（通常のではなく ）緊急送信供給を優先することや、問題が起こったためルータがパケットを「ド ロップした」場合にエラーレポートを要求することが含まれる。後者の特徴 はパケットの再送が有効かどうか判定するのに十分な情報をソースノードに提供 する。改良ＩＰＸヘッダに関連して、可変サイズの拡張ヘッダではパケット内の 互換性のある位置に将来他の最適化を追加することが出来る。 改良ネットワーク層ヘッダ５００内部に含まれる拡張アドレスの動作について 、図６に図示してある相互接続されたコンピュータ・ネットワークのシステムと の関連で説明する。システム６００はバックボーン・ネットワーク６１０に接続 された複数のドメインＡ〜Ｃを含む。代表的実施例において、ドメインは独立し たＩＰＸネットワーク、たとえばノベル社製ＩＰＸネットワークやマイクロソフ ト社製ＩＰＸネットワーク等を含み、バックボーン・ネットワークはＡＴ＆Ｔ／ ＩＰＸインターネットとすることが出来る。 各ドメインの内部で、ルーティングは４バイトの宛先ネットワーク番号４１２ （図４）に基づいているので、これらの番号は各ＩＰＸネットワーク・ドメイン 内部で一意的になるように割り当てられている。また、各ドメインはバックボー ン・ネットワークに接続される時にユニークなドメイン番号が動的に割り当てら れる。あるドメインが別の時刻または場所でバックボーン・ネットワークに「フ ック」されるように再構成してあり新しいドメイン番号が割り当てられる場合に はドメイン内のアドレスを再割り当てする必要がないためこれは有意である。 各ドメインは本明細書で説明している余剰レベルのアドレシングにしたがって 動作するように構成されていないドメイン内ルータも含んでいる。尚且つドメイ ンＡのソースノードＳは別のドメイン、例えばドメインＣにある宛先ノードＤと 通信できる必要がある。したがって、各ドメインはこれに対応するドメインをバ ックボーン・ネットワーク６１０に接続する少なくともひとつのインタードメイ ン・ルータを含む。 図６から分かるように、ドメインＡとＣに含まれるＬＡＮは同様のネットワー ク番号例えば５７を有している。さらに、ドメインＣの宛先ノードＤは、データ リンク層アドレスＤとソケット番号Ｙを有し、一方でドメインＡにあるソースノ ードＳはデータリンク層アドレスＳとソケット番号Ｘを有している。したがって 宛先ノードＤの完全なアドレスは、ドメインＣ，ネットワーク５７，ノード Ｄ，ソケットＹとなり、ソースノードＳの完全なアドレスはドメインＡ，ネット ワーク５７，ノードＳ，ソケットＸとなる。このアドレシング方式はインタード メイン・ルータを一意的に指定する宛先ネットワーク・アドレスに対して特別な ネットワーク値、例えば「２７」を定義することにより、従来と改良されたＩＰ Ｘヘッダ・フォーマットの両方に適合するように構成できる。このネットワーク 値を指定するパケットを受信した他のドメイン内ルータは適当なノードへパケッ トを単純にルーティングする。 適当なインタードメイン・ルータがパケットを受信すると、ネットワーク上に パケットをフォワーディングする前に拡張ヘッダ・フィールドの内容を検証する ようにルータに指示する特別なソケット値、例えば「５５」を復号する。前述の ように、拡張ヘッダ・フィールドの内容は、宛先及びソースのドメイン番号と併 せて、実際の宛先ソケット及びネットワーク番号を含む。 動作的には、ドメインＡのソースノードＳがネットワーク層ヘッダの宛先ネッ トワーク及びソケット番号をこれらの特別な値（すなわち、それぞれ「２７」と 「５５」）にセットしてからドメインＣの宛先ノードＤへパケットを送出する。 パケットはネットワーク上に送信され、中間にあるドメイン内ルータは特別なネ ットワーク値に基づいて適切なインタードメイン・ルータへパケットを単純にフ ォワーディングする。場合によっては、バックボーン・ネットワーク６１０に数 個の異なるインタードメイン・ルータが接続されていることがあり、そのそれぞ れが特別なネットワーク値「２７」に応答する場合がある。ソースノードＳとす べてのドメイン内ルータはバックボーン・ネットワークに接続された最も近いイ ンタードメイン・ルータへパケットをフォワーディングする。ドメインＡにある すべてのルータは特別なネットワーク値に基づいてパケットをルーティングする ので、本発明の構造では、各ルータがインタードメイン・ルータ例えばルータＡ に高速フォワーディング・デシジョンを生成できる。 ルータに到達すると、宛先ネットワーク・アドレスの特別なソケット値「５５ 」にしたがってパケットが分析される。つまり、インタードメイン・ルータＡは 拡張ヘッダ・フィールドの内容を調べて、これに対応する宛先ドメイン番号がパ ケット内で指定されているか判定する。拡張ヘッダ・フィールド内に含ま れる宛先ドメイン番号はＣであるから、インタードメイン・ルータＡはインター ドメイン・ルータＣへパケットをフォワーディングする。パケットがインタード メイン・ルータＣに到達すると、ルータＣは宛先ネットワーク番号の特別な値を 拡張ヘッダ・フィールドに含まれる実際の宛先ネットワーク番号で置き換え（「 上書き」）し、ネットワーク５７の宛先ノードＤへパケットをルーティングする 。 宛先ノードＤでは、そのコンピュータ上で実行されている各プロセスが所定の ソケット、例えばソケット番号Ｙを「聴取(listens)」している。アドレスされ たそのソケットに応答するプロセスがない場合、宛先ノードＤはパケットをドロ ップする。つまり、宛先ノードがソケットと内部プロセスを関連付けられない場 合、パケットを破棄する。しかし、指定されたソケット番号Ｙをモニタしている プロセスが存在する場合、そのプロセスがパケットを受け取り処理する。これは 従来のノードを含む宛先ノードが本発明による拡張ヘッダ・フィールド・パケッ ト構造により混乱しないことを保証するものである。 要約すると、本発明は慣用のドメイン内ルータの更新を回避するような方法で 見かけ上不変なパケット・フォーマットからネットワーク・アドレスを拡張する ための技術を提供する。本発明によるアドレシング構造を解釈するようにインタ ードメイン・ルータだけを構成すれば良いので、本技術は既存のルータに対する 互換性が得られるという利点を提供する。 さらに、本発明によるアドレシング構造はネットワーク層アドレスの別のセク ションに基づくルーティングを容易にする。本発明のこの特徴は多くのルータが パケットのフォワーディング前にネットワーク層ヘッダの指定された部分、すな わち４バイトの宛先ネットワーク番号フィールドを検証する必要しかないことか らネットワーク・アドレシングの効率を向上させるものである。インタードメイ ン・ルータだけがアドレシング情報の残りの部分を検証する必要がある。 新規な技術を実現するように構成されていないノード例えばドメイン内ルータ やある種の宛先ノードと互換性を得られるような方法でネットワーク層ヘッダと ノードのアドレス空間を拡張するための新規な構造を実現するための代表的実施 例を図示し説明したが、本発明の趣旨と範囲内でその他各種適応及び変更を成し 得ることは理解されるべきである。例えば、拡張ヘッダ・フォーマットを用いる ソースノードの送信プロセスは、宛先ノードがこのフォーマットを理解しない場 合があることに注意する必要がある。宛先ノードが新規なヘッダ・フォーマット を実現するように設定されていないとの指標がない場合、ソースは従来通りと新 規な種類のヘッダ・パケットの両方を送信して情報の受信を保証すべきである。 前述の説明は本発明の特定の実施例を指向したものである。しかし本発明の利 点の幾つかまたは全部を実現しつつ説明した実施例に対してその他の変化及び変 更を行えることは明らかであろう。従って、添付の請求項の目的は本発明の真の 趣旨と範囲内に含まれるものとしてこれらすべての変化及び変更を内包すること にある。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＡＭ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｃ Ａ，ＣＮ，ＣＺ，ＥＥ，ＧＥ，ＨＵ，ＩＬ，ＩＳ，ＪＰ ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＶ， ＭＤ，ＭＧ，ＭＮ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＲＯ，Ｒ Ｕ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ，ＵＡ，ＵＺ ，ＶＮ

Claims (1)

1. 【特許請求の範囲】 １．インタードメイン・ルータにより相互接続された複数のドメインを有するコ ンピュータ・ネットワークに接続されたノードのアドレス空間を拡張し、パケッ トの一部を形成して前記パケットを受信する宛先ノードを識別する階層化宛先ア ドレス・エレメントを格納するためのアドレス・フィールドを含むネットワーク 層ヘッダであって、 前記インタードメイン・ルータを一意的に識別するための手段と、 既存のルータ及びノードと互換性がある方法で前記ネットワーク層ヘッダを拡 張するための手段と、 を含むことを特徴とするネットワーク層ヘッダ。 ２．前記拡張手段は前記ネットワーク層ヘッダのバージョン・フィールド及び種 別フィールドの一方の内容を置き換えるための特別な値を含む ことを特徴とする請求項１に記載のネットワーク層ヘッダ。 ３．前記拡張手段は前記アドレス・フィールドに追加された拡張ヘッダ・フィー ルドの提供を表わし前記階層化宛先アドレスの宛先ソケット・エレメントに置き 換わる特別なソケット値を含む ことを特徴とする請求項１に記載のネットワーク層ヘッダ。 ４．インタードメイン・ルータにより相互接続された複数のドメインを有するコ ンピュータ・ネットワークに接続されているノードのアドレス空間を拡張し、パ ケットの一部を形成して前記パケットを受信する宛先ノードを識別する階層化宛 先アドレス・エレメントを格納するためのアドレス・フィールドを含む改良され たネットワーク層ヘッダであって、 前記インタードメイン・ルータを一意的に識別し前記階層化宛先アドレスの宛 先ネットワーク・エレメントに置き換わる特別なネットワーク値と、 前記アドレス・フィールドに追加された拡張ヘッダ・フィールドの提供を表わ し前記階層化宛先アドレスの宛先ソケット・エレメントに置き換わる特別なソケ ット値と、 を含むことを特徴とする改良されたネットワーク層ヘッダ。 ５．前記宛先ノードのドメインを一意的に識別するための新規な宛先ドメイン番 号をさらに含む ことを特徴とする請求項４に記載の改良されたネットワーク層ヘッダ。 ６．前記拡張ヘッダ・フィールドは実際の宛先ソケット及びネットワーク番号と 併せて前記新規な宛先ドメイン番号を含む ことを特徴とする請求項５に記載の改良されたネットワーク層ヘッダ。 ７．ネットワーク層ヘッダ・フォーマットと、インタードメイン・ルータで相互 接続された複数のドメインを有するコンピュータ・ネットワークに接続されてい るノードのアドレス空間とを拡張するための方法であり、前記ヘッダがパケット の一部を形成して前記パケットを受信する宛先ノードを識別する階層化宛先アド レス・エレメントを格納するためのアドレス・フィールドを含む方法であって、 前記方法は、 前記インタードメイン・ルータを一意的に識別する特別なネットワーク値で前 記階層化宛先アドレスの宛先ネットワーク・エレメントを置き換えるステップと 、 前記階層化宛先アドレスの宛先ソケット・エレメントの代わりに、前記アドレ ス・フィールドに追加された拡張ヘッダ・フィールドの提供を表わす特別なソケ ット値で置き換えるステップと、 を含むことを特徴とする方法。 ８．前記宛先ノードのドメインを一意的に識別するための新規な宛先ドメイン番 号を提供するステップをさらに含む ことを特徴とする請求項７に記載の方法。 ９．前記拡張ヘッダ・フィールドの実際の宛先ソケット及びネットワーク番号と 併せて前記新規な宛先ドメイン番号を記憶するステップをさらに含む ことを特徴とする請求項８に記載の方法。