JP3679336B2 - パケットルーティング方法 - Google Patents
パケットルーティング方法 Download PDFInfo
- Publication number
- JP3679336B2 JP3679336B2 JP2001046513A JP2001046513A JP3679336B2 JP 3679336 B2 JP3679336 B2 JP 3679336B2 JP 2001046513 A JP2001046513 A JP 2001046513A JP 2001046513 A JP2001046513 A JP 2001046513A JP 3679336 B2 JP3679336 B2 JP 3679336B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- virtual
- network
- input
- address
- 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.)
- Expired - Lifetime
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、インターネットプロトコル（ＩＰ）ネットワークを介して構築されるＶＰＮ（Value Private Network）のパケットルーティング方法および装置に関する。より詳細には、顧客に対してレイヤ２での仮想プライベートネットワークを、規模拡張性に優れかつ低コストな状態で、ＩＰルーティングネットワーク上に実現するパケットルーティング方法に関するものである。
【０００２】
【従来の技術】
従来のＶＰＮサービスの実現方法は、キャリアネットワーク内でのパケット転送方式の違いにより、専用線，レイヤ３−ＶＰＮとレイヤ２−ＶＰＮの３種類に大別される。
まず、専用線について説明すると、従来の専用線の多くは、キャリア独自の通信プロトコルを使用して顧客の拠点間を１対１で接続する。このため、キャリア独自の高度な付加価値サービス、例えば、ＱｏＳサービスやセキュリティーサービスを提供できるという利点がある。
【０００３】
レイヤ３−ＶＰＮについて説明すると、レイヤ３−ＶＰＮにおいては、顧客からキャリアへ送信される入力パケット中の情報のうち、ＯＳＩ参照モデル第３層（レイヤ３）に対応する情報に基づいて、キャリアネットワーク内での経路制御を行う。１対１接続の専用線と異なり、顧客の複数拠点間の経路制御をキャリアネットワーク内で行うため、顧客の各拠点からキャリアネットワークへは、単一の仮想回線を接続するだけで、他の全ての拠点との通信が確保されるという利点がある。
【０００４】
つぎに、レイヤ２−ＶＰＮについて説明すると、レイヤ２−ＶＰＮでは、顧客からキャリアへ送信された入力パケットの情報のうち、ＯＳＩ参照モデル第２層（レイヤ２）に対応する情報に基づいて、キャリアネットワーク内での経路制御を行う。特にレイヤ２プロトコルとしては、イーサネット（登録商標）プロトコルあるいはＩＥＥＥ８０２．３プロトコルが利用されることが多く、この場合、複数のＶＰＮを識別するために、ＩＥＥＥ８０２．１Ｑで規定される拡張ヘッダ内の１２ビット長領域（ＶＬＡＮタグ）が用いられる。
【０００５】
レイヤ２−ＶＰＮでは、レイヤ３−ＶＰＮと同様、顧客の複数拠点間の経路制御をキャリアネットワーク内で行うため、顧客の各拠点からキャリアネットワークへは単一の仮想回線を接続するだけで、他の全ての拠点との通信が確保されるという利点がある。また、キャリアは、顧客パケットのレイヤ３情報については関知せずにレイヤ３情報を変更せずに転送するため、顧客は自身のＶＰＮ内で複数のレイヤプロトコルを自由に利用できるという利点がある。
【０００６】
さらに、多くの顧客がＬＡＮ内のレイヤ２プロトコルとしてイーサネットを利用しているため、キャリアのレイヤ２プロトコルにイーサネットを使用することにより、高度な専門知識を必要とせず、ＷＡＮであるＶＰＮと顧客におけるＬＡＮとをシームレスに接続できるという利点を有する。
【０００７】
【発明が解決しようとする課題】
しかしながら、上述した従来のパケットルーティングでは、各々つぎに示すような問題点があった。
まず、専用線について説明する。第１に、専用線で用いられている通信プロトコルは、顧客のＬＡＮでは一般に利用されていないため、顧客は専用線に接続するために高価な専用装置を用意する必要があり、ネットワークの構築に当たってはキャリア独自プロトコルに関する高度な専門知識が要求される。
【０００８】
第２に、専用線は、通常、顧客の拠点間を１対１で接続するのみであるため、３拠点以上を接続するためには、各拠点間を別々の専用線で１対１に接続する必要があり、拠点数が多い場合には高コストとなる。
第３に、上述のように複数拠点間を専用で１対１に接続する場合、各専用線間の経路制御を顧客側で行う必要があるため、接続拠点が多くなると顧客側の経路制御装置の負担が多くなる。
【０００９】
この状態を図１０に示す。一般に専用線では、拠点間（顧客側ルータ）を往路と復路との２つの仮想回線で接続するが、図１０に示すように、接続拠点数が４拠点の場合には１２本、５拠点の場合には２０本と、一般にＮ拠点では拠点数Ｎの二乗のオーダーで必要な仮想回線数が増大する。したがって、専用線の場合、接続拠点の規模を拡張することが容易ではない。
第４に、通常の専用線は、フレームリレーやＡＴＭといった単一の伝送方法を用いているため、ネットワークの途中にこれらの伝送方式のインフラストラクチャーが導入されていない場合には、サービスを提供できないという問題がある。
【００１０】
つぎに、レイヤ３−ＶＰＮについて説明する。レイヤ３−ＶＰＮでは、第１に、キャリア側が対応していないレイヤ３プロトコルを自由に利用して通信することができないという問題があった。また、たとえキャリア側が対応しているプロトコルでも、ＶＰＮをまたがってアドレスの割り当てを変更する場合には、通常、キャリア側ルータにおいてもアドレスの変更が必要になる。
【００１１】
他の例では、ＩＰv４からＩＰv６への移行などで顧客が利用するレイヤ３プロトコルに大きな変更がある場合には、経路制御に関わるキャリア側の全てのソフトウエアまたはハードウエアの更改が必要となり、更改のために莫大なコストがかかる。
また、顧客の複数のプロトコル間を相互に接続するには、接続のための機構も別途用意する必要がある。したがって、キャリアネットワークの構成が複雑になり、構築コストや管理コストが増大する。
【００１２】
第２に、プロバイダネットワークのエッジ（顧客からの回線を終端する部分）において、顧客のレイヤ３経路制御プロトコルを解釈する必要がある。図１１に、従来のレイヤ３−ＶＰＮにおけるエッジルータの構成を示した。ＢＧＰプロセス１１０３を介してキャリアネットワーク１１０４に接続するプロバイダエッジルータ１１０５では、接続する顧客の拠点ＬＡＮ１１０１と同じ数だけのレイヤ３経路制御のためのＩＧＰプロセス１１０２を起動する必要がある。しかし、レイヤ３経路制御の処理は、一般に複雑である。したがって、収容するユーザ数が多い場合、エッジに大きな処理能力が要求され、ひいてはネットワークのエッジのコスト上昇を招く。
【００１３】
第３に、ほとんどのレイヤ３−ＶＰＮでは、管理コスト低減のため顧客のレイヤ３情報を自動的にネットワーク全体に流布する機構が必要とされるが、この機構は一般に複雑であり、運用に際してキャリア側に高度な専門知識が要求される。このことは、ネットワーク運用のコスト上昇を招く。
【００１４】
第４に、ネットワーク内でのパケット転送にＭＰＬＳを利用する場合（例えばRFC2547『BGP/MPLS VPN』）では、効率的なパケット転送のためには、同一顧客のＶＰＮを収容するエッジ装置の全てのペア間で仮想回線を設定（フルメッシュ接続）する必要がある。したがって、ネットワークが大規模化すると、ネットワーク内の仮想回線の数は拠点数の二乗に比例して増大するため、規模の拡張が容易でないという問題がある。
【００１５】
つぎに、レイヤ２−ＶＰＮについて説明する。レイヤ２−ＶＰＮでは、つぎに示すように多くの課題を有している。第１に顧客のレイヤ２宛先アドレスに基づいてキャリアネットワーク内でのパケットの経路制御を行うが、イーサネットの場合、このレイヤ２アドレスの分布は階層化されておらずフラットなため、ネットワーク内のパケット交換機の経路制御には、顧客の全端末のレイヤ２アドレスを登録する必要がある。したがって、ネットワーク内の経路制御テーブルが、収容する顧客端末の数に応じて巨大化してしまう。この問題は、特にネットワークの中心部のパケット交換機において顕著であり、ネットワーク収容可能な端末数に対応して大きな制約を加えることになる。
【００１６】
第２に、顧客のパケットが属するＶＰＮを論理的に識別するために、ほとんどのキャリアネットワークの入り口では、ＩＥＥＥ８０２．１で規定されている拡張ヘッダ（ＶＬＡＮタグ）を付与するが、ＶＰＮ識別のための領域長は１２ビットである。これによって識別可能なＶＰＮの最大数は、４０９５（ＶＬＡＮタグ値＝０は予約されている）に制限されるため、大規模なネットワーク事業者にとっては、多数のユーザにＶＰＮサービスを提供する際の大きな妨げとなる。４０９５を越えるＶＰＮを収容するためにネットワーク装置を物理的に分離することも考えられるが、大規模ネットワークでは顧客や中継回線の収容設計および保守が複雑になる。
【００１７】
第３に、レイヤ２−ＶＰＮでは、キャリアネットワーク内でのパケット交換機において、顧客パケットのレイヤ２ヘッダに基づいて経路制御を行うが、レイヤ２プロトコルとして一般に利用されるイーサネットには、ネットワーク内でのホップ数をカウントあるいは制限するための標準的手法が存在しない。このことから、ネットワークトポロジの変化や経路制御のミスにより経路ループが形成された場合、経路ループにトラップされたパケットを排除する方法がない。
【００１８】
また、トラップされたパケットがブロードキャストパケットである場合、ループの分岐点で際限なくパケットがコピーされてしまうため、１カ所の経路操作のミスによってネットワーク全体が多大な影響を被る可能性が高い。また、このことから、リング型やメッシュ型などのループを含んだ冗長な物理トポロジーのネットワークの構築が困難であり、単純なスター型の物理トポロジーとならざるを得ない。したがって、従来のレイヤ２−ＶＰＮでは、可用性や信頼性の高いネットワークサービスを提供することが困難である。
【００１９】
第４に、レイヤ２−ＶＰＮは、例えばＩＥＥＥ８０２．３，あるいはイーサネットなどの単一の伝送方式に強く依存しているため、これらの伝送方式のインフラストラクチャーが導入されていない地域ではサービスが受けられないという問題がある。また、ネットワークの途中に他の伝送方式のインフラストラクチャーが存在する場合は、ネットワークの構成が複雑になるというネットワーク構築上の難点がある。
【００２０】
第５に、例えば網内のレイヤ２技術として一般に用いられているイーサネットでは、レイヤ２アドレスであるＭＡＣアドレスに基づくパケット転送を行うが、この場合、ＭＡＣアドレスを用いて柔軟な経路制御を行える一般的なプロトコルが、レイヤ２−ＶＰＮにはない。したがって、ある特定の宛先へのパケットや、特定の優先度を持ったパケットに対し、他のパケットと異なる経路を通過させることは非常に困難である。
【００２１】
本発明は、以上のような問題点を解消するためになされたものであり、前述したような従来のＶＰＮにおける問題を解決し、レイヤ３透過な仮想プライベートネットワークを、拡張性に優れた形態で提供できるようにすることを目的とする。
【００２２】
【課題を解決するための手段】
本発明のパケットルーティング方法は、ＬＡＮや端末を接続する端末側仮想インタフェースを複数もつレイヤ３の仮想プライベートネットワークを収容する共用ネットワークにおいて端末側仮想インタフェース間でパケットをＩＰルーティングしてレイヤ３の仮想プライベートネットワークにおいてレイヤ２の仮想プライベートネットワークを実現する方法であって、全ての端末側仮想インタフェースは、少なくとも１つの仮想ハブに接続され、全ての仮想ハブは少なくとも１つの端末側仮想インタフェースと、端末側仮想インタフェースと同じ仮想プライベートネットワークに属する少なくとも１つの網側仮想インタフェースとをもち、端末側および網側仮想インタフェースの間でパケットをレイヤ２ルーティングし、網側仮想インタフェースは、共用ネットワークを介して対向するレイヤ２仮想プライベートネットワーク装置の網側インタフェースにレイヤ３で接続し、共用ネットワークの内部でのパケットの転送は、ＩＰトンネルを利用してパケットを送受する共用ネットワークにおいて、入力パケットのレイヤ２ヘッダ内の少なくともレイヤ２アドレスであるＭＡＣアドレスと対応付けて、宛先となる仮想インタフェースを学習してテーブルに記憶し、宛先のＭＡＣアドレスが学習されていなく入力パケットが端末側仮想インタフェースから入力したものの場合、パケットが入力した仮想プライベートネットワークに属する全ての仮想インタフェースのうち、パケットが入力した仮想インタフェース以外の全ての仮想インタフェース各々に宛てて入力パケットを転送し、宛先のＭＡＣアドレスの宛先仮想インタフェースが学習されている場合には、対応する仮想インタフェース各々に宛てて入力パケットを転送し、テーブルに前述のＭＡＣアドレスが記録されていなければ、ＭＡＣアドレスとパケットが受信された仮想インタフェースとの対応を学習してテーブルに記憶し、網側仮想インタフェース宛のパケットについて、レイヤ２の仮想プライベートネットワーク識別子を付与して共用ネットワークの内部で転送するためのパケットに格納し、網側仮想インタフェースから受信したパケットに対してはこのパケットに格納された仮想ネットワーク識別子と受信側のレイヤ２仮想プライベートネットワーク装置が有する仮想プライベートネットワークを区別する識別子を比較することにより、受信したパケットに含まれる受信フレームが同一なレイヤ２仮想プライベートネットワークに属することを検査し、同一なレイヤ２仮想プライベートネットワークに属する受信フレームを受信したパケットから取り出し、仮想プライベートネットワーク識別子をはずしてフレームへ復元し、受信したパケットに含まれる送信元のＭＡＣアドレスがテーブルに記憶されていない場合は、受信したパケットに含まれる送信元の仮想プライベートネットワーク装置のＩＰアドレスと送信元のＭＡＣアドレスとの対応をテーブルに記録し、受信したパケットに含まれる送信先のＭＡＣアドレスがテーブルに記憶されている場合は、パケットに含まれる送信先のＭＡＣアドレスに対応する送信先にパケットに含まれるフレームを転送し、受信したパケットに含まれる送信先のＭＡＣアドレスがテーブルに記憶されていない場合は、パケットに含まれるフレームを全ての仮想インタフェースに転送することでパケットをＩＰルーティングネットワークを介してＩＰルーティングするようにしたものである。
この発明によれば、一度学習された仮想インタフェースに対し、対応するアドレスが宛先となっているパケットが、ＩＰルーティングネットワークに送出される。
【００２５】
上記発明において、テーブルに入力パケットが収容する宛先のアドレスに一致するものがない場合、入力パケットをこの入力パケットが入力した仮想ハブにおける入力パケットが入力した仮想インタフェース以外の全ての仮想インタフェースに送出する。
【００２６】
本発明のパケットルーティング方法は、入力パケットのレイヤ２ヘッダ内の少なくともレイヤ２アドレスと対応付けて、宛先となる仮想インタフェースを学習し、宛先レイヤ２アドレスが学習されていなく入力パケットが端末側仮想インタフェースから入力したものの場合、パケットが入力した仮想プライベートネットワークに属する全ての仮想インタフェースのうち、パケットが入力した仮想インタフェース以外の全ての仮想インタフェース各々に宛てて入力パケットを転送し、宛先レイヤ２アドレスの宛先仮想インタフェースが学習されている場合には、対応する仮想インタフェース各々に宛てて入力パケットを転送し、網側仮想インタフェース宛のパケットについて、仮想プライベートネットワーク識別子を付与し、ＩＰカプセル化パケットにカプセル化し、網側仮想インタフェースから受信したパケットに対してはＩＰカプセルを解除し、仮想プライベートネットワーク識別子をはずし、ＩＰカプセル化パケットをＩＰルーティングネットワークを介してＩＰルーティングするものである。
【００２７】
上記発明において、パケットの転送では、端末側仮想インタフェースから入力したパケットの宛先レイヤ２アドレスがブロードキャストアドレスである場合には、パケットが入力した仮想プライベートネットワークに属する全ての仮想ハブの端末側仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを含まない全ての端末側仮想インタフェースに宛ててパケットを転送する。また、端末から入力したパケットの転送では、宛先レイヤ２アドレスがマルチキャストアドレスである場合には、このパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、このパケットが入力した仮想インタフェースを含まない全ての仮想ハブに宛ててこのパケットを転送し、このパケットの転送各々において、対応する宛先の仮想プライベートネットワーク識別子でカプセル化する。
【００２８】
また、宛先レイヤ２アドレスがマルチキャストアドレスであり、かつマルチキャストアドレスが特定の仮想インタフェースに対応付けられている場合には、パケットの宛先マルチキャストアドレスに対応する特定の仮想インタフェースのうち、パケットが入力した仮想インタフェースを含まない上記特定の仮想インタフェースに宛てて入力パケットを転送する。また、ネットワークが、レイヤ２アドレスを告知するサーバを含み、送元レイヤ２アドレスの学習内容を変更する際、サーバに送元レイヤ２アドレスを通知し、サーバが同一仮想プライベートネットワークに含まれる他の全ての仮想ハブにレイヤ２アドレスを通知する。
【００２９】
また、共用ネットワークは、網側仮想インタフェースによって仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、宛先レイヤ２アドレスが学習されていない場合には、網側仮想インタフェースを通じてサーバへパケットを転送し、サーバにてパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、パケットが入力した仮想ハブ以外の全ての仮想ハブ各々に宛てて入力パケットを転送する。
【００３０】
また、共用ネットワークは、網側仮想インタフェースによって仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、宛先レイヤ２アドレスがブロードキャストアドレスである場合には、網側仮想インタフェースを通じてサーバへパケットを転送し、サーバにてパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうちパケットが入力した仮想ハブ以外の全ての仮想ハブ各々に宛てて入力パケットを転送する。
【００３１】
また、共用ネットワークは、網側仮想インタフェースによって仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、宛先レイヤ２アドレスがマルチキャストアドレスである場合には、網側仮想インタフェースを通じてサーバへパケットを転送し、サーバにてパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、パケットが入力した仮想ハブ以外の全ての仮想ハブ各々に宛てて入力パケットを転送する。
【００３２】
また、共用ネットワークは、網側仮想インタフェースによって仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、宛先レイヤ２アドレスがマルチキャストアドレスである場合には、網側仮想インタフェースを通じてサーバへパケットを転送し、サーバにてマルチキャストアドレスが特定の仮想ハブに対応づけれれている場合、パケットが入力した仮想ハブ以外の特定の仮想ハブ各々に宛てて入力パケットを転送する。
【００３３】
本発明の他の形態におけるパケットルーティング方法は、仮想インタフェースから入力したパケットの送元レイヤ２アドレスを、該当する仮想インタフェースと関係付けて学習し、仮想ハブ間を転送するパケットを、ＩＰユニキャストパケットにカプセル化し、第１の端末側仮想インタフェースから仮想ハブに入力したパケットに対して、パケットの送元レイヤ２アドレスが、同一の仮想ハブに収容された第２の端末側仮想インタフェースに対応付けて学習されている場合には、少なくともすでに学習されている第２の端末側仮想インタフェースに宛てて、送元レイヤ２アドレスを含む通知パケットを送信し、パケットの送元レイヤ２アドレスが、同一の仮想ハブに収容された他の網側仮想インタフェースに対応付けられて学習されている場合には、少なくとも同一仮想プライベートネットワークに属する他の全ての網側仮想インタフェースに宛てて、送元レイヤ２アドレスを含む通知パケットを送信し、パケットの送元レイヤ２アドレスが、同一の仮想ハブに収容された他の仮想インタフェースに対応付けて学習されていない場合には、少なくとも同一仮想プライベートネットワークに属する他の全ての網側仮想インタフェースに宛てて、送元レイヤ２アドレスを含む通知パケットを送信し、第１の網側仮想インタフェースから仮想ハブに入力したパケットに対して、パケットの送元レイヤ２アドレスが、同一の仮想ハブに収容された第３の端末側仮想インタフェースに対応付けて学習されている場合には、少なくともすでに学習されている第３の端末側仮想インタフェースに宛てて、送元レイヤ２アドレスを含む通知パケットを送信し、パケットの送元レイヤ２アドレスが、同一の仮想ハブに収容された他の仮想インタフェースに対応付けて学習されていない場合には、少なくとも同一仮想プライベートネットワークに属する他の全ての端末側仮想インタフェースに宛てて、送元レイヤ２アドレスを含む通知パケットを送信し、仮想ハブに入力したパケットに対して、パケットの宛先レイヤ２アドレスがすでに特定の仮想インタフェースに対応付けて学習されている場合には、少なくとも特定の仮想インタフェースに宛ててパケットを転送し、パケットの宛先レイヤ２アドレスが特定の仮想インタフェースに対応付けて学習されていない場合には、同一仮想プライベートネットワークに属するパケットが転送されてきた仮想インタフェース以外の全ての仮想インタフェース宛にパケットをコピーして転送するものである。
【００３４】
上記発明において、共用ネットワークは、網側仮想インタフェースによって仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、宛先レイヤ２アドレスが学習されていない場合には、網側仮想インタフェースを通じてサーバへパケットを転送し、サーバにてパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、パケットが入力した仮想ハブ以外の全ての仮想ハブ各々に宛てて入力パケットを転送する。
【００３５】
【発明の実施の形態】
以下、本発明の実施の形態について図を参照して説明する。
＜実施の形態１＞
図１は、本発明の第１の実施の形態におけるパケットルーティング方法を用いたキャリアネットワークの構成を示す構成図である。ＶＰＮサービスの顧客（端末）１０１は、端末側仮想インタフェース多重分離部１０２を介し、アクセスルータ１０３内の対応する仮想ハブ１０４に接続している。各端末１０１は、物理的なインタフェースを介して端末側仮想インタフェース多重分離部１０２に接続している。端末側仮想インタフェース多重分離部１０２では、同一物理媒体上に複数の仮想インタフェースを多重化し、また分離している。
【００３６】
この場合、各端末側の仮想インタフェースを識別するために使えるものとして、例えばＩＥＥＥ８０２．１のＶＬＡＮタグ、ＡＴＭのＶＣ、フレームリレーのＤＬＣＩ，ＴＤＭのタイムスロット、ＦＤＭの周波数、ＣＤＭのコード、ＩＳＤＮのチャネル，「ＰＰＰ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ」等が挙げられるが、これに限るものではない。
各仮想ハブ１０４は、網側仮想インタフェース多重分離部（識別子多重分離部）１０５を介し、ＩＰルーティング制御部１０６を通り、ＩＰルーティングネットワーク１０７に接続している。なお、ＩＰ（インターネットプロトコル）には、ＩＰｖ４やＩＰｖ６などがあるが、どちらでもよく、また、これらに限るものではない。
【００３７】
各アクセスルータ１０３は、ＩＰルーティングネットワーク１０７を介してＩＰトンネリングで接続されている。また、異なるアクセスルータ１０３に収容され、同一の顧客に対応する仮想ハブ１０４同士は、網側仮想インタフェース１０８によって接続されている。
アクセスルータ１０３を含みこれより網側が、異なるＶＰＮが共有する共有ネットワークである。
【００３８】
図２は、図１に示したアクセスルータ１０３の構成を示す構成図である。図２（ａ）に示すように、アクセスルータ１０３は、各顧客に対応して複数の仮想ハブ１０４を備えている。顧客側の端末側物理インタフェース２０１を通過してきた多重化されたパケットは、端末側仮想インタフェース多重分離部１０２で分離され、端末側仮想インタフェース２０３を通って対応する仮想ハブ１０４内の対応する端末側仮想インタフェース終端部２０４に転送される。端末側仮想インタフェース多重分離部１０２で分離されたパケットには、端末の所属を示すＶＬＡＮタグが含まれている。
【００３９】
端末側仮想インタフェース多重分離部１０２は、ＶＬＡＮタグとＶＰＮ番号が対応付けられたテーブルを参照することで、分離したパケットを対応する仮想ハブ１０４内の端末側仮想インタフェース終端部２０４に転送する。このとき、ＶＬＡＮタグはパケットよりはずされる。
なお、各仮想ハブ（仮想インタフェース）を識別するために使えるものとして、例えばＩＥＥＥ８０２．１のＶＬＡＮタグ、ＡＴＭのＶＣ、フレームリレーのＤＬＣＩ，ＴＤＭのタイムスロット、ＦＤＭの周波数、ＣＤＭのコード、ＩＳＤＮのチャネル、ＷＤＭの波長等が挙げられるが、これに限るものではない。
【００４０】
以上のことにより仮想ハブ１０４の端末側仮想インタフェース終端部２０４に入力したパケットは、図２（ｂ）に示すように、ユーザＭＡＣヘッダフィールド（６），ユーザペイロードフィールド（７），ユーザＦＣＳフィールド（８）から構成されている。
【００４１】
各端末側仮想インタフェース終端部２０４，網側仮想インタフェース終端部２０６，およびパケットフォワーディング部２０７は、仮想バス２０５によって相互に接続されている。上述したように、ある端末側仮想インタフェース終端部２０４に図２（ｂ）に示すような構成のパケットが入力すると、パケットフォワーディング部２０７は、このパケットを受け取る。パケットを受け取ったパケットフォワーディング部２０７は、受け取ったパケット中のユーザＭＡＣヘッダ（６）内の送元ＭＡＣアドレスと、このパケットが通過した端末側仮想インタフェース終端部２０４との関係を学習し、この情報をテーブル２０８に記憶する。
【００４２】
上記学習を行ったパケットフォワーディング部２０７は、受け取ったパケットの中のユーザＭＡＣヘッダ（６）内の宛先ＭＡＣアドレスとこれを転送すべき網側仮想インタフェース終端部２０６との関係を示す情報を、テーブル２０８より取得し、取得した情報に基づいてパケットを対応する網側仮想インタフェース終端部２０６に転送する。パケットを受け取った各網側仮想インタフェース終端部２０６は、このパケットを網側仮想インタフェース２０９を介して網側仮想インタフェース多重分離部１０５に転送する。
【００４３】
各仮想ハブ１０４の各網側仮想インタフェース終端部２０６より複数のパケットを受け取った網側仮想インタフェース多重分離部１０５は、各々のパケットに、図２（ｃ）に示すように、キャリアＩＰヘッダ（２）とＶＰＮ−ＩＤ（ＶＰＮ識別子）（３）および予約（４），タイプ（５）の情報を付加し、各パケットを多重化する。
【００４４】
パケットに付加する情報について説明すると、まず、キャリアＩＰヘッダ（２）は、ＩＰルーティングネットワーク内で入り口のアクセスルータから出口のアクセスルータまでパケットを転送するために用いられる。なお、キャリアＩＰヘッダ（２）のフィールドには、ＴＯＳフィールドを備えているが、ここは、ユーザペイロードフィールド（７）部分のＩＰヘッダのＴＯＳや、ユーザＭＡＣヘッダフィールド（６）のＩＥＥＥ８０２．１優先度ビットと関連付けて、ＩＰルーティングネットワーク内での優先制御に用いることもできる。
【００４５】
ＶＰＮ−ＩＤ（３）の領域は、同一のアクセスルータ１０３内における複数の仮想ハブ１０４を識別するために用いられる。ユーザのＶＰＮには、全て一意のＶＰＮ−ＩＤを割り当て、このＶＰＮ−ＩＤと同じ値をアクセスルータ内の仮想ハブに割り当てることによって、同一のＩＰトンネル内に複数のＶＰＮのパケットを多重化することができる。また、予約（４）の領域は、将来のための予約部分である。タイプ（５）は、この後のユーザＭＡＣヘッダの種類を表す領域である。これによって、ユーザの希望にあわせたレイヤ２技術を利用することが可能となる。
【００４６】
網側仮想インタフェース多重分離部１０５で多重化されたパケットは、ＩＰルーティング制御部１０６により、図２（ｄ）に示すように、キャリアＭＡＣヘッダ（１），キャリアＦＣＳ（９）が付加され、網側物理インタフェース２１１に送り出される。キャリアＦＣＳフィールド（９）の値により、必要に応じてエラーチェックを行うことができる。
【００４７】
なお、各仮想インタフェースを識別するために使えるものとして、例えば、ＩＰカプセル化されたパケット中に記録された送元ＩＰアドレス、宛先ＩＰアドレス、ＶＰＮ識別子、ＩＥＥＥ８０２．１のＶＬＡＮタグ、ＷＤＭの波長などを利用できる。
【００４８】
図３は、テーブル２０８に含まれる各種テーブルの構成を示す構成図である。テーブル２０８は、ＭＡＣアドレス学習テーブル３０１と、ＭＡＣフォワーディングテーブル３０２と、仮想インタフェース・ＶＰＮテーブル３０３と、ＶＰＮ・仮想インタフェーステーブル３０４とを備えている。
ＭＡＣアドレス学習テーブル３０１は、仮想ハブ１０４に入力されたパケットの送元ＭＡＣアドレスを、通過してきた仮想ハブ１０４内の仮想インタフェース（仮想インタフェース終端部）と対応付けて学習する。
【００４９】
この学習内容は、ＭＡＣフォワーディングテーブル３０２に反映され、パケットフォワーディング部２０７が、パケットを宛先の仮想インタフェース終端部にフォワーディングする際に用いられる。
仮想インタフェース・ＶＰＮテーブル３０３は、パケットが入力した仮想インタフェース終端部から、このパケットが属するＶＰＮ番号を得るために用いられる。仮想インタフェース・ＶＰＮテーブル３０３は、端末側仮想インタフェース・ＶＰＮテーブル３０３ａと網側仮想インタフェース・ＶＰＮテーブル３０３ｂとから構成されている。
【００５０】
端末側仮想インタフェース・ＶＰＮテーブル３０３ａは、パケットが入力した端末側仮想インタフェース多重部１０２において、このパケットが属するＶＰＮ番号および仮想インタフェース番号を得るために用いる。
また、ＶＰＮ・仮想インタフェーステーブル３０４は、あるＶＰＮ番号に属する全ての仮想インタフェース（仮想インタフェース終端部）を示し、宛先を学習していないパケットなどの転送に用いる。
【００５１】
以下の表１、表２にＭＡＣアドレス学習テーブルの例を示す。
【００５２】
【表１】
【００５３】
ＭＡＣアドレス学習テーブルは、入力仮想インタフェースの種類の識別子、ＶＰＮの番号、インタフェース番号、および送元ＭＡＣアドレスを含む。例えば、表１のはじめの行の内容は、「ＶＰＮ番号１に属する網側仮想インタフェースから、送元ＭＡＣアドレス００−００−００−００−００−０１のパケットが入力したことを学習した」ことを示す。表１では、複数のＶＰＮ番号に属するエントリが同一のテーブル上に示されているが、各ＶＰＮ番号に対応する仮想ハブ内のテーブルで、各々別のＭＡＣアドレス学習テーブルを保持しても良い。また、各ＶＰＮのテーブル毎にサイズを制限する機構を持っても良い。また、送元ＭＡＣアドレスのみならず、パケットの優先度毎に異なるエントリを保持することもできる。
【００５４】
表１でＭＡＣアドレスを学習した内容から、ＭＡＣフォワーディングテーブルを作成した例を以下の表２に示す。
【００５５】
【表２】
【００５６】
表２に示すように、ＭＡＣフォワーディングテーブルでは、パケットの属するＶＰＮ番号と宛先ＭＡＣアドレスとから、宛先仮想インタフェースの種類と、宛先仮想インタフェースの番号を得る。ＭＡＣアドレス学習テーブルの人力仮想インタフェースの種類、ＶＰＮ番号、入力インタフェース番号、送元ＭＡＣアドレスが、各々、ＭＡＣフォワーディングテーブルの宛先仮想インタフェースの種類、ＶＰＮ番号、宛先仮想インタフェース番号、宛先ＭＡＣアドレスに対応する。
【００５７】
表２でも、複数のＶＰＮ番号に属するエントリが同一のテーブル上に示されているが、各ＶＰＮ番号に対応する仮想ハブ内のテーブルで、各々別のＭＡＣアドレス学習テーブルを保持しても良い。
表２に基づいてパケットをフォワーディングする場合、例えば、ＶＰＮ番号１の仮想ハブ１０４の端末側仮想インタフェース終端部２０４に入力した宛先ＭＡＣアドレス００−００−００−００−００−０１宛のパケットは、仮想インタフェース番号が１の網側仮想インタフェース終端部２０６に出力される。
【００５８】
以下に示す表３，表４は、各々端末側仮想インタフェース・ＶＰＮテーブルおよび網側仮想インタフェース・ＶＰＮテーブルの例である。なお、表４におけるＶＰＮ番号は、パケットに含まれるものである。
【００５９】
【表３】
【００６０】
【表４】
【００６１】
表３において、「端末側物理インタフェース番号」は、パケットを入出力する各端末側物理インタフェースを示している。「ＶＬＡＮタグ」は、同一の端末側物理インタフェースにおいて入出力するパケットに含まれるＶＬＡＮタグの値を表している。「ＶＰＮ番号」は、同一アクセルルータ内の各仮想ハブに対応し、「仮想インタフェース番号」は、同一アクセスルータ内の各仮想ハブに対応する。
【００６２】
端末側仮想インタフェース・ＶＰＮテーブルは、端末側仮想インタフェース多重部１０２において、端末側物理インタフェースから入力するパケットに対し、対応する仮想ハブと仮想インタフェースを得るために用いる。表３に示したように、例えば、番号２０１の端末側物理インタフェースで受信したパケットが、値１００５のＶＬＡＮタグを含むとき、このパケットは番号１のＶＰＮに属し、番号１のＶＰＮの仮想ハブの、番号１の仮想インタフェースに転送するものであることが分かる。
【００６３】
端末側仮想インタフェース・ＶＰＮテーブルは、端末側仮想インタフェース多重部１０２において、仮想ハブから端末側仮想インタフェースに出力されたパケットを、端末側物理インタフェースに多重するためにも用いることができる。このときは、パケットを出力した仮想ハブが属するＶＰＮ番号と仮想インタフェース番号とを元にして表を検索し、パケットを出力すべき端末側物理インタフェース番号とＶＬＡＮタグとを得る。表３に示したように、例えば、ＶＰＮ番号２の仮想ハブから番号３の仮想インタフェースに対して出力されたパケットは、ＶＬＡＮタグとして値１２３４を付与し、番号２０１の端末側物理インタフェースに出力されるものであることが分かる。
【００６４】
端末側インタフェース・ＶＰＮテーブルは、パケットが入力した網側仮想インタフェース多重部１０５において、このパケットが属するＶＰＮ番号および仮想インタフェース番号を得るために用いる。
表４において、「ローカルＩＰアドレス」は、このアクセスルータに設定されたＩＰアドレスを示し、「リモートＩＰアドレス」は、ＩＰルーティングネットワークを介して接続されている接続先のアクセスルータのＩＰアドレスを示している。また、「ＶＰＮ番号」は、網側仮想インタフェース１０８において入出力されるパケットに含まれるＶＰＮ番号である。「仮想ハブ番号」は、アクセスルータ内でパケットを送受信する仮想ハブの番号を示し、「仮想インタフェース番号」は、仮想ハブにおける仮想インタフェース番号である。
【００６５】
ＩＰルーティング制御部１０６から網側仮想インタフェース多重部１０５に対してＩＰパケットが入力した場合を例にとると、まず、パケットに含まれる宛先ＩＰアドレスと送元ＩＰアドレスとＶＰＮ番号とが、各々表４中の「ローカルＩＰアドレス」と「送元ＩＰアドレス」と「ＶＰＮ番号」とに対応づけられ、テーブルが検索される。
つぎに、この検索で得られた「仮想ハブ番号」と「仮想インタフェース番号」とに基づいて、パケットフォワーディング部は、対応する仮想ハブの対応する仮想インタフェースにパケットを転送する。
【００６６】
表４によれば、例えばＩＰアドレス１０．２．２．２を持つアクセスルータから、ＩＰルーティングネットワークを介してＩＰアドレス１０．１．１．１を持つアクセスルータに入力したパケットが、ＶＰＮ番号２を含む場合、このパケットは、番号２の仮想ハブの番号２の仮想インタフェースに転送されることになる。
【００６７】
さらに、網側仮想インタフェース・ＶＰＮテーブル３０３ｂは、網側仮想インタフェース多重部１０５において、各仮想ハブ１０４から網側仮想インタフェース１０８に対して出力されたパケットを、ＩＰルーティング制御部１０６へ多重して転送するためにも用いる。このときは、パケットを出力した仮想ハブ１０４の番号と仮想インタフェースの番号とを元に、テーブルが検索され、パケットを付与すべきＶＰＮ番号とキャリアＩＰヘッダ内の送元および宛先アドレスが取り出される。
【００６８】
なお、表４の例では、「ＶＰＮ番号」と「仮想ハブのＶＰＮ番号」とは同じ値となっているが、これらの値は必ずしも一致する必要はなく、運用の形態によって異なる値を用いるようにしても良い。
【００６９】
つぎに示す表５は、ＶＰＮ・仮想インタフェーステーブルの例である。
【００７０】
【表５】
【００７１】
ＶＰＮ・仮想インタフェーステーブルは、ＶＰＮ番号から、このＶＰＮに属する全ての仮想インタフェースの番号を得るために用いられる。表５によれば、例えば、ＶＰＮ番号１に属する仮想インタフェースは２つあり、これらが、仮想インタフェース番号が１の網側仮想インタフェースと、仮想インタフェース番号が２の端末側仮想インタフェースとであることがわかる。ＶＰＮ・仮想インタフェーステーブルは、パケットを何れかの仮想インタフェース終端部に転送するときに、宛先ＭＡＣアドレスが学習されていない場合に、ＶＰＮ番号に属する仮想インタフェース宛に、必要数のパケットをコピーして各々を転送するために用いられる。
【００７２】
以下、図４を用いて、アクセスルータ１０３による図１，２に示したネットワークにおける典型的なパケットの転送手順を説明する。図４では、ある拠点のＬＡＮに接続された端末１０１から、他の拠点のＬＡＮに接続された端末１０１へのパケットを転送する場合を例にしている。
まず、端末１０１からパケットが出力されると（ステップＳ４００）、出力されたパケットは、送元のアクセスルータ１０３内で、端末側仮想インタフェース多重分離部１０２から、対応する仮想ハブ１０４の対応する端末側仮想インタフェース終端部２０４に入力する（ステップＳ４０１）。
【００７３】
端末側仮想インタフェース終端部２０４にパケットが到達すると、パケットフォワーディング部２０７は、パケットが到達した（通過する）端末仮想インタフェース終端部２０４の入力インタフェース番号とこれが網側であるか端末側であるかとの情報に、送元ＭＡＣアドレスを対応付け、これをテーブル２０８のＭＡＣアドレス学習テーブル３０１に登録する（ステップＳ４０２）。
【００７４】
つぎに、パケットフォワーディング部２０７は、宛先ＭＡＣアドレスを、ＭＡＣフォワーディングテーブル３０２から検索し、対応する宛先の網側仮想インタフェース終端部２０６へパケットを転送する（ステップＳ４０３）。このとき、対応する宛先が複数存在する場合、パケットフォワーディング部２０７は、パケットを必要数コピーして、各々の宛先の網側仮想インタフェース終端部へパケットを転送する。また、ＭＡＣアドレスフォワーディングテーブル３０２に必要な情報がない場合、パケットフォワーディング部２０７は、ＶＰＮ・仮想インタフェーステーブル３０４を参照し、ＶＰＮ番号に属する仮想インタフェース宛に、必要数のパケットをコピーして各々を転送する。
【００７５】
以上のことにより、所定の網側仮想インタフェース終端部２０６へパケットが転送されると、パケットは網側仮想インタフェース２０９を介して網側仮想インタフェース多重分離部１０５に転送されて多重化され、ＩＰルーティング制御部１０６により網側仮想インタフェース１０８へ出力される（ステップＳ４０４）。なお、この例では、ＩＰルーティングネットワーク１０７（図１）を介して接続された他の仮想ハブ１０４を経由してパケットを転送する場合について示してある。出力されたパケットは、ＩＰパケットにカプセル化され、ＩＰルーティングネットワーク１０７内を宛先の仮想ハブ１０４のあるアクセスルータ１０３まで転送される（ステップＳ４０５）。
【００７６】
ＩＰルーティングネットワーク１０７内を転送されて宛先のアクセスルータ１０３に上記ＩＰパケットが入力すると（ステップＳ４０６）、まず、ＩＰルーティング制御部１０６によりＩＰカプセルが解除される。次いで、このパケットは、網側仮想インタフェース多重分離部１０５で分離され、対応する仮想ハブ１０４の対応する網側仮想インタフェース終端部２０６に転送される。パケットを受け取った仮想ハブ１０４では、パケットフォワーディング部２０７が、パケットが到達した（通過する）網側仮想インタフェース終端部２０６の入力インタフェース番号とこれが網側であるか端末側であるかとの情報に、送元ＭＡＣアドレスを対応付け、これをテーブル２０８のＭＡＣアドレス学習テーブル３０１に登録する。
【００７７】
次いで、パケットフォワーディング部２０７は、パケットの宛先ＭＡＣアドレスをＭＡＣアドレスフォワーディングテーブル３０２から検索し、宛先に対応する端末側仮想インタフェース終端部２０４へパケットを転送する（ステップＳ４０８）。転送されて端末側仮想インタフェース終端部２０４を通過したパケットは、端末側仮想インタフェース多重分離部１０２で他のパケットと共に多重化されて出力され（ステップＳ４０９）、最終的に宛先の端末１０１に到達する（ステップＳ４１０）。
【００７８】
以上説明したように、本実施の形態によれば、キャリアのエッジに上述したアクセスルータ１０３を設けるようにし、顧客の各拠点（端末）とキャリアネットワーク（ＩＰルーティングネットワーク１０７）との間を、単一の仮想回線（仮想ハブ１０４）で接続し、これにより他の全拠点との通信が確保する状態とした。したがって、ＶＰＮの接続対地数が増加しても顧客とキャリアとの間の仮想回線を増設する必要が無くなる。
また、キャリアネットワークのエッジ（アクセスルータ１０３）の負荷が軽減され、ネットワークが、顧客および顧客グループ数（ＶＰＮ数）の大規模化に対応可能となる。
【００７９】
また、本実施の形態によれば、キャリアネットワークの中心部における経路制御を、顧客やＶＰＮ数，あるいは各ＶＰＮ内の接続拠点やＶＰＮ内アドレッシングとは独立して管理できるので、堅牢かつ規模拡大生に優れたＶＰＮサービスが提供できる。また、本実施の形態では、伝送方式や伝送媒体に依存しないので、複数種類の伝送媒体や伝送方式にまたがってＶＰＮサービス用のネットワークの構築が可能となる。また、顧客の各種レイヤ３プロトコルに対して透過な接続が提供でき、顧客はレイヤ３プロトコルを自由に選択することが可能になる。
【００８０】
＜実施の形態２＞
以下、本発明の第２の実施の形態について説明する。本実施の形態では、仮想ハブ１０４内において、スパニングツリーアルゴリズム等のループ回避機構の有無により、パケットフォワーディング部２０７による仮想バス２０５を介したパケットの転送先に制限を設けるようにした。
【００８１】
はじめに、ループ回避機構を設けていない場合の、仮想ハブ１０４におけるパケット転送動作について説明する。網側仮想インタフェースから受信したパケットは、ＭＡＣアドレス学習機能により、入力した仮想インタフェースと送元ＭＡＣアドレスとを対応付けて学習された後、転送ステップにおいて、ユーザＭＡＣヘッダ以降のフレームの宛先ＭＡＣアドレスが検査される。
【００８２】
宛先ＭＡＣアドレスが、すでに何れかの端末側仮想インタフェース終端部２０４の先にあると学習され、ＭＡＣフォワーディングテーブル３０２に用意されていたならば、上記パケットは、学習されていた端末側仮想インタフェース終端部２０４へ転送される。これは、前述した実施の形態と同様である。
【００８３】
これに対し、宛先ＭＡＣアドレスが、何れの端末側仮想インタフェース終端部２０４の先にも学習されていない場合、パケットフォワーディング部２０７は、この仮想ハブ１０４の全ての端末側仮想インタフェース終端部２０４宛に、当該パケットをコピーして転送する。また、宛先ＭＡＣアドレスが、ブロードキャストアドレスであった場合にも、パケットフォワーディング部２０７は、当該仮想ハブ１０４の全ての端末側仮想インタフェース終端部２０４宛に、上記パケットをコピーして転送する。
【００８４】
このように、本実施の形態では、ループ回避機構がない場合、もしくは機能していない場合、網側仮想インタフェース２０９から入力したパケットは、同一の仮想ハブ１０４内の別の網側仮想インタフェース２０９（網側仮想インタフェース終端部２０６）には転送しないようにした。このことにより、網側から仮想ハブ１０４内に入力されたパケットが、網側に戻ることが抑制されるので、キャリア側のネットワークであるＩＰルーティングネットワーク１０７内で、上記パケットがループするのが防がれるようになる。
【００８５】
一方、端末側から仮想ハブ内にパケットが入力された場合は、上述とは異なり、端末側に戻すようにしても良い。端末１０１より端末側仮想インタフェース２０３，端末側仮想インタフェース終端部２０４を介して入力したパケットは、パケットフォワーディング部２０７におけるＭＡＣアドレス学習機能により、通過した端末側仮想インタフェース終端部２０４と送元ＭＡＣアドレスとを対応付けて学習された後、宛先ＭＡＣアドレスが検査される。
【００８６】
ＭＡＣフォワーディングテーブル３０２内に、パケットに格納されている宛先ＭＡＣアドレスが、すでに何れかの端末側または網側仮想インタフェースの先にあると学習されていたならば、パケットフォワーディング部２０７は、当該パケットを該当する網側仮想インタフェース終端部２０６に転送する。
【００８７】
一方、ＭＡＣフォワーディングテーブル３０２内に、上記宛先ＭＡＣアドレスに対応する仮想インタフェース終端部の情報が無ければ（学習されていなければ）、パケットフォワーディング部２０７は、同一の仮想ハブ１０４内で、パケットが入力した端末側仮想インタフェース終端部２０４を除く、全ての端末側仮想インタフェース終端部２０４および網側仮想インタフェース終端部２０６に、パケットをコピーして転送する。
【００８８】
また、宛先ＭＡＣアドレスが、ブロードキャストアドレスであった場合にも、パケットフォワーディング部２０７は、当該仮想ハブ１０４の全ての仮想インタフェースのうち、パケットが入力した端末側仮想インタフェース終端部２０４を除く全ての端末仮想インタフェース終端部２０４および網側仮想インタフェース終端部２０６宛に、上記パケットをコピーして転送する。
【００８９】
つぎに、仮想ハブ１０４間に、スパニングツリーアルゴリズム等のループ回避機構を設けた場合について説明する。この例では、仮想インタフェース（端末側仮想インタフェース終端部２０４，網側仮想インタフェース終端部２０６）の内のいくつかは、ループ回避機構によってブロックされている場合があるが、以後の記述では、ブロックされている仮想インタフェースに対しては、パケットの宛先から除外することとする。
【００９０】
例えば、ある網側仮想インタフェース２０９を経由して網側仮想インタフェース終端部２０６に入力したパケットは、パケットフォワーディング部２０７により、入力した網側仮想インタフェース終端部２０６と送元ＭＡＣアドレスとを対応付けて学習された後、パケット内の宛先ＭＡＣアドレスが検査される。
この検査の結果得られた宛先ＭＡＣアドレスが、ＭＡＣアドレスフォワーディングテーブル３０２内に、すでに何れかの端末側仮想インタフェース２０３の先にあると学習されていたならば、学習されていた端末側仮想インタフェース終端部２０４へ転送される。
【００９１】
一方、パケット内の宛先ＭＡＣアドレスが、ＭＡＣアドレスフォワーディングテーブル３０２内に、何れの端末側仮想インタフェース終端部２０４との関連も学習されていない場合はつぎのようになる。この場合、パケットフォワーディング部２０７は、この仮想ハブ１０４に接続した仮想インタフェースの終端部のうち、パケットが入力した端末側仮想インタフェース終端部２０４と、ループ回避機構によりブロックされているもの以外の全ての仮想インタフェース終端部に、コピーして転送する。
【００９２】
また、宛先ＭＡＣアドレスが、ブロードキャストアドレスであった場合にも、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェース終端部２０６と、ループ回避機構によりブロックされているもの以外の全ての仮想インタフェース終端部宛に、コピーして転送される。ただし、パケットフォワーディング部２０７は、網側仮想インタフェースから入力したパケットを、別の網側仮想インタフェースに出力する際に、入力したカプセル化パケット中のキャリアＩＰヘッダのＴＴＬ値を少なくとも１以上減算して、別の網側仮想インタフェースから出力する。このことにより、万一ループが発生しても、無限にループすることが回避できる。また、ユーザペイロードの中のＩＰヘッダのＴＴＬ値を減算するようにしても良い。
【００９３】
一方、端末側から入力したパケットについては、以降に説明するように、制限はない。端末側仮想インタフェース終端部２０４から仮想ハブ１０４に入力したパケットは、パケットフォワーディング部２０７の学習機能により、通過した端末側仮想インタフェース終端部２０４と送元ＭＡＣアドレスとを対応付けて学習された後、パケット内の宛先ＭＡＣアドレスが検査される。パケット内の宛先ＭＡＣアドレスが、ＭＡＣアドレスフォワーディングテーブル３０２内で、すでに何れかの仮想インタフェース終端部の先にあると学習されていたならば、パケットフォワーディング部２０７は、パケットを該当する仮想インタフェース終端部に転送する
【００９４】
また、パケット内の宛先ＭＡＣアドレスが、何れの仮想インタフェース終端部とも関連付けられていない場合、この仮想ハブ１０４に接続した仮想インタフェースの終端部のうち、パケットが通過した端末側仮想インタフェース終端部２０４を除く全ての仮想インタフェース終端部にコピーして転送される。また、宛先ＭＡＣアドレスが、ブロードキャストアドレスであった場合にも、当該仮想ハブ１０４に接続した仮想インタフェースの終端部のうち、パケットが通過した端末側仮想インタフェース終端部２０４を除く全ての仮想インタフェース終端部にコピーして転送される。
【００９５】
＜実施の形態３＞
つぎに、本発明の第３の実施の形態について説明する。本実施の形態でも、仮想ハブ間でスパニングツリーアルゴリズム等のループ回避機構を動作させていない場合の、仮想ハブにおけるパケット転送動作を説明する。ただし、本実施の形態では、宛先ＭＡＣアドレスがマルチキャストアドレスであるものを扱う場合について説明する。
【００９６】
網側仮想インタフェースから受信したＭＡＣフレームは、ＭＡＣアドレス学習機能により、入力した仮想インタフェースと送元ＭＡＣアドレスとを対応付けて学習された後、転送ステップにおいて、宛先ＭＡＣアドレスを検査される。
宛先ＭＡＣアドレスがすでに何れかの端末側仮想インタフェースの先にあると学習されていたならば、学習されていた仮想インタフェースへ転送される。
【００９７】
また、宛先ＭＡＣアドレスが、何れの仮想インタフェースの先にも学習されていないならば、当該仮想ハブに接続した全ての端末側仮想インタフェース宛にコピーして転送される。また、宛先ＭＡＣアドレスが、マルチキャストアドレスであった場合にも、当該仮想ハブに接続した全ての端末側仮想インタフェース（終端部）宛にコピーして転送される。
ここで、同一の仮想ハブに、複数の網側インタフェースが接続している場合でも、上記のように、網側仮想インタフェースから入力したパケットは別の網側仮想インタフェースには転送しないことに注意が必要である。これは、ネットワーク内でパケットがループするのを防ぐためである。
【００９８】
一方、端末側仮想インタフェースから入力したパケットは、ＭＡＣアドレス学習機能により、入力した端末側仮想インタフェースと送元ＭＡＣアドレスとを対応付けて学習された後、転送ステップにおいて、宛先ＭＡＣアドレスを検査される。
【００９９】
宛先ＭＡＣアドレスが、すでに何れかの端末側または網側仮想インタフェースの先にあると学習されていたならば、該当する仮想インタフェースに転送される。また、上記宛先ＭＡＣアドレスが、何れの仮想インタフェースの先にも学習されていないならば、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての仮想インタフェース宛にコピーして転送される。
また、宛先ＭＡＣアドレスが、マルチキャストアドレスであった場合にも、当該仮想ハブに接続した全ての仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての仮想インタフェース宛にコピーして転送される。
【０１００】
つぎに、仮想ハブ間でスパニングツリーアルゴリズム等のループ回避機構を動作させている場合の動作を以下に記す。このとき、仮想インタフェースの内のいくつかはスパニングツリーアルゴリズム等によってブロックされている場合があるが、以後の記述では、ブロックされている仮想インタフェースに対しては、パケットの宛先から除外することとする。網側仮想インタフェースから入力したパケットは、ＭＡＣアドレス学習機能により、入力した網側仮想インタフェースと送元ＭＡＣアドレスとを対応付けて学習された後、転送ステップにおいて、宛先ＭＡＣアドレスを検査される。
【０１０１】
宛先ＭＡＣアドレスがすでに何れかの端末側仮想インタフェースの先にあると学習されていたならば、学習されていた仮想インタフェースへ転送される。また、宛先ＭＡＣアドレスが、何れの端末側仮想インタフェースの先にも学習されていないならば、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての宛先に必要に応じてコピーして転送される。
【０１０２】
また、宛先ＭＡＣアドレスが、マルチキャストアドレスであった場合にも、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての仮想インタフェース宛に必要に応じてコピーして転送される。ただし、上記の様に網側仮想インタフェースから入力したパケットを、別の網側仮想インタフェースに出力する際には、万一ループが発生してもよいように、入力したカプセル化パケット中のキャリアＩＰヘッダのＴＴＬ値を少なくとも１以上減算して、別の網側仮想インタフェースから出力することが望ましい。
【０１０３】
端末側仮想インタフェースからパケットが入力すると、ＭＡＣアドレス学習機能により、まず、入力した端末側仮想インタフェースと送元ＭＡＣアドレスとを対応付けて学習された後、転送ステップにおいて、宛先ＭＡＣアドレスを検査される。宛先ＭＡＣアドレスが、すでに何れかの仮想インタフェースの先にあると学習されていたならば、該当する仮想インタフェースに転送される。
また、宛先ＭＡＣアドレスが、何れの仮想インタフェースの先にも学習されていないならば、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての仮想インタフェース宛にコピーして転送される。
【０１０４】
また、宛先ＭＡＣアドレスが、マルチキャストアドレスであった場合にも、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての仮想インタフェース宛にコピーして転送される。
【０１０５】
＜実施の形態４＞
本実施の形態では、マルチキャストグループに属する仮想インタフェースを学習し、ＶＰＮ内マルチキャストパケットの転送先を最小限にすることにより、網内トラフィックの低減を図るものである。以下の表６に、本実施の形態でのＭＡＣフォワーディングテーブル４０２の例を示す。
【０１０６】
【表６】
【０１０７】
ＶＰＮ番号１に属する仮想インタフェースが１，２，３である場合、学習されているマルチキャストアドレスに対しては必要なインタフェース１，２のみにパケットを転送することができる。なお、宛先ＭＡＣアドレス０１−００−５Ｅ−００−００−０１は、マルチキャストアドレスを示している。
【０１０８】
＜実施の形態５＞
本実施の形態では、ＭＡＣアドレスの新規学習や移動・エージングの結果を網内に流布するためにＭＡＣアドレスを告知するサーバを設けるようにした。図５は、ＭＡＣアドレス告知サーバ５０１を使用したネットワーク構成を示す構成図である。他の構成は図１と同様であり、詳細は省略する。
各アクセスルータ１０３からＭＡＣアドレス告知サーバ５０１へは、ＩＰルーティングネットワーク１０７を介して接続することができる。この場合、各アクセスルータ１０３は、ＩＰアドレスで識別される。ＭＡＣアドレス告知サーバ５０１は、以下の表７に例を示すＭＡＣアドレスデータベースを備えている。
【０１０９】
【表７】
【０１１０】
表７に示すＭＡＣアドレスデータベースは、ＶＰＮ番号に対して、この番号のＶＰＮに接続している端末１０１のＭＡＣアドレスと、この端末１０１を収容するアクセスルータ１０３の網側ＩＰアドレスを含む。例えば、ＶＰＮ番号１番に接続している端末１０１のＭＡＣアドレス００−００−００−００−００−０１は、ＩＰアドレス１０．１．１．１のアクセスルータ１０３に収容されていることがわかる。
【０１１１】
図６は、ＭＡＣアドレス告知サーバ５０１を利用したＭＡＣアドレスの告知の例を示す説明図である。時間の流れは図の上から下に向かっている。まず、ＩＰアドレス１０．１．１．１のアクセスルータ１０３が、新たに増設された端末１０１のＭＡＣアドレスを新規に学習する。アクセスルータ１０３に、新たな端末１０１が接続されると、この情報が入力され、アクセスルータ１０３は新規端末のＭＡＣアドレスを学習することになる。
【０１１２】
このアクセスルータ１０３は、自身のＩＰアドレスと、新規の端末１０１のＭＡＣアドレスと新規の端末１０１のＶＰＮ番号とをサーバに通知する。これは、ＭＡＣアドレスが収容されるＭＡＣフレームに、新規の端末１０１のＭＡＣアドレスと共にＶＰＮ番号を付加し、これをアクセスルータ１０３を示すＩＰアドレス１０．１．１．１のＩＰパケットにカプセル化し、このパケットをＭＡＣアドレス告知サーバ５０１に転送することで実現できる。
【０１１３】
上記パケットを受信したＭＡＣアドレス告知サーバ５０１では、受信したパケットにおけるＭＡＣアドレスとアクセスルータ１０３のＩＰアドレスの対応を、表７に示すような状態で学習テーブルに記録する。加えて、ＭＡＣアドレス告知サーバ５０１は、記録した対応情報を自身のＩＰパケットにカプセル化し、同一ＶＰＮ番号の端末を収容する、ＩＰアドレス１０．１．２．１および１０．１．３．１のアクセスルータ１０３に転送する。
【０１１４】
このとき、ＭＡＣアドレス告知サーバ５０１が送出するパケットの送元ＩＰアドレスを１０．１．１．１とすることによって、どのアクセスルータ１０３からの情報かを示すことができる。あるいは、送出するパケットのペイロードにアクセスルータのＩＰアドレスを挿入しても良い。
【０１１５】
以上の方法によって、アクセスルータ１０３が、新規に増設された端末１０１のＭＡＣアドレスを学習した場合や、既設の端末１０１がアクセスルータ１０３間で移動した場合などに、アクセスルータ１０３自身が、他の全てのアクセスルータ１０３に変更した内容を通知しなくても良いので、アクセスルータ１０３の負荷が軽減でき、またＩＰルーティングネットワーク１０７の資源も有効に利用することができる。
【０１１６】
＜実施の形態６＞
つぎに、本発明の他の形態について説明する。
未知アドレス宛にパケットを転送する場合、未知のアドレスが属するＶＰＮ全体へのマルチキャストを伴う。本実施の形態では、図７に示すように、マルチキャストのためのパケットコピーサーバ７０１を、ＩＰルーティングネットワーク１０７に設けるようにした。ＩＰルーティングネットワーク１０７は、前述した実施の形態と同様に、アクセスルータ１０３が接続されている。また、図７には示していないが、図１，２に示したように、アクセスルータ１０３内には、複数の仮想ハブ１０４が備えられている。
【０１１７】
本実施の形態の場合、前述したＩＰルーティングネットワーク１０７を介した他のアクセスルータ１０３へのパケットの転送は、アクセスルータ１０３とパケットコピーサーバ７０１に分散して存在することになる。ただし、宛先ＭＡＣアドレスが既知である場合には、送元のアクセスルータ１０３から、直接宛先のアクセスルータ１０３へパケットが転送される。
【０１１８】
以下、宛先ＭＡＣアドレスが未知である場合のパケット転送について、図８を用いて説明する。
送元のアクセスルータ１０３において、例えば宛先ＭＡＣアドレスが００−００−００−００−００−０４宛のパケットが入力し、このとき全てのアクセスルータ１０３のＭＡＣフォワーディングテーブルが、以下の表８のようであったとする。
【０１１９】
【表８】
【０１２０】
この場合、宛先ＭＡＣアドレスがわからないので、上記パケットを入力したアクセスルータ１０．１．１．１では、パケットが入力したＶＰＮに属する端末側仮想インタフェースのうち、すなわち上記ＶＰＮに属する仮想ハブにおいて、パケットが入力したものを除く全ての端末側仮想インタフェースと、網側のパケットコピーサーバ７０１に対して、上記パケットをコピーして出力する。
【０１２１】
一方、パケットコピーサーバ７０１では、受信したパケットが入力したＶＰＮに属する網側仮想インタフェースのうち、パケットが入力したものを除く全ての網側仮想インタフェース宛に（すなわちアクセスルータ１０．１．２．１およびアクセスルータ１０．１．３．１内の対応する仮想ハブ宛）にパケットを送信する。以上のような方法により、ＶＰＮ拠点が広域に分散している場合に、よりネットワークの中心に近い場所でパケットをコピーすることが可能となるため、ネットワークの資源を有効に利用することが可能となる。なお、パケットコピーサーバを複数用意して、ＶＰＮ毎や送元アクセスルータ毎に負荷を分散することもできる。また、パケットコピーサーバを複数接続して、冗長構成をとることもできる。
【０１２２】
＜実施の形態７＞
上記実施の形態では、未知アドレス宛のパケット転送について説明したが、以下に、ブロードキャスト宛のパケット転送について説明する。ブロードキャストアドレス宛パケットの転送は、このパケットが属するＶＰＮを収容するアクセスルータへのマルチキャストを伴う。ここでマルチキャストのためのパケットコピーサーバを導入した例を図７，８，９を用いて説明する。
【０１２３】
宛先ＭＡＣアドレスが既知である場合には、前述したように、送元アクセスルータから直接宛先アクセスルータへパケットが転送される。
これに対し、宛先ＭＡＣアドレスがブロードキャストである場合、まず送元アドレスが１０．１．１．１のアクセスルータにおいて、パケットが入力したＶＰＮに属する端末側仮想インタフェースのうち、パケットが入力したものを除く全ての端末側仮想インタフェースと、網側仮に接続されたパケットコピーサーバ７０１に対して、上記パケットをコピーして出力する。
【０１２４】
一方、パケットコピーサーバ７０１では、受信したパケットが入力したＶＰＮに属する網側仮想インタフェースのうち、パケットが入力したものを除く全ての網側仮想インタフェース宛、すなわちアドレスが１０．１．２．１のアクセスルータおよびアドレスが１０．１．３．１のアクセスルータの対応する仮想ハブ宛にパケットを送信する。これにより、ＶＰＮ拠点が広域に分散している場合に、よりネットワークの中心に近い場所でパケットを送出することが可能となるため、ネットワークの資源を有効に利用することが可能となる。なお、パケットコピーサーバを複数用意して、ＶＰＮ毎や送元アクセスルータ毎に負荷を分散しても良い。
【０１２５】
＜実施の形態８＞
つぎに、マルチキャストアドレス宛にパケットの転送の場合について説明する。この場合でも、マルチキャストアドレスが属するＶＰＮを収容するのアクセスルータへのマルチキャストを伴う。ここでマルチキャストのためのパケットコピーサーバを導入した例を図７，８，および表８を用いて説明する。この場合、パケットの転送はアクセスルータ１０３とパケットコピーサーバ７０１に分散して存在することになる。
【０１２６】
宛先ＭＡＣアドレスが既知である場合には、前述したように、送元アクセスルータから直接宛先アクセスルータへパケットが転送される。
これに対し、本実施の形態では、宛先ＭＡＣアドレスがマルチキャストであっても、前述のブロードキャストアドレスの場合と同様にする。したがって、本実施の形態においても、まず送元アクセスルータにおいて、パケットが入力したＶＰＮに属する端末側仮想インタフェースのうち、パケットが入力したものを除く全ての端末側仮想インタフェースと、網側仮想インタフェースに接続されたコピーサーバに対して、上記パケットをコピーして出力する。
【０１２７】
一方、パケットコピーサーバ７０１では、受信したパケットが入力したＶＰＮに属する網側仮想インタフェースのうち、パケットが入力したものを除く全ての網側仮想インタフェース宛に（すなわちアクセスルータ１０．１．２．１およびアクセスルータ１０．１．３．１の対応する仮想ハブ宛）にパケットを送信する。これにより、ＶＰＮ拠点が広域に分散している場合に、よりネットワークの中心に近い場所でパケットをコピーすることが可能となるため、ネットワークの資源を有効に利用することが可能となる。なお、本実施の形態においても、パケットコピーサーバを複数用意して、ＶＰＮ毎や送元アクセスルータ毎に負荷を分散しても良い。
【０１２８】
＜実施の形態９＞
つぎに、マルチキャスト宛のパケットの転送の場合、上述したブロードキャストアドレスの場合とは異なる方法でパケットを転送する場合について、図８を用いて説明する。アドレスが１０．１．１．１のアクセスルータに入力したパケットに対し、宛先ＭＡＣアドレスが既知のユニキャストである場合には、前述したように、送元アクセスルータから直接宛先アクセスルータへパケットが転送される。
【０１２９】
これに対し、宛先ＭＡＣアドレスがマルチキャストである場合、まず送元アクセスルータにおいて、パケットが入力したＶＰＮのマルチキャストグループに属する端末側仮想インタフェースのうち、パケットが入力したものを除く全ての端末側仮想インタフェースと、網側仮想インタフェースに接続されたコピーサーバに対して、上記パケットをコピーして出力する。このように、この実施の形態９では、ＶＰＮのマルチキャストグループに属する仮想インタフェースに、パケットを送出するようにしたところが、前述した実施の形態と異なる。
【０１３０】
一方、パケットコピーサーバ７０１では、受信したパケットが入力したＶＰＮのマルチキャストグループに属する網側仮想インタフェースのうち、パケットが人力したものを除く網側仮想インタフェース宛に（この図ではアクセスルータ１０．１．２．１とアクセスルータ１０．１．３．１の対応する仮想ハブ）にパケットを送信する。
これにより、ＶＰＮ拠点が広域に分散している場合に、よりネットワークの中心に近い場所でパケットをコピーすることが可能となるため、キャリア側のネットワークの資源を有効に利用することが可能となる。なお、パケットコピーサーバを複数用意して、ＶＰＮ毎や送元アクセスルータ館に負荷を分散しても良い。
【０１３１】
＜実施の形態１０＞
以下、端末のアドレスが変更されたり端末が新規に追加された場合に、他のアクセスルータやＬＡＮに対して、変更または追加された端末の位置を通知することについて説明する。この通知は、図２に示すパケットフォワーディング部２０７で行うようにしてもよく、また、仮想バス２０５に接続する通知制御部を新たに設けるようにしても良い。以下では、パケットフォワーディング部２０７で通知を行うようにした場合について図９のフローチャートを用いて説明する。
【０１３２】
まず、仮想インタフェースＡにあるパケットが入力すると、仮想ハブでは、入力したパケットにおけるレイヤ２の送元を示すＭＡＣアドレスＭが、学習済みかどうかを判定する（ステップＳ９０１））。
ＭＡＣアドレスＭが他の仮想インタフェースＢに対応付けて学習済みであった場合、仮想インタフェースＡと仮想インタフェースＢとの関係を判定する（ステップＳ９０２）。
【０１３３】
ここで、「仮想インタフェースＡが端末側であり、仮想インタフェースＢが網側である」と判定された場合には、ＭＡＣアドレスＭの学習エントリを仮想インタフェースＡに対応づけるように再登録する（ステップＳ９０４）とともに、同一仮想ハブに接続した全ての網側仮想インタフェースに宛てて、ＭＡＣアドレスＭを送元とするパケットを送出する（ステップＳ９０５）。このことにより、端末の追加や変更に関する情報を、他のアクセスルータやＬＡＮに対して通知できる。なお、宛先ＭＡＣアドレス以外には、パケットのヘッダだけなど、通知に必要な情報だけを送出するようにしても良い。
【０１３４】
また、「仮想インタフェースＡも仮想インタフェースＢも端末側である」と判定された場合には、ＭＡＣアドレスＭの学習エントリを仮想インタフェースＡに対応づけるように再登録する（ステップＳ９０６）。次いで、この場合は、他のアクセスルータなどの通知する必要がないので、端末側である仮想インタフェースＢに宛てて、ＭＡＣアドレスＭのパケットを送出する（ステップＳ９０７）。
【０１３５】
また、「仮想インタフェースＡが網側であり、仮想インタフェースＢが端末側である」と判定された場合には、ＭＡＣアドレスＭの学習エントリを仮想インタフェースＡに対応づけるように再登録する（ステップＳ９０８）。次いで、この場合も、他のアクセスルータなどの通知する必要がないので、端末側の仮想インタフェースＢに宛てて、ＭＡＣアドレスＭを含むパケットを送出する（ステップＳ９０９）。
また、「仮想インタフェースＡと仮想インタフェースＢとが同一の仮想インタフェースである」と判定された場合には、学習位置に変更が無いため、通知パケットは送信しない（終了）。
【０１３６】
一方、ＭＡＣアドレスＭが未学習で（ステップＳ９０１）、仮想インタフェースＡが網側の場合（ステップＳ９０３）、まず、ＭＡＣアドレスＭの学習エントリを仮想インタフェースＡに対応付けるように登録する（ステップＳ９１１）。次いで、同一仮想ハブに接続した全ての端末側仮想インタフェースに宛てて、ＭＡＣアドレスＭを送元とする通知パケットを送信する。
このことにより、端末の追加や変更に関する情報を、複数の端末が接続している顧客側のネットワークに対して通知できる。なお、宛先ＭＡＣアドレス以外には、パケットのヘッダだけなど、通知に必要な情報だけを送出するようにしても良い。
【０１３７】
また、ＭＡＣアドレスＭが未学習で（ステップＳ９０１）、仮想インタフェースＡが端末側の場合（ステップＳ９０３）、まず、ＭＡＣアドレスＭの学習エントリを仮想インタフェースＡに対応付けるように登録する（ステップＳ９１２）。次いで、同一仮想ハブに接続した全ての網側仮想インタフェースに宛てて、ＭＡＣアドレスＭを送元とするパケットを送出する（ステップＳ９１３）。
このことにより、端末の追加や変更に関する情報を、他のアクセスルータやＬＡＮに対して通知できる。なお、宛先ＭＡＣアドレス以外には、パケットのヘッダだけなど、通知に必要な情報だけを送出するようにしても良い。
【０１３８】
以上のように、同一ＶＰＮに属する顧客のＬＡＮに対しては、キャリア側のネットワーク（アクセスルータ１０３，ＩＰルーティングネットワーク１０７）は単一のスイッチングハブのように振る舞う。また、キャリアネットワーク（ＩＰルーティングネットワーク１０７）内では、顧客からの全てのパケットはユニキャストＩＰルーティングされる。
【０１３９】
顧客からのブロードキャストパケットに対しても、仮想ハブ１０４内でパケットを転送するため、ＩＰルーティングネットワーク１０７内では、同様にユニキャストＩＰルーティングで十分である。ＩＰルーティングネットワーク１０７内のＩＰコアルータは、公知のＩＰルーティングプロトコルを顧客のＶＰＮとは独立して動作させることができる。ＩＰコアルータが顧客のＭＡＣアドレスやＶＰＮ番号の学習から独立している。したがって堅牢かつ規模拡張性に優れたＶＰＮサービスを提供可能である。また、ＩＰルーティングネットワーク１０７上にＶＰＮを構築することで、ＩＰ層が物理伝送媒体や伝送方式の違いを吸収できる。
【０１４０】
なお、上述では、パケットフォワーディング部２０７（図２）が、仮想ハブ１０４において受け取ったパケット中のユーザＭＡＣヘッダ（６）内の送元ＭＡＣアドレスと、このパケットが通過した端末側仮想インタフェースまたは網側仮想インタフェースとの関係を学習し、この情報を記憶するようにしたが、これに限るものではない。例えば、仮想バス２０５に接続する学習部を、新たに設けるようにしても良い。学習部において、仮想ハブを通過するパケット内より、送り元のＭＡＣアドレスを取得してこのパケットが通過した仮想インタフェースとの関連を学習し、この学習した情報をテーブルに記憶するようにしても良い。
【０１４１】
学習部の学習によりテーブルには、ＭＡＣアドレスと対応する仮想インタフェースとの情報が記憶されている。したがって、パケットフォワーディング部では、パケットに収容されている宛先のＭＡＣアドレスをキーとしてテーブルを検索し、このＭＡＣアドレスに対応する仮想インタフェースの情報を取り出し、上記パケットを対応する仮想インタフェースに転送することができる。
【０１４２】
【発明の効果】
以上説明したように、本発明によれば、顧客に対しては簡易なインタフェースのＶＰＮを提供し、キャリアに対しては規模拡張性に優れたＶＰＮサービスを提供できるという優れた効果が得られる。
【図面の簡単な説明】
【図１】 本発明の実施の形態におけるパケットルーティング装置が用いられるネットワークの構成を示す構成図である。
【図２】 本発明の実施の形態におけるパケットルーティング方法が用いられるアクセスルータの構成と、パケットの構成とを示す構成図である。
【図３】 図２のテーブル２０８の構成を示す構成図である。
【図４】 本発明の実施の形態におけるパケットルーティング方法を説明するためのフローチャートである。
【図５】 本発明の他の形態におけるパケットルーティング装置が用いられるネットワークの構成を示す構成図である。
【図６】 本発明の他の形態におけるパケットルーティング方法を説明する説明図である。
【図７】 本発明の他の形態におけるパケットルーティング装置が用いられるネットワークの構成を示す構成図である。
【図８】 本発明の他の形態におけるパケットルーティング方法を説明する説明図である。
【図９】 本発明の他の形態におけるパケットルーティング方法を説明するためのフローチャートである。
【図１０】 従来のネットワークの構成を示す構成図である。
【図１１】 従来のネットワークの構成を示す構成図である。
【符号の説明】
１０１…端末、１０２…端末側仮想インタフェース多重分離部、１０３…アクセスルータ、１０４…仮想ハブ、１０５…網側仮想インタフェース多重分離部、１０６…ＩＰルーティング制御部、１０７…ＩＰルーティングネットワーク、２０１…端末側物理インタフェース、２０３…端末側仮想インタフェース、２０４…端末側仮想インタフェース終端部、２０５…仮想バス、２０６…網側仮想インタフェース終端部、２０７…パケットフォワーディング部、２０８…テーブル、２０９…網側仮想インタフェース。
【発明の属する技術分野】
本発明は、インターネットプロトコル（ＩＰ）ネットワークを介して構築されるＶＰＮ（Value Private Network）のパケットルーティング方法および装置に関する。より詳細には、顧客に対してレイヤ２での仮想プライベートネットワークを、規模拡張性に優れかつ低コストな状態で、ＩＰルーティングネットワーク上に実現するパケットルーティング方法に関するものである。
【０００２】
【従来の技術】
従来のＶＰＮサービスの実現方法は、キャリアネットワーク内でのパケット転送方式の違いにより、専用線，レイヤ３−ＶＰＮとレイヤ２−ＶＰＮの３種類に大別される。
まず、専用線について説明すると、従来の専用線の多くは、キャリア独自の通信プロトコルを使用して顧客の拠点間を１対１で接続する。このため、キャリア独自の高度な付加価値サービス、例えば、ＱｏＳサービスやセキュリティーサービスを提供できるという利点がある。
【０００３】
レイヤ３−ＶＰＮについて説明すると、レイヤ３−ＶＰＮにおいては、顧客からキャリアへ送信される入力パケット中の情報のうち、ＯＳＩ参照モデル第３層（レイヤ３）に対応する情報に基づいて、キャリアネットワーク内での経路制御を行う。１対１接続の専用線と異なり、顧客の複数拠点間の経路制御をキャリアネットワーク内で行うため、顧客の各拠点からキャリアネットワークへは、単一の仮想回線を接続するだけで、他の全ての拠点との通信が確保されるという利点がある。
【０００４】
つぎに、レイヤ２−ＶＰＮについて説明すると、レイヤ２−ＶＰＮでは、顧客からキャリアへ送信された入力パケットの情報のうち、ＯＳＩ参照モデル第２層（レイヤ２）に対応する情報に基づいて、キャリアネットワーク内での経路制御を行う。特にレイヤ２プロトコルとしては、イーサネット（登録商標）プロトコルあるいはＩＥＥＥ８０２．３プロトコルが利用されることが多く、この場合、複数のＶＰＮを識別するために、ＩＥＥＥ８０２．１Ｑで規定される拡張ヘッダ内の１２ビット長領域（ＶＬＡＮタグ）が用いられる。
【０００５】
レイヤ２−ＶＰＮでは、レイヤ３−ＶＰＮと同様、顧客の複数拠点間の経路制御をキャリアネットワーク内で行うため、顧客の各拠点からキャリアネットワークへは単一の仮想回線を接続するだけで、他の全ての拠点との通信が確保されるという利点がある。また、キャリアは、顧客パケットのレイヤ３情報については関知せずにレイヤ３情報を変更せずに転送するため、顧客は自身のＶＰＮ内で複数のレイヤプロトコルを自由に利用できるという利点がある。
【０００６】
さらに、多くの顧客がＬＡＮ内のレイヤ２プロトコルとしてイーサネットを利用しているため、キャリアのレイヤ２プロトコルにイーサネットを使用することにより、高度な専門知識を必要とせず、ＷＡＮであるＶＰＮと顧客におけるＬＡＮとをシームレスに接続できるという利点を有する。
【０００７】
【発明が解決しようとする課題】
しかしながら、上述した従来のパケットルーティングでは、各々つぎに示すような問題点があった。
まず、専用線について説明する。第１に、専用線で用いられている通信プロトコルは、顧客のＬＡＮでは一般に利用されていないため、顧客は専用線に接続するために高価な専用装置を用意する必要があり、ネットワークの構築に当たってはキャリア独自プロトコルに関する高度な専門知識が要求される。
【０００８】
第２に、専用線は、通常、顧客の拠点間を１対１で接続するのみであるため、３拠点以上を接続するためには、各拠点間を別々の専用線で１対１に接続する必要があり、拠点数が多い場合には高コストとなる。
第３に、上述のように複数拠点間を専用で１対１に接続する場合、各専用線間の経路制御を顧客側で行う必要があるため、接続拠点が多くなると顧客側の経路制御装置の負担が多くなる。
【０００９】
この状態を図１０に示す。一般に専用線では、拠点間（顧客側ルータ）を往路と復路との２つの仮想回線で接続するが、図１０に示すように、接続拠点数が４拠点の場合には１２本、５拠点の場合には２０本と、一般にＮ拠点では拠点数Ｎの二乗のオーダーで必要な仮想回線数が増大する。したがって、専用線の場合、接続拠点の規模を拡張することが容易ではない。
第４に、通常の専用線は、フレームリレーやＡＴＭといった単一の伝送方法を用いているため、ネットワークの途中にこれらの伝送方式のインフラストラクチャーが導入されていない場合には、サービスを提供できないという問題がある。
【００１０】
つぎに、レイヤ３−ＶＰＮについて説明する。レイヤ３−ＶＰＮでは、第１に、キャリア側が対応していないレイヤ３プロトコルを自由に利用して通信することができないという問題があった。また、たとえキャリア側が対応しているプロトコルでも、ＶＰＮをまたがってアドレスの割り当てを変更する場合には、通常、キャリア側ルータにおいてもアドレスの変更が必要になる。
【００１１】
他の例では、ＩＰv４からＩＰv６への移行などで顧客が利用するレイヤ３プロトコルに大きな変更がある場合には、経路制御に関わるキャリア側の全てのソフトウエアまたはハードウエアの更改が必要となり、更改のために莫大なコストがかかる。
また、顧客の複数のプロトコル間を相互に接続するには、接続のための機構も別途用意する必要がある。したがって、キャリアネットワークの構成が複雑になり、構築コストや管理コストが増大する。
【００１２】
第２に、プロバイダネットワークのエッジ（顧客からの回線を終端する部分）において、顧客のレイヤ３経路制御プロトコルを解釈する必要がある。図１１に、従来のレイヤ３−ＶＰＮにおけるエッジルータの構成を示した。ＢＧＰプロセス１１０３を介してキャリアネットワーク１１０４に接続するプロバイダエッジルータ１１０５では、接続する顧客の拠点ＬＡＮ１１０１と同じ数だけのレイヤ３経路制御のためのＩＧＰプロセス１１０２を起動する必要がある。しかし、レイヤ３経路制御の処理は、一般に複雑である。したがって、収容するユーザ数が多い場合、エッジに大きな処理能力が要求され、ひいてはネットワークのエッジのコスト上昇を招く。
【００１３】
第３に、ほとんどのレイヤ３−ＶＰＮでは、管理コスト低減のため顧客のレイヤ３情報を自動的にネットワーク全体に流布する機構が必要とされるが、この機構は一般に複雑であり、運用に際してキャリア側に高度な専門知識が要求される。このことは、ネットワーク運用のコスト上昇を招く。
【００１４】
第４に、ネットワーク内でのパケット転送にＭＰＬＳを利用する場合（例えばRFC2547『BGP/MPLS VPN』）では、効率的なパケット転送のためには、同一顧客のＶＰＮを収容するエッジ装置の全てのペア間で仮想回線を設定（フルメッシュ接続）する必要がある。したがって、ネットワークが大規模化すると、ネットワーク内の仮想回線の数は拠点数の二乗に比例して増大するため、規模の拡張が容易でないという問題がある。
【００１５】
つぎに、レイヤ２−ＶＰＮについて説明する。レイヤ２−ＶＰＮでは、つぎに示すように多くの課題を有している。第１に顧客のレイヤ２宛先アドレスに基づいてキャリアネットワーク内でのパケットの経路制御を行うが、イーサネットの場合、このレイヤ２アドレスの分布は階層化されておらずフラットなため、ネットワーク内のパケット交換機の経路制御には、顧客の全端末のレイヤ２アドレスを登録する必要がある。したがって、ネットワーク内の経路制御テーブルが、収容する顧客端末の数に応じて巨大化してしまう。この問題は、特にネットワークの中心部のパケット交換機において顕著であり、ネットワーク収容可能な端末数に対応して大きな制約を加えることになる。
【００１６】
第２に、顧客のパケットが属するＶＰＮを論理的に識別するために、ほとんどのキャリアネットワークの入り口では、ＩＥＥＥ８０２．１で規定されている拡張ヘッダ（ＶＬＡＮタグ）を付与するが、ＶＰＮ識別のための領域長は１２ビットである。これによって識別可能なＶＰＮの最大数は、４０９５（ＶＬＡＮタグ値＝０は予約されている）に制限されるため、大規模なネットワーク事業者にとっては、多数のユーザにＶＰＮサービスを提供する際の大きな妨げとなる。４０９５を越えるＶＰＮを収容するためにネットワーク装置を物理的に分離することも考えられるが、大規模ネットワークでは顧客や中継回線の収容設計および保守が複雑になる。
【００１７】
第３に、レイヤ２−ＶＰＮでは、キャリアネットワーク内でのパケット交換機において、顧客パケットのレイヤ２ヘッダに基づいて経路制御を行うが、レイヤ２プロトコルとして一般に利用されるイーサネットには、ネットワーク内でのホップ数をカウントあるいは制限するための標準的手法が存在しない。このことから、ネットワークトポロジの変化や経路制御のミスにより経路ループが形成された場合、経路ループにトラップされたパケットを排除する方法がない。
【００１８】
また、トラップされたパケットがブロードキャストパケットである場合、ループの分岐点で際限なくパケットがコピーされてしまうため、１カ所の経路操作のミスによってネットワーク全体が多大な影響を被る可能性が高い。また、このことから、リング型やメッシュ型などのループを含んだ冗長な物理トポロジーのネットワークの構築が困難であり、単純なスター型の物理トポロジーとならざるを得ない。したがって、従来のレイヤ２−ＶＰＮでは、可用性や信頼性の高いネットワークサービスを提供することが困難である。
【００１９】
第４に、レイヤ２−ＶＰＮは、例えばＩＥＥＥ８０２．３，あるいはイーサネットなどの単一の伝送方式に強く依存しているため、これらの伝送方式のインフラストラクチャーが導入されていない地域ではサービスが受けられないという問題がある。また、ネットワークの途中に他の伝送方式のインフラストラクチャーが存在する場合は、ネットワークの構成が複雑になるというネットワーク構築上の難点がある。
【００２０】
第５に、例えば網内のレイヤ２技術として一般に用いられているイーサネットでは、レイヤ２アドレスであるＭＡＣアドレスに基づくパケット転送を行うが、この場合、ＭＡＣアドレスを用いて柔軟な経路制御を行える一般的なプロトコルが、レイヤ２−ＶＰＮにはない。したがって、ある特定の宛先へのパケットや、特定の優先度を持ったパケットに対し、他のパケットと異なる経路を通過させることは非常に困難である。
【００２１】
本発明は、以上のような問題点を解消するためになされたものであり、前述したような従来のＶＰＮにおける問題を解決し、レイヤ３透過な仮想プライベートネットワークを、拡張性に優れた形態で提供できるようにすることを目的とする。
【００２２】
【課題を解決するための手段】
本発明のパケットルーティング方法は、ＬＡＮや端末を接続する端末側仮想インタフェースを複数もつレイヤ３の仮想プライベートネットワークを収容する共用ネットワークにおいて端末側仮想インタフェース間でパケットをＩＰルーティングしてレイヤ３の仮想プライベートネットワークにおいてレイヤ２の仮想プライベートネットワークを実現する方法であって、全ての端末側仮想インタフェースは、少なくとも１つの仮想ハブに接続され、全ての仮想ハブは少なくとも１つの端末側仮想インタフェースと、端末側仮想インタフェースと同じ仮想プライベートネットワークに属する少なくとも１つの網側仮想インタフェースとをもち、端末側および網側仮想インタフェースの間でパケットをレイヤ２ルーティングし、網側仮想インタフェースは、共用ネットワークを介して対向するレイヤ２仮想プライベートネットワーク装置の網側インタフェースにレイヤ３で接続し、共用ネットワークの内部でのパケットの転送は、ＩＰトンネルを利用してパケットを送受する共用ネットワークにおいて、入力パケットのレイヤ２ヘッダ内の少なくともレイヤ２アドレスであるＭＡＣアドレスと対応付けて、宛先となる仮想インタフェースを学習してテーブルに記憶し、宛先のＭＡＣアドレスが学習されていなく入力パケットが端末側仮想インタフェースから入力したものの場合、パケットが入力した仮想プライベートネットワークに属する全ての仮想インタフェースのうち、パケットが入力した仮想インタフェース以外の全ての仮想インタフェース各々に宛てて入力パケットを転送し、宛先のＭＡＣアドレスの宛先仮想インタフェースが学習されている場合には、対応する仮想インタフェース各々に宛てて入力パケットを転送し、テーブルに前述のＭＡＣアドレスが記録されていなければ、ＭＡＣアドレスとパケットが受信された仮想インタフェースとの対応を学習してテーブルに記憶し、網側仮想インタフェース宛のパケットについて、レイヤ２の仮想プライベートネットワーク識別子を付与して共用ネットワークの内部で転送するためのパケットに格納し、網側仮想インタフェースから受信したパケットに対してはこのパケットに格納された仮想ネットワーク識別子と受信側のレイヤ２仮想プライベートネットワーク装置が有する仮想プライベートネットワークを区別する識別子を比較することにより、受信したパケットに含まれる受信フレームが同一なレイヤ２仮想プライベートネットワークに属することを検査し、同一なレイヤ２仮想プライベートネットワークに属する受信フレームを受信したパケットから取り出し、仮想プライベートネットワーク識別子をはずしてフレームへ復元し、受信したパケットに含まれる送信元のＭＡＣアドレスがテーブルに記憶されていない場合は、受信したパケットに含まれる送信元の仮想プライベートネットワーク装置のＩＰアドレスと送信元のＭＡＣアドレスとの対応をテーブルに記録し、受信したパケットに含まれる送信先のＭＡＣアドレスがテーブルに記憶されている場合は、パケットに含まれる送信先のＭＡＣアドレスに対応する送信先にパケットに含まれるフレームを転送し、受信したパケットに含まれる送信先のＭＡＣアドレスがテーブルに記憶されていない場合は、パケットに含まれるフレームを全ての仮想インタフェースに転送することでパケットをＩＰルーティングネットワークを介してＩＰルーティングするようにしたものである。
この発明によれば、一度学習された仮想インタフェースに対し、対応するアドレスが宛先となっているパケットが、ＩＰルーティングネットワークに送出される。
【００２５】
上記発明において、テーブルに入力パケットが収容する宛先のアドレスに一致するものがない場合、入力パケットをこの入力パケットが入力した仮想ハブにおける入力パケットが入力した仮想インタフェース以外の全ての仮想インタフェースに送出する。
【００２６】
本発明のパケットルーティング方法は、入力パケットのレイヤ２ヘッダ内の少なくともレイヤ２アドレスと対応付けて、宛先となる仮想インタフェースを学習し、宛先レイヤ２アドレスが学習されていなく入力パケットが端末側仮想インタフェースから入力したものの場合、パケットが入力した仮想プライベートネットワークに属する全ての仮想インタフェースのうち、パケットが入力した仮想インタフェース以外の全ての仮想インタフェース各々に宛てて入力パケットを転送し、宛先レイヤ２アドレスの宛先仮想インタフェースが学習されている場合には、対応する仮想インタフェース各々に宛てて入力パケットを転送し、網側仮想インタフェース宛のパケットについて、仮想プライベートネットワーク識別子を付与し、ＩＰカプセル化パケットにカプセル化し、網側仮想インタフェースから受信したパケットに対してはＩＰカプセルを解除し、仮想プライベートネットワーク識別子をはずし、ＩＰカプセル化パケットをＩＰルーティングネットワークを介してＩＰルーティングするものである。
【００２７】
上記発明において、パケットの転送では、端末側仮想インタフェースから入力したパケットの宛先レイヤ２アドレスがブロードキャストアドレスである場合には、パケットが入力した仮想プライベートネットワークに属する全ての仮想ハブの端末側仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを含まない全ての端末側仮想インタフェースに宛ててパケットを転送する。また、端末から入力したパケットの転送では、宛先レイヤ２アドレスがマルチキャストアドレスである場合には、このパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、このパケットが入力した仮想インタフェースを含まない全ての仮想ハブに宛ててこのパケットを転送し、このパケットの転送各々において、対応する宛先の仮想プライベートネットワーク識別子でカプセル化する。
【００２８】
また、宛先レイヤ２アドレスがマルチキャストアドレスであり、かつマルチキャストアドレスが特定の仮想インタフェースに対応付けられている場合には、パケットの宛先マルチキャストアドレスに対応する特定の仮想インタフェースのうち、パケットが入力した仮想インタフェースを含まない上記特定の仮想インタフェースに宛てて入力パケットを転送する。また、ネットワークが、レイヤ２アドレスを告知するサーバを含み、送元レイヤ２アドレスの学習内容を変更する際、サーバに送元レイヤ２アドレスを通知し、サーバが同一仮想プライベートネットワークに含まれる他の全ての仮想ハブにレイヤ２アドレスを通知する。
【００２９】
また、共用ネットワークは、網側仮想インタフェースによって仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、宛先レイヤ２アドレスが学習されていない場合には、網側仮想インタフェースを通じてサーバへパケットを転送し、サーバにてパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、パケットが入力した仮想ハブ以外の全ての仮想ハブ各々に宛てて入力パケットを転送する。
【００３０】
また、共用ネットワークは、網側仮想インタフェースによって仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、宛先レイヤ２アドレスがブロードキャストアドレスである場合には、網側仮想インタフェースを通じてサーバへパケットを転送し、サーバにてパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうちパケットが入力した仮想ハブ以外の全ての仮想ハブ各々に宛てて入力パケットを転送する。
【００３１】
また、共用ネットワークは、網側仮想インタフェースによって仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、宛先レイヤ２アドレスがマルチキャストアドレスである場合には、網側仮想インタフェースを通じてサーバへパケットを転送し、サーバにてパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、パケットが入力した仮想ハブ以外の全ての仮想ハブ各々に宛てて入力パケットを転送する。
【００３２】
また、共用ネットワークは、網側仮想インタフェースによって仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、宛先レイヤ２アドレスがマルチキャストアドレスである場合には、網側仮想インタフェースを通じてサーバへパケットを転送し、サーバにてマルチキャストアドレスが特定の仮想ハブに対応づけれれている場合、パケットが入力した仮想ハブ以外の特定の仮想ハブ各々に宛てて入力パケットを転送する。
【００３３】
本発明の他の形態におけるパケットルーティング方法は、仮想インタフェースから入力したパケットの送元レイヤ２アドレスを、該当する仮想インタフェースと関係付けて学習し、仮想ハブ間を転送するパケットを、ＩＰユニキャストパケットにカプセル化し、第１の端末側仮想インタフェースから仮想ハブに入力したパケットに対して、パケットの送元レイヤ２アドレスが、同一の仮想ハブに収容された第２の端末側仮想インタフェースに対応付けて学習されている場合には、少なくともすでに学習されている第２の端末側仮想インタフェースに宛てて、送元レイヤ２アドレスを含む通知パケットを送信し、パケットの送元レイヤ２アドレスが、同一の仮想ハブに収容された他の網側仮想インタフェースに対応付けられて学習されている場合には、少なくとも同一仮想プライベートネットワークに属する他の全ての網側仮想インタフェースに宛てて、送元レイヤ２アドレスを含む通知パケットを送信し、パケットの送元レイヤ２アドレスが、同一の仮想ハブに収容された他の仮想インタフェースに対応付けて学習されていない場合には、少なくとも同一仮想プライベートネットワークに属する他の全ての網側仮想インタフェースに宛てて、送元レイヤ２アドレスを含む通知パケットを送信し、第１の網側仮想インタフェースから仮想ハブに入力したパケットに対して、パケットの送元レイヤ２アドレスが、同一の仮想ハブに収容された第３の端末側仮想インタフェースに対応付けて学習されている場合には、少なくともすでに学習されている第３の端末側仮想インタフェースに宛てて、送元レイヤ２アドレスを含む通知パケットを送信し、パケットの送元レイヤ２アドレスが、同一の仮想ハブに収容された他の仮想インタフェースに対応付けて学習されていない場合には、少なくとも同一仮想プライベートネットワークに属する他の全ての端末側仮想インタフェースに宛てて、送元レイヤ２アドレスを含む通知パケットを送信し、仮想ハブに入力したパケットに対して、パケットの宛先レイヤ２アドレスがすでに特定の仮想インタフェースに対応付けて学習されている場合には、少なくとも特定の仮想インタフェースに宛ててパケットを転送し、パケットの宛先レイヤ２アドレスが特定の仮想インタフェースに対応付けて学習されていない場合には、同一仮想プライベートネットワークに属するパケットが転送されてきた仮想インタフェース以外の全ての仮想インタフェース宛にパケットをコピーして転送するものである。
【００３４】
上記発明において、共用ネットワークは、網側仮想インタフェースによって仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、宛先レイヤ２アドレスが学習されていない場合には、網側仮想インタフェースを通じてサーバへパケットを転送し、サーバにてパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、パケットが入力した仮想ハブ以外の全ての仮想ハブ各々に宛てて入力パケットを転送する。
【００３５】
【発明の実施の形態】
以下、本発明の実施の形態について図を参照して説明する。
＜実施の形態１＞
図１は、本発明の第１の実施の形態におけるパケットルーティング方法を用いたキャリアネットワークの構成を示す構成図である。ＶＰＮサービスの顧客（端末）１０１は、端末側仮想インタフェース多重分離部１０２を介し、アクセスルータ１０３内の対応する仮想ハブ１０４に接続している。各端末１０１は、物理的なインタフェースを介して端末側仮想インタフェース多重分離部１０２に接続している。端末側仮想インタフェース多重分離部１０２では、同一物理媒体上に複数の仮想インタフェースを多重化し、また分離している。
【００３６】
この場合、各端末側の仮想インタフェースを識別するために使えるものとして、例えばＩＥＥＥ８０２．１のＶＬＡＮタグ、ＡＴＭのＶＣ、フレームリレーのＤＬＣＩ，ＴＤＭのタイムスロット、ＦＤＭの周波数、ＣＤＭのコード、ＩＳＤＮのチャネル，「ＰＰＰ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ」等が挙げられるが、これに限るものではない。
各仮想ハブ１０４は、網側仮想インタフェース多重分離部（識別子多重分離部）１０５を介し、ＩＰルーティング制御部１０６を通り、ＩＰルーティングネットワーク１０７に接続している。なお、ＩＰ（インターネットプロトコル）には、ＩＰｖ４やＩＰｖ６などがあるが、どちらでもよく、また、これらに限るものではない。
【００３７】
各アクセスルータ１０３は、ＩＰルーティングネットワーク１０７を介してＩＰトンネリングで接続されている。また、異なるアクセスルータ１０３に収容され、同一の顧客に対応する仮想ハブ１０４同士は、網側仮想インタフェース１０８によって接続されている。
アクセスルータ１０３を含みこれより網側が、異なるＶＰＮが共有する共有ネットワークである。
【００３８】
図２は、図１に示したアクセスルータ１０３の構成を示す構成図である。図２（ａ）に示すように、アクセスルータ１０３は、各顧客に対応して複数の仮想ハブ１０４を備えている。顧客側の端末側物理インタフェース２０１を通過してきた多重化されたパケットは、端末側仮想インタフェース多重分離部１０２で分離され、端末側仮想インタフェース２０３を通って対応する仮想ハブ１０４内の対応する端末側仮想インタフェース終端部２０４に転送される。端末側仮想インタフェース多重分離部１０２で分離されたパケットには、端末の所属を示すＶＬＡＮタグが含まれている。
【００３９】
端末側仮想インタフェース多重分離部１０２は、ＶＬＡＮタグとＶＰＮ番号が対応付けられたテーブルを参照することで、分離したパケットを対応する仮想ハブ１０４内の端末側仮想インタフェース終端部２０４に転送する。このとき、ＶＬＡＮタグはパケットよりはずされる。
なお、各仮想ハブ（仮想インタフェース）を識別するために使えるものとして、例えばＩＥＥＥ８０２．１のＶＬＡＮタグ、ＡＴＭのＶＣ、フレームリレーのＤＬＣＩ，ＴＤＭのタイムスロット、ＦＤＭの周波数、ＣＤＭのコード、ＩＳＤＮのチャネル、ＷＤＭの波長等が挙げられるが、これに限るものではない。
【００４０】
以上のことにより仮想ハブ１０４の端末側仮想インタフェース終端部２０４に入力したパケットは、図２（ｂ）に示すように、ユーザＭＡＣヘッダフィールド（６），ユーザペイロードフィールド（７），ユーザＦＣＳフィールド（８）から構成されている。
【００４１】
各端末側仮想インタフェース終端部２０４，網側仮想インタフェース終端部２０６，およびパケットフォワーディング部２０７は、仮想バス２０５によって相互に接続されている。上述したように、ある端末側仮想インタフェース終端部２０４に図２（ｂ）に示すような構成のパケットが入力すると、パケットフォワーディング部２０７は、このパケットを受け取る。パケットを受け取ったパケットフォワーディング部２０７は、受け取ったパケット中のユーザＭＡＣヘッダ（６）内の送元ＭＡＣアドレスと、このパケットが通過した端末側仮想インタフェース終端部２０４との関係を学習し、この情報をテーブル２０８に記憶する。
【００４２】
上記学習を行ったパケットフォワーディング部２０７は、受け取ったパケットの中のユーザＭＡＣヘッダ（６）内の宛先ＭＡＣアドレスとこれを転送すべき網側仮想インタフェース終端部２０６との関係を示す情報を、テーブル２０８より取得し、取得した情報に基づいてパケットを対応する網側仮想インタフェース終端部２０６に転送する。パケットを受け取った各網側仮想インタフェース終端部２０６は、このパケットを網側仮想インタフェース２０９を介して網側仮想インタフェース多重分離部１０５に転送する。
【００４３】
各仮想ハブ１０４の各網側仮想インタフェース終端部２０６より複数のパケットを受け取った網側仮想インタフェース多重分離部１０５は、各々のパケットに、図２（ｃ）に示すように、キャリアＩＰヘッダ（２）とＶＰＮ−ＩＤ（ＶＰＮ識別子）（３）および予約（４），タイプ（５）の情報を付加し、各パケットを多重化する。
【００４４】
パケットに付加する情報について説明すると、まず、キャリアＩＰヘッダ（２）は、ＩＰルーティングネットワーク内で入り口のアクセスルータから出口のアクセスルータまでパケットを転送するために用いられる。なお、キャリアＩＰヘッダ（２）のフィールドには、ＴＯＳフィールドを備えているが、ここは、ユーザペイロードフィールド（７）部分のＩＰヘッダのＴＯＳや、ユーザＭＡＣヘッダフィールド（６）のＩＥＥＥ８０２．１優先度ビットと関連付けて、ＩＰルーティングネットワーク内での優先制御に用いることもできる。
【００４５】
ＶＰＮ−ＩＤ（３）の領域は、同一のアクセスルータ１０３内における複数の仮想ハブ１０４を識別するために用いられる。ユーザのＶＰＮには、全て一意のＶＰＮ−ＩＤを割り当て、このＶＰＮ−ＩＤと同じ値をアクセスルータ内の仮想ハブに割り当てることによって、同一のＩＰトンネル内に複数のＶＰＮのパケットを多重化することができる。また、予約（４）の領域は、将来のための予約部分である。タイプ（５）は、この後のユーザＭＡＣヘッダの種類を表す領域である。これによって、ユーザの希望にあわせたレイヤ２技術を利用することが可能となる。
【００４６】
網側仮想インタフェース多重分離部１０５で多重化されたパケットは、ＩＰルーティング制御部１０６により、図２（ｄ）に示すように、キャリアＭＡＣヘッダ（１），キャリアＦＣＳ（９）が付加され、網側物理インタフェース２１１に送り出される。キャリアＦＣＳフィールド（９）の値により、必要に応じてエラーチェックを行うことができる。
【００４７】
なお、各仮想インタフェースを識別するために使えるものとして、例えば、ＩＰカプセル化されたパケット中に記録された送元ＩＰアドレス、宛先ＩＰアドレス、ＶＰＮ識別子、ＩＥＥＥ８０２．１のＶＬＡＮタグ、ＷＤＭの波長などを利用できる。
【００４８】
図３は、テーブル２０８に含まれる各種テーブルの構成を示す構成図である。テーブル２０８は、ＭＡＣアドレス学習テーブル３０１と、ＭＡＣフォワーディングテーブル３０２と、仮想インタフェース・ＶＰＮテーブル３０３と、ＶＰＮ・仮想インタフェーステーブル３０４とを備えている。
ＭＡＣアドレス学習テーブル３０１は、仮想ハブ１０４に入力されたパケットの送元ＭＡＣアドレスを、通過してきた仮想ハブ１０４内の仮想インタフェース（仮想インタフェース終端部）と対応付けて学習する。
【００４９】
この学習内容は、ＭＡＣフォワーディングテーブル３０２に反映され、パケットフォワーディング部２０７が、パケットを宛先の仮想インタフェース終端部にフォワーディングする際に用いられる。
仮想インタフェース・ＶＰＮテーブル３０３は、パケットが入力した仮想インタフェース終端部から、このパケットが属するＶＰＮ番号を得るために用いられる。仮想インタフェース・ＶＰＮテーブル３０３は、端末側仮想インタフェース・ＶＰＮテーブル３０３ａと網側仮想インタフェース・ＶＰＮテーブル３０３ｂとから構成されている。
【００５０】
端末側仮想インタフェース・ＶＰＮテーブル３０３ａは、パケットが入力した端末側仮想インタフェース多重部１０２において、このパケットが属するＶＰＮ番号および仮想インタフェース番号を得るために用いる。
また、ＶＰＮ・仮想インタフェーステーブル３０４は、あるＶＰＮ番号に属する全ての仮想インタフェース（仮想インタフェース終端部）を示し、宛先を学習していないパケットなどの転送に用いる。
【００５１】
以下の表１、表２にＭＡＣアドレス学習テーブルの例を示す。
【００５２】
【表１】
ＭＡＣアドレス学習テーブルは、入力仮想インタフェースの種類の識別子、ＶＰＮの番号、インタフェース番号、および送元ＭＡＣアドレスを含む。例えば、表１のはじめの行の内容は、「ＶＰＮ番号１に属する網側仮想インタフェースから、送元ＭＡＣアドレス００−００−００−００−００−０１のパケットが入力したことを学習した」ことを示す。表１では、複数のＶＰＮ番号に属するエントリが同一のテーブル上に示されているが、各ＶＰＮ番号に対応する仮想ハブ内のテーブルで、各々別のＭＡＣアドレス学習テーブルを保持しても良い。また、各ＶＰＮのテーブル毎にサイズを制限する機構を持っても良い。また、送元ＭＡＣアドレスのみならず、パケットの優先度毎に異なるエントリを保持することもできる。
【００５４】
表１でＭＡＣアドレスを学習した内容から、ＭＡＣフォワーディングテーブルを作成した例を以下の表２に示す。
【００５５】
【表２】
表２に示すように、ＭＡＣフォワーディングテーブルでは、パケットの属するＶＰＮ番号と宛先ＭＡＣアドレスとから、宛先仮想インタフェースの種類と、宛先仮想インタフェースの番号を得る。ＭＡＣアドレス学習テーブルの人力仮想インタフェースの種類、ＶＰＮ番号、入力インタフェース番号、送元ＭＡＣアドレスが、各々、ＭＡＣフォワーディングテーブルの宛先仮想インタフェースの種類、ＶＰＮ番号、宛先仮想インタフェース番号、宛先ＭＡＣアドレスに対応する。
【００５７】
表２でも、複数のＶＰＮ番号に属するエントリが同一のテーブル上に示されているが、各ＶＰＮ番号に対応する仮想ハブ内のテーブルで、各々別のＭＡＣアドレス学習テーブルを保持しても良い。
表２に基づいてパケットをフォワーディングする場合、例えば、ＶＰＮ番号１の仮想ハブ１０４の端末側仮想インタフェース終端部２０４に入力した宛先ＭＡＣアドレス００−００−００−００−００−０１宛のパケットは、仮想インタフェース番号が１の網側仮想インタフェース終端部２０６に出力される。
【００５８】
以下に示す表３，表４は、各々端末側仮想インタフェース・ＶＰＮテーブルおよび網側仮想インタフェース・ＶＰＮテーブルの例である。なお、表４におけるＶＰＮ番号は、パケットに含まれるものである。
【００５９】
【表３】
【表４】
表３において、「端末側物理インタフェース番号」は、パケットを入出力する各端末側物理インタフェースを示している。「ＶＬＡＮタグ」は、同一の端末側物理インタフェースにおいて入出力するパケットに含まれるＶＬＡＮタグの値を表している。「ＶＰＮ番号」は、同一アクセルルータ内の各仮想ハブに対応し、「仮想インタフェース番号」は、同一アクセスルータ内の各仮想ハブに対応する。
【００６２】
端末側仮想インタフェース・ＶＰＮテーブルは、端末側仮想インタフェース多重部１０２において、端末側物理インタフェースから入力するパケットに対し、対応する仮想ハブと仮想インタフェースを得るために用いる。表３に示したように、例えば、番号２０１の端末側物理インタフェースで受信したパケットが、値１００５のＶＬＡＮタグを含むとき、このパケットは番号１のＶＰＮに属し、番号１のＶＰＮの仮想ハブの、番号１の仮想インタフェースに転送するものであることが分かる。
【００６３】
端末側仮想インタフェース・ＶＰＮテーブルは、端末側仮想インタフェース多重部１０２において、仮想ハブから端末側仮想インタフェースに出力されたパケットを、端末側物理インタフェースに多重するためにも用いることができる。このときは、パケットを出力した仮想ハブが属するＶＰＮ番号と仮想インタフェース番号とを元にして表を検索し、パケットを出力すべき端末側物理インタフェース番号とＶＬＡＮタグとを得る。表３に示したように、例えば、ＶＰＮ番号２の仮想ハブから番号３の仮想インタフェースに対して出力されたパケットは、ＶＬＡＮタグとして値１２３４を付与し、番号２０１の端末側物理インタフェースに出力されるものであることが分かる。
【００６４】
端末側インタフェース・ＶＰＮテーブルは、パケットが入力した網側仮想インタフェース多重部１０５において、このパケットが属するＶＰＮ番号および仮想インタフェース番号を得るために用いる。
表４において、「ローカルＩＰアドレス」は、このアクセスルータに設定されたＩＰアドレスを示し、「リモートＩＰアドレス」は、ＩＰルーティングネットワークを介して接続されている接続先のアクセスルータのＩＰアドレスを示している。また、「ＶＰＮ番号」は、網側仮想インタフェース１０８において入出力されるパケットに含まれるＶＰＮ番号である。「仮想ハブ番号」は、アクセスルータ内でパケットを送受信する仮想ハブの番号を示し、「仮想インタフェース番号」は、仮想ハブにおける仮想インタフェース番号である。
【００６５】
ＩＰルーティング制御部１０６から網側仮想インタフェース多重部１０５に対してＩＰパケットが入力した場合を例にとると、まず、パケットに含まれる宛先ＩＰアドレスと送元ＩＰアドレスとＶＰＮ番号とが、各々表４中の「ローカルＩＰアドレス」と「送元ＩＰアドレス」と「ＶＰＮ番号」とに対応づけられ、テーブルが検索される。
つぎに、この検索で得られた「仮想ハブ番号」と「仮想インタフェース番号」とに基づいて、パケットフォワーディング部は、対応する仮想ハブの対応する仮想インタフェースにパケットを転送する。
【００６６】
表４によれば、例えばＩＰアドレス１０．２．２．２を持つアクセスルータから、ＩＰルーティングネットワークを介してＩＰアドレス１０．１．１．１を持つアクセスルータに入力したパケットが、ＶＰＮ番号２を含む場合、このパケットは、番号２の仮想ハブの番号２の仮想インタフェースに転送されることになる。
【００６７】
さらに、網側仮想インタフェース・ＶＰＮテーブル３０３ｂは、網側仮想インタフェース多重部１０５において、各仮想ハブ１０４から網側仮想インタフェース１０８に対して出力されたパケットを、ＩＰルーティング制御部１０６へ多重して転送するためにも用いる。このときは、パケットを出力した仮想ハブ１０４の番号と仮想インタフェースの番号とを元に、テーブルが検索され、パケットを付与すべきＶＰＮ番号とキャリアＩＰヘッダ内の送元および宛先アドレスが取り出される。
【００６８】
なお、表４の例では、「ＶＰＮ番号」と「仮想ハブのＶＰＮ番号」とは同じ値となっているが、これらの値は必ずしも一致する必要はなく、運用の形態によって異なる値を用いるようにしても良い。
【００６９】
つぎに示す表５は、ＶＰＮ・仮想インタフェーステーブルの例である。
【００７０】
【表５】
ＶＰＮ・仮想インタフェーステーブルは、ＶＰＮ番号から、このＶＰＮに属する全ての仮想インタフェースの番号を得るために用いられる。表５によれば、例えば、ＶＰＮ番号１に属する仮想インタフェースは２つあり、これらが、仮想インタフェース番号が１の網側仮想インタフェースと、仮想インタフェース番号が２の端末側仮想インタフェースとであることがわかる。ＶＰＮ・仮想インタフェーステーブルは、パケットを何れかの仮想インタフェース終端部に転送するときに、宛先ＭＡＣアドレスが学習されていない場合に、ＶＰＮ番号に属する仮想インタフェース宛に、必要数のパケットをコピーして各々を転送するために用いられる。
【００７２】
以下、図４を用いて、アクセスルータ１０３による図１，２に示したネットワークにおける典型的なパケットの転送手順を説明する。図４では、ある拠点のＬＡＮに接続された端末１０１から、他の拠点のＬＡＮに接続された端末１０１へのパケットを転送する場合を例にしている。
まず、端末１０１からパケットが出力されると（ステップＳ４００）、出力されたパケットは、送元のアクセスルータ１０３内で、端末側仮想インタフェース多重分離部１０２から、対応する仮想ハブ１０４の対応する端末側仮想インタフェース終端部２０４に入力する（ステップＳ４０１）。
【００７３】
端末側仮想インタフェース終端部２０４にパケットが到達すると、パケットフォワーディング部２０７は、パケットが到達した（通過する）端末仮想インタフェース終端部２０４の入力インタフェース番号とこれが網側であるか端末側であるかとの情報に、送元ＭＡＣアドレスを対応付け、これをテーブル２０８のＭＡＣアドレス学習テーブル３０１に登録する（ステップＳ４０２）。
【００７４】
つぎに、パケットフォワーディング部２０７は、宛先ＭＡＣアドレスを、ＭＡＣフォワーディングテーブル３０２から検索し、対応する宛先の網側仮想インタフェース終端部２０６へパケットを転送する（ステップＳ４０３）。このとき、対応する宛先が複数存在する場合、パケットフォワーディング部２０７は、パケットを必要数コピーして、各々の宛先の網側仮想インタフェース終端部へパケットを転送する。また、ＭＡＣアドレスフォワーディングテーブル３０２に必要な情報がない場合、パケットフォワーディング部２０７は、ＶＰＮ・仮想インタフェーステーブル３０４を参照し、ＶＰＮ番号に属する仮想インタフェース宛に、必要数のパケットをコピーして各々を転送する。
【００７５】
以上のことにより、所定の網側仮想インタフェース終端部２０６へパケットが転送されると、パケットは網側仮想インタフェース２０９を介して網側仮想インタフェース多重分離部１０５に転送されて多重化され、ＩＰルーティング制御部１０６により網側仮想インタフェース１０８へ出力される（ステップＳ４０４）。なお、この例では、ＩＰルーティングネットワーク１０７（図１）を介して接続された他の仮想ハブ１０４を経由してパケットを転送する場合について示してある。出力されたパケットは、ＩＰパケットにカプセル化され、ＩＰルーティングネットワーク１０７内を宛先の仮想ハブ１０４のあるアクセスルータ１０３まで転送される（ステップＳ４０５）。
【００７６】
ＩＰルーティングネットワーク１０７内を転送されて宛先のアクセスルータ１０３に上記ＩＰパケットが入力すると（ステップＳ４０６）、まず、ＩＰルーティング制御部１０６によりＩＰカプセルが解除される。次いで、このパケットは、網側仮想インタフェース多重分離部１０５で分離され、対応する仮想ハブ１０４の対応する網側仮想インタフェース終端部２０６に転送される。パケットを受け取った仮想ハブ１０４では、パケットフォワーディング部２０７が、パケットが到達した（通過する）網側仮想インタフェース終端部２０６の入力インタフェース番号とこれが網側であるか端末側であるかとの情報に、送元ＭＡＣアドレスを対応付け、これをテーブル２０８のＭＡＣアドレス学習テーブル３０１に登録する。
【００７７】
次いで、パケットフォワーディング部２０７は、パケットの宛先ＭＡＣアドレスをＭＡＣアドレスフォワーディングテーブル３０２から検索し、宛先に対応する端末側仮想インタフェース終端部２０４へパケットを転送する（ステップＳ４０８）。転送されて端末側仮想インタフェース終端部２０４を通過したパケットは、端末側仮想インタフェース多重分離部１０２で他のパケットと共に多重化されて出力され（ステップＳ４０９）、最終的に宛先の端末１０１に到達する（ステップＳ４１０）。
【００７８】
以上説明したように、本実施の形態によれば、キャリアのエッジに上述したアクセスルータ１０３を設けるようにし、顧客の各拠点（端末）とキャリアネットワーク（ＩＰルーティングネットワーク１０７）との間を、単一の仮想回線（仮想ハブ１０４）で接続し、これにより他の全拠点との通信が確保する状態とした。したがって、ＶＰＮの接続対地数が増加しても顧客とキャリアとの間の仮想回線を増設する必要が無くなる。
また、キャリアネットワークのエッジ（アクセスルータ１０３）の負荷が軽減され、ネットワークが、顧客および顧客グループ数（ＶＰＮ数）の大規模化に対応可能となる。
【００７９】
また、本実施の形態によれば、キャリアネットワークの中心部における経路制御を、顧客やＶＰＮ数，あるいは各ＶＰＮ内の接続拠点やＶＰＮ内アドレッシングとは独立して管理できるので、堅牢かつ規模拡大生に優れたＶＰＮサービスが提供できる。また、本実施の形態では、伝送方式や伝送媒体に依存しないので、複数種類の伝送媒体や伝送方式にまたがってＶＰＮサービス用のネットワークの構築が可能となる。また、顧客の各種レイヤ３プロトコルに対して透過な接続が提供でき、顧客はレイヤ３プロトコルを自由に選択することが可能になる。
【００８０】
＜実施の形態２＞
以下、本発明の第２の実施の形態について説明する。本実施の形態では、仮想ハブ１０４内において、スパニングツリーアルゴリズム等のループ回避機構の有無により、パケットフォワーディング部２０７による仮想バス２０５を介したパケットの転送先に制限を設けるようにした。
【００８１】
はじめに、ループ回避機構を設けていない場合の、仮想ハブ１０４におけるパケット転送動作について説明する。網側仮想インタフェースから受信したパケットは、ＭＡＣアドレス学習機能により、入力した仮想インタフェースと送元ＭＡＣアドレスとを対応付けて学習された後、転送ステップにおいて、ユーザＭＡＣヘッダ以降のフレームの宛先ＭＡＣアドレスが検査される。
【００８２】
宛先ＭＡＣアドレスが、すでに何れかの端末側仮想インタフェース終端部２０４の先にあると学習され、ＭＡＣフォワーディングテーブル３０２に用意されていたならば、上記パケットは、学習されていた端末側仮想インタフェース終端部２０４へ転送される。これは、前述した実施の形態と同様である。
【００８３】
これに対し、宛先ＭＡＣアドレスが、何れの端末側仮想インタフェース終端部２０４の先にも学習されていない場合、パケットフォワーディング部２０７は、この仮想ハブ１０４の全ての端末側仮想インタフェース終端部２０４宛に、当該パケットをコピーして転送する。また、宛先ＭＡＣアドレスが、ブロードキャストアドレスであった場合にも、パケットフォワーディング部２０７は、当該仮想ハブ１０４の全ての端末側仮想インタフェース終端部２０４宛に、上記パケットをコピーして転送する。
【００８４】
このように、本実施の形態では、ループ回避機構がない場合、もしくは機能していない場合、網側仮想インタフェース２０９から入力したパケットは、同一の仮想ハブ１０４内の別の網側仮想インタフェース２０９（網側仮想インタフェース終端部２０６）には転送しないようにした。このことにより、網側から仮想ハブ１０４内に入力されたパケットが、網側に戻ることが抑制されるので、キャリア側のネットワークであるＩＰルーティングネットワーク１０７内で、上記パケットがループするのが防がれるようになる。
【００８５】
一方、端末側から仮想ハブ内にパケットが入力された場合は、上述とは異なり、端末側に戻すようにしても良い。端末１０１より端末側仮想インタフェース２０３，端末側仮想インタフェース終端部２０４を介して入力したパケットは、パケットフォワーディング部２０７におけるＭＡＣアドレス学習機能により、通過した端末側仮想インタフェース終端部２０４と送元ＭＡＣアドレスとを対応付けて学習された後、宛先ＭＡＣアドレスが検査される。
【００８６】
ＭＡＣフォワーディングテーブル３０２内に、パケットに格納されている宛先ＭＡＣアドレスが、すでに何れかの端末側または網側仮想インタフェースの先にあると学習されていたならば、パケットフォワーディング部２０７は、当該パケットを該当する網側仮想インタフェース終端部２０６に転送する。
【００８７】
一方、ＭＡＣフォワーディングテーブル３０２内に、上記宛先ＭＡＣアドレスに対応する仮想インタフェース終端部の情報が無ければ（学習されていなければ）、パケットフォワーディング部２０７は、同一の仮想ハブ１０４内で、パケットが入力した端末側仮想インタフェース終端部２０４を除く、全ての端末側仮想インタフェース終端部２０４および網側仮想インタフェース終端部２０６に、パケットをコピーして転送する。
【００８８】
また、宛先ＭＡＣアドレスが、ブロードキャストアドレスであった場合にも、パケットフォワーディング部２０７は、当該仮想ハブ１０４の全ての仮想インタフェースのうち、パケットが入力した端末側仮想インタフェース終端部２０４を除く全ての端末仮想インタフェース終端部２０４および網側仮想インタフェース終端部２０６宛に、上記パケットをコピーして転送する。
【００８９】
つぎに、仮想ハブ１０４間に、スパニングツリーアルゴリズム等のループ回避機構を設けた場合について説明する。この例では、仮想インタフェース（端末側仮想インタフェース終端部２０４，網側仮想インタフェース終端部２０６）の内のいくつかは、ループ回避機構によってブロックされている場合があるが、以後の記述では、ブロックされている仮想インタフェースに対しては、パケットの宛先から除外することとする。
【００９０】
例えば、ある網側仮想インタフェース２０９を経由して網側仮想インタフェース終端部２０６に入力したパケットは、パケットフォワーディング部２０７により、入力した網側仮想インタフェース終端部２０６と送元ＭＡＣアドレスとを対応付けて学習された後、パケット内の宛先ＭＡＣアドレスが検査される。
この検査の結果得られた宛先ＭＡＣアドレスが、ＭＡＣアドレスフォワーディングテーブル３０２内に、すでに何れかの端末側仮想インタフェース２０３の先にあると学習されていたならば、学習されていた端末側仮想インタフェース終端部２０４へ転送される。
【００９１】
一方、パケット内の宛先ＭＡＣアドレスが、ＭＡＣアドレスフォワーディングテーブル３０２内に、何れの端末側仮想インタフェース終端部２０４との関連も学習されていない場合はつぎのようになる。この場合、パケットフォワーディング部２０７は、この仮想ハブ１０４に接続した仮想インタフェースの終端部のうち、パケットが入力した端末側仮想インタフェース終端部２０４と、ループ回避機構によりブロックされているもの以外の全ての仮想インタフェース終端部に、コピーして転送する。
【００９２】
また、宛先ＭＡＣアドレスが、ブロードキャストアドレスであった場合にも、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェース終端部２０６と、ループ回避機構によりブロックされているもの以外の全ての仮想インタフェース終端部宛に、コピーして転送される。ただし、パケットフォワーディング部２０７は、網側仮想インタフェースから入力したパケットを、別の網側仮想インタフェースに出力する際に、入力したカプセル化パケット中のキャリアＩＰヘッダのＴＴＬ値を少なくとも１以上減算して、別の網側仮想インタフェースから出力する。このことにより、万一ループが発生しても、無限にループすることが回避できる。また、ユーザペイロードの中のＩＰヘッダのＴＴＬ値を減算するようにしても良い。
【００９３】
一方、端末側から入力したパケットについては、以降に説明するように、制限はない。端末側仮想インタフェース終端部２０４から仮想ハブ１０４に入力したパケットは、パケットフォワーディング部２０７の学習機能により、通過した端末側仮想インタフェース終端部２０４と送元ＭＡＣアドレスとを対応付けて学習された後、パケット内の宛先ＭＡＣアドレスが検査される。パケット内の宛先ＭＡＣアドレスが、ＭＡＣアドレスフォワーディングテーブル３０２内で、すでに何れかの仮想インタフェース終端部の先にあると学習されていたならば、パケットフォワーディング部２０７は、パケットを該当する仮想インタフェース終端部に転送する
【００９４】
また、パケット内の宛先ＭＡＣアドレスが、何れの仮想インタフェース終端部とも関連付けられていない場合、この仮想ハブ１０４に接続した仮想インタフェースの終端部のうち、パケットが通過した端末側仮想インタフェース終端部２０４を除く全ての仮想インタフェース終端部にコピーして転送される。また、宛先ＭＡＣアドレスが、ブロードキャストアドレスであった場合にも、当該仮想ハブ１０４に接続した仮想インタフェースの終端部のうち、パケットが通過した端末側仮想インタフェース終端部２０４を除く全ての仮想インタフェース終端部にコピーして転送される。
【００９５】
＜実施の形態３＞
つぎに、本発明の第３の実施の形態について説明する。本実施の形態でも、仮想ハブ間でスパニングツリーアルゴリズム等のループ回避機構を動作させていない場合の、仮想ハブにおけるパケット転送動作を説明する。ただし、本実施の形態では、宛先ＭＡＣアドレスがマルチキャストアドレスであるものを扱う場合について説明する。
【００９６】
網側仮想インタフェースから受信したＭＡＣフレームは、ＭＡＣアドレス学習機能により、入力した仮想インタフェースと送元ＭＡＣアドレスとを対応付けて学習された後、転送ステップにおいて、宛先ＭＡＣアドレスを検査される。
宛先ＭＡＣアドレスがすでに何れかの端末側仮想インタフェースの先にあると学習されていたならば、学習されていた仮想インタフェースへ転送される。
【００９７】
また、宛先ＭＡＣアドレスが、何れの仮想インタフェースの先にも学習されていないならば、当該仮想ハブに接続した全ての端末側仮想インタフェース宛にコピーして転送される。また、宛先ＭＡＣアドレスが、マルチキャストアドレスであった場合にも、当該仮想ハブに接続した全ての端末側仮想インタフェース（終端部）宛にコピーして転送される。
ここで、同一の仮想ハブに、複数の網側インタフェースが接続している場合でも、上記のように、網側仮想インタフェースから入力したパケットは別の網側仮想インタフェースには転送しないことに注意が必要である。これは、ネットワーク内でパケットがループするのを防ぐためである。
【００９８】
一方、端末側仮想インタフェースから入力したパケットは、ＭＡＣアドレス学習機能により、入力した端末側仮想インタフェースと送元ＭＡＣアドレスとを対応付けて学習された後、転送ステップにおいて、宛先ＭＡＣアドレスを検査される。
【００９９】
宛先ＭＡＣアドレスが、すでに何れかの端末側または網側仮想インタフェースの先にあると学習されていたならば、該当する仮想インタフェースに転送される。また、上記宛先ＭＡＣアドレスが、何れの仮想インタフェースの先にも学習されていないならば、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての仮想インタフェース宛にコピーして転送される。
また、宛先ＭＡＣアドレスが、マルチキャストアドレスであった場合にも、当該仮想ハブに接続した全ての仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての仮想インタフェース宛にコピーして転送される。
【０１００】
つぎに、仮想ハブ間でスパニングツリーアルゴリズム等のループ回避機構を動作させている場合の動作を以下に記す。このとき、仮想インタフェースの内のいくつかはスパニングツリーアルゴリズム等によってブロックされている場合があるが、以後の記述では、ブロックされている仮想インタフェースに対しては、パケットの宛先から除外することとする。網側仮想インタフェースから入力したパケットは、ＭＡＣアドレス学習機能により、入力した網側仮想インタフェースと送元ＭＡＣアドレスとを対応付けて学習された後、転送ステップにおいて、宛先ＭＡＣアドレスを検査される。
【０１０１】
宛先ＭＡＣアドレスがすでに何れかの端末側仮想インタフェースの先にあると学習されていたならば、学習されていた仮想インタフェースへ転送される。また、宛先ＭＡＣアドレスが、何れの端末側仮想インタフェースの先にも学習されていないならば、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての宛先に必要に応じてコピーして転送される。
【０１０２】
また、宛先ＭＡＣアドレスが、マルチキャストアドレスであった場合にも、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての仮想インタフェース宛に必要に応じてコピーして転送される。ただし、上記の様に網側仮想インタフェースから入力したパケットを、別の網側仮想インタフェースに出力する際には、万一ループが発生してもよいように、入力したカプセル化パケット中のキャリアＩＰヘッダのＴＴＬ値を少なくとも１以上減算して、別の網側仮想インタフェースから出力することが望ましい。
【０１０３】
端末側仮想インタフェースからパケットが入力すると、ＭＡＣアドレス学習機能により、まず、入力した端末側仮想インタフェースと送元ＭＡＣアドレスとを対応付けて学習された後、転送ステップにおいて、宛先ＭＡＣアドレスを検査される。宛先ＭＡＣアドレスが、すでに何れかの仮想インタフェースの先にあると学習されていたならば、該当する仮想インタフェースに転送される。
また、宛先ＭＡＣアドレスが、何れの仮想インタフェースの先にも学習されていないならば、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての仮想インタフェース宛にコピーして転送される。
【０１０４】
また、宛先ＭＡＣアドレスが、マルチキャストアドレスであった場合にも、当該仮想ハブに接続した仮想インタフェースのうち、パケットが入力した端末側仮想インタフェースを除く全ての仮想インタフェース宛にコピーして転送される。
【０１０５】
＜実施の形態４＞
本実施の形態では、マルチキャストグループに属する仮想インタフェースを学習し、ＶＰＮ内マルチキャストパケットの転送先を最小限にすることにより、網内トラフィックの低減を図るものである。以下の表６に、本実施の形態でのＭＡＣフォワーディングテーブル４０２の例を示す。
【０１０６】
【表６】
ＶＰＮ番号１に属する仮想インタフェースが１，２，３である場合、学習されているマルチキャストアドレスに対しては必要なインタフェース１，２のみにパケットを転送することができる。なお、宛先ＭＡＣアドレス０１−００−５Ｅ−００−００−０１は、マルチキャストアドレスを示している。
【０１０８】
＜実施の形態５＞
本実施の形態では、ＭＡＣアドレスの新規学習や移動・エージングの結果を網内に流布するためにＭＡＣアドレスを告知するサーバを設けるようにした。図５は、ＭＡＣアドレス告知サーバ５０１を使用したネットワーク構成を示す構成図である。他の構成は図１と同様であり、詳細は省略する。
各アクセスルータ１０３からＭＡＣアドレス告知サーバ５０１へは、ＩＰルーティングネットワーク１０７を介して接続することができる。この場合、各アクセスルータ１０３は、ＩＰアドレスで識別される。ＭＡＣアドレス告知サーバ５０１は、以下の表７に例を示すＭＡＣアドレスデータベースを備えている。
【０１０９】
【表７】
表７に示すＭＡＣアドレスデータベースは、ＶＰＮ番号に対して、この番号のＶＰＮに接続している端末１０１のＭＡＣアドレスと、この端末１０１を収容するアクセスルータ１０３の網側ＩＰアドレスを含む。例えば、ＶＰＮ番号１番に接続している端末１０１のＭＡＣアドレス００−００−００−００−００−０１は、ＩＰアドレス１０．１．１．１のアクセスルータ１０３に収容されていることがわかる。
【０１１１】
図６は、ＭＡＣアドレス告知サーバ５０１を利用したＭＡＣアドレスの告知の例を示す説明図である。時間の流れは図の上から下に向かっている。まず、ＩＰアドレス１０．１．１．１のアクセスルータ１０３が、新たに増設された端末１０１のＭＡＣアドレスを新規に学習する。アクセスルータ１０３に、新たな端末１０１が接続されると、この情報が入力され、アクセスルータ１０３は新規端末のＭＡＣアドレスを学習することになる。
【０１１２】
このアクセスルータ１０３は、自身のＩＰアドレスと、新規の端末１０１のＭＡＣアドレスと新規の端末１０１のＶＰＮ番号とをサーバに通知する。これは、ＭＡＣアドレスが収容されるＭＡＣフレームに、新規の端末１０１のＭＡＣアドレスと共にＶＰＮ番号を付加し、これをアクセスルータ１０３を示すＩＰアドレス１０．１．１．１のＩＰパケットにカプセル化し、このパケットをＭＡＣアドレス告知サーバ５０１に転送することで実現できる。
【０１１３】
上記パケットを受信したＭＡＣアドレス告知サーバ５０１では、受信したパケットにおけるＭＡＣアドレスとアクセスルータ１０３のＩＰアドレスの対応を、表７に示すような状態で学習テーブルに記録する。加えて、ＭＡＣアドレス告知サーバ５０１は、記録した対応情報を自身のＩＰパケットにカプセル化し、同一ＶＰＮ番号の端末を収容する、ＩＰアドレス１０．１．２．１および１０．１．３．１のアクセスルータ１０３に転送する。
【０１１４】
このとき、ＭＡＣアドレス告知サーバ５０１が送出するパケットの送元ＩＰアドレスを１０．１．１．１とすることによって、どのアクセスルータ１０３からの情報かを示すことができる。あるいは、送出するパケットのペイロードにアクセスルータのＩＰアドレスを挿入しても良い。
【０１１５】
以上の方法によって、アクセスルータ１０３が、新規に増設された端末１０１のＭＡＣアドレスを学習した場合や、既設の端末１０１がアクセスルータ１０３間で移動した場合などに、アクセスルータ１０３自身が、他の全てのアクセスルータ１０３に変更した内容を通知しなくても良いので、アクセスルータ１０３の負荷が軽減でき、またＩＰルーティングネットワーク１０７の資源も有効に利用することができる。
【０１１６】
＜実施の形態６＞
つぎに、本発明の他の形態について説明する。
未知アドレス宛にパケットを転送する場合、未知のアドレスが属するＶＰＮ全体へのマルチキャストを伴う。本実施の形態では、図７に示すように、マルチキャストのためのパケットコピーサーバ７０１を、ＩＰルーティングネットワーク１０７に設けるようにした。ＩＰルーティングネットワーク１０７は、前述した実施の形態と同様に、アクセスルータ１０３が接続されている。また、図７には示していないが、図１，２に示したように、アクセスルータ１０３内には、複数の仮想ハブ１０４が備えられている。
【０１１７】
本実施の形態の場合、前述したＩＰルーティングネットワーク１０７を介した他のアクセスルータ１０３へのパケットの転送は、アクセスルータ１０３とパケットコピーサーバ７０１に分散して存在することになる。ただし、宛先ＭＡＣアドレスが既知である場合には、送元のアクセスルータ１０３から、直接宛先のアクセスルータ１０３へパケットが転送される。
【０１１８】
以下、宛先ＭＡＣアドレスが未知である場合のパケット転送について、図８を用いて説明する。
送元のアクセスルータ１０３において、例えば宛先ＭＡＣアドレスが００−００−００−００−００−０４宛のパケットが入力し、このとき全てのアクセスルータ１０３のＭＡＣフォワーディングテーブルが、以下の表８のようであったとする。
【０１１９】
【表８】
この場合、宛先ＭＡＣアドレスがわからないので、上記パケットを入力したアクセスルータ１０．１．１．１では、パケットが入力したＶＰＮに属する端末側仮想インタフェースのうち、すなわち上記ＶＰＮに属する仮想ハブにおいて、パケットが入力したものを除く全ての端末側仮想インタフェースと、網側のパケットコピーサーバ７０１に対して、上記パケットをコピーして出力する。
【０１２１】
一方、パケットコピーサーバ７０１では、受信したパケットが入力したＶＰＮに属する網側仮想インタフェースのうち、パケットが入力したものを除く全ての網側仮想インタフェース宛に（すなわちアクセスルータ１０．１．２．１およびアクセスルータ１０．１．３．１内の対応する仮想ハブ宛）にパケットを送信する。以上のような方法により、ＶＰＮ拠点が広域に分散している場合に、よりネットワークの中心に近い場所でパケットをコピーすることが可能となるため、ネットワークの資源を有効に利用することが可能となる。なお、パケットコピーサーバを複数用意して、ＶＰＮ毎や送元アクセスルータ毎に負荷を分散することもできる。また、パケットコピーサーバを複数接続して、冗長構成をとることもできる。
【０１２２】
＜実施の形態７＞
上記実施の形態では、未知アドレス宛のパケット転送について説明したが、以下に、ブロードキャスト宛のパケット転送について説明する。ブロードキャストアドレス宛パケットの転送は、このパケットが属するＶＰＮを収容するアクセスルータへのマルチキャストを伴う。ここでマルチキャストのためのパケットコピーサーバを導入した例を図７，８，９を用いて説明する。
【０１２３】
宛先ＭＡＣアドレスが既知である場合には、前述したように、送元アクセスルータから直接宛先アクセスルータへパケットが転送される。
これに対し、宛先ＭＡＣアドレスがブロードキャストである場合、まず送元アドレスが１０．１．１．１のアクセスルータにおいて、パケットが入力したＶＰＮに属する端末側仮想インタフェースのうち、パケットが入力したものを除く全ての端末側仮想インタフェースと、網側仮に接続されたパケットコピーサーバ７０１に対して、上記パケットをコピーして出力する。
【０１２４】
一方、パケットコピーサーバ７０１では、受信したパケットが入力したＶＰＮに属する網側仮想インタフェースのうち、パケットが入力したものを除く全ての網側仮想インタフェース宛、すなわちアドレスが１０．１．２．１のアクセスルータおよびアドレスが１０．１．３．１のアクセスルータの対応する仮想ハブ宛にパケットを送信する。これにより、ＶＰＮ拠点が広域に分散している場合に、よりネットワークの中心に近い場所でパケットを送出することが可能となるため、ネットワークの資源を有効に利用することが可能となる。なお、パケットコピーサーバを複数用意して、ＶＰＮ毎や送元アクセスルータ毎に負荷を分散しても良い。
【０１２５】
＜実施の形態８＞
つぎに、マルチキャストアドレス宛にパケットの転送の場合について説明する。この場合でも、マルチキャストアドレスが属するＶＰＮを収容するのアクセスルータへのマルチキャストを伴う。ここでマルチキャストのためのパケットコピーサーバを導入した例を図７，８，および表８を用いて説明する。この場合、パケットの転送はアクセスルータ１０３とパケットコピーサーバ７０１に分散して存在することになる。
【０１２６】
宛先ＭＡＣアドレスが既知である場合には、前述したように、送元アクセスルータから直接宛先アクセスルータへパケットが転送される。
これに対し、本実施の形態では、宛先ＭＡＣアドレスがマルチキャストであっても、前述のブロードキャストアドレスの場合と同様にする。したがって、本実施の形態においても、まず送元アクセスルータにおいて、パケットが入力したＶＰＮに属する端末側仮想インタフェースのうち、パケットが入力したものを除く全ての端末側仮想インタフェースと、網側仮想インタフェースに接続されたコピーサーバに対して、上記パケットをコピーして出力する。
【０１２７】
一方、パケットコピーサーバ７０１では、受信したパケットが入力したＶＰＮに属する網側仮想インタフェースのうち、パケットが入力したものを除く全ての網側仮想インタフェース宛に（すなわちアクセスルータ１０．１．２．１およびアクセスルータ１０．１．３．１の対応する仮想ハブ宛）にパケットを送信する。これにより、ＶＰＮ拠点が広域に分散している場合に、よりネットワークの中心に近い場所でパケットをコピーすることが可能となるため、ネットワークの資源を有効に利用することが可能となる。なお、本実施の形態においても、パケットコピーサーバを複数用意して、ＶＰＮ毎や送元アクセスルータ毎に負荷を分散しても良い。
【０１２８】
＜実施の形態９＞
つぎに、マルチキャスト宛のパケットの転送の場合、上述したブロードキャストアドレスの場合とは異なる方法でパケットを転送する場合について、図８を用いて説明する。アドレスが１０．１．１．１のアクセスルータに入力したパケットに対し、宛先ＭＡＣアドレスが既知のユニキャストである場合には、前述したように、送元アクセスルータから直接宛先アクセスルータへパケットが転送される。
【０１２９】
これに対し、宛先ＭＡＣアドレスがマルチキャストである場合、まず送元アクセスルータにおいて、パケットが入力したＶＰＮのマルチキャストグループに属する端末側仮想インタフェースのうち、パケットが入力したものを除く全ての端末側仮想インタフェースと、網側仮想インタフェースに接続されたコピーサーバに対して、上記パケットをコピーして出力する。このように、この実施の形態９では、ＶＰＮのマルチキャストグループに属する仮想インタフェースに、パケットを送出するようにしたところが、前述した実施の形態と異なる。
【０１３０】
一方、パケットコピーサーバ７０１では、受信したパケットが入力したＶＰＮのマルチキャストグループに属する網側仮想インタフェースのうち、パケットが人力したものを除く網側仮想インタフェース宛に（この図ではアクセスルータ１０．１．２．１とアクセスルータ１０．１．３．１の対応する仮想ハブ）にパケットを送信する。
これにより、ＶＰＮ拠点が広域に分散している場合に、よりネットワークの中心に近い場所でパケットをコピーすることが可能となるため、キャリア側のネットワークの資源を有効に利用することが可能となる。なお、パケットコピーサーバを複数用意して、ＶＰＮ毎や送元アクセスルータ館に負荷を分散しても良い。
【０１３１】
＜実施の形態１０＞
以下、端末のアドレスが変更されたり端末が新規に追加された場合に、他のアクセスルータやＬＡＮに対して、変更または追加された端末の位置を通知することについて説明する。この通知は、図２に示すパケットフォワーディング部２０７で行うようにしてもよく、また、仮想バス２０５に接続する通知制御部を新たに設けるようにしても良い。以下では、パケットフォワーディング部２０７で通知を行うようにした場合について図９のフローチャートを用いて説明する。
【０１３２】
まず、仮想インタフェースＡにあるパケットが入力すると、仮想ハブでは、入力したパケットにおけるレイヤ２の送元を示すＭＡＣアドレスＭが、学習済みかどうかを判定する（ステップＳ９０１））。
ＭＡＣアドレスＭが他の仮想インタフェースＢに対応付けて学習済みであった場合、仮想インタフェースＡと仮想インタフェースＢとの関係を判定する（ステップＳ９０２）。
【０１３３】
ここで、「仮想インタフェースＡが端末側であり、仮想インタフェースＢが網側である」と判定された場合には、ＭＡＣアドレスＭの学習エントリを仮想インタフェースＡに対応づけるように再登録する（ステップＳ９０４）とともに、同一仮想ハブに接続した全ての網側仮想インタフェースに宛てて、ＭＡＣアドレスＭを送元とするパケットを送出する（ステップＳ９０５）。このことにより、端末の追加や変更に関する情報を、他のアクセスルータやＬＡＮに対して通知できる。なお、宛先ＭＡＣアドレス以外には、パケットのヘッダだけなど、通知に必要な情報だけを送出するようにしても良い。
【０１３４】
また、「仮想インタフェースＡも仮想インタフェースＢも端末側である」と判定された場合には、ＭＡＣアドレスＭの学習エントリを仮想インタフェースＡに対応づけるように再登録する（ステップＳ９０６）。次いで、この場合は、他のアクセスルータなどの通知する必要がないので、端末側である仮想インタフェースＢに宛てて、ＭＡＣアドレスＭのパケットを送出する（ステップＳ９０７）。
【０１３５】
また、「仮想インタフェースＡが網側であり、仮想インタフェースＢが端末側である」と判定された場合には、ＭＡＣアドレスＭの学習エントリを仮想インタフェースＡに対応づけるように再登録する（ステップＳ９０８）。次いで、この場合も、他のアクセスルータなどの通知する必要がないので、端末側の仮想インタフェースＢに宛てて、ＭＡＣアドレスＭを含むパケットを送出する（ステップＳ９０９）。
また、「仮想インタフェースＡと仮想インタフェースＢとが同一の仮想インタフェースである」と判定された場合には、学習位置に変更が無いため、通知パケットは送信しない（終了）。
【０１３６】
一方、ＭＡＣアドレスＭが未学習で（ステップＳ９０１）、仮想インタフェースＡが網側の場合（ステップＳ９０３）、まず、ＭＡＣアドレスＭの学習エントリを仮想インタフェースＡに対応付けるように登録する（ステップＳ９１１）。次いで、同一仮想ハブに接続した全ての端末側仮想インタフェースに宛てて、ＭＡＣアドレスＭを送元とする通知パケットを送信する。
このことにより、端末の追加や変更に関する情報を、複数の端末が接続している顧客側のネットワークに対して通知できる。なお、宛先ＭＡＣアドレス以外には、パケットのヘッダだけなど、通知に必要な情報だけを送出するようにしても良い。
【０１３７】
また、ＭＡＣアドレスＭが未学習で（ステップＳ９０１）、仮想インタフェースＡが端末側の場合（ステップＳ９０３）、まず、ＭＡＣアドレスＭの学習エントリを仮想インタフェースＡに対応付けるように登録する（ステップＳ９１２）。次いで、同一仮想ハブに接続した全ての網側仮想インタフェースに宛てて、ＭＡＣアドレスＭを送元とするパケットを送出する（ステップＳ９１３）。
このことにより、端末の追加や変更に関する情報を、他のアクセスルータやＬＡＮに対して通知できる。なお、宛先ＭＡＣアドレス以外には、パケットのヘッダだけなど、通知に必要な情報だけを送出するようにしても良い。
【０１３８】
以上のように、同一ＶＰＮに属する顧客のＬＡＮに対しては、キャリア側のネットワーク（アクセスルータ１０３，ＩＰルーティングネットワーク１０７）は単一のスイッチングハブのように振る舞う。また、キャリアネットワーク（ＩＰルーティングネットワーク１０７）内では、顧客からの全てのパケットはユニキャストＩＰルーティングされる。
【０１３９】
顧客からのブロードキャストパケットに対しても、仮想ハブ１０４内でパケットを転送するため、ＩＰルーティングネットワーク１０７内では、同様にユニキャストＩＰルーティングで十分である。ＩＰルーティングネットワーク１０７内のＩＰコアルータは、公知のＩＰルーティングプロトコルを顧客のＶＰＮとは独立して動作させることができる。ＩＰコアルータが顧客のＭＡＣアドレスやＶＰＮ番号の学習から独立している。したがって堅牢かつ規模拡張性に優れたＶＰＮサービスを提供可能である。また、ＩＰルーティングネットワーク１０７上にＶＰＮを構築することで、ＩＰ層が物理伝送媒体や伝送方式の違いを吸収できる。
【０１４０】
なお、上述では、パケットフォワーディング部２０７（図２）が、仮想ハブ１０４において受け取ったパケット中のユーザＭＡＣヘッダ（６）内の送元ＭＡＣアドレスと、このパケットが通過した端末側仮想インタフェースまたは網側仮想インタフェースとの関係を学習し、この情報を記憶するようにしたが、これに限るものではない。例えば、仮想バス２０５に接続する学習部を、新たに設けるようにしても良い。学習部において、仮想ハブを通過するパケット内より、送り元のＭＡＣアドレスを取得してこのパケットが通過した仮想インタフェースとの関連を学習し、この学習した情報をテーブルに記憶するようにしても良い。
【０１４１】
学習部の学習によりテーブルには、ＭＡＣアドレスと対応する仮想インタフェースとの情報が記憶されている。したがって、パケットフォワーディング部では、パケットに収容されている宛先のＭＡＣアドレスをキーとしてテーブルを検索し、このＭＡＣアドレスに対応する仮想インタフェースの情報を取り出し、上記パケットを対応する仮想インタフェースに転送することができる。
【０１４２】
【発明の効果】
以上説明したように、本発明によれば、顧客に対しては簡易なインタフェースのＶＰＮを提供し、キャリアに対しては規模拡張性に優れたＶＰＮサービスを提供できるという優れた効果が得られる。
【図面の簡単な説明】
【図１】 本発明の実施の形態におけるパケットルーティング装置が用いられるネットワークの構成を示す構成図である。
【図２】 本発明の実施の形態におけるパケットルーティング方法が用いられるアクセスルータの構成と、パケットの構成とを示す構成図である。
【図３】 図２のテーブル２０８の構成を示す構成図である。
【図４】 本発明の実施の形態におけるパケットルーティング方法を説明するためのフローチャートである。
【図５】 本発明の他の形態におけるパケットルーティング装置が用いられるネットワークの構成を示す構成図である。
【図６】 本発明の他の形態におけるパケットルーティング方法を説明する説明図である。
【図７】 本発明の他の形態におけるパケットルーティング装置が用いられるネットワークの構成を示す構成図である。
【図８】 本発明の他の形態におけるパケットルーティング方法を説明する説明図である。
【図９】 本発明の他の形態におけるパケットルーティング方法を説明するためのフローチャートである。
【図１０】 従来のネットワークの構成を示す構成図である。
【図１１】 従来のネットワークの構成を示す構成図である。
【符号の説明】
１０１…端末、１０２…端末側仮想インタフェース多重分離部、１０３…アクセスルータ、１０４…仮想ハブ、１０５…網側仮想インタフェース多重分離部、１０６…ＩＰルーティング制御部、１０７…ＩＰルーティングネットワーク、２０１…端末側物理インタフェース、２０３…端末側仮想インタフェース、２０４…端末側仮想インタフェース終端部、２０５…仮想バス、２０６…網側仮想インタフェース終端部、２０７…パケットフォワーディング部、２０８…テーブル、２０９…網側仮想インタフェース。
Claims (9)
- ＬＡＮや端末を接続する端末側仮想インタフェースを複数もつレイヤ３の仮想プライベートネットワークを収容する共用ネットワークにおいて前記端末側仮想インタフェース間でパケットをＩＰルーティングしてレイヤ３の仮想プライベートネットワークにおいてレイヤ２の仮想プライベートネットワークを実現する方法であって、全ての前記端末側仮想インタフェースは、少なくとも１つの仮想ハブに接続され、全ての仮想ハブは少なくとも１つの前記端末側仮想インタフェースと、前記端末側仮想インタフェースと同じ前記仮想プライベートネットワークに属する少なくとも１つの網側仮想インタフェースとをもち、前記端末側および網側仮想インタフェースの間でパケットをレイヤ２ルーティングし、前記網側仮想インタフェースは、前記共用ネットワークを介して対向するレイヤ２仮想プライベートネットワーク装置の網側インタフェースにレイヤ３で接続し、前記共用ネットワークの内部でのパケットの転送は、ＩＰトンネルを利用してパケットを送受する前記共用ネットワークにおいて、
入力パケットのレイヤ２ヘッダ内の少なくともレイヤ２アドレスであるＭＡＣアドレスと対応付けて、宛先となる前記仮想インタフェースを学習してテーブルに記憶し、
前記宛先のＭＡＣアドレスが学習されていなく前記入力パケットが前記端末側仮想インタフェースから入力したものの場合、前記パケットが入力した前記仮想プライベートネットワークに属する全ての仮想インタフェースのうち、前記パケットが入力した仮想インタフェース以外の全ての前記仮想インタフェース各々に宛てて前記入力パケットを転送し、前記宛先のＭＡＣアドレスの宛先仮想インタフェースが学習されている場合には、対応する前記仮想インタフェース各々に宛てて前記入力パケットを転送し、
前記テーブルに前記ＭＡＣアドレスが記録されていなければ、前記ＭＡＣアドレスと前記パケットが受信された前記仮想インタフェースとの対応を学習して前記テーブルに記憶し、
前記網側仮想インタフェース宛の前記パケットについて、レイヤ２の仮想プライベートネットワーク識別子を付与して前記共用ネットワークの内部で転送するためのパケットに格納し、
前記網側仮想インタフェースから受信したパケットに対してはこのパケットに格納された仮想ネットワーク識別子と受信側のレイヤ２仮想プライベートネットワーク装置が有する仮想プライベートネットワークを区別する識別子を比較することにより、受信したパケットに含まれる受信フレームが同一なレイヤ２仮想プライベートネットワークに属することを検査し、同一なレイヤ２仮想プライベートネットワークに属する前記受信フレームを受信した前記パケットから取り出し、仮想プライベートネットワーク識別子をはずしてフレームへ復元し、
受信した前記パケットに含まれる送信元のＭＡＣアドレスが前記テーブルに記憶されていない場合は、受信した前記パケットに含まれる送信元の仮想プライベートネットワーク装置のＩＰアドレスと送信元のＭＡＣアドレスとの対応を前記テーブルに記録し、
受信した前記パケットに含まれる送信先のＭＡＣアドレスが前記テーブルに記憶されている場合は、前記パケットに含まれる送信先のＭＡＣアドレスに対応する送信先に前記パケットに含まれるフレームを転送し、
受信した前記パケットに含まれる送信先のＭＡＣアドレスが前記テーブルに記憶されていない場合は、前記パケットに含まれるフレームを全ての前記仮想インタフェースに転送することで
前記パケットをＩＰルーティングネットワークを介してＩＰルーティングする
ことを特徴とするパケットルーティング方法。 - 請求項１記載のパケットルーティング方法において、
前記パケットの転送では、前記端末側仮想インタフェースから入力した前記パケットの宛先レイヤ２アドレスがブロードキャストアドレスである場合には、前記パケットが入力した前記仮想プライベートネットワークに属する全ての前記仮想ハブの前記仮想インタフェースのうち、前記パケットが入力した前記端末側仮想インタフェースを含まない全ての 前記仮想インタフェースに宛てて前記パケットを転送することを特徴とするパケットルーティング方法。 - 請求項１記載のパケットルーティング方法において、
前記端末から入力したパケットの転送では、前記宛先レイヤ２アドレスがマルチキャストアドレスである場合には、前記入力したパケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、前記入力したパケットが入力した仮想インタフェースを含まない全ての前記仮想ハブに宛てて前記入力したパケットを転送し、
前記入力したパケットの転送各々において、対応する宛先の前記仮想プライベートネットワーク識別子とＩＰヘッダとでカプセル化する
ことを特徴とするパケットルーティング方法。 - 請求項１記載のパケットルーティング方法において、
前記宛先レイヤ２アドレスがマルチキャストアドレスであり、かつ前記マルチキャストアドレスが特定の前記仮想インタフェースに対応付けられている場合には、前記パケットの前記マルチキャストアドレスに対応する特定の前記仮想インタフェースのうち、前記パケットが入力した仮想インタフェースを含まない前記特定の仮想インタフェースに宛てて前記入力パケットを転送することを特徴とするパケットルーティング方法。 - 請求項１記載のパケットルーティング方法において、
前記ネットワークが、レイヤ２アドレスを告知するサーバを含み、
送元レイヤ２アドレスの学習内容を変更する際、前記サーバに前記送元レイヤ２アドレスを通知し、
前記サーバが同一仮想プライベートネットワークに含まれる他の全ての前記仮想ハブに前記レイヤ２アドレスを通知する
ことを特徴とするパケットルーティング方法。 - 請求項１記載のパケットルーティング方法において、
前記共用ネットワークは、網側仮想インタフェースによって前記仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、
前記宛先レイヤ２アドレスが学習されていない場合には、前記網側仮想インタフェースを通じて前記サーバへパケットを転送し、
前記サーバにて前記パケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、前記パケットが入力した仮想ハブ以外の全ての前記仮想ハブ各々に宛てて前記入力パケットを転送する
ことを特徴とするパケットルーティング方法。 - 請求項１記載のパケットルーティング方法において、
前記共用ネットワークは、網側仮想インタフェースによって前記仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、
前記宛先レイヤ２アドレスがブロードキャストアドレスである場合には、前記網側仮想インタフェースを通じて前記サーバへパケットを転送し、
前記サーバにて前記パケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち前記パケットが入力した仮想ハブ以外の全ての前記仮想ハブ各々に宛てて前記入力パケットを転送する
ことを特徴とするパケットルーティング方法。 - 請求項１記載のパケットルーティング方法において、
前記共用ネットワークは、網側仮想インタフェースによって前記仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、
前記宛先レイヤ２アドレスがマルチキャストアドレスである場合には、前記網側仮想インタフェースを通じて前記サーバへパケットを転送し、
前記サーバにて前記パケットが入力した仮想プライベートネットワークに属する全ての仮想ハブのうち、前記パケットが入力した仮想ハブ以外の全ての前記仮想ハブ各々に宛てて前記入力パケットを転送する
ことを特徴とするパケットルーティング方法。 - 請求項１記載のパケットルーティング方法において、
前記共用ネットワークは、網側仮想インタフェースによって前記仮想ハブと接続されたパケットを転送するサーバを少なくとも１つ含み、
前記宛先レイヤ２アドレスがマルチキャストアドレスである場合には、前記網側仮想インタフェースを通じて前記サーバへパケットを転送し、
前記サーバにて前記マルチキャストアドレスが特定の前記仮想ハブに対応づけられている場合には、前記パケットが入力した仮想ハブ以外の、前記特定の仮想ハブ各々に宛てて前記入力パケットを転送する
ことを特徴とするパケットルーティング方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001046513A JP3679336B2 (ja) | 2001-02-22 | 2001-02-22 | パケットルーティング方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001046513A JP3679336B2 (ja) | 2001-02-22 | 2001-02-22 | パケットルーティング方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002247089A JP2002247089A (ja) | 2002-08-30 |
| JP3679336B2 true JP3679336B2 (ja) | 2005-08-03 |
Family
ID=18908123
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001046513A Expired - Lifetime JP3679336B2 (ja) | 2001-02-22 | 2001-02-22 | パケットルーティング方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3679336B2 (ja) |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3791621B2 (ja) | 2003-01-21 | 2006-06-28 | 富士通株式会社 | バーチャルネットワークシステムのキャリアネットワークおよび該キャリアネットワークの通信ノード |
| CN1323525C (zh) * | 2003-06-12 | 2007-06-27 | 华为技术有限公司 | 在虚拟专用网内使用路由分辨符进行通信的方法 |
| CN101202706A (zh) * | 2003-09-26 | 2008-06-18 | 华为技术有限公司 | 一种虚拟交换机系统 |
| JP4529144B2 (ja) * | 2004-08-11 | 2010-08-25 | 日本電気株式会社 | 仮想ｌａｎシステムおよびノード装置 |
| JP2006339927A (ja) * | 2005-06-01 | 2006-12-14 | Nec Commun Syst Ltd | ルーティング装置及びそれに用いるルーティング方法並びにそのプログラム |
| JP4186971B2 (ja) | 2005-09-01 | 2008-11-26 | 富士通株式会社 | パケット転送装置 |
| JP4706542B2 (ja) * | 2006-04-10 | 2011-06-22 | 株式会社日立製作所 | 通信装置 |
| JP4733583B2 (ja) * | 2006-07-24 | 2011-07-27 | 株式会社アイ・オー・データ機器 | ネットワーク機器、およびｉｐネットワークシステム、ならびに同システムにおけるネットワーク機器の接続設定方法、プログラム |
| JP4728209B2 (ja) | 2006-12-05 | 2011-07-20 | アラクサラネットワークス株式会社 | マルチキャストネットワーク冗長化システム |
| JP4899959B2 (ja) * | 2007-03-19 | 2012-03-21 | 富士通株式会社 | Ｖｐｎ装置 |
| EP2201474B1 (en) * | 2007-10-03 | 2020-05-06 | NTT Global Networks Incorporated | Virtualized application acceleration infrastructure |
| JP5585219B2 (ja) | 2010-06-03 | 2014-09-10 | 富士通株式会社 | スイッチング装置および仮想ｌａｎ構築方法 |
| WO2012037518A1 (en) | 2010-09-17 | 2012-03-22 | Oracle International Corporation | System and method for facilitating protection against run-away subnet manager instances in a middleware machine environment |
| WO2012093429A1 (en) | 2011-01-05 | 2012-07-12 | Nec Corporation | Communication control system, control server, forwarding node, communication control method, and communication control program |
| US9935848B2 (en) | 2011-06-03 | 2018-04-03 | Oracle International Corporation | System and method for supporting subnet manager (SM) level robust handling of unkown management key in an infiniband (IB) network |
| EP2716003B1 (en) | 2011-06-03 | 2016-09-28 | Oracle International Corporation | System and method for authenticating components in a network |
| WO2013168737A1 (ja) | 2012-05-09 | 2013-11-14 | 日本電気株式会社 | 通信システム、制御装置、通信方法及びプログラム |
| JP6024474B2 (ja) | 2013-01-23 | 2016-11-16 | 富士通株式会社 | マルチテナントシステム、管理装置、管理プログラム、およびマルチテナントシステムの制御方法 |
| CN110740093B (zh) * | 2019-10-24 | 2020-09-15 | 北京大学 | 一种基于虚拟主机的数据转发装置 |
-
2001
- 2001-02-22 JP JP2001046513A patent/JP3679336B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002247089A (ja) | 2002-08-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3679336B2 (ja) | パケットルーティング方法 | |
| JP4183379B2 (ja) | ネットワーク及びエッジルータ | |
| JP4355422B2 (ja) | パケットをルーティングする方法および装置 | |
| US7260097B2 (en) | Label control method and apparatus for virtual private LAN segment networks | |
| US8767749B2 (en) | Method and system for transparent LAN services in a packet network | |
| JP3868815B2 (ja) | 通信システム | |
| CN102804693B (zh) | 用于在ip网络上实现l2 vpn的方法和设备 | |
| US7532634B2 (en) | Resilient packet ring device | |
| US7660303B2 (en) | Point-to-multipoint functionality in a bridged network | |
| JP5846199B2 (ja) | 制御装置、通信システム、通信方法、および通信プログラム | |
| US20120300774A1 (en) | Method and apparatus for exchanging routing information and establishing connectivity across multiple network areas | |
| CN108199963B (zh) | 报文转发方法和装置 | |
| US20080130490A1 (en) | Method For Implementing on-Ring Process, Off-Ring Process and Data Forwarding in Resilience Packet Data Ringnet and a Network Device Thereof | |
| US20080151899A1 (en) | Data transmission method and a system thereof | |
| KR20090028531A (ko) | 분산 브릿지에서의 ｍａｃ 어드레스 학습 | |
| JP2005086820A (ja) | チャネライズイーサネットオーバーソネット（ＥｏＳ）インターフェースを用いる仮想プライベートネットワーク（ＶＰＮ）、エッジルータ及び方法 | |
| JP2004140776A (ja) | ネットワークにおけるフレーム転送方法及びノード、フレーム転送プログラム | |
| JPH1141272A (ja) | Ｌａｎインターネット接続 | |
| US8064465B2 (en) | Packet forwarding apparatus | |
| EP2092692A1 (en) | Method and apparatus for exchanging routing information and the establishment of connectivity across multiple network areas | |
| US7058730B2 (en) | Unique address space and method for a transport network | |
| US20070291665A1 (en) | Lan topology detection and assignment of addresses | |
| JP3910200B2 (ja) | ルータ，フレーム転送方法および下位レイヤフレーム仮想転送システム | |
| CN113037883B (zh) | 一种mac地址表项的更新方法及装置 | |
| WO2007104201A1 (fr) | Procédé d'acheminement de messages dans un tunnel de services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041020 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041102 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041228 |
|
| 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: 20050510 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050512 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 3679336 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090520 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090520 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100520 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100520 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110520 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120520 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130520 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140520 Year of fee payment: 9 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| EXPY | Cancellation because of completion of term |