JP4030968B2 - 多重化のためのパケット・データ・フローの識別 - Google Patents

Description

本発明は、複数のパケット・データ・フローを単一の集合体フローに多重化する処理を対象とする。より詳細には、本出願は、単一の結合フローへの集約に好適な個別フローの識別を提供する。

リアルタイム・トランスポート・プロトコル（ＲＴＰ）フローを単一の集合体フローに含めるパケット・データ・フローの多重化の概念は、インターネット技術標準化委員会（ＩＥＴＦ）による、いくつかのインターネットに関する草案で扱われている概念である。ワイド・エリア・ネットワーク（ＷＡＮ）リンクの帯域幅の使用を削減させ、エッジ・ルータにおけるＲＴＰパケット・レートの事故を減らすことができるので、ＲＴＰフローの多重化が望まれる。さらに、ＲＴＰフローの多重化によって、たとえばサービス品質レベルの構成に関して、ネットワークを管理する負担が削減される。さらに、ＲＴＰフローを多重化することによって、既存のサービス品質方式の拡張性を高めることができる。

集合体フローのパケット形式、ヘッダ圧縮アルゴリズム、およびパケット紛失の補償を規定するＩＥＴＦのインターネット草案が提案されているが、どのＲＴＰフローを単一のフローに集約するかをマルチプレクサに信号で伝える方法が話し合われていない。マルチプレクサが、個別ＲＴＰフローを調べてどのパケットが集約の対象であるか判定することができたとしても、そうするにはマルチプレクサにかなりの負担がかかることになる。具体的には、このようなシステムにおけるＲＴＰマルチプレクサは、個別パケットの宛先アドレスを調べて、その宛先アドレスが、個別フローまたは個別パケットへの集約解除用の別の多重化装置に移送するために他のパケットと集約することができるかどうか判定する必要があるであろう。さらに、個別パケットの宛先アドレスを検討して集約が有益であるか判定するようマルチプレクサに要求することにより、データ・ストリームにいっそうの遅延がもたらされる。遅延が増すことは、インターネット・プロトコル上の音声通信（ＶｏＩＰ）セッションに関して特に望ましくなく、遅延を軽減しまたは回避するために高価なハードウェアを多重化装置に追加する必要があり得る。さらに、集約されるべきフローに関する明示的な情報がマルチプレクサに提供されない場合、どのフローが集約されるかということに関する不確定性がシステムにもたらされる。こうした不確定性は遅れの原因となる場合があり、多重化装置は、届くことのない、期待されるパケットを待つ。

本発明は、こうしたならびに他の課題、および従来技術の欠点を解決することを対象とする。

全般的には、本発明によると、識別子が、関連するマルチプレクサを有する遠隔サブネットワークに割り当てられる。割り当てられた識別子は、通信装置と、第１のサブネットワークに関連するマルチプレクサとに伝達される。識別子が割り当てられた遠隔サブネットワークに関連するエンドポイントにアドレス指定された、第１のサブネットワーク上の通信装置から発信されたパケットは、その識別子に関連づけられ、第１のサブネットワーク上のマルチプレクサに提供される。マルチプレクサは次いで、個別通信ストリームの一部であり同じ識別子に関連づけられたパケットをバンドル化（ｂｕｎｄｌｅ）しまたは集約（ａｇｇｒｅｇａｔｅ）して、スーパー・パケットまたは集合体ストリームを形成する。集合体ストリームは次いで、遠隔サブネットワークに関連する第２のマルチプレクサに渡される。第２のマルチプレクサで、集合体ストリームは非バンドル化（ｕｎｂｕｎｄｌｅ）され、個別ストリームに関連づけられたパケットは、適切なエンドポイントまたは宛先通信装置に渡される。

本発明の実施形態によると、識別子は、先在フィールドを用いて個別データ・パケットまたはデータ・ストリームに関連づけられる。たとえば、同じ物理ＬＡＮ上の仮想ローカル・エリア・ネットワーク（ＬＡＮ）同士を区別する目的で一般に使用され、メディア・アクセス制御（ＭＡＣ）ヘッダ中にある仮想ローカル・エリア・ネットワーク（ＶＬＡＮ）フィールドは、遠隔サブネットワーク上のマルチプレクサを識別するのに使用される。本発明の別の実施形態によると、サービス要件のタイプを定義するのに通常使用される区別化サービス・フィールド（ＤＳ）は、識別子を伝達するのに使用される。このフィールドは、サービス・フィールドのタイプ（ＴＯＳ）としても知られ、インターネット・プロトコル（ＩＰ）ヘッダ中にある。本発明のさらに別の実施形態によると、ルータ上の資源を予約してＷＡＮリンク上でのＶｏＩＰコールのベアラ・チャネルのために適切なサービス品質を確保するのに一般に使用される資源予約プロトコル（ＲＳＶＰ）フィールドは、識別子を伝達するのに使用される。本発明のさらに別の実施形態によると、ＲＳＶＰ ＤＣＬＡＳＳオブジェクトは、区別化サービス・フィールド中に配置された区別化サービス・コード・ポイント（ＤＳＣＰ）を伝達するのに使用され、結合フローに集約することができる個別フローを識別するのに使用される。本発明のさらに別の実施形態によると、集約することができる個別フローは、フローを集約することができるか判定するために交渉中のチャネルのパラメータを識別するセッション開始プロトコル（ＳＩＰ）またはＨ．３２３信号に関連づけられた情報を用いて識別される。

本発明の実施形態によると、マルチプレクサをサブネットワーク・ルータの一部としてまたはそれと協同して提供するシステムが提供される。さらに、識別子を遠隔サブネットワークに割り当てるために、制御ユニットを提供することができる。本発明によるシステムはまた、遠隔または第２のサブネットワークに関連する第２のエッジ・ルータに関連づけられたまたはその一部として実装された第２のマルチプレクサを含むことができる。第１および第２のエッジ・ルータは、インターネットなどのワイド・エリア・ネットワーク（ＷＡＮ）によって、相互接続することができる。

本発明のこうしたならびに他の利点および特徴は、以下の説明を特に添付の図面と併せ見るとよりいっそう明らかになるであろう。

本発明は、結合フローへの集約に好適なデータ・パケットの識別を対象とする。
図１では、本発明の実施形態による通信システム１００を示してある。一般に、通信システム１００は、第１のサブネットワーク１０４および第２のまたは遠隔サブネットワーク１０８を備える。第１のサブネットワーク１０４は、通信ネットワーク１１２によって第２のサブネットワーク１０８に相互接続される。通信ネットワーク１１２は一般に、パケット・データ・ネットワークまたはパケット・データと交換回路ネットワークとの組合せを備える。一例として、通信ネットワーク１１２は、インターネット、イントラネット、あるいは１つまたは複数のイントラネットとインターネットとの組合せを備えることができる。

第１のサブネットワーク１０４は一般に、複数の通信装置１１６を備える。通信装置１１６はそれぞれ、マルチプレクサ１２０に相互接続される。制御ユニット１２４は、通信装置１１６とマルチプレクサ１２０の間の活動を調整するために提供することができる。第１のサブネットワーク１０４はさらに、第１のサブネットワーク１０４を通信ネットワーク１１２に相互接続するエッジ・ルータ１２８を備える。

第１のサブネットワーク１０４と同様に、第２のサブネットワーク１０８は、複数の通信装置１３２、マルチプレクサ１３６、制御１４０、およびエッジ・ルータ１４４を備えることができる。

本発明の実施形態によると、サブネットワーク１０４、１０８は、ローカル・エリア・ネットワーク（ＬＡＮ）を備えることができる。したがって、一方または両方のサブネットワーク１０４、１０８は、イーサネット（登録商標）のネットワークとして実装することができる。

システム１００に関連する通信装置１１６、１３２は、通信ネットワークまたはサブネットワークを介してパケット・データを送信するのに適したどのような装置も含むことができる。したがって、通信装置１１６、１３２は、インターネット・プロトコルによる電話、汎用コンピュータ、携帯情報端末（ＰＤＡ）、またはリアルタイムに起こる通信などのメディア通信と共に機能するよう構成された他の計算装置を備えることができる。マルチプレクサ１２０、１３６は一般に、データ・パケットを含むスーパー・パケットを有するバンドル化されたストリームに、メディア・ストリームまたはデータ・ストリームを集約するよう機能する。こうしたデータ・パケットは、第１のサブネットワーク１０４に関連するいくつかの通信装置（たとえば、通信装置１１６）から発信することができ、遠隔サブネットワーク１０８に関連する１つまたは複数の通信装置（たとえば、通信装置１３２）にアドレス指定される。集約されたデータ・ストリームの受信と共に、マルチプレクサ（たとえば、第２のマルチプレクサ１３６）は、集約されたストリームを非バンドル化して受信側通信装置１３２への個別ストリームの引渡しを可能にする。上述の機能は一般に、第２のサブネットワーク１０８に関連する通信装置１３２で発信されまたはそれを介して第１のサブネットワーク１０４に関連する通信装置１１６に伝送されるデータ・パケットに関しては逆になることが理解できよう。本発明の実施形態によると、マルチプレクサ１２０、１３６は、バンドル化機能および非バンドル化機能を実装するソフトウェアを実行する汎用またはサーバ・コンピュータとして実装される。代替実施形態では、マルチプレクサ１２０、１３６を実装するソフトウェア命令の代わりにまたはそれと組み合わせて、配線接続回路を使用することができる。本発明の別の実施形態によると、マルチプレクサ１２０、１３６は、エッジ・ルータ１２８または１４４それぞれの一部として実装することができる。さらに別の実施形態では、マルチプレクサ１２０、１３６は、適切な専用ハードウェアを利用する専用装置として実装し、必要な場合は、他のＶｏＩＰ装置のデータ・ストリーム（たとえば、ＲＴＰストリーム）に透過アクセスを提供するために、そうした装置のためのネットワーク・ゲートウェイとして構成することができる。

制御１２４、１４０は一般に、通信装置１１６、１３２と関連するマルチプレクサ１２０または１３６との間の活動を調整するよう機能する。たとえば、第１の制御１２４は、第１のサブネットワーク１０４に関連する通信装置１１６で発信されまたはそれを介して第２のサブネットワーク１０８に関連する通信装置１３２にアドレス指定されるパケットに関して使用するための識別子を割り当てることができる。制御１２４、１４０は、汎用コンピュータとして実装することができる。本発明のさらに別の実施形態によると、各制御１２４、１４０は、対応するマルチプレクサ１２０、１３６および／またはエッジ・ルータ１２８、１４４の一部として実装することができる。

エッジ・ルータ１２８、１４４は一般に、通信ネットワーク１１２へのサブネットワーク１０４または１０８それぞれと相互接続するよう機能する。さらに、本発明の実施形態によるエッジ・ルータ１２８、１４４は、サブネットワーク１０４、１０８それぞれのマルチプレクサ１２０、１３６および／または制御１２４、１４０を組み込むことができる。

ここで図２を参照すると、本発明の実施形態によって伝送されるデータ・パケットの合成を示してある。一般に、通信装置１１６、１３２はそれぞれ、さまざまなフィールドを含むデータ・パケットを送信（または受信）することができる。具体的には、データ・パケットまたは個別データ・ストリーム２０４はそれぞれ、さまざまなヘッダ情報フィールド２０８、たとえばメディア・アクセス制御、インターネット・プロトコル、ユニバーサル・データグラム・プロトコル（ＵＤＰ）、リアルタイム・トランスポート・プロトコル（ＲＴＰ）、およびメディア・アクセス制御による巡回冗長検査（ＭＡＣ ＣＲＣ）の各フィールドを含む。さらに、データ・パケット２０４はそれぞれ、一般にペイロード２１２、たとえばＧ．７２９ペイロードを含む。さらに、本発明によると、データ・パケット２０４はそれぞれ、宛先サブネットワークＩｄ２１６を含む。以下で詳細に説明するように、宛先サブネットワークＩｄ２１６は、フィールドのうちの別のもの、たとえばヘッダ情報フィールド２０８のいずれかなどの中に含むことができる。個別のデータ・パケット２０４は、サブネットワーク１０４、１０８に関連するマルチプレクサ１２０、１３６に提供（またはそこから受信）される。

マルチプレクサ１２０、１３６は、個別のデータ・パケット２０４を１つまたは複数のスーパー・パケットまたは集合体データ・ストリーム２２０に集約する。図２を見るとわかるように、スーパー・パケット２２０は、それ自体のヘッダ情報を含む。さらに、スーパー・パケット２２０は、個別のデータ・パケット２０４からのヘッダ情報２０８およびペイロード２１２を含む。スーパー・パケット２２０は、エッジ・ルータ１２８、１３６に提供（またはそこから受信）される。

一般に、個別のデータ・パケット２０４をスーパー・パケット２２０に集約することにより、エッジ・ルータ１２８、１３６への負担が減ることが当業者には理解されよう。具体的には、複数の個別パケット２０４をより少ない数のスーパー・パケット２２０に集約することによって、エッジ・ルータ１２８、１３６によって経路指定されなければならない個別パケットの数が削減される。さらに、一般にルータの効率的な帯域幅を限定するのは、ルータのインターフェース１２８、１３６の帯域幅ではなく、ルータ１２８、１３６のデータ・パケットを分類し経路指定する性能なので、本発明は、多数の小型パケットを有するデータ・ストリームを搬送するネットワークまたはサブネットワーク１０４、１０８のデータ伝送能力を向上させることができる。

ここで図３を参照すると、本発明の実施形態によるシステム１００の動作を示すフロー図を示してある。はじめに、ステップ３００で、識別子２１６が遠隔サブネットワーク１０８に割り当てられる。ステップ３０４ａで、遠隔サブネットワーク１０８上の第１の通信装置１３２ａにアドレス指定された音声データが、第１のサブネットワーク１０４上の第１の通信装置１１６ａで受信される。同様に、ステップ３０４ｂで、遠隔サブネットワーク１０８上の第２の通信装置１３２ｂにアドレス指定された音声データが、第１のサブネットワーク１０４上の第２の通信装置１１６ｂで受信される。さらに、遠隔サブネットワーク１０８上の第ｎの通信装置１３２ｎにアドレス指定された音声データは、第ｎの通信装置１１６ｎで受信することができる（ステップ３０４ｎ）。ステップ３０８ａ〜３０８ｎで、受信データは、通信装置１１６ａ〜１１６ｎそれぞれによってパケット化される。ステップ３１２ａ〜３１２ｎで、遠隔サブネットワーク１０８に割り当てられた識別子２１６は、通信装置１１６ａ〜１１６ｎのそれぞれによって、パケット化されたデータに関連づけられ、通信装置１１６ａ〜１１６ｎは、そのデータ・パケット２０４をマルチプレクサ１２０に送る。

ステップ３１６で、第１のサブネットワーク１０４上のマルチプレクサ１２０は、同じ識別子２１６に関連づけられたパケット２０４を１つまたは複数のスーパー・パケットまたはスーパー・フロー２２０とバンドル化し、それを通信ネットワーク１１２を介して遠隔サブネットワーク１０８に送る。通信装置１１６ａ〜１１６ｎから単一のスーパー・パケット２２０として受信されたさまざまなデータ・パケット２０４を送ることによって、通信ネットワーク１１２に関連するエッジ・ルータ１２８、１４４とスイッチおよびルータとにかかる処理負荷が減少することが当業者には理解されよう。たとえば、図３に示した例では、３つの個別パケット２０４ではなく、単一のスーパー・パケットに関連づけられたヘッダ情報のみがルータおよびスイッチによって検討されなければならない。

ステップ３２０で、遠隔サブネットワーク１０８上のマルチプレクサ１３６は、スーパー・パケット２２０を受信し、集合体フローを非バンドル化して、個別フロー（すなわち、個別パケット２０４）を宛先通信装置１３２ａ〜１３２ｎに送る。ステップ３２４ａ〜３２４ｎで、パケット化された音声データは、遠隔サブネットワーク１０８上の適切な通信装置１３２ａ〜１３２ｎで受信される。

ここで図４を参照すると、本発明の実施形態によるシステム１００の動作を示すフロー図を示してある。一般に、図４に関連して示す実施形態では、サブネットワーク１０４または１０８を介して伝送されるデータ・パケット２０４に関連して提供される、仮想ローカル・エリア・ネットワーク（ＶＬＡＮ）識別フィールドを使用して、遠隔サブネットワーク１０８のマルチプレクサ１３６に個別パケット２０４を関連づけまたはそれを識別する。より詳細には、ＭＡＣヘッダ中のＶＬＡＮ Ｉｄフィールドが、データ・パケット２０４を、本発明によるマルチプレクサ１３６を有する遠隔サブネットワーク１０８に関連する通信装置１３２にアドレス指定されていると識別するのに使われる。さらに、割り当てられたＶＬＡＮ Ｉｄは、第１のサブネットワーク１０４または第２のサブネットワーク１０８と共に確立された有効な仮想ローカル・エリア・ネットワークに対応しないように選択されることが理解できよう。

はじめに、ステップ４００で、ＶＬＡＮ Ｉｄが遠隔サブネットワーク１０８に関連して割り当てられる。具体的には、第１の制御１２４は、本発明によるマルチプレクサ１３６を有する遠隔サブネットワーク１０８を識別するＶＬＡＮ Ｉｄを選択するよう機能することができる。さらに、制御１２４は、割り当てられた識別子を第１のサブネットワーク１０４上の通信装置１１６のそれぞれに伝達し、そうすることによって通信装置１１６は、遠隔サブネットワーク１０８上の通信装置１３２にアドレス指定されたデータ・パケット２０４を有しているときに識別子を使用できるようになる。

ステップ４０４で、第１のマルチプレクサ１２０は、遠隔サブネットワーク１０８上の通信装置１３２にアドレス指定されるとともに遠隔サブネットワーク１０８に関連づけられたＶＬＡＮ Ｉｄを割り当てられて印をつけられたデータ・パケット２０４を受信する。マルチプレクサ１２０は、同じＶＬＡＮ Ｉｄを有するパケット２０４を１つまたは複数のスーパー・パケット２２０に集約する（ステップ４０８）。

第１のマルチプレクサ１２０は次いで、スーパー・パケット２２０を遠隔サブネットワーク１０８上の第２のマルチプレクサ１３６に送信する（ステップ４１２）。第２のマルチプレクサ１３６は、スーパー・パケット２２０を集約解除し、個別パケット２０４を個別ストリームとして遠隔サブネットワーク１０８上の適切な通信装置１３２に送信する（ステップ４１６）。

図４に関する本明細書での説明から理解できるように、送信マルチプレクサ１２０は、個別パケット２０４の宛先アドレスから、パケット２０４がスーパー・パケット２２０への集約に適したものであるかどうか検討する必要はない。そうではなく、マルチプレクサ１２０は、各パケット２０４中の比較的短いＶＬＡＮ Ｉｄフィールドを検討して、そのフィールドが遠隔サブネットワーク１０８上の第２のマルチプレクサ１３６に関連づけられた識別子を含むかどうか判定することだけが必要である。さらに、図４に関連する説明に従う実施形態では、新しいデータ・パケット２０４の情報またはヘッダ・フィールドの定義は必要ないことが理解できよう。そうではなく、先在フィールドが利用される。スーパー・パケット２２０は第２のマルチプレクサ１３６に関連づけられたアドレスに送信されることも理解できよう。第２のマルチプレクサ１３６は、それに直接アドレス指定されたスーパー・パケット２２０を受信すると、次いで、スーパー・パケット２２０の個別データ・ストリーム２０４を非バンドル化し、個別パケット２０４を上述のように引渡しする。

ここで図５を参照すると、本発明の別の実施形態によるシステム１００の動作を示してある。一般に、図５に示す実施形態では、本発明によるマルチプレクサ１３６を有する遠隔サブネットワーク１０８上の通信装置１３２にアドレス指定される個別データ・ストリーム２０４を識別するために、ＩＰヘッダ中の区別化サービス・フィールド（ＤＳ）またはサービス・タイプ（ＴＯＳ）フィールドを使用する。

ステップ５０４で、Ｄｉｆｆｓｅｒｖコード・ポイント（ＤＳＣＰ）が遠隔サブネットワーク１０８に割り当てられる。ステップ５０８で、第１のマルチプレクサ１２０は、遠隔サブネットワーク１０８上の通信装置１３２にアドレス指定されるとともにその遠隔サブネットワーク１０８に割り当てられたＤＳＣＰを有するとの印がつけられたデータ・パケット２０４を受信する。第１のマルチプレクサ１２０は次いで、共通のＤＳＣＰを有する個別データ・パケットまたは個別フロー２０４を、第２のマルチプレクサ１３６にアドレス指定された１つまたは複数のスーパー・パケットまたは集合体フロー２２０に集約する（ステップ５１２）。スーパー・パケット２２０は次いで、遠隔サブネットワーク１０８上の第２のマルチプレクサ１３６に送信される（ステップ５１６）。遠隔サブネットワーク１０８上のマルチプレクサ１３６は、スーパー・パケット２２０を集約解除し、個別データ・ストリームを含む個別パケット２０４を遠隔サブネットワーク１０８上の適切な通信装置１３２に送信する（ステップ５２０）。

図５に関連する本明細書における説明から、ＤＳフィールドを利用する実施形態によって、マルチプレクサ１２０は、このようなデータ・パケットに関連づけられた比較的短いＤＳＣＰフィールドを検討するだけで、スーパー・パケット２２０への集約に適したデータ・パケット２０４を識別できるようになることが理解できよう。マルチプレクサ１２０は、遠隔サブネットワーク１０８に割り当てられているＤＳＣＰに関連づけられた複数のデータ・パケット２０４を識別すると、個別パケット２０４をバンドル化し、得られるスーパー・パケット２２０を遠隔サブネットワーク１０８に関連するマルチプレクサ１３６にアドレス指定する。マルチプレクサは、通信ネットワークのＷＡＮ部分に要求されるホップごとの動作を指定するために、適切なＤＳＣＰ値をスーパー・パケットのＤＳフィールドに配置することができる。

ここで図６を参照すると、本発明のさらに別の実施形態によるシステム１００の動作を示してある。一般に、図６を参照して説明する実施形態では、どのＲＴＰデータ・フローが期待され得るか判定するために、資源予約プロトコル（ＲＳＶＰ）を使用して、個別データ・パケット２０４に関連づけられた発信ならびに宛先アドレス、およびポートを識別する。このようなフローの一部であり同じサブネットワーク１０８上の通信装置１３２にアドレス指定される個別データ・パケット２０４は次いで、１つまたは複数のスーパー・パケット２２０に集約される。

このような実施形態の動作の一例として、ＲＳＶＰが可能なＶＯＩＰ通信装置１１６が、第１のサブネットワーク１０４上の第１のマルチプレクサ１２０をそのデフォルトのＩＰゲートウェイとして使うように構成される（ステップ６００）。ステップ６０４で、インターネット・プロトコル上の音声通信セッションまたは他の通信セッションが開始される。ステップ６０８で、ＲＴＰストリームに対してある特定のサービス品質を提供するＲＳＶＰ要求（ＰＡＴＨメッセージ）が、通信装置１１６によってマルチプレクサ１２０に送信される。

マルチプレクサ１２０は、通信装置１１６から受信されるであろう個別フローまたはＲＴＰストリームの宛先を判定し、そのフローを新しいまたは既存の集合体フローに割り当てる（ステップ６１２）。ステップ６１６で、通信装置１１６への戻り予約メッセージ（ＲＥＳＶメッセージ）がマルチプレクサ１２０によってエミュレートされ、通信装置１１６に渡される。通信装置１１６は次いで、個別パケット２０４をマルチプレクサ１２０に送信する。個別パケット２０４はマルチプレクサ１２０で受信され、スーパー・パケット２２０中に配置されて、マルチプレクサと遠隔マルチプレクサの間で保持される一度のＲＳＶＰ予約の下で遠隔サブネットワーク１０８に渡される（ステップ６２０）。ＲＳＶＰ予約のパラメータは、集合体フローの異なる要件に適応するために変更することができる。スーパー・パケット２２０は、遠隔サブネットワーク１０８に関連するマルチプレクサ１３６で受信され、マルチプレクサはスーパー・パケット２２０を集約解除し、個別パケット２０４を遠隔サブネットワーク１０８上の１つまたは複数の適切な通信装置１３２に送信する（ステップ６２４）。

ＲＳＶＰフィールドを利用する本発明の実施形態によって、マルチプレクサ１２０は、どのＶｏＩＰフローが通信装置１１６から期待されるか知ることが可能になることが、本明細書における説明から理解できよう。ただし、マルチプレクサ１２０は、識別されたフロー中の少なくとも１つの個別パケット２０４の宛先アドレスを調べて、そのフローの宛先アドレスを判定しなければならない。したがって、宛先アドレスは、個別データ・パケット２０４の初期識別子として働く。ＲＳＶＰ情報は次いで、集約に適したパケットを識別するのに使用することができる。ＲＳＶＰ要求の一部として提供された情報はまた、いつ個別フローが開始および終了するか伝達し、そうすることによって、所望のサービス・レベルを保証するために、作成されたスーパー・パケット２２０に関連してどれだけ多くの資源を要求しなければならないかをマルチプレクサ１２０が判定することができる。

図７には、本発明のさらに別の実施形態によるシステム１００の動作を示してある。一般に、図７に示す実施形態では、ＤＳフィールドを使用してフローを識別し、また、個別データ・ストリームに関連して提供されるＲＳＶＰ要求の一部として含まれる情報を使って、集合体ストリームに対する一度のＲＳＶＰ要求を行う。このような実施形態によると、ステップ７００で、ＤＳＣＰが、遠隔サブネットワーク１０８を識別するために割り当てられる。ステップ７０４で、ＲＳＶＰが可能なＶｏＩＰ通信装置１１６が、第１のサブネットワーク１０４上のマルチプレクサ１２０を装置のデフォルトのＩＰゲートウェイとして備えて構成される。次いで、ＶｏＩＰセッションが開始される（ステップ７０８）。

ステップ７１２で、通信装置１１６は、第１のサブネットワーク１０４上のマルチプレクサ１２０にＲＳＶＰ要求を送信する（ステップ７１２）。マルチプレクサ１２０は次いで、ＲＳＶＰ要求に関連づけられたフロー２０４を新しいまたは既存の集合体フロー２２０中の位置に割り当てる（ステップ７１６）。

ステップ７２０で、マルチプレクサ１２０は、集合体フロー２２０に対してＲＳＶＰ予約を要求する。マルチプレクサ１２０は、戻りＲＳＶＰメッセージを受信し、正しい予約メッセージをエミュレートして通信装置１１６に戻し、割り当てられたＤＳＣＰを含むＤＣＬＡＳＳオブジェクトを挿入する（ステップ７２４）。

通信装置１１６は次いで、割り当てられたＤＳＣＰで個別パケットに印をつけ、そのパケット２０４をマルチプレクサ１２０に送信する（ステップ７２８）。マルチプレクサ１２０は、共通のＤＳＣＰを有するパケット２０４を１つまたは複数のスーパー・パケット２２０に集約し、一度のＲＳＶＰ予約の下でスーパー・パケット２２０を遠隔サブネットワーク１０８に渡す（ステップ７３２）。スーパー・パケット２２０は、遠隔サブネットワーク１０８上の第２のマルチプレクサ１３６で受信され、マルチプレクサは、スーパー・パケット２２０を集約解除し、その個別パケット２０４を遠隔サブネットワーク１０８上の適切な通信装置１３２に送信する（ステップ７３６）。

上記の説明から、マルチプレクサ１２０は、個別データ・パケット２０４がスーパー・パケット２２０への集約に適しているかどうか判定するために、ＤＳフィールドを検討しさえすればよいことが理解できよう。さらに、図７に関連して説明した実施形態によって、スーパー・パケット２２０に関して一度のＲＳＶＰ予約が確立されることが可能になる。したがって、個別データ・パケット２２０のそれぞれに対して別々のＲＳＶＰ予約を確立する必要なく、所望のサービス・レベルを維持することができる。

ここで図８を参照すると、本発明の別の実施形態によるシステム１００の動作を示してある。はじめに、ステップ８００で、ＲＴＰフローに関連づけられたパケットが第１のマルチプレクサ１２０で受信される。第１のマルチプレクサ１２０は、受信済みパケットに関連づけられたメディア・チャネルを開始するのに使われる、セッション開始プロトコル（ＳＩＰ）やＨ．３２３など、どの電話信号プロトコルに従って定義されたセットアップ・パケットも調べる（ステップ８０４）。たとえば、セッション開始プロトコルを利用するフローに関連して、交渉中のチャネルのパラメータを判定するためにＩＮＶＩＴＥおよびＡＣＫパケットが調べられる。マルチプレクサ１２０は次いで、共通の遠隔サブネットワークにアドレス指定された個別パケット２０４を１つまたは複数のスーパー・パケット２２０に集約する（ステップ８０８）。スーパー・パケット２２０は次いで、遠隔サブネットワーク１０８に渡される（ステップ８１２）。遠隔サブネットワーク１０８に関連するマルチプレクサ１３６は次いで、スーパー・パケット２２０を集約解除し、個別パケット２０４を遠隔サブネットワーク１０８上の適切な通信装置１３２に送信する（ステップ８１６）。図８に関連して説明した実施形態によって、ルータ１２８、１４４は、スーパー・パケット２２０への集約に適した個別フロー２０４を識別することが可能になり、また、この実施形態では、使用される特定の電話信号プロトコルに従って、リアルタイム・トランスポート・プロトコルのフローの開始および終了を明示的に信号で知らせる。

本発明のさまざまな実施形態に関する上記の説明では、概して、インターネット・プロトコル上の音声通信または他のリアルタイム転送プロトコルに従った音声データの伝送を例として用いたが、本発明がそのように限定されないことを理解されたい。具体的には、本発明は、パケット・データ・ネットワークを介したどのデータ伝送に関しても適用することができる。

以上、本発明を、例示および説明の目的で述べた。さらに、上記の説明は、本発明を本明細書で開示した形に限定することを意図するものではない。したがって、変形形態および変更形態は、関連分野の技術および知識の範囲において上述の教示に等しく、本発明の範囲内である。本明細書で説明した実施形態はさらに、本発明を実施するのに現在知られている最良の方式を説明すること、および本発明の特定の適用または使用に必要なさまざまな変更を伴うこのようなまたは他の実施形態において当業者が本発明を利用することを可能にすることを意図したものである。添付の特許請求の範囲は、代替実施形態を従来技術によって許容される範囲まで含むよう解釈されることを意図したものである。

本発明の一実施形態による通信システムを示すブロック図である。 本発明の一実施形態によるサブネットワークを介するパケット・フローを示す図である。 本発明の一実施形態によるデータ・パケットの集約を示すフロー図である。 本発明の一実施形態による、集約に適したパケットの識別を示すフロー図である。 本発明の別の実施形態による、集約に適したパケットの識別を示すフロー図である。 本発明の別の実施形態による、集約に適したパケットの識別を示すフロー図である。 本発明の別の実施形態による、集約に適したパケットの識別を示すフロー図である。 本発明の別の実施形態による、集約に適したパケットの識別を示すフロー図である。

Claims (31)

1. パケット・データ伝送を多重化する方法であって、
   第１のネットワーク要素に識別子を割り当てる工程であって、前記識別子は前記第１のネットワーク要素のインターネット・プロトコル・アドレスではない、割り当てる工程と、
   少なくとも第２のネットワーク要素において、複数のデータ・パケットを集約するために、前記識別子を前記複数のデータ・パケットに関連づける工程と、
   少なくとも第３のネットワーク要素において、前記複数のデータ・パケットについて前記識別子を認識する工程と、
   前記第３のネットワーク要素において、前記複数のデータ・パケットを少なくとも第１のスーパー・パケットに集約する工程と、
   前記データ・パケットをバンドル化したものを前記第１のネットワーク要素にアドレス指定する工程とを含む方法。
2. 前記第３のネットワーク要素がパケット・データ・マルチプレクサを含む、請求項１に記載の方法。
3. 前記パケット・データ・マルチプレクサがルータを含む、請求項２に記載の方法。
4. 前記複数のデータ・パケットを集約解除する工程と、
   第１の前記複数のデータ・パケットを第１の受信側通信装置に渡す工程と、
   第２の前記複数のデータ・パケットを第２の受信側通信装置に渡す工程とをさらに含む、請求項２に記載の方法。
5. 前記識別子が、前記識別子を伝達すること以外の目的で少なくとも第１のプロトコルに関連して確立されたフィールドを用いて伝達される、請求項１に記載の方法。
6. 前記識別子が仮想ローカル・エリア・ネットワーク識別子を含む、請求項１に記載の方法。
7. 前記識別子を前記データ・パケットに対するメディア・アクセス制御の一部として書き込むことによって、前記仮想ローカル・エリア・ネットワーク識別子が前記データ・パケットに関連づけられる、請求項６に記載の方法。
8. 前記識別子がＤｉｆｆＳｅｒｖコード・ポイントを含む、請求項１に記載の方法。
9. 前記識別子が資源予約プロトコル要求を含む、請求項１に記載の方法。
10. 複数のデータ・パケットを前記識別子に関連づける前記工程が、前記識別子を第１の発信側通信装置内の第１のデータ・パケットに関連づける工程と、前記識別子を第２の発信側通信装置内の第２のデータ・パケットに関連づける工程とを含む、請求項１に記載の方法。
11. パケット・データ伝送を多重化するシステムであって、
    データ・パケットを形成し、既存データ・フィールドを用いて前記データ・パケットに識別子で印をつける少なくとも第１の通信装置手段であって、前記既存データ・フィールドはインターネット・プロトコル・アドレス・フィールドではない、第１の通信装置手段と、
    第１および第２のデータ・パケットが前記識別子に関連づけられたことを認識することに応答して、前記識別子に関連づけられた前記第１および第２のデータ・パケットをスーパー・パケットに集約する第１の手段と、
    遠隔サブネットワークを前記識別子に関連づける手段と
    前記集約する第１の手段を通信ネットワークに相互接続する手段であって、前記スーパー・パケットを前記遠隔サブネットワークに伝送することができる手段とを備えるシステム。
12. 前記既存データ・フィールドが、仮想ローカル・エリア・ネットワーク識別子フィールド、サービスフィールドの一種、ＤｉｆｆＳｅｒｖコード・ポイントフィールド、資源予約プロトコルのＤＣＬＡＳＳオブジェクト・フィールド、及びセッション開始プロトコルフィールドを有する、請求項１１に記載のシステム。
13. 前記スーパー・パケットを集約解除する手段をさらに備える、請求項１１に記載のシステム。
14. 複数のデータ・パケットを集約するために第１の識別子で印がつけられ、前記第１の識別子以外の宛先アドレスを含む前記複数のデータ・パケットが受信されるインターフェースと、
    前記複数のデータ・パケットが、スーパー・パケットに集約されて引渡しのために前記インターフェースに提供されるプロセッサと、
    前記インターフェースが、第１の通信ネットワークからの入力と、
    ルータおよび第２の通信ネットワークの少なくとも１つへの出力とを備え、
    前記第２の通信ネットワークと前記第１の識別子が関連付けられていることを特徴とするデータ・マルチプレクサ。
15. データ記憶装置をさらに備える、請求項１４に記載のデータ・マルチプレクサ。
16. アドレス・フィールドに第１の宛先アドレスを、および第２のフィールドに第１の識別子を含む第１のデータ・パケットを受信する工程であって、前記第１の識別子が、第２の宛先アドレスを有する第１のネットワーク要素を識別し、前記第２のフィールドが、ネットワーク要素を識別する識別子を伝送すること以外の目的で、少なくとも第１のネットワーク・プロトコルによって識別される工程と、
    アドレス・フィールドに前記第１の宛先アドレスおよび第２の宛先アドレスの少なくとも１つと、第２のフィールドに前記第１の識別子とを含む第２のデータ・パケットを受信する工程と、
    前記第１および第２のデータ・パケットをペイロードとして含むスーパー・パケットを形成する工程であって、前記スーパー・パケットが前記第２の宛先アドレスをアドレス・フィールドに含む工程とを含む方法を実施する計算機構成要素。
17. 前記第２のフィールドが仮想ローカル・エリア・ネットワーク識別子フィールドを含む、請求項１６に記載の計算機構成要素。
18. 前記第２のフィールドが区別化サービス・コード・ポイント・フィールドを含む、請求項１６に記載の計算機構成要素。
19. 前記第２のフィールドが資源予約プロトコル・フィールドを含む、請求項１６に記載の計算機構成要素。
20. 前記第２のフィールドが資源予約プロトコルのＤＣＬＡＳＳオブジェクト・フィールドを含む、請求項１６に記載の計算機構成要素。
21. 前記第２のフィールドがセッション開始プロトコル・フィールドを含む、請求項１６に記載の計算機構成要素。
22. 前記第１のネットワーク要素が遠隔サブネットワーク上のマルチプレクサを含む、請求項１６に記載の計算機構成要素。
23. 前記第１の宛先アドレスが前記遠隔サブネットワーク上のエンドポイントを含む、請求項２２に記載の計算機構成要素。
24. 前記第１および第２のデータ・パケットがそれぞれ、音声データを有するペイロードを含む、請求項１６に記載の計算機構成要素。
25. 前記計算機構成要素が、前記方法を実施する命令を搬送するコンピュータ可読記憶媒体を備える、請求項１６に記載の計算機構成要素。
26. 多重化するデータ・パケットを識別する方法であって、
    第１のパケット・データ・フロー用の資源を予約する第１の要求を、第１のマルチプレクサで受信する工程と、
    前記要求から、第１の遠隔サブネットワーク上の第２のマルチプレクサに関連する識別子を判定する工程であって、前記識別子は前記第１の遠隔サブネットワークのアドレスとは異なり、前記識別子は既存データ・フィールド内に配置される、判定する工程と、
    第２のパケット・データ・フロー用の資源を予約する第２の要求を、前記第１のマルチプレクサで受信する工程と、
    前記要求から、前記第２のマルチプレクサに関連する前記識別子を判定する工程と、
    前記第１の遠隔サブネットワーク上の宛先にアドレス指定されている前記第１および第２のデータ・パケット・フローに応答して、少なくとも前記第１のデータ・パケット・フローからの第１のデータ・パケットを、前記第２のデータ・パケット・フローからのデータ・パケットと集約して、スーパー・パケットを形成する工程と、
    一度の資源予約の下で、前記スーパー・パケットを前記第１の遠隔サブネットワークに関連する前記第２のマルチプレクサに送信する工程とを含む方法。
27. 資源を予約する前記第１の要求の受信に応答して、前記第１の要求を行う第１の通信装置に第１の識別子を提供する工程であって、前記第１の要求に関連づけられた、前記第１の通信装置からのデータ・パケットが前記第１の識別子で印をつけられる工程をさらに含む、請求項２６に記載の方法。
28. 前記一度の資源予約が第１の量の通信資源を要求する、請求項２６に記載の方法。
29. 第３のパケット・データ・フロー用の資源を予約する第３の要求を前記マルチプレクサで受信する工程であって、前記一度の予約が第２の量の通信資源を要求し、前記第１の量の通信資源が前記第２の量の通信資源とは異なる工程をさらに含む、請求項２８に記載の方法。
30. 多重化するデータ・パケットを識別する方法であって、
    第１のパケット・データ・フローに関連づけられた少なくとも第１のセットアップ・パケットを第１のマルチプレクサで受信する工程と、
    前記少なくとも第１のセットアップ・パケットから、第１の遠隔サブネットワーク上の第２のマルチプレクサに関連する識別子を判定する工程であって、前記識別子は前記第１の遠隔サブネットワークのアドレスとは異なる、判定する工程と、
    第２のパケット・データ・フローに関連する少なくとも第２のセットアップ・パケットを前記第１のマルチプレクサで受信する工程と、
    前記少なくとも第２のセットアップ・パケットから、前記第２のマルチプレクサに関連する前記識別子を判定する工程と、
    前記第１の遠隔サブネットワーク上の宛先にアドレス指定されている前記第１および第２のデータ・パケット・フローに応答して、前記第１のデータ・パケット・フローからの少なくとも第１のデータ・パケットを前記第２のデータ・パケット・フローからのデータ・パケットと集約して、スーパー・パケットを形成する工程と、
    前記スーパー・パケットを前記第１の遠隔サブネットワークに関連する前記第２のマルチプレクサに送信する工程であって、前記第２のマルチプレクサが、前記スーパー・パケットを有する前記集約されたフローを解除する、送信する工程とを含む方法。
31. 前記セットアップ・パケットが、セッション開始プロトコルおよびＨ．３２３プロトコル・パケットの少なくとも１つを含む、請求項３０に記載の方法。

Images