処理中

しばらくお待ちください...

設定

設定

出願の表示

1. WO2020110725 - トラフィックモニタリング方法、トラフィックモニタリング装置、及びプログラム

Document

明 細 書

発明の名称 トラフィックモニタリング方法、トラフィックモニタリング装置、及びプログラム

技術分野

0001  

背景技術

0002   0003   0004  

先行技術文献

非特許文献

0005  

発明の概要

発明が解決しようとする課題

0006   0007   0008   0009   0010   0011   0012   0013   0014   0015   0016   0017   0018  

課題を解決するための手段

0019   0020   0021   0022   0023   0024   0025   0026  

発明の効果

0027  

図面の簡単な説明

0028  

発明を実施するための形態

0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044  

符号の説明

0045  

請求の範囲

1   2   3   4   5   6   7   8  

図面

1   2   3   4   5   6   7   8   9   10   11   12  

明 細 書

発明の名称 : トラフィックモニタリング方法、トラフィックモニタリング装置、及びプログラム

技術分野

[0001]
 本開示は、汎用CPUと汎用NIC上で動作するトラフィックモニタリングのため方法、装置及びプログラムに関する。

背景技術

[0002]
 IPネットワークにおいてトラフィックモニタリングは、日々の管理、運用、及び課金に必要な技術であるとともに、設備計画、収容設計、トラフィックエンジニアリング及びセキュリティ対応に必要な情報を提供する重要なタスクである。
[0003]
 高速、高精度、及びリアルタイムなモニタリング用途には専用ハードウエアが利用されている。しかし、専用ハードウエアは、高コストであり、自由に観測箇所を追加することが困難とう課題がある。一方、モニタリングを汎用CPUと汎用NICを用いたソフトウェアで実現することもできる。汎用CPUと汎用NICを用いることで、コストダウンを図ることができ、多数の場所に設置してモニタリングすることや必要に応じてモニタリングポイントを設置することができる。しかし、ソフトウェアによるパケット処理性能は専用ハードウエアと比較すると低い。このため、複数のCPUによるマルチコアで性能の向上を図ることが検討されている。
[0004]
 マルチコアでトラフィックモニタリングを行う場合、性能を発揮するには次の2点が必要とされている。
1.トラフィックを各コアに均等に分散させるためNICでReceive Side Scaling(RSS)(例えば、非特許文献1を参照。)を有効にする。
2.各コアを独立に動作させる(コア間に相互作用があった場合、同期処理が必要となるため性能が低下する)。

先行技術文献

非特許文献

[0005]
非特許文献1 : Intel(登録商標)82576EB Gigabit Ethernet Controller Datasheet, https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/82576eb-gigabit-ethernet-controller-datasheet.pdf(2018年11月6日検索)
非特許文献2 : Pat Morin, “Open Data Structures”, AU Press Athabasca University, 2013, http://www.aupress.ca/index.php/books/120226(2018年11月6日検索)

発明の概要

発明が解決しようとする課題

[0006]
 しかしながら、マルチコアでトラフィックモニタリングを行う場合、観測粒度の設定により同じ観測アイテムが別々のコアに振り分けられる可能性がある。ここで観測粒度とは集計の単位であり、例えば“IPペア毎に通信量を計測する”、“宛先IP毎に通信量を計測する”などの観測タスクにおけるIPペアや宛先IPに相当する。
[0007]
 これはRSSで計算対象となるヘッダ(例えばIPv6ペア)が観測粒度(例えばソースIPv6の先頭64bitのみ)と異なる場合などである。ここでRSSはパケットヘッダの指定されたビット列からハッシュ値を計算し、そのハッシュ値に従いパケットを各CPUコアに振り分ける機能である(図1)。
[0008]
 これによりアイテムの観測値の正しい値が得られない場合がある。例えばRSSでIPペアでハッシュ値を計算しており、アイテムとして各宛先IP毎に通信量を観測していた場合、同一の宛先IPをもつパケットが別々のコアに割り振られる場合がある。このため、通信量が閾値を越えるかどうかを観測していた場合、各コアでは実際の通信量より少ない値しか観測できないため閾値判定を誤認する可能性がある。
[0009]
 さらに、ソフトウェアによるトラフィックモニタリングを複数のコアで行った場合、各コアで構築した複数のデータ構造を高速に合併(重複要素を排除)する必要性がある。複数のデータ構造から重複要素を排除する方法としては次の3つの方法がある。
方法1.各コアで観測により構築したデータ構造の各要素を入力として、一つの大きなデータ構造を再構築する方法
方法2.RSSのハッシュ値を調整して、同じキーは同じCPUコアに割り振られるように調整する方法
方法3.全ての要素について各データ構造を検索して重複要素を削除する方法
[0010]
 以下、それぞれの方法についての課題を説明する。
[0011]
〔方法1の課題〕
 方法1は、再度データ構造を構築するので追加の領域計算量と時間計算量が必要という課題がある。
 例えば、重複を排除するために集合を木構造(例えば、非特許文献2を参照。)などで実装した場合、データ構造の再構築にはO(TlogT)の計算量が必要となる。ここでTは各コアで観測された要素数の合計である。
 また、他の例として、データ構造にハッシュテーブル(例えば、非特許文献2を参照。)を利用していた場合、各コアでの観測により構築されたハッシュテーブルの各要素について、ハッシュ値を再度計算して、新しいハッシュテーブルに挿入する必要がある。このため、ハッシュ値の再計算の他に新しいハッシュテーブル用のメモリ確保などの作業が必要となる。
[0012]
〔方法2の課題〕
 RSSはNICの機能でありハードウエアでRSSのハッシュ値が計算される。方法2は2つの課題がある。
[0013]
 課題の1つは、観測粒度にRSS機能を対応させる必要性である。観測粒度としては次のようなものが考えられる。
(1) 送信元IP
(2) 宛先IP
(3) 送信元IPの上位24bitと宛先IPの上位24bitの組
(4) 送信元IP、宛先IP、プロトコル番号、送信元ポート、宛先ポート
(5) パケット長
 例えば(5)のパケット長の場合はRSSの計算にパケット長を含める必要がある。しかし、RSS計算はL4のポート番号(TCPやUDPのポート番号)までが一般的であり、パケット長はRSS機能として通常サポートされていない。
[0014]
 他の課題は、複数の観測粒度で観測する場合、観測粒度によって別のコアに割り振られてしまうことである。
 例えば上記(1)と(2)を観測する場合を考える。図3及び図4は、RSS計算フィールドと観測粒度の関係を説明した図である。図4で説明するように、RSS計算に送信元IPと宛先IPを使用すると、同じ送信元IPでも宛先IPが異なるパケットは別のコアに割り振られる可能性があり(1)での観測粒度に適合しなくなる。一方、図3で説明するように、RSS計算に送信元IPのみを利用すると、同じ宛先IPでも送信元IPが異なるパケットが別のコアに割り振られる可能性があり(2)での観測粒度に適合しなくなる。RSS計算に宛先IPのみを利用する場合も同様である。
[0015]
〔方法3の課題〕
 方法3は、全ての要素について、各コアのデータ構造から検索し、それら重複要素を合併する方法である。このため、方法3は、各要素と各データ構造に対して検索操作を実施するので追加の計算時間を必要とし、合併も実行する必要があるという課題がある。
[0016]
 例えば、データ構造に木構造を利用して集合を利用していた場合を考える。検索はO(logN)の計算量が必要となる、Nは集合の要素数である。ここでi番目のコアのデータ構造の要素数を|T |とする。全てのデータ構造に対して並列に検索できる場合、O(Tmax log|T |)の計算量が必要となる。並列に検索できない場合、式1の計算量が必要となる。
[数1]


ただし、Tは各コアで観測された要素数の合計であり、
[数2]


である。
[0017]
 また、例えば、データ構造にハッシュテーブルを利用していた場合は、再構築と同様に全要素のハッシュ値を再計算する必要がある。さらに、各コアで使用するハッシュ関数が異なる場合、対応したハッシュ関数を利用する必要があるため、異なるハッシュ関数の数だけハッシュ値を再計算する必要がある。
[0018]
 本発明は、上記の方法1~3の課題を解決することを目的とする。すなわち、本発明は、上記課題を解決するために、マルチコア環境における各コアのデータ構造に対して、データ構造の再構築、データ構造の検索処理、およびRSS機能の調整を行うことなく、これらを効率的に合併できるトラフィックモニタリング方法、トラフィックモニタリング装置及びプログラムを提供することを目的とする。

課題を解決するための手段

[0019]
 上記目的を達成するために、本発明に係るトラフィックモニタリング方法は、各コアが形成したデータ構造の要素をアイテム毎に比較し、当該要素内の統計値をいずれか一つの要素にまとめるとともに、他の要素の統計値をゼロとすることとした。
[0020]
 具体的には、本発明に係るトラフィックモニタリング方法は、マルチコア環境でのトラフィックモニタリング方法であって、
 レシーブサイドスケーリング(RSS:Receive Side Scaling)機能でパケットを複数のコアに振り分ける振分工程と、
 所定時間毎に、それぞれの前記コアで、アイテム毎に前記パケットを観測して統計値を取得し、前記アイテムと前記統計値の組み合わせからなる要素で構成されるデータ構造を形成する観測工程と、
 それぞれの前記コアで形成した前記データ構造の前記要素を前記アイテム毎に突き合わせ、前記アイテム毎に、いずれか1つのコアの前記要素の前記統計値を該統計値の目的に応じた値に書き換えし、他のコアの前記要素の前記統計値をゼロに置き換え、それぞれの前記コアの前記データ構造を合併する合併工程と、
を行うことを特徴とする。
[0021]
 また、本発明に係るトラフィックモニタリング装置は、マルチコアのトラフィックモニタリング装置であって、
 レシーブサイドスケーリング(RSS:Receive Side Scaling)機能でパケットを複数に振り分ける振分部と、
 前記振分部が振り分けた前記パケットをそれぞれ受信し、所定時間毎に、アイテム毎に前記パケットを観測して統計値を取得し、前記アイテムと前記統計値の組み合わせからなる要素で構成されるデータ構造を形成する複数のコアと、
 それぞれの前記コアで形成した前記データ構造の前記要素を前記アイテム毎に突き合わせ、前記アイテム毎に、いずれか1つのコアの前記要素の前記統計値を該統計値の目的に応じた値に書き換えし、他のコアの前記要素の前記統計値をゼロに置き換え、それぞれの前記コアの前記データ構造を合併する合併部と、
を備えることを特徴とする。
[0022]
 本発明のようにデータ構造の要素の統計値を処理し、データ構造の合併時に統計値がゼロである要素を無視することで、データ構造間の重複要素を除去することができる。従って、本発明は、マルチコア環境における各コアのデータ構造に対して、データ構造の再構築、データ構造の検索処理、およびRSS機能の調整を行うことなく、これらを効率的に合併できるトラフィックモニタリング方法及びトラフィックモニタリング装置を提供することができる。
[0023]
 なお、前記統計値には、次のような値を採用できる。
(1)前記要素の前記統計値が、前記要素の前記アイテムに該当する前記パケットの出現回数であり、前記合併工程での、該統計値の目的に応じた値が、全てのコアの前記要素の前記統計値の和である。
(2)前記要素の前記統計値が、前記要素の前記アイテムに該当する前記パケットのパケット長であり、前記合併工程での、該統計値の目的に応じた値が、全てのコアの前記要素の前記統計値の和である。
(3)前記要素の前記統計値が、前記要素の前記アイテムに該当する前記パケットの最大パケット長であり、前記合併工程での、該統計値の目的に応じた値が、全てのコアの前記要素の前記統計値の最大値である。
(4)前記要素の前記統計値が、前記要素の前記アイテムに該当する前記パケットの最小パケット長であり、前記合併工程での、該統計値の目的に応じた値が、全てのコアの前記要素の前記統計値の最小値である。
[0024]
 本発明に係るトラフィックモニタリング方法は、前記所定時間に、前記観測工程で、前記コアの一方のデータベースに前記データ構造を形成するとともに、前記合併工程で、前記コアの他方のデータベースに保管されている前記データ構造を合併することを特徴とすることが好ましい。
 本トラフィックモニタリング方法は、定期的に合併工程を行い、データ構造の合併後に新たなデータが記録されることを防止することができる。
[0025]
 本発明に係るプログラムは、前記トラフィックモニタリング方法をコンピュータに実行させるためのプログラムである。
 本発明に係るトラフィックモニタリング方法は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。
[0026]
 なお、上記各発明は、可能な限り組み合わせることができる。

発明の効果

[0027]
 本発明は、マルチコア環境における各コアのデータ構造に対して、データ構造の再構築、データ構造の検索処理、およびRSS機能の調整を行うことなく、これらを効率的に合併できるトラフィックモニタリング方法、トラフィックモニタリング装置及びプログラムを提供することができる。

図面の簡単な説明

[0028]
[図1] マルチコアでトラフィックモニタリングを行う装置を説明する図である。
[図2] 本発明に係るトラフィックモニタリング装置を説明する図である。
[図3] 本発明の課題を説明する図である。
[図4] 本発明の課題を説明する図である。
[図5] 本発明に係るトラフィックモニタリング装置の動作を説明する図である。
[図6] 本発明に係るトラフィックモニタリング装置の動作を説明する図である。
[図7] 本発明に係るトラフィックモニタリング装置の動作を説明する図である。
[図8] 本発明に係るトラフィックモニタリング装置の動作を説明する図である。
[図9] 本発明に係るトラフィックモニタリング装置の動作を説明する図である。
[図10] 本発明に係るトラフィックモニタリング装置のコアを説明する図である。
[図11] 本発明に係るトラフィックモニタリング装置の動作を説明する図である。
[図12] 本発明に係るトラフィックモニタリング方法を説明するフローチャートである。

発明を実施するための形態

[0029]
 添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。
[0030]
 図1及び図2は、本実施形態のトラフィックモニタリング装置を説明する図である。本トラフィックモニタリング装置は、
 レシーブサイドスケーリング(RSS:Receive Side Scaling)機能でパケットを複数に振り分ける振分部11と、
 振分部11が振り分けた前記パケットをそれぞれ受信し、所定時間毎に、アイテム毎に前記パケットを観測して統計値を取得し、前記アイテムと前記統計値の組み合わせからなる要素で構成されるデータ構造を形成する複数のコア12と、
 それぞれのコア12で形成した前記データ構造の前記要素を前記アイテム毎に突き合わせ、前記アイテム毎に、いずれか1つのコアの前記要素の前記統計値を該統計値の目的に応じた値に書き換えし、他のコアの前記要素の前記統計値をゼロに置き換え、それぞれのコア12の前記データ構造を合併する合併部13と、
を備える。
[0031]
 図12は、本実施形態のトラフィックモニタリング装置が行うトラフィックモニタリング方法を説明するフローチャートである。本トラフィックモニタリング方法は、
 レシーブサイドスケーリング(RSS:Receive Side Scaling)機能でパケットを複数のコアに振り分ける振分工程S11と、
 所定時間毎に、それぞれの前記コアで、アイテム毎に前記パケットを観測して統計値を取得し、前記アイテムと前記統計値の組み合わせからなる要素で構成されるデータ構造を形成する観測工程S12と、
 それぞれの前記コアで形成した前記データ構造の前記要素を前記アイテム毎に突き合わせ、前記アイテム毎に、いずれか1つのコアの前記要素の前記統計値を該統計値の目的に応じた値に書き換えし、他のコアの前記要素の前記統計値をゼロに置き換え、それぞれの前記コアの前記データ構造を合併する合併工程S13と、
を行う。
[0032]
 本実施形態では、例として、前記要素の前記統計値が、前記要素の前記アイテムに該当する前記パケットの出現回数であり、前記合併工程での、該統計値の目的に応じた値が、全てのコアの前記要素の前記統計値の和であることで説明する。具体的には、観測タスクとしてt秒ごと、観測粒度(アイテム)毎の出現回数を計測することで説明する。
[0033]
 なお、統計値としてアイテムの総バイト数、最大パケット長、最小パケット長、その他の観測値を扱うことができる。最大パケット長や最小パケット長を観測する場合は後述するステップ8の総和Σをmaxやminに置き換えることで同様に扱うことができる。
[0034]
 また、本実施形態のトラフィックモニタリング装置は、所定時間(t秒)に、観測工程S12で、前記コアの一方のデータベースに前記データ構造を形成するとともに、合併工程S13で、前記コアの他方のデータベースに保管されている前記データ構造を合併するように動作する。
[0035]
 図10は、コア12の構造を説明する図である。各コア12は、データ構造を記録するデータベースを2つ備える。例えば、当該データベースをA面とB面とする。図11は、図10のようなコア12と合併部13の動作を説明する図である。コア12は、0秒からt秒までの観測結果をA面に記録する。続いてコア12は、t秒から2t秒までの観測結果をB面に記録する。このようにコア12は、t秒毎に記録するデータ構造を交換していく。そして、合併部13は、t秒から2t秒の間にA面のデータ構造を合併し、2t秒から3t秒の間にB面のデータ構造を合併していく。このようにt秒毎に合併するデータ構造を交換し、合併後に新しいデータが記録されないようにする。
[0036]
 図5~図9は、本トラフィックモニタリング装置の動作を説明する図である。
 i番目のコア12が観測したデータ構造をリストT としている。リストT は、複数の要素xからなる。要素xは、アイテムa (本実施形態では送信先アドレスである)と当該アイテムに該当するパケットの出現回数f のペアで表現される。jはアイテムを識別する符号である。
[数3]


また、リスト要素xに対応するアイテムをa(x)、出現回数をf(x)と書く。
[0037]
 例えば、オープンアドレス方式のハッシュテーブル(線形探索ハッシュテーブル(Linear Hash Table)など)(非特許文献2)はこのようなリストとしてみなせる。優先度付きキューや配列もリストとみなすことができる。
[0038]
 以下に述べる方法により、あるアイテムaが複数のリスト(式4参照)に含まれていた場合は式5のように更新する。
[数4]


[数5]


 式5は、各コアが形成したデータ構造の要素をアイテム毎に比較し、当該要素内の統計値をいずれか一つの要素にまとめるとともに、他の要素の統計値をゼロとすることを意味する。このように更新できれば出現頻度が0の要素を無視することでデータ構造間の重複要素を除去できる。
[0039]
 具体的には次のように合併工程S13を実行する。
[ステップ1]
 まずアイテム間に全順序を定める。例えばビット列を自然数とみた順序などである。本実施形態では送信先アドレスの小さい順に作業を行うこととする。
[ステップ2]
 ステップ1で定めた全順序に従い各T を昇順にソートする(式6及び図5参照)。
[数6]


ここでl はリストT の長さである。
[ステップ3]
 各リストT 内で処理対象の要素を選出する。
i=1,2,・・・,nについて式7とする。
[数7]


ここでs はi番目のリストT の中で処理対象とする要素xの番号である(要素は、“x si”と表現できる。)。つまり、それぞれのT 内で最初の処理対象の要素xを選出し、それらの番号s 、s 、s 、s 、・・・を1とする。
[ステップ4]
 全てのリストについて選出する要素が存在するか確認する。Iは選出した要素xの集合である。
[数8]


[ステップ5]
Iが空集合ならば終了する。
[ステップ6]
 選出した要素の中で最小のアイテムをa とする。
[数9]


 図5の状態であればa =192.0.2.9、図7の状態であればa =192.0.2.10、図9の状態であればa =192.0.2.11である。
[ステップ7]
 集合Iの中で処理対象(アイテムa がである)の要素の番号を見つける。
[数10]


 図5の場合、処理対象はs とs であり、Jは3と4である。図7の場合、処理対象はs とs とs であり、Jは1と2と4である。図9の場合、処理対象はs とs であり、Jは1と3である。
[ステップ8]
 処理対象の要素の統計値をまとめる。図5、図7及び図9の場合、統計値が出現回数なので、処理対象の要素の出現回数を加算する。
[数11]


 なお、前述したように、統計値の種類によって式11の計算式は異なる。
[ステップ9]
 各j∈Jについて、式12のようにリストの要素を更新する。
[数12]


 具体的には、処理対象の要素の中で、番号が最小の要素の統計値をステップ8で計算した値に置き換え、他の要素の統計値をゼロに置き換える。
 図5の場合、s とs が処理対象なので、s の要素の統計値(出現回数)を2から5へ置き換え、s の要素の統計値(出現回数)を3から0へ置き換える。図6は、統計値を置き換えた後の状態を示している。
 図7の場合、s とs とs が処理対象なので、s の要素の統計値(出現回数)を4から9へ置き換え、s とs の要素の統計値(出現回数)をそれぞれ3から0、2から0へ置き換える。図8は、統計値を置き換えた後の状態を示している。
 図9の場合、s とs が処理対象なので、s の要素の統計値(出現回数)を1から4へ置き換え、s の要素の統計値(出現回数)を3から0へ置き換える。
[ステップ10]
 次のアイテムについて同様な作業を行う。
 各j∈Jについて式13とし、ステップ4に戻る。
[数13]


[0040]
 ステップ2でのソートにクイックソート(非特許文献2)などを使うことで新しいメモリを確保する必要がない。またソート後は各リストを先頭から順番にアクセスするだけなので高速に操作が完了する。
[0041]
 各リストを並列でソートした場合、必要な計算量は式14となる。
[数14]


 各リストを並列にソートできない場合、必要な計算量は式15となる。
[数15]


[0042]
[付記]
 以下は、本実施形態のトラフィックモニタリング方法を説明したものである。
 本発明は、複数n個のコアでトラフィックを観測することで構築された複数n個のデータ構造を、重複要素を排除して合併する方法において、i(iは1以上n以下の整数)番目のコアが観測したデータ構造のリストT の各々について「アイテムa とその出現回数f の組合せからなる要素x」をアイテムa の所定の全順序に基づいて昇順にソートし、各リストの先頭から順に要素xを検査し、同じアイテムa からなる要素x含む全てのリストT について当該要素xにおける出現回数f の総和を算出し、当該要素xを含むリストT のうちiが最小であるリストT の当該要素xにおける出現回数f を算出した総和に置き換え、その他のリストT の当該要素xにおける出現回数f を全て0に置き換える処理を繰り返すことを特徴とする。
[0043]
 本発明は次の3つをポイントとする。
(A)オープンアドレス方式のハッシュテーブルや優先度付きキュー、配列などデータ構造はリストとして扱うこともできること。
(B)各リストのソートはクイックソートなどを利用すれば新しいメモリを確保することなく高速に実行できること。
(C)ソート後はリスト全体ではなくリストの先頭の要素のみを調べることで合併できること。
[0044]
[発明の効果]
 複数コアでトラフィックを観測する場合、構築した複数のデータ構造を高速に合併する必要があるが、本発明により、データ構造の再構築、データ構造の検索処理、RSS機能の調整をすることなく複数のデータ構造を高速に合併できる。

符号の説明

[0045]
11:振分部
12:コア
13:合併部

請求の範囲

[請求項1]
 マルチコア環境でのトラフィックモニタリング方法であって、
 レシーブサイドスケーリング(RSS:Receive Side Scaling)機能でパケットを複数のコアに振り分ける振分工程と、
 所定時間毎に、それぞれの前記コアで、アイテム毎に前記パケットを観測して統計値を取得し、前記アイテムと前記統計値の組み合わせからなる要素で構成されるデータ構造を形成する観測工程と、
 それぞれの前記コアで形成した前記データ構造の前記要素を前記アイテム毎に突き合わせ、前記アイテム毎に、いずれか1つのコアの前記要素の前記統計値を該統計値の目的に応じた値に書き換えし、他のコアの前記要素の前記統計値をゼロに置き換え、それぞれの前記コアの前記データ構造を合併する合併工程と、
を行うことを特徴とするトラフィックモニタリング方法。
[請求項2]
 前記要素の前記統計値が、前記要素の前記アイテムに該当する前記パケットの出現回数であり、
 前記合併工程での、該統計値の目的に応じた値が、全てのコアの前記要素の前記統計値の和である
ことを特徴とする請求項1に記載のトラフィックモニタリング方法。
[請求項3]
 前記要素の前記統計値が、前記要素の前記アイテムに該当する前記パケットのパケット長であり、
 前記合併工程での、該統計値の目的に応じた値が、全てのコアの前記要素の前記統計値の和である
ことを特徴とする請求項1に記載のトラフィックモニタリング方法。
[請求項4]
 前記要素の前記統計値が、前記要素の前記アイテムに該当する前記パケットの最大パケット長であり、
 前記合併工程での、該統計値の目的に応じた値が、全てのコアの前記要素の前記統計値の最大値である
ことを特徴とする請求項1に記載のトラフィックモニタリング方法。
[請求項5]
 前記要素の前記統計値が、前記要素の前記アイテムに該当する前記パケットの最小パケット長であり、
 前記合併工程での、該統計値の目的に応じた値が、全てのコアの前記要素の前記統計値の最小値である
ことを特徴とする請求項1に記載のトラフィックモニタリング方法。
[請求項6]
 前記所定時間に、
 前記観測工程で、前記コアの一方のデータベースに前記データ構造を形成するとともに、前記合併工程で、前記コアの他方のデータベースに保管されている前記データ構造を合併することを特徴とする請求項1から5のいずれかに記載のトラフィックモニタリング方法。
[請求項7]
 マルチコアのトラフィックモニタリング装置であって、
 レシーブサイドスケーリング(RSS:Receive Side Scaling)機能でパケットを複数に振り分ける振分部と、
 前記振分部が振り分けた前記パケットをそれぞれ受信し、所定時間毎に、アイテム毎に前記パケットを観測して統計値を取得し、前記アイテムと前記統計値の組み合わせからなる要素で構成されるデータ構造を形成する複数のコアと、
 それぞれの前記コアで形成した前記データ構造の前記要素を前記アイテム毎に突き合わせ、前記アイテム毎に、いずれか1つのコアの前記要素の前記統計値を該統計値の目的に応じた値に書き換えし、他のコアの前記要素の前記統計値をゼロに置き換え、それぞれの前記コアの前記データ構造を合併する合併部と、
を備えることを特徴とするトラフィックモニタリング装置。
[請求項8]
 請求項1から6のいずれかに記載のトラフィックモニタリング方法をコンピュータに実行させるためのプログラム。

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]