JP2003518817A

JP2003518817A - パケットスケジューリングを用いるネットワーク交換方法

Info

Publication number: JP2003518817A
Application number: JP2001547777A
Authority: JP
Inventors: ロジャース，スチーブン，エー．
Original assignee: シテイシャンネットワークスインコーポレイテッド
Priority date: 1999-12-23
Filing date: 2000-12-22
Publication date: 2003-06-10
Anticipated expiration: 2020-12-22
Also published as: WO2001047162A8; US20010036181A1; DE60018799D1; DE60018799T2; US7274691B2; EP1240740A1; EP1240740A4; EP1240740B1; ATE291303T1; JP4616535B2; WO2001047162A1

Abstract

(57)【要約】保証された遅延及び帯域幅トラフィックへスケジュールを割付けることによってデータパケットフローを交換する方法。ネットワークスイッチ（５、６、８及び９）にはスケジューリングサーバー（７）によりスケジュールが付与される。スケジューリングサーバー（７）はスケジュール情報をコンピューター処理してスイッチ（５、６、８及び９）と送信元と宛先端末（４及び１３）へ送信する。スイッチ（５、６、８及び９）はスケジュール情報に基づいてパケットのリアルタイム送信及び受信を管理する。

Description

【発明の詳細な説明】

【０００１】発明の背景技術本発明は全般的には音声電話方式等の殆どのリアルタイムアプリケーションに
必要とされるような帯域幅及び遅延限界範囲内でのデータパケットの送出を保証
するコンピューターネットワークを介したデータパケットの送信及び交換に関す
る。音声通信は、データ遅延及びデータ紛失に敏感なリアルタイム通信アプリケ
ーションの１例であり、本発明を有利に適用できる通信方式である。現状のイン
ターネットパケットは一般的には高質音声通信に要求される限界内でのデータ送
出を保証することはできない。かかる課題に取り組むため、本発明は帯域幅及び
遅延限界内でデータパケットが高い信頼度をもって送出されることを可能とする
交換技術を提供するものである。

【０００２】周知の通り、パケット交換は局所パケットアドレスに基づいてエーテルネット
及びインターネットプロトコル（ＩＰ）データパケットのトランスポートに使用
される。ここで用いる用語「局所パケットアドレス」とは、パケット自体のフォ
ーマットの一部であるパケットアドレスのことを言う。パケットスイッチは、ポ
ートがそのポートの次の宛先へ接続されている場合のみ到着パケットを転送する
マルチポート装置である。パケット交換は、例えばネットワークブリッジを採用
する場合に起こり得る、その特定のポートへ接続されているホストあるいは端末
へ向けられていないパケットの受信からネットワークのポートあるいはセグメン
トにかかる過重を軽減するものである。パケット交換においては、パケットは一
般的にはスイッチのすべてのポートへは送信されないが、実施中の通信において
関与しているホストへと導くパケットのみに送信される。一般的に各セグメント
の有効帯域幅は他のセグメントのパケットトラフィックによって減じられないの
で、パケット交換にはパケットネットワーク時間当たりの全処理量を増加できる
利点がある。そのため、パケット交換はパケット輻輳を減じ性能を増大させる。

【０００３】しかしながら、パケット交換はバケット衝突及び可変性パケット遅延の問題を
取り除くものではない。このような問題はポートが十分に利用されていない場合
にも起こり得る。例えば、多数のアプリケーションが瞬間的に単一ポート資源で
競合する場合に問題が起こる可能性がある。特に、競合するアプリケーションが
互いに妨害しあって１または２以上のパケットの送信あるいは受信における可変
性遅延を起こす。

【０００４】既存のシステムにおいて、上記問題に対処するため異なるタイプのパケットへ
優先度を割り付ける試みが行われてきた。既存の技術においては、リアルタイム
要求のあるパケットには比較的高い優先度が割り付けられているので、かかるパ
ケットはリアルタイム送出が必要とされない優先度の低いパケットよりも先に処
理される。しかし残念なことに、パケットすべてが同等な優先度にある場合は、
優先付けたパケット処理によって作業性が向上するわけではない。かかる想定が
実際に起こるアプリケーションの例として音声電話方式を挙げることができる。
通常、多数の同時電話呼び出しが単一ポート接続へと送られる。かかる電話呼出
用のデータを保有しているパケットには高い優先度が与えられるべきことは特に
知られていない。多数の優先音声パケットが単一の回線で混線すると、非決定論
的なパケット輻輳や遅延が起って電話呼出が破綻してしまう。

【０００５】例えば、パケットを介するリアルタイムデータの転送専用に使用されるデータ
回線を複数ポート上に複数アプリケーションをもつパケットスイッチへ接続する
ことが可能である。リアルタイムデータ回線はこのスイッチを使用するすべての
アプリケーションによって共有できる。例えば、前記リアルタイムデータ回線は
前記スイッチを別の場所にある別のスイッチあるいは電話サービス会社へ接続す
るのに使用される。この回線へ秒当りのビット数でＢｒの生データ容量をもたせ
てもよい。各リアルタイムアプリケーションにはＢａの帯域幅が要求され、ここ
でＢａは秒当りビット数で表すとアプリケーションの持続的帯域幅に等しい。従
って、理論的には回線を介して送信できるリアルタイムアプリケーションの最大
数Ｎは下記式で表わされる。 N = Int[Br/Ba]

【０００６】完全に利用されている回線中のすべてのアプリケーションには一定のデータパ
ケットを送信する等しい機会が与えられている。この例では、すべてのアプリケ
ーションは同一であって、同一サイズ、同一速度でパケットを送信すると想定す
る。さらに、この例でのすべてのアプリケーションは互いに独立して整合するこ
となく送信を行うと想定する。また、すべてのアプリケーションは固定された間
隔で各アプリケーションの必要性に応じてパケットを送信すると想定する。最後
に、すべてのパケットは送信側にとって同等の重要性を持ち、同等の優先度をも
つと想定する。任意の時において、あるアプリケーションが共有されている回線
へパケットを送信すると、そのパケットが遅延なく回線中へ入る確率Ｐｄは下記
式で表わされる。Ｐ_{（ｄ＝０）}＝１／Ｎ

【０００７】十分に荷重された回線は出て行くパケットストリーム中に有効なウィンドーを
もつ回数Ｎにおいて１回しか機会をもたないため、どのアプリケーションについ
ても、いかなる時点でも、上記確率は維持される。パケットが回線へ送られると
他のアプリケーションの他のパケットとその回線資源について競合することにな
る。特に他のパケットが先に到着していて、既に送信機会の待ち行列中で待機し
ている場合がある。送出データストリームにおける順位の競合は、パケットは待
ち行列順に１つ１つ送信されるので遅延が起こる。予想される最大遅延時間は、
すべての他のアプリケーションからのパケットの受取後にすぐ新たなパケットが
受信された場合は、Ｎパケット数の送信時間に相当することになる筈である。実
際の遅延は起こり得る最小と最大遅延時間の範囲内で予測不可に変動する。

【０００８】パケットが受ける遅延を予測するためには、そのパケットの転送中に要する「
転送時間」を考慮することも必要である。このため、「転送時間」は、あるパケ
ットをその回線へ送信するために要する時間を参照するために用いられるべきで
ある。従って、転送時間（Ｔ）は下記式のように、秒当たりのビット数（Ｒ）の
データ速度で分けられたビット（Ｌ）のパケット長に等しくなる。Ｔ＝Ｌ／Ｒ従って最大遅延（Ｄ_ｍａｘ）は下記式で表され、Ｄ_ｍａｘ＝ＮＴ及び、平均遅延（Ｄ_ａｖｇ）は下記式で表される。Ｄ_ａｖｇ＝ＮＴ／２

【０００９】リアルタイムアプリケーションに関して、従来のパケット交換システムによっ
てもたらされる可変性遅延はシステム設計において考慮しなければならない点で
ある。すなわち、遭遇する実際のパケット遅延は平均遅延がＤ_ａｖｇであってゼ
ロからＤ_ｍａｘまで変動し得る。遅延の変動は「ジッタ」として知られるが、こ
れもシステム設計において考慮されねばならない要素である。ジッタ補正はバッ
ファリングによって行われる。従って、アプリケーションは、ジッタによるパケ
ット損失を防止するため、Ｄ_ｍａｘまでのパケットからパケットにおけるジッタ
の取扱い能力とともに受信したデータパケットをバッファー処理できなければな
らない。従って受信ジッタバッファーはパケットを規則的な間隔でアプリケーシ
ョンへと運ぶことができる。もしそのアプリケーションが入ってきたデータをバ
ッファー処理しなければ、オーバーランあるいはアンダーラン状態が起こり得る
。アンダーラン状態の場合、パケット到着の瞬時の遅延が受取側アプリケーショ
ンによるパケット処理や実行を遅くなり過ぎさせてしまう。すなわち、受け取っ
たアプリケーションは次のサンプルが出力されねばならない時に処理を行うめの
有効データをもっていない状態が起こり得る。電話機を端末とする音声通信アプ
リケーションにおいては、音声信号が持続してユーザーの耳元へ送られ続けられ
ねばならない。もしパケット遅延のためにデータが受信されなければ出力されて
いる音声が中断してしまう。この理由から、音声通信アプリケーションをベース
とする電話にはジッタバッファーを備えなければならない。これら受信用ジッタ
バッファーは、ジッタバッファー内に保存されているパケットが時間を要するた
めに、全般的システムにおける遅延を増加させる。もし各パケットが重要であれ
ば、ジッタを最大限大きくした分に見合う大きさにジッタバッファーを構成しな
ければならない。従って、ジッタバッファーによってもたらされる時間の遅延は
システムの最大パケット間ジッタと同じかあるいはそれより大きくなる可能性が
ある。

【００１０】パケットジッタは一般的通信ネットワークをパケットが移動するときに蓄積す
る。パケットが通常の場合と同様にその宛先へ到達する前に多スイッチ回線トラ
ンジションを行う場合は全体的遅延が増大する。一定のスイッチ及び通信回線で
の遅延は通常は次のスイッチで起こる遅延とは相関関係に無い。事実、平均及び
最大遅延はルートに沿ったスイッチの数とともに増加する。従って、Ｍ個のスイ
ッチが「ホップ」する場合の進路の遅延指標は下記式で表される。式中、Ｄ_ｍａｘ（ｉ）は宛先へのパスに沿った各スイッチにおける最大遅延であ
る。パケットが進路において交換遅延に遭遇しない確率には限界があるので最小
交換遅延は猶ゼロである。従って最大遅延は最大遅延Ｄ_{ｍａｘ（Ｍ）}に等しい。

【００１１】既存のパケット交換ネットワークはパケット挿入遅延ともに固定遅延をもたら
す。かかる固定遅延は種々の原因から起こる。第１に、パケットはパケットが送
信される物理的距離に依存する伝搬遅延を受ける。自由空間中の光速度はかかる
遅延の根底にある別の基本的制限である。光は、光ファイバー等の物理的通信媒
体を通って自由空間を通過するよりもかなりゆっくりと伝搬する。生ずる遅延は
長距離、リアルタイム通信の場合、特にパケットがその宛先へと回り道をとる場
合に重大である。

【００１２】パケット長に関連する挿入遅延及びパケットを一定の回線上へ送信するのに要
する時間もまた既存の通信ネットワークへ導入される。例えば、モデムでのリア
ルタイムパケット通信における主要な困難性は比較的狭い帯域幅の通信回線にお
ける挿入遅延がかなり大きくなることである。距離とモデム挿入双方により起こ
る遅延は交換遅延を考慮に入れなくともネットワーク上の高質音声通信を実行不
可能にするのに十分である。

【００１３】上記遅延に加えて、既存のパケット交換装置においてはそれ自体による遅延が
起こる。殆どのスイッチ及びルータは受け取ったパケットを入力待ち行列へ入れ
る。前述したスイッチ交換装置は受け取ったパケットそれぞれの次の宛先を検出
して、適当なポートの出力待ち行列へ受け取った各パケットを送り込む。パケッ
トはその後待ち行列の先頭に来た時に送信される。パケットが高優先度をもつ場
合でも、また他の優先度の高いパケットによる待ち行列遅延がなくとも、スイッ
チ内での待ち行列間のパケットの移動中にスイッチ操作によりパケットへかなり
の遅延が加えられる。

【００１４】他のネットワークパケットトラフィックもまた遅延を引き起こす。多くの既存
のネットワークにおいては、多数の形態のパケットトラフィックが相互に入り混
ざっている。その結果、多種のパケットアプリケーションがネットワークを介し
て有効な帯域幅で競合している。パケットトラフィックに優先順位をつけても、
高優先度パケットが遅延なく送信されることの保証にはならない。事実、その逆
が起こる場合もある。例えば、優先度の低いパケットが受け取られ、高優先度の
パケットが受け取られる直前に送出され、高優先度のパケットが受け取られる直
前に低優先度パケットの送信が始まった場合を考える。低優先度パケットがまず
送信され、高優先度パケットは低優先度パケットの送信が済むまで待たなければ
ならない。高優先度パケットを先にするため低優先度パケットを送信途中に中断
する方法は一般的にはない。従って、高優先度パケットはホップ毎に低優先度パ
ケットの最大幅を送信するために要する時間だけ潜在的に遅延する可能性をもっ
ている。さらに厄介な問題として、低優先度トラフィックは効率の問題からしば
しば最大長のパケットに集められて遅延可能性を増大させる。他方、高優先度パ
ケットはネットワークを横切る挿入遅延特性を減じるため非常に短い場合が多い
。適例として、エーテルネット通信プロトコルにおいてパケットの最大と最小と
の比が２０：１以上であってもよい。つまり、優先順位が決められたスイッチに
おいても、低優先度パケットの送信によって起こる各ホップでの高優先度パケッ
トが受けるパケット遅延は２０以上の小さな高優先度パケットを送信するのに要
する時間と等しくなる可能性がある。現在いくつかのネットワークでは「ジャン
ボ」パケットが送信されているが、この場合の遅延はさらに長くなる。

【００１５】リアルタイムアプリケーションにおいては、パケットは許容される遅延特性に
よって大きさがまちまちである。その結果、一定の速度で情報を転送するために
、より多くの小さいパケットあるいはより少ない大きなパケットを使用できる。
より少ない大きなパケットが用いられる場合、交換資源及び送受信システムへの
荷重が減じられる。これは交換資源にはパケットの処理速度に関して性能に限界
があるからである。また、ホストの送信及び受信は各パケットを処理するためソ
フトウェアで中断される筈であり、それらホストの秒当たりのパケット処理数に
おける性能には限界がある。他方、同量のデータを送信するためにより少ない大
きなパケットを使用することは、各パケットへより多くのデータが集められるこ
とを意味する。その結果、上記式中のＮで表されるパケット転送時間の長さが増
すことによりもたらされる遅延はさらに長くなる。

【００１６】１００バイト容量の高優先度音声パケットが「ジャンボ」パケットにより遅延
される場合について考える。いくつかのジャンボパケットは現今の最大長インタ
ーネットプロトコルパケットよりも６倍長いものである。短いパケットは極めて
高速なネットワーク接続を備えるネットワークサーバーへ過度の応力を与えるた
め多くのユーザーがジャンボパケットの使用を強く支持している。しかしながら
、ジャンボパケットは最新のスイッチ技術を採用したリアルタイムアプリケーシ
ョンへ混乱を引き起こすものである。ジャンボパケットは１００バイトを含み、
単一の高優先度音声パケットを９０の他の音声パケットまで遅延させる可能性を
もつものである。

【００１７】低優先度待ち行列遅延は多数のスイッチの移動中に蓄積する。送信機から受信
機へとネットワークを移動する時に３０以上のスイッチを通り抜けることが通常
である。従って、１件のみ呼出しが行われ完全に作動している優先度に基づくネ
ットワークにおいては、２７００の他の高優先度音声パケットに相当する低優先
度パケット待ち行列遅延が起こり得る。

【００１８】遅延と遅延変動だけが先行技術におけるパケットスイッチに関して起こる問題
なのではない。リアルタイムアプリケーションはしばしば帯域幅保証を伴って提
供される。もしネットワーク回線が有り得るすべてのセッションに対して帯域幅
保証の全量を同時に支持するに十分でないならば、ネットワークは「過剰登録」
となる。既存のシステムにおいては、いずれかの回線脚あるいはスイッチにおい
て「過剰登録」となることはネットワーク帯域幅に関して全くあり得ることであ
る。かかる過剰登録はパケットトラフィックが優先扱いされているかどうかによ
って起こる。優先方式が採用される場合、高優先度トラフィック自体が回線の過
剰登録をしない限り高優先度トラフィック（おそらくは音声トラフィック）は妨
害のない回線を通過することができる。この場合、高優先度トラフィックは低優
先度トラフィックに対してその実行により不利な影響を与える。既存のシステム
においては、かかる状況で帯域幅を割り付ける確かな方法はない。従って、過剰
登録は低優先度トラフィックの完全な破綻を引き起こし、また場合によっては高
優先度トラフィックの破綻さえも引き起こす。

【００１９】パケット輻輳の程度は単一のリアルタイムセッションの途中においてもその時
その時で極端に変動する。例えば、トラフィック状態が比較的よい時にパケット
ネットワーク上で電話呼出しを設定する。しかし、呼出し中、急激に輻輳状態が
進み呼出しが格下げされたりあるいは中断さえされたりする。このような事態は
殆どの重要任務リアルタイムアプリケーション、特に音声電話方式にとっては通
常許容できないものである。かかる場合、有効な帯域幅と同じかそれより小さい
だけでは平均的なトラフィックにとっては不十分である。通常輻輳が瞬時でも共
通回線の容量を超えると競合を避けるためパケットは失われる。そのため、全シ
ステムの帯域幅はいかなる瞬時においてもすべてのアプリケーションにより要求
される最大帯域幅と同等以上でなければならない。

【００２０】以上述べたように、すべてのトラフィックへ特性が与えられ、過剰登録もなく
、優先方式が採用されている理想的な場合であっても、パケットネットワークに
は遅延と遅延変動の欠点がある。さらに、既存のパケットスイッチは例え優先方
式を取り入れていても容易に過剰登録状態に陥ってしまう。かかる理由から、パ
ケットネットワーク上のリアルタイムアプリケーションを効果的に支持するため
、遅延を制御しかつ最小化できるパケットスイッチが必要とされる。さらに、リ
アルタイムセッション中の帯域幅の使用を保証して、セッション終了後に他のア
プリケーションへ帯域幅を開放するシステムとできれば有利である。パケットを
介する音声電話方式等のリアルタイムアプリケーションの場合、システムとして
、既存の回路交換電話ネットワークから得られたものに近似する全音声遅延処理
機能をもつ呼出し装置を備えるべきである。最終的には、呼出し側は呼出しを開
始する際その呼出しの実行が終了まで保証されることを知っているべきである。

【００２１】発明の要約本発明の目的に従い、複数のリアルタイムアプリケーションのそれぞれへ帯域
幅を割り付けてパケット遅延を制御でき保証されたパケット送出を可能とするパ
ケットスイッチについて開示する。開示にかかるスイッチは帯域幅競合により起
こる送信上の問題を多少でも解消する動的帯域幅割付けを行うものである。この
開示されたシステムは各リアルタイム通信セッション中に使用する帯域幅を割り
付けるものである。開示された動的帯域幅割付けシステムの作動は、影響を受け
るポート上の有効帯域幅が減じられることを除いては他のパケットトラフィック
のパケット交換性能を低下させるものではない。

【００２２】本開示は従来のパケットスイッチ構成へ追加することができるスケジューリン
グシステムを含むものである。この開示されたスケジューリングシステムはスイ
ッチの各ポート内の送受信機能へ別個に適用されるものである。開示されたスケ
ジューリングシステムを介して、スイッチは保証帯域幅と制御遅延に関する特定
のアプリケーションの必要性に従って作動することができる。本発明の目的にお
いて、用語「パケットフロー」は特定のアプリケーションに関連付けられたパケ
ットを指している。さらにパケットフローにはあるアプリケーションに関わる送
信ホストと受信ホスト間のパケットの一方向のフローを指す意味もある。

【００２３】各スイッチ内では、開示されたスケジューリングシステムがスケジュール発生
の基本になっている。スケジュールは１または２以上のパケットのパケット送受
信が行われる予想時間である。スケジュールはネットワーク中の各スイッチごと
に独立して発生する。一定のスケジュールはスイッチ内のすべてのポートの送受
信へ、あるいはスイッチ内の１または２以上のポートの送受信機能の部分集合へ
適用される。従って、一定のスイッチは単一のスケジュールあるいは複数のスケ
ジュールに基づいて作動する。スケジュールは持続的に繰り返される。あるいは
、各スケジュールは、以下でも説明するが、トリガー事象に対応して明示的に誘
発される。

【００２４】スケジュール間隔内で、パケットフローオフセットはパケットフローに関わる
パケットあるいはパケット群の始まりを限定する。パケットフローオフセットが
スイッチポート送信機能と関連付けられている場合、そのパケットフローオフセ
ットは関連するパケットフローに関して１または２以上のパケット送信が開始で
きるスケジュール間隔内で時間を限定する。パケットフローオフセットがスイッ
チポートの受信機能と関連付けられている場合、そのパケットフローオフセット
はその関連するパケットフローに関する１または２以上のパケット受信が予想で
きるスケジュール間隔内の時間の一点を限定する。

【００２５】一定のパケットフローについて、ホスト送信機とホスト受信機間にあるパスに
沿った各スイッチへ異なるパケットフローオフセットが確立される。前記パスに
沿ったすべてのスイッチのためのパケットフローに関連付けられたオフセット値
を設定することによってそのパケットフロー（パケットフロースケジュールとも
いう）のスケジュールを限定する。パケットフロースケジュールにはスケジュー
ル間隔期間及びパケット長を含めることも可能である。一定のパケットフロース
ケジュールに関わるスケジュール間隔内の時間はパケットフロースケジュール期
間と称される。

【００２６】個々のパケットフロースケジュールはパケットフローに関わるアプリケーショ
ンの必要性とネットワーク中の算定された最良の通過パスに基づいて決定される
。パケットフロースケジュールは問題となる通信回線の帯域幅限界までいかなる
アプリケーションにも与えられる。あるアプリケーションに関連付けられたパケ
ットフロースケジュールはそのアプリケーションが送信パス中へ１または２以上
のパケットを配置できる時間を保証する。パケットフロースケジュールは、その
回線に関してすべての送信時間が割り付けられるまで、いずれのアプリケーショ
ンへも、またいかなる順番によっても割付けられる。割付けのないいずれの送信
機会も従来のパケットトラフィックの転送に利用でき、既存のシステムにおける
と同様に交換転送が可能である。

【００２７】パケットフローが確立された場合、関連するパケットフロースケジュールは、
そのパケットフロー用の送信ホストと受信ホスト間のパスに沿ったスイッチ間に
おいて整合される。このパケットフロースケジュールに基づき、一定のスイッチ
はそのパケットフロースケジュールに基づいてそのパケットフロー用の保証帯域
幅パケットを受信ホストへ通ずるパスに沿ってある次のスイッチへと送信できる
。また、このパケットフロースケジュールに基づいて、次のスイッチがパケット
フロースケジュールによって示された時間に保証帯域幅パケットの到着を予想す
る。このような方法で、パス内のスイッチを通過するパケットフロースケジュー
ルの形成に基づいて、いずれかの送信機と受信機間に専用の帯域幅が与えられる
。その結果、ホスト送信機がパケットを送信する場合、そのパケットはパケット
フロースケジュールに従って遅延無く自動的にホスト受信機へと送信される。い
ずれか１のスイッチに対して、いずれか１のパケットフロースケジュールがその
スイッチを介して連結するため一方向へ作用している。各スイッチポートはそれ
自体専用のスケジュール間隔を有し、その１は送信機能用であり、また１は受信
機能用である。リアルタイムセッションの確立中は、送信パケットに関わるパケ
ットフローオフセットと受信パケットに関わるパケットフローオフセットはパス
に沿った各スイッチを介して一致している。一定のパケットフローに関わり、そ
のパケットフロー用のパスに沿った一組のスイッチを通過するパケットフローオ
フセットの一組は本明細書中ではそのパケットフロー用の「パケット軌道」と呼
ばれる場合もある。開示に係るスケジューリングシステムを用いて送信された保
証帯域幅パケットは「スケジューリングされた」パケットと呼ばれる。送信パス
及びスイッチ自体間の交換システムに関連する遅延がフロースケジュールの計算
に含まれている。

【００２８】開示に係るシステムは、ホスト送信機がホスト受信機へ通ずるパスに沿ったす
べてのスイッチとの送信を整合できることを必要としている。スケジューリング
されたパケットを運ぶ各スイッチは、関連するパケットフロー用のホスト受信機
へ通ずるパスに沿った次のスイッチとスケジュール整合されていなければならな
い。

【００２９】前記パス中の最後のスイッチとの交渉または整合はホスト受信機については要
求されない。前記パス中の最後のスイッチは、そのホスト受信機に関連付けられ
たパケットフロースケジュールに従ってホスト受信機パケットを送出するだけで
ある。ホスト受信機はそのパケットすべてを前記パス中の最後のスイッチから受
信するので、その同じスイッチがその受信機へのすべてのパケットの引渡しを制
御する。そのため、ホスト受信機は通常はスケジュール情報を整合することを必
要としない。ホスト受信機は常に正しい時間に保証帯域幅パケットを受信する。
前記受信機はリアルタイムパケットに含まれた情報の取り扱いをスケジュール化
することを必要とするいずれかのアプリケーションタイミング情報をパケット自
体から通常引き出すことができる。パケット引渡し回数を保証することにより大
きなパケットジッタバッファーを維持する必要性とジッタ、あるいはパケット衝
突及び再送問題対処する必要性ガスケット大幅に減じられる。受信機は常に連続
している次のスイッチを時間通りに受信するので広範囲なジッタバッファリング
は必要としない。

【００３０】スイッチ間のリアルタイムパケットフローはスイッチ間のスケジュール同士を
整合することによって完成される。このスイッチ間整合はスイッチ間のスケジュ
ールを計算して引き渡す特別なアプリケーションを使用することによって完了さ
れる。このアプリケーションにはスケジュールフロー、スイッチ及びスイッチ間
リンクにおける遅延、リンク速度、及びネットワーク位相に関する知識が備わっ
ていなければならない。このスケジュールアプリケーションが要求を受信すると
、そのパケットフロー用のスイッチのネットワークを介して最も速いスケジュー
ルを計算する。

【００３１】発明の詳細な説明本願が３５ＵＳＣ§１１９（ｅ）の規定に基づき優先権主張を行っている出願
日１９９９年１２月２３日、仮出願番号６０／１７１，９７６号、発明の名称「
パケットスケジューリングを用いたネットワークスイッチ」の出願における開示
をここで参照しながら本発明について以下に説明する。

【００３２】図１の高レベルブロック図に示すように、また本発明の実施態様例において首
尾一致して開示される構成として、本発明に係るパケットスイッチは、スイッチ
２、第一ホスト端末１及び第二ホスト端末３の３つの構成要素から構成される。
ホスト端末１及び３のそれぞれはパケットの送信及び／または受信を行う。

【００３３】受け渡し及び／または遅延に関して保証を要しないパケットは以下に述べるよ
うにスイッチ２を通過する。最初に、ホスト端末１は通信リンク２０によってス
イッチへパケットを送信する。ホスト端末１がエーテルネットインタフェースを
介してスイッチ２へ相互接続されている場合、通信リンク２０はＵＴＰ（非密封
撚り対）から作られた４対のケーブルで構成できる。しかしながら、スイッチ２
はインタフェースを用いて多種の通信回線あるいはリンク、例えばこれらに限定
されないが１０メガビット／秒、１００メガビット／秒、ギガビット、１０ギガ
ビットエーテルネットネットワークへと具現化できる。スイッチ２は従来「ＯＣ
」、「ＤＳ」、「Ｔ」、「Ｅ」、及びＳＯＮＥＴ（同期光ネットワーク）および
ＳＤＨ（同期デジタル階層）通信標準に関連付けられた他のファイバーベースま
たはワイアレスベースのリンクまたは回線と呼ばれもの、インターネットあるい
はエーテルネットパケットに適するものへインタフェースを採用してもよい。従
って、開示に係るシステムはいずれか特定の通信リンクへインタフェースを必要
とするものではない。説明のためここでは標準的エーテルネットインタフェース
を用いる実施態様を挙げるが、開示されたシステムに従って作製されたスイッチ
は他の種類のインタフェースを含むものであってもよい。

【００３４】スイッチ２をホスト端末１とスイッチ２間の通信リンクへ接続するインタフェ
ースは、従来エーテルネットネットワークを接続するために用いられていた一般
に「ＲＪ−４５」と呼ばれるコネクタ等の標準のコネクタ２２を用いて具現化で
きる。コネクタ２２での受信後、パケットは受信制御論理回路（ＲＣＬ）２４へ
と運ばれる。ＲＣＬ２４はパケットの宛先アドレスを抽出してパケットの内容を
受信パケット待ち行列２６へと配列するように作動する。ＲＣＬ２４はパケット
宛先アドレスを含む待ち行列をスイッチ制御ＣＰＵ（ＳＣＣ）４３へ同時に送出
する。ＳＣＣ４３はエーテルネットＭＡＣ（メディアアクセス制御装置）アドレ
スとＩＰ（インターネットプロトコル）アドレス双方から成るパケットアドレス
を取り上げ、そのパケットアドレスを用いてどのポートへそのパケットが送信さ
れるべきかを示すポート番号を決定する。ＳＣＣ４３はこれらの操作を２方法の
うちの１つ、すなわち（１）内部の検索表を調べるか、あるいはパケットアドレ
スをパケット分類装置（ＰＣ）２８へ送出するかによって実施する。パケット分
類装置２８は特にスイッチ２上のポートへＩＰあるいはエーテルネットＭＡＣア
ドレスを写像するように作動する。パケット分類装置２８は、例えば内容をアド
レスで呼び出せるメモリ（ＣＡＭ）システムを採用してパケットアドレスの与え
られたポート番号を迅速に回答する。

【００３５】ＳＣＣ４３が一旦正しいポート番号を確認すると、ＳＣＣ４３は内部メモリ表
を調べて交差点マトリックス３２上の宛先ポート送信制御論理回路（ＴＣＬ）、
例えば送信制御論理回路（ＴＣＬ）３２がスケジューリングされた送信に使われ
ていないかどうかを明らかにする。宛先ポートＴＣＬは他のソースからのパケッ
トの受信で回線が塞がっている場合がある。もし宛先ポートＴＣＬが使用中の場
合、ＳＣＣ４３は待ち行列中の要求を保存して次回の要求まで待機する。もし交
差点マトリックス３２上の宛先ポートＴＣＬが使用中でなければ、ＳＣＣ４３は
交差点マトリックス３２へ、ＲＣＬ２４の内部スイッチ出力へ接続された交差点
マトリックスポートと、ＴＣＬ３０への内部スイッチ入力への交差点マトリック
スの接続との間に接続を設定する指令を出す。この接続が完了すると直ぐにＳＣ
Ｃ４３はＲＣＬ２４へメッセージを送出する。このメッセージはＲＣＬ２４へ指
示を与えてパケットを交差点マトリックス３２へそのまま送出させる。次にＲＣ
Ｌ２４はそのパケットを交差点マトリックス３２へ送信する。同時に、ＴＣＬ３
０はそのパケットを受信する。その時点で送信パケット待ち行列（ＴＰＱ）３４
からの送信中のパケットがなければ、ＴＣＬ３０は入ってくるパケットのホスト
端末３への送信を開始する。

【００３６】図１の実施態様において、受信制御論理回路２４、受信パケット待ち行列２６
、送信制御論理回路２７及び送信パケット待ち行列２９はスイッチ２の第１ポー
ト内に含まれていると考えられる。同様に、送信制御論理回路３０、送信パケッ
ト待ち行列３４、受信制御論理回路３７及び受信パケット待ち行列３９はスイッ
チ２の第２ポート内に含まれていると考えられる。従って、パケットがスイッチ
２の第１ポートで受信され送信用のスイッチ２の第２ポートへ送出される場合、
第１ポートは入りポートあるいはソースポートと呼ばれ、第２ポートは出ポート
あるいは宛先ポートと呼ばれる。ＲＣＬ２４が一旦交差点マトリックス３２への
パケットの送信を完了すると、ＲＣＬ２４はＳＣＣ４３へその完了を知らせる。
ＳＣＣ４３は内部メモリ表中の適当なエントリーを出ポートの送信側に関して「
消去」状態に設定し、出ポートの送信機能が他のポートからのパケット受信に対
して有効であることを表示する。その後ＳＣＣ４３は２つのポート間の既存の接
続を遮断することも可能である。

【００３７】この処理において、すべてのパケットはスイッチ２に入り、識別されて正しい
宛先ポートへと一定進路を経て送出される。当業者は、ＳＣＣ４３、ＰＣ２８、
交差点ロードメモリ（ＣＰＬＭ）４２及び交差点マトリックス３２の一部あるい
は全部を組み込んでいる「スイッチファブリック」と呼ばれる従来の構成部品が
入手可能であることを認識している。このような従来型スイッチファブリックは
本開示に係るスケジューリングパケットスイッチの実施態様においても使用する
ことができる。

【００３８】リアルタイムパケットと呼ばれる受渡し及び遅延限界保証に関わるパケット送
信について説明する。かかるパケットは、例えばリアルタイムアプリケーション
に関連付けられたものであってもよい。リアルタイムパケットとリアルタイムア
プリケーションとの関連性は例えばパケットフローを介することにある。リアル
タイムアプリケーションに関連付けられたパケットフローはパケットフロー内の
すべてのパケットに共通な何らかの組のパケットヘッダーフィールド値によって
識別できる。リアルタイムパケットはスイッチ２により取り扱われてもよい。例
えば、ホスト１によってスイッチ２へ送出されたリアルタイムパケットの処理に
は、ホスト１がその保証済みの送信をスイッチ２と整合させることが要求される
。ホスト１はさらに所定の割り付けられたスケジュールに従ってそのリアルタイ
ムパケットを送出する。かかる操作の実行のため、ホスト１はそのパケット送信
機とスイッチ２中の関連受信機との間に共通の時間基準を持つことが求められる
。このことは開示に係るシステムにおいては以下の処理を経た上で可能となる。
まず、スイッチ２はエーテルネットパケットをホスト１内の受信機５０へ送出す
る。このパケットはスイッチ２によって基準情報を含むものとして識別される。
ホスト１内の受信機５０は次に「ハートビート」パケットと呼ばれる基準パケッ
トを用いてスケジュール間隔の開始点を決定する。スイッチ２は、ホスト１内の
受信機５０が適切にそのスケジュール間隔の始まりを決定できるように十分な規
則性をもってハートビートパケットを送出すべく作動する。例えば受信機５０は
複数のハートビートパケットの受信により集められたタイミング情報を平均化し
て基準ロックを与えることができる。この方法により、ホスト送信機５２をスイ
ッチ２から基準ソースへと効果的に位相ロックすることができる。開示に係るス
ケジューリングされたサービスを支えるために用いられるスイッチ２のすべての
ポートはハートビートパケットを送信することが可能である。各ハートビートパ
ケットはスイッチのスケジュール間隔に対する位相を決定するために用いるられ
るパケットデータフィールド内に情報を有しているので、ハートビートパケット
は規則的な間隔で送信される必要はない。本明細書では、ハートビートパケット
が規則的な間隔で与えられているものとして説明する。図１の実施態様に示すよ
うに、スイッチ２内のすべての受信送信制御論理回路への接続をもつマスターク
ロックシステム６５をスイッチ２内の受信送信制御論理回路へスケジュール間隔
を与えるために使用することが可能である。このマスタークロックシステム６５
は上記した受信ハートビートパケット等の外部クロック基準７１に対して対応可
能に示されている。

【００３９】ハートビートパケットは管理的特性をもつ他の情報も伝達することができる。
しかしながら、ハートビートパケットの主要な機能は正しいタイミング基準を与
えることである。パケットを受信するいずれのホストも平均化アルゴリズムを用
いてその内部基準に合うように整合を行う。ハートビートパケットは、いずれの
ホストあるいはいずれのホストネットワークにも共通ソースからタイミング基準
を引き出すことを可能とする。この方法により、リアルタイムパケットの形態で
保証されたデータを送信する必要があるすべての局部ホストあるいはポートが正
確な参照局所フレームを持つようになる。すべてのポテンシャルホスト送信機は
このようにスイッチ基準について参照される。ここで「スケジュール領域」と呼
ばれるスイッチのいずれかの集合においてハートビートは単一スイッチから始ま
る。ネットワーク中の各スイッチは、ハートビートパケットが木の根としてハー
トビートソースをもった木配置に存在するスイッチのネットワークを介して分配
されるように、少なくとも１ポートからハートビートを受信して多数の「下流」
ポートからハートビートを送出するように構成されている。

【００４０】図２（ａ）、２（ｂ）、及び２（ｃ）はパケットデータ交換のための３つの技
術的アプローチを示すものである。これら３つの技術的アプローチにはここで開
示するように２つの従来技術と１つの新技術が含まれている。ここでは説明のた
めすべての交換が「切り離し」型であると想定する。すなわち、スイッチはパケ
ットの受信を始めるや否やパケットを送出し始めることができる。パケットは再
送信が始まる前に完全に受信される必要はない。切り離し型スイッチは伝送時間
が蓄積される必要がないことを利点としている。すなわち、最後のパケットが入
力ポートで猶受信されている間にそのパケットは既にその宛先へ送信されている
。

【００４１】従来システムにおいては、パケットは先入れ先出し法（ＦＩＦＯ）により交換
されていた。これを図２（ａ）に示す。ＦＩＦＯは今日では殆どのパケット網で
用いられる。図２（ａ）は３つのパケット入力ストリームを備えるパケットスイ
ッチ１０１を示している。パケットスイッチ１０１においては、パケットは受信
された順に送信される。図２（ａ）に示すように、最初に受信されたパケット１
０５が最初に送信されるパケット１０３である。２番目に受信されたパケット１
００は同様に２番目に送信され以下同様である。リアルタイムパケットは陰を付
けて示したパケットであり、パケット１０４及び１０２を含んでいる。パケット
の受信順により、またスイッチ１０１のＦＩＦＯ特性により、リアルタイムパケ
ット１０４は最後の送信パケット１０２となっている。これは、すべての他のパ
ケットはパケット１０２が受信されると同時あるいはその前にスイッチ１０１に
よって受信されたからである。このような動作に伴って、標準のＦＩＦＯスイッ
チ網を通過するパケットは予測できない遅延を受ける。これら遅延は蓄積されし
ばしば長時間となる。

【００４２】このような遅延を緩和するために提案されている最も一般的な技術が図２（ｂ
）に示されている。この方法においては、各パケットには優先タグあるいはラベ
ルが付される。スイッチはパケットを受信するとその優先タグをチェックする。
高優先度の他のパケットが既に待ち行列にあると、スイッチは高優先度のパケッ
トを最初に送出する。さもなければ、スイッチは優先度が同等のもののうち最も
古いパケットを送出する。この方法により、パケットＦＩＦＯ待ち行列中で長時
間待つことが軽減される。

【００４３】優先度に基づくパケットの取り扱いによって遅延が除去できるわけではない。
図２（ｂ）に示した例では、長い低優先度のパケット１１６が最初に受信される
とそのパケットが送信を始める。それが受信を始めてまもなく、高優先度のパケ
ット１１０及び１１１が受信される。これらの高優先度パケットは、パケット送
信が一旦開始されると通常中断できないため低優先度パケットの送信がまず終了
するまで待たねばならない。また、高優先度パケット１１０、１１１及び１１５
相互間においても遅延が起こる。これらパケットは同等の優先度をもつためＦＩ
ＦＯに従い他のパケットの終了を待たねばならない。

【００４４】スケジュールに基づくパケット処理は図２（ｃ）に示すものである。スケジュ
ールに基づくパケット処理は本願で開示されるスケジューリングシステムによっ
て可能となる新たな形式である。スケジュールに基づくシステムにおいては、リ
アルタイムパケット１２５は同時にスイッチに到着しない。これらパケットは時
間を違えて到着するようにその端点でスケジューリングされている。他の例にお
けるように、長いパケット１２６等の他のパケットがすぐに到着する。しかしな
がら、スケジュールに基づくスイッチは新しいリアルタイムパケットの差し迫っ
た到着をスケジュールを介して事前に知っているため長いパケット１２６の送信
を行わない。それに代わり、スケジュール実行前にそれを行う余裕があることか
ら送信済パケット１２４と示された短い受信パケット１２０を送信する。最初の
リアルタイムパケットが到着すると、そのパケットは送信済パケット１２３と表
示され直ちに送出される。本願開示のスケジュールに基づくパケット処理では本
質的に待ち行列による遅延なしにパケットの送出が可能である。

【００４５】図３は一般的なスケジュール領域を示す。図３に示すスケジュール領域におい
ては、１のスイッチを「マスター」に指定する。とりわけ、このマスタースケジ
ューリングパケットスイッチ６はハートビートパケットから始めるように作動す
る。他のスケジューリングスイッチ５、８及び９はハートビートパケットを受信
する。スケジューリングスイッチ５、８及び９は、例えば平均化アルゴリズムを
用いて到着時間及びハートビートパケットの内容に基づいてそれら自体の参照値
を計算してハートビートパケットを分配する。スケジューリングスイッチ５の場
合、ハートビートパケットをインターネットパケット電話４として示されたホス
トへ送出する。スケジューリングスイッチ８の場合、ハートビートパケットをス
ケジューリングスイッチ９その他へ送出する。

【００４６】リアルタイム送信を行うホストのみが受信したハートビートパケットの使用を
必要としている。保証済パケット受信のみ必要とするホストはスイッチを参照す
る時間を維持することを必要としない。そのようなホストは受信したハートビー
トパケットをただ捨てるだけである。スイッチがポート上にスケジューリングさ
れた送信能力がないと判定したならば、そのポートからハートビートパケットを
送出しないことを選択することも可能である。

【００４７】図３の実施態様は、図中に示したスケジューリングされたスイッチのための一
般的リアルタイムアプリケーション作動環境を表すものである。図３に示された
リアルタイムアプリケーションはパケットに基づく音声電話方式である。図３に
おいては、スケジューリングされたスイッチ５、６、８及び９、電話方式ホスト
４及び１０、デスクトップコンピューターホスト１１、サーバー１２、及び電話
方式用リアルタイムスケジュールサーバー７が示されている。リアルタイムスケ
ジュールサーバー７は信号方式７（ＳＳ７）リンク１６と接続されて示されてい
る。従って、図３は一般的ネットワークと一般的リアルタイムアプリケーション
の代表例である。

【００４８】図３のリアルタイム電話方式アプリケーションは数種の異なるセッションを支
えている。第１に、電話機４が他の電話機１０あるいはスイッチ５、６、８及び
９へ繋がれた他の複数の電話機とセッションを確立する。第２に、電話機４はス
ケジューリングされたスイッチ網上にない遠距離の電話機とセッションを確立し
ている。これはＴＤＭリンク１８へ接続された広域電話インタフェース１３との
セッションを確立することによって達成される。この広域電話インタフェース１
３は遠隔にある電話機との接続を確立するものである。第３に、電話機は別のス
イッチへ取り連れられているいずれか他の電話機と通信可能である。これはスイ
ッチ間ＬＡＮ中継を利用することによって達成できる。第４に、電話機はサーバ
ー１２とセッションを確立できる。このセッション確立は音声メッセージの回復
あるいは音声応答システムへのアクセスに有用である。さらに、電話機はインタ
ーネット等のパケット交換データサービスへ接続される遠隔電話機とのセッショ
ンを確立できる。このセッションは広域インターネットあるいはデータインタフ
ェースと確立されたセッションを介して達成される。最後に、デスクトップコン
ピューター１１は、もし音声等のリアルタイムアプリケーションを支える適当な
構成要素が与えられれば、リアルタイムセッションを確立し受け入れることが可
能である。

【００４９】図３に表されたもの等のホストはリアルタイムスケジューリングサーバー７と
通信することによってリアルタイムセッションを確立する。スケジューリングサ
ーバー７はすべてのリアルタイムホストの相互運用制御に要求されるすべてのス
ケジューリング機能を提供する。これらホストはスイッチ５、６、８及び９とは
直接には通信を行わない。スイッチ５、６、８及び９とのリアルタイムセッショ
ンの確立を統合するのはスケジューリングサーバー７の役割である。

【００５０】セッションは以下の手法で確立され終了する。ホストはスケジューリングサー
バー７へメッセージを送出することによって要求を行う。このメッセージは従来
のＬＡＮ−ＷＡＮ−ＩＰ非スケジューリング接続を用いて送出される。スケジュ
ーリングサーバー７は、そこへ新たなパケットフローが確立されるあるいはすで
に確立している要求元ホストとパケット宛先間のパスをコンピューター処理する
。スケジューリングサーバー７は次にスケジュール情報を電話機４及び１３とス
イッチ５、６、８及び９へ送信する。スケジュール情報メッセージパケットはス
イッチ５、６、８及び9によって受信され各スイッチの適当な出力ポートへと送
出される。スイッチ管理ＣＰＵ６４（図１）は各スイッチによって扱われるリア
ルタイム送信及び受信を管理するためスケジュール情報パケット内容の処理を行
う。

【００５１】図４は信号ソフトスイッチコンピューターアプリケーション１４を含むスケジ
ューリングされたスイッチ網を示している。図４中の装置は図３に示したものと
同様であるが、信号ソフトスイッチコンピューターアプリケーション１４が追加
されている。このソフトスイッチコンピューターアプリケーション１４はインタ
ーネット上で電話呼び出しを中継する呼出し信号を与える従来のソフトウェア要
素である。図４に示したネットワークの実行中にセッションは以下の手法で確立
され終了する。ホストは信号ソフトスイッチコンピューターアプリケーション１
４へメッセージを送出することにより要求を行う。信号ソフトスイッチコンピュ
ーターアプリケーション１４はスケジューリングサーバー７を介してスケジュー
リングされたパケットフローを要求する。図４に示した装置のその他の操作は図
３で説明したものと同様である。

【００５２】図５はハートビートパケット１８０により始まり第２のハートビートパケット
１８１により継続されるスケジュール間隔１８２を示している。一般的なリアル
タイムアプリケーションに対しては、ハートビートパケット１８０及び１８１等
のハートビート信号はスケジュール間隔１８２自体と同頻度で送出可能である。
しかしながら、有効ハートビートパケット到着時間は平均化されるのでハートビ
ート信号はすべての間隔ごとに送出される必要はない。かかる平均化によりスケ
ジュール間隔タイミングは任意の高い正確性へと導かれる。

【００５３】ハートビートパケットの実例形態１８９を図５に示す。図５の実例によるハー
トビートパケット形態１８９においては、標準エーテルネットあるいはインター
ネットプロトコル（ＩＰ）をもつエーテルネットフレームが使用されている。エ
ーテルネットヘッダー１８３はＩＰヘッダー１８４の前に示されている。「最終
ハートビートからの時間」フィールドを含んでもよいペイロード１８５がさらに
示されており、さらに参照バイト１８６が続いている。ＩＰ端部フィールド１８
７及びエーテルネット端部フィールド１８８も図５に示されている。参照バイト
１８６は図５に示したハートビートパケットからタイミングを取得するため受信
機によって使用される。従って、スケジューリングされたスイッチ中の受信制御
論理回路がハートビートパケットを取得する時、同回路は参照バイト１８６を検
索する。スケジューリングされたスイッチが参照バイト１８６を取得する場合、
同スイッチはＳＣＣ４３によって行われる平均化計算を介してそのマスタークロ
ック６５（図１）をリセットする。あるいは、スケジューリングされたスイッチ
のためのタイミング情報は終了、あるいは開始、あるいは図５に示したハートビ
ートパケット等の受信ハートビートパケット内のいずれかの他の時点に合わせ、
次いでその時間を平均化することによって取得できる。かかる二者択一的アプロ
ーチにおいて、時間参照の正確性には正確なロックを得るためにより多くのハー
トビートパケットが取得される。

【００５４】図６は図１に示したスイッチ２内におけるスケジューリングサーバーとＳＭＣ
６４間の通常メッセージ交換を示している。双方向セッションのため、スケジュ
ーリングサーバー７は第1ＳｅｓＲｅｑメッセージ２００をＳＭＣ６４へ送出す
る。ＳｅｓＲｅｑメッセージ２００はセッションスケジュール割付が求められて
いることをＳＭＣ６４へ通知する。ＳｅｓＲｅｑメッセージ２００には、入手可
能な場合、求められたセッションに関するソース及び宛先ポート番号、ソース及
び宛先ＭＡＣアドレス、及びソース及び宛先ＩＰアドレス等の情報を含まれてい
る。ＳｅｓＲｅｑメッセージ２００にはさらに、リアルタイムセッションのため
求められたパケット番号及びパケットサイズ等のスケジュール構成が含まれてい
る。

【００５５】ＳＭＣ６４はさらにＳｅｓＲｅｑＡｃｋメッセージ２０２をもってＳｅｓＲｅ
ｑメッセージへ応答するように作用する。ＳｅｓＲｅｑＡｃｋメッセージ２０２
はそのセッション要求が受け入れられたかどうかを表示する。セッション要求が
受け入れられればセッションは確立される。両方向性セッションについては、Ｓ
ｅｓＲｅｑメッセージがパケットフローの各方向へ１度ずつ２度送出される。さ
もなければ、スケジュールサーバーは両方向に関して単一の要求を受け入れるこ
とができる。その結果、図６に示すように、第２ＳｅｓＲｅｑメッセージ２０４
は第２のＳｅｓＲｅｑＡｃｋメッセージ２０６によって承認される。両方のセッ
ションパケットフローが受け入れられたことが表示された時に呼出し２０８が行
われる。

【００５６】セッションはまたスケジュールサーバーから送られた２つのメッセージによっ
て中断される。まず、スケジューリングサーバー７は第１のＳｅｓＲｅ１メッセ
ージ２１０をＳＭＣ６４へ送出する。このＳｅｓＲｅ１メッセージ２１０は指定
されたパケットフローのためのスケジュール内で割り付けられた時間がもはや必
要のないことをスイッチへ表示する。ＳＭＣ６４は次にＳｅｓＲｅ１Ａｃｋメッ
セージ２１２を用いて応答する。ＳｅｓＲｅ１Ａｃｋメッセージ２１２は指定さ
れたセッションに関連するスケジュール資源は現在放出されていることをスケジ
ューリングサーバー７へ表示する。図６はまた、通常の電話通話等の両方向リア
ルタイムアプリケーションへの適用が考えられる２つのセッション放出についも
示している。従って、第２のＳｅｓＲｅ１メッセージ２１４とそれに続く第２の
ＳｅｓＲｅ１Ａｃｋメッセージ２１６が示されている。

【００５７】次に図１に示すリアルタイムパケット転送のためのスイッチ２の内部操作につ
いて説明する。前記したように、図１のスイッチ２は交差点マトリックス３２を
用いてリアルタイムと非リアルタイムパケットフロー双方を接続することができ
る。しかしながら、前記交差点マトリックスはリアルタイム用と非リアルタイム
用では用い方が異なる。スイッチ２内部において、ＳＣＣ４３は交差点ロードメ
モリ４２を維持している。交差点ロードメモリ４２は交差点マトリックス３２を
完全な状態で含んでいる。この完全な状態の交差点マトリックス３２はスケジュ
ール間隔中の各パケットフロースケジュールの状態を反映している。

【００５８】図７は図１に示した交差点マトリックス３２に対応する交差点マトリックスの
例を示すものである。図７の交差点マトリックスは多様な交差点入力２８０を多
様な交差点出力２８２へ接続するための多数のスイッチ２８４を含んだ構成で示
されている。

【００５９】図７に示すように、交差点マトリックスは交差点スイッチの設定を制御するた
めに用いられる２列のラッチ、新ラッチ６６及び現ラッチ６７を含む。現ラッチ
６７は交差点マトリックスを直接制御する状態にある。現ラッチ６７は交差点マ
トリックスのどの入力が交差点マトリックスのどの出力と実際に接続されるかを
決定する。現ラッチ６７は２通りの方法で荷重することができる。第１は、ＳＣ
Ｃ４３はいつでも直接いずれかのラッチへアクセスしてその値を変えることがで
きる。第２は、新ラッチ６６の内容からすべての現ラッチ６７に同時に荷重する
ことができる。新ラッチ６６からのデータは荷重制御ピン６８の表明に基づいて
同時に現ラッチ６７へ転送される。この過重制御ピンはＳＣＣ４３へ接続される
。ＳＣＣ４３はいつでも荷重制御ピンを表明できる。ＳＣＣ４３はいずれの新ラ
ッチへもアクセスし荷重することができる。

【００６０】非リアルタイムパケットに対しては、ＳＣＣ４３はパケットごとに接続要求を
処理し、適当な交差点マトリックスへ現ラッチを書き込むことによって接続を確
立する。一方において、リアルタイム接続セッションは新ラッチ６６を荷重する
ことによって確立される。新たなスケジュール各々の始まりにおいて、荷重制御
ピン６８の表明によって新ラッチ６６は現ラッチへ過重される。スケジュールの
過程において、次のパケットフロースケジュール期間のためにスイッチを設定す
るＣＰ構成は新ラッチ６６へと荷重される。新ラッチの内容は荷重制御ピン６８
が表明されるまでは交差点マトリックスの作用には影響しない。これにより、ス
イッチ構成は新たなスケジュールが始まる時点において即時に設定可能である。

【００６１】現ラッチ６７と新ラッチ６６の双方は交差点マトリックスを横切るポテンシャ
ル接続の各々について1バイトを保有している。実施態様の１例においては、ス
イッチ２は１２８個のスイッチを支持することができる。交差点マトリックス上
の単一のポートは多数の外部ポートに対して使用できる。図７に示す交差点マト
リックスの例は１２８の入力と１２８の出力を含む。各入力はいずれかの出力へ
と接続される。各出力には１２８個のＳＰＳＴ（単極単スロー）スイッチがある
。１２８個のスイッチの各々が異なる入力へ取り付けられている。１の出力には
１の入力のみ接続できる。１以上の入力を接続すれば交差点マトリックスでの競
合を起こし損傷を引き起こすからである。他方１の入力を１またはすべての出力
へ接続することは可能である。各出力に必要なメモリは１２８バイトである。通
常１２７バイトの「ゼロ」と選択された入力線を示す１バイトの「１」として保
存される。もし入力が全く選択されなければ１２８バイトの「ゼロ」となる。１
２８バイトに必要とされるメモリスペースは１６バイトである。

【００６２】ＳＣＣ４３がポートＲＣＬから接続要求を受信した場合、ＳＣＣはいくつかの
機能を実施しなければならない。第１に、ＳＣＣ４３は接続が要求されているポ
ートが塞がっているかどうかを確認する。この確認のため、ＳＣＣ４３は各スケ
ジュールについてリアルタイム接続メモリをチェックする。非リアルタイム接続
メモリについてもチェックしなければならない。メモリが実行中の接続がないこ
とを示すと、ＳＣＣ４３は非リアルタイムメモリを設定し適当なＣＰレジスター
に対して変更を行う。ＳＣＣ４３は次いで要求元のＲＣＬに対してそのパケット
を送出するよう信号を送る。ＳＣＣ４３がＲＣＬからパケット転送終了のメッセ
ージを受信すると、ＳＣＣは非リアルタイムメモリを消去して適当な交差点マト
リックスレジスターを介する接続をリセットする。もしＳＣＣ４３がポートＲＣ
Ｌからのパケット接続要求を受信し、接続要求がのあるポートが塞がっていると
確認したならば、その接続要求は実行中の接続が終了するまで接続待ち行列中へ
送られる。

【００６３】高速プロセッサの実施態様図１のスイッチ２へ与えられた機能性は主としてードウェア構成要素によって
与えられたものであるが、かかる機能性は１または２以上の高速プロセッサ上で
使用するソフトウェアあるいはファームウェアを用いて二者択一的に付与するこ
とも可能である。かかる実施態様においては、開示に係るスケジューリングパケ
ットスイッチは図８に示した構成を用いて実行される。かかる実施態様において
は、開示に係るスイッチは、エーテルネット及び／またはインターネットプロト
コルパケット上での運用に適した「ネットワークプロセッサ」あるいは「通信プ
ロセッサ」と呼ばれる多数の高速プロセッサ３０２、３０３を用いて構築される
。これらネットワークプロセッサ３０２、３０３はスイッチを介するパケットフ
ロー管理に用いられる。

【００６４】このアプリケーションに適する一般的ネットワークプロセッサの内部構成を図
９に示す。図９では、ネットワークプロセッサ４００は多様な構成部分を伴う集
積回路として示されている。パケットは一般的には高速インタフェース４１０を
介してネットワークへ出入りする。これらのインタフェースはエーテルネットあ
るいはＳＯＮＥＴまたはプログラム可能なＲＩＳＣ（命令セット簡単化）インタ
フェース機関４０３、４０４、４０５、４０６等を用いたＴ−キャリアーインタ
フェースとして構成することができる。ＲＩＳＣ機関の作用構成は制御ＣＰＵ４
３２によって設定される。制御ＣＰＵ４３２はネットワークプロセッサ４００の
作動開始時にＲＩＳＣ機関中へいくつかのマイクロコードを装荷する。

【００６５】ＲＩＳＣ機関４０３、４０４、４０５、４０６等は高速インタフェース上で入
ってくるデータをフォーマットして枠組データからパケットデータを抽出する。
このデータはＲＩＳＣパケットプロセッサ４２０、４２１、４２２、４２３等へ
送出される。同様に送信では、パケットデータはＲＩＳＣパケットプロセッサか
ら離脱してインタフェースＲＩＳＣ機関４０３、４０４、４０５、４０６等によ
ってフォーマットされる。

【００６６】パケットプロセッサ４２０、４２１、４２２、４２３等はパケット宛先の決定
を行うために使用される。これらプロセッサはパケットを待ち行列に並ばせ、送
信のためパケットを他のパケットプロセッサへ送出できる。待ち行列機関４３０
は待ち行列の管理を行う。パケットプロセッサ４２０、４２１、４２２、４２３
等の各々は送信用と受信用に複数の待ち行列を備えている。パケットプロセッサ
はその待ち行列のどちらへパケットを入れるかを決定し、パケットの保存を行う
待ち行列機関４３０へパケットを送出する。待ち行列機関４３０は次に高速ＲＡ
Ｍインタフェース４４０を介して外部高速ＲＡＭを用いてパケットを保存する。

【００６７】もし、パケットプロセッサ４２０、４２１、４２２、４２３等がパケットを他
のパケットプロセッサへ送信すべきと決定した場合は、パケットプロセッサはそ
のパケットをファブリックインタフェース制御器４３１へそのパケットを転送す
る。本インタフェースはそのパケットを宛先ネットワークプロセッサと宛先ネッ
トワークプロセッサのポートのアドレスとともに転送する。スイッチファブリッ
ク３０８は次いでそのパケットを次のネットワークプロセッサのファブリックイ
ンタフェース制御器４３１へ移動させる。一般的なスイッチは多数のネットワー
クプロセッサ４２０、４２１、４２２、４２３等上に多数のポート４１０を有す
る。

【００６８】制御ＣＰＵ４３２はネットワークプロセッサ４００の構成部分の作用を制御す
る。これら構成部分にはインタフェースＲＩＳＣ機関、ＲＩＳＣパケットプロセ
ッサ４２０、４２１、４２２、４２３等、待ち行列機関４３０、及びファブリッ
クインタフェース４３１が含まれる。制御ＣＰＵはバス４４３を介して外部ＣＰ
Ｕ３１４、３１５等と通信を行う。制御ＣＰＵはまた内部ＲＡＭ４３３及びＲＯ
Ｍ４３４を使用してその作動を実施している。

【００６９】図８に示したスイッチ３００においては、複数のネットワークプロセッサ３０
３、３０４をスイッチ構造３０８、３０９と共に使用してスイッチ３００の内外
へパケットを移動している。パケットはこのスイッチを物理層装置３０２中へ差
し込む。これらの装置は信号レベル、インピーダンス及びメディア（光、電気、
平衡、非平衡）をネットワークプロセッサ３０３、３０４等へインタフェース連
結可能な信号へと変換する。ホスト３０１はパケットデータをスイッチ３００へ
送出し及びスイッチ３００から受信する。このパケットデータはスケジューリン
グされていてもスケジューリングされていなくとも構わない。

【００７０】スイッチ操作は配線ＣＰＵ３０７、３１０を介して制御される。これら配線Ｃ
ＰＵ３０７、３１０はスイッチ網の位相を知るために他のパケットスイッチと通
信を行い、配線情報をネットワークプロセッサ３０３、３０４等へ与えてそれら
プロセッサが入ってくるパケットを適当な出力ポートへ送出できるようにする。

【００７１】このスイッチは主スイッチ構造３０８、配線ＣＰＵ３０７及びクロックシステ
ム３０６が破損しても機能する付加的能力を備えている。冗長スイッチ構造３０
９、配線ＣＰＵ３１０及びクロックシステム３１１に対する準備ができている。
ネットワークプロセッサ３０３、３０４等は主システムが故障しているかどうか
を主システムからの応答を調べることによって確認できる。故障が検出できると
、ネットワークプロセッサ３０３、３０４等は冗長システムを使用すべく切り替
えを行える。好ましい実施態様において、主プロセッサ及び冗長プロセッサは別
々の取り出し可能なカード上にある。故障が検出されれば、スイッチ３００の操
作ロスを生ずることなくその故障したカードを取り替えられる。

【００７２】パケットフロースケジュールは配線ＣＰＵ３０７、３１０へのメッセージを介
してスイッチへと運ばれる。主及び冗長ＣＰＵ３０７、３１０の双方がスケジュ
ール及び配線情報を受信する。冗長ＣＰＵ３１０と連動していない場合に限り、
主配線ＣＰＵ３０７のみがその情報に対応して動作する。スケジュール情報は次
いで適当なネットワークプロセッサへと転送される。もしスケジュールが除去あ
るいは取り消されると、スケジュール情報は同様な手法で消去される。

【００７３】スイッチへ入ったスケジューリングされていない（通常の）パケットはネット
ワークプロセッサ３０３、３０４等によって処理され、必要であれば待ち行列中
へ送られる。パケットは次に最終宛先へ送信するためのネットワークプロセッサ
３０３、３０４等の後部のスイッチ構造３０８へと転送される。待ち行列は到着
順、優先度順、あるいは多プロトコルラベル交換（ＭＰＬＳ）等のタグによって
構成することができる。スケジューリングされていないパケットトラフィックは
パケットのストリームとスイッチ中の多様な待ち行列システム間の相互作用によ
って起こる正規遅延変動を受ける。

【００７４】スケジュールパケットは異なる手法で転送（交換）される。ネットワークプロ
セッサ３０３、３０４等は配線ＣＰＵ３０７によってスケジュールを与えられる
。ネットワークプロセッサ３０３、３０４等は新しいパケットを受信する度にそ
のスケジュールをチェックする。もしネットワークプロセッサ３０３、３０４等
がスケジュールは有効と決定すると、該プロセッサはそのパケットを、そのスイ
ッチ構造、宛先ネットワークプロセッサ３０３、３０４及び宛先ポートに関する
情報とともにそのスイッチ構造へとそのまま送出する。同様に、ネットワークプ
ロセッサ３０３、３０４等の送信側において、プロセッサはそのスケジュールを
頻繁にチェックしている。もし特定のスケジュールが有効になると、ネットワー
クプロセッサは待ち行列中のパケットを送信せずにファブリックインタフェース
３１９を介して現在受信しているパケットをそのまま送出する。

【００７５】この方法により、スケジューリングされたパケットは迅速かつ予測可能な手法
でスイッチを介して送出される。この操作に関するフローチャートを図１０及び
１１に示す。受信側の処理については図１０に、また送信側処理については図１
１に示している。

【００７６】図１０に示すように、ネットワークプロセッサは待ち受けパケット状態５００
でパケットを待っている。パケットが受信されると（５０１）、プロセッサはス
ケジュール情報に対して受信されたパケットがスケジュールの制御を受けるかど
うかを確認すべく問う。もし回答が「イエス」であれば、パケットはそのままス
イッチ構造５０６へと送られる。この転送が完了すると、プロセッサは他のパケ
ット５０２をチェックする。もしパケットが存在しなければ、プロセッサは待ち
受けパケット状態５００へ復帰する。もしパケットが存在すると、プロセッサは
再びステップ５０３において関連スケジュール情報をチェックする。もしスケジ
ュールが実施されていなければ、プロセッサはステップ５０４で次のパケットを
送出するのに十分な時間があるかどうかを決定すべくチェックを行う。もし回答
が「ノー」であれば、プロセッサは再度関連スケジュール情報をステップ５０３
においてチェックする。もし回答が「イエス」であれば、プロセッサはスケジュ
ーリングされていないパケットを通常ステップ５０５において送出する。そして
待ち受け状態へ戻る。この処理により、受信処理はすべてのスケジューリングさ
れたパケットが迅速な処理を受けることを保証する。また、この処理はスケジュ
ーリングされていないパケットの処理がやがてやって来るスケジューリングされ
たパケットの妨害とならないことを保証する。ついには、切迫したスケジューリ
ングされたパケットの直前でのスケジューリングされていないパケットの送信終
了までの待機をも可能としている。

【００７７】送信側処理は同様な方式で実行される。図１１は送信処理について説明してい
る。送信側ネットワークプロセッサはステップ５１１でスケジュールを継続的に
チェックしている。もしスケジュールが実施されているならば、送信処理はスケ
ジューリングされたパケットがファブリック５１４から到着して、それが到着す
るや否やステップ５１５で送信されるのを待つ。そしてプロセッサはステップ５
１１で再度スケジュールをチェックできる。もしスケジュールが実行されていな
ければ、ネットワークプロセッサはスケジューリングされていないパケットを送
出する。かかるパケットについてはステップ５１０で最初にチェックすべきであ
り、もし存在すればステップ５１３で送出する時間もチェックすべきである。も
し次のスケジュールに先立って完全に送るにはパケットが長すぎるならば、ネッ
トワークプロセッサは待ってそのパケットを送出しない。もしパケットが新たな
スケジューリングされたパケットに先立つ残りの時間に適合するならば、パケッ
トは通常ステップ５１２において送出される。

【００７８】本願発明が適用できるリアルタイムアプリケーションの単純な例は音声電話方
式である。本実施例において、従来の音声電話呼出し信号が２つの電話機器間へ
電話ネットワークを介して送信される。一般に知られるように、電話ネットワー
クは世界中において、１２，５００中１未満の不良音声サンプルのエラー率、１
００ミリ秒を超えない固定遅延条件において、秒当たり６４キロビット（秒当た
り８０００の８ビットサンプル）の保証ビット速度で搬送するように通常設計さ
れている。

【００７９】開示に係るスケジューリングされたネットワークを介してリアルタイム音声デ
ータを送信するため、デジタル化された音声サンプルは８キロヘルツの速度でパ
ケット中へ蓄積される。例えば、通常の蓄積期間は２０ミリ秒である。もしサン
プルが２０ミリ秒以上の期間蓄積されると各期間ごとに８０サンプルが蓄積され
る。これらの８０サンプルはインターネットパケット中へ配置されて送信される
。新たなパケットは２０ミリ秒毎に送信される。本開示に係るシステムはスケジ
ュールを送信元電話、第１スイッチ、パス上受信側電話機までのすべての後続ス
イッチと整合するものである。最後に、パス中の最後のスイッチがパケットを受
信側電話機へと送出する。

【００８０】電話呼出しのためのパケットフロースケジュールは、例えば２０ミリ秒の全ス
ケジュール間隔期間、スケジュール間隔内でパケットの始まりを限定するパケッ
トフローオフセット記述（これは０から２０までの間の十分な解像度数であろう
）及びパケット長（この場合、パケット及びＩＰオーバーヘッド用に可能とする
ため８０バイト以上であろう）に基づいて限定してもよい。

【００８１】このパケットフロースケジュールはコンピューター処理されて受信側電話機へ
のパスに沿った各スイッチへと搬送される。パケットフローオフセットは各スイ
ッチごとに異なる。スケジュール間隔期間は概してそのままである。パケット長
もそのままである。パケットはスイッチからスイッチへとネットワークを通過す
るのに時間を要するため、パケット間隔中のパケットの位置は、スイッチ相互間
で変動する。スイッチからスイッチにおいて遅延が起こる。スイッチ間の送信も
遅延を引き起こすこれらの遅延はパケットフロースケジュールの計算において考
慮に入れなければならない。

【００８２】スケジューリングされた電話呼出しが始まると、スケジュールサーバーアプリ
ケーションは必要なパケットフロースケジュールのコンピューター処理を行う。
スケジュールアプリケーションは次にスケジュール情報を送信側電話機とそのパ
ケットフロー用のパスに沿ったすべてのスイッチへ伝える。呼出しが完了すると
、スケジュールサーバーは前記パスに沿ったスイッチすべてにそのスケジュール
の破棄を通知する。

【００８３】本発明の重要な特長はパケット遅延を多数のスイッチにわたって蓄積する必要
がないことである。多数のスイッチがそれらのスケジュールを整合化しているた
め、同じ電話呼び出しパケットを多数のスイッチを介して遠距離にわたって送信
することが可能とされている。この場合加わる遅延は物理的距離とパケット送出
処理に関するもののみである。この特徴は既存の「最善の努力を払った」あるい
はスケジューリングされていないパケット交換システムと明確な対比をなすもの
である。スケジューリングされていないパケットがネットワークを通って流れる
と、それらパケットは容易に瞬時的輻輳や待ち行列によるオーバーフローを受け
、予測しえない遅延あるいは損失を被ることになる。

【００８４】本発明の機能を限定するプログラムは以下に述べる種々の形態でコンピュータ
ーへ分配できることは当業者には容易に認識できるところである。但しこのプロ
グラムは以下に限定されるものではない。（ａ）書き込み不可の記録媒体上に永久保存された情報（例えば、コンピュータ
ーＩ／Ｏアタッチメントで読み出せるＲＯＭあるいはＣＤ−ＲＯＭ等のコンピュ
ーター内の読み出し専用メモリ装置；（ｂ）書き込み可記録媒体上に変更可能に
記録された情報（例えばフロッピー（登録商標）ディスク及びハードディスク）
；あるいは（ｃ）例えば、モデムを介したコンピューターあるいは電話ネットワ
ーク上の搬送波信号方式を含めたベースバンド信号方式あるいはブロードバンド
信号方式用の通信媒体を介してコンピューターへ搬送された情報。さらに、本発
明はコンピューターソフトウェアとしても具現化できるが、本発明を実行するた
めに必要な機能を、アプリケーション専用集積回路あるいは他のハードウェア等
のハードウェアコンポーネントを用いてその一部あるいは全体を変形して具現化
してもよい。

【００８５】本発明については上述した実施態様を通して説明したが、ここで取り上げた開
示に係る実施例の発明趣旨を逸脱しない範囲で変更及び変形をなしうることは当
業者には明らかである。さらに、多様な例示的データ構造と関連させて好ましい
実施態様について説明を起こっているが、本発明システムを特定のデータ構造を
用いて具現化できることは当業者は認識している。従って、本発明は添付のクレ
ームにおける限定を除いて限定的に理解されてはならない。

【図面の簡単な説明】

【図１】２つの受信機／送信機ホストとスイッチの主要構成要素及び主要
な信号パスが装着されたスケジューリングされたパケットスイッチの高レベルブ
ロック図である。

【図２】２（Ａ）、２（Ｂ）及び２（Ｃ）はパケットスケジュール方法の
例を示す図である。

【図３】スケジューリングされたスイッチのネットワーク例を示す図であ
る。

【図４】信号ソフトスイッチとともにネットワークスケジューリングされ
たスイッチ例を示す図である。

【図５】ハートビートパケット構造例とともにスケジュール間隔内におけ
るハートビート信号の発生を示す図である。

【図６】２方向性リアルタイムセッションの確立及び終了に関する一連の
プロトコルメッセージを示す図である。

【図７】交差点マトリックス例を示す図である。

【図８】ネットワークプロセッサに基づいてスケジューリングされたパケ
ットスイッチ例を示す図である。

【図９】ネットワークプロセッサの１実施態様例を示す図である。

【図１０】１実施態様例において受信側処理中に実施されるステップを示
す図である。

【図１１】１実施態様例において送信側処理中に実施されるステップを示
す図である。

Claims

【特許請求の範囲】

【請求項１】スイッチにおいて、一定のパケットフローに関わり及び前記
スイッチが前記パケットフローに関わるパケットを受信するパケット到着時間を
表示するパケット到着時間情報を受信するステップと、前記パケットフローに関わり及び前記スイッチが前記パケットフローに関わる
受信パケットをどのように送出すべきかを表示する送出情報を受信するステップ
と、前記パケット到着時間に前記パケットフローに関わるパケットを受信するステ
ップと、及び前記パケットフローに関わる前記送出情報に従った前記パケット到着時間に基
づいて前記パケットを送出するステップから構成されることを特徴とする保証さ
れた遅延と帯域幅をもつデータパケットフローの交換方法。
【請求項２】前記スイッチにおいて、前記パケットフローに関わり及び前
記スイッチが前記パケットフローに関わる前記パケットを送信できるパケット送
信時間を表示するパケット送信時間情報を受信するステップをさらに含み、及び前記パケット到着時間に基づく前記パケットの送出には前記パケット送信時間
における前記パケットの送信も含まれることを特徴とする請求項１項記載の方法
。
【請求項３】前記スイッチの第１ポートと前記パケット到着時間情報とを
関連付けるステップをさらに含み、及び前記パケットの受信が前記スイッチの前記第１ポートで行われることを特徴と
する請求項２項記載の方法。
【請求項４】前記スイッチの第２ポートと前記パケット送信時間とを関連
付けるステップをさらに含み、及び前記パケットの送信が前記スイッチの前記第２ポートで行われることを特徴と
する請求項３項記載の方法。
【請求項５】前記パケットはリアルタイムアプリケーションと関連付けら
れ、非リアルタイムアプリケーションに関わる他のパケットを受信するステップと
、及び前記非リアルタイムアプリケーションに関わる前記パケットの送信を実施する
ために前記リアルタイムパケットの送信を遅延させるステップをさらに含むこと
を特徴とする請求項４項記載の方法。
【請求項６】前記非リアルタイムアプリケーションに関わる前記パケット
の受信が前記リアルタイムアプリケーションに関わる前記パケットの受信前に起
こることを特徴とする請求項５項記載の方法。
【請求項７】参照時間に参照パケットを受信するステップと、前記参照時間に対応するスケジュール間隔開始時間を決定するステップと、及
び前記パケット到着時間情報と前記スケジュール間隔開始時間に基づいて前記パ
ケット到着時間を決定するステップをさらに含むことを特徴とする請求項１項記
載の方法。
【請求項８】前記パケット到着時間情報はパケットフローオフセット値を
含み、及び前記パケット到着時間の決定には前記スケジュール間隔開始時間への
前記パケットフローオフセット値の追加が含まれることを特徴とする請求項７項
記載の方法。
【請求項９】参照時間に参照パケットを受信するステップと、前記参照時間に対応するスケジュール間隔開始時間を決定するステップと、及
び前記パケット送信時間情報と前記スケジュール間隔開始時間に基づいて前記パ
ケット送信時間を決定するステップをさらに含むことを特徴とする請求項２項記
載の方法。
【請求項１０】前記パケット送信時間情報はパケットフローオフセット値
を含み、前記パケット送信時間の決定には前記スケジュール間隔開始時間へ前記
パケットフローオフセット値の追加が含まれることを特徴とする請求項９項記載
の方法。
【請求項１１】第２スイッチへ前記パケット送信時間情報を送信するステ
ップと、及び前記パケット送信時間情報の受取通知を受信するステップをさらに含み、前記
パケット送信時間情報の受取通知には承認と不承認の確認が含まれることを特徴
とする請求項２項記載の方法。
【請求項１２】スイッチにおいて、一定のパケットフローに関わり及び前
記スイッチが前記パケットフローに関わるパケットを受信するパケット到着時間
を表示するパケット到着時間情報を受信する制御論理回路と、前記パケットフローに関わり及び前記スイッチが前記パケットフローに関わる
受信パケットをどのように送出するかを表示する送出情報を受信する制御論理回
路と、前記パケット到着時間に前記パケットフローに関わる前記パケットを受信する
制御論理回路と、及び前記パケットフローに関わる前記送出情報に従った前記パケット到着時間に基
づいて前記パケットを送出する制御論理回路から構成される保証された遅延及び
帯域幅をもつデータパケットフロー交換装置。
【請求項１３】前記パケットフローに関わり及び前記スイッチが前記パケ
ットフローに関わる前記パケットを送信するパケット送信時間を表示するパケッ
ト送信時間情報を受信する制御論理回路をさらに含み、前記パケット到着時間に基づいて前記パケットを送出する前記制御論理回路に
は前記パケット送信時間に前記パケットを送信する制御論理回路が含まれること
を特徴とする請求項１２項記載の装置。
【請求項１４】前記パケット到着時間情報を前記スイッチの第１ポートと
関連付ける制御論理回路をさらに含み、及び前記パケットを受信する前記制御論理回路が前記スイッチの前記第１ポートと
関連付けられていることを特徴とする請求項１３項記載の装置。
【請求項１５】前記パケット送信時間情報を前記スイッチの第２ポートと
関連付ける制御論理回路をさらに含み、及び前記パケット送信する前記制御論理回路が前記スイッチの前記第２ポートと関
連付けられていることを特徴とする請求項１４項記載の装置。
【請求項１６】前記パケットフローはリアルタイムアプリケーションと関
連付けられ、及び前記リアルタイムアプリケーションに関連付けられた前記パケットの送信を実
施するため受信した非リアルタイムパケットの送信を遅延させる制御論理回路を
さらに含むことを特徴とする請求項１５項記載の装置。
【請求項１７】前記非リアルタイムパケットの送信を遅延させる前記制御
論理回路は、前記リアルタイムアプリケーションに関わる前記パケットの受信前
に前記非リアルタイムパケットが受信された場合には、前記受信された非リアル
タイムパケットの送信を遅延させるように作動することを特徴とする請求項１６
項記載の装置。
【請求項１８】参照時間に参照パケットを受信する制御論理回路と、前記参照時間に対応してスケジュール間隔開始時間を決定する制御論理回路と
、及び前記パケット到着時間情報及び前記スケジュール間隔開始時間に基づいて前記
パケット到着時間を決定する制御論理回路をさらに含むことを特徴とする請求項
１２項記載の装置。
【請求項１９】前記パケット到着時間情報にはパケットフローオフセット
値が含まれ、及び前記パケット到着時間を決定する前記制御論理回路には前記ス
ケジュール間隔開始時間へ前記パケットフローオフセット値を加える制御論理回
路が含まれることを特徴とする請求項１８項記載の装置。
【請求項２０】参照パケットを受信し、及び前記参照パケットが受信され
た参照時間を記録する制御論理回路と、前記参照時間に対応してスケジュール間隔開始時間を決定する制御論理回路と
、及び前記パケット送信時間情報と前記スケジュール間隔開始時間に基づいて前記パ
ケット送信時間を決定する制御論理回路をさらに含むことを特徴とする請求項１
３項記載の装置。
【請求項２１】前記パケット送信時間情報にはパケットフローオフセット
値が含まれ、及び前記パケット送信時間を決定する前記制御論理回路には前記ス
ケジュール間隔開始時間へ前記パケットフローオフセット値を加える制御論理回
路が含まれることを特徴とする請求項２０項記載の装置。
【請求項２２】前記パケット送信時間情報を第２のスイッチへ送信する制
御論理回路と、及び承認と不承認のいずれかを含む前記パケット送信時間情報の受取通知を受信す
る制御論理回路をさらに含むことを特徴とする請求項１３項記載の装置。
【請求項２３】前記複数のスイッチ装置の第１の部分集合が前記パケット
到着時間情報と前記パケット送信時間情報を含む参照パケットの発信源であり、
前記複数のスイッチ装置の第２の部分集合が前記パケット到着時間情報と前記パ
ケット送信時間情報を含む参照パケットの受信側であることを特徴とする請求項
１３項記載の複数のパケット交換装置を含む通信装置ネットワーク。
【請求項２４】前記複数のパケット交換装置の所定の１装置が集中スケジ
ューリングエージェントとして作動して前記パケット到着時間情報と前記パケッ
ト送信時間情報を含む参照パケットを生成することを特徴とする請求項１３項記
載の複数のパケット交換装置を含む通信装置ネットワーク。
【請求項２５】マスタークロックシステムはスケジュール間隔の始まりを
決定するように作用し、スケジュール情報は少なくとも１のパケットフロースケ
ジュールを限定し、前記スケジュール情報は前記少なくとも１のパケットフロー
に関わる少なくとも１のパケットについてスケジューリングされた受信及び送信
時間を限定し、及び複数のインタフェースポートはその各々が送信制御論理回路及び受信制御論理
回路を有し、前記送信及び受信機能の各々は前記スケジュール情報及び前記マス
クロックシステムに対応し、前記複数のインタフェースポートの少なくとも１ポ
ートの前記送信制御論理回路は、前記少なくとも１のパケットフローに関わる受
信パケットの送信時間を前記パケットフロースケジュールによって限定される前
記スケジュール間隔への送信時間オフセットに対応して決定するように作用する
ことより構成されるスケジュールベーストパケットスイッチ。
【請求項２６】前記複数のインタフェースポートの少なくとも１ポートの
前記受信制御論理回路は、前記少なくとも１のパケットフローに関わるパケット
の受信時間を前記パケットフロースケジュールによって限定される前記スケジュ
ール間隔への送信時間オフセットに対応して決定するように作用することを特徴
とする請求項２５項記載のスケジュールベーストパケットスイッチ。
【請求項２７】前記マスタークロックは外部クロック参照に対応し、前記
外部クロック参照は受信されたハートビートパケットに基づくことを特徴とする
請求項２５項記載のスケジュールベーストパケットスイッチ。
【請求項２８】前記スケジューリングされたパケットスイッチ中のマスタ
ークロックシステムによってスケジュール間隔の始まりを決定するステップと、少なくとも１のパケットフロースケジュールを限定し及び前記少なくとも１の
パケットフローに関わる少なくとも１のパケットについてスケジューリングされ
た受信及び送信時間を決定するスケジュール情報を前記スケジューリングされた
パケットスイッチ内に保存するステップと、及び前記スケジューリングされたパケットスイッチのインタフェースポートの送信
制御論理回路において、及び前記スケジュール情報と前記マスタークロックシス
テムに対応して、前記パケットフロースケジュールにより限定された前記スケジ
ュール間隔への送信時間オフセットに対応する前記少なくとも１のパケットフロ
ーに関わる受信パケットの送信時間を決定するステップから構成されるスケジュ
ーリングされたパケットスイッチ中におけるスケジュールベーストパケットの交
換方法。
【請求項２９】前記スケジューリングされたパケットスイッチのインタフ
ェースポートの受信制御論理回路において、及び前記スケジュール情報と前記マ
スタークロックシステムに対応して、前記パケットフロースケジュールによって
限定された前記スケジュール間隔への受信時間オフセットに対応した少なくとも
１のパケットフローに関わるパケットの受信時間を決定するステップをさらに含
むことを特徴とする請求項２７項記載の方法。
【請求項３０】ハートビートパケットを受信するステップと、及び前記ハートビートパケットに対応する前記マスタークロックシステムによって
前記スケジュール間隔の始まりを決定するステップをさらに含むことを特徴とす
る請求項２６項記載の方法。