JP3879754B2 - 帯域制御装置およびプログラム - Google Patents

Description

本発明は、パケット通信網に用いて好適な帯域制御装置およびプログラムに関する。

パケット通信網においては、通信網に接続される端末のインタフェースそのものに対して通信帯域の制限が設定されている。また、当該端末を介して送信されるパケットを複数のクラス（例えばパケットの用途）のうち何れかに分類し、これらクラス毎に通信帯域を所定の最大値以下に制限し、あるいは所定の保証帯域以上の通信帯域を確保する場合も多い。例えば、特許文献１においては、複数のクラスに対して帯域制限を施しつつパケットを送信する技術が開示されている。同文献においては、まずパケットのクラス毎にパケットキュー（順次送信すべきパケットのリスト）が作成される。そして、新たなパケットが発生すると、そのパケットの属するクラスに応じて送信予定時刻が決定され、該パケットはその送信予定時刻とともに当該クラスのパケットキューに追加される。また、全クラスに共用される優先送信予約キューおよび非優先送信予約キューが作成され、上記各パケットキューから出力されたパケットが当該優先（または非優先）送信予約キューにおいて送信予定時刻順にソートされる。そして、この優先送信予約キューに記憶されたパケットが送信予定時刻順に、順次送信されることになる。

特開２００２−３６８７９９号公報

しかし、上記特許文献１記載の技術によれば、各パケットは、各クラスのパケットキューと優先（または非優先）送信予約キューとの２段階に渡って蓄積された後に送信されるため、端末に実装すべきメモリ容量が増大し、制御が複雑化するという問題がある。さらに、当該技術においては端末のインタフェース全体の通信帯域の制限値を指定することはできないという問題がある。すなわち、インタフェース全体の通信帯域の制限値は、各クラスの通信帯域の制限値の総和に等しくなる。仮に、インタフェース全体の通信帯域をこの総和よりも低い値に設定すべき場合には、上記優先（または非優先）送信予約キューの後段にリーキーバケットなどの帯域制御手段をさらに設ける必要があり、所要メモリ容量が一層増大し、制御が一層複雑になる。
この発明は上述した事情に鑑みてなされたものであり、メモリ容量を抑制しつつ複数のクラス毎に帯域保証および帯域制限を付与することができ、しかも端末のインタフェース全体の通信帯域を各クラスの帯域制限とは独立して制限することのできる帯域制御装置およびプログラムを提供することを目的としている。

上記課題を解決するため本発明にあっては、下記構成を具備することを特徴とする。なお、括弧内は例示である。
請求項１記載の帯域制御装置にあっては、複数のクラスのうち何れかに属するパケットを通信網に送信するにあたって、前記各クラス毎に帯域制限または帯域保証を行う帯域制御装置において、前記通信網にパケットを送信する送信装置の通信帯域を当該送信装置に対して許可された許容帯域幅（Ｌs）以下に抑制するために、次に該送信装置からパケットを送信できる最先時刻であるインタフェース制限時刻（ＩＲＬ）を記憶する第１のレジスタ（３２）と、前記各クラス毎に設けられ、対応するクラスの許容帯域以下に当該クラスの通信帯域を抑制するために次に当該クラスのパケットを送信できる最先時刻であるクラス制限時刻（ＲＬ−ｍ）を記憶する第２のレジスタ（４２−ｍ）と、前記各クラス毎に設けられ、対応するクラスの保証帯域以上の通信帯域を当該クラスに付与するために次に当該クラスのパケットを送信すべき最終時刻であるクラス保証時刻（ＲＧ−ｍ）を記憶する第３のレジスタ（４４−ｍ）と、前記各クラスの中から、これらクラスの前記クラス制限時刻（ＲＬ−ｍ）および前記クラス保証時刻（ＲＧ−ｍ）に基づいて、パケットを送信すべき一のクラスを送信対象クラスに決定するクラス決定手段（ＳＰ３０〜ＳＰ４６）と、該送信対象クラスに属するパケットを送信する送信手段（１４，ＳＰ４８）と、該送信対象クラスに属するパケットのデータ量に基づいて、前記インタフェース制限時刻（ＩＲＬ）と、該送信対象クラスのクラス制限時刻（ＲＬ−ｍ）と、該送信対象クラスのクラス保証時刻（ＲＧ−ｍ）とを再計算し、これらの再計算結果を前記第１ないし第３のレジスタに格納する再計算手段（ＳＰ５０）とを有することを特徴とする。
さらに、請求項２記載の構成にあっては、請求項１記載の帯域制御装置において、前記クラス決定手段（ＳＰ３０〜ＳＰ４６）は、前記各クラスのうち前記クラス保証時刻（ＲＧ−ｍ）が現在時刻（ＳＣ）よりも遅れているクラスが検出された（ＳＰ３４において「ＮＯ」と判定された）場合には、前記インタフェース制限時刻（ＩＲＬ）にかかわらず該検出されたクラスを前記送信対象クラスとして決定する一方、前記クラス保証時刻（ＲＧ−ｍ）が現在時刻（ＳＣ）よりも遅れているクラスが存在しない（ＳＰ３４において「ＮＯ」と判定された）場合には、現在時刻（ＳＣ）が前記インタフェース制限時刻（ＩＲＬ）を越えていることを条件として、送信すべきパケットを有する（ＦＬ−ｍ＝１である）クラスであって現在時刻が前記クラス制限時刻（ＲＬ−ｍ）に達していないクラスの中から前記クラス保証時刻（ＲＧ−ｍ）が最先であるクラスを前記送信対象クラスとして決定することを特徴とする。
また、請求項３記載のプログラムにあっては、複数のクラスのうち何れかに属するパケットを通信網に送信するにあたって、前記各クラス毎に帯域制限または帯域保証を行うために処理装置によって実行される帯域制御プログラムにおいて、前記通信網にパケットを送信する送信装置の通信帯域を当該送信装置に対して許可された許容帯域幅（Ｌs）以下に抑制するために、次に該送信装置からパケットを送信できる最先時刻であるインタフェース制限時刻（ＩＲＬ）を第１のレジスタ（３２）から読出す第１の読出し過程（ＳＰ３６）と、対応するクラスの許容帯域以下に当該クラスの通信帯域を抑制するために、次に当該クラスのパケットを送信できる最先時刻であるクラス制限時刻（ＲＬ−ｍ）を、前記各クラス毎に設けられた第２のレジスタ（４２−ｍ）から読出す第２の読出し過程（ＳＰ４４）と、対応するクラスの保証帯域以上の通信帯域を当該クラスに付与するために、次に当該クラスのパケットを送信すべき最終時刻であるクラス保証時刻（ＲＧ−ｍ）を、前記各クラス毎に設けられた第３のレジスタ（４４−ｍ）から読出す第３の読出し過程（ＳＰ３０，ＳＰ３８）と、前記各クラスの中から、これらクラスの前記クラス制限時刻（ＲＬ−ｍ）および前記クラス保証時刻（ＲＧ−ｍ）に基づいて、パケットを送信すべき一のクラスを送信対象クラスに決定するクラス決定過程（ＳＰ３０〜ＳＰ４６）と、該送信対象クラスに属するパケットを送信する送信過程（ＳＰ４８）と、該送信対象クラスに属するパケットのデータ量に基づいて、前記インタフェース制限時刻（ＩＲＬ）と、該送信対象クラスのクラス制限時刻（ＲＬ−ｍ）と、該送信対象クラスのクラス保証時刻（ＲＧ−ｍ）とを再計算し、これらの再計算結果を前記第１ないし第３のレジスタに格納する再計算手段（ＳＰ５０）とを実行することを特徴とする。
さらに、請求項４記載の構成にあっては、請求項３記載のプログラムにおいて、前記クラス決定過程（ＳＰ３０〜ＳＰ４６）は、前記各クラスのうち前記クラス保証時刻（ＲＧ−ｍ）が現在時刻（ＳＣ）よりも遅れているクラスが検出された（ＳＰ３４において「ＮＯ」と判定された）場合には、前記インタフェース制限時刻（ＩＲＬ）にかかわらず該検出されたクラスを前記送信対象クラスとして決定する一方、前記クラス保証時刻（ＲＧ−ｍ）が現在時刻（ＳＣ）よりも遅れているクラスが存在しない（ＳＰ３４において「ＮＯ」と判定された）場合には、現在時刻（ＳＣ）が前記インタフェース制限時刻（ＩＲＬ）を越えていることを条件として、送信すべきパケットを有する（ＦＬ−ｍ＝１である）クラスであって現在時刻が前記クラス制限時刻（ＲＬ−ｍ）に達していないクラスの中から前記クラス保証時刻（ＲＧ−ｍ）が最先であるクラスを前記送信対象クラスとして決定することを特徴とする。

このように本発明によれば、各クラスのクラス制限時刻およびクラス保証時刻に基づいて、パケットを送信すべき一のクラスを送信対象クラスに決定し、該送信対象クラスに属するパケットを送信するとともに、該送信対象クラスに属するパケットのデータ量に基づいて、インタフェース制限時刻と、該送信対象クラスのクラス制限時刻と、該送信対象クラスのクラス保証時刻とを再計算するから、複数段階に渡ってパケットキューを設ける必要がなくなり、メモリ容量を抑制しつつ複数のクラス毎に帯域保証および帯域制限を付与することができる。さらに、インタフェース制限時刻は各クラスのクラス保証時刻およびクラス制限時刻とは独立して設定できるから、端末全体の通信帯域を任意の許容帯域幅以内に抑制することができる。

1．実施例のハードウエア構成
次に、本発明の一実施例のルータ装置の構成を図１を参照し説明する。
図１において１００は本実施例のルータ装置であり、その内部に設けられたＣＰＵ２は、フラッシュメモリ４に格納された制御プログラムに基づいて、バス１０を介してルータ装置１００内の各部を制御する。６はＲＡＭであり、ＣＰＵ２のワークメモリとして使用される。８はタイマであり、現在時刻を計時するとともに、必要に応じてＣＰＵ２に対してタイマ割込みを発生させる。１２はＬＡＮインタフェースであり、図示せぬローカルエリアネットワーク(ＬＡＮ)に接続される。このＬＡＮには、Ｗｅｂサーバ、クライアントコンピュータ等が必要に応じて接続される。１４はＷＡＮインタフェースであり、モデム２４を介してインターネット２６に接続される。１６はＶｏＩＰ（Voice over IP）アダプタであり、電話機２２から受信される音声信号および制御信号をＩＰパケットに変換しＷＡＮインタフェース１４を介して送信するとともに、ＷＡＮインタフェース１４を介して受信したＩＰパケットを音声信号または制御信号に変換し電話機２２に供給する。

2．実施例のデータ構成
次に、本実施例において使用される各種データを図２を参照し説明する。図において３０はシステムカウンタであり、逐次更新される現在時刻ＳＣを記憶する。３２はインタフェース帯域制限レジスタであり、インタフェース帯域制限時刻データＩＲＬを記憶する。ここで、この制限時刻データＩＲＬについて説明しておく。ルータ装置１００がＷＡＮインタフェース１４を介してインターネット２６に送信できるデータの通信帯域すなわちデータの伝送速度には制限がある。この制限（インタフェース許容帯域幅）を「Ｌs ビット毎秒」とする。いま、ある時刻ｔ1に「Ｐビット」のＩＰパケットの送信を開始したのであれば、当該ＩＰパケットのために確保しておくべき時間は「Ｐ／Ｌs」である。従って、現在時刻ＳＣが「ｔ2＝ｔ1＋Ｐ／Ｌs」に達するまで、原則として他のＩＰパケットをＷＡＮインタフェース１４から送信することはできない。制限時刻データＩＲＬは、この時刻ｔ2に相当するデータである。３４はパケットバッファ領域であり、ＷＡＮインタフェース１４またはＶｏＩＰアダプタ１６を介して供給されたＩＰパケットの実体がここに格納される。

次に、４０−ｍ（但しｍ＝１，２，…，ｎ）はクラス領域であり、送信されるＩＰパケットのクラス毎に確保されている。ここで、「クラス」とは、パケットの用途（例えば、ＶｏＩＰ用、ＳＴＭＰサービス用、ＨＴＴＰサービス用等）、あるいは送信元の装置（ＶｏＩＰアダプタ１６、サーバ、クライアントコンピュータ）のローカルＩＰアドレス等に応じてＩＰパケットを分類したものである。クラス領域４０−ｍの内部において４２−ｍは帯域制限レジスタであり、クラス帯域制限時刻データＲＬ−ｍを記憶する。上述したようにルータ装置１００全体として通信帯域が制限されているのと同様に、各クラスに対しても通信帯域が制限されている。クラスｍに対する制限（クラス許容帯域幅）を「Ｌcm ビット毎秒」とし、ある時刻ｔ1に当該クラスｍの「Ｐビット」のＩＰパケットの送信を開始したのであれば、当該クラスの他のＩＰパケットは、現在時刻ＳＣが「ｔ3＝ｔ1＋Ｐ／Ｌcm」に達するまで送信することはできない。制限時刻データＲＬ−ｍは、この時刻ｔ3に相当するデータである。

次に、４４−ｍは帯域保証レジスタであり、クラス帯域保証時刻データＲＧ−ｍを記憶する。クラスの種類によっては、ある程度の通信帯域を最低限保証しておくべき場合がある。例えば、ＶｏＩＰによる電話通信がこれに該当する。ＶｏＩＰにおいては、ＵＤＰ／ＩＰプロトコルが採用されているが、このプロトコルではパケットの再送制御が行われない。従って、ある時刻にある音声データのＩＰパケットを送信しようとした際に、そのＩＰパケットを送信できなかったときは、その音声データは相手側に届くことがない。このように、ＶｏＩＰにおいてはＩＰパケットが全く送信できない状況になると通信品質が著しく悪化するという問題が生じるため、ある程度の通信帯域を最低限保証しておくことが望ましいのである。クラスｍに対して保証されている帯域幅（クラス保証帯域幅）を「Ｇcm ビット毎秒」とし、ある時刻ｔ1に当該クラスｍの「Ｐビット」のＩＰパケットの送信を開始したのであれば、次にクラスｍのＩＰパケットを送信すべき時刻は、遅くとも「ｔ4＝ｔ1＋Ｐ／Ｇcm」でなければならない。保証時刻データＲＧ−ｍは、この時刻ｔ4に相当するデータである。

４６−ｍはパケットキュー領域であり、パケットバッファ領域３４に格納されたＩＰパケットのうちクラスｍに属するＩＰパケットのポインタを要素とするリストを格納する。該リストにおいては、各要素は、対応するＩＰパケットの受信時刻順（これは送信順に等しい）にリンクされている。このリストを「パケットキューＣＵＥ−ｍ」という。４８−ｍは送信待ちフラグ領域であり、ここには送信待ちフラグＦＬ−ｍが格納される。送信待ちフラグＦＬ−ｍは、パケットキューＣＵＥ−ｍに少なくとも一の要素が含まれているときに“１”にされ、パケットキューＣＵＥ−ｍが空のときに“０”にされるフラグである。

3．実施例の動作
3．1．ＩＰパケットの受信処理
次に、本実施例の動作を説明する。
ＬＡＮインタフェース１２またはＶｏＩＰアダプタ１６を介して、ＷＡＮインタフェース１４から送信すべきＩＰパケットが受信されると、図３に示すＩＰパケット受信ルーチンが起動される。図３において処理がステップＳＰ１０に進むと、受信されたＩＰパケットの実体がパケットバッファ領域３４に格納される。次に、処理がステップＳＰ１１に進むと、当該ＩＰパケットの送信元のローカルＩＰアドレス、またはＩＰプロトコルの上位のプロトコル（ＴＣＰ、ＵＤＰ等）に応じて、当該ＩＰパケットが何れかのクラスに分類される。ここで、分類先のクラスの番号を「ｍ」とする。

次に、処理がステップＳＰ１２に進むと、クラスｍのパケットキューＣＵＥ−ｍの末尾に、先に受信したＩＰパケットのポインタを内容とする新たな要素が追加される。次に、処理がステップＳＰ１４に進むと、送信待ちフラグＦＬ−ｍが“０”であるか否か（先のステップＳＰ１２の直前までパケットキューＣＵＥ−ｍが空であったか否か）が判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳＰ１６に進み、送信待ちフラグＦＬ−ｍが“１”に変更される。これは、先のステップＳＰ１２において新たな要素が追加されたため、パケットキューＣＵＥ−ｍが空ではなくなったためである。次に処理がステップＳＰ１８に進むと、現在時刻ＳＣが保証時刻データＲＧ−ｍを越えているか否かが判定される。ここで「ＹＥＳ」と判定されると処理はステップＳＰ２０に進み、保証時刻データＲＧ−ｍが現在時刻ＳＣに変更される。なお、上記ステップＳＰ１４またはＳＰ１８において「ＮＯ」と判定されると、本ルーチンの処理は直ちに終了する。

ここで、上記ステップＳＰ２０において保証時刻データＲＧ−ｍを現在時刻ＳＣに変更する理由について説明しておく。保証時刻データＲＧ−ｍは、クラスｍのクラス保証帯域幅Ｇcmを確保するために定められていた値であるが、送信すべきＩＰパケットが元々存在しない場合にはクラス保証帯域幅Ｇcmを確保することができず、その必要もない。また、後述する処理においては、保証時刻データＲＧ−ｍが現在時刻ＳＣ未満である場合には、「クラスｍに対して保証すべき帯域幅が確保されていない異常な事態」が生じているものとみなされ、インタフェース許容帯域幅Ｌsを一時的に超過する場合であってもクラスｍのＩＰパケットが特に優先的に送信される。特に、保証時刻データＲＧ−ｍと現在時刻ＳＣとの差が大きい場合には、クラスｍのＩＰパケットが繰り返し優先的に送信されるような状況が生じる。しかし、上記ステップＳＰ１８が実行される場合とは、元々クラスｍのパケットキューＣＵＥ−ｍに要素が存在しなかった場合に限られるから、クラスｍのＩＰパケットをさほど優先して送信する必要はない。このため、保証時刻データＲＧ−ｍを現在時刻ＳＣに設定したものである。

3．2．送信スケジュール割込処理
ＣＰＵ２においては、所定時間毎に「送信スケジュール割込」なる割込が発生する。この割込が発生すると、図４に示す送信スケジュール割込処理ルーチンが起動される。図において処理がステップＳＰ３０に進むと、全てのクラスｘ（ｘ＝１，２，…，ｎ）の中から送信待ちフラグＦＬ−ｘが“１”である一または複数のクラスが検索され、これらの中から保証時刻データＲＧ−ｘが最小であるクラスが検索される。次に、処理がステップＳＰ３２に進むと、この検索されたクラスの番号が変数ｍに格納される。次に、処理がステップＳＰ３４に進むと、クラスｍの保証時刻データＲＧ−ｍが現在時刻ＳＣ未満であるか否かが判定される。

3．2．1．全クラスの保証帯域が確保されている場合
ステップＳＰ３４において「ＮＯ」と判定されると、処理はステップＳＰ３６に進む。なお、ステップＳＰ３４では、最小の保証時刻データであるＲＧ−ｍに対して「ＲＧ−ｍ＜ＳＣ」の条件が満たされるか否かが判断されるため、ここで「ＮＯ」と判定された場合は、ＩＰパケットの送信を必要とする全てのクラスｘについて「ＲＧ−ｘ＜ＳＣ」が成立することになり、現状では全クラスの保証帯域が確保されていることに他ならない。さて、ステップＳＰ３６においては、インタフェース帯域制限時刻データＩＲＬが現在時刻ＳＣ未満であるか否かが判定される。仮に制限時刻データＩＲＬが現在時刻ＳＣ未満であるときにＩＰパケットを送信すると、ＷＡＮインタフェース１４全体の許容帯域を越えた状態でＩＰパケットが伝送されることになるため、ここで「ＮＯ」と判定されると、本ルーチンの処理が直ちに終了する。

一方、ステップＳＰ３６において「ＹＥＳ」と判定されると、処理はステップＳＰ３８に進み、送信待ちフラグＦＬ−ｘが“１”であるクラス番号の集合が保証時刻データＲＧ−ｘの小さい順にソートされる。次に、処理がステップＳＰ４０に進むと、このソート結果がリストＬＳとしてＲＡＭ６内に格納される。次に、処理がステップＳＰ４２に進むと、リストＬＳの先頭の要素であるクラス番号が変数ｍに格納され、当該先頭の要素がリストＬＳから削除される。次に、処理がステップＳＰ４４に進むと、クラスｍの制限時刻データＲＬ−ｍが現在時刻ＳＣ未満であるか否かが判定される。ここで、制限時刻データＲＬ−ｍが現在時刻ＳＣ未満であれば、当該クラスｍに属するＩＰパケットを送信すると、クラスｍの許容帯域を越えることになるため、当該ＩＰパケットは送信することができない。かかる場合にはステップＳＰ４４において「ＮＯ」と判定され、処理はステップＳＰ４６に進む。

ステップＳＰ４６においては、リストＬＳが空であるか否かが判定される。ここで「ＮＯ」と判定されると、処理はステップＳＰ４２に戻り、リストＬＳの先頭の要素がリストＬＳから再び削除され、削除された要素であるクラス番号が変数ｍに格納される。以後、ステップＳＰ４４において「ＹＥＳ」と判定されるまで、リストＬＳの残りの要素に対して同ステップＳＰ４２，ＳＰ４４の処理が繰り返される。ここで、リストＬＳの全ての要素についてステップＳＰ４４の判定が実行され、最後の判定結果が「ＮＯ」であると、この時点でリストＬＳは空になっている筈であるから、ステップＳＰ４６において「ＹＥＳ」と判定され、本ルーチンの処理は終了する。かかる場合においては、ＷＡＮインタフェース１４全体では送信データ量は許容帯域の範囲内に抑制されている（先にステップＳＰ３６において「ＹＥＳ」と判定されている）ものの、個々のクラス毎に見れば各クラスの許容帯域内にデータ量を抑制できないため、結局送信可能なＩＰパケットは存在しないことになる。従って、ＩＰパケットの送信処理が行われないまま処理が終了する。

一方、ステップＳＰ４２〜ＳＰ４６のループが実行されている途中で何れかのクラスｍについて「ＲＬ−ｍ＜ＳＣ」の条件が充足されると、ステップＳＰ４４において「ＹＥＳ」と判定され、処理はステップＳＰ４８に進む。ここでは、パケットキューＣＵＥ−ｍの先頭の要素（ポインタ）によって指定されるＩＰパケットの送信が開始され、このパケットキューＣＵＥ−ｍの先頭の要素も削除される。そして、本ルーチンにおいては、ステップＳＰ４８においてＩＰパケットの送信が開始されると、ＩＰパケットの全ビットの送信が未完了の状態であっても、処理はステップＳＰ５０に進む。

ステップＳＰ５０においては、インタフェース帯域制限時刻データＩＲＬ、クラス帯域制限時刻データＲＬ−ｍおよびクラス帯域保証時刻データＲＧ−ｍが再計算され、これら再計算結果が対応するレジスタ３２，４２−ｍ，４４−ｍに格納される。なお、ステップＳＰ５０における具体的な再計算の数式については後述する。次に、処理がステップＳＰ５２に進むと、パケットキューＣＵＥ−ｍが空になったか否かが判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳＰ５４に進み、送信待ちフラグＦＬ−ｍが“０”に設定される。以上により、本ルーチンの処理が終了する。なお、本ルーチンの処理が終了したとしても、ＩＰパケットの送信は未だ完了していないため、ＷＡＮインタフェース１４においては、モデム２４を介して、該ＩＰパケットの内容が徐々にインターネット２６に出力される。そして、ＩＰパケットの送信が完全に終了すると、パケットバッファ領域３４において当該ＩＰパケットの実体が削除される。

3．2．2．保証帯域が確保されていないクラスが存在する場合
次に、ステップＳＰ３４において「ＹＥＳ」と判定された場合、すなわち「ＲＧ−ｍ＜ＳＣ」の条件が満たされた場合の処理を説明する。「ＲＧ−ｍ＜ＳＣ」の条件が満たされたということは、少なくともクラスｍに対しては保証帯域が確保されていないということに他ならない。ここでは、当該クラスｍに対して、上述したステップＳＰ４８〜ＳＰ５４の処理が直ちに実行され、クラスｍに係るＩＰパケットが送信される。この場合には、上述したステップＳＰ３６のように現在時刻ＳＣが制限時刻データＩＲＬを越えているか否かの判断が行われない。

従って、現在時刻ＳＣが制限時刻データＩＲＬ未満であるにもかかわらずＩＰパケットの送信処理が行われる可能性がある。かかる場合にはＩＰパケットの帯域幅は一時的にインタフェース許容帯域幅Ｌsを越えることもありうる。しかし、インタフェース許容帯域幅Ｌsは平均値として遵守すべき値であってピーク的にはさらに大きな帯域幅を有しても差し支えない場合が多い。このため、本実施例においては、何れかのクラスにおいて保証帯域が確保されていない状況が生じた場合には、一時的にインタフェース許容帯域幅Ｌsを越える場合であっても、当該クラスのＩＰパケットを直ちに送出することにしたものである。

3．2．3．ＩＲＬ，ＲＬ−ｍ，ＲＧ−ｍの再計算（ＳＰ５０）
次に、上記ステップＳＰ５０における制限時刻データＩＲＬ，ＲＬ−ｍおよび保証時刻データＲＧ−ｍの再計算方法を図５(a)〜(c)を参照し説明する。なお、これらの図は各時刻データの値を時刻軸上の位置によって表したものであり、ステップＳＰ５０による更新が実行される前の時刻データは各時刻データの名称の後に「０」を付し、更新後の時刻データは各時刻データの名称の後に「１」を付す。
図５(a)において、インタフェース帯域制限時刻データＩＲＬの更新値ＩＲＬ1は、下式（１）により計算される。

ＩＲＬ1 ＝ max（ＩＲＬ0, ＳＣ）＋Ｐ／Ｌs （１）

式（１）においてＰは送信されたパケットのデータ量（ビット）、Ｌsはインタフェース許容帯域幅（ビット毎秒）である。

通常の送信状態（ステップＳＰ３６以降が実行される場合）では「ＩＲＬ＜ＳＣ」の条件が必ず満たされた状態でＩＰパケットが送出されるため、更新後の制限時刻データＩＲＬ1は現在時刻ＳＣ（パケットの送信開始時刻に等しい）を基準とし、パケットデータ量Ｐとインタフェース許容帯域幅Ｌsとに基づいて決定すべきである。しかし、上記ステップＳＰ３４において「ＹＥＳ」と判定されステップＳＰ４８が直ちに実行された場合にあっては、「ＩＲＬ＞ＳＣ」の状態でＩＰパケットが送出され、ＷＡＮインタフェース１４の送信帯域幅がインタフェース許容帯域幅Ｌsをピーク的に越えている場合も考えられる。かかる場合には、平均値として許容帯域幅Ｌsを遵守する必要があるため、更新前の制限時刻データＩＲＬ0を基準として更新後の制限時刻データＩＲＬ1を決定すべきである。従って、本実施例においては、制限時刻データの更新値ＩＲＬ1は、「max（ＩＲＬ0, ＳＣ）」を基準として決定される。

次に、図５(b)において、クラス帯域制限時刻データＲＬ−ｍの更新値ＲＬ−ｍ1は、下式（２）により計算される。

ＲＬ−ｍ1 ＝ ＳＣ＋Ｐ／Ｌcm （２）

式（２）においてＬcmは、クラスｍの許容帯域幅（ビット毎秒）である。クラスｍのＩＰパケットは、制限時刻データＲＬ−ｍが現在時刻ＳＣ未満であるときにのみ送信されるため（ステップＳＰ４４参照）、制限時刻データＲＬ−ｍ1の決定に際して基準となりうるタイミングは現在時刻ＳＣのみであり、更新前の制限時刻データＲＬ−ｍ0は考慮する必要がない。

次に、図５(c)において、保証時刻データＲＧ−ｍの更新値ＲＧ−ｍ1は、下式（３）により計算される。

ＲＧ−ｍ1 ＝ min（ＲＧ−ｍ0, ＳＣ）＋Ｐ／Ｇcm （３）

式（３）においてＧcmはクラスｍの保証帯域幅（ビット毎秒）である。クラスｍのＩＰパケットは、通常は「ＲＧ−ｍ0＞ＳＣ」である状況において出力されるため、かかる場合は現在時刻ＳＣを基準として次の保証時刻データＲＧ−ｍ1を決定すると、全体としてクラス保証帯域幅Ｇcm以上の通信帯域をクラスｍに対して確保することができる。しかし、「ＲＧ−ｍ0＜ＳＣ」である状態（ステップＳＰ３４において「ＹＥＳ」と判定された状態）においてＩＰパケットが送信されたのであれば、その時点において短期的にはクラス保証帯域幅Ｇcmが確保されていないことになる。そこで、かかる場合には平均値としてクラス保証帯域幅Ｇcmを確保すべく、更新前の保証時刻データＲＧ−ｍ0を基準として更新値ＲＧ−ｍ1を決定すべきである。従って、本実施例においては、保証時刻データの更新値ＲＧ−ｍ1は、「min（ＲＧ−ｍ0, ＳＣ）」を基準として決定される。

4．変形例
本発明は上述した実施例に限定されるものではなく、例えば以下のように種々の変形が可能である。
(1)上記実施例においては、ＣＰＵ２上で動作するプログラムによって帯域制限および保証処理を実行したが、これらの処理と等価な処理をハードウエアによって実行してもよい。
(2)上記実施例においては、ＣＰＵ２上で動作するプログラムによって帯域制限および保証処理を実行したが、これらのプログラムのみをＣＤ−ＲＯＭ、フレキシブルディスク等の記録媒体に格納して頒布し、あるいは伝送路を通じて頒布することもできる。

本発明の一実施例のルータ装置１００のブロック図である。 本実施例のデータ構造図である。 ＩＰパケット受信ルーチンのフローチャートである。 送信スケジュール割込処理ルーチンのフローチャートである。 本実施例のタイミングチャートである。

符号の説明

２：ＣＰＵ、４：フラッシュメモリ、６：ＲＡＭ、８：タイマ、１０：バス、１２：ＬＡＮインタフェース、１４：ＷＡＮインタフェース、１６：ＶｏＩＰアダプタ、２２：電話機、２４：モデム、２６：インターネット、３０：システムカウンタ、３２：インタフェース帯域制限レジスタ、３４：パケットバッファ領域、４０−ｍ：クラス領域、４２−ｍ：帯域制限レジスタ、４６−ｍ：パケットキュー領域、４８−ｍ：送信待ちフラグ領域。

Claims (4)

1. 複数のクラスのうち何れかに属するパケットを通信網に送信するにあたって、前記各クラス毎に帯域制限または帯域保証を行う帯域制御装置において、
   前記通信網にパケットを送信する送信装置の通信帯域を当該送信装置に対して許可された許容帯域幅以下に抑制するために、次に該送信装置からパケットを送信できる最先時刻であるインタフェース制限時刻を記憶する第１のレジスタと、
   前記各クラス毎に設けられ、対応するクラスの許容帯域以下に当該クラスの通信帯域を抑制するために次に当該クラスのパケットを送信できる最先時刻であるクラス制限時刻を記憶する第２のレジスタと、
   前記各クラス毎に設けられ、対応するクラスの保証帯域以上の通信帯域を当該クラスに付与するために次に当該クラスのパケットを送信すべき最終時刻であるクラス保証時刻を記憶する第３のレジスタと、
   前記各クラスの中から、これらクラスの前記クラス制限時刻および前記クラス保証時刻に基づいて、パケットを送信すべき一のクラスを送信対象クラスに決定するクラス決定手段と、
   該送信対象クラスに属するパケットを送信する送信手段と、
   該送信対象クラスに属するパケットのデータ量に基づいて、前記インタフェース制限時刻と、該送信対象クラスのクラス制限時刻と、該送信対象クラスのクラス保証時刻とを再計算し、これらの再計算結果を前記第１ないし第３のレジスタに格納する再計算手段と
   を有することを特徴とする帯域制御装置。
2. 前記クラス決定手段は、前記各クラスのうち前記クラス保証時刻が現在時刻よりも遅れているクラスが検出された場合には、前記インタフェース制限時刻にかかわらず該検出されたクラスを前記送信対象クラスとして決定する一方、前記クラス保証時刻が現在時刻よりも遅れているクラスが存在しない場合には、現在時刻が前記インタフェース制限時刻を越えていることを条件として、送信すべきパケットを有するクラスであって現在時刻が前記クラス制限時刻に達していないクラスの中から前記クラス保証時刻が最先であるクラスを前記送信対象クラスとして決定することを特徴とする請求項１記載の帯域制御装置。
3. 複数のクラスのうち何れかに属するパケットを通信網に送信するにあたって、前記各クラス毎に帯域制限または帯域保証を行うために処理装置によって実行される帯域制御プログラムにおいて、
   前記通信網にパケットを送信する送信装置の通信帯域を当該送信装置に対して許可された許容帯域幅以下に抑制するために、次に該送信装置からパケットを送信できる最先時刻であるインタフェース制限時刻を第１のレジスタから読出す第１の読出し過程と、
   対応するクラスの許容帯域以下に当該クラスの通信帯域を抑制するために、次に当該クラスのパケットを送信できる最先時刻であるクラス制限時刻を、前記各クラス毎に設けられた第２のレジスタから読出す第２の読出し過程と、
   対応するクラスの保証帯域以上の通信帯域を当該クラスに付与するために、次に当該クラスのパケットを送信すべき最終時刻であるクラス保証時刻を、前記各クラス毎に設けられた第３のレジスタから読出す第３の読出し過程と、
   前記各クラスの中から、これらクラスの前記クラス制限時刻および前記クラス保証時刻に基づいて、パケットを送信すべき一のクラスを送信対象クラスに決定するクラス決定過程と、
   該送信対象クラスに属するパケットを送信する送信過程と、
   該送信対象クラスに属するパケットのデータ量に基づいて、前記インタフェース制限時刻と、該送信対象クラスのクラス制限時刻と、該送信対象クラスのクラス保証時刻とを再計算し、これらの再計算結果を前記第１ないし第３のレジスタに格納する再計算手段と
   を実行することを特徴とするプログラム。
4. 前記クラス決定過程は、前記各クラスのうち前記クラス保証時刻が現在時刻よりも遅れているクラスが検出された場合には、前記インタフェース制限時刻にかかわらず該検出されたクラスを前記送信対象クラスとして決定する一方、前記クラス保証時刻が現在時刻よりも遅れているクラスが存在しない場合には、現在時刻が前記インタフェース制限時刻を越えていることを条件として、送信すべきパケットを有するクラスであって現在時刻が前記クラス制限時刻に達していないクラスの中から前記クラス保証時刻が最先であるクラスを前記送信対象クラスとして決定することを特徴とする請求項３記載のプログラム。

Images