JPH11346247A - データ中継方法 - Google Patents

Abstract

(57)【要約】 【課題】論理的伝送路を共有するため、衝突による伝送
遅延やバッファ枯渇によるパケット喪失が発生しうるネ
ットワークを経由するデータ通信において、送信ノード
が要求する転送レートを遵守するデータ中継方法を提供
する。 【解決手段】送信ノードはデータ転送開始前にその転送
レートをルータノードに通知する。ルータノードはその
転送レートに１より大きな定数値を乗じたレートでデー
タ転送を行なうのに十分な資源を確保する。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

【従来の技術】複数のデータ中継装置を介して接続され
た二つの情報処理装置間で、送信情報処理装置が要求す
る送信レートを充足しつつ、音声データや動画データな
どの連続メディアデータを転送可能とするデータ中継方
法としては、RSVP（L.Zhang, S. Deering, D. Estrin,
S. Shenker, D. Zappala, "RSVP: A New Resource ReSe
rVation Protocol," IEEE Network Magazine, Sep. 199
3）がよく知られている。 図１で示されたシステムにR
SVPを用いたデータ中継方法を適用した例を以下に示
す。

【０００３】図１では、連続メディアデータを送信する
情報処理装置である送信ノード(101)と、連続メディア
データを受信する情報処理装置である受信ノード(102)
との間に、データ中継装置であるルータノード(103)が
二つ存在している。送信ノード(101)とルータノード(10
3)、及びルータノード(103)間は、Ethernetを代表例と
する論理的な伝送路を複数ノードで共有する伝送路共有
型ネットワーク(104)にて接続されている。また受信ノ
ード(101)とルータノード(103)との間は、ATMを代表例
とする論理的な伝送路を共有しない伝送路非共有型ネッ
トワーク(105)にて接続されている。

【０００４】ルータノード(103)のハードウェアウェア
構成、ソフトウェア・モジュール構成、ソフトウェア・
モジュールが使用するデータ構造及び連続メディアデー
タ中継時の動作の概要を図２を用いて示す。ルータノー
ド(103)は、送信ノード（１０１）が要求する送信レー
トに厳密に従ったデータ中継を行なう。これにより送信
ノード（１０１）から受信ノード(102)までの高品質な
連続メディアデータの転送が実現する。以後、ルータノ
ード(103)のデータ中継時の動作と併せて、ルータノー
ド(103)のハードウェア構成、ソフトウェア・モジュー
ル構成、データ構造の概要を述べる。

【０００５】ルータノードは、ネットワークインタフェ
ース(201)により、伝送路共有型ネットワーク(104)や伝
送路非共有型ネットワーク(105)に接続されている。ネ
ットワークインタフェース(201)は、ネットワークイン
タフェースドライバ(202)（ソフトウェア・モジュー
ル）により制御される。

【０００６】ネットワークインタフェースドライバ(20
2)は、フリーバッファキュー(207)（データ構造）から
未使用のバッファをデキューし、ネットワークインタフ
ェース(201)に対し、パケットが受信したらパケットの
内容を該当バッファに書き込むよう要求を発行してお
く。

【０００７】ネットワークインタフェースドライバ(20
2)はパケット受信を検知すると、IPプロトコルスタック
(203)（ソフトウェア・モジュール）に受信したパケッ
トの内容を通知する。IPプロトコルスタック(203)は、
受信通知を受けたパケットがRSVPパケット（連続メディ
アデータ転送時に必要となるCPU時間やネットワーク帯
域幅などの各種資源を予めルータノード内に確保するこ
とを要求するパケット）である場合には、RSVPプロトコ
ルスタック(204)（ソフトウェア・モジュール）に受信
パケットの内容を通知する。さらに、RSVPプロトコルス
タック(204)は、必要な各種資源の確保処理を行ない、
確保した資源を使用すべきストリーム（送信ノードと受
信ノードの組）を識別するために用いるストリームIDや
該当ストリームが使用する帯域幅などを帯域予約テーブ
ル(206)に登録する。RSVPプロトコルスタック(204)は上
記処理を完了すると、IPプロトコルスタック(203)に該
当パケットの中継を要求（送信要求を発行）する。

【０００８】IPプロトコルスタック(203)は、データ中
継に必要な処理（中継先のネットワークインタフェース
の決定処理など）を行ない、パケットスケジューラ(20
5)（ソフトウェア・モジュール）に送信すべきパケット
の内容を通知する。

【０００９】パケットスケジューラ(205)は、送信ノー
ド(101)が要求するデータ転送レートに厳密に従ったデ
ータ中継を実現するソフトウェア・モジュールである。
送信すべきパケットを受け取ったパケットスケジューラ
(205)は、直ちに該当パケットをネットワークインタフ
ェースドライバ(202)に渡さず、一旦送信を保留する。
パケットスケジューラ(205)は周期的に駆動し、駆動さ
れる度に、帯域予約テーブル(206)に書かれている帯域
幅に相当する分のパケットをネットワークインタフェー
スドライバ(202)に渡す。帯域予約テーブル(206)には、
送信先ネットワークの最大使用可能帯域から予約されて
いる帯域幅の総計を引いた値（以後「余剰帯域幅」と呼
ぶ）も格納されている。RSVPパケットによる資源確保を
行なっていないパケット（以後「NRTパケット」と呼
ぶ。またRSVPパケットによる資源確保を行なっているパ
ケット、すなわち連続メディアデータが格納されている
パケットを「RTパケット」と呼ぶ。）は、データ中継レ
ートの総計がこの「余剰帯域幅」を超えないようにネッ
トワークインタフェースドライバ(202)に渡される。

【００１０】送信すべきパケットを受け取ったネットワ
ークインタフェースドライバ(202)は、ネットワークイ
ンタフェース(201)を経由してパケットを送信する処理
を行なった後、使用していたバッファをフリーバッファ
キュー(207)に返す（エンキューする）。

【００１１】高品質な連続メディアデータの転送の実現
するためには、上記の構成をとるルータノード(103)の
他に、送信ノード(101)が、要求データ送信レートを各
ルータノード(103)に通知する必要がある。このため、
送信ノード(101)は、転送の際にルータノードにおいて
必要となる各種資源を確保してもらうべく、受信ノード
(102)に向かってRSVPパケットを送信する。RSVPパケッ
トには、要求する送信レートが含まれる。このRSVPパケ
ットを中継する各種ルータノード(103)は、RSVPプロト
コルスタック(204)において上記送信レートのデータの
中継を行なう際に必要となる資源の確保処理を行なう。
また帯域予約テーブル(206)の更新も行なう。 上記処
理が完了したら、送信ノード(101)は連続メディアデー
タの送信を開始する。送信ノード(101)からのデータ送
信レートは、RSVPパケットに含まれていた情報と一致し
ていなければならない。データを中継するルータノード
(103)のパケットスケジューラ(205)は、帯域予約テーブ
ル(206)に格納されている帯域幅の情報（RSVPパケット
に格納されていた送信レートの情報と一致する）に従う
ようにパケット中継を行なうので（中継を行なうのに必
要な資源は予め確保されている）、データの伝送遅延や
喪失が発生しない限り、送信ノード(101)から受信ノー
ド(102)まで、送信ノードが要求した送信レートを厳密
に守った連続メディアデータの転送が可能となる。

【００１２】

【発明が解決しようとする課題】RSVPによる連続メディ
アデータの転送は、パケットの伝送遅延や喪失が発生し
ない限りにおいて、送信ノードが要求する送信レートを
厳密に守ることが可能である。しかし、パケットの伝送
遅延や喪失が発生した場合にはこの限りではない。

【００１３】パケットの伝送遅延が発生すると、RSVPに
よる連続メディアデータの転送は送信ノードが要求する
送信レートを厳密に守れなくなる理由を以下に述べる。

【００１４】伝送路共有型ネットワークにおいては、他
の送信ノードと送信タイミングが衝突することによる伝
送遅延が発生し得る。伝送遅延が発生した場合の、デー
タ転送タイミングを図３に示す。

【００１５】図３において、t307からt309が、送信ノー
ド(101)がパケット送信を開始するタイミングである。
送信ノードは１回の送信タイミングにつき３パケットを
送信すると仮定する。また、t310からt316が各ルータノ
ード(103)におけるパケットスケジューラ(205)の周期駆
動タイミングである。この例では、各パケットスケジュ
ーラ(205)は１回の駆動につき、前の周期に到達したパ
ケットのうち最大３パケットまでを送信している。

【００１６】図３の例においては、送信ノード(101)
が、送信タイミングt307においてパケット301から303
を、送信タイミングt308においてパケット304から306を
送信する。そしてこの例では、パケット303の伝送遅延
が送信ノード(101)とルータノード１(103)を結ぶ伝送路
共有型ネットワーク(104)にて発生している。

【００１７】上記伝送遅延が発生しているため、ルータ
ノード１(103)にはt310とt311の間に２パケットしか到
達しない。そのため送信タイミングt311においては２パ
ケットのみの送信を行なう。また、t311とt312の間に４
パケット到達する。しかし、ルータノード１(103)のパ
ケットスケジューラ(205)は帯域予約テーブル(206)の内
容に従い、そのうちの３パケットのみの送信を行なう。

【００１８】このようにルータノード１(103)では、t31
1の送信タイミングにおいて２パケットのみの送信を行
ない、その他の送信タイミングでも３パケット以下の送
信しか行なわないことから、データ中継レートが、送信
ノード(101)が要求する送信レートより小さくなる。こ
の小さくなったデータ中継レートは以後ルータノード２
(103)においても回復しない。従って受信ノード(102)に
おける連続メディアデータの受信レートも、送信ノード
が要求するレートを充足することはできない。

【００１９】次に、パケット喪失が発生すると、RSVPに
よる連続メディアデータの転送は送信ノードが要求する
送信レートを厳密に守れなくなる理由を以下に述べる。

【００２０】伝送路共有型のネットワークのネットワー
クインタフェース(201)は、すべてのパケットを同等に
扱う。すなわち、ネットワークインタフェースドライバ
(202)が、RTパケットを受信するためのバッファと、NRT
パケットを受信するためのバッファを別々にネットワー
クインタフェース(201)に対して指定することはできな
い。そのためフリーバッファキュー(207)が空になった
際には、RTパケットもNRTパケットも共に受信すること
ができなくなり、パケット喪失が発生する。

【００２１】ところで、パケットスケジューラ(205)
は、NRTパケットのデータ中継レートが余剰帯域幅を超
えないようにNRTパケットの送信処理を行なう。余剰帯
域幅を超えるレートでNRTパケットを受信した場合に
は、超えた分のNRTパケットはパケットスケジューラが
管理するキュー（以後「送信要求キュー」と呼ぶ）に一
旦キューイングしておく。そして、次の駆動タイミング
において該当パケットをデキューして、ネットワークイ
ンタフェースドライバ(202)に該当パケットの送信を要
求する。

【００２２】余剰帯域幅はルータノード(103)間で異な
る可能性がある。例えば、ルータノード１(103)の帯域
予約テーブル(205)に登録されている余剰帯域幅が、ル
ータノード２(103)の帯域予約テーブル(205)に登録され
ている余剰帯域幅より大きかったとする。この状態のも
とで、ルータノード１(103)、伝送路共有型ネットワー
ク(104)、ルータノード２(103)を通過する大量のNRTパ
ケットが存在したとする。 ルータノード１(103)のパ
ケットスケジューラ(205)は、送信要求キューに余剰帯
域幅分以上のパケットがエンキューされているため、ル
ータノード１(103)の帯域予約テーブル(206)に登録され
ている余剰帯域幅と等しいレートでルータノード２(10
3)にNRTパケットを送信する。従って、ルータノード２
(103)の送信要求キューには、ルータノード１(103)の帯
域予約テーブル(205)に登録されている余剰帯域幅と等
しいレートでパケットがキューイングされていく。

【００２３】しかし、ルータノード２(103)の帯域予約
テーブルには、この到達レートより小さい余剰帯域幅が
登録されているため、パケットスケジューラ(205)によ
るパケットのデキューレートはエンキューレートより小
さくなる。従って、送信要求キューにエンキューされて
いるパケット（すなわち使用中であるバッファの総数）
が次第に増えていき、遂にフリーバッファキュー(207)
にエンキューされているバッファがなくなる。

【００２４】フリーバッファキュー(207)が空になる
と、ネットワークインタフェースドライバ(202)はネッ
トワークインタフェース(201)にパケット受信のための
バッファを提供することが不可能となり、以後しばらく
の間ネットワークインタフェース(201)に到達したRTパ
ケットやNRTパケットは失なわれる（パケット喪失が発
生している間は送信要求キューにパケットが到達しない
ので、しばらくするとフリーバッファキューに(207)バ
ッファが再びエンキューされ、受信を再開できる）。RT
パケットの喪失の発生は、送信ノードが要求する送信レ
ートの充足を不可能とする。

【００２５】本発明では、送信ノードと受信ノードとの
間に、Ethernetを代表例とする伝送路を共有するネット
ワークが存在しても、 １）衝突に伴なう伝送遅延によるデータ中継レートの低
下や、 ２）バッファの枯渇によるパケット喪失の発生を防ぎ、
送信ノードが要求する送信レートを充足可能なデータ中
継方法を提供する。

【００２６】

【課題を解決するための手段】本発明では、データを送
信する情報処理装置がそのデータ転送を開始する前に、
データの転送レートを宣言し、かつデータ転送の際に必
要となるハードウェア資源の確保を要求する制御メッセ
ージをデータの受信を実行する情報処理装置に向かって
送り出す、一つまたはそれ以上の情報中継装置を二つの
情報処理装置群の間に直列に接続してある情報処理装置
群において、 １）該制御メッセージを受信した情報中継装置が、デー
タを送信する情報処理装置が要求するデータ転送量に１
より大きな定数値を乗じたデータ量を中継するのに十分
な資源を確保するステップと、 ２）情報中継装置内のソフトウェアモジュールが一定周
期で周期駆動するステップと、 ３）該ソフトウェアモジュールが、高々データを送信す
る情報処理装置が要求するデータ転送レートに１より大
きな定数値を乗じたデータ転送レートに相当するデータ
量を送信するステップ、を有することを特徴とするデー
タ中継方法を提供する。

【００２７】さらに、上記情報処理装置群において、 １）情報中継処理装置に接続されたネットワークインタ
フェースを制御するモジュールが、該ネットワークイン
タフェースを経由して到達したパケットのタイプを判別
するステップと、 ２）該ネットワークインタフェースを制御するモジュー
ルが、該パケットのタイプがデータ転送レートを厳密に
遵守する必要のないタイプのパケットである場合、該パ
ケットのデータ中継処理を行なうモジュールの処理待ち
のパケット数を検索するステップと、 ３）該ネットワークインタフェースを制御するモジュー
ルが、該パケット数が一定の数以上であると判断した場
合には、該パケットを直ちに破棄するステップと、 ４）該パケットのデータ中継処理を行なうモジュール
が、ネットワークインタフェースを制御するモジュール
による送信処理を待ち合わせているパケット数を検索す
るステップと、 ５）該パケットのデータ中継処理を行なうモジュール
が、該パケット数が一定数以上である場合には、該パケ
ットを直ちに破棄するステップ、 を有することを特徴とするデータ中継方法を提供する。

【００２８】

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

【００２９】本実施の形態で仮定するシステム構成は図
１に示した通りである。このシステムにおいて、送信ノ
ードから受信ノードに向かってRTパケットを送信すると
仮定する。

【００３０】本実施の形態で仮定するルータノード(10
3)のハードウェアウェア構成、ソフトウェア・モジュー
ル構成、ソフトウェア・モジュールが使用するデータ構
造を図４を用いて示す。

【００３１】ルータノード(103)は、図２で説明した構
成と同様に、ネットワークインタフェース(201)、ネッ
トワークインタフェースドライバ(202)、IPプロトコル
スタック(203)、RSVPプロトコルスタック(204)、パケッ
トスケジューラ(205)、帯域予約テーブル(206)、フリー
バッファキュー(207)を備える。

【００３２】さらに本構成では、ソフトウェアモジュー
ルとしてRTIPプロトコルスタック(401)を備える。図２
の構成では、IPプロトコルスタック(203)は、RSVPプロ
トコルスタック(204)へのRSVPパケットの受信通知処理
及びRTパケット、NRTパケットの中継処理を行なった。
図４の構成では、IPプロトコルスタック(203)は、RSVP
プロトコルスタック(204)へのRSVPパケットの受信通知
処理及びNRTパケットの中継処理のみを行なう。一方、R
TIPプロトコルスタック(401)はRTパケットの中継処理を
行なう。

【００３３】また本構成では、ネットワークインタフェ
ースドライバ(202)からIPプロトコルスタック(203)に受
け渡すNRTパケットをキューイングするNRT受信キュー(4
02)、及びネットワークインタフェースドライバ(202)か
らRTIPプロトコルスタック(401)に受け渡すRTパケット
をキューイングするRT受信キュー(403)が存在する。IP
プロトコルスタック(203)からパケットスケジューラ(20
5)に受け渡すNRTパケットをキューイングするNRT送信要
求キュー(404)、RTIPプロトコルスタック(204)からパケ
ットスケジューラ(205)に受け渡すRTパケットをキュー
イングするRT送信要求キュー(405)も存在する。

【００３４】本実施の形態で仮定するRSVPプロトコルス
タック(204)のフローチャートを図５に示す。なお、本
実施の形態においても、送信ノード(101)は連続メディ
アデータ転送を開始する前に、ルータノードにおける帯
域予約を行なうため、RSVPパケットを受信ノード(102)
に向かって送信すると仮定する。そのため、RSVPプロト
コルスタック(204)はRSVPパケットを受信したら、そのR
SVPパケットに格納されている帯域幅のデータを中継す
るのに必要な資源を確保する必要がある。

【００３５】ステップ501において、受信したRSVPパケ
ットから、送信ノード(101)のIPアドレス、受信ノード
(102)のIPアドレス、及び帯域幅を読みとる。

【００３６】ステップ502において、受信ノード(102)へ
パケットを中継する際に、パケット送出先となるネット
ワークインタフェース(201)の名前（ネットワークイン
タフェース名）をIPルーティング解決により決定する。

【００３７】ステップ503において、該当ストリームに
ストリームIDを一つ割り当て、かつ、RT送信要求キュー
を生成する。

【００３８】ステップ504において、帯域予約テーブル
(206)の各エントリを登録する。帯域予約テーブル(206)
の構成を図６に示す。帯域予約テーブルは、ストリーム
IDフィールド(601)、ストリームID(601)に対応するスト
リームの送信ノード(101)のIPアドレスを格納する送信I
Pアドレスフィールド(602)、ストリームID(601)に対応
するストリームの受信ノード(102)のIPアドレスを格納
する受信IPアドレスフィールド(603)、ストリームID(60
1)に対応するストリームの使用帯域幅を格納する帯域幅
フィールド(604)、ストリームID(601)に対応するストリ
ームのデータを中継する際に、送信要求をエンキューす
べきRT送信要求キュー(405)のアドレスを格納する送信
要求キューアドレスフィールド(605)、ストリームID(60
1)に対応するストリームデータを中継する際、データを
送出すべきネットワークインタフェース(201)の名前を
格納するネットワークインタフェース名フィールド(60
6)からなる。

【００３９】ステップ504では、 １）ステップ503で得られたストリームIDをストリームI
Dフィールド(601)に、 ２）ステップ501で得られた送信IPアドレスを送信IPア
ドレスフィールド(602)に、 ３）ステップ501で得られた受信IPアドレスを受信IPア
ドレスフィールド(603)に、 ４）ステップ501で得られた要求帯域幅にα（αは１よ
り大きい定数）をかけた値を帯域幅フィールド(604)
に、 ５）ステップ503で生成したRT送信要求キューのアドレ
スを送信要求キューアドレスフィールド(605)に、 ６）ステップ502で得られたネットワークインタフェー
ス名をネットワークインタフェース名フィールド(606)
に、格納している。

【００４０】ステップ505において、データ中継の際に
必要となる各種資源の予約処理や、RSVPパケットの送信
処理を行なう。この各種資源の予約処理においては、帯
域幅フィールド(604)に格納した帯域幅（すなわち、送
信ノード(101)が要求している帯域幅のα倍）のデータ
を中継するのに十分な資源を予約する。この処理は従来
のRSVPプロトコルと同様であるので詳細は省略する。

【００４１】このように、本発明のデータ中継方法で
は、送信ノード(101)が要求する帯域幅のα倍のデータ
を中継するのに十分な資源を各ルータノード(103)内に
確保する。上記に示した資源予約を行なうと、データの
転送遅延に伴なうデータ中継レートの低下を防止可能で
あることを図７を用いて示す。

【００４２】図７では、図３と同様に、送信ノード(10
1)が、送信タイミングt307においてパケット301から303
を、送信タイミングt308においてパケット304から306を
送信する。そしてこの例では、パケット303の伝送遅延
が、送信ノード(101)とルータノード１(103)を結ぶ伝送
路共有型ネットワーク(104)にて発生している。なお、
以降αは4/3であるとし、各ルータノード(103)には、４
パケット分のデータ中継を行なうのに十分な各種資源が
予約されていると仮定する。

【００４３】上記伝送遅延が発生しているため、図３の
場合と同様に、ルータノード１(103)にはt310とt311の
間に２パケットしか到達しない。そのため送信タイミン
グt311においては２パケットのみの送信を行なう。ま
た、t311とt312の間に４パケット到達する。しかし、ル
ータノード１(103)では、４パケット分のデータを中継
するのに十分な資源を確保し、かつ、パケットスケジュ
ーラ(205)も最大４パケットまで１周期につき送信する
（帯域予約テーブル(206)の帯域幅フィールド(604)がそ
のように設定されている）ため、t312において４パケッ
トの送信を行なう。この例でルータノード１は、t311の
送信タイミングにおいて２パケットしか送信を行なわ
ず、送信ノード(101)が要求するデータ中継レートを下
回っている。しかし、t312の送信タイミングにおいて４
パケットを送信しすぐその不足分を補っているため、受
信ノード(102)におけるデータ受信レートも、送信ノー
ド(101)の要求を充足することが可能となっている。

【００４４】次に、パケット受信時のネットワークイン
タフェースドライバ(202)のフローチャートを図８に示
す。ネットワークインタフェースドライバ(202)は、到
達したパケットをそのパケットタイプに応じ、IPプロト
コルスタック(203)もしくはRTIPプロトコルスタック(40
1)に、受信したパケットを通知する（NRT受信キュー(40
2)やRT受信キュー(403)に受信したパケットをエンキュ
ーする）役割を果たす。この際、NRT受信キュー(402)の
長さが一定値を超えないようにすることで、バッファ枯
渇によるパケット喪失を防いでいる。これが可能である
理由は後述する。

【００４５】ステップ801において、受信したパケット
のパケットタイプ（RTパケットかNRTパケットか）の判
定を行なっている。このパケットタイプの判定方法は、
多くのネットワークインタフェースドライバが用いてい
る方法と同様の方法をとるので、ここではその詳細を省
略する。そして、受信したパケットがRTパケットである
場合にはステップ802に、NRTパケットである場合にはス
テップ805にジャンプする。

【００４６】ステップ802にて、受信したパケットをRT
受信キュー(403)にエンキューしている。

【００４７】さらにステップ803にてRTIPプロトコルス
タック(401)を起動し、受信したパケットの中継処理を
行なわせる。

【００４８】さらにステップ804にて次にネットワーク
インタフェース(201)が受信するために必要なセットア
ップ処理を行ない、１回分の受信処理を完了する。この
処理も、多くのネットワークインタフェースドライバが
用いている方法と同様の方法をとるので、ここではその
詳細を省略する。

【００４９】ステップ805にて、現在NRT受信キュー(40
2)にキューイングされているパケット数を検査する。そ
してその数がある一定値（図ではＮで表している）より
小さい場合にはステップ806に、それ以外の場合にはス
テップ810にジャンプする。

【００５０】ステップ806にて、受信したパケットをNRT
受信キュー(402)にエンキューしている。

【００５１】さらにステップ807にてIPプロトコルスタ
ック(203)を起動し、受信したパケットの中継処理を行
なわせる。

【００５２】さらにステップ808にてステップ804と同様
の処理を行ない、１回分の受信処理を完了する。

【００５３】ステップ810にて、受信したパケットを格
納しているバッファを直ちに解放し、フリーバッファキ
ュー(207)にエンキューする。このように、NRT受信キュ
ー(402)の長さが一定値を超えた場合には、直ちにパケ
ットの破棄（バッファの解放）を行ない、IPプロトコル
スタック(203)にパケットを受け渡さない。

【００５４】IPプロトコルスタック(203)のフローチャ
ートを図９に示す。

【００５５】IPプロトコルスタック(203)はNRTパケット
の中継処理を行なった後、NRT送信要求キュー(404)に該
当パケットをエンキューする（パケットスケジューラ(2
05)に該当パケットの送信を要求する）。このとき、NRT
送信要求キュー(404)の長さが一定値を超えないように
することで、バッファ枯渇によるパケット喪失を防いで
いる。これが可能となる理由も後述する。

【００５６】ステップ901にてパケットの中継処理を行
ない、パケットの送出先となるネットワークインタフェ
ース名を決定する。この処理は通常のIPパケットの通常
処理と全く同様にできるのでここではその詳細を省略す
る。

【００５７】ステップ902にて、ステップ901にて決定し
たパケット送出先となるネットワークインタフェース(2
01)に対応するNRT送信要求キュー(404)のアドレスを求
める。この決定は、図10に示すネットワークインタフェ
ース名フィールド(1001)、NRT送信要求キューフィール
ド(1002)からなるテーブルより求める。このテーブルの
構築もオペレーティングシステムのブート時に容易に可
能であるので、構築方法の詳細はここでは省略する。

【００５８】ステップ903にて、ステップ902にて求めた
NRT送信要求キュー(404)にエンキューされているパケッ
ト数を検査する。パケット数が一定値（図ではＮで表し
ている）より小さい場合にはステップ904に、それ以外
の場合にはステップ906にジャンプする。

【００５９】ステップ904にてNRT送信要求キューへ中継
すべきパケットをエンキューし、１パケット分の中継処
理を完了する。

【００６０】ステップ906にて、中継すべきパケットを
格納しているバッファを直ちに解放し、フリーバッファ
キュー(207)にエンキューする。このように、NRT送信要
求キュー(404)の長さが一定値を超えた場合には、直ち
にパケットの破棄（バッファの解放）を行ない、パケッ
トスケジューラ(205)にパケットを受け渡さない。

【００６１】RTIPプロトコルスタック(401)のフローチ
ャートを図11に示す。RTIPプロトコルスタック(401)はR
Tパケットの中継処理を行なった後、NRT送信要求キュー
(405)に該当パケットをエンキューする（パケットスケ
ジューラ(205)に該当パケットの送信を要求する）。

【００６２】ステップ1101にてパケット中継処理を行な
い、パケット送出先となるネットワークインタフェース
名を決定する。この処理も通常のIPパケットの通常処理
と全く同様にできるのでここではその詳細を省略する。

【００６３】ステップ1102にて、ステップ1101にて決定
したパケット送出先となるネットワークインタフェース
(201)に対応するRT送信要求キュー(405)のアドレスを求
める。この決定は、帯域予約テーブル(206)のネットワ
ークインタフェース名フィールド(606)、送信要求キュ
ーアドレスフィールド(605)、送信ノードIPアドレスフ
ィールド(601)、受信ノードIPアドレスフィールド(602)
を参照することにより容易に実現できる。

【００６４】ステップ1103にて、ステップ1102で求めた
RT送信要求キューに中継すべきパケットをエンキューす
る。RT送信要求キューにエンキュー可能なパケット数の
上限は存在しない。

【００６５】パケットスケジューラ(205)、パケット送
信時のネットワークインタフェースドライバ(202)のフ
ローチャートは、特願平9-75018号出願（参照）と同様
に実現できるので、ここでは省略する。

【００６６】以上のようにルータノード(103)の各ソフ
トウェアモジュールを構成した際に、バッファの枯渇に
よるパケット喪失の発生を防止できることを示す。

【００６７】図４において、ルータノード内におけるバ
ッファは、 １）フリーバッファキュー(207)にエンキューされてい
る、 ２）ネットワークインタフェースドライバ(202)が、ネ
ットワークインタフェース(201)の受信のために提供し
ている、 ３）NRT受信キュー(402)にエンキューされている、 ４）RT受信キュー(403)にエンキューされている、 ５）IPプロトコルスタック(203)がバッファを参照しつ
つ中継処理を行なっている、 ６）RSVPプロトコルスタック(204)がバッファを参照し
つつ資源予約処理を行なっている、 ７）RTIPプロトコルスタック(401)がバッファを参照し
つつ中継処理を行なっている、 ８）NRT送信要求キュー(404)にエンキューされている、 ９）RT送信要求キュー(405)にエンキューされている、 10）パケットスケジューラ(205)がネットワークインタ
フェースドライバ(202)にバッファを渡そうとしてる、 11）ネットワークインタフェースドライバ(202)がパケ
ットを送信中である、のいずれかの状態にある。

【００６８】このうち、３），８）の状態にあるバッフ
ァは、ステップ805，903が存在することによりＮ以下で
ある。また、４），９）の状態にあるバッファは、周期
駆動するRTIPプロトコルスタックが１周期に中継するパ
ケット数（Ｎ'とする）以下である。５），６），
７），10），11）の状態にあるバッファは１以下であ
る。従って、2N + 2N' + 5 より大きい数のバッファを
ルータノード(103)内に準備しておくと、１）または
２）の状態にあるバッファ数が１以上であることを保証
可能となる。従って、このデータ中継方法においては、
バッファの枯渇によるパケット喪失の発生を防止でき
る。

【００６９】

【発明の効果】本発明によるデータ中継方法を用いる
と、複数のルータノードを介して接続された送信ノード
と受信ノードとの間で連続メディアデータを転送する際
に、伝送路を共有するネットワーク上での衝突の発生に
伴なう伝送遅延が発生しても、ルータノードにおけるデ
ータ中継レートが送信ノードの要求するデータ転送レー
トを下回らないことを保証可能となる。また、ルータノ
ードにおいて、バッファの枯渇に伴なう連続メディアデ
ータの喪失を回避することも可能となる。

【図面の簡単な説明】

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

【図２】RSVPによるデータ中継を行なうルータノードの
構成を示すブロック図。

【図３】RSVPによるデータ中継を行なう際のパケットの
流れを示す図。

【図４】本発明の実施の形態で仮定するルータノードの
構成を示すブロク図。

【図５】RSVPプロトコルスタックのフローチャート。

【図６】帯域予約テーブルの構成を示す図。

【図７】本発明のデータ中継を行なう際のパケットの流
れを示す図。

【図８】ネットワークインタフェースドライバのフロー
チャート。

【図９】IPプロトコルスタックのフローチャート。

【図１０】NRT送信要求キューのアドレスとネットワー
クインタフェース名を対応づけるテーブルの構成を示す
図。

【図１１】RTIPプロトコルスタックのフローチャート。

【符号の説明】

１０１…送信ノード、 １０２…受信ノード、
１０３…ルータノード、２０３…IPプロトコルスタッ
ク、２０４…RSVPプロトコルスタック、２０６…帯域予
約テーブル、 ４０１…RTIPプロトコルスタック、４０
２…NRT受信キュー、 ４０３…RT受信キュー、４０
４…NRT送信要求キュー、４０５…RT送信要求キュー。

Claims (2)

【特許請求の範囲】
1. 【請求項１】データを送信する情報処理装置がそのデー
   タ転送を開始する前に、データの転送レートを宣言し、
   かつデータ転送の際に必要となるハードウェア資源の確
   保を要求する制御メッセージをデータの受信を実行する
   情報処理装置に向かって送り出す、一つまたはそれ以上
   の情報中継装置を二つの情報処理群の間に直列に接続し
   てある情報処理装置群において、該制御メッセージを受
   信した情報中継装置が、データを送信する情報処理装置
   が要求するデータ転送量に１より大きな定数値を乗じた
   データ量を中継するのに十分な資源を確保するステップ
   と、情報中継装置内のソフトウェアモジュールが一定周
   期で周期駆動するステップと、該ソフトウェアモジュー
   ルが、高々データを送信する情報処理装置が要求するデ
   ータ転送レートに１より大きな定数値を乗じたデータ転
   送レートに相当するデータ量を送信するステップ、を有
   することを特徴とするデータ中継方法。
2. 【請求項２】請求項１の情報処理装置群において、情報
   中継処理装置に接続されたネットワークインタフェース
   を制御するモジュールが、該ネットワークインタフェー
   スを経由して到達したパケットのタイプを判別するステ
   ップと、該ネットワークインタフェースを制御するモジ
   ュールが、該パケットのタイプがデータ転送レートを厳
   密に遵守する必要のないタイプのパケットである場合、
   該パケットのデータ中継処理を行なうモジュールの処理
   待ちのパケット数を検索するステップと、該ネットワー
   クインタフェースを制御するモジュールが、該パケット
   数が一定の数以上であると判断した場合には、該パケッ
   トを直ちに破棄するステップと、該パケットのデータ中
   継処理を行なうモジュールが、ネットワークインタフェ
   ースを制御するモジュールによる送信処理を待ち合わせ
   ているパケット数を検索するステップと、該パケットの
   データ中継処理を行なうモジュールが、該パケット数が
   一定数以上である場合には、該パケットを直ちに破棄す
   るステップ、を有することを特徴とするデータ中継方
   法。