JP4410408B2 - ネットワーク機器のサービス品質管理方法及び装置 - Google Patents
ネットワーク機器のサービス品質管理方法及び装置 Download PDFInfo
- Publication number
- JP4410408B2 JP4410408B2 JP2000374073A JP2000374073A JP4410408B2 JP 4410408 B2 JP4410408 B2 JP 4410408B2 JP 2000374073 A JP2000374073 A JP 2000374073A JP 2000374073 A JP2000374073 A JP 2000374073A JP 4410408 B2 JP4410408 B2 JP 4410408B2
- Authority
- JP
- Japan
- Prior art keywords
- network device
- information
- qos
- data
- data packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/302—Route determination based on requested QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/302—Route determination based on requested QoS
- H04L45/306—Route determination based on the nature of the carried application
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/60—Router architectures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
Description
【０００１】
【発明の属する技術分野】
本発明は、一般に電気通信ネットワークに関し、詳しくは、データ供給のサービス・レベルに関与するネットワーク機器に関する。更に詳しくは、本発明はネットワーク機器の品質関連属性のリアルタイム調整に関する。
【０００２】
【従来の技術】
ルータやスイッチなどの機器は、ネットワーク（例えば、ＬＡＮやＷＡＮなど）接続用、および一つのネットワークから別のネットワークへのデータグラム転送用に使用される。データグラムは、通信データ（ペイロード）ならびに送信元アドレスと最終的な宛先アドレスとを含む。広く使用されているデータグラムのフォーマットは、ＴＣＰ／ＩＰ（transmission control protocol/internet protocol）フォーマットである。スイッチは、ただ単に到着したデータグラムに含まれる宛先情報に基づき、そのデータグラムを特定の出力ポートへ供給する。同様に、ルータはデータグラムを中間的な宛先へ送信するが、中間的な宛先は最後には最終的な宛先となる。しかしながら、ルータは、トラフィック条件や可用性等の基準に従い、出力ポートを多くの中間的宛先の中から選択することになる。
【０００３】
ネットワークに結合されたホストは、各種のデータを搬送する。データ送信（又はデータフロー）のある種のものは、ネットワークに一定レベルの品質を要求する。一般的な属性は、サービス品質（Quality of Service; QoS）である。例えば、ビデオ・データと音声データの一方又は両方の送信では、ビデオ・コンテンツと音声コンテンツの一方又は両方の円滑なプレゼンテーションを確保するため、一般的にワールド・ワイド・ウェブ（ＷＷＷ）ページ表示用のデータ送信において通常必要とされるよりも高いＱｏＳが必要とされる。これは、特にオーディオコンテンツの場合に言えることである。なぜなら、人の聴感は、ビデオ通信よりもオーディオ通信における劣化に対し非常に敏感なためである。しかしながら、ウェブ・ページを見る場合には、低いＱｏＳに起因するページコンテンツ表示の遅延は我慢することができる。
【０００４】
ＱｏＳは様々な方法で表現され、例えば最小の帯域要求や最大の送信遅延或いはデータフローに必要なメモリ又はバッファ空間の量などが、Ｑｏｓの指定対象とされる。それゆえ、ビデオ会議やその他のリアルタイム・データ通信は、高ＱｏＳを有し、ネットワークに充分な帯域と最小遅延が要求される。特定のデータフローに必要となるＱｏＳを指定することにより、データの送信元又は送信先は満足できる通信路が入手できるかどうかを確認することができる。このようにして、ＱｏＳルーティングでは、必要な資源を欠くリンクを迂回したデータフロー転送が可能となる。
【０００５】
インターネット・プロトコル（ＩＰ）ルータ又はスイッチ（本明細書ではこれらを合わせてネットワーク機器と呼ぶことにする）の一般的な動作環境では、様々な管理タスクの実行中にＱｏＳの設定を調整するシステム管理者が存在する。この代わりに、一組のネットワーク機器を管理する自動管理方式のコントローラが、上記ネットワーク機器によるサービスを受けるドメイン内のトラフィック条件に応じて、ＱｏＳ設定を定期的に調整する場合もある。
【０００６】
図１５に示したフローチャートは、ネットワーク機器におけるＱｏＳ設定を変更するための従来の手法のステップを示すものである。
人間又は自動コントローラのいずれかである管理者は、一般に、メンテナンス・チャンネルを介してネットワーク機器へアクセスする。このチャンネルは、例えばネットワーク機器上のローカル・エリア・ネットワーク（ＬＡＮ）インタフェースの一つであるイーサネット・ポートなどを経由してアクセスされるテルネット（telnet）セッションなどの論理チャンネルとすることができる。これに代えて、ネットワーク機器がＰＣに接続されるシリアルポートなどを備えてもよい。
【０００７】
ＱｏＳ設定を変更するための管理コマンドは、ネットワーク機器に含まれるサービス・ソフトウェアを介して発行される（ステップ１５０４）。上記管理コマンドは、適当なプロトコル規格やコマンド・インタフェース或いはアプリケーション・プログラム・インタフェース（ＡＰＩ）により、ネットワーク機器の内部コントローラへ送られる（ステップ１５０６）。現在の技術では、ＳＮＭＰ（simple network management protocol）のような管理／保守プロトコルが、最も一般的に使用されている。大半の装置は、上記プロトコル・サポートに加え、主として機器独自の特徴をサポートするためのコマンド・インタフェースを備えている。ここで、ネットワーク機器内部のコントローラ計算機は、上記コマンドからＱｏＳパラメータを抽出し、ＱｏＳテーブルの内容を更新する（ステップ１５０８）。このシーケンスはあまり頻繁に実行されるものではなく、一般的には数時間に１回程度かそれより長い間隔で行なわれる。
【０００８】
現在のネットワーク使用方法では、ほとんどのＱｏＳ割り当ては、事前の要求に基づいて行われる。例えば、我々が特定の日の午後１時から午後３時まで電子会議を開催したい場合を想定する。この場合、我々は管理者（人間または計算機）に対して、上記会議に関係するネットワーク機器（必ずしも１対１でなく、複数の地点が関係してもよい）に特定のＱｏＳを割り当てるよう要求を出す。管理者は、電子会議セッションをサポートすべく、ネットワークに午後１時（または１２時５５分）にコマンドを送信するためのトリガ機構をセットする。
【０００９】
将来、ＱｏＳ制御は、前述したように「セッション指向の」時間粒度（granularity）で適用されるのではなく、どちらかと言えば「リアルタイム」粒度で適用されるものと想定される。例えば、ビデオ・データフローの送信中に、コンテンツによっては特定の機器におけるＱｏＳ設定を変更したい場合がある。ビデオでは、主構成が静止画であって帯域要求が小さくなるような（持続時間が数分の）シーンもあり得る。（数時間単位に及ぶことがある）ビデオ・フローの持続時間全体にわたって特定帯域を予約するよりは、ネットワーク資源全体をもっと効率的な方法で活用するため、ＱｏＳをより動的な方法で変更することが望まれる。
【００１０】
しかしながら、このようにデータ送信中にＱｏＳを動的に変更する場合、ＱｏＳ変更のタイミングとデータのフローとがリンクしていない（同期していない）ために問題を生ずる。例えば、画像送信では、送信元サーバから送信先クライアントへの大量の画像データ・パケット通信を必要とする。伝送優先順位を上げようとして画像データ・パケットのストリームの途中でＱｏＳを変更したものと仮定すると、結果的には後から送信される画像データ・パケットが先に送信されたパケットよりも早く到着することがある。このような場合、送信先に到着するパケットのシーケンスが乱れることになる。
【００１１】
送信先サイトは、パケットを受信してバッファリングするための追加ソフトウェアを使用してこれを補償することができる。上記ソフトウェアにより、パケットを再シーケンスすることで、画像は正しく表示される。これに代えて、上記受信ソフトウェアに、表示前に画像全体を蓄えるための非常に大きなバッファを実装することもできる。いずれの場合も、クライアント側ソフトウェアが複雑さを増すことは好ましくなく、性能低下を招く。更に、後者の解決方法は、物理メモリにしても仮想メモリ（ディスク・スワッピングの増加に起因する追加遅延量の増加見込みから性能は更に劣化する）にしても追加メモリが必要となるという問題がある。ビデオ・ストリームの場合、ライブ・ビデオフィードにおける大量のデータとライブ・アクション・ビデオのリアルタイム性のため、ストリーム全体を一括したバッファリングは無理である。こうした状況下では、シーケンスから外れて到着したデータ・パケットは廃棄され、誤ったビデオ画像しか得られないことになる。
【００１２】
ネットワーク機器のＱｏＳを調整する代表的な方式は、既に知られている。例えば、ＩＥＴＦ（Internet Engineering Task Force）で定義された「特殊化サービス（differentiated services）」アーキテクチャは、ＩＰ層パケット・マーキング方式を用いて所望のＱｏＳを伝える。ＩＰヘッダには、特殊化サービス・コードポイント（ＤＳＣＰ）フィールドが含まれる。上記ＤＳＣＰは、ネットワーク機器内で各パケットを特定の伝送優先順位にマッピングするために使用される。ＤＳＣＰの値と伝送優先順位との間のマッピングは、通常、送信開始に先立ってネットワーク管理システムによって設定され、上記マッピングは送信が完了するまで変更されない。この方式には、送信中にマッピングを変更するための機構は存在しない。
【００１３】
「アクティブ・ネットワーク」では、ユーザはデータ・ストリームにカスタマイズされたプログラムを挿入することができる。データ・パケットには、宛先に到達する過程で遭遇する一又はそれ以上のネットワーク機器により実行されるプログラムが含まれる。つまり、ネットワーク・ノードにおけるＱｏＳ動作を制御するために書かれたプログラムをデータ・ストリームに挿入することができる。上記方法に伴う一つの欠点は、パケット内へのプログラムの封入（encapsulation）によって、そのパケットが搬送できるペイロードの量が制限されることにある。アクティブ・ネットワークの多能性と柔軟性は、ＱｏＳにパケット単位の精密な制御をもたらす。しかしながら、この能力は、各ネットワーク機器におけるソフトウェアの実行という犠牲のもとに生まれ、上記余分な処理はネットワーク性能を劣化させる。
【００１４】
現在ＩＥＥＥで定義中のプログラマブル・ネットワークとして知られているネットワーク・クラスでは、ネットワークの資源はソフトウェアの抽象物として表現される。ソフトウェアは、標準化された一組のアプリケーション・プログラム・インタフェース（ＡＰＩ）を用いて、ネットワーク機器と相互作用する。シグナリング・サービスや品質レベルサービスのようなスイッチング機能に関連した資源を抽象化することで、新規サービスの開発と展開を容易にすることがその目標となっている。
【００１５】
【発明が解決しようとする技術課題】
ネットワーク資源のより良い利用と、より柔軟なサービスを供給する一般的なニーズが存在している。ＱｏＳの調整は、能力のあるデータ・サービス・プロバイダにユーザのための資源利用の改善を可能とする。サービス・プロバイダは、データ伝送に対してもっときめ細かな制御を行なうことにより、新規サービスと、より柔軟かつ公平な課金施策の立案が可能となる。こうすることで、例えば、割増し料金を支払ったユーザには、平均的ユーザに通常提供されるであろう帯域よりも広い帯域を割り当てることができる。他の状況では、変化するトラフィック条件に適合すべく、ユーザ間で帯域割り当てを再調整することができる。同様に、ビデオ会議接続のように、多くの資源を必要とする用途の伝送時間を改善するため、必要に応じて送信遅延を制御することができる。上述した利益を実現し得る手法へのニーズが存在している。
【００１６】
【課題を解決するための手段】
本発明は、データ・サービス・プロバイダが、一又はそれ以上のネットワーク機器に情報を通信し、クライアントへの通常のデータ通信中に、ネットワーク機器における少なくとも一つの通信属性を変更する。データ・サービス・プロバイダは、一層効率的にネットワーク資源を割り当てることにより、様々なクライアントに適切なサービス・レベルを割り振ることができる。データ・サービス・プロバイダは、全てのクライアントの間で資源を再割り当てすることで、変化するトラフィック条件に効果的に対応できる。また、追加サービスや一層柔軟な課金施策を開発することができる。
【００１７】
本発明の一態様において、データ供給システムは、一又はそれ以上のネットワーク機器とデータ通信するデータ・サーバを含む。これにより、標的となるネットワーク機器、すなわち、属性を変更しようとするネットワーク機器へ第１の情報が送信される。上記第１の情報の送信は、上記データ・サーバから行なわれる。上記第１の情報は、少なくとも一つの新しいネットワーク機器属性を含み、この属性はネットワーク機器に保存される。次に、上記データ・サーバにより、標的ネットワーク機器に第２の情報が送信される。上記第２の情報は、トリガとして機能し、上記ネットワーク機器を作動させて現在の属性設定を新属性設定に更新する。従って、ネットワーク機器属性の動的なリアルタイム調整が実現できる。
【００１８】
本発明のこの態様によれば、上記第１の情報には、標的ネットワーク機器（群）を識別するためのアドレス情報を含めてもよい。また、第２の情報は、クライアント宛のデータ・パケットに含めることができる。標的ネットワーク機器における上記新属性設定は、新属性設定動作をトリガする上記第２の情報を含んだデータ・パケットの送出に先立って実行される。これに代えて、上記動作が上記第２の情報を含むデータ・パケットの送信後に起きるようにしてもよい。
本発明の別の態様によれば、上記第１、第２の情報のどちらか一方又は両方を、ネットワーク機器によって取り込まれる特殊なデータ・パケットに含めることができる。
【００１９】
本発明の特定の態様によれば、調整中のネットワーク機器属性はサービス品質（ＱｏＳ）設定であり、上記第１の情報がＱｏＳ設定を特定するＱｏＳパラメータを含む。本発明の上記特定態様の一変形例では、上記第１の情報がＱｏＳパラメータのリストを含む。本発明の上記特定態様の別の変形例では、ＱｏＳパラメータのリストが標的ネットワーク機器内で組み立てられ、上記第２の情報が上記ＱｏＳパラメータリストへの索引を含む。
【００２０】
本発明の更に別の態様では、ネットワーク機器が、上記ネットワークからデータ・パケットを受信するための一つのネットワークに接続されたネットワーク回路を含む。また、第１の情報を含む受信データ・パケットの存在を検出するためのデータ・モニタリング回路がある。外部供給された一又はそれ以上のＱｏＳパラメータを受信するために第１のプログラム・コードが装備されており、上記第１の情報の検出に応答し、外部から提供されたＱｏＳパラメータに従って、ネットワーク機器のＱｏＳ設定を変更するための第２のプログラム・コードが装備されている。
【００２１】
【発明の実施の態様】
純粋に本発明の新規な特徴及び利点を説明するための方策として、プログラマブル・ネットワーク上で展開されるネットワーク・サービスについて、本発明の実施例を提供する。代表的実施例において、ネットワーク・サービスは、ビデオ・データを配信する品質多層化ビデオサービス（ＭＱＬＶＳ）モデルに従って提供される。尚、上記ＭＱＬＶＳモデルについては、１９９９年５月に国際電気通信連合の研究グループ１６の会議でＴ．スズキにより発表された「ＩＰネットワーク上のスケーラブルＭＰＥＧ２ビデオ伝送システム」と題する論文において議論されており、その内容については、あらゆる目的のために全面的に本明細書に編入することにする。
【００２２】
図１は、このようなプログラマブル・ネットワークの簡略化されたシステム図である。
ビデオ・サーバ１００は、ネットワーク１０によって、ビデオ・プログラムを様々なクライアント１０４に送信する。上記ネットワーク１０は、ネットワークの世界的な集合体であるインターネットと、ネットワーク機器とからなる。但し、上記ネットワーク１０は、より局所化されたイントラネットであってもよい。上記ネットワークは、ルーティング装置やスイッチング装置を含む多数のネットワーク機器１０２の相互接続によって定義される。ビデオ・サーバ１００の受信側には、クライアント１０４がある。
【００２３】
図２は、ルータ装置１０２の代表的な構成を示す簡略化されたシステム図である。
ルータ機器は、制御部２１０を含んでおり、この制御部２１０は、典型的には、一般のルータ装置に代表されるルータ部２２０から離れて存在するコンピュータである。一つの構成において、制御部２１０はルータ部２２０に隣接して配置される。制御部２１０は、ネットワーク・リンクによってルータ部２２０に接続されたＰＣ又はワークステーションであり、別の実施例では、上記制御部２１０は遠隔地に配置される。更に別の実施例では、単一のコントローラを使用して１台又はそれ以上のルータ部２２０が管理される。
【００２４】
制御部２１０は、アプリケーション・プログラム・インタフェース（ＡＰＩ）２１４の最上部で実行されるサービス・ソフトウェア２１２を含む。ＡＰＩは、サービス・ソフトウェア２１２とコントローラ・ソフトウェア２１６との間のインタフェースを提供する。上記コントローラ・ソフトウェアは、ルータ部２２０と直接通信する。本発明の典型的な実施例において、上記サービス・ソフトウェアは、ビデオコンテンツを配信するためのＭＱＬＶＳモデルに従って、ネットワーク・サービスを提供する。
【００２５】
ルータ部２２０は、ネットワーク１０に結合された一又はそれ以上のネットワーク・インタフェース２２２（例えば、イーサネット・インタフェース）を含む。データ・パケットは、上記ネットワーク・インタフェースによりネットワークに送受信される。ネットワーク・インタフェース２２２は、転送コントローラ２２６を用いて内部バス又はスイッチ２２４に結合されている。各転送コントローラ２２６は、フロー制御テーブル２２７を含んでいる。
【００２６】
ルータは、典型的には、一つの物理ポートについて複数の出力キューを有し、各キューには、互いに質の異なるサービス属性を設定することができる。これらの属性は、集合的にＱｏＳパラメータと呼ばれる。例えば、各キューは、キュー内に置かれているデータ・パケットを送信するための異なる伝送順位を持つことができ、各キューは、互いに異なったパケット廃棄レベルを持つこともできる。フロー制御テーブル２２７は、情報（ＱｏＳパラメータ）を含み、これによって到着データ・パケットの転送用となる各出力キューのＱｏＳ設定が作成される。フロー制御テーブル２２７は、ルータ・コントローラ２２８により維持される。
【００２７】
図１，２に関しては、ネットワーク上に送信するビデオ・プラットフォームとして、ＭＰＥＧ（Motion Picture Experts Group）に規定された標準規格が一般的に使用される。ＭＰＥＧデータ・ストリームでは、ビデオ・データは、Ｉフレーム・データ・パケットとこれに続く複数グループのＢフレーム・データ・パケットとからなるデータユニットにブロック化することができる。Ｂフレーム・データ・パケットの各グループには、Ｐフレーム・データ・パケットが付随しており、これはＢフレームの一つのグループを次のグループから分離するために用いられる。Ｐフレームの復号には、Ｉフレームに含まれる情報が必要である。Ｂフレームの復号には、Ｉフレームとこれに対応するＰフレームとの両方に含まれる情報が用いられる。
【００２８】
各クライアント１０４は、特定のレベルのビデオ品質を決定することができる。高品質のビデオほど多くの帯域を消費する。従って、高品質ビデオを必要又は希望するクライアントには、高レベルのサービスに対して割増し料金が請求される。大半の消費者は、通常の低品質のビデオで満足するので、サービスに対する請求は安価になる。図１では、帯域要求の変化を大きさが異なるデータフロー矢印で図示してある。ネットワーク・トラフィック条件が悪くなり、全てのクライアントについて品質変更の実施が必要となる場合もある。
【００２９】
こうしたサービス変更への対処は、各ルータ装置１０２に含まれる選択的パケット送信処理によって実現される。パケット・コンテンツは、Ｉフレーム・データ、Ｐフレーム・データ、或いはＢフレーム・データとして認識される。更に、データ・パケット内の低周波または高周波の階層符号化要素を検波する論理も存在する。任意の一クライアント１０４へ配信すべきビデオの要求品質如何で、フロー制御テーブル２２７は、所望する品質レベルの達成に不要な全てのパケットを廃棄するよう設定することもできる。その結果、要求品質を実現するのに必要なパケットだけが転送される。
【００３０】
従来のシステムでは、ビデオ送信に先立って、品質レベルがルータ内に設定されている。送信中に品質レベルを変更する場合、ルータはこれに合わせてパケット選択処理を変更することになる。しかしながら、このことは、或るパケットの幾つかのクライアントへの送信が突如として断たれたままとなったり、逆に、幾つかのクライアントで期せずしてパケット受信が始まることを意味する。ＭＰＥＧデータ・パケットの場合を例にとるならば、これはクライアントがＰフレーム・パケットを受信しない可能性をも意味し、結果として、クライアントがその後に受信したＢフレーム・パケットを正しく復号できなくなってしまう。こうした状況を回避するため、従来のルータは、データユニットの始端においてのみ、換言すればルータがＩフレーム・パケットを受信した時だけ、設定を変更する。
【００３１】
図２ないし図４は、本発明の第１実施例によるルータ装置１０２内でのパケット処理を示す。
図３は、フロー制御テーブル２２７の一実施例を示すものである。フロー制御テーブルは、エントリ１、２、３、．．．Ｎを含む。各エントリは、ＦＬＯＷフィールド３１０、ＡＣＴＩＯＮフィールド３２０、ＦＬＡＧフィールド３３０、ＮＥＷ＿ＡＣＴＩＯＮフィールド３４０からなり、ＦＬＯＷフィールド３１０は、更に、送信元アドレス・サブフィールド３１２と、これに対応する宛先アドレス・サブフィールド３１４からなる。一般に、フローは、
｛ＳＲＣ＿ＡＤＤＲ，ＤＳＴ＿ＡＤＤＲ，ＳＲＣ＿ＰＯＲＴ，
ＤＳＴ＿ＰＯＲＴ，ＰＲＯＴＯＣＯＬ｝
によって識別される。
【００３２】
ポートは、プロトコル（例えばＴＣＰ／ＩＰ、ＵＤＰ／ＩＰなど）によって割り当てられたソフトウェア要素であり、同じ組のコンピュータ（サーバとクライアント）間での多数のフローを区別するために使用される。ＦＬＯＷフィールドは、到着パケットのヘッダ・フィールドに含まれる情報と照合され、到着パケットの所属フローが識別される。ＡＣＴＩＯＮフィールドとＮＥＷ＿ＡＣＴＩＯＮフィールドは、後述するように、送出データ・パケットの出力ＱｏＳを決定するＱｏＳパラメータを含む。
【００３３】
例えば、ＭＱＬＶＳ（又はＤｉｆｆＳｅｒｖ）の場合を考えてみる。ＱｏＳパラメータの例として、ＴＯＳ値（又はＤＳＣＰ値）と出力キューとの間のをマッピングがある。この場合、ＱｏＳパラメータは、ＴＯＳ値とＱｕｅｕｅＩＤ値の対応リストとなる。
【００３４】
｛{ＴＯＳ＝１，ＱｕｅｕｅＩＤ＝４}，
{ＴＯＳ＝２，ＱｕｅｕｅＩＤ＝２}，．．．｝．
他の実施例にあっては、ＴＯＳ（又はＤＳＣＰ）値をＦＬＯＷフィールド３１０に追加することができる。この場合、ＱｏＳパラメータは、ＱｕｅｕｅＩＤそのものである。いずれにしても、出力キューは何らかの優先順位／廃棄設定が予め設定してあることを想定しており、キューへ特定のパケットを割り当てることは、パケットに対し特定の（所定の）ＱｏＳを直接与えることを意味する。
【００３５】
図４は、転送コントローラ２２６の処理の概略を示す。
ネットワーク１０からのデータ・パケットの到着によって処理が開始する。ネットワーク・インタフェース２２２は、パケットを受信してこれを転送コントローラ２２６に渡す。転送コントローラは、データ・パケットのヘッダを調べ、フロー制御テーブル２２７内の一致するエントリを検索する（ステップ４０２）。ペイロード中に「キー」が埋込まれており、この情報に対して検索を行なうことが想定されている。この場合、ＦＬＯＷフィールドは、単にＡ地点からＢ地点への「フロー」についての情報を含むだけではなく、データそれ自体のコンテンツ／セマンティックスに基づいた情報も含む。更に、上記ステップ４０２では、受信したデータ・パケットに含まれる送信元アドレスと、フロー制御テーブル内の各エントリのＦＬＯＷフィールド３１０の送信元アドレス・サブフィールド３１２とを照合し、且つ、受信したデータ・パケットに含まれる宛先アドレスと、フロー制御テーブルの各エントリにあるＦＬＯＷフィールド３１０の宛先アドレス・サブフィールド３１４とを照合する。ちなみに、ＦＬＯＷフィールド３１０内の他のサブフィールドも同様に照合する。
【００３６】
このように、ＦＬＯＷフィールドは、到着パケットのヘッダ・フィールドに含まれる情報を照合するための「キー」として使用される。つまり、各到着パケットについて、フロー制御テーブルで検索を行い、一致するエントリがＦＬＯＷフィールドに見付かった場合に、これに対応するＡＣＴＩＯＮを起こすことを意味する。更に、ワイルドカードの指定も可能である。例えば、ＳＲＣ＿ＡＤＤＲにおけるエントリ「ｘｘ．ｙｙ．ｚｚ．＊」は、ＩＰアドレス「ｘｘ．ｙｙ．ｚｚ．１」、「ｘｘ．ｙｙ．ｚｚ．３」などに一致させることができる。ワイルドカード自体は、「マスク」フィールドの導入により実現される。例えば、「２５５．２５５．２５５．０」の値をとるＳＲＣ＿ＡＤＤＲ＿ＭＡＳＫは、ワイルドカードフォーマットと同じ照合結果が得られる。
【００３７】
次に、受信データ・パケットのエントリが見付かったかどうかを判定するためのテストが行われる（ステップ４０１）。エントリが見付からなかった場合には、ステップ４１０において、データ・パケットをどう転送すべきかに関し、ＤＥＦＡＵＬＴ＿ＡＣＴＩＯＮが実行される。デフォルト動作では、例えば、パケットを転送することなく、単に廃棄するようにしてもよい。受信データ・パケットの処理は、ここで終了する。
【００３８】
ＦＬＯＷフィールド３１０の送信元と宛先アドレス・サブフィールドの両方が、受信データ・パケットに含まれる送信元と宛先のフィールドに一致した場合、一致エントリが見付かる。一致エントリが見付かると、処理はステップ４０３における第２のテストへ進む。ここで、一致エントリのＦＬＡＧフィールド３３０が調べられる。ＦＬＡＧフィールド３３０がセットされていない（例えば値「０」を含んでいる）場合、処理はステップ４０４へ進む。ステップ４０４では、受信データ・パケットがルータ装置１０２から送信（すなわち、転送）される。送信されるデータ・パケットの出力ＱｏＳは、一致エントリのＡＣＴＩＯＮフィールド３２０に含まれるパラメータにより決定される。データ・パケットの処理は、ここで終了する。
【００３９】
ステップ４０３に戻って、もし、ＦＬＡＧフィールド３３０が設定されていた場合（例えば「０」以外の値を含む場合）、処理はステップ４０５における更に別のテストへ進む。本発明のこの実施例にあっては、データ・パケットの所定部分に含まれる情報がテストされる。１実施例として、ＩＰパケット・ヘッダの特定フィールド（ビット）が使用され、例えば、ＩＰ（ｖ４）ヘッダのＴＯＳフィールドのＵＮＵＳＥＤビット、またはＩＰヘッダのＩＰ ＯＰＴＩＯＮＳフィールドが使用される。テストを容易にするため、データ・パケットの上記所定部分は、セット（例えば、「１」を含む）と非セット（例えば、「０」を含む）のどちらかをとる単一のビットであることが望ましい。上記所定部分がセットされていなければ、処理はステップ４０４に従って行なわれる。つまり、データ・パケットは、一致エントリのＡＣＴＩＯＮフィールド３２０に含まれるＱｏＳパラメータにより決定された出力ＱｏＳでもって送信される。パケットの処理は、ここで終了する。
【００４０】
データ・パケットの所定部分がセットされている場合、処理はステップ４０６へ進む。ここで、一致エントリのＮＥＷ＿ＡＣＴＩＯＮフィールド３４０に含まれる情報が、そのエントリのＡＣＴＩＯＮフィールド３２０に複写される。データ・パケットの所定部分に含まれる情報の有無の検出を契機に、ＮＥＷ＿ＡＣＴＩＯＮフィールドからＡＣＴＩＯＮフィールドへのコンテンツの複写が開始される。このようにして、付随するキューからのその後の送信に用いる出力ＱｏＳが変更される。
【００４１】
次に、ステップ４０８において、一致エントリのＦＬＡＧフィールド３３０をクリア（例えば、「０」にセット）する。前述のように、ステップ４０４において、一致エントリのＡＣＴＩＯＮフィールド３２０に含まれるＱｏＳパラメータにより決定された出力ＱｏＳでもって、データ・パケットが送信される。しかしながら、ＡＣＴＩＯＮフィールドに含まれるパラメータは、ここではＮＥＷ＿ＡＣＴＩＯＮフィールド３４０から取得したパラメータとなっている。つまり、ステップ４０４において、データ・パケットは新しいＱｏＳ設定でもって送信される。受信データ・パケットの処理は、ここで終了する。
【００４２】
図５は、本発明の第１実施例の変形例における転送コントローラ２２６内の処理フローを示す。
図４の処理フローの場合と同様、ネットワーク・インタフェース２２２経由のネットワーク１０からのデータ・パケットの到着によって処理が開始される。転送コントローラ２２６は、データ・パケットのコンテンツを調べてフロー制御テーブル２２７から一致エントリを探す（ステップ５０２）。受信データ・パケットに含まれる送信元アドレスは、フロー制御テーブル内の各エントリのＦＬＯＷフィールド３１０の送信元アドレス・サブフィールド３１２と照合される。同様に、受信データ・パケットに含まれる宛先アドレスも、フロー制御テーブル内の各エントリのＦＬＯＷフィールド３１０の宛先アドレス・サブフィールド３１４と照合される。ステップ５０１では、受信データ・パケットのエントリが見付かったかどうかを判定するためのテストが行われる。エントリが見付からなければ、ステップ５１０において、データ・パケットをどう転送するかに関して、ＤＥＦＡＵＬＴ＿ＡＣＴＩＯＮが取られる（ステップ５１０）。前述したように、デフォルト動作では、パケットを転送することなく、単に廃棄するようにしてもよい。受信データ・パケットの処理は、ここで終了する。
【００４３】
ステップ５０１のテストに戻って、ＦＬＯＷフィールド３１０の送信元と宛先のアドレス・サブフィールドが、受信したデータ・パケットに含まれる送信元と宛先フィールドに一致した場合、一致エントリが見付かる。一致エントリが見付かった場合、処理はステップ５０４へ進む。ここで、受信パケットはルータ装置１０２から送信される。送信されるデータ・パケットの出力ＱｏＳは、一致エントリのＡＣＴＩＯＮフィールド３２０に含まれるパラメータにより決定される。次に、処理はステップ５０３のテストへ進む。ここで、一致エントリのＦＬＡＧフィールド３３０が調べられる。もし、ＦＬＡＧフィールド３３０がセットされていない（例えば、値「０」を含む）場合は、送信済みとなっている上記受信パケットの処理を終了する。
【００４４】
一方、ＦＬＡＧフィールド３３０がセットされていた（例えば、「０」以外の値を含む）場合は、処理はステップ５０５において更に別のテストへ進む。本発明のこの実施例によれば、データ・パケットの所定部分に含まれる情報がテストされる。例えば、テストを容易にするため、データ・パケットの上記所定部分は、セット（例えば、「１」を含む）か非セット（例えば、「０」を含む）のどちらかをとる単一のビットであることが望ましい。上記所定部分がセットされていなければ、送信済みとなっている上記受信データ・パケットの処理が終了する。
【００４５】
データ・パケットの上記所定部分がセットされていた場合、処理はステップ５０６に進む。ここで、一致エントリのＮＥＷ＿ＡＣＴＩＯＮフィールド３４０に含まれる情報が、そのエントリのＡＣＴＩＯＮフィールド３２０へ複写される。一致エントリのＦＬＡＧフィールド３３０は、ステップ５０８でクリア（例えば、「０」にセット）される。データ・パケットの上記所定部分に含まれる情報の有無の検出を契機に、ＮＥＷ＿ＡＣＴＩＯＮフィールドからＡＣＴＩＯＮフィールドへのコンテンツの複写が開始され、次いで、送信済みとなっている上記受信データ・パケットの処理を終了する。
【００４６】
図５において概説した手法の利点は、ある出力キューについてルータが新しいＱｏＳ設定を有効にするのに多少時間を要する場合において明白となる。例えば、図４の処理で概説した事例のように、データ・パケットを送信する前にＱｏＳが再設定される場合、トリガ情報を含むデータ・パケットは新しいＱｏＳ設定の付与に要する時間だけ遅延されることになる。しかしながら、上記遅延は、図５に示したように、受信データ・パケットを直ちに送信し、それから新しいＱｏＳ設定の存在を検出するためのテストを行なうことにより回避できる。
【００４７】
本発明の第１実施例の更に別の変形例においては、トリガ情報を含むデータ・パケットを、実際のビデオ・データのペイロードをもつデータ・パケットとしてではなく、特別なデータ・パケットとして配送することができる。第１実施例のこの変形例にあっては、転送コントローラ２２６は、トリガイベントとなる特別なパケットの受信を検出するだけでよい。ＮＥＷ＿ＡＣＴＩＯＮフィールド内に通常含まれるパラメータは、フロー制御テーブル２２７とは別のメモリに格納されることになる。
【００４８】
図１に示したＭＱＬＶＳシステムを再度参照すると、ビデオ・サーバ１００はトリガ情報を含むデータ・パケットを作成する。更に詳しくは、ビデオ・サーバ１００は、データユニットを含む第１のデータ・パケット、すなわちＩフレーム・データを搬送するデータ・パケットの所定部分にビット（フラグ）をセットする。これは、送信ビデオ・データをパケット化するソフトウェアや、ファームウェア或いは論理回路において簡単に実施される。データ・サーバの他の応用例では、トリガ情報をいつどのように提供するか決定するため、他の適当な論理回路や、ファームウェア或いはソフトウェアの使用もあり得ることが理解されよう。
【００４９】
次に、図６には、本発明の第１実施例によるフロー制御テーブルの設定に使用されるＡＰＩが、代表的なＣ言語コードの一部を用いて図示してある。
関数コールＳｅｔ＿ＱｏＳ（）は、ＦＬＯＷデータ構造、ＡＣＴＩＯＮデータ構造、ＦＬＡＧデータ種別の３つの引数を取る。ＦＬＯＷデータ構造は、トリガ情報を含むデータ・パケットの送信元と宛先のアドレスを指定する。ＡＣＴＩＯＮデータ構造は、特にＦＬＯＷデータ構造に含まれる宛先アドレスに付随して、ルータ内で出力キューのＱｏＳを設定するためのパラメータを含む。ＦＬＡＧデータ種別は、ＱｏＳ設定を直ちに実行するのか、それともＱｏＳ設定を遅延させるのかを指定する。
【００５０】
図１、２に戻り、ビデオ・サーバがＱｏＳの変更が適切であると判断した場合、ビデオ・サーバは、ルータ装置１０２の制御部２１０にあるサービス・ソフトウェア２１２と通信する。上記サーバは、ＡＰＩ２１４へのサービス・ソフトウェア２１２によって、新しいＱｏＳ情報をフロー制御テーブルへ送信する。
【００５１】
一実施例では、サービス・ソフトウェア２１２は、例えば、Ｊａｖａのような可搬型（mobile）コードで書かれ、サービス開始時点でビデオ・サーバにより送信されたプログラムであってもよい。この場合、サービス・ソフトウェアとビデオ・サーバは、ネットワーク接続に通信路（例えば、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰなど）を維持することができる。
【００５２】
手法が更にすっきりとした別の実施例では、システム全体が分散コンピューティング環境に構築される。このような環境の一例は、ＣＯＲＢＡ（Common Object Request Broker Architecture）である。この場合、サービス・ソフトウェアとビデオ・サーバ（の一部）とを構成するオブジェクトは、ＴＣＰ／ＩＰに基づくＩＩＯＰ（Internet Inter-ORB Protocol; ORB: Object Request Broker）と呼ばれる機構を介して通信でき、物理的にはどのようなネットワーク接続（例えば、ＬＡＮやＷＡＮなど）でも実行可能である。
【００５３】
サービス・ソフトウェアは、ＡＰＩ関数コールＳｅｔ＿Ｑｏｓ（）にこの情報を使用する。更に詳しく説明すると、この情報はｔａｒｇｅｔ−ｆｌｏｗ引数、ｎｅｗ＿ａｃｔｉｏｎ引数、ｆｌａｇ引数を指定する。Ｓｅｔ＿Ｑｏｓ（）は、ｔａｒｇｅｔ＿ｆｌｏｗ引数に含まれる情報と一致する一致エントリをフロー・テーブルで検索する。ｆｌａｇ引数がＣＨＡＮＧＥ＿ＩＭＭＥＤＩＡＴＥであれば、ｎｅｗ＿ａｃｔｉｏｎ引数が、一致エントリのＡＣＴＩＯＮフィールド３２０に書き込まれる。もし、ｆｌａｇ引数がＣＨＡＮＧＥ＿ＳＹＮＣＨＲＯＮＯＵＳであれば、上記エントリのＮＥＷ＿ＡＣＴＩＯＮフィールドが、ｎｅｗ＿ａｃｔｉｏｎ引数からの情報で埋められ、これに対応するＦＬＡＧフィールド３３０がセットされる。
【００５４】
サービス・ソフトウェア２１２を用いて新しいＱｏＳ情報を通信する代わりに、同じ情報を含む特別なデータ・パケットを定義することができる。この場合、転送コントローラ２２６は上記特別なパケットを検出する。転送コントローラは、上記特別なパケットから情報を抽出し、これをフロー制御テーブル２２７の適当なフィールドへ直接供給するための論理回路、またはコードを含む。上記特別なパケットは、パケット内に、１ビットの「フラグ」を含む所定の位置を割り当てることによって定義できる。上記フラグは、パケットが新しいＱｏＳ情報を有する特別なデータ・パケットであることを示すために使用される。
【００５５】
図２、７、８は、本発明の第２実施例によるルータ装置１０２のパケット処理を示す。
図７は、フロー制御テーブル２２７の別の実施例を示しており、図３に示したフロー制御テーブルと類似のフィールドを有する。図７に図示したフロー制御テーブルは、エントリ１、２、３、．．．Ｎを含む。各エントリは、ＦＬＯＷフィールド７１０、ＡＣＴＩＯＮフィールド７２０、ＭＡＳＫフィールド７３０、ＮＥＷ＿ＡＣＴＩＯＮフィールド７４０からなる。ＦＬＯＷフィールド７１０は、更に、送信元アドレス・サブフィールド７１２と、これに対応する宛先アドレス・サブフィールド７１４とからなる。ＡＣＴＩＯＮ及びＮＥＷ＿ＡＣＴＩＯＮフィールドは、後述するように、送出データ・パケットの出力ＱｏＳを決定するＱｏＳパラメータを含む。ＭＡＳＫフィールドは、ビット・パターンである。
【００５６】
図８は、転送コントローラ２２６の処理の概要を示す。
ネットワーク・インタフェース２２２経由でネットワーク１０からのデータ・パケットの到着によって処理が開始される。転送コントローラは、データ・パケットのコンテンツを調べてフロー制御テーブル２２７から一致エントリを探す（ステップ８０２）。これは、受信データ・パケットに含まれる送信元アドレスとフロー制御テーブル内の各エントリのＦＬＯＷフィールド７１０の送信元アドレス・サブフィールド７１２とを照合し、且つ受信データ・パケットに含まれる宛先アドレスもフロー制御テーブル内の各エントリのＦＬＯＷフィールド７１０の宛先アドレス・サブフィールド７１４と照合することにより行なわれる。
【００５７】
受信データ・パケットについて、エントリが見付かったかどうかを判定するためのテストが行われる（ステップ８０１）。エントリが見付からなければ、データ・パケットをどう処理するかに関連して、ＤＥＦＡＵＬＴ＿ＡＣＴＩＯＮが取られる（ステップ８１０）。デフォルト動作では、例えば、パケットを転送することなく、単に廃棄するようにしてもよい。受信データ・パケットの処理は、ここで終了する。
【００５８】
ＦＬＯＷフィールド７１０の送信元と宛先アドレス・サブフィールドの両方が、受信データ・パケットに含まれる送信元と宛先のフィールドに一致した場合は、一致エントリが見付かる。一致エントリが見付かった場合、処理はステップ８０３における第２のテストへ進む。ここで、フロー制御テーブル２２７内の一致エントリのＭＡＳＫフィールド７３０がテストされる。ＭＡＳＫフィールド７３０のマスク値が全てゼロであれば、処理はステップ８０４へ進む。ステップ８０４では、受信データ・パケットがルータ装置１０２から送信される。送信データ・パケットの出力ＱｏＳは、一致エントリのＡＣＴＩＯＮフィールド７２０に含まれるパラメータにより決定される。パケットの処理は、ここで終了する。
【００５９】
ステップ８０３に戻って、ＭＡＳＫフィールド７３０に含まれる値がオールゼロでなかった場合、処理はステップ８０５における更に別のテストへ進む。本発明のこの実施例によれば、ＭＡＳＫフィールドは、同程度の大きさのマスク・フィールドを含むデータ・パケットの所定部分と比較される。図１に例示したＭＱＬＶＳシステムの場合、上記所定フィールドは、データ・パケットのＩＰヘッダに入っているサービス種別（ＴＯＳ）フィールドとすることができる。ＭＡＳＫがデータ・パケットの所定部分に一致しない場合は、処理はステップ８０４に従って行なわれる。ステップ８０４で、データ・パケットは、一致エントリのＡＣＴＩＯＮフィールド７２０に含まれるＱｏＳパラメータにより決定される出力ＱｏＳでもって送信され、これによりデータ・パケットの処理が終了する。
【００６０】
データ・パケットの上記所定部分がＭＡＳＫフィールド７３０に一致した場合、処理はステップ８０６へ進む。ここで、一致エントリのＮＥＷ＿ＡＣＴＩＯＮフィールド７４０に含まれる情報が、そのエントリのＡＣＴＩＯＮフィールド７２０に複写される。データ・パケットの上記所定部分における情報の存在が検出されたことを契機に、ＮＥＷ＿ＡＣＴＩＯＮフィールドからＡＣＴＩＯＮフィールドへのコンテンツの複写が開始される。
【００６１】
次に、ステップ８０８において、一致エントリのＭＡＳＫフィールド７３０がクリアされる（すなわち、全てゼロにセットされる）。データ・パケットは、ステップ８０４において、一致エントリのＡＣＴＩＯＮフィールド７２０に含まれるＱｏＳパラメータにより決定された出力ＱｏＳでもって送信される。しかしながら、ＡＣＴＩＯＮフィールドに含まれるパラメータは、ＮＥＷ＿ＡＣＴＩＯＮフィールド７４０から取得されたパラメータである。つまり、データ・パケットは、ステップ８０４において、新しいＱｏＳ設定でもって送信される。受信データ・パケットの処理は、ここで終了する。
【００６２】
図９は、本発明の第２実施例の変形例による転送コントローラ２２６内の処理フローを示す。
図８の処理フローと同様、ネットワーク・インタフェース２２２経由でネットワーク１０からのデータ・パケットの到着によって、処理が開始される。転送コントローラは、データ・パケットのコンテンツを調べてフロー制御テーブル２２７内の一致エントリを探す（ステップ９０２）。受信データ・パケットに含まれる発信元アドレスは、フロー制御テーブル内の各エントリのＦＬＯＷフィールド７１０の送信元アドレス・サブフィールド７１２と照合される。同様に、受信データ・パケットに含まれる宛先アドレスも、フロー制御テーブル内の各エントリにおいてＦＬＯＷフィールド７１０の宛先アドレス・サブフィールド７１４と照合される。ステップ９０１において、受信データ・パケットに対するエントリが見付かったかどうか判定するためのテストが行われる。もし、エントリが見付からなければ、ステップ９１０において、データ・パケットをどう処理するかに関連して、ＤＥＦＡＵＬＴ＿ＡＣＴＩＯＮが取られる。デフォルト動作は、例えば、パケットを転送することなく、単に廃棄するようにしてもよい。受信データ・パケットの処理は、ここで終了する。
【００６３】
ステップ９０１のテストに戻って、ＦＬＯＷフィールド７１０の送信元と宛先の両方のアドレス・サブフィールドが、受信データ・パケットに含まれる送信元と宛先フィールドに一致した場合、一致エントリが見付かる。一致エントリが見付かった場合、処理はステップ９０４へ進む。ここで、受信パケットがルータ装置１０２から送信される。送信データ・パケットの出力ＱｏＳは、一致エントリのＡＣＴＩＯＮフィールド７２０に含まれるパラメータにより決定される。処理は、ステップ９０３におけるテストへ進む。ここで、一致エントリのＭＡＳＫフィールド７３０が調べられる。もし、ＭＡＳＫフィールド７３０がオールゼロの場合、送信済みとなっている上記受信パケットの処理を終了する。
【００６４】
一方、ＭＡＳＫフィールド７３０がオールゼロではなかった場合、処理はステップ９０５における更に別のテストへ進む。本発明のこの実施例によれば、ＭＡＳＫがデータ・パケットの所定部分と比較される。上記所定部分がＭＡＳＫと一致しなければ、送信済みとなっている上記受信データ・パケットの処理を終了する。
【００６５】
データ・パケットの上記所定部分が一致した場合、処理はステップ９０６へ進む。ここで、一致エントリのＮＥＷ＿ＡＣＴＩＯＮフィールド７４０に含まれる情報が、そのエントリのＡＣＴＩＯＮフィールド７２０に複写される。ステップ９０８において、一致エントリのＭＡＳＫフィールド７３０がオールゼロにセットされる。データ・パケットの上記所定部分との一致検出を契機に、ＮＥＷ＿ＡＣＴＩＯＮフィールドからＡＣＴＩＯＮフィールドへコンテンツが複写され、送信済みとなっている上記受信データ・パケットの処理を終了する。
【００６６】
図９において概説した方法の利点は、或る出力キューについてルータが新しいＱｏＳ設定を有効にするのに多少時間を要するような場合において明白となる。図８の処理で概説したケースのように、もし、データ・パケットの送信前にＱｏＳが再設定された場合、複写の契機となるデータ・パケットは、新しいＱｏＳ設定の付与に要する時間だけ遅延される。しかしながら、上記遅延は、図９に示したように、受信データ・パケットを直ちに送信し、それから新しいＱｏＳ設定を有効にすることによって、回避することができる。
【００６７】
次に、図１０を参照すると、本発明の第２実施例によるフロー制御テーブルを設定するのに用いるＡＰＩが、代表的なＣ言語コードの一部を用いて図示してある。関数コールＳｅｔ＿ＱｏＳ（）は、ＦＬＯＷデータ構造、ＡＣＴＩＯＮデータ構造、ＭＡＳＫ引数の３つの引数を取る。ＦＬＯＷデータ構造は、トリガ情報を含むデータ・パケットの送信元と宛先のアドレスを指定する。ＡＣＴＩＯＮデータ構造は、特にＦＬＯＷデータ構造に含まれる宛先アドレスに付随して、ルータ内での出力キューのＱｏＳ設定用のパラメータを含む。ＭＡＳＫは、８ビットのビット・パターンである。
【００６８】
図１、２を参照すると、ビデオ・サーバは、ＱｏＳの変更が適切であると判断した時、ビデオ・サーバはルータ装置１０２の制御部２１０にあるサービス・ソフトウェア２１２と通信する。ビデオ・サーバは、ＡＰＩを用いてフロー制御テーブルへ新しいＱｏＳ情報を送信する。サービス・ソフトウェア２１２は、この情報をＡＰＩ関数コールＳｅｔ＿Ｑｏｓ（）に使用する。更に詳しくは、上記情報は、ｔａｒｇｅｔ＿ｆｌｏｗ引数、ｎｅｗ＿ａｃｔｉｏｎ引数、ｍａｓｋ引数を指定する。Ｓｅｔ＿Ｑｏｓ（）は、ｍａｓｋ引数に含まれる情報と一致するフロー・テーブル内の一致エントリを検索する。一致エントリのＮＥＷ＿ＡＣＴＩＯＮフィールド７４０は、ｎｅｗ＿ａｃｔｉｏｎ引数からの情報で埋められ、ｍａｓｋ引数の値が、一致エントリの対応するＭＡＳＫフィールド７３０に複写される。
【００６９】
サービス・ソフトウェア２１２を用いて新しいＱｏＳ情報を通信する別の方法として、同じ情報を含む特別なデータ・パケットを定義することができる。この場合、転送コントローラ２２６は、上記特別なパケットを検出する。転送コントローラに含まれる論理回路やソフトウェアなどが、パケットから上記情報を抽出し、これをフロー制御テーブル２２７内の適当なフィールドへ直接配送する。
【００７０】
図１１は、図７のフロー制御テーブルをセットするのに使用されるＡＰＩの変形例を示す。このＡＰＩの変形例は極めて一般的なものであり、マスク値を指定することに加え、到着データ・パケットの上記所定部分の位置をデータ・パケット内の任意の場所に定義することを可能にしている。上記所定部分は、パケット・ヘッダ内、またはペイロード自体の中で、指定された位置に指定された長さとすることができる。
【００７１】
関数コールＳｅｔ＿Ｑｏｓ（）は、ＦＬＯＷデータ構造、ＡＣＴＩＯＮデータ構造、ＭＡＳＫデータ構造の３つの引数を取る。ＦＬＯＷデータ構造とＡＣＴＩＯＮデータ構造は、前述したように定義される。ＭＡＳＫデータ構造は、ヘッダ及びペイロードの仕様に対応することができる。もし、上記所定部分をヘッダ内に配置すべき場合には、関連するデータ構造はＨＥＡＤＥＲ＿ＦＩＥＬＤである。このデータ構造は、ｍａｓｋ値を比較する箇所がデータ・パケットのヘッダ内のどのフィールドかを指定する。上記所定部分をペイロード内に配置すべき場合には、関連するデータ構造はＰＡＹＬＯＡＤ＿ＦＩＥＬＤである。このデータ構造は、ペイロードの始端を基点として、上記所定部分の開始位置を示すｏｆｆｓｅｔ＿ｐｏｓｉｔｉｏｎを指定する。ｆｉｅｌｄ＿ｌｅｎｇｔｈは、マスク値と比較すべきフィールドの長さを指定する。ＨＥＡＤＥＲ＿ＦＩＥＬＤまたはＰＡＹＬＯＡＤ＿ＦＩＥＬＤが指定されたか否かに関わらず、フロー制御テーブル内に格納すべきマスク値を指定するｆｉｅｌｄ＿ｖａｌｕｅが存在する。
【００７２】
図１２は、図７のフロー制御テーブルを設定するためのＡＰＩの更に別の変形例を示す。ここでは、Ｓｅｔ＿Ｑｏｓ（）の複数回の呼出または実行が可能である。実行のマスク値は、Ｃｏｍｍｉｔ＿Ｃｈａｎｇｅ（）への１回の関数コールによって設定できる。Ｓｅｔ＿Ｑｏｓ（）コールによって影響される各エントリが、上記マスク値を受け取る。
【００７３】
図１３は、フロー制御テーブル２２７がＱｏＳパラメータの複数エントリのベクトルを含んだ本発明の第３の実施例を示す。ＦＬＯＷフィールド１３１０とＡＣＴＩＯＮフィールド１３２０に加え、ＮＥＷ＿ＡＣＴＩＯＮ＿ＬＩＳＴフィールド１３５０が備わっている。ＮＥＷ＿ＡＣＴＩＯＮ＿ＬＩＳＴフィールド１３５０は、ＱｏＳ設定１３７０の配列へのポインタである。上記配列内の各エントリは、ＭＡＳＫフィールド１３３０と、ＱｏＳパラメータを含むＮＥＷ＿ＡＣＴＩＯＮフィールド１３４０とからなる。このように、フロー制御テーブル２２７内の或るエントリに対し、対応する出力キューに多数のＱｏＳ設定が存在し得る。選択される特定のＱｏＳレベルは、どのＭＡＳＫフィールド１３３０が受信データ・パケットの所定位置に含まれるビットパターンに一致するかによって決まる。
【００７４】
フロー制御テーブルのこの変形例を設定するためのＡＰＩは、図１０ないし図１２に示したＡＰＩの実施例に適当な変更を加えることによって、簡単に得られる。ＭＡＳＫとＡＣＴＩＯＮのデータ構造は、単一要素の構造に代えて、リストとなるよう変更できる。
【００７５】
図１３のフロー制御テーブルの変形例において、ＮＥＷ＿ＡＣＴＩＯＮ＿ＬＩＳＴは、継続モード（persistent mode）をもつことができる。前述の実施例において、ＭＡＳＫフィールドは、ＱｏＳ設定の変更時にクリアされる。例えば、図８のステップ８０８は、ＭＡＳＫフィールドをクリアするステップである。継続モードの動作では、それが明示的に消去されない限り、ＭＡＳＫフィールドは影響されることはない。これは、適当なＡＰＩを準備することによって実現可能である。
【００７６】
図１３のフロー制御テーブルに継続モードの特徴を備えることは、帯域要求パターンが既知となっているトラフィック・フロー状況で有用と思われる。例えば、ビデオ・ストリームの場合、ビデオ内の異なる場面で帯域要求が変化する。従って、ビデオコンテンツの関数としてネットワークの帯域要求を変化させることが可能である。更に、この情報は、ビデオ・ストリーム全体について決定することができる。図１４は、例えば、帯域要求が時間とともに変化する典型的なシーケンスを示す。
【００７７】
ビデオ・サーバ１００は、適当なＡＰＩにより、配列１３７０内のＱｏＳ設定リストからなるＱｏＳパラメータをもった図１３のフロー制御テーブルをプログラミングすることができる。これに代えて、特別なデータ・パケットでＱｏＳパラメータのリストを提供するために、適当なプロトコルを定義してもよい。
【００７８】
ビデオ送信中に、ビデオ・サーバが、適当なビデオ・データ・パケット内にマスク値を設定し、ビデオ送信の別々の場面で要求される帯域に応じてルータ装置１０２内のＱｏＳを選択する。例えば、各場面の最初のパケットに、その場面で必要とされるＱｏＳを選択するためのマスク値を持たせる。このパケットを受信すると、ルータはそれに合わせて出力ＱｏＳを設定する。ビデオの場面が変化した時、次の場面の最初のパケットが、ルータ内で適当なＱｏＳを選択する別のマスク値をもつ。このようにしてフロー制御テーブルを動的に調整することにより、ルータ資源を効率的に利用できる。ビデオの帯域要求が減ると資源を解放し、その逆の動作も行なうことにより、資源消費が最小限になる。
【００７９】
図６に示したＡＰＩも、同様の態様で使用することができる。場面の変化が発生しそうになると、その都度ビデオ・サーバがＣＨＡＮＧＥ＿ＩＭＭＥＤＩＡＴＥフラグを用いてＡＰＩを呼び出すことができる。
【００８０】
上述した議論はルータ装置以外のネットワーク機器を含むように容易に拡張できることが分かる。一般に、サービス・プロバイダは自分自身のルータを保有していない。ルータやスイッチは、ネットワーク・プロバイダにより保守されている。更に、サーバからクライアントへの通信路は、多数のネットワーク・ドメインを通過することがある。本発明は、サーバとクライアントの間の通信路に沿ったスイッチング装置、更に一般的にはネットワーク機器へ、当業者が容易に適用することができる。例えば、本発明に従って、サーバからクライアントへの通信路に沿った２以上のネットワーク機器のＱｏＳ設定を調整することができる。装置のアドレス情報は、着目ネットワーク機器（群）を識別するために簡単に組み込むことができるため、後続のＱｏＳパラメータをこれらの機器へ通信できる。多数のネットワーク機器が同じＱｏＳパラメータを共有できるような場合は、マルチキャスト送信を使用することができる。
【００８１】
上記のように、本明細書で開示したビデオ・サーバは、本発明の新規な特徴及び態様を提示する単なる一例に過ぎない。本発明は、一般のデータ・サーバに適用可能であり、ビデオ・サーバに限定されるものと解釈してはならない。
本発明により、データ・サービス・プロバイダは、データ通信資源のきめ細かな制御に基づく新規なサービスを立案することができる。
【００８２】
例えば、図１に図示したＭＱＬＶＳシステムにおいて、ＭＰＥＧのデータユニットの最初のパケットにのみ基づいてサービス変更を制限する代わりに、サービス・プロバイダは、ビデオ場面の変化時やトラフィック条件の変動時などに、ビデオコンテンツに基づいて時間刻みでサービス変更を制御することができる。サービスには、プロバイダの課金施策と請求施策の一方又は両方を含めることができ、クライアント端末の顧客は希望するサービス品質に基づいてプロバイダに料金を支払うことになる。
【００８３】
【発明の効果】
本発明は、ネットワーク資源の効率的利用を高めるために使用することができる。
【図面の簡単な説明】
【図１】本発明に従って動作するネットワーク上の代表的なデータ・サーバ・アプリケーションの簡略化されたシステム図である。
【図２】本発明に従って構成されたルータの簡略化されたブロック図である。
【図３】本発明の一実施例によるフロー制御テーブルを示す。
【図４】本発明の一実施例による転送コントローラにおいて行なわれる幾つかの処理の概略を示す。
【図５】上記転送コントローラの処理の変形例の概略を示す。
【図６】本発明によるフロー制御テーブルを設定するための特徴を強調するＡＰＩの１実施例を示す。
【図７】本発明の別の実施例によるフロー制御テーブルを示す。
【図８】本発明の別の実施例による転送コントローラにおいて行なわれる幾つかの処理の概略を示す。
【図９】転送コントローラの処理における変形例の概略を示す。
【図１０】図７のフロー制御テーブルを設定するための特徴を強調したＡＰＩの１実施例である。
【図１１】図７のフロー制御テーブルを設定するための特徴を強調したＡＰＩの変形例である。
【図１２】図７のフロー制御テーブルを設定するための特徴を強調したＡＰＩの更に別の変形例である。
【図１３】フロー制御テーブルの更に別の実施例を示す。
【図１４】ビデオ・ストリームにおける典型的な帯域パターンを示す。
【図１５】従来技術の代表的なメンテナンス・シーケンスを示す。
【符号の説明】
１００：サーバ、１０２：ルータ、１０４：クライアント端末、
２１０：制御部、２１２：サービスソフトウエア、２１４：アプリケーション・プログラム・インタフェース（ＡＰＩ）、２１６：コントローラ・ソフトウエア、
２２２：ネットワークインタフェース、２２４：バス／スイッチ、
２２６：転送コントローラ、２２７：フロー制御テーブル、
２２８：ルータコントローラ。
【発明の属する技術分野】
本発明は、一般に電気通信ネットワークに関し、詳しくは、データ供給のサービス・レベルに関与するネットワーク機器に関する。更に詳しくは、本発明はネットワーク機器の品質関連属性のリアルタイム調整に関する。
【０００２】
【従来の技術】
ルータやスイッチなどの機器は、ネットワーク（例えば、ＬＡＮやＷＡＮなど）接続用、および一つのネットワークから別のネットワークへのデータグラム転送用に使用される。データグラムは、通信データ（ペイロード）ならびに送信元アドレスと最終的な宛先アドレスとを含む。広く使用されているデータグラムのフォーマットは、ＴＣＰ／ＩＰ（transmission control protocol/internet protocol）フォーマットである。スイッチは、ただ単に到着したデータグラムに含まれる宛先情報に基づき、そのデータグラムを特定の出力ポートへ供給する。同様に、ルータはデータグラムを中間的な宛先へ送信するが、中間的な宛先は最後には最終的な宛先となる。しかしながら、ルータは、トラフィック条件や可用性等の基準に従い、出力ポートを多くの中間的宛先の中から選択することになる。
【０００３】
ネットワークに結合されたホストは、各種のデータを搬送する。データ送信（又はデータフロー）のある種のものは、ネットワークに一定レベルの品質を要求する。一般的な属性は、サービス品質（Quality of Service; QoS）である。例えば、ビデオ・データと音声データの一方又は両方の送信では、ビデオ・コンテンツと音声コンテンツの一方又は両方の円滑なプレゼンテーションを確保するため、一般的にワールド・ワイド・ウェブ（ＷＷＷ）ページ表示用のデータ送信において通常必要とされるよりも高いＱｏＳが必要とされる。これは、特にオーディオコンテンツの場合に言えることである。なぜなら、人の聴感は、ビデオ通信よりもオーディオ通信における劣化に対し非常に敏感なためである。しかしながら、ウェブ・ページを見る場合には、低いＱｏＳに起因するページコンテンツ表示の遅延は我慢することができる。
【０００４】
ＱｏＳは様々な方法で表現され、例えば最小の帯域要求や最大の送信遅延或いはデータフローに必要なメモリ又はバッファ空間の量などが、Ｑｏｓの指定対象とされる。それゆえ、ビデオ会議やその他のリアルタイム・データ通信は、高ＱｏＳを有し、ネットワークに充分な帯域と最小遅延が要求される。特定のデータフローに必要となるＱｏＳを指定することにより、データの送信元又は送信先は満足できる通信路が入手できるかどうかを確認することができる。このようにして、ＱｏＳルーティングでは、必要な資源を欠くリンクを迂回したデータフロー転送が可能となる。
【０００５】
インターネット・プロトコル（ＩＰ）ルータ又はスイッチ（本明細書ではこれらを合わせてネットワーク機器と呼ぶことにする）の一般的な動作環境では、様々な管理タスクの実行中にＱｏＳの設定を調整するシステム管理者が存在する。この代わりに、一組のネットワーク機器を管理する自動管理方式のコントローラが、上記ネットワーク機器によるサービスを受けるドメイン内のトラフィック条件に応じて、ＱｏＳ設定を定期的に調整する場合もある。
【０００６】
図１５に示したフローチャートは、ネットワーク機器におけるＱｏＳ設定を変更するための従来の手法のステップを示すものである。
人間又は自動コントローラのいずれかである管理者は、一般に、メンテナンス・チャンネルを介してネットワーク機器へアクセスする。このチャンネルは、例えばネットワーク機器上のローカル・エリア・ネットワーク（ＬＡＮ）インタフェースの一つであるイーサネット・ポートなどを経由してアクセスされるテルネット（telnet）セッションなどの論理チャンネルとすることができる。これに代えて、ネットワーク機器がＰＣに接続されるシリアルポートなどを備えてもよい。
【０００７】
ＱｏＳ設定を変更するための管理コマンドは、ネットワーク機器に含まれるサービス・ソフトウェアを介して発行される（ステップ１５０４）。上記管理コマンドは、適当なプロトコル規格やコマンド・インタフェース或いはアプリケーション・プログラム・インタフェース（ＡＰＩ）により、ネットワーク機器の内部コントローラへ送られる（ステップ１５０６）。現在の技術では、ＳＮＭＰ（simple network management protocol）のような管理／保守プロトコルが、最も一般的に使用されている。大半の装置は、上記プロトコル・サポートに加え、主として機器独自の特徴をサポートするためのコマンド・インタフェースを備えている。ここで、ネットワーク機器内部のコントローラ計算機は、上記コマンドからＱｏＳパラメータを抽出し、ＱｏＳテーブルの内容を更新する（ステップ１５０８）。このシーケンスはあまり頻繁に実行されるものではなく、一般的には数時間に１回程度かそれより長い間隔で行なわれる。
【０００８】
現在のネットワーク使用方法では、ほとんどのＱｏＳ割り当ては、事前の要求に基づいて行われる。例えば、我々が特定の日の午後１時から午後３時まで電子会議を開催したい場合を想定する。この場合、我々は管理者（人間または計算機）に対して、上記会議に関係するネットワーク機器（必ずしも１対１でなく、複数の地点が関係してもよい）に特定のＱｏＳを割り当てるよう要求を出す。管理者は、電子会議セッションをサポートすべく、ネットワークに午後１時（または１２時５５分）にコマンドを送信するためのトリガ機構をセットする。
【０００９】
将来、ＱｏＳ制御は、前述したように「セッション指向の」時間粒度（granularity）で適用されるのではなく、どちらかと言えば「リアルタイム」粒度で適用されるものと想定される。例えば、ビデオ・データフローの送信中に、コンテンツによっては特定の機器におけるＱｏＳ設定を変更したい場合がある。ビデオでは、主構成が静止画であって帯域要求が小さくなるような（持続時間が数分の）シーンもあり得る。（数時間単位に及ぶことがある）ビデオ・フローの持続時間全体にわたって特定帯域を予約するよりは、ネットワーク資源全体をもっと効率的な方法で活用するため、ＱｏＳをより動的な方法で変更することが望まれる。
【００１０】
しかしながら、このようにデータ送信中にＱｏＳを動的に変更する場合、ＱｏＳ変更のタイミングとデータのフローとがリンクしていない（同期していない）ために問題を生ずる。例えば、画像送信では、送信元サーバから送信先クライアントへの大量の画像データ・パケット通信を必要とする。伝送優先順位を上げようとして画像データ・パケットのストリームの途中でＱｏＳを変更したものと仮定すると、結果的には後から送信される画像データ・パケットが先に送信されたパケットよりも早く到着することがある。このような場合、送信先に到着するパケットのシーケンスが乱れることになる。
【００１１】
送信先サイトは、パケットを受信してバッファリングするための追加ソフトウェアを使用してこれを補償することができる。上記ソフトウェアにより、パケットを再シーケンスすることで、画像は正しく表示される。これに代えて、上記受信ソフトウェアに、表示前に画像全体を蓄えるための非常に大きなバッファを実装することもできる。いずれの場合も、クライアント側ソフトウェアが複雑さを増すことは好ましくなく、性能低下を招く。更に、後者の解決方法は、物理メモリにしても仮想メモリ（ディスク・スワッピングの増加に起因する追加遅延量の増加見込みから性能は更に劣化する）にしても追加メモリが必要となるという問題がある。ビデオ・ストリームの場合、ライブ・ビデオフィードにおける大量のデータとライブ・アクション・ビデオのリアルタイム性のため、ストリーム全体を一括したバッファリングは無理である。こうした状況下では、シーケンスから外れて到着したデータ・パケットは廃棄され、誤ったビデオ画像しか得られないことになる。
【００１２】
ネットワーク機器のＱｏＳを調整する代表的な方式は、既に知られている。例えば、ＩＥＴＦ（Internet Engineering Task Force）で定義された「特殊化サービス（differentiated services）」アーキテクチャは、ＩＰ層パケット・マーキング方式を用いて所望のＱｏＳを伝える。ＩＰヘッダには、特殊化サービス・コードポイント（ＤＳＣＰ）フィールドが含まれる。上記ＤＳＣＰは、ネットワーク機器内で各パケットを特定の伝送優先順位にマッピングするために使用される。ＤＳＣＰの値と伝送優先順位との間のマッピングは、通常、送信開始に先立ってネットワーク管理システムによって設定され、上記マッピングは送信が完了するまで変更されない。この方式には、送信中にマッピングを変更するための機構は存在しない。
【００１３】
「アクティブ・ネットワーク」では、ユーザはデータ・ストリームにカスタマイズされたプログラムを挿入することができる。データ・パケットには、宛先に到達する過程で遭遇する一又はそれ以上のネットワーク機器により実行されるプログラムが含まれる。つまり、ネットワーク・ノードにおけるＱｏＳ動作を制御するために書かれたプログラムをデータ・ストリームに挿入することができる。上記方法に伴う一つの欠点は、パケット内へのプログラムの封入（encapsulation）によって、そのパケットが搬送できるペイロードの量が制限されることにある。アクティブ・ネットワークの多能性と柔軟性は、ＱｏＳにパケット単位の精密な制御をもたらす。しかしながら、この能力は、各ネットワーク機器におけるソフトウェアの実行という犠牲のもとに生まれ、上記余分な処理はネットワーク性能を劣化させる。
【００１４】
現在ＩＥＥＥで定義中のプログラマブル・ネットワークとして知られているネットワーク・クラスでは、ネットワークの資源はソフトウェアの抽象物として表現される。ソフトウェアは、標準化された一組のアプリケーション・プログラム・インタフェース（ＡＰＩ）を用いて、ネットワーク機器と相互作用する。シグナリング・サービスや品質レベルサービスのようなスイッチング機能に関連した資源を抽象化することで、新規サービスの開発と展開を容易にすることがその目標となっている。
【００１５】
【発明が解決しようとする技術課題】
ネットワーク資源のより良い利用と、より柔軟なサービスを供給する一般的なニーズが存在している。ＱｏＳの調整は、能力のあるデータ・サービス・プロバイダにユーザのための資源利用の改善を可能とする。サービス・プロバイダは、データ伝送に対してもっときめ細かな制御を行なうことにより、新規サービスと、より柔軟かつ公平な課金施策の立案が可能となる。こうすることで、例えば、割増し料金を支払ったユーザには、平均的ユーザに通常提供されるであろう帯域よりも広い帯域を割り当てることができる。他の状況では、変化するトラフィック条件に適合すべく、ユーザ間で帯域割り当てを再調整することができる。同様に、ビデオ会議接続のように、多くの資源を必要とする用途の伝送時間を改善するため、必要に応じて送信遅延を制御することができる。上述した利益を実現し得る手法へのニーズが存在している。
【００１６】
【課題を解決するための手段】
本発明は、データ・サービス・プロバイダが、一又はそれ以上のネットワーク機器に情報を通信し、クライアントへの通常のデータ通信中に、ネットワーク機器における少なくとも一つの通信属性を変更する。データ・サービス・プロバイダは、一層効率的にネットワーク資源を割り当てることにより、様々なクライアントに適切なサービス・レベルを割り振ることができる。データ・サービス・プロバイダは、全てのクライアントの間で資源を再割り当てすることで、変化するトラフィック条件に効果的に対応できる。また、追加サービスや一層柔軟な課金施策を開発することができる。
【００１７】
本発明の一態様において、データ供給システムは、一又はそれ以上のネットワーク機器とデータ通信するデータ・サーバを含む。これにより、標的となるネットワーク機器、すなわち、属性を変更しようとするネットワーク機器へ第１の情報が送信される。上記第１の情報の送信は、上記データ・サーバから行なわれる。上記第１の情報は、少なくとも一つの新しいネットワーク機器属性を含み、この属性はネットワーク機器に保存される。次に、上記データ・サーバにより、標的ネットワーク機器に第２の情報が送信される。上記第２の情報は、トリガとして機能し、上記ネットワーク機器を作動させて現在の属性設定を新属性設定に更新する。従って、ネットワーク機器属性の動的なリアルタイム調整が実現できる。
【００１８】
本発明のこの態様によれば、上記第１の情報には、標的ネットワーク機器（群）を識別するためのアドレス情報を含めてもよい。また、第２の情報は、クライアント宛のデータ・パケットに含めることができる。標的ネットワーク機器における上記新属性設定は、新属性設定動作をトリガする上記第２の情報を含んだデータ・パケットの送出に先立って実行される。これに代えて、上記動作が上記第２の情報を含むデータ・パケットの送信後に起きるようにしてもよい。
本発明の別の態様によれば、上記第１、第２の情報のどちらか一方又は両方を、ネットワーク機器によって取り込まれる特殊なデータ・パケットに含めることができる。
【００１９】
本発明の特定の態様によれば、調整中のネットワーク機器属性はサービス品質（ＱｏＳ）設定であり、上記第１の情報がＱｏＳ設定を特定するＱｏＳパラメータを含む。本発明の上記特定態様の一変形例では、上記第１の情報がＱｏＳパラメータのリストを含む。本発明の上記特定態様の別の変形例では、ＱｏＳパラメータのリストが標的ネットワーク機器内で組み立てられ、上記第２の情報が上記ＱｏＳパラメータリストへの索引を含む。
【００２０】
本発明の更に別の態様では、ネットワーク機器が、上記ネットワークからデータ・パケットを受信するための一つのネットワークに接続されたネットワーク回路を含む。また、第１の情報を含む受信データ・パケットの存在を検出するためのデータ・モニタリング回路がある。外部供給された一又はそれ以上のＱｏＳパラメータを受信するために第１のプログラム・コードが装備されており、上記第１の情報の検出に応答し、外部から提供されたＱｏＳパラメータに従って、ネットワーク機器のＱｏＳ設定を変更するための第２のプログラム・コードが装備されている。
【００２１】
【発明の実施の態様】
純粋に本発明の新規な特徴及び利点を説明するための方策として、プログラマブル・ネットワーク上で展開されるネットワーク・サービスについて、本発明の実施例を提供する。代表的実施例において、ネットワーク・サービスは、ビデオ・データを配信する品質多層化ビデオサービス（ＭＱＬＶＳ）モデルに従って提供される。尚、上記ＭＱＬＶＳモデルについては、１９９９年５月に国際電気通信連合の研究グループ１６の会議でＴ．スズキにより発表された「ＩＰネットワーク上のスケーラブルＭＰＥＧ２ビデオ伝送システム」と題する論文において議論されており、その内容については、あらゆる目的のために全面的に本明細書に編入することにする。
【００２２】
図１は、このようなプログラマブル・ネットワークの簡略化されたシステム図である。
ビデオ・サーバ１００は、ネットワーク１０によって、ビデオ・プログラムを様々なクライアント１０４に送信する。上記ネットワーク１０は、ネットワークの世界的な集合体であるインターネットと、ネットワーク機器とからなる。但し、上記ネットワーク１０は、より局所化されたイントラネットであってもよい。上記ネットワークは、ルーティング装置やスイッチング装置を含む多数のネットワーク機器１０２の相互接続によって定義される。ビデオ・サーバ１００の受信側には、クライアント１０４がある。
【００２３】
図２は、ルータ装置１０２の代表的な構成を示す簡略化されたシステム図である。
ルータ機器は、制御部２１０を含んでおり、この制御部２１０は、典型的には、一般のルータ装置に代表されるルータ部２２０から離れて存在するコンピュータである。一つの構成において、制御部２１０はルータ部２２０に隣接して配置される。制御部２１０は、ネットワーク・リンクによってルータ部２２０に接続されたＰＣ又はワークステーションであり、別の実施例では、上記制御部２１０は遠隔地に配置される。更に別の実施例では、単一のコントローラを使用して１台又はそれ以上のルータ部２２０が管理される。
【００２４】
制御部２１０は、アプリケーション・プログラム・インタフェース（ＡＰＩ）２１４の最上部で実行されるサービス・ソフトウェア２１２を含む。ＡＰＩは、サービス・ソフトウェア２１２とコントローラ・ソフトウェア２１６との間のインタフェースを提供する。上記コントローラ・ソフトウェアは、ルータ部２２０と直接通信する。本発明の典型的な実施例において、上記サービス・ソフトウェアは、ビデオコンテンツを配信するためのＭＱＬＶＳモデルに従って、ネットワーク・サービスを提供する。
【００２５】
ルータ部２２０は、ネットワーク１０に結合された一又はそれ以上のネットワーク・インタフェース２２２（例えば、イーサネット・インタフェース）を含む。データ・パケットは、上記ネットワーク・インタフェースによりネットワークに送受信される。ネットワーク・インタフェース２２２は、転送コントローラ２２６を用いて内部バス又はスイッチ２２４に結合されている。各転送コントローラ２２６は、フロー制御テーブル２２７を含んでいる。
【００２６】
ルータは、典型的には、一つの物理ポートについて複数の出力キューを有し、各キューには、互いに質の異なるサービス属性を設定することができる。これらの属性は、集合的にＱｏＳパラメータと呼ばれる。例えば、各キューは、キュー内に置かれているデータ・パケットを送信するための異なる伝送順位を持つことができ、各キューは、互いに異なったパケット廃棄レベルを持つこともできる。フロー制御テーブル２２７は、情報（ＱｏＳパラメータ）を含み、これによって到着データ・パケットの転送用となる各出力キューのＱｏＳ設定が作成される。フロー制御テーブル２２７は、ルータ・コントローラ２２８により維持される。
【００２７】
図１，２に関しては、ネットワーク上に送信するビデオ・プラットフォームとして、ＭＰＥＧ（Motion Picture Experts Group）に規定された標準規格が一般的に使用される。ＭＰＥＧデータ・ストリームでは、ビデオ・データは、Ｉフレーム・データ・パケットとこれに続く複数グループのＢフレーム・データ・パケットとからなるデータユニットにブロック化することができる。Ｂフレーム・データ・パケットの各グループには、Ｐフレーム・データ・パケットが付随しており、これはＢフレームの一つのグループを次のグループから分離するために用いられる。Ｐフレームの復号には、Ｉフレームに含まれる情報が必要である。Ｂフレームの復号には、Ｉフレームとこれに対応するＰフレームとの両方に含まれる情報が用いられる。
【００２８】
各クライアント１０４は、特定のレベルのビデオ品質を決定することができる。高品質のビデオほど多くの帯域を消費する。従って、高品質ビデオを必要又は希望するクライアントには、高レベルのサービスに対して割増し料金が請求される。大半の消費者は、通常の低品質のビデオで満足するので、サービスに対する請求は安価になる。図１では、帯域要求の変化を大きさが異なるデータフロー矢印で図示してある。ネットワーク・トラフィック条件が悪くなり、全てのクライアントについて品質変更の実施が必要となる場合もある。
【００２９】
こうしたサービス変更への対処は、各ルータ装置１０２に含まれる選択的パケット送信処理によって実現される。パケット・コンテンツは、Ｉフレーム・データ、Ｐフレーム・データ、或いはＢフレーム・データとして認識される。更に、データ・パケット内の低周波または高周波の階層符号化要素を検波する論理も存在する。任意の一クライアント１０４へ配信すべきビデオの要求品質如何で、フロー制御テーブル２２７は、所望する品質レベルの達成に不要な全てのパケットを廃棄するよう設定することもできる。その結果、要求品質を実現するのに必要なパケットだけが転送される。
【００３０】
従来のシステムでは、ビデオ送信に先立って、品質レベルがルータ内に設定されている。送信中に品質レベルを変更する場合、ルータはこれに合わせてパケット選択処理を変更することになる。しかしながら、このことは、或るパケットの幾つかのクライアントへの送信が突如として断たれたままとなったり、逆に、幾つかのクライアントで期せずしてパケット受信が始まることを意味する。ＭＰＥＧデータ・パケットの場合を例にとるならば、これはクライアントがＰフレーム・パケットを受信しない可能性をも意味し、結果として、クライアントがその後に受信したＢフレーム・パケットを正しく復号できなくなってしまう。こうした状況を回避するため、従来のルータは、データユニットの始端においてのみ、換言すればルータがＩフレーム・パケットを受信した時だけ、設定を変更する。
【００３１】
図２ないし図４は、本発明の第１実施例によるルータ装置１０２内でのパケット処理を示す。
図３は、フロー制御テーブル２２７の一実施例を示すものである。フロー制御テーブルは、エントリ１、２、３、．．．Ｎを含む。各エントリは、ＦＬＯＷフィールド３１０、ＡＣＴＩＯＮフィールド３２０、ＦＬＡＧフィールド３３０、ＮＥＷ＿ＡＣＴＩＯＮフィールド３４０からなり、ＦＬＯＷフィールド３１０は、更に、送信元アドレス・サブフィールド３１２と、これに対応する宛先アドレス・サブフィールド３１４からなる。一般に、フローは、
｛ＳＲＣ＿ＡＤＤＲ，ＤＳＴ＿ＡＤＤＲ，ＳＲＣ＿ＰＯＲＴ，
ＤＳＴ＿ＰＯＲＴ，ＰＲＯＴＯＣＯＬ｝
によって識別される。
【００３２】
ポートは、プロトコル（例えばＴＣＰ／ＩＰ、ＵＤＰ／ＩＰなど）によって割り当てられたソフトウェア要素であり、同じ組のコンピュータ（サーバとクライアント）間での多数のフローを区別するために使用される。ＦＬＯＷフィールドは、到着パケットのヘッダ・フィールドに含まれる情報と照合され、到着パケットの所属フローが識別される。ＡＣＴＩＯＮフィールドとＮＥＷ＿ＡＣＴＩＯＮフィールドは、後述するように、送出データ・パケットの出力ＱｏＳを決定するＱｏＳパラメータを含む。
【００３３】
例えば、ＭＱＬＶＳ（又はＤｉｆｆＳｅｒｖ）の場合を考えてみる。ＱｏＳパラメータの例として、ＴＯＳ値（又はＤＳＣＰ値）と出力キューとの間のをマッピングがある。この場合、ＱｏＳパラメータは、ＴＯＳ値とＱｕｅｕｅＩＤ値の対応リストとなる。
【００３４】
｛{ＴＯＳ＝１，ＱｕｅｕｅＩＤ＝４}，
{ＴＯＳ＝２，ＱｕｅｕｅＩＤ＝２}，．．．｝．
他の実施例にあっては、ＴＯＳ（又はＤＳＣＰ）値をＦＬＯＷフィールド３１０に追加することができる。この場合、ＱｏＳパラメータは、ＱｕｅｕｅＩＤそのものである。いずれにしても、出力キューは何らかの優先順位／廃棄設定が予め設定してあることを想定しており、キューへ特定のパケットを割り当てることは、パケットに対し特定の（所定の）ＱｏＳを直接与えることを意味する。
【００３５】
図４は、転送コントローラ２２６の処理の概略を示す。
ネットワーク１０からのデータ・パケットの到着によって処理が開始する。ネットワーク・インタフェース２２２は、パケットを受信してこれを転送コントローラ２２６に渡す。転送コントローラは、データ・パケットのヘッダを調べ、フロー制御テーブル２２７内の一致するエントリを検索する（ステップ４０２）。ペイロード中に「キー」が埋込まれており、この情報に対して検索を行なうことが想定されている。この場合、ＦＬＯＷフィールドは、単にＡ地点からＢ地点への「フロー」についての情報を含むだけではなく、データそれ自体のコンテンツ／セマンティックスに基づいた情報も含む。更に、上記ステップ４０２では、受信したデータ・パケットに含まれる送信元アドレスと、フロー制御テーブル内の各エントリのＦＬＯＷフィールド３１０の送信元アドレス・サブフィールド３１２とを照合し、且つ、受信したデータ・パケットに含まれる宛先アドレスと、フロー制御テーブルの各エントリにあるＦＬＯＷフィールド３１０の宛先アドレス・サブフィールド３１４とを照合する。ちなみに、ＦＬＯＷフィールド３１０内の他のサブフィールドも同様に照合する。
【００３６】
このように、ＦＬＯＷフィールドは、到着パケットのヘッダ・フィールドに含まれる情報を照合するための「キー」として使用される。つまり、各到着パケットについて、フロー制御テーブルで検索を行い、一致するエントリがＦＬＯＷフィールドに見付かった場合に、これに対応するＡＣＴＩＯＮを起こすことを意味する。更に、ワイルドカードの指定も可能である。例えば、ＳＲＣ＿ＡＤＤＲにおけるエントリ「ｘｘ．ｙｙ．ｚｚ．＊」は、ＩＰアドレス「ｘｘ．ｙｙ．ｚｚ．１」、「ｘｘ．ｙｙ．ｚｚ．３」などに一致させることができる。ワイルドカード自体は、「マスク」フィールドの導入により実現される。例えば、「２５５．２５５．２５５．０」の値をとるＳＲＣ＿ＡＤＤＲ＿ＭＡＳＫは、ワイルドカードフォーマットと同じ照合結果が得られる。
【００３７】
次に、受信データ・パケットのエントリが見付かったかどうかを判定するためのテストが行われる（ステップ４０１）。エントリが見付からなかった場合には、ステップ４１０において、データ・パケットをどう転送すべきかに関し、ＤＥＦＡＵＬＴ＿ＡＣＴＩＯＮが実行される。デフォルト動作では、例えば、パケットを転送することなく、単に廃棄するようにしてもよい。受信データ・パケットの処理は、ここで終了する。
【００３８】
ＦＬＯＷフィールド３１０の送信元と宛先アドレス・サブフィールドの両方が、受信データ・パケットに含まれる送信元と宛先のフィールドに一致した場合、一致エントリが見付かる。一致エントリが見付かると、処理はステップ４０３における第２のテストへ進む。ここで、一致エントリのＦＬＡＧフィールド３３０が調べられる。ＦＬＡＧフィールド３３０がセットされていない（例えば値「０」を含んでいる）場合、処理はステップ４０４へ進む。ステップ４０４では、受信データ・パケットがルータ装置１０２から送信（すなわち、転送）される。送信されるデータ・パケットの出力ＱｏＳは、一致エントリのＡＣＴＩＯＮフィールド３２０に含まれるパラメータにより決定される。データ・パケットの処理は、ここで終了する。
【００３９】
ステップ４０３に戻って、もし、ＦＬＡＧフィールド３３０が設定されていた場合（例えば「０」以外の値を含む場合）、処理はステップ４０５における更に別のテストへ進む。本発明のこの実施例にあっては、データ・パケットの所定部分に含まれる情報がテストされる。１実施例として、ＩＰパケット・ヘッダの特定フィールド（ビット）が使用され、例えば、ＩＰ（ｖ４）ヘッダのＴＯＳフィールドのＵＮＵＳＥＤビット、またはＩＰヘッダのＩＰ ＯＰＴＩＯＮＳフィールドが使用される。テストを容易にするため、データ・パケットの上記所定部分は、セット（例えば、「１」を含む）と非セット（例えば、「０」を含む）のどちらかをとる単一のビットであることが望ましい。上記所定部分がセットされていなければ、処理はステップ４０４に従って行なわれる。つまり、データ・パケットは、一致エントリのＡＣＴＩＯＮフィールド３２０に含まれるＱｏＳパラメータにより決定された出力ＱｏＳでもって送信される。パケットの処理は、ここで終了する。
【００４０】
データ・パケットの所定部分がセットされている場合、処理はステップ４０６へ進む。ここで、一致エントリのＮＥＷ＿ＡＣＴＩＯＮフィールド３４０に含まれる情報が、そのエントリのＡＣＴＩＯＮフィールド３２０に複写される。データ・パケットの所定部分に含まれる情報の有無の検出を契機に、ＮＥＷ＿ＡＣＴＩＯＮフィールドからＡＣＴＩＯＮフィールドへのコンテンツの複写が開始される。このようにして、付随するキューからのその後の送信に用いる出力ＱｏＳが変更される。
【００４１】
次に、ステップ４０８において、一致エントリのＦＬＡＧフィールド３３０をクリア（例えば、「０」にセット）する。前述のように、ステップ４０４において、一致エントリのＡＣＴＩＯＮフィールド３２０に含まれるＱｏＳパラメータにより決定された出力ＱｏＳでもって、データ・パケットが送信される。しかしながら、ＡＣＴＩＯＮフィールドに含まれるパラメータは、ここではＮＥＷ＿ＡＣＴＩＯＮフィールド３４０から取得したパラメータとなっている。つまり、ステップ４０４において、データ・パケットは新しいＱｏＳ設定でもって送信される。受信データ・パケットの処理は、ここで終了する。
【００４２】
図５は、本発明の第１実施例の変形例における転送コントローラ２２６内の処理フローを示す。
図４の処理フローの場合と同様、ネットワーク・インタフェース２２２経由のネットワーク１０からのデータ・パケットの到着によって処理が開始される。転送コントローラ２２６は、データ・パケットのコンテンツを調べてフロー制御テーブル２２７から一致エントリを探す（ステップ５０２）。受信データ・パケットに含まれる送信元アドレスは、フロー制御テーブル内の各エントリのＦＬＯＷフィールド３１０の送信元アドレス・サブフィールド３１２と照合される。同様に、受信データ・パケットに含まれる宛先アドレスも、フロー制御テーブル内の各エントリのＦＬＯＷフィールド３１０の宛先アドレス・サブフィールド３１４と照合される。ステップ５０１では、受信データ・パケットのエントリが見付かったかどうかを判定するためのテストが行われる。エントリが見付からなければ、ステップ５１０において、データ・パケットをどう転送するかに関して、ＤＥＦＡＵＬＴ＿ＡＣＴＩＯＮが取られる（ステップ５１０）。前述したように、デフォルト動作では、パケットを転送することなく、単に廃棄するようにしてもよい。受信データ・パケットの処理は、ここで終了する。
【００４３】
ステップ５０１のテストに戻って、ＦＬＯＷフィールド３１０の送信元と宛先のアドレス・サブフィールドが、受信したデータ・パケットに含まれる送信元と宛先フィールドに一致した場合、一致エントリが見付かる。一致エントリが見付かった場合、処理はステップ５０４へ進む。ここで、受信パケットはルータ装置１０２から送信される。送信されるデータ・パケットの出力ＱｏＳは、一致エントリのＡＣＴＩＯＮフィールド３２０に含まれるパラメータにより決定される。次に、処理はステップ５０３のテストへ進む。ここで、一致エントリのＦＬＡＧフィールド３３０が調べられる。もし、ＦＬＡＧフィールド３３０がセットされていない（例えば、値「０」を含む）場合は、送信済みとなっている上記受信パケットの処理を終了する。
【００４４】
一方、ＦＬＡＧフィールド３３０がセットされていた（例えば、「０」以外の値を含む）場合は、処理はステップ５０５において更に別のテストへ進む。本発明のこの実施例によれば、データ・パケットの所定部分に含まれる情報がテストされる。例えば、テストを容易にするため、データ・パケットの上記所定部分は、セット（例えば、「１」を含む）か非セット（例えば、「０」を含む）のどちらかをとる単一のビットであることが望ましい。上記所定部分がセットされていなければ、送信済みとなっている上記受信データ・パケットの処理が終了する。
【００４５】
データ・パケットの上記所定部分がセットされていた場合、処理はステップ５０６に進む。ここで、一致エントリのＮＥＷ＿ＡＣＴＩＯＮフィールド３４０に含まれる情報が、そのエントリのＡＣＴＩＯＮフィールド３２０へ複写される。一致エントリのＦＬＡＧフィールド３３０は、ステップ５０８でクリア（例えば、「０」にセット）される。データ・パケットの上記所定部分に含まれる情報の有無の検出を契機に、ＮＥＷ＿ＡＣＴＩＯＮフィールドからＡＣＴＩＯＮフィールドへのコンテンツの複写が開始され、次いで、送信済みとなっている上記受信データ・パケットの処理を終了する。
【００４６】
図５において概説した手法の利点は、ある出力キューについてルータが新しいＱｏＳ設定を有効にするのに多少時間を要する場合において明白となる。例えば、図４の処理で概説した事例のように、データ・パケットを送信する前にＱｏＳが再設定される場合、トリガ情報を含むデータ・パケットは新しいＱｏＳ設定の付与に要する時間だけ遅延されることになる。しかしながら、上記遅延は、図５に示したように、受信データ・パケットを直ちに送信し、それから新しいＱｏＳ設定の存在を検出するためのテストを行なうことにより回避できる。
【００４７】
本発明の第１実施例の更に別の変形例においては、トリガ情報を含むデータ・パケットを、実際のビデオ・データのペイロードをもつデータ・パケットとしてではなく、特別なデータ・パケットとして配送することができる。第１実施例のこの変形例にあっては、転送コントローラ２２６は、トリガイベントとなる特別なパケットの受信を検出するだけでよい。ＮＥＷ＿ＡＣＴＩＯＮフィールド内に通常含まれるパラメータは、フロー制御テーブル２２７とは別のメモリに格納されることになる。
【００４８】
図１に示したＭＱＬＶＳシステムを再度参照すると、ビデオ・サーバ１００はトリガ情報を含むデータ・パケットを作成する。更に詳しくは、ビデオ・サーバ１００は、データユニットを含む第１のデータ・パケット、すなわちＩフレーム・データを搬送するデータ・パケットの所定部分にビット（フラグ）をセットする。これは、送信ビデオ・データをパケット化するソフトウェアや、ファームウェア或いは論理回路において簡単に実施される。データ・サーバの他の応用例では、トリガ情報をいつどのように提供するか決定するため、他の適当な論理回路や、ファームウェア或いはソフトウェアの使用もあり得ることが理解されよう。
【００４９】
次に、図６には、本発明の第１実施例によるフロー制御テーブルの設定に使用されるＡＰＩが、代表的なＣ言語コードの一部を用いて図示してある。
関数コールＳｅｔ＿ＱｏＳ（）は、ＦＬＯＷデータ構造、ＡＣＴＩＯＮデータ構造、ＦＬＡＧデータ種別の３つの引数を取る。ＦＬＯＷデータ構造は、トリガ情報を含むデータ・パケットの送信元と宛先のアドレスを指定する。ＡＣＴＩＯＮデータ構造は、特にＦＬＯＷデータ構造に含まれる宛先アドレスに付随して、ルータ内で出力キューのＱｏＳを設定するためのパラメータを含む。ＦＬＡＧデータ種別は、ＱｏＳ設定を直ちに実行するのか、それともＱｏＳ設定を遅延させるのかを指定する。
【００５０】
図１、２に戻り、ビデオ・サーバがＱｏＳの変更が適切であると判断した場合、ビデオ・サーバは、ルータ装置１０２の制御部２１０にあるサービス・ソフトウェア２１２と通信する。上記サーバは、ＡＰＩ２１４へのサービス・ソフトウェア２１２によって、新しいＱｏＳ情報をフロー制御テーブルへ送信する。
【００５１】
一実施例では、サービス・ソフトウェア２１２は、例えば、Ｊａｖａのような可搬型（mobile）コードで書かれ、サービス開始時点でビデオ・サーバにより送信されたプログラムであってもよい。この場合、サービス・ソフトウェアとビデオ・サーバは、ネットワーク接続に通信路（例えば、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰなど）を維持することができる。
【００５２】
手法が更にすっきりとした別の実施例では、システム全体が分散コンピューティング環境に構築される。このような環境の一例は、ＣＯＲＢＡ（Common Object Request Broker Architecture）である。この場合、サービス・ソフトウェアとビデオ・サーバ（の一部）とを構成するオブジェクトは、ＴＣＰ／ＩＰに基づくＩＩＯＰ（Internet Inter-ORB Protocol; ORB: Object Request Broker）と呼ばれる機構を介して通信でき、物理的にはどのようなネットワーク接続（例えば、ＬＡＮやＷＡＮなど）でも実行可能である。
【００５３】
サービス・ソフトウェアは、ＡＰＩ関数コールＳｅｔ＿Ｑｏｓ（）にこの情報を使用する。更に詳しく説明すると、この情報はｔａｒｇｅｔ−ｆｌｏｗ引数、ｎｅｗ＿ａｃｔｉｏｎ引数、ｆｌａｇ引数を指定する。Ｓｅｔ＿Ｑｏｓ（）は、ｔａｒｇｅｔ＿ｆｌｏｗ引数に含まれる情報と一致する一致エントリをフロー・テーブルで検索する。ｆｌａｇ引数がＣＨＡＮＧＥ＿ＩＭＭＥＤＩＡＴＥであれば、ｎｅｗ＿ａｃｔｉｏｎ引数が、一致エントリのＡＣＴＩＯＮフィールド３２０に書き込まれる。もし、ｆｌａｇ引数がＣＨＡＮＧＥ＿ＳＹＮＣＨＲＯＮＯＵＳであれば、上記エントリのＮＥＷ＿ＡＣＴＩＯＮフィールドが、ｎｅｗ＿ａｃｔｉｏｎ引数からの情報で埋められ、これに対応するＦＬＡＧフィールド３３０がセットされる。
【００５４】
サービス・ソフトウェア２１２を用いて新しいＱｏＳ情報を通信する代わりに、同じ情報を含む特別なデータ・パケットを定義することができる。この場合、転送コントローラ２２６は上記特別なパケットを検出する。転送コントローラは、上記特別なパケットから情報を抽出し、これをフロー制御テーブル２２７の適当なフィールドへ直接供給するための論理回路、またはコードを含む。上記特別なパケットは、パケット内に、１ビットの「フラグ」を含む所定の位置を割り当てることによって定義できる。上記フラグは、パケットが新しいＱｏＳ情報を有する特別なデータ・パケットであることを示すために使用される。
【００５５】
図２、７、８は、本発明の第２実施例によるルータ装置１０２のパケット処理を示す。
図７は、フロー制御テーブル２２７の別の実施例を示しており、図３に示したフロー制御テーブルと類似のフィールドを有する。図７に図示したフロー制御テーブルは、エントリ１、２、３、．．．Ｎを含む。各エントリは、ＦＬＯＷフィールド７１０、ＡＣＴＩＯＮフィールド７２０、ＭＡＳＫフィールド７３０、ＮＥＷ＿ＡＣＴＩＯＮフィールド７４０からなる。ＦＬＯＷフィールド７１０は、更に、送信元アドレス・サブフィールド７１２と、これに対応する宛先アドレス・サブフィールド７１４とからなる。ＡＣＴＩＯＮ及びＮＥＷ＿ＡＣＴＩＯＮフィールドは、後述するように、送出データ・パケットの出力ＱｏＳを決定するＱｏＳパラメータを含む。ＭＡＳＫフィールドは、ビット・パターンである。
【００５６】
図８は、転送コントローラ２２６の処理の概要を示す。
ネットワーク・インタフェース２２２経由でネットワーク１０からのデータ・パケットの到着によって処理が開始される。転送コントローラは、データ・パケットのコンテンツを調べてフロー制御テーブル２２７から一致エントリを探す（ステップ８０２）。これは、受信データ・パケットに含まれる送信元アドレスとフロー制御テーブル内の各エントリのＦＬＯＷフィールド７１０の送信元アドレス・サブフィールド７１２とを照合し、且つ受信データ・パケットに含まれる宛先アドレスもフロー制御テーブル内の各エントリのＦＬＯＷフィールド７１０の宛先アドレス・サブフィールド７１４と照合することにより行なわれる。
【００５７】
受信データ・パケットについて、エントリが見付かったかどうかを判定するためのテストが行われる（ステップ８０１）。エントリが見付からなければ、データ・パケットをどう処理するかに関連して、ＤＥＦＡＵＬＴ＿ＡＣＴＩＯＮが取られる（ステップ８１０）。デフォルト動作では、例えば、パケットを転送することなく、単に廃棄するようにしてもよい。受信データ・パケットの処理は、ここで終了する。
【００５８】
ＦＬＯＷフィールド７１０の送信元と宛先アドレス・サブフィールドの両方が、受信データ・パケットに含まれる送信元と宛先のフィールドに一致した場合は、一致エントリが見付かる。一致エントリが見付かった場合、処理はステップ８０３における第２のテストへ進む。ここで、フロー制御テーブル２２７内の一致エントリのＭＡＳＫフィールド７３０がテストされる。ＭＡＳＫフィールド７３０のマスク値が全てゼロであれば、処理はステップ８０４へ進む。ステップ８０４では、受信データ・パケットがルータ装置１０２から送信される。送信データ・パケットの出力ＱｏＳは、一致エントリのＡＣＴＩＯＮフィールド７２０に含まれるパラメータにより決定される。パケットの処理は、ここで終了する。
【００５９】
ステップ８０３に戻って、ＭＡＳＫフィールド７３０に含まれる値がオールゼロでなかった場合、処理はステップ８０５における更に別のテストへ進む。本発明のこの実施例によれば、ＭＡＳＫフィールドは、同程度の大きさのマスク・フィールドを含むデータ・パケットの所定部分と比較される。図１に例示したＭＱＬＶＳシステムの場合、上記所定フィールドは、データ・パケットのＩＰヘッダに入っているサービス種別（ＴＯＳ）フィールドとすることができる。ＭＡＳＫがデータ・パケットの所定部分に一致しない場合は、処理はステップ８０４に従って行なわれる。ステップ８０４で、データ・パケットは、一致エントリのＡＣＴＩＯＮフィールド７２０に含まれるＱｏＳパラメータにより決定される出力ＱｏＳでもって送信され、これによりデータ・パケットの処理が終了する。
【００６０】
データ・パケットの上記所定部分がＭＡＳＫフィールド７３０に一致した場合、処理はステップ８０６へ進む。ここで、一致エントリのＮＥＷ＿ＡＣＴＩＯＮフィールド７４０に含まれる情報が、そのエントリのＡＣＴＩＯＮフィールド７２０に複写される。データ・パケットの上記所定部分における情報の存在が検出されたことを契機に、ＮＥＷ＿ＡＣＴＩＯＮフィールドからＡＣＴＩＯＮフィールドへのコンテンツの複写が開始される。
【００６１】
次に、ステップ８０８において、一致エントリのＭＡＳＫフィールド７３０がクリアされる（すなわち、全てゼロにセットされる）。データ・パケットは、ステップ８０４において、一致エントリのＡＣＴＩＯＮフィールド７２０に含まれるＱｏＳパラメータにより決定された出力ＱｏＳでもって送信される。しかしながら、ＡＣＴＩＯＮフィールドに含まれるパラメータは、ＮＥＷ＿ＡＣＴＩＯＮフィールド７４０から取得されたパラメータである。つまり、データ・パケットは、ステップ８０４において、新しいＱｏＳ設定でもって送信される。受信データ・パケットの処理は、ここで終了する。
【００６２】
図９は、本発明の第２実施例の変形例による転送コントローラ２２６内の処理フローを示す。
図８の処理フローと同様、ネットワーク・インタフェース２２２経由でネットワーク１０からのデータ・パケットの到着によって、処理が開始される。転送コントローラは、データ・パケットのコンテンツを調べてフロー制御テーブル２２７内の一致エントリを探す（ステップ９０２）。受信データ・パケットに含まれる発信元アドレスは、フロー制御テーブル内の各エントリのＦＬＯＷフィールド７１０の送信元アドレス・サブフィールド７１２と照合される。同様に、受信データ・パケットに含まれる宛先アドレスも、フロー制御テーブル内の各エントリにおいてＦＬＯＷフィールド７１０の宛先アドレス・サブフィールド７１４と照合される。ステップ９０１において、受信データ・パケットに対するエントリが見付かったかどうか判定するためのテストが行われる。もし、エントリが見付からなければ、ステップ９１０において、データ・パケットをどう処理するかに関連して、ＤＥＦＡＵＬＴ＿ＡＣＴＩＯＮが取られる。デフォルト動作は、例えば、パケットを転送することなく、単に廃棄するようにしてもよい。受信データ・パケットの処理は、ここで終了する。
【００６３】
ステップ９０１のテストに戻って、ＦＬＯＷフィールド７１０の送信元と宛先の両方のアドレス・サブフィールドが、受信データ・パケットに含まれる送信元と宛先フィールドに一致した場合、一致エントリが見付かる。一致エントリが見付かった場合、処理はステップ９０４へ進む。ここで、受信パケットがルータ装置１０２から送信される。送信データ・パケットの出力ＱｏＳは、一致エントリのＡＣＴＩＯＮフィールド７２０に含まれるパラメータにより決定される。処理は、ステップ９０３におけるテストへ進む。ここで、一致エントリのＭＡＳＫフィールド７３０が調べられる。もし、ＭＡＳＫフィールド７３０がオールゼロの場合、送信済みとなっている上記受信パケットの処理を終了する。
【００６４】
一方、ＭＡＳＫフィールド７３０がオールゼロではなかった場合、処理はステップ９０５における更に別のテストへ進む。本発明のこの実施例によれば、ＭＡＳＫがデータ・パケットの所定部分と比較される。上記所定部分がＭＡＳＫと一致しなければ、送信済みとなっている上記受信データ・パケットの処理を終了する。
【００６５】
データ・パケットの上記所定部分が一致した場合、処理はステップ９０６へ進む。ここで、一致エントリのＮＥＷ＿ＡＣＴＩＯＮフィールド７４０に含まれる情報が、そのエントリのＡＣＴＩＯＮフィールド７２０に複写される。ステップ９０８において、一致エントリのＭＡＳＫフィールド７３０がオールゼロにセットされる。データ・パケットの上記所定部分との一致検出を契機に、ＮＥＷ＿ＡＣＴＩＯＮフィールドからＡＣＴＩＯＮフィールドへコンテンツが複写され、送信済みとなっている上記受信データ・パケットの処理を終了する。
【００６６】
図９において概説した方法の利点は、或る出力キューについてルータが新しいＱｏＳ設定を有効にするのに多少時間を要するような場合において明白となる。図８の処理で概説したケースのように、もし、データ・パケットの送信前にＱｏＳが再設定された場合、複写の契機となるデータ・パケットは、新しいＱｏＳ設定の付与に要する時間だけ遅延される。しかしながら、上記遅延は、図９に示したように、受信データ・パケットを直ちに送信し、それから新しいＱｏＳ設定を有効にすることによって、回避することができる。
【００６７】
次に、図１０を参照すると、本発明の第２実施例によるフロー制御テーブルを設定するのに用いるＡＰＩが、代表的なＣ言語コードの一部を用いて図示してある。関数コールＳｅｔ＿ＱｏＳ（）は、ＦＬＯＷデータ構造、ＡＣＴＩＯＮデータ構造、ＭＡＳＫ引数の３つの引数を取る。ＦＬＯＷデータ構造は、トリガ情報を含むデータ・パケットの送信元と宛先のアドレスを指定する。ＡＣＴＩＯＮデータ構造は、特にＦＬＯＷデータ構造に含まれる宛先アドレスに付随して、ルータ内での出力キューのＱｏＳ設定用のパラメータを含む。ＭＡＳＫは、８ビットのビット・パターンである。
【００６８】
図１、２を参照すると、ビデオ・サーバは、ＱｏＳの変更が適切であると判断した時、ビデオ・サーバはルータ装置１０２の制御部２１０にあるサービス・ソフトウェア２１２と通信する。ビデオ・サーバは、ＡＰＩを用いてフロー制御テーブルへ新しいＱｏＳ情報を送信する。サービス・ソフトウェア２１２は、この情報をＡＰＩ関数コールＳｅｔ＿Ｑｏｓ（）に使用する。更に詳しくは、上記情報は、ｔａｒｇｅｔ＿ｆｌｏｗ引数、ｎｅｗ＿ａｃｔｉｏｎ引数、ｍａｓｋ引数を指定する。Ｓｅｔ＿Ｑｏｓ（）は、ｍａｓｋ引数に含まれる情報と一致するフロー・テーブル内の一致エントリを検索する。一致エントリのＮＥＷ＿ＡＣＴＩＯＮフィールド７４０は、ｎｅｗ＿ａｃｔｉｏｎ引数からの情報で埋められ、ｍａｓｋ引数の値が、一致エントリの対応するＭＡＳＫフィールド７３０に複写される。
【００６９】
サービス・ソフトウェア２１２を用いて新しいＱｏＳ情報を通信する別の方法として、同じ情報を含む特別なデータ・パケットを定義することができる。この場合、転送コントローラ２２６は、上記特別なパケットを検出する。転送コントローラに含まれる論理回路やソフトウェアなどが、パケットから上記情報を抽出し、これをフロー制御テーブル２２７内の適当なフィールドへ直接配送する。
【００７０】
図１１は、図７のフロー制御テーブルをセットするのに使用されるＡＰＩの変形例を示す。このＡＰＩの変形例は極めて一般的なものであり、マスク値を指定することに加え、到着データ・パケットの上記所定部分の位置をデータ・パケット内の任意の場所に定義することを可能にしている。上記所定部分は、パケット・ヘッダ内、またはペイロード自体の中で、指定された位置に指定された長さとすることができる。
【００７１】
関数コールＳｅｔ＿Ｑｏｓ（）は、ＦＬＯＷデータ構造、ＡＣＴＩＯＮデータ構造、ＭＡＳＫデータ構造の３つの引数を取る。ＦＬＯＷデータ構造とＡＣＴＩＯＮデータ構造は、前述したように定義される。ＭＡＳＫデータ構造は、ヘッダ及びペイロードの仕様に対応することができる。もし、上記所定部分をヘッダ内に配置すべき場合には、関連するデータ構造はＨＥＡＤＥＲ＿ＦＩＥＬＤである。このデータ構造は、ｍａｓｋ値を比較する箇所がデータ・パケットのヘッダ内のどのフィールドかを指定する。上記所定部分をペイロード内に配置すべき場合には、関連するデータ構造はＰＡＹＬＯＡＤ＿ＦＩＥＬＤである。このデータ構造は、ペイロードの始端を基点として、上記所定部分の開始位置を示すｏｆｆｓｅｔ＿ｐｏｓｉｔｉｏｎを指定する。ｆｉｅｌｄ＿ｌｅｎｇｔｈは、マスク値と比較すべきフィールドの長さを指定する。ＨＥＡＤＥＲ＿ＦＩＥＬＤまたはＰＡＹＬＯＡＤ＿ＦＩＥＬＤが指定されたか否かに関わらず、フロー制御テーブル内に格納すべきマスク値を指定するｆｉｅｌｄ＿ｖａｌｕｅが存在する。
【００７２】
図１２は、図７のフロー制御テーブルを設定するためのＡＰＩの更に別の変形例を示す。ここでは、Ｓｅｔ＿Ｑｏｓ（）の複数回の呼出または実行が可能である。実行のマスク値は、Ｃｏｍｍｉｔ＿Ｃｈａｎｇｅ（）への１回の関数コールによって設定できる。Ｓｅｔ＿Ｑｏｓ（）コールによって影響される各エントリが、上記マスク値を受け取る。
【００７３】
図１３は、フロー制御テーブル２２７がＱｏＳパラメータの複数エントリのベクトルを含んだ本発明の第３の実施例を示す。ＦＬＯＷフィールド１３１０とＡＣＴＩＯＮフィールド１３２０に加え、ＮＥＷ＿ＡＣＴＩＯＮ＿ＬＩＳＴフィールド１３５０が備わっている。ＮＥＷ＿ＡＣＴＩＯＮ＿ＬＩＳＴフィールド１３５０は、ＱｏＳ設定１３７０の配列へのポインタである。上記配列内の各エントリは、ＭＡＳＫフィールド１３３０と、ＱｏＳパラメータを含むＮＥＷ＿ＡＣＴＩＯＮフィールド１３４０とからなる。このように、フロー制御テーブル２２７内の或るエントリに対し、対応する出力キューに多数のＱｏＳ設定が存在し得る。選択される特定のＱｏＳレベルは、どのＭＡＳＫフィールド１３３０が受信データ・パケットの所定位置に含まれるビットパターンに一致するかによって決まる。
【００７４】
フロー制御テーブルのこの変形例を設定するためのＡＰＩは、図１０ないし図１２に示したＡＰＩの実施例に適当な変更を加えることによって、簡単に得られる。ＭＡＳＫとＡＣＴＩＯＮのデータ構造は、単一要素の構造に代えて、リストとなるよう変更できる。
【００７５】
図１３のフロー制御テーブルの変形例において、ＮＥＷ＿ＡＣＴＩＯＮ＿ＬＩＳＴは、継続モード（persistent mode）をもつことができる。前述の実施例において、ＭＡＳＫフィールドは、ＱｏＳ設定の変更時にクリアされる。例えば、図８のステップ８０８は、ＭＡＳＫフィールドをクリアするステップである。継続モードの動作では、それが明示的に消去されない限り、ＭＡＳＫフィールドは影響されることはない。これは、適当なＡＰＩを準備することによって実現可能である。
【００７６】
図１３のフロー制御テーブルに継続モードの特徴を備えることは、帯域要求パターンが既知となっているトラフィック・フロー状況で有用と思われる。例えば、ビデオ・ストリームの場合、ビデオ内の異なる場面で帯域要求が変化する。従って、ビデオコンテンツの関数としてネットワークの帯域要求を変化させることが可能である。更に、この情報は、ビデオ・ストリーム全体について決定することができる。図１４は、例えば、帯域要求が時間とともに変化する典型的なシーケンスを示す。
【００７７】
ビデオ・サーバ１００は、適当なＡＰＩにより、配列１３７０内のＱｏＳ設定リストからなるＱｏＳパラメータをもった図１３のフロー制御テーブルをプログラミングすることができる。これに代えて、特別なデータ・パケットでＱｏＳパラメータのリストを提供するために、適当なプロトコルを定義してもよい。
【００７８】
ビデオ送信中に、ビデオ・サーバが、適当なビデオ・データ・パケット内にマスク値を設定し、ビデオ送信の別々の場面で要求される帯域に応じてルータ装置１０２内のＱｏＳを選択する。例えば、各場面の最初のパケットに、その場面で必要とされるＱｏＳを選択するためのマスク値を持たせる。このパケットを受信すると、ルータはそれに合わせて出力ＱｏＳを設定する。ビデオの場面が変化した時、次の場面の最初のパケットが、ルータ内で適当なＱｏＳを選択する別のマスク値をもつ。このようにしてフロー制御テーブルを動的に調整することにより、ルータ資源を効率的に利用できる。ビデオの帯域要求が減ると資源を解放し、その逆の動作も行なうことにより、資源消費が最小限になる。
【００７９】
図６に示したＡＰＩも、同様の態様で使用することができる。場面の変化が発生しそうになると、その都度ビデオ・サーバがＣＨＡＮＧＥ＿ＩＭＭＥＤＩＡＴＥフラグを用いてＡＰＩを呼び出すことができる。
【００８０】
上述した議論はルータ装置以外のネットワーク機器を含むように容易に拡張できることが分かる。一般に、サービス・プロバイダは自分自身のルータを保有していない。ルータやスイッチは、ネットワーク・プロバイダにより保守されている。更に、サーバからクライアントへの通信路は、多数のネットワーク・ドメインを通過することがある。本発明は、サーバとクライアントの間の通信路に沿ったスイッチング装置、更に一般的にはネットワーク機器へ、当業者が容易に適用することができる。例えば、本発明に従って、サーバからクライアントへの通信路に沿った２以上のネットワーク機器のＱｏＳ設定を調整することができる。装置のアドレス情報は、着目ネットワーク機器（群）を識別するために簡単に組み込むことができるため、後続のＱｏＳパラメータをこれらの機器へ通信できる。多数のネットワーク機器が同じＱｏＳパラメータを共有できるような場合は、マルチキャスト送信を使用することができる。
【００８１】
上記のように、本明細書で開示したビデオ・サーバは、本発明の新規な特徴及び態様を提示する単なる一例に過ぎない。本発明は、一般のデータ・サーバに適用可能であり、ビデオ・サーバに限定されるものと解釈してはならない。
本発明により、データ・サービス・プロバイダは、データ通信資源のきめ細かな制御に基づく新規なサービスを立案することができる。
【００８２】
例えば、図１に図示したＭＱＬＶＳシステムにおいて、ＭＰＥＧのデータユニットの最初のパケットにのみ基づいてサービス変更を制限する代わりに、サービス・プロバイダは、ビデオ場面の変化時やトラフィック条件の変動時などに、ビデオコンテンツに基づいて時間刻みでサービス変更を制御することができる。サービスには、プロバイダの課金施策と請求施策の一方又は両方を含めることができ、クライアント端末の顧客は希望するサービス品質に基づいてプロバイダに料金を支払うことになる。
【００８３】
【発明の効果】
本発明は、ネットワーク資源の効率的利用を高めるために使用することができる。
【図面の簡単な説明】
【図１】本発明に従って動作するネットワーク上の代表的なデータ・サーバ・アプリケーションの簡略化されたシステム図である。
【図２】本発明に従って構成されたルータの簡略化されたブロック図である。
【図３】本発明の一実施例によるフロー制御テーブルを示す。
【図４】本発明の一実施例による転送コントローラにおいて行なわれる幾つかの処理の概略を示す。
【図５】上記転送コントローラの処理の変形例の概略を示す。
【図６】本発明によるフロー制御テーブルを設定するための特徴を強調するＡＰＩの１実施例を示す。
【図７】本発明の別の実施例によるフロー制御テーブルを示す。
【図８】本発明の別の実施例による転送コントローラにおいて行なわれる幾つかの処理の概略を示す。
【図９】転送コントローラの処理における変形例の概略を示す。
【図１０】図７のフロー制御テーブルを設定するための特徴を強調したＡＰＩの１実施例である。
【図１１】図７のフロー制御テーブルを設定するための特徴を強調したＡＰＩの変形例である。
【図１２】図７のフロー制御テーブルを設定するための特徴を強調したＡＰＩの更に別の変形例である。
【図１３】フロー制御テーブルの更に別の実施例を示す。
【図１４】ビデオ・ストリームにおける典型的な帯域パターンを示す。
【図１５】従来技術の代表的なメンテナンス・シーケンスを示す。
【符号の説明】
１００：サーバ、１０２：ルータ、１０４：クライアント端末、
２１０：制御部、２１２：サービスソフトウエア、２１４：アプリケーション・プログラム・インタフェース（ＡＰＩ）、２１６：コントローラ・ソフトウエア、
２２２：ネットワークインタフェース、２２４：バス／スイッチ、
２２６：転送コントローラ、２２７：フロー制御テーブル、
２２８：ルータコントローラ。
Claims (17)
- 複数のネットワーク機器とデータ通信するデータ・サーバを有するデータ供給システムにおける標的ネットワーク機器の現在のネットワーク機器属性の変更方法であって、
上記データ・サーバから上記標的ネットワーク機器に、少なくとも一つの新たなネットワーク機器属性を含む第１の情報を送信するステップと、
上記新たなネットワーク機器属性を上記標的ネットワーク機器内に保存するステップと、
上記データ・サーバが、データ・パケットに第２の情報の組み込み、該第２の情報を上記標的ネットワーク機器に送信するステップと、
上記標的ネットワーク機器が、上記第２の情報の受信に応答して、上記標的ネットワーク機器の現在のネットワーク機器属性を上記新たなネットワーク機器属性に従って変更するステップとからなり、
上記標的ネットワーク機器が、上記データ・サーバから新たに受信する特定フローのデータ・パケットを上記新たなネットワーク機器属性に従って転送制御するようにしたことを特徴とするネットワーク機器属性の変更方法。 - 前記第１の情報が前記標的ネットワーク機器のアドレスを含むことを特徴とする請求項１に記載のネットワーク機器属性の変更方法。
- 前記データ・サーバが、前記第２の情報の送信ステップで、前記第２の情報をクライアント宛のデータ・パケット、またはクライアント以外に宛てたデータ・パケットに組み込んで送信することを特徴とする請求項１または請求項２に記載のネットワーク機器属性の変更方法。
- 前記データ・サーバが、前記第１の情報の送信ステップで、前記第１の情報をクライアント宛のデータ・パケット、またはクライアント以外に宛てたデータ・パケットに組み込んで送信することを特徴とする請求項１〜請求項３の何れかに記載のネットワーク機器属性の変更方法。
- 前記標的ネットワーク機器が、前記第２の情報を含むデータ・パケットを宛先装置または別のネットワーク機器に転送するステップを含み、
前記現在のネットワーク機器属性から前記新たなネットワーク機器属性への変更ステップが、上記転送ステップの前または後で実行されることを特徴とする請求項１〜請求項４の何れかに記載のネットワーク機器属性の変更方法。 - 前記ネットワーク機器属性がＱｏＳ設定であり、前記第１の情報が少なくとも１つのＱｏＳパラメータを含むことを特徴とする請求項１〜請求項５の何れかに記載のネットワーク機器属性の変更方法。
- 前記標的ネットワーク機器が、各エントリに少なくとも１つのＱｏＳパラメータを含む複数エントリのリストを蓄積し、前記第２の情報が上記リストの索引情報を含み、前記ネットワーク機器属性の変更ステップが、上記索引情報に基づいて上記リストから検索された特定のエントリにおいて実行されることを特徴とする請求項６に記載のネットワーク機器属性の変更方法。
- １つ以上のネットワーク機器を有するネットワークを通してクライアントにデータを配送するように構成されたデータ・サーバによるサービス品質（ＱｏＳ）の設定方法であって、
上記データ・サーバが、少なくとも１つの標的ネットワーク機器に、１以上のＱｏＳパラメータを含むＱｏＳ設定を表わす第１の情報を送信するステップと、
上記データ・サーバが、第２の情報を含むデータ・パケットを上記標的ネットワーク機器に送信するステップと、
上記第２の情報の受信に応答して、上記標的ネットワーク機器が、現在のＱｏＳ設定を上記第１の情報に従った新たなＱｏＳ設定に変更するステップとからなり、
上記標的ネットワーク機器が、上記データ・サーバから新たに受信する特定フローのデータ・パケットを上記新たなＱｏＳ設定に従って転送制御するようにしたことを特徴とするサービス品質の設定方法。 - 前記第１の情報が、各エントリにＱｏＳ設定を表わす１以上のＱｏＳパラメータを含む複数エントリのリストとして、前記標的ネットワーク機器に送信されることを特徴とする請求項８に記載のサービス品質の設定方法。
- 前記第２の情報が、前記リストに含まれる複数エントリのうちの１つを識別する索引情報を含み、前記第２の情報を受信した前記標的ネットワーク機器が、上記索引情報で特定されたエントリが示すＱｏＳパラメータに従って、前記ＱｏＳ設定を変更することを特徴とする請求項８または請求項９に記載のサービス品質の設定方法。
- ネットワークへデータ・パケットを送信するように構成されたデータ・サーバと、上記ネットワークから受信したデータ・パケットを上記ネットワークに転送するように構成された少なくとも一つのネットワーク機器とからなるデータ供給システムであって、
上記データ・サーバが、上記ネットワーク機器に、該ネットワーク機器のサービス品質（ＱｏＳ）設定を表わす少なくとも一つのＱｏＳパラメータを含む第１の情報を送信するように構成され、
上記ネットワーク機器が、上記第１の情報を保存するためのメモリを有し、
上記データ・サーバが、上記ネットワーク機器に第２の情報を含むデータ・パケットを送信するよう構成され、
上記ネットワーク機器が、上記第２の情報の受信に応答して、現在のＱｏＳ設定を上記第１の情報が示す新たなＱｏＳ設定に変更するよう構成され、
上記ネットワーク機器が、上記データ・サーバから新たに受信する特定データフローのデータ・パケットを上記新たなＱｏＳ設定に従って転送制御するようにしたことを特徴とするデータ供給システム。 - ネットワークに接続され、該ネットワークとの間でデータ・パケットを送受信するネットワーク・インタフェース回路と、
上記ネットワーク・インタフェース回路に動作的に結合された制御部と、
現在のサービス品質（ＱｏＳ）設定を含むサービス制御情報を記憶するメモリとからなり、
上記制御部が、
外部から第１の情報として提供される１以上のＱｏＳパラメータを受信して、上記メモリに保存するための第１のプログラムと、
上記ネットワーク・インタフェース回路で受信したデータ・パケットの中から、第２の情報を含む受信データ・パケットを検出したとき、上記第１の情報として提供されたＱｏＳパラメータに従って、上記メモリに記憶された特定のサービス制御情報における現在のＱｏＳ設定を新たなＱｏＳ設定に変更するための第２のプログラムとを備え、
上記制御部が、上記ネットワーク・インタフェース回路が上記ネットワークから受信したデータ・パケットを上記メモリが示すサービス制御情報に従ってＱｏＳ制御するようにしたことを特徴とするネットワーク機器。 - 前記第２のプログラムが、前記第１の情報を含むデータ・パケットの転送前、または転送後に、前記メモリに記憶された現在のＱｏＳ設定を前記新たなＱｏＳ設定に変更するように構成されていることを特徴とする請求項１２に記載のネットワーク機器。
- 前記第１の情報として提供される１以上のＱｏＳパラメータが、少なくとも１つのデータ・パケットに組み込んで、前記ネットワーク機器に送信され、
前記第１のプログラムが、前記ネットワーク・インタフェース回路で受信したデータパケットの中から、上記ＱｏＳパラメータを抽出することを特徴とする請求項１２または請求項１３に記載のネットワーク機器。 - 前記データサーバが、ビデオサーバであり、前記第２の情報をＭＰＥＧのＩフレームを含むデータ・パケットに組み込んで、前記標的ネットワーク機器に送信することを特徴とする請求項１に記載のネットワーク機器属性の変更方法。
- 前記データサーバが、ビデオサーバであり、前記第２の情報をＭＰＥＧのＩフレームを含むデータ・パケットに組み込んで、前記標的ネットワーク機器に送信することを特徴とする請求項８に記載のサービス品質の設定方法。
- 前記データ・サーバが、ビデオサーバであり、前記第２の情報をＭＰＥＧのＩフレームを含むデータ・パケットに組み込んで、前記ネットワーク機器に送信することを特徴とする請求項１１に記載のデータ供給システム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/516331 | 2000-03-01 | ||
| US09/516,331 US6944169B1 (en) | 2000-03-01 | 2000-03-01 | Method and apparatus for managing quality of service in network devices |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001244987A JP2001244987A (ja) | 2001-09-07 |
| JP4410408B2 true JP4410408B2 (ja) | 2010-02-03 |
Family
ID=24055099
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000374073A Expired - Fee Related JP4410408B2 (ja) | 2000-03-01 | 2000-12-08 | ネットワーク機器のサービス品質管理方法及び装置 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6944169B1 (ja) |
| EP (1) | EP1133111B1 (ja) |
| JP (1) | JP4410408B2 (ja) |
| DE (1) | DE60140978D1 (ja) |
Families Citing this family (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8914022B2 (en) | 1992-03-06 | 2014-12-16 | Gogo Llc | System for providing high speed communications service in an airborne wireless cellular network |
| US8457627B2 (en) * | 1999-08-24 | 2013-06-04 | Gogo Llc | Traffic scheduling system for wireless communications |
| US8452276B2 (en) * | 2000-10-11 | 2013-05-28 | Gogo Llc | Differentiated services code point mirroring for wireless communications |
| GB0016185D0 (en) * | 2000-06-30 | 2000-08-23 | Nokia Networks Oy | Dynamic DSCP availability request method |
| US7111163B1 (en) | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
| US20020112244A1 (en) * | 2000-12-19 | 2002-08-15 | Shih-Ping Liou | Collaborative video delivery over heterogeneous networks |
| US20030033467A1 (en) * | 2001-08-08 | 2003-02-13 | Satoshi Yoshizawa | Method and apparatus for resource allocation in network router and switch |
| CN101772091A (zh) * | 2001-12-05 | 2010-07-07 | 高通股份有限公司 | 调整通信系统服务质量的系统与方法 |
| US7802008B2 (en) * | 2002-08-12 | 2010-09-21 | Matsushita Electric Industrial Co., Ltd. | Quality of service management in network gateways |
| US7743166B2 (en) * | 2003-04-04 | 2010-06-22 | Ellacoya Networks, Inc. | Scaleable flow-based application and subscriber traffic control |
| US20050021718A1 (en) * | 2003-05-09 | 2005-01-27 | Palliser Networks, Inc. | Centrally managed differentiated service |
| US20050005105A1 (en) * | 2003-06-24 | 2005-01-06 | Brown Larry Cecil | Remote access control feature for limiting access to configuration file components |
| FR2856813B1 (fr) * | 2003-06-27 | 2005-09-23 | Cit Alcatel | Traitement d'adresses de terminaux de communication, par integration et/ou extraction de caracteristiques d'interface de communication dans l'adresse |
| US20070261082A1 (en) * | 2003-08-22 | 2007-11-08 | Interuniversitair Microelektronica Centrum (Imec) | Method for operating a multi-media wireless system in a multi-user environment |
| US20060114836A1 (en) * | 2004-08-20 | 2006-06-01 | Sofie Pollin | Method for operating a combined multimedia -telecom system |
| FI116592B (fi) * | 2003-11-24 | 2005-12-30 | Nokia Corp | Päätelaitteen konfigurointi |
| US8442519B2 (en) | 2003-12-07 | 2013-05-14 | Gogo Llc | Spectrum sharing between an aircraft-based air-to-ground communication system and existing geostationary satellite services |
| US20060193327A1 (en) * | 2005-02-25 | 2006-08-31 | International Business Machines Corporation | System and method for providing quality of service in a virtual adapter |
| US8281351B2 (en) | 2005-04-29 | 2012-10-02 | Alcatel Lucent | System, method, and computer readable medium rapid channel change |
| US7636801B1 (en) | 2005-06-20 | 2009-12-22 | Symantec Operating Corporation | Coordination of quality of service in a multi-layer virtualized storage environment |
| US8259566B2 (en) * | 2005-09-20 | 2012-09-04 | Qualcomm Incorporated | Adaptive quality of service policy for dynamic networks |
| US7852853B1 (en) | 2006-02-07 | 2010-12-14 | Nextel Communications Inc. | System and method for transmitting video information |
| CN1859306A (zh) * | 2006-02-21 | 2006-11-08 | 华为技术有限公司 | 一种提供QoS服务的方法和系统 |
| WO2008015379A1 (en) * | 2006-07-31 | 2008-02-07 | British Telecommunications Public Limited Company | User prioritisation of communications traffic |
| US8194657B2 (en) * | 2007-05-22 | 2012-06-05 | Actiontec Electronics, Inc. | Systems and methods for dynamic quality of service |
| KR101545587B1 (ko) | 2009-01-15 | 2015-08-19 | 엘지전자 주식회사 | 화상 회의 시스템 및 그 방법 |
| KR101502014B1 (ko) * | 2009-01-15 | 2015-03-12 | 엘지전자 주식회사 | 화상 회의 시스템 및 그 방법 |
| US8270425B2 (en) * | 2009-12-29 | 2012-09-18 | Symbol Technologies, Inc. | Method and system for multicast video streaming over a wireless local area network (WLAN) |
| ES2556381T3 (es) * | 2011-06-04 | 2016-01-15 | Alcatel Lucent | Un concepto de planificación |
| US8873403B2 (en) * | 2012-02-21 | 2014-10-28 | Avaya Inc. | System and method for automatic DSCP tracing for XoIP elements |
| US9438524B2 (en) | 2012-02-29 | 2016-09-06 | Avaya Inc. | System and method for verifying multiprotocol label switching contracts |
| JP6060051B2 (ja) * | 2013-08-08 | 2017-01-11 | アラクサラネットワークス株式会社 | パケット中継装置及びパケット中継方法 |
| US9319307B2 (en) * | 2013-09-06 | 2016-04-19 | At&T Intellectual Property I, L.P. | Providing differentiated service to traffic flows obscured by content distribution systems |
| WO2016088244A1 (ja) * | 2014-12-05 | 2016-06-09 | 富士通株式会社 | サーバの画像配信方法 |
| US10103997B2 (en) | 2016-06-01 | 2018-10-16 | At&T Intellectual Property I, L.P. | Dynamic quality of service for over-the-top content |
| US11194558B2 (en) * | 2016-10-14 | 2021-12-07 | Accenture Global Solutions Limited | Application migration system |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5768527A (en) | 1996-04-23 | 1998-06-16 | Motorola, Inc. | Device, system and method of real-time multimedia streaming |
| GB2312592A (en) | 1996-04-24 | 1997-10-29 | Ibm | Quality of service parameters |
| FI103455B1 (fi) * | 1996-10-08 | 1999-06-30 | Nokia Telecommunications Oy | Pakettiverkon reititin |
| US6335927B1 (en) | 1996-11-18 | 2002-01-01 | Mci Communications Corporation | System and method for providing requested quality of service in a hybrid network |
| US6341309B1 (en) | 1997-05-27 | 2002-01-22 | Novell, Inc. | Firewall system for quality of service management |
| US6292465B1 (en) | 1997-05-27 | 2001-09-18 | Ukiah Software, Inc. | Linear rule based method for bandwidth management |
| US6104700A (en) | 1997-08-29 | 2000-08-15 | Extreme Networks | Policy based quality of service |
| US6226277B1 (en) | 1997-10-14 | 2001-05-01 | Lucent Technologies Inc. | Method for admitting new connections based on usage priorities in a multiple access system for communications networks |
| US6327254B1 (en) | 1997-10-14 | 2001-12-04 | Lucent Technologies Inc. | Method for bandwidth sharing in a multiple access system for communications networks |
| US6308216B1 (en) * | 1997-11-14 | 2001-10-23 | International Business Machines Corporation | Service request routing using quality-of-service data and network resource information |
| US6091709A (en) | 1997-11-25 | 2000-07-18 | International Business Machines Corporation | Quality of service management for packet switched networks |
| US6154776A (en) * | 1998-03-20 | 2000-11-28 | Sun Microsystems, Inc. | Quality of service allocation on a network |
| US6317438B1 (en) | 1998-04-14 | 2001-11-13 | Harold Herman Trebes, Jr. | System and method for providing peer-oriented control of telecommunications services |
| US6157955A (en) * | 1998-06-15 | 2000-12-05 | Intel Corporation | Packet processing system including a policy engine having a classification unit |
| US6246702B1 (en) | 1998-08-19 | 2001-06-12 | Path 1 Network Technologies, Inc. | Methods and apparatus for providing quality-of-service guarantees in computer networks |
| US6286052B1 (en) * | 1998-12-04 | 2001-09-04 | Cisco Technology, Inc. | Method and apparatus for identifying network data traffic flows and for applying quality of service treatments to the flows |
| US6466984B1 (en) * | 1999-07-02 | 2002-10-15 | Cisco Technology, Inc. | Method and apparatus for policy-based management of quality of service treatments of network data traffic flows by integrating policies with application programs |
| US6745246B1 (en) * | 2000-01-28 | 2004-06-01 | Advanced Micro Devices, Inc. | Apparatus and method in a network switch for modifying a bandwidth request between a requestor and a router |
| US6732168B1 (en) * | 2000-07-05 | 2004-05-04 | Lucent Technologies Inc. | Method and apparatus for use in specifying and insuring policies for management of computer networks |
| US6763392B1 (en) * | 2000-09-29 | 2004-07-13 | Microsoft Corporation | Media streaming methods and arrangements |
| US6661780B2 (en) * | 2001-12-07 | 2003-12-09 | Nokia Corporation | Mechanisms for policy based UMTS QoS and IP QoS management in mobile IP networks |
-
2000
- 2000-03-01 US US09/516,331 patent/US6944169B1/en not_active Expired - Fee Related
- 2000-12-08 JP JP2000374073A patent/JP4410408B2/ja not_active Expired - Fee Related
-
2001
- 2001-02-22 EP EP01104298A patent/EP1133111B1/en not_active Expired - Lifetime
- 2001-02-22 DE DE60140978T patent/DE60140978D1/de not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP1133111A3 (en) | 2007-01-03 |
| DE60140978D1 (de) | 2010-02-25 |
| JP2001244987A (ja) | 2001-09-07 |
| US6944169B1 (en) | 2005-09-13 |
| EP1133111B1 (en) | 2010-01-06 |
| EP1133111A2 (en) | 2001-09-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4410408B2 (ja) | ネットワーク機器のサービス品質管理方法及び装置 | |
| US10200251B2 (en) | Methods and apparatus for accessing selectable application processing of data packets in an adaptive private network | |
| US5461611A (en) | Quality of service management for source routing multimedia packet networks | |
| US20030031178A1 (en) | Method for ascertaining network bandwidth allocation policy associated with network address | |
| US7327681B2 (en) | Admission control method in internet differentiated service network | |
| US20030033467A1 (en) | Method and apparatus for resource allocation in network router and switch | |
| US7792140B2 (en) | Reflecting the bandwidth assigned to a virtual network interface card through its link speed | |
| US20020035641A1 (en) | Service allocating device | |
| US20010056459A1 (en) | Service assignment apparatus | |
| US20070008884A1 (en) | Immediate ready implementation of virtually congestion free guarantedd service capable network | |
| US20030033421A1 (en) | Method for ascertaining network bandwidth allocation policy associated with application port numbers | |
| JP2001045066A (ja) | ＩＰ通信ネットワークシステム及びＱｏＳ保証装置 | |
| WO2007010408A2 (en) | Next generation network for providing diverse data types | |
| US7773624B2 (en) | Network system and method with centralized flow behavioral mapping between layers | |
| JP4041038B2 (ja) | 高位レイヤ処理方法及びシステム | |
| EP1142202B1 (en) | System and method for providing flexible management of a network | |
| CN1643858B (zh) | 服务质量请求关联 | |
| JP3438857B2 (ja) | ネットワークの通信品質制御システム及びトラフィック管理装置 | |
| JP2000253053A (ja) | ネットワークシステム | |
| Yau et al. | Migrating sockets-end system support for networking with quality of service guarantees | |
| US20030099199A1 (en) | Bandwidth allocation credit updating on a variable time basis | |
| JP2003158544A (ja) | プログラマブル・ネットワーク・ルータ兼スイッチのための方法および装置 | |
| US20020184382A1 (en) | Method and apparatus for the dynamic regulation of resource splitting over a plurality of data streams competing for these resources in a communications network by a dynamic release rate | |
| JP3616621B2 (ja) | 通信品質割当システム | |
| JP2002305538A (ja) | 通信品質制御方法、サーバ及びネットワークシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050314 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070223 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070403 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070604 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20070604 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070821 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20091113 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121120 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121120 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131120 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |