JP4698684B2 - アクセスドメイン上でデータトラフィックを集合する方法と、本方法に関するノード - Google Patents

Description

３５ Ｕ．Ｓ．Ｃ．Ｓ．１１９（ｅ）および３７ Ｃ．Ｆ．Ｒ．Ｓ．１．７８に基づく優先権ステートメント。
この特許出願は、シルヴェイン・モネッテ（Ｓｙｌｖａｉｎ Ｍｏｎｅｔｔｅ）、マチュー・ジゲーレ（Ｍａｔｈｉｅｕ Ｇｉｇｕｅｒｅ）、マーチン・ジュリアン（Ｍａｒｔｈｉｎ Ｊｕｌｉｅｎ）、ベノア・トレムブレイ（Ｂｅｎｏｉｔ Ｔｒｅｍｂｌａｙ）の名の下に２００５年２月１４日の出願された出願番号６０／６５１，９７１号「ポリプロジェクト（Ｐｏｌｙ ｐｒｏｊｅｃｔ）」、およびシルヴェイン・モネッテ（Ｓｙｌｖａｉｎ Ｍｏｎｅｔｔｅ）、マチュー・ジゲーレ（Ｍａｔｈｉｅｕ Ｇｉｇｕｅｒｅ）、マーチン・ジュリアン（Ｍａｒｔｈｉｎ Ｊｕｌｉｅｎ）、ベノア・トレムブレイ（Ｂｅｎｏｉｔ Ｔｒｅｍｂｌａｙ）の名の下に２００５年４月２５日出願の出願番号６０／６７４，３０７号「アクセスノードエッジノード複合プロトコル（ＡＥＰ：Ａｃｃｅｓｓ ｎｏｄｅ−ｅｄｇｅ ｎｏｄｅ ｃｏｍｐｌｅｘ ｐｒｏｔｏｃｏｌ）」の先の米国仮特許出願に基づく優先権を主張するものである。

本発明はアクセスドメイン上でデータトラフィックを集合する方法と、本方法に従ってデータトラフィックを集合するアクセスノードとアクセスエッジノードとに関する。

近年、インターネットプロトコル（ＩＰ）ネットワークの爆発的な増加が見られる。当初は、大学や研究者が通信を行い、研究プロジェクトで協力することを可能とするための開発であったが、巨大市場レベルで提供されるネットワークへと成長した。今日では、一般世帯がワールドワイドウェブを使用したり、対話式ゲームを行ったり、ＩＰに乗せて音声を運んだり、文書やソフトウェアをダウンロードしたり、電子商取引を行ったりするためにＩＰネットワークに接続することは普通になっている。

以下、図１に関して述べる。図１は、ＩＰネットワーク１００の従来の技術例を示す説明図である。典型的に、ＩＰネットワークは、アクセスドメイン１１５と、ネットワークサービスプロバイダドメイン１４０と、アプリケーションサービスプロバイダドメイン１５０から構成されている。アクセスドメイン１１５はアクセスノード（ＡＮ）１２０とＩＰネットワークのようなアクセスネットワーク１３０を含んでいる。アクセスノード１２０は、ユーザドメイン１１０にＩＰネットワーク１３０への接続を提供するアクセスプロバイダである。ユーザドメイン１１０は、例えばユーザデバイス（ＵＤ）（コンピュータ、携帯電話、携帯情報端末（ＰＤＡ：Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）など）や、ローカルエリアネットワーク（ＬＡＮ）や、無線ＬＡＮ（Ｗ−ＬＡＮ）を含んでいる。ユーザドメインはアクセスノードと様々な可能な技術で通信を行う。これらの技術には、電話線上でのダイヤルアップ接続やＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）接続や、テレビケーブルネットワーク上でのケーブルモデム接続や、無線通信がある。アクセスネットワーク１３０は一群の独立したスイッチとルータから構成されている。スイッチとルータの役割は、入ってくるデータトラフィックを、データトラフィックの中に埋め込まれた目的アドレスに基づいて、スイッチング／ルーティングすることである。ネットワークサービスプロバイダドメイン１４０は、例えばＩＰ上の音声伝達サービスに適するものであり、一方、アプリケーションサービスプロバイダドメイン１５０は電子銀行取引や電子商取引に適している。

図1は、３つのユーザドメインと２つのアクセスノードと２つのサービスプロバイダドメインと２つのアプリケーションサービスドメインを描いてあるが、典型的には、ＩＰネットワーク１００は、数千のユーザドメインと、数十のアクセスノードと、数百のネットワークサービスプロバイダドメイン及びアプリケーションサービスプロバイダドメインを含んでいる。アクセスネットワーク１３０に関しては、数百のスイッチおよび／またはルータを含むネットワークに遭遇することは、普通のことである。この様に、図１には明瞭にするために極めて簡略化されたＩＰネットワーク１００が描かれている。

この様なＩＰネットワーク上での、一元化されたデータトラフィックとメッセージとの交換を確実に行うために、ＩＰプロトコルは１９７０年代の初期に開発された。ＩＰヴァージョン４（ＩＰｖ４）は現在の発達したＩＰネットワークの大部分で使用されている。ＩＰｖ４は３２ビットを使用するアドレス割り当て方式で、４,２９４,９６７,２９６の可能アドレスを割り当てることができる。割り当てられたそれぞれのアドレスはユニークなものであり、直接1つのデバイスを識別するものである。図１で示される様なＩＰネットワーク１００の場合では、ネットワークは、イーサネットベースのデータリンクに基づいていることが一般的に知られている。イーサネットベースのデータリンクは、ＩＰネットワーク１００中のデータトラフィックとメッセージとに速くて簡潔な交換を提供する。

しかしながら、ＩＰネットワーク上で通信を行うデバイスの数の増加とＩＰｖ４の本来持っている限界のため、ＩＰコミュニティーはＩＰの新しい修正：ＩＰヴァージョン６（ＩＰｖ６）を必要としている。この新しいヴァージョンは１２８ビットを使用するアドレス割り当て方式に基づいており、より多くの可能アドレスを提供することができる。

ＩＰｖ６がより多くのＩＰアドレス数を可能とし、ＩＰｖ４で見られた不足分のアドレス割り当てが可能となるにもかかわらず、ＩＰｖ４とＩＰｖ６の両方が“ベストエフォート”のプロトコルである。“ベストエフォート”とは、ネットワークがデータトラフィックを運ぶ際に、確立を高めるための特別な努力も、それらのタイプのデータトラフィックで要求されるサービス品質の特別な要求もしないということである。この方式は、いくつかのネットワークサービスプロバイダ１４０とアプリケーションサービスプロバイダ１５０にとっては十分であるが、残念ながら、その他に対しては十分に機能を提供しない。この様に、いくつかのネットワークサービスプロバイダ１４０とアプリケーションサービスプロバイダ１５０では、ＩＰネットワーク１００上でそれほど簡単でスムーズにサービスを提供することができない。

この問題を解決するために、ＩＰネットワーク上ではマルチプロトコルラベルスイッチング（ＭＰＬＳ：ＭｕｌｔｉＰｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）が使用されている。ＭＰＬＳは、リザベーションプロトコル（ＲＳＶＰ：ＲｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のようなプロトコルに基づいており、ＲＳＶＰはＩＰネットワーク１００上で一定のサービス品質を保ち、経路を確保する。ＲＳＶＰは、最初に一連のルータを通して経路を確保する。経路を確保するために、それぞれのルータはそのルータのＭＰＬＳテーブルにエントリを追加する。そのエントリは、特定の入力ポートに到着し、あらかじめ決められたラベル、対応する出力ポート、および使用されるラベルを持つデータトラフィックのことを指し示している。確保された経路をＩＰネットワーク１００内に作ることによって、ネットワークサービスプロバイダ１４０とアプリケーションサービスプロバイダー１５０の大きな連続した範囲でデータトラフィックを運ぶことが可能となる。

しかし、“ベストエフォート”より高いサービス品質が求められるネットワークサービスプロバイダ１４０とアプリケーションサービスプロバイダ１５０の数の増加と共に、また、ユーザドメイン１１０と、これらのユーザドメイン１１０がアクセスネットワーク１３０を使用する可能性を高める必要があるアクセスノード１２０の数の拡大と共に、ＭＰＬＳはよい選択肢ではないことが分かってきた。

初期のＩＰネットワークの原理は、到着したデータトラフィックを最終目的地に向けてルーティングする前にできる限り少ない操作で処理を行うルータに基づいている。“ベストエフォート”のネットワークは、サービス品質とデータトラフィックの量とのトレードオフであることも、広く認知されている概念である。サービスの品質が高くなるにつれ、同じ数のルータによって運ばれたデータトラフィックは少なくなる。ＩＰネットワークは高レベルのサービス品質を考えて設計されてこなかった。この様に、ＩＰネットワーク上でデータトラフィックの高いサービス品質のために、確保された経路を作ることによって、直接的な結果としてはＩＰネットワーク上のデータトラフィック量は減る。さらに、前述のようなＭＰＬＳに必要な確保された経路は、確保された経路上のそれぞれのルータにおいてルーティングのためにさらに多くの努力を消費する結果となる。前述のルーティングの努力は、少しの確保された経路が同時に開かれる時にはそれほど重大ではないが、サービスが進歩した現在では、アプリケーションは“ベストエフォート”のサービス品質以上を求める。ＩＰネットワーク上で何千もの確保された経路が同時に要求されることは容易に想像できる。非常に多くの確保された経路を持ちながら、データトラフィックを保持し、ルーティングすることはさらにルータに負荷をかけ、影響を受けたルータのルーティング能力を低下させる。ゆえに、ＩＰネットワーク上でサービス品質の改良のためにＭＰＬＳを現在使用することは、データトラフィックの交換を減少させデータトラフィックを遅くする結果となる。その様な影響は、確保された経路の一部でなく全体のデータトラフィックに直接影響するため、許容しがたいものである。

現在は、ユーザデバイス数の拡大とＩＰネットワーク上でサービスを提供するサービスプロバイダ数の拡大に結びつく問題の解決方法は知られていない。さらに、特定のサービスとアプリケーションのために増加したＱｏＳの必要性に対する、実体がある建設的な解決方法を可能とするために、長期にわたる解決方法はまだ確認されていない。

それゆえ、現存する解決方法では不足する点や欠点を克服するために、アクセスドメイン上で何千ものネットワークサービスプロバイダドメインとアプリケーションサービスプロバイダドメインがユーザドメインと通信することを効率的に可能とするノードと手法を持つことの有利性を、直ちに評価すべきである。様々なサービス品質のレベルを提供する一方、一元化されたアクセスネットワークの使用を考慮したノードと手法を持つこともまた有利である。本発明は、前述に記載の方法とノードを提供する。

本発明は、データトラフィックを集合することによって、アクセスドメイン上で、数千のネットワークサービスプロバイダドメインおよびアプリケーションサービスプロバイダドメインが、ユーザドメインと通信を行うことを効率的に可能とする。本発明のデータトラフィックを集合する方法とノードは、アクセスドメインの一元化された使用と様々なレベルのサービス品質を提供するサービスバインディングの概念に関する。

そうするために、本発明のある観点によれば、アクセスドメイン上のデータトラフィックを集合するアクセスエッジノードにおいて具体化される。ここで、アクセスドメインは、ユーザドメインとサービスプロバイダドメインとの間のデータトラフィックを運ぶ。本発明のアクセスエッジノードは、サービスエージェントユニットとサービスバインディングユニットと入出力ユニットと制御ユニットとを含む。サービスエージェントユニットはサービスエージェントをホストする。各々のサービスエージェントは、１つのサービスプロバイダドメインに対応し、サービスプロバイダドメインに対してアクセスドメイン上で仮想ローカルエリアネットワークを保持する。サービスバインディングユニットは存在するサービスバインディング情報をホストする。各々のサービスバインディングは、１つのサービスエージェントの属性、ユーザドメイン情報、およびアクセスドメイン転送プリミティブを含んでいる。入出力ユニットは、サービスプロバイダドメインおよびアクセスノードと通信を行う。アクセスノードは、ユーザドメインにアクセスドメインへの接続を提供する。入出力ユニットは、１つのサービスプロバイダドメインおよび１つのユーザドメインを識別するサービス要求関連メッセージを受信する。制御ユニットは、入出力ユニットでのサービス要求関連メッセージを受信した時に、１つのサービスエージェントがサービス要求関連メッセージの中で識別されたサービスプロバイダドメインに対応するかどうかを決定する。もし、１つのサービスエージェントが、サービス要求関連メッセージの中で識別されたサービスプロバイダドメインに対応すれば、制御ユニットは、サービスバインディングユニットの中で対応するサービスバインディングを作成し、作成されたサービスバインディングに従って、サービス要求メッセージ内で識別されたユーザドメインに接続を提供するアクセスノードに、識別されたユーザドメインが、識別されたサービスプロバイダドメインにデータトラフィックを送信するための情報を伝達する。

本発明のある観点によれば、サービスバインディングユニットの中でサービスバインディングを作成することは、要求されたサービスプロバイダと対応するＶＬＡＮにユーザドメインを追加することを含む。その際、サービスバインディングユニットの中にエントリを追加することによって、要求されたサービスプロバイダと対応するＶＬＡＮにユーザドメインを追加する。そのエントリは、要求されたサービスプロバイダに対応するサービスエージェントの属性とユーザドメイン情報とアクセスドメイン転送プリミティブとを持っている。

本発明の別の観点によれば、複数のサービスプロバイダとユーザドメインの間でデータトラフィックを運ぶアクセスドメイン上で、データトラフィックを集合する方法に関する。本方法は、アクセスエッジノードの中で複数のサービスエージェントを構築するステップを含む。各々のサービスエージェントは、１つのサービスプロバイダドメイン用のアクセスドメイン上の仮想ローカルエリアネットワークと対応する。アクセスエッジノードにおいてサービス要求関連メッセージを受信すると、サービス要求関連メッセージは、１つのサービスプロバイダドメインおよび１つのユーザドメインを識別し、構築されたサービスエージェントの1つが、要求されたサービスプロバイダドメインと対応するかどうかを決定するステップが実施され、もし、構築されたサービスエージェントの1つが要求されたサービスプロバイダドメインと対応するならば、受信したサービス要求関連メッセージ用のサービスバインディングをアクセスエッジノードで作成する。サービスバインディングは、対応するサービスエージェントの属性、ユーザドメインに関する情報、およびアクセスドメイン転送プリミティブを含む。本方法は、さらに続けてアクセスノードに情報を伝達する。このアクセスノードは、識別されたユーザドメインおよびサービスバインディングが作成されたアクセスドメインに接続を提供する責任がある。続けて、本方法は、作成されたサービスバインディングに従って、識別されたユーザドメインから受信した、識別されたサービスプロバイダ用のデータトラフィックを集合する。

本発明の別の観点によれば、アクセスドメイン上のデータトラフィックを集合するアクセスノードに関する。ここで、アクセスドメインは、ユーザドメインとサービスプロバイダドメイン間でデータトラフィックを運ぶ。アクセスノードは、入出力ユニット、集合ユニット、および制御ユニットを含んでいる。入出力ユニットはユーザドメインからデータトラフィックを受信し、アクセスドメイン上で、ユーザドメインから受信したデータトラフィックを転送する。集合ユニットは、アクセスドメイン上に存在するサービスバインディングの情報を格納する。ここで、アクセスドメイン上に存在するサービスバインディングの情報とは、サービスバインディングの識別や、対応するサービスプロバイダの属性を持ったユーザドメインの属性のようなものである。制御ユニットは、１つのユーザドメインからの情報を受信すると、受信したデータトラフィックが存在するサービスバインディングの1つに対応するかどうかを決定する。その決定処理は、集合ユニットの中で、ユーザドメインとサービスプロバイダドメインの属性を比較することによって行われる。もし、ユーザドメインおよびサービスプロバイダドメインの属性が存在するサービスバインディングに対応すれば、制御ユニットは、識別されたサービスバインディングに従って、アクセスドメイン上で受信されたデータトラフィックを集合するという情報を入出力ユニットに伝達する。

本発明の目的と利点のさらに詳細な理解のため、以下に記載の添付図面と併せて説明をする。
本発明の革新的な開示は、様々な実施形態の例について個々に言及することによって記載される。しかし、この種の実施形態は、本発明の革新的な開示の数多くの利点ある使用方法のほんの少しの例しか提供していないことを理解すべきである。概して、本出願の明細書中で記述されていることは、本発明の要求された様々な項目のどれをも必ずしも限定しない。さらに、いくつかの記述はいくつかの発明の特徴に当てはまるが、他の発明の特徴には当てはまらない。図中で、同じ、あるいはよく似た要素は、いくつかの図表を通して同じ符号で示されている。

本発明は、データトラフィックを効率的に集合する方法とノードを提供する。このデータトラフィックは、サービスプロバイダドメインと通信している複数のユーザドメインから送信される、またはユーザドメインへ送信されるデータトラフィックである。そのために、アクセスエッジノードは、ユーザドメインとサービスプロバイダドメインの間にあるアクセスドメイン内に導入されるのである。
アクセスエッジノードは、サービスエージェントユニットを含む。ここで、サービスエージェントユニットは、サービスエージェントを管理し、制御する。それぞれのサービスエージェントは、一方では、１つのサービスプロバイダドメインと対応し、他方では、サービスプロバイダドメインのためのアクセスドメイン上の仮想ローカルエリアネットワーク（ＶＬＡＮ：Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を管理し、制御する。ユーザドメインが、選択された１つのサービスプロバイダドメインとの通信を希望するたびに、サービス要求関連メッセージがアクセスエッジノードに送信される。サービス要求関連メッセージは、1つのサービスプロバイダドメインおよび1つのユーザドメインを識別する情報を含んでいる。アクセスエッジノードは、１つのサービスエージェントが、サービス要求関連メッセージの中で識別されたサービスプロバイダドメインに対応するかどうかを決定する。もし、１つのサービスエージェントが、サービス要求関連メッセージの中で識別されたサービスプロバイダドメインに対応すれば、受信したサービス要求関連メッセージのためにサービスバインディングを作成する。サービスバインディングは、１つのサービスエージェント、ユーザドメイン情報、およびアクセスドメイン転送プリミティブを識別する。その後、要求を出しているユーザドメインに接続を提供するアクセスノードは、サービスバインディングが作成されたという情報を受け取る。そして、サービス要求関連メッセージに関するデータトラフィックの集合処理が、作成されたサービスバインディングに従ってアクセスドメイン上で実行される。以下の段落では、アクセスドメイン上でデータトラフィックを集合するために、サービスエージェント、サービスバインディング、アクセスエッジノード、およびアクセスノードが、どのように組み立てられるかがより詳細に説明されている。
“データトラフィック”という表現は、本明細書を通して使用され、データネットワーク上で転送されるメッセージと情報に関する。

本発明と、本発明のメカニズムを理解するためには、図２に関して述べる。図２は、本発明が組み込まれたネットワーク２００を例示した概略図である。
ネットワーク２００の概略図は、明確化の目的で簡略化されている。描写されている様々な要素は、よく似た機能ごとにグループ化されており、ネットワークエンティティを位置的に図で表現しているのではない。しかし、よく似た機能を持つそれぞれのグループは、典型的に、ネットワーク２００に位置的にばらまかれた、特定の機能を持つ物理的なネットワークエンティティに対応する。ネットワーク２００の概略図は、ユーザドメイン１１０とアクセスドメイン１１５とネットワークサービスプロバイダ１４０とアプリケーションサーバ１５０を含んでいる。アクセスドメイン１１５は、アクセスノード１２０とアクセスネットワーク１３０とアクセスエッジノード１６０と地域ネットワーク１３５とを含んでいる。包括的な説明とそれぞれの要素の例は、以下の段落で図２を参照して提供される。

ネットワーク２００は、互いに通信を行う、１または複数のデータネットワークに対応している。このように、ネットワーク２００は、１または複数の操作者によって操作されることが可能である。データネットワークは、通常、多数の操作可能なエンティティ、および／または多数の操作可能な組織によってサポートされているため、どのようにしてこれらのエンティティおよび組織が通信を成功させるかを明確にすることは必須である。この理由のため、データネットワークは、通常、オープンシステムインターコネクションモデル（ＯＳＩモデル：Ｏｐｅｎ Ｓｙｓｔｅｍ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ ｍｏｄｅｌ）を用いて詳しく説明される。ＯＳＩモデルは、７つのレイヤー内でプロトコルを実行するためのネットワークのフレームワークを明確にする。これらの７つのレイヤーは、それぞれ次に示す順になっている。１）物理層；２）データリンク層；３）ネットワーク層；４）トランスポート層；５）セッション層；６）プレゼンテーション層；７）アプリケーション層。それぞれのレイヤーは、データネットワーク上でデータの転送を行うときに、考えられる側面および請け負う動作に対応している。本発明のネットワーク２００を表現するためにＯＳＩモデルを使用すると、本発明のネットワークによって使用されている、および／またはサポートされている様々なプロトコルのいくつかは、以下のように層に分離することができる。
レイヤー２：イーサネット（Ｅｔｈｅｒｎｅｔ）（登録商標）、非同期転送モード（ＡＴＭ：Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）
レイヤー３：インターネットプロトコル（ＩＰ）ヴァージョン４、インターネットプロトコル（ＩＰ）ヴァージョン６
レイヤー４と５：トランスミッションコントロールプロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ユーザデータグラムプロトコル（ＵＤＰ：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）
レイヤー６と７：現在存在しているか、または今後使用される、様々なプレゼンテーションプロトコルとアプリケーションプロトコル
前記のプロトコルのリストは、例としての目的のために提供されているのであり、本発明によってサポートされるプロトコルを限定するものではない。

次に、アクセスドメイン１１５について述べる。アクセスドメイン１１５は、その機能を、ユーザドメイン１１０、ネットワークサービスプロバイダ１４０、およびアプリケーションサービスプロバイダ１５０の間のエンド・トゥ・エンドの接続を提供する手段としてまとめることができる。アクセスドメインは、アクセスノード１２０、アクセスネットワーク１３０、地域ネットワーク１３５、およびアクセスエッジノード１６０を含む。このように、アクセスドメイン１１５は、それ自体はエンティティではなく、むしろ、構成要素の集合である。この構成要素の集合は、直接的であっても間接的であっても、互いに連結されると、接続を提供するためのドメインとして振舞う。それゆえ、この名前を“アクセスドメイン”と言うのである。このように、１つのアクセスノード１２０と1つのアクセスネットワーク１３０と1つのアクセスエッジノード１６０と1つの地域ネットワーク１３５のみを含む現在のアクセスドメイン１１５の表現は、そのようなエンティティがアクセスドメイン内でシングルであるという意味ではなく、明確化の目的で、ただ1つのそれらのエンティティが表現されていることは明確である。以下の段落で、アクセスドメインの様々な構成要素のさらに詳細な説明がなされる。

アクセスノード１２０は、（図示されていないが）アクセスゲートウェイを含み、アクセスドメイン１１５の第一の構成要素を表現している。典型的に、アクセスノード１２０は、ユーザドメイン１１０のアクセスネットワーク１３０への接続を可能とするアクセスプロバイダに、例えば、固定制であるか従量制であるかについて問い合わせる。そのような接続は、さまざまなメディアとテクノロジーを使用することで可能となる。使用可能なメディアとしては、ケーブル、固定電話、携帯電話がある。使用可能なテクノロジーについては、統合デジタル通信網（ＩＳＤＮ：Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）や、非対称デジタル加入者線（ＡＤＳＬ：Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）や、ＷｉＭａｘ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）が例として挙げられる。しかし、本発明は、それらのメディアまたはテクノロジーのみに限定されるものではないという点に注意すべきである。同様に、３つのアクセスノードのみが図に描かれているが、ネットワーク２００は、潜在的に数百または数千のアクセスノードを含んでいる点にも注意すべきである。

アクセスドメインは、以降で共に論じられるアクセスネットワーク１３０と地域ネットワーク１３５も含んでいる。アクセスネットワーク１３０と地域ネットワーク１３５の第一の機能は、アクセスノード１２０、ネットワークサービスプロバイダ１４０、およびアプリケーションサービスプロバイダ１５０間でエンド・トゥ・エンドの、独立した転送を提供することである。アクセスネットワーク１３０および地域ネットワーク１３５は、次のような役割を果たすネットワークである。その役割とは、ダウンストリームおよびアップストリームのデータトラフィックを集合し、スイッチングし、およびルーティングするような役割である。アクセスネットワーク１３０は、ＯＳＩモデルのレイヤー２に対応するイーサネット（登録商標）、または他の同様なプロトコルを好適に使用することができる。しかし、ＯＳＩモデルのレイヤー２に対応するプロトコルに限定はされない。アクセスネットワーク１３０は、ＩＰｖ４および／またはＩＰｖ６を有利にサポートすることができる。地域ネットワーク１３５は、イーサネット（登録商標）および／またはＩＰとＭＰＬＳを好適にサポートし、可能な他のレイヤー３のプロトコルをサポートする。さらに、アクセスネットワーク１３０と地域ネットワーク１３５は、１または複数の異なる操作者によって、操作、および／または管理されることが可能である。

アクセスエッジノード１６０を通しての、それらのトラフィックエンジニアリング能力の強い結合を通して、アクセスネットワーク１３０および地域ネットワーク１３５はエンド・トゥ・エンドのサービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を提供することができるのである。アクセスエッジノード１６０の役割は、サービスエージェント１７０とサービスバインディング（図２には描かれていないが、図４に描かれている）の作成、管理、およびホスティングである。それぞれのサービスエージェント１７０は、１つのサービスプロバイダドメイン（１４０または１５０）に対応し、対応するサービスプロバイダドメインに対して、アクセスネットワーク１３０上のＶＬＡＮを管理し、制御する。“サービスバインディング”という表現は、ユーザドメイン１１０と１つのネットワークサービスプロバイダドメイン１４０との間、または、ユーザドメイン１１０と１つのアプリケーションサービスプロバイダドメイン１５０との間のバインディングのことを表している。サービスエージェントおよびサービスバインディングの概念とアクセスエッジノードとは図４、図５ａ、図５ｂについて述べる記述で、さらに詳しく記述される。

次に、ユーザドメイン１１０について述べる。ユーザドメインは、ユーザドメイン１１０とネットワークサービスプロバイダ１４０との間、および、ユーザドメインと１１０アプリケーションサービスプロバイダ１５０との間でのエンド・トゥ・エンドの通信を処理するためのアクセスドメイン１１５に関する。本記述では、“ドメイン”という言葉は、１または複数の、よく似た機能特性を持つネットワーク構成要素のことを表していることに注意すべきである。このように、本発明に関しては、“ユーザドメイン”という表現は、独立したコンピュータや、物理的にあるいは無線で、ルータを通してつながれたコンピュータのローカルネットワークや、携帯電話や、携帯情報端末（ＰＤＡ：Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）や、ネットワーク２００のようなネットワーク上でデータ通信可能なすべての他のデバイスのことを表す。さらに、“ユーザドメイン”という表現は、同時に起こる複数のデータトラフィックセッションを含むことが意図されている。その同時に起こる複数のデータトラフィックセッションは、１つのシングルユーザポートを通して、複数のデバイスによって実行される。例えば、ユーザは、インターネット接続やテレビ会議やテレビ番組のような異なるアプリケーションとネットワークサービスに同時にアクセスすることができる。その際、ユーザは、１または複数のデバイスを使用して、ＶＬＡＮに設けられたユーザドメインを通して、または、ここで“ユーザドメイン”と表現される１つのシングルユーザポートを通して、同時にアクセスすることができる。

ネットワークサービスプロバイダ１４０は、ＩＰアドレスの割り当てと、他のネットワークへの接続を提供するために、そして、特定のアプリケーションを提供し届けるために、アクセスドメイン１１５を使用するエンティティを表している。ユーザドメイン１１０を持つデータトラフィックに関しては、典型的に、ネットワークサービスプロバイダ１４０は、例えばＲＡＤＩＵＳ（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ―Ｉｎ ＵｓｅｒＳｅｒｖｉｃｅ）に基づく識別を使用して、ＩＰアドレスを所有し、ユーザドメイン１１０にＩＰアドレスを割り当てる。さらに、もし、要求された場合、および／または必要な場合、ネットワークサービスプロバイダ１４０は、ユーザレベルの認証と権限付与を行う。

アプリケーションサービスプロバイダ１５０は、ユーザドメイン１１０のエンドユーザにアプリケーションを提供し届けるために、アクセスドメイン１１５を使用する。その様なアプリケーションの例は、ゲーム、ビデオ・オンデマンド、テレビ会議、およびその他多くの可能なアプリケーションを含む。しかし、アプリケーションサービスプロバイダに代わってユーザドメイン１１０にＩＰアドレスを割り当てるのは、アクセスドメイン１１５である。もし、要求されれば、アプリケーションサービスプロバイダ１５０は、ユーザレベルでの認証も行うことが可能であり、もし必要であれば、権限付与も行う。前述の記述で、“サービスプロバイダ”と“サービスプロバイダドメイン”という表現は、ネットワークサービスプロバイダ１４０とアプリケーションサービスプロバイダ１５０の両方を同時に表現するために、代わりに用いられている。“サービスプロバイダ”という表現はネットワークサービスプロバイダ１４０またはアプリケーションサービスプロバイダ１５０の1つを表現している場合もある。

次に、図３に関して述べる。図３は、本発明に従ってデータトラフィックを集合する方法の簡略化されたフローチャートである。本方法は、アクセスドメイン１１５上でデータトラフィックの集合を行う。アクセスドメイン１１５は、複数のネットワークサービスプロバイダ１４０、複数のアプリケーションサービスプロバイダ１５０、および複数のユーザドメイン１１０の間でデータトラフィックを転送する。本方法は、アクセスドメイン１１５上で複数のサービスエージェントを構築するためのステップ３００によって、随意にスタートする。しかし、複数のサービスエージェントを構築するステップ３００は、毎回実行されるのではなく、アクセスエッジノード１６０がアクセスドメイン１１５に導入されたときに実行されるということに注意すべきである。その後、本方法は、ステップ３１０から始まる。ステップ３１０では、アクセスエッジノード１６０上でサービス要求関連メッセージを受信する。サービス要求関連メッセージは、１つのサービスプロバイダおよび１つのユーザドメインを識別する。サービス要求関連メッセージは、例えば、識別されたサービスプロバイダのウェブページへの識別されたユーザドメインによるアクセスを通して発生する。次に、本方法は、ステップ３２０に続く。ステップ３２０では、構築されたサービスエージェントの1つが、識別されたサービスプロバイダ１４０または１５０に対応するかどうかを識別する。そして、本方法は、ステップ３３０を実行する。ステップ３３０では、サービスバインディングが必要とされるかどうかを決定する。もしサービスバインディングの必要の有無を決定するステップ３３０が真であれば、本方法は、ステップ３４０に続く。ステップ３４０では、受信したサービス要求関連メッセージのためのサービスバインディングを作成する。次に、本方法は、ステップ３５０に続く。ステップ３５０では、サービス要求関連メッセージの中で識別されたユーザドメインに接続を提供する責任を持つアクセスノード１２０に、サービスバインディングを作成したという情報を伝達する。このようにして、サービス要求関連メッセージの中で識別され、識別されたサービスプロバイダにアドレスを割り当てられたユーザドメインから受信したデータトラフィックが、アクセスドメイン上で作成されたサービスバインディングに従って集合される、という情報がアクセスノード１２０に伝達される。そして、本方法は、ステップ３６０に続く。ステップ３６０では、識別されたユーザドメインとサービスプロバイダのためのアクセスエッジノード、またはアクセスノードで受信され、アクセスドメイン１１５上で転送されるデータトラフィックが、作成されたサービスバインディングに従って集合される。ステップ３３０の中で、サービスバインディングが必要ないと決定された場合は、本方法はステップ３７０へと続く。ステップ３７０では、受信されたサービス要求関連メッセージのためのサービスバインディングがすでに存在するかどうかを決定する。ステップ３７０での決定の結果、サービスバインディングがすでに存在している場合、本方法は、ステップ３５０を実行する。ステップ３５０では、アクセスノード１２０に存在するサービスバインディングの情報を伝達する。前述の結果の代わりに、もし、ステップ３７０での決定の結果が偽である場合、本方法はステップ３８０に続く。ステップ３８０では、受信したサービス要求関連メッセージに対応するデータトラフィックを、アクセスドメイン１１５上で集合せずに、転送する。

前述のように、サービスバインディングは転送関係に関連する。転送関係は１つのユーザドメインと１つのサービスプロバイダとの間で構築され、接続を提供するアクセスノード１２０とアクセスエッジノード１６０の１つのサービスエージェント１７０とに直接的に影響を及ぼす。概念的に言えば、サービスバインディングの作成は、アクセスドメイン上でサービスプロバイダドメインに対応するＶＬＡＮに識別されたユーザドメインを追加することに対応する。このように、それぞれのサービスバインディングは、取引可能なビジネスエンティティを表現している。取引可能なビジネスエンティティは、ユーザドメインの特定のユーザポートとサービスプロバイダの特定のプロバイダポートとの間で、適切な状態とＱｏＳを保ち、対応するサービスを届けることを保証する。サービスバインディングは、アクセスエッジノード内で作成され、管理され、ホストされ、サービスエージェント１７０と結合して存在する。

アクセスエッジノード内で、サービスエージェントおよびサービスバインディングが、作成され、管理され、ホストされる。そのため、図２と図４に関して同時に述べる。図４は本発明の開示に従うアクセスエッジノードの概略図である。サービスエージェントおよびサービスバインディングの作成、管理、及びホスティングの役割を果たすことを可能とするために、アクセスエッジノードは複数の要素から構成されている。アクセスドメイン１１５内でのアクセスエッジノードの位置的な理由で、アクセスドメイン１１５のアクセスネットワーク１３０およびアクセスノード１２０と通信するために、アクセスエッジノードは、アクセスドメイン入出力ユニット４１０を含む入出力ユニットを含んでいる。サービス要求関連メッセージ４２０を受信するのも、アクセスドメイン入出力ユニット４１０である。アクセスエッジノード１６０の入出力ユニットは、地域ネットワーク１３５上でネットワークサービスプロバイダ１４０およびアプリケージョンサービスプロバイダ１５０と通信を行うためのネットワーク／アプリケーションサービスプロバイダドメイン入出力ユニット４３０も含んでいる。さらに、アクセスエッジノード１６０は、サービスエージェントユニット４４０および制御ユニット４５０を含み、さらに、翻訳テーブル４６０、転送ユニット４７０、および調整ユニット４８０を含むこともある。

サービスエージェントユニット４４０は、サービスエージェント管理・制御ユニット４４２およびサービスバインディングホスティングユニット４４４から構成されている。サービスエージェントユニット４４０は、存在するサービスエージェント１７０の情報をサービスエージェント管理・制御ユニット４４２内に保持する。次に、サービスエージェント管理・制御ユニット４４２は、サービスバインディング４４６を作成し、管理する責任を持つ。そのため、サービスエージェント管理・制御ユニット４４２は、いつ新しいサービスバインディング４４６が要求される、または削除されるかを決定し、続けてサービスバインディング４４６の作成／削除を行う。サービスエージェント管理・制御ユニット４４２は、存在するサービスバインディングへのユーザデバイスの追加／削除にも責任がある。さらに、サービスエージェント管理・制御ユニット４４２は、相互に通信するアクセスノードとのサービスバインディング４４６関連情報の共時性を確保する責任を持つ。サービスエージェント管理・制御ユニット４４２は、アクセスネットワーク１３０内で、ＭＰＬＳ（Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）によって確保された経路が要求された場合、そのような経路の作成にも責任を持つ。図７と図８と共になされる説明では、様々な責任を果たすためにサービスエージェント管理・制御ユニットによって使用される様々なメッセージの包括的な説明が提供される。

次に、図４と図５ａに関して同時に述べる。図５ａは、サービスエージェント管理・制御ユニット４４２の項目を例示した図表である。ヘッダ行である最初の行は例外として、図５ａにおけるそれぞれの行は、サービスエージェント管理・制御ユニット４４２によって管理され、制御されるいくつかのサービスエージェント１７０の項目を例示している。図５ａのそれぞれの列は、それぞれのサービスエージェント１７０のために、サービスエージェント管理・制御ユニット４４２によって保持される特定の情報に対応している。１列目はサービスエージェント１７０の識別を表している。その識別は典型的には、対応するサービスエージェントのサービスエージェント識別子か、または数字である。本発明の好適な一実施形態において、アクセスエッジノード内のそれぞれのサービスエージェントは、ユニークなサービスエージェント識別子を持っており、１つの特定のサービスプロバイダドメイン１４０または１５０に対応している。２列目は、対応するサービスエージェントのための特定のサービスタイプの識別を示している。例えば、１つのサービスプロバイダドメイン１４０または１５０が複数のサービスを提供する場合は、提供されたそれぞれのサービスは、サービスプロバイダドメインの様々なサービス間の差別化のために、異なるサービスタイプと関連付けられる。３列目は、好適な、あるいは必要なサービス品質（ＱｏＳ）を識別する。前述のサービス品質（ＱｏＳ）は、関連付けられたサービスタイプと前述のサービスプロバイダドメインのために、適切にデータトラフィックを転送するために必要なサービス品質（ＱｏＳ）である。ＱｏＳの評価基準の例としては、遅延、ビット誤り率、帯域幅、および推奨プロトコルなどがある。４列目は、対応するサービスプロバイダドメインと通信するために、地域ネットワーク内で使用されるポートを指し示している。この項目に加え、追加されたサービスエージェントを作成し、不要になったサービスエージェントを削除するために、サービスエージェント管理・制御ユニット４４２は、十分な論理ソフトウェアとハードウェアとを含んでいる。図５ａ中では、サービスエージェント管理・制御ユニットの項目は表の形で表現されているが、そのような項目は図５ａで示されているものに限定されないという点に十分注意すべきである。サービスエージェント管理・制御ユニットは、リレーショナルデータベース、ハードコーディングされた構成要素、マイクロプロセッサ、プログラミングライブラリ、などで構成されることも可能である。

次に、図４と図５ｂに関して同時に述べる。図５ｂは、本発明の開示におけるサービスバインディングホスティングユニットの項目を例示した図表である。ヘッダ行は例外として、図５ｂにおけるそれぞれの行は、サービスバインディングホスティングユニット４４４内でホストされるいくつかのサービスバインディング４４６の項目を例示している。図５ｂのそれぞれの列は、それぞれのサービスバインディング４４６のために、サービスバインディングホスティングユニット４４４内でホストされる特定の情報に対応している。１列目は、例えば、サービスエージェントのサービスエージェント識別子を使用することによって、対応するサービスエージェントの識別を表している。２列目は、図５ａに関して記述されたように、サービスタイプを識別する。その他の列は、サービスバインディングに関するデータトラフィックの転送プリミティブを表している。さらに明確に言えば、３列目はユーザドメインのＭＡＣアドレス（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｌ ａｄｄｒｅｓｓ）を識別する。４列目は、接続を提供するアクセスノード上でユーザドメインによって使用されるポートの識別から構成される。５列目は、ユーザドメインによって使用される、ローカルネットワーク不定識別子に対応し、例えば、潜在的な、あるいは明示的なＶＬＡＮ情報を含むこともある。６列目は、ユーザドメインに接続を提供するアクセスノードの仮想ＭＡＣアドレスを表している。このように、１つのユーザドメインと１つのサービスプロバイダドメイン１４０または１５０との間のデータトラフィックを提供するために、それぞれのサービスバインディング４４６は、１つのサービスエージェントと１つのユーザドメインと１つのアクセスノードとを結びつける。図５ｂ中では、サービスバインディングホスティングユニット４４４の項目は表の形で表現されているが、そのような項目は図５ｂで示されているものに限定されないという点に注意すべきである。サービスバインディングホスティングユニットは、リレーショナルデータベース、ハードコーディングされた構成要素、マイクロプロセッサ、プログラミングライブラリ、などで構成されることも可能である。

さらに、サービスバインディングホスティングユニットは７つめのさらなる項目を含むことも可能である。この７つめの項目は、その項目によってユーザドメインまたはユーザデバイスが、ユニークに識別されるＩＰアドレスを含む。そのユニークなＩＰアドレスは、例えば、サービス要求メッセージより優先的に実行されるブロードキャストメカニズムを使用して、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のようなプロトコルを通して、アクセスエッジノードによって、ユーザドメインまたはユーザデバイスに提供される。このように、ユーザドメインまたはユーザデバイスのユニークなＩＰアドレスと、サービスエージェント識別子との組み合わせは、入ってくるメッセージを適切なサービスバインディングにすばやく関係付けるための、簡潔で信頼性のある方法を表す。典型的に、サービスバインディングが一度作成されると、その情報がアクセスノードに伝達され、データトラフィックがサービスバインディングに従ってアクセスドメイン上で集合される。そして、アクセスエッジノードで受信された集合されたデータトラフィックは、サービスバインディングホスティングユニットによって提供される情報を使用して、対応するサービスプロバイダドメインへの転送よりも優先的に分解される。特に、アクセスドメインがイーサネットネットワークである場合は、サービスエージェント識別子は、例えば、ユニキャスト、マルチキャスト、およびブロードキャストメッセージのＶＬＡＮタグとして知られているフィールド内で提供される。一方、このとき、ユーザドメインまたはユーザデバイスのＩＰアドレスは、イーサネットメッセージの中に埋め込まれたＩＰメッセージ内で提供される。イーサネットメッセージのＶＬＡＮタグフィールド内で提供されたサービスエージェント識別子に基づいて、そして、埋め込まれたＩＰメッセージ内で提供されたＩＰアドレスに基づいて、サービスエージェントユニット４４０は、データトラフィックを分解し、ユーザのＭＡＣ情報やローカルネットワークコンテキストのような送信元ユーザドメインについての必要な情報を確実に含め、対応するサービスプロバイダドメインへデータトラフィックを確実に転送することができる。

図４に話を戻すが、アクセスエッジノードの制御ユニット４５０は、サービス要求関連メッセージ４２０を受信すると、サービス要求関連メッセージ４２０が１つのサービスエージェントに対応するかどうかを決定する責任がある。そうするために、制御ユニット４５０は、１つのサービスエージェント１７０がサービス要求関連メッセージ４２０の中で識別されたサービスプロバイダドメインに対応するかどうかを決定するサービスエージェント管理・制御ユニット４４２に問い合わせる。１つのサービスエージェント１７０が、サービス要求関連メッセージ４２０の中で識別されたサービスプロバイダドメインに対応する場合、制御ユニット４５０は、受信したサービス要求関連メッセージのためにサービスバインディング４４６を作成するよう、サービスエージェント管理・制御ユニット４４２に指示を出す。受信したサービス要求関連メッセージ４２０のためにサービスバインディング４４６を作成することは、サービスバインディングホスティングユニット４４４に以下のようにエントリを追加することを含んでいる。
―サービスエージェントＩＤ（１列目）は、要求されたサービスプロバイダドメインに対応するサービスエージェントのためのサービスエージェント識別子に対応する。
―ユーザのＭＡＣ情報は、ユーザデバイスのＭＡＣアドレスである。
―アクセスノード上のユーザポートは、接続を提供するアクセスノード上のポートの識別であり、ユーザデバイスは、接続を提供するアクセスノードと連結されている。
―ローカルネットワークコンテキストは、ユーザデバイスから受信したイーサネットメッセージの“ＶＬＡＮタグ”のラベルがつけられたフィールド内で提供される不定の識別子、およびローカルユーザドメイン識別子と対応する不定の識別子と対応する。
―アクセスノードＭＡＣは、それに関するサービス要求関連メッセージが受信された、接続を提供するアクセスノードに関する仮想のＭＡＣアドレスである。

その後、制御ユニット４５０は、サービス要求関連メッセージ内で識別されたユーザドメインに接続を提供するアクセスノードに、サービスバインディング４４６を作成したという情報を伝達する。このとき、情報の伝達は、アクセスドメイン入出力ユニット４１０によって送信されたサービスバインディング関連メッセージ４９０を通して行われる。サービス要求関連メッセージ４２０のためのサービスバインディングがすでに存在する場合は、制御ユニット４５０は、サービスバインディング関連メッセージ４９０を通して、接続を提供するアクセスノードにサービスバインディングが存在するという情報を伝達する。

制御ユニット４５０は、翻訳テーブル４６０とも協働する。サービスエージェント管理・制御ユニットのそれぞれのサービスエージェント１７０は、サービスエージェント識別子によってユニークに識別されるため、翻訳テーブル内で、サービスエージェント１７０に対応するサービスエージェント識別子と、対応するサービスプロバイダドメイン（１４０または１５０）との間のマッピングを保持することは必要不可欠である。このように、アクセスドメイン入出力ユニット４１０で、アクセスエッジノード１６０のための仮想ＭＡＣアドレスに対応する目的アドレスを持ち、１つのサービスエージェント識別子に対応するＶＬＡＮタグを持つデータトラフィックを受信すると、アクセスエッジノードの仮想ＭＡＣアドレスを、ＶＬＡＮタグの中で提供されたサービスエージェント識別子に対応する目的サービスプロバイダドメインアドレス（１４０または１５０のアドレス）へすばやく変換するために、制御ユニット４５０は、翻訳テーブル４６０に問い合わせる。

さらに、アクセスドメイン入出力ユニット４１０で受信したデータトラフィックが、何も変更せずに、サービスプロバイダドメイン入出力ユニットに直接転送されるかどうかを決定するために、制御ユニット４５０は、転送ユニット４７０に問い合わせる。
最後に、制御ユニット４５０は、調整ユニット４８０とも協働する。調整ユニット４８０は、アクセスドメイン入出力ユニット４１０とネットワーク／アプリケーションサービスプロバイダドメイン入出力ユニット４３０のどちらでデータトラフィックを受信した場合でも、対応するサービスエージェント１７０によって指し示された、および／または要求されたように、アップストリーム／ダウンストリームのトラフィックの秩序を保ち、マーキングし、トラフィックをリマーキングする。

次に、図６に関して述べる。図６は、本発明の開示に従った１つのアクセスノードの概略図である。アクセスドメイン１１５内での位置的な理由で、アクセスノード１２０は、アクセスドメイン１１５のアクセスネットワーク１３０とアクセスエッジノード１６０と通信するために、アクセスドメイン入出力ユニット６１０を含んでいる。アクセスノード１２０は、ユーザドメイン１１０と通信するために、ユーザドメイン入出力ユニット６２０も含んでいる。アクセスドメイン入出力ユニット６１０で受信されるメッセージタイプは、サービスバインディング関連メッセージ４９０である。サービスバインディング関連メッセージ４９０は、アクセスエッジノード１６０によって発生させられ、アクセスネットワーク１３０上で送信される。サービスバインディングメッセージ４９０の例は、図７と図８についての記述の中で提供される。

アクセスノード１２０は複数のサービスバインディング関連メッセージ４９０を受信し、処理することができる。サービスバインディング関連メッセージ４９０は、アクセスネットワーク１３０から来て、アクセスドメイン入出力ユニット６１０を通してアクセスノード１２０で受信される。サービスバインディング関連メッセージ４９０を受信すると、アクセスドメイン入出力ユニットは、受信したサービスバインディング関連メッセージ４９０を制御ユニット６３０に転送する。制御ユニット６３０は、サービスバインディング関連メッセージ４９０のコンタクトを抽出し、実行すべき処理があるかどうかを決定する。サービスバインディング関連メッセージ４９０の例は、新しいサービスバインディングの作成に関する情報である。前述のように、アクセスエッジノード１６０が、新しいサービスバインディングが要求されていると決定した場合、続けて、サービスバインディングの作成と、要求を出しているユーザドメインに接続を提供しているアクセスノードへの、サービスバインディングが作成されたという情報の伝達とが行われる。この特別な場合に使用されるサービスバインディング関連メッセージ４９０は、ＡＤＤ＿ＳＢ（ａｄｄ ｓｅｒｖｉｃ ｂｉｎｄｉｎｇ）と呼ばれる。ＡＤＤ＿ＳＢメッセージは、アクセスエッジノード１６０からアクセスノード１２０に送信され、作成されたサービスバインディングについての情報を含んでいる。ＡＤＤ＿ＳＢメッセージに含まれている情報は、その後、アクセスノード１２０の集合ユニット６８０に取り入れられる。

集合ユニット６８０の様々な責任のうちの１つは、サービスバインディング関連情報のホスティングである。サービスバインディング関連情報は、（サービスエージェント属性とサービスタイプの形の）特定のサービスバインディング情報とサービス要求関連メッセージを受信するアクセスノードのポートにおける識別とユーザドメインのローカルネットワークコンテキストとを含む。

アクセスノード１２０は、さらに、ユーザドメインから送信された／ユーザドメインに送信される、受信したデータトラフィックを処理し、ユーザドメインにアクセスネットワーク１３０への接続サービスを提供する。そのため、アクセスノード１２０は、さらに、翻訳テーブルと６５０と転送ユニット６６０と調整ユニット６７０と集合ユニット６８０とを含む。そうすることで、アクセスノード１２０において、ユーザドメイン入出力ユニット６２０またはアクセスドメイン入出力ユニット６１０のどちらで受信されたデータトラフィックも、制御ユニット６３０に転送される。制御ユニット６３０は翻訳テーブル６５０と協働する。サービスエージェントユニット４４０のサービスバインディングホスティングユニット４４４に格納されているそれぞれのサービスバインディングは、パラメータ（サービスエージェント属性、サービスタイプ、ユーザデバイスＭＡＣアドレス、および、アクセスノード仮想ＭＡＣアドレス）の組み合わせによって識別される。そのため、翻訳テーブル６５０内で、サービスエージェント１７０に対応するサービスエージェント属性と対応するサービスプロバイダドメイン（１４０または１５０）との間のマッピングを保持することは必要不可欠である。このように、アクセスドメイン入出力ユニット６１０で、アクセスノード１２０の仮想ＭＡＣアドレスに対応する目的アドレスを持つデータトラフィックを受信すると、ユーザドメインＭＡＣアドレスとローカル識別子とのそれぞれに対応するために、制御ユニット６３０は、目的アドレスとＶＬＡＮタグをすばやく変換するために、翻訳テーブル６５０に問い合わせる。ユーザドメイン情報が、アクセスエッジノード１６０とアクセスノード１２０との間のアクセスドメイン上で運ばれないため、そのような変換が必要となる。本発明の一実施形態は、このように、ユーザドメインの観点からすると、アクセスドメイン上でデータトラフィックを途切れずに集合させることを可能とする。

さらに、アクセスドメイン入出力ユニット６１０またはユーザドメイン入出力ユニット６２０で受信したデータトラフィックが、何も変更せずに、対応するユーザドメイン１１０またはアクセスネットワーク１３０に直接転送されるかどうかを決定するために、制御ユニット６３０は、転送ユニット６６０に問い合わせる。
最後に、制御ユニット６３０は、調整ユニット６７０とも協働する。調整ユニット６７０との相互作用は、サービスバインディングの属性内で指し示されたように、ダウンストリーム／アップストリームトラフィックの秩序を保ち、マーキングし、トラフィックをリマーキングする必要があるときに、要求される。

次に、図７に関して述べる。図７はアクセスノード１２０とアクセスエッジノード１６０との間でやり取りされるいくつかのメッセージのフローチャートである。それらのメッセージは、アクセスノード１２０とアクセスエッジノード１６０との間の管理とトラフィック操作とに関する情報を運ぶ。図７に描かれたメッセージは、順次読まれるのではなく、それぞれのアクセスノード１２０とアクセスエッジノード１６０の間で情報をやり取りするための、可能なメッセージの例のリストとして読まれるべきである。図７上でやり取りされるメッセージは、前述の記述を通して、代わりに、“サービスバインディング関連メッセージ４９０”とも呼ばれている。図７に描かれているメッセージリストは、アクセスノード１２０とアクセスエッジノード１６０の間でやり取りされる徹底的で、完全なメッセージリストとして読まれるべきではなく、メッセージの例として読まれるべきである。

図７に描かれている１つめのメッセージは、ＡＬＩＶＥメッセージ７００と呼ばれている。ＡＬＩＶＥメッセージ７００は、現在はアクセスエッジノード１６０によって活動中でないとみなされる、という情報を伝達するために、アクセスエッジノード１６０からアクセスノード１２０の１つに向けて送信される。ＡＬＩＶＥメッセージ７００を受信したアクセスノード１２０に対しては、前述のＡＬＩＶＥメッセージ７００の受信は、アクセスエッジノード１６０へのＳＹＮＣメッセージ７０５の送信を引き起こす。ＳＹＮＣメッセージ７０５は、送信元のアクセスノード１２０に格納された集合ユニット６８０内で格納されたローカル設定が失われたか、古くなったことを通知するために使用されることが可能である。ＳＹＮＣメッセージ７０５は、送信元のアクセスノード１２０の設定が再構築される必要があることをアクセスエッジノード１６０に通知する。ＳＹＮＣメッセージ７０５の後には、典型的に、ＣＯＮＦＩＧ−ＡＮメッセージ７１０が続く。ＣＯＮＦＩＧ−ＡＮメッセージ７１０は、メッセージを受信したアクセスノード１２０でそのローカル設定を再構築するために必要な情報を含んでいる。ＣＯＮＦＩＧ−ＡＮメッセージ７１０が正しく受信されたか否かを確証するために、ＣＯＮＦＩＧ−ＡＮメッセージの後にはＣＯＮＦＩＧ−ＡＮ ＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージ、またはＣＯＮＦＩＧ−ＡＮ ＮＡＣＫ（ｎｏ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージ７１５が続く。

さらに図７について記述すると、アクセスノード１２０とアクセスエッジノード１６０の間でやり取りされる、もう１つの別のメッセージタイプは、ＡＤＤ＿ＳＢメッセージ７２０である。そのＡＤＤ＿ＳＢメッセージ７２０によって、アクセスエッジノード１６０が、新しいサービスバインディングをそのローカル設定に追加した、または、存在するサービスバインディングをアップデートしたという情報を、メッセージを受信するアクセスノード１２０に伝達することが可能となる。ＡＤＤ＿ＳＢメッセージ７２０の後には、ＡＤＤ＿ＳＢ ＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージ、またはＡＤＤ＿ＳＢ ＮＡＣＫ（ｎｏ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージ７２５が続く。

やり取りされるもう１つの別のメッセージタイプは、特に、ＩＰｖ４のためのサービスバインディングに関する。メッセージＡＤＤ＿ＵＤ＿ＩＰｖ４ ７３０は、ＩＰｖ４のための存在するサービスバインディングに対してユーザデバイスを追加する、またはアップデートすることを、メッセージを受信するアクセスノード１２０に通知する。ＡＤＤ＿ＵＤ＿ＩＰｖ４メッセージの後には、ＡＤＤ＿ＵＤ＿ＩＰｖ４ ＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージ、またはＡＤＤ＿ＵＤ＿ＩＰｖ４ ＮＡＣＫ（ｎｏ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージ７３５が続く。アクセスエッジノード１６０によって発生させられる、ＩＰｖ４サービスバインディングに関するもう１つの別のメッセージは、ＲＥＭ＿ＵＤ＿ＩＰｖ４メッセージ７４０である。ＲＥＭ＿ＵＤ＿ＩＰｖ４メッセージ７４０は、ＩＰｖ４のための存在するサービスバインディングに対してユーザデバイスを削除することを、アクセスエッジノード１６０がメッセージを受信するアクセスノード１２０に通知することを可能とする。前述のメッセージと同様、ＲＥＭ＿ＵＤ＿ＩＰｖ４メッセージ７４０の後には、ＲＥＭ＿ＵＤ＿ＩＰｖ４ ＡＣＫ、またはＲＥＭ＿ＵＤ＿ＩＰｖ４ ＮＡＣＫメッセージ７４５の形で、アクセスノード１２０からの応答メッセージが続く。

ＩＰｖ４のサービスバインディングのためのメッセージと同様に、ＩＰｖ６のサービスバインディングのための一連のメッセージが提供される。メッセージＡＤＤ＿ＵＤ＿ＩＰｖ６ ７５０は、ＩＰｖ６のための存在するサービスバインディングに対してユーザデバイスを追加する、またはアップデートすることを、メッセージを受信するアクセスノード１２０に通知する。ＡＤＤ＿ＵＤ＿ＩＰＶ６メッセージの後には、ＡＤＤ＿ＵＤ＿ＩＰＶ６ ＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージ、またはＡＤＤ＿ＵＤ＿ＩＰＶ６ ＮＡＣＫ（ｎｏ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージ７５５が続く。アクセスエッジノード１６０によって発生させられる、ＩＰｖ６サービスバインディングに関するもう１つの別のメッセージは、ＲＥＭ＿ＵＤ＿ＩＰｖ６メッセージ７６０である。ＲＥＭ＿ＵＤ＿ＩＰｖ６メッセージ７６０は、ＩＰｖ６のための存在するサービスバインディングに対してユーザデバイスを削除することを、アクセスエッジノード１６０がメッセージを受信するアクセスノード１２０に通知することを可能とする。前述のＲＥＭ＿ＵＤ＿ＩＰｖ４メッセージ７４０と同様、ＲＥＭ＿ＵＤ＿ＩＰｖ６メッセージ７６０の後には、ＲＥＭ＿ＵＤ＿ＩＰｖ６ ＡＣＫ、またはＲＥＭ＿ＵＤ＿ＩＰｖ６ ＮＡＣＫメッセージ７６５の形で、アクセスノード１２０からの応答メッセージが続く。

アクセスエッジノード１６０からアクセスノードに送信される、もう１つ別のメッセージタイプは、ＲＥＭ＿ＳＢメッセージ７７０である。ＲＥＭ＿ＳＢメッセージ７７０は、ローカル設定からメッセージ中で識別されたサービスバインディングを削除することをアクセスノード１２０に通知する。アクセスノード１２０でサービスバインディングの削除が完了すると、通知されたサービスバインディングのローカル設定からの削除が完了したことを確証する、または、正しく完了しなかったことを通知するために、ＲＥＭ＿ＳＢ＿ＡＣＫメッセージまたはＲＥＭ＿ＳＢ＿ＮＡＣＫメッセージ７７５が、アクセスノードからアクセスエッジノード１６０に送信される。
前述で列挙された様々なメッセージをアクセスエッジノード１６０から受信すると、メッセージを受信したアクセスノード１２０は、アクティブなサービスバインディングと同期するために、アクセスノード１２０のローカル設定に対して必要なアップデートを行うことが期待される。

次に、図８に関して述べる。図８には、図７のメッセージのフィールドを示す表が示されている。メッセージのフォーマット８００は、箱で描かれているフィールドを含んでおり、箱の底に対応するバイト数が示されている。最初のフィールドはバージョンフィールド８０５である。バージョンフィールドは、メッセージ内で使用されているバージョンを示している。対応する返答メッセージは、同じバージョンのプロトコルを使用して送信されることが望ましい。２番目のフィールドは、メッセージフラグフィールド８１０である。そのフィールドの１つの利用可能性は、１はメッセージが要求であることを示し、一方、０はメッセージが返答であることを示すバイトの、ビット０を使用することで示される。３番目のフィールドは、メッセージ長フィールド８１５である。メッセージ長フィールド８１５は、認証コードフィールド８５０を除く、ここで定義されている全てのフィールドから構成されるメッセージの全長を示している。続くフィールドは、タイムスタンプ８２０である。タイムスタンプフィールド８２０は、メッセージが送信された時間を示すために使用されている。タイムスタンプフィールドは、秒単位で正確に定義された協定世界時を使用している。サービスエージェント識別子８２５フィールドは、サービスの属性を指定する。サービスエージェント内のアプリケーションインスタンス識別子８３０は、アプリケーションインスタンスをサービスバインディングごとにユニークに指定する。メッセージ識別子フィールド８３５は、返答メッセージとその対応する要求メッセージとを相互に関係させるために、要求者によって使用される。次に続くのは、コマンド数フィールド８４０である。コマンド数フィールド８４０は、コマンドリスト中で指定されたコマンドの数を示すために使用される。コマンドリストフィールド８４５は、コマンドリストを表している。それぞれのコマンドは、次のフォーマットに従うことが望ましい。そのフォーマットは、２バイトがコマンドタイプに関し、２バイトがコマンドデータ長に関し、コマンドデータに関する可変バイト数を持つ。以下の表は、可能なコマンドタイプ、コマンドデータ長、およびコマンドデータに関する追加的な情報を提供する。最後に、認証コードフィールド８５０はメッセージを認証するために使用される。

上記の表の理解を助けるために、下記の頭字語とその定義のリストが提供される。
ＡＥＮ：アクセスエッジノード（ａｃｃｅｓｓ ｅｄｇｅ ｎｏｄｅ）
ＡＣＫ：アクナリッジメント（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）
ＡＤＤ＿ＡＵＴＨ＿ＭＡＣ：認定ＭＡＣの追加／アップデート（Ａｄｄ／ｕｐｄａｔｅ ａｎ ａｕｔｈｏｒｉｚｅ ＭＡＣ）
ＡＤＤ＿ＡＵＴＨ＿ＳＢ：認証されたサービスバインディングの追加／アップデート（Ａｄｄ／ｕｐｄａｔｅ ａｎ ａｕｔｈｅｎｔｉｃａｔｅｄ ｓｅｒｖｉｃｅ ｂｉｎｄｉｎｇ）
ＡＤＤ＿ＰＲＯＦＩＬＥ：制限プロファイルの追加／アップデート（Ａｄｄ／ｕｐｄａｔｅ ａ ｒａｔｅ ｌｉｍｉｔｉｎｇ ｐｒｏｆｉｌｅ）
ＡＤＤ＿ＳＢ：サービスバインディングの追加／アップデート（Ａｄｄ／ｕｐｄａｔｅ ａ ｓｅｒｖｉｃｅ ｂｉｎｄｉｎｇ）
ＡＤＤ＿ＵＤ＿ＩＰｖ４：ＩＰｖ４のための存在するサービスバインディングへのデバイスの追加／アップデート（Ａｄｄ／ｕｐｄａｔｅ ａ ｕｓｅｒ ｄｅｖｉｃｅ ｔｏ ａｎ ｅｘｉｓｔｉｎｇ ｓｅｒｖｉｃｅ ｂｉｎｄｉｎｇ ｆｏｒ ＩＰｖ４）
ＡＤＤ＿ＵＤ＿ＩＰｖ６：ＩＰｖ６のための存在するサービスバインディングへのデバイスの追加／アップデート（Ａｄｄ／ｕｐｄａｔｅ ａ ｕｓｅｒ ｄｅｖｉｃｅ ｔｏ ａｎ ｅｘｉｓｔｉｎｇ ｓｅｒｖｉｃｅ ｂｉｎｄｉｎｇ ｆｏｒ ＩＰｖ６）
ＡＮ：アクセスノード（ａｃｃｅｓｓ ｎｏｄｅ）
ＣＢＳ：コミッテッドバーストサイズ（Ｃｏｍｍｉｔｔｅｄ Ｂｕｒｓｔ Ｓｉｚｅ）
ＣＩＲ：コミッテッド情報比率（Ｃｏｍｍｉｔｔｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｒａｔｅ）
ＣＯＮＦＩＧ＿ＡＮ：アクセスノード設定（Ｃｏｎｆｉｇｕｒｅ Ａｃｃｅｓｓ Ｎｏｄｅ）
ＥＢＳ：超過バーストサイズ（Ｅｘｃｅｓｓ Ｂｕｒｓｔ Ｓｉｚｅ）
ＪＯＩＮ＿ＡＵＴＨ＿ＩＰｖ４：認証されたユーザデバイスに関するＩＰｖ４マルチキャストグループの結合／再結合（Ｊｏｉｎ／ｒｅ‐ｊｏｉｎ ＩＰｖ４ ｍｕｌｔｉｃａｓｔ ｇｒｏｕｐ ｆｏｒ ａｕｔｈｅｎｔｉｃａｔｅｄ ｕｓｅｒ ｄｅｖｉｃｅ）
ＪＯＩＮ＿ＡＵＴＨ＿ＩＰｖ６：認証されたユーザデバイスに関するＩＰｖ６マルチキャストグループの結合／再結合（Ｊｏｉｎ／ｒｅ‐ｊｏｉｎ ＩＰｖ６ ｍｕｌｔｉｃａｓｔ ｇｒｏｕｐ ｆｏｒ ａｕｔｈｅｎｔｉｃａｔｅｄ ｕｓｅｒ ｄｅｖｉｃｅ）
ＪＯＩＮ＿ＩＰｖ４：ＩＰｖ４マルチキャストグループの結合／再結合（Ｊｏｉｎ／ｒｅ−ｊｏｉｎ ＩＰｖ４ ｍｕｌｔｉｃａｓｔ ｇｒｏｕｐ）
ＪＯＩＮ＿ＩＰｖ６：ＩＰｖ６マルチキャストグループの結合／再結合（Ｊｏｉｎ／ｒｅ−ｊｏｉｎ ＩＰｖ６ ｍｕｌｔｉｃａｓｔ ｇｒｏｕｐ）
ＬＥＡＶＥ＿ＡＵＴＨ＿ＩＰｖ４：認証されたユーザデバイスに関するＩＰｖ４マルチキャストグループの分離（Ｌｅａｖｅ ＩＰｖ４ ｍｕｌｔｉｃａｓｔ ｇｒｏｕｐ ｆｏｒ ａｕｔｈｅｎｔｉｃａｔｅｄ ｕｓｅｒ ｄｅｖｉｃｅ）
ＬＥＡＶＥ＿ＡＵＴＨ＿ＩＰｖ６：認証されたユーザデバイスに関するＩＰｖ６マルチキャストグループの分離（Ｌｅａｖｅ ＩＰｖ６ ｍｕｌｔｉｃａｓｔ ｇｒｏｕｐ ｆｏｒ ａｕｔｈｅｎｔｉｃａｔｅｄ ｕｓｅｒ ｄｅｖｉｃｅ）
ＬＥＡＶＥ＿ＩＰｖ４：ＩＰｖ４マルチキャストグループの分離（Ｌｅａｖｅ ＩＰｖ４ ｍｕｌｔｉｃａｓｔ ｇｒｏｕｐ）
ＬＥＡＶＥ＿ＩＰｖ６：ＩＰｖ６マルチキャストグループの分離（Ｌｅａｖｅ ＩＰｖ６ ｍｕｌｔｉｃａｓｔ ｇｒｏｕｐ）
ＭＡＣ ａｄｄｒｅｓｓ：ＭＡＣアドレス（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ ａｄｄｒｅｓｓ）
ＰＢＳ：最大バーストサイズ（Ｐｅａｋ Ｂｕｒｓｔ Ｓｉｚｅ）
ＰＩＲ：最大情報比率（Ｐｅａｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｒａｔｅ）
ＲＥＭ＿ＡＵＴＨ＿ＳＢ：認証されたサービスバインディングの削除（Ｒｅｍｏｖｅ ａｎ ａｕｔｈｅｎｔｉｃａｔｅｄ ｓｅｒｖｉｃｅ ｂｉｎｄｉｎｇ）
ＲＥＭ＿ＰＲＯＦＩＬＥ：比率制限属性の削除（Ｒｅｍｏｖｅ ａ ｒａｔｅ‐ｌｉｍｉｔｉｎｇ ｐｒｏｆｉｌｅ）
ＲＥＭ＿ＳＢ：サービスバインディングの削除（Ｒｅｍｏｖｅ ａ ｓｅｒｖｉｃｅ ｂｉｎｄｉｎｇ）
ＲＥＭ＿ＵＤ＿ＩＰｖ４：ＩＰｖ４に関する存在するサービスバインディングからのユーザデバイスの削除（Ｒｅｍｏｖｅ ａ ｕｓｅｒ ｄｅｖｉｃｅ ｆｒｏｍ ａｎ ｅｘｉｓｔｉｎｇ ｓｅｒｖｉｃｅ ｂｉｎｄｉｎｇ ｆｏｒ ＩＰｖ４）
ＲＥＭ＿ＵＤ＿ＩＰｖ６：ＩＰｖ６に関する存在するサービスバインディングからのユーザデバイスの削除（Ｒｅｍｏｖｅ ａ ｕｓｅｒ ｄｅｖｉｃｅ ｆｒｏｍ ａｎ ｅｘｉｓｔｉｎｇ ｓｅｒｖｉｃｅ ｂｉｎｄｉｎｇ ｆｏｒ ＩＰｖ６）
ＳＮＤ＿ＡＮＤ：アクセスネットワークドメイン上でのフレーム送信（Ｓｅｎｄ ｆｒａｍｅ ｏｎ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｄｏｍａｉｎ）
ＳＮＤ＿ＥＴＨ＿Ｄ：フレームダウンストリームの送信（Ｓｅｎｄ ｆｒａｍｅ ｄｏｗｎｓｔｒｅａｍ）
ＳＮＤ＿ＥＴＨ＿Ｕ：フレームアップストリームの送信（Ｓｅｎｄ ｆｒａｍｅ ｕｐｓｔｒｅａｍ）
ＳＮＤ＿ＵＮＤ：特定のユーザポート上でのユーザドメインへのフレーム送信（Ｓｅｎｄ ｆｒａｍｅ ｏｎ ｔｈｅ ｓｐｅｃｉｆｉｅｄ ｕｓｅｒ ｐｏｒｔ ｔｏｗａｒｄ ｔｈｅ Ｕｓｅｒ Ｄｏｍａｉｎ）

本発明の方法とノードに関するいくつかの好適な実施形態は添付図面に示され、前述の詳細な記述で説明されているが、本発明は、記載された実施例に限定されず、特許請求の範囲に記載され定義された発明の技術的思考から離れない各種の変更や修正や代替は可能であることを理解すべきである。

ＩＰネットワークの従来技術例を示す説明図である。 本発明が組み込まれたネットワークを例示する概略図である。 本発明に従ってデータトラフィックを集合する方法の簡略化されたフローチャートである。 本発明の開示に従うアクセスエッジノードの概略図である。 本発明におけるサービスエージェント管理・制御ユニットの項目を例示した図表である。 本発明の開示におけるサービスバインディングホスティングユニットの項目を例示した図表である。 本発明の開示に従ったアクセスノードの概略図である。 本発明の開示に従って、アクセスノードとアクセスエッジノード間で交換されるメッセージを例示したフローチャートである。 本発明の開示に従って、アクセスノードとアクセスエッジノード間で交換されるメッセージの様々なフィールドを示した図表である。

Claims (18)

1. アクセスドメイン上でデータトラフィックを集合するアクセスエッジノードであり、
   前記アクセスドメインは、ユーザドメインとサービスプロバイダドメインとの間でデータトラフィックを運び、
   前記アクセスエッジノードは、サービスエージェントユニット、サービスバインディングユニット、入出力ユニット、および制御ユニットより構成され、
   前記サービスエージェントユニットは、サービスエージェントを提供し、
   それぞれの前記サービスエージェントは、１つの前記サービスプロバイダドメインに対応し、対応する１つの前記サービスプロバイダドメインに対して、前記アクセスドメイン上で仮想ローカルエリアネットワークを保持し、
   前記サービスバインディングユニットは、存在するサービスバインディング情報を提供し、
   それぞれの前記サービスバインディング情報は、１つの前記サービスエージェントの属性、ユーザドメイン情報、アクセスドメイン転送プリミティブを含み、
   前記入出力ユニットは、前記サービスプロバイダドメイン、前記アクセスドメイン、および前記アクセスドメインと前記ユーザドメインとに接続を提供するアクセスノードと通信し、
   さらに、前記入出力ユニットは、サービス要求関連メッセージを受信し、
   前記サービス要求関連メッセージは、１つの前記サービスプロバイダドメインおよび１つの前記ユーザドメインを識別し、
   前記制御ユニットは、前記入出力ユニットでサービス要求関連メッセージを受信すると、１つの前記サービスエージェントが、前記サービス要求関連メッセージ中で識別された前記サービスプロバイダドメインに対応するかどうかを決定し、
   もし、対応する前記サービスプロバイダドメインが存在すれば、前記サービスバインディングユニットの中で、対応するサービスバインディングを作成し、
   作成された前記サービスバインディングに従って、受信した前記サービス要求に関連するデータトラフィックを送信するために、前記サービス要求メッセージの中で識別された前記ユーザドメインに接続を提供するアクセスノードに情報を伝達する
   ことを特徴とする、アクセスドメイン上でデータトラフィックを集合するアクセスエッジノード。
2. 前記サービスバインディングユニット内で対応するサービスバインディングを作成することが、前記ユーザドメインを、要求された前記サービスプロバイダに対応する前記仮想ローカルエリアネットワークに追加することに対応し、
   その際、前記サービスバインディングユニット内に、要求されたサービスプロバイダに対応する前記サービスエージェントの属性、ユーザドメイン情報、およびアクセスドメイン転送プリミティブを持つエントリを追加することによって、要求された前記サービスプロバイダに対応する前記仮想ローカルエリアネットワークに追加することを特徴とする、
   請求項１に記載のアクセスエッジノード。
3. 前記入出力ユニットが、さらに、サービスプロバイダドメイン入出力ユニットとアクセスドメイン入出力ユニットから構成されており、
   前記サービスプロバイダドメイン入出力ユニットは、前記サービスプロバイダドメインと通信するために設けられており、
   前記アクセスドメイン入出力ユニットは、前記アクセスドメインおよびアクセスノードと通信するために設けられており、
   前記アクセスノードは、前記アクセスドメインと前記ユーザドメインとに接続を提供し、
   さらに、前記アクセスドメイン入出力ユニットは、前記サービスプロバイダドメインから前記サービス要求関連メッセージを受信し、
   前記サービス要求関連メッセージが、１つの前記サービスプロバイダドメインおよび１つの前記ユーザドメインを識別することを特徴とする、
   請求項２に記載のアクセスエッジノード。
4. それぞれの前記サービスバインディングの前記アクセスドメイン転送プリミティブが、少なくとも１つのユーザドメインＭＡＣアドレス、ユーザドメインローカルネットワークコンテキスト、および仮想アクセスノードＭＡＣアドレスを含むことを特徴とする、
   請求項２に記載のアクセスエッジノード。
5. いくつかの前記サービスバインディングが、イーサネットユニキャストサービスバインディングであることを特徴とする、請求項２に記載の前記アクセスエッジノード。
6. いくつかの前記サービスバインディングが、イーサネットマルチキャストサービスバインディングであることを特徴とする、請求項２に記載の前記アクセスエッジノード。
7. 前記サービスバインディングユニットが、１つのユーザドメインに対して複数のサービスバインディングを提供することを特徴とする、請求項２に記載の前記アクセスエッジノード。
8. アクセスドメイン上でデータトラフィックの集合を行う方法で、
   前記アクセスドメインは、複数のサービスプロバイダドメインと複数のユーザドメインとの間でデータトラフィックを運び、前記方法は、
   アクセスエッジノード内で複数のサービスエージェントを構築し、
   それぞれのサービスエージェントは、１つの前記サービスプロバイダドメインに対応し、対応する前記サービスプロバイダドメインに対して、アクセスドメイン上で仮想ローカルエリアネットワークを保持するステップと、
   前記アクセスエッジノードで、サービス要求関連メッセージを受信した時に、
   前記サービス要求関連メッセージが、１つの前記サービスプロバイダドメインおよび１つの前記ユーザドメインを識別し、
   構築された１つの前記サービスエージェントが、要求された前記サービスプロバイダドメインに対応するかどうかを決定するステップと、
   もし、１つの構築された前記サービスエージェントが、識別された前記サービスプロバイダドメインに対応すれば、
   前記アクセスエッジノードにおいて、受信した前記サービス要求関連メッセージのためにサービスバインディングを作成し、
   このとき、前記サービスバインディングは、対応する前記サービスエージェントの属性、識別されたユーザドメイン情報、およびアクセスドメイン転送プリミティブを含むステップと、
   識別された前記ユーザドメインと前記アクセスドメインに接続を提供する前記アクセスノードに、前記サービスバインディングが作成されたという情報を伝達するステップと、
   作成された前記サービスバインディングに従って、識別された前記ユーザドメインと識別された前記サービスプロバイダとの間のデータトラフィックを集合するステップと
   より構成されることを特徴とする、アクセスドメイン上でデータトラフィックの集合を行う方法。
9. サービスバインディングを作成する前記ステップが、要求された前記サービスプロバイダに対応する前記仮想ローカルエリアネットワークに、前記ユーザドメインを追加することに対応することを特徴とする、
   請求項８に記載の方法。
10. それぞれの前記サービスバインディングの前記アクセスドメイン転送プリミティブが、少なくとも１つのユーザドメインＭＡＣアドレス、ユーザドメインローカルネットワークコンテキスト、および仮想アクセスノードＭＡＣアドレスを含むことを特徴とする、
    請求項９に記載の方法。
11. いくつかの前記サービスバインディングが、イーサネットユニキャストサービスバインディングであることを特徴とする、請求項９に記載の方法。
12. 存在する仮想ローカルエリアネットワークの１つが、マルチプロトコルラベルスイッチングの確保された経路であることを特徴とする、請求項１０に記載の方法。
13. アクセスドメイン上でデータトラフィックを集合するアクセスノードであり、
    前記アクセスドメインは、ユーザドメインとサービスプロバイダドメインとの間でデータトラフィックを運び、
    前記アクセスノードは、入出力ユニット、集合ユニット、および制御ユニットより構成され、
    前記入出力ユニットは、前記アクセスドメイン上で、前記ユーザドメインからデータトラフィックを受信し、前記ユーザドメインから受信したデータトラフィックを転送し、
    前記集合ユニットは、前記アクセスドメイン上で存在するサービスバインディングに関する情報を格納し、
    前記情報は、それぞれのサービスバインディングに対し、前記アクセスドメイン上で、サービスプロバイダドメインに対応する仮想ローカルエリアネットワークの属性を持つユーザドメインの属性と、前記サービスバインディングの識別とを含み、
    前記制御ユニットは、１つの前記ユーザドメインからデータトラフィックを受信したときに、そのデータトラフィックが１つの存在する前記サービスバインディングに対応するかどうかを、前記集合ユニット内のユーザドメイン属性と比較することによって決定し、
    もし、前記ユーザドメイン属性が１つの存在する前記サービスバインディングに対応すれば、対応する前記サービスバインディングに従って、前記アクセスドメイン上で受信したそのデータトラフィックを集合することを、前記入出力ユニットに情報伝達することを特徴とする、
    アクセスドメイン上でデータトラフィックを集合するアクセスノード。
14. いくつかの前記サービスバインディングが、イーサネットユニキャストサービスバインディングに対応することを特徴とする、請求項１３に記載のアクセスノード。
15. 前記入出力ユニットが、さらに、ユーザドメイン入出力ユニットとアクセスドメイン入出力ユニットから構成されており、
    前記ユーザドメイン入出力ユニットは、前記ユーザドメインからデータトラフィックを受信し、
    前記アクセスドメイン入出力ユニットは、前記アクセスドメイン上で前記ユーザドメインから受信したデータトラフィックを転送する
    ことを特徴とする、請求項１３に記載のアクセスノード。
16. 前記アクセスドメイン入出力ユニットが、イーサネットベースの入出力ユニットであることを特徴とする、請求項１５に記載のアクセスノード。
17. 前記アクセスドメイン入出力ユニットが、ＩＰネットワーク入出力ユニットであることを特徴とする、請求項１５に記載のアクセスノード。
18. 少なくとも１つの仮想ローカルエリアネットワークが、マルチプロトコルラベルスイッチングの確保された経路に対応することを特徴とする、請求項１４に記載のアクセスノード。