JP2000196669A - 情報中継装置 - Google Patents

Abstract

(57)【要約】 【課題】 カプセル化処理を行う擬似ネットワークイン
タフェース経由で送信情報が無限ループに陥ることによ
る送信不能を防止する。 【解決手段】 主記憶装置６０２のオペレーティングシ
ステム８００に実装されたパケットフォワーディングプ
ログラム８０３、ルーティングテーブル８０４にて、物
理ネットワークインタフェース６０３、６０４、トンネ
ルデバイスドライバ８０２による擬似ネットワークイン
タフェース間でのパケット中継を行うルータ装置におい
て、ネットワークインタフェースの定義情報を含むイン
タフェーステーブル８０５を、ルーティングテーブル８
０４の更新を行う経路制御プログラム９０１やテーブル
保守プログラム９０２等のアプリケーションプログラム
から参照可能にして、ルーティングテーブル８０４の更
新時にカプセル化後のパケットが再び擬似ネットワーク
インタフェースに送出されるような誤設定を防止する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報中継技術に関
し、特に、データ通信において行われるネットワークレ
イヤにおける仮想経路設定技術に係り、より詳しくは、
擬似ネットワークインタフェースを使用したカプセル化
処理によるトンネル送信のためのルーティングテーブル
操作等に適用して有効な技術に関する。

【０００２】

【従来の技術】データ通信において、ネットワークの構
成や運用上の都合からトンネル送信といわれる技術がし
ばしば必要になる。たとえば離れた位置に配置されたプ
ライベートネットワーク間で通信を実現する場合や、中
継経路中の通信プロトコルと送受信を行うホストの通信
プロトコルが異なる場合、そして送信パケットを暗号化
する場合などである。

【０００３】データ通信において、送信されるデータに
は各種の通信プロトコルで定められたデータが付加さ
れ、パケットと呼ばれる単位で送出される。データ送信
時に付加されるデータには通信を行うホストのアドレス
情報などが含まれる。受信側では受け取ったパケットか
らプロトコル依存の付加データを取り外して送信されて
きたデータを得ることができる。

【０００４】トンネル送信を行うには、カプセル化とよ
ばれる技術が用いられる。カプセル化とはプロトコル情
報を含んだパケット全体をひとつのデータとして扱い、
このパケットに更にプロトコル情報を付加して異なるパ
ケットを新たに構成することである。実質的なトンネル
の先であるデカプセル化ポイントにおいては、カプセル
化されたときに付加されたアドレス情報などのデータを
取り除きカプセル化される前のパケットを復元する。

【０００５】一般的にパケットのカプセル化およびデカ
プセル化処理は、物理インタフェースと同様に扱うこと
ができる仮想的な擬似ネットワークインタフェースを介
して行われる。この擬似ネットワークインタフェースは
上位のプロトコルスタックからは物理的なインタフェー
スと同様に見え、仮想的なトンネルネットワークを形成
することができる。この擬似ネットワークインタフェー
スは上位レイヤのプロトコルスタックから送信パケット
を受け取り、カプセル化して再度同一レイヤのプロトコ
ルスタックへ引き渡すとともに、カプセル化されたパケ
ットを受信した場合においてはデカプデル化と呼ばれる
カプセル化されたパケットからもとのパケットを復元す
る処理を行い、上位プロトコルスタックへ引き渡すか又
は転送する機能を兼ね備える。

【０００６】通常パケットのカプセル化はＯＳＩ基準モ
デルにおけるネットワークレイヤにおいて行われる。す
なわちネットワークレイヤ内においてネットワークレイ
ヤによるカプセル化が行われる。公知の例としては、例
えばインターネットプロトコル（ＩＰ）によるＩＰパケ
ットのカプセル化に関連して「ＩＥＴＦ（Internet Eng
ineering Task Force ）のＲＦＣ（Request For Commen
ts）１８５３ “ＩＰｉｎ ＩＰ ｔｕｎｎｅｌｉｎ
ｇ”」に示されている。カプセル化処理を擬似ネットワ
ークインタフェースによって行うことによる利点はカプ
セル化処理を通常のパケット送信と変わらずに行うこと
ができる点にある。そのため実装の上においても有利で
あり、既存のプロトコルスタックを大幅に変更すること
なく簡単にカプセル化機能を追加することができるだけ
でなく、仮想的なネットワークを実際のネットワークと
同様に扱うことができるようになる。以下、擬似ネット
ワークインタフェースを用いたトンネル送信例を図１３
とともに説明する。

【０００７】図１３に擬似ネットワークインタフェース
を備えトンネル送信を実現したパケットカプセル化装置
２台による仮想的なトンネルネットワークの模式図を示
す。ここでパケットカプセル化装置１０１および１０２
はそれぞれ物理ネットワークインタフェース１０５、１
０６および１０８、１０９と、擬似ネットワークインタ
フェース１０７および１１０を持っている。ここで、ネ
ットワーク１１１からネットワーク１１２へ中継される
パケットは、擬似ネットワークインタフェースにより構
築されている仮想的なトンネルネットワーク１０４を経
由して中継されるものとする。このとき中継されるパケ
ットは、実際にはネットワーク１０３内をカプセル化さ
れて流れることになる。例えば、ネットワーク１１１か
らパケットカプセル化装置１０１が受け取ったネットワ
ーク１１２宛のパケット１１３は、１０１内においてカ
プセル化処理が施されたパケット１１４が構成されネッ
トワーク１０３を経由してパケットカプセル化装置１０
２へ届けられる。このときのカプセル化処理は事前に決
められたカプセル化規則に基づいて行われる。すなわち
カプセル化された後の宛先ネットワークアドレスは物理
ネットワークインタフェース１０８のアドレスであるこ
とは事前に決められている。パケット１１４を受け取っ
た１０２はカプセル化を解き元のパケット１１３と同じ
パケット１１５を取り出し、ネットワーク１１２へ送出
する。

【０００８】上記のように、擬似ネットワークインタフ
ェースを用いたパケットカプセル化装置１０１における
カプセル化およびパケットカプセル化装置１０２におけ
るデカプセル化により、物理的には存在しない仮想的な
トンネルネットワーク１０４を形成することができる。

【０００９】

【発明が解決しようとする課題】擬似ネットワークイン
タフェースをトンネル送信に用いる方法はほとんどの場
合はうまく機能する。しかし、トンネル内に中継ノード
の数が実際には多数あったとしても、トンネル間の仮想
的なネットワークではそれらが見えてこないことから後
述のような技術的課題が生じてくる場合がある。例えば
中継ノード数をもとにしてネットワークのコストを計算
するＴＣＰ／ＩＰプロトコルにおけるＲＩＰなどの経路
制御プロトコルを使用した場合などである。

【００１０】ネットワークレイヤプロトコルであるＩＰ
プロトコルの場合、パケット送信時において主に以下の
ような処理が行われる。まず上位レイヤからデータと宛
先のアドレスを受け取り、宛先アドレスから送出するネ
ットワークインタフェースを決定する。このときネット
ワークインタフェースの選定はルーティングテーブルと
呼ばれる経路表を元にして行われ、トンネル用の擬似ネ
ットワークインタフェースを含むネットワークインタフ
ェースの内から選択される。その後ＩＰヘッダと呼ばれ
るプロトコル処理に用いられるデータが上位レイヤから
受け取ったデータに付加され、下位レイヤに渡される。

【００１１】ＩＰレイヤからＩＰパケットを受け取った
下位レイヤが物理的に実在するネットワークインタフェ
ースであった場合には、物理ネットワークインタフェー
スを制御するドライバが起動され、実際にネットワーク
にパケットが送出される。一方、トンネル用の擬似ネッ
トワークインタフェースである場合には、事前に決めら
れたカプセル化処理が行われた後に、カプセル化された
パケットが上位レイヤから渡されてきた時と同様にネッ
トワークレイヤへ渡され再びネットワークレイヤ処理が
施されることになる。

【００１２】カプセル化処理において、デカプセル化が
行われるデカプセル化ポイントのネットワークノードを
宛先アドレスとするようなパケットとして再構築され
る。このアドレスは事前に決められている。技術的課題
が発生するのはカプセル化されたパケットの宛先となっ
たデカプセル化ポイントのアドレスに対するルーティン
グテーブル内エントリの送出ネットワークインタフェー
スが再び擬似ネットワークインタフェースとなった場合
である。この場合はカプセル化されたパケットを更にカ
プセル化する処理へと渡され、この２重にカプセル化さ
れたパケットが更にカプセル化されるという具合に物理
的なネットワークインタフェースへ渡されることができ
ないため、パケットを実際に送出することができない。

【００１３】例としてＩＰパケットをＩＰパケットでカ
プセル化するいわゆるＩＰ ｏｖｅｒ ＩＰトンネルの
設定を行ったネットワークについて考察する。このネッ
トワークにおける経路制御プロトコルとしてＲＩＰを使
用した場合には上記技術的課題が発生してしまう。ＲＩ
Ｐは隣接するネットワークノード間において経路情報の
交換を行い、中継するネットワークノードの数（ホップ
数）をもとに宛先ネットワークへのコストの計算を行
い、計算結果をルーティングテーブルへ反映させる。経
路情報の交換はカプセル化を行う擬似ネットワークイン
タフェースを介しても行われる。仮想的なトンネルネッ
トワーク間は現実に多数のネットワークノードを経由し
ていたとしてもその間のホップ数はカウントされない。
このためデカプセル化されるトンネルのデカプセル化ポ
イントまでが現実の物理ネットワークでは多段になって
いた場合には、物理ネットワークよりも仮想トンネルネ
ットワークを経由するほうがネットワークコストが小さ
くなってしまうため、カプセル化されたときの宛先アド
レス（すなわちトンネルのデカプセル化ポイントのアド
レス）への送出先ネットワークインタフェースとしてカ
プセル化用の擬似ネットワークインタフェースがルーテ
ィングテーブルへ登録されてしまう。そのため上記の技
術的課題が発生するのである。

【００１４】図１３に示したネットワークの場合につい
て考えてみる。ネットワーク１１１から１１２への中継
されるパケットは仮想的なトンネルネットワーク１０４
を経由するものとする。パケットカプセル化装置１０１
では、パケット送出時において図１４に示した処理が行
われる。まず送出するパケットに含まれる宛先アドレス
の情報をもとルーティングテーブルを検索して、宛先ア
ドレスに対応する送出先のインタフェースを決定する。
送出先となるインタフェースが物理ネットワークインタ
フェースであった場合には、実際に対応する物理インタ
フェースへパケットが渡され送出される。一方、対応す
るネットワークインタフェースが擬似ネットワークイン
タフェースであった場合には、事前に決められたカプセ
ル化処理が施され、再構築されたカプセル化後のパケッ
トに対して再びルーティングテーブルの検索を行い対応
するネットワークインタフェースが決定される。

【００１５】このときのパケットカプセル化装置１０１
内のルーティングテーブルを図１５に、そして１０２内
のルーティングテーブルを図１６に示す。ルーティング
テーブルには各々の宛先ネットワークに対応するネクス
トホップおよび送出ネットワークインタフェースが記さ
れている。ネクストホップとは対応する宛先アドレス宛
のパケットを自分の次に中継するネットワークノードの
ことであり、中継するネットワークノードのアドレスが
エントリされ、自ノードが最終的な中継ノードである場
合には直接配送というエントリが入る。送出ネットワー
クインタフェースの項目には、宛先となるネットワーク
に対する擬似および物理的なネットワークインタフェー
スが入る。

【００１６】ネットワーク１１１からネットワーク１１
２宛のパケット１１３を受けとったパケットカプセル化
装置１０１はパケットを送出する際に、図１５に示した
自分のルーティングテーブルのエントリから１１２宛の
送出ネットワークインタフェースとして擬似ネットワー
クインタフェース１０７を選択する。その後、そのパケ
ット１１３に対してカプセル化処理が施され、宛先アド
レスとして物理ネットワークインタフェース１０８のア
ドレスを持つパケット１１４が構成される。このパケッ
ト１１４に対して更にルーティングテーブルの検索が行
われ、送出ネットワークインタフェースとして物理ネッ
トワークインタフェース１０６が選択され、実際にカプ
セル化されたパケットが物理ネットワークインタフェー
ス１０６から送出され１０２へ届けられる。カプセル化
されたパケット１１４を受け取った１０２はカプセル化
されたパケット１１４から元のパケットを復元するデカ
プセル化の処理を行いパケット１１５を得た後に、図１
６に示した自装置のルーティングテーブルを検索して１
１２宛の送出ネットワークインタフェースとして物理ネ
ットワークインタフェース１０９を選択して１０９から
パケット１１５を送出する。

【００１７】この１０１におけるトンネル送信におい
て、何らかの理由により１０１内のルーティングテーブ
ルが図１７に示したものに変更された場合を考えてみ
る。図１５のルーティングテーブルと図１７のルーティ
ングテーブルの違いは１０３へのネットワーク宛に送出
するネットワークインタフェースが擬似ネットワークイ
ンタフェース１０７へ変更されていることである。この
場合カプセル化されたパケット１１４に対する送出ネッ
トワークインタフェースが再び擬似ネットワークインタ
フェース１０７になるため、パケット１１３からパケッ
ト１１４へ行われたカプセル化と同じカプセル化処理が
パケット１１４に対して行われる。このカプセル化処理
はルーティングテーブルが図１７のまま変更がない限り
繰り返されることになり、本パケットは実際の物理ネッ
トワークインタフェースから送出されることはない。す
なわちトンネル送信ができない。

【００１８】この技術的課題は上記に例のようにＩＰプ
ロトコルをＩＰプロトコルでカプセル化した場合だけで
はなく、同一プロトコルによるカプセル化を行う場合に
は発生する。

【００１９】従来技術による本技術的課題の解決手段と
しては、上記技術的課題を考慮した上でネットワーク管
理者が仮想的なトンネルネットワークを意識してスタテ
ィックに経路を設定することが考えられる。しかしスタ
ティックに経路情報を設定した場合、カプセル化ポイン
トからデカプセル化ポイントまでの物理的なネットワー
クへの経路が変化した場合に対応することができない、
という他の技術的課題を生じてしまう。また、人手によ
る設定ではどうしても設定ミスが発生してしまう、とい
う技術的課題も生じる。

【００２０】本発明の目的は、経路情報を固定化するこ
となく、パケット等の通信情報が擬似ネットワークイン
タフェース経由で無限ループに陥ることに起因する送信
不能等の障害を確実に回避することが可能な情報中継技
術を提供することにある。

【００２１】本発明の他の目的は、経路情報の設定作業
において、パケット等の通信情報を擬似ネットワークイ
ンタフェースで無限ループに陥らせるような誤設定を確
実に防止することが可能な情報中継技術を提供すること
にある。

【００２２】

【課題を解決するための手段】本発明においては、擬似
ネットワークインタフェースの構成定義として登録され
たトンネル設定等の情報をもとにして、経路計算方法を
変更する手段を提供するとともに、カプセル化されたパ
ケットが擬似ネットワークインタフェース経由で無限ル
ープに陥ることで送出不能となるようなルーティングテ
ーブルへの不適切なエントリ登録を抑制する手段を提供
する。

【００２３】具体的には、一例として、経路計算時にお
いて、不当に低く抑えられている仮想ネットワークであ
るトンネル間のネットワークコストを、デカプセル化さ
れるネットワークノードまでの物理ネットワークコスト
に合わせて調整する機能をもつ経路計算エンジンによっ
てダイナミックルーティング使用時における上記技術的
課題を解決することができる。

【００２４】このトンネルネットワークを意識させたダ
イナミックルーティングによる経路制御を行う場合に
は、経路計算エンジンにおいて、トンネルネットワーク
に関する情報（トンネルの種類やデカプセル化ポイント
のネットワーク情報）を事前に知る必要がある。通常、
経路計算エンジンは自装置の持つネットワークインタフ
ェースに関する情報として、アドレス情報やネットワー
ク情報については持っているが、トンネルに関する情報
は持っていない。本発明では経路計算エンジンがトンネ
ルに関する情報を得ることができる手段を提供する。

【００２５】この経路計算エンジンにより計算されたル
ーティングテーブルを用いることにより、カプセル化さ
れたパケットの送出先ネットワークインタフェースがト
ンネル用の擬似ネットワークインタフェースとなること
を防ぐことができるようになる。

【００２６】また、ルーティングテーブルへのエントリ
の追加は何もＲＩＰなどのダイナミックルーティングに
よるものだけとは限らず、例えば手動によるスタティッ
ク設定によりなされる場合もある。このスタティック設
定により不正な設定を抑制するためにルーティングエン
トリ追加もしくは変更時において、デカプセル化ポイン
トのネットワークもしくはネットワークノードに対する
送出先インタフェースが擬似ネットワークインタフェー
スとなるかどうかのチェックを行う機構を設ける。この
事前のチェックにより、擬似ネットワークインタフェー
スにてカプセル化されたパケットが送出不能に陥るとい
う上記技術的課題を解消することができる。

【００２７】

【発明の実施の形態】以下、本発明の実施の形態を図面
を参照しながら詳細に説明する。

【００２８】以下の説明では、情報中継装置の一例とし
て、ＩＰプロトコルをサポートしたルータ装置を例にし
て説明する。ルータ装置とはオープンシステムインター
コネクション（ＯＳＩ）基準モデルにおけるネットワー
ク層レイヤにおいてパケットの中継を行うことを主目的
とした装置である。このルータ装置は２つの物理ネット
ワークインタフェースを装備しており、ＩＰ ｏｖｅｒ
ＩＰトンネル（ＩＰをＩＰでカプセル化する機能）を
有しており、以下この前提を元に説明するが、本発明は
この物理ネットワークインタフェースの数およびＩＰプ
ロトコルに限定するものではない。

【００２９】図１は、本発明の情報中継装置の一実施の
形態であるをルータ装置のモジュール構成の一例を示す
概念図である。

【００３０】本実施の形態のルータ装置６０６における
パケットの中継処理は通常ハードウエアおよびソフトウ
エアの双方により実現される。ソフトウエアは主記憶装
置６０２上に配置され、主プロセッサ６０１により実行
される。主記憶装置６０２はソフトウエアを配置するだ
けでなく受信したパケットを格納するためのバッファと
しても機能する。２つの物理ネットワークインタフェー
ス６０３および物理ネットワークインタフェース６０４
はＯＳＩ基準モデルにおけるデータリンクレイヤおよび
物理レイヤをつかさどる回線制御用ハードウエアであ
る。これら各モジュールはシステムバス６０５により接
続されている。物理ネットワークインタフェース６０３
および６０４はともにＣＳＭＡ／ＣＤ方式の伝送方式を
採用したイーサネット（登録商標）インタフェースであ
り、それぞれ独自のハードウエアアドレスを有してい
る。この２つのイーサネットインタフェースに対して
は、異なるネットワークに属するそれぞれ固有のＩＰア
ドレスが動的もしくは静的に割り当てられる。

【００３１】図２に本実施の形態のルータ装置６０６に
実装されるＴＣＰ／ＩＰのプロトコルスタックを示す。
リンクレベル制御レイヤ７０５は、物理ネットワークイ
ンタフェース６０３および６０４やこれらを制御するド
ライバソフトウェアが該当する。アドレス解決プロトコ
ル（ＡＲＰレイヤ７０４）はネットワークインタフェー
ス固有のハードウエアアドレス（ＭＡＣアドレスと呼ば
れる）とＩＰアドレスとを対応させるためのプロトコル
である。ＩＰレイヤ７０３はＯＳＩ基準モデルでいうと
ころのネットワークレイヤに相当する。ルータ装置６０
６はこの通常このレイヤでの処理を行いＩＰパケットの
中継処理を行う。ＴＣＰ／ＵＤＰレイヤ７０２はトラン
スポートレイヤに相当するプロトコルでありエンド−エ
ンド間におけるネットワークストリームの送受信に用い
られる。その上位レイヤに位置するアプリケーションレ
イヤ７０１にはＴＥＬＮＥＴやＦＴＰといったＴＣＰ／
ＩＰプロトコルを使ったアプリケーションが該当する。
経路制御計算を行いルーティングテーブルの更新を行う
後述の経路制御プログラム９０１も一般的にはここのレ
イヤで動作する。

【００３２】本実施の形態の場合、主記憶装置６０２に
実装されるソフトウェアは、オペレーティングシステム
８００と、その上で稼働するアプリケーションプログラ
ム９００がある。

【００３３】オペレーティングシステム８００には、物
理ネットワークインタフェース６０３および６０４を制
御する物理ネットワークインタフェースドライバ８０
１、パケットのカプセル化／デカプセル化等を行う擬似
ネットワークインタフェースを実現するためのトンネル
デバイスドライバ８０２、物理ネットワークインタフェ
ース６０３と６０４との間のパケットの中継動作を行う
パケットフォワーディングプログラム８０３、パケット
フォワーディングプログラム８０３にて参照されるルー
ティングテーブル８０４、物理ネットワークインタフェ
ース６０３および６０４、擬似ネットワークインタフェ
ース等の構成定義が格納されたインタフェーステーブル
８０５、アプリケーションプログラム９００の側からの
要求に応じて、ルーティングテーブル８０４の更新やイ
ンタフェーステーブル８０５の参照／更新のための操作
インタフェースを含むとともにＵＤＰを処理するプロト
コル処理部８０６等が実装されており、図２に例示した
プロトコルスタックの、リンクレベル制御レイヤ７０５
〜ＴＣＰ／ＵＤＰレイヤ７０２の機能を実現する。

【００３４】アプリケーションプログラム９００として
は、たとえば経路制御プログラム９０１、テーブル保守
プログラム９０２があり、図２に例示したアプリケーシ
ョンレイヤ７０１に相当する。

【００３５】経路制御プログラム９０１は、隣接する情
報中継装置等のネットワークノードから得られる経路情
報に基づいてプロトコル処理部８０６を介して、ルーテ
ィングテーブル８０４の内容を動的に更新する動作を行
うソフトウェアである。本実施の形態では、この経路制
御プログラム９０１は、プロトコル処理部８０６を介し
てインタフェーステーブル８０５を参照することで、カ
プセル化されたパケットの送出先ネットワークインタフ
ェースがトンネル用の擬似ネットワークインタフェース
となることを防ぐ、という動作を行う機能を備えてい
る。

【００３６】テーブル保守プログラム９０２は、図示し
ない保守端末等を介してシステム管理者から入力される
情報に基づいてプロトコル処理部８０６を介して、ルー
ティングテーブル８０４や、インタフェーステーブル８
０５の内容を静的に編集する動作を行うソフトウェアで
ある。本実施の形態では、テーブル保守プログラム９０
２は、ルーティングテーブル８０４の編集時のルーティ
ングエントリ追加もしくは変更時において、インタフェ
ーステーブル８０５を参照することで、デカプセル化ポ
イントのネットワークもしくはネットワークノードに対
する送出先インタフェースが擬似ネットワークインタフ
ェースとなるかどうかのチェックを行う機能を備えてい
る。

【００３７】インタフェーステーブル８０５は、一例と
して図９に例示されるように、インタフェース名８０５
ａ、自ＩＰアドレス８０５ｂ、インタフェースタイプ８
０５ｃ、相手ＩＰアドレス８０５ｄ、デカプセル化ポイ
ントアドレス８０５ｅ、の各情報が、インタフェース名
８０５ａに対して対応付けられて格納されている。な
お、デカプセル化ポイントアドレス８０５ｅは、当該イ
ンタフェースがトンネルデバイスの場合にのみ設定され
る。なお、設定内容は、後述の図５に例示されたネット
ワーク構成のルータ装置１００４における設定例を示し
ている。

【００３８】自宛ではないＩＰパケットを受信したルー
タ装置６０６はＩＰレイヤ７０３において内部に保持し
ているルーティングテーブル８０４の情報をもとにパケ
ットの中継処理を行う。図３にＩＰパケットの受信、中
継そして送信の処理の流れを示す。物理ネットワークイ
ンタフェース６０３、６０４において受信されたパケッ
トはＩＰ入力処理に集められ、そこからＩＰ入力処理を
開始する。ＩＰ入力処理ではまずＩＰヘッダ内に記述さ
れた宛先アドレス（デスティネーションアドレス）を検
査する。この宛先アドレスが自宛であった場合には次ヘ
ッダ解析を行い対応する上位レイヤへＩＰヘッダを除去
して引き渡す。次ヘッダがＴＣＰの場合はＴＣＰの入力
処理へ、ＵＤＰの場合はＵＤＰの入力処理へ渡されるこ
とになる。

【００３９】一方、受け取ったＩＰパケットの宛先アド
レスが自宛ではなかった場合は、受信パケットはパケッ
ト中継処理へと渡される。ここではホップ数の減算など
が行われパケットはＩＰ出力処理へと渡される。

【００４０】送信処理のほうを見てみると、上位レイヤ
であるＴＣＰ／ＵＤＰレイヤ７０２から受け取るパケッ
トとともに中継されてきたパケットはＩＰ送信処理部に
集められる。ここでは送出されるＩＰパケットの宛先ア
ドレスをキーにしてルーティングテーブル８０４の検索
が行われる。ルーティングテーブル８０４には宛先アド
レスに対応する物理ネットワークインタフェースが記さ
れており、この情報を元にして送出するネットワークイ
ンタフェースが選択され、ＩＰパケットは対応する物理
ネットワークインタフェース６０３、６０４へ渡される
ことになる。

【００４１】以上が通常のＩＰレイヤ処理の主な流れで
ある。ＩＰパケットをＩＰパケットでカプセル化して通
信を行うＩＰ ｏｖｅｒ ＩＰトンネル通信は通常仮想
的な擬似ネットワークインタフェース（トンネルデバイ
スドライバ８０２）を介して行う。この擬似ネットワー
クインタフェースは上位レイヤであるＴＣＰ／ＵＤＰレ
イヤ７０２やその上のアプリケーションレイヤ７０１か
らも物理的なネットワークインタフェースと同様に見
え、この擬似ネットワークインタフェースによって仮想
的なポイントツーポイントのトンネルネットワークを形
成することができる。この擬似ネットワークインタフェ
ースには物理ネットワークインタフェース６０３、６０
４と同様に、仮想ネットワークに属するＩＰアドレス
（自ＩＰアドレス８０５ｂ）が割り当てられると同時
に、ＩＰパケットをどのようにカプセル化するかを決定
をするためのデカプセル化ポイントのアドレス（デカプ
セル化ポイントアドレス８０５ｅ）が設定される。この
デカプセル化ポイントのアドレスはカプセル化されたと
きの宛先アドレスとなる。この擬似ネットワークインタ
フェースを含めたＩＰレイヤの処理の流れを図４に示
す。

【００４２】受信処理の方から見てみると、物理ネット
ワークインタフェース６０３、６０４が受信したカプセ
ル化されたＩＰパケットはＩＰ入力処理へ集められ、通
常のＩＰ受信処理と同様に処理される。そしてカプセル
化されたＩＰパケットは、次ヘッダ解析処理において次
ヘッダが再びＩＰと判定され擬似ネットワークインタフ
ェース（トンネルデバイスドライバ８０２）の入力処理
へ渡される。ここでデカプセル化処理が行われ元のＩＰ
パケットが復元され、再び復元されたＩＰパケットはＩ
Ｐ入力処理へと渡され、中継処理もしくは上位レイヤへ
と送られる。

【００４３】一方、送信処理においては、上位レイヤで
あるＴＣＰもしくはＵＤＰからＩＰ出力処理部が受け取
り、宛先アドレスを元にしてルーティングテーブル８０
４の検索を行い、対応する出力ネットワークインタフェ
ースが決定される。このとき、送出先のネットワークイ
ンタフェースが擬似ネットワークインタフェース（トン
ネルデバイスドライバ８０２）であった場合には擬似イ
ンタフェースの出力処理部へＩＰパケットが渡され、決
められた宛先アドレスを持つＩＰパケットにカプセル化
され、カプセル化されたＩＰパケットが再びＩＰ出力処
理部へ戻される。ここでさらにカプセル化されたＩＰパ
ケットの送出先が決定され、実際の物理ネットワークイ
ンタフェース６０３、６０４へ送られネットワークへ送
出されることになる。

【００４４】このように擬似ネットワークインタフェー
スを用いることにより、既存のＩＰプロトコルの処理を
ほとんど変更することなしにカプセル化によるトンネル
送信を既存のＩＰプロトコルスタックを用いて行うこと
が可能になる。しかしながらカプセル化されたＩＰパケ
ットの送信時において、カプセル化されたＩＰパケット
の宛先アドレスに対応する出力インタフェースが再度、
擬似ネットワークインタフェースとなった場合に上述の
ような技術的課題が発生する。このような場合にはカプ
セル化を永遠に繰り返してしまい、実際にＩＰパケット
をネットワークに送出することはできなくなってしま
う。

【００４５】一般的にルータ装置６０６においてルーテ
ィングテーブル８０４の更新は、ダイナミックルーティ
ングによる経路制御をつかさどる経路制御プログラム９
０１もしくは、テーブル保守プログラム９０２等を用い
た手動によるスタティック設定によりなされる。本発明
では、これら二つの方法によって上記技術的課題が引き
起こされることがないような（すなわちカプセル化され
たＩＰパケットの宛先アドレスに対する送出ネットワー
クインタフェースが擬似ネットワークインタフェースと
なるようなルーティングテーブル８０４のエントリを排
除する）方法を提供する。

【００４６】図５のような構成のネットワークを考え
る。複数のルータ装置１００４、ルータ装置１００５、
ルータ装置１０１５、ルータ装置１００６が、ネットワ
ーク１０１３、ネットワーク１０１２、ネットワーク１
０１０を介して多段に接続されており、その両端にネッ
トワーク１０１４、ネットワーク１００９を介してホス
ト１００２およびホスト１００３が存在している。ルー
タ装置１００４は、物理ネットワークインタフェース
Ａ、物理ネットワークインタフェースＢおよび擬似ネッ
トワークインタフェースＣを持つ。

【００４７】ここで、ルータ装置１００４および１００
６は、図１に例示した構成のルータ装置６０６で構成さ
れ、このルータ装置１００４の擬似ネットワークインタ
フェースＣとルータ装置１００６の擬似ネットワークイ
ンタフェース１００８との間にはＩＰ ｏｖｅｒ ＩＰ
トンネルの設定がなされており仮想的なトンネルネット
ワーク１００１が構成されている。ここでホスト１００
２からホスト１００３への通信を考える。

【００４８】トンネルネットワーク１００１が存在しな
い場合はホスト１００２から送出されたＩＰパケットは
ルータ装置１００４〜１００６の間を中継されホスト１
００３へ到達することができるであろう。この到達条件
としてはルータ装置１００４〜１００６がホスト１００
３のネットワークへの経路情報を正しくもっていること
である。ルータ装置１００４で見てみると、１００４で
もっているルーティングテーブルのなかにホスト１００
３の接続されているネットワーク１００９宛のパケット
送出先として物理ネットワークインタフェースＢが設定
されていればよい。

【００４９】一方、ルータ装置１００４〜１００６の間
においてトンネル送信したい場合は、ルータ装置１００
４および１００６において擬似ネットワークインタフェ
ースを用いてトンネルネットワーク１００１の設定を行
う。このときルータ装置１００４においてはトンネルの
デカプセル化ポイントとして、相手先のルータ装置１０
０６のネットワークインタフェース１００７を設定する
と同時に、ルータ装置１００６ではトンネルのデカプセ
ル化ポイントとしてルータ装置１００４の物理ネットワ
ークインタフェースＢが設定される。このときホスト１
００２から送出されたＩＰパケットがこのトンネルネッ
トワーク１００１を経由してホスト１００３に到達させ
るためには、ルータ装置１００４のルーティングテーブ
ルには以下のエントリがなければならない。

【００５０】１．ネットワーク１００９への送出ネット
ワークインタフェースは擬似ネットワークインタフェー
スＣである。

【００５１】２．ネットワーク１０１０への送出ネット
ワークインタフェースは物理ネットワークインタフェー
スＢである。

【００５２】この条件が成り立った場合に図６に示した
ようなカプセル化されたＩＰパケットがルータ装置１０
０４〜１００６間を流れ、ルータ装置１００６において
元のＩＰパケットにデカプセル化されホスト１００３へ
到達することができる。

【００５３】次に、図５の構成のネットワークにおいて
各ルータ装置がＲＩＰによる経路制御を行った場合につ
いて考える。ＲＩＰは最もポピュラーなダイナミックル
ーティングプロトコルであり、中継経路中におけるルー
タの数（ホップ数）をもとにネットワークのコストを算
出し、ルーティングテーブルを更新するプログラムであ
る。ＲＩＰは隣接するルータ間において経路情報の交換
を行い最小のホップ数となる送出先をルーティングテー
ブルに登録する。

【００５４】このときに上述のような技術的課題が発生
する。仮想的なトンネルネットワークを経由することに
よってルータ装置１００４と１００６は隣接ルータとな
るため、両ルータ装置間においても経路情報の交換が行
われる。その結果として、ルータ装置１００４から見た
場合、ネットワーク１０１０へのホップ数は現実の物理
ネットワークにおける３ではなくトンネルネットワーク
経由で２になってしまう。そしてネットワーク１０１０
への送出先ネットワークインタフェースは擬似ネットワ
ークインタフェースＣとなってしまう。このためルータ
装置１００４からみたトンネルネットワーク１００１の
デカプセル化ポイントであるネットワークインタフェー
ス１００７への送出ネットワークインタフェースは常に
カプセル化を行う擬似ネットワークインタフェースＣと
なるため、これまでに説明してきたデッドロック状態と
なってしまう。

【００５５】すなわち、図１０に例示されるように、ル
ータ装置１００４でルーティングテーブル８０４の内容
が事前にに例示される内容の状態で、物理提供および
論理提供に隣り合うルータ装置１００５およびルータ装
置１００６から、それぞれおよびに例示される経路
情報を順次受け取った場合を考えると、従来技術の場合
には、当該およびの経路情報に基づいて図１２の
およびの内容のようにルーティングテーブル８０４が
更新される。このとき、図１２のに示されるように、
ネットワーク１０１０への送出先のネットワークインタ
フェースとして、擬似ネットワークインタフェースＣが
設定されるため、ルータ装置１００６のデカプセル化ポ
イント（ネットワークインタフェース１００７）に向け
て送出されるはずの、カプセル化されたパケットが再び
擬似ネットワークインタフェースＣに送出されることと
なり、当該パケットは無限ループに陥って、送出不能と
なる。

【００５６】本発明では過小に評価されすぎたトンネル
ネットワーク経由のネットワークコストを、インタフェ
ーステーブル８０５に定義された、トンネルネットワー
ク１００１のネットワークアドレスおよびデカプセル化
ポイントの情報を元にして、実際の物理ネットワーク構
成と適合するように調整することにより、上記デッドロ
ック状態をひきおこすことを回避する。以下にこの技術
的課題を解決する具体例を示す。

【００５７】図７に、経路制御プログラム９０１におい
てルーティングプロトコルにＲＩＰを用いた場合に必要
となる、本実施の形態に係る処理のフローチャートを示
す。ＲＩＰによるネットワークコストの計算は隣接する
ルータ装置から受け取るそのルータ装置のもつ経路情報
を元にして算出される。通常処理において、この経路情
報を受け取ったことをトリガにして再計算がなされる。
経路情報を受け取るごとに図７に示した処理が経路の再
計算前に行われる。

【００５８】一例として、図５のルータ装置１００４を
中心に考えると、ＲＩＰの経路制御プログラム９０１が
隣接のルータ装置（ルータ装置１００５、ルータ装置１
００６）から経路情報を受け取ると処理１２０１へ入
る。まず処理１２０２において、インタフェーステーブ
ル８０５を参照することで、トンネルの設定がなされて
いるか（擬似ネットワークインタフェースが存在する
か）どうかチェックする。トンネルの設定がなされてい
ない場合には、以下に行うような特別な処理は必要ない
ため、処理１２０６へ飛び、受け取った情報をもとに経
路計算を行う。

【００５９】トンネル設定がなされている場合には処理
１２０３が行われ、受け取った経路情報はトンネル経由
で受け取った情報か物理的に隣接しているルータ装置１
００５から受け取った情報かどうかチェックする。これ
はトンネル用の仮想ネットワーク（トンネルネットワー
ク１００１）に対するホップ数が最小になっているかそ
うでないかにより判定できる。トンネル経由ではなく実
際に隣接しているルータ装置１００５から受け取った情
報であるとわかった場合には、処理１２０６へ飛びその
情報をもとに通常の経路計算が行われる。トンネル経由
で受け取った情報である場合には、処理１２０４におい
て受け取った経路情報の中にデカプセル化されるポイン
トの経路情報が含まれるかどうかチェックされ、もしあ
った場合（トンネルの先となるルータ装置１００６から
の経路情報なので通常は含まれているはずである）に
は、処理１２０５にて、そのネットワークに対するホッ
プ数を最大（たとえば１６）に設定しなおす。ＲＩＰに
おいてホップ数が１６の場合、到達不可能と判断され
る。その後、更新された経路情報をもとに経路情報の再
計算を行い、計算結果をルーティングテーブル８０４へ
反映させる。

【００６０】図７のフローチャートに例示した処理を行
うことにより、経路制御プログラム９０１のＲＩＰによ
る経路計算によって、トンネルネットワーク１００１の
デカプセル化ポイント（ルータ装置１００６のネットワ
ークインタフェース１００７）への送出ネットワークイ
ンタフェースが擬似ネットワークインタフェースＣとな
るようなエントリのルーティングテーブル８０４での存
在を抑制することが可能となる。

【００６１】すなわち、図１１に例示されるように、本
実施の形態の場合には、図１０に例示されたおよび
の経路情報を順次受信した時、上述の処理により、ルー
ティングテーブル８０４の内容は、図１１のおよび
のように変化し、この時、図１２のに示された従来技
術の場合に、送出先のネットワークインタフェースが、
物理ネットワークインタフェースＢから擬似ネットワー
クインタフェースＣに変更されていたネットワーク１０
１０のエントリは、元の物理ネットワークインタフェー
スＢのままに維持され、ルータ装置１００４においてカ
プセル化されたパケットが再び擬似ネットワークインタ
フェースＣに送出されるという不具合がなくなり、カプ
セル化されたパケットの正常な送信が可能になる。

【００６２】図７のフローチャートに示した処理を行う
ためには、トンネル設定の有り無し、トンネルネットワ
ーク、そしてデカプセル化ポイントのネットワークの情
報をＲＩＰが動作する経路制御プログラム９０１に知ら
せる必要がある。このため本実施の形態では、プロトコ
ル処理部８０６が、上述のようにオペレーティングシス
テム８００の内部に設定されているインタフェーステー
ブル８０５を、上位のアプリケーションプログラム９０
０から参照可能にする機能を備えることにより、トンネ
ル用の擬似ネットワークインタフェース（トンネルデバ
イスドライバ８０２）に関する情報を経路制御プログラ
ム９０１等に提供している。

【００６３】ルーティングテーブル８０４の更新を行う
のは何もＲＩＰなどのようなダイナミックルーティング
プロトコルによるものだけとは限らない。例えばテーブ
ル保守プログラム９０２等のソフトウェアを用いて、ス
タティックに経路を手動で設定した場合にもルーティン
グテーブル８０４の更新が伴う。この場合においてもト
ンネルデカプセル化ポイント宛の経路の送出先ネットワ
ークインタフェースがトンネル用の擬似ネットワークイ
ンタフェースＣとなることを防止する必要がある。この
ために本実施の形態においては、テーブル保守プログラ
ム９０２等のソフトウェアを用いて手動で設定する場合
におけるルーティングテーブル８０４へのエントリ追加
または更新時において、事前にこれについてチェックを
行い対象となるエントリはエラーではじく機構をテーブ
ル保守プログラム９０２に設ける。

【００６４】この処理を図８のフローチャートに例示す
る。処理１３０１において、操作者からテーブル保守プ
ログラム９０２への指令によりルーティングテーブル８
０４へのエントリ更新または追加の要求がくる。本実施
の形態のテーブル保守プログラム９０２ではこのエント
リをそのままルーティングテーブル８０４へ追加するの
ではなく、処理１３０２においてトンネルデカプセル化
ポイントへの送出先がカプセル化を行う擬似ネットワー
クインタフェースとなるかならないかを、インタフェー
ステーブル８０５におけるトンネルの設定状況から判定
して、もしも該当する場合には処理１３０３において本
要求を破棄して操作者にエラーの表示を行う。このチェ
ックに該当しなかった場合のみ、テーブル保守プログラ
ム９０２は、処理１３０４においてルーティングテーブ
ル８０４のエントリの更新または追加を行う。この図８
のフローチャートに示した処理をテーブル保守プログラ
ム９０２が行うことによって、カプセル化を繰り返して
実際にネットワークへ送出されないＩＰパケットが発生
することを未然に防ぐことができる。

【００６５】以上説明してきたように、本実施の形態に
よれば擬似ネットワークインタフェース（トンネルデバ
イスドライバ８０２）を用いてカプセル化されたパケッ
トを送出する際に、ルーティングテーブル８０４の中
に、カプセル化後のパケットの送出先が再び擬似ネット
ワークインタフェースとなるような不適切な設定がなさ
れることに起因してカプセル化後のパケットが送信不能
に陥るという技術的課題を克服してトンネル送信を不都
合なく行うことが可能となる。このため同一プロトコル
によるトンネル送信を行う場合において、仮想的なトン
ネルネットワークを意識することなく経路制御の方式と
して、経路制御プログラム９０１によるダイナミックル
ーティングを使用することができるようになる。

【００６６】また、テーブル保守プログラム９０２等を
用いるルーティングテーブル８０４の編集によるスタテ
ィックなルーティング設定時においても設定者のミスに
よる不当な設定を抑制することが可能となる。

【００６７】以上本発明者によってなされた発明を実施
の形態に基づき具体的に説明したが、本発明は前記実施
の形態に限定されるものではなく、その要旨を逸脱しな
い範囲で種々変更可能であることはいうまでもない。

【００６８】

【発明の効果】本発明の情報中継装置によれば、経路情
報を固定化することなく、パケット等の通信情報が擬似
ネットワークインタフェース経由で無限ループに陥るこ
とに起因する送信不能等の障害を確実に回避することが
できる、という効果が得られる。

【００６９】また、経路情報のマニュアル設定作業にお
いて、パケット等の通信情報を擬似ネットワークインタ
フェースで無限ループに陥らせるような誤設定を確実に
防止することができる、という効果が得られる。

【図面の簡単な説明】

【図１】本発明の情報中継装置の一実施の形態であるを
ルータ装置のモジュール構成の一例を示す概念図であ
る。

【図２】本発明の一実施の形態であるルータ装置に実装
されるＴＣＰ／ＩＰのプロトコルスタックを示す概念図
である。

【図３】ＩＰパケットの受信、中継そして送信の処理の
流れを示すフローチャートである。

【図４】擬似ネットワークインタフェースを含めたＩＰ
レイヤの処理の流れを示すフローチャートである。

【図５】本発明の一実施の形態であるルータ装置を用い
て構築されたネットワーク構成の一例を示す概念図であ
る。

【図６】本発明の一実施の形態であるルータ装置におけ
るカプセル化機能で生成されるパケットの構成の一例を
示す概念図である。

【図７】本発明の一実施の形態であるルータ装置に実装
された経路制御プログラムの作用の一例を示すフローチ
ャートである。

【図８】本発明の一実施の形態であるルータ装置に実装
されたテーブル保守プログラムの作用の一例を示すフロ
ーチャートである。

【図９】本発明の一実施の形態であるルータ装置に実装
されたインタフェーステーブルの一例を示す概念図であ
る。

【図１０】本発明の一実施の形態であるルータ装置に実
装された経路制御プログラムの作用の一例を示す概念図
である。

【図１１】本発明の一実施の形態であるルータ装置に実
装された経路制御プログラムの作用の一例を示す概念図
である。

【図１２】従来技術のルータ装置に実装された経路制御
機能の作用の一例を示す概念図である。

【図１３】擬似ネットワークインタフェースにてトンネ
ル送信を実現する複数のパケットカプセル化装置にて構
築されたトンネルネットワークを示す模式図である。

【図１４】従来技術のトンネルネットワークの作用を示
すフローチャートである。

【図１５】従来技術のトンネルネットワークにおけるル
ーティングテーブルの設定状態を示す説明図である。

【図１６】従来技術のトンネルネットワークにおけるル
ーティングテーブルの内容の推移を示す説明図である。

【図１７】従来技術のトンネルネットワークにおけるル
ーティングテーブルの内容の推移を示す説明図である。

【符号の説明】

６０１…主プロセッサ、６０２…主記憶装置、６０３，
６０４…物理ネットワークインタフェース、６０５…シ
ステムバス、６０６…ルータ装置、７０１…アプリケー
ションレイヤ、７０２…ＴＣＰ／ＵＤＰレイヤ、７０３
…ＩＰレイヤ、７０４…ＡＲＰレイヤ、７０５…リンク
レベル制御レイヤ、８００…オペレーティングシステ
ム、８０１…物理ネットワークインタフェースドライ
バ、８０２…トンネルデバイスドライバ、８０３…パケ
ットフォワーディングプログラム、８０４…ルーティン
グテーブル、８０５…インタフェーステーブル（設定情
報）、８０５ａ…インタフェース名、８０５ｂ…自ＩＰ
アドレス、８０５ｃ…インタフェースタイプ、８０５ｄ
…相手ＩＰアドレス、８０５ｅ…デカプセル化ポイント
アドレス、８０６…プロトコル処理部、９００…アプリ
ケーションプログラム、９０１…経路制御プログラム
（アプリケーション部）、９０２…テーブル保守プログ
ラム（アプリケーション部）、１００１…トンネルネッ
トワーク、１００２，１００３…ホスト、１００４〜１
００６，１０１５…ルータ装置、１００７…ネットワー
クインタフェース、１００８…擬似ネットワークインタ
フェース、１００９，１０１０，１０１２，１０１３，
１０１４…ネットワーク、Ａ，Ｂ…物理ネットワークイ
ンタフェース、Ｃ…擬似ネットワークインタフェース。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 １つもしくは複数の物理ネットワークイ
   ンタフェース、および仮想的なネットワークを構成する
   ためのカプセル化方法とデカプセル化されるネットワー
   ク情報を含む設定情報にもとづいてパケットのカプセル
   化を行う機能を有した擬似ネットワークインタフェース
   と、 ネットワークアドレスと前記物理ネットワークインタフ
   ェースもしくは擬似ネットワークインタフェースとの対
   応を保持するルーティングテーブルと、 前記ルーティングテーブルに対してダイナミックもしく
   はスタティックにルーティングエントリを更新または追
   加できる機能と、を備え、 前記パケットの送信時において送信パケットの宛先ネッ
   トワークアドレス情報をもとに前記ルーティングテーブ
   ル内の対応する前記物理ネットワークインタフェースま
   たは前記擬似ネットワークインタフェースを選択してパ
   ケット送出を行う情報中継装置であって、 前記パケットのカプセル化に用いられた前記擬似ネット
   ワークインタフェースと、カプセル化後に宛先となるネ
   ットワークアドレスに対する前記ルーティングテーブル
   内エントリにおける送出ネットワークインタフェースと
   が同一となることを前記設定情報を用いて抑制する制御
   論理を備えたことを特徴とする情報中継装置。
2. 【請求項２】 請求項１記載の情報中継装置において、
   ダイナミックまたはスタティックな前記ルーティングテ
   ーブルへのエントリの追加および更新の要求を行うアプ
   リケーション部と、前記ルーティングテーブルを管理し
   前記アプリケーション部からの要求により当該ルーティ
   ングテーブルへのエントリの追加および更新の要求に応
   じてエントリの追加または更新を行うプロトコル処理部
   を備え、 前記アプリケーション部からの前記ルーティングテーブ
   ルへのエントリの追加または更新の要求時においてデカ
   プセル化先のネットワークアドレスへの送出ネットワー
   クインタフェースが前記擬似ネットワークインタフェー
   スとなるかどうかの検査を行い、該当する場合には前記
   要求を破棄する機能を有したことを特徴とする情報中継
   装置。
3. 【請求項３】 請求項２記載の情報中継装置において、 前記アプリケーション部は、ネットワーク間を接続する
   情報中継装置間において授受される経路情報をもとにし
   て経路の計算を行いダイナミックに前記ルーティングテ
   ーブルへ登録する動作を行うとき、他の前記情報中継装
   置から受信した前記経路情報と前記擬似ネットワークイ
   ンタフェースに関する設定情報を利用してデカプセル化
   先のネットワークアドレスへの送出ネットワークインタ
   フェースが前記擬似ネットワークインタフェースに一致
   するようなエントリの追加を抑止する動作を行い、 前記プロトコル処理部は、ダイナミックに経路制御を行
   う前記アプリケーション部に対して、前記仮想的なネッ
   トワークのアドレス情報およびカプセル化する際のあて
   先ネットワークアドレス情報を公開する手段を備えたこ
   とを特徴とする情報中継装置。