JP4394336B2 - リアルタイム・トランスポート・プロトコル・データフローのフロー品質統計値を求めるシステム及び方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、遠距離通信網に関し、特に、リアルタイム・マルチメディア・フローに関する。
【０００２】
【従来の技術】
公衆交換電話網（ＰＳＴＮ）は、ユーザが、約１０億台の電話のうち１台の受話器を取り上げ、約１０億台のエンドポイントのいずれか１台に電話をかけることのできる効率的なリアルタイムマルチメディア通信セッションツールに発展した。番号計画、スイッチング及びルーティングの分散化、信号方式のネットワーク化等いくつかの開発により、このネットワークの自動化が可能となった。
【０００３】
残念ながら、ＰＳＴＮは今のところ電話番号やその一部を使用して通信のエンドポイントへの経路を見つけるので、ＰＳＴＮにある階層に適合するアドレス以外のものに基づいて、実際の通信セッションをルーティングすることができない。携帯の機構では、通信セッションをネットワークを経由して方向付けるために、仮想のまたは仮の番号を必要とする。
【０００４】
ＰＳＴＮが階層に基づいているのと同様に、インターネットはインターネットプロトコル（ＩＰ）に基づいている。ＩＰメッセージは、１つのリンクから次のリンクへ（すなわち、データフローのソースからデータフローのデスティネーションへ）ルーティング、もしくは転送される。各ＩＰパケットはＩＰアドレスを含む。インターネットプロトコル バージョン４（ＩＰｖ４）では、ＩＰアドレスは３２ビットである。各ＩＰアドレスには、ネットワーク部用の一定数のビットと、ホスト部用の一定数のビットとが含まれる。
【０００５】
ＩＰルータは、１つのネットワーク（またはリンク）からパケットを受取り、別のネットワーク（またはリンク）に送出するために使用される。ＩＰルータには、パケットをルーティングする最良の経路を決定するために使用される情報または基準を含むテーブルが設けられている。この情報の一例として、ネットワークリンク及びプログラムされた距離表示の状態が挙げられる。残念ながら、通常ＩＰルータはデスティネーションＩＰアドレスによってパケットをルーティングするが、これは伝送に適当な経路を見出すのには役に立たない。しかしながら、このルーティングシステムの例外として、ネットワークドメインの両側にインテリジェントな装置を使用することにより、パケットに一時アドレスを割当ててネットワーク経由で送り、パケットがネットワークを離れる際にネットワークの反対側で元のアドレスに戻すことができる。これが、現在の多くの仮想私設網（ＶＰＮ）製品の基本であり、当該技術の中で理解される。
【０００６】
ルーティングシステムの別の例外として、マルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）がある。ＭＰＬＳは、カリフォルニア州サンノゼのシスコシステム株式会社によって開発されたタグスイッチングと呼ばれる技術に基づいている。このＩＰパケットをルーティングする方法によると、パケットが実際ネットワーク上で取る経路とデスティネーションＩＰアドレスとを潜在的に分離することができる。ＭＰＬＳを最大限使用する方法の１つは、ＶＰＮまたは仮想専用回線を生成することである。ＭＰＬＳタグは、ネットワーク上のデータパケットのルーティングを効果的にカプセル化できる。
【０００７】
要するに、結論としては、データ網はＩＰデスティネーションに基づきＩＰパケットの実質転送を行う。また、ＩＰデスティネーションはネットワークトポロジーに関連し、電話網のように、パケットを伝送するために使用される。ＭＰＬＳタグ及び経路は、ルーティングに使用されるＩＰアドレス部に結び付けられたルール、例えばＦＥＣ（転送等価クラス）に基づき、ＩＰパケットのオーバーライド転送を可能とする。
【０００８】
ネットワーク要素（例えば、電話網の切換器、データ網のルータなど）が共同で行うタスクを実行することを保証するため、隣接する通信リンク及び利用可能な経路のステータスを知る必要があり、この情報を提供するために信号方式を用いる。電話網では、通常使用される信号方式はＳＳ７に準拠しているかもしくはＳＳ７相当である。この信号方式は、個々のリンク、リンク装置、経路等についての情報を提供する。データ網では、境界ゲートウェイプロトコル（ＢＧＰ）、内部ゲートウェイプロトコル（ＩＧＰ）、ＯＳＰＦ（ｏｐｅｎ ｓｈｏｒｔｅｓｔ ｐａｔｈ ｆｉｒｓｔ）等のプロトコルを使用して接続状態及び経路を決定する。
【０００９】
電話網では、ネットワーク経由で末端間経路（すなわち、ＩＳＤＮユーザ部（ＩＳＵＰ））を確立する際にも信号方式を用いる。残念ながら、ＩＰネットワークでは、端末間経路の割り当てはない。その代わり、通信セッションに参加するため、エンドポイントを名前や目的に関連付けるシステムが必要である。
【００１０】
現在、インターネット上では世界的な登録機関は知られていない。ドメイン名Ｅ１６４．ｃｏｍの世界的登録機関が、マサチューセッツ州ローウェルのＮｅｔＮｕｍｂｅｒ．ｃｏｍ株式会社によって提案された。この世界的登録機関の開発は、現在は北米番号計画（ＮＡＮＰ）を管理するＮｅｕＳｔａｒ株式会社による提案に基づいている。この提案では、現在のドメインネームサービス（ＤＮＳ）を使用し、ＤＮＳサーバを使用して解決されるような方法で番号をＵＲＬのフォーマットに形成することが必要である。このように、各電話番号は１台のＤＮＳサーバに登録され、他の全てのＤＮＳサーバに配信される。ＤＮＳクエリの末尾はリソースのレコードで、軽量ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）のディレクトリサーバを示す。
【００１１】
ＩＰエンドポイント用のユニバーサル携帯電話（ＵＰＴ）番号を使用し、従来の有線電話番号との重複を避けるというＩＴＵからの提案は効果的であり、ＩＰエンドポイントをアドレス指定可能にする。上記２つの提案を組み合わせてＰＳＴＮから／へのインターネットコールをさせることも可能である。残念ながら、この技術には幾つかの制限がある。これらの制限としては、ＤＮＳの配信と複写には著しい待ち時間が含まれる、ＤＮＳアドレスの解決が遅くなる、ＤＮＳサーバが予定された数のアドレスを扱うことができないことがある、ＤＮＳサーバが重複する項目を管理できない（ただし、ラウンドロビン方式を除く）、ＤＮＳは並列更新機構を採用しており、意図的ではなく重複項目を生じる、私設網アドレスまたはアドレッシングゲートウェイによって重複項目や一致が生じる、要求のあったリソースの管理を扱うポリシーがない、ＰＳＴＮとデータ網との間で重複する番号を扱う方法がない等が挙げられる。
【００１２】
現行のほとんどの電気通信用エンドポイントはＰＳＴＮに基づくシステムを介してサービスを受けるので、パケットデータ網とＰＳＴＮとの間のマルチメディアフローを容易にするためにゲートウェイが使用される。ゲートウェイはデータ網と音声網との間の境界に設置され、マルチメディア（及び、信号）を変換し、通信を確保するために使用される。ゲートウェイで受信した呼を他のゲートウェイにルーティングする当該技術で説明される方法が幾つかある。これらの方法のうちの２つが、フルメッシュルーティングと階層ルーティングである。フルメッシュルーティングはほとんどのソフトスイッチングアーキテクチャで記述される標準的な方法である。セッション・イニシエーション・プロトコル（ＳＩＰ）は、任意点間でのシグナリングモデルをサポートするので、ソフトスイッチ間信号方式である。このモデルでは、呼を成立させるために全てのソフトスイッチが他の全てのソフトスイッチに仮想接続される。ソフトスイッチメーカーにより提供されるポリシーに基づき、トラフィックを１つのソフトスイッチに向けるために使用されるルーティングテーブルが利用される。
【００１３】
残念ながら、多数のソフトスイッチを含むネットワークを運用する場合、ネットワークの所有者は、フルメッシュを維持するためのポリシー管理に多くの相違点がある。このようなポリシー管理問題には、各ソフトスイッチが他の各ソフトスイッチのＩＰアドレス、及び接続する電話番号もしくはＰＳＴＮを認識していることを保証することが含まれる。複数のベンダからのソフトスイッチを運用する場合、さらなる管理問題が生じる。実際には様々なリンクを介して設備が管理されることから、管理問題はさらに複雑になる。
【００１４】
配置されるソフトスイッチの数が多くなると、様々な経路のシェアリングを生じやすい。フルメッシュのルーティング構成においては、異なる出口ソフトスイッチが満杯であるか機能していないものもあるので、呼のルーティングが難しい。例えば、回線業者が国内長距離を扱える３０個のソフトスイッチを有していて、ネットワークが約５０％で稼動しているとすると、各発信元のソフトスイッチは、塞がっていない経路のソフトスイッチを見つけるまでにおそらく平均１５の別々のソフトスイッチを試さなければならない。もし、純粋なランダム分布が実施されるのであれば、この検索の労力は非常に軽減される。しかしながら、コストや品質から他の経路よりも好ましい経路もあることが考えられ、問題を悪化させる。
【００１５】
限定はしないが、例えば、Ｃｉｓｃｏ ＡＳ５３００のなどのある種の単純なゲートウェイは、ＳＩＰプロキシサーバにＳＩＰに基づく呼び出し要求を転送できる。残念ながら、これらのゲートウェイは性能が低く、ルーティングポリシをセットアップするのに、ソフトスイッチの精巧さを欠くことがよくある。したがって、ソフトスイッチ制御装置を用いずに、これらのルータを相互に接続してネットワークを生成することはできない。
【００１６】
したがって、各種ＩＰネットワーク間に高品質な境界を生成するために一般的に必要とされることだが、リアルタイムパケットフローをある種のしきい値により案内することが大切である。適切に案内しないと、パケットはネットワークが許可するどの経路でも流れ、それにより、パケットを上流及び下流の障害だけでなく破壊された経路に通すことになる。
【００１７】
【課題を解決するための手段】
上記を鑑みて、本発明の好ましい実施形態は、概して、ＲＴＰ（リアルタイム・トランスポート・プロトコル）データフローについてフロー品質の統計値を求めるシステムと方法とに関する。
【００１８】
概して、本システムの構造を参照すると、本システムは第２のエンドポイントに接続された第１のエンドポイントを利用し、第１のエンドポイントは、送受信器と、第１のエンドポイント内に格納され、第１のエンドポイントによって実行される関数を定義するソフトウェアと、プロセッサとを含む。或いは、これらの関数は、特定用途向け集積回路に設けられる、スイッチやコントローラなどのハードウェアを使用して定義してもよい。プロセッサはソフトウェアによって構成され、ＲＴＰデータフローの待ち時間を求めるステップと、ＲＴＰデータフローのジッタを求めるステップと、及び／または、ＲＴＰデータフローの消失パケットを求めるステップとを実行する。
【００１９】
本発明は、またＲＴＰデータフローのフロー品質の統計値を求める方法を提供すると考えられる。これに関し、このような方法の１つは、別々に、または組み合わせて使用される次のステップ、すなわちＲＴＰデータフローの待ち時間を求めるステップ、ＲＴＰデータフローのジッタを求めるステップ、かつ／または、ＲＴＰデータフローの消失パケットを求めるステップに大まかに要約される。
【００２０】
以下の図面や詳細説明を検討することにより、当業者には本発明の別のシステムや方法が明らかになるだろう。このような更なるシステム、方法、特徴、及び利点は全て本記述に含まれ、本発明の範囲内であり、添付の請求項によって保護されるものである。
【００２１】
【発明の実施の形態】
本発明のリルーティングシステムは、ソフトウェア、ファームウェア、ハードウェア、もしくはそれらの組み合わせで実施できる。本発明の好ましい実施形態では、リルーティングシステムの一部は、例えば、これに限らないが、パーソナルコンピュータ、ワークステーション、ミニコンピュータ、メインフレームコンピュータといったコンピュータで実行されるソフトウェアで実施される。ただし、本実施形態は限定をしない例とする。
【００２２】
リルーティングシステムのソフトウェア部は、論理関数を実行する実行命令の順序付リストから構成されており、コンピュータベースのシステムプロセッサを含むシステム等の命令実行システム、装置、または機器や、あるいは、命令実行システム、装置、または機器からの命令を取り込み、命令を実行できる他のシステムによって、使用されるか、またはこれらと共に使用されるコンピュータ読取可能媒体にて実現することができる。
【００２３】
本稿の文中、「コンピュータ読取可能媒体」とは、命令実行システム、装置、または機器によって使用される、またはこれらと共に使用されるプログラムを含有、格納、伝達、伝播、または伝送することのできる何等かの手段である。コンピュータ読取可能媒体は、例えば、これに限らないが、電子、磁気、光、電磁気、赤外線、または半導体のシステム、機器、または装置、或いは、伝播媒体である。コンピュータ読取可能媒体のより具体的な例（ただし、完全に列挙していない）としては、１本以上のワイヤを有する電気接続機器（電子）、携帯可能なコンピュータディスク（磁気）、ランダムアクセスメモリ（ＲＡＭ）（磁気）、リードオンリメモリ（ＲＯＭ）（磁気）、消去可能プログラム可能リードオンリメモリ（ＥＰＲＯＭまたはフラッシュメモリ）（磁気）、光ファイバ（光）、及び携帯可能なコンパクトディスク・リードオンリメモリ（ＣＤ ＲＯＭ）（光）が挙げられる。ただし、コンピュータ読取可能媒体はプログラムが印刷された紙や他の適当な媒体でもよく、プログラムは、例えば紙や他の媒体のオプティカルスキャニングによって電子的に取込まれ、その後コンパイルされ、解釈されるかまたは適当な方法で処理され、その後、必要であればコンピュータのメモリに格納される。
【００２４】
図１は、通信ネットワーク１０２に関連して実施される本リルーティングシステムを示すブロック図である。図１に示されるように、第１キャリヤネットワーク１１２は、米国マサチューセッツ州Ｐｉｎｇｔｅｌ製の電話等の第１ＳＩＰ電話１１４と、第１セッションルータ１１６と、第１マルチメディアルータ１１８とを含む。第２キャリヤネットワーク１３２は、インターネット１２２を介して第１キャリヤネットワーク１１２に接続され、第２ＳＩＰ電話１３４と、第２マルチメディアルータ１３６と、第２セッションルータ１３８とを含む。ただし、第１および第２キャリヤネットワーク１１２、１３２には、ＳＩＰでもＳＩＰでなくてもよいが、ネットワーク１１２とネットワーク１３２との間で通信を実施できるいかなる装置が含まれてもよい。他のＲＴＰデータ送信装置としては、これに限らないが、統合アクセス装置（ＩＡＤ）、ＶｏＩＰゲートウェイ（Ｃｉｓｃｏ ＡＳ５３００、Ｓｏｎｕｓ ＧＳＸ）、マルチメディア送信装置（ＰＣ、ＩＰ−ＰＢＸ）が挙げられる。さらに、ネットワーク１１２とネットワーク１３２との間の通信は、代わりに、ワイドエリアネットワーク（ＷＡＮ）やローカルエリアネットワーク（ＬＡＮ）を介して行われてもよい。また、マルチメディアルータ１１８、１３６はインターネット１２２内の２つのドメイン間で利用されるので、インターネット１２２は、代わりに、データネットワークドメインでもよい。
【００２５】
或いは、第１マルチメディアルータ１１８と第２マルチメディアルータ１３６との間に、これに限らないが、境界ルータ等のルータを設け、第１キャリヤネットワーク１１２と第２キャリヤネットワーク１３２との間の通信を補助してもよい。ただし、第１キャリヤネットワーク１１２と第２キャリヤネットワーク１３２との間の通信を行うのに境界ルータ等の追加のルータは必要ない。その代わり、第１ＳＩＰ電話１１４から第２ＳＩＰ電話１３４への通信は、以下詳細に説明するように、第１マルチメディアルータ１１８と第２マルチメディアルータ１３６とにより行われる。ただし、通信は、セッションルータから直接インターネット１２２に対して、マルチメディアルータ１１８または１３６を経由しなくてもよい。
【００２６】
第１および第２セッションルータ１１６、１３８は、ＭｅＬａｍｐｙらの「複数ネットワークを経由するＲＴＰ（リアルタイム・トランスポート・プロトコル）フローの制御を支援するシステムと方法」（出願番号０９／８４４，２０４、出願日２００１年４月２７日）という現在係属中の出願により詳細に説明されるように、セッション開始プロトコル（ＳＩＰ）とＴＲＩＰ（ｔｅｌｅｐｈｏｎｙｒｏｕｔｉｎｇ ｏｖｅｒ ＩＰ）プロトコルとをサポートする。この出願の明細書を本明細書に全て援用する。
【００２７】
第１マルチメディアルータ１１８と第２マルチメディアルータ１３６との間に別のマルチメディアルータを設けてもよい。図２は、本発明の別の実施形態による、２台のマルチメディアルータの代わりに３台のマルチメディアルータを使用する場合を示すブロック図である。このように、第１キャリヤネットワーク１１２に設けられた第１マルチメディアルータ１１８は、インターネット１２２を介して、第３マルチメディアルータ１３７と通信する。第３マルチメディアルータ１３７は、同様に、インターネット１２２を介して、第２キャリヤネットワーク１３２内の第２マルチメディアルータ１３６と通信する。
【００２８】
図３は、更に本発明の好ましい実施形態によるマルチメディアルータ１１８、１３６、１３７（図１）（以降、１１８とする）を示すブロック図である。図３に示されるように、これに限らないが、伝送制御プロトコル（ＴＣＰ）ソケット接続等の通信リンク１５２が、マルチメディアルータ１１８に設けられ、セッションルータや他のマルチメディアルータ等の他方のエンドポイントに接続する手段を提供する。当該技術において周知のように、ＴＣＰは、信頼性の高い全二重データ伝送を提供するコネクション型トランスポート層プロトコルである。或いは、別の種類のソケット接続を使用してもよい。出力装置１５４もマルチメディアルータ１１８に設けられる。マルチメディアルータ１１８の命令及び制御のために、マルチメディアルータ１１８とセッションルータとの間に私設網を確立することが好ましい。
【００２９】
通信リンク１５２は、パーソナルコンピュータメモリカード国際協会（ＰＣＭＣＩＡ）スロットでもよい。これに限らないが、フラッシュカードや外部ドライブ等の外部装置を使用してマルチメディアルータ１１８のソフトウェアをアップグレードするため、ＰＣＭＣＩＡスロットが使用される。ただし、マルチメディアルータ１１８には２つ以上の通信リンク１５２が設けられてもよい。
【００３０】
マルチメディアルータはまたトラフィックマネージャ１５６を備える。トラフィックマネージャ１５６は好ましくはＩＰセッションデータフロー速度やトラフィックを計測したり、強化したりするために使用され、トラフィック測定を行う。市販のトラフィックマネージャ１５６の例としては、米国カリフォルニア州にあるＭＭＣネットワークにより販売されているＮＰＸ５７００トラフィックマネージャがある。基本的に、トラフィックマネージャ１５６は通信リンク１５２を流れるデータパケット数を測定する。トラフィックマネージャ１５６はネットワークプロセッサ１５８（後述する）とともに動作して、一度転送決定がされると、トラフィックマネージャ１５６は受信パケットを、それぞれのＩＰフローに、関連する優先順位に従って並べる。
【００３１】
当該技術で周知のように、トラフィックマネージャ１５６は受信したデータパケットを一時的に格納するメモリを備える。受信の観点から見ると、マルチメディアルータ１１８はＲＴＰデータフローを監視し、パケットがデータフロー用に割当てられた帯域幅の外側にある場合、パケットを捨てるか、廃棄に値するとしてマークするかにより、最大データ速度にする。
【００３２】
好ましくは、セッションルータが、データフローへの帯域幅の割当てや、どのデータフローがデスティネーションまでマルチメディアルータ１１８を経由して流れるように割当てられるかの指定を担当する。ただし、この指定はマルチメディアルータ１１８により直接行われてもよい。または、マルチメディアルータ１１８があるデータフローを通すように割当てられていない場合、そのデータフローはマルチメディアルータ１１８を通ることができない。トラフィックマネージャ１５６はまた、セッションルータに命令されて、割当てられた帯域幅とビットレートとに従い特定量のデータを受信する。したがって、データがセッションルータにより許可されたよりも高速のビットレートで受信されると、その高速のビットレートで受信されたデータは送信されない。ただし、セッションルータにより指定される特性は、代わりに、セッションルータを使用せずにマルチメディアルータ１１８に直接プログラムしてもよい。
【００３３】
マルチメディアルータ１１８は、以下に詳細に説明するように、受信したデータパケットを送信する際、トラフィックシェーピングを提供することもできる。トラフィックシェーピングにより、マルチメディアルータ１１８に一時的に格納された受信データパケットがマルチメディアルータ１１８からデスティネーションへ送信される順番が指定される。さらに、トラフィックシェーピングにより、データパケットの送信用に割当てられる帯域幅の大きさの指定が可能になる。
【００３４】
マルチメディアルータ１１８はＲＴＰデータフローのフロー品質統計値を生成することができる。更に、マルチメディアルータ１１８は、ＲＴＰパケットが通信ネットワーク１０２を流れる際、ＲＴＰパケットからフロー品質統計値を生成することができる。図１に示すように、マルチメディアルータ間のリンクにのみ関連する統計値もある。つまり、マルチメディアルータ１１８はエンドポイントまでのフロー品質を測定できない。ジッタ及び待ち時間は、この部類に該当する２つのフロー品質の測定値である。
【００３５】
好ましくは、マルチメディアルータ１１８を経由するフローごとに１つ以上の統計値が格納される。これらの統計値には、これに限らないが、待ち時間、ジッタ、１パケット中のオクテット数、及び／または脱落パケット数などがあり、それぞれ以下に詳細に述べる。ただし、マルチメディアルータ１１８を経由する各データフローに関して、他の統計値を格納してもよい。各データフローの統計値を生成するために、マルチメディアルータ１１８は、接続されたマルチメディアルータ間で、これに限らないが、リアルタイム制御プロトコル（ＲＴＣＰ）等のプロトコルの専用バージョンを実行し、待ち時間を求める。ジッタ及び脱落パケットの統計値は、マルチメディアルータ１１８により独立して生成することができる。以下に、待ち時間、ジッタ、及び脱落パケットがＲＴＣＰ情報なしにどのように求められるかを説明する。
【００３６】
データフローの待ち時間を測定するため、マルチメディアルータ１１８がそのデータフローの別のエンドポイントと通信する。おそらく、この別のエンドポイントは別のマルチメディアルータである。ただし、必ずしもそうでなくてもよい。好ましくは、この通信の対象は、ＲＴＰデータフローの待ち時間を求めるために、エンドポイントがマルチメディアルータ１１８に折り返すテストパケットである。折り返されたパケットを受信するマルチメディアルータ１１８は、パケットを受信した時刻とパケットを送信した時刻を比較し、往復時間を調べる。次に、往復時間を半分にして片道の時間の近似値を求める。これが待ち時間である。
【００３７】
上述したようにパケットを折り返す専用の方法を使用する以外に、２台のマルチメディアルータ間にＲＴＣＰパケットフォーマットを使用することもできる。このフォーマットにより、送信側のタイムスタンプを（送信レポートから）抽出でき、パケットを折り返すのにかかる時間の見積もりとともに、タイムスタンプを折り返すパケット（受信レポート）に入れることができる。
【００３８】
ジッタは１フロー上のパケット間隔の変化量の測定値である。別の定義では、ジッタはフローの待ち時間の変化である。マルチメディアルータ１１８は、ＲＴＰデータフローがマルチメディアルータ１１８を通過する際に、そのＲＴＰデータフローについてジッタを測定する。データパケットが、マルチメディアルータ１１８内に設けられたネットワークプロセッサ１５８に達すると、タイマがスタートし、そのＲＴＰデータフローの次のパケットが到着するまで動作する。パケット間隔は、総量に加算されて「平均」ジッタ値を維持する。「平均」ジッタ値をフローレコードの最小値／最大値と比較し、新たな最小／最大ジッタ値となるかを判定することもできる。ただし、フローレコードは、ネットワークプロセッサ１５８に設けられたネットワークプロセッサメモリ（図示せず）内に設けられる。また、マルチメディアルータ１１８に設けられる全てのメモリが、マルチメディアルータ１１８の内部または外部に備えられた単一のメモリ内に設けられてもよい。このプロセスがプロセッサに集中しすぎる状況では、周期的にジッタサンプルを集計し、集計した情報を使用して最小／最大の計算を行ってもよい。
【００３９】
ＲＴＣＰに基づく機構が無い場合の脱落パケット、または消失パケットの処理は、あるＲＴＰフローにおいてブーリアンの２つのスコアボード配列を用いて行われる。スコアボード配列は、パケットがいつ無くなるのか、及び、パケットがジッタウィンドウ中に現れるかを追跡するために使用される。パケットを処理する別の方法を使用してもよい。ただし、ジッタウィンドウは通常、変動するネットワーク条件を補償するために音声ゲートウェイで実装される。ジッタウィンドウは、入ってくるパケットを転送する前に、復元のために一定時間保持するパケットバッファである。このプロセスは、パケットフローを平滑にする効果があり、パケットロスに対する符号化／復号化装置（ＣＯＤＥＣ）の復元力を増加させ、パケットを遅延させ、他の伝送効果をもたらす。ジッタウィンドウはマルチメディアルータ１１８により直接的に定義されてもよいが、好ましくは、セッションルータによって定義される。
【００４０】
スコアボード配列における各項目は、特定のシーケンス番号のパケットがマルチメディアルータに受信されたかを示す。スコアボード配列は、ネットワークプロセッサメモリまたは何れかのローカルまたは遠隔メモリに設けられてもよい。ブーリアンの各配列は、幾つの項目が「紛失」とマークされたのか追跡するカウンタを備える。好ましくは、全ての項目は初めに「受信」とマークされる。
【００４１】
ネットワークプロセッサ１５８で、連続番号が追跡され、紛失パケットが検出されると、具体的には、連続番号が２以上増分したパケットが検出されると、カレントの配列における適当な項目は「紛失」とマークされ、紛失カウンタが増分される。好ましくは、２つの配列は、ジッタウィンドウにおけるパケットの最大数の大きさにする。これらの２つの配列は以下、カレント配列と古い配列と呼ぶ。カレント配列がジッタウィンドウの最大に達すると、古い配列が再初期化され、カレント配列となり、カレント配列が古い配列になる。古い配列が消去される前に、該データフローについて脱落パケット用のカウンタを検索し集計する。
【００４２】
もし、代わりに、連続番号が現在の連続番号より小さい、順序の違う古いパケットが受信されると、ネットワークプロセッサ１５８はパケットの遅れ時間に応じて、カレント配列または古い配列のいずれかにおいてその連続番号の項目を探索する。ネットワークプロセッサ１５８が紛失とマークされた項目を見つけその項目を変更すると、ネットワークプロセッサ１５８は、紛失パケットを追跡するために使用される、該配列の紛失パケットカウンタを減分する。パケットが紛失とマークされていなければ、ネットワークプロセッサ１５８はパケットが複製であることを示す。もし、連続番号が古くて、パケットの日付がジッタウィンドウの深さより遡る場合、ネットワークプロセッサ１５８は探索を行わない。ただし、脱落パケットをカウントするこの方法はＲＴＣＰを用いて得られるものより正確である。
【００４３】
ＲＴＣＰ情報を用いて、待ち時間、ジッタ及び脱落パケットをどのように調べるかついて以下に記述する。詳細は、ＲＴＰ規格ＲＦＣ１８８９「リアルタイムアプリケーションのためのトランスポートプロトコル」（１９９６年１月、Ｓｃｈｕｌｚｒｉｎｎｅら）に記述されている。別の参考文献として、「Ｈ．３２３によるＩＰ電話」（Ｋｕｍａｒら、ＩＳＢＮ ０−４７１−３９３４３−６）が挙げられ、これは、今日当該技術において行われる統計値の計測について記述している。マルチメディアルータ１１８は、エンドポイントから受信するＲＴＰデータフローに付随するＲＴＣＰストリームを処理することができる。この処理は、上記プロセスの代わりに、または上記プロセスに付加して行われる。ＲＴＣＰフローはＲＴＰセッションの間に調査され、様々な精度レベルの品質統計値が得られる。詳細に関係のあるＲＴＣＰパケットは、送信側レポートと受信側レポートとを含む。送信側レポートが送信側の送信情報と受信側毎の情報とを含み、受信側レポートは受信側毎の情報を含むという差異はあるが、この２つのレポートはほとんど同一である。
【００４４】
待ち時間、ジッタ、及び脱落パケットの導出に特に関係のある、受信側レポートメッセージのセッション統計値には、部分消失、累積消失、受信した最大の連続番号、到着間隔ジッタ、最終セッションレポートのタイムスタンプ（ＬＳＲ）、及び／またはＬＳＲからの遅延が含まれる。部分消失のセッション統計値は、最後の送信側レポートまたは受信側レポートのメッセージが送信されてから消失した、ある特定ソースからのＲＴＰパケットの率を示す。累積消失のセッション統計値は、セッションの開始以来消失した、ある特定ソースからのＲＴＰパケットの総数を示す。この数には、事実上消失している遅延パケットは含まれない。上記で参照されたＲＴＰ仕様によって識別された複製パケットが、受信されたものとしてカウントされ、紛失パケットを補償し、さらにこの計測値の精度を上げている。
【００４５】
受信した最大連続番号のセッション統計値の値は、送信側レポートまたは受信側レポートからメッセージごとに追跡され、累積消失の統計値とともに、１セッション中に流れたはずのＲＴＰパケットの数を求めるのに使用される。
【００４６】
送信されたＬＳＲ時刻メッセージ及びＬＳＲからの遅延時間のセッション統計値は、最後に送信された送信側レポートメッセージの受信側が、その送信側レポートメッセージの送信側にエコーバックすることと、送信側レポートのネットワークタイムプロトコル（ＮＴＰ）のタイムスタンプと、受信側がどれくらいの時間で送信側レポートメッセージをターンアラウンドし、受信側レポートを送信するのか、とに関係する。基本的に、受信側は受信側レポートメッセージを受信した時刻をマークし、現在の時刻から、(送信側レポートが送信されたときの)ＬＳＲと最終セッションレポートからの遅延時間（ＤＳＬＲ）（メッセージ処理遅延）とを減算して往復の遅延時間を求めることができる。
【００４７】
送信側レポートメッセージに固有のセッション統計値には、送信側レポートのＮＴＰタイムスタンプと、送信側パケット数と、送信側オクテット数とが含まれる。送信側レポートＮＴＰタイムスタンプのセッション統計値については上記に詳細に記述した。送信側パケット数のセッション統計値は、マルチメディアルータ１１８を経由して１エンドポイントに送信されるＲＴＰデータパケットの総数を示す。さらに、送信側オクテット数のセッション統計値は、セッションの開始以降、送信側によりＲＴＰデータパケットで送信されたペイロードのオクテットの総数を示す。
【００４８】
ＲＴＣＰパケットから利用可能なデータを与えられたとすると、フロー毎に、消失パケットの数と、パケットの総数と、略即時の待ち時間及びジッタのレベルとが得られる。これら４つのマトリクスの各々の計算は、以下詳細に論議する。
【００４９】
消失パケットの数は、受信側レポートメッセージで通知される累積消失の統計値から直接生成してもよい。残念ながら、この生成方法は、期待される数に対し複製パケット及び遅延パケットを誤ってカウントするので、この測定値はいくらか不正確である。
【００５０】
パケットの総数は、受信側レポートから受信した最大の連続番号を受信側レポートの初期値と比較し、流れたと期待されるパケット数を求めることで生成される。流れたことが期待されるパケット数から消失パケット数を減算して、受信された実際のパケット数を求める。本発明の別の実施形態によると、送信側レコードの送信側パケット数の統計値を使用して期待される値を設定できる。
【００５１】
待ち時間に関しては、受信側レポートメッセージのデスティネーションが、受信側レポートメッセージのＬＳＲフィールド及びＤＬＳＲフィールドを使用し、往復の遅延時間を求めてもよい。つまり、受信側レポートメッセージのデスティネーションが、受信側レポートメッセージが受信された時刻を記録し、ＬＳＲ、すなわち送信側レポートが送信された時刻と、ＤＳＬＲ、すなわち、受信側レポートの送信側が受信側レポートを送信するのにかかる時間とを減算する。
【００５２】
送信側レポートの発信者が受信側レポートを受信する実際の時刻が必要なので、待ち時間の計算には誤差を生じる余地がある。待ち時間の計算における誤差を最小限にするために、送信するマルチメディアルータはフロー毎の最終の送信側レポートのタイムスタンプを保持してもよい。これによると、受信側レコードが戻って送信側で受信されると、受信側レコードが、送信するマルチメディアルータによって求められる現在時刻から減算される。更に、受信側レコードメッセージのＤＳＬＲが受信側レコードの受信時刻から減算され、送信するマルチメディアルータと受信側レポートの発信者との間の往復遅延時間となる。
【００５３】
好ましくは、送信側レコードメッセージのＮＴＰタイムスタンプを戻ってきた受信側レコードメッセージのＬＳＲと比較し、待ち時間の計算が妥当であることを確認する。タイムスタンプが一致しなければ、計算が正しくないので修正される。修正する方法の１つは、次の送信側レコードメッセージが受信されるときに、再度やり直すだけでもよい。ただし、往復の待ち時間は、マルチメディアルータ１１８を経由するＲＴＰフローの両側から計算され、往復の値が二等分されて片道の待ち時間とする。
【００５４】
次にジッタの計算について述べる。ジッタは、パケットの到着間時間の標準偏差と考えられる。そのため、ジッタを測定するには、あるフローに関する最初のパケットの受信後にタイマをセットし、該フローにおける次のパケットの受信時にタイマを停止する。この経過時間が「パケット間時間」の１サンプルである。パケット間時間を数回連続して測定することにより、フローの平均変動、すなわちジッタを求めることができる。フローのジッタを正確に求めるには、一定の数のサンプルを記録し平均して許容値外の測定値の影響を取り除く。これは、時間のウィンドウと考えることができる。一度計算が実行された後、次の計算値を得る方法がいくつかある。１つの方法は、スライディングウィンドウであり、最も古いサンプルを捨て新しいサンプルを追加した後、平均を計算する。つまり、スライディングウィンドウでは、平均はサンプル毎に再計算される。これにより、非常に正確な傾向の指標が得られる。次のウィンドウを計算する二番目の方法は、全てのサンプルを捨てて、データの収集を開始し新しいサンプルを一揃い得る方法である。これにより、非常に正確な「期間」指標が得られる。何れの機構を用いてもよい。ネットワーク動作の品質を把握するためには、待ち時間の最良の計測値と共に最悪の計測値を保持することも有益である。
【００５５】
図２のブロック図に戻ると、マルチメディアルータ１１８にはフロー品質管理エンジン１５７が設けられている。フロー品質管理エンジン１５７は、マルチメディアルータ１１８の変換サービスと、品質測定サービスと、上流・下流の障害の検出及び訂正とを提供する。各々について以下詳細に論議する。
【００５６】
マルチメディアルータ１１８でフロー品質管理エンジン１５７の実行する変換サービスは、ソースアドレス、デスティネーションアドレス、ソースポート、デスティネーションポート、またはこれらのフィールドの組み合わせを変換する機能を備える。マルチメディアルータ１１８はまた、ＲＴＰデータパケットがルーティングシステム１００を通過する際に、そのＩＰヘッダのマルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）タグを削除及び／または挿入できる。さらに、マルチメディアルータ１１８は、ＲＴＰデータパケットのＩＰヘッダに設けられるＤｉｆｆｓｅｒｖコードポイントの挿入または変更ができる。当該技術で周知のように、Ｄｉｆｆｓｅｒｖコードポイントは、データパケットのプライオリティを変更するために使用される。
【００５７】
マルチメディアルータ１１８のフロー品質管理エンジン１５７の提供する品質測定サービスはフロー毎に提供され、ここで、ＲＴＰフローは、ソースＩＰアドレスと、デスティネーションＩＰアドレスと、ソースポートと、デスティネーションポートとにより定義される。品質測定において、好ましくは、ネットワークプロセッサメモリにＲＴＰデータフローの現在の統計値を保持し、適用可能であれば、ＲＴＰデータフローの総計及び最大／最小の統計値も同様に保持する。収集される統計値の例としては、所定の時間ウィンドウでの待ち時間、ジッタ、及びパケットロスが挙げられる。ただし、このウィンドウはセッションルータまたはマルチメディアルータ１１８により特定することができる。
【００５８】
総計の統計値には、送信されたＲＴＰデータパケット、脱落ＲＴＰデータパケット、及び複製ＲＴＰデータパケットを含んでもよい。時間ウィンドウ毎の待ち時間、ジッタ、及びパケットロスを含む、境界統計値とも呼ばれる、最小及び最大の統計値を収集してもよい。トラフィックマネージャ１５６に関連して、待ち時間、ジッタ、及びパケットロスについての更なる論議は上記に示す。
【００５９】
上述のように、マルチメディアルータ１１８のフロー品質管理エンジン１５７はまた、ＲＴＰデータパケットの伝送における上流及び下流の障害の検出及び訂正を行う。フロー品質管理エンジン１５７が使用する１つの方法は、ＲＴＰデータフローの中断を検出する。図４は、フロー中断検出を示すために通信ネットワークの一例を提示するブロック図である。
【００６０】
図４に示すように、４つの別々のＲＴＰデータソース２０２、２０４、２０６、２０８から、４つの別々のＲＴＰデータフローが生じている。ただし、ＲＴＰデータソースには、これに限らないが、ＳＩＰ電話等が含まれる。４つのＲＴＰデータフローは各々、少なくとも１台のセッションルータ（図示せず）を介して、第１マルチメディアルータ２１２に伝送される。次に第１マルチメディアルータ２１２は、第１マルチメディアルータ２１２のネットワークプロセッサメモリ内に格納された開始ソースアドレスとデスティネーションアドレスの組み合わせにしたがって、ＲＴＰデータパケットを第２マルチメディアルータ２１４または第３マルチメディアルータ２１６の何れかにルーティングする。図４に示すように、第２マルチメディアルータ２１４は、第１マルチメディアルータ２１２から同時に３つのＲＴＰデータフローがあり、第３マルチメディアルータ２１６は、第１マルチメディアルータ２１２から１つのＲＴＰデータフローしかない。ただし、マルチメディアルータの数、ＲＴＰデータフローのソース、セッションルータの種類、及びＲＴＰデータフローのデスティネーションは異なってもよい。
【００６１】
図４に示すように、第２マルチメディアルータ２１４は、ＲＴＰデータパケットを３つの異なるデスティネーション２２２，２２４、２２６に転送する。ＲＴＰデータパケットのデスティネーションは、これに限らないが、ＳＩＰ電話を含む何れの装置でもよい。第３マルチメディアルータ２１６も、受信したＲＴＰデータパケットをデスティネーション２２８に転送する。好ましくは、各マルチメディアルータが、各ＲＴＰデータフローについて定められた閾値よりも長いＲＴＰデータパケットに欠落があるフロー中断を、個々に検出する。
【００６２】
フローの中断を判定するために、各ＲＴＰデータフローは、初期パケット保護タイマと、後続パケット保護タイマとを有する。保護タイマはセッションの初期開始時、またはパケット受信時にスタートする。新たなパケットが到着せず、かつタイマが切れると、フロー中断が検出される。「無音圧縮」が開始されることを示すために送信される特定のパケットがあり、保護タイマはこれを考慮しなければならないので、実際に単に完全無音のときには、フローが「中断された」と報告されない。
【００６３】
全てのＲＴＰデータフロー、または少なくとも、割合もしくは閾値の数により決められた大多数のＲＴＰデータフローが、フロー中断を検出される状態であるとき、第１マルチメディアルータ２１２は障害を起こしている可能性が高い。詳細に説明すると、マルチメディアルータは、全フローのそれぞれのタイマ（初期及び後続パケット保護タイマ）を同時にセット及びクリアしている。マルチメディアルータはパケットを次のホップ先に送信する。もし、次のホップ先が別のマルチメディアルータであって、そのマルチメディアルータから到着するフローまたはそのフローの多くの箇所で同時にフロー中断が検出されると、次のホップ先のマルチメディアルータが障害を起こしている可能性が高い。例として、図４を考えると、ＲＴＰデータパケットは、ＲＴＰデータソース２０２からＲＴＰデスティネーション２２２へ流れ、同時に、ＲＴＰデータパケットはＲＴＰデスティネーション２２２からＲＴＰデータソース２０２へ流れる。
【００６４】
つまり、ＲＴＰパケットはＲＴＰデータソース２０２から第１マルチメディアルータ２１２、第２マルチメディアルータ２１４、デスティネーション２２２へ流れ、またその逆にも流れる。第１マルチメディアルータ２１２は、ＲＴＰデータソース２０２からのパケットを第２マルチメディアルータ２１４へ転送し、第２マルチメディアルータ２１４は、デスティネーション２２２からのＲＴＰデータパケットを第１マルチメディアルータ２１２へ転送する。ただし、図４において、３つのＲＴＰデータフローが矢印で示されている（ここで、逆のフローは示されていないが、当然含まれている）。ただし、また、第２マルチメディアルータ２１４は、上述したフロー保護タイマを用いてフロー中断検出を行う。３本の全てのフローが同時に中断された場合、第１マルチメディアルータ２１２、または第１マルチメディアルータ２１２と第２マルチメディアルータ２１４との間の共有リンクがもはや動作していない可能性が非常に高い。したがって、第２マルチメディアルータ２１４は、逆方向に向かうＲＴＰデータパケットをどこに送信するかの決定を行う。第２マルチメディアルータ２１４は、或いは、パケットをＲＴＰデータソース２０２に転送するために、第３マルチメディアルータ２１６に転送することもできる。
【００６５】
或いは、フロー中断の検出が、第１マルチメディアルータ２１２と第２マルチメディアルータ２１４との間の経路が機能していないことを示していることもある。結果として、複数の別個のＲＴＰフローの不通を累積的に検出することにより、第１マルチメディアルータの経路の不通が検出される。したがって、第２マルチメディアルータ２１４は、第１マルチメディアルータ２１２が稼動していない、または、第２マルチメディアルータ２１４と第１マルチメディアルータ２１２との間の経路が破損していることを認識する。結果として、第２マルチメディアルータ２１４は、第１マルチメディアルータ２１２を使用する経路以外の別のデータ経路を使用することにより、デスティネーション２２２、２２４、２２６から４つのＲＴＰデータソース２０２、２０４、２０６、２０８に到着するＲＴＰデータフローをリルーティングすることで対処することができる。
【００６６】
マルチメディアルータ１１８には、またホストプロセッサ１６４が設けられ、ローカルリンク１６６を介してトラフィックマネージャ１５６に接続されている。当該技術で周知のように、ローカルリンク１６６はバス、専用パス、及び／またはデータ伝送手段である。ホストプロセッサ１６４は、トラフィックマネージャ１５６と同様、上流及び下流の障害の検出及び訂正を提供する。ＲＴＰデータパケットの伝送において上流及び下流の障害を検出及び訂正するために、ホストプロセッサ１６４の使用する方法には、これに限らないが、リンク障害の使用及び外部管理イベントの使用が含まれる。
【００６７】
上流及び下流の障害を検出及び訂正するためにリンク障害を使用する方法に関し、図４を再度参照する。第２マルチメディアルータ２１４が、第１マルチメディアルータ２１２と第２マルチメディアルータ２１４との間のリンク障害に関する情報を受信した場合、その情報を使用してＲＴＰフロートラフィックをリルーティングしてもよい。リンク障害の種類の例としては、例えば、リンク層のハードウェアとドライバとが、これに限らないが、キャリア喪失、ビットエラー、過度の衝突、及び警報を含む各種リンク障害を報告可能な、直接接続されたリンクが挙げられる。これらのリンク障害は、第２マルチメディアルータ２１４に直接マルチメディアルータのハードウェア及びドライバによって報告され、マルチメディアルータのネットワークプロセッサ１５８へ入って、ここでリルーティングの決定が行われる。ネットワークプロセッサ１５８について以下詳細に論議する。
【００６８】
マルチメディアルータに直接接続されていないリンクのリンク障害は、多数の様々な方法を用いて発見することができる。そのうちの幾つかを以下に示す。リンク障害を発見する第１の方法には、ＯＳＰＦ（ｏｐｅｎ ｓｈｏｒｔｅｓｔ ｐａｔｈ ｆｉｒｓｔ）プロトコルの実施が含まれる。ＯＳＰＦプロトコルはリンクステートトポロジーを絶え間なく配信する。リンク障害を発見する第２の方法は、マルチメディアルータにより使用されていた到達可能な経路を削除する境界ゲートウェイプロトコル−４（ＢＧＰ−４）の使用によるものである。ＯＳＰＦリンクステート情報を得るために、マルチメディアルータ１１８は、マルチメディアルータ１１８をインテリア・ゲートウェイ・プロトコル（ＩＧＰ）のピアとして、ＯＳＰＦ情報交換もしくはフラッディングに参加する。したがって、ＢＧＰ−４撤回経路情報を得るために、マルチメディアルータ１１８はＩＧＰ（ＯＳＰＦ）参加を使用する。つまり、あるネットワーク内に接続されている場合、経路情報はＯＳＰＦを介して配信される。ＢＧＰ−４撤回経路指示によって、外部経路が使用不能になった場合、前述のように接続された全てのリンクに対し、新たな外部ルーティングの可能性がＯＳＰＦを介してプロトコルによって内部通知される。或いは、ＢＧＰ−４の経路情報交換へ直接参加することにより、撤回経路情報を得てもよい。
【００６９】
リンク障害を発見する第３の方法は、隣接フローを処理しているアクティブなマルチメディアルータ間でハートビートメッセージを使用するか、またはポーリングを行い、接続を確保し統計値を共有することである。ポーリングに応答が無い場合、リンクまたはマルチメディアルータは使用不能とされる。
【００７０】
以下は、上流及び下流の障害を検出及び訂正するための外部管理イベントの使用についての記述である。ネットワーク運用センタ（ＮＯＣ）に設けられる、これに限らないが、ヒューレッドパッカードのオープンビュー等のネットワーク管理システムで、ネットワークの障害を認識してもよい。このイベントは意図的でない、すなわちネットワークの定期保守に関連させることもできる。つまり、ＳＮＭＰを使用して、ネットワークリンク及びハードウェアを監視することが可能である。管理局は、ハードウェアやネットワークの問題を様々な方法で発見することが可能である。第１の方法では、ＳＮＭＰメッセージが被監視装置から管理局に送信される。これは、一般にＳＮＭＰトラップと呼ばれる。第２の方法では、管理局から情報要求が送信され、被監視装置はデータを応答する。どちらの場合も、管理局がネットワーク及びその物理リンクの動作についての情報を得る。
【００７１】
このように、管理局は、保守目的のためにリンクをサービスから外してもよく、リンクが使用可能でないことを通知する。ＯＳＰＦプロトコル及びＢＧＰ−４プロトコルは、ネットワークテーブルの再構成と伝送を管理する。これは、リンクの使用可能性に変更を反映するために必要である。当該技術で周知のように、ＯＳＰＦ（及び他の内部ルーティングプロトコル）及びＢＧＰ−４（及び他の外部ルーティングプロトコル）を使用して、ネットワークに設けられた各ネットワークルータに含まれるネットワークテーブルに変化を通知する。これらのテーブルは、１つのリンクから別のリンクへ適正にパケットを転送するために使用される。したがって、ルーティングの変更が実行されると、ネットワークルータのネットワークテーブルで変化を認識する。セッションルータの制御下にあるマルチメディアルータ１１８は、ＲＴＰデータフローをある特定の削除された、または使用禁止のエンドポイントに導くポリシーを１つ以上備えてもよく、それにより、稼動しているリンクの使用を防止する。
【００７２】
前述のように、ネットワークプロセッサ１５８もマルチメディア１１８に設けられている。ネットワークプロセッサ１５８は、パケットヘッダの検査及びＲＴＰデータフローパケットの高速リルーティングのためのパケットの転送決定を行う。さらに、ネットワークプロセッサ１５８はマルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）のラベル抽出及び挿入をサポートする。数種の高速ルーティングの方法、すなわち、ロードシェアリング構成、セカンダリ経路構成、経路を新たにルーティングする構成、及びネットワーク指向ルートアラウンド構成がネットワークプロセッサ１５８によって提供される。
【００７３】
以下は、高速ルーティングのためのロードシェアリング構成の使用を説明する。各ＲＴＰデータフローは、連続番号、好ましくは、１で始まりパケット毎に増分する連続番号を有するＲＴＰデータパケットからなる。ネットワークへの入り口でＲＴＰデータパケットを受信すると、ＲＴＰデータパケットは、例えば、偶数／奇数分散アルゴリズムや、次回のマルチメディアルータの数によるモジュロ除算アルゴリズムに基づき、様々な位置に送信される。ただし、本発明の別の実施形態により他の分散方法を使用してもよい。
【００７４】
図５のブロック図を用いてさらに上述のプロセスを説明する。図５に示されるように、偶数／奇数分散が使用される。ＲＴＰデータフローが始まると、フローの最初のデータパケットに連続番号の「１」が付される。連続番号はＲＴＰデータパケットのヘッダ部に配置される。後続の各パケットについては、連続番号が増分される。このように、図５では、偶数番号のパケットは、第１マルチメディアルータ２５２から第３マルチメディアルータ２５４、デスティネーション位置２５８へ横断し、奇数番号のパケットは、第１マルチメディアルータ２５２から第２マルチメディアルータ２５６、デスティネーション位置２５８へ横断する。ただし、後続のパケットについて連続番号が増分されれば、代わりに最初のデータパケットに別の連続番号を付してもよい。
【００７５】
以下に、図５を参照してＲＴＰデータフローについて詳細に記述する。第１マルチメディアルータ２５２は、通信ネットワーク１０２の入り口で、セッションルータ２５３からＲＴＰデータフローを受信する。ただし、このセッションルータ２５３から受信されたＲＴＰデータフローは、元々図示されない１台もしくは複数のソースから発生する。偶数番号を付されたＲＴＰデータパケットは第３マルチメディアルータ２５４に送信され、奇数番号を付されたＲＴＰデータパケットは第２マルチメディアルータ２５６に送信される。第２マルチメディアルータ２５６及び第３マルチメディアルータ２５４は、どちらもセッションルータ２５３により指定された通りに、ＲＴＰデータパケットを転送し、最終的に、偶数番号及び奇数番号のパケットが到着するデスティネーション位置２５８に集まる。つまり、ＲＴＰデータパケットはＲＴＰデータパケットのソースからＲＴＰデータパケットのデスティネーション２５８に横断する際、すなわち通信ネットワーク１０２の入り口から出口まで横断する際、２本の経路を使用する。第２マルチメディアルータ２５６が障害を起こすと、両方の方向について、第１マルチメディアルータ２５２及びＲＴＰデータパケットのデスティネーション２５８は、偶数番号のパケットのみを受信する。
【００７６】
本発明の実施例によると、偶数番号のＲＴＰデータパケットのみが受信されるので、奇数番号の経路が機能していないことが明らかであり、奇数番号のＲＴＰデータパケットも第３マルチメディアルータ２５８に送信されることを示す。したがって、第２マルチメディアルータ２５６の経路上でリンクまたはマルチメディアルータの障害が発生するまでは、ＲＴＰデータパケット負荷は均一に分配される。このとき、ＲＴＰデータパケット負荷は、第３マルチメディアルータ２５４によって管理される経路に移動する。ただし、これは通信ネットワークの一例であって、ソース、マルチメディアルータ、データ経路、セッションルータ、またはデスティネーションの数を限定するものではない。
【００７７】
モジュロ除算方法は、２本以上の経路が負荷を分担する機構を提供する。したがって、経路の数が例えば３本であるとき、ＲＴＰデータパケット連続番号０、３、６、９等が、第１経路に送出さる。また、ＲＴＰデータパケット連続番号１、４、７、１０等が第２経路に送出され、ＲＴＰデータパケット連続番号２、５、８、１１、１３等が第３経路に送出される。
【００７８】
以下に、高速ルーティングのためのセカンダリ経路構成の使用方法について述べる。プライマリ経路が、セッションルーティングを用いてマルチドメインネットワーク経由で割当てられる。この一例が「複数ネットワークを経由するリアルタイム・トランスポート・プロトコルフローの制御を支援するシステム及び方法」と題された係属中出願に記述されている。さらに、マルチメディアルータを使用して様々な位置にパケットを転送する場合、同様に実行可能なセカンダリ経路が割当てられる。したがって、各マルチメディアルータには、プライマリ変換とセカンダリ変換とが用意される。以下にセカンダリ経路構成の一実施例を提示する。本実施例により、セッションルータからマルチメディアルータへのマルチメディアフローを設定する以下のコマンドを考える。
【００７９】
【実施例】

ただし、上記提示された実施例では、プライマリまたはセカンダリアドレスの組から受信されるパケットは、１つのＲＴＰデータパケットフローの一部であるものとする。したがって、プライマリのソースとデスティネーションの組、またはセカンダリのソースとデスティネーションの組を持つ、リンクに到着したパケットが変換され、プライマリまたはセカンダリのアウトバウンドアドレスに変換される。つまり、ソースアドレスが１２９．０．０．１：３０００、デスティネーションアドレスが１３０．０．０．１：５０００のＲＴＰデータパケットが到着すると、このパケットは、ソースアドレス１３１．０．０．１：３０００、デスティネーションアドレス１３２．０．０．２：４０００、または、ソースアドレス１３３．０．０．１：１０００、デスティネーションアドレス１３４．０．０．１：７０００に変換される。プライマリ変換かセカンダリ変換かの選択は、好ましくは、フロー中断検出及びリンク障害検出に関して上記で略述したような障害判定に基づく。
【００８０】
以下に、高速ルーティングのための経路を新たにルーティングする構成の使用について記述する。経路を新たにルーティングする構成は、転送経路で障害を検出すると、マルチメディアルータのアウトバウンド側に新しいアドレスを割当てる。マルチメディアルータは好ましくは転送経路の障害をセッションルータに報告し、セッションルータで新しい転送経路が割当てられる。セッションルータは次に新しい経路を再接続指示とともにマルチメディアルータに送信する。
【００８１】
ネットワーク指向ルートアラウンド構成に関しては、別々のネットワークアドレスを用いてネットワークを経由する様々な経路をターゲットとし、ＯＳＰＦに基づくルーティングを使用して、ＲＴＰトラフィックの二重経路構成または負荷分担構成を有するようにする。ＯＳＰＦを使用して、複数リンクに均等にパケットを流すことができる。リンクの距離値を慎重に設定することにより、マルチメディアルータは、共通デスティネーションに負荷を分担させることができる。さらに、ＢＧＰ−４を用いると、通知され受け取った到達可能経路を慎重に管理することにより、複数リンクにわたりトラフィックを低減することもできる。ＯＳＰＦ、ＢＧＰ−４のどちらの場合でも、１つのリンクが障害を起こすと、他のリンクがトラフィックの残りを吸収する。
【００８２】
図３に戻って参照すると、マルチメディアルータ１１８はシステムレベルでコンフィギュレーションされる。このコンフィギュレーション手段は、好ましくは入力装置１６６から入力されるコマンドラインを介して行われる。マルチメディアルータのコンフィギュレーションは、ブートソース情報を含む、マルチメディアルータ１１８用のブート情報と、（管理者が割当てる）システム識別名、ユーザログイン及び／またはパスワード、及びリンクＩＰアドレスを含むシステム情報とを備える。この情報はネットワークプロセッサメモリに格納される。
【００８３】
マルチメディアルータ１１８の監視も行われる。監視方法の一例には、簡易ネットワーク管理プロトコル（ＳＮＭＰ）を介してアクセス可能な管理情報ベース（ＭＩＢ）を１組サポートするマルチメディアルータを含む。当該技術で周知のように、ＭＩＢは、ネットワークマネージャがアクセス可能なネットワーク要素の管理項目を決定する。マルチメディアルータ１１８の監視はまた、イベントメッセージを介してマルチメディアルータ１１８から監視情報を収集するセッションルータによって行われる。イベントメッセージは、フロー上でイベントが発生したときに生成される。例えば、フローが中断されたり、ジッタが管理者の定義する許容限界を超えて増加すると、イベントが生成されセッションルータに転送される。必要であれば、セッションルータがイベントを使用して、トラフィックをリルーティングしてもよい。
【００８４】
図６は、マルチメディアルータ１１８（図１）の可能な実装のアーキテクチャ、機能性、及び動作と、ＲＴＰデータフローパケットがリルーティングシステム１０２を通過する際にパケットが受ける個々の処理ステップを示すフローチャートである。これにおいて、各ブロックは、指定された論理関数を実施する実行可能な命令を１以上含む、コードのモジュール、セグメント、または一部を示す。ただし、別の実装では、ブロックに示される関数が示される順番でなく発生するものもある。例えば、以下に明らかになるように、含まれる機能により、連続して示される２つのブロックが実際ほぼ同時に実行されたり、時々逆の順番で実行されたりする。
【００８５】
ブロック３０２に示されるように、ＲＴＰフローデータパケットがマルチメディアルータ１１８（図１）で受信されると、レイヤ２／マルチメディアアクセス制御（ＭＡＣ）処理が行われる。レイヤ２／ＭＡＣ処理では、これに限らないが、リンクプロトコルヘッダ等のレベル２ヘッダまたは、レイヤ２ヘッダが受信されたデータパケットから削除される。リンクプロトコルヘッダの例としては、これに限らないが、イーサネット（登録商標）ヘッダやＨＤＬＣヘッダが挙げられる。レイヤ２ヘッダが削除されるので、データパケットのレイヤ３ヘッダがマルチメディアルータ１１８（図１）によって検査される。当該技術で周知のように、レイヤ３ヘッダは、セッションルータにより割当てられるかまたはマルチメディアルータ１１８（図１）に直接割当てられる、ＩＰソース及びデスティネーションアドレスとＩＰソース及びデスティネーションポートとを含む。次に、ＲＴＰフローデータパケットが適当に形成され妥当であることを確認するため、標準的なＩＰ処理を行って、レイヤ３ヘッダの妥当性が検査される。当該技術者らには、ＩＰ処理にどのようなプロセスが含まれるかが分かるので、このプロセスの更なる論議はここでは行わない。
【００８６】
ブロック３０４に示されるように、レイヤ２／ＭＡＣ処理が行われた後、フロー処理が行われる。図７はフロー処理の詳細を示すフローチャートである。ブロック３５２に示されるように、フロー処理では、パケットのソース及びデスティネーションのＩＰアドレスとポートとが求められる。好ましくは、ネットワークアドレスの変換技術を用いて、フローの方向を決定する。ＲＴＰデータパケットフローは２つの異なる方向、すなわち、クライアントからマルチメディアルータ１１８（図１）へのアウトバウンド及びマルチメディアルータ１１８（図１）からクライアントへのインバウンドに流れる。
【００８７】
パケットのソース及びデスティネーションのＩＰアドレスとポートとが識別されると、ネットワークプロセッサにフロー・トランスフォーム・レコード（ＦＴＲ）が存在するかについて判定する（ブロック３５４）。本発明の好ましい実施形態によると、ＦＴＲは、新しいフローが判定される都度、セッションルータによって継続して更新される。或いは、ＦＴＲは、所定のタイムリミット後に間隔をおいて更新してもよい。また、ＦＴＲの更新は、マルチメディアルータ１１８（図１）によって直接行われる。ＦＴＲを更新する別の方法を使用してもよい。
【００８８】
ブロック３５６に示されるように、ＦＴＲが存在する場合、ネットワークプロセッサ１５８（図３）は、セッションルータにより定義されるように、ＦＴＲを検索する。ただし、ＦＴＲはソース、デスティネーション、またはソース、デスティネーション双方のアドレスを変換すべきか指示する。さらに、ＦＴＲは、マルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）タグをＲＴＰデータパケットに挿入すべきかを指示する。好ましくは、しかし、必ずではないが、ＦＴＲを検索するのに連想記憶装置（ＣＡＭ）を使用する。ＣＡＭは直接ＦＴＲを返したり、ネットワークプロセッサ１５８（図３）に設けられたテーブル内のアドレスを返す。このようなテーブルの例としては、シンクロナス・ダイナミック・ランダムアクセスメモリ（ＳＤＲＡＭ）テーブルがある。
【００８９】
しかし、ネットワークプロセッサ１５８（図３）にＦＴＲ項目が無い場合に、例外としてパケットを廃棄したり、パケットをホストプロセッサ１６４に転送して処理する（ブロック３５８）。つまり、ＦＴＲを持たないパケットついては、ホストプロセッサ１６４に転送され、ホストプロセッサ１６４により一連の動作以外の動作が行われ、ネットワークプロセッサ１５８でパケット転送が行われる。これらの動作には、パケットのソース及びコンテンツのロギング及び／または管理システムへの通知が含まれる。ブロック３６２に示されるように、一度パケットに対しルックアップが行われた後、パケットはチェックされＲＴＣＰパケットであるか判定される。パケットがＲＴＣＰパケットである場合、さらにパケットに対して処理が行われる（ブロック３６４）。ＲＴＣＰパケットの処理には、ジッタ及びパケットロスの統計値と、待ち時間を求めるための送り側タイムスタンプの抽出が含まれる。しかし、パケットがＲＴＣＰパケットで無い場合、パケットは、以下に示す図６で記述されるフローの中で処理が続けられる（ブロック３６６）。
【００９０】
図６に戻って参照すると、フロー処理が行われた後（ブロック３０４）、マルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）タグの削除が行われる（ブロック３０６）。本発明の好ましい実施形態によると、ＭＰＬＳタグの削除は、ＦＴＲで指定された場合にネットワークプロセッサ１５８（図３）によって行われる。
【００９１】
ブロック３０８に示されるように、ＭＰＬＳタグの削除が行われた後、ネットワークアドレス変換（ＮＡＴ）とポートアドレス変換（ＰＡＴ）が行われる。ＮＡＴ処理及びＰＡＴ処理で、ＲＴＰデータフローパケットはさらに調べられる。次に、セッションルータによって与えられるパラメータに応じて、ＲＴＰデータフローパケットにおいて、ソースアドレス、デスティネーションアドレス及びポートアドレスの変換が行われる。好ましくは、ただし必ずではないが、上述のアドレスを各々格納及び保持するためにネットワークプロセッサメモリに別々のテーブルを設ける。
【００９２】
本発明の好ましい実施形態によると、次にマルチメディアルータにより転送の決定がなされる（ブロック３１２）。マルチメディアルータ１１８（図１）内に２以上のリンクがある状況に適合するような、転送の決定を行うオプションが提供される。フローをＩＰ転送用に構成しない場合、セッションルータはＦＴＲの接続情報において静的転送インタフェースを構成している。要するに、ＲＴＰデータパケットは、ＩＰルーティングテーブルを使用して通信システム外にルーティングされてもよく、これにより、動的転送特性が提供される。または、「ルーティングせず」を指定することができ、該パケットは特定リンクに送出される。
【００９３】
ブロック３１４に示されるように、次に、受信したＲＴＰデータフローパケットに従いトラフィック測定が行われる。トラフィック測定手順の詳細説明は、フロー品質管理エンジン１６２（図３）の記述を参照して上記で行った。トラフィック測定で測定される各統計値、すなわち、待ち時間、ジッタ、脱落パケット処理の統計値は、ネットワークプロセッサメモリに格納される。
【００９４】
ブロック３１６に示されるように、次にサービス品質（ＱｏＳ）特性をＲＴＰデータフローに適用する。ＱｏＳ特性を使用することにより、高級なＲＴＰデータパケットフローと、フロー毎のポリシング及びシェーピングを提供することで帯域幅の保証とを可能にする。
【００９５】
本発明の好ましい実施形態によると、次に、ＲＴＰデータパケットの細分化が行われる（ブロック３１８）。細分化は、マルチメディアルータ１１８（図１）を経由するＲＴＰデータパケットのサイズを小さくするために、マルチメディアルータ１１８（図１）により行われる。例として、ＲＴＰデータパケットがマルチメディアルータ１１８（図１）に入ったとき、パケットが既に最大伝送単位（ＭＴＵ）サイズある場合、デスティネーションエンドポイントに送信する前に細分化する必要がある。このプロセスには、ＩＰヘッダの複製、細分化フラグの設定、及び／またはパケット間のペイロードの分割が含まれる。
【００９６】
ブロック３２２に示されるように、次に、マルチメディアルータ１１８（図１）によってレイヤ２／ＭＡＣのカプセル化が行われ、マルチメディアルータ１１８（図１）から送信される前に、データリンク（レイヤ２）ヘッダがＲＴＰフローパケットに再度付加される。
【００９７】
本発明の上記実施形態、つまり、いずれの「好ましい」実施形態も、単に本発明の原理の明確な理解のために述べられた単に可能な実装例であることを強調する。本発明の上記実施形態に対し、本発明の趣旨及び原理をほぼ逸脱することなく多数の変形及び変更が行われ得る。このような変形や変更は全て本明細書及び本発明の範囲内に含まれ、以下の請求項によって保護される。
【図面の簡単な説明】
本発明は、以下の図面を参照するとより理解できる。図面の構成要素は必ずしも同一の縮尺ではなく、本発明の原理を明確に説明するために強調されている。また、図中、同様の参照番号は、複数の図を通じ対応する部品を示す。
【図１】図１は、本リルーティングシステムが実施される通信ネットワークを示すブロック図である。
【図２】図２は、本発明の別の実施形態による、図１に示される２台のマルチメディアルータの代わりに３台のマルチメディアルータを使用する場合を示すブロック図である。
【図３】図３は、さらに図１及び図２に示されるマルチメディアルータの１台を示すブロック図である。
【図４】図４は、図３のマルチメディアルータにより実行されるフロー中断検出を示すために、通信ネットワークの一例を提示するブロック図である。
【図５】図５は、ＲＴＰデータパケットの高速ルーティングに使用される負荷分担構成を示すブロック図である。
【図６】図６は、ＲＴＰデータフローパケットが本リルーティングシステムを通る際に受ける具体的な処理ステップに加え、図３のマルチメディアルータの可能な実装形態のアーキテクチャ、機能性、及び動作を示すフローチャートである。
【図７】図７は、更に図６のフロー処理ステップを示すフローチャートである。

Claims (3)

1. 第１のエンドポイントと第２のエンドポイントとの間の、リアルタイム・トランスポート・プロトコルのデータフローについて待ち時間を求める方法において、
   前記第１のエンドポイントと前記第２のエンドポイントとの間に設けられたメディアルータが送信した送信側レポートを受信した前記第１のエンドポイントが送信した第１の受信側レポートを、前記メディアルータで受信することと、
   前記メディアルータが前記第１の受信側レポートを受信した第１の受信時刻を決定することと、
   前記第１の受信時刻から、前記第１のエンドポイントが最後に受信した前記送信側レポートのタイムスタンプ（ＬＳＲ）及びＬＳＲからの遅延時間（ＤＬＳＲ）を引いて、前記メディアルータと前記第１のエンドポイントとの間の第１の往復の待ち時間を求めることと、
   前記メディアルータが送信した前記送信側レポートを受信した前記第２のエンドポイントが送信した第２の受信側レポートを、前記メディアルータで受信することと、
   前記メディアルータが前記第２の受信側レポートを受信した第２の受信時刻を決定することと、
   前記第２の受信時刻から、前記第２のエンドポイントが最後に受信した前記送信側レポートのタイムスタンプ（ＬＳＲ）及びＬＳＲからの遅延時間（ＤＬＳＲ）を引いて、前記メディアルータと前記第２のエンドポイントとの間の第２の往復の待ち時間を求めることと、
   前記第１の往復の待ち時間及び前記第２の往復の待ち時間から、前記第１のエンドポイントと前記第２のエンドポイントとの間のデータフローについての待ち時間を求めること
   とを備えることを特徴とするリアルタイム・トランスポート・プロトコルのデータフローについて待ち時間を求める方法。
2. 第１のエンドポイントと第２のエンドポイントとの間の、リアルタイム・トランスポート・プロトコルのデータフローについて待ち時間を求めるシステムにおいて、
   前記第１のエンドポイントと前記第２のエンドポイントとの間に設けられ、送信側レポートを送信し、前記送信側レポートを受信した前記第１のエンドポイントが送信した第１の受信側レポートを受信し、
   前記第１の受信側レポートを受信した第１の受信時刻を決定し、
   前記第１の受信時刻から、前記第１のエンドポイントが最後に受信した前記送信側レポートのタイムスタンプ（ＬＳＲ）及びＬＳＲからの遅延時間（ＤＬＳＲ）を引いて、前記第１のエンドポイントとの間の第１の往復の待ち時間を求め、
   前記送信側レポートを受信した前記第２のエンドポイントが送信した第２の受信側レポートを受信し、
   前記第２の受信側レポートを受信した第２の受信時刻を決定し、
   前記第２の受信時刻から、前記第２のエンドポイントが最後に受信した前記送信側レポートのタイムスタンプ（ＬＳＲ）及びＬＳＲからの遅延時間（ＤＬＳＲ）を引いて、前記第２のエンドポイントとの間の第２の往復の待ち時間を求め、
   前記第１の往復の待ち時間及び前記第２の往復の待ち時間から、前記第１のエンドポイントと前記第２のエンドポイントとの間のデータフローについての待ち時間を求めるメディアルータ
   を備えることを特徴とするリアルタイム・トランスポート・プロトコルのデータフローの待ち時間を求めるシステム。
3. 第１のエンドポイントと第２のエンドポイントとの間の、リアルタイム・トランスポート・プロトコルのデータフローについて待ち時間を求めるシステムにおいて、
   前記第１のエンドポイントと前記第２のエンドポイントとの間に設けられたメディアルータと、
   前記メディアルータに格納され、前記メディアルータにより実行される関数を定義するソフトウェアと、
   前記ソフトウェアによって構成され、前記メディアルータが送信した送信側レポートを受信した前記第１のエンドポイントが送信した第１の受信側レポートを、前記メディアルータで受信することと、
   前記メディアルータが前記第１の受信側レポートを受信した第１の受信時刻を決定することと、
   前記第１の受信時刻から、前記第１のエンドポイントが最後に受信した前記送信側レポートのタイムスタンプ（ＬＳＲ）及びＬＳＲからの遅延時間（ＤＬＳＲ）を引いて、前記メディアルータと前記第１のエンドポイントとの間の第１の往復の待ち時間を求めることと、
   前記メディアルータが送信した前記送信側レポートを受信した前記第２のエンドポイントが送信した第２の受信側レポートを、前記メディアルータで受信することと、
   前記メディアルータが前記第２の受信側レポートを受信した第２の受信時刻を決定することと、
   前記第２の受信時刻から、前記第２のエンドポイントが最後に受信した前記送信側レポートのタイムスタンプ（ＬＳＲ）及びＬＳＲからの遅延時間（ＤＬＳＲ）を引いて、前記メディアルータと前記第２のエンドポイントとの間の第２の往復の待ち時間を求めることと、
   前記第１の往復の待ち時間及び前記第２の往復の待ち時間から、前記第１のエンドポイントと前記第２のエンドポイントとの間のデータフローについての待ち時間を求めること
   を実行するプロセッサ
   とを備えることを特徴とするリアルタイム・トランスポート・プロトコルのデータフローの待ち時間を求めるシステム。

Images