JP2004274703A - ルータ装置及びパケット転送制御方法 - Google Patents

ルータ装置及びパケット転送制御方法 Download PDF

Info

Publication number
JP2004274703A
JP2004274703A JP2003323667A JP2003323667A JP2004274703A JP 2004274703 A JP2004274703 A JP 2004274703A JP 2003323667 A JP2003323667 A JP 2003323667A JP 2003323667 A JP2003323667 A JP 2003323667A JP 2004274703 A JP2004274703 A JP 2004274703A
Authority
JP
Japan
Prior art keywords
packet
user network
router
address
connections
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2003323667A
Other languages
English (en)
Other versions
JP4277189B2 (ja
Inventor
Kenichi Nagami
健一 永見
Ikuo Nakagawa
郁夫 中川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intec NetCore Inc
Original Assignee
Intec NetCore Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intec NetCore Inc filed Critical Intec NetCore Inc
Priority to JP2003323667A priority Critical patent/JP4277189B2/ja
Publication of JP2004274703A publication Critical patent/JP2004274703A/ja
Application granted granted Critical
Publication of JP4277189B2 publication Critical patent/JP4277189B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】 マルチホーム接続されたユーザネットワークへのパケットトラフィックを、複数のリンクを有効に利用して転送する。
【解決手段】 インターネット内に設けられたディストリビューションルータ(DR)は、ユーザネットワークを宛先とする(P(X)を宛先に含む)パケットを受信すると、冗長パケットを作成し、例えば、受信したパケットをあるプロバイダネットワーク(ISP−A)がユーザネットワークに提供する接続(リンクA)を通ってユーザネットワークの境界ルータ(UR)に到達する経路へ、作成した冗長パケットを別のプロバイダネットワーク(ISP−B)がユーザネットワークに提供する接続(リンクB)を通ってURに到達する経路へ、転送するため、いずれかの経路でパケットロスが起きても、ユーザネットワークでは、紛失したパケットを別の経路で受信もしくは復元することができる。
【選択図】 図2

Description

本発明は、複数のプロバイダ・ネットワークと接続する(いわゆる「マルチホーム接続」を行う)ユーザネットワークに対して提供するサービスに関し、特に、インターネットとユーザネットワークとの間のパケット転送の信頼性を高める機構に関する。なお、本明細書において、「複数の」プロバイダという場合には、ユーザネットワークに「複数の」リンク(インターネット接続)を提供するものを意味し、単一のインターネット・サービス・プロバイダ(ISP)が「複数の」プロバイダとして機能することも可能である。同様に、各プロバイダのネットワークが、物理的に分離したものである必要はなく、単一のネットワークを「複数の」プロバイダネットワークとして機能させることも可能である。
ユーザネットワーク(例えば企業ネットワークやSOHO(Small Office Home Office)ネットワーク)がより確実なインターネット接続性を獲得するために、「マルチホーム接続」と呼ばれる技術が使用されている。これは、ユーザネットワークが、二つ以上のISPのそれぞれからIP(Internet Protocol)アドレスの割り当てを受けることにより、一つのISPとの間のリンクがダウンしても、他のISPとの間のリンクによりインターネット接続性を確保することができるものである。
このような技術として、図1(a)(b)に示す二つの方式が提案されている(例えば、非特許文献1参照)。ユーザネットワークは、ISP−AからアドレスとしてプレフィックスAを割り当てられ、ISP−BからアドレスとしてプレフィックスBを割り当てられているものとする。プレフィックスとは、IPアドレスの上位所定ビットを指し、これによりネットワークが特定される。IPアドレスの残りのビットは、そのネットワーク内の複数のホストに、各ホストを特定するための情報として割り当てることができる。
ユーザネットワークには、ISP−Aとの間の接続点に設けられたユーザ境界ルータ−Aと、ISP−Bとの間の接続点に設けられたユーザ境界ルータ−Bとがある。これらのユーザ境界ルータは、IBGP(内部BGP:BGP(Border Gateway Protocol)は、インターネットにおいてルーティング情報を交換するためのプロトコルの一つ)により、ルーティング情報を共有している。そして、それぞれのユーザ境界ルータは、インターネットに対し、ルーティングプロトコルBGPを用いて、アドレスの広告(アナウンス)を行う。
図1(a)の方式では、通常時には、ユーザ境界ルータ−AからISP−A経由でプレフィックスAを広告し、ユーザ境界ルータ−BからISP−B経由でプレフィックスBを広告している。したがって、プレフィックスA宛のパケットはISP−A経由でユーザネットワークへ転送され、プレフィックスB宛のパケットはISP−B経由でユーザネットワークへ転送されることになる。
そして、例えばユーザネットワークとISP−Bの間の接続が失われたときには、ユーザ境界ルータAからISP−A経由でプレフィックスAとプレフィックスBの両方を広告する。すると、プレフィックスB宛のパケットもISP−Aを経由することによりユーザネットワークへ転送されるので、インターネット接続性を維持することができる。
図1(b)の方式でも、通常時には、ユーザ境界ルータ−AからISP−A経由でプレフィックスAを広告し、ユーザ境界ルータ−BからISP−B経由でプレフィックスBを広告している。そして、ISP−Bとの間の接続が失われたときには、ユーザ境界ルータ−AからプレフィックスBを広告するが、その広告は、ISP−Bの境界ルータに対して、間接的な(ISP−Aの境界ルータを介する)BGPによって行われる。すると、プレフィックスB宛のパケットは、ISP−Bを経由した後、ISP−Bの境界ルータからISP−Aをトンネルすることにより、ISP−Aとの間のリンクを通ってユーザネットワークに到達することになる。
このようなマルチホーム接続の技術を、IPv4ネットワークだけではなくIPv6ネットワークに適用しようとする提案も、なされている(例えば、非特許文献2参照)。
T. Bates et al., "RFC 2260: Scalable Support for Multi-homed Multi-provider Connectivity," January 1998, Internet Engineering Task Force (IETF) <URL: http://www.ietf.org/rfc/rfc2260.txt?number=2260> J. Hagino et al., "RFC 3178: IPv6 Multihoming Support at Site Exit Routers," October 2001, IETF <URL: http://www.ietf.org/rfc/rfc3178.txt?number=3178>
図1(a)の方式では、あるISP経由で別のISPが割り当てたアドレスを広告することを許すことになるため、インターネットにおいて交換されるルーティング情報の量が爆発的に増えてしまう可能性がある。
図1(b)の方式では、ユーザネットワークとISP−Bの間のリンクがダウンしたときも、プレフィックスBはインターネットの内部においてはあくまでISP−Bから広告されることになるので、ルーティング情報の増加という問題は起こらないが、現実問題として、ISPがこのような方式を採用する可能性は低い。それは、各ISPのユーザに対する課金が、各ISPが提供したインターネットとの間のトラフィック量に応じてなされることによる。すなわち、ISP−Bとの間のリンクがダウンしており、ISP−Aがその代わりのリンクを提供しているにも拘らず、ユーザに課金できるのは、ユーザネットワークとインターネットの間のトラフィックを担っているISP−Bということになり、ISP−Aにとってはビジネス上デメリットしかないからである。
さらに、マルチホーム接続をするユーザネットワークとしては、上記のように、あるISPの接続がダウンした場合のバックアップとして別のISPの接続を利用するだけでなく、両方のISPの接続が維持されている状態でこれら両方を有効に利用できることが、望ましい。特に、接続がダウンしなくとも、転送される一連のパケット群のうち、一部のパケットが紛失することがあり、このようなパケットロスに対処するために、ISPとの間の複数のリンクを活用する仕組みが、望まれる。
しかし、上述した従来方式では、複数のISPのリンクが使用できる通常時においては、プレフィックスA宛のパケットがISP−A経由でユーザネットワークに到達し、プレフィックスB宛のパケットがISP−B経由でユーザネットワークに到達することが可能になっているだけであり、いずれにおいても、パケットロスが起きた場合には、TCP等のプロトコルを使って、紛失したパケットを同じ経路で再送するしかなかった。
また、ユーザネットワーク内のノードが、ISPから割り当てられたアドレスではなく、独自のアドレス(例えばPI(Provider Independent)アドレス)を使用する構成の場合は、両方のISP経由で独自アドレスのプレフィックスを広告することになり、インターネットにおいて交換されるルーティング情報の量が爆発的に増えるという問題が残る。
本発明は、以上のような事情を考慮し、まず、インターネット内でのルーティング情報の量の爆発的増加を防ぎつつ、ISPが現実問題として採用しやすいマルチホーム接続方式を提供することを目的とする。ここで、マルチホーム接続とは、一つのユーザネットワークに対し、複数もしくは単一のISPから複数のリンク(インターネットとの接続)を提供することをいう。そして、本発明はさらに、ユーザネットワークがマルチホーム接続されていることを生かして、ユーザネットワークとインターネットとの間のパケット転送で、パケットロスが起きても、再送が必要となる確率を低くすることができる機構を提供することを目的とする。
本発明は、インターネットを構成するルータとして、次のようにパケット転送を制御する新規なルータを導入する。ここで、コンテンツ配信サーバ等も、本発明に係るルータに該当する。サーバの場合は、ユーザネットワーク宛のパケットを、自装置の外から受信するのではなく、自装置内のアプリケーションから受信することになる。
本発明に係るルータは、インターネットとの接続を複数提供されるユーザネットワークを宛先とするパケットを受信すると、そのユーザネットワークのアドレスを含むパケットに基づいて、ユーザネットワークに提供される複数の接続のうちの少なくとも二つを特定するとともに、受信したパケットの冗長パケットを作成する。そして、特定した接続のうちの一つに対応するアドレスに従って本ルータからユーザネットワークへパケットが転送される(いわば仮想的なトンネルが設定されている)経路へ、受信したパケット及び作成した冗長パケットのうちの一部を転送するとともに、特定した接続のうちの他の一つに対応するアドレスに従って本ルータからユーザネットワークへパケットが転送される(別の仮想的なトンネルが設定されている)経路へ、受信したパケット及び作成した冗長パケットのうちの他の一部を転送する。これらの仮想的なトンネルのためには、例えば後述する3通りのパケット転送方法が利用できる。
本発明によれば、マルチホーム接続を実現するために、インターネットを構成する多数のルータのうちごく一部である、本発明に係るルータとして機能可能なものだけに、ユーザネットワークのアドレスと各接続に対応するアドレスとの対応を知るための情報が送れば済むため、インターネット内でのルーティング情報の量が爆発的に増えることが無くなる。さらに、本発明によれば、特定された接続に対応するアドレスに従って本発明に係るルータからユーザネットワークへパケットが転送される経路が用いられるため、ある接続(リンク)を通してユーザネットワークに到達するパケットは、そのリンクを提供するプロバイダのネットワークを経由して転送されるものであるから、各プロバイダは自身の提供したサービスに見合った課金ができることになる。
さらに、本発明によれば、ユーザネットワークに提供される少なくとも二つの接続を利用して、冗長性を有するパケット群(受信したパケットとそれから作成される冗長パケット)が転送されるため、いずれかの接続を利用する経路でパケットロスが起きても、他の接続を利用する経路で受信されたパケットから紛失したパケットに含まれていたデータを復元できる可能性が高くなり、パケット再送が必要になる可能性を低くすることができる。
上記の本発明に係るルータにおける冗長パケットとして、例えば、受信したパケットを複製することにより作成される、重複パケットを用いることができる。この場合、受信したパケットと、作成した重複パケット(受信したパケットと同一のパケット)とが、異なる経路で(異なる接続を利用して)転送されるようにするとよい。これにより、ユーザネットワークは、一方の経路においてパケットロスがあっても、他方の経路から紛失したパケットと同一のパケットを受信することができるので、再送要求をしなくて済むようになる。さらに、本発明に係るルータにおいて、受信したパケット及び作成した重複パケットに同一のパケット識別子を付与してから、転送してもよい。すると、ユーザネットワークが、両方の経路(複数の接続)からパケットロスなく重複するパケットを受信した場合には、各パケットに付与されているパケット識別子を用いて、複数の同一のパケットのうちの一つを残して他を廃棄することができる。
上記の本発明に係るルータにおける冗長パケットとして、例えば、受信したパケットに含まれるデータを誤り訂正符号化して作成される、誤り訂正パケットを用いることができる。この場合、特定された二つの接続を利用する経路に、本来の経路とバックアップの経路が存在するならば、受信したパケットが本来の経路で転送され、作成した誤り訂正パケットがバックアップの経路で転送されるようにしてもよい。あるいは、受信したパケットと作成した誤り訂正パケットとを区別せずに、これらから成るパケット群の一部がある経路に、他の一部が他の経路に、転送されるようにしてもよい。いずれの転送方法でも、ユーザネットワークは、ある経路においてパケットロスが起きて、受信されるべきパケットが受信されなくても、その経路及び他の経路から受信された誤り訂正パケットを含むパケット群を用いて、紛失したパケットを復元することができる。ユーザネットワークが、パケットロスなく受信されるべきパケットを全て受信した場合には、誤り訂正パケットを使用せずに廃棄してもよい。
上記の少なくとも二つの経路の特定(本来の経路とバックアップの経路を区別する場合にはそれも含めた特定)は、受信したパケットに基づいて行われるが、そのために、受信したパケット内の情報である宛先アドレス、ポート番号、送信元アドレス、ポート番号、プロトコルID等を参照することができる。さらに、ネットワーク層より上位層の情報を参照すれば、より細かな制御が可能となる。
上記の少なくとも二つの経路の特定(本来の経路とバックアップの経路を区別する場合には、本来の経路の選択を含む)を、各接続を利用してユーザネットワークに提供される通信環境に基づいて行うことも可能である。さらに、受信したパケットと作成した誤り訂正パケットとから成るパケット群の一部をある経路に、他の一部を他の経路に、転送する場合、パケット群のどの一部をどの経路に転送するかの選択を、上記の通信環境に基づいて行うこともできる。
上記の通信環境の一例として、各プロバイダネットワークとユーザネットワークとの間のトラフィック量を用いることができる。これは、各リンクのインターネット−ユーザネットワーク間のトラフィック量であるが、入出力トラフィックの双方を合わせた量でも良いし、ユーザネットワークへの入力トラフィックの量を検出するのでも良い。これらのトラフィック量は、ユーザネットワークにおいて観測することができる。これにより、本発明に係るルータは、例えばあるリンクのトラフィック量が多ければ、そのリンクを通る経路を選択していたパケット群のうちの一部について、他のリンクを通る経路を選択するように切り替えることが可能となる。
上記通信環境の他の例として、本発明に係るルータから各接続(リンク)を通ってユーザネットワークに至るそれぞれの経路の遅延、パケット損失率、ジッタ、帯域等の通信品質パラメータを用いることもできる。これらの通信品質パラメータは、各経路に対して計測されるものであり、ユーザネットワークにおいて観測しても良いし、本発明に係るルータがユーザネットワークとの間でメッセージ交換することにより獲得しても良い。これにより、本発明に係るルータは、例えばあるリンクを通る経路の遅延が大きければ、遅延に敏感なデータ(例えば音声通話や映像ストリーミング等)を運ぶパケット群について、他のリンクを通る経路を選択するように切り替えることが可能となる。また、例えば、受信したパケットと作成した誤り訂正パケットとから成るパケット群のうち、帯域の大きな方の経路に多くのパケットを、帯域の小さな方の経路に残りのパケットを、転送することが可能になる。
ここでは、動的に変化するトラフィック量や通信品質パラメータを、通信環境の例として取り上げたが、静的な値すなわち予め本発明に係るルータに記憶された値を、通信環境として用いることもできる。例えば、あるプロバイダがユーザネットワークに提供するリンクの帯域が、別のプロバイダが提供するリンクの帯域よりも大きいことが予め分かっている場合、本発明に係るルータは、これらの帯域を通信環境として参照し、ユーザネットワーク宛のパケット群を、各経路に対応する帯域に応じて、ある経路には多く、別の経路には少なく振り分けることが可能となる。また、あるプロバイダ経由の経路が別のプロバイダ経由の経路よりも遅延が大きいことが予め分かっている場合も、本発明に係るルータは、これらの帯域を通信環境として参照し、ユーザネットワーク宛のパケット群のうち遅延に敏感なデータを運ぶものについては、遅延の小さい経路を選択することが可能になる。
また、ユーザネットワークに提供される各接続(リンク)について、その接続を利用するパケット転送経路が正常に動作しているか(リンクが切断されたりプロバイダネットワーク内の故障によりリンクまでの到達性が失われたりしていないか)に基づいて、パケット転送経路の特定や選択を行うことも可能である。このためには、例えば、本発明に係るルータが、各接続(リンク)に対応するアドレスに向けて確認メッセージを送信し、これに対する返答メッセージの有無またはその内容により、各リンクを利用する本ルータからユーザネットワークへの経路が、正常に動作しているか否かを確認すれば良い。
上記の確認メッセージを所定間隔毎に送信することにより、現在の各経路の状況を調べることができるが、この送信間隔を、各経路の通信品質に基づいて変更するようにしても良い。例えば、ある経路の帯域が大きいときには、送信間隔を短くして頻繁に確認メッセージを送信し、帯域が小さいときには、送信間隔を長くして送信頻度を抑えれば、確認メッセージのような試験トラフィックのために実トラフィックが使用できる帯域を過度に圧迫してしまうことを、適切に回避することが可能となる。
選択した経路(選択した接続に対応するアドレスに従った経路)でパケットを転送する方法としては、例えば次の3通りがあり得る。なお、この例では、受信したパケットの宛先アドレスフィールドにはユーザネットワークのアドレスが、送信元フィールドには送信元のネットワークのアドレスが、それぞれ書き込まれているものとする。ここで、ユーザネットワークのアドレスとしては、いずれか一つのプロバイダから割り当てられたアドレスを用いても良いし、PIアドレスのようなユーザ独自のアドレスを用いても良い。
一つ目は、IPパケットのカプセル化を利用するものであり、本発明に係るルータは、選択した接続を提供するプロバイダがその接続に対応して割り当てたアドレス(好ましくは、ユーザネットワークの境界ルータ(ユーザルータ)に割り当てたアドレス)を宛先とし、自装置のアドレスを送信元とする新しいパケットで、受信したパケットを包んで転送する。このカプセル化されたパケットを受信したユーザルータでは、カプセルを解いて元のパケットの宛先アドレスを参照し、宛先ホストへパケットを転送する。
二つ目は、MPLS(Multi-Protocol Label Switching)と呼ばれる技術を利用するものであり、本発明に係るルータを出発点とし各接続(リンク)を通ってユーザネットワークへ至る各経路に沿って、ネットワーク層より下位層の情報であるラベルに基づいてパケットが転送されるラベルスイッチングパスが設定されているとする。本発明に係るルータは、選択した経路に対応するラベルスイッチングパスのラベルを、受信したパケットに付与して転送する。このラベルスイッチングパスからパケットを受信したユーザルータでは、ラベルを取り除き、パケットの宛先アドレスをネットワーク層で参照することにより、宛先ホストへパケットを転送する。なお、ラベルスイッチングパスは、各接続を提供するプロバイダがユーザルータに割り当てたアドレスに従って設定され、ユーザルータは、ラベルスイッチングパスの設定のときに、そのラベルスイッチングパスの出発点となるルータ(本発明に係るルータ)のアドレスを通知されているため、受信したパケットに付与されているラベルを参照すれば、本発明に係るルータのアドレスを獲得できる。
三つ目は、ユーザネットワーク内のホストはユーザルータを介さない限りインターネットと通信できないことに着目し、本発明に係るルータにおいてパケットの宛先アドレスを変換してしまうものである。すなわち、本発明に係るルータが、選択した接続を提供するプロバイダがその接続に対応して(好ましくはその接続が提供されるユーザルータに)割り当てたアドレスに基づいて、パケットの宛先アドレスフィールドを書き換えて転送する。ここで元のパケットに記入されていた情報は失われてしまうが、必ず通過することになるユーザルータにおいて、アドレスの逆変換が行われて情報が復活する。すなわち、ユーザルータは、受信したパケットの宛先アドレスフィールドを、ユーザネットワークのアドレスに基づいて書き換えて、宛先ホストへ転送する。
一つ目と二つ目の方法では、ユーザネットワークの境界ルータにおいて、受信したパケットの経路選択が行われたルータ(本発明に係るルータ)のアドレスを知ることができるというメリットがある。三つ目の方法は、IPパケットのパケットサイズ(MTU:Max Transfer Unit)が変化しないというメリットがある。
本発明に係るルータにおいて特定の対象となる各経路の情報として、例えば、ユーザネットワークのアドレスと各接続を提供するプロバイダが各接続に対応して(好ましくは各接続が提供される各ユーザルータに)割り当てたアドレスとの対応を表わす情報(この情報をルータ登録情報と呼ぶ)が、本発明に係るルータに記憶される。
この情報を、インターネットを構成する他のルータであって本発明に係るルータとして機能可能なものに対して送信すると、その送信を受けた他のルータも、本発明に係るルータと同様に、ユーザネットワークに至る少なくとも二つの接続を特定し、冗長性を有するパケット群を転送する動作を行うようになる。
一方、本発明に係るルータが、インターネットを構成する他のルータに対して、ユーザネットワークのアドレスと自装置のアドレスとの対応を表わす情報を送信すると、その送信を受けた他のルータは、ユーザネットワークのアドレスを宛先とするパケットを本発明に係るルータへ転送するようになるので、本発明に係るルータが、その転送されてきたパケットについても、ユーザネットワークに至る少なくとも二つの接続を特定し、冗長性を有するパケット群を転送する動作を行う。
本発明は、インターネットを構成するルータとして、以上のように新規なルータを導入する一方で、ユーザルータとして、次のようにパケット転送を制御する新規なルータを導入する。ユーザルータとは、インターネットとの接続を複数提供されているユーザネットワークの、インターネットとの接続点に設けられたルータである。本発明に係るユーザルータは、複数の接続の全てに対応するように複数のネットワークインタフェースを備える装置として構成しても良いし、複数の接続のうちの一部に対応するネットワークインタフェースを備える装置として構成しても良い。後者の場合、各接続に対応する各ユーザルータ装置が、例えばIBGPやOSPFでルーティング情報を共有し、集合体としてインターネットとマルチホーム接続する境界ルータの機能を果たすように構成しても良い。
本発明に係るユーザルータは、自装置が属するユーザネットワークの識別情報と各接続に対応して割り当てられたアドレスのうち自装置に割り当てられたアドレス(自装置が提供されている接続に対応するアドレス)に関する情報とを送信し、ユーザネットワークを宛先とするパケットを、複数の接続のうち自装置に提供されている接続に対応するアドレスに従った経路で受信する。この受信に用いられる経路は、インターネットを構成する、上述した本発明に係るルータにより特定された少なくとも二つの接続のうちの少なくとも一つであり、受信されるパケットは、上述した本発明に係るルータにより転送された冗長性を有するパケット群のうちの少なくとも一部である。本発明に係るユーザルータが、上記の情報を送信することにより、本発明に係るルータは、特定の対象となる各経路の情報を得ることができる。
上記の本発明に係るユーザルータにおいて、冗長性を有するパケット群が受信された場合に、この冗長性を削除することも可能である。例えば、同一のパケットを複数含むパケット群が受信された場合には、重複するパケットを廃棄する。誤り訂正パケットを含むパケット群が受信された場合には、パケットロスがあれば誤り訂正をして紛失したパケットを復元し、不要な誤り訂正パケットは廃棄する。このような冗長性の削除は、一つのユーザルータに上記の少なくとも二つの接続が提供されている場合には、当該ユーザルータ内で行うことができ、複数のユーザルータにそれぞれ接続が提供されている場合には、例えば、次の三通りの方式が可能である。
一つ目は、複数のユーザルータ間で、受信されたパケットに関して情報交換し、協調して冗長性の削除を行う方式である。例えば、従たるユーザルータは、情報交換により主たるユーザルータで同一のパケットが受信されていることを知ると、自身が受信したパケットを廃棄する。従たるユーザルータが、情報交換により主たるユーザルータでは受信されなかったパケットを自身が受信していることを知ると、そのパケットを主たるユーザルータもしくは宛先ノードへ転送する。別の例では、主たるユーザルータは、情報交換により受信されるべきパケットがいずれのユーザルータでも受信されなかったことを知ると、従たるユーザルータが受信したパケット群を自身へ転送させ、自身が受信したパケット群と合わせて誤り訂正を行い、受信されなかったパケットを復元する。なお、情報交換により不要であることが分かった誤り訂正パケットは、各ユーザルータにて廃棄する。上記のいずれの例においても、主たるユーザルータと従たるユーザルータは、それぞれ専用のユーザルータを設けるのでもよいし、両方の機能を持つユーザルータが、あるパケットフロー(例えば宛先ノードや送信元ノード等により規定される)については主たるユーザルータとして機能し、別のパケットフローについては従たるユーザとして機能するようにしてもよい。
二つ目は、各ユーザルータが受信したパケットを、ユーザネットワーク内の一つの決まったルータに転送するようにし、そのルータが冗長性の削除を行う方式である。この場合は、その決まったルータが、複数の接続を介してユーザネットワークに受信された冗長性を有するパケット群を全て受信することになるので、そのルータ内で、冗長性の削除を行うことができる。この冗長性の削除を行うルータは、ユーザネットワーク内に一つだけ設けてもよいし、例えば宛先ノードのグループ毎に、複数設けてもよい。二つ目の方法でも、一つ目の方法と同様に、宛先ノードには、冗長性が削除された、送信元ノードが送信した通りのパケット群が、受信されることになる。
三つ目は、各ユーザルータが受信したパケットを、そのままユーザネットワーク内の宛先ノードに転送し、宛先ホストにおいて冗長性の削除を行う方式である。この場合、ユーザネットワーク内の各宛先ノード(各ホスト)に冗長性を削除する機能を備えさせることになるが、一つ目の方法におけるユーザルータ間の情報交換や、二つ目の方法のように特定のルータを経由させる仕組みは、不要である。
本発明に係るユーザルータは、自装置に提供されたリンクを介して(自装置が対応するプロバイダネットワークにより)ユーザネットワークに提供される通信環境を観測し、観測により得られた情報を送信することもでき、その場合、本発明に係るルータは、この情報を上記の通信環境として用いて、経路の特定もしくは選択を行うことができる。
別の方法として、本発明に係るユーザルータが、各リンクを介してユーザネットワークに提供される通信環境を観測して得られた情報に基づいて、ユーザネットワークを宛先とするパケット群のうちどの一部をどのリンクに対応するアドレスに従った経路で転送すべきか(具体的な選択基準)を指示する情報を生成し、この指示情報を送信することにしても良い。この場合、本発明に係るルータは、この指示情報に従うことにより、経路の特定もしくは選択を行うことができる。
さらに別の方法として、本発明に係るユーザルータが、ユーザネットワークを宛先とするパケット群のうちどの一部がどのような通信環境をユーザネットワークに提供するリンクを介してユーザネットワークへ転送されるべきか(抽象的なポリシー)を指示する情報を生成し、この指示情報を送信することにしても良い。この場合、本発明に係るルータは、この指示情報と、それとは別に得た各リンクを介してユーザネットワークに提供される通信環境に関する情報とを照合して、複数のリンクのうち少なくとも二つを本来の経路とバックアップの経路を区別しながら特定したり、冗長性を有するパケット群について少なくとも二つの経路を使い分けるために経路を選択したりすることができる。
なお、本発明に係るルータにおいて、上述した3通りのパケット転送方法のうち一つ目もしくは二つ目が採用された場合には、本発明に係るユーザルータにおいて、受信したパケットの経路選択が行われたルータ(本発明に係るルータ)のアドレスを知ることができ、このアドレスにより特定のルータを指定して、ユーザネットワークに提供される通信環境の観測情報や、その通信環境に基づく指示情報等を送信することができる。すなわち、これらの情報を必要とするルータを特定して、通知することができる。
本発明に係るユーザルータが、ユーザネットワークの識別情報と自装置が提供されている接続に対応して割り当てられたアドレスに関する情報と(これらの情報をユーザ登録情報と呼ぶ)を、インターネットへ送信する方法としては、例えば次の2通りがあり得る。なお、本発明に係るルータが、経路の特定を行うために用いるルータ登録情報は、ここで送信されるユーザ登録情報に基づいて得られるものである。
一つは、複数の接続についての上記のユーザ登録情報を、一つの接続を介して送信する方法である。この場合、他の接続がダウンしたときには、ダウンした接続に対応してユーザルータに割り当てられたアドレスに関する情報が、上記のユーザ登録情報に含まれていればこれを削除して、送信されないようにする。これにより、インターネットを構成するルータは、ダウンしている接続を利用する経路を、選択対象として認識しなくなるため、ユーザネットワークのインターネットとの接続性を確保することができる。
もう一つは、複数の接続のそれぞれについての上記のユーザ登録情報を、それぞれ対応する接続を介して送信する方法である。この場合、ある接続がダウンしたときには、その接続についての上記のユーザ登録情報だけが自動的に届かなくなる。したがって、インターネットを構成するルータは、ダウンしている接続を利用する経路を、選択対象として認識しなくなり、ユーザネットワークのインターネットとの接続性を確保することができる。
上記のユーザ登録情報に含まれるユーザネットワークの識別情報として、ユーザネットワークのアドレス情報を用いても良いし、ユーザネットワークのアドレスとは別の識別子を用いても良い。前者の場合は、本発明に係るルータは、ルータ登録情報を直接的に得ることができるが、インターネット内に誤ったルーティング情報が混入することがないように、ユーザルータから申告されたユーザネットワークのアドレスに誤りがないかを確認することが望ましい。後者の場合は、本発明に係るルータは、ユーザルータから送信された識別子に基づいて、ユーザネットワークのアドレスを求めることにより、ルータ登録情報を得る。
上記のように、転送するパケットに冗長性を付加し、冗長性を有するパケット群をマルチホーム接続に係る少なくとも二つの接続を利用して複数の経路に分散して転送することにより、パケット転送の信頼性を高める機構は、インターネットからユーザネットワークへの下流方向の仮想的なトンネルだけではなく、ユーザネットワークからインターネットへの上流方向の仮想的なトンネルについても、適用することが可能である。上流方向に適用する場合の、本発明の別の発明に係るユーザルータは、次のようなものになる。
すなわち、ユーザルータがユーザネットワーク内のノードからインターネットへのパケットを受信すると、受信したパケットの冗長パケットを作成し、受信したパケット及び作成した冗長パケット(冗長性を有するパケット群)のうちの一部を、複数の接続のうちの一つを通ってインターネット内に設けられたルータに達する仮想的なトンネル(そのルータのアドレスへ向けてパケットが転送される経路)へ転送する。冗長性を有するパケット群のうちの他の一部は、複数の接続のうちの他の一つを通って上記のルータに達する別の仮想的なトンネルへ転送する。ユーザルータが複数ある場合には、冗長性を有するパケット群のうちの一部は、あるユーザルータ(冗長パケットを作成したユーザルータ)に提供されている接続を通って転送され、他の一部は、そのユーザルータから他のユーザルータ経由で、他のユーザルータに提供されている接続を通って転送される。上記のインターネット内のルータは、複数の経路から冗長性を有するパケット群を受信すると、その冗長性を除く機能を備えている。
上述した本発明はいずれも、パケット転送制御方法やルータ装置、ユーザルータ装置としてだけではなく、インターネットを構成するルータとして機能するコンピュータ、もしくは、インターネットとの接続を複数提供されているユーザネットワークの境界に位置しユーザルータとして機能するコンピュータに、インストールされ、実行されるプログラムとしても、そのようなプログラムを記憶する記憶媒体としても、実施可能なものである。
本発明によれば、複数のプロバイダ(複数のISPであっても良いし単一のISPが複数のリンクを提供するのでも良い)からインターネットとの接続を提供されているユーザネットワークを宛先とするパケットを転送する際に、パケットに冗長性を持たせ、且つ、接続が複数あることを生かして、送信元からのパケットを確実に宛先のユーザネットワークに受信させることが可能となる。
以下、本発明の実施の形態について、図面を用いて説明する。
図2は、本発明の一実施形態におけるパケット転送の様子を例示したものである。ISP−A〜ISP−Eは、プロバイダのネットワークを表わし、各ネットワーク内には多数のルータ(図示せず)が存在して、IPによる通信を提供している。このようなISP−A〜ISP−Eと、これらプロバイダネットワークの間を接続する多数のルータ(図示せず)とから、インターネットが構成されている。このインターネット内に、本発明により新たに導入されるルータ(ディストリビューションルータ)DR1〜DR4が設けられる。
ユーザネットワークは、ISP−AからリンクAを介してインターネットとの接続を提供され、ISP−BからリンクBを介してインターネットとの接続を提供されている。このようにマルチホーム接続されたユーザネットワークの境界には、ユーザルータURが設けられ、URは、リンクAに対応する第1のインタフェースと、リンクBに対応する第2のインタフェースを有している。以下の説明は、一つのURが二つのインタフェースを持つ例で進めるが、ユーザネットワークの境界にリンクAに対応する第1のURとリンクBに対応する第2のURとを設けて二つのURに必要な情報を共有させる例でも、同様のことが実現できることを最後に示す。
ユーザネットワークには、多数のホスト(図示せず)が存在し、それぞれのホストが、P(X)をプレフィックス(上位所定ビット)とするIPアドレスXを持っている。このP(X)は、ISP−Aから割り当てられたアドレスプレフィックスAとしても良いし、ISP−Bから割り当てられたアドレスプレフィックスBとしても良いし、ユーザネットワーク独自のPIアドレスプレフィックスとしても良い。
本実施形態をIPv4ネットワークに適用する場合、各ホストが使用するアドレスは、上述のように、ISP−Aから割り当てられたものとしても、ISP−Bから割り当てられたものとしても、PIアドレスとしても良い。IPv6ネットワークの場合は、経路集約型のルーティング広告が行われることから、PIアドレスの使用が困難なことがあるが、その場合でも、いずれかのISPから割り当てられたアドレスを使えば、本実施形態を適用することができる。勿論、IPv6ネットワークにおいてPIアドレスを使って、本実施形態を適用しても構わない。
URの第1のインタフェースは、ISP−Aから割り当てられたアドレスURaを有し、URの第2のインタフェースはISP−Bから割り当てられたアドレスURbを有する。URaの上位所定ビットはAであり、URbの上位所定ビットはBである。
本実施形態においては、ユーザネットワークのホスト宛にパケットを送信したい送信元ホストS1は、そのパケットの宛先にP(X)をプレフィックスとするアドレスXを書き込んで、インターネットに送出する。DR1〜DR4はいずれも、自身のアドレスとは別に、P(X)をインターネット内に広告している。したがって、S1を発した宛先P(X)のパケットは、最初に到達したDR(S1から最も近いDRであり、この図の例ではDR1)に吸い込まれる。このS1からDR1へのパケット配送は、anycastと呼ばれる技術を利用したものである。
DR1内には、図3に例示するような検索テーブルが記憶されており、上記のようにP(X)を宛先とするパケットを受信すると、そのパケット内の情報(宛先アドレス/ポート、送信元アドレス/ポート、プロトコルID等の少なくとも一部)を検索キーとして、検索テーブルを参照する(詳細後述)。すると、DR1は、受信したP(X)宛のパケットを転送できる経路として、DR1からISP−AとリンクAを通ってURに至る経路(図2中、実線矢印)と、DR1からISP−BとリンクBを通ってURに至る経路(図2中、点線矢印)とが存在することが、特定できる。このように、二つ以上の経路が検索テーブルに記憶されている場合、DR1は、受信したP(X)宛のパケットの冗長パケット(複製パケットもしくは誤り訂正パケット)を作成する。そして、複製パケットが作成される場合、URは、リンクAを通る経路とリンクBを通る経路のいずれにおいてもパケットロスがなければ、両方の経路から同一のパケットを二つ受信するので、そのうち一つを廃棄する。一方の経路でパケットロスがあれば、他方の経路からパケットを一つ受信する。
誤り訂正パケットの作成は、例えばリードソロモン符号のように、前方誤り訂正(Forward Error Correction)ができる符号化を利用して行なわれる。リードソロモン符号では、送信側でn個のパケット(これを元パケットと呼ぶ)のデータに基づいてk個の誤り訂正パケットを作成し、合計n+k個のパケットを転送する。そして、n個の元パケットのうちm個が途中で紛失し、受信側に届かなかったとしても、受信側にm個の誤り訂正パケットが届いていれば、受信したn−m個の元パケットとm個の誤り訂正パケットに基づいて、紛失したm個の元パケットが復元できる(但しm≦k)。本実施形態においては、DR1からは、n+k個のパケット(元パケットと誤り訂正パケット)が、リンクAを通る経路とリンクBを通る経路に分散して転送され、URにおいて、リンクAから受信したパケットとリンクBから受信したパケット(元パケットでも誤り訂正パケットでも良い)が合わせてn個以上あれば、紛失したパケットは復元できるので、n個の元パケットが受信できたことになる。このように、前方誤り訂正をかけて、複数の経路を利用することで、バースト誤りに強いパケット転送が可能になる。
送信元ホストS2が、ユーザネットワークのホスト宛にパケットを送信したい場合も、同様に、P(X)を宛先とするパケットをインターネットに送出すれば、S2に最も近いDR2がこのパケットを受信する。そして、DR2も、P(X)宛のパケットに関して、DR1と同様な検索テーブルを記憶しているので、このテーブルをパケット内の情報を検索キーとして参照した結果に従い、DR2からISP−AとリンクAを通ってURに至る経路(図2中、点線矢印)と、DR2からISP−BとリンクBを通ってURに至る経路(図2中、実線矢印)とを特定し、冗長パケットを作成し、元パケットと冗長パケット(複製パケットもしくは誤り訂正パケット)とを、二つの経路に分散して転送する。
送信元ホストS3が、ユーザネットワークのホスト宛にパケットを送信したい場合も、DR3が、DR1やDR2と同様な検索テーブルを記憶していて、同様の手順で経路の特定と、元パケット及び冗長パケットの分散転送とが行われる。上述した経路の特定と分散転送は、いずれもパケット単位で行われる。
なお、上記の各DRで行われる経路の特定とは、実際には、パケットがDRからURまで仮想的なトンネルにより転送されると想定した場合の、トンネルの出口(リンクAとリンクBのうちどちらを通ってURに到達するか)を決定することである。この仮想的なトンネルは、入口(DR)と出口(URの第1もしくは第2のインタフェース)が規定されれば足りるものであり、その間に経由すべき複数のルータ(図示しないもの)までを入口(DR)で指定する必要はない。このような仮想的なトンネルは、例えば図4(a)〜(c)に示す3通りの方法により形成することができる。
図4(a)は、IPパケットのカプセル化を利用するものであり、例えばDR1で受信したパケット(Xが宛先で、S1が送信元)に、次のように新たなIPヘッダを追加する。DR1で検索テーブルを参照した結果、トンネルの宛先(パケットの転送先)としてURaが得られれば、追加するIPヘッダの宛先をURa、送信元をDR1とする。すると、インターネット内のルータは宛先URaに基づいてこのパケットを転送するので、このパケットはリンクAを通ってURに到着する。URでは、DRで新たに追加されたIPヘッダを取り除き、元のパケットの宛先Xを参照して、ユーザネットワーク内の宛先ホストへこのパケットを転送する。
図4(b)は、MPLSの技術を利用するものであり、トンネルの入口から出口まで、ネットワーク層より下位層の情報(ラベル)を参照するだけで(IPアドレスを参照せずに)パケットが転送できるように、ラベルスイッチングパスが設定される。ラベルスイッチングパス(LSP)は、DRからURa(URの第1のインタフェース)へのパスと、DRからURb(URの第2のインタフェース)へのパスの2本だけが、常時設定してあるのでも良いが、さらに細かい粒度のパケットフローに対応させて、様々なLSPを必要に応じて設定するのでも良い。
前者の場合、DRの検索テーブルにトンネルの宛先(パケットの転送先)として記憶されるラベルの値は2種類であり、ラベルAを選択することがリンクAを通る経路を選択することを意味し、ラベルBを選択することがリンクBを通る経路を選択することを意味する。
後者の場合、同じURa(リンクA)を経由するパケットフローであっても、特定の宛先ホストに対するパケットフロー専用のLSPを、その他の宛先ホストに対するパケットフローを収容するLSPとは別に設定したり、音声通話のデータを運ぶ(特定のプロトコルIDの)パケットフロー専用のLSPを、その他のデータを運ぶパケットフローを収容するLSPとは別に設定したり、宛先/送信元、アドレス/ポート、プロトコルIDの任意の組合せに対する専用のLSPを設定することができる。この場合は、DRの検索テーブルには、検索キーとして細かい粒度のパケットフローを規定する情報が記憶され、これら各パケットフローに対応してそれぞれのLSPのラベルが記憶されることになる。
そして、例えばDR1で、Xが宛先であるパケットを受信すると、パケットを下位層(例えばデータリンク層)のフレームに分解し、各フレームに、検索テーブルを参照して得られるラベル(例えばリンクAを通るLSPのものとする)を付加する。すると、インターネット内のルータはそのラベルに基づいてこれらのフレームをネットワーク層より下位層で転送し、各フレームはリンクAを通ってURに到着する。URでは、ラベルを取り除き、フレームを元のパケットに組み立て、元のパケットの宛先Xを参照して、ユーザネットワーク内の宛先ホストへこのパケットを転送する。
図4(c)は、トンネルの入口でアドレス変換を、出口でその逆変換を行うものであり、例えばDR1で受信したパケット(Xが宛先で、S1が送信元)の宛先アドレスを、次のように変換する。DR1で検索テーブルを参照した結果、トンネルの宛先(パケットの転送先)としてA(ユーザネットワークがISP−Aから割り当てられたアドレスプレフィックス)が得られたとすると、宛先アドレスXのうちの上位所定ビットをP(X)からAに置き換える。すると、インターネット内のルータは宛先アドレスプレフィックスAに基づいてこのパケットを転送するので、このパケットはリンクAを通ってURに到着する。
アドレス変換方式を採用する場合のURでは、プレフィックスAを宛先アドレスに含むIPパケットを受信すると、受信したパケットの宛先アドレスのうちの上位所定ビットをAからP(X)に置き換える。すると、元のパケットの宛先アドレスが復活するので、この宛先Xを参照して、ユーザネットワーク内の宛先ホストへこのパケットを転送する。URは、プレフィックスBを宛先アドレスに含むIPパケットを受信した場合も、宛先アドレスの上位所定ビットをBからP(X)に置き換える。図4(c)の場合、トンネルを通っている間のパケットからはP(X)の情報は失われているので、トンネルの出口のURが、失われた情報を復活するために、AやBをP(X)に変換するためのアドレス変換表を、予め記憶している。
アドレス変換方式においては、P(X)をAもしくはBに変換するDRと、AもしくはBをP(X)に変換するURで、変換先のアドレスの数が足りないためにマッピングが取れないと動作が困難になるので、P(X)、A、Bのそれぞれのプレフィックスに含まれるアドレスの数が同じに(もしくはA,Bの方が多く)なるように、ISP−A及びBからのアドレス割り当てを受けることになる。アドレス変換方式の利点は、IPパケットカプセル化のようにヘッダを追加するわけではないため、一つのパケットに入るデータの量がトンネルに入る前後で変化することがなく、追加ヘッダの分入らなくなったデータを多数のパケットに分割して送らなければならなくなることもないことである。
なお、図3の検索テーブルを参照する際、各DRは、受信したパケットのヘッダの内容を検索キーとして、最も良く一致するエントリを探す(この方法を「ベストマッチ」と呼ぶ)。二つの経路に元パケット及び冗長パケットを分散したい場合には、最も良く一致するエントリが二つあれば、それらを出力し、一つしかなければ、次に良く一致するエントリを探して、合計二つを出力する。三つ以上の経路に分散したい場合は、同様に、最も良く一致するエントリから順に、必要な数だけエントリを探す。図3の例では、P(X)=10.1.1.x宛のパケットを受信して、そのパケットの宛先アドレスが10.1.1.2であれば、トンネルの宛先としてURaとURbの二つが出力される。そして、両方の経路のそれぞれにおいて、図4(a)の方式でパケットが転送される。
また、DRからURbへのLSPであって、Web通信のパケットフロー用に設定されたもののラベルの値が100であるとすると、図3を参照することにより、受信したパケットのポート番号やプロトコルIDがWeb通信を表わすものであれば、トンネルの宛先としてベストマッチしたラベル100が出力される。加えて、P(X)=10.1.1.x宛のパケットであれば何でも入れることのできるDRからURaへのLSPのラベルの値が200であるとすると、セカンドベストマッチであるラベル200も出力される。そして、両方の経路のそれぞれにおいて、図4(b)の方式でパケットが転送される。
さらに、図3の例では、受信したパケットの送信元ネットワークが2.2.2.xであれば、トンネルの宛先としてベストマッチしたプレフィックスBが出力され、セカンドベストマッチであるプレフィックスAも出力される。そして、両方の経路のそれぞれにおいて、図4(c)の方式でパケットが転送される。
図3には、各DRが複数種類のトンネルを扱えるものである場合の検索テーブルの例を示したが、各DRが扱えるトンネルの種類が単一であっても良く、例えばIPカプセル化のみに対応するDRであれば、検索テーブルからはURaとURbが出力されることになる。また、上記には、検索キー全体に対するベストマッチでテーブルのエントリを選択する例を説明したが、検索キーのうち宛先アドレスの部分のみベストマッチで、残りの部分(ポートや送信元など)はテーブルの上から順に参照して行って最初に一致したエントリと次に一致したエントリを選択するようにしても良い。あるいは、検索キー全体に対して、テーブルの最初の方でマッチしたエントリから順に(ベストマッチかどうかに拘らず)選択するようにしても構わない。
上記のベストマッチした経路を本来の経路として、上記のセカンドベストマッチの経路をバックアップの経路として、使用することも可能である。ベストマッチした経路が複数ある場合には、任意の一つを本来の経路とし、他をバックアップの経路とすればよい。例えば、通常の状況下では、本来の経路一つだけを用いて(冗長パケットを作成せずに)パケット転送しており、特殊な状況が生じたとき(例えば、特にパケット再送を避けたいアプリケーションのパケットフローを転送するときや、パケットロスが多くユーザネットワークから多重転送をリクエストされたときなど)に、本来の経路に加えてバックアップの経路を用いて、多重にパケット(元パケットと冗長パケット)転送をするように、切り替えることが可能である。また、常に多重転送を行う例においては、冗長パケットとして複製パケットを転送する場合は、元パケットと同一のパケットであるため、どちらをどの経路で転送するか区別する必要はないが、冗長パケットとして誤り訂正パケットを転送する場合には、元パケットを本来の経路で、誤り訂正パケットをバックアップの経路でという使い分けをすることがあり得る。
図2で説明した例では、全てのDRが、冗長パケットを作成し、ユーザネットワークに対する二つの経路(リンクA,B)を使用する機能を有する。すなわち、全てのDRが、図3のようなP(X)宛のパケットについての検索テーブルを有する。この方式の場合、ユーザネットワークは実際には複数あるため、図5(a)に示すように、全てのDRがそれぞれ全てのユーザネットワークについて、複数経路の情報(図3の検索テーブル)を持つことになり、各DRの検索テーブルの情報量や後述するDR間のメッセージ交換の量が多くなる。
これに対し、図5(b)に示すように、一つのユーザネットワークに対する複数経路を、全てのDRが有するのではなく、特定のDRが有するようにすれば、各DRの検索テーブルを小さくすることができる。すなわち、あるユーザネットワーク宛のパケットを特定のDR以外が受信した場合、そのパケットを特定のDRに向けて転送する。そして、パケットが特定のDRに到達すると、その特定のDRが、冗長パケットを作成し、宛先のユーザネットワークへの複数の経路を使用する。この方式では、各DRは、自身が担当するユーザネットワークについては、複数経路の情報(図3の検索テーブル)を持つが、それ以外のユーザネットワークについては他のDRへパケットを転送するだけで済む。
図5(b)の場合のパケット転送の例を、図6に示す。ユーザネットワークのホスト宛にパケットを送信したい送信元ホストS1,S2,S3が、そのパケットの宛先にP(X)をプレフィックスとするアドレスXを書き込んで、インターネットに送出すると、最も送信元に近いDR(S1からの場合DR1、S2からの場合DR2、S3からの場合DR3)に配送されるのは、図2の場合と同様である。
DR1は、ユーザネットワークP(X)を担当するDRであるので、S1から受信したパケットを基に、図3の検索テーブルを参照して、DR1からISP−AとリンクAを通ってURに至る経路(図6中、実線矢印)と、DR1からISP−BとリンクBを通ってURに至る経路(図6中、点線矢印)を特定し、冗長パケットを作成して、元パケットと冗長パケットを両方の経路を分散して転送する。なお、上述したように、通常の状況下では、二つの経路のうちいずれか一方を選択してパケットを転送しており、特殊な状況が生じたときに、他方の経路をバックアップとして追加して、冗長パケットの作成と分散転送をするようにしてもよい。
DR2も、ユーザネットワークP(X)を担当するDRであるので、S2から受信したパケットを基に、図3の検索テーブルを参照して、DR2からISP−AとリンクAを通ってURに至る経路(図6中、点線矢印)と、DR2からISP−BとリンクBを通ってURに至る経路(図6中、実線矢印)を特定し、冗長パケットを作成して、元パケットと冗長パケットを両方の経路を分散して転送する。
DR3は、ユーザネットワークP(X)を担当するDRではないので、S3からP(X)宛のパケットを受信すると、ルーティングテーブルを検索し、DR2のアドレスを得る。DR2は、予め、自身がP(X)宛のパケットについて複数経路の選択を行うことを、他のDRに通知しているので、DR3のルーティングテーブルは、P(X)をキーとして検索するとDR2のアドレスが出力されるように、設定されているのである。よって、S3からのP(X)宛のパケットは、DR3からDR2へ転送され、DR2で、上述したようにパケットと経路の多重化が行われる。
DR4も、ユーザネットワークP(X)を担当するDRではないので、近くの送信元ホストからP(X)宛のパケットを受信すると、ルーティングテーブルを検索し、DR2のアドレスを得る。DR4のルーティングテーブルにも、DR2がP(X)宛のパケットについて複数経路の選択を行うことを他のDRに予め通知することにより、P(X)とDR2の対応が設定されている。なお、ここでは、DR4から直接DR2へ、P(X)宛のパケットが転送される例を挙げたが、DR4からDR3へパケットが転送され、さらにDR3からDR2へパケットが転送されるようにしても良い。そのためには、DR2がP(X)とDR2の対応を他の全てのDRに通知するのではなく、近くのDR(例えばDR3)に通知し、これを受けたDR3がさらに近くのDR(例えばDR4)に、P(X)と自身(DR3)の対応を通知すれば良い。
以上には、図2や図6において、ユーザネットワークに流入するパケットを転送する方法について説明したが、同図において、ユーザネットワークからインターネットへ流出するパケットの転送は、次のようにすれば良い。例えばユーザネットワーク内のホストが、S2へ向けてパケットを送出したい場合、宛先をS2とし、送信元をXとするパケットを、URが第1のインタフェースからISP−A経由で、もしくは第2のインタフェースからISP−B経由で、インターネットへ送出すれば良い。
但し、ISPが入力フィルタを行い、自ISPが割り当てたIPアドレスを送信元とするパケット以外は自ISPを経由させないように設定している場合であって、アドレスXが経由させたいISPから割り当てられたアドレスでない場合は、URが、DRへ上流方向の(図中の矢印とは逆の)トンネルを設定して、そこにパケットを転送する。上流方向へのトンネルが設定されるのは、例えば、P(X)としてISP−AのプレフィックスAを使用している場合にISP−B経由で送出したいときや、P(X)としてPIアドレスプレフィックスを使用している場合である。上流方向へのトンネルは、図4(a)〜(c)の3通りの方法で実現でき、URが図中のDRと同様な動作によりパケットを転送し、DRが図中のURと同様な動作によりパケットを転送することになる。なお、ここでは上流方向へのトンネルの設定が必要となる場合を説明したが、不要な場合であっても、上流方向へのトンネルを設定して勿論構わない。
URの第1のインタフェースからISP−Aを経由してDR1に至るトンネルと、URの第2のインタフェースからISP−Bを経由して同じDR1に至るトンネルとが設定されている場合、URは、ユーザネットワーク内の送信元ノードから受信したパケットの冗長パケットを作成し、元パケットと冗長パケットを二つのトンネルに分散させて転送することが可能である。この場合、DR1で、重複パケットの廃棄もしくは誤り訂正パケットを用いた紛失パケットの復元を行う。
図7には、図2や図6のようなパケット転送を実現するためにURやDRが行う、メッセージ交換の様子を例示する。なお、メッセージ交換は、インターネットにおいて別の目的で規定されたプロトコルを流用して行なっても良いし、本実施形態のUR及びDR用に新たなプロトコルを規定しても良い。また、それぞれのURやDRにおいて、上述したパケット転送を行うネットワーク層処理のためのモジュールと、後述するメッセージ交換をトランスポート層以上の層で動くプロトコルを使用して行うモジュールとを、別個に設けても良い。
まず、URが、自身のP(X)とURa及びURbとの対応を登録するためのメッセージを、DRへ送信する。この登録メッセージは、anycastを用いて送信される。すなわち、URが発する登録メッセージは、URに最も近いDRに受信されそこで処理される。URは、anycastではなくユニキャストで、登録メッセージを送信しても良い。ユニキャストを用いる場合は、URに予め登録されている一つまたは複数のDRのアドレスを宛先として、送信する。
この登録メッセージの送り方には、次の二通りがあり得る。一つは、URが、リンクA(第1のインタフェース)からは、第1のインタフェースのアドレスURaとP(X)の対応を、リンクB(第2のインタフェース)からは、第2のインタフェースのアドレスURbとP(X)の対応を送信するやり方である。もう一つは、URが、いずれか一つのリンク(例えばリンクA)を選択し、選択したリンクから複数のアドレス(URaとURb)とP(X)の対応を送信するやり方である。
いずれの送り方の場合も、URaとURbを同時に登録しなくても良く、前者の場合、リンクAからの登録メッセージとリンクBからのそれとを別々のタイミングで送信できるし、後者の場合、リンクAから二つのメッセージ、すなわちP(X)とURaの対応を登録するメッセージとP(X)とURbの対応を登録するメッセージとを、別々に送信するのでも構わない。
両方のリンクを用いる送り方の場合、URを発した登録メッセージA(P(X)とURaの対応)は、ISP−A経由で最も近いDR1に吸い込まれ、登録メッセージB(P(X)とURbの対応)は、ISP−B経由で最も近いDR2に吸い込まれる。DR1とDR2は、後述するように登録情報の共有を行うので、DR1にもDR2にも、P(X)とURa及びURbの対応が登録されることになる。各DRは、この登録情報を用いて、図3のような検索テーブルを生成することができる。後述する通信環境に関する情報やURからの指示情報を用いて、図3の検索テーブルを更新することも可能である。
片方のリンク(例えばリンクA)を用いる送り方の場合、URを発した登録メッセージ(P(X)とURa及びURbの対応)は、ISP−A経由で最も近いDR1に吸い込まれる。すると、DR1には、P(X)とURa及びURbの対応が登録され、DR1とDR2は、後述するように登録情報の共有を行うので、DR2にも、同じ対応が登録されることになる。各DRが、この登録情報に基づいて、図3のような検索テーブルを生成することができるのは、上記と同様である。
各DRにおいて、上述したように一旦登録した対応情報を、維持もしくは削除する一つの方法は、URから定期的に同一内容の登録メッセージを送信することである(この方法をソフトステートと呼ぶことがある)。すると、DRは、その登録メッセージが受信されている限り、登録内容を維持し、受信されなくなったら(最後に登録メッセージを受信してから所定の期間が経過したら)、登録内容を削除する。例えば、P(X)とURbの対応を示す登録メッセージが受信されなくなったら、この対応を削除する(P(X)とURaの対応のみが登録情報として残る)。そして、図3の検索テーブルから、リンクBを通る経路に相当するトンネルの宛先を削除し、残っているリンクAに対するトンネルが選択されるように、検索テーブルを書き換える。この結果、残っているトンネルが二つ以上存在するうちは、上述した冗長パケットの作成と分散転送が可能であるが、残っているトンネルが一つになってしまった場合には、冗長パケットの作成を止め、受信したパケットを一つの経路にそのまま転送する。なお、冗長パケットが誤り訂正パケットである場合には、冗長パケットの作成を継続し、元パケットと誤り訂正パケットの両方を一つの経路に転送するようにしてもよい。
ソフトステートを採用する場合、上記の両方のリンクを用いる登録メッセージの送り方で、片方のリンク(例えばリンクB)がダウンすると、登録メッセージBはインターネットに到達しなくなる。よって、P(X)とURbの対応情報は、各DRから削除され、各DRの検索テーブルは、残っているリンクAの経路を指し示すようになり、ユーザネットワーク宛のパケットはISP−A経由で転送されるので、インターネットとの接続性が保持される。
ソフトステートで、上記の片方のリンクを用いる登録メッセージの送り方を採用する場合、片方のリンク(例えばリンクB)がダウンしたことをURが検出すると、URは、P(X)とURa及びURbの対応を登録メッセージとして送出するのを止め、P(X)とURaの対応だけを登録メッセージとして送出する。すると、P(X)とURbの対応情報は、各DRから削除され、各DRの検索テーブルは、残っているリンクAの経路を指し示すようになる。
登録情報の維持もしくは削除のための別の方法として、URから明示的に削除を依頼するメッセージを送信することとしても良い(この方法をハードステートと呼ぶことがある)。すると、DRは、その削除メッセージが受信されるまでは登録内容を維持し、受信されたら登録内容を削除する。この方法の場合、両方のリンクともダウンしたりUR自体がダウンしたりして通信不能になっている場合も、URからの削除メッセージが受信されないため、そのような場合にまで登録内容を維持することのないように、DRが定期的にURの生存確認を行う。この確認は、本実施形態のメッセージ交換とは別に動作しているプロトコルによる生存確認を、共用しても良い。
ハードステートを採用する場合、上記の両方のリンクを用いる登録メッセージの送り方で、片方のリンク(例えばリンクB)がダウンすると、DRが定期的にURbに対して送信している生存確認に応答が返ってこなくなる。これにより、P(X)とURbの対応情報をDRから削除することができ、各DRの検索テーブルが指し示す経路を残っているリンクAに変更することができる。
ハードステートで、上記の片方のリンクを用いる登録メッセージの送り方を採用する場合、片方のリンク(例えばリンクB)がダウンしたことをURが検出すると、URは、P(X)とURbの対応を削除するよう指示する削除メッセージをDRに送出する。
以上では、URからDRへ送信する登録メッセージに、ユーザネットワークのプレフィックスP(X)とURaまたはURbとの組を含ませる例を説明したが、登録メッセージには、ユーザネットワークの識別子IxとURaまたはURbとの組を含ませることとし、これを受信したDRにおいて、IxからプレフィックスP(X)を求めることにより、P(X)とURaまたはURbとの対応を登録するようにしても良い。このようにURからの登録メッセージに含ませる情報としてプレフィックスP(X)を用いないことは、次のような利点がある。
P(X)は、インターネット内の他の多数のルータに広告されるルーティング情報となるので、P(X)に誤りがあると、広範囲に誤動作を引き起こし、ネットワークが機能しなくなる可能性が高い。このようなリスクを低減するため、インターネットの外のユーザであるURから申告される情報をそのままルーティング情報として使用することは、避けることが望ましい。上記のように、DRは、自身が担当するユーザネットワークxを識別子Ixにより識別することとし、URからは、P(X)ではなくIxを申告させ、DRにおいて、IxをP(X)に変換することにより、誤ったP(X)が使用されるリスクを減らすことができる。なお、Ixとしては、例えばURのユーザネットワークにおけるアドレス(P(X)を上位所定ビットに持つURのアドレス)を用いることができる。この場合、DRは、自身が担当するユーザネットワークのP(X)のビット数を予め知っており、受信したIxからそのビット数分だけ上位ビットを抽出することにより、P(X)を得る。また、この登録メッセージ送信用のプロトコルとしては、例えばIETFで標準化されているMobile IPを応用することができ、URをモバイルノード、DRをホームエージェントと見立て、登録メッセージ中のIxをURのホームアドレス、URaまたはURbをURのケア・オブ・アドレスとして扱うことで、DRがP(X)宛てのパケットをURaまたはURbに転送するための登録処理が実現できる。
また、URから、P(X)を申告させる場合であっても、その登録メッセージを受信したDRにおいて、自身が担当するユーザネットワークの正しいプレフィックスP(X)を予め記憶しておき、登録メッセージに含まれるP(X)と自身が記憶しているP(X)とが一致しているかどうかを検査することが望ましい。検査の結果、一致していれば、P(X)とURaまたはURbとの対応の登録処理を開始するが、不一致であれば、登録メッセージの送信元のURへ、エラーメッセージを返す。
以上のように、URの発した登録メッセージにより、少なくとも一つのDRに、P(X)とURのアドレスの対応が登録されるため、次には、DR間でこの登録情報を伝達する。図7に示した例では、BGPのルート・リフレクタのような役割をする登録情報サーバを導入し、登録情報サーバが、登録情報を交換するためのDR間のコネクションを集中管理している。これにより、登録情報を全てのDRにフルメッシュ伝達する場合でも、各DRにかかる負荷を低減し、ネットワークの管理を容易にすることができる。別の例として、OSPF(Open Shortest Path First)というルーティングプロトコルのように、登録情報をDR間で伝播させることもできる。
ここで、図5を用いて説明したように、全てのDRがURに対する経路選択を行う(a)の場合は、上記のDR間で伝達される情報は全て、P(X)とURの複数のアドレスの対応となる。一方、特定のDRがURに対する経路選択を行う(b)の場合、上記のDR間で伝達される情報は、特定のDRに対しては、P(X)とURの複数のアドレスの対応となり、その他のDRに対しては、P(X)と特定のDRのアドレスの対応となる。
以上に説明したメッセージ交換により、各DRが図3のような検索テーブルを作成する基礎となる登録情報(P(X)とURa及びURbとの対応)が、各DRに記憶される。以下には、DRに対して、複数の転送経路のうちいずれを本来の経路として選択するかを決定する方法について述べる。なお、ここで決定された選択すべき経路が、ベストマッチの経路として検索テーブルに書き込まれるので、パケット転送の際にこの検索テーブルを参照することにより、経路の選択が行われる。この検索テーブルが書き換えられると、選択経路が変更されることになる。また、誤り訂正パケットと元パケットを複数の経路に分散させて転送する場合は、どのパケットをどの経路で転送するかを選択することになるが、この場合には、検索テーブルに各トンネルの通信品質等を記入する欄を追加しておくとよい。そして、検索テーブルを参照してベストマッチの経路とセカンドベストマッチの経路を特定し、特定した各経路の通信品質等を検索テーブルから読み出し、例えば帯域の大きいトンネルの方へパケットを多く振り分けるように、各パケットについて二つの経路からの選択を行う。この場合にも、検索テーブルの通信品質等を記入する欄が書き換えられると、一部のパケットについては二つの経路のうちいずれを選択するかが変更されることになる。
選択すべき経路を決定するため、図8に示すような、各リンクのトラフィックや、各経路の通信品質(例えば、遅延、ジッター、帯域、パケットロス等)等を検出すると、効果的な負荷分散や最適な経路選択ができる。各リンクのトラフィックは、URの第1及び第2のインタフェースで観測することができ、全てのDRからの全てのパケットフローのトラフィックの合計だけを観測するのでも良いし、特定のパケットフロー毎にトラフィックを観測しても良いし、IPパケットカプセル化やMPLSによるトンネルの場合にはURが知ることのできるトンネルの入口のDR毎にトラフィックを観測しても良い。URが、DR毎にトラフィックを観測する場合には、トラフィックが多いDRに対して選択的に、経路変更の通知を行うこともできる。
トラフィックの合計だけを観測するのでも、例えばリンクAのトラフィックがリンクBよりも多ければ、適当に(例えばランダムに)決定したパケットフロー(例えば特定の宛先アドレスと送信元アドレスの組等)について、経路(トンネルの出口)をリンクAからリンクBに変更するように、指示することができる。この指示は、例えば、トラフィックを観測したURで、経路を変更するパケットフローの特定まで行なって、この特定されたパケットフローを規定する情報を含む指示メッセージをURからDRへ送出することで、実現できる。他の例として、観測されたトラフィックの値を含む通信環境通知メッセージをURがDRへ送出し、このメッセージの情報を基に、DRが経路を変更するパケットフローの特定を行なうこともできる。
さらに、URにて、特定のパケットフロー毎にトラフィックを観測すれば、例えばリンクAのトラフィックがリンクBよりも多いときに、どのパケットフローについて経路変更をすれば、リンクAとリンクBのトラフィックが最適に分散するかまで決定することができる。この場合、経路変更するパケットフローの特定をDR側で行う通信環境通知メッセージ方式でも良いが、パケットフロー毎の観測結果であるのでメッセージの情報量が多くなる。したがって、経路変更するパケットフローの特定をUR側で行なう指示メッセージ方式がより適している可能性がある。
URが発する上記の指示メッセージや通信環境通知メッセージは、図7で登録メッセージについて説明したのと同様に、anycastを利用して最も近いDRに配送し、DR間でこれを伝達させることもできるし、URが個々のDRのアドレスを知ることができるトンネル方式の場合には、URが上記のメッセージを特定のDR宛に送信し、DR間での伝達はしないとすることもできる。
anycastを利用して指示メッセージを送る場合、全てのDRもしくはそのURを担当するDRの全てが、同じように選択すべき経路を変更しても良いし、指示メッセージ中に変更すべきDRのアドレスリストを含めることで、特定のDRのみの経路を変更することも可能である。anycastを利用して通信環境通知メッセージを送る場合は、このメッセージに含まれる観測結果に基づいて、各DRが個別の判断を行うので、各DRで異なる変更内容になる可能性がある。
特定のDRに指示メッセージを送りDR間での伝達はしないならば、全てのDRがURに対する経路選択をする構成(図5(a))の場合は、同じパケットフローであっても、経由するDRによって選択される経路が異なることが生じ、それによる負荷分散も可能になる。特定のDRがURに対する経路選択をする構成(図5(b))の場合は、特定のDR以外のDRへは選択経路変更のためのメッセージを送る必要がないが、URがトンネルの入口のアドレスを検出することにより特定のDR(経路選択をするDR)に指示メッセージや通信環境通知メッセージを送ることとすれば、DR間の伝達をなくすだけで必要のないメッセージ交換を省略することができる。
URにおけるトラフィック観測で、トラフィックがどのDRから送られてきているかを区別すれば、どのDRに上記の指示メッセージや通信環境通知メッセージを送信すれば良いかを、特定することができる。さらに、同じパケットフローが複数のDR経由で送られてきている場合、一部のDRのみに上記の指示メッセージや通信環境通知メッセージを送信することにより、一部のDRのみに経路変更を要求することでも、リンクAとリンクBのトラフィックを適切に分散することができる。
図8に示す各経路の通信品質の例としては、ここでは遅延を取り上げて説明するが、ジッター、帯域、パケットロス等についても、同様に本実施形態を適用することができる。一つの方法は、URが個々のDRのアドレスを知ることができるトンネル方式の場合に、URが、特定のDRからのパケットが有する遅延を観測し、これを上記のトラフィックについての指示メッセージもしくは通信環境通知メッセージと同様に、その特定のDRへフィードバックするものである。
別の方法は、どのトンネル方式でも適用可能なもので、DRが、図2や図6で説明したパケット転送を行うのとは別に、URへの複数の経路に対し、遅延を測定するためのメッセージを流し、これに応答してURから返送されてくるメッセージに含まれる遅延の情報を得るものである。
DRは、URから指示メッセージを受信すれば、そのメッセージにて特定されるパケットフローの経路を指定された通り変更し、URから遅延情報を含むメッセージを受信すれば、DR自身で経路を変更するパケットフローを特定する。
さらに別の方法として、ユーザネットワークの管理者(オペレータ)が、URにおいて、経路の選択ポリシー、例えば音声通話(VoIP:Voice over IP)のパケットは遅延最小のトンネルで送る等を設定し、これを指示メッセージとしてDRに送信する方法もあり得る。これは、例えば、DRもしくは図7の登録情報サーバがWebサーバとしての機能を有し、URがWebクライアントとしての機能を備えていれば、Webページにオペレータがポリシーを入力することによっても、実現できる。DRがWebサーバとして機能する場合には、そのDRがURからの指示メッセージを受け、その内容を他のDRへ転送する。図7の登録情報サーバがWebサーバとして機能する場合には、図7の登録情報サーバが、URからの指示メッセージの内容を他のDRへ配送する。
そして、DRでは、この指示されたポリシーと、上述したように計測した各経路の遅延の情報とに基づいて、ユーザの要望に沿った経路を選択することができる。具体的には、例えば、図3の検索テーブルに、音声通話のパケットフローを示す検索キーに対応して、遅延最小のトンネルの宛先を記憶させる。
図9及び図10は、それぞれ本実施形態に係るDR装置100及びUR装置200の内部構成例を示す機能ブロック図である。ここでは、上述した経路の選択のいずれの方法も扱える例を説明する(図9のブロック114〜120、図10のブロック214〜220)が、実際には、ここで特定されたブロックのうちの一部を必要に応じて選択して実装しても良いし、ここで特定されたブロックは全く備えなくても、DRやURとしての基本的な機能は果たされる。なお、図中の二重線矢印は、パケットの流れを示し、その他の矢印は、制御情報の流れを示す。
DR装置100においては、パケット受信部102が、送信元ホストを発したパケット、もしくは図5(b)の場合は他のDRから転送されてきたパケットを受信し、経路選択部104が、受信したパケット内の情報をキーにして検索テーブル記憶部124を参照し、この検索結果に基づいて宛先ユーザネットワークへの複数の経路のうち二つ以上を選択した場合は、冗長パケット作成部140が、冗長パケット(複製パケットもしくは誤り訂正パケット)を作成し、パケット送信部106が、図4(a)〜(c)のいずれかの方法で、選択された経路(トンネルの出口となるURのインタフェース)へパケットを転送する。図4(c)の方法の場合は、アドレス変換部128を用いる。なお、図5(b)の場合、検索テーブル記憶部124が、転送先として他のDRを示すことがあり、その場合、パケット送信部106は、そのDRへパケットを転送する。冗長パケット作成部140が、複製パケットを作成する場合には、元パケットと複製パケットに同一のパケット識別子を付与することとすれば、URにおいて受信した各パケットのパケット識別子を調べることにより、パケットを重複して受信したことを検出できる。
UR装置200においては、リンクAからパケットが転送されてくればISP−A用パケット受信部202がこれを受信し、リンクBからパケットが転送されてくればISP−B用パケット受信部204がこれを受信し、図4(a)〜(c)のいずれかのUR側の処理を行う。図4(c)の場合は、アドレス変換部206が、登録情報記憶部210に記憶されているP(X)とA及びBの対応を参照して、アドレス変換する。そして、受信したパケットから生成された元のパケットに基づいて、冗長パケット削除部230が、冗長パケットを削除する処理を行ない、その後パケット送信部208が宛先ホストへ転送する。冗長パケットの削除は、冗長パケットが複製パケットである場合は、各パケットに付与されたパケット識別子を参照して、重複パケットを廃棄することにより行う。冗長パケットが誤り訂正パケットである場合は、冗長パケット削除部230は、各パケットのシーケンス番号を調べて、受信されるべき元パケットが受信されていないことを確認すると、受信されなかった元パケットの数だけ誤り訂正パケットを用いて、誤り訂正を行い、受信された元パケットと復元された元パケットを、パケット送信部208に渡す。このとき、不要となった誤り訂正パケットは廃棄する。
UR200の登録情報送信部212は、登録情報記憶部210に記憶されているP(X)とURa及びURbの対応を、図7で説明したように登録メッセージとしてDR100へ送信し、UR登録受信部108がこれを受信する。登録情報送信部212は、通信環境観測部214にていずれかのリンクがダウンしていることを検出すると、上述したように送信する登録メッセージの内容を変更する(削除メッセージを送信する例を含む)。DR100が受信した登録メッセージの内容は登録情報記憶部112に記憶され、上記のように変更があると、登録情報更新部110がその記憶内容を書き換える。
登録メッセージとして、P(X)とURa及びURbの対応ではなく、ネットワーク識別子IxとURa及びURbの対応を送る構成を採用する場合は、UR200の登録情報送信部212は、登録情報記憶部210に記憶されているP(X)ではなく、Ixを用いて登録メッセージを作成する。そして、DR100の登録情報更新部110は、受信した登録メッセージのIxに基づいてプレフィックス記憶部130を参照することにより、P(X)を得て、登録情報記憶部112にP(X)とURa及びURbの対応を記憶する。なお、登録メッセージとして、P(X)とURa及びURbの対応が送信される場合、DR100の登録情報更新部110が、受信した登録メッセージのP(X)に基づいてプレフィックス記憶部130を参照し、受信したP(X)が正しければ登録情報を記憶し、誤っていれば登録せずにURへエラーメッセージを返すようにすることができる。
UR200の通信環境観測部214は、パケット受信部202及び204を監視して、トラフィック量や通信品質等の情報を得る。そして、この観測された情報を観測情報送信部216が通信環境通知メッセージとしてDRへ送信し、UR観測受信部114がこれを受信する。あるいは、通信環境観測部214で観測された情報を基に、指示情報生成部218がどのパケットフローの経路をどこに変更すべきかを判断し、この判断結果を含む情報を指示情報送信部220が指示メッセージとしてDRへ送信し、UR指示受信部118がこれを受信する。
指示情報生成部218は、オペレータの入力するポリシーと観測された通信環境とに基づいて、経路を変更すべきパケットフローを決定し、この具体的な決定結果を指示情報としても良いし、通信環境に基づく判断は行わずにオペレータの入力するポリシー自体を指示情報としても良い。前者の場合は、UR指示受信部118で受信した指示メッセージの内容に従って、検索テーブル更新部122が検索テーブル記憶部124の内容を書き換える。後者の場合は、UR指示受信部118で受信した指示メッセージの内容はポリシー記憶部120に記憶され、このポリシーと通信環境検出部116の出力とに基づいて、検索テーブル更新部112が、経路を変更すべきパケットフローを決定する。UR指示受信部118は、DRが上述したWebサーバとして機能する場合は、Webサーバの機能を持つ。
UR指示受信部118が指示メッセージを受信しない場合も、UR観測受信部114から出力される通信環境の情報を通信環境検出部116が検出し、検索テーブル更新部112が通信環境検出部116の出力に基づいて、経路を変更すべきパケットフローを決定して検索テーブルを書き換えることができる。あるいは、検索テーブルに各経路の通信環境をも記憶しておく例においては、検索テーブル更新部112は、通信環境検出部116の出力に従って、検索テーブル記憶部124の通信環境を記入する欄を書き換え、経路選択部104が、検索テーブルの各経路の情報として通信環境の情報をも参照して、経路を決定する。通信環境検出部116は、URで観測された通信環境の情報だけでなく、DRがURとメッセージ交換することにより獲得した通信環境の情報を用いることができる。
このように書き換えられた検索テーブル記憶部124を参照することで、経路選択部104で選択される経路(トンネルの出口となるURのインタフェース)が変更され、トラフィックの分散や最適経路の選択が可能となる。また、DR装置100は、DR制御情報送受信部126を備え、他のDRとの間で、上述した指示メッセージの内容や、通信環境の情報、登録情報等の制御情報を交換することができる。すなわち、DR制御情報送受信部126は、検索テーブル更新部122に接続されており、DR装置100がURから受信部108、114、118を介して受信した情報を、他のDRへ、必要であれば加工した上で転送する。また、DR制御情報送受信部126は、他のDRもしくは図7の登録情報サーバから上記の制御情報を受信し、検索テーブル更新部122は、受信した他のDR等からの制御情報に基づいて、検索テーブル記憶部124の内容を書き換えることもできる。
図11には、DRが、URへの複数の経路のそれぞれが正常に動作しているか否かを確認し、P(X)宛のパケットを転送する経路として、正常に動作している経路を選択するための機構を示す。図中のDRは、図9に示したDR100と同様の機能を有し、登録情報記憶部112には、ユーザネットワークP(X)に対して、ISP−AによるリンクAを利用する経路Aと、ISP−BによるリンクBを利用する経路Bとが登録されているものとする。この登録情報は、DRの検索テーブルに反映され、経路選択部104は、この検索テーブルを参照してユーザネットワークへの経路を選択する。本例におけるDRは、これらの他に、確認パケット送信部132、返答パケット受信部134、間隔制御部136を備える。
確認パケット送信部132は、登録情報記憶部112を参照し、経路A(URaを出口とする仮想的なトンネル)と経路B(URbを出口とする仮想的なトンネル)のそれぞれに対し、定期的に、キープアライブパケットと呼ばれるパケット(実トラフィックとは別の試験トラフィック)を送信する。返答パケット受信部134は、送信されたそれぞれのキープアライブパケットに対して返信されるパケットを検査して、DR1からURaへのトンネルとDR1からURbへのトンネルのそれぞれが、有効に機能しているかを確認する。そして、有効に機能していないことが判明した経路は、本来の経路として選択しないように、経路選択部104に指示する。経路選択部104は、例えば経路Aを使用しないように指示されれば、検索テーブルを参照して経路A以外の経路(例えば経路B)を選択し、P(X)宛のパケットを転送する。
間隔制御部136は、確認パケット送信部132が各経路にキープアライブパケットを送信する間隔を、各経路の通信品質(例えば帯域)に応じて変更することができる。送信間隔が短ければ、各経路の状況をよりリアルタイムに把握することが可能になる反面、帯域が狭い場合にキープアライブのような試験パケットを頻繁に送信するのは、実トラフィックのパケットを送信できる帯域をますます狭めてしまう結果となるため、帯域が狭くなるほどキープアライブの送信間隔を長くするように、制御する。例えば、経路Aの帯域が、経路Bの帯域より大きければ、経路Aへキープアライブを送信する間隔は、経路Bへキープアライブを送信する間隔よりも短くなる。
上記の各経路の通信品質は、pathcharとして知られている仕組みを応用すると、上記のキープアライブパケットに対する返信内容から推定することができる。この仕組みによれば、DR1がトンネルの出口を指定してtracerouteを実行した場合と同様に、キープアライブパケットに対する返答として、DR1からトンネルの出口(URaまたはURb)への経路上のルータのアドレスが、DR1に近い方から順番に得られ、さらに経路上の各ルータまでの所要時間も測定することができる。この測定を、送信するキープアライブパケットのサイズを変えて、何度も繰り返す。そして、サイズの異なる測定パケットのそれぞれに対するRTT(Round Trip Time)を計測し、回帰曲線を求めることにより、トンネルの帯域が推測できる。回帰曲線の傾きから、帯域が推定でき、回帰曲線が示すパケットサイズが0のときのRTTから、伝播遅延が推定できる。
上記では、DRからURへの(下流方向の)トンネルに対する動作確認を行ない、DRが正常に動作している経路を選択してユーザネットワークへのパケットを転送する例を説明したが、上記の機構は、ユーザネットワークからインターネットへ流入させるパケットのために、URからDRへの(上流方向の)トンネルを利用する場合にも、適用可能である。すなわち、URは、URaのインタフェースからDRへの経路(図11では経路Aの横に点線で示す)と、URbのインタフェースからDRへの経路(図11では経路Bの横に点線で示す)のそれぞれに対し、キープアライブパケットを送信し、その返答を調べ、正常に動作しているトンネルを、本来の経路として選択して、ユーザネットワークから出て行くパケットを転送する。キープアライブの送信間隔を、経路の通信品質に応じて変更可能なことも、同様である。
図12には、リンクAに対応する境界ルータとしてUR−Aが、リンクBに対応する境界ルータとしてUR−Bが設けられている場合に、冗長パケットを削除するための三通りの方式を示す。例えばDR1を出発点として、リンクAを介して元のパケットフローが、リンクBを介して複製されたパケットフローが、転送されてくるものとする。
図12(a)の方式では、例えば、UR−Aが、自身が受信したパケットのパケット識別子の情報をUR−Bに伝え、UR−Bは、同一のパケットがUR−Aでも受信されていれば自身が受信したパケットを廃棄し、同一のパケットがUR−Aでは受信されていなければ自身が受信したパケットをUR−Aに渡す。UR−Aは、UR−Bから渡されたパケットと自身が受信したパケットとを、宛先ノード(ホスト)へ転送する。この変形として、UR−Bが、UR−Aでは受信されていないパケットを受信している場合には、これをUR−A経由でなく直接ホストへ転送する方法もあり得る。
また、リンクAを介して元のパケットフローが、リンクBを介して誤り訂正のパケットフローが、転送されてくる場合は、例えば、UR−Aが、自身が受信したパケットフローに含まれるシーケンス番号から受信されていないパケットがあると判断した場合は、UR−Bが受信した誤り訂正パケットをUR−Aへ転送させ、UR−Aで紛失したパケットを復元する。そして、受信された元のパケットと復元されたパケットが、UR−Aからホストへ転送される。一方、リンクAを介して元のパケットフローと誤り訂正のパケットフローを合わせたパケットフローの任意の一部が、リンクBを介してその残りの部分が、転送されてくる場合には、例えば、UR―Bが、自身が受信したパケットのシーケンス番号の情報をUR−Aに伝え、UR−Aは、自身が受信したパケットのシーケンス番号と通知されたシーケンス番号を合わせても受信されていないと判断されるパケットが存在する場合には、自身が受信した誤り訂正パケットを用いて、それで足りなければUR−Bが受信した誤り訂正パケット又は元パケットの転送を受けて、紛失したパケットを復元する。そして、UR−Aは、受信した元のパケットと復元したパケットとをホストへ転送する。元のパケットの一部は、それを受信したUR−Bからホストへ転送されても構わない。
図12(b)の方式では、UR−AとUR−Bは共に、自身が受信したパケットフローに対し、トンネルの出口に相当する処理を行うだけで、そのパケットフローをユーザネットワーク内の特定のルータRへ転送し、特定のルータRが、図10の冗長パケット削除部230と同様な処理を行う。このとき、同じパケットフローに属するパケットは全て、UR−Aに受信されたかUR−Bに受信されたかを問わず、同じ特定のルータへ転送されるように、UR−AとUR−Bのルーティングテーブルを設定しておく。図12(c)の方式では、UR−AとUR−Bは共に、自身が受信したパケットフローに対し、トンネルの出口に相当する処理を行うだけで、そのパケットフローを普通にユーザネットワーク内の宛先ノードへ転送し、宛先ノードが、図10の冗長パケット削除部230と同様な処理を行う。
なお、図1の従来方式では、企業ネットワーク等では通常は扱っていないBGP(インターネット用のプロトコル)をネットワーク管理者が運用して、インターネットへのアドレス広告をする必要があるが、本実施形態によれば、そのようなBGPを導入しなくても、企業ネットワーク等に上述した登録メッセージ送信等の機能を有するURを設置すれば、マルチホーム接続を実現することができる。
以上、本発明の実施形態について説明したが、上述の実施形態を本発明の範囲内で当業者が種々に変形、応用して実施できることは勿論である。例えば、上記では、一つのユーザネットワークが二つのISPのそれぞれからリンクを提供されている場合を説明したが、一つのユーザネットワークが三つ以上のISPのそれぞれからリンクを提供されている場合にも、同様のマルチホーム接続やトラフィック分散等が可能である。また、上記では、一つのISPが一つのリンクをユーザネットワークに提供する(二つのリンクは二つのISPにより提供される)場合を説明したが、二つ以上のリンクを一つのISPがユーザネットワークに提供する(例えば図2のISP−AとISP−Bのネットワークが一つのISPにより運営され、その一つのISPネットワークから二つのリンクA,BがURに提供される)場合にも、同様のマルチホーム接続を生かしたパケット転送の多重化やトラフィック分散等が可能である。
以上説明したように、本発明に係るルータとユーザルータを使用すれば、例えば、データをリアルタイムで確実に宛先に届けたいが、宛先のユーザネットワークとインターネットとの間の接続が不安定であるような場合に応用して、接続を二重化(多重化)するとともに転送されるパケットも二重化(多重化)することにより、途中の経路でパケットロスがあっても、別の接続を利用する経路から届くパケットで紛失したパケットを代替もしくは復元することが可能となり、インターネットとユーザネットワーク間のパケット転送の高信頼化に有用である。
従来のマルチホーム接続の方式を説明するための図。 本発明の一実施形態におけるパケット転送の例を説明するための図。 本実施形態におけるパケット転送に用いられる検索テーブルの例を示す図。 本実施形態においてパケットが転送される経路が(a)IPパケットのカプセル化により構成される場合と、(b)ラベルスイッチングパスにより構成される場合と、(c)IPパケットの宛先アドレス変換により構成される場合とを説明するための図。 インターネットに複数存在する本実施形態に係るルータ装置DRのうち(a)全てのDRがユーザネットワークへの転送を行う場合と、(b)一部のDRがユーザネットワークへの転送を担当する場合とを説明するための図。 本実施形態におけるパケット転送の別の例を説明するための図。 本実施形態に係るルータ装置DRに制御に必要な情報を登録するためのメッセージが交換される様子を例示する図。 本実施形態において検出される通信環境の例を説明するための図。 本実施形態に係るルータ装置DRの内部構成例を示す図。 本実施形態に係るユーザルータ装置URの内部構成例を示す図。 本実施形態においてパケットが転送される経路(仮想的なトンネル)が、正常に動作しているか否かを確認する機能を持つルータ装置の構成例と、その機能を説明するための図。 本実施形態においてユーザネットワークにて受信されたパケット群から冗長性を除くための3通りの方式を例示する図。
符号の説明
100 本実施形態に係るルータ装置DR
102 パケット受信部
104 経路選択部
106 パケット送信部
108 UR登録受信部
110 登録情報更新部
112 登録情報記憶部
114 UR観測受信部
116 通信環境検出部
118 UR指示受信部
120 ポリシー記憶部
122 検索テーブル更新部
124 検索テーブル記憶部
126 DR制御情報送受信部
130 プレフィックス記憶部
132 確認パケット送信部
134 返答パケット受信部
136 送信間隔制御部
140 冗長パケット作成部
200 本実施形態に係るユーザルータ装置UR
202 ISP−Aからのパケット受信部
204 ISP−Bからのパケット受信部
128、206 アドレス変換部(オプショナル)
208 パケット送信部
210 登録情報記憶部
212 登録情報送信部
214 通信環境観測部
216 観測情報送信部
218 指示情報生成部
220 指示情報送信部
230 冗長パケット削除部

Claims (30)

  1. インターネットを構成するルータにおいて、パケットの転送を制御する方法であって、
    インターネットとの接続を複数提供されるユーザネットワークを宛先とするパケットを受信し、
    受信した前記パケットの冗長パケットを作成し、
    前記ユーザネットワークのアドレスを含む前記パケットに基づいて、前記ユーザネットワークに提供される複数の接続のうちの少なくとも二つを特定し、
    受信した前記パケット及び作成した前記冗長パケットのうちの一部を、前記特定した接続のうちの一つに対応するアドレスに従ってパケットが前記ルータから前記ユーザネットワークへ転送される経路へ、転送し、
    受信した前記パケット及び作成した前記冗長パケットのうちの他の一部を、前記特定した接続のうちの他の一つに対応するアドレスに従ってパケットが前記ルータから前記ユーザネットワークへ転送される経路へ、転送することを特徴とするパケット転送制御方法。
  2. 受信した前記パケットの宛先アドレスフィールドには前記ユーザネットワークのアドレスが、前記パケットの送信元フィールドには送信元のネットワークのアドレスが、それぞれ書き込まれており、
    前記接続に対応するアドレスに従ったパケットの転送は、前記接続を提供するプロバイダが前記接続に対応して割り当てたアドレスを宛先として、前記ルータのアドレスを送信元として、それぞれ用いて前記パケットをカプセル化することにより、行われるものであることを特徴とする請求項1記載のパケット転送制御方法。
  3. 前記ルータを出発点とし前記複数の接続のうちの一つを利用することにより前記ユーザネットワークへ至る経路に沿って、ネットワーク層より下位層の情報であるラベルに基づいてパケットが転送されるラベルスイッチングパスが設定されており、
    前記接続に対応するアドレスに従ったパケットの転送は、前記接続に対応するラベルスイッチングパスのラベルを前記パケットに付与することにより、行われるものであることを特徴とする請求項1記載のパケット転送制御方法。
  4. 受信した前記パケットの宛先アドレスフィールドには前記ユーザネットワークのアドレスが、前記パケットの送信元フィールドには送信元のネットワークのアドレスが、それぞれ書き込まれており、
    前記接続に対応するアドレスに従ったパケットの転送は、前記接続を提供するプロバイダが前記接続に対応して割り当てたアドレスに基づいて、前記宛先アドレスフィールドを書き換えることにより、行うことを特徴とする請求項1記載のパケット転送制御方法。
  5. 前記冗長パケットの作成は、受信した前記パケットを複製し、重複パケットを作成することにより、行い、
    受信した前記パケット及び作成した前記冗長パケットの転送は、受信した前記パケットと作成した前記重複パケットとが異なる経路で転送されるように、行うことを特徴とする請求項1記載のパケット転送制御方法。
  6. 前記ユーザネットワークにおいて複数の接続から重複するパケットを受信した場合に一方を廃棄できるように、受信した前記パケット及び作成した前記重複パケットに同一のパケット識別子を付与することを特徴とする請求項5記載のパケット転送制御方法。
  7. 前記冗長パケットの作成は、受信した前記パケットに含まれるデータを誤り訂正符号化し、誤り訂正パケットを作成することにより、行うことを特徴とする請求項1記載のパケット転送制御方法。
  8. 前記特定は、前記少なくとも二つの接続のうち、一つを本来の経路として、他の少なくとも一つをバックアップの経路として、特定するものであり、
    受信した前記パケット及び作成した前記冗長パケットの転送は、受信した前記パケットが前記本来の経路で転送され、作成した前記誤り訂正パケットが前記バックアップの経路で転送されるように、行うことを特徴とする請求項7記載のパケット転送制御方法。
  9. 前記各接続を利用して前記ユーザネットワークに提供される通信環境に基づいて、受信した前記パケット及び作成した前記冗長パケットのうちのどの一部を、前記特定した接続のうちのどの一つに対応するアドレスに従ってパケットが前記ルータから前記ユーザネットワークへ転送される経路へ、転送すべきかを選択することを特徴とする請求項1記載のパケット転送制御方法。
  10. 前記ルータを出発点とし前記複数の接続のうちのある一つを利用することにより前記ユーザネットワークへ至る経路におけるパケット転送の通信品質と、前記ルータを出発点とし前記複数の接続のうちの他の一つを利用することにより前記ユーザネットワークへ至る経路におけるパケット転送の通信品質とを計測し、
    前記選択は、計測した各通信品質を、前記各接続を利用して前記ユーザネットワークに提供される通信環境として用いることにより、行うことを特徴とする請求項9記載のパケット転送制御方法。
  11. 前記ユーザネットワークが観測した、前記複数の接続のうちのある一つによるインターネットと前記ユーザネットワークとの間のパケットトラフィック及び前記複数の接続のうちの他の一つによるインターネットと前記ユーザネットワークとの間のパケットトラフィックに関する情報を、受信し、
    前記選択は、受信した各トラフィックに関する情報を、前記各接続を利用して前記ユーザネットワークに提供される通信環境として用いることにより、行うことを特徴とする請求項9記載のパケット転送制御方法。
  12. 前記ユーザネットワークに提供される各接続について、その接続を利用して前記ルータから前記ユーザネットワークへの転送が行われる経路が、正常に動作しているか否かを確認し、
    前記特定は、前記特定した接続のうちの少なくとも一つが、正常に動作していることを確認した経路であるように、行うことを特徴とする請求項1記載のパケット転送制御方法。
  13. 前記確認は、前記ルータから前記各接続へ向けて所定間隔毎に確認メッセージを送信することにより、行い、
    前記確認メッセージを送信する間隔を、前記各接続を利用して転送が行われる経路の通信品質に基づいて、変更することを特徴とする請求項12記載のパケット転送制御方法。
  14. 前記ユーザネットワークのアドレスと各接続を提供するプロバイダが前記各接続に対応して割り当てたアドレスとの対応を表わす情報を記憶し、
    前記特定は、記憶した前記情報に基づいて、行うものであり、
    記憶した前記情報、もしくは、前記ユーザネットワークのアドレスと前記ルータのアドレスとの対応を表わす情報を、他のルータへ送信することを特徴とする請求項1記載のパケット転送制御方法。
  15. 前記ユーザネットワークから、前記ユーザネットワークの識別情報と各接続を提供するプロバイダが前記各接続に対応して割り当てたアドレスに関する情報とを受信し、
    受信した前記識別情報から前記ユーザネットワークのアドレスを求め、
    前記ユーザネットワークのアドレスと各接続を提供するプロバイダが前記各接続に対応して割り当てたアドレスとの対応を表わす情報を記憶し、
    前記特定は、記憶した前記情報に基づいて、行うことを特徴とする請求項1記載のパケット転送制御方法。
  16. インターネットとの接続を複数提供されるユーザネットワークの、インターネットとの接続点に設けられたユーザルータにおいて、パケットの転送を制御する方法であって、
    インターネット内に設けられたルータであって前記ユーザネットワークに提供される複数の接続のうち少なくとも二つの接続を利用して冗長性を有するパケット群を転送する機能を備えるルータに対し、前記ユーザネットワークの識別情報と前記複数の接続のそれぞれに対応して割り当てられたアドレスのうち前記ユーザルータに割り当てられたアドレスに関する情報とを送信し、
    前記複数の接続のうち前記ユーザルータに提供される接続に対応するアドレスに従った経路で転送された前記ユーザネットワーク宛のパケットを受信することを特徴とするパケット転送制御方法。
  17. 送信される前記ユーザネットワークの識別情報は、前記ユーザネットワークのアドレス情報、もしくは、前記機能を備えるルータにより前記ユーザネットワークのアドレスに変換可能な情報であることを特徴とする請求項16記載のパケット転送制御方法。
  18. 前記複数の接続のうち前記ユーザルータに提供される接続を介して前記ユーザネットワークに提供される通信環境を観測し、観測により得られた情報を、前記機能を備えるルータへ送信することを特徴とする請求項16記載のパケット転送制御方法。
  19. 前記少なくとも二つの接続から前記ユーザネットワーク宛のパケットが重複して受信された場合、複数の同一パケットのうちいずれか一つのパケットを残して他のパケットを廃棄することを特徴とする請求項16記載のパケット転送制御方法。
  20. 前記少なくとも二つの接続から前記ユーザネットワーク宛のパケット及び誤り訂正パケットが受信され、受信されるべき前記ユーザネットワーク宛の別のパケットの紛失が検出された場合、前記誤り訂正パケットを用いて紛失したパケットを復元することを特徴とする請求項16記載のパケット転送制御方法。
  21. 受信した前記パケットの宛先アドレスフィールドには前記選択された接続に対応するアドレスが書き込まれており、
    前記宛先アドレスフィールドを、前記ユーザネットワークのアドレスに基づいて書き換えて、受信した前記パケットを前記ユーザネットワーク内のノードへ転送することを特徴とする請求項16記載のパケット転送制御方法。
  22. 前記送信は、前記ユーザネットワークの識別情報及び各接続に対応して割り当てられたアドレスに関する情報を、前記複数の接続のうちの一つを利用して送信するものであり、
    前記複数の接続のうちの他の少なくとも一つが切断された場合には、該他の少なくとも一つの接続に対応して割り当てられたアドレスに関する情報の送信を停止することを特徴とする請求項16記載のパケット転送制御方法。
  23. 前記ユーザネットワークの識別情報及び前記ユーザルータに割り当てられたアドレスに関する情報の送信は、前記複数の接続のうち前記ユーザルータに割り当てられたアドレスが対応する接続を利用して行うことを特徴とする請求項16記載のパケット転送制御方法。
  24. インターネットを構成するルータとして機能するコンピュータにおいて実行される、パケットの転送を制御するためのプログラムであって、
    前記ルータが、インターネットとの接続を複数提供されるユーザネットワークのアドレスを宛先に含むパケットを受信すると、前記パケットに基づいて、前記ユーザネットワークに提供される複数の接続のうちの少なくとも二つを特定し、
    前記パケットの冗長パケットを作成し、
    前記ルータに、前記特定した接続のうちの一つに対応するアドレスに従ってパケットが前記ユーザネットワークへ転送される経路へ、受信した前記パケット及び作成した前記冗長パケットのうちの一部を転送させるとともに、記特定した接続のうちの他の一つに対応するアドレスに従ってパケットが前記ユーザネットワークへ転送される経路へ、受信した前記パケット及び作成した前記冗長パケットのうちの他の一部を転送させることを特徴とするパケット転送制御プログラム。
  25. インターネットとの接続を複数提供されるユーザネットワークの、インターネットとの接続点に設けられたユーザルータとして機能するコンピュータにおいて実行される、パケットの転送を制御するためのプログラムであって、
    前記ユーザルータに、インターネット内に設けられたルータであって前記ユーザネットワークに提供される複数の接続のうち少なくとも二つの接続を利用して冗長性を有するパケット群を転送する機能を備えるルータに対し、前記ユーザネットワークの識別情報と前記複数の接続のそれぞれに対応して割り当てられたアドレスのうち前記ユーザルータに割り当てられたアドレスに関する情報とを送信させ、
    前記ユーザルータに、前記複数の接続のうち前記ユーザルータに提供される接続に対応するアドレスに従った経路で転送された前記ユーザネットワーク宛のパケットを受信させることを特徴とするパケット転送制御プログラム。
  26. インターネットとの接続が複数提供されるユーザネットワークを宛先とするパケットを受信する受信手段と、
    前記ユーザネットワークのアドレスに対応して、前記複数の接続のそれぞれに対応するアドレスを記憶する記憶手段と、
    前記受信手段により受信されたパケットの冗長パケットを作成する作成手段と、
    前記受信手段により受信されたパケットに基づいて、前記記憶手段に記憶された複数のアドレスのうちいずれのアドレスに従った経路で前記パケット及び前記冗長パケットのそれぞれが転送されるべきかを決定する制御手段と、
    前記制御手段により決定された前記ユーザネットワークへ至る経路のそれぞれに、前記パケット及び前記冗長パケットのそれぞれを転送する転送手段とを具備したことを特徴とするルータ装置。
  27. インターネットとの接続が複数提供されるユーザネットワークに属する自装置に、前記複数の接続のうち少なくとも一つに対応して割り当てられた、少なくとも一つのアドレスを記憶する記憶手段と、
    インターネット内に設けられたルータであって前記複数の接続のうち少なくとも二つの接続を利用して冗長性を有するパケット群を転送する機能を備えるルータに対し、前記ユーザネットワークの識別情報と前記自装置に割り当てられたアドレスに関する情報とを送信する送信手段と、
    前記複数の接続のうち自装置に提供される接続に対応するアドレスに従った経路で転送された前記ユーザネットワーク宛のパケットを受信する受信手段と、
    前記受信手段が受信したパケットから前記冗長性を除いて前記ユーザネットワーク内のノードに転送する転送手段とを具備したことを特徴とするユーザルータ装置。
  28. 前記冗長性を有するパケット群のうち一部が前記受信手段により受信され、他の一部が前記複数の接続のうち他のユーザルータ装置に提供される接続を利用して転送される場合に、前記他のユーザルータ装置により受信された各パケットについての識別情報を受信する手段を更に備え、
    前記転送手段は、受信した前記識別情報を用いて前記冗長性を除くものであることを特徴とする請求項27記載のユーザルータ装置。
  29. インターネットとの接続を複数提供されるユーザネットワークの、インターネットとの接続点に設けられたユーザルータにおいて、パケットの転送を制御する方法であって、
    前記ユーザネットワーク内のノードからインターネットへのパケットを受信し、
    受信した前記パケットの冗長パケットを作成し、
    受信した前記パケット及び作成した前記冗長パケットのうちの一部を、前記複数の接続のうちの一つを通って、インターネット内に設けられたルータであって冗長性を有するパケット群を受信すると該冗長性を除く機能を備えるルータのアドレスへ向けてパケットが転送される経路へ、転送し、
    受信した前記パケット及び作成した前記冗長パケットのうちの他の一部を、前記複数の接続のうちの他の一つを通って、前記ルータのアドレスへ向けてパケットが転送される経路へ、転送することを特徴とするパケット転送制御方法。
  30. 自装置の属するユーザネットワークに複数提供されるインターネットとの接続のうちの少なくとも一つに接続する接続手段と、
    前記ユーザネットワーク内のノードからインターネットへのパケットを受信する受信手段と、
    前記受信手段により受信したパケットの冗長パケットを作成する作成手段と、
    前記パケット及び前記冗長パケットのうちの一部を、前記接続手段が接続する接続を通って、インターネット内に設けられたルータであって冗長性を有するパケット群を受信すると該冗長性を除く機能を備えるルータのアドレスへ向けてパケットが転送される経路へ、転送する転送手段と、
    前記パケット及び前記冗長パケットのうちの他の一部は、前記複数の接続のうちの他の一つを通って、前記ルータのアドレスへ向けてパケットが転送される経路へ転送されるように、制御する制御手段とを具備したことを特徴とするユーザルータ装置。

JP2003323667A 2003-02-19 2003-09-16 ルータ装置及びパケット転送制御方法 Expired - Lifetime JP4277189B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2003323667A JP4277189B2 (ja) 2003-02-19 2003-09-16 ルータ装置及びパケット転送制御方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2003041858 2003-02-19
JP2003323667A JP4277189B2 (ja) 2003-02-19 2003-09-16 ルータ装置及びパケット転送制御方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2008206103A Division JP2008301517A (ja) 2003-02-19 2008-08-08 ルータ装置及びパケット転送制御方法

Publications (2)

Publication Number Publication Date
JP2004274703A true JP2004274703A (ja) 2004-09-30
JP4277189B2 JP4277189B2 (ja) 2009-06-10

Family

ID=33134162

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003323667A Expired - Lifetime JP4277189B2 (ja) 2003-02-19 2003-09-16 ルータ装置及びパケット転送制御方法

Country Status (1)

Country Link
JP (1) JP4277189B2 (ja)

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006090789A1 (ja) * 2005-02-25 2006-08-31 Softbank Bb Corp. データ通信システム及びデータ通信方法
JP2007235621A (ja) * 2006-03-01 2007-09-13 Nec Corp データ伝送システムおよびデータ伝送方法
JP2007251541A (ja) * 2006-03-15 2007-09-27 Mitsubishi Electric Corp 接続監視装置
JP2008527948A (ja) * 2005-01-19 2008-07-24 クゥアルコム・インコーポレイテッド 符号化伝送のための節電方法
JP2008311715A (ja) * 2007-06-12 2008-12-25 Nippon Telegr & Teleph Corp <Ntt> オーバレイノード、該オーバレイノードを備えたオーバレイネットワークおよびオーバレイルーティング方法とそのためのプログラム
JP2009071462A (ja) * 2007-09-12 2009-04-02 Nec Corp 通信装置及び通信システム並びに通信制御方法
JP2009272800A (ja) * 2008-05-02 2009-11-19 Kddi Corp 品質計測システム、受信装置、品質計測方法及びプログラム
JP2009542140A (ja) * 2006-06-27 2009-11-26 インターナショナル・ビジネス・マシーンズ・コーポレーション 高速短待ち時間データ通信環境において冗長メッセージ・ストリームを使用する高信頼性メッセージングのための方法、装置、およびプログラム
JP2009542114A (ja) * 2006-06-20 2009-11-26 ハリス コーポレイション 圧縮ベースQoSのための方法及びシステム
JP2010056990A (ja) * 2008-08-29 2010-03-11 Hitachi Ltd 複数コネクションを用いたデータ通信方法
US7693063B2 (en) 2005-06-14 2010-04-06 Fujitsu Limited Communication control apparatus and communication control method
JP2010523019A (ja) * 2007-03-21 2010-07-08 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Sipベースのメディアサービスにおけるセッション制御
WO2010116616A1 (ja) * 2009-03-30 2010-10-14 日本電気株式会社 ストリーム配信システムにおける中継装置および配信制御方法
JP2011176424A (ja) * 2010-02-23 2011-09-08 Hitachi Information Systems Ltd 通信方法及びスイッチングハブ装置
WO2011155064A1 (ja) * 2010-06-11 2011-12-15 株式会社日立製作所 中継通信装置および多段中継通信システム
JP2012501012A (ja) * 2008-08-22 2012-01-12 インテル コーポレイション 統合マルチ転送媒体コネクタ・アーキテクチャ
JP4870812B2 (ja) * 2006-06-27 2012-02-08 インターナショナル・ビジネス・マシーンズ・コーポレーション 高速短待ち時間データ通信環境においてアクティブ・フィード・アダプタとバックアップ・フィード・アダプタを同期させるための方法、装置、およびプログラム
JP2012175480A (ja) * 2011-02-23 2012-09-10 Oki Electric Ind Co Ltd 通信制御装置、通信制御方法、および、通信制御プログラム
US8782321B2 (en) 2012-02-08 2014-07-15 Intel Corporation PCI express tunneling over a multi-protocol I/O interconnect
US9003428B2 (en) 2006-06-27 2015-04-07 International Business Machines Corporation Computer data communications in a high speed, low latency data communications environment
JP2015519801A (ja) * 2012-04-18 2015-07-09 アクメ パケット インコーポレイテッドAcme Packet, Inc. リアルタイム通信のための冗長性
US9141132B2 (en) 2011-12-27 2015-09-22 Intel Corporation Multi-protocol I/O interconnect time synchronization
US9600060B2 (en) 2012-03-29 2017-03-21 Intel Corporation Link power management in an I/O interconnect
US10333817B2 (en) 2016-08-10 2019-06-25 Fujitsu Limited Non-transitory computer-readable storage medium, communication device, and determination method
JP2020195245A (ja) * 2019-05-30 2020-12-03 株式会社日立製作所 系統監視装置及び系統監視方法
WO2022201911A1 (ja) * 2021-03-25 2022-09-29 ソニーグループ株式会社 車載通信装置、通信方法、及び、通信システム

Cited By (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008527948A (ja) * 2005-01-19 2008-07-24 クゥアルコム・インコーポレイテッド 符号化伝送のための節電方法
US8826093B2 (en) 2005-01-19 2014-09-02 Qualcomm Incorporated Power saving method for coded transmission
WO2006090789A1 (ja) * 2005-02-25 2006-08-31 Softbank Bb Corp. データ通信システム及びデータ通信方法
US7693063B2 (en) 2005-06-14 2010-04-06 Fujitsu Limited Communication control apparatus and communication control method
JP2007235621A (ja) * 2006-03-01 2007-09-13 Nec Corp データ伝送システムおよびデータ伝送方法
JP2007251541A (ja) * 2006-03-15 2007-09-27 Mitsubishi Electric Corp 接続監視装置
JP4680808B2 (ja) * 2006-03-15 2011-05-11 三菱電機株式会社 接続監視装置
JP2009542114A (ja) * 2006-06-20 2009-11-26 ハリス コーポレイション 圧縮ベースQoSのための方法及びシステム
US9003428B2 (en) 2006-06-27 2015-04-07 International Business Machines Corporation Computer data communications in a high speed, low latency data communications environment
JP2009542140A (ja) * 2006-06-27 2009-11-26 インターナショナル・ビジネス・マシーンズ・コーポレーション 高速短待ち時間データ通信環境において冗長メッセージ・ストリームを使用する高信頼性メッセージングのための方法、装置、およびプログラム
US8549168B2 (en) 2006-06-27 2013-10-01 International Business Machines Corporation Reliable messaging using redundant message streams in a high speed, low latency data communications environment
US8676876B2 (en) 2006-06-27 2014-03-18 International Business Machines Corporation Synchronizing an active feed adapter and a backup feed adapter in a high speed, low latency data communications environment
JP4870812B2 (ja) * 2006-06-27 2012-02-08 インターナショナル・ビジネス・マシーンズ・コーポレーション 高速短待ち時間データ通信環境においてアクティブ・フィード・アダプタとバックアップ・フィード・アダプタを同期させるための方法、装置、およびプログラム
US8122144B2 (en) 2006-06-27 2012-02-21 International Business Machines Corporation Reliable messaging using redundant message streams in a high speed, low latency data communications environment
JP2010523019A (ja) * 2007-03-21 2010-07-08 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Sipベースのメディアサービスにおけるセッション制御
JP2008311715A (ja) * 2007-06-12 2008-12-25 Nippon Telegr & Teleph Corp <Ntt> オーバレイノード、該オーバレイノードを備えたオーバレイネットワークおよびオーバレイルーティング方法とそのためのプログラム
JP2009071462A (ja) * 2007-09-12 2009-04-02 Nec Corp 通信装置及び通信システム並びに通信制御方法
JP2009272800A (ja) * 2008-05-02 2009-11-19 Kddi Corp 品質計測システム、受信装置、品質計測方法及びプログラム
JP2012501012A (ja) * 2008-08-22 2012-01-12 インテル コーポレイション 統合マルチ転送媒体コネクタ・アーキテクチャ
JP2010056990A (ja) * 2008-08-29 2010-03-11 Hitachi Ltd 複数コネクションを用いたデータ通信方法
WO2010116616A1 (ja) * 2009-03-30 2010-10-14 日本電気株式会社 ストリーム配信システムにおける中継装置および配信制御方法
JP2011176424A (ja) * 2010-02-23 2011-09-08 Hitachi Information Systems Ltd 通信方法及びスイッチングハブ装置
WO2011155064A1 (ja) * 2010-06-11 2011-12-15 株式会社日立製作所 中継通信装置および多段中継通信システム
JP5485389B2 (ja) * 2010-06-11 2014-05-07 株式会社日立製作所 中継通信装置および多段中継通信システム
US8971318B2 (en) 2010-06-11 2015-03-03 Hitachi, Ltd. Relay communication apparatus and multistage relay communication system
JP2012175480A (ja) * 2011-02-23 2012-09-10 Oki Electric Ind Co Ltd 通信制御装置、通信制御方法、および、通信制御プログラム
US9141132B2 (en) 2011-12-27 2015-09-22 Intel Corporation Multi-protocol I/O interconnect time synchronization
US9164535B2 (en) 2011-12-27 2015-10-20 Intel Corporation Multi-protocol I/O interconnect time synchronization
US8782321B2 (en) 2012-02-08 2014-07-15 Intel Corporation PCI express tunneling over a multi-protocol I/O interconnect
US9934181B2 (en) 2012-02-08 2018-04-03 Intel Corporation PCI express tunneling over a multi-protocol I/O interconnect
US10387348B2 (en) 2012-02-08 2019-08-20 Intel Corporation PCI express tunneling over a multi-protocol I/O interconnect
US10884965B2 (en) 2012-02-08 2021-01-05 Intel Corporation PCI express tunneling over a multi-protocol I/O interconnect
US9600060B2 (en) 2012-03-29 2017-03-21 Intel Corporation Link power management in an I/O interconnect
JP2015519801A (ja) * 2012-04-18 2015-07-09 アクメ パケット インコーポレイテッドAcme Packet, Inc. リアルタイム通信のための冗長性
US10333817B2 (en) 2016-08-10 2019-06-25 Fujitsu Limited Non-transitory computer-readable storage medium, communication device, and determination method
JP2020195245A (ja) * 2019-05-30 2020-12-03 株式会社日立製作所 系統監視装置及び系統監視方法
WO2022201911A1 (ja) * 2021-03-25 2022-09-29 ソニーグループ株式会社 車載通信装置、通信方法、及び、通信システム

Also Published As

Publication number Publication date
JP4277189B2 (ja) 2009-06-10

Similar Documents

Publication Publication Date Title
JP4277189B2 (ja) ルータ装置及びパケット転送制御方法
US7188189B2 (en) System and method to improve the resiliency and performance of enterprise networks by utilizing in-built network redundancy
US7336615B1 (en) Detecting data plane livelines in connections such as label-switched paths
JP5596182B2 (ja) ポイント・ツー・マルチポイント・ラベル・スイッチ・パスのバックアップ・イングレスを計算するシステムおよび方法
US6751190B1 (en) Multihop nested tunnel restoration
US7894352B2 (en) Detecting data plane liveliness of a label-switched path
CN112118182B (zh) 发送流量工程的ip路径隧道
US7765306B2 (en) Technique for enabling bidirectional forwarding detection between edge devices in a computer network
US20080159288A1 (en) TRAFFIC ENGINEERING AND FAST PROTECTION USING IPv6 CAPABILITIES
US20150003240A1 (en) Adaptive call routing in ip networks
US7778204B2 (en) Automatic maintenance of a distributed source tree (DST) network
US8009683B2 (en) IP network system
JP3665622B2 (ja) ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法
KR20090003225A (ko) Mac 브리지를 이용하여 멀티홉 메시 네트워크를 연결하기 위한 컴퓨터 구현 방법, 컴퓨터 판독가능 매체, 및 메시 네트워크 연결 장치
CN113056891B (zh) 源路由隧道入节点保护
WO2005034440A1 (ja) ルータ選択方法及びルータ装置
JP2004128723A (ja) ラベルスイッチルータ及びそのパス切替制御方法
JP2005524261A (ja) 冗長性接続用に動的に修正されるメトリック値を用いるトラフィックネットワークフロー制御方法
JPWO2005057864A1 (ja) ネットワークの経路切替えシステム
JP3736554B2 (ja) ルータ装置及びパケット転送制御方法
JP2008301517A (ja) ルータ装置及びパケット転送制御方法
JP4305091B2 (ja) マルチホーミング負荷分散方法およびその装置
WO2009033104A1 (en) Traffic re-route for optical add-drop multiplexer
Charoenpanyasak et al. SCTP multihoming with cross layer interface in ad hoc multihomed networks
JP5071245B2 (ja) パケットの交換装置及びプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060912

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080602

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080610

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080808

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090127

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090225

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120319

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4277189

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120319

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120319

Year of fee payment: 3

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120319

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120319

Year of fee payment: 3

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120319

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130319

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130319

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130319

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130319

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140319

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term