JPH1132078A - 送信キュー管理方式および本方式を用いるインタネットワーク装置 - Google Patents

Abstract

(57)【要約】 【課題】プロトコルに依存せずフロー制御を実現する簡
易送信キュー制御方式の実現。 【解決手段】複数のネットワークに相互に接続し、ある
ネットワークから別のネットワークへパケットを中継す
る装置において、プロトコルに関わらず受信パケットが
優先制御を必要とするかフロー制御を必要とするか特別
な処理を必要としないか判断する機能を持ち、判断結果
に基づきパケットを該当する送信キューへ分別する機能
を持ち、さらに、優先制御を要するパケットの送信キュ
ーからはパケットが一定以上の帯域を保って送信される
よう、またフロー制御を要するパケットの送信キューか
らはフロー毎に割り当てられた帯域値に従ってほぼ一定
間隔を保って送信されるよう制御する機能を持つ。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】複数のネットワーク間を接続
しパケットの相互通信を実現するスイッチ、ルータなど
のインタネットワーク装置に関わる発明である。

【０００２】

【従来の技術】はじめに「フロー」という言葉の説明を
する。ある特定の送信元端末のアプリケーションから別
のある特定の宛先端末のアプリケーションへ送信する一
連のパケット群のうち、通過する経路上に存在するネッ
トワーク間接続装置において一定の帯域を保証しながら
中継する必要があるパケットの単一方向の流れを指す。
また、ネットワーク間接続装置において、あるフローに
属するパケット群を特別に扱いこのパケット群に対して
帯域を保証する処理をフロー制御と呼ぶ。

【０００３】帯域保証のためのフロー制御技術には従来
からもあったが、いずれも交換機などの大規模な装置に
適用することを狙った技術であり、ルータ、スイッチと
いった小型装置に同じ技術を適用しようとすると装置全
体の規模に比べフロー制御を実現するための部分が大掛
かりになり過ぎるため適さない。

【０００４】

【発明が解決しようとする課題】本発明はネットワーク
間接続装置において、厳密なフロー制御は必要としてい
ないが最善努力型の大まかなフロー制御を必要としてい
る場合には対応する、比較的処理負荷が軽い優先制御お
よびフロー制御機能を実現することを目的とする。この
際、異なる複数のプロトコル、特にIPv４プロトコル（I
nternet Protocolversion４）とIPv６プロトコル（Inte
rnet Protocol vrsion６）両方を区別なく同様に取り扱
えることが課題である。

【０００５】

【課題を解決するための手段】受信したパケットを解析
し、優先制御を必要とするパケットか、フロー制御を必
要とするパケットか、特別な処理を必要としないパケッ
トかプロトコル種別に関わらず判断する手段を設ける。
さらに、その解析結果別にパケットを該当する送信キュ
ーに分別する手段を設け、分別された各送信キュー毎に
送信時間を管理して送信処理する手段を設ける。送信時
間の管理方法は、優先制御の場合とフロー制御の場合で
は異なり、優先制御の場合には対象となるパケットが一
定以上の帯域を保って送信されるよう、またフロー制御
の場合にはフロー毎に割り当てられた帯域値に従ってほ
ぼ一定間隔を保って送信されるよう制御する手段を設け
る。

【０００６】

【発明の実施の形態】本発明の一実施例として図１に示
す構成を持つネットワーク間接続装置の説明をする。本
発明の装置は、パケットをデータリンク層アドレスに基
づいて中継するスイッチである場合も考えられ、ネット
ワーク層アドレスに基づいて中継するルータである場合
も考えられ、また、その両者を組み合わせたネットワー
ク間接続装置である場合も考えられる。

【０００７】本実施例の説明では「フロー」という言葉
を使う。フローとは、ある特定の送信元端末のアプリケ
ーションから別のある特定の宛先端末のアプリケーショ
ンへ送信する一連のパケット群のうち、通過する経路上
に存在するネトワーク間接続装置において帯域を保証し
ながら中継する必要があるパケットの単一方向の流れを
指す。また、ネットワーク間接続装置においてあるフロ
ーに属するパケットの帯域を保証する処理をフロー制御
と呼ぶ。さらに、本実施例ではパケットの流れをフロー
と認識するようネットワーク間接続装置に設定すること
をフローを設定すると呼ぶことにする。なお、宛先端末
は単一の端末である場合もあり得るし、同一マルチキャ
ストグループに属する複数の端末である場合も考えられ
る。

【０００８】さらに、本実施例ではOSI(Open Systems I
nterconnection)参照モデルのネットワーク層プロトコ
ルに相当するものとしてIPv４(Internet Protocol vers
ion４)およびIPv６（Internet Protocol version６）を
利用するパケットの取り扱いを中心に説明する。ここ
で、IPv４とはIETF(Internet Engineering Task Force)
発行のRFC(Request For Comments)ドキュメントRFC791
で定義されるプロトコルである。またIPv６とはRFCドキ
ュメントRFC1883で定義される次世代IPプロトコルであ
り、IPv４の後継プロトコルである。本実施例ではIPv
４、IPv6両方のことをまとめてIPと表現する。なお、IP
v４およびIPv６以外のプロトコルを用いる場合について
も同様の機能を実現可能であるが、ここでは詳細は説明
しない。

【０００９】●本実施例の装置構造 本実施例の装置は、ネットワークに接続しパケットの送
受信と他のモジュールとの間のデータ転送を制御するモ
ジュール1−1，1−2，1−3，…1−ｉ（ｉは０でない整
数）、全てのモジュール1−1〜1−iを相互に接続しモジ
ュール間のデータ転送経路となるデータ転送手段２、か
ら構成される。

【００１０】受信側モジュール1−1は、ネットワークか
らパケツトを受信するネットワークインタフェース制御
部3−1（図中、インタフェースはＩ／Ｆと表記）、ネッ
トワークインタフェース制御部3−1から受信したパケッ
トを格納する受信キュー４、受信キュー４に格納した受
信パケットのヘッダ部を解析し受信パケットの転送先モ
ジュールを決定する解析処理部５、解析処理部５の解析
結果をまとめパケットのモジョール間転送に利用する転
送タグを生成する転送タグ生成部６、転送タグに従って
モジュール間のデータ転送を制御する転送制御部7−1、
から構成される。

【００１１】さらに、解析処理部５は受信したパケット
を解析するパケット解析部51、パケット解析時にフロー
識別情報を参照するためのフロー識別情報テーブル52か
ら構成される。

【００１２】送信側モジュール1−2は、他モジュールか
ら転送されたパケットの取り込みを制御する転送制御部
7−2、優先度制御やフロー制御を必要としない通常のパ
ケットを送信するための一般送信キュー８、優先度制御
を必要とするパケットを送信するための優先送信キュー
9−1，9−2，…9−ｊ（ｊは０でない整数）、フロー制
御を必要とするパケットを送信するためのフロー送信キ
ュー10−1，10−2，…10−ｋ（ｋは０でない整数）、転
送制御部7−2が取り込んだパケットを転送タグに従って
送信キュー８，9−1〜9−ｊ，10−1〜10−ｋへ振り分け
る振り分け制御部11、送信キュー８，9−1〜9−ｊ，10
−1〜10−ｋを管理制御する送信キュー管理部12、送信
キュー８，9−1〜9−ｊ，10−1〜10−ｋのパケットをネ
ットワークへ送信するネットワークインタフェース制御
部3−2、から構成される。

【００１３】さらに、送信キュー管理部12は、送信キュ
ー登録表121、一般送信キュー８の管理表122、優先送信
キュー9−1，9−2，…9−ｊの管理表123−1，123−2，
…123−ｊ、フロー送信キュー10−1，10−2，…10−ｋ
の管理表124−1，124−2，…124−ｋ、送信管理用のフ
リーランタイマ125から構成される。

【００１４】ここでは説明を簡略化するためにモジュー
ル1−1とモジュール1−2をデータ転送手段２により接続
し、モジュール1−1のネットワークインタフェース制御
部3−1がネットワークからパケットを受信し、そのパケ
ットをモジュール1−2のネットワークインタフェース制
御部3−2がネットワークへ送信する場合だけに差目して
説明を進める。しかし、次に示す各構成およびそれらの
組み合わせをとる場合も考えられる。

【００１５】・同一モジュールに送信用ネットワークイ
ンタアェース制御部と受信用ネットワークインタフェー
ス制御部の両方を持つ構成 ・１モジュールに送信用または受信用のネットワークイ
ンタフェース制御部を複数持つ構成 ・同一装置内にモジュールを３個以上接続する構成 ・受信したパケットを同一モジュール内の送信用ネット
ワークインタフェース制御部から送信する機能を持つ構
成 次に図１の装置においてモジュール1−1から受信したパ
ケットをモジュール1−2から送信するまでの処理全体を
説明する。

【００１６】●パケットの受信、解析 はじめにネットワークインタフェース制御部3−1を通じ
てネットワークから受信したパケットはヘッダ部から順
に受信キュー４に格納される。ネットワークインタフェ
ース制御部3−1は接続されているネットワークのデータ
リンク層種別に従ってパケットを受信し、受信キュー４
に格納する。パケットが受信キュー４に格納されたら、
解析処理部５のパケット解析部51が受信キュー４に格納
されたパケットを解析し始める。解析を始める契機は、
ネットワークから受信したパケットのうち少なくともヘ
ッダ部が受信キュー４に格納された時点とする場合もあ
り、またパケットが完全に受信キュー４に格納された後
とする場合もあり得る。ヘッダ解析の目的は次の２つで
ある。

【００１７】・転送先決定 ・受信パケットの取り扱い決定 このうち転送先決定とは、受信したパケットをどのモジ
ュールへ転送しどのネットワークインタフェース制御部
からネットワークへ送信すべきか決定する処理のことで
あり、このためのヘッダの解析内容はネットワーク間接
続装置の種類、ネットワーク層プロトコルの種類によっ
て異なる。本発明はパケットの転送先決定に関わるもの
ではないので詳細は述べないが、簡単に例を示してお
く。例えば、本実施例のネットワーク間接族装置がルー
タである場合には次のように処理する。ヘッダ解析の結
果ネットワーク層プロトコルが例えばIPv６(Internet P
rotocol version６）であったならば、パケットから宛
先IPv６アドレスを抽出しそれを元にあらかじめ登録済
みの経路表を検索してパケットの中継先モジュールおよ
びネットワークインタフェース制御部を決定する。パケ
ットを受信したネットワークと中継先のネットワークの
データリンク層種別が異なる場合にはパケットを送信す
る前にデータリンクヘッダを付け換える必要があり、デ
ータリンク種別が同じであってもデータリンクヘッダの
宛先データリンクアドレスなどを書きかえる必要を生じ
る場合もある。また、例えば本実施例の装置がスイッチ
である場合には、宛先データリンク層アドレスを抽出し
それを元にあらかじめ登録済みのデータリンクアドレス
表を検索してパケットの中継先モジュールおよびネット
ワークインタフェース制御部を決定する。

【００１８】２番目の受信パケットの取り扱い決定と
は、本実施例のネットワーク間接続装置が受信したパケ
ットに対して次の（ａ）〜（ｃ）３種のうちどの処理を
施す必要があるか判定する処理である。

【００１９】（ａ）あらかじめフロー設定情報を登録し
ていてフロー制御を要するパケット （ｂ）プロトコルの特性により優先制御を要するパケッ
ト （ｃ）特別な処理を必要としないパケット 受信したパケットが（ａ）〜（ｃ）のいずれに該当する
か判断する方法を説明する前に、まずIPを利用するセッ
ション層アプリケーション群のプロトコル特性を説明す
る。IPを利用するセッション層アプリケーション群を大
まかに分けると、送逹確認をするTCP(Transmission Con
trol Protocol)をトランスポート層に利用するものと送
逹確認をしないUDP(User Datagram Protocol)を利用す
るものがある。ネットワークが混雑していて途中経路で
パケットが廃棄される場合を考える。このような場合、
廃棄されたパケットがTCPを利用していたならば再送に
より廃棄されたデータを回復しようとし、UDPを利用し
ていたならば再送されずデータは失われる。TCPを利用
していた場合には混雑緩和のためにパケットが廃棄され
たにもかかわらず再びパケットが送信されるので、場合
によっては混雑がさらに激しくなる可能性もある。この
ため、TCPを利用したパケットは途中経路で可能な限り
廃棄しないよう処理することが要求される。さらにTCP
パケットの中でも、データをまとめて送信するFTP(File
Transfer Protocol)などのパケットは個々のパケット
の遅延時間は問題にならないが全体としての単位時間あ
たりのデータ転送量(スループット)が大きいことが要求
され、また人間が対話的に操作するアプリケーションで
あるtelnet(仮想端末)などのパケットには人間の作業を
妨げない程度に応答時間(レイテンシ)が早いことが要求
される。また、画像や音声を送るパケットの場合には定
期的にパケットを送信する必要があり、このようなパケ
ットの場合TCP/UDPに関わらず一定の帯域を確保するた
めにフローを設定して通信する場合が多い。

【００２０】次に、受信したパケットが登録済みのフロ
ーに該当するパケットか識別するための情報について述
べる。本実施例ではフロー制御を必要としているパケッ
トのフローを識別するための情報は本実施例のネットワ
ーク間接続装置全体で一元管理し、それぞれのフローの
フロー識別情報エントリには装置全体で一意に定まるフ
ロー識別番号が割り当てられているものとする。また、
それぞれのモジュールは一元管理されたフロー識別情報
またはその複写物をフロー識別情報テーブル52を用いて
参照でき、また何らかの手段で更新できフロー識別情報
テーブル52に反映できるものとする。フロー識別情報テ
ーブル52の各エントリは次の各項目から構成される。

【００２１】・フローの識別番号 ・フロー識別方法（ポート番号利用／フローラベル利
用） ・ポート番号を利用してフローを識別する場合 ネットワーク層プロトコル種別（IPv４／IPv６) 宛先装置の端末IPアドレス トランスポート層プロトコル種を表す値 宛先装置のアプリケーションに対応するポート番号 ・フローラベルを利用してフローを識別する場合 送り元装置の端末IPv６アドレス フローラベル値 フローの識別方法はこの後(ａ−1)，(ａ−2)に述べるよ
うにアプリケーションに対応するポート番号を利用する
ものとフローラベルを利用するものがあるため、フロー
識別方法の違いによりフロー識別情報の各エントリに登
録される内容が異なる。詳しくはこの後説明する。本実
施例では既にフロー識別情報テーブル52にはフロー識別
のための情報が登録済みであるものと仮定して説明を進
める。

【００２２】次に受信したパケットが（ａ）〜（ｃ）い
ずれに該当するか判断する方法を受信したパケットのネ
ットワーク層プロトコルがIPv４、IPv６それぞれの場合
について説明する。

【００２３】（ａ−1）フロー制御を必要とするIPv４パ
ケットの判定方法 IPv４パケット内には後述のフローラベルのようなフロ
ー制御に関する明示的な指示は含まれていないので、パ
ケットに含まれている情報から判断する必要がある。は
じめに述べたように、フローはある特定の端末アプリケ
ーションから別のある特定の端末アプリケーションへの
単一方向のパケットの流れに対して設定する。よってフ
ローを識別するためには宛先装置の端末IPv４アドレス
とアプリケーションを特定するためのトランスポート層
プロトコル種、アプリケーションが利用するポート番号
を使う。IPv４ヘッダにはトランスポート層プロトコル
に何を使ってするか指定する“プロトコル”フィールド
がある。トランスポート層プロトコルとしてTCPを利用
しているならばこの値が６となり、UDPを利用している
ならば17となる。さらに、TCPおよびUDPヘッダには宛先
装置の“ポート番号”フィールドがあり、セッション層
アプリケーションに対応するポート番号が設定される。
受信パケットのIPv４ヘッダの宛先IPv４アドレス、トラ
ンスポート層プロトコル、TCP／UDPヘッダの宛先ポート
番号を調べ、フロー識別情報テーブル52に登録済みの各
項目と比較し一致したものがあればフローが設定されて
いてフロー制御を必要としているパケットであると判断
でき、そのフロー識別番号も分かる。

【００２４】（ａ−2）フロー制御を必要とするIPv６パ
ケットの判定方法 IPv６は基本的にはIPv４を拡張したプロトコルであるた
め、（ａ−1）の説明と同様の方法でフロー制御を必要
とするパケットか判定できる。この場合、トランスポー
ト層プロトコル番号およびポート番号は（ａ−1）で使
用していた番号を基本的にそのまま利用できる。

【００２５】しかし、IPv６の新たな機能の一つとし
て、IPv６ヘッダには通信の途中経路でフロー制御をす
るために“フローラベル”フィールドが定義されてい
る。フロー制御を必要としているパケットではフローラ
ベルフィールドの値は１〜16777215の範囲の値を持ち、
フロー制御を必要としていないパケットでは０になって
いる。送り元IPv６アドレスとフローラベルを組み合わ
せるとフローを一意に識別できるが、フローラベルは宛
先IPv６アドレスと対になるわけではない。しかしRFC18
83によれば同じフローに属するパケットは送り元IPv６
アドレス、宛先IPv６アドレス、優先度フィールド（後
述）の値、フローラベル、経路上のネットワーク機器で
処理すべき各種オプションヘッダ（ルーティングオプシ
ョンヘッダやホップバイホップオプションヘッダなど）
がすべて同じ値になっていなければならないことから、
送り元IPv６アドレス、フローラベル値が一意に定まれ
ば宛先IPv６アドレスも一意に定まり、本実施例のフロ
ー識別方法と矛盾は無い。よって受信パケットの送り元
IPv６アドレスとフローラベル、宛先IPv６アドレスの組
み合わせがフロー識別情報テーブル52に登録済みの各項
目と一致したものがあればフローが設定されていてフロ
ー制御を必要としているパケットであると判断できる。
なお、フローラベルの値が設定されているパケットであ
ってもフロー設定情報がフロー識別情報テーブル52に未
登録であればここではフロー制御を必要とするパケット
とは認めないこととする。

【００２６】このようにネットワーク層プロトコルがIP
v６のパケットの場合には、（ａ−１）と同じ方法か、
またはフローラベル値を用いる方法どちらか、または両
方を利用してフロー制御を必要とするパケットを判定で
き、またそのフロー識別番号も分かる。

【００２７】（ｂ−１）優先制御を必要とするIPv４パ
ケットの判定方法 IPv４パケット内には優先度の取り扱いに関する明示的
な指示は記録されていないので、上位プロトコルの情報
から判断する必要がある。IPv４ヘッダにはトランスポ
ート層プロトコルに何を使っているか指定する“プロト
コル”フィールドがあり、トランスポート層プロトコル
として優先制御を必要とするTCPを利用している場合に
はこの値が６となる。さらに、TCPヘッダには送り元装
置または宛先装置の“ポート番号”フィールドがあり、
送り元または宛先のポート番号フィールドにセッション
層アプリケーションに対応する“良く知られたポート番
号”が設定される。本実施例では優先制御を必要とする
パケットをスループットが要求されるアプリケーショ
ン、レイテンシが要求されるアプリケーションの２種に
分けて扱う。良く知られたポート番号はRFC1700に定義
されており、例えば次に示すものがある。

【００２８】 スループットが要求されるアプリケーション ftp(File Transfer Protocol、データ転送用) 20 レイテンシが要求されるアプリケーション ftp(File Transfer Protocol、制御用) 21 telbet 23 http(Hyper Text Transfer Protocol) 80 ポート番号を調べるとセッション層アプリケーションが
何であるかわかるので、前述のように受信パケットの取
り扱い方法を決定できる。以上に示したようにIPv４ヘ
ッダのプロトコルフィールド値とTCPヘッダのポート番
号値を併用して、優先制御を必要とするパケットか、ま
た優先制御を必要とするならばスループットが重視され
るのかレイテンシが重視されるのか、判断することがで
きる。

【００２９】（ｂ−2）優先制御を必要とするIPv６パケ
ットの判定方法 （ａ−2）にも述べたようにIPv６は基本的にはIPv４を
拡張したプロトコルであるため、（ｂ−1）の説明と同
じ方法で優先制御を必要とするかどうか判定できる。こ
の場合、上位プロトコル番号（TCPを利用している場合
には６）およびポート番号はIPv４が使用していた番号
をほぼそのまま利用できるが、IPv４のアプリケーショ
ンとは異なるIPv６独自のアプリケーションについては
ポート番号の定義を追加する。

【００３０】しかし、IPv６の新たな機能の一つとし
て、IPv６ヘッダには通信の途中経路で優先制御をする
ために“優先度”フィールドが定義されている。優先度
フィールドは０〜15の範囲の値を持ちIPv６の上位プロ
トコルの性格によりパケットの中継を優先する度合を表
している。IPv６を定義しているRFC1883ではそれぞれの
値に意味を持たせているが、ここでは次のように大まか
に分類する例を示す。

【００３１】 ０〜２：遅延時間が問題にならない電子メールなどのパ
ケット ３〜５：ファイル転送などのスループットが要求される
パケット ６〜７：telnetなど対話型のレイテンシが要求されるパ
ケット ８〜15：ほぼ一定間隔で送られる画像、音声などの等時
性データパケット 通信する端末のセッション層アプリケーションに優先度
フィールドの値を適切に設定させれば、この値を利用す
ることで上位プロトコルの情報を参照しなくても優先制
御を必要とするか、またスループット／レイテンシどち
らかを重視するか判定できる。本実施例ではこのうち優
先度制御を必要とするパケットは優先度値３〜５、優先
度値６〜７のパケットと定義する。上位アプリケーショ
ンと優先度フィールド値の対応付けは上記分類例に従え
ば次のようになる。

【００３２】 優先度値３〜５：ftp（データ転送用ポート）など 優先度値６〜７：ftp（制御用ポート），telnet，http
など このようにネットワーク層プロトコルがIPv６のパケッ
トの場合には、(ｂ−１）と同じ方法か、または優先度
フィールドを用いる方法どちらか、または両方を利用し
て優先制御を必要とするパケットを判定できる。

【００３３】（ｃ）特別な処理を必要としないパケット
の判定方法 これまでの（ａ−１），（ａ−2），（ｂ−1），（ｂ−
2）の説明で優先処理またはフロー制御が必要と判断さ
れなかったパケットは全て特別な処理を必要としないパ
ケットと判断できる。

【００３４】以上（ａ）〜（ｃ）の判定結果により、本
実施例ではパケットをIPv４／IPv６の区別をせず次の４
種に分類する。

【００３５】・フローが設定されており、フロー制御を
必要とするパケット ・優先制御を必要とするパケットのうちスループットが
要求されるパケット ・優先制御を必要とするパケットのうちレイテンシが要
求されるパケット ・上記以外の特別な処理を必要としないパケット 解析処理部５はこの分類結果を転送タグ生成部６へ渡
す。なお、図２に（ａ）〜（ｃ）の判定処理手順をフロ
ーチャートを使って示す。図中、手順200は上記説明中
の（ａ−1），(ａ−2）であり、手順201は上記説明中の
（b−1）,（b−2）である。受信したパケットが優先度
処理の対象となるうえフローが設定されていてフロー制
御の対象にもなる場合には、暗黙のうちに設定される優
先度制御より明示的に意図して設定されるフロー制御を
優先して実施する。このため図２に示すようにフロー制
御の要否を優先制御の要否より先に調べる。

【００３６】●フローの設定／削除方法 これまでの説明はフローを識別するための設定情報はフ
ロー識別情報テーブル52にあらかじめ登録しておくもの
として登録方法には触れずに進めてきた。ここでフロー
の設定情報を登録／削除する方法を述べる。まず設定情
報を登録する方法であるが、次のように３種類考えられ
る。

【００３７】・手動登録する方法 あるフローに対してフロー制御を利用した通信を行う前
に、あらかじめフローを設定する必要がある宛先装置の
端末IPアドレスとトランスポート層プロトコル種、ポー
ト番号を手動で登録する。設定時に同時に各フローに割
り当てる帯域も設定する必要がある。

【００３８】・RSVP(Resource Ser Vstion Protocol)を
利用して自動登録する方法 IETFにおいて標準化作業中の帯域予約プロトコルである
RSVPの制御パケットを利用して自動的に設定する。RSVP
のドラフト第14版draft-ietf-rsvp-spec-14によれば、
帯域予約の手順は次のようになる。すなわち、フローを
設定したい経路の宛先装置側からフローの送り元装置へ
向けてフロー設定要求パケット(Resvメッセージ)を送信
し、フローの途中経路にあるネットワーク機器はこのパ
ケットを監視して自動的にフローを設定し帯域を予約す
る。よってフローの途中経路にあるネットワーク機器は
帯域の予約と関連付けて同時にフローの設定情報を登録
すれば良い。RSVPではフローは宛先IPアドレス、トラン
スポート層プロトコル種、ポート番号によって定義され
るので、本実施例のフロー識別方法と矛盾無く協調動作
できる。

【００３９】・本実施例のネットワーク間接続装置が取
り扱うパケットを監視して自動登録する方法 本実施例のネットワーク間接続装置が通過させるパケッ
トの内容を監視して、フローとしては未登録であるが登
録して処理した方が良いパケットを判別して自動登録す
る。監視する項目としては（１）宛先IPアドレス、トラ
ンスポート層プロトコル種、ポート番号の組み合わせ、
（２）IPv６パケットの場合には送り元IPアドレス、フ
ローラベル値の組み合わせが考えられる。が、これらは
いずれも解析処理部５でフロー制御を必要とするパケッ
トの判別に使っている項目であるため大幅な機能追加な
しに実現可能である。両者について個別に説明する。ま
ず、（１）の組み合わせの場合には、例えば音声や画像
を実時間で取り扱うアプリケーションのように、フロー
制御が必要となるアプリケーションのトランスポートプ
ロトコルおよび“良く知られたポート番号”をあらかじ
め登録しておく必要がある。受信したパケットの宛先ま
たは送り元のトランスポートプロトコルおよび“良く知
られたポート番号”があらかじめ登録してある値に一致
し、しかもフロー識別情報テーブル52にフローを識別す
るための設定情報が未登録であったならば、このパケッ
トはフローを設定してフロー制御すべきパケットと判断
できる。この方法はIPv４，IPv６両方に共通して使え
る。次に（２）の組み合わせの場合には、IPv６特有の
フローラベルを利用する方法である。バケットの送り元
装置がフロー制御を必要としているパケットを送信する
場合、送り元装置はIPv６パケットヘッダのフローラベ
ル値を０以外の値に設定する。すなわち、フローラベル
値が０で無いにも関わらずフロー識別情報テーブル52に
フローを識別するための設定情報が未登録であったなら
ば、このパケットはフローを設定してフロー制御すべき
パケットと判断できる。（１），（２）両者ともフロー
を識別するための情報を自動設定することはできるがそ
れぞれのフローに割り当てる帯域値は分からないので、
例えばセッション層アプリケーション毎すなわちポート
番号毎にあらかじめ割り当てる帯域値を決めておき、フ
ロー設定時にこの値に基づき帯域値を割り当てるなどの
方法により帯域の自動設定も実現できる。

【００４０】次に、上記３種のいずれかの方法で設定さ
れたフロー識別情報を削除する方法は同様に次の３種類
考えられる。

【００４１】・手動削除する方法 削除対象となるフローの識別情報および予約された帯域
の設定情報を手動で削除する。

【００４２】・RSVPを利用して自動削除する方法 RSVPの帯域予約の状態に連動させてフロー識別情報を削
除する方法である。RSVPでは、フロー毎の予約帯域を次
の２種のいずれかの方法で解除する。（１）予約した帯
域の設定を削除するメッセージ(Resv Tearメッセージ)
やフローの途中経路にあるネットワーク機器の情報を削
除するメッセージ(Path Tearメッセージ)を監視してこ
のパケットを受信したらフローの設定情報を削除する。
（２）フローの途中経路にあるネットワーク機器の情報
を定期的に更新するメッセージ(Pathメッセージ)を監視
し更新期限までに次のメッセージが来なかった場合にフ
ローの設定情報を削除する。よって、本実施例のネット
ワーク間接続装置ではRSVPが予約していた帯域を解除し
たことを検出して、またはRSVPと同様に（１），（２）
のパケットを監視してフロー識別情報を削除する。PSVP
と同様に（１），（２）のパケットを監視する場合、フ
ロー識別情報エントリにはこれまでに述べた項目以外に
監視のためのエージングタイマを持つ必要がある。

【００４３】・フローに属するパケットを監視して自動
削除する方法 設定したフローに属しているパケットを監視して、一定
時間以上通信が行われなかった設定情報を削除する。

【００４４】●受信側モジュールから送信側モジュール
へのパケット転送 ここまでの処理により、転送先モジュール、受信パケッ
トの取り扱いは決定した。次はモジュール間でパケット
を転送するために転送タグを生成する。転送タグ生成部
６は解析処理部５における解析結果を受けて転送タグを
生成する。転送タグの書式例を図３に示す。転送タグ
は、受信側モジュール1−1が受信したパケットを次のネ
ットワークへ送出する送信側モジュール1−2へ転送する
ための宛先を示す以外に、送信側モジュールで転送する
パケットをどのように取り扱う必要があるか示す目的が
ある。このため転送タグに入れなければならない情報
は、転送先モジュール番号、受信パケットの取り扱い方
法を示すフラグ、利用する優先送信キューの番号（優先
制御が必要な場合にのみ有効）、フローの識別番号（フ
ロー制御が必要な場合にのみ有効）である。図４に転送
タグに入れる転送先モジュール番号の書式例を示す。転
送先モジュール番号はパケットによっては複数のモジュ
ールへ同時に転送する必要があるため、図４に示すよう
にそれぞれのビットが転送先モジュールに対応するビッ
ト列を使って指定する。例えば、転送先モジュール1−2
と転送先モジュール1−5に対応するビットが“１”に設
定されその他がすべて“０”に設定されている場合に
は、パケットはモジュール1−2と1−5に同報転送され
る。本実施例では送信側モジュール1−2へ転送するた
め、モジュール1−2に対応するビットだけ“１”に設定
する。また、受信パケットの取り扱い方法を示すフラグ
には次の２種を持つ。

【００４５】・フロー制御フラグ：フロー制御を要する
パケットであることを表すフラグ ・優先制御フラグ：優先制御を要するパケットであるこ
とを表すフラグ 解析処理部５の処理結果のパケットの取り扱いに対応す
るフラグのみ“１”に設定する。本実施例の場合、優先
制御を要する時には優先送信キューの番号として、スル
ープット保証を要するパケットの場合には“１”、レイ
テンシ保証を要するパケットの場合には“２”を設定す
る。フロー制御や優先制御を必要としない場合にはいず
れのビットも“１”に設定せず全て“０”と設定する。
転送タグにはこれ以外にもフラグや付加情報を追加する
ことも可能である。例えば、パケットが使っているネッ
トワーク層プロトコルがIPv４であるかIPv６であるかそ
れ以外であるか示すフラグや、送信元／宛先装置のネッ
トワーク層アドレスを追加することで、転送先モジュー
ルの処理を容易にできる場合もあり得る。また、データ
転送手段２の構造によっては転送元モジュール番号を必
要とする場合もあり得る。なお、本実施例では優先制御
を要するパケットを２種類に分類して説明するが、優先
制御を要するパケットをすべて１まとめにして扱う場合
も考えられ、また、さらに多くの種類に細分化して扱う
場合も考えられる。その場合には転送タグの優先送信キ
ューの番号としてとり得る値の範囲が増減する。

【００４６】その後、転送制御部7−1は転送タグ生成部
６が生成した転送タグを受け取り、解析処理部５で決定
した転送先の送信側モジュール1−2へ向けてまず転送タ
グを、続いて受信キュー４に格納されているパケット本
体を連続してデータ転送手段２へ送り出す。転送タグに
宛先モジュールと指定されたモジュールはデータ転送手
段２に送り出された転送タグとパケット本体を取り込む
が、この時の処理を次に説明する。

【００４７】●送信キューへの振り分け 各モジュール1−ｉの転送制御部7−ｉはデータ転送手段
２に送り出される転送タグを監視し、自モジュールが宛
先モジュールに指定されていれば転送タグとパケットの
取り込みを開始する。ここでは宛先モジュールとして送
信側モジュール1−2が指定された場合を考える。転送制
御手段7−2は自モジュールが宛先モジュールに指定され
ているならば、まずはじめに転送タグを取り込んで振り
分け制御部11で転送タグの内容を解析する。転送タグに
は図３に示したようにパケットを前述の（ａ）〜（ｃ）
の判定結果４種のうちどれに従って取り扱えば良いかフ
ラグ化して記録してあるので、フラグの状態に従って転
送タグに続いて取り込むパケットをそれぞれ次のように
対応する送信キューへ振り分け、登録する。

【００４８】・フロー制御を要するパケットは、個々の
フローに対応するフロー送信キュー10−1，10−2，…10
−ｋへ登録 ・優先制御を要するパケットのうちスループットが要求
されるパケットは、優先送信キュー9−1へ登録 ・上記以外の特別な処理を必要としないパケトは、一般
送信キュー８へ登録 フローは個別に帯域を予約し個々の予約されている帯域
幅が異なるため、フロー送信キューはフロー毎に個別に
持つ必要がある。

【００４９】次に、送信キューの管理方法の例を述べ
る。まず、図５にフロー送信キュー10−1〜10−ｋとそ
の管理表124−1〜124−kの構造例を示す。一般送信キュ
ー、優先送信キュー、フロー送信キューいずれも基本的
には管理方法は同じである。フロー送信キューを例にし
て説明する。送信キューはパケット本体を格納するメモ
リ領域、このメモリ領域へのポインタを登録する送信キ
ュー本体、キューを管理する管理表から構成される。管
理表が持っている情報は、キュー管理のポインタ、送信
タイマー管理用の情報（後述）、フロー識別番号であ
る。キュー管理のポインタとは、実際に該当する送信キ
ューに対してパケットの格納／読み出しをするために必
要なキューを構成するメモリ領域のアドレス情報であ
り、メモリ領域の先頭アドレス、１エントリのデータ
長、キューの最大エントリ数、読み出しポインタ、書き
込みポインタなどのことを指す。送信タイマー管理用の
情報は一般送信キューの管理表にはなく、優先送信キュ
ーとフロー送信キューの管理表だけが持つ。また、フロ
ー識別番号はフロー送信キューの管理表だけが持つ。他
のモジュールから転送されてきたパケットを適切な送信
キューに振り分けるまでの処理を説明する。はじめに他
モジュールから転送された転送タグを取り込み、振り分
け制御部11へ渡す。振り分け制御部11で転送タグのフラ
グを調べる処理と平行して、空いているメモリ領域を確
保して転送されたパケットを格納する。メモリの実際の
管理方法は装置によって異なることが考えられるが、ど
のような方法で管理していても構わない。例えば、メモ
リ領域の長さが固定長か可変長か、１パケットを格納す
るメモリ領域が１個か複数か、などの方式の違いが考え
られる。振り分け制御部11で転送タグのフラグからどの
送信キューに格納するか判断すると、該当する送信キュ
ーの管理表から現在の書き込みポインタを得る。本実施
例では、転送タグの優先送信フラグが“１”に設定され
ていれば転送タグの優先送信キューの番号に対応する優
先送信キュー9−1〜9−ｊを、フロー送信フラグが
“１”に設定されていれば転送タグのフロー識別番号に
対応するフロー送信キュー10−１〜10−ｋを、いずれの
フラグも“１”に設定されていなければ一般送信キュー
を利用する。該当する送信キューの書き込みポインタの
値を得たらパケットを格納したメモリ領域の先頭アドレ
スをキューの現在の書き込みポインタの位置に書き込
み、書き込みポインタの値を更新する。

【００５０】一般送信キューと優先送信キューは本実施
例のネットワーク間接続装置が動作を開始する時点から
固定的に設定するが、フロー送信キューは本実施例のネ
ットワーク間接続装置が動作を開始した時点では存在し
ない。一般送信キューと優先送信キューを利用するパケ
ットはいつ到着するか分からないので常に送信キューを
用意しておかねばならない。これに対して、フローキュ
ーを利用するパケットはフローを設定してから削除する
までの期間にのみ到着しそれ以外の期間には到着しない
ことが分かっているため、フローの設定と共に対応する
フロー送信キューとその管理表を作り、フローの削除と
共に対応するフロー送信キューとその管理表を削除する
ことができ、キュー管理処理に費やす処理負荷を低減で
きる。

【００５１】●送信制御 各送信キューからパケットを送信する制御は、各キュー
の内容を調べてパケットが登録されていれば送信すると
いう方法を取る。一般送信キュー８から送信する場合に
はタイマ管理などは一切行わない。優先送信キュー9−1
〜9−ｊおよびフロー送信キュー10−１〜10−ｋから送
信する場合にはタイマの値を利用する。タイマを利用し
た送信制御について述べる。

【００５２】優先送信キュー9−ｘ（1≦ｘ≦ｊ；ｘは整
数）の場合、定期的に一定の時間を割り当てその期間中
は連続してパケットを送信する。定期的に時間を割り当
てる方法は、例えば次の２方式が考えられる。１番目の
方法は、優先送信キュー9−ｘに対応する送信キュー管
理表123−ｘに次に送信処理を実行予定時刻のタイマ値
をタイマ値Ａとして登録しておき優先送信キュー9−ｘ
以外の優先送信キュー／一般送信キュー／フロー送信キ
ューを１つ処理する毎に優先送信キュー9−ｘに対応す
る送信キュー管理表123−ｘのタイマ値Ａとフリーラン
タイマ125の値を比較し、フリーランタイマ125の値がタ
イマ値Ａの値に達したら優先送信キューの処理を開始す
る。２番目の方法は、別に用意するタイマに優先送信キ
ュー9−ｘの処理時間間隔を設定しておき、時間が来た
らタイマから割り込みを発生させて優先送信キュー処理
を実行する方法である。優先送信キュー9−ｘの送信処
理は次のような手順で実施できる。優先送信キュー9−
ｘの送信処理を開始するとき最初に現在のフリーランタ
イマ125の値を送信キュー管理表123-xのタイマ値Ｂに登
録する。その後キューにパケットが登録されていれば１
パケット送信し、例えば優先送信キュー9−ｘの処理時
間として一定時間ｍを与えたとすると送信キュー管理表
123−ｘに登録したタイマ値Ｂにｍを加えた値が現在の
フリーランタイマ125の値より小さければさらにもう１
パケット送信する。このようにして送信キュー管理表12
3−ｘに登録したタイマ値にｍを加えた値が現在のフリ
ーランタイマ125の値より大きくなるまで送信し続け
る。送信を終了するときには上記のように管理表123−
ｘのタイマ値Ａの値を更新する。定期的に割り当てる時
間間隔を短くし、かつ処理時間ｍを短く設定すれば、デ
ータ量は少ないが個々のパケットに対して早い応答速度
を必要とするパケットの扱いに適した処理を実行でき
る。これに対して、定期的に割り当てる時間間隔を比較
的長くし、かつ処理時間ｍも長く設定すれば、個々のパ
ケットに対する応答速度はあまり重要視されないがデー
タ量が多く高いスループットを必要とするパケットの扱
いに適した処理を実行できる。このような処理により、
混雑時にもある程度優先してパケットを送信できる。

【００５３】フロー送信キュー10−ｙ（１≦ｙ≦ｋ；ｙ
は整数）の場合、まず各フロー毎に割り当てられた帯域
および推定の平均パケット長から平均的なパケットの送
信時間間隔ｎを決める。同一フローに属するパケットは
ほぼ同じ性質のデータを扱っていると仮定でき、パケッ
ト長が大幅に変動することはないと考えられる。フロー
送信キューのパケットを送信し終わる毎に次の２つの値
を管理表にタイマ値Ａ、タイマ値Ｂとして登録しておく
ものとする。

【００５４】・タイマ値Ａ：現在のフリーランタイマ12
5の値に例えばｎの０.８倍を加えた値 ・タイマ値Ｂ：現在のフリーランタイマ125の値に例え
ばｎの１.２倍を加えた値 次にこのフロー送信キューのパケットを送信する前に現
在のフリーランタイマ125の値を調べ、前回送信時に管
理表に登録したタイマ値Ａからタイマ値Ｂまでの範囲に
入っていれば１パケットを送信し、タイマ値Ａ，Ｂを更
新する。フローを設定して最初に扱うパケットの場合に
は無条件で送信する。また、仮に現在のフリーランタイ
マ値125が前回送信時に管理表に登録したタイマ値Ｂを
越える場合、輻輳が発生しているものとしてパケットを
廃棄する。これを繰り返すことでフロー送信キューに登
録されたパケットをほぼ一定間隔で送信することが可能
となる。また、個別のフロー送信キュー10−ｙに対応す
る管理テーブル124−ｙに登録されたタイマ値Ａとタイ
マ値Ｂをすべてフリーランタイマ125と比較する処理を
ハードウェアに処理させることにより処理負荷を軽減す
ることが可能である。一般的にCAM(Content Addressabl
e Memory)と呼ばれている半導体素子があり、登録され
ている複数のデータとある１個の値とを比較し、一致し
たデータが登録されているアドレスを出力する機能を持
つ。このCAMの機能を一致検出ではなくある範囲に入っ
ていることを検出する機能に拡張し、タイマ値ＡとＢを
登録しておきフリーランタイマ125の値と比較する構成
をとれば実現可能である。

【００５５】以上のようにそれぞれの送信キューから送
信処理をされたパケットはネットワークインタフェース
制御部3−2を経てネットワークへ送信される。

【００５６】●異なる構成の場合 本実施例では、ネットワークから受信したパケットの取
り扱いを決定するためのヘッダ解析を受信側モジュール
1−1の解析処理部５で処理するように説明した。しか
し、受信パケットの取り扱い決定のための解決結果はパ
ケットの転送には無関係であるため、この解析はパケッ
トを送信側モジュール1−2へ転送しそれぞれの送信キュ
ーへ振り分ける直前に実施する構成をとる別の実施例も
考えられる。この場合、これまでに説明した実施例にお
ける送信側モジュール1−2の振り分け制御部11にパケッ
トの取り扱い決定のためのヘッダ解析機能を持つ。受信
側モジュール1−1から転送されてきたパケットをモジュ
ールに取り込むと同時に振り分け制御部11においてパケ
ットのヘッダを解析し優先送信キュー／フロー送信キュ
ー／一般送信キューのいずれを使うか決定してパケトを
該当する送信キューへ登録する。パケットの解析処理と
解析結果によりパケットを対応する送信キューへ振り分
ける処理を同一モジュールで実施するため、モジュール
間転送時の転送タグには解析結果フラグを入れる必要が
なく転送タグは転送先モジュール番号だけがあれば良
い。

【００５７】また本実施例では。あるモジュールがネッ
トワークから受信したパケットを別のモジュールに転送
し、そのモジュールから別のネットワークへ送信する場
合を説明した。しかし、単一モジュールに複数のネット
ワークを接続しているモジュールの場合、そのモジュー
ルのあるネットワークから受信したパケットを同一モジ
ュールの別のネットワークへ送信することもあり得る。
このように受信したパケットをモジュール内で折り返し
て送信する場合、このモジュールがこれまでに説明した
受信側モジュール1−1の機能と送信側モジュール1−2の
機能を兼ね備えている必要がある。解析処理部５の解析
の結果モジュール間転送が不要であることが分かった
ら、解析処理部５は同一モジュール内の振り分け制御部
11に直接解析結果を伝えパケットをそれぞれ送信キュー
へ振り分ける。解析処理部５から振り分け処理部11へ解
析結果を伝える手段は、転送タグを用いても良いし転送
タグを生成する元となる情報を直接伝えても構わない。
折り返し処理をする場合にはパケットをモジュール間で
転送するわけではないので転送タグは必ずしも必要では
ないが、パケットをモジュール間で転送する場合との処
理手順を共通化するために転送タグを利用しても構わな
い。

【００５８】

【発明の効果】本発明の方式によりネットワークから受
信したパケットを解析してそのパケットが優先制御を要
するか、フロー制御を要するか、特別な処理を要さない
か判別し、判別結果に従ってプロトコルに関わらずパケ
ットの取り扱い別に送信キューにパケットを分別し、優
先制御を要するパケットの送信キューからはパケットが
一定以上の帯域を保って送信されるよう、またフロー制
御を要するパケットの送信キューからはフロー毎に割り
当てられた帯域値に従ってほぼ一定間隔を保って送信さ
れるよう制御することで、異なる複数のプロトコル、特
にIPv４プロトコル（Internet Protocol version４）と
IPv６プロトコル(Internet Protocol version６）両方
を区別なく同様に取り扱え比較的処理負荷が軽い優先制
御およびフロー制御機能を実現できる。

【図面の簡単な説明】

【図１】本発明の装置の内部構成例。

【図２】受信パケットの取り扱い判定処理手順を表すフ
ローチャート。

【図３】転送タグの書式例。

【図４】転送先モジュール番号の書式例。

【図５】フロー送信キューとその管理表の構造例。

【符号の説明】

1-1,1-2,1-3,…1-i(ｉは０でない整数)…モジュール、
２…データ転送手段、3-1,3-2,3-3,…3-i…ネットワー
クインタフェース制御部、４…受信キュー、 ５…
解析処理部、 51…パケット解析部、52…フロー識
別情報テーブル、 ６…転送タグ生成部、7-1,7-
2,…7-i…転送制御部、 ８…一般送信キュー、
9-1,9-2,…9-j(ｊは０でない整数)…優先送信キュー、1
0-1,10-2,…10-k(ｋは０でない整数)…フロー送信キュ
ー、11…振り分け制御部、 12…送信キュ
ー管理部、121…送信キュー登録表、 122…一
般送信キュー８の管理表、123-1,123-2,…123-j…優先
送信キュー9-1,9-2,…9-jの管理表、124-1,124-2,…124
-k…フロー送信キュー10-1,10-2,…10-kの管理表、125
…送信管理用のフリーランタイマ。

Claims (6)

【特許請求の範囲】
1. 【請求項１】複数のネットワークに相互に接続しそれぞ
   れのネットワーク間のパケットを相互に中継するインタ
   ネットワーク装置であって、 該インタネットワーク装置に接続するあるネットワーク
   から受信したパケットに記録されている宛先ネットワー
   ク層アドレスとトランスポート層プロトコル、セッショ
   ン層アプリケーションを解析する機能を有し、 また、受信したパケットに記録されている送り元ネット
   ワーク層アドレスとフローを識別するための値を解析す
   る機能を有し、 該インタネットワーク装置に、宛先ネットワーク層アド
   レスとトランスポート層プロトコルとセッション層アプ
   リケーションの値の組、および、送り元ネットワーク層
   アドレスとフローを識別するための値を組にして登録
   し、登録したそれぞれの組に識別番号を付ける機能を有
   し、 両者それぞれの解析結果と該インタネットワーク装置に
   該登録済みの情報とを比較し、いずれかの解析結果と一
   致する情報が存在した場合には、該受信パケットが一定
   の帯域を保証しながら中継する必要があるパケット群の
   １つと判断する機能を有し、 該パケットを該インタネットワーク装置に接続する別の
   ネットワークへ中継する際に解析結果と一致した情報の
   識別番号毎に帯域を保証するための送信キューを用意
   し、該送信キューを使って送信する機能を有することを
   特徴とするインタネットワーク装置。
2. 【請求項２】請求項１記載のインタネットワーク装置に
   おいて、該インタネットワーク装置が動作しつづける限
   り一定の間隔で値を増加させるタイマと、前記送信キュ
   ー毎に該送信キューの管理情報を保持する管理表を有
   し、該管理表には該タイマの値を一時的に記録しておく
   記録領域を２個設け、 前記パケット群の通信に必要な既登録の帯域幅と推定平
   均パケット長から前記送信キューの送信処理を実行する
   送信時間間隔の値をあらかじめ算出しておき、 前記送信キューに登録されているパケットを１パケット
   送信し終わる毎に、該送信時間間隔の値から次に該送信
   キューの送信処理をすべき時間を算出し、これに時間幅
   を付けた値の上限値と下限値を該送信キューの管理表の
   該記録領域２個に記録し、 該記録領域に記録した時間幅の上限値と下限値の範囲に
   該タイマの値が入ったならば該送信キューに登録したパ
   ケットを１パケット送信する機能を有することを特徴と
   するインタネットワーク装置。
3. 【請求項３】２個のｎビット（ｎは整数）のデータを１
   組にして複数組のデータを登録することができ、任意の
   １組のデータを削除することができ、それぞれの組に該
   組のデータが有功か否かを表す有効ビットを有し、デー
   タを登録した組の該有効ビットは有効の状態に設定さ
   れ、データを削除した組の該有功ビットは無効の状態に
   設定される記憶素子であって、 比較対照として該記憶素子外部から与えられるｎビット
   のデータが、あらかじめ登録された１組２個のデータで
   挟まれた値の範囲に入っているか、全ての有効な組に対
   して調べる機能を有し、 範囲内と判定された組が存在したならば該組が登録され
   ている該記憶素子の番地を出力いる機能を有し、範囲内
   と判定された組が複数存在するならば番地の値が小さい
   順番、または大きい順番に番地の値を全てまたは一部出
   力する機能を有することを特徴とする記憶素子。
4. 【請求項４】請求項２記載のインタネットワーク装置に
   おいて、 前記管理表に設ける前記タイマの値を一時的に記録して
   おく記録領域として請求項３記載の記憶素子を利用し、
   あらかじめ前記次に送信処理をすべき時間の上限値と下
   限値を組にして該記憶素子に登録しておき、前記記憶素
   子に与えるデータとして前記タイマの値を与え、該記憶
   素子に記憶した時間幅の上限値と下限値の範囲に該タイ
   マの値が入ったならば該送信キューに登録したパケット
   を１パケット送信する機能を有することを特徴とするイ
   ンタネットワーク装置。
5. 【請求項５】複数のネットワークに相互に接続しそれぞ
   れのネットワーク間のパケットを相互に中断するインタ
   ネットワーク装置であって、 該インタネットワーク装置に接続するあるネットワーク
   から受信したパケットに記録されているトランスポート
   層プロトコルとセッション層アプリケーションを解析す
   る機能を有し、 また、受信したパケットに記録されている優先処理の必
   要性の程度を表す値を解析する機能を有し、 該インタネットワーク装置にあらかじめ個々のトランス
   ポート層プロトコルとセッション層アプリケーションの
   組、または、優先処理の必要性の程度を表す値に、識別
   番号を割り当てておき、 両者それぞれの解析結果と該インタネットワーク装置に
   既登録の情報とを比較し、いずれかの解析結果と一致す
   る情報が存在した場合には、該受信パケットが他のパケ
   ットより優先的に中継する必要があるパケット群の１つ
   と判断する機能を有し、 該パケットを該インタネットワーク装置に接続する別の
   ネットワークへ中継する際に解析結果と一致した情報の
   識別番号毎にパケットの優先的な送信処理を実行するた
   めの送信キューを用意し、該送信キューを使って送信す
   る機能を有することを特徴とするインタネットワーク装
   置。
6. 【請求項６】請求項４記載のインタネットワーク装置に
   おいて、該インタネットワーク装置が動作しつづける限
   り一定の間隔で値を増加させるタイマと、前記送信キュ
   ー毎に該送信キューの管理情報を保持する管理表を有
   し、該管理表には該タイマの値を一時的に記録しておく
   記録領域を２個設け、 第１の該記録領域には次に前記送信キューの送信処理を
   起動する予定時刻の該タイマ値を記録しておき、前記送
   信キュー以外の送信キューの処理を１回実施する毎に第
   １の該記録領域に記録した該タイマ値と現在の該タイマ
   値を比較し、現在の該タイマ値が大きければ前記送信キ
   ューに登録されているパケットを１パケット送信する機
   能を有し、 前記パケット群を取り扱う送信キューの処理継続時間を
   あらかじめ決定しておき、 前記送信キューに登録されているパケットを１パケット
   送信する際、送信処理を開示したときに現在の該タイマ
   値を第２の該記録領域に記録しておき、１パケットの送
   信処理を終了したときに第２の該記録領域に記憶してい
   る値に該処理継続時間を加えた値が現在の該タイマ値よ
   りも大きな値であれば、加えて１パケットの送信処理を
   実行する機能を有することを特徴とするインタネットワ
   ーク装置。