JP2000508145A - 動的なトラフィック調整 - Google Patents

Abstract

(57)【要約】 マルチメディア・ネットワークは、データストリームにネットワーク接続に対してあるサービス品質が与えられることを要求するが、この種の事前交渉は典型的な現在のデータ・ネットワーキングと合わない。データ・ネットワークにおけるリアルタイム・トラフィック・フローは、遅延の許容範囲および遅延の変動にはっきりした制限を必要とする。対話型音声およびビデオは、人間との対話が容認しがたいほど損なわれない境界を合計遅延時間超えないことを要求する。この発明は、ネットワークが各トラフィック・フローのサービスの性質を発見し、動的にそれを分類して、トラフィックを下流に送るとき、受け入れ制御およびスケジューリングの手法によってトラフィック調整を実行することを可能にする。

Description

【発明の詳細な説明】 動的なトラフィック調整 発明の属する技術分野 この発明は、データ・ネットワークのノードにおけるトラフィックの調 整に関する。特に、割り当てられたクラスまたはネットワーク作業者のようなネ ットワーク管理者によって指定されたサービス品質（QOS）に従って、トラフィ ックがノードで動的に分類され、下流に送られる技術に関する。 背景技術 マルチメディア・ネットワークは、データ・フローがネットワーク連結 に対してなんらかのサービス品質を与えられることを必要とする。ＩＰ(およびA TMネットワークの中での信号法)のために最近提案されたリソース・リザーブ・ プロトコル(RSVP)）は、特定のサービス品質を要請する方法であるが、この種類 のプレ折衝は、現在のデータ・ネットワーキング・モデルにとってなじみがなく 、そして、アプリケーション・レベルで変更を必要とする。 データ・ネットワークにおける異なるサービス品質に対する要求の後に ある主な要因は、遅延の許容範囲およびその遅延の変動にはっきりした限界を持 つ実時間フローを導入する必要性である。対話的な音声およびビデオは、人間の 対話が容認しがたく損なわれる限界を合計遅延時間が上回らないことを要求する 。リアルタイムで転送中の非対話的な音声およびビデオの流れは、最大遅延変化 が制限されるので、バッファを合理的なサイズに保ち、アンダーフローしないよ う保証することができる。リアルタイム・フローのための遅延条件に合うことは 、通常、これらのフローが他のトラフィックに対して優先度を与えられなければ ならないことを意味する。これは、他のクラスのトラフィックもバンド幅のいく らかを得ることを確実にするために、なんらかの受け入れ制御策によってそのよ うな高優先度トラフィックの総計を制限する必要性をもたらす。 音声およびビデオ以外にも制御された待ち時間から利益を得ることがで きるアプリケーションがある。DNSトランザクションのようなネットワーク制御 トラフィックは全体のうちの小部分を表すが、優先的に扱われるならば、非常に 改善されたパフォーマンスを提供する。 音声またはビデオのようなきつい条件を持たないが、コンピュータと人 間の対話を含み、長い遅延を受けると、生産性の際だった減少（またはフラスト レーションの増加）に至るもう一つのクラスのトラフィックがある。このトラフ ィック・タイプはX Window、テルネット(Telnet)、ワールドワイド・ウェブ（WW W）ブラウザのようなアプリケーションによって生成される。このトラフィック は、出力スケジューリング策の一部として保証されたバンド幅の一部を割り当て られることによって、FTPまたはNFSのようなバルク性転送に起因する長い待ち行 列遅延から保護される。 バルク性トラフィックさえ、あまりにたくさんの競合で苦しむことがあ る。ファイル転送は、しばしば多くのネットワーク資源を使った後にアボート（ 中途終了、異常終了）される。その理由は、全体の時間がアプリケーション、ユ ーザー、または中間サーバーの管理策の遅延許容範囲を超えることである。また 、ふくそうによってパケットが落とされるとき、それは簡単に多数のフローに衝 撃を与え、多くの再送を生じる。ある数のフローに最小帯域幅を保証し、残りを 最善の努力で取り扱うことにより、多数フローにわたるパケット・ロスの広がり を避け、アボートされるフローの数を減らすことが可能である。 サービス品質条件が信号法の必要性なくしてネットワークによって自動 的かつ動的に満足されるならば、それはより受け入れられやすい。これは、より 自然に現在のIPネットワーキング・パラダイムに適合する。 伝統的に、インターネット・サービス（FTP、テルネット、NFSのような ）は終端システムにだけ知られており、ネットワーク自身には知られていない。 この発明によって、ネットワークが各トラフィック・フローについてサービスの 性質を発見することができ、動的にそれを分類し、適切にサービスを支えるため にトラフィックを下流に送るとき、受け入れ制御とスケジューリングのような手 法によってトラフィック調整を実行することができる。スケジューリングは、優 先度によってリアルタイム・トラフィックを他のトラフィックから切り離し、ト ラフィックのいろいろなクラスの間でバンド幅を割り当てる。スケジューリング に関連して、受け入れ制御は、パフォーマンスを保証する。スケジューリングに よるオーバーレイ管理策の実行は、たとえばあるグループに他のグループとは異 なる扱いを与えることができる。分類は、予め交渉されたネットワーク接続の影 響を正確にエミュレートすることを必要としないが、ユーザーおよびネットワー クに見えるサービス品質に同様の改良を提供しなければならない。 この明細書においてデータ・ネットワークは、ATMネットワークを含む いかなるパケット・ベースのまたはセル・ベースのネットワークをも含むことが できることに注意しなければならない。 したがって、この発明の目的は、データ・ネットワークのノードで動的 にトラフィックを調整する方法および装置を提供することである。 この発明の更なる目的は、トラフィックを連続的に監視し、一組の分類 パラメーターに従って複数のプリセット・クラスのうちの１つに動的に分類する 方法および装置を提供することである。 発明のもう一つの目的は、動的に選ばれたクラスによって指定されるサ ービス品質パラメータに従って下流へのトラフィックの受け渡しを制御するため の方法および装置を提供することである。 発明の開示 簡単に述べると、発明は一つ以上のノードを持つマルチメディア・トラ フィックのためのパケット・データ・ネットワークにある。１つの面によると、 トラフィックを動的に調整する方法は、そのトラフィック特性に関してノードで 連続的にトラフィックを監視し、トラフィック特性についての予め設定した基準 に従ってトラフィックを複数のクラスのうちの１つに分類するステップを含む。 この方法は、複数のクラスうちの１つによって指定したサービス品質に従ってト ラフィックを下流に送るステップを含む。 もう一つの面によると、この発明はトラフィックを動的に調整する方法 に向けられている。この方法は、リアルタイム・トラフィック・フローを見つけ るためにトラフィックをノードで連続的に監視し、リアルタイム・トラフィック ・ フローが下流への送出のために受け入れられるかどうかをデータ・ネットワーク の有効バンド幅に基づいて判断するステップを含む。この方法は、下流に送るた め、異なるクラスによって指定されるサービス品質に従ってリアルタイム・トラ フィックを異なるクラスに再分類するステップを含む。 図面の簡単な説明 図１は、発明の実施例のトラフィック・コンディショナーの回路図であ る。 図２と３は、発明のトラフィック・コンディショナーの可能な位置を示す。 図４は、発明のトラフィック調整機能がルーターまたはスイッチでイン ストールされることができることを示す。 図５は、状態遷移を示す。 図６は、下流に伝播されている分類情報を示す。 図７は、REJECT情報が前方にパスされ、ソース・ホストに反映されるこ とを示す。 図８は、停止通報がノードから上流に送り出される環境を示す。 発明の実施の形態 図１を参照して、トラフィック・コンディショナーは、発明の１つの実 施例に従って、複数の待ち行列10（各クラスについて少なくとも1）を含む。そ れは、データ・ネットワークのノードにある。入力ストリームのあらゆるパケッ トは、例えばIPアドレス、ポートとプロトコルを使って調べられて12で識別され る。コントローラ14は、（レート、期問、その他を使って）フローの特性を表し 、それにクラスを割り当てる。複数のクラスについては、後述する。コントロー ラは、データベース16を参照し、出力スケジューリングを使用してクラスの間で バンド幅を割り当て、下流側ノードまたは周辺装置に出力ストリームを送る前に 、クラスのための受け入れ制御策を実行する。それは、認められないフローから のパケットを捨てて、下流側ノードにフロー分類をパスする。 この発明のトラフィック調整は、データ・ネットワーク中のいろいろな 場所で行われることができる。例えば、ゲートウェイがたびたびボトルネックで あり、対話的なユーザーのためのバルク性フローが応答時間を減少させるので、 トラフィック・コンディショナーは、この問題を軽減するよう図２に示される場 所にあることができる。図３において、トラフィック・コンディショナーは、デ ータ・ネットワーク40を形成する複数のIPスイッチに位置する。パケット・スイ ッチは、トラフィック調整が実行されない限り、リアルタイム・ビデオのような 新しいサービスのためによいパフォーマンスを提供することができない。コンデ ィショナーは、スイッチ42の出力ポートでスイッチに入り、この出力ポートから 下流側ノード44に出る全てのトラフィックをモニタおよび制御する。統合トラフ ィック調整機能は図４に示されるルーターまたはサーバーにインストールされる ことができる。 IPネットワーキングの１つのインスタンスにおいて、個々のトラフィッ ク・フローを識別することは、単純である。それは、送信元と宛て先のアドレス およびプロトコル・ポート番号の検査を必要とするだけである。この方法が、TC P経路制御とかIPスイッチングのような他のアプリケーションで使われている。 違う処理のためにフローを特徴付け分類するいかなる手法も、特定の動 作環境に合うよう修正ができなければならない。１つの実施例によると、典型的 なTCP/IPベースのネットワークで使用されるトラフィック・フローについて次の ６つのクラスが考えられる。 （クラス1）対話的なユーザー(TCP) このクラスは、X-ウィンドウ、テルネットおよび軽量のウェブ・ブラウ ジングのようなアプリケーションのためにTCPフローを捕らえる。テルネットと Ｘウィンドウは、非常に長いセッションでありえるが、主に短いパケットを持つ 。この実施例での分類において、ショート（短い）パケットは128バイト以下、 ロング（長い）パケットは128バイト超と定義する。ウェブ・ブラウジングは、 パケットサイズとトランザクション長さの混合を含んでおり、特に画像ファイル をロードする間、ロングパケットのフローを引き起こすことがある。このクラス は、TCPフローのデフォルトであるが、フローが２つ以上のショートパケットの シリーズを間に含まないロングパケットの長いシリーズ（例えば200）を含むと き、それはバルク転送であると考えられ、このクラスにとってもはや妥当でない 。TCPバルク・フローは時折ショート・パケットを含むことがあり、TCP ACKメッ セージだけまたは送信バッファのテールエンド含だけを含むことがある。このよ うにショート・パケットが２以上のシリーズでない限り、フローは依然としてバ ルク転送であると考えられる。 （クラス2）保証されたバンド幅でのバルク転送（TCP） TCPトラフィックが対話的でないならば、それはバルク転送として分類 される。バルク転送フローの一部は、バンド幅の保護された部分および限られた 数のメンバを持つスケジューリング・クラスに受け入れられ、これらのフローに はそのようないくらかの最小帯域幅が保証される。 （クラス3）バルク転送、最善の努力（TCP） 保証されたバンド幅クラスに受け入れられないバルク性TCPフローは、 このクラスにおいて最善の努力という基準で取り扱われる。クラス(2)と(3)は、 大きいFTPまたは大きいウェブ・イメージを取り扱うことを意図している。 （クラス4）小待ち時間（UDP） このクラスは、非常に小さいバンド幅を必要とするフローを含む。一般 に、これらのフローは、低バンド幅音声、NFS要求、ショートNFS応答およびDNS トランザクションのようなネットワーク制御パケットから成る。大部分のリアル タイム音声は、一秒につき20未満のパケットでの連続するフローUDP（User Data gram Protocol）である。これはUDPのデフォルトのクラスであり、限界バンド幅 より上のフローは速く外に動かされる。このクラスのための割当バンド幅が使い 果たされるならば、新しいフローが最善の努力のクラスに動かされるような受け 入れ制御方策がある。 （クラス5）リアルタイム（UDP） 下で定義されるリアルタイム特性、および小待ち時間クラスにとっては 大きすぎるバンド幅を持つフローは、このクラスで捕らえられる。高帯域音声お よびストリーミングビデオは、期待されるメンバである。例えば、ビデオは最高 4Mb/s=（1000pps）までの連続するUDPフローである。リアルタイム特性を示して いるが受け入れ制御策の下でリソースがないフローは、拒絶され後続のパケット は捨てられる。 （クラス6）バルク最善の努力（UDP） 全ての他のUDPフローは、このクラスに分類される。期待されるメンバ は、相当なレートの多数のロングパケットによって特徴づけられるNFSファイル コピーおよびバックアップ・セッションである。 要約すると、この実施例に従うと、トラフィック・タイプの間の区別は 、パケット到着率とパケット長さの単純な解析および下で記述されるリアルタイ ムUDPトラフィックに対する特定のテストに基づく。フローの特性は連続的にモ ニターされ、フローはその寿命の間、再分類されることができる。再分類する能 力は、連続フローが同じアイデンティティをとるが、異なる特性を持つケースを カバーする。 サービスタイプを判断するため、あるインスタンスにおけるポート番号 情報を使い、上述した動的な分類を補完することが可能である。例えば、TCPポ ート23は、テルネット・サーバーについて周知のポートである。テルネット・セ ッションが常に対話的なトラフィックを運ぶので、そのポート番号のうちの１つ が23であるTCPフローを対話的なTCPとして分類することができる。しかし、単一 ポート番号を性質の異なる複数のサービスのために使うことができる。たとえば 、ＨＴＴＰサーバーのために確保されたTCPポート番号80を、対話的なTCPとバル クTCPの両方ために使ってもよい。分類方式は、ポート番号とプロトコル・タイ プのようなパケットヘッダの中の静的な情報および動的に集められる情報を使う のがよい。 図５は、実施例に従ってこれらのクラスを含んでいる状態遷移を示す。 図では、以下の略語が使われている。 p = パケット sp = ショート・パケット lp = ロングパケット con lp = 連続ロングパケット bw = 利用できるバンド幅 chosen = 方策によって選ばれた pps = 秒あたりパケット到着数（packets per second arrival） 以下の基準も、適用される： （a）全てのクラスについて、30秒問パケットがないならば最初に戻る。 （b）全てのフローについて、オプション・フィールドをチェックし、クラスが 定義されるならば、100パケットまたは30秒間フローをそのクラスに強制する。 図５を参照して、ステートマシンは以下の状態を含む： (A) イニシャル (B) TCP対話型 (C) TCPバルク最善の努力型 (D) TCPバルク保証型 (E) UDP小待ち時間型 (F) UDPリアルタイム型 (G) UDPバルク最善の努力型 (H) 拒否 以下の詳細な記述において、「>」は全ての状態について「真」を示す。 パワーアップ 〉[30秒間アイドル]->イニシャル クラス情報が上流から受け取られるならば、100パケットの間その状態を強制す る。 情報のない状態が100パケットまたは30秒間続いた後、ローカルな判断に戻る。 >イニシャル（図５における50） >［Protocol=TCP］−〉TCP対話型 >［Protocol=UDP］−>UDP小待ち時間型 >TCP対話型（52において） >［200の連続ロングパケット、各サイズ>2以上のショート・パケットの シリーズを間に含まない128バイト］ >［いくらかのTCPバルク、最小バンド幅利用可能］ -->TCPバルク保証型 >［さもなければ］ -->TCPバルク最善の努力型 >TCPバルク最善の努力型（54において） >[TCPバルク保証からフローが離れる]、そして[方策によって点検] -->TCPバルク保証型 >［128バイト以下のサイズの２つの連続ショート・パケット］ -->TCP対話型 >TCPバルク保証型（56において） >［128バイト以下のサイズの２つの連続ショート・パケット］ -->TCP対話型 >UDP小待ち時間（58において） >［1秒間この状態にあった後、>25パケットが到着した］ -->UDPバルク最善の努力型 あるいは、 >[2以上の連続ロングパケット]、そして[>１秒に５パケット] -->UDPバルク最善の努力 >[バンド幅が知られている]、そして[これ以上利用できるバンド幅はな い] -->UDPバルク最善の努力型 >UDPバルク最善の努力型（60において） >[リアルタイム・テンプレートと一致]、そして[UDPビデオに利用できるバンド 幅] -->UDPリアルタイム型 >［さもなければ］ −>拒否> >[１秒を超えてアイドル]、そして[バンド幅利用可能] -->UDP小待ち時間型 >UDPリアルタイム型（62において） >［300番目のパケットが時間どおり到着<200ms］ -->UDPバルク最善の努力 >［１つの秒のために働いていない］ -->UDP低待ち時間 >拒否（64において） 拒否情報を伝搬するのに使われる以外すべてのパケットを捨てる。リアルタイム・フロー検出 先に述べたように、リアルタイム・トラフィックを他のバルクUDPフロ ーから区別することが必要である。それは、現在の技術水準では、バルク性であ りリアルタイムでない唯一のUDPトラフィックをNFSが表すとみなすのが合理的で ある。すると、簡単な方法は、問題のフローのポート番号を調べることである。 それらのどちらもNFSサーバーのために予約されたポート番号である2049でない ならば、フローはリアルタイムとして分類される。 同じように、関心のあるリアルタイム・フローすべてが予約のポート番 号を持つサーバーを使用するとするならば、それらはポート番号についての静的 な情報によって分類されることができる。今日、大部分のリアルタイム音声とビ デオサーバーは、簡単に認識することができる一組の特別なポートを使うように 思われる。 これらの仮定があてはまらない環境では、リアルタイム・フローを識別 するためにダイナミック方式を提供することが必要である。NFSのようなリアル タイムUDPフローと他のUDPアプリケーションの間の主な相違は、(a)リアルタイ ム・ストリームがセルフクロックされないということであり、すなわち、パケッ トはレシーバからの肯定応答なしで連続的に送り出され、(b)平均パケット発生 率が一定であることである。 リアルタイム・フローを見つけるためにこれらの属性を使う２つの方法 がある。ふくそう条件の下で、リアルタイム・フローの待ち行列は、限界なしで 成長する。ところが、自己計時（セルフクロック）されたフローの待ち行列は、 認められたバースト（肯定応答のない最大バーストは、NFSについて8Kバイトで ある）のサイズまで成長するだけである。もう一つの方法は、フローのパケット について到着の間の時間の履歴を保持することである。自己計時されたフローは 双峰分布を示すが、リアルタイム・ストリームは平均レートのまわりで単峰形で ある。１つの実施例において、この方法は、平均の到着間の時間よりいくぶん大 きい値にセットされるしきい値を使うことによって実行することができる。しき い値の下の到着の間の時間のカウントと、しきい値より上の到着の間の時間のカ ウントの２つのカウントが保たれる。この第２のカウントがある値、たとえば最 初のカウントの10%、より大きければ、フローは非リアルタイムとクラス分けさ れる。ふくそうがストリームを識別するのを待つ必要がないから、この第2の方 法がむしろ好まれるかもしれない。フローの速い受け入れまたは拒否が重要であ る。フローのスケジューリング 交換ノードの出力ポートで多数の待ち行列をスケジュールするのに利用 できるいろいろな手法がある。いずれにせよ、典型的には、上述のリアルタイム かつ小待ち時間のクラスは、絶対優先度（それゆえに、受け入れ制御の必要性） を与えられ、その他のクラスは、それらにネットワーク管理者によって割り当て られるバンド幅の一部分を割り当てる態様でスケジュールされる。 図６を参照すると、更なる実施例において、各ノードが上記の分類を自 律的に実行する代わりに、ルート上の最初のノード（ノードA）がその発見を下 流ノードにパスし、より効率的なトラフィック調整を提供する。また更なる実施 例において、ソースのホストマシンを、トラフィックを分類しルートに沿ったノ ードに分類を送信する最初のノードとみなすことができない理由はない。これら の下流ノードは、ローカルな分類でなく取得した知識を使うことができ、そのパ スを通してフローに一貫した処理を与えることができる。それらは、期限切れに なるまで上流の分類を受け入れ、下流にそれを伝播する。情報はいろいろな方法 において伝播されることができるが、ある方法では、（例えば、IPオプション・ フィールドにおけるエントリーによって）フローの一つ以上のパケットに情報を 挿入することによってフロー中で運ばれることができる。第ｎ番目のパケットご とに情報を運ぶことができ、下流ノードは、複数のｎパケットの後、その情報が 古くなるまでその情報で作用する。ATMベースのネットワークでは、分類はその フローのために選ばれるVPI/VCI値によって暗示されうる。 図７を参照すると、分類拒否は、接続先ホストから、ソース・ホストへ 反映され、ネットワークの効率を改善することができる。これを容易にするため に、フローからの全てのパケットが捨てられるというわけでない。その代わりに 、k番目ごとのパケットが、オプション・フィールドでの分類で前方へパスされ る。例えば、ノードのＢは、パケットがなんらかの理由で拒絶しなければならな いことを判断し、k番目ごとのパケット以外の全てを捨て、k番目ごとのパケット が接続先ホストに転送される。そして、接続先ホストは転じてソース・ホストに 停止のメッセージを送る。図８で示されるもう一つのシナリオにおいては、ホス トではなく、なんらかの理由でトラフィック・ストリームを拒絶するノードが、 トラフィックが拒絶され、したがって、停止しなければならないこと示すメッセ ージを上流に送ることができる。複雑さ 異なるサービス品質がサポートされているいかなるネットワークにおい ても、フロー属性を分類するいくらかの処理と、フローが属性に準拠しているこ とを確かめる方法がなければならない。この検証すなわちポリーシング （policing）は、サブネットのエッジまたはあらゆるノードで実行することがで きる。ここで記述される方法は、フロー属性を発見するための検証に適当である メカニズムを使うが、信号法のようなプレ折衝（事前の交渉）は必要としない。 それは、したがって、ノードでの実行において同等の複雑さを持つが、信号法の オーバーレイを必要としない。 いろいろなクラスにバンド幅割当てする方策のために必要な管理上のオ ーバーレイ、および予め予約されたビデオ・セッションのためのバンド幅の予約 は、複雑さにおいて信号法に基づくシステムともはや異ならない。RSVP および管理された接続との共存 動的な分類は信号法を必要とすることなく走ることができるけれども、 より高水準のプロセスの結果としてフローの分類を強制することも可能である。 信号法または管理によってネットワークに予約されたパスおよび取り扱いを与え られたフローは、そのようにマークされることができる。自動分類を使用禁止に したり使用したりしてマークされたフローの特性を確認することができる。 この発明によると、異なる取り扱いにグループ分けするためにパケット ・トラフィック・フローが分類される。アプリケーションの信号法サポートが利 用できないときでも、これはサービス品質の区別がサポートされるのを可能にす る。実行は、信号法が使われるとき、ポリーシングのために必要なより複雑でな く、知覚されたネットワーク性能を改善しビデオのような新しいサービスを可能 にするのに効果的であるかもしれない。

【手続補正書】 【提出日】１９９９年７月２７日（１９９９．７．２７） 【補正内容】 請求の範囲 1.１つまたは複数のノード（４２，４４）を持つマルチメディア・トラフィック のためのパケット・データ・ネットワークにおいてトラフィックを動的に調整す る方法であって、 上記ノード（４２，４４）またはトラフィックのディジタル・フローを 生成するソース・ホストにおけるフロー特性に関しトラフィックのディジタル・ フローを継続的にモニターするステップ（１２）と、 上記ノード（４２，４４）またはソース・ホストにおいて、トラフィッ クのディジタル・フローをフロー特性（１６）の予めセットされた基準に従って 複数のクラスの１つに分類するステップ（１４）と、 を含み、上記複数のクラスがトラフィックのディジタル・フローを条件づける サービスの品質のそれぞれのレベルを指定する、トラフィックを動的に調整する 方法。 ２．上記予めセットされた基準がトラフィックのディジタル・フローのプロトコ ル・タイプであり、該プロトコル・タイプは、伝送制御プロトコル(TCP)、およ びユーザ・データグラム・プロトコル（UDP）である、請求項１に記載の調整方 法。 ３．上記分類するステップは、TCP対話（５２）およびUDP小待ち時間（５８）の ２つのデフォルト・クラスに分類するステップを含む請求項２に記載の調整方法 。 ４．上記TCP対話クラス（５２）をTCPバルク保証（５６）およびTCPバルク最善 努力（５４）のどちらか１つに変更するステップを含む請求項３に記載の調整方 法。 ５．上記変更するステップは、トラフィックが２以上の短いパケットの介在なし に一連の長いパケットを含むときに実行される請求項４に記載の調整方法。 ６．上記UDP小待ち時間クラス（５８）をUDP実時間（６２）およびUDPバルク最 善努力（６０）のどちらか一方に変更するステップを含む請求項３に記載の方法 。 ７．上記継続的モニターするステップによって実時間のトラフィック・フローが 検出されるとき、データネットワークの利用可能なバンド幅に基づいて、該実時 間のトラフィック・フローを下流に配信してよいか判断するステップと、 異なるクラスによって指定されるサービス品質にしたがって、条件付けのため 上記実時間トラフィック・フローを異なるクラスに最分類するステップと、 を含む、請求項１に記載の調整方法。 ８．上記継続的にモニターするステップは、トラフィックのディジタル・フロー が配信のために記憶されるノードにおける待ち行列の成長の特性をモニターする ステップを含む、請求項７に記載の調整方法。 ９．上記継続的にモニターするステップは、トラフィックの上記ディジタル・フ ローのパケットの到着間の時間の履歴をモニターするステップを含む、請求項７ に記載の調整方法。 １０．請求項７に記載の調整方法であって、 予めセットしたしきい値より小さい到着時間について第１のカウントを記録す るステップと、 上記しきい値より大きい到着時間について第２のカウントを記録するステップ と、 上記第１のカウントが予定量以上上記第２のカウントより大きくなければ、ト ラフィックの上記ディジタル・フローを実時間のトラフィック・フローとして判 断するステップと、 をさらに含む請求項７に記載の調整方法。 １１．上記予めセットした基準の１つがトラフィックの上記ディジタル・フロー の長さである請求項１から３のいずれかに記載の調整方法。 １２．上記予めセットした基準の１つがトラフィックの上記ディジタル・フロー における連続パケットの数である請求項１から３のいずれかに記載の調整方法。 １３．上記トラフィックが使用するポート番号を判断するステップと、 上記ポート番号およびトラフック特性の予めセットした基準に従ってトラフィ ックを複数のクラスの１つに分類するステップと、 をさらに含む請求項１から３のいずれかに記載の調整方法。 １４．上記複数のクラスの１つによって指定されるサービス品質に従ってトラフ ィックの上記ディジタル・フローを下流に送るステップを含む、請求項１から１ ３のいずれかに記載の調整方法． １５．モニターおよび分類の結果を１つまたは複数の下流ノードに知らせるステ ップを含む、請求項１から１４のいずれかに記載の調整方法。 １６．上記サービス品質は、トラフィックの上記ディジタル・フローに割当てら れた配信の優先レベルおよびバンド幅を含む複数のパラメータによって表現され る、請求項１４に記載の調整方法。 １７．上記知らせるステップは、結果に関する情報をトラフィックの上記ディジ タル・フローに挿入されるパケットで伝播させるステップを含む、請求項１５に 記載の調整方法。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＣＡ，ＪＰ (72)発明者 クン・シャン−ツン アメリカ合衆国02173マサチューセッツ州 レキシントン、ジョセフ・コミー・ロー ド １

Claims (1)

1. 【特許請求の範囲】 1.一つ以上のノードを持つマルチメディア・トラフィックのためのパケット・デ ータ・ネットワークにおいてトラフィックを動的に調整する方法であって、 そのトラフィック特性に関してノードでトラフィックを連続的にモニタ ーするステップと、 TCPプロトコル・タイプ、UDPプロトコル・タイプ、トラフィックにおけ るパケットの長さ、およびトラフィックにおける連続パケットの数を含むトラフ ィック特性のプリセット基準に従って、２つのデフォルトのクラス、対話的なTC Pおよび低待ち時間UDPを含む複数のクラスのうちの１つにトラフィックを分類す るステップとを含み、 前記複数のクラスは、トラフィックを条件づけるサービス品質のそれぞれのレベ ルを指定するものであり、 トラフィックが２以上のショート・パケットのシリーズの介入なしで、一連のロ ングパケットを含むならば、TCP対話的なクラスを保証されたTCPバルクおよび最 善努力のTCPバルクのどちらか一方に変更するステップと、 を含むトラフィックの動的調整方法。 2.UDPリアルタイム型とUDPバルク最善努力型のどちらか一方にUDP小待ち時間ク ラスを変更するステップを含む請求項１に記載の方法。 3.前記複数のクラスの一つによって指定されるサービス品質に従ってトラフィッ クを下流に送るステップを含む請求項２に記載の方法。 4.請求項１に記載の方法であって、 トラフィックが使うポート番号を判断するステップと、 TCPプロトコル・タイプ、UDPプロトコル・タイプ、トラフィックにおけるパケッ トの長さ、およびトラフィックにおける連続パケットの数を含むトラフィック特 性のプリセット基準およびポート番号に従って、トラフィックを、対話的TCP および低待ち時間UDPの２つのデフォルト・クラスを含む複数のクラスのうちの １つに分類するステップと、を含み、 前記複数のクラスがトラフィックを条件づけるサービス品質のそれぞれのレベル を指定している、トラフィックを動的に調整する方法。 5.サービス品質が、トラフィックを下流側に送る優先レベルおよびトラフィック に割り当てられたバンド幅を含む複数のパラメーターによって表される、請求項 １に記載の方法。 6.一つ以上の下流側ノードにモニターおよび分類の結果を知らせるステップを含 む請求項１に記載の方法。 7.前記知らせるステップが、 トラフィックに挿入されるパケットに関連した情報を伝播させるステッ プを有する請求項６に記載の方法。 8.一つ以上のノードを持つマルチメディア・トラフィックのためのパケット・デ ータ・ネットワークにおいてトラフィックを動的に調整する方法であって、 トラフィックが生成されるソース・ホストでそのトラフィック特性に関 してトラフィックを連続的にモニターするステップと、 ソース・ホストにおいて、TCPプロトコル・タイプ、UDPプロトコル・タ イプ、トラフィックにおけるパケットの長さ、およびトラフィックにおける連続 パケットの数を含むトラフィック特性のプリセット基準に従って、対話的なTCP および低待ち時間UDPの２つのデフォルト・クラスを含む複数のクラスのうちの １つにトラフィックを分類するステップとを含み、 前記複数のクラスは、トラフィックを条件づけるサービス品質のそれぞれのレベ ルを指定するものであり、 トラフィックが２以上のショート・パケットのシリーズの介入なしで、一連のロ ングパケットを含むならば、TCP対話的なクラスを保証されたTCPバルクおよび 最善努力のTCPバルクのどちらか一方に変更するステップと、 を含むトラフィックを動的に調整する方法。 9.UDPリアルタイム型とUDPバルク最善の努力型のどちらか一方へUDP小待ち時間 クラスを変更するようにした請求項８に記載の方法。 10.複数のクラスの言われた一つによって指定されるサービス品質に従ってトラ フィックを下流に送るようにした請求項９に記載の方法。 11.モニターおよび分類の結果を下流のノードに知らせるようにした請求項８に 記載の方法。 12.トラフィックに挿入されるパケットで関連情報を伝播するようにした請求項1 1に記載の方法。 13．トラフィックが使うポート番号を判断するステップと、 TCPプロトコル・タイプを含むトラフィック特性のポート番号とプリセット基準 、UDPプロトコル・タイプ、トラフィックにおけるパケットの長さとトラフィッ クにおける連続パケットの数に従って、２つのデフォルトのクラスを含む複数の クラスのうちの１つ、対話的なTCPとUDP低待ち時間にトラフィックを分類するス テップと、を含み、 前記複数のクラスが、トラフィックを条件づけるサービス品質のそれぞれのレベ ルを指定する、請求項８に記載の方法。