JPH10510414A - ネットワークのオンデマンド型リンクによるデータ送信を同期させるための方法ならびにその装置 - Google Patents

Abstract

(57)【要約】 新規な同期メカニズムはコンピュータ・ネットワークのオンデマンド型リンク上でこれらのリンクを効率的に使用するような方法でデータ・パケットの配布を同期させる。送信元ノードで生成されて前記ネットワークのオンデマンド型リンクに接続された少なくともひとつのルータを経由して宛先ノードへ送信されるデータ・パケットのネットワーク層ヘッダに格納される制御情報を、本メカニズムは含む。ルータは、宛先ノードへパケットの配布のための接続を確立するためのリンクを即時ダイヤル呼出するか否かを、制御情報の状態によって指示される。

Description

【発明の詳細な説明】 ネットワークのオンデマンド型リンクによるデータ送信を 同期させるための方法ならびにその装置 発明の分野 本発明は通例コンピュータ・ネットワークに関し、さらに具体的にはコンピュ ータ・ネットワークのオンデマンド型通信リンクの効率的使用(efficient utili zation)に関する。 発明の背景 コンピュータ・ネットワークは、コンピュータなどのノード間でデータを転送 するために相互接続されている通信リンクの地理的に分散した集合体である。複 数のコンピュータ・ネットワークを中間ノードまたはルータでさらに相互接続す ることで、ネットワークの実効「サイズ」を拡張することができ、これのもっと 小さなグループをノードの自律系(autonomous system)またはドメインとして維 持できる。これらのノードは所定のプロトコルにしたがってデータの離散的な「 パケット」を交換することにより通信するのが普通である。これに関連して、プ ロトコルは、ノードが互いにどのように相互作用するかを定義した一組のルール から構成されている。 ネットワークを形成する通信リンクはイーサネット(Ethernet)通信システムの 場合のように相互接続されたノードに対して永久的に設置されたり、または通常 は接続されていない交換電話回線のダイヤル呼出回線とすることもできる。これ らのダイヤル呼出回線は典型的にはルータにより「立ち上げた」すなわちダイヤ ル呼出されて、オンデマンド型のノード間通信を開始する。従って、これらの回 線はオンデマンド型リンクとしても知られている。オンデマンド型リンクを使用 するネットワークの一例としては、総合サービスデジタル網（ＩＳＤＮ）が挙げ られる。 設計の複雑さを減らすため、多くのネットワークは各ノード内部で一連のハー ドウェアとソフトウェアのレベル、または「レイヤ（層）」として構成される。 これらのレイヤが相互作用して、たとえばネットワーク上で通信する送信元ノー ドと宛先ノード間の転送用にデータをフォーマットする。さらに具体的には、デ ータが各レイヤを通過すると、そのデータに対して所定のサービスが実行され、 レイヤ同士が所定のプロトコルを使って通信する。このように階層化した設計に より、各レイヤはサービスの実際の実装細部（インプリメンテーション細部）か らレイヤを遮蔽する標準化インタフェースを用いて、他のレイヤへ選択されたサ ービスを提供できるようになっている。 ネットワーク・アーキテクチャ、即ちネットワーク内で使用されるレイヤとプ ロトコルの組を標準化しようとする試みにおいて、国際標準化機構（ＩＳＯ）に より一般化したモデルが提案されている。このモデルはＯＳＩ（開放型システム 間相互接続：Open Systems Interconnection）参照モデルと呼ばれ、他のシステ ムとの通信に「開放型」システムでの相互接続を指向したものである。提案され ているＯＳＩモデルは７層からなり、インタフェースが下から順に物理層、デー タリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテー ション層、アプリケーション層と名付けられている。これらのレイヤ（層）は、 ネットワークの各ノードで「プロトコル・スタック」(protocol stack)を形成す るように構成されている。 図１はコンピュータ・ネットワーク１００の送信元ノード１１０と宛先ノード １５０の間でデータを転送するために、それぞれ使用される従来技術のプロトコ ル・スタック１２５、１７５の模式的ブロック図を示したものである。各プロト コル・スタックはＯＳＩ７層モデルに従った構成になっているので、各スタック はレイヤ毎に１つづつ、プロトコル集合を含んでいる。理解されているように、 プロトコル・スタック１２５および１７５は、物理層１２４および１６４で通信 チャンネルを介して物理的に接続される。説明を簡単にするため、プロトコル・ スタック１２５について説明する。 大まかに言うと、物理層１２４は通信チャンネル１８０上に生データ(raw data)のビット・ストリームを送信し、一方、データリンク層はビット・ストリ ームを操作して、それを見かけ上、送信エラーのないデータ・ストリームに変換 する。後者のタスクは、送信データをフレームに分割し、エラーの検出または訂 正のためのエラー訂正メカニズムを伴って、それらフレームを順次送信すること で実現される。ネットワーク層１２０は、多くの代替パスの１つを選択すること によって、物理ネットワークを介して送信元ノードから宛先ノードへとデータ・ パケットをルーチング(route)する。トランスポート層１１８は、セッション層 １１６からのデータ・ストリームを受け取り、（必要なら）それをもっと小さい 単位に細く配分した小ユニットをネットワーク層１２０へ渡し、全てのユニット が宛先に正しく到着することを保証する適切なメカニズムを備えている。 セッション層１１６は、送信元ノードおよび宛先ノード上のソフトウェア・プ ロセス間にデータ転送「セッション」を確立し、併せて順序だって当該セッショ ンの管理を行なうばかりでなく、あるセッションはノード間の通常のデータ転送 を行なえるようにする以外に、何らかのアプリケーションに拡張サービスを提供 する。プレゼンテーション層１１４は、送信データのプレゼンテーションに関連 して、標準フォーマットへのデータ符号化を含めて頻繁に要求される機能を実行 し、アプリケーション層１１２はノード上で実行中のプロセスで通例必要とされ る各種のプロトコルを含んでいる。 つまり、ネットワーク１００上のデータ転送は、たとえば送信元ノード１１０ 上で実行している送信プロセス１０４でデータを生成し、そのデータをアプリケ ーション層１１２へと渡し、さらに、プロトコル・スタック１２５の各層を下向 きに通過することで、ビットとしてチャンネル１８０上に配布されるパケットの 形にデータが順次フォーマットされる。これらのパケット・ビットが宛先ノード １５０のプロトコル・スタック１７５へ向けて送信され、宛先ノードではスタッ クをのぼって受信プロセス１７４へ渡される。このデータ・フローは実線の矢印 で模式的に図示してある。 実際のデータ送信は、スタックを介して縦方向に生じるが、各層は、送信が水 平方向であるかのようにプログラムされている。つまり、送信元ノード１００の 各層は宛先ノード１５０内のこれに対応する層へ、破線矢印で模式的に示したよ うに、データを送信するようにプログラムされている。これを行なえるようにす るには、パケットがスタックを下降する際に、送信元ノード１１０内のプロトコ ル・スタック１２５の各層が、送信プロセスにより生成されたデータ・パケット へ（ヘッダ・フィールドの形で）情報を追加するのが典型的である。宛先ノード １５０では、受信プロセスに到着するまで、パケットがスタック１７５の層を上 へと伝わる際に、各種ヘッダが１つづつ取り除かれる。 前述のように、ＯＳＩモデルにおける各層の重要な機能は、他の層へのサービ スを提供することである。各層で提供される２タイプ（種類）のサービスは、「 接続指向」(connection-oriented)および「コネクションレス」のネットワーク ・サービスである。接続指向サービスでは、送信元ノードが宛先ノードとの接続 を確立し、パケットの送信後、接続を終了する。この接続を確立することに伴う オーバヘッドは、効率的な通信性能を要求するノードでは魅力がないであろう。 この場合には、各々の送信パケットがネットワーク経由でその宛先の完全なアド レスを運ぶような、完全コネクションレス型サービスが望ましい。 ネットワーク層プロトコルはコネクションレス型ネットワーク・サービスを実 施するために用いられるのが一般的であって、このサービスが主としてパケット ・フォーマットを定義している。ネットワーク層は、ネットワーク上への送信の ためにトランスポート層からパケットを受信すると、特に送信元アドレスと宛先 アドレスを含むヘッダを（パケットに）追加する。ネットワーク層プロトコルの 例としては、ＩＳＯにより定義されているコネクションレス型ネットワーク・プ ロトコル（ＣＬＮＰ）、インターネット（ＩＰ）ネットワーク層プロトコル、お よびインターネット・パケット交換（ＩＰＸ）プロトコルとがある。 ＣＬＮＰとＩＰヘッダのパケット全体のフォーマットは、ネットワーク層サー ビスによって定義されるヘッダ内部に含まれるオプション・フィールドを用いて 追加機能に対応するように拡張できる。これらのフィールドでサポートされるオ プションのタイプ（種類）としては、典型的には送信元ルーティング、プライオ リティ、機密仕様情報(security-specific information)が含まれる。しかし、 従来のＩＰＸヘッダ・フォーマットは、パケットの残りのフィールドと互換性が ある方法で追加フィールドに対応するように設計されなかったので、通例拡張不 可能である。 また既に説明してあるように、典型的にはリンク上に転送されることを意図し たデータ・パケットの受信に応答して、ネットワークのオンデマンド型リンクを 立ち上げるためにルータが使用される。しかし、リンクをダイヤル呼出するたび に、接続課金(connection charges)を招くある種のデータ・パケットは、時間が 重要でない利用(non-time critical application)、例えばディレクトリ・サー ビスに対して分散したデータベースを同期させる等の利用のために交換される。 この種のコンピュータ間トラフィックは、パケット送信が発生する場合と同様に 柔軟性があり、本発明は他の切実な理由でオンデマンド型リンクをダイヤル呼出 する必要がある時刻までに、このようなトラフィックの配布を同期させることを 指向している。 発明の開示 本発明は、コンピュータ・ネットワークのオンデマンド型リンク上でこれらの リンクを効率使用するような方法で、各種データ・パケットの配布を同期させる ためのメカニズムを備えている。この新規な同期メカニズムは、送信元ノードで 生成されて、かつネットワークのオンデマンド型リンクに接続された少なくとも ひとつのルータを経由して宛先ノードへ送信されるデータ・パケットのネットワ ーク層ヘッダに通例格納される制御情報を備える。この制御情報の状態に基づい て、ルータは、宛先ノードへのパケット配布のための接続を確立するリンクに、 すぐにダイヤルすべきかどうかを指示される。 好ましくは、その制御情報はオプションとしてネットワーク層ヘッダ内部に含 まれる。オプション・フィールドをサポートするネットワーク層ヘッダの場合は 、例えば、コネクションレス型ネットワーク・プロトコル（ＣＬＮＰ）やインタ ーネット（ＩＰ）ネットワーク層プロトコル・ヘッダにおいて、オンデマンド型 リンク用として新規なオプションのタイプを定義させる。しかし、インターネッ ト・パケット交換（ＩＰＸ）プロトコル・ヘッダは、オプション・フィール ドに対応していないので、ネットワーク・アドレシング管理が、新規な制御情報 、例えばフラグをオプションとしてサポートすることでこのヘッダのフォーマッ トを拡張するように備えられている。 本発明の例示実施例（代表的な実施例）では、新規のフラグをアサーション(a ssert)した場合、ルータには「オンデマンド型リンクにダイヤルしないように」 指示する。アサーションされたフラグのあるデータ・パケットをルータが受信し た時に、送信元ノード内部の送信プロセスを識別するのに十分な、パケット内に 含まれるあるタイプの情報を格納し、そして送信元への戻りパケットを送信する 前にパケットの残りの部分を破棄する。この戻りパケットは，データ・パケット の完全な送信元アドレスと宛先アドレス、すなわちそのパケットを送出した送信 元ノード内部のプロセスを識別するのに十分な情報に、そのパケットを返送する 理由（例えば「オンデマンド型リンクが現在のところダイヤル呼出されていない 」等）を併せて含ませるのが望ましい。さらに、ルータは、これらの送信元アド レス及び宛先アドレスを追跡し、最終的にリンクを立ち上げる際に、宛先へのデ ータ・パケット送信のためにオンデマンド型リンクが現在利用できるようになっ ていることを示す次の通知パケットを送信元に送信することができる。 特定のタイプのデータ・パケット、例えばオンデマンド型リンクで定期的に送 信される、時間的に重要でない(not time critical)データ・パケットの同期は 、リンクが接続されているか否かを検査するために、ルータを定期的にポーリン グ(poll)するように、送信元ノードに要求することでさらに実現される。この技 術は、ポーリング・トラフィックで必要とされるネットワーク帯域幅が増加する との理由で、例示実施例の技術よりは最適ではないが、しかしルータが「クラッ シュ」した場合や、送信元ノード内部の送信プロセスを識別するのに必要な情報 を喪失した場合には、バックアップ・メカニズムとして有用であろう。 別の実施例において、ルータはアサーションしたフラグをもつデータ・パケッ トを格納し、オンデマンド型リンクが次にダイヤル呼出された時に、宛先ノード へパケットを送出する。この実施例では、ルータはリンクがそれまでに利用でき なかったことと、ルータでデータ・パケットが一時的に格納されていたことを送 信元ノードに通知する必要がない。このアプローチでは、ルータと送信元ノード 間のトラフィックが減少するが、リンクが接続するのを待機する間に発生するレ イテンシが実在する場合には、宛先ノードへ「新鮮でない」（state）データが 送信されてしまうことになる。 本発明のさらに別の実施例において、ルータは、オンデマンド型リンクが立ち 上げられている時にネットワークの全ノードへマルチキャスト・メッセージ(mul ticast message)を送信できる。ここで、マルチキャスト・メッセージは、「オ ンデマンド型リンクがデータ転送用に現在利用できる」ことを受信者(receipien t)送信元ノードの送信プロセスに通告する新規な制御情報を含む。この制御情報 は、さらに宛先ノードがリンク上で利用できることを送信元ノードに通知するの に十分な情報を含む。 このマルチキャスト・メッセージに応答して、そのリンク上に情報を送信した いと望む送信元ノードは、ルータへデータ・パケットを送信できる。この実施例 の一つの利点は、アクティブでないオン・デマンド・リンクを宛先とするすべて のデータ・パケットの送信元アドレス及び宛先アドレスを保持する必要がないこ とであり、また別の利点は、マルチキャスト・メッセージを受信するまではリン ク上のデータ転送を送信元ノードが開始する必要がないことである。 図面の簡単な説明 本発明の上記の利点及びそれ以外の利点は添付の図面との関連において以下の 説明を参照することにより、一層良く理解されよう。図面においては同じ参照番 号で類似の要素を表わしており、 図１は、コンピュータ・ネットワークの送信元ノードと宛先ノード間でデータ を転送するのに使用される従来技術のプロトコル・スタックの模式的ブロック図 である。 図２は、複数のノードに接続されたコンピュータ・ネットワークの集合を含む ネットワーク・システムのブロック図である。 図３は、本発明による新規な同期メカニズムが有利に使用できるオンデマンド 型リンクにより相互接続される複数ドメインを有するシステムの模式的ブロック 図である。 図４Ａ〜図４Ｃは、本発明による新規な同期メカニズムを格納するための従来 のネットワーク層ヘッダのオプション・フィールドの模式図である。 図５は、従来のＩＰＸネットワーク層ヘッダのフォーマットを図示する模式図 である。 図６は、本発明による新規な同期メカニズムを格納するためのＩＰＸネットワ ーク層ヘッダの改良フォーマットを示す模式図である。 例示実施例の詳細な説明 図２は複数のノードに接続されたコンピュータ・ネットワークの集合を備えた ネットワーク・システム２００のブロック図である。ノードは、送信元ノードＳ 、末端ノードＮ、宛先ノードＤ、および複数の中間ノードＲ１〜Ｒ２を備えた汎 用コンピュータが代表的なものである。各ノードは、典型的には、システムバス ２１０で相互接続されている中央演算処理ユニット（ＣＰＵ）２０２、メモリ・ ユニット２０４、および少なくとも１個のネットワーク・アダプタ２０６とを有 する。メモリ・ユニット２０４は、ランダム・アクセス・メモリ（ＲＡＭ）デバ イスから構成されるのが典型的である記憶場所を備え、ＣＰＵ２０２およびネッ トワーク・アダプタ２０６からアドレスが可能である。このメモリ・ユニットは 、典型的には本明細書でさらに説明するように、実行可能なプロセスやデータ・ パケットの内容等の情報の一時格納を提供する。典型的には一部がメモリに常駐 してＣＰＵにより実行されるオペレーティング・システムでは、特にＣＰＵで実 行するプロセスのサポートにおいて、ネットワーク動作を実行することにより、 機能的にノードを構成する。 ネットワーク・システム２００に含まれるコンピュータ・ネットワークとして は、ローカル・エリア・ネットワーク（ＬＡＮ）から広域ネットワーク（ＷＡＮ ）まである。ＬＡＮは限定された領域のネットワークであり、一方、ＷＡＮは通 信リンクを用いて広範囲に分散したノードを相互接続する公衆または専用の電気 通信設備(telecommunications facility)であるとすることができ る。これらのネットワークに接続されたノード間での通信は、典型的には例えば 送信元ノードのアドレスと宛先ノードのアドレスを指定するデータの離散的な「 パケット」を交換することにより行われる。図２に図示したシステムは、比較的 少数の相互接続されたＬＡＮ１〜３のグループを有するので、自律的ドメインと して維持されるのが望ましい。中間ノードとしては、正しい受信ノードへこれら パケットをルーチングすることで、ドメイン２００全体のデータ・パケットの流 れを容易にするように構成されたルータが望ましい。 通例、送信元ノードＳがＬＡＮ１上にパケットを送信する際には、そのパケッ トはそのＬＡＮ上にある全ノードに送信される。パケットの意図している受け手 がＬＡＮ３に接続されている場合には、パケットはルータＲ１を通りＬＡＮ２へ 、またルータＲ２を通ってＬＡＮ３上へルーチングされる。ルータの重要な機能 は、パケットが送信される次のノードを決定することであって、このルーチング 機能は各ノード内部のプロトコル・スタック２５０のネットワーク層２６０で行 われるのが望ましい。典型的には、パケットは２種類の宛先アドレスを含み：こ のアドレスは最終宛先ノードのアドレスと、経路（ルート）に沿った次のノード のアドレスとである。最終宛先アドレスは、パケットがネットワーク上を移動し ても一定のままであるが、次の宛先アドレスは、ネットワークを通る経路に沿っ たノードからノードへとパケットが移動すると変化する。 さらに具体的には、送信元ノードＳは、宛先ノードＤへすなわち最終宛先アド レスへパケットを送出する場合、パケットをＬＡＮ１へ送信し、次の宛先アドレ スでルータＲ１のアドレスを指定する。パケット内に嵌め込まれてプロトコル・ スタック２５０の高位層ソフトウェアにより処理されるアドレス情報は、パケッ トの最終宛先をノードＤとして指定する。この情報に基づいて、ルータＲ１は次 のノードがルータＲ２であることを決定し、次に進んでそのノードが受信できる ように、ＬＡＮ２へパケットを渡す。ルータＲ２はその後において次のノードが 最終宛先ノードＤであると決定し、パケットをＬＡＮ３を通じてノードＤへ送信 する。 図３は、ルータ３１２及び３２２に接続された通信リンク３３０によって相互 接続されている複数のドメイン３１０及び３２０を有するシステム３００の概略 ブロック図である。通信リンク３３０としては、ルータにより「立ち上げられた 」すなわちダイヤル呼出されてオンデマンド型ノード間通信を開始できる一時リ ンク（テンポラリ・リンク）が望ましい。つまり、オンデマンド型リンク３３０ は、普段は接続されていない交換電話回線のダイヤル呼出リンクとして実現でき る。例示的実施例において、オンデマンド型リンクは、総合サービスデジタル網 （ＩＳＤＮ）回線を有して、一方、リンクにより相互接続されるドメインは、独 立したインターネット・パケット交換（ＩＰＸ）ネットワーク、例えばノベル社 のＩＰＸネットワークやマイクロソフト社のＩＰＸネットワーク等を有するとす ることができる。 典型的に、ルータ３１２は、宛先ノードＤを宛先とする送信元ノードＳからの データ・パケットの受信に応答して、オンデマンド・リンク３３０をダイヤル呼 出する。但し、リンクをダイヤル呼出するたびに、交換電話回線の課金と同様の 接続課金が発生する。それにもかかわらず、あるタイプのデータ・パケットは、 時間的に重要でない利用、例えば電子メールまたはディレクトリ・サービスに伴 う分散データベースの同期等の利用に従って送信される。この種のコンピュータ 間トラフィックは、通例データ転送が行われる時に柔軟性があり、また前述した ように本発明はオンデマンド型リンクがダイヤル呼出される時刻までこのような トラフィックの配布を同期させることを意図している。 システム３００で使用するルータ３１２及び３２２においては、相互接続ネッ トワークが同一のネットワーク層プロトコルを共有する必要があり、かつより高 次のプロトコル・スタック層で互換性がある必要がある。しかし、ルータ３１２ のプロトコル・スタック３５０に模式的に図示してあるように、ネットワークは データリンク層３６２と物理層３６４では異っている。ルータは、本明細書で説 明する例示的実施例においては、何らかのネットワーク層プロトコルに従って動 作できるが、ネットワーク層プロトコルとしては、コネクションレス型ネットワ ーク層プロトコル（ＣＬＮＰ）、インターネット（ＩＰ）ネットワーク層プロト コル、及びＩＰＸプロトコルが望ましい。 さらに説明したように、ネットワーク層３６０は、ネットワーク上への送信の ために、トランスポート層３５８からデータ・パケットを受信すると、ネット ワーク層ヘッダをパケットに追加する。このようなヘッダ・フィールドのフォー マットは、何よりもまず各パケットに典型的には同じ情報が含まれることから、 すべてのネットワーク層サービスの間で通例同一である。図４Ａ及び図４Ｂは、 それぞれＩＰ及びＣＬＮＰのネットワーク層パケット４１０と４５０のフォーマ ットを示す。これらのパケットは両方とも、ヘッダ４１２及び４５２（すなわち 長さ及びチェックサム・フィールド）に関連する情報を通例含むということが分 かる。さらに具体的には、それぞれのヘッダが追加される機能に対応するために 、オプション・フィールド４２６及び４６６を含む。これらのフィールドでサポ ートされるオプションのタイプとしては、送信元ルーティング、プライオリティ 、機密仕様情報が含まれる。図４Ｃは、オプション・フィールド４８０の内容の 一般的なフォーマットを示したもので、これにはオプションのタイプ（種類）を 特有な形で定義する１オクテット（１バイト）のオプション・コード・フィール ド４８２、オプションの長さをバイト数で表わす１バイト長フィールド４８４、 および可変、例えば０〜２５４バイトの値フィールド４８６とを含む。 しかし、ＩＰＸプロトコル・ヘッダは、オプション・フィールドに対応してい ないので、本発明はこのヘッダのフォーマットを拡張するネットワーク・アドレ シング構造を提供する。図５は約３０バイトからなるネットワーク層ヘッダを有 する従来のＩＰＸパケット５００のフォーマットを示す概略図である。さらに具 体的には、このヘッダは、特に階層化した宛先アドレス及び送信元アドレスを含 み、そのそれぞれが複数のアドレス・エレメントを有する。例えば、宛先アドレ ス５１０は、パケットが伝送される特定のネットワークを表わす４バイトの宛先 ネットワーク・フィールド５１２と、そのネットワーク上の受信ノードのデータ リンク層アドレスとを識別する６バイトの宛先ノード・フィールド５１４と、受 信ノードでの受信プロセスを指定する２バイトの宛先ソケット・フィールド５１ ６とを含む。データ・フィールド５３０は、送信元アドレス・フィールド５２０ のすぐ直後のヘッダに追加される。 アドレス構造に従って、送信元アドレス・フィールドの後に追加ヘッダ情報の 用意を指示し、ネットワーク層ヘッダの改良を効率的に創成する特別なソケット 値が備えられている。図６は改良したＩＰＸネットワーク層ヘッダ６００のフォ ーマットを示す概略図である。送信元ノードは、従来の宛先アドレス・フィール ド５１０の２バイト宛先ソケット・フィールド５１６内部の実際の宛先ソケット 番号を特別なソケット値６５６に置き換える。好ましくは、その特別なソケット 値は、ネットワーク上にパケットを送出する前に、拡張ヘッダ・フィールド６６ ０の内容を検証することをルータに指示する。 本発明によれば、コンピュータ・ネットワークのオンデマンド型リンク上でこ れらリンクを効率使用するような方法で、特定のタイプのデータ・パケットの発 信を同期させるメカニズムが提供される。図１から図６を参照すると、新規な同 期メカニズムは、送信元ノード、例えば送信元ノードＳにより生成される制御信 号を有し、この制御信号はネットワーク・システム３００の通信リンク３３０に 接続されたルータ３１２を経由して、宛先ノード、例えば宛先ノードＤへ送信さ れるデータ・パケットのネットワーク層ヘッダに格納される。この制御情報の状 態により、ルータは、宛先ノードＤへパケット配布用の接続を確立するためのリ ンクをすぐにダイヤルすべきか否かを指示される。 好ましくは、制御情報はオプションとしてネットワーク層ヘッダ内部に組み入 れられる。ヘッダにオプション・フィールドを含むＩＰ及びＣＬＮＰネットワー ク層プロトコルの場合には、新規のオプションタイプがオンデマンド型リンクに 定義される。さらに具体的には、新規のオプションタイプは、パケットの受信に 応答してオンデマンド型リンクをダイヤルすべきか否かをルータに指示する値フ ィールド４８６に格納された情報と伴に、オンデマンド型リンクを特有な形で指 定するフィールド４８２に格納されるオプション・コード、例えば「ＯＤＬ」を 含む。オプション・フィールド４８０のバイト数でのトータル長（全長）は、長 さフィールド４８４に示される。 一方、改良ＩＰＸヘッダ６００に関連して、制御情報は、拡張ヘッダ・フィー ルド６６０のフィールド６７０に格納される。制御情報を含むフィールドの内容 は変化するが、フィールドは新規のフラグ６７０として提供されるのが望ましく 、このフラグの状態でオンデマンド型リンク３３０をどのように取り扱うかをル ータに指示する。言い替えれば、ルータ３１２が宛先アドレスの実際の宛先ソ ケット番号に代わって、特別なソケット値、たとえば「ＳＳ」を有するデータ・ パケットを受信した場合、ルータは、リンク３３０上にパケットを転送する前に 、拡張ヘッダ・フィールドの内容、さらに具体的には、フラグ６７０の状態を調 べる。 本発明の例示的実施例において、フラグのアサートは「オンデマンド型リンク をダイヤル呼出しない」ことをルータに指示するのが望ましい。フラグがアサー ションされた場合には、ルータは、パケットに含まれるあるタイプの情報を格納 し、送信元へ戻り、パケットを送信する前に、パケットの残りの内容を破棄する 。この戻りパケットは、そのパケットを返送する理由（例えば「オンデマンド型 リンクが現在ダイヤル呼出されていない」等）とともに、データ・パケットの完 全な送信元アドレス及び宛先アドレス、すなわちそのパケットを送信した送信元 ノード内部のプロセスを識別するのに十分な情報を含むのが望ましい。さらに、 ルータ３１２は、これのメモリ２０４にヘッダの送信元アドレス及び宛先アドレ スを一時的に格納し、それによりリンク３３０をこれから立ち上げる時に、宛先 ノードへのデータ・パケット送信用にオンデマンド型リンク３３０が現在利用可 能であることを指示する後続の通知パケットを送信元ノードＳへ送信できるよう にする。 本発明の別の実施例において、ルータ３１２は、メモリ２０４（図２）にアサ ーションされたフラグ６７０を有するデータ・パケット全体を格納でき、オンデ マンド型リンク３３０が後でダイヤル呼出された時に、ドメイン３２０の宛先ノ ードＤへパケットを送信する。この実施例においては、リンク３３０がそれまで 利用できなかったことと、ルータ３１２において一時的にデータ・パケットを格 納していたことをルータ３１２が送信元ノードＳへ通知する必要はない。このア プローチはルータと送信元ノードの間のトラフィックを減少するが、リンクが接 続するのを待機する間に発生するレイテンシが存在する場合には、宛先ノードへ 「新鮮でない」データが送信されてしまうことになる可能性がある。 本発明のさらに別の実施例において、ルータ３１２は、オンデマンド型リンク ３３０がダイヤル呼出されて利用可能である時に、ネットワークの全ノードへ単 一のマルチキャスト・メッセージを送信できる。ここで、マルチキャスト・メッ セージは、アサーションされた時に、「オンデマンド型リンクがデータ転送用に 現在利用できる」ことを受信者送信元ノードの送信プロセスに通知する新規な制 御情報を含む。制御情報はさらに宛先ノードがリンク上で利用できることについ て送信元ノードに通知するのに十分な情報も含む。 さらに具体的には、利用できる宛先ノードは、(i)ルータで送信元／宛先のア ドレス対の情報を格納することにより分かる。この場合、ルータはリンク上で利 用可能な宛先アドレスをリスト（作表）するそれぞれの送信元ノードへ個別のパ ケットを送信する。即ち(ii)送信元ノードに格納された情報をルーチングする。 ここでルータは利用可能な特定のリンクを識別するだけで良い。さらに、(iii) リンク上で到達可能な(reachable)宛先アドレスの合計(summary)でルータを構成 する。ルータは後者の情報をマルチキャスト・メッセージを介して送信元ノード ヘ供給できる。 このメッセージに応答して、リンク３３０上へ情報を送信しよう望むいずれの 送信元ノードでも、ルータ３１２へデータ・パケットを送信できる。本実施例の 利点は、アクティブでないオン・デマンド・リンクを宛先とするすべてのデータ ・パケットの送信元アドレス及び宛先アドレスをルータ３１２が保持する必要が ないことであり、また別の利点は、送信元ノードがマルチキャスト・メッセージ を受信するまでリンク上のデータ転送を開始する必要がないことである。 特定のタイプのデータ・パケット、例えば時間的に重要ではないが、定期的に 送信されるデータ・パケットを、コンピュータ・ネットワークのオンデマンド型 リンクで、そのリンクを効率使用するような方法で、同期させるための代表的実 施例を図示し説明してきたが、本発明の趣旨と範囲内でその他の各種の適応及び 修正・変更を成し得ることは理解されるべきである。例えば、送信元ノードは、 オンデマンド型リンクがアクティブに接続されているか否かを調べるために、ル ータを定期的にポーリングするように構成してもよい。この技術は、ポーリンル ・トラフィックにより必要とされるネットワークの帯域幅が増加するために、例 示実施例の技術よりも最適ではないが、しかし、ルータが「クラッシュ」した場 合や、送信元ノード内部の送信プロセスを識別するのに必要な情報を喪失した場 合には、バックアップ・メカニズムとして有用であろう。 さらに、オンデマンド型リンクをアクティブにすべきかどうかを指定する制御 情報は、ネットワーク層ヘッダ以外のデータ・パケット・ロケーションを用いて ルータへ提供できる。例えば、ルータは、ネットワーク層ヘッダを超えて検証す るように、すなわちパケットを構成要素に分析(parse)することで高レベルのプ ロトコル・スタック層ヘッダを分析し、パケットがルータにリンクをアクティブ にするように指示しているか否かを決定するように構成することができる。 これまでの説明は本発明の特定の実施例について注いだものである。しかし、 これら記述した実施例に対する、これら実施例の利点の幾つかまたは全部を実現 する、その他の変形及び変更を行えるということは自明であろう。従って、添付 の請求の範囲（クレーム）の目的は、本発明の真の趣旨と範囲内に含まれるもの として、これらすべての変形及び変更を内包することにある。

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

Claims (1)

1. 【特許請求の範囲】 １．送信元ノードで生成されてコンピュータ・ネットワークのオンデマンド型リ ンク上で宛先ノードへそのリンクを効率的に使用するような方法で送信されるデ ータ・パケットの配布を同期させるための装置であって、 前記オンデマンド型リンクに接続され、前記リンクをアクティブにするように 構成されて宛先ノードへの前記パケットの配布のために前記ネットワークの別の ノードへの接続を確立するためのルータと、 前記リンクをすぐにアクティブにして接続を確立すべきか否かを前記ルータに 指示し前記データ・パケットに格納される制御情報を含む指示手段と を含むことを特徴とする装置。 ２．前記制御情報が前記送信元ノードによって生成される ことを特徴とする請求項１に記載の装置。 ３．前記制御情報が前記データ・パケットのネットワーク層ヘッダに格納される ことを特徴とする請求項１に記載の装置。 ４．前記制御情報がネットワーク層ヘッダ内部にオプションを含む ことを特徴とする請求項３に記載の装置。 ５．前記オプションが前記オンデマンド型リンクについて定義される新規のオプ ションタイプであり、前記ヘッダのオプション・フィールド内に含まれる ことを特徴とする請求項４に記載の装置。 ６．前記オプションが前記ヘッダの拡張ヘッダ・フィールド内部に格納されるフ ラグである ことを特徴とする請求項４に記載の装置。 ７．前記制御情報がネットワーク層ヘッダではなく前記データ・パケットのもっ と高い階層のプロトコル・スタック・ヘッダ内部に含まれる ことを特徴とする請求項１に記載の装置。 ８．コンピュータ・ネットワークの送信元ノード内部の送信プロセスにより生成 されて、前記ネットワークのオンデマンド型リンク上で前記リンクを効率的に使 用するような方法で宛先ノードヘ送信されるデータ・パケットの配布を同期させ るための方法であって、 前記送信元ノードの前記送信プロセスにおいて前記データ・パケット内部に制 御情報を生成するステップと、 前記オンデマンド型リンクへ接続されたルータへ前記データ・パケットを転送 するステップと、 前記ネットワークの別のノードへの接続を確立するために前記リンクをすぐに アクティブにしないように前記ルータへ指示する前記制御情報を前記ルータにお いて調べるステップと、 前記パケット内部に含まれ、前記送信元ノード内部の前記送信プロセスを識別 するのに十分な情報を前記ルータにおいて格納するステップと、 を含むことを特徴とする方法。 ９．前記オンデマンド型リンクがアクティブになった時に前記送信プロセスへ通 知パケットを送信するステップをさらに含み、該通知パケットは前記宛先ノード への前記データ・パケット配布に前記リンクが現在利用可能であることを前記送 信プロセスへ知らせることを特徴とする請求項８に記載の方法。 １０．前記格納ステップの直後に、前記送信元ノードへ戻りパケットを送信する ステップを更に含み、該戻りパケットが前記送信元ノードの前記送信プロセスを 識別して前記オンデマンド型リンクが現在ダイヤル呼出されていないことを該プ ロセスに通知することを特徴とする請求項８に記載の方法。 １１．前記送信元ノードへ戻りパケットを送信するステップを更に含み、該戻り パケットが前記送信元ノードの送信プロセスを識別し前記オンデマンド型リンク が現在アクティブになっていないことをそのプロセスに通知することを特徴とす る請求項８に記載の方法。 １２．前記送信元ノードにおいて、前記リンクがアクティブか否かを調べるため に前記ルータを定期的にポーリングするステップをさらに含むことを特徴とする 請求項１１に記載の方法。 １３．前記データ・パケットのネットワーク層ヘッダに前記制御情報を格納する ステップをさらに含むことを特徴とする請求項８に記載の方法。 １４．送信元ノードで生成されてコンピュータ・ネットワークのオンデマンド型 リンク上で該リンクを効率的に使用するような方法で宛先ノードへ送信されるデ ータ・パケットの配布を同期するための方法であって、 前記送信元ノードにおいて前記データ・パケット内に制御情報を生成するステ ップと、 前記オンデマンド型リンクに接続されたルータへ前記パケットを転送するステ ップと、 前記ネットワークの別のノードへの接続を確立する前記リンクをすぐにアクテ ィブにしないように前記ルータに指示する前記制御情報を前記ルータにおいて調 べるステップと、 前記ルータにおいて前記データ・パケットを格納するステップと、 前記リンクが次にアクティブになった時に前記オンデマンド型リンク上で前記 宛先ノードへ前記データ・パケットを送信するステップと、 を含むことを特徴とする方法。 １５．送信元ノードで生成されてコンピュータ・ネットワークのオンデマンド型 リンク上で該リンクを効率的に使用するような方法で宛先ノードへ送信される データ・パケットの配布を同期するための方法であって、 前記オンデマンド型リンクに接続されたルータにおいてマルチキャスト・デー タ・パケット内部に制御情報を生成するステップと、 前記送信元ノードを含む前記ネットワークのノードへ前記マルチキャスト・パ ケットを配布するステップと、 前記宛先ノードへの接続を確立するために現在前記オンデマンド型リンクが利 用できることを前記制御情報が前記送信元ノードへ通知する前記制御情報を前記 送信元ノードにおいて調べるステップと、 前記宛先ノードへの前記リンク上での送信のために前記ルータへ前記送信元ノ ードからデータ・パケットを送信するステップと、 を含むことを特徴とする方法。 １６．送信元ノードで生成されてコンピュータ・ネットワークのオンデマンド型 リンク上で前記リンクを効率的に使用するような方法で宛先ノードへ送信される データ・パケットの配布を同期するための装置であって、 前記オンデマンド型リンクに接続され、前記リンクをアクティブにして前記宛 先ノードへの前記パケット配布のために前記ネットワークの別のノードへの接続 を確立するように構成されるルータと、 前記送信元ノードで生成され前記データ・パケットのネットワーク層ヘッダ内 に格納される制御情報を含み、前記接続を確立するために前記リンクをすぐにア クティブにするか否かを前記ルータに指示するための手段と、 を含むことを特徴とする装置。 １７．前記制御情報が前記ネットワーク層ヘッダ内部にオプションを含む ことを特徴とする請求項１６に記載の装置。 １８．前記オプションが前記オンデマンド型リンクについて定義される新規のオ プションタイプであり、前記ヘッダのオプション・フィールド内に含まれる ことを特徴とする請求項１７に記載の装置。 １９．前記オプションが前記ヘッダの拡張ヘッダ・フィールド内部に格納される フラグである ことを特徴とする請求項１７に記載の装置。