JP2004304574A - 通信装置 - Google Patents
通信装置 Download PDFInfo
- Publication number
- JP2004304574A JP2004304574A JP2003095909A JP2003095909A JP2004304574A JP 2004304574 A JP2004304574 A JP 2004304574A JP 2003095909 A JP2003095909 A JP 2003095909A JP 2003095909 A JP2003095909 A JP 2003095909A JP 2004304574 A JP2004304574 A JP 2004304574A
- Authority
- JP
- Japan
- Prior art keywords
- network
- user
- frame
- layer
- connection destination
- 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.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Abstract
【課題】本発明は、セッションコントロール処理が集中することにより生じるボトルネックを回避することができる通信装置を提供することを目的とする。
【解決手段】ＰＰＰｏＥを用いてユーザが複数の接続先から任意の接続先選択を行う通信システムにおいて、ユーザにより選択された接続先宛のデータを中継するレイヤ２網のエッジに配置され、１以上のユーザ側装置を収容する通信装置であって、ユーザ側装置から受信するＰＰＰｏＥフレームがＰＰＰセッション確立用のフレームか前記接続先宛のデータを含むフレームかを判別するフレーム判別手段と、前記フレーム判別手段で判別されたセッション確立用のフレームに基づいて、ユーザ認証及び接続先識別を含むユーザ側装置とユーザにより選択された接続先との間の通信に係るＰＰＰセッションを確立するための処理を行うセッション管理手段と、前記フレーム判別手段で判別された前記接続先宛のデータを含むＰＰＰｏＥフレームから当該データを抽出するフレーム変換手段と、前記フレーム変換手段で抽出されたデータを前記レイヤ２網へ送出する転送処理手段とを含む。
【選択図】 図１６
【解決手段】ＰＰＰｏＥを用いてユーザが複数の接続先から任意の接続先選択を行う通信システムにおいて、ユーザにより選択された接続先宛のデータを中継するレイヤ２網のエッジに配置され、１以上のユーザ側装置を収容する通信装置であって、ユーザ側装置から受信するＰＰＰｏＥフレームがＰＰＰセッション確立用のフレームか前記接続先宛のデータを含むフレームかを判別するフレーム判別手段と、前記フレーム判別手段で判別されたセッション確立用のフレームに基づいて、ユーザ認証及び接続先識別を含むユーザ側装置とユーザにより選択された接続先との間の通信に係るＰＰＰセッションを確立するための処理を行うセッション管理手段と、前記フレーム判別手段で判別された前記接続先宛のデータを含むＰＰＰｏＥフレームから当該データを抽出するフレーム変換手段と、前記フレーム変換手段で抽出されたデータを前記レイヤ２網へ送出する転送処理手段とを含む。
【選択図】 図１６
Description
【０００１】
【発明の属する技術分野】
本発明は、１以上のユーザ側装置を収容する通信装置、及びこの通信装置がエッジ部分に配置されるＬ２ＶＰＮ（Ｌａｙｅｒ ２ Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）網に関する。例えば、本発明は、ｘＳＰ（インターネットサービスプロバイダ（ＩＳＰ）、コンテンツサービスプロバイダ（ＣＳＰ））や企業ネットワークへのアクセス・メトロ網において、上記通信装置において認証・接続先識別を含むセッションコントロールを行い、ｘＳＰ接続網とユーザ拠点間接続網のシームレスな統合を可能とする技術に関する。
【０００２】
【従来の技術】
近年、インターネットのブロードバンド化が本格化している。従来の電話網によるダイヤルアップ接続に比べ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）などは、数十倍のスピードでのアクセスを提供することができる。
【０００３】
また、今後、各家庭まで光ファイバが敷設され、それに伴って高画質の映像配信サービスや音楽ダウンロードサービスなどを提供するｘＳＰ（ＩＳＰ，ＣＳＰ等）が数多く出現すると考えられる。
【０００４】
また、企業網が広帯域なアクセス・メトロ網に接続されることによって、家庭と企業間で大容量かつ高速なデータのやりとりができ、在宅勤務なども可能となる。
【０００５】
したがって、今後さらに高速な数十メガビットクラスでのアクセスが可能で、なおかつ接続先を用途に応じて切り替えるといったニーズが高まると考えられる。このようなニーズを満たすキーとなる技術は次の二つである。
【０００６】
（１）イーサネット（Ｅｔｈｅｒｎｅｔ（登録商標）：ＩＥＥＥ ８０２．３に準拠するネットワーク）
イーサネット（図１にフレームフォーマットを示す）は、従来ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋｓ）において広く用いられている技術であり、１０Ｍｂｐｓから１０Ｇｂｐｓ（２００２年６月にＩＥＥＥ８０２．３ａｅとして標準化完了）までの幅広い帯域を提供することができる。図２に本発明に係る主なイーサネットサービス（イーサタイプ）をパケット種別ごとに示す。
【０００７】
また、イーサネットは、装置コストが安価でなおかつユーザ側装置のインタフェースとしても広く普及している。このため、イーサネットを用いれば、経済的にブロードバンドアクセスサービスを提供することが可能となる。
【０００８】
ＩＥＥＥ８０２．３委員会では、アクセス網の最後の１マイルにイーサネット技術を適用することを目的としたＩＥＥＥ８０２．３ａｈ ＥＦＭ（Ｅｔｈｅｒｎｅｔ ｉｎ ｔｈｅ Ｆｉｒｓｔ Ｍｉｌｅ）が現在仕様策定中である。
【０００９】
（２）ＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）
ＰＰＰ（ＲＦＣ１６６１規定）は、ユーザ認証およびレイヤ３アドレスの割当およびレイヤ３パケットのカプセル化転送を実現する方式である。ＰＰＰでは、最初に、データリンクの確立を行うＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ネゴシエーションが行われる。続いて、ユーザから送信されたユーザＩＤおよびパスワードを用いたユーザ認証（ＰＡＰ認証、ＣＨＡＰ認証等がある）が行われる。最後に、レイヤ３アドレスのネゴシエーションを行うＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、ＩＰの場合はＩＰＣＰ）において、アドレスプールからユーザにＩＰアドレスが割り当てられるとともに、対向アクセスサーバ（ＲＡＳ：Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ）のＩＰアドレスがユーザに通知される。このような手順を経て、実際のＩＰデータ通信が可能となる。
【００１０】
また、最近では、ユーザ認証でユーザ名およびｘＳＰ名を指定（「ユーザ名＠ｘＳＰ名」と指定）することにより、ユーザが接続先を任意に選択するサービス（「接続先選択サービス」と称する）が行われている。この接続先選択サービスでは、ＢＲＡＳ（Ｂｒｏａｄｂａｎｄ Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ）と呼ばれる装置が、ユーザとｘＳＰとの接続点で、接続先ごとにユーザパケットを振り分ける。これによって、ユーザの接続先が任意に選択される。
【００１１】
上述した両方の技術を合わせた方式としてＰＰＰｏＥ（ＰＰＰ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ，ＲＦＣ２５１６規定）がある。ＰＰＰｏＥは、ＡＤＳＬ接続やＦＴＴＨ接続で広く使用されている。ＰＰＰｏＥは、文字どおりイーサネット上でＰＰＰパケットを転送する方式であり、イーサネット上での任意の接続先への切替接続を実現することができる。図３は、ＰＰＰｏＥを使用したＢＲＡＳを介したユーザ側装置とｘＳＰ間の接続イメージを示す図である。
【００１２】
図４は、ＰＰＰｏＥによるＢＲＡＳを介したユーザ側装置とｘＳＰとの間の接続における通信方式のシーケンス例を示す図である。ＰＰＰｏＥは、ＰＰＰｏＥ Ｄｉｓｃｏｖｅｒｙ Ｓｔａｇｅと、ＰＰＰ Ｓｅｓｓｉｏｎ Ｓｔａｇｅとに大きく分けることができる。
【００１３】
ＰＰＰ Ｄｉｓｃｏｖｅｒｙ Ｓｔａｇｅでは、ブロードキャスト型の通信方式を使用し、或るイーサネット上で２地点（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ）のセッションを確立する相手が特定される。このステージでは、ユーザ側装置は、ＰＰＰｏＥ発呼のＰＡＤＩ（ＰＰＰｏＥ Ａｃｔｉｖｅ Ｄｉｓｃｏｖｅｒｙ Ｉｎｉｔｉａｔｉｏｎ、図５にフレームフォーマットを示す）をブロードキャストで送出する。この場合、ＢＲＡＳは、ＰＡＤＩに応答し、ＰＡＤＯ（ＰＰＰｏＥ Ａｃｔｉｖｅ Ｄｉｓｃｏｖｅｒｙ Ｏｆｆｅｒ）をユニキャストで（ＰＡＤＩで受けたフレームの送信元ＭＡＣアドレスを宛先ＭＡＣアドレスとして）ユーザ側装置に返す。ユーザ側装置は、ＰＡＤＯの送信元ＭＡＣアドレスからＢＲＡＳのＭＡＣアドレスを認識することができる。これによって、ユーザ側装置は、以降のＢＲＡＳに対する通信において、ＢＲＡＳのＭＡＣアドレスを宛先ＭＡＣアドレスとして設定し、ユニキャストでＰＡＤＲ（ＰＰＰｏＥ Ａｃｔｉｖｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）を送出する。ＢＲＡＳは、ＰＡＤＲを受信すると、ユーザ側装置とＢＲＡＳとの間でセッション毎にユニークなＩＤ（Ｓｅｓｓｉｏｎ−ＩＤ：以下「セッションＩＤ」とも表記）を設定し、ＰＡＤＳ（ＰＰＰｏＥ Ａｃｔｉｖｅ Ｄｉｓｃｏｖｅｒｙ Ｓｅｓｓｉｏｎ−Ｃｏｎｆｏｒｍａｔｉｏｎ）をユーザ側装置に返す。
【００１４】
ＰＰＰ Ｓｅｓｓｉｏｎ Ｓｔａｇｅでは、ユーザ側装置とＢＲＡＳとの間でユニキャスト通信が行われる。このときのユニキャスト通信では、確立されたセッションＩＤ値が設定されたデータの送受信が行われる。このステージでは、ＢＲＡＳは、ユーザ側装置からのデータに付加された送信元ＭＡＣアドレスおよびセッションＩＤからユーザセッションを識別し、上記したＰＰＰネゴシエーション（ＬＣＰネゴシエーション，ユーザ認証，ＮＣＰネゴシエーション）を行う。
【００１５】
このとき、ＢＲＡＳは、ユーザ認証において、ユーザが指定した「ユーザ名＠ｘＳＰ名」からユーザの接続先を抽出し、ＲＡＤＩＵＳ（ＲＦＣ２８６５）クライアントとして、該当接続先のＲＡＤＩＵＳサーバに認証情報を送信（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ）する。このときの実際の認証は認証用のデータベースを持つｘＳＰで行われる。その後、ＢＲＡＳは、ＲＡＤＩＵＳサーバからの認証成功を示すパケット（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）をもとにＩＰアドレスの割当（ＩＰＣＰ）のネゴシエーションを行うことができる。
【００１６】
ＩＰＣＰ完了後、ユーザ側装置は、接続先との間でＩＰデータ通信を行うことが可能となる。すると、ユーザ側装置からＰＰＰｏＥでカプセル化されたＩＰパケット（ＰＰＰｏＥパケット）がＢＲＡＳに送られてくる状態となる（図６にＰＰＰｏＥパケットのフレームフォーマットを示す）。この場合、ＢＲＡＳはＰＰＰを終端し、ＩＰパケットを該当接続先に転送する。
【００１７】
なお、接続先ネットワークへのデータ転送に際し、Ｌ２ＴＰ（Ｌａｙｅｒ ｔｗｏ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ：ＲＦＣ２６６１規定）等が用いられ、Ｌ３ＶＰＮ（ｌａｙｅｒ ｔｈｒｅｅ ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ）網においてＰＰＰフレームのままで転送される場合もある。以後、本発明では、ユーザ認証・接続先の識別、提供サービス、および接続先へのパケット転送を含む処理を“セッションコントロール”と称する。
【００１８】
その他、本発明に係る技術として、特許文献１に開示されたネットワーク間通信方法及びその装置に係る技術がある。
【００１９】
【特許文献１】
特開２００１−１６２５５号公報
【００２０】
【発明が解決しようとする課題】
上述したように、ＰＰＰｏＥはイーサネット上での切替接続を実現することができる。しかしながら、従来のＢＲＡＳを用いた集中型の処理では以下に示すような問題があった。
【００２１】
（１）ＢＲＡＳのボトルネック
図７に示すように、ユーザ側装置は、どのｘＳＰ（ｘＳＰ網）と接続する場合でも、ＢＲＡＳを経由しての接続となる。このため、ＢＲＡＳにセッションコントロール処理が集中してしまう（場合によっては数十万〜数百万セッションとなる）。
【００２２】
ここに、ＰＰＰのネゴシエーションは、互いに条件を要求（Ｃｏｎｆｉｇｕｒｅ−Ｒｅｑｕｅｓｔ）し合い、互いに承認（Ｃｏｎｆｉｇｕｒｅ−Ａｃｋ）し合うといった複雑な状態遷移を伴う。しかも、ユーザごとにネゴシエーションの条件が異なる。このため、ＰＰＰによるネゴシエーションは、ソフトウェア処理が前提となる。
【００２３】
また、パケット転送は、ＢＲＡＳにおけるセッションコントロールの一部として行われる（図８に示すように、ＢＲＡＳの内部では、ソフトウェアで保持される状態遷移（図９）に基づいてパケット転送の可否が決定される）。このため、ハードウェア処理／ソフトウェア処理の切り分けが困難である。
【００２４】
さらに、ＢＲＡＳは、ｘＳＰにパケット転送を行うため、レイヤ３の処理（ＩＰルーティング等）を行わなければならない。従って、ＢＲＡＳは、ｘＳＰごとのＩＰアドレス体系およびダイナミックルーティングをサポートする必要がある（「バーチャルルータ機能」と呼ばれる）。
【００２５】
以上の理由から、ネットワークプロセッサなどの進歩がめざましいとはいえ、ＢＲＡＳによる処理の高速化には限界がある。
【００２６】
（２）ｘＳＰ接続網とユーザ拠点間接続網のシームレスな統合が困難
近年、広域ＬＡＮサービスなどと呼ばれる、ユーザ（主に企業）がイーサネットインタフェースでリモートの拠点間をあたかも同一ＬＡＮセグメントのように接続できるユーザ拠点間接続サービスが注目を集めている。
【００２７】
図１０に示すように、ユーザ拠点間接続サービスでは、ユーザを収容する装置でユーザを接続（収容）するポートやユーザフレームのＩＥＥＥ８０２．１Ｑ ＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）−ｔａｇなどからＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）を識別する。この場合、Ｌ２ＳＷ（Ｅｔｈｅｒｎｅｔ ＳＷ）で網が構成され、ＶＰＮ識別のための拡張ＶＬＡＮ−ｔａｇがユーザに付与（ユーザＥｔｈｅｒｎｅｔフレームに挿入）され、網がＶＰＮごとのブロードキャストドメインに論理的に分離され、ＭＡＣブリッジ転送によってユーザフレームが転送される。
【００２８】
また、最近では、網をＭＰＬＳ（Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）で構成し、ＭＰＬＳ網でイーサネットフレームを転送するＥｏＭＰＬＳ（Ｅｔｈｅｒｎｅｔ ｏｖｅｒ ＭＰＬＳ）サービスも提供されている。図１１に示すように、ＥｏＭＰＬＳでは、ユーザ収容のポートやユーザフレームのＶＬＡＮ−ｔａｇからＶＰＮが識別され、ＭＰＬＳ網内を転送するためのＴｕｎｎｅｌ（トンネル）ラベルパスとＭＰＬＳ網の出入口のエッジ装置（ＬＥＲ：Ｌａｂｅｌ Ｅｄｇｅ Ｒｏｕｔｅｒ）でＶＰＮを識別するためのＶＣ（Ｖｉｒｔｕａｌ ｃｉｒｃｕｉｔ）ラベルパスにユーザフレームがマッピング（ユーザＥｔｈｅｒｎｅｔフレームがトンネルラベルおよびＶＣラベルでカプセル化）され、ユーザフレームがラベルスイッチ転送される。
【００２９】
一般に、ＭＰＬＳは２地点間（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ）のサービスである。但し、ＬＥＲにＭＡＣブリッジングの機能を持たせることによって、１対複数地点間（Ｐｏｉｎｔ−ｔｏ−Ｍｕｌｔｉｐｏｉｎｔ）のイーサネットフレーム転送サービスを提供することが可能である（「ＶＰＬＳ： Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ ＬＡＮ Ｓｅｒｖｉｃｅ」と呼ばれる）。
【００３０】
このように、ユーザ拠点間サービスでは、ユーザ収容装置でＶＰＮが一意に識別でき、さらに、網内では拡張ＶＬＡＮの２段スタック（Ｌ２ＳＷ網の場合）や、ＭＰＬＳラベルをさらにスタックしたりラベルパスをマージ（ＭＰＬＳ網の場合）したりしてトラフィックを多重化することも可能である。従って、経済的・効率的なネットワークの構築が可能である。
【００３１】
しかし、ｘＳＰ接続サービスにＢＲＡＳを用いた場合では、アクセス網内ではフレームがＢＲＡＳに至るまでユーザの接続先ｘＳＰを判別することができない。従って、図１２に示すように、例えばＬ２ＳＷで網が構成される場合において拡張ＶＬＡＮ等でトラフィックを多重化しても、ＢＲＡＳで接続先識別および提供しているサービス（最大速度や一戸建てや集合住宅型シェアドアクセスなどの接続形態等）を識別するためにアグリゲートトラフィックを分離してＢＲＡＳに渡す必要がある。ＭＰＬＳ網の場合も同様で、ユーザ側装置とｘＳＰとの間にＢＲＡＳが存在することが上記ユーザ拠点間接続網とｘＳＰ接続網の統合の妨げとなってしまう。
【００３２】
なお、イーサネット上でアクセスコントロールを実現する方式としては、ＩＥＥＥ８０２．１Ｘ（Ｐｏｒｔ ｂａｓｅｄ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）がある。ＩＥＥＥ８０２．１ＸはＥＡＰＯＬ（ＥＡＰ ｏｖｅｒ ＬＡＮｓ、図１３にフレームフォーマットを示す）とも呼ばれ、上記ＰＰＰの拡張認証方式であるＥＡＰ（Ｅｘｔｅｎｄｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のパケットフォーマットを流用し、イーサネットフレーム上で直接やりとりして、ＰＰＰ同様「ユーザ名＠組織名」から接続先セグメントを抽出して、認証が成功すると当該セグメント（ＶＬＡＮ）へのアクセスを許可するものである（図１４にＩＥＥＥ８０２．１Ｘによるシーケンス例、図１５にＩＥＥＥ８０２．１Ｘによる接続イメージを示す）。
【００３３】
しかし、ＩＥＥＥ８０２．１Ｘは、エッジＬ２ＳＷのポート単位でアクセスを許可するものであり、ポートあたり１ユーザしか認証できない。つまり集合住宅などで集線された環境など、エッジＬ２ＳＷのポートに複数ユーザが接続された環境では適用できない。またＩＥＥＥ８０２．１Ｘは主にイーサネットや無線ＬＡＮのセキュリティ（ポートにケーブルを繋げばだれでも簡単にアクセスできてしまうことや無線ＬＡＮのパケットを傍受することでなりすましが可能になってしまうことなど）に鑑みたものであって、例えばＩＰアドレス割当および管理の機構を備えていないことや、認証後の接続先セグメントは通常のＬＡＮと同じくフリーアクセスとなるため、セキュリティ等の観点からｘＳＰ選択接続としてそのまま適用することは難しい。
【００３４】
本発明は、以上のような問題を解決し、セッションコントロール処理が集中することにより生じるボトルネックを回避することができる通信装置を提供することを目的とする。
【００３５】
【課題を解決するための手段】
上記問題を解決するため、本発明は以下のような構成をとる。即ち、本発明は、ＰＰＰｏＥを用いてユーザが複数の接続先から任意の接続先選択を行う通信システムにおいて、ユーザにより選択された接続先宛のデータを中継するレイヤ２網のエッジに配置され、１以上のユーザ側装置を収容する通信装置であって、ユーザ側装置から受信するＰＰＰｏＥフレームがＰＰＰセッション確立用のフレームか上記接続先宛のデータを含むフレームかを判別するフレーム判別手段と、上記フレーム判別手段で判別されたセッション確立用のフレームに基づいて、ユーザ認証及び接続先識別を含むユーザ側装置とユーザにより選択された接続先との間の通信に係るＰＰＰセッションを確立するための処理を行うセッション管理手段と、上記フレーム判別手段で判別された上記接続先宛のデータを含むＰＰＰｏＥフレームから当該データを抽出するフレーム変換手段と、上記フレーム変換手段で抽出されたデータを前記レイヤ２網へ送出する転送処理手段とを含む。
【００３６】
好ましくは、本発明の通信装置は、上記各接続先の網のエッジ装置が接続先毎に用意された上記レイヤ２網の網終端装置にそれぞれ接続されており、上記フレーム変換手段は、上記接続先宛のデータに宛先レイヤ２アドレスとして設定されている自装置のレイヤ２アドレスを当該接続先のエッジ装置のレイヤ２アドレスに変換して上記転送処理手段に渡すように構成してもよい。
【００３７】
好ましくは、本発明における通信装置は、上記レイヤ２網が上記各接続先の網を収容するレイヤ３網にエッジ装置を介して接続され、このエッジ装置が上記レイヤ２網を通じて受信する上記接続先宛のデータに対して上記レイヤ２網の終端処理を行うとともに上記レイヤ３網を介して該当する接続先の網へ転送する処理を行うように構成されており、上記セッション管理手段は、ユーザ側装置との間におけるＰＰＰセッションの確立において、ユーザ側装置に転送されるセッション確立用フレームの送信元レイヤ２アドレスとして上記エッジ装置のレイヤ２アドレスを設定し、上記フレーム変換手段は、ＰＰＰセッションの確立後にユーザ側装置から受信する接続先宛のデータに宛先レイヤ２アドレスとして設定されている上記エッジ装置のレイヤ２アドレスを変更することなく当該データを上記転送処理手段に渡すように構成してもよい。
【００３８】
好ましくは、本発明における通信装置は、上記レイヤ２網が上記各接続先の網を収容するレイヤ３網に複数のエッジ装置を介して接続され、各エッジ装置が上記レイヤ２網を通じて受信する上記接続先宛のデータに対して上記レイヤ２網の終端処理を行うとともに上記レイヤ３網を介して該当する接続先の網へ転送する処理を行うように構成されており、上記セッション管理手段は、ユーザ側装置との間におけるＰＰＰセッションの確立において、ユーザ側装置に転送されるセッション確立用フレームの送信元レイヤ２アドレスとして、接続先に応じたエッジ装置のレイヤ２アドレスを設定し、上記フレーム変換手段は、ＰＰＰセッションの確立後にユーザ側装置から受信する接続先宛のデータに宛先レイヤ２アドレスとして設定されている上記エッジ装置のレイヤ２アドレスを変更することなく当該データを上記転送処理手段に渡すように構成してもよい。
【００３９】
好ましくは、本発明におけるレイヤ２網は、ＩＥＥＥ８０２．１Ｑ ＶＬＡＮに従って接続先毎に論理分割され、本発明における転送処理手段は、上記接続先宛のデータに対し、当該データの接続先に対応するＶＬＡＮ−ｔａｇを設定して上記レイヤ２網に送出するように構成してもよい。
【００４０】
このようにして、本発明によれば、ユーザ側装置を収容する通信装置において、ユーザ認証及び接続先識別を含むセッション管理を行うことにより、セッションコントロール処理が集中することにより生じるボトルネックを回避することができる。
【００４１】
【発明の実施の形態】
以下、図面を用いて本発明の実施形態について説明する。なお、本実施形態の説明は例示であり、本発明の構成は以下の説明に限定されない。
【００４２】
〈概要〉
本発明を実現するにあたってのポイントは次の（１）〜（４）である。
（１）従来ＢＲＡＳで行っていたセッションコントロールを分散処理する。
（２）上記（１）に加えて、標準化されたＰＰＰｏＥ（通信プロトコル）を用いてＩＰデータフレーム（ＩＰｏＰＰＰｏＥ）を送受信する（ただし、セッション識別後はＰＰＰｏＥデカプセル化する）。
【００４３】
上記（１）及び（２）については、ＢＲＡＳの機能をそのままユーザ収容装置に分散させる方法が考えられる。しかし、上述したように、ＢＲＡＳによる処理では、パケット転送がソフトウェア処理により行われる。このため、処理の高速化の問題が解決できない。さらに、ＢＲＡＳはレイヤ３に対する処理も行うので、ｘＳＰ毎のＩＰアドレス体系やダイナミックルーティングまでもが分散されることになる。従って、これらの管理運用が煩雑化することが考えられる。従って、次の（３）及び（４）もポイントとなる。
（３）ハード処理／ソフト処理の切り分けを明確にする。即ち、ＩＰデータフレームをハード処理化する。
（４）ＩＰデータフレームのレイヤ２処理を行う。
以上のポイント（１）〜（４）を踏まえ、本発明の実施形態を説明する。
【００４４】
《実施形態》
図１６は、本発明の実施形態に係る通信装置（ユーザ収容装置）及びこの通信装置を含むＬ２ＶＰＮネットワークシステムの概要を示す図である。図１６には、Ｌ２ＶＰＮ網１が示されている。本発明に係るユーザ収容装置２は、Ｌ２ＶＰＮ網のエッジに配置される。ユーザ収容装置２は、一戸建てや集合住宅等のユーザ拠点におけるユーザ側装置３を直接的に（例えば、レイヤ２におけるブロードキャストドメイン内で）収容することができる。
【００４５】
ユーザ収容装置２は、各ユーザ側装置３が、ユーザ側装置３で選択されたサービスプロバイダ（ｘＳＰ（ＩＳＰ、ＣＳＰ等））にアクセスするための制御（ユーザ任意の接続先選択サービスの制御）を行う。図１６には、ユーザが選択可能な複数のｘＳＰの例として、ｘＳＰ−Ａと、ｘＳＰ−Ｂとのそれぞれによって用意されたｘＳＰ網及びその入口に設置されたエッジ装置（エッジルータ）が図示されている。
【００４６】
各ユーザ側装置３と各ｘＳＰとの間では、ＰＰＰｏＥによるセッションを介して通信が行われる。このため、ユーザ収容装置２は、各ユーザ側装置３とｘＳＰ間の通信に係るＰＰＰｏＥのセッションコントロールを行う。
【００４７】
ユーザ収容装置２は、セッションコントロールの後、ｘＳＰ宛のＩＰデータフレームがＰＰＰｏＥでカプセル化されたＰＰＰｏＥフレームをユーザ側装置３から受信する。ユーザ収容装置２は、このＰＰＰｏＥフレームをデカプセル化してＩＰｏＥデータフレームに変換し、このＩＰｏＥデータフレームをＬ２ＶＰＮ網１の網構成に応じたフォーマット（Ｌ２ＶＰＮの既存の標準フォーマット）にマッピング（カプセル化）し、Ｌ２ＶＰＮ網１へ送出する。
【００４８】
そして、ＩＰｏＥデータフレームは、Ｌ２ＶＰＮ網１の網構成に依存する転送手順に従ってＬ２ＶＰＮ網１における所定の終端点までレイヤ２転送され、この終端点でＬ２ＶＰＮ網１の終端処理が行われ、続いてＩＰｏＥデータフレームのｘＳＰへの転送処理が行われる。
【００４９】
また、ユーザ収容装置２は、ユーザの任意の接続先選択接続サービスと、ユーザ拠点間接続サービスを実現するＬ２ＶＰＮ網とが統合された統合Ｌ２ＶＰＮ網に適用することができる。すなわち、図１６に示すような企業間（Ｃ社支店６とＣ社本店７間）を結ぶユーザ拠点間接続サービスを、ユーザ−ｘＳＰ間の接続先選択接続サービスに適用することができる。
【００５０】
ユーザ側装置３は、例えばパソコン（ＰＣ）等のユーザがｘＳＰからサービスの提供を受けるための操作端末（「ユーザ端末」とも表記：コンテンツの表示や再生を行うアプリケーションが搭載されていても良い）と、ユーザ−ｘＳＰ間の通信機能を司る（少なくともＰＰＰｏＥ通信をサポートする）通信機器（ＡＤＳＬモデム等）との組み合わせにより構成される。但し、この例では、ユーザ端末−ｘＳＰ間通信はＩＰベースで行われるので、ユーザ側装置３は、ＩＰｏＰＰＰｏＥをサポートしている。
【００５１】
〈ユーザ収容装置のシステム構成〉
次に、ユーザ収容装置２のシステム構成について図１７〜２０を用いて説明する。図１７は、ユーザ収容装置２のシステム構成を示す図である。図１８は、フレーム判別手段の説明図である。図１９は、セッション管理手段の説明図である。図２０は、フレーム変換手段の説明図である。
【００５２】
図１７において、ユーザ収容装置２は、ユーザ側装置３を収容（直収）可能な通信装置として構成される。ユーザ収容装置２は、ＰＰＰｏＥフレーム入力時にフレームを解析し、フレームタイプ（セッションネゴシエーションフレームかＩＰデータフレームか）を判別するフレーム判別手段２０と、ＰＰＰ状態遷移に基づいて認証・接続先識別を含むセッションネゴシエーションを行うセッション管理手段２１と、認証成功・接続先識別後にユーザ側装置より送出されたＰＰＰｏＥカプセル化されたＩＰデータフレームのデカプセル化を行うフレーム変換手段２２と、デカプセル化されたＩＰデータフレームを接続先毎の仮想閉域網（Ｌ２ＶＰＮ網）にマッピングしてレイヤ２転送を行う転送処理手段２３とを備える。また、図１７において、実線矢印は、ユーザ端末３からのフレームの流れを示し、破線矢印は、セッションネゴシエーションに基づく情報の流れを示す。
【００５３】
ユーザ収容装置２の構成要素のうち、セッション管理手段２１は、ソフトウェアで構成され、図９に示すような従来と同様の状態遷移テーブル（「ＰＰＰ状態遷移テーブル」とも表記）に基づくセッションネゴシエーション処理をソフトウェア処理で行う。一方、フレーム判別手段２０，フレーム変換手段２２，及び転送処理手段２３は、ハードウェアで構成される。以下、各構成要素について詳細に説明する。
【００５４】
≪フレーム判別手段≫
フレーム判別手段２０は、ユーザ側装置３からのＰＰＰｏＥフレームを受信する。フレーム判別手段２０は、入力されたＰＰＰｏＥフレームを解析し、フレームタイプを判別する。フレームタイプの判別によって、当該フレームがセッションネゴシエーションフレーム（「ネゴシエーションパケット」とも表記）であるか、ＩＰデータフレームであるかが判別される。
【００５５】
フレーム判別手段２０は、フレームがセッションネゴシエーションフレームである場合には、当該フレームをセッション管理手段２１に渡し、ＩＰデータフレームである場合には、当該フレームをフレーム変換手段に渡す。
【００５６】
図１８に示す例では、フレーム判定手段２０は、ユーザ側から受信したＰＰＰｏＥフレームの“ＥＴＨＥＲ＃ＴＹＰＥ”が“０ｘ８８６４（ＰＰＰｏＥ（Ｓｅｓｓｉｏｎ））”であり、且つ“ＣＯＤＥ”が“０ｘ００”であり、且つ“ＰＰＰ＃ＰＲＯＴＯＣＯＬ”値が“０ｘ００２１”である場合（図６参照）には、当該ＰＰＰｏＥフレームについて、ＩＰパケットがＰＰＰｏＥカプセル化されたフレーム（ＩＰｏＰＰＰｏＥ）、即ちＩＰデータフレームであると判別し、当該ＰＰＰｏＥフレームをフレーム変換手段２２に転送する。
【００５７】
これに対し、フレーム判定手段２０は、ユーザ側からのＰＰＰｏＥフレームがＩＰデータフレーム以外のフレームである場合には、当該フレームがセッションネゴシエーションフレームであると判断し、当該フレームをセッション管理手段２１に転送する。
【００５８】
≪セッション管理手段≫
セッション管理手段２１は、ＰＰＰ状態遷移テーブルに基づいて、ユーザ認証・接続先識別を含む従来のＢＲＡＳとほぼ同様のセッションネゴシエーションを行う。図１９に示す例では、セッション管理手段２１は、ネゴシエーションパケット（ＰＰＰｏＥ）を受信し（Ｓ１）、受信したネゴシエーションパケットに含まれた送信元ＭＡＣアドレスとセッションＩＤを用いて状態遷移テーブルを検索し（Ｓ２）、検索した状態遷移に従った処理を行いユーザに応答する（Ｓ３）、という一連のセッションネゴシエーションを行う。
【００５９】
Ｓ３において、認証及び接続先識別処理が行われる。セッション管理手段２１は、認証を行う場合には、ＲＡＤＩＵＳクライアントとして、接続先として識別したｘＳＰのＲＡＤＩＵＳサーバとの間で、ＲＡＤＩＵＳ認証通信を行う。ＲＡＤＩＵＳ認証通信については、Ｌ２ＶＰＮ網内にプロキシＲＡＤＩＵＳサーバを配置して、ｘＳＰとの通信を一元化することも可能である。
【００６０】
セッション管理手段２１は、セッションネゴシエーション（認証成功・接続先識別）後に、ＰＰＰ状態遷移テーブルを参照し、新しい状態をチェックする（Ｓ４）。この時、状態が“ＩＰアドレス割り当て完了（ＩＰＣＰ Ｏｐｅｎｅｄ）”である場合には、その時点で当該ユーザ側装置３のＭＡＣアドレス，ＰＰＰｏＥのセッションＩＤ，及び接続先のＶＰＮ−ＩＤ（ＶＰＮ識別子）をフレーム変換手段２２に登録通知として通知する（Ｓ５）。この登録通知は、認証成功時（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔ受信時）の時点で登録可能とする。
【００６１】
一方、Ｓ４において、状態が“接続終了”の場合には当該ユーザ側装置３のＭＡＣアドレス，ＰＰＰｏＥのセッションＩＤ，及び接続先ＶＰＮ−ＩＤを削除通知として通知する（Ｓ６）。この削除通知は、ユーザからの明示的な接続終了（ＬＣＰ Ｔｅｒｍｉｎａｔｅ Ｒｅｑｕｅｓｔ ｏｒ ＰＡＤＴ：図４参照）の受信時、或いは無通信時間タイマのタイムアウト時に接続終了とみなし通知されるように構成することも可能である。
【００６２】
≪フレーム変換手段≫
フレーム変換手段２２は、認証成功・接続先識別後にユーザ側装置３により送出されるＰＰＰｏＥカプセル化されたＩＰデータフレームのデカプセル化を行う。
【００６３】
図２０に示す例では、フレーム変換手段２２は、ＭＡＣアドレス，ＰＰＰｏＥセッションＩＤ，及び接続先ＶＰＮ−ＩＤからなるテーブル２２ａを有している。
【００６４】
フレーム変換手段２２は、フレーム判別手段２０から転送されたＰＰＰｏＥカプセル化されたＩＰデータフレーム（ＩＰｏＰＰＰｏＥ）を受け取ったときに、当該フレーム中の送信元ＭＡＣアドレス及びセッションＩＤに対応するエントリがテーブル２２ａにあれば、当該ＰＰＰｏＥフレームをＩＰｏＥデータフレームに変換（ＰＰＰｏＥフレームのデカプセル化）し、ＶＰＮ−ＩＤの情報（セッション管理手段２１から受け取っている）とともに転送処理手段２３に送る。これに対し、フレーム変換手段２２は、テーブル２２ａに該当エントリがなければ、未だ認証前であるものとして、当該ＰＰＰｏＥフレームを廃棄する。
【００６５】
一方、フレーム変換手段２２は、Ｌ２ＶＰＮ網１側から転送処理手段２３を経て送られてきたＩＰｏＥデータフレームを受け取った場合には、当該フレーム中の宛先ＭＡＣアドレスをキーとしてテーブル２２ａを検索し、該当エントリがヒットすれば、このエントリ中のセッションＩＤが設定されたＰＰＰヘッダで当該フレームに対するＰＰＰｏＥカプセル化を行い、ユーザ側装置３に送出する。
【００６６】
さらに、フレーム変換手段２２は、テーブル２２ａのエントリ管理を行う。即ち、フレーム変換手段２２は、セッション管理手段２１から登録通知を受け取った場合には、その登録通知の内容が記録されたエントリをテーブル２２ａ内に作成する。一方、フレーム変換手段２２は、セッション管理手段２１から削除通知を受け取った場合には、対応するエントリをテーブル２２ａから削除する。
【００６７】
≪転送処理手段≫
転送処理手段２３は、デカプセル化されたＩＰデータフレームを接続先ごとの仮想閉域網（Ｌ２ＶＰＮ網）にマッピングしてレイヤ２転送する（詳細については後述）。
【００６８】
以上のように、ユーザ収容装置２は、従来ＢＲＡＳで行われていたユーザ側装置と選択接続先のｘＳＰとの間のセッションコントロールを、自身が収容している１以上のユーザ側装置について行う。これによって、従来のように、ＢＲＡＳで集中的に行われていた多数のユーザからのセッションコントロールを、複数のユーザ収容装置２に分散することができる。
【００６９】
また、ユーザ収容装置２は、ｘＳＰへのＩＰデータフレームの転送処理を、Ｌ２ＶＰＮ網１へのレイヤ２転送により行う。従って、ユーザ収容装置２において、ｘＳＰ毎のＩＰアドレス体系を管理したり、ダイナミックルーティングを管理したりする必要がない（バーチャルルータとしての機能を要しない）。従って、ユーザ収容装置２におけるＬ３処理を回避することができる。これによって、ユーザ側装置３と接続先のｘＳＰとの通信に係るセッションコントロールはセッション管理手段２１によるソフトウェア処理で行い、ＩＰデータフレームの転送処理は、フレーム判別手段２０，フレーム変換手段２２，及び転送処理手段２３によるハードウェア処理で行う構成を採用することができる。さらに、ＰＰＰｏＥフレームの判別及びフレーム変換処理をハードウェアで行うことで、高速化を図ることができる。
【００７０】
〈ｘＳＰの接続形態〉
次に、ｘＳＰの接続形態について説明する。ユーザ収容装置２がＩＰデータフレームをレイヤ２転送するための処理は、ｘＳＰのＬ２ＶＰＮ網１に対する接続形態によって異なる。接続形態としては、以下の二通りが考えられる。
〈Ａ〉ｘＳＰがＬ２ＶＰＮ網の終端点に直接接続される場合
〈Ｂ〉ｘＳＰがＬ２ＶＰＮ網及びＬ３ＶＰＮ網（ＩＰ−ＶＰＮ網）を経由する場合図２１（Ａ）及び（Ｂ）は、上記した接続形態〈Ａ〉、即ちＬ２ＶＰＮ網１の終端点でｘＳＰに直接接続される場合の接続形態例を示す図である。接続形態〈Ａ〉は、例えば、比較的小さい単位（例えば、県単位など）でｘＳＰに直接接続されるケースに適用される。
【００７１】
この場合、ユーザ収容装置２がＩＰパケット（ＩＰｏＥフレーム）をレイヤ２転送する際の宛先ＭＡＣアドレスは、選択接続先に該当するｘＳＰのエッジ装置（エッジルータ：図２１（Ａ）ではエッジ装置９Ａ，９Ｂ，９Ｃを例示。以下エッジ装置を特に指定しない説明では「エッジ装置９」と表記）のＭＡＣアドレスとなる。エッジ装置９は、例えば、ｘＳＰ毎に用意される。
【００７２】
エッジ装置９は、Ｌ２ＶＰＮ網１に接続される。このとき、図２１（Ａ）に示すように、各エッジ装置９がｘＳＰ毎に用意されたＬ２ＶＰＮ網１の網終端装置（図２１（Ａ）では網終端装置１３Ａ，１３Ｂ，１３Ｃを例示。以下網終端装置を特に指定しない説明では「網終端装置１３」と表記）に接続されるように構成しても良い。或いは、図２１（Ｂ）に示すように、各エッジ装置９が、複数のエッジ装置９を収容し、各エッジ装置９に対するトラフィックを宛先アドレスに従って分配する集約型網終端装置１６に接続されるように構成しても良い。
【００７３】
上述したように、ＰＰＰｏＥでは、ユーザ側装置３は、ＰＰＰ Ｄｉｓｃｏｖｅｒｙ Ｓｔａｇｅにおいて、セッションの確立相手のレイヤ２アドレス（例えばＭＡＣアドレス）を認識する。本実施形態では、ユーザ側装置３のセッションの確立相手はユーザ収容装置２であり、しかもユーザ認証時までは接続先のｘＳＰ（のエッジ装置のレイヤ２アドレス）が未知である。
【００７４】
このため、ユーザ収容装置２のフレーム変換手段２２は、認証成功・接続先識別後にユーザ側装置３から送信されてくるＰＰＰｏＥカプセル化されたＩＰデータフレームに対し、デカプセル化に加え、その宛先レイヤ２アドレスを、接続先の識別により得られたｘＳＰのエッジ装置のレイヤ２アドレスに変換して転送処理手段２３に渡す。
【００７５】
図２２は、図２１に示す接続形態（接続形態〈Ａ〉）において適用されるユーザ収容装置２の構成例を示す図である。図２２に示す例では、フレーム変換手段２２は、ユーザ側装置３からのＩＰｏＰＰＰｏＥフレームからＰＰＰｏＥを取り外しＩＰｏＥデータフレームへとデカプセル化する。さらに、フレーム変換手段２２は、デカプセル化されたＩＰｏＥデータフレームの宛先ＭＡＣアドレスに設定されているユーザ収容装置２のＭＡＣアドレス“Ｐ”を、接続先のｘＳＰのエッジ装置９のＭＡＣアドレス“Ｃ”に変換する。このとき設定される接続先ｘＳＰのエッジ装置９のＭＡＣアドレスは、フレーム変換手段２２が管理するテーブル２２ｂ（図２０のテーブル２２ａに相当）に登録されている。
【００７６】
フレーム変換手段２２は、セッション管理手段２１から、ユーザ側装置３のＭＡＣアドレス，ＰＰＰｏＥセッションＩＤ，及びＶＰＮ−ＩＤに加えて当該エッジ装置９のＭＡＣアドレスを含む登録通知を受け取り、この登録通知の内容を含むエントリをテーブル２２ｂに登録するように構成されている。
【００７７】
この場合、セッション管理手段２１は、あらかじめ自身に登録されている各ｘＳＰのエッジ装置９のＭＡＣアドレスを、接続先識別の結果に応じて登録通知に含めてフレーム変換手段２２に与える構成を適用することができる。或いは、認証時のＲＡＤｌＵＳ通信においてｘＳＰ側から該当エッジ装置９のＭＡＣアドレスを含む認証成功メッセージ（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）を受け取り、このＭＡＣアドレスを含む登録通知をフレーム変換手段２２に与えるように構成することも可能である。
【００７８】
後者が採用される場合には、ユーザ収容装置２は、接続先のｘＳＰのエッジ装置９のＭＡＣアドレスを動的に取得することができる。従って、ユーザ収容装置２毎に各ｘＳＰのエッジ装置９のＭＡＣアドレスを予め登録する必要がない。また、ｘＳＰのエッジ装置９が故障等で交換された場合でもＭＡＣアドレスを登録変更する必要がない。
【００７９】
図２３は、上記した接続形態〈Ｂ〉、即ちユーザからのトラフィックがＬ２ＶＰＮ網１、さらにＬ３ＶＰＮ網１０（例えば、ＩＰ−ＶＰＮ網）を経由する場合の接続形態例を示す図である。当該接続形態〈Ｂ〉は、比較的大きな単位（全国的に集約する場合など）でｘＳＰに接続されるケースに適用される。図２４は、図２３に示す接続形態（接続形態〈Ｂ〉）において適用されるユーザ収容装置２の構成例を示す図である。
【００８０】
図２３において、Ｌ２ＶＰＮ網１Ａに収容されている各ユーザ収容装置２がＩＰｏＥデータフレームをレイヤ２転送する際の宛先ＭＡＣアドレスは、Ｌ３ＶＰＮ網１０の入口のエッジ装置１１のＭＡＣアドレスとなる。この場合では、宛先ＭＡＣアドレスは、ユーザがどのｘＳＰと接続する場合でも一つに決まる。このため、ユーザ収容装置２は、図２４に示すような次の構成を持つ。
【００８１】
セッション管理手段２１は、ユーザ側装置３からのＰＰＰｏＥ発呼（ＰＡＤＩ）に対し、応答ＰＰＰｏＥフレーム（ＰＡＤＯ）の送信元レイヤ２アドレスとしてＬ３ＶＰＮ網１０のエッジ装置１１のレイヤ２アドレスを設定する。
【００８２】
続いて、ユーザ側装置３からのセッションネゴシエーションフレーム（ＰＡＤＲ）に対し、フレーム判別手段２０は、そのフレームの宛先レイヤ２アドレスが自装置宛でなくても、セッション管理手段２１に転送する。セッション管理手段２１は、当該フレームに基づいてセッション管理（ユーザ認証、接続先識別、ＩＰＣＰ等）を行う。
【００８３】
認証・接続先識別後では、ユーザ側装置３からのＰＰＰｏＥカプセル化されたＩＰデータフレームは、フレーム変換手段２２において、デカプセル化され転送処理手段２３に渡される。このような構成下では、フレーム変換手段２２で宛先ＭＡＣアドレスの変換する処理は不要となる。
【００８４】
図２４に示す例では、ユーザ側装置３は、ＰＰＰｏＥ発呼（ＰＡＤＩ）の宛先ＭＡＣアドレスにブロードキャストアドレス“ｆｆ”（実際には、ｆｆ：ｆｆ：ｆｆ：ｆｆ：ｆｆ：ｆｆ）を設定し、ＰＰＰｏＥ発呼（ＰＡＤＩ）をブロードキャストする。セッション管理手段２１は、ＰＡＤＩを受け取ると、応答ＰＰＰｏＥフレーム（ＰＡＤＯ）の送信元レイヤ２アドレスとしてＬ３ＶＰＮ網１０のエッジ装置１１のレイヤ２アドレス“Ｌ”を設定する。
【００８５】
ユーザ側装置３は、ＰＡＤＯを受け取ることで、セッションの相手先がレイヤ２アドレス“Ｌ”の装置（エッジ装置１１：実際にはユーザ収容装置２）であると認識する。従って、ユーザ側装置３は、その後のセッションネゴシエーションフレームについては、宛先レイヤ２アドレスとして“Ｌ”を用いる。そして、ＩＰ通信が可能な状態となると、ユーザ側装置３は、宛先レイヤ２アドレスが“Ｌ”に設定されたＰＰＰｏＥカプセル化ＩＰデータフレームをユーザ収容装置２へ送信する。ユーザ収容装置２のフレーム変換手段２２は、当該ＰＰＰｏＥフレームに対し、ＰＰＰｏＥのデカプセル化を行うのみで（宛先アドレスの変換を行うことなく）、転送処理手段２３に転送する。
【００８６】
なお、上述したユーザ収容装置２の構成では、ユーザ側装置３からはＰＰＰｏＥセッションがＬ３ＶＰＮ網１０のエッジ装置１１との間で確立されているかのように見える。しかし、実際にはユーザ収容装置２がセッション管理を行っており、Ｌ３ＶＰＮ網１０のエッジ装置１１はセッションに介在しない。
【００８７】
また、図２３においてＬ２ＶＰＮ網１Ｂとして例示するように、負荷分散等の目的でＬ３ＶＰＮ網１０のエッジ装置１１が複数台存在する場合には、ユーザ収容装置２ではユーザごとに異なるＬ３ＶＰＮ網１０のエッジ装置１１のレイヤ２アドレス（例えばＭＡＣアドレス）を与え、各ユーザが当該レイヤ２アドレスを宛先レイヤ２アドレスとして使用するようにしても良い。また、このような接続形態〈Ｂ〉においても、フレーム変換手段２２でＩＰデータフレームの宛先レイヤ２アドレスをＬ３ＶＰＮ網のエッジ装置１１のレイヤ２アドレスに変換する方法（図２２に示した構成）を適用することができる。
【００８８】
なお、本発明の実施形態では、ユーザセッションはユーザ収容装置２で制御している。このため、Ｌ３ＶＰＮ網１０内でのユーザセッションの識別は不要である。Ｌ３ＶＰＮ１０としては、ＭＰＬＳ−ＶＰＮ網（ＲＦＣ２５４７ｂｉｓにより規定）等の適用を考えることができる。
【００８９】
〈Ｌ２ＶＰＮ網における転送処理〉
次に、Ｌ２ＶＰＮ網における実際の転送処理（転送処理手段２３の詳細）について説明する。本発明において、Ｌ２ＶＰＮ網は、次のような網構成を適用することができる。
［網構成１］Ｌ２ＳＷ（Ｅｔｈｅｒｎｅｔ ＳＷ）で構成され、ＩＥＥＥ８０２．１Ｑ ＶＬＡＮでｘＳＰ毎に論理分割された網。
［網構成２］ＭＰＬＳ網であって、ユーザ収容装置とｘＳＰとのＰＯＩ（相互接続点）に位置するｘＳＰ毎の網終端装置をＭＰＬＳラベルパスのエッジノード（ＬＥＲ）とする網。
［網構成３］ＭＰＬＳ網であって、ユーザ収容装置とｘＳＰとのＰＯＩに位置する集約型網終端装置（同一の終端装置に複数のｘＳＰが接続されている）をＬＥＲとする網。
以下、網構成１〜３について詳細に説明する。
【００９０】
［網構成１］
図２５は、網構成１において適用されるユーザ収容装置２の構成例を示す図であり、図２６は、網構成１、即ち、Ｌ２ＶＰＮ網がＬ２ＳＷ（Ｅｔｈｅｒｎｅｔ ＳＷ）で構成され、ＶＬＡＮ（ＩＥＥＥ８０２．１Ｑ）でｘＳＰごとに論理分割された網構成を示す。
【００９１】
図２６では、ユーザにより接続先として選択される複数のｘＳＰとして、ｘＳＰ−Ａ，ｘＳＰ−Ｂ，ｘＳＰ−Ｃが例示され、これらのｘＳＰのそれぞれに対してＶＬＡＮ−ＩＤ“１００”，“２００”，“３００”がそれぞれ割り当てられている。このようにして、Ｌ２ＶＰＮ網１が複数に論理分割されたＶＬＡＮ網１２として構成されている。
【００９２】
網構成１では、ユーザ収容装置２の転送処理手段２３は、いわゆるＶＬＡＮ対応のＬ２ＳＷに備わる機能を司る。但し、転送処理手段２３は、通常のＶＬＡＮ対応のＬ２ＳＷのようにユーザフレームからＶＬＡＮを静的（スタティック）に識別するのではなく、ユーザとのセッションネゴシエーションを通じ、認証成功・接続先識別後に、ユーザからのＩＰｏＥデータフレームを動的（ダイナミック）に接続先のｘＳＰに対応するＶＬＡＮにマッピングする。
【００９３】
具体的には、図２５に示すように、転送処理手段２３は、ＶＬＡＮごとに用意され、ＭＡＣアドレス、出力ポート番号、タグの付与／除去を保持するエントリが登録されるフォワーディングテーブル２３ａを持つ。
【００９４】
フォワーディングテーブル２３ａは、ＭＡＣアドレス学習により作成される。即ち、転送処理手段２３は、自身に入力されたフレームからその送信元ＭＡＣアドレスとそのフレームの入力（受信ポート）番号とがフォワーディングテーブル２３ａに登録されているか否かを判別し、登録されていなければ、当該ＭＡＣアドレス及びポート番号を登録する。このとき、入力フレームにおけるタグ（ＶＬＡＮ−ｔａｇ）の有無から、タグの付与／除去を登録することもできる。
【００９５】
転送処理手段２３は、フォワーディングテーブル２３ａを用いて次のような転送処理を行う。転送処理手段２３には、フレーム変換手段２２から、デカプセル化されたＩＰｏＥフレームとともに識別したｘＳＰを一意に示すＶＬＡＮ−ＩＤ（「ＶＰＮ−ＩＤ」と同義）が通知される。このＶＬＡＮ−ＩＤは、別途制御用の内部バスで通知されるか、あるいはＩＰｏＥデータフレームに装置内部処理用のタグが付与されて通知される。
【００９６】
フレーム変換手段２２は、セッション管理手段２１からの通知により、セッション毎にユーザ側装置３の送信元ＭＡＣアドレスとＶＬＡＮ−ＩＤとの対応関係を把握しており、ＩＰｏＥデータフレームの送信元ＭＡＣアドレスに対応するＶＬＡＮ−ＩＤをこのＩＰｏＥデータフレームとともに転送処理手段２３に与える。
【００９７】
このような構成により、転送処理手段２３は、ＩＰｏＥデータフレームの送信元ＭＡＣアドレスに対応するＶＬＡＮ−ＩＤ（ＶＬＡＮ）を認識することができる（ＭＡＣアドレスベースのＶＬＡＮ）。
【００９８】
そして、転送処理手段２３は、ＶＬＡＮ−ＩＤに対応するフォワーディングテーブル２３ａを参照し、ＩＰｏＥデータフレームの宛先ＭＡＣアドレスに対応する出力ポートを特定するとともに、当該ＩＰｏＥデータフレームに対応するＶＬＡＮ−ｔａｇを設定し、対応出力ポートへ向けて送出する。
【００９９】
このように、ＶＬＡＮ−ＩＤは、接続先ｘＳＰを一意に示すＶＬＡＮ−ｔａｇとしてＩＰｏＥフレームに挿入される。ＶＬＡＮ−ｔａｇを持つＩＰｏＥデータフレームは、ＭＡＣブリッジングによってＬ２ＶＰＮ網（ＶＬＡＮ網１２）内を転送される。
【０１００】
一方、転送処理手段２３は、Ｌ２ＶＰＮ網側から、ＶＬＡＮ−ｔａｇが付与された形式のＩＰｏＥデータフレームを受信する。この場合、転送処理手段２３は、ＶＬＡＮ−ｔａｇを除去してフレーム変換手段２２に送る。図２５に示す例では、接続先ｘＳＰを一意に示すＶＬＡＮ−ｔａｇとしてＶＬＡＮ−ＩＤ“１００”がＩＰｏＥデータフレームに対して挿入または除去されている。
【０１０１】
［網構成２］
図２７は、上記した網構成２が適用される場合におけるユーザ収容装置２の構成例を示す図であり、図２８は、網構成２、即ちＬ２ＶＰＮ網がＭＰＬＳ網１５で構成され、ユーザ収容装置２とｘＳＰとのＰＯＩ（相互接続点）１４に位置するｘＳＰごとの網終端装置１３をＭＰＬＳラベルパスのエッジノード（ＬＥＲ）とする場合の網構成例を示す図である。
【０１０２】
網構成２では、ユーザ収容装置２の転送処理手段２３は、ＭＰＬＳ対応のエッジノード（ＬＥＲ）に相当する。但し、転送処理手段２３は、通常のＬＥＲのように、ユーザフレームをＭＰＬＳラベルパスにスタティックにマッピングするのではなく、ユーザとのセッションネゴシエーションを通じた認証成功・接続先識別後に、接続先のｘＳＰに対応するＭＰＬＳラベルパスにダイナミックにマッピングする。
【０１０３】
具体的には、図２７に示すように、転送処理手段２３は、ＶＰＮ（ｘＳＰ）毎に用意されるＭＡＣフォワーディングテーブル２３ｂと、各ＶＰＮに対して共通に使用されるＭＰＬＳラベルテーブル２３ｃとを持つ。
【０１０４】
ＭＡＣフォワーディングテーブル２３ｂは、ＶＰＮ−ＩＤごとにＭＡＣアドレスと出力ポートの対応を保持する。ＭＰＬＳラベルテーブル２３ｃは、ＶＰＮ（ｘＳＰ）ごとに送信ＭＰＬＳラベル値（「送信ラベル」とも表記）と受信ＭＰＬＳラベル値（「受信ラベル」とも表記）との対応を保持する。
【０１０５】
送信ＭＰＬＳラベル値は、Ｌ２ＶＰＮ網側にフレームを出力する際において接続先に該当するｘＳＰに転送するためのＭＰＬＳラベルパス（ＬＳＰ）を一意に示す値を示し、受信ＭＰＬＳラベル値は、Ｌ２ＶＰＮ網側からフレームを受信した際において当該フレームの送信元のｘＳＰを一意に示す値を示す。
【０１０６】
転送処理手段２３は、フレーム変換手段２２からデカプセル化されたＩＰｏＥデータフレームを受信すると、フレーム変換手段２２から通知されるＶＰＮ−ＩＤから対象のＭＡＣフォワーディングテーブル２３ｂを特定し、ＩＰｏＥデータフレームの宛先ＭＡＣアドレスを用いて対応出力ポートを検索する。このとき、ＭＰＬＳのラベル付与が指定されていれば、ＶＰＮ−ＩＤに対応する送信ＭＰＬＳラベル値をＭＰＬＳラベルテーブル２３ｃから取り出して付与（Ｐｕｓｈ）し、ラベルスイッチ転送する。なお、対応ＭＡＣフォワーディングテーブル２３ｂに該当するエントリがなければ、転送処理手段２３は、網構成１（図２５）と同様のＭＡＣアドレス学習を行う。
【０１０７】
Ｌ２ＶＰＮ網（ＭＰＬＳ網１５）内では、ＩＰｏＥデータフレームは、予め設定されたＭＰＬＳラベルパスにしたがって通過するノード（ＬＳＲ：Ｌａｂｅｌ Ｓｗｉｔｃｉｎｇ Ｎｏｄｅ）でラベルが置換（Ｓｗａｐ）されてラベルスイッチ転送され、ｘＳＰごとに用意された網終端装置１３（図２８には網終端装置１３Ａ，１３Ｂ，１３Ｃを例示）まで転送される。その後、網終端装置１３において、ＩＰｏＥデータフレームからラベルが除去され、対応ｘＳＰのエッジ装置９（図２８にはエッジ装置９Ａ，９Ｂ，９Ｃを例示）に転送される。
【０１０８】
図２７及び２８に示す構成例は、網管理者がＮＭＳ（Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）等を通じて、各ユーザ側装置３と全てのｘＳＰごとの網終端装置１３との間でＭＰＬＳラベルパスを予め設定している場合を想定している。この場合では、接続ユーザの存在しないｘＳＰへのＭＰＬＳラベルパスも保持しておく必要がある。
【０１０９】
上記に鑑み、図２９に示すように、ユーザ収容装置２がラベルパスシグナリング手段２４をさらに備えるように構成することができる。ラベルパスシグナリング手段２４は、ユーザの接続先ｘＳＰが識別された後において、ユーザ収容装置２と当該ｘＳＰへの網終端装置１３との間でＭＰＬＳラベルパスが設定されていない場合には、当該ユーザの接続先ｘＳＰの識別をトリガとして所望のＭＰＬＳラベルパスを設定するためのシグナリングを行う。
【０１１０】
ＭＰＬＳでは、ラベルシグナリングプロトコルとして、ＬＤＰ（ＲＦＣ３０３６），ＣＲ−ＬＤＰ（ＲＦＣ３２１２），ＲＳＶＰ−ＴＥ（ＲＦＣ３２０９）等が規定されている。ラベルパスシグナリング手段２４には、これらのラベルシグナリングプロトコルのいずれをも適用することができる。但し、ＭＰＬＳにおけるラベルパスは片方向性（Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ）である。従って、ユーザ収容装置２は、網終端装置１３ヘラベルを配布し、且つ網終端装置１３からラベルの配布を受ける必要がある。
【０１１１】
ユーザ収容装置２から網終端装置１３へ配布されるラベルは、ＭＰＬＳラベルテーブル２３ｃ（図２７）に登録される受信ラベルに相当する。受信ラベルは、ユーザ収容装置２において網終端装置１３とユーザ収容装置２間との下り方向（網終端装置１３→ユーザ収容装置２）のＭＰＬＳラベルパスを識別するためのラベルである。網終端装置１３から配布を受けるラベルは、ＭＰＬＳラベルテーブル２３ｃに登録される送信ラベルに相当する。送信ラベルは、ユーザ収容装置２において上り方向のＭＰＬＳラベルパスを識別（上り方向のフレームに付与）するラベルである。
【０１１２】
図２９に示すように、セッション管理手段２１は、ユーザの接続先のｘＳＰを識別したときに、当該ｘＳＰに対する接続者がいるか否か（当該ｘＳＰに対応する網終端装置１３との間でラベルパスが設定されているか否か）を判定し、ＭＰＬＳラベルパスが設定されていないことが分かると、ラベルパスシグナリング手段２４に対し、ラベルパスを設定するためのシグナリングを行うことを通知する（図２９の▲１▼）。
【０１１３】
ラベルパスシグナリング手段２４は、まず接続先のｘＳＰに対応するＶＰＮ−ＩＤに対応する送信ラベルを該当する網終端装置１３に配布し（「ＤＵ， Ｄｏｗｎｓｔｒｅａｍ Ｕｎｓｏｌｉｃｉｔｅｄモード」と呼ぶ：図２９の▲２▼）、かつ当該網終端装置１３にラベル配布を要求して受信ラベルの配布を受ける（「ＤｏＤ，Ｄｏｗｎｓｔｒｅａｍ ｏｎ Ｄｅｍａｎｄ」モードと呼ぶ：図２９の▲３▼及び▲４▼）。そして、ラベルパスシグナリング手段２４は、送信ラベルと受信ラベルの情報の設定を転送処理手段２３へ通知する（図２９の▲５▼）。転送処理手段２３は、送信ラベルと受信ラベルとの対応をＶＰＮ−ＩＤに応じたＭＰＬＳラベルテーブル２３ｃに設定する。
【０１１４】
これにより、転送処理手段２３は、セッション管理手段２１によるユーザの接続先ｘＳＰの識別をトリガとして、ユーザ収容装置２−網終端装置１３間にＰＰＰｏＥセッションに応じた双方向のＭＰＬＳラベルパスを設定することができる。
【０１１５】
なお、網終端装置１３がユーザ収容装置２からのＤＵモードでのラベル配布をトリガとして、同じくＤＵモードでユーザ収容装置２にラベルを配布するように構成され、ラベルパスシグナリング手段２４が、このＤＵモードにより配布される受信ラベルを受け取るようにしても良い。この場合には、ラベルパスシグナリング手段２４は、ＤｏＤモードによるラベル要求（図２９の▲３▼）を行わなくて済む。
【０１１６】
また、ラベルパスシグナリング手段２４は、或るラベルパスについて接続者がいなくなったことを示す通知をセッション管理手段２１から受け取るように構成されており、この通知を受け取った場合には、当該ラベルパスを削除するためのシグナリングを行う。このとき、転送処理手段２３に対し、ラベルパスの削除が通知され、転送処理手段２３が該当ラベルパスに係るエントリをＭＰＬＳラベルテーブル２３ｃから削除するように構成することもできる。
【０１１７】
以上のような構成を適用すれば、全てのｘＳＰのそれぞれについて、ユーザ収容装置２と各ｘＳＰに対応する網終端装置１３との間に予めＭＰＬＳラベルパスを設定しておく必要がなくなる。即ち、シグナリングに必要なラベルパスのみを保持しておくことができる。
【０１１８】
［網構成３］
図３０は、上記した網構成３に適用されるユーザ収容装置２の構成例を示す図であり、図３１は、網構成３、すなわちＬ２ＶＰＮ網がＭＰＬＳ網１５であって、ユーザ収容装置２とｘＳＰとのＰＯＩ（相互接続点）１４に位置する集約型網終端装置１６（同一終端装置から複数ｘＳＰに接続されている）をＬＥＲとする網構成例を示す図である。集約型網終端装置１６は、複数のｘＳＰのエッジ装置９に接続される。
【０１１９】
網構成３では、図３１に示すような集約型網終端装置１６が用いられる。この場合、ＭＰＬＳラベル一段では、集約型網終端装置１６において、各ユーザからのＩＰｏＥデータフレームを、ユーザが選択した接続先情報に基づいて、複数のｘＳＰ（エッジ装置９）に振り分ける処理を行うことができない。
【０１２０】
このため、各ユーザ収容装置２と集約型網終端装置１６間でＩＰｏＥデータフレームをＭＰＬＳ網１５を介して転送するためのＭＰＬＳラベルパス（Ｔｕｎｎｅｌ（トンネル）ラベルパス）および接続先ｘＳＰを一意に示すＭＰＬＳラベルパス（ＶＣラベルパス）をあらかじめ設定する必要がある。
【０１２１】
各ユーザ収容装置２および集約型網終端装置１６は、それぞれＶＣラベル値からｘＳＰを識別する。このため、同一のユーザ収容装置２から集約型網終端装置１６へのトンネルラベルパスは接続先ｘＳＰが異なっていても同一のトンネルラベルパスにマージすることができる。即ち、接続先ｘＳＰが異なっていても同一のトンネルラベルパスを用いてＩＰｏＥデータフレームを転送することができる。
【０１２２】
その他、ＭＰＬＳ網１５内において、網終端装置１６のひとつ手前の中継装置（ＬＳＲ）でラベル（Ｔｕｎｎｅｌ）を除去（Ｐｏｐ）して網終端装置１６に転送することもできる（「ＰＨＰ： Ｐｅｎｕｌｔｉｍａｔｅ Ｈｏｐ Ｐｏｐｐｉｎｇ」と呼ぶ）。
【０１２３】
なお、ユーザ収容装置２とｘＳＰとのＰＯＩに位置するｘＳＰ毎の網終端装置をＭＰＬＳラベルパスのエッジノード（ＬＥＲ）とする網（上記網構成２）においても、トンネル及びＶＣラベルパスの二段ラベルパス構成を用いることができる。
【０１２４】
上述したように、網構成２や３でＭＰＬＳラベルを二段で用いる場合も、ユーザの接続先ｘＳＰ識別をトリガとしてラベルパスシグナリング手段２４がトンネル及びＶＣラベルパスを動的に設定する構成とすることができる。このような構成例を図３２に示す。
【０１２５】
但し、網構成３（集約型網終端装置１６が用いられる場合）では、ユーザがどのｘＳＰに接続（アクセス）する場合でも、これらの間を流れるＩＰｏＥデータフレームは集約型網終端装置１６を経由する。このため、ユーザ収容装置２と集約型網終端装置１６との間でトンネルラベルパスが常に設定されているように構成し、ＶＣラベルパスのみが対応するｘＳＰに対する接続者の有無に応じて設定／削除されるように構成しても良い。
【０１２６】
〈転送処理手段の具体的構成〉
上述したように、本発明に係るＬ２ＶＰＮ網の構成としては、ＶＬＡＮ網あるいはＭＰＬＳ網を適用することができる。この場合、ユーザ収容装置２における転送処理手段２３は、認証成功・接続先識別後にＩＰｏＥデータフレームを接続先のｘＳＰごとに用意されたＶＰＮに動的にマッピングする点を除けば、通常のＶＬＡＮ対応のＬ２ＳＷあるいはＭＰＬＳ対応のＬＥＲに相当する機能を持つ。
【０１２７】
従って、図３３に示すように、１以上のＭＰＬＳインタフェースカード３１，１以上のイーサネット（Ｅｔｈｅｒｎｅｔ）インタフェースカード３２，切替スイッチ３３を含む転送処理手段２３を備えたシャーシ型（多彩な機能を実現するインタフェースカードを追加挿入可能な）通信装置３０に対し、フレーム判別手段２０，セッション管理手段２１及びフレーム変換手段２２を持つ通信モジュール３４を追加することで、ユーザ収容装置２を構成することが可能である。
【０１２８】
なお、図３３に示すような構成を持つユーザ収容装置２が網構成２又は３に適用される場合には、通信モジュール３４がラベルパスシグナリング手段２４を更に含むように構成されても良く、ラベルパスシグナリング手段２４を含む通信モジュールが図３３に示す構成に更に追加されるように構成されていても良い。
【０１２９】
〈Ｌ２ＶＰＮネットワークの統合〉
また、ユーザ収容装置２では、セッション管理手段２１が接続先ｘＳＰを識別するとともに、加えて提供サービス形態（最大速度等の品質、或いは一戸建てや集合住宅型シェアドアクセスなど）も同様に識別し、複数のユーザ間において接続先ｘＳＰが同じであっても、提供サービス形態（例えばフレーム転送の最大速度）が異なる場合には、相互に異なるＶＰＮ−ＩＤを割り当て、ＩＰｏＥデータフレームがユーザ毎に異なるＶＰＮを介してｘＳＰ−ユーザ間を転送されるように構成することができる。
【０１３０】
この場合、ＶＰＮ−ＩＤは、提供サービス形態毎に用意される。従って、フレーム変換手段２２におけるテーブル（テーブル２２ａ，２２ｂ），及び転送処理手段２３におけるフォワーディングテーブル（テーブル２３ａ，２３ｂ）は、提供サービス形態毎に用意される。
【０１３１】
図３４には、ｘＳＰ−Ａの提供サービス形態として最大速度１００Ｍｂｐｓサービス及びシェアドサービスとが用意されている場合において、これらのサービス毎に用意されたＶＰＮを通ってユーザ−ｘＳＰＡ間をＩＰｏＥデータフレームが転送される例が示されている。
【０１３２】
上記のような接続先及び提供サービス形態毎に異なるＶＰＮが使用される構成となれば、Ｌ２ＶＰＮ網内にＢＲＡＳを設けることが不要となる。従って、ＢＲＡＳで接続先及びサービスを識別するためにアグリゲートトラフィックを分離する網構成も不要となる。
【０１３３】
このような状況下では、ｘＳＰ選択接続サービスと、ＶＰＮは固定ではあるが、ユーザごとに保証帯域など提供サービスの異なるユーザ拠点間接続サービスとの混在が可能となる統合Ｌ２ＶＰＮネットワークを実現することができる。
【０１３４】
《実施例１》
次に、本発明の実施例１について図３５，３６を用いて説明する。実施例１は、複数のｘＳＰのエッジ装置９（９Ａ，９Ｂ，９Ｃ）が、ｘＳＰ毎に用意されたＬ２ＶＰＮ網（ｘＳＰ毎に用意されたＶＬＡＮ網で論理分割されている）の終端点（網終端装置１３（１３Ａ，１３Ｂ，１３Ｃ））に直接接続されている場合の網構成が示されている。
【０１３５】
図３５において、ユーザ側装置３は、任意のｘＳＰ（例えば、ｘＳＰ−Ａ）を選択して当該ｘＳＰに対する通信を開始する場合には、最初に、ＰＡＤＩをブロードキャストする（Ｓ１１）。
【０１３６】
ユーザ収容装置２は、ＰＡＤＩを受信すると、フレーム判別手段２０においてフレームの判別処理を行う。フレーム判別手段２０は、フレーム判別の結果、ＰＡＤＩをセッションネゴシエーションフレームであると判別し、セッション管理手段２１に転送する。
【０１３７】
セッション管理手段２１では、ユーザ側装置３のＰＡＤＩに対して、ＰＡＤＯを返す（Ｓ１２）。この時、ＰＡＤＯの送信元ＭＡＣアドレスには、ユーザ収容装置２のＭＡＣアドレスが設定される。
【０１３８】
ユーザ側装置３はＰＡＤＯを受信することにより、２地点間（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ）でセッションを確立する装置（ユーザ収容装置２）のＭＡＣアドレスを知る。ユーザ側装置３は、以降、このＭＡＣアドレスが宛先ＭＡＣアドレスに設定されたＰＰＰｏＥフレームをユニキャストする。
【０１３９】
続いて、ユーザ側装置３からＰＡＤＲがユーザ収容装置２に送信され（Ｓ１３）、ユーザ収容装置２では、セッション管理手段２１がＰＡＤＲ（Ｓ１３）に基づいてＳｅｓｓｉｏｎ−ＩＤ（セッションＩＤ）を確立し、ＰＡＤＳを応答する（Ｓ１４）。そして、当該ＰＰＰｏＥセッションに対するデータリンク（ＬＣＰ）が確立される（Ｓ１５）。
【０１４０】
データリンクが確立されると、ユーザ認証のための要求（ＣＨＡＰ Ｃｈａｌｌｅｎｇｅ）がユーザ収容装置２からユーザ側装置３へ送信される（Ｓ１６）。ＣＨＡＰ要求に対し、ユーザ側装置３は、「ユーザ名＠ｘＳＰ名」で接続先ｘＳＰが指定されたＣＨＡＰ応答をユーザ収容装置２に返すことができる（Ｓ１７）。
【０１４１】
ユーザ収容装置２では、セッション管理手段２１がＣＨＡＰ応答を受け付けると、ＲＡＤＩＵＳ認証を行うための認証要求（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ）を、接続先のｘＳＰの網内に存するＲＡＤＩＵＳサーバに対して発呼する（Ｓ１８）。これにより、当該ｘＳＰのＲＡＤＩＵＳサーバにより、ユーザのＲＡＤＩＵＳ認証が行われる。
【０１４２】
この時、認証要求が一旦Ｌ２ＶＰＮ網１内のプロキシＲＡＤＩＵＳサーバに転送され、そこからｘＳＰ網内のＲＡＤＩＵＳサーバに転送されるようにしてもよい。これにより、ユーザ収容装置２と各ｘＳＰのＲＡＤＩＵＳサーバとの間における通信を一元化することができ管理運用が容易となる。
【０１４３】
ＲＡＤＩＵＳサーバは、ユーザ認証が成功した場合には、認証成功を示す認証応答（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）をユーザ収容装置２へ返す（Ｓ１９）。成功を示す認証応答は、ユーザに対して割り当てられるＩＰアドレスや、当該ｘＳＰのエッジ装置のＭＡＣアドレス等を含むことができる。このようにしてユーザ側装置３とユーザ収容装置２との間でＰＰＰｏＥセッションが確立される。
【０１４４】
ユーザ収容装置２は、認証応答に含まれたＩＰアドレス値をもとにＩＰＣＰを行ってユーザにＩＰアドレスを割り当てる（Ｓ２０）。
【０１４５】
また、ユーザ収容装置２において、セッション管理手段２１は、認証成功・接続先識別に伴い、フレーム変換手段２２に対し、当該ユーザ側装置３のＭＡＣアドレス，ＰＰＰｏＥ Ｓｅｓｓｉｏｎ−ＩＤ，接続先のｘＳＰのエッジ装置９のＭＡＣアドレス，及びＬ２ＶＰＮ網１内で接続先のｘＳＰを一意に示すＶＰＮ−ＩＤを含む登録通知を与える。フレーム変換手段２２は、セッション管理手段２１からの通知内容をテーブル２２ｂ（図２２）に登録する。
【０１４６】
ユーザ側装置３はＩＰアドレスの割り当てを受けた後、ＰＰＰｏＥカプセル化したＩＰデータフレーム（ＩＰｏＰＰＰｏＥ）をユーザ収容装置２に送出する（Ｓ２１）。
【０１４７】
ユーザ収容装置２において、フレーム判別手段２０は、判別の結果、受信フレームがＩＰデータフレームであると判別し、フレーム変換手段２２に転送する。フレーム変換手段２２は、受信フレームの送信元ＭＡＣアドレスのエントリがテーブル２２ｂに存在する場合には、ＰＰＰｏＥデカプセル化を行ってＩＰｏＥデータフレームに変換する。さらに、フレーム変換手段２２は、ＩＰデータフレームの宛先ＭＡＣアドレスを当該ｘＳＰのエッジ装置９のＭＡＣアドレスに変換し、転送処理手段２３に対応するＶＰＮ−ＩＤ（ＶＬＡＮ−ＩＤ）情報とともに転送する。
【０１４８】
なお、フレーム変換手段２２は、受信フレームの送信元ＭＡＣアドレスのエントリがテーブル２２ｂに存在しない場合には、未認証とみなしてフレームを廃棄する。
【０１４９】
実施例１における転送処理手段２３は、ＶＬＡＮ対応のＬ２ＳＷに相当する。そのため、ユーザの最初のＩＰデータ通信の場合は、当該ＶＬＡＮ−ＩＤのフォワーディングテーブル（ＭＡＣブリッジングテーブル）２３ａ（図２５）に対応エントリが存在しないのでアドレス学習する。即ち、送信元ＭＡＣアドレスとユーザ側装置３が接続されているポートの番号をフォワーディングテーブル２３ａに登録する。
【０１５０】
転送処理手段２３は、受信フレームの宛先ＭＡＣアドレスからフォワーディングテーブル２３ａ内の出力ポートを検索し、対応するＶＬＡＮ−ｔａｇ（ＶＬＡＮ−ＩＤ“１００”）を付与してＬ２ＶＰＮ網（ＶＬＡＮ網）１内に送出する。
【０１５１】
図３６に示す例では、Ｌ２ＶＰＮ網１内はＶＰＮごとに論理分割されている（ＶＬＡＮ−ＩＤ“１００”，“２００”，“３００”で３分割）。このため、ＩＰｏＥデータフレームは、ＭＡＣブリッジング転送によって接続先ｘＳＰ（ｘＳＰ−Ａ）との境界（ＰＯＩ）に位置する網終端装置１３Ａまで転送される（Ｓ２２）。そして、網終端装置１３においてＶＬＡＮ−ｔａｇを除去してｘＳＰ−Ａのエッジ装置９Ａに転送される（Ｓ２３）。
【０１５２】
ｘＳＰ（ｘＳＰ−Ａ）からユーザ側装置３に対して送信されるデータ（ＩＰｏＥデータフレーム）は、Ｓ２１からＳ２３に示す処理と反対の処理が実行される。まず、ｘＳＰ−Ａのエッジ装置９Ａから網終端装置１３ＡまでＩＰデータ（ＩＰｏＥデータフレーム）が転送される（Ｓ２４）。網終端装置１３Ａは、ＩＰデータにＶＬＡＮ−ｔａｇ（ＶＬＡＮ−ＩＤ“１００”）を付与して送出する。当該ＩＰデータは、Ｌ２ＶＰＮ網１内をＭＡＣブリッジング転送される（Ｓ２５）。
【０１５３】
ユーザ収容装置２では、ＭＡＣブリッジング転送されたＩＰデータを受け取る。ユーザ収容装置２の転送処理手段２３は、ＩＰデータのＶＬＡＮ−ｔａｇを除去して、フレーム変換手段２２へ転送する。フレーム変換手段２２は、ＩＰデータの送信元ＭＡＣアドレスを自装置のＭＡＣアドレスに変換し、ＰＰＰｏＥカプセル化してユーザ側装置３に送出する（Ｓ２６）。
【０１５４】
実施例１によれば、ユーザと選択接続先のｘＳＰとの間を中継するＬ２ＶＰＮ網１のエッジにおいて１以上のユーザを収容するユーザ収容装置２が設置され、ユーザ収容装置２がユーザが選択したｘＳＰへアクセスするためのＰＰＰセッションをセッションコントロールを、標準化ベースの通信プロトコル（ＰＰＰｏＥ）を用いて行う。このため、多数のユーザに対するセッションコントロールが複数のユーザ収容装置２に分散される。従って、ＢＲＡＳを用いた場合のようなボトルネックの発生を回避することができる。
【０１５５】
なお、実施例１では、ＶＬＡＮ−ＩＤがｘＳＰを一意に示す場合について説明した。これに代えて、或るｘＳＰがサービスを最大速度１０Ｍｂｐｓと１００Ｍｂｐｓとの二種類で提供可能な場合（提供サービス形態が複数の場合）や、ユーザが集合住宅に存する場合等のシェアド型などのサービスに応じて、同一のｘＳＰに対する接続であっても異なるＶＬＡＮ−ＩＤが割り当てられ、Ｌ２ＶＰＮ網内でＶＬＡＮに応じた帯域制御が行われるようにすることも可能である。
【０１５６】
《実施例２》
次に、本発明の実施例２を図３７及び３８を用いて説明する。 実施例２は、ユーザ−ｘＳＰ間のトラフィックがＬ２ＶＰＮ網（ｘＳＰ毎のＭＰＬＳラベルパスが用意されるＥｏＭＰＬＳ網で構成されている）、さらにＬ３ＶＰＮ網１０（例えば、ＩＰ−ＶＰＮ網）を経由する場合の接続形態例を示す。
【０１５７】
図３７及び３８に示す例では、Ｌ２ＶＰＮ網がＥｏＭＰＬＳ網であって、ユーザ収容装置２および接続先ネットワークとのＰＯＩ（相互接続点）に位置する集約型網終端装置がＭＰＬＳラベルパスのエッジノード（Ｌ３ＶＰＮ網のエッジ装置）１１として構成され、さらに、各ｘＳＰ（ｘＳＰ−Ａ，ｘＳＰ−Ｂ，ｘＳＰ−３）のエッジ装置９Ａ，９Ｂ，９ＣがＬ３ＶＰＮ網１０に接続されている。
【０１５８】
この場合、各ユーザ収容装置２によるレイヤ２転送の宛先に該当する装置がエッジ装置１１となる。従って、各ユーザがｘＳＰを選択接続する場合でも、各ユーザからのＩＰｏＥデータフレームのＬ２ＶＰＮ網１における宛先は固定となる。このため、ユーザ収容装置２において、ＩＰデータの宛先ＭＡＣアドレスの変換は不要となる。
【０１５９】
ユーザ収容装置２のセッション管理手段２１は、ユーザ側装置３からのＰＰＰｏＥ発呼（ＰＡＤＩ）に対し、応答ＰＰＰｏＥフレーム（ＰＡＤＯ）の送信元レイヤ２アドレス（送信元ＭＡＣアドレス）としてエッジ装置１１のレイヤ２アドレス（ＭＡＣアドレス）を設定する（Ｓ３１，Ｓ３２）。
【０１６０】
その後、実施例１におけるＳ１３〜Ｓ１９と同様の手順が行われ、ＰＰＰセッションが確立され、ユーザと選択接続先のｘＳＰとの間でＩＰ通信が可能な状態となる（Ｓ３３〜Ｓ３９）。なお、ＰＡＤＲ以降のユーザからのセッションネゴシエーションフレームの宛先アドレスは、エッジ装置１１のＭＡＣアドレスであるが、ユーザ収容装置２のフレーム判別手段２０は、当該セッションネゴシエーションフレームをセッション管理手段２１に与える。
【０１６１】
認証・接続先識別後（ＰＰＰセッション確立後）にユーザ側装置３からＰＰＰｏＥカプセル化されたＩＰデータフレームが送出されると、フレーム変換手段２２は、ＰＰＰｏＥデカプセル化を行い、得られたＩＰｏＥデータフレームを対応ＶＰＮ−ＩＤとともに転送処理手段２３に送る（Ｓ４１）。この時、ＩＰデータの宛先ＭＡＣアドレスの変換は行われない。
【０１６２】
転送処理手段２３では、フォワーディングテーブル及びＭＰＬＳラベルテーブルを参照し、当該ＶＰＮ−ＩＤに対応したＭＰＬＳラベル（ＶＣラベルおよびＴｕｎｎｅｌラベル）をＩＰｏＥデータフレームに付与してＬ２ＶＰＮ網１内に転送する。Ｌ２ＶＰＮ網１内では、Ｔｕｎｎｅｌラベルのみを参照してラベルスイッチが行われる（Ｓ４２〜Ｓ４４，Ｓ４７〜Ｓ４９）。
【０１６３】
Ｌ３ＶＰＮ網１０のエッジ装置１１は、ＩＰデータを受け取ると、ＭＰＬＳを終端し、Ｌ３ＶＰＮカプセル化して接続先のｘＳＰのエッジルータ９に転送する（Ｓ４５）。
【０１６４】
接続先のｘＳＰからユーザ側装置３に対して送信されるＩＰデータは、Ｓ４０からＳ４５に示す処理と反対の処理により転送される。従って、網内を転送されてきたＩＰデータは、ユーザ収容装置２においてＰＰＰｏＥカプセル化されてユーザ側装置３に送出される（Ｓ５０）。この時、Ｓ４１と同様に、ＩＰデータの宛先ＭＡＣアドレスの変換は不要である。
【０１６５】
なお、ユーザ収容装置２にラベルのシグナリングを行うラベルパスシグナリング手段２４が設けられていれば、ユーザの接続先ｘＳＰの識別をトリガとしてダイナミックにラベルパスを設定することができる。網内では、ＭＰＬＳ（Ｔｕｎｎｅｌ）ラベルパスに沿ってＩＰデータがラベルスイッチング転送され、Ｌ３ＶＰＮ網１０のエッジ装置１１に渡される。
【０１６６】
そして、Ｌ３ＶＰＮ網１０でもまたＶＰＮごとの転送処理がなされてｘＳＰに転送される。なお、ユーザセッションはユーザ収容装置２で制御しているため、Ｌ３ＶＰＮ網１０内でユーザセッションの識別は不要である。
【０１６７】
〈その他〉
本発明は、以下のように特定することができる。
（付記１） ＰＰＰｏＥを用いてユーザが複数の接続先から任意の接続先選択を行う通信システムにおいて、ユーザにより選択された接続先宛のデータを中継するレイヤ２網のエッジに配置され、１以上のユーザ側装置を収容する通信装置であって、
ユーザ側装置から受信するＰＰＰｏＥフレームがＰＰＰセッション確立用のフレームか前記接続先宛のデータを含むフレームかを判別するフレーム判別手段と、
前記フレーム判別手段で判別されたセッション確立用のフレームに基づいて、ユーザ認証及び接続先識別を含むユーザ側装置とユーザにより選択された接続先との間の通信に係るＰＰＰセッションを確立するための処理を行うセッション管理手段と、
前記フレーム判別手段で判別された前記接続先宛のデータを含むＰＰＰｏＥフレームから当該データを抽出するフレーム変換手段と、
前記フレーム変換手段で抽出されたデータを前記レイヤ２網へ送出する転送処理手段と
を含む通信装置。（１）
（付記２） 前記各接続先の網のエッジ装置が接続先毎に用意された前記レイヤ２網の網終端装置にそれぞれ接続されており、
前記フレーム変換手段は、前記接続先宛のデータに宛先レイヤ２アドレスとして設定されている自装置のレイヤ２アドレスを当該接続先のエッジ装置のレイヤ２アドレスに変換して前記転送処理手段に渡す
付記１記載の通信装置。（２）
（付記３） 前記レイヤ２網が前記各接続先の網を収容するレイヤ３網にエッジ装置を介して接続され、このエッジ装置が前記レイヤ２網を通じて受信する前記接続先宛のデータに対して前記レイヤ２網の終端処理を行うとともに前記レイヤ３網を介して該当する接続先の網へ転送する処理を行うように構成されており、前記セッション管理手段は、ユーザ側装置との間におけるＰＰＰセッションの確立において、ユーザ側装置に転送されるセッション確立用フレームの送信元レイヤ２アドレスとして前記エッジ装置のレイヤ２アドレスを設定し、
前記フレーム変換手段は、ＰＰＰセッションの確立後にユーザ側装置から受信する接続先宛のデータに宛先レイヤ２アドレスとして設定されている前記エッジ装置のレイヤ２アドレスを変更することなく当該データを前記転送処理手段に渡す
付記１記載の通信装置。（３）
（付記４） 前記レイヤ２網が前記各接続先の網を収容するレイヤ３網に複数のエッジ装置を介して接続され、各エッジ装置が前記レイヤ２網を通じて受信する前記接続先宛のデータに対して前記レイヤ２網の終端処理を行うとともに前記レイヤ３網を介して該当する接続先の網へ転送する処理を行うように構成されており、
前記セッション管理手段は、ユーザ側装置との間におけるＰＰＰセッションの確立において、ユーザ側装置に転送されるセッション確立用フレームの送信元レイヤ２アドレスとして、接続先に応じたエッジ装置のレイヤ２アドレスを設定し、
前記フレーム変換手段は、ＰＰＰセッションの確立後にユーザ側装置から受信する接続先宛のデータに宛先レイヤ２アドレスとして設定されている前記エッジ装置のレイヤ２アドレスを変更することなく当該データを前記転送処理手段に渡す
付記１記載の通信装置。（４）
（付記５） 前記レイヤ２網は、ＩＥＥＥ８０２．１Ｑ ＶＬＡＮに従って接続先毎に論理分割されており、
前記転送処理手段は、前記接続先宛のデータに対し、当該データの接続先に対応するＶＬＡＮ−ｔａｇを設定して前記レイヤ２網に送出する
付記１〜４のいずれかに記載の通信装置。（５）
（付記６） 前記レイヤ２網は、各接続先の網と前記通信装置との相互接続点にそれぞれ位置する接続先毎の網終端装置と前記通信装置との間に前記接続先毎に用意されるＭＰＬＳラベルパスが設定されるＭＰＬＳ網として構成され、
前記転送処理手段は、前記接続先宛のデータに対し、このデータの接続先に対応するＭＰＬＳラベルを設定して前記ＭＰＬＳ網に送出する
付記１〜４のいずれかに記載の通信装置。
（付記７） 前記接続先宛のデータを転送するためのＭＰＬＳラベルパスが設定されていない場合に、当該ＭＰＬＳラベルパスを設定するためのシグナリングを行うラベルパスシグナリング手段をさらに含む
付記６記載の通信装置。
（付記８） 前記レイヤ２網は、各接続先の網と前記通信装置との相互接続点に位置する集約型網終端装置と前記通信装置との間に前記接続先宛のデータの転送用の第１のＭＰＬＳラベルパスと、このデータの接続先の識別用の第２のＭＰＬＳラベルパスとが設定されるＭＰＬＳ網として構成され、
前記転送処理手段は、前記接続先宛のデータに対し、当該データを第１のＭＰＬＳラベルパスを通じて転送するための第１のＭＰＬＳラベルと、当該データの接続先を識別するための第２のＭＰＬＳラベルとを設定して前記ＭＰＬＳ網に送出する
付記１〜４のいずれかに記載の通信装置。
（付記９） 前記接続先宛のデータに対し、対応する第１のＭＰＬＳラベルパスと第２のＭＰＬＳラベルパスとの少なくとも一方が設定されていない場合には、設定されていないＭＰＬＳラベルパスを設定するためのシグナリングを行うラベルパスシグナリング手段をさらに含む
付記８記載の通信装置。
（付記１０） 前記転送処理手段として機能する、スイッチ，イーサネットインタフェース，ＭＰＬＳインタフェースを備えるシャーシ型の通信装置に対し、前記フレーム判別手段，前記セッション管理手段，及び前記フレーム変換手段を含む通信モジュールが付加されてなる
付記６〜９のいずれかに記載の通信装置。
（付記１１） 前記転送処理手段が、接続先毎に且つ接続先からユーザに対するサービスの提供形態毎に用意されるレイヤ２の仮想閉域網を介して前記接続先のデータが前記レイヤ２網を転送されるように、当該データの接続先及びサービスの提供形態に対応するレイヤ２の仮想閉域網に当該データをマッピングして送出する付記１〜１０のいずれかに記載の通信装置。
【０１６８】
【発明の効果】
本発明によれば、セッションコントロール処理が集中することにより生じるボトルネックを回避することができる通信装置を提供することが可能となる。
【図面の簡単な説明】
【図１】イーサフレームフォーマットを示す図である。
【図２】イーサタイプを示す図である。
【図３】ＰＰＰｏＥを使用したＢＲＡＳを介したユーザ側装置とｘＳＰ間の接続イメージの一例を示す図である。
【図４】ＰＰＰｏＥによるＢＲＡＳを介したユーザ側装置とｘＳＰとの間の接続における通信方式のシーケンス例を示す図である。
【図５】ＰＰＰｏＥフレームフォーマットの一例を示す図である。
【図６】ＰＰＰｏＥフレームフォーマットの一例を示す図である。
【図７】ＰＰＰｏＥを使用したＢＲＡＳを介したユーザ側装置とｘＳＰ間の接続イメージの一例を示す図である。
【図８】ＢＲＡＳの内部を示す図である。
【図９】ＰＰＰ状態遷移テーブルを示す図である。
【図１０】Ｌ２ＳＷをベースとした広域ＬＡＮサービス例を示す図である。
【図１１】ＥｏＭＰＬＳサービス例を示す図である。
【図１２】ＢＲＡＳを用いたｘＳＰ選択接続サービスの問題点を説明する図である。
【図１３】ＩＥＥＥ８０２．１Ｘのフレームフォーマットを示す図である。
【図１４】ＩＥＥＥ８０２．１Ｘによるシーケンス例を示す図である。
【図１５】ＩＥＥＥ８０２．１Ｘによる接続イメージを示す図である。
【図１６】本発明の実施形態に係る通信装置及びこの通信装置を含むＬ２ＶＰＮネットワークシステムの概要を示す図である。
【図１７】ユーザ収容装置のシステム構成を示す図である。
【図１８】フレーム判別手段の説明図である。
【図１９】セッション管理手段の説明図である。
【図２０】フレーム変換手段の説明図である。
【図２１】Ｌ２ＶＰＮ網の終端点でｘＳＰに直接接続される場合の接続形態例を示す図である。
【図２２】図２１に示す接続形態において適用されるユーザ収容装置の構成例を示す図である。
【図２３】Ｌ２ＶＰＮ網、さらにＬ３ＶＰＮ網を経由する場合の接続形態例を示す図である。
【図２４】図２３に示す接続形態において適用されるユーザ収容装置の構成例を示す図である。
【図２５】ｘＳＰごとに論理分割された網構成において適用されるユーザ収容装置の構成例を示す図である。
【図２６】ＶＬＡＮ（ＩＥＥＥ８０２．１Ｑ）でｘＳＰごとに論理分割された網構成を示す。
【図２７】図２８に示す網構成が適用される場合におけるユーザ収容装置の構成例を示す図である。
【図２８】Ｌ２ＶＰＮ網がＭＰＬＳ網１５で構成され、ｘＳＰごとの網終端装置をＭＰＬＳラベルパスのエッジノード（ＬＥＲ）とする場合の網構成例を示す図である。
【図２９】ラベルパスシグナリング手段をさらに備えたユーザ収容装置の構成例を示す図である。
【図３０】図３１に示す網構成に適用されるユーザ収容装置の構成例を示す図である。
【図３１】Ｌ２ＶＰＮ網がＭＰＬＳ網であって集約型網終端装置をＬＥＲとする網構成例を示す図である。
【図３２】ＭＰＬＳラベルを二段で用いる場合のユーザ収容装置の構成例を示す図である。
【図３３】本発明におけるユーザ収容装置の構成例を示す図である。
【図３４】本発明における統合Ｌ２ＶＰＮネットワークの構成例を示す図である。
【図３５】本発明の実施例１を説明する図である。
【図３６】本発明の実施例１を説明する図である。
【図３７】本発明の実施例２を説明する図である。
【図３８】本発明の実施例２を説明する図である。
【符号の説明】
１ Ｌ２ＶＰＮ網
２ ユーザ収容装置
３ ユーザ側装置（ユーザ端末）
９ エッジ装置（エッジルータ）
１１ Ｌ３ＶＰＮ網エッジ装置
１２ ＶＬＡＮ網
１３ 網終端装置
１５ ＭＰＬＳ網
１６ 集約型網終端装置
２０ フレーム判別手段
２１ セッション管理手段
２２ フレーム変換手段
２２ａ，ｂ テーブル（フレーム変換手段）
２３ 転送処理手段
２３ａ，ｂ フォワーディングテーブル
２３ｃ ＭＰＬＳラベルテーブル
２４ ラベルパスシグナリング手段
３０ シャーシ型ＭＰＬＳ対応通信装置
３１，３２ インタフェース
３３ 切替スイッチ
３４ 通信モジュール
【発明の属する技術分野】
本発明は、１以上のユーザ側装置を収容する通信装置、及びこの通信装置がエッジ部分に配置されるＬ２ＶＰＮ（Ｌａｙｅｒ ２ Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）網に関する。例えば、本発明は、ｘＳＰ（インターネットサービスプロバイダ（ＩＳＰ）、コンテンツサービスプロバイダ（ＣＳＰ））や企業ネットワークへのアクセス・メトロ網において、上記通信装置において認証・接続先識別を含むセッションコントロールを行い、ｘＳＰ接続網とユーザ拠点間接続網のシームレスな統合を可能とする技術に関する。
【０００２】
【従来の技術】
近年、インターネットのブロードバンド化が本格化している。従来の電話網によるダイヤルアップ接続に比べ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）などは、数十倍のスピードでのアクセスを提供することができる。
【０００３】
また、今後、各家庭まで光ファイバが敷設され、それに伴って高画質の映像配信サービスや音楽ダウンロードサービスなどを提供するｘＳＰ（ＩＳＰ，ＣＳＰ等）が数多く出現すると考えられる。
【０００４】
また、企業網が広帯域なアクセス・メトロ網に接続されることによって、家庭と企業間で大容量かつ高速なデータのやりとりができ、在宅勤務なども可能となる。
【０００５】
したがって、今後さらに高速な数十メガビットクラスでのアクセスが可能で、なおかつ接続先を用途に応じて切り替えるといったニーズが高まると考えられる。このようなニーズを満たすキーとなる技術は次の二つである。
【０００６】
（１）イーサネット（Ｅｔｈｅｒｎｅｔ（登録商標）：ＩＥＥＥ ８０２．３に準拠するネットワーク）
イーサネット（図１にフレームフォーマットを示す）は、従来ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋｓ）において広く用いられている技術であり、１０Ｍｂｐｓから１０Ｇｂｐｓ（２００２年６月にＩＥＥＥ８０２．３ａｅとして標準化完了）までの幅広い帯域を提供することができる。図２に本発明に係る主なイーサネットサービス（イーサタイプ）をパケット種別ごとに示す。
【０００７】
また、イーサネットは、装置コストが安価でなおかつユーザ側装置のインタフェースとしても広く普及している。このため、イーサネットを用いれば、経済的にブロードバンドアクセスサービスを提供することが可能となる。
【０００８】
ＩＥＥＥ８０２．３委員会では、アクセス網の最後の１マイルにイーサネット技術を適用することを目的としたＩＥＥＥ８０２．３ａｈ ＥＦＭ（Ｅｔｈｅｒｎｅｔ ｉｎ ｔｈｅ Ｆｉｒｓｔ Ｍｉｌｅ）が現在仕様策定中である。
【０００９】
（２）ＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）
ＰＰＰ（ＲＦＣ１６６１規定）は、ユーザ認証およびレイヤ３アドレスの割当およびレイヤ３パケットのカプセル化転送を実現する方式である。ＰＰＰでは、最初に、データリンクの確立を行うＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ネゴシエーションが行われる。続いて、ユーザから送信されたユーザＩＤおよびパスワードを用いたユーザ認証（ＰＡＰ認証、ＣＨＡＰ認証等がある）が行われる。最後に、レイヤ３アドレスのネゴシエーションを行うＮＣＰ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、ＩＰの場合はＩＰＣＰ）において、アドレスプールからユーザにＩＰアドレスが割り当てられるとともに、対向アクセスサーバ（ＲＡＳ：Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ）のＩＰアドレスがユーザに通知される。このような手順を経て、実際のＩＰデータ通信が可能となる。
【００１０】
また、最近では、ユーザ認証でユーザ名およびｘＳＰ名を指定（「ユーザ名＠ｘＳＰ名」と指定）することにより、ユーザが接続先を任意に選択するサービス（「接続先選択サービス」と称する）が行われている。この接続先選択サービスでは、ＢＲＡＳ（Ｂｒｏａｄｂａｎｄ Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ）と呼ばれる装置が、ユーザとｘＳＰとの接続点で、接続先ごとにユーザパケットを振り分ける。これによって、ユーザの接続先が任意に選択される。
【００１１】
上述した両方の技術を合わせた方式としてＰＰＰｏＥ（ＰＰＰ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ，ＲＦＣ２５１６規定）がある。ＰＰＰｏＥは、ＡＤＳＬ接続やＦＴＴＨ接続で広く使用されている。ＰＰＰｏＥは、文字どおりイーサネット上でＰＰＰパケットを転送する方式であり、イーサネット上での任意の接続先への切替接続を実現することができる。図３は、ＰＰＰｏＥを使用したＢＲＡＳを介したユーザ側装置とｘＳＰ間の接続イメージを示す図である。
【００１２】
図４は、ＰＰＰｏＥによるＢＲＡＳを介したユーザ側装置とｘＳＰとの間の接続における通信方式のシーケンス例を示す図である。ＰＰＰｏＥは、ＰＰＰｏＥ Ｄｉｓｃｏｖｅｒｙ Ｓｔａｇｅと、ＰＰＰ Ｓｅｓｓｉｏｎ Ｓｔａｇｅとに大きく分けることができる。
【００１３】
ＰＰＰ Ｄｉｓｃｏｖｅｒｙ Ｓｔａｇｅでは、ブロードキャスト型の通信方式を使用し、或るイーサネット上で２地点（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ）のセッションを確立する相手が特定される。このステージでは、ユーザ側装置は、ＰＰＰｏＥ発呼のＰＡＤＩ（ＰＰＰｏＥ Ａｃｔｉｖｅ Ｄｉｓｃｏｖｅｒｙ Ｉｎｉｔｉａｔｉｏｎ、図５にフレームフォーマットを示す）をブロードキャストで送出する。この場合、ＢＲＡＳは、ＰＡＤＩに応答し、ＰＡＤＯ（ＰＰＰｏＥ Ａｃｔｉｖｅ Ｄｉｓｃｏｖｅｒｙ Ｏｆｆｅｒ）をユニキャストで（ＰＡＤＩで受けたフレームの送信元ＭＡＣアドレスを宛先ＭＡＣアドレスとして）ユーザ側装置に返す。ユーザ側装置は、ＰＡＤＯの送信元ＭＡＣアドレスからＢＲＡＳのＭＡＣアドレスを認識することができる。これによって、ユーザ側装置は、以降のＢＲＡＳに対する通信において、ＢＲＡＳのＭＡＣアドレスを宛先ＭＡＣアドレスとして設定し、ユニキャストでＰＡＤＲ（ＰＰＰｏＥ Ａｃｔｉｖｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）を送出する。ＢＲＡＳは、ＰＡＤＲを受信すると、ユーザ側装置とＢＲＡＳとの間でセッション毎にユニークなＩＤ（Ｓｅｓｓｉｏｎ−ＩＤ：以下「セッションＩＤ」とも表記）を設定し、ＰＡＤＳ（ＰＰＰｏＥ Ａｃｔｉｖｅ Ｄｉｓｃｏｖｅｒｙ Ｓｅｓｓｉｏｎ−Ｃｏｎｆｏｒｍａｔｉｏｎ）をユーザ側装置に返す。
【００１４】
ＰＰＰ Ｓｅｓｓｉｏｎ Ｓｔａｇｅでは、ユーザ側装置とＢＲＡＳとの間でユニキャスト通信が行われる。このときのユニキャスト通信では、確立されたセッションＩＤ値が設定されたデータの送受信が行われる。このステージでは、ＢＲＡＳは、ユーザ側装置からのデータに付加された送信元ＭＡＣアドレスおよびセッションＩＤからユーザセッションを識別し、上記したＰＰＰネゴシエーション（ＬＣＰネゴシエーション，ユーザ認証，ＮＣＰネゴシエーション）を行う。
【００１５】
このとき、ＢＲＡＳは、ユーザ認証において、ユーザが指定した「ユーザ名＠ｘＳＰ名」からユーザの接続先を抽出し、ＲＡＤＩＵＳ（ＲＦＣ２８６５）クライアントとして、該当接続先のＲＡＤＩＵＳサーバに認証情報を送信（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ）する。このときの実際の認証は認証用のデータベースを持つｘＳＰで行われる。その後、ＢＲＡＳは、ＲＡＤＩＵＳサーバからの認証成功を示すパケット（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）をもとにＩＰアドレスの割当（ＩＰＣＰ）のネゴシエーションを行うことができる。
【００１６】
ＩＰＣＰ完了後、ユーザ側装置は、接続先との間でＩＰデータ通信を行うことが可能となる。すると、ユーザ側装置からＰＰＰｏＥでカプセル化されたＩＰパケット（ＰＰＰｏＥパケット）がＢＲＡＳに送られてくる状態となる（図６にＰＰＰｏＥパケットのフレームフォーマットを示す）。この場合、ＢＲＡＳはＰＰＰを終端し、ＩＰパケットを該当接続先に転送する。
【００１７】
なお、接続先ネットワークへのデータ転送に際し、Ｌ２ＴＰ（Ｌａｙｅｒ ｔｗｏ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ：ＲＦＣ２６６１規定）等が用いられ、Ｌ３ＶＰＮ（ｌａｙｅｒ ｔｈｒｅｅ ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ）網においてＰＰＰフレームのままで転送される場合もある。以後、本発明では、ユーザ認証・接続先の識別、提供サービス、および接続先へのパケット転送を含む処理を“セッションコントロール”と称する。
【００１８】
その他、本発明に係る技術として、特許文献１に開示されたネットワーク間通信方法及びその装置に係る技術がある。
【００１９】
【特許文献１】
特開２００１−１６２５５号公報
【００２０】
【発明が解決しようとする課題】
上述したように、ＰＰＰｏＥはイーサネット上での切替接続を実現することができる。しかしながら、従来のＢＲＡＳを用いた集中型の処理では以下に示すような問題があった。
【００２１】
（１）ＢＲＡＳのボトルネック
図７に示すように、ユーザ側装置は、どのｘＳＰ（ｘＳＰ網）と接続する場合でも、ＢＲＡＳを経由しての接続となる。このため、ＢＲＡＳにセッションコントロール処理が集中してしまう（場合によっては数十万〜数百万セッションとなる）。
【００２２】
ここに、ＰＰＰのネゴシエーションは、互いに条件を要求（Ｃｏｎｆｉｇｕｒｅ−Ｒｅｑｕｅｓｔ）し合い、互いに承認（Ｃｏｎｆｉｇｕｒｅ−Ａｃｋ）し合うといった複雑な状態遷移を伴う。しかも、ユーザごとにネゴシエーションの条件が異なる。このため、ＰＰＰによるネゴシエーションは、ソフトウェア処理が前提となる。
【００２３】
また、パケット転送は、ＢＲＡＳにおけるセッションコントロールの一部として行われる（図８に示すように、ＢＲＡＳの内部では、ソフトウェアで保持される状態遷移（図９）に基づいてパケット転送の可否が決定される）。このため、ハードウェア処理／ソフトウェア処理の切り分けが困難である。
【００２４】
さらに、ＢＲＡＳは、ｘＳＰにパケット転送を行うため、レイヤ３の処理（ＩＰルーティング等）を行わなければならない。従って、ＢＲＡＳは、ｘＳＰごとのＩＰアドレス体系およびダイナミックルーティングをサポートする必要がある（「バーチャルルータ機能」と呼ばれる）。
【００２５】
以上の理由から、ネットワークプロセッサなどの進歩がめざましいとはいえ、ＢＲＡＳによる処理の高速化には限界がある。
【００２６】
（２）ｘＳＰ接続網とユーザ拠点間接続網のシームレスな統合が困難
近年、広域ＬＡＮサービスなどと呼ばれる、ユーザ（主に企業）がイーサネットインタフェースでリモートの拠点間をあたかも同一ＬＡＮセグメントのように接続できるユーザ拠点間接続サービスが注目を集めている。
【００２７】
図１０に示すように、ユーザ拠点間接続サービスでは、ユーザを収容する装置でユーザを接続（収容）するポートやユーザフレームのＩＥＥＥ８０２．１Ｑ ＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）−ｔａｇなどからＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）を識別する。この場合、Ｌ２ＳＷ（Ｅｔｈｅｒｎｅｔ ＳＷ）で網が構成され、ＶＰＮ識別のための拡張ＶＬＡＮ−ｔａｇがユーザに付与（ユーザＥｔｈｅｒｎｅｔフレームに挿入）され、網がＶＰＮごとのブロードキャストドメインに論理的に分離され、ＭＡＣブリッジ転送によってユーザフレームが転送される。
【００２８】
また、最近では、網をＭＰＬＳ（Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）で構成し、ＭＰＬＳ網でイーサネットフレームを転送するＥｏＭＰＬＳ（Ｅｔｈｅｒｎｅｔ ｏｖｅｒ ＭＰＬＳ）サービスも提供されている。図１１に示すように、ＥｏＭＰＬＳでは、ユーザ収容のポートやユーザフレームのＶＬＡＮ−ｔａｇからＶＰＮが識別され、ＭＰＬＳ網内を転送するためのＴｕｎｎｅｌ（トンネル）ラベルパスとＭＰＬＳ網の出入口のエッジ装置（ＬＥＲ：Ｌａｂｅｌ Ｅｄｇｅ Ｒｏｕｔｅｒ）でＶＰＮを識別するためのＶＣ（Ｖｉｒｔｕａｌ ｃｉｒｃｕｉｔ）ラベルパスにユーザフレームがマッピング（ユーザＥｔｈｅｒｎｅｔフレームがトンネルラベルおよびＶＣラベルでカプセル化）され、ユーザフレームがラベルスイッチ転送される。
【００２９】
一般に、ＭＰＬＳは２地点間（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ）のサービスである。但し、ＬＥＲにＭＡＣブリッジングの機能を持たせることによって、１対複数地点間（Ｐｏｉｎｔ−ｔｏ−Ｍｕｌｔｉｐｏｉｎｔ）のイーサネットフレーム転送サービスを提供することが可能である（「ＶＰＬＳ： Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ ＬＡＮ Ｓｅｒｖｉｃｅ」と呼ばれる）。
【００３０】
このように、ユーザ拠点間サービスでは、ユーザ収容装置でＶＰＮが一意に識別でき、さらに、網内では拡張ＶＬＡＮの２段スタック（Ｌ２ＳＷ網の場合）や、ＭＰＬＳラベルをさらにスタックしたりラベルパスをマージ（ＭＰＬＳ網の場合）したりしてトラフィックを多重化することも可能である。従って、経済的・効率的なネットワークの構築が可能である。
【００３１】
しかし、ｘＳＰ接続サービスにＢＲＡＳを用いた場合では、アクセス網内ではフレームがＢＲＡＳに至るまでユーザの接続先ｘＳＰを判別することができない。従って、図１２に示すように、例えばＬ２ＳＷで網が構成される場合において拡張ＶＬＡＮ等でトラフィックを多重化しても、ＢＲＡＳで接続先識別および提供しているサービス（最大速度や一戸建てや集合住宅型シェアドアクセスなどの接続形態等）を識別するためにアグリゲートトラフィックを分離してＢＲＡＳに渡す必要がある。ＭＰＬＳ網の場合も同様で、ユーザ側装置とｘＳＰとの間にＢＲＡＳが存在することが上記ユーザ拠点間接続網とｘＳＰ接続網の統合の妨げとなってしまう。
【００３２】
なお、イーサネット上でアクセスコントロールを実現する方式としては、ＩＥＥＥ８０２．１Ｘ（Ｐｏｒｔ ｂａｓｅｄ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）がある。ＩＥＥＥ８０２．１ＸはＥＡＰＯＬ（ＥＡＰ ｏｖｅｒ ＬＡＮｓ、図１３にフレームフォーマットを示す）とも呼ばれ、上記ＰＰＰの拡張認証方式であるＥＡＰ（Ｅｘｔｅｎｄｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のパケットフォーマットを流用し、イーサネットフレーム上で直接やりとりして、ＰＰＰ同様「ユーザ名＠組織名」から接続先セグメントを抽出して、認証が成功すると当該セグメント（ＶＬＡＮ）へのアクセスを許可するものである（図１４にＩＥＥＥ８０２．１Ｘによるシーケンス例、図１５にＩＥＥＥ８０２．１Ｘによる接続イメージを示す）。
【００３３】
しかし、ＩＥＥＥ８０２．１Ｘは、エッジＬ２ＳＷのポート単位でアクセスを許可するものであり、ポートあたり１ユーザしか認証できない。つまり集合住宅などで集線された環境など、エッジＬ２ＳＷのポートに複数ユーザが接続された環境では適用できない。またＩＥＥＥ８０２．１Ｘは主にイーサネットや無線ＬＡＮのセキュリティ（ポートにケーブルを繋げばだれでも簡単にアクセスできてしまうことや無線ＬＡＮのパケットを傍受することでなりすましが可能になってしまうことなど）に鑑みたものであって、例えばＩＰアドレス割当および管理の機構を備えていないことや、認証後の接続先セグメントは通常のＬＡＮと同じくフリーアクセスとなるため、セキュリティ等の観点からｘＳＰ選択接続としてそのまま適用することは難しい。
【００３４】
本発明は、以上のような問題を解決し、セッションコントロール処理が集中することにより生じるボトルネックを回避することができる通信装置を提供することを目的とする。
【００３５】
【課題を解決するための手段】
上記問題を解決するため、本発明は以下のような構成をとる。即ち、本発明は、ＰＰＰｏＥを用いてユーザが複数の接続先から任意の接続先選択を行う通信システムにおいて、ユーザにより選択された接続先宛のデータを中継するレイヤ２網のエッジに配置され、１以上のユーザ側装置を収容する通信装置であって、ユーザ側装置から受信するＰＰＰｏＥフレームがＰＰＰセッション確立用のフレームか上記接続先宛のデータを含むフレームかを判別するフレーム判別手段と、上記フレーム判別手段で判別されたセッション確立用のフレームに基づいて、ユーザ認証及び接続先識別を含むユーザ側装置とユーザにより選択された接続先との間の通信に係るＰＰＰセッションを確立するための処理を行うセッション管理手段と、上記フレーム判別手段で判別された上記接続先宛のデータを含むＰＰＰｏＥフレームから当該データを抽出するフレーム変換手段と、上記フレーム変換手段で抽出されたデータを前記レイヤ２網へ送出する転送処理手段とを含む。
【００３６】
好ましくは、本発明の通信装置は、上記各接続先の網のエッジ装置が接続先毎に用意された上記レイヤ２網の網終端装置にそれぞれ接続されており、上記フレーム変換手段は、上記接続先宛のデータに宛先レイヤ２アドレスとして設定されている自装置のレイヤ２アドレスを当該接続先のエッジ装置のレイヤ２アドレスに変換して上記転送処理手段に渡すように構成してもよい。
【００３７】
好ましくは、本発明における通信装置は、上記レイヤ２網が上記各接続先の網を収容するレイヤ３網にエッジ装置を介して接続され、このエッジ装置が上記レイヤ２網を通じて受信する上記接続先宛のデータに対して上記レイヤ２網の終端処理を行うとともに上記レイヤ３網を介して該当する接続先の網へ転送する処理を行うように構成されており、上記セッション管理手段は、ユーザ側装置との間におけるＰＰＰセッションの確立において、ユーザ側装置に転送されるセッション確立用フレームの送信元レイヤ２アドレスとして上記エッジ装置のレイヤ２アドレスを設定し、上記フレーム変換手段は、ＰＰＰセッションの確立後にユーザ側装置から受信する接続先宛のデータに宛先レイヤ２アドレスとして設定されている上記エッジ装置のレイヤ２アドレスを変更することなく当該データを上記転送処理手段に渡すように構成してもよい。
【００３８】
好ましくは、本発明における通信装置は、上記レイヤ２網が上記各接続先の網を収容するレイヤ３網に複数のエッジ装置を介して接続され、各エッジ装置が上記レイヤ２網を通じて受信する上記接続先宛のデータに対して上記レイヤ２網の終端処理を行うとともに上記レイヤ３網を介して該当する接続先の網へ転送する処理を行うように構成されており、上記セッション管理手段は、ユーザ側装置との間におけるＰＰＰセッションの確立において、ユーザ側装置に転送されるセッション確立用フレームの送信元レイヤ２アドレスとして、接続先に応じたエッジ装置のレイヤ２アドレスを設定し、上記フレーム変換手段は、ＰＰＰセッションの確立後にユーザ側装置から受信する接続先宛のデータに宛先レイヤ２アドレスとして設定されている上記エッジ装置のレイヤ２アドレスを変更することなく当該データを上記転送処理手段に渡すように構成してもよい。
【００３９】
好ましくは、本発明におけるレイヤ２網は、ＩＥＥＥ８０２．１Ｑ ＶＬＡＮに従って接続先毎に論理分割され、本発明における転送処理手段は、上記接続先宛のデータに対し、当該データの接続先に対応するＶＬＡＮ−ｔａｇを設定して上記レイヤ２網に送出するように構成してもよい。
【００４０】
このようにして、本発明によれば、ユーザ側装置を収容する通信装置において、ユーザ認証及び接続先識別を含むセッション管理を行うことにより、セッションコントロール処理が集中することにより生じるボトルネックを回避することができる。
【００４１】
【発明の実施の形態】
以下、図面を用いて本発明の実施形態について説明する。なお、本実施形態の説明は例示であり、本発明の構成は以下の説明に限定されない。
【００４２】
〈概要〉
本発明を実現するにあたってのポイントは次の（１）〜（４）である。
（１）従来ＢＲＡＳで行っていたセッションコントロールを分散処理する。
（２）上記（１）に加えて、標準化されたＰＰＰｏＥ（通信プロトコル）を用いてＩＰデータフレーム（ＩＰｏＰＰＰｏＥ）を送受信する（ただし、セッション識別後はＰＰＰｏＥデカプセル化する）。
【００４３】
上記（１）及び（２）については、ＢＲＡＳの機能をそのままユーザ収容装置に分散させる方法が考えられる。しかし、上述したように、ＢＲＡＳによる処理では、パケット転送がソフトウェア処理により行われる。このため、処理の高速化の問題が解決できない。さらに、ＢＲＡＳはレイヤ３に対する処理も行うので、ｘＳＰ毎のＩＰアドレス体系やダイナミックルーティングまでもが分散されることになる。従って、これらの管理運用が煩雑化することが考えられる。従って、次の（３）及び（４）もポイントとなる。
（３）ハード処理／ソフト処理の切り分けを明確にする。即ち、ＩＰデータフレームをハード処理化する。
（４）ＩＰデータフレームのレイヤ２処理を行う。
以上のポイント（１）〜（４）を踏まえ、本発明の実施形態を説明する。
【００４４】
《実施形態》
図１６は、本発明の実施形態に係る通信装置（ユーザ収容装置）及びこの通信装置を含むＬ２ＶＰＮネットワークシステムの概要を示す図である。図１６には、Ｌ２ＶＰＮ網１が示されている。本発明に係るユーザ収容装置２は、Ｌ２ＶＰＮ網のエッジに配置される。ユーザ収容装置２は、一戸建てや集合住宅等のユーザ拠点におけるユーザ側装置３を直接的に（例えば、レイヤ２におけるブロードキャストドメイン内で）収容することができる。
【００４５】
ユーザ収容装置２は、各ユーザ側装置３が、ユーザ側装置３で選択されたサービスプロバイダ（ｘＳＰ（ＩＳＰ、ＣＳＰ等））にアクセスするための制御（ユーザ任意の接続先選択サービスの制御）を行う。図１６には、ユーザが選択可能な複数のｘＳＰの例として、ｘＳＰ−Ａと、ｘＳＰ−Ｂとのそれぞれによって用意されたｘＳＰ網及びその入口に設置されたエッジ装置（エッジルータ）が図示されている。
【００４６】
各ユーザ側装置３と各ｘＳＰとの間では、ＰＰＰｏＥによるセッションを介して通信が行われる。このため、ユーザ収容装置２は、各ユーザ側装置３とｘＳＰ間の通信に係るＰＰＰｏＥのセッションコントロールを行う。
【００４７】
ユーザ収容装置２は、セッションコントロールの後、ｘＳＰ宛のＩＰデータフレームがＰＰＰｏＥでカプセル化されたＰＰＰｏＥフレームをユーザ側装置３から受信する。ユーザ収容装置２は、このＰＰＰｏＥフレームをデカプセル化してＩＰｏＥデータフレームに変換し、このＩＰｏＥデータフレームをＬ２ＶＰＮ網１の網構成に応じたフォーマット（Ｌ２ＶＰＮの既存の標準フォーマット）にマッピング（カプセル化）し、Ｌ２ＶＰＮ網１へ送出する。
【００４８】
そして、ＩＰｏＥデータフレームは、Ｌ２ＶＰＮ網１の網構成に依存する転送手順に従ってＬ２ＶＰＮ網１における所定の終端点までレイヤ２転送され、この終端点でＬ２ＶＰＮ網１の終端処理が行われ、続いてＩＰｏＥデータフレームのｘＳＰへの転送処理が行われる。
【００４９】
また、ユーザ収容装置２は、ユーザの任意の接続先選択接続サービスと、ユーザ拠点間接続サービスを実現するＬ２ＶＰＮ網とが統合された統合Ｌ２ＶＰＮ網に適用することができる。すなわち、図１６に示すような企業間（Ｃ社支店６とＣ社本店７間）を結ぶユーザ拠点間接続サービスを、ユーザ−ｘＳＰ間の接続先選択接続サービスに適用することができる。
【００５０】
ユーザ側装置３は、例えばパソコン（ＰＣ）等のユーザがｘＳＰからサービスの提供を受けるための操作端末（「ユーザ端末」とも表記：コンテンツの表示や再生を行うアプリケーションが搭載されていても良い）と、ユーザ−ｘＳＰ間の通信機能を司る（少なくともＰＰＰｏＥ通信をサポートする）通信機器（ＡＤＳＬモデム等）との組み合わせにより構成される。但し、この例では、ユーザ端末−ｘＳＰ間通信はＩＰベースで行われるので、ユーザ側装置３は、ＩＰｏＰＰＰｏＥをサポートしている。
【００５１】
〈ユーザ収容装置のシステム構成〉
次に、ユーザ収容装置２のシステム構成について図１７〜２０を用いて説明する。図１７は、ユーザ収容装置２のシステム構成を示す図である。図１８は、フレーム判別手段の説明図である。図１９は、セッション管理手段の説明図である。図２０は、フレーム変換手段の説明図である。
【００５２】
図１７において、ユーザ収容装置２は、ユーザ側装置３を収容（直収）可能な通信装置として構成される。ユーザ収容装置２は、ＰＰＰｏＥフレーム入力時にフレームを解析し、フレームタイプ（セッションネゴシエーションフレームかＩＰデータフレームか）を判別するフレーム判別手段２０と、ＰＰＰ状態遷移に基づいて認証・接続先識別を含むセッションネゴシエーションを行うセッション管理手段２１と、認証成功・接続先識別後にユーザ側装置より送出されたＰＰＰｏＥカプセル化されたＩＰデータフレームのデカプセル化を行うフレーム変換手段２２と、デカプセル化されたＩＰデータフレームを接続先毎の仮想閉域網（Ｌ２ＶＰＮ網）にマッピングしてレイヤ２転送を行う転送処理手段２３とを備える。また、図１７において、実線矢印は、ユーザ端末３からのフレームの流れを示し、破線矢印は、セッションネゴシエーションに基づく情報の流れを示す。
【００５３】
ユーザ収容装置２の構成要素のうち、セッション管理手段２１は、ソフトウェアで構成され、図９に示すような従来と同様の状態遷移テーブル（「ＰＰＰ状態遷移テーブル」とも表記）に基づくセッションネゴシエーション処理をソフトウェア処理で行う。一方、フレーム判別手段２０，フレーム変換手段２２，及び転送処理手段２３は、ハードウェアで構成される。以下、各構成要素について詳細に説明する。
【００５４】
≪フレーム判別手段≫
フレーム判別手段２０は、ユーザ側装置３からのＰＰＰｏＥフレームを受信する。フレーム判別手段２０は、入力されたＰＰＰｏＥフレームを解析し、フレームタイプを判別する。フレームタイプの判別によって、当該フレームがセッションネゴシエーションフレーム（「ネゴシエーションパケット」とも表記）であるか、ＩＰデータフレームであるかが判別される。
【００５５】
フレーム判別手段２０は、フレームがセッションネゴシエーションフレームである場合には、当該フレームをセッション管理手段２１に渡し、ＩＰデータフレームである場合には、当該フレームをフレーム変換手段に渡す。
【００５６】
図１８に示す例では、フレーム判定手段２０は、ユーザ側から受信したＰＰＰｏＥフレームの“ＥＴＨＥＲ＃ＴＹＰＥ”が“０ｘ８８６４（ＰＰＰｏＥ（Ｓｅｓｓｉｏｎ））”であり、且つ“ＣＯＤＥ”が“０ｘ００”であり、且つ“ＰＰＰ＃ＰＲＯＴＯＣＯＬ”値が“０ｘ００２１”である場合（図６参照）には、当該ＰＰＰｏＥフレームについて、ＩＰパケットがＰＰＰｏＥカプセル化されたフレーム（ＩＰｏＰＰＰｏＥ）、即ちＩＰデータフレームであると判別し、当該ＰＰＰｏＥフレームをフレーム変換手段２２に転送する。
【００５７】
これに対し、フレーム判定手段２０は、ユーザ側からのＰＰＰｏＥフレームがＩＰデータフレーム以外のフレームである場合には、当該フレームがセッションネゴシエーションフレームであると判断し、当該フレームをセッション管理手段２１に転送する。
【００５８】
≪セッション管理手段≫
セッション管理手段２１は、ＰＰＰ状態遷移テーブルに基づいて、ユーザ認証・接続先識別を含む従来のＢＲＡＳとほぼ同様のセッションネゴシエーションを行う。図１９に示す例では、セッション管理手段２１は、ネゴシエーションパケット（ＰＰＰｏＥ）を受信し（Ｓ１）、受信したネゴシエーションパケットに含まれた送信元ＭＡＣアドレスとセッションＩＤを用いて状態遷移テーブルを検索し（Ｓ２）、検索した状態遷移に従った処理を行いユーザに応答する（Ｓ３）、という一連のセッションネゴシエーションを行う。
【００５９】
Ｓ３において、認証及び接続先識別処理が行われる。セッション管理手段２１は、認証を行う場合には、ＲＡＤＩＵＳクライアントとして、接続先として識別したｘＳＰのＲＡＤＩＵＳサーバとの間で、ＲＡＤＩＵＳ認証通信を行う。ＲＡＤＩＵＳ認証通信については、Ｌ２ＶＰＮ網内にプロキシＲＡＤＩＵＳサーバを配置して、ｘＳＰとの通信を一元化することも可能である。
【００６０】
セッション管理手段２１は、セッションネゴシエーション（認証成功・接続先識別）後に、ＰＰＰ状態遷移テーブルを参照し、新しい状態をチェックする（Ｓ４）。この時、状態が“ＩＰアドレス割り当て完了（ＩＰＣＰ Ｏｐｅｎｅｄ）”である場合には、その時点で当該ユーザ側装置３のＭＡＣアドレス，ＰＰＰｏＥのセッションＩＤ，及び接続先のＶＰＮ−ＩＤ（ＶＰＮ識別子）をフレーム変換手段２２に登録通知として通知する（Ｓ５）。この登録通知は、認証成功時（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔ受信時）の時点で登録可能とする。
【００６１】
一方、Ｓ４において、状態が“接続終了”の場合には当該ユーザ側装置３のＭＡＣアドレス，ＰＰＰｏＥのセッションＩＤ，及び接続先ＶＰＮ−ＩＤを削除通知として通知する（Ｓ６）。この削除通知は、ユーザからの明示的な接続終了（ＬＣＰ Ｔｅｒｍｉｎａｔｅ Ｒｅｑｕｅｓｔ ｏｒ ＰＡＤＴ：図４参照）の受信時、或いは無通信時間タイマのタイムアウト時に接続終了とみなし通知されるように構成することも可能である。
【００６２】
≪フレーム変換手段≫
フレーム変換手段２２は、認証成功・接続先識別後にユーザ側装置３により送出されるＰＰＰｏＥカプセル化されたＩＰデータフレームのデカプセル化を行う。
【００６３】
図２０に示す例では、フレーム変換手段２２は、ＭＡＣアドレス，ＰＰＰｏＥセッションＩＤ，及び接続先ＶＰＮ−ＩＤからなるテーブル２２ａを有している。
【００６４】
フレーム変換手段２２は、フレーム判別手段２０から転送されたＰＰＰｏＥカプセル化されたＩＰデータフレーム（ＩＰｏＰＰＰｏＥ）を受け取ったときに、当該フレーム中の送信元ＭＡＣアドレス及びセッションＩＤに対応するエントリがテーブル２２ａにあれば、当該ＰＰＰｏＥフレームをＩＰｏＥデータフレームに変換（ＰＰＰｏＥフレームのデカプセル化）し、ＶＰＮ−ＩＤの情報（セッション管理手段２１から受け取っている）とともに転送処理手段２３に送る。これに対し、フレーム変換手段２２は、テーブル２２ａに該当エントリがなければ、未だ認証前であるものとして、当該ＰＰＰｏＥフレームを廃棄する。
【００６５】
一方、フレーム変換手段２２は、Ｌ２ＶＰＮ網１側から転送処理手段２３を経て送られてきたＩＰｏＥデータフレームを受け取った場合には、当該フレーム中の宛先ＭＡＣアドレスをキーとしてテーブル２２ａを検索し、該当エントリがヒットすれば、このエントリ中のセッションＩＤが設定されたＰＰＰヘッダで当該フレームに対するＰＰＰｏＥカプセル化を行い、ユーザ側装置３に送出する。
【００６６】
さらに、フレーム変換手段２２は、テーブル２２ａのエントリ管理を行う。即ち、フレーム変換手段２２は、セッション管理手段２１から登録通知を受け取った場合には、その登録通知の内容が記録されたエントリをテーブル２２ａ内に作成する。一方、フレーム変換手段２２は、セッション管理手段２１から削除通知を受け取った場合には、対応するエントリをテーブル２２ａから削除する。
【００６７】
≪転送処理手段≫
転送処理手段２３は、デカプセル化されたＩＰデータフレームを接続先ごとの仮想閉域網（Ｌ２ＶＰＮ網）にマッピングしてレイヤ２転送する（詳細については後述）。
【００６８】
以上のように、ユーザ収容装置２は、従来ＢＲＡＳで行われていたユーザ側装置と選択接続先のｘＳＰとの間のセッションコントロールを、自身が収容している１以上のユーザ側装置について行う。これによって、従来のように、ＢＲＡＳで集中的に行われていた多数のユーザからのセッションコントロールを、複数のユーザ収容装置２に分散することができる。
【００６９】
また、ユーザ収容装置２は、ｘＳＰへのＩＰデータフレームの転送処理を、Ｌ２ＶＰＮ網１へのレイヤ２転送により行う。従って、ユーザ収容装置２において、ｘＳＰ毎のＩＰアドレス体系を管理したり、ダイナミックルーティングを管理したりする必要がない（バーチャルルータとしての機能を要しない）。従って、ユーザ収容装置２におけるＬ３処理を回避することができる。これによって、ユーザ側装置３と接続先のｘＳＰとの通信に係るセッションコントロールはセッション管理手段２１によるソフトウェア処理で行い、ＩＰデータフレームの転送処理は、フレーム判別手段２０，フレーム変換手段２２，及び転送処理手段２３によるハードウェア処理で行う構成を採用することができる。さらに、ＰＰＰｏＥフレームの判別及びフレーム変換処理をハードウェアで行うことで、高速化を図ることができる。
【００７０】
〈ｘＳＰの接続形態〉
次に、ｘＳＰの接続形態について説明する。ユーザ収容装置２がＩＰデータフレームをレイヤ２転送するための処理は、ｘＳＰのＬ２ＶＰＮ網１に対する接続形態によって異なる。接続形態としては、以下の二通りが考えられる。
〈Ａ〉ｘＳＰがＬ２ＶＰＮ網の終端点に直接接続される場合
〈Ｂ〉ｘＳＰがＬ２ＶＰＮ網及びＬ３ＶＰＮ網（ＩＰ−ＶＰＮ網）を経由する場合図２１（Ａ）及び（Ｂ）は、上記した接続形態〈Ａ〉、即ちＬ２ＶＰＮ網１の終端点でｘＳＰに直接接続される場合の接続形態例を示す図である。接続形態〈Ａ〉は、例えば、比較的小さい単位（例えば、県単位など）でｘＳＰに直接接続されるケースに適用される。
【００７１】
この場合、ユーザ収容装置２がＩＰパケット（ＩＰｏＥフレーム）をレイヤ２転送する際の宛先ＭＡＣアドレスは、選択接続先に該当するｘＳＰのエッジ装置（エッジルータ：図２１（Ａ）ではエッジ装置９Ａ，９Ｂ，９Ｃを例示。以下エッジ装置を特に指定しない説明では「エッジ装置９」と表記）のＭＡＣアドレスとなる。エッジ装置９は、例えば、ｘＳＰ毎に用意される。
【００７２】
エッジ装置９は、Ｌ２ＶＰＮ網１に接続される。このとき、図２１（Ａ）に示すように、各エッジ装置９がｘＳＰ毎に用意されたＬ２ＶＰＮ網１の網終端装置（図２１（Ａ）では網終端装置１３Ａ，１３Ｂ，１３Ｃを例示。以下網終端装置を特に指定しない説明では「網終端装置１３」と表記）に接続されるように構成しても良い。或いは、図２１（Ｂ）に示すように、各エッジ装置９が、複数のエッジ装置９を収容し、各エッジ装置９に対するトラフィックを宛先アドレスに従って分配する集約型網終端装置１６に接続されるように構成しても良い。
【００７３】
上述したように、ＰＰＰｏＥでは、ユーザ側装置３は、ＰＰＰ Ｄｉｓｃｏｖｅｒｙ Ｓｔａｇｅにおいて、セッションの確立相手のレイヤ２アドレス（例えばＭＡＣアドレス）を認識する。本実施形態では、ユーザ側装置３のセッションの確立相手はユーザ収容装置２であり、しかもユーザ認証時までは接続先のｘＳＰ（のエッジ装置のレイヤ２アドレス）が未知である。
【００７４】
このため、ユーザ収容装置２のフレーム変換手段２２は、認証成功・接続先識別後にユーザ側装置３から送信されてくるＰＰＰｏＥカプセル化されたＩＰデータフレームに対し、デカプセル化に加え、その宛先レイヤ２アドレスを、接続先の識別により得られたｘＳＰのエッジ装置のレイヤ２アドレスに変換して転送処理手段２３に渡す。
【００７５】
図２２は、図２１に示す接続形態（接続形態〈Ａ〉）において適用されるユーザ収容装置２の構成例を示す図である。図２２に示す例では、フレーム変換手段２２は、ユーザ側装置３からのＩＰｏＰＰＰｏＥフレームからＰＰＰｏＥを取り外しＩＰｏＥデータフレームへとデカプセル化する。さらに、フレーム変換手段２２は、デカプセル化されたＩＰｏＥデータフレームの宛先ＭＡＣアドレスに設定されているユーザ収容装置２のＭＡＣアドレス“Ｐ”を、接続先のｘＳＰのエッジ装置９のＭＡＣアドレス“Ｃ”に変換する。このとき設定される接続先ｘＳＰのエッジ装置９のＭＡＣアドレスは、フレーム変換手段２２が管理するテーブル２２ｂ（図２０のテーブル２２ａに相当）に登録されている。
【００７６】
フレーム変換手段２２は、セッション管理手段２１から、ユーザ側装置３のＭＡＣアドレス，ＰＰＰｏＥセッションＩＤ，及びＶＰＮ−ＩＤに加えて当該エッジ装置９のＭＡＣアドレスを含む登録通知を受け取り、この登録通知の内容を含むエントリをテーブル２２ｂに登録するように構成されている。
【００７７】
この場合、セッション管理手段２１は、あらかじめ自身に登録されている各ｘＳＰのエッジ装置９のＭＡＣアドレスを、接続先識別の結果に応じて登録通知に含めてフレーム変換手段２２に与える構成を適用することができる。或いは、認証時のＲＡＤｌＵＳ通信においてｘＳＰ側から該当エッジ装置９のＭＡＣアドレスを含む認証成功メッセージ（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）を受け取り、このＭＡＣアドレスを含む登録通知をフレーム変換手段２２に与えるように構成することも可能である。
【００７８】
後者が採用される場合には、ユーザ収容装置２は、接続先のｘＳＰのエッジ装置９のＭＡＣアドレスを動的に取得することができる。従って、ユーザ収容装置２毎に各ｘＳＰのエッジ装置９のＭＡＣアドレスを予め登録する必要がない。また、ｘＳＰのエッジ装置９が故障等で交換された場合でもＭＡＣアドレスを登録変更する必要がない。
【００７９】
図２３は、上記した接続形態〈Ｂ〉、即ちユーザからのトラフィックがＬ２ＶＰＮ網１、さらにＬ３ＶＰＮ網１０（例えば、ＩＰ−ＶＰＮ網）を経由する場合の接続形態例を示す図である。当該接続形態〈Ｂ〉は、比較的大きな単位（全国的に集約する場合など）でｘＳＰに接続されるケースに適用される。図２４は、図２３に示す接続形態（接続形態〈Ｂ〉）において適用されるユーザ収容装置２の構成例を示す図である。
【００８０】
図２３において、Ｌ２ＶＰＮ網１Ａに収容されている各ユーザ収容装置２がＩＰｏＥデータフレームをレイヤ２転送する際の宛先ＭＡＣアドレスは、Ｌ３ＶＰＮ網１０の入口のエッジ装置１１のＭＡＣアドレスとなる。この場合では、宛先ＭＡＣアドレスは、ユーザがどのｘＳＰと接続する場合でも一つに決まる。このため、ユーザ収容装置２は、図２４に示すような次の構成を持つ。
【００８１】
セッション管理手段２１は、ユーザ側装置３からのＰＰＰｏＥ発呼（ＰＡＤＩ）に対し、応答ＰＰＰｏＥフレーム（ＰＡＤＯ）の送信元レイヤ２アドレスとしてＬ３ＶＰＮ網１０のエッジ装置１１のレイヤ２アドレスを設定する。
【００８２】
続いて、ユーザ側装置３からのセッションネゴシエーションフレーム（ＰＡＤＲ）に対し、フレーム判別手段２０は、そのフレームの宛先レイヤ２アドレスが自装置宛でなくても、セッション管理手段２１に転送する。セッション管理手段２１は、当該フレームに基づいてセッション管理（ユーザ認証、接続先識別、ＩＰＣＰ等）を行う。
【００８３】
認証・接続先識別後では、ユーザ側装置３からのＰＰＰｏＥカプセル化されたＩＰデータフレームは、フレーム変換手段２２において、デカプセル化され転送処理手段２３に渡される。このような構成下では、フレーム変換手段２２で宛先ＭＡＣアドレスの変換する処理は不要となる。
【００８４】
図２４に示す例では、ユーザ側装置３は、ＰＰＰｏＥ発呼（ＰＡＤＩ）の宛先ＭＡＣアドレスにブロードキャストアドレス“ｆｆ”（実際には、ｆｆ：ｆｆ：ｆｆ：ｆｆ：ｆｆ：ｆｆ）を設定し、ＰＰＰｏＥ発呼（ＰＡＤＩ）をブロードキャストする。セッション管理手段２１は、ＰＡＤＩを受け取ると、応答ＰＰＰｏＥフレーム（ＰＡＤＯ）の送信元レイヤ２アドレスとしてＬ３ＶＰＮ網１０のエッジ装置１１のレイヤ２アドレス“Ｌ”を設定する。
【００８５】
ユーザ側装置３は、ＰＡＤＯを受け取ることで、セッションの相手先がレイヤ２アドレス“Ｌ”の装置（エッジ装置１１：実際にはユーザ収容装置２）であると認識する。従って、ユーザ側装置３は、その後のセッションネゴシエーションフレームについては、宛先レイヤ２アドレスとして“Ｌ”を用いる。そして、ＩＰ通信が可能な状態となると、ユーザ側装置３は、宛先レイヤ２アドレスが“Ｌ”に設定されたＰＰＰｏＥカプセル化ＩＰデータフレームをユーザ収容装置２へ送信する。ユーザ収容装置２のフレーム変換手段２２は、当該ＰＰＰｏＥフレームに対し、ＰＰＰｏＥのデカプセル化を行うのみで（宛先アドレスの変換を行うことなく）、転送処理手段２３に転送する。
【００８６】
なお、上述したユーザ収容装置２の構成では、ユーザ側装置３からはＰＰＰｏＥセッションがＬ３ＶＰＮ網１０のエッジ装置１１との間で確立されているかのように見える。しかし、実際にはユーザ収容装置２がセッション管理を行っており、Ｌ３ＶＰＮ網１０のエッジ装置１１はセッションに介在しない。
【００８７】
また、図２３においてＬ２ＶＰＮ網１Ｂとして例示するように、負荷分散等の目的でＬ３ＶＰＮ網１０のエッジ装置１１が複数台存在する場合には、ユーザ収容装置２ではユーザごとに異なるＬ３ＶＰＮ網１０のエッジ装置１１のレイヤ２アドレス（例えばＭＡＣアドレス）を与え、各ユーザが当該レイヤ２アドレスを宛先レイヤ２アドレスとして使用するようにしても良い。また、このような接続形態〈Ｂ〉においても、フレーム変換手段２２でＩＰデータフレームの宛先レイヤ２アドレスをＬ３ＶＰＮ網のエッジ装置１１のレイヤ２アドレスに変換する方法（図２２に示した構成）を適用することができる。
【００８８】
なお、本発明の実施形態では、ユーザセッションはユーザ収容装置２で制御している。このため、Ｌ３ＶＰＮ網１０内でのユーザセッションの識別は不要である。Ｌ３ＶＰＮ１０としては、ＭＰＬＳ−ＶＰＮ網（ＲＦＣ２５４７ｂｉｓにより規定）等の適用を考えることができる。
【００８９】
〈Ｌ２ＶＰＮ網における転送処理〉
次に、Ｌ２ＶＰＮ網における実際の転送処理（転送処理手段２３の詳細）について説明する。本発明において、Ｌ２ＶＰＮ網は、次のような網構成を適用することができる。
［網構成１］Ｌ２ＳＷ（Ｅｔｈｅｒｎｅｔ ＳＷ）で構成され、ＩＥＥＥ８０２．１Ｑ ＶＬＡＮでｘＳＰ毎に論理分割された網。
［網構成２］ＭＰＬＳ網であって、ユーザ収容装置とｘＳＰとのＰＯＩ（相互接続点）に位置するｘＳＰ毎の網終端装置をＭＰＬＳラベルパスのエッジノード（ＬＥＲ）とする網。
［網構成３］ＭＰＬＳ網であって、ユーザ収容装置とｘＳＰとのＰＯＩに位置する集約型網終端装置（同一の終端装置に複数のｘＳＰが接続されている）をＬＥＲとする網。
以下、網構成１〜３について詳細に説明する。
【００９０】
［網構成１］
図２５は、網構成１において適用されるユーザ収容装置２の構成例を示す図であり、図２６は、網構成１、即ち、Ｌ２ＶＰＮ網がＬ２ＳＷ（Ｅｔｈｅｒｎｅｔ ＳＷ）で構成され、ＶＬＡＮ（ＩＥＥＥ８０２．１Ｑ）でｘＳＰごとに論理分割された網構成を示す。
【００９１】
図２６では、ユーザにより接続先として選択される複数のｘＳＰとして、ｘＳＰ−Ａ，ｘＳＰ−Ｂ，ｘＳＰ−Ｃが例示され、これらのｘＳＰのそれぞれに対してＶＬＡＮ−ＩＤ“１００”，“２００”，“３００”がそれぞれ割り当てられている。このようにして、Ｌ２ＶＰＮ網１が複数に論理分割されたＶＬＡＮ網１２として構成されている。
【００９２】
網構成１では、ユーザ収容装置２の転送処理手段２３は、いわゆるＶＬＡＮ対応のＬ２ＳＷに備わる機能を司る。但し、転送処理手段２３は、通常のＶＬＡＮ対応のＬ２ＳＷのようにユーザフレームからＶＬＡＮを静的（スタティック）に識別するのではなく、ユーザとのセッションネゴシエーションを通じ、認証成功・接続先識別後に、ユーザからのＩＰｏＥデータフレームを動的（ダイナミック）に接続先のｘＳＰに対応するＶＬＡＮにマッピングする。
【００９３】
具体的には、図２５に示すように、転送処理手段２３は、ＶＬＡＮごとに用意され、ＭＡＣアドレス、出力ポート番号、タグの付与／除去を保持するエントリが登録されるフォワーディングテーブル２３ａを持つ。
【００９４】
フォワーディングテーブル２３ａは、ＭＡＣアドレス学習により作成される。即ち、転送処理手段２３は、自身に入力されたフレームからその送信元ＭＡＣアドレスとそのフレームの入力（受信ポート）番号とがフォワーディングテーブル２３ａに登録されているか否かを判別し、登録されていなければ、当該ＭＡＣアドレス及びポート番号を登録する。このとき、入力フレームにおけるタグ（ＶＬＡＮ−ｔａｇ）の有無から、タグの付与／除去を登録することもできる。
【００９５】
転送処理手段２３は、フォワーディングテーブル２３ａを用いて次のような転送処理を行う。転送処理手段２３には、フレーム変換手段２２から、デカプセル化されたＩＰｏＥフレームとともに識別したｘＳＰを一意に示すＶＬＡＮ−ＩＤ（「ＶＰＮ−ＩＤ」と同義）が通知される。このＶＬＡＮ−ＩＤは、別途制御用の内部バスで通知されるか、あるいはＩＰｏＥデータフレームに装置内部処理用のタグが付与されて通知される。
【００９６】
フレーム変換手段２２は、セッション管理手段２１からの通知により、セッション毎にユーザ側装置３の送信元ＭＡＣアドレスとＶＬＡＮ−ＩＤとの対応関係を把握しており、ＩＰｏＥデータフレームの送信元ＭＡＣアドレスに対応するＶＬＡＮ−ＩＤをこのＩＰｏＥデータフレームとともに転送処理手段２３に与える。
【００９７】
このような構成により、転送処理手段２３は、ＩＰｏＥデータフレームの送信元ＭＡＣアドレスに対応するＶＬＡＮ−ＩＤ（ＶＬＡＮ）を認識することができる（ＭＡＣアドレスベースのＶＬＡＮ）。
【００９８】
そして、転送処理手段２３は、ＶＬＡＮ−ＩＤに対応するフォワーディングテーブル２３ａを参照し、ＩＰｏＥデータフレームの宛先ＭＡＣアドレスに対応する出力ポートを特定するとともに、当該ＩＰｏＥデータフレームに対応するＶＬＡＮ−ｔａｇを設定し、対応出力ポートへ向けて送出する。
【００９９】
このように、ＶＬＡＮ−ＩＤは、接続先ｘＳＰを一意に示すＶＬＡＮ−ｔａｇとしてＩＰｏＥフレームに挿入される。ＶＬＡＮ−ｔａｇを持つＩＰｏＥデータフレームは、ＭＡＣブリッジングによってＬ２ＶＰＮ網（ＶＬＡＮ網１２）内を転送される。
【０１００】
一方、転送処理手段２３は、Ｌ２ＶＰＮ網側から、ＶＬＡＮ−ｔａｇが付与された形式のＩＰｏＥデータフレームを受信する。この場合、転送処理手段２３は、ＶＬＡＮ−ｔａｇを除去してフレーム変換手段２２に送る。図２５に示す例では、接続先ｘＳＰを一意に示すＶＬＡＮ−ｔａｇとしてＶＬＡＮ−ＩＤ“１００”がＩＰｏＥデータフレームに対して挿入または除去されている。
【０１０１】
［網構成２］
図２７は、上記した網構成２が適用される場合におけるユーザ収容装置２の構成例を示す図であり、図２８は、網構成２、即ちＬ２ＶＰＮ網がＭＰＬＳ網１５で構成され、ユーザ収容装置２とｘＳＰとのＰＯＩ（相互接続点）１４に位置するｘＳＰごとの網終端装置１３をＭＰＬＳラベルパスのエッジノード（ＬＥＲ）とする場合の網構成例を示す図である。
【０１０２】
網構成２では、ユーザ収容装置２の転送処理手段２３は、ＭＰＬＳ対応のエッジノード（ＬＥＲ）に相当する。但し、転送処理手段２３は、通常のＬＥＲのように、ユーザフレームをＭＰＬＳラベルパスにスタティックにマッピングするのではなく、ユーザとのセッションネゴシエーションを通じた認証成功・接続先識別後に、接続先のｘＳＰに対応するＭＰＬＳラベルパスにダイナミックにマッピングする。
【０１０３】
具体的には、図２７に示すように、転送処理手段２３は、ＶＰＮ（ｘＳＰ）毎に用意されるＭＡＣフォワーディングテーブル２３ｂと、各ＶＰＮに対して共通に使用されるＭＰＬＳラベルテーブル２３ｃとを持つ。
【０１０４】
ＭＡＣフォワーディングテーブル２３ｂは、ＶＰＮ−ＩＤごとにＭＡＣアドレスと出力ポートの対応を保持する。ＭＰＬＳラベルテーブル２３ｃは、ＶＰＮ（ｘＳＰ）ごとに送信ＭＰＬＳラベル値（「送信ラベル」とも表記）と受信ＭＰＬＳラベル値（「受信ラベル」とも表記）との対応を保持する。
【０１０５】
送信ＭＰＬＳラベル値は、Ｌ２ＶＰＮ網側にフレームを出力する際において接続先に該当するｘＳＰに転送するためのＭＰＬＳラベルパス（ＬＳＰ）を一意に示す値を示し、受信ＭＰＬＳラベル値は、Ｌ２ＶＰＮ網側からフレームを受信した際において当該フレームの送信元のｘＳＰを一意に示す値を示す。
【０１０６】
転送処理手段２３は、フレーム変換手段２２からデカプセル化されたＩＰｏＥデータフレームを受信すると、フレーム変換手段２２から通知されるＶＰＮ−ＩＤから対象のＭＡＣフォワーディングテーブル２３ｂを特定し、ＩＰｏＥデータフレームの宛先ＭＡＣアドレスを用いて対応出力ポートを検索する。このとき、ＭＰＬＳのラベル付与が指定されていれば、ＶＰＮ−ＩＤに対応する送信ＭＰＬＳラベル値をＭＰＬＳラベルテーブル２３ｃから取り出して付与（Ｐｕｓｈ）し、ラベルスイッチ転送する。なお、対応ＭＡＣフォワーディングテーブル２３ｂに該当するエントリがなければ、転送処理手段２３は、網構成１（図２５）と同様のＭＡＣアドレス学習を行う。
【０１０７】
Ｌ２ＶＰＮ網（ＭＰＬＳ網１５）内では、ＩＰｏＥデータフレームは、予め設定されたＭＰＬＳラベルパスにしたがって通過するノード（ＬＳＲ：Ｌａｂｅｌ Ｓｗｉｔｃｉｎｇ Ｎｏｄｅ）でラベルが置換（Ｓｗａｐ）されてラベルスイッチ転送され、ｘＳＰごとに用意された網終端装置１３（図２８には網終端装置１３Ａ，１３Ｂ，１３Ｃを例示）まで転送される。その後、網終端装置１３において、ＩＰｏＥデータフレームからラベルが除去され、対応ｘＳＰのエッジ装置９（図２８にはエッジ装置９Ａ，９Ｂ，９Ｃを例示）に転送される。
【０１０８】
図２７及び２８に示す構成例は、網管理者がＮＭＳ（Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）等を通じて、各ユーザ側装置３と全てのｘＳＰごとの網終端装置１３との間でＭＰＬＳラベルパスを予め設定している場合を想定している。この場合では、接続ユーザの存在しないｘＳＰへのＭＰＬＳラベルパスも保持しておく必要がある。
【０１０９】
上記に鑑み、図２９に示すように、ユーザ収容装置２がラベルパスシグナリング手段２４をさらに備えるように構成することができる。ラベルパスシグナリング手段２４は、ユーザの接続先ｘＳＰが識別された後において、ユーザ収容装置２と当該ｘＳＰへの網終端装置１３との間でＭＰＬＳラベルパスが設定されていない場合には、当該ユーザの接続先ｘＳＰの識別をトリガとして所望のＭＰＬＳラベルパスを設定するためのシグナリングを行う。
【０１１０】
ＭＰＬＳでは、ラベルシグナリングプロトコルとして、ＬＤＰ（ＲＦＣ３０３６），ＣＲ−ＬＤＰ（ＲＦＣ３２１２），ＲＳＶＰ−ＴＥ（ＲＦＣ３２０９）等が規定されている。ラベルパスシグナリング手段２４には、これらのラベルシグナリングプロトコルのいずれをも適用することができる。但し、ＭＰＬＳにおけるラベルパスは片方向性（Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ）である。従って、ユーザ収容装置２は、網終端装置１３ヘラベルを配布し、且つ網終端装置１３からラベルの配布を受ける必要がある。
【０１１１】
ユーザ収容装置２から網終端装置１３へ配布されるラベルは、ＭＰＬＳラベルテーブル２３ｃ（図２７）に登録される受信ラベルに相当する。受信ラベルは、ユーザ収容装置２において網終端装置１３とユーザ収容装置２間との下り方向（網終端装置１３→ユーザ収容装置２）のＭＰＬＳラベルパスを識別するためのラベルである。網終端装置１３から配布を受けるラベルは、ＭＰＬＳラベルテーブル２３ｃに登録される送信ラベルに相当する。送信ラベルは、ユーザ収容装置２において上り方向のＭＰＬＳラベルパスを識別（上り方向のフレームに付与）するラベルである。
【０１１２】
図２９に示すように、セッション管理手段２１は、ユーザの接続先のｘＳＰを識別したときに、当該ｘＳＰに対する接続者がいるか否か（当該ｘＳＰに対応する網終端装置１３との間でラベルパスが設定されているか否か）を判定し、ＭＰＬＳラベルパスが設定されていないことが分かると、ラベルパスシグナリング手段２４に対し、ラベルパスを設定するためのシグナリングを行うことを通知する（図２９の▲１▼）。
【０１１３】
ラベルパスシグナリング手段２４は、まず接続先のｘＳＰに対応するＶＰＮ−ＩＤに対応する送信ラベルを該当する網終端装置１３に配布し（「ＤＵ， Ｄｏｗｎｓｔｒｅａｍ Ｕｎｓｏｌｉｃｉｔｅｄモード」と呼ぶ：図２９の▲２▼）、かつ当該網終端装置１３にラベル配布を要求して受信ラベルの配布を受ける（「ＤｏＤ，Ｄｏｗｎｓｔｒｅａｍ ｏｎ Ｄｅｍａｎｄ」モードと呼ぶ：図２９の▲３▼及び▲４▼）。そして、ラベルパスシグナリング手段２４は、送信ラベルと受信ラベルの情報の設定を転送処理手段２３へ通知する（図２９の▲５▼）。転送処理手段２３は、送信ラベルと受信ラベルとの対応をＶＰＮ−ＩＤに応じたＭＰＬＳラベルテーブル２３ｃに設定する。
【０１１４】
これにより、転送処理手段２３は、セッション管理手段２１によるユーザの接続先ｘＳＰの識別をトリガとして、ユーザ収容装置２−網終端装置１３間にＰＰＰｏＥセッションに応じた双方向のＭＰＬＳラベルパスを設定することができる。
【０１１５】
なお、網終端装置１３がユーザ収容装置２からのＤＵモードでのラベル配布をトリガとして、同じくＤＵモードでユーザ収容装置２にラベルを配布するように構成され、ラベルパスシグナリング手段２４が、このＤＵモードにより配布される受信ラベルを受け取るようにしても良い。この場合には、ラベルパスシグナリング手段２４は、ＤｏＤモードによるラベル要求（図２９の▲３▼）を行わなくて済む。
【０１１６】
また、ラベルパスシグナリング手段２４は、或るラベルパスについて接続者がいなくなったことを示す通知をセッション管理手段２１から受け取るように構成されており、この通知を受け取った場合には、当該ラベルパスを削除するためのシグナリングを行う。このとき、転送処理手段２３に対し、ラベルパスの削除が通知され、転送処理手段２３が該当ラベルパスに係るエントリをＭＰＬＳラベルテーブル２３ｃから削除するように構成することもできる。
【０１１７】
以上のような構成を適用すれば、全てのｘＳＰのそれぞれについて、ユーザ収容装置２と各ｘＳＰに対応する網終端装置１３との間に予めＭＰＬＳラベルパスを設定しておく必要がなくなる。即ち、シグナリングに必要なラベルパスのみを保持しておくことができる。
【０１１８】
［網構成３］
図３０は、上記した網構成３に適用されるユーザ収容装置２の構成例を示す図であり、図３１は、網構成３、すなわちＬ２ＶＰＮ網がＭＰＬＳ網１５であって、ユーザ収容装置２とｘＳＰとのＰＯＩ（相互接続点）１４に位置する集約型網終端装置１６（同一終端装置から複数ｘＳＰに接続されている）をＬＥＲとする網構成例を示す図である。集約型網終端装置１６は、複数のｘＳＰのエッジ装置９に接続される。
【０１１９】
網構成３では、図３１に示すような集約型網終端装置１６が用いられる。この場合、ＭＰＬＳラベル一段では、集約型網終端装置１６において、各ユーザからのＩＰｏＥデータフレームを、ユーザが選択した接続先情報に基づいて、複数のｘＳＰ（エッジ装置９）に振り分ける処理を行うことができない。
【０１２０】
このため、各ユーザ収容装置２と集約型網終端装置１６間でＩＰｏＥデータフレームをＭＰＬＳ網１５を介して転送するためのＭＰＬＳラベルパス（Ｔｕｎｎｅｌ（トンネル）ラベルパス）および接続先ｘＳＰを一意に示すＭＰＬＳラベルパス（ＶＣラベルパス）をあらかじめ設定する必要がある。
【０１２１】
各ユーザ収容装置２および集約型網終端装置１６は、それぞれＶＣラベル値からｘＳＰを識別する。このため、同一のユーザ収容装置２から集約型網終端装置１６へのトンネルラベルパスは接続先ｘＳＰが異なっていても同一のトンネルラベルパスにマージすることができる。即ち、接続先ｘＳＰが異なっていても同一のトンネルラベルパスを用いてＩＰｏＥデータフレームを転送することができる。
【０１２２】
その他、ＭＰＬＳ網１５内において、網終端装置１６のひとつ手前の中継装置（ＬＳＲ）でラベル（Ｔｕｎｎｅｌ）を除去（Ｐｏｐ）して網終端装置１６に転送することもできる（「ＰＨＰ： Ｐｅｎｕｌｔｉｍａｔｅ Ｈｏｐ Ｐｏｐｐｉｎｇ」と呼ぶ）。
【０１２３】
なお、ユーザ収容装置２とｘＳＰとのＰＯＩに位置するｘＳＰ毎の網終端装置をＭＰＬＳラベルパスのエッジノード（ＬＥＲ）とする網（上記網構成２）においても、トンネル及びＶＣラベルパスの二段ラベルパス構成を用いることができる。
【０１２４】
上述したように、網構成２や３でＭＰＬＳラベルを二段で用いる場合も、ユーザの接続先ｘＳＰ識別をトリガとしてラベルパスシグナリング手段２４がトンネル及びＶＣラベルパスを動的に設定する構成とすることができる。このような構成例を図３２に示す。
【０１２５】
但し、網構成３（集約型網終端装置１６が用いられる場合）では、ユーザがどのｘＳＰに接続（アクセス）する場合でも、これらの間を流れるＩＰｏＥデータフレームは集約型網終端装置１６を経由する。このため、ユーザ収容装置２と集約型網終端装置１６との間でトンネルラベルパスが常に設定されているように構成し、ＶＣラベルパスのみが対応するｘＳＰに対する接続者の有無に応じて設定／削除されるように構成しても良い。
【０１２６】
〈転送処理手段の具体的構成〉
上述したように、本発明に係るＬ２ＶＰＮ網の構成としては、ＶＬＡＮ網あるいはＭＰＬＳ網を適用することができる。この場合、ユーザ収容装置２における転送処理手段２３は、認証成功・接続先識別後にＩＰｏＥデータフレームを接続先のｘＳＰごとに用意されたＶＰＮに動的にマッピングする点を除けば、通常のＶＬＡＮ対応のＬ２ＳＷあるいはＭＰＬＳ対応のＬＥＲに相当する機能を持つ。
【０１２７】
従って、図３３に示すように、１以上のＭＰＬＳインタフェースカード３１，１以上のイーサネット（Ｅｔｈｅｒｎｅｔ）インタフェースカード３２，切替スイッチ３３を含む転送処理手段２３を備えたシャーシ型（多彩な機能を実現するインタフェースカードを追加挿入可能な）通信装置３０に対し、フレーム判別手段２０，セッション管理手段２１及びフレーム変換手段２２を持つ通信モジュール３４を追加することで、ユーザ収容装置２を構成することが可能である。
【０１２８】
なお、図３３に示すような構成を持つユーザ収容装置２が網構成２又は３に適用される場合には、通信モジュール３４がラベルパスシグナリング手段２４を更に含むように構成されても良く、ラベルパスシグナリング手段２４を含む通信モジュールが図３３に示す構成に更に追加されるように構成されていても良い。
【０１２９】
〈Ｌ２ＶＰＮネットワークの統合〉
また、ユーザ収容装置２では、セッション管理手段２１が接続先ｘＳＰを識別するとともに、加えて提供サービス形態（最大速度等の品質、或いは一戸建てや集合住宅型シェアドアクセスなど）も同様に識別し、複数のユーザ間において接続先ｘＳＰが同じであっても、提供サービス形態（例えばフレーム転送の最大速度）が異なる場合には、相互に異なるＶＰＮ−ＩＤを割り当て、ＩＰｏＥデータフレームがユーザ毎に異なるＶＰＮを介してｘＳＰ−ユーザ間を転送されるように構成することができる。
【０１３０】
この場合、ＶＰＮ−ＩＤは、提供サービス形態毎に用意される。従って、フレーム変換手段２２におけるテーブル（テーブル２２ａ，２２ｂ），及び転送処理手段２３におけるフォワーディングテーブル（テーブル２３ａ，２３ｂ）は、提供サービス形態毎に用意される。
【０１３１】
図３４には、ｘＳＰ−Ａの提供サービス形態として最大速度１００Ｍｂｐｓサービス及びシェアドサービスとが用意されている場合において、これらのサービス毎に用意されたＶＰＮを通ってユーザ−ｘＳＰＡ間をＩＰｏＥデータフレームが転送される例が示されている。
【０１３２】
上記のような接続先及び提供サービス形態毎に異なるＶＰＮが使用される構成となれば、Ｌ２ＶＰＮ網内にＢＲＡＳを設けることが不要となる。従って、ＢＲＡＳで接続先及びサービスを識別するためにアグリゲートトラフィックを分離する網構成も不要となる。
【０１３３】
このような状況下では、ｘＳＰ選択接続サービスと、ＶＰＮは固定ではあるが、ユーザごとに保証帯域など提供サービスの異なるユーザ拠点間接続サービスとの混在が可能となる統合Ｌ２ＶＰＮネットワークを実現することができる。
【０１３４】
《実施例１》
次に、本発明の実施例１について図３５，３６を用いて説明する。実施例１は、複数のｘＳＰのエッジ装置９（９Ａ，９Ｂ，９Ｃ）が、ｘＳＰ毎に用意されたＬ２ＶＰＮ網（ｘＳＰ毎に用意されたＶＬＡＮ網で論理分割されている）の終端点（網終端装置１３（１３Ａ，１３Ｂ，１３Ｃ））に直接接続されている場合の網構成が示されている。
【０１３５】
図３５において、ユーザ側装置３は、任意のｘＳＰ（例えば、ｘＳＰ−Ａ）を選択して当該ｘＳＰに対する通信を開始する場合には、最初に、ＰＡＤＩをブロードキャストする（Ｓ１１）。
【０１３６】
ユーザ収容装置２は、ＰＡＤＩを受信すると、フレーム判別手段２０においてフレームの判別処理を行う。フレーム判別手段２０は、フレーム判別の結果、ＰＡＤＩをセッションネゴシエーションフレームであると判別し、セッション管理手段２１に転送する。
【０１３７】
セッション管理手段２１では、ユーザ側装置３のＰＡＤＩに対して、ＰＡＤＯを返す（Ｓ１２）。この時、ＰＡＤＯの送信元ＭＡＣアドレスには、ユーザ収容装置２のＭＡＣアドレスが設定される。
【０１３８】
ユーザ側装置３はＰＡＤＯを受信することにより、２地点間（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ）でセッションを確立する装置（ユーザ収容装置２）のＭＡＣアドレスを知る。ユーザ側装置３は、以降、このＭＡＣアドレスが宛先ＭＡＣアドレスに設定されたＰＰＰｏＥフレームをユニキャストする。
【０１３９】
続いて、ユーザ側装置３からＰＡＤＲがユーザ収容装置２に送信され（Ｓ１３）、ユーザ収容装置２では、セッション管理手段２１がＰＡＤＲ（Ｓ１３）に基づいてＳｅｓｓｉｏｎ−ＩＤ（セッションＩＤ）を確立し、ＰＡＤＳを応答する（Ｓ１４）。そして、当該ＰＰＰｏＥセッションに対するデータリンク（ＬＣＰ）が確立される（Ｓ１５）。
【０１４０】
データリンクが確立されると、ユーザ認証のための要求（ＣＨＡＰ Ｃｈａｌｌｅｎｇｅ）がユーザ収容装置２からユーザ側装置３へ送信される（Ｓ１６）。ＣＨＡＰ要求に対し、ユーザ側装置３は、「ユーザ名＠ｘＳＰ名」で接続先ｘＳＰが指定されたＣＨＡＰ応答をユーザ収容装置２に返すことができる（Ｓ１７）。
【０１４１】
ユーザ収容装置２では、セッション管理手段２１がＣＨＡＰ応答を受け付けると、ＲＡＤＩＵＳ認証を行うための認証要求（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ）を、接続先のｘＳＰの網内に存するＲＡＤＩＵＳサーバに対して発呼する（Ｓ１８）。これにより、当該ｘＳＰのＲＡＤＩＵＳサーバにより、ユーザのＲＡＤＩＵＳ認証が行われる。
【０１４２】
この時、認証要求が一旦Ｌ２ＶＰＮ網１内のプロキシＲＡＤＩＵＳサーバに転送され、そこからｘＳＰ網内のＲＡＤＩＵＳサーバに転送されるようにしてもよい。これにより、ユーザ収容装置２と各ｘＳＰのＲＡＤＩＵＳサーバとの間における通信を一元化することができ管理運用が容易となる。
【０１４３】
ＲＡＤＩＵＳサーバは、ユーザ認証が成功した場合には、認証成功を示す認証応答（ＲＡＤＩＵＳ Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）をユーザ収容装置２へ返す（Ｓ１９）。成功を示す認証応答は、ユーザに対して割り当てられるＩＰアドレスや、当該ｘＳＰのエッジ装置のＭＡＣアドレス等を含むことができる。このようにしてユーザ側装置３とユーザ収容装置２との間でＰＰＰｏＥセッションが確立される。
【０１４４】
ユーザ収容装置２は、認証応答に含まれたＩＰアドレス値をもとにＩＰＣＰを行ってユーザにＩＰアドレスを割り当てる（Ｓ２０）。
【０１４５】
また、ユーザ収容装置２において、セッション管理手段２１は、認証成功・接続先識別に伴い、フレーム変換手段２２に対し、当該ユーザ側装置３のＭＡＣアドレス，ＰＰＰｏＥ Ｓｅｓｓｉｏｎ−ＩＤ，接続先のｘＳＰのエッジ装置９のＭＡＣアドレス，及びＬ２ＶＰＮ網１内で接続先のｘＳＰを一意に示すＶＰＮ−ＩＤを含む登録通知を与える。フレーム変換手段２２は、セッション管理手段２１からの通知内容をテーブル２２ｂ（図２２）に登録する。
【０１４６】
ユーザ側装置３はＩＰアドレスの割り当てを受けた後、ＰＰＰｏＥカプセル化したＩＰデータフレーム（ＩＰｏＰＰＰｏＥ）をユーザ収容装置２に送出する（Ｓ２１）。
【０１４７】
ユーザ収容装置２において、フレーム判別手段２０は、判別の結果、受信フレームがＩＰデータフレームであると判別し、フレーム変換手段２２に転送する。フレーム変換手段２２は、受信フレームの送信元ＭＡＣアドレスのエントリがテーブル２２ｂに存在する場合には、ＰＰＰｏＥデカプセル化を行ってＩＰｏＥデータフレームに変換する。さらに、フレーム変換手段２２は、ＩＰデータフレームの宛先ＭＡＣアドレスを当該ｘＳＰのエッジ装置９のＭＡＣアドレスに変換し、転送処理手段２３に対応するＶＰＮ−ＩＤ（ＶＬＡＮ−ＩＤ）情報とともに転送する。
【０１４８】
なお、フレーム変換手段２２は、受信フレームの送信元ＭＡＣアドレスのエントリがテーブル２２ｂに存在しない場合には、未認証とみなしてフレームを廃棄する。
【０１４９】
実施例１における転送処理手段２３は、ＶＬＡＮ対応のＬ２ＳＷに相当する。そのため、ユーザの最初のＩＰデータ通信の場合は、当該ＶＬＡＮ−ＩＤのフォワーディングテーブル（ＭＡＣブリッジングテーブル）２３ａ（図２５）に対応エントリが存在しないのでアドレス学習する。即ち、送信元ＭＡＣアドレスとユーザ側装置３が接続されているポートの番号をフォワーディングテーブル２３ａに登録する。
【０１５０】
転送処理手段２３は、受信フレームの宛先ＭＡＣアドレスからフォワーディングテーブル２３ａ内の出力ポートを検索し、対応するＶＬＡＮ−ｔａｇ（ＶＬＡＮ−ＩＤ“１００”）を付与してＬ２ＶＰＮ網（ＶＬＡＮ網）１内に送出する。
【０１５１】
図３６に示す例では、Ｌ２ＶＰＮ網１内はＶＰＮごとに論理分割されている（ＶＬＡＮ−ＩＤ“１００”，“２００”，“３００”で３分割）。このため、ＩＰｏＥデータフレームは、ＭＡＣブリッジング転送によって接続先ｘＳＰ（ｘＳＰ−Ａ）との境界（ＰＯＩ）に位置する網終端装置１３Ａまで転送される（Ｓ２２）。そして、網終端装置１３においてＶＬＡＮ−ｔａｇを除去してｘＳＰ−Ａのエッジ装置９Ａに転送される（Ｓ２３）。
【０１５２】
ｘＳＰ（ｘＳＰ−Ａ）からユーザ側装置３に対して送信されるデータ（ＩＰｏＥデータフレーム）は、Ｓ２１からＳ２３に示す処理と反対の処理が実行される。まず、ｘＳＰ−Ａのエッジ装置９Ａから網終端装置１３ＡまでＩＰデータ（ＩＰｏＥデータフレーム）が転送される（Ｓ２４）。網終端装置１３Ａは、ＩＰデータにＶＬＡＮ−ｔａｇ（ＶＬＡＮ−ＩＤ“１００”）を付与して送出する。当該ＩＰデータは、Ｌ２ＶＰＮ網１内をＭＡＣブリッジング転送される（Ｓ２５）。
【０１５３】
ユーザ収容装置２では、ＭＡＣブリッジング転送されたＩＰデータを受け取る。ユーザ収容装置２の転送処理手段２３は、ＩＰデータのＶＬＡＮ−ｔａｇを除去して、フレーム変換手段２２へ転送する。フレーム変換手段２２は、ＩＰデータの送信元ＭＡＣアドレスを自装置のＭＡＣアドレスに変換し、ＰＰＰｏＥカプセル化してユーザ側装置３に送出する（Ｓ２６）。
【０１５４】
実施例１によれば、ユーザと選択接続先のｘＳＰとの間を中継するＬ２ＶＰＮ網１のエッジにおいて１以上のユーザを収容するユーザ収容装置２が設置され、ユーザ収容装置２がユーザが選択したｘＳＰへアクセスするためのＰＰＰセッションをセッションコントロールを、標準化ベースの通信プロトコル（ＰＰＰｏＥ）を用いて行う。このため、多数のユーザに対するセッションコントロールが複数のユーザ収容装置２に分散される。従って、ＢＲＡＳを用いた場合のようなボトルネックの発生を回避することができる。
【０１５５】
なお、実施例１では、ＶＬＡＮ−ＩＤがｘＳＰを一意に示す場合について説明した。これに代えて、或るｘＳＰがサービスを最大速度１０Ｍｂｐｓと１００Ｍｂｐｓとの二種類で提供可能な場合（提供サービス形態が複数の場合）や、ユーザが集合住宅に存する場合等のシェアド型などのサービスに応じて、同一のｘＳＰに対する接続であっても異なるＶＬＡＮ−ＩＤが割り当てられ、Ｌ２ＶＰＮ網内でＶＬＡＮに応じた帯域制御が行われるようにすることも可能である。
【０１５６】
《実施例２》
次に、本発明の実施例２を図３７及び３８を用いて説明する。 実施例２は、ユーザ−ｘＳＰ間のトラフィックがＬ２ＶＰＮ網（ｘＳＰ毎のＭＰＬＳラベルパスが用意されるＥｏＭＰＬＳ網で構成されている）、さらにＬ３ＶＰＮ網１０（例えば、ＩＰ−ＶＰＮ網）を経由する場合の接続形態例を示す。
【０１５７】
図３７及び３８に示す例では、Ｌ２ＶＰＮ網がＥｏＭＰＬＳ網であって、ユーザ収容装置２および接続先ネットワークとのＰＯＩ（相互接続点）に位置する集約型網終端装置がＭＰＬＳラベルパスのエッジノード（Ｌ３ＶＰＮ網のエッジ装置）１１として構成され、さらに、各ｘＳＰ（ｘＳＰ−Ａ，ｘＳＰ−Ｂ，ｘＳＰ−３）のエッジ装置９Ａ，９Ｂ，９ＣがＬ３ＶＰＮ網１０に接続されている。
【０１５８】
この場合、各ユーザ収容装置２によるレイヤ２転送の宛先に該当する装置がエッジ装置１１となる。従って、各ユーザがｘＳＰを選択接続する場合でも、各ユーザからのＩＰｏＥデータフレームのＬ２ＶＰＮ網１における宛先は固定となる。このため、ユーザ収容装置２において、ＩＰデータの宛先ＭＡＣアドレスの変換は不要となる。
【０１５９】
ユーザ収容装置２のセッション管理手段２１は、ユーザ側装置３からのＰＰＰｏＥ発呼（ＰＡＤＩ）に対し、応答ＰＰＰｏＥフレーム（ＰＡＤＯ）の送信元レイヤ２アドレス（送信元ＭＡＣアドレス）としてエッジ装置１１のレイヤ２アドレス（ＭＡＣアドレス）を設定する（Ｓ３１，Ｓ３２）。
【０１６０】
その後、実施例１におけるＳ１３〜Ｓ１９と同様の手順が行われ、ＰＰＰセッションが確立され、ユーザと選択接続先のｘＳＰとの間でＩＰ通信が可能な状態となる（Ｓ３３〜Ｓ３９）。なお、ＰＡＤＲ以降のユーザからのセッションネゴシエーションフレームの宛先アドレスは、エッジ装置１１のＭＡＣアドレスであるが、ユーザ収容装置２のフレーム判別手段２０は、当該セッションネゴシエーションフレームをセッション管理手段２１に与える。
【０１６１】
認証・接続先識別後（ＰＰＰセッション確立後）にユーザ側装置３からＰＰＰｏＥカプセル化されたＩＰデータフレームが送出されると、フレーム変換手段２２は、ＰＰＰｏＥデカプセル化を行い、得られたＩＰｏＥデータフレームを対応ＶＰＮ−ＩＤとともに転送処理手段２３に送る（Ｓ４１）。この時、ＩＰデータの宛先ＭＡＣアドレスの変換は行われない。
【０１６２】
転送処理手段２３では、フォワーディングテーブル及びＭＰＬＳラベルテーブルを参照し、当該ＶＰＮ−ＩＤに対応したＭＰＬＳラベル（ＶＣラベルおよびＴｕｎｎｅｌラベル）をＩＰｏＥデータフレームに付与してＬ２ＶＰＮ網１内に転送する。Ｌ２ＶＰＮ網１内では、Ｔｕｎｎｅｌラベルのみを参照してラベルスイッチが行われる（Ｓ４２〜Ｓ４４，Ｓ４７〜Ｓ４９）。
【０１６３】
Ｌ３ＶＰＮ網１０のエッジ装置１１は、ＩＰデータを受け取ると、ＭＰＬＳを終端し、Ｌ３ＶＰＮカプセル化して接続先のｘＳＰのエッジルータ９に転送する（Ｓ４５）。
【０１６４】
接続先のｘＳＰからユーザ側装置３に対して送信されるＩＰデータは、Ｓ４０からＳ４５に示す処理と反対の処理により転送される。従って、網内を転送されてきたＩＰデータは、ユーザ収容装置２においてＰＰＰｏＥカプセル化されてユーザ側装置３に送出される（Ｓ５０）。この時、Ｓ４１と同様に、ＩＰデータの宛先ＭＡＣアドレスの変換は不要である。
【０１６５】
なお、ユーザ収容装置２にラベルのシグナリングを行うラベルパスシグナリング手段２４が設けられていれば、ユーザの接続先ｘＳＰの識別をトリガとしてダイナミックにラベルパスを設定することができる。網内では、ＭＰＬＳ（Ｔｕｎｎｅｌ）ラベルパスに沿ってＩＰデータがラベルスイッチング転送され、Ｌ３ＶＰＮ網１０のエッジ装置１１に渡される。
【０１６６】
そして、Ｌ３ＶＰＮ網１０でもまたＶＰＮごとの転送処理がなされてｘＳＰに転送される。なお、ユーザセッションはユーザ収容装置２で制御しているため、Ｌ３ＶＰＮ網１０内でユーザセッションの識別は不要である。
【０１６７】
〈その他〉
本発明は、以下のように特定することができる。
（付記１） ＰＰＰｏＥを用いてユーザが複数の接続先から任意の接続先選択を行う通信システムにおいて、ユーザにより選択された接続先宛のデータを中継するレイヤ２網のエッジに配置され、１以上のユーザ側装置を収容する通信装置であって、
ユーザ側装置から受信するＰＰＰｏＥフレームがＰＰＰセッション確立用のフレームか前記接続先宛のデータを含むフレームかを判別するフレーム判別手段と、
前記フレーム判別手段で判別されたセッション確立用のフレームに基づいて、ユーザ認証及び接続先識別を含むユーザ側装置とユーザにより選択された接続先との間の通信に係るＰＰＰセッションを確立するための処理を行うセッション管理手段と、
前記フレーム判別手段で判別された前記接続先宛のデータを含むＰＰＰｏＥフレームから当該データを抽出するフレーム変換手段と、
前記フレーム変換手段で抽出されたデータを前記レイヤ２網へ送出する転送処理手段と
を含む通信装置。（１）
（付記２） 前記各接続先の網のエッジ装置が接続先毎に用意された前記レイヤ２網の網終端装置にそれぞれ接続されており、
前記フレーム変換手段は、前記接続先宛のデータに宛先レイヤ２アドレスとして設定されている自装置のレイヤ２アドレスを当該接続先のエッジ装置のレイヤ２アドレスに変換して前記転送処理手段に渡す
付記１記載の通信装置。（２）
（付記３） 前記レイヤ２網が前記各接続先の網を収容するレイヤ３網にエッジ装置を介して接続され、このエッジ装置が前記レイヤ２網を通じて受信する前記接続先宛のデータに対して前記レイヤ２網の終端処理を行うとともに前記レイヤ３網を介して該当する接続先の網へ転送する処理を行うように構成されており、前記セッション管理手段は、ユーザ側装置との間におけるＰＰＰセッションの確立において、ユーザ側装置に転送されるセッション確立用フレームの送信元レイヤ２アドレスとして前記エッジ装置のレイヤ２アドレスを設定し、
前記フレーム変換手段は、ＰＰＰセッションの確立後にユーザ側装置から受信する接続先宛のデータに宛先レイヤ２アドレスとして設定されている前記エッジ装置のレイヤ２アドレスを変更することなく当該データを前記転送処理手段に渡す
付記１記載の通信装置。（３）
（付記４） 前記レイヤ２網が前記各接続先の網を収容するレイヤ３網に複数のエッジ装置を介して接続され、各エッジ装置が前記レイヤ２網を通じて受信する前記接続先宛のデータに対して前記レイヤ２網の終端処理を行うとともに前記レイヤ３網を介して該当する接続先の網へ転送する処理を行うように構成されており、
前記セッション管理手段は、ユーザ側装置との間におけるＰＰＰセッションの確立において、ユーザ側装置に転送されるセッション確立用フレームの送信元レイヤ２アドレスとして、接続先に応じたエッジ装置のレイヤ２アドレスを設定し、
前記フレーム変換手段は、ＰＰＰセッションの確立後にユーザ側装置から受信する接続先宛のデータに宛先レイヤ２アドレスとして設定されている前記エッジ装置のレイヤ２アドレスを変更することなく当該データを前記転送処理手段に渡す
付記１記載の通信装置。（４）
（付記５） 前記レイヤ２網は、ＩＥＥＥ８０２．１Ｑ ＶＬＡＮに従って接続先毎に論理分割されており、
前記転送処理手段は、前記接続先宛のデータに対し、当該データの接続先に対応するＶＬＡＮ−ｔａｇを設定して前記レイヤ２網に送出する
付記１〜４のいずれかに記載の通信装置。（５）
（付記６） 前記レイヤ２網は、各接続先の網と前記通信装置との相互接続点にそれぞれ位置する接続先毎の網終端装置と前記通信装置との間に前記接続先毎に用意されるＭＰＬＳラベルパスが設定されるＭＰＬＳ網として構成され、
前記転送処理手段は、前記接続先宛のデータに対し、このデータの接続先に対応するＭＰＬＳラベルを設定して前記ＭＰＬＳ網に送出する
付記１〜４のいずれかに記載の通信装置。
（付記７） 前記接続先宛のデータを転送するためのＭＰＬＳラベルパスが設定されていない場合に、当該ＭＰＬＳラベルパスを設定するためのシグナリングを行うラベルパスシグナリング手段をさらに含む
付記６記載の通信装置。
（付記８） 前記レイヤ２網は、各接続先の網と前記通信装置との相互接続点に位置する集約型網終端装置と前記通信装置との間に前記接続先宛のデータの転送用の第１のＭＰＬＳラベルパスと、このデータの接続先の識別用の第２のＭＰＬＳラベルパスとが設定されるＭＰＬＳ網として構成され、
前記転送処理手段は、前記接続先宛のデータに対し、当該データを第１のＭＰＬＳラベルパスを通じて転送するための第１のＭＰＬＳラベルと、当該データの接続先を識別するための第２のＭＰＬＳラベルとを設定して前記ＭＰＬＳ網に送出する
付記１〜４のいずれかに記載の通信装置。
（付記９） 前記接続先宛のデータに対し、対応する第１のＭＰＬＳラベルパスと第２のＭＰＬＳラベルパスとの少なくとも一方が設定されていない場合には、設定されていないＭＰＬＳラベルパスを設定するためのシグナリングを行うラベルパスシグナリング手段をさらに含む
付記８記載の通信装置。
（付記１０） 前記転送処理手段として機能する、スイッチ，イーサネットインタフェース，ＭＰＬＳインタフェースを備えるシャーシ型の通信装置に対し、前記フレーム判別手段，前記セッション管理手段，及び前記フレーム変換手段を含む通信モジュールが付加されてなる
付記６〜９のいずれかに記載の通信装置。
（付記１１） 前記転送処理手段が、接続先毎に且つ接続先からユーザに対するサービスの提供形態毎に用意されるレイヤ２の仮想閉域網を介して前記接続先のデータが前記レイヤ２網を転送されるように、当該データの接続先及びサービスの提供形態に対応するレイヤ２の仮想閉域網に当該データをマッピングして送出する付記１〜１０のいずれかに記載の通信装置。
【０１６８】
【発明の効果】
本発明によれば、セッションコントロール処理が集中することにより生じるボトルネックを回避することができる通信装置を提供することが可能となる。
【図面の簡単な説明】
【図１】イーサフレームフォーマットを示す図である。
【図２】イーサタイプを示す図である。
【図３】ＰＰＰｏＥを使用したＢＲＡＳを介したユーザ側装置とｘＳＰ間の接続イメージの一例を示す図である。
【図４】ＰＰＰｏＥによるＢＲＡＳを介したユーザ側装置とｘＳＰとの間の接続における通信方式のシーケンス例を示す図である。
【図５】ＰＰＰｏＥフレームフォーマットの一例を示す図である。
【図６】ＰＰＰｏＥフレームフォーマットの一例を示す図である。
【図７】ＰＰＰｏＥを使用したＢＲＡＳを介したユーザ側装置とｘＳＰ間の接続イメージの一例を示す図である。
【図８】ＢＲＡＳの内部を示す図である。
【図９】ＰＰＰ状態遷移テーブルを示す図である。
【図１０】Ｌ２ＳＷをベースとした広域ＬＡＮサービス例を示す図である。
【図１１】ＥｏＭＰＬＳサービス例を示す図である。
【図１２】ＢＲＡＳを用いたｘＳＰ選択接続サービスの問題点を説明する図である。
【図１３】ＩＥＥＥ８０２．１Ｘのフレームフォーマットを示す図である。
【図１４】ＩＥＥＥ８０２．１Ｘによるシーケンス例を示す図である。
【図１５】ＩＥＥＥ８０２．１Ｘによる接続イメージを示す図である。
【図１６】本発明の実施形態に係る通信装置及びこの通信装置を含むＬ２ＶＰＮネットワークシステムの概要を示す図である。
【図１７】ユーザ収容装置のシステム構成を示す図である。
【図１８】フレーム判別手段の説明図である。
【図１９】セッション管理手段の説明図である。
【図２０】フレーム変換手段の説明図である。
【図２１】Ｌ２ＶＰＮ網の終端点でｘＳＰに直接接続される場合の接続形態例を示す図である。
【図２２】図２１に示す接続形態において適用されるユーザ収容装置の構成例を示す図である。
【図２３】Ｌ２ＶＰＮ網、さらにＬ３ＶＰＮ網を経由する場合の接続形態例を示す図である。
【図２４】図２３に示す接続形態において適用されるユーザ収容装置の構成例を示す図である。
【図２５】ｘＳＰごとに論理分割された網構成において適用されるユーザ収容装置の構成例を示す図である。
【図２６】ＶＬＡＮ（ＩＥＥＥ８０２．１Ｑ）でｘＳＰごとに論理分割された網構成を示す。
【図２７】図２８に示す網構成が適用される場合におけるユーザ収容装置の構成例を示す図である。
【図２８】Ｌ２ＶＰＮ網がＭＰＬＳ網１５で構成され、ｘＳＰごとの網終端装置をＭＰＬＳラベルパスのエッジノード（ＬＥＲ）とする場合の網構成例を示す図である。
【図２９】ラベルパスシグナリング手段をさらに備えたユーザ収容装置の構成例を示す図である。
【図３０】図３１に示す網構成に適用されるユーザ収容装置の構成例を示す図である。
【図３１】Ｌ２ＶＰＮ網がＭＰＬＳ網であって集約型網終端装置をＬＥＲとする網構成例を示す図である。
【図３２】ＭＰＬＳラベルを二段で用いる場合のユーザ収容装置の構成例を示す図である。
【図３３】本発明におけるユーザ収容装置の構成例を示す図である。
【図３４】本発明における統合Ｌ２ＶＰＮネットワークの構成例を示す図である。
【図３５】本発明の実施例１を説明する図である。
【図３６】本発明の実施例１を説明する図である。
【図３７】本発明の実施例２を説明する図である。
【図３８】本発明の実施例２を説明する図である。
【符号の説明】
１ Ｌ２ＶＰＮ網
２ ユーザ収容装置
３ ユーザ側装置（ユーザ端末）
９ エッジ装置（エッジルータ）
１１ Ｌ３ＶＰＮ網エッジ装置
１２ ＶＬＡＮ網
１３ 網終端装置
１５ ＭＰＬＳ網
１６ 集約型網終端装置
２０ フレーム判別手段
２１ セッション管理手段
２２ フレーム変換手段
２２ａ，ｂ テーブル（フレーム変換手段）
２３ 転送処理手段
２３ａ，ｂ フォワーディングテーブル
２３ｃ ＭＰＬＳラベルテーブル
２４ ラベルパスシグナリング手段
３０ シャーシ型ＭＰＬＳ対応通信装置
３１，３２ インタフェース
３３ 切替スイッチ
３４ 通信モジュール
Claims (5)
- ＰＰＰｏＥを用いてユーザが複数の接続先から任意の接続先選択を行う通信システムにおいて、ユーザにより選択された接続先宛のデータを中継するレイヤ２網のエッジに配置され、１以上のユーザ側装置を収容する通信装置であって、
ユーザ側装置から受信するＰＰＰｏＥフレームがＰＰＰセッション確立用のフレームか前記接続先宛のデータを含むフレームかを判別するフレーム判別手段と、
前記フレーム判別手段で判別されたセッション確立用のフレームに基づいて、ユーザ認証及び接続先識別を含むユーザ側装置とユーザにより選択された接続先との間の通信に係るＰＰＰセッションを確立するための処理を行うセッション管理手段と、
前記フレーム判別手段で判別された前記接続先宛のデータを含むＰＰＰｏＥフレームから当該データを抽出するフレーム変換手段と、
前記フレーム変換手段で抽出されたデータを前記レイヤ２網へ送出する転送処理手段と
を含む通信装置。 - 前記各接続先の網のエッジ装置が接続先毎に用意された前記レイヤ２網の網終端装置にそれぞれ接続されており、
前記フレーム変換手段は、前記接続先宛のデータに宛先レイヤ２アドレスとして設定されている自装置のレイヤ２アドレスを当該接続先のエッジ装置のレイヤ２アドレスに変換して前記転送処理手段に渡す
請求項１記載の通信装置。 - 前記レイヤ２網が前記各接続先の網を収容するレイヤ３網にエッジ装置を介して接続され、このエッジ装置が前記レイヤ２網を通じて受信する前記接続先宛のデータに対して前記レイヤ２網の終端処理を行うとともに前記レイヤ３網を介して該当する接続先の網へ転送する処理を行うように構成されており、
前記セッション管理手段は、ユーザ側装置との間におけるＰＰＰセッションの確立において、ユーザ側装置に転送されるセッション確立用フレームの送信元レイヤ２アドレスとして前記エッジ装置のレイヤ２アドレスを設定し、
前記フレーム変換手段は、ＰＰＰセッションの確立後にユーザ側装置から受信する接続先宛のデータに宛先レイヤ２アドレスとして設定されている前記エッジ装置のレイヤ２アドレスを変更することなく当該データを前記転送処理手段に渡す
請求項１記載の通信装置。 - 前記レイヤ２網が前記各接続先の網を収容するレイヤ３網に複数のエッジ装置を介して接続され、各エッジ装置が前記レイヤ２網を通じて受信する前記接続先宛のデータに対して前記レイヤ２網の終端処理を行うとともに前記レイヤ３網を介して該当する接続先の網へ転送する処理を行うように構成されており、
前記セッション管理手段は、ユーザ側装置との間におけるＰＰＰセッションの確立において、ユーザ側装置に転送されるセッション確立用フレームの送信元レイヤ２アドレスとして、接続先に応じたエッジ装置のレイヤ２アドレスを設定し、
前記フレーム変換手段は、ＰＰＰセッションの確立後にユーザ側装置から受信する接続先宛のデータに宛先レイヤ２アドレスとして設定されている前記エッジ装置のレイヤ２アドレスを変更することなく当該データを前記転送処理手段に渡す
請求項１記載の通信装置。 - 前記レイヤ２網は、ＩＥＥＥ８０２．１Ｑ ＶＬＡＮに従って接続先毎に論理分割されており、
前記転送処理手段は、前記接続先宛のデータに対し、当該データの接続先に対応するＶＬＡＮ−ｔａｇを設定して前記レイヤ２網に送出する
請求項１〜４のいずれかに記載の通信装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003095909A JP4166609B2 (ja) | 2003-03-31 | 2003-03-31 | 通信装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003095909A JP4166609B2 (ja) | 2003-03-31 | 2003-03-31 | 通信装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004304574A true JP2004304574A (ja) | 2004-10-28 |
| JP4166609B2 JP4166609B2 (ja) | 2008-10-15 |
Family
ID=33408123
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003095909A Expired - Fee Related JP4166609B2 (ja) | 2003-03-31 | 2003-03-31 | 通信装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4166609B2 (ja) |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006311159A (ja) * | 2005-04-28 | 2006-11-09 | Nec Corp | ユーザ側装置、ｉｐ電話システム、及び電話機の位置固定方法 |
| JP2006352503A (ja) * | 2005-06-16 | 2006-12-28 | Hewlett-Packard Development Co Lp | 通信システムおよびその方法 |
| JP2007174209A (ja) * | 2005-12-21 | 2007-07-05 | Matsushita Electric Works Ltd | セキュリティ通信システム |
| JP2007312289A (ja) * | 2006-05-22 | 2007-11-29 | Hitachi Communication Technologies Ltd | パケット転送装置、パケット転送システムおよびパケット転送方法 |
| JP2008160868A (ja) * | 2008-01-16 | 2008-07-10 | Hitachi Communication Technologies Ltd | パケット転送装置 |
| JP2008530882A (ja) * | 2005-02-14 | 2008-08-07 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | サービスバインディングを用いアクセスドメイン上でユニキャストメッセージを介してデータトラフィックを集合する方法およびノード |
| JP2008530881A (ja) * | 2005-02-14 | 2008-08-07 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | アクセスドメイン上でデータトラフィックを集合する方法と、本方法に関するノード |
| WO2009086776A1 (zh) * | 2007-12-27 | 2009-07-16 | Huawei Technologies Co., Ltd. | 虚拟专用网接入方法、***及装置 |
| JP2011107796A (ja) * | 2009-11-13 | 2011-06-02 | Alaxala Networks Corp | 複数認証サーバを有効利用する装置、システム |
| WO2019240024A1 (ja) * | 2018-06-13 | 2019-12-19 | 日本電信電話株式会社 | ネットワーク制御装置、ユーザ端末、通信システム、ネットワーク制御方法およびネットワーク制御プログラム |
-
2003
- 2003-03-31 JP JP2003095909A patent/JP4166609B2/ja not_active Expired - Fee Related
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4698684B2 (ja) * | 2005-02-14 | 2011-06-08 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | アクセスドメイン上でデータトラフィックを集合する方法と、本方法に関するノード |
| JP4696131B2 (ja) * | 2005-02-14 | 2011-06-08 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | サービスバインディングを用いアクセスドメイン上でユニキャストメッセージを介してデータトラフィックを集合する方法およびノード |
| JP2008530882A (ja) * | 2005-02-14 | 2008-08-07 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | サービスバインディングを用いアクセスドメイン上でユニキャストメッセージを介してデータトラフィックを集合する方法およびノード |
| JP2008530881A (ja) * | 2005-02-14 | 2008-08-07 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | アクセスドメイン上でデータトラフィックを集合する方法と、本方法に関するノード |
| JP2006311159A (ja) * | 2005-04-28 | 2006-11-09 | Nec Corp | ユーザ側装置、ｉｐ電話システム、及び電話機の位置固定方法 |
| JP2006352503A (ja) * | 2005-06-16 | 2006-12-28 | Hewlett-Packard Development Co Lp | 通信システムおよびその方法 |
| JP2007174209A (ja) * | 2005-12-21 | 2007-07-05 | Matsushita Electric Works Ltd | セキュリティ通信システム |
| JP2007312289A (ja) * | 2006-05-22 | 2007-11-29 | Hitachi Communication Technologies Ltd | パケット転送装置、パケット転送システムおよびパケット転送方法 |
| US7733859B2 (en) | 2006-05-22 | 2010-06-08 | Hitachi, Ltd. | Apparatus and method for packet forwarding in layer 2 network |
| WO2009086776A1 (zh) * | 2007-12-27 | 2009-07-16 | Huawei Technologies Co., Ltd. | 虚拟专用网接入方法、***及装置 |
| JP4621259B2 (ja) * | 2008-01-16 | 2011-01-26 | 株式会社日立製作所 | パケット転送制御方法 |
| JP2008160868A (ja) * | 2008-01-16 | 2008-07-10 | Hitachi Communication Technologies Ltd | パケット転送装置 |
| JP2011107796A (ja) * | 2009-11-13 | 2011-06-02 | Alaxala Networks Corp | 複数認証サーバを有効利用する装置、システム |
| WO2019240024A1 (ja) * | 2018-06-13 | 2019-12-19 | 日本電信電話株式会社 | ネットワーク制御装置、ユーザ端末、通信システム、ネットワーク制御方法およびネットワーク制御プログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4166609B2 (ja) | 2008-10-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4631961B2 (ja) | 仮想アクセスルータ | |
| JP4236398B2 (ja) | 通信方法、通信システム及び通信接続プログラム | |
| USRE46195E1 (en) | Multipath transmission control protocol proxy | |
| JP4732974B2 (ja) | パケット転送制御方法およびパケット転送装置 | |
| JP4394590B2 (ja) | パケット中継装置および通信帯域制御方法 | |
| US7835370B2 (en) | System and method for DSL subscriber identification over ethernet network | |
| US7656872B2 (en) | Packet forwarding apparatus and communication network suitable for wide area Ethernet service | |
| KR101063080B1 (ko) | 이더넷 ｄｓｌ 액세스 멀티플렉서 및 동적 서비스 선택과최종-사용자 구성을 제공하는 방법 | |
| EP2031803B1 (en) | Relay network system and terminal adapter apparatus | |
| JP2000341327A (ja) | Ｖｐｎ構成方式、インターワークルータ装置、パケット通信方法、データ通信装置及びパケット中継装置 | |
| EP1415442B1 (en) | Metropolitan access via tunnel transports | |
| WO2007124679A1 (fr) | Procédé et système de communication en réseau | |
| JP4241329B2 (ja) | 仮想アクセスルータ | |
| JP4166609B2 (ja) | 通信装置 | |
| US7978602B2 (en) | Dynamic construction of label switching protocol interfaces | |
| Cisco | Remote Access to MPLS VPN | |
| JPWO2003043276A1 (ja) | プロバイダ接続システム及びそのパケット交換装置並びにパケット交換方法及びそのコンピュータプログラム | |
| EP1981217A1 (en) | Method for forwarding data packets in an access network and device | |
| WO2009086776A1 (zh) | 虚拟专用网接入方法、***及装置 | |
| CN101030877B (zh) | 一种点到点协议实现组播业务的方法 | |
| JP2004104527A (ja) | インターネットアクセスネットワーク及びアクセススイッチ装置 | |
| WO2009065349A1 (fr) | Procédé, dispositif et système de mandataire de commande de couche 2 | |
| JP2003234753A (ja) | エッジ・ブロードバンド・アクセス中継装置およびブロードバンドネットワークシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060223 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080318 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080408 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080609 |
|
| 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: 20080722 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080730 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110808 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120808 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120808 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130808 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |