JP3386117B2 - マルチレイヤクラス識別通信装置と通信装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＩＳＯ参照モデル
のネットワーク層のＩＰネットワークに用いられるマル
チレイヤクラス識別通信装置と通信装置に関する。

【０００２】

【従来の技術】近年、インターネットはデファクトスタ
ンダード的に国際的なネットワークとして標準化されて
おり、ＴＣＰ／ＩＰ（Transmission Control Protocol
／Internet Protocol）がベースとして用いられてい
る。通常、ＯＳＩ参照モデルの７階層に当てはめれば、
ＩＰはネットワーク層として、ＴＣＰはトランスポート
層としての働きを行い、最下位層のイーサネットやトー
クンリングからＩＰに渡され、ＴＣＰからアプリケーシ
ョン層に渡されてデータの取得等が行われる。

【０００３】ここで、ルータは、ＬＡＮ間の中継装置と
して、リピータやブリッジとゲートウェイ間に配置さ
れ、通信回線から受け取ったフレームを蓄積し、フレー
ムのデータ内にある宛先ネットワークアドレスに従っ
て、適切な通信回線にフレームを転送する中継装置とし
て用いられている。

【０００４】

【発明が解決しようとする課題】従来のルータは、基本
的にパケット単位の優先制御を行わず、すべてのＩＰパ
ケットを公平に扱っている。ＩＰパケットは、ヘッダ部
にＩＰアドレス等を含み、ルータのバッファに滞留する
が、バッファからの読み出しは、ＦＩＦＯ（First In F
irst Out）方式による制御であるため、遅延優先制御は
ない。

【０００５】また、ＩＰパケットが一定の出力ポートに
集中すると、輻輳が発生し、ルータ内部のバッファで、
パケット廃棄が発生する。通常、どのパケットを廃棄す
るかの廃棄優先制御は無い。

【０００６】翻って、周知のＡＴＭ技術は、コネクショ
ンの概念（送信元、宛先を結ぶ経路をＶＰＩ／ＶＣＩ
（Virtual Path Identifier／Virtual Channel Identif
ier：仮想パス・仮想チャネル識別子）により明示的に
定義）を導入し、コネクション単位に必要なＱＯＳ（遅
延特性、廃棄率等の通信品質：Quality of Service）を
定義し、ネットワーク装置は各コネクションのＱＯＳを
満たすように優先制御を行う。

【０００７】（ＩＰ−ＱＯＳ）昨今、インターネット網
上に簡易に優先制御を実現する技術が検討されている。
代表的なものに、Ｉｎｔｓｅｒｖｅ／ＲＳＶＰ（Resour
ce Reservation SetupProtocol：ネットワークの帯域管
理を実現するプロトコル）や、Ｄｉｆｆ−Ｓｅｒｖ（Di
fferenciated Service：サービスの差別化）が挙げられ
る。Ｉｎｔｓｅｒｖｅ／ＲＳＶＰがＡＴＭのようなコネ
クションの概念を擬似的に導入するのに対し、Ｄｉｆｆ
−Ｓｅｒｖは極力パケット単体の情報から優先制御を実
現する技術である。

【０００８】Ｉｎｔｓｅｒｖｅ／ＲＳＶＰのような方式
は、妥当なコストでは大規模基幹網に適応できない（Sc
alabilityに欠ける）という課題を有しており、普及し
ていないのが現状である。これに対処するために考えら
れたＤｉｆｆ−Ｓｅｒｖは、（１）Ｓｃａｌａｂｌｅで
あること、（２）妥当なコストで実現可能ということ、
（３）ＯＣ−４８クラス（Optical Carrier：幹線用光
ファイバのインターフェースで伝送速度別に）の高速化
に対応できること、等が第一に考えられている。

【０００９】Ｄｉｆｆ−Ｓｅｒｖでは、ＡＴＭ−ＱＯＳ
のような定量的なサービス保証をあきらめて、Ｂｅｓｔ
−Ｅｆｆｏｒｔ（最善の効果）からみて、相対的な品質
差を設定し、簡易的にサービスの差別化を図る狙いがあ
り、ＩＥＴＦ（Internet Engineering Task Force：イ
ンターネットの問題点を解決するための組織）の仕様化
進行状況と、各ベンダー各社の対応状況をみても、非常
に現実的な解として受け入れられている。

【００１０】（Ｄｉｆｆ−Ｓｅｒｖ）Ｄｉｆｆ−Ｓｅｒ
ｖは、インターネット技術の規定を行うＩＥＴＦにて論
議されている。Ｄｉｆｆ−Ｓｅｒｖは、サービスレベル
の差別化を実現するための手段であり、ＱＯＳ「保証」
の手段ではない。あくまで（相対的な）優先制御の枠組
みになる。つまり、Ｄｉｆｆ−Ｓｅｒｖは、ＱＯＳクラ
スのフレームワークを定義するのみであり、各ＱＯＳク
ラスの詳細やクラス間のスケジューリング方式は、ベン
ダーマター、運用者マターとなっている。

【００１１】（Ｄｉｆｆ−Ｓｅｒｖにおけるサービスク
ラス）Ｄｉｆｆ−Ｓｅｒｖでは、（１）Expedited Forw
arding(Premium service)（ＥＦクラス）、（２）Assur
ed Forwarding Service（ＡＦ：前方保証クラス）,
（３）Best Effort Service（ＢＥ：最大効果クラス）
の３種類のトラヒック（サービスクラス）が規定されて
いる。

【００１２】（１）Expedited Forwarding （ＥＦ：前
方促進，プレミアム）クラスは、ＩＰ−ＣＢＲ（Consta
nt Bit Rate）のように、ＩＰ網上に仮想的な専用線を
提供するものである。従って、ＵＰＣ（Usage Paramete
r Control）やShaperも含んだ厳密な転送制御が必要と
なる。ＥＦクラスは、帯域保証サービスとして位置づけ
られるため、後述するAssured Forwarding Service（Ａ
Ｆクラス）や、Best Effort Service（ＢＥクラス）に
対して絶対的な優先度を持つ。

【００１３】（２）Assured Forwarding Service（Ａ
Ｆ）クラスは、Expedited Forwarding(Premium servic
e)（ＥＦ）クラスと異なり、あくまで（相対的な）優先
制御の枠組みになる。Assured Forwarding Serviceは、
４種類の遅延クラスと、３種類の廃棄クラスを有する。
遅延優先制御は、ネットワーク装置内におけるＩＰパケ
ットの転送順序に優先度を持たせることで実現され、例
えば、遅延に敏感なアプリケーションの転送遅延を下げ
る効果がある。廃棄制御はネットワーク装置内の輻輳発
生箇所において、パケットの廃棄に優先度を持たせるこ
とで実現される。

【００１４】（３）Best Effort Service（ＢＥクラ
ス）は、ＥＦ、ＡＦクラス以外のトラヒックが該当し、
サービスにおける最も下位の優先制御を受ける。

【００１５】上記によって、Ｄｉｆｆ−Ｓｅｒｖのアウ
トラインを説明したが、Ｄｉｆｆ−Ｓｅｒｖの勧告は未
だ流動的であり、上記の定義や運用方法が変更されるこ
とはありえる。

【００１６】そこで、本発明は、インターネットのＩＰ
パケットを扱うＡＴＭ網のネットワーク層において、Ｌ
ＡＮ間を接続するルータの機能に上記サービスクラスに
応じて、パラメータの変更のみで柔軟に対応可能であ
り、汎用性に優れたマルチレイヤクラス識別通信装置を
提供することを課題とする。

【００１７】

【課題を解決するための手段】本発明は、上記課題を解
決するためになされたもので、ＩＰ（Internet Protoco
l）パケットを、ネットワークサービス品質（Quality o
f Service：ＱＯＳ）に応じて制御する手段を有した装
置であり、下記機能を実現する手段を有することを特徴
とする。

【００１８】（１） 入力インタフェースにおいて、受
信したＩＰパケットのヘッダ情報、具体的にはＩＰヘッ
ダに代表されるレイヤ３情報、およびその上位レイヤに
相当するＴＣＰ／ＵＤＰヘッダに代表されるレイヤ４情
報の組合わせに基づいて、装置内におけるクラス識別子
を解決し、個々のＩＰパケットフローを装置内で取り扱
うサービス品質（Internet Protocol Quality of Servi
ce：ＩＰ−ＱＯＳ）コードを割当てる手段を有し、ＢＥ
クラス、遅延の４種類と廃棄の３種類のＡＦクラス、Ｅ
Ｆクラスの計１６種類にそれぞれ分けるために、ＣＡＭ
検索からＳＲＡＭアクセスすることにより、優先度とス
ケジューリングに関するＩＰ−ＱＯＳコードを割り当て
る。

【００１９】（２） 上記ＩＰ−ＱＯＳコード割り当て
（トラヒッククラスのmapping)については、汎用性をも
たせるために、ＩＰヘッダおよび、ＴＣＰヘッダ内容情
報の任意の組み合わせで、後述する図５に示すように、
優先度とフィルタリングによるクラス分けにより優先ト
ラヒックを規定できる手段を有する。

【００２０】（３） 送信側のクラス別スケジューリン
グ方式として、ＷＲＲＳ（WeightedRound Robin Schedu
ling：重み付け周回ロビンスケジューリング）と、固定
優先スケジューリングを共存させ、各ＩＰ−ＱＯＳクラ
スを固定優先で選択できるとともに、最小帯域指定も可
能とする手段を有する。

【００２１】（４） 受信側で解決したＩＰ−ＱＯＳコ
ードは、パケット（主信号）データとは独立に、ＩＰ−
ＱＯＳクラス決定部で処理するので、装置内で取り扱う
固定長のパケット情報格納セル（以下、便宜上“Ｏｂｊ
ｅｃｔ（オブジェクト）”と呼ぶこととする）に収容す
る手段を有する。

【００２２】（５） 宛先アドレスにスイッチするクロ
スバースイッチの入出力に備える入力インタフェース、
および出力インタフェースがＩＰ−ＱＯＳクラス分けに
応じて出力側でそのクラスに応じたスケジューリングを
行うように、相互に連動して動作することにより、前記
Ｏｂｊｅｃｔ内に収容されたＩＰ−ＱＯＳコードによ
り、所定の優先制御を行う手段を有する。

【００２３】（６） ＩＰ−ＱＯＳコード単位にクラス
分けされたＩＰパケットの群毎に、区別して処理するこ
とにより、同一クラスは同一処理が可能となって処理が
迅速になっていくという統計多重効果を得るために、複
数のＩＰフローを集約して共有できるクラスキュー管理
を行う手段を有する。

【００２４】（７） 入力インタフェース、および出力
インタフェースにおいて、ＩＰ−ＱＯＳコード単位にト
ラヒックを監視し、ＩＰ−ＱＯＳコード毎に廃棄処分可
能か否かも判断でき、過剰なトラヒックの規制を行う手
段を有する。

【００２５】また、本発明は、通信回線の複数の通信品
質のレベルを選択可能な入力インターフェースと出力イ
ンターフェースとを備えた通信装置において、前記入力
インタフェースは、入力するＩＰパケットからＩＰパケ
ットヘッダ情報とＴＣＰヘッダ情報とを抽出するＩＰパ
ケット受信部と、前記ＩＰパケットヘッダ情報を検索キ
ーとしてＩＰ−ＱＯＳコード（クラス識別子）解決メモ
リをアクセスして解決対象となるクラス識別子を取得す
るＩＰ−ＱＯＳクラス決定部と、前記ＩＰパケット受信
部より受信したＩＰパケットデータと前記ＩＰ−ＱＯＳ
クラス決定部において解決した該ＩＰパケットに対応す
るＩＰ−ＱＯＳクラスコードにより宛先特定の優先制御
を行う受信側スイッチインタフェース制御部と、前記優
先制御機能と送信要求を前記クラス識別子単位に前記出
力インターフェースカードに送出する受信側スイッチイ
ンタフェースとを備え、前記ＩＰ−ＱＯＳクラス決定部
は、前記ＩＰ−ＱＯＳクラス毎に設定された転送可能容
量を超える過剰なトラヒックの流入を監視し、転送可能
容量を超える場合は、該当するＩＰパケットを廃棄、あ
るいは、前記送信優先度を下げるポリシング（監視）制
御を行う手段を有していることを特徴とする。

【００２６】また、本発明は、通信回線の複数の通信品
質のレベルを選択可能な入力インターフェースと出力イ
ンターフェースとを備えた通信装置において、前記入力
インターフェースから送出された優先制御されたＩＰパ
ケットを受信する出力インタフェースは、受信した前記
ＩＰパケットを送信側ペイロードメモリに格納すると同
時に該ＩＰパケット情報を生成しＦＩＦＯメモリに書き
込む送信側スイッチインターフェースと、前記ＩＰパケ
ット情報内に収容されたＩＰ−ＱＯＳクラスコードに基
づいて、クラス毎にキューイングを行い優先的に送信要
求し且つＷＲＲ（Weighted Round Robin）方式に基づい
たスケジューリング機能により要求サービス品質を提供
する制御機能を有するＩＰ−ＱＯＳクラス別スケジュー
ラと、前記送信側スイッチインタフェースからのＩＰパ
ケットを前記ＩＰ−ＱＯＳクラス別スケジューラの優先
度でスケジューリングされた順序に従って送出する送信
側スイッチインタフェース制御部と、前記ＩＰパケット
を下位層のデータリンク層及びネットワークアクセス層
に送出するＩＰパケット送信部とからなることを特徴と
する。

【００２７】また、上記通信装置において、前記入力イ
ンタフェースに、受信した前記ＩＰパケットのヘッダ情
報(ＩＰヘッダに代表されるレイヤ３情報、およびその
上位レイヤに相当するＴＣＰ／ＵＤＰヘッダに代表され
るレイヤ４情報の組合わせ)から前記ＩＰパケット内に
おけるクラス識別子を解決し、個々のＩＰパケットフロ
ーを前記ＩＰ−ＱＯＳコードを割当てる割当手段を有す
ることを特徴とする。

【００２８】

【発明の実施の形態】本発明の実施形態について、図面
を参照して詳細に説明する。

【００２９】［第１の実施形態］ （１）構成の説明 図１は、本発明で適用するマルチレイヤクラス識別通信
装置の構成を示すブロック図である。本実施形態による
装置は、主として、入出力インタフェースカードと、Ｎ
×Ｎクロスバースイッチ（１ｇ）と、スイッチスケジュ
ーラ（１ｈ）から構成される。

【００３０】入力インタフェースラインカードは、ＩＰ
パケット受信部（１ａ）、受信側スイッチインタフェー
ス制御部（１ｂ）、受信側スイッチインタフェース（１
ｄ）、受信側ペイロードメモリ（１ｃ）、ＩＰ−ＱＯＳ
クラス決定（１ｅ）およびＩＰ−ＱＯＳコード解決メモ
リ（１ｆ）により構成される。

【００３１】出力インタフェースラインカードは、送信
側スイッチインタフェース（１ｊ）、送信側スイッチイ
ンタフェース制御部（１ｋ）、ＩＰ−ＱＯＳクラス別ス
ケジューラ（１ｍ）、クラス別パケット情報キューイン
グメモリ（１ｐ）、ＩＰパケット送信部（１ｑ）により
構成される。

【００３２】なお、ここで、入力インタフェースライン
カード及び出力インタフェースラインカードとしたの
は、送信元アドレスから宛先アドレスに交換するクロス
バースイッチ（１ｇ）にカード形式に各必要な部材を装
着したブロックを装着する意味であり、単にそれぞれ入
力及び出力インターフェースとしてもよい。また、マル
チレイヤクラス識別通信装置は、主にクロスバースイッ
チ（１ｇ）に加えて入出力インターフェースとスイッチ
スケジューラ（１ｈ）を備えたものである。また、クロ
スバースイッチ（１ｇ）及びこのクロスバースイッチ
（１ｇ）への切り換え制御するスイッチスケジューラ
（１ｈ）を欠いた簡潔な構成の通信装置の場合には、イ
ンターネットでＩＰパケットを扱いネットワーク層まで
をサポートするルータや、物理層とデータリンク層の機
能を備えパケットのフィルタリングなどを行うブリッジ
等が、本実施形態の機能やプログラムソフトウェアを備
えていてもよい。

【００３３】（入力インタフェースラインカード）入力
インタフェースラインカード（受信側）において、ＩＰ
パケット受信部（１ａ）は、ＯＳＩ参照モデルのレイヤ
４のトランスポート層のＴＣＰによりアプリケーション
層のパケットをＩＰパケットに分割して送出されたパケ
ット情報から、ＩＰパケットヘッダ情報と、およびその
上位レイヤに収容されるＴＣＰ／ＵＤＰヘッダ情報とを
抽出し、その情報をＩＰ−ＱＯＳクラス決定部（１ｅ）
に転送する。

【００３４】ここで、ＩＰパケット受信部（１ａ）で
は、ＩＰパケットから、受信したＩＰパケットの情報を
元にＣＡＭまたはＳＲＡＭエリアの内容によって定義さ
れている各種条件を検索し、その条件にかなったアクシ
ョンとしてそのＩＰパケットに対する、(i)Queueプライ
オリティ、(ii)廃棄/通過処理（フイルタリング）、(ii
i)ＳＷ優先/非優先処理、(iv)Diff servのＤＳＣＰ値の
付与など、の処理が導き出される仕組みを有している。

【００３５】ＩＰ−ＱＯＳクラス決定部（１ｅ）は、受
信したＩＰパケットのヘッダ情報（ＩＰヘッダに代表さ
れるレイヤ３情報、およびその上位レイヤに相当するＴ
ＣＰ／ＵＤＰヘッダに代表されるレイヤ４情報の組合わ
せ）を検索キーとして、ＩＰ−ＱＯＳコード（クラス識
別子）解決メモリ（１ｆ）をアクセスし、解決対象とな
るクラス識別子を取得し、受信側スイッチインタフェー
ス制御部（１ｂ）にＩＰ−ＱＯＳコードのクラス識別子
を通知する。

【００３６】また、ＩＰ−ＱＯＳクラス決定部（１ｅ）
は、ＩＰ−ＱＯＳクラス毎に設定された転送可能容量を
超えるような過剰なトラヒックの流入を監視し、転送可
能容量を超える場合は、該当する（ＩＰ−ＱＯＳコード
をもつ）パケットを廃棄、あるいは、転送優先度を下げ
る等のポリシング（監視）制御を行う手段を有してお
り、該パケットが属するＩＰ−ＱＯＳコード毎に割り当
てられた網リソース量に応じて転送パケットの送出頻度
を決定する。

【００３７】受信側スイッチインタフェース制御部（１
ｂ）は、ＩＰパケット受信部（１ａ）より受信したパケ
ットデータと、ＩＰ−ＱＯＳクラス決定部（１ｅ）にお
いて解決した該パケットに対応するＩＰ−ＱＯＳクラス
コードにより、クロスバースイッチ（１ｇ）に対して優
先制御を行う。

【００３８】受信側スイッチインタフェース（１ｄ）
は、送信要求をクラス単位および出力インターフェース
カード単位に管理しており、常に高優先の送信要求を優
先してスイッチスケジューラ（１ｈ）に送り、この優先
制御は、クロスバースイッチ（１ｇ）に対する受信側ペ
イロードメモリ（１ｃ）からの、パケット読み出しと対
応し、遅延優先制御として位置づけ、ＩＰパケットを宛
先アドレスを選択・接続するクロスバースイッチ（１
ｇ）に出力する。

【００３９】受信側ペイロードデータメモリ（１ｃ）
は、入力されたＩＰパケット情報を格納し、送出する際
に必要となる空きパケット情報を格納している。

【００４０】（出力インタフェースラインカード）送信
側スイッチインタフェース（１ｊ）は、クロスバースイ
ッチ（１ｇ）から受信したパケットデータを送信側ペイ
ロードメモリ（１ｉ）に格納すると同時に、該パケット
情報を生成し、ＦＩＦＯメモリ（１ｎ）に書き込む。左
記パケット情報は、装置内でパケット単位に定義した仮
想的な処理単位であり、以下、“オブジェクト”と呼ぶ
こととする。オブジェクトは、パケットデータを装置内
で逐一持ち回ることを避けるために定義しており、パケ
ットデータそのものではない。装置内では、左記オブジ
ェクトの受け渡しによって、パケット転送処理が実施さ
れることとしている。

【００４１】ＦＩＦＯ（１ｎ）は、送信側スイッチイン
タフェース（１ｊ）からのパケットヘッダ情報を先読み
先出しによって所定の遅延時間を保って送出する。

【００４２】ＩＰ−ＱＯＳクラス別スケジューラ（１
ｍ）は、オブジェクト内に収容されたＩＰ−ＱＯＳクラ
スコードに基づいて、クラス毎にキューイングを行う。
左記ＩＰ−ＱＯＳコードは、複数の遅延クラスおよび複
数の廃棄クラスに対応づけされ、遅延優先順位の高いキ
ューに格納されたオブジェクトが、優先的に送信側スイ
ッチインタフェース制御部（１ｋ）に送出される。ＩＰ
−ＱＯＳクラス別スケジューラ（１ｍ）は、ＷＲＲ（We
ighted Round Robin）方式に基づいたスケジューリング
機能により、要求サービス品質が提供されるべく制御す
る機能を有している。また、ＩＰ網上で、仮想的な専用
線を提供する特定クラス(Premium Serviceclass)に対し
ては、ＵＰＣ(Usage Parameter Control)やShaperも含
んだ厳密な転送制御が実施される。

【００４３】送信側スイッチインタフェース制御部（１
ｋ）は、送信側スイッチインタフェース（１ｊ）からの
ＩＰパケットをＩＰ−ＱＯＳクラス別スケジューラ（１
ｍ）の優先度等でスケジューリングされた順序に従って
ＩＰパケット送信部（１ｑ）に出力する。

【００４４】ＩＰパケット送信部（１ｑ）は、ＩＰパケ
ットを下位層のデータリンク層及びネットワークアクセ
ス層のイーサネットやトークンリングに出力する。

【００４５】（２）動作の説明 図２は、本発明を適用する装置の機能を示した説明図で
ある。図１で示した装置構成で、本発明で採用した優先
制御の方法例について説明する。

【００４６】まず、ＩＰ−ＱＯＳクラス決定部（１ｅ）
においては、ＩＰ−ＱＯＳクラスの解決のため、レベル
Ｌ３又はＬ４の所定情報をキーとして、ＣＡＭ／ＳＲＡ
Ｍをアクセスし、ＩＰ−ＱＯＳクラス（装置内のＱＯＳ
コード）を解決する。この場合、ＢＡクラス化／ＭＦク
ラス化の両者をサポートする。

【００４７】また、ＥＦクラスの追加と、ポリシング制
御に関し、解決したＩＰ−ＱＯＳクラス（ＥＦ／ＡＦ１
〜ＡＦ４／ＢＥ）に対するポリシング機能をサポートす
る。ポリシング制御の実態は、該クラス毎のトークン
と、送出パケット長の比較であり、トークンがデータ長
に達していない場合は、廃棄処理する。

【００４８】ＩＰ−ＱＯＳクラス決定部（１ｅ）から受
信側スイッチインタフェース制御部（１ｂ）へ送出され
るＩＰ−ＱＯＳコード（クラス識別子）であり、ＩＰ−
ＱＯＳコード解決メモリ（１ｆ）を用いて、例えば、遅
延、廃棄クラス種別として、（ＥＦ．Ｈ），（ＡＦ１〜
ＡＦ４．Ｈ／Ｍ／Ｌ），（ＢＥ．Ｈ／Ｍ／Ｌ）等により
１６種類（５×３＋１）に振り分けられる。そのＩＰ−
ＱＯＳコード（クラス識別子）は、受信側スイッチイン
タフェース制御部（１ｂ）と受信側スイッチインタフェ
ース（１ｄ）との間で、空きエリアのアドレスを取得す
る。

【００４９】また、ＩＰ−ＱＯＳクラス別スケジューラ
部（１ｍ）においては、ＩＰ−ＱＯＳクラス別スケジュ
ーラとして、受信側で解決したＩＰ−ＱＯＳクラス（装
置内ＱＯＳコード）に基づくスケジューリングとして、
実際は、高優先クラスのオブジェクトから、送信側スイ
ッチインタフェース制御部（１ｋ）に出力する処理の、
ＥＦ＞（ＡＦ１〜ＡＦ４／ＢＥ）を実行する。ただし、
（ＡＦ１〜ＡＦ４／ＢＥ）は、ＷＲＲによるスケジュー
リングを実行する。

【００５０】また、ＩＰ−ＱＯＳクラス別スケジューラ
部（１ｍ）においての廃棄制御について、オブジェクト
の引き落とし（drop）を生成するため、ＡＦ１〜ＡＦ４
／ＢＥは、Ｈ／Ｍ／Ｌの３クラスのしきい値と、バッフ
ァ長の比較により、廃棄制御（Drop Objectの生成）を
行い、ＥＦについては、Ｈクラスの１種類を追加してサ
ポートする。

【００５１】また、ＥＦクラスの追加、シェイピング
（Shaping）機能に関し、解決したＩＰ−ＱＯＳクラス
（ＥＦのみ対象）に対するシェイピング（Delay Schedu
le）機能が実行され、シェイピング制御の実態は、ポリ
シング制御と、同等のトークンバケット方式であり、該
クラス毎のトークンと、送出パケット長の大小比較（Co
mp(token length)）を行い、Tokenがlengthに達してい
ない場合は、送出待ちとなる。ＩＰ−ＱＯＳクラス別ス
ケジューラ部（１ｍ）はクラス別オブジェクトキユーイ
ングメモリＳＲＡＭ（１ｐ）を用いて、オブジェクトに
対するスケジューリングを行う。

【００５２】（優先制御）装置内のスイッチ制御におけ
る優先制御として、以下の４形態を想定する。

【００５３】受信側スイッチインタフェース制御部
（１ｂ）における装置内遅延クラスへのマッピング 装置内遅延クラスへのマッピングは、転送リクエストの
送出方法で、２クラス（Ｈ／Ｌ）の遅延優先制御を指定
→遅延クラス（６種類）に対応する。

【００５４】受信側スイッチインタフェース（１ｄ）は
パケットを出力ＩＦカード（ラインカード送信側）に転
送する前に、スイッチスケジューラ（１ｈ）に接続要求
(request)を発行する。スイッチスケジューラ（１ｈ）
は、各入力ラインカードからの転送要求を調停し、クロ
スバースイッチ（１ｇ）に対して、入出力パスの接続情
報を通知する。また、各入力ラインカード（受信側）に
対して、接続調停結果通知を発行する。

【００５５】受信側スイッチインタフェース（１ｄ）
は、requestをクラス単位および出力ＩＦカード単位に
管理しており、常に高優先のrequestを優先して、スイ
ッチスケジューラ（１ｈ）に送る。本優先制御は、クロ
スバースイッチ（１ｇ）に対する受信側ペイロードデー
タメモリ（１ｃ）からのパケット読み出しと対応し、遅
延優先制御として位置づけられる。

【００５６】装置内遅延クラスへのマッピングは、受信
側スイッチインタフェース（１ｄ）の前段に位置する受
信側スイッチインタフェース制御（１ｂ）がパケットの
トラヒッククラスに応じて、本優先度を決定する。図２
では、Ｄｉｆｆ−ｓｅｒｖに準拠したクラス数と整合を
とるため、パケットのトラヒッククラスとして、６種類
の遅延優先クラスを規定する。クロスバースイッチ（１
ｇ）に対する２種類（Ｈｉｇｈ／Ｌｏｗ）のクラスキュ
ーと対応づける例を示している。

【００５７】受信側ペイロードメモリメモリ（１ｃ）
に入力パケットを書き込む際の廃棄クラスへのマッピン
グ この廃棄クラスへのマッピング空きエリアのアドレス(f
ree page address)の取得処理において、３クラス（Ｈ
／Ｍ／Ｌ）の廃棄優先制御を指定する。こうして、廃棄
クラス（３種類）で、ＥＦのみ（種類）に対応する。

【００５８】入力パケットを受信側ペイロードデータメ
モリ（１ｃ）に書き込む際に、前段の受信側スイッチイ
ンタフェース制御部（１ｂ）は、受信側ペイロードデー
タメモリ（１ｃ）内の空きエリアのアドレス(free page
address)を取得し、左記アドレスにより、受信側ペイ
ロードデータメモリ（１ｃ）に書き込む。

【００５９】空きエリアのアドレス取得に関して、受信
側スイッチインタフェース（１ｄ）は、数種類の優先度
を有している。説明を簡易にするため、図２中では、３
クラス（高／中／低）＝（Ｈ／Ｍ／Ｌ）の廃棄クラスを
実装した例を示している。

【００６０】受信側ペイロードデータメモリ（１ｃ）の
空きエリアのメモリ量を監視し、予め決められた閾値
（高）より少ない時は、高優先のパケット書き込みのみ
許可する。閾値（低）より少ない時は高優先、中優先の
パケット書き込みのみ許可する。それ以外の場合は、ど
のクラスに対しても書き込みを許可する。本制御は、メ
モリ（１ｃ）に対する廃棄制御であり、トラヒッククラ
スの３種類の廃棄クラスと対応する。

【００６１】送信側ペイロードメモリ（１ｉ）から出
力パケットを読み出す際の優先制御（遅延優先制御） 送信側ペイロードデータメモリ（１ｉ）からのパケット
読み出しは、ＩＰ−ＱＯＳクラス別スケジューラ（１
ｍ）、送信側スイッチインタフェース制御（１ｋ）、送
信側スイッチインタフェース（１ｊ）により制御され
る。

【００６２】本装置の優先制御は、送信側ペイロードデ
ータメモリ（１ｉ）からのパケット読出順序の制御であ
り、遅延優先制御に対応する。左記遅延優先制御は、Ｉ
Ｐ−ＱＯＳコードにおける遅延クラス６種類と対応して
いる。

【００６３】送信側ペイロードメモリにスイッチから
転送されてきたパケットを書き込む際の優先制御（廃棄
優先制御） クロスバースイッチ（１ｇ）から転送されてくるパケッ
トは、送信側ペイロードメモリに書き込まれる。書き込
まれたパケットの諸情報は、オブジェクトとしてＩＰ−
ＱＯＳクラス別スケジューラ（１ｍ）に通知される。Ｉ
Ｐ−ＱＯＳクラス別スケジューラ（１ｍ）は、クラス単
位に送信側ペイロードデータメモリ内のキュー長を管理
しており、キュー長と廃棄クラスの閾値比較により、送
信側ペイロードメモリ内のパケットを廃棄するか否かの
判定を行う。

【００６４】従って、本制御は廃棄優先制御を実行す
る。左記廃棄優先制御はトラヒッククラスの廃棄クラス
と対応している。

【００６５】また、送信側スイッチインタフェース制御
部（１ｋ）では、２種類（送出／廃棄）のオブジェクト
によるパケット送出／廃棄処理を実行し、送出の場合、
ＦＳＵメモリに滞留しているパケットをリードコマンド
を発行して読み出して送出し、廃棄の場合、ＦＳＵメモ
リに滞留しているパケットをドロップコマンドを発行し
て廃棄する。

【００６６】（ＩＰ−ＱｏＳクラス決定部）図３は、Ｉ
Ｐ−ＱＯＳクラス決定部（１ｅ）の要部説明図を示した
ものである。図３を参照してＩＰ−ＱｏＳクラス決定部
の詳細に関して説明する。

【００６７】同図に示す通り、ＩＰ−ＱＯＳクラス決定
部（１ｅ）は、ヘッダ抽出部（３ａ）、ヘッダチェック
部（３ｂ）、ＩＰ−ＱＯＳコード検索部（３ｃ）、ポリ
シング制御部（３ｄ）、ＩＰ−ＱＯＳコード出力部（３
ｅ）、パラメータレジスタ制御部（３ｆ）から構成され
る。

【００６８】ＩＰヘッダ抽出部（３ａ）において、図９
に示すＩＰｖ４のＩＰヘッダとＴＣＰ／ＵＤＰヘッダの
フォーマットから、所定の情報を抽出し、左記に含まれ
る各フィールドを（ＩＰｄａｔａとして）ＩＰ−ＱＯＳ
コード検索部（３ｃ）に送出する。

【００６９】なお、図９において、 （１）細い斜線部（Ver）は、Ｃｈｅｃｋ対象となるフ
ィールドを示している。

【００７０】（２）粗い斜線部（TOS、Src IP Adress D
st,IP Adress, L4 Src Port,L4 DstPort）は、クラスを
特定するための（検索ｋｅｙ対象となる）フィールドを
示している。

【００７１】ここで、抽出される情報は、４ビット構成
のバージョン（Ｖｅｒ）、８ビットで構成されるサービ
スタイプ識別子（ＴＯＳ：Type of Service）、送信元
ＩＰアドレス(Src(Source) IP Address)、宛先ＩＰアド
レス(Dest(Destination) IPAddress)、レイヤ４ヘッダ
内のＬ４送信元ポート番号（L4 Src Port）、レイヤ４
ヘッダ内のＬ４宛先ポート番号（L4 Dst Port）であ
る。

【００７２】また、ＩＰヘッダ自体の大きさを示すのＩ
ＨＬ(Internet Header Length)、ＩＰヘッダとＩＰデー
タを加えたパケット全体を示すTotal LengthであるData
gramLength、フラグメントを復元する際の識別子を示す
Identification、３ビット構成のフラグＭ、１３ビット
で構成され、分割されたフラグメントがオリジナルデー
タの何処に位置しているのかを示すFragment Offset、
ネットワークに存在してもよい時間を示すTime to Liv
e、上位層のプロトコルを特定するProtocol、ＩＰヘッ
ダのチェックサムを示すHeader Checksumをそれぞれ示
している。

【００７３】ＩＰヘッダチェック部（３ｂ）は、ＩＰヘ
ッダの正常性を判定し、IP HeaderError or Encap Fiel
dの結果を、ＩＰ−ＱＯＳコード出力部（３ｅ）に出力
する。ＩＰ−ＱＯＳコード検索部（３ｃ）は、ヘッダ抽
出部（３ａ）より受けた諸情報を検索キーとして、ＣＡ
Ｍ（Contents Addressable Memory）およびＳＲＡＭを
アクセスし、ＩＰ−ＱＯＳコードを解決する。この解決
したＩＰ−ＱＯＳコードには、装置内におけるクラス識
別子、スイッチ制御に対する優先度等の情報が含まれ
る。

【００７４】ポリシング制御部（３ｄ）は、前段のＩＰ
−ＱＯＳコード検索部において解決されたクラス種別単
位にトラヒックを監視し、過剰なトラヒックの規制を行
う。左記処理は、Token-Backet方式によるトラヒック違
反の監視である。Token-backet方式は、ｂｕｃｋｅｔ内
のｔｏｋｅｎ量は、経過時間Ｔ×平均レートｒのＴ・ｒ
で増加する。パケット到着時に、該パケットに対して、
パケットを入れる容器であるｔｏｋｅｎに必要なｔｏｋ
ｅｎ量に満たない場合は、該パケットを廃棄する。

【００７５】左記処理は、パケット長とｔｏｋｅｎの比
較であり、token < packet長の場合は、廃棄ビットを”
ＯＮ”（廃棄対象パケットを明示）にして、後段ブロッ
クに送出し、左記以外（token ≧ packet長）の場合
は、廃棄ビットをスルーとする簡易なロジックである。

【００７６】違反トラヒックの判定を高速化するため
に、ハードやソフトを作成・調整するインプリメンテー
ション上では、以下のようにしてもよい。

【００７７】入力パケットの通過条件を、「token ≧ p
acket長」ではなく、「token >=0」とする。

【００７８】パケットを送信した後、ｔｏｋｅｎからパ
ケットサイズ分減算するため、ｔｏｋｅｎの値は負の値
を取りうる。パケット送信時、ｔｏｋｅｎが負の値であ
る場合は、送信パケットはトラヒック違反の対象とす
る。本判定回路を用いることにより、違反判定は、ｔｏ
ｋｅｎの符号情報（１ｂｉｔ）の情報ですむため、回路
構成がシンプルになる。

【００７９】ＩＰ−ＱＯＳコード出力部（３ｅ）は、Ｉ
Ｐ−ＱＯＳコード検索部（３ｃ）で解決したＩＰ−ＱＯ
Ｓコードと共に、ポリシング制御部（３ｄ）からのFilt
eringビット、および、ヘッダチェック部（３ｂ）から
のエラー情報をリタイミングして、後段ブロック（受信
側スイッチインタフェース制御部：１ｂ）に出力する。
トラヒッククラスのマッピング（ＭＦ／ＢＡ Classifie
r）ＩＰヘッダに含まれる各フィールドをどのように組
み合わせて、トラヒッククラスに対応づけるかは、運用
者マターであり、各ＩＥＴＦのＲＦＣ等の勧告において
も明確に記載されている訳ではない。この対応付けに、
汎用性を持たせるためには、抽出したヘッダ情報の任意
の組み合わせでトラヒッククラスにマッピングさせる必
要がある。

【００８０】例えば、ある契約ユーザ間の特定のＩＰト
ラヒックに対して優先制御を行う場合は、送信元（Ｓｒ
ｃ） IP アドレスと、宛先（Ｄｓｔ） IP アドレスの組
み合わせで、クラスを判断することになる。また、左記
ＩＰトラヒックの中でＨＴＴＰ（ＷＷＷサーバで使うハ
イパーテキストをインターネット上で交換するプロトコ
ル）トラヒックのみ優先処理したいのであれば、さらに
その上位レイヤのヘッダ内に収容されているＳｒｃ Ｐ
ｏｒｔ＃， Ｄｅｓｔ Ｐｏｒｔ＃を組み合わせてクラ
スを判断する必要がある。また、あるサーバから転送さ
れるトラヒックのみに優先制御を行いたいのであれば、
サーバのＩＰアドレスであるSrc IP アドレスと、Ｓｒ
ｃ Ｐｏｒｔ番号のみを参照してクラスを判断する必要
がある。このようにＩＰヘッダおよび、上位レイヤの複
数のフィールドの組み合わせで、トラヒッククラスを判
定する（Classifier）方法を、Multi-Field （ＭＦ） C
lassifierと呼ぶ。

【００８１】上記に対して、Behavior Aggregate（Ｂ
Ａ） Classifierと呼ばれるクラス判定方法も存在す
る。ＢＡクラス分け方法は、ＩＰヘッダのＴＯＳフィー
ルドのみ参照して、トラヒッククラスを判定する方法で
ある。ＩＰヘッダに定義されるＴＯＳフィールドは、Ｄ
ｉｆｆ−Ｓｅｒｖ用に定義される特殊なフィールドであ
る。ＴＯＳフィールドの目的は、各ルータでＩＰヘッダ
の各フィールドの組み合わせから、トラヒッククラスを
判定する処理を削減することにある。つまり、上流のル
ータがＩＰヘッダの各フィールドからトラヒッククラス
を判定し、左記クラス情報をＴＯＳフィールドに付与し
て転送する。次段以降のルータは、ＴＯＳフィールドの
みを参照してトラヒッククラス別の優先制御を行えば良
い。しかしながら、ＴＯＳフィールドの使用方法もベン
ダーマターになっているので、同一系列（同一ベンダ
ー）の装置同士で接続するか、隣接するルータ間にて運
用上の取り決めを行う等の制約が発生する。

【００８２】このように、トラヒッククラスのｍａｐｐ
ｉｎｇ（マッピング）においては、任意のフィールドの
多種多様な組み合わせに応じて、登録できるような方式
が必要であり、本発明では、以下に示す方法により、Ｍ
Ｆ ClassifierとＢＡ Classifierを同時にサポート可能
である。

【００８３】（クラス検索部の動作）クラス検索部の動
作を図４、図５を参照して説明する。図４は、クラス検
索部（３ｃ）の構成および動作を示したものであり、図
５は検索処理のフローを示したものである。また、図４
は、ＩＰ−ＱＯＳクラス検索部（３ｃ）は、レイヤＬ４
ポートの変換用ＳＲＡＭと、部送信元ＩＰアドレス検索
用のＣＡＭと、宛先ＩＰアドレス検索用のＣＡＭと、優
先度マッピング検索用のＣＡＭと、優先度を設定するた
めのＳＲＡＭとの各記憶部を備えたブロック図であり、
ソフトウェア的に優先制御用のデータを抽出する。ま
た、図５は、送信元アドレスと宛先アドレスとサービス
タイプ識別子（ＴＯＳ）とプロトコルとを入力し、検索
したアドレスＱを出力するＣＡＭ検索部と、検索したア
ドレスＱと、上位層のＴＣＰ送信元ポートとＴＣＰ宛先
ポートとを入力し、ＩＰ−ＱＯＳコードを出力するＳＲ
ＡＭアクセス部とからなるフローチャートを示してい
る。

【００８４】ここで、ＣＡＭ上には主に条件情報、ＳＲ
ＡＭにはアクションの情報が記述される。ＳＲＡＭに記
述するアクションは、ＣＡＭ上の条件記述と対応してお
り、特に媒体として分けることは、必要条件ではない
が、ＳＲＡＭの高速性を鑑みれば、ＣＡＭをＳＲＡＭで
構成して、記憶領域を区分すればよい。あくまでも、Ｃ
ＡＭのリソース（エリア：エントリ数）を有効利用する
ためのインプリ的な手法を用いる。

【００８５】前述した通り、ＭＦ Classifierでは、送
信元Ｓｒｃ ＩＰ アドレス、宛先Ｄｓｔ ＩＰアドレ
ス、送信元Ｓｒｃ Ｐｏｒｔ番号、宛先Ｄｓｔ Ｐｏｒ
ｔ番号、プロトコル番号、ＴＯＳの任意の組み合わせか
ら、トラヒッククラスを判定する。ＭＦ Classifierに
おいて、最も簡易な検索方法は、ｅｎｔｒｙ毎にＭａｓ
ｋを指定できるＣＡＭに、登録情報として（送信元Ｓｒ
ｃ ＩＰ アドレス、宛先Ｄｓｔ ＩＰアドレス、送信
元Ｓｒｃ Ｐｏｒｔ番号、宛先Ｄｓｔ Ｐｏｒｔ番号、
プロトコル番号、ＴＯＳ）の値を設定し、パケット入力
毎にパケットヘッダ情報をもとに検索を行う方式であ
る。しかしながら、ＣＡＭのｂｉｔ幅などに制約があ
り、インプリ上の工夫が必要になる。

【００８６】そこで、本発明では、汎用的なＣＡＭを使
用し、且つ以下に示す２段階の検索方法によりＩＰ−Ｑ
ＯＳコードを取得するシーケンスを有する。なお、ＢＡ
Classifierの処理（ＴＯＳフィールドのみの参照によ
り、ＩＰ−ＱＯＳコードへ変換する処理）も、ＭＦの処
理と同じ枠組みの中で実施される。つまり、ＭＦにおい
て、ＴＯＳフィールドのみ有効となる運用と考えればよ
く、ＣＡＭの構造（Configuration）において、両者を
共存させた運用が可能である。

【００８７】（１）まず、前処理として、個々のフィー
ルドを“ｋｅｙ値”に縮退し、ＣＡＭ及びＳＲＡＭに登
録する。

【００８８】（２）次に、クラス判定処理として、前記
“ｋｅｙ値”により登録されたｅｎｔｒｙをＣＡＭ上で
検索する。

【００８９】以下に、図４および図５に即して、具体的
に説明する。

【００９０】（ＣＡＭへの事前登録）前処理１：送信元
（Src IP）アドレスの登録および縮退（図４中）予
め、クラス判定処理のｅｎｔｒｙに含まれる送信元（Sr
c IP）アドレス／ｐｒｅｆｉｘをすべて登録しておく。
前処理において、特に送信元（Src IP）アドレス、宛先
（Dest IP）アドレスを縮退する場合は、ＣＩＤＲ（Cla
ssless Inter Domain Routing）に基づく規定により、
送信元（Src IP）アドレスをｋｅｙとして、Longest Pr
efix Matchにより検索する。検索で返されたＣＡＭアド
レスをアドレスＡとする。登録されていない場合は、ａ
ｌｌ”０”がアドレスＡ値となる。本処理は、図５のス
テップ（１）の処理となる。

【００９１】前処理２：宛先（Dest IP）アドレスの登
録および縮退（図４中）前処理１と同様、予め、クラ
ス判定処理のｅｎｔｒｙに含まれる宛先（Dest IP）ア
ドレス／ｐｒｅｆｉｘをすべて登録しておく。宛先アド
レスを検索ｋｅｙとして、Longest Prefix Matchにより
検索される。検索で返されたＣＡＭアドレスをＡｄｄｒ
＿Ｂとする。登録されていない場合は、ａｌｌ”０”が
Ａｄｄｒ＿Ｂ値となる。本処理は、図５のＳＴＥＰ
（２）の処理となる。

【００９２】なお、ＣＡＭをパラレル接続することによ
り、図５のＳＴＥＰ（１）（２）は、並列処理が可能で
ある。

【００９３】前処理３：ポート番号（レイヤ４情報）の
登録および縮退（図４中’,’） 本処理の目的は、Ｓｒｃポート番号もしくはＤｅｓｔポ
ート番号からレイヤ４アプリケーションを判定し、所定
のｋｅｙ値に縮退することである。ポート番号は、レイ
ヤ４プロトコルを規定するWell Known Port番号と、各
端末が任意に付与する番号に分類される。

【００９４】通常のレイヤ４アプリケーションにおい
て、クライエントからサーバ方向に転送されるパケット
のDest Port番号には、サーバで機能するレイヤ４アプ
リケーションのWell Known Port番号が付与されてお
り、左記Well known番号をメモリ（テーブル）に登録す
る。

【００９５】運用で必要なWell Known Port番号は数種
類に限られている（ＨＴＴＰ，ＴＥＬＮＥＴ，ＦＴＰ等
々）ため、メモリ量としては僅か（２５６×８＝２０６
４ｂｉｔ）でよい。

【００９６】本処理では、ポート番号をアドレスとし
て、”ポート番号→Ｋｅｙ”変換用のメモリにアクセス
し、所定のｋｅｙ値を得る。左記Ｋｅｙは、レイヤ４を
特定するｃｏｄｅと、送信元（Scr）ポートとして有効
か、あるいは、宛先（Dest）ポートとして有効かを指定
するｆｌａｇより構成される。Ｓｒｃ／Ｄｅｓｔポート
のｆｌａｇを指定する理由は、例えばサーバ向けのトラ
ヒックは、高優先クラスとして扱うが、クライエント向
けのトラヒックはＢｅｓｔ Ｅｆｆｏｒｔ扱いする等
の、片方向トラヒックに対するクラス分けも可能とさせ
るためである。

【００９７】図５のＳＴＥＰ（３）およびＳＴＥＰ
（４）に示すように、本処理はＳｒｃポート番号および
Ｄｅｓｔポート番号のそれぞれに対して実行される。Ｓ
ｒｃポート番号による変換キーの読み出し処理が、図５
のＳＴＥＰ（３）に相当し、Ｄｅｓｔポート番号による
変換キーの読み出し処理が、図４における’’、お
よび図５のＳＴＥＰ（４）に相当する。

【００９８】両者の結果からWell Known Port番号が縮
退された“Ｋｅｙ値”、およびＳｒｃポートに発生した
か、Ｄｅｓｔポートに発生したかを示す”ｆｌａｇ”が
生成される。本処理が、図５のPory Keyを算出するＳＴ
ＥＰ（５）に相当する。

【００９９】（クラス判定処理（図４の））前処理
（図５におけるＳＴＥＰ（１）〜（５））で得られた各
種Ｋｅｙ値、およびＴＯＳ、プロトコル番号を元に、再
度ＣＡＭを検索する。本処理が図５のＳｔｅｐ（６）に
該当し、各Ｋｅｙの組み合わせ（どのＫｅｙを有効情報
として検索するか）は、ＣＡＭ内のｅｎｔｒｙ単位にｍ
ａｓｋ情報として定義されている。本処理により、ｅｎ
ｔｒｙの格納されているＣＡＭアドレス（ａｄｄｒ＿
Ｑ）が得られる。

【０１００】最後に、図５におけるＳＴＥＰ（７）にお
いて、左記ＣＡＭアドレス（ａｄｄｒ＿Ｑ）を外部メモ
リへのポインタ情報（アドレス）として使用して、アク
セスすることにより、最終的に必要なトラヒッククラス
の情報が得られる。

【０１０１】図５に示す処理フローにて得られた情報
（ＩＰ＿ＩＮＦＯ）は、受信側スイッチインタフェース
制御（１ｂ）部で、ｏｂｊｅｃｔにｍａｐｐｉｎｇさ
れ、及び受信側スイッチインタフェース（１ｄ）に転送
することにより、入力ＩＦカードで実施される各種優先
制御が行われる。

【０１０２】なお、ＣＡＭの検索で登録にＨｉｔしない
場合、ＣＡＭはアドレス”０”を返すこととし、この場
合はＢｅｓｔ Ｅｆｆｏｒｔトラヒックを示すクラスコ
ードであると規定しておけばよい。外部メモリにおいて
も、リセット時の外部メモリ値はａｌｌ’０’とし、ア
ドレス”０”の領域にはＢｅｓｔ Ｅｆｆｏｒｔトラヒ
ック用のクラス情報が格納されることとなる。上記によ
り、ＣＡＭ検索でｈｉｔしないトラヒックはＢｅｓｔ
Ｅｆｆｏｒｔトラヒックの扱いを受ける。各テーブルの
詳細内容は、図６乃至図８に示す通りである。

【０１０３】図６には、記憶手段のＣＡＭ（Contents A
ddressable Memory：連想メモリ）に格納したテーブル
構成例の表と、IP Src Prefix エントリの格納領域のテ
ーブル図を示し、図７には、IP Des Prefixエントリ格
納領域のテーブル図と、IPINFOアドレスエントリ格納領
域のテーブル図を示している。また、図８はIPINFOエン
トリ格納領域のテーブル図である。

【０１０４】なお、上記図６乃至図８の場合に、 Ｄ ：Discard Indication (0:Normal, 1:Discard)フィ
ルタリング処理に使用する。

【０１０５】Ｐ ：Packet Priority （０：低優先，
１：高優先） Route ：上位１ビット Route Change Flag （０：Default Routeに設定、１：下位４ビットのroute
fieldに設定） Output TOS bit9 ：DSCP Update Flag （０：ＴＯＳのDSCP Field
（bit７−２）の書き換えを行わない、１：書き換えを
実施） bit8 ：CU Update Flag （０：ＴＯＳのCU Field（bit
１， ０）の書き換えを行わない、１：書き換えを実
施） bit7-2 ：TOS DSCP（differentiated service code poi
nt） Field bit1-0 ：TOS CU（currently unused） Field であることを付加する。

【０１０６】（トラヒック規制手段）本発明におけるト
ラヒック帰省手段は、図１５に示すように、ｔｏｋｅｎ
ｂｕｃｋｅｔモデルによってトラヒック特性を表現
し、（１）受信側インタフェース部におけるポリシング
処理部（３ｄ）、（２） 送信側インタフェース部にお
けるシェーピング処理部（８ｆ）において 本ｔｏｋｅ
ｎ ｂｕｃｋｅｔモデルを適用する。

【０１０７】つまり、トラヒック違反を検出するアルゴ
リズムは、シェーピング、ポリシング共に同等の回路構
成となる。図１５にＴｏｋｅｎ ｂｕｃｋｅｔ モデル
を示す。Ｔｏｋｅｎ ｂｕｃｋｅｔは、ｔｏｋｅｎ格納
用レジスタ（バケツ：ｂ）を持ち、周期的にバケツにｔ
ｏｋｅｎを追加する（平均レート（ｒ）でｔｏｋｅｎが
増加する）。Ｔｏｋｅｎ加算処理においては、Ｔｏｋｅ
ｎ上限値（ｂ）と比較し、ＷＣ＋ｔｏｋｅｎがｂを越え
る場合は、ｂ値を設定する。

【０１０８】パケット送信条件は、送信するパケットサ
イズ分のｔｏｋｅｎがバケツに格納されていることであ
る。また、パケットを送信した後、ｔｏｋｅｎからパケ
ットサイズ分減算する。パケット送信時、パケットサイ
ズ以上のｔｏｋｅｎがｂｕｃｋｅｔに無い場合は、該送
信パケットはトラヒック違反の対象になる。ポリシング
処理部（３ｄ）に適用する場合は、違反の対象となった
パケットを廃棄（あるいは低優先のマーキング等）を行
い、シェーピング処理部（８ｆ）に適用する場合は、違
反したパケットを送信可能になる量のｔｏｋｅｎがｂｕ
ｃｋｅｔに溜まるまで待ち合わせてから送信することと
なる。

【０１０９】（図１６による補足説明）トラヒック違反
はパケットを転送するのに必要なｔｏｋｅｎ量がｂｕｃ
ｋｅｔに溜まっていないときである。ｂｕｃｋｅｔ内ｔ
ｏｋｅｎ量は経過時間Ｔ×平均レートｒで増加する。パ
ケット到着時に必要なｔｏｋｅｎ量に満たない場合は、
不足ｔｏｋｅｎが溜まるのに必要な時間を待ってからパ
ケットを出力する。

【０１１０】図１６に、ポリシング・シェーピングの動
作イメージを示す。同図に即して説明すると、以下のよ
うになる。

【０１１１】（ポリシングの動作例） （１） 時刻Ｔ１にパケット１が到着したとする。この
とき、トラヒック違反でないので、同時刻Ｔ１’でパケ
ットを出力する。出力した時点でのｂｕｃｋｅｔに残っ
ているｔｏｋｅｎ量はＸ１である。

【０１１２】（２） 時刻Ｔ２にサイズｓ２のパケット
２が到着したとする。パケット２を出力するのに必要な
ｔｏｋｅｎ量はｓ２であるが、ｓ２＞Ｘ１＋（Ｔ２−Ｔ
１）×ｒであったとする。この条件では、トラヒック違
反であるので、パケット２を廃棄する。

【０１１３】（シェーピングの動作例） （１） 時刻Ｔ１にパケット１が到着したとする。この
とき、トラヒック違反でないので、同時刻Ｔ１’でパケ
ットを出力する。出力した時点でのｂｕｃｋｅｔに残っ
ているｔｏｋｅｎ量はＸ１である。

【０１１４】（２） 時刻Ｔ２にサイズｓ２のパケット
２が到着したとする。パケット２を出力するのに必要な
ｔｏｋｅｎ量はｓ２であるが、ｓ２＞Ｘ１＋（Ｔ２−Ｔ
１）×ｒであったとする。この条件では、トラヒック違
反であるので、規定ｔｏｋｅｎ量が溜まるまでの時間τ
だけ待ち合わせた後、パケット２を出力する。ここで、
τは、 ｓ２＝Ｘ１＋｛（Ｔ２＋τ）−Ｔ１｝×ｒ よ
り算出可能である。

【０１１５】（出力インタフェース（ＩＦ）カードにお
ける優先制御の詳細）図２を参照しつつ出力インタフェ
ース（ＩＦ）カードにおける優先制御について説明すれ
ば、出力ＩＦカードでは、ＩＰ−ＱＯＳクラス別スケジ
ューラ（１ｍ）が、ｏｂｊｅｃｔ情報に定義されるＩＰ
−ＱＯＳコード（トラヒッククラス）を基に、所定の優
先制御を行う。ＩＰ−ＱＯＳコードは、トラヒッククラ
スの識別情報として定義されるものであり、複数の遅延
クラスと複数の廃棄クラスが表現されている。ＩＰ−Ｑ
ＯＳクラス別スケジューラ（１ｍ）で実施される優先制
御は、図２で示した、の処理である。ＩＰ−ＱＯＳ
クラス別スケジューラ（１ｍ）における優先制御の概念
図を図１０に示す。

【０１１６】（ＩＰ−ＱＯＳクラス別スケジューラ（１
ｍ）における優先制御）ＩＰ−ＱＯＳクラス別スケジュ
ーラ（１ｍ）は、送信側スイッチインタフェース（１
ｊ）からＦＩＦＯ（１ｎ）経由でＯｂｊｅｃｔを受け取
り、Ｃｌａｓｓｉｆｉｅｒ（８ａ）にて、左記Ｏｂｊｅ
ｃｔを仕分けし、クラス単位のキューを選り分ける共有
バッファ（８ｃ）に格納する。左記共有バッファ（８
ｃ）は、クラス単位のＯｂｊｅｃｔ格納用であり、それ
ぞれ、ＥＦ、ＡＦ１〜４、ＢＥの計６種類のＯｂｊｅｃ
ｔ ｑｕｅｕｅ（８ｃ）が存在し、共有バッファによる
管理される。ＥＦ／ＡＦ／ＢＥクラスの意味について
は、従来の技術にて説明したとおりである。

【０１１７】ＥＦクラスは、帯域保証サービスとして位
置づけられるため、Ｓｈａｐｅｒ（８ｆ）も含んだ厳密
な転送制御を行う。図１０中のWeighted Round Robin C
ontroller（８ｄ）で、ＥＦクラスキューは、後述する
ＡＦクラスキューやＢＥクラスキューに対し絶対優先で
読み出されるべく、Output Class Selector（８ｅ）に
対するセレクタ制御が実施される。Ｓｈａｐｅｒ（８
ｆ）は、Ｐｏｌｉｃｉｎｇ部と、同等のＴｏｋｅｎ−ｂ
ａｃｋｅｔモデルによる回路構成であり、ｓｈａｐｅｒ
部とポリシング制御部との差異は、違反パケットに対し
て、待ち合わせるか、廃棄するかの違いのみである。本
箇所においても、インプリ上は、ｐｏｌｉｃｉｎｇ回路
と同様、ｔｏｋｅｎに付与する符号ｂｉｔのみの判定に
より、送出判定を高速化すると共に回路構成の簡素化を
図ることも可能である。

【０１１８】ＡＦクラスおよびＢＥクラスに対しては、
ＷＲＲ（Weighted Round Robin）でスケジューリングさ
れる。

【０１１９】（ＷＲＲの補足説明）ＷＲＲとは、Round
Robin方式の拡張であり、予め決められたウェイト比に
したがって、各クラスに対してサービスを行う。ＷＲＲ
では各クラス毎にカウンタを設けている。カウンタの値
は、次にカウンタがリセットされるまでに送出可能なセ
ル（ｏｒ固定長パケット）の個数を表し、リセット時に
は各クラスのウェイトの値に設定される。選択されたク
ラスのカウンタの値が０以上であり、且つバッファ内に
セルが１つ以上あれば、そのクラスからセルを１つ送出
し、カウンタ値をデクリメントする。もし、全てのクラ
スにおいて、ウェイトの値が０になるかバッファ内のセ
ル数が０となった場合、全てのウェイトカウンタはリセ
ットされる。従って全てのクラスに充分な入力トラヒッ
クがある場合、出力されるセルの個数はウェイトの比に
従う。

【０１２０】ＡＦクラスおよびＢＥクラスに対しては、
左記クラス毎に、Weighted Counter（８ｇ）を有し、Ｗ
ｅｉｇｈｔ値を保持している。Weighted Round Robin C
ontroller（８ｄ）は、左記Ｗｅｉｇｈｔ値と共有バッ
ファの各クラスキュー（８ｃ）のキュー長の情報を元
に、どのＡＦあるいはＢＥクラスのＯｂｊｅｃｔを読み
出すか判定し、セレクタを制御する。選択されたＡＦ及
びＢＥクラスのキューは、ＦＩＦＯの順序でＯｂｊｅｃ
ｔを出力する。

【０１２１】（廃棄制御）図１０中に示す廃棄制御ロジ
ック部（８ｂ）は、図１１で示されるロジックに基づ
き、廃棄制御が行われる。入力ｏｂｊｅｃｔ情報を元
に、各クラスのキュー長（８ｈ）が管理される。各クラ
スには廃棄制御用のスレッシュホールド（８ｋ）が定義
されている。同時に、共有バッファ（８ｃ）全体のスレ
ッシュホールドも定義されている。廃棄制御ロジック
（８ｂ）では、キュー長とスレッシュホールド（８ｋ）
の比較により廃棄制御を行い、廃棄するｏｂｊｅｃｔは
Drop Objectとして送信側スイッチインタフェース（１
ｊ）に通知する。

【０１２２】クラス単位のキュー長（８ｈ）、スレッシ
ュホールド比較による廃棄制御に加え、共有メモリ（８
ｃ）全体に渡る同一廃棄クラスのキュー長総和とスレッ
シュホールド比較による廃棄制御も行われる。図１１に
示す通り、３種類の廃棄クラスに対してそれぞれ３種類
のスレッシュホールドを定めている。従って、全クラ
スで廃棄無し、低優先クラスのみで廃棄、低優先お
よび中優先クラスで廃棄、全クラスで廃棄の状態があ
る。図１１において、Ｔｈｒｅｓｈ３以上にキュー長が
増えると、空き領域があるのに関わらず、すべてのパケ
ットが廃棄扱いとなる。

【０１２３】同様に、ＡＦクラス単位のみならず全メモ
リ内の廃棄クラスの総和に対しても、同様なスレッシュ
ホールドを定義し、廃棄制御を行う。

【０１２４】（ＷＲＲ対象バッファ）図１４は、ＷＲＲ
対象バッファの要部説明図である。各クラス別Ｏｂｊｅ
ｃｔキュー（８ｃ）に対して、現状のウェイト値を管理
するカウンタ（１１１，１２１，…１ｎ１）と共に、ウ
ェイトカウンタリセット処理後のウェイト値を管理する
予備判定用のウェイトカウンタ（１１２，１２２，…１
ｎ２）を設けている。

【０１２５】最初の判定におけるWeighted Round Robin
で即時に判定できない時は、ウェイトカウンタリセット
処理後のウェイト値（予備判定用のウェイトカウンタ）
で同様にクラス判定を行う。左記処理でも判定できない
場合は、固定遅延優先でＡＦクラスを選択する。左記ク
ラス判定処理は、ループ処理を削除した並列処理で実施
されるため、高速性を損なうことはない。

【０１２６】（スケジューリング処理フロー）図１２及
び図１３に本スケジューリングの処理フローを示す。処
理のパスとしては、ＥＦクラス判定パスと、ＡＦ／ＢＥ
クラス判定のパスが存在する。ＥＦクラスがＡＦ／ＢＥ
より絶対優先であるので、ＥＦクラスの送出要求がある
ときは、ＥＦクラスが選択され、ＥＦクラスの送出要求
がないときのみ、ＡＦ／ＢＥの所定クラスが採用され
る。

【０１２７】ＡＦ／ＢＥクラス判定に関しては、２度目
までの判定まではWeighted Round Robinで実現し、３度
目の判定として固定遅延優先で選択される。

【０１２８】なお、図１２及び図１３の処理フローを読
み込む場合は、以下の点を把握してほしい。図１２及び
図１３において、各パラメータを説明すれば、ＥＦクラ
スでは、Ｗ［ＥＦ］：ＥＦクラスの初期ウェイト（加算
token値）、ＷＨ［ＥＦ］：tokenの上限値、ＷＣ［Ｅ
Ｆ］：ＥＦクラスのtoken値（変数）、Ａｄｄ Ｔｉｍ
ｅ［ＥＦ］：token加算周期（例えば、契約時の平均レ
ートで規定）、であり、ＡＦ／ＢＥクラス（ｉ ＡＦ
１，２，３，４，ＢＥ）では、Ｗ［ｉ］：クラス毎初期
ウェイト値、ＷＨ［ｉ］：ウェイトカウンタ上限値、Ｗ
Ｃ［ｉ］：ウェイトカウンタ値（変数）、ＷＣ［ｉ］
ｒ：１回のウェイトカウンタリセット後のウェイトカウ
ンタ値（変数）、ＷＣ［ｉ］ｒ≦ＷＣ［ｉ］＋ clas
s ptr：送出、検索クラスを指すポインタ、ＭＰＳＺ（M
aximum Packet Size）：ＡＦ／ＢＥクラスで適用：レア
ケースの判断基準とするパケット最大長。fixed Priori
ty(Q[i])：ＷＣ値に依存せず、Ｑ［ｉ］＞０：キュー内
のobjectの有無のみをみて固定優先度（ＡＦ１，２，
３，４，ＢＥの順）に基づいた出力要求を送信する。Ｅ
Ｆ／ＡＦ／ＢＥ共通として、Length：パケット長であ
る。

【０１２９】まず、ＥＦクラス選択の処理過程を説明す
る。

【０１３０】（Ｔｏｋｅｎの周期的な加算処理）図１２
において、初期化処理について、ステップＳ０ａにて、
ｔｏｋｅｎ（ＷＣ［ＥＦ］）を“０”に初期化する（ス
テップＳ０ａ）。ステップＳ０ｂにて、Ｔｏｋｅｎ加算
タイミングを生成し、所定タイミング（ｃｎｔ＝＝Ａｄ
ｄ＿ｔｉｍｅ［ＥＦ］）であれば、Ｓ０ｃにてＴｏｋｅ
ｎを加算する。現状のＷＣ［ＥＦ］に初期ｔｏｋｅｎで
あるＷ［ＥＦ］を加算する。つぎに、Ｔｏｋｅｎ加算周
期は、例えば契約時における平均レートで規定される。
上記処理において、Ｔｏｋｅｎ上限値（ＷＨ［ＥＦ］）
と比較し、ＷＣ［ＥＦ］＋Ｗ［ＥＦ］がＷＨ［ＥＦ］を
越える場合は、ＷＨ［ＥＦ］を設定する。

【０１３１】（ＥＦクラス送信要求の生成）次に、図１
３に示すように、ステップＳ１ａにて、Ｏｂｊｅｃｔ読
み出し要求を受信した場合は、Ｓ１ｂにてキュー長の判
定を行い、Ｓ１ｃにて、Ｔｏｋｅｎの有無判定を行う。

【０１３２】左記判定において、ＥＦクラスのキューに
Ｏｂｊｅｃｔが１個以上あり、且つｔｏｋｅｎも存在す
る場合（０以上）には、Ｓ１ｄにて、出力要求（Ｓｅｎ
ｄ＿ｒｅｑ［ＥＦ］＝ＯＮ）を送出する。その後Ｓ１ｅ
にてパケット送出後、ｔｏｋｅｎからパケット長分減算
する。Ｓ３の最終段のセレクタ処理にて、最優先クラス
であるＥＦクラスの送出要求が受理される。

【０１３３】次にＡＦ／ＢＥクラス選択処理について説
明する。

【０１３４】（ＡＦ／ＢＥクラス選択処理）このＡＦ／
ＢＥクラス選択処理の場合、図１２と図１３とを参照し
て説明する。

【０１３５】（１） Ｓ０ｄ、およびＳ０ｅにて、クラ
スポインタ、およびウェイトカウンタの値を初期化す
る。

【０１３６】（２） Ｓ１ａにて、Ｏｂｊｅｃｔ読み出
し要求を受信し、ＥＦクラスが送出不可のとき（Ｓ１
ｂ、Ｓ１ｄがいずれもＮｏのとき）のみ、ＡＦ／ＢＥの
クラス選択処理が実施される。Ｓ２ｂにてキュー長の判
定を行い、Ｓ１ｃにて、ｗｅｉｇｈｔの有効性を判定す
る。

【０１３７】（３） ＡＦ／ＢＥクラスは複数クラスあ
るため、Ｓ２ｅにて、全クラスに対して、上記（２）の
判定処理を行う。Ｓ２ｇにて、クラスポインタ（検索ク
ラスを指すポインタ）の更新は、ラウンドロビンの規則
に従う。

【０１３８】（４） 送出条件（キュー長＞０ 且つ
Ｗｅｉｇｈｔ値＞０）に合致するクラスが存在する場合
は、Ｓ２ｄにて該当クラスの出力要求（Ｓｅｎｄ＿ｒｅ
ｑ［Ｃｌａｓｓ］＝ＯＮ）を送出する。

【０１３９】前述した（１）〜（４）の処理が１ｓｔル
ーチンによるクラス選択である。

【０１４０】（５） 前述した（３）の検索処理におい
て、全てのクラスについて、送出条件に合致しない場合
は、全クラスに対して、クラス毎に規定された初期ウェ
イト値を現状のウェイト値に加算する。（左記処理をウ
ェイトカウンタリセット処理と呼んでいる。） （６） １ｓｔルーチンでクラス選択ができない（出力
クラス候補が存在しない）場合は、（５）において１回
のウェイトカウンタリセット後のウェイト値によって再
度クラス選択を行う。図１１に示すように、方法とし
て、現状のウェイト値を管理するとレジスタ（ＷＣ［ｃ
ｌａｓｓ］）と共に、１回のウェイトカウンタリセット
処理後のウェイト値を管理するレジスタ（ＷＣ［ｃｌａ
ｓｓ］ｒ）を別に有し、（４）の処理と同様、送出条件
（キュー長＞０ 且つ ＷＣ［ｃｌａｓｓ］ｒ＞０）に
合致するクラスが存在する場合は、該当クラスの出力要
求（Ｓｅｎｄ＿ｒｅｑ［Ｃｌａｓｓ］ｒ＝ＯＮ）を送出
する。

【０１４１】前述した（５）〜（６）の処理が、２ｎｄ
ルーチンによるクラス選択である。

【０１４２】（７） ２ｎｄルーチンにおいても、クラ
ス選択ができない（出力クラス候補が存在しない）場合
は、特例措置として、固定優先的にクラス選択を実施す
る。本処理の意図は、回線容量に空きがあるにも関わら
ず、パケットが送出できない状態に陥る状態を救済する
ためであり、予め決められている固定優先度（例えば、
図８のモデルでは、ＡＦ１＞ＡＦ２＞ＡＦ３＞ＡＦ４＞
ＢＥの順）に基づいて、送出クラスを選択する。左記処
理は、ウェイト値に依存せず、キュー内のＯｂｊｅｃｔ
の有無のみを判定して出力候補を決定する手法であり、
本手法を用いることにより、１回のクラス選択処理にお
いてウェイトカウンタリセット処理が２度以上起こるケ
ースはない。通常の判定は、Weighted Round Robinで実
現し、特例の判定として固定遅延優先（図１２中では、
Fixed Priority MODEと呼ぶ。）で実現する。

【０１４３】（８） ステップＳ２ｎにて、（４），
（６），（７）で処理された該当クラスの出力要求よ
り、出力クラスを選択する。

【０１４４】本ステップの処理において、パラメータと
して最大パケット長（Maximum Packet Size：ＭＰＳ
Ｚ）を導入する。最大パケット長導入の意図は、過大な
パケット長が到着したときにウェイトカウンタの値が負
の方向に大きな値となることを救済するための措置であ
る。例えば、ＩＰパケットの最大長は、６４ｋｂｙｔｅ
であるが、左記の様なパケットは、異常な事態として考
えて良い。統計的に、一般的なパケット長は数ｋｂｙｔ
ｅまでを想定すれば十分である。そこで、異常パケット
とみなされる最大パケット長を設定可能とし、過大なパ
ケットが到着したことを、パケット長（Length）と最大
パケット長との比較を行う。パケット長＞最大パケット
長の場合は、特殊ケースとして扱い、ウェイトカウンタ
の減算処理をスキップする、もしくは、ある一定のペナ
ルティを与えるべくウェイト値を強制的に”０”にする
等の処置を行う。

【０１４５】上述した実施形態によって、未だ規格的に
流動的なＤｉｆｆ−Ｓｅｒｖにおいても、ＯＳＩ参照モ
デルのＴＣＰ層とＩＰ層の組み合わせによって、ＩＰパ
ケットから、ＩＰパケットとは独立して、ＩＰ−ＱＯＳ
コードをそれぞれ割り当て、ＩＰ−ＱＯＳコードに応じ
て各種の通信品質のクラス分けを行うことが望まれる。
このＩＰ−ＱＯＳコードのクラス分けによって、通信系
の輻輳状態を解消することが大きな効果として呈示し得
る。

【０１４６】

【発明の効果】本発明による効果は、以下の点にある。

【０１４７】（１） オペレータの設定によりパケット
のレイヤ３・レイヤ４情報の組み合わせ（上位アプリケ
ーション別フロー単位）による優先トラヒックを規定で
きる。

【０１４８】（２） 汎用的な運用を想定して、ＷＲＲ
Ｓ（Weighted Round Robin Scheduling）と固定優先ス
ケジューリングとを組み合わせることが可能である。各
ＱＯＳクラスを固定優先で選択できるとともに、最小帯
域指定も可能である。

【図面の簡単な説明】

【図１】本発明によるマルチレイヤクラス識別通信装置
の構成図である。

【図２】本発明によるマルチレイヤクラス識別通信装置
の構成動作の説明図である。

【図３】本発明によるＩＰ−ＱＯＳクラス決定部の要部
説明図である。

【図４】本発明によるクラス検索部の動作説明図であ
る。

【図５】本発明によるクラス検索部の処理フローチャー
トである。

【図６】本発明によるＣＡＭ領域分割のテーブル構成例
及びIP Src Predixエントリ格納領域の構造図である。

【図７】本発明によるIP Src Prefixエントリ格納領域
のテーブル構成図及びIP Src Predixエントリ格納領域
の構成図である。

【図８】本発明によるIPINFOエントリ格納領域のテーブ
ル構成図である。

【図９】本発明に用いるIPv4 & TCP/UDP/Other Header
フォーマット図である。

【図１０】本発明によるＩＰ−ＱＯＳクラス別スケジュ
ーラの原理図である。

【図１１】本発明による廃棄制御ロジックの説明図であ
る。

【図１２】本発明によるスケジューラの処理フローチャ
ートである。

【図１３】本発明によるスケジューラの処理フローチャ
ートである。

【図１４】本発明によるＷＲＲ対象バッファ要部の説明
図である。

【図１５】本発明によるtoken-bucketモデルによるポリ
シング・シェーピング図である。

【図１６】本発明によるポリシング・シェーピング動作
の説明図である。

【符号の説明】

１ａ ＩＰパケット受信部 １ｂ 受信側スイッチインタフェース制御部 １ｃ 受信側ペイロードデータメモリ １ｄ 受信側スイッチインタフェース部 １ｅ ＩＰ−ＱＯＳクラス決定部 １ｆ ＩＰ−ＱＯＳコード（クラス識別子）解決メモリ １ｇ クロスバースイッチ １ｈ スイッチスケジューラ １ｉ 送信側ペイロードデータメモリ １ｊ 送信側スイッチインタフェース部 １ｋ 送信側スイッチインタフェース制御部 １ｍ ＩＰ−ＱＯＳクラス別スケジューラ部 １ｎ ＦＩＦＯ １ｐ ＳＲＡＭ １ｑ ＩＰパケット送信部 ３ａ ヘッダ抽出部 ３ｂ ヘッダチェック部 ３ｃ ＩＰ−ＱＯＳコード検索部 ３ｄ ポリシング制御部 ３ｅ ＩＰ−ＱＯＳコード出力部 ３ｆ パラメータレジスタ制御部 ８ａ クラスファイア ８ｂ 廃棄制御ロジック ８ｃ 共有バッファ ８ｄ 重み付けラウンド・ロビン制御部 ８ｅ 出力クラス選択部 ８ｆ シェイパー ８ｇ 重み付けカウンタ ８ｈ クラスキューの長さ ８ｊ 全キュー長さ ８ｋ スレシホルド（クラス、レベル、全）

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平11−331257（ＪＰ，Ａ) 特開 平８−307454（ＪＰ，Ａ) 特開 平９−331348（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04L 12/56

Claims (6)

(57)【特許請求の範囲】
1. 【請求項１】 入力インターフェースとスイッチ回路と
   出力インターフェースとを備え、通信回線の複数の通信
   品質のレベルを選択可能なマルチレイヤクラス識別通信
   装置であって、 前記通信回線に接続した入力インターフェースに、受信
   したＩＰパケットのヘッダ情報(ＩＰヘッダに代表され
   るレイヤ３情報、およびその上位レイヤに相当するＴＣ
   Ｐ／ＵＤＰヘッダに代表されるレイヤ４情報の組合わ
   せ)から前記ＩＰパケット内におけるクラス識別子を解
   決し、個々のＩＰパケット処理を前記入力インターフェ
   ース内で取り扱うサービス品質(Internet Protocol Qua
   lity of Service：ＩＰ−ＱＯＳ)コードを割当てる割当
   手段を有して、前記スイッチ回路で宛先アドレスに向け
   て前記通信回線を選択し、前記出力インターフェースか
   らレイヤ３以上の上位レイヤ毎に出力スケジューリング
   を実施するマルチレイヤクラス識別通信装置において、 送信側のクラス別スケジューリング方式として、ＥＦ
   （Expedited Forwarding）クラスのパケットを最優先に
   送出し、ＡＦ(Assured Forwarding)クラスのパケット及
   びＢＥ(Best Effort)クラスのパケットに対しては、Ｗ
   ＲＲ(Weighted Round Robin)スケジューリングを行い、
   該ＷＲＲスケジューリングを行っても送出するべきパケ
   ットが無いときに、固定遅延優先のスケジューリングを
   行う方式を用いたことを特徴とするマルチレイヤクラス
   識別通信装置。
2. 【請求項２】 上記ＩＰコードの割当て(トラヒックク
   ラスのmapping)に関し、前記ＩＰパケットのＩＰヘッダ
   および、ＴＣＰヘッダ内の複数フィールドの任意の組み
   合わせで優先トラヒックを規定できる手段を有すること
   を特徴とする請求項１に記載のマルチレイヤクラス識別
   通信装置。
3. 【請求項３】 前記装置は、前記入力インターフェース
   と、出力インターフェースと、前記入力インターフェー
   スと前記出力インターフェースとの間に宛先アドレスに
   向けて切り換えを行う切り換えスイッチと、前記入力イ
   ンターフェースと前記出力インターフェースとの間に前
   記切り換えスイッチの切り換えタイミングを指示するス
   ケジューラとを備え、前記入力インタフェースおよび前
   記出力インタフェース、および前記切り換えスイッチが
   連動して動作することにより、前記ＩＰ−ＱＯＳコード
   により、前記スケジューラの指示により所定の優先制御
   を行う有線制御手段を有することを特徴とする請求項１
   に記載のマルチレイヤクラス識別通信装置。
4. 【請求項４】 前記ＩＰ−ＱＯＳコード単位に統計多重
   効果を得るために、複数のＩＰフローパケットを集約し
   て共有できるキュー管理を行うキュー管理手段を有する
   ことを特徴とする請求項１に記載のマルチレイヤクラス
   識別通信装置。
5. 【請求項５】 前記入力インタフェース、および前記出
   力インタフェースに、前記ＩＰ−ＱＯＳコード単位にト
   ラヒックを監視し、過剰なトラヒックの規制を行うトラ
   ヒック規制手段を有することを特徴とする請求項３に記
   載のマルチレイヤクラス識別通信装置。
6. 【請求項６】 前記クラス識別子は、ＥＦ（Expedited
   Forwarding(Premiumservice)）クラスと、ＡＦ（Assure
   d Forwarding Service）クラスと、ＢＥ（Best Effort
   Service）クラスの３種類のトラヒック（サービスクラ
   ス）であることを特徴とする請求項３に記載のマルチレ
   イヤクラス識別通信装置。