JP5817606B2 - 負荷分散ポリシング機能を含むポリサ - Google Patents

Description

本発明は、負荷分散ポリシング機能を含むポリサに関する。

伝送対象データをパケット形態で送受信するパケット処理装置は、近年の高速インタフェースのサポートに伴い、内部処理速度がほぼ限界に達している。このパケット処理装置に設けることが可能なポリシング機能を含むポリサは、トークンの単純な加減算処理だけではなく、より複雑な処理を必要とされている。ポリサにおける処理の複雑化傾向は高速処理に対する阻害要因となる。

このような現状においては、ポリシングの根幹である正確なレート制限が担保できなくなるので、対処する必要がある。

特開２００４−３３６５４９号公報

図１は、ポリシング機能を含むパケット処理装置１の構成例を示す。このパケット処理装置１は、例えば、通信ネットワークに存在するルータ、スイッチ、及び交換機などのパケット処理機能を有するネットワーク構成装置である。パケット処理装置１は、複数（ｎ個；ｎ≧２）の入出力インタフェース部ＩＦ＃１〜ＩＦ＃ｎ、入出力スイッチ部ＳＷ、及び制御部ＣＯＮＴを備える。

パケット処理装置１において、入出力インタフェース部（単に、インタフェース部と記載することもある）ＩＦ＃１〜ＩＦ＃ｎ及び入出力スイッチ部（単に、スイッチ部と記載することもある）ＳＷは、相互接続され、点線で示す制御線を通して制御部ＣＯＮＴに接続されている。各入出力インタフェース部ＩＦ＃１〜ＩＦ＃ｎは光ファイバなどの伝送路（物理リンク）ＴＬに接続される。

また、制御部ＣＯＮＴは、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、及びＲＯＭ（Read Only Memory）を含むプロセッサＰＲ１と、不揮発性の
フラッシュメモリであり、ＯＳ（Operating System）、各種アプリケーションプログラム、及び各種情報（データを含む）を書換え可能に保存する情報保持メモリＭＭ１とを備えている。

インタフェース部ＩＦ＃１〜ＩＦ＃ｎはユーザデータなどの入出力を行うインタフェースを有する。スイッチ部ＳＷは、クロスコネクト機能を有するスイッチファブリックのスイッチを介して、インタフェース部ＩＦ＃１〜ＩＦ＃ｎを選択的に接続し、ユーザデータなどを転送する。また、制御部ＣＯＮＴは、インタフェース部ＩＦ＃１〜ＩＦ＃ｎ及びスイッチ部ＳＷに対して制御情報を送信したり、装置全体の状態を管理するなどの機能を含む。

図１に示すパケット処理装置１において、各入出力インタフェース部ＩＦ＃１〜ＩＦ＃ｎは、図２に示す詳細構成を採る。

インタフェース部ＩＦ（ＩＦ＃１〜ＩＦ＃ｎ）においては、光ファイバの伝送路ＴＬを通して入力されたパケット形態の光信号は、光モジュールＭＤにより電気信号に変換され、ＰＨＹ／ＭＡＣ（Physical/Media Access Control）処理機能を有するデバイスＰＨＹ
／ＭＡＣへ入力される。なお、伝送路ＴＬを通して出力されるパケット形態の光信号は、光モジュールＭＤにより電気−光変換される。ここで、光モジュールＭＤは、例えばファイバチャネル及びギガビットイーサネット（イーサネット：登録商標）などを通信機器に接続する光トランシーバの一規格であるＳＦＰ（Small Form Factor Pluggable）を採用
している。

デバイスＰＨＹ／ＭＡＣにおいては、パケットが抽出され、後段のＦＰＧＡ(Field Programmable Gate Array)またはＡＳＩＣ（Application Specific Integrated Circuit）などのトラヒック処理部へ出力される。トラヒック処理部としてのＦＰＧＡまたはＡＳＩＣでは、ポリシング及びシェーピングなどのトラヒック管理処理が行われる。

また、インタフェース部ＩＦは、ＦＰＧＡまたはＡＳＩＣがトラヒック管理処理を行う際にそれぞれ利用するパケットデータ用バッファ及び設定テーブル用メモリなどのメモリＭＭ２を備えている。インタフェース部ＩＦは、統計情報収集などのソフトウェア処理及びユーザ設定インタフェースのために、ＣＰＵ、ＲＡＭ、及びＲＯＭを含むプロセッサＰＲ２を更に備えている。

ここで、トラヒック処理部としてのＦＰＧＡまたはＡＳＩＣにおいて実施されるトラヒック管理処理の一つであるポリシング機能に着目すると、図２に示すＦＰＧＡまたはＡＳＩＣは、図３に示す詳細構成を採る。

図３に例示するように、ＦＰＧＡまたはＡＳＩＣに入力されたパケットについては、フロー識別部ＦＬが識別子（ＩＤ）変換テーブルＴＢを参照することにより、ＶＬＡＮ（Virtual Local Area Network）識別子ＶＩＤ（例えば、ＶＩＤ＝２）基づいてフロー識別子ＦＩＤ（例えば、ＦＩＤ＝８）、更に必要に応じてグループ識別子ＧＩＤ（例えば、ＧＩＤ＝３）が導かれ、これらの識別子情報をパケット内（ペイロード）情報として含むパケットがポリサ（policer）ＰＬへ入力される。

更に詳述すると、ポリシング機能とは、通信ネットワークへの入力トラヒックを契約帯域内に制限する機能であり、通常、フローと呼ばれる契約単位で実施されることが多い。また、複数のフローを束ねたグループ単位で実施されることもある。

このようなフロー及びグループは、ポリサＰＬにおいては、フロー識別子ＦＩＤ及びグループ識別子ＧＩＤにより認識される。また、これらのフロー識別子ＦＩＤ及びグループ識別子ＧＩＤは、契約者（ユーザ）を識別するためのパケット内情報であるＶＬＡＮ識別子ＶＩＤと関連付けられる。

ところで、近年の高速インタフェース（１００Ｇｂｐｓ（以下、ｂ／ｓと記載することもある）以上の速度など）のサポートにより、パケット処理装置の内部処理速度はほぼ限界に達している。例えば、イーサネットにおいて、１００Ｇｂｐｓのスループットをサポートする場合、最大で次に示すパケット処理性能が必要になる。
１００Ｇｂpｓ／（（６４ｂｙｔｅ＋２０ｂｙｔｅ）×８）＝１４８．８ Ｍｐｐｓ
ここで、６４ｂｙｔｅはイーサネットの最短パケット長であり、２０ｂｙｔｅはプリアンブル（８ｂｙｔｅ）と最短フレーム間ギャップ（１２ｂｙｔｅ）とを加算した固定値である。この約１５０Ｍｐｐｓ（ｐｐｓ：packet per second）という値は、ＦＰＧＡまた
はＡＳＩＣの動作周波数を３００ＭＨｚとした場合でも、１つの処理に対して２クロック（ｃｌｏｃｋ）しか処理時間が与えられないことを意味する。すなわち、３００ＭＨｚ／
２ｃｌｏｃｋ＝１５０Ｍｐｐｓから求まる。３００ＭＨｚというクロック速度は現在のデバイスのほぼ限界値であり、また２ｃｌｏｃｋという処理時間についてもメモリのリード／ライトにそれぞれ１ｃｌｏｃｋずつ必要であることを考えると、アーキテクチャのほぼ限界値と云える。すなわち、パケット処理に必要とされている性能は現在のテクノロジのほぼ限界に達してしまっている。

この限界に関しては、ＦＰＧＡまたはＡＳＩＣにおけるポリシング機能にも当然当てはまる。また、近年のポリサは、認定情報レート（ＣＩＲ：Committed Information Rate）及び超過情報レート（ＥＩＲ：Excess Information Rate）という２つのレートによるカ
ラーリング判定（２−ｒａｔｅ ３−ｃｏｌｏｒ ｐｏｌｉｃｅｒ（詳細は、例えばＲＦＣ２６９８，ＭＥＦ１０参照））、クラス（ＣｏＳ：Class of Service）間で溢れたトークンのやり取りを行うハイアラーキ型、さらにはフローを束ねたグループ単位でもポリシングを行うグループ型などと、むしろ複雑化傾向にある。すなわち、パケット送信権に相当するトークンの単純な加減算処理だけではなく、より複雑な処理が必要となっていることも、高速処理に対する阻害要因となっている。

図４は、このような複雑化したポリサＰＬ１の構成例を示す。ポリサＰＬ１は、ポリシング部２、トークンバケットメモリ３、及びトークン加算部４を備えている。ポリシング部２は、フロー毎のパケットの通過及び廃棄判定、グループ毎のパケットの通過及び廃棄判定、フローまたはグループ間の結果調整、フロー毎のトークン減算、グループ毎のトークン減算、及びカラーリング判定などの機能を有する。

ポリサＰＬ１におけるトークンバケットメモリ３は、フロー及びクラス単位のトークンバケットカウンタ、及びグループ単位のトークンバケットカウンタを含む。トークンバケットカウンタには、ＣＩＲ用のトークンバケットカウンタＴｃ及びＥＩＲ用のトークンバケットカウンタＴｅがある。

また、トークン加算部４は、フロー毎のトークン加算、グループ毎のトークン加算、トークンバケットカウンタＴｃまたはＴｅ間で溢れたトークンの供給（カップリング処理）、及びクラス間で溢れたトークンの供給（ハイアラーキ処理）などの機能を有する。ポリシング部２及びトークン加算部４は、トークンバケットメモリ３におけるトークンバケットカウンタＴｃ，Ｔｅのカウンタ値によって表されるトークン残量の読出及び更新に基づいて各機能を遂行する。

図４を参照して上述した複雑化ポリサＰＬ１の問題を解消するために、ポリシング機能の単純負荷分散手法を採ることが考えられる。図５は、単純負荷分散手法を採用したポリサＰＬ２の構成例を示す。

このポリサＰＬ２は、図４に示すポリサＰＬ１におけるポリシング部２、トークンバケットメモリ３、及びトークン加算部４と同一の機能を有する２系統のポリシング部２Ａ，２Ｂ、トークンバケットメモリ３Ａ，３Ｂ、及びトークン加算部４Ａ，４Ｂを備え、更にポリシング部２Ａ，２Ｂの前段にパケット振分部５を設けている。このパケット振分部５は、到着したパケットのフロー（つまり、フロー識別子ＦＩＤ）を識別することなく、第１系統のポリシング部２Ａ及び第２系統のポリシング部２Ｂに順番に振り分けるトグル機能を有する。

これにより、１４８．８Ｍｐｐｓのパケット到着速度が、最大でも半分の値７４．４Ｍｐｐｓになるので、各ポリシング部２Ａ，２Ｂは、１００Ｇｂ／ｓ時の半分の処理性能により処理可能となる。ただし、この場合、各フローのパケットが第１系統のポリシング部２Ａ及び第２系統のポリシング部２Ｂのいずれに振り分けられるか分からない。このため
、第１系統のポリシング部２Ａに付属するトークンバケットメモリ３Ａ及び第２系統のポリシング部２Ｂに付属するトークンバケットメモリ３Ｂが必要である。また、トータルの通過レートを設定値どおりに抑制するためには、トークン加算部４Ａ，４Ｂによるトークン供給レートと、トークンバケットメモリ３Ａ，３Ｂのバケットサイズとをそれぞれ半分にすることが必要となる。

しかし、このような単純負荷分散手法を採るポリサＰＬ２においては、パケット振分部５がフローを識別することなくパケットを振り分けるので、第１系統のポリシング部２Ａ及び第２系統のポリシング部２Ｂのいずれかに特定のフローのパケットが偏ることを免れない。図５においては、第１系統のポリシング部２Ａに同一フロー（フロー＃２のパケット）が集中している例を示している。

これにより、例えば、トークンバケットメモリ３Ｂのトークンバケット（token bucket）には、十分なトークン（フロー＃２対応のトークン）が存在するにも関わらず、トークンバケットメモリ３Ａのトークンバケットのトークン（フロー＃２対応のトークン）ばかりが消費されて枯渇する。

また、上述したとおり、トークン加算部４Ａ，４Ｂによるトークン供給レートは半分であるので、設定レートの半分のパケットしか通過できない。すなわち、ワーストケースにおいては、１／２のレートでしかパケットが通過できない。この分割損は分散系統数の増加に比例して大きくなる。この結果、上述したような単純負荷分散手法では、ポリシングの根幹である正確なレート制限が担保できなくなる。

課題は、ポリシングの正確性を維持しつつ、負荷分散ポリシングを可能にする技術を提供することにある。

上記課題を解決するために、ポリサは、到着パケットを公平に振り分けるパケット振分部と；個別対応の第１トークンバケット内のトークン残量に応じて、振り分けられたパケットの通過及び廃棄を判定するポリシング処理部と、前記個別対応の第１トークンバケット内のトークン残量が閾値を下回ったとき、予め定めた量を単位としたトークンの追加を要求するトークン要求部とをそれぞれ含む複数の分散ポリシング部と；前記トークンの追加を要求した前記トークン要求部対応の前記第１トークンバケットに対して、第２トークンバケット内のトークン残量に応じて、予め定めた量を単位としたトークンを供給するトークン払出部を含み、包括的なトークン管理を行う集中トークン管理部とを備える。

開示したポリサによれば、公平に振り分けられたパケットを複数の分散ポリシング部で分散処理し、かつトークンを包括的に集中管理することにより、トータルのポリシング性能を向上させ、複数の分散ポリシング部間のトークン不均衡を抑制することができる。

他の課題、特徴及び利点は、図面及び特許請求の範囲とともに取り上げられる際に、以下に記載される発明を実施するための形態を読むことにより明らかになるであろう。

図１はポリシング機能を含むパケット処理装置の構成例を示す。 図２は図１に示すパケット処理装置における各入出力インタフェース部の詳細構成例を示す。 図３は図２に示すＦＰＧＡまたはＡＳＩＣの詳細構成例を示す。 図４は複雑化したポリサの構成例を示す。 図５は単純負荷分散手法を採用したポリサの構成例を示す。 図６は一実施の形態のポリサの構成例を示す。 図７は一実施の形態のポリサの構成例を示す。 図８は一実施の形態のポリサの構成例を示す。 図９は一実施の形態のポリサの構成例を示す。 図１０は一実施の形態のポリサにおける負荷分散ポリシング動作例を説明するための図。 図１１は負荷分散ポリシング動作例におけるポリシング処理部の処理手順を説明するためのフローチャート。 図１２は負荷分散ポリシング動作例におけるトークン要求部の処理手順を説明するためのフローチャート。 図１３は負荷分散ポリシング動作例におけるトークン要求パケットのフォーマットを示す。 図１４は負荷分散ポリシング動作例におけるトークン払出部の処理手順を説明するためのフローチャート。 図１５は負荷分散ポリシング動作例における要求状態管理テーブルを示す。 図１６は負荷分散ポリシング動作例におけるトークン加算部の処理手順を説明するためのフローチャート。 図１７は負荷分散ポリシング動作例におけるトークン払出部の他の処理手順を説明するためのフローチャート。

以下、添付図面を参照して、さらに詳細に説明する。図面には好ましい実施形態が示されている。しかし、多くの異なる形態で実施されることが可能であり、本明細書に記載される実施形態に限定されない。

［ポリサの構成及び機能］
一実施の形態におけるポリサＰＬ１０の構成例を示す図６を参照すると、負荷分散ポリシング機能を含むポリサＰＬ１０は、到着したパケットを後述の複数の分散ポリシング部に均等なパケット数となるように公平に振り分けるパケット振分部１５と、パケットの通過廃棄判定を行う複数（ｎ個；ｎ≧２）の分散ポリシング部２０と、包括的なトークン管理を行う集中トークン管理部３０とを備える。

このポリサＰＬ１０は、例えば、図１に示すパケット処理装置におけるインタフェース部のＦＰＧＡまたはＡＳＩＣに配置可能である。

ポリサＰＬ１０において、各分散ポリシング部（＃１〜＃ｎ）２０は、パケット振分部１５により公平に振り分けられたパケットの通過廃棄判定、トークン減算、及びカラーリング判定を行うポリシング処理部２１と、ポリシング処理部２１に個別に付随し、フロー及びクラス単位のトークン残量を保持するトークンバケットメモリ（以下、ミニバケツと記載することもある）２２と、ミニバケツ２２のトークン残量に基づいて、パケット送信権に相当するトークンの要求（追加要求）を行うトークン要求部２３とを備える。

また、集中トークン管理部３０は、フロー及びクラス単位のトークン残量、及び必要に応じてグループ単位のトークン残量を保持するトークンバケットメモリ（以下、メインバケツと記載することもある）３１と、トークン要求部２３からの要求に基づいて、ミニバケツ２２へのトークンの供給及びメインバケツ３１へのトークン減算を行うトークン払出部３２と、分散ポリシング部２０からのトークン要求状態を保持する要求状態管理テーブル３３と、メインバケツ３１へのトークン加算、及び必要に応じてトークン溢れ処理（カ
ップリング処理、ハイアラーキ処理）などを行うトークン加算部３４とを備える。

なお、ミニバケツ２２及びメインバケツ３１における各トークン残量は、各メモリ上の認定情報レートＣＩＲ用のトークンバケットカウンタＴｃ及び超過情報レートＥＩＲ用のトークンバケットカウンタＴｅが示すカウンタ値によって表される。ここでは、カウンタＴｃ，Ｔｅ対応の各トークン残量についても同一符号Ｔｃ，Ｔｅを用いて説明する。

各分散ポリシング部２０におけるポリシング処理部２１は、ミニバケツ２２を参照し、振り分けられたパケットの通過及び廃棄を判定する。ポリシング処理部２１は、この通過廃棄判定によりパケットの通過を許可した場合、ミニバケツ２２の該当するフロー及びクラスのトークン残量からのみ通過したパケットのバイト長分のトークンを減算する。一方、ポリシング処理部２１は、トークン残量が十分でない場合、到着したパケットを廃棄するので、ミニバケツ２２におけるトークン残量は変化しない。すなわち、このポリサＰＬ１０においては、ポリシング処理部２１によるパケット単位での通過廃棄判定は、メインバケツ３１は関与せず、ミニバケツ２２のトークン残量のみに基づいて実施される。

ミニバケツ２２において、トークン残量が閾値（トークン追加要求通常閾値）を下回ると、トークン要求部２３は集中トークン管理部３０に対してトークンの追加要求を行う。このとき、トークン要求量は一定量単位とする。トークン要求部２３は、例えば、一定量が１０００ｂｙｔｅとすると、閾値を１００ｂｙｔｅ下回った場合でも、１０００ｂｙｔｅのトークンを要求し、閾値を４５００ｂｙｔｅ下回った場合は、５０００ｂｙｔｅのトークンを要求する。

トークン要求部２３からトークン追加要求を受けた集中トークン管理部３０のトークン払出部３２は、メインバケツ３１から当該フロー及びクラスのトークン残量を読み出す。トークン払出部３２が、グループポリシングを併せて行っている場合は、グループのトークン残量も読み出す。

また、トークン払出部３２は、これらの情報（トークン残量）に基づいて、メインバケツ３１に要求値以上のトークン残量があると判断した場合、トークン要求部２３からのトークン追加要求に応じて、ミニバケツ２２に対してトークンの供給（払い出し）を行うと共に、メインバケツ３１から当該供給量相当のトークンを減算する。

さらに、トークン払出部３２は、メインバケツ３１に十分な残量がないと判断した場合、要求状態管理テーブル３３にトークン追加要求状態を一旦書込んでおき、メインバケツ３１に十分なトークンが溜まった際に、要求された分散ポリシング部２０に対してトークンの供給を行う。

トークン加算部３４は、一定時間毎に、設定レートに基づいたトークン供給を行う。また、トークン加算部３４は、ＲＦＣ２６９８，ＭＥＦ１０．２規定のカップリングモードなどのトークン溢れ処理も実施する。すなわち、このポリサＰＬ１０においては、包括的なトークン管理は、メインバケツ３１においてのみ実施される。

図７に示すように、上述した一実施の形態のポリサＰＬ１０においては、集中トークン管理部３０は、トークン払出部３２の前段に、各分散ポリシング部２０のトークン要求部２３からの要求を一時的に保持する要求待ち合わせバッファ３５を更に備えてもよい。

この要求待ち合わせバッファ３５をトークン払出部３２の前段に設ける場合、トークン要求部２３によって参照される閾値テーブル２４は、トークン追加要求通常閾値（閾値１）を設定可能な構成とする。

このような要求待ち合わせバッファ３５及び閾値テーブル２４を備えることにより、トークン要求部２３からのトークン要求がバースト状態で到着した場合、要求を一時的に保持し、トークン払出部３２において順番に処理するトークン要求制御を行うことができる。

例えば、パケット振分部１５がある特定フローの連続するパケット（パケット１、パケット２）を分散ポリシング部（＃１）２０及び分散ポリシング部（＃２）２０へ振り分けた際、両方のパケットが通過判定を受け、トークン減算した結果が閾値１を下回った場合、分散ポリシング部（＃１）２０及び分散ポリシング部（＃２）２０の両方からトークン要求が到着することになる。

このような場合、分散ポリシング部（＃１）２０及び分散ポリシング部（＃２）２０のトークンの要求間隔はパケットの到着差異分しかないため、トークン払出部３２は高速な処理を要求されることになる。そこで、要求を一時的に保持する要求待ち合わせバッファ３５を設け、処理性能を超える要求は待ち合わせをさせることにより、低い処理性能での動作を可能とする。これにより、例えば、平均的には１６ｃｌｏｃｋ間隔であるが、最短では２ｃｌｏｃｋ間隔で要求がバースト到着するようなケースにおいて、トークン払出部３２の処理速度を４ｃｌｏｃｋ単位に落としたりすることが可能となる。

また、図８に示すように、上述した一実施の形態のポリサＰＬ１０においては、集中トークン管理部３０は、トークン払出部３２の前段に、各分散ポリシング部２０のトークン要求部２３からの要求を一時的に保持し、緊急用キュー及び通常用キューを有する要求待ち合わせバッファ３５を更に備えてもよい。

この形態の要求待ち合わせバッファ３５をトークン払出部３２の前段に設ける場合、トークン要求部２３によって参照される閾値テーブル２４は、トークン追加要求通常閾値（閾値１）とは別に、緊急度の高いトークン追加要求緊急閾値（閾値２）を設定可能な構成とする。

この形態の要求待ち合わせバッファ３５及び閾値テーブル２４を備えることにより、ミニバケツ２２のトークン残量が閾値２を下回った場合、トークン要求部２３は緊急トークン要求を送出し、トークン払出部３２の前段の要求待ち合わせバッファ３５は緊急トークン要求を優先して読み出すトークン要求優先制御を行うことができる。

例えば、閾値１＝１０００ｂｙｔｅ及び閾値２＝０ｂｙｔｅを閾値テーブル２４に予め設定しておく。トークン要求部２３は閾値１を下回った場合に通常のトークン要求を行うが、要求待ち合わせバッファ３５がたまたま輻輳している場合、比較的大きなパケットの到着により、一気にトークン残量が不足状態になったミニバケツ２２に対してトークン供給が間に合わない可能性がある。そこで、閾値２を下回った場合に、トークン要求部２３から緊急用のトークン追加要求を送出し、要求待ち合わせバッファ３５の緊急用キューを経由して優先的にトークン払出処理を行う。

図６及び図９を併せ参照すると、上述した一実施の形態のポリサＰＬ１０においては、集中トークン管理部３０のトークン払出部３２は、メインバケツ３１内のトークンが枯渇状態にあるフロー及びクラスに対して複数の分散ポリシング部（＃１〜＃ｎ）２０からトークン要求が到着した場合、要求状態管理テーブル３３を参照し、事前に定められた順序（例えば、若番順など）に基づいてトークンを払い出すトークン供給候補決定制御を行う。

つまり、集中トークン管理部３０のトークン払出部３２は、入力（トークン要求）がポリシングレートよりも定常的に高い場合、メインバケツ３１のトークンが枯渇状態になり、複数の分散ポリシング部２０からトークン要求が到着したような状態になりうる。このような場合、トークン加算部３４からトークンが加算され、一定量を超えると、トークンの供給が可能となるが、１つの分散ポリシング部２０に対してしか供給できない。

そこで、複数の分散ポリシング部（＃１〜＃ｎ）２０について若番順に供給することが考えられ、例えば、先ず第１番目の分散ポリシング部（＃１）２０に対してトークンが供給されることになる。

また、要求値の最も大きな分散ポリシング部２０から順にトークンを払い出すことが考えられる。図９における要求状態管理テーブル３３の例示では、要求バイト（ｂｙｔｅ）数の最も大きい第２番目の分散ポリシング部（＃２）２０に供給されることになる。

［ポリサの動作例］
次に、図６から図９に示す一実施の形態のポリサＰＬ１０における負荷分散ポリシング動作例について、図１０から図１７を併せ参照して説明する。

この負荷分散ポリシング動作例においては、図１０に示すように、ポリサＰＬ１０が３個の分散ポリシング部（＃１〜＃３）２０を備える場合について説明する。

また、ポリサＰＬ１０においては、フロー及びクラス単位での２−ｒａｔｅ ３−ｃｏｌｏｒポリシング処理（カラーリング判定）を行うものとする。さらに、一定量単位＝１０００ｂｙｔｅ（１ｋｂｙｔｅ）、閾値１（トークン追加要求通常閾値）＝１０００ｂｙｔｅ、及び閾値２（トークン追加要求緊急閾値）＝０ｂｙｔｅを前提条件とする。

１００ギガビットイーサネットインタフェース（１００ＧＥ−ＩＦ）を採るポリサＰＬ１０にパケットが到着すると、このパケットはパケット振分部１５により３個の分散ポリシング部（＃１〜＃３）２０へ順次に振り分けられる。ここでは、パケット振分部１５は、ラウンドロビン（Round Robin）により、パケットを分散ポリシング部（＃１〜＃３）
２０に均等になるように振り分ける。

分散ポリシング部（＃１〜＃３）２０における各ポリシング処理部２１は、パケット振分部１５によって振り分けられたパケットが到着したときを契機に、処理を開始する。図１１はポリシング処理部２１における処理手順を示す。

図１１に示すように、例えば、分散ポリシング部（＃１）２０におけるポリシング処理部２１は、パケットが到着した場合（図１０中のＳ１）、到着パケットからフロー識別子ＦＩＤ＝４、クラス＝Ｂ、及びパケット長＝７００ｂｙｔｅを取得する（図１１中の１１０１）。

ポリシング処理部２１は、フロー識別子ＦＩＤ＝４及びクラス＝Ｂに対応するミニバケツ情報、つまり認定情報レートＣＩＲ用トークンバケットのトークン残量Ｔｃ及び超過情報レートＥＩＲ用トークンバケットのトークン残量Ｔｅをミニバケツ２２から読み出す（取得する）（Ｓ２，１１０２）。

続いて、ポリシング処理部２１は、読み出したトークン残量Ｔｃ，Ｔｅの値、更には到着パケットのパケット長に基づいて、パケットの通過廃棄判定、カラーリング判定及びトークン減算の処理を行う。

例えば、Ｔｃ＝５００及びＴｅ＝１０００（Ｔｃ＞０）の場合、パケットはグリーン（Green）にカラーリングされて通過し、Ｔｃ（５００）からパケット長（７００）が減算
される（１１０３，１１０４）。トークン減算により、Ｔｃ＝−２００及びＴｅ＝１０００となる。

また、Ｔｃ＝−１００及びＴｅ＝１０００（Ｔｃ≦０，Ｔｅ＞０）の場合、パケットはイエロー（Yellow）にカラーリングされて通過し、Ｔｅ（１０００）からパケット長（７００）が減算される（１１０３，１１０５，１１０６）。トークン減算により、Ｔｃ＝−１００及びＴｅ＝３００となる。

さらに、Ｔｃ＝−２００及びＴｅ＝−１００（Ｔｃ≦０，Ｔｅ≦０）の場合、パケットはレッド（Red）にカラーリング判定されるので廃棄され、Ｔｃ及びＴｅの値はそのまま
となる（１１０３，１１０５，１１０７）。このような処理によって更新されたＴｃ及びＴｅの値はミニバケツ２２に書き戻される（Ｓ３，１１０８）。

トークン要求部２３は、トークン残量Ｔｃ，Ｔｅが更新されたことをポリシング処理部２１から通知されたときを契機に、処理を開始する。図１２はトークン要求部２３における処理手順を示す。

図１２に示すように、トークン要求部２３においては、ミニバケツ２２から当該フロー及びクラスのＴｃ及びＴｅ情報を読み出した（取得した）後に（図１０中のＳ４、図１２中の１２０１）、閾値テーブル２４から閾値１及び閾値２を読み出す（１２０２）。

Ｔｃ及びＴｅは個別に閾値２及び閾値１とそれぞれ比較され、ＴｃまたはＴｅが閾値２を下回っている場合は、Ｔｃ緊急トークン追加要求またはＴｅ緊急トークン追加要求が送出される（１２０３，１２０５，１２０８，１２１０）。

また、ＴｃまたはＴｅが閾値２以上であり、かつ閾値１以下である場合は、Ｔｃ通常トークン追加要求またはＴｅ通常トークン追加要求が送出される（１２０３，１２０４，１２０６，１２０８，１２０９，１２１１）。なお、ＴｃまたはＴｅが閾値２以上であり、かつ閾値１以上である場合は、特にアクションは行わず、つまり追加要求は無く処理が完了する（１２０３，１２０４，１２０７，１２０８，１２０９，１２１２）。

トークン追加要求を送出する場合、トークン要求部２３からトークン払出部３２に対して要求情報が通知される（Ｓ５）。この場合、ポリサ内パケットによる通知などが採り得るが、トークン要求パケットのフォーマットの一例を図１３に示す。

このトークン要求パケットにおいては、分散ポリシング部（＃１〜＃３）２０の番号（分散ｐｏｌ＃）、フロー識別子ＦＩＤ、クラス、及びＴｃ／Ｔｅの各情報によりトークンの要求元を通知し、緊急ｂｉｔ（例えば、１／０）により緊急要求または通常要求を通知し、要求トークン量により追加してほしいトークン量（例えば、一定量１ｋｂｙｔｅ単位）を通知する。

トークン要求部２３からトークン払出部３２に対して通知されるトークン要求パケットは一時的に要求待ち合わせバッファ３５に格納される。この場合、緊急ｂｉｔ＝１のトークン要求パケットは緊急用キューに格納され、緊急ｂｉｔ＝０のトークン要求パケットは通常用キューに格納される。

要求待ち合わせバッファ３５からの読出しはトークン払出部３２の処理に応じた速度で実施される。例えば、トークン払出部３２において、１つの要求に対する処理に４ｃｌｏ
ｃｋ相当の時間が必要な場合は、４ｃｌｏｃｋ毎にトークン要求パケットが読み出される。なお、緊急用キューからのトークン要求パケットが完全優先で読み出される。

図１４は、トークン要求パケットを受け取ったトークン払出部３２における処理手順を示す。なお、図１４においては、トークン残量Ｔｃについての要求例について記載しているが、トークン残量Ｔｅについての要求の場合も同様な処理であり、ＴｃをＴｅに置き換えれば、同様に実施できる。

まず、トークン払出部３２においては、到着したトークン要求パケットから、要求元情報、つまり分散ポリシング部（＃１）２０、フロー識別子ＦＩＤ、クラス、及びＴｃ／Ｔｅと、要求トークン量とが取得される（図１４中の１４０１）。また、取得したフロー識別子ＦＩＤ及びクラスに基づいて、メインバケツ３１から該当するＴｃ情報が読み出される（取得される）（図１０中のＳ６、図１４中の１４０２）。

次に、要求トークン量とＴｃとが比較される。このとき、Ｔｃが要求トークン量以上であれば、要求元のミニバケツ２２に対して要求されたトークン量相当のトークンが供給され、Ｔｃから要求トークン量が減算され、減算結果のＴｃ値がメインバケツ３１に書き戻される（図１０中のＳ７，Ｓ８、図１４中の１４０３，１４０４）。

一方、Ｔｃが要求トークン量未満であった場合は、Ｔｃから１ｋｂｙｔｅ未満を切り捨てた値、つまり１ｋｂｙｔｅ単位の上限量のトークンが要求元ミニバケツ２２に供給される（１４０５）。

また、供給したトークン量がＴｃから減算され、供給できなかったトークン量が要求ｂｙｔｅとして図１５に示す要求状態管理テーブル３３に記載されると共に、トークン要求中であることを示すフラグ（要求フラグ）を立てる（１４０５）。

具体的には、例えば、要求トークン量＝５０００ｂｙｔｅ及びＴｃ＝３２００ｂｙｔｅである場合、Ｔｃは要求トークン量を下回っているため、要求どおりのトークン供給はできない。よって、Ｔｃの１ｋｂｙｔｅ単位である３０００ｂｙｔｅを供給することになる。

また、Ｔｃ＝３２００−３０００＝２００ｂｙｔｅがメインバケツ３１に書き戻され、供給できなかったトークン量、つまり５０００−３０００＝２０００ｂｙｔｅが要求状態管理テーブル３３に書かれる。

上述したように、ポリサＰＬ１０においては、パケット到着を契機に、当該パケットのポリシング処理からトークン供給までの一連の処理が実施される。

一方、パケット到着を契機にしたパケットのポリシング処理からトークン供給までの一連の処理とは独立して、トークン加算部３４はフロー及びクラス毎のトークン加算を周期的に行う。図１６はトークン加算部３４におけるトークン加算契機の処理手順を示す。なお、図１６は、トークン残量Ｔｃへのトークン供給例について記載しているが、トークン残量Ｔｅへのトークン供給の場合は、図１６中のＴｃをＴｅに置き換えれば、同様に実施できる。

まず、トークン加算部３４においては、メインバケツ３１から当該フロー識別子ＦＩＤ及びクラスのＴｃ情報が取得される（図１０中のＳ９、図１６中の１６０１）。また、要求状態管理テーブル３３から当該フロー識別子ＦＩＤ、クラス、及び全てのＴｃの分散ポリシング部２０の番号についての要求フラグが取得される（Ｓ１０、１６０２）。図１５
に示す要求状態管理テーブル３３の場合、３個の要求フラグ（０）が取得される。

次に、Ｔｃに周期加算トークン量が加算される。この周期加算トークン量は設定されたＣＩＲ値に基づいて一意に決まる値である。更新されたＴｃ値は、メインバケツ３１へ書き戻される（Ｓ１１、１６０３）。続いて、この更新処理により、Ｔｃ値が１ｋｂｙｔｅ以上であり、かつ要求フラグが立っているものがあるか（１つ以上の要求フラグ＝１）を確認する（１６０４，１６０５）。この条件が満たされた場合、メインバケツ３１のトークンが枯渇していたが、払い出せる量が蓄積されたことを意味しているため、ミニバケツ２２へのトークン払出処理が開始される。

ここでは、分散ポリシング部（＃１）２０からの要求と同じルートでのトークン供給を考える。すなわち、上記条件を満たした場合、トークン要求部２３から送出されるトークン要求パケットと同じフォーマットのパケットが、トークン加算部３４から要求待ち合わせバッファ３５経由でトークン払出部３２へトークン供給指示として送出される（Ｓ１２）。このとき、トークン要求パケットには、フロー識別子ＦＩＤ、クラス、及びＴｃはトークン加算を行ったものと同じ値を記述し、分散ポリシング部２０の番号は存在しない値（例えば、０）を記述する（１６０６）。これにより、トークン払出部３２に対して払出契機が与えられる。なお、上記条件を満たさない場合、トークン加算部３４からトークン払出部３２に対するトークン要求パケットは送出されない、つまり追加要求は無い。（１６０７）。

図１７は、トークン払出部３２がトークン加算部３４から送出されたトークン供給指示（追加要求）を受けたときの処理手順を示す。すなわち、トークン払出部３２は、トークン要求パケットにおける分散ポリシング部２０の番号（識別子）を確認し、分散ｐｏｌ＃＝０であった場合には、図１７に示す処理手順を選択して実施する。

まず、トークン払出部３２においては、トークン要求パケットの到着を契機に、分散ポリシング部（＃１〜＃３）２０からの通常の要求と同様に、トークン要求パケットから分散ポリシング部２０の番号（ここでは、分散ｐｏｌ＃＝０）、フロー識別子ＦＩＤ、クラス、Ｔｃ／Ｔｅ、及び要求トークン量が取得される（図１７中の１７０１）。

次に、メインバケツ３１から当該フロー識別子ＦＩＤ及びクラスのＴｃが取得される（１７０２）。また、要求状態管理テーブル３３から当該フロー識別子ＦＩＤ、クラス、及びＴｃ／Ｔｅの全ての分散ポリシング部２０の番号と、全ての分散ポリシング部２０の番号対応の要求フラグ及び要求ｂｙｔｅとが取得される（図１０中のＳ１３、１７０３）。そして、全ての分散ポリシング部２０の番号の中から要求ｂｙｔｅが最も大きな分散ポリシング部（ｐｏｌ＿ｎ）２０を選択する（１７０４）。

次に、Ｔｃの値と分散ポリシング部（ｐｏｌ＿ｎ）２０の要求ｂｙｔｅとが比較され、Ｔｃの値が要求ｂｙｔｅ未満である場合、Ｔｃが払い出せる上限量（１ｋｂｙｔｅ単位）のトークンを分散ポリシング部（ｐｏｌ＿ｎ）２０に供給する（１７０５，１７０６）。また、Ｔｃ及び分散ポリシング部（ｐｏｌ＿ｎ）２０の要求ｂｙｔｅからそれぞれ供給トークン量が減算されて処理完了となる（１７０６）。

一方、Ｔｃの値が要求ｂｙｔｅ以上である場合、分散ポリシング部（ｐｏｌ＿ｎ）２０に対して要求ｂｙｔｅ分のトークンが供給され、Ｔｃから要求ｂｙｔｅ分のトークン量が減算される（１７０５，１７０７）。また、要求状態管理テーブル３３における分散ポリシング部（ｐｏｌ＿ｎ）２０の要求フラグ及び要求ｂｙｔｅがゼロ（０）にそれぞれ設定されて、状態更新が行われる（Ｓ１４、１７０７）。

その後、要求フラグ＝１の分散ポリシング部２０が他にも存在するかが確認され、存在する場合は、分散ポリシング部２０の選択処理（１７０４）に戻り、存在しない場合は、供給処理を終了する（１７０９）。このように、メインバケツ３１へのトークン供給を契機として、ミニバケツ２２へのトークン供給を実施してもよい。

［一実施の形態の効果］
上述した一実施の形態のポリサＰＬ１０においては、パケット振分部１５により複数の分散ポリシング部２０に負荷を分散し、かつ包括的なトークン加減算処理を集中トークン管理部３０が実施するため、パケット単位での処理が必要な分散ポリシング部２０の処理負荷を低減することが可能となる。

具体的には、１００ギガビットイーサネットインタフェース（１００ＧＥ−ＩＦ）を採るポリサＰＬ１０において、３個の分散ポリシング部（＃１〜＃３）２０を備える場合、単純な２−ｒａｔｅ ３−ｃｏｌｏｒポリシング処理は、最大で、１４８．８Ｍｐｐｓ／３＝４９．６Ｍｐｐｓから求められる処理速度で行えばよい。

一方、包括的なトークン処理の必要な集中トークン管理部３０は、パケット単位の処理から切り離され、比較的大きな一定量単位のトークン追加要求に基づいた処理でよいため、平均的な処理負荷を低減させることができる。具体的には、一定量＝１０００ｂｙｔｅとすると、１００Ｇｂｐｓ／（１０００ｂｙｔｅ×８）＝１２．５Ｍｐｐｓから求められる処理速度で行えばよい。

また、フロー単位の包括的なトークン管理は集中トークン管理部３０により行われるため、単純負荷分散におけるパケット振り分けの偏りによりポリシングの正確性が損なわれることもない。このように、ポリシング動作を機能的に分割し、高速化が必要なポイントをずらすことにより、個々の必要処理性能を落としつつ、全体では高速な処理を実現することが可能となる。

上述した他の構成を採るポリサＰＬ１０においては、瞬時的なバースト要求を均等化し、集中トークン管理部３０の処理負荷を低減させることが可能となる。

また、トークン供給優先制御により、トークンが直ぐに必要な緊急度の高いミニバケツ２２に対して優先的なトークン供給が可能となるので、メインバケツ３１にトークンがあるにもかかわらず、パケットロスが発生する確率を下げることができる。

トークン供給候補決定制御を採った場合、仕組みが単純なため回路規模を低減することができる。さらに、特定の分散ポリシング部２０への不均衡性を減らし、ポリシングの精度を高めることが可能となる。

［変形例］
上述した一実施の形態における処理はコンピュータで実行可能なプログラムとして提供され、ＣＤ−ＲＯＭやフレキシブルディスクなどの非一時的コンピュータ可読記憶媒体、さらには通信回線を経て提供可能である。

また、上述した一実施の形態における各処理はその任意の複数または全てを選択し組合せて実施することもできる。

［その他］
上述した一実施の形態及び変形例に関し、更に以下の付記を開示する。

（付記１）
到着パケットを公平に振り分けるパケット振分部と；
個別対応の第１トークンバケット内のトークン残量に応じて、振り分けられたパケットの通過及び廃棄を判定するポリシング処理部と、前記個別対応の第１トークンバケット内のトークン残量が閾値を下回ったとき、予め定めた量を単位としたトークンの追加を要求するトークン要求部とをそれぞれ含む複数の分散ポリシング部と；
前記トークンの追加を要求した前記トークン要求部対応の前記第１トークンバケットに対して、第２トークンバケット内のトークン残量に応じて、予め定めた量を単位としたトークンを供給するトークン払出部を含み、包括的なトークン管理を行う集中トークン管理部と；
を備えるポリサ。

（付記２）
前記集中トークン管理部は、前記トークン要求部からのトークン追加要求を一時的に保持する要求待ち合わせバッファを前記トークン払出部の前段に更に含み、前記要求待ち合わせバッファは、通常用キュー及び優先読出し可能な緊急用キューを有する
付記１記載のポリサ。

（付記３）
前記トークン要求部によって参照されるトークン追加要求のための前記閾値としての通常閾値とは別に、緊急度の高い緊急閾値を設定し、前記第１トークンバケット内のトークン残量が前記緊急閾値を下回ったとき、前記トークン要求部からのトークン追加要求は、前記要求待ち合わせバッファの前記緊急用キューに保持される
付記２記載のポリサ。

（付記４）
前記トークン払出部は、複数の候補が存在するとき、予め定めた順序に基づいて決定した前記第１トークンバケットに対してトークンを供給する
付記１記載のポリサ。

（付記５）
前記トークン払出部は、複数の候補が存在するとき、要求量が最も大きい前記第１トークンバケットに対してトークンを供給する
付記１記載のポリサ。

（付記６）
前記各第１トークンバケット及び前記第２トークンバケットは、少なくともフロー及びクラス単位のトークンを残量として保持する第１メモリ及び第２メモリ上にそれぞれ形成される
付記１記載のポリサ。

（付記７）
前記ポリシング処理部は、前記振り分けられたパケットの通過を許可したとき、前記第１トークンバケットのトークン残量から通過パケットのバイト長分のトークンを減算する処理を行う
付記１記載のポリサ。

（付記８）
前記トークン払出部は、前記トークン要求部からのトークン追加要求値以上のトークン残量が前記第２トークンバケットにあると判断したとき、前記第１トークンバケットに対
してトークンの供給を行うと共に、前記第２トークンバケットから供給量相当のトークンを減算する処理を行う
付記１記載のポリサ。

（付記９）
前記トークン払出部は、前記トークン要求部からのトークン追加要求値以上のトークン残量が前記第２トークンバケットにないと判断したとき、要求状態管理テーブルにトークン追加要求状態を保存する
付記１記載のポリサ。

（付記１０）
前記集中トークン管理部は、前記第２トークンバケットへの周期的なトークン加算を行うトークン加算部を更に含む
付記１記載のポリサ。

ＰＬ１０ ポリサ
１５ パケット振分部
２０ 分散ポリシング部
２１ ポリシング処理部
２２ トークンバケットメモリ（ミニバケツ）
２３ トークン要求部
２４ 閾値テーブル
３０ 集中トークン管理部
３１ トークンバケットメモリ（メインバケツ）
３２ トークン払出部
３３ 要求状態管理テーブル
３４ トークン加算部
３５ 要求待ち合わせバッファ

Claims (5)

1. 到着パケットを公平に振り分けるパケット振分部と；
   個別対応の第１トークンバケット内のトークン残量に応じて、振り分けられたパケットの通過及び廃棄を判定するポリシング処理部と、前記個別対応の第１トークンバケット内のトークン残量が閾値を下回ったとき、予め定めた量を単位としたトークンの追加を要求するトークン要求部とをそれぞれ含む複数の分散ポリシング部と；
   前記トークンの追加を要求した前記トークン要求部対応の前記第１トークンバケットに対して、第２トークンバケット内のトークン残量に応じて、予め定めた量を単位としたトークンを供給するトークン払出部を含み、包括的なトークン管理を行う集中トークン管理部と；
   を備えるポリサ。
2. 前記集中トークン管理部は、前記トークン要求部からのトークン追加要求を一時的に保持する要求待ち合わせバッファを前記トークン払出部の前段に更に含み、前記要求待ち合わせバッファは、通常用キュー及び優先読出し可能な緊急用キューを有する
   請求項１記載のポリサ。
3. 前記トークン要求部によって参照されるトークン追加要求のための前記閾値としての通常閾値とは別に、緊急度の高い緊急閾値を設定し、前記第１トークンバケット内のトークン残量が前記緊急閾値を下回ったとき、前記トークン要求部からのトークン追加要求は、前記要求待ち合わせバッファの前記緊急用キューに保持される
   請求項２記載のポリサ。
4. 前記トークン払出部は、複数の候補が存在するとき、予め定めた順序に基づいて決定した前記第１トークンバケットに対してトークンを供給する
   請求項１記載のポリサ。
5. 前記トークン払出部は、複数の候補が存在するとき、要求量が最も大きい前記第１トークンバケットに対してトークンを供給する
   請求項１記載のポリサ。

Images