JP2008538885A - アクセスドメイン上でサービスバインディングを管理する方法、およびアクセスノード - Google Patents

Abstract

本発明は、アクセスドメイン上でサービスバインディングを管理する方法およびノードに関する。このために、アクセスドメイン上で複数のサービスプロバイダとユーザドメインとの間にアクセスエッジノードが導入され、ユーザドメインとアクセスドメインとの間にアクセスノードが導入される。アクセスエッジノードは、サービスバインディングを生成、修正、および削除し、サービスバインディングの生成、修正および削除をアクセスノードに通知する。各サービスバインディングは、ユーザドメインとサービスプロバイダドメインとの間のアクセスドメイン上で処理するデータトラフィックに関して、ユーザドメインの１つ、アクセスノード、およびアクセスエッジノードを結合する。サービスバインディングは、サービスプロバイダのために、アクセスエッジノードにより制御されるアクセスドメイン上でユーザドメインをＶＬＡＮに関連付ける。
【選択図】図３

Description

本特許出願は、発明者Sylvain Monette、Mathieu Giguere、Martin Julien、およびBenoit Tremblayにより“Access node-edge node complex protocol (AEP)”として2005年４月２５日に出願された米国特許出願60/674,307の優先権を主張するものである。

本発明は、アクセスドメイン上でサービスバインディングを管理する方法、および本方法によりサービスバインディングを管理するアクセスノードおよびアクセスエッジノードに関するものである。

（関連技術の説明）
近年、インターネットプロトコル（ＩＰ）ネットワークが急増している。当初、研究プロジェクト中の連絡および協力を大学および研究者に可能にならしめるために開発されたＩＰネットワークは、大量市場レベルで提供されるネットワークに成長している。今日、ＷＷＷ（World Wide Web）をサーフし、双方向型のゲームを楽しみ、ＩＰ上で音声を伝え、書類およびソフトウェアウェアをダウンロードし、電子商取引などをするために、ＩＰネットワークへの接続を家庭内に有することは一般的である。

ＩＰネットワーク１００の従来技術を例示する図１が参照される。通常、ＩＰネットワークは、アクセスドメイン１１５、ネットワークサービスプロバイダドメイン１４０、およびアプリケーションサービスプロバイダドメイン１５０からなる。アクセスドメイン１１５は、アクセスノード（ＡＮ）１２０、および例えばＩＰネットワークなどのアクセスネットワーク１３０を含む。ＡＮ１２０は、ユーザドメイン１１０にＩＰネットワーク１３０へのアクセスを提供可能なネットワークプロバイダである。ユーザドメイン１１０は、例えば、ユーザデバイス（ＵＤ）（コンピュータ、移動電話、ＰＤＡなど）、ローカルエリアネットワーク（ＬＡＮ）、および無線ＬＡＮ（Ｗ−ＬＡＮ）を含む。ユーザドメインは、各種の考えられる技術を介してＡＮと通信する。これらの技術としては、ダイアルアップ接続、電話線上のＡＤＳＬ接続、テレビケーブルネットワークを接続するケーブルモデム、または無線通信が挙げられる。アクセスネットワーク１３０は、入来するデータトラフィックをデータに埋め込まれた宛先アドレスに基づいてルーティングすることをタスクとする独立ルータのグループからなる。ネットワークサービスプロバイダドメイン１４０は、例えばＶｏＩＰ（Voice over IP）サービスに対応し、アプリケーションサービスプロバイダドメイン１５０は、電子決済および電子商取引に対応している。

図１は、３つのユーザドメイン、２つのアクセスノード、２つのサービスプロバイダドメイン、および２つのアプリケーションサービスプロバイダドメインを示すが、ＩＰネットワーク１００は、通常、数千のユーザドメイン、数十のアクセスノード、数百のサービスプロバイダドメインおよびアプリケーションサービスプロバイダドメインを含む。アクセスネットワーク１３０は、一般に数百のルータを含むネットワークである。よって、図１は、説明のために非常に簡略化されたＩＰネットワーク１００を示すものとして理解される。

ＩＰネットワーク上でデータトラフィックおよびメッセージの調整された交換を確保するために、１９７０年代初期にＩＰプロトコルが開発された。ＩＰバージョン４（ＩＰｖ４）は、現在展開されているＩＰネットワークの大半により用いられている。ＩＰｖ４は、３２ビットを用いたアドレス方式を提供し、各々に固有であり１つのデバイスを直接特定する4, 294, 967, 296個のアドレスを提供する。例えば図１に示したＩＰネットワーク１００の場合、ネットワークは、ＩＰネットワーク１００を通じてデータトラフィックおよびメッセージの高速かつ簡単な伝送を提供するイーサネットベースのデータリンクに依存することが一般に知られている。

しかし、ＩＰネットワーク上で通信するデバイスの増加、およびＩＰｖ４特有の制限により、ＩＰコミュニティは、ＩＰの新バージョン、ＩＰバージョン６（ＩＰｖ６）を必要としている。新バージョンは、１２８ビットを用いたアドレス方式に依存し、より多くのアドレスを提供する。

ＩＰｖ６は、より多くのＩＰアドレスを準備し、ＩＰｖ４の問題にも対処しているが、ＩＰｖ４およびＩＰｖ６は、“ベストエフォート”型のプロトコルである。“ベストエフォート”とは、データトラフィックの種類に応じて要求されるサービス品質に対するより高い要求または特定の要求を満たすための特別な努力をせずに、ネットワークがデータトラフィックを配信することを意味する。このことは、一部のネットワークサービスプロバイダ１４０およびアプリケーションサービスプロバイダ１５０では十分であるが、残念ながら、他では不十分となることが判明している。よって、一部のネットワークサービスプロバイダ１４０およびアプリケーションサービスプロバイダ１５０は、ＩＰネットワーク１００上で容易かつ円滑にサービスを提供することができない。

この問題を解決するために、マルチプロトコルラベルスイッチング（ＭＰＬＳ）がＩＰネットワーク上で用いられる。ＭＰＬＳは、ＩＰネットワーク１００上で特定のサービス品質を伴うパスを予約するために、例えばリザベーションプロトコル（ＲＳＶＰ）に依存する。ＲＳＶＰは、まず、ルータの組を通じてパスを形成する。パスを形成するために、各ルータは、そのＭＰＬＳテーブルにエントリを追加する。エントリは、特定のエントリポートに到来し、予め定められたラベル、対応する出力ポート、および使用されるべきラベルを有するデータトラフィックを示す。このようなリザーブパスをＩＰネットワーク１００上で形成することにより、ＲＳＶＰは、ネットワークサービスプロバイダ１４０およびアプリケーションサービスプロバイダ１５０のより広い範囲でデータトラフィックを運ぶことを可能にする。

しかし、“ベストエフォート”よりも高いサービス品質を要求するネットワークサービスプロバイダ１４０およびアプリケーションサービスプロバイダ１５０の増加、ならびにユーザドメイン１１０の増加、およびアクセスネットワーク１３０の利用をユーザドメイン１１０に可能ならしめるアクセスノード１２０の増加により、ＭＰＬＳは、良好な選択肢とならないことが判明している。

ＩＰネットワークの根底をなす初期の原理は、入来するデータトラフィックを最終宛先へルーティングする前に可能な限り少ない演算を実行するルータに依存するものである。また、“ベストエフォート”型ネットワークがサービス品質とデータトラフィック量との間で二律背反することは、広く認識されている。ルータの数が同一でサービス品質が増加すると、ルータ上でトランスポートされるデータトラフィックの量が低下する。ＩＰネットワークは、より高いレベルのサービス品質を考慮して設計されていない。よって、ＩＰネットワーク上でより高いレベルのサービス品質のためにリザーブパスを形成することにより、ＩＰネットワーク上でデータトラフィック量が低下してしまう。さらに、ＭＰＬＳのために必要とされるリザーブパスにより、リザーブパス上の各ルータで、より多くのルーティングエフォートが消費されてしまう。このようなルーティングエフォートは、２、３のリザーブパスが同時にオープンされている場合には顕著なものではないが、“ベストエフォート”以上のサービス品質を要求するサービスアプリケーションの最近の動向によれば、ＩＰネットワーク上で数千のリザーブパスが同時に要求されるようになることを予測することができる。多くのリザーブパスを伴うデータトラフィックを維持およびルーティングすることは、より大きな負担をルータに課すこととなり、よって、影響を受けるルータのルーティング性能を低下させてしまう。よって、サービス品質の向上のためにＩＰネットワーク上でＭＰＬＳを利用することは、データトラフィックの交換量を低下させ、データトラフィックを低速化させる。このような影響は、リザーブパス以外の全てのデータトラフィックに直接作用するので容認することができない。

ユーザデバイスおよびＩＰネットワーク上でサービスを提供するサービスプロバイダの急増に関連する問題に対する解決策は、現在知られていない。さらに、特定のサービスおよびアプリケーションのために増加されたＱｏＳの必要性に対する実現可能かつ有効な長期的解決策は、特定されていない。

よって、既存の解決策の欠点を解消するために、サービスバインディングの管理された利用を通じてアクセスネットワークを効率的に調整利用するための方法およびノードを有することは利点となる。本発明は、そのような方法およびノードを提供するものである。

（発明の要旨）
本発明は、サービスバインディングを効率的に管理することにより、数千のネットワークサービスプロバイダドメインおよびアプリケーションサービスプロバイダドメインにアクセスドメイン上で通信することを効率的に可能ならしめる。本発明のサービスバインディングを管理する方法およびノードは、アクセスドメインの調整された利用に依存する。

このために、本発明は、第１の観点において、アクセスドメイン上でサービスバインディングを管理する方法として具現化される。本方法は、アクセスエッジノードでサービス要請関連メッセージを受信することにより開始する。サービス要請関連メッセージは、ユーザドメインの第１デバイスのために受信され、選択されたサービスプロバイダドメインを特定する。本方法は、アクセスエッジノードでのサービスバインディングの生成により継続する。サービスバインディングは、ユーザドメインの第１デバイスとサービスプロバイダドメインとの間のデータトラフィックを規制するエンティティであり、そのために、ユーザドメインの第１デバイスとサービスプロバイダドメインとの間のデータトラフィックを管理する、ユーザドメインにサービスするアクセスノードおよびサービスプロバイダドメインを示すアクセスエッジノードをコミットする。アクセスエッジノードでサービスバインディングが生成されると、アクセスエッジノードは、そのためにサービス要請関連メッセージが受信されたユーザドメインにサービスするアクセスノードに通知する。そして、本方法は、ユーザドメインの第１デバイスとサービスプロバイダドメインとの間のデータトラフィックのために、生成されたサービスバインディングをアクセスノードおよびアクセスエッジノードで実行する。

他の観点において、本発明は、アクセスドメイン上でサービスバインディングを管理するアクセスエッジノードに関する。アクセスエッジノードは、ユーザドメインとサービスプロバイダドメインとの間で、アクセスドメイン内に位置するノードである。サービスバインディングを管理するために、アクセスエッジノードは、入出力ユニット、サービスエージェントユニット、および制御ユニットを含む。入出力ユニットは、ユーザドメインの第１デバイスのために、選択されたサービスプロバイダドメインを特定するサービス要請関連メッセージを受信する。サービスエージェントは、アクセスドメイン上でユーザドメインの第１デバイスとサービスプロバイダドメインとの間のデータトラフィックを規定するサービスバインディングを生成する。また、サービスバインディングは、ユーザドメインの第１デバイスとサービスプロバイダドメインとの間のデータトラフィックを管理する、ユーザドメインにサービスするアクセスノードおよび選択されたサービスプロバイダドメインを示すアクセスエッジノードをコミットする。制御ユニットは、そのためにサービス要請関連メッセージが受信されたユーザドメインにサービスするアクセスノードに入出力ユニットを通じて通知する。制御ユニットは、また、ユーザドメインの第１デバイスと選択されたサービスプロバイダドメインとの間のデータトラフィックのために、生成されたサービスバインディングをアクセスエッジノードで実行する。

他の観点において、本発明は、ユーザドメインとアクセスドメインとの間でアクセスドメイン内に位置するアクセスノードに関する。アクセスノードは、アクセスドメイン上でサービスバインディングを管理するためのエレメントを含む。このために、アクセスノードは、入出力ユニット、集約ユニット、および制御ユニットを含む。入出力ユニットは、アクセスドメイン上でユーザドメインからのデータトラフィックを転送し、サービスバインディング関連メッセージを受信する。集約ユニットは、サービスバインディングを格納し、格納されたサービスバインディングを実行する。制御ユニットは、集約ユニットおよびアクセスドメイン入出力ユニットと電子的に接続される。制御ユニットは、入出力ユニットで受信されたデータトラフィックを制御し、サービスバインディングを管理する。このために、制御ユニットは、入出力ユニットで受信されたサービスバインディング関連メッセージを評価し、評価に応じて集約ユニットを更新する。また、制御ユニットは、格納されたサービスバインディングに従って、ユーザドメインからのデータトラフィックを制御する。

本発明の創造的な知見は、各種の例示的な実施形態を具体的に参照して説明される。しかし、これらの実施形態は、本発明の創造的な知見の多くの好適な利用のうちいくつかの例のみを提供するものであることが理解される。本出願の明細書に含まれる一般的な記述は、本発明の様々な主張された側面のいずれかに限定される必要はない。さらに、いくつかの記述は、発明のいくつかの特徴には適用できるが、他の特徴には適用できない場合もある。図面の説明では、発明の同一または同様な要素が同一の参照番号で表されている。

本発明は、各種サービスプロバイダドメインと通信する複数のユーザドメインから／複数のユーザドメインへのサービスバインディングを効率的に管理するための方法およびノードを提供する。このために、ユーザドメインとサービスプロバイダドメインとの間では、アクセスドメイン内にアクセスエッジノードが導入される。アクセスエッジノードは、サービスエージェントを管理および制御するサービスエージェントユニットを含む。各サービスエージェントは、一方ではサービスプロバイダドメインの１つに対応し、そのために他方ではアクセスドメイン上で仮想ローカルエリアネットワーク（ＶＬＡＮ）を管理および制御する。選択されたサービスプロバイダドメインの１つとの通信をユーザドメインが望むと、サービス要請関連メッセージがアクセスエッジノードへ送信される。

サービス要請関連メッセージは、サービスプロバイダドメインの１つおよびユーザドメインの１つを特定する情報を含む。アクセスエッジノードは、サービス要請関連メッセージ中で特定されるサービスプロバイダドメインにサービスエージェントの１つが対応するかを判定し、対応する場合には受信したサービス要請関連メッセージのためにサービスバインディングを生成する。サービスバインディングは、サービスエージェントの１つ、ユーザドメイン情報、およびアクセスドメイントランスポートプリミティブを特定する。そして、要請するユーザドメインにサービスするアクセスノードは、サービスバインディングの生成を通知され、生成されたサービスバインディングにより両者間でデータトラフィックを統合するために、アクセスノードおよびアクセスエッジノードでサービスバインディングの実施が行われる。以下では、サービスバインディングを管理するために、サービスエージェント、サービスバインディング、アクセスエッジノードおよびアクセスノードを関連付ける方法について詳細に説明する。

本明細書では、データネットワーク上で伝送されるメッセージおよび情報に関連して、“データトラフィック”という用語が用いられる。

本発明およびその創造的メカニズムを理解するために、本発明が組込まれるネットワーク２００を例示する概略図である図２が参照される。ネットワーク２００の概略図は、説明のために簡略化されており、各種エレメントは、地理的なネットワークエンティティを図式的に示す代わりに同様な機能により分類されて示されている。しかし、同様な機能の各グループは、特定の機能を実行し、ネットワーク２００内で地理的に点在する多くの物理的なネットワークエンティティに対応する。ネットワーク２００の概略図は、ユーザドメイン１１０、アクセスドメイン１１５（アクセスノード１２０、アクセスネットワーク１３０、アクセスエッジノード１６０、および地域ネットワーク１３５を含む）、ネットワークサービスプロバイダ１４０、アプリケーションサービスプロバイダ１５０を含む。以下では、図２を参照しながら、各エレメントの包括的な説明および例が提供される。

ネットワーク２００は、相互通信する１つ以上のデータネットワークに相当する。よって、ネットワーク２００は、１つ以上のオペレータにより運用可能である。データネットワークは、通常多くの異なる運用エンティティおよび／または運組織によりサポートされるので、それらのエンティティおよび組織が良好に通信可能な方法を定義することが必要である。このため、データネットワークは、通常、オープンシステムインターコネクション（ＯＳＩ）モデルを用いて、説明および詳述される。ＯＳＩモデルは、プロトコルを実施するネットワークフレームワークを７つの層に定義する。７つの層は、１）物理層、２）データリンク層、３）ネットワーク層、４）トランスポート層、５）セッション層、６）プレゼンテーション層、および７）アプリケーション層からなる。各層は、データネットワーク上でデータ送信を実行する際に考慮されるべき側面および実行されるべきアクションに対応している。本発明のネットワーク２００をＯＳＩモデルを用いて説明すれば、本発明のネットワークにより利用および／またはサポートされる各種プロトコルを以下のように階層化することができる。

第２層：イーサネット、非対称伝送モード
第３層：ＩＰｖ４、ＩＰｖ６
第４層、第５層：送信制御プロトコル（ＴＣＰ）およびユーザデータグラムプロトコル（ＵＤＰ）
第６層、第７層：既存および将来的な各種プレゼンテーションおよびアプリケーションプロトコル

上記プロトコルのリストは、例示のために提供されるものであり、本発明によりサポートされるプロトコルを限定するものではない。

アクセスドメイン１１５は、ユーザドメイン１１０とネットワークサービスプロバイダ１４０およびアプリケーションサービスプロバイダ１５０との間でエンドツーエンドアクセスを提供する手段として機能する。アクセスドメインは、アクセスノード１２０、アクセスネットワーク１３０、地域ネットワーク１３５、およびアクセスエッジノード１６０を含む。よって、アクセスドメイン１１５は、それ自体エンティティではなく、直接的または間接的に相互接続されてアクセスを提供するドメインとして機能するコンポーネントの集合体であるため、“アクセスドメイン”と称される。よって、１つのアクセスノード１２０、１つのアクセスネットワーク１３０、１つのアクセスエッジノード１６０、および１つの地域ネットワーク１３５のみを含むアクセスドメインの表記は、このようなエンティティがアクセスドメイン内に単一で存在することを意味せず、説明のために１つのエンティティのみが表記されている。以下では、アクセスドメインの各種コンポーネントの詳細について説明する。

アクセスゲートウェイ（不図示）も含むアクセスノード１２０は、アクセスドメイン１１５の第１コンポーネントを表す。アクセスノード１２０は、例えば加入権または従量課金制に基づいて、アクセスネットワーク１３０へのアクセスをユーザドメイン１１０に可能ならしめるアクセスプロバイダを一般に参照している。このようなアクセスは、各種の媒体および技術を用いて実行可能である。考えられる媒体として、ケーブル、固定電話、および無線電話が挙げられる。考えられる技術として、総合デジタル通信網（ＩＳＤＮ）、非対称型デジタル加入者回線（ＡＤＳＬ）、ＩＥＥＥ８０２．１６規格（ＷｉＭａｘ: Worldwide Interoperability for Microwave Access）が挙げられる。しかし、本発明は、これらの媒体および技術に限定されるものではない。また、３つのアクセスノードのみが示されているが、ネットワーク２００は、数百または数千のアクセスノードを含む可能性がある。

アクセスドメインは、また、併せて説明するアクセスネットワーク１３０および地域ネットワーク１３５を含む。アクセスネットワーク１３０および地域ネットワーク１３５の基本機能は、アクセスノード１２０とネットワークサービスプロバイダ１４０およびアプリケーションサービスプロバイダ１５０との間でエンドツーエンドの独立したトランスポートを提供することである。アクセスネットワーク１３０および地域ネットワーク１３５は、例えば、集約（aggregate）、スイッチング、およびダウンストリーム／アップストリームでのデータトラフィックのルーティングなどのタスクを実行可能なネットワークである。アクセスネットワーク１３０は、非限定的に、例えば、ＯＳＩモデルの第２層に対応する、イーサネットまたは他の同様なプロトコルを利用可能であることが望ましい。アクセスネットワーク１３０は、ＩＰｖ４および／またはＩＰｖ６をサポート可能であることが望ましい。地域ネットワーク１３５は、イーサネットおよび／またはＩＰおよびＭＰＬＳ、および他の第３層プロトコルをサポートすることが望ましい。さらに、アクセスネットワーク１３０および地域ネットワーク１３５は、単一のオペレータまたは多くの異なるオペレータにより運用および／または管理可能である。

アクセスネットワーク１３０および地域ネットワーク１３５は、アクセスエッジノード１６０を通じたトラフィック技術能力の密結合（tight coupling）を通じて、エンドツーエンドのサービス品質（ＱｏＳ）を提供可能である。アクセスエッジノード１６０の役割は、サービスエージェント１７０およびサービスバインディングの生成、管理、およびホスティングである（図２に示されていないが図４に示されている。）。各サービスエージェント１７０は、サービスプロバイダドメイン（１４０または１５０）の１つに対応し、そのためにアクセスネットワーク１３０上でＶＬＡＮを管理および制御する。“サービスバインディング”という表現は、ユーザドメイン１１０と、ネットワークサービスプロバイダドメイン１４０の１つまたはアプリケーションサービスプロバイダドメイン１３０の１つとの間の結合を参照している。アクセスエッジノード、およびサービスエージェント、およびサービスバインディングの概念については、図４、５ａ、５ｂを参照しながら、さらに詳細に説明する。

ユーザドメイン１１０は、ネットワークサービスプロバイダドメイン１４０およびアプリケーションサービスプロバイダドメイン１３０とのエンドツーエンド通信を処理するアクセスドメイン１１５に依存する。本説明では、“ドメイン”という用語は、同様な機能的特徴を共有する１つ以上のネットワークエレメントを参照している。よって、本発明に関連して、“ユーザドメイン”という表現は、独立したコンピュータ、ルータを通じて有線または無線で接続されたコンピュータのローカルネットワーク、無線電話、ＰＤＡ、および、例えばネットワーク２００などのデータネットワーク上でデータ通信を実行可能な他の全てのデバイスを参照している。また、“ユーザドメイン”という表現は、単一のユーザポートを通じて多数のデバイスにより実行される複数同時データトラフィックセッションも含むことを意図している。例えば、ユーザは、インターネットアクセス、ビデオ会議、およびテレビジョンプログラムなど、異なるアプリケーションおよびネットワークサービスに、ＶＬＡＮに位置するユーザドメインを通じて、または“ユーザドメイン”として参照される単一のユーザポートを通じて、１つ以上のデバイスにより同時にアクセス可能である。

ネットワークサービスプロバイダ１４０は、ＩＰアドレス指定および他のＩＰネットワークへの接続性を提供し特定のアプリケーションを提供および配信するために、アクセスドメイン１１５を用いるエンティティを参照している。ユーザドメイン１１０とのデータトラフィックに関連して、ネットワークサービスプロバイダ１４０は、ＩＰアドレスを所有し、例えばＲＡＤＩＵＳ（Remote Authentication Dial-In User Service）などに基づく識別を用いてユーザドメイン１１０に割当てる。ネットワークサービスプロバイダ１４０は、希望および／または必要に応じて、ユーザレベルの認証および承認を実行してもよい。

アプリケーションサービスプロバイダ１５０は、ユーザドメイン１１０のエンドユーザへアプリケーションを提供および配信するために、アクセスドメイン１１５を用いる。このようなアプリケーションの例として、ゲーム、ビデオオンデマンド、ビデオ会議、および他の多くのアプリケーションが挙げられる。しかし、アクセスドメイン１１５は、アプリケーションサービスプロバイダの代わりにユーザドメイン１１０にＩＰアドレスを割当てる。希望に応じて、アプリケーションサービスプロバイダ１５０は、ユーザレベルで認証を実行可能であり、必要に応じて承認を実行可能である。以下の説明では、“サービスプロバイダ（service providers）”および“サービスプロバイダドメイン”という表現は、ネットワークサービスプロバイダ１４０およびアプリケーションサービスプロバイダ１５０の双方を同時に示すためにも用いられ、“サービスプロバイダ（service provider）”という表現は、ネットワークサービスプロバイダ１４０の１つまたはアプリケーションサービスプロバイダ１５０の１つを示すために用いられる。

本発明に基づくサービスバインディングを管理する方法の簡略化されたフロー図である図３が参照される。本方法は、複数のネットワークサービスプロバイダ１４０およびアプリケーションサービスプロバイダ１５０とユーザドメイン１１０との間でデータトラフィックをトランスポートするアクセスドメイン１１５上でサービスバインディングの管理を実行する。本方法は、アクセスエッジノード１６０で複数のサービスエージェントを確立するステップ３００により選択的に開始される。しかし、複数のサービスエージェントを確立するステップ３００は、毎回実行されずに、アクセスエッジノード１６０がアクセスドメイン１１５に導入されるときに実行される。そして、本方法は、アクセスエッジノード１６０でサービス要請関連メッセージを受信するステップ３１０により開始する。サービス要請関連メッセージは、サービスプロバイダの１つおよびユーザドメインの１つを特定する。サービス要請関連メッセージは、例えば、特定されたユーザドメインが特定されたサービスプロバイダのウェブページへアクセスすることを通じて生成されている。本方法は、確立されたサービスエージェントの１つが特定されたサービスプロバイダ１４０または１５０に対応するかを識別するステップ３２０により続行する。そして、本方法は、新たなサービスバインディングが必要とされているかを判定するステップ３３０を有する。判定ステップ３３０の結果が肯定的である場合、本方法は、受信されたサービス要請関連メッセージのためのサービスバインディングを生成するステップ３４０により続行する。本方法は、そして、サービス要請関連メッセージ中で特定されたユーザドメインへのアクセスの提供に関与するアクセスノード１２０に、サービスバインディングの生成を通知するステップ３５０により継続する。アクセスノード１２０は、よって、生成されたサービスバインディングにより、サービス要請関連メッセージ中で特定されたユーザドメインから受信され、特定されるサービスプロバイダにアドレス指定されているデータトラフィックがアクセスドメイン上で集約されるべきであることを通知される。本方法は、生成されたサービスバインディングに従って、アクセスドメイン１１５上でトランスポートされ、特定されたユーザドメインおよびサービスプロバイダのためにアクセスノードまたはアクセスエッジノードで受信されるべきデータトラフィックを集約するために、生成されたサービスバインディングを実施することを含むステップ３６０により継続する。ステップ３３０で新たなサービスバインディングが必要とされないと判定される場合、本方法は、受信されたサービス要請関連メッセージのためのサービスバインディングが既に存在し修正を必要とするかを判定するステップ３７０に進む。判定ステップ３７０の結果によりサービスバインディングが既に存在し修正を必要としない場合、本方法は、ステップ３１０へ復帰し、ステップ３１０で他のサービス要請関連メッセージの受信を待機することにより継続する。しかし、判定ステップ３７０の結果によりサービスバインディングが既に存在し修正を必要としている場合、本方法は、対応する既存のサービスバインディングがステップ３８０で削除される必要があるかを検証するステップ３８０により継続する。サービスバインディンが削除される必要がある場合、本方法は、アクセスエッジノードからサービスバインディングを削除するステップ３９０、サービスバインディングが削除されるべきであることをアクセスノードに通知するステップ３５０、およびサービスバインディングの削除を実施するステップ３６０により継続する。ステップ３８０でサービスバインディングが削除される必要がないと判定される場合、本方法は、受信されたサービス要請関連メッセージ中で指示される修正が実行されるステップ３９５により継続し、本方法は、ステップ３５０へ進むことにより継続する。サービスバインディングの修正例は、ユーザドメインへのデバイスの追加、ユーザドメインからのデバイスの削除、サービス品質要求の修正、さらに説明される多くの他の例を含む。

前述したように、サービスバインディングは、トランスポートの関係性に関連する。トランスポートの関係性は、ユーザドメインの１つとサービスプロバイダの１つとの間で確立され、サービスアクセスノード１２０、およびアクセスエッジノード１６０のサービスエージェント１７０の１つに直接的な影響を及ぼす。概念的にいえば、サービスバインディングの生成は、特定されるユーザドメインをアクセスドメイン上でサービスプロバイダドメインに対応するＶＬＡＮへ追加することに相当する。よって、各サービスバインディングは、ユーザドメインの特定のユーザポートとサービスプロバイダの特定のプロバイダポートとの間で、適切な整合性およびサービス品質を伴って対応するサービスの配信を保証する取引可能な事業体（tradable business entity）を表している。サービスバインディングは、アクセスエッジノード内で生成、管理およびホストされ、サービスエージェント１７０との組合せとして存在する。

サービスエージェントおよびサービスバインディングがアクセスエッジノード内で生成、管理およびホストされるので、本発明の知見に基づくアクセスエッジノードの概略図である図４が図２と同時に参照される。サービスエージェントおよびサービスバインディングの生成、管理、およびホスティングのタスクを実行可能とするために、アクセスエッジノードは、複数のエレメントから構成される。アクセスドメイン１１５内での位置により、アクセスエッジノードは、アクセスドメイン１１５のアクセスネットワーク１３０と通信し、アクセスノード１２０と通信するアクセスドメイン入出力ユニット４１０を含む入出力ユニットを含む。アクセスドメイン入出力ユニット４１０は、サービス要請関連メッセージ４２０を受信する。アクセスエッジノード１６０の入出力ユニットは、地域ネットワーク上でネットワークサービスプロバイダ１４０およびアプリケーションサービスプロバイダ１５０と通信するネットワーク／アプリケーションサービスプロバイダドメイン入出力ユニット４３０を含む。さらに、アクセスエッジノード１６０は、サービスエージェントユニット４４０、制御ユニット４５０を含み、変換（translation）テーブル４６０、転送（forwarding）ユニット４７０、および規制（regulating）ユニット４８０を含んでもよい。

サービスエージェントユニット４４０は、サービスエージェント管理制御ユニット４４２およびサービスバインディングホストユニット４４４からなる。サービスエージェントユニット４４０は、既存のサービスエージェント１７０の情報をサービスエージェント管理制御ユニット４４２内に確保する。サービスエージェント管理制御ユニット４４２は、サービスバインディング４４６の生成および管理に関与する。このために、サービスエージェント管理制御ユニット４４２は、新たなサービスバインディング４４６が要求される時、または削除可能な時を判定し、サービスバインディング４４６の生成／削除を継続する。サービスエージェント管理制御ユニット４４２は、既存のサービスバインディングへのユーザデバイスの追加／削除に関与する。さらに、サービスエージェント管理制御ユニット４４２は、相互作用のために、サービスバインディング４４６関連情報とアクセスノードとの同期性の確保に関与する。サービスエージェント管理制御ユニット４４２は、リザーブパスが要求される場合には、アクセスネットワーク１３０内のリザーブパスのＭＰＬＳの形成にも関与する。図７、８に関連する記載は、各種タスクを実行するためにサービスエージェント管理制御ユニット４４２により用いられる各種メッセージの包括的な説明を提供する。

サービスエージェント管理制御ユニット４４２の内容を例示する表である図５ａが図４と併せて参照される。図５ａの各行（ヘッダ行である第１行を除く）は、サービスエージェント管理制御ユニット４４２により管理および制御されるサービスエージェント１７０の内容を例示している。図５ａの各列は、各サービスエージェント１７０のためにサービスエージェント管理制御ユニット４４２により維持される特定の情報に相当する。第１列は、サービスエージェントの識別を表す。識別は、一般にサービスエージェントに対応する数字またはサービスエージェント識別子である。本発明の一実施形態によれば、アクセスエッジノード内の各サービスエージェントは、固有のサービスエージェント識別子を有し、１つの特定のサービスプロバイダドメイン１４０または１５０に対応する。第２列は、対応するサービスエージェントのための特定のサービス種類の識別を参照している。例えば、１つのサービスプロバイダドメイン１４０または１５０が複数のサービスを提供する場合、提供される各サービスは、サービスプロバイダドメインの各種サービスを区別するために異なるサービス種類に関連付けられる。第３列は、サービスプロバイダドメインおよび関連するサービス種類に応じてデータトラフィックを適切にトランスポートするために要求される望ましいまたは必要とされるサービス品質（ＱｏＳ）を特定する。ＱｏＳの基準例は、遅延、ビット誤り率、帯域幅、望ましいプロトコルを含んでもよい。第４列は、対応するサービスプロバイダドメインと通信するために地域ネットワーク内で用いられるべきポートを特定する。この内容に加えて、サービスエージェント管理制御ユニット４４２は、追加のサービスエージェントを生成し、不必要なサービスエージェントを削除するために十分な論理ソフトウェアおよびハードウェアを含む。図５ａでは、サービスエージェント管理制御ユニット４４２の内容がテーブル形式で表されているが、このような内容に限定されるものではない。サービスエージェント管理制御ユニットは、関連データベース、ハードコードされたコンポーネント、マクロプロセッサ、プログラムライブラリなどから構成されてもよい。

サービスバインディングホストユニット４４４の内容を例示する表である図５ｂが図４と併せて参照される。図５ｂの各行（ヘッダ行である第１行を除く）は、サービスバインディングホストユニット４４６内でホストされるサービスバインディング４４６の内容を例示している。図５ｂの各列は、各サービスバインディング４４６のためにサービスバインディングホストユニット４４４内でホストされる特定の情報に相当する。第１列は、例えばサービスエージェントのサービスエージェント識別子を用いて、対応するサービスエージェントの識別を表す。第２列は、図５ａに関連して説明されたように、サービス種類を特定している。他の列は、サービスバインディングに関連するデータトラフィックのためのトランスポートプリミティブを表す。より具体的には、第３列は、ユーザドメインのメディアアクセスコントロール（ＭＡＣ）アドレスを特定する。第４列は、サービスアクセスノード上でユーザドメインにより用いられるポートの識別を含む。第５列は、ユーザドメインにより用いられるローカルネットワークの任意識別子に対応し、例えば明示的または非明示的なＶＬＡＮ情報を含んでもよい。第６列は、ユーザドメインにサービスするアクセスノードの仮想ＭＡＣアドレスを参照している。ここで、各サービスバインディング４４６は、ユーザドメインの１つとサービスプロバイダドメイン１４０または１５０との間でデータトラフィックを提供するために、サービスエージェントの１つ、ユーザドメインの１つ、およびアクセスノードの１つを結合する。図５ｂでは、サービスバインディングホストユニット４４４の内容がテーブル形式で表されているが、このような内容に限定されるものではない。サービスバインディングホストユニットは、関連データベース、ハードコードされたコンポーネント、マクロプロセッサ、プログラムライブラリなどから構成されてもよい。

さらに、サービスバインディングホストユニットは、ユーザドメインまたはユーザデバイスを特定する固有のＩＰアドレスを含む第７列を含んでもよい。固有のＩＰアドレスは、例えばサービス要請関連メッセージに先立って実行可能なブロードキャストメカニズムを用いて、例えばＤＨＣＰ（Dynamic Host Configuration Protocol）などのプロトコルを通じてアクセスエッジノードによりユーザドメインまたはユーザデバイスに提供可能である。サービスエージェント識別子とユーザドメインもしくはユーザデバイスに固有のＩＰアドレスとの組合せは、よって、入来するメッセージを適切なサービスバインディングに素早く関連付ける単純かつ信頼性の高い方法となる。一般に、サービスバインディングが生成されると、アクセスノードは、その旨を通知され、サービスバインディングによりアクセスドメイン上でデータトラフィックが集約され、アクセスエッジノードで受信される集約されたデータトラフィックは、対応するサービスプロバイダドメインへの転送に先立ってサービスバインディングホストユニット内で提供される情報を用いて分散される。より具体的には、アクセスドメインがイーサネットワークである場合、サービスエージェント識別子は、例えば、ユニキャストのＶＬＡＮタグ、マルチキャストおよびブロードキャストメッセージとして知られるフィールド内で提供され、ユーザドメインまたはユーザデバイスのＩＰアドレスは、イーサネットメッセージ中に埋め込まれるＩＰメッセージ中で提供される。イーサネットメッセージのＶＬＡＮタグフィールド内で提供されるサービスエージェント識別子、および埋め込まれたＩＰメッセージ中で提供されるＩＰアドレスに基づいて、サービスエージェントユニット４４０は、データトラフィックを分散可能であり、対応するサービスプロバイダドメインへの転送、および例えばユーザＭＡＣ情報およびローカルネットワークコンテクストなど、送信ユーザドメインに関する必要な情報の封入（inclusion）を保証する。

図４の説明を再び参照すれば、アクセスエッジノードの制御ユニット４５０は、サービス要請関連メッセージ４２０の受信に際して、サービス要請関連メッセージがサービスエージェントの１つに対応するかを判定することに関与する。このために、制御ユニット４５０は、サービスエージェント管理制御ユニット４４２を参照し、サービスエージェント１７０の１つがサービス要請関連メッセージ４２０中で特定されるサービスプロバイダドメインに対応するかを判定する。サービスエージェント１７０の１つが対応する場合、制御ユニット４５０は、受信されたサービス要請関連メッセージのためにサービスバインディング４４６を生成することをサービスエージェント管理制御ユニット４４２に指示する。受信されたサービス要請関連メッセージ４２０のためのサービスバインディング４４６の生成は、サービスバインディングホストユニット４４４内にエントリを追加することを含み、その中において、
−サービスエージェントＩＤ（第１列）は、要請されたサービスプロバイダドメインに対応するサービスエージェントのためのサービスエージェント識別子に相当し、
−ユーザＭＡＣ情報は、ユーザデバイスのＭＡＣアドレスであり、
−アクセスノード上のユーザポートは、ユーザデバイスが接続するサービスアクセスノード上のポートの識別であり、
−ローカルネットワークコンテクストは、ユーザデバイスから受信されるべきイーサネットメッセージの“ＶＬＡＮタグ”をラベルされたフィールド内で提供され、ローカルユーザドメイン識別子に対応する任意識別子に対応し、
−アクセスノードＭＡＣは、そのためにサービス要請関連メッセージが受信された、ユーザデバイスにサービスするアクセスノードのための仮想ＭＡＣアドレスである。

そして、制御ユニット４５０は、サービスバインディング４４６の生成を、アクセスドメイン入出力ユニット４１０により送信されたサービスバインディング関連メッセージ４９０を通じて、サービス要請関連メッセージ中で特定されるユーザドメインにサービスするアクセスノードに通知する。サービス要請関連メッセージ４２０のためのサービスバインディングが既に存在する場合、制御ユニット４５０は、既存のサービスバインディングをサービスバインディング関連メッセージ４９０を通じてサービスアクセスノードに通知する。

制御ユニット４５０は、また、変換テーブル４６０と相互作用する。サービスエージェント管理制御ユニットの各サービスエージェント１７０は、固有のサービスエージェント識別子により特定されるので、サービスエージェント１７０に対応するサービスエージェント識別子と対応するサービスプロバイダドメイン（１４０または１５０）との間のマッピングを変換テーブル内に確保する必要がある。よって、アクセスエッジノード１６０のための仮想ＭＡＣアドレスに対応する宛先アドレス、およびサービスエージェント識別子の１つに対応するＶＬＡＮタグを有するアクセスドメイン入出力ユニット４１０でデータトラフィックが受信されると、制御ユニット４５０は、変換テーブル４６０を参照し、アクセスエッジノードの仮想ＭＡＣアドレスから、ＶＬＡＮタグ内で提供されるサービスエージェント識別子に対応するサービスプロバイダドメイン（１４０または１５０）の宛先アドレスへの高速な変換を得る。

制御ユニット１５０は、また、転送ユニット１７０を参照し、アクセスドメイン入出力ユニット４１０で受信されるデータトラフィックが修正なしにサービスプロバイダドメイン入出力ユニットへ直接転送されるべきかを判定する。

最後に、制御ユニット４５０は、また、アクセスドメイン入出力ユニット４１０またはネットワーク／アプリケーションサービスプロバイダドメイン入出力ポートユニット４３０で受信されるデータトラフィックに関して、対応するサービスエージェント１７０による指示および／または要求に応じて、ダウンストリーム／アップストリームでのトラフィックの規制およびマーキング、トラフィックリマーキングを実行可能な規制ユニット４８０と相互作用可能である。

本発明の知見に基づくアクセスノードの１つを表す概略図である図６が参照される。アクセスドメイン１１５内での位置により、アクセスノード１２０は、アクセスドメイン１１５のアクセスネットワーク１３０と通信し、アクセスエッジノード１６０と通信するアクセスドメイン入出力ユニット６１０を含む。アクセスノード１２０は、また、ユーザドメイン１１０と通信するユーザドメイン入出力ユニット６２０を含む。アクセスドメイン入出力ユニット６１０で受信されるメッセージの種類は、サービスバインディング関連メッセージ４９０である。サービスバインディング関連メッセージ４９０は、アクセスエッジノードにより生成され、アクセスネットワーク１３０上で送信される。サービスバインディングメッセージ４９０の例は、図７，８の説明として提供される。

アクセスノード１２０は、複数のサービスバインディング関連メッセージ４９０を受信および処理可能である。サービスバインディング関連メッセージ４９０は、アクセスドメイン入出力ユニット６１０を通じて、アクセスネットワーク１３０からアクセスノード１２０で受信される。サービスバインディング関連メッセージ４９０を受信すると、アクセスドメイン入出力ユニットは、受信されたサービスバインディング関連メッセージ４９０を制御ユニット６３０へ転送する。制御ユニット６３０は、サービスバインディング関連メッセージ４９０のコンタクトを抽出し、実行されるべきアクションが存在するかを判定する。サービスバインディング関連メッセージ４９０の例は、新たなサービスバインディングの生成に関する情報である。前述したように、アクセスエッジノード１６０は、新たなサービスバインディングが要求されていると判定すると、それを生成し、要請するユーザドメインにサービスするアクセスノードにサービスバインディングの生成を通知する。この場合に用いられるサービスバインディング関連メッセージ４９０は、ＡＤＤ＿ＳＢ（サービスバインディングの追加）と称される。ＡＤＤ＿ＳＢメッセージは、アクセスエッジノード１６０からアクセスノード１２０へ送信され、生成されたサービスバインディングに関する情報を含む。そして、ＡＤＤ＿ＳＢメッセージ中に含まれる情報は、アクセスノード１２０の集約ユニット６８０に組込まれる。

集約ユニット６８０の各種タスクの１つは、サービスバインディング関連情報のホスティングである。サービスバインディング関連情報は、特定のサービスバインディング情報（サービスエージェント識別子およびサービス種類の形式で）、サービス要請関連メッセージを受信したアクセスノードのポートの識別、ユーザドメインのローカルネットワークコンテクストを含む。

アクセスノード１２０は、また、自らがアクセスネットワーク１３０へのアクセスサービスを提供するユーザドメインから／ユーザドメインへ入来するデータトラフィックを処理する。このために、アクセスノード１２０は、また、変換（translation）テーブル６５０、転送（forwarding）ユニット６６０、規制（regulating）ユニット６７０、および集約ユニット６８０を含む。このために、ユーザドメイン入出力ユニット６２０またはアクセスドメイン入出力ユニット６１０によりアクセスノード１２０で受信されるデータトラフィックは、制御ユニット６３０へ転送される。制御ユニット６３０は、変換テーブル６５０と相互作用する。サービスエージェントユニット４４０のサービスバインディングホストユニット４４４内に格納される各サービスバインディングは、パラメータ（サービスエージェント識別子、サービス種類、ユーザデバイスのＭＡＣアドレス、およびアクセスノードの仮想ＭＡＣアドレス）の組合せにより特定されるので、サービスエージェント１７０に対応するサービスエージェント識別子と、対応するサービスプロバイダドメイン（１４０または１５０）との間のマッピングを変換テーブル内に維持する必要がある。よって、アクセスノード１２０の仮想ＭＡＣアドレスに対応する宛先アドレスを有するアクセスドメイン入出力ユニット６１０でデータトラフィックが受信されると、制御ユニット６３０は、変換テーブル６５０を参照し、ユーザドメインＭＡＣアドレスおよびローカル識別子に各々に対応するように、宛先アドレスおよびＶＬＡＮタグの高速な変換を得る。アクセスエッジノード１６０とアクセスノード１２０との間ではユーザドメイン情報がアクセスドメイン上で引継がれないので、このような変換が要求される。

制御ユニット６３０は、また、転送ユニット６６０を参照し、アクセスドメイン入出力ユニット６１０またはユーザドメイン入出力ユニット６２０で受信されるデータトラフィックが修正なしに、対応するユーザドメイン１１０またはアクセスネットワーク１３０へ直接転送されるべきかを判定する。

最後に、制御ユニット６３０は、また、規制ユニット６７０と相互作用可能である。サービスバインディングのプロパティ内で指示されるように、例えば、ダウンストリーム／アップストリームでのトラフィックの規制およびマーキング、トラフィックリマーキングが必要なときに、規制ユニット６７０との相互作用が要求される。

アクセスノード１２０とアクセスエッジノード１６０との間で交換されるメッセージのフロー図である図７が参照される。これらのメッセージは、両者の間で管理およびトラフィック動作に関する情報を運ぶ。図７に示すメッセージは、シーケンシャルとしてではなく、各アクセスノード１２０とアクセスエッジノード１６０との間での情報交換のために可能なメッセージの例のリストとして理解される。図７上で交換されるメッセージは、前述の説明では“サービスバインディング関連メッセージ４９０”とも称される。図７上に示すメッセージのリストは、アクセスノード１２０とアクセスエッジノード１６０との間で交換されるメッセージの包括的かつ完全なリストとしてではなく、例示的なメッセージとして理解される。

図７に示す第１メッセージは、ＡＬＩＶＥメッセージ７００と称される。これは、アクセスエッジノード１６０からアクセスノード１２０の１つへ送信され、そのアクセスノード１２０が動作していないとアクセスエッジノード１６０により現在考慮されている旨をアクセスノード１２０へ通知する。ＡＬＩＶＥメッセージ７００を受信するアクセスノード１２０のために、ＡＬＩＶＥメッセージ７００は、アクセスエッジノード１６０へのＳＹＮＣメッセージ７０５の送信をトリガーする。ＳＹＮＣメッセージ７０５は、送信アクセスノード１２０内の集約ユニット１６０内に格納されるローカルコンフィギュレーションが喪失または失効された旨を示すために利用可能である。ＳＹＮＣメッセージ７０５は、アクセスエッジノード１６０が送信アクセスノード１２０のコンフィギュレーションを再構築する必要がある旨をアクセスエッジノード１６０に示す。ＳＹＮＣメッセージ７０５には、ローカルコンフィギュレーションを再構築するために受信アクセスノード１２０で必要とされる情報を含むＣＯＮＦＩＧ＿ＡＮメッセージ７１０が一般に続く。ＣＯＮＦＩＧ＿ＡＮメッセージ７１０が適切または不適切に受信されたことを確認するために、ＣＯＮＦＩＧ＿ＡＮメッセージ７１０には、ＣＯＮＦＩＧ＿ＡＮ ＡＣＫ（確認）またはＣＯＮＦＩＧ＿ＡＮ ＮＡＣＫ（未確認）メッセージ７１５が続く。

図７を参照すれば、アクセスノード１２０とアクセスエッジノード１６０との間では、他の種類のメッセージとしてＡＤＤ＿ＳＢメッセージ７２０が交換される。このメッセージは、ローカルコンフィギュレーションへの新たなサービスバインディングの追加、または既存のサービスバインディングの更新を受信アクセスノード１２０に通知することをアクセスエッジノード１６０に可能ならしめる。ＡＤＤ＿ＳＢメッセージ７２０には、ＡＤＤ＿ＳＢ ＡＣＫ（確認）またはＡＤＤ＿ＳＢ ＮＡＣＫ（未確認）メッセージ７２５が続く。

交換される他の種類のメッセージは、ＩＰｖ４用のサービスバインディングに特に関連する。メッセージＡＤＤ＿ＵＤ＿ＩＰｖ４ ７３０は、ＩＰｖ４用の既存のサービスバインディングに対するユーザデバイスの追加または更新を受信アクセスノード１２０に通知する。このメッセージには、ＡＤＤ＿ＵＤ＿ＩＰｖ４ ＡＣＫ（確認）またはＡＤＤ＿ＵＤ＿ＩＰｖ４ ＮＡＣＫ（未確認）メッセージ７３５が続く。ＩＰｖ４サービスバインディングに関連してアクセスエッジノード１６０により生成される他のメッセージは、ＲＥＭ＿ＵＤ＿ＩＰｖ４メッセージ７４０である。ＲＥＭ＿ＵＤ＿ＩＰｖ４メッセージ７４０は、ＩＰｖ４用の既存のサービスバインディングに対するユーザデバイスの削除を受信アクセスノード１２０に通知することをアクセスエッジノード１６０に可能ならしめる。前述したメッセージと同様に、ＲＥＭ＿ＵＤ＿ＩＰｖ４メッセージ７４０には、ＲＥＭ＿ＵＤ＿ＩＰｖ４ ＡＣＫまたはＮＡＣＫメッセージ７４５の形式でアクセスノード１２０からの応答メッセージが続く。

ＩＰｖ４用のサービスバインディングのためのメッセージと同様に、ＩＰｖ６用のサービスバインディングのためのメッセージが提供される。メッセージＡＤＤ＿ＵＤ＿ＩＰｖ６ ７５０は、ＩＰｖ６用の既存のサービスバインディングに対するユーザデバイスの追加または更新を受信アクセスノード１２０に通知する。このメッセージには、ＡＤＤ＿ＵＤ＿ＩＰｖ６ ＡＣＫ（確認）またはＡＤＤ＿ＵＤ＿ＩＰｖ６ ＮＡＣＫ（未確認）メッセージ７５５が続く。ＩＰｖ６サービスバインディングに関連してアクセスエッジノード１６０により生成される他のメッセージは、ＲＥＭ＿ＵＤ＿ＩＰｖ６メッセージ７６０である。ＲＥＭ＿ＵＤ＿ＩＰｖ６メッセージ７６０は、ＩＰｖ６用の既存のサービスバインディングに対するユーザデバイスの削除を受信アクセスノード１２０に通知することをアクセスエッジノード１６０に可能ならしめる。前述したＲＥＭ＿ＵＤ＿ＩＰｖ４メッセージ７４０と同様に、ＲＥＭ＿ＵＤ＿ＩＰｖ６メッセージ７６０には、ＲＥＭ＿ＵＤ＿ＩＰｖ６ ＡＣＫまたはＮＡＣＫメッセージ７６５の形式でアクセスノード１２０からの応答メッセージが続く。

アクセスエッジノード１６０からアクセスノードへ送信される他の種類のメッセージは、メッセージ中で特定されるサービスバインディングをローカルコンフィギュレーションから削除することをアクセスノード１２０に指示するＲＥＭ＿ＳＢメッセージ７７０である。アクセスノード１２０でサービスバインディングの削除が完了すると、完了を確認するため、または特定されるサービスバインディングのローカルコンフィギュレーションからの削除が不適切に完了したことを示すために、ＲＥＭ＿ＳＢ＿ＡＣＫまたはＲＥＭ＿ＳＢ＿ＮＡＣＫメッセージ７７５がアクセスノードからアクセスエッジノード１６０へ送信される。

アクセスエッジノード１６０から前述した各種メッセージが受信されると、受信アクセスノード１２０は、動作中のサービスバインディングと同期するために、ローカルコンフィギュレーションに対して必要とされる更新を実行する。

図７のメッセージのフィールドを示す表である図８が参照される。メッセージのフォーマット８００は、ボックス内に記載されたフィールド、および対応するバイト数を含む。第１フィールドは、バージョンフィールド８０５である。バージョンフィールドは、メッセージ中で用いられるプロトコルのバージョンを示す。対応する応答メッセージは、同一バージョンのプロトコルを用いて送信されることが望ましい。第２フィールドは、メッセージフラグフィールド８１０である。このフィールドの考えられる利用方法の例として、バイトの第０ビットを用いることであり、“１”は、メッセージが要請であることを示し、“０”は、メッセージが応答であることを示す。第３フィールドは、メッセージ長フィールド８１５であり、ここで定義される全てのフィールド（認証フィールド８５０を除く）を含むメッセージの全長を示す。次のフィールドは、タイムスタンプフィールド８２０である。タイムスタンプフィールド８２０は、メッセージが送信された時間を示すために用いられる。それは、秒精度を有する協定世界時（ＵＴＣ）を用いる。サービスエージェント識別子フィールド８２５は、サービスエージェントの識別子を特定する。サービスエージェント内のアプリケーションインスタンス識別子８３０は、サービスバインディング毎のアプリケーションインスタンスを個別に特定する。メッセージ識別子フィールド８３５は、応答メッセージを対応する要請メッセージに関連付けるために要請者（requester）により用いられる。コマンドリスト中で特定されるコマンドの数を示すために用いられるコマンド数フィールド８４０が続く。コマンドリストフィールド８４５は、コマンドのリストを表す。各コマンドは、コマンド種類のための２バイト、コマンドデータ長のための２バイト、コマンドデータのための可変数のビットという形式を有することが望ましい。以下の表は、考えられるコマンド種類、コマンドデータ長、およびコマンドデータに関する追加的情報を提供する。最後に、認証フィールド８５０は、メッセージを認証するために用いられる。

上記表の理解を助けるために、略号および略号の定義が以下に提供される。
ＡＥＮ：アクセスエッジノード
ＡＣＫ：確認
ＡＤＤ＿ＡＵＴＨ＿ＭＡＣ：許可ＭＡＣの追加／更新
ＡＤＤ＿ＡＵＴＨ＿ＳＢ：認証されたサービスバインディングの追加／更新
ＡＤＤ＿ＰＲＯＦＩＬＥ：レート制限プロファイルの追加／更新
ＡＤＤ＿ＳＢ：サービスバインディングの追加／更新
ＡＤＤ＿ＵＤ＿ＩＰｖ４：ＩＰｖ４用の既存のサービスバインディングへのユーザデバイスの追加／更新
ＡＤＤ＿ＵＤ＿ＩＰｖ６：ＩＰｖ６用の既存のサービスバインディングへのユーザデバイスの追加／更新
ＡＮ：アクセスノード
ＢＣ：ブロードキャスト
ＣＢＳ：コミットされたバーストサイズ
ＣＩＲ：コミットされた情報レート
ＣＯＮＦＩＧ＿ＡＮ：コンフィギュアされたアクセスノード
ＥＢＳ：超過バーストサイズ
ＪＯＩＮ＿ＡＵＴＨ＿ＩＰｖ４：認証されたユーザデバイスのためのＩＰｖ４マルチキャストグループへの加入／再加入（join/rejoin）
ＪＯＩＮ＿ＡＵＴＨ＿ＩＰｖ６：認証されたユーザデバイスのためのＩＰｖ６マルチキャストグループへの加入／再加入
ＪＯＩＮ＿ＩＰｖ４：ＩＰｖ４マルチキャストグループへの加入／再加入
ＪＯＩＮ＿ＩＰｖ６：ＩＰｖ６マルチキャストグループへの加入／再加入
ＬＥＡＶＥ＿ＡＵＴＨ＿ＩＰｖ４：認証されたユーザデバイスのためのＩＰｖ４マルチキャストグループからの脱退（leave）
ＬＥＡＶＥ＿ＡＵＴＨ＿ＩＰｖ６： 認証されたユーザデバイスのためのＩＰｖ６マルチキャストグループからの脱退
ＬＥＡＶＥ＿ＩＰｖ４：ＩＰｖ４マルチキャストグループからの脱退
ＬＥＡＶＥ＿ＩＰｖ６：ＩＰｖ６マルチキャストグループからの脱退
ＭＡＣ ＡＤＤＲＥＳＳ：メディアアクセスコントロールアドレス
ＭＣ：マルチキャスト
ＰＢＳ：ピークバーストサイズ
ＰＩＲ：ピーク情報レート
ＲＥＭ＿ＡＵＴＨ＿ＳＢ：認証されたサービスバインディングの削除
ＲＥＭ＿ＰＲＯＦＩＬＥ：レート制限プロファイルの削除
ＲＥＭ＿ＳＢ：サービスバインディングの削除
ＲＥＭ＿ＵＤ＿ＩＰｖ４：ＩＰｖ４用の既存のサービスバインディングからのユーザデバイスの削除
ＲＥＭ＿ＵＤ＿ＩＰｖ６：ＩＰｖ６用の既存のサービスバインディングからのユーザデバイスの削除
ＳＮＤ＿ＡＮＤ：アクセスネットワークドメインに関するフレームの送信
ＳＮＤ＿ＥＴＨ＿Ｄ：ダウンストリームへのフレームの送信
ＳＮＤ＿ＥＴＨ＿Ｕ：アップストリームへのフレームの送信
ＳＮＤ＿ＵＮＤ：ユーザポートに関するフレームのユーザドメインへの送信

本発明の方法およびノードの様々な好ましい実施形態が添付図面に示され、前述した詳細な説明で説明された。しかし、本発明は、開示された実施形態に限定されるものではなく、前述され、特許請求の範囲により定義された本発明の本質から逸脱しない範囲で、多くの再構成、変更、および代替が可能であることが理解される。

ＩＰネットワークの従来技術を例示する説明図である。 本発明が組込まれるネットワークを例示する概略図である。 本発明に基づくサービスバインディングを管理する方法を示す簡略化されたフロー図である。 本発明の知見に基づくアクセスエッジノードの概略図である。 本発明に基づくサービスエージェント管理制御ユニットの内容を例示する表である。 本発明の知見に基づくサービスバインディングホストユニットの内容を例示する表である。 本発明に基づくアクセスノードの概略図である。 本発明の知見に基づくアクセスノードとアクセスエッジノードとの間で交換されるメッセージを例示するフロー図である。 本発明の知見に基づくアクセスノードとアクセスエッジノードとの間で交換されるメッセージの各種フィールドを示す表である。

Claims (14)

1. アクセスドメイン上でサービスバインディングを管理する方法であって、
   ユーザドメインの第１デバイスおよびサービスプロバイダドメインを特定するサービス要請関連メッセージを、前記ユーザドメインの前記第１デバイスのためにアクセスエッジノードで受信すると、
   前記アクセスドメイン上で前記ユーザドメインの前記第１デバイスと前記サービスプロバイダドメインとの間のデータトラフィックを管理する、前記ユーザドメインにサービスするアクセスノードおよび前記アクセスエッジノードをコミットすることにより、前記データトラフィックを規定するサービスバインディングを前記アクセスエッジノードで生成するステップと、
   受信された前記サービス要請関連メッセージに関連する前記ユーザドメインにサービスする前記アクセスノードに、生成された前記サービスバインディングを通知するステップと、
   前記アクセスドメイン上で前記データトラフィックのために、生成された前記サービスバインディングを前記アクセスノードおよび前記アクセスエッジノードで実行するステップと、
   を含む、サービスバインディングを管理する方法。
2. 前記サービスバインディングは、前記サービスプロバイダドメインのために前記アクセスエッジノードにより制御される前記アクセスドメイン上のバーチャルローカルエリアネットワーク内における前記ユーザドメインの前記第１デバイスを含むことを特徴とする、請求項１に記載の方法。
3. 前記サービスプロバイダドメインのために前記ユーザドメインの第２デバイスのための前記アクセスエッジノードで他のサービス要請関連メッセージを受信するステップと、
   生成された前記サービスバインディングに前記ユーザドメインの前記第２デバイスを追加することにより、生成された前記サービスバインディングを修正するステップと、
   修正された前記サービスバインディングを、前記ユーザドメインにサービスする前記アクセスノードに通知するステップと、
   前記ユーザドメインの前記第１および第２デバイスと前記サービスプロバイダドメインとの間のデータトラフィックのために、修正された前記サービスバインディングを前記アクセスノードおよび前記アクセスエッジノードで実行するステップと、
   をさらに含むことを特徴とする、請求項１に記載の方法。
4. 前記ユーザドメインの前記第１デバイスのために、前記アクセスエッジノードで終了サービス要請を前記サービスプロバイダドメインから受信するステップと、
   前記第１ユーザデバイスを前記サービスバインディングから削除するステップと、
   前記サービスバインディングからの前記第１ユーザデバイスの削除を前記アクセスノードに通知し、前記通知に応じて前記アクセスノードで前記サービスバインディングを修正するステップと、
   新たに修正された前記サービスバインディングを前記アクセスノードで実行するステップと、
   をさらに含むことを特徴とする、請求項３に記載の方法。
5. 前記ユーザドメインの前記第１デバイスのために、前記アクセスエッジノードで終了サービス要請を前記サービスプロバイダドメインから受信するステップと、
   前記サービスバインディングを前記アクセスエッジノードから削除するステップと、
   削除された前記サービスバインディングを前記アクセスノードに通知するステップと、
   をさらに含むことを特徴とする、請求項３に記載の方法。
6. 前記アクセスエッジノードおよび前記アクセスノードは、複数のユーザドメインおよび複数のサービスプロバイダドメインのために複数のサービスバインディングを同時に処理することを特徴とする、請求項１に記載の方法。
7. ユーザドメインとサービスプロバイダドメインとの間のアクセスドメイン内に位置し、前記アクセスドメイン上でサービスバインディングを管理するアクセスエッジノードであって、
   サービスプロバイダドメインのために、ユーザドメインの第１デバイスのためのサービス要請関連メッセージを受信する入出力ユニットと、
   前記アクセスドメイン上で前記ユーザドメインの前記第１デバイスと前記サービスプロバイダドメインとの間のデータトラフィックを規定し、かつ、前記データトラフィックを処理する、前記ユーザドメインにサービスするアクセスノードおよび前記サービスプロバイダドメインを示す前記アクセスエッジノードをコミットする、サービスバインディングを生成するサービスエージェントユニットと、
   受信された前記サービス要請関連メッセージに関連する前記ユーザドメインにサービスする前記アクセスノードに前記サービスバインディングの生成を前記入出力ユニットを通じて通知し、かつ、前記アクセスドメイン上で前記データトラフィックのために、生成された前記サービスバインディングを前記アクセスエッジノードで実行する制御ユニットと、
   を備える、アクセスエッジノード。
8. 生成された前記サービスバインディングは、前記サービスプロバイダドメインのために前記アクセスエッジノードにより制御される前記アクセスドメイン上のバーチャルローカルエリアネットワーク内における前記ユーザドメインの前記第１デバイスを含むことを特徴とする、請求項７に記載のアクセスエッジノード。
9. 前記入出力ユニットは、さらに、第１ユーザデバイスから前記サービスプロバイダへデータトラフィックを転送し、かつ、前記第１ユーザデバイスのために前記データトラフィックを前記サービスプロバイダから受信することを特徴とする、請求項７に記載のアクセスエッジノード。
10. 前記サービスエージェントユニットは、サービスエージェント管理制御ユニットおよびサービスバインディングホストユニットを有し、
    前記サービスエージェント管理制御ユニットは、前記サービスプロバイダドメインのために前記アクセスドメイン上で前記バーチャルローカルエリアネットワークを制御し、前記サービスバインディングを生成、変更、または削除し、
    前記サービスバインディングホストユニットは、前記サービスバインディングをホストし、
    前記制御ユニットは、さらに、前記サービスエージェント管理制御ユニットが前記サービスバインディングを変更または削除する時を、前記ユーザドメインにサービスする前記アクセスノードに通知することを特徴とする、請求項８に記載のアクセスエッジノード。
11. 前記サービスエージェント管理制御ユニットは、前記サービスプロバイダドメインの１つに各々に対応する複数のバーチャルローカルエリアネットワークを前記アクセスドメイン上で同時に制御し、
    前記サービスバインディングホストユニットは、複数のユーザドメインおよび複数のサービスプロバイダドメインのために複数のサービスバインディングを同時にホストすることを特徴とする、請求項１０に記載のアクセスエッジノード。
12. ユーザドメインとアクセスドメインとの間に位置し、前記アクセスドメイン上でサービスバインディングを管理するアクセスノードであって、
    前記アクセスドメイン上でデータトラフィックを前記ユーザドメインから転送し、サービスバインディング関連メッセージを受信する入出力ユニットと、
    サービスバインディングを格納し、格納された前記サービスバインディングを実行する集約ユニットと、
    データトラフィックを制御し、サービスバインディングを管理し、前記入出力ユニットで受信された前記サービスバインディング関連メッセージを評価し、前記評価に応じて格納された前記サービスバインディングを更新し、格納された前記サービスバインディングに応じて前記アクセスドメイン上で前記ユーザドメインからの前記データトラフィックを制御する制御ユニットと、
    を備える、アクセスノード。
13. 前記集約ユニットは、複数のユーザドメインおよび複数のサービスプロバイダドメインのために複数のサービスバインディングを同時にホストすることを特徴とする、請求項１２に記載のアクセスノード。
14. 前記サービスバインディングの各々は、前記アクセスドメイン上でバーチャルローカルエリアネットワークを参照することを特徴とする、請求項１３に記載のアクセスノード。

Images