JP2000299701A - パケット処理装置およびパケット処理方法 - Google Patents

Abstract

(57)【要約】 【課題】 品質を予約したために却って遅延時間やサー
ビス品質が低下する品質予約異常に効率良く対処するこ
とができるパケット処理装置およびパケット処理方法を
提供すること。 【解決手段】 予約キュー１３に実パケットを挿入する
際に、この実パケットに対応するバブルを作成してＢＥ
Ｓキュー１４に投入し、実パケットよりもバブルの方が
先にスケジューリングされる場合には、この実パケット
をバブルの代わりにＢＥＳキュー１４から出力する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、入力パケットを
分類し、分類したパケットをそれぞれ複数のキューに蓄
積し、該複数のキューに蓄積されたパケットの中からい
ずれかのパケットをスケジューラによって選択して出力
するパケット処理装置およびパケット処理方法に関す
る。

【０００２】近年、音声や動画などの実時間通信がＩＰ
上で実現することが可能となり、また企業の基幹業務通
信にもＩＰが利用されつつあるため、かかるＩＰを用い
た場合の通信品質の保証が重要となってきた。このた
め、たとえばＲＳＶＰ（resorce ReSaVation Protcol）
などの予約プロトコルを用いてエンドツーエンドで品質
を予約するシグナリングや、ＷＦＱ（Weight Fair Queu
eing）などのバンド幅スケジューラを用いて通信パス上
のノードで品質を保証するトラフィック制御がおこなわ
れている。

【０００３】

【従来の技術】従来、ＴＣＰ／ＩＰ体系の中核となるイ
ンターネットプロトコル（ＩＰ）は、目的地までの配送
に関して最善の努力を払う反面、その確実な配送は保証
しないというベストエフォート型（以下「ＢＥＳ」とい
う）の配送をその特徴とするため、利用可能なバンド幅
などの品質については保証されない。

【０００４】しかし、最近になって音声や動画などの実
時間通信がＩＰ上で実現することが可能となり、また企
業の基幹業務通信にもＩＰが利用されつつあるため、か
かるＩＰを用いた場合の通信品質の保証が重要となって
いる。このため、ＲＳＶＰなどの予約プロトコルを用い
てエンドツーエンドで品質を予約するシグナリングや、
ＷＦＱなどのバンド幅スケジューラを用いて通信パス上
のノードで品質を保証するトラフィック制御がおこなわ
れている。

【０００５】具体的には、図１４に示すように、ルーテ
ィング処理部１４０でルーティング処理されたパケット
をクラシファイア（classifier）１４１でストリームに
分類し、パケット廃棄部１４２でパケットを廃棄するか
否かを判断し、廃棄しないパケットをストリームごとの
キューに入力し、スケジューラ１４３が適切な順序でパ
ケットを選択出力することにより、通信品質が保証され
る。

【０００６】なお、フィルタ１４１ａ〜１４１ｃは、入
力パケットを予約キュー１４３ａ〜１４３ｃに加えるか
否かのフィルタリングをおこない、いずれの予約キュー
にも属さないものは、ベストエフォートキュー（以下
「ＢＥＳキュー」という）１４３ｄに加えられる。

【０００７】

【発明が解決しようとする課題】しかしながら、図１４
に示すネットワークノードを用いて品質を予約したとし
ても、品質を予約したために却って遅延時間やサービス
品質が低下するという異常（以下「品質予約異常」とい
う）が生ずる場合がある。

【０００８】具体的には、図１５（ａ）に示すように、
パケット廃棄部１４２がシステム全体としてパケットを
廃棄する場合には、予約キュー１４１ａ以外のキュー１
４１ｂ〜１４１ｄが混雑すると、レートＡでパケットが
到着してもこの予約キュー１４３ａからは予約レートＲ
でしかパケットを出力できないため、結果的にこの予約
キュー１４３ａに滞留するパケットが（Ａ−Ｒ）のレー
トで増加する。

【０００９】そして、かかる予約キュー１４３ａに滞留
するパケットが増加すると、その後にトラフィックのレ
ートが低下したとしても、他のキュー１４３ｂ〜１４３
ｄが混雑している間は、この予約キュー１４３ａのキュ
ー長が短くはならないので、品質を予約したために却っ
て遅延時間が大きくなるという品質予約異常が生ずるこ
ととなる。

【００１０】また、図１５（ｂ）に示すように、キュー
ごとに設けたキュー長制限に基づいてパケット廃棄部１
４２がパケットをキューごとに廃棄する場合には、この
キュー長制限をレートＲで除算した時間内に遅延時間を
抑制できる反面、入出力レートの差分（Ａ−Ｒ）に相当
する分のパケットが予約キュー１４３ａの入り口で廃棄
される。すなわち、かかる場合には、品質を予約したた
めに却って廃棄されるパケット量が増大し、結果的にサ
ービス品質が低下するという品質予約異常が生ずること
となる。

【００１１】さらに、図１５（ｃ）に示すように、予約
時にトークンバケットにより示されるトラフィックの条
件（Tspec ）を示し、到着するパケットがその条件を満
たすか否かの条件チェック（以下「コンフォーマンスチ
ェック」という）をおこない、条件を満たすコンフォー
マントなパケットについては予約キュー１４３ａに投入
し、条件を満たさないノンコンフォーマントなパケット
についてはＢＥＳのＲＥＤ（Random Early Detection）
にかけ、廃棄されないパケットを予約キュー１４３ａに
投入することもできる。

【００１２】しかしながら、この技術を用いたとして
も、予約キュー１４３ａ中にノンコンフォーマントなパ
ケットが溜まりすぎる場合があり得るので、品質を予約
したために却って遅延時間が大きくなるという品質予約
異常を回避することはできない。

【００１３】具体的には、アプリケーションがトラフィ
ック特性（Tspec ）を指定し、かつ、このアプリケーシ
ョンがTspec に準拠する場合には、アプリケーションが
適切なTspec を指定し、送信を正しく制御しさえしてい
れば、ノンコンフォーマントなパケットは発生しない。
しかしながら、アプリケーションが制御できる時間精度
は１０ｍｓ程度であることが多く、この場合には細かな
誤差が避けられないため、一部のパケットがノンコンフ
ォーマントになる。

【００１４】また、アプリケーションがトラフィック特
性（Tspec ）を指定するが、このアプリケーションが故
意にTspec に準拠しないで出力する場合には、故意また
はバグのいずれにしても、Tspec 以上に送信することと
なるため、定常的にノンコンフォーマントなパケットが
発生する。

【００１５】さらに、アプリケーションがトラフィック
特性（Tspec ）を指定するが、このアプリケーションが
トラフィック特性を制御できない場合には、たとえばＯ
Ｓ内のＴＣＰ処理モジュールが予約値以上のパケットを
勝手に送出してしまい、かなりの割合でノンコンフォー
マントなパケットが発生する。

【００１６】また、アプリケーションがトラフィック特
性（Tspec ）を指定しない場合には、そのバンド幅を利
用する多数のアプリケーションが同時かつ独立に動作
し、それぞれのアプリケーションが予約バンド幅を意識
せずに動作するため、ノンコンフォーマントなパケット
が頻繁に発生する。

【００１７】これらのことから、品質を予約したために
却って遅延時間やサービス品質が低下する品質予約異常
をいかに効率良く解決するかが極めて重要な課題となっ
ている。

【００１８】本発明は、上記に鑑みてなされたもので、
品質を予約したために却って遅延時間やサービス品質が
低下する品質予約異常に効率良く対処することができる
パケット処理装置およびパケット処理方法を提供するこ
とを目的とする。

【００１９】

【課題を解決するための手段】上記目的を達成するため
に、請求項１にかかるパケット処理装置は、入力パケッ
トを分類する分類手段と、この分類手段によって分類さ
れたパケットをそれぞれ蓄積する複数のキューと、該複
数のキューに蓄積されたパケットの中からいずれかのパ
ケットを選択して出力するスケジューラとを有するパケ
ット処理装置において、前記分類手段により分類された
パケットを第１のキューに挿入する際に、このパケット
に対応する疑似パケットを作成して第２のキューに挿入
する疑似パケット入力手段（後述する実施の形態のパケ
ット廃棄部２３ｂがおこなう処理に相当）と、前記疑似
パケット入力手段により第２のキューに挿入された疑似
パケットが前記スケジューラの処理対象とされた際に、
当該疑似パケットに代えて前記第１のキューのパケット
を第２のキューからの出力として処理する処理手段（後
述する実施の形態のスケジューラ２３ｆがおこなう処理
に相当）とを備えたことを特徴とする。

【００２０】この請求項１にかかる発明では、分類され
たパケットを第１のキューに挿入する際に、このパケッ
トに対応する疑似パケットを作成して第２のキューに挿
入し、この第２のキューに挿入した疑似パケットがスケ
ジューラの処理対象とされた際に、当該疑似パケットに
代えて第１のキューのパケットを第２のキューからの出
力として処理することとしたので、少なくとも第２のキ
ューの品質を第１のキューの品質として確保ことができ
る。

【００２１】また、請求項２にかかるパケット処理装置
は、前記疑似パケット入力手段は、前記第１のキューに
挿入するパケットと該パケットに対応する前記第２のキ
ューに挿入する疑似パケットとを相互に関連づけること
を特徴とする。

【００２２】この請求項２にかかる発明では、第１のキ
ューに挿入するパケットと該パケットに対応する第２の
キューに挿入する疑似パケットとを相互に関連づけるこ
ととしたので、パケットまたは疑似パケットのいずれか
がスケジューリング対象とされた際に、他のキューに所
在する当該パケットまたは疑似パケットに関連する疑似
パケットまたはパケットを容易に特定することができ
る。

【００２３】また、請求項３にかかるパケット処理装置
は、前記処理手段は、前記疑似パケットが該疑似パケッ
トに対応する前記第１のキューに挿入されたパケットよ
りも先にスケジューラの処理対象とされた場合には、当
該疑似パケットに対応する前記第１のキューのパケット
を第２のキューからの出力として処理し（後述する図７
のステップＳ２０８〜Ｓ２１２に相当）、前記疑似パケ
ットよりも該疑似パケットに対応する前記第１のキュー
に挿入されたパケットの方が先にスケジューラの処理対
象とされた場合には、当該パケットを処理するとともに
前記疑似パケットを無効化する（後述する図７のステッ
プＳ２０２〜Ｓ２０７に相当）ことを特徴とする。

【００２４】この請求項３にかかる発明では、疑似パケ
ットが先にスケジューラの処理対象とされた場合には、
この疑似パケットに対応する第１のキューのパケットを
第２のキューからの出力として処理するので、少なくと
も第２のキューの品質を第１のキューで保証できる。ま
た、第１のキューに挿入されたパケットの方が先にスケ
ジューラの処理対象とされた場合には、当該パケットを
処理するとともに疑似パケットを無効化するので、不要
な疑似パケットを処分することができる。

【００２５】また、請求項４にかかるパケット処理装置
は、前記第１のキューに挿入するパケットは、該パケッ
トが実パケットであることを示す識別情報と、該疑似パ
ケットへのリンク情報とを有し（後述する図４に示すパ
ケットの構造に相当）、前記第２のキューに挿入する疑
似パケットは、疑似パケットであることを示す識別情報
と、該疑似パケットに対応する実パケットへのリンク情
報とを有する（後述する図４に示すバブルの構造に相
当）ことを特徴とする。

【００２６】この請求項４にかかる発明では、第１のキ
ューに挿入するパケットに、該パケットが実パケットで
あることを示す識別情報と、該疑似パケットへのリンク
情報とを付加することとしたので、このパケットが先に
スケジューリング対象とされた場合に対応する疑似パケ
ットの廃棄を容易におこなうことができる。また、第２
のキューに挿入する疑似パケットは、疑似パケットであ
ることを示す識別情報と、該疑似パケットに対応するパ
ケットへのリンク情報とを付加することとしたので、疑
似パケットが先にスケジューリング対象とされた場合
に、この疑似パケットに対応するパケットを迅速に取り
出すことができる。

【００２７】また、請求項５にかかるパケット処理装置
は、前記疑似パケット入力手段は、前記第２のキューに
挿入する疑似パケットと前記第１のキューとを関連づけ
ることを特徴とする。

【００２８】この請求項５にかかる発明では、パケット
と該パケットに対応する疑似パケットとを関連づけるの
ではなく、疑似パケットと第１のキューとを関連づける
こととしたので、パケットと疑似パケットの関連づけに
かかわる処理負担を軽減することができる。

【００２９】また、請求項６にかかるパケット処理装置
は、前記処理手段は、前記疑似パケットがスケジューラ
の処理対象とされた場合に、前記第１のキューにパケッ
トが存在すれば、その先頭のパケットを第２のキューか
らの出力として処理し（後述する図１３のステップＳ４
０９〜Ｓ４１３に相当）、前記第１のキューにパケット
が存在しない場合は、前記疑似パケットを廃棄し、その
際第２のキューに次のパケットが存在すればそのパケッ
トを処理対象とし、第２のキューに次のパケットが存在
しなければ、スケジューリングをやり直すことを特徴と
する。

【００３０】この請求項６にかかる発明では、第１のキ
ューに挿入されたパケットの方が先にスケジューラの処
理対象とされた場合には、疑似パケットを無視して当該
パケットの処理のみをおこなうこととしたので、疑似パ
ケットにかかわる処理を軽減することができる。

【００３１】また、請求項７にかかるパケット処理装置
は、前記第２のキューに挿入する疑似パケットは、疑似
パケットであることを示す識別情報と、前記第１のキュ
ーへのリンク情報とを有する（後述する図１０に示すバ
ブルの構造に相当）ことを特徴とする。

【００３２】この請求項７にかかる発明では、第２のキ
ューに挿入する疑似パケットには、対応する第１のキュ
ーのパケットへのポインタではなく第１のキューへのリ
ンク情報を付加し、また第１のキューに挿入するパケッ
トには疑似パケットへのポインタを付加しないので、パ
ケットと疑似パケットのリンクにかかわる処理負担を軽
減することができる。

【００３３】また、請求項８にかかるパケット処理装置
は、前記複数のキューは、出力バンド幅を予約した複数
の予約キューおよびベストエフォートキューからなり、
前記第１のキューは前記複数の予約キューのいずれかに
対応し、前記第２のキューは前記ベストエフォートキュ
ーに対応することを特徴とする。

【００３４】この請求項８にかかる発明では、疑似パケ
ットをベストエフォートキューに挿入することとしたの
で、各予約キューの品質として少なくともベストエフォ
ートキューの品質を確保することができる。

【００３５】また、請求項９にかかるパケット処理方法
は、入力パケットを分類し、分類したパケットをそれぞ
れ複数のキューに蓄積し、該複数のキューに蓄積された
パケットの中からいずれかのパケットをスケジューラに
よって選択して出力するパケット処理方法において、前
記分類したパケットを第１のキューに挿入する際に、こ
のパケットに対応する疑似パケットを作成して第２のキ
ューに挿入する疑似パケット入力工程（後述する図５お
よび図６に示すステップＳ１０１〜Ｓ１１４に相当）
と、前記疑似パケット入力工程において第２のキューに
挿入された疑似パケットが前記スケジューラの処理対象
とされた際に、当該疑似パケットに代えて前記第１のキ
ューのパケットを第２のキューからの出力として処理す
る処理工程（後述する図７に示すステップＳ２０１〜Ｓ
２１２に相当）とを含んだことを特徴とする。

【００３６】この請求項９にかかる発明では、分類され
たパケットを第１のキューに挿入する際に、このパケッ
トに対応する疑似パケットを作成して第２のキューに挿
入し、この第２のキューに挿入した疑似パケットがスケ
ジューラの処理対象とされた際に、当該疑似パケットに
代えて第１のキューのパケットを第２のキューからの出
力として処理することとしたので、少なくとも第２のキ
ューの品質を第１のキューの品質として確保ことができ
る。

【００３７】また、請求項１０にかかるパケット処理方
法は、前記疑似パケット入力工程は、前記第１のキュー
に挿入するパケットと該パケットに対応する前記第２の
キューに挿入する疑似パケットとを相互に関連づけるこ
とを特徴とする。

【００３８】この請求項１０にかかる発明では、第１の
キューに挿入するパケットと該パケットに対応する第２
のキューに挿入する疑似パケットとを相互に関連づける
こととしたので、パケットまたは疑似パケットのいずれ
かがスケジューリング対象とされた際に、他のキューに
所在する当該パケットまたは疑似パケットに関連する疑
似パケットまたはパケットを容易に特定することができ
る。

【００３９】また、請求項１１にかかるパケット処理方
法は、前記処理工程は、前記疑似パケットが該疑似パケ
ットに対応する前記第１のキューに挿入されたパケット
よりも先にスケジューラの処理対象とされた場合には、
当該疑似パケットに対応する前記第１のキューのパケッ
トを第２のキューからの出力として処理（後述する図７
のステップＳ２０８〜Ｓ２１２に相当）し、前記疑似パ
ケットよりも該疑似パケットに対応する前記第１のキュ
ーに挿入されたパケットの方が先にスケジューラの処理
対象とされた場合には、当該パケットを処理するととも
に前記疑似パケットを無効化する（後述する図７のステ
ップＳ２０２〜Ｓ２０７に相当）ことを特徴とする。

【００４０】この請求項１１にかかる発明では、疑似パ
ケットが先にスケジューラの処理対象とされた場合に
は、この疑似パケットに対応する第１のキューのパケッ
トを第２のキューからの出力として処理するので、少な
くとも第２のキューの品質を第１のキューで保証でき
る。また、第１のキューに挿入されたパケットの方が先
にスケジューラの処理対象とされた場合には、当該パケ
ットを処理するとともに疑似パケットを無効化するの
で、不要な疑似パケットを処分することができる。

【００４１】また、請求項１２にかかるパケット処理方
法は、前記疑似パケット入力工程は、前記第２のキュー
に挿入する疑似パケットと前記第１のキューとを関連づ
けることを特徴とする。

【００４２】この請求項１２にかかる発明では、パケッ
トと該パケットに対応する疑似パケットとを関連づける
のではなく、疑似パケットと第１のキューとを関連づけ
ることとしたので、パケットと疑似パケットの関連づけ
にかかわる処理負担を軽減することができる。

【００４３】また、請求項１３にかかるパケット処理方
法は、前記処理手段は、前記疑似パケットがスケジュー
ラの処理対象とされた場合に、前記第１のキューにパケ
ットが存在すれば、その先頭のパケットを第２のキュー
からの出力として処理し（後述する図１３のステップＳ
４０９〜Ｓ４１３に相当）、前記第１のキューにパケッ
トが存在しない場合は、前記疑似パケットを廃棄し、そ
の際第２のキューに次のパケットが存在すればそのパケ
ットを処理対象とし、第２のキューに次のパケットが存
在しなければ、スケジューリングをやり直すことを特徴
とする。

【００４４】この請求項１３にかかる発明では、第１の
キューに挿入されたパケットの方が先にスケジューラの
処理対象とされた場合には、疑似パケットを無視して当
該パケットの処理のみをおこなうこととしたので、疑似
パケットにかかわる処理を軽減することができる。

【００４５】また、請求項１４にかかるパケット処理方
法は、前記複数のキューは、出力バンド幅を予約した複
数の予約キューおよびベストエフォートキューからな
り、前記第１のキューは前記複数の予約キューのいずれ
かに対応し、前記第２のキューは前記ベストエフォート
キューに対応することを特徴とする。

【００４６】この請求項１４にかかる発明では、疑似パ
ケットをベストエフォートキューに挿入することとした
ので、各予約キューの品質として少なくともベストエフ
ォートキューの品質を確保ことができる。

【００４７】

【発明の実施の形態】以下に添付図面を参照して、この
発明にかかるパケット処理装置およびパケット処理方法
の好適な実施の形態を詳細に説明する。なお以下では、
本発明をルータの出力インターフェース部に適用した場
合を示すこととする。

【００４８】（実施の形態１）図２は、この実施の形態
１で用いるルータおよび出力インターフェース部の構成
を示す機能ブロック図である。図２（ａ）に示すルータ
２０は、ＯＳＩ（OpenSystem Interconnection ）基本
参照モデルのネットワーク層プロトコルに相当するＩＰ
に基づいてＩＰパケットの中継をおこなうＩＰパケット
中継装置であり、複数の入力インターフェース部２１
と、ルーティング処理部２２と、複数の出力インターフ
ェース部２３とからなる。

【００４９】入力インターフェース部２１は、ルータ２
０の外部から到来するパケットを受け付けてルーティン
グ処理部２２に出力する処理部であり、ルーティング処
理部２２は、入力インターフェース部２１から受け付け
たパケットのヘッダに基づいて、このパケットをいずれ
かの出力インターフェース部２３に出力する処理部であ
る。

【００５０】出力インターフェース部２３は、本発明に
かかわるパケット処理装置およびパケット処理方法を内
在し、パケットの廃棄、キューイングおよび品質保証を
おこなう処理部である。具体的には、予約キューにパケ
ットを投入する際にこのパケットの疑似パケット（以下
「バブル」という）を作成し、作成したバブルをＢＥＳ
キューに投入して、予約キューの品質がＢＥＳキューよ
りも低下しないことを保証するキューイング技術（以下
「完全バブルキューイング」という）を採用する。

【００５１】かかる完全バブルキューイングを採用した
理由は、品質を予約したために却って遅延時間やサービ
ス品質が低下する品質予約異常を解消し、予約キューに
おいて少なくともＢＥＳキューの品質を保証するためで
ある。

【００５２】図２（ｂ）に示すように、この出力インタ
ーフェース部２３は、クラシファイア２３ａと、パケッ
ト廃棄部２３ｂと、出力キュー２３ｃと、リシェーパ２
３ｄと、リミッタ２３ｅと、スケジューラ２３ｆとから
なる。クラシファイア２３ａは、ルーティング処理部２
２から受け付けた各パケットをフィルタリングして予約
キューのストリームごとに分類し、パケット廃棄部２３
ｂに出力する処理部である。

【００５３】パケット廃棄部２３ｂは、クラシファイア
２３ａから受け付けるパケット群のうち一定の条件に当
てはまる一部のパケットを廃棄する処理部分である。こ
の条件には、対応するキューにパケットを投入すると該
キューの最大キュー長を越えてしまう場合や、輻輳回避
のためのＲＥＤにより確率的に廃棄すべきと判断される
場合を含む。具体的には、このパケット廃棄部２３ｂで
は、ＢＥＳキューのストリームについてはＢＥＳのＲＥ
Ｄをおこない、また予約キューのストリームについては
コンフォーマンスチェックをおこなってノンコンフォー
マントなパケットにＢＥＳのＲＥＤをおこなう。

【００５４】なお、このＲＥＤ（Random Early Detecti
on）１２とは、ＲＥＤの対象とするキューの平均キュー
長をパラメータとして、前記キューに入るパケットの廃
棄確率を変更するパケット廃棄方式で、その内容はＩＥ
ＴＦ（Internet EngineeringTask Force ）のＲＦＣ２
３０９に示されている。

【００５５】出力キュー２３ｃは、複数の予約キューと
ＢＥＳキューとからなり、先入れ先出し方式で複数のパ
ケットからなるストリームを保持する。リシェーパ２３
ｄおよびリミッタ２３ｅは、ストリームの出力トラフィ
ックをあらかじめ定められた形に整形するレギュレータ
を形成し、このリミッタ２３ｅでは、ストリームの出力
トラフィックのピークレート制御をおこない、リシェー
パ２３ｄは、その他の整形をおこなう。

【００５６】スケジューラ２３ｆは、ストリーム単位で
パケットのスケジューリングをおこなう処理部である。
このスケジューラ２３ｆは、バンド幅保証、遅延保証お
よび平等性（Fairness）を判断基準としてパケットのス
ケジューリングをおこなう。

【００５７】つぎに、図２に示す出力インターフェース
部２３がおこなう完全バブルキューイングの処理概念に
ついて説明する。なお、この完全バブルキューイング
は、主として図２に示すパケット廃棄部２３ｂ、出力キ
ュー２３ｃおよびスケジューラ２３ｆにかかわる処理で
ある。

【００５８】図１は、図２に示す出力インターフェース
部２３がおこなう完全バブルキューイングの処理概念を
示す図である。同図に示すように、この完全バブルキュ
ーイングでは、予約キュー１３に投入される実パケット
のバブルをＢＥＳキュー１４に投入し、このＢＥＳキュ
ー１４に投入したバブルを予約キュー１３に投入した実
パケットとを対応づけることにより、予約キュー１３に
おいて少なくともＢＥＳキュー１４の品質を保証し、品
質を予約したために却って遅延時間やサービス品質が低
下する品質予約異常を解消している。

【００５９】具体的には、ＢＥＳキュー１４のストリー
ムは、従来と同様にＢＥＳのＲＥＤ１２によって廃棄す
べきか否かが判断され、廃棄しないパケットのみがＢＥ
Ｓキュー１４に投入される。

【００６０】これに対して、予約キュー１３のストリー
ムは、予約時にトークンバケットにより示されるトラフ
ィックの条件（Tspec ）を満たすか否かを判定するコン
フォーマンスチェック１１をおこない、条件を満たすコ
ンフォーマントなパケットを予約キュー１３に投入する
とともに、このパケットに対応するマーカとしてのバブ
ルをＢＥＳキュー１４に投入する。

【００６１】また、このコンフォーマンスチェック１１
の結果がノンコンフォーマントであるパケットについて
は、これをＢＥＳのＲＥＤ１２にかけてその一部を廃棄
し、廃棄されないパケットを予約キュー１３に投入しつ
つ、このパケットのバブルをＢＥＳキュー１４に投入す
る。

【００６２】なお、かかる予約キュー１３に投入したパ
ケットとＢＥＳキュー１４に投入したバブルとはそれぞ
れ対応づけられており、スケジューラ２３ｆでは、複数
のキューの中からつぎに出力するパケットを持つキュー
を選択する際に、このバブルについても通常のパケット
と同様にスケジューリングの対象とする。

【００６３】このように、かかる完全バブルキューイン
グでは、パケットをＢＥＳ扱いとした際にスケジューリ
ングされる時期をバブルを用いて特定し、このパケット
をＢＥＳ扱いした方が遅延時間が短くなって結果的に品
質が向上する場合には、バブルがスケジューリングされ
る時期に該バブルに対応するパケットをスケジューリン
グする。

【００６４】図３は、図１に示す予約キュー１３内の実
パケットとＢＥＳキュー１４内のバブルとの対応関係を
示す図である。同図（ａ）に示すように、スケジューラ
２３ｆによって予約キュー１３内の実パケットの方が、
ＢＥＳキュー１４内の対応するバブルのよりも早くスケ
ジューリングされた場合には、通常通り予約キュー１３
から実パケットを出力するとともに、ＢＥＳキュー１４
中の当該実パケットに対応するバブルを廃棄するなどし
て無効化する。

【００６５】これに対して、同図（ｂ）に示すように、
スケジューラ２３ｆによって予約キュー１３内の実パケ
ットよりも、ＢＥＳキュー１４内の対応するバブルの方
が早くスケジューリングされた場合には、その時点で当
該バブルに対応する実パケットを予約キュー１３から取
り出し、この実パケットをバブルに代えてＢＥＳキュー
１４から出力する。なお、この完全バブルキューイング
の場合には、ＢＥＳキュー１４のバブルが先頭にきたと
きに、対応する実パケットが必ず予約キュー１３の先頭
に位置することになる。

【００６６】具体的には、かかる場合にはこの実パケッ
トがＢＥＳキュー１４に割り当てられたバンド幅を消費
するように出力される。ここで、一般のスケジューラ
は、パケットが到着した際に当該パケットに時刻タグを
付け、その後この時刻タグに基づいて全パケットをソー
トするよう処理されることが多いが、全パケットをソー
トしなくともパケットの存在するキューでソートするこ
とにより、同様の結果が得られる。

【００６７】このため、このスケジューラ２３ｆでは、
パケットではなくキュー自体に時刻タグを付け、パケッ
トの到達時ではなく各キューの先頭のパケットが新しく
なったときに時刻タグを計算することとし、実パケット
をＢＥＳキュー１４から出力する場合には、このパケッ
トが使用したバンド幅をＢＥＳキュー１４の時刻タグに
反映させることとしている。なお、かかる処理をおこな
う理由は、パケットに時刻タグを付与したのでは、実パ
ケットをＢＥＳキュー１４から出力する際の処理が複雑
化するためである。

【００６８】つぎに、図１に示す予約キュー１３、ＢＥ
Ｓキュー１４、実パケットおよびバブルについてさらに
具体的に説明する。図４は、図１に示す予約キュー１３
内の実パケットおよびＢＥＳキュー１４内のバブルの具
体的なデータ構造の一例を示す図である。

【００６９】同図に示すように、ここでは複数の実パケ
ットを双方向のリンクドリストで連結して予約キュー１
３を形成するとともに、実パケットおよびバブルを双方
向のリンクドリストで連結してＢＥＳキュー１４を形成
している。

【００７０】具体的には、実パケットは、次パケットへ
のポインタを格納する“ｎｅｘｔ”と、前パケットへの
ポインタを格納する“ｐｒｅｖ”と、実パケットまたは
バブルのいずれであるかを示す“ｆｌａｇ”と、バブル
へのポインタを格納する“ｂｕｂｂｌｅ”と、実パケッ
トのサイズを格納する“パケットサイズ”と、実パケッ
トの内容を格納する“パケット本体”とからなる。

【００７１】また、バブルは、次パケットへのポインタ
を格納する“ｎｅｘｔ”と、前パケットへのポインタを
格納する“ｐｒｅｖ”と、実パケットまたはバブルのい
ずれであるかを示す“ｆｌａｇ”と、実パケットへのポ
インタを格納する“ｒｅａｌ”とからなり、“パケット
サイズ”および“パケット本体”は有しない。

【００７２】なお、このパケットが実パケットである場
合には“ｆｌａｇ＝０”となり、バブルである場合には
“ｆｌａｇ＝１”となる。また、ＢＥＳキュー１４内に
保持される実パケットについては、バブルへのポインタ
を格納しない。

【００７３】そして、予約キュー１３では、“ｎｅｘ
ｔ”および“ｐｒｅｖ”を用いてヘッド（ｈｅａｄ）の
パケットからテール（ｔａｉｌ）のパケットに至る双方
向のリンクが張られるとともに、各実パケットからＢＥ
Ｓキュー１４内の対応するバブルへリンクが張られる。

【００７４】これに対して、ＢＥＳキュー１４では、
“ｎｅｘｔ”および“ｐｒｅｖ”を用いてヘッド（ｈｅ
ａｄ）のパケットからテール（ｔａｉｌ）のパケットに
至る双方向のリンクが張られるとともに、各バブルから
予約キュー１３内の対応する実パケットへリンクが張ら
れる。

【００７５】このように、ここでは、実パケットを双方
向のリンクドリストで連結することにより予約キュー１
３を形成し、実パケットおよびバブルを双方向のリンク
ドリストで連結してＢＥＳキュー１４を形成するととも
に、実パケットおよびバブルの間をポインタで相互に対
応づけることとしている。

【００７６】つぎに、図１に示す完全バブルキューイン
グによるパケットキューイング時の処理手順について説
明する。図５および図６は、図１に示す完全バブルキュ
ーイングによるパケットキューイング時の処理手順を示
すフローチャートである。

【００７７】図５および図６に示すように、この完全バ
ブルキューイングでは、まず最初にストリームが瞬間最
大キュー長の制限を越えているか否かが調べられ（ステ
ップＳ１０１）、瞬間最大キュー長の制限を越えている
場合には（ステップＳ１０１否定）、パケットが廃棄さ
れる。

【００７８】一方、瞬間最大キュー長の制限を越えてい
ない場合には（ステップＳ１０１肯定）、予約ストリー
ムであるか否かが調べられ（ステップＳ１０２）、予約
ストリームでない場合には（ステップＳ１０２否定）、
ＢＥＳのＲＥＤを実行し（ステップＳ１１０）、当該パ
ケットが廃棄すべきものである場合には（ステップＳ１
１０肯定）そのままパケットを廃棄し、当該パケットが
廃棄すべきものでない場合には（ステップＳ１１０否
定）、このパケットをＢＥＳキュー１４に挿入する（ス
テップＳ１１１）。

【００７９】これに対し、ステップＳ１０２において予
約ストリームであると判断された場合には（ステップＳ
１０２肯定）、予約条件のチェックがあるか否かを判断
し（ステップＳ１０３）、予約条件のチェックがなく
（ステップＳ１０３否定）、このストリームのＲＥＤが
オンである場合には（ステップＳ１０４肯定）、全パケ
ット群に対してＲＥＤを実行し（ステップＳ１０５）、
廃棄対象となるパケットを廃棄する。

【００８０】また、ステップＳ１０４においてストリー
ムのＲＥＤがオンでない場合や（ステップＳ１０４否
定）、ストリームのＲＥＤがオンであるが当該ＲＥＤを
実行してもパケットが廃棄対象とはならない場合には
（ステップＳ１０５否定）、実パケットに対応するバブ
ルを作成して、作成したバブルをＢＥＳキュー１４に挿
入し（ステップＳ１１３）、実パケットを当該ストリー
ムの予約キュー１３に挿入する（ステップＳ１１４）。

【００８１】なお、このバブルには、バブルであること
を示す識別情報“ｆｌａｇ＝１”と、実パケットへのポ
インタを示す“ｒｅａｌ”とを付加する。また、実パケ
ットには、バブルでないことを示す識別情報“ｆｌａｇ
＝０”と、バブルへのポインタを示す“ｂｕｂｂｌｅ”
とを付加する。

【００８２】また、ステップＳ１０３において予約条件
のチェックすなわちコンフォーマンスチェックがなされ
（ステップＳ１０３肯定）、この予約条件が満たされて
いるコンフォーマントな場合には（ステップＳ１０６肯
定）、ステップＳ１１３に移行する。

【００８３】これに対して、予約条件が満たされていな
いノンコンフォーマントな場合には（ステップＳ１０６
否定）、ストリームのＲＥＤがオンであるか否かを調べ
（ステップＳ１０７）、このＲＥＤがオンでなければ
（ステップＳ１０７否定）、ＢＥＳのＲＥＤを実行する
（ステップＳ１１２）。そして、このパケットが廃棄対
象となる場合には（ステップＳ１１２肯定）当該パケッ
トを廃棄し、廃棄対象にならない場合には（ステップＳ
１１２否定）、ステップＳ１１３に移行する。

【００８４】また、ＲＥＤがオンであれば、この予約キ
ュー１３について違反パケット群に対するＲＥＤを実行
し（ステップＳ１０８）、パケットが廃棄対象となる場
合には（ステップＳ１０８肯定）このパケットを廃棄
し、廃棄対象とならない場合には（ステップＳ１０８否
定）、違反パケットであることを示す情報をパケットに
付加した後に（ステップＳ１０９）、ステップ１１３に
移行する。

【００８５】上記一連の処理をおこなうことにより、実
パケットを予約キュー１３に挿入するとともに、当該実
パケットに対応するバブルを作成してＢＥＳキュー１４
に挿入することができる。

【００８６】つぎに、図１に示す完全バブルキューイン
グによるパケットの出力時の処理手順について説明す
る。図７は、図１に示す完全バブルキューイングによる
パケットの出力時の処理手順を示すフローチャートであ
る。完全バブルキューイングにおいては、いずれかのキ
ューにパケットが存在するようになるまで待ち、スケジ
ューラが出力処理対象となるキューを選択したならば、
下記に示す処理をおこなう。

【００８７】図７に示すように、まず最初に先頭パケッ
トがバブルであるか否かを調べ（ステップＳ２０１）、
このパケットがバブルでない場合には（ステップＳ２０
１否定）、レギュレータがあるか否かを確認し（ステッ
プＳ２０２）、レギュレータの制限を満たさない場合に
は（ステップＳ２０３否定）ウエイト処理へ移行する。

【００８８】また、レギュレータがない場合や（ステッ
プＳ２０２否定）、レギュレータがあるが制限を満たす
場合には（ステップＳ２０３肯定）、当該キューのＲＥ
Ｄ用瞬間キュー長を減算し（ステップＳ２０５４、当該
キューからパケットを取り出す（ステップＳ２０５）。
なお、ステップＳ２０４において、予約キュー１３の場
合には、違反マーク付きのパケットについてのみおこな
う。

【００８９】その後、このパケットに対応するバブルが
存在するか否かを確認し（ステップＳ２０６）、対応す
るバブルが存在する場合には（ステップＳ２０６肯
定）、このバブルをバブルが入っているＢＥＳキュー１
４から取り出して廃棄する（ステップＳ２０７）。

【００９０】これに対し、上記ステップＳ２０１におい
て、パケットがバブルである場合には（ステップＳ２０
１肯定）、レギュレータがあるか否かを確認し（ステッ
プＳ２０８）、レギュレータの制限を満たさない場合に
は（ステップＳ２０９否定）ウエイト処理へ移行する。
なお、ここではウエイト処理についての説明は省略す
る。

【００９１】また、レギュレータがない場合や（ステッ
プＳ２０８否定）、レギュレータがあるが制限を満たす
場合には（ステップＳ２０９肯定）、ＢＥＳキュー１４
のＲＥＤ用瞬間キュー長を減算し（ステップＳ２１
０）、バブルをＢＥＳキュー１４から取り出して解放し
た後に（ステップＳ２１１）、予約キュー１３から当該
バブルに対応する実パケットを取り出す（ステップＳ２
１２）。

【００９２】上記一連の処理をおこなうことにより、少
なくともＢＥＳキュー１４と同程度の品質を予約キュー
１３に保証して、品質を予約したために却って遅延時間
やサービス品質が低下する品質予約異常を解消すること
ができる。

【００９３】上述してきたように、本実施の形態１にか
かわる完全バブルキューイングでは、予約キュー１３に
実パケットを挿入する際に、この実パケットに対応する
バブルを作成してＢＥＳキュー１４に投入し、実パケッ
トよりもバブルの方が先にスケジューリングされる場合
には、この実パケットをバブルの代わりにＢＥＳキュー
１４から出力するよう構成したので、少なくともＢＥＳ
キュー１４と同程度の品質を予約キュー１３に保証し
て、品質を予約したために却って遅延時間やサービス品
質が低下する品質予約異常を解消することができる。

【００９４】たとえば、ある予約ストリームについて、
“Ｒ”のバンド幅を割り当て、実際には“Ｒ”よりも大
きい“Ｓ”のバンド幅のトラフィックを流した場合に、
予約範囲の“Ｒ”分のトラフィックについてはパケット
を廃棄せずに予約ストリームの予約バンド幅を利用して
出力し、予約範囲をオーバーした“Ｓ−Ｒ”分のトラフ
ィックについては、あたかもＢＥＳストリームのパケッ
トであるかのようにＢＥＳと同じ方法でパケット廃棄を
おこない、廃棄されなかったパケットについてＢＥＳス
トリームに割り当てられたバンド幅を利用して出力す
る。このため結果的に、従来のバンド幅保証スケジュー
ラと同様に“Ｒ”のバンド幅が保証されるとともに、予
約しなかった場合のバンド幅も保証される。

【００９５】もし仮に、上記の“Ｓ−Ｒ”分のパケット
を単純にＢＥＳキュー１４に投入するような方法をとっ
たとすると、それらのパケットと、予約キュー１３のパ
ケットの順序関係が保たれず、受信側とは異なった順序
でパケットを出力することになり、アプリケーションの
動作に障害をきたしたり、通信の実行性能を低下させる
などの問題が生じる。バブルキューイング方式により、
予約ストリームのパケットをＢＥＳストリームのバンド
幅を利用して出力する場合は、予約キュー１３内の実パ
ケットは受信順を保って管理され、その順序で出力され
るため、予約ストリームのパケット順序が変動しない。
したがって、パケット順の変動により、アプリケーショ
ンや通信の性能を低下させることがない。

【００９６】なお、この完全バブルキューイングの実行
コストを検討すると、ここでは予約キュー１３に投入す
るすべてのパケットに対応するバブルを作成し、このバ
ブルをＢＥＳキュー１４に投入して実パケットとの対応
関係を保持することとしたため、バブルにかかわる情報
を記憶するメモリ容量が必要となる。

【００９７】しかしながら、バブルにかかわる情報は、
すでに説明したようにＢＥＳキュー１４内でのリンク、
バブルであることを示すフラグおよび実パケットへのポ
インタのみであるから、これらの情報は２ワード程度に
納めることができ、大きな問題とはならない。

【００９８】また、かかる完全バブルキューイングを採
用する場合には、バブルをＢＥＳキュー１４に投入した
り、バブルであるか否かを判断したり、バブルと実パケ
ットとの対応づけをおこなうＣＰＵコストが必要となる
が、かかるＣＰＵ負担はバンド幅保証をおこなうコスト
と比較すると極めて小さいため、大きな問題とはならな
い。

【００９９】（実施の形態２）ところで、上記実施の形
態１が採用する完全バブルキューイングでは、メモリ容
量およびＣＰＵコストが特に問題にならないと考えた
が、ハードウエア化を図る場合には、ＣＰＵの処理負担
をできるだけ低減することが望ましい。このため、本実
施の形態２では、パケットとバブルとを一対一で対応づ
ける処理負担を軽減する技術（以下「部分バブルキュー
イング」という）について説明する。なお、この場合の
ルータおよび出力インターフェース部の構成は図２に示
すものと同様のものになるので、ここではその説明を省
略する。

【０１００】図８は、実施の形態２にかかわる部分バブ
ルキューイングの処理概念を示す図である。同図に示す
ように、この部分バブルキューイングでは、予約ストリ
ームのうちノンコンフォーマントなパケットのみについ
てバブルを作成することとしたので、予約ストリームの
すべてのパケットがコンフォーマントであるならば、バ
ブルが発生しないために処理負担が軽減する。

【０１０１】しかしながら、ノンコンフォーマントなパ
ケットについてのみバブルを作成することとすると、完
全バブルキューイングの場合と異なり、バブルがＢＥＳ
キュー１４の先頭にきたときに当該バブルに対応する実
パケットが予約キュー１３の先頭にあるとは限らなくな
る。

【０１０２】このため、バブルに対応する実パケットを
予約キュー１３から抜き出して送信したのでは、予約ス
トリーム中のパケットの順序が変動してしまうという問
題がある。また、このバブルに対応する実パケットまで
のすべてのパケットを連続送信することとすると、他の
ストリームに対するバンド幅を保証できなくなるという
問題もある。加えて、外部で観察した場合には、ノード
でどのパケットをノンコンフォーマントと解釈して出力
したかをパケットごとに正確に判別できないという事実
もある。

【０１０３】そこで、この部分バブルキューイングで
は、バブルと実パケットとの厳密な対応関係はとらず、
バブルから予約キュー１３への対応関係のみを保持し
て、予約キュー１３中の実パケットのうちＢＥＳキュー
１４のバンド幅を利用して予約キュー１３のパケットを
出力すべきタイミングだけを管理するよう構成してい
る。

【０１０４】具体的には、ＢＥＳキュー１４のストリー
ムは、従来と同様にＢＥＳのＲＥＤ１２によって破棄す
べきか否かが判断され、破棄しないパケットのみをＢＥ
Ｓキュー１４に投入する。

【０１０５】これに対して、予約キュー１３のストリー
ムについては、コンフォーマンスチェック１１をおこな
い、条件を満たすコンフォーマントなパケットについて
はバブルを作成することなく予約キュー１３に投入す
る。

【０１０６】また、このコンフォーマンスチェック１１
の結果がノンコンフォーマントであるパケットについて
は、これをＢＥＳのＲＥＤ１２にかけてその一部を廃棄
し、廃棄されないパケットを予約キュー１３に投入しつ
つ、このパケットのバブルをＢＥＳキュー１４に投入す
る。

【０１０７】なお、かかる予約キュー１３に投入したパ
ケットとＢＥＳキュー１４に投入したバブルとは直接の
対応関係はとらず、バブルから予約キュー１３への対応
関係のみを保持する。

【０１０８】このように、かかる部分バブルキューイン
グでは、完全バブルキューイングのように予約キュー１
３に投入するすべての実パケットについてバブルを作成
するのではなく、ＲＥＤで廃棄されないノンコンフォー
マントなパケットについてのみバブルを作成してＢＥＳ
キュー１４に投入するとともに、バブルから予約キュー
１３への対応関係のみを保持することとしている。

【０１０９】図９は、図８に示す予約キュー１３内の実
パケットとＢＥＳキュー１４内のバブルとの対応関係を
示す図である。同図（ａ）に示すように、スケジューラ
２３ｆによって予約キュー１３内の実パケットの方が、
ＢＥＳキュー１４内の対応するバブルよりも早くスケジ
ューリングされた場合には、通常通り予約キュー１３か
ら実パケットを出力する。なお、この実パケットと当該
実パケットに対応するＢＥＳキュー１４中のバブルとの
対応関係は保持されていないので、ＢＥＳキュー１４中
のバブルに関する処理はおこなわない。

【０１１０】これに対して、同図（ｂ）に示すように、
スケジューラ２３ｆによって、ＢＥＳキュー１４内の対
応するバブルがスケジューリングされた場合には、その
時点でたまたま予約キュー１３の先頭に存在する実パケ
ットをＢＥＳキュー１４のバンド幅を使って出力する。
ただし、予約キュー１３にパケットが存在しなければ、
当該バブルを廃棄し、ＢＥＳキュー１４の次のパケット
の処理をおこなう。また、ＢＥＳキュー１４にパケット
がなければ、再スケジューリングする。

【０１１１】このように、この部分バブルキューイング
では、ＢＥＳキュー１４中のバブル１個について予約キ
ュー１３中の実パケットを最大１個出力して、パケット
数の整合性のみを維持することとしている。

【０１１２】つぎに、図８に示す予約キュー１３、ＢＥ
Ｓキュー１４、実パケットおよびバブルについてさらに
具体的に説明する。図１０は、図８に示す予約キュー１
３内の実パケットおよびＢＥＳキュー１４内のバブルの
具体的なデータ構造の一例を示す図である。

【０１１３】同図に示すように、この部分バブルキュー
イングにおいても、完全バブルキューイングと同様に、
複数の実パケットを双方向のリンクドリストで連結して
予約キュー１３を形成するとともに、実パケットおよび
バブルを双方向のリンクドリストで連結してＢＥＳキュ
ー１４を形成している。

【０１１４】しかしながら、この部分バブルキューイン
グでは、バブルが実パケットへのポインタ“ｒｅａｌ”
ではなく、予約キュー１３へのポインタ“ｑｕｅｕｅ”
を持ち、また実パケットがバブルへのポインタを格納す
る“ｂｕｂｂｌｅ”を持たない点で完全バブルキューイ
ングと異なる。

【０１１５】このように、この部分バブルキューイング
では、予約キュー１３およびＢＥＳキュー１４をリンク
ドリストで形成する点では完全バブルキューイングと共
通するものの、実パケットとバブルとの対応関係をとら
ない点が異なる。

【０１１６】つぎに、図８に示す部分バブルキューイン
グによるパケットキューイング時の処理手順について説
明する。図１１および図１２は、図８に示す部分バブル
キューイングによるパケットキューイング時の処理手順
を示すフローチャートである。

【０１１７】図１１および図１２に示すように、この部
分バブルキューイングでは、まず最初にストリームが瞬
間最大キュー長の制限を越えているか否かを調べ（ステ
ップＳ３０１）、瞬間最大キュー長の制限を越えている
場合には（ステップＳ３０１否定）、パケットを廃棄す
る。

【０１１８】一方、瞬間最大キュー長の制限を越えてい
ない場合には（ステップＳ３０１肯定）、予約ストリー
ムであるか否かを調べ（ステップＳ３０２）、予約スト
リームでない場合には（ステップＳ３０２否定）、ＢＥ
ＳのＲＥＤを実行し（ステップＳ３１１）、当該パケッ
トが廃棄対象となる場合には（ステップＳ３１１肯定）
そのままパケットを廃棄し、当該パケットが廃棄対象と
ならない場合には（ステップＳ３１１否定）このパケッ
トをＢＥＳキュー１４に挿入する（ステップＳ３１
２）。

【０１１９】これに対し、上記ステップＳ３０２におい
て予約ストリームであると判断された場合には（ステッ
プＳ３０２肯定）、予約条件のチェックがあるか否かを
判断し（ステップＳ３０３）、予約条件のチェックがな
く（ステップＳ３０３否定）、このストリームのＲＥＤ
がオンである場合には（ステップＳ３０４肯定）、全パ
ケット群に対してこのストリームのＲＥＤを実行し（ス
テップＳ３０５）、廃棄対象となるパケットを廃棄す
る。

【０１２０】また、ステップＳ３０４においてストリー
ムのＲＥＤがオンでない場合や（ステップＳ３０４否
定）、ストリームのＲＥＤがオンであるが当該ＲＥＤを
実行してもパケットが廃棄対象とならない場合には（ス
テップＳ３０５否定）、このパケットを当該ストリーム
のキューに挿入する（ステップＳ３１０）。この際、併
せて瞬間キュー長の加算についてもおこなわれる。な
お、完全バブルキューイングと異なり、この場合には実
パケットに対応するバブルは作成されない。

【０１２１】また、ステップＳ３０３において予約条件
のチェックすなわちコンフォーマンスチェックがなされ
（ステップＳ３０３肯定）、この予約条件が満たされて
いるコンフォーマントな場合には（ステップＳ３０６肯
定）、ステップＳ３１０に移行する。

【０１２２】これに対して、予約条件が満たされていな
いノンコンフォーマントな場合には（ステップＳ３０６
否定）、ストリームのＲＥＤがオンであるか否かを調べ
（ステップＳ３０７）、このＲＥＤがオンでなければ
（ステップＳ３０７否定）、ＢＥＳのＲＥＤを実行する
（ステップＳ３１３）。

【０１２３】その結果、パケットが廃棄対象となる場合
には（ステップＳ３１３肯定）当該パケットを廃棄し、
廃棄対象とならない場合には（ステップＳ３１３否
定）、パケットを当該ストリームの予約キュー１３に挿
入するとともに（ステップＳ３１４）、ストリーム用の
バブルを生成してＢＥＳキュー１４に挿入する（ステッ
プＳ３１５）。

【０１２４】また、ＲＥＤがオンであれば、違反パケッ
ト群に対するＲＥＤを実行し（ステップＳ３０８）、パ
ケットが廃棄対象となる場合には（ステップＳ３０８肯
定）このパケットを廃棄し、廃棄対象とならない場合に
は（ステップＳ３０８否定）、違反パケットであること
を示す情報をパケットに付加した後に（ステップＳ３０
９）、ステップ３１０に移行する。

【０１２５】上記一連の処理をおこなうことにより、パ
ケットがノンコンフォーマントであり、かつ、ＢＥＳの
ＲＥＤで廃棄すべきものでない場合にのみ、バブルを作
成してＢＥＳキュー１４に挿入することができる。

【０１２６】つぎに、図８に示す部分バブルキューイン
グによるパケットの出力時の処理手順について説明す
る。図１３は、図８に示す部分バブルキューイングによ
るパケットの出力時の処理手順を示すフローチャートで
ある。この部分バブルキューイングにおいても、いずれ
かのキューにパケットが存在するようになるまで待ち、
スケジューラが出力処理対象となるキューを選択したな
らば、下記に示す処理をおこなう。

【０１２７】図１３に示すように、まず最初に先頭パケ
ットがバブルであるか否かを調べ（ステップＳ４０
１）、このパケットがバブルではない場合には（ステッ
プＳ４０１否定）、レギュレータがあるか否かを確認し
（ステップＳ４０２）、レギュレータの制限を満たさな
い場合には（ステップＳ４０３否定）ウエイト処理へ移
行する。

【０１２８】また、レギュレータがない場合や（ステッ
プＳ４０２否定）、レギュレータがあるが制限を満たす
場合には（ステップＳ４０３肯定）、当該キューのＲＥ
Ｄ用瞬間キュー長を減算し（ステップＳ４０４）、当該
キューからパケットを取り出す（ステップＳ４０５）。
なお、ステップＳ４０４において、予約キュー１３の場
合には、違反マーク付きのパケットについてのみおこな
う。

【０１２９】これに対して、このパケットがバブルであ
る場合には（ステップＳ４０１肯定）、このバブルに対
応づけられた予約キュー１３に実パケットがあるか否か
を確認し（ステップＳ４０６）、実パケットが存在しな
い場合には（ステップＳ４０６否定）、ＢＥＳキュー１
４のＲＥＤ用瞬間キュー長を減算し（ステップＳ４０
７）、バブルをＢＥＳキュー１４から取り出して解放し
（ステップＳ４０８）、ステップＳ４０１に移行する。

【０１３０】また、ステップＳ４０６において、バブル
に対応づけられた予約キュー１３に実パケットが存在す
る場合には（ステップＳ４０６肯定）、レギュレータが
あるか否かを確認し（ステップＳ４０９）、レギュレー
タの制限を満たさない場合には（ステップＳ４１０否
定）ウエイト処理へと移行する。

【０１３１】また、レギュレータがない場合や（ステッ
プＳ４０９否定）、レギュレータがあるが制限を満たす
場合には（ステップＳ４１０肯定）、ＢＥＳキュー１４
のＲＥＤ用瞬間キュー長を減算し（ステップＳ４１
１）、バブルをＢＥＳキュー１４から取り出して解放し
た後に（ステップＳ４１２）、予約キュー１３から当該
バブルに対応する実パケットを取り出す（ステップＳ４
１３）。

【０１３２】上記一連の処理をおこなうことにより、完
全バブルキューイングの場合と異なり、ＢＥＳキュー１
４中のバブル１個について予約キュー１３中の実パケッ
トを最大１個出力して、パケット数の整合性を維持する
ことができる。

【０１３３】上述してきたように、本実施の形態２にか
かわる部分バブルキューイングでは、完全バブルキュー
イングと異なり、ＲＥＤで廃棄されないノンコンフォー
マントなパケットのみについてバブルを作成するととも
に、このバブルと実パケットとの対応関係をとらず、Ｂ
ＥＳキュー１４中のバブル１個について予約キュー１３
中の実パケットを最大１個出力して、パケット数の整合
性を維持するよう構成したので、完全バブルキューイン
グ処理をより単純化し、効率良くハードウエア化するこ
とが可能となる。

【０１３４】なお、本実施の形態では、説明の便宜上予
約キュー１３に挿入する実パケットのバブルをＢＥＳキ
ュー１４に挿入する場合を示したが、本発明はこれに限
定されるものではなく、かかるバブルを他の予約キュー
１３に挿入する場合に適用することもできる。

【０１３５】また、本実施の形態では、ＢＥＳキューの
バブルがスケジューリングの対象となった場合におい
て、対応する予約キューに実パケットが存在する場合に
は、必ず当該実パケットをＢＥＳキューのバンド幅を使
って出力していた。しかし、一般には、対応する予約キ
ューに実パケットが存在しても、ある条件を満たす場合
のみバブルの処理を行い、条件を満たさない場合には対
応する実パケットがあたかも存在しなかった時のように
動作させる（つまり、バブルが無効であるとみなす）よ
うな実施の形態もあり得る。前記条件としては、たとえ
ば、予約キュー内のパケット数が２以上である、という
条件などがある。これは、バブル処理時に、予約キュー
が空になった場合の特殊な処理が必要となる可能性をな
くし、バブル処理を簡単化する場合などに有効である。

【０１３６】

【発明の効果】上記に説明したとおり、請求項１または
請求項９にかかる発明では、分類されたパケットを第１
のキューに挿入する際に、このパケットに対応する疑似
パケットを作成して第２のキューに挿入し、この第２の
キューに挿入した疑似パケットがスケジューラの処理対
象とされた際に、当該疑似パケットに代えて第１のキュ
ーのパケットを第２のキューからの出力として処理する
よう構成したので、少なくとも第２のキューの品質を第
１のキューの品質として確保もって品質を予約したため
に却って遅延時間やサービス品質が低下する品質予約異
常に効率良く対処できるという効果を奏する。

【０１３７】また、請求項２または請求項１０にかかる
発明では、第１のキューに挿入するパケットと該パケッ
トに対応する第２のキューに挿入する疑似パケットとを
相互に関連づけるよう構成したので、パケットまたは疑
似パケットのいずれかがスケジューリング対象とされた
際に、他のキューに所在する当該パケットまたは疑似パ
ケットに関連する疑似パケットまたはパケットを容易に
特定し、もってパケットおよび疑似パケットのスケジュ
ーリングを容易にできるという効果を奏する。

【０１３８】また、請求項３または請求項１１にかかる
発明では、疑似パケットが先にスケジューラの処理対象
とされた場合には、この疑似パケットに対応する第１の
キューのパケットを第２のキューからの出力として処理
し、第１のキューに挿入されたパケットの方が先にスケ
ジューラの処理対象とされた場合には、当該パケットを
処理するとともに疑似パケットを無効化するよう構成し
たので、少なくとも第２のキューの品質を第１のキュー
で保証しつつ、不要な疑似パケットを迅速に処分できる
という効果を奏する。

【０１３９】また、請求項４にかかる発明では、第１の
キューに挿入するパケットに、該パケットが実パケット
であることを示す識別情報と、該疑似パケットへのリン
ク情報とを付加するよう構成したので、このパケットが
先にスケジューリング対象とされた場合に対応する疑似
パケットの廃棄を容易におこなうことができ、また第２
のキューに挿入する疑似パケットには、疑似パケットで
あることを示す識別情報と、該疑似パケットに対応する
実パケットへのリンク情報とを付加するよう構成したの
で、疑似パケットが先にスケジューリング対象とされた
場合に、この疑似パケットに対応するパケットを迅速に
取り出すことができるという効果を奏する。

【０１４０】また、請求項５または請求項１２にかかる
発明では、パケットと該パケットに対応する疑似パケッ
トとを関連づけるのではなく、疑似パケットと第１のキ
ューとを関連づけることよう構成したので、パケットと
疑似パケットの関連づけにかかわる処理負担を軽減し、
比較的容易にハードウエア化することができるという効
果を奏する。

【０１４１】また、請求項６または請求項１３にかかる
発明では、第１のキューに挿入されたパケットがスケジ
ューラの処理対象とされた場合には、疑似パケットを無
視して当該パケットの処理のみをおこなうよう構成した
ので、疑似パケットにかかわる処理を軽減することがで
きるという効果を奏する。

【０１４２】また、請求項７にかかる発明では、第２の
キューに挿入する疑似パケットには、対応する第１のキ
ューのパケットへのポインタではなく第１のキューへの
リンク情報を付加し、また第１のキューに挿入するパケ
ットには疑似パケットへのポインタを付加しないよう構
成したので、パケットと疑似パケットのリンクにかかわ
る処理負担を軽減できるという効果を奏する。

【０１４３】また、請求項８または請求項１４にかかる
発明では、疑似パケットをベストエフォートキューに挿
入するよう構成したので、各予約キューの品質として少
なくともベストエフォートキューの品質を確保できると
いう効果を奏する。

【図面の簡単な説明】

【図１】実施の形態１にかかる完全バブルキューイング
の処理概念を示す図である。

【図２】実施の形態１にかかるルータおよび出力インタ
ーフェース部の構成を示す機能ブロック図である。

【図３】図１に示した予約キュー内の実パケットとＢＥ
Ｓキュー内のバブルとの対応関係を示す図である。

【図４】図１に示した予約キュー内の実パケットおよび
ＢＥＳキュー内のバブルの具体的なデータ構造の一例を
示す図である。

【図５】図１に示した完全バブルキューイングによるパ
ケットキューイング時の処理手順を示すフローチャート
である。

【図６】図１に示した完全バブルキューイングによるパ
ケットキューイング時の処理手順を示すフローチャート
である。

【図７】図１に示した完全バブルキューイングによるパ
ケットの出力時の処理手順を示すフローチャートであ
る。

【図８】実施の形態２にかかる部分バブルキューイング
の処理概念を示す図である。

【図９】図８に示した予約キュー内の実パケットとＢＥ
Ｓキュー内のバブルとの対応関係を示す図である。

【図１０】図８に示した予約キュー内の実パケットおよ
びＢＥＳキュー内のバブルの具体的なデータ構造の一例
を示す図である。

【図１１】図８に示した部分バブルキューイングによる
パケットキューイング時の処理手順を示すフローチャー
トである。

【図１２】図８に示した部分バブルキューイングによる
パケットキューイング時の処理手順を示すフローチャー
トである。

【図１３】図８に示した部分バブルキューイングによる
パケットの出力時の処理手順を示すフローチャートであ
る。

【図１４】従来におけるルータをモデル化した一例を示
すブロック図である。

【図１５】従来におけるパケット廃棄技術を説明するた
めの説明図である。

【符号の説明】

１１ コンフォーマンスチェック １２ ＢＥＳ（ベストエフォート）のＲＥＤ １３ 予約キュー １４ ＢＥＳキュー ２０ ルータ ２１ 入力インターフェース部 ２２ ルーティング処理部 ２３ 出力インターフェース部 ２３ａ クラシファイア ２３ｂ パケット廃棄部 ２３ｃ 出力キュー ２３ｄ リシェーパ ２３ｅ リミッタ ２３ｆ スケジューラ １４０ ルーティング処理部 １４１ クラシファイア １４１ａ，１４１ｂ，１４１ｃ フィルタ １４２ パケット廃棄部 １４３ａ，１４３ｂ，１４３ｃ 予約キュー １４３ｄ ＢＥＳキュー １４４ スケジューラ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 冨川 真弓 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 Ｆターム(参考） 5K030 GA02 GA11 HA08 HB01 HB02 HB16 JA11 KA13 KX12 KX18 LB05 LC02 LC06 LC15

Claims (14)

【特許請求の範囲】
1. 【請求項１】 入力パケットを分類する分類手段と、こ
   の分類手段によって分類されたパケットをそれぞれ蓄積
   する複数のキューと、該複数のキューに蓄積されたパケ
   ットの中からいずれかのパケットを選択して出力するス
   ケジューラとを有するパケット処理装置において、 前記分類手段により分類されたパケットを第１のキュー
   に挿入する際に、このパケットに対応する疑似パケット
   を作成して第２のキューに挿入する疑似パケット入力手
   段と、 前記疑似パケット入力手段により第２のキューに挿入さ
   れた疑似パケットが前記スケジューラの処理対象とされ
   た際に、当該疑似パケットに代えて前記第１のキューの
   パケットを第２のキューからの出力として処理する処理
   手段と、 を備えたことを特徴とするパケット処理装置。
2. 【請求項２】 前記疑似パケット入力手段は、前記第１
   のキューに挿入するパケットと該パケットに対応する前
   記第２のキューに挿入する疑似パケットとを相互に関連
   づけることを特徴とする請求項１に記載のパケット処理
   装置。
3. 【請求項３】 前記処理手段は、前記疑似パケットが該
   疑似パケットに対応する前記第１のキューに挿入された
   パケットよりも先にスケジューラの処理対象とされた場
   合には、当該疑似パケットに対応する前記第１のキュー
   のパケットを第２のキューからの出力として処理し、前
   記疑似パケットよりも該疑似パケットに対応する前記第
   １のキューに挿入されたパケットの方が先にスケジュー
   ラの処理対象とされた場合には、当該パケットを処理す
   るとともに前記疑似パケットを無効化することを特徴と
   する請求項２に記載のパケット処理装置。
4. 【請求項４】 前記第１のキューに挿入するパケット
   は、該パケットが実パケットであることを示す識別情報
   と、該疑似パケットへのリンク情報とを有し、前記第２
   のキューに挿入する疑似パケットは、疑似パケットであ
   ることを示す識別情報と、該疑似パケットに対応する実
   パケットへのリンク情報とを有することを特徴とする請
   求項２または３に記載のパケット処理装置。
5. 【請求項５】 前記疑似パケット入力手段は、前記第２
   のキューに挿入する疑似パケットと前記第１のキューと
   を関連づけることを特徴とする請求項１に記載のパケッ
   ト処理装置。
6. 【請求項６】 前記処理手段は、第２のキューの前記疑
   似パケットがスケジューラの処理対象とされた際に、前
   記第１のキューにパケットが存在する場合には、前記第
   １のキューの先頭に所在するパケットを第２のキューか
   らの出力として処理し、前記疑似パケットに対応する前
   記第１のキューにパケットが存在せず、かつ、前記第２
   のキューの次のパケットが存在する場合には、そのパケ
   ットをスケジューラの処理対象とし、前記疑似パケット
   に対応する前記第１のキューにパケットが存在せず、か
   つ、前記第２のキューの次のパケットが存在しない場合
   には、再スケジューリングをおこなうことを特徴とする
   請求項５に記載のパケット処理装置。
7. 【請求項７】 前記第２のキューに挿入する疑似パケッ
   トは、疑似パケットであることを示す識別情報と、前記
   第１のキューへのリンク情報とを有することを特徴とす
   る請求項５または６に記載のパケット処理装置。
8. 【請求項８】 前記複数のキューは、出力バンド幅を予
   約した複数の予約キューおよびベストエフォートキュー
   からなり、前記第１のキューは前記複数の予約キューの
   いずれかに対応し、前記第２のキューは前記ベストエフ
   ォートキューに対応することを特徴とする請求項１〜７
   のいずれか一つに記載のパケット処理装置。
9. 【請求項９】 入力パケットを分類し、分類したパケッ
   トをそれぞれ複数のキューに蓄積し、該複数のキューに
   蓄積されたパケットの中からいずれかのパケットをスケ
   ジューラによって選択して出力するパケット処理方法に
   おいて、 前記分類したパケットを第１のキューに挿入する際に、
   このパケットに対応する疑似パケットを作成して第２の
   キューに挿入する疑似パケット入力工程と、 前記疑似パケット入力工程において第２のキューに挿入
   された疑似パケットが前記スケジューラの処理対象とさ
   れた際に、当該疑似パケットに代えて前記第１のキュー
   のパケットを第２のキューからの出力として処理する処
   理工程と、 を含むことを特徴とするパケット処理方法。
10. 【請求項１０】 前記疑似パケット入力工程は、前記第
    １のキューに挿入するパケットと該パケットに対応する
    前記第２のキューに挿入する疑似パケットとを相互に関
    連づけることを特徴とする請求項９に記載のパケット処
    理方法。
11. 【請求項１１】 前記処理工程は、前記疑似パケットが
    該疑似パケットに対応する前記第１のキューに挿入され
    たパケットよりも先にスケジューラの処理対象とされた
    場合には、当該疑似パケットに対応する前記第１のキュ
    ーのパケットを第２のキューからの出力として処理し、
    前記疑似パケットよりも該疑似パケットに対応する前記
    第１のキューに挿入されたパケットの方が先にスケジュ
    ーラの処理対象とされた場合には、当該パケットを処理
    するとともに前記疑似パケットを無効化することを特徴
    とする請求項１０に記載のパケット処理方法。
12. 【請求項１２】 前記疑似パケット入力工程は、前記第
    ２のキューに挿入する疑似パケットと前記第１のキュー
    とを関連づけることを特徴とする請求項９に記載のパケ
    ット処理方法。
13. 【請求項１３】 前記処理工程は、第２のキューの前記
    疑似パケットがスケジューラの処理対象とされた際に、
    前記第１のキューにパケットが存在する場合には、前記
    第１のキューの先頭に所在するパケットを第２のキュー
    からの出力として処理し、前記疑似パケットに対応する
    前記第１のキューにパケットが存在せず、かつ、前記第
    ２のキューの次のパケットが存在する場合には、そのパ
    ケットをスケジューラの処理対象とし、前記疑似パケッ
    トに対応する前記第１のキューにパケットが存在せず、
    かつ、前記第２のキューの次のパケットが存在しない場
    合には、再スケジューリングをおこなうことを特徴とす
    る請求項１２に記載のパケット処理装置。
14. 【請求項１４】 前記複数のキューは、出力バンド幅を
    予約した複数の予約キューおよびベストエフォートキュ
    ーからなり、前記第１のキューは前記複数の予約キュー
    のいずれかに対応し、前記第２のキューは前記ベストエ
    フォートキューに対応することを特徴とする請求項９〜
    １３のいずれか一つに記載のパケット処理方法。