JP4543097B2 - セッションアウェア接続制御方法および装置 - Google Patents

Description

本発明は異種環境にわたってユニキャストセッションとマルチキャストセッションの接続を制御する技術に関する。

次世代無線ネットワークは異種環境（heterogeneous environments）にわたる多種多様なリアルタイムのグループ通信サービスをサポートするものであることが想定される。そのようなネットワークトではホストまたはネットワークは異なるトランスポート技術をサポートすることができることになる。複数のユーザを対象とするサービス、例えばモバイルＩＰＴＶ、ファイル配信およびプッシュメディア（push media）などのサービスは、フローの集合から構成され、複数のモバイルユーザに同時に配信することができる。それゆえ、トランスポート（データ配送）の点から見て、マルチキャスト（multicast）はセッションのコンテンツを複数のユーザに配信する（マルチユーザセッション）際に最適な技術であり、パケットの重複を避け、ネットワーク資源を節約することができる（例えば非特許文献１参照）。

しかしながら、ディストリビューション・ツリー（distribution tree）（例えばローカルな範囲のマルチキャストツリー）を生成するローカルスキームを有するドメインと、アドレス体系が同じまたは異なるモバイルユーザおよびオペレータとが存在するために、セッションパス（session path）におけるディストリビューション・ツリーのエンドツーエンドの接続を制御し、セッション通信時における通信途絶点を避けるようなメカニズムが必要とされる。ドメインは、例えばＩＰマルチキャスト分野では、ＡＳＭ（Any-Source Multicast、例えば非特許文献２参照）、ＳＧＭ（Small-Group Multicast、例えば非特許文献３参照）またはＳＳＭ（Source-Specific Multicast、例えば非特許文献４参照）に対応している場合がある。加えて、次世代無線ネットワークは（例えばリンク障害、ユーザのモバイル性およびネットワークの輻輳などにより）動的かつ予測不可能なものとなり、ディストリビューション・ツリーは断片化されるかまたは非効率的なものになる可能性がある（例えば、同じマルチホームアクセスドメイン（multi-homed access domain）において同一のセッションに対して２つ以上の入口ポイントが存在する場合）。この意味において、長いディストリビューション・ツリーの構築が可能となるように、効率的な形状を有するドメイン間ディストリビューション・ツリーを生成することが要求される。

異種環境にわたる固定またはモバイルのユーザのグループへのマルチユーザセッションの配信は、集中または分散したエージェントがマルチキャストドメイン間のトンネルを生成する責務を負う状況に対して解決されており、非マルチキャストネットワーク上においてマルチキャストセッションのコンテンツの配信（dissemination）が可能である。これらのソリューションはＩＰマルチキャスト能力を有するネットワークおよびホストに焦点を置いており、それらの利用をＩＰマルチキャストサポートのあるネットワークに接続したマルチキャストアウェアな（multicast-aware：マルチキャストを認識しうる）ユーザまたはモバイルのユーザのみに制限している。それと同時に、従来のアプローチではユニキャストリンクで送られたマルチキャスト・パケットをカプセル化および／または脱カプセル化するためにエンドユーザに独自のエージェントを導入する必要があり、システムの柔軟性が低下する。さらに、他のソリューションは同じアドレス体系と異なるアドレス体系を有するネットワーク間のセッションの接続をサポートしていない。これらの場合に含まれる一例は、異なるスキームを使用してマルチキャストツリーを生成する、マルチキャストモデルが同じドメイン間の接続である。さらに、既存のアプローチでは異種環境にわたる効率的な形状を有するディストリビューション・ツリーの構築はサポートされていない。

異種環境にわたる固定またはモバイルのユーザのグループへのマルチユーザセッションの配信の問題を解決するには、同じアドレス体系と異なるアドレス体系を有するドメイン間のマルチユーザセッションの接続をモバイルのエンドユーザまたはネットワーク技術に関係なく制御するセッションアウェアな（session-aware：セッションを認識しうる）メカニズムが必要である。さらに、そのメカニズムは好ましくはドメイン間ディストリビューション・ツリーの形状（shape）を制御するほかにホストもしくはネットワークのモバイル性またはネットワークの障害に起因するセッションパス全体の再構築を避ける必要がある。さらに、斯かる接続制御メカニズムは好ましくはエンドユーザへの独自のモジュールの導入または標準規格（スタンダード）の変更を避けるものであるべきである。加えて、オープンインタフェースを利用することが好ましく、それにより、異なるプロトコルおよびメカニズムとの容易な相互作用と直接的な展開が同時に可能となる。

これまでもいくつものアプローチによって同じまたは異なるアドレス体系を有するドメイン間のセッションの接続の問題が取り組まれてきた。しかしながら、既存のソリューションは、ユニキャスト・パケットをマルチキャスト・パケットへマップし、逆にマルチキャスト・パケットをユニキャスト・パケットへマップするために、エンドホストへのエージェントの導入またはＩＥＴＦ標準の修正を必要とし、このためにシステムとネットワークにおけるそれらの配置の柔軟性が低下する（例えば非特許文献５または特許文献１参照）。さらに、いくつかのソリューションはユニキャストリンクでマルチキャストユーザにマルチキャスト・パケットを送信するためにトンネルベースのアプローチを使用し、その結果、それらの利用がマルチキャストアウェアなネットワークに配置されたマルチキャストホストのみに制限される（例えば非特許文献６参照）。マルチキャスト・パケットからユニキャスト・パケットへの一方向変換（unidirectional translation）は特許文献２に概説されており、その逆の手続きは特許文献３に記述されている。しかしながら、一方向変換ソリューションは異種環境では適切に機能しない。

加えて、変換ベースの（translation-based）アプローチでは、マルチキャスト・パケットをユニキャスト・パケットに変換し、逆にユニキャスト・パケットをマルチキャスト・パケットに変換することによって、非マルチキャストリンクでマルチキャストコンテンツを配信することを可能にするために、ネットワークの特定の場所にあるエージェントを利用する（非特許文献７参照）。しかしながら、このスキームはエンドホストおよびアクセスネットワークの両方がＩＰマルチキャスト能力を備えることを必要とする。さらに、他の変換ベースのソリューションは同じアドレス体系を有するネットワーク間におけるセッションの接続を実現しない（例えば特許文献４参照）。この接続スキームの１つの例として、エンドツーエンドセッションパスにおいて同じディストリビューション・ツリーに関連したいくつかのドメインによってサポートされる異なるマルチキャストツリーのリンケージ（linkage）が挙げられる。ＰＩＭ−ＳＭ（PIM Sparse Mode）モデルに基づくドメイン間のＩＰｖ６マルチキャストセッションの変換が非特許文献８に提案されている。しかしながら、この提案ではアドレス体系が異なるドメイン間のセッションの接続をサポートしていない。また無線ネットワークに接続されたユーザへのユニキャストまたはマルチキャストセッションコンテンツの配信は非特許文献９と非特許文献１０に提示されている。一番目の提案にはレイヤ３マルチキャスト・パケットからレイヤ２マルチキャスト・パケットへの変換のみが存在し、二番目の提案にはＩＰｖ６パケットのＩＥＥＥ８０２．１５．４パケットへのマッピングとその逆のマッピングが存在する。しかしながら、これらのソリューションは両方ともユニキャストドメインとマルチキャストドメインとの間のパケット変換をサポートしていない。最後に、非特許文献１１は、マルチキャストソースのマルチキャストネットワークへのモバイル性に起因するマルチキャストツリー全体の再構築を避けるための、マルチキャストアウェアな環境に焦点を置く、トンネルベースの（tunnel-based）ソリューションを提案している。それでもなお、このスキームはＰＩＭ−ＳＭランデブーポイント（PIM-SM Rendezvous Point）の変更とモバイル機器に関する変更を必要とし、異種環境間のセッションの接続を許容しない。
欧州特許第１６８０８８６号明細書 米国特許第７０７９４９５（Ｂ１）号明細書、２００６年７月出願（E. Pearce, D. Whetten and L. Michalewicz, "System and Method for Enabling Multicast Telecommunications", Application Patent Number US7079495 B1, July 2006） 米国特許第７０８２１４２（Ｂ１）号明細書、２００５年７月出願（L. Begeja, "System and Method for Delivering Content in a Unicast/Multicast Manner", Application Patent Number US708142 B1, July 2005） 米国特許第７０３１３２６（Ｂ１）号明細書、２００６年４月出願 技術仕様書ＲＦＣ３１７０ 技術仕様書ＲＦＣ３６７８ R. Boive, N. Feldman and C. Metz, "Small Group Multicast: A New Solution for Multicasting on the Internet", IEEE Internet Computing, vol. 4, issue: 3, May 2000, pp. 75-79 技術仕様書ＲＦＣ４６０７ J. Park et al, "Multicast Delivery Based on Unicast and Subnet Multicast", IEEE Communications Letters. Vol. 5, N. 4, April 2001, pp 181-183 B. Zhang, S. Jamin and L. Zhang, "Host Multicast: A Framework for Delivering Multicast to End Users", Proceedings of the Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies - INFOCOM 2002. June 2002, pp. 1366-1375 D. Thaler et al, "Automatic IP Multicast without Explicit Tunnels (ATM)", IETF Internet Draft, October 2005 M. In et all, "An Efficient Mechanism for Multicast Deployment in IPv6", The 8th International Conference Advanced Communication Technology (ICACT 2006),Vol. 03, February 2006, pp. 2008-2011 W. Park et al "An Implementation of the Broadband Home Gateway Supporting Multi-Channel IPTV Service", Proceeding of IEEE 10th International Symposium on Consumer Electronics - ISCE 2006, June 2006, pp. 1-5 S. Sakane et all, "A Translation method between 802.15.4 nodes and IPv6 nodes". Proceedings of the International Symposium on Applications and the Internet Workshop (SAINTW'06), January 2006, pp. 34-37 I. Romdhani, H. Bettarhar and A. Bouabdallah, "Transparent Handover for Mobile Multicast Sources", IEEE International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies, April 2006, pp. 145-152

このコンテクストでは、既存のソリューションは同じアドレス体系と異なるアドレス体系を有するドメイン間のマルチユーザセッションの接続を制御するための全ての要件は満たさない。さらに、従来の提案では、ディストリビューション・ツリーの形成はマルチキャストアウェアな環境に制限されている。最後に、エンドホストまたは標準において変更を行うこと、および、トンネルベースのアプローチを利用することは、提案されたシステムとそれらの実現可能な展開の柔軟性を低下させる。そこで本発明の課題はこれらの問題点を効率的かつ経済的に克服することができる技術を提供することにある。

本発明は、上記課題を解決するため、異種ネットワークのドメイン間の境界に位置するネットワークエージェントが異種ネットワークにおけるエンドツーエンドのセッションアウェアな接続の制御を実行するための方法を提供する。本方法は、
エンドツーエンドのパスにおいて一意のグローバルセッション識別子を、各マルチユーザセッションに割り当てるステップと、
ユニキャストセッションまたはマルチキャストセッションの送信機（sender）が、グローバルセッション識別子を含む利用可能なセッションについての情報とセッションフローおよび送信元（source）アドレスについての情報とを、受信機（receiver）がそれらのセッションへの参加を申し込むことができるように、それが接続された先のまたはそれが移動する先のネットワークエージェントに発行（publish）するステップと
を有し、
更なるネットワークエージェントが前記セッションパスにあり、前記ネットワークエージェントは、
ドメイン内または該ドメイン間においてマルチユーザセッションフローが関連付けられるローカルチャネル識別子の割当の要求を可能にするためのアドレス割当コントローラ・インタフェースを具備しており、
本方法は、ネットワークエージェントが関連付けられているドメイン内または該ドメイン間における現セッションについてのセッションごとおよびフローごとの状態を含んでいるマルチユーザセッションについての状態を保持するステップを更に有し、
前記ネットワークエージェントが前記セッションパスに分散していて、本方法は、
入口ネットワークエージェントが前記送信元から１つ以上のセッションを受信し、前記送信元からの当該セッションについての情報を発行し、その情報を、更なるネットワークエージェントを通じて受信機に向けてダウンストリームに転送するステップと、
受信機からアプリケーション・プロトコルに従ってこの受信機がセッションへの参加の意思があることを示す参加申込メッセージを、アクセスエージェントを介して前記送信元に向けて送信し、そのメッセージを、前記セッションパス内に位置するネットワークエージェントを通じて前記送信元に向けてアップストリームに転送するステップと、
前記リクエストが受信された各ネットワークエージェントにおいて、要求されたセッションが既にそのネットワークエージェントによって受信されているかどうかを前記状態情報をクエリーすることによって確認し、受信されていない場合には、前記参加申込メッセージを更にアップストリームに転送するステップと、
あるネットワークエージェントによって前記セッションが受信されていることが分かった場合には、前記参加申込メッセージをアップストリームに転送することを停止するとともに前記セッションが受信機に向けて既にアクティブになっているかどうかを確認するステップと、
前記確認の結果が肯定的である場合には、前記アクセスエージェントが属するドメインのネットワークエージェントに向けて、前記参加申込メッセージをダウンストリームに転送するステップと、
前記確認の結果が否定的な場合には、
ａ）前記アドレス割当コントローラ・インタフェースから、ダウンストリームのセッションフローへのチャネル識別子の割当を要求し、前記ネットワークエージェントの発信インタフェーステーブルを受信機に向けた次のネットワークエージェントの前記チャネル識別子とアドレスとによって更新するサブステップと、
ｂ）受信機に向かってダウンストリームにある次のネットワークエージェントにおいて、到来インタフェーステーブルをセッション識別子およびチャネル識別子についての情報によって更新し、ダウンストリームセッションフローへのチャネル識別子の割当を要求し、ネットワークエージェントの発信インタフェーステーブルをそのチャネル識別子とアドレスとによって更新するサブステップとを実行するステップと、
前記アクセスエージェントに到達したかどうかを確認して、到達していない場合には、前記アクセスエージェントに到達するまでサブステップａ）およびサブステップｂ）を繰り返すステップと、
前記アクセスエージェントに到達した場合には、前記アドレス割当コントローラ・インタフェースから、ダウンストリームのセッションフローへのチャネル識別子の割当を要求し、前記ネットワークエージェントの発信インタフェーステーブルをそのチャネル識別子によって更新し、受信機がこのアクセスエージェントを介して前記セッションに参加するステップとを有する。

本方法は異種ネットワーク（heterogeneous networks）にわたるエンドツーエンドのセッションアウェア接続制御方法を実現する。既存のディストリビューション・ツリー（distribution trees）が可能な限り利用され、このため効率性が高まる。

本方法は、１つの態様として、ネットワークエージェントを通じてセッションを確立するための参加申込メッセージまたはリクエストメッセージを転送するステップと、
前記メッセージが受信された各エージェントにおけるセッションおよびフローと関連付けられた状態をクエリーするステップと、
ネットワークエージェントが、要求されたマルチユーザセッションフローの接続がアップストリームおよび／またはダウンストリームのセッションパスに向けて既にアクティブにされていることを前記クエリーから検出したら、エンドツーエンドではなくそれ自体と宛先に向かってアップストリームおよび／またはダウンストリームにおける次のエージェントとの間のパスにおける接続を構築または再構築することを試みるステップと
を更に含み、前記参加申込メッセージは新しくセッションに参加するために受信機によって送信されたメッセージであり、前記リクエストメッセージは新しいアクセスエージェントに移動した送信元によって送信されたメッセージである。

これにより、送信元（source）が移動する場合でも、既存のセッションおよびリンクを新たな参加申込リクエスト（subscription requests）に利用することができる。

本方法は、１つの態様として、ユニキャストアウェア（unicast-aware：ユニキャストを認識しうる）なドメイン内または該ドメイン間リンク内の２つ以上のネットワークエージェントが同じセッションフローを要求する場合において、パケットを変換し、それらをこれらのネットワークエージェントに複製するステップを更に含む。

１つの態様として、前記保持された状態情報はセッションフローを要求した受信機のドメイン識別子とその受信機のドメインに向けたセッションに関連するダウンストリームエージェントのアドレスとについての情報を含み、本方法は、
ネットワークエージェントがセッションフローのリクエストを受信した場合には、その状態のクエリーに基づいてそのセッションフローが当該リクエスタのドメインに既に存在しているかどうかを確認するステップと、
接続が既に存在している場合には、そのメッセージをそれが当該リクエスタのドメインの入口エージェントに到達するまで次のダウンストリームエージェントに転送するステップと、
当該参加リクエストが新たなアクセスエージェントまたは受信機からのものである場合には、その新たなネットワークエージェントまたは受信機に向けたチャネル識別子の割当を要求するとともに、発信インタフェーステーブルをその新たなネットワークエージェントまたは受信機についての情報によって更新するステップと
を更に含む。

１つの態様として、前記ネットワークエージェントは、
パケットを、マルチキャストからユニキャストへ変換するためのモジュールと、マルチキャストからマルチキャストへ変換するためのモジュールと、ユニキャストからユニキャストへ変換するためのモジュールをサポートする接続制御モジュールを更に具備し、本方法は、
異なるマルチキャストスキームの間の接続、マルチキャストスキームとユニキャストスキームとの間の接続、および１つのユニキャスト送信元と複数のユニキャスト受信機との間の接続を可能とするために、前記モジュールがパケットを適切に変換し、必要に応じてそれらを複製するステップを更に含む。

１つの態様として、更なる受信機が既にアクティブなセッションへの参加申込メッセージを同じアクセスエージェントを介して送信する場合、このアクセスエージェントはその発信インタフェーステーブルを前記更なる受信機のポートおよび宛先ＩＰアドレスを含めることによって更新し、前記既にアクティブなセッションから到来するパケットを複製してそれらを前記更なる受信機へ転送する。

１つの態様として、セッションのパス（経路）は複数のドメインを通過し、前記ネットワークエージェントは前記複数のドメインの境界に位置している。

本発明は、上記課題を解決するため、異種ネットワークのドメイン間の境界に位置するネットワークエージェントが異種ネットワークにおけるエンドツーエンドのセッションアウェアな接続の制御を実行するための装置も提供する。本装置は、
エンドツーエンドのパスにおいて一意のグローバルセッション識別子を、各マルチユーザセッションに割り当てるためのモジュールと、
ユニキャストセッションまたはマルチキャストセッションの送信機が、グローバルセッション識別子を含む利用可能なセッションについての情報とセッションフローおよび送信元アドレスについての情報とを、受信機がそれらのセッションへの参加を申し込むことができるように、それが接続された先のまたはそれが移動する先のネットワークエージェントに発行するためのモジュールと
を有し、
更なるネットワークエージェントが前記セッションパスにあり、前記ネットワークエージェントは、ドメイン内または該ドメイン間においてマルチユーザセッションフローが関連付けられるローカルチャネル識別子の割当の要求を可能にするためのアドレス割当コントローラ・インタフェースを具備し、
本装置は、ネットワークエージェントが関連付けられているドメイン内または該ドメイン間における現セッションについてのセッションごとおよびフローごとの状態を含んでいるマルチユーザセッションについての状態を保持するためのモジュールを更に有し、
前記ネットワークエージェントが前記セッションパスに分散していて、
本装置は、
入口ネットワークエージェントが前記送信元から１つ以上のセッションを受信し、前記送信元からの当該セッションについての情報を発行し、その情報を、更なるネットワークエージェントを通じて受信機に向かってダウンストリームに転送するためのモジュールと、
受信機からアプリケーション・プロトコルに従ってこの受信機がセッションへの参加の意思があることを示す参加申込メッセージをアクセスエージェントを介して前記送信元に向けて送信し、そのメッセージを、前記セッションパス内に位置するネットワークエージェントを通じて前記送信元に向けてアップストリームに転送するためのモジュールと、
前記リクエストが受信された各ネットワークエージェントにおいて、要求されたセッションが既にそのネットワークエージェントによって受信されているかどうかを前記状態情報をクエリーすることによって確認し、受信されていない場合には、前記参加申込メッセージを更にアップストリームに転送するためのモジュールと、
あるネットワークエージェントによって前記セッションが受信されていることが分かった場合には、前記参加申込メッセージをアップストリームに転送することを停止するとともに前記セッションが受信機に向けて既にアクティブになっているかどうかを確認するためのモジュールと、
前記確認の結果が肯定的である場合には、前記参加申込メッセージを前記アクセスエージェントが属するドメインのネットワークエージェントに向かってダウンストリームに転送するためのモジュールと、
前記確認の結果が否定的な場合には、
ａ）前記アドレス割当コントローラ・インタフェースから、ダウンストリームのセッションフローへのチャネル識別子の割当を要求し、前記ネットワークエージェントの発信インタフェーステーブルを受信機に向けた次のネットワークエージェントの前記チャネル識別子とアドレスとによって更新するためのステップと、
ｂ）受信機に向かってダウンストリームにある次のネットワークエージェントにおいて、到来インタフェーステーブルをセッション識別子およびチャネル識別子についての情報によって更新し、ダウンストリームセッションフローへのチャネル識別子の割当を要求し、ネットワークエージェントの発信インタフェーステーブルをそのチャネル識別子とアドレスとによって更新するためのステップとを実行するためのモジュールと、
前記アクセスエージェントに到達したかどうかを確認して、到達していない場合には、前記アクセスエージェントに到達するまでステップａ）およびステップｂ）を繰り返すためのモジュールと、
前記アクセスエージェントに到達した場合には、前記アドレス割当コントローラ・インタフェースから、ダウンストリームのセッションフローへのチャネル識別子の割当を要求し、前記ネットワークエージェントの発信インタフェーステーブルをそのチャネル識別子によって更新し、受信機がこのアクセスエージェントを介して前記セッションに参加するためのモジュールと
を有する。

本装置は、更なる態様として、本装置が本発明の上記いずれかの態様の方法に従って動作することを可能にするモジュールを更に具備する。

以下、本発明の実施の最良の形態を添付図面を参照して詳細に説明する。実施形態の説明を開始する前に、最初に本明細書の中で使用される用語について説明する。

ドメイン（domain）：単一の管理団体に代わって共通のネットワーク管理者によってコントロールされる単一ネットワークまたはネットワーク群。

ダウンストリーム（downstream）：データフローと同じ方向。

アップストリーム（upstream）：データフローとは逆の方向。

セッション（session）：ユーザ（またはユーザエージェント）とピア（peer）との間の通信を規定する。セッションは１つのフローまたはフローの集合によって構成することができる。

マルチユーザセッション（multi-user session）：数人のユーザが同時に受信することができる相互に関連するフローの集合によって構成されるセッション。

ディストリビューション・ツリー（distribution trees）：１つのドメイン内またはドメイン間においてセッションのフローが関連付けられたユニキャストフローの集合またはマルチキャストツリー。

ドメイン識別子（domain identifier）：同じドメインに属するエージェントの集合を識別するために使用される一意の識別子で、マニュアル設定または何らかの自己組織化スキームを用いて定義される。

セッション識別子（session identifier）：エンドツーエンドパスにおいてセッションを識別するために使用されるグローバルかつ一意の値。

チャネル識別子（channel identifier）：１つのドメイン内または複数のドメイン間にわたる各セッションフローを識別するために使用される値の集合。例えば、ユニキャストドメインでは、チャネル識別子は、送信元と宛先のＩＰアドレスのペア、送信元と宛先のポートのペア、およびトランスポートプロトコルの番号によって構成することができる。

本発明の実施形態は、以下ＳＥＡＣＯＮと呼ぶセッションアウェア接続制御（Session-aware Connectivity Control）のメカニズムに関する。このメカニズムは異種環境にわたってマルチユーザセッションのフローと関連付けられたディストリビューション・ツリーのセッションレベルのマルチユーザセッション接続を実行する。このときエンドユーザおよび／またはネットワークの機器は、エンドホストまたは標準に関する変更なしに、同じトランスポート技術および／または異なるトランスポート技術をサポートしている。それゆえ、ユーザはマルチユーザセッションのコンテンツを機器またはネットワークのトランスポート技術とは無関係に受信することができる。例えば、ＳＥＡＣＯＮメカニズムは、ユニキャストドメインからマルチキャストドメインへおよびマルチキャストドメインからユニキャストドメインへのマルチユーザセッションのリンケージのほか、マルチキャストおよびユニキャストドメイン間のマルチユーザセッションの接続を提供する。さらに、ＳＥＡＣＯＮメカニズムは同一または異なるアドレス体系を有するマルチキャストドメイン間の変換（translation）を提供する。両方のケースにおいてＳＥＡＣＯＮは異なるドメインにおいて構築されたマルチキャストツリーのリンケージを可能にする。これはエンドツーエンドのマルチキャストが、異なるマルチキャストツリーの連結（concatenation）によって実行されることを意味する。

さらに、実施の一形態におけるＳＥＡＣＯＮメカニズムはディストリビューション・ツリーのドメイン間形成も制御する。これは可能な限りユーザに近いところにブランチポイントを有するディストリビューション・ツリーの構築を目的とする。また本提案のメカニズムは、受信機、送信機またはネットワークのモバイル性のほかにネットワーク故障に起因するセッションパス全体の再構築を回避する。このコンテクストにおいて、実施の一形態におけるＳＥＡＣＯＮメカニズムによれば、マルチユーザセッションを複数のモバイルのユーザへ同時に配信することが可能となる。このとき各マルチユーザセッションはセッションフロー（session flows）と呼ばれるフローの集合によって構成することができる。

本発明の実施の一形態によるＳＥＡＣＯＮメカニズムは以下のことに基づく。
・ユニキャストまたはマルチキャストセッションの送信機はマルチユーザセッション記述（セッションオブジェクトと呼ばれる）を定義する。このマルチユーザセッション記述は、セッションフロー、送信元アドレスおよびグローバルセッション識別子についての情報のほかに（例えばＳＤＰ（Session Description Protocol、ＲＦＣ２３２７参照）を使って）参加申込（subscription）を可能とするのに十分な情報を含むことができる。
・各マルチユーザセッションはエンドツーエンドパスにおいて一意のグローバル識別子を有する。
・マルチキャストアウェアなドメインにおいてセッションのフローと関連付けられたマルチキャストツリーを制御するためのＩＰマルチキャストプロトコルが存在する。
・ユニキャストまたはマルチキャストセッションの送信機は利用可能なセッションについての情報（セッション識別子を含む）を、それが接続された先の、またはそれが移動する先のネットワークエージェントに提供する。移動できるケースでは、この情報はセッションコンテクストトランスファースキーム（session context transfer scheme）［ＲＦＣ４０６７参照］を用いてエージェントの間で交換することができる。
・受信機は利用可能なマルチユーザセッションを任意のオフラインまたはオンライン手段を用いて−例えば、ＨＴＴＰによって、またはＳＡＰ（Session Announcement Protocol、ＲＦＣ２９７４参照）による広報（advertisement）を受信することによって−取得する。
・受信機は、セッションオブジェクトをその位置／アドレスを含めて、セッションセットアップ時間にそれが接続された先のネットワーク内のエージェントへ、またはそのモバイル性のために新たなエージェントへ送信する。移動できるケースでは、セッションオブジェクトはセッションコンテクストトランスファースキームを使用することによってネットワークエージェント同士の間で転送することも可能である。

ＳＥＡＣＯＮ機能は素子またはモジュール（以下、ＳＥＡＣＯＮエージェントと呼ぶ）によってサポートされる。ＳＥＡＣＯＮエージェントは、同じアドレス体系および異なるアドレス体系を有するドメイン間におけるマルチユーザセッションの接続とディストリビューション・ツリーの形成とを制御するネットワークエージェントである。ＳＥＡＣＯＮエージェントはドメイン内部またはドメイン間のネットワークエージェント群に対するセッションの接続と形成を制御するように構成することもできる。図１に一般的なシナリオにおけるＳＥＡＣＯＮエージェントの位置とこのメカニズムによってサポートされる基本的な機能の一例を示す。ドメインＤ１において、ＳＥＡＣＯＮエージェントは境界（edges）に配置されている。入口（ingress）エージェントＨは到来するユニキャストセッションフロー（先だってマルチキャストツリーからユニキャストフローへ変換されている）をマルチキャストツリーにマップし、ＳＥＡＣＯＮエージェントＧはレイヤ３マルチキャスト・パケットをレイヤ２マルチキャスト・パケットに変換（translate）する。マルチキャスト送信元（multicast Source）２に関連するマルチキャスト・パケットはエージェントＥ（ドメインＤ２とドメインＤ３の間にある）によってユニキャスト・パケットに変換される。さらに、入口エージェントＪに到来するユニキャスト・パケットはアクセスエージェントＫにマルチキャスト（ディストリビューション・ツリーの形成に寄与する）で転送される。アクセスエージェントＫは関心のあるモバイル受信機のリスト（例えばＰＡＮ（Personal Area Network）内に位置するＩＥＥＥ８０２．１５．４デバイス）にＩＰユニキャストフローを変換し、複製する。

最後に、セッションフローに関連する、送信元（Source）３によって送信されたユニキャスト・パケットは、エージェントＣによって、Ｄ２内のローカルな範囲でマルチキャストツリーに変換される。Ｄ２とＤ４との間のドメイン間リンクは端点間（edge-to-edge）マルチキャストツリー（ドメイン間のマルチキャストツリー）を生成するためのそれ自体のスキームを有するため、マルチキャストフローはドメイン間マルチキャストツリーにマップされる。同じ手続きがＤ４内部で起こる。この際、入口エージェントＬはドメイン間マルチキャストツリーに関連する全てのパケットをドメイン内部のセッションフローのために生成された新たなマルチキャストツリーに変換する。ユニキャストアウェアな受信機がアクセスエージェントＭに移動し、送信元３のセッションフローに参加したい場合は、ＳＥＡＣＯＮエージェントＭとその新たな受信機までのユニキャスト接続が確立される。

実施の一形態におけるＳＥＡＣＯＮマルチユーザセッション接続と異種環境にわたるディストリビューション・ツリーのドメイン間形成はオープンインタフェースを使用を通じて実現される。これらのインタフェースは外部プロトコルまたはメカニズムとの相互作用、異種環境への容易な展開およびＳＥＡＣＯＮの適用を可能にする。実施の一形態によるＳＥＡＣＯＮスキームの主なコンポーネントは以下のようなものである。
・ＳＥＡＣＯＮインタフェース：
・・セッション／アプリケーション・インタフェース（Session/application interface）：外部のセッション／アプリケーション・プロトコルまたはメカニズムはこのインタフェースを使用して、異種環境にわたるディストリビューション・ツリーのマルチユーザセッション接続および形成の生成、複製、削除、修正またはリフレッシュを要求することによって、マルチユーザセッションの形成と接続制御を要求する。例えば、ネットワーク輻輳期間において、ＱｏＳ適応メカニズムはこのインタフェースを使用していくつかのディストリビューション・ツリーと関連付けられた優先順位の低いセッションフローのリリースを要求することができる。加えて、セッション／アプリケーション・プロトコルまたはメカニズムは同じアドレス体系と異なるアドレス体系を有するドメイン間のセッションフローの接続のほかに関心のあるモバイルのユーザのリストへの到来パケットの複製を要求することができる。ＳＥＡＣＯＮはその仕事を終えると、同じインタフェースを使用してリクエスタ（requester）にリスポンスを送る。そのリスポンスに基づいて、セッション／アプリケーション・プロトコルまたはメカニズムはネットワーク・プロトコルまたはメカニズムをトリガー（開始）してドメイン内部およびドメイン間のセッションフローと関連付けられたディストリビューション・ツリーのリソースおよび管理を制御することができる（例えば、セッション／アプリケーション・メカニズムはＰＩＭ−ＳＳＭ（Protocol Independent Multicast for SSM、ＲＦＣ２５７９参照）をトリガーしてマルチキャストドメイン内部またはドメイン間の各セッションフローと関連付けられたマルチキャストツリーを制御することができる）。加えて、セッション／アプリケーション・メカニズムまたはプロトコルはＳＥＡＣＯＮリスポンスを使用してマルチキャストアウェアなホストに各セッションフローごとに（例えば、例えばＳＩＰ（Session Initiation Protocol、ＲＦＣ３２６１参照）などの標準プロトコルを使用することによって）参加されなければならないマルチキャストチャネルについて通知することができる。
・・アドレス割当コントローラ・インタフェース（Address Allocation Controller interface）：このインタフェースはドメイン内または該ドメイン間において各マルチユーザセッションフローが関連付けられているチャネル識別子の割当を外部のアドレス割当コントローラまたはメカニズムに要求するために使用される。例えば、ドメイン内部またはドメイン間の各セッションフローを識別するために、１つの送信元および１つのマルチキャストグループまたはＩＰユニキャストアドレスおよびトランスポートポートのペア（ドメインまたはホストがユニキャストアウェアな場合）から構成されるマルチキャストＳＳＭチャネルを割り当てることが可能である。この情報に基づいて、ＳＥＡＣＯＮは同じアドレス体系または異なるアドレス体系を有するドメイン間のセッションフローを変換することが可能である。さらに、関心のあるユーザがセッションフローに（ユーザのモバイル性のために）これ以上存在しないときは、ＳＥＡＣＯＮは外部のアドレス割当コントローラプロトコルまたはメカニズムと相互作用して各フローに関連するチャネル識別子をリリースする。
・・ファイアウォール制御インタフェース（Firewall controller interface）：このインタフェースはセッションパス（session path）にファイアウォールエージェントが存在していてもホストアクセスネットワーク間の通信を可能にする。ＳＥＡＣＯＮはこのインタフェースを使用して到来するマルチユーザセッションフローについてファイアウォールメカニズムに通知し、ローカルなポリシールール（local policy rules）の設定と、その結果としてファイアウォールスキームの背後でユーザへのマルチユーザセッションコンテンツへのアクセスができるようにする。関心のあるユーザがセッションフローにこれ以上存在しないときは、ＳＥＡＣＯＮはファイアウォールと相互作用してリリースされたセッションフローについて通知する。
・接続制御メカニズム（Connectivity Control mechanism）：この変換ベースのメカニズムは同じアドレス体系および／または異なるアドレス体系を有するドメイン内部および／またはドメイン間のマルチユーザセッションの接続（connectivity）を制御するように構成することができる。例えば、マルチキャストモデルが異なるドメイン間のパケットの変換またはユニキャスト移動ユーザのリストへのマルチキャスト・パケットの変換および複製が行われる。この目標のため、このメカニズムは以下のようないくつかのモジュールをサポートしている。
・・マルチキャスト＜−＞ユニキャスト・モジュール（Multicast <-> Unicast module）：このモジュールはマルチキャスト・パケットをユニキャスト・パケットに変換し、ユニキャスト・パケットをマルチキャスト・パケットに変換し、それにより異なるアドレス体系を有するドメイン間のマルチユーザセッションコンテンツの配信を可能にする。ユニキャストアウェアなユーザが（例えばハンドオーバなどにより）マルチキャストアウェアなドメインに接続された場合、ＳＥＡＣＯＮエージェントからのユニキャスト接続が生成され、ユーザまたはネットワークアドレス体系とは無関係にセッションフローの配信が可能となる。
・・マルチキャスト＜−＞マルチキャスト・モジュール（Multicast <-> Multicast module）：このモジュールはマルチキャスト・パケットをマルチキャストモデルが同じまたは異なるマルチキャスト・パケットに変換し、オペレータがそれらのローカルなマルチキャスト接続スキームに基づいて、それらの近隣によって使用されるマルチキャストスキームとは無関係に、マルチキャストツリーを制御することができるようにする。
・・ユニキャスト＜−＞ユニキャスト・モジュール（Unicast <-> Unicast module）：このモジュールはユニキャスト・パケットをユニキャスト・パケットへ変換および（必要に応じて）複製し、オペレータがローカルな範囲のユニキャストディストリビューション・ツリーを生成し、ユーザが無線ネットワークに接続されているときでもユニキャストフローを関心のあるユニキャストアウェアなユーザにマルチキャストで送信することができるようにする。
・形状制御メカニズム（Shape Control mechanism）：このメカニズムは効率的な形状（shape）を持つディストリビューション・ツリーの生成を制御するとともに、送信機、受信機（例えばユニキャストアウェアな受信機）またはアクセスネットワークのモバイル性（mobility）によって引き起こされるほかにネットワーク故障に起因するセッションパス全体の再構築を避ける。例えば、このメカニズムは同じマルチホーム（multi-homed）アクセスドメインにおいて同じマルチユーザセッションフローに対して２つ以上の入口ポイントの存在を避ける。

マルチユーザセッション（multi-user sessions）に関連する状態を生成、削除、修正またはリフレッシュするためのリクエストは外部のプロトコル／メカニズムによって（ＳＥＡＣＯＮセッション／アプリケーション・インタフェースを使用することによって）、または別のＳＥＡＣＯＮエージェントによって、オンデマンドで実行することができる。この手続きにより、ＳＥＡＣＯＮは、エンドホストおよび／またはネットワークのアドレス体系とは無関係に、異種環境にわたるマルチユーザセッションの接続を制御することができる。この接続制御作業に加えて、現在のセッションフローについての状態はドメイン間ディストリビューション・ツリーの形成を制御することを目標とする。この目標のため、ＳＥＡＣＯＮエージェントまたは外部のセッション／アプリケーション・プロトコルまたはメカニズムは、現在のマルチユーザセッションについてのセッションごとおよびフローごとの状態（グローバルセッション識別子と、エージェントの到来インタフェーステーブルと発信インタフェーステーブルの中の各フローと関連付けられたチャネル識別子とを含む）を保持（maintain）する。

セッション識別子は、セッションフローと関連付けられたチャネル識別子（例えば、送信元および／または宛先のＩＰアドレス、送信元および宛先のポート）が各ドメインで変わることがあっても、エンドツーエンドパスにおいて変更はなされない。到来するセッションフローが発信インタフェーステーブルの中にいくつかの関心のあるエージェントまたはユーザを有する場合、パケットはそれら各々に対してローカルなチャネル識別子とトランスポート技術に基づいて変換および複製することができる。一例として、１つの入口エージェント（ingress-agent）がその発信インタフェーステーブルの中に同じセッションフローと関連付けられた２つの出口エージェント（egress-agent）を有するユニキャストアウェアなドメインを議論する。このシナリオでは、入口エージェントはセッションフローと関連付けられた状態を使用してこれらのセッションフローと関連付けられた到来パケット（ユニキャストまたはマルチキャスト・パケット）を別個の出口エージェントにアドレス指定された２つの異なるＩＰユニキャスト・パケットに変換（例えば、ＩＰパケットの中の送信元と宛先のアドレスを置き換える）および複製する。

ＳＥＡＣＯＮエージェント同士の間の相互作業（interoperation）はシグナリングメッセージを通じて（ＳＥＡＣＯＮメッセージによって、または外部のプロトコルまたはメカニズムによってサポートされているシグナリングメッセージを使用することによって）実行される。ＳＥＡＣＯＮエージェントはシグナリングメッセージによって搬送された情報を使用して（アドレス割当コントローラ・インタフェースを使用してドメイン内または該ドメイン間においてセッションを配信するために使用される）各セッションフローごとにチャネル識別子を要求し、セッションフローと関連した状態を更新し、その結果としてマルチユーザセッション接続とディストリビューション・ツリーの形成を制御する。例えば、セッションのセットアップの際、セッション識別子とチャネル識別子（メッセージで搬送され、エージェントに格納された、例えば、マルチキャストアウェアなドメイン内部の各セッションフローに関連するＳＳＭチャネル）についての情報は、ＳＥＡＣＯＮエージェントによって、各セッションフローの全ての到来マルチキャスト・パケットをユニキャストアウェアなドメインまたは別のマルチキャストアウェアなドメインに接続した関心のあるユーザのリストへ変換するために使用される。

さらに、実施の一形態におけるＳＥＡＣＯＮはディストリビューション・ツリーの形状を制御し、ユーザのモバイル性（例えば、ユニキャストまたはマルチキャストユーザのマルチホーミングアクセスネットワークにおける新しいアクセスエージェントへのモバイル性は、ドメイン内部の同じセッションフローに対して２つ以上の入口ポイントの存在を許し、ひいては非効率なディストリビューション・ツリーの構築を許してしまう）またはネットワーク故障によって引き起こされるエンドツーエンドセッションパスの再構築を避ける。一例としてマルチユーザセッションのマルチキャストソースがドメイン内部の新たなアクセスエージェントに移動する状況が挙げられる。このときには、シグナリングメッセージ（signaling messages）がダウンストリームの出口エージェントにソース（送信元）の移動について通知するために使用される。それゆえ、出口エージェントがシグナリングメッセージを受信し、要求されたセッションフローの接続がアクセスエージェントに向かうパスにおいて既に活性化されていることを確認すると、シグナリングメッセージは止められ、到来インタフェーステーブルの中の状態がアップストリームパスにおける新しいチャネル識別子についての情報によって更新される。これにより、途絶点、信号オーバヘッド、およびグローバルセッションパスの再構築が避けられる。

それゆえ、ＳＥＡＣＯＮエージェントは要求されたマルチユーザセッションフローが既にアップストリームおよび／またはダウンストリームのセッションパスに向けてアクティブにされていることを（セッションフローと関連付けられた状態を問い合わせて）検出すると、ＳＥＡＣＯＮエージェントはエンドツーエンドではなくそれ自体と次のアップストリームおよび／またはダウンストリームエージェントとの間の宛先にへのパス上の接続を、基礎となるトランスポート技術とは無関係に、構築／再構築しようと試みる。例えば、ユニキャストアウェアなモバイルのユーザが同じドメイン内部の新しいアクセスエージェントに移動すると、セッションの接続はモバイルユーザのアクセスドメインの入口エージェントからその新しいアクセスエージェントまでだけが（エンドツーエンドではなく）再構築される。さらに、新しいアクセスエージェントにおいて同じセッションフローを受信する別の受信機が存在する場合、到来パケットは新しいモバイルのユーザに向けて複製され、新しいパス上にセッション接続を構築するためのシグナリングは一切交換されない。

様々な実施形態においてＳＥＡＣＯＮメカニズムは多数の利点が伴う。すなわち、それは、
・ユニキャストネットワークおよびマルチキャストネットワーク上におけるマルチユーザセッションの接続を制御する。
・ユニキャストまたはマルチキャストの送信元がそれらのセッションコンテンツをモバイルのユーザのグループに各アクセスネットワークで使用される接続技術に関係なく送ることを可能にする。
・ユニキャストまたはマルチキャストの受信機が要求されたセッションフローを各アクセスネットワークで使用される接続技術に関係なく受信することを可能にする。
・移動している端末（moving terminals）が、異なるアクセスネットワークによって利用可能となり、それら端末の能力に一層適している接続スキームを利用することを可能にする。
・マルチユーザサービスがグローバル接続変更なしにクライアントによって移動式設備が提供されることを可能にする。
・異なるプロトコル／メカニズムとの容易な相互作用を可能にするオープンインタフェース（open interfaces）を利用する。
・セッションのフローと関連付けられたドメイン間ディストリビューション・ツリーの形成を制御することを目的とする。
・ネットワークオペレータがそれら自体の接続スキームに基づいて新たなマルチユーザサービスを、それらの近隣によって使用されるスキームとは無関係に、迅速に展開することを可能にする。
・エンドホストに独自のモジュールを導入することを必要としない。

このことは以下の更なる実施形態の説明から明らかとなる。

実施の一形態によれば、ＳＥＡＣＯＮメカニズムは、ネットワークおよび／またはホストネットワークのトランスポート技術とは無関係に、異種環境にわたるマルチユーザセッションのモバイルのユーザとの接続を制御する。例えば、ＳＥＡＣＯＮは、ユニキャストドメインからマルチキャストドメインへの接続と、逆にマルチキャストドメインからユニキャストドメインへの接続とを制御するほかに、同じまたは異なるアドレス体系を有するマルチキャストドメイン間のリンケージ（linkage）を実現することができる。それはまた無線ネットワーク上に配置されたユーザがマルチユーザセッションコンテンツをそれらの能力により適した接続スキームに基づいて受信することができるようにする。

加えて、ＳＥＡＣＯＮはセッションフローと関連付けられたドメイン間ディストリビューション・ツリーの形状を制御し、ホストのモバイル性またはネットワーク故障に起因するエンドツーエンドのセッションパスの再構築を避けることを目標としている。ＳＥＡＣＯＮはエンドツーエンドのセッションパスにおけるドメイン間のマルチユーザセッションの接続および形状を制御するのでこれは可能である。グローバルセッション識別子（マルチユーザセッションを識別するために送信元によって使用される）とローカルチャネル識別子（ドメイン内または該ドメイン間の各セッションフローを識別するためにアドレス割当コントローラ・メカニズムによって割り当てられる）を使用することでホストの位置またはＩＰアドレスとは無関係にドメインごとのトランスポート接続の制御が可能となる。それゆえ、ホストが移動するとき、そのホストが接続されたまたは接続される新しいＳＥＡＣＯＮエージェントと要求（リクエスト）されたセッションフローが（例えば受信機のモバイル性に起因して）送信元に向けてあるいは（例えば送信元のモバイル性とネットワーク故障に起因して）アクセスエージェント／受信機への途上でアクティブにされている最初のＳＥＡＣＯＮエージェントとの間で制御情報を交換するためにシグナリングメッセージが使用される。

要求されたセッションフローの接続（connectivity）が確立されたことをエージェントが確認すると、シグナリングメッセージは停止され、状態はセッションフローと関連付けられた新しいチャネル識別子についての情報によって更新される（これにより、例えば、異なるトランスポート技術の間でパケットのマッピングが可能となる）。さらに、アップストリームおよび／またはダウンストリームのエージェントはマルチユーザセッションフローに関係した接続制御プロセスを実行するよう合図されることが可能である。上述の作業はセッションパス全体の再構築を避け、新しいパス上のセッション接続を生成するのに必要な信号オーバヘッドとセッション収束時間を減らすことを目標とする。加えて、古いパス上のセッションフローに関係したまたはセッションフローが終わるときの状態は明示的に（シグナリングメッセージを使用する）リリース手続きによって、またはソフトステート（soft-state）操作によって削除することができる。

どのマルチユーザセッションフロー接続が、生成、複製、リリース、リフレッシュまたは修正されなければならないかについての情報は、外部のプロトコルまたはメカニズムによってサポートすることができるほかに、その情報はＳＥＡＣＯＮエージェントの間でＳＥＡＣＯＮメッセージを使って交換することができる。それゆえ、同じまたは異なるアドレス体系を有するドメイン間の接続を制御するため、ＳＥＡＣＯＮエージェントはアップストリームパスにおける各セッションフローに関連するチャネル識別子（１つのドメイン内または複数のドメイン間において、例えば、グローバルセッション識別子、送信元と宛先のＩＰアドレスによって定義することができるチャネル識別子、トランスポートプロトコル番号および送信元と宛先のトランスポートポート番号）についての情報を受信する必要がある。この接続制御情報に基づいて、ＳＥＡＣＯＮエージェントはその到来インタフェーステーブルを更新し、ダウンストリームのドメイン内または該ドメイン間における各セッションフローと関連付けられるチャネル識別子の割当を要求する。各セッションフローに割り当てられたチャネル識別子についての情報は発信インタフェーステーブルに保存される。到来インタフェーステーブルと発信インタフェーステーブルの一例については後で図２Ｂを参照して詳しく説明する。このように、セッションフローにアドレス指定された全ての到来パケットは変換され、エージェントまたはユーザのリストに（ネットワーク技術に応じて）複製および転送することができる。ＳＥＡＣＯＮエージェントがアクセスエージェントに配置され、関心のあるモバイル受信機が無線ネットワークに接続された場合、データパケットはレイヤ２のＭＡＣアドレス（発信インタフェーステーブルへの問い合わせに基づく）に基づいて目標ポートにマップおよび転送される。ユニキャストアウェアなドメインでは、パケットは、ＩＰアドレス、ポートおよびトランスポートプロトコル番号に基づいてユーザのリストにマップおよび複製される。

ＳＥＡＣＯＮエージェントはステイトフル（stateful）かまたはステイトレス（stateless）であり得る。後者の場合、外部のセッションまたはアプリケーション・プロトコルまたはメカニズムが、ＳＥＡＣＯＮエージェントが関連付けられたドメイン内または該ドメイン間の現在のセッションについてのセッションごと（per-session）またはフローごと（per-flow）の状態を保持していると仮定する。既に述べたように、マルチユーザセッション接続を実行するために必要とされる状態はアップストリームとダウンストリームのドメイン内における各セッションフローに関連したセッション識別子とチャネル識別子についての情報（例えばマルチキャストアウェアなドメインにおけるＳＳＭチャネル）を含む。しかしながら、ユニキャストアウェアなドメイン内または該ドメイン間の２つ以上のエージェントが同じセッションフローを要求する場合、パケットはそれらに向けて変換および複製される。さらに、ユニキャストドメインのアクセスエージェントにおいて、関心のあるユーザのリストは、ＩＰユニキャストアドレス、トランスポートプロトコル番号およびユニキャストユーザのポートまたは無線ネットワークに接続されたユーザのポートおよびＭＡＣアドレスを含む。ＳＥＡＣＯＮ状態はマルチキャストドメインに接続されたユニキャストユーザがマルチユーザセッションのコンテンツを受信することも認める。

マルチホーム（multi-homed）環境におけるセッションフローと関連付けられたドメイン間ディストリビューション・ツリーの形成を実現するため、ＳＥＡＣＯＮエージェントが保存する状態はセッションフローが要求されたところの受信機のドメイン識別子（ドメイン識別子は、マニュアル設定またはある自己組織化スキームを使用することによって定義される、同じドメインに属するエージェント群を識別するために使用される一意の識別子であると想定される）と受信機のドメインに向かうセッションに関連したダウンストリームエージェントのユニキャストＩＰアドレスについての情報で拡張される。それゆえ、ＳＥＡＣＯＮエージェントがトリガーされると、要求されたセッションフローがリクエスタ／受信機のドメイン内に既に存在するかどうかを（その状態の問い合わせに基づいて）確認するために形状制御メカニズムがアクティブにされる。セッションフローが既に受信機のドメインで進行中の場合、メッセージがそのドメインへの次のダウンストリームエージェントへ転送されるだけであり、状態操作は存在しない。受信機のドメインの入口エージェントがこのメッセージを受信すると、形状制御（Shape Control）は要求されたセッションフローの接続が受信機またはエンドホストに接続されたアクセスエージェントに向けて既に存在しているかどうかを確認する。接続が存在する場合、メッセージは次のダウンストリームエージェントへ転送される。しかしながら、リクエストが新しいアクセスエージェントまたは受信機からのものである場合、接続制御メカニズムがトリガーされ、新しいアクセスエージェントまたは受信機に向かう各セッションフローへのチャネル識別子の割当を要求する。その後、発信インタフェーステーブル上の状態が新しいエージェントまたは受信機についての情報によって更新され、結果的に、セッションフロー接続が生成される。要求されたセッションフローの接続が既に確立されている場合にはメッセージは入口エージェントでストップされる。このアプローチによれば、ＳＥＡＣＯＮは同じマルチホームアクセスドメイン内の同じセッションフローに対して２つ以上の入口ポイントが存在することを避け、ネットワーク資源を節約する。

図２Ａに異種環境にわたる（３つのフローで構成された）マルチユーザセッションの接続（connectivity）と形成（shaping）を制御するためのＳＥＡＣＯＮメカニズムの一例を示す。説明を簡単にするために本例は次のような仮定を置く。
・アップストリームとダウンストリームのパスを通じたＳＥＡＣＯＮに信号伝達するアプリケーション・プロトコルの存在。このプロトコルは接続制御プロセスに対して、受信機が接続されたドメイン識別子を含めて、セッションオブジェクトを満たす（fill）ことを要求する責務を負う。このプロトコルはＳＥＡＣＯＮエージェントとして働くネットワークエージェントによって実行される専用のプロトコルでよい、あるいはそれは例えばＩＥＴＦ（Internet Engineering Task Force）のＮＳＩＳワーキンググループによって開発されたＧＩＳＴプロトコルの上で走る新しいサービスレイヤプロトコルなどの標準プロトコルを使用することによって組み込まれるもしくは実装される。斯かるプロトコルは次のように機能することができる。リクエスト（Request）メッセージは受信機のアクセスエージェントによってセッションの送信元に向けて送信される。このメッセージはＩＰ警告機能を有し、他の中間エージェントがそれを調べることを認める。このメッセージはメッセージの中で特定されるセッションを有する最初のエージェントによって止められる（最悪のケースではメッセージは送信元近くのエージェントによって止められる）。メッセージを止めるエージェントは、ＳＥＡＣＯＮプロセスをアクティブにした後に、リスポンス（Response）メッセージをリクエスタのアクセスエージェントの方向にある次のエージェントに送信する。各エージェンにおいて、ＳＥＡＣＯＮがそのタスクを実行するためにアクティブにされる。プロトコルの振る舞いの一例を後で図２Ａを参照して説明する。
・マルチキャストアウェアなドメインにおける各セッションフローへのＳＳＭチャネルの割当を制御する責務を負うアドレス割当コントローラ（Address Allocation Controller）メカニズムの存在。ユニキャストアウェアなドメイン内または該ドメイン間において、このメカニズムは送信元と宛先のアドレスのペア、送信元および宛先ポートのペアの割当を制御し、次のダウンストリームエージェントに各セッションフローについて通知する。
・マルチキャストアウェアなドメインにおいて、外部のプロトコルまたはメカニズムは各セッションフローと関連付けられたマルチキャストツリーを制御するためにアプリケーション・プロトコルによってトリガーされる。
・送信機は利用可能なセッションフローをユーザに告知（announce）する（セッション識別子および各フローの番号のほかに参加申込（subscription）を可能とするのに十分な情報（例えばアドレスおよびポート）を含むセッションオブジェクトを含む）。

図２Ａに戻って、本発明の実施の一形態によるＳＥＡＣＯＮメカニズムの説明を続ける。図からＳＥＡＣＯＮエージェントは、ドメインＤ１、ドメインＤ２、およびドメインＤ３の境界（edges）に配置されていることが見て取れる。つまり所与のセッションに対して、ＳＥＡＣＯＮエージェントはある特定のドメインに関して入口エージェント（ingress agent）または出口エージェント（egress agent）のどちらかとして働く。入口エージェントＧにおけるＳＥＡＣＯＮエージェントはＳ１の発行（publish）されたマルチキャストセッションフロー（multicast session-flows）についての情報を受信し、エージェントＨはＳ２の告知（announce）されたユニキャストセッションフロー（unicast session-flows）についての情報を受信し、その後、各ＳＥＡＣＯＮエージェントはその到来インタフェーステーブルを告知されたセッションフローのセッション識別子およびチャネル識別子についての情報によって更新することができる。その目的のため、この情報は可能な受信機に向かう更なるＳＥＡＣＯＮエージェントを通じて（例えば“発行”メッセージによって）ダウンストリームに配信することができる。この際、ＳＥＡＣＯＮエージェントはどのセッションが参加申込可能かについての情報を含む対応する情報を例えば到来インタフェーステーブルに保存することができる。到来インタフェーステーブルの中では、参加申込可能だがＳＥＡＣＯＮエージェントによってまだ受信されていないセッションとＳＥＡＣＯＮエージェントによって既に受信されているセッションは例えばセッションのステータスを“受信中（being received）”または“参加申込可能（available for subscription）”のようなもので表示する適切なフラグ（flag）によって区別されるべきであることに留意しなければならない。“発行”メッセージを通じて斯かる情報は可能な受信機に向かってダウンストリームに転送される。

マルチユーザセッション告知メントを受信すると同時に受信機Ｒ１のアプリケーションはシグナリングメッセージ（例えば“参加申込（subscribe）”メッセージまたは“リクエスト（request）”メッセージ）を使用してセッションＳ１の全てのフローへの参加を申し込む。このメッセージはＩＰルータ警告オプション（IP Router Alert Option）［ＲＦＣ２１１３］をイネーブルにした状態でセッションソースに向けて送信される。このオプションがイネーブルにされると、全てのＳＥＡＣＯＮエージェントはメッセージによって搬送されたセッションオブジェクトをより念入りに調べることが認められる。それらはセッションフローについての情報を有する場合にはその進行を停止する。これはセッションが既に発行されたことから入口ＳＥＡＣＯＮエージェントＧで起こる。実際に本実施形態ではセッションＳ１は既にエージェントＧによって受信されていることがあり、送信元Ｓ１とエージェントＧとの間の接続が既に存在する。このことは例えばセッションＳ１が受信されることを要求することによってこの接続を更に確立する必要がないことを意味する。別の例として、セッションがエージェントＧによってまだ受信されていない場合、この事実はエージェントＧの到来インタフェーステーブルの中に示され、セッションＳ１を受信するための対応するリクエストが接続が確立されるよう送信元に転送される。

入口エージェントＧにおいて、ＳＥＡＣＯＮ形状制御（SEACON Shape Control）メカニズムは要求されたセッションがＤ１で（まだ）アクティブにされていないことを確認し、接続制御（Connectivity Control）メカニズムをトリガーしてセッションフロー接続を許可する。続いて、接続制御（Connectivity Control）メカニズムは、セッションフローがこのマルチキャストドメインにおいて関連付けられたチャネル識別子と出口エージェント（このケースでは次のダウンストリームエージェントＥ）のＩＰアドレスの割当を要求するローカルなアドレス割当コントローラ・メカニズムと相互作用する。リスポンスに基づいて、ＳＥＡＣＯＮはその発信インタフェーステーブル（outgoing interface table）をローカルな範囲で各セッションフローに割り当てられた各ＳＳＭチャネルとＤ１に向かう次のダウンストリームエージェント（ここではエージェントＥ）についての情報によって更新する。その後、ＳＥＡＣＯＮはリクエスタ（アプリケーション・プロトコル）と相互作用してそれにこのドメインの各セッションフローのローカルチャネル識別子について通知する。さらに、ドメイン間ディストリビューション・ツリーの形状を制御するために、ＳＥＡＣＯＮエージェントは受信機が各セッションフローと関連付けられた状態で接続されたドメイン識別子を含む。このアプローチにより、同じセッションフローに関連しており同じマルチホームドメインにアドレス指定された異なるディストリビューション・ツリーの生成が避けられる。例えば、この状況は同じセッションフローの接続制御を要求する第２のリクエストが（例えばマルチホームドメインにおけるいくつかの入口エージェントの存在に起因して）それへのセッション接続が同じドメインに向けて既に確立されているエージェントに到達するときに起こる。最後に、ＳＥＡＣＯＮが上記の手続きを終了すると、ダウンストリームパスにおける接続を要求するためにアプリケーション・プロトコルがトリガーされる。このアプリケーション・プロトコルはシグナリングメッセージの中にセッションフローと関連付けられた接続制御情報を含ませて、それを次のダウンストリームＳＥＡＣＯＮエージェント（このケースではＥ）に送信する。

斯かるシグナリングメッセージを受信すると同時に、エージェントＥはその到来インタフェーステーブルをドメインＤ２における各セッションフローと関連付けられたセッション識別子とチャネル識別子についての情報によって更新し、既に述べたものと同じ手続きを実行する。しかしながら、ユニキャストがドメインＤ２とドメインＤ１との間のネットワークトランスポート技術であるときには、発信インタフェーステーブルの中の各セッションフローに関連した情報は、送信元（そのローカルＩＰユニキャストアドレス）と宛先ＩＰアドレス（次のダウンストリームエージェントのＩＰアドレス）と送信元ポートおよび宛先ポート（送信元ポートおよび宛先ポートのペアは各フローに割り当てられる）とトランスポートプロトコル番号についての情報のほかにＤ１に向かうダウンストリームエージェントについての情報によって更新される。この（アドレス割当コントローラ・メカニズムによって提供された）情報に基づいて、ＳＥＡＣＯＮは、ドメイン内ＳＳＭチャネルから来る全てのパケットを、ローカルな範囲でＤ２とＤ１との間のセッションフローに使用される、対応するユニキャスト・パケットへ変換する。

到来インタフェーステーブルと発信インタフェーステーブルの一例を図２Ｂに示す。この例はＳＥＡＣＯＮエージェントがマルチキャストセッションからユニキャストセッションへ変換する場合にこれらのインタフェースがどのように見えるかを示すものである。表の例に則して説明すれば、エージェントＥはエージェントＡからマルチキャストセッションを受信し、それをユニキャストセッションへ変換し、そしてそれをエージェントＩへダウンストリーム方向に転送する。所与のマルチユーザセッションＩＤに対して、到来インタフェーステーブルはセッションＩＤ（ここには図示されていない）と送信元アドレス（ここではエージェントＡ）を保存する。さらに、各フロー（ここではフロー１〜フローＮ）のチャネル識別子が保存される。最後に、宛先アドレスが保存される。各到来マルチキャストセッションフローは対応する発信ユニキャストフローに変換され、状態情報が図２Ｂに示すように発信インタフェーステーブルに保存される。各フローごとに、送信元アドレス（ここではエージェントＥ）、宛先アドレス（エージェントＩ）、および送信元ポートと宛先ポートのペアのほかに、トランスポートプロトコルの表示（番号）が保存される。このようにして各フローはその状態に関して識別できる。この情報は受信機が接続された先のドメイン（図２Ｂには示されていない）の表示も更に含む。さらに、実施の一形態によれば、セッションが送信元から受信機へ通過する際に経由するドメインについての表示が、場合によっては各ドメインの入口エージェントと出口エージェントと一緒に保存される。これにより、要求元の受信機に複数のドメインを介してのみ到達できるような場合でも進行中のセッションを利用することが可能となる。参加申込メッセージは例えば、それがアップストリーム方向に通過したネットワークエージェントのリストを含むことがある。また、このリストを進行中のセッションが通過するドメインについての情報と比較することによって、最小数のリンクが新たに確立されることを要求するダウンストリームパスを見つけることが可能である。

上記の手続きはダウンストリームデータパスにおける全てのＳＥＡＣＯＮエージェントによって、それがアクセスエージェント（access agent）として働くネットワークエージェント（ここではエージェントＡ）に到達するまで、実行される。続いてエージェントＡの発信インタフェーステーブルは、ホスト上のアプリケーションが（セッションオブジェクトで搬送された）パケットをそれを介して受信したいと欲する送信元と宛先のポートのほかにＲ１のユニキャストＩＰアドレスについての情報によって更新される。それゆえ、エージェントＡにおいて、参加を申し込まれたセッションフローと関連付けられた全ての到来パケットは（送信元アドレスはエージェントＣ、宛先アドレスはエージェントＡ、および特定の送信元と宛先のポートとプロトコル番号で）Ｒ１のユニキャストＩＰアドレスに転送される。

Ｒ１の参加申込（subscription）後、受信機Ｒ２上のアプリケーションは同じセッションフローに参加するためのシグナリングメッセージを生成することができる。要求されたセッションフローの接続制御手続きはアクセスエージェントＡにおいて既にアクティブにされたので、ＳＥＡＣＯＮエージェントがトリガーされると、それはセッションフローの受信機のリストをＲ２のユニキャストＩＰアドレスを含めて調整し、直ちにリスポンスをリクエスタに返信するだけである。それゆえ、ＳＥＡＣＯＮは全てのパケットを関心のあるユーザのリストにマップし、要求されたパケットの複製をそのドメインのアクセスエージェントでのみで実行し、その結果、ネットワーク資源が節約されるとともに、信号オーバヘッドとセッションセットアップ時間が短縮される。

受信機Ｒ３上のアプリケーションが同じセッションフローに参加するためのシグナリングメッセージを生成するときの、ドメイン間ディストリビューション・ツリーの一例を紹介する。図２Ａに示された本例では、Ｄ１はマルチホーム（multi-homed）ドメインであるから、セッションの接続を要求する送信元に送られるシグナリングメッセージは、ドメインＤ１から、エージェントＣではなく（セッションフローの接続はエージェントＣにおいて既に確立されている）エージェントＤを経由して出る。

いま、リクエストが、要求されたセッションが既にアクティブになっているエージェントを通過することなく、それが図２Ａに示されたエージェントＧに到達するまで、アップストリーム方向にＳＥＡＣＯＮエージェントを経由して転送される状況を想定する。入口エージェントＧにおけるＳＥＡＣＯＮ形状制御（SEACON Shape Control）メカニズムがトリガーされると、それは受信機が接続された先のドメインに向けて要求されたセッションフローが既にアクティブにされていることを（要求されたセッションフローと関連付けられたドメイン識別子によって特定され、ドメインのリストについての情報を含んでいるその状態のクエリーに基づいて）確認する。この時点で、ＳＥＡＣＯＮは接続を制御するためのローカルな手続きは（接続は既に存在しているので）実行せず、メッセージ（リクエストまたは参加申込メッセージ）がドメインＤ１に向けて次のダウンストリームエージェントに転送される。同じプロセスがＳＥＡＣＯＮエージェントＥによって実行される。このエージェントにおいてもセッションは受信機Ｒ２のドメインに向かうダウンストリーム方向において既にアクティブになっているからである。これはエージェントに保存された状態情報は受信機のドメインの表示を含んでいるので検証可能である。しかしながら、メッセージを受信すると同時に、エージェントＣは、受信機Ｒ３が接続されたアクセスエージェントＢに向けてセッションフロー接続がまだアクティブにされていないことを確認する。その後、形成接続制御作業が実行され（パケットは新しいアクセスエージェントに向けて変換、複製される）、ＳＥＡＣＯＮエージェントＣは受信機Ｒ３へのセッション接続を状態の更新（発信インタフェーステーブルの更新）を含めて制御するように合図される。

受信機Ｒ４上のアプリケーションがセッションＳ２の全てのフローに参加するためにシグナリングメッセージを送信するとき、各ドメインがそのローカルスキームを使用してローカルな範囲でマルチキャストツリーを生成する場合の、マルチキャストアウェアな環境にわたるマルチユーザセッションの接続の１つの例を示す。このメッセージが入口エージェントＨに到達すると、セッションはＤ３に向けてアクティブにされていないので、ＳＥＡＣＯＮ接続制御（SEACON Connectivity Control）メカニズムがトリガーされる。この時点で、アドレス割当コントローラ（Address Allocation Controller）がトリガーされて、各セッションフローごとにマルチキャストチャネルを割り当て、出口エージェント（ここではエージェントＦ）のユニキャストＩＰアドレスが通知さる。この情報に基づいて、ＳＥＡＣＯＮエージェントＨは発信インタフェーステーブルの中のＳ２に関連する状態を更新し、到来ユニキャストフローの対応するマルチキャストツリーへの変換が可能となる。その後、ダウンストリームパスにおけるセッション接続を要求するためにシグナリング（signaling）プロトコルがトリガーされる。ドメイン間ＳＥＡＣＯＮエージェントＦはメッセージを受信すると、既に説明したのと同じ接続形成情報（connectivity and shaping information）を要求するドメイン間アドレス割当コントローラ・メカニズムをトリガーする。ＳＳＭはドメイン間リンク内の各セッションフローに割り当てられているので、ＳＥＡＣＯＮは到来インタフェーステーブル内の全てのドメイン内ＳＳＭパケットを対応するドメイン間ＳＳＭパケットに、送信元ＩＰアドレスと宛先ＩＰアドレスを置き換えることによって変換する。この手続きはダウンストリームパスにおける全てのエージェントによって実行される。しかしながら、アクセスエージェントＪは外部のアプリケーション・プロトコルをトリガーしてＲ４に各セッションフローごとに（例えばＳＩＰを使って）参加しなければならないマルチキャストチャネルについて（例えばＳＩＰを使って）通知する。続いてＲ４上のアプリケーションはこの情報を使用して、例えばＩＧＭＰｖ３（Internet Group Management Protocol、ＲＦＣ３３７６参照）またはＭＬＤｖ２（Multicast Listener Discovery protocol、ＲＦＣ３８１０参照）を使用することによって、新しいマルチキャストチャネルに参加することが可能である。

ここで、本発明の実施の一形態によるＳＥＡＣＯＮメカニズムについて整理する。最初に、参加申込を可能（イネーブル）とするために利用可能なセッションが発行される。参加申込（subscription）の後、ＳＥＡＣＯＮメカニズムは、セッションが既にアクティブになっている最初のエージェントを（受信機から開始して）送信元に向かって探し始める。続いて次のダウンストリームエージェントが特定され、セッションがまだアクティブになっていない場合にはチャネル識別子がアドレス割当インタフェースによってドメイン内のセッションに割り当てられることが要求される。発信インタフェーステーブルが更新され、リスポンスメッセージが（リクエストまたは参加申込メッセージに応答して）このエージェントからダウンストリーム方向に転送され、続いてダウンストリームパスにおいてトランスレータを設定するために使用される。これは例えば適切なユニキャスト（またはマルチキャスト）プロトコル（ＰＩＭ−ＳＳＭのような）を次のダウンストリームエージェントでトリガーすることによって、接続を確立することを既に含む場合がある。その目的のため、リスポンスメッセージは最初にダウンストリームパス内の次のエージェントに転送され、ＳＥＡＣＯＮメカニズムはこのエージェントに進んでトランスレータを設定するかまたは既に行われているのであればダウンストリーム方向にメッセージを更に転送する。この手続きは受信機が接続された先のアクセスエージェントに到達するまで実行される。言い換えると、ダウンストリームの接続が既に確立されている限り、リスポンスメッセージは（参加申込メッセージに応答して）ダウンストリームに転送されるだけである。更なるダウンストリームに接続がまだ存在しなければ（このことはエージェントの到来インタフェーステーブルと発信インタフェーステーブルに保存されている場合がある状態情報をチェックすることによってチェックすることができる）、チャネル識別子が割り当てられ、トランスレータが設定され、接続が確立される。さらに、その後、状態情報が（例えば到来インタフェーステーブルと発信インタフェーステーブルを更新することによって）更新される。好ましくは、状態情報は任意の変化あるいは変更（例えば移動もしくはエージェントの故障に起因して起こり得る接続ロスなど）が分かるように継続的にリフレッシュされる。

ホストのモバイル性に起因するドメイン間ディストリビューション・ツリーの接続および形状を制御するためのＳＥＡＣＯＮメカニズムの一例を図３に示す。本例はＳＥＡＣＯＮが受信機の移動によって引き起こされるセッションパス全体の再構築を避け、セッションセットアップ時間と信号オーバヘッドを減らす様子を示している。受信機Ｒ１が新しいアクセスドメインに移動すると、ＳＥＡＣＯＮエージェントへのセッションの接続を要求するために外部プロトコル（例えば、ＳＩＰベースのプロトコルまたはコンテクストトランスファープロトコル（Context Transfers Protocol））がトリガーされる。それゆえ、エージェントＥがアップストリームに転送されたリクエストによってセッションがアクティブになっている最も近いエージェント（それは同じセッションフローへの別の分岐点を有するため）としてトリガーされると、それはアドレス割当コントローラ・メカニズムと相互作用してユニキャストドメイン間リンク（ＥからＫ）で使用される各セッションフローごとにチャネル識別子（Ｒ１に向けた）の割当を要求する。外部のＱｏＳ適応メカニズムがネットワーク輻輳に起因するセッションの優先順位の低いフローを落としたことから、セッションの２つのフローのみがこの特定例では要求される。この情報に基づいて、ＳＥＡＣＯＮエージェントＥはその状態を更新し、セッションフローと関連付けられた到来パケットのエージェントＣへのマッピングと複製がエージェントＫにも転送可能となる。その後、受信機に向かってダウンストリームパスにある次のエージェント（ここではエージェントＫ）に合図するためにシグナリングプロトコルがトリガーされる。

メッセージを受信すると同時に、ＳＥＡＣＯＮエージェントＫはその到来インタフェーステーブルをドメイン間リンクにおける各セッションフローと関連付けられたセッション識別子およびチャネル識別子についての情報によって更新し、そのローカル手続きを実行してセッション接続を制御する。それゆえ、ＳＥＡＣＯＮメカニズムはアドレス割当コントローラ・メカニズムと相互作用してマルチキャストドメインＤ４内部の各セッションフローに対するチャネル識別子の割当を要求する。この情報に基づいて、ＳＥＡＣＯＮエージェントＫはその状態を更新し、全てのドメイン間ユニキャスト・パケットのＤ４内部のセッションフローに使用されるマルチキャスト・パケットへの変換が可能となる。それがその仕事を終えると、ダウンストリームＳＥＡＣＯＮエージェントＬに合図し、それにセッションオブジェクトを各フローに割り当てられたローカルＳＳＭを含めて供給するために、シグナリングプロトコルがトリガーされる。

エージェントＬがそのメッセージを受信すると、それはその状態を更新し（それはこのエージェントに接続されたユニキャストアウェアなユーザへのパケットのマッピングと複製を可能にする）、アプリケーション・プロトコルをトリガーして受信機Ｒ１上のアプリケーションに各セッションフローに割り当てられたローカルＳＳＭについて通知する。次にＲ１上のアプリケーションはこの情報を使用して、例えばＩＧＭＰｖ３（Internet Group Management Protocol、ＲＦＣ３３７６参照）またはＭＬＤｖ２（Multicast Listener Discovery protocol、ＲＦＣ３８１０参照）によって、そのセッションフローと関連付けられた新しいマルチキャストチャネルに参加することが可能である。

次に、図４を参照して、１つのネットワークエージェントから別のネットワークエージェントへ送信元が移動する場合に関連した１つの実施形態を説明する。本例では、送信元はエージェントＦからエージェントＧへ移動する。

新しく付け替った送信元はエージェントＧから進行中のセッションのアクティブ化をエージェントＧに要求する。この際、例えば各ドメインでセッションを要求していた１つ以上のエージェントを含むリストが示される。このリストは今議論しているケースではエージェントＡ（ドメインＤ１）とエージェントＥ（ドメインＤ２）を含む。実施の一形態によれば、それらの状態はセッションがこれらのエージェントでまだ進行中かどうかをチェックするために問い合わせ（query）されるが、これは不可欠というわけではない。しかしながら、セッションがまだアクティブになっているダウンストリームのエージェントを選択することが好ましいことがある。次に、各セッションフローごとにチャネル識別子が要求され、ダウンストリームのエージェント（好ましくは、かつ可能なら、セッションが既にアクティブなもの）が選択され、発信インタフェーステーブルが適宜に更新される。次に進行中のセッションフローに対する接続の再確立を要求するためにメッセージがダウンストリームストリーム方向にアクセスエージェントＡに向けて送信される。続いてエージェントＥは要求されたセッションフローがドメインＤ１に向かうパスにおいて既にアクティブにされていることを確認し、その状態を（到来インタフェーステーブルを新しいＳＳＭチャネルによって更新することによって）更新する。次に接続が再確立され、パケット変換が実行される。次に古いパス上の状態がＰＩＭ−ＳＳＭによって取り除かれる。セッションに参加している全てのアクセスエージェントには告知メッセージを通じてセッションのトランスレータの１つの位置の変更（ＦからＧへ）が通知され、それらはそれらの状態情報を適宜に更新することができる。

送信元が移動する場合のメカニズムは従って受信機が移動する場合と同様である。後者のように、要求されたセッションが既に実行されている最も近いネットワークエージェントが探索される。しかしながら、この場合の探索は受信機においてではなく送信元において開始し、送信元に最も近くセッションが既にアクティブになっているエージェントを探索する。こうして見つかったエージェントへの途上における全てのエージェントに対して、セッションの再確立が要求され、実行される。その先のダウンストリームにおけるエージェント（これらにおいてセッションは既にアクティブになっている）に対しては、アップストリーム方向におけるトランスレータの変更についての情報が提供されるに過ぎない。

受信機が移動する場合と同様に、リクエストがドメインＤ２をエージェントＨを経由して出てドメインＤ１にエージェントＤを経由して入る場合には、それでもなお、セッションが既にアクティブになっているエージェント（本例ではエージェントＡ）が最初に探索されるため、エージェントＧからエージェントＡへのパスにおいてのみ接続が再確立されることになる。続いて必要なところでのみ送信元に向けて接続が再確立される。これはエージェントＡからエージェントＥまで新たな接続が全く必要でなく、エージェントＥからエージェントＧまでのパスだけが新たに確立される必要があることを意味している。それゆえ、本メカニズムは非常に頑強（robust）であり、送信元が移動する場合にも効率的である。

次に図５を参照して本発明の実施形態を更に詳しく説明する。図５は本発明の実施の一形態によるセッション制御メカニズムの動作を説明するためのフロー図である。

ステップ５００において、複数のフローから構成されることがあるセッションにグローバルセッション識別子が割り当てられる。ステップ５０５において、セッションへの参加申込を可能とするためにそのセッションについての情報が発行（パブリッシュ）される。この手続きは、例えば、その情報をそのセッションを受信するネットワークエージェントから、受信機がセッションへの参加を申し込むことができるアクセスエージェントにそれが到達するまで、ダウンストリームに他のネットワークエージェントを経由して転送することによって実行することができる。

ステップ５１０において、受信機は斯かる参加申込メッセージを、一般的にはそのアクセスエージェントを通じて送信する。

ステップ５１５において、この（アクセスエージェントとして働く）ネットワークエージェントが既にセッションを受信しているかどうかをチェックする。受信していなければ、ステップ５２０において、参加申込メッセージが、それがセッションを既に受信しているネットワークエージェントに到達するまで（到達すれば問い合わせ（query）５１５に対する回答は肯定的になる）、アップストリームに転送される。図２Ａに示した例では、これは例えばネットワークエージェントＧに相当する。

次にステップ５２５においてそのネットワークエージェントは既にアクセスエージェントであるかどうかがチェックされる。アクセスエージェントである場合、受信機はセッションに直接参加することができるので以降の手続きは比較的シンプルである。手続きはステップ５３０に進み、チャネル識別子の割当を要求し、発信インタフェーステーブルを更新した後、ステップ５３５においてセッションに受信機が参加する。

しかしながらそのネットワークエージェントがまだアクセスエージェントでない場合には（図２のエージェントＧのように）、ステップ５４０においてセッションが受信機に向けて（towards the receiver）既にアクティブかどうかが確認（verify）される。これは例えば図２Ａに示した例のように、リクエストは受信機Ｒ３から異なるパスを経由して到来するが、エージェントＧ（およびエージェントＥも）は既にその受信機に向けてアクティブなセッションを有している場合に当てはまる。これは受信機が接続された先のドメインをチェックするとともに（この情報は参加申込メッセージと一緒に転送される）、このドメインに向けてセッションが既にアクティブであるかどうかをチェックすることによって調べることができる。斯かる場合におけるセッションについての状態情報は、斯かるチェックを実行することができるように、アクティブなセッションの目標ドメインについての情報、好ましくはセッションパスにおける全てのダウンストリームの目標ドメインについての情報を含む必要があることは容易に明らかである。

図２ＡにおけるエージェントＧのように、チェック結果が肯定的である場合、参加申込メッセージは、例えばそれを次のダウンストリームエージェント（ダウンストリームにおけるエージェント）へ転送することによって、受信機に向けて転送される。図２Ａの例では、これはエージェントＥである。再びステップ５４０におけるチェックが実行され、再びその回答は肯定的である。従って、参加申込メッセージは、ステップ５４５においてダウンストリームへネットワークエージェントＣに向けて転送される。

本ケースでは、ステップ５４０においてセッションが受信機に向けてまだアクティブでないと判断される。これは進行中のセッションは異なるエージェント（エージェントＡ）を通じて実行中であり、参加リクエストは新しいアクセスエージェントによって成されたからである。

それゆえ、ステップ５５０において、（新しい）ダウンストリームセッションフロー（エージェントＣからエージェントＢへ）に対するチャネル識別子が要求され、発信インタフェーステーブルが更新される。このようにしてエージェントＣからエージェントＢへの接続が有効になる。

次にステップ５５５において参加申込メッセージは次のダウンストリームエージェントに転送され、到来インタフェーステーブルが更新される。

ステップ５６０においてアクセスエージェントに到達したかどうかがチェックされる。到達していなければ、手続きは再びステップ５５０に進み、アクセスエージェントに到達するまで、新たなダウンストリームのセッションブランチの確立に備える。

アクセスエージェントに最終的に到達した場合、手続きは更にステップ５３０へ進み、チャネル識別子の割当を要求し、最終的に受信機はアクセスエージェントを介してセッションに参加する。

上記の実施形態の説明から分かるように、セッションアウェアな接続制御は異種ネットワークの境界において、より正確には異種ネットワークの境界に位置するネットワークエージェントにおいて、エンドツーエンドで実行される。ドメインはその境界に位置する１つ以上の、一般的には少なくとも２つのネットワークエージェント（１つは入口エージェントとして働き、もう１つは出口エージェントとして働く）を有する。エージェントそれ自体はセッションアウェアな接続制御の実行と、エンドツーエンドのパスにおける適切な信号伝達を通じてセッションツリーを構築する責務を負う。要求されたセッションが既に進行中である最も近いエージェントを探索し、最小限の数の新しいリンクのみを確立するディストリビューション・ツリー形成メカニズムが提供される。

当業者であれば、上記の実施形態は、ハードウェアによって、ソフトウェアによって、あるいはハードウェアおよびソフトウェアの組み合わせによって実施することができることは理解されよう。本発明の実施形態に関連して説明したモジュールおよび機能は、全体的または部分的に、本発明の実施形態に関連して説明した方法に従って動作するように適切にプログラムされたマイクロプロセッサまたはコンピュータによって実施することができる。本発明の実施形態を実現する装置は例えば本発明の実施形態に記述されたセッションアウェアな接続の制御を実行することができるように適切にプログラムされたネットワーク内のノードまたはその他の構成要素を含むことができる。

本発明の実施形態によれば、コンピュータ上で実行されたときにそのコンピュータが上述した本発明の実施形態に従って動作することを可能にする、データキャリアに格納されたかまたは何らか他の方法で記録媒体もしくは伝送リンクなどの何らかの物理的手段によって具現化されたコンピュータプログラムが提供される。

本発明の実施形態は、例えば、上述したセッションアウェアな接続制御メカニズムに従って動作するようプログラムされたネットワーク内のノードまたはネットワーク内のその他の構成要素によって実施することができる。

本発明の実施形態が適用される一般的な異種ネットワークが混在するシナリオを示す図である。 本発明の実施の一形態によるＳＥＡＣＯＮメカニズムの働きを説明するための図である。 本発明の実施の一形態による到来インタフェーステーブルと発信インタフェーステーブルの実例を示す図である。 受信機がドメイン間で移動する場合の本発明の１つの実施形態を示す図である。 送信元がドメイン内で移動する場合の本発明の１つの実施形態を示す図である。 本発明の実施の一形態によるセッション制御メカニズムの動作を説明するためのフロー図である。

符号の説明

Ａ〜Ｍ ネットワークエージェント
Ｄ１〜Ｄ４ ドメイン
Ｒ１〜Ｒ４ 受信機
Ｓ１〜Ｓ３ 送信元

Claims (16)

1. 異種ネットワークのドメイン間の境界に位置するネットワークエージェントが異種ネットワークにおけるエンドツーエンドのセッションアウェアな接続の制御を実行するための接続制御方法であって、
   エンドツーエンドのパスにおいて一意のグローバルセッション識別子を、各マルチユーザセッションに割り当てるステップと、
   ユニキャストセッションまたはマルチキャストセッションの送信機が、グローバルセッション識別子を含む利用可能なセッションについての情報と、セッションフローおよび送信元アドレスについての情報とを、受信機がそれらのセッションへの参加を申し込むことができるように、それが接続された先のまたはそれが移動する先のネットワークエージェントに発行するステップと
   を有し、
   更なるネットワークエージェントが前記セッションパスにあり、
   前記ネットワークエージェントは、ドメイン内または該ドメイン間においてマルチユーザセッションフローが関連付けられるローカルチャネル識別子の割当の要求を可能にするためのアドレス割当コントローラ・インタフェースを具備しており、
   当該方法は、ネットワークエージェントが関連付けられているドメイン内または該ドメイン間における現セッションについてのセッションごとおよびフローごとの状態を含んでいるマルチユーザセッションについての状態を保持するステップを更に有し、
   前記ネットワークエージェントが前記セッションパスに分散していて、
   当該方法は、
   入口ネットワークエージェントが前記送信元から１つ以上のセッションを受信し、前記送信元からの当該セッションについての情報を発行し、その情報を更なるネットワークエージェントを通じて受信機に向けてダウンストリームに転送するステップと、
   受信機がセッションへの参加の意思があることを示す参加申込メッセージを、アクセスエージェントを介してアプリケーション・プロトコルに従って当該受信機から前記送信元に向けて送信し、そのメッセージを、前記セッションパス内に位置するネットワークエージェントを通じて前記送信元に向けてアップストリームに転送するステップと、
   前記リクエストが受信された各ネットワークエージェントにおいて、要求されたセッションが既にそのネットワークエージェントによって受信されているかどうかを、前記状態情報をクエリーすることによって確認し、受信されていない場合には、前記参加申込メッセージを更にアップストリームに転送するステップと、
   あるネットワークエージェントによって前記セッションが受信されていることが分かった場合には、前記参加申込メッセージをアップストリームに転送することを停止するとともに前記セッションが受信機に向けて既にアクティブになっているかどうかを確認するステップと、
   前記確認の結果が肯定的である場合には、前記アクセスエージェントが属するドメインのネットワークエージェントに向けて、前記参加申込メッセージをダウンストリームに転送するステップと、
   前記確認の結果が否定的な場合には、
   ａ）前記アドレス割当コントローラ・インタフェースから、ダウンストリームのセッションフローへのチャネル識別子の割当を要求し、前記ネットワークエージェントの発信インタフェーステーブルを、当該チャネル識別子と受信機への方向の次のネットワークエージェントのアドレスとによって更新するサブステップと、
   ｂ）受信機に向かってダウンストリームにある次のネットワークエージェントにおいて、到来インタフェーステーブルをセッション識別子およびチャネル識別子についての情報によって更新し、ダウンストリームのセッションフローへのチャネル識別子の割当を要求し、そのネットワークエージェントの発信インタフェーステーブルをそのチャネル識別子と受信機への方向の次のネットワークエージェントのアドレスとによって更新するサブステップと
   を実行するステップと、
   前記アクセスエージェントに到達したかどうかを確認して、到達していない場合には、前記アクセスエージェントに到達するまでサブステップａ）およびサブステップｂ）を繰り返すステップと、
   前記アクセスエージェントに到達した場合には、前記アドレス割当コントローラ・インタフェースから、ダウンストリームのセッションフローへのチャネル識別子の割当を要求し、前記ネットワークエージェントの発信インタフェーステーブルをそのチャネル識別子によって更新し、受信機がこのアクセスエージェントを介して前記セッションに参加するステップと
   を有するセッションアウェア接続制御方法。
2. ネットワークエージェントを通じてセッションを確立するための参加申込メッセージまたはリクエストメッセージを転送するステップと、
   前記メッセージが受信された各エージェントにおけるセッションおよびフローと関連付けられた状態をクエリーするステップと、
   ネットワークエージェントが、前記クエリーから、要求されたマルチユーザセッションフローの接続がアップストリームおよび／またはダウンストリームのセッションパスに向けて既にアクティブにされていることを検出したら、エンドツーエンドではなくそれ自体と宛先に向かってアップストリームおよび／またはダウンストリームにおける次のエージェントとの間のパスにおける接続を構築または再構築することを試みるステップと
   を更に含み、
   前記参加申込メッセージが新しくセッションに参加するために受信機によって送信されたメッセージであり、前記リクエストメッセージは新しいアクセスエージェントに移動した送信元によって送信されたメッセージである、請求項１に記載のセッションアウェア接続制御方法。
3. ユニキャストアウェアなドメイン内または該ドメイン間リンク内の２つ以上のネットワークエージェントが同じセッションフローを要求する場合において、パケットを変換し、それらをこれらのネットワークエージェントに複製するステップを更に含む請求項１または２に記載のセッションアウェア接続制御方法。
4. 前記保持された状態情報はセッションフローを要求した受信機のドメイン識別子とその受信機のドメインに向けたセッションに関連するダウンストリームエージェントのアドレスとについての情報を含み、当該方法は、
   ネットワークエージェントがセッションフローのリクエストを受信した場合には、その状態のクエリーに基づいてそのセッションフローが当該リクエスタのドメインに既に存在しているかどうかを確認するステップと、
   接続が既に存在している場合には、そのメッセージをそれが当該リクエスタのドメインの入口エージェントに到達するまで次のダウンストリームエージェントに転送するステップと、
   当該参加リクエストが新たなアクセスエージェントまたは受信機からのものである場合には、その新たなネットワークエージェントまたは受信機に向けたチャネル識別子の割当を要求するとともに、発信インタフェーステーブルをその新たなネットワークエージェントまたは受信機についての情報によって更新するステップと
   を更に含む請求項１〜３のいずれかに記載のセッションアウェア接続制御方法。
5. 前記ネットワークエージェントは、
   パケットを、マルチキャストからユニキャストへ変換するためのモジュールと、マルチキャストからマルチキャストへ変換するためのモジュールと、ユニキャストからユニキャストへ変換するためのモジュールをサポートする接続制御モジュールとを更に具備し、当該方法は、
   異なるマルチキャストスキームの間の接続、マルチキャストスキームとユニキャストスキームとの間の接続、および１つのユニキャスト送信元と複数のユニキャスト受信機との間の接続を可能とするために、前記モジュールがパケットを適切に変換し、必要に応じてそれらを複製するステップを更に含む請求項１〜４のいずれかに記載のセッションアウェア接続制御方法。
6. 更なる受信機が既にアクティブなセッションへの参加申込メッセージを同じアクセスエージェントを介して送信する場合、このアクセスエージェントはその発信インタフェーステーブルを前記更なる受信機のポートおよび宛先ＩＰアドレスを含めることによって更新し、前記既にアクティブなセッションから到来するパケットを複製してそれらを前記更なる受信機へ転送する請求項１〜５のいずれかに記載のセッションアウェア接続制御方法。
7. セッションのパスは複数のドメインを通過し、
   前記ネットワークエージェントは前記複数のドメインの境界に位置している、請求項１〜６のいずれかに記載のセッションアウェア接続制御方法。
8. 前記ネットワークエージェントは、セッション／アプリケーション・プロトコルへのインタフェースを具備しており、セッション／アプリケーション・プロトコルはこのインタフェースを使用して、マルチユーザセッションの接続の生成、複製、削除、変更または更新のいずれか１つを要求することによってマルチユーザセッションの接続制御を要求し、当該方法は、
   セッションに対するチャネル識別子が設定されたらすぐに接続が確立されることを要求するステップを含む請求項１〜７のいずれかに記載のセッションアウェア接続制御方法。
9. 異種ネットワークのドメイン間の境界に位置するネットワークエージェントが異種ネットワークにおけるエンドツーエンドのセッションアウェアな接続の制御を実行するための装置であって、
   エンドツーエンドのパスにおいて一意のグローバルセッション識別子を、各マルチユーザセッションに割り当てるためのモジュールと、
   ユニキャストセッションまたはマルチキャストセッションの送信機が、グローバルセッション識別子を含む利用可能なセッションについての情報とセッションフローおよび送信元アドレスについての情報とを、受信機がそれらのセッションへの参加を申し込むことができるように、それが接続された先のまたはそれが移動する先のネットワークエージェントに発行するためのモジュールと
   を有し、
   更なるネットワークエージェントが前記セッションパスにあり、前記ネットワークエージェントは、ドメイン内または該ドメイン間においてマルチユーザセッションフローが関連付けられるローカルチャネル識別子の割当の要求を可能にするためのアドレス割当コントローラ・インタフェースを具備し、
   当該装置は、ネットワークエージェントが関連付けられているドメイン内または該ドメイン間における現セッションについてのセッションごとおよびフローごとの状態を含んでいるマルチユーザセッションについての状態を保持するためのモジュールを更に有し、
   前記ネットワークエージェントが前記セッションパスに分散していて、
   当該装置は、
   入口ネットワークエージェントが前記送信元から１つ以上のセッションを受信し、前記送信元からの当該セッションについての情報を発行し、その情報を、更なるネットワークエージェントを通じて受信機に向けてダウンストリームに転送するためのモジュールと、
   受信機からアプリケーション・プロトコルに従ってこの受信機がセッションへの参加の意思があることを示す参加申込メッセージを、アクセスエージェントを介して前記送信元に向けて送信し、そのメッセージを、前記セッションパス内に位置するネットワークエージェントを通じて前記送信元に向けてアップストリームに転送するためのモジュールと、
   前記リクエストが受信された各ネットワークエージェントにおいて、要求されたセッションが既にそのネットワークエージェントによって受信されているかどうかを前記状態情報をクエリーすることによって確認し、受信されていない場合には、前記参加申込メッセージを更にアップストリームに転送するためのモジュールと、
   あるネットワークエージェントによって前記セッションが受信されていることが分かった場合には、前記参加申込メッセージをアップストリームに転送することを停止するとともに前記セッションが受信機に向けて既にアクティブになっているかどうかを確認するためのモジュールと、
   前記確認の結果が肯定的である場合には、前記アクセスエージェントが属するドメインのネットワークエージェントに向けて、前記参加申込メッセージをダウンストリームに転送するためのモジュールと、
   前記確認の結果が否定的な場合には、
   ａ）前記アドレス割当コントローラ・インタフェースから、ダウンストリームのセッションフローへのチャネル識別子の割当を要求し、前記ネットワークエージェントの発信インタフェーステーブルを、当該チャネル識別子と受信機への方向の次のネットワークエージェントのアドレスとによって更新するためのステップと、
   ｂ）受信機に向かってダウンストリームにある次のネットワークエージェントにおいて、到来インタフェーステーブルをセッション識別子およびチャネル識別子についての情報によって更新し、ダウンストリームのセッションフローへのチャネル識別子の割当を要求し、そのネットワークエージェントの発信インタフェーステーブルをそのチャネル識別子と受信機への方向の次のネットワークエージェントのアドレスとによって更新するためのステップとを実行するためのモジュールと、
   前記アクセスエージェントに到達したかどうかを確認して、到達していない場合には、前記アクセスエージェントに到達するまでステップａ）およびステップｂ）を繰り返すためのモジュールと、
   前記アクセスエージェントに到達した場合には、前記アドレス割当コントローラ・インタフェースから、ダウンストリームのセッションフローへのチャネル識別子の割当を要求し、前記ネットワークエージェントの発信インタフェーステーブルをそのチャネル識別子によって更新し、受信機がこのアクセスエージェントを介して前記セッションに参加するためのモジュールと
   を有するセッションアウェア接続制御装置。
10. ネットワークエージェントを通じてセッションを確立するための参加申込メッセージまたはリクエストメッセージを転送するためのモジュールと、
    前記メッセージが受信された各エージェントにおけるセッションおよびフローと関連付けられた状態をクエリーするためのモジュールと、
    ネットワークエージェントが、前記クエリーから、要求されたマルチユーザセッションフローの接続がアップストリームおよび／またはダウンストリームのセッションパスに向けて既にアクティブにされていることを検出したら、エンドツーエンドではなくそれ自体と宛先に向かってアップストリームおよび／またはダウンストリームにおける次のエージェントとの間のパスにおける接続を構築または再構築することを試みるためのモジュールと
    を更に含み、
    前記参加申込メッセージは新しくセッションに参加するために受信機によって送信されたメッセージであり、前記リクエストメッセージは新しいアクセスエージェントに移動した送信元によって送信されたメッセージである、請求項９に記載のセッションアウェア接続制御装置。
11. ユニキャストアウェアなドメイン内または該ドメイン間リンク内の２つ以上のネットワークエージェントが同じセッションフローを要求する場合において、
    パケットを変換し、それらをこれらのネットワークエージェントに複製するためのモジュールを更に含む請求項９または１０に記載のセッションアウェア接続制御装置。
12. 前記保持された状態情報はセッションフローを要求した受信機のドメイン識別子とその受信機のドメインに向けたセッションに関連するダウンストリームエージェントのアドレスとについての情報を含み、
    ネットワークエージェントがセッションフローのリクエストを受信した場合には、その状態のクエリーに基づいてそのセッションフローが当該リクエスタのドメインに既に存在しているかどうかを確認するためのモジュールと、
    接続が既に存在している場合には、そのメッセージをそれが当該リクエスタのドメインの入口エージェントに到達するまで次のダウンストリームエージェントに転送するためのモジュールと、
    当該参加リクエストが新たなアクセスエージェントまたは受信機からのものである場合には、その新たなネットワークエージェントまたは受信機に向けたチャネル識別子の割当を要求するとともに、発信インタフェーステーブルをその新たなネットワークエージェントまたは受信機についての情報によって更新するためのモジュールと
    を更に含む請求項９〜１１のいずれかに記載のセッションアウェア接続制御装置。
13. 前記ネットワークエージェントは、パケットを、マルチキャストからユニキャストへ変換するためのモジュールと、マルチキャストからマルチキャストへ変換するためのモジュールと、ユニキャストからユニキャストへ変換するためのモジュールをサポートする接続制御モジュールを更に具備し、
    異なるマルチキャストスキームの間の接続、マルチキャストスキームとユニキャストスキームとの間の接続、および１つのユニキャスト送信元と複数のユニキャスト受信機との間の接続を可能とするために、前記モジュールはパケットを適切に変換し、必要に応じてそれらを複製する、請求項９〜１２のいずれかに記載のセッションアウェア接続制御装置。
14. 更なる受信機が既にアクティブなセッションへの参加申込メッセージを同じアクセスエージェントを介して送信する場合、このアクセスエージェントはその発信インタフェーステーブルを前記更なる受信機のポートおよび宛先ＩＰアドレスを含めることによって更新し、前記既にアクティブなセッションから到来するパケットを複製してそれらを前記更なる受信機へ転送する、請求項９〜１３のいずれかに記載のセッションアウェア接続制御装置。
15. セッションのパスは複数のドメインを通過し、
    前記ネットワークエージェントは前記複数のドメインの境界に位置している、請求項９〜１４のいずれかに記載のセッションアウェア接続制御装置。
16. コンピュータ上で実行されたときにこのコンピュータが請求項１〜８のいずれかに記載された方法を実行することを可能にするコンピュータプログラムコードから成るコンピュータプログラム。

Images