JPH1185632A

JPH1185632A - データ通信方法

Info

Publication number: JPH1185632A
Application number: JP9248175A
Authority: JP
Inventors: Osamu Takeuchi; 理竹内; Takahiro Nakano; 隆裕中野; Masaaki Iwasaki; 正明岩▲崎▼; Teruo Tanaka; 輝雄田中
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1997-09-12
Filing date: 1997-09-12
Publication date: 1999-03-30
Also published as: US6321260B1

Abstract

(57)【要約】【課題】データのルーティング処理がCPUネックとなる
ような高速ネットワークや伝送路を複数ノードで共有す
るネットワークを介した通信において、送信ノードが要
求する転送レートの充足を保証するデータ通信方法を提
供する。【解決手段】送信ノードはデータ転送を開始する前に、
データ転送の際に必要となるハードウェア資源の確保を
要求するCONNECTメッセージを受信ノードに向け送信す
る。CONNECTメッセージを中継する各ノードは、データ
転送の際に必要なCPU時間やバンド幅などの確保を行な
う。伝送路を複数ノードで共有するネットワークのバン
ド幅を確保する際には、該ネットワークの総トラフィッ
ク量を管理するノードと制御メッセージの送受信を行な
う。CONNECTメッセージが受信ノードに到達したら、該
メッセージの到達を知らせるACCEPTメッセージを送信ノ
ードに送り返す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はデータ通信方法に関
し、特に複数の情報処理装置を介して接続された二つの
情報処理装置間で、送信情報処理装置が要求する転送レ
ートを充足しつつ、音声データや動画データなどの連続
メディアデータを転送可能とするデータ通信方法に関す
る。

【０００２】

【従来の技術】音声データや動画データなどの連続メデ
ィアデータを、その送信を行なう情報処理装置（以後、
送信ノードと略す）が要求する転送レートを充足しつつ
転送する通信方法として、ST-II（RFC-1190）及びTTCP/
ITM（特願平9ー75018）が知られている。

【０００３】ST-IIにおいて、一つの送信ノードから一
つの受信を行なう情報処理装置（以後、受信ノードと略
す）に対して連続メディアデータ転送を行なう際の処理
手順につき以下説明する。送信ノードから受信ノードに
到達するまでに、連続メディアデータは複数のデータ中
継を行なう情報処理装置（以後、ルータノードと略す）
によって中継されるものとする。

【０００４】送信ノードは連続メディアデータの転送を
開始する前に、CONNECTメッセージを受信ノードに向か
って送信する。CONNECTメッセージは送信ノードから受
信ノードに到達するまでの間に、複数のルータノードを
通過する。このときに通過するルータノードはST-IIの
ルーティング機能により一意に決定される。

【０００５】CONNECTメッセージには以下の情報が含ま
れる。

【０００６】Ａ）ホップ識別子Ｂ）QoS（QoSとは「Quality of Service」の略。ここで
は「連続メディアデータの品質」を意味する）パラメー
タＣ）受信ノードの識別情報ホップ識別子は、CONNECTメッセージにより生成される
送信ノードと受信ノードとの間の論理コネクションを識
別するために用いられる。CONNECTメッセージを次に受
信するルータノードまたは受信ノード（以後、次段ノー
ドと略す、またCONNECTメッセージを一つ前に受信する
ノードを以後前段ノードと呼ぶ）との間とのネゴシエー
ションにより決定される。本識別子は、次段ノード上で
一意となるように指定しなければならない。また、同一
論理コネクションに対応するホップ識別子がノードによ
り異なっている可能性もある。QoSパラメータは、上記
論理コネクション上を転送される連続メディアデータの
要求品質（例えば要求ネットワークバンド幅など）を指
定する。受信ノードの識別情報には、受信ノードをネッ
トワーク上で一意に決定するのに十分な情報が格納され
る。

【０００７】CONNECTメッセージを受信したルータノー
ドは以下を行なう。

【０００８】１）ホップ識別子の取得次段ノードにおいて未使用であるホップ識別子を次段ノ
ードとのネゴシエーションにより一つ確保する。次段ノ
ードは、CONNECTメッセージに含まれる受信ノードの識
別情報からST-IIのルーティング機能が一意に決定す
る。

【０００９】２）連続メディア転送時に使用するルーテ
ィング情報の生成受信した連続メディアデータに含まれるホップ識別子か
ら、次段ノードに転送する連続メディアデータに含める
べきホップ識別子、LANアドレスを検索可能とするのに
十分なルーティング情報を構築する。

【００１０】３）連続メディア転送時に必要となる資源
の予約ルータノード上の物理バッファ、ルータノードと次段ノ
ードとの間のネットワークのバンド幅を確保する。ネッ
トワークのバンド幅を確保するために他ノードと制御メ
ッセージを授受する方法についてはST-IIは規定してい
ない。そのため、ATMネットワークのような論理的な伝
送路（以後「論理的な伝送路」のことを「伝送路」と略
して記す）を自ノードのみで占有して使用できるネット
ワークにおいては、確保したバンド幅を連続メディアデ
ータ転送時にも使用可能であることを保証できる。しか
し、Ethernetのような伝送路を他ノードと共有するネッ
トワークにおいては上記保証は不可能である（この理由
についてはすぐ後で述べる）。

【００１１】４）CONNECTメッセージの次段ノードへの
中継 ST-IIのルーティング機能により一意に決定される次段
ノードへCONNECTメッセージを中継する。

【００１２】また、CONNECTメッセージを受信した受信
ノードは、送信ノードからの論理コネクション確立要求
を受け入れる場合にはACCEPTメッセージを、拒絶する場
合にはREFUSEメッセージを送信ノードに向かって送信す
る。

【００１３】受信ノードからのACCEPTメッセージを受信
した送信ノードは、連続メディアデータの転送を開始す
る。送信ノードから送られる連続メディアデータには、
送信ノードの次段ノードとのネゴシエーションにより得
られたホップ識別子が含まれる。

【００１４】連続メディアデータは、受信ノードに到達
するまでに複数のルータノードを通過する。ルータノー
ドは、この連続メディアデータのルーティングを上記
２）で得られたルーティング情報を用いて行なう。すな
わち、CONNECTメッセージやACCEPTメッセージなどの制
御メッセージのルーティング方式と、連続メディアデー
タのルーティング方式は異なる。

【００１５】連続メディアデータの中継処理に必要な物
理バッファやネットワークバンド幅は上記３）において
確保されている。従って、物理バッファ不足や、（次段
ノードとの間で伝送路を占有できるネットワークにおい
ては）バンド幅不足により、連続メディアデータの中継
が遅延され、送信ノードが要求するデータ転送レートが
充足されなくなることはあり得ない。

【００１６】次にTTCP/ITMにおいて、送信ノードから受
信ノードに対して連続メディアデータを転送する際の処
理手順につき以下説明する。TTCP/ITMでは送信ノードと
受信ノードがのCSMA/CD方式（「Open Design No.3 −イ
ーサネットトTCP/IP（Ethernet and TCP/IP）−」、CQ
シュッパンシャ（CQ Shuppansha）、pp7〜17）の同一LA
N上に存在することを仮定している。従って、送信ノー
ドと受信ノードはルータノードを介さずに通信を行な
う。

【００１７】CSMA/CD方式のLAN（すなわち、伝送路を複
数ノードで共有するネットワーク）では、他のデータ転
送による連続メディアデータの転送遅延が発生し得る。
すなわち、送信ノードが連続メディアデータを自ノード
が要求する転送レートで転送しようとしても、転送開始
時にネットワークが他のデータ転送により使用中である
ため、連続メディアデータの転送が遅延し得る。結果と
して、送信ノードが要求するデータ転送レートが充足さ
れなくなる。上記を防ぐためには、LAN上で使用されて
いるバンド幅の総計がいかなるときにも一定の上限値を
超えないよう制御する必要がある。使用バンド幅の総計
が一定の上限値以下であれば、ネットワークが使用中で
あることによる遅延の発生の確率が小さくなり、送信ノ
ードが要求するデータ転送レートも充足可能となる。

【００１８】TTCP/ITMでは、LAN上に一つ、そのLANの総
使用バンド幅を集中管理する帯域管理サーバが存在す
る。LAN上でデータ転送を行なおうとするノードはすべ
て、帯域管理サーバに対してバンド幅の使用を要求する
制御メッセージを送信する。

【００１９】連続メディアデータの転送を要求するノー
ドは、この制御メッセージに要求バンド幅の情報も含め
る。

【００２０】バンド幅の使用要求メッセージを受信した
帯域管理サーバは、各要求ノードが使用可能なバンド幅
を算出する。この算出は、総使用バンド幅が一定の上限
以下となるように、かつ、連続メディアデータを送信す
るノードが要求するバンド幅はできる限り充足されるよ
うに行なう。算出が完了したら、帯域管理サーバは各要
求ノードに、各ノードの使用可能なバンド幅を知らせる
制御メッセージを送信する。

【００２１】使用可能なバンド幅の通知を受けた各要求
ノード（送信ノードも含む）は、指定されたバンド幅を
使ってデータ転送を開始する。

【００２２】本方式に従えば、LANの総使用バンド幅は
一定値以下に抑えられ、送信ノードが要求する転送レー
トに従った連続メディア転送も可能となる。すなわち伝
送路を共有するLAN上の２ノード間での連続メディア転
送において、送信ノードが要求する転送レートの充足を
TTCP/ITMは可能としている。

【００２３】

【発明が解決しようとする課題】前述した通りST-II
は、複数のルータノードを介して送信ノードから受信ノ
ードへの連続メディア転送を行なっても、ルータ上の物
理バッファ不足により、送信ノードの要求転送レートが
充足されなくなる可能性はない。また送信ノードと受信
ノードとの間のネットワークがATMなどの伝送路を占有
可能なネットワークのみから構成されている場合には、
ネットワークのバンド幅不足により送信ノードの要求転
送レートが充足されなくなる可能性はない。

【００２４】しかし近年ネットワークは高速化し、ルー
タノードや受信ノードの処理能力不足により、ルータノ
ードが行なう連続メディアデータの中継処理又は受信ノ
ードが行なう連続メディアデータの受信処理が遅延する
可能性がある。例えば、送信ノードから受信ノードに向
かって、80Mbpsの連続メディアデータを中継したいもの
とする。中途のネットワークは100MbpsのFast Ethernet
及び155MbpsのATMネットワークで構成されており、ST-I
IにおけるCONNECTメッセージによる論理コネクションの
確立は成功する。しかし、中途のルータノードが40Mbps
の連続メディアデータの中継能力しかない場合、ルータ
ノードにおいて中継処理の遅延が発生し、送信ノードが
要求する転送レートは充足不可能となる。同様に受信ノ
ードが40Mbpsの連続メディア処理の受信能力しかない場
合にも、送信ノードの要求転送レートは充足不可能とな
る。

【００２５】また、ST-IIは、送信ノードと受信ノード
との間にEthernetのような伝送路を他ノードと共有する
ネットワークが存在する場合にも、送信ノードが要求す
る転送レートの充足が不可能となる可能性もある。例え
ば上述の例では、ST-IIにおける論理コネクションの確
立には成功するものの、送信ノードやルータノードがFa
st Ethernetに連続メディアデータの送出を開始しよう
とした時に、Fast Ethenetが同一LANに属する他ノード
により使用中であり、送出の遅延が発生し得る。結果と
して送信ノードの転送レートの充足が困難となってしま
う。

【００２６】またTTCP/ITMは、伝送路共有型ネットワー
クにおける連続メディアデータ転送において、送信ノー
ドの転送レートの充足を保証する。しかし、この方式は
送信ノードと受信ノードが同一のLAN上にあることを仮
定しており、送信ノードから受信ノードまでルータノー
ドを中継して連続メディア転送を行なう場合には適用不
可能である。

【００２７】そこで、本発明のデータ通信方法では、送
信ノードと受信ノードとの間に（１）ルータノードの中
継処理能力不足や受信ノードの受信処理能力不足による
伝送遅延が発生しうる高速ネットワーク、（２）伝送路
を複数ノードで共有するネットワーク、（３）ルータノ
ードのすべてが存在する場合にも、送信ノードが要求す
る転送レートを充足しつつ、送信ノードから受信ノード
までの連続メディアデータの転送を可能とするデータ通
信方法を提供することを目的とする。

【００２８】

【課題を解決するための手段】上に掲げた課題を解決す
るため、本発明では、データを送信する情報処理装置が
そのデータ転送を開始する前に、データ転送の際に必要
となるハードウェア資源の確保を要求する制御メッセー
ジをデータを受信する情報処理装置に対して送り出し、
データを受信する情報処理装置が該制御メッセージを受
信したら、該制御メッセージの受信を知らせる制御メッ
セージをデータを送信する情報処理装置に送り返す、一
つまたはそれ以上の情報中継装置を間にはさんで接続さ
れた情報処理装置群において、データを送信すべき情報
処理装置、受信すべき情報処理装置、データパケットの
サイズ、データパケットの転送レートを引数にとり、指
定されたサイズのデータパケットを指定したデータ転送
レートにおいて転送する際に必要となるハードウェア資
源の確保を要求する外部インタフェースを備え、データ
を送信する情報処理装置が該外部インタフェースを呼び
出すステップと、データを送信する情報処理装置が該外
部インタフェースの呼び出し時に指定された引数の値
を、該制御メッセージに格納するステップと、情報中継
装置が該制御メッセージの中継処理を行なう直前に、該
制御メッセージに格納されているパケットサイズ、転送
レートを有するデータの中継処理を行なうのに十分なCP
U時間を予約するステップと、データを受信する情報処
理装置が該制御メッセージを受信したら、該制御メッセ
ージに格納されているパケットサイズ、転送レートを有
するデータの受信処理を行なうのに十分なCPU時間を予
約するステップ、を有することを特徴とするデータ通信
方法を提供する。

【００２９】また本発明では、情報処理装置間に伝送路
を複数の情報処理装置で共有するネットワークが存在す
る上記の情報処理装置群において、情報中継装置が、該
制御メッセージを受信し、かつ該制御メッセージを伝送
路を複数の情報処理装置で共有するネットワーク経由で
中継する直前に、該ネットワークの総トラフィック量を
管理する情報処理装置に、データ中継の際に必要となる
バンド幅の予約を要求する制御メッセージを送信するス
テップ、を有することを特徴とするデータ通信方法も提
供する。

【００３０】さらに本発明では、上記の情報処理装置群
において、データを送信、受信する処理のうち、パケッ
トサイズに依存する処理が必要とする単位サイズあたり
のCPU時間と、パケットサイズに依存しない処理が必要
とするCPU時間をそれぞれ宣言可能な外部インタフェー
スを備え、情報中継装置が上記外部インタフェースを呼
び出すステップと、情報中継装置が、該制御メッセージ
の中継処理を行なう直前に、該制御メッセージに格納さ
れているデータパケットのサイズ、転送レート、該外部
インタフェース呼び出し時に宣言したCPU時間から、デ
ータ中継の際に必要となるCPU時間を算出するステッ
プ、を有することを特徴とするデータ通信方法も提供す
る。

【００３１】

【発明の実施の形態】以下、本発明の実施の形態を詳細
に説明する。

【００３２】図１に本実施の形態で仮定するノード構成
及びノード間を結ぶネットワーク構成を示す。

【００３３】本実施の形態では、連続メディアデータを
送受信しあう送信ノード(101)及び受信ノード(102)が複
数のルータノード(103)を介してネットワーク接続され
ていることを仮定している。ルータノードは、送信ノー
ドから受信ノードに送られる制御データ及び連続メディ
アデータの中継処理を行なう。送信ノードと受信ノード
との間に存在するネットワークには、Ethernetのような
伝送路共有型ネットワーク(105)と、ATMのような伝送路
占有型ネットワーク(106)が混在しているものとする。
伝送共有型ネットワークには、そのネットワークで使用
されているバンド幅の総計を管理する帯域管理サーバ(1
04)が１つ存在するものとする。

【００３４】図２に、本発明のデータ通信方法に従った
連続メディアデータを行なう際に必要となる制御データ
の流れを示す。

【００３５】本発明のデータ通信方法では、送信ノード
(101)が連続メディアデータを受信ノード(102)に転送を
開始する前にCONNECT制御メッセージ(201)を受信ノード
に向かって送信する。CONNECT制御メッセージは、送信
ノードから受信ノードまでの論理コネクションの確立を
要求する。論理コネクションの確立後は、コネクション
に沿った連続メディアデータ送信、中継、受信に必要な
物理バッファ、CPU時間、バンド幅がコネクション上の
各ノードで確保されていることが保証される。

【００３６】CONNECT制御メッセージはルータノード(10
3)により中継されつつ受信ノードまで到達する。CONNEC
T制御メッセージを送信、中継する送信ノード及びルー
タノードは、CONNECT制御メッセージを次のノードに送
信、中継する直前に上記各種資源を予約する。この予約
方法の詳細については後述する。

【００３７】CONNECT制御メッセージを受け取った受信
ノードは、送信ノードからの論理コネクションを受け入
れる場合はACCEPT制御メッセージ(202)を送信ノードに
送る。送信ノードはACCEPT制御メッセージを受信したら
連続メディアデータの転送を開始する。

【００３８】このように本発明のデータ通信方法では、
CONNECT制御メッセージとACCEPT制御メッセージを連続
メディアデータ転送に先立って交換することにより、バ
ンド幅不足、ノードの処理能力不足（CPU時間不足）、
物理バッファ不足により連続メディアデータ転送遅延が
発生しないことを保証可能としている。

【００３９】上記の例でCONNECT制御メッセージの送
信、中継の直前に行なう各種資源予約が失敗する場合も
考えられる。その場合の制御データの流れを図３に示
す。資源予約に失敗したノードは送信ノード(101)に向
かってRESV_FAIL制御メッセージ(301)が送り出す。さら
にRESV_FAILメッセージを送信、中継する各ノードは、
その送信、中継の直前に、CONNECT制御メッセージ(201)
を送信、中継する直前に確保した各種資源の解放処理を
行なう。これにより送信ノードは連続メディアデータ転
送に必要な各種資源の予約が不可能であることを知るこ
とができる。また、各ノード上で無駄に予約された資源
の解放も可能となる。

【００４０】図４に本発明のデータ通信方法を実現する
ために各ノード（送信ノード、受信ノード、ルータノー
ド）が備える必要のある、ソフトウェアモジュール、及
びデータ構造の構成を示す。

【００４１】各ノードには、連続メディアデータの送信
及び受信、資源を割り当て処理の際に使用する各種パラ
メータの設定を行なうアプリケーション(401)が存在す
る。さらに、各ノードは、ネットワークインタフェース
カード(417)を制御するネットワークデバイスドライ
バ、タイマデバイス(418)を制御するタイマデバイスド
ライバが備わっているものとする。

【００４２】また各ノードには、CRSVP受信モジュール
(402)、CRSVP送信モジュール(406)、TTCP受信モジュー
ル(403)、TTCP送信モジュール(407)、RT受信モジュール
(404)、RT送信モジュール(408)、NRT受信モジュール(40
5)、NRT送信モジュール（４０９）が存在する。これら
は、制御メッセージや連続メディアデータをネットワー
クで送受信するために必要なプロトコルスタックであ
る。

【００４３】ＣＲＳＶＰ受信モジュール(402)及びCRSVP
送信モジュール(406)は、図２及び図３で示したCONNECT
制御メッセージ、ACCEPT制御メッセージ、RESV_FAIL制
御メッセージを授受するためのプロトコルスタックであ
る。CRSVP受信モジュールは、上記制御メッセージを受
信した際にネットワークデバイスドライバ(415)により
起動される。これらのメッセージを受信すると、必要に
応じてバンド幅やCPU時間などの各種資源の予約や連続
メディアデータのルーティング情報の構築を行なう。そ
の結果をバンド幅割り当てテーブル(410)、CPU割り当て
テーブル(412)、連続メディアデータのルーティング情
報テーブル(411)に反映する。

【００４４】なお、伝送路共有型ネットワークにおいて
バンド幅を予約する場合には、帯域管理サーバに対して
バンド幅の予約を要求する制御メッセージを送信すべく
TTCP送信モジュールを呼び出す。また、各種資源の予約
を完了後、制御メッセージを他ノードに中継、送信する
必要がある場合には、CRSVP送信モジュールを呼び出
す。

【００４５】TTCP受信モジュール(403)及びTTCP送信モ
ジュール(405)は、伝送路共有型ネットワークでバンド
幅を予約するため、帯域管理サーバとの間で制御メッセ
ージを授受する際に必要となるプロトコルスタックであ
る。前述した通りバンド幅予約が必要のある場合に、TT
CP送信モジュールはCRSVP受信モジュールから呼び出さ
れる。バンド幅を要求する制御メッセージを帯域管理サ
ーバに送出すると、帯域管理サーバはその要求結果を含
む制御メッセージを自ノードに送り返す。TTCP受信モジ
ュールは、その制御メッセージをネットワークデバイス
ドライバ(415)を経由して受け取る。さらにCRSVP受信モ
ジュールを起動してその結果を通知する。

【００４６】RT受信モジュール(404)、RT送信モジュー
ル(408)は、連続メディアデータの受信及び送信を行な
うために必要なプロトコルスタックである。RT受信モジ
ュールは周期スケジューラ(416)により周期駆動され
る。RT受信モジュールは、ネットワークデバイスドライ
バ(415)により受信された連続メディアデータを検索
し、連続メディアデータが自ノード宛のものであれば、
アプリケーション(401)に連続メディアデータ到達を通
知する。連続メディアデータを他ノードに中継する必要
がある場合にはRT送信モジュールを呼び出す。RT送信モ
ジュールは、連続メディアデータのルーティング情報テ
ーブル(411)を参照してその中継処理を行なう。また、R
T送信モジュールはアプリケーションからの連続メディ
アデータの転送要求も受け付ける。この場合、RT送信モ
ジュールはアプリケーションからトラップによって呼び
出される。

【００４７】NRT受信モジュール(405)、NRT送信モジュ
ール(409)は、通常データの受信及び送信を行なうため
に必要なプロトコルスタックである。これらは、既存の
UDP/IPプロトコルスタック（「Open Design No.3 ーイ
ーサネットトTCP/IP（Ethernetand TCP/IP）ー」、CQシ
ュッパンシャ（CQ Shuppansha）、pp18〜40）などと全
く同様の動作を行なう。以後本実施例では、NRT受信モ
ジュール、送信モジュールにUDP/IPプロトコルスタック
の受信モジュール、送信モジュールが使用されているこ
とを仮定する。

【００４８】さらに、各ノードには送信制御モジュール
(413)が存在する。送信制御モジュールはネットワーク
インタフェースカードごとに存在する。送信制御モジュ
ールは、CRSVP送信モジュール(406)、TTCP送信モジュー
ル(407)、RT送信モジュール(408)、NRT送信モジュール
(409)がネットワークに送出を要求するデータを一旦キ
ューイングし、バンド幅割り当てテーブル(410)に従
い、割り当てられたバンド幅を過不足なく使用しながら
データ転送を行なう（ネットワークデバイスドライバ(4
15)にデータ転送要求を発行する）処理を行なう。この
モジュールが存在することにより、CRSVP受信モジュー
ルが構築したバンド幅割り当てテーブルに厳密に従った
ネットワークへのデータ転送が実現可能となる。

【００４９】また各ノードには周期スケジューラ(414)
が存在する。周期スケジューラはタイマデバイスドライ
バ(416)により起動され、送信制御モジュール、及びRT
送信モジュールを厳密に一定周期で駆動する処理、及
び、これらのモジュールの走行時間を、CRSVP受信モジ
ュールが構築したCPU割り当てテーブル(412)の内容と厳
密に一致させる処理を行なう。このモジュールが存在す
ることにより、CRSVP受信モジュールが構築したCPU割り
当てテーブルに厳密に従ったスケジューリングが実現可
能となる。本実施例では、周期スケジューラとして、ア
イソクロナススケジューラ（タケウチタダシホカ（Tada
shi Takeuchi, et al.）、「アイソクロナス・スケジュ
ーラノセッケイトセイノウヒョウカ（A Design and Per
formanceEvaluation of Isochronous Scheudler）」、
ジョホウショリガッカイケンキュウホウコク（IPSJ SIG
Reports）、97-OS-74）が使用されているものとする。

【００５０】図５に送信制御モジュール(413)に対して
各送信モジュールが送信パケットを受け渡すために必要
となるデータ構造を示す。

【００５１】RT送信モジュール(408)が送信制御モジュ
ールに対してパケット送信を要求する場合、RT送信キュ
ー(502)に送信を要求するパケットをエンキューする。R
T送信キューは論理コネクションごとに存在する。ホッ
プ識別子（論理コネクションごとに存在する）とキュー
ポインタとの対応はキューテーブル(501)により管理す
る。

【００５２】一方、CRSVP送信モジュール(406)、TTCP送
信モジュール(407)、NRT送信モジュール(409)が送信制
御モジュールに対してパケット送信を要求するパケット
をエンキューする。一つの送信制御モジュールに対して
NRT送信キューは一つしか存在しない。

【００５３】図６にネットワークデバイスドライバ(41
5)が各受信モジュールに受信パケットを受け渡すために
必要となるデータ構造を示す。

【００５４】ネットワークデバイスドライバはパケット
を受信すると、そのパケットヘッダの内容からそのパケ
ットを受信すべき受信モジュールを判別する。そしてCR
SVP受信モジュール(402)、TTCP受信モジュール(403)、R
T受信モジュール(404)、NRT受信モジュール(405)のそれ
ぞれに受信パケットを受け渡す場合には、CRSVP受信キ
ュー(601)、TTCP受信キュー(602)、RT受信キュー(60
3)、NRT受信キュー(604)にエンキューする。

【００５５】以下、図４に示したモジュールのうちの主
要モジュールの動作の概要を示す。

【００５６】まず図７〜１５を用いてCRSVP受信モジュ
ール(402)の動作の概要を示す。

【００５７】図７に、CRSVP受信モジュール及びCRSVP送
信モジュール(406)が送受信する制御メッセージのパケ
ットフォーマットを示す。CRSVPパケットはIPヘッダ(70
1)、送信ノードIPアドレス(702)、送信ノードポート番
号(703)、受信ノードIPアドレス(704)、受信ノードポー
ト番号(705)、コマンド(706)、要求転送レート(707)か
らなる。

【００５８】IPヘッダ(701)は、既存のIPパケットのIP
ヘッダと全く同様の情報が含まれる。

【００５９】送信ノードIPアドレス(702)、送信ノード
ポート番号(703)、受信ノードIPアドレス(704)、受信ノ
ードポート番号(705)は、それぞれ本パケットに対応す
る論理コネクションの送受信ノードのIPアドレス及び論
理コネクション上に連続メディアデータを転送する際に
送受信ノードで使用するポート番号を格納する。

【００６０】コマンド(706)には、パケットのタイプ（C
ONNECT、ACCEPT、RESV_FAILのいずれか）が格納され
る。

【００６１】要求転送レート(707)は、パケットタイプ
がCONNECTである場合にのみ使用され、要求する連続メ
ディアデータの転送レートを格納する。本要求転送レー
トには、１パケットあたりのパケット長と単位時間あた
りの転送パケット数が格納されているものとする。

【００６２】図８にCRSVP受信モジュール(402)の処理フ
ローを示す。CRSVP受信モジュールは、ネットワークド
ライバ(415)からのCRSVPパケットの受信通知または、ア
プリケーションからのCRSVPパケットの送出要求の発行
により起動される。受信パケット及び送信要求が行われ
たパケットはCRSVP受信キュー(601)にキューイングされ
る。

【００６３】ステップ801で、CRSVP受信モジュールは、
このキューイングされたパケットをデキューする。

【００６４】ステップ802で、デキューしたパケットの
パケットタイプフィールド(706)を検索する。パケット
タイプフィールドがCONNECTである場合にはステップ803
に、ACCEPTである場合にはステップ804に、RESV_FAILで
ある場合にはステップ805にジャンプする。

【００６５】ステップ803で、CRSVP受信モジュールは、
各種資源の予約と、CONNECT制御メッセージの送信、中
継またはACCEPT制御メッセージの中継処理を行なうべく
CRSVP送信モジュール(406)の関数呼び出しを行なう。こ
の処理の詳細については図９を用いて後述する。

【００６６】ステップ604で、CRSVP受信モジュールは、
ACCEPT制御メッセージの中継処理を行なうべくCRSVP送
信モジュールを呼び出す。

【００６７】ステップ605で、CRSVP受信モジュールは、
各種資源の解放処理と、（必要ならば）RESV_FAIL制御
メッセージの中継処理を行なうべくCRSVP送信モジュー
ルを呼び出す。各種資源の解放処理は、ステップ603に
おける各種資源の予約処理と逆の処理を行なうことによ
り実現できる。そのため、その詳細の処理フローは本明
細書では省略する。

【００６８】図９にステップ803を詳細化した処理フロ
ーを示す。

【００６９】ステップ901で、自ノードが受信ノードか
それ以外のノードであるかの判定を行なう。本判定は、
ステップ801でデキューしたパケットのIPヘッダ(701)の
宛先IPアドレスと受信ノードIPアドレス(703)が一致す
るか否かにより実現可能である。受信ノードであれば
（上記二つが一致するならば）ステップ910に、それ以
外であればステップ902にジャンプする。

【００７０】ステップ902で、CONNECT制御メッセージに
より構築される論理コネクションに対応するホップ識別
子を取得する。このホップ識別子は次段ノードで一意と
なるべく、次段ノードとの通信により決定する。この決
定アルゴリズムは、ST-IIにおけるホップ識別子の決定
アルゴリズムと同様であるため省略する。この通信によ
り、次段ノードにおいて、論理コネクションに属する送
信ノードのIPアドレス及びポート番号とホップ識別子と
の対応がホップ識別子登録テーブル(1406)に登録され
る。このテーブルのデータ構造の詳細については後述す
る。

【００７１】ステップ903で、連続メディアデータの送
信、中継に必要となるCPU時間を予約する。この予約方
法の詳細は図１０、１１を用いて後述する。

【００７２】ステップ904で、自ノードと次段ノードの
との間のネットワークが伝送路占有型ネットワークであ
るか、伝送路共有型ネットワークであるかの判別を行な
う。本判定はステップ801でデキューしたパケットのIP
ヘッダ(701)を参照しつつIPルーティング処理を行な
い、送出先ネットワークインタフェースカード(417)を
決定することにより実現できる。該当ネットワークが伝
送路占有型ネットワークである場合にはステップ905
に、伝送路共有型ネットワークである場合にはステップ
906にジャンプする。

【００７３】ステップ905で連続メディアデータの送
信、中継に必要なバンド幅を確保する。この確保は、ス
テップ902で確保したホップ識別子と、ステップ801でデ
キューしたパケットの要求転送レートフィールド(907)
との対を定められたテーブルに登録することにより行な
う。登録されている要求転送レートの合計がネットワー
クの転送能力を超える場合には、本ステップのバンド幅
予約をエラーリターンさせる。

【００７４】ステップ906で、帯域管理サーバ(104)と通
信し、伝送路共有型ネットワークの帯域予約要求を行な
う。本ステップの詳細は図１２、１３を用いて後述す
る。

【００７５】ステップ907で、連続メディアデータの送
信、中継の際に必要となるルーティング情報の構築を行
なう。本ステップの詳細は図１４、１５を用いて後述す
る。

【００７６】ステップ908で、連続メディアデータの送
信、中継の際に必要となる物理バッファを確保する。本
ステップの詳細は、ST-IIにおいて物理バッファを確保
するステップと同様であるため省略する。

【００７７】ステップ909で、CONNECTメッセージを次段
ノードに送信、中継すべくCRSVP送信モジュール(406)を
呼び出す。そして、ステップ914にジャンプし正常終了
する。

【００７８】ステップ910で、連続メディアデータの受
信に必要となるCPU時間を予約する。本予約方法の詳細
は図１０、１１を用いて後述する。

【００７９】ステップ911で、連続メディアデータの受
信の際に必要となるルーティング情報の構築を行なう。
本ステップの詳細は図１４、１５を用いて後述する。

【００８０】ステップ912で、連続メディアデータの受
信に必要となる物理バッファを予約する。本ステップの
詳細は、ST-IIにおいて物理バッファを確保するステッ
プと同様であるため省略する。

【００８１】ステップ913で、ACCEPTメッセージを送信
ノードに送るためにCRSVP送信モジュール(406)を呼び出
す。本ステップで生成されるACCEPTメッセージを格納す
るパケットは、IPヘッダ(701)及びパケットタイプ(706)
フィールドを除いてステップ801でデキューしたパケッ
トと同様である。IPヘッダの送り元IPアドレスには自ノ
ードのIPアドレスが、宛先IPアドレスには送信ノードIP
アドレス(702)に格納されているIPアドレスが格納され
る。パケットタイプ(706)フィールドにはACCEPTが格納
される。

【００８２】また、図示していないが、ステップ903、9
05、906、908、910、912において、各種資源予約が失敗
する場合がある。その場合、これらのステップで確保し
た資源を解放してから、RESV_FAIL制御メッセージを送
信するためにCRSVP送信モジュールを呼び出す。本ステ
ップで生成されるRESV_FAIL制御メッセージを格納する
パケットは、パケットタイプ(706)フィールドにRESV_FA
ILが格納されている点を除けば、ステップ913で生成さ
れるパケットと同様である。

【００８３】図１０に、ステップ903、ステップ910にお
けるCPU時間の予約を実現するために必要なテーブル類
のデータ構造を示す。

【００８４】CPU時間の予約処理は、CPU割り当てテーブ
ル(1001)、CPU割り当て上限テーブル(1006)、処理単価
テーブル(1009)を用いて行なう。CPU割り当てテーブル
は、ステップ903、ステップ910において動的に更新され
る。一方、CPU割り当て上限テーブル、処理単価テーブ
ルは、アプリケーション(401)が予め設定する。この設
定の際に使用するインタフェースについては後述する。

【００８５】CPU割り当てテーブルは、送信制御モジュ
ール(413)のCPU割り当てを管理するテーブル(1002)（以
後、送信制御モジュールCPU割り当てテーブルと略す）
と、RT受信モジュールのCPU割り当てを管理するテーブ
ル(1003)（以後、RT受信モジュールCPU割り当てテーブ
ルと略す）からなる。それぞれのテーブルには、ホップ
識別子(1004)と、そのホップ識別子に対応する論理コネ
クション上を流れる連続メディアデータの送信または受
信のために予約してあるCPUの利用率(1005)の対が格納
されている。

【００８６】CPU割り当て上限テーブルは、送信制御モ
ジュール及びRT受信モジュールのそれぞれが使用可能な
最大のCPU利用率を格納するフィールド(1007、1008)が
存在する。送信制御モジュールCPU割り当てテーブル、R
T受信モジュールCPU割り当てテーブルに格納されている
使用率の合計値は、フィールド1007、1008に格納されて
いる使用率よりも小さい値でなければならない。

【００８７】処理単価テーブルは、該当ノードで１パケ
ットの送受信に要するCPU使用率の単価を格納するテー
ブルである。本テーブルは受信処理の単価を格納したテ
ーブル(1010)と、送信処理の単価を格納したテーブル(1
011)からなる。各テーブルには、送受信処理のパケット
長に依存する処理の１バイトあたりの処理単価(1012)
と、パケット長非依存処理の処理単価(1013)が格納され
る。

【００８８】図１１に、ステップ903、910にて行なわれ
るCPU時間の予約処理の詳細を示す。

【００８９】ステップ1101にて、自ノードが送信ノー
ド、中継ノード、受信ノードのいずれかであるかを判定
する。本判定は、ステップ801にてデキューしたパケッ
トのIPヘッダ(701)の送信元アドレスと送信ノードIPア
ドレス(702)が一致するか、及びIPヘッダの宛先アドレ
スと受信ノードIPアドレス(704)が一致するかを検査す
ることにより判定可能となる。自ノードが送信ノードで
ある場合にはステップ１１０２に、中継ノードである場
合にはステップ１１０３に、受信ノードである場合には
ステップ1105にジャンプする。

【００９０】ステップ1102では、送信制御モジュールCP
U割り当てテーブル(802)への登録処理を行なう。登録す
るホップ識別子は、ステップ902において確保したホッ
プ識別子を指定する。また、CPU利用率は以下の手順で
計算される値を格納する。

【００９１】ステップ801でデキューしたパケットの要
求転送レートに、パケット長Ｌ、単位時間あたりのパケ
ット数Ｎが格納されているとする。また、テーブル1011
のパケット長依存フィールドにCsd、パケット長非依存
フィールドにCsiが格納されているものとする。この場
合、登録すべきCPU利用率は Csi＋Csd×Nとなる。

【００９２】ステップ1103はステップ1102と全く同様で
ある。

【００９３】ステップ1104では、RT受信モジュールCPU
割り当てテーブル(1003)への登録処理を行なう。登録す
るホップ識別子は、ステップ801においてデキューした
パケットの送信ノードIPアドレス(702)、送信ノードポ
ート番号(703)に対応するホップ識別子を指定する。こ
の対応は後述するホップ識別子登録テーブル(1406)から
求められる。また、登録すべきCPU利用率は以下により
計算される。

【００９４】ステップ801でデキューしたパケットの要
求転送レートに、パケット長Ｌ、単位時間あたりのパケ
ット数Ｎが格納されているとする。また、テーブル1010
のパケット長依存フィールドにCsd、パケット長非依存
フィールドにCsiが格納されているものとする。この場
合、登録すべきCPU利用率は Csi＋Csd×Nとなる。

【００９５】ステップ1105はステップ1104と全く同様で
ある。

【００９６】ステップ1106において、送信制御モジュー
ルCPU割り当てテーブル(1002)に登録されているCPU利用
率の合計、及びRT受信モジュールCPU割り当てテーブル
(1003)に登録されているCPU利用率の合計が、CPU割り当
て上限テーブル(1006)に格納されている各上限値を超え
ていないかのチェックを行なう。超えていなければステ
ップ1107にジャンプして正常終了する。超えていればス
テップ1108にジャンプし異常終了する。異常終了後、ス
テップ902で確保したホップ識別子やステップ903で確保
したCPU時間の予約を解放し、RESV_FAIL制御メッセージ
を送信ノードに対して送信すべくCRSVP送信モジュール
を呼び出す。

【００９７】図１２にステップ906の伝送路共有型ネッ
トワークのバンド幅予約を実現するために必要なデータ
構造を示す。

【００９８】バンド幅管理はネットワークのバンド幅の
バンド幅割り当てテーブル(1201)と、バンド幅割り当て
上限テーブル(1207)からなる。バンド幅割り当てテーブ
ルは、各ノードに接続されているネットワークインタフ
ェースカード(417)毎に存在し、各ネットワークインタ
フェース毎に管理されるバンド幅の予約状況を格納す
る。本テーブルはRT送受信モジュール(404)により使用
されるバンド幅の予約状況を管理するテーブル(1202)
（以後、RTバンド幅割り当てテーブルと略す）と、NRT
送受信モジュール(405)により使用されるバンド幅の予
約状況を管理するテーブル(1205)（以後、NRTバンド幅
割り当てテーブルと略す）からなる。RTバンド幅割り当
てテーブルには、さらに、ホップ識別子を格納するフィ
ールド(1203)と、該当ホップ識別子に対応する論理コネ
クション上の連続メディアデータ転送の際に使用される
バンド幅を格納するフィールド(1204)が存在する。これ
により、論理コネクションごとのバンド幅の予約状況が
判別可能となっている。

【００９９】バンド幅割り当て上限テーブルは、ネット
ワークインタフェース名(1208)と、該当ネットワークイ
ンタフェースにおける上限バンド幅(1209)の対を格納す
る。バンド幅割り当てテーブルに登録される使用バンド
幅の合計は、本テーブルの上限バンド幅を超えてはなら
ない。

【０１００】図１３にステップ906で行なわれる伝送路
共有型ネットワークのバンド幅予約処理フローの詳細を
示す。

【０１０１】ステップ1301にて、バンド幅予約を要求す
る制御メッセージを帯域管理サーバ(104)に対して送信
するため、TTCP送信モジュール(407)を起動する。ステ
ップ801でデキューしたパケットの要求転送レートフィ
ールド(707)に含まれる情報から算出した要求バンド幅
をTTCP送信モジュールには併せて通知する。

【０１０２】ステップ1302にてTTCP送信モジュールとTT
CP受信モジュール(403)が帯域管理サーバとの制御メッ
セージの送受信を行なう。この処理の詳細はTTCP/ITMの
制御メッセージの送受信処理と同様である。

【０１０３】ステップ1303にて上記処理の完了を待ち合
わせる。CRSVP受信モジュール(402)はバンド幅予約のた
めの制御メッセージの受信を契機に起動されるTTCP受信
モジュールにより上記待ち合わせは解除される。その際
にCRSVP受信モジュールが要求したバンド幅予約の結果
も併せて通知される。ハンド幅予約の成功通知が到達し
たらステップ1304に、失敗通知が到達したらステップ13
06にジャンプする。

【０１０４】ステップ1304にてバンド幅割り当てテーブ
ル(1201)の更新処理を行なう。具体的には、RTバンド幅
割り当てテーブル(1202)のホップ識別子フィールド(120
3)にステップ902で取得したホップ識別子を格納し、使
用バンド幅フィールド(1204)に上記ステップにより予約
に成功したバンド幅を格納する。さらにステップ1205に
ジャンプして正常終了する。

【０１０５】なお、本ステップにより、バンド幅割り当
てテーブルに登録されている使用バンド幅の合計がバン
ド幅上限テーブル(1207)に格納されている上限バンド幅
(1209)を超えることはない（超えないように帯域管理サ
ーバがバンド幅の割り当てを行なう）。また、NRTバン
ド幅割り当てテーブル(1205)の使用バンド幅(1206)フィ
ールドの更新は、上記ステップ1302にてTTCP受信モジュ
ールが行なう。

【０１０６】ステップ1306では異常終了を行なう。以
後、ステップ902で確保したホップ識別子やステップ903
で確保したCPU時間の予約を解放し、RESV_FAIL制御メッ
セージを送信ノードに対して送信すべくCRSVP送信モジ
ュール(406)を呼び出す。

【０１０７】図１４にルーティング情報の管理に必要な
データ構造を示す。ルーティング情報は、ルーティング
情報テーブル(1401)とホップ識別子登録テーブル(1406)
を用いて管理する。

【０１０８】ルーティング情報テーブルは、受信ホップ
識別子(1402)、インタフェース名(1403)、送信ホップ識
別子(1404)、LANアドレス(1405)の各フィールドからな
る。そして、受信ホップ識別子(1402)をヘッダに格納し
て到達した連続メディアデータを格納するパケットは、
送信ホップ識別子(1404)とLANアドレス(1405)で指定さ
れる値をヘッダに格納した後、インタフェース名(1403)
で指定されるネットワークインタフェースから送出すべ
きであることを示す。

【０１０９】ホップ識別子登録テーブルは、ホップ識別
子(1407)、送信ノードIPアドレス(1408)、送信ノードポ
ート番号(1409)の各フィールドからなる。そして、送信
ノードIPアドレス(1408)、送信ノードポート番号(1409)
の対で一意に決定される論理コネクションにはホップ識
別子(1407)が対応していることを示す。前述した通り、
本識別子テーブルの登録エントリは、前段ノードがステ
ップ902を実行しホップ識別子を取得する際に生成され
る。

【０１１０】ステップ907、ステップ911のルーティング
情報テーブルの構築方法の詳細を図１５を用いて示す。

【０１１１】受信ホップ識別子(1402)フィールドには、
ステップ801で受信したパケットの送信ノードIPアドレ
ス(702)、及び送信ノードポート番号(703)が一致するホ
ップ識別子登録テーブルのエントリのホップ識別子(140
7)フィールドの値が格納される。

【０１１２】インタフェース名(1403)、及びLANアドレ
ス(1405)フィールドには、ステップ801で受信したパケ
ットのIPヘッダ部(701)と、IPルーティング情報から得
られる、次段ノードと接続されているインタフェース
名、及び次段ノードのLANアドレスを格納する。なお自
ノードが受信ノードであり、次段ノードが存在しない場
合にはインタフェース名にLOCALが格納される。

【０１１３】また、送信ホップ識別子(1404)フィールド
には、ステップ902で取得したホップ識別子を格納す
る。ただし、自ノードが受信ノードである場合には何も
格納しない。

【０１１４】図１６にCRSVP送信モジュール(406)の動作
の概要を示す。

【０１１５】ステップ1601において、送出ネットワーク
インタフェースの決定を行なう。これは、CRSVP受信モ
ジュール(402)から受け渡されたCRSVPパケットのIPヘッ
ダ部(701)とIPルーティング情報から、IPのルーティン
グ処理と同様な処理を行なうことにより実現する。

【０１１６】ステップ1602において、次段ノードのLAN
アドレスなどを含むLANヘッダの作成を行なう。この処
理は、IPプロトコルスタックがEthenetに送出する際のE
thenetヘッダ作成アルゴリズムと同様のアルゴリズムに
より実現できる。

【０１１７】ステップ1603において、ステップ1602で生
成したLANヘッダを含んだパケットをNRT送信キュー(50
3)にエンキューする。エンキューされたパケットは、後
に送信制御モジュール(413)によりネットワークに送出
される。

【０１１８】そして、ステップ1604にて正常終了する。

【０１１９】図１７、１８を用いてRT受信モジュール(4
04)の動作の概要を示す。

【０１２０】図１７にRT送受信モジュールが送受信する
パケットのフォーマットを示す。パケットはポート識別
子(1701)、UDPパケット(1702)フィールドからなる。UDP
パケットフィールドにはUDPヘッダと連続メディアデー
タが含まれる。

【０１２１】図１８にRT受信モジュールの処理フローを
示す。

【０１２２】RT受信モジュールは周期スケジューラ(41
4)により周期駆動される。ネットワークデバイスドライ
バ(415)は、RT受信モジュールが受信すべきパケットが
到達すると、RT受信キュー(603)に該当パケットをエン
キューする。そして、RT受信モジュールがステップ1801
にてRT受信キューが空であるか否かの検査を行なう。空
であればステップ1806にジャンプし正常終了し、空でな
ければステップ1802にジャンプする。

【０１２３】ステップ1802にてRT受信キューから受信パ
ケットをデキューする。

【０１２４】ステップ1803にて、受信したパケットが自
ノード宛か否かを判別する。これは、受信したパケット
のポート識別子(1701)フィールドに対応するルーティン
グ情報テーブル(1401)のエントリを検索することにより
実現する。該当エントリのインタフェース名(1403)フィ
ールドにLOCALが格納されていれば自ノード宛のパケッ
トであり、それ以外であれば他ノード宛のパケットであ
ることがわかる。自ノード宛のパケットであればステッ
プ1804にジャンプし、そうでなければステップ1805にジ
ャンプする。

【０１２５】ステップ1804にて、RT受信モジュールはUD
Pプロトコル処理の後、アプリケーション(401)にUDPパ
ケットの到達を通知する。そしてステップ1801にジャン
プする。

【０１２６】ステップ1805にて、RT受信モジュールは、
受信パケットの中継処理を行なうためにRT送信モジュー
ル(408)を呼び出す。そしてステップ1801にジャンプす
る。

【０１２７】図１９を用いてRT送信モジュール(408)の
動作の概要を示す。

【０１２８】ステップ1901にて、RT受信モジュール(40
4)から中継処理を依頼されたパケットのホップ識別子(1
701)フィールドを更新する。更新すべきホップ識別子フ
ィールドの値は、該当パケットのホップ識別子フィール
ドの値に対応するルーティング情報テーブル(1401)のエ
ントリのホップ識別子(1404)フィールドを参照すること
により求められる。

【０１２９】ステップ1902にて、中継するパケットに含
めるべきLANヘッダを作成する。これは、上記で得たエ
ントリのLANアドレス(1905)フィールドの値を用いれば
容易に実現できる。

【０１３０】ステップ1903にて、中継するパケットデー
タをネットワークデバイスドライバ(415)に送出しても
らうべく、該当パケットのRT送信キュー(502)へのキュ
ーイングを行なう。キューイングすべきキューのアドレ
スは以下のアルゴリズムにて決定する。まず上記で得た
エントリのインタフェース名(1403)フィールドに対応す
るキューテーブル(501)を検索する。そして得られたキ
ューテーブルのエントリのうち、ホップ識別子フィール
ドの値が、中継処理を依頼されたパケットのホップ識別
子(1701)と一致するエントリを探し出す。探し出したエ
ントリのキューポインタフィールドの値が求めるアドレ
スである。

【０１３１】図２０を用いて送信制御モジュール(413)
の動作の概要を示す。送信制御モジュールはネットワー
クデバイスドライバ(415)ごと（すなわちネットワーク
インタフェースカード(417)ごと）に存在する。

【０１３２】図２０に送信制御モジュールの処理フロー
を示す。

【０１３３】送信制御モジュールは周期スケジューラに
より厳密に一定の間隔で周期駆動される。また、送信制
御モジュールは１周期に送り出すパケットのサイズの総
計を厳密に一定に保つ。そのため送信制御モジュール
は、バンド幅割り当てテーブル(1201)に登録されている
使用バンド幅に厳密に従ったネットワークへの転送を実
現していると言える。

【０１３４】ステップ2001にて、送信制御モジュール
は、対応するRT割り当てバンド幅テーブル(1202)を読み
出し、自送信制御モジュールにより送信すべき連続メデ
ィアデータのホップ識別子(1203)、及び使用バンド幅(1
204)を読み出す。ステップ2002にて、ステップ2001で読
み出したバンド幅から１周期に送り出すべきパケットの
サイズの総計を算出する。そして、該当ポップ識別子に
対応するRT送信キュー(502)のアドレスをキューテーブ
ル(501)を用いて検索後、該当キューのキュートップか
らパケットサイズの総計が上記の値になるまでパケット
のデキュー処理を行なう。ステップ2001及びステップ20
02の処理をRTバンド幅割り当てテーブルに登録されてい
るエントリ数分だけ繰り返す。

【０１３５】ステップ2003にて、送信制御モジュール
は、対応するNRT割り当てバンド幅テーブル(1205)の使
用バンド幅(1206)フィールドを読み出す。

【０１３６】ステップ2004にて、ステップ2003で読み出
したバンド幅から１周期に送り出すべきパケットサイズ
の総計を算出する。そして、NRT送信キュー(503)を探索
し、キュートップからパケットサイズの総計が上記の値
になるまでパケットのデキュー処理を行なう。

【０１３７】ステップ2005にて、ステップ2002及びステ
ップ2004でデキューしたパケットの送出をネットワーク
デバイスドライバに要求すべく、ネットワークデバイス
ドライバの起動処理を行なう。

【０１３８】そしてステップ2006にて正常終了する。

【０１３９】図２１を用いてアプリケーション(401)の
動作の概要を示す。

【０１４０】アプリケーションは連続メディアデータの
転送に先立つ、論理コネクションの確立要求、及び連続
メディアデータの送受信処理、資源処理の際に使用する
各種パラメータの設定を行なう。連続メディアデータの
送受信処理は、既存のソケットインタフェースを用いて
実現可能である。また、論理コネクションの確立要求
は、以下の外部インタフェースを用いて行なう。

【０１４１】kern_return_t establish_connection( po
rtno_t send_portno, ipaddr_t recv_IPaddr, portno
_t recv_portno, size_t pakcet_size, int packet_n
um )上記関数は、自ノードを送信ノードとし、引数recv
_IPaddrで指定されるIPアドレスを持つノードを受信ノ
ードとする論理コネクションの確立を要求する。併せ
て、論理コネクション上を流れる連続メディアデータ
は、引数send_portnoで指定される送信ノード上のUDPポ
ートから送信され、かつ引数recv_portnoで指定される
受信ノード上のUDPポートで受信されることを宣言す
る。かつ、送受信される連続メディアデータの１パケッ
トのサイズは引数packet_sizeで指定したサイズであ
り、かつ秒あたり引数packet_numで指定した数だけのデ
ータが転送されることも宣言する。

【０１４２】本関数の宣言の後上記で指定したUDPポー
ト間で連続メディアデータの転送処理を行なった場合、
送信側が引数packet_size、packet_numで指定した転送
レートに従った送信処理を行なっている限りにおいて
は、受信側も同一の転送レートにおける受信が可能であ
ることを保証する。

【０１４３】本関数の処理フローを図２１に示す。

【０１４４】ステップ2101にて、CRSVP受信モジュール
(402)に渡すべきCONNECTタイプのパケットを生成する。
本パケットのIPヘッダ(701)の送信元IPアドレスと送信
ノードIPアドレス(702)には自ノードのIPアドレスを、I
Pヘッダ(701)の宛先IPアドレスと受信ノードIPアドレス
(704)には引数recv_IPaddrで指定されたIPアドレスを格
納する。また、送信ノードポート番号(703)フィールド
には引数send_portnoで指定されるポート番号を、受信
ノードポート番号(705)フィールドには引数recv_portno
で指定されるポート番号を格納する。さらに、要求転送
レートフィールド(707)には引数packet_size、packet_n
umで指定される値を、パケットタイプ(706)フィールド
にはCONNECTを格納する。さらに、生成したパケットをC
RSVP受信キュー(601)にエンキューする。

【０１４５】ステップ2102にて、CRSVP受信モジュール
を起動する。

【０１４６】ステップ2103にて、CRSVP受信モジュール
が上記パケットをCRSVP受信キューからデキューした
後、前述した各種資源の予約処理やルーティング情報の
構築を行なう。さらに、上記パケットを受信ノードに対
して送信すべくCRSVP送信モジュルを起動する。CONNECT
タイプのパケットを受信ノードに対して送信すると、上
記パケットに対応するACCEPTタイプパケット、またはRE
SV_FAILタイプパケットが自ノードに送り返される。こ
れらのパケットを受信すると、CRSVP受信モジュールは
アプリケーションにその到達を通知する。

【０１４７】ステップ2104にて、アプリケーションは上
記通知を受け取り起動する。

【０１４８】ステップ2105にて、受信したパケットがAC
CEPTタイプかRESV_FAILタイプであるかを判定する。ACC
EPTであればステップ2106にジャンプし正常終了（KERN_
SUCCESSをリターン）し、RESV_FAILであればステップ21
07にジャンプし異常終了（エラーリターン）する。

【０１４９】また、アプリケーションは、CPU資源の予
約の際に使用する、CPU割り当て上限テーブル(1006)に
登録されるパラメータや、処理単価テーブル(1009)の各
パラメータを設定する。これは以下の関数を用いて行な
う。これらの関数の処理フローは自明であるため省略す
る。kern_return_t set_cpu_upperbound( module_name_
t module_name, float utilization ) 本関数は、引数
module_nameで指定するモジュールのCPU時間使用率の上
限を引数utilizationで指定する値に設定する。module_
nameには「送信制御モジュール」を示すITM、「RT受信
モジュール」を示すRTRECVERのいずれかを指定する。本
関数の宣言の後には、各モジュールのCPU使用率が上記
で設定した値を超えるようなCPU時間予約がCRSVP受信モ
ジュールから発行されても受け付けなくなる。

【０１５０】kern_return_t set_cpu_transaction_time
( transaction_type_t transaction_type, boolean len
gth_dependent, float utilization ) 本関数は、引数transaction_typeで指定したタイプの処
理に要するCPU時間が引数utilizationで指定した値であ
ることを宣言する。ただし、引数transaction_typeには
「送信」を示すSEND、「受信」を示すRECVのいずれかを
指定する。また、引数length_dependentにTRUEを指定し
た場合には、utilizationは送受信処理のうちパケット
長の依存した処理が必要とする１バイトあたりのCPU使
用率を示す。引数length_dependentにFALSEを指定した
場合には、utilizationは送受信処理のうちパケット長
に依存しない処理が必要とするCPU使用率を示す。CRSVP
受信モジュールが行なうCPU時間の予約処理は、上記で
設定したパラメータを使用して行なう。

【０１５１】上記で説明してきた各種モジュールの他に
図４には、TTCP受信モジュール(403)、TTCP送信モジュ
ール(407)、NRT受信モジュール(404)、NRT送信モジュー
ル(408)、周期スケジューラ(414)、ネットワークデバイ
スドライバ(415)、タイマデバイスドライバ(416)が図示
されているが、これらのモジュールの動作は既存モジュ
ールの動作と全く同様であるので本明細書ではその概要
の説明は省略する。

【０１５２】

【発明の効果】本発明のデータ通信方法では、送信ノー
ドと受信ノードとの間で連続メディアデータの転送を開
始する前に、送信ノードの要求転送レートを充足可能と
すべく送受信ノード及び中途のルータノードの各種資源
を予約する。

【０１５３】上記資源には各ノードのCPU時間も含まれ
る。そのため、ルータノードの中継処理能力不足や受信
ノードの受信処理能力不足による伝送遅延が発生しうる
高速ネットワークが送受信ノードの間に存在したとして
も、要求転送レートは充足可能となる。

【０１５４】また、送受信ノードの間にEthenetのよう
な伝送路を複数ノードで共有するネットワークが存在し
た場合には、資源予約時に帯域管理サーバに対して帯域
予約要求を発行する。従って、伝送共有路ネットワーク
通過時に要求転送レートが満たされなくなることはな
い。また本通信方法は、中途にルータノードが介在す
る場合も上記資源予約が実行可能である。従って、送受
信ノード間にルータノードが存在しても要求転送レート
の充足は可能となる。

【図面の簡単な説明】

【図１】本発明の実施の形態で仮定するノード構成及び
ネットワーク構成図。

【図２】資源予約成功時の制御メッセージの流れ図。

【図３】資源予約失敗時の制御メッセージの流れ図。

【図４】ノードのソフトウェアモジュール構成及びデー
タ構造図。

【図５】パケット送信時に使用するデータ構造図。

【図６】パケット受信時に使用するデータ構造図。

【図７】CRSVPパケットのフォーマット。

【図８】CRSVP受信モジュールの処理フロー図。

【図９】ステップ803の詳細処理フロー図。

【図１０】CPU時間予約時に使用するデータ構造図。

【図１１】ステップ903、910の詳細処理フロー

【図１２】バンド幅予約時に使用するデータ構造図。

【図１３】ステップ906の詳細処理フロー図。

【図１４】ルーティング情報構築時に使用するデータ構
造図。

【図１５】ステップ907、911の詳細処理フロー図。

【図１６】CRSVP送信モジュールの処理フロー図。

【図１７】RTパケットのフォーマット。

【図１８】RT受信モジュールの処理フロー図。

【図１９】RT送信モジュールの処理フロー図。

【図２０】送信制御モジュールの処理フロー図。

【図２１】関数establish_connectionの処理フロー図。

【符号の説明】

101 …… 送信ノード、102 …… 受信ノード、103 ……
ルータノード、104…… 帯域管理サーバ、201 …… CO
NNECT制御メッセージ、402 …… CRSVP受信モジュー
ル、406 …… CRSVP送信モジュール、412 …… CPU割り
当てテーブル、1201 …… バンド幅割り当てテーブル。

───────────────────────────────────────────────────── フロントページの続き (72)発明者田中輝雄神奈川県秦野市堀山下１番地株式会社日立製作所汎用コンピュ−タ事業部内

Claims

【特許請求の範囲】

【請求項１】データを送信する情報処理装置がそのデー
タ転送を開始する前に、データ転送の際に必要となるハ
ードウェア資源の確保を要求する制御メッセージをデー
タを受信する情報処理装置に対して送り出し、データを受信する情報処理装置が該制御メッセージを受
信したら、該制御メッセージの受信を知らせる制御メッ
セージをデータを送信する情報処理装置に送り返す、一つまたはそれ以上の情報中継装置を間にはさんで接続
された情報処理装置群において、データを送信すべき情報処理装置、受信すべき情報処理
装置、データパケットのサイズ、データパケットの転送
レートを引数にとり、指定されたサイズのデータパケッ
トを指定したデータ転送レートにおいて転送する際に必
要となるハードウェア資源の確保を要求する外部インタ
フェースを備え、データを送信する情報処理装置が該外部インタフェース
を呼び出すステップと、データを送信する情報処理装置が該外部インタフェース
の呼び出し時に指定された引数の値を、該制御メッセー
ジに格納するステップと、情報中継装置が該制御メッセージの中継処理を行なう直
前に、該制御メッセージに格納されているパケットサイ
ズ、転送レートを有するデータの中継処理を行なうのに
十分なCPU時間を予約するステップと、データを受信する情報処理装置が該制御メッセージを受
信したら、該制御メッセージに格納されているパケット
サイズ、転送レートを有するデータの受信処理を行なう
のに十分なCPU時間を予約するステップ、を有すること
を特徴とするデータ通信方法。
【請求項２】情報処理装置間に伝送路を複数の情報処理
装置で共有するネットワークが存在する請求項１の情報
処理装置群において、情報中継装置が、該制御メッセージを受信し、かつ該制
御メッセージを伝送路を複数の情報処理装置で共有する
ネットワーク経由で中継する直前に、該ネットワークの
総トラフィック量を管理する情報処理装置に、データ中
継の際に必要となるバンド幅の予約を要求する制御メッ
セージを送信するステップ、を有することを特徴とする
データ通信方法。
【請求項３】請求項１の情報処理装置群において、データを送信、受信する処理のうち、パケットサイズに
依存する処理が必要とする単位サイズあたりのCPU時間
と、パケットサイズに依存しない処理が必要とするCPU
時間をそれぞれ宣言可能な外部インタフェースを備え、情報中継装置が上記外部インタフェースを呼び出すステ
ップと、情報中継装置が、該制御メッセージの中継処理を行なう
直前に、該制御メッセージに格納されているデータパケ
ットのサイズ、転送レート、該外部インタフェース呼び
出し時に宣言したCPU時間から、データ中継の際に必要
となるCPU時間を算出するステップ、を有することを特
徴とするデータ通信方法。