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

Description

【発明の詳細な説明】 発明の分野 本発明は一般にコンピュータ・ネットワークに関し、
さらに詳しくは、コンピュータ・ネットワークに接続さ
れたノードのアドレス空間の拡張に関する。

発明の背景 コンピュータ・ネットワークはコンピュータなどのノ
ード間でデータを伝送するために相互接続されている通
信リンクの地域的に分散した集合体である。ローカル・
エリア・ネットワーク（LAN）から広域ネットワーク（W
AN）まで、多くの種類のコンピュータ・ネットワークが
利用可能になっている。LANはたとえば同軸ケーブルや
ツイステッドペア線などの伝送媒体で構成されることの
多い限定領域内のネットワークで、WANは通信リンクを
用いて広範囲に分散したノードを相互接続する公衆また
は専用の電気通信設備である。これらのノードは所定の
プロトコルにしたがってデータの独立した「パケット」
を交換することにより通信するのが代表的である。この
状況で、プロトコルはノード同士がどのように相互作用
するかを定義した一組のルールから構成されている。

コンピュータ・ネットワークはルータとよばれる中間
ノードによりさらに相互接続されてそれぞれのネットワ
ークの実効的「サイズ」を拡張できる。相互接続された
コンピュータ・ネットワークの大きなシステムの管理は
厄介になることがあるので、コンピュータ・ネットワー
クの小さいグループを自律的なシステムまたはドメイン
として維持し、ドメイン内のネットワークを慣用の「イ
ントラ・ドメイン」ルータにより相互に接続するのが代
表的である。データ交換が可能なノード数を増加するの
がさらに望ましいことがあり、この場合、ドメイン間の
ルーティング・プロトコルを用いてドメインのノード間
の相互作用が出来るようにする。

設計の複雑さを減らすため、多くのネットワークは各
ノード内部で一連のハードウェアとソフトウェアのレベ
ル、または「レイヤ（層）」として構成される。これら
の層が相互作用して、たとえばネットワーク上で通信す
るソースノードと宛先ノードの間の転送用にデータをフ
ォーマットする。さらに詳しくは、データが各レイヤを
通過するとそのデータに対して所定のサービスが実行さ
れ、レイヤ同士が所定のプロトコルにしたがって通信す
る。このように階層化した設計により、各レイヤはサー
ビスの実際の実施詳細からレイヤを遮蔽する標準化イン
タフェースを用いて、他のレイヤへ選択されたサービス
を提供できる。

ネットワーク・アーキテクチャ、即ちネットワーク内
で使用されるレイヤとプロトコルの組を標準化しようと
する試みにおいて、国際標準化機構（ISO）により一般
化したモデルが提案された。このモデルはOSI（Open Sy
stems Interconnection）参照モデルと呼ばれ、他のシ
ステムとの通信に「オープンな」システムの相互接続を
指向したものである。提案されているOSIモデルは７層
からなり、下からの順番で物理層、データリンク層、ネ
ットワーク層、トランスポート層、セッション層、プレ
ゼンテーション層、アプリケーション層と呼ばれる。こ
れらのレイヤはネットワークの各ノードで「プロトコル
スタック」を形成するように構成されている。

図１はコンピュータ・ネットワーク100のソースノー
ド110と宛先（destination）ノード150の間でデータを
送信するためにそれぞれ使用される従来技術のプロトコ
ルスタック125、175の模式的ブロック図を示したもので
ある。各プロトコルスタックはOSI7層モデルに従った構
成になっており、各スタックはレイヤ毎に１つづつのプ
ロトコル集合を含む。理解されるように、プロトコルス
タック125および175は物理層124および164で通信チャン
ネルを介して物理的に接続される。説明を簡単にするた
め、プロトコルスタック125について説明する。

大まかに言うと、物理層124は通信チャンネル180上に
生データ・ビットストリームを送信し、一方データリン
ク層はビットストリームを操作し送信エラーの見られな
いデータストリームに変換する。後者のタスクは送信デ
ータをフレームに分割し、フレームを順次送信すること
で達成され、エラーの検出または訂正のためのエラー訂
正メカニズムが伴う。ネットワーク層120は物理ネット
ワークを通る多くの代替パスの１つを選択することによ
ってソースノードから宛先ノードへデータ・パケットを
ルーティングする。トランスポート層118はセッション
層116からのデータストリームを受け取り、（必要な
ら）もっと小さい単位に細分して細分したユニットをネ
ットワーク層120へ渡し、全てのユニットが宛先に正し
く到着することを保証する適当なメカニズムを提供す
る。

セッション層116はソースおよび宛先ノード上のソフ
トウェア・プロセス間にデータ転送「セッション」を確
立し併せて順序だった当該セッションの管理を行なう。
つまり、セッションはノード間の通常のデータ転送を行
なえるようにする以外に、何らかのアプリケーションに
拡張サービスを提供する。プレゼンテーション層114は
送信データのプレゼンテーションに関連して、標準フォ
ーマットへのデータ符号化を含め頻繁に要求される機能
を実行し、アプリケーション層112はノード上で実行中
のプロセスで一般に必要とされる各種のプロトコルを含
んでいる。

つまりネットワーク100上のデータ送信はたとえばソ
ースノード110上で実行されている送信プロセス104でデ
ータを一般化し、そのデータをアプリケーション層112
へ渡し、さらにプロトコルスタック125の各層を下向き
に通り、ビットとしてチャンネル180へ供給するパケッ
トの形にデータが順次フォーマットされる。これらのパ
ケット・ビットが宛先ノード150のプロトコルスタック1
75へ向けて送信され、宛先ノードではスタックを上り受
信プロセス174へ渡される。データフローは実線矢印で
模式的に図示してある。

実際のデータ送信はスタックを縦方向に通過するが、
各層は送信が水平方向に通るようにプログラムされてい
る。つまり、ソースノード100の各層は宛先ノード150で
これに対応する層へ、模式的に破線矢印で示したよう
に、データを送信するようにプログラムされている。こ
れを行なえるようにするには、パケットがスタックを下
降する際に、ソースノード110内のプロトコルスタック1
25の各層が送信プロセスにより生成されたデータ・パケ
ットへ（ヘッダ・フィールドの形で）情報を追加するの
が一般的である。宛先ノード150では、受信プロセスに
到着するまでパケットがスタック175の層を上へ伝わる
際に、各種ヘッダが１つづつ取り除かれる。

前述のように、OSIモデルにおける各層の顕著な機能
は他の層へのサービスを提供することである。各層で提
供される２種類のサービスが「コネクション指向（conn
ection−oriented）」および「コネクションレス」ネッ
トワーク・サービスである。接続指向サービスでは、ソ
ースノードが宛先ノードとの接続を確立し、パケットの
送信後、接続を終了する。接続を確立することに伴うオ
ーバヘッドは効率的通信性能を要求するノードでは不要
である。この場合、各々の送信パケットがネットワーク
経由で宛先の完全なアドレスを伝送するような完全コネ
クションレス・サービスが望ましい。

ネットワーク層プロトコルはコネクションレス・ネッ
トワーク・サービスを実施するために用いられるのが一
般的で、このサービスが主としてパケット・フォーマッ
トを定義している。ネットワーク層がネットワーク上へ
の送信のためにトランスポート層からパケットを受信す
ると、特にソース・アドレスと宛先アドレスを含むヘッ
ダを（パケットに）追加する。ネットワーク層プロトコ
ルの例としては、ISOにより定義されているコネクショ
ンレス・ネットワーク層プロトコル（CLNP）、インター
ネット（IP）ネットワーク層プロトコル、インターネッ
ト・パケット交換（IPX）プロトコルが挙げられる。

ネットワーク層サービスにより定義されるヘッダ・フ
ィールドは、主に各パケットに同じ情報が代表的に含ま
れるため一般に同一である。例えば、こうしたヘッダの
大部分は、ネットワークに接続された比較的多数のノー
ドに対応できるように構成された固定長階層化アドレス
を含む。IPXヘッダの場合、ソース及び宛先アドレスは
階層化されており４バイトのネットワーク番号、６バイ
トのノード番号、及び２バイトのソケット番号を含む複
数のエレメントから構成される。例外としてはCLNPヘッ
ダがあり、これは潜在的に広範囲のネットワーク層アド
レスを取り扱うように構成されている。しかし、これら
のヘッダ全部のアドレス拡張は、アドレスフィールドの
ほぼ固定されたフォーマットからなり同時にこれによっ
て大幅に制約される。

CLNP及びIPヘッダの全体的なパケット・フォーマット
はヘッダ内部に含まれるオプション・フィールドを用い
て追加機能に対応するように拡張できる。これらのフィ
ールドでサポートされるオプションの種類としては、代
表的にソース・ルーティング、プライオリティおよび保
安仕様情報（securityspecific information）が含まれ
る。しかし、従来のIPXヘッダ・フォーマットは一般に
パケットの残りのフィールドと互換性がある方法で追加
フィールドに対応するように設計されなかったため一般
に拡張不可能である。

発明の概要 本発明はコンピュータ・ネットワークに接続されたノ
ードのアドレス空間を、当該ネットワークの異るドメイ
ンのノード間ルーティングを効率的に拡張するような方
法で、拡張するためのネットワーク・アドレシング構造
の改良を含む。つまり、新規の構造は、従来の階層化ネ
ットワーク層アドレスに新規のエレメントを提供し既存
のエレメントすなわちそのアドレスの宛先ネットワーク
及びソケット番号を変更して改良されたネットワーク層
ヘッダを効率的に作成することによりネットワーク・ア
ドレシングを改善するものである。

さらに、ネットワーク・アドレシング構造では、イン
タードメイン・ルータすなわち対応するドメイン内部に
あってネットワークを横断して他のドメインに到達する
ことの出来るルータの能力を最大限に発揮させる改良さ
れたネットワーク層ヘッダの拡張ヘッダ・フィールド・
フォーマットが可能になり、同時に従来のドメイン内ル
ータが慣用のネットワーク層ヘッダを構成するフィール
ド内容に対して障害なく動作を継続することを保証でき
る。

さらに詳しくは、本発明の構造はインタードメイン・
ルータを一意的に識別する特別のネットワーク値を提供
して従来のネットワーク・アドレスの宛先ネットワーク
番号をその値に起き換える。宛先ソケット番号に対して
特別なソケット値がさらに提供され、特別なソケット値
がヘッダのソース・アドレス・フィールドの後の追加拡
張ヘッダ情報の提供を表わす。さらに、本構造は適当な
宛先及びソース・ドメインを識別する新規なドメイン番
号を提供する。前述のように、ドメイン番号は従来のネ
ットワーク・アドレスに追加され、ネットワーク層ヘッ
ダがほぼ固定フォーマットであるため、拡張ヘッダ・フ
ィールドに格納される。

本発明の代表的実施例において、各インタードメイン
・ルータはこれの対応するドメインをバックボーン・ネ
ットワークに接続する。動作的には、ソースノードが異
なるドメイン内部の宛先ノードへパケットを送出する前
にこれらの特別な値に宛先ネットワーク及びソケット番
号をセットする。実際の宛先ネットワーク及びソケット
番号は、新規な宛先ドメイン番号といっしょに、パケッ
トの拡張ヘッダ・フィールド内に格納される。この後パ
ケットはネットワーク上に送信され、挿入された宛先ネ
ットワーク値がインタードメイン・ルータを一意的に識
別するため、従来のドメイン内ルータはこの値に基づい
てパケットを適当なインタードメイン・ルータへ単にフ
ォワーディングする。

インタードメイン・ルータに到達すると、パケットが
ネットワーク宛先アドレスの特別なソケット値にしたが
って分析される。すなわち、ルータは拡張ヘッダ・フィ
ールドの内容を調べてこれに対応する宛先ドメイン番号
がパケットで指定されているか判定する。インタードメ
イン・ルータが指定されたルータではない場合、パケッ
トはそのドメイン番号に基づいてさらにルーティングさ
れる。パケットが所望の宛先ドメインに接続する適当な
インタードメイン・ルータへ到達すると、そのルータは
特別な値を実際の宛先ネットワーク及びソケット番号に
置き換え、パケットを適当な宛先ノードへルーティング
する。

有利にも、本発明は従来のインタードメイン・ルータ
のアップグレードを回避するような方法で見かけ上不変
なパケット・フォーマットからネットワーク・アドレス
を拡張するための技術を提供する。本発明のアドレシン
グ構造を解釈するようにインタードメイン・ルータだけ
を構成すれば良いので、本技術は既存のルータと互換性
を有する。

さらに、本発明はネットワーク層アドレスの異なるセ
クションに基づいてルーティングを容易にする。これは
多くのルータがパケット・フォワーディングの前にネッ
トワーク層ヘッダの指定された部分、すなわち４バイト
の宛先ネットワーク番号フィールドを検証するだけで済
むので、ネットワーク・アドレシングの効率を向上する
ことが出来る。インタードメイン・ルータだけはアドレ
シング情報の残りの部分を検証する必要がある。

図面の簡単な説明 本発明の上記の及びそれ以外の利点は添付の図面との
関連において以下の説明を参照することにより、一層良
く理解されよう。図面においては同じ参照番号で類似の
要素を表わしており、 図１はコンピュータ・ネットワークのソースノードと
宛先ノードの間でデータを転送するために使用される従
来技術のプロトコルスタックの模式的ブロック図であ
る。

図２は複数のノードに接続されたコンピュータ・ネッ
トワークの集合を含むコンピュータ・ネットワーク・ド
メインのブロック図である。

図3A〜図3Cは本発明による新規なネットワーク・アド
レシング構造に関する情報を記憶するためのオプション
・フィールドを備える慣用のネットワーク層ヘッダのフ
ォーマットを示す略図である。

図４は従来のIPXネットワーク層ヘッダのフォーマッ
トを示す模式図である。

図５は新規なネットワーク・アドレシング構造に基づ
く図４のIPXネットワーク層ヘッダの改良フォーマット
を示す模式図である。

図６はバックボーン・ネットワークに接続された複数
のドメインを含み本発明の新規なネットワーク・アドレ
シング構造を有利に使用できるような相互接続されたコ
ンピュータ・ネットワークのシステムの略ブロック図で
ある。

代表的実施例の詳細な説明 図２は複数のノードに接続されたコンピュータ・ネッ
トワークの集合を含むネットワーク・システム200のブ
ロック図である。ノードはソースノードＳ、末端ノード
Ｎ、宛先ノードＤ、複数の中間ノードR1〜R2からなる汎
用コンピュータが代表的である。各ノードは代表的に
は、システムバス210で相互接続されている中央演算処
理ユニット（CPU）202、メモリ・ユニット204、および
少なくとも１個のネットワーク・アダプタ206を含む。
メモリ・ユニット204はランダム・アクセス・メモリ（R
AM）デバイスから構成されるのが代表的な記憶ロケーシ
ョンを含み、CPU202およびネットワーク・アダプタ206
からアドレス可能である。代表的には一部がメモリに常
駐してCPUにより実行されるオペレーティング・システ
ムは、特にCPUで実行するプロセスのサポートにおいて
ネットワーク動作を実行することにより、機能的にノー
ドを構成する。

ネットワーク・システム200内部に含まれるコンピュ
ータ・ネットワークは中間ノードR1及びR2により相互接
続されたローカル・エリア・ネットワーク（LAN）１〜
３である。LANに接続されたノード間の通信は代表的に
は例えばソースと宛先ノードのアドレスを指定する独立
したデータ「パケット」を交換することにより行われ
る。本システムは相互接続されたLANの比較的少数のグ
ループを含むことから、自律的ドメインとして維持され
るのが望ましい。中間ノードは正しい受信ノードへパケ
ットをルーティングすることでドメイン200全体のデー
タ・パケットのフローを容易にするように構成されたイ
ンタードメイン・ルータが望ましい。

一般に、ソースノードＳがLAN1上にパケットを送信す
る際に、パケットはそのLAN上にある全ノードに送信さ
れる。意図しているパケット受け手がLAN3に接続されて
いる場合、パケットはルータR1を通りLAN2へまたR2を通
ってLAN3へルーティングされる。ルータの重要な機能は
パケットが送信される次のノードを決定することで、こ
のルーティング機能は各ノード内部のプロトコル・スタ
ック250のネットワーク層260で行われるのが望ましい。
代表的には、パケットは２種類の宛先アドレスを含む。
最終的な宛先ノードのアドレスと、ルートに沿った次の
ノードのアドレスである。最終的宛先アドレスはパケッ
トがネットワークを横断しても一定のままだが、次の宛
先アドレスは、ネットワークを通るルートに沿ったノー
ドからノードへパケットが移動すると変化する。

さらに詳しくは、ソースノードＳは宛先ノードＤへ、
すなわち最終宛先アドレスへパケットを送出する場合、
パケットをLAN1へ送信し、次の宛先アドレスでルータR1
のアドレスを指定する。パケット内に埋め込まれてプロ
トコルスタック250の高層部ソフトウェアにより処理さ
れるアドレス情報はパケットの最終宛先をノードＤに指
定する。この情報に基づいて、R1はルートに沿った次の
ノードがルータR2であることを判定し、そのノードが受
信できるようにLAN2へパケットを渡す。ルータR2は次の
ノードが最終宛先ノードＤであると判定し、パケットを
LAN3上でノードＤへ送信する。

ルータR1及びR2をドメイン200で使用するには相互接
続されたネットワークが同一のネットワーク層プロトコ
ルを共有する必要があり、また高次のプロトコル・スタ
ック層で互換性がある必要がある。しかしLAN1をLAN2に
接続するR1のプロトコルスタック250に模式的に図示し
てあるようにネットワークはデータリンク層262と物理
層264では異っている。ルータはコネクションレス・ネ
ットワーク層プロトコル（CLNP）やインターネット（I
P）ネットワーク層プロトコル等のネットワーク層プロ
トコルで動作できるが、本明細書で説明している代表的
実施例において、ネットワーク層プロトコルはインター
ネット・パケット交換（IPX）プロトコルが望ましい。

前述のように、ネットワーク層260がネットワーク上
への送信のためにトランスポート層258からパケットを
受信すると、ネットワーク層ヘッダを追加する。このよ
うなヘッダ・フィールドのフォーマットは主として各パ
ケットに代表的に同じ情報が含まれることから、すべて
のネットワーク層サービスの間で一般に同一である。図
3A及び図3BはそれぞれIP及びCLNPネットワーク層パケッ
ト310と350のフォーマットを示す。これらのパケットは
両方ともヘッダ312及び352（例えばバージョン番号フィ
ールド314及び354）に同様の情報を含むことが分かる。
さらに詳しく説明すると、各ヘッダは追加される機能に
対応するためのオプション・フィールド326及び366を含
む。これらのフィールドでサポートされるオプションの
種類としては、ソース・ルーティング、プライオリテ
ィ、保安仕様情報が含まれる。図3Cは、オプション・フ
ィールド380の内容の一般フォーマットを示したもの
で、これにはオプションの種類を一意的に定義する１オ
クテット（１バイト）のオプション・コード・フィール
ド382、オプションの長さをバイト数で表わす１バイト
長フィールド384、および可変例えば０〜254バイトの値
フィールド386を含む。

図４は約30バイトのネットワーク層ヘッダを有する従
来のIPXパケット400のフォーマットを示す略図である。
さらに詳しくは、ヘッダは２バイトのチェックサム・フ
ィールド402、２バイトのパケット長フィールド404、１
バイトのホップ（hop）・カウント・フィールド406およ
び１バイトのパケットタイプ・フィールド408を含む。
ヘッダが多くのネットワーク層サービスで定義されてい
る場合では、IPXヘッダは固定長で階層化した宛先及び
ソース・アドレスを含み、そのそれぞれが複数のアドレ
ス・エレメントを含む。つまり、宛先アドレス410はパ
ケットが伝送される特定のネットワークを表わす４バイ
トの宛先ネットワーク・フィールド412、ネットワーク
上の受信ノードのデータリンク層アドレスを識別する６
バイトの宛先ノード・フィールド414、および受信ノー
ドにおける受信プロセスを指定する２バイトの宛先ソケ
ット・フィールド416を含む。同様に、ソース・アドレ
ス420は４バイトのソース・ネットワーク・フィールド4
22、６バイトのソースノード・フィールド424、および
２バイトのソース・ソケット・フィールド426を含む。
データ・フィールド430はソース・アドレス・フィール
ド420の直後にヘッダに追加される。前述したような従
来の階層化アドレスは従来のドメイン内ルータR1及びR2
を用いてドメイン200のコンピュータ・ネットワークに
接続されているノード間のデータのルーティングに対応
するのに十分である。しかしインタードメイン・ルー
タ、すなわち対応するドメイン内部でネットワークを横
断して他のドメインに到達することの出来るルータによ
り、各種ドメインを相互接続することでデータ交換出来
るノード数を増加させるのが望ましい。これには各ドメ
インに接続されたノードのアドレス空間を拡張する必要
がある。しかし、IPXヘッダ（及び多くのネットワーク
層ヘッダ）でのアドレス拡張はアドレス・フィールドの
固定フォーマットのために通常は制限されている。さら
に、従来のIPXパケット400の固定フォーマットは、パケ
ットの残りのフィールド、例えばデータ・フィールド43
0と互換性のある方法で拡張ヘッダ・フィールドに対応
するような拡張が出来ない。

本発明によれば、ネットワークの異なるドメイン間で
のルーティングを効率的に拡張するような方法で、コン
ピュータ・ネットワークに接続されたノードのアドレス
空間を拡張する新規な構造が提供される。さらに詳しく
は、この構造は従来の階層化ネットワーク・アドレスに
ドメイン・エレメントを追加することでネットワーク・
アドレシングを改良するものである。IPXプロトコルの
場合、ネットワーク・アドレシングは従来のアドレスの
宛先ネットワーク及びソケット・エレメントを変更して
改良ネットワーク層ヘッダを効率的に作成することで改
良され、一方でIP及びCLNPプロトコルでは、新規のドメ
イン・エレメントをオプションとして含むことが出来
る。このような改良で新しい情報を解読するように構成
したインタードメイン・ルータの能力を最大限に発揮さ
せ、同時に従来のドメイン内ルータは慣用のネットワー
ク層ヘッダを構成する情報フィールドの内容について動
作し続けるように保証する。

図５は改良されたネットワーク層ヘッダ500のフォー
マットを示す模式図である。新規な構造によれば、イン
タードメイン・ルータを一意的に識別する特別なネット
ワーク値552が提供される。IPXヘッダの場合、主として
ルーティングは宛先ネットワーク番号に基づくため、ソ
ースノードが慣用のネットワーク層宛先アドレス410
（図４）の４バイト宛先ネットワーク・フィールド412
内部の実際の宛先ネットワーク番号をこの特別なネット
ワーク値に置き換える。しかしIP及びCLNPヘッダでは、
特別な宛先アドレス値で実際の宛先アドレス324および3
62（図3A及び図3B）を置き換えることが出来る。

さらに、この構造は既存のルータ及び宛先ノードと互
換性の取れるような方法で固定長アドレスを有するネッ
トワーク層ヘッダのフォーマット拡張を提供する。IPX
ヘッダの場合、ソースノードは従来のアドレスの２バイ
ト宛先ソケット・フィールド416内部の実際の宛先ソケ
ット番号を特別なソケット値556に置き換える。望まし
くは、特別なソケット値はパケットのソースアドレス・
フィールドの後に追加のヘッダ情報の提供を表わす。さ
らに詳しくは、特別なソケット値がパケットをネットワ
ーク上にフォワーディングする前に拡張ヘッダ・フィー
ルド560の内容を検証するようにインタードメイン・ル
ータに指示する。その他のネットワーク層ヘッダ、例え
ばIPやCLNPでは、ヘッダ拡張はバージョン・フィールド
（図3A及び図3Bのそれぞれ参照番号314及び354を参照）
またはタイプ・フィールド（316及び356で図示してあ
る）のどちらかで特別な値により表わされる。

さらに、本発明の構造は相互接続ドメインを一意的に
識別するための新規なドメイン番号を提供する。前述の
ように、これらのドメイン番号はIP及びCLNPパケット31
0及び350のそれぞれのヘッダ・オプション・フィールド
326及び366でオプションとして提供できる。図3Cを参照
すると、新規のオプション種別はドメインについて定義
され、オプション種別は特にソース及び宛先ドメインを
一意的に指定しフィールド382に格納されるオプション
・コード例えば「DOMAIN」を含む。

しかしIPXネットワーク層ヘッダ500の通常は固定され
ているフォーマットのため、ドメイン番号はそのヘッダ
の拡張ヘッダ・フィールド560に格納される。さらに詳
しくは、宛先ドメイン番号562が宛先ノードのドメイン
を指定し、ソースドメイン番号564でパケットを生成す
るソースノードのドメインを識別する。このような拡張
ヘッダ・フィールド内には実際の宛先ソケット番号566
及び実際の宛先ネットワーク番号568も含まれている。

本発明によれば、インタードメイン・ルータはヘッダ
500の拡張フィールド560内部の補助情報を解読しこれに
基づいて機能するように構成され、従来のドメイン内ル
ータは拡張アドレシングを実装するように構成されてい
ないので、ネットワークの動作を妨害することなくこの
情報を単純に無視することが出来る。この互換性の特徴
は、パケットの宛先アドレス410のネットワーク・フィ
ールド412内部に含まれる特別なネットワーク値552がイ
ンタードメイン・ルータを一意的に識別するため可能で
あり、パケットを受信したドメイン内ルータはヘッダの
宛先ネットワーク・フィールドの内容だけに基づいて適
当なインタードメイン・ルータへそのパケットを単純に
フォワーディングする。

拡張ヘッダ・フィールドは可変サイズとして追加の特
徴に対応できるのが望ましい。例えば、新規の拡張ヘッ
ダ・フォーマットでは中間ルータの幾つかまたは全部が
本発明の構造を実現するように構成されていればソース
ノードがある程度の最適化を利用できる。これらの最適
化には、特定パケットの（通常のではなく）緊急送信供
給を優先することや、問題が起こったためルータがパケ
ットを「ドロップした」場合にエラーレポートを要求す
ることが含まれる。後者の特徴はパケットの再送が有効
かどうか判定するのに十分な情報をソースノードに提供
する。改良IPXヘッダに関連して、可変サイズの拡張ヘ
ッダではパケット内の互換性のある位置に将来他の最適
化を追加することが出来る。

改良ネットワーク層ヘッダ500内部に含まれる拡張ア
ドレスの動作について、図６に図示してある相互接続さ
れたコンピュータ・ネットワークのシステムとの関連で
説明する。システム600はバックボーン・ネットワーク6
10に接続された複数のドメインＡ〜Ｃを含む。代表的実
施例において、ドメインは独立したIPXネットワーク、
たとえばノベル社製IPXネットワークやマイクロソフト
社製IPXネットワーク等を含み、バックボーン・ネット
ワークはAT＆T/IPXインターネットとすることが出来
る。

各ドメインの内部で、ルーティングは４バイトの宛先
ネットワーク番号412（図４）に基づいているので、こ
れらの番号は各IPXネットワーク・ドメイン内部で一意
的になるように割り当てられている。また、各ドメイン
はバックボーン・ネットワークに接続される時にユニー
クなドメイン番号が動的に割り当てられる。あるドメイ
ンが別の時刻または場所でバックボーン・ネットワーク
に「フック」されるように再構成してあり新しいドメイ
ン番号が割り当てられる場合にはドメイン内のアドレス
を再割り当てする必要がないためこれは有意である。

各ドメインは本明細書で説明している余剰レベルのア
ドレシングにしたがって動作するように構成されていな
いドメイン内ルータも含んでいる。尚且つドメインＡの
ソースノードＳは別のドメイン、例えばドメインＣにあ
る宛先ノードＤと通信できる必要がある。したがって、
各ドメインはこれに対応するドメインをバックボーン・
ネットワーク610に接続する少なくともひとつのインタ
ードメイン・ルータを含む。

図６から分かるように、ドメインＡとＣに含まれるLA
Nは同様のネットワーク番号例えば57を有している。さ
らに、ドメインＣの宛先ノードＤは、データリンク層ア
ドレスＤとソケット番号Ｙを有し、一方でドメインＡに
あるソースノードＳはデータリンク層アドレスＳとソケ
ット番号Ｘを有している。したがって宛先ノードＤの完
全なアドレスは、ドメインC,ネットワーク57,ノードD,
ソケットＹとなり、ソースノードＳの完全なアドレスは
ドメインA,ネットワーク57,ノードS,ソケットＸとな
る。このアドレシング方式はインタードメイン・ルータ
を一意的に指定する宛先ネットワーク・アドレスに対し
て特別なネットワーク値、例えば「27」を定義すること
により、従来と改良されたIPXヘッダ・フォーマットの
両方に適合するように構成できる。このネットワーク値
を指定するパケットを受信した他のドメイン内ルータは
適当なノードへパケットを単純にルーティングする。

適当なインタードメイン・ルータがパケットを受信す
ると、ネットワーク上にパケットをフォワーディングす
る前に拡張ヘッダ・フィールドの内容を検証するように
ルータに指示する特別なソケット値、例えば「55」を復
号する。前述のように、拡張ヘッダ・フィールドの内容
は、宛先及びソースのドメイン番号と併せて、実際の宛
先ソケット及びネットワーク番号を含む。

動作的には、ドメインＡのソースノードＳがネットワ
ーク層ヘッダの宛先ネットワーク及びソケット番号をこ
れらの特別な値（すなわち、それぞれ「27」と「55」）
にセットしてからドメインＣの宛先ノードＤへパケット
を送出する。パケットはネットワーク上に送信され、中
間にあるドメイン内ルータは特別なネットワーク値に基
づいて適切なインタードメイン・ルータへパケットを単
純にフォワーディングする。場合によっては、バックボ
ーン・ネットワーク610に数個の異なるインタードメイ
ン・ルータが接続されていることがあり、そのそれぞれ
が特別なネットワーク値「27」に応答する場合がある。
ソースノードＳとすべてのドメイン内ルータはバックボ
ーン・ネットワークに接続された最も近いインタードメ
イン・ルータへパケットをフォワーディングする。ドメ
インＡにあるすべてのルータは特別なネットワーク値に
基づいてパケットをルーティングするので、本発明の構
造では、各ルータがインタードメイン・ルータ例えばル
ータＡに高速フォワーディング・デシジョンを生成でき
る。

ルータに到達すると、宛先ネットワーク・アドレスの
特別なソケット値「55」にしたがってパケットが分析さ
れる。つまり、インタードメイン・ルータＡは拡張ヘッ
ダ・フィールドの内容を調べて、これに対応する宛先ド
メイン番号がパケット内で指定されているか判定する。
拡張ヘッダ・フィールド内に含まれる宛先ドメイン番号
はＣであるから、インタードメイン・ルータＡはインタ
ードメイン・ルータＣへパケットをフォワーディングす
る。パケットがインタードメイン・ルータＣに到達する
と、ルータＣは宛先ネットワーク番号の特別な値を拡張
ヘッダ・フィールドに含まれる実際の宛先ネットワーク
番号で置き換え（「上書き」）し、ネットワーク57の宛
先ノードＤへパケットをルーティングする。

宛先ノードＤでは、そのコンピュータ上で実行されて
いる各プロセスが所定のソケット、例えばソケット番号
Ｙを「聴取（listens）」している。アドレスされたそ
のソケットに応答するプロセスがない場合、宛先ノード
Ｄはパケットをドロップする。つまり、宛先ノードがソ
ケットと内部プロセスを関連付けられない場合、パケッ
トを破棄する。しかし、指定されたソケット番号Ｙをモ
ニタしているプロセスが存在する場合、そのプロセスが
パケットを受け取り処理する。これは従来のノードを含
む宛先ノードが本発明による拡張ヘッダ・フィールド・
パケット構造により混乱しないことを保証するものであ
る。

要約すると、本発明は慣用のドメイン内ルータの更新
を回避するような方法で見かけ上不変なパケット・フォ
ーマットからネットワーク・アドレスを拡張するための
技術を提供する。本発明によるアドレシング構造を解釈
するようにインタードメイン・ルータだけを構成すれば
良いので、本技術は既存のルータに対する互換性が得ら
れるという利点を提供する。

さらに、本発明によるアドレシング構造はネットワー
ク層アドレスの別のセクションに基づくルーティングを
容易にする。本発明のこの特徴は多くのルータがパケッ
トのフォワーディング前にネットワーク層ヘッダの指定
された部分、すなわち４バイトの宛先ネットワーク番号
フィールドを検証する必要しかないことからネットワー
ク・アドレシングの効率を向上させるものである。イン
タードメイン・ルータだけがアドレシング情報の残りの
部分を検証する必要がある。

新規な技術を実現するように構成されていないノード
例えばドメイン内ルータやある種の宛先ノードと互換性
を得られるような方法でネットワーク層ヘッダとノード
のアドレス空間を拡張するための新規な構造を実現する
ための代表的実施例を図示し説明したが、本発明の趣旨
と範囲内でその他各種適応及び変更を成し得ることは理
解されるべきである。例えば、拡張ヘッダ・フォーマッ
トを用いるソースノードの送信プロセスは、宛先ノード
がこのフォーマットを理解しない場合があることに注意
する必要がある。宛先ノードが新規なヘッダ・フォーマ
ットを実現するように設定されていないとの指標がない
場合、ソースは従来通りと新規な種類のヘッダ・パケッ
トの両方を送信して情報の受信を保証すべきである。

前述の説明は本発明の特定の実施例を指向したもので
ある。しかし本発明の利点の幾つかまたは全部を実現し
つつ説明した実施例に対してその他の変化及び変更を行
えることは明らかであろう。従って、添付の請求項の目
的は本発明の真の趣旨と範囲内に含まれるものとしてこ
れらすべての変化及び変更を内包することにある。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 カスタニョーリ，ニール，ディー. アメリカ合衆国 95037 カリフォルニ ア州 モーガン ヒル オークリッジ ロード 15910 (56)参考文献 特開 平２−176347（ＪＰ，Ａ) 特開 平１−264031（ＪＰ，Ａ) 特表 平５−501345（ＪＰ，Ａ) 特公 平５−21457（ＪＰ，Ｂ２) Ｒａｄｉａ Ｐｅｒｌｍａｎ著、”Ｉ ｎｔｅｒｃｏｎｎｅｃｔｉｏｎｓ −ブ リッジとルータにいて”初版、ソフトバ ンク、1995年５月31日。（セクション ２．５（ｐ．28−ｐ．31）及び、セクシ ョン４．１．１（ｐ．98−102）、セク ション10．２．１（ｐ．316−319)

Claims (6)

(57)【特許請求の範囲】
1. 【請求項１】インタードメイン・ルータにより相互接続
   された複数のドメインを有するコンピュータ・ネットワ
   ークに接続されたノードのアドレス空間を拡張し、パケ
   ットの一部を形成して前記パケットを受信する宛先ノー
   ドを識別する階層化宛先アドレス・エレメントを格納す
   るためのアドレス・フィールドを含むネットワーク層ヘ
   ッダを含むネットワーク層プロトコルに従ってパケット
   をルーティングするルータであって、 前記ネットワーク層ヘッダは、 前記インタードメイン・ルータを一意的に識別する特別
   な宛て先アドレスであって、前記宛先アドレス・エレメ
   ントからなる実際の宛先アドレスに置き換わる特別な宛
   先アドレスと、 前記アドレス・フィールドに追加された拡張ヘッダ・フ
   ィールドの提供を表わし、前記ネットワーク層ヘッダの
   バージョン・フィールド及び種別フィールドの一方に設
   定される特別な値であって、前記ネットワーク層ヘッダ
   のバージョン・フィールド及び種別フィールドの一方の
   内容に置き換わる特別な値と、 を含むことを特徴とするルータ。
2. 【請求項２】前記ヘッダは、ドメイン番号及び前記コン
   ピュータ・ネットワークの少なくとも１つのドメインを
   表すオプション・コードの一方を設定するオプション・
   フィールドをさらに含むことを特徴とする請求項１に記
   載のルータ。
3. 【請求項３】インタードメイン・ルータにより相互接続
   された複数のドメインを有するコンピュータ・ネットワ
   ークに接続されているノードのアドレス空間を拡張し、
   パケットの一部を形成して前記パケットを受信する宛先
   ノードを識別する階層化宛先アドレス・エレメントを格
   納するためのアドレス・フィールドを含むネットワーク
   層ヘッダを含むネットワーク層プロトコルに従ってパケ
   ットをルーティングするルータであって、 前記ネットワーク層ヘッダは、 前記インタードメイン・ルータを一意的に識別する特別
   なネットワーク値であって、前記階層化宛先アドレスの
   実際の宛先ネットワーク値に置き換わる特別なネットワ
   ーク値と、 前記アドレス・フィールドに追加された拡張ヘッダ・フ
   ィールドの提供を表わす特別なソケット値であって、前
   記階層化宛先アドレスの実際の宛先ソケット値に置き換
   わる特別なソケット値とを含み、 前記拡張ヘッダ・フィールドは、前記実際の宛先ネット
   ワーク値と、前記実際の宛先ソケット値と、前記コンピ
   ュータ・ネットワーク内における前記パケットのソース
   及び宛先ドメインを一意的に指定する情報とを含むこと
   を特徴とするルータ。
4. 【請求項４】ネットワーク層ヘッダ・フォーマットと、
   インタードメイン・ルータで相互接続された複数のドメ
   インを有するコンピュータ・ネットワークに接続されて
   いるノードのアドレス空間とを拡張するための方法であ
   り、前記ヘッダがパケットの一部を形成して前記パケッ
   トを受信する宛先ノードを識別する階層化宛先アドレス
   ・エレメントを格納するためのアドレス・フィールドを
   含む方法であって、前記方法は、 前記インタードメイン・ルータを一意的に識別する特別
   なネットワーク値で前記階層化宛先アドレスの実際の宛
   先ネットワーク値を置き換えるステップと、 前記階層化宛先アドレスの実際の宛先ソケット値の代わ
   りに、前記アドレス・フィールドに追加された拡張ヘッ
   ダ・フィールドの提供を表わす特別なソケット値で置き
   換えるステップとを含み、 前記拡張ヘッダ・フィールドは、前記コンピュータ・ネ
   ットワーク内における前記パケットのソース及び宛先ド
   メインを一意的に指定する情報を含むことを特徴とする
   方法。
5. 【請求項５】前記情報は、前記宛先ノードのドメインを
   一意的に識別するための新規な宛先ドメイン番号を含む
   ことを特徴とする請求項４に記載の方法。
6. 【請求項６】前記オプション・フィールドは、前記コン
   ピュータ・ネットワーク内における前記パケットのソー
   ス及び宛先ドメインを一意的に指定する情報を含むこと
   を特徴とする請求項２に記載のルータ。