JP2010045704A

JP2010045704A - トラヒック情報の収集方法およびトラヒック受信装置

Info

Publication number: JP2010045704A
Application number: JP2008209624A
Authority: JP
Inventors: Yutaka Hirokawa; 裕廣川; Junji Kobayashi; 淳史小林
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: NTT Inc
Priority date: 2008-08-18
Filing date: 2008-08-18
Publication date: 2010-02-25
Anticipated expiration: 2028-08-18
Also published as: JP4643692B2

Abstract

【課題】トラヒック情報配信機器で用いるフィルタリング条件と、トラヒック受信装置側で行う処理を連携させるための技術を提供する。
【解決手段】トラヒック受信装置１００はフィルタ条件設定部１１０とフロー処理部１２０とを有する。フィルタ条件設定部１１０はフィルタ条件をフロー配信機能を有したルータ（トラヒック情報配信機器）１３１とフロー処理部１２０に投入する。フロー処理部１２０はルータ１３１から配信されたトラヒック情報の処理を前記フィルタ条件毎に行う。フィルタ条件設定部１１０は、ルータ１３１で用いるフィルタ条件と、フロー処理部１２０でフィルタ条件毎に行うトラヒック情報の処理を、同一の設定ファイルで記述する。フィルタ条件設定部１１０は、各フィルタ条件に個別の識別番号を割り振り、ルータ１３１に識別番号をトラヒック情報に含めて配信させ、フロー処理部１２０は識別番号のみを参照して分類を行う。
【選択図】図１

Description

本発明は、インターネットに代表される大規模ネットワーク上を流れるトラヒックをモニタする際に、ネットワーク上のトラヒックを効率的にモニタする手法に関し、特に、トラヒック情報の収集及び振り分け方法に関する。

大規模、大容量化したネットワークにおいては、膨大なトラヒック全てについてパケット単位での観測を行うことは困難である。そのため、トラヒックのフロー集約やパケットのサンプリングといった技術が必要となる。現在はｓＦｌｏｗ（非特許文献１参照）やＮｅｔＦｌｏｗ（非特許文献２参照）といったフロー統計配信プロトコルを用いてネットワーク上のトラヒックを監視する技術が、ルータやスイッチといったＮＷ機器（Network機器）に主に導入されている。

ｓＦｌｏｗやＮｅｔＦｌｏｗといった従来のフロー統計配信プロトコルは、ＮＷ機器のＩＦ（Interface）上で受信する全てのパケットを対象にサンプリングが行われている。また、フロー統計配信プロトコルの一つであるＩＰＦＩＸプロトコル（非特許文献３参照）では、フィルタ条件とサンプリングを組み合わせることでより柔軟なトラヒック測定を可能としているが、情報の配信方法については、一律同じ方式が適用される。

このような状況の中で、より柔軟にトラヒックを抽出する方法として、一次的に異常として検出されたトラヒックを抽出して、大容量のトラヒックの中に埋もれないようにする機能や、フロー条件を元に、より柔軟にフロー統計を実施する機能が考案されている。更に、特定のパケットのフィルタリングやパケットの分類を行ってからサンプリングされたトラヒックの配信方法を、分類されたフィルタ条件毎に設定可能とする機能も考案されている。

しかし、ＮＷ機器でパケットのフィルタリングやパケットの分類を行うためには、ネットワーク上でトラヒックの監視を行っている複数のＮＷ機器にフィルタ条件などの設定を行わなければならない。同様に、フロー配信パケットを受信する装置についても、アプリケーション毎に適した処理を行うための振り分け条件を設定しなければならない。

また、より詳細なトラヒック分析を行おうとすると、フィルタ条件として設定しなければならない項目も多くなり、一つのＮＷ機器毎の設定に要する作業量も大きくなってしま
う。

今後ＮＷ機器においてフィルタ条件毎にフロー情報を配信する機能が増え、設定を変更する頻度も多くなれば、それを設定する作業に要するコストが大きくなる。更に、受信したフロー情報を受信する装置側についても、ＮＷ機器で用いられたフィルタ条件毎に異なる処理（分析・転送・蓄積など）をフロー情報に対して行うためには、同様にフィルタ条件の設定作業をしなければならない。

ＩＰＦＩＸによるフロー配信機能を有したＮＷ機器に対して、ＸＭＬで記述された設定ファイルを、Ｎｅｔｃｏｎｆプロトコル（非特許文献４参照）を用いて外部のサーバから投入する手法が存在する。これにより、ＮＷ機器におけるフィルタ条件を動的かつ効率的に設定することが可能となる。しかし、受信装置側における各フィルタ条件に合致するフローレコードに対して行う処理の内容を、ＮＷ機器の設定と連携させ同時に設定する機能は、現状存在しない。

また、ＩＰＦＩＸのConfiguration Data Model（非特許文献５参照）には受信装置側の処理内容に関する設定条件については、定義されていない。また、設定したフィルタ条件毎に割り振るＩＤのような識別子は定義されていない。そのため、多様なトラヒック情報を扱うようになると、フィルタ条件の項目が多くなり、トラヒック情報とフィルタ条件のマッチング処理を行う際には、それら全ての項目についてマッチング処理を行わなければならないため、コレクタの負荷が高くなる。

ＲＦＣ３１７６，"InMon Corporation's sFlow:A Method for Monitoring Traffic in Switched and Routed Networks"，September 2001 ＲＦＣ３９５４，"Cisco Systems NetFlow Services Export Version 9"，October 2004 draft-ietf-ipfix-protocol-26.txt，"Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information"，September 2007 ＲＦＣ４７４１，"ＮＥＴＣＯＮＦ Configuration Protocol"，December 2006 draft-muenz-ipfix-configuration-04.txt，"Configuration Data Model for IPFIX and PSAMP"，February 2008

従来の技術は、トラヒック情報配信機器（ＮＷ機器）で行われるフィルタリング処理に用いるフィルタ条件と、トラヒック受信装置側で振り分け処理に用いる振り分け条件を連携させるための手段が無く、フィルタ条件の設定を変える度に手動で設定しなおさなければならないため効率が悪い。本機能では、トラヒック情報配信機器のフィルタ条件とトラヒック受信装置の振り分け条件を同一のファイルで記述することにより、両機器の設定を連携させることを可能とした。

また、従来の技術においては、配信されるフロー配信パケットをフィルタ条件毎に分類する際に、フローレコードの内容を参照しフィルタ条件とのマッチングを行うため、大量のフローレコードを扱う際に、効率が悪くなる。本機能では、フィルタ条件毎に固有の識別番号を持たせ、配信されるフロー統計内にも識別番号を記載することにより、フロー統計情報を受信する側は、フロー統計情報を全て参照しなくとも、当該識別番号をだけを参照し、フィルタ条件毎の振り分けを行うことにより、より効率的な処理が可能となる。ＮＷ機器側でトラヒック情報を配信する際に、合致したフィルタ条件の識別番号を配信するトラヒック情報内に格納することで、トラヒック情報受信装置（コレクタ）側は、当該識別番号を参照するだけで、フィルタ条件に関する処理を行うことが可能となる。

本発明の目的は、トラヒック情報配信機器で用いるフィルタリング条件と、トラヒック受信装置側で行う処理を連携させるための技術を提供することにある。

本明細書において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

第１の発明は、トラヒック情報配信機器から配信されるトラヒック情報を収集するトラヒック受信装置におけるトラヒック情報収集方法であって、前記トラヒック受信装置は、フィルタ条件設定手段とフロー処理手段とを有し、前記フィルタ条件設定手段が、前記トラヒック情報配信機器が用いるフィルタ条件を前記トラヒック情報配信機器と前記フロー処理手段に投入し、前記フロー処理手段が、前記トラヒック情報配信機器から配信されたトラヒック情報に対して前記フィルタ条件に基づくトラヒック情報の処理を前記フィルタ条件毎に行う、ことを特徴とする。

第２の発明は、第１の発明において、前記フロー処理手段は、デコード手段と分類手段とアクション実行手段とを有し、前記デコード手段が、前記トラヒック情報配信機器から配信されたトラヒック情報をデコードし、前記分類手段が、デコードされたトラヒック情報を前記フィルタ条件毎に分類し、前記アクション実行手段が、前記分類手段によりフィルタ条件毎に分類されたトラヒック情報に対して、前記フィルタ条件設定手段によってフィルタ条件毎に定められたトラヒック情報の処理を行う、ことを特徴とする。

第３の発明は、第１の発明において、前記フィルタ条件設定手段が、前記トラヒック情報配信機器で用いるフィルタ条件と、前記フロー処理手段でフィルタ条件毎に行うトラヒック情報の処理を、同一の設定ファイルで記述することを特徴とする。

第４の発明は、第１の発明において、前記フィルタ条件設定手段が、各フィルタ条件に個別の識別番号を割り振り、前記トラヒック情報配信機器に、マッチしたフィルタ条件の識別番号をトラヒック情報に含めて配信させ、前記フロー処理手段が、トラヒック情報の処理を前記フィルタ条件毎に行う際に、前記識別番号のみを参照して分類を行う、ことを特徴とする。

第５の発明は、トラヒック情報配信機器から配信されるトラヒック情報を収集するトラヒック受信装置であって、前記トラヒック情報配信機器が用いるフィルタ条件を前記トラヒック情報配信機器と前記フロー処理手段に投入するフィルタ条件設定手段と、前記トラヒック情報配信機器から配信されたトラヒック情報に対して前記フィルタ条件に基づくトラヒック情報の処理を前記フィルタ条件毎に行うフロー処理手段と、を備えることを特徴とする。

本発明により、トラヒック情報配信機器で用いるフィルタリング条件と、トラヒック受信装置側で行う処理を連携させることができる。また、トラヒック受信装置とトラヒック情報配信機器を連携させる際の設定を簡略化する。また、識別番号を用いたマッチングを行うことにより、振り分け処理の負荷を減らし、大量のフロー統計情報を処理することが可能となる。

本発明の実施の形態のトラヒック情報収集方法は、受信したＩＰパケットを分類し、あらかじめ設定したフィルタ条件にマッチする特定のトラヒックについて、サンプリングを行い、パケット情報をフロー配信パケット（ｓＦｌｏｗ，ＩＰＦＩＸ，ＮｅｔＦｌｏｗなど）として配信するルータと連携し、ルータへのフィルタ条件の投入を行い、配信されたフロー配信パケットを受信し、フィルタ条件毎のトラヒック分析装置への転送や、フロー配信パケット内に含まれる情報に沿った蓄積方式での蓄積といった処理を行うことにより、より詳細なトラヒックの監視・分析を可能とするものである。また、これにより、トラヒックの分析結果を反映させた新たなフィルタ条件を自動生成し、ルータに追加設定するといった、柔軟なトラヒック監視・分析を可能とする。

本発明の実施の形態は、トラヒック受信装置として、フロー配信機能を有したルータとは別の専用のサーバに実装されることを想定している。

以下、本発明の実施の形態を、図面を用いて詳細に説明する。

図１に全体概要図を示す。１００は本発明の実施の形態のトラヒック受信装置、１１０はフィルタ条件設定部、１２０はフロー処理部である。１１１はトラヒック受信装置１００のＧＵＩである。１３０はネットワーク、１３１−１〜１３１−３はネットワーク１３０上に配置されたフロー配信機能を有したルータ（一般的には、フロー配信機能（トラヒック情報配信機能）を有したトラヒック情報配信機器）である。１４０はトラヒック分析装置群、１４１は異常パケットの収集・分析装置、１４２はUnroutable／未使用アドレストラヒック分析装置、１４３はシグネチャ分析装置、１４４はＴＣＰステータス分析装置・ＩＣＭＰ分析装置、１４５はＶｏＩＰ品質分析装置、１４６はProtocol Analyzerである。１５０は侵入検知システム（ＩＤＳ）、１６０は外部サーバである。

図１の例において、監視対象となるネットワーク１３０上にフロー配信機能を有したルータ１３１が３台配置されている。図１の例ではルータの数は３台だが、ルータ１３１の数には特に制限は無い。

図の中央のトラヒック受信装置１００は、各ルータ１３１が配信するフロー配信パケットを受信する本実施の形態の機能を搭載したサーバである。トラヒック受信装置１００は、フロー配信ルータ１３１が用いるフィルタ条件をトラヒック情報配信機器とフロー処理部１２０に投入するフィルタ条件設定部１１０と、フロー配信ルータ１３１から配信されたトラヒック情報に対して前記フィルタ条件に基づくトラヒック情報の処理を前記フィルタ条件毎に行うフロー処理部１２０と、を備える。

図の例では、トラヒック分析装置群１４０として異常パケットの収集・分析装置１４１、Unroutable／未使用アドレストラヒック分析装置１４２、シグネチャ分析装置１４３、ＴＣＰステータス分析装置・ＩＣＭＰ分析装置１４４、ＶｏＩＰ品質分析装置１４５、Protcol Analyzer１４６といった装置が配置されているが、これらは一例であり、これらの一部の分析装置だけで構成してもよいし、これら以外の分析装置を含んでいてもよい。また、トラヒック受信装置１００はトラヒック分析装置群１４０や侵入検知システム（ＩＤＳ）１５０にフローレコードの情報を基に構築したイーサフレームの転送を行う。これらのトラヒック分析装置群１４０やＩＤＳ１５０は一般に使用されている装置を使用すればよいので、その詳細な説明は省略する。また、図の例のように、トラヒック受信装置１００は各ルータ１３１に設定するフィルタ条件を外部のサーバ１６０から受け取ることができる。

図２に本機能を搭載したトラヒック受信装置１００の構成図を示す。

トラヒック受信装置１００はフロー処理部１２０とフィルタ条件設定部１１０から構成されている。更に、フロー処理部１２０はデコード部１２１、分類部１２２、アクション実行部１２３から構成される。２０３はトラヒック受信装置１００のＩＦである。

デコード部１２１は受信したフロー配信パケット２０１をデコードし、パケット内のフローレコード２１０を読み取ることができる形式に変換する。

分類部１２２は、フロー配信パケット２０１がルータ１３１で分類された際に用いられたフィルタ条件に従って、デコードされたフローレコードの分類を行う。

アクション実行部１２３では、分類部１２２でフィルタ条件毎に分類されたフローレコードに対して、トラヒック分析装置群１４０の各トラヒック分析装置へのフロー配信パケット２０２の転送、ＩＤＳ１５０へのイーサフレームの転送、一定周期毎のフローレコードの蓄積、といったフィルタ条件毎に定められた処理を実行する。

フィルタ条件設定部１１０はルータでＩＰパケットの分類を行う際に用いるフィルタ条件を作成し、ルータ１３１に投入する。フィルタ条件設定部１１０は、Ｗｅｂ画面上のＧＵＩ１１１から操作により、ルータ１３１とトラヒック受信装置１００で共有可能な設定ファイルを作成する。この設定ファイルは、例えば、ＸＭＬ形式で記述される。もしくは外部サーバ１６０からＸＭＬフォーマットでフィルタ条件を記述した設定ファイルを投入することにより、フィルタ条件を作成する。また、作成したフィルタ条件はルータ１３１とトラヒック受信装置１００の分類部１２２に投入される。

以下に、本発明の機能を搭載したトラヒック受信装置１００の動作手順を図１に従って示す。

（１）フィルタ条件の作成
まず初めに監視対象のネットワーク１３０上のルータ１３１で監視したいトラヒックのフィルタ条件を作成する（２０５）。フィルタ条件には宛先／送信元ＩＰアドレス、上位プロトコル、宛先／送信元ポート番号といった５タプルの情報の他、ＴＣＰフラグ、ＴＯＳ、宛先／送信元ＭＡＣアドレス、ＩＰバージョン、パケット長、ＢＧＰＮｅｘｔｈｏｐといった項目のうち、１つ以上を指定し作成する。また、作成したフィルタ条件には、個別の識別番号を設定する。更に、各フィルタ条件にはフロー処理部１２０のアクション実行部１２３で行われる処理の内容が指定される。

（２）フィルタ条件の投入
作成されたフィルタ条件は、フィルタ条件設定部１１０によりネットワーク１３０上のルータ１３１とフロー処理部１２０の分類部１２２に投入される。

（３）トラヒック情報の配信
フロー情報配信機能を有したルータ１３１はネットワーク１３０上に流れるパケットが入力されると、設定されたフィルタ条件に従ってパケットを分類し、フィルタ条件毎にサンプリング等の処理を行い、フロー配信パケット２０１を作成し、フロー配信プロトコルを用いてトラヒック受信装置１００に配信する。この時、フロー配信パケット２０１にはフィルタ条件の識別番号の情報も記載する。

（４）トラヒック情報の処理
トラヒック受信装置１００が持つフロー配信パケット受信用のＩＦ２０３を通してフロー配信パケット２０１はトラヒック受信装置１００に流入する。

トラヒック受信装置１００にフロー配信パケット２０１が流入すると、まずデコード部１２１でフローレコードを読み込むことが出来る形式にフロー配信パケットがデコードされる（２２１）。

次に、デコード部１２１でデコードされたフローレコードは、ルータ１３１で適用されたフィルタ条件に従って、分類部１２２で分類（振り分け）される（２２２）。この際、フローレコードの分類にはフィルタ条件作成時に割り振った識別番号を参照することにより、フィルタ条件とフローレコードのマッチングを行うよりも効率的に分類処理を行うことができる。

次に、アクション実行部１２３でフィルタ条件に記載された処理が、フィルタ条件毎に分類されたフローレコードに対して行われる。アクション実行部１２３で行われる処理は複数考えられる。本実施の形態では３種類の処理が行われている。一つ目はトラヒック分析装置群１４０へのフロー配信パケット２０２の転送である。特定のフィルタ条件に合致するフローレコードでフロー配信パケット２０２を再構成し、指定されたサンプリングレートで、指定されたＩＰアドレスとポート番号に宛てて送信する（２２３）。二つ目はＩＤＳ１５０へのフローサンプルの転送である。フローサンプルのイーサフレームを指定されたＭＡＣアドレスに強制的に転送する（２２４）。三つ目はフローレコードの蓄積である。特定のフィルタ条件に合致したフローレコードのＤＢ１２１への蓄積を一定周期毎に行う（２２５）。蓄積したフローレコードは、汎用的なパケット解析ツールやトラヒック分析ツール等で利用することができる。各フローレコードは、アクション実行部１２３で行われる処理の中から一つ以上を指定され処理が行われる。

図３に、本発明の実施の形態で使用するフロー配信パケット２０１、２０２の構成例を示す。フロー配信パケット２０１、２０２はフロー配信プロトコルのバージョン、フロー配信元のルータのＩＰアドレス、パケット内のフローレコード数などの情報を記載したパケットヘッダ２２０を持つ。パケットヘッダ２２０に記載される情報は、用いられるフロー配信プロトコルによって異なる。フロー配信パケット２０１、２０２は一つ以上のフローレコード２１０を持つ。２１１はフローレコードの内容である。本実施の形態においては、フロー配信パケット作成時に、各フローレコードの分類に用いられたフィルタ条件に割り振られた識別番号２１２を、各フローレコードの中に記述する。トラヒック受信装置１００は、この識別番号２１２を参照することにより各フローレコードをフィルタ条件毎に分類する。

図４に、本発明の実施の形態で使用するフィルタ条件設定ファイル４００の例を示す。図４の例はＸＭＬを用いて記述している。フィルタ条件設定ファイル４００は、フィルタ条件を記述するAccessList４１０と、トラヒック受信装置１００でフィルタ条件毎に行う処理の詳細を記述するActionList４２０から構成される。AccessList４１０は複数のフィルタ条件FilterMatch４１１を記述することが可能である。各フィルタ条件FilterMatch４１１内には、フィルタ条件毎に割り振られる識別番号FilterId４１２が記述され、実際のフィルタ条件の項目infoElementValue４１４とトラヒック受信装置１００で行う処理を指定するActionProcess４１３が記述される。infoElementValue４１４とActionProcess４１３は一つのFilterMatch４１１につき複数記述することが可能である。ActionList４２０はAccessList４１０内で記述される各ActionProcess４１３について詳細な情報４２３を記述する。

図４に示すフィルタ条件設定ファイルは、フィルタ条件設定部１１０が作成する。フィルタ条件設定部１１０はこのフィルタ条件をルータ１３１とフロー処理部１２０の分類部１２２へ投入する。本実施の形態では、フィルタ条件設定部１１０は図４のAccessList４１０とActionList４２０の両方をルータ１３１とフロー処理部１２０の分類部１２２へ投入するが、ルータ１３１ではAccessList４１０のみを読み込み利用し、ActionList４２０は無視する。フロー処理部１２０の分類部１２２ではAccessList４１０とActionList４２０の両方を読み込み利用する。フィルタ条件設定部１１０がルータ１３１にはAccessList４１０のみを投入するようにしてもよい。

本実施の形態により、トラヒック受信装置（コレクタ）１００の振り分け条件の設定ファイルとルータ（ＮＷ機器）１３１のフィルタ条件の設定ファイルを統一化し、トラヒック受信装置１００とルータ１３１を連携させる際の設定を簡略化する。トラヒック受信装置１００とルータ１３１を連携により、あるトラヒック分析装置で検出した例えば攻撃トラヒックやスキャンと思われるような特定のフローに対して、更に詳細な分析ができるように、その特定フローだけを取り出して別の分析装置で監視するためのフィルタ条件を追加する、といったような柔軟なトラヒックの分析が可能となる。また、識別番号を用いたマッチングを行うことにより、分類（振り分け）処理の負荷を減らし、大量のフロー統計情報を処理することが可能となる。

本実施の形態のトラヒック受信装置は、１または複数のコンピュータとプログラムで構成することができる。また、そのプログラムの一部または全部に代えてハードウェアで構成してもよい。

以上、本発明者によってなされた発明を、前記実施形態に基づき具体的に説明したが、本発明は、前記実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。

本発明の実施形態の全体概要図である。本発明の実施形態のコレクタの構成図である。本発明の実施形態で用いるフロー配信パケットの構成例である。本発明の実施形態で用いるフィルタ条件設定ファイルの例である。

符号の説明

１００…トラヒック受信装置、１１０…フィルタ条件設定部、１２０…フロー処理部、１１１…トラヒック受信装置のＧＵＩ、１３０…ネットワーク、１３１−１〜１３１−３…フロー配信機能を有したルータ、１４０…トラヒック分析装置群、１４１…異常パケットの収集・分析装置、１４２…Unroutable／未使用アドレストラヒック分析装置、１４３…シグネチャ分析装置、１４４…ＴＣＰステータス分析装置・ＩＣＭＰ分析装置、１４５…ＶｏＩＰ品質分析装置、１４６…Protocol Analyzer、１５０…侵入検知システム（ＩＤＳ）、１６０…外部サーバ、１２１…デコード部、１２２…分類部、１２３…アクション実行部、２０３…ＩＦ、２０１、２０２…フロー配信パケット、２１０…フローレコード、２２０…パケットヘッダ、２１１…フローレコードの内容、４００…フィルタ条件設定ファイル

Claims

トラヒック情報配信機器から配信されるトラヒック情報を収集するトラヒック受信装置におけるトラヒック情報収集方法であって、
前記トラヒック受信装置は、フィルタ条件設定手段とフロー処理手段とを有し、
前記フィルタ条件設定手段が、前記トラヒック情報配信機器が用いるフィルタ条件を前記トラヒック情報配信機器と前記フロー処理手段に投入し、
前記フロー処理手段が、前記トラヒック情報配信機器から配信されたトラヒック情報に対して前記フィルタ条件に基づくトラヒック情報の処理を前記フィルタ条件毎に行う、
ことを特徴とするトラヒック情報収集方法。
請求項１に記載のトラヒック情報収集方法であって、
前記フロー処理手段は、デコード手段と分類手段とアクション実行手段とを有し、
前記デコード手段が、前記トラヒック情報配信機器から配信されたトラヒック情報をデコードし、
前記分類手段が、デコードされたトラヒック情報を前記フィルタ条件毎に分類し、
前記アクション実行手段が、前記分類手段によりフィルタ条件毎に分類されたトラヒック情報に対して、前記フィルタ条件設定手段によってフィルタ条件毎に定められたトラヒック情報の処理を行う、
ことを特徴とするトラヒック情報収集方法。
請求項１に記載のトラヒック情報収集方法であって、
前記フィルタ条件設定手段が、前記トラヒック情報配信機器で用いるフィルタ条件と、前記フロー処理手段でフィルタ条件毎に行うトラヒック情報の処理を、同一の設定ファイルで記述することを特徴とするトラヒック情報収集方法。
請求項１に記載のトラヒック情報収集方法であって、
前記フィルタ条件設定手段が、各フィルタ条件に個別の識別番号を割り振り、前記トラヒック情報配信機器に、マッチしたフィルタ条件の識別番号をトラヒック情報に含めて配信させ、
前記フロー処理手段が、トラヒック情報の処理を前記フィルタ条件毎に行う際に、前記識別番号のみを参照して分類を行う、
ことを特徴とするトラヒック情報収集方法。
トラヒック情報配信機器から配信されるトラヒック情報を収集するトラヒック受信装置であって、
前記トラヒック情報配信機器が用いるフィルタ条件を前記トラヒック情報配信機器と前記フロー処理手段に投入するフィルタ条件設定手段と、
前記トラヒック情報配信機器から配信されたトラヒック情報に対して前記フィルタ条件に基づくトラヒック情報の処理を前記フィルタ条件毎に行うフロー処理手段と、
を備えることを特徴とするトラヒック受信装置。