RFC2123 日本語訳
2123 Traffic Flow Measurement: Experiences with NeTraMet. N. Brownlee. March 1997. (Format: TXT=81874 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Brownlee Request for Comments: 2123 The University of Auckland Category: Informational March 1997
コメントを求めるワーキンググループN.ブラウンリーの要求をネットワークでつないでください: 2123 オークランド大学カテゴリ: 情報の1997年3月
Traffic Flow Measurement: Experiences with NeTraMet
交通の流れ測定: NeTraMetの経験
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo records experiences in implementing and using the Traffic Flow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet.
このメモはTraffic Flow Measurement ArchitectureとMeter MIBを実装して、使用する経験を記録します。 それは、NeTraMet(トラフィックメーター)とNeMaC(結合したマネージャとメーター読者)の実装について議論して、メーター規則セットの書くことを考えて、NeTraMetを使用することで交通の流れ測定システムをセットアップするときの何らかの指導を与えます。
Table of Contents
目次
1 Introduction 2
1.1 NeTraMet structure and development . . . . . . . . . . . . . . 3
1.2 Scope of this document . . . . . . . . . . . . . . . . . . . . 4
2 Implementation 4
2.1 Choice of meter platform . . . . . . . . . . . . . . . . . . . 4
2.2 Programming support requirements . . . . . . . . . . . . . . . 5
2.2.1 DOS environment . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Unix environment . . . . . . . . . . . . . . . . . . . . . 7
2.3 Implementing the meter . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Data structures . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Packet matching . . . . . . . . . . . . . . . . . . . . . 8
2.3.3 Testing groups of rule addresses . . . . . . . . . . . . . 8
2.3.4 Compression of address masks . . . . . . . . . . . . . . . 9
2.3.5 Ignoring unwanted flow data . . . . . . . . . . . . . . . 10
2.3.6 Observing meter reader activity . . . . . . . . . . . . . 11
2.3.7 Meter memory management . . . . . . . . . . . . . . . . . 12
2.4 Data collection . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Restarting a meter . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Performance . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Writing rule sets 16
3.1 Rule set to observe all flows . . . . . . . . . . . . . . . . 17
3.2 Specifying flow direction, using computed attributes . . . . . 18
3.3 Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 More complicated rule sets . . . . . . . . . . . . . . . . . . 23
この.31.2Scopeが.4 2に記録する1つの序論2 1.1のNeTraMet構造と開発、Implementation、4、2.1Choice、メータープラットホーム. . . . . . . . . . . . . . . . . . . 4 2.2Programmingでは、要件. . . . . . . . . . . . . . . 5 2.2.1DOS環境. . . . . . . . . . . . . . . . . . . . . 6 2.2.2Unix環境. . . . . . . . . . . . . . . . . . . . . 7 2.3Implementingがメーターであるとサポートしてください…; 規則アドレスの7 2.3.1のデータ構造. . . . . . . . . . . . . . . . . . . . . 7 2.3.2Packet合っている. . . . . . . . . . . . . . . . . . . . . 8 2.3.3のTestingグループ、.82.3、.4Compression、アドレスマスク. . . . . . . . . . . . . . . 9 2.3では、.5のIgnoringの求められていないフロー・データ. . . . . . . . . . . . . . . 10 2.3.6Observingは読者活動. . . . . . . . . . . . . 11 2.3.7Meterメモリ管理. . . . . . . . . . . . . . . . . 12 2.4Data収集を計量します… . . . . . . . . . . . . 14 2.5に、メーター.152.6パフォーマンス. . . . . . . . . . . . . . . . . . . . . . . . . 16 3Writing規則を再開すると、3.1Ruleがすべての流れ. . . . . . . . . . . . . . . . 17 3.2Specifying流れ方向を観測するように設定する16は設定されます、計算された属性. . . . . 18 3.3Subroutines. . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4のMoreの複雑な規則セット. . . . . . . . . . . . . . . . . . 23を使用して
Brownlee Informational [Page 1] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[1ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
4 Flow data files 26 4.1 Sample flow data file . . . . . . . . . . . . . . . . . . . . 27 4.2 Flow data file features . . . . . . . . . . . . . . . . . . . 28 4.3 Terminating and restarting meter reading . . . . . . . . . . . 29 5 Analysis applications 30 6 Using NeTraMet in a measurement system 31 6.1 Examples of NeTraMet in production use . . . . . . . . . . . . 31 7 Acknowledgments 33 8 References 33 9 Security Considerations 34 10 Author's Address 34
4つの流れデータファイル26 4.1のSampleフロー・データが.274.2のFlowデータファイル機能. . . . . . . . . . . . . . . . . . . 28 4.3Terminatingと再開検針. . . . . . . . . . . 29 5Analysisアプリケーションをファイルする、30、6Using NeTraMet、測定システム、31、6.1Examples、生産におけるNeTraMetでは、.317Acknowledgments33 8References33 9Security Considerations34 10のAuthorのAddress34を使用してください。
1 Introduction
1つの序論
Early in 1992 my University needed to develop a system for recovering the costs of its Internet traffic. In March of that year I attended the Internet Accounting Working Group's session at the San Diego IETF, where I was delighted to find that the Group had produced a detailed architecture for measuring network traffic and were waiting for someone to try implementing it.
私の大学がインターネットトラフィックのコストを取り戻すために体系をたてるために必要とした1992年に早いです。 その年の3月に、私はサンディエゴIETFにインターネットAccounting作業部会のセッションに出席しました。そこでは、私は、Groupが測定ネットワークトラフィックに詳細なアーキテクチャを作成したのがわかるので喜ばせられて、だれかがそれを実装してみるのを待っていました。
During 1992 I produced a prototype measurement system, using balanced binary trees to store information about traffic flows. This work was reported at the Washington IETF in November 1992. The prototype performed well, but it made no attempt to recover memory from old flows, and the overheads in managing the balanced trees proved to be unacceptably high. I moved on to develop a production-quality system, this time using hash tables to index the flow information.
1992の間、交通の流れの情報を保存するのにバランスのとれている2進の木を使用して、私はプロトタイプ測定システムを作成しました。 この仕事は1992年11月にワシントンIETFで報告されました。 プロトタイプはよく振る舞いましたが、それはバランスのとれている木が容認できないほど高いと立証した管理で古い流れ、およびオーバーヘッドからメモリを取り戻す試みを全くしませんでした。 今回が流れ情報に索引をつけるのにハッシュ表を使用して、私は、生産品質システムを開発するために移動しました。
This version was called NeTraMet (the Network Traffic Meter), and was released as free software in October 1993. Since then I have continued working on NeTraMet, producing new releases two or three times each year. NeTraMet is now in production use at many sites around the world. It is difficult to estimate the number of sites, but there is an active NeTraMet mailing list, which had about 130 subscribers in March 1996.
このバージョンは、NeTraMet(Network Traffic Meter)と呼ばれて、1993年10月にフリーソフトウェアとしてリリースされました。 それ以来、私は、2回か1年に3回の新版を製作して、NeTraMetに働き続けています。 NeTraMetが世界中の多くのサイトに現在、生産使用であります。 サイトの数を見積もっているのは難しいのですが、アクティブなNeTraMetメーリングリストがあります。(1996年3月に、それは、およそ130人の加入者がいました)。
Early in 1996 the Realtime Traffic Flow Measurement Working Group (RTFM) was chartered to move the Traffic Flow Measurement Architecture on to the IETF standards track. This document records traffic flow measurement experience gained through three years experience with NeTraMet.
中では、早く、1996年のRealtime Traffic Flow Measurement作業部会(RTFM)は、Traffic Flow Measurement ArchitectureをIETF標準化過程に動かすためにチャーターされました。 このドキュメント記録交通の流れ測定経験は3年間のNeTraMetの経験でしました。
Brownlee Informational [Page 2] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[2ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
1.1 NeTraMet structure and development
1.1 NeTraMet構造と開発
The Traffic Flow Architecture document [1] describes four components:
Traffic Flow Architectureドキュメント[1]は4つのコンポーネントについて説明します:
- METERS, which are attached to the network at the points where
it is desired to measure the traffic,
- Meters、どれがトラフィックを測定するのが必要であるポイントのネットワークに付けられているか。
- METER READERS, which read data from meters and store it for later
use,
- METER READERS。(そのMETER READERSはメーターからデータを読んで、後の使用のためにそれを保存します)。
- MANAGERS, which configure meters and control meter readers, and
- そしてマネージャ。(そのマネージャは、メーターとコントロールメーター読者を構成します)。
- ANALYSIS APPLICATIONS, which process the data from meter readers
so as to produce whatever reports are required.
- ANALYSIS APPLICATIONSが必要です。(ANALYSIS APPLICATIONSは、レポートが何であっても生産するためにメーター読者からデータを処理します)。
NeTraMet is a computer program which implements the Traffic Meter, stores the measured flow data in memory, and provides an SNMP agent so as to make it available to Meter Readers. The NeTraMet distribution files include NeMaC, which is a combined Manager and Meter Reader capable of managing an arbitrary number of meters, each of which may be using its own rule set, and having its flow data collected at its own specified intervals. The NeTraMet distribution also includes several rudimentary Analysis Applications, allowing users to produce simple plots from NeMaC's flow data files (fd_filter and fd_extract) and to monitor - in real time - the flows at a remote meter (nm_rc and nifty).
NeTraMetはTraffic Meterを実装して、メモリの測定フロー・データを保存して、それをMeter読者にとって利用可能にするようにSNMPエージェントを提供するコンピュータ・プログラムです。 NeMaCはNeTraMet分配ファイルは含まれています、そして、どれがそれのそれぞれがそれ自身の規則を使用しているかもしれないメーターの特殊活字の数字を管理できる結合したマネージャとMeter読者であるかはセットしました、そして、それ自身のところにフロー・データを集めさせると、間隔は指定されました。 また、NeTraMet分配は数個の初歩的なAnalysis Applicationsを含んでいます、ユーザがNeMaCの流れデータファイル(_フィルタとfd_が抽出するfd)から単純な筋を作成して、リアルタイムでリモートメーター(nm_rcの、そして、かっこよい)で流れをモニターするのを許容して。
Since the first release the Traffic Meter MIB [2] has been both improved and simplified. Significant changes have included better ways to specify traffic flows (i.e. more actions and better control structures for the Packet Matching Engine), and computed attributes (class and kind). These changes have been prompted by operational requirements at sites using NeTraMet, and have been tested extensively in successive versions of NeTraMet.
最初のリリース以来、Traffic Meter MIB[2]は改良されていて、かつ簡易型です。 著しい変化は、交通の流れを指定するより良い方法(すなわち、より多くの動作とPacket Matching Engineには、より良い制御構造)を含んで、属性(クラスと種類)を計算しました。 これらの変化は、サイトで操作上の要件によってNeTraMetを使用することでうながされて、NeTraMetの連続したバージョンで手広くテストされました。
NeTraMet is widely used to collect usage data for Internet Service Providers. This is especially so in Australia and New Zealand, but there are also active users at sites around the world, for example in Canada, France, Germany and Poland.
NeTraMetは、インターネットサービスプロバイダのための用法データを集めるのに広く使用されます。 オーストラリアとニュージーランドでこれは特にそうですが、また、活発なユーザが世界中のサイトにいます、例えば、カナダ、フランス、ドイツ、およびポーランドで。
NeTraMet is very useful as a tool for understanding exactly where traffic is flowing in large networks. Since the Traffic Meters perform considerable data reduction (as specified by their rule sets) they significantly reduce the volume of data to be read by Meter Readers. This characteristic makes NeTraMet particularly effective for networks with many remote sites. An example of this (the Kawaihiko network) is briefly described below.
NeTraMetはトラフィックがちょうどどこを大きいネットワークで流れているかを理解するためのツールとして非常に役に立ちます。 Traffic Metersがかなりのデータ整理を実行するので(それらの規則セットによって指定されるように)、Meter読者によって読まれるように、それらはデータ量をかなり減少させます。 この特性で、NeTraMetは多くのリモートサイトによってネットワークには特に有効になります。 この(Kawaihikoネットワーク)例は以下で簡潔に説明されます。
Brownlee Informational [Page 3] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[3ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
As well as providing data for post-observation analysis, NeTraMet can be used for real-time network monitoring and trouble-shooting. The NeTraMet distribution includes 'nifty,' an X/Motif application which monitors traffic flows and attempts to highlight those which are 'interesting.'
ポスト観測分析のためのデータを提供することと同様に、リアルタイムのネットワーク監視とトラブルシューティングにNeTraMetを使用できます。 NeTraMet分配は'かっこよい'、そして、交通の流れをモニターするX/モチーフアプリケーション、および'おもしろい'ものを強調する試みを含んでいます。
1.2 Scope of this document
1.2 このドキュメントの範囲
This document presents the experience gained from three years work with the Traffic Flow Measurement Architecture. Its contents are grouped as follows
このドキュメントは3年間のTraffic Flow Measurement Architectureとの仕事から行われた経験を提示します。 内容は以下の通り分類されます。
- Implementation issues for NeTraMet and NeMaC,
- NeTraMetとNeMaCのための導入問題
- How rule files work, and how to write them for particular
purposes, and
- そして特定の目的のために規則ファイルがどう動作するか、そして、どうそれらを書くか。
- How to use NeTraMet and NeMaC for short-term and long-term flow
measurement.
- 短期的で長期の流量測定にNeTraMetとNeMaCを使用する方法。
2 Implementation
2実装
2.1 Choice of meter platform
2.1 メータープラットホームの選択
As pointed out in the Architecture document [1], the goal of the Realtime Traffic Flow Measurement Working Group is to develop a standard for the Traffic Meter, with the goal of seeing it implemented in network devices such as hubs, switches and routers. Until the Architecture is well enough developed to allow this, it has sufficed to implement the meter as a program running on a general- purpose computer system.
Architectureドキュメント[1]で指摘されるように、Realtime Traffic Flow Measurement作業部会の目標はTraffic Meterの規格を開発することです、それがハブや、スイッチやルータなどのネットワークデバイスで実装されるのを見るという目標のために。 Architectureがこれを許容するために十分よく開発されるまで、それは、一般的な目的コンピュータ・システムで動くプログラムとしてメーターを実装するために十分でした。
The choice of computer system for NeTraMet was driven by the need to choose one which would be widely available within the Internet community. One strong possibility was a Unix system, since these are commonly used for a variety of network support and management tasks. For the initial implementation, however, Unix would have had some disadvantages:
NeTraMetのコンピュータ・システムの選択は1つを選ぶ必要性によって動かされました(インターネットコミュニティの中で広く利用可能でしょう)。 1つの高い可能性がUnixシステムでした、これらがさまざまなネットワークサポートと管理タスクに一般的に使用されるので。 しかしながら、初期の実装のために、Unixには、いくつかの損失があったでしょう:
- The wide variety of different Unix systems can increase the
difficulties of software support.
- 広いバラエティーの異なったUnixシステムはソフトウェアサポートの困難を増強できます。
- The cost of a Unix system as a meter is too high to allow users
to run meters simultaneously at many points within their
networks.
- 1個のメーターがユーザが同時に多くでメーターを動かすのを許容できないくらい高いので、Unixシステムの費用はそれらのネットワークの中で指します。
Brownlee Informational [Page 4] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[4ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
Another factor in choosing the platform was system performance. When I first started implementing NeTraMet it was impossible to predict how much processing workload was needed for a viable meter. Similarly, I had no idea how much memory would be required for code or data. I therefore chose to implement NeTraMet on a DOS PC. This was because:
プラットホームを選ぶ別の要素はシステム性能でした。 私が最初にNeTraMetを実装し始めたとき、どのくらいの処理ワークロードが実行可能なメーターに必要であったかを予測するのは不可能でした。 同様に、私は、どのくらいのメモリがコードかデータに必要であるかが分かりませんでした。 したがって、私は、DOS PCの上のNeTraMetを実装するのを選びました。 これがそうであった、:
- It is a minimum system in all respects. If the meter works
well on such a system, it can be implemented on almost any
hardware (including routers, switches, etc.)
- それはあらゆる点で最小のシステムです。 メーターがそのようなシステムの上でうまくいくなら、ほとんどどんなハードウェアの上でもそれを実装することができます。(ルータ、スイッチなどを含んでいます)
- It is an inexpensive system. Sites can easily afford to have
many meters around their networks.
- それは安価なシステムです。 サイトにはそれらのネットワークより多くのメーター持つ余裕が容易にあります。
- It is a simple system, and one which I had complete control over.
This allowed me to implement effective instrumentation to monitor
the meter's performance, and to include a wide variety of
performance optimisations in the code.
- それは、簡単なシステムと、私が完全なコントロールを持っていたものです。これは、計器性能をモニターして、コードにおけるさまざまな性能最適化を含むように私が有効な計装を実装するのを許容しました。
Once the meter was running I needed a manager to download rule files to it. Since a single manager and meter reader can effectively support a large number of meters, a Unix environment for NeMaC was a natural choice. There are fewer software support problems for NeMaC than for NeTraMet since NeMaC has minimal support needs - it only needs to open a UDP socket to the SNMP port on each controlled meter.
メーターがいったん動いていると、私は、マネージャが規則ファイルをそれにダウンロードする必要がありました。 事実上、読者が多くのメーター支えることができる独身のマネージャとメーター以来、NeMaCのためのUnix環境は自然な選択でした。 NeMaCには最小量のサポートの必要性があるので、NeMaCにはNeTraMetより少ないソフトウェアサポート問題があります--それは、それぞれの制御メーターの上のSNMPポートにUDPソケットを開ける必要があるだけです。
Early NeTraMet distributions contained only the PC meter and Unix manager. In later releases I ported NeTraMet (the meter) to Unix, and extended the control features of NeMaC (the combined manager and meter reader). I have also experimented with porting NeMaC to the DOS system. This is not difficult, but doesn't seem to be worth pursuing.
早めのNeTraMet配はPCメーターとUnixマネージャだけを含みました。 後のリリースでは、私は、NeTraMet(メーター)をUnixに移植して、NeMaC(結合したマネージャとメーター読者)のコントロール機能を広げました。 また、私はポーティングNeMaCをDOSシステムに実験しました。 これは、難しくはありませんが、追求する価値があるように思えません。
The current version of NeTraMet is a production-quality traffic measurement system which has been in continuous use at the University of Auckland for nearly two years.
NeTraMetの最新版はおよそ2年間オークランド大学で連続して使用中である生産品質トラフィック測定システムです。
2.2 Programming support requirements
2.2 プログラミングサポート要件
To implement the Traffic Flow Meter I needed a programming environment providing good support for the following:
Traffic Flow Meterを実装するために、私は以下の良いサポートを提供するプログラミング環境を必要としました:
- observation of packet headers on the network;
- ネットワークにおけるパケットのヘッダーの観測。
- system timer with better than 10 ms resolution;
- 10ms解決より良いのがあるシステムタイマ。
- IP (Internet Protocol), for communications with manager and meter
reader;
- マネージャとメーター読者とのコミュニケーションのためのIP(インターネットプロトコル)、。
Brownlee Informational [Page 5] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[5ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
- SNMP, for the agent implementing the Meter MIB.
- Meter MIBを実装するエージェントのためのSNMP。
2.2.1 DOS environment
2.2.1 DOS環境
For the PC I chose to use Ethernet as the physical network medium. This is simply an initial choice, being the medium used within the University of Auckland's data network. Interfaces for other media could easily be added as they are needed.
PCのために、私は、物理ネットワーク媒体としてイーサネットを使用するのを選びました。 オークランド大学のデータ網の中で使用された媒体でありこれは単に初期の選択です。 それらが必要であるように容易に他のメディアのためのインタフェースを加えることができました。
In the PC environment a variety of 'generalised' network interfaces are available. I considered those available from companies such as Novell, DEC and Microsoft and decided against them, partly because they are proprietary, and partly because they did not appear to be particularly easy to use. Instead I chose the CRYNWR Packet Drivers [3] . These are available for a wide variety of interface cards and are simple and clearly documented. They support Ethernet's promiscuous mode, allowing one to observe headers for every passing packet in a straightforward manner. One disadvantage of the Packet Drivers is that it is harder to use them with newer user shells (such as Microsoft Windows), but this was irrelevant since I intended to run the meter as the only program on a dedicated machine.
PC環境で、さまざまな'一般化された'ネットワーク・インターフェースが利用可能です。 私は、ノベルや、12月やマイクロソフトなどの会社から利用可能なそれらを考えて、それらの不利な判決を下しました、一部一部使用するのが特に簡単であるように見えなかったのでそれらが独占であるので。 代わりに、私はCRYNWR Packet Drivers[3]を選びました。これらは、さまざまなインタフェースカードに利用可能であり、簡単で明確に記録されています。 人があらゆる一時的なパケットのために正直な態度でヘッダーを観察するのを許容して、彼らはイーサネットの無差別なモードをサポートします。 Packet Driversの1つの難点は、より新しいユーザシェル(マイクロソフトWindowsなどの)と共に彼らをより使用しにくいということですが、私が専用マシンの上の唯一のプログラムとしてメーターを動かすつもりであったので、これは無関係でした。
Timing on the PC presented a challenge since the BIOS timer routines only provide a clock tick about 18 times each second, which limits the available time resolution. Initially I made do with a timing resolution of one second for packets, since I believed that most flows existed for many seconds. In recent years it has become apparent that many flows have lifetimes well under a second. To measure them properly with the Traffic Flow Meter one needs times resolved to 10 millisecond intervals, this being the size of TimeTicks, the most common time unit within SNMP [4]. Since all the details of the original PC are readily available [5], it was not difficult to understand the underlying hardware. I have written PC timer routines for NeTraMet which read the hardware timer with 256 times the resolution of the DOS clock ticks, i.e. about 5 ticks per millisecond.
BIOSタイマルーチンが1秒におよそ18回の時計ダニ(使用可能時間解決を制限する)を供給するだけであるので、PCのタイミングは挑戦を提示しました。 初めは、私はパケットのために1秒のタイミング解決で間に合わせました、私が、ほとんどの流れが何秒も存在したと信じていたので。 近年、多くの流れが1秒の下で上手に生涯を持っているのは明らかになりました。 Traffic Flow Meter1と共にそれらを適切に測定するのは、回を10回のミリ秒間隔まで決議する必要があります、このTimeTicks、SNMP[4]の中の最も一般的なタイム・ユニットのサイズの存在。 以来オリジナルのPCに関する一部始終が容易に利用可能な[5]である、基盤となるハードウェアを理解しているのは難しくはありませんでした。 私はすなわち、時計カチカチする音、およそ5のDOSの解決の256倍で1ミリセカンドあたりのカチカチする音にハードウェアタイマを読むNeTraMetのためにPCタイマルーチンを書きました。
There are many TCP/IP implementations available for DOS, but most of them are commercial software. Instead I chose Waterloo TCP [6], since this was available (including full source code) as public domain software. This was necessary since I needed to modify it to allow me to save incoming packet headers at the same time as forwarding packets destined for the meter to the IP handler routines. For SNMP I chose CMU SNMP [7], since again this was available (with full source code) as public domain software. This made it fairly simple to port it from Unix to the PC.
DOSに利用可能な多くのTCP/IPインプリメンテーションがありますが、彼らの大部分は商用ソフトウェアです。 代わりに、これが利用可能であったので(完全なソースコードを含んでいて)、私はパブリックドメインソフトとしてウォータールーTCP[6]を選びました。 私が、メーターのためにIP操作者ルーチンに運命づけられたパケットを進めることと同時に私が入って来るパケットのヘッダーを救うのを許容するようにそれを変更する必要があったので、これが必要でした。 SNMPのために、これが一方パブリックドメインソフトとして利用可能であったので(完全なソースコードがある)、私はCMU SNMP[7]を選びました。 これで、UnixからPCまでそれを移植するのはかなり簡単になりました。
Brownlee Informational [Page 6] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[6ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
Finally, for the NeTraMet development I used Borland's Turbo C and Turbo Assembler. Although many newer C programming environments are now available, I have been perfectly happy with Turbo C version 2 for the NeTraMet project!
最終的に、NeTraMet開発のために、私はBorlandのTurbo CとTurbo Assemblerを使用しました。 多くの、より新しいCプログラミング環境が現在、利用可能ですが、私はNeTraMetプロジェクトのためのTurbo Cバージョン2に完全に満足です!
2.2.2 Unix environment
2.2.2 unix環境
In implementing the Unix meter, the one obvious problem was 'how do I get access to packet headers?' Early versions of the Unix meter were implemented using various system-specific interfaces on a SunOS 4.2 system. Later versions use libpcap [8], which provides a portable method of obtaining access to packet headers on a wide range of Unix systems. I have verified that this works very well for ethernet interfaces on Solaris, SunOS, Irix, DEC Unix and Linux, and for FDDI interfaces on Solaris. libpcap provides timestamps for each packet header with resolution determined by the system clock, which is certainly better than 10 ms!
Unixメーターを実装する際に、問題がUnixメーターの'私はどのようにパケットのヘッダーに近づく手段を得ますか?'Earlyバージョンであったのが明白なものは、SunOS4.2システムの上で様々なシステム特有のインタフェースを使用することで実装されました。 後のバージョンはlibpcap[8]を使用します。(libpcapはさまざまなUnixシステムの上でパケットのヘッダーへのアクセスを得る携帯用のメソッドを提供します)。私は、これがSolaris、SunOS、Irix、12月のUnix、およびリナックスのイーサネットインタフェース、およびSolarisの上のFDDIインタフェースに非常によく働くことを確かめました。libpcapは確かに、10msより良いシステムクロックで決定している解決を各パケットのヘッダーへのタイムスタンプに提供します!
All Unix systems provide TCP/IP capabilities, so that was not an issue. For SNMP I used CMU SNMP, exactly as on the PC.
すべてのUnixシステムがTCP/IP能力を提供するので、それは問題ではありませんでした。 SNMPのために、私はちょうどPCのようにCMU SNMPを使用しました。
2.3 Implementing the meter
2.3 メーターを実装すること。
This section briefly discusses the data structures used by the meter, and the packet matching process. One very strong concern during the evolution of NeTraMet has been the need for the highest possible level of meter performance. A variety of interesting optimisations have been developed to achieve this; as discussed below. Another particular concern was the need for efficient and effective memory managent; this is discussed in detail below.
このセクションは簡潔にメーターによって使用されるデータ構造、およびパケットマッチング過程を論じます。 NeTraMetの発展の間の1回の非常に強い関心が可能な限り高いレベルのメーター性能の必要性です。 これを達成するためにさまざまなおもしろい最適化を開発してあります。 以下で議論するように。 別の特別の関心は効率的で有効なメモリmanagentの必要性でした。 以下で詳細にこれについて議論します。
2.3.1 Data structures
2.3.1 データ構造
All the programs in NeTraMet, NeMaC and their supporting utility programs are written in C, partly because C and its run-time libraries provides good access to the underlying hardware, and partly because I have found it to be a highly portable language.
NeTraMetと、NeMaCとユティリティプログラムをサポートすることにおけるすべてのプログラムがCに書かれています、Cとそのランタイムライブラリが一部基盤となるハードウェアへの良いアクセスを前提として、一部私が、それが非常に携帯用の言語であることがわかったので。
Brownlee Informational [Page 7] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[7ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
The data for each flow is stored in a C structure. The structure includes all the flow's attribute values (including packet and byte counts), together with a link field which can be used to link flows into lists. NeTraMet assumes that Adjacent addresses are 802 MAC Addresses, which are all six bytes long. Similarly, Transport addresses are assumes to be two bytes long, which is the case for port numbers in IP. Peer addresses are normally four bytes or less in length. They may, however, be as long as 20 bytes (for CLNS). I have chosen to use a fixed Peer address size, defined at compile time, so as to avoid the complexity of having variable-sized flow structures.
各流れのためのデータはC構造に保存されます。 構造はすべての流れの属性値を含んでいます(パケットとバイト・カウントを含んでいて)、リストへの流れをリンクするのに使用できるリンクフィールドと共に。 NeTraMetは、Adjacentアドレスが802MAC Addressesであると仮定します。(MAC Addressesはすべての長さ6バイトです)。 同様に、Transportアドレスはそうです。IPにおける2バイト長であると仮定します。(それは、ポートナンバーのためのケースです)。 通常、同輩アドレスは長さが4バイト以下です。 しかしながら、それらは20バイト(CLNSのための)と同じくらい長いかもしれません。 私は、変数サイズの流れ構造を持つ複雑さを避けるためにコンパイル時に定義された固定Peerアドレスサイズを使用するのを選びました。
The flow table itself is an array of pointers to flow data structures, which allows indexed access to flows via their flow numbers. There is also a single large hash table, referred to in the Architecture document [1] as the flow table's 'search index'. Each hash value in the table points to a circular chain of flows. To find a flow one computes its hash value then searches that value's flow chain.
フロー・テーブル自体はフロー・データ構造への指針の勢ぞろいです。(その勢ぞろいはそれらの流れ番号で流れへの索引をつけられたアクセスを許します)。 また、Architectureドキュメント[1]にフロー・テーブルの'検索インデックス'と呼ばれたただ一つの大きいハッシュ表があります。 テーブルの各ハッシュ値は流れの円形のチェーンを示します。 流れ1がハッシュ値を計算するのがわかるために、その値の流れチェーンはその時、探されます。
The meter stores each rule in a C structure. All the rule components have fixed sizes, but address fields must be wide enough to hold any type of address - Adjacent, Peer or Transport. The rule address width is defined at compile time, in the same way as flow Peer addresses. Each rule set is implemented as an array of pointers to rule data structures, and the rule table is an array of pointers to the rule sets. The size of each rule set is specified by NeMaC (before it begins downloading the rule set), but the maximum number of rule sets is defined at compile time.
メーターはC構造の各規則を保存します。 すべての規則コンポーネントがサイズを固定しましたが、アドレス・フィールドはどんなタイプのアドレスも保持できるくらい広くなければなりません--、隣接している、PeerかTransport。 規則アドレス幅はコンパイル時に流れPeerアドレスと同じようで定義されます。 それぞれの規則セットは指針の勢ぞろいとして規則データ構造に実装されます、そして、規則テーブルは規則セットへの指針の勢ぞろいです。 それぞれの規則セットのサイズはNeMaCによって指定されますが(規則セットをダウンロードし始める前に)、規則セットの最大数はコンパイル時に定義されます。
2.3.2 Packet matching
2.3.2 パケットマッチング
Packet matching is carried out in NeTraMet exactly as described in the Architecture document [1]. Each incoming packet header is analysed so as to determine its attribute values. These values are stored in a structure which is passed to the Packet Matching Engine. To facilitate matching with source and destination reversed this structure contains two substructures, one containing the source Adjacent, Peer and Transport address values, the other containing the destination address values.
パケットマッチングがちょうどArchitectureドキュメント[1]で説明されるようにNeTraMetで行われます。 それぞれの入って来るパケットのヘッダーは、属性値を決定するために分析されます。 これらの値はPacket Matching Engineに通り過ぎられる構造に保存されます。 逆にされるソースと目的地にこの構造を合わせるのを容易にするのが2つの基礎を含んでいて、ソースAdjacentを含む1つ、Peer、およびTransportは、値、他の含有が目的地アドレス値であると扱います。
2.3.3 Testing groups of rule addresses
2.3.3 規則アドレスのテストグループ
As described in the Architecture [1] each rule's address will usually be tested, i.e. ANDed with the rule's mask and compared with the rule's value. If the comparison fails, the next rule in sequence is executed. This allows one to write rule sets which use a group of rules to test an incoming packet to see whether one of its addresses
[1] Architectureで説明されるように、通常、各規則のアドレスはテストされるでしょう、すなわち、規則のマスクと規則の値と比べたANDed。 比較が失敗するなら、次の規則は連続して実行されます。 人が見るためにこれでテストするのに規則のグループを使用する規則セットに入って来るパケットを書くことができる、アドレスの1つ
Brownlee Informational [Page 8] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[8ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
- e.g. its SourcePeerAddress - is one of a set of specified IP addresses. Such groups of related rules can grow quite large, containing hundreds of rules. It was clear that sequential execution of such groups of rules would be slow, and that something better was essential.
- 例えば、SourcePeerAddress--1つが1セットの指定されたIPアドレスがありますか? 何百もの規則を含んでいる場合、関連する規則のそのようなグループはかなり大きくなることができます。 規則のそのようなグループの連続した実行が遅いのが、明確であり、その何かより良いものは不可欠でした。
The optimisation implemented in NeTraMet is to find groups of rules which test the same attribute with the same mask, and convert them into a single hashed search of their values. The overhead of setting up hash tables (one for each group) is incurred once, just before the meter starts running a new rule set. When a 'group' test is to be performed, the meter ANDs the incoming attribute value, computes a hash value from it, and uses this to search the group's hash table. Early tests showed that the rule hash chains were usually very short, usually having only one or two members. The effect is to reduce large sequences of tests to a hash computation and lookup, with a very small number of compares; in short this is an essential optimisation for any traffic meter!
NeTraMetで実装された最適化は、同じマスクで同じ属性をテストする規則のグループを見つけて、それらの値のただ一つの論じ尽くされた検索にそれらを変換することです。 ハッシュ表(各グループあたり1つ)をセットアップするオーバーヘッドは一度被られます、メーターが、新しい規則セットを経営してい始めるすぐ前に。 'グループ'がいつテストされるかが実行されることになっている、入って来る属性が評価するANDsを計量して、それからaハッシュ値を計算して、グループのハッシュ表を捜すのにこれを使用します。 通常、1か2人のメンバーしかいないで、早めのテストは、通常、規則ハッシュチェーンが非常に短いのを示しました。 効果はテストの大きい系列をハッシュ計算とルックアップに減少させることです、非常に少ない数で比較します。 要するにこれはどんなトラフィックメーターのための不可欠の最適化です!
There is, of course, overhead associated with performing the hashed compare. NeTraMet handles this by having a minimum group size defined at compile time. If the group is too small it is not combined into a hashed group.
もちろん、論じ尽くすのが比較する実行に関連しているオーバーヘッドがあります。 NeTraMetは、コンパイル時に定義された最小のグループサイズを持っていることによって、これを扱います。 グループが小さ過ぎるなら、それは論じ尽くされたグループに結合されません。
In early versions of NeTraMet I did not allow Gotos into a hashed group of rules, which proved to be an unnecessarily conservative position. NeTraMet stores each group's hash table in a separate memory area, and keeps a pointer to the hash table in the first rule of the group. (The rules data structure has an extra component to hold this hash table pointer). Rules within the group don't have hash table pointers; when they are executed as the target of a Goto rule they behave as ordinary rules, i.e. their tests are performed normally.
NeTraMetの早めのバージョンでは、私は規則の論じ尽くされたグループにGotosの入ることを許しませんでした。(規則は不必要に保守的な立場であると判明しました)。 NeTraMetは別々のメモリ領域に各グループのハッシュ表を保存して、グループの最初の規則で指針をハッシュ表に保ちます。 (データ構造にはこのハッシュ表指針を保持する付加的なコンポーネントがあるという規則。) グループの中の規則には、ハッシュ表指針がありません。 それらがゴトー規則の目標として実行されるとき、彼らは普通の規則として振る舞います、すなわち、通常、彼らのテストが実行されます。
2.3.4 Compression of address masks
2.3.4 アドレスマスクの圧縮
When the Packet Matching Engine has decided that an incoming packet belongs to a flow which is to be measured, it searches the flow table to determine whether or not the flow is already present. It does this by computing a hash from the packet and using it for access to the flow table's search index.
Packet Matching Engineが、入って来るパケットが測定されることである流れに属すと決めたとき、それは、流れが既に存在しているかどうか決定するためにフロー・テーブルを捜します。 それは、パケットからハッシュを計算して、フロー・テーブルの検索インデックスへのアクセスにそれを使用することによって、これをします。
When designing a hash table, one normally assumes that the objects in the table have a constant size. For NeTraMet's flow table this would mean that each flow would contain a value for every attribute. This, however, is not the case, since only those attribute values 'pushed' by rules during packet matching are stored for a flow.
ハッシュ表を設計するとき、通常、人は、テーブルのオブジェクトには一定のサイズがあると仮定します。 NeTraMetのフロー・テーブルに関しては、これは、各流れがあらゆる属性のための値を含むことを意味するでしょう。 しかしながら、これはそうではありません、パケットマッチングの間の規則で'押された'それらの属性値だけが流れのために保存されるので。
Brownlee Informational [Page 9] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[9ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
To demonstrate this problem , let us assume that every flow in the table contains a value for only one attribute, SourcePeerAddress, and that the rule set decides whether flows belong to a specified list of IP networks, in which case only their network numbers are pushed. The rules perform this test using a variety of masks, since the network number allocations range from 16 to 24 bits in width. In searching the flow table, the meter must distinguish between zeroes in the address and 'don't care' bits which had been ANDed out. To achieve this it must store SourcePeerMask values in the flow table as well as the ANDed SourcePeerAddress values.
この問題を示すために、テーブルのあらゆる流れが1つの属性だけのための値、SourcePeerAddressを含んでいて、規則セットが、流れがIPネットワークに関する明細表に属すかどうか決めて、その場合、それらのネットワーク・ナンバーだけが押されると仮定しましょう。 規則はさまざまなマスクを使用することでこのテストを実行します、ネットワーク・ナンバー配分が16〜24ビット幅のねらいを定めるので。 フロー・テーブルを捜す際に、メーターは外でANDedであったアドレスと'気にかけないでください'というビットのゼロを見分けなければなりません。 これを達成するために、それはANDed SourcePeerAddress値と同様にフロー・テーブルにSourcePeerMask値を保存しなければなりません。
In early versions of NeTraMet this problem was side-stepped by using multiple hash tables and relying on the user to write rules which used the same set of attributes and masks for all the flows in each table. This was effective, but clumsy and difficult to explain. Later versions changed to using a single hash table, and storing the mask values for all the address attributes in each flow.
NeTraMetの早めのバージョンでは、この問題は、各テーブルのすべての流れに同じセットの属性とマスクを使用した規則を書くために複数のハッシュ表を使用して、ユーザに頼ることによって、かわされました。 これは、有効ですが、不器用であって、説明するのは難しかったです。 後のバージョンは各流れにおけるすべてのアドレス属性のためにただ一つのハッシュ表を使用して、マスク値を保存するのに変化しました。
The current version of the meter stores the address masks in compressed form. After examining a large number of rule sets I realised that although a rule set may have many rules, it usually has a very small number of address masks. It is a simple matter to build a table of address masks, and store an index to this 'mask table' instead of a complete mask. NeTraMet's maximum number of masks is defined at compile time, up to a maximum of 256. This allows me to use a single byte for each mask in the flow data structure, significantly reducing the structure's size. As well as this size reduction, two masks can be compared by comparing their indices in the mask table, i.e. it reduces to a single-byte comparison. Overall, using a mask table seems to provide useful improvements in storage efficiency and execution speed.
メーターの最新版は圧縮形にアドレスマスクを保存します。 規則がセットしましたが、多くの規則を持っているかもしれない私がわかった多くの規則セットを調べた後に、通常、それは非常に少ない数のアドレスマスクを持っています。 完全なマスクの代わりにこの'マスクテーブル'としてアドレスマスクのテーブルを組立てて、インデックスを保存するのは、簡単な事柄です。 NeTraMetの最大数のマスクはコンパイル時に最大256まで定義されます。 これで、私は各マスクに流れデータ構造に1バイトを使用できます、構造のサイズをかなり減少させて。 このサイズリダクションと同様に、マスクテーブルのそれらのインデックスリストを比較することによって、2個のマスクを比較できます、すなわち、それは単一のバイト比較に減少します。 全体的に見て、マスクテーブルを使用するのは充てん率と実行速度に役に立つ改良を提供するように思えます。
2.3.5 Ignoring unwanted flow data
2.3.5 求められていないフロー・データを無視すること。
As described in the Architecture document [1], every incoming packet is tested against the current rule set by the Packet Matching Engine. This section explains my efforts to improve NeTraMet performance on the PC by reducing the amount of processing required by each incoming packet.
Architectureドキュメント[1]で説明されるように、あらゆる入って来るパケットが現在の規則セットに対してPacket Matching Engineによってテストされます。 このセクションは、それぞれの入って来るパケットによって必要とされた処理の量を減少させることによってPCに関するNeTraMet性能を向上させるために私の取り組みについて説明します。
On the PC each incoming packet causes an interrupt, which NeTraMet must process so as to collect information about the packet. In early versions I used a ring buffer with 512 slots for packet headers, and simply copied each packet's first 64 bytes into the next free slot. The packet headers were later taken from the buffer, attribute values were extracted from them, and the resulting 'incoming attribute values' records were passed to the Packet Matching Engine.
PCでは、それぞれの入って来るパケットは中断を引き起こします。(NeTraMetは、パケットの情報を集めるためにそれを処理しなければなりません)。 早めのバージョンでは、私は、パケットのヘッダーに512のスロットがあるリングバッファを使用して、単に次の自由なスロットにパケットの各ものを最初に64バイトコピーしました。 パケットのヘッダーは後でバッファから抜粋されました、そして、属性値はそれらから抽出されました、そして、結果として起こる'入って来る属性値'記録はPacket Matching Engineに移られました。
Brownlee Informational [Page 10] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[10ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
I modified the interrupt handling code to extract the attribute values and store them in a 'buffer slot.' This reduced the amount of storage required in each slot, allowing more space for storing flows. It did increase slightly the amount of processing done for each packet interrupt, but this has not caused any problems.
私は、属性値を抽出して、'バッファスロット'にそれらを保存するように割込み処理コードを変更しました。Thisは各スロットで必要であるストレージの量を減少させました、流れを保存するための、より多くのスペースを許容して。 それはそれぞれのパケット中断のために行われた処理の量をわずかに増強しましたが、これはどんな問題も引き起こしていません。
In later versions I realised that if one is only interested in measuring IP packets, there is no point in storing (and later processing) Novell or EtherTalk packets! It is a simple matter for the meter to inspect a rule set and determine which Peer types are of interest. If there are PushRule rules which test SourcePeerType (or DestPeerType), they specify which types are of interest. If there are no such rules, every packet type is of interest. The PC NeTraMet has a set of Boolean variables, one for each protocol it can handle. The values of these 'protocol' variables are determined when the meter begins running a new rule set. For each incoming packet, the interrupt handler determines the Peer type. If the protocol is not of interest, no further processing is done - the packet is simply ignored. In a similar manner, if Adjacent addresses are never tested there is no point in copying them into the packet buffer slot.
後のバージョンでは、私は、人がIPパケットを測定するだけでありたいなら、ノベルかEtherTalkパケットを保存する(後で処理して)意味が全くないとわかりました! メーターが、規則セットを点検して、どのPeerタイプが興味があるかを決定するのは、簡単な事柄です。 SourcePeerType(または、DestPeerType)をテストするPushRule規則があれば、それらは、どのタイプが興味があるかを指定します。 何かそのような規則がなければ、すべてのパケットタイプが興味があります。 PC NeTraMetには、1セットのブール変数、それが扱うことができる各プロトコルあたり1つがあります。 メーターが、新しい規則セットを経営してい始めるとき、これらの'プロトコル'変数の値は決定しています。 それぞれの入って来るパケットに関しては、割り込みハンドラは、Peerがタイプすることを決定します。 プロトコルは興味がないなら、どんなより遠い処理もしません--パケットは単に無視されます。 同じように、Adjacentアドレスが決してテストされないなら、パケットバッファスロットにそれらをコピーする意味が全くありません。
The overall effect of these optimisations is most noticeable for rule files which measure IP flows on a network segment which also carries a lot of traffic for other network protocols; this situation is common on multiprotocol Local Area networks. On the Unix version of NeTraMet the Operating System does all the packet interrupt processing, and libpcap [8] delivers packet headers directly to NeTraMet. The 'protocol' and 'adjacent address' optimisations are still performed, at the point when NeTraMet receives the packet headers from libpcap.
また、他のネットワーク・プロトコルのために多くのトラフィックを運ぶネットワークセグメントでIP流れを測定する規則ファイルに、これらの最適化の総合的な効果は最もめぼしいです。 この状況はmultiprotocol Local Areaネットワークで一般的です。 NeTraMetのUnixバージョンでは、Operating Systemはすべてのパケット割込み処理をします、そして、libpcap[8]は直接NeTraMetにパケットのヘッダーを提供します。 'プロトコル'と'隣接しているアドレス'最適化はNeTraMetがlibpcapからパケットのヘッダーを受けるときのポイントでまだ実行されています。
2.3.6 Observing meter reader activity
2.3.6 メーター読者活動を観測すること。
The Architecture document [1] explains that a flow data record must be held in the meter until its data has been read by a meter reader. A meter must therefore have a reliable way of deciding when flow data has been read. The problem is complicated by the fact that there may be more than one meter reader, and that meter readers collect their data asynchronously.
Architectureドキュメント[1]で、データがメーター読者によって読まれるまでメーターに流れデータレコードを保持しなければならないのがわかります。 したがって、1メーターには、いつフロー・データを読んであるかを決める信頼できる方法がなければなりません。 1メーター以上の読者がいるかもしれなくて、メーター読者が彼らのデータを非同期に集めるという事実によって問題は複雑にされます。
Brownlee Informational [Page 11] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[11ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
Early versions of NeTraMet solved this problem by having a single MIB variable which a meter reader could set to indicate that it was beginning a data collection. In response to such an SNMP SET request, NeTraMet would update its 'collectors' table. This had an entry for each meter reader, and variables recording the start time for the last two collections. The most recent collection might still be in progress, but its start time provides a safe estimate of the time when the one before it actually finished. Space used for flows which have been idle since the penultimate collection started can be recovered by the meter's garbage collector, as described below.
NeTraMetの早めのバージョンは、メーター読者がデータ収集を始めていたのを示すように設定できるただ一つのMIB変数を持っていることによって、この問題を解決しました。 そのようなSNMP SET要求に対応して、NeTraMetは'コレクタ'テーブルをアップデートするでしょう。 これは、それぞれのメーター読者のためにエントリーを持っていて、最後の2つの収集のために開始時刻を記録する変数を持っていました。 最新の収集はまだ進行しているかもしれませんが、開始時刻はそれの前のものが実際に終わった時の安全な見積りを提供します。 計器ごみ収集人は終わりから二番目の収集が始まって以来活動していない流れに使用されるスペースを回復できます、以下で説明されるように。
The Meter MIB [2] specifies a more general table of meter reader information. A meter reader wishing to collect data from a meter must inform the meter of its intention by creating a row in the table, then setting a LastTime variable in that row to indicate the start of a collection. The meter handles such a SET request exactly as described above. If there are multiple meter readers the meter can easily find the earliest time any of them started its penultimate collection, and may recover flows idle since then. Should a meter reader fail, NeTraMet will eventually time out its entry in the meter reader info table, and delete it. This avoids a situation where the meter can't recover flows until they have been collected by several meter readers, one of which has failed.
Meter MIB[2]はメーター読者情報の、より一般的なテーブルを指定します。 1メーターからデータを集めたがっているメーター読者はテーブルの行を作成することによって、意志のメーターを知らせなければなりません、次に、収集の始まりを示すためにその行にLastTime変数をはめ込んで。 メーターはちょうど上で説明されるようにそのようなSET要求を扱います。 メーターが容易に当たることができる中で最も前半時間もの複数のメーター読者がいれば、彼らのいずれも、終わりから二番目の収集を始めて、それ以来活動していない流れを回復するかもしれません。 メーター読者やり損ない、NeTraMetは結局メーター読者インフォメーションテーブルでタイムアウトにエントリーを望んでいて、それを削除するはずですか? これはメーターがそれの1つが失敗したそれらが数人のメーター読者によって集められるまでの流れを回復できない状況を避けます。
2.3.7 Meter memory management
2.3.7 メーターメモリ管理
In principle, the size of the flow table (i.e. the maximum number of flows) could be changed dynamically. This would involve allocating space for the flow table's new pointer array and copying the old pointers into it. NeTraMet does not implement this. Instead the maximum number of flows is set from the command line when it starts execution. If no maximum is specified, a compile-time default number is used.
原則として、ダイナミックにフロー・テーブル(すなわち、流れの最大数)のサイズを変えることができました。 これは、フロー・テーブルの新しい指針配列のためにスペースを割り当てて、古い指針をそれにコピーすることを伴うでしょう。 NeTraMetはこれを実装しません。 それが実行を始めるとき、代わりに、流れの最大数はコマンドラインから設定されます。 最大が全く指定されないなら、コンパイル時のデフォルト番号は使用されています。
Memory for flow data structures (i.e. 'flows') is allocated dynamically. NeTraMet requests the C run-time system for blocks of several hundred flows, and links them into a free list. When a new flow is needed NeTraMet gets memory space from the free list, then searches the flow table's pointer array for an unused flow pointer. In practice a 'last-allocated' index is used to point to the flow table, so a simple linear search suffices. The flow index is saved in the flow's data record, and its other attribute values are set to zero.
ダイナミックに流れデータ構造(すなわち、'流れる')のためのメモリを割り当てます。 NeTraMetは数100のブロックのCラン・タイム・システムが流れるよう要求して、免税品リストの中にそれらをリンクします。 新しい流れが必要であると、NeTraMetは免税品リストからメモリスペースを得て、未使用の流れ指針のためにフロー・テーブルの指針配列を捜します。 実際には、'最後、割り当てられた'インデックスがフロー・テーブルを示すのに使用されるので、簡単なリニアサーチは十分です。 フローインデックスは流れのデータレコード、および合わせてください値が設定されるゼロその他の属性で保存されます。
Brownlee Informational [Page 12] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[12ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
To release a flow data record it must first be removed from any hash list it is part of - this is straightforward since those lists are circular. The flow's entry in the flow table pointer array is then set to zero (NULL pointer), and its space is returned to the free list.
最初にどんなハッシュリストからも取り除いて、それが部分であるということであるに違いないというフロー・データ記録を発表するために、簡単です、--それらのリストが円形であるので、これは簡単です。 次に、フロー・テーブル指針配列における流れのエントリーが(NULL指針)のゼロに合うように設定されて、スペースは免税品リストに返されます。
Once a flow data record is created it could continue to exist indefinitely. In time, however, the meter would run out of space. To deal with this problem NeTraMet uses an incremental garbage collector to reclaim memory.
流れデータレコードがいったん作成されると、それは無期限に存続するかもしれません。 しかしながら、時間内に、メーターはスペースを使い果たすでしょう。 この問題NeTraMetに対処するのは、メモリを取り戻すのに増加のごみ収集人を使用します。
At regular intervals specified by a 'GarbageCollectInterval' variable the garbage collector procedure is invoked. This searches through the flow table looking for flows which might be recovered. To control the resources consumed by garbage collection there are limits on the number of in-use and idle flows which the garbage collector may inspect these are set either when NeTraMet is started (as options on the command line) or dynamically by NeMaC (using variables in an Enterprise MIB for NeTraMet)
'GarbageCollectInterval'変数によって指定された一定の間隔で、ごみ収集人手順は呼び出されます。 これは、回復されるかもしれない流れを探しながら、フロー・テーブルを隅々まで捜します。 ガーベージコレクションで消費されたリソースを制御するために、限界がある、NeTraMetがNeMaCによってダイナミックに始動されるとき(コマンドラインにおけるオプションとして)、ごみ収集人が点検するかもしれない使用中の、そして、活動していない流れの数では、これらは設定されます。(NeTraMetにエンタープライズMIBの変数を使用します)
To decide whether a flow can be recovered, the garbage collector considers how long it has been idle (no packets in either direction), and when its data was last collected. If it has been collected by all known meter readers since its LastTime, its memory may be recovered. This alogrithm is implemented using a variable called 'GarbageCollectTime,' which normally contains the meter's UpTime when the penultimate collection (i.e. the one before last) was started. See the section on observing meter reader activity (above) for more details.
流れを回復できるかどうか決めるために、ごみ収集人は、それがどれくらい長い間活動していないか、そして、(どちらかの方向へのパケットがありません)データが最後にいつ集められたかを考えます。 LastTime以来それがすべての知られているメーター読者によって集められているなら、メモリは回復されるかもしれません。 このalogrithmは、終わりから二番目の収集(すなわち、最終の前のもの)が始められたとき通常、計器UpTimeを含む'GarbageCollectTime'と呼ばれる変数を使用することで実装されます。 その他の詳細に関してメーター読者活動(above)を観測するところのセクションを見てください。
Should flows not be collected often enough the meter could run out of space. NeTraMet attempts to prevent this by having a low-priority background process check the percentage of flows active and compare it with the HighWaterMark MIB variable. If the percentage of active flows is greater than the high-water mark, 'GarbageCollectTime' is incremented by the current value of the InactivityTimeout MIB variable.
十分しばしば流れを集めるというわけではないなら、メーターはスペースを使い果たすかもしれません。 NeTraMetは低い優先度バックグラウンドで実行中のプロセスに流れの割合をチェックさせることによってアクティブな状態でこれを防いで、HighWaterMark MIB変数とそれを比べるのを試みます。 アクティブな流れの割合が最高水位線より大きいなら、'GarbageCollectTime'はInactivityTimeout MIB変数の現行価値によって増加されます。
The Meter MIB [2] specifies that a meter should switch to using a 'standby' rule set if the percentage of active flows rises above HighWaterMark. In using NeTraMet to measure traffic flows to and from the University of Auckland it has not been difficult to create standby rules which are very similar to the 'production' rule file, differing only in that they push much less information about flows. This has, on several occasions, allowed the meter to continue running for one or two days after the meter reader failed. When the meter reader restarted, it was able to collect all the accumulated flow data!
Meter MIB[2]は、1個のメーターがアクティブな流れの割合がHighWaterMarkの上で上昇するなら'予備'規則セットを使用するのに切り替わるはずであると指定します。 オークランド大学とオークランド大学からの交通の流れを測定するのにNeTraMetを使用するのにおいて、'生産'規則ファイルと非常に同様の予備規則を作成するのは難しくはありません、まして、単に流れの情報を押すという点において異なって。 これで、メーターは、時折、メーター読者が失敗した1日か2日後に立候補し続けることができました。 メーター読者が再開したとき、それはすべての蓄積されたフロー・データを集めることができました!
Brownlee Informational [Page 13] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[13ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
The MIB also specifies that the meter should take some action when the active flow percentage rises above its FloodMark value. If this were not done, the meter could spend a rapidly increasing proportion of its time garbage collecting, to the point where its ability to respond to requests from its manager would be compromised. NeTraMet switches to the default rule set when its FloodMark is reached.
また、MIBは、アクティブな流れ割合がFloodMark値を超えて上昇するとき、メーターが何らかの行動を取るはずであると指定します。 これをしないなら、メーターは時間ゴミの急速に増加する割合を集まるのに費やすかもしれないでしょうに、マネージャから要求に応じる性能が感染されるポイントに。 FloodMarkに達しているとき、省略時の解釈へのNeTraMetスイッチはセットしました。
A potentially large number of new flows may be created when the meter switches to a standby rule set. It is important to set a HighWaterMark so as to allow enough flow table space for this. In practice, a HighWaterMark of 65% and a FloodMark of 95% seem to work well.
予備規則へのメータースイッチがセットしたとき、潜在的に多くの新しい流れが引き起こされるかもしれません。 HighWaterMarkを設定するのは、これのための十分なフロー・テーブルスペースを許容するために重要です。 実際には、65%のHighWaterMarkと95%のFloodMarkは、うまくいくように思えます。
2.4 Data collection
2.4 データ収集
As explained above, a meter reader wishing to collect flows begins each collection by setting the LastTime variable in its ReaderInfoTable row, then works its way through the flow table collecting data. A number of algorithms can be used to examine the flow table; these are presented below.
上で説明されるように、流れを集めたがっているメーター読者は、ReaderInfoTable行にLastTime変数をはめ込むことによって各収集を始めて、次に、フロー・テーブル資料収集を進んでいます。 フロー・テーブルを調べるのに多くのアルゴリズムを使用できます。 これらは以下に提示されます。
The simplest approach is a linear scan of the table, reading the LastTime variable for each row. If the read fails the row is inactive. If it succeeds, it is of interest if its LastTime value is greater than the time of the last collection. Although this method is simple it is also rather slow, requiring an SNMP GET request for every possible flow; this renders it impractical.
各行のためにLastTime変数を読んで、最も簡単なアプローチはテーブルの線形走査です。 読みが失敗するなら、行は不活発です。 成功するなら、LastTime値が最後の収集の時間より大きいなら、興味があります。 このメソッドは簡単ですが、また、あらゆる可能な流れを求めるSNMP GET要求を必要として、それもかなり遅いです。 これはそれを非実用的にします。
Early versions of NeTraMet used two 'windows' into the flow table to find flows which were of interest. Both windows were SNMP tables, indexed by a variable which specified a time. A succession of GETNEXT requests on one of these windows allowed NeMaC (the meter reader) to find the flow indices for all flows which had been active since the specified time. The two windows were the ActivityTime window (which located active flows), and the CreateTime window (which located new flows). Knowing the index of an active flow, the meter reader can GET the values for all the attributes of interest. NeMaC allows the user to specify which these are, rather than simply read all the attributes.
NeTraMetの早めのバージョンは、興味がある流れを見つけるのに2'窓'をフロー・テーブルに使用しました。 両方の窓は時間を指定した変数によって索引をつけられたSNMPテーブルでした。 これらの窓の1つのGETNEXT要求の連続で、指定された時間以来NeMaC(メーター読者)はすべてのアクティブであった流れに関して流れインデックスリストを見つけることができました。 2つの窓が、ActivityTimeの窓(アクティブな流れの場所を見つけた)と、CreateTimeの窓(新しい流れの場所を見つけた)でした。 インデックスを知っている、能動態は流れて、メーター読者缶のGETは興味があるすべての属性のための値です。 NeMaCは単にすべての属性を読むよりこれらがどれであるかをユーザをむしろ指定させます。
Having the two windows allowed NeMaC to read attributes which remain constant - such as the flow's address attributes - when the flow is created, but to only read attributes which change with time - such as its packet and byte counts - during later collections. Experience has shown, however, that many flows have rather short lifetimes; one effect of this is that the improved efficiency of using two windows does not result in any worthwhile improvement in collection performance.
2つの窓を持っているのに、NeMaCは流れが引き起こされますが、そのパケットやバイトなどの時間を交換する属性を読むだけであるのが数えられるとき後の収集の間に流れのアドレス属性などのように一定のままで残っている属性を読むことができました。 しかしながら、経験は、多くの流れにはかなり短い寿命があるのを示しました。 この1つの効果は2つの窓を使用する改良された効率が収集性能における少しの価値がある改良ももたらさないということです。
Brownlee Informational [Page 14] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[14ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
The current version of the Meter MIB [2] uses a TimeFilter variable in the flow table entries. This can be used with GETNEXT requests to find all flows which have been active since a specified time directly, without requiring the extra 'window' SNMP variables. It can be combined with SNMPv2's GETBULK request to further reduce the number of SNMP packets needed for each collection; I have yet to implement this in NeTraMet.
Meter MIB[2]の最新版はフロー・テーブルエントリーでTimeFilter変数を使用します。 すべての指定された時間以来直接アクティブである流れを見つけるというGETNEXT要求と共にこれを使用できます、付加的な'窓'SNMP変数を必要としないで。 各収集に必要であるSNMPパケットの数をさらに減少させるというSNMPv2のGETBULK要求にそれを結合できます。 私はNeTraMetでまだこれを実装していません。
A disadvantage of using SNMP to collect data from the meter is that SNMP packets impose a high overhead. For example, if we wish to read an Integer32 variable (four bytes of data), it will be returned with its object identifier, type and length, i.e. at least ten bytes of superfluous data. One way to reduce this overhead is to use an Opaque object to return a collection of data. NeTraMet uses this approach to retrieve 'column activity data' from the meter, as follows.
メーターからデータを集めるのにSNMPを使用する不都合はSNMPパケットが高いオーバーヘッドを課すということです。 例えば、Integer32変数(4バイトのデータ)を読みたいと思うなら、オブジェクト識別子、タイプ、および長さ(すなわち、少なくとも10バイトの余計なデータ)と共にそれを返すでしょう。 このオーバーヘッドを下げる1つの方法はデータの収集を返すのにOpaqueオブジェクトを使用することです。 NeTraMetは、以下のメーターからの'コラム活動データ'を検索するのにこのアプローチを使用します。
Each packet of column activity data contains data values for a specified attribute, and each value is preceded by its flow number. The flow table can be regarded as a two-dimensional array, with a column for each flow attribute. Column activity data objects allow the meter reader to read columns of the flow table, so as to collect only those attributes specified by the user. The actual implementation is complicated by the fact that since the flow table is read column by column, rows can become active after the first column has been read. NeMaC reads the widest columns (those with greatest size in bytes, e.g. PeerAddress) first, and ignores any rows which appear in later columns. Newly active rows will, of course, be read in the next collection.
コラム活動データの各パケットは指定された属性のためのデータ値を含んでいます、そして、流れ番号は各値に先行します。 フロー・テーブルをそれぞれの流れ属性のためのコラムがある2次元配列と見なすことができます。 メーター読者はコラム活動データ・オブジェクトでフロー・テーブルに関するコラムを読むことができます、ユーザによって指定されたそれらの属性だけを集めるために。 コラムがコラムによってフロー・テーブルに読み込まれるので、最初のコラムを読んである後に、行がアクティブになることができるという事実によって実際の実装は複雑にされます。 NeMaCは最初に最も広いコラム(バイト、例えば、PeerAddressにおける最大級のサイズがあるそれら)を読んで、後のコラムに現れるどんな行も無視します。 新たにアクティブな行はもちろん次の収集で読まれるでしょう。
Using Opaque objects in this way dramatically reduces the number of SNMP packets required to read a meter. This has proved worthwhile in situations where the number of flows is large (for example on busy LANs), and where the meter(s) are physically dispersed over slow WAN links. It has the disadvantage that general-purpose MIB browsers cannot understand the column activity variables, but this seems a small price to pay for the improved data collection performance.
このようにOpaqueオブジェクトを使用すると、パケットが検針するのを必要としたSNMPの数は劇的に減少します。 これは流れの数が大きく(例えば、忙しいLANの)、メーターが遅いWANリンクの上に物理的に分散される状況でやりがいがありました。 それには、不都合があります。向上したデータ収集性能の代価を払うために汎用MIBブラウザはコラム活動変数を理解できるのではなく、これを理解するようにわずかな価格に思えます。
2.5 Restarting a meter
2.5 1個のメーターを再開すること。
If a meter fails, for example because of a power failure, it will restart and begin running rule set 1, the default rule set which is built into the meter. Its manager must recognise that this has happened, and respond with some suitable action.
1個のメーターが例えば、停電で失敗すると、再開して、規則セット1を経営してい始めるでしょう、メーターが組み込まれる省略時の解釈セット。 マネージャは、これが起こったと認めて、何らかの適当な動作でこたえなければなりません。
NeMaC allows the user to specify a 'keepalive' interval. After every such interval NeMaC reads the meter's sysUptime and compares it with the last sysUptime. If the new sysUptime is less than the last one,
NeMaCはユーザに'keepalive'間隔を指定させます。 そのようなあらゆる間隔の後に、NeMaCは計器sysUptimeを読み込んで、最後のsysUptimeとそれを比べます。 新しいsysUptimeが最後のもの以下であるなら
Brownlee Informational [Page 15] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[15ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
NeMaC decides that the meter has restarted. It downloads the meter's backup rule set and production rule set, then requests the meter to start running the production rule set. In normal use we use a keepalive interval of five minutes and a collection interval of 15 minutes. If a meter restarts, we lose up to five minutes data before the rules sets are downloaded.
NeMaCは、メーターが再開したと決めます。 それは、計器バックアップ規則セットとプロダクションルールセットをダウンロードして、次に、プロダクションルールセットを経営してい始めるようメーターに要求します。 通常の使用で、私たちは5分のkeepalive間隔と15分の収集間隔を費やします。 1個のメーターが再開するなら、私たちはセットをダウンロードするという規則の前に最大5分のデータを失います。
Having the meter run the default rule set on startup is part of the Traffic Flow Measurement Architecture [1], in keeping with the notion that meters are very simple devices which do not have disk storage. Since disks are now very cheap, it may be worth considering whether the architecture should allow a meter to save its configuration (including rule sets) on disk.
省略時の解釈が始動に設定したメーター走を持つのは、Traffic Flow Measurement Architecture[1]の一部です、メーターがディスクストレージを持っていない非常に簡単なデバイスであるという概念で保つ際に。 ディスクが現在非常に安いので、ディスクの上で1メーターがアーキテクチャで構成を節約するはずであることができるかどうか(規則セットを含んでいて)考える価値があるかもしれません。
2.6 Performance
2.6 パフォーマンス
The PC version of the meter, NeTraMet, continually measures how much processor time is being used. Whenever there is no incoming packet data to process, 'dummy' packets are generated and placed in the input buffer. These packets are processed normally by the Packet Matching Engine; they have a PeerType of 'dummy.' The numbers of dummy and normal packets are counted by the meter; their ratio is used as an estimate of the processor time which is 'idle,' i.e. not being used to process incoming packets. The Unix version is intended to run as a process in a multiprocessing system, so it cannot busy- wait in this way.
メーターのPCバージョン(NeTraMet)は、絶えずどのくらいのプロセッサ時間が費やされているかを測定します。 処理するどんな入って来るパケットデータもないときはいつも、'ダミー'のパケットは、入力バッファに生成されて、置かれます。 通常、これらのパケットはPacket Matching Engineによって処理されます。 彼らは'ダミー'のPeerTypeを持っています。ダミーの、そして、正常なパケットの数はメーターによって数えられます。 それらの比率は、入って来るパケットを処理するのに'活動していません、な'プロセッサ時間、すなわち、使用されない見積りとして使用されます。 Unixバージョンがプロセスとしてマルチプロセシングシステムで稼働することを意図するので、それはこのように待ちと忙しくすることができません。
The meter also collects several other performance measures; these can be displayed on the meter console in response to keyboard requests.
また、メーターは他の数個の性能測定を集めます。 メーターコンソールの上にキーボード要求に対応してこれらを表示できます。
The PC meter can be used with a 10 MHz 286 machine, on which it can handle a steady load of about 750 packets per second. On a 25 MHz 386SX it will handle about 1250 packets per second. Users have reported that a 40 MHz 486 can handle peaks of about 3,000 packets per second without packet loss. The Unix meter has been tested metering traffic on a (lightly loaded) FDDI interface; it uses about one percent of the processor time on a SPARC 10 system running Solaris.
10MHzの286マシンと共にPCメーターを使用できます。そこでは、それが、1秒あたりおよそ750のパケットの安定した荷重を扱うことができます。 25MHzの386SXでは、それは1秒あたりおよそ1250のパケットを扱うでしょう。 ユーザは、40MHz486がパケット損失なしで1秒あたりおよそ3,000のパケットのピークを扱うことができると報告しました。 Unixメーターは(軽くロードされています)のFDDIインタフェースのテストされた計量トラフィックです。 それは、Solarisを実行しながら、SPARC10システムの上でプロセッサ現代のおよそ1パーセントを使用します。
3 Writing rule sets
3 規則セットに書くこと。
The Traffic Meter provides a versatile device for measuring a user- specified set of traffic flows, and performing useful data reduction on them. This data reduction capability not only minimises the volume of data to be collected by meter readers, but also simplifies the later processing of traffic flow data.
Traffic Meterはユーザの指定されたセットの交通の流れを測定して、役に立つデータ整理をそれらに実行するための多能なデバイスを提供します。 このデータ整理能力はメーター読者によって集められるようにデータ量を最小とならせるだけではなく、トラフィックフロー・データの後の処理を簡素化もします。
Brownlee Informational [Page 16] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[16ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
The flows of interest, and the processing to be performed, are specified in a 'rule set' which is downloaded to the meter (NeTraMet) by the manager (NeMaC). This section explains what is involved in writing rule sets.
興味がある流れ、および実行されるべき処理はマネージャ(NeMaC)によってメーター(NeTraMet)にダウンロードされる'規則セット'で指定されます。 このセクションは、何が規則セットに書くのにかかわるかを説明します。
NeTraMet is limited to metering packets observed on a network segment. This means that for all the observed flows, Source and Dest Type attributes (e.g. SourcePeerType and DestPeerType) have the same value.
NeTraMetはネットワークセグメントで観察された計量パケットに制限されます。 これは、すべての観測された流れのために、同じ値がSourceとDest Type属性(例えば、SourcePeerTypeとDestPeerType)にあることを意味します。
The NeTraMet implementation uses single variables in its flow data structure for AdjacentType, SourceType and TransType. Nonetheless, the rule sets discussed below push values for both Source and Dest Type attributes; this make sure that packet matching works properly with the directions reversed, even for a meter which allows Source and Dest Type values to be different.
NeTraMet実装はAdjacentType、SourceType、およびTransTypeに流れデータ構造にただ一つの変数を使用します。 それにもかかわらず、規則セットはSourceとDest Type属性の両方のために以下のプッシュ値について議論しました。 これは確実に適切にそれをパケットの合っている作品に方向が逆にされている状態でします、SourceとDest Type値が異なっているのを許容する1メーターさえ。
3.1 Rule set to observe all flows
すべてを観測するように設定された3.1定規は流れます。
NeMaC reads rule sets from text files which contain the rules, the set number which the meter (and meter reader) will identify them by, and a 'format,' i.e. a list specifying which attributes the meter reader should collect and write to the flow data file. The # character indicates the start of a comment; NeMaC ignores the rest of the line.
NeMaCは規則を含むテキストファイル、セット番号、メーター(読者を計量する)がそれらを特定するおよび'形式'(すなわち、メーター読者が流れデータファイルにどの属性を集めて、書くべきであるかを指定するリスト)から規則セットを読みます。 #キャラクタはコメントの始まりを示します。 NeMaCは系列の残りを無視します。
SET 2
#
RULES
#
SourcePeerType & 255 = Dummy: Ignore, 0;
Null & 0 = 0: GotoAct, Next;
#
SourcePeerType & 255 = 0: PushPkttoAct, Next;
DestPeerType & 255 = 0: PushPkttoAct, Next;
SourcePeerAddress & 255.255.255.255 = 0: PushPkttoAct, Next;
DestPeerAddress & 255.255.255.255 = 0: PushPkttoAct, Next;
SourceTransType & 255 = 0: PushPkttoAct, Next;
DestTransType & 255 = 0: PushPkttoAct, Next;
SourceTransAddress & 255.255 = 0: PushPkttoAct, Next;
DestTransAddress & 255.255 = 0: CountPkt, 0;
#
FORMAT FlowRuleSet FlowIndex FirstTime " "
SourcePeerType SourcePeerAddress DestPeerAddress " "
SourceTransType SourceTransAddress DestTransAddress " "
ToPDUs FromPDUs " " ToOctets FromOctets;
2#規則#SourcePeerTypeと255=ダミーを設定してください: 無視、0。 ヌルと0 = 0: GotoAct、次。 # SourcePeerTypeと255 = 0: PushPkttoAct、次。 DestPeerTypeと255 = 0: PushPkttoAct、次。 SourcePeerAddressと255.255.255.255 = 0: PushPkttoAct、次。 DestPeerAddressと255.255.255.255 = 0: PushPkttoAct、次。 SourceTransTypeと255 = 0: PushPkttoAct、次。 DestTransTypeと255 = 0: PushPkttoAct、次。 SourceTransAddressと255.255 = 0: PushPkttoAct、次。 DestTransAddressと255.255 = 0: CountPkt、0。 # FlowRuleSet FlowIndex FirstTimeをフォーマットしてください、「「SourcePeerType SourcePeerAddress DestPeerAddress」「SourceTransType SourceTransAddress DestTransAddress」「ToPDUs FromPDUs」「ToOctets FromOctets」
Brownlee Informational [Page 17] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[17ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
The first rule tests the incoming packet's SourcePeerType to see whether it is 'dummy.' If it is, the packet is ignored, otherwise the next rule is executed.
それはそうです。. 'ダミー'はIfです。パケットは無視されます。最初の規則が見るために入って来るパケットのSourcePeerTypeをテストする、それ、さもなければ、次の規則は実行されます。
The second rule tests the Null attribute. Such a test always succeeds, so the rule simply jumps to the action of the next rule. (The keyword 'next' is converted by NeMaC into the number of the following rule.)
2番目の規則はNull属性をテストします。 そのようなテストがいつも成功するので、規則は単に次の規則の動作までジャンプします。 ('次'のキーワードはNeMaCによって以下の規則の数に変換されます。)
The third rule pushes the packet's SourcePeerType value, then jumps to the action of the next rule. The user does not know in advance what the value of PushPkt rules will be, which is why the value appearing in them is always zero. The user must take care not to write rule sets which try to perform the test in a PushPkt rule. This is a very common error in a rule set, so NeMaC tests for it and displays an error message.
3番目の規則は、パケットのSourcePeerType値を押して、次に、次の規則の動作までジャンプします。 ユーザは、あらかじめ、PushPkt規則の値が何になるかを知りません(いつもそれらに現れる値がゼロである理由です)。 ユーザは、PushPkt規則でテストを実行しようとする規則セットに書かないように注意しなければなりません。 これが規則セットで非常に一般的な誤りであるので、NeMaCはそれとディスプレイがないかどうかエラーメッセージをテストします。
The following rules push a series of attribute values from the packet, and the last rule also Counts the packet, i.e. it tells the Packet Matching Engine (PME) that the packet has been successfully matched. The PME responds by searching the flow table to see whether the flow is already current (i.e. in the table), creating a new flow data record for it should this be necessary, and incrementing its packet and byte counters.
以下は、パケットがPacket Matching Engine(PME)ですが、属性のシリーズがパケット、およびパケットであり、言うという最後の規則カウンツからも評価するプッシュが首尾よく合わせられていると裁決します。 PMEは流れが既によく見られるかどうか(すなわち、テーブルの)確認するためにフロー・テーブルを捜すことによって、応じます、これが必要であるならデータがそれのために記録して、パケットを増加して、バイトが対抗する新しい流れを引き起こして。
Overall this rule set simply classifies the packet (i.e. decides whether or not it is to be counted), then pushes all the Peer and Transport attribute values for it. It makes no attempt to specify a direction for the flow - this is left to the PME, as described in [1]. The resulting flow data file will have each flow's source and destination addresses in the order of the first packet the meter observed for the flow.
全体的に見て、単に設定されたこの規則は、パケットを分類して(すなわち、それが数えられることになっているかどうか決めます)、次に、それのためにすべてのPeerとTransport属性値を押します。 それは流れに方向を指定する試みを全くしません--これはPMEに残されます、[1]で説明されるように。 結果として起こる流れデータファイルには、各流れのソースがあるでしょう、そして、目的地は最初のパケットの注文で流れに関して観測されたメーターを扱います。
3.2 Specifying flow direction, using computed attributes
3.2 計算された属性を使用して、流れ方向を指定すること。
As indicated above, the Packet Matching Engine will reliably determine the flow, and the direction within that flow, for every packet seen by a meter. If the rule set does not specify a direction for the flow, the PME simply assumes that the first packet observed for a flow is travelling forward, i.e. from source to destination. In later analysis of the flow data, however, one is usually interested in traffic to or from a particular source.
上で示されるように、Packet Matching Engineはその流れの中で流れ、および方向を確かに決定するでしょう、1メーターによって見られたあらゆるパケットのために。 規則セットが流れに方向を指定しないなら、PMEは、流れに関して観察された最初のパケットが前方に移動していると単に仮定します、すなわち、ソースから目的地まで。 しかしながら、フロー・データの後の分析では、通常、1つはソース、または、特定のソースからトラフィックに興味を持っています。
One can achieve this in a simple manner by writing a rule set to specify the source for flows. All that is required is to have rules which succeed if the packet is travelling in the required direction, and which execute a 'Fail' action otherwise. This is demonstrated in the following two examples.
1つは流れにソースを指定するために規則セットに書くことによって、簡単な方法でこれを実現できます。 必要であるすべてはパケットが必要な方向に移動しているなら成功してそうでなければ'失敗してください'という動作を実行する規則を持つことです。 これは以下の2つの例に示されます。
Brownlee Informational [Page 18] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[18ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
(Note that early versions of NeMaC allowed 'Retry' as a synonym for 'Fail.' The current version also allows 'NoMatch,' which seems a better way to imply "fail, allowing PME to try a second match with directions reversed.")
NeMaCの早めのバージョンが'失敗してください'のための同義語として'再試行'を許容したことに注意してください。(また、最新版は「失敗してください、PMEが逆にされる方向との2番目のマッチを試すのを許容して」と含意するように、より良い方法で思える'NoMatch'を許容します。)
# Count IP packets from network 130.216.0.0
#
SourcePeerType & 255 = IP: Pushto, ip_pkt;
Null & 0 = 0: Ignore, 0;
#
ip_pkt:
SourcePeerAddress & 255.255.0.0 = 130.216.0.0: Goto c_pkt;
Null & 0 = 0: NoMatch, 0;
#
c_pkt:
SourcePeerAddress & 255.255.255.255 = 0: PushPkttoAct, Next;
DestPeerAddress & 255.255.255.255 = 0: CountPkt, 0;
# ネットワーク130.216.0.0#SourcePeerTypeと255=IPからIPパケットを数えてください: Pushto、ip_pkt。 ヌルと0 = 0: 無視、0。 # ip_pkt: SourcePeerAddressと255.255.0.0 = 130.216.0.0: ゴトーc_pkt。 ヌルと0 = 0: NoMatch、0。 # _c pkt: SourcePeerAddressと255.255.255.255 = 0: PushPkttoAct、次。 DestPeerAddressと255.255.255.255 = 0: CountPkt、0。
The rule labelled ip_pkt tests whether the packet came from network 130.216. If it did not, the test fails and the following rule executes a NoMatch action, causing the PME to retry the match with the directions reversed. If the second match fails the packet did not have 130.216 as an end-point, and is ignored.
パケットがネットワーク130.216から来たか否かに関係なく、規則はip_pktテストをラベルしました。 そうしなかったなら、テストは失敗します、そして、以下の規則はNoMatch動作を実行します、PMEが逆にされる方向とのマッチを再試行することを引き起こして。 2番目のマッチが失敗するなら、パケットは、エンドポイントとして130.216を持たないで、無視されます。
The next rule set meters IP traffic on a network segment which connects two routers, g1 and g2. It classifies flows into three groups - those travelling from g1 to g2, those whose source is g1 and those whose source is g2.
次の規則セットは2つのルータ、g1、およびg2を接続するネットワークセグメントでIPトラフィックを計量します。 それは流れを3つのグループに分類します--g1からg2(ソースがソースがg2であるg1とそれらであるそれら)まで旅行するもの。
Brownlee Informational [Page 19] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[19ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
# Count IP packets between two gateways
#
# -------+-------------------+------------------+-------
# | | |
# +----+-----+ +----+-----+ +---+---+
# | g1 | | g2 | | meter |
# +-+-+-+-+--+ +-+-+-+-+--+ +-------+
#
SourcePeerType & 255 = IP: Pushto, ip_pkt;
Null & 0 = 0: Ignore, 0;
#
ip_pkt:
SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-80-48-81-0E-7C:
Goto, s1;
Null & 0 = 0: Goto, s2;
s1:
DestAdjacentAddress & FF-FF-FF-FF-FF-FF = 02-07-01-04-ED-4A
GotoAct, g3;
Null & 0 = 0: GotoAct, g1;
s2:
SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 02-07-01-04-ED-4A:
Goto, s3;
Null & 0 = 0: NoMatch, 0;
s3:
DestAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-80-48-81-0E-7C:
NoMatch, 0;
Null & 0 = 0: GotoAct, g2;
#
g1: FlowClass & 255 = 1: PushtoAct, c_pkt; # From g1
g2: FlowClass & 255 = 2: PushtoAct, c_pkt; # From g2
g3: FlowClass & 255 = 3: PushtoAct, c_pkt; # g1 to g2
#
c_pkt:
SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 0:
PushPkttoAct, Next;
DestAdjacentAddress & FF-FF-FF-FF-FF-FF = 0: PushPkttoAct, Next;
SourcePeerAddress & 255.255.255.255 = 0: PushPkttoAct, Next;
DestPeerAddress & 255.255.255.255 = 0: PushPkttoAct, Next;
Null & 0 = 0: Count, 0
# 2門##の間のIPパケットを数えてください。-------+-------------------+------------------+------- # | | | # +----+-----+ +----+-----+ +---+---+ # | g1| | g2| | メーター| # +-+-+-+-+--+ +-+-+-+-+--+ +-------+ #SourcePeerTypeと255、はIPと等しいです: Pushto、ip_pkt。 ヌルと0 = 0: 無視、0。 # ip_pkt: SourceAdjacentAddressとff ff ff ff ff ffは00-80-48-81-0 E-7Cと等しいです: ゴトー、s1。 ヌルと0 = 0: ゴトー、s2。 s1: DestAdjacentAddress&FF-FF-FF-FF-FF-FFは02-07-01-04-ED-4A GotoAct、g3と等しいです。 ヌルと0 = 0: GotoAct、g1。 s2: SourceAdjacentAddressとff ff ff ff ff ffが等しい、02-07-01-04 教育4A: ゴトー、s3。 ヌルと0 = 0: NoMatch、0。 s3: DestAdjacentAddressとff ff ff ff ff ffは00-80-48-81-0 E-7Cと等しいです: NoMatch、0。 ヌルと0 = 0: GotoAct、g2。 # g1: FlowClassと255 = 1: PushtoAct、c_pkt。 # g1 g2から: FlowClassと255 = 2: PushtoAct、c_pkt。 # g2 g3から: FlowClassと255 = 3: PushtoAct、c_pkt。 # _g2#c pktへのg1: SourceAdjacentAddressとff ff ff ff ff ff=0: PushPkttoAct、次。 DestAdjacentAddressとff ff ff ff ff ff=0: PushPkttoAct、次。 SourcePeerAddressと255.255.255.255 = 0: PushPkttoAct、次。 DestPeerAddressと255.255.255.255 = 0: PushPkttoAct、次。 ヌルと0 = 0: カウント、0
The first two rules ignore non-IP packets. The next two rules Goto s1 if the packet's source was g1, or to s2 otherwise. The rule labelled s2 tests whether the packet's source was g2; if not a NoMatch action is executed, allowing the PME to try the match with the packet's direction reversed. If the match fails on the second try the packet didn't come from (or go to) g1 or g2, and is ignored.
最初の2つの規則が非IPパケットを無視します。 そうでなければ、パケットのソースであるなら、次の2つの規則ゴトーs1はg1であったかs2にそうです。 規則はパケットのソースがg2であったか否かに関係なく、s2テストをラベルしました。 そうでなければ、PMEが逆にされるパケットの指示との照合を試みるのを許容して、NoMatch動作は実行されます。 マッチが2番目でパケットが来なかったトライに失敗する、(許可する)、g1かg2、無視されます。
Brownlee Informational [Page 20] RFC 2123 Traffic Flow Measurement March 1997
1997年の[20ページ]RFC2123交通の流れ測定行進の情報のブラウンリー
Packets which come from g1 are tested by the rule labelled s1, and the PME will Goto either g3 or g1.
g1から来るパケットはs1とラベルされた規則でテストされます、そして、PMEはゴトーのg3かg1のどちらかをテストされるでしょう。
Packets which came from g2 are tested by the rule labelled s3. If they are not going to g1 the PME will Goto g2. If they are going to g1 a NoMatch action is executed - we want them counted as backward- travelling packets for the g1-g2 flow.
g2から来たパケットはs3とラベルされた規則でテストされます。 彼らがg1に行く予定でないと、PMEはゴトーg2がそうするでしょう。 彼らがg1に行く予定であるなら、NoMatch動作は実行されます--私たちは、g1-g2流動のために後方の旅行のパケットにそれらをみなして欲しいと思います。
The rules at g1, g2 and g3 push the value 1, 2 or 3 from their rule into the flow's FlowClass attribute. This value can be used by an Analysis Application to separate the flows into the three groups of interest. FlowClass is an example of a 'computed' attribute, i.e. one whose value is Pushed by the PME during rule matching.
g1、g2、およびg3の規則はそれらの規則から流れのFlowClass属性に値1、2または3を押します。 Analysis Applicationは、興味深い3つのグループへの流れを切り離すのにこの値を使用できます。 FlowClassは'計算された'属性に関する例、すなわち、値が規則マッチングの間のPMEによるPushedであるものです。
The remaining rules Push the values of other attributes required for later analysis, then Count the flow.
他の属性の値が後の分析、当時のCountのために流れを必要としたという残っている規則Push。
3.3 Subroutines
3.3 サブルーチン
Subroutines are implemented in the PME in much the same way as in BASIC. A subroutine body is just a sequence of statements, supported by the GoSub and Return actions. 'GoSub' saves the PME's running environment and jumps to the first rule of the subroutine body. Subroutine calls may be nested as required - NeTraMet defines the maximum nesting at compile time. 'Return n' restores the environment and jumps to the action part of the nth rule after the Gosub, where n is the index value from the Return rule.
サブルーチンは大体同じようなやり方でBASICのようにPMEで実行されます。 サブルーチン本体はただGoSubによってサポートされた声明とReturn動作の系列です。 'GoSub'は、PMEの走行環境を節約して、サブルーチン本体の最初の規則までジャンプします。 サブルーチン呼出しは必要に応じて入れ子にされるかもしれません--NeTraMetはコンパイル時に最大の巣篭もりを定義します。 'リターンn'はGosubの後にn番目の規則の動作部分に環境とジャンプを復元します。そこでは、nがReturn規則からのインデックス値です。
The Return action provides a way of influencing the flow of control in a rule set, rather like a FORTRAN Computed Goto. This is one way in which a subroutine can return a result. The other way is by Pushing a value in either a computed attribute (as demonstrated in the preceding section), or in a flow attribute.
Return動作は規則セットのコントロールの流れに影響を及ぼす方法を提供します、FORTRAN Computedゴトーのように。 これはサブルーチンが結果を返すことができる1つの方法です。 Pushingで、もう片方の道は計算された属性(先行するセクションで示されるように)、または流れ属性において値です。
One common use for a subroutine is to test whether a packet attribute matches one of a set of values. Such a subroutine becomes much more useful if it can be used to test one of several attributes. The PME architecture provides for this by using 'meter variables' to hold the names of the attributes to be tested. The meter variables are called V1, V2, V3, V4 and V5, and the Assign action is provided to set their values. If, for example, we need a subroutine to test either SourcePeerAddress or DestPeerAddress, we write its rules to test V1 instead. Before calling the subroutine we Assign SourcePeerAddress to V1; later tests of V1 are converted by the PME into tests on SourcePeerAddress. Note that since meter variables may be reassigned in a subroutine, their values are part of the environment which must be saved by a Gosub action.
パケット属性が1セットの値の1つに合っているか否かに関係なく、サブルーチンの一般の使用がテストすることになっているもの。 いくつかの属性の1つをテストするのにそれを使用できるなら、そのようなサブルーチンははるかに役に立つようになります。 テストされるために属性の名前を保持するのに'メーター変数'を使用することによって、PME構造はこれに備えます。 メーター変数をV1、V2、V3、V4、およびV5と呼びます、そして、それらの値を設定するためにAssign動作を前提とします。 例えば、SourcePeerAddressかDestPeerAddressのどちらかをテストするためにサブルーチンを必要とするなら、私たちは、代わりにV1をテストするために規則を書きます。 サブルーチンをV1に私たちAssign SourcePeerAddressと呼ぶ前に。 V1の後のテストはPMEによってSourcePeerAddressのテストに変換されます。 メーター変数がサブルーチンで再選任されるかもしれないのでそれらの値がGosub動作で節約しなければならない環境の一部であることに注意してください。
Brownlee Informational [Page 21] RFC 2123 Traffic Flow Measurement March 1997
1997年の[21ページ]RFC2123交通の流れ測定行進の情報のブラウンリー
The following rule set demonstrates the use of a subroutine ..
以下の規則セットはサブルーチンの使用を示します。
# Rule specification file to tally IP packets in three groups:
# UA to AIT, UA to elsewhere, AIT to elsewhere
#
# -------+-------------------+-----------------+--------
# | | |
# +----+-----+ +----+-----+ +---+---+
# | UA | | AIT | | meter |
# +-+-+-+-+--+ +-+-+-+-+--+ +-------+
#
SourcePeerType & 255 = IP: PushtoAct, ip_pkt;
Null & 0 = 0: Ignore, 0;
#
ip_pkt:
v1 & 0 = SourcePeerAddress: AssignAct, Next;
Null & 0 = 0: Gosub, classify;
Null & 0 = 0: GotoAct, from_ua; # 1 ua
Null & 0 = 0: GotoAct, from_ait; # 2 ait
Null & 0 = 0: NoMatch, 0; # 3 other
#
from_ua:
v1 & 0 = DestPeerAddress: AssignAct, Next;
Null & 0 = 0: Gosub, classify;
Null & 0 = 0: Ignore, 0; # 1 ua-ua
Null & 0 = 0: GotoAct, ok_pkt; # 2 ua-ait
Null & 0 = 0: Gotoact, ok_pkt; # 3 ua-other
#
from_ait:
v1 & 0 = DestPeerAddress: AssignAct, Next;
Null & 0 = 0: Gosub, classify;
Null & 0 = 0: NoMatch, 0; # 1 ait-ua
Null & 0 = 0: Ignore, 0; # 2 ait-ait
Null & 0 = 0: GotoAct, ok_pkt; # 3 ait-other
#
ok_pkt:
Null & 0 = 0: Count, 0;
# 仕様ファイルを統治して、3つのグループでIPパケットを記録してください: # AITへのUA、ほかの場所へのUA、ほかの場所へのAIT、##-------+-------------------+-----------------+-------- # | | | # +----+-----+ +----+-----+ +---+---+ # | Ua| | オート麦| | メーター| # +-+-+-+-+--+ +-+-+-+-+--+ +-------+ #SourcePeerTypeと255、はIPと等しいです: PushtoAct、ip_pkt。 ヌルと0 = 0: 無視、0。 # ip_pkt: v1と0はSourcePeerAddressと等しいです: AssignAct、次。 ヌルと0 = 0: Gosub、分類します。 ヌルと0 = 0: _uaからのGotoAct、。 # 1 ua Nullと0 = 0: _オート麦からのGotoAct、。 # 2 オート麦Nullと0 = 0: NoMatch、0。 # _uaからの他の3#: v1と0はDestPeerAddressと等しいです: AssignAct、次。 ヌルと0 = 0: Gosub、分類します。 ヌルと0 = 0: 無視、0。 # 1 ua-ua Nullと0 = 0: GotoAct、OK_pkt。 # 2 ua-オート麦Nullと0 = 0: Gotoact、OK_pkt。 # _オート麦からのua他の3#: v1と0はDestPeerAddressと等しいです: AssignAct、次。 ヌルと0 = 0: Gosub、分類します。 ヌルと0 = 0: NoMatch、0。 # 1 オート麦-ua Nullと0 = 0: 無視、0。 # 2 オート麦オート麦Nullと0 = 0: GotoAct、OK_pkt。 # 3 オート麦他の#OK_pkt: ヌルと0 = 0: カウント、0。
The subroutine begins at the rule labelled classify (shown below). It returns to the first, second or third rule after the invoking Gosub rule, depending on whether the tested PeerAddress is in the UA, AIT, or 'other' group of networks. In the listing below only one network is tested in each of the groups - it is trivial to add more rules (one per network) into either of the first two groups. In this example the subroutine Pushes the network number from the packet into the tested attribute before returning.
ラベルされて、サブルーチンは規則に基づき始まります。分類します(以下では、目立ちます)。 それは1日に戻ります、Gosubが統治する呼び出しの後の2番目か3番目の規則、UA、AIT、またはネットワークの'他'のグループにはテストされたPeerAddressがあるかによって。 以下のリストでは、1つのネットワークだけがそれぞれのグループでテストされます--より多くの規則(1ネットワークあたり1つ)を最初の2つのグループのどちらかに加えるのは些細です。 この例のテストへのパケットからのネットワーク・ナンバーが戻る前に結果と考えるサブルーチンPushes。
Brownlee Informational [Page 22] RFC 2123 Traffic Flow Measurement March 1997
1997年の[22ページ]RFC2123交通の流れ測定行進の情報のブラウンリー
The first invocation of classify (above) begins at the rule labelled ip_pkt. It Assigns SourcePeerAddress to V1 then executes a Gosub action. Classify returns to one of the three following rules. They will Goto from_ua or from_ait if the packet came from the UA or AIT groups, otherwise the PME will retry the match. This means that matched flows will have a UA or AIT network as their source, and flows between other networks will be ignored.
(above)を分類してください。最初の実施、ip_pktとラベルされた規則では、始まります。 それ、そして、V1へのAssigns SourcePeerAddressはGosub動作を実行します。 3つの次の規則の1つへのリターンを分類してください。 パケットがUAかAITグループから来たなら、彼らは_uaか_オート麦からゴトーを望んでいます。さもなければ、PMEはマッチを再試行するでしょう。 これは、取り組んでいる流れには彼らのソースとしてUAかAITネットワークがあることを意味します、そして、他のネットワークの間の流れは無視されるでしょう。
The next two invocations of 'classify' test the packet's DestPeerAddress. Packets from AIT to UA are Retried, forcing them to be counted as AU to AIT flows. Packets from UA to UA are ignored, as are packets from AIT to AIT.
'分類'の次の2つの実施がパケットのDestPeerAddressをテストします。 AITへのAUが流れるのに従ってそれらが数えさせられて、AITからUAまでのパケットはRetriedです。 UAからUAまでのパケットはパケットのようにAITからAITまで無視されます。
classify:
v1 & 255.255.0.0 = 130.216.0.0: GotoAct, ua; # ua
v1 & 255.255.0.0 = 156.62.0.0: GotoAct, ait; # ait
Null & 0 = 0: Return, 3; # other
ua:
v1 & 255.255.0.0 = 0: PushPkttoAct, Next;
Null & 0 = 0: Return, 1;
ait:
v1 & 255.255.0.0 = 0: PushPkttoAct, Next;
Null & 0 = 0: Return, 2;
分類します: v1と255.255.0.0 = 130.216.0.0: GotoAct、ua。 # ua v1と255.255.0.0 = 156.62.0.0: GotoAct、オート麦。 # オート麦Nullと0 = 0: リターン、3。 # 他のua: v1と255.255.0.0 = 0: PushPkttoAct、次。 ヌルと0 = 0: リターン、1。 オート麦: v1と255.255.0.0 = 0: PushPkttoAct、次。 ヌルと0 = 0: リターン、2。
3.4 More complicated rule sets
3.4 より複雑な規則セット
The next example demonstrates a way of grouping IP flows together depending on their Transport Address, i.e. their IP port number. Simply Pushing every flow's SourceTransAddress and DestTransAddress would produce a large number of flows, most of which differ only in one of their transport addresses (the one which is not a well-known port).
次の例はIP流れを分類するのがそれらのTransport Address(すなわち、彼らのIPポートナンバー)による方法を示します。 単にPushing、あらゆる流れのSourceTransAddressとDestTransAddressは多くの流れを発生させるでしょう。その大部分はそれらの輸送アドレス(ウェルノウンポートでないもの)の1つだけにおいて異なります。
Instead we Push the well-known port number into each flow's SourceTransAddress; its DestTransAddress will be zero by default.
代わりに私たち、Push、各流れのSourceTransAddressへのウェルノウン・ポート番号。 DestTransAddressはデフォルトでゼロになるでしょう。
SourcePeerType & 255 = dummy: Ignore, 0;
SourcePeerType & 255 = IP: Pushto, IP_pkt;
Null & 0 = 0: GotoAct, Next;
SourcePeerType & 255 = 0: PushPkttoAct, Next;
Null & 0 = 0: Count, 0; # Count others by protocol type
#
IP_pkt:
SourceTransType & 255 = tcp: Pushto, tcp_udp;
SourceTransType & 255 = udp: Pushto, tcp_udp;
SourceTransType & 255 = icmp: CountPkt, 0;
SourceTransType & 255 = ospf: CountPkt, 0;
Null & 0 = 0: GotoAct, c_unknown; # Unknown transport type
SourcePeerTypeと255はダミーと等しいです: 無視、0。 SourcePeerTypeと255はIPと等しいです: Pushto、IP_pkt。 ヌルと0 = 0: GotoAct、次。 SourcePeerTypeと255 = 0: PushPkttoAct、次。 ヌルと0 = 0: カウント、0。 # プロトコルタイプ#IP_pktは他のものを数えてください: SourceTransTypeと255はtcpと等しいです: Pushto、tcp_udp。 SourceTransTypeと255はudpと等しいです: Pushto、tcp_udp。 SourceTransTypeと255はicmpと等しいです: CountPkt、0。 SourceTransTypeと255はospfと等しいです: CountPkt、0。 ヌルと0 = 0: GotoAct、c_未知。 # 未知の輸送タイプ
Brownlee Informational [Page 23] RFC 2123 Traffic Flow Measurement March 1997
1997年の[23ページ]RFC2123交通の流れ測定行進の情報のブラウンリー
#
tcp_udp:
s_domain:
SourceTransAddress & 255.255 = domain: PushtoAct, c_well_known;
s_ftp:
SourceTransAddress & 255.255 = ftp: PushtoAct, c_well_known;
s_imap:
SourceTransAddress & 255.255 = 113: PushtoAct, c_well_known;
s_nfs
SourceTransAddress & 255.255 = 2049: PushtoAct, c_well_known;
s_pop:
SourceTransAddress & 255.255 = 110: PushtoAct, c_well_known;
s_smtp:
SourceTransAddress & 255.255 = smtp: PushtoAct, c_well_known;
s_telnet:
SourceTransAddress & 255.255 = telnet: PushtoAct, c_well_known;
s_www:
SourceTransAddress & 255.255 = www: PushtoAct, c_well_known;
s_xwin
SourceTransAddress & 255.255 = 6000: PushtoAct, c_well_known;
#
DestTransAddress & 255.255 = domain: GotoAct, s_domain;
DestTransAddress & 255.255 = ftp: GotoAct, s_ftp;
DestTransAddress & 255.255 = 113: GotoAct, s_imap;
DestTransAddress & 255.255 = 2049: GotoAct, s_nfs;
DestTransAddress & 255.255 = 110: GotoAct, s_pop;
DestTransAddress & 255.255 = smtp: GotoAct, s_smtp;
DestTransAddress & 255.255 = telnet: GotoAct, s_telnet;
DestTransAddress & 255.255 = www: GotoAct, s_www;
DestTransAddress & 255.255 = 6000: GotoAct, s_xwin;
#
Null & 0 = 0: GotoAct, c_unknown; # 'Unusual' port
#
c_unknown:
SourceTransType & 255 = 0: PushPkttoAct, Next;
DestTransType & 255 = 0: PushPkttoAct, Next;
SourceTransAddress & 255.255 = 0: PushPkttoAct, Next;
DestTransAddress & 255.255 = 0: CountPkt, 0;
#
c_well_known:
Null & 0 = 0: Count, 0
#
# tcp_udp: s_ドメイン: SourceTransAddressと255.255はドメインと等しいです: PushtoAct、知られているc_井戸_。 _s ftp: SourceTransAddressと255.255はftpと等しいです: PushtoAct、知られているc_井戸_。 _s imap: SourceTransAddressと255.255 = 113: PushtoAct、知られているc_井戸_。 s_nfs SourceTransAddressと255.255 = 2049: PushtoAct、知られているc_井戸_。 s_ポップス: SourceTransAddressと255.255 = 110: PushtoAct、知られているc_井戸_。 _s smtp: SourceTransAddressと255.255はsmtpと等しいです: PushtoAct、知られているc_井戸_。 s_telnet: SourceTransAddressと255.255はtelnetと等しいです: PushtoAct、知られているc_井戸_。 _s www: SourceTransAddressと255.255はwwwと等しいです: PushtoAct、知られているc_井戸_。 s_xwin SourceTransAddressと255.255 = 6000: PushtoAct、知られているc_井戸_。 # DestTransAddressと255.255はドメインと等しいです: GotoAct、s_ドメイン。 DestTransAddressと255.255はftpと等しいです: GotoAct、s_ftp。 DestTransAddressと255.255 = 113: GotoAct、s_imap。 DestTransAddressと255.255 = 2049: GotoAct、s_nfs。 DestTransAddressと255.255 = 110: GotoAct、s_は飛び出します。 DestTransAddressと255.255はsmtpと等しいです: GotoAct、s_smtp。 DestTransAddressと255.255はtelnetと等しいです: GotoAct、s_telnet。 DestTransAddressと255.255はwwwと等しいです: GotoAct、s_www。 DestTransAddressと255.255 = 6000: GotoAct、s_xwin。 # ヌルと0 = 0: GotoAct、c_未知。 # 未知の'珍しい'ポート#c_: SourceTransTypeと255 = 0: PushPkttoAct、次。 DestTransTypeと255 = 0: PushPkttoAct、次。 SourceTransAddressと255.255 = 0: PushPkttoAct、次。 DestTransAddressと255.255 = 0: CountPkt、0。 # 知られているc_井戸_: ヌルと0 = 0: カウント、0#
The first few rules ignore dummy packets, select IP packets for further processing, and count packets for other protocols in a single flow for each PeerType. TCP and UDP packets cause the PME to Push their TransType and Goto tcp_udp. ICMP and OSPF packets are counted in flows which have only their TransType Pushed.
わずかな最初の規則が、ダミーのパケットを無視して、さらなる処理のためにIPパケットを選択して、他のプロトコルのために各PeerTypeに、ただ一つの流れでパケットを数えます。 TCPとUDPパケットはPushへのそれらのTransTypeとゴトーtcp_udpをPMEに引き起こします。 ICMPとOSPFパケットはそれらのTransType Pushedしか持っていない流れで数えられます。
Brownlee Informational [Page 24] RFC 2123 Traffic Flow Measurement March 1997
1997年の[24ページ]RFC2123交通の流れ測定行進の情報のブラウンリー
At tcp_udp the packets' SourceTransAddress is tested to see whether it is included in a set of 'interesting' port numbers. If it is, the port number is pushed from the rule into the SourceTransAddress attribute, and the packet is counted at c_well_known. (NeMaC accepts Pushto as a synonym for PushRuleto).
tcp_udpでは、パケットのSourceTransAddressは、それが'おもしろい'ポートナンバーのセットに含まれているかどうか確認するためにテストされます。 それがそうなら、ポートナンバーは規則からSourceTransAddress属性に押されます、そして、パケットは知られているc_井戸_で数えられます。 (NeMaCはPushRuletoのための同義語としてPushtoを認めます。)
This testing is repeated for the packet's DestTransAddress; if one of these tests succeeds the PME Goes to the corresponding rule above and Pushes the port number into the flow's SourceTransAddress. If these tests fail the packet is counted at c_unknown, where all the flow's Trans attributes are pushed. For production use more well-known ports would need to be included in the tests above - c_unknown is intended only for little-used exception flows!
このテストはパケットのDestTransAddressのために繰り返されます。 これらのテストの1つがPMEゴエスのために上の対応する規則とPushesへのポートナンバーを流れのSourceTransAddressに引き継ぐなら。 これらのテストが失敗するなら、流れのTransが結果と考えるすべてが押されるところでパケットはc_未知で数えられます。 より多くのウェルノウンポートがテストに含まれるように必要とする生産使用において、上では、c_未知が少ししか使用されなかった例外流れのためだけに意図します!
Note that these rules only Push a value into a flow's SourceTransAddress, and they don't contain any NoMatch actions. They therefore don't specify a packet's direction, and they could be used in other rule sets to group together flows for well-known ports.
これらがPush a価値だけを流れのSourceTransAddressに統治することに注意してください。そうすれば、彼らは少しのNoMatch動作も含みません。 したがって、彼らはパケットの指示を指定しません、そして、ウェルノウンポートのために流れを一緒に分類するのに他の規則セットにそれらは使用できました。
The last example (below) meters flows from a remote router, and demonstrates another approach to grouping well-known ports.
最後の例の(below)メーターは、リモートルータから流れて、ウェルノウンポートを分類することへの別のアプローチを示します。
SourceAdjacentAddress & FF-FF-FF-FF-FF-FF =
00-60-3E-10-E0-A1: Goto, gateway; # tmkr2 router
DestAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-60-3E-10-E0-A1:
Goto, gateway; # Source is tmkr2
Null & 0 = 0: Ignore, 0;
#
gateway:
SourcePeerType & 255 = IP: GotoAct, IP_pkt;
Null & 0 = 0: GotoAct, Next;
SourcePeerType & 255 = 0: CountPkt, 0;
#
IP_pkt:
SourceTransType & 255 = tcp: PushRuleto, tcp_udp;
SourceTransType & 255 = udp: PushRuleto, tcp_udp;
Null & 0 = 0: GotoAct, not_wkp; # Unknown transport type
#
tcp_udp:
SourceTransAddress & FC-00 = 0: GotoAct, well_known_port;
DestTransAddress & FC-00 = 0: NoMatch, 0;
Null & 0 = 0: GotoAct, not_wkp;
#
not_wkp:
DestTransAddress & 255.255 = 0: PushPkttoAct, Next;
well_known_port:
SourcePeerType & 255 = 0: PushPkttoAct, Next;
DestPeerType & 255 = 0: PushPkttoAct, Next;
SourceAdjacentAddressとff ff ff ff ff ffは00-60-3E-10-E0-A1と等しいです: ゴトー、ゲートウェイ。 # tmkr2ルータDestAdjacentAddressとFF-FF-FF-FF-FF-FFは00-60-3 E-10Eの0-A1と等しいです: ゴトー、ゲートウェイ。 # ソースは、tmkr2 Nullと0 = 0です: 無視、0。 # ゲートウェイ: SourcePeerTypeと255はIPと等しいです: GotoAct、IP_pkt。 ヌルと0 = 0: GotoAct、次。 SourcePeerTypeと255 = 0: CountPkt、0。 # _IP pkt: SourceTransTypeと255はtcpと等しいです: PushRuleto、tcp_udp。 SourceTransTypeと255はudpと等しいです: PushRuleto、tcp_udp。 ヌルと0 = 0: _wkpではなく、GotoAct。 # 未知の輸送タイプ#tcp_udp: SourceTransAddress&FC-00=0: GotoAct、井戸の_の知られている_港。 DestTransAddress&FC-00=0: NoMatch、0。 ヌルと0 = 0: _wkpではなく、GotoAct。 # _wkpでない: DestTransAddressと255.255 = 0: PushPkttoAct、次。 井戸の_の知られている_港: SourcePeerTypeと255 = 0: PushPkttoAct、次。 DestPeerTypeと255 = 0: PushPkttoAct、次。
Brownlee Informational [Page 25] RFC 2123 Traffic Flow Measurement March 1997
1997年の[25ページ]RFC2123交通の流れ測定行進の情報のブラウンリー
SourcePeerAddress & 255.255.255.0 = 0: PushPkttoAct, Next;
DestPeerAddress & 255.255.255.0 = 0: PushPkttoAct, Next;
SourceTransType & 255 = 0: PushPkttoAct, Next;
DestTransType & 255 = 0: PushPkttoAct, Next;
SourceTransAddress & 255.255 = 0: CountPkt, 0;
SourcePeerAddressと255.255.255.0 = 0: PushPkttoAct、次。 DestPeerAddressと255.255.255.0 = 0: PushPkttoAct、次。 SourceTransTypeと255 = 0: PushPkttoAct、次。 DestTransTypeと255 = 0: PushPkttoAct、次。 SourceTransAddressと255.255 = 0: CountPkt、0。
The first group of rules test incoming packet's AdjacentAddresses to see whether they belong to a flow with an end point at the specified router. Any which don't are ignored. Non-IP packets are counted in flows which only have their PeerType Pushed; these will produce one flow for each non-IP protocol. IP packets with TransTypes other than UDP and TCP are counted at not_wkp, where all their address attributes are pushed.
規則の最初のグループは、彼らが指定されたルータにおけるエンドポイントがある流れに属すかどうか確認するために入って来るパケットのAdjacentAddressesをテストします。 いくらか、どれが無視しないかは無視されます。 非IPパケットはそれらのPeerType Pushedを持っているだけである流れで数えられます。 これらはそれぞれの非IPプロトコルあたり1回の流れを発生させるでしょう。 UDPとTCP以外のTransTypesがあるIPパケットは_どんなwkpでも数えられません。そこでは、彼らのすべてのアドレス属性が押されます。
The high-order six bits of SourceTransAddress for UDP and TCP packets are compared with zero. If this succeeds their source port number is less than 1024, so they are from a well-known port. The port number is pushed from the rule into the flow's SourceTransAddress attribute, and the packet is counted at well_known_port. If the test fails, it is repeated on the packet's DestTransAddress. If the destination is a well-known port the match is Retried, and will succeed with the well-known port as the flow's source.
UDPのためのSourceTransAddressとTCPパケットの高位6ビットはゼロにたとえられます。 これが成功するならそれらのソースポートナンバーが1024未満であるので、彼らはウェルノウンポートから来ています。 ポートナンバーは規則から流れのSourceTransAddress属性に押されます、そして、パケットは井戸の_の知られている_港で数えられます。 テストが失敗するなら、それはパケットのDestTransAddressで繰り返されます。 目的地がウェルノウンポートであるなら、マッチは、Retriedであり、流れのソースとしてウェルノウンポートで成功するでしょう。
If later analysis were to show that a high proportion of the observed flows were from non-well-known ports, further pairs of rules could be added to perform a test in each direction for other heavily-used ports.
観測された流れの高い割合が非ウェルノウンポートから来ていたショーに後の分析があるなら、他のずっしりと使用されたポートのための各方向にテストを実行するためにさらなる組の規則を加えることができるでしょうに。
4 Flow data files
4 流れデータファイル
Although the Architecture document [1] specifies - in great detail - how the Traffic Flow Meter works, and how a meter reader should collect flow data from a meter, it does not say anything about how the collected data should be stored. NeMaC uses a simple, self- documenting file format, which has proved to be very effective in use.
Architectureドキュメント[1]は、Traffic Flow Meterがどのように働くか、そして、メーター読者が1メーターからフロー・データをどのように集めるべきであるかを丹念に指定しますが、集まっているデータがどう格納されるべきであるかに関してそれは何も示しません。 NeMaCは簡単な自己ドキュメントファイル形式を使用します。(それは、使用中に非常に効果的であると判明しました)。
There are two kinds of records in a flow data file: flow records and information records. Each flow record is simply a sequence of attribute values with separators (these can be specified in a NeMaC rule file) or spaces between them, terminated by a newline.
流れデータファイルには2種類の記録があります: 流れ記録と情報記録。 それぞれの流れ記録は単に分離符(NeMaC規則ファイルでこれらを指定できる)がある属性値かそれらの間のニューラインによって終えられた空間の系列です。
Information records all start with a cross-hatch. The file's first record begins with ##, and identifies the file as being a file of data from NeTraMet. It records NeMaC's parameters and the time this collection was started. The file's second record begins with #Format: and is a copy of the Format statement used by NeMaC to collect the data.
情報記録はすべて、網状線から始まります。 ファイルの最初の記録は、NeTraMetからのデータのファイルであるとして##で始まって、ファイルを特定します。 それはこの収集が始められたNeMaCのパラメタと時を記録します。 ファイルの2番目の記録は#Formatと共に始まります: そして、Format声明のコピーは、データを集めるのにNeMaCによって使用されますか?
Brownlee Informational [Page 26] RFC 2123 Traffic Flow Measurement March 1997
1997年の[26ページ]RFC2123交通の流れ測定行進の情報のブラウンリー
The rest of the file is a sequence of collected data sets. Each of these starts with a #Time: record, giving the time-of-day the collection was started, the meter name, and the range of meter times this collection represents. These from and to times are meter UpTimes, i.e. they are times in hundredths of seconds since the meter commenced operation. Most analysis applications have simply used the collection start times (which are ASCII time-of-day values), but the from and to times could be used to convert Uptime values to time-of- day. The flow records which comprise a data set follow the #Time record.
ファイルの残りは集まっているデータセットの系列です。 それぞれのこれらは#Timeから始まります: 収集に口もきくのは、この収集が表す記録してください、そして、始められてメーター名と、メーター回の範囲でした。 回と回へのこれらがメーターUpTimesである、すなわち、メーターが操業を開始したので、彼らは秒の100分の1で回です。 しかし、ほとんどの分析アプリケーションが単に、収集スタート回数(ASCII時刻値である)を使用した、時間までUptime値を変換するのに回と回まで使用できた、-、日について。 データセットを包括する流れ記録は#Time記録に従います。
4.1 Sample flow data file
4.1 サンプルフロー・データはファイルされます。
A sample flow data file appears below. Most of the flow records have been deleted, but lines of dots show where they were.
サンプル流れデータファイルは以下に現れます。 流れ記録の大部分は削除されましたが、ドットの線は、それらがどこにあったかを示します。
##NeTraMet v3.2. -c300 -r rules.lan -e rules.default
test_meter -i eth0 4000 flows starting at 12:31:27 Wed 1 Feb 95
#Format: flowruleset flowindex firsttime sourcepeertype
sourcepeeraddress destpeeraddress topdus frompdus
tooctets fromoctets
#Time: 12:31:27 Wed 1 Feb 95 130.216.14.251 Flows
from 1 to 3642
1 2 13 5 31.32.0.0 33.34.0.0 1138 0 121824 0
1 3 13 2 11.12.0.0 13.14.0.0 4215 0 689711 0
1 4 13 7 41.42.0.0 43.34.0.0 1432 0 411712 0
1 5 13 6 21.22.0.0 23.24.0.0 8243 0 4338744 0
3 6 3560 2 130.216.14.0 130.216.3.0 0 10 0 1053
3 7 3560 2 130.216.14.0 130.216.76.0 59 65 4286 3796
3 8 3560 7 0.0.255.0 1.144.200.0 0 4 0 222
3 9 3560 2 130.216.14.0 130.216.14.0 118 1 32060 60
3 10 3560 6 130.216.0.28 130.216.0.192 782 1 344620 66
3 11 3560 7 0.0.255.0 0.128.113.0 0 1 0 73
3 12 3560 5 59.3.13.0 4.1.152.0 1 1 60 60
3 13 3560 7 0.128.94.0 0.129.27.0 2 2 120 158
3 14 3560 5 59.3.40.0 4.1.153.0 2 2 120 120
3 15 3560 5 0.0.0.0 4.1.153.0 0 1 0 60
3 16 3560 5 4.1.152.0 59.2.189.0 2 2 120 120
. . . . . . . . .
3 42 3560 7 0.128.42.0 0.129.34.0 0 1 0 60
3 43 3560 7 0.128.42.0 0.128.43.0 0 1 0 60
3 44 3560 7 0.128.42.0 0.128.41.0 0 1 0 60
3 45 3560 7 0.128.42.0 0.129.2.0 0 1 0 60
3 46 3560 5 4.1.152.0 59.2.208.0 2 2 120 120
3 47 3560 5 59.3.46.0 4.1.150.0 2 2 120 120
3 48 3560 5 4.1.152.0 59.2.198.0 2 2 120 120
3 49 3560 5 0.0.0.0 59.2.120.0 0 1 0 60
3 50 3664 5 4.1.152.0 59.2.214.0 0 1 0 60
##NeTraMet v3.2。 -12:31:27 2月1日水曜日95#Formatで始まって、c300-r rules.lan-e rules.defaultテスト_メーター-i eth0 4000は流れます: flowruleset flowindex firsttime sourcepeertype sourcepeeraddress destpeeraddress topdus frompdus tooctets fromoctets#Time: 12:31: 27 1〜3642 1 2 13 5 31.32.0.0 33.34.0.0 1138 0 121824 0 1 3 13 2 11.12.0.0 13.14.0.0 4215 0 689711 0 1 4 13 7 41.42.0.0 43.34.0.0 1432 0 411712 0 1 5 13 6 21.22.0.0 23.24.0.0 8243 0 4338744からの95 130.216回の2月1日水曜日の.14.251流れ、0 3 6、3560 2 130.216; 14.0 130.216.3.0 0 10 0 1053 3 7 3560 2 130.216.14.0 130.216.76.0 59 65 4286 3796 3 8 3560 7 0.0.255.0 1.144.200.0 0 4 0 222 3 9 3560 2 130.216.14.0 130.216.14.0 118 1 32060 60 3 10 3560 6 130.216.0.28 130.216.0.192 782 1 344620 66 3 11 3560 7 0.0.255.0 0; 128.113.0 0 1 0 73 3 12 3560 5 59.3.13.0 4.1.152.0 1 1 60 60 3 13 3560 7 0.128.94.0 0.129.27.0 2 2 120 158 3 14 3560 5 59.3.40.0 4.1.153.0 2 2 120 120 3 15 3560 5 0.0.0.0 4.1.153.0 0 1 0 60 3 16 3560 5 4.1.152.0 59.2.189.0 2 2 120 120 . . . . . . . . . 3 42 3560 7 0.128.42.0 0.129.34.0 0 1 0 60 3 43 3560 7 0.128.42.0 0.128.43.0 0 1 0 60 3 44 3560 7 0.128.42.0 0.128.41.0 0 1 0 60 3 45 3560 7 0.128.42.0 0.129.2.0 0 1 0 60 3 46 3560 5 4.1.152.0 59.2.208.0 2 2 120 120 3 47 3560 5 59.3.46.0 4.1.150.0 2 2 120 120 3 48 3560 5 4.1.152.0 59.2.198.0 2 2 120 120 3 49 3560 5 0.0.0.0 59.2.120.0 0 1 0 60 3 50 3664 5 4.1.152.0 59.2.214.0 0 1 0 60
Brownlee Informational [Page 27] RFC 2123 Traffic Flow Measurement March 1997
1997年の[27ページ]RFC2123交通の流れ測定行進の情報のブラウンリー
3 51 3664 5 0.0.0.0 4.2.142.0 0 1 0 60
3 52 3664 5 4.1.153.0 59.3.45.0 4 4 240 240
#Time: 12:36:25 Wed 1 Feb 95 130.216.14.251 Flows
from 3641 to 33420
3 6 3560 2 130.216.14.0 130.216.3.0 0 21 0 2378
3 7 3560 2 130.216.14.0 130.216.76.0 9586 7148 1111118 565274
3 8 3560 7 0.0.255.0 1.144.200.0 0 26 0 1983
3 9 3560 2 130.216.14.0 130.216.14.0 10596 1 2792846 60
3 10 3560 6 130.216.0.28 130.216.0.192 16589 1 7878902 66
3 11 3560 7 0.0.255.0 0.128.113.0 0 87 0 16848
3 12 3560 5 59.3.13.0 4.1.152.0 20 20 1200 1200
3 13 3560 7 0.128.94.0 0.129.27.0 15 14 900 1144
3 14 3560 5 59.3.40.0 4.1.153.0 38 38 2280 2280
3 15 3560 5 0.0.0.0 4.1.153.0 0 30 0 1800
3 16 3560 5 4.1.152.0 59.2.189.0 20 20 1200 1200
3 17 3560 5 0.0.0.0 59.2.141.0 0 11 0 660
. . . . . . . . .
3 476 26162 7 0.129.113.0 0.128.37.0 0 1 0 82
3 477 27628 7 0.128.41.0 0.128.46.0 1 1 543 543
3 478 27732 7 0.128.211.0 0.128.46.0 1 1 543 543
3 479 31048 7 0.128.47.0 2.38.221.0 1 1 60 60
3 480 32717 2 202.14.100.0 130.216.76.0 0 4 0 240
3 481 32717 2 130.216.76.0 130.216.3.0 0 232 0 16240
#Time: 12:41:25 Wed 1 Feb 95 130.216.14.251 Flows
from 33419 to 63384
3 6 3560 2 130.216.14.0 130.216.3.0 51 180 3079 138195
3 7 3560 2 130.216.14.0 130.216.76.0 21842 18428 2467693 1356570
3 8 3560 7 0.0.255.0 1.144.200.0 0 30 0 2282
3 9 3560 2 130.216.14.0 130.216.14.0 24980 1 5051834 60
3 10 3560 6 130.216.0.28 130.216.0.192 20087 1 8800070 66
3 11 3560 7 0.0.255.0 0.128.113.0 0 164 0 32608
3 12 3560 5 59.3.13.0 4.1.152.0 41 41 2460 2460
3 14 3560 5 59.3.40.0 4.1.153.0 82 82 4920 4920
3 15 3560 5 0.0.0.0 4.1.153.0 0 60 0 3600
. . . . . . . . .
3 51 3664 5 0.0.0.0 4.2.142.0 0 1 0 60 3 52 3664 5 4.1.153.0 59.3.45.0 4 4 240 240#、は調節されます: 12:36: 25 3641〜33420 3 6 3560 2 130.216.14.0 130.216.3.0 0 21 0 2378 3 7 3560 2 130.216.14.0 130.216.76.0 9586 7148 1111118 565274 3 8 3560 7 0.0.255.0 1.144.200.0 0 26 0 1983 3 9 3560 2 130.216.14.0 130.216.14.0 10596 1 2792846 60 3 10 3560 6 130.216.0.28 130.216.0.192 16589 1 7878902 66 3 11 3560 7 0.0.255.0 0.128.113.0 0 87 0 16848 3 12 3560 5 59.3.13.0 4.1.152.0 20 20 1200 1200 3 13 3560 7 0.128.94.0 0.129.27.0 15 14 900 1144年からの95 130.216回の2月1日水曜日の.14.251流れ、3、14 3560、5 59; 3.40.0 4.1.153.0 38 38 2280 2280 3 15 3560 5 0.0.0.0 4.1.153.0 0 30 0 1800 3 16 3560 5 4.1.152.0 59.2.189.0 20 20 1200 1200 3 17 3560 5 0.0.0.0 59.2.141.0 0 11 0 660. . . . . . . . . 3 476 26162 7 0.129.113.0 0.128.37.0 0 1 0 82 3 477 27628 7 0.128.41.0 0.128.46.0 1 1 543 543 3 478 27732 7 0.128.211.0 0.128.46.0 1 1 543 543 3 479 31048 7 0.128.47.0 2.38.221.0 1 1 60 60 3 480 32717 2 202.14.100.0 130.216.76.0 0 4 0 240 3 481 32717 2 130.216.76.0 130.216.3.0 0 232 0 16240#時間: 12:41: 25 33419〜63384 3 6 3560 2 130.216.14.0 130.216.3.0 51 180 3079 138195 3 7 3560 2 130.216.14.0 130.216.76.0 21842 18428 2467693 1356570 3 8 3560 7 0.0.255.0 1.144.200.0 0 30 0 2282 3 9 3560 2 130.216.14.0 130.216.14からの95 130.216回の2月1日水曜日の.14.251流れ; 0 24980 1 5051834 60 3 10 3560 6 130.216.0.28 130.216.0.192 20087 1 8800070 66 3 11 3560 7 0.0.255.0 0.128.113.0 0 164 0 32608 3 12 3560 5 59.3.13.0 4.1.152.0 41 41 2460 2460 3 14 3560 5 59.3.40.0 4.1.153.0 82 82 4920 4920 3 15 3560 5 0.0.0.0 4.1.153.0 0 60 0 3600 . . . . . . . . .
4.2 Flow data file features
4.2 流れデータファイル機能
Several features of NeMaC's flow data files (as indicated above) are worthy of note:
NeMaCの流れデータファイル(上で示されるように)のいくつかの特徴が注意にふさわしいです:
- Collection times overlap slightly between samples. This allows for
flows which were created after the collection started, and makes
sure that flows are not missed from a collection.
- 収集時間はサンプルのわずかに間に重なります。 これは、収集が始まった後に引き起こされた流れを考慮して、流れが収集から逃されていないのを確実にします。
Brownlee Informational [Page 28] RFC 2123 Traffic Flow Measurement March 1997
1997年の[28ページ]RFC2123交通の流れ測定行進の情報のブラウンリー
- The rule set may change during a run. The above shows flows from
rule set 1 - the default set - in the first collection, followed by
the first flows created by rule set 3 (which has just been
downloaded by NeMaC).
- 規則セットは走行の間、変化するかもしれません。 デフォルトがセットしたという規則セット1から、規則セット3(NeMaCによってちょうどダウンロードされました)によって引き起こされた最初の流れがあとに続いた最初の収集を流れます上記が、示す。
- FlowIndexes may be reused by the meter once their flows have been
recovered by the garbage collector. The combination of
FlowRuleSet, FlowIndex and StartTime are needed to identify a flow
uniquely.
- 彼らの流れがごみ収集人によっていったん回復されると、FlowIndexesはメーターによって再利用されるかもしれません。 FlowRuleSetの組み合わせ、FlowIndex、およびStartTimeが唯一流れを特定するのが必要です。
- Packet and Byte counters are 32-bit unsigned integers, and are
never reset by the meter. Computing the counts occurring within a
collection interval requires taking the difference between the
collected count and its value when the flow was last collected.
Note that counter wrap-around can be allowed for by simply
performing an unsigned subtraction and ignoring any carry.
- パケットとByteカウンタは、32ビットの符号のない整数であり、メーターによって決してリセットされません。 収集間隔以内に起こるカウントを計算するのは、流れが最後に集められたとき、集まっているカウントとその値の違いを取るのを必要とします。 単に無記名の引き算を実行することによって考慮できて、いずれかも無視すると運ばれるそのカウンタ巻きつけて着るドレスに注意してください。
- In the sample flow data file above I have used double spaces as
separators between the flow identifiers, peer addresses, pdu counts
and packet counts.
- サンプル流れデータファイルでは、上では、私が流れ識別子と、同輩アドレスと、pduカウントとパケットカウントの間の分離符としてダブルスペースを使用しました。
- The format of addresses in the flow data file depends on the type
of address. NeMaC always displays Adjacent addresses as six hex
bytes separated by hyphens, and Transport addresses as (16-bit)
integers. The format of a Peer address depends on its PeerType,
e.g. dotted decimal for IP. To facilitate this NeMaC needs to know
the PeerType for each flow; the user must request NeMaC to collect
it.
- 流れデータファイルのアドレスの形式はアドレスのタイプに頼っています。 NeMaCはいつも6十六進法バイト切り離されるとしてのハイフンによるAdjacentアドレスを表示します、そして、Transportは(16ビット)として整数を記述します。 Peerアドレスの形式は例えば、PeerType、IPのためのドット付き10進法に依存します。 このNeMaCを容易にするのは、各流れでPeerTypeを知る必要があります。 ユーザは、それを集めるようNeMaCに要求しなければなりません。
4.3 Terminating and restarting meter reading
4.3 検針を終えて、再開すること。
When NeMaC first starts collecting from a meter, it reads the flow data for all active flows. This provides a starting point for analysis applications to compute the counts between successive collections.
NeMaCが最初に1個のメーターを取り始めるとき、それはすべてのアクティブな流れのためのフロー・データを読みます。 分析アプリケーションが連続した収集の間のカウントを計算するように、これは出発点を提供します。
From time to time the user needs to terminate a flow data file and begin a new one. For example, a user might need to generate a separate file for each day of metering. NeMaC provides for this by closing the file after each collection, then opening it and appending the data from the next collection. To terminate a file the user simply renames it. The Unix system will effect the name change either immediately (if the file was closed) or as soon as the current collection is complete (and the file is closed).
時々、ユーザは、流れデータファイルを終えて、新しいものを始める必要があります。 例えば、ユーザは、計量の毎日の間の別々のファイルを発生させる必要があるかもしれません。 各収集の後にファイルを閉じることによって、NeMaCはこれに備えます、それとデータを追加するのがその時次の収集から開いて。 ファイルを終えるために、ユーザは単にそれを改名します。 すぐに(ファイルが閉じられたなら)か現在の収集が完全であると(ファイルは閉じられます)すぐに、Unixシステムは改名に作用するでしょう。
When NeMaC begins its next collection it observes that the file has disappeared, so it creates a new one and writes the # header records before writing the collected data.
NeMaCが次の収集を始めるとファイルが見えなくなったのを観測するので、集まっているデータを書く前に、それは、新しいものを作成して、#見出しレコードを書きます。
Brownlee Informational [Page 29] RFC 2123 Traffic Flow Measurement March 1997
1997年の[29ページ]RFC2123交通の流れ測定行進の情報のブラウンリー
There is one aspect of the above which requires some care on the user's part. The last data set in a file is not duplicated as the first data set of the next file. In other words, analysis applications must either look ahead at the first data set of the next file, or begin by reading the last data set of the previous file. If they fail to do this they will loose one collection's worth of flow data at each change of file.
ユーザの部分の上に何らかの注意を必要とする上記の1つの局面があります。 ファイルにおける最後のデータセットは次のファイルの最初のデータセットとしてコピーされません。 言い換えれば、分析アプリケーションは、次のファイルの最初のデータセットで前を見なければならないか、または前のファイルに関する最後のデータセットを読むことによって、始まらなければなりません。 彼らがこれをしないと、彼らはファイルの各変化で1つの収集のフロー・データの価値を発射するでしょう。
5 Analysis applications
5 分析アプリケーション
Most analysis applications will be unique, taking data produced by a locally-developed rule set and producing reports to satisfy specific local requirements. The NeTraMet distribution files include three applications which are of general use, as follows:
ほとんどの分析アプリケーションがユニークになるでしょう、特定の地方の要件を満たすために設定されて、レポートを製作しながら局所的に開発された規則で作り出されたデータを取って。 NeTraMet分配ファイルは以下の通り一般的使用のものである3つのアプリケーションを含んでいます:
- fd_filter computes data rates, i.e. the differences between
successive data sets in a flow data file. It also allows the user
to assign a 'tag' number to each flow; these are 'computed'
attributes similar to FlowClass and FlowKind - the only difference
is that they are computed from the collected data sets.
- fd_フィルタはデータ信号速度、すなわち、流れデータファイルの連続したデータセットの違いを計算します。 また、それで、ユーザは'タグ'番号を各流れに割り当てることができます。 これらは、FlowClassと同様の'計算された'属性とFlowKindです--唯一の違いは彼らが集まっているデータセットから計算されるということです。
- fd_extract takes 'tagged' files from fd_filter and produces simple
'column list' files for use by other programs. One common use for
fd_extract is to produce time-series data files which can be plotted
by utilities like GNUPlot.
- 抽出が取るfd_が'fd_フィルタから'ファイルにタグ付けをして、簡単な状態で生産される'という'他のプログラム1時までに一般の使用のためのファイルがfd_抽出に使用するコラムリストはGNUPlotのようなユーティリティで企むことができる時系列データファイルを作り出すことです。
- nm_rc is a 'remote console' for a NeTraMet meter. It is a slightly
simplified version of NeMaC combined with fd_filter. It can be used
to monitor any meter, and will display (as lines of text
characters) information about the n busiest flows observed during
each collection interval.
- nm_rcはNeTraMetメーター'リモートコンソール'です。 それはfd_フィルタに結合されたNeMaCのわずかに簡易型のバージョンです。 それは、どんなメーターもモニターするのに使用できて、nそれぞれの収集間隔の間に観測される中で最も忙しい流れに関して情報を表示するでしょう(テキストキャラクタの系列として)。
- nifty is a traffic flow analyser, which (like nm_rc) displays data
from a NeTraMet meter. nifty is an X/Motif application, which
produces displays like 'Packet rate (pps) vs Flow lifetime
(minutes),' so as to highlight those flows which are 'interesting.'
- かっこよいのは、交通の流れ分析器(NeTraMetメーターからデータを表示します(nm_rcのように))です。かっこよいのは、X/モチーフアプリケーション('パケットレート(pps)対Flow生涯(数分)'のようにディスプレイを起こす)です、それらの'おもしろい'流れを強調するために。
These applications are useful in themselves, and they provide a good starting point for users who wish to write their own analysis applications.
これらのアプリケーションは自分たちで役に立ちます、そして、それらはそれら自身の分析アプリケーションを書きたがっているユーザに良い出発点を提供します。
Brownlee Informational [Page 30] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[30ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
6 Using NeTraMet in a measurement system
6 測定システムでNeTraMetを使用すること。
This section gives a brief summary of the steps involved in setting up a traffic measurement system using NeTraMet. These are:
このセクションはNeTraMetを使用することでトラフィック測定システムをセットアップするのにかかわるステップの簡潔な概要をします。 これらは以下の通りです。
- Decide what is to be measured. One good way to approach this is to
specify exactly which flows are to be measured, and what reports
will be required. Specifying the flows should make it obvious
where meters will have to be placed so that the flows can be
observed, whether PCs will be adequate for the task, etc..
- 測定されることになっているべきものについて決めてください。 これにアプローチする1つの早道はどの流れが測定されることであるか、そして、どんなレポートが必要であるかをまさに指定することです。 メーターが流れを観測できるように置かれなければならないところで流れを指定するのに明白になるべきです、PCがタスクに適切になるか否かに関係なく。
- Install meters. As well as actually placing the meter hosts this
includes making sure that they are configured correctly, with
appropriate IP addresses, SNMP community strings, etc.
- メーターをインストールしてください。 実際にメーターホストを置いて、これが、彼らが正しく構成されるのを確実にするのをよく含んでいる適切なIPアドレスのように、SNMP共同体ストリングですなど。
- Develop the rule set (and a standby rule set). The degree of
difficulty here depends on how much is known in advance about the
traffic. One possible approach is to start with the meter default
rule set and measure how much traffic there is for each PeerType.
(This is a good way to verify that NeTraMet and NeMaC are working
properly). You can now add rules so as to increase the granularity
of the flows; this will of course increase the number of flows to
be collected, and force the meter's garbage collector to work
harder. Another approach is to try a rule set with very fine
granularity (i.e. one which Pushes all the address attributes),
then observing how many flows are collected every few minutes.
- 規則セット(予備規則はセットした)を発展させてください。 ここの難易度はどのくらいかがあらかじめトラフィックに関して知られているかによります。 1つの可能なアプローチは、メーター省略時の解釈セットから始まって、どのくらいのトラフィックが各PeerTypeのためにあるかを測定することです。 (これはNeTraMetとNeMaCが適切に働いていることを確かめる早道です。) あなたは現在、流れの粒状を増強するために規則を加えることができます。 これは、集められるためにもちろん流れの数を増強して、働かせる計器ごみ収集人をより困難に強制するでしょう。 別のアプローチが非常にすばらしい粒状で規則セットを試みることである、(すなわち、1、どのPushes、すべてのアドレス属性)、そして、いくつが流れるかが、あらゆる数分単位で集まっているのを観測するか。
- Develop a strategy for controlling meter reader. This means
setting the meter's maximum number of flows, the collection
interval, how breaks between flow data files will be handled, how
often NeMaC should check that the meter is running, etc.
- メーター読者を監督するための戦略を開発してください。 これは、流れの計器最大数、収集間隔を設定することを意味して、流れデータファイルの間の中断がどうあるかが扱われて、NeMaCがどれくらいの頻度でそうするべきであるかは、メーターが稼働であることなどをチェックします。
- Develop application(s) to process the collected flow data and
produce the required files and reports.
- アプリケーションを開発して、集まっているフロー・データを処理して、必要なファイルとレポートを製作してください。
- Test run. Monitor the system, then refine the rule sets and meter
reading strategy until the overall system performance is
satisfactory.
- 走行をテストしてください。 システムをモニターしてください、そして、総合体系性能が満足できるまで、次に、規則セットと検針戦略を洗練してください。
This process can take quite a long time, but the overall result is well worth the effort.
このプロセスはかなり長い時間がかかるかもしれませんが、総合的な結果は取り組みの十分価値があります。
6.1 Examples of NeTraMet in production use
6.1 生産使用でのNeTraMetに関する例
At the University of Auckland we run two sets of meters. One of these measures the traffic entering and leaving our University network, and generates usage reports for all our Internet users. This has been in production since early 1994.
オークランド大学では、私たちは2セットのメーターを動かします。 これらの1つは、私たちの大学ネットワークに入って、出て、トラフィックを測定して、私たちのすべてのインターネットユーザのために用法がレポートであると生成します。 1994年前半以来これは生産中です。
Brownlee Informational [Page 31] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[31ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
The other set consists of meters which are distributed at Universities throughout New Zealand. They provide continuous traffic flow measurements at five-minute intervals for all the links making up the Universities' network (Kawaihiko); this system has been in production since January 1996, and has already proved very useful in planning the network's development.
もう片方のセットはニュージーランド中の大学で分配されるメーターから成ります。 彼らは5分の間隔で、大学のネットワーク(Kawaihiko)を構成しているすべてのリンクに連続した交通の流れ測定値を供給します。 このシステムは、1996年1月以来生産にはあって、ネットワークの開発を計画する際に非常に役に立つと既に判明しました。
The Kawaihiko Network provides IP connectivity for the New Zealand Universities. They are linked via a Frame Relay cloud, using a partial mesh of permanent virtual circuits. There is a NeTraMet meter at each site, metering inward and outward traffic. All the meters are managed from Auckland, and they all run copies of the same rule set.
Kawaihiko NetworkはIPの接続性をニュージーランド大学に提供します。 相手固定接続の部分的なメッシュを使用して、それらはFrame Relay雲を通してリンクされます。 内部の、そして、外へ向かうトラフィックを計量して、NeTraMetメーターが各サイトにあります。 すべてのメーターがオークランドから管理されます、そして、それらは皆、同じ規則セットのコピーを動かします。
The rule set has about 650 rules, most of which are in a single subroutine which classifies PeerAddresses into three categories - 'Kawaihiko network,' 'other New Zealand network' and 'non-New Zealand network.' Inside New Zealand IP addresses lie within six CIDR blocks, and there are about four hundred older networks which have addresses outside those blocks. The rules are arranged in groups by subnet size, i.e. all the /24 networks are tested first, then the /23 networks, etc, finishing with the /16 networks. This means that although there are about 600 networks, any PeerAddress can be classified with only nine tests.
規則セットに、およそ650の規則があります。その大部分はどれがPeerAddressesを3つのカテゴリに分類するか--'Kawaihikoネットワーク'(それらのブロックの外にアドレスを持っている400の. InsideニュージーランドIPアドレスが6つのCIDRブロック属して、そこで関する'他のニュージーランドネットワーク'と'非ニュージーランドネットワーク'より古いネットワーク)というただ一つのサブルーチンにあります。 規則がサブネットサイズによってグループでアレンジされて、すなわち、すべての/24ネットワークが最初にテストされて、その時は、/23ネットワークですなど、/16ネットワークで終わって。 これは、およそ600のネットワークがありますが、9つのテストだけでどんなPeerAddressも分類できることを意味します。
The Kawaihiko rule set classifies flows, using computed attributes to indicate the network 'kind' (Kawaihiko / New Zealand / international) for each flow's SourcePeerAddress and DestPeerAddress, and to indicate whether the flow is a 'network news' flow or not.
Kawaihiko規則セットは流れを分類します、各流れのSourcePeerAddressとDestPeerAddressにおいて(Kawaihiko/ニュージーランド/国際的)でネットワーク'種類'について暗示して、流れが'ネットニュース'流動であるかどうかと暗示するのに計算された属性を使用して。
Flow data is collected from all of the meters every five minutes, and is used to produce weekly reports, as follows:
フロー・データは、5分毎にメーターのすべてから集められて、週報を製作するのに使用されます、以下の通りです:
- Traffic Plots. Plots of the 5-minute traffic rates for each site,
showing international traffic in and out, news traffic in and out,
and total traffic in and out of the site.
- トラフィックは企みます。 5分のトラフィックの陰謀は各サイトに評価します、サイトとサイトから内外での国際輸送、内外のニューストラフィック、および総トラフィックを示して。
- Traffic Matrices. Two of these are produced, one for news traffic,
the other for total traffic. They show the traffic rates from
every site (including 'other New Zealand' and 'international') to
every other site. The mean, third quartile and maximum are printed
for every cell in the matrices.
- トラフィックマトリクス。 これらの2が生産されて、ニュースのための1つがトラフィックであり、合計のためのもう片方がトラフィックです。 彼らはあらゆるサイト(含んでいる'他のニュージーランド'の、そして、'国際的な')から他のあらゆるサイトまでトラフィックレートを示しています。 平均、四分位数、および3番目の最大はマトリクスの中のあらゆるセルのために印刷されます。
Brownlee Informational [Page 32] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[32ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
7 Acknowledgments
7つの承認
This memo documents the implementation work on traffic flow measurement here at the University of Auckland. Many of my University colleagues have contributed significantly to this work, especially Russell Fulton (who developed the rules sets, Perl scripts and Cron jobs which produce our traffic usage reports automatically week after week) and John White (for his patient help in documenting the project).
このメモはここ、オークランド大学にトラフィック流量測定に対する実装仕事を記録します。 私の大学の同僚の多くがこの仕事、特にラッセル・フルトン(だれが規則を開発したかがセットして、Perlは、毎週毎週自動的に私たちのトラフィック用法レポートを製作するスクリプトとCron仕事である)、およびジョン・ホワイト(プロジェクトを記録することにおける彼の我慢強いご協力のための)にかなり貢献しました。
8 References
8つの参照箇所
[1] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2063, The University of Auckland,
Bolt Beranek and Newman Inc., GTE Laboratories, Inc, January 1997.
[1] ブラウンリー、N.、工場、C.、およびG.ルース、「流量測定を取引してください」 「アーキテクチャ」、RFC2063、オークランド大学は1997年1月にBeranekとニューマン株式会社、GTE研究所、Incをボルトで締めます。
[2] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
RFC 2064, The University of Auckland, January 1997.
[2] ブラウンリー、N.、「流量測定を取引してください」 「メーターMIB」、RFC2064、オークランド大学、1997年1月。
[3] CRYNWR Packer Drivers distribution site:
http://www.crynwr.com/
[3] CRYNWR Packer Drivers分配サイト: http://www.crynwr.com/
[4] Case J., McCloghrie K., Rose M., and Waldbusser S.,
"Structure of Management Information for version 2 of the
Simple Network Managemenet Protocol", RFC 1902, SNMP Research
Inc., Hughes LAN Systems, Dover Beach Consulting, Carnegie
Mellon University, April 1993.
[4] J.、McCloghrie K.、ローズM.、およびWaldbusser S.、「Simple Network Managemenetプロトコルのバージョン2のためのManagement情報の構造」をケースに入れてください、RFC1902、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting、カーネギーメロン大学、1993年4月。
[5] IBM Corporation, "IBM PC Technical Reference Manual," 1984.
[5]IBM社、「IBMのPCの技術的なリファレンスマニュアル」、1984。
[6] Waterloo TCP distribution site:
http://mvmpc9.ciw.uni-karlsruhe.de:80/d:/public/tcp_ip/wattcp
[6] ウォータールーTCP分配サイト: http://mvmpc9.ciw.uni-karlsruhe.de:80/d:/public/tcp_ip/wattcp
[7] CMU SNMP distribution site:
ftp://lancaster.andrew.cmu.edu/pub/snmp-dist
[7] CMU SNMP分配サイト: ftp://lancaster.andrew.cmu.edu/pub/snmp-dist
[8] libpcap distribution site:
ftp://ftp.ee.lbl.gov/libpcap-*.tar.gz
[8] libpcap分配サイト: ftp://ftp.ee.lbl.gov/libpcap-*.tar.gz
Brownlee Informational [Page 33] RFC 2123 Traffic Flow Measurement March 1997
ブラウンリー情報[33ページ]のRFC2123Trafficは1997年の測定行進のときに流れます。
9 Security Considerations
9 セキュリティ問題
Security issues are not discussed in detail in this document. The meter's management and collection protocols are responsible for providing sufficient data integrity and confidentiality.
詳細に本書では安全保障問題について議論しません。 計器管理回収プロトコルは十分なデータ保全と秘密性を提供するのに原因となります。
10 Author's Address
10作者のアドレス
Nevil Brownlee The University of Auckland
ネヴィル・ブラウンリーオークランド大学
Phone: +64 9 373 7599 x8941 Email: n.brownlee@auckland.ac.nz
以下に電話をしてください。 +64 9 373 7599年のx8941メール: n.brownlee@auckland.ac.nz
Brownlee Informational [Page 34]
ブラウンリーInformationalです。[34ページ]
一覧
スポンサーリンク
