パケット通信システム
【課題】複数のサービス網を収容するＩＰ網内で、ユーザ端末から送信されたパケットを、適切なサービス網へ転送する。
【解決手段】ユーザ端末とサービス網との間でパケット通信を行うためのパケット通信システムにおいて、送信元ＩＤと、宛先ＩＤと、前記サービス網の位置情報とを対応付けて保持する対応表を生成する対応表生成格納装置と、ユーザが契約するサービス網の情報を格納した契約情報格納装置と、パケット転送装置と、を備え、前記対応表生成格納装置は、前記契約情報格納装置から、サービス網の識別情報と位置情報を取得し、前記送信元ＩＤ、宛先ＩＤ、及び位置情報とを対応付けて記録し、前記パケット転送装置は、前記ユーザ端末から、前記送信元ＩＤ、及び前記宛先ＩＤを含むパケットを受信したときに、対応するサービス網の位置情報を前記対応表生成格納装置から取得し、位置情報を宛先としたヘッダを付加して前記パケットを転送する。
【解決手段】ユーザ端末とサービス網との間でパケット通信を行うためのパケット通信システムにおいて、送信元ＩＤと、宛先ＩＤと、前記サービス網の位置情報とを対応付けて保持する対応表を生成する対応表生成格納装置と、ユーザが契約するサービス網の情報を格納した契約情報格納装置と、パケット転送装置と、を備え、前記対応表生成格納装置は、前記契約情報格納装置から、サービス網の識別情報と位置情報を取得し、前記送信元ＩＤ、宛先ＩＤ、及び位置情報とを対応付けて記録し、前記パケット転送装置は、前記ユーザ端末から、前記送信元ＩＤ、及び前記宛先ＩＤを含むパケットを受信したときに、対応するサービス網の位置情報を前記対応表生成格納装置から取得し、位置情報を宛先としたヘッダを付加して前記パケットを転送する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、キャリアのＩＰ網において柔軟かつ軽量にルーティングを行うための技術に関するものである。
【背景技術】
【０００２】
現在のキャリアの基幹ネットワークはＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網で構成され、その上で様々なサービス網を収容し、ユーザにサービスを提供している。そのため、キャリアのＩＰ網では、サービスを利用するユーザと、そのサービスが提供されているサービス網との間で、ＩＰの接続性を提供する必要がある。例えば、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）と契約しているユーザのＩＰパケットをそのＩＳＰに転送したり、企業拠点等（以下、ＶＰＮ拠点）へのリモートアクセスサービスを契約しているユーザと、そのユーザが属しているＶＰＮ拠点との間でパケットを転送したりする機能を提供する。
【０００３】
ユーザとサービス網の接続機能を提供するには、通常、キャリアのＩＰ網を介して、個々のユーザとサービス網の間に仮想的なトンネルを生成する技術を利用する。このようなトンネル技術を利用することで、ユーザからはキャリアのＩＰ網が隠蔽され、直接サービス網との間で、ＩＰによって接続されたように見える。トンネルを生成するプロトコルとしては、ＶＰＮを構成する際に利用されるＩＰｓｅｃやＬ２ＴＰ、ＰＰＴＰなどがある。しかし、これらのプロトコルは、個々のユーザのトンネルごとに状態管理が必要であり、数千万ユーザにも及ぶキャリアの大規模ネットワークでは、スケールしないという課題がある。
【０００４】
一方、キャリアＩＰ網を簡易に実現できる可能性のある新たな技術として、ＬＩＳＰ（Ｌｏｃａｔｏｒ／ＩＤ Ｓｅｐａｒａｔｉｏｎ）が注目されている（非特許文献１）。ＬＩＳＰは、端末に付与されたＩＰアドレス（ＩＤ）と、その端末が存在する場所（サイト）を示すＬｏｃａｔｏｒを分離し、両者の対応関係を適切に設定することで、端末とサイト間のシームレスな通信を実現する技術である。端末をユーザ、サイトをサービス網とするネットワーク構成により、キャリアＩＰ網を実現できる可能性がある。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】"Ｌｏｃａｔｏｒ／ＩＤ Ｓｅｐａｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＬＩＳＰ），" ＩＥＴＦドラフト，ｄｒａｆｔ−ｉｅｔｆ−ｌｉｓｐ−１２http://datatracker.ietf.org/doc/draft-ietf-lisp/?include_text=1（２０１１年６月８日検索）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、従来提案されているＬＩＳＰでは、次のような課題がある。
【０００７】
まず、ＬＩＳＰは、本来、インターネットにおいて、端末そのものを示すＩＤと、端末が存在するサイトを示すＬｏｃａｔｏｒを分離し、インターネット内の経路制御をＬｏｃａｔｏｒのみで実現することで、インターネット内の経路表の削減を狙った技術である。そのため、宛先のＩＤから、その宛先端末が存在するサイトを示すＬｏｃａｔｏｒを求める場合には、通常のＩＰルーティングと同様に、宛先端末を示すＩＤをキーとしてＬｏｃａｔｏｒを得る方法が採用されている。この手法は、全体が単一のＩＰアドレス空間であるインターネットには適用可能である。しかし、リモートアクセスサービスにおけるＶＰＮ拠点のように同一のプライベートアドレスが複数のサイトに存在したり、宛先がインターネット上のアドレスであっても、ユーザが契約するＩＳＰを経由して通信させたりする必要のあるキャリアＩＰ網では、ユーザの契約するＩＳＰに応じて経路が変わるため、必ずしも宛先端末のＩＤから、サイト（＝サービス網）を示すＬｏｃａｔｏｒが一意に定まるわけではない。そのため、従来のＬＩＳＰをそのまま適用することができない。
【０００８】
また、インターネットでは、全てのユーザに対して、あらゆるサイトへのＩＰ到達性を一律に提供すればよいため、ＬＩＳＰには特定のサイトへのアクセスを制限するような機能はない。一方、キャリアＩＰ網では、ユーザごとに契約するＩＳＰや所属するＶＰＮ拠点などが異なり、契約していないサービス網への通信を制限する機能が必要であるため、単純に従来のＬＩＳＰを適用することはできない。
【０００９】
本発明は上記の点に鑑みてなされたものであり、キャリアのＩＰ網内で、ユーザ端末から送信されたパケットを、ユーザの契約情報に基づいて適切なサービス網へ転送することを可能とした技術を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記の課題を解決するために、本発明は、複数のサービス網を収容するＩＰ網において、あるユーザのユーザ端末と当該ユーザが契約するサービス網との間でパケット通信を行うためのパケット通信システムであって、
前記ユーザを識別するＩＤである送信元ＩＤと、前記ユーザ端末の通信相手となる端末のＩＤである宛先ＩＤと、前記サービス網の前記ＩＰ網上での位置を示す位置情報とを対応付けて保持する対応表を生成し、格納する対応表生成格納装置と、
前記ユーザのユーザ名と対応付けて、当該ユーザが契約するサービス網の情報を格納した契約情報格納装置と、
前記ユーザ端末と接続されるパケット転送装置と、を備え、
前記対応表生成格納装置は、前記ユーザのユーザ名と前記送信元ＩＤとを含む対応表生成要求を受信したことに応じて、前記契約情報格納装置から、前記ユーザ名に対応するサービス網の識別情報と当該サービス網の位置情報を取得し、前記送信元ＩＤ、当該サービス網における宛先ＩＤ、及び当該サービス網の位置情報とを対応付けて前記対応表に記録し、
前記パケット転送装置は、前記ユーザ端末から、前記送信元ＩＤ、及び前記宛先ＩＤを含むパケットを受信したときに、当該送信元ＩＤ及び宛先ＩＤに対応するサービス網の位置情報を前記対応表生成格納装置から取得し、取得した位置情報を宛先としたヘッダを付加して前記パケットを前記ＩＰ網に転送することを特徴とするパケット通信システムとして構成される。
【００１１】
前記パケット通信システムは、前記送信元ＩＤを前記ユーザ端末に割り当てるＩＤ割り当て装置を備え、前記ユーザ端末が前記ＩＤ割り当て装置に対してＩＤ割り当て要求を送信し、当該ＩＤ割り当て要求を受信したＩＤ割り当て装置は、前記ユーザ端末に対して前記送信元ＩＤの割り当てを行うとともに、前記対応表生成格納装置に対して前記対応表生成要求を送信するように構成してもよい。
【００１２】
なお、前記ＩＤ割り当て装置は例えばＤＨＣＰサーバであり、前記送信元ＩＤとして、前記ユーザ端末にＩＰアドレスを割り当てることとしてもよい。
【００１３】
また、前記パケット転送装置は、前記対応表生成格納装置から取得した前記位置情報を、前記送信元ＩＤ及び前記宛先ＩＤとともに記憶手段に保持し、前記パケットの受信以降に、当該パケットと同一の送信元ＩＤ及び宛先ＩＤを持つパケットを受信した場合に、前記記憶手段に保持した位置情報を用いて転送を行うようにしてもよい。
【発明の効果】
【００１４】
本発明によれば、キャリアのＩＰ網内で、ユーザ端末から送信されたパケットを、ユーザの契約情報に基づいて適切なサービス網へ転送することを可能とする技術が実現される。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施の形態におけるネットワーク構成を示す図である。
【図２】マップテーブルの構成を示す図である。
【図３】ＤＨＣＰサーバのテーブルの構成を示す図である。
【図４】ユーザ契約情報テーブルの構成を示す図である。
【図５】エッジルータ、ゲートウェイルータとして使用されるルータの構成図である。
【図６】マップサーバの構成図である。
【図７】マップテーブルを生成する手順を示すシーケンス図である。
【図８】パケットの転送の流れを示すシーケンス図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照しながら本発明の実施の形態を説明する。
【００１７】
（実施の形態の概要）
後に詳述するように、本実施の形態では、端末ＩＤとＬｏｃａｔｏｒの対応関係を保持するマップテーブルにおいて、宛先端末のＩＤに加えて、ユーザを識別する何らかのＩＤをキーに加えることで、宛先端末のＩＤ（すなわち宛先アドレス）が同一であっても、ユーザ毎に付与されるＩＤが異なれば、別のＬｏｃａｔｏｒを引けるようにする。これにより、ユーザの契約情報等に基づいて、異なるサービス網へパケットを転送できるようになる。ユーザを識別するＩＤとしては、例えば、ユーザ端末に割り当てる端末ＩＤ（ＩＰアドレス）が利用できる。
【００１８】
また、ユーザ毎にマップテーブルの設定が異なるため、マップテーブルを生成する手間が増大する可能性がある。これに対して、ユーザの契約情報に応じたマップテーブルを、ユーザ端末にアドレスを割り当てるＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバと、ユーザの契約情報等を保持するユーザ契約情報サーバを連携させることで、自動的に設定することとしている。
【００１９】
本実施の形態では、ユーザを識別するＩＤとして、ユーザ端末に割り当てる端末ＩＤ（具体的には、キャリア網内で利用するＩＰアドレス）を利用することとするが、ユーザを識別するＩＤはこれに限定されるものではない。
【００２０】
（システム構成）
図１に、本実施に形態におけるネットワーク構成を示す。図１に示すように、本実施の形態に係るネットワークは、キャリアのＩＰ網１に、サービス網として、２つのＩＳＰ（ＩＳＰ＃Ａ（２Ａ）、ＩＳＰ＃Ｂ（２Ｂ））、１つのＶＰＮサイト３、及び１つのＣＳＰ（Ｃｏｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）４が、それぞれゲートウェイルータ７（ＧＷ１〜ＧＷ４）を介して接続されて構成されている。また、それぞれのＩＳＰ（２Ａ、２Ｂ）は、インターネット５と接続されている。
【００２１】
また、ユーザＡのユーザ端末１１ＡとユーザＢのユーザ端末１１Ｂが、それぞれエッジルータ６（Ｅ１、Ｅ２）を介して接続されている。本実施の形態では、ユーザＡとユーザＢの二人のユーザがいることを仮定する。ユーザＡは、インターネット接続サービスとしてＩＳＰ＃Ａと、リモートアクセスサービスの接続先としてＶＰＮ＃１と契約しており、ユーザＢはＩＳＰ＃Ｂとのみ契約しているものとする。
【００２２】
エッジルータ６（Ｅ１、Ｅ２）やゲートウェイルータ７（ＧＷ１〜ＧＷ４）は、通常のルータ１２（Ｒ１〜Ｒ３）を介してＩＰ網１内で相互に接続されている。さらに、ＩＰ網１には、ＩＤとＬｏｃａｔｏｒの対応表を作成・管理するマップサーバ８、ユーザ端末にＩＰアドレスを割り当てるＤＨＣＰサーバ９、及びユーザ毎の契約情報を保持しているユーザ契約情報サーバ１０が接続されている。マップサーバ８、ＤＨＣＰサーバ９、及びユーザ契約情報サーバ１０は互いに通信可能である。本実施の形態におけるＬｏｃａｔｏｒは、例えばＩＰアドレスである。また、Ｌｏｃａｔｏｒは、サービス網のＩＰ網上での位置を示す位置情報である。
【００２３】
なお、マップサーバ８、ＤＨＣＰサーバ９、及びユーザ契約情報サーバ１０は、それぞれ、その機能から、対応表生成格納装置、ＩＤ割り当て装置、契約情報格納装置と呼んでもよい。
【００２４】
次に、図２〜図４を用いて、マップサーバ８、ＤＨＣＰサーバ９、ユーザ契約情報サーバ１０が保持するテーブルの構成例を説明する。
【００２５】
図２は、マップサーバ８が保持するマップテーブル１００である。マップテーブル１００は、ユーザを識別するＩＤである送信元ＩＤ１０１、及び宛先ＩＤ１０２の組み合わせと、宛先端末に到達するために経由するサービス網を示すＬｏｃａｔｏｒ１０３の対応関係を保持している。
【００２６】
図３は、ＤＨＣＰサーバ９が保持するＤＨＣＰサーバテーブル２００である。ＤＨＣＰサーバ９は、ＩＰ網１に接続してきたユーザ端末にＩＤを割り当てるサーバである。ＤＨＣＰは一般に広く利用されているプロトコルであり、ここで示すＤＨＣＰサーバテーブル２００の構成も、一般的なＤＨＣＰサーバが保持するテーブルと同じである。ＤＨＣＰサーバテーブル２００は、ユーザ端末に割り当てたＩＤ２０１と、そのＩＤを割り当てたユーザ端末のユーザを一意に識別する文字列であるユーザ名２０２、及び、そのユーザ端末が接続されているエッジルータのＬｏｃａｔｏｒ２０３を保持する。ユーザ端末にＩＤを割り当てるたびに、これらの情報が１行ずつ追加されていく。
【００２７】
図４は、ユーザ契約情報サーバ１０が保持するユーザ契約情報テーブル３００である。ユーザ毎に契約しているサービス網（ＩＳＰ、ＶＰＮ拠点など）の情報が保持されているテーブルである。ユーザ契約情報テーブル３００は、ユーザ名３０１と、そのユーザが契約しているサービス網のリストであるサービス網リスト３０２、ユーザが契約しているそれぞれのサービス網に接続されているＧＷのＬｏｃａｔｏｒのリストであるＧＷのＬｏｃａｔｏｒリスト３０３から構成される。ユーザ契約情報テーブル３００は、ユーザがサービス網との契約を追加したり、削除したりした場合に更新されるものである。
【００２８】
図５を用いて、エッジルータ６及びゲートウェイルータ７の構成例を説明する。なお、エッジルータ６及びゲートウェイルータ７は基本的に同じ構成であるため、図５には、エッジルータ６及びゲートウェイルータ７のいずれにも使用できるルータ４００の構成が示されている。なお、ルータ４００はパケット転送装置と呼んでもよい。
【００２９】
ルータ４００は、通常のルータと同様に、ネットワークに接続される複数のインタフェース４０１と、パケットの宛先に応じて転送先のインタフェースへ転送するスイッチ４０３を保持する。インタフェース４０１の内部には、ルーティングテーブルのコピーであるフォワーディングテーブル４０２を保持する。また、他のルータとの間で、ＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ）やＢＧＰ（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）などのルーティングプロトコルを通じて取得した経路情報を保持するルーティングテーブル４０４を保持する点も一般のルータと同様である。
【００３０】
一方、本発明に係る技術に特有の構成として、マップキャッシュ４０５を保持している。マップキャッシュ４０５は、マップサーバ８から取得したＩＤとＬｏｃａｔｏｒの対応関係を一時的に保持するキャッシュテーブルである。後述するように、パケットを転送する際に、ＩＤに対応したＬｏｃａｔｏｒを取得するため、両者の対応関係を保持するマップサーバ８に問い合わせる必要があるが、一般に同一の宛先へのパケットは連続して転送されることが多いため、パケットを１つ転送するたびにマップサーバ８に問い合わせるのは非効率である。一度問い合わせたものについては、ローカルに保持しておくことが望ましいため、ルータ４００（すなわち、エッジルータ６及びゲートウェイルータ７）の内部にマップキャッシュ４０５を保持する構成をとる。なお、マップキャッシュ４０５は、マップサーバ８に問い合わせた内容を一時的に保持するためのものであるため、その構成はマップテーブル１００と同様である。テーブルの内容としては、マップサーバ８がネットワーク全体のＩＤとＬｏｃａｔｏｒの対応関係すべてを保持するのに対して、マップキャッシュ４０５は、そのエッジルータ６やゲートウェイルータ７が問い合わせた内容のみを保持するため、マップサーバ８が保持するマップテーブル１００のサブセットとなる。
【００３１】
図６に、マップサーバ８の機能構成図を示す。図６に示すようにマップサーバ８は、マップテーブル格納部８１、契約情報取得部８２、マップテーブルエントリ作成部８３、マップテーブル検索部８４を備える。
【００３２】
マップテーブル格納部８１は、マップテーブル１００を格納するメモリ等の記憶手段である。契約情報取得部８２は、ＤＨＣＰサーバ９からマップ生成リクエストを受信したことに応じて、ユーザ契約情報サーバ１０に契約情報リクエストを送信することにより、ユーザ契約情報サーバ１０から契約情報を取得する機能部である。マップテーブルエントリ作成部８３は、契約情報取得部８２が取得した契約情報等を用いてマップテーブルエントリを作成する機能部である。マップテーブル検索部８４は、エッジルータ６やゲートウェイルータ７からマップ解決リクエストを受信したことに応じて、マップテーブル１００を検索し、該当するＬｏｃａｔｏｒを返す機能部である。
【００３３】
マップサーバ８は、ＣＰＵ、メモリ、通信装置等から構成されるコンピュータに、各機能部に対応したプログラムを実行させることにより実現可能である。すなわち、マップサーバ８の各部が有する機能は、当該マップサーバ８を構成するコンピュータに内蔵されるＣＰＵやメモリなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【００３４】
ＤＨＣＰサーバ９は、通常のＤＨＣＰサーバの機能に加えて、マップ生成リクエストをマップサーバ８に送信する機能を有する。ユーザ契約情報サーバ１０は、ユーザ名を含む契約情報リクエストをマップサーバ８から受信し、ユーザ名でユーザ契約情報テーブルを検索することにより、該当ユーザの契約情報を取得して、契約情報リプライをマップサーバ８に返す機能を有する。
【００３５】
（システムの動作）
以下、上述した構成を有するシステムの動作を説明する。
【００３６】
＜マップテーブル生成手順＞
まず、図７を用いて、マップサーバ８においてマップテーブル１００が生成されるまでの手順を説明する。なお、ここでは、ユーザＡのユーザ端末１１ＡがＩＰ網１に接続してきたと仮定し、ユーザＡのマップテーブルのエントリを生成する手順を説明する。
【００３７】
まず、ユーザ端末１１Ａは、ＩＰ網１に接続すると、ＩＤの割り当てをＩＰ網１に要求するために、ＤＨＣＰリクエストを送信する（ステップＳ１１）。ＤＨＣＰリクエストは、エッジルータＥ１を経由してＤＨＣＰサーバ９に転送される。なお、ここでは、ＤＨＣＰリクエストにユーザ名「ユーザＡ」が含まれているものとする。
【００３８】
ＤＨＣＰサーバ９では、ユーザ端末１１Ａに対するＩＤとして、ａを割り当て、ＤＨＣＰサーバ９のテーブル２００に、ユーザＡにＩＤ＝ａを割り当て、さらにそのユーザ端末１１ＡがエッジルータＥ１に収容されていることを記録する。図３では、１行目のエントリが該当する。その後、ＤＨＣＰサーバ９は、ユーザ端末１１ＡにＤＨＣＰリプライを返送する（ステップＳ１２）。これで、ユーザ端末１１Ａに、ＩＤとしてａが割り当てられた。
【００３９】
次に、ＤＨＣＰサーバ９は、マップサーバ８に対して、ユーザＡ（ユーザ端末１１Ａ）にＩＤ＝ａを割り当てたことを通知し、マップテーブルの生成を要求するマップ生成リクエストを送信する（ステップＳ１３）。マップサーバ８は、マップ生成リクエストを受信すると、ユーザ契約情報サーバ１０に対して、ユーザＡが契約するサービス網のリストを送信するように要求する契約情報リクエストを送信する（ステップＳ１４）。
【００４０】
ユーザ契約情報サーバ１０は、契約情報リクエストを受信すると、ユーザ契約情報テーブル３００を参照し、ユーザＡが契約しているサービス網のリスト（サービス網の識別情報のリスト）として（ＩＳＰ＃１、ＶＰＮ＃１）を、それらのサービス網が接続されているゲートウェイのＬｏｃａｔｏｒリストとして（ＧＷ１、ＧＷ３）を取得して、マップサーバ８に対して、契約情報リプライとして返送する（ステップＳ１５）。
【００４１】
マップサーバ８は、契約情報リプライを受信した段階で、マップテーブル１００の生成に必要な情報がそろうため、マップテーブルエントリ作成部８３により、マップテーブル１００のエントリを生成する（ステップＳ１６）。具体的には、まずユーザＡが契約しているＩＳＰ＃Ａへの通信を実現するエントリとして、送信元ＩＤ＝ａ、宛先ＩＤ＝ａｎｙ、Ｌｏｃａｔｏｒ＝ＧＷ１を設定する（図２の１行目のエントリ）。ここで、宛先ＩＤ＝ａｎｙというのは、あらゆるＩＤに合致することを意味する。契約するＩＳＰに対する通信では、ＩＳＰ内の宛先に加えて、インターネットのあらゆる宛先に対する通信が行われるため、マップテーブルにおいて、送信元ＩＤが一致し、宛先ＩＤに一致するエントリがない全ての通信をＩＳＰに転送する必要がある。そのため、ＩＳＰに対する通信では宛先ＩＤ＝ａｎｙを設定する。
【００４２】
次に、ユーザＡが契約するＶＰＮ＃１への通信を実現するエントリとして、送信元ＩＤ＝ａ、宛先ＩＤ＝ｄ、Ｌｏｃａｔｏｒ＝ＧＷ３を設定する（図２の２行目のエントリ）。ここで、宛先ＩＤ＝ｄはＶＰＮ＃１内で利用されているＩＤのセットを示す。一般に、ＶＰＮ拠点内ではプライベートアドレスが利用されるため、ｄはプライベートアドレス空間を指し示す値（たとえば、ＩＰｖ４アドレスでは、１０．０．０．０／８がプライベート空間を示す）を設定する。ただし、プライベートアドレス空間以外のＩＤが利用されていた場合でも、予めマップサーバ８にＶＰＮ拠点と、そのＶＰＮ拠点内で利用されているＩＤの対応を保持しておけば、どのようなＩＤでも設定することが可能である。
【００４３】
なお、サービス網毎に、どのような宛先ＩＤを設定するかを示す情報はマップサーバ８において予め保持されているものとする。
【００４４】
さらに、マップサーバ８は、他のゲートウェイルータ７やエッジルータ６から、ユーザ端末１１Ａ宛てのパケットを転送するために、送信元ＩＤ＝ａｎｙ、宛先ＩＤ＝ａ、Ｌｏｃａｔｏｒ＝Ｅ１のエントリを生成する（図２の３行目のエントリ）。
【００４５】
＜パケット送信手順＞
次に、図８を用いて、ユーザ端末１１Ａがインターネット５上にある宛先ＩＤ（図８ではＤＩＤ）がｘの端末にパケットを送信する手順を説明する。
【００４６】
まず、ユーザ端末１１Ａは、通常のＩＰパケットの転送と同じように、ＩＰヘッダの送信元アドレス（図８ではＳＩＤ）に自身のＩＤであるａを、宛先アドレス（ＤＩＤ）にｘをセットしてパケットを送信する（ステップＳ２１）。
【００４７】
パケットを受信したエッジルータＥ１は、自身のマップキャッシュ４０５内に、送信元ＩＤ＝ａ、宛先ＩＤ＝ｘに対応するＬｏｃａｔｏｒのアドレスが保存されているかを検索する（ステップＳ２２）。ここでは、キャッシュ内の該当するＬｏｃａｔｏｒが保存されていないと仮定し、マップサーバ８に問い合わせを行う。すなわち、エッジルータＥ１は、マップサーバ８に、送信元ＩＤ＝ａ及び宛先ＩＤ＝ｘを含むマップ解決リクエストを送信し（ステップＳ２３）、送信元ＩＤ＝ａ、宛先ＩＤ＝ｘに対応するＬｏｃａｔｏｒを問い合わせる。
【００４８】
マップ解決リクエストを受信したマップサーバ８は、マップテーブル検索部８４により、マップテーブル１００を、送信元ＩＤ＝ａ、宛先ＩＤ＝ｘで検索する（ステップＳ２４）。ここでは、完全に一致するエントリは存在しないが、送信元ＩＤ＝ａ、宛先ＩＤ＝ａｎｙのエントリ（図２の１行目のエントリ）が該当するため、その対応するＬｏｃａｔｏｒとしてＧＷ１を、マップ解決リプライとして、エッジルータＥ１に返送する（ステップＳ２５）。なお、宛先ＩＤ＝ａｎｙ以外のエントリで該当するエントリがある場合は、そのエントリが優先される。例えば、図２の２行目のエントリが該当する場合は、ＬｏｃａｔｏｒとしてＧＷ３が返送される。
【００４９】
エッジルータＥ１は、該当するＬｏｃａｔｏｒが得られたため、ＩＤとの対応関係をマップキャッシュ４０５に記録する。ここでは、送信元ＩＤ＝ａ、宛先ＩＤ＝ａｎｙ、Ｌｏｃａｔｏｒ＝ＧＷ１を記録する。その後、ユーザ端末１１Ａから送信されてきたパケットに、宛先Ｌｏｃａｔｏｒ（図８ではＤＬｏｃ）としてＧＷ１を、送信元Ｌｏｃａｔｏｒ（図８ではＳＬｏｃ）としてエッジルータＥ１自身のＬｏｃａｔｏｒをセットしたヘッダを付与して、送信する（ステップＳ２６）。
【００５０】
ＩＰ網１内は、エッジルータＥ１で付与された外側のヘッダのみを参照してＩＰパケットが転送される。ここでは、通常のＩＰルーティングに従う転送が行われる。例えば、エッジルータ６でもゲートウェイルータ７でもない通常のルータ１２は、ユーザ端末のＩＤは意識せず、エッジルータ６で付与されたヘッダに記載されるＬｏｃａｔｏｒのみを参照して転送処理を行う。なお、ＩＰ網１内での各Ｌｏｃａｔｏｒ（ＧＷ１など）への到達性は、通常のルーティングプロトコルを通じて取得するものとする。これらは、エッジルータ６、ゲートウェイルータ７、通常のルータ１２が保持するルーティングテーブルに保持されている。
【００５１】
ゲートウェイルータＧＷ１は、転送されてきたパケットを受信すると、そのパケットのヘッダのＤＬｏｃを参照し、自分宛てのパケットかどうかをチェックする。そのうえで、自分宛てのパケットであれば、外側のヘッダを外し、サービス網（この場合はＩＳＰ＃１）にパケットを送信する（ステップＳ２７）。
【００５２】
インターネット（ＩＳＰ＃１経由）やＶＰＮ＃１からユーザ端末１１Ａ宛てのパケットの転送も、同様に行われる。各ゲートウェイルータ７が、マップサーバ８に宛先ＩＤ＝ａ宛てのＬｏｃａｔｏｒを問い合わると、図２の３行目のエントリが該当し、Ｌｏｃａｔｏｒ＝Ｅ１が返送されることにより、ゲートウェイルータ７からエッジルータＥ１にパケットが転送される。また、図１のユーザ端末１１Ｂの通信に関しても、ユーザ端末１１Ａの通信と同様である。
【００５３】
（実施の形態の効果）
通常のＬＩＳＰでは宛先ＩＤのみからＬｏｃａｔｏｒを取得するが、上述したように本実施の形態では、ユーザを識別するＩＤ（本実施の形態では、ユーザ端末に割り当てたＩＤ）もキーとして利用することで、ユーザの契約状況に応じたサービス網へのパケット転送を実現している。
【００５４】
これにより、従来のＬＩＳＰでは実現できなかった、ユーザの契約情報に基づいてキャリアのＩＰ網内で、適切なサービス網へパケットを転送することが可能となる。また、ユーザの契約情報をサーバに保持しておくことで、ユーザがＩＰ網に接続してきたことを契機として、自動的にマップサーバのエントリを生成することとしたので、手動でマップテーブルを生成する手間が省ける。
【００５５】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００５６】
１ ＩＰ網
２Ａ、２Ｂ ＩＳＰ
３ ＶＰＮ
４ ＣＳＰ
５ インターネット
６ エッジルータ
７ ゲートウェイルータ
８ マップサーバ
８１ マップテーブル格納部
８２ 契約情報取得部
８３ マップテーブルエントリ作成部
８４ マップテーブル検索部
９ ＤＨＣＰサーバ
１０ ユーザ契約情報サーバ
１００ マップテーブル
２００ ＤＨＣＰサーバテーブル
３００ ユーザ契約情報テーブル
４００ ルータ
４０１ インタフェース
４０２ フォワーディングテーブル
４０３ スイッチ
４０４ ルーティングテーブル
４０５ マップキャッシュ
【技術分野】
【０００１】
本発明は、キャリアのＩＰ網において柔軟かつ軽量にルーティングを行うための技術に関するものである。
【背景技術】
【０００２】
現在のキャリアの基幹ネットワークはＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網で構成され、その上で様々なサービス網を収容し、ユーザにサービスを提供している。そのため、キャリアのＩＰ網では、サービスを利用するユーザと、そのサービスが提供されているサービス網との間で、ＩＰの接続性を提供する必要がある。例えば、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）と契約しているユーザのＩＰパケットをそのＩＳＰに転送したり、企業拠点等（以下、ＶＰＮ拠点）へのリモートアクセスサービスを契約しているユーザと、そのユーザが属しているＶＰＮ拠点との間でパケットを転送したりする機能を提供する。
【０００３】
ユーザとサービス網の接続機能を提供するには、通常、キャリアのＩＰ網を介して、個々のユーザとサービス網の間に仮想的なトンネルを生成する技術を利用する。このようなトンネル技術を利用することで、ユーザからはキャリアのＩＰ網が隠蔽され、直接サービス網との間で、ＩＰによって接続されたように見える。トンネルを生成するプロトコルとしては、ＶＰＮを構成する際に利用されるＩＰｓｅｃやＬ２ＴＰ、ＰＰＴＰなどがある。しかし、これらのプロトコルは、個々のユーザのトンネルごとに状態管理が必要であり、数千万ユーザにも及ぶキャリアの大規模ネットワークでは、スケールしないという課題がある。
【０００４】
一方、キャリアＩＰ網を簡易に実現できる可能性のある新たな技術として、ＬＩＳＰ（Ｌｏｃａｔｏｒ／ＩＤ Ｓｅｐａｒａｔｉｏｎ）が注目されている（非特許文献１）。ＬＩＳＰは、端末に付与されたＩＰアドレス（ＩＤ）と、その端末が存在する場所（サイト）を示すＬｏｃａｔｏｒを分離し、両者の対応関係を適切に設定することで、端末とサイト間のシームレスな通信を実現する技術である。端末をユーザ、サイトをサービス網とするネットワーク構成により、キャリアＩＰ網を実現できる可能性がある。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】"Ｌｏｃａｔｏｒ／ＩＤ Ｓｅｐａｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＬＩＳＰ），" ＩＥＴＦドラフト，ｄｒａｆｔ−ｉｅｔｆ−ｌｉｓｐ−１２http://datatracker.ietf.org/doc/draft-ietf-lisp/?include_text=1（２０１１年６月８日検索）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、従来提案されているＬＩＳＰでは、次のような課題がある。
【０００７】
まず、ＬＩＳＰは、本来、インターネットにおいて、端末そのものを示すＩＤと、端末が存在するサイトを示すＬｏｃａｔｏｒを分離し、インターネット内の経路制御をＬｏｃａｔｏｒのみで実現することで、インターネット内の経路表の削減を狙った技術である。そのため、宛先のＩＤから、その宛先端末が存在するサイトを示すＬｏｃａｔｏｒを求める場合には、通常のＩＰルーティングと同様に、宛先端末を示すＩＤをキーとしてＬｏｃａｔｏｒを得る方法が採用されている。この手法は、全体が単一のＩＰアドレス空間であるインターネットには適用可能である。しかし、リモートアクセスサービスにおけるＶＰＮ拠点のように同一のプライベートアドレスが複数のサイトに存在したり、宛先がインターネット上のアドレスであっても、ユーザが契約するＩＳＰを経由して通信させたりする必要のあるキャリアＩＰ網では、ユーザの契約するＩＳＰに応じて経路が変わるため、必ずしも宛先端末のＩＤから、サイト（＝サービス網）を示すＬｏｃａｔｏｒが一意に定まるわけではない。そのため、従来のＬＩＳＰをそのまま適用することができない。
【０００８】
また、インターネットでは、全てのユーザに対して、あらゆるサイトへのＩＰ到達性を一律に提供すればよいため、ＬＩＳＰには特定のサイトへのアクセスを制限するような機能はない。一方、キャリアＩＰ網では、ユーザごとに契約するＩＳＰや所属するＶＰＮ拠点などが異なり、契約していないサービス網への通信を制限する機能が必要であるため、単純に従来のＬＩＳＰを適用することはできない。
【０００９】
本発明は上記の点に鑑みてなされたものであり、キャリアのＩＰ網内で、ユーザ端末から送信されたパケットを、ユーザの契約情報に基づいて適切なサービス網へ転送することを可能とした技術を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記の課題を解決するために、本発明は、複数のサービス網を収容するＩＰ網において、あるユーザのユーザ端末と当該ユーザが契約するサービス網との間でパケット通信を行うためのパケット通信システムであって、
前記ユーザを識別するＩＤである送信元ＩＤと、前記ユーザ端末の通信相手となる端末のＩＤである宛先ＩＤと、前記サービス網の前記ＩＰ網上での位置を示す位置情報とを対応付けて保持する対応表を生成し、格納する対応表生成格納装置と、
前記ユーザのユーザ名と対応付けて、当該ユーザが契約するサービス網の情報を格納した契約情報格納装置と、
前記ユーザ端末と接続されるパケット転送装置と、を備え、
前記対応表生成格納装置は、前記ユーザのユーザ名と前記送信元ＩＤとを含む対応表生成要求を受信したことに応じて、前記契約情報格納装置から、前記ユーザ名に対応するサービス網の識別情報と当該サービス網の位置情報を取得し、前記送信元ＩＤ、当該サービス網における宛先ＩＤ、及び当該サービス網の位置情報とを対応付けて前記対応表に記録し、
前記パケット転送装置は、前記ユーザ端末から、前記送信元ＩＤ、及び前記宛先ＩＤを含むパケットを受信したときに、当該送信元ＩＤ及び宛先ＩＤに対応するサービス網の位置情報を前記対応表生成格納装置から取得し、取得した位置情報を宛先としたヘッダを付加して前記パケットを前記ＩＰ網に転送することを特徴とするパケット通信システムとして構成される。
【００１１】
前記パケット通信システムは、前記送信元ＩＤを前記ユーザ端末に割り当てるＩＤ割り当て装置を備え、前記ユーザ端末が前記ＩＤ割り当て装置に対してＩＤ割り当て要求を送信し、当該ＩＤ割り当て要求を受信したＩＤ割り当て装置は、前記ユーザ端末に対して前記送信元ＩＤの割り当てを行うとともに、前記対応表生成格納装置に対して前記対応表生成要求を送信するように構成してもよい。
【００１２】
なお、前記ＩＤ割り当て装置は例えばＤＨＣＰサーバであり、前記送信元ＩＤとして、前記ユーザ端末にＩＰアドレスを割り当てることとしてもよい。
【００１３】
また、前記パケット転送装置は、前記対応表生成格納装置から取得した前記位置情報を、前記送信元ＩＤ及び前記宛先ＩＤとともに記憶手段に保持し、前記パケットの受信以降に、当該パケットと同一の送信元ＩＤ及び宛先ＩＤを持つパケットを受信した場合に、前記記憶手段に保持した位置情報を用いて転送を行うようにしてもよい。
【発明の効果】
【００１４】
本発明によれば、キャリアのＩＰ網内で、ユーザ端末から送信されたパケットを、ユーザの契約情報に基づいて適切なサービス網へ転送することを可能とする技術が実現される。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施の形態におけるネットワーク構成を示す図である。
【図２】マップテーブルの構成を示す図である。
【図３】ＤＨＣＰサーバのテーブルの構成を示す図である。
【図４】ユーザ契約情報テーブルの構成を示す図である。
【図５】エッジルータ、ゲートウェイルータとして使用されるルータの構成図である。
【図６】マップサーバの構成図である。
【図７】マップテーブルを生成する手順を示すシーケンス図である。
【図８】パケットの転送の流れを示すシーケンス図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照しながら本発明の実施の形態を説明する。
【００１７】
（実施の形態の概要）
後に詳述するように、本実施の形態では、端末ＩＤとＬｏｃａｔｏｒの対応関係を保持するマップテーブルにおいて、宛先端末のＩＤに加えて、ユーザを識別する何らかのＩＤをキーに加えることで、宛先端末のＩＤ（すなわち宛先アドレス）が同一であっても、ユーザ毎に付与されるＩＤが異なれば、別のＬｏｃａｔｏｒを引けるようにする。これにより、ユーザの契約情報等に基づいて、異なるサービス網へパケットを転送できるようになる。ユーザを識別するＩＤとしては、例えば、ユーザ端末に割り当てる端末ＩＤ（ＩＰアドレス）が利用できる。
【００１８】
また、ユーザ毎にマップテーブルの設定が異なるため、マップテーブルを生成する手間が増大する可能性がある。これに対して、ユーザの契約情報に応じたマップテーブルを、ユーザ端末にアドレスを割り当てるＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバと、ユーザの契約情報等を保持するユーザ契約情報サーバを連携させることで、自動的に設定することとしている。
【００１９】
本実施の形態では、ユーザを識別するＩＤとして、ユーザ端末に割り当てる端末ＩＤ（具体的には、キャリア網内で利用するＩＰアドレス）を利用することとするが、ユーザを識別するＩＤはこれに限定されるものではない。
【００２０】
（システム構成）
図１に、本実施に形態におけるネットワーク構成を示す。図１に示すように、本実施の形態に係るネットワークは、キャリアのＩＰ網１に、サービス網として、２つのＩＳＰ（ＩＳＰ＃Ａ（２Ａ）、ＩＳＰ＃Ｂ（２Ｂ））、１つのＶＰＮサイト３、及び１つのＣＳＰ（Ｃｏｎｔｅｎｔｓ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）４が、それぞれゲートウェイルータ７（ＧＷ１〜ＧＷ４）を介して接続されて構成されている。また、それぞれのＩＳＰ（２Ａ、２Ｂ）は、インターネット５と接続されている。
【００２１】
また、ユーザＡのユーザ端末１１ＡとユーザＢのユーザ端末１１Ｂが、それぞれエッジルータ６（Ｅ１、Ｅ２）を介して接続されている。本実施の形態では、ユーザＡとユーザＢの二人のユーザがいることを仮定する。ユーザＡは、インターネット接続サービスとしてＩＳＰ＃Ａと、リモートアクセスサービスの接続先としてＶＰＮ＃１と契約しており、ユーザＢはＩＳＰ＃Ｂとのみ契約しているものとする。
【００２２】
エッジルータ６（Ｅ１、Ｅ２）やゲートウェイルータ７（ＧＷ１〜ＧＷ４）は、通常のルータ１２（Ｒ１〜Ｒ３）を介してＩＰ網１内で相互に接続されている。さらに、ＩＰ網１には、ＩＤとＬｏｃａｔｏｒの対応表を作成・管理するマップサーバ８、ユーザ端末にＩＰアドレスを割り当てるＤＨＣＰサーバ９、及びユーザ毎の契約情報を保持しているユーザ契約情報サーバ１０が接続されている。マップサーバ８、ＤＨＣＰサーバ９、及びユーザ契約情報サーバ１０は互いに通信可能である。本実施の形態におけるＬｏｃａｔｏｒは、例えばＩＰアドレスである。また、Ｌｏｃａｔｏｒは、サービス網のＩＰ網上での位置を示す位置情報である。
【００２３】
なお、マップサーバ８、ＤＨＣＰサーバ９、及びユーザ契約情報サーバ１０は、それぞれ、その機能から、対応表生成格納装置、ＩＤ割り当て装置、契約情報格納装置と呼んでもよい。
【００２４】
次に、図２〜図４を用いて、マップサーバ８、ＤＨＣＰサーバ９、ユーザ契約情報サーバ１０が保持するテーブルの構成例を説明する。
【００２５】
図２は、マップサーバ８が保持するマップテーブル１００である。マップテーブル１００は、ユーザを識別するＩＤである送信元ＩＤ１０１、及び宛先ＩＤ１０２の組み合わせと、宛先端末に到達するために経由するサービス網を示すＬｏｃａｔｏｒ１０３の対応関係を保持している。
【００２６】
図３は、ＤＨＣＰサーバ９が保持するＤＨＣＰサーバテーブル２００である。ＤＨＣＰサーバ９は、ＩＰ網１に接続してきたユーザ端末にＩＤを割り当てるサーバである。ＤＨＣＰは一般に広く利用されているプロトコルであり、ここで示すＤＨＣＰサーバテーブル２００の構成も、一般的なＤＨＣＰサーバが保持するテーブルと同じである。ＤＨＣＰサーバテーブル２００は、ユーザ端末に割り当てたＩＤ２０１と、そのＩＤを割り当てたユーザ端末のユーザを一意に識別する文字列であるユーザ名２０２、及び、そのユーザ端末が接続されているエッジルータのＬｏｃａｔｏｒ２０３を保持する。ユーザ端末にＩＤを割り当てるたびに、これらの情報が１行ずつ追加されていく。
【００２７】
図４は、ユーザ契約情報サーバ１０が保持するユーザ契約情報テーブル３００である。ユーザ毎に契約しているサービス網（ＩＳＰ、ＶＰＮ拠点など）の情報が保持されているテーブルである。ユーザ契約情報テーブル３００は、ユーザ名３０１と、そのユーザが契約しているサービス網のリストであるサービス網リスト３０２、ユーザが契約しているそれぞれのサービス網に接続されているＧＷのＬｏｃａｔｏｒのリストであるＧＷのＬｏｃａｔｏｒリスト３０３から構成される。ユーザ契約情報テーブル３００は、ユーザがサービス網との契約を追加したり、削除したりした場合に更新されるものである。
【００２８】
図５を用いて、エッジルータ６及びゲートウェイルータ７の構成例を説明する。なお、エッジルータ６及びゲートウェイルータ７は基本的に同じ構成であるため、図５には、エッジルータ６及びゲートウェイルータ７のいずれにも使用できるルータ４００の構成が示されている。なお、ルータ４００はパケット転送装置と呼んでもよい。
【００２９】
ルータ４００は、通常のルータと同様に、ネットワークに接続される複数のインタフェース４０１と、パケットの宛先に応じて転送先のインタフェースへ転送するスイッチ４０３を保持する。インタフェース４０１の内部には、ルーティングテーブルのコピーであるフォワーディングテーブル４０２を保持する。また、他のルータとの間で、ＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ）やＢＧＰ（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）などのルーティングプロトコルを通じて取得した経路情報を保持するルーティングテーブル４０４を保持する点も一般のルータと同様である。
【００３０】
一方、本発明に係る技術に特有の構成として、マップキャッシュ４０５を保持している。マップキャッシュ４０５は、マップサーバ８から取得したＩＤとＬｏｃａｔｏｒの対応関係を一時的に保持するキャッシュテーブルである。後述するように、パケットを転送する際に、ＩＤに対応したＬｏｃａｔｏｒを取得するため、両者の対応関係を保持するマップサーバ８に問い合わせる必要があるが、一般に同一の宛先へのパケットは連続して転送されることが多いため、パケットを１つ転送するたびにマップサーバ８に問い合わせるのは非効率である。一度問い合わせたものについては、ローカルに保持しておくことが望ましいため、ルータ４００（すなわち、エッジルータ６及びゲートウェイルータ７）の内部にマップキャッシュ４０５を保持する構成をとる。なお、マップキャッシュ４０５は、マップサーバ８に問い合わせた内容を一時的に保持するためのものであるため、その構成はマップテーブル１００と同様である。テーブルの内容としては、マップサーバ８がネットワーク全体のＩＤとＬｏｃａｔｏｒの対応関係すべてを保持するのに対して、マップキャッシュ４０５は、そのエッジルータ６やゲートウェイルータ７が問い合わせた内容のみを保持するため、マップサーバ８が保持するマップテーブル１００のサブセットとなる。
【００３１】
図６に、マップサーバ８の機能構成図を示す。図６に示すようにマップサーバ８は、マップテーブル格納部８１、契約情報取得部８２、マップテーブルエントリ作成部８３、マップテーブル検索部８４を備える。
【００３２】
マップテーブル格納部８１は、マップテーブル１００を格納するメモリ等の記憶手段である。契約情報取得部８２は、ＤＨＣＰサーバ９からマップ生成リクエストを受信したことに応じて、ユーザ契約情報サーバ１０に契約情報リクエストを送信することにより、ユーザ契約情報サーバ１０から契約情報を取得する機能部である。マップテーブルエントリ作成部８３は、契約情報取得部８２が取得した契約情報等を用いてマップテーブルエントリを作成する機能部である。マップテーブル検索部８４は、エッジルータ６やゲートウェイルータ７からマップ解決リクエストを受信したことに応じて、マップテーブル１００を検索し、該当するＬｏｃａｔｏｒを返す機能部である。
【００３３】
マップサーバ８は、ＣＰＵ、メモリ、通信装置等から構成されるコンピュータに、各機能部に対応したプログラムを実行させることにより実現可能である。すなわち、マップサーバ８の各部が有する機能は、当該マップサーバ８を構成するコンピュータに内蔵されるＣＰＵやメモリなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【００３４】
ＤＨＣＰサーバ９は、通常のＤＨＣＰサーバの機能に加えて、マップ生成リクエストをマップサーバ８に送信する機能を有する。ユーザ契約情報サーバ１０は、ユーザ名を含む契約情報リクエストをマップサーバ８から受信し、ユーザ名でユーザ契約情報テーブルを検索することにより、該当ユーザの契約情報を取得して、契約情報リプライをマップサーバ８に返す機能を有する。
【００３５】
（システムの動作）
以下、上述した構成を有するシステムの動作を説明する。
【００３６】
＜マップテーブル生成手順＞
まず、図７を用いて、マップサーバ８においてマップテーブル１００が生成されるまでの手順を説明する。なお、ここでは、ユーザＡのユーザ端末１１ＡがＩＰ網１に接続してきたと仮定し、ユーザＡのマップテーブルのエントリを生成する手順を説明する。
【００３７】
まず、ユーザ端末１１Ａは、ＩＰ網１に接続すると、ＩＤの割り当てをＩＰ網１に要求するために、ＤＨＣＰリクエストを送信する（ステップＳ１１）。ＤＨＣＰリクエストは、エッジルータＥ１を経由してＤＨＣＰサーバ９に転送される。なお、ここでは、ＤＨＣＰリクエストにユーザ名「ユーザＡ」が含まれているものとする。
【００３８】
ＤＨＣＰサーバ９では、ユーザ端末１１Ａに対するＩＤとして、ａを割り当て、ＤＨＣＰサーバ９のテーブル２００に、ユーザＡにＩＤ＝ａを割り当て、さらにそのユーザ端末１１ＡがエッジルータＥ１に収容されていることを記録する。図３では、１行目のエントリが該当する。その後、ＤＨＣＰサーバ９は、ユーザ端末１１ＡにＤＨＣＰリプライを返送する（ステップＳ１２）。これで、ユーザ端末１１Ａに、ＩＤとしてａが割り当てられた。
【００３９】
次に、ＤＨＣＰサーバ９は、マップサーバ８に対して、ユーザＡ（ユーザ端末１１Ａ）にＩＤ＝ａを割り当てたことを通知し、マップテーブルの生成を要求するマップ生成リクエストを送信する（ステップＳ１３）。マップサーバ８は、マップ生成リクエストを受信すると、ユーザ契約情報サーバ１０に対して、ユーザＡが契約するサービス網のリストを送信するように要求する契約情報リクエストを送信する（ステップＳ１４）。
【００４０】
ユーザ契約情報サーバ１０は、契約情報リクエストを受信すると、ユーザ契約情報テーブル３００を参照し、ユーザＡが契約しているサービス網のリスト（サービス網の識別情報のリスト）として（ＩＳＰ＃１、ＶＰＮ＃１）を、それらのサービス網が接続されているゲートウェイのＬｏｃａｔｏｒリストとして（ＧＷ１、ＧＷ３）を取得して、マップサーバ８に対して、契約情報リプライとして返送する（ステップＳ１５）。
【００４１】
マップサーバ８は、契約情報リプライを受信した段階で、マップテーブル１００の生成に必要な情報がそろうため、マップテーブルエントリ作成部８３により、マップテーブル１００のエントリを生成する（ステップＳ１６）。具体的には、まずユーザＡが契約しているＩＳＰ＃Ａへの通信を実現するエントリとして、送信元ＩＤ＝ａ、宛先ＩＤ＝ａｎｙ、Ｌｏｃａｔｏｒ＝ＧＷ１を設定する（図２の１行目のエントリ）。ここで、宛先ＩＤ＝ａｎｙというのは、あらゆるＩＤに合致することを意味する。契約するＩＳＰに対する通信では、ＩＳＰ内の宛先に加えて、インターネットのあらゆる宛先に対する通信が行われるため、マップテーブルにおいて、送信元ＩＤが一致し、宛先ＩＤに一致するエントリがない全ての通信をＩＳＰに転送する必要がある。そのため、ＩＳＰに対する通信では宛先ＩＤ＝ａｎｙを設定する。
【００４２】
次に、ユーザＡが契約するＶＰＮ＃１への通信を実現するエントリとして、送信元ＩＤ＝ａ、宛先ＩＤ＝ｄ、Ｌｏｃａｔｏｒ＝ＧＷ３を設定する（図２の２行目のエントリ）。ここで、宛先ＩＤ＝ｄはＶＰＮ＃１内で利用されているＩＤのセットを示す。一般に、ＶＰＮ拠点内ではプライベートアドレスが利用されるため、ｄはプライベートアドレス空間を指し示す値（たとえば、ＩＰｖ４アドレスでは、１０．０．０．０／８がプライベート空間を示す）を設定する。ただし、プライベートアドレス空間以外のＩＤが利用されていた場合でも、予めマップサーバ８にＶＰＮ拠点と、そのＶＰＮ拠点内で利用されているＩＤの対応を保持しておけば、どのようなＩＤでも設定することが可能である。
【００４３】
なお、サービス網毎に、どのような宛先ＩＤを設定するかを示す情報はマップサーバ８において予め保持されているものとする。
【００４４】
さらに、マップサーバ８は、他のゲートウェイルータ７やエッジルータ６から、ユーザ端末１１Ａ宛てのパケットを転送するために、送信元ＩＤ＝ａｎｙ、宛先ＩＤ＝ａ、Ｌｏｃａｔｏｒ＝Ｅ１のエントリを生成する（図２の３行目のエントリ）。
【００４５】
＜パケット送信手順＞
次に、図８を用いて、ユーザ端末１１Ａがインターネット５上にある宛先ＩＤ（図８ではＤＩＤ）がｘの端末にパケットを送信する手順を説明する。
【００４６】
まず、ユーザ端末１１Ａは、通常のＩＰパケットの転送と同じように、ＩＰヘッダの送信元アドレス（図８ではＳＩＤ）に自身のＩＤであるａを、宛先アドレス（ＤＩＤ）にｘをセットしてパケットを送信する（ステップＳ２１）。
【００４７】
パケットを受信したエッジルータＥ１は、自身のマップキャッシュ４０５内に、送信元ＩＤ＝ａ、宛先ＩＤ＝ｘに対応するＬｏｃａｔｏｒのアドレスが保存されているかを検索する（ステップＳ２２）。ここでは、キャッシュ内の該当するＬｏｃａｔｏｒが保存されていないと仮定し、マップサーバ８に問い合わせを行う。すなわち、エッジルータＥ１は、マップサーバ８に、送信元ＩＤ＝ａ及び宛先ＩＤ＝ｘを含むマップ解決リクエストを送信し（ステップＳ２３）、送信元ＩＤ＝ａ、宛先ＩＤ＝ｘに対応するＬｏｃａｔｏｒを問い合わせる。
【００４８】
マップ解決リクエストを受信したマップサーバ８は、マップテーブル検索部８４により、マップテーブル１００を、送信元ＩＤ＝ａ、宛先ＩＤ＝ｘで検索する（ステップＳ２４）。ここでは、完全に一致するエントリは存在しないが、送信元ＩＤ＝ａ、宛先ＩＤ＝ａｎｙのエントリ（図２の１行目のエントリ）が該当するため、その対応するＬｏｃａｔｏｒとしてＧＷ１を、マップ解決リプライとして、エッジルータＥ１に返送する（ステップＳ２５）。なお、宛先ＩＤ＝ａｎｙ以外のエントリで該当するエントリがある場合は、そのエントリが優先される。例えば、図２の２行目のエントリが該当する場合は、ＬｏｃａｔｏｒとしてＧＷ３が返送される。
【００４９】
エッジルータＥ１は、該当するＬｏｃａｔｏｒが得られたため、ＩＤとの対応関係をマップキャッシュ４０５に記録する。ここでは、送信元ＩＤ＝ａ、宛先ＩＤ＝ａｎｙ、Ｌｏｃａｔｏｒ＝ＧＷ１を記録する。その後、ユーザ端末１１Ａから送信されてきたパケットに、宛先Ｌｏｃａｔｏｒ（図８ではＤＬｏｃ）としてＧＷ１を、送信元Ｌｏｃａｔｏｒ（図８ではＳＬｏｃ）としてエッジルータＥ１自身のＬｏｃａｔｏｒをセットしたヘッダを付与して、送信する（ステップＳ２６）。
【００５０】
ＩＰ網１内は、エッジルータＥ１で付与された外側のヘッダのみを参照してＩＰパケットが転送される。ここでは、通常のＩＰルーティングに従う転送が行われる。例えば、エッジルータ６でもゲートウェイルータ７でもない通常のルータ１２は、ユーザ端末のＩＤは意識せず、エッジルータ６で付与されたヘッダに記載されるＬｏｃａｔｏｒのみを参照して転送処理を行う。なお、ＩＰ網１内での各Ｌｏｃａｔｏｒ（ＧＷ１など）への到達性は、通常のルーティングプロトコルを通じて取得するものとする。これらは、エッジルータ６、ゲートウェイルータ７、通常のルータ１２が保持するルーティングテーブルに保持されている。
【００５１】
ゲートウェイルータＧＷ１は、転送されてきたパケットを受信すると、そのパケットのヘッダのＤＬｏｃを参照し、自分宛てのパケットかどうかをチェックする。そのうえで、自分宛てのパケットであれば、外側のヘッダを外し、サービス網（この場合はＩＳＰ＃１）にパケットを送信する（ステップＳ２７）。
【００５２】
インターネット（ＩＳＰ＃１経由）やＶＰＮ＃１からユーザ端末１１Ａ宛てのパケットの転送も、同様に行われる。各ゲートウェイルータ７が、マップサーバ８に宛先ＩＤ＝ａ宛てのＬｏｃａｔｏｒを問い合わると、図２の３行目のエントリが該当し、Ｌｏｃａｔｏｒ＝Ｅ１が返送されることにより、ゲートウェイルータ７からエッジルータＥ１にパケットが転送される。また、図１のユーザ端末１１Ｂの通信に関しても、ユーザ端末１１Ａの通信と同様である。
【００５３】
（実施の形態の効果）
通常のＬＩＳＰでは宛先ＩＤのみからＬｏｃａｔｏｒを取得するが、上述したように本実施の形態では、ユーザを識別するＩＤ（本実施の形態では、ユーザ端末に割り当てたＩＤ）もキーとして利用することで、ユーザの契約状況に応じたサービス網へのパケット転送を実現している。
【００５４】
これにより、従来のＬＩＳＰでは実現できなかった、ユーザの契約情報に基づいてキャリアのＩＰ網内で、適切なサービス網へパケットを転送することが可能となる。また、ユーザの契約情報をサーバに保持しておくことで、ユーザがＩＰ網に接続してきたことを契機として、自動的にマップサーバのエントリを生成することとしたので、手動でマップテーブルを生成する手間が省ける。
【００５５】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００５６】
１ ＩＰ網
２Ａ、２Ｂ ＩＳＰ
３ ＶＰＮ
４ ＣＳＰ
５ インターネット
６ エッジルータ
７ ゲートウェイルータ
８ マップサーバ
８１ マップテーブル格納部
８２ 契約情報取得部
８３ マップテーブルエントリ作成部
８４ マップテーブル検索部
９ ＤＨＣＰサーバ
１０ ユーザ契約情報サーバ
１００ マップテーブル
２００ ＤＨＣＰサーバテーブル
３００ ユーザ契約情報テーブル
４００ ルータ
４０１ インタフェース
４０２ フォワーディングテーブル
４０３ スイッチ
４０４ ルーティングテーブル
４０５ マップキャッシュ
【特許請求の範囲】
【請求項１】
複数のサービス網を収容するＩＰ網において、あるユーザのユーザ端末と当該ユーザが契約するサービス網との間でパケット通信を行うためのパケット通信システムであって、
前記ユーザを識別するＩＤである送信元ＩＤと、前記ユーザ端末の通信相手となる端末のＩＤである宛先ＩＤと、前記サービス網の前記ＩＰ網上での位置を示す位置情報とを対応付けて保持する対応表を生成し、格納する対応表生成格納装置と、
前記ユーザのユーザ名と対応付けて、当該ユーザが契約するサービス網の情報を格納した契約情報格納装置と、
前記ユーザ端末と接続されるパケット転送装置と、を備え、
前記対応表生成格納装置は、前記ユーザのユーザ名と前記送信元ＩＤとを含む対応表生成要求を受信したことに応じて、前記契約情報格納装置から、前記ユーザ名に対応するサービス網の識別情報と当該サービス網の位置情報を取得し、前記送信元ＩＤ、当該サービス網における宛先ＩＤ、及び当該サービス網の位置情報とを対応付けて前記対応表に記録し、
前記パケット転送装置は、前記ユーザ端末から、前記送信元ＩＤ、及び前記宛先ＩＤを含むパケットを受信したときに、当該送信元ＩＤ及び宛先ＩＤに対応するサービス網の位置情報を前記対応表生成格納装置から取得し、取得した位置情報を宛先としたヘッダを付加して前記パケットを前記ＩＰ網に転送する
ことを特徴とするパケット通信システム。
【請求項２】
前記パケット通信システムは、前記送信元ＩＤを前記ユーザ端末に割り当てるＩＤ割り当て装置を備え、
前記ユーザ端末が前記ＩＤ割り当て装置に対してＩＤ割り当て要求を送信し、当該ＩＤ割り当て要求を受信したＩＤ割り当て装置は、前記ユーザ端末に対して前記送信元ＩＤの割り当てを行うとともに、前記対応表生成格納装置に対して前記対応表生成要求を送信する
ことを特徴とする請求項１に記載のパケット通信システム。
【請求項３】
前記ＩＤ割り当て装置はＤＨＣＰサーバであり、前記送信元ＩＤとして、前記ユーザ端末にＩＰアドレスを割り当てることを特徴とする請求項１又は２に記載のパケット通信システム。
【請求項４】
前記パケット転送装置は、前記対応表生成格納装置から取得した前記位置情報を、前記送信元ＩＤ及び前記宛先ＩＤとともに記憶手段に保持し、前記パケットの受信以降に、当該パケットと同一の送信元ＩＤ及び宛先ＩＤを持つパケットを受信した場合に、前記記憶手段に保持した位置情報を用いて転送を行う
ことを特徴とする請求項１ないし３のうちいずれか１項に記載のパケット通信システム。
【請求項１】
複数のサービス網を収容するＩＰ網において、あるユーザのユーザ端末と当該ユーザが契約するサービス網との間でパケット通信を行うためのパケット通信システムであって、
前記ユーザを識別するＩＤである送信元ＩＤと、前記ユーザ端末の通信相手となる端末のＩＤである宛先ＩＤと、前記サービス網の前記ＩＰ網上での位置を示す位置情報とを対応付けて保持する対応表を生成し、格納する対応表生成格納装置と、
前記ユーザのユーザ名と対応付けて、当該ユーザが契約するサービス網の情報を格納した契約情報格納装置と、
前記ユーザ端末と接続されるパケット転送装置と、を備え、
前記対応表生成格納装置は、前記ユーザのユーザ名と前記送信元ＩＤとを含む対応表生成要求を受信したことに応じて、前記契約情報格納装置から、前記ユーザ名に対応するサービス網の識別情報と当該サービス網の位置情報を取得し、前記送信元ＩＤ、当該サービス網における宛先ＩＤ、及び当該サービス網の位置情報とを対応付けて前記対応表に記録し、
前記パケット転送装置は、前記ユーザ端末から、前記送信元ＩＤ、及び前記宛先ＩＤを含むパケットを受信したときに、当該送信元ＩＤ及び宛先ＩＤに対応するサービス網の位置情報を前記対応表生成格納装置から取得し、取得した位置情報を宛先としたヘッダを付加して前記パケットを前記ＩＰ網に転送する
ことを特徴とするパケット通信システム。
【請求項２】
前記パケット通信システムは、前記送信元ＩＤを前記ユーザ端末に割り当てるＩＤ割り当て装置を備え、
前記ユーザ端末が前記ＩＤ割り当て装置に対してＩＤ割り当て要求を送信し、当該ＩＤ割り当て要求を受信したＩＤ割り当て装置は、前記ユーザ端末に対して前記送信元ＩＤの割り当てを行うとともに、前記対応表生成格納装置に対して前記対応表生成要求を送信する
ことを特徴とする請求項１に記載のパケット通信システム。
【請求項３】
前記ＩＤ割り当て装置はＤＨＣＰサーバであり、前記送信元ＩＤとして、前記ユーザ端末にＩＰアドレスを割り当てることを特徴とする請求項１又は２に記載のパケット通信システム。
【請求項４】
前記パケット転送装置は、前記対応表生成格納装置から取得した前記位置情報を、前記送信元ＩＤ及び前記宛先ＩＤとともに記憶手段に保持し、前記パケットの受信以降に、当該パケットと同一の送信元ＩＤ及び宛先ＩＤを持つパケットを受信した場合に、前記記憶手段に保持した位置情報を用いて転送を行う
ことを特徴とする請求項１ないし３のうちいずれか１項に記載のパケット通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１３−３８６１１（Ｐ２０１３−３８６１１Ａ）
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願番号】特願２０１１−１７３４１３（Ｐ２０１１−１７３４１３）
【出願日】平成２３年８月８日（２０１１．８．８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願日】平成２３年８月８日（２０１１．８．８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]