ソースアドレスを選択する通信装置
【課題】複数のソースアドレスを有する通信装置において、宛先通信装置との接続性が確認され、かつ、より性能の良い通信経路を経由するためのソースアドレスを選択する通信装置を提供する。
【解決手段】本発明の通信装置は、複数のネットワークと接続可能であり、各ネットワークとそれぞれ接続するためのソースアドレスが割り当てられた通信装置において、送信データの宛先に関する情報を受信すると、各ネットワークを介した宛先までのそれぞれの通信経路の特性情報を取得する通信経路特性情報取得部と、特性情報に基づいて、複数のソースアドレスの中から一つのソースアドレスを選択するソースアドレス選択部と、選択されたソースアドレスに対応するネットワークに対して送信データを送信する送信部とを備える。複数のネットワークのうち最適な通信経路を有するネットワークに対応するソースアドレスを選択して、通信を行うことができる。
【解決手段】本発明の通信装置は、複数のネットワークと接続可能であり、各ネットワークとそれぞれ接続するためのソースアドレスが割り当てられた通信装置において、送信データの宛先に関する情報を受信すると、各ネットワークを介した宛先までのそれぞれの通信経路の特性情報を取得する通信経路特性情報取得部と、特性情報に基づいて、複数のソースアドレスの中から一つのソースアドレスを選択するソースアドレス選択部と、選択されたソースアドレスに対応するネットワークに対して送信データを送信する送信部とを備える。複数のネットワークのうち最適な通信経路を有するネットワークに対応するソースアドレスを選択して、通信を行うことができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信を行う通信装置が複数のネットワークに接続しており、また、それぞれのネットワークからアドレスを割り当てられている場合において、通信装置が他の通信装置と適切な通信経路で通信することを可能とするためのソースアドレスを選択する通信装置に関する。
【背景技術】
【０００２】
近年、IP(Internet Protocol)技術に基づいたインターネットが全世界で急速に普及してきている。インターネットでは、ネットワークプロバイダあるいはインターネットサービスプロバイダ(ISP)と呼ばれる事業者が、IPアドレスあるいは、IPアドレスの上位ビット部のプレフィックスをユーザに割り当て、ユーザの通信装置（例えば、パーソナルコンピュータ）は、そのIPアドレスあるいはプレフィックスを含むIPアドレスを通信装置のソースアドレスとしてインターネットにアクセスする。
【０００３】
各事業者がそれぞれ独自のサービスを提供していたり、企業内ネットワークにアクセスしたりするために、ユーザは複数のネットワークからIPアドレス(プレフィックス)を割り当てられることが多くなってきている。
【０００４】
このように、複数のIPアドレスが割り当てられている場合は、このうちの一つのIPアドレスをソースアドレスと選択し、そのIPアドレスを用いてネットワークにアクセスする必要がある。ソースアドレス選択方法として、インターネットの仕様などの標準化活動を行っている組織IETF(The Internet Engineering Task Force)では、次の方法を標準化している。すなわち、従来のソースアドレス選択方法は、宛先アドレスとの最大プレフィックス一致に基づいて、ソースアドレスを選択する方法である。
【０００５】
図１は、従来のソースアドレス選択方法を説明する図である。図１において、複数のIPアドレスを有する通信装置Xが、宛先通信装置Yと通信するとき、通信装置Xは、最大プレフィクス長一致に基づいて、IPアドレスを選択する。具体的には、通信装置Xが、二つのIPアドレス、2001:0:10::1と2001:100:10::1を有し、宛先通信装置YのIPアドレスが、2001:100:20::1である場合、通信装置Ｘは、宛先通信装置YのIPアドレスとのプレフィクスの一致度がより高いIPアドレス2001:100:10::1（ネットワークプロバイダBから割り当てられたIPアドレス）を選択する。
【０００６】
しかしながら、プレフィックス長の一致が長いほど、ネットワーク的に近いとは限らない。例えば、宛先通信装置Yへの往路パスに障害があった場合は通信不能となる。障害がなく、正常に宛先通信装置Yと通信できたとしても、遅延などの性能は、ネットワークプロバイダAを経由した方が良い場合も考えられる。また、宛先通信装置Yからのリターンパスに障害があった場合も通信不能となる。また、ネットワークプロバイダ事業者が独自のサービスを提供するための閉域網のアドレスをソースアドレスとしてインターネットにアクセスした場合、インターネットと接続関係の無い閉域網のためリターンパスが存在しないという致命的な問題が生じる。
【０００７】
また、"Site Exit Issue"の問題も存在することが指摘されている。"Site Exit Issue"は、"address spoofing"を防止するために、プロバイダが割り当てたアドレス／プレフィックス以外のソースアドレスを有するパケットを廃棄する機能であるIngress Filteringにより、引き起こされる。すなわち、Hostが選択したソースアドレスを割り当てたプロバイダ以外のプロバイダにルーティングされると、Ingress Filteringにより廃棄され、全く通信できなくなってしまう。IETFでは、この"Site Exit Issue"の問題を解決するために、以下の４つの方法を提案しているが、それぞれに課題が存在する。
【０００８】
(1) Ingress Filteringのルール緩和
【０００９】
Ingress Filteringによるaddress spoofingに対する効果が減少し、セキュリテの脆弱性を増す。
【００１０】
(2) ソースアドレスルーティング
【００１１】
通信装置がある程度経路を制御できる点に利点があるが、その経路が最適か接続性は 確保されているかなどの保証がない。
【００１２】
(3) 端末によるソースアドレス選択(Source Address Discovery、 Exit Router Discovery)
・SAD： Path MTU-Discoveryのように、ソースアドレスを通信可能になるまでの順 次変えていくため、遅延が大きく、また、経路が最適とは限らない。
【００１３】
・ERD： Exit Routerまでのトンネル設定が必要であり、通信装置の負荷が増大する。
【００１４】
(4) NAT
【００１５】
End-to-Endで直接通信可能なIPv6の場合、その利点を打ち消してしまう。
【００１６】
このように、標準化技術では、経路の最適化(例：RTTが最小)とSite Exit Issueを共に解決することができなかった。
【００１７】
一方、上述したような標準化技術の課題に対処するために、下記特許文献１では、複数のISPと接続したマルチホーム環境で、接続性が確認されたISPにより割り当てられたアドレスプレフィックスをソースアドレスとして、ルータでソースアドレスルーティングすることで、通信できるようにすることが提案されている。特許文献１では、IPv6のND(Neighbor Discovery)メッセージ等により、それぞれのISPとの接続性確認をすると共に、ソースアドレスルーティングを行うことが記述されている。
【００１８】
しかし、特許文献１の発明によれば、ISPとの接続性しか確認していないため、宛先ドメイン／ホストの接続性を保証できない。また、複数のISPとの接続性が確認されているときに、どのISPのプレフィックスを利用すべきか具体化されていない。
【００１９】
一方、特許文献２では、複数のルータからアドレスプレフィックスを割り当てられる環境で、割り当てられたアドレスプレフィックス毎に仮想インターフェースを生成し、アドレスプレフィックスを利用して生成したアドレスを付与する。そして、ソースアドレス選択は、宛先アドレスとの最長プレフィックス一致に基づいて行う。さらに、アドレスプレフィックスの配布時に、プレフィックスと対応付けたラベルを配布することでパケット処理効率を上げることが記述されている。
【００２０】
しかし、ソースアドレス選択方法自体は、上述の標準化技術の範囲内であって、最適な経路による通信、Site Exit Issueの解決に課題が残る。
【特許文献１】特開2003-298635号
【特許文献２】特開2003-324461号
【発明の開示】
【発明が解決しようとする課題】
【００２１】
このように、End-to-Endの接続性が保証され、かつ、性能が最適となる通信路を経由するようなソースアドレス選択方法を提供することが望まれている。
【００２２】
従って、本発明の目的は、複数のネットワークプロバイダにより割り当てられたアドレスから一のアドレスを選択し、それをソースアドレスとして通信する通信装置において、宛先通信装置との双方向の接続性が確認され、かつ、より性能の良い通信経路を経由するためのソースアドレスを選択する通信装置を提供することにある。
【課題を解決するための手段】
【００２３】
上記目的を達成するための本発明の通信装置の構成は、複数のネットワークと接続可能であり、各ネットワークとそれぞれ接続するためのソースアドレスが割り当てられた通信装置において、送信データの宛先に関する情報を受信すると、各ネットワークを介した前記宛先までのそれぞれの通信経路の特性情報を取得する通信経路特性情報取得部と、
前記特性情報に基づいて、複数のソースアドレスの中から一つのソースアドレスを選択するソースアドレス選択部と、前記選択されたソースアドレスに対応するネットワークに対して前記送信データを送信する送信部とを備えることを特徴とする。
【００２４】
例えば、前記特性情報は、前記宛先までのそれぞれの通信経路の接続性に関する情報であり、この場合、前記通信経路特性情報取得部は、各ネットワークの通信経路が前記宛先まで接続しているかどうかを確認し、前記ソースアドレス選択部は、前記宛先と接続しているネットワークに対応するソースアドレスを選択する。
【００２５】
また、例えば、前記特性情報は、前記宛先までのそれぞれの通信経路の遅延性に関する情報であり、この場合、前記通信経路特性情報取得部は、各ネットワークの通信経路の遅延を測定し、前記ソースアドレス選択部は、通信経路の遅延が最小となるネットワークに対応するソースアドレスを選択する。
【００２６】
また、本発明の通信装置は、さらに、前記選択されたソースアドレスと前記宛先との対応関係を格納する格納部を備えていてもよく、この場合、前記通信経路特性情報取得部は、前記格納部に、前記宛先に対応するソースアドレスが格納されていない場合に、前記特性情報を取得し、前記ソースアドレス選択部は、前記特性情報に基づいて選択したソースアドレスを、前記宛先に対応づけて前記格納部に登録する。そして、好ましくは、前記格納部に格納された前記対応関係は、所定時間経過後消去される。
【発明の効果】
【００２７】
本発明の通信装置によれば、複数のソースアドレスが割り当てられた通信装置において、複数のネットワークのうち最適な通信経路を有するネットワークに対応するソースアドレスを選択して、通信を行うことができる。
【発明を実施するための最良の形態】
【００２８】
以下、図面を参照して本発明の実施の形態について説明する。しかしながら、かかる実施の形態例が、本発明の技術的範囲を限定するものではない。
【００２９】
図２は、本発明の第一の実施の形態例における通信装置を説明する図であって、第一の実施の形態例におけるブロック構成例を示す図である。第一の構成例の通信装置は、例えばパーソナルコンピュータのような端末１Aである。端末１A（通信装置）は、各ネットワークプロバイダからの割り当てられたIPアドレス（以下、単にアドレスと称す）をソースアドレスリスト格納部１６に記憶する。ネットワークプロバイダからのアドレス割り当て方法は、主に次の３つが考えられる。（本発明では下記の3方法に限定するものではない）
IPCP (Internet Protocol Control Protocol)
DHCP (Dynamic Host Configuration Protocol)
RA (Router Advertisement)
一般に、アドレスはネットワークアドレス部(プレフィックスという)とホストアドレス部から構成される。ネットワークプロバイダは、プレフィックスとホストアドレス部を含むアドレスを割り当てることもあるし、プレフィックスのみを割り当て、ホストアドレス部はプレフィックスを割り当てられた通信装置がMACアドレスなどから自動的に生成し、アドレスを合成することもある。ソースアドレスリスト格納部１６はこうして得られたアドレスを記憶する。複数のネットワークプロバイダそれぞれからアドレスを割り当てられた場合は、ソースアドレス格納部１６は、複数のアドレスを記憶する。
【００３０】
送信データ受付部１１は、アプリケーションから送信すべきデータを受信すると、そのデータと宛先情報を送信パケット生成部１２に送る。ここで、宛先情報としては、宛先通信装置のアドレスであったり、ホスト名であったりする。
【００３１】
送信パケット生成部１２は、送信データをパケット化し、送信データにソースアドレス及び宛先アドレスを付した送信パケットを生成する。
【００３２】
図３は、送信パケット生成部１２の処理例を示すフローチャートである。送信パケット生成部１２は、送信データ受付部１１より送信データ、宛先情報を受信すると（S１１）、宛先情報がアドレスであるかどうか判定する（S１２）。宛先情報がアドレスであれば、宛先・ソースアドレス対応表格納部１４を検索し、宛先アドレスに対応するソースアドレスが登録されているか問い合わせ（S１３）、ソースアドレスが登録されていれば（S１４）、そのアドレスを利用して送信パケットを生成し、パケット送信部１３に送る（S１９）。ソースアドレスが得られなかった場合（Ｓ１４）や宛先情報がホスト名だった場合（この場合、ソースアドレスも得られていない）（Ｓ１２）、宛先情報をソースアドレス選択部１５に送る（Ｓ１５、Ｓ１７）。そして、後述するソースアドレス選択部１５の処理により、ソースアドレス（Ｓ１６）又はソースアドレスと宛先アドレス（Ｓ１８）の応答を受信すると、そのアドレスを利用して送信パケットを生成し、パケット送信部１３に送る。
【００３３】
図２に戻って、宛先・ソースアドレス対応表格納部１４は、宛先アドレスとソースアドレスの対応関係を記憶すると共に、一定時間、対応関係の問い合わせがない場合は、その登録の削除を行う。
【００３４】
ソースアドレス選択部１５は、本発明に特徴的な要素であってソースアドレス格納部１６に格納されている複数のソースアドレスの中から、宛先通信装置との通信に最適なソースアドレスを選択する。
【００３５】
図４は、ソースアドレス選択部１５の処理例のフローチャートである。ソースアドレス選択部１５は、送信パケット生成部１２から、宛先情報を受けると（Ｓ２１）、ソースアドレスリスト格納部１６に格納されている複数のソースアドレスを取得し（Ｓ２２）、宛先情報とソースアドレスを通信経路特性情報取得部１７に送り（Ｓ２３）、通信経路特性情報取得部１７から情報を待つ。そして、通信経路特性情報取得部１７より、各ソースアドレスを利用した場合の特性情報をそれぞれ受信して（Ｓ２４）、その性能情報に基づいて、最良の性能を得られるソースアドレスを選択し、それを送信パケット生成部１２に応答するとともに、宛先・ソースアドレス対応表格納部１４に登録する（Ｓ２５）。
【００３６】
なお、送信パケット生成部１２から受信した宛先情報が宛先アドレスではなく、宛先ホスト名の場合は、通信経路特性情報取得部１７は、特性情報と一緒に宛先アドレスをソースアドレス選択部１５に応答し、ソースアドレス選択部１５は、ソースアドレスと共に宛先アドレスを送信パケット生成部１２に応答する。また、ソースアドレス選択部１５は、定期的に性能情報の更新を通信経路特性情報取得部１７に要求し、その結果を宛先・ソースアドレス対応表格納部１４に反映させてもよい。
【００３７】
通信経路特性情報取得部１７は、通信装置と相手先通信装置との間の通信経路の特性情報を取得する。特性情報は、通信経路の接続性（通信障害、通信不能状態にないかどうか）や、接続可能状態における遅延性（通信速度）などの情報である。
【００３８】
図５は、第一の実施の形態例における通信経路特性情報取得部１７の処理例を説明する図である。図５の処理例は、通信装置X（端末１A）と宛先通信装置Yとの間の接続性を確認するための処理であって、宛先情報がホスト名である場合に、宛先アドレスを取得する処理を利用して、接続性に関する特性情報を取得する。通信経路特性情報取得部１７（通信装置X）は、複数のソースアドレスをソースアドレス格納部１６より取得している。宛先情報がホスト名の場合、通信経路特性情報取得部１７は、宛先アドレスを取得するために、各ネットワークプロバイダの名前解決サーバA、Bのアドレスを宛先アドレスとし、ソースアドレスは各ネットワークプロバイダから割り当てられたアドレスを使用した名前解決要求メッセージを生成し、パケット送信部１３に送る。パケット送信部１３は、各名前解決サーバA、Bに名前解決要求メッセージを送信する。図５の場合、名前解決サーバAは、宛先通信装置Yが属する名前解決サーバCから宛先アドレスを含む名前解決応答を受信し、通信装置Xのパケット受信部１８は、それを受信する。一方、名前解決サーバBは、名前解決サーバCとの通信経路に障害があるため、名前解決応答を受信しない。この場合、名前解決サーバBは、名前解決エラーメッセージを、通信装置Xに送信する。
【００３９】
通信経路特性情報取得部１７は、パケット受信部１８より名前解決サーバAからの名前解決応答を受信して、宛先アドレスを取得する。そして、通信経路特性情報取得部１７は、宛先アドレスを取得するとともに、各ネットワークの宛先通信装置との接続性に関する情報も取得することができる。すなわち、名前解決サーバAを経由する通信経路は、宛先通信装置のネットワークと接続しているが、名前解決サーバBを経由する通信経路は宛先通信装置のネットワークと接続していない。
【００４０】
一般には、各ネットワークプロバイダ経由の名前解決応答で得られる宛先アドレスは同一であるが、サーバ負荷分散が施されている場合、異なるアドレスが得られることもある。この場合、それぞれの宛先アドレスにアクセスするときは、そのアドレスを取得したときに経由したネットワークプロバイダに割り当てられたアドレスをソースアドレスとして利用する。
【００４１】
このように、通信経路特性情報取得部１７は、名前解決のためのメッセージを宛先通信装置の属するネットワークとの接続性の確認に用いることができる。すなわち、名前解決応答が得られないネットワークプロバイダは宛先通信装置の属するネットワークとの接続性がないと判断でき、一方、名前解決応答が得られるネットワークプロバイダは接続性が存在すると判断することができる。通信経路特性情報取得部１７は、この旨、ソースアドレス選択部１５に通知する。特性情報の取得方法の具体例について、さらに後述する。
【００４２】
こうして、パケット送信部１３は、送信パケットのソースアドレスに基づき、そのソースアドレスを割り当てたネットワークプロバイダのネットワークに対してパケットを転送する。
【００４３】
図６は、本発明の第二の実施の形態例における通信装置を説明する図である。第二の実施の形態例における通信装置は、端末１Aと接続するゲイトウェイ１Bである。ゲイトウェイ１Bには、複数の端末１Aが接続可能であって、複数の端末１Aが、ゲイトウェイ１Bを介して、ネットワークに接続することができる。
【００４４】
図７は、本実施の第二の実施の形態例における端末１Aとゲイトウェイ（通信装置）１Bのブロック構成を示す図である。本第二の実施の形態例では、図２の端末１Aにおけるソースアドレス選択機能を、ゲイトウェイ１Bが実現する。
【００４５】
ゲイトウェイ１Bは、各ネットワークプロバイダより、プレフィックスをそれぞれ割り当てられ、その情報をソースアドレスリスト格納部１６Bに記憶するとともに、各ネットワークプロバイダから割り当てられたプレフィックスを用いたアドレスを端末１Aに割り当てる。端末１Aは、ゲイトウェイ１Bにより割り当てられたアドレスをソースアドレスリスト格納部１６Aに記憶する。
【００４６】
端末１Aは、送信データ受付部１１、送信パケット生成部１２、パケット送信部１３A、宛先・ソースアドレス対応表格納部１４、ソースアドレス格納部１７A、パケット受信部１８A、アドレス情報要求部１９を備える。なお、パケット送信部１３A及びパケット受信部１８Aは、それぞれ、ゲイトウェイ１Bに対するパケットの送受信を行う。
【００４７】
ゲイトウェイ１Bは、パケット送信手段１３B、ソースアドレス選択部１５、ソースアドレスリスト格納部１６B、通信経路特性情報取得部１７、パケット受信手段１８B、アドレス情報応答手段２０を備える。パケット送信手段１３B及びパケット受信手段１８Bは、ネットワークに対するパケットの送受信と、端末１Aに対するパケットの送受信を行う。
【００４８】
また、図２の構成では、送信パケット生成部１２がソースアドレス選択部１５に対して直接宛先情報を送り、ソースアドレス選択部１５からアドレスを直接取得するが、図７の構成では、端末１Aのアドレス情報要求部１９とゲイトウェイ１Bのアドレス情報応答部２０を介して、宛先情報及びアドレスの送受信が行われる。具体的には、端末１Aのアドレス情報要求部１９が、ゲイトウェイ１Bのアドレス情報応答部２０に対して宛先情報を含むアドレス要求を送り、アドレス情報応答部２０は、そのアドレス要求をソースアドレス選択部１５に転送する。そして、アドレス情報応答部２０は、ソースアドレス選択部１５により選択されたアドレスを、アドレス要求部１９に通知する。
【００４９】
図８は、本発明の第二の実施の形態例における端末１Aとゲイトウェイ１Bの別のブロック構成例を示す図である。図８では、端末１Aとゲイトウェイ１Bの両方が、それぞれ宛先・ソースアドレス対応表格納部１４A、１４Bを有している。ゲイトウェイ１Bに複数の端末１Aが接続している場合、宛先・ソースアドレス対応表格納部１４Bをゲイトウェイ１Bに設けることで、複数の端末１Aそれぞれからのアドレス要求に対応することができる。
【００５０】
以下、通信経路特性情報取得部１７における特性情報の取得に関するさまざまな形態例について説明する。
【００５１】
図９は、ネットワークの接続性に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。通信経路特性情報取得部１７は、接続性確認パケット生成部１７１と接続性確認パケット受信部１７２とを備える。接続性確認のために名前解決メッセージが利用される場合、接続性確認パケット生成部１７１は、ソースアドレス選択部１５からの指示に従って、上述の名前解決要求（図５参照）を生成し、接続性確認パケット受信部１７２は、名前解決応答又は名前解決エラーメッセージを受信し、ソースアドレス選択部１５に通知する。
【００５２】
接続性確認は、名前解決メッセージ以外にも、例えば、ICMP Echo メッセージ、SIPメッセージ、TCPのセッション確立メッセージなどを利用してもよい。
【００５３】
図１０は、ICMP Echo メッセージを利用した接続性確認のための通信経路特性情報取得部１７の処理例を説明する図である。ICMP Echo メッセージを利用する場合、通信装置X（端末１A又はゲイトウェイ１B）の通信経路特性情報取得部１７（接続性確認パケット生成部１７１）は、宛先アドレスを宛先通信装置Yのアドレスとして、ソースアドレス毎にICMP Echo メッセージを生成し、ICMP Echo メッセージは、それぞれのネットワークを経由して宛先通信装置Yに転送される（名前解決メッセージを利用する場合は、名前解決要求は、宛先通信装置Yまでは転送されず、その手前の宛先通信装置Yの属するネットワークの名前解決サーバが応答処理を行う）。宛先通信装置Yは、正常に受信したICMP Echo メッセージに対応するICMP Echo Replyメッセージを返送する。通信装置Xの通信経路特性情報取得部１７（接続性確認パケット受信部１７２）は、ICMP Echo Replyメッセージを受信すると、ICMP Echo メッセージのソースアドレスにおける接続性が確認された旨をソースアドレス選択部１５に通知する。一方、ICMP Echo Replyメッセージの受信に失敗した場合は、ICMP Echo メッセージのソースアドレスでは接続性が確認されなかったことをソースアドレス選択部１５に通知する。
【００５４】
なお、同一のICMP Echoメッセージを複数送信して、接続性を確認することもできる。この場合、例えば、ICMP Echo メッセージを５メッセージずつ送信したとすると、あるソースアドレスに対するICMP Echo Replyメッセージは５メッセージ受信できたのに対して、別のソースアドレスに対するICMP Echo Replyメッセージは３メッセージしか受信できなかった場合、ソースアドレス選択部１５は前者のソースアドレスを使用することを選択することができる。後者のソースアドレスを使った場合、ネットワークの輻輳のため、５メッセージのうち２メッセージが往復の経路上のどこかで廃棄されたものと推測されるからである。
【００５５】
SIPメッセージを利用する場合、接続性確認パケット生成部１７１は、SIP Inviteメッセージを生成し、宛先通信装置あるいは仲介するSIPプロキシサーバに転送する。直接あるいはSIPプロキシサーバを介して、SIP Inviteメッセージを受信した宛先通信装置は、通信の開始に問題がなければ、SIP 200 OKメッセージを返信する。接続性確認パケット受信部１７２は、ICMP Echo Replyと同様に、SIP 200 OKメッセージの受信結果をソースアドレス選択部１５に通知して、ソースアドレス選択部１５は、受信結果に基づいて、利用するソースアドレスを選択する。
【００５６】
また、ICMP EchoやSIPメッセージなどのように、宛先通信装置からの応答を受けるのではなく、ネットワーク管理サーバ（例えば、名前解決メッセージを利用する場合の名前解決サーバ）に正常性を確認することもある。
【００５７】
図１１は、ネットワークの遅延に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。通信経路特性情報取得部１７は、遅延測定パケット生成部１７３と遅延測定応答パケット受信部１７４と遅延計測部１７５とを備える。遅延測定には、名前解決メッセージ、ICMP Echoメッセージ、SIPメッセージ、TCPのセッション確立メッセージなどが利用される。
【００５８】
図１２は、ICMP Echoメッセージを利用した遅延測定のための通信経路特性情報取得部１７の処理例を説明する図である。通信装置Xの通信経路特性情報取得部１７（遅延測定パケット生成部１７３）は、遅延測定パケットとして、ソースアドレス毎にICMP Echoメッセージを利用した遅延測定パケットを生成し、送信するとともに、遅延計測部１７５に対して、タイマーのセットを行う。そして、遅延測定応答パケット受信部１７４が遅延測定パケットに対応する応答パケット(ICMP Echo Replyメッセージ)を受信すると、遅延計測部１７５のタイマー値を、ソースアドレスとともに、ソースアドレス選択部１５に通知する。所定時間応答がない場合は、ソースアドレスとともに、その旨通知する。ソースアドレス選択部１５は、最短の遅延を実現するソースアドレスを選択する。なお、遅延測定は、一回だけでなく、複数回行い、その平均値をソースアドレス選択部１５に通知することが好ましい。
【００５９】
図１３は、通信経路の帯域に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。通信経路特性情報取得部１７は、帯域予約パケット生成部１７６と帯域予約応答パケット受信部１７７とを備える。帯域に関しては、帯域予約のためのリソース予約プロトコル（RSVP）やSIPメッセージなどのメッセージが利用される。ネットワーク管理サーバに対するメッセージが利用されてもよい。
【００６０】
帯域予約パケット生成部１７６は、所定のメッセージを利用して、利用を希望する帯域を記載した帯域予約要求パケットをソースアドレス毎に生成して送信する。帯域予約応答パケット受信部１７７は、帯域予約応答パケットを受信し、応答パケット内に含まれる予約可能な帯域情報を、ソースアドレスとともにソースアドレス選択部１５に通知する。そして、ソースアドレス選択部１５は、最も帯域の太い経路を実現するソースアドレスを選択する。
【００６１】
図１４は、通信経路のポリシーに関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。通信経路特性情報取得部１７は、ポリシー検索部１７８とポリシー格納部１７９とを備える。ポリシーは、宛先アドレスと接続するために利用するネットワークの優先度である。ポリシー格納部１７９の登録内容は、ネットワーク管理者による設定や管理サーバからのダウンロードにより構築することができる。また、ポリシー格納部で優先度を解決できない場合、ポリシー検索部１７９は、ネットワーク管理サーバなどに問い合わせることもできる。設定する優先度については、ネットワーク管理者の裁量によるものであり、本発明では特に規定しないが、通信コストなどを基準に優先度を決めることもできる。
【００６２】
ポリシー検索部１７８は、宛先情報を受信すると、宛先情報をキーとしてポリシー格納部１７９を検索し、接続するネットワークの優先度を取得する。そして、優先度の情報をソースアドレス選択部１５に通知する。ソースアドレス選択部１５では、取得された優先度のうち、最高優先度を有するネットワークより割り当てられたアドレスをソースアドレスとして選択する。好ましくは、上述の接続性確認をあわせて行い、接続性が確認されたネットワークの中から最高優先度のネットワークを選択してもよい。
【００６３】
図１５に、ポリシー格納部１７９の構成例を示す図である。検索キーとしての宛先情報は、例えば、ホスト名(いわゆるFQDN: Fully Qualified Domain Name)あるいは、アドレス(プレフィックス)である。そして、各優先度におけるネットワーク識別子あるいはネットワークから割り当てられたプレフィックスを記憶する。
【００６４】
図１６は、図７の構成（第二の実施の形態例）における名前解決メッセージを利用した接続性確認の処理例を説明する図である。図１６において、まず、端末１A側（例えば、送信パケット生成部１２）が名前解決要求をゲイトウェイ１Bに送ると、ゲイトウェイ１B（通信装置）の通信経路特性情報取得部１７は、その名前解決要求を各ネットワークの名前解決サーバに送り、名前解決応答を受信する。そして、ソースアドレス選択部１５により選択されたソースアドレスを、受信した名前解決応答を利用して選択されたソースアドレスを端末１Aに通知する。図７の構成例においても、接続性の確認は、名前解決メッセージに限らず、ICMP Echoメッセージなどの他のメッセージを利用してもよい。
【００６５】
図１７は、名前解決メッセージのフォーマット例を示す図である。名前解決要求メッセージでは、図のQuestionにホスト名が含まれる。一方、名前解決応答メッセージでは、Answerにホストのアドレス情報、Authorityに名前解決サーバ名、Additionalに、名前解決サーバ名のアドレスがそれぞれ含まれる。ゲイトウェイ１Bが利用するソースアドレスを選択した後、端末１Aに名前解決応答メッセージを送信するときに、Authorityにはソースアドレスを割り当てたネットワークプロバイダの名前解決サーバ名、Additionalには、その名前解決サーバのアドレスを含める。名前解決応答メッセージを受信した端末１Aは、名前解決サーバのアドレスと最大プレフィックス一致するアドレスをソースアドレスとして利用するように判断する。
【００６６】
なお、上述の例では、既存の名前解決メッセージのフィールドを用いて、利用するソースアドレスを選択するための情報(名前解決サーバのアドレス)を端末１Aに通知するが、独自のフィールドを定義して、ソースアドレス(プレフィックス)を通知することもできる。
【００６７】
また、名前解決サーバのメッセージ内容ではなく、メッセージを転送するためのパケットヘッダに付与されるアドレスを用いて、端末１Aが利用するソースアドレスを通知することもできる。すなわち、ゲイトウェイ１Bから端末１Aに送信する名前解決メッセージのソースアドレスとして、選択されたソースアドレスと同じプレフィックスを有するゲイトウェイ１Bのアドレスを利用する。本メッセージを受信した端末１Aは、本メッセージのソースアドレスと最大プレフィックス一致するアドレスをソースアドレスとして利用するように判断する。
【００６８】
図１８は、図７の構成における名前解決メッセージを利用した接続性確認の別の処理例を説明する図である。図１８では、ゲイトウェイ１B（通信装置）から端末１Aへのソースアドレスを、名前解決応答に含めて通知せず、名前解決応答とは異なるリダイレクト（Redirect）メッセージを利用して通知する。なお、図１８では、リダイレクトメッセージの送信タイミングを名前解決応答メッセージ後としているが、端末１Aから宛先通信装置への通信パケットをゲイトウェイ１Bが受信した後にリダイレクトメッセージを送信するようにしてもよい。
【００６９】
図１９は、IPv6におけるリダイレクトメッセージのフォーマット例を示す図である。メッセージ中のTarget Addressには、選択したソースアドレスと同一のプレフィックスを使ったゲイトウェイ１Bのアドレス、Destination Addressには、宛先通信装置のアドレスが含められる。
【００７０】
端末１Aは、リダイレクトメッセージに含まれるゲイトウェイ１０Aのソースアドレスとプレフィックスが同じアドレスをソースアドレスとして、宛先アドレスとの対応関係を保存する。
【００７１】
図２０は、IPv4におけるリダイレクトメッセージのフォーマット例を示す図である。メッセージ中のGateway Internet Addressには、選択したソースアドレスと同一のプレフィックスを使ったゲイトウェイ１Bのアドレス、Internet Header + 65 bits of Original Data Datagramには、宛先通信装置のアドレスが含められる。
【００７２】
図２１は、図８の構成例において、ゲイトウェイ１Bが端末１Aから通信パケットを受信した場合の処理例を示す図である。具体的には、ゲイトウェイ１B（通信装置）が通信パケットの宛先アドレスとソースアドレスの対応関係のチェックし、ゲイトウェイ１Bで、通信パケットの宛先アドレスとソースアドレスの対応関係の正当性が確認できなかったため、ソースアドレスの選択を行い、適切なソースアドレスをリダイレクトメッセージにより、端末１Aに通知する例を示している。
【００７３】
図８の構成では、端末１Aとゲイトウェイ１Bの両方が、それぞれ宛先・ソースアドレス対応表格納部１４A、１４Bを有しているが、両者の内容が一致しない場合があり得る。具体的には、宛先・ソースアドレス対応表の各宛先・ソースアドレスの対応関係は、ソースアドレス選択部１５により選択されてから所定時間経過後消去される。ネットワークの特性（接続性、遅延性、帯域など）は、リアルタイムで変化しているため、一定時間経過後は、当該対応関係が最適でなくなってしまう可能性があるからである。消去された後に、再度、同じ宛先アドレスへの接続要求があった場合は、再度特性情報を取得し直して、最適なソースアドレスが選択され、その対応関係が宛先・ソースアドレス対応表格納部１４に格納される。この際、宛先・ソースアドレスの対応関係を保持する時間に関し、ゲイトウェイ１Bの方が端末１Aより短く設定される場合がある。ゲイトウェイ１Bが、最終的なソースアドレスを選択するため、できるだけ最新の特性情報に基づいた対応関係を設定する必要があるからである。
【００７４】
図２２は、ゲイトウェイ１Bが通信パケットの宛先アドレスとソースアドレスの対応関係のチェックする処理例のフローチャートである。端末１Aは、自己の宛先・ソースアドレス対応表格納部１４Aに基づいて、宛先アドレスとソースアドレスを付した通信パケットをゲイトウェイ１Bに送信する。ゲイトウェイ１Bは、その通信パケットを受信すると（Ｓ３１）、受信した通信パケットの宛先アドレスとソースアドレスの対応関係を、自己の宛先・ソースアドレス対応表格納部１４Bに基づいてチェックする（Ｓ３２）。ステップＳ３３において、対応関係が一致していれば、通信パケットをネットワークに送信する（Ｓ３４）。対応関係が一致せず、さらに、ステップＳ３５において、ゲイトウェイ１Bの宛先・ソースアドレス対応表格納部１４Bに別の対応関係が登録されている場合は、その別の対応関係におけるソースアドレスをリダイレクトメッセージで端末１Aに通知する。端末１Aは、そのソースアドレスに基づいて、自己の宛先・ソースアドレス対応表格納部１４Aを更新する。
【００７５】
ステップＳ３５において、ゲイトウェイ１Bの宛先・ソースアドレス対応表格納部１４Bに対応関係が登録されていない場合は、図２１に示すように、例えば、ICMP Echo メッセージを用いて、ソースアドレス選択処理を行い（Ｓ３７）、選択したソースアドレスに基づいて、自己の宛先・ソースアドレス対応表格納部１４Bを更新するとともに（Ｓ３８）、その選択されたソースアドレスをリダイレクトメッセージで端末１Aに通知する（Ｓ３６）。端末１Aは、同様に、そのソースアドレスに基づいて、自己の宛先・ソースアドレス対応表格納部１４Aを更新する。
【００７６】
図２３は、図７の構成における名前解決メッセージを利用した接続性確認のさらなる別の処理例を説明する図である。図１８では、ゲイトウェイ１Bから端末１Aへのソースアドレスを、リダイレクト（Redirect）メッセージを利用して通知したが、本処理例では、DHCP static routeメッセージを利用して通知する。
【００７７】
図２４は、DHCP Static Routeメッセージのフォーマット例を示す図である。ゲイトウェイ１Bは、DHCP Static RouteメッセージのDestination Descriptorに宛先通信装置のアドレス、Router Addressに選択したソースアドレスと同一のプレフィックスを使ったゲイトウェイ１Bのアドレスをそれぞれ格納して、端末1Aに当該メッセージを送信する。端末１Aは、DHCP Static Routeメッセージに含まれるゲイトウェイのソースアドレスとプレフィックスが同じアドレスをソースアドレスとして、宛先アドレスとの対応関係を保存する。
【００７８】
図２５は、本発明の第一の実施の形態例における通信装置（端末）の別のブロック構成例を示す図である。図２５の構成例では、図２の構成に加えて、通信断検出部１０が設けられる。通信断検出部１０は、一定時間、宛先通信端末からの通信パケットを受信しない場合、あるいは、ICMP Destination Unreachableメッセージなどのエラーメッセージを受信した場合に、宛先端末との接続性が断絶したと判断し、別のソースアドレスを選択するようにソースアドレス選択部１５に要求する。通信経路特性情報取得部１７は、特性情報を取得し直し、ソースアドレス選択部１５は、その特性情報に基づいて、別のソースアドレスに変更する。IPv4のICMPメッセージはRFC792に、IPv6のICMPv6メッセージはRFC2463に、それぞれ規定されている。
【００７９】
上述した実施の形態例において、好ましくは、ソースアドレス選択部１５は、宛先・ソースアドレス対応表格納部１４にソースアドレスとの対応関係のある宛先アドレスについて、各ネットワークプロバイダを経由した通信経路の特性情報を定期的に取得して、特性が最適となるソースアドレスを更新し、そのソースアドレスと宛先アドレスとの対応関係を宛先・ソースアドレス対応表格納部１４に登録するようにしてもよい。
【００８０】
上述の実施の形態例では、ソースアドレスを選択するための複数の方法を示した。しかし、これはそれぞれが単独で利用されることに限定されるわけではなく、それぞれを組み合わせて、ソースアドレスを選択することもできる。
【００８１】
また、本発明の実施の形態例では、異なる物理伝送メディアを有する通信装置が、それぞれの伝送メディアが接続するネットワークを使い分けるときにも適用することができる。たとえば、無線LANインターフェースを有するパケット通信対応携帯電話は、無線LAN或いは携帯電話網を経由して、インターネット等に接続することができる。このとき、無線LANインターフェースと携帯電話のパケット通信機能のどちらを使って、インターネット等に接続するかを判断するときに、本発明を利用することができる。
【００８２】
（付記１）
複数のネットワークと接続可能であり、各ネットワークとそれぞれ接続するためのソースアドレスが割り当てられた通信装置において、
送信データの宛先に関する情報を受信すると、各ネットワークを介した前記宛先までのそれぞれの通信経路の特性情報を取得する通信経路特性情報取得部と、
前記特性情報に基づいて、複数のソースアドレスの中から一つのソースアドレスを選択するソースアドレス選択部と、
前記選択されたソースアドレスに対応するネットワークに対して前記送信データを送信する送信部とを備えることを特徴とする通信装置。
【００８３】
（付記２）
付記１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の接続性に関する情報であり、
前記通信経路特性情報取得部は、各ネットワークの通信経路が前記宛先まで接続しているかどうかを確認し、
前記ソースアドレス選択部は、前記宛先と接続しているネットワークに対応するソースアドレスを選択することを特徴とする通信装置。
【００８４】
（付記３）
付記１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の遅延性に関する情報であり、
前記通信経路特性情報取得部は、各ネットワークの通信経路の遅延を測定し、
前記ソースアドレス選択部は、通信経路の遅延が最小となるネットワークに対応するソースアドレスを選択することを特徴とする通信装置。
【００８５】
（付記４）
付記１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の帯域に関する情報であり、
前記通信経路特性情報取得部は、各ネットワークの通信経路の利用可能帯域を確認し、
前記ソースアドレス選択部は、利用可能帯域が最大となるネットワークに対応するソースアドレスを選択することを特徴とする通信装置。
【００８６】
（付記５）
付記１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の優先度に関する情報であり、
前記通信経路特性情報取得部は、宛先別に選択すべきソースアドレスの優先度を記憶し、
前記ソースアドレス選択部は、前記宛先に対する最上位優先度のソースアドレスを選択することを特徴とする通信装置。
【００８７】
（付記６）
付記１において、さらに、
前記選択されたソースアドレスと前記宛先との対応関係を格納する格納部を備え、
前記通信経路特性情報取得部は、前記格納部に、前記宛先に対応するソースアドレスが格納されていない場合に、前記特性情報を取得し、
前記ソースアドレス選択部は、前記特性情報に基づいて選択したソースアドレスを、前記宛先に対応づけて前記格納部に登録することを特徴とする通信装置。
【００８８】
（付記７）
請求項６において、
前記格納部に格納された前記対応関係は、所定時間経過後消去されることを特徴とする通信装置。
【００８９】
（付記８）
付記１において、
端末と接続し、前記端末からの送信データをネットワークに送信する通信装置であって、
前記通信経路特性情報取得部は、前記端末からの要求に応じて、前記特性情報を取得し、
前記ソースアドレス選択部は、前記特性情報に基づいて選択したソースアドレスを前記端末に通知することを特徴とする通信装置。
【００９０】
（付記９）
付記１において、さらに、
前記選択されたソースアドレスに基づく前記宛先までの通信経路の通信断を検出する検出部を備え、
前記検出部が前記通信断を検出すると、前記通信経路特性情報取得部は、再度、前記特性情報を取得し、
前記ソースアドレス選択部は、前記特性情報に基づいて、選択すべきソースアドレスを変更することを特徴とする通信装置。
【００９１】
（付記１０）
付記１において、
前記通信経路特性情報取得部は、定期的に前記特性情報を取得し、
前記ソースアドレス選択部は、前記特性情報に基づいて、選択すべきソースアドレスを定期的に更新することを特徴とする通信装置。
【図面の簡単な説明】
【００９２】
【図１】従来のソースアドレス選択方法を説明する図である。
【図２】本発明の第一の実施の形態例における通信装置の構成例を示す図である。
【図３】送信パケット生成部１２の処理例を示すフローチャートである。
【図４】ソースアドレス選択部１５の処理例のフローチャートである。
【図５】通信経路特性情報取得部１７の処理例を説明する図である。
【図６】本発明の実施の第二の形態例における通信装置を説明する図である。
【図７】本実施の第二の実施の形態例における端末１Aとゲイトウェイ１Bのブロック構成を示す図である。
【図８】本発明の第二の実施の形態例における端末１Aとゲイトウェイ１Bの別のブロック構成例を示す図である。
【図９】ネットワークの接続性に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。
【図１０】ICMP Echo メッセージを利用した接続性確認のための通信経路特性情報取得部１７の処理例を説明する図である。
【図１１】ネットワークの遅延に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。
【図１２】ICMP Echoメッセージを利用した遅延測定のための通信経路特性情報取得部１７の処理例を説明する図である。
【図１３】通信経路の帯域に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。
【図１４】通信経路のポリシーに関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。
【図１５】ポリシー格納部１７９の構成例を示す図である。
【図１６】図７の構成における名前解決メッセージを利用した接続性確認の処理例を説明する図である。
【図１７】名前解決メッセージのフォーマット例を示す図である。
【図１８】図７の構成における名前解決メッセージを利用した接続性確認の別の処理例を説明する図である。
【図１９】IPv6におけるリダイレクトメッセージのフォーマット例を示す図である。
【図２０】IPv4におけるリダイレクトメッセージのフォーマット例を示す図である。
【図２１】図８の構成において、ゲイトウェイ１Bが端末１Aから通信パケットを受信した場合の処理例を示す図である。
【図２２】ゲイトウェイ１Bが通信パケットの宛先アドレスとソースアドレスの対応関係のチェックする処理例のフローチャートである。
【図２３】図７の構成における名前解決メッセージを利用した接続性確認のさらなる別の処理例を説明する図である。
【図２４】DHCP Static Routeメッセージのフォーマット例を示す図である。
【図２５】本発明の実施の第一の実施の形態例における通信装置の別のブロック構成例を示す図である。
【符号の説明】
【００９３】
１A：端末（通信装置）、１B：ゲイトウェイ（通信装置）、１０：通信断検出部、１１：送信データ受付部、１２：送信パケット生成部、１３：パケット送信部、１４：宛先・ソースアドレス対応表格納部、１５：ソースアドレス選択部、１６：ソースアドレスリスト格納部、１７：通信経路特性情報取得部、１８：パケット受信部、１９：アドレス情報要求部、２０：アドレス情報応答部
【技術分野】
【０００１】
本発明は、パケット通信を行う通信装置が複数のネットワークに接続しており、また、それぞれのネットワークからアドレスを割り当てられている場合において、通信装置が他の通信装置と適切な通信経路で通信することを可能とするためのソースアドレスを選択する通信装置に関する。
【背景技術】
【０００２】
近年、IP(Internet Protocol)技術に基づいたインターネットが全世界で急速に普及してきている。インターネットでは、ネットワークプロバイダあるいはインターネットサービスプロバイダ(ISP)と呼ばれる事業者が、IPアドレスあるいは、IPアドレスの上位ビット部のプレフィックスをユーザに割り当て、ユーザの通信装置（例えば、パーソナルコンピュータ）は、そのIPアドレスあるいはプレフィックスを含むIPアドレスを通信装置のソースアドレスとしてインターネットにアクセスする。
【０００３】
各事業者がそれぞれ独自のサービスを提供していたり、企業内ネットワークにアクセスしたりするために、ユーザは複数のネットワークからIPアドレス(プレフィックス)を割り当てられることが多くなってきている。
【０００４】
このように、複数のIPアドレスが割り当てられている場合は、このうちの一つのIPアドレスをソースアドレスと選択し、そのIPアドレスを用いてネットワークにアクセスする必要がある。ソースアドレス選択方法として、インターネットの仕様などの標準化活動を行っている組織IETF(The Internet Engineering Task Force)では、次の方法を標準化している。すなわち、従来のソースアドレス選択方法は、宛先アドレスとの最大プレフィックス一致に基づいて、ソースアドレスを選択する方法である。
【０００５】
図１は、従来のソースアドレス選択方法を説明する図である。図１において、複数のIPアドレスを有する通信装置Xが、宛先通信装置Yと通信するとき、通信装置Xは、最大プレフィクス長一致に基づいて、IPアドレスを選択する。具体的には、通信装置Xが、二つのIPアドレス、2001:0:10::1と2001:100:10::1を有し、宛先通信装置YのIPアドレスが、2001:100:20::1である場合、通信装置Ｘは、宛先通信装置YのIPアドレスとのプレフィクスの一致度がより高いIPアドレス2001:100:10::1（ネットワークプロバイダBから割り当てられたIPアドレス）を選択する。
【０００６】
しかしながら、プレフィックス長の一致が長いほど、ネットワーク的に近いとは限らない。例えば、宛先通信装置Yへの往路パスに障害があった場合は通信不能となる。障害がなく、正常に宛先通信装置Yと通信できたとしても、遅延などの性能は、ネットワークプロバイダAを経由した方が良い場合も考えられる。また、宛先通信装置Yからのリターンパスに障害があった場合も通信不能となる。また、ネットワークプロバイダ事業者が独自のサービスを提供するための閉域網のアドレスをソースアドレスとしてインターネットにアクセスした場合、インターネットと接続関係の無い閉域網のためリターンパスが存在しないという致命的な問題が生じる。
【０００７】
また、"Site Exit Issue"の問題も存在することが指摘されている。"Site Exit Issue"は、"address spoofing"を防止するために、プロバイダが割り当てたアドレス／プレフィックス以外のソースアドレスを有するパケットを廃棄する機能であるIngress Filteringにより、引き起こされる。すなわち、Hostが選択したソースアドレスを割り当てたプロバイダ以外のプロバイダにルーティングされると、Ingress Filteringにより廃棄され、全く通信できなくなってしまう。IETFでは、この"Site Exit Issue"の問題を解決するために、以下の４つの方法を提案しているが、それぞれに課題が存在する。
【０００８】
(1) Ingress Filteringのルール緩和
【０００９】
Ingress Filteringによるaddress spoofingに対する効果が減少し、セキュリテの脆弱性を増す。
【００１０】
(2) ソースアドレスルーティング
【００１１】
通信装置がある程度経路を制御できる点に利点があるが、その経路が最適か接続性は 確保されているかなどの保証がない。
【００１２】
(3) 端末によるソースアドレス選択(Source Address Discovery、 Exit Router Discovery)
・SAD： Path MTU-Discoveryのように、ソースアドレスを通信可能になるまでの順 次変えていくため、遅延が大きく、また、経路が最適とは限らない。
【００１３】
・ERD： Exit Routerまでのトンネル設定が必要であり、通信装置の負荷が増大する。
【００１４】
(4) NAT
【００１５】
End-to-Endで直接通信可能なIPv6の場合、その利点を打ち消してしまう。
【００１６】
このように、標準化技術では、経路の最適化(例：RTTが最小)とSite Exit Issueを共に解決することができなかった。
【００１７】
一方、上述したような標準化技術の課題に対処するために、下記特許文献１では、複数のISPと接続したマルチホーム環境で、接続性が確認されたISPにより割り当てられたアドレスプレフィックスをソースアドレスとして、ルータでソースアドレスルーティングすることで、通信できるようにすることが提案されている。特許文献１では、IPv6のND(Neighbor Discovery)メッセージ等により、それぞれのISPとの接続性確認をすると共に、ソースアドレスルーティングを行うことが記述されている。
【００１８】
しかし、特許文献１の発明によれば、ISPとの接続性しか確認していないため、宛先ドメイン／ホストの接続性を保証できない。また、複数のISPとの接続性が確認されているときに、どのISPのプレフィックスを利用すべきか具体化されていない。
【００１９】
一方、特許文献２では、複数のルータからアドレスプレフィックスを割り当てられる環境で、割り当てられたアドレスプレフィックス毎に仮想インターフェースを生成し、アドレスプレフィックスを利用して生成したアドレスを付与する。そして、ソースアドレス選択は、宛先アドレスとの最長プレフィックス一致に基づいて行う。さらに、アドレスプレフィックスの配布時に、プレフィックスと対応付けたラベルを配布することでパケット処理効率を上げることが記述されている。
【００２０】
しかし、ソースアドレス選択方法自体は、上述の標準化技術の範囲内であって、最適な経路による通信、Site Exit Issueの解決に課題が残る。
【特許文献１】特開2003-298635号
【特許文献２】特開2003-324461号
【発明の開示】
【発明が解決しようとする課題】
【００２１】
このように、End-to-Endの接続性が保証され、かつ、性能が最適となる通信路を経由するようなソースアドレス選択方法を提供することが望まれている。
【００２２】
従って、本発明の目的は、複数のネットワークプロバイダにより割り当てられたアドレスから一のアドレスを選択し、それをソースアドレスとして通信する通信装置において、宛先通信装置との双方向の接続性が確認され、かつ、より性能の良い通信経路を経由するためのソースアドレスを選択する通信装置を提供することにある。
【課題を解決するための手段】
【００２３】
上記目的を達成するための本発明の通信装置の構成は、複数のネットワークと接続可能であり、各ネットワークとそれぞれ接続するためのソースアドレスが割り当てられた通信装置において、送信データの宛先に関する情報を受信すると、各ネットワークを介した前記宛先までのそれぞれの通信経路の特性情報を取得する通信経路特性情報取得部と、
前記特性情報に基づいて、複数のソースアドレスの中から一つのソースアドレスを選択するソースアドレス選択部と、前記選択されたソースアドレスに対応するネットワークに対して前記送信データを送信する送信部とを備えることを特徴とする。
【００２４】
例えば、前記特性情報は、前記宛先までのそれぞれの通信経路の接続性に関する情報であり、この場合、前記通信経路特性情報取得部は、各ネットワークの通信経路が前記宛先まで接続しているかどうかを確認し、前記ソースアドレス選択部は、前記宛先と接続しているネットワークに対応するソースアドレスを選択する。
【００２５】
また、例えば、前記特性情報は、前記宛先までのそれぞれの通信経路の遅延性に関する情報であり、この場合、前記通信経路特性情報取得部は、各ネットワークの通信経路の遅延を測定し、前記ソースアドレス選択部は、通信経路の遅延が最小となるネットワークに対応するソースアドレスを選択する。
【００２６】
また、本発明の通信装置は、さらに、前記選択されたソースアドレスと前記宛先との対応関係を格納する格納部を備えていてもよく、この場合、前記通信経路特性情報取得部は、前記格納部に、前記宛先に対応するソースアドレスが格納されていない場合に、前記特性情報を取得し、前記ソースアドレス選択部は、前記特性情報に基づいて選択したソースアドレスを、前記宛先に対応づけて前記格納部に登録する。そして、好ましくは、前記格納部に格納された前記対応関係は、所定時間経過後消去される。
【発明の効果】
【００２７】
本発明の通信装置によれば、複数のソースアドレスが割り当てられた通信装置において、複数のネットワークのうち最適な通信経路を有するネットワークに対応するソースアドレスを選択して、通信を行うことができる。
【発明を実施するための最良の形態】
【００２８】
以下、図面を参照して本発明の実施の形態について説明する。しかしながら、かかる実施の形態例が、本発明の技術的範囲を限定するものではない。
【００２９】
図２は、本発明の第一の実施の形態例における通信装置を説明する図であって、第一の実施の形態例におけるブロック構成例を示す図である。第一の構成例の通信装置は、例えばパーソナルコンピュータのような端末１Aである。端末１A（通信装置）は、各ネットワークプロバイダからの割り当てられたIPアドレス（以下、単にアドレスと称す）をソースアドレスリスト格納部１６に記憶する。ネットワークプロバイダからのアドレス割り当て方法は、主に次の３つが考えられる。（本発明では下記の3方法に限定するものではない）
IPCP (Internet Protocol Control Protocol)
DHCP (Dynamic Host Configuration Protocol)
RA (Router Advertisement)
一般に、アドレスはネットワークアドレス部(プレフィックスという)とホストアドレス部から構成される。ネットワークプロバイダは、プレフィックスとホストアドレス部を含むアドレスを割り当てることもあるし、プレフィックスのみを割り当て、ホストアドレス部はプレフィックスを割り当てられた通信装置がMACアドレスなどから自動的に生成し、アドレスを合成することもある。ソースアドレスリスト格納部１６はこうして得られたアドレスを記憶する。複数のネットワークプロバイダそれぞれからアドレスを割り当てられた場合は、ソースアドレス格納部１６は、複数のアドレスを記憶する。
【００３０】
送信データ受付部１１は、アプリケーションから送信すべきデータを受信すると、そのデータと宛先情報を送信パケット生成部１２に送る。ここで、宛先情報としては、宛先通信装置のアドレスであったり、ホスト名であったりする。
【００３１】
送信パケット生成部１２は、送信データをパケット化し、送信データにソースアドレス及び宛先アドレスを付した送信パケットを生成する。
【００３２】
図３は、送信パケット生成部１２の処理例を示すフローチャートである。送信パケット生成部１２は、送信データ受付部１１より送信データ、宛先情報を受信すると（S１１）、宛先情報がアドレスであるかどうか判定する（S１２）。宛先情報がアドレスであれば、宛先・ソースアドレス対応表格納部１４を検索し、宛先アドレスに対応するソースアドレスが登録されているか問い合わせ（S１３）、ソースアドレスが登録されていれば（S１４）、そのアドレスを利用して送信パケットを生成し、パケット送信部１３に送る（S１９）。ソースアドレスが得られなかった場合（Ｓ１４）や宛先情報がホスト名だった場合（この場合、ソースアドレスも得られていない）（Ｓ１２）、宛先情報をソースアドレス選択部１５に送る（Ｓ１５、Ｓ１７）。そして、後述するソースアドレス選択部１５の処理により、ソースアドレス（Ｓ１６）又はソースアドレスと宛先アドレス（Ｓ１８）の応答を受信すると、そのアドレスを利用して送信パケットを生成し、パケット送信部１３に送る。
【００３３】
図２に戻って、宛先・ソースアドレス対応表格納部１４は、宛先アドレスとソースアドレスの対応関係を記憶すると共に、一定時間、対応関係の問い合わせがない場合は、その登録の削除を行う。
【００３４】
ソースアドレス選択部１５は、本発明に特徴的な要素であってソースアドレス格納部１６に格納されている複数のソースアドレスの中から、宛先通信装置との通信に最適なソースアドレスを選択する。
【００３５】
図４は、ソースアドレス選択部１５の処理例のフローチャートである。ソースアドレス選択部１５は、送信パケット生成部１２から、宛先情報を受けると（Ｓ２１）、ソースアドレスリスト格納部１６に格納されている複数のソースアドレスを取得し（Ｓ２２）、宛先情報とソースアドレスを通信経路特性情報取得部１７に送り（Ｓ２３）、通信経路特性情報取得部１７から情報を待つ。そして、通信経路特性情報取得部１７より、各ソースアドレスを利用した場合の特性情報をそれぞれ受信して（Ｓ２４）、その性能情報に基づいて、最良の性能を得られるソースアドレスを選択し、それを送信パケット生成部１２に応答するとともに、宛先・ソースアドレス対応表格納部１４に登録する（Ｓ２５）。
【００３６】
なお、送信パケット生成部１２から受信した宛先情報が宛先アドレスではなく、宛先ホスト名の場合は、通信経路特性情報取得部１７は、特性情報と一緒に宛先アドレスをソースアドレス選択部１５に応答し、ソースアドレス選択部１５は、ソースアドレスと共に宛先アドレスを送信パケット生成部１２に応答する。また、ソースアドレス選択部１５は、定期的に性能情報の更新を通信経路特性情報取得部１７に要求し、その結果を宛先・ソースアドレス対応表格納部１４に反映させてもよい。
【００３７】
通信経路特性情報取得部１７は、通信装置と相手先通信装置との間の通信経路の特性情報を取得する。特性情報は、通信経路の接続性（通信障害、通信不能状態にないかどうか）や、接続可能状態における遅延性（通信速度）などの情報である。
【００３８】
図５は、第一の実施の形態例における通信経路特性情報取得部１７の処理例を説明する図である。図５の処理例は、通信装置X（端末１A）と宛先通信装置Yとの間の接続性を確認するための処理であって、宛先情報がホスト名である場合に、宛先アドレスを取得する処理を利用して、接続性に関する特性情報を取得する。通信経路特性情報取得部１７（通信装置X）は、複数のソースアドレスをソースアドレス格納部１６より取得している。宛先情報がホスト名の場合、通信経路特性情報取得部１７は、宛先アドレスを取得するために、各ネットワークプロバイダの名前解決サーバA、Bのアドレスを宛先アドレスとし、ソースアドレスは各ネットワークプロバイダから割り当てられたアドレスを使用した名前解決要求メッセージを生成し、パケット送信部１３に送る。パケット送信部１３は、各名前解決サーバA、Bに名前解決要求メッセージを送信する。図５の場合、名前解決サーバAは、宛先通信装置Yが属する名前解決サーバCから宛先アドレスを含む名前解決応答を受信し、通信装置Xのパケット受信部１８は、それを受信する。一方、名前解決サーバBは、名前解決サーバCとの通信経路に障害があるため、名前解決応答を受信しない。この場合、名前解決サーバBは、名前解決エラーメッセージを、通信装置Xに送信する。
【００３９】
通信経路特性情報取得部１７は、パケット受信部１８より名前解決サーバAからの名前解決応答を受信して、宛先アドレスを取得する。そして、通信経路特性情報取得部１７は、宛先アドレスを取得するとともに、各ネットワークの宛先通信装置との接続性に関する情報も取得することができる。すなわち、名前解決サーバAを経由する通信経路は、宛先通信装置のネットワークと接続しているが、名前解決サーバBを経由する通信経路は宛先通信装置のネットワークと接続していない。
【００４０】
一般には、各ネットワークプロバイダ経由の名前解決応答で得られる宛先アドレスは同一であるが、サーバ負荷分散が施されている場合、異なるアドレスが得られることもある。この場合、それぞれの宛先アドレスにアクセスするときは、そのアドレスを取得したときに経由したネットワークプロバイダに割り当てられたアドレスをソースアドレスとして利用する。
【００４１】
このように、通信経路特性情報取得部１７は、名前解決のためのメッセージを宛先通信装置の属するネットワークとの接続性の確認に用いることができる。すなわち、名前解決応答が得られないネットワークプロバイダは宛先通信装置の属するネットワークとの接続性がないと判断でき、一方、名前解決応答が得られるネットワークプロバイダは接続性が存在すると判断することができる。通信経路特性情報取得部１７は、この旨、ソースアドレス選択部１５に通知する。特性情報の取得方法の具体例について、さらに後述する。
【００４２】
こうして、パケット送信部１３は、送信パケットのソースアドレスに基づき、そのソースアドレスを割り当てたネットワークプロバイダのネットワークに対してパケットを転送する。
【００４３】
図６は、本発明の第二の実施の形態例における通信装置を説明する図である。第二の実施の形態例における通信装置は、端末１Aと接続するゲイトウェイ１Bである。ゲイトウェイ１Bには、複数の端末１Aが接続可能であって、複数の端末１Aが、ゲイトウェイ１Bを介して、ネットワークに接続することができる。
【００４４】
図７は、本実施の第二の実施の形態例における端末１Aとゲイトウェイ（通信装置）１Bのブロック構成を示す図である。本第二の実施の形態例では、図２の端末１Aにおけるソースアドレス選択機能を、ゲイトウェイ１Bが実現する。
【００４５】
ゲイトウェイ１Bは、各ネットワークプロバイダより、プレフィックスをそれぞれ割り当てられ、その情報をソースアドレスリスト格納部１６Bに記憶するとともに、各ネットワークプロバイダから割り当てられたプレフィックスを用いたアドレスを端末１Aに割り当てる。端末１Aは、ゲイトウェイ１Bにより割り当てられたアドレスをソースアドレスリスト格納部１６Aに記憶する。
【００４６】
端末１Aは、送信データ受付部１１、送信パケット生成部１２、パケット送信部１３A、宛先・ソースアドレス対応表格納部１４、ソースアドレス格納部１７A、パケット受信部１８A、アドレス情報要求部１９を備える。なお、パケット送信部１３A及びパケット受信部１８Aは、それぞれ、ゲイトウェイ１Bに対するパケットの送受信を行う。
【００４７】
ゲイトウェイ１Bは、パケット送信手段１３B、ソースアドレス選択部１５、ソースアドレスリスト格納部１６B、通信経路特性情報取得部１７、パケット受信手段１８B、アドレス情報応答手段２０を備える。パケット送信手段１３B及びパケット受信手段１８Bは、ネットワークに対するパケットの送受信と、端末１Aに対するパケットの送受信を行う。
【００４８】
また、図２の構成では、送信パケット生成部１２がソースアドレス選択部１５に対して直接宛先情報を送り、ソースアドレス選択部１５からアドレスを直接取得するが、図７の構成では、端末１Aのアドレス情報要求部１９とゲイトウェイ１Bのアドレス情報応答部２０を介して、宛先情報及びアドレスの送受信が行われる。具体的には、端末１Aのアドレス情報要求部１９が、ゲイトウェイ１Bのアドレス情報応答部２０に対して宛先情報を含むアドレス要求を送り、アドレス情報応答部２０は、そのアドレス要求をソースアドレス選択部１５に転送する。そして、アドレス情報応答部２０は、ソースアドレス選択部１５により選択されたアドレスを、アドレス要求部１９に通知する。
【００４９】
図８は、本発明の第二の実施の形態例における端末１Aとゲイトウェイ１Bの別のブロック構成例を示す図である。図８では、端末１Aとゲイトウェイ１Bの両方が、それぞれ宛先・ソースアドレス対応表格納部１４A、１４Bを有している。ゲイトウェイ１Bに複数の端末１Aが接続している場合、宛先・ソースアドレス対応表格納部１４Bをゲイトウェイ１Bに設けることで、複数の端末１Aそれぞれからのアドレス要求に対応することができる。
【００５０】
以下、通信経路特性情報取得部１７における特性情報の取得に関するさまざまな形態例について説明する。
【００５１】
図９は、ネットワークの接続性に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。通信経路特性情報取得部１７は、接続性確認パケット生成部１７１と接続性確認パケット受信部１７２とを備える。接続性確認のために名前解決メッセージが利用される場合、接続性確認パケット生成部１７１は、ソースアドレス選択部１５からの指示に従って、上述の名前解決要求（図５参照）を生成し、接続性確認パケット受信部１７２は、名前解決応答又は名前解決エラーメッセージを受信し、ソースアドレス選択部１５に通知する。
【００５２】
接続性確認は、名前解決メッセージ以外にも、例えば、ICMP Echo メッセージ、SIPメッセージ、TCPのセッション確立メッセージなどを利用してもよい。
【００５３】
図１０は、ICMP Echo メッセージを利用した接続性確認のための通信経路特性情報取得部１７の処理例を説明する図である。ICMP Echo メッセージを利用する場合、通信装置X（端末１A又はゲイトウェイ１B）の通信経路特性情報取得部１７（接続性確認パケット生成部１７１）は、宛先アドレスを宛先通信装置Yのアドレスとして、ソースアドレス毎にICMP Echo メッセージを生成し、ICMP Echo メッセージは、それぞれのネットワークを経由して宛先通信装置Yに転送される（名前解決メッセージを利用する場合は、名前解決要求は、宛先通信装置Yまでは転送されず、その手前の宛先通信装置Yの属するネットワークの名前解決サーバが応答処理を行う）。宛先通信装置Yは、正常に受信したICMP Echo メッセージに対応するICMP Echo Replyメッセージを返送する。通信装置Xの通信経路特性情報取得部１７（接続性確認パケット受信部１７２）は、ICMP Echo Replyメッセージを受信すると、ICMP Echo メッセージのソースアドレスにおける接続性が確認された旨をソースアドレス選択部１５に通知する。一方、ICMP Echo Replyメッセージの受信に失敗した場合は、ICMP Echo メッセージのソースアドレスでは接続性が確認されなかったことをソースアドレス選択部１５に通知する。
【００５４】
なお、同一のICMP Echoメッセージを複数送信して、接続性を確認することもできる。この場合、例えば、ICMP Echo メッセージを５メッセージずつ送信したとすると、あるソースアドレスに対するICMP Echo Replyメッセージは５メッセージ受信できたのに対して、別のソースアドレスに対するICMP Echo Replyメッセージは３メッセージしか受信できなかった場合、ソースアドレス選択部１５は前者のソースアドレスを使用することを選択することができる。後者のソースアドレスを使った場合、ネットワークの輻輳のため、５メッセージのうち２メッセージが往復の経路上のどこかで廃棄されたものと推測されるからである。
【００５５】
SIPメッセージを利用する場合、接続性確認パケット生成部１７１は、SIP Inviteメッセージを生成し、宛先通信装置あるいは仲介するSIPプロキシサーバに転送する。直接あるいはSIPプロキシサーバを介して、SIP Inviteメッセージを受信した宛先通信装置は、通信の開始に問題がなければ、SIP 200 OKメッセージを返信する。接続性確認パケット受信部１７２は、ICMP Echo Replyと同様に、SIP 200 OKメッセージの受信結果をソースアドレス選択部１５に通知して、ソースアドレス選択部１５は、受信結果に基づいて、利用するソースアドレスを選択する。
【００５６】
また、ICMP EchoやSIPメッセージなどのように、宛先通信装置からの応答を受けるのではなく、ネットワーク管理サーバ（例えば、名前解決メッセージを利用する場合の名前解決サーバ）に正常性を確認することもある。
【００５７】
図１１は、ネットワークの遅延に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。通信経路特性情報取得部１７は、遅延測定パケット生成部１７３と遅延測定応答パケット受信部１７４と遅延計測部１７５とを備える。遅延測定には、名前解決メッセージ、ICMP Echoメッセージ、SIPメッセージ、TCPのセッション確立メッセージなどが利用される。
【００５８】
図１２は、ICMP Echoメッセージを利用した遅延測定のための通信経路特性情報取得部１７の処理例を説明する図である。通信装置Xの通信経路特性情報取得部１７（遅延測定パケット生成部１７３）は、遅延測定パケットとして、ソースアドレス毎にICMP Echoメッセージを利用した遅延測定パケットを生成し、送信するとともに、遅延計測部１７５に対して、タイマーのセットを行う。そして、遅延測定応答パケット受信部１７４が遅延測定パケットに対応する応答パケット(ICMP Echo Replyメッセージ)を受信すると、遅延計測部１７５のタイマー値を、ソースアドレスとともに、ソースアドレス選択部１５に通知する。所定時間応答がない場合は、ソースアドレスとともに、その旨通知する。ソースアドレス選択部１５は、最短の遅延を実現するソースアドレスを選択する。なお、遅延測定は、一回だけでなく、複数回行い、その平均値をソースアドレス選択部１５に通知することが好ましい。
【００５９】
図１３は、通信経路の帯域に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。通信経路特性情報取得部１７は、帯域予約パケット生成部１７６と帯域予約応答パケット受信部１７７とを備える。帯域に関しては、帯域予約のためのリソース予約プロトコル（RSVP）やSIPメッセージなどのメッセージが利用される。ネットワーク管理サーバに対するメッセージが利用されてもよい。
【００６０】
帯域予約パケット生成部１７６は、所定のメッセージを利用して、利用を希望する帯域を記載した帯域予約要求パケットをソースアドレス毎に生成して送信する。帯域予約応答パケット受信部１７７は、帯域予約応答パケットを受信し、応答パケット内に含まれる予約可能な帯域情報を、ソースアドレスとともにソースアドレス選択部１５に通知する。そして、ソースアドレス選択部１５は、最も帯域の太い経路を実現するソースアドレスを選択する。
【００６１】
図１４は、通信経路のポリシーに関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。通信経路特性情報取得部１７は、ポリシー検索部１７８とポリシー格納部１７９とを備える。ポリシーは、宛先アドレスと接続するために利用するネットワークの優先度である。ポリシー格納部１７９の登録内容は、ネットワーク管理者による設定や管理サーバからのダウンロードにより構築することができる。また、ポリシー格納部で優先度を解決できない場合、ポリシー検索部１７９は、ネットワーク管理サーバなどに問い合わせることもできる。設定する優先度については、ネットワーク管理者の裁量によるものであり、本発明では特に規定しないが、通信コストなどを基準に優先度を決めることもできる。
【００６２】
ポリシー検索部１７８は、宛先情報を受信すると、宛先情報をキーとしてポリシー格納部１７９を検索し、接続するネットワークの優先度を取得する。そして、優先度の情報をソースアドレス選択部１５に通知する。ソースアドレス選択部１５では、取得された優先度のうち、最高優先度を有するネットワークより割り当てられたアドレスをソースアドレスとして選択する。好ましくは、上述の接続性確認をあわせて行い、接続性が確認されたネットワークの中から最高優先度のネットワークを選択してもよい。
【００６３】
図１５に、ポリシー格納部１７９の構成例を示す図である。検索キーとしての宛先情報は、例えば、ホスト名(いわゆるFQDN: Fully Qualified Domain Name)あるいは、アドレス(プレフィックス)である。そして、各優先度におけるネットワーク識別子あるいはネットワークから割り当てられたプレフィックスを記憶する。
【００６４】
図１６は、図７の構成（第二の実施の形態例）における名前解決メッセージを利用した接続性確認の処理例を説明する図である。図１６において、まず、端末１A側（例えば、送信パケット生成部１２）が名前解決要求をゲイトウェイ１Bに送ると、ゲイトウェイ１B（通信装置）の通信経路特性情報取得部１７は、その名前解決要求を各ネットワークの名前解決サーバに送り、名前解決応答を受信する。そして、ソースアドレス選択部１５により選択されたソースアドレスを、受信した名前解決応答を利用して選択されたソースアドレスを端末１Aに通知する。図７の構成例においても、接続性の確認は、名前解決メッセージに限らず、ICMP Echoメッセージなどの他のメッセージを利用してもよい。
【００６５】
図１７は、名前解決メッセージのフォーマット例を示す図である。名前解決要求メッセージでは、図のQuestionにホスト名が含まれる。一方、名前解決応答メッセージでは、Answerにホストのアドレス情報、Authorityに名前解決サーバ名、Additionalに、名前解決サーバ名のアドレスがそれぞれ含まれる。ゲイトウェイ１Bが利用するソースアドレスを選択した後、端末１Aに名前解決応答メッセージを送信するときに、Authorityにはソースアドレスを割り当てたネットワークプロバイダの名前解決サーバ名、Additionalには、その名前解決サーバのアドレスを含める。名前解決応答メッセージを受信した端末１Aは、名前解決サーバのアドレスと最大プレフィックス一致するアドレスをソースアドレスとして利用するように判断する。
【００６６】
なお、上述の例では、既存の名前解決メッセージのフィールドを用いて、利用するソースアドレスを選択するための情報(名前解決サーバのアドレス)を端末１Aに通知するが、独自のフィールドを定義して、ソースアドレス(プレフィックス)を通知することもできる。
【００６７】
また、名前解決サーバのメッセージ内容ではなく、メッセージを転送するためのパケットヘッダに付与されるアドレスを用いて、端末１Aが利用するソースアドレスを通知することもできる。すなわち、ゲイトウェイ１Bから端末１Aに送信する名前解決メッセージのソースアドレスとして、選択されたソースアドレスと同じプレフィックスを有するゲイトウェイ１Bのアドレスを利用する。本メッセージを受信した端末１Aは、本メッセージのソースアドレスと最大プレフィックス一致するアドレスをソースアドレスとして利用するように判断する。
【００６８】
図１８は、図７の構成における名前解決メッセージを利用した接続性確認の別の処理例を説明する図である。図１８では、ゲイトウェイ１B（通信装置）から端末１Aへのソースアドレスを、名前解決応答に含めて通知せず、名前解決応答とは異なるリダイレクト（Redirect）メッセージを利用して通知する。なお、図１８では、リダイレクトメッセージの送信タイミングを名前解決応答メッセージ後としているが、端末１Aから宛先通信装置への通信パケットをゲイトウェイ１Bが受信した後にリダイレクトメッセージを送信するようにしてもよい。
【００６９】
図１９は、IPv6におけるリダイレクトメッセージのフォーマット例を示す図である。メッセージ中のTarget Addressには、選択したソースアドレスと同一のプレフィックスを使ったゲイトウェイ１Bのアドレス、Destination Addressには、宛先通信装置のアドレスが含められる。
【００７０】
端末１Aは、リダイレクトメッセージに含まれるゲイトウェイ１０Aのソースアドレスとプレフィックスが同じアドレスをソースアドレスとして、宛先アドレスとの対応関係を保存する。
【００７１】
図２０は、IPv4におけるリダイレクトメッセージのフォーマット例を示す図である。メッセージ中のGateway Internet Addressには、選択したソースアドレスと同一のプレフィックスを使ったゲイトウェイ１Bのアドレス、Internet Header + 65 bits of Original Data Datagramには、宛先通信装置のアドレスが含められる。
【００７２】
図２１は、図８の構成例において、ゲイトウェイ１Bが端末１Aから通信パケットを受信した場合の処理例を示す図である。具体的には、ゲイトウェイ１B（通信装置）が通信パケットの宛先アドレスとソースアドレスの対応関係のチェックし、ゲイトウェイ１Bで、通信パケットの宛先アドレスとソースアドレスの対応関係の正当性が確認できなかったため、ソースアドレスの選択を行い、適切なソースアドレスをリダイレクトメッセージにより、端末１Aに通知する例を示している。
【００７３】
図８の構成では、端末１Aとゲイトウェイ１Bの両方が、それぞれ宛先・ソースアドレス対応表格納部１４A、１４Bを有しているが、両者の内容が一致しない場合があり得る。具体的には、宛先・ソースアドレス対応表の各宛先・ソースアドレスの対応関係は、ソースアドレス選択部１５により選択されてから所定時間経過後消去される。ネットワークの特性（接続性、遅延性、帯域など）は、リアルタイムで変化しているため、一定時間経過後は、当該対応関係が最適でなくなってしまう可能性があるからである。消去された後に、再度、同じ宛先アドレスへの接続要求があった場合は、再度特性情報を取得し直して、最適なソースアドレスが選択され、その対応関係が宛先・ソースアドレス対応表格納部１４に格納される。この際、宛先・ソースアドレスの対応関係を保持する時間に関し、ゲイトウェイ１Bの方が端末１Aより短く設定される場合がある。ゲイトウェイ１Bが、最終的なソースアドレスを選択するため、できるだけ最新の特性情報に基づいた対応関係を設定する必要があるからである。
【００７４】
図２２は、ゲイトウェイ１Bが通信パケットの宛先アドレスとソースアドレスの対応関係のチェックする処理例のフローチャートである。端末１Aは、自己の宛先・ソースアドレス対応表格納部１４Aに基づいて、宛先アドレスとソースアドレスを付した通信パケットをゲイトウェイ１Bに送信する。ゲイトウェイ１Bは、その通信パケットを受信すると（Ｓ３１）、受信した通信パケットの宛先アドレスとソースアドレスの対応関係を、自己の宛先・ソースアドレス対応表格納部１４Bに基づいてチェックする（Ｓ３２）。ステップＳ３３において、対応関係が一致していれば、通信パケットをネットワークに送信する（Ｓ３４）。対応関係が一致せず、さらに、ステップＳ３５において、ゲイトウェイ１Bの宛先・ソースアドレス対応表格納部１４Bに別の対応関係が登録されている場合は、その別の対応関係におけるソースアドレスをリダイレクトメッセージで端末１Aに通知する。端末１Aは、そのソースアドレスに基づいて、自己の宛先・ソースアドレス対応表格納部１４Aを更新する。
【００７５】
ステップＳ３５において、ゲイトウェイ１Bの宛先・ソースアドレス対応表格納部１４Bに対応関係が登録されていない場合は、図２１に示すように、例えば、ICMP Echo メッセージを用いて、ソースアドレス選択処理を行い（Ｓ３７）、選択したソースアドレスに基づいて、自己の宛先・ソースアドレス対応表格納部１４Bを更新するとともに（Ｓ３８）、その選択されたソースアドレスをリダイレクトメッセージで端末１Aに通知する（Ｓ３６）。端末１Aは、同様に、そのソースアドレスに基づいて、自己の宛先・ソースアドレス対応表格納部１４Aを更新する。
【００７６】
図２３は、図７の構成における名前解決メッセージを利用した接続性確認のさらなる別の処理例を説明する図である。図１８では、ゲイトウェイ１Bから端末１Aへのソースアドレスを、リダイレクト（Redirect）メッセージを利用して通知したが、本処理例では、DHCP static routeメッセージを利用して通知する。
【００７７】
図２４は、DHCP Static Routeメッセージのフォーマット例を示す図である。ゲイトウェイ１Bは、DHCP Static RouteメッセージのDestination Descriptorに宛先通信装置のアドレス、Router Addressに選択したソースアドレスと同一のプレフィックスを使ったゲイトウェイ１Bのアドレスをそれぞれ格納して、端末1Aに当該メッセージを送信する。端末１Aは、DHCP Static Routeメッセージに含まれるゲイトウェイのソースアドレスとプレフィックスが同じアドレスをソースアドレスとして、宛先アドレスとの対応関係を保存する。
【００７８】
図２５は、本発明の第一の実施の形態例における通信装置（端末）の別のブロック構成例を示す図である。図２５の構成例では、図２の構成に加えて、通信断検出部１０が設けられる。通信断検出部１０は、一定時間、宛先通信端末からの通信パケットを受信しない場合、あるいは、ICMP Destination Unreachableメッセージなどのエラーメッセージを受信した場合に、宛先端末との接続性が断絶したと判断し、別のソースアドレスを選択するようにソースアドレス選択部１５に要求する。通信経路特性情報取得部１７は、特性情報を取得し直し、ソースアドレス選択部１５は、その特性情報に基づいて、別のソースアドレスに変更する。IPv4のICMPメッセージはRFC792に、IPv6のICMPv6メッセージはRFC2463に、それぞれ規定されている。
【００７９】
上述した実施の形態例において、好ましくは、ソースアドレス選択部１５は、宛先・ソースアドレス対応表格納部１４にソースアドレスとの対応関係のある宛先アドレスについて、各ネットワークプロバイダを経由した通信経路の特性情報を定期的に取得して、特性が最適となるソースアドレスを更新し、そのソースアドレスと宛先アドレスとの対応関係を宛先・ソースアドレス対応表格納部１４に登録するようにしてもよい。
【００８０】
上述の実施の形態例では、ソースアドレスを選択するための複数の方法を示した。しかし、これはそれぞれが単独で利用されることに限定されるわけではなく、それぞれを組み合わせて、ソースアドレスを選択することもできる。
【００８１】
また、本発明の実施の形態例では、異なる物理伝送メディアを有する通信装置が、それぞれの伝送メディアが接続するネットワークを使い分けるときにも適用することができる。たとえば、無線LANインターフェースを有するパケット通信対応携帯電話は、無線LAN或いは携帯電話網を経由して、インターネット等に接続することができる。このとき、無線LANインターフェースと携帯電話のパケット通信機能のどちらを使って、インターネット等に接続するかを判断するときに、本発明を利用することができる。
【００８２】
（付記１）
複数のネットワークと接続可能であり、各ネットワークとそれぞれ接続するためのソースアドレスが割り当てられた通信装置において、
送信データの宛先に関する情報を受信すると、各ネットワークを介した前記宛先までのそれぞれの通信経路の特性情報を取得する通信経路特性情報取得部と、
前記特性情報に基づいて、複数のソースアドレスの中から一つのソースアドレスを選択するソースアドレス選択部と、
前記選択されたソースアドレスに対応するネットワークに対して前記送信データを送信する送信部とを備えることを特徴とする通信装置。
【００８３】
（付記２）
付記１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の接続性に関する情報であり、
前記通信経路特性情報取得部は、各ネットワークの通信経路が前記宛先まで接続しているかどうかを確認し、
前記ソースアドレス選択部は、前記宛先と接続しているネットワークに対応するソースアドレスを選択することを特徴とする通信装置。
【００８４】
（付記３）
付記１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の遅延性に関する情報であり、
前記通信経路特性情報取得部は、各ネットワークの通信経路の遅延を測定し、
前記ソースアドレス選択部は、通信経路の遅延が最小となるネットワークに対応するソースアドレスを選択することを特徴とする通信装置。
【００８５】
（付記４）
付記１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の帯域に関する情報であり、
前記通信経路特性情報取得部は、各ネットワークの通信経路の利用可能帯域を確認し、
前記ソースアドレス選択部は、利用可能帯域が最大となるネットワークに対応するソースアドレスを選択することを特徴とする通信装置。
【００８６】
（付記５）
付記１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の優先度に関する情報であり、
前記通信経路特性情報取得部は、宛先別に選択すべきソースアドレスの優先度を記憶し、
前記ソースアドレス選択部は、前記宛先に対する最上位優先度のソースアドレスを選択することを特徴とする通信装置。
【００８７】
（付記６）
付記１において、さらに、
前記選択されたソースアドレスと前記宛先との対応関係を格納する格納部を備え、
前記通信経路特性情報取得部は、前記格納部に、前記宛先に対応するソースアドレスが格納されていない場合に、前記特性情報を取得し、
前記ソースアドレス選択部は、前記特性情報に基づいて選択したソースアドレスを、前記宛先に対応づけて前記格納部に登録することを特徴とする通信装置。
【００８８】
（付記７）
請求項６において、
前記格納部に格納された前記対応関係は、所定時間経過後消去されることを特徴とする通信装置。
【００８９】
（付記８）
付記１において、
端末と接続し、前記端末からの送信データをネットワークに送信する通信装置であって、
前記通信経路特性情報取得部は、前記端末からの要求に応じて、前記特性情報を取得し、
前記ソースアドレス選択部は、前記特性情報に基づいて選択したソースアドレスを前記端末に通知することを特徴とする通信装置。
【００９０】
（付記９）
付記１において、さらに、
前記選択されたソースアドレスに基づく前記宛先までの通信経路の通信断を検出する検出部を備え、
前記検出部が前記通信断を検出すると、前記通信経路特性情報取得部は、再度、前記特性情報を取得し、
前記ソースアドレス選択部は、前記特性情報に基づいて、選択すべきソースアドレスを変更することを特徴とする通信装置。
【００９１】
（付記１０）
付記１において、
前記通信経路特性情報取得部は、定期的に前記特性情報を取得し、
前記ソースアドレス選択部は、前記特性情報に基づいて、選択すべきソースアドレスを定期的に更新することを特徴とする通信装置。
【図面の簡単な説明】
【００９２】
【図１】従来のソースアドレス選択方法を説明する図である。
【図２】本発明の第一の実施の形態例における通信装置の構成例を示す図である。
【図３】送信パケット生成部１２の処理例を示すフローチャートである。
【図４】ソースアドレス選択部１５の処理例のフローチャートである。
【図５】通信経路特性情報取得部１７の処理例を説明する図である。
【図６】本発明の実施の第二の形態例における通信装置を説明する図である。
【図７】本実施の第二の実施の形態例における端末１Aとゲイトウェイ１Bのブロック構成を示す図である。
【図８】本発明の第二の実施の形態例における端末１Aとゲイトウェイ１Bの別のブロック構成例を示す図である。
【図９】ネットワークの接続性に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。
【図１０】ICMP Echo メッセージを利用した接続性確認のための通信経路特性情報取得部１７の処理例を説明する図である。
【図１１】ネットワークの遅延に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。
【図１２】ICMP Echoメッセージを利用した遅延測定のための通信経路特性情報取得部１７の処理例を説明する図である。
【図１３】通信経路の帯域に関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。
【図１４】通信経路のポリシーに関する特性情報を取得する通信経路特性情報取得部１７のブロック構成例を示す図である。
【図１５】ポリシー格納部１７９の構成例を示す図である。
【図１６】図７の構成における名前解決メッセージを利用した接続性確認の処理例を説明する図である。
【図１７】名前解決メッセージのフォーマット例を示す図である。
【図１８】図７の構成における名前解決メッセージを利用した接続性確認の別の処理例を説明する図である。
【図１９】IPv6におけるリダイレクトメッセージのフォーマット例を示す図である。
【図２０】IPv4におけるリダイレクトメッセージのフォーマット例を示す図である。
【図２１】図８の構成において、ゲイトウェイ１Bが端末１Aから通信パケットを受信した場合の処理例を示す図である。
【図２２】ゲイトウェイ１Bが通信パケットの宛先アドレスとソースアドレスの対応関係のチェックする処理例のフローチャートである。
【図２３】図７の構成における名前解決メッセージを利用した接続性確認のさらなる別の処理例を説明する図である。
【図２４】DHCP Static Routeメッセージのフォーマット例を示す図である。
【図２５】本発明の実施の第一の実施の形態例における通信装置の別のブロック構成例を示す図である。
【符号の説明】
【００９３】
１A：端末（通信装置）、１B：ゲイトウェイ（通信装置）、１０：通信断検出部、１１：送信データ受付部、１２：送信パケット生成部、１３：パケット送信部、１４：宛先・ソースアドレス対応表格納部、１５：ソースアドレス選択部、１６：ソースアドレスリスト格納部、１７：通信経路特性情報取得部、１８：パケット受信部、１９：アドレス情報要求部、２０：アドレス情報応答部
【特許請求の範囲】
【請求項１】
複数のネットワークと接続可能であり、各ネットワークとそれぞれ接続するためのソースアドレスが割り当てられた通信装置において、
送信データの宛先に関する情報を受信すると、各ネットワークを介した前記宛先までのそれぞれの通信経路の特性情報を取得する通信経路特性情報取得部と、
前記特性情報に基づいて、複数のソースアドレスの中から一つのソースアドレスを選択するソースアドレス選択部と、
前記選択されたソースアドレスに対応するネットワークに対して前記送信データを送信する送信部とを備えることを特徴とする通信装置。
【請求項２】
請求項１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の接続性に関する情報であり、
前記通信経路特性情報取得部は、各ネットワークの通信経路が前記宛先まで接続しているかどうかを確認し、
前記ソースアドレス選択部は、前記宛先と接続しているネットワークに対応するソースアドレスを選択することを特徴とする通信装置。
【請求項３】
請求項１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の遅延性に関する情報であり、
前記通信経路特性情報取得部は、各ネットワークの通信経路の遅延を測定し、
前記ソースアドレス選択部は、通信経路の遅延が最小となるネットワークに対応するソースアドレスを選択することを特徴とする通信装置。
【請求項４】
請求項１において、さらに、
前記選択されたソースアドレスと前記宛先との対応関係を格納する格納部を備え、
前記通信経路特性情報取得部は、前記格納部に、前記宛先に対応するソースアドレスが格納されていない場合に、前記特性情報を取得し、
前記ソースアドレス選択部は、前記特性情報に基づいて選択したソースアドレスを、前記宛先に対応づけて前記格納部に登録することを特徴とする通信装置。
【請求項５】
請求項４において、
前記格納部に格納された前記対応関係は、所定時間経過後消去されることを特徴とする通信装置。
【請求項１】
複数のネットワークと接続可能であり、各ネットワークとそれぞれ接続するためのソースアドレスが割り当てられた通信装置において、
送信データの宛先に関する情報を受信すると、各ネットワークを介した前記宛先までのそれぞれの通信経路の特性情報を取得する通信経路特性情報取得部と、
前記特性情報に基づいて、複数のソースアドレスの中から一つのソースアドレスを選択するソースアドレス選択部と、
前記選択されたソースアドレスに対応するネットワークに対して前記送信データを送信する送信部とを備えることを特徴とする通信装置。
【請求項２】
請求項１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の接続性に関する情報であり、
前記通信経路特性情報取得部は、各ネットワークの通信経路が前記宛先まで接続しているかどうかを確認し、
前記ソースアドレス選択部は、前記宛先と接続しているネットワークに対応するソースアドレスを選択することを特徴とする通信装置。
【請求項３】
請求項１において、
前記特性情報は、前記宛先までのそれぞれの通信経路の遅延性に関する情報であり、
前記通信経路特性情報取得部は、各ネットワークの通信経路の遅延を測定し、
前記ソースアドレス選択部は、通信経路の遅延が最小となるネットワークに対応するソースアドレスを選択することを特徴とする通信装置。
【請求項４】
請求項１において、さらに、
前記選択されたソースアドレスと前記宛先との対応関係を格納する格納部を備え、
前記通信経路特性情報取得部は、前記格納部に、前記宛先に対応するソースアドレスが格納されていない場合に、前記特性情報を取得し、
前記ソースアドレス選択部は、前記特性情報に基づいて選択したソースアドレスを、前記宛先に対応づけて前記格納部に登録することを特徴とする通信装置。
【請求項５】
請求項４において、
前記格納部に格納された前記対応関係は、所定時間経過後消去されることを特徴とする通信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【公開番号】特開２００６−８６８００（Ｐ２００６−８６８００Ａ）
【公開日】平成１８年３月３０日（２００６．３．３０）
【国際特許分類】
【出願番号】特願２００４−２６９３８３（Ｐ２００４−２６９３８３）
【出願日】平成１６年９月１６日（２００４．９．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成１８年３月３０日（２００６．３．３０）
【国際特許分類】
【出願日】平成１６年９月１６日（２００４．９．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]