(57)【要約】      （修正有）【課題】メーター処理の精度を上げる技術を提供する。【解決手段】メーター処理方法は、ダミーパケットを所定時間毎に取得し、取得したダミーパケットに基づきトークンバケットにトークンを補充し、メーター処理の実行タイミングを表すタイムスタンプを更新する処理を含む。【選択図】図５Ａ
2017017538.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサに、
ダミーパケットを所定時間毎に取得し、
取得した前記ダミーパケットに基づきトークンバケットにトークンを補充し、メーター処理の実行タイミングを表すタイムスタンプを更新する、
処理を実行させるメーター処理プログラム。
【請求項２】
前記プロセッサに、
前記タイムスタンプの前回の更新が、外部の装置から受信したパケットに基づくか判定する、
処理をさらに実行させ、
前記タイムスタンプを更新する処理において、
前記タイムスタンプの前回の更新が、前記外部の装置から受信したパケットに基づく場合に、前記トークンバケットにトークンを補充する処理及び前記タイムスタンプを更新する処理を実行する、
請求項１記載のメーター処理プログラム。
【請求項３】
前記タイムスタンプを更新する処理において、
更新前の前記タイムスタンプと今回の実行タイミングとに基づき、前記トークンバケットに補充すべきトークンの量を算出し、
算出した当該量のトークンを前記トークンバケットに補充し、
更新前の前記タイムスタンプを、前記今回の実行タイミングに更新する、
請求項１又は２記載のメーター処理プログラム。
【請求項４】
前記プロセッサに、
前記ダミーパケットのパケット長を０として前記トークンバケット内のトークン量を更新する、
処理をさらに実行させる請求項１乃至３のいずれか１つ記載のメーター処理プログラム。
【請求項５】
前記所定時間は、タイムスタンプがラップアラウンドするまでの時間より短い、
請求項１乃至４のいずれか１つ記載のメーター処理プログラム。
【請求項６】
プロセッサが、
ダミーパケットを所定時間毎に取得し、
取得した前記ダミーパケットに基づきトークンバケットにトークンを補充し、メーター処理の実行タイミングを表すタイムスタンプを更新する、
処理を実行するメーター処理方法。
【請求項７】
ダミーパケットを所定時間毎に取得する取得部と、
取得した前記ダミーパケットに基づきトークンバケットにトークンを補充し、メーター処理の実行タイミングを表すタイムスタンプを更新する更新部と、
を有するネットワーク装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットの出力レートの制御技術に関する。
【背景技術】
【０００２】
ネットワーク装置が有するＱｏＳ（Quality of Service）機能の１つであるポリサー機能は、ユーザパケットの出力レートを監視し、出力レートが基準値を超えるユーザパケットにペナルティを科す機能である。ネットワーク装置のＮＰＵ（Network Processing Unit）においては、ポリサー機能を実現するためにメーター処理（Meter Operation）が実行される。メーター処理はトークンバケット方式を用いて実現され、採用されるアルゴリズムは、例えばＭＥＦ（Metro Ethernet Forum）１０或いはＲＦＣ（Request for Comments）２６９８である。
【０００３】
図１に、ＭＥＦ１０の概要を示す。ＭＥＦ１０においては、Committed Bucket（以下、ＣＢと呼ぶ）とExcess Bucket（以下、ＥＢと呼ぶ）とが使用される。ＣＩＲ（Committed Information Rate）は、単位時間当たりにＣＢに補充されるトークンの量であり、トラフィックで最低限保証される帯域である。ＣＢＳ（Committed Burst Size）は、ＣＢに貯蔵できるトークンの最大量である。ＣＢＬ（ｔ）（Committed Bucket Level at the given time t）は、メーター処理を実行した時刻（ｔ）におけるトークンの量である。パケット長Ｐ＜＝ＣＢＬ（ｔ）である場合フレームは「Ｇｒｅｅｎ」と判定され、Ｐ＞ＣＢＬ（ｔ）である場合フレームは「Ｙｅｌｌｏｗ」と判定される。ＣＢＳを超える量のトークンは、カップリングフラグが１である場合にはＥＢにトークンが貯蔵され、カップリングフラグが０である場合には廃棄される。「Ｇｒｅｅｎ」又は「Ｙｅｌｌｏｗ」であると判定された場合、Ｐバイト分のトークンがＣＢから取り除かれる。
【０００４】
ＥＩＲ（Excess Information Rate）は、単位時間当たりにＥＢに補充されるトークンの量であり、出力レートがＣＩＲを超えた場合に一時的に使用できる帯域である。ＥＢＳ（Excess Burst Size）は、ＥＢに貯蔵できるトークンの最大量であり、ＥＢを超えた分のトークンは廃棄される。ＥＢＬ（ｔ）（Excess Bucket Level at the given time t）は、メーター処理を実行した時刻（ｔ）におけるトークンの量である。パケット長Ｐ＜＝ＥＢＬ（ｔ）である場合フレームは「Ｙｅｌｌｏｗ」と判定され、Ｐ＞ＥＢＬ（ｔ）である場合フレームは「Ｒｅｄ」と判定される。「Ｙｅｌｌｏｗ」であると判定された場合、Ｐバイト分のトークンがＥＢから取り除かれる。
【０００５】
図２に、ＲＦＣ２６９８の概要を示す。ＲＦＣ２６９８においては、ＣＢとPeak Bucket（以下、ＰＢと呼ぶ）とが使用される。ＰＩＲ（Peak Information Rate）は、単位時間当たりにＰＢに補充されるトークンの量であり、トラフィックで使用できる最大の帯域である。ＰＢＳ（Peak Burst Size）は、ＰＢに貯蔵できるトークンの最大量であり、ＰＢを超えた分のトークンは廃棄される。ＰＢＬ（ｔ）（Peak Bucket Level at the given time t）は、メーター処理を実行した時刻（ｔ）におけるトークンの量である。パケット長がＰバイトであるパケットを受信した場合には、メーター処理によってＰバイト分のトークンがＰＢから取り除かれる。Ｐ＜＝ＰＢＬ（ｔ）である場合フレームは「Ｇｒｅｅｎ ｏｒ Ｙｅｌｌｏｗ」と判定され、Ｐ＞ＰＢＬ（ｔ）である場合フレームは「Ｒｅｄ」と判定される。「Ｇｒｅｅｎ ｏｒ Ｙｅｌｌｏｗ」であると判定された場合、Ｐバイト分のトークンがＰＢから取り除かれる。
【０００６】
通常、メーター処理はネットワーク装置がユーザパケットを受信した時に実行され、上で説明したようなトークンバケットにトークンが補充される。トークンの量は、メモリ上のテーブル（以下、メーターテーブルと呼ぶ）に保存された情報に基づき算出される。ＲＦＣ２６９８の場合、ＣＩＲ＊（今回のアクセス時点−タイムスタンプ）に相当する量のトークンがＣＢＬに補充され、ＰＩＲ＊（今回のアクセス時点−タイムスタンプ）に相当する量のトークンがＰＢＬに補充される。タイムスタンプは前回のアクセス時点（すなわち、メーター処理を前回実行したタイミング）を表し、メーターテーブルに保存されている。
【０００７】
但し、タイムスタンプの保存領域のビット幅は有限であるため、タイムスタンプが一定時間でラップアラウンドする。そのため、しばらくユーザパケットを受信しておらず、前回メーターテーブルにアクセスした時点から今回メーターテーブルにアクセスした時点までの間にタイムスタンプがラップアラウンドした場合には、適切な量のトークンがトークンバケットに補充されない。
【０００８】
図３を用いて、この現象について説明する。図３においては、タイムスタンプが「２０００」である時点においてユーザパケットＡを受信しており、タイムスタンプが「８０００」である時点においてユーザパケットＢを受信しているが、２つの時点の間でタイムスタンプのラップアラウンドが発生している。ＲＦＣ２６９８の場合、本来はＣＩＲ＊（期間３０２）及びＰＩＲ＊（期間３０２）によってトークンの量が算出されるべきであるが、ユーザパケットＢを受信した時点におけるタイムスタンプが「８０００」であるため、ＣＩＲ＊（期間３０１）及びＰＩＲ＊（期間３０１）によってトークンの量が算出される。そのため、適切な量のトークンがトークンバケットに補充されず、メーター処理の精度が下がってしまう。
【０００９】
図４に、タイムスタンプのラップアラウンドが発生した場合における出力レートの一例を示す。通常は、図４における出力４０１及び４０４のように、パケットが流れ始めた瞬間に出力レートが上昇するようなバースト出力が発生し、以降は設定レートに従った出力が得られる。しかしながら、タイムスタンプがラップアラウンドした場合にはバースト出力が発生せず、図４における出力４０２及び４０３のような出力が得られる。なお、タイムスタンプの保存領域のビット幅を増やせばラップアラウンドの発生頻度を少なくすることができるが、メモリリソースを増やす必要があるためコストの増大につながる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００８−２８８８８号公報
【特許文献２】特開２００５−２６９０００号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
従って、本発明の目的は、１つの側面では、メーター処理の精度を上げるための技術を提供することである。
【課題を解決するための手段】
【００１２】
本発明に係るメーター処理方法は、ダミーパケットを所定時間毎に取得し、取得したダミーパケットに基づきトークンバケットにトークンを補充し、メーター処理の実行タイミングを表すタイムスタンプを更新する処理を含む。
【発明の効果】
【００１３】
１つの側面では、メーター処理の精度を上げることができるようになる。
【図面の簡単な説明】
【００１４】
【図１】図１は、ＭＥＦ１０の概要を示す図である。
【図２】図２は、ＲＦＣ２６９８の概要を示す図である。
【図３】図３は、タイムスタンプがラップアラウンドした場合におけるトークンの補充について説明するための図である。
【図４】図４は、出力レートの一例を示す図である。
【図５Ａ】図５Ａは、ネットワーク装置の構成を示す図である。
【図５Ｂ】図５Ｂは、第１プロトコル処理部の機能ブロック図である。
【図６】図６は、メーターテーブルに格納されるデータの一例を示す図である。
【図７】図７は、第１の実施の形態の概要を示す図である。
【図８】図８は、第１の実施の形態における第１プロトコル処理部が実行する処理の処理フローを示す図である。
【図９】図９は、第１の実施の形態における第２プロトコル処理部が実行する処理の処理フローを示す図である。
【図１０】図１０は、第２の実施の形態の概要を示す図である。
【図１１】図１１は、第２の実施の形態における第１プロトコル処理部が実行する処理の処理フローを示す図である。
【図１２】図１２は、第２の実施の形態における第２プロトコル処理部が実行する処理の処理フローを示す図である。
【図１３】図１３は、ＮＰＵを搭載したネットワーク装置のハードウエア構成の一例を示す図である。
【図１４】図１４は、一般的なＮＰＵの機能ブロック図である。
【発明を実施するための形態】
【００１５】
［実施の形態１］
図５Ａに、本実施の形態におけるネットワーク装置１の構成を示す。ネットワーク装置１は、ＮＰＵ１００と、ＣＰＵ（Central Processing Unit）１１０と、例えばＳＲＡＭ（Static Random Access Memory）であるＲＡＭ１２０と、送受信部１３１乃至１３３と、パケット生成部１４０とを有する。ＮＰＵ１００は、ネットワーク装置に搭載されるプロセッサであり、プロトコルスタック（例えばＬ１レイヤやＬ２レイヤなど）の各層でプログラミングが可能なチップである。ＮＰＵ１００は、ＣＰＵ１１０と、ＲＡＭ１２０と、送受信部１３１乃至１３３と、パケット生成部１４０とにバスによって接続される。図５Ａにおいて、破線はパケットのフローを表し、太線は第１プロトコル処理部１０４からメーターテーブル１２１へのアクセス及び第２プロトコル処理部１０５からメーターテーブル１２１へのアクセスを表す。
【００１６】
本実施の形態の処理を実行するためのファームウエアはＮＰＵ１００のプロセッサによって実行され、第１プロトコル処理部１０４及び第２プロトコル処理部１０５を実現する。第１プロトコル処理部１０４は、送受信部１３１乃至１３３から受信したユーザパケットを受信バッファ１０１から取り出し、取り出したユーザパケットに対してプロトコル処理を実行する。プロトコル処理のうちメーター処理（本実施の形態においては、ＲＦＣ２６９８のメーター処理とする）においては、ＲＡＭ１２０に格納されたメーターテーブル１２１に対するアクセスが行われる。送信可能なパケットは送信バッファ１０２に格納され、送受信部１３１乃至１３３のいずれかから宛先へ送信される。なお、ＮＰＵ１００を搭載したネットワーク装置及びプロトコル処理の詳細については、付録を参照されたい。
【００１７】
第２プロトコル処理部１０５は、パケット生成部１４０によって定期的に生成されるパケットをバッファ１０３から取り出し、パケット長Ｐを０としてメーター処理を定期的に実行する。第２プロトコル処理部１０５は、メーター処理後のパケットを廃棄する。
【００１８】
パケット生成部１４０は、所定時間毎にダミーパケットを生成し、ＮＰＵ１００のバッファ１０３に出力する。パケット生成部１４０は、例えばＦＰＧＡ（Field Programmable Gate Array）によって実装される。
【００１９】
送受信部１３１乃至１３３は、パケットの送信及び受信を行う。
【００２０】
図５Ｂに、第１プロトコル処理部１０４の機能ブロック図を示す。第１プロトコル処理部１０４は、第１処理部１０４１と、第２処理部１０４２とを含む。第１処理部１０４１は、メーター処理の主要な部分を実行し、パケットのカラーについての判定結果を第２処理部１０４２に通知する。第２処理部１０４２は、判定結果に従いパケットを処理する。なお、第１プロトコル処理部１０４はその他の処理を実行する処理部をも含むが、本実施の形態とは直接関係しないのでここでは説明を省略する。詳細については付録を参照されたい。
【００２１】
図６に、ＲＡＭ１２０に格納されるメーターテーブル１２１の一例を示す。メーターテーブル１２１は入力ポート番号或いはＶＬＡＮ（Virtual Local Area Network）毎に用意され、メーターＩＤ（IDentifier）によって識別される。ＲＦＣ２６９８の場合、各メーターテーブル１２１には、ＰＢＬの値と、ＣＢＬの値と、タイムスタンプと、ＣＩＲの値と、ＣＢＳの値と、ＰＩＲの値と、ＰＢＳの値とが格納される。
【００２２】
図７を用いて、第１の実施の形態の概要について説明する。第１の実施の形態においては、フォアグラウンドにおいて第１プロトコル処理部１０４がメーターテーブル１２１にアクセスすることとは別に、バックグラウンドにおいて第２プロトコル処理部１０５が定期的にメーターテーブル１２１にアクセスする。図７の例では、４０００ミリ秒ごとに第２プロトコル処理部１０５がメーターテーブル１２１にアクセスし、トークンの補充及びタイムスタンプの更新を実行する。このようにすれば、パケットＡを受信してからパケットＢを受信するまでの時間（１６０００ミリ秒）に相当するトークンをトークンバケットに補充できるようになるので、出力レートが低下することを防ぐことができる。
【００２３】
次に、図８及び図９を用いて、第１の実施の形態において行われる処理について詳細に説明する。まず、図８を用いて、第１プロトコル処理部１０４が実行する処理について説明する。
【００２４】
送受信部１３１乃至１３３のいずれかが、ネットワークからユーザパケットを受信する（図８：ステップＳ１）。受信されたユーザパケットは受信バッファ１０１に出力され、第１プロトコル処理部１０４によって取り出される。ユーザパケットは、メーターＩＤを含む。
【００２５】
第１プロトコル処理部１０４の第１処理部１０４１は、メーター処理の前までに実行すべきプロトコル処理を、受信したユーザパケット（以下、受信パケットと呼ぶ）に対して実行する。そして、第１処理部１０４１は、ＲＡＭ１２０における、受信パケットに含まれるメーターＩＤに対応するメーターテーブル１２１にアクセスする（ステップＳ３）。具体的には、第１処理部１０４１は、メーターテーブル１２１に格納されたＣＢＬ及びＰＢＬを更新する（ステップＳ５）。ステップＳ５においては、ＣＩＲ＊（今回のアクセス時刻−メーターテーブル１２１に格納されたタイムスタンプ）がＣＢＬに加算され、ＰＩＲ＊（今回のアクセス時刻−メーターテーブル１２１に格納されたタイムスタンプ）がＰＢＬに加算される。今回のアクセス時刻は、例えば、ステップＳ３の実行タイミングである。
【００２６】
第１処理部１０４１は、メーターテーブル１２１に格納されているタイムスタンプを、今回のアクセス時刻で更新する（ステップＳ７）。
【００２７】
第１処理部１０４１は、Ｐ＞ＰＢＬが成立するか判定する（ステップＳ９）。Ｐ＞ＰＢＬが成立する場合（ステップＳ９：Ｙｅｓルート）、第１処理部１０４１は、受信パケットのカラーが「赤」であることを示す応答を生成し（ステップＳ１１）、応答及び受信パケットを第２処理部１０４２に出力する。これに応じ、第２処理部１０４２は、受信パケットを廃棄する（ステップＳ１３）。そして処理は終了する。
【００２８】
一方、Ｐ＞ＰＢＬが成立しない場合（ステップＳ９：Ｎｏルート）、第１処理部１０４１は、Ｐ＞ＣＢＬが成立するか判定する（ステップＳ１５）。Ｐ＞ＣＢＬが成立する場合（ステップＳ１５：Ｙｅｓルート）、第１処理部１０４１は、受信パケットのカラーが「黄」であることを示す応答を生成し（ステップＳ１７）、応答及び受信パケットを第２処理部１０４２に出力する。第２処理部１０４２は、受信パケットのカラーが「黄」であるので、受信パケットを廃棄せず、次のプロトコル処理を実行する処理部に受信パケットを出力する。そしてステップＳ２１の処理に移行する。
【００２９】
一方、Ｐ＞ＣＢＬが成立しない場合（ステップＳ１５：Ｎｏルート）、第１処理部１０４１は、受信パケットのカラーが「緑」であることを示す応答を生成し（ステップＳ１９）、応答及び受信パケットを第２処理部１０４２に出力する。第２処理部１０４２は、受信パケットのカラーが「緑」であるので、受信パケットを廃棄せず、次のプロトコル処理を実行する処理部に受信パケットを出力する。
【００３０】
第１処理部１０４１は、メーターテーブル１２１に格納されたＣＢＬ及びＰＢＬを、パケット長Ｐの分だけ減らす（ステップＳ２１）。そして処理を終了する。
【００３１】
以上のような処理を実行すれば、ユーザパケットの受信に応じてメーターテーブル１２１を更新できるようになる。
【００３２】
次に、図９を用いて、第２プロトコル処理部１０５が実行する処理について説明する。
【００３３】
まず、パケット生成部１４０は、各メーターＩＤについてダミーパケットを生成し（図９：ステップＳ３１）、バッファ１０３に出力する。所定時間は、タイムスタンプがラップアラウンドするのに要する時間よりも短いとする。各ダミーパケットはメーターＩＤを含み、ステップＳ３１においてはメーターＩＤの数だけダミーパケットが生成される。但し、説明を簡単にするため、以下では１つのダミーパケットに対して行われる処理に着目して説明を行う。
【００３４】
第２プロトコル処理部１０５は、バッファ１０３からのダミーパケットの取得及びメーターテーブル１２１（ここでは、ダミーパケットに含まれるメーターＩＤに対応するメーターテーブル）へのアクセスを行う（ステップＳ３３）。具体的には、第２プロトコル処理部１０５は、メーターテーブル１２１に格納されたＣＢＬ及びＰＢＬを更新する（ステップＳ３５）。ステップＳ３５においては、ＣＩＲ＊（今回のアクセス時刻−メーターテーブル１２１に格納されたタイムスタンプ）がＣＢＬに加算され、ＰＩＲ＊（今回のアクセス時刻−メーターテーブル１２１に格納されたタイムスタンプ）がＰＢＬに加算される。今回のアクセス時刻は、例えば、ステップＳ３３の実行タイミングである。
【００３５】
第２プロトコル処理部１０５は、メーターテーブル１２１に格納されているタイムスタンプを、今回のアクセス時刻で更新し、パケット長Ｐを０としてＣＢＬ及びＰＢＬからトークンを取り除く（ステップＳ３７）。但し、Ｐ＝０であるのでＰＢＬ及びＣＢＬは変化しない。このような処理を実行すれば、ダミーパケットによってトークンが消費されることを回避できる。
【００３６】
第２プロトコル処理部１０５は、ダミーパケットを廃棄し（ステップＳ３８）、前回メーター処理を実行してから所定時間が経過したか判定する（ステップＳ３９）。前回メーター処理を実行してから所定時間が経過していない場合（ステップＳ３９：Ｎｏルート）、ステップＳ３９の処理に戻る。一方、前回メーター処理を実行してから所定時間が経過した場合（ステップＳ３９：Ｙｅｓルート）、ステップＳ３１の処理に戻る。
【００３７】
以上のように、所定時間毎にトークンバケットにトークンを補充するので、たとえユーザパケットを受信しない期間が長くなったとしても、実際に補充すべき量とは極端に異なる量のトークンが補充されることが無くなる。これにより、メーター処理の精度が低下することを抑制できるようになる。
【００３８】
なお、タイムスタンプの更新に利用するタイマの精度を低くすることでラップアラウンドが発生するまでの時間を長くすることも考えられるが、トークンの補充量が適切に計算されなくなるという問題がある。また、タイムスタンプを使用しない方法として、定期的に定量的なトークンを補充することも考えられるが、更新されるメーターテーブルの数が多くなると処理が遅延し、更新タイミングがずれて、バースト出力が得られなくなる。よって、これらの方法よりも本実施の形態の方法の方が優れている。
【００３９】
［実施の形態２］
図１０を用いて、第２の実施の形態の概要について説明する。第２の実施の形態においては、第１の実施の形態と同様、フォアグラウンドにおいて第１プロトコル処理部１０４がメーターテーブル１２１にアクセスすることとは別に、バックグラウンドにおいて第２プロトコル処理部１０５が定期的にメーターテーブル１２１にアクセスする。但し、必ずしもトークンの補充及びタイムスタンプの更新を実行するわけではなく、前回のアクセスがユーザパケットによるものではない（すなわち、メーターテーブル１２１におけるフラグが０である）場合に限りトークンの補充及びタイムスタンプの更新を実行する。図１０の例では、バックグラウンドの処理によってメーターテーブル１２１へのアクセスが３回行われるが、実際にトークンの補充及びタイムスタンプの更新が行われるのは１回だけである。このように、トークンの補充及びタイムスタンプの更新を、一定の条件を満たす場合にのみ行うようにすることで、ＮＰＵ１００の処理負荷が高くなることを抑制できるようになる。
【００４０】
次に、図１１及び図１２を用いて、第２の実施の形態において行われる処理について詳細に説明する。まず、図１１を用いて、第１プロトコル処理部１０４が実行する処理について説明する。
【００４１】
送受信部１３１乃至１３３のいずれかが、ネットワークからユーザパケットを受信する（図１１：ステップＳ４１）。受信されたユーザパケットは受信バッファ１０１に出力され、第１プロトコル処理部１０４によって取り出される。ユーザパケットは、メーターＩＤを含む。
【００４２】
第１プロトコル処理部１０４の第１処理部１０４１は、メーター処理の前までに実行すべきプロトコル処理を、受信したユーザパケット（以下、受信パケットと呼ぶ）に対して実行する。そして、第１処理部１０４１は、ＲＡＭ１２０における、受信パケットに含まれるメーターＩＤに対応するメーターテーブル１２１にアクセスする（ステップＳ４３）。具体的には、第１処理部１０４１は、メーターテーブル１２１に格納されたＣＢＬ及びＰＢＬを更新する（ステップＳ４５）。ステップＳ４５においては、ＣＩＲ＊（今回のアクセス時刻−メーターテーブル１２１に格納されたタイムスタンプ）がＣＢＬに加算され、ＰＩＲ＊（今回のアクセス時刻−メーターテーブル１２１に格納されたタイムスタンプ）がＰＢＬに加算される。今回のアクセス時刻は、例えば、ステップＳ４３の実行タイミングである。
【００４３】
第１処理部１０４１は、メーターテーブル１２１に格納されているタイムスタンプを、今回のアクセス時刻で更新し（ステップＳ４７）、メーターテーブル１２１に格納されているフラグを１に設定する（ステップＳ４９）。
【００４４】
第１処理部１０４１は、Ｐ＞ＰＢＬが成立するか判定する（ステップＳ５１）。Ｐ＞ＰＢＬが成立する場合（ステップＳ５１：Ｙｅｓルート）、第１処理部１０４１は、受信パケットのカラーが「赤」であることを示す応答を生成し（ステップＳ５３）、応答及び受信パケットを第２処理部１０４２に応答を出力する。これに応じ、第２処理部１０４２は、受信パケットを廃棄する（ステップＳ５５）。そして処理は終了する。
【００４５】
一方、Ｐ＞ＰＢＬが成立しない場合（ステップＳ５１：Ｎｏルート）、第１処理部１０４１は、Ｐ＞ＣＢＬが成立するか判定する（ステップＳ５７）。Ｐ＞ＣＢＬが成立する場合（ステップＳ５７：Ｙｅｓルート）、第１処理部１０４１は、受信パケットのカラーが「黄」であることを示す応答を生成し（ステップＳ５９）、応答及び受信パケットを第２処理部１０４２に出力する。第２処理部１０４２は、受信パケットのカラーが「黄」であるので、受信パケットを廃棄せず、次のプロトコル処理を実行する処理部に受信パケットを出力する。そしてステップＳ６３の処理に移行する。
【００４６】
一方、Ｐ＞ＣＢＬが成立しない場合（ステップＳ５７：Ｎｏルート）、第１処理部１０４１は、受信パケットのカラーが「緑」であることを示す応答を生成し（ステップＳ６１）、応答及び受信パケットを第２処理部１０４２に出力する。第２処理部１０４２は、受信パケットのカラーが「緑」であるので、受信パケットを廃棄せず、次のプロトコル処理を実行する処理部に受信パケットを出力する。
【００４７】
第１処理部１０４１は、メーターテーブル１２１に格納されたＣＢＬ及びＰＢＬを、パケット長Ｐの分だけ減らす（ステップＳ６３）。そして処理を終了する。
【００４８】
以上のような処理を実行すれば、ユーザパケットの受信に応じてメーターテーブル１２１を更新し、また、ユーザパケットに基づくアクセスが行われたことを第２プロトコル処理部１０５が確認できるようになる。
【００４９】
次に、図１２を用いて、第２プロトコル処理部１０５が実行する処理について説明する。
【００５０】
まず、パケット生成部１４０は、各メーターＩＤについてダミーパケットを生成し（図１２：ステップＳ７１）、バッファ１０３に出力する。所定時間は、タイムスタンプがラップアラウンドするのに要する時間よりも短いとする。各ダミーパケットはメーターＩＤを含み、ステップＳ７１においてはメーターＩＤの数だけダミーパケットが生成される。但し、説明を簡単にするため、以下では１つのダミーパケットに対して行われる処理に着目して説明を行う。
【００５１】
第２プロトコル処理部１０５は、バッファ１０３からのダミーパケットの取得及びメーターテーブル１２１（ここでは、ダミーパケットに含まれるメーターＩＤに対応するメーターテーブル１２１）へのアクセスを行い（ステップＳ７３）、メーターテーブル１２１に格納されたフラグが１に設定されているか判定する（ステップＳ７５）。
【００５２】
フラグが１に設定されている場合（ステップＳ７５：Ｙｅｓルート）、第２プロトコル処理部１０５は、メーターテーブル１２１に格納されているフラグを０に設定する（ステップＳ７７）。そしてステップＳ８５の処理に移行する。
【００５３】
一方、フラグが１に設定されていない場合（ステップＳ７５：Ｎｏルート）、第２プロトコル処理部１０５は、メーターテーブル１２１に格納されたＣＢＬ及びＰＢＬを更新する（ステップＳ８１）。ステップＳ８１においては、ＣＩＲ＊（今回のアクセス時刻−メーターテーブル１２１に格納されたタイムスタンプ）がＣＢＬに加算され、ＰＩＲ＊（今回のアクセス時刻−メーターテーブル１２１に格納されたタイムスタンプ）がＰＢＬに加算される。今回のアクセス時刻は、例えば、ステップＳ７３の実行タイミングである。
【００５４】
第２プロトコル処理部１０５は、メーターテーブル１２１に格納されているタイムスタンプを、今回のアクセス時刻で更新し、パケット長Ｐを０としてＣＢＬ及びＰＢＬからトークンを取り除く（ステップＳ８３）。但し、Ｐ＝０であるのでＰＢＬ及びＣＢＬは変化しない。このような処理を実行すれば、ダミーパケットによってトークンが消費されることを回避できる。
【００５５】
第２プロトコル処理部１０５は、ダミーパケットを廃棄し（ステップＳ８５）、前回メーター処理を実行してから所定時間が経過したか判定する（ステップＳ８７）。前回メーター処理を実行してから所定時間が経過していない場合（ステップＳ８７：Ｎｏルート）、ステップＳ８７の処理に戻る。一方、前回メーター処理を実行してから所定時間が経過した場合（ステップＳ８７：Ｙｅｓルート）、ステップＳ７１の処理に戻る。
【００５６】
以上のような処理を実行すれば、ＮＰＵ１００の処理負荷を低い状態に維持しつつ、メーター処理の精度が低下することを抑制できるようになる。
【００５７】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明したネットワーク装置１の構成は実際のプログラムモジュール構成に一致しない場合もある。
【００５８】
また、上で説明したテーブル構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。
【００５９】
また、パケット生成部１４０を設けるのではなく、ＣＰＵ１１０が定期的にダミーパケットを生成するようにしてもよい。また、ネットワーク装置１の外部の装置から定期的にダミーパケットを取得するようにしてもよい。
【００６０】
［付録］
本付録においては、本実施の形態に関連する技術について説明する。
【００６１】
１．ＮＰＵを搭載したネットワーク装置
図１３に、ＮＰＵを搭載したネットワーク装置の構成の一例を示す図である。ネットワーク装置は、ギガビットイーサネット（「イーサネット」は登録商標）の物理層回路（「ＧｂＥ−ＰＨＹ」と表されている）１３０３に接続される複数のＳＦＰ（Small Form-Factor Pluggable）モジュール１３０１と、１０ギガビットイーサネットの物理層回路（「１０ＧＥ−ＰＨＹ」と表されている）１３０４に接続される複数のＳＦＰモジュール１３０２と、ＦＰＧＡ１３０５と、ＤＤＲ３（Double-Data-Rate3） ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）１３０６と、ＣＰＵ１３０７と、ＣＰＵ１３０７へのアクセス（例えば、制御及び監視）をアウトバンドで行うためのＬＣＮ（LAN Control Network）１３０８と、ＣＰＵ１３０７へのアクセスをインバンドで行うためのインバンドスイッチ（「Ｉｎｂａｎｄ−ＳＷ」と表されている）１３０９と、ＮＰＵ１３１０と、ＴＣＡＭ（Ternary Content Addressable Memory）１３１４と、ＤＤＲ２（Double-Data-Rate2） ＳＤＲＡＭ及びＳＲＡＭ、又は、ＱＤＲ２（Quad Data Rate 2）のＳＲＡＭを含むメモリ１３１５と、ＤＤＲ３ ＳＤＲＡＭ １３１６とを有する。ＮＰＵ１３１０は、ＮＳＥ（Network Search Engine）１３１１と、仮想アドレスから物理アドレスへの変換を高速化するＬＡＳ（Look-Aside SRAM）１３１２及びＬＡＤ（Look-Aside DRAM）１３１３とを有する。図１３において、ＱＳＧＭＩＩはQuad Serial Gigabit Media Independent Interfaceの略であり、ＸＡＵＩは10 Gigabit Attachment Unit Interfaceの略であり、ＰＣＩｅはPeripheral Component Interconnectの略であり、ＳＧＭＩＩはSerial Gigabit Media Independent Interfaceの略である。
【００６２】
２．プロトコル処理
図１４に、一般的なＮＰＵの機能ブロック図の一例を示す。ＮＰＵにおいては、ＦＰＧＡによるＴＳ−１０００処理の結果に基づきＶＩＤ（VLAN IDentifier）変換が実行される。ＶＩＤ変換からポリサー処理（この処理がメーター処理に相当する）までの処理は、Ｉｎｇｒｅｓｓ処理と呼ばれる。Ｉｎｇｒｅｓｓ処理の後に行われる処理であって、マルチキャストを行うためのマルチキャスト処理からシェイパー処理までの処理は、Ｅｇｒｅｓｓ処理と呼ばれる。
【００６３】
以上で付録を終了する。
【００６４】
以上述べた本発明の実施の形態をまとめると、以下のようになる。
【００６５】
本実施の形態に係るメーター処理方法は、（Ａ）ダミーパケットを所定時間毎に取得し、（Ｂ）取得したダミーパケットに基づきトークンバケットにトークンを補充し、メーター処理の実行タイミングを表すタイムスタンプを更新する処理を含む。
【００６６】
このようにすれば、タイマがラップアラウンドした場合においてもトークンバケット内のトークン量が適切な値に設定されるので、メーター処理の精度を上げることができるようになる。
【００６７】
また、本メーター処理方法は、（Ｃ）タイムスタンプの前回の更新が、外部の装置から受信したパケットに基づくか判定する処理をさらに含んでもよい。そして、（ｂ１）タイムスタンプの前回の更新が、外部の装置から受信したパケットに基づく場合に、トークンバケットにトークンを補充する処理及びタイムスタンプを更新する処理を実行してもよい。このようにすれば、必要以上に処理を実行することを抑制できるので、プロセッサの処理負荷を減らせるようになる。
【００６８】
また、タイムスタンプを更新する処理において、（ｂ２）更新前のタイムスタンプと今回の実行タイミングとに基づき、トークンバケットに補充すべきトークンの量を算出し、（ｂ３）算出した当該量のトークンをトークンバケットに補充し、（ｂ４）更新前のタイムスタンプを、今回の実行タイミングに更新してもよい。これにより、パケットの転送量を適切に制御できるようになる。
【００６９】
また、本メーター処理方法は、（Ｄ）ダミーパケットのパケット長を０としてトークンバケット内のトークン量を更新する処理をさらに含んでもよい。このようにすれば、ダミーパケットによってトークンが消費されることを回避できるようになる。
【００７０】
また、上で述べた所定時間は、タイムスタンプがラップアラウンドするまでの時間より短くてもよい。
【００７１】
なお、上記方法による処理をプロセッサに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。
【００７２】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【００７３】
（付記１）
プロセッサに、
ダミーパケットを所定時間毎に取得し、
取得した前記ダミーパケットに基づきトークンバケットにトークンを補充し、メーター処理の実行タイミングを表すタイムスタンプを更新する、
処理を実行させるメーター処理プログラム。
【００７４】
（付記２）
前記プロセッサに、
前記タイムスタンプの前回の更新が、外部の装置から受信したパケットに基づくか判定する、
処理をさらに実行させ、
前記タイムスタンプを更新する処理において、
前記タイムスタンプの前回の更新が、前記外部の装置から受信したパケットに基づく場合に、前記トークンバケットにトークンを補充する処理及び前記タイムスタンプを更新する処理を実行する、
付記１記載のメーター処理プログラム。
【００７５】
（付記３）
前記タイムスタンプを更新する処理において、
更新前の前記タイムスタンプと今回の実行タイミングとに基づき、前記トークンバケットに補充すべきトークンの量を算出し、
算出した当該量のトークンを前記トークンバケットに補充し、
更新前の前記タイムスタンプを、前記今回の実行タイミングに更新する、
付記１又は２記載のメーター処理プログラム。
【００７６】
（付記４）
前記プロセッサに、
前記ダミーパケットのパケット長を０として前記トークンバケット内のトークン量を更新する、
処理をさらに実行させる付記１乃至３のいずれか１つ記載のメーター処理プログラム。
【００７７】
（付記５）
前記所定時間は、タイムスタンプがラップアラウンドするまでの時間より短い、
付記１乃至４のいずれか１つ記載のメーター処理プログラム。
【００７８】
（付記６）
プロセッサが、
ダミーパケットを所定時間毎に取得し、
取得した前記ダミーパケットに基づきトークンバケットにトークンを補充し、メーター処理の実行タイミングを表すタイムスタンプを更新する、
処理を実行するメーター処理方法。
【００７９】
（付記７）
ダミーパケットを所定時間毎に取得する取得部と、
取得した前記ダミーパケットに基づきトークンバケットにトークンを補充し、メーター処理の実行タイミングを表すタイムスタンプを更新する更新部と、
を有するネットワーク装置。
【符号の説明】
【００８０】
１  ネットワーク装置    １００  ＮＰＵ
１０１  受信バッファ    １０２  送信バッファ
１０３  バッファ    １０４  第１プロトコル処理部
１０５  第２プロトコル処理部    １１０  ＣＰＵ
１２０  ＲＡＭ    １２１  メーターテーブル
１３１，１３２，１３３  送受信部    １４０  パケット生成部
【図１】
2017017538.tif 000003
【図２】
2017017538.tif 000004
【図３】
2017017538.tif 000005
【図４】
2017017538.tif 000006
【図５Ａ】
2017017538.tif 000007
【図５Ｂ】
2017017538.tif 000008
【図６】
2017017538.tif 000009
【図７】
2017017538.tif 000010
【図８】
2017017538.tif 000011
【図９】
2017017538.tif 000012
【図１０】
2017017538.tif 000013
【図１１】
2017017538.tif 000014
【図１２】
2017017538.tif 000015
【図１３】
2017017538.tif 000016
【図１４】
2017017538.tif 000017