(57)【特許請求の範囲】
【請求項１】
複数のスイッチおよび通信ネットワークに接続される複数のクライアントを有する前記通信ネットワークに接続されるホスト・プロセッサを有するビデオ、マルチメディアを含む連続的なコンテンツの配信システムにおいて、前記クライアントにより要求されたコンテンツを前記クライアントに伝送する方法であって、
前記クライアントのうちの１つが、前記ホスト・プロセッサに宛てて要求メッセージを伝送して前記コンテンツまたは前記コンテンツの一部を要求するステップと、
要求された前記コンテンツを格納した少なくとも１つの前記スイッチを識別するステップと、
前記ホスト・プロセッサから前記スイッチへと、前記コンテンツまたは前記コンテンツの一部を前記スイッチから前記クライアントのうちの１つへと送信するように指令し、かつ要求された前記コンテンツまたは前記コンテンツの一部を含まない制御メッセージを伝送するステップと、
前記クライアントのうちの１つへと前記スイッチの出力ポートを介して前記スイッチから事前処理されたパケットとして要求された前記コンテンツまたは前記コンテンツの一部の複製を伝送するステップとを含み、
前記コンテンツは、前記クライアントによって前記事前処理されたパケットから再アセンブルされ、その後、前記スイッチでの前記事前処理されたパケットとしての前記コンテンツは、前記スイッチの記憶手段に保持され、前記スイッチは、前記コンテンツを要求した前記クライアントのどれに対してでも独立して前記コンテンツを伝送させる切換手段と複数の出力ポートとを備える
方法。
【請求項２】
前記事前処理されたパケットは、前記コンテンツからのペイロードと、ネットワーク・プロトコル・スタックのヘッダ及びトレーラを含む、請求項１に記載の方法。
【請求項３】
複数のスイッチおよび通信ネットワークに接続される複数のクライアントを有する前記通信ネットワークに接続されるホスト・プロセッサを有するビデオ、マルチメディアを含む連続的なコンテンツを通信するデータ通信システムにおいて、前記クライアントにより要求されたコンテンツを前記クライアントに伝送するデータ通信システムであって、
前記クライアントのうちの１つが、前記ホスト・プロセッサに宛てて要求メッセージを伝送して前記コンテンツまたは前記コンテンツの一部を要求する手段と、
前記ホスト・プロセッサから前記スイッチへと、前記コンテンツまたは前記コンテンツの一部を前記スイッチから前記クライアントのうちの１つへと送信するように指令し、かつ要求された前記コンテンツまたは前記コンテンツの一部を含まない制御メッセージを伝送する手段と、
前記クライアントのうちの１つへと前記スイッチの出力ポートを介して前記スイッチから事前処理されたパケットとして要求された前記コンテンツまたは前記コンテンツの一部の複製をスケジュールする手段および伝送する手段と、
切換手段と複数の出力ポートとを備える前記スイッチに対して、前記コンテンツを要求した前記クライアントのどれに対してでも独立して前記コンテンツを伝送させ、その後でも前記スイッチの記憶手段に前記事前処理されたパケットとして前記コンテンツまたはその一部を記憶手段に保有させる手段と
前記コンテンツを、前記クライアントによって前記事前処理されたパケットから再アセンブルさせる手段と
を含むデータ通信システム。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明はマルチメディア・データ及びビデオ・データをサーバから通信ネットワークを介し要求クライアントに配布する方法及び装置に関する。
【０００２】
【従来の技術】
情報及び娯楽サービスをエンド・ユーザの家庭に配布するシステムは、３つの別個の構成要素、すなわち、サーバ・システム、エンド・ユーザ・システム、及び多数のエンド・ユーザ（クライアント）をサーバに同時に接続するネットワークを有する。情報を家庭に配布するために最も広範に使用される２つのシステムは、公衆電話網及び同報通信／ケーブル・テレビ・システムである。電話網は今日、様々な事務処理手順の命令などの音声セグメントの他に、預金残高などの電子的に記憶されたテキスト情報へのアクセスを提供する。
【０００３】
技術的な進歩が、対話式マルチメディア・サービスを可能にすると広く信じられている。検討されるサービスには、映画、ニュース、スポーツ、ＴＶ番組などのビデオ・オン・デマンド、家庭ショッピング、対話式ゲーム、旅行代理、及び広範な教育及び情報サービスが含まれる。しかしながら、従来の情報／娯楽配布システムの３つの全ての構成要素、すなわちサーバ、ネットワーク、及びエンド・ユーザ端末（ＰＣまたはセット・トップ・ボックス（set-top-box））は、対話式マルチメディア・サービスを配布するために改良を要する。ＰＣ及びセット・トップ・ボックスは、完全な動画ビデオ及び付随音声を受信し、伸長する能力を必要とする。各ユーザがサーバに対する自身の専用のビデオ・チャネルを有するように、ネットワークは十分な帯域幅を有さねばならず、またほとんどのサービスにおいて、サーバは非常に多数のビデオ・ストリームを低コストで同時に配布することができなければならない。
【０００４】
今日の電話網の主な欠点は、各エンド・ユーザが使用可能な帯域幅が制限され、これは高々１つの音声チャネルに十分であるに過ぎない。このことは動画ビデオ情報の転送を阻害し、また高解像イメージに対しては遅すぎる。ケーブル・テレビ及び同報テレビの両者は、各ユーザに非常に高い帯域幅を提供するが、ネットワークの制限総帯域幅（ケーブルの帯域幅または空間波に割当てられるスペクトル帯域幅）により、ユーザは自身が関心を持つ情報を対話式に選択することができない。代わりに、ユーザの選択は、任意の時間に放送される約５０の番組の１つに制限される。従って、現在の電話網、並びに同報テレビ及びケーブル・テレビの両テレビ網は、ビデオ・オン・デマンド及び対話式ゲームなどの対話式マルチメディア・サービスを配布するには好適でない。
【０００５】
しかしながら、電話及びケーブル・テレビ・サービスの提供側は、上記制限を除去するように、技術的進歩に投資を続けている。ＶＬＳＩ技術における集積化レベルの向上は、動画ビデオ圧縮／伸長ハードウェアのコスト低下に寄与し、ＡＤＳＬ（Asymmetric Digital Subscriber Loop）のような技術を可能にした。これらの２つ結果は、ユーザ家庭における動画ビデオの送受信、及び局所電話局における交換を実現し、各ユーザに専用のビデオ・チャネルを提供するようになる。同様に、光ファイバ伝送技術の進歩及びそのコスト低下は、ケーブルＴＶ網のトランク（trunk）及びフィーダ・システムのアップグレードを可能にし、それにより各アクティブ加入者に、圧縮デジタル・ビデオを受信するためのヘッド・エンドへの専用のチャネルを提供するように、ネットワーク帯域幅を十分に増加させる。直接放送衛星及び他の出現しつつある無線通信技術もまた、多数のエンド・ユーザとサーバとの間の専用のビデオ・チャネルを提供する。低コストのビデオ圧縮／伸長ハードウェア、及び新たな強力且つ安価なマイクロプロセッサを利用することにより、ネットワーク化マルチメディア・アプリケーションを可能にするパーソナル・コンピュータ及びセット・トップ・ボックスも出現しつつある。
【０００６】
エンド・ユーザ（クライアント）・システム及びネットワーク基盤は、対話式マルチメディア・サービスの要求に合致するように、急速に進化しつつあるが、現在使用されるサーバは未だに高価であり、その上、各サーバによりサポートされうるストリーム数の制限により、これらのサービスを配布するには現実的でない。対話式マルチメディア・サービスに対応するサーバのこれまでの選択は、オフザシェルフ（梱包済みですぐ使用できる状態）のメインフレーム、またはワークステーション技術ベースの並列コンピュータ・システムであった。両者の場合のハードウェア及びソフトウェアは、計算集中型アプリケーション及び複数同時ユーザ（タイム・シェアリング）をサポートするように最適化され、ネットワーク・インタフェース及び入出力装置との間のデータの転送に関しては、あまり重要視していない。例えば、ＲＳ／６０００におけるメモリからキャッシュへの帯域幅は４００Ｍバイト／秒であるのに対し、入出力装置またはネットワーク装置からシステムへの帯域幅は８０Ｍバイト／秒に過ぎない。浮動小数点のサポートは、ビデオ／マルチメディア・データの配布に関する利益をもたらすこと無く、システム・コストを押し上げる。ネットワーク・プロトコルは、より優れた最近のネットワーク上でのビデオに対する信頼性要求の軽減に反し、１９７０年代前半の低信頼性の低速ネットワーク・リンク、ネットワーク基盤、及びアプリケーション環境における確実なデータ転送のために最適化され、不要なＣＰＵオーバヘッドを招く。
【０００７】
上記要因は、汎用コンピュータ・システム・ベースのビデオ／マルチメディア・サーバの価格／性能を、ビデオの配布に最適化されたシステムに比較して高価／高度なものにする。上記制限を指摘する周知の活動は、これまで最小限にとどめられ、具体的には、ビデオ・サーバ・アプリケーションにおいてディスク・スループットを最大化するように、ディスク・アレイ上へのデータの配置を最適化するケース（参考文献［３］、［４］参照）、ビデオ・サーバ環境における再利用性を最大化するように、ディスクから検索されるデータをバッファリングするポリシを最適化するケース（参考文献［５］、［６］参照）、またはビデオ・データに対応してファイル・システムを最適化するケース（参考文献［７］参照）に限られた。こうした改良は、現ビデオ・サーバ・システムの価格／性能を２倍乃至４倍改良することができるが、対話式マルチメディア・サービスを経済的に可能性のあるものにするためには、１００倍乃至１０００倍の改良が必要とされる。
【０００８】
Hoartyらによる２つの特許（米国特許第５０９３７１８号及び同第５２２０４２０号）は、各々が隣合うクライアントをサービスする複数サーバを使用し、完全なマルチメディア・プログラムがこれらのサーバにオフロードされるケースを提案する。それに対し、本願では、マルチメディア・アプリケーションのビデオ内容配布部分だけを、ネットワーク内のスイッチまたはルータへオフロードする大型のサーバを使用する。アプリケーション制御、すなわち再生するビデオ・シーケンス及びその再生時期の決定は、請求書（bill）作成と同様に、中央サーバのサポート機能として維持される。
【０００９】
Hamilton及びNelsonによる米国特許第５２８７５０７号は、あるクライアントが別のクライアントにある情報の参照を送信したいときに発生する問題を指摘し、ポインタをサーバ内に記憶されるコピーへではなく、局所キャッシュ内に記憶される情報のコピーへ渡す。これは受信クライアントが、サーバ内に記憶される情報を指し示すポインタを再構成することを可能にする。本願の配布機構は局所キャッシュの存在を前提とせず、従って上記特許は本発明には関連しない。
【００１０】
Griffenらによる米国特許第５００５１２２号は、バックアップ、ソフトウェア配布などのサービスを提供するために、非常に多数のクライアント・コンピュータを含むネットワークにおいて、サーバ・コンピュータの使用を提案する。これは連続メディア情報の配布に対応したサーバの設計について指摘していない。
【００１１】
Chungによる米国特許第５２１８６９７号は、異なるオペレーティング・システムを実行する異種のファイル・サーバ、異なるファイル・サーバ、及び異なるファイル・システムのネットワークにおいて、中央ファイル・サーバを提供する方法を提案する。Chungは、局所ファイル・サーバが中央ファイル・サーバにファイル・サーバ要求を送信し、中央サーバがそれを適切なファイル・システム・コマンドに変換しなければならない従来方法によるのではなく、局所サーバが中央サーバにファイル・システム・コマンドを送信することにより、中央サーバのファイル・システムを直接アクセスできる方法を教示する。
【００１２】
Mooreによる米国特許第５２８７４６１号は、遠隔的にサーバを配置する。この方法は複数サーバのコンソール・ラインを多重化し、多重化情報を所望のロケーションに送信するためにモデムを使用する。
【００１３】
Changらによる米国特許第４８９７７８１号は、クライアントがオープンされたファイルのために局所キャッシュを有するネットワーク・ファイル・システムを教示する。この特許は、あるファイルから既にキャッシュされた情報を、異なるオープン・コマンドにより生成される同一ファイルへの別のアクセスのために利用する方法を教示する。
【００１４】
【発明が解決しようとする課題】
本発明の目的は、通信ネットワーク上において対話式マルチメディア・サービスを低コストで提供することである。
【００１５】
本発明のより特定の目的は、ビデオ内容をネットワークのスイッチにオフロードすることにより、ビデオ内容を要求クライアントに効率的に配布し、サーバから要求クライアントへのビデオ内容の配布に関連するオーバヘッドを低減することである。
【００１６】
【課題を解決するための手段】
本発明は、ネットワークの改良により、従来のアプローチに比較して、ビデオ・ストリームの配布コストを１００倍乃至１０００倍低減する方法を提案する。ここで提案される改良は、ビデオ／マルチメディア内容をネットワーク・パケット形式でネットワークのスイッチまたはルータに記憶することを可能にする。マルチメディア・アプリケーション・サーバが、要求ビデオまたはマルチメディア情報に対応するネットワーク・パケットを記憶するスイッチまたはルータに、制御メッセージを送信し、これらの１つまたは複数のパケットが指定クライアントに送信される。こうした命令を受信するスイッチまたはルータは、要求パケットを検索し、パケットのヘッダ及び可能であればトレーラ情報、特にネットワークがこれらのパケットを一連のルータを介して伝送し、指定クライアントにスイッチするための経路指定情報を変更し、これらのパケットをネットワーク上に送出する。数万のオーダの多数のストリームをサポートするために、半導体記憶装置により予めパケット化されたビデオを記憶し、特殊目的ハードウェアによりパケットを検索し、ヘッダ情報を変更する。図４のビデオ・ディスパッチャ、並びに後述のストリーム制御及び出力アダプタの説明を参照されたい。半導体記憶装置は、人気の低いビデオ内容を記憶するディスク記憶装置により増補されうる。数百から数千の少ないストリームをサポートするためには、ディスクだけの使用が可能であり、またパケットを検索し、ヘッダ情報を変更するために、特殊目的ハードウェアの代わりにマイクロコントローラ／マイクロプロセッサを使用することができる。
【００１７】
【実施例】
後述の実施例において、ビデオ／マルチメディアまたは連続メディア内容をオフロードするためのスイッチの使用について述べるが、こうした説明はスイッチの代わりに、ルータ／ブリッジなどの使用にも容易に適応化されうる。更に、ここでは固定サイズのセルだけを移送するパケット交換ネットワークの使用について述べるが、後述の実施例は可変サイズのパケットを移送するネットワーク、または回線交換網における使用にも容易に適応化されうる。本実施例では、ＡＴＭ（非同期転送モード）広帯域ネットワーク及びＡＡＬ５（ＡＴＭアダプテーション層）アダプテーション層を使用する（参考文献［１］参照）。最後に、本実施例では、圧縮形式で記憶されるビデオ情報の配布だけについて述べるが、当業者には非圧縮ビデオ情報、及び音声、動画などの他の連続メディア情報についても、本実施例の変更無しに処理できることが理解されよう。異なる音声またはビデオ情報は、異なるレートで圧縮されうる。例えば、音楽は音声よりも高いビット・レート（低い圧縮率）で圧縮されうる。連続メディア・ストリームは、ＭＰＥＧ−ＩＩ（Motion Picture Expert Group）トランスポート・ストリームとして多重化される異なるメディア・タイプの複数のストリームを含む。本実施例では、１ビデオ及び１音声チャネルをビデオ内容として運搬するＭＰＥＧ−ＩＩトランスポート・ストリームを使用する。ここではこのビデオの各１秒が４Ｍビットのデジタル・データに圧縮されるものと仮定する。
【００１８】
本発明の実施例は２つの別個の要素を有する。第１の要素は、ホストまたはアプリケーション・サーバから、ネットワーク内のスイッチへのビデオ内容のオフロードであり、第２の要素はビデオ内容を記憶し、ホストにより命令されると、それを指定クライアントにディスパッチすることのできるスイッチング・ハードウェアである。以降では、ビデオ内容がネットワーク内で記憶されるフォーマット、及びビデオ内容を検索しクライアントにディスパッチするために、スイッチ内で要求されるハードウェアを最小化するために、ビデオ内容と一緒に記憶される追加データについて述べられる。更に、ビデオを半導体記憶装置に記憶し、この記憶装置を割当て、再利用（reclaim）するオペレーションを実行し、またホストに要求されると、ビデオ内容の検索及びディスパッチをサポートするために、共用バッファ・スイッチ内で必要とされるハードウェア変更／追加についても述べられる。最後のセクションでは、共用バッファ・スイッチ以外のネットワーク・スイッチが使用され、半導体記憶装置の代わりにディスク記憶装置が使用される本発明の別の実施例を簡単に述べる。
【００１９】
ホストからネットワーク内スイッチへのビデオ内容のオフロード：
図１及び図２を参照すると、本発明の第１のステップは、ビデオ内容９００（図３）のＡＴＭ広帯域ネットワーク５０のスイッチ６０（図２）へのオフロードを含む。１時間番組のＭＰＥＧ−ＩＩトランスポート・ストリームは、約１．８ギガバイトのデジタル・データ９００である。ＵＮＩＸの様なオペレーティング・システム上で実行される汎用コンピュータに記憶されると、このデータ９００は４Ｋバイト・ページ９０１（図１）に区分化され、各々が４Ｋバイトを有する約４５万個のデータ・ブロック９１０を含む磁気ディスクなどに記憶される。ビデオ内容を表現するこれらのデータ・ブロックの他に、Ｉノード９１１及び間接ブロック９１２などのディスク上に、集合的にメタデータとして知られる他の情報が記憶されうる（参考文献［２］参照）。このメタデータ（図１に示される）は、ビデオ内容とは別に記憶される。すなわち、ビデオ内容を記憶するディスク・ブロックとは別のディスク・ブロックに記憶される。このメタデータは、特定のビデオ・ファイルに属するページを配置するために、またビデオ内容ファイルの指定領域データを記憶するページを配置するために、オペレーティング・システムにより使用される。
【００２０】
図８を参照すると、クライアント２０からネットワークのスイッチ６０を介し、ホスト１０に送信される要求メッセージ６が示される。この要求メッセージは好適には、ホスト上のビデオ配布プロシージャを呼出すために、クライアントにより発行される複数のパラメータを有する遠隔プロシージャ呼出しである。要求メッセージの第１のパラメータは、クライアントにより要求されるビデオ・ファイルの名前または索引であり、クライアント及びサーバの分散コンピュータ環境において実行される対話式マルチメディア・アプリケーションの実行の早い段階に、サーバによりクライアントに提供される使用可能なビデオ・ファイルのリストから選択される。要求メッセージ内の第２のパラメータは、ビデオ・ファイルの再生が開始する位置の、ビデオ・ファイルの開始からのオフセットを指定する。要求メッセージ内の第３のパラメータは、ビデオ・ファイルの再生が終了する位置の、ビデオ・ファイルの開始または開始オフセットからのオフセットを指定する。更に別のパラメータが、第３のパラメータ内のオフセットが、ビデオ・ファイルの開始または相対再生開始位置のいずれに関連するかを指定する。第２及び第３のパラメータ内のオフセットは、時間またはデータ・バイト数として表現されうる。遠隔プロシージャ呼出しは既知であるので、ここでは要求メッセージについてはこれ以上触れないことにする（参考文献［８］参照）。ホストは要求メッセージを処理し、後述のように、要求ビデオ内容がネットワーク・スイッチの１つに記憶されているかどうかを判断する。記憶されている場合、ホストは要求データを含む制御メッセージ８をスイッチに送信する（参考文献［２］、［６］参照）。制御メッセージに応答して、スイッチは制御メッセージ内で指定されるビデオ・パケットを検索し、これらのパケットをクライアントに配布する。
【００２１】
図２は本発明のシステムのハイレベル図を示し、ホスト１０、クライアント２０、及び複数のスイッチ６０を有するネットワーク５０を含む。ホストまたはアプリケーション・サーバ（通常は汎用コンピュータ）からビデオ内容９００（図１参照）をオフロードするために、本発明ではビデオ内容９００をビデオ・メッセージ９２０を生成するための固定サイズのペイロード９１５に区分する（図３参照）。ペイロード・サイズは通常１Ｋバイト乃至１６Ｋバイトであり、本実施例では１５２８バイトに選択される。このサイズのペイロードは、図３に示されるように、３２個のＡＴＭセル９３０に適合する。ホストまたはアプリケーション・サーバ内の各ペイロードは、ネットワーク・スイッチ・アドレス９２６及びスイッチ内のメッセージ・アドレス９２７を含むポインタ９２５により置換される（図２参照）。各こうしたポインタのサイズは、８バイト乃至１６バイトでありうる。ホスト内でポインタ９２５により表されるビデオ・メッセージ９２０自身は、図２に示されるように、ポインタのスイッチ・アドレス要素９２６により指定されるスイッチ６０内の、ポインタ内で指定されるメッセージ・アドレスに記憶される。
【００２２】
ビデオ内容９００を含むホスト内のファイルは、ネットワークのスイッチに記憶されるビデオ・メッセージを差すポインタ９２５を含むファイルとは異なり、またホストはこれらのファイルを異なって使用する必要があるので、ホストは特定のファイル・タイプをビデオ内容９００を含む全てのファイルに割当て、別のファイル・タイプをネットワークに記憶されるビデオ・メッセージを差すポインタ含む全てのファイルに割当てる命名変換を使用する。或いは、ホストは、全てのビデオ内容ファイルをリストし、かつファイルがビデオ内容であるか、或いはネットワークのスイッチに記憶されるビデオ・メッセージを差すポインタのリストであるかを示すエントリを有するテーブルを保持することができる。
【００２３】
ビデオ内容をネットワーク内のスイッチに記憶する以前に、図３に示されるように、８バイトのＡＴＭ  ＡＡＬ５コンバージェンス・サブレイヤ（ＣＳＬ）・トレーラ９３１が各ペイロード９１５に付加され、結果のバイトが一連のＡＴＭセル９３０を含むビデオ・メッセージ９２０に再フォーマットされる（ＡＴＭネットワークでは、ネットワーク・パケットはセルと呼ばれる）。同様に、非ＡＴＭパケット交換ネットワークでは、トランスポート層のヘッダ／トレーラがメッセージに付加された後に、必要に応じてセグメンテーションが実行され、メッセージがスイッチに記憶される以前に、ネットワーク層のヘッダ及び（または）トレーラがこれらのセグメントに付加される。
【００２４】
パケットがスイッチに記憶されるときに予め計算されうるネットワーク／トランスポート／アダプテーション層のヘッダまたはトレーラ内のフィールドが、予め計算され、適切なロケーションのＡＴＭセルに記憶される。本発明では、各メッセージの最後のパケットが８バイトのコンバージェンス・サブレイヤ（ＣＳＬ）・トレーラ９３１を有し、この部分にメッセージがスイッチに記憶される以前に、メッセージ長フィールド及びチェックサム・フィールドが予め計算され、ユーザ間指示（ＵＵ）フィールド及び共通部分指示（ＣＰＩ）フィールドがゼロにセットされる。これらの４つのフィールドは完全なＡＴＭ  ＡＡＬ５／ＣＳＬトレーラを表す。各ＡＴＭセル内の５バイトのヘッダ９３５内で、最後の半バイトだけが予め計算可能である。これらの４ビットはセル紛失優先順位及びペイロード・タイプを含み、ペイロード・タイプは、ＡＡＬ５  ＳＡＲ（セグメンテーション及び再アセンブリ）層におけるデータグラム・フィールドの１ビット・エンドを含む。上述のように、部分的に予め計算されたヘッダ／トレーラを有するＡＴＭセル９３０は、予め処理されたビデオ・パケットを含む。
【００２５】
ビデオ・メッセージ９２０はネットワーク内のフロー制御の基本単位であり、結果的に、ビデオ・メモリへのアクセス、及びビデオ・データのクライアントへの伝送における基本スケジューリング単位である。ビデオ・メモリから検索されたＡＴＭセルがビデオ・メッセージの最後のセルでない場合、スイッチはビデオ・メッセージ内の次のセルの検索を自動的にスケジュールする。ビデオ・メッセージのＡＴＭセルは、クライアントによりバーストとして受信される。なぜなら、スイッチは、伝送レートを制御するために、ビデオ・メッセージの２つのＡＴＭセルの伝送間で遅延を挿入しないからである。ビデオ・メッセージのサイズは、ネットワークの効率的なオペレーションのために、すなわち対話式マルチメディア・アプリケーションにおける迅速な応答時間を提供し、クライアントにおけるバッファ要求を最小化するために、制限される必要がある。しかしながら、短いビデオ・メッセージは、ホストとスイッチとの間で頻繁な対話を要求しうるので、より強力な（従って高価な）ホスト、及びより多数の制御メッセージを処理できるスイッチ内のハードウェアを要求する。
【００２６】
上記問題は、スイッチがホストから受信された単一の制御メッセージに応答して、複数のビデオ・メッセージをクライアントに送信できるようにすることにより解決される。この機能をサポートするために、各ビデオ・メッセージに対応して追加の情報が生成され、ネットワーク・スイッチ内のビデオ・メッセージに記憶される。この情報はリンク・フィールド９４０及びフロー制御フィールド９５０を含む（図３参照）。ビデオ・ストリーム９００の各ビデオ・メッセージ９２０内のリンク・フィールド９４０は、そのストリームの次のビデオ・メッセージを差す。従って、ホストまたはアプリケーション・サーバは、開始メッセージのアドレス及び続いて送信されるメッセージ数を指定する制御メッセージをスイッチに送信することができ、スイッチはリンク・フィールド９４０を用いて、続くメッセージを検索することができる。フロー制御フィールド９５０は、固定開始ポイントから参照した時の次のビデオ・メッセージの再生時間を含む。従って、スイッチはクライアントへのビデオ・データの配布のための適切なレートを維持するために、同一ストリームの２つのビデオ・メッセージの伝送の間に、正しい遅延を挿入することができる。
【００２７】
変更スイッチ・ハードウェア及びそのオペレーション：
このセクションでは、最初に、本実施例の基本となる共用バッファ・スイッチの設計及びそのオペレーションについて簡単に述べる。次に、スイッチに対しビデオを記憶する機能、及びホストにより命令されたときに、指定クライアントに指定ビデオ・パケットをディスパッチする機能を提供するための変更について述べる。最初に変更の無いスイッチについて述べるとき、これは本実施例には直接関係はしないが、後述されるスイッチの変更バージョンの説明において、本実施例との関係が明らかとなろう。
【００２８】
共用バッファ・スイッチ：
図４は共用バッファ・スイッチのハイレベル・アーキテクチャを示す。その中心部分には大容量の共用メモリ４００が存在し、メモリにデータを書込むための入力バス３００、及びメモリからデータを呼出すための出力バス３５０が接続される。入力バス３００及び出力バス３５０の両方とも、本実施例ではＡＴＭセルのサイズに等しい５３バイト幅である。各高速シリアル・リンク１００上を到来するパケット（ＡＴＭセル）は、入力アダプタ２００内で処理され、ＡＴＭセル・ヘッダが調査されて、パケットが経路指定されなければならないスイッチ出力１５０が決定され、ＡＴＭネットワーキング・メソッドに従い、セルのアドレス（ＶＰＩ（仮想パス識別子））フィールドとＶＣＩ（仮想回線識別子）フィールドがスワップされる（参考文献［１］参照）。この処理の後、入力アダプタ２００はパケットを単一の５３バイト幅のワードに非直列化し、これを入力バス３００上に出力する。同時に、入力アダプタ２００は、このパケットが転送されなければならないスイッチ出力１５０のアドレスを、出力アドレス・バス３１０上に出力する。パケットは次に、中央制御装置５００により独立に決定される共用メモリ４００内のロケーションに記憶される。バス帯域幅は全ての入力信号線の総帯域幅に合致する。共用メモリ４００は５３バイト・ワード４１０のアレイとして構成される。すなわち、読出し及び書込みオペレーションにおけるデータ転送の基本単位は、ＡＴＭセルのサイズに等しい５３バイトである。続く説明を容易にするために、共用メモリ内のこれらの５３バイト・ワードをセルと呼ぶことにする。各出力リンク１５０は、関連付けられる出力アダプタ２５０を有する。全ての出力リンクに対応する出力アダプタ２５０は、入力アダプタ２００により共用されるバス３００と同様に、時分割多重バス３５０により共用メモリに接続される。
【００２９】
共用メモリ４００内のフリー・セルのリストが、制御セクション５００により保持される。このリストはＦＩＦＯキュー５１０内に保持される。各出力リンク１５０は、制御セクション５００内に対応するＦＩＦＯキュー５２０を有する。これらのキューは論理的に別個であるが、単一の物理メモリを用いて実現されうる。キュー５２０は、対応する出力アダプタが共用メモリから検索し、ネットワークに配布しなければならないＡＴＭセルのアドレスを記憶する。入力パケットを共用メモリに記憶するために、フリー・セルのアドレスがフリー・セル・リスト５１０から獲得され、書込みアドレス・バス５３０上に出力される。同時に、このアドレスはフリー・セル・リスト５１０からデキュー（キューでの待機を解除）され、パケットの送信先のスイッチ出力１５０のアドレスを伝達する出力アドレス・バス３１０により選択されるアドレス・キュー５２０にエンキュー（キューに待機）される。出力アダプタ２５０は、それらの出力リンク１５０に送信される共用メモリに記憶されるパケットのアドレスを、中央制御装置５００の対応するアドレス・キュー５２０からデキューし、パケットを共用メモリから読出し、それを直列化して、出力リンク１５０上に移送する。アドレス・キュー５２０からデキューされたパケットのアドレスは、読出しアドレス・バス５４０上に出力され、同時にフリー・セル・リスト５１０内にリサイクル（再生利用）される。
【００３０】
入力バス３００の帯域幅は、全ての入力リンク１００の結合帯域幅に等しい。従って、入力バス３００のアービトレーションは不要である。代わりに、バスがスロット形式でオペレートされ、Ｎ個の入力アダプタの各々が、バスを毎Ｎスロット目ごとにアクセスする。本実施例では、スロットはクロック・サイクルに相当する。出力バス３５０も同様にオペレートされ、入力及び出力アダプタは、入力または出力バスへのアクセスを獲得するクロック・サイクル内でのみ、中央制御装置と対話する。各入力アダプタ２００内にはマイクロプロセッサ２１０が、また各出力アダプタ２５０内にはマイクロプロセッサ２６０が示される。これらは様々なリンク・モニタリング及びサービス機能を実行するために使用され、入力アダプタ内のマイクロプロセッサは、経路指定テーブルを管理するためにも使用される。これらは続く説明において、スイッチから配布されるビデオ・ストリームをサービスするためにも、有効に使用される。制御ポイント６００はワークステーションまたはＰＣクラスの汎用コンピュータであり、ネットワーク全体のトポロジ、リンク状態及びリンク利用度のデータベースの保守などのネットワーク管理機能の実行、新たに確立される回線に対するラベルの割当て、及びマイクロプロセッサ２１０及び２６０の初期化及びモニタのために使用される。制御ポイントはまた続く説明において、ビデオ内容を記憶するために使用されるメモリの割当て及び再利用にも、有効に使用される。
【００３１】
最後に、説明を容易にするために、ここでは共用バッファ・スイッチが、それぞれがマイクロプロセッサを有する別々の入力及び出力アダプタ、並びに別々の入力及び出力バスを有するように述べた。コンパクトな形態では、これらの２つのアダプタは単一のカードに結合され、１個のマイクロプロセッサが両方のアダプタをサービスし、入力及び出力バスの２倍の帯域幅を有する単一のバスが、入力及び出力バスを置換しうる。
【００３２】
ホストからの命令の受信に応じ、ビデオを記憶し、それをクライアントに配布するように変更された共用バッファ・スイッチ：
図５は、ビデオ・メッセージ９２０の記憶機能、及びホスト１０からの制御メッセージ８の受信に応じて、指定グループのメッセージを指定クライアント２０に配布する機能を提供するために、共用バッファ・スイッチにおいて要求されるハードウェア変更を示す。ビデオ・メッセージのＡＴＭセル９３０を図５の共用バッファ・スイッチに記憶するために、共用バッファ４００にビデオ・メモリ７００が増補される。共用バッファ４００及びビデオ・メモリ７００は、入力及び出力バス、アドレス・バス、及び書込み許可制御を共用する。リンク・フィールド９４０及びフロー制御フィールド９５０が、ビデオ・ディスパッチャ８００内に存在するタグ・メモリ８１０に別々に記憶される（図５及び図６参照）。
【００３３】
ビデオ・ディスパッチャ８００が図６に詳細に示される。ビデオ・ディスパッチャ８００は、制御メッセージ８（図７及び図８参照）を含むＡＴＭセルを、ホスト１０から直接受信することができる。これらの制御メッセージは入力アダプタ２００が信号７１７を活動化すると、インタフェース論理８７０により、入力バス３００から受信される。各制御メッセージ８は、図７に示されるように、ビデオ・メッセージ・グループ内の第１のＡＴＭセルのアドレス、そのグループの第１のビデオ・メッセージが配布されるべき時刻、グループ内のビデオ・メッセージの数、出力アダプタ・アドレス、及びストリーム番号を指定し、ビデオ・ディスパッチャに、中央制御装置５００'に１度に１個のＡＴＭセルに対する要求を発行することにより、中央制御装置５００'から指定出力アダプタ２５０'へ、グループ内の全てのＡＴＭセルを配布するように要求する。ＡＴＭセルを読出すための要求は、マルチプレクサ８２０を介してスケジューラ８１５により、制御メッセージ内で指定される時刻にディスパッチ・キュー８２５にエンキューされる。ビデオ・ディスパッチャはまたインタフェース論理８７１により、ＡＴＭセルへのカプセル化無しに、バス２７０上の出力アダプタ２５０'内のマイクロプロセッサ２６０から類似の命令を受信する。中央制御装置との対話の場合と同様に、入力及び出力アダプタは、入力バス３００または出力バス３５０をアクセスするサイクルにおいてのみ、ビデオ・ディスパッチャと対話するので、バス２７０、２７１及び７１７上ではアービトレーションが要求されない。これらのバスの使用については以降で詳述される。あるメッセージ・グループの第１のメッセージの配布時刻がビデオ・ディスパッチャに指定されると、残りの各メッセージの配布時刻は、タグ・メモリ８１０に記憶される以前のメッセージのフロー制御フィールドから獲得される。
【００３４】
ビデオ・ディスパッチャ８００は、ビデオ・メモリ７００からのＡＴＭセルに対する読出し要求を記憶するＦＩＦＯディスパッチ・キュー８２５を有する。ＡＴＭセルは、入力アダプタ２００からのアドレス・キュー５２０に対する競合により、即時中央制御装置５００にエンキューすることができない。ディスパッチ・キュー８２５内の各エントリは、３つのフィールドを有する。出力アダプタ・アドレス・フィールド８２６は、この読出し要求によりビデオ・メモリ７００から読出されるセルを受信する出力アダプタ２５０'を示し、ストリームＩＤフィールド８２７は、フィールド８２６で指定されてセルが読出されるアダプタ上のビデオ・ストリームを指定し、ビデオ・メモリ・アドレス・フィールド８２８は、セルが読出されるビデオ・メモリ内のアドレスを指定する。図５の出力アドレス・バス３１０の信号線３１５上のビットが非アクティブの時、これは中央制御装置と対話している入力アダプタが存在しないことを示し、エントリがディスパッチ・キュー８２５からデキューされる。出力アダプタ・アドレス・フィールド８２６の内容は、中央制御装置内のアドレス・キュー５２０を選択するために、バス７４５上に出力される。残りのフィールドすなわちストリームＩＤフィールド８２７及びビデオ・メモリ・アドレス・フィールド８２８は、バス７２５上に出力され、アドレス・キュー５２０への入力と多重化され、バス７４５上のアドレスにより選択されるアドレス・キュー５２０に記憶される。
【００３５】
ビデオ・ディスパッチャはまた、バス５４０上においてビデオ・メモリから読出される全てのセルのアドレス、及びそれらが属する出力アダプタ及びストリームＩＤを、セル・アドレス・モニタ８５０においてモニタする。信号線５８１は、セルがビデオ・メモリから読出されたことを示す。ビデオ・メモリから丁度読出されたセルがメッセージの最後のセルでない場合、セル・アドレスを増分器８５５により増分することにより、新たな要求が生成され、この要求はマルチプレクサ８２０を介し、ディスパッチ・キュー８２５に送信される。ビデオ・メモリから読出されたセルがメッセージの最後のセルの場合、そのメッセージのリンク・フィールド及びフロー制御フィールドが、バス５４０から受信されたストリームＩＤと一緒にタグ・メモリから読出され、このメッセージを受信する出力アダプタ２５０'に送信される。この情報はバス２７１上に送信され、ビデオ・メモリから新たなメッセージを要求するために、出力アダプタ２５０'内のマイクロプロセッサ２６０をトリガする。
【００３６】
ビデオ・ディスパッチャ８００及び入力アダプタ２００と対話し、ビデオ内容をロードするために、中央制御装置５００（図５の５００'）は次のように変更される。マルチプレクサ７２０が、フリー・セル・リスト５１０とアドレス・
キュー５２０との間に提供される。このマルチプレクサの１入力は、特定の入力アダプタにより現サイクル内に書込まれる共用バッファ４００内のフリー・セルのアドレスを伝達するバス５３０であり、このアドレスは出力アドレス・バス３１０によりアドレスされるアドレス・キュー５２０に待機されなければならない。他の入力はビデオ・ディスパッチャ８００からのバス７２５であり、このバスはビデオ・メモリ内のセルのアドレス及びストリームの識別番号を伝達し、これらの両者は、バス７４５により識別されるアドレス・キュー５２０に待機されなければならない。出力アドレス・バス３１０の信号線３１５上の１ビットは、出力アドレスが有効であることを示し、バス５３０に高位優先順位を提供するために使用され、それに従いマルチプレクサ７２０を制御する。制御ビット３１５はまた、バス５３０が選択されるときには、出力アドレス３１０を使用するように、またアドレス・キュー５２０に記憶される内容がバス７２５から選択されるときには、ビデオ・ディスパッチャによりバス７４５上に生成されるアドレスを使用するように、中央制御装置内のアドレス・マルチプレクサ７２０を制御する。本実施例では、ビデオ・ディスパッチャは、バス５３０の内容が異なるアドレス・キュー５２０に書込まれるときにも、アドレス・キュー５２０への書込みを阻止される。より複雑な論理の提供により、この欠点は回避されうる。アドレス・キュー５２０からデキューされたアドレスは、そのアドレスが共用バッファ４００のアドレスの場合に限り、フリー・セル・リスト５１０にリサイクルされる。制御論理７３０は、バス５４０上のアドレスが共用バッファのアドレス範囲内にあるかどうかをチェックし、この範囲内のアドレスだけをフリー・セル・リスト５１０にエンキューする。ビデオ・メモリ７００のアドレスは共用バッファ４００のアドレスよりも多くのビットを有し、ビデオ・ストリーム番号によりタグ付けされるので、アドレス・キュー５２０及びバス５４０は拡張される。
【００３７】
ホストからのビデオ・メモリのロード：
入力アダプタ２００からビデオ・メモリ７００に情報をロードするために、ロード・アドレス・バス７６０が制御ビット７６１と共に使用される。入力アダプタ２００内のマイクロプロセッサ２１０は、ホストからメッセージを受信し、メッセージ内に含まれるＡＴＭセルのシーケンスを、ビデオ・メモリのある開始アドレスからロードする。この開始アドレスもメッセージ内で指定される。それに応答して、ＡＴＭセルが入力バス上に出力され、これらのＡＴＭセルが記憶されるべきビデオ・メモリのアドレスが、ロード・アドレス・バス７６０上に出力されて、制御ビット７６１が活動化される。制御ビット７６１は、ビデオ・メモリの書込みアドレス５３２がバス５３０上のフリー・セル・リストからではなく、ロード・アドレス・バス７６０から選択されるように、中央制御措置５００'内のマルチプレクサ７１０を制御する。制御ビット７６１がアクティブの時、制御ビット３１５は非アクティブであり、ビデオ・ディスパッチャがアドレス・キュー５２０をアクセスすることを許可する。
【００３８】
共用バッファ・スイッチ内で制御ポイントとして使用される汎用コンピュータ６００'は、ビデオ記憶を割当て再利用するためのビデオ記憶マネージャとしても機能する。ホスト・コンピュータまたはアプリケーション・サーバは、フリー・ビデオ・メモリのブロックを要求したり、ビデオ・メモリのブロックを返却するために、ビデオ記憶マネージャと対話する。ビデオ記憶マネージャがビデオ・メモリ・ブロックをホストに割当て、そのブロックに対応するアドレス範囲を有するホストに通知すると、ホストは上述のように、ビデオ記憶マネージャからのそれ以上の掛かり合い無しに、割当てられたビデオ・メモリに直接書込むことができる。ホストからのビデオ・メモリ７００への書込み指示コマンドは、直接マイクロプロセッサ２１０に送信されるか、制御ポイント・プロセッサ６００'を介して、間接的にマイクロプロセッサ２１０に送信される。
【００３９】
ビデオ記憶マネージャは汎用コンピュータであるので、それとホストとの間の通信は、任意の標準の信頼のあるトランスポート・プロトコルを用いて発生し、所望の機密保護及び確認手段も使用されうる。ホストから入力アダプタ２００内のマイクロプロセッサ２１０へのメッセージはまた、安全なリンク上にも配布されることが可能で、キーの配布がビデオ記憶マネージャにより処理され、メッセージの解読がマイクロプロセッサ内で実行される。ホストからマイクロプロセッサ２１０に送信される２つの共通のタイプのメッセージは、ビデオ・メモリのロード、及びビデオ・ディスパッチャへのコマンドの送信のためのものである。これらのコマンド・メッセージが、肯定応答を返送するための適切な情報を含む場合に、マイクロプロセッサ２１０はホストに肯定応答を返送するようにプログラムされうる。ビデオ・メモリの断片化（fragmentation）は、多重プログラム式コンピュータにおいて主メモリを割当てるために提案されるバディ・システム法（buddy system method）を用いることにより、圧縮（compaction）を要求することなく処理されうる。
【００４０】
ビデオ・メモリからエンド・ユーザへのビデオ・データの配布：
上述のように、ビデオ・メッセージのグループを配布するためにホストから送信される制御メッセージ８は、入力アダプタ２００により横取りされ、入力アダプタ２００が次に、このコマンドをビデオ・ディスパッチャ８００に転送する。このグループのビデオ・メッセージの各ＡＴＭセルに対応して、ビデオ・ディスパッチャは中央制御装置に対し、ＡＴＭセルを読出し、それを正しい出力アダプタに配布するように、別々の要求を提示する。出力アダプタは、ビデオ・メモリから読出されたＡＴＭセルが出力リンク１５０上に送出される以前に、これらのヘッダ内のＶＰＩ／ＶＣＩフィールドを埋めなければならない。
【００４１】
ＡＴＭセルがビデオ・メモリ７００から読出され、出力アダプタ２５０'（図１０参照）に配布されるとき、ビデオ・ディスパッチャはこのセルのストリームＩＤをバス５４０から受信し、ストリームＩＤをバス２７１を介して、その出力アダプタに転送する。出力アダプタに配布されるＡＴＭセルが、ビデオ・メッセージの最後のセルの場合には、リンク・フィールド９４０及びフロー制御フィールド９５０も、ストリームＩＤと一緒に送信される。出力アダプタは、ビデオ・メモリから同時に受信されるＡＴＭセルのヘッダを、後述のように完成する。
【００４２】
出力アダプタは、ホストに返送するためのビデオ・メッセージの成功転送を示す肯定応答を生成することができる。大規模サーバにおける効率的な具現化では、この肯定応答は、ストリーム制御テーブルからの戻りアドレス及び他の関連情報を用いて、ハードウェアにより生成されなければならない。但し、メッセージ・グループ内のＡＴＭセル数が十分に大きい場合、従って、肯定応答の頻度がマイクロプロセッサ２６０により処理されうる場合を除く。
【００４３】
ビデオ・メモリの好適な具現化：
好適な実施例では、共用バッファ４００はスタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）・モジュールにより実現される。しかしながら、ビデオ・メモリは共用バッファよりも遥かに大きいので、コスト、電力、及びスペース制限（共用バッファのサイズが数メガバイトであるのに対し、ビデオ・メモリのサイズは数１００ギガバイトのオーダである）により、ＳＲＡＭ技術により実現することはできない。従って、ビデオ・メモリ７００は図９に示されるように、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）・モジュール７１０により実現される。好適には４乃至１６のＤＲＡＭモジュールが存在し、各モジュールは５３バイト幅である。本実施例では、４モジュールを使用する。ＤＲＡＭモジュールはＳＲＡＭモジュールのように、別々のデータ入力ポート及びデータ出力ポートを有さないために、ＤＲＡＭモジュールのデータ・ポートを入力バス３００及び出力バス３５０に接続するために、トライステート・ドライバ７１１及び７１２が使用される。マルチプレクサ４２０は、読出しアドレス５４０及び書込みアドレス５３２をアドレス・バス４２５上に多重化するために使用される。書込み許可信号５８５はマルチプレクサ４２０を制御し、またＳＲＡＭ及びＤＲＡＭモジュールに対する書込み許可制御を提供する。
【００４４】
ＤＲＡＭ制御装置７５０は、アドレス・バス４２５から受信されるアドレスを用いて、各ＤＲＡＭモジュールに対するアドレス信号及びチップ選択信号を生成する。更に、ＤＲＡＭ制御装置７５０は、ＤＲＡＭモジュールに対する行アドレス選択信号及び列アドレス選択信号を生成し、メモリ・リフレッシュ信号を提供する。
【００４５】
ＳＲＡＭのデータ・アクセス時間は、ＤＲＡＭのデータ・アクセス時間よりも遥かに短い。ＳＲＡＭに提供されるアドレスは、ＳＲＡＭ及びＤＲＡＭの両者に対して等しいアクセス時間を強要し、出力バス３５０に対する競合を回避するために、遅延素子４１０により遅延される。ＤＲＡＭモジュールに対するアクセス要求が、そのＤＲＡＭモジュールが以前の要求によりビジーであるために、即時受諾されない場合、要求受諾信号５８１がターンオフされ、それによりそのアドレスがアドレス・キュー５２０からデキューされることを阻止し、ビデオ・ディスパッチャ８００に対し、ビデオ・パケットが出力アダプタに送信されていることを伝える。ビデオ・メモリ内のＡＴＭセルは、ＤＲＡＭモジュールに渡ってインタリーブされる。
【００４６】
出力アダプタ：
変更出力アダプタ２５０'のハイレベル・アーキテクチャが図１０に示される。ＡＴＭセルは毎Ｎクロック・サイクル目ごとに、共用バッファまたはビデオ・メモリから出力バス３５０を介して受信される。ここでＮは出力アダプタの数である。論理ブロック２８２は、出力バス３５０上で受信されるＡＴＭセルを、３２ビット幅または１６ビット幅のバス２８３上に直列化する。論理ブロック２８４は、バス２８３上のＡＴＭセルが共用バッファ４００から到来している場合、ビデオ・ディスパッチャ８００により駆動されるバス２７１をモニタする。この場合、ＡＴＭセルは変更されずに、マルチプレクサ２８６を介して出力リンク・インタフェース論理２８８に渡され、出力リンク・インタフェース論理２８８が最終的にＡＴＭセルを出力リンク１５０上に伝送する。
【００４７】
バス２８３上のＡＴＭセルがビデオ・メモリから到来している場合、バス２７１はそのセルのストリームＩＤを含む。ストリームＩＤは論理ブロック２８４によりバス２８５上に出力され、そのＡＴＭセルのヘッダ情報を検索するために、ストリーム制御テーブル２８０を索引指示する。このヘッダ情報はバス２８９を介してマルチプレクサ２８６に転送され、マルチプレクサ２８６により、バス２８３上で受信されるＡＴＭセル内において代用される。論理ブロック２８４により生成される制御信号２８７は、このヘッダの代用を発生させる。
【００４８】
論理ブロック２８４は、共用バッファ４００から受信される各ＡＴＭセルのヘッダを走査し、ＡＴＭセルが出力アダプタ上のマイクロプロセッサ２６０にアドレス指定されるかどうかを判断する。アドレス指定される場合には、ＡＴＭセルは出力リンク・インタフェース論理２８８には転送されずに、マイクロプロセッサ２６０に送信される。これはホスト１０がマイクロプロセッサ２６０と通信して、ストリーム制御テーブル２８０を管理するための主要機構である。ホストによりマイクロプロセッサ２６０に送信される２つの主要コマンドは、ストリーム制御テーブルへの新たなエントリの生成、及びストリーム制御テーブルからのエントリの消去である（図８参照）。マイクロプロセッサ２６０は局所メモリ２６１を用いて、そのプログラム及びデータを記憶し、論理ブロック２８４と対話して、ストリーム制御テーブルの変更を生じる。ホストはストリーム制御テーブルを管理するためのコマンドを、直接マイクロプロセッサ２６０に送信するか、或いは制御ポイント・プロセッサ６００を介して送信する。
【００４９】
スイッチはホストから受信される各制御メッセージに応答して、複数のビデオ・メッセージをクライアントに配布しなければならないことは既に述べた。確認のための１つの方法は、上述のように、ホストに単一の制御メッセージにより、複数のビデオ・メッセージの配布を要求させることである。
【００５０】
別の方法は、ストリーム制御テーブル内の各ストリームのメッセージ・カウントを指定するか、時間を停止するか、或いはリンク・ポインタ値を停止することである。ホストは制御メッセージをビデオ・ディスパッチャに送信し、第１のビデオ・メッセージの配布を指定することにより、ストリームを開始する。ビデオ・メッセージの最後のＡＴＭセルが出力アダプタにおいて処理されるとき、ストリーム制御テーブルに記憶されるストリームのメッセージ・カウントが減分されるか、ストリームの停止時刻が代わりに指定される場合には、停止時刻がストリームの配布時刻と比較されるか、或いは、リンク・ポインタ停止値が、バス２７１上で受信されるリンク・フィールドと比較される。停止条件が合致すると、適切な肯定応答が生成され、ホストに送信される。それ以外では、リンク・フィールド及びフロー制御フィールドが、そのストリームの次のビデオ・メッセージを読出すための新たな要求を生成するために使用され、新たな要求がビデオ・ディスパッチャにバス２７０を介して送信される。ホストは停止条件の肯定応答を受信すると、ストリーム制御テーブルにおける停止条件のリセットを指示するコマンドを出力アダプタに送信し、そのストリームにおいて配布された最後のメッセージに続くビデオ・メッセージの送信を指示する制御メッセージをビデオ・ディスパッチャに送信することにより、ビデオ・ストリームの配布を継続することができる。
【００５１】
ホストが複数のビデオ・メッセージの配布を要求するための、上述の２つの異なる方法の提供は、最初は不要に思われよう。しかしながら、第１の方法では、ホストが、ビデオ・ディスパッチャに直接送信される制御メッセージ内で、複数のビデオ・メッセージを要求し、第２のアプローチに比較して、短いビデオ・ストリームが非常に小さな待ち時間スタートアップを有することができる。それに対し第２のアプローチでは、ホストがクライアントへのビデオ・メッセージの配布を開始する以前に、最初に正確な停止条件をストリーム制御テーブル内にセットアップしなければならないので、スタートアップ待ち時間が大きい。しかしながら、第１のアプローチの欠点は、ホストが、指定数のビデオ・メッセージをクライアントに送信するように指示する制御メッセージをスイッチに送信すると、ホストはスイッチが全てのビデオ・メッセージの配布を完了するのを中断することができず、また全てのビデオ・メッセージが配布されるまで、再生モードを変更することができない。一方、ホストは再生モード、停止条件を変更するために、或いは新たな開始ポイントを指定するために、任意の時にストリーム制御テーブルを変更することができる。第１のアプローチは、アプリケーションがホストにスイッチと頻繁に対話するように要求する場合に好適である。なぜなら、このアプローチは低いオーバヘッド及びストリーム・スタートアップ待ち時間を提供するからである。第２のアプローチは、ホストとスイッチとの間の対話が稀である場合に好適である。なぜなら、このアプローチはホストがビデオ・メッセージの転送の制御を保持することを可能にするからである。
【００５２】
逆方向再生、早送り及び早戻しのサポート：
上述の説明では、正規の再生におけるビデオの配布方法について述べた。これを達成するために、１つのリンク・フィールド及び１つのフロー制御フィールドが使用された。多重再生モードをサポートするためには、複数のビデオ・メッセージが複数のリンク・フィールド及び複数のフロー制御フィールドを要求する。このセクションでは、最初に、多重再生モードをサポートするために、ビデオ・メッセージが一緒にリンクされる方法について述べる。これはしばしば、各ビデオ・メッセージ内の複数リンクを用いて実施される。各リンク・フィールドは常にその固有のフロー制御フィールドと関連付けられ、フロー制御フィールドは、そのリンクにより指示されるビデオ・メッセージをスケジュールするときに、スイッチが導入すべき遅延を指定する。メッセージのリンク方法に続き、スイッチ内にリンク・フィールド及びフロー制御フィールドを記憶するためのスペース効率のよい方法について述べる。
【００５３】
ＭＰＥＧアルゴリズムにより圧縮されるビデオ・ストリームでは、圧縮フレームには、内部符号化（Intra coded）、予測符号化（Predictive coded）、及び双方向予測符号化（Bidirectionally predictive coded）の３つのタイプがある。内部符号化フレーム（Ｉフレーム）は追加情報無しに復号化されうるが、予測符号化フレーム（Ｐフレーム）の復号化には、先行する復号化Ｉフレームが必要となる。双方向予測符号化コード（Ｂフレーム）の復号化は、先行する復号化ＩフレームまたはＰフレームの他に、後に続く復号化ＩフレームまたはＰフレームを必要とする。
【００５４】
図１５は、ビデオ・ストリーム内のフレーム（ピクチャ）・シーケンスを示す。これはフレームが捕獲され表示される順序に対応し、ここではこの順序をプレゼンテーション順序と呼ぶことにする。しかしながら、Ｂフレームに相当する第２のフレームは、このフレームに続く最初のＰフレームまたはＩフレームである５番目のフレームが復号化されるまで、復号化され得ないことが容易に理解されよう。従って、ビデオ・ストリームのフレームが復号化される順序（復号化順序として参照される）は、プレゼンテーション順序とは異なる。図１６を参照すると、矢印は左から右にプレゼンテーション順序に従いリストされるフレームの復号化順序を示す。本実施例では、ビデオ・ストリーム内の圧縮ピクチャ・フレームが復号化順に記憶され、従って復号化順にクライアントに送信される。順方向リンク９４１によりアクセスされるビデオ・メッセージにおいて、圧縮ピクチャ・フレームは復号化順に表される。
【００５５】
ビデオの逆方向再生をサポートするために、図１７に示される圧縮ピクチャ・フレーム（順方向再生におけるプレゼンテーション順序に従い左から右にリストされる）はクライアントに送信され、逆方向リンク９４２により示される順序で復号化され、クライアントにより右から左に向けて表示される。ビデオ・メッセージをアクセスするために逆方向リンクが使用される場合、圧縮ビデオ・フレームは図１７に示されるように、ビデオを逆方向に再生するための復号化順序に従い現れる。ビデオ・メッセージは固定サイズであるので、ピクチャ・フレームの開始及び終了は、ビデオ・メッセージ境界に整列されない。従って、ビデオ・メッセージが例えば逆方向再生、早送り及び早戻しなどの正規の再生モードとは異なる順序でアクセスされるとき、ビデオ・フレームの最初と最後のビデオ・メッセージが、余分なデータを含むことになる。この場合、クライアントは余分なデータを廃棄するようにプログラムされるか、或いは埋込みバイトがビデオ・メッセージ内で、ピクチャ・フレーム境界をビデオ・メッセージに位置合せするように使用されなければならない。逆方向リンクは、フレームの終りを含まないビデオ・メッセージとは一緒に記憶されない。なぜなら、これらのフレームでは、順方向リンク及び逆方向リンクが同一であるからである。
【００５６】
早送り及び早戻し機能が、逆方向再生と同様にサポートされる。図１８を参照すると、リンク９４３は、Ｉフレーム・データを含む最後のビデオ・メッセージを、次のＩフレーム・データを含む最初のビデオ・メッセージにリンクする。リンク９４３がデータをアクセスするために使用され、Ｉフレームが検索されて、そのＩフレームが、正規の再生時にクライアントにより受信されるレートよりも高速のレートでユーザに配布されるとき、早送り効果が達成される。正規の再生では、クライアントは通常１秒につき２つのＩフレームを受信するので、この方法は早送り速度が通常の再生速度の約１５倍であれば、有用である。もっと遅い速度の早送りをサポートするためには、図１８に示されるように、リンク９４４により、全てのＩ及びＰフレームをリンクすればよい。リンク９４５及び９４６は図１８に示されるように、同様にして、巻戻し機能を２つの異なる速度でサポートするために使用される。再度、リンク９４３及び９４５はＩフレームの終りを含むビデオ・メッセージ内に存在し、リンク９４４及び９４６はＩフレームまたはＰフレームの終りを含むビデオ・メッセージ内に存在する。これらのリンクがビデオ・メッセージ内に記憶されていない場合、順方向リンクが使用される。最後に、リンク９４３及び９４４は、リンク９４５及び９４６によりそれぞれ共用されうる独自のフロー制御フィールドを有する。
【００５７】
各ビデオ・メッセージは異なる数のリンク・フィールドを有するので、各ビデオ・メッセージ内に、最大可能な数のリンク・フィールドに対応する記憶領域を提供することは無駄である。要求記憶領域を最小化するために、リンク・フィールドはフロー制御フィールドと一緒に、ビデオ・ディスパッチャ内のタグ記憶領域にコンパクトに記憶され、各ビデオ・メッセージのリンクを差す固定サイズのポインタが、ビデオ・ディスパッチャに追加されるタグ・ポインタ記憶領域に記憶される。そしてビデオ・メッセージのアドレスが、タグ・ポインタ記憶領域からポインタを獲得するために使用され、次にこのポインタが、タグ記憶領域からそのビデオ・メッセージに対応するリンクをアクセスするために使用される。タグ・ポインタ記憶領域の各エントリは、タグ記憶領域を差すポインタの他に、マスク・エントリを有する。マスクは存在するリンクを示す。
【００５８】
最後に、逆方向、早送り及び早戻し再生モードをサポートするために、ホストからビデオ・ディスパッチャに送信される制御メッセージに、余分なフィールドが追加される。このフィールドは再生モードを指定する。再生モード情報はＡＴＭセル・アドレス（及びストリームＩＤ）と共に、バス７２５及び５４０上で伝達され、ＡＴＭセル・アドレスと一緒にアドレス・キュー５２０に記憶される。従って、ビデオ・メッセージの最後のＡＴＭセルがビデオ・メモリから検索されるとき、次のビデオ・メッセージへのリンク及び対応するフロー制御フィールドが、直前に送信されたビデオ・メッセージに対応して記憶された一連のリンクから、再生モード情報を用いて選択される。
【００５９】
別の実施例：
上述のセクションで述べられた実施例では、共用バッファ・スイッチ設計を使用し、ビデオ記憶装置が共用バッファ自身の拡張として実現され、共用記憶装置から検索されるビデオ・パケット（セル）が、スイッチの出力アダプタに転送された。このセクションでは、各々が予めパケット化されたビデオ情報をネットワーク内のスイッチに記憶する、上記実施例の３つの別の態様について簡単に述べることにする。
【００６０】
バッファがスイッチの出力アダプタ内に提供され、これらのアダプタにおいて出力アダプタの概略の機能を実行する処理能力が使用可能であれば、たとえ共用バッファ設計に基づかないビデオ記憶装置であっても、このスイッチに接続されうる。図１１及び図１２は、半導体メモリをこうしたスイッチに統合する一般的な方法を示す。図１１は入力リンク６１を有する総称スイッチを示し、このスイッチはスイッチ・ハードウェア１０００及びその制御回路１１５０の他に、出力キュー１２５０を有する。図１２は、ビデオ・メモリ７００がこのスイッチに追加された様子を示し、ビデオ・メモリ７００はビデオ・ディスパッチャ８００を介して、直接出力キューに接続される。上述された実施例とは異なり、ビデオ・データはビデオ・ディスパッチャにより出力アダプタに送信され、これは正規のネットワーク・トラフィックとは異なるバスを介して出力アダプタに至る。ビデオ・メモリ・マネージャ１６００もビデオ・データを受信し、それをビデオ・メモリ７００に書込む。それ以外のオペレーションについては、共用バッファ・スイッチに基づく上述の実施例の場合と同様である。
【００６１】
上述したように、半導体メモリが出力アダプタに直接接続され得ない場合、図１３に示すように、スイッチの入力リンクが半導体記憶装置を接続するために使用される。ビデオ記憶装置７００''がスイッチの入力に接続されるポート８００''により、多重ポート化される。入力アダプタは、ビデオ・ディスパッチ論理を組込むように変更される。変更された各入力アダプタ２００''はストリーム制御テーブルを有し、このテーブルを介してアクセスされるビデオ・ストリームに対し、ビデオ・ディスパッチ機能を処理する。出力アダプタ２５０''は、スイッチ・ハードウェアとのインタフェースがもはや幅広の共用バスでない以外は、２５０と同様である。このアプローチでは、ビデオが入力及び出力アダプタの両者を通じて移動するので、同一のスループットをサポートするために、より多数のスイッチング・ハードウェアを必要とする欠点を有する。それに対し、前セクションで述べた設計では、スイッチは少ない入力アダプタを有することができる。なぜなら、トラフィックがもっぱら、出力アダプタに直接統合されるビデオ・データであるからである。使用される入力アダプタの数が少ないと、入力アダプタのハードウェアの節約だけでなく、小さなスイッチが使用可能になる点でも、節約が達成される。
【００６２】
最後に、全ての上述の設計において、特にサポートされるストリーム数が余り大きくない場合には、半導体記憶装置の代わりに、ディスク７９０のアレイに基づく記憶装置が使用されうる。小容量の半導体バッファ７９５が、アクティブのビデオ・ストリームにより現在アクセスされているビデオ・セクションをプリフェッチする。このプリフェッチは正確にスケジュールされうる。なぜなら、ビデオ・データへのアクセスは、もっぱら順次的であるからである。システムの残りの要素に対しては、バッファは全てのビデオ内容の完全なソースであるように見える。図１４はこのアプローチを示す。
【００６３】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００６４】
（１）複数のスイッチ及び通信ネットワークに接続される複数のクライアントを有する前記ネットワークに接続されるホスト・プロセッサを有するデータ通信システムにおいて、要求データを要求クライアントに伝送する方法であって、
複数の選択データを少なくとも１つの前記選択スイッチに記憶するステップと、
前記要求データを前記要求クライアントに送信するための要求メッセージを、前記要求クライアントから前記ホスト・プロセッサに伝送するステップと、
前記要求データが前記選択データの１部の場合、前記要求データを前記要求クライアントに送信する要求を示す制御メッセージを、前記ホスト・プロセッサから、前記要求データを記憶する前記選択スイッチに伝送し、前記選択スイッチが前記制御メッセージに応答して、該スイッチに記憶される前記要求データを前記要求クライアントに伝送するステップと、
前記要求が前記選択データの１部でない場合、前記要求データを前記ホスト・プロセッサから前記要求クライアントに伝送するステップと、
を含む方法。
（２）前記選択データが、前記要求クライアントからの前記要求メッセージの伝送以前に、事前処理されたパケットとして前記選択スイッチに記憶される、前記（１）記載の方法。
（３）前記の各事前処理パケットが、前記選択データからのペイロードと、ネットワーク・プロトコル・スタックのヘッダ及びトレーラを含む、前記（２）記載の方法。
（４）複数のスイッチ及び通信ネットワークに接続される複数のクライアントを有する前記ネットワークに接続されるホスト・プロセッサを有するデータ通信システムにおいて、要求データを要求クライアントに伝送する装置であって、
複数の選択データを少なくとも１つの前記選択スイッチに記憶する手段と、
前記要求データを前記要求クライアントに送信するための要求メッセージを、前記要求クライアントから前記ホスト・プロセッサに伝送する手段と、
前記要求データが前記選択データの１部の場合、前記要求データを前記要求クライアントに送信する要求を示す制御メッセージを、前記ホスト・プロセッサから、前記要求データを記憶する前記選択スイッチに伝送し、前記選択スイッチが前記制御メッセージに応答して、該スイッチに記憶される前記要求データを前記要求クライアントに伝送する手段と、
前記要求が前記選択データの１部でない場合、前記要求データを前記ホスト・プロセッサから前記要求クライアントに伝送する手段と、
を含む装置。
（５）複数のスイッチを有する通信システムと、
データ通信ネットワークに接続されるホスト・プロセッサと、
前記データ通信ネットワークに接続される複数のクライアントと、
各々が事前処理されたビデオ・パケットを記憶する手段と、要求される前記事前処理ビデオ・パケットを検索し、前記要求クライアントにディスパッチする手段と、前記事前処理パケット内のネットワーク・プロトコル・スタックのヘッダ及びトレーラから紛失した情報を提供する手段と、を有する複数のスイッチと、
を含む前記データ通信ネットワーク。
（６）複数のスイッチを有する通信ネットワークと、
前記通信ネットワークに接続されるホスト・プロセッサと、
前記通信ネットワークに接続される複数のクライアントと、
複数のスイッチであって、各前記スイッチが、
事前処理されたビデオ・パケットを記憶する半導体記憶装置と、
制御メッセージに応答して、制御モジュールにより要求されるビデオ・データ内の各前記事前処理ビデオ・パケットの前記記憶装置内でのアドレスをディスパッチするビデオ・ディスパッチャと、
各々が各前記要求クライアントに対応するエントリを含むストリーム制御テーブルを有する複数の出力アダプタであって、前記の各エントリが、前記事前処理パケット内のネットワーク・プロトコル・スタックのヘッダ及びトレーラから紛失した情報を含むものにおいて、前記の各出力アダプタが、
前記ビデオ・ディスパッチャにより要求される前記事前処理パケットを、前記半導体記憶装置から受信する手段と、
前記ストリーム制御テーブルから受信される情報を前記事前処理パケットと併合する手段と、
前記ビデオ・ディスパッチャにより要求される前記事前処理パケットを前記要求クライアントに送信する手段と、
を含む、前記出力アダプタと、
を含むデータ通信システム。
（７）複数の検索モードをサポートするためのビデオ／音声データの記憶方法であって、前記ビデオ／音声データをメッセージ・シーケンスとして記憶するステップを含み、前記の各メッセージがビデオ・データの１部と、各々が前記検索モードの１つに関連付けられる複数のリンクを有し、前記の各リンクが、選択オペレーション・モードに関連付けられる前記リンクが、前記選択検索モードに対して要求される前記ビデオ・メッセージにリンクされるように、別の前記ビデオ／音声メッセージを指し示す、前記記憶方法。
【００６５】
【発明の効果】
以上説明したように、本発明によれば、クライアントはビデオ及びマルチメディア・データを受信するように希望するとき、要求をホスト・プロセッサに送信し、次にホストが制御メッセージを要求データを記憶するスイッチに送信する。これらのスイッチが次に要求データを要求クライアントに送信する。但し、要求データがスイッチに記憶されていない場合には、データはサーバから要求クライアントに直接転送されなければならない。このように、ビデオ内容をネットワークのスイッチにオフロードすることにより、ビデオ内容を要求クライアントに効率的に配布し、サーバから要求クライアントへのビデオ内容の配布に関連するオーバヘッドを低減することができる。
【図面の簡単な説明】
【図１】ＵＮＩＸオペレーティング・システムのファイル内のデータ構成を示す図である。
【図２】本発明が実施される環境、及びホスト内に保持されているオフロード・データを差すポインタにより、ネットワークのスイッチにデータをオフロードする様子を示す図である。
【図３】ビデオ内容から導出される事前処理パケットを示す図である。
【図４】事前処理パケットを記憶するように変更される共用バッファ・スイッチを示す図である。
【図５】事前処理パケットを記憶するために変更された共用バッファ・スイッチを示す図である。
【図６】変更された共用バッファ・スイッチのビデオ・ディスパッチャ・ユニットの詳細を示す図である。
【図７】ホスト・プロセッサからスイッチに送信される制御メッセージのフォーマットを示す図である。
【図８】クライアントからホストへの要求メッセージ、ホストからスイッチへの制御メッセージ、及び制御メッセージに応答してスイッチからクライアントへ伝送されるビデオ・パケットを含む、クライアント、スイッチ、及びホスト・プロセッサ間のメッセージ・フローを示す図である。
【図９】本発明で使用される好適なビデオ・メモリを示す図である。
【図１０】本発明の変更出力アダプタを示す図である。
【図１１】共用バッファを有さない異なるスイッチを使用する本発明の別の実施例を示す図である。
【図１２】共用バッファを有さない異なるスイッチを使用する本発明の別の実施例を示す図である。
【図１３】半導体記憶装置をスイッチに統合する本発明の別の方法を示す図である。
【図１４】半導体記憶装置の代わりに磁気ディスク記憶装置を使用する本発明の更に別の方法を示す図である。
【図１５】ビデオ・ストリーム内のフレーム・シーケンスを示す図である。
【図１６】図１４のフレームの順方向再生時の復号化順序を示す図である。
【図１７】図１４のフレームの逆方向再生時の復号化順序を示す図である。
【図１８】図１４のフレームの早送り及び早戻し機能を説明する図である。
【符号の説明】
６  要求メッセージ
８  制御メッセージ
１０  ホスト
２０  クライアント
５０  ＡＴＭ広帯域ネットワーク
６０  スイッチ
６１  入力リンク
１００  シリアル・リンク
１５０  スイッチ出力
１５０  出力リンク
２００、２００''  入力アダプタ
２１０、２６０  マイクロプロセッサ
２８６、４２０、７２０、８２０  マルチプレクサ
２８７  制御信号
２８８  出力リンク・インタフェース論理
２８８、８７０、８７１  インタフェース論理
３００  入力バス
３１０  出力アドレス・バス
３１５、５８１  信号線
３１５、７６１  制御ビット
３５０  出力バス
４００  共用メモリ
４１０  遅延素子
５００  制御セクション
５００、５００'  中央制御装置
５１０  フリー・セル・リスト
５１０、５２０  ＦＩＦＯキュー
５２０  アドレス・キュー
５３０  書込みアドレス・バス
５４０  読出しアドレス・バス
５８１  要求受諾信号
５８５  書込み許可信号
６００  制御ポイント
６００'  汎用コンピュータ
７００  ビデオ・メモリ
７１０  ダイナミック・ランダム・アクセス・メモリ・モジュール
７１７  信号
７３０  制御論理
７５０  ＤＲＡＭ制御装置
７６０  ロード・アドレス・バス
７９０  ディスク
７９５  半導体バッファ
８００  ビデオ・ディスパッチャ
８１０  タグ・メモリ
８１５  スケジューラ
８２５  ディスパッチ・キュー
８２６  出力アダプタ・アドレス・フィールド
８２７  ストリームＩＤフィールド
８２８  ビデオ・メモリ・アドレス・フィールド
８５０  セル・アドレス・モニタ
８５５  増分器
９００  ビデオ内容
９１５  ペイロード
９２０  ビデオ・メッセージ
９２５  ポインタ
９２６  ネットワーク・スイッチ・アドレス
９２６  スイッチ・アドレス要素
９２７  メッセージ・アドレス
９３０  ＡＴＭセル
９３１  コンバージェンス・サブレイヤ・トレーラ
９３５  ヘッダ
９４０  リンク・フィールド
９４１  順方向リンク
９４２  逆方向リンク
９４３、９４４、９４５、９４６  リンク
９５０  フロー制御フィールド
１０００  スイッチ・ハードウェア
１１５０  制御回路
１２５０  出力キュー
１６００  ビデオ・メモリ・マネージャ
【参考文献】
［１］Craig Partridge, "Gigabit Networking", Addison Wesley Publishing Co., Reading, Mass.01867, ISBN 0-201-56333-9, Oct.1993.
［２］M. J. Bach, "The design of the Unix operating system", Prentice Hall Inc., Englewoods Cliffs, NJ, 07632, ISBN 0-13-201799-7 025, 1986.
［３］H. M. Vin and P. V. Rangan, "Designing a multiuser HDTV storage server", IEEE Jour. on Selected Areas in Communications, 11(1), Jan. 1993,pp. 153-164.
［４］D. Kandlur, M. S. Chen, and Z. Y. Shae, "Design of multimedia storage server", In IS&T/SPIE symposium on Electronic Imaging Science and Technology, (San Jose, CA 1994).
［５］A. Dan and D. Sitaram, "Buffer management policy for an on-demand video server", IBM Research Report RC 19347.
［６］A. Dan and D. Sitaram, "Scheduling policy for an on-demand video server with batching", IBM Research Report RC 19381.
［７］R. Haskin, "The Shark continuous media file server", Proc. IEEE COMPCON 1993 (San Francisco CA, 1993).
［８］W. Rosenberry et.al., "Understanding DCE", O'Reilley and Associates Inc., 103 Morris Street, Suite A, Sebastopol, CA 95472, ISBN 1-56592-005-8, Sept.1992.
【図１】
0003730686.tif 000002
【図２】
0003730686.tif 000003
【図３】
0003730686.tif 000004
【図４】
0003730686.tif 000005
【図５】
0003730686.tif 000006
【図６】
0003730686.tif 000007
【図７】
0003730686.tif 000008
【図８】
0003730686.tif 000009
【図９】
0003730686.tif 000010
【図１０】
0003730686.tif 000011
【図１１】
0003730686.tif 000012
【図１２】
0003730686.tif 000013
【図１３】
0003730686.tif 000014
【図１４】
0003730686.tif 000015
【図１５】
0003730686.tif 000016
【図１６】
0003730686.tif 000017
【図１７】
0003730686.tif 000018
【図１８】
0003730686.tif 000019