JP5810047B2 - 通信システム、及びパケット通信方法 - Google Patents

Description

本発明は、移動体ネットワークにおける多様な通信形態の実現方式に関するものである。

現在の移動体ネットワークは、端末と、その端末が接続する先のネットワーク（宛先ネットワーク）との間で仮想的なトンネルを確立することで、端末と宛先ネットワーク間の接続性をユーザに提供している。例えば、インターネットへの接続の場合、宛先ネットワークとして、ユーザが契約しているＩＳＰに接続することになる。また、ユーザの端末が移動するのにともなって、網内のトンネルも端末の移動に追随することで、モビリティをサポートする（非特許文献１）。

一方、移動体の速度向上に伴い、単なるインターネット接続に加えて、ＣＤＮ（Contents Delivery Network）を利用したスケーラビリティの高いＶｏＤサービスや、多数のユーザへの同一コンテンツを配信するＩＰＴＶサービス、企業ユースとしてのＶＰＮ接続など、現在の固定回線と同様の用途が移動体ネットワークに求められるようになると想定される。

また、将来は、移動体ネットワークと固定ネットワークの統合が想定されており、その場合は、将来主流となる移動体ネットワークをベースとしたアーキテクチャになると考えられる。

「All-IPネットワークを実現する SAE基本制御技術」，2009年，NTTドコモテクニカルジャーナル 2009年 VOL17，No.3， http://www.nttdocomo.co.jp/corporate/technology/rd/technical_journal/bn/vol17_3 /006.html

現在の移動体ネットワークは、前述のように、端末と宛先ネットワーク間を１対１で接続することしかできないため、多対多の接続を必要とするＶＰＮサービスや、マルチキャストを利用したＩＰＴＶサービスなどを実現するには、端末が通信する可能性のある対地全てにトンネルを確立しておく必要があり、非効率である。

また、ＶＰＮサービスに代表されるキャリアのサービスでは、キャリアのネットワーク側でユーザの端末やサーバ等のアドレスや位置を管理し、ユーザ端末から送信されてきたパケットを適切にルーティングすることで、ユーザ側での煩雑なネットワーク管理が不要になるという付加価値を提供している。ところが、現在の移動体ネットワークでは、最初にユーザが指定した宛先ネットワークに接続したら、それ以降は、トンネル単位での制御しか行わないため、前述のようなネットワーク側でのルーティング機能を提供することができない。

本発明は上記の点に鑑みてなされたものであり、移動体ネットワークにおいて、１対１以外の通信形態にも対応でき、付加価値の高いサービスを提供することを可能とする技術を提供することを目的とする。

上記の課題を解決するために、本発明は、ＩＰ網のエッジに備えられる複数の通信装置を有する通信システムであって、
各通信装置配下のリソースにラベルが割り当てられており、
パケット送信元のリソースからパケットを受信する送信元の通信装置が、
前記パケットに付与された宛先のリソースのラベルに対応する宛先の通信装置を識別する識別手段と、
識別された宛先の通信装置に向けて前記パケットを送信する手段と、を備え、
前記ＩＰ網を介して前記パケットを受信する宛先の通信装置が、
前記パケットに付与されたラベルを除去し、ラベルの除去されたパケットを前記宛先のリソースに転送する手段を備える通信システムであり、
前記送信元の通信装置は、パケットの宛先アドレスと、当該宛先アドレスを持つ装置が収容されているエッジの通信装置の識別情報とを対応付けたテーブルを格納した格納手段を備え、
前記宛先のリソースが、複数のエッジの通信装置に対応付けられている場合において、前記送信元の通信装置の識別手段は、前記格納手段を参照することにより、前記パケットの宛先アドレスに対応するエッジの通信装置を前記宛先の通信装置として識別する
ことを特徴とする通信システムとして構成される。

前記通信システムは、リソースと、当該リソースを収容するエッジの通信装置の識別情報とを対応付けたテーブルを格納するテーブル格納手段を備え、前記送信元の通信装置の識別手段は、前記宛先のリソースを収容するエッジの通信装置の識別情報を前記テーブル格納手段から取得することにより、前記宛先の通信装置を識別するようにしてもよい。

また、前記宛先のリソースが別の場所に移動した場合に、前記テーブル格納手段において、移動前のリソースを収容するエッジの通信装置の識別情報が、移動後のリソースを収容するエッジの通信装置の識別情報に書き換えられ、前記送信元の通信装置の識別手段は、移動後のリソースを収容するエッジの通信装置の識別情報を前記テーブル格納手段から取得することにより、リソースが別の場所に移動した後の宛先の通信装置を識別するようにしてもよい。

前記通信装置は、例えば前記ＩＰ網におけるエッジルータであり、前記リソースは、例えばサービス網又は端末である。

また、本発明は、通信システムにおいて実行されるパケット通信方法として構成することもできる。

本発明によれば、従来の移動体ネットワークでは実現が難しかった１対１以外の通信形態にも対応することができるようになり、移動体ネットワーク内で、ＶＰＮサービスやクラウドサービスなどの付加価値の高いサービスを提供することができるようになる。

本発明の実施の形態に係るネットワーク構成を示す図である。 サービス網・エッジ対応テーブルの構成例を示す図である。 サービス網・ラベル対応テーブルの構成例を示す図である。 ユーザ端末が保持する宛先テーブルの構成例を示す図である。 エッジルータの機能構成図である。 サービス網インスタンスの例を示す図である。 本発明の実施の形態に係る通信の一例（1対１、ＣＳＰへのアクセス例）を示す図である。 本発明の実施の形態に係る通信の一例（多地点間通信、ＶＰＮへのアクセス例）を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

＜実施の形態の概要＞
本実施の形態では、端末が送受信するパケットに、送信元と宛先のリソースを示す識別子（ラベル）を付与することで、そのラベルに応じたネットワーク内でのルーティング等の高度な制御を実現する。これにより、端末と宛先ネットワークの１対１の接続に加え、多対多の接続を必要とするＶＰＮサービスや、時々刻々とコンテンツの場所が変わるＣＤＮのようにネットワーク側で適切にパケットをルーティングしなくては実現できないようなサービスも容易に実現できるようになる。ここで、送信元と宛先のリソースとは、ネットワーク側でルーティングの制御を分離したい単位で決めればよい。例えば、１対１の接続では宛先ネットワーク、ＶＰＮサービスではＶＰＮを契約しているユーザ企業単位などである。

＜システム構成＞
以降、本発明の実施の形態を詳細に説明する。本実施の形態では、ラベルで示されるリソースとして、宛先ネットワーク（以下、サービスを提供する網という意味で「サービス網」と呼ぶ）を割り当てる。

図１に、本実施の形態に係るネットワーク構成を示す。図１に示すネットワーク構成において、キャリアのＩＰ網１は、サービス網（宛先ＮＷ）として、ＩＳＰ２、ＣＳＰ３（Contents Service Provider）、ＶＰＮ４に接続されている。ＶＰＮ４には、拠点Ａと拠点Ｂの二つの拠点がある。また、ＩＳＰ２は、インターネット５に接続されている。

各サービス網は、それぞれエッジルータ６（Ｅ１１〜Ｅ１４）によって、ＩＰ網１と接続されている。また、別のエッジルータ６（Ｅ１、Ｅ２）の配下には、ユーザ端末１０が接続されている。各エッジルータ６は、ＩＰ網１内に配備されたルータ１２によって接続されている。なお、各ユーザ端末１０は、宛先テーブル１１を保持する。

更に、各サービス網と、そのサービス網が接続されているエッジの対応関係を保持するサービス網・エッジ対応テーブル８と、サービス網と、そのサービス網の識別子であるラベル値を保持するサービス網・ラベル対応テーブル９が網内に存在する。

サービス網・エッジ対応テーブル８とサービス網・ラベル対応テーブル９は、例えば、ＩＰ網１におけるテーブル格納装置であるデータベースサーバに備えられる。サービス網・エッジ対応テーブル８とサービス網・ラベル対応テーブル９は別々のテーブル格納装置に備えられていてもよい。

次に、図２〜図４を用いて、各テーブルの構成を説明する。

図２は、サービス網・エッジ対応テーブルの構成例を示す図である。サービス網・エッジ対応テーブルは、サービス網１０１と、そのサービス網が収容されているエッジルータを示すエッジ１０２、そのエッジの識別子を示すエッジＩＤ１０３により構成され、ＩＰ網１に接続されるサービス網と、そのサービス網が接続されているエッジルータ６の対応関係を保持するものである。ここで、サービス網１０１の欄には、説明上わかりやすいように、サービス網の名称を記載しているが、実際には、サービス網を示すラベルの値（図３のサービス網・ラベルテーブルを参照）が記載されている。なお、端末もサービス網と同等の扱いとし、各ユーザ端末がどのエッジルータ配下に接続されているかの情報も保持することとする。また、図２の例では、ＶＰＮに対応するエッジ１０２及びエッジＩＤ１０３が空欄となっているが、これは、サービス網のＶＰＮには複数の拠点が存在し、サービス網とエッジが１対１に対応しないためである。

図３は、サービス網・ラベル対応テーブルの構成例を示す図である。サービス網・ラベル対応テーブルは、サービス網２０１と、そのサービス網に対応するラベル２０２から構成される。なお、ここでも、各ユーザ端末をサービス網と同じ扱いとし、端末に対応するラベルの情報も保持する。

図４は、ユーザ端末が保持する宛先テーブル１１の構成例を示す図である。宛先テーブルは、端末がパケットを送信する宛先のアドレス３０１（ＩＰプレフィックス等）と、その宛先アドレスが示すサーバやネットワークが存在するサービス網のラベル（宛先サービス網のラベル３０２）を保持する。ここで、宛先サービス網のラベル３０２は、サービス網・ラベル対応テーブル２００のラベル２０２と対応している。ユーザ端末がパケットを送信する際には、この宛先テーブル３００を参照し、適切なラベルを付与して送信する。図４の例では、１０．０．０．０／８宛てのパケットはサービス網のラベル＃２に対応するＣＳＰへ、１９２．１６８．０．０／１６宛てのパケットはサービス網のラベル＃３に対応するＶＰＮへ送信することを意味する。また、宛先アドレスの"ｄｅｆａｕｌｔ"は、他の宛先にマッチしないものを転送するためのものであり、一般的にはＩＳＰを経由したインターネットへの通信に用いられる。本実施の形態でも、"ｄｅｆａｕｌｔ"をＩＳＰに対応するラベル＃１に割り当てている。

次に、図５を用いて、エッジルータ６の構成を説明する。図５に示すとおり、エッジルータ６は、通常のルータと同様に、ネットワークに接続される複数のインタフェース４０１と、パケットの宛先に応じて転送先のインタフェースへ転送するスイッチ４０２を具備する。

一方、本実施の形態に係る技術に特有の構成要素として、ラベルキャッシュ４０４を保持する。ラベルキャッシュ４０４は、パケットを転送する際に、ユーザ端末が送信したパケットに付与されたサービス網を示すラベルを参照するためのテーブルを持つ機能部であり、テーブルの構成はサービス網・エッジ対応テーブル８と同様である。具体的には、パケットの転送先の決定、及び、必要に応じてサービス網個別の処理を実施するサービス網個別制御部４０５へパケットを振り分ける処理を実施する。ラベルキャッシュ４０４は、サービス網・エッジ対応テーブル８の一部分をキャッシュとして保持しており、必要に応じて、サービス網・エッジ対応テーブル８に問い合わせて情報を取得する。

サービス網個別制御部４０５は、ＶＰＮサービスなどのネットワーク側でルーティングの処理等を実施する高度なサービスを提供する際に利用する機能部である。例えば、本実施の形態のように、ＶＰＮサービスを提供する場合、通常は複数の拠点が存在するが、ユーザが送信したパケットがどの拠点当てのものかを判断し、その拠点が収容されているエッジルータ６にパケットを送信する処理を実施する。各サービス網個別のルーティング情報等は、サービス網インスタンス４０６が保持する。ＶＰＮサービスの例では、図６に示すように、各ＶＰＮ拠点に収容されている端末やサーバ等のアドレスと、その拠点が接続されているエッジのエッジＩＤの対応関係（いわゆるＶＰＮのルーティングテーブル）を保持する。

本実施の形態に係るエッジルータ６は、コンピュータ（メモリ、ＣＰＵ）の機能を含むルータ（通信装置）において、本実施の形態で説明する処理に対応するプログラムを実行させることにより実現可能である。当該プログラムは、可搬メモリ等の記憶媒体に格納して配布し、上記ルータにインストールして用いてもよいし、ネットワーク上のサーバからダウンロードして上記ルータにインストールしてもよい。また、本実施の形態で説明する処理をハードウェア回路として実現し、当該ハードウェア回路をルータに備えることとしてもよい。

＜システムの動作例＞
次に、図７、図８を用いて、本実施の形態での通信の例を、順を追って説明する。

図７は、ユーザ端末と特定のサービス網を１対１で接続、通信する例として、ユーザ端末１（ラベル＃１００１）が、ＣＳＰ（ラベル＃２）に通信する場合の動作例を示している。

まず、ユーザ端末１は、自身が保持する宛先テーブル１１（本実施の形態では図４に示す３００）を参照し、宛先サービス網に対応するラベルを取得する。本実施の形態では、宛先ＩＰアドレスが１０．１．１．１とすると、宛先テーブル３００の、「宛先アドレス」が「１０．０．０．０／８」のエントリに該当するため、ラベルは＃２となる。このラベルを宛先ラベル（図７中では"Ｄｓｔ"と表示）に付与し、送信元ラベル（"Ｓｒｃ"と表示）にユーザ端末１のラベル＃１００１を付与して、ユーザ端末１からエッジルータＥ１にパケットを送信する（ステップ１）。

エッジルータＥ１がパケットを受信すると、まずラベルキャッシュ４０４を参照して、宛先ラベル＃２に該当するエッジルータのＩＤを検索する（ステップ２）。本実施の形態では、ラベルキャッシュに該当するエントリが存在しなかったと仮定する。その場合には、ラベル解決リクエストをサービス網・エッジ対応テーブル８（テーブル格納装置）に向けて送信する（ステップ３）。本メッセージには、宛先のサービス網のラベル＃２を記載して送信する。ラベル解決リクエストを受信したテーブル格納装置は、サービス網・エッジ対応テーブル８を検索する。本実施の形態では、サービス網・エッジ対応テーブル１００（図２）を検索すると、サービス網１０２が＃２であるエントリが見つかり、サービス網＃２（ＣＳＰ）がエッジルータＥ１２（ラベル＃１２）に収容されていることがわかる（ステップ４）。サービス網・エッジ対応テーブル８を格納するテーブル格納装置は、エッジのＩＤとして＃１２を、ラベル解決リプライとして、エッジルータＥ１に回答する（ステップ５）。

エッジルータＥ１は、サービス網＃２が収容されているエッジルータのＩＤとして＃１２をパケットに新たに付与して、網内にパケットを転送する（ステップ６）。なお、網内では、ラベルの値を参照することで、当該エッジルータまでパケットが転送できる構成であることを前提とする。例えば、ＭＰＬＳ（Multiprotocol Label Switching）のように、ラベルの値によりパケットを転送する技術を適用する構成が考えられる。また、各エッジルータ同士が、波長パスやＴＤＭなどのパスで直結されていて、パスとエッジルータが１対１に対応する場合は、エッジのＩＤでパスを選択するだけでよく、パケットにエッジのＩＤを付与しなくてもよい。

パケットを受信したエッジルータＥ１２は、当該パケットが自分宛てのものであるかを、エッジＩＤで確認したうえで、宛先サービス網のラベル（＃２）を参照して、ＣＳＰへパケットを転送する（ステップ７）。このとき、エッジＩＤやラベルなどは全て除去することで、通常のＩＰパケットとしてＣＳＰへ転送する。

なお、図７の例では、端末→ＣＳＰ方向の通信の例を示したが、前述のように、サービス網・エッジ対応テーブルにおいて、端末もサービス網と同様の扱いとしているため、ＣＳＰ→端末方向の通信も同様となる。ただし、ＣＳＰ内部のサーバや端末などが、本技術をサポートしていない場合には、送信元ラベルや宛先ラベルの付与を、エッジルータＥ１２が代理で実施することも可能である。

図８に、多地点間通信の例として、端末が複数あるＶＰＮ拠点の一つへパケットを送信する場合の動作例を示す。

まず、ユーザ端末１は自分が保持する宛先テーブル３００を検索する。宛先アドレスが１９２．１６８．１．１の場合、図４の１９２．１６８．０．０／１６のエントリが該当するため、サービス網のラベルは＃３となる。したがって、パケットに、宛先ラベル＃３、送信元ラベル＃１００１を付与して、エッジルータＥ１に送信する（ステップ１１）。なお、端末がアプリケーションのレベルで宛先のサービス網を判別できる場合は、本処理を省略してもよい。例えば、ＶＰＮにアクセスするために専用のアプリケーションを用いる場合、そのアプリケーションから送信されるパケットは、全てＶＰＮ宛ての通信とみなすことができる。

パケットを受信したエッジルータＥ１は、パケットに付与された宛先ラベル＃３をキーとして、自身のラベルキャッシュを検索する（ステップ１２）。ここで、ラベルキャッシュに、図２のサービス網・エッジ対応テーブルと同じ情報がキャッシュされていたとすると、ＶＰＮのラベル＃３に対応するエッジのＩＤが記載されていない。これは、サービス網がいずれか一つのエッジルータと１対１の関係にあるのではなく、どのエッジルータにパケットを転送すべきかを、エッジルータが判別しなくてはならないこと示す。

エッジルータＥ１は、サービス網個別制御部４０５の中から、サービス網の宛先ラベル＃３に該当するサービス網インスタンス４０６（アドレス・エッジ対応テーブル格納手段）を検索する（ステップ１３）。図６に示すＶＰＮのサービス網インスタンスには、宛先アドレスとそのアドレスの端末やサーバが収容されているエッジルータの対応関係が示されている。本実施の形態では、パケットの宛先アドレスは、１９２．１６８．１．１であるので、宛先アドレス１９２．１６８．１．０／２４のエントリ、すなわち、エッジＩDが＃１４のエッジルータにパケットを転送すればよいことがわかる。なお、ＶＰＮインスタンスが保持する端末やサーバのアドレスとエッジルータの対応関係の情報をどのように管理するかは本技術の対象外であるが、既存のネットワークベースのＶＰＮの仕組みをエッジルータ間に適用することが可能である。例えば、ＩＰ−ＶＰＮであれば、ＢＧＰ／ＭＰＬＳ ＶＰＮｓ（ＩＥＴＦにてＲＦＣ２５４７で規定）が適用可能である。

以降は、図７の例と同様に、パケットに宛先となるエッジのＩＤ（＃１４）を付加したうえで、パケットを転送する（ステップ１４）。パケットを受信したエッジルータＥ１４は、宛先ラベル＃３を参照して、ラベルを除去したうえで、ＶＰＮへパケットを転送する。

なお、詳細な実施例は省略するが、本技術を適用することで、ラベルで示されるリソースとエッジルータの関係が変わった場合、すなわち、リソースが別の場所へ移動した場合への対応も可能である。

一例として、端末が別のエッジルータの配下に移動することを考えると、サービス網・エッジ対応テーブル８では、端末とエッジルータの対応関係が保持されているため、この対応関係を書き換えることによって、端末の移動にも対応できる。例えば、ユーザ端末１がエッジルータＥ１の配下から、エッジルータＥ２の配下に移動した場合には、サービス網・エッジ対応テーブル８のユーザ端末１（＃１００１）に対応するエッジルータを、Ｅ１（エッジＩＤ＝１）から、Ｅ２（エッジＩＤ＝２）に書き換えればよい。これにより、例えば、移動後のユーザ端末１宛のパケット転送において、書き換え後のサービス網・エッジ対応テーブル８から、移動後のユーザ端末１を収容するエッジルータＥ２が識別され、正しく転送が行われる。

同様に、クラウドサービスなどで用いられる、サーバリソースの移動（バーチャルマシンのライブマイグレーションなど）への対応も可能である。サーバを、本技術におけるリソース（サーバのアドレス、あるいは、サーバが収容されているサブネットなど）として扱い、そのサーバがあるエッジルータに接続されているデータセンタから、別のエッジルータに接続されているデータセンタへ移動した場合に、サービス網・エッジ対応テーブル８を書き換える。本技術では、リソースに割り当てられたラベルの単位で転送先を判別するため、サーバのＩＰアドレスなどを変更しなくても、正常に通信ができる。

＜実施の形態のまとめ＞
上述したように、本実施の形態では、通信の宛先となるリソースに対してラベルを割り当て、そのラベルの単位で通信先を判別することで、必要に応じて網内でのルーティングを実現することとした。これにより、網内での制御が必要なＶＰＮのような多地点間通信等の高度なサービスも提供できるようになる。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１ ＩＰ網
２ ＩＳＰ
３ ＣＳＰ
４ ＶＰＮ
５ インターネット
６ エッジルータ
８ サービス網・エッジ対応テーブル
９ サービス網・ラベル対応テーブル
１０ ユーザ端末
１１ 宛先テーブル
１２ ルータ
１００ サービス網・エッジ対応テーブル
１０１ サービス網
１０２ エッジ
１０３ エッジＩＤ
２００ サービス網・ラベル対応テーブル
２０１ サービス網
２０２ ラベル
３００ 宛先テーブル
３０１ 宛先アドレス
３０２ 宛先サービス網のラベル
５００ サービス網インスタンス
５０１ 宛先アドレス
５０２ エッジＩＤ

Claims (8)

1. ＩＰ網のエッジに備えられる複数の通信装置を有する通信システムであって、
   各通信装置配下のリソースにラベルが割り当てられており、
   パケット送信元のリソースからパケットを受信する送信元の通信装置が、
   前記パケットに付与された宛先のリソースのラベルに対応する宛先の通信装置を識別する識別手段と、
   識別された宛先の通信装置に向けて前記パケットを送信する手段と、を備え、
   前記ＩＰ網を介して前記パケットを受信する宛先の通信装置が、
   前記パケットに付与されたラベルを除去し、ラベルの除去されたパケットを前記宛先のリソースに転送する手段を備える通信システムであり、
   前記送信元の通信装置は、パケットの宛先アドレスと、当該宛先アドレスを持つ装置が収容されているエッジの通信装置の識別情報とを対応付けたテーブルを格納した格納手段を備え、
   前記宛先のリソースが、複数のエッジの通信装置に対応付けられている場合において、前記送信元の通信装置の識別手段は、前記格納手段を参照することにより、前記パケットの宛先アドレスに対応するエッジの通信装置を前記宛先の通信装置として識別する
   ことを特徴とする通信システム。
2. 前記通信システムは、リソースと、当該リソースを収容するエッジの通信装置の識別情報とを対応付けたテーブルを格納するテーブル格納手段を備え、
   前記送信元の通信装置の識別手段は、前記宛先のリソースを収容するエッジの通信装置の識別情報を前記テーブル格納手段から取得することにより、前記宛先の通信装置を識別する
   ことを特徴とする請求項１に記載の通信システム。
3. 前記宛先のリソースが別の場所に移動した場合に、前記テーブル格納手段において、移動前のリソースを収容するエッジの通信装置の識別情報が、移動後のリソースを収容するエッジの通信装置の識別情報に書き換えられ、前記送信元の通信装置の識別手段は、移動後のリソースを収容するエッジの通信装置の識別情報を前記テーブル格納手段から取得することにより、リソースが別の場所に移動した後の宛先の通信装置を識別する
   ことを特徴とする請求項２に記載の通信システム。
4. 前記通信装置は、前記ＩＰ網におけるエッジルータであり、前記リソースは、サービス網又は端末である
   ことを特徴とする請求項１ないし３のうちいずれか１項に記載の通信システム。
5. ＩＰ網のエッジに備えられる複数の通信装置を有する通信システムにおけるパケット通信方法であって、
   各通信装置配下のリソースにラベルが割り当てられており、
   送信元の通信装置が、パケット送信元のリソースからパケットを受信し、当該パケットに付与された宛先のリソースのラベルに対応する宛先の通信装置を識別する識別ステップと、
   前記送信元の通信装置が、識別された宛先の通信装置に向けて前記パケットを送信するステップと、
   前記宛先の通信装置が、前記ＩＰ網を介して前記パケットを受信し、当該パケットに付与されたラベルを除去し、ラベルの除去されたパケットを前記宛先のリソースに転送するステップとを備えるパケット通信方法であり、
   前記送信元の通信装置は、パケットの宛先アドレスと、当該宛先アドレスを持つ装置が収容されているエッジの通信装置の識別情報とを対応付けたテーブルを格納した格納手段を備え、
   前記宛先のリソースが、複数のエッジの通信装置に対応付けられている場合、前記識別ステップにおいて、前記送信元の通信装置は、前記格納手段を参照することにより、前記パケットの宛先アドレスに対応するエッジの通信装置を前記宛先の通信装置として識別する
   ことを特徴とするパケット通信方法。
6. 前記通信システムは、リソースと、当該リソースを収容するエッジの通信装置の識別情報とを対応付けたテーブルを格納するテーブル格納手段を備え、
   前記識別ステップにおいて、前記送信元の通信装置は、前記宛先のリソースを収容するエッジの通信装置の識別情報を前記テーブル格納手段から取得することにより、前記宛先の通信装置を識別する
   ことを特徴とする請求項５に記載のパケット通信方法。
7. 前記宛先のリソースが別の場所に移動した場合に、前記テーブル格納手段において、移動前のリソースを収容するエッジの通信装置の識別情報が、移動後のリソースを収容するエッジの通信装置の識別情報に書き換えられ、前記識別ステップにおいて、移動後のリソースを収容するエッジの通信装置の識別情報を前記テーブル格納手段から取得することにより、リソースが別の場所に移動した後の宛先の通信装置を識別する
   ことを特徴とする請求項６に記載のパケット通信方法。
8. 前記通信装置は、前記ＩＰ網におけるエッジルータであり、前記リソースは、サービス網又は端末である
   ことを特徴とする請求項５ないし７のうちいずれか１項に記載のパケット通信方法。

Images