JP5640982B2 - 通信システム、転送ノード、経路管理サーバ、通信方法およびプログラム - Google Patents

Description

［関連出願についての記載］
本発明は、日本国特許出願：特願２００９−２１２２２１号（２００９年９月１４日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信システム、転送ノード、経路管理サーバ、通信方法およびプログラムに関し、特に、ネットワークに配置された転送ノードによりパケットを転送して通信を実現する通信システム、転送ノード、経路管理サーバ、通信方法およびプログラムに関する。

図２０にＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を使ったネットワーク構成を示す。図２０において、通信ノード１００（通信ノード１００ａおよび通信ノード１００ｂ）は、ＩＰを使って通信を行う通信ノードである。転送ノード２００は、通信ノード１００が送信したＩＰパケットを受信した際に、前記ＩＰパケットの転送先を決定し、決定された転送先に転送する。転送ノードは、これを繰り返し、最終的に宛先とする通信ノードにＩＰパケットを転送する。

前記ＩＰパケットの転送先の決定には、転送ノード２００が内部に保持するルーティングテーブルが使用される。ルーティングテーブルとは、どのネットワーク宛のパケットを、どのインタフェースを介して次の転送処理を担う転送ノードに送れば良いかを示すテーブルであり、宛先ネットワークアドレス、次の転送先のＩＰアドレス、送信先とするインタフェースの対応を１つのエントリとして、これを列挙したテーブルである。エントリには前述した情報以外の情報も含むが、ここでは簡単のため省略する。

前記ネットワークアドレスとは、ＩＰアドレスの内、上位から一部のビット数を抜き出したアドレスであり、例えば、１９２．１６８．１．０／２４といった形式で表現される。この場合、アドレスの上位２４ｂｉｔがネットワークアドレスであり、当該ネットワークには、１９２．１６８．１．１から１９２．１６８．１．２５５までのアドレスが含まれる。このとき、２４をプレフィクス長と呼ぶ。

転送ノード２００は、ルーティングテーブルから適切なルート情報を決定する際に、ロンゲストマッチという方法を使用する。これは、ＩＰパケットの宛先アドレスとルーティングテーブルの個々のエントリを比較し、前記宛先アドレスの上位ビットから、より長いビット数が一致したものに決定するという方法である。

前記ルーティングテーブルは、転送ノード２００に手動などの方法により事前に設定するか、ルーティングプロトコルと呼ばれるルート情報を交換するプロトコルにより自動的に設定される。

ＩＰネットワークでは、以上の転送方式によりパケットを転送するが、この場合パケットの転送は、個々の転送ノードのルーティングテーブルに依存し、経路を完全には制御できないという問題点がある。また、宛先アドレスのみで転送先を決定するので、送信元アドレスや、どのアプリケーションによる通信か、といった違いによる緻密な経路制御ができない問題点もある。

上記経路制御を行う方式として、ソースルーティングという手法が存在する。ソースルーティングとは、送信元となるノード（例えば、通信ノード１００ａ）が、転送経路としたい転送ノード２００のアドレスを送信パケット中に明示的に列挙する方法である。この場合、通信ノード１００ａは使用するアプリケーションなどにより意図した転送経路で宛先とするノード（例えば、通信ノード１００ｂ）にパケットを転送することができる。

また、ＭＰＬＳ（Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）というパケット転送技術にも、ソースルーティングに相当する技術が存在する。ＭＰＬＳは、受信したパケットに対してラベルを付与し、ラベルに基づいて転送処理を行う技術である。

前記ラベルの付与は、パケットがＭＰＬＳネットワークの境界に配置された転送ノードに入力された後、当該パケットを転送する際に実施され、以降ＭＰＬＳネットワーク内の転送ノードは、当該パケット転送するたびラベルを張り替えながら、転送処理を繰り返す。そして、ＭＰＬＳネットワークの境界に配置された転送ノードにより外部のネットワークへ転送される際に、当該転送ノードによりラベルが除去される。

ＭＰＬＳにおける、ソースルーティングに相当する技術とは、ＣＲ−ＬＤＰ（Ｃｏｎｓｔｒａｉｎｔ Ｒｏｕｔｉｎｇ−Ｌａｂｅｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）である。ＬＤＰは、ＭＰＬＳネットワーク内の転送ノード間で前記ラベルを交換するためのプロトコルであるが、トラフィック・エンジニアリングなどの目的で、パケットの転送経路を厳密に指定することを目的としたＬＤＰがＣＲ−ＬＤＰである。

特許文献１には、アドホックネットワークにおいて、すべての移動端末装置が、隣接する移動端末装置との間のリンク情報を送信するのではなく、クラスタヘッドとなった移動端末装置のみがリンク情報を送信することによって制御パケットの総量を削減できる方法が開示されている。

また同じく経路制御を行うものとして、非特許文献１にオープンフロー（ＯｐｅｎＦｌｏｗ）という技術が提案されている。オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行うものである。転送ノードとして機能するオープンフロースイッチは、オープンフローコントローラとの通信用のセキュアチャネルを備え、オープンフローコントローラから適宜追加または書き換え指示されるフローテーブルに従って動作する。フローテーブルには、フロー毎に、パケットヘッダと照合するルールと、処理内容を定義したアクションと、フロー統計情報との組が定義される。

例えば、オープンフロースイッチは、最初のパケット（ｆｉｒｓｔ ｐａｃｋｅｔ）を受信すると、フローテーブルから、受信パケットのヘッダ情報に適合するルール（ＦｌｏｗＫｅｙ）を持つエントリを検索する。検索の結果、受信パケットに適合するエントリが見つかった場合、オープンフロースイッチは、受信パケットに対して、当該エントリのアクションフィールドに記述された処理内容を実施する。一方、前記検索の結果、受信パケットに適合するエントリが見つからなかった場合、オープンフロースイッチは、セキュアチャネルを介して、オープンフローコントローラに対して受信パケットを転送し、受信パケットの送信元・送信先に基づいたパケットの経路の決定を依頼し、これを実現するフローエントリを受け取ってフローテーブルを更新する。

特開２００７−２３５４４４号公報

Nick McKeownほか７名、"OpenFlow: Enabling Innovation in Campus Networks"、［online］、［平成21年7月17日検索］、インターネット〈URL：http://www.openflowswitch.org//documents/openflow-wp-latest.pdf〉

上記特許文献１及び非特許文献１の全開示内容はその引用をもって本書に繰込み記載する。
以下に本発明による関連技術の分析を与える。
ＩＰ技術に基づく転送ノード、すなわちスイッチやルータが保持するルーティングテーブルは増大の一途をたどり、ルート情報の爆発と呼ばれる問題が指摘されている。ルート増大の結果、ルーティングテーブルを保持するためのメモリの必要量が増えるとともに、ルート決定処理に時間がかかるため、パケット転送処理能力が劣化する。

ＭＰＬＳは、ＩＰルーティングと比してルート決定時間が削減できるものの、多様な転送ポリシを適用すれば、やはりルーティングテーブルのエントリ数は増大し、処理性能の劣化につながる。

以上のように、ルーティングテーブルのエントリ数の抑制は、メモリ削減や処理能力向上の観点で転送ノードの重要な課題となっている。

一方、上記したソースルーティングでは、パケット中に転送ノード１００のアドレスを格納するため、パケットが含むことができる正味のデータ量が小さくなってしまうという問題点がある。このため、ソースルーティングは、ネットワークの試験など一部の用途に限られ、アプリケーションなどの通信で使われるパケット（これを以降「データパケット」と呼称する。）には使用されない。なお、正味のデータ以外の情報をオーバヘッドと呼ぶ。すなわち、前述の問題は、オーバヘッドが大きくなる問題と言い換えられる。

また、ＣＲ−ＬＤＰで使われるパケット中には、前述のＩＰルーティングにおけるソースルーティングと同様に、転送毎（１ｈｏｐ毎）の転送ノードの情報が含まれる。転送ノードの情報としては、例えばＩＰｖ４アドレスやＩＰｖ６アドレスが使われるが、この場合も転送経路中のすべての転送ノードの情報を列挙する場合は当該情報が大きくなるため、制御用パケット以外に用いるのは現実的ではない。結果として、データパケットの転送経路を厳密に決定する際には、前記ＣＲ−ＬＤＰなどで、転送ポリシごとの転送情報を転送ノード内に設定する必要が生じる。

特許文献１の方法は、移動通信ネットワークの基盤となる設備を要せず、複数の移動端末装置のみで構成されるアドホックネットワークに関するものである。ネットワークの構成も絶えず変わりうるため、上記したソースルーティングのような送信元が経路を指定できる経路制御を実現するものではない。

また、非特許文献１の方法は、冒頭に述べたルーティングテーブルを参照する方式と同様に、個々の転送ノードが、フローテーブルを参照する必要があり、エントリの増大に従って、レイテンシ（遅延時間）の発生やノードへの負荷が掛かってしまうことが考えられる。

以上説明したように、ルーティングテーブルやフローテーブルに様々な転送ポリシごとのエントリを追加する方式は、エントリの追加・更新・削除の処理負荷と、ルーティングテーブルの情報量が増大するという問題点があり、転送経路を明示的に指定するソースルーティング等は、オーバヘッドが大きくなり、データパケットの送信には適さないという問題点がある。

本発明は、上記した事情に鑑みてなされたものであって、その目的とするところは、簡略化された転送テーブルを用いて実現可能であり、しかも、データパケットの経路制御にも適用できる通信システム、転送ノード、経路管理サーバ、通信方法およびプログラムを提供することにある。

本発明の第１の視点によれば、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を含む転送経路情報を構成する経路管理サーバと、前記転送経路情報を格納したヘッダが付加されたパケットを、前記転送経路情報に従って転送する転送ノードと、を含み、前記転送ノードのうち、外部ネットワークとの境界に位置する転送ノードが、前記外部ネットワークから受信したパケットへの前記転送経路情報を格納したヘッダの付加または前記外部ネットワークへ送信するパケットから前記転送経路情報を格納したヘッダの削除を行うヘッダ操作部を備える通信システムが提供される。

本発明の第２の視点によれば、第一のネットワークと第二のネットワークとの境界に配置される境界転送ノードであって、前記第一のネットワークに配置された転送ノードと通信可能な第一の手段と、前記転送ノードの通信インターフェースまたは前記転送ノード間のリンクを識別するための識別子を含む転送経路情報を格納したヘッダを前記第二のネットワークから受信したパケットに付加する第一の処理、または、前記ヘッダを前記第二のネットワークに送信するパケットから削除する第二の処理の少なくとも一つを実行する第二の手段とを備える境界転送ノードが提供される。

本発明の第３の視点によれば、送信元の通信ノードから送信されたパケットに付加するためのヘッダに含める転送経路情報を作成して提供する経路管理サーバが提供される。

本発明の第４の視点によれば、第一のネットワークと第二のネットワークとの境界に配置される境界転送ノードの通信方法であって、前記第一のネットワークに配置された転送ノードと通信し、前記転送ノードの通信インターフェースまたは前記転送ノード間のリンクを識別するための識別子を含む転送経路情報を格納したヘッダを前記第二のネットワークから受信したパケットに付加する第一の処理、または、前記ヘッダを前記第二のネットワークに送信するパケットから削除する第二の処理の少なくとも一つを実行する通信方法が提供される。本方法は、データ転送ネットワークを構成する転送ノードという、特定の機械に結びつけられている。

本発明の第５の視点によれば、上記した転送ノード、経路管理サーバを構成するコンピュータに実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明によれば、膨大なボリュームの転送テーブルを用いずに、しかも、正味データ量を圧迫しない、パケットの経路制御が可能となる。その理由は、転送ノードがパケットヘッダに含まれる転送経路情報に従ってパケット転送処理を実行するように構成するとともに、その転送経路情報を、通信インタフェースまたはリンクの識別子を並べた構成としたことにある。

本発明の第１の実施形態に係る通信システムを示す図である。 本発明の第１の実施形態に係る通信システムの境界転送ノードの構成を示す図である。 境界転送ノードおよび内部転送ノードの記録部に記録される転送テーブルを示す図である。 境界転送ノードにて付加される経路転送ヘッダのフォーマットの例である。 本発明の第１の実施形態に係る通信システムの内部転送ノードの構成を示す図である。 本発明の第１の実施形態に係る通信システムの経路管理サーバの構成を示す図である。 各転送ノードからの近隣情報を示す図である。 図７の近隣情報から構築したネットワークトポロジの例である。 境界転送ノードがパケットを受信した際の動作を示すフローチャートである。 図９の転送処理の詳細を示すフローチャートである。 内部転送ノードがパケットを受信した際の動作を示すフローチャートである。 境界転送ノードおよび内部転送ノードが近隣情報通知を送信する動作を示すフローチャートである。 経路管理サーバが近隣情報通知を受信した際の動作を示すフローチャートである。 経路管理サーバが経路情報を要求された際の動作を示すフローチャートである。 通信ノードが、パケットを対向の通信ノードに送信した際のパケット転送の流れを示すシーケンス図である。 本発明の第２の実施形態に係る通信システムの境界転送ノードの構成を示す図である。 本発明の第２の実施形態の境界転送ノードがパケットを受信した際の動作を示すフローチャートである。 本発明の第２の実施形態の境界転送ノードまたは内部転送ノードが含む経路情報キャッシュの内容を示す図である。 本発明の第２の実施形態の通信システムにおいて、通信ノードが受信したパケットの送信元にパケット送信した際のパケット転送の流れを示すシーケンス図である。 背景技術として説明する、パケット転送を行う通信システムを示す図である。

はじめに、本発明の概要を説明する。本発明の通信システムの転送ノードは、受信パケットに、転送経路情報が含まれるヘッダが付与されている場合、ヘッダ内の経路情報に基づき転送処理を実施する。

ここで、前記転送経路は、転送経路上に配置された各々の転送ノードが転送先とする通信インタフェースを識別可能な識別子を転送順に並べたものとすることができる。前記識別子は、各転送ノード内で、転送先の一意性を確保するに足る長さがあればよい。

冒頭に述べたソースルーティングと異なり、本発明の転送経路情報を構成する識別子は、例えば１バイト長などの短い情報で記述することが可能となるため、正味のデータ量に与える影響は軽微である。従って、一部の制御用パケットのみならず、データパケットなど、すべてのパケットに対して、転送経路を１ｈｏｐ毎に記述した情報を格納することが可能となり、高度な転送制御が可能となる。

さらに、個々の転送ノードは、前記識別子と、転送先の通信インタフェースとの対応関係を保持すればよく、膨大な数となる冒頭に述べたルーティングテーブル等の転送テーブルを保持する必要はないため、メモリ量が削減できる。また、転送先の決定も、簡単かつ高速に行えるため、パケットの転送遅延も小さくすることが可能となる。さらに、個々の転送ノードのＣＰＵの処理能力も低くて済む。

なお、上記転送経路情報を含んだヘッダの付加および削除は、転送ノードのうち、外部ネットワークとの境界に配置された転送ノード（境界転送ノード）に次のように実行させればよい。外部ネットワークからパケットを受信した境界転送ノードは、当該パケットの転送経路を、別途設けられた経路管理サーバまたは当該境界転送ノード内に記録された情報から取得し、前記転送経路の情報を格納したヘッダを受信したパケットに付与する。また、境界転送ノードは、外部ネットワークにパケットを送信する場合、前記ヘッダを削除する。

［第１の実施形態］
続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。図１は、本発明の第１の実施形態に係る通信システムを示す図である。図１を参照すると、通信ノード１００ａ、１００ｂと、境界転送ノード３００ａ、３００ｂと、内部転送ノード４００と、経路管理サーバ５００とが示されている。

データ転送ネットワーク６００は、本発明の方式によりパケットの転送処理を行うネットワークであり、外部ネットワーク７００は、ＩＰネットワークなどのように、ネットワーク６００とは異なる方式によりパケット転送処理を実施するネットワークである。ただし、ネットワーク６００と同様の転送方式を使っている場合も、管理者が異なる場合は外部ネットワーク７００となり得る。ここでは外部ネットワーク７００は、ＩＰネットワークとした説明を行う。外部ネットワーク７００は、データ転送ネットワーク６００と、境界転送ノード３００ａ、３００ｂを介して接続される。

通信ノード１００ａ、１００ｂは、それぞれ外部ネットワーク７００に属する通信ノードであり、外部ネットワーク７００のパケット転送方式に沿ったパケットの送受信を行う。つまり、本実施形態においてはＩＰパケットの送受信を行うノードである。通信ノード１００ａ、１００ｂは、一般的なＩＰノードと同様であるので詳細な説明は省略する。

境界転送ノード３００ａ、３００ｂは、データ転送ネットワーク６００と外部ネットワーク７００との間に配置され、通信ノード１００ａ、１００ｂから送信されたパケットを受信した場合には、後述の転送経路情報を含むヘッダ（以降、「経路情報ヘッダ」と呼称する。）を付与し、さらにヘッダ中の転送経路情報に基づきデータ転送ネットワーク６００内の内部転送ノード４００に当該パケットを転送する。

また、境界転送ノード３００ａ、３００ｂは、内部転送ノード４００から送られたパケットを受信した場合であってそのヘッダ中の転送経路情報からデータ転送ネットワーク６００内の最後の転送経路であると判定された場合、受信したパケットから前記ヘッダを削除し、その後、外部ネットワーク７００の通信ノード１００ａ、１００ｂ側にパケットを送信する。

なお、以下の説明では、転送経路情報は、経路管理サーバ５００から取得するものとして説明するが、これに拘らず、境界転送ノード３００内に保持した情報により転送経路情報を生成しても良い。

以下、本実施形態の境界転送ノード３００ａ（３００ｂ）、内部転送ノード４００、経路監視サーバ５００の順に、その構成を説明する。

図２は、図１の境界転送ノード３００ａ、３００ｂの構成を示す図である。図２に示すとおり、境界転送ノード３００は、通信インタフェース３１０と、パケット転送部３２０と、ヘッダ操作部３３０と、ローカルＩＤ決定部３４０と、近隣情報通知部３５０と、経路取得部３６０と、記録部３７０とを備えて構成される。

通信インタフェース３１０は、パケットの送受信を行うためのインタフェースであり、例えばＬＡＮカードのようなＮｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ（ＮＩＣ）と、それを動作させるソフトウェア（ドライバ）により実現される。ただし、前記のような物理的なインタフェースのみならず、論理的なインタフェースであっても良い。この場合、物理的なインタフェース１つを使って、複数のインタフェースを備えているように動作させることができる。

境界転送ノード３００は、上記のような１つ以上の物理インタフェース、あるいは論理インタフェースを備える。各々の通信インタフェース３１０は、データ転送ネットワーク内の内部転送ノード４００や他の境界転送ノード３００と接続される。また、一部の通信インタフェース３１０は、外部ネットワーク７００の通信ノード１００とも接続される。さらに、一部の通信インタフェース３１０は、経路管理サーバ５００とも接続される。経路管理サーバ５００は、データ転送ネットワーク６００内に配置していても構わないし、経路管理サーバ５００専用のネットワークを介して接続することとしても構わない。

パケット転送部３２０は、受信パケットに経路情報ヘッダが付与されていた場合、前記経路情報ヘッダと、記録部３７０に記録された情報に基づき、パケットを転送する機能を備える。

記録部３７０には、図３に示すとおり、ローカルＩＤと、転送先とする通信インタフェースと、当該通信インタフェース３１０と接続している近隣の境界転送ノード３００、あるいは内部転送ノード４００の識別子の対応情報を１つのエントリとした転送テーブルが記録されている。パケット転送部３２０は、前記ローカルＩＤに対応する次ノードにパケットを転送することができる。

なお、以降では、境界転送ノード３００と内部転送ノード４００の総称を転送ノードとする。また、直接接続しているノード（通信ノード１００、境界転送ノード３００、内部転送ノード４００）同士を近隣ノードと呼称する。

図３は、境界転送ノード３００および内部転送ノード４００の記録装置に記録される転送テーブルを示す図である。本実施形態では、図３に示すとおり、ローカルＩＤとして、隣接する転送ノード間あるいは境界転送ノード３００と通信ノード１００ａ（１００ｂ）間の、物理リンクあるいは論理リンクに割当てた識別子（リンクＩＤ）を使用する。したがって、「ローカルＩＤ」のフィールドには前記リンクＩＤが設定される。転送先とする通信インタフェースを示す「インタフェース」のフィールドには、リンクＩＤが割当てられたリンクに接続した通信インタフェース３１０を識別する情報が設定される。また、図３の例では、近隣ノードの情報を示す「次ホップ」のフィールドに、前記リンクに接続された転送ノードの識別子が設定されている。

なお、転送先とする通信インフェースがＩＰにより通信を行う通信ノード１００ａ（１００ｂ）と接続されていた場合は、「次ホップ」のフィールドの識別子として、例えば、通信ノード１００ａ（１００ｂ）のＩＰアドレスを使用できる。一方、境界転送ノード３００、あるいは内部転送ノード４００の場合は、一意に割当てた識別子（例えば、図３のＮｏｄｅ＿１、Ｎｏｄｅ＿２等）を使用する。前記転送ノードの識別子は、事前に設定することとしても良いし、経路管理サーバ５００など、外部のノードから設定する方式としても構わない。さらに、前記「次ホップ」フィールドの識別子は、転送処理に必ず必要なわけではなく、省略することもできる。

また、ローカルＩＤとして、通信インタフェース３１０を識別する情報そのものを使うこともできる。通信インタフェース３１０を識別する情報は、短い情報量（例えば、１〜２バイト程度）で記述できる情報であることが望ましいため、通信インタフェース３１０を識別する情報が長い場合（例えば、通信インタフェースの名前などを使う場合）は、１バイトなど短い情報で記述できる別の識別子を別途割り振った上でローカルＩＤとして適用する。ただし、ここでは特に説明しない場合、ローカルＩＤとしてリンクＩＤを使用するものとして説明する。

一般的なレイヤ３で転送処理を行うルータやＬ３スイッチ、また、レイヤ２での転送処理を行うＬ２スイッチが備えている通信インタフェースは基本的に数十個程度であるため、リンクの識別子や通信インタフェースの識別子は、１バイトで十分表現できる。実際の通信インタフェースの識別子が数バイトを要するような長い情報である場合は、１バイト、あるいは２バイトに格納可能な範囲とした識別子を別途作成し、通信インタフェースの識別子に対応づければよい。

なお、図３の転送テーブルは、本発明を端的説明するために例示したものであり、個々のエントリに、他の情報をさらに対応づけて記録することとしても構わない。

図４は、本実施形態で用いる経路情報ヘッダのフォーマットの１例である。図４において、’Ｄｉｒｅｃｔｉｏｎ’は転送方向を示す。例えば、’１’なら順方向の転送を示し、’２’なら逆方向の転送を示す。’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’は、転送時に参照すべきローカルＩＤ情報のオフセット情報が設定される（単位はバイト）。この値は、’ＬｏｃａｌＩＤ ＃０’からのオフセットバイト数で示される。境界転送ノード３００で経路情報ヘッダを付与する際には、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’の値は’０’に設定される。’Ｈｅａｄｅｒ Ｌｅｎｇｔｈ’は、’Ｒｏｕｔｅ Ｌｅｎｇｔｈ’以降のヘッダの長さをバイト数で示す。パケットの整形を考慮し、４バイト単位の値とする。正味のデータの終わりが４バイト単位の境界に合わない場合は、スタッフィング（パディング）を行う（０を設定したダミーの情報を後置する。）。’Ｒｏｕｔｅ Ｌｅｎｇｔｈ’は、後に続くローカルＩＤの列挙により示された経路情報の合計バイト数を示す。’Ｌｏｃａｌ ＩＤ＃ｎ’は、ｎ ｈｏｐ目の境界転送ノード３００、あるいは内部転送ノード４００が転送先として参照すべきローカルＩＤが設定される。上記図４のフォーマットはあくまで一例であり、種々の変形フォーマットで情報を格納したとしても構わない。

上記のように、転送経路の情報として、転送ノード内、あるいは、隣接する転送ノード間といった局所的な範囲において一意となるローカルＩＤを用いることで、経路情報ヘッダの情報量を削減できる。なお、本実施形態では、各々のローカルＩＤは１バイトとしたが、論理的なリンクでは１バイトでは表現できない可能性がある。この場合は、’ＬｏｃａｌＩＤ＃ｎ’の最上位ｂｉｔを、ローカルＩＤが１バイト表記か２バイト表記かを示すローカルＩＤ拡張フラグとして使用しても良い。すなわち、この場合、最上位ビットが０の場合は、ローカルＩＤを１バイトの識別子と解釈し、最上位ビットが１の場合、ローカルＩＤを２バイトの識別子として解釈するものとすればよい。

パケット転送部３２０は、受信パケットの経路情報ヘッダの’Ｄｉｒｅｃｔｉｏｎ’フィールドが’１’であった場合、すなわち順方向への転送を示していた場合、経路情報ヘッダの’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’を参照し、対応するローカルＩＤを参照して転送先の通信インタフェース３１０を決定した後、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’の値を参照したローカルＩＤの長さ分（例えば、１バイト、あるいは２バイト）増やし、前記決定した通信インタフェース３１０からパケットを送出する。一方、’Ｄｉｒｅｃｔｉｏｎ’が’２’である場合、すなわち逆方向への転送を示していた場合、経路情報ヘッダの’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’を参照し、対応するローカルＩＤの１つ手前のローカルＩＤを参照し、転送先とする通信インタフェース３１０を決定する。その後、経路情報ヘッダの’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’の値を参照したローカルＩＤの長さ分減らし、決定した通信インタフェース３１０からパケットを送出する。

なお、本実施形態では双方向の転送を行うものとして説明するが、一方向の転送しか実施しない通信システムとしても構わない。この場合、’Ｄｉｒｅｃｔｉｏｎ’フィールドを常に’１’に設定するようにしても構わないし、当該フィールドをなくしても構わない。

ヘッダ操作部３３０は、外部ネットワーク７００からパケットを受信した場合、経路取得部３６０から、当該境界転送ノード３００から出口となる境界転送ノード３００までの１ｈｏｐ毎の経路情報を取得し、図４に示した経路情報ヘッダを構成し、前記パケットに付与する機能を備える。例えば、ヘッダ操作部３３０は、経路情報ヘッダを付与する際には、’Ｄｉｒｅｃｔｉｏｎ’には順方向への転送を意味する’１’を、’ＣｕｒｒｅｎｔＯｆｆｓｅｔ’には’０’を、’ＬｏｃａｌＩＤ＃ｎ’には取得した１ｈｏｐ毎の経路情報（ローカルＩＤ）を設定する。また、ヘッダ操作部３３０は、上述したルールに従い、他のフィールドにもそれぞれ適切な値を設定する。

ヘッダ操作部３３０は、また、経路情報ヘッダが付与されていたパケットを外部ネットワーク７００に転送する場合は、経路情報ヘッダを削除する機能を備える。

ローカルＩＤ決定部３４０は、当該境界転送ノード３００と近隣ノードとの間で情報交換を行って、重複しないリンクＩＤを決定する機能を備える。例えば、以下の方法で隣接するノードとのリンクＩＤの重複設定を回避することができる。

まず、転送ノードは、自身が既に割当てたリンクＩＤ以外のリンクＩＤを設定したパケットを近隣ノードに送信することでリンクＩＤ候補を提案する。リンクＩＤを提案された近隣ノードは、自ノード内に重複したリンクＩＤがないかどうか確認し、重複するリンクＩＤがない場合は、提案されたリンクＩＤと自ノードの識別情報を設定した応答パケットを、提案元となる転送ノードに送信する。一方、近隣ノードにおいて重複するリンクＩＤがあった場合は、重複することを意味する情報と自ノードの識別子を設定した応答パケットを送信する。この処理を、重複するリンクＩＤがなくなるまで繰り返す。

このようにして決定されたリンクＩＤや、近隣ノードの情報は、記録部３７０に転送テーブルとして記録される。

以上、リンクＩＤの決定方法の例を示したが、他の方法でリンクＩＤを決定することとしても構わない。例えば、経路管理サーバ５００など、他のノードが決定し、各転送ノードに通知することとしても良い。

なお、ローカルＩＤとして通信インタフェースの識別子を使う場合において、前記した逆方向の転送が不要である場合には、上記近隣ノードとのネゴシエーションを省略することができる。一方、逆方向への転送が必要である場合には、ローカルＩＤとしてインタフェースの識別子を使う場合においても、近隣ノードとネゴシエーションを行うことにより、近隣の転送ノードのどの通信インタフェースが、自身の通信インタフェースに接続されているかの情報を取得することができ、上記したリンクＩＤを用いる場合と同様に、Ｄｉｒｅｃｔｉｏｎによる転送方向によるインタフェースの選択が可能となる。

近隣情報通知部３５０は、ローカルＩＤ決定部３４０によりローカルＩＤとして決定したリンクＩＤと、リンクに接続された近隣ノードの識別子と、自らの識別子と、を格納した近隣情報を経路管理サーバ５００に送信する機能を備える。リンクに接続されているのが外部ネットワーク７００の通信ノード１００ａ、１００ｂであった場合は、外部ネットワークのノードと判定できる情報も前記情報に追加する。また、経路管理サーバ５００での経路計算のため、前記近隣情報には、各リンクの帯域、信頼性、混雑状況といった情報や、近隣ノードの故障情報などを含めることとしても良い。経路管理サーバ５００に前記近隣情報を送信する契機は、ローカルＩＤの決定処理が完了したタイミングでも良いし、所定の時間間隔で送信するものとしてもよい。また、リンクの情報や、近隣ノードの故障情報も含めて送信する場合は、これらの情報に変化が生じた契機で送信しても良い。

経路取得部３６０は、外部ネットワーク７００の通信ノード１００ａ、１００ｂからパケットを受信した際に、当該受信パケットの情報と、当該境界転送ノード３００の識別子を格納した経路要求信号を経路管理サーバ５００に送信し、当該パケットの転送経路を取得する機能を備える。前記受信パケットの情報とは、転送経路決定に影響を与えうる情報であり、最も単純な場合は、宛先アドレスのみである。しかし、より緻密な経路制御を実施する場合には、宛先アドレスに加え、送信元アドレス、当該パケットヘッダ以降に格納されたプロトコル情報、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）あるいはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）使用時の宛先ポート番号、送信元ポート番号といった情報の一部、あるいはすべてを含めることができる。さらに、他の情報を含むこととしてもかまわない。

前記経路要求信号を送った結果、経路管理サーバ５００から経路応答信号が返される。前記経路応答信号に含まれる転送経路情報には、当該境界転送ノード３００を起点とした転送経路に沿って、ローカルＩＤを１ｈｏｐ毎に列挙した情報が格納される。

なお、宛先アドレスなど、前記転送経路に影響を与えうる情報と、転送経路を示すローカルＩＤ群との対応情報は、当該境界転送ノード３００に事前に設定し、予め経路管理サーバから受信しておくこともできる。この場合は、経路取得部３６０は、経路管理サーバ５００ではなく、内部に設定された情報から転送経路情報を取得する。

また、上記の例では、当該境界転送ノード３００が最初に転送先とする通信インタフェースを識別可能なローカルＩＤを起点としたが、前記パケットを受信した通信インタフェース３１０を識別可能なローカルＩＤを、起点としても構わない。

記録部３７０は、図３に示す転送テーブルを保持し、パケット転送部３２０や、ローカルＩＤ決定部３４０や、近隣情報通知部３５０に、参照させる。

内部転送ノード４００は、データ転送ネットワーク６００内に配置され、近隣ノードから送信されたパケットを受信した場合には、パケット中の経路情報ヘッダの情報に基づきデータ転送ネットワーク６００内の近隣ノードに当該パケットを転送する機能を備える。

図５は、図１の内部転送ノード４００の構成を示す図である。内部転送ノード４００は、図５に示すように、通信インタフェース４１０と、パケット転送部４２０と、ローカルＩＤ決定部４３０と、近隣情報通知部４４０と、記録部４５０とを備えて構成されている。

通信インタフェース４１０、パケット転送部４２０、ローカルＩＤ決定部４３０、近隣情報通知部４４０および記録部４５０は、それぞれ、境界転送ノード３００の、通信インタフェース３１０、パケット転送部３２０、ローカルＩＤ決定部３４０、近隣情報通知部３５０、記録部３７０と同等であるため、ここでは詳細な説明を省略する。

つまり内部転送ノード４００は、境界転送ノード３００から、ヘッダ操作部３３０と、経路取得部３６０を差し引いたものとみなすことができる。反対に、境界転送ノード３００は、内部転送ノード４００に、ヘッダ操作部３３０と、経路取得部３６０を追加した転送ノードであるということができる。

経路管理サーバ５００は、境界転送ノード３００と内部転送ノード４００から通知された近隣情報を収集し、データ転送ネットワーク６００内の境界転送ノード３００および内部転送ノード４００の接続関係を記述したネットワークトポロジ情報を構築する。このネットワークトポロジ情報には、境界転送ノード３００に接続する通信ノード１００ａ、１００ｂとの接続情報も含まれる。前記通知された経路情報に、各転送ノード間のリンクや転送ノードの状態を示す情報（混雑状況、故障状況など）が含まれていた場合は、それも前記接続情報に対応づけて管理する。そして、境界転送ノード３００から、転送経路情報を要求された場合には、経路要求に含まれる情報と、内部に構築したネットワークトポロジ情報を使って適切な転送経路を求める計算を実施し、経路要求を行った境界転送ノード３００を起点として、外部ネットワーク７００への出口となる境界転送ノード３００までの転送経路を、１ｈｏｐ毎のローカルＩＤ（リンクＩＤ）を順に列挙した情報として応答する機能を備える。

図６は、図１の経路管理サーバ５００の構成を示す図である。経路管理サーバ５００は図６に示すようにさらに、通信インタフェース５１０と、経路情報収集部５２０と、経路要求処理部５３０と、経路計算部５３１と、経路情報記録部５４０とを備えて構成されている。

通信インタフェース５１０は、パケットの送受信を行うためのインタフェースである。前述のように、例えばＬＡＮカードのようなＮＩＣと、それを動作させるソフトウェア（ドライバ）により実現できる。

経路情報収集部５２０は、境界転送ノード３００および内部転送ノード４００から送られた近隣情報を受信すると、近隣情報に格納された、前記近隣情報を送信したノードの識別子、ローカルＩＤ（リンクＩＤ）、近隣ノード識別子を使って、経路情報記録部５４０内にデータ転送ネットワーク６００内のネットワークトポロジ情報を構築する。前記近隣情報に、リンクの帯域、信頼性、混雑状況や、近隣ノードの故障情報といった付帯情報が含まれていた場合は、前記ネットワークトポロジ情報に前記付帯情報を関連づけて記録する。これらの情報は、例えば、後述する経路計算のときにリンクのコストとして使用することができる。

図７は、各転送ノードから受信した近隣情報の例である。図８は、図７の近隣情報から構築したネットワークトポロジの例である。図８の例では、簡単のため、付帯情報は省略している。また、外部ネットワークはＩＰネットワークであることを想定している。

図７中の’ｓｅｎｄｅｒＩＤ’は近隣情報を送信した転送ノードの識別子を示している。図７中の’ＬｉｎｋＩＤ’は、前記転送ノードが接続するリンクに割当てたリンクＩＤを示している。図７中の’ｎｅｉｇｈｂｏｒＩＤ’は前記リンクに接続している近隣ノードの識別子を示している。外部ネットワークはＩＰネットワークとの想定なので、通信ノード１００の識別子としてＩＰアドレスを使用する。また、上述のように隣接する転送ノード間でネゴシエーションが行われているため、リンクＩＤは、一の転送ノードに重複して設定されないが、隣接しない転送ノード同士が同一のリンクＩＤを用いることは許容される。例えば、ＬｉｎｋＩＤ＝１のリンクは、ＩＤ＝１のノードと、ＩＤ＝１０のノード間およびＩＤ＝５のノードと、ＩＤ＝６のノード間に用いられているが、それぞれの転送ノード内で一意にリンクを識別することが可能である。つまり、リンクＩＤの長さは、一の転送ノード内で一意性を確保するに足る長さがあればよい。

経路情報収集部５２０は、例えば、図７の近隣情報が得られている場合、図８に示すようなネットワークトポロジを構築し、経路情報記録部５４０に記録する。

図７の近隣情報と、それに基づいて構築された図８のネットワークトポロジ情報にはリンクＩＤを使ったが、インタフェース識別子など、他の情報をローカルＩＤとした場合でも、同様にネットワークトポロジ情報の構築は可能である。

経路要求処理部５３０は、境界転送ノード３００から送信された経路要求信号を受信し、そこに含まれる情報と共に、経路計算要求を経路計算部５３１に通知する。

経路要求処理部５３０はまた、経路計算部５３１から、転送経路情報（１ｈｏｐ毎のリンクＩＤを転送経路順に列挙した情報）を取得した際に、当該転送経路情報を格納した経路応答信号を前記経路要求信号の送信元となる境界転送ノード３００に送信する。

経路計算部５３１は、経路要求処理部５３０から経路計算要求を通知された場合、共に入力された、経路要求元の境界転送ノード３００の識別子と、宛先アドレスをそれぞれ始点、終点ポイントとして、経路情報記録部５４０に記録された図８のようなネットワークトポロジ情報を使って、経路の計算を行う。経路計算には、Ｄｉｊｋｓｔｒａ法と呼ばれる最短経路を求めるアルゴリズムを適用することができる。ただし、他のアルゴリズムを適用することとしても構わない。

経路計算要求にＩＰパケットの送信元アドレスを含む場合は、始点として送信元アドレス（即ち境界転送ノード３００が受信したパケットの送信元となる通信ノード１００ａまたは１００ｂの識別子）を使っても良い。また、前記したように経路計算を行う上で、ＴＣＰ、あるいはＵＤＰの宛先／送信元ポート番号など、他の情報を使って経路計算を行っても良い。さらには、リンクに付帯する情報（帯域、混雑具合など）や、故障した境界／内部転送ノードの識別子といった情報を経路計算に使用しても良い。

経路情報記録部５４０は、経路情報収集部５２０により、図８に示すようなネットワークトポロジ情報が記録される。前記ネットワークトポロジ情報は、経路計算のため経路計算部５３１から参照される。

以上本発明の実施の形態で説明した、通信インタフェース３１０、４１０、５１０は、前記したとおり、例えばＬＡＮカードのようなＮＩＣと、それを動作させるソフトウェア（ドライバ）により実現できる。

また、記録部３７０、記録部４５０、経路情報記録部５４０は、半導体メモリ、ハードディスクドライブなど情報を記録可能な装置で実現することができる。

その他の機能ブロックについては、それぞれの機器に搭載された１つあるいは複数のＣＰＵにて実行されるコンピュータプログラム（ソフトウェア）あるいはハードウェアで実現できる。機能ブロックが行うべき処理の一部をソフトウェアで実施し、それ以外をハードウェアで実施することとしても良い。

続いて、本実施形態の動作について図面を参照して詳細に説明する。はじめに、境界転送ノード３００の動作を説明する。

図９は、境界転送ノード３００が、データ転送ネットワーク６００あるいは外部ネットワーク７００からパケットを受信した場合の処理を示している。

まず、パケット転送部３２０は、通信インタフェース３１０を介してパケットを受信すると、当該パケットに経路情報ヘッダが付与されているかどうかをチェックする（ステップＳ１００）。

経路情報ヘッダが付与されていた場合は’Ｙ’に進み、その経路情報ヘッダに従って転送処理が行われる（ステップＳ１０３へ）。一方、経路情報ヘッダが付与されていなかった場合は’Ｎ’に進み、経路取得部３６０から、経路要求信号を経路管理サーバ５００に送信することで転送経路情報を取得する経路取得処理が行われる（ステップＳ１０１）。

転送経路情報の取得が完了すると、ヘッダ操作部３３０は、前記取得した転送経路情報の転送経路の順に従って、図４の経路情報ヘッダのローカルＩＤフィールド（’ＬｏｃａｌＩＤ＃ｎ’）に、ローカルＩＤを設定する。また、ヘッダ操作部３３０は、’Ｄｉｒｅｃｔｉｏｎ’を’１’に設定し、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’を’０’に設定する。ヘッダ操作部３３０は、その他のフィールドも適切な値に設定した上で、経路情報ヘッダを、前記受信したパケットの先頭に付加する（ステップＳ１０２）。

パケット転送部３２０は、前記した経路情報ヘッダに従って転送処理を実施する（ステップＳ１０３）。

図１０は、図９のステップＳ１０３の転送処理の詳細を表したフローチャートである。図１０を参照すると、まず、パケット転送部３２０は、経路情報ヘッダの’Ｄｉｒｅｃｔｉｏｎ’フィールドをチェックし順方向への転送をすべきか、逆方向の転送をすべきかを判定する（ステップＳ２００）。

’Ｄｉｒｅｃｔｉｏｎ’フィールドの値が順方向の転送を示す（’１’）場合は、’Ｙ’に進み、当該パケットの転送先が外部ネットワーク７００であるかどうかが判定される（ステップＳ２０１）。順方向の転送において、外部ネットワーク７００への転送かどうかの判定は、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’と’Ｒｏｕｔｅ Ｌｅｎｇｔｈ’を比較することにより判定できる。判定方法は他にも、ローカルＩＤを外部ネットワーク７００への転送かどうかを区別可能な値とすることとしても良いし、経路情報ヘッダ中の最後のローカルＩＤの後に、終端を意味する情報を格納しても良い。さらに、他の方法としても構わない。

外部ネットワーク７００への転送でないと判定された場合は、’Ｎ’に進み、経路情報ヘッダの’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’に１ｈｏｐ分のバイト数が加算される（ステップＳ２０２）。１ｈｏｐ分のバイト数とは、現在参照している’ＬｏｃａｌＩＤ＃ｎ’フィールドのバイト数となる。ここで、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’の値を加算する前に参照先となっていたローカルＩＤを保持しておく。

そして、パケット転送部３２０は、前記保持しておいたローカルＩＤを用いて、順方向へのパケットの転送処理を行う（ステップＳ２０６）。具体的には、記録部３７０に記録された転送テーブルの情報を使ってローカルＩＤから、転送先とすべき通信インタフェース３１０を決定し、当該通信インタフェース３１０からパケットを転送する。

一方、ステップＳ２００にて’Ｄｉｒｅｃｔｉｏｎ’フィールドの値が逆方向の転送を示す（’２’）場合は、’Ｎ’に進み、当該パケットの転送先が外部ネットワーク７００であるかどうかが判定される（ステップＳ２０３）。逆方向の転送における、外部ネットワーク７００への転送かどうかの判定は、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’の値が’０’かどうかにより判定することができる（’０’のとき外部ネットワークへの転送）。これは、パケットをはじめに送信する通信ノード１００ａ、１００ｂと、それを受信する境界転送ノード３００間のリンクのリンクＩＤを、１番最初のローカルＩＤとして使わない場合の判定方法となる。前記リンクＩＤを１番最初のローカルＩＤとして使う場合は、現在の’Ｃｕｒｒｒｅｎｔ Ｏｆｆｓｅｔ’を、１ｈｏｐ分減算した値が’０’の場合、外部ネットワークへの転送と判定できる。逆方向への転送時の判定方法は他にも、ローカルＩＤを、外部ネットワーク７００への転送かどうかを区別可能な値とすることとしても良いし、経路情報ヘッダ中の最初のローカルＩＤの前に、開始を意味する情報を格納しても良い。さらに、他の方法としても構わない。

外部ネットワーク７００への転送でないと判定された場合は、’Ｎ’に進み、経路情報ヘッダの’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’の値が１ｈｏｐ分減算される（ステップＳ２０４）。ここで、減算後の’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’で参照先となるローカルＩＤを保持しておく。

そして、パケット転送部３２０は、前記保持しておいたローカルＩＤを用いて、逆方向へのパケットの転送処理を行う（ステップＳ２０６）。具体的には、記録部３７０に記録された転送テーブルの情報を使ってローカルＩＤから、転送先とすべき通信インタフェース３１０を決定し、当該通信インタフェース３１０からパケットを転送する。

上記ステップＳ２０１またはＳ２０３において、外部ネットワーク７００への転送と判定された場合は、それぞれ’Ｙ’に進み、ヘッダ操作部３３０により、経路情報ヘッダの除去処理が行われる（ステップＳ２０５）。ここで、経路情報ヘッダを除去する前に、転送先となるローカルＩＤを保持しておく。

そして、パケット転送部３２０は、前記保持しておいたローカルＩＤを用いて、外部ネットワーク７００へのパケットの転送処理を行う（ステップＳ２０６）。具体的には、記録部３７０に記録された転送テーブルの情報を使ってローカルＩＤから、転送先とすべき通信インタフェース３１０を決定し、当該通信インタフェース３１０からパケットを転送する。

なお、’Ｄｉｒｅｃｔｉｏｎ’フィールドを使わず、常に順方向に転送する場合は、ステップＳ２００の転送方向の判定は不要であり、ステップＳ２０１の外部ネットワークへの転送であるか否かの判定を行うようにすればよい。

続いて、内部転送ノード４００の動作を説明する。

図１１は、内部転送ノード４００が、データ転送ネットワーク６００の境界転送ノード３００あるいは内部転送ノード４００からパケットを受信した場合の処理を示している。

図１１を参照すると、まず、パケット転送部４２０は、通信インタフェース４１０を介してパケットを受信すると、当該パケットに経路情報ヘッダが付与されているかどうかをチェックする（ステップＳ３００）。

経路情報ヘッダが付与されていた場合は’Ｙ’に進み、経路情報ヘッダの’Ｄｉｒｅｃｔｉｏｎ’フィールドをチェックし、順方向への転送をすべきか、逆方向の転送をすべきかを判定する（ステップＳ３０２）。一方、経路情報ヘッダが付与されていなかった場合は’Ｎ’に進み、受信したパケットが破棄処理が行われる（ステップＳ３０１）。

ステップＳ３０２でチェックした’Ｄｉｒｅｃｔｉｏｎ’フィールドの値が順方向の転送を示す（’１’）場合は、’Ｙ’に進み、経路情報ヘッダの’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’に１ｈｏｐ分のバイト数が加算される（ステップＳ３０３）。ここで、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’の値を加算する前に参照先となっていたローカルＩＤを保持しておく。

一方、ステップＳ３０２でチェックした’Ｄｉｒｅｃｔｉｏｎ’フィールドの値が逆方向の転送を示す（’２’）場合は、’Ｎ’に進み、経路情報ヘッダの’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’に１ｈｏｐ分のバイト数が減算される（ステップＳ３０４）。ここで、ここで、減算後の’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’で参照先となるローカルＩＤを保持しておく。

最後に、上記ステップＳ３０３あるいはステップＳ３０４で保持されたローカルＩＤに基づき、パケットの転送処理が行われる。具体的には、記録部４５０に記録された転送テーブルの情報を使ってローカルＩＤから、転送先とすべき通信インタフェース４１０を決定し、当該通信インタフェース４１０からパケットを転送する（ステップＳ３０５）。

なお、’Ｄｉｒｅｃｔｉｏｎ’フィールドを使わず、常に順方向の転送とする場合は、ステップＳ３０２の転送方向の判定は不要であり、常にステップＳ３０３の’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’加算処理が行われる。

続いて、境界転送ノード３００および内部転送ノード４００によるローカルＩＤの決定およびその結果を経路管理サーバ５００に近隣情報として通知する処理を説明する。

図１２は、境界転送ノード３００および内部転送ノード４００が近隣情報通知を送信する動作を示すフローチャートである。

図１２を参照すると、まず、ローカルＩＤ決定部３４０（４３０）が、ローカルＩＤを決定する（ステップＳ４００）。ローカルＩＤとしてリンクＩＤを使う場合は、近隣ノードとリンクＩＤのネゴシエーションを実施することでリンクＩＤを決定する。なお、ローカルＩＤとして、通信インタフェースの識別子を使う場合は、当該境界転送ノード３００あるいは内部転送ノード４００は、自らが備える通信インタフェース３１０（４１０）に割当てた識別子をローカルＩＤとする。

ここで、前記リンクＩＤは、当該境界転送ノード３００あるいは内部転送ノード４００が使用可能なすべての物理的あるいは論理的なリンクに対して決定される。同じように、通信インタフェースの識別子は、全ての物理的あるいは論理的な通信インタフェースに対して決定される。ただし、管理上の理由などにより、一部のリンクや、通信インタフェースを対象外としても構わない。

次に、ローカルＩＤ決定部３４０（４３０）は、前記決定したローカルＩＤと通信インタフェース情報（当該通信インタフェースをパケット転送先とするのに必要な情報）とを対応づけて、記録部３７０（４５０）中の転送テーブル（図３参照）に記録する（ステップＳ４０１）。転送テーブルには、各リンクの先に接続された近隣ノードの識別子も対応づけて記録する。さらに、各リンクに関連する情報や、近隣ノードの故障情報なども付帯情報として記録しても良い。

前記転送テーブルへの記録が完了すると、近隣情報通知部３５０（４４０）が、記録部３７０（４５０）に記録された転送テーブルの情報から、ローカルＩＤと、近隣ノードの識別子を設定した近隣情報（図７参照）を構成し、これを経路管理サーバ５００へ送信する（ステップＳ４０２）。近隣情報には、各リンクに関連する情報や、近隣ノードの故障情報などといった付帯情報も格納することとしても良い。

続いて、経路管理サーバ５００の動作を説明する。

図１３は、上記近隣情報を受信した経路管理サーバ５００の処理を表したフローチャートである。図１３を参照すると、まず、経路情報収集部５２０にて境界転送ノード３００あるいは内部転送ノード４００から送られた近隣情報を受信すると（ステップＳ５００）、経路管理サーバ５００は、受信した近隣情報から、ローカルＩＤや近隣ノードの識別子といった情報を取得し、取得した情報を用いてネットワークトポロジ情報を構築し、記録部５４０に記録する（ステップＳ５０１）。

図１４は、境界転送ノード３００から経路情報を要求された経路管理サーバ５００の処理を表したフローチャートである。図１４を参照すると、まず、境界転送ノード３００から経路要求信号を受信すると、経路要求処理部５３０は、経路要求信号に含まれる情報を経路計算部５３１に通知する（ステップＳ６００）。

次に、経路計算部５３１は、ステップＳ６００で通知された経路要求信号に含まれていた情報と、経路情報記録部５４０に記録されたネットワークトポロジ情報とにより、最適な転送経路の計算を行う（ステップＳ６０１）。転送経路の計算が完了すると、経路計算部５３１は、決定された経路の転送順に１ｈｏｐ毎のローカルＩＤを読み出し、経路要求処理部５３０に通知する。

前記転送経路の計算結果を受け取った経路要求処理部５３０は、通知された転送経路情報（ローカルＩＤの並び）を、経路情報応答信号に設定して、経路要求信号の送信元である境界転送ノード３００に送信する（ステップＳ６０２）。

最後に、図１５のシーケンス図を参照して、ＩＰノードである通信ノード１００ａが境界転送ノード３００ａにパケットを送信し、それが順次転送処理され、最終的にＩＰノードである通信ノード１００ｂに届くまでの一連の流れを説明する。

ここでは、例として、各ノードの接続状況が図８に示したネットワークトポロジのようになっているものとして説明する。境界転送ノード３００ａは、図８のＩＤ＝１のノードに相当する。境界転送ノード３００ｂは、図８のＩＤ＝８のノードに相当する。ＩＰパケットの送信元アドレスは、１９２．１６８．０．５０であり、宛先アドレスは、１９２．１６８．０．２０であるものとする。

通信ノード１００ａから送信されたＩＰパケットが境界転送ノード３００ａに届くと（ステップＳ７００）、境界転送ノード３００ａは、図９に示すフローチャートに従った処理を実行する。ここでは、ＩＰパケットには経路情報ヘッダが付与されていないため、図９のステップＳ１０１において経路情報要求信号が経路管理サーバ５００に送信される（ステップＳ７０１）。

前記経路情報要求信号を受信した経路管理サーバ５００は、図１４のフローチャートに従い、経路情報を計算し、転送経路を決定した後、経路情報応答信号を境界転送ノード３００ａに送信する（ステップＳ７０２）。

リンクの帯域や、混雑具合は考慮せず、最短パスを計算する場合、以下のとおり、転送経路が計算される。図８のネットワークトポロジの最短パスは、ＩＤ＝１のノード −＞ ＩＤ＝１０のノード −＞ ＩＤ＝８のノード −＞ １９２．１６８．０．２０のノード（パケットの宛先となる外部ネットワークのＩＰノード）が転送経路として選択される。従って、前記経路情報応答信号には、図８のネットワークトポロジのパス上のリンクＩＤである、１、２、０の値がローカルＩＤとして上記順番で格納される。

ここで、ＩＤ＝１９２．１６８．０．５０のノード（外部ネットワーク７００のＩＰノード）からＩＤ＝８のノード間のリンクＩＤ（＝０）を経路情報応答に含めることとしても構わない。この場合、前記経路情報応答信号に含めるローカルＩＤの格納順序は、０、１、２、０となる。また逆に、外部ネットワーク（通信ノード１００ｂ）へのリンクＩＤ（＝０）を経路情報応答に含めないこととしても構わない。この場合、ローカルＩＤの格納順序は。１、２となる。

さらに、外部ネットワークのＩＰノードのＩＤとしてＩＰアドレスを使ったが、ＩＰアドレスの上位から任意のｂｉｔ長を抜き出したネットワークアドレスとしても良いし、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスなどレイヤ２の情報や、それ以外の情報を用いても構わない。

境界転送ノード３００は前記経路情報応答信号を受信すると（ステップＳ７０３）、図９のステップＳ１０２以降の処理にしたがい、ステップＳ７００で受信したＩＰパケットに経路情報ヘッダを付与し、その後、図９のステップＳ１０３において、付与した経路情報ヘッダに従い、転送すべきローカルＩＤ（＝１）に対応した通信インタフェースからパケットを送出する（ステップＳ７０４）。この結果、ＩＤ＝１０の内部転送ノード４００にパケットが転送される。

内部転送ノード４００は、経路情報ヘッダが付与されたパケットを受信すると（ステップＳ７０５）、図１１に示すフローチャートに従い転送処理を行う（ステップＳ７０６）。ここでは、転送経路情報に従って、転送すべきローカルＩＤ（＝２）に対応した通信インタフェースからパケットが送出され、ＩＤ＝８の境界転送ノード３００ｂにパケットが転送される。

境界転送ノード３００ｂは、経路情報ヘッダが付与されたパケットを受信すると（ステップＳ７０７）、図９に示すフローチャートにそって処理を実施する。さらに図９のステップＳ１０３では、さらに図１０に示すフローチャートに示した転送処理が実施される。ここでは、図１０のステップＳ２０１で外部ネットワークへの転送と判定されるため、境界転送ノード３００ｂは、前記受信したパケットから経路情報ヘッダが除去した後、除去前の経路情報ヘッダの情報に従い、転送すべきローカルＩＤ（＝０）に対応した通信インタフェースからパケットを送出する（ステップＳ７０８）。この結果、最終的に通信ノード１００ｂへとＩＰパケットが転送される。

以上のとおり、本実施形態によれば、ＩＰアドレス等のグローバルに一意性が確保される経路情報ではなく、転送ノード内、あるいは、隣接する転送ノード間といった局所的な範囲での一意性だけが保証されたローカルＩＤを使って転送先を指定するよう構成している。このため、１バイトあるいは２バイト程度の情報量に１ｈｏｐ分の転送経路が格納可能となり、当該転送経路の情報を経路情報ヘッダに格納してパケットに付与した場合でも、付与するヘッダによるオーバヘッドを極めて小さいサイズに抑制することが可能になる。この結果、用途を限らずすべてのパケットに経路情報ヘッダを格納することが可能となる。

また本実施形態では、転送ノードに備える転送テーブルのエントリ数を、各転送ノードが備える通信インタフェースの数程度とすることが可能になる。また、転送テーブルの格納・更新・利用のため、転送ノードに必要とされるメモリのサイズやＣＰＵの処理能力も抑制可能となり、転送ノードを安価とすることができる。

これらの結果として、本実施形態によれば、転送経路を１ｈｏｐ毎に厳密に指定した場合においても正味の情報を効率よく、さらに高速に転送可能となる。

［第２の実施形態］
続いて、本発明の第１の実施形態に変更を加えた本発明の第２の実施形態について図面を参照して詳細に説明する。

本発明の第２の実施形態の全体の構成は、第１の実施形態とほぼ同じ構成、機能であるので、以下、その相違点を中心に説明する。

図１６は、本発明の第２の実施形態の境界転送ノード３０１の構成を表した図である。図１６を参照すると、本実施形態の境界転送ノード３０１は、第１の実施形態の境界転送ノード３００の構成に、キャッシュ管理部３８０を追加した構成となっている。また、経路取得部３６０Ａの動作や、記録部３７０Ａの記録する情報も第１の実施形態と異なっている。

経路取得部３６０Ａは、本発明の第１の実施形態の経路取得部３６０とほぼ同じ機能を備えるが、経路管理サーバ５００に転送経路情報の要求を行う前に、後述する経路情報キャッシュを検索する機能をさらに備える。経路情報キャッシュを検索した結果、受信パケットに対応する経路情報キャッシュが見つかった場合、経路管理サーバ５００に経路情報の要求は行なわず、見つかった経路情報キャッシュから転送経路情報を取得する。また、経路情報キャッシュが見つからなかった場合、経路取得手段３６０Ａは、経路情報キャッシュとして記録するようキャッシュ管理部３８０に経路管理サーバ５００から取得した転送経路情報と受信パケットの情報とを送信する。

キャッシュ管理部３８０は、経路取得部３６０Ａが経路管理サーバ５００から転送経路情報を取得した際、また、ヘッダ操作部３３０が経路情報ヘッダを削除する際、受信パケットの情報と、経路情報ヘッダに設定された情報とを対応づけて経路情報キャッシュとして記録部３７０Ａに記録する機能を備える。

本実施形態では、前記受信パケットの情報として、宛先アドレスおよび送信元アドレスを記録するものとする。ただし、宛先アドレスおよび送信元アドレスに加え、他の情報を使っても良い。

経路情報キャッシュは、一定の時間の経過や、一定量の経路情報キャッシュが蓄積されたことを契機として古い経路情報キャッシュから削除することとしても良い。また、管理上の理由などで、任意の経路情報キャッシュを削除しても良い。

記録部３７０Ａは、第１の実施形態における記録部３７０が記録する情報に加えて、さらに、経路情報キャッシュを記録する。経路情報キャッシュは、キャッシュ管理部３８０により、追加・更新・削除といった管理がなされる。

続いて、上記第２の実施形態の境界転送ノード３０１の動作を説明する。

図１７は、境界転送ノード３０１が、データ転送ネットワーク６００あるいは外部ネットワーク７００からパケットを受信した場合の処理を示している。

図１７を参照すると、まず、パケット転送部３２０は、通信インタフェース３１０を介してパケットを受信すると、当該パケットに経路情報ヘッダが付与されているかどうかをチェックする（ステップＳ８００）。

経路情報ヘッダが付与されていた場合は’Ｙ’に進み、その経路情報ヘッダに従って転送処理が行われる（ステップＳ８０９へ）。一方、経路情報ヘッダが付与されていなかった場合は’Ｎ’に進み、経路取得部３６０Ａが、順方向の経路情報キャッシュの検索処理が行われる（ステップＳ８０１）。前記順方向の経路情報キャッシュの検索は、受信パケットの宛先アドレスと、経路情報キャッシュ中の宛先アドレスとを比較することで行うことができる。

前記順方向の経路情報キャッシュの検索の結果、経路情報キャッシュが見つかった場合（ステップＳ８０２の’Ｙ’）、当該経路情報キャッシュを用いた経路情報ヘッダの付加処理が行われる（ステップＳ８０８へ）。

一方、前記順方向の経路情報キャッシュの検索の結果、経路情報キャッシュが見つからなかった場合（ステップＳ８０２の’Ｎ’）、経路取得部３６０Ａは、逆方向の経路情報キャッシュの検索処理を行う（ステップＳ８０４）。前記逆方向の経路情報キャッシュの検索は、受信パケットの宛先アドレスと、経路情報キャッシュ中の送信元アドレスとを比較することで行うことができる。

前記逆方向の経路情報キャッシュの検索の結果、経路情報キャッシュが見つかった場合（ステップＳ８０５の’Ｙ’）、当該経路情報キャッシュを用いた経路情報ヘッダの付加処理が行われる（ステップＳ８０８へ）。

一方、前記逆方向の経路情報キャッシュの検索の結果、経路情報キャッシュが見つからなかった場合（ステップＳ８０５の’Ｎ’）、経路取得部３６０Ａは、経路管理サーバ５００に経路要求信号を送信し転送経路情報を取得する経路取得処理を行なう（ステップＳ８０６）。

転送経路情報の取得が完了すると、キャッシュ管理部３８０が、受信パケットに含まれる宛先アドレスおよび送信元アドレスと、ステップＳ８０６で取得した転送経路情報とを対応づけて経路情報キャッシュとして記録部３７０Ａに記録する（ステップＳ８０７）。

また、ヘッダ操作部３３０は、経路情報キャッシュまたは前記取得した転送経路情報の転送経路の順に従って、経路情報ヘッダを構成し、前記受信したパケットの先頭に付加する（ステップＳ８０８）。経路情報ヘッダの各フィールドに設定する値は、次のようになる。

経路管理サーバ５００から転送経路情報を取得した場合は、図４に示す経路情報ヘッダのローカルＩＤフィールド（’ＬｏｃａｌＩＤ＃ｎ’）に、転送順に従って経路情報を設定する。また、’Ｄｉｒｅｃｔｉｏｎ’を’１’に設定し、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’を’０’に設定する。

また、ステップＳ８０１の順方向キャッシュ検索において経路情報キャッシュから経路情報を取得した場合には、’Ｄｉｒｅｃｔｉｏｎ’を’１’に、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’を’０’に設定する。’ＬｏｃａｌＩＤ＃ｎ’には、経路情報キャッシュに記録された値を、順番を維持したまま設定する。

一方、ステップＳ８０４の逆方向キャッシュ検索において経路情報キャッシュから経路情報を取得した場合には、’Ｄｉｒｅｃｔｉｏｎ’を’２’に、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’を経路情報キャッシュに記録された値に設定する。’ＬｏｃａｌＩＤ＃ｎ’には、経路情報キャッシュに記録された値を、順番を維持したまま設定する。

なお、ステップＳ８０４の逆方向キャッシュ検索において経路情報キャッシュから経路情報を取得した場合には、経路情報キャッシュに記録された値を、逆の順番で’ＬｏｃａｌＩＤ＃ｎ’に設定することもできる。この場合は、’Ｄｉｒｅｃｔｉｏｎ’を’１’に、’Ｃｕｒｒｅｎｔ Ｏｆｆｓｅｔ’を最初の転送先となるローカルＩＤ＃ｎを示すオフセットバイト数に設定する。

パケット転送部３２０は、上記のように構成した経路情報ヘッダに従って転送処理を実施する（ステップＳ８０９）。ステップＳ８０９の処理の詳細は、図１０に示した第１の実施形態における境界転送ノード３００の転送処理とほぼ同様であるので省略する。ただし、本実施形態においては、図１０のステップＳ２０５において、経路情報ヘッダが削除される際にキャッシュ管理部３８０が、受信パケットの情報と、経路情報ヘッダに設定された情報とを対応づけて経路情報キャッシュとして記録部３７０Ａに記録する。

続いて、第２の実施形態における通信ノード１００ａおよび通信ノード１００ｂ間のパケット転送処理の流れを説明する。

最初（往路側）のパケットの転送手順は、第１の実施形態とほぼ同様であり、図１５に示したシーケンス図のとおりパケットが転送される。但し、図１５のステップＳ７０３と、ステップＳ７０７において、それぞれ、境界転送ノード３０１ａ、境界転送ノード３０１ｂの記録部３７０に、図１８（ａ）、（ｂ）に示す経路情報キャッシュが作成される。

図１８の経路情報キャッシュ中の経路情報フィールドに記録された’Ｄｉｒｅｃｔｉｏｎ’、’ＣｕｒｒｅｎｔＯｆｆｓｅｔ’、’ＲｏｕｔｅＬｅｎｇｔｈ’には、経路情報ヘッダの同名のフィールドに設定された値が記録される。’ＬｏｃａｌＩＤｓ’には、経路情報ヘッダの’ＬｏｃａｌＩＤ＃ｎ’フィールドの値が、順番を維持したまま記録される。

経路管理サーバ５００から経路情報を取得した場合は、’Ｄｉｒｅｃｔｉｏｎ’に’０’を、’ＣｕｒｒｅｎｔＯｆｆｓｅｔ’に’０’を記録する。また’ＲｏｕｔｅＬｅｎｇｔｈ’、’ＬｏｃａｌＩＤｓ’には、それぞれ取得した転送経路数分のローカルＩＤの総バイト長、転送経路数分のローカルＩＤが設定される。なお、カッコの中の値は、図１５のシーケンス図に従ってパケット転送を処理した場合に記録される値を示している。

図１８の経路情報キャッシュには、作成時刻情報も含めているが、これは必ずしも必要ではない。なお、作成時刻情報のＨＨ：ＭＭ：ＳＳはそれぞれ、時：分：秒を示す。

続いて、図１９のシーケンス図を参照して、通信ノード１００ａにより送信されたパケットが宛先の通信ノード１００ｂに転送された後、今度は、前記通信ノード１００ｂが、通信ノード１００ａにパケットを送信し、それが順次転送処理され、最終的にＩＰノードである通信ノード１００ａに届くまでの一連の流れを説明する。

以下においても、各ノードの接続状況が図８に示したネットワークトポロジのようになっているものとして説明する。境界転送ノード３０１ａは、図８のＩＤ＝１のノードに相当する。境界転送ノード３０１ｂは、図８のＩＤ＝８のノードに相当する。ＩＰパケットの送信元アドレスは、１９２．１６８．０．２０であり、宛先アドレスは、１９２．１６８．０．５０であるものとする。

通信ノード１００ｂからＩＰパケットが送信され（ステップＳ９００）、境界転送ノード３００ｂに届くと、境界転送ノード３０１ｂは、図１７に示すフローチャートに従った処理を実行する（ステップＳ９０１）。まず、ＩＰパケットには経路情報ヘッダが付与されていないため、図１７のステップＳ８０１において順方向の経路情報キャッシュ検索が実行される。すなわち、図１８（ｂ）に示す経路情報キャッシュの宛先アドレスフィールドを走査して、宛先アドレス１９２．１６８．０．５０を持つエントリを検索する処理が行われる。

図１８（ｂ）に示す経路情報キャッシュには、宛先アドレスフィールドに、宛先アドレス１９２．１６８．０．５０を持つエントリはないため、今度は、図１７のステップＳ８０４において逆方向の経路情報キャッシュ検索が実行される。すなわち、図１８（ｂ）に示す経路情報キャッシュの送信元アドレスフィールドを走査して、宛先アドレス１９２．１６８．０．５０を持つエントリを検索する処理が行われる。

図１８（ｂ）に示す経路情報キャッシュの例では、送信元アドレスフィールドに、宛先アドレス１９２．１６８．０．５０を持つエントリがある。経路取得部３６０Ａは、前記検索により見つかったエントリの経路情報を読み出す。

図１８（ｂ）に示す経路情報キャッシュから読み出される経路情報は、以下となる。
’Ｄｉｒｅｃｔｉｏｎ’ ＝ １
’ＣｕｒｒｅｎｔＯｆｆｓｅｔ’ ＝ ２
’ＲｏｕｔｅＬｅｎｇｔｈ’ ＝ ３
’ＬｏｃａｌＩＤｓ’ ＝｛１、２、０｝

ここでは、前記読み出された経路情報から経路情報ヘッダを構成する際に、転送経路’ＬｏｃａｌＩＤｓ’の順番を維持するものとする。この場合、経路情報ヘッダの各フィールドは、以下のように設定される。

’Ｄｉｒｅｃｔｉｏｎ’ ＝ ２
’ＣｕｒｒｅｎｔＯｆｆｓｅｔ’ ＝ ２
’ＨｅａｄｅｒＬｅｎｇｔｈ’ ＝ ４
’ＲｏｕｔｅＬｅｎｇｔｈ’ ＝ ３
’ＬｏｃａｌＩＤ＃０’ ＝ １
’ＬｏｃａｌＩＤ＃１’ ＝ ２
’ＬｏｃａｌＩＤ＃２’ ＝ ０

このように、’Ｄｉｒｅｃｔｉｏｎ’が’２’であるため、逆方向の転送が実施される。

また、図１５のシーケンス図に示す順方向の転送処理において、経路情報ヘッダに格納するローカルＩＤの情報に、外部ネットワークへの転送に対応する情報を含まない構成も考えられる。この場合、経路情報キャッシュには当該情報が含まれず、その結果、構成される経路情報ヘッダの各フィールドは以下のとおりとなる。
’Ｄｉｒｅｃｔｉｏｎ’ ＝ ２
’ＣｕｒｒｅｎｔＯｆｆｓｅｔ’ ＝ ２
’ＨｅａｄｅｒＬｅｎｇｔｈ’ ＝ ４
’ＲｏｕｔｅＬｅｎｇｔｈ’ ＝ ３
’ＬｏｃａｌＩＤ＃０’ ＝ １
’ＬｏｃａｌＩＤ＃１’ ＝ ２

経路情報ヘッダが構成された後、受信パケットに経路情報ヘッダが付与され、転送処理が実行される（ステップＳ９０２）。この結果、ローカルＩＤ（＝２）に対応した通信インタフェースからパケットが送出され、ＩＤ＝１０の内部転送ノード４００にパケットが転送される。

内部転送ノード４００は、経路情報ヘッダが付与されたパケットを受信すると、図１１に示すフローチャートに従い、経路情報ヘッダが付与されており、かつ逆方向の転送を行うパケットとして転送処理を実行する（ステップＳ９０３）。ここでは、転送経路情報に従って、転送すべきローカルＩＤ（＝１）に対応した通信インタフェースからパケットが送出され、ＩＤ＝１の境界転送ノード３０１ａにパケットが転送される（ステップＳ９０４）。

境界転送ノード３０１ａは、経路情報ヘッダが付与されたパケットを受信すると、図１７に示すフローチャートに従い、経路情報ヘッダが付与されており、かつ逆方向の転送を行うパケットとして転送処理を実行する（ステップＳ９０５）。

さらに経路情報ヘッダの’ＣｕｒｒｅｎｔＯｆｆｓｅｔ’が’０’であることから、図１０のステップＳ２０３において外部ネットワークへの転送と判定され、ステップＳ２０５において経路情報ヘッダが削除される。このとき、境界転送ノード３０１ａの経路情報キャッシュには既に図１８（ａ）に示すエントリが記録されているため、内容が重複する新たな経路情報キャッシュを追加することなく、前記エントリの記録時刻の更新を行う。その後、経路情報ヘッダ削除後のパケットの情報（宛先アドレス１９２．１６８．０．５０）を使って転送処理を実施する。この結果、前記パケットは、宛先である通信ノード１００ａへと転送される（ステップＳ９０６）。

以上のように、本発明の第２の実施形態によれば、境界転送ノード３０１ａ、３０１ｂが、経路管理サーバ５００から経路情報を取得した際、あるいは経路情報ヘッダを削除する際に、経路管理サーバ５００から取得した経路情報、また、経路情報ヘッダに含まれる経路情報を記録し、経路情報キャッシュとして利用する。このため、経路管理サーバ５００に経路要求を送信する頻度を減らし、経路管理サーバ５００の負荷を低減することができる。

さらに、本発明の第２の実施形態によれば、パケットがある宛先に送られた際に記録された経路情報のキャッシュを、逆方向のパケット、つまり前記パケットの送信元に送られたパケット用の経路情報ヘッダを構成する際にも利用しているため、経路管理サーバ５００の負荷の低減効果を高めることができている。

以上、本発明の好適な実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、上記した各実施形態では、リンクの両端の近隣ノード間で共有しているリンクＩＤを用いるものとして説明したが、ローカルＩＤとして、通信インタフェースの識別子を用いることも可能である。この場合、双方向の転送を実施する場合は、近隣ノード間で通信インタフェースの識別子を交換し、情報を共有すればよい。もちろん、近隣ノード間で通信インタフェースの識別子の交換を行わずに、一方向の転送を実施することも可能である。

またさらに、リンクＩＤや通信インタフェースの識別子に代えて、第３のローカルＩＤを採番し、これをリンクＩＤや通信インタフェースに紐付けておく変形構成も採用可能である。

また、例えば、上記した実施形態では、個々の転送ノードがローカルＩＤ決定部を備えて、それぞれローカルＩＤを決定するものとして説明したが、経路管理サーバにて各転送ノードの構成情報を入手可能である場合には、経路管理サーバがローカルＩＤを決定し、それぞれの記録部に転送テーブルを記憶させる構成も採用可能である。この場合、個々の転送ノードのローカルＩＤ決定部を省略することができる。またさらに、経路管理サーバが各転送ノードの接続関係も入手可能であり、隣接するノード同士でが重複しないようにローカルＩＤを設定可能である場合には、個々の転送ノードの近隣情報通知部も省略することが可能である。

また、上記した実施形態の経路管理サーバ５００は、非特許文献１のオープンフローコントローラにて実現することができ、この場合、転送ノードは、オープンフロースイッチにて実現することができる。

また、上記した実施形態の経路管理サーバ５００は、専用のサーバとして実現することもでき、転送ノードとしては、上記オープンフロースイッチのほか、ＩＰ網におけるルータ、ＭＰＬＳ網におけるＭＰＬＳスイッチにて実現することができる。その他、サーバがネットワーク内の転送ノードを集中管理するようなネットワークであれば、本発明を適用することが可能である。

データセンタなどの商用ネットワークでは、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）や、負荷分散のため、宛先アドレス、送信元アドレス、使用プロトコルといった様々な条件により、パケットの転送経路を厳密に制御する必要がある。本発明によれば、経路情報を増やすことなくパケットのオーバヘッドを抑制しつつ、転送経路を厳密に指定することを可能とする。したがって、本発明はデータセンタなどの商用ネットワークへ好適に適用可能である。
なお、上記の特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

１００、１００ａ、１００ｂ 通信ノード
２００ 転送ノード
３００、３００ａ、３００ｂ、３０１、３０１ａ、３０１ｂ 境界転送ノード
３１０ 通信インタフェース
３２０ パケット転送部
３３０ ヘッダ操作部
３４０ ローカルＩＤ決定部
３５０ 近隣情報通知部
３６０ 経路取得部
３７０ 記録部
３６０Ａ 経路取得部
３７０Ａ 記録部
３８０ キャッシュ管理部
４００ 内部転送ノード
４１０ 通信インタフェース
４２０ パケット転送部
４３０ ローカルＩＤ決定部
４４０ 近隣情報通知部
４５０ 記録部
５００ 経路管理サーバ
５１０ 通信インタフェース
５２０ 経路情報収集部
５３０ 経路要求処理部
５３１ 経路計算部
５４０ 経路情報記録部
６００ データ転送ネットワーク
７００ 外部ネットワーク

Claims (20)

1. データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を含む転送経路情報を構成する経路管理サーバと、
   前記転送経路情報を格納したヘッダが付加されたパケットを、前記転送経路情報に従って転送する転送ノードと、を含み、
   前記転送ノードのうち、外部ネットワークとの境界に位置する転送ノードが、前記外部ネットワークから受信したパケットへの前記転送経路情報を格納したヘッダの付加または前記外部ネットワークへ送信するパケットから前記転送経路情報を格納したヘッダの削除を行うヘッダ操作部を備える通信システム。
2. 前記識別子は、少なくとも一の転送ノード内で一意性を有することを特徴とする請求項１の通信システム。
3. 前記識別子は、少なくとも一の転送ノードと、該転送ノードと隣接する転送ノードとの間において一意性を有することを特徴とする請求項１の通信システム。
4. 前記ヘッダは、さらに、転送方向を示す情報を含む請求項１から３いずれか一の通信システム。
5. 前記外部ネットワークとの境界に位置する転送ノードは、さらに、前記ヘッダに含まれる情報を保持するキャッシュ管理部を備え、
   同一の宛先パケットに対して、前記保持した情報を用いて構成したヘッダを付与する請求項１から４いずれか一の通信システム。
6. 前記外部ネットワークとの境界に位置する転送ノードは、さらに、前記ヘッダを削除した際に、当該ヘッダに含まれる情報を保持するキャッシュ管理部を備え、
   前記ヘッダを削除したパケットの送信元に対して送られた逆方向のパケットに対して、前記保持した情報を用いて構成したヘッダを付与する請求項１から４いずれか一の通信システム。
7. 前記ヘッダには、パケットの転送先が外部ネットワークであるか否かを前記外部ネットワークとの境界に位置する転送ノードが区別するための情報を含めることが可能である請求項１から６いずれか一の通信システム。
8. さらに、前記個々の転送ノードの接続情報を保持し、前記外部ネットワークとの境界に位置する転送ノードからの要求に応じて、転送経路情報を作成して提供する経路管理サーバを備える請求項１から７いずれか一の通信システム。
9. 前記個々の転送ノードが、前記経路管理サーバに対して、自装置に備えられている通信インタフェースまたは自装置と隣接するノードとの間に張られたリンクを識別するための識別子を通知する近隣情報通知部を備え、
   前記経路管理サーバは、前記個々の転送ノードから通知された情報に基づいて、前記境界転送ノードに提供する転送経路情報を作成する請求項８の通信システム。
10. 前記個々の転送ノードが、隣接する転送ノードと情報交換を行って、自装置と隣接する転送ノード間の通信インタフェースの対応関係を取得し、前記ヘッダに含まれる転送方向に基づいてパケットを転送する請求項４の通信システム。
11. 第一のネットワークと第二のネットワークとの境界に配置される境界転送ノードであって、
    前記第一のネットワークに配置された転送ノードと通信可能な第一の手段と、
    前記転送ノードの通信インターフェースまたは前記転送ノード間のリンクを識別するための識別子を含む転送経路情報を格納したヘッダを前記第二のネットワークから受信したパケットに付加する第一の処理、または、前記ヘッダを前記第二のネットワークに送信するパケットから削除する第二の処理の少なくとも一つを実行する第二の手段とを備える境界転送ノード。
12. さらに、前記ヘッダに含まれる情報を保持する第三の手段を備え、
    同一の宛先パケットに対して、前記保持した情報を用いて構成したヘッダを付与する請求項１１の境界転送ノード。
13. さらに、前記ヘッダを削除した際に、当該ヘッダに含まれる情報を保持する第三の手段を備え、
    前記ヘッダを削除したパケットの送信元に対して送られた逆方向のパケットに対して、前記保持した情報を用いて構成したヘッダを付与する請求項１１の境界転送ノード。
14. 第一のネットワークに配置された転送ノードの接続情報に基づいて、前記転送ノードの通信インタフェースまたは前記転送ノード間のリンクを識別するための識別子を含む転送経路情報を作成する経路計算部と、
    前記第一のネットワークと第二のネットワークとの境界に配置された境界転送ノードからの要求に応じて、前記作成した転送経路情報を送信する経路要求処理部と、を備え、
    前記経路要求処理部は、前記転送ノードに、前記転送経路情報を格納したヘッダを前記第二のネットワークから受信したパケットに付加する第一の処理、または、前記ヘッダを前記第二のネットワークに送信するパケットから削除する第二の処理の少なくとも一つを、前記転送ノードに実行させる
    ことを特徴とする経路管理サーバ。
15. 少なくとも一の転送ノード内で一意性を有する識別子を含む態様で転送経路情報を作成する求項１４の経路管理サーバ。
16. 少なくとも一の転送ノードと、該転送ノードと隣接する転送ノードとの間において一意性を有する識別子で転送経路情報を作成する請求項１４または１５の経路管理サーバ。
17. 前記転送経路情報に加えて、転送方向を示す情報を前記境界転送ノードに送信し、転送方向を示す情報を含んだヘッダを作成させる請求項１４から１６いずれか一の経路管理サーバ。
18. 前記転送経路情報に加えて、前記境界転送ノードに対し、前記第二のネットワークへ転送する場合とそれ以外の場合とを前記境界転送ノードが区別するための情報を送信し、前記第二のネットワークへ転送するものであるか否かの情報を含んだヘッダを作成させる請求項１４から１７いずれか一の経路管理サーバ。
19. 前記個々の転送ノードから通知された情報に基づいて、前記第一のネットワーク内のネットワークトポロジ情報を構築する経路情報収集部を備え、
    前記経路計算部は、前記ネットワークトポロジ情報に基づいて経路計算を行う請求項１４から１８いずれか一の経路管理サーバ。
20. 第一のネットワークと第二のネットワークとの境界に配置される境界転送ノードの通信方法であって、
    前記第一のネットワークに配置された転送ノードと通信し、
    前記転送ノードの通信インターフェースまたは前記転送ノード間のリンクを識別するための識別子を含む転送経路情報を格納したヘッダを前記第二のネットワークから受信したパケットに付加する第一の処理、または、前記ヘッダを前記第二のネットワークに送信するパケットから削除する第二の処理の少なくとも一つを実行する
    ことを特徴とする通信方法。

Images