ネットワークシステム
【課題】複数のトンネルを効率的に確立する。
【解決手段】要求メッセージに対する応答メッセージに対し、パケットが通過すべき複数の中継装置のアドレスが格納される。応答メッセージは、応答メッセージに中継装置アドレスが格納された中継装置の夫々によって受信されることができ、応答メッセージを受信した中継装置は、応答メッセージに格納された中継装置アドレスを用いてトンネルを確立し、トンネルの確立に用いた中継装置アドレスを応答メッセージから削除して、他の中継装置へ転送する。
【解決手段】要求メッセージに対する応答メッセージに対し、パケットが通過すべき複数の中継装置のアドレスが格納される。応答メッセージは、応答メッセージに中継装置アドレスが格納された中継装置の夫々によって受信されることができ、応答メッセージを受信した中継装置は、応答メッセージに格納された中継装置アドレスを用いてトンネルを確立し、トンネルの確立に用いた中継装置アドレスを応答メッセージから削除して、他の中継装置へ転送する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステムに関する。
【背景技術】
【０００２】
インターネットバックボーンにおけるルータの経路数を削減する技術として、ID-Locator分離技術が検討されている。その代表的な例がIETF（The Internet Engineering Task Force）で標準化検討中のＬＩＳＰ（Locator ID Separation Protocol）である。図３４ は、ＬＩＳＰの概要を説明する図である。
【０００３】
ＬＩＳＰは、コア網１と、コア網１に接続される１以上のアクセス網（図３４ではアクセス網２、３を例示）とを備える。コア網１は、アクセス網からのアクセス回線を収容する、エッジノードと呼ばれるルータを備える。図３４の例では、アクセス網２におけるホスト４（ＩＤ＃１）からのアクセス回線を収容するエッジノード５（ＬＯＣ１）と、アクセス網３におけるホスト６（ＩＤ＃２）からのアクセス回線を収容するエッジノード７（ＬＯＣ２）とが例示されている。“ＩＤ”は、アクセス網で使用されるアドレス（ＩＰアドレス）を示し、“ＬＯＣ（Locator：Location address）”は、コア網におけるエッジ
ノードのアドレス（ＩＰアドレス）を示す。
【０００４】
ＬＩＳＰでは、アクセス網のアドレスと、コア網のアドレスとが分離して管理される。このため、ＬＩＳＰでは、アクセス網のアドレスとコア網のアドレスとの対応関係を管理する１以上の管理サーバが設けられる。図３４では、エッジノード５に対応する管理サーバ８と、エッジノード７に対応する管理サーバ９とが設けられている。エッジノード５は、ホスト４のＩＤ（ＩＤ＃１）とエッジノード５のＬＯＣ（ＬＯＣ１）との対応関係を管理サーバ８に登録し（図３４の＜１＞）、エッジノード７は、ホスト６のＩＤ（ＩＤ＃２）とエッジノード７のＬＯＣ（ＬＯＣ２）との対応関係を管理サーバ９に登録している。
【０００５】
ＬＩＳＰの動作を、図３４を用いて説明する。例えば、ホスト４がホスト６へデータを送信する場合の動作を例示する。ホスト４は、データにホスト６のアドレス（ホストＩＤ：ＩＤ＃２）を含むヘッダが付与されたパケットをエッジノード５へ送信する。ホスト４からのパケットを受信したエッジノード５は、当該パケットの宛先のホストを収容するエッジノード（エッジノード７）とのトンネル構築を試行する。
【０００６】
このとき、エッジノード５は、宛先であるホスト６を収容するエッジノード７のアドレス（ＬＯＣ）を知らない場合には、対応する管理サーバ８に対して、宛先のコア網アドレス（ＬＯＣ）を問い合わせるメッセージ（ＬＯＣ要求）を送信する（図３４の＜３＞）。ＬＯＣ要求を受信した管理サーバ８は、ＬＯＣ要求に含まれる宛先アドレス（ＩＤ＃２）に対応するＬＯＣを管理している管理サーバ９へＬＯＣ要求を転送する（図３４の＜４＞）。ＬＯＣ要求は、直接に、又は図３４に示すような中継装置（例えばルータ）を介して制御プレーン（Ｃプレーン）上を転送され、管理サーバ９に到達する。ＬＯＣ要求を受信した管理サーバ９は、管理サーバ９が管理している、宛先ホストＩＤ（ＩＤ＃２）に対応するエッジノードのアドレス（ＬＯＣ２）を含むメッセージ（ＬＯＣ応答）を、ＬＯＣ要求の送信元であるエッジノード５へ送信する（図３４の＜５＞）。ＬＯＣ応答を受信したエッジノード５は、エッジノード７との間でＩＰトンネルを確立する。続いて、エッジノード５は、ホスト４からのパケット（ユーザＩＰパケット）に宛先エッジノードアドレス（エッジノード７のアドレス（ＬＯＣ２））を含むヘッダを付与することによってカプセル化パケット（ＬＩＳＰパケット）を生成する。ＬＩＳＰパケットはＩＰトンネルへ送出され、エッジノード７に到達する。エッジノード７は、ＬＩＳＰパケットからのヘッダの
除去（デカプセル化）を行い、得られたユーザＩＰパケットをホスト６へ転送する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１６６０８９号公報
【非特許文献】
【０００８】
【非特許文献１】Locator/ID Separation Protocol(LISP) draft-ietf-lisp-10, D. Farinacci, V. Fuller, D. Meyer, D. Lewis, cisco Systems, March 4, 2011
【非特許文献２】LISP-DHT: Towards a DHT to map identifiers onto locators, draft-mathy-lisp-dht-00, L. Mathy, Lancaster U, L. Iannone, O. Bonaventure, UCLouvain, February 25, 2008
【非特許文献３】Hierarchical Mobile IPv6 Mobility Management (HMIPv6), H. Soliman, Flarion, C. Castelluccia, INRIA, K. El Malki, Ericsson, L. Bellier, INRIA, August 2005
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ＬＩＳＰは、動的にトンネルを確立する、という第１の特徴と、ホストから送信されたパケットは変更されることなくトンネル上に転送される、という第２の特徴を有する。これらの特徴を生かしたホストの移動に対応する動作がIETF LISP WG(Working group)で検
討されている。
【００１０】
ホストの移動に伴って、コア網の出口（egress）側のエッジノード（例えば、図３４に示したエッジノード７）の変更が生じた場合には、新たな出口エッジノードと、他のエッジノード（例えば、入口エッジノード）との間でトンネルの再構築（ＬＯＣ変更）が発生する。このようなＬＯＣ変更に係る遅延や、コア網内で生じる処理負荷は、できる限り小さくすることが好ましい。また、ＬＯＣ変更に係る遅延や処理負荷の低減を図るために、複数のエッジノード間を結ぶ多段（複数段）トンネルが一括で確立可能な技術が求められる。
【００１１】
本発明の一態様は、複数の中継装置間を結ぶ複数のトンネルを効率的に確立可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の一態様は、パケットを受信する第１中継装置と、前記パケットの宛先アドレスを有する端末と接続された第２中継装置とを含む複数の中継装置と、
前記第１中継装置を管理する第１管理装置と、前記第２中継装置を管理する第２管理装置とを含む、前記複数の中継装置を管理する複数の管理装置とを備え、
前記第１中継装置は、前記パケットの転送に用いる中継装置アドレスを解決するための、前記宛先アドレスを含む要求メッセージを前記第１管理装置へ送信し、
前記複数の管理装置は、前記要求メッセージが前記第１管理装置から前記第２管理装置へ到達するように、前記宛先アドレスに対応する転送情報に基づいて前記要求メッセージを転送するとともに、前記第１中継装置から前記第２中継装置へ到達する前記パケットが通過すべき１以上の中継装置の中継装置アドレスを前記要求メッセージに格納し、
前記第２管理装置は、前記要求メッセージに格納された複数の中継装置アドレスと、前記第２中継装置の中継装置アドレスを含む１以上の中継装置アドレスとが格納された応答メッセージを生成し、
前記応答メッセージに中継装置アドレスが格納された前記第２中継装置を除く中継装置の夫々は、前記応答メッセージを受信し、前記応答メッセージに格納された中継装置アド
レスを用いて、中継装置間の前記パケットの転送に使用されるトンネルを確立するとともに、少なくともトンネルの確立に用いた中継装置アドレスを前記応答メッセージから削除し、前記応答メッセージに残った１以上の中継装置アドレスの何れかへ前記応答メッセージを転送し、
前記応答メッセージを受信する前記第１中継装置は、前記応答メッセージに格納された中継装置アドレスを用いて自装置より１つ前に位置する中継装置との間でトンネルを確立し、
前記パケットは、前記第１中継装置、及び前記パケットが通過する中継装置の夫々からトンネルへ送出されるときに、宛先中継装置アドレスを含むヘッダを用いてカプセル化されるネットワークシステムである。
他の態様は、上記ネットワークシステムに係る管理装置、中継装置を含み得る。また、他の態様は、ネットワークシステム、管理装置、中継装置に係る方法や、管理装置や中継装置で実行されるプログラム、又はプログラムを記録した記録媒体を含み得る。
【発明の効果】
【００１３】
本発明の一態様によれば、中継装置間を結ぶ複数のトンネルを効率的に確立することができる。
【図面の簡単な説明】
【００１４】
【図１】図１は、本発明の第１実施形態に係るＬＩＳＰネットワーク（ネットワークシステム）の構成例を示す。
【図２】図２は、図１に示したエッジノードとして適用可能なエッジノードのハードウェア構成例を示す。
【図３】図３は、図２に示したハードウェア構成を有するエッジノードによって実現される機能構成例を示す。
【図４】図４は、経路テーブルのデータ構造例を示す。
【図５】図５は、トンネル管理テーブルのデータ構造例を示す。
【図６】図６は、図１に示した各管理サーバとして適用される管理サーバのハードウェア構成例を示す。
【図７】図７は、図６に示した管理サーバのハードウェア構成によって実現される機能構成例を示す。
【図８】図８は、ＬＯＣ管理サーバ情報テーブルのデータ構造例を示す。
【図９】図９は、ホストＩＤ−ＬＯＣ管理テーブルのデータ構造例を示す。
【図１０】図１０は、図１に示したネットワークシステムの動作例の説明図である。
【図１１】図１１は、管理サーバ４１が保持するＬＯＣ管理サーバ情報テーブルの登録内容例を示す。
【図１２】図１２は、管理サーバ４２が保持するＬＯＣ管理サーバテーブルの登録内容例を示す。
【図１３】図１３は、管理サーバ４３が保持するＬＯＣ管理サーバテーブルの登録内容例を示す。
【図１４】図１４は、管理サーバ４２が保持するホストＩＤ−ＬＯＣ管理テーブルの登録内容例を示す。
【図１５】図１５は、管理サーバ４３が保持するホストＩＤ−ＬＯＣ管理テーブルの登録内容例を示す。
【図１６】図１６は、管理サーバ４４が保持するホストＩＤ−ＬＯＣ管理テーブルの登録内容例を示す。
【図１７】図１７は、データパケットを受信したエッジノードの処理例を示すフローチャートである。
【図１８】図１８は、ＬＯＣ要求を受信した管理サーバで実行される処理例を示すフローチャートである。
【図１９】図１９は、ＬＯＣ応答を受信したエッジノードで実行される処理例を示すフローチャートである。
【図２０】図２０は、エッジノード２７のトンネル管理テーブル６７に登録されるエントリを示す。
【図２１】図２１は、エッジノード２１，２５，２６，２７の経路テーブルに登録されるエントリを示す。
【図２２】図２２は、エッジノード２６のトンネル管理テーブル６７に登録されるエントリを示す。
【図２３】図２３は、エッジノード２５のトンネル管理テーブル６７に登録されるエントリを示す。
【図２４】図２４は、エッジノード２１のトンネル管理テーブル６７に登録されるエントリを示す。
【図２５】図２５は、エッジノード２７の経路テーブル６６に登録されたエントリを示す。
【図２６】図２６は、エッジノード２７のトンネル管理テーブル６７に登録されたエントリを示す。
【図２７】図２７は、エッジノード２１，２５，２６が夫々有する経路テーブル６６のエントリを示す。
【図２８】図２８は、第１実施形態の参考図である。
【図２９】図２９は、第１実施形態の変形例２において管理サーバ４２が保持するＬＯＣ管理サーバ情報テーブルを示す。
【図３０】図３０は、第１実施形態の変形例２において管理サーバ４２が保持するホストＩＤ−ＬＯＣ管理テーブルを示す。
【図３１】図３１は、第３実施形態における各管理サーバの処理例を示すフローチャートである。
【図３２】図３２は、第３実施形態におけるエッジノードの処理例を示すフローチャートである。
【図３３】図３３は、第４実施形態におけるネットワークシステムの例を示す。
【図３４】図３４は、ＬＩＳＰの説明図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
〔第１実施形態〕
＜ネットワーク構成＞
図１は、本発明の第１実施形態に係るＬＩＳＰネットワーク（ネットワークシステム）の構成例を示す。ＬＩＳＰネットワークは、ＩＰパケットをトンネリング（カプセリング）するネットワークの一例である。ＬＩＳＰでは、コア網１０においてパケットを転送するためのトンネルが動的に確立される。
【００１６】
図１に例示するネットワークシステムは、コア網１０と、コア網１０に収容される複数のアクセス網１１，１２，１３，１４を備えている。コア網１０は、複数のエッジノードとして機能する複数のルータを備えている。図１には、エッジノード２１〜２９が例示されている。エッジノードは中継装置の一例である。エッジノード２１〜２９は、夫々、コア網１０で使用されるエッジノードアドレス（ＩＰアドレス）である、ＬＯＣ１〜ＬＯＣ９を有している。エッジノード２１〜２７は、複数の中継装置の一例である。
【００１７】
エッジノード２１は、アクセス網１１に属するホスト３１のアクセス回線を収容している。エッジノード２１は、第１中継装置及び始点中継装置の一例である。エッジノード２２は、アクセス網１２に属するホスト３２のアクセス回線を収容している。エッジノード
２２は、第２中継装置及び終点中継装置の一例である。エッジノード２３は、アクセス網１３に属するホスト３３のアクセス回線を収容している。エッジノード２３は、第３中継装置の一例である。エッジノード２７は、第４中継装置の一例である。エッジノード２５〜２７は、１以上の中間中継装置の一例である。
【００１８】
ホスト３１〜３３の夫々は、アクセス網で使用されるＩＰアドレスである、ＩＤ＃１(
ホストＩＰ１)，ＩＤ＃２（ホストＩＰ２），ＩＤ＃３（ホストＩＰ３）を夫々有してい
る。ホスト３１〜３３は、例えば、パーソナルコンピュータ（ＰＣ），ＰＤＡ（Personal
Digital Assistant），スマートフォン，セルラーフォンのような、固定端末又は移動端末を含むことができる。アクセス回線は、有線であっても無線であっても良い。各ホスト３１〜３３は、端末の一例である。
【００１９】
また、コア網１０のエッジノード２５は、エッジノード２１に物理回線を介して接続される一方で、エッジノード２６，２８と物理回線を介して夫々接続されている。エッジノード２６は、エッジノード２７，２９と物理回線を介して夫々接続されている。エッジノード２７は、エッジノード２２，２３，２４と物理回線を介して夫々接続されている。エッジノード２８，２９の夫々は、図示しないコア網１０内の他のエッジノードと物理回線を介して接続されている。このように、図１に示す例では、エッジノード２１が入口エッジノードであり、エッジノード２５がルートであるツリー構造のトポロジが複数のエッジノード２５〜２９で形成されている。
【００２０】
また、コア網１０の制御プレーン（Ｃプレーン）上には、ＬＯＣ（エッジノードの位置識別情報）とＩＤ（ホストのＩＤ）との対応関係が登録される１以上の管理サーバが配置される。図１に示す例では、管理サーバ４１〜４４が配置されている。管理サーバ４１は、エッジノード２１を管理し、エッジノード２１のＬＯＣとエッジノード２１が収容する１以上のホスト（例えばホスト３１）のＩＤとの対応関係を保持する。
【００２１】
また、管理サーバ４４は、エッジノード２２のＬＯＣとエッジノード２２に収容されるホスト（例えばホスト３２）のＩＤとの対応関係と、及びエッジノード２３のＬＯＣとエッジノード２３に収容されるホスト（例えばホスト３３）のＩＤとの対応関係と、エッジノード２７のＬＯＣとエッジノード２７に収容されるホストのＩＤとの対応関係を保持することができる。管理サーバ４２，４３は、夫々、エッジノード２５，２６のＬＯＣとエッジノード２５，２６に収容される各ホストのＩＤとの対応関係を保持することができる。管理サーバ４１〜４４は、複数の管理装置の一例であり、管理サーバ４１は第１管理装置の一例であり、管理サーバ４４は、第２管理装置の一例である。
【００２２】
管理サーバ４１〜４４は、Ｃプレーンの制御パケットが転送されるネットワークを介して接続されている。また、各管理サーバ４１〜４４は、管理サーバ自身の管理下にあるエッジノードと通信回線を介して接続されており、エッジノードの間で制御パケットを送受信することができる。
【００２３】
＜エッジノードの構成＞
図２は、図１に示したエッジノード２１〜２９として適用可能なエッジノード２０のハードウェア構成例を示す。以下の説明において、エッジノード２１〜２９を区別することなく説明する場合には、エッジノード２０との表記を用いることもある。図２において、エッジノード２０は、バスＢを介して相互に接続されたＣＰＵ（Central Processing Unit）５１，スイッチカード５２，記憶装置５３と、１以上のインタフェースカード５４（
図２では、複数のインタフェースカードを例示）とを備える。インタフェースカード５４は、送受信装置の一例である。ＣＰＵ５１は、制御装置の一例である。
【００２４】
各インタフェースカード５４は、エッジノード２０のパケットの送受信処理を司る。スイッチカード５４は、パケットの転送処理、すなわち、各インタフェースカード５４で受信されたパケットをバスＢを介して受け取り、パケットの目的地に対応するインタフェースカードへパケットをバスＢを介して転送する処理を司る。ＣＰＵ５１は、エッジノード２０全体の動作を制御する。記憶装置５２は、ＣＰＵ５１がエッジノード２０の動作制御のために実行するプログラムや、プログラムの実行に際して使用されるデータを格納する。
【００２５】
記憶装置（ストレージ）５３は、ＲＡＭ（Random Access Memory）のようなＣＰＵ５１の作業領域として使用されるメモリ（記録媒体）と、ＣＰＵ５１によって実行されるプログラム，エッジノード２０の動作を規定する各種設定に係るデータを記録する不揮発性記録媒体とを含む。不揮発性記録媒体として、ＲＯＭ（Read Only Memory），ＥＥＰＲＯＭ，フラッシュメモリ，ＨＤＤ（Hard Disk Drive）を例示することができる。
【００２６】
スイッチカード５２は、各インタフェースカード５４との内部通信に使用される受信機及び送信機として機能する電気・電子回路を備える。また、スイッチカード５２は、インタフェースカード５４から受信されたパケットを一時的に保持する（バッファとして使用される）記憶デバイスを含む。また、スイッチカード５２は、転送処理に必要な情報を格納したテーブルを保持する記憶デバイスを含む。記憶デバイスは、用途に応じて、ＲＡＭ，ＲＯＭ，ＥＥＰＲＯＭ，フラッシュメモリ，ハードディスクのような様々な不揮発性又は揮発性記録媒体の中から１以上が選択されて搭載される。
【００２７】
さらに、スイッチカード５２は、テーブルに保持された情報に基づいてパケットの転送処理を行う。パケットの転送処理は、受信されたパケットの出力経路の決定、パケットのカプセル化，デカプセル化を含む。パケットの転送処理は、スイッチカード５２に搭載された電気・電子回路に含まれる１以上の半導体集積回路（ＩＣ（integrated circuit）、ＬＳＩ(Large Scale Integration)、ＡＳＩＣ(Application Specific Integrated Circuit)）を用いたハードウェア処理（転送処理回路による処理）、スイッチカード５２搭載のプロセッサ（例えば、ＣＰＵ，ＤＳＰ（Digital Signal Processor），ＦＰＧＡ(Field-Programmable Gate Array)）がプログラムを実行することによって実現されるソフトウェ
ア処理（プロセッサによる処理）、或いは上記したハードウェア処理とソフトウェア処理との組合せの何れかによって実現されることができる。
【００２８】
ＣＰＵ５１は、記憶装置５３に保持されたプログラムを実行することによって、エッジノード全体の動作を管理する。例えば、ＣＰＵ５１は、管理サーバから受信される情報を元に、スイッチカード５２が備えるテーブルの書き換えを行う。ＣＰＵ５１は、プロセッサ（マイクロプロセッサ）の一例である。プロセッサは、ＤＳＰやＦＰＧＡを含むことができる。
【００２９】
図３は、図２に示したハードウェア構成を有するエッジノード２０によって実現される機能構成例を示す。図３において、エッジノード２０は、パケット受信部６１と、パケット転送部６２と、パケット送信部６３と、デカプセル部６４と、カプセル部６５とを備える。
【００３０】
また、エッジノード２０は、経路テーブル（ルーティングテーブル）６６と、トンネル管理テーブル６７と、ＬＯＣ要求生成部６８と、ＬＯＣ要求送信部６９とを備える。さらに、エッジノード２０は、ＬＯＣ応答送信部７０と、トンネル生成部７１と、ＬＯＣ応答受信部７２とを備える。
【００３１】
パケット受信部６１は、ネットワークからパケット（データパケット）を受信する。パ
ケット送信部６３は、パケット（データパケット）をネットワークへ送信する。パケッ
ト受信部６１及びパケット送信部６３の機能は、インタフェースカード５４によって実現される。
【００３２】
デカプセル部６４は、パケット受信部６１で受信されたパケットがカプセル化されている（ＬＩＳＰパケットである）場合に、カプセル化パケットに付与されているヘッダ（ＬＩＳＰヘッダ）を除去する。
【００３３】
カプセル部６５は、パケット転送部６２からカプセル化すべきパケット（トンネルへ送信すべきパケット）を受け取る。カプセル部６５は、トンネルの受信側端点に位置するエッジノードのアドレス（ＬＯＣ）が宛先アドレスとして設定されたヘッダ（ＬＩＳＰヘッダ）をパケットの先頭に付与する（カプセル化）。
【００３４】
パケット転送部６２は、パケット受信部６１又はデカプセル部６４からのパケットを受け取る。パケット転送部６２は、経路テーブル６６を参照し、パケットの宛先ＩＰアドレスに対応する経路（出力ポート）を決定する。パケット転送部６２は、経路テーブル６６を参照して得られた経路がトンネルである場合には、トンネル管理テーブル６７を参照し、トンネルの他方端点のエッジノードアドレスを取得する。パケット転送部６２は、経路テーブル６６を参照した結果、宛先アドレスに対応する出力経路が登録されたエントリが存在しない（ヒットしない）場合に、ＬＯＣ要求生成部６８に対し、トンネル転送を行うか否かを問い合わせる。
【００３５】
経路テーブル６６は、宛先アドレスに対応する転送先を含む１以上のエントリが登録されたテーブルである。図４は、経路テーブル６６のデータ構造例を示す。図４に示すように、テーブル６６は、宛先アドレス（宛先ＩＰアドレス）に対応する転送先のエントリを保持する。転送先を示す情報として、次ホップのルータを示す情報、或いは、トンネル番号が登録される。
【００３６】
トンネル管理テーブル６７は、エッジノード間を結ぶトンネル構築のために要求される情報を保持する。すなわち、トンネル管理テーブル６７には、エッジノード間に構築されるトンネルの一方の端点が自エッジノードに位置するとの仮定において、当該トンネルの他方の端点が位置するエッジノードのアドレス（ＬＯＣ）が登録される。図５は、トンネル管理テーブル６７のデータ構造例を示す。図５に示すように、トンネル管理テーブル６７には、トンネル識別情報（トンネル番号）と、トンネルの他端に位置するエッジノードのＩＰアドレス（ＬＯＣ）とを含む１以上のエントリが登録される。
【００３７】
上述したデカプセル部６４，パケット転送部６２，カプセル部６５，経路テーブル６６，及びトンネル管理テーブル６７は、スイッチカード５２によって実現される。ＬＯＣ要求生成部６８は、パケット転送部６２からの問い合わせに基づいて、パケットの宛先アドレスに対応するエッジノードアドレスの解決のためにＬＯＣ要求処理を行う。すなわち、ＬＯＣ要求生成部６８は、宛先アドレスに対応するエッジノードアドレスを要求するＬＯＣ要求メッセージ（以下、単に「ＬＯＣ要求」と表記することもある）を生成する。生成されるＬＯＣ要求には、宛先アドレスとＬＯＣ要求の生成元（送信元）を示すエッジノードアドレス（以下、「ＬＯＣ要求元アドレス」と称する）とが格納される。通常、ＬＯＣ要求は、入口エッジノードによって生成される。ＬＯＣ要求生成部６８は、スイッチカード５２から問い合わせの信号をバスＢを介して受け取ったＣＰＵ５１によって実現される。
【００３８】
ＬＯＣ要求送信部６９は、自エッジノードを管理している管理サーバに対し、ＬＯＣ要求を送信する。例えば、エッジノード２０がエッジノード２１（図１）であれば、管理サ
ーバ４１へＬＯＣ要求が送信される。ＬＯＣ要求送信部６９は、ＣＰＵ５１で生成されたＬＯＣ要求をバスＢを介して受け取るインタフェースカード５４によって実現される。ＬＯＣ応答受信部７２は、自エッジノードを管理している管理サーバ（例えば、エッジノード２１に対する管理サーバ４１）、或いは、他のエッジノード（“下位階層”のエッジノード）から送信されたＬＯＣ応答メッセージ（以下、単に「ＬＯＣ応答」と表記することもある）を受信する。“下位階層”とは、図１に示した複数のエッジノードが形成するツリー型のトポロジにおいて、自エッジノードからみてルート側を“上位階層”と定義し、リーフ側を“下位階層”と定義したときの“下位階層”を示す。ＬＯＣ応答受信部７２は、インタフェースカード５４によって実現される。
【００３９】
トンネル生成部７１は、受信したＬＯＣ応答に格納されているＬＯＣリストに含まれたＬＯＣ（エッジノードアドレス）を用いて下位階層のエッジノードとのトンネルを確立する。トンネルの確立は、トンネル管理テーブル６７にトンネル番号と下位階層のエッジノードアドレスを登録することによって行われる。
【００４０】
また、トンネル生成部７１は、ＬＯＣ応答のＬＯＣリストから下位階層のエッジノードアドレスを取り除き、上位階層のエッジノードへ転送すべきＬＯＣ応答を作成する。宛先アドレス、送信元アドレス、プロトコルＩＤ、ポート番号をベースに、どの階層の上位エッジノードへ転送するかを決定し、下位階層のエッジノードアドレスに加え、バイパスするレイヤのエッジノードのアドレスをＬＯＣリストから削除する。トンネル生成部７１は、インタフェースカード５４で受信されたＬＯＣ応答をバスＢを介して受信したＣＰＵ５１によって実現される。
【００４１】
ＬＯＣ応答送信部７０は、他のエッジノード（上位階層のエッジノード）へＬＯＣ応答を送信する。ＬＯＣ応答送信部７０は、ＣＰＵ５１によって生成されたＬＯＣ応答をバスＢを介して受信するインタフェースカード５４によって実現される。
【００４２】
＜管理サーバの構成＞
図６は、図１に示した各管理サーバ４１〜４４として適用される管理サーバ４０のハードウェア構成例を示す。以下の説明において、管理サーバ４１〜４４を区別しない場合には、管理サーバ４０との表記を用いることもある。管理サーバ４０は、パーソナルコンピュータ（ＰＣ）のような汎用のコンピュータ、或いはサーバマシンのような専用のコンピュータを適用することができる。図６において、管理サーバ４０は、バスＢ１を介して相互に接続されたＣＰＵ８１，ＲＡＭ８２，ＨＤＤ８３，及びネットワークインタフェース（インタフェース（ＩＦ）回路、ＩＦ装置）８４を備える。
【００４３】
ＲＡＭ８２は、管理サーバ４０（ＣＰＵ８１）の主記憶装置の一例である。ＲＡＭ８２は、ＣＰＵ８１の作業領域であり、オペレーティングシステム（ＯＳ）やアプリケーションプログラムのような各種のプログラムの実行に際して使用されるデータを一時的に格納する。
【００４４】
ＨＤＤ８３は、管理サーバ４０（ＣＰＵ８１）の二次記憶装置の一例である。ＨＤＤは、ＣＰＵ８１によって実行されるＯＳやアプリケーションプログラムのような各種のプログラムや、各プログラムの実行のために使用されるデータを保持する。データは、ＨＤＤ８３によって保持されるテーブル又はデータベース上に格納されることができる。
【００４５】
ＣＰＵ８１は、プロセッサ（マイクロプロセッサ）の一例であり、ＨＤＤ８３に格納された各種のプログラムをＲＡＭ８２にロードして実行する。これによって、ＣＰＵ８１は、管理サーバ４０全体を管理する。例えば、ＣＰＵ８１は、エッジノード２０からネットワークインタフェース８４を介して受信される制御パケット（例えば、ＬＯＣ要求）に対
する処理を行う。
【００４６】
ネットワークインタフェース８４は、少なくともエッジノード及び他の管理サーバとの通信回線を収容し、外部ネットワークとの接続処理（パケットの送受信処理）を行う。図７は、図６に示した管理サーバ４０のハードウェア構成によって実現される機能構成例を示す。図７に示すように、管理サーバ４０は、ＬＯＣ要求受信部８５と、ＬＯＣ要求処理部８６と、ＬＯＣ要求送信部８７と、ＬＯＣ応答送信部８８と、ＬＯＣ管理サーバ情報テーブル８９と、ホストＩＤ−ＬＯＣ管理テーブル９０とを備えた装置として機能する。ＬＯＣ要求受信部８５は、エッジノード２０、あるいは、上位階層の管理サーバが送信したＬＯＣ要求を受信する。ＬＯＣ要求受信部８５は、ネットワークインタフェース８４によって実現される。管理サーバ４０の階層関係においても、入口エッジノードのＬＯＣを管理する管理サーバを最上位層として、リーフ側に位置する管理サーバが下位階層と定義されている。すなわち、エッジノードの階層関係に準じた階層関係が設定されている。
【００４７】
ＬＯＣ要求送信部８７は、下位階層の管理サーバへＬＯＣ要求を送信する。ＬＯＣ要求送信部８７は、ネットワークインタフェース８４によって実現される。ＬＯＣ応答送信部８８は、上位階層のエッジノードへＬＯＣ応答を送信する。ＬＯＣ応答送信部８８は、ネットワークインタフェース８４によって実現される。
【００４８】
ＬＯＣ要求処理部８６は、ＬＯＣ要求受信部８５で受信されたＬＯＣ要求に格納されている宛先アドレスに対応するエッジノード、又はエッジノードのリストをホストＩＤ−ＬＯＣ管理テーブル９０を参照して特定する。
【００４９】
また、ＬＯＣ要求処理部８６は、特定したエッジノード又はエッジノードのリストに最下位階層のエッジノードが含まれていない場合には、特定したエッジノード又はエッジノードリストを、受信したＬＯＣ要求に追加し、ＬＯＣ要求をＬＯＣ要求送信部へ送る。これに対し、最下位層のエッジノードが含まれている場合には、ＬＯＣ要求処理部８６は、受信したＬＯＣ要求に格納されていたＬＯＣリストと特定したエッジノード又はエッジノードのリストを合わせた（マージした）ＬＯＣリストを含むＬＯＣ応答を生成する。さらにＬＯＣ応答にはＬＯＣ要求元アドレスが格納される。ＬＯＣ要求処理部８６は、エッジノード２０への転送のために、ＬＯＣ応答をＬＯＣ応答送信部８８へ送る。
【００５０】
また、ＬＯＣ要求処理部８６は、上記したＬＯＣ要求、ＬＯＣ応答を生成する際に、エッジノードの宛先アドレス、送信元アドレス、プロトコルＩＤ、ポート番号をベースに、ＬＯＣ要求又はＬＯＣ応答が経由すべきエッジノードを決定し、決定されたエッジノードのリストをＬＯＣリストに格納する。ＬＯＣ要求処理部８６は、ネットワークインタフェース８４で受信されたＬＯＣ要求をバスＢ１を介して受け取ったＣＰＵ８１によって実現される。ＣＰＵ８１は、ＬＯＣ要求処理によって生成したＬＯＣ要求、ＬＯＣ応答を、バスＢ１を介してネットワークインタフェース８４へ送る。
【００５１】
ＬＯＣ管理サーバ情報テーブル８９は、ホストの宛先ＩＰアドレスに対応する、ＬＯＣ要求を転送すべき下位階層の管理サーバ４０の識別情報（ＩＰアドレス）が登録される。図８は、ＬＯＣ管理サーバ情報テーブル８９のデータ構造例を示す。図８に示すように、テーブル８９は、ホストの宛先ＩＰアドレスに対応する転送先の管理サーバ４０のＩＰアドレスを含む１以上のエントリが登録される。
【００５２】
ホストＩＤ−ＬＯＣ管理テーブル９０は、パケットが宛先ＩＰアドレスへ転送される際に経由するエッジノード２０のアドレスのリストと、リストが最下位階層（リーフ）のエッジノード（最終エッジ）を含んでいるか否かを示す情報を保持する。図９は、ホストＩＤ−ＬＯＣ管理テーブル９０のデータ構造例を示す。図９に示すように、ホストＩＤ−Ｌ
ＯＣ管理テーブル９０は、登録された１以上のエントリを含む。各エントリは、ホストの宛先ＩＰアドレス（ホストＩＤ）と、宛先ＩＰアドレスへ向けてコア網１０を転送されるパケットが経由する１以上のエッジノード２０のアドレスを含むアドレスリスト（“エッジノードリスト”、又は“ＬＯＣリスト”と呼ぶ）と、エッジノードリストに含まれたアドレスを有するエッジノードがツリーの最下位層（リーフ）に該当するエッジノード（最終エッジと呼ぶ）のアドレスを含んでいるか否かを示す情報（例えば、ＹＥＳ、ＮＯを示すフラグ）とを含む。
【００５３】
ＬＯＣ管理サーバ情報テーブル８９及びホストＩＤ−ＬＯＣ管理テーブル９０は、ＨＤＤ８３によって保持される。なお、ＬＯＣ管理サーバ情報テーブル８９に登録される情報とホストＩＤ−ＬＯＣ管理テーブル９０に登録される情報とは、１つのテーブルによって管理されるように変形することができる。
【００５４】
＜動作例１＞
次に、図１に示したネットワークシステムにおける動作例１について説明する。図１０は、動作例１の説明図であり、図１に示したネットワークシステムが図示されている。図１０に示すホスト３１（ＩＤ＃１）がホスト３２（ＩＤ＃２）へパケットを転送する動作を以下に説明する。
【００５５】
ホスト３１はエッジノード２１に接続されており、ホスト３２はエッジノード２に接続されている。ホスト３１に対してＩＰアドレス“ホストＩＰ１（ＩＤ＃１）”が割り当てられ、ホスト３２に対して“ホストＩＰ２（ＩＤ＃２）”が割り当てられている。エッジノード２２は、階層化されたエッジノードツリーのリーフに位置し、エッジノードツリーは、エッジノード２５をルート（最上位層）として、エッジノード２６を含む中間層（上位層）、エッジノード２７を含む中間層（下位層）、エッジノード２２，２３，２４を含む最下位層が形成されている。
【００５６】
各エッジノード２１〜２７には、ＩＰアドレス（エッジノードアドレス）である“ＬＯＣ１”，“ＬＯＣ２”，“ＬＯＣ３”，“ＬＯＣ４”，“ＬＯＣ５”，“ＬＯＣ６”，“ＬＯＣ７”が夫々割り当てられている。
【００５７】
各エッジノード２１〜２７は、管理サーバ４１〜４４によって管理されている。エッジノード２１〜２７と、管理サーバ４１〜４４は、次のような対応関係を有する。すなわち、エッジノード２１は管理サーバ４１によって管理されている。エッジノード５は管理サーバ４２によって管理されている。エッジノード２６は管理サーバ４３によって管理されている。エッジノード２７，２２，２３，２４は管理サーバ４４に管理されている。管理サーバ４４のように、管理サーバ４０は、単一のエッジノードだけでなく、エッジノードツリー上の同一階層に位置する複数のエッジノードを管理したり、複数の階層（異なる階層）に属する複数のエッジノードを管理したりすることができる。
【００５８】
図１１は、管理サーバ４１が保持するＬＯＣ管理サーバ情報テーブル８９の登録内容例を示す。管理サーバ４１のＬＯＣ管理サーバ情報テーブル８９は、ホスト３２のＩＰアドレス“ホストＩＰ２”に対応する管理サーバ４２のＩＰアドレスが格納されたエントリと、ホスト３３のＩＰアドレス“ホストＩＰ３”に対応する管理サーバ４２のＩＰアドレスが格納されたエントリとを保持する。
【００５９】
図１２は、管理サーバ４２が保持するＬＯＣ管理サーバテーブル８９の登録内容例を示す。管理サーバ４２のＬＯＣ管理サーバ情報テーブル８９は、ホスト３２のＩＰアドレス“ホストＩＰ２”に対応する管理サーバ４３のＩＰアドレスが格納されたエントリと、ホスト３３のＩＰアドレス“ホストＩＰ３”に対応する管理サーバ４３のＩＰアドレスが格
納されたエントリとを保持する。
【００６０】
図１３は、管理サーバ４３が保持するＬＯＣ管理サーバテーブル８９の登録内容例を示
す。管理サーバ４３のＬＯＣ管理サーバ情報テーブル８９は、ホスト３２のＩＰアドレ
ス“ホストＩＰ２”に対応する管理サーバ４４のＩＰアドレスが格納されたエントリと、ホスト３３のＩＰアドレス“ホストＩＰ３”に対応する管理サーバ４４のＩＰアドレスが格納されたエントリとを保持する。
【００６１】
図１４は、管理サーバ４２が保持するホストＩＤ−ＬＯＣ管理テーブルの登録内容例を示す。管理サーバ４２のホストＩＤ−ＬＯＣ管理テーブル９０は、ホスト３２のＩＰアドレス“ホストＩＰ２”，ホスト３３のＩＰアドレス“ホストＩＰ３”のそれぞれに関して、対応するエッジノードリスト“ＬＯＣ５”と、エッジノードリストが最終エッジを含まないことを示す情報（“Ｎｏ”）とを保持している。
【００６２】
図１５は、管理サーバ４３が保持するホストＩＤ−ＬＯＣ管理テーブル９０の登録内
容例を示す。管理サーバ４３のホストＩＤ−ＬＯＣ管理テーブル９０は、ホスト３２のＩＰアドレス“ホストＩＰ２”，ホスト３３のＩＰアドレス“ホストＩＰ３”のそれぞれに関して、対応するエッジノードリスト“ＬＯＣ６”と、エッジノードリストが最終エッジを含まないことを示す情報（“Ｎｏ”）とを保持している。
【００６３】
図１６は、管理サーバ４４が保持するホストＩＤ−ＬＯＣ管理テーブルの登録内容例を示す。管理サーバ４４のホストＩＤ−ＬＯＣ管理テーブル９０は、ホスト３２のＩＰアドレス“ホストＩＰ２”に関して、対応するエッジノードリスト“ＬＯＣ７，ＬＯＣ２”及び最終エッジを含むことを示す情報（“Ｙｅｓ”）を含むエントリを保持する。また、管理サーバ４４のホストＩＤ−ＬＯＣ管理テーブル９０は、ホスト３３のＩＰアドレス“ホストＩＰ３”に関して、対応するエッジノードリスト“ＬＯＣ７，ＬＯＣ３”及び最終エッジを含むことを示す情報（“Ｙｅｓ”）を含むエントリを保持する。
【００６４】
図１７は、データパケットを受信したエッジノード２０（エッジノード２１〜２７の何れか）で実行される処理例を示すフローチャートである。図１７の処理は、エッジノード２０のインタフェースカード５４でネットワークから受信されたデータパケットをスイッチカード５２が受信することによって開始される（Ｓ０１）。
【００６５】
データパケットを受信したスイッチカード５２（パケット転送部６２）は、データパケットに設定された宛先ＩＰアドレスに対応するエントリを経路テーブル６６から検索する（Ｓ０２）。対応するエントリが検索された（ヒットした）場合には、当該エントリに格納された宛先ＩＰアドレスに対応する転送先情報に基づき、転送先情報に対応するインタフェースカード５４にデータパケットが転送され、当該インタフェースカード５４からネットワークへ送出される（Ｓ０３）。
【００６６】
これに対し、宛先ＩＰアドレスに対応する転送先情報を含むエントリがヒットしなかった場合には、スイッチカード５２は、宛先ＩＰアドレスに対応するＬＯＣを解決するためのＬＯＣ要求の生成を要求するメッセージをＣＰＵ５１に与える。ＣＰＵ５１は、ＬＯＣ要求生成部６８として、スイッチカード５２からの要求に基づいてＬＯＣ要求を生成し、対応する管理サーバ４０と接続されたインタフェースカード５４へＬＯＣ要求を送る。生成されたＬＯＣ要求には、宛先ＩＰアドレスとＬＯＣ要求元アドレスとが格納される。ＬＯＣ要求を受け取ったインタフェースカード５４は、ＬＯＣ要求送信部６９として、ＬＯＣ要求をネットワーク（管理サーバ４０）へ送信する（Ｓ０４）。
【００６７】
図１８は、ＬＯＣ要求を受信した管理サーバ４０（管理サーバ４１〜４４の何れか）で
実行される処理例を示すフローチャートである。図１８に例示する処理は、ＬＯＣ要求をネットワークから受信したネットワークインタフェース８４（ＬＯＣ要求受信部８５）がネットワークから受信したＬＯＣ要求をＣＰＵ８１に送り、ＣＰＵ８１がＬＯＣ要求を受信する（Ｓ２１）ことによって開始される。
【００６８】
ＣＰＵ８１は、ＬＯＣ要求処理部８６としての機能を用い、以下の処理を行う。すなわち、ＣＰＵ８１は、ホストＩＤ−ＬＯＣ管理テーブル９０（図９）を参照し、ＬＯＣ要求に含まれる宛先ＩＰアドレスに対応するエントリを検索する（Ｓ２２）。対応するエントリがヒットした場合には、ＣＰＵ８１は、ヒットしたエントリ中のエッジノードリスト（ＬＯＣリスト）が最下位層のエッジノード（リーフ：最終エッジ）を含むか否かを判定する（Ｓ２３）。
【００６９】
最終エッジが含まれない場合には、ＣＰＵ８１は、ヒットしたエントリ中のＬＯＣリストに含まれるＬＯＣ（エッジノードアドレス）を、ＬＯＣ要求に追加する（Ｓ２４）。続いて、ＣＰＵ８１は、ＬＯＣ管理サーバ情報テーブル８９（図８）を参照し、ＬＯＣ要求中の宛先ＩＰアドレスに対応するエントリを検索する（Ｓ２５）。
【００７０】
対応するエントリがヒットした場合には、ＣＰＵ８１は、エントリ中の管理サーバアドレスへＬＯＣ要求を転送する。すなわち、宛先ＩＰアドレスがＬＯＣ管理サーバ情報テーブル８９から得られた管理サーバアドレスに設定されたＬＯＣ要求がＣＰＵ８１から対応するインタフェースカード５４へ転送され、当該インタフェースカード５４からネットワーク（次の管理サーバ４０）へ送信される。これに対し、対応するエントリがヒットしない場合には、ＬＯＣ要求に含まれる宛先IPアドレスが存在しないとして、所定のエラー処理が行われる（Ｓ２７）。
【００７１】
Ｓ２３において、ＬＯＣリストに最終エッジが含まれると判定された場合には、ＣＰＵ８１は、ＬＯＣ応答を生成する。このとき、ＣＰＵ８１は、宛先ＩＰアドレスと、ＬＯＣ要求元アドレスと、ＬＯＣ要求に含まれるＬＯＣリストに含まれるＬＯＣ（エッジノードアドレス）と、Ｓ２２でヒットしたエントリ中のＬＯＣリスト（エッジノードアドレス）とをＬＯＣ応答に含める（Ｓ２８）。
【００７２】
ＣＰＵ８１は、ＬＯＣ応答に含まれるＬＯＣリスト中の最終エッジ、又は最終エッジの１つ前のエッジノードへＬＯＣ応答を送信する（Ｓ２９）。すなわち、ＣＰＵ８１は、ＬＯＣ応答を送信先のエッジノード２０に対応するインタフェースカード５４へ送り、当該インタフェースカード５４は、ＬＯＣ応答をネットワーク（対応するエッジノード２０）へ送信する。
【００７３】
図１９は、ＬＯＣ応答を受信したエッジノード２０（エッジノード２１〜２７の何れか）で実行される処理例を示すフローチャートである。図１９に示す処理は、エッジノード２０のインタフェースカード５４で受信されたＬＯＣ応答をＣＰＵ５１が受け取ることによって開始される（Ｓ３１）。
【００７４】
ＬＯＣ応答を受信したＣＰＵ５１は、スイッチカード５２が有する経路テーブル６６（図４）の登録内容を参照（スイッチカード５２から入手）し、宛先ＩＰアドレス（ＬＯＣ要求中のホストの宛先ＩＰアドレス）を有するホストがエッジノード２０に接続されているか否かを判定する（Ｓ３２）。ホストが接続されている場合には、ＣＰＵ５１は、上位層側に位置する他のエッジノード２０へＬＯＣ応答を転送する（Ｓ３３）。当該Ｓ３３の処理は、例えば、ＬＯＣ応答を管理サーバ４４から受信したエッジノード２２がＬＯＣ応答を上位層側のエッジノード２７へ転送するための処理である。すなわち、エッジノード自身の配下にホストが実際に接続されていれば、Ｓ３３に処理が進み、そうでなければＳ
３４に処理が進むようにしている。但し、最終エッジに相当するエッジノード２２では、ホストが接続されていなければ、エラー処理が行われるようになっている。
【００７５】
Ｓ３２において、宛先ＩＰアドレスが登録されていない場合には、ＣＰＵ５１は、トン
ネル生成部７１として機能する。すなわち、ＣＰＵ５１は、ＬＯＣ応答中のＬＯＣリス
トの最後に位置するＬＯＣ及び対応するトンネル番号を含むエントリをトンネル管理テーブル６７（図５）に登録する。また、ＣＰＵ５１は、“ホストＩＰ２”に対応する転送先（転送経路）を示すトンネル番号を含むエントリを経路テーブル６６（図４）に登録する（Ｓ３４）。経路テーブル６６及びトンネル管理テーブル６７に対する登録処理は、ＣＰＵ５１がスイッチカード５２に対する上記した各エントリの登録指示を与え、スイッチカード５２が各テーブル６６及び６７の更新（エントリ登録）を行うことによって実現される。
【００７６】
ＣＰＵ５１は、自エッジノードがホストからデータパケットを受信したエッジノード２０か否かを判定する（Ｓ３５）。データパケットを受信したエッジノード２０に該当する場合には、ＬＯＣ要求送信前に受信したデータパケットの転送指示をスイッチカード５２に与える。スイッチカード５２は、パケット転送部６２及びカプセル部６５として機能し、更新された経路テーブル６６及びトンネル管理テーブル６７を用いてデータパケットをカプセル化し（ＬＩＳＰパケットを生成し）、宛先ＩＰアドレス（ＬＯＣ）に応じたインタフェースカード５４へＬＩＳＰパケットを転送する。インタフェースカード５４は、ＬＩＳＰパケットをトンネルによって結ばれた次ホップのエッジノード２０へ送信する（Ｓ３６）。但し、ＬＯＣ応答を受信するまでパケットを保持しておくことは要求されない。
【００７７】
一方、Ｓ３５において、データパケットを受信したエッジノードでないと判定される場合には、ＣＰＵ５１は、ＬＯＣ応答中のＬＯＣリストからエントリ登録に用いたＬＯＣを除去する（Ｓ３７）。ＬＯＣ応答中のＬＯＣリストからエントリ登録に用いたＬＯＣを除去した結果、２つ以上のＬＯＣ情報がある場合（Ｓ３８，２以上）には、その後のＬＯＣリストの最後に位置するＬＯＣより１つ前に位置するＬＯＣを有するエッジノードへＬＯＣ応答を転送する（Ｓ３９）。ＬＯＣを除去した結果、ＬＯＣ情報が１つになった場合（Ｓ３８，１つ）には、ＬＯＣ要求元アドレスにＬＯＣ応答を転送する（Ｓ４０）。このとき、ＬＯＣ応答は、ＣＰＵ５１から対応するインタフェースカード５４へ与えられ、インタフェースカード５４からネットワークへ送出される。
【００７８】
以下、図１０に示すネットワークにおいて、管理サーバ４１〜４４が図１１〜図１６に示したテーブルエントリを有し、且つ各エッジノード２１〜２７が図１７及び図１９に示した処理を行い、各管理サーバ４１〜４４が図１８に示す処理を行うことを前提に、動作例１を説明する。
【００７９】
＜＜フェーズ１＞＞
ホスト３１は、宛先ＩＰアドレス“ホストＩＰ２”が設定されたユーザデータパケット（以下、動作例において、単に「パケット」と表記）を送信する（図１０（１））。パケットは、エッジノード２１で受信される。
【００８０】
＜＜フェーズ２＞＞
パケットを受信したエッジノード２１では、経路テーブル６６が参照され、パケットの宛先ＩＰアドレス“ホストＩＰ２”に対応する転送経路が特定される。ホスト３２宛のパケットがエッジノード２１に最初に到着したときには、経路テーブル６６は、“ホストＩＰ２”向けの転送先情報を保持していない。すなわち、ホストＩＰ２に対応する経路が存在しない。このため、エッジノード２１は、“ホストＩＰ２”に対応するＬＯＣを解決するためのＬＯＣ要求を生成し、管理サーバ４１へ送信する。（図１０（２））。生成され
たＬＯＣ要求は、宛先ＩＰアドレス “ホストＩＰ２” とＬＯＣ要求元アドレス“ＬＯＣ１"とを含む。
【００８１】
＜＜フェーズ３＞＞
管理サーバ４１は、ＬＯＣ要求を受信すると、ＬＯＣ管理サーバ情報テーブル８９（図１１）を参照する。このとき、ＬＯＣ要求に含まれた“ホストＩＰ２”に対応する管理サーバ４２のＩＰアドレスがテーブル８９に登録されている。このため、管理サーバ４１は、ＬＯＣ要求を管理サーバ４２へ転送する（図１０（３））。但し、ＬＯＣ管理テーブルには、管理サーバアドレスの代わりに、管理サーバへＬＯＣ要求を転送する中継サーバのアドレスが登録され、中継サーバが次の管理サーバ宛のＬＯＣ要求を中継する構成が採用されても良い。
【００８２】
＜＜フェーズ４＞＞
ＬＯＣ要求を受信した管理サーバ４２は、ホストＩＰ−ＬＯＣ管理テーブル９０（図１４）を参照し、“ホストＩＰ２”宛てのパケットが経由するエッジノードが管理されているかを確認する。すなわち、管理サーバ４２は、テーブル９０からＬＯＣ要求中のホストの宛先ＩＰアドレス“ホストＩＰ２”に対応するエントリを検索する。図１４に示すように、ホストＩＰ−ＬＯＣ管理テー部９０は、“ホストＩＰ２”に対応するエントリが登録されており、検索によって当該エントリがヒットする。
【００８３】
管理サーバ４２は、ヒットしたエントリ中の、ＬＯＣリストが最終エッジを含むか否かを示す情報（最終エッジ情報）を参照する。以下の説明において、最終エッジ情報によって示される、最終エッジを含むことを示す情報を“Ｙｅｓ情報”と表記し、最終エッジを含まないことを示す情報を“Ｎｏ情報”と表記する。最終エッジ情報がＮｏ情報であるので、管理サーバ４２は、エントリ中のエッジノードリスト（ＬＯＣリスト）として登録されている“ＬＯＣ５（エッジノード２５のＩＰアドレス）”をＬＯＣ要求に格納する。
【００８４】
続いて、管理サーバ４２は、ＬＯＣ管理テーブル８９（図１２）を検索する。このとき、“ホストＩＰ２”に対応する転送先として管理サーバ４３のＩＰアドレスが登録されたエントリがヒットする。管理サーバ４２は、ヒットしたエントリに従って、ＬＯＣ要求を管理サーバ４３に転送する（図１０（４））。
【００８５】
＜＜フェーズ５＞＞
ＬＯＣ要求を受信した管理サーバ４３は、管理サーバ４２と同様の動作を行う。すなわち、管理サーバ４３は、ホストＩＤ−ＬＯＣ管理テーブル９０（図１５）の参照によって、ＬＯＣ要求中のＬＯＣリストにエッジノード２６のＩＰアドレス“ＬＯＣ６”を追加する（ＬＯＣ要求中のＬＯＣリストは、ＬＯＣ５及びＬＯＣ６を含む状態となる）。また、管理サーバ４３は、ＬＯＣ管理テーブル８９（図１３）の参照によって、宛先ＩＰアドレス“ホストＩＰ２”に対応する管理サーバ４４のＩＰアドレス宛にＬＯＣ要求を転送する（図１０（５））。
【００８６】
＜＜フェーズ６＞＞
ＬＯＣ要求を受信した管理サーバ４４は、管理サーバ４２，４３と同様に、ホストＩＰ−ＬＯＣ管理テーブル９０（図１６）を検索する。このとき、“ホストＩＰ２”に対応するエントリがヒットする。ヒットしたエントリの最終エッジ情報はＹｅｓ情報である（図１６）。このため、管理サーバ４４は、ＬＯＣ応答を生成する。ＬＯＣ応答には、ＬＯＣ要求元アドレス“ＬＯＣ１"と、ＬＯＣ要求中のＬＯＣリストに含まれた全てのＬＯＣと
、ヒットしたエントリ中のＬＯＣリストに含まれた全てのＬＯＣとが格納される。したがって、ＬＯＣ応答は、複数のＬＯＣ情報として、“ＬＯＣ５”，“ＬＯＣ６”，“ＬＯＣ７”及び“ＬＯＣ２”を含むＬＯＣリストを含んだ状態となる。ＬＯＣリストに含まれる
複数のＬＯＣは、本実施形態では、ルートからリーフへ向かう順に並んだ状態で格納される。
【００８７】
管理サーバ４４は、予め設定されたＬＯＣ応答の送信先情報に従って、最終エッジであるエッジノード２０（エッジノード２２），又は最終エッジより１つ前のエッジノード２０（エッジノード２７）へＬＯＣ応答を送信する。ＬＯＣ応答の送信先情報は、例えば、ＨＤＤ８３のような二次記憶装置上に予め保持されることができる。送信先情報は、例えば、ホストＩＤ−ＬＯＣ管理テーブル９０の、最終エッジであることを示す情報を保持するエントリ中に含めることができる。以降の動作は、ＬＯＣ応答がエッジノード２７へ送信された場合を例示する（図１０（６））。
【００８８】
＜＜フェーズ７＞＞
ＬＯＣ応答を受信したエッジノード２７は、ＬＯＣ応答に格納されているＬＯＣリストの最後に位置するＬＯＣ（ＬＯＣ２）を、エッジノード２７が有するトンネル管理テーブル６７に登録する。例えば、トンネル番号“１”に対応する“ＬＯＣ２”として登録する。図２０は、エッジノード２７のトンネル管理テーブル６７に登録されるエントリを示す。
【００８９】
さらに、エッジノード２７は、エッジノード２７が有する経路テーブル６６に対し、“ホストＩＰ２”宛のパケットに対応する転送経路は、トンネル番号“１”のトンネル（トンネル１）であることを示すエントリが登録される。図２１は、エッジノード２７の経路テーブル６６に登録されるエントリを示す。これによって、エッジノード２７で受信した“ホストＩＰ２”（ホスト３２）宛のパケットは、エッジノードアドレス“ＬＯＣ２”を宛先ＩＰアドレスとするヘッダをパケットの先頭に追加してカプセリングすることによって、トンネル１へ転送することができる。
【００９０】
エッジノード２７は、ＬＯＣ応答中のＬＯＣリストから“ＬＯＣ２”を取り除く。これによって、ＬＯＣリストに含まれる１以上のＬＯＣは、“ＬＯＣ５”，“ＬＯＣ６”，“ＬＯＣ７”となる。エッジノード２７は、ＬＯＣリストにおける“ＬＯＣ７”の１つ前に示されたＬＯＣ（“ＬＯＣ６”）を有するエッジノード２６へＬＯＣ応答を転送する（図１０（７））。
【００９１】
＜＜フェーズ８＞＞
ＬＯＣ応答を受信したエッジノード２６も、エッジノード２７と同様の処理を行う。すなわち、エッジノード２６は、エッジノード２６が有するトンネル管理テーブル６７に対し、“ＬＯＣ７”に対応するトンネル番号“１”を含むエントリを登録する。図２２は、エッジノード２６のトンネル管理テーブル６７に登録されるエントリを示す。また、エッジノード２６は、エッジノード２６が有する経路テーブル６６に対し、ホストＩＰアドレス“ホストＩＰ２”に対応するトンネル番号“１”を含むエントリを登録する（図２１参照）。そして、エッジノード２６は、ＬＯＣ応答中のＬＯＣリストから、最後に位置する“ＬＯＣ７”を取り除き、次のエッジノードに該当するエッジノード２５へ、“ＬＯＣ５”及び“ＬＯＣ６”のＬＯＣリストを含むＬＯＣ応答を送信する（図１０（８））。
【００９２】
＜＜フェーズ９＞＞
ＬＯＣ応答を受信したエッジノード２５も、エッジノード２７，エッジノード２６と同様の動作を行う。すなわち、エッジノード２５は、エッジノード２５が有するトンネル管理テーブル６７に対し、“ＬＯＣ６”に対応するトンネル番号“１”を含むエントリを登録する。図２３は、エッジノード２５のトンネル管理テーブル６７に登録されるエントリを示す。また、エッジノード２５は、エッジノード２５が有する経路テーブル６６に対し、ホストＩＰアドレス“ホストＩＰ２”に対応するトンネル番号“１”を含むエントリを
登録する（図２１参照）。そして、エッジノード２５は、ＬＯＣ応答中のＬＯＣリストから、最後に位置する“ＬＯＣ６”を取り除く。これによって、ＬＯＣ応答中のＬＯＣリストのＬＯＣ情報が“ＬＯＣ５”の１つとなる。このため、エッジノード２５は、ＬＯＣ要求元アドレス“ＬＯＣ１”（すなわち、エッジノード２１）へ、 “ＬＯＣ５”のＬＯＣ
リストを含むＬＯＣ応答を送信する（図１０（９））。
【００９３】
＜＜フェーズ１０＞＞
ＬＯＣ応答を受信したエッジノード２１は、エッジノード２７，２６，２５と同様の動作を行う。すなわち、エッジノード２１は、エッジノード２１が有するトンネル管理テーブル６７に対し、“ＬＯＣ５”に対応するトンネル番号“１”を含むエントリを登録する。図２４は、エッジノード２１のトンネル管理テーブル６７に登録されるエントリを示す。また、エッジノード２１は、エッジノード２１が有する経路テーブル６６に対し、ホストＩＰアドレス“ホストＩＰ２”に対応するトンネル番号“１”を含むエントリを登録する（図２１参照）。
【００９４】
これによって、ホスト３１を収容するエッジノード２１と、宛先のホスト３２を収容するエッジノード２２との間に、エッジノード２５，エッジノード２６及びエッジノード２７を経由する多段トンネルが構築された状態となる（図１０（１０））。多段トンネルは、上記したように、同一のトンネル番号で管理することができる。このような多段トンネルを用いて、フェーズ２でエッジノード２１がホスト３１から受信したデータパケットをエッジノード２２まで転送することができる。
【００９５】
＜＜フェーズ１１＞＞
以下のフェーズ１１〜１５において、フェーズ２〜１０によって確立された複数段を有するトンネル（多段トンネル）を用いてフェーズ２で転送できなかったホストＩＰ２宛のパケット、および、その後にホスト３１からエッジノード２１へ送信されるホストＩＰ２宛のパケットを転送する際の動作例を説明する。
【００９６】
エッジノード２１は、エッジノード２１が有する経路テーブル６６（図２１参照）を参照し、“ホストＩＰ２”の転送経路を特定する。経路テーブル６６には、“ホストＩＰ２”の転送経路として、トンネル１が登録されている。さらに、“ホストＩＰ２”をトンネル１を介して転送するためのＬＯＣである“ＬＯＣ５”が、エッジノード２１のトンネル管理テーブル６７に登録されている（図２４参照）。従って、エッジノード２１は、ホスト３１からのパケットに宛先エッジノードアドレス“ＬＯＣ５”を含むヘッダを追加してカプセリングし（ＬＩＳＰパケットを生成し）、次のエッジノード２５へ転送する（図１０（１１））。
【００９７】
＜＜フェーズ１２＞＞
カプセル化されたパケット（ＬＩＳＰパケット）を受信したエッジノード２５は、ＬＩＳＰパケットの先頭に追加されたヘッダを削除する（デカプセル）。続いてエッジノード２５は、元のパケットの宛先ＩＰアドレス“ホストＩＰ２”に対応するエントリを経路テーブル６６（図２１参照）から検索する。
【００９８】
エッジノード２５の経路テーブル６６には、“ホストＩＰ２”の転送経路として、トンネル１が登録されている。さらに、“ホストＩＰ２”をトンネル１を介して転送するためのＬＯＣである“ＬＯＣ６”が、エッジノード２５のトンネル管理テーブル６７に登録されている（図２３参照）。従って、エッジノード２５は、元のパケットの先頭に宛先エッジノードアドレス“ＬＯＣ６”を含むヘッダを追加してカプセリングし（ＬＩＳＰパケットを生成し）、次のエッジノード２６へ転送する（図１０（１２））。
【００９９】
＜＜フェーズ１３＞＞
カプセル化されたパケット（ＬＩＳＰパケット）を受信したエッジノード２６は、エッジノード２５と同様の動作を行う。すなわち、エッジノード２６は、ＬＩＳＰパケットの先頭に追加されたヘッダを削除する（デカプセル）。続いてエッジノード２６は、デカプセルされたパケット（元のパケット）の宛先ＩＰアドレス“ホストＩＰ２”に対応するトンネル番号を、エッジノード２６が有する経路テーブル６６（図２１参照）から検索する。
【０１００】
検索によって、“ホストＩＰ２”の転送経路として“トンネル１”がヒットする。また、エッジノード２６が有する経路テーブル６７（図２２）の検索によって、“ホストＩＰ２”に対応する“ＬＯＣ７”がヒットする。従って、エッジノード２６は、元のパケットの先頭に宛先エッジノードアドレス“ＬＯＣ７”を含むヘッダを追加してカプセリングし（ＬＩＳＰパケットを生成し）、次のエッジノード２７へ転送する（図１０（１３））。
【０１０１】
＜＜フェーズ１４＞＞
カプセル化されたパケット（ＬＩＳＰパケット）を受信したエッジノード２７は、エッジノード２５や２６と同様の動作を行う。すなわち、エッジノード２７は、ＬＩＳＰパケットの先頭に追加されたヘッダを削除する（デカプセル）。続いてエッジノード２７は、デカプセルされたパケット（元のパケット）の宛先ＩＰアドレス“ホストＩＰ２”に対応するトンネル番号を、エッジノード２７が有する経路テーブル６６（図２１参照）から検索する。
【０１０２】
検索によって、“ホストＩＰ２”の転送経路として“トンネル１”がヒットする。また、エッジノード２７が有する経路テーブル６７（図２０）の検索によって、“ホストＩＰ２”に対応する“ＬＯＣ２”がヒットする。従って、エッジノード２６は、元のパケットの先頭に宛先エッジノードアドレス“ＬＯＣ２”を含むヘッダを追加してカプセリングし（ＬＩＳＰパケットを生成し）、次のエッジノード２２へ転送する（図１０（１４））。
【０１０３】
＜＜フェーズ１５＞＞
カプセル化されたパケット（ＬＩＳＰパケット）を受信したエッジノード２２は、ＬＩＳＰパケットの先頭に追加されたヘッダを削除する（デカプセル）。続いてエッジノード２７は、デカプセルされたパケット（元のパケット）の宛先ＩＰアドレス“ホストＩＰ２”に対応する転送先を、エッジノード２２が有する経路テーブル６６から検索する。
【０１０４】
エッジノード２２が有する経路テーブル６６には、“ホストＩＰ２”に対応する転送先として、ホスト３２のアドレスである“ホストＩＰ２”又は“ホストＩＰ２”へのパケットを転送する次ホップルータのＩＰアドレスが登録されている。従って、エッジノード２２は、通常のルーティング処理と同様の処理によって、ホスト３２へ向けてパケットを転送する（図１０（１５））。
【０１０５】
以上のようにして、コア網１０では、ホスト３１からのパケット受信を契機として、コア網の入口エッジノード２１と出口エッジノード２２との間を１以上の中継エッジノード２５，２６，２７で結ぶ複数段のトンネルが確立され、確立されたトンネルを用いて宛先ホスト３２へパケットが転送される。
【０１０６】
動作例１によれば、１つのＬＯＣ要求によって、夫々ホストを収容する入口エッジノードと出口エッジノードとの間に、１以上の中継エッジノードを経由する複数段トンネル（多段トンネル）を構築することができる。これによって、トンネルの起点となるエッジノードの夫々がＬＯＣ要求を管理サーバ４０へ送信することで多段トンネルを構築する場合に比べて、処理の負荷や処理に要する時間を軽減することができる。
【０１０７】
＜動作例２＞
動作例１に続いて、ホスト３１がエッジノード２３に接続されているホスト３３へパケットを送信する場合の動作を、動作例２として説明する。動作例２でも、動作例１と同様に、エッジノード２１がホスト３３（“ホストＩＰ３”）宛のパケットをホスト３１から受信することを契機として、ホストＩＰ３に対応するＬＯＣを解決するためのＬＯＣ要求が管理サーバ４１へ送信される。
【０１０８】
ＬＯＣ要求は、管理サーバ４１〜４４が保持するホストＩＤ−ＬＯＣ管理テーブル９０，ＬＯＣ管理テーブル８９（図１１〜図１６）の登録内容に従って、管理サーバ４２→管理サーバ４３→管理サーバ４４の順で転送される。このような転送の際に、ＬＯＣ要求が含むＬＯＣリストには、“ＬＯＣ５”，“ＬＯＣ６”が登録される。そして、管理サーバ４４において、“ＬＯＣ５”，“ＬＯＣ６”，“ＬＯＣ７”，“ＬＯＣ３”が格納されたＬＯＣリストを有するＬＯＣ応答が、エッジノード２３又は２７へ送信される。但し、以降の説明は、エッジノード２７へＬＯＣ応答が送信される例について説明する。
【０１０９】
ＬＯＣ応答を受信したエッジノード２７は、エッジノード２３への新たなトンネルを生成するため、動作例１と同様の処理によって、エッジノード２７が有する経路テーブル６６及びトンネル管理テーブル６７にエントリを追加する。図２５は、エッジノード２７の経路テーブル６６に登録されたエントリを示し、図２６は、エッジノード２７のトンネル管理テーブル６７に登録されたエントリを示す。図２５に示すように、“ホストＩＰ３”に対応するトンネル番号“２”（トンネル２）を含むエントリが経路テーブル６６に追加されるとともに、図２６に示すように、トンネル番号“２”に対応するエッジノードアドレス“ＬＯＣ３”を含むエントリがトンネル管理テーブル６７に登録される。
【０１１０】
ＬＯＣ応答は、エッジノード２７→エッジノード２６→エッジノード２５→エッジノード１の順で転送される。ここで、エッジノード２６，２５，２１には、すでに下位階層のエッジノードへのトンネル１が登録されている。このため、エッジノード２６，２５及び２１は、新たにトンネルを生成せず、登録済みのトンネル１を使用して転送を行う。このため、エッジノード２６，２５，２１は、図２７に示すように、自ノードが有する経路テーブル６６に、“ホストＩＰ３”に対応する転送先情報（トンネル１）を登録する。図２７は、エッジノード２１，２５，２６が夫々有する経路テーブル６６のエントリを示す。
【０１１１】
動作例２によれば、既に構築された複数段トンネル（多段トンネル）の途中から枝分かれする経路を辿って到達する出口エッジノード（エッジノード２３）に収容されたホスト（ホスト３３）宛のトンネルが新たに構築される場合には、分岐点となるエッジノード（エッジノード２７）とホスト３３に対する出口エッジノード（エッジノード２３）との間に新たなトンネル（トンネル２）が構築され、分岐点から上流側（エッジノード２５−エッジノード２６−エッジノード２７）は、既に構築されたトンネル（トンネル１）が使用される。従って、トンネル構築に要する時間及び負荷を軽減することができる。
【０１１２】
＜動作例３＞
動作例１の終了後において、ホスト３２が移動し、ホスト３２が属するアクセス網がアクセス網１２からアクセス網１３に変更され、ホスト３２がエッジノード２３に収容された状態となった場合を仮定する。この場合、エッジノード２２，２３は、ホスト３２の移動を公知の手法（例えば、ＯＳＰＦ（Open Shortest Path First）のHelloパケットの利
用、或いはpingメッセージの利用）によって知ることができる。
【０１１３】
この場合、エッジノード２２は、エッジノード２７に対し、ホスト３２の不存在に起因するＬＯＣ変更要求を送信する。すると、エッジノード２７のＣＰＵ５１は、エッジノー
ド２２へ向けた“ホストＩＰ２”宛てのパケットの送信を停止する。続いて、エッジノード２７のＣＰＵ５１は、エッジノードツリーの最終エッジ（エッジノード２２）と同一階層に位置するエッジノード２３，２４の夫々に対し、各エッジノード２２，２３が“ホストＩＰ２”を収容しているか否かを問い合わせる（問い合わせメッセージを作成して送信する）。エッジノード２３，２４のエッジノードアドレスは、エッジノード２７の記憶装置５３に予め保持されている。
【０１１４】
エッジノード２３及び２４の夫々は、“ホストＩＰ２”宛てにpingメッセージを送信し、応答メッセージ“echo reply”を待つ。エッジノード２３及び２４の夫々は、応答メッセージの受領／非受領に基づき、問い合わせに対する回答メッセージ（“ホストＩＰ２の存在／非存在）をエッジノード２７に送信する。
【０１１５】
エッジノード２７は、回答メッセージをエッジノード２３及び２４から受信することによって、エッジノード２３又は２４がホスト３２を収容しているか否かを知ることができる。動作例３では、ホスト３２は、エッジノード２３に接続されているので、エッジノード２７は、エッジノード２３からの回答メッセージによって、ホスト３２がエッジノード２３に接続されていることを知ることができる。
【０１１６】
すると、エッジノード２７のＣＰＵ５１は、出口エッジノード（最終エッジ）を、エッジノード２２からエッジノード２３に変更する（エッジノード２７から先のトンネルの再構築を行う）ための処理を行う。すなわち、エッジノード２７は、エッジノード２７が有するトンネル管理テーブル６７（図２０参照）における、“トンネル１”，“ＬＯＣ２”のエントリを、新たなトンネル番号“２（トンネル２）”，“ＬＯＣ３”に書き換える。また、エッジノード２７は、エッジノード２７が有する経路テーブル６６（図２１参照）における“ホストＩＰ２”，“トンネル１”のエントリを、“ホストＩＰ２”（変更なし），“トンネル２”に書き換える。上記したテーブル６６，６７に対する書き換えは、ＣＰＵ５１がスイッチカード５２に対して書き換え指示を発行することによって行われる。これによって、エッジノード２７より下位階層側において、アクセス網１３へ移動したホスト３２宛てのパケットを転送するためのトンネル２が構築された状態となる。
【０１１７】
テーブル６６及び６７の書き換えが完了したエッジノード２７のＣＰＵ５１は、スイッチカード５２に対してパケット送信の再開指示を与える。スイッチカード５２は、再開指示に従って、書き換え後のテーブル６６及びテーブル６７の登録内容に基づき、“ホストＩＰ２”宛のパケットがＬＯＣ３を含むヘッダでカプセル化されたＬＩＳＰパケットをエッジノード２３へ送信する状態となる。このように、ホスト３２が属するアクセス網が変更された場合には、最終エッジより一つ上位側のエッジノード（エッジノード２７）から下位側のトンネルのみが再構築される。これによって、トンネル再構築に要する時間を短縮することができ、アクセス網の変更による転送の中断時間を短縮することができる。
【０１１８】
＜動作例４＞
動作例２の終了後に、ホスト３２がアクセス網１２からアクセス網１３へ移動して、出口エッジノード（最終エッジ）がエッジノード２２からエッジノード２３へ変更された場合を仮定する。エッジノード２２がＬＯＣ変更要求をエッジノード２７へ送信し、エッジノード２７がエッジノード２３，２４へ問い合わせを行い、回答メッセージによってエッジノード２３がホスト３２と接続されていることをエッジノード２７が認識するまでのステップは、動作例３と同じである。
【０１１９】
但し、動作例４では、動作例２での動作によって、エッジノード２７とエッジノード２３とを結ぶトンネル“トンネル２”が既に構築されている（図２５、図２６）。このため、エッジノード２７のＣＰＵ５１は、トンネル管理テーブル２７（図２６）から、“トン
ネル１”，“ＬＯＣ２”を削除する書き換え指示をスイッチカード５２に与える一方で、経路テーブル６６（図２５）における“ホストＩＰ２”，“トンネル１”のエントリを、“ホストＩＰ２”，“トンネル２”に書き換える書き換え指示をスイッチカード５２に与える。書き換え指示に従って、スイッチカード５２は、エッジノード２７の各テーブル６６，６７を更新する。これによって、動作例３と同様に、エッジノード２２からエッジノード２７までの間はトンネル１、エッジノード２７からエッジノード２３までの間はトンネル２が構築された状態となる。その後、動作例３と同様に、エッジノード２７にて“ホストＩＰ２”宛のパケットの転送処理が再開される。
【０１２０】
＜第１実施形態の効果＞
第１実施形態の動作例１によれば、ホスト間の通信開始時において、コア網１０の入口エッジノード２１がＬＯＣ要求を管理サーバ４１へ送信することを契機として、入口エッ
ジノード２１と出口エッジノード２２とを結ぶ多段トンネルが一括で構築される。この
ため、エッジノード２１，２５，２６，２７の夫々が、下位階層のエッジノードとの間でトンネルを構築するために、対応する管理サーバ４０にＬＯＣ要求を送信する場合に比べて、各エッジノードの負荷やトンネル構築に要する時間を短縮化することができる。また、エッジノード２１における、ホスト３２向け（“ホストＩＰ２”向け）パケットの転送中断時間の短縮化が図られる。
【０１２１】
また、動作例２によれば、入口エッジノードが共通で、出口エッジノードが異なるホスト（ホスト３３）へのトンネル構築時において、ツリーの分岐点となるエッジノード２７より下位層側のトンネル（エッジノード２７−エッジノード２３間のトンネル）のみが新規に構築される。これによって、トンネル構築に要する時間や各エッジノードにおける負荷の低減を図ることができる。
【０１２２】
さらに、動作例３，４によれば、ホスト３２が移動した場合に、エッジノード２７における経路テーブル６６及びトンネル管理テーブル６７の書き換えによって、移動後のホスト３２に対し、適正にパケットを転送することができる。動作例３、４によれば、下記の利点が得られる。
【０１２３】
図２７の参考図に示すように、ホスト３１とホスト３２との通信において、エッジノード２１とエッジノード２２との間にトンネルが構築された場合を仮定する。この場合において、ホスト３２が、アクセス網１２からアクセス網１３へ移動し、ホスト３２が接続されるエッジノードがエッジノード２２からエッジノード２３へ変更された場合を仮定する。
【０１２４】
このとき、エッジノード２２は、エッジノード２１へＬＯＣ変更を通知し、エッジノード２１は、エッジノード２３との間でトンネルを再構築する。これによって、ホスト３２向けのパケット転送を継続することができる。エッジノード２２からエッジノード２１へＬＯＣ変更が通知され、トンネルが再構築されるまでの間、ホスト３２へのパケット転送が途絶える。エッジノード２１とエッジノード２２との距離が長い程、パケット転送の中断時間は大きくなる。これに対し、動作例３、４によれば、エッジノード２１より距離が近いエッジノード２７へＬＯＣ変更が通知されるので、パケット転送の中断時間の短縮化を図ることができる。
【０１２５】
また、ホスト３１と通信するホスト３２が、アクセス網１２→アクセス網１３→アクセス網１４へ移動し、ホスト３２が接続されるエッジノードがエッジノード２２→エッジノード２３→エッジノード２４のように変更された場合でも、トンネル再構築に係る処理は、エッジノード２７におけるテーブル６６及び６７の書き換えだけで済む。従って、パケット転送の中断時間の長期化を抑え、円滑な通信の継続を期待することができる。
【０１２６】
＜変形例１＞
動作例１，２では、管理サーバ４４は、最終エッジ（エッジノード２２，２３）の１つ前のエッジノード(エッジノード２７)へＬＯＣ応答を送信する。これによって、最終エッジにおける処理が省略されるので、最終エッジの処理負荷が軽減されるとともに、トンネル確立のための処理時間を短くすることができる。
【０１２７】
但し、上述したように、管理サーバ４０が最終エッジにＬＯＣ応答を送信する構成が採用されても良い。この場合、図１９のＳ３３のように、ＬＯＣ応答を受信した最終エッジは、ＬＯＣ応答を修正することなく、ＬＯＣ応答中のＬＯＣリストに格納されている１つ上位階層のエッジノードへＬＯＣ応答を転送する。この場合には、最終エッジのエッジノードは、宛先ホストが確かに接続されているか確認したり、あるいは、トンネルから受信されるパケットのＱｏＳ（Quality of Service）制御の設定を行ったりできるという利点がある。
【０１２８】
＜変形例２＞
図１及び図１０に示した例では、管理サーバ４０のトポロジにおける最下位層の管理サーバ４４がエッジノードツリーにおける複数階層のエッジノード（エッジノード２７，２２，２３）を管理している。管理サーバ４０のトポロジにおいて最上位階層、あるいは中位階層に位置する管理サーバ４０が複数階層のエッジノードを管理するように、第１実施形態の構成を変更可能である。
【０１２９】
例えば、管理サーバ４３が存在せず、管理サーバ４２がエッジノード２５及びエッジノード２６を管理する場合には、管理サーバ４２は、図２９に示すＬＯＣ管理サーバ情報テーブル８９と、図３０に示すホストＩＤ−ＬＯＣ管理テーブル９０を保持する。図２８に示すように、ＬＯＣ管理サーバ情報テーブル８９は、“ホストＩＰ２”と“ホストＩＰ３”の双方に対して、管理サーバ４４のＩＰアドレスが保持された状態になる。また、図２９に示すように、ホストＩＤ−ＬＯＣ管理テーブル９０は、“ホストＩＰ２”と“ホストＩＰ３”の夫々に対して、“ＬＯＣ５”及び“ＬＯＣ６”からなるＬＯＣリストを保持する状態となる。
【０１３０】
そして、変形例２では、上記したフェーズ４において、以下のような動作が行われる。すなわち、ＬＯＣ要求を受信した管理サーバ４２のＣＰＵ８１は、ホストＩＤ−ＬＯＣ管理テーブル９０（図３０）を参照し、“ホストＩＰ２”に対応するエントリを検索する。エントリが検索されると、管理サーバ４２のＣＰＵ８１は、検索されたエントリからＬＯＣリスト（ＬＯＣ５，ＬＯＣ６）を取得する。検索されたエントリ中の最終エッジ情報はＮｏ情報であるので、管理サーバ４２のＣＰＵ８１は、ＬＯＣ５及びＬＯＣ６が格納されたＬＯＣ要求を、ＬＯＣ管理サーバ情報テーブル８９（図２９）から検索される管理サーバ４４のＩＰアドレスへ転送する。
【０１３１】
変形例２によれば、ＬＯＣ要求に対する処理を行う管理サーバ４０の数を減らすことができるので、多段トンネル構築に要する時間の短縮化を期待することができる。
〔第２実施形態〕
次に、本発明の第２実施形態について説明する。第２実施形態は、第１実施形態との共通点を含むので、主として相違点について説明し、共通点については詳細な説明を省略する。第２実施形態における動作例として、図１に示したネットワークシステムにおいて、
第１ホスト３３がホスト３２へパケットを転送する場合の動作を説明する。
通常、送信側ホスト（ホスト３１）が接続している入口エッジノード（エッジノード２
１）のＬＯＣ管理サーバ情報テーブル８９には、エッジノードツリーのルートとなるエッジノード（エッジノード２５）を管理している管理サーバ４０（管理サーバ４２）のＩＰ
アドレスが登録される。このため、エッジツリー内のリーフ間での通信でも、ルートのエッジノード２０（エッジノード２５）を経由するパケット転送となってしまう。コア網１０内でのパケット転送は、エッジノードツリーのルートを起点として行われるように制御されるからである。
【０１３２】
第２実施形態では、エッジノード２０が、ホストＩＤ−ＬＯＣ管理テーブル９０を最初に参照することによって、ルートのエッジノード２０（エッジノード２５）を経由しない効率的なトンネルを確立し、効率的な転送を行うことを可能にする手法について説明する。以下の説明においては、第１実施形態の動作例１と同様に、図１１〜図１６に示したような、ＬＯＣ管理サーバ情報テーブル８９，ホストＩＤ−ＬＯＣ管理テーブル９０が管理サーバ４１〜４４に保持されていることを仮定する。
【０１３３】
図１に示すネットワークシステムにおいて、ホスト３３がホスト３２向けのパケット（宛先ＩＰアドレス“ホストＩＰ２”）を送信する。“ホストＩＰ２”宛のパケットを受信したエッジノード２３は、経路テーブル６６を参照し、パケットの転送経路を特定する。ここで、“ホストＩＰ２”宛てのパケットが最初に到着したときには、経路テーブル６６には“ホストＩＰ２”宛の転送先を登録したエントリが存在しない。このため、エッジノード２３は、“ホストＩＰ２”に対応するＬＯＣを解決するためのＬＯＣ要求を管理サーバ４４へ送信する。
【０１３４】
ＬＯＣ要求を受信した管理サーバ４４のＣＰＵ８１は、管理サーバ４４が保持するホストＩＤ−ＬＯＣ管理テーブル９０（図１６）を参照し、管理下のエッジノードから送信されたＬＯＣ要求であるか否かを判別する。図１６に示す例では、“ホストＩＰ２”に対するエッジノードリスト（ＬＯＣリスト（ＬＯＣ７，ＬＯＣ２））がテーブル９０に登録されている。
【０１３５】
管理サーバ４４のＣＰＵ８１は、宛先ホストに最も近いエッジノードのＬＯＣをＬＯＣリストから抽出する。図１６に示す例では、エントリ中のＬＯＣリストに含まれるＬＯＣは、ルートからリーフへ向かう方向で並べて登録されている。従って、ＬＯＣリスト中の最後に配置されたＬＯＣ２が宛先ホスト（ホスト３２）に最も近いエッジノードのＬＯＣである。従って、ＣＰＵ８１は、ＬＯＣ２を抽出し、抽出したＬＯＣ２が格納されたＬＯＣ応答を生成し、ネットワークインタフェース８４を介してエッジノード２３へ直接に返信する。
【０１３６】
ＬＯＣ応答を受信したエッジノード２３は、エッジノード２３が有するトンネル管理テーブル６７に対し、ＬＯＣ応答に格納された“ＬＯＣ２”と、“ＬＯＣ２”に対応するトンネル番号とを含むエントリを登録する。また、エッジノード２３のＣＰＵ５１は、スイッチカード５２に対する指示によって、エッジノード２３が有する経路テーブル６６に対して、“ホストＩＰ２”に対応する転送経路情報としてエッジノードアドレス“ＬＯＣ２”が格納されたエントリを登録する。
【０１３７】
これによって、ホスト３３から得たホスト３２（ホストＩＰ２）宛のパケットをエッジノード２３とエッジノード２２との間に構築されたトンネルを通じてエッジノード２２へ転送することができる。すなわち、“ホストＩＰ２”宛のパケットに“ＬＯＣ２”を含むヘッダが付与されたカプセル化パケット（ＬＩＳＰパケット）をエッジノード２２へ転送することができる。エッジノード２２では、通常のルーティングに従って、エッジノード２２から受信されたＬＩＳＰパケットに対するデカプセル処理を行い、得られた元のパケットをホスト３２へ転送する。
【０１３８】
第２実施形態によれば、配下のエッジノード２０からＬＯＣ要求を受信した管理サーバ
４０が、ホストＩＤ−ＬＯＣ管理テーブル９０を参照し、ＬＯＣ要求に含まれるホストＩＰアドレス（宛先ホストＩＰアドレス）に対応するエントリを検索する。このとき、対応するエントリが見つかれば、エントリ中のＬＯＣリストから宛先ホストに最も近いエッジノード２０のＬＯＣが抽出され、このＬＯＣを端点とするトンネルが構築される。従って、エッジノードツリーのルート又は中位階層のエッジノード２０を経由しない、効率的なパケットの転送が可能となる。
【０１３９】
なお、エッジノードツリーにおける各エッジノード２０がどの程度、宛先ホストと離れているかを勘案し、効率的な転送経路を用いることが考えられる。例えば、ＬＯＣリストが最終エッジを含んでいる場合にのみ、ツリーの中で近接しているとして、ダイレクトなエッジ−エッジ間のトンネルを確立することが考えられる。あるいは、ホストＩＤ−ＬＯＣ管理テーブル９０に効率的転送が可能であるか否かを示すフラグを設け、フラグがＯＮ
にセットされている場合のみ、上記した効率的な転送経路を構築する手法を選択するこ
とが考えられる。
【０１４０】
〔第３実施形態〕
次に、本発明の第３実施形態について説明する。第３実施形態は、第１実施形態との共通点を含むので、主として相違点について説明し、共通点については詳細な説明を省略する。
【０１４１】
図１に示すネットワークシステムの例では、エッジノードツリーが、最上位階層（エッジノード２５），上位階層（エッジノード２６），下位階層（エッジノード２７），最下位層（エッジノード２２，２３，２４）の４階層を有する。
【０１４２】
このようなツリー構成において、ホスト３１がホスト３２へパケットを転送する場合において、コア網１０におけるパケットの転送経路が、常に全ての階層のエッジノード２０を経由することは要求されない。例えば、第１実施形態で説明したようなホストの移動が頻繁に発生したり、広範に移動したりする場合では、パケット転送経路が全ての階層のエッジノード２０を経由するように、転送経路を決定することが考えられる。これに対し、ホストの移動が頻繁に発生しない、あるいは、ホストの移動による一時的な切断よりも、経由エッジノード２０の削減によって低遅延で転送した方がよい通知が望まれる場合は、入口エッジノード（ＬＯＣ１）と最下位層エッジノード(ＬＯＣ２)とでダイレクトにトンネルを確立した方がよい場合があり得る。あるいは、ＬＯＣ１とＬＯＣ２の間にすべての階層ではないいくつかの階層のエッジノード２０を通過することによって、ホストの移動時の切り替え処理の効率化と、低遅延転送をバランスさせた経路を選択することがよい場合もある。これを実現するためには、以下の手法が考えられる。
【０１４３】
[方法１−１]
ＬＯＣ要求を受信した管理サーバ４０（第１実施形態における各管理サーバ４１〜４４）が、ＬＯＣ要求に含まれたホストの宛先ＩＰアドレス（宛先ホストＩＰアドレス）に応じてＬＯＣ要求を下位階層に位置する他の管理サーバ４０に転送する場合に、管理サーバ４０が管理しているエッジノード２０（例えば、管理サーバ４２であればエッジノード２５、より具体的には、管理サーバ４２が有するホストＩＤ−ＬＯＣ管理テーブル９０のＬＯＣリストに含まれたＬＯＣを持つエッジノード２５）のＬＯＣをＬＯＣ要求が有するＬＯＣリストに追加するか否かを判定する。例えば、宛先ホストの移動時における効率的なトンネル切り替えを優先する場合には、ＬＯＣの追加が決定される。これに対し、例えば、パケットが通過するエッジノード２０の数を削減した効率的なパケット転送を行うときには、ＬＯＣを追加しないことが決定される。
【０１４４】
また、上記したＬＯＣ要求にＬＯＣを追加するか否かの判定時において、移動時の効率
的な切り替え処理と効率的なパケット転送のバランスとが考慮され、管理サーバ４０が管理するエッジノード２０のうち、パケットが経由（通過）すべき一部のエッジノード２０のＬＯＣのみをＬＯＣ要求のＬＯＣリストに追加することを決定することもできる。ＬＯＣ要求は宛先ホストＩＰアドレスに従って、下位階層に位置する他の管理サーバ４０へ送信される。
【０１４５】
[方法１−２]
ＬＯＣ要求を受信した管理サーバ４０（第１実施形態における各管理サーバ４１〜４４）が、ＬＯＣ要求に含まれた宛先ホストＩＰアドレスに応じて送信するＬＯＣ応答に対し、管理サーバ４０自身が管理するエッジノード２０のＬＯＣを追加（格納）するか否かを判定する。そして、ホスト移動時の効率的なトンネル切り替え処理を優先する場合には、管理サーバ４０は、ＬＯＣの追加を決定し、管理サーバ４０自身が管理するエッジノード２０のＬＯＣをＬＯＣ応答に格納し、所定のエッジノード２０へ送信する。そうでなければ、ＬＯＣを追加しないことが決定される。
【０１４６】
また、ＬＯＣ応答にＬＯＣを追加するか否かの判定時において、ホスト移動時の効率的な切り替え処理と効率的なパケット転送とのバランスを考慮し、管理サーバ４０自身が管理するエッジノード２０のうちの一部をパケットが経由するように、パケットが経由すべきエッジノード２０のＬＯＣのみをＬＯＣ応答に追加することを決定することも可能である。
【０１４７】
[方法１−３]
管理サーバ４０（第１実施形態における各管理サーバ４１〜４４）によって受信されるＬＯＣ要求に対し、宛先ホストＩＰアドレスだけでなく、送信元ホストＩＰアドレス，プロトコルＩＤ，ポート番号のような、管理サーバ４０が管理するＬＯＣの全部追加、一部追加、追加無しの何れかを選択するための選択用情報が格納される。選択用情報に基づいて、ＬＯＣの全部追加、一部追加、追加無しが判定される。
【０１４８】
[方法２−１]
第１実施形態で説明したようなＬＯＣリストを保持したＬＯＣ応答を受信したエッジ
ノード２０（第１実施形態におけるエッジノード２７，２６，２５）が、ＬＯＣ応答に含まれる宛先ホストＩＰアドレス，又は、ホストの移動時の効率的な切り替え処理と効率的なパケット転送のバランスを考慮した結果に基づいて、パケットが通過するエッジノード（パケット転送時にバイパスされるエッジノード）を決定する。エッジノードは、決定の結果に従って、ＬＯＣ応答中のＬＯＣリストから、バイパスされる（パケットが経由しない）１以上のエッジノードのＬＯＣを削除する。ＬＯＣ応答は、上位階層のエッジノードへ転送される。
【０１４９】
[方法２−２]
エッジノード（第１実施形態におけるエッジノード２７，２６，２５）が受信する応答に宛先ホストＩＰアドレスだけでなく、送信元ホストＩＰ、プロトコルＩＤ、ポート番号などのような、ＬＯＣ応答に格納されたＬＯＣリストから、パケットが通過すべき（パケットがバイパスすべき）エッジノードを選択するための選択用情報が格納される。選択用情報に基づいて、パケットがバイパスすべきエッジノードが決定され、決定されたエッジノードのＬＯＣがＬＯＣ応答のＬＯＣリストから削除する。
【０１５０】
[判定基準]
上記した方法１−１，１−２，１−３におけるＬＯＣの全部追加、一部追加、追加無しの判定，及び方法２−１，２−２におけるＬＯＣの一部削除、削除無しの判定に使用される判定基準として、以下のものを例示できる。
（１）エッジノードの輻輳度合
各エッジノードにおける輻輳度合が監視され、輻輳度合に応じて対応するエッジノードが除外されるように、管理サーバ４０におけるＬＯＣの追加、エッジノードにおけるＬＯＣの削除が実施される。
【０１５１】
輻輳度合の監視は、例えば、エッジノード２０，管理サーバ４０、又は専用の監視サーバ（監視用ＰＣ；図示せず）で実施することができる。監視結果（すなわち、エッジノードの輻輳の有無を示す情報（輻輳情報））は、適宜のタイミングでInband通信又はOutband通信により、管理サーバ４０又はエッジノード２０に通知される構成が適用される。
【０１５２】
エッジノード２０の輻輳情報は、当該エッジノード２０を管理する管理サーバ４０に取得される。例えば、エッジノード２５の輻輳情報は、管理サーバ４２によって取得される。管理サーバ４０が取得する輻輳情報は、例えば、管理サーバ４０の二次記憶装置（ＨＤＤ８３）に格納される。輻輳情報は、例えば、管理サーバ４０が有するホストＩＤ−ＬＯＣ管理テーブル９０に格納することができる。例えば、テーブル９０のエントリに輻輳の有無を示すフラグ（例：０（オフ）：輻輳なし、１（オン）：輻輳あり）の格納領域を設けることができる。
【０１５３】
そして、管理サーバ４０のＣＰＵ８１が、テーブル９０から検索したエントリ中のＬＯＣリストをＬＯＣ要求に追加するか否かが判定される場合に、フラグがオフであれば、ＬＯＣリストがＬＯＣ要求に追加され、フラグがオンであれば、ＬＯＣ要求へＬＯＣリストが追加されないようにすることができる。エントリ中に複数のＬＯＣが格納される場合、輻輳の有無を示すフラグとして、複数のＬＯＣを代表する１つのフラグを用意してもよく、ＬＯＣ毎に用意されても良い。ＬＯＣ毎にフラグが用意される場合には、一部のフラグがオンで、一部のフラグがオフとなることによって、ＬＯＣの一部追加を実現することができる。
【０１５４】
エッジノード２０の輻輳情報は、ＬＯＣ応答を受信するエッジノード２０に通知、又はエッジノード２０自身の取得によって取得される。例えば、エッジノード２７は、エッジノード２２の輻輳情報を、エッジノード２２，管理サーバ４４，監視サーバから受領することができる。一方で、エッジノード２７の輻輳情報は、エッジノード２７自身で監視した結果を使用することができる。輻輳情報は、例えば、エッジノード２０の記憶装置５３で保持される。
【０１５５】
ＬＯＣ応答を受信したエッジノード２０のＣＰＵ５１は、記憶装置５３に保持された輻輳情報を参照し、ＬＯＣ応答中のＬＯＣの一部を削除するか否かを判定する。記憶装置５３に保持された輻輳情報は、エッジノード毎の輻輳状態を示すものであっても、２以上のエッジノード２０の輻輳状態を代表して示すものであっても良い。ＣＰＵ５１は、輻輳ありを示す輻輳情報に対応する１以上のＬＯＣをＬＯＣ応答から削除する。これによって、ＬＯＣの一部削除が行われる。一方、全ての輻輳情報が輻輳なしを示すときには、ＬＯＣの一部削除が実施されない。
【０１５６】
また、ＬＯＣ応答を管理サーバ４０から最初に受信するエッジノード２０（例えばエッジノード２７）が、ＬＯＣ応答中のＬＯＣリストにＬＯＣが格納されたエッジノード２０の全て（例えば、エッジノード２２，２７，２６，２５）の輻輳情報を収集し、輻輳ありの輻輳情報に対応するＬＯＣがＬＯＣ応答から削除されるようにしても良い。この場合、エッジノード２７より上位側に位置するエッジノード２６，２５にて、ＬＯＣの一部削除の判定の実施を省略することができる（但し、トンネル確立のために用いたＬＯＣの削除は除く）。
【０１５７】
（２）ホストの移動頻度
ホスト（例えば、図１のホスト３２）が頻繁に出口エッジノードを切り替える（アクセス網間を移動する）場合には、ＬＯＣ要求へのＬＯＣの追加回避や、ＬＯＣ応答からのＬＯＣ削除が実行されない制御が行われる。ホストの移動頻度は、公知の様々な手法を用いて入手することができる。例えば、最終エッジに該当する各エッジノード２２，２３，２４がpingメッセージを用いてホスト３２“ホストＩＰ２”の接続状態を監視し、その監視結果を集約して、移動頻度（例えば大／小）を示す情報を作成し、所定の管理サーバ４０やエッジノード２０に移動頻度情報をセットする（記憶装置５３，ＨＤＤ８３に保持）ことが考えられる。
【０１５８】
この場合、“ホストＩＰ２”の移動頻度情報“小”がセットされた管理サーバ４０は、ＬＯＣの追加回避を行い、“ホストＩＰ２”の移動頻度情報“大”がセットされた管理サーバ４０は、ＬＯＣの追加を行う。また、“ホストＩＰ２”の移動頻度情報“小”がセットされたエッジノード２０は、ＬＯＣの削除を行い、“ホストＩＰ２”の移動頻度情報“大”がセットされた管理サーバ４０は、ＬＯＣの削除を回避する。
これによって、移動頻度“大”のホストに関しては、多くのエッジノード２０を経由する転送経路が適用され、移動時におけるトンネルの切り替え短縮化が図られるようにする。これに対し、移動頻度“小”のホストに関しては、経由エッジノードの数を減らすことができる。
【０１５９】
（３）ＬＯＣ要求、ＬＯＣ応答に含まれるパラメータ
方法１−３、方法２−２に示したように、ＬＯＣ要求，ＬＯＣ応答は、宛先ホストＩＰアドレス，送信元ホストＩＰアドレス，プロトコルＩＤ，ポート番号のような複数のパラメータを含む選択用情報を有することができる。
【０１６０】
例えば、特定の宛先ホストＩＰに対しては、様々な事情（例えば移動頻度）を反映して、常時エッジノード２０のバイパスが行われない（ＬＯＣの追加回避や削除が行われない）設定（第１設定）、或いは逆の設定（常に一部のエッジノード２０をバイパスする設定：第２設定）を行うことができる。或いは、特定のパケットフロー（送信元ＩＰアドレス及び宛先ＩＰアドレスで特定される）に対して、上記第１設定と第２設定との何れを適用するかを決定することができる。
【０１６１】
また、短時間でのトンネル切り替えが要求されるアプリケーション（プロトコルＩＤやポート番号で特定される）については、第１設定が適用され、余裕を持ったトンネル切り替えが許容されるアプリケーションについては第２設定が適用されることを決定することができる。
【０１６２】
或いは、上記した複数のパラメータの組合せ（例えば、パケットフロー＋アプリケーション）によって、第１設定と第２設定との何れを適用するかを決定することもできる。第２設定においてバイパスされるエッジノード２０は適宜決定することができる。
【０１６３】
また、上記したようなＬＯＣ追加回避の判定及び処理は、管理サーバ４０のＣＰＵによって行われる。管理サーバ４０のＨＤＤ８３のような二次記憶装置は、ＬＯＣ追加回避の判定用の情報を保持することができる。ＬＯＣ削除の判定及び処理は、エッジノード２０のＣＰＵ５１によって行われる。ＬＯＣ削除の判定用情報は、記憶装置５３で保持しておくことができる。
【０１６４】
＜第３実施形態における管理サーバ、エッジノードの処理＞
以下、第３実施形態における管理サーバ４０及びエッジノード２０における処理例を示す。第３実施形態におけるネットワークシステム，管理サーバ４１〜４４及びエッジノー
ド２０（エッジノード２１〜２９）の構成は、第１実施形態と同様である（図１〜図９参照）。但し、第３実施形態では、上記した方法１−１〜２−２を考慮し、管理サーバ４１〜４４及びエッジノード２０（エッジノード２１〜２９）の夫々における処理が第１実施形態と異なる。
【０１６５】
図３１は、第３実施形態における管理サーバ４０（各管理サーバ４１〜４４）の処理例を示すフローチャートである。図３１に示すフローチャートにおいて、Ｓ２１〜Ｓ２３の処理は、第１実施形態における管理サーバ４０の処理（図１８）と同様であるので説明を省略する。
【０１６６】
Ｓ２３において、ホストＩＤ−ＬＯＣ管理テーブル９０から検索されたエントリ中の最終エッジ情報がＮｏ情報である場合には、処理がＳ１０１へ進む。Ｓ１０１では、管理サーバ４０は、検索されたエントリに含まれるＬＯＣリストのうち、パケット転送時にパケットが通過すべきエッジノード２０のＬＯＣのみを抽出する。抽出は、上記した判定基準に基づいて行われる。次のＳ２４では、抽出されたＬＯＣのみがＬＯＣ要求のＬＯＣリストに追加される。Ｓ１０１でＬＯＣが抽出されない場合もあり得る。この場合、Ｓ２４において、ＬＯＣの追加は行われない。その後のＳ２５〜Ｓ２７の処理は、第１実施形態と同様であるので説明を省略する。
【０１６７】
Ｓ２３において、ホストＩＤ−ＬＯＣ管理テーブル９０から検索されたエントリ中の最終エッジ情報がＹｅｓ情報である場合には、処理がＳ１０２へ進む。Ｓ１０２でも、Ｓ１０１と同様の処理が行われる。その後のＳ１０３において、管理サーバ４０は、Ｓ１０２で抽出されたＬＯＣと、ＬＯＣ要求のＬＯＣリストに含まれたＬＯＣとが格納されたＬＯＣ応答が作成される。そして、管理サーバ４０は、ＬＯＣ応答に格納されたＬＯＣリスト中の最後に位置するエッジノード２０又は最後から１つ前のエッジノード２０へＬＯＣ応答を送信する（Ｓ１０４）。
【０１６８】
図３２は、ＬＯＣ応答を受信したエッジノード２０における処理を示すフローチャートである。図３２の処理において、Ｓ３１〜Ｓ３５，Ｓ３６の処理は、第１実施形態（図１９）と同様であるので説明を省略する。
【０１６９】
これに対し、Ｓ３５にて、ＬＯＣ応答を受信したエッジノード２０がホストからのパケットを受信したエッジノード２０でない場合には、処理がＳ１０５に進む。Ｓ１０５では、第１実施形態と同様に、ＬＯＣ応答中のＬＯＣリストから、最後に位置するＬＯＣが削除される。Ｓ１０５では、エッジノード２０は、上述した判定基準に従って、ＬＯＣ応答中のＬＯＣリストから、パケット転送経路が通過を要しない（バイパスすべき）エッジノード２０のＬＯＣを抽出し、抽出したＬＯＣをＬＯＣ応答から除去する。但し、判定基準に照らして抽出すべきＬＯＣがない場合には、ＬＯＣの除去は行われない。
【０１７０】
その後、Ｓ１０６において、エッジノード２０は、ＬＯＣ応答中のＬＯＣリストにおいて最後から１つ前に格納されたＬＯＣを有するエッジノード２０へＬＯＣ応答を送信する。
【０１７１】
＜動作例＞
以下、第３実施形態における動作例について説明する。
（動作例１）
動作例１として、第１実施形態の動作例１と同様に、ホスト３１とホスト３２とが通信を開始する場合を仮定する。但し、ホスト３２（ホストＩＰ２）へのパケット転送に関して、ホスト移動時の効率的なトンネル切り替え処理の優先が要求されない環境下であると仮定する。そして、管理サーバ４３に対して、ホストＩＤ−ＬＯＣ管理テーブル９０に格
納されたＬＯＣ（ＬＯＣ６）をＬＯＣ要求に追加しない判定を行うための情報が静的に又は動的に管理サーバ４３に対して設定されていると仮定する。
【０１７２】
この場合、フェーズ５（フェーズ１〜４は第１実施形態と同じ）において、管理サーバ４３は、管理サーバ４３が管理するエッジノード２０のＬＯＣであるＬＯＣ６をＬＯＣ要求中のＬＯＣリストに追加することなく、次の管理サーバ４４へ送信する。
【０１７３】
フェーズ６において、ＬＯＣ要求を受信した管理サーバ４４は、第１実施形態と同様の処理を行い、エッジノード２７へＬＯＣ応答を送信する。この場合、ＬＯＣ応答のＬＯＣリストは、ＬＯＣ５，ＬＯＣ７，ＬＯＣ２を含む状態となる。
【０１７４】
フェーズ７では、エッジノード２７は、ＬＯＣ応答中のＬＯＣ２を用いてエッジノード
２２とのトンネルを確立し、ＬＯＣ応答からＬＯＣ２を削除した後に、エッジノード２
６ではなくエッジノード２５へＬＯＣ応答を送信する。従って、フェーズ８がスキップされて、フェーズ９が実施される。これによって、エッジノード２５は、エッジノード２６がバイパスされるトンネルをエッジノード２７との間で確立する。フェーズ９及び１０は、第１実施形態と同様である。このようにして、エッジノード２６がバイパスされた複数段トンネルを構築することができる。
【０１７５】
（動作例２）
動作例２として、第１実施形態の動作例１と同様に、ホスト３１とホスト３２とが通信を開始する場合を仮定する。但し、ホスト３２（ホストＩＰ２）へのパケット転送に関して、ホスト移動時の効率的なトンネル切り替え処理の優先が要求されない環境下であると仮定する。そして、エッジノード２７に対して、ＬＯＣ応答中のＬＯＣリストから所定のＬＯＣ（例えばＬＯＣ６）を除去する設定が静的に又は動的にエッジノード２７に対して設定されていると仮定する。
【０１７６】
この場合、第１実施形態におけるフェーズ１〜６が実施され、エッジノード２７がＬＯＣ応答を管理サーバ４４から受信する。フェーズ７において、エッジノード２７は、エッジノード２２とのトンネルを確立し、ＬＯＣ２をＬＯＣ応答から削除する。さらに、エッジノード２７は、上記した設定に従って、ＬＯＣ６をＬＯＣ応答から除去する。以降の動作は、第３実施形態の動作例１と同様である。最終的にエッジノード２６がバイパスされた複数段トンネルが確立され、ホスト３１からホスト３２へのパケット転送に使用される。
【０１７７】
第３実施形態によれば、第１実施形態における管理サーバ４０やエッジノード２０の少なくとも１つに対して、ＬＯＣ要求にＬＯＣを追加しない、又はＬＯＣ応答から所定のＬＯＣを削除するための情報を設定しておくことによって、所望のエッジノード２０がバイパスされたパケット転送経路（多段トンネル）を構築することができる。
【０１７８】
なお、上述した動作例１、２では、複数の管理サーバ４０及び複数のエッジノード２０の一箇所で、ＬＯＣの追加回避又はＬＯＣ除去が実施される例について説明したが、管理サーバ４０及びエッジノード２０の複数箇所において、ＬＯＣの追加回避又はＬＯＣ除去が実施されるようにしてもよい。実施箇所は適宜設定可能である。
【０１７９】
〔第４実施形態〕
次に、本発明の第４実施形態について説明する。第４実施形態は、第１〜３実施形態と共通点を有するので、主として相違点について説明し、共通点の詳細な説明は省略する。図３３は、第４実施形態に係るネットワークシステムである。図３３に示すように、第４実施形態では、第１実施形態のネットワークシステム（図１）と異なり、コア網１０に含
まれる複数のエッジノード２０（図３３ではエッジノード２１〜２９）がメッシュ状に接続されている。
【０１８０】
このようなシステムにおいて、ホスト３１とホスト３２が通信を行うに当たり、ホスト３１がホスト３２（ホストＩＰ２）向けのパケットをエッジノード２１へ送信すると、第１実施形態の動作例１と同様の動作乃至処理が行われ、入口エッジノード２１と出口エッジノード２２との間に、エッジノード２５，２６及び２７を経由する多段トンネルを確立することができる。
【０１８１】
第４実施形態によれば、少なくとも第１実施形態の動作例１と同様に、コア網１０にホスト間を結ぶ多段トンネル（複数のトンネル）を確立する場合における各エッジノード２０及び各管理サーバ４０の処理負荷を軽減することができる。また、多段トンネルの確立に要する時間を短縮化することが期待できる。第４実施形態の構成と、第２、３実施形態で説明した構成とは適宜組み合わせることができる。
【符号の説明】
【０１８２】
２０，２１〜２７・・・エッジノード（中継装置）
３１〜３３・・・ホスト（端末装置）
４０，４１〜４４・・・管理サーバ（管理装置）
【技術分野】
【０００１】
本発明は、ネットワークシステムに関する。
【背景技術】
【０００２】
インターネットバックボーンにおけるルータの経路数を削減する技術として、ID-Locator分離技術が検討されている。その代表的な例がIETF（The Internet Engineering Task Force）で標準化検討中のＬＩＳＰ（Locator ID Separation Protocol）である。図３４ は、ＬＩＳＰの概要を説明する図である。
【０００３】
ＬＩＳＰは、コア網１と、コア網１に接続される１以上のアクセス網（図３４ではアクセス網２、３を例示）とを備える。コア網１は、アクセス網からのアクセス回線を収容する、エッジノードと呼ばれるルータを備える。図３４の例では、アクセス網２におけるホスト４（ＩＤ＃１）からのアクセス回線を収容するエッジノード５（ＬＯＣ１）と、アクセス網３におけるホスト６（ＩＤ＃２）からのアクセス回線を収容するエッジノード７（ＬＯＣ２）とが例示されている。“ＩＤ”は、アクセス網で使用されるアドレス（ＩＰアドレス）を示し、“ＬＯＣ（Locator：Location address）”は、コア網におけるエッジ
ノードのアドレス（ＩＰアドレス）を示す。
【０００４】
ＬＩＳＰでは、アクセス網のアドレスと、コア網のアドレスとが分離して管理される。このため、ＬＩＳＰでは、アクセス網のアドレスとコア網のアドレスとの対応関係を管理する１以上の管理サーバが設けられる。図３４では、エッジノード５に対応する管理サーバ８と、エッジノード７に対応する管理サーバ９とが設けられている。エッジノード５は、ホスト４のＩＤ（ＩＤ＃１）とエッジノード５のＬＯＣ（ＬＯＣ１）との対応関係を管理サーバ８に登録し（図３４の＜１＞）、エッジノード７は、ホスト６のＩＤ（ＩＤ＃２）とエッジノード７のＬＯＣ（ＬＯＣ２）との対応関係を管理サーバ９に登録している。
【０００５】
ＬＩＳＰの動作を、図３４を用いて説明する。例えば、ホスト４がホスト６へデータを送信する場合の動作を例示する。ホスト４は、データにホスト６のアドレス（ホストＩＤ：ＩＤ＃２）を含むヘッダが付与されたパケットをエッジノード５へ送信する。ホスト４からのパケットを受信したエッジノード５は、当該パケットの宛先のホストを収容するエッジノード（エッジノード７）とのトンネル構築を試行する。
【０００６】
このとき、エッジノード５は、宛先であるホスト６を収容するエッジノード７のアドレス（ＬＯＣ）を知らない場合には、対応する管理サーバ８に対して、宛先のコア網アドレス（ＬＯＣ）を問い合わせるメッセージ（ＬＯＣ要求）を送信する（図３４の＜３＞）。ＬＯＣ要求を受信した管理サーバ８は、ＬＯＣ要求に含まれる宛先アドレス（ＩＤ＃２）に対応するＬＯＣを管理している管理サーバ９へＬＯＣ要求を転送する（図３４の＜４＞）。ＬＯＣ要求は、直接に、又は図３４に示すような中継装置（例えばルータ）を介して制御プレーン（Ｃプレーン）上を転送され、管理サーバ９に到達する。ＬＯＣ要求を受信した管理サーバ９は、管理サーバ９が管理している、宛先ホストＩＤ（ＩＤ＃２）に対応するエッジノードのアドレス（ＬＯＣ２）を含むメッセージ（ＬＯＣ応答）を、ＬＯＣ要求の送信元であるエッジノード５へ送信する（図３４の＜５＞）。ＬＯＣ応答を受信したエッジノード５は、エッジノード７との間でＩＰトンネルを確立する。続いて、エッジノード５は、ホスト４からのパケット（ユーザＩＰパケット）に宛先エッジノードアドレス（エッジノード７のアドレス（ＬＯＣ２））を含むヘッダを付与することによってカプセル化パケット（ＬＩＳＰパケット）を生成する。ＬＩＳＰパケットはＩＰトンネルへ送出され、エッジノード７に到達する。エッジノード７は、ＬＩＳＰパケットからのヘッダの
除去（デカプセル化）を行い、得られたユーザＩＰパケットをホスト６へ転送する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１６６０８９号公報
【非特許文献】
【０００８】
【非特許文献１】Locator/ID Separation Protocol(LISP) draft-ietf-lisp-10, D. Farinacci, V. Fuller, D. Meyer, D. Lewis, cisco Systems, March 4, 2011
【非特許文献２】LISP-DHT: Towards a DHT to map identifiers onto locators, draft-mathy-lisp-dht-00, L. Mathy, Lancaster U, L. Iannone, O. Bonaventure, UCLouvain, February 25, 2008
【非特許文献３】Hierarchical Mobile IPv6 Mobility Management (HMIPv6), H. Soliman, Flarion, C. Castelluccia, INRIA, K. El Malki, Ericsson, L. Bellier, INRIA, August 2005
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ＬＩＳＰは、動的にトンネルを確立する、という第１の特徴と、ホストから送信されたパケットは変更されることなくトンネル上に転送される、という第２の特徴を有する。これらの特徴を生かしたホストの移動に対応する動作がIETF LISP WG(Working group)で検
討されている。
【００１０】
ホストの移動に伴って、コア網の出口（egress）側のエッジノード（例えば、図３４に示したエッジノード７）の変更が生じた場合には、新たな出口エッジノードと、他のエッジノード（例えば、入口エッジノード）との間でトンネルの再構築（ＬＯＣ変更）が発生する。このようなＬＯＣ変更に係る遅延や、コア網内で生じる処理負荷は、できる限り小さくすることが好ましい。また、ＬＯＣ変更に係る遅延や処理負荷の低減を図るために、複数のエッジノード間を結ぶ多段（複数段）トンネルが一括で確立可能な技術が求められる。
【００１１】
本発明の一態様は、複数の中継装置間を結ぶ複数のトンネルを効率的に確立可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の一態様は、パケットを受信する第１中継装置と、前記パケットの宛先アドレスを有する端末と接続された第２中継装置とを含む複数の中継装置と、
前記第１中継装置を管理する第１管理装置と、前記第２中継装置を管理する第２管理装置とを含む、前記複数の中継装置を管理する複数の管理装置とを備え、
前記第１中継装置は、前記パケットの転送に用いる中継装置アドレスを解決するための、前記宛先アドレスを含む要求メッセージを前記第１管理装置へ送信し、
前記複数の管理装置は、前記要求メッセージが前記第１管理装置から前記第２管理装置へ到達するように、前記宛先アドレスに対応する転送情報に基づいて前記要求メッセージを転送するとともに、前記第１中継装置から前記第２中継装置へ到達する前記パケットが通過すべき１以上の中継装置の中継装置アドレスを前記要求メッセージに格納し、
前記第２管理装置は、前記要求メッセージに格納された複数の中継装置アドレスと、前記第２中継装置の中継装置アドレスを含む１以上の中継装置アドレスとが格納された応答メッセージを生成し、
前記応答メッセージに中継装置アドレスが格納された前記第２中継装置を除く中継装置の夫々は、前記応答メッセージを受信し、前記応答メッセージに格納された中継装置アド
レスを用いて、中継装置間の前記パケットの転送に使用されるトンネルを確立するとともに、少なくともトンネルの確立に用いた中継装置アドレスを前記応答メッセージから削除し、前記応答メッセージに残った１以上の中継装置アドレスの何れかへ前記応答メッセージを転送し、
前記応答メッセージを受信する前記第１中継装置は、前記応答メッセージに格納された中継装置アドレスを用いて自装置より１つ前に位置する中継装置との間でトンネルを確立し、
前記パケットは、前記第１中継装置、及び前記パケットが通過する中継装置の夫々からトンネルへ送出されるときに、宛先中継装置アドレスを含むヘッダを用いてカプセル化されるネットワークシステムである。
他の態様は、上記ネットワークシステムに係る管理装置、中継装置を含み得る。また、他の態様は、ネットワークシステム、管理装置、中継装置に係る方法や、管理装置や中継装置で実行されるプログラム、又はプログラムを記録した記録媒体を含み得る。
【発明の効果】
【００１３】
本発明の一態様によれば、中継装置間を結ぶ複数のトンネルを効率的に確立することができる。
【図面の簡単な説明】
【００１４】
【図１】図１は、本発明の第１実施形態に係るＬＩＳＰネットワーク（ネットワークシステム）の構成例を示す。
【図２】図２は、図１に示したエッジノードとして適用可能なエッジノードのハードウェア構成例を示す。
【図３】図３は、図２に示したハードウェア構成を有するエッジノードによって実現される機能構成例を示す。
【図４】図４は、経路テーブルのデータ構造例を示す。
【図５】図５は、トンネル管理テーブルのデータ構造例を示す。
【図６】図６は、図１に示した各管理サーバとして適用される管理サーバのハードウェア構成例を示す。
【図７】図７は、図６に示した管理サーバのハードウェア構成によって実現される機能構成例を示す。
【図８】図８は、ＬＯＣ管理サーバ情報テーブルのデータ構造例を示す。
【図９】図９は、ホストＩＤ−ＬＯＣ管理テーブルのデータ構造例を示す。
【図１０】図１０は、図１に示したネットワークシステムの動作例の説明図である。
【図１１】図１１は、管理サーバ４１が保持するＬＯＣ管理サーバ情報テーブルの登録内容例を示す。
【図１２】図１２は、管理サーバ４２が保持するＬＯＣ管理サーバテーブルの登録内容例を示す。
【図１３】図１３は、管理サーバ４３が保持するＬＯＣ管理サーバテーブルの登録内容例を示す。
【図１４】図１４は、管理サーバ４２が保持するホストＩＤ−ＬＯＣ管理テーブルの登録内容例を示す。
【図１５】図１５は、管理サーバ４３が保持するホストＩＤ−ＬＯＣ管理テーブルの登録内容例を示す。
【図１６】図１６は、管理サーバ４４が保持するホストＩＤ−ＬＯＣ管理テーブルの登録内容例を示す。
【図１７】図１７は、データパケットを受信したエッジノードの処理例を示すフローチャートである。
【図１８】図１８は、ＬＯＣ要求を受信した管理サーバで実行される処理例を示すフローチャートである。
【図１９】図１９は、ＬＯＣ応答を受信したエッジノードで実行される処理例を示すフローチャートである。
【図２０】図２０は、エッジノード２７のトンネル管理テーブル６７に登録されるエントリを示す。
【図２１】図２１は、エッジノード２１，２５，２６，２７の経路テーブルに登録されるエントリを示す。
【図２２】図２２は、エッジノード２６のトンネル管理テーブル６７に登録されるエントリを示す。
【図２３】図２３は、エッジノード２５のトンネル管理テーブル６７に登録されるエントリを示す。
【図２４】図２４は、エッジノード２１のトンネル管理テーブル６７に登録されるエントリを示す。
【図２５】図２５は、エッジノード２７の経路テーブル６６に登録されたエントリを示す。
【図２６】図２６は、エッジノード２７のトンネル管理テーブル６７に登録されたエントリを示す。
【図２７】図２７は、エッジノード２１，２５，２６が夫々有する経路テーブル６６のエントリを示す。
【図２８】図２８は、第１実施形態の参考図である。
【図２９】図２９は、第１実施形態の変形例２において管理サーバ４２が保持するＬＯＣ管理サーバ情報テーブルを示す。
【図３０】図３０は、第１実施形態の変形例２において管理サーバ４２が保持するホストＩＤ−ＬＯＣ管理テーブルを示す。
【図３１】図３１は、第３実施形態における各管理サーバの処理例を示すフローチャートである。
【図３２】図３２は、第３実施形態におけるエッジノードの処理例を示すフローチャートである。
【図３３】図３３は、第４実施形態におけるネットワークシステムの例を示す。
【図３４】図３４は、ＬＩＳＰの説明図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
〔第１実施形態〕
＜ネットワーク構成＞
図１は、本発明の第１実施形態に係るＬＩＳＰネットワーク（ネットワークシステム）の構成例を示す。ＬＩＳＰネットワークは、ＩＰパケットをトンネリング（カプセリング）するネットワークの一例である。ＬＩＳＰでは、コア網１０においてパケットを転送するためのトンネルが動的に確立される。
【００１６】
図１に例示するネットワークシステムは、コア網１０と、コア網１０に収容される複数のアクセス網１１，１２，１３，１４を備えている。コア網１０は、複数のエッジノードとして機能する複数のルータを備えている。図１には、エッジノード２１〜２９が例示されている。エッジノードは中継装置の一例である。エッジノード２１〜２９は、夫々、コア網１０で使用されるエッジノードアドレス（ＩＰアドレス）である、ＬＯＣ１〜ＬＯＣ９を有している。エッジノード２１〜２７は、複数の中継装置の一例である。
【００１７】
エッジノード２１は、アクセス網１１に属するホスト３１のアクセス回線を収容している。エッジノード２１は、第１中継装置及び始点中継装置の一例である。エッジノード２２は、アクセス網１２に属するホスト３２のアクセス回線を収容している。エッジノード
２２は、第２中継装置及び終点中継装置の一例である。エッジノード２３は、アクセス網１３に属するホスト３３のアクセス回線を収容している。エッジノード２３は、第３中継装置の一例である。エッジノード２７は、第４中継装置の一例である。エッジノード２５〜２７は、１以上の中間中継装置の一例である。
【００１８】
ホスト３１〜３３の夫々は、アクセス網で使用されるＩＰアドレスである、ＩＤ＃１(
ホストＩＰ１)，ＩＤ＃２（ホストＩＰ２），ＩＤ＃３（ホストＩＰ３）を夫々有してい
る。ホスト３１〜３３は、例えば、パーソナルコンピュータ（ＰＣ），ＰＤＡ（Personal
Digital Assistant），スマートフォン，セルラーフォンのような、固定端末又は移動端末を含むことができる。アクセス回線は、有線であっても無線であっても良い。各ホスト３１〜３３は、端末の一例である。
【００１９】
また、コア網１０のエッジノード２５は、エッジノード２１に物理回線を介して接続される一方で、エッジノード２６，２８と物理回線を介して夫々接続されている。エッジノード２６は、エッジノード２７，２９と物理回線を介して夫々接続されている。エッジノード２７は、エッジノード２２，２３，２４と物理回線を介して夫々接続されている。エッジノード２８，２９の夫々は、図示しないコア網１０内の他のエッジノードと物理回線を介して接続されている。このように、図１に示す例では、エッジノード２１が入口エッジノードであり、エッジノード２５がルートであるツリー構造のトポロジが複数のエッジノード２５〜２９で形成されている。
【００２０】
また、コア網１０の制御プレーン（Ｃプレーン）上には、ＬＯＣ（エッジノードの位置識別情報）とＩＤ（ホストのＩＤ）との対応関係が登録される１以上の管理サーバが配置される。図１に示す例では、管理サーバ４１〜４４が配置されている。管理サーバ４１は、エッジノード２１を管理し、エッジノード２１のＬＯＣとエッジノード２１が収容する１以上のホスト（例えばホスト３１）のＩＤとの対応関係を保持する。
【００２１】
また、管理サーバ４４は、エッジノード２２のＬＯＣとエッジノード２２に収容されるホスト（例えばホスト３２）のＩＤとの対応関係と、及びエッジノード２３のＬＯＣとエッジノード２３に収容されるホスト（例えばホスト３３）のＩＤとの対応関係と、エッジノード２７のＬＯＣとエッジノード２７に収容されるホストのＩＤとの対応関係を保持することができる。管理サーバ４２，４３は、夫々、エッジノード２５，２６のＬＯＣとエッジノード２５，２６に収容される各ホストのＩＤとの対応関係を保持することができる。管理サーバ４１〜４４は、複数の管理装置の一例であり、管理サーバ４１は第１管理装置の一例であり、管理サーバ４４は、第２管理装置の一例である。
【００２２】
管理サーバ４１〜４４は、Ｃプレーンの制御パケットが転送されるネットワークを介して接続されている。また、各管理サーバ４１〜４４は、管理サーバ自身の管理下にあるエッジノードと通信回線を介して接続されており、エッジノードの間で制御パケットを送受信することができる。
【００２３】
＜エッジノードの構成＞
図２は、図１に示したエッジノード２１〜２９として適用可能なエッジノード２０のハードウェア構成例を示す。以下の説明において、エッジノード２１〜２９を区別することなく説明する場合には、エッジノード２０との表記を用いることもある。図２において、エッジノード２０は、バスＢを介して相互に接続されたＣＰＵ（Central Processing Unit）５１，スイッチカード５２，記憶装置５３と、１以上のインタフェースカード５４（
図２では、複数のインタフェースカードを例示）とを備える。インタフェースカード５４は、送受信装置の一例である。ＣＰＵ５１は、制御装置の一例である。
【００２４】
各インタフェースカード５４は、エッジノード２０のパケットの送受信処理を司る。スイッチカード５４は、パケットの転送処理、すなわち、各インタフェースカード５４で受信されたパケットをバスＢを介して受け取り、パケットの目的地に対応するインタフェースカードへパケットをバスＢを介して転送する処理を司る。ＣＰＵ５１は、エッジノード２０全体の動作を制御する。記憶装置５２は、ＣＰＵ５１がエッジノード２０の動作制御のために実行するプログラムや、プログラムの実行に際して使用されるデータを格納する。
【００２５】
記憶装置（ストレージ）５３は、ＲＡＭ（Random Access Memory）のようなＣＰＵ５１の作業領域として使用されるメモリ（記録媒体）と、ＣＰＵ５１によって実行されるプログラム，エッジノード２０の動作を規定する各種設定に係るデータを記録する不揮発性記録媒体とを含む。不揮発性記録媒体として、ＲＯＭ（Read Only Memory），ＥＥＰＲＯＭ，フラッシュメモリ，ＨＤＤ（Hard Disk Drive）を例示することができる。
【００２６】
スイッチカード５２は、各インタフェースカード５４との内部通信に使用される受信機及び送信機として機能する電気・電子回路を備える。また、スイッチカード５２は、インタフェースカード５４から受信されたパケットを一時的に保持する（バッファとして使用される）記憶デバイスを含む。また、スイッチカード５２は、転送処理に必要な情報を格納したテーブルを保持する記憶デバイスを含む。記憶デバイスは、用途に応じて、ＲＡＭ，ＲＯＭ，ＥＥＰＲＯＭ，フラッシュメモリ，ハードディスクのような様々な不揮発性又は揮発性記録媒体の中から１以上が選択されて搭載される。
【００２７】
さらに、スイッチカード５２は、テーブルに保持された情報に基づいてパケットの転送処理を行う。パケットの転送処理は、受信されたパケットの出力経路の決定、パケットのカプセル化，デカプセル化を含む。パケットの転送処理は、スイッチカード５２に搭載された電気・電子回路に含まれる１以上の半導体集積回路（ＩＣ（integrated circuit）、ＬＳＩ(Large Scale Integration)、ＡＳＩＣ(Application Specific Integrated Circuit)）を用いたハードウェア処理（転送処理回路による処理）、スイッチカード５２搭載のプロセッサ（例えば、ＣＰＵ，ＤＳＰ（Digital Signal Processor），ＦＰＧＡ(Field-Programmable Gate Array)）がプログラムを実行することによって実現されるソフトウェ
ア処理（プロセッサによる処理）、或いは上記したハードウェア処理とソフトウェア処理との組合せの何れかによって実現されることができる。
【００２８】
ＣＰＵ５１は、記憶装置５３に保持されたプログラムを実行することによって、エッジノード全体の動作を管理する。例えば、ＣＰＵ５１は、管理サーバから受信される情報を元に、スイッチカード５２が備えるテーブルの書き換えを行う。ＣＰＵ５１は、プロセッサ（マイクロプロセッサ）の一例である。プロセッサは、ＤＳＰやＦＰＧＡを含むことができる。
【００２９】
図３は、図２に示したハードウェア構成を有するエッジノード２０によって実現される機能構成例を示す。図３において、エッジノード２０は、パケット受信部６１と、パケット転送部６２と、パケット送信部６３と、デカプセル部６４と、カプセル部６５とを備える。
【００３０】
また、エッジノード２０は、経路テーブル（ルーティングテーブル）６６と、トンネル管理テーブル６７と、ＬＯＣ要求生成部６８と、ＬＯＣ要求送信部６９とを備える。さらに、エッジノード２０は、ＬＯＣ応答送信部７０と、トンネル生成部７１と、ＬＯＣ応答受信部７２とを備える。
【００３１】
パケット受信部６１は、ネットワークからパケット（データパケット）を受信する。パ
ケット送信部６３は、パケット（データパケット）をネットワークへ送信する。パケッ
ト受信部６１及びパケット送信部６３の機能は、インタフェースカード５４によって実現される。
【００３２】
デカプセル部６４は、パケット受信部６１で受信されたパケットがカプセル化されている（ＬＩＳＰパケットである）場合に、カプセル化パケットに付与されているヘッダ（ＬＩＳＰヘッダ）を除去する。
【００３３】
カプセル部６５は、パケット転送部６２からカプセル化すべきパケット（トンネルへ送信すべきパケット）を受け取る。カプセル部６５は、トンネルの受信側端点に位置するエッジノードのアドレス（ＬＯＣ）が宛先アドレスとして設定されたヘッダ（ＬＩＳＰヘッダ）をパケットの先頭に付与する（カプセル化）。
【００３４】
パケット転送部６２は、パケット受信部６１又はデカプセル部６４からのパケットを受け取る。パケット転送部６２は、経路テーブル６６を参照し、パケットの宛先ＩＰアドレスに対応する経路（出力ポート）を決定する。パケット転送部６２は、経路テーブル６６を参照して得られた経路がトンネルである場合には、トンネル管理テーブル６７を参照し、トンネルの他方端点のエッジノードアドレスを取得する。パケット転送部６２は、経路テーブル６６を参照した結果、宛先アドレスに対応する出力経路が登録されたエントリが存在しない（ヒットしない）場合に、ＬＯＣ要求生成部６８に対し、トンネル転送を行うか否かを問い合わせる。
【００３５】
経路テーブル６６は、宛先アドレスに対応する転送先を含む１以上のエントリが登録されたテーブルである。図４は、経路テーブル６６のデータ構造例を示す。図４に示すように、テーブル６６は、宛先アドレス（宛先ＩＰアドレス）に対応する転送先のエントリを保持する。転送先を示す情報として、次ホップのルータを示す情報、或いは、トンネル番号が登録される。
【００３６】
トンネル管理テーブル６７は、エッジノード間を結ぶトンネル構築のために要求される情報を保持する。すなわち、トンネル管理テーブル６７には、エッジノード間に構築されるトンネルの一方の端点が自エッジノードに位置するとの仮定において、当該トンネルの他方の端点が位置するエッジノードのアドレス（ＬＯＣ）が登録される。図５は、トンネル管理テーブル６７のデータ構造例を示す。図５に示すように、トンネル管理テーブル６７には、トンネル識別情報（トンネル番号）と、トンネルの他端に位置するエッジノードのＩＰアドレス（ＬＯＣ）とを含む１以上のエントリが登録される。
【００３７】
上述したデカプセル部６４，パケット転送部６２，カプセル部６５，経路テーブル６６，及びトンネル管理テーブル６７は、スイッチカード５２によって実現される。ＬＯＣ要求生成部６８は、パケット転送部６２からの問い合わせに基づいて、パケットの宛先アドレスに対応するエッジノードアドレスの解決のためにＬＯＣ要求処理を行う。すなわち、ＬＯＣ要求生成部６８は、宛先アドレスに対応するエッジノードアドレスを要求するＬＯＣ要求メッセージ（以下、単に「ＬＯＣ要求」と表記することもある）を生成する。生成されるＬＯＣ要求には、宛先アドレスとＬＯＣ要求の生成元（送信元）を示すエッジノードアドレス（以下、「ＬＯＣ要求元アドレス」と称する）とが格納される。通常、ＬＯＣ要求は、入口エッジノードによって生成される。ＬＯＣ要求生成部６８は、スイッチカード５２から問い合わせの信号をバスＢを介して受け取ったＣＰＵ５１によって実現される。
【００３８】
ＬＯＣ要求送信部６９は、自エッジノードを管理している管理サーバに対し、ＬＯＣ要求を送信する。例えば、エッジノード２０がエッジノード２１（図１）であれば、管理サ
ーバ４１へＬＯＣ要求が送信される。ＬＯＣ要求送信部６９は、ＣＰＵ５１で生成されたＬＯＣ要求をバスＢを介して受け取るインタフェースカード５４によって実現される。ＬＯＣ応答受信部７２は、自エッジノードを管理している管理サーバ（例えば、エッジノード２１に対する管理サーバ４１）、或いは、他のエッジノード（“下位階層”のエッジノード）から送信されたＬＯＣ応答メッセージ（以下、単に「ＬＯＣ応答」と表記することもある）を受信する。“下位階層”とは、図１に示した複数のエッジノードが形成するツリー型のトポロジにおいて、自エッジノードからみてルート側を“上位階層”と定義し、リーフ側を“下位階層”と定義したときの“下位階層”を示す。ＬＯＣ応答受信部７２は、インタフェースカード５４によって実現される。
【００３９】
トンネル生成部７１は、受信したＬＯＣ応答に格納されているＬＯＣリストに含まれたＬＯＣ（エッジノードアドレス）を用いて下位階層のエッジノードとのトンネルを確立する。トンネルの確立は、トンネル管理テーブル６７にトンネル番号と下位階層のエッジノードアドレスを登録することによって行われる。
【００４０】
また、トンネル生成部７１は、ＬＯＣ応答のＬＯＣリストから下位階層のエッジノードアドレスを取り除き、上位階層のエッジノードへ転送すべきＬＯＣ応答を作成する。宛先アドレス、送信元アドレス、プロトコルＩＤ、ポート番号をベースに、どの階層の上位エッジノードへ転送するかを決定し、下位階層のエッジノードアドレスに加え、バイパスするレイヤのエッジノードのアドレスをＬＯＣリストから削除する。トンネル生成部７１は、インタフェースカード５４で受信されたＬＯＣ応答をバスＢを介して受信したＣＰＵ５１によって実現される。
【００４１】
ＬＯＣ応答送信部７０は、他のエッジノード（上位階層のエッジノード）へＬＯＣ応答を送信する。ＬＯＣ応答送信部７０は、ＣＰＵ５１によって生成されたＬＯＣ応答をバスＢを介して受信するインタフェースカード５４によって実現される。
【００４２】
＜管理サーバの構成＞
図６は、図１に示した各管理サーバ４１〜４４として適用される管理サーバ４０のハードウェア構成例を示す。以下の説明において、管理サーバ４１〜４４を区別しない場合には、管理サーバ４０との表記を用いることもある。管理サーバ４０は、パーソナルコンピュータ（ＰＣ）のような汎用のコンピュータ、或いはサーバマシンのような専用のコンピュータを適用することができる。図６において、管理サーバ４０は、バスＢ１を介して相互に接続されたＣＰＵ８１，ＲＡＭ８２，ＨＤＤ８３，及びネットワークインタフェース（インタフェース（ＩＦ）回路、ＩＦ装置）８４を備える。
【００４３】
ＲＡＭ８２は、管理サーバ４０（ＣＰＵ８１）の主記憶装置の一例である。ＲＡＭ８２は、ＣＰＵ８１の作業領域であり、オペレーティングシステム（ＯＳ）やアプリケーションプログラムのような各種のプログラムの実行に際して使用されるデータを一時的に格納する。
【００４４】
ＨＤＤ８３は、管理サーバ４０（ＣＰＵ８１）の二次記憶装置の一例である。ＨＤＤは、ＣＰＵ８１によって実行されるＯＳやアプリケーションプログラムのような各種のプログラムや、各プログラムの実行のために使用されるデータを保持する。データは、ＨＤＤ８３によって保持されるテーブル又はデータベース上に格納されることができる。
【００４５】
ＣＰＵ８１は、プロセッサ（マイクロプロセッサ）の一例であり、ＨＤＤ８３に格納された各種のプログラムをＲＡＭ８２にロードして実行する。これによって、ＣＰＵ８１は、管理サーバ４０全体を管理する。例えば、ＣＰＵ８１は、エッジノード２０からネットワークインタフェース８４を介して受信される制御パケット（例えば、ＬＯＣ要求）に対
する処理を行う。
【００４６】
ネットワークインタフェース８４は、少なくともエッジノード及び他の管理サーバとの通信回線を収容し、外部ネットワークとの接続処理（パケットの送受信処理）を行う。図７は、図６に示した管理サーバ４０のハードウェア構成によって実現される機能構成例を示す。図７に示すように、管理サーバ４０は、ＬＯＣ要求受信部８５と、ＬＯＣ要求処理部８６と、ＬＯＣ要求送信部８７と、ＬＯＣ応答送信部８８と、ＬＯＣ管理サーバ情報テーブル８９と、ホストＩＤ−ＬＯＣ管理テーブル９０とを備えた装置として機能する。ＬＯＣ要求受信部８５は、エッジノード２０、あるいは、上位階層の管理サーバが送信したＬＯＣ要求を受信する。ＬＯＣ要求受信部８５は、ネットワークインタフェース８４によって実現される。管理サーバ４０の階層関係においても、入口エッジノードのＬＯＣを管理する管理サーバを最上位層として、リーフ側に位置する管理サーバが下位階層と定義されている。すなわち、エッジノードの階層関係に準じた階層関係が設定されている。
【００４７】
ＬＯＣ要求送信部８７は、下位階層の管理サーバへＬＯＣ要求を送信する。ＬＯＣ要求送信部８７は、ネットワークインタフェース８４によって実現される。ＬＯＣ応答送信部８８は、上位階層のエッジノードへＬＯＣ応答を送信する。ＬＯＣ応答送信部８８は、ネットワークインタフェース８４によって実現される。
【００４８】
ＬＯＣ要求処理部８６は、ＬＯＣ要求受信部８５で受信されたＬＯＣ要求に格納されている宛先アドレスに対応するエッジノード、又はエッジノードのリストをホストＩＤ−ＬＯＣ管理テーブル９０を参照して特定する。
【００４９】
また、ＬＯＣ要求処理部８６は、特定したエッジノード又はエッジノードのリストに最下位階層のエッジノードが含まれていない場合には、特定したエッジノード又はエッジノードリストを、受信したＬＯＣ要求に追加し、ＬＯＣ要求をＬＯＣ要求送信部へ送る。これに対し、最下位層のエッジノードが含まれている場合には、ＬＯＣ要求処理部８６は、受信したＬＯＣ要求に格納されていたＬＯＣリストと特定したエッジノード又はエッジノードのリストを合わせた（マージした）ＬＯＣリストを含むＬＯＣ応答を生成する。さらにＬＯＣ応答にはＬＯＣ要求元アドレスが格納される。ＬＯＣ要求処理部８６は、エッジノード２０への転送のために、ＬＯＣ応答をＬＯＣ応答送信部８８へ送る。
【００５０】
また、ＬＯＣ要求処理部８６は、上記したＬＯＣ要求、ＬＯＣ応答を生成する際に、エッジノードの宛先アドレス、送信元アドレス、プロトコルＩＤ、ポート番号をベースに、ＬＯＣ要求又はＬＯＣ応答が経由すべきエッジノードを決定し、決定されたエッジノードのリストをＬＯＣリストに格納する。ＬＯＣ要求処理部８６は、ネットワークインタフェース８４で受信されたＬＯＣ要求をバスＢ１を介して受け取ったＣＰＵ８１によって実現される。ＣＰＵ８１は、ＬＯＣ要求処理によって生成したＬＯＣ要求、ＬＯＣ応答を、バスＢ１を介してネットワークインタフェース８４へ送る。
【００５１】
ＬＯＣ管理サーバ情報テーブル８９は、ホストの宛先ＩＰアドレスに対応する、ＬＯＣ要求を転送すべき下位階層の管理サーバ４０の識別情報（ＩＰアドレス）が登録される。図８は、ＬＯＣ管理サーバ情報テーブル８９のデータ構造例を示す。図８に示すように、テーブル８９は、ホストの宛先ＩＰアドレスに対応する転送先の管理サーバ４０のＩＰアドレスを含む１以上のエントリが登録される。
【００５２】
ホストＩＤ−ＬＯＣ管理テーブル９０は、パケットが宛先ＩＰアドレスへ転送される際に経由するエッジノード２０のアドレスのリストと、リストが最下位階層（リーフ）のエッジノード（最終エッジ）を含んでいるか否かを示す情報を保持する。図９は、ホストＩＤ−ＬＯＣ管理テーブル９０のデータ構造例を示す。図９に示すように、ホストＩＤ−Ｌ
ＯＣ管理テーブル９０は、登録された１以上のエントリを含む。各エントリは、ホストの宛先ＩＰアドレス（ホストＩＤ）と、宛先ＩＰアドレスへ向けてコア網１０を転送されるパケットが経由する１以上のエッジノード２０のアドレスを含むアドレスリスト（“エッジノードリスト”、又は“ＬＯＣリスト”と呼ぶ）と、エッジノードリストに含まれたアドレスを有するエッジノードがツリーの最下位層（リーフ）に該当するエッジノード（最終エッジと呼ぶ）のアドレスを含んでいるか否かを示す情報（例えば、ＹＥＳ、ＮＯを示すフラグ）とを含む。
【００５３】
ＬＯＣ管理サーバ情報テーブル８９及びホストＩＤ−ＬＯＣ管理テーブル９０は、ＨＤＤ８３によって保持される。なお、ＬＯＣ管理サーバ情報テーブル８９に登録される情報とホストＩＤ−ＬＯＣ管理テーブル９０に登録される情報とは、１つのテーブルによって管理されるように変形することができる。
【００５４】
＜動作例１＞
次に、図１に示したネットワークシステムにおける動作例１について説明する。図１０は、動作例１の説明図であり、図１に示したネットワークシステムが図示されている。図１０に示すホスト３１（ＩＤ＃１）がホスト３２（ＩＤ＃２）へパケットを転送する動作を以下に説明する。
【００５５】
ホスト３１はエッジノード２１に接続されており、ホスト３２はエッジノード２に接続されている。ホスト３１に対してＩＰアドレス“ホストＩＰ１（ＩＤ＃１）”が割り当てられ、ホスト３２に対して“ホストＩＰ２（ＩＤ＃２）”が割り当てられている。エッジノード２２は、階層化されたエッジノードツリーのリーフに位置し、エッジノードツリーは、エッジノード２５をルート（最上位層）として、エッジノード２６を含む中間層（上位層）、エッジノード２７を含む中間層（下位層）、エッジノード２２，２３，２４を含む最下位層が形成されている。
【００５６】
各エッジノード２１〜２７には、ＩＰアドレス（エッジノードアドレス）である“ＬＯＣ１”，“ＬＯＣ２”，“ＬＯＣ３”，“ＬＯＣ４”，“ＬＯＣ５”，“ＬＯＣ６”，“ＬＯＣ７”が夫々割り当てられている。
【００５７】
各エッジノード２１〜２７は、管理サーバ４１〜４４によって管理されている。エッジノード２１〜２７と、管理サーバ４１〜４４は、次のような対応関係を有する。すなわち、エッジノード２１は管理サーバ４１によって管理されている。エッジノード５は管理サーバ４２によって管理されている。エッジノード２６は管理サーバ４３によって管理されている。エッジノード２７，２２，２３，２４は管理サーバ４４に管理されている。管理サーバ４４のように、管理サーバ４０は、単一のエッジノードだけでなく、エッジノードツリー上の同一階層に位置する複数のエッジノードを管理したり、複数の階層（異なる階層）に属する複数のエッジノードを管理したりすることができる。
【００５８】
図１１は、管理サーバ４１が保持するＬＯＣ管理サーバ情報テーブル８９の登録内容例を示す。管理サーバ４１のＬＯＣ管理サーバ情報テーブル８９は、ホスト３２のＩＰアドレス“ホストＩＰ２”に対応する管理サーバ４２のＩＰアドレスが格納されたエントリと、ホスト３３のＩＰアドレス“ホストＩＰ３”に対応する管理サーバ４２のＩＰアドレスが格納されたエントリとを保持する。
【００５９】
図１２は、管理サーバ４２が保持するＬＯＣ管理サーバテーブル８９の登録内容例を示す。管理サーバ４２のＬＯＣ管理サーバ情報テーブル８９は、ホスト３２のＩＰアドレス“ホストＩＰ２”に対応する管理サーバ４３のＩＰアドレスが格納されたエントリと、ホスト３３のＩＰアドレス“ホストＩＰ３”に対応する管理サーバ４３のＩＰアドレスが格
納されたエントリとを保持する。
【００６０】
図１３は、管理サーバ４３が保持するＬＯＣ管理サーバテーブル８９の登録内容例を示
す。管理サーバ４３のＬＯＣ管理サーバ情報テーブル８９は、ホスト３２のＩＰアドレ
ス“ホストＩＰ２”に対応する管理サーバ４４のＩＰアドレスが格納されたエントリと、ホスト３３のＩＰアドレス“ホストＩＰ３”に対応する管理サーバ４４のＩＰアドレスが格納されたエントリとを保持する。
【００６１】
図１４は、管理サーバ４２が保持するホストＩＤ−ＬＯＣ管理テーブルの登録内容例を示す。管理サーバ４２のホストＩＤ−ＬＯＣ管理テーブル９０は、ホスト３２のＩＰアドレス“ホストＩＰ２”，ホスト３３のＩＰアドレス“ホストＩＰ３”のそれぞれに関して、対応するエッジノードリスト“ＬＯＣ５”と、エッジノードリストが最終エッジを含まないことを示す情報（“Ｎｏ”）とを保持している。
【００６２】
図１５は、管理サーバ４３が保持するホストＩＤ−ＬＯＣ管理テーブル９０の登録内
容例を示す。管理サーバ４３のホストＩＤ−ＬＯＣ管理テーブル９０は、ホスト３２のＩＰアドレス“ホストＩＰ２”，ホスト３３のＩＰアドレス“ホストＩＰ３”のそれぞれに関して、対応するエッジノードリスト“ＬＯＣ６”と、エッジノードリストが最終エッジを含まないことを示す情報（“Ｎｏ”）とを保持している。
【００６３】
図１６は、管理サーバ４４が保持するホストＩＤ−ＬＯＣ管理テーブルの登録内容例を示す。管理サーバ４４のホストＩＤ−ＬＯＣ管理テーブル９０は、ホスト３２のＩＰアドレス“ホストＩＰ２”に関して、対応するエッジノードリスト“ＬＯＣ７，ＬＯＣ２”及び最終エッジを含むことを示す情報（“Ｙｅｓ”）を含むエントリを保持する。また、管理サーバ４４のホストＩＤ−ＬＯＣ管理テーブル９０は、ホスト３３のＩＰアドレス“ホストＩＰ３”に関して、対応するエッジノードリスト“ＬＯＣ７，ＬＯＣ３”及び最終エッジを含むことを示す情報（“Ｙｅｓ”）を含むエントリを保持する。
【００６４】
図１７は、データパケットを受信したエッジノード２０（エッジノード２１〜２７の何れか）で実行される処理例を示すフローチャートである。図１７の処理は、エッジノード２０のインタフェースカード５４でネットワークから受信されたデータパケットをスイッチカード５２が受信することによって開始される（Ｓ０１）。
【００６５】
データパケットを受信したスイッチカード５２（パケット転送部６２）は、データパケットに設定された宛先ＩＰアドレスに対応するエントリを経路テーブル６６から検索する（Ｓ０２）。対応するエントリが検索された（ヒットした）場合には、当該エントリに格納された宛先ＩＰアドレスに対応する転送先情報に基づき、転送先情報に対応するインタフェースカード５４にデータパケットが転送され、当該インタフェースカード５４からネットワークへ送出される（Ｓ０３）。
【００６６】
これに対し、宛先ＩＰアドレスに対応する転送先情報を含むエントリがヒットしなかった場合には、スイッチカード５２は、宛先ＩＰアドレスに対応するＬＯＣを解決するためのＬＯＣ要求の生成を要求するメッセージをＣＰＵ５１に与える。ＣＰＵ５１は、ＬＯＣ要求生成部６８として、スイッチカード５２からの要求に基づいてＬＯＣ要求を生成し、対応する管理サーバ４０と接続されたインタフェースカード５４へＬＯＣ要求を送る。生成されたＬＯＣ要求には、宛先ＩＰアドレスとＬＯＣ要求元アドレスとが格納される。ＬＯＣ要求を受け取ったインタフェースカード５４は、ＬＯＣ要求送信部６９として、ＬＯＣ要求をネットワーク（管理サーバ４０）へ送信する（Ｓ０４）。
【００６７】
図１８は、ＬＯＣ要求を受信した管理サーバ４０（管理サーバ４１〜４４の何れか）で
実行される処理例を示すフローチャートである。図１８に例示する処理は、ＬＯＣ要求をネットワークから受信したネットワークインタフェース８４（ＬＯＣ要求受信部８５）がネットワークから受信したＬＯＣ要求をＣＰＵ８１に送り、ＣＰＵ８１がＬＯＣ要求を受信する（Ｓ２１）ことによって開始される。
【００６８】
ＣＰＵ８１は、ＬＯＣ要求処理部８６としての機能を用い、以下の処理を行う。すなわち、ＣＰＵ８１は、ホストＩＤ−ＬＯＣ管理テーブル９０（図９）を参照し、ＬＯＣ要求に含まれる宛先ＩＰアドレスに対応するエントリを検索する（Ｓ２２）。対応するエントリがヒットした場合には、ＣＰＵ８１は、ヒットしたエントリ中のエッジノードリスト（ＬＯＣリスト）が最下位層のエッジノード（リーフ：最終エッジ）を含むか否かを判定する（Ｓ２３）。
【００６９】
最終エッジが含まれない場合には、ＣＰＵ８１は、ヒットしたエントリ中のＬＯＣリストに含まれるＬＯＣ（エッジノードアドレス）を、ＬＯＣ要求に追加する（Ｓ２４）。続いて、ＣＰＵ８１は、ＬＯＣ管理サーバ情報テーブル８９（図８）を参照し、ＬＯＣ要求中の宛先ＩＰアドレスに対応するエントリを検索する（Ｓ２５）。
【００７０】
対応するエントリがヒットした場合には、ＣＰＵ８１は、エントリ中の管理サーバアドレスへＬＯＣ要求を転送する。すなわち、宛先ＩＰアドレスがＬＯＣ管理サーバ情報テーブル８９から得られた管理サーバアドレスに設定されたＬＯＣ要求がＣＰＵ８１から対応するインタフェースカード５４へ転送され、当該インタフェースカード５４からネットワーク（次の管理サーバ４０）へ送信される。これに対し、対応するエントリがヒットしない場合には、ＬＯＣ要求に含まれる宛先IPアドレスが存在しないとして、所定のエラー処理が行われる（Ｓ２７）。
【００７１】
Ｓ２３において、ＬＯＣリストに最終エッジが含まれると判定された場合には、ＣＰＵ８１は、ＬＯＣ応答を生成する。このとき、ＣＰＵ８１は、宛先ＩＰアドレスと、ＬＯＣ要求元アドレスと、ＬＯＣ要求に含まれるＬＯＣリストに含まれるＬＯＣ（エッジノードアドレス）と、Ｓ２２でヒットしたエントリ中のＬＯＣリスト（エッジノードアドレス）とをＬＯＣ応答に含める（Ｓ２８）。
【００７２】
ＣＰＵ８１は、ＬＯＣ応答に含まれるＬＯＣリスト中の最終エッジ、又は最終エッジの１つ前のエッジノードへＬＯＣ応答を送信する（Ｓ２９）。すなわち、ＣＰＵ８１は、ＬＯＣ応答を送信先のエッジノード２０に対応するインタフェースカード５４へ送り、当該インタフェースカード５４は、ＬＯＣ応答をネットワーク（対応するエッジノード２０）へ送信する。
【００７３】
図１９は、ＬＯＣ応答を受信したエッジノード２０（エッジノード２１〜２７の何れか）で実行される処理例を示すフローチャートである。図１９に示す処理は、エッジノード２０のインタフェースカード５４で受信されたＬＯＣ応答をＣＰＵ５１が受け取ることによって開始される（Ｓ３１）。
【００７４】
ＬＯＣ応答を受信したＣＰＵ５１は、スイッチカード５２が有する経路テーブル６６（図４）の登録内容を参照（スイッチカード５２から入手）し、宛先ＩＰアドレス（ＬＯＣ要求中のホストの宛先ＩＰアドレス）を有するホストがエッジノード２０に接続されているか否かを判定する（Ｓ３２）。ホストが接続されている場合には、ＣＰＵ５１は、上位層側に位置する他のエッジノード２０へＬＯＣ応答を転送する（Ｓ３３）。当該Ｓ３３の処理は、例えば、ＬＯＣ応答を管理サーバ４４から受信したエッジノード２２がＬＯＣ応答を上位層側のエッジノード２７へ転送するための処理である。すなわち、エッジノード自身の配下にホストが実際に接続されていれば、Ｓ３３に処理が進み、そうでなければＳ
３４に処理が進むようにしている。但し、最終エッジに相当するエッジノード２２では、ホストが接続されていなければ、エラー処理が行われるようになっている。
【００７５】
Ｓ３２において、宛先ＩＰアドレスが登録されていない場合には、ＣＰＵ５１は、トン
ネル生成部７１として機能する。すなわち、ＣＰＵ５１は、ＬＯＣ応答中のＬＯＣリス
トの最後に位置するＬＯＣ及び対応するトンネル番号を含むエントリをトンネル管理テーブル６７（図５）に登録する。また、ＣＰＵ５１は、“ホストＩＰ２”に対応する転送先（転送経路）を示すトンネル番号を含むエントリを経路テーブル６６（図４）に登録する（Ｓ３４）。経路テーブル６６及びトンネル管理テーブル６７に対する登録処理は、ＣＰＵ５１がスイッチカード５２に対する上記した各エントリの登録指示を与え、スイッチカード５２が各テーブル６６及び６７の更新（エントリ登録）を行うことによって実現される。
【００７６】
ＣＰＵ５１は、自エッジノードがホストからデータパケットを受信したエッジノード２０か否かを判定する（Ｓ３５）。データパケットを受信したエッジノード２０に該当する場合には、ＬＯＣ要求送信前に受信したデータパケットの転送指示をスイッチカード５２に与える。スイッチカード５２は、パケット転送部６２及びカプセル部６５として機能し、更新された経路テーブル６６及びトンネル管理テーブル６７を用いてデータパケットをカプセル化し（ＬＩＳＰパケットを生成し）、宛先ＩＰアドレス（ＬＯＣ）に応じたインタフェースカード５４へＬＩＳＰパケットを転送する。インタフェースカード５４は、ＬＩＳＰパケットをトンネルによって結ばれた次ホップのエッジノード２０へ送信する（Ｓ３６）。但し、ＬＯＣ応答を受信するまでパケットを保持しておくことは要求されない。
【００７７】
一方、Ｓ３５において、データパケットを受信したエッジノードでないと判定される場合には、ＣＰＵ５１は、ＬＯＣ応答中のＬＯＣリストからエントリ登録に用いたＬＯＣを除去する（Ｓ３７）。ＬＯＣ応答中のＬＯＣリストからエントリ登録に用いたＬＯＣを除去した結果、２つ以上のＬＯＣ情報がある場合（Ｓ３８，２以上）には、その後のＬＯＣリストの最後に位置するＬＯＣより１つ前に位置するＬＯＣを有するエッジノードへＬＯＣ応答を転送する（Ｓ３９）。ＬＯＣを除去した結果、ＬＯＣ情報が１つになった場合（Ｓ３８，１つ）には、ＬＯＣ要求元アドレスにＬＯＣ応答を転送する（Ｓ４０）。このとき、ＬＯＣ応答は、ＣＰＵ５１から対応するインタフェースカード５４へ与えられ、インタフェースカード５４からネットワークへ送出される。
【００７８】
以下、図１０に示すネットワークにおいて、管理サーバ４１〜４４が図１１〜図１６に示したテーブルエントリを有し、且つ各エッジノード２１〜２７が図１７及び図１９に示した処理を行い、各管理サーバ４１〜４４が図１８に示す処理を行うことを前提に、動作例１を説明する。
【００７９】
＜＜フェーズ１＞＞
ホスト３１は、宛先ＩＰアドレス“ホストＩＰ２”が設定されたユーザデータパケット（以下、動作例において、単に「パケット」と表記）を送信する（図１０（１））。パケットは、エッジノード２１で受信される。
【００８０】
＜＜フェーズ２＞＞
パケットを受信したエッジノード２１では、経路テーブル６６が参照され、パケットの宛先ＩＰアドレス“ホストＩＰ２”に対応する転送経路が特定される。ホスト３２宛のパケットがエッジノード２１に最初に到着したときには、経路テーブル６６は、“ホストＩＰ２”向けの転送先情報を保持していない。すなわち、ホストＩＰ２に対応する経路が存在しない。このため、エッジノード２１は、“ホストＩＰ２”に対応するＬＯＣを解決するためのＬＯＣ要求を生成し、管理サーバ４１へ送信する。（図１０（２））。生成され
たＬＯＣ要求は、宛先ＩＰアドレス “ホストＩＰ２” とＬＯＣ要求元アドレス“ＬＯＣ１"とを含む。
【００８１】
＜＜フェーズ３＞＞
管理サーバ４１は、ＬＯＣ要求を受信すると、ＬＯＣ管理サーバ情報テーブル８９（図１１）を参照する。このとき、ＬＯＣ要求に含まれた“ホストＩＰ２”に対応する管理サーバ４２のＩＰアドレスがテーブル８９に登録されている。このため、管理サーバ４１は、ＬＯＣ要求を管理サーバ４２へ転送する（図１０（３））。但し、ＬＯＣ管理テーブルには、管理サーバアドレスの代わりに、管理サーバへＬＯＣ要求を転送する中継サーバのアドレスが登録され、中継サーバが次の管理サーバ宛のＬＯＣ要求を中継する構成が採用されても良い。
【００８２】
＜＜フェーズ４＞＞
ＬＯＣ要求を受信した管理サーバ４２は、ホストＩＰ−ＬＯＣ管理テーブル９０（図１４）を参照し、“ホストＩＰ２”宛てのパケットが経由するエッジノードが管理されているかを確認する。すなわち、管理サーバ４２は、テーブル９０からＬＯＣ要求中のホストの宛先ＩＰアドレス“ホストＩＰ２”に対応するエントリを検索する。図１４に示すように、ホストＩＰ−ＬＯＣ管理テー部９０は、“ホストＩＰ２”に対応するエントリが登録されており、検索によって当該エントリがヒットする。
【００８３】
管理サーバ４２は、ヒットしたエントリ中の、ＬＯＣリストが最終エッジを含むか否かを示す情報（最終エッジ情報）を参照する。以下の説明において、最終エッジ情報によって示される、最終エッジを含むことを示す情報を“Ｙｅｓ情報”と表記し、最終エッジを含まないことを示す情報を“Ｎｏ情報”と表記する。最終エッジ情報がＮｏ情報であるので、管理サーバ４２は、エントリ中のエッジノードリスト（ＬＯＣリスト）として登録されている“ＬＯＣ５（エッジノード２５のＩＰアドレス）”をＬＯＣ要求に格納する。
【００８４】
続いて、管理サーバ４２は、ＬＯＣ管理テーブル８９（図１２）を検索する。このとき、“ホストＩＰ２”に対応する転送先として管理サーバ４３のＩＰアドレスが登録されたエントリがヒットする。管理サーバ４２は、ヒットしたエントリに従って、ＬＯＣ要求を管理サーバ４３に転送する（図１０（４））。
【００８５】
＜＜フェーズ５＞＞
ＬＯＣ要求を受信した管理サーバ４３は、管理サーバ４２と同様の動作を行う。すなわち、管理サーバ４３は、ホストＩＤ−ＬＯＣ管理テーブル９０（図１５）の参照によって、ＬＯＣ要求中のＬＯＣリストにエッジノード２６のＩＰアドレス“ＬＯＣ６”を追加する（ＬＯＣ要求中のＬＯＣリストは、ＬＯＣ５及びＬＯＣ６を含む状態となる）。また、管理サーバ４３は、ＬＯＣ管理テーブル８９（図１３）の参照によって、宛先ＩＰアドレス“ホストＩＰ２”に対応する管理サーバ４４のＩＰアドレス宛にＬＯＣ要求を転送する（図１０（５））。
【００８６】
＜＜フェーズ６＞＞
ＬＯＣ要求を受信した管理サーバ４４は、管理サーバ４２，４３と同様に、ホストＩＰ−ＬＯＣ管理テーブル９０（図１６）を検索する。このとき、“ホストＩＰ２”に対応するエントリがヒットする。ヒットしたエントリの最終エッジ情報はＹｅｓ情報である（図１６）。このため、管理サーバ４４は、ＬＯＣ応答を生成する。ＬＯＣ応答には、ＬＯＣ要求元アドレス“ＬＯＣ１"と、ＬＯＣ要求中のＬＯＣリストに含まれた全てのＬＯＣと
、ヒットしたエントリ中のＬＯＣリストに含まれた全てのＬＯＣとが格納される。したがって、ＬＯＣ応答は、複数のＬＯＣ情報として、“ＬＯＣ５”，“ＬＯＣ６”，“ＬＯＣ７”及び“ＬＯＣ２”を含むＬＯＣリストを含んだ状態となる。ＬＯＣリストに含まれる
複数のＬＯＣは、本実施形態では、ルートからリーフへ向かう順に並んだ状態で格納される。
【００８７】
管理サーバ４４は、予め設定されたＬＯＣ応答の送信先情報に従って、最終エッジであるエッジノード２０（エッジノード２２），又は最終エッジより１つ前のエッジノード２０（エッジノード２７）へＬＯＣ応答を送信する。ＬＯＣ応答の送信先情報は、例えば、ＨＤＤ８３のような二次記憶装置上に予め保持されることができる。送信先情報は、例えば、ホストＩＤ−ＬＯＣ管理テーブル９０の、最終エッジであることを示す情報を保持するエントリ中に含めることができる。以降の動作は、ＬＯＣ応答がエッジノード２７へ送信された場合を例示する（図１０（６））。
【００８８】
＜＜フェーズ７＞＞
ＬＯＣ応答を受信したエッジノード２７は、ＬＯＣ応答に格納されているＬＯＣリストの最後に位置するＬＯＣ（ＬＯＣ２）を、エッジノード２７が有するトンネル管理テーブル６７に登録する。例えば、トンネル番号“１”に対応する“ＬＯＣ２”として登録する。図２０は、エッジノード２７のトンネル管理テーブル６７に登録されるエントリを示す。
【００８９】
さらに、エッジノード２７は、エッジノード２７が有する経路テーブル６６に対し、“ホストＩＰ２”宛のパケットに対応する転送経路は、トンネル番号“１”のトンネル（トンネル１）であることを示すエントリが登録される。図２１は、エッジノード２７の経路テーブル６６に登録されるエントリを示す。これによって、エッジノード２７で受信した“ホストＩＰ２”（ホスト３２）宛のパケットは、エッジノードアドレス“ＬＯＣ２”を宛先ＩＰアドレスとするヘッダをパケットの先頭に追加してカプセリングすることによって、トンネル１へ転送することができる。
【００９０】
エッジノード２７は、ＬＯＣ応答中のＬＯＣリストから“ＬＯＣ２”を取り除く。これによって、ＬＯＣリストに含まれる１以上のＬＯＣは、“ＬＯＣ５”，“ＬＯＣ６”，“ＬＯＣ７”となる。エッジノード２７は、ＬＯＣリストにおける“ＬＯＣ７”の１つ前に示されたＬＯＣ（“ＬＯＣ６”）を有するエッジノード２６へＬＯＣ応答を転送する（図１０（７））。
【００９１】
＜＜フェーズ８＞＞
ＬＯＣ応答を受信したエッジノード２６も、エッジノード２７と同様の処理を行う。すなわち、エッジノード２６は、エッジノード２６が有するトンネル管理テーブル６７に対し、“ＬＯＣ７”に対応するトンネル番号“１”を含むエントリを登録する。図２２は、エッジノード２６のトンネル管理テーブル６７に登録されるエントリを示す。また、エッジノード２６は、エッジノード２６が有する経路テーブル６６に対し、ホストＩＰアドレス“ホストＩＰ２”に対応するトンネル番号“１”を含むエントリを登録する（図２１参照）。そして、エッジノード２６は、ＬＯＣ応答中のＬＯＣリストから、最後に位置する“ＬＯＣ７”を取り除き、次のエッジノードに該当するエッジノード２５へ、“ＬＯＣ５”及び“ＬＯＣ６”のＬＯＣリストを含むＬＯＣ応答を送信する（図１０（８））。
【００９２】
＜＜フェーズ９＞＞
ＬＯＣ応答を受信したエッジノード２５も、エッジノード２７，エッジノード２６と同様の動作を行う。すなわち、エッジノード２５は、エッジノード２５が有するトンネル管理テーブル６７に対し、“ＬＯＣ６”に対応するトンネル番号“１”を含むエントリを登録する。図２３は、エッジノード２５のトンネル管理テーブル６７に登録されるエントリを示す。また、エッジノード２５は、エッジノード２５が有する経路テーブル６６に対し、ホストＩＰアドレス“ホストＩＰ２”に対応するトンネル番号“１”を含むエントリを
登録する（図２１参照）。そして、エッジノード２５は、ＬＯＣ応答中のＬＯＣリストから、最後に位置する“ＬＯＣ６”を取り除く。これによって、ＬＯＣ応答中のＬＯＣリストのＬＯＣ情報が“ＬＯＣ５”の１つとなる。このため、エッジノード２５は、ＬＯＣ要求元アドレス“ＬＯＣ１”（すなわち、エッジノード２１）へ、 “ＬＯＣ５”のＬＯＣ
リストを含むＬＯＣ応答を送信する（図１０（９））。
【００９３】
＜＜フェーズ１０＞＞
ＬＯＣ応答を受信したエッジノード２１は、エッジノード２７，２６，２５と同様の動作を行う。すなわち、エッジノード２１は、エッジノード２１が有するトンネル管理テーブル６７に対し、“ＬＯＣ５”に対応するトンネル番号“１”を含むエントリを登録する。図２４は、エッジノード２１のトンネル管理テーブル６７に登録されるエントリを示す。また、エッジノード２１は、エッジノード２１が有する経路テーブル６６に対し、ホストＩＰアドレス“ホストＩＰ２”に対応するトンネル番号“１”を含むエントリを登録する（図２１参照）。
【００９４】
これによって、ホスト３１を収容するエッジノード２１と、宛先のホスト３２を収容するエッジノード２２との間に、エッジノード２５，エッジノード２６及びエッジノード２７を経由する多段トンネルが構築された状態となる（図１０（１０））。多段トンネルは、上記したように、同一のトンネル番号で管理することができる。このような多段トンネルを用いて、フェーズ２でエッジノード２１がホスト３１から受信したデータパケットをエッジノード２２まで転送することができる。
【００９５】
＜＜フェーズ１１＞＞
以下のフェーズ１１〜１５において、フェーズ２〜１０によって確立された複数段を有するトンネル（多段トンネル）を用いてフェーズ２で転送できなかったホストＩＰ２宛のパケット、および、その後にホスト３１からエッジノード２１へ送信されるホストＩＰ２宛のパケットを転送する際の動作例を説明する。
【００９６】
エッジノード２１は、エッジノード２１が有する経路テーブル６６（図２１参照）を参照し、“ホストＩＰ２”の転送経路を特定する。経路テーブル６６には、“ホストＩＰ２”の転送経路として、トンネル１が登録されている。さらに、“ホストＩＰ２”をトンネル１を介して転送するためのＬＯＣである“ＬＯＣ５”が、エッジノード２１のトンネル管理テーブル６７に登録されている（図２４参照）。従って、エッジノード２１は、ホスト３１からのパケットに宛先エッジノードアドレス“ＬＯＣ５”を含むヘッダを追加してカプセリングし（ＬＩＳＰパケットを生成し）、次のエッジノード２５へ転送する（図１０（１１））。
【００９７】
＜＜フェーズ１２＞＞
カプセル化されたパケット（ＬＩＳＰパケット）を受信したエッジノード２５は、ＬＩＳＰパケットの先頭に追加されたヘッダを削除する（デカプセル）。続いてエッジノード２５は、元のパケットの宛先ＩＰアドレス“ホストＩＰ２”に対応するエントリを経路テーブル６６（図２１参照）から検索する。
【００９８】
エッジノード２５の経路テーブル６６には、“ホストＩＰ２”の転送経路として、トンネル１が登録されている。さらに、“ホストＩＰ２”をトンネル１を介して転送するためのＬＯＣである“ＬＯＣ６”が、エッジノード２５のトンネル管理テーブル６７に登録されている（図２３参照）。従って、エッジノード２５は、元のパケットの先頭に宛先エッジノードアドレス“ＬＯＣ６”を含むヘッダを追加してカプセリングし（ＬＩＳＰパケットを生成し）、次のエッジノード２６へ転送する（図１０（１２））。
【００９９】
＜＜フェーズ１３＞＞
カプセル化されたパケット（ＬＩＳＰパケット）を受信したエッジノード２６は、エッジノード２５と同様の動作を行う。すなわち、エッジノード２６は、ＬＩＳＰパケットの先頭に追加されたヘッダを削除する（デカプセル）。続いてエッジノード２６は、デカプセルされたパケット（元のパケット）の宛先ＩＰアドレス“ホストＩＰ２”に対応するトンネル番号を、エッジノード２６が有する経路テーブル６６（図２１参照）から検索する。
【０１００】
検索によって、“ホストＩＰ２”の転送経路として“トンネル１”がヒットする。また、エッジノード２６が有する経路テーブル６７（図２２）の検索によって、“ホストＩＰ２”に対応する“ＬＯＣ７”がヒットする。従って、エッジノード２６は、元のパケットの先頭に宛先エッジノードアドレス“ＬＯＣ７”を含むヘッダを追加してカプセリングし（ＬＩＳＰパケットを生成し）、次のエッジノード２７へ転送する（図１０（１３））。
【０１０１】
＜＜フェーズ１４＞＞
カプセル化されたパケット（ＬＩＳＰパケット）を受信したエッジノード２７は、エッジノード２５や２６と同様の動作を行う。すなわち、エッジノード２７は、ＬＩＳＰパケットの先頭に追加されたヘッダを削除する（デカプセル）。続いてエッジノード２７は、デカプセルされたパケット（元のパケット）の宛先ＩＰアドレス“ホストＩＰ２”に対応するトンネル番号を、エッジノード２７が有する経路テーブル６６（図２１参照）から検索する。
【０１０２】
検索によって、“ホストＩＰ２”の転送経路として“トンネル１”がヒットする。また、エッジノード２７が有する経路テーブル６７（図２０）の検索によって、“ホストＩＰ２”に対応する“ＬＯＣ２”がヒットする。従って、エッジノード２６は、元のパケットの先頭に宛先エッジノードアドレス“ＬＯＣ２”を含むヘッダを追加してカプセリングし（ＬＩＳＰパケットを生成し）、次のエッジノード２２へ転送する（図１０（１４））。
【０１０３】
＜＜フェーズ１５＞＞
カプセル化されたパケット（ＬＩＳＰパケット）を受信したエッジノード２２は、ＬＩＳＰパケットの先頭に追加されたヘッダを削除する（デカプセル）。続いてエッジノード２７は、デカプセルされたパケット（元のパケット）の宛先ＩＰアドレス“ホストＩＰ２”に対応する転送先を、エッジノード２２が有する経路テーブル６６から検索する。
【０１０４】
エッジノード２２が有する経路テーブル６６には、“ホストＩＰ２”に対応する転送先として、ホスト３２のアドレスである“ホストＩＰ２”又は“ホストＩＰ２”へのパケットを転送する次ホップルータのＩＰアドレスが登録されている。従って、エッジノード２２は、通常のルーティング処理と同様の処理によって、ホスト３２へ向けてパケットを転送する（図１０（１５））。
【０１０５】
以上のようにして、コア網１０では、ホスト３１からのパケット受信を契機として、コア網の入口エッジノード２１と出口エッジノード２２との間を１以上の中継エッジノード２５，２６，２７で結ぶ複数段のトンネルが確立され、確立されたトンネルを用いて宛先ホスト３２へパケットが転送される。
【０１０６】
動作例１によれば、１つのＬＯＣ要求によって、夫々ホストを収容する入口エッジノードと出口エッジノードとの間に、１以上の中継エッジノードを経由する複数段トンネル（多段トンネル）を構築することができる。これによって、トンネルの起点となるエッジノードの夫々がＬＯＣ要求を管理サーバ４０へ送信することで多段トンネルを構築する場合に比べて、処理の負荷や処理に要する時間を軽減することができる。
【０１０７】
＜動作例２＞
動作例１に続いて、ホスト３１がエッジノード２３に接続されているホスト３３へパケットを送信する場合の動作を、動作例２として説明する。動作例２でも、動作例１と同様に、エッジノード２１がホスト３３（“ホストＩＰ３”）宛のパケットをホスト３１から受信することを契機として、ホストＩＰ３に対応するＬＯＣを解決するためのＬＯＣ要求が管理サーバ４１へ送信される。
【０１０８】
ＬＯＣ要求は、管理サーバ４１〜４４が保持するホストＩＤ−ＬＯＣ管理テーブル９０，ＬＯＣ管理テーブル８９（図１１〜図１６）の登録内容に従って、管理サーバ４２→管理サーバ４３→管理サーバ４４の順で転送される。このような転送の際に、ＬＯＣ要求が含むＬＯＣリストには、“ＬＯＣ５”，“ＬＯＣ６”が登録される。そして、管理サーバ４４において、“ＬＯＣ５”，“ＬＯＣ６”，“ＬＯＣ７”，“ＬＯＣ３”が格納されたＬＯＣリストを有するＬＯＣ応答が、エッジノード２３又は２７へ送信される。但し、以降の説明は、エッジノード２７へＬＯＣ応答が送信される例について説明する。
【０１０９】
ＬＯＣ応答を受信したエッジノード２７は、エッジノード２３への新たなトンネルを生成するため、動作例１と同様の処理によって、エッジノード２７が有する経路テーブル６６及びトンネル管理テーブル６７にエントリを追加する。図２５は、エッジノード２７の経路テーブル６６に登録されたエントリを示し、図２６は、エッジノード２７のトンネル管理テーブル６７に登録されたエントリを示す。図２５に示すように、“ホストＩＰ３”に対応するトンネル番号“２”（トンネル２）を含むエントリが経路テーブル６６に追加されるとともに、図２６に示すように、トンネル番号“２”に対応するエッジノードアドレス“ＬＯＣ３”を含むエントリがトンネル管理テーブル６７に登録される。
【０１１０】
ＬＯＣ応答は、エッジノード２７→エッジノード２６→エッジノード２５→エッジノード１の順で転送される。ここで、エッジノード２６，２５，２１には、すでに下位階層のエッジノードへのトンネル１が登録されている。このため、エッジノード２６，２５及び２１は、新たにトンネルを生成せず、登録済みのトンネル１を使用して転送を行う。このため、エッジノード２６，２５，２１は、図２７に示すように、自ノードが有する経路テーブル６６に、“ホストＩＰ３”に対応する転送先情報（トンネル１）を登録する。図２７は、エッジノード２１，２５，２６が夫々有する経路テーブル６６のエントリを示す。
【０１１１】
動作例２によれば、既に構築された複数段トンネル（多段トンネル）の途中から枝分かれする経路を辿って到達する出口エッジノード（エッジノード２３）に収容されたホスト（ホスト３３）宛のトンネルが新たに構築される場合には、分岐点となるエッジノード（エッジノード２７）とホスト３３に対する出口エッジノード（エッジノード２３）との間に新たなトンネル（トンネル２）が構築され、分岐点から上流側（エッジノード２５−エッジノード２６−エッジノード２７）は、既に構築されたトンネル（トンネル１）が使用される。従って、トンネル構築に要する時間及び負荷を軽減することができる。
【０１１２】
＜動作例３＞
動作例１の終了後において、ホスト３２が移動し、ホスト３２が属するアクセス網がアクセス網１２からアクセス網１３に変更され、ホスト３２がエッジノード２３に収容された状態となった場合を仮定する。この場合、エッジノード２２，２３は、ホスト３２の移動を公知の手法（例えば、ＯＳＰＦ（Open Shortest Path First）のHelloパケットの利
用、或いはpingメッセージの利用）によって知ることができる。
【０１１３】
この場合、エッジノード２２は、エッジノード２７に対し、ホスト３２の不存在に起因するＬＯＣ変更要求を送信する。すると、エッジノード２７のＣＰＵ５１は、エッジノー
ド２２へ向けた“ホストＩＰ２”宛てのパケットの送信を停止する。続いて、エッジノード２７のＣＰＵ５１は、エッジノードツリーの最終エッジ（エッジノード２２）と同一階層に位置するエッジノード２３，２４の夫々に対し、各エッジノード２２，２３が“ホストＩＰ２”を収容しているか否かを問い合わせる（問い合わせメッセージを作成して送信する）。エッジノード２３，２４のエッジノードアドレスは、エッジノード２７の記憶装置５３に予め保持されている。
【０１１４】
エッジノード２３及び２４の夫々は、“ホストＩＰ２”宛てにpingメッセージを送信し、応答メッセージ“echo reply”を待つ。エッジノード２３及び２４の夫々は、応答メッセージの受領／非受領に基づき、問い合わせに対する回答メッセージ（“ホストＩＰ２の存在／非存在）をエッジノード２７に送信する。
【０１１５】
エッジノード２７は、回答メッセージをエッジノード２３及び２４から受信することによって、エッジノード２３又は２４がホスト３２を収容しているか否かを知ることができる。動作例３では、ホスト３２は、エッジノード２３に接続されているので、エッジノード２７は、エッジノード２３からの回答メッセージによって、ホスト３２がエッジノード２３に接続されていることを知ることができる。
【０１１６】
すると、エッジノード２７のＣＰＵ５１は、出口エッジノード（最終エッジ）を、エッジノード２２からエッジノード２３に変更する（エッジノード２７から先のトンネルの再構築を行う）ための処理を行う。すなわち、エッジノード２７は、エッジノード２７が有するトンネル管理テーブル６７（図２０参照）における、“トンネル１”，“ＬＯＣ２”のエントリを、新たなトンネル番号“２（トンネル２）”，“ＬＯＣ３”に書き換える。また、エッジノード２７は、エッジノード２７が有する経路テーブル６６（図２１参照）における“ホストＩＰ２”，“トンネル１”のエントリを、“ホストＩＰ２”（変更なし），“トンネル２”に書き換える。上記したテーブル６６，６７に対する書き換えは、ＣＰＵ５１がスイッチカード５２に対して書き換え指示を発行することによって行われる。これによって、エッジノード２７より下位階層側において、アクセス網１３へ移動したホスト３２宛てのパケットを転送するためのトンネル２が構築された状態となる。
【０１１７】
テーブル６６及び６７の書き換えが完了したエッジノード２７のＣＰＵ５１は、スイッチカード５２に対してパケット送信の再開指示を与える。スイッチカード５２は、再開指示に従って、書き換え後のテーブル６６及びテーブル６７の登録内容に基づき、“ホストＩＰ２”宛のパケットがＬＯＣ３を含むヘッダでカプセル化されたＬＩＳＰパケットをエッジノード２３へ送信する状態となる。このように、ホスト３２が属するアクセス網が変更された場合には、最終エッジより一つ上位側のエッジノード（エッジノード２７）から下位側のトンネルのみが再構築される。これによって、トンネル再構築に要する時間を短縮することができ、アクセス網の変更による転送の中断時間を短縮することができる。
【０１１８】
＜動作例４＞
動作例２の終了後に、ホスト３２がアクセス網１２からアクセス網１３へ移動して、出口エッジノード（最終エッジ）がエッジノード２２からエッジノード２３へ変更された場合を仮定する。エッジノード２２がＬＯＣ変更要求をエッジノード２７へ送信し、エッジノード２７がエッジノード２３，２４へ問い合わせを行い、回答メッセージによってエッジノード２３がホスト３２と接続されていることをエッジノード２７が認識するまでのステップは、動作例３と同じである。
【０１１９】
但し、動作例４では、動作例２での動作によって、エッジノード２７とエッジノード２３とを結ぶトンネル“トンネル２”が既に構築されている（図２５、図２６）。このため、エッジノード２７のＣＰＵ５１は、トンネル管理テーブル２７（図２６）から、“トン
ネル１”，“ＬＯＣ２”を削除する書き換え指示をスイッチカード５２に与える一方で、経路テーブル６６（図２５）における“ホストＩＰ２”，“トンネル１”のエントリを、“ホストＩＰ２”，“トンネル２”に書き換える書き換え指示をスイッチカード５２に与える。書き換え指示に従って、スイッチカード５２は、エッジノード２７の各テーブル６６，６７を更新する。これによって、動作例３と同様に、エッジノード２２からエッジノード２７までの間はトンネル１、エッジノード２７からエッジノード２３までの間はトンネル２が構築された状態となる。その後、動作例３と同様に、エッジノード２７にて“ホストＩＰ２”宛のパケットの転送処理が再開される。
【０１２０】
＜第１実施形態の効果＞
第１実施形態の動作例１によれば、ホスト間の通信開始時において、コア網１０の入口エッジノード２１がＬＯＣ要求を管理サーバ４１へ送信することを契機として、入口エッ
ジノード２１と出口エッジノード２２とを結ぶ多段トンネルが一括で構築される。この
ため、エッジノード２１，２５，２６，２７の夫々が、下位階層のエッジノードとの間でトンネルを構築するために、対応する管理サーバ４０にＬＯＣ要求を送信する場合に比べて、各エッジノードの負荷やトンネル構築に要する時間を短縮化することができる。また、エッジノード２１における、ホスト３２向け（“ホストＩＰ２”向け）パケットの転送中断時間の短縮化が図られる。
【０１２１】
また、動作例２によれば、入口エッジノードが共通で、出口エッジノードが異なるホスト（ホスト３３）へのトンネル構築時において、ツリーの分岐点となるエッジノード２７より下位層側のトンネル（エッジノード２７−エッジノード２３間のトンネル）のみが新規に構築される。これによって、トンネル構築に要する時間や各エッジノードにおける負荷の低減を図ることができる。
【０１２２】
さらに、動作例３，４によれば、ホスト３２が移動した場合に、エッジノード２７における経路テーブル６６及びトンネル管理テーブル６７の書き換えによって、移動後のホスト３２に対し、適正にパケットを転送することができる。動作例３、４によれば、下記の利点が得られる。
【０１２３】
図２７の参考図に示すように、ホスト３１とホスト３２との通信において、エッジノード２１とエッジノード２２との間にトンネルが構築された場合を仮定する。この場合において、ホスト３２が、アクセス網１２からアクセス網１３へ移動し、ホスト３２が接続されるエッジノードがエッジノード２２からエッジノード２３へ変更された場合を仮定する。
【０１２４】
このとき、エッジノード２２は、エッジノード２１へＬＯＣ変更を通知し、エッジノード２１は、エッジノード２３との間でトンネルを再構築する。これによって、ホスト３２向けのパケット転送を継続することができる。エッジノード２２からエッジノード２１へＬＯＣ変更が通知され、トンネルが再構築されるまでの間、ホスト３２へのパケット転送が途絶える。エッジノード２１とエッジノード２２との距離が長い程、パケット転送の中断時間は大きくなる。これに対し、動作例３、４によれば、エッジノード２１より距離が近いエッジノード２７へＬＯＣ変更が通知されるので、パケット転送の中断時間の短縮化を図ることができる。
【０１２５】
また、ホスト３１と通信するホスト３２が、アクセス網１２→アクセス網１３→アクセス網１４へ移動し、ホスト３２が接続されるエッジノードがエッジノード２２→エッジノード２３→エッジノード２４のように変更された場合でも、トンネル再構築に係る処理は、エッジノード２７におけるテーブル６６及び６７の書き換えだけで済む。従って、パケット転送の中断時間の長期化を抑え、円滑な通信の継続を期待することができる。
【０１２６】
＜変形例１＞
動作例１，２では、管理サーバ４４は、最終エッジ（エッジノード２２，２３）の１つ前のエッジノード(エッジノード２７)へＬＯＣ応答を送信する。これによって、最終エッジにおける処理が省略されるので、最終エッジの処理負荷が軽減されるとともに、トンネル確立のための処理時間を短くすることができる。
【０１２７】
但し、上述したように、管理サーバ４０が最終エッジにＬＯＣ応答を送信する構成が採用されても良い。この場合、図１９のＳ３３のように、ＬＯＣ応答を受信した最終エッジは、ＬＯＣ応答を修正することなく、ＬＯＣ応答中のＬＯＣリストに格納されている１つ上位階層のエッジノードへＬＯＣ応答を転送する。この場合には、最終エッジのエッジノードは、宛先ホストが確かに接続されているか確認したり、あるいは、トンネルから受信されるパケットのＱｏＳ（Quality of Service）制御の設定を行ったりできるという利点がある。
【０１２８】
＜変形例２＞
図１及び図１０に示した例では、管理サーバ４０のトポロジにおける最下位層の管理サーバ４４がエッジノードツリーにおける複数階層のエッジノード（エッジノード２７，２２，２３）を管理している。管理サーバ４０のトポロジにおいて最上位階層、あるいは中位階層に位置する管理サーバ４０が複数階層のエッジノードを管理するように、第１実施形態の構成を変更可能である。
【０１２９】
例えば、管理サーバ４３が存在せず、管理サーバ４２がエッジノード２５及びエッジノード２６を管理する場合には、管理サーバ４２は、図２９に示すＬＯＣ管理サーバ情報テーブル８９と、図３０に示すホストＩＤ−ＬＯＣ管理テーブル９０を保持する。図２８に示すように、ＬＯＣ管理サーバ情報テーブル８９は、“ホストＩＰ２”と“ホストＩＰ３”の双方に対して、管理サーバ４４のＩＰアドレスが保持された状態になる。また、図２９に示すように、ホストＩＤ−ＬＯＣ管理テーブル９０は、“ホストＩＰ２”と“ホストＩＰ３”の夫々に対して、“ＬＯＣ５”及び“ＬＯＣ６”からなるＬＯＣリストを保持する状態となる。
【０１３０】
そして、変形例２では、上記したフェーズ４において、以下のような動作が行われる。すなわち、ＬＯＣ要求を受信した管理サーバ４２のＣＰＵ８１は、ホストＩＤ−ＬＯＣ管理テーブル９０（図３０）を参照し、“ホストＩＰ２”に対応するエントリを検索する。エントリが検索されると、管理サーバ４２のＣＰＵ８１は、検索されたエントリからＬＯＣリスト（ＬＯＣ５，ＬＯＣ６）を取得する。検索されたエントリ中の最終エッジ情報はＮｏ情報であるので、管理サーバ４２のＣＰＵ８１は、ＬＯＣ５及びＬＯＣ６が格納されたＬＯＣ要求を、ＬＯＣ管理サーバ情報テーブル８９（図２９）から検索される管理サーバ４４のＩＰアドレスへ転送する。
【０１３１】
変形例２によれば、ＬＯＣ要求に対する処理を行う管理サーバ４０の数を減らすことができるので、多段トンネル構築に要する時間の短縮化を期待することができる。
〔第２実施形態〕
次に、本発明の第２実施形態について説明する。第２実施形態は、第１実施形態との共通点を含むので、主として相違点について説明し、共通点については詳細な説明を省略する。第２実施形態における動作例として、図１に示したネットワークシステムにおいて、
第１ホスト３３がホスト３２へパケットを転送する場合の動作を説明する。
通常、送信側ホスト（ホスト３１）が接続している入口エッジノード（エッジノード２
１）のＬＯＣ管理サーバ情報テーブル８９には、エッジノードツリーのルートとなるエッジノード（エッジノード２５）を管理している管理サーバ４０（管理サーバ４２）のＩＰ
アドレスが登録される。このため、エッジツリー内のリーフ間での通信でも、ルートのエッジノード２０（エッジノード２５）を経由するパケット転送となってしまう。コア網１０内でのパケット転送は、エッジノードツリーのルートを起点として行われるように制御されるからである。
【０１３２】
第２実施形態では、エッジノード２０が、ホストＩＤ−ＬＯＣ管理テーブル９０を最初に参照することによって、ルートのエッジノード２０（エッジノード２５）を経由しない効率的なトンネルを確立し、効率的な転送を行うことを可能にする手法について説明する。以下の説明においては、第１実施形態の動作例１と同様に、図１１〜図１６に示したような、ＬＯＣ管理サーバ情報テーブル８９，ホストＩＤ−ＬＯＣ管理テーブル９０が管理サーバ４１〜４４に保持されていることを仮定する。
【０１３３】
図１に示すネットワークシステムにおいて、ホスト３３がホスト３２向けのパケット（宛先ＩＰアドレス“ホストＩＰ２”）を送信する。“ホストＩＰ２”宛のパケットを受信したエッジノード２３は、経路テーブル６６を参照し、パケットの転送経路を特定する。ここで、“ホストＩＰ２”宛てのパケットが最初に到着したときには、経路テーブル６６には“ホストＩＰ２”宛の転送先を登録したエントリが存在しない。このため、エッジノード２３は、“ホストＩＰ２”に対応するＬＯＣを解決するためのＬＯＣ要求を管理サーバ４４へ送信する。
【０１３４】
ＬＯＣ要求を受信した管理サーバ４４のＣＰＵ８１は、管理サーバ４４が保持するホストＩＤ−ＬＯＣ管理テーブル９０（図１６）を参照し、管理下のエッジノードから送信されたＬＯＣ要求であるか否かを判別する。図１６に示す例では、“ホストＩＰ２”に対するエッジノードリスト（ＬＯＣリスト（ＬＯＣ７，ＬＯＣ２））がテーブル９０に登録されている。
【０１３５】
管理サーバ４４のＣＰＵ８１は、宛先ホストに最も近いエッジノードのＬＯＣをＬＯＣリストから抽出する。図１６に示す例では、エントリ中のＬＯＣリストに含まれるＬＯＣは、ルートからリーフへ向かう方向で並べて登録されている。従って、ＬＯＣリスト中の最後に配置されたＬＯＣ２が宛先ホスト（ホスト３２）に最も近いエッジノードのＬＯＣである。従って、ＣＰＵ８１は、ＬＯＣ２を抽出し、抽出したＬＯＣ２が格納されたＬＯＣ応答を生成し、ネットワークインタフェース８４を介してエッジノード２３へ直接に返信する。
【０１３６】
ＬＯＣ応答を受信したエッジノード２３は、エッジノード２３が有するトンネル管理テーブル６７に対し、ＬＯＣ応答に格納された“ＬＯＣ２”と、“ＬＯＣ２”に対応するトンネル番号とを含むエントリを登録する。また、エッジノード２３のＣＰＵ５１は、スイッチカード５２に対する指示によって、エッジノード２３が有する経路テーブル６６に対して、“ホストＩＰ２”に対応する転送経路情報としてエッジノードアドレス“ＬＯＣ２”が格納されたエントリを登録する。
【０１３７】
これによって、ホスト３３から得たホスト３２（ホストＩＰ２）宛のパケットをエッジノード２３とエッジノード２２との間に構築されたトンネルを通じてエッジノード２２へ転送することができる。すなわち、“ホストＩＰ２”宛のパケットに“ＬＯＣ２”を含むヘッダが付与されたカプセル化パケット（ＬＩＳＰパケット）をエッジノード２２へ転送することができる。エッジノード２２では、通常のルーティングに従って、エッジノード２２から受信されたＬＩＳＰパケットに対するデカプセル処理を行い、得られた元のパケットをホスト３２へ転送する。
【０１３８】
第２実施形態によれば、配下のエッジノード２０からＬＯＣ要求を受信した管理サーバ
４０が、ホストＩＤ−ＬＯＣ管理テーブル９０を参照し、ＬＯＣ要求に含まれるホストＩＰアドレス（宛先ホストＩＰアドレス）に対応するエントリを検索する。このとき、対応するエントリが見つかれば、エントリ中のＬＯＣリストから宛先ホストに最も近いエッジノード２０のＬＯＣが抽出され、このＬＯＣを端点とするトンネルが構築される。従って、エッジノードツリーのルート又は中位階層のエッジノード２０を経由しない、効率的なパケットの転送が可能となる。
【０１３９】
なお、エッジノードツリーにおける各エッジノード２０がどの程度、宛先ホストと離れているかを勘案し、効率的な転送経路を用いることが考えられる。例えば、ＬＯＣリストが最終エッジを含んでいる場合にのみ、ツリーの中で近接しているとして、ダイレクトなエッジ−エッジ間のトンネルを確立することが考えられる。あるいは、ホストＩＤ−ＬＯＣ管理テーブル９０に効率的転送が可能であるか否かを示すフラグを設け、フラグがＯＮ
にセットされている場合のみ、上記した効率的な転送経路を構築する手法を選択するこ
とが考えられる。
【０１４０】
〔第３実施形態〕
次に、本発明の第３実施形態について説明する。第３実施形態は、第１実施形態との共通点を含むので、主として相違点について説明し、共通点については詳細な説明を省略する。
【０１４１】
図１に示すネットワークシステムの例では、エッジノードツリーが、最上位階層（エッジノード２５），上位階層（エッジノード２６），下位階層（エッジノード２７），最下位層（エッジノード２２，２３，２４）の４階層を有する。
【０１４２】
このようなツリー構成において、ホスト３１がホスト３２へパケットを転送する場合において、コア網１０におけるパケットの転送経路が、常に全ての階層のエッジノード２０を経由することは要求されない。例えば、第１実施形態で説明したようなホストの移動が頻繁に発生したり、広範に移動したりする場合では、パケット転送経路が全ての階層のエッジノード２０を経由するように、転送経路を決定することが考えられる。これに対し、ホストの移動が頻繁に発生しない、あるいは、ホストの移動による一時的な切断よりも、経由エッジノード２０の削減によって低遅延で転送した方がよい通知が望まれる場合は、入口エッジノード（ＬＯＣ１）と最下位層エッジノード(ＬＯＣ２)とでダイレクトにトンネルを確立した方がよい場合があり得る。あるいは、ＬＯＣ１とＬＯＣ２の間にすべての階層ではないいくつかの階層のエッジノード２０を通過することによって、ホストの移動時の切り替え処理の効率化と、低遅延転送をバランスさせた経路を選択することがよい場合もある。これを実現するためには、以下の手法が考えられる。
【０１４３】
[方法１−１]
ＬＯＣ要求を受信した管理サーバ４０（第１実施形態における各管理サーバ４１〜４４）が、ＬＯＣ要求に含まれたホストの宛先ＩＰアドレス（宛先ホストＩＰアドレス）に応じてＬＯＣ要求を下位階層に位置する他の管理サーバ４０に転送する場合に、管理サーバ４０が管理しているエッジノード２０（例えば、管理サーバ４２であればエッジノード２５、より具体的には、管理サーバ４２が有するホストＩＤ−ＬＯＣ管理テーブル９０のＬＯＣリストに含まれたＬＯＣを持つエッジノード２５）のＬＯＣをＬＯＣ要求が有するＬＯＣリストに追加するか否かを判定する。例えば、宛先ホストの移動時における効率的なトンネル切り替えを優先する場合には、ＬＯＣの追加が決定される。これに対し、例えば、パケットが通過するエッジノード２０の数を削減した効率的なパケット転送を行うときには、ＬＯＣを追加しないことが決定される。
【０１４４】
また、上記したＬＯＣ要求にＬＯＣを追加するか否かの判定時において、移動時の効率
的な切り替え処理と効率的なパケット転送のバランスとが考慮され、管理サーバ４０が管理するエッジノード２０のうち、パケットが経由（通過）すべき一部のエッジノード２０のＬＯＣのみをＬＯＣ要求のＬＯＣリストに追加することを決定することもできる。ＬＯＣ要求は宛先ホストＩＰアドレスに従って、下位階層に位置する他の管理サーバ４０へ送信される。
【０１４５】
[方法１−２]
ＬＯＣ要求を受信した管理サーバ４０（第１実施形態における各管理サーバ４１〜４４）が、ＬＯＣ要求に含まれた宛先ホストＩＰアドレスに応じて送信するＬＯＣ応答に対し、管理サーバ４０自身が管理するエッジノード２０のＬＯＣを追加（格納）するか否かを判定する。そして、ホスト移動時の効率的なトンネル切り替え処理を優先する場合には、管理サーバ４０は、ＬＯＣの追加を決定し、管理サーバ４０自身が管理するエッジノード２０のＬＯＣをＬＯＣ応答に格納し、所定のエッジノード２０へ送信する。そうでなければ、ＬＯＣを追加しないことが決定される。
【０１４６】
また、ＬＯＣ応答にＬＯＣを追加するか否かの判定時において、ホスト移動時の効率的な切り替え処理と効率的なパケット転送とのバランスを考慮し、管理サーバ４０自身が管理するエッジノード２０のうちの一部をパケットが経由するように、パケットが経由すべきエッジノード２０のＬＯＣのみをＬＯＣ応答に追加することを決定することも可能である。
【０１４７】
[方法１−３]
管理サーバ４０（第１実施形態における各管理サーバ４１〜４４）によって受信されるＬＯＣ要求に対し、宛先ホストＩＰアドレスだけでなく、送信元ホストＩＰアドレス，プロトコルＩＤ，ポート番号のような、管理サーバ４０が管理するＬＯＣの全部追加、一部追加、追加無しの何れかを選択するための選択用情報が格納される。選択用情報に基づいて、ＬＯＣの全部追加、一部追加、追加無しが判定される。
【０１４８】
[方法２−１]
第１実施形態で説明したようなＬＯＣリストを保持したＬＯＣ応答を受信したエッジ
ノード２０（第１実施形態におけるエッジノード２７，２６，２５）が、ＬＯＣ応答に含まれる宛先ホストＩＰアドレス，又は、ホストの移動時の効率的な切り替え処理と効率的なパケット転送のバランスを考慮した結果に基づいて、パケットが通過するエッジノード（パケット転送時にバイパスされるエッジノード）を決定する。エッジノードは、決定の結果に従って、ＬＯＣ応答中のＬＯＣリストから、バイパスされる（パケットが経由しない）１以上のエッジノードのＬＯＣを削除する。ＬＯＣ応答は、上位階層のエッジノードへ転送される。
【０１４９】
[方法２−２]
エッジノード（第１実施形態におけるエッジノード２７，２６，２５）が受信する応答に宛先ホストＩＰアドレスだけでなく、送信元ホストＩＰ、プロトコルＩＤ、ポート番号などのような、ＬＯＣ応答に格納されたＬＯＣリストから、パケットが通過すべき（パケットがバイパスすべき）エッジノードを選択するための選択用情報が格納される。選択用情報に基づいて、パケットがバイパスすべきエッジノードが決定され、決定されたエッジノードのＬＯＣがＬＯＣ応答のＬＯＣリストから削除する。
【０１５０】
[判定基準]
上記した方法１−１，１−２，１−３におけるＬＯＣの全部追加、一部追加、追加無しの判定，及び方法２−１，２−２におけるＬＯＣの一部削除、削除無しの判定に使用される判定基準として、以下のものを例示できる。
（１）エッジノードの輻輳度合
各エッジノードにおける輻輳度合が監視され、輻輳度合に応じて対応するエッジノードが除外されるように、管理サーバ４０におけるＬＯＣの追加、エッジノードにおけるＬＯＣの削除が実施される。
【０１５１】
輻輳度合の監視は、例えば、エッジノード２０，管理サーバ４０、又は専用の監視サーバ（監視用ＰＣ；図示せず）で実施することができる。監視結果（すなわち、エッジノードの輻輳の有無を示す情報（輻輳情報））は、適宜のタイミングでInband通信又はOutband通信により、管理サーバ４０又はエッジノード２０に通知される構成が適用される。
【０１５２】
エッジノード２０の輻輳情報は、当該エッジノード２０を管理する管理サーバ４０に取得される。例えば、エッジノード２５の輻輳情報は、管理サーバ４２によって取得される。管理サーバ４０が取得する輻輳情報は、例えば、管理サーバ４０の二次記憶装置（ＨＤＤ８３）に格納される。輻輳情報は、例えば、管理サーバ４０が有するホストＩＤ−ＬＯＣ管理テーブル９０に格納することができる。例えば、テーブル９０のエントリに輻輳の有無を示すフラグ（例：０（オフ）：輻輳なし、１（オン）：輻輳あり）の格納領域を設けることができる。
【０１５３】
そして、管理サーバ４０のＣＰＵ８１が、テーブル９０から検索したエントリ中のＬＯＣリストをＬＯＣ要求に追加するか否かが判定される場合に、フラグがオフであれば、ＬＯＣリストがＬＯＣ要求に追加され、フラグがオンであれば、ＬＯＣ要求へＬＯＣリストが追加されないようにすることができる。エントリ中に複数のＬＯＣが格納される場合、輻輳の有無を示すフラグとして、複数のＬＯＣを代表する１つのフラグを用意してもよく、ＬＯＣ毎に用意されても良い。ＬＯＣ毎にフラグが用意される場合には、一部のフラグがオンで、一部のフラグがオフとなることによって、ＬＯＣの一部追加を実現することができる。
【０１５４】
エッジノード２０の輻輳情報は、ＬＯＣ応答を受信するエッジノード２０に通知、又はエッジノード２０自身の取得によって取得される。例えば、エッジノード２７は、エッジノード２２の輻輳情報を、エッジノード２２，管理サーバ４４，監視サーバから受領することができる。一方で、エッジノード２７の輻輳情報は、エッジノード２７自身で監視した結果を使用することができる。輻輳情報は、例えば、エッジノード２０の記憶装置５３で保持される。
【０１５５】
ＬＯＣ応答を受信したエッジノード２０のＣＰＵ５１は、記憶装置５３に保持された輻輳情報を参照し、ＬＯＣ応答中のＬＯＣの一部を削除するか否かを判定する。記憶装置５３に保持された輻輳情報は、エッジノード毎の輻輳状態を示すものであっても、２以上のエッジノード２０の輻輳状態を代表して示すものであっても良い。ＣＰＵ５１は、輻輳ありを示す輻輳情報に対応する１以上のＬＯＣをＬＯＣ応答から削除する。これによって、ＬＯＣの一部削除が行われる。一方、全ての輻輳情報が輻輳なしを示すときには、ＬＯＣの一部削除が実施されない。
【０１５６】
また、ＬＯＣ応答を管理サーバ４０から最初に受信するエッジノード２０（例えばエッジノード２７）が、ＬＯＣ応答中のＬＯＣリストにＬＯＣが格納されたエッジノード２０の全て（例えば、エッジノード２２，２７，２６，２５）の輻輳情報を収集し、輻輳ありの輻輳情報に対応するＬＯＣがＬＯＣ応答から削除されるようにしても良い。この場合、エッジノード２７より上位側に位置するエッジノード２６，２５にて、ＬＯＣの一部削除の判定の実施を省略することができる（但し、トンネル確立のために用いたＬＯＣの削除は除く）。
【０１５７】
（２）ホストの移動頻度
ホスト（例えば、図１のホスト３２）が頻繁に出口エッジノードを切り替える（アクセス網間を移動する）場合には、ＬＯＣ要求へのＬＯＣの追加回避や、ＬＯＣ応答からのＬＯＣ削除が実行されない制御が行われる。ホストの移動頻度は、公知の様々な手法を用いて入手することができる。例えば、最終エッジに該当する各エッジノード２２，２３，２４がpingメッセージを用いてホスト３２“ホストＩＰ２”の接続状態を監視し、その監視結果を集約して、移動頻度（例えば大／小）を示す情報を作成し、所定の管理サーバ４０やエッジノード２０に移動頻度情報をセットする（記憶装置５３，ＨＤＤ８３に保持）ことが考えられる。
【０１５８】
この場合、“ホストＩＰ２”の移動頻度情報“小”がセットされた管理サーバ４０は、ＬＯＣの追加回避を行い、“ホストＩＰ２”の移動頻度情報“大”がセットされた管理サーバ４０は、ＬＯＣの追加を行う。また、“ホストＩＰ２”の移動頻度情報“小”がセットされたエッジノード２０は、ＬＯＣの削除を行い、“ホストＩＰ２”の移動頻度情報“大”がセットされた管理サーバ４０は、ＬＯＣの削除を回避する。
これによって、移動頻度“大”のホストに関しては、多くのエッジノード２０を経由する転送経路が適用され、移動時におけるトンネルの切り替え短縮化が図られるようにする。これに対し、移動頻度“小”のホストに関しては、経由エッジノードの数を減らすことができる。
【０１５９】
（３）ＬＯＣ要求、ＬＯＣ応答に含まれるパラメータ
方法１−３、方法２−２に示したように、ＬＯＣ要求，ＬＯＣ応答は、宛先ホストＩＰアドレス，送信元ホストＩＰアドレス，プロトコルＩＤ，ポート番号のような複数のパラメータを含む選択用情報を有することができる。
【０１６０】
例えば、特定の宛先ホストＩＰに対しては、様々な事情（例えば移動頻度）を反映して、常時エッジノード２０のバイパスが行われない（ＬＯＣの追加回避や削除が行われない）設定（第１設定）、或いは逆の設定（常に一部のエッジノード２０をバイパスする設定：第２設定）を行うことができる。或いは、特定のパケットフロー（送信元ＩＰアドレス及び宛先ＩＰアドレスで特定される）に対して、上記第１設定と第２設定との何れを適用するかを決定することができる。
【０１６１】
また、短時間でのトンネル切り替えが要求されるアプリケーション（プロトコルＩＤやポート番号で特定される）については、第１設定が適用され、余裕を持ったトンネル切り替えが許容されるアプリケーションについては第２設定が適用されることを決定することができる。
【０１６２】
或いは、上記した複数のパラメータの組合せ（例えば、パケットフロー＋アプリケーション）によって、第１設定と第２設定との何れを適用するかを決定することもできる。第２設定においてバイパスされるエッジノード２０は適宜決定することができる。
【０１６３】
また、上記したようなＬＯＣ追加回避の判定及び処理は、管理サーバ４０のＣＰＵによって行われる。管理サーバ４０のＨＤＤ８３のような二次記憶装置は、ＬＯＣ追加回避の判定用の情報を保持することができる。ＬＯＣ削除の判定及び処理は、エッジノード２０のＣＰＵ５１によって行われる。ＬＯＣ削除の判定用情報は、記憶装置５３で保持しておくことができる。
【０１６４】
＜第３実施形態における管理サーバ、エッジノードの処理＞
以下、第３実施形態における管理サーバ４０及びエッジノード２０における処理例を示す。第３実施形態におけるネットワークシステム，管理サーバ４１〜４４及びエッジノー
ド２０（エッジノード２１〜２９）の構成は、第１実施形態と同様である（図１〜図９参照）。但し、第３実施形態では、上記した方法１−１〜２−２を考慮し、管理サーバ４１〜４４及びエッジノード２０（エッジノード２１〜２９）の夫々における処理が第１実施形態と異なる。
【０１６５】
図３１は、第３実施形態における管理サーバ４０（各管理サーバ４１〜４４）の処理例を示すフローチャートである。図３１に示すフローチャートにおいて、Ｓ２１〜Ｓ２３の処理は、第１実施形態における管理サーバ４０の処理（図１８）と同様であるので説明を省略する。
【０１６６】
Ｓ２３において、ホストＩＤ−ＬＯＣ管理テーブル９０から検索されたエントリ中の最終エッジ情報がＮｏ情報である場合には、処理がＳ１０１へ進む。Ｓ１０１では、管理サーバ４０は、検索されたエントリに含まれるＬＯＣリストのうち、パケット転送時にパケットが通過すべきエッジノード２０のＬＯＣのみを抽出する。抽出は、上記した判定基準に基づいて行われる。次のＳ２４では、抽出されたＬＯＣのみがＬＯＣ要求のＬＯＣリストに追加される。Ｓ１０１でＬＯＣが抽出されない場合もあり得る。この場合、Ｓ２４において、ＬＯＣの追加は行われない。その後のＳ２５〜Ｓ２７の処理は、第１実施形態と同様であるので説明を省略する。
【０１６７】
Ｓ２３において、ホストＩＤ−ＬＯＣ管理テーブル９０から検索されたエントリ中の最終エッジ情報がＹｅｓ情報である場合には、処理がＳ１０２へ進む。Ｓ１０２でも、Ｓ１０１と同様の処理が行われる。その後のＳ１０３において、管理サーバ４０は、Ｓ１０２で抽出されたＬＯＣと、ＬＯＣ要求のＬＯＣリストに含まれたＬＯＣとが格納されたＬＯＣ応答が作成される。そして、管理サーバ４０は、ＬＯＣ応答に格納されたＬＯＣリスト中の最後に位置するエッジノード２０又は最後から１つ前のエッジノード２０へＬＯＣ応答を送信する（Ｓ１０４）。
【０１６８】
図３２は、ＬＯＣ応答を受信したエッジノード２０における処理を示すフローチャートである。図３２の処理において、Ｓ３１〜Ｓ３５，Ｓ３６の処理は、第１実施形態（図１９）と同様であるので説明を省略する。
【０１６９】
これに対し、Ｓ３５にて、ＬＯＣ応答を受信したエッジノード２０がホストからのパケットを受信したエッジノード２０でない場合には、処理がＳ１０５に進む。Ｓ１０５では、第１実施形態と同様に、ＬＯＣ応答中のＬＯＣリストから、最後に位置するＬＯＣが削除される。Ｓ１０５では、エッジノード２０は、上述した判定基準に従って、ＬＯＣ応答中のＬＯＣリストから、パケット転送経路が通過を要しない（バイパスすべき）エッジノード２０のＬＯＣを抽出し、抽出したＬＯＣをＬＯＣ応答から除去する。但し、判定基準に照らして抽出すべきＬＯＣがない場合には、ＬＯＣの除去は行われない。
【０１７０】
その後、Ｓ１０６において、エッジノード２０は、ＬＯＣ応答中のＬＯＣリストにおいて最後から１つ前に格納されたＬＯＣを有するエッジノード２０へＬＯＣ応答を送信する。
【０１７１】
＜動作例＞
以下、第３実施形態における動作例について説明する。
（動作例１）
動作例１として、第１実施形態の動作例１と同様に、ホスト３１とホスト３２とが通信を開始する場合を仮定する。但し、ホスト３２（ホストＩＰ２）へのパケット転送に関して、ホスト移動時の効率的なトンネル切り替え処理の優先が要求されない環境下であると仮定する。そして、管理サーバ４３に対して、ホストＩＤ−ＬＯＣ管理テーブル９０に格
納されたＬＯＣ（ＬＯＣ６）をＬＯＣ要求に追加しない判定を行うための情報が静的に又は動的に管理サーバ４３に対して設定されていると仮定する。
【０１７２】
この場合、フェーズ５（フェーズ１〜４は第１実施形態と同じ）において、管理サーバ４３は、管理サーバ４３が管理するエッジノード２０のＬＯＣであるＬＯＣ６をＬＯＣ要求中のＬＯＣリストに追加することなく、次の管理サーバ４４へ送信する。
【０１７３】
フェーズ６において、ＬＯＣ要求を受信した管理サーバ４４は、第１実施形態と同様の処理を行い、エッジノード２７へＬＯＣ応答を送信する。この場合、ＬＯＣ応答のＬＯＣリストは、ＬＯＣ５，ＬＯＣ７，ＬＯＣ２を含む状態となる。
【０１７４】
フェーズ７では、エッジノード２７は、ＬＯＣ応答中のＬＯＣ２を用いてエッジノード
２２とのトンネルを確立し、ＬＯＣ応答からＬＯＣ２を削除した後に、エッジノード２
６ではなくエッジノード２５へＬＯＣ応答を送信する。従って、フェーズ８がスキップされて、フェーズ９が実施される。これによって、エッジノード２５は、エッジノード２６がバイパスされるトンネルをエッジノード２７との間で確立する。フェーズ９及び１０は、第１実施形態と同様である。このようにして、エッジノード２６がバイパスされた複数段トンネルを構築することができる。
【０１７５】
（動作例２）
動作例２として、第１実施形態の動作例１と同様に、ホスト３１とホスト３２とが通信を開始する場合を仮定する。但し、ホスト３２（ホストＩＰ２）へのパケット転送に関して、ホスト移動時の効率的なトンネル切り替え処理の優先が要求されない環境下であると仮定する。そして、エッジノード２７に対して、ＬＯＣ応答中のＬＯＣリストから所定のＬＯＣ（例えばＬＯＣ６）を除去する設定が静的に又は動的にエッジノード２７に対して設定されていると仮定する。
【０１７６】
この場合、第１実施形態におけるフェーズ１〜６が実施され、エッジノード２７がＬＯＣ応答を管理サーバ４４から受信する。フェーズ７において、エッジノード２７は、エッジノード２２とのトンネルを確立し、ＬＯＣ２をＬＯＣ応答から削除する。さらに、エッジノード２７は、上記した設定に従って、ＬＯＣ６をＬＯＣ応答から除去する。以降の動作は、第３実施形態の動作例１と同様である。最終的にエッジノード２６がバイパスされた複数段トンネルが確立され、ホスト３１からホスト３２へのパケット転送に使用される。
【０１７７】
第３実施形態によれば、第１実施形態における管理サーバ４０やエッジノード２０の少なくとも１つに対して、ＬＯＣ要求にＬＯＣを追加しない、又はＬＯＣ応答から所定のＬＯＣを削除するための情報を設定しておくことによって、所望のエッジノード２０がバイパスされたパケット転送経路（多段トンネル）を構築することができる。
【０１７８】
なお、上述した動作例１、２では、複数の管理サーバ４０及び複数のエッジノード２０の一箇所で、ＬＯＣの追加回避又はＬＯＣ除去が実施される例について説明したが、管理サーバ４０及びエッジノード２０の複数箇所において、ＬＯＣの追加回避又はＬＯＣ除去が実施されるようにしてもよい。実施箇所は適宜設定可能である。
【０１７９】
〔第４実施形態〕
次に、本発明の第４実施形態について説明する。第４実施形態は、第１〜３実施形態と共通点を有するので、主として相違点について説明し、共通点の詳細な説明は省略する。図３３は、第４実施形態に係るネットワークシステムである。図３３に示すように、第４実施形態では、第１実施形態のネットワークシステム（図１）と異なり、コア網１０に含
まれる複数のエッジノード２０（図３３ではエッジノード２１〜２９）がメッシュ状に接続されている。
【０１８０】
このようなシステムにおいて、ホスト３１とホスト３２が通信を行うに当たり、ホスト３１がホスト３２（ホストＩＰ２）向けのパケットをエッジノード２１へ送信すると、第１実施形態の動作例１と同様の動作乃至処理が行われ、入口エッジノード２１と出口エッジノード２２との間に、エッジノード２５，２６及び２７を経由する多段トンネルを確立することができる。
【０１８１】
第４実施形態によれば、少なくとも第１実施形態の動作例１と同様に、コア網１０にホスト間を結ぶ多段トンネル（複数のトンネル）を確立する場合における各エッジノード２０及び各管理サーバ４０の処理負荷を軽減することができる。また、多段トンネルの確立に要する時間を短縮化することが期待できる。第４実施形態の構成と、第２、３実施形態で説明した構成とは適宜組み合わせることができる。
【符号の説明】
【０１８２】
２０，２１〜２７・・・エッジノード（中継装置）
３１〜３３・・・ホスト（端末装置）
４０，４１〜４４・・・管理サーバ（管理装置）
【特許請求の範囲】
【請求項１】
パケットを受信する第１中継装置と、前記パケットの宛先アドレスを有する端末と接続された第２中継装置とを含む複数の中継装置と、
前記第１中継装置を管理する第１管理装置と、前記第２中継装置を管理する第２管理装置とを含む、前記複数の中継装置を管理する複数の管理装置とを備え、
前記第１中継装置は、前記パケットの転送に用いる中継装置アドレスを解決するための、前記宛先アドレスを含む要求メッセージを前記第１管理装置へ送信し、
前記複数の管理装置は、前記要求メッセージが前記第１管理装置から前記第２管理装置へ到達するように、前記宛先アドレスに対応する転送情報に基づいて前記要求メッセージを転送するとともに、前記第１中継装置から前記第２中継装置へ到達する前記パケットが通過すべき１以上の中継装置の中継装置アドレスを前記要求メッセージに格納し、
前記第２管理装置は、前記要求メッセージに格納された複数の中継装置アドレスと、前記第２中継装置の中継装置アドレスを含む１以上の中継装置アドレスとが格納された応答メッセージを生成し、
前記応答メッセージに中継装置アドレスが格納された、前記第２中継装置を除く中継装置の夫々は、前記応答メッセージを受信し、前記応答メッセージに格納された中継装置アドレスを用いて、中継装置間の前記パケットの転送に使用されるトンネルを確立するとともに、少なくともトンネルの確立に用いた中継装置アドレスを前記応答メッセージから削除し、前記応答メッセージに残った１以上の中継装置アドレスの何れかへ前記応答メッセージを転送し、
前記応答メッセージを受信する前記第１中継装置は、前記応答メッセージに格納された中継装置アドレスを用いて次ホップに相当する中継装置との間でトンネルを確立し、
前記パケットは、前記第１中継装置、及び前記パケットが通過する中継装置の夫々から前記宛先アドレスに対応するトンネルへ送出されるときに、宛先中継装置アドレスを含むヘッダを用いてカプセル化される
ネットワークシステム。
【請求項２】
前記第１中継装置と前記第２中継装置との間における前記パケットの転送経路上の各中継装置間にトンネルが確立されている状態において、前記第２中継装置と異なる、前記複数の中継装置に含まれる第３中継装置に接続された端末宛のパケットを前記第１中継装置が受信した場合には、前記パケットの転送経路において前記第１中継装置と前記第２中継装置との間に位置する中継装置である第４中継装置が前記第３中継装置との間で新たなトンネルを確立し、
前記第３中継装置に接続された端末宛のパケットは、前記第１中継装置から前記第４中継装置までの経路において既に確立されているトンネルを用いて転送され、前記第４中継装置から前記第３中継装置までの経路において新たなトンネルを用いて転送される
請求項１に記載のネットワークシステム。
【請求項３】
前記第１中継装置と前記第２中継装置との間における前記パケットの転送経路上の各中継装置間にトンネルが確立されている状態において、前記端末が前記第２中継装置と切断され且つ前記第２中継装置と異なる、前記複数の中継装置に含まれる第３中継装置と接続された場合には、前記パケットの転送経路において前記第１中継装置と前記第２中継装置との間に位置する中継装置である第４中継装置が前記第３中継装置との間で新たなトンネルを確立し、
前記端末宛のパケットは、前記第１中継装置から前記第４中継装置までの経路において、既に確立されているトンネルを用いて転送され、前記第４中継装置から前記第３中継装置までの経路において新たなトンネルを用いて転送される
請求項１に記載のネットワークシステム。
【請求項４】
前記第１管理装置は、前記宛先アドレスに対応する、前記要求メッセージの転送先である管理装置アドレスを保持した記憶装置と、前記管理装置アドレスへ前記要求メッセージの転送するための処理を行うプロセッサとを含み、
前記要求メッセージを受信する前記第１管理装置以外の管理装置は、前記宛先アドレスに対応する、前記要求メッセージの転送先である管理装置アドレスと、前記要求メッセージに格納すべき１以上の中継装置アドレスと、自管理装置が前記第２管理装置か否かを示す情報とを保持する記憶装置と、自管理装置が前記第２管理装置でなければ、前記１以上の中継装置アドレスを前記要求メッセージに格納する一方で、前記管理装置アドレスへ前記要求メッセージを転送するための処理を行い、自管理装置が前記第２管理装置であれば、前記応答メッセージを生成して送信する処理を行うプロセッサとを含む、
請求項１から３の何れか１項に記載のネットワークシステム。
【請求項５】
前記応答メッセージを受信する、前記第２中継装置を除く前記各中継装置は、前記応答メッセージに格納された中継装置アドレスの１つと、トンネル識別情報と、前記宛先ＩＰアドレスとが関連づけられた情報を記憶装置に保持し、受信されるパケットの宛先アドレスに対応するトンネルへ当該パケットがカプセル化されたパケットを送信するための処理を行う装置を含む
請求項１から４の何れか１項に記載のネットワークシステム。
【請求項６】
前記複数の中継装置は、前記パケットの転送経路上に位置する所定の中継装置をルートとするツリー状のトポロジを有し、
前記第２中継装置は、前記複数の中継装置に含まれる第３中継装置とともにツリーのリーフに位置し、
前記第１中継装置と前記第２中継装置との間の各中継装置間でトンネルが夫々確立されている状態において、前記第３中継装置に接続された端末が、前記第２中継装置に接続された端末に対してパケットを送信する場合には、前記第１中継装置から前記第２中継装置へのパケットの転送経路において前記ルートに位置する中継装置と前記第２中継装置との間に位置する中継装置である第４中継装置が、前記第３中継装置との間でトンネルを構築し、第３中継装置からトンネルを通じて到達するパケットを前記第２中継装置の間で確立されているトンネルへ転送する
請求項１，４又は５に記載のネットワークシステム。
【請求項７】
前記要求メッセージを受信する前記第１管理装置以外の管理装置の少なくとも１つにおける記憶装置は、前記要求メッセージに格納すべき１以上の中継装置アドレスを前記要求メッセージに格納するか否かを判定するための判定用情報を保持し、前記プロセッサは、前記判定用情報に基づいて、１以上の中継装置アドレスの一部又は全部の格納，及び格納回避の何れかを行う
請求項４に記載のネットワークシステム。
【請求項８】
前記応答メッセージを受信する、前記第２中継装置を除く複数の中継装置の少なくとも１つは、前記応答メッセージに格納された特定の中継装置アドレスを削除するか否かの判定用情報を保持する記憶装置と、前記判定用情報に応じて前記特定の中継装置アドレスの削除又は削除回避を行う制御装置とを含む
請求項１に記載のネットワークシステム。
【請求項９】
前記第２管理装置から送信された応答メッセージは、前記応答メッセージに格納された複数の中継装置アドレスの前記パケットの通過順において、前記第２中継装置より１つ前に位置する中継装置で受信され、その後、前記パケットの通過順と逆順で、前記応答メッセージに格納された中継装置アドレスを有する各中継装置に転送される
請求項１に記載のネットワークシステム。
【請求項１０】
前記第２管理装置から送信された応答メッセージは、前記第２中継装置で受信され、前記第２中継装置は、前記応答メッセージに格納された複数の中継装置アドレスの前記パケットの通過順において、前記第２中継装置より１つ前に位置する中継装置へ転送され、その後、前記パケットの通過順と逆順で、前記応答メッセージに格納された中継装置アドレスを有する各中継装置に転送される
請求項１に記載のネットワークシステム。
【請求項１１】
パケットを受信する第１中継装置と、前記パケットの宛先アドレスを有する端末と接続された第２中継装置とを含む複数の中継装置と、
前記第１中継装置を管理する第１管理装置と、前記第２中継装置を管理する第２管理装置とを含む、前記複数の中継装置を管理する複数の管理装置とを備えるネットワークシステムにおける複数のトンネルの確立方法であって、
前記第１中継装置は、前記パケットの転送に用いる中継装置アドレスを解決するための、前記宛先アドレスを含む要求メッセージを前記第１管理装置へ送信し、
前記複数の管理装置は、前記要求メッセージが前記第１管理装置から前記第２管理装置へ到達するように、前記宛先アドレスに対応する転送情報に基づいて前記要求メッセージを転送するとともに、前記第１中継装置から前記第２中継装置へ到達する前記パケットが通過すべき１以上の中継装置の中継装置アドレスを前記要求メッセージに格納し、
前記第２管理装置は、前記要求メッセージに格納された複数の中継装置アドレスと、前記第２中継装置の中継装置アドレスを含む１以上の中継装置アドレスとが格納された応答メッセージを生成し、
前記応答メッセージに中継装置アドレスが格納された、前記第２中継装置を除く中継装置の夫々は、前記応答メッセージを受信し、前記応答メッセージに格納された中継装置アドレスを用いて、中継装置間の前記パケットの転送に使用されるトンネルを確立するとともに、少なくともトンネルの確立に用いた中継装置アドレスを前記応答メッセージから削除し、前記応答メッセージに残った１以上の中継装置アドレスの何れかへ前記応答メッセージを転送し、
前記応答メッセージを受信する前記第１中継装置は、前記応答メッセージに格納された中継装置アドレスを用いて次ホップに相当する中継装置との間でトンネルを確立し、
前記パケットは、前記第１中継装置、及び前記パケットが通過する中継装置の夫々から前記宛先アドレスに対応するトンネルへ送出されるときに、宛先中継装置アドレスを含むヘッダを用いてカプセル化される
ネットワークシステムにおける複数のトンネルの確立方法。
【請求項１２】
パケットの転送経路の起点に位置する起点中継装置と、前記転送経路の終点に位置する終点中継装置と、始点中継装置と終点中継装置との間に位置する１以上の中間中継装置とを含む複数の中継装置が中継装置間を結ぶパケット転送用のトンネルを夫々確立するネットワークシステムにおいて、前記複数の中継装置のアドレスを管理する複数の管理装置の１つである管理装置であって、
前記起点中継装置から送信され、且つ前記起点中継装置を管理する前記複数の管理装置の１つを経由した、前記終点中継装置のアドレスを解決するための要求メッセージを受信する受信部と、
前記要求メッセージに含まれたパケットの宛先アドレスに対応する、前記要求メッセージの転送先である管理装置アドレスと、前記要求メッセージに格納すべき１以上の中継装置アドレスと、自管理装置が前記終点中継装置を管理する終点管理装置か否かを示す情報と、を保持する記憶装置と、
自管理装置が前記終点管理装置でなければ、前記１以上の中継装置アドレスを前記要求メッセージに格納する一方で、前記管理装置アドレスへ前記要求メッセージを転送するための処理を行い、自管理装置が前記終点管理装置であれば、前記要求メッセージに対する
応答メッセージを生成して送信する処理を行うプロセッサと
を含む管理装置。
【請求項１３】
前記応答メッセージは、前記始点中継装置、前記終点中継装置、及び前記１以上の中間中継装置の中継装置アドレスを含み、前記終点管理装置から前記終点中継装置、又は前記終点中継装置に隣接する中間中継装置に転送される
請求項１２に記載の管理装置。
【請求項１４】
前記記憶装置は、前記要求メッセージに格納すべき１以上の中継装置アドレスを前記要求メッセージに格納するか否かを判定するための判定用情報を保持し、
前記プロセッサは、前記判定用情報に基づいて、前記１以上の中継装置アドレスの一部又は全部の格納及び格納回避の何れかを行う
請求項１２又は１３に記載の管理装置。
【請求項１５】
パケットの転送経路の起点に位置する起点中継装置と、前記転送経路の終点に位置する終点中継装置と、始点中継装置と終点中継装置との間に位置する１以上の中間中継装置とを含む複数の中継装置が中継装置間を結ぶパケット転送用のトンネルを夫々確立するネットワークシステムにおいて、前記中間中継装置となる中継装置であって、
前記始点中継装置から送信された、前記終点中継装置の中継装置アドレスを解決するための要求メッセージに対する応答メッセージであって、中継装置自身の下流側に位置する隣接中継装置から前記始点中継装置までの各中継装置の中継装置アドレスが格納された応答メッセージを受信する受信部と、
前記応答メッセージ中の前記隣接中継装置の中継装置アドレスを用いて、前記隣接中継装置との間でトンネルを確立し、前記応答メッセージから前記隣接中継装置の中継装置アドレスを削除し、且つ中継装置自身の上流側に位置する中継装置へ前記応答メッセージを転送する処理を行う制御装置と
を含む中継装置。
【請求項１６】
前記応答メッセージに格納された特定の中継装置アドレスを削除するか否かの判定用情報を保持する記憶装置をさらに含み、
前記制御装置は、前記判定用情報に応じて前記特定の中継装置アドレスの削除又は削除回避を行う
請求項１５に記載の中継装置。
【請求項１】
パケットを受信する第１中継装置と、前記パケットの宛先アドレスを有する端末と接続された第２中継装置とを含む複数の中継装置と、
前記第１中継装置を管理する第１管理装置と、前記第２中継装置を管理する第２管理装置とを含む、前記複数の中継装置を管理する複数の管理装置とを備え、
前記第１中継装置は、前記パケットの転送に用いる中継装置アドレスを解決するための、前記宛先アドレスを含む要求メッセージを前記第１管理装置へ送信し、
前記複数の管理装置は、前記要求メッセージが前記第１管理装置から前記第２管理装置へ到達するように、前記宛先アドレスに対応する転送情報に基づいて前記要求メッセージを転送するとともに、前記第１中継装置から前記第２中継装置へ到達する前記パケットが通過すべき１以上の中継装置の中継装置アドレスを前記要求メッセージに格納し、
前記第２管理装置は、前記要求メッセージに格納された複数の中継装置アドレスと、前記第２中継装置の中継装置アドレスを含む１以上の中継装置アドレスとが格納された応答メッセージを生成し、
前記応答メッセージに中継装置アドレスが格納された、前記第２中継装置を除く中継装置の夫々は、前記応答メッセージを受信し、前記応答メッセージに格納された中継装置アドレスを用いて、中継装置間の前記パケットの転送に使用されるトンネルを確立するとともに、少なくともトンネルの確立に用いた中継装置アドレスを前記応答メッセージから削除し、前記応答メッセージに残った１以上の中継装置アドレスの何れかへ前記応答メッセージを転送し、
前記応答メッセージを受信する前記第１中継装置は、前記応答メッセージに格納された中継装置アドレスを用いて次ホップに相当する中継装置との間でトンネルを確立し、
前記パケットは、前記第１中継装置、及び前記パケットが通過する中継装置の夫々から前記宛先アドレスに対応するトンネルへ送出されるときに、宛先中継装置アドレスを含むヘッダを用いてカプセル化される
ネットワークシステム。
【請求項２】
前記第１中継装置と前記第２中継装置との間における前記パケットの転送経路上の各中継装置間にトンネルが確立されている状態において、前記第２中継装置と異なる、前記複数の中継装置に含まれる第３中継装置に接続された端末宛のパケットを前記第１中継装置が受信した場合には、前記パケットの転送経路において前記第１中継装置と前記第２中継装置との間に位置する中継装置である第４中継装置が前記第３中継装置との間で新たなトンネルを確立し、
前記第３中継装置に接続された端末宛のパケットは、前記第１中継装置から前記第４中継装置までの経路において既に確立されているトンネルを用いて転送され、前記第４中継装置から前記第３中継装置までの経路において新たなトンネルを用いて転送される
請求項１に記載のネットワークシステム。
【請求項３】
前記第１中継装置と前記第２中継装置との間における前記パケットの転送経路上の各中継装置間にトンネルが確立されている状態において、前記端末が前記第２中継装置と切断され且つ前記第２中継装置と異なる、前記複数の中継装置に含まれる第３中継装置と接続された場合には、前記パケットの転送経路において前記第１中継装置と前記第２中継装置との間に位置する中継装置である第４中継装置が前記第３中継装置との間で新たなトンネルを確立し、
前記端末宛のパケットは、前記第１中継装置から前記第４中継装置までの経路において、既に確立されているトンネルを用いて転送され、前記第４中継装置から前記第３中継装置までの経路において新たなトンネルを用いて転送される
請求項１に記載のネットワークシステム。
【請求項４】
前記第１管理装置は、前記宛先アドレスに対応する、前記要求メッセージの転送先である管理装置アドレスを保持した記憶装置と、前記管理装置アドレスへ前記要求メッセージの転送するための処理を行うプロセッサとを含み、
前記要求メッセージを受信する前記第１管理装置以外の管理装置は、前記宛先アドレスに対応する、前記要求メッセージの転送先である管理装置アドレスと、前記要求メッセージに格納すべき１以上の中継装置アドレスと、自管理装置が前記第２管理装置か否かを示す情報とを保持する記憶装置と、自管理装置が前記第２管理装置でなければ、前記１以上の中継装置アドレスを前記要求メッセージに格納する一方で、前記管理装置アドレスへ前記要求メッセージを転送するための処理を行い、自管理装置が前記第２管理装置であれば、前記応答メッセージを生成して送信する処理を行うプロセッサとを含む、
請求項１から３の何れか１項に記載のネットワークシステム。
【請求項５】
前記応答メッセージを受信する、前記第２中継装置を除く前記各中継装置は、前記応答メッセージに格納された中継装置アドレスの１つと、トンネル識別情報と、前記宛先ＩＰアドレスとが関連づけられた情報を記憶装置に保持し、受信されるパケットの宛先アドレスに対応するトンネルへ当該パケットがカプセル化されたパケットを送信するための処理を行う装置を含む
請求項１から４の何れか１項に記載のネットワークシステム。
【請求項６】
前記複数の中継装置は、前記パケットの転送経路上に位置する所定の中継装置をルートとするツリー状のトポロジを有し、
前記第２中継装置は、前記複数の中継装置に含まれる第３中継装置とともにツリーのリーフに位置し、
前記第１中継装置と前記第２中継装置との間の各中継装置間でトンネルが夫々確立されている状態において、前記第３中継装置に接続された端末が、前記第２中継装置に接続された端末に対してパケットを送信する場合には、前記第１中継装置から前記第２中継装置へのパケットの転送経路において前記ルートに位置する中継装置と前記第２中継装置との間に位置する中継装置である第４中継装置が、前記第３中継装置との間でトンネルを構築し、第３中継装置からトンネルを通じて到達するパケットを前記第２中継装置の間で確立されているトンネルへ転送する
請求項１，４又は５に記載のネットワークシステム。
【請求項７】
前記要求メッセージを受信する前記第１管理装置以外の管理装置の少なくとも１つにおける記憶装置は、前記要求メッセージに格納すべき１以上の中継装置アドレスを前記要求メッセージに格納するか否かを判定するための判定用情報を保持し、前記プロセッサは、前記判定用情報に基づいて、１以上の中継装置アドレスの一部又は全部の格納，及び格納回避の何れかを行う
請求項４に記載のネットワークシステム。
【請求項８】
前記応答メッセージを受信する、前記第２中継装置を除く複数の中継装置の少なくとも１つは、前記応答メッセージに格納された特定の中継装置アドレスを削除するか否かの判定用情報を保持する記憶装置と、前記判定用情報に応じて前記特定の中継装置アドレスの削除又は削除回避を行う制御装置とを含む
請求項１に記載のネットワークシステム。
【請求項９】
前記第２管理装置から送信された応答メッセージは、前記応答メッセージに格納された複数の中継装置アドレスの前記パケットの通過順において、前記第２中継装置より１つ前に位置する中継装置で受信され、その後、前記パケットの通過順と逆順で、前記応答メッセージに格納された中継装置アドレスを有する各中継装置に転送される
請求項１に記載のネットワークシステム。
【請求項１０】
前記第２管理装置から送信された応答メッセージは、前記第２中継装置で受信され、前記第２中継装置は、前記応答メッセージに格納された複数の中継装置アドレスの前記パケットの通過順において、前記第２中継装置より１つ前に位置する中継装置へ転送され、その後、前記パケットの通過順と逆順で、前記応答メッセージに格納された中継装置アドレスを有する各中継装置に転送される
請求項１に記載のネットワークシステム。
【請求項１１】
パケットを受信する第１中継装置と、前記パケットの宛先アドレスを有する端末と接続された第２中継装置とを含む複数の中継装置と、
前記第１中継装置を管理する第１管理装置と、前記第２中継装置を管理する第２管理装置とを含む、前記複数の中継装置を管理する複数の管理装置とを備えるネットワークシステムにおける複数のトンネルの確立方法であって、
前記第１中継装置は、前記パケットの転送に用いる中継装置アドレスを解決するための、前記宛先アドレスを含む要求メッセージを前記第１管理装置へ送信し、
前記複数の管理装置は、前記要求メッセージが前記第１管理装置から前記第２管理装置へ到達するように、前記宛先アドレスに対応する転送情報に基づいて前記要求メッセージを転送するとともに、前記第１中継装置から前記第２中継装置へ到達する前記パケットが通過すべき１以上の中継装置の中継装置アドレスを前記要求メッセージに格納し、
前記第２管理装置は、前記要求メッセージに格納された複数の中継装置アドレスと、前記第２中継装置の中継装置アドレスを含む１以上の中継装置アドレスとが格納された応答メッセージを生成し、
前記応答メッセージに中継装置アドレスが格納された、前記第２中継装置を除く中継装置の夫々は、前記応答メッセージを受信し、前記応答メッセージに格納された中継装置アドレスを用いて、中継装置間の前記パケットの転送に使用されるトンネルを確立するとともに、少なくともトンネルの確立に用いた中継装置アドレスを前記応答メッセージから削除し、前記応答メッセージに残った１以上の中継装置アドレスの何れかへ前記応答メッセージを転送し、
前記応答メッセージを受信する前記第１中継装置は、前記応答メッセージに格納された中継装置アドレスを用いて次ホップに相当する中継装置との間でトンネルを確立し、
前記パケットは、前記第１中継装置、及び前記パケットが通過する中継装置の夫々から前記宛先アドレスに対応するトンネルへ送出されるときに、宛先中継装置アドレスを含むヘッダを用いてカプセル化される
ネットワークシステムにおける複数のトンネルの確立方法。
【請求項１２】
パケットの転送経路の起点に位置する起点中継装置と、前記転送経路の終点に位置する終点中継装置と、始点中継装置と終点中継装置との間に位置する１以上の中間中継装置とを含む複数の中継装置が中継装置間を結ぶパケット転送用のトンネルを夫々確立するネットワークシステムにおいて、前記複数の中継装置のアドレスを管理する複数の管理装置の１つである管理装置であって、
前記起点中継装置から送信され、且つ前記起点中継装置を管理する前記複数の管理装置の１つを経由した、前記終点中継装置のアドレスを解決するための要求メッセージを受信する受信部と、
前記要求メッセージに含まれたパケットの宛先アドレスに対応する、前記要求メッセージの転送先である管理装置アドレスと、前記要求メッセージに格納すべき１以上の中継装置アドレスと、自管理装置が前記終点中継装置を管理する終点管理装置か否かを示す情報と、を保持する記憶装置と、
自管理装置が前記終点管理装置でなければ、前記１以上の中継装置アドレスを前記要求メッセージに格納する一方で、前記管理装置アドレスへ前記要求メッセージを転送するための処理を行い、自管理装置が前記終点管理装置であれば、前記要求メッセージに対する
応答メッセージを生成して送信する処理を行うプロセッサと
を含む管理装置。
【請求項１３】
前記応答メッセージは、前記始点中継装置、前記終点中継装置、及び前記１以上の中間中継装置の中継装置アドレスを含み、前記終点管理装置から前記終点中継装置、又は前記終点中継装置に隣接する中間中継装置に転送される
請求項１２に記載の管理装置。
【請求項１４】
前記記憶装置は、前記要求メッセージに格納すべき１以上の中継装置アドレスを前記要求メッセージに格納するか否かを判定するための判定用情報を保持し、
前記プロセッサは、前記判定用情報に基づいて、前記１以上の中継装置アドレスの一部又は全部の格納及び格納回避の何れかを行う
請求項１２又は１３に記載の管理装置。
【請求項１５】
パケットの転送経路の起点に位置する起点中継装置と、前記転送経路の終点に位置する終点中継装置と、始点中継装置と終点中継装置との間に位置する１以上の中間中継装置とを含む複数の中継装置が中継装置間を結ぶパケット転送用のトンネルを夫々確立するネットワークシステムにおいて、前記中間中継装置となる中継装置であって、
前記始点中継装置から送信された、前記終点中継装置の中継装置アドレスを解決するための要求メッセージに対する応答メッセージであって、中継装置自身の下流側に位置する隣接中継装置から前記始点中継装置までの各中継装置の中継装置アドレスが格納された応答メッセージを受信する受信部と、
前記応答メッセージ中の前記隣接中継装置の中継装置アドレスを用いて、前記隣接中継装置との間でトンネルを確立し、前記応答メッセージから前記隣接中継装置の中継装置アドレスを削除し、且つ中継装置自身の上流側に位置する中継装置へ前記応答メッセージを転送する処理を行う制御装置と
を含む中継装置。
【請求項１６】
前記応答メッセージに格納された特定の中継装置アドレスを削除するか否かの判定用情報を保持する記憶装置をさらに含み、
前記制御装置は、前記判定用情報に応じて前記特定の中継装置アドレスの削除又は削除回避を行う
請求項１５に記載の中継装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【公開番号】特開２０１３−６６１７１（Ｐ２０１３−６６１７１Ａ）
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願番号】特願２０１２−１８３０８１（Ｐ２０１２−１８３０８１）
【出願日】平成２４年８月２２日（２０１２．８．２２）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願日】平成２４年８月２２日（２０１２．８．２２）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]