JP4706542B2 - 通信装置 - Google Patents

Description

本発明は、インターネットプロトコルを用いて、物理的に離れた拠点間で論理的な閉域ネットワーク（VPN）を構成する通信システムに関する。

インターネットプロトコル(IP)を用いてL2VPNを構築する方式として、EtherIP(非特許文献１参照)、L2TPv3(非特許文献２参照)等がIETFにより標準化されている。EtherIPでは、VPN装置が接続するLAN上を流れるイーサフレームを捕捉し、EtherIPヘッダおよびIPヘッダでカプセル化して対向のVPN装置に送信する。イーサフレームをEtherIPヘッダおよびIPヘッダでカプセル化したIPパケットを受信したVPN装置は、受信したIPパケットからイーサフレームを取り出し、IPパケットを受信したVPN装置が接続するLANにイーサフレームを送信することで、L2VPNを構築する。L2TPv3では、論理的な二つの通信路（制御チャネルとデータチャネル）を定義している。制御チャネルでは、制御コネクションやセッションの確立、解放を行う。データチャネルでは、確立されたセッションを利用して、イーサフレームの転送を行う。イーサフレームの転送には、L2TPセッションヘッダを用いる。セッションヘッダはIPヘッダまたはUDP、IPヘッダでカプセル化される。

ＲＦＣ３３７８ ＲＦＣ３９３１

L2VPNでローカルエリアネットワーク(LAN)間を接続すると、接続したLAN間でOSI(Open System Interconnection)参照モデルの第2層(Layer2:L2)の接続性が確保できるため、上位層であるIPのバージョンに依存せず、任意のアドレス体系で通信することが可能となる。そのため、家庭内のLANとサービス提供事業者のサービス提供網とをL2VPNで接続すれば、サービス提供事業者の任意の運用ポリシーで、端末へのサービスを提供することができる。しかしながら、複数のサービス提供事業者とユーザ宅とを複数のVPNで接続した場合、家庭内のLANを介して、全てのサービス提供事業者の網がL2で接続されるため、不要なトラヒックが増大したり、IPアドレスの重複により通信が混乱し、適切なサービスを享受できない可能性がある。そのため、家庭内のLANと複数のサービス事業者の網とを複数のVPNで接続する場合、家庭内の端末が送受信するトラヒックを適切なVPNへ振り分ける必要がある。

また、家庭内の端末がサービス提供事業者に接続する場合、家庭内のルータに各端末に応じたサービス提供事業者へのVPN設定を行う必要がある。そのため、複数の端末がサービス提供事業者に接続する場合、端末数分のVPN設定が必要である。VPN設定を誤ると適切なサービス提供事業者へ接続不能となる可能性がある。家庭内のユーザは、ネットワークの知識が必ずしも豊富ではないため、家庭内のユーザが行う設定は少ない方が誤設定の危険性を削減することができる。本特許は、このような課題を解決する。

端末がネットワーク接続時に送信するUPnPメッセージを解析し、得られた端末情報と、契約ユーザ情報をもとにVPNのSIP URIを管理サーバに問合せる。管理サーバは、通知された情報をもとに端末に提供するVPNのSIP URIを解決し、ルータに通知する。ルータは通知されたSIP URIにもとづいてVPNを確立する。このようにして確立したVPNと、UPnPメッセージの送信元端末との関連付けをルータが保持し、ルータはVPN確立後各端末が送受信するトラヒックを、上記関連づけに基づいて転送する。

また、VPN SIP URIは、管理サーバに問合せを行わず、ルータが自動生成することも可能である。

本発明によると、端末が送信する端末情報と、ユーザ情報等から、端末に適切なサービスを提供するサービス提供事業者へのVPN情報を、中継ルータが解決または自動生成し、端末に適切なVPNを動的に構築することが可能となる。これにより、サービスを利用するユーザは、各端末に応じた詳細なVPN設定を手動で行う必要がなく、ユーザの処理を削減できる。また、端末情報の送信元MACアドレスとVPNとを関連付けるMAC-VPN対応テーブルを確立することにより、各端末に適切なVPNにトラヒックを振り分けることが可能となる。これにより、サービス提供事業者は、IPのバージョン、アドレス体系に関係なく、任意の運用ポリシーで、家庭内の特定の端末にサービスを提供することが可能となる。

図１は本発明が実施される通信システムを示している。本通信システムは、ルータA101、B102、C103、D104、ルータAが所属するホーム網105、IP網106、ルータBからDが所属する各サービス提供事業者の網（107、108、109）、ホーム網に所属する端末A110、B111、C112、各サービス提供事業者のサーバ（113、114、115）、SIPサーバ119、サービス提供事業者BのDHCPサーバ120、管理サーバ121から構成される。ルータA、BはVPN116、ルータA、CはVPN117、ルータA、DはVPN118で接続される。

図２−１は、ルータの構成例である。ルータA101は、CPU(Central Processing Unit)201、メモリ202、インタフェース部204、205から構成される。CPU201は、各種アプリケーションプログラムや、OS(Operating System)を実際に実行する。メモリ202はCPU201の実行において使用するプログラムや、各種アプリケーションプログラムが格納される。CPU201とメモリ202は、バス203を介して接続される。インタフェース部204、205はCPU201やメモリ202から供給されたデータを外部の機器に供給したり、外部の機器からのデータを受信する。インタフェース部はそれぞれ回線（206、207）に接続され、インタフェース部204、205のうちどちらか一方はホーム網105に接続する回線、もう一方はIP網106に接続する回線である。

図２−２はメモリ202内に格納された情報を示している。MAC-VPN対応テーブル214、SIP URI変換テーブル215、ユーザ情報テーブル216、フィルタエントリテーブル217、VPN管理テーブル218などのテーブル及び、メモリ202内には、UPnP（Universal Plug and Play）解析処理208、DHCP（Dynamic Host Configuration Protocol）処理209、SIP(Session Initiation Protocol)処理210、L2TP処理213などのプログラムが格納されている。L2TP処理213は、制御コネクション処理211及び、L2転送処理212から構成される。

UPnP解析処理208は、ホーム網105に所属する端末（110、111、112）からのUPnPメッセージを解析し、VPN確立に必要なSIP URIを取得または生成する。DHCP処理209は、VPNの確立の有無に応じて、端末にDHCPサーバ機能を提供するか否かを決定する。L2TP処理213は、L2TPを利用したVPN機能を提供する。制御コネクション処理211は、L2TPの制御コネクションの確立、解放処理を行う。L2転送処理212はL2TPの制御コネクション確立後、L2データの転送処理を行う。SIP処理210は、SIPセッションの確立、解放を行う。

MAC-VPN対応テーブル214は、端末からのトラヒックを適切なVPNに振り分けるために、MACアドレスとVPNとの対応関係を管理する。図３−１は、MAC-VPN対応テーブル214の構成例を示している。管理する情報は、端末のMACアドレス、サービス提供事業者へのVPNのSIP URI、サービス提供事業者ルータのIPアドレス、確立中のVPNのVPN IDである。

SIP URI変換テーブル215は、UPnPを利用して取得した端末情報と、端末に対応するVPNのSIP URIを管理する。図３−２は、SIP URI変換テーブル215の構成例を示している。管理する情報は、製品名、製造者名などの端末情報と、端末情報に対応するVPNのSIP URIである。

ユーザ情報テーブル216は、サービス提供事業者及びプラットホーム事業者と契約するユーザの契約ユーザ名などの情報を管理する。図３−３は、ユーザ情報テーブル216の構成例を示している。

フィルタエントリテーブル217は、VPN内のトラヒックを適切にフィルタリングするために、L2TPのセッションごとにフィルタエントリを管理する。図３−４は、フィルタエントリテーブル217の構成例を示している。管理する情報は、エントリに従ってフィルタを行うか否か（ON/OFF）、パケットの向き（Inbound/Outbound）、イーサフレームの送信元MACアドレス及び宛先アドレス、IPパケットの送信元IPアドレス及び宛先IPアドレス、UDP、TCPパケットの送信元ポート番号、宛先ポート番号、プロトコル種別、イーサフレーム及びパケットが上記記述ルールに合致した場合の取り扱い（通過又は破棄）である。

VPN管理テーブル218は、確立中のL2TP VPNを管理するする。図３−５はVPN管理テーブル218の構成例を示している。管理する情報は、確立中の各VPNを識別するためのVPN ID、VPNを確立した自インタフェースに割り当てているIPアドレスであるローカルIPアドレス、VPNを確立した対向ルータのIPアドレスであるリモートIPアドレス、自ルータがL2TPの制御コネクションID、セッションIDに割り当てたIDである、ローカル制御コネクションID、ローカルセッションID、対向ルータがL2TPの制御コネクションID、セッションIDに割り当てたIDである、リモート制御コネクションID、リモートセッションIDである。

管理サーバ121は、SIP URI管理テーブル1101を保持し、契約ユーザが利用する端末情報とサービス提供事業へVPNを確立するためのSIP URIとの対応関係を管理する。図１１−１にSIP URI管理テーブル1101の構成例を示す。SIP URI管理テーブル1101は、少なくとも契約ユーザ名、製品名、製造者名、サービス提供事業者、SIP URIの情報を管理する。製品名及び製造者名は、端末を識別するための値であり、図１１−２に示すように、製造番号と製造者名などを用いてもよい。

図４は、本発明が実施されるシーケンスを示している。ホーム網105のユーザは、予めルータA101に、サービス提供事業者及びプラットホーム事業者と契約したユーザ名（USER A）などの契約情報を登録しておく。登録した情報は、ルータA101のユーザ情報テーブル216で管理される。また、ルータB102は、サービスを提供するVPNのSIP URIと、上記SIP URIに対応するIPアドレスとをREGISTERメッセージを用いてSIPサーバ119に登録する。

ホーム網105内の端末A110は、ネットワークに接続するとIPアドレスを取得するために、DHCP DISCOVERメッセージをブロードキャストで送信する。本メッセージの送信元MACアドレスは端末A110のMACアドレスであるaaaである。DHCP DISCOVERメッセージを受信したルータA101は、DHCP処理209を呼び出す。

図６にDHCP処理209の処理フローを示す。ルータA101は、DHCP DISCOVERメッセージを受信する（ステップ601）と、メッセージの送信元MACアドレスaaaを取得する（ステップ602）。取得したMACアドレスaaaをもとに、MAC-VPN対応テーブル214を検索し（ステップ603）、MACアドレスの登録の有無を確認する（ステップ604）。MAC-VPN対応テーブル214にMACアドレスの登録がありVPN IDが登録されている場合は、VPNで接続した網内にDHCPサーバが設置されていると判断し、端末に対してDHCPサーバ機能を提供せず、処理を終了する（ステップ606）。MAC-VPN対応テーブル214にMACアドレスの登録がない場合は、端末に対してDHCPサーバ機能を提供する（ステップ605）。端末に対し、利用可能なアドレスを通知するために、DHCP OFFERメッセージを送信し、処理を終了する。この段階で、端末A110のMACアドレスは、MAC-VPN対応テーブル214に登録されていないため、ルータA101は、端末A110に対してDHCPサーバ機能を提供する。ルータA101は、ホーム網105用に管理しているIPアドレスプールの中から、使用していないIPアドレスaを選択し、DHCP OFFERメッセージを用いて端末A110にIPアドレスを通知する。通知するIPアドレスaの有効時間は、以後サービス提供事業者のDHCPサーバから端末A110にアドレスが配布されることを想定し、比較的短い時間に設定する。

図４に戻り、シーケンスを説明する。端末A110は、ルータA101が送信したDHCP OFFERメッセージを受信し、指定されたアドレスaを利用することを通知するためにルータA101にDHCP REQUESTメッセージを送信する。DHCP REQUESTメッセージを受信したルータA101は、応答としてDHCP ACKメッセージを端末A110に送信する。以上により、端末A110にIPアドレスaが割り当てられる。

端末A110は、ルータA101から取得したIPアドレスaを利用して、UPnP Device DiscoveryメッセージのAdvertisement: Device availableを送信する。Advertisement: Device availableは、自端末が利用可能であることを通知するメッセージであり、SSDP（Simple Service Discovery Protocol）のaliveを用いる。

ルータA101は、端末A110が送信したUPnPメッセージを受信すると、UPnP解析処理208を呼び出す。図８にUPnP解析処理208の処理フローを示す。ルータA101は、UPnPメッセージを受信する（ステップ801）と、UPnPメッセージの送信元MACアドレスを取得する（ステップ802）。受信したメッセージを解析し（ステップ803）し、UPnPメッセージの種別を判定する。まず、受信メッセージがUPnP Device DiscoveryメッセージのAdvertisementか否かを判定する（ステップ804）。図１０−１、図１０−２に、UPnP Device DiscoveryメッセージのAdvertisementメッセージの記述例を示す。Advertisementか否かは、メッセージのリクエストメソッド1001で判定する。リクエストメソッドがNOTIFYの場合、Advertisementと判定する。本受信メッセージはAdvertisementであるので、ステップ812を処理する。ステップ812では、受信したAdvertisementメッセージのNTSヘッダ1003を解析し、端末が利用可能であることを通知するDevice availableか否かを判定する（ステップ812）。NTSヘッダ1003が、ssdp: aliveである場合には、Device availableと判定する。本受信メッセージは、Device availableであるので、ステップ813を処理する。ステップ813では、LOCATIONヘッダから端末A110のDescription URL (http://a:12121)を取得する。Description URLは、端末の詳細情報の記述場所を示すURLである。ルータA101はステップ813で取得したURL (http://a:12121)に対し、HTTP（Hyper Text Transfer Protocol）のGETリクエストを送信し（ステップ814）、処理を終了する。

図４に戻りシーケンスを説明する。HTTP GETリクエストを受信した端末A110は、200 OKのレスポンスコードと共に、UPnP Device DescriptionメッセージをルータA101に送信する。ルータA101は、UPnPメッセージを受信すると、UPnP解析処理208を呼び出す。ステップ801から804を処理し、受信メッセージを解析する。図１０−３にUPnP Device Descriptionメッセージの記述例を示す。本メッセージは、Advertisementではないので、ステップ805を処理する。ステップ805では、XML構文を解析し受信メッセージがUPnP Device Descriptionメッセージか否かを判定する。rootヘッダ1004の値が<root xmlns="urn:schemas-upnp-org:device-1-0">の場合、UPnP Device Descriptionメッセージと判定し、ステップ806を処理する。受信メッセージがUPnP Device Descriptionでない場合には処理を終了する。ステップ806では、UPnP Device Descriptionのmanufactureヘッダ1005及びmodelNameヘッダ1006から、端末A110の製造者名（HITACHI）及び、製品名(AA-100)を取得する。manufactureヘッダ1005及びmodelNameヘッダ1006はUPnP Device Descriptionメッセージには必須な情報であり、記述がない場合には処理を終了する。ステップ807では、ステップ806で取得した端末A110の製品名、製造者名とユーザ情報テーブル216に登録された契約ユーザ名をSIP URI要求メッセージとして、管理サーバ121に通知し、端末A110に対応するVPNサービスのSIP URIを要求する。

SIP URI要求を受信した管理サーバ121は、受信したSIP URI要求に含まれる契約ユーザ名、製品名、製造者名を取得後、SIP URI管理テーブル1101を参照し該当するSIP URIを取得する。取得したSIP URIと、SIP URI要求メッセージで通知された製品名、製造者名をSIP URI応答としてルータA101に送信する。

管理サーバ121が、端末の識別を製造番号で行っている場合は、ステップ806でSerialNumberヘッダ1007から端末の製番号（112233）を取得する。ステップ807では、ステップ806で取得した端末の製造番号（112233）とユーザ情報テーブル216に登録された契約ユーザ名をSIP URI要求メッセージとして、管理サーバ121に通知し、端末A110に対応するVPNサービスのSIP URIを要求する。その他の処理についても、製品名のかわりに製造番号を用いる。

図８に戻り、UPnP解析処理フロー208を説明する。SIP URI要求を送信（ステップ807）後、UPnP解析処理208は、SIP URI応答を受信するまで待機する。一定時間待機し、SIP URI応答を受信しない場合は処理を終了する。SIP URI応答を受信する（ステップ808）と、SIP URI応答から取得した、製品名、製造者名、SIP URIをSIP URI変換テーブル215に設定する。設定したSIP URI変換テーブル215から端末A110に該当するSIP URI（×××＠△△△）を取得する（ステップ810）。ステップ802で取得したMACアドレスaaa及び、ステップ810で取得したSIP URIをMAC-VPN対応テーブル214に設定し（ステップ811）、処理を終了する。

図４に戻り、シーケンスを説明する。UPnP解析処理208でSIP URIを取得したルータA101は、SIP処理210に処理を引き継ぐ。SIP処理210は、UPnP解析処理208で取得したSIP URIを用いてセッション開始要求（INVITEメッセージ）をSIPサーバ119に送信する。INVITEメッセージを受信したSIPサーバ119は、SIP URIを解析し、適切な転送先であるルータB102にINVITEメッセージを転送する。INVITEメッセージを受信したルータB102は、セッション開始要求に応じる場合は、200OKメッセージをSIPサーバ119に送信する。SIPサーバ119は、上記メッセージをルータA101に転送する。200OKメッセージを受信したルータA101は、ヘッダフィールドを参照し、Toヘッダに含まれるSIP URI（×××＠△△△）とContractヘッダに含まれるIPアドレス（B）を取得する。MAC-VPN対応テーブル214を参照し、該当するSIP URIを有するエントリにContractフィールドから取得したIPアドレスBを記録する。その後、ACKメッセージをルータB102に直接送信する。上記、シーケンスによって、ルータA101、B102間にSIPセッションが確立する。

SIPセッション確立後、ルータA101はL2TP処理213の制御コネクション処理211に処理を引き継ぐ。制御コネクション処理211は、SIP処理210で取得した対向ルータのIPアドレスBに対して、L2TP制御コネクションの確立を開始する。ルータA101は、MAC-VPN対応テーブル214を参照し、ルータB102のIPアドレスBを取得する。取得したIPアドレスBをIPパケットの宛先とするSCCRQ(Start Control Connection Request)メッセージを生成し、ルータB102に送信する。SCCRQメッセージには、ルータA101が割り当てた制御コネクションID 9000が含まれる。ルータA101が割り当てた制御コネクションIDは、Assigned Control Connection ID AVPを用いて通知する。通知した制御コネクションIDである9000をローカル制御コネクションIDとして、VPN管理テーブル218に登録する。ルータB102は、SCCRQへの応答としてSCCRP(Start Control Connection Reply)をルータA101に送信する。SCCRPメッセージには、ルータB102が割り当てた制御コネクションID 1111が含まれる。ルータB102が割り当てた制御コネクションIDは、Assigned Control Connection ID AVPを用いて通知する。SCCRPメッセージを受信したルータA101は、メッセージに含まれるルータBが割り当てた制御コネクションID（1111）を取得し、リモート制御コネクションIDとして、VPN管理テーブル218に記録する。その後、SCCCN(Start Control Connection Connected)メッセージをルータBに送信する。上記、シーケンスによって、ルータA101、B102間にL2TP制御コネクションが確立する。さらに、ルータA101、ルータB102間でICRQ(Incoming call Request)、ICRP(Incoming call Reply)、ICCN(Incoming call Connected)メッセージを交換し、L2TPセッションが確立する。ICRQメッセージには、ルータA101が割り当てたセッションID 6000が含まれる。また、ICRPメッセージには、ルータB102が割り当てたセッションID 4444が含まれる。ルータAが割り当てたセッションIDである6000は、ローカルセッションIDとして、ルータB102が割り当てたセッションIDである4444は、リモートセッションIDとして、ルータA101のVPN管テーブル218に登録する。各ルータ（A101、B102）が割り当てたセッションIDは、Local Session ID AVPを用いて通知される。

制御コネクション、セッションが確立後、該当するVPN管理テーブル218にVPNを識別するためのVPN ID 1を登録する。VPN管理テーブル218に登録したVPN IDと同様のVPN ID（VPN ID 1）を、制御コネクション確立開始前に参照したMAC-VPN対応テーブル214に登録する。

以上の処理、UPnP解析処理208、SIP処理210、制御コネクション処理211により、MAC-VPN対応テーブル214のエントリが完成し、MACアドレスとVPNとの対応関係が管理できる。以後、上記テーブルを参照し、L2転送処理212を行う。

端末A110は、ルータA101のDHCPサーバが割り当てたIPアドレスaの有効時間が切れると、IPアドレスaを解放し、DHCP DISCOVERメッセージをブロードキャストで送信する。DHCP DISCOVERメッセージを受信したルータA101は、DHCP処理209を呼び出す。DHCP処理209は、図６−２に示すフローに従ってステップ601から604を処理する。端末A110のMACアドレスaaaは、UPnP解析処理208のステップ811によりMAC-VPN対応テーブル214に既に登録されているので、ルータA101は、端末A110に対し、DHCPサーバとして動作せず（ステップ606）、処理を終了する。

一方、DHCP DISCOVERメッセージは、ブロードキャストで送信されているため、L2TP処理213のL2転送処理212でも受信される。

図７−１にイーサフレーム受信時のL2転送処理212の処理フローを示す。図９にL2転送処理212で利用するパケットの構成図示す。ルータA101はLAN側インタフェースからイーサフレーム907を捕捉する（ステップ701）と、イーサフレーム907の送信元MACアドレス及び宛先MACアドレスを取得する（ステップ702）。DHCP DISCOVERメッセージの宛先MACアドレスはブロードキャストアドレスである。取得した宛先MACアドレスが、ブロードキャスト宛又は他宛であるかを判定する（ステップ703）。ブロードキャスト又は他宛でない場合は処理を終了する。本イーサフレームの宛先MACアドレスはブロードキャストアドレスであるので、次にステップ704を処理する。ステップ704では、MAC-VPN対応テーブル214を参照する。イーサフレームの送信元MACアドレスがMAC-VPN対応テーブル214に登録があり、VPN IDの登録済みか否かを判定する（ステップ705）。未登録の場合は、処理を終了する。登録済みの場合は、該当するVPN IDのフィルタエントリテーブル217を参照し、ステップ701で捕捉したイーサフレーム907がエントリに該当するか否かを判定する（ステップ707）。フィルタエントリテーブル217の送信元MACアドレス及び宛先MACアドレスは、イーサヘッダ904と比較して判定する。送信元IPアドレス及び宛先IPアドレスは、IPヘッダ905と比較して判定する。送信元ポート及び宛先ポートはTCP/UDPヘッダ906と比較して判定する。プロトコルは、IPヘッダ905のプロトコル番号（IPv4の場合）、次ヘッダ（IPv6の場合）フィールドや、イーサヘッダ904のタイプフィールドから判定する。

エントリに該当しない場合は、処理を終了する。エントリに該当する場合は、エントリのアクションを参照し、アクションが破棄か通過かを判定する（ステップ708）。破棄の場合は処理を終了する。通過の場合は、ステップ705で取得したVPN IDからVPN管理テーブル218を参照し、リモートIPアドレス、リモートセッションIDを取得する。ステップ701で捕捉したイーサフレーム907にIPヘッダ901、UDPヘッダ902、L2TPセッションヘッダ903を付与し（ステップ709）、WAN側回線にL2TPパケット908を出力する（ステップ710）。

以上の処理により、ホーム網内の端末が送信したイーサフレーム907が、端末に適切なサービス提供事業者の網へと転送される。そのため、端末A110が送信したDHCP DISCOVERメッセージは、ルータA101、B102間に構築されたL2TPトンネルを利用して、サービス提供事業者Bの網107へと転送される。サービス提供事業者Bの網107内に設置されたDHCPサーバB120は、端末A110からのDHCP DISCOVERメッセージを受信すると、端末A110が利用可能なIPアドレスAを通知するためにDHCP OFFERメッセージを端末A110に送信する。DHCP OFFERメッセージを捕捉したルータB102は、本メッセージを含むL2TPパケット908を生成し、ルータA101にメッセージを転送する。

図７−２にL2TPパケット受信時のL2転送処理212の処理フローを示す。ルータA101はWAN側インタフェースからL2TPパケット908を受信する（ステップ711）と、IPヘッダ901、L2TPセッションヘッダ903、イーサフレーム904から、送信元IPアドレス、L2TPのセッションID、L2TPでトンネリングされたイーサフレームの宛先MACアドレスを取得する（ステップ712）。VPN管理テーブル218を参照し、ステップ712で取得した送信元IPアドレス及びL2TPのセッションIDが確立中のL2TP VPNのリモートIPアドレス及びローカルセッションIDと一致するか否かを判定する（ステップ713）。一致しない場合は、処理を終了する。一致する場合は、VPN管理テーブル218からVPN IDを取得すると共に、受信したL2TPパケット908から、IPヘッダ901、UDPヘッダ902、L2TPセッションヘッダ903を除去し、イーサフレーム907を取得する（ステップ714）。取得したイーサフレーム907に対し、フィルタエントリテーブル218を参照し（ステップ715）、ステップ714で取得したイーサフレーム907がエントリに該当するか否かを判定する（ステップ716）。フィルタエントリテーブル217は、イーサフレーム受信時と同様に、送信元MACアドレス及び宛先MACアドレスは、イーサヘッダ904と比較して判定する。送信元IPアドレス及び宛先IPアドレスは、IPヘッダ905と比較して判定する。送信元ポート及び宛先ポートはTCP/UDPヘッダ906と比較して判定する。プロトコルは、IPヘッダ905のプロトコル番号（IPv4の場合）、次ヘッダ（IPv6の場合）フィールドや、イーサヘッダ904のタイプフィールドから判定する。エントリに該当しない場合は、処理を終了する。エントリに該当する場合は、エントリのアクションを参照し、アクションが破棄か通過かを判定する（ステップ717）。破棄の場合は処理を終了する。通過の場合は、MAC-VPN対応テーブル214を参照する（ステップ718）。ステップ713で取得したVPN IDに該当するMAC-VPN対応テーブルエントリのMACアドレスと、イーサフレーム907の宛先MACアドレスが一致するか否かを判定する（ステップ719）。MACアドレスが一致する場合は、L2TPパケット908から取得したイーサフレーム907をLAN側回線に出力する（ステップ722）。一致しない場合は、イーサフレーム907の宛先MACアドレスがブロードキャストか否かを判定する（ステップ720）。宛先MACアドレスがブロードキャストでない場合は、処理を終了する。宛先MACアドレスがブロードキャストの場合は、イーサフレーム907の宛先MACアドレスを該当するMAC-VPN対応テーブルエントリに登録されたMACアドレスに書き換え（ステップ721）、イーサフレーム907をLAN側回線に出力する（ステップ722）。

以上の処理により、サービス事業者のサーバが送信したイーサフレーム907が、適切な端末へと転送される。そのため、DHCPサーバB120が送信したDHCP OFFERメッセージが、端末A110へと転送される。

端末A110は、DHCP OFFERメッセージを受信し、指定されたアドレスAを利用することを通知するためにDHCPサーバB120にDHCP REQUESTメッセージを送信する。DHCP REQUESTメッセージを受信したDHCPサーバB120は、応答としてDHCP ACKメッセージを端末A110に送信する。以上により、サービス提供事業者Bの運用ポリシーにより端末A110にIPアドレスAAが割り当てられる。端末A110とサービス提供事業者Bの網107とはL2の接続性が確保されているため、割り当てるIPアドレスは、IPのバージョン（IPv4、IPv6）に関係なく、任意のIPアドレスが割り当て可能である。また、IPv4のプライベートアドレスやIPv6のリンクローカルアドレスの場合でも双方向に通信可能である。

端末B111とサービス提供事業者Cの網108、端末Cとサービス提供事業者Dの網109間で、端末Aの場合と同様にVPNを構築する。

端末A110と同様にして、端末B111とサービス提供事業者Cの網108及び、端末C112とサービス提供事業者Dの網109を接続するために、ルータA101、ルータC103間でVPN117、ルータA101、ルータD104でVPN118を構築する。ルータA101のVPN管理テーブル218に登録されたVPN117のローカル制御コネクションIDは8000、ローカルセッションIDは5000、リモート制御コネクションIDは2222、リモートセッションIDは5555であり、VPN IDは2である。サービス提供事業者Cが端末B111に割り当てたIPアドレスはBB、端末B111のMACアドレスはbbb、ルータCのIPアドレスはCである。また、ルータA101のVPN管理テーブル218に登録されたVPN118のローカル制御コネクションIDは7000、ローカルセッションIDは4000、リモート制御コネクションIDは3333、リモートセッションIDは6666であり、VPN IDは3である。サービス提供事業者Dが端末C112に割り当てたIPアドレスはCC、端末C112のMACアドレスはccc、ルータDのIPアドレスはDである。

ルータAは、上記処理で作成したMAC-VPN対応テーブル214を参照することで、各端末（110、111、112）に適切なVPNへ端末のトラヒックを振り分けることが可能である。

図１２にVPN確立後の制御シーケンス例を示す。サービス提供事業者の網B107をホームセキュリティ会社、サービス提供事業者の網C108を映像配信会社、サービス提供事業者の網D109を端末メーカとする。ホームセキュリティ会社は、ユーザ宅内のカメラ映像を解析し、不審者等の監視サービスを提供する。映像配信会社は、ユーザ宅のTVやSTB（Set Top Box）等に映像配信サービスを提供する。端末メーカは、メーカが販売した製品のプログラム更新サービスを提供する。

VPN確立、IPアドレス配布後、ホームセキュリティ会社のサーバB113は、契約ユーザ宅のカメラ（端末A）110に映像送信要求を通知する。映像送信要求の宛先IPアドレスは、DHCPサーバB120が割り当てたユニキャストアドレスAAを用いる。映像送信要求は、ルータB102に捕捉され、ルータA101、B102間に確立されたVPN116を介してカメラ（端末A110）に送信される。本L2TPパケット908のIPヘッダ901の送信元IPアドレスはB、L2TPセッションヘッダ902のセッションIDは6000である。

上記L2TPパケットを受信したルータA101は、L2転送処理212を呼び出す。L2転送処理212では、図７−２に示すフローに従って処理する。送信元IPアドレスB及びセッションID 6000からVPN管理テーブル218を参照し、VPN ID 1が選択される。さらに、VPN IDからMAC-VPN対応テーブル214を参照する。VPN ID 1に対応するMACアドレスaaaは、L2TPパケット908から取得したイーサフレーム907の宛先MACアドレスと一致するため、映像送信要求を含むイーサフレーム907は端末A110 に送信される。

映像送信要求を受信した端末A110は、カメラ映像をサーバB113に送信する。本カメラ映像を含むイーサフレーム907の送信元MACアドレスはaaaである。送信されたカメラ映像は、ルータA101のL2転送処理212の図７−１に示すフローに従って処理される。MAC-VPN対応テーブル214を参照し、送信元MACアドレスaaaに対応するVPN ID 1を取得する。VPN ID 1に対応するフィルタエントリテーブル217を参照し、通過であれば、VPN管理テーブル218を参照し、リモートIPアドレスB及びリモートセッションID 4444を取得する。カメラ映像を含むイーサフレーム907はIP、UDP L2TPヘッダを付与され、VPN116を介してホームセキュリティ会社のサーバB113に送信される。ホームセキュリティ会社のサーバB113は、カメラ映像を受信し、映像を解析後、解析結果を端末A110に送信する。解析結果の送信は、映像送信要求と同様である。

映像配信会社のサーバC114は、契約ユーザ宅のTV（端末B111）に、配信可能な映像のリストを送信する。リストの宛先IPアドレスは、端末に割り当てたユニキャストIPアドレスBB、マルチキャストアドレス、ブロードキャストアドレスのいずれかを用いる。リストは、ルータC103に捕捉され、ルータA101、C103間に確立されたVPN117を介してTV（端末B111）に送信される。本L2TPパケット908のIPヘッダ901の送信元IPアドレスはC、L2TPセッションヘッダ902のセッションIDは5000である。

上記L2TPパケットを受信したルータA101は、L2転送処理212を呼び出す。L2転送処理212では、図７−２に示すフローに従って処理する。セッションIDからVPN管理テーブル218を参照し、VPN ID 2が選択される。さらに、VPN IDからMAC-VPN対応テーブル214を参照する。リストを端末B111に割り当てたユニキャストアドレス宛に送信した場合、VPN ID 2に対応するMACアドレスbbbは、L2TPパケット908から取得したイーサフレーム907の宛先MACアドレスと一致するため、リストを含むイーサフレーム907は端末B111 に送信される。リストをブロードキャストアドレス宛に送信した場合は、VPN ID 2に対応するMACアドレスbbbにイーサフレームの宛先MACアドレスを書き換え、リストを含むイーサフレーム907を端末B111に送信する。

リストを受信した端末B111は、リストをディスプレイに表示する。ユーザがリストから映像を選択した際に、配信要求を映像配信業者のサーバC114に送信する。本イーサフレーム907の送信元MACアドレスはbbbである。送信された配信要求は、ルータA101のL2転送処理212の図７−１に示すフローに従って処理される。MAC-VPN対応テーブル214を参照し、送信元MACアドレスbbbに対応するVPN ID 2を取得する。VPN ID 2に対応するフィルタエントリテーブル217を参照し、通過であれば、VPN管理テーブル218を参照し、リモートIPアドレスC及びリモートセッションID 5555を取得する。配信要求を含むイーサフレーム907はIP、UDP L2TPヘッダを付与され、VPN117を介して映像配信業者のサーバC114に送信される。映像配信会社のサーバC114は、要求された映像をVPN117を介して端末B111に配信する。映像の配信は、ユニキャストアドレス宛のリスト配信と同様である。

端末メーカのサーバD115は、契約ユーザ宅のPC（端末C112）に、端末に対応するファームプログラム等の更新通知を送信する。プログラムの宛先IPアドレスは、端末に割り当てたユニキャストIPアドレスCCである。プログラム更新通知は、ルータD103に捕捉され、ルータA101、D104間に確立されたVPN118を介してPC（端末C112）に送信される。本L2TPパケット908のIPヘッダ901の送信元IPアドレスはD、L2TPセッションヘッダ902のセッションIDは4000である。

上記L2TPパケットを受信したルータA101は、L2転送処理212を呼び出す。L2転送処理212では、図７−２に示すフローに従って処理する。セッションIDからVPN管理テーブル218を参照し、VPN ID 3が選択される。さらに、VPN IDからMAC-VPN対応テーブル214を参照する。VPN ID 3に対応するMACアドレスcccは、L2TPパケット908から取得したイーサフレーム907の宛先MACアドレスと一致するため、プログラム更新通知を含むイーサフレーム907は端末C112 に送信される。

プログラム更新通知を受信した端末C112は、プログラム更新要求を端末メーカのサーバD115に送信する。本イーサフレーム907の送信元MACアドレスはcccである。送信されたプログラム更新要求は、ルータA101のL2転送処理212の図７−１に示すフローに従って処理される。MAC-VPN対応テーブル214を参照し、送信元MACアドレスcccに対応するVPN ID 3を取得する。VPN ID 3に対応するフィルタエントリテーブル217を参照し、通過であれば、VPN管理テーブル218を参照し、リモートIPアドレスD及びリモートセッションID 6666を取得する。プログラム更新要求を含むイーサフレーム907はIP、UDP L2TPヘッダを付与され、VPN118を介して端末メーカのサーバD115に送信される。端末メーカのサーバD115は、プログラム更新要求を受信し、新規プログラムをVPN118を介して端末C112に送信する。新規プログラムの送信は、プログラム更新通知の場合と同様である。新規プログラムを受信したPC（端末C112）はプログラムを更新する。

図５は端末がホーム網105への接続を切断し、ルータA101がVPNを解放するシーケンスを示している。端末A110は、ホーム網105への接続を切断するために、UPnPのDevice DiscoveryメッセージのAdvertisement: Device unavailableを送信する。Advertisement: Device unavailableは、自端末が利用不可能となることを通知するメッセージであり、SSDPのbyebyeを用いる。

ルータA101は、端末A110が送信したUPnPメッセージを受信すると、UPnP解析処理208を呼び出す。ステップ801から804を処理する。本メッセージのリクエストメソッド1001は、NOTIFYであるので、ステップ804を処理後、ステップ812を処理する。NTSヘッダ1003は、ssdp:aliveではないため、ステップ812の後、ステップ815を処理する。Device availableか否かを判定（ステップ815）は、NTSヘッダ1003がssdp:byebyeか否かで行う。NTSヘッダ1003がssdp:byebye以外の場合は、処理を終了する。NTSヘッダ1003がssdp:byebyeの場合は、MAC-VPN対応テーブル214を参照し（ステップ816）、該当するMACアドレスに対応するSIP URI、IPアドレス、制御コネクションID、セッションIDを取得する（ステップ817）。該当するMAC-VPN対応テーブル214のエントリを削除し（ステップ818）、処理を終了する。

図５に戻り、シーケンスを説明する。UPnP解析処理208で、削除するVPNを取得したルータA101は、L2TP処理213の制御コネクション処理211に処理を引き継ぐ。制御コネクション処理211では、StopCCN(Stop Control Connection Notification)またはCDN(Call Disconnect Notify)を送信し、VPNを解放する。ルータA101、B102間で他に有効なL2TPセッションが確立されている場合にはCDN、確立されていない場合にはStopCCNを送信する。上記シーケンスによってL2TP制御コネクションを解放する。

VPN解放後、SIP処理210に処理を引き継ぐ。SIP処理210では、ステップ615で取得したSIP URIを用いてセッション解放要求（BYEメッセージ）をSIPサーバ119に送信する、BYEメッセージを受信したSIPサーバ119は、ルータB102にBYEメッセージを転送する。BYEメッセージを受信したルータB102は、200OKメッセージをSIPサーバ119に送信し、SIPセッションを解放する。SIPサーバ119は、200OKメッセージをルータA101に転送する。上記シーケンスによってSIPセッションを解放する。

以上により、端末に適切なVPNのSIP URIをルータA101がユーザ情報及び端末情報から解決し、端末に応じたサービス提供事業者へのVPNを確立することが可能となる。さらに、VPN確立過程で作成したVPN-MAC対応テーブルを利用して、各端末毎に適切なVPNにトラヒックを振り分けることが可能となる。

実施例２では、管理サーバ121が存在しない場合に、ルータA101がSIP URIを自動生成する例について説明する。本発明が実施される通信システムを図１３に示す。本通信システムは、ルータA101、B102、C103、D104、ルータAが所属するホーム網105、IP網106、ルータBからDが所属する各サービス提供事業者の網（107、108、109）、ホーム網に所属する端末A110、B111、C112、各サービス提供事業者のサーバ（113、114、115）、SIPサーバ119、サービス提供事業者BのDHCPサーバ120から構成される。ルータA、BはVPN116、ルータA、CはVPN117、ルータA、DはVPN118で接続される。

図１４は、本発明が実施されるシーケンスを示している。ホーム網105のユーザは、予めルータA101に、サービス提供事業者またはプラットホーム事業者と契約したユーザ名などの契約情報を登録しておく。登録した情報は、ルータA101のユーザ情報テーブル216で管理される。また、ルータB102は、サービスを提供するユーザ情報と端末情報とを含むSIP URIと、上記SIP URIに対応するIPアドレスとをREGISTERメッセージを用いてSIPサーバ119に登録する。登録するSIP URIは、SIP URI生成規則テーブル1102に従う。図１１−３にSIP URI生成規則テーブルの構成例を示す。SIP URI生成規則テーブルは、SIP URIを構成する情報要素と、上記情報要素から生成されるSIP URIの生成規則を管理する。さらに、SIP URI生成規則テーブル1102は、サービスを利用するユーザのルータA101と、サービスを提供するサービス提供事業者のルータB102で同一のテーブルを保持する。本実施例では、契約ユーザ名がUSER A、サービスを提供する端末Aの製品名がAA-100、製造者名がHITACHIとして、SIP URI生成規則テーブル1102に従いServiceVPN＠UserA.AA-100.HITACHI.co.jpをContactアドレスと共に登録する。Contactアドレスは、ルータB102のIPアドレスであるBを登録する。

ホーム網105内の端末A110 は、実施例１同様の方法で、ルータA101からIPアドレスaを取得する。端末A110は、ルータA101から取得したIPアドレスaを利用して、実施例１と同様に、UPnP Device DiscoveryメッセージのAdvertisement: Device availableを送信する。

ルータA101は、端末A110が送信したUPnPメッセージを受信すると、UPnP解析処理208を呼び出す。図１５に本実施例におけるUPnP解析処理208の処理フローを示す。受信したUPnPメッセージは、Advertisement: Device availableであるので、ステップ801から804及び、ステップ812から814を処理し、HTTP GETリクエストを端末A110に送信し、処理を終了する。

図１４に戻りシーケンスを説明する。HTTP GETリクエストを受信した端末A110は、200 OKのレスポンスコードと共に、UPnP Device DescriptionメッセージをルータA101に送信する。ルータA101は、UPnPメッセージを受信すると、UPnP解析処理208を呼び出す。本メッセージはUPnP Device Descriptionメッセージであるので、ステップ801から806を処理し、Device Descriptionメッセージに含まれるmanufactureヘッダ1005及びmodelNameヘッダ1006から、端末A110の製造者名（HITACHI）及び、製品名(AA-100)等の端末情報を取得する。manufactureヘッダ1005及びmodelNameヘッダ1006はUPnP Device Descriptionメッセージには必須な情報であり、記述がない場合には処理を終了する。

端末情報取得後、SIP URI生成規則テーブル1102を参照し（ステップ1501）、SIP URI生成に必要な情報要素を確定する。本実施例では、契約ユーザ名、製品名、製造者名が必要なため、ユーザ情報テーブル217を参照し、契約ユーザ情報を取得する（ステップ1502）。SIP URI生成規則に従い、ステップ806で取得した製品名、製造者名、ステップ1502で取得した契約ユーザ名を利用して、SIP URI（ServiceVPN＠UserA.AA-100.HITACHI.co.jp）を生成する（ステップ1503）。ステップ802で取得したMACアドレスaaa及び、ステップ1503で生成したSIP URIをMAC-VPN対応テーブル213に設定し（ステップ811）、処理を終了する。

上記処理により、ルータA101は、端末が接続するVPNのSIP URIを生成する。以後の処理は、実施例１と同様である。以上により、管理サーバ121が存在しない場合でも、ルータA101はSIP URIを自動生成し、端末に応じたサービス提供事業者へのVPNを確立することが可能となる。さらに、VPN確立過程で作成したVPN-MAC対応テーブルを利用して、各端末適切なVPNにトラヒックを振り分けることが可能となる。

実施例３では、ホーム網内の端末が接続するVPNのSIP URIを通知する例について説明する。本発明が実施される通信システム及びシーケンスは、実施例２と同様である。

ルータB102は、サービスを提供するユーザの端末A110が通知するSIP URIと同様のSIP URIと、上記SIP URIに対応するIPアドレスとをREGISTERメッセージを用いてSIPサーバ119に登録する。本実施例では、SIP URIをserviceVPN@AA-100.HITACHI.co.jpとし、ContactアドレスとしてルータB102のIPアドレスであるBをREGISTERメッセージを用いて登録する。

ホーム網105内の端末A110 は、実施例１、２と同様の方法で、ルータA101からIPアドレスaを取得する。端末A110は、ルータA101から取得したIPアドレスaを利用して、実施例１と同様に、UPnP Device DiscoveryメッセージのAdvertisement: Device availableを送信する。

ルータA101は、端末A110が送信したUPnPメッセージを受信すると、UPnP解析処理208を呼び出す。図１６に本実施例におけるUPnP解析処理208の処理フローを示す。受信したUPnPメッセージは、Advertisement: Device availableであるので、ステップ801から804及び、ステップ812から814を処理し、HTTP GETリクエストを端末A110に送信し、処理を終了する。

図１４に戻りシーケンスを説明する。HTTP GETリクエストを受信した端末A110は、200 OKのレスポンスコードと共に、UPnP Device DescriptionメッセージをルータA101に送信する。ルータA101は、UPnPメッセージを受信すると、UPnP解析処理208を呼び出す。本メッセージはUPnP Device Descriptionメッセージであるので、ステップ801から805を処理し、端末A110が送信したDevice Descriptionメッセージを取得する。図１７にDevice Descriptionメッセージの記述例を示す。通常のDevice Descriptionメッセージの他に、ServiceVPNヘッダ1701が規定されており、端末A110が接続するVPNのSIP URIが記述されている。ルータA101のUPnP解析処理208は、ステップ1601でDevice Descriptionメッセージで通知された、端末が接続するVPNのSIP URIを取得する。ステップ802で取得したMACアドレス及び、ステップ1601で取得したSIP URIをMAC-VPN対応テーブル214に設定し（ステップ811）、処理を終了する。

上記処理により、ルータA101は、端末が接続するVPNのSIP URIを取得する。以後の処理は、実施例１、２と同様である。以上により、端末がサービスを提供するVPNのSIP URIを自ら通知する場合に、通知されたSIP URIを用いて端末に応じたサービス提供事業者へのVPNを確立することが可能となる。さらに、VPN確立過程で作成したVPN-MAC対応テーブルを利用して、各端末適切なVPNにトラヒックを振り分けることが可能となる。

実施例４では、UPnPに対応してない端末を適切なVPNへルータAが振り分ける場合、またはUPnPを利用しない場合について説明する。本発明が実施される通信システムは、実施例２と同様である。

図１８は、本発明が実施されるシーケンスを示している。ルータA101には、ホーム網105に接続する端末のうち、サービス提供事業者の網へ接続する必要のある端末のMACアドレスとSIP URIを事前にMAC-VPN対応テーブル214に登録する。図１の通信システムでは、端末A110、B111、C112のMACアドレスとSIP URIを登録する。SIP URIはサービス提供事業者がサービスを利用するユーザに書面等で事前に通知するものとする。また、各サービス提供事業者B、C、DのルータB、C、Dは各サービス提供事業者が提供するVPNのSIP URIと、上記SIP URIに対応するIPアドレスとをREGISTERメッセージを用いてSIPサーバ119に登録する。

MACアドレス及びSIP URIの登録後、ルータA101はSIP処理210を呼び出す。SIP処理210はMAC-VPN対応テーブル214に登録されたSIP URIをもとにSIPセッションを確立する。SIPセッション確立後の処理は、実施例１と同様である。

以上により、端末がUPnPをサポートしない場合でも、ルータA101は、端末に応じたサービス提供事業者へのVPNを確立することが可能となる。さらに、VPN確立過程で作成したVPN-MAC対応テーブルを利用して、各端末適切なVPNにトラヒックを振り分けることが可能となる。

実施例４では、UPnPに対応していない場合またはUPnPを利用しない場合に、端末のSIP URIを、管理サーバ121を利用して解決し、端末からのトラヒックを適切なVPNへルータAが振り分ける例について説明する。本発明が実施される通信システムは実施例１と同様である。

図１９は、本発明が実施されるシーケンスを示している。
管理サーバ121は、SIP URI管理テーブル1101を管理する。SIP URI管理テーブルは、契約ユーザ情報及び端末情報に対応するSIP URIを管理するためのテーブルである。
サービス提供事業者のルータB102は、サービスを提供するユーザの端末A110が通知するSIP URIと同様のSIP URIと、上記SIP URIに対応するIPアドレスBとをREGISTERメッセージを用いてSIPサーバ119に登録する。一方、ホーム網105のルータAには、契約ユーザ情報、端末情報（端末のMACアドレス、製造番号、製造者名）を登録しておく。契約ユーザ情報は、ユーザ情報テーブル216、端末情報は、ルータA110の端末情報管理テーブル1104に登録される。図１１−４に端末情報管理テーブルの構成例を示す。端末情報管理テーブル1104は、端末と端末のMACアドレスとを関連付けるためのテーブルであり、端末を識別するための値であれば、製造番号と製造者名以外の値を用いてもよい。例えば、UPnPのUUIDや、製造者やサービス提供事業者が独自に割り振った値でもよい。

ルータA101には、契約ユーザ情報及びホーム網105内の端末の情報が登録されると、管理サーバ121にSIP URI要求を送信する。SIP URI要求には、少なくともVPNのSIP URIを解決したい端末情報（製造番号、製造者名）及び契約ユーザ情報が含まれる。端末情報のみでSIP URIが一意に決まらない場合は、サービスを利用するユーザのID及び、端末の製造メーカ、サービス提供事業者などの付加情報を含めてもよい。SIP URI要求を受信した管理サーバ121は、SIP URI管理テーブル1101を参照し、要求されたユーザ、端末情報に対応するSIP URIを特定する。特定したSIP URIをSIP URI応答として、ルータA101に通知する。ルータA101は、通知されたSIP URIとSIP URI要求を行った端末に対応するMACアドレスとをMAC-VPN管理テーブル214に登録する。MACアドレス及びSIP URIの登録後、ルータA101はSIP処理210を呼び出す。SIP処理210はMAC-VPN対応テーブル214に登録されたSIP URIをもとにSIPセッションを確立する。以後の処理は、実施例１と同様である。

以上により、端末がUPnPをサポートしない場合でも、サービスを利用するユーザは、ルータA101にSIP URIを登録することなく、ルータA101は、端末に応じたサービス提供事業者へのVPNを確立することが可能となる。さらに、VPN確立過程で作成したVPN-MAC対応テーブルを利用して、各端末適切なVPNにトラヒックを振り分けることが可能となる。

本発明が実施される通信システムを示した概念図。 本発明で用いられるCEルータの内部構成（３−１）と内部処理（３−２）を示した概念図。 MAC-VPN対応テーブル（３−１）、フィルタエントリテーブル（３−２）、ユーザ情報テーブル（３−３）、フィルタエントリテーブル（３−４）、VPN管理テーブル（３−５）を示した概念図。 本発明が実施される様子を示したシーケンス図。 本発明が実施される様子を示したシーケンス図。 DHCP処理を示すフローチャート。 L2転送処理を示すフローチャート。 UPnP処理を示すフローチャート。 L2転送処理で処理されるパケットの概念図。 Device availableメッセージ（１０−１）、Device unavailableメッセージ（１０−２）、Device Descriptionメッセージ（１０−３）の記述例。 SIP URI管理テーブル（１１−１、１１−２）、SIP URI生成規則テーブル（１１−３）、端末情報管理テーブル（１１−４）の概念図。 端末制御のシーケンス例。 管理サーバが存在しない場合に、本発明が実施される通信システムを示した概念図様子を示したシーケンス図。 管理サーバが存在しない場合に、本発明が実施される様子を示したシーケンス図。 管理サーバが存在しない場合のUPnP処理を示すフローチャート。 端末がSIP URIを通知する場合のUPnP処理を示すフローチャート。 端末がSIP URIを通知する場合のDevice Descriptionメッセージの記述例。 UPnP非対応の端末で本発明が実施される様子を示したシーケンス図。 UPnP非対応の端末と管理サーバを利用して、本発明が実施される様子を示したシーケンス図。

符号の説明

101…ルータA、102…ルータB、103…ルータC 、104…ルータD、105…ホーム網、106…IP網（インターネット）、107…サービス提供事業者Bの網、108…サービス提供事業者Cの網、109…サービス提供事業者Dの網、110…端末A110、111…端末B111、112…端末C、113…サービス提供事業者BのサーバB、114…サービス提供事業者CのサーバC、115…サービス提供事業者DのサーバD、119…SIPサーバ、120…DHCPサーバB、212…管理サーバ121、201…CPU、202…メモリ、203…バス、204…インタフェース、205…インタフェース、206…回線、207…回線、208…UPnP解析処理、209…DHCP処理、210…L2TP処理、211…制御コネクション処理、212…L2転送処理、213…MAC-VPN対応テーブル、214…SIP処理、215…フィルタエントリテーブル、216…ユーザ情報テーブル、217…フィルタエントリテーブル、218…VPN管理テーブル、901…IPヘッダ、902…UDPヘッダ、903…L2TPセッションヘッダ、904…イーサヘッダ、905…IPヘッダ、906…TCP/UDPヘッダ、907…イーサフレーム、908…L2TPパケット、1001…リクエストメソッド、1002…Locationヘッダ、1003…NTSヘッダ、1004…rootヘッダ、1005…manufactureヘッダ、1006…modelNameヘッダ、1007…serialNumberヘッダ、1101…SIP URI管理テーブル、1102…SIP URI生成規則テーブル、1104…端末情報管理テーブル、1701…serviceVPNヘッダ。

Claims (9)

1. 端末と他の通信装置と管理サーバとに接続された通信装置であって、
   上記他の通信装置とVPNを介して接続された第一のインタフェースと、
   上記端末と接続された第二のインタフェースと、
   上記端末のMACアドレスと上記VPNを識別するVPN情報との対応関係を記憶する記憶部と、
   上記端末が送信するデータの転送先VPNを上記対応関係に基づいて決定する制御部と、を有し、
   上記端末から受信するパケットに含まれる製品情報を上記管理サーバに送信し、上記管理サーバから上記製品情報に対応するSIP URIを取得し、該取得したSIP URIに基づいてVPN情報を取得することを特徴とする通信装置。
2. 請求項１記載の通信装置であって、
   上記端末から受信した情報に基づいて、上記対応関係を自動生成することを特徴とする通信装置。
3. 請求項１記載の通信装置であって、
   上記対応関係は、上記端末から受信したものであることを特徴とする通信装置。
4. 請求項３記載の通信装置であって、
   上記対応関係は、UPnPのデバイスディスクリプションメッセージを用いて上記端末から受信したものであることを特徴とする通信装置。
5. 請求項１記載の通信装置であって、
   上記対応関係の入力を外部から受け付ける入力インタフェースを有することを特徴とする通信装置。
6. 請求項１記載の通信装置であって、
   上記端末インタフェース情報は、上記端末のMACアドレスであることを特徴とする通信装置。
7. 請求項１記載の通信装置であって、
   上記VPN情報は、L2TPの制御コネクションID及びセッションIDであることを特徴とする通信装置。
8. 請求項１記載の通信装置であって、
   さらに、上記対応関係に基づいて生成された上記VPNごとのフィルタリング情報を保持し、
   上記フィルタリング情報に基づいて、上記端末が送受信するデータを廃棄するか転送するかを決定することを特徴とする通信装置。
9. 請求項１記載の通信装置であって、
   複数の上記端末、及び複数の上記他の通信装置と接続されており、
   さらに上記他の通信装置とは複数のVPNを介して接続されており、
   上記記憶部には、上記複数の端末及び上記複数の他の通信装置についての上記対応関係が記憶されており、
   さらに上記対応関係に基づいて生成された上記VPNごとのフィルタリング情報を保持し、
   上記フィルタリング情報に基づいて、上記複数の端末のいずれかと、上記複数の他の通信装置のいずれかとの間で上記複数のVPNのいずれかを介して送受信されるデータを廃棄するか転送するかを決定することを特徴とする通信装置。

Images