複数のサービス網を収容するIP網において、あるユーザのユーザ端末と当該ユーザが契約するサービス網との間でパケット通信を行うためのパケット通信システムであって、前記ユーザを識別するIDである送信元IDと、前記ユーザ端末の通信相手となる端末のIDである宛先IDと、前記サービス網の前記IP網上での位置を示す位置情報とを対応付けて保持する対応表を生成し、格納する対応表生成格納装置と、前記ユーザのユーザ名と対応付けて、当該ユーザが契約するサービス網の情報を格納した契約情報格納装置と、前記ユーザ端末と接続されるパケット転送装置と、を備え、前記対応表生成格納装置は、前記ユーザのユーザ名と前記送信元IDとを含む対応表生成要求を受信したことに応じて、前記契約情報格納装置から、前記ユーザ名に対応するサービス網の識別情報と当該サービス網の位置情報を取得し、前記送信元ID、当該サービス網における宛先ID、及び当該サービス網の位置情報とを対応付けて前記対応表に記録し、前記パケット転送装置は、前記ユーザ端末から、前記送信元ID、及び前記宛先IDを含むパケットを受信したときに、当該送信元ID及び宛先IDに対応するサービス網の位置情報を前記対応表生成格納装置から取得し、取得した位置情報を宛先としたヘッダを付加して前記パケットを前記IP網に転送することを特徴とするパケット通信システム。前記パケット通信システムは、前記送信元IDを前記ユーザ端末に割り当てるID割り当て装置を備え、前記ユーザ端末が前記ID割り当て装置に対してID割り当て要求を送信し、当該ID割り当て要求を受信したID割り当て装置は、前記ユーザ端末に対して前記送信元IDの割り当てを行うとともに、前記対応表生成格納装置に対して前記対応表生成要求を送信することを特徴とする請求項1に記載のパケット通信システム。前記ID割り当て装置はDHCPサーバであり、前記送信元IDとして、前記ユーザ端末にIPアドレスを割り当てることを特徴とする請求項1又は2に記載のパケット通信システム。前記パケット転送装置は、前記対応表生成格納装置から取得した前記位置情報を、前記送信元ID及び前記宛先IDとともに記憶手段に保持し、前記パケットの受信以降に、当該パケットと同一の送信元ID及び宛先IDを持つパケットを受信した場合に、前記記憶手段に保持した位置情報を用いて転送を行うことを特徴とする請求項1ないし3のうちいずれか1項に記載のパケット通信システム。しかし、従来提案されているLISPでは、次のような課題がある。まず、LISPは、本来、インターネットにおいて、端末そのものを示すIDと、端末が存在するサイトを示すLocatorを分離し、インターネット内の経路制御をLocatorのみで実現することで、インターネット内の経路表の削減を狙った技術である。そのため、宛先のIDから、その宛先端末が存在するサイトを示すLocatorを求める場合には、通常のIPルーティングと同様に、宛先端末を示すIDをキーとしてLocatorを得る方法が採用されている。この手法は、全体が単一のIPアドレス空間であるインターネットには適用可能である。しかし、リモートアクセスサービスにおけるVPN拠点のように同一のプライベートアドレスが複数のサイトに存在したり、宛先がインターネット上のアドレスであっても、ユーザが契約するISPを経由して通信させたりする必要のあるキャリアIP網では、ユーザの契約するISPに応じて経路が変わるため、必ずしも宛先端末のIDから、サイト=サービス網を示すLocatorが一意に定まるわけではない。そのため、従来のLISPをそのまま適用することができない。また、インターネットでは、全てのユーザに対して、あらゆるサイトへのIP到達性を一律に提供すればよいため、LISPには特定のサイトへのアクセスを制限するような機能はない。一方、キャリアIP網では、ユーザごとに契約するISPや所属するVPN拠点などが異なり、契約していないサービス網への通信を制限する機能が必要であるため、単純に従来のLISPを適用することはできない。本発明は上記の点に鑑みてなされたものであり、キャリアのIP網内で、ユーザ端末から送信されたパケットを、ユーザの契約情報に基づいて適切なサービス網へ転送することを可能とした技術を提供することを目的とする。上記の課題を解決するために、本発明は、複数のサービス網を収容するIP網において、あるユーザのユーザ端末と当該ユーザが契約するサービス網との間でパケット通信を行うためのパケット通信システムであって、前記ユーザを識別するIDである送信元IDと、前記ユーザ端末の通信相手となる端末のIDである宛先IDと、前記サービス網の前記IP網上での位置を示す位置情報とを対応付けて保持する対応表を生成し、格納する対応表生成格納装置と、前記ユーザのユーザ名と対応付けて、当該ユーザが契約するサービス網の情報を格納した契約情報格納装置と、前記ユーザ端末と接続されるパケット転送装置と、を備え、前記対応表生成格納装置は、前記ユーザのユーザ名と前記送信元IDとを含む対応表生成要求を受信したことに応じて、前記契約情報格納装置から、前記ユーザ名に対応するサービス網の識別情報と当該サービス網の位置情報を取得し、前記送信元ID、当該サービス網における宛先ID、及び当該サービス網の位置情報とを対応付けて前記対応表に記録し、前記パケット転送装置は、前記ユーザ端末から、前記送信元ID、及び前記宛先IDを含むパケットを受信したときに、当該送信元ID及び宛先IDに対応するサービス網の位置情報を前記対応表生成格納装置から取得し、取得した位置情報を宛先としたヘッダを付加して前記パケットを前記IP網に転送することを特徴とするパケット通信システムとして構成される。前記パケット通信システムは、前記送信元IDを前記ユーザ端末に割り当てるID割り当て装置を備え、前記ユーザ端末が前記ID割り当て装置に対してID割り当て要求を送信し、当該ID割り当て要求を受信したID割り当て装置は、前記ユーザ端末に対して前記送信元IDの割り当てを行うとともに、前記対応表生成格納装置に対して前記対応表生成要求を送信するように構成してもよい。なお、前記ID割り当て装置は例えばDHCPサーバであり、前記送信元IDとして、前記ユーザ端末にIPアドレスを割り当てることとしてもよい。また、前記パケット転送装置は、前記対応表生成格納装置から取得した前記位置情報を、前記送信元ID及び前記宛先IDとともに記憶手段に保持し、前記パケットの受信以降に、当該パケットと同一の送信元ID及び宛先IDを持つパケットを受信した場合に、前記記憶手段に保持した位置情報を用いて転送を行うようにしてもよい。本発明によれば、キャリアのIP網内で、ユーザ端末から送信されたパケットを、ユーザの契約情報に基づいて適切なサービス網へ転送することを可能とする技術が実現される。以下、図面を参照しながら本発明の実施の形態を説明する。実施の形態の概要後に詳述するように、本実施の形態では、端末IDとLocatorの対応関係を保持するマップテーブルにおいて、宛先端末のIDに加えて、ユーザを識別する何らかのIDをキーに加えることで、宛先端末のIDすなわち宛先アドレスが同一であっても、ユーザ毎に付与されるIDが異なれば、別のLocatorを引けるようにする。これにより、ユーザの契約情報等に基づいて、異なるサービス網へパケットを転送できるようになる。ユーザを識別するIDとしては、例えば、ユーザ端末に割り当てる端末IDIPアドレスが利用できる。また、ユーザ毎にマップテーブルの設定が異なるため、マップテーブルを生成する手間が増大する可能性がある。これに対して、ユーザの契約情報に応じたマップテーブルを、ユーザ端末にアドレスを割り当てるDHCPDynamicHostConfigurationProtocolサーバと、ユーザの契約情報等を保持するユーザ契約情報サーバを連携させることで、自動的に設定することとしている。本実施の形態では、ユーザを識別するIDとして、ユーザ端末に割り当てる端末ID具体的には、キャリア網内で利用するIPアドレスを利用することとするが、ユーザを識別するIDはこれに限定されるものではない。システム構成図1に、本実施に形態におけるネットワーク構成を示す。図1に示すように、本実施の形態に係るネットワークは、キャリアのIP網1に、サービス網として、2つのISPISPA2A、ISPB2B、1つのVPNサイト3、及び1つのCSPContentsServiceProvider4が、それぞれゲートウェイルータ7GW1~GW4を介して接続されて構成されている。また、それぞれのISP2A、2Bは、インターネット5と接続されている。また、ユーザAのユーザ端末11AとユーザBのユーザ端末11Bが、それぞれエッジルータ6E1、E2を介して接続されている。本実施の形態では、ユーザAとユーザBの二人のユーザがいることを仮定する。ユーザAは、インターネット接続サービスとしてISPAと、リモートアクセスサービスの接続先としてVPN1と契約しており、ユーザBはISPBとのみ契約しているものとする。エッジルータ6E1、E2やゲートウェイルータ7GW1~GW4は、通常のルータ12R1~R3を介してIP網1内で相互に接続されている。さらに、IP網1には、IDとLocatorの対応表を作成管理するマップサーバ8、ユーザ端末にIPアドレスを割り当てるDHCPサーバ9、及びユーザ毎の契約情報を保持しているユーザ契約情報サーバ10が接続されている。マップサーバ8、DHCPサーバ9、及びユーザ契約情報サーバ10は互いに通信可能である。本実施の形態におけるLocatorは、例えばIPアドレスである。また、Locatorは、サービス網のIP網上での位置を示す位置情報である。なお、マップサーバ8、DHCPサーバ9、及びユーザ契約情報サーバ10は、それぞれ、その機能から、対応表生成格納装置、ID割り当て装置、契約情報格納装置と呼んでもよい。次に、図2~図4を用いて、マップサーバ8、DHCPサーバ9、ユーザ契約情報サーバ10が保持するテーブルの構成例を説明する。図2は、マップサーバ8が保持するマップテーブル100である。マップテーブル100は、ユーザを識別するIDである送信元ID101、及び宛先ID102の組み合わせと、宛先端末に到達するために経由するサービス網を示すLocator103の対応関係を保持している。図3は、DHCPサーバ9が保持するDHCPサーバテーブル200である。DHCPサーバ9は、IP網1に接続してきたユーザ端末にIDを割り当てるサーバである。DHCPは一般に広く利用されているプロトコルであり、ここで示すDHCPサーバテーブル200の構成も、一般的なDHCPサーバが保持するテーブルと同じである。DHCPサーバテーブル200は、ユーザ端末に割り当てたID201と、そのIDを割り当てたユーザ端末のユーザを一意に識別する文字列であるユーザ名202、及び、そのユーザ端末が接続されているエッジルータのLocator203を保持する。ユーザ端末にIDを割り当てるたびに、これらの情報が1行ずつ追加されていく。図4は、ユーザ契約情報サーバ10が保持するユーザ契約情報テーブル300である。ユーザ毎に契約しているサービス網ISP、VPN拠点などの情報が保持されているテーブルである。ユーザ契約情報テーブル300は、ユーザ名301と、そのユーザが契約しているサービス網のリストであるサービス網リスト302、ユーザが契約しているそれぞれのサービス網に接続されているGWのLocatorのリストであるGWのLocatorリスト303から構成される。ユーザ契約情報テーブル300は、ユーザがサービス網との契約を追加したり、削除したりした場合に更新されるものである。図5を用いて、エッジルータ6及びゲートウェイルータ7の構成例を説明する。なお、エッジルータ6及びゲートウェイルータ7は基本的に同じ構成であるため、図5には、エッジルータ6及びゲートウェイルータ7のいずれにも使用できるルータ400の構成が示されている。なお、ルータ400はパケット転送装置と呼んでもよい。ルータ400は、通常のルータと同様に、ネットワークに接続される複数のインタフェース401と、パケットの宛先に応じて転送先のインタフェースへ転送するスイッチ403を保持する。インタフェース401の内部には、ルーティングテーブルのコピーであるフォワーディングテーブル402を保持する。また、他のルータとの間で、OSPFOpenShortestPathFirstやBGPBorderGatewayProtocolなどのルーティングプロトコルを通じて取得した経路情報を保持するルーティングテーブル404を保持する点も一般のルータと同様である。一方、本発明に係る技術に特有の構成として、マップキャッシュ405を保持している。マップキャッシュ405は、マップサーバ8から取得したIDとLocatorの対応関係を一時的に保持するキャッシュテーブルである。後述するように、パケットを転送する際に、IDに対応したLocatorを取得するため、両者の対応関係を保持するマップサーバ8に問い合わせる必要があるが、一般に同一の宛先へのパケットは連続して転送されることが多いため、パケットを1つ転送するたびにマップサーバ8に問い合わせるのは非効率である。一度問い合わせたものについては、ローカルに保持しておくことが望ましいため、ルータ400すなわち、エッジルータ6及びゲートウェイルータ7の内部にマップキャッシュ405を保持する構成をとる。なお、マップキャッシュ405は、マップサーバ8に問い合わせた内容を一時的に保持するためのものであるため、その構成はマップテーブル100と同様である。テーブルの内容としては、マップサーバ8がネットワーク全体のIDとLocatorの対応関係すべてを保持するのに対して、マップキャッシュ405は、そのエッジルータ6やゲートウェイルータ7が問い合わせた内容のみを保持するため、マップサーバ8が保持するマップテーブル100のサブセットとなる。図6に、マップサーバ8の機能構成図を示す。図6に示すようにマップサーバ8は、マップテーブル格納部81、契約情報取得部82、マップテーブルエントリ作成部83、マップテーブル検索部84を備える。マップテーブル格納部81は、マップテーブル100を格納するメモリ等の記憶手段である。契約情報取得部82は、DHCPサーバ9からマップ生成リクエストを受信したことに応じて、ユーザ契約情報サーバ10に契約情報リクエストを送信することにより、ユーザ契約情報サーバ10から契約情報を取得する機能部である。マップテーブルエントリ作成部83は、契約情報取得部82が取得した契約情報等を用いてマップテーブルエントリを作成する機能部である。マップテーブル検索部84は、エッジルータ6やゲートウェイルータ7からマップ解決リクエストを受信したことに応じて、マップテーブル100を検索し、該当するLocatorを返す機能部である。マップサーバ8は、CPU、メモリ、通信装置等から構成されるコンピュータに、各機能部に対応したプログラムを実行させることにより実現可能である。すなわち、マップサーバ8の各部が有する機能は、当該マップサーバ8を構成するコンピュータに内蔵されるCPUやメモリなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。DHCPサーバ9は、通常のDHCPサーバの機能に加えて、マップ生成リクエストをマップサーバ8に送信する機能を有する。ユーザ契約情報サーバ10は、ユーザ名を含む契約情報リクエストをマップサーバ8から受信し、ユーザ名でユーザ契約情報テーブルを検索することにより、該当ユーザの契約情報を取得して、契約情報リプライをマップサーバ8に返す機能を有する。システムの動作以下、上述した構成を有するシステムの動作を説明する。<マップテーブル生成手順>まず、図7を用いて、マップサーバ8においてマップテーブル100が生成されるまでの手順を説明する。なお、ここでは、ユーザAのユーザ端末11AがIP網1に接続してきたと仮定し、ユーザAのマップテーブルのエントリを生成する手順を説明する。まず、ユーザ端末11Aは、IP網1に接続すると、IDの割り当てをIP網1に要求するために、DHCPリクエストを送信するステップS11。DHCPリクエストは、エッジルータE1を経由してDHCPサーバ9に転送される。なお、ここでは、DHCPリクエストにユーザ名ユーザAが含まれているものとする。DHCPサーバ9では、ユーザ端末11Aに対するIDとして、aを割り当て、DHCPサーバ9のテーブル200に、ユーザAにID=aを割り当て、さらにそのユーザ端末11AがエッジルータE1に収容されていることを記録する。図3では、1行目のエントリが該当する。その後、DHCPサーバ9は、ユーザ端末11AにDHCPリプライを返送するステップS12。これで、ユーザ端末11Aに、IDとしてaが割り当てられた。次に、DHCPサーバ9は、マップサーバ8に対して、ユーザAユーザ端末11AにID=aを割り当てたことを通知し、マップテーブルの生成を要求するマップ生成リクエストを送信するステップS13。マップサーバ8は、マップ生成リクエストを受信すると、ユーザ契約情報サーバ10に対して、ユーザAが契約するサービス網のリストを送信するように要求する契約情報リクエストを送信するステップS14。ユーザ契約情報サーバ10は、契約情報リクエストを受信すると、ユーザ契約情報テーブル300を参照し、ユーザAが契約しているサービス網のリストサービス網の識別情報のリストとしてISP1、VPN1を、それらのサービス網が接続されているゲートウェイのLocatorリストとしてGW1、GW3を取得して、マップサーバ8に対して、契約情報リプライとして返送するステップS15。マップサーバ8は、契約情報リプライを受信した段階で、マップテーブル100の生成に必要な情報がそろうため、マップテーブルエントリ作成部83により、マップテーブル100のエントリを生成するステップS16。具体的には、まずユーザAが契約しているISPAへの通信を実現するエントリとして、送信元ID=a、宛先ID=any、Locator=GW1を設定する図2の1行目のエントリ。ここで、宛先ID=anyというのは、あらゆるIDに合致することを意味する。契約するISPに対する通信では、ISP内の宛先に加えて、インターネットのあらゆる宛先に対する通信が行われるため、マップテーブルにおいて、送信元IDが一致し、宛先IDに一致するエントリがない全ての通信をISPに転送する必要がある。そのため、ISPに対する通信では宛先ID=anyを設定する。次に、ユーザAが契約するVPN1への通信を実現するエントリとして、送信元ID=a、宛先ID=d、Locator=GW3を設定する図2の2行目のエントリ。ここで、宛先ID=dはVPN1内で利用されているIDのセットを示す。一般に、VPN拠点内ではプライベートアドレスが利用されるため、dはプライベートアドレス空間を指し示す値たとえば、IPv4アドレスでは、10.0.0.0/8がプライベート空間を示すを設定する。ただし、プライベートアドレス空間以外のIDが利用されていた場合でも、予めマップサーバ8にVPN拠点と、そのVPN拠点内で利用されているIDの対応を保持しておけば、どのようなIDでも設定することが可能である。なお、サービス網毎に、どのような宛先IDを設定するかを示す情報はマップサーバ8において予め保持されているものとする。さらに、マップサーバ8は、他のゲートウェイルータ7やエッジルータ6から、ユーザ端末11A宛てのパケットを転送するために、送信元ID=any、宛先ID=a、Locator=E1のエントリを生成する図2の3行目のエントリ。<パケット送信手順>次に、図8を用いて、ユーザ端末11Aがインターネット5上にある宛先ID図8ではDIDがxの端末にパケットを送信する手順を説明する。まず、ユーザ端末11Aは、通常のIPパケットの転送と同じように、IPヘッダの送信元アドレス図8ではSIDに自身のIDであるaを、宛先アドレスDIDにxをセットしてパケットを送信するステップS21。パケットを受信したエッジルータE1は、自身のマップキャッシュ405内に、送信元ID=a、宛先ID=xに対応するLocatorのアドレスが保存されているかを検索するステップS22。ここでは、キャッシュ内の該当するLocatorが保存されていないと仮定し、マップサーバ8に問い合わせを行う。すなわち、エッジルータE1は、マップサーバ8に、送信元ID=a及び宛先ID=xを含むマップ解決リクエストを送信しステップS23、送信元ID=a、宛先ID=xに対応するLocatorを問い合わせる。マップ解決リクエストを受信したマップサーバ8は、マップテーブル検索部84により、マップテーブル100を、送信元ID=a、宛先ID=xで検索するステップS24。ここでは、完全に一致するエントリは存在しないが、送信元ID=a、宛先ID=anyのエントリ図2の1行目のエントリが該当するため、その対応するLocatorとしてGW1を、マップ解決リプライとして、エッジルータE1に返送するステップS25。なお、宛先ID=any以外のエントリで該当するエントリがある場合は、そのエントリが優先される。例えば、図2の2行目のエントリが該当する場合は、LocatorとしてGW3が返送される。エッジルータE1は、該当するLocatorが得られたため、IDとの対応関係をマップキャッシュ405に記録する。ここでは、送信元ID=a、宛先ID=any、Locator=GW1を記録する。その後、ユーザ端末11Aから送信されてきたパケットに、宛先Locator図8ではDLocとしてGW1を、送信元Locator図8ではSLocとしてエッジルータE1自身のLocatorをセットしたヘッダを付与して、送信するステップS26。IP網1内は、エッジルータE1で付与された外側のヘッダのみを参照してIPパケットが転送される。ここでは、通常のIPルーティングに従う転送が行われる。例えば、エッジルータ6でもゲートウェイルータ7でもない通常のルータ12は、ユーザ端末のIDは意識せず、エッジルータ6で付与されたヘッダに記載されるLocatorのみを参照して転送処理を行う。なお、IP網1内での各LocatorGW1などへの到達性は、通常のルーティングプロトコルを通じて取得するものとする。これらは、エッジルータ6、ゲートウェイルータ7、通常のルータ12が保持するルーティングテーブルに保持されている。ゲートウェイルータGW1は、転送されてきたパケットを受信すると、そのパケットのヘッダのDLocを参照し、自分宛てのパケットかどうかをチェックする。そのうえで、自分宛てのパケットであれば、外側のヘッダを外し、サービス網この場合はISP1にパケットを送信するステップS27。インターネットISP1経由やVPN1からユーザ端末11A宛てのパケットの転送も、同様に行われる。各ゲートウェイルータ7が、マップサーバ8に宛先ID=a宛てのLocatorを問い合わると、図2の3行目のエントリが該当し、Locator=E1が返送されることにより、ゲートウェイルータ7からエッジルータE1にパケットが転送される。また、図1のユーザ端末11Bの通信に関しても、ユーザ端末11Aの通信と同様である。実施の形態の効果通常のLISPでは宛先IDのみからLocatorを取得するが、上述したように本実施の形態では、ユーザを識別するID本実施の形態では、ユーザ端末に割り当てたIDもキーとして利用することで、ユーザの契約状況に応じたサービス網へのパケット転送を実現している。これにより、従来のLISPでは実現できなかった、ユーザの契約情報に基づいてキャリアのIP網内で、適切なサービス網へパケットを転送することが可能となる。また、ユーザの契約情報をサーバに保持しておくことで、ユーザがIP網に接続してきたことを契機として、自動的にマップサーバのエントリを生成することとしたので、手動でマップテーブルを生成する手間が省ける。本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更応用が可能である。