Network Working Group N. Brownlee
Request for Comments: 2722 The University of Auckland
Obsoletes: 2063 C. Mills
Category: Informational GTE Laboratories, Inc
G. Ruth
GTE Internetworking
October 1999
Traffic Flow Measurement: Architecture
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet.
この文書は、ネットワーク・トラフィック・フローを記述するための一般的なフレームワークを提供するトラフィック流量測定および報告のためのアーキテクチャを示し、これはネットワーク全体のトラフィックフローアーキテクチャに関し、それは、インターネット内で使用することができるかを示す方法について説明します。
Table of Contents
目次
1 Statement of Purpose and Scope 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2 Traffic Flow Measurement Architecture 5
2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . 5
2.2 Interaction Between METER and METER READER . . . . . . . . 7
2.3 Interaction Between MANAGER and METER . . . . . . . . . . 7
2.4 Interaction Between MANAGER and METER READER . . . . . . . 8
2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . 9
2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . 10
2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . 10
3 Traffic Flows and Reporting Granularity 10
3.1 Flows and their Attributes . . . . . . . . . . . . . . . . 10
3.2 Granularity of Flow Measurements . . . . . . . . . . . . . 13
3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . 15
4 Meters 17
4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . 17
4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . 20
4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . 23
4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . 28
4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . 29
5 Meter Readers 30
5.1 Identifying Flows in Flow Records . . . . . . . . . . . . 30
5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . 30
5.3 Meter to Meter Reader: Usage Record Transmission . . . . 31
6 Managers 32
6.1 Between Manager and Meter: Control Functions . . . . . . 32
6.2 Between Manager and Meter Reader: Control Functions . . . 33
6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . 35
6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . 36
7 Security Considerations 36
7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . 36
7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . 37
8 IANA Considerations 39
8.1 PME Opcodes . . . . . . . . . . . . . . . . . . . . . . . 39
8.2 RTFM Attributes . . . . . . . . . . . . . . . . . . . . . 39
9 APPENDICES 41
Appendix A: Network Characterisation . . . . . . . . . . . . . 41
Appendix B: Recommended Traffic Flow Measurement Capabilities . 42
Appendix C: List of Defined Flow Attributes . . . . . . . . . . 43
Appendix D: List of Meter Control Variables . . . . . . . . . . 44
Appendix E: Changes Introduced Since RFC 2063 . . . . . . . . . 45
10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 45
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47
13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 48
1 Statement of Purpose and Scope
目的と範囲の1人の書
This document describes an architecture for traffic flow measurement and reporting for data networks which has the following characteristics:
このドキュメントでは、次のような特徴を持っているデータネットワークのトラフィック流量測定および報告のためのアーキテクチャについて説明します。
- The traffic flow model can be consistently applied to any protocol, using address attributes in any combination at the 'adjacent' (see below), network and transport layers of the networking stack.
- トラフィックフローモデルは、一貫してネットワークスタックの「隣接」（下記参照）、ネットワークおよびトランスポート層での任意の組み合わせでアドレス属性を使用して、任意のプロトコルに適用することができます。
- Traffic flow attributes are defined in such a way that they are valid for multiple networking protocol stacks, and that traffic flow measurement implementations are useful in multi-protocol environments.
- トラフィックフロー属性は、それらが、複数のネットワークプロトコルスタックのために有効であること、およびトラフィック流量測定実装は、マルチプロトコル環境で有用であるように定義されています。
- Users may specify their traffic flow measurement requirements by writing 'rule sets', allowing them to collect the flow data they need while ignoring other traffic.
- ユーザーは、彼らが他のトラフィックを無視して、彼らが必要とするフローデータを収集することができ、「設定のルール」を書き込むことによって、彼らの交通流計測の要件を指定することもできます。
- The data reduction effort to produce requested traffic flow information is placed as near as possible to the network measurement point. This minimises the volume of data to be obtained (and transmitted across the network for storage), and reduces the amount of processing required in traffic flow analysis applications.
- 要求されたトラフィックフロー情報を生成するデータ削減努力は、ネットワーク測定点のできるだけ近くに配置されています。これにより得られた（と記憶のためにネットワークを介して送信）されるデータの量を最小限にし、トラフィックフロー分析アプリケーションに必要な処理の量を減少させます。
'Adjacent' (as used above) is a layer-neutral term for the next layer down in a particular instantiation of protocol layering. Although 'adjacent' will usually imply the link layer (MAC addresses), it does not implicitly advocate or dismiss any particular form of tunnelling or layering.
（上記で使用される）「隣接」プロトコルレイヤリングの特定のインスタンス化に次の層のためのダウン層中立的な用語です。 「隣接」は通常、リンク層（MACアドレス）を意味するものではありますが、それは暗黙的トンネリングまたはレイヤーのいずれかの特定の形を提唱または却下しません。
The architecture specifies common metrics for measuring traffic flows. By using the same metrics, traffic flow data can be exchanged and compared across multiple platforms. Such data is useful for:
アーキテクチャは、トラフィックフローを測定するための共通の指標を指定します。同じメトリックを使用して、トラフィックフローデータは、複数のプラットフォーム間で交換し、比較することができます。このようなデータはのために便利です。
- Understanding the behaviour of existing networks,
- 既存のネットワークの振る舞いを理解した上で、
- Planning for network development and expansion,
- ネットワークの発展と拡大のための計画、
- Quantification of network performance,
- ネットワークパフォーマンスの定量化、
- Verifying the quality of network service, and
- ネットワークサービスの品質を確認し、
- Attribution of network usage to users.
- ユーザーにネットワークの使用状況の帰属。
The traffic flow measurement architecture is deliberately structured using address attributes which are defined in a consistent way at the Adjacent, Network and Transport layers of the networking stack, allowing specific implementations of the architecture to be used effectively in multi-protocol environments. Within this document the term 'usage data' is used as a generic term for the data obtained using the traffic flow measurement architecture.
トラフィック流量測定アーキテクチャは、意図的なアーキテクチャの特定の実装は、マルチプロトコル環境で効果的に使用できるように、ネットワークスタックの隣接して、ネットワークおよびトランスポート層で一貫した方法で定義されているアドレスの属性を使用して構成されています。本文書内の用語「使用データは」トラフィック流量測定アーキテクチャを使用して得られたデータの総称として使用されます。
In principle one might define address attributes for higher layers, but it would be very difficult to do this in a general way. However, if an RTFM traffic meter were implemented within an application server (where it had direct access to application-specific usage information), it would be possible to use the rest of the RTFM architecture to collect application-specific information. Use of the same model for both network- and application-level measurement in this way could simplify the development of generic analysis applications which process and/or correlate both traffic and usage information. Experimental work in this area is described in the RTFM 'New Attributes' document [RTFM-NEW].
原則として、1は上位レイヤのアドレス属性を定義するかもしれないが、一般的な方法でこれを行うことは非常に困難であろう。 RTFMトラフィックメータは、（それがアプリケーション固有の使用状況の情報に直接アクセスした場合）、アプリケーションサーバ内に実装された場合は、アプリケーション固有の情報を収集するためにRTFMアーキテクチャの残りの部分を使用することも可能です。このようにネットワーク - およびアプリケーションレベルの測定の両方に同じモデルを使用すると、トラフィックと使用情報の両方を相関プロセスおよび/または一般的な分析アプリケーションの開発を簡素化することができます。この領域での実験的な作品はRTFM「新しい属性」ドキュメント[RTFM-NEW]に記載されています。
This document is not a protocol specification. It specifies and structures the information that a traffic flow measurement system needs to collect, describes requirements that such a system must meet, and outlines tradeoffs which may be made by an implementor.
この文書では、プロトコル仕様ではありません。これは、指定した構造交通流計測システムが収集するために必要な情報を、このようなシステムが満たすべき要件について説明し、実装により作製することができるトレードオフを概説します。
For performance reasons, it may be desirable to use traffic information gathered through traffic flow measurement in lieu of network statistics obtained in other ways. Although the quantification of network performance is not the primary purpose of this architecture, the measured traffic flow data may be used as an indication of network performance.
パフォーマンス上の理由から、他の方法で得られたネットワーク統計の代わりに交通流計測を通じて収集交通情報を使用することが望ましいです。ネットワーク性能の定量化は、このアーキテクチャの主な目的ではないが、測定されたトラフィックフローデータは、ネットワーク性能の指標として使用することができます。
A cost recovery structure decides "who pays for what." The major issue here is how to construct a tariff (who gets billed, how much, for which things, based on what information, etc). Tariff issues include fairness, predictability (how well can subscribers forecast their network charges), practicality (of gathering the data and administering the tariff), incentives (e.g. encouraging off-peak use), and cost recovery goals (100% recovery, subsidisation, profit making). Issues such as these are not covered here.
コスト回収の構造は、「誰が何のために支払う。」決定しますここでの大きな問題は、（どのような情報などに基づいて、その物事のために、どのくらいの、請求されます）関税を構築する方法です。関税の問題は、公平性、予測可能性（どれだけの加入者が自分のネットワーク費用を予測することができます）、（データを収集し、関税を投与する）実用性、インセンティブ（例えばオフピーク利用を奨励）、およびコスト回収の目標（回収率100％、補助金を含み、営利）。このような問題は、ここではカバーされていません。
Background information explaining why this approach was selected is provided by the 'Internet Accounting Background' RFC [ACT-BKG].
このアプローチを選択した理由を説明する背景情報は、「インターネット会計背景」RFC [ACT-BKG]によって提供されます。
2 Traffic Flow Measurement Architecture
2交通流計測アーキテクチャ
A traffic flow measurement system is used by Network Operations personnel to aid in managing and developing a network. It provides a tool for measuring and understanding the network's traffic flows. This information is useful for many purposes, as mentioned in section 1 (above).
交通流計測システムは、ネットワークを管理し、開発を支援するためにネットワークオペレーション担当者によって使用されます。これは、ネットワークのトラフィックフローを測定し、理解するためのツールを提供しています。セクション1（上記）で述べたように、この情報は、多くの目的のために有用です。
The following sections outline a model for traffic flow measurement, which draws from working drafts of the OSI accounting model [OSI-ACT].
次のセクションでは、OSI会計モデル[OSI-ACT]のワーキングドラフトから引く交通流計測のためのモデルの概要を説明します。
At the heart of the traffic measurement model are network entities called traffic METERS. Meters observe packets as they pass by a single point on their way through the network and classify them into certain groups. For each such group a meter will accumulate certain attributes, for example the numbers of packets and bytes observed for the group. These METERED TRAFFIC GROUPS may correspond to a user, a host system, a network, a group of networks, a particular transport address (e.g. an IP port number), any combination of the above, etc, depending on the meter's configuration.
トラフィック測定モデルの中心に交通METERSと呼ばれるネットワークエンティティです。彼らは、ネットワークを介して自分の道上の一点を通過し、特定のグループにそれらを分類するとメーターはパケットを観察します。このような各グループのためにメーターは、例えばパケットおよびバイトの数は、グループについて観察、特定の属性を蓄積します。これらの計量されたトラフィック・グループは、ユーザ、ホストシステム、ネットワーク、メーターの構成に応じてネットワークのグループ、特定のトランスポートアドレス（例えば、IPポート番号）、上記の任意の組み合わせ、等に対応することができます。
We assume that routers or traffic monitors throughout a network are instrumented with meters to measure traffic. Issues surrounding the choice of meter placement are discussed in the 'Internet Accounting Background' RFC [ACT-BKG]. An important aspect of meters is that they provide a way of succinctly aggregating traffic information.
私たちは、ネットワーク全体のルータやトラフィックのモニタがトラフィックを測定するメーターで計測されていることを前提としています。メーターの配置の選択を取り巻く問題は、「インターネット会計背景」RFC [ACT-BKG]で議論されています。メートルの重要な側面は、彼らが簡潔に交通情報を集約する方法を提供するということです。
For the purpose of traffic flow measurement we define the concept of a TRAFFIC FLOW, which is like an artificial logical equivalent to a call or connection. A flow is a portion of traffic, delimited by a start and stop time, that belongs to one of the metered traffic groups mentioned above. Attribute values (source/destination addresses, packet counts, byte counts, etc.) associated with a flow are aggregate quantities reflecting events which take place in the DURATION between the start and stop times. The start time of a flow is fixed for a given flow; the stop time may increase with the age of the flow.
交通流計測の目的のために、我々は、コールまたは接続への人工的な論理と同等のようなものであるトラフィックフローの概念を定義します。流れは、上述した計量トラフィック・グループの一つに属する、スタートで区切ら及び停止時間、トラフィックの一部です。フローに関連付けられた値は、（ソース/宛先アドレス、パケット数、バイト数、等）の開始と終了時刻間の期間で起こるイベントを反映する骨材量である属性。フローの開始時間は、所与の流れのために固定されています。停止時間は流れの年齢とともに増加することができます。
For connectionless network protocols such as IP there is by definition no way to tell whether a packet with a particular source/destination combination is part of a stream of packets or not - each packet is completely independent. A traffic meter has, as part of its configuration, a set of 'rules' which specify the flows of interest, in terms of the values of their attributes. It derives attribute values from each observed packet, and uses these to decide which flow they belong to. Classifying packets into 'flows' in this way provides an economical and practical way to measure network traffic and subdivide it into well-defined groups.
各パケットは、完全に独立して - 例えばIPのようなコネクションレスネットワークプロトコルの定義により、特定のソース/宛先の組み合わせでパケットはパケットかどうかのストリームの一部であるかどうかを指示する方法はありません。トラフィックメータは、その構成の一部として、それらの属性の値の観点から、関心の流れを指定して「ルール」のセットがあります。これは、各観測されたパケットから属性値を導出し、彼らが属する流れるかを決定するためにこれらを使用しています。このように「流れ」にパケットを分類すると、ネットワークのトラフィックを測定し、明確に定義されたグループにそれを細分化するために経済的で実用的な方法を提供します。
Usage information which is not derivable from traffic flows may also be of interest. For example, an application may wish to record accesses to various different information resources or a host may wish to record the username (subscriber id) for a particular network session. Provision is made in the traffic flow architecture to do this. In the future the measurement model may be extended to gather such information from applications and hosts so as to provide values for higher-layer flow attributes.
トラフィックフローから誘導されていない使用法の情報も興味深いかもしれません。例えば、録音することができるアプリケーションは、様々な異なる情報リソースへのアクセスまたはホストは、特定のネットワークセッションのためにユーザ名（加入者ID）を記録することを望むかもしれません。提供は、これを行うには、トラフィックフローアーキテクチャで作られています。上位層フロー属性の値を提供するように、将来的に測定モデルは、アプリケーションおよびホストからそのような情報を収集するように拡張することができます。
As well as FLOWS and METERS, the traffic flow measurement model includes MANAGERS, METER READERS and ANALYSIS APPLICATIONS, which are explained in following sections. The relationships between them are shown by the diagram below. Numbers on the diagram refer to sections in this document.
同様に流れ、メーター、トラフィック流量測定モデルは、セクションを以下に説明するMANAGERS、METERリーダおよび分析アプリケーションを含みます。それらの間の関係は以下の図で示されています。図の番号は、このドキュメントのセクションを参照してください。
MANAGER
/ \
2.3 / \ 2.4
/ \
/ \ ANALYSIS
METER <-----> METER READER <-----> APPLICATION
2.2 2.7
- MANAGER: A traffic measurement manager is an application which configures 'meter' entities and controls 'meter reader' entities. It sends configuration commands to the meters, and supervises the proper operation of each meter and meter reader. It may well be convenient to combine the functions of meter reader and manager within a single network entity.
- MANAGER：トラフィック測定マネージャ「メーター」エンティティとコントロールのメーター読者 'エンティティを構成するアプリケーションです。それはメートルに設定コマンドを送信し、各計器やメータ読取装置の適切な動作を監視します。よく、単一のネットワークエンティティ内メーターリーダーとマネージャの機能を組み合わせることが好都合であり得ます。
- METER: Meters are placed at measurement points determined by Network Operations personnel. Each meter selectively records network activity as directed by its configuration settings. It can also aggregate, transform and further process the recorded activity before the data is stored. The processed and stored results are called the 'usage data'.
- METER：メーターがネットワーク運営者によって決定された測定点に配置されています。その構成設定の指示に従って、各メーターは、選択的にネットワークアクティビティを記録します。データが格納される前に、それはまた、記録活動を変換、集約し、さらに処理することができます。処理され、保存された結果は、「使用状況データ」と呼ばれています。
- METER READER: A meter reader transports usage data from meters so that it is available to analysis applications.
- METERリーダー：それは分析アプリケーションに利用できるようにメータリーダメートルから使用データを搬送します。
- ANALYSIS APPLICATION: An analysis application processes the usage data so as to provide information and reports which are useful for network engineering and management purposes. Examples include:
- 解析アプリケーション：分析アプリケーションネットワークエンジニアリングと管理の目的のために有用である情報とレポートを提供するように使用データを処理します。例としては、
- TRAFFIC FLOW MATRICES, showing the total flow rates for many
of the possible paths within an internet.
- FLOW RATE FREQUENCY DISTRIBUTIONS, summarizing flow rates over a period of time.
- 流量頻度分布、時間をかけて流量をまとめました。
- USAGE DATA showing the total traffic volumes sent and received by particular hosts.
- 特定のホストによって送信され、受信された総トラフィック量を示す使用データ。
The operation of the traffic measurement system as a whole is best understood by considering the interactions between its components. These are described in the following sections.
全体としてトラフィック測定システムの動作は、最良の構成要素間の相互作用を考慮することによって理解されます。これらは以下のセクションで説明されています。
The information which travels along this path is the usage data itself. A meter holds usage data in an array of flow data records known as the FLOW TABLE. A meter reader may collect the data in any suitable manner. For example it might upload a copy of the whole flow table using a file transfer protocol, or read the records in the current flow set one at a time using a suitable data transfer protocol. Note that the meter reader need not read complete flow data records, a subset of their attribute values may well be sufficient.
この経路に沿って移動情報は、利用データそのものです。メータは、フローテーブルとして知られているフローデータレコードの配列内の使用量データを保持しています。メーター読者は、任意の適切な方法でデータを収集することができます。例えば、それはファイル転送プロトコルを使用して全体の流れテーブルのコピーをアップロードしたり、電流の流れにレコードを読み取る適切なデータ転送プロトコルを使用して、一度に1つを設定します。メーター読者が完全なフローデータレコードを読み取る必要がないことに注意し、その属性値のサブセットはよく十分であろう。
A meter reader may collect usage data from one or more meters. Data may be collected from the meters at any time. There is no requirement for collections to be synchronized in any way.
メーター読者は、一つ以上のメートルから使用状況データを収集することができます。データはいつでもメーターから収集することができます。コレクションはどのような方法で同期させるために必要はありません。
A manager is responsible for configuring and controlling one or more meters. Each meter's configuration includes information such as:
管理者は、1メートル以上を設定し、制御するための責任があります。各メーターの設定は、次のような情報が含まれています。
- Flow specifications, e.g. which traffic flows are to be measured, how they are to be aggregated, and any data the meter is required to compute for each flow being measured.
- フローの仕様、例えばそのトラフィックフローは、それらが集約される方法、測定すべきであり、任意のデータが計器が測定されるフローごとに計算する必要があります。
- Meter control parameters, e.g. the 'inactivity' time for flows (if no packets belonging to a flow are seen for this time the flow is considered to have ended, i.e. to have become idle).
- メータ制御パラメータ、例えばフローの「非アクティブ」の時間（フローに属するパケットがフローが終了したと考えられている。この時のために見られない場合には、すなわち、アイドル状態になっているため）。
- Sampling behaviour. Normally every packet will be observed. It may sometimes be necessary to use sampling techniques so as to observe only some of the packets (see following note).
- サンプリング動作。通常、すべてのパケットが観測されます。 （以下の注を参照）のみのパケットの一部を観察するように時々サンプリング技術を使用する必要があります。
A note about sampling: Current experience with the measurement architecture shows that a carefully-designed and implemented meter compresses the data sufficiently well that in normal LANs and WANs of today sampling is seldom, if ever, needed. For this reason sampling algorithms are not prescribed by the architecture. If sampling is needed, e.g. for metering a very-high-speed network with fine-grained flows, the sampling technique should be carefully chosen so as not to bias the results. For a good introduction to this topic see the IPPM Working Group's RFC "Framework for IP Performance Metrics" [IPPM-FRM].
サンプリングについての注意：計測アーキテクチャと現在の経験は慎重に設計され、実装さ計はこれまで、必要に応じて、今日のサンプリングの通常のLANとWANで、めったにないことを十分にデータを圧縮することを示していますこのため、サンプリングアルゴリズムはアーキテクチャによって規定されていません。サンプリングが必要な場合は、例えばファイングレインフローを有する超高速ネットワークを計量するために、サンプリング技術を注意深くないバイアスするように結果を選択すべきです。このトピックへの良好な概要については、[IPPM-FRM] IPPMワーキンググループのRFC「IPパフォーマンス・メトリックのためのフレームワーク」を参照してください。
A meter may run several rule sets concurrently on behalf of one or more managers, and any manager may download a set of flow specifications (i.e. a 'rule set') to a meter. Control parameters which apply to an individual rule set should be set by the manager after it downloads that rule set.
いくつかのルールを実行することができる計器は、一の以上のマネージャの代わりに同時に設定し、任意のマネージャはメーターにフロー仕様のセット（すなわち、「ルール・セット」）をダウンロードすることができます。それはそのルールセットをダウンロードした後、個々のルール・セットに適用する制御パラメータは、管理者が設定する必要があります。
One manager should be designated as the 'master' for a meter. Parameters such as sampling behaviour, which affect the overall operation of the meter, should only be set by the master manager.
1つのマネージャは、メーターのための「マスター」として指定する必要があります。メートルの全体的な動作に影響を与えるようなサンプリングの挙動などのパラメータは、唯一のマスター管理者が設定する必要があります。
A manager is responsible for configuring and controlling one or more meter readers. A meter reader may only be controlled by a single manager. A meter reader needs to know at least the following for every meter it is collecting usage data from:
マネージャーは、1つまたは複数の検針を設定し、制御するための責任があります。メーター読者は、単一のマネージャによって制御されてもよいです。メーター読者はそれから使用状況データを収集しているすべてのメーターについては、以下の少なくとも知っておく必要があります。
- The meter's unique identity, i.e. its network name or address.
- メーターの一意の識別情報、すなわち、そのネットワーク名またはアドレス。
- How often usage data is to be collected from the meter.
- どのくらいの頻度で使用データは、メーターから収集されます。
- Which flow records are to be collected (e.g. all flows, flows for a particular rule set, flows which have been active since a given time, etc.).
- 収集されるべきレコードを流れ（例えば、すべてのフローは、特定のルールセット、与えられた時間以来アクティブであったフロー等に流れます）。
- Which attribute values are to be collected for the required flow records (e.g. all attributes, or a small subset of them)
必要なフローレコード（例えば、すべての属性、またはそれらの小さなサブセット）のために収集されるべき属性値を -
Since redundant reporting may be used in order to increase the reliability of usage data, exchanges among multiple entities must be considered as well. These are discussed below.
冗長レポートは、利用データの信頼性を高めるために使用することができるので、複数のエンティティ間で交換も考慮しなければなりません。これらは、以下で説明されています。
-- METER READER A --
/ | \
/ | \
=====METER 1 METER 2=====METER 3 METER 4=====
\ | /
\ | /
-- METER READER B --
Several uniquely identified meters may report to one or more meter readers. The diagram above gives an example of how multiple meters and meter readers could be used.
いくつか一意に識別されたメーターは、一つ以上のメーター読者に報告することができます。上記の図は、使用することができる方法を複数メートル、メートル読者の例を示します。
In the diagram above meter 1 is read by meter reader A, and meter 4 is read by meter reader B. Meters 1 and 4 have no redundancy; if either meter fails, usage data for their network segments will be lost.
計1上の図では、メータリーダAによって読み取られ、メーター4は計リーダB.計1によって読み取られ、図4は、冗長性を持ちません。どちらかのメーターが故障した場合、そのネットワークセグメントの使用データが失われます。
Meters 2 and 3, however, measure traffic on the same network segment. One of them may fail leaving the other collecting the segment's usage data. Meters 2 and 3 are read by meter reader A and by meter reader B. If one meter reader fails, the other will continue collecting usage data from both meters.
メートル2及び3は、しかし、同じネットワークセグメント上のトラフィックを測定します。そのうちの一つは、他の収集セグメントの使用状況データを残して失敗することがあります。メートル2及び3は、1メートル読者が失敗した場合、他方は両方メートルから使用データを収集続けるメータリーダAによってメータリーダBによって読み取られます。
The architecture does not require multiple meter readers to be synchronized. In the situation above meter readers A and B could both collect usage data at the same intervals, but not necesarily at the same times. Note that because collections are asynchronous it is unlikely that usage records from two different meter readers will agree exactly.
アーキテクチャは、同期させるために複数のメーター読者を必要としません。メーター読者A及びB上記の状況ではなくnecesarily同じ時間に、同じ間隔で、使用量データを収集することができ、両方。コレクションは非同期であるので、二つの異なるメーター読者からの使用記録が正確に同意することはありそうにないことに注意してください。
If identical usage records were required from a single meter, a manager could achieve this using two identical copies of a ruleset in that meter. Let's call them RS1 and RS2, and assume that RS1 is running. When a collection is to be made the manager switches the meter from RS1 to RS2, and directs the meter reader(s) to read flow data for RS1 from the meter. For the next collection the manager switches back to RS1, and so on. Note, however, that it is not possible to get identical usage records from more than one meter, since there is no way for a manager to switch rulesets in more than one meter at the same time.
同じ使用状況レコードが単一メートルから要求された場合は、管理者がそのメートルでのルールセットの2つの同一のコピーを使用して、これを達成できます。のは、RS1とRS2それらを呼び出すと、RS1が実行されていることを前提としましょう。コレクションが行われるべき場合マネージャはRS1からRS2へメーターを切り替え、計からRS1ためのフローデータを読み取るメーターリーダー（単数または複数）を指示します。次のコレクションの管理者は、というように、RS1に戻ります。管理者が同時に1メートル以上にルールセットを切り替える方法はありませんので、1メートル以上から、同一の使用状況レコードを取得することができないこと、しかし、注意してください。
If there is only one meter reader and it fails, the meters continue to run. When the meter reader is restarted it can collect all of the accumulated flow data. Should this happen, time resolution will be lost (because of the missed collections) but overall traffic flow information will not. The only exception to this would occur if the traffic volume was sufficient to 'roll over' counters for some flows during the failure; this is addressed in the section on 'Rolling Counters'.
そこだけ1メートルのリーダーであり、それが失敗した場合、メーターは実行し続けます。メーター読者が再開された場合には、蓄積されたフローデータのすべてを収集することができます。これが起こるはず、時間分解能が（理由は逃したコレクションの）失われますが、全体のトラフィックフロー情報はしません。交通量は、障害時の一部のフローのためのカウンター「ロールオーバー」に十分であった場合は例外が発生します。これは、「ローリングカウンター」に関するセクションで扱われています。
Synchronization between multiple management systems is the province of network management protocols. This traffic flow measurement architecture specifies only the network management controls necessary to perform the traffic flow measurement function and does not address the more global issues of simultaneous or interleaved (possibly conflicting) commands from multiple network management stations or the process of transferring control from one network management station to another.
複数の管理システム間の同期は、ネットワーク管理プロトコルの州です。この交通流計測アーキテクチャは唯一のネットワーク管理は、トラフィックフロー測定機能を実行するために必要なコントロールとのよりグローバルな問題に対処していない指定、同時またはインターリーブされた（おそらく競合）複数のネットワーク管理ステーションまたは1つのネットワークからの制御を転送するプロセスからのコマンド別の管理ステーション。
Once a collection of usage data has been assembled by a meter reader it can be processed by an analysis application. Details of analysis applications - such as the reports they produce and the data they require - are outside the scope of this architecture.
一度利用状況データの収集は、解析アプリケーションで処理可能なメーター読者によって組み立てられました。それらが生み出すレポートや、彼らが必要とするデータとして - - 分析アプリケーションの詳細については、このアーキテクチャの範囲外です。
It should be noted, however, that analysis applications will often require considerable amounts of input data. An important part of running a traffic flow measurement system is the storage and regular reduction of flow data so as to produce daily, weekly or monthly summary files for further analysis. Again, details of such data handling are outside the scope of this architecture.
分析アプリケーションは、多くの場合、入力データのかなりの量が必要になることに留意すべきです。さらなる分析のために、毎日、毎週、または毎月の要約ファイルを生成するように交通流計測システムを実行しているの重要な部分は、フローデータの保存や定期的な減少です。再び、そのようなデータ処理の詳細は、このアーキテクチャの範囲外です。
3 Traffic Flows and Reporting Granularity
3つのトラフィックフローおよび粒度の報告
A flow was defined in section 2.1 above in abstract terms as follows:
次のように流れ、抽象に関して上記セクション2.1で定義されました。
"A TRAFFIC FLOW is an artifical logical equivalent to a call or
connection, belonging to a (user-specieied) METERED TRAFFIC
GROUP."
In practical terms, a flow is a stream of packets observed by the meter as they pass across a network between two end points (or from a single end point), which have been summarized by a traffic meter for analysis purposes.
それらは、分析のためにトラフィックメータによって要約された2つのエンドポイント（またはシングルエンドポイントからの）との間のネットワークを介して通過するように実際には、フローメータによって観測されたパケットのストリームです。
Every traffic meter maintains a table of 'flow records' for flows seen by the meter. A flow record holds the values of the ATTRIBUTES of interest for its flow. These attributes might include:
すべてのトラフィックメーターはメーターで見フローのための「フローレコード」のテーブルを維持します。フローレコードは、その流れのための関心の属性の値を保持します。これらの属性は、次のものがあります
- ADDRESSES for the flow's source and destination. These comprise the protocol type, the source and destination addresses at various network layers (extracted from the packet header), and the number of the interface on which the packet was observed.
- フローの送信元と送信先のアドレス。これらは、プロトコルタイプ、（パケットヘッダから抽出された）は、種々のネットワーク層での送信元アドレスと宛先アドレス、パケットが観測されたインターフェースの数を含みます。
- First and last TIMES when packets were seen for this flow, i.e. the 'creation' and 'last activity' times for the flow.
- まず、パケットがこの流れのために見られた最後TIMES、流れのための、すなわち「創造」と「最後のアクティビティ」回。
- COUNTS for 'forward' (source to destination) and 'backward' (destination to source) components (e.g. packets and bytes) of the flow's traffic. The specifying of 'source' and 'destination' for flows is discussed in the section on packet matching below.
- フローのトラフィックの「フォワード」（宛先へのソース）と「逆方向」（送信元へ送信先）のコンポーネントの数（例えば、パケットおよびバイト）。 「ソース」と流れのための「宛先」の指定は、以下のパケット・マッチングに関するセクションで説明されています。
- OTHER attributes, e.g. the index of the flow's record in the flow table and the rule set number for the rules which the meter was running while the flow was observed. The values of these attributes provide a way of distinguishing flows observed by a meter at different times.
- 他の属性、例えばフローのフローテーブル内のレコードと流れが観察されたメーターが実行されていたルールのルールセットの数の指標。これらの属性の値は、異なる時間に計で観測フローを区別する方法を提供します。
The attributes listed in this document (Appendix C) provide a basic (i.e. useful minimum) set; IANA considerations for allocating new attributes are set out in section 8 below.
この文書（付録C）に記載されている属性は、基本的な（すなわち、有用な最小の）セットを提供します。新しい属性を割り当てるためのIANA問題は、以下のセクション8に記載されています。
A flow's METERED TRAFFIC GROUP is specified by the values of its ADDRESS attributes. For example, if a flow's address attributes were specified as "source address = IP address 10.1.0.1, destination address = IP address 26.1.0.1" then only IP packets from 10.1.0.1 to 26.1.0.1 and back would be counted in that flow. If a flow's address attributes specified only that "source address = IP address 10.1.0.1," then all IP packets from and to 10.1.0.1 would be counted in that flow.
流れの計量されたTRAFFIC GROUPは、そのアドレス属性の値によって指定されます。フローのアドレス属性は以下のように指定された場合、例えば、「送信元アドレス= IPアドレス10.1.0.1、宛先アドレス= IPアドレス26.1.0.1は、」次に10.1.0.1から26.1.0.1及び背面にのみIPパケットがそのフローでカウントされます。流れのアドレス属性のみに指定した場合、「送信元アドレス= IPアドレス10.1.0.1、」その後、10.1.0.1からとするすべてのIPパケットは、その流れの中でカウントされます。
The addresses specifying a flow's address attributes may include one or more of the following types:
流れのアドレス属性を指定するアドレスは、次の種類の一つ以上を含むことができます。
- The INTERFACE NUMBER for the flow, i.e. the interface on which the meter measured the traffic. Together with a unique address for the meter this uniquely identifies a particular physical-level port.
- 流れのためのインターフェイス番号、すなわちメーターがトラフィックを測定するインターフェイス。一緒にメータの一意のアドレスをこの一意特定の物理レベルのポートを識別する。
- The ADJACENT ADDRESS, i.e. the address in the the next layer down from the peer address in a particular instantiation of protocol layering. Although 'adjacent' will usually imply the link layer, it does not implicitly advocate or dismiss any particular form of tunnelling or layering.
- ADJACENT ADDRESS、すなわちプロトコルレイヤリングの特定のインスタンス化でダウンピアアドレスから次の層内のアドレス。 「隣接」は通常、リンク層を意味するものではありますが、それは暗黙的トンネリングまたはレイヤーのいずれかの特定の形を提唱または却下しません。
For example, if flow measurement is being performed using IP as the network layer on an Ethernet LAN [802-3], an adjacent address will normally be a six-octet Media Access Control (MAC) address. For a host connected to the same LAN segment as the meter the adjacent address will be the MAC address of that host. For hosts on other LAN segments it will be the MAC address of the adjacent (upstream or downstream) router carrying the traffic flow.
流量測定は、イーサネットLAN【802から3]上のネットワーク層としてIPを使用して実行されている場合、例えば、隣接するアドレスは、通常、6オクテットのMAC（Media Access Control）アドレスであろう。メータと同じLANセグメントに接続されたホストのための隣接アドレスは、ホストのMACアドレスになります。他のLANセグメント上のホストのためには、トラフィックフローを運ぶ隣接（上流または下流）ルータのMACアドレスになります。
- The PEER ADDRESS, which identifies the source or destination of the packet for the network layer (n) at which traffic measurement is being performed. The form of a peer address will depend on the network-layer protocol in use, and the measurement network layer (n).
- トラフィック測定が行われている時、ネットワーク層（n）のためのパケットの送信元または宛先を識別するピアアドレス、。ピアアドレスの形式は、使用中のネットワーク層プロトコル、および計測ネットワーク層（n）に依存するであろう。
- The TRANSPORT ADDRESS, which identifies the source or destination port for the packet, i.e. its (n+1) layer address. For example, if flow measurement is being performed at the IP layer a transport address is a two-octet UDP or TCP port number.
- パケットの送信元または宛先ポートを識別するトランスポート・アドレス、すなわちその（N + 1）層アドレス。流量測定は、IPレイヤで実行されている場合、例えば、トランスポート・アドレスは、2オクテットのUDPまたはTCPポート番号です。
The four definitions above specify addresses for each of the four lowest layers of the OSI reference model, i.e. Physical layer, Link layer, Network layer and Transport layer. A FLOW RECORD stores both the VALUE for each of its addresses (as described above) and a MASK specifying which bits of the address value are being used and which are ignored. Note that if address bits are being ignored the meter will set them to zero, however their actual values are undefined.
上記の4つの定義は、OSI参照モデル、すなわち物理層、リンク層、ネットワーク層とトランスポート層の4つの最下位層のそれぞれのアドレスを指定します。アドレス値のビットが使用されて、そのアドレスの各々についてのフローレコードを格納する値の両方（上記のように）マスク指定は無視されます。しかし、彼らの実際の値は未定義で、アドレスビットは無視されている場合はメーターがゼロにそれらを設定することに注意してください。
One of the key features of the traffic measurement architecture is that attributes have essentially the same meaning for different protocols, so that analysis applications can use the same reporting formats for all protocols. This is straightforward for peer addresses; although the form of addresses differs for the various protocols, the meaning of a 'peer address' remains the same. It becomes harder to maintain this correspondence at higher layers - for example, at the Network layer IP, Novell IPX and AppleTalk all use port numbers as a 'transport address', but CLNP and DECnet have no notion of ports.
トラフィック測定アーキテクチャの重要な特徴の一つは、解析アプリケーションは、すべてのプロトコルに対して同一の報告フォーマットを使用できるように、属性は、本質的に異なるプロトコルについて同じ意味を持っているということです。これは、ピアアドレスのために簡単です。アドレスの形式は、さまざまなプロトコルのために異なるが、「ピアアドレス」の意味は同じまま。例えば、ネットワーク層IP、ノベルIPXおよびAppleTalkですべてが「トランスポートアドレス」とポート番号を使用しますが、CLNPとのDECnetは、ポートの概念を持っていない - それは上位層ではこの対応を維持することが難しくなります。
Reporting by adjacent intermediate sources and destinations or simply by meter interface (most useful when the meter is embedded in a router) supports hierarchical Internet reporting schemes as described in the 'Internet Accounting Background' RFC [ACT-BKG]. That is, it allows backbone and regional networks to measure usage to just the next lower level of granularity (i.e. to the regional and stub/enterprise levels, respectively), with the final breakdown according to end user (e.g. to source IP address) performed by the stub/enterprise networks.
隣接する中間ソースおよび宛先によって、または単にメータインターフェース（計をルータに埋め込まれている場合に最も有用である）で報告する「インターネット会計背景」RFC [ACT-BKG]で説明されるように階層インターネット報告スキームをサポートします。すなわち、それは実行（例えば、送信元IPアドレスに）エンドユーザに応じて最終的な分解と、（それぞれ、すなわち地域及びスタブ/エンタープライズレベルに）骨格と地域ネットワークは、粒状のちょうど次の低いレベルに使用量を測定することを可能にしますスタブ/企業ネットワークによります。
In cases where network addresses are dynamically allocated (e.g. dial-in subscribers), further subscriber identification will be necessary if flows are to ascribed to individual users. Provision is made to further specify the metered traffic group through the use of an optional SUBSCRIBER ID as part of the flow id. A subscriber ID may be associated with a particular flow either through the current rule set or by unspecified means within a meter. At this time a subscriber ID is an arbitrary text string; later versions of the architecture may specify details of its contents.
フローは、個々のユーザに起因することがある場合は、ネットワークアドレスが動的に割り当てられている場合には（例えばダイヤルイン加入者）、さらに加入者識別が必要であろう。規定は、さらに、フローIDの一部として任意加入者IDの使用を介して計量トラフィック・グループを指定するために行われます。加入者IDは、現在のルールセットを介して、または計器内の不特定の手段のいずれかによって特定のフローに関連付けられてもよいです。この時、加入者IDは、任意のテキスト文字列です。アーキテクチャのそれ以降のバージョンは、その内容の詳細を指定することもできます。
GRANULARITY is the 'control knob' by which an application and/or the meter can trade off the overhead associated with performing usage reporting against its level of detail. A coarser granularity means a greater level of aggregation; finer granularity means a greater level of detail. Thus, the number of flows measured (and stored) at a meter can be regulated by changing the granularity of their attributes. Flows are like an adjustable pipe - many fine-granularity streams can carry the data with each stream measured individually, or data can be bundled in one coarse-granularity pipe. Time granularity may be controlled by varying the reporting interval, i.e. the time between meter readings.
粒度は、アプリケーション及び/又は計器の詳細のそのレベルに対して利用状況レポートの実行に関連するオーバーヘッドをトレードオフすることができることにより、「制御ノブ」です。粗い粒度は、凝集のより高いレベルを意味します。細かい粒度は、より詳細なレベルを意味します。従って、計器で測定（及び記憶）フローの数は、その属性の粒度を変更することによって調節することができます。フローは、調整可能なパイプのようなもの - 多くの細粒度のストリームは、個別に測定された各ストリームとの間でデータを運ぶことができる、またはデータが1つの粗粒度のパイプにバンドルすることができます。時間粒度は、報告間隔、メータの読み取りの間、すなわち時間を変えることによって制御することができます。
Flow granularity is controlled by adjusting the level of detail for the following:
フローの粒度は、以下の詳細レベルを調整することによって制御されます。
- The metered traffic group (address attributes, discussed above).
- 計量されたトラフィック・グループ（アドレス属性は、上述しました）。
- The categorisation of packets (other attributes, discussed below).
- パケットの分類（他の属性は、以下で説明します）。
- The lifetime/duration of flows (the reporting interval needs to be short enough to measure them with sufficient precision).
- フローの存続期間/時間（レポートインターバルが十分な精度でそれらを測定するのに十分に短くする必要があります）。
The set of rules controlling the determination of each packet's metered traffic group is known as the meter's CURRENT RULE SET. As will be shown, the meter's current rule set forms an integral part of the reported information, i.e. the recorded usage information cannot be properly interpreted without a definition of the rules used to collect that information.
各パケットの計量されたトラフィック・グループの決意を制御するルールのセットは、メーターの現在のルールセットとして知られています。示されるように、測定器の現在のルールセットは、記録された使用情報が正しく、その情報を収集するために使用されるルールを定義することなく解釈することができない、すなわち報告された情報の不可欠な部分を形成します。
Settings for these granularity factors may vary from meter to meter. They are determined by the meter's current rule set, so they will change if network Operations personnel reconfigure the meter to use a new rule set. It is expected that the collection rules will change rather infrequently; nonetheless, the rule set in effect at any time must be identifiable via a RULE SET NUMBER. Granularity of metered traffic groups is further specified by additional ATTRIBUTES. These attributes include:
これらの粒度係数の設定はメートルからメートルに異なる場合があります。ネットワーク運用担当者が新しいルールセットを使用するようにメーターを再構成した場合、彼らが変更されますので、彼らは、メーターの現在のルールセットによって決定されます。収集ルールではなく、まれに変更されることが期待されます。それにもかかわらず、任意の時点で有効に設定されたルールは、ルール・セット番号で識別できる必要があります。計量されたトラフィック・グループの粒度は、さらに追加の属性によって指定されます。これらの属性は、次のとおりです。
- Attributes which record information derived from other attribute values. Six of these are defined (SourceClass, DestClass, FlowClass, SourceKind, DestKind, FlowKind), and their meaning is determined by the meter's rule set. For example, one could have a subroutine in the rule set which determined whether a source or destination peer address was a member of an arbitrary list of networks, and set SourceClass/DestClass to one if the source/dest peer address was in the list or to zero otherwise.
- 他の属性値から得られた情報を記録属性。これらのシックス（sourceClassを、DestClass、FlowClass、SourceKind、DestKind、FlowKind）に定義されており、その意味は、メーターのルールセットによって決定されます。例えば、一つのソースまたは宛先ピアアドレスは、ネットワークの任意のリストのメンバーであったか否かが判定ルール・セット内のサブルーチンを有することができ、及びソース/ DESTピアアドレスがリストにあった場合のいずれかにsourceClassを/ DestClassを設定したりそれ以外の場合はゼロに。
- Administratively specified attributes such as Quality of Service and Priority, etc. These are not defined at this time.
- などこれらのサービスの品質と優先順位、など行政指定された属性は、この時点で定義されていません。
Settings for these granularity factors may vary from meter to meter. They are determined by the meter's current rule set, so they will change if Network Operations personnel reconfigure the meter to use a new rule set.
これらの粒度係数の設定はメートルからメートルに異なる場合があります。ネットワークオペレーション担当者が新しいルールセットを使用するようにメーターを再構成した場合、彼らが変更されますので、彼らは、メーターの現在のルールセットによって決定されます。
A rule set can aggregate groups of addresses in two ways. The simplest is to use a mask in a single rule to test for an address within a masked group. The other way is to use a sequence of rules to test for an arbitrary group of (masked) address values, then use a PushRuleTo rule to set a derived attribute (e.g. FlowKind) to indicate the flow's group.
ルールセットは、2つの方法でアドレスのグループを集約することができます。最も単純には、マスクされたグループ内のアドレスをテストするために、単一のルールでマスクを使用することです。他の方法は、フローのグループを示すように誘導される属性（例えばFlowKind）を設定するPushRuleToルールを使用し、（マスク）アドレス値の任意のグループをテストするためにルールの配列を使用することです。
The LIFETIME of a flow is the time interval which began when the meter observed the first packet belonging to the flow and ended when it saw the last packet. Flow lifetimes are very variable, but many - if not most - are rather short. A meter cannot measure lifetimes directly; instead a meter reader collects usage data for flows which have been active since the last collection, and an analysis application may compare the data from each collection so as to determine when each flow actually stopped.
流れのLIFETIMEはメーターは、フローに属する第1のパケットを観察し、それが最後のパケットを見たときに終了したときに開始した時間間隔です。フローの寿命は非常に変数が、多くある - ないほとんどの場合 - かなり短いです。メーターは直接寿命を測定することはできません。代わりメーター読者は、最後の収集以降にアクティブであったフローの利用データを収集し、各フローが実際に停止したときに決定するように解析アプリケーションは、各コレクションからのデータを比較することができます。
The meter does, however, need to reclaim memory (i.e. records in the flow table) being held by idle flows. The meter configuration includes a variable called InactivityTimeout, which specifies the minimum time a meter must wait before recovering the flow's record. In addition, before recovering a flow record the meter should be sure that the flow's data has been collected by all meter readers which registered to collect it. These two wait conditions are desired goals for the meter; they are not difficult to achieve in normal usage, however the meter cannot guarantee to fulfil them absolutely.
メータは、しかし、（すなわち、フローテーブルのレコード）がアイドル流れによって保持されているメモリを解放する必要がありません。メーターの設定はメーターが、フローの記録を回復する前に待機しなければならない最小時間を指定しInactivityTimeoutと呼ばれる変数が含まれています。また、フローレコードを回復する前に、メーターは、フローのデータは、それを収集するために登録されているすべてのメーター読者によって収集されていることを確認する必要があります。これら二つの待ち条件がメーターの目標を望まれています。彼らは、しかし、メーターは絶対にそれらを満たすために保証することはできません、通常の使用で達成することは困難ではありません。
These 'lifetime' issues are considered further in the section on meter readers (below). A complete list of the attributes currently defined is given in Appendix C later in this document.
これらの「寿命」の問題は、検針（下記）のセクションでさらに考えられています。現在定義された属性の完全なリストは、このドキュメントの後半の付録Cに記載されています。
Once a usage record is sent, the decision needs to be made whether to clear any existing flow records or to maintain them and add to their counts when recording subsequent traffic on the same flow. The second method, called rolling counters, is recommended and has several advantages. Its primary advantage is that it provides greater reliability - the system can now often survive the loss of some usage records, such as might occur if a meter reader failed and later restarted. The next usage record will very often contain yet another reading of many of the same flow buckets which were in the lost usage record. The 'continuity' of data provided by rolling counters can also supply information used for "sanity" checks on the data itself, to guard against errors in calculations.
使用状況レコードが送信されると、決定は、既存のフローレコードをクリアするか、同じフローに後続のトラフィックを記録するときにそれらを維持し、そのカウントに追加するかどうかの判断がなされる必要があります。ローリングカウンタと呼ばれる第二の方法は、推奨およびいくつかの利点を持っています。その主な利点は、より高い信頼性を提供することである - システムは現在、多くの場合、メーター読者が失敗した後に再起動した場合に発生する可能性があるとして、いくつかの使用状況レコードの損失を生き残ることができます。次の使用実績は、非常に多くの場合、失われた使用履歴にあった同じ流れバケットの多くのさらに別の読み取りが含まれています。ローリングカウンタによって提供されたデータの「連続性」も計算にエラーを防ぐために、データ自体の「健全性」を確認するために使用される情報を供給することができます。
The use of rolling counters does introduce a new problem: how to distinguish a follow-on flow record from a new flow record. Consider the following example.
新しいフローレコードから後続のフローレコードを区別するための方法：ローリングカウンタの使用は、新たな問題を紹介しません。次の例を考えてみましょう。
CONTINUING FLOW OLD FLOW, then NEW FLOW
その後、FLOW FLOW OLD、NEW FLOWを継続
start time = 1 start time = 1 Usage record N: flow count = 2000 flow count = 2000 (done)
起動時間= 1、開始時間= 1つの使用法レコードN：フロー数= 2000、フロー数= 2000（行われます）
start time = 1 start time = 5 Usage record N+1: flow count = 3000 new flow count = 1000
起動時間= 1、開始時間= 5使用法レコードN + 1：フロー数= 3000新しいフロー数= 1000
Total count: 3000 3000
合計数：3000 3000
In the continuing flow case, the same flow was reported when its count was 2000, and again at 3000: the total count to date is 3000. In the OLD/NEW case, the old flow had a count of 2000. Its record was then stopped (perhaps because of temporary idleness), but then more traffic with the same characteristics arrived so a new flow record was started and it quickly reached a count of 1000. The total flow count from both the old and new records is 3000.
そのカウントが3000で再び2000年だった、とするとき継続フローの場合には、同一のフローが報告された。これまでの総数は、OLD / NEW場合は3000で、古いフローは、そのレコードが続いた2000年のカウントを持っていました（恐らくは一時的アイドルの）停止しますが、同じ特性を持つ、より多くのトラフィックがので、新しいフローレコードが開始された到着し、それはすぐに、新旧両方の記録から総流量のカウントが3000で1000のカウントに達しました。
The flow START TIMESTAMP attribute is sufficient to resolve this. In the example above, the CONTINUING FLOW flow record in the second usage record has an old FLOW START timestamp, while the NEW FLOW contains a recent FLOW START timestamp. A flow which has sporadic bursts of activity interspersed with long periods of inactivity will produce a sequence of flow activity records, each with the same set of address attributes, but with increasing FLOW START times.
フロー開始タイムスタンプ属性は、この問題を解決するのに十分です。新しいフローが最近FLOWのSTARTタイムスタンプが含まれていながら、上記の例では、第2の使用実績の継続的FLOWフローレコードは、古いFLOWのSTARTタイムスタンプを持っています。長期の休止が点在活動の散発的なバーストを持つフローは、各アドレス属性の同じセットを持つが、増加FLOW START時間で、フロー・アクティビティレコードのシーケンスを生成します。
Each packet is counted in at most one flow for each running ruleset, so as to avoid multiple counting of a single packet. The record of a single flow is informally called a "bucket." If multiple, sometimes overlapping, records of usage information are required (aggregate, individual, etc), the network manager should collect the counts in sufficiently detailed granularity so that aggregate and combination counts can be reconstructed in post-processing of the raw usage data. Alternatively, multiple rulesets could be used to collect data at different granularities.
単一のパケットの複数のカウントを回避するために、各パケットは、実行中の各ルールセットのために最大1つのフローにカウントされます。単一のフローの記録は非公式に「バケット」と呼ばれています。使用情報の、時には重複、複数のレコードが（集約、個人など）が要求される場合に骨材と組み合わせカウントが生使用データの後処理中に再構成することができるように、ネットワーク管理者は十分に詳細な粒度でカウントを収集しなければなりません。あるいは、複数のルールセットは、異なる粒度でデータを収集するために使用することができます。
For example, consider a meter from which it is required to record both 'total packets coming in interface #1' and 'total packets arriving from any interface sourced by IP address = a.b.c.d', using a single rule set. Although a bucket can be declared for each case, it is not clear how to handle a packet which satisfies both criteria. It must only be counted once. By default it will be counted in the first bucket for which it qualifies, and not in the other bucket. Further, it is not possible to reconstruct this information by post-processing. The solution in this case is to define not two, but THREE buckets, each one collecting a unique combination of the two criteria:
例えば、単一のルールセットを用いて、および「IPアドレス= A.B.C.Dによって供給任意のインタフェースから到着するパケット合計」 'インタフェース＃1に来て、合計パケットの両方を記録するために必要とされた計器を考えます。バケットはそれぞれのケースのために宣言することができますが、両方の基準を満たすパケットを処理する方法は明らかではありません。それは一度だけカウントされなければなりません。デフォルトでは、それは資格れる最初のバケットではなく、他のバケットにカウントされます。さらに、後加工することによって、この情報を再構築することはできません。この場合の解決策は、二つの基準のユニークな組み合わせを収集それぞれをしない2つが、3つのバケットを定義することです。
Bucket 1: Packets which came in interface 1,
AND were sourced by IP address a.b.c.d
Bucket 2: Packets which came in interface 1, AND were NOT sourced by IP address a.b.c.d
バケツ2：インタフェース1に来て、IPアドレスA.B.C.Dによって供給されなかったパケット
Bucket 3: Packets which did NOT come in interface 1, AND were sourced by IP address a.b.c.d
バケツ3：インタフェース1に来なかったし、IPアドレスA.B.C.Dによって供給されたパケット
(Bucket 4: Packets which did NOT come in interface 1, AND were NOT sourced by IP address a.b.c.d)
（バケット4：インタフェース1に来なかったし、IPアドレスA.B.C.Dによって供給されなかったパケット）
The desired information can now be reconstructed by post-processing. "Total packets coming in interface 1" can be found by adding buckets 1 & 2, and "Total packets sourced by IP address a.b.c.d" can be found by adding buckets 1 & 3. Note that in this case bucket 4 is not explicitly required since its information is not of interest, but it is supplied here in parentheses for completeness.
所望の情報は、現在の後処理によって再構成することができます。 「インタフェース1に来る総パケットは」「IPアドレスABCDによって供給総パケット」バケツ1＆2、およびを添加することによって求めることができるバケット1＆この場合、バケット4が明示的にので、必要とされないことに留意されたいを追加することによって求めることができますその情報は、関心のあるではありませんが、完全を期すために、ここで括弧内に供給されます。
Alternatively, the above could be achieved by running two rule sets (A and B), as follows:
次のように別の方法として、上記二つのルールセット（A及びB）を実行することによって達成することができます。
Bucket 1: Packets which came in interface 1;
counted by rule set A.
Bucket 2: Packets which were sourced by IP address a.b.c.d; counted by rule set B.
バケツ2：IPアドレスA.B.C.Dによって供給されたパケット。ルールセットBによってカウント
4 Meters
4メートル
A traffic flow meter is a device for collecting data about traffic flows at a given point within a network; we will call this the METERING POINT. The header of every packet passing the network metering point is offered to the traffic meter program.
トラフィック流量計は、ネットワーク内の所与の点でのトラフィックフローに関するデータを収集するための装置です。私たちは、このメーターポイントを呼び出します。ネットワーク計量点を通過するすべてのパケットのヘッダは、トラフィックメータープログラムに提供されます。
A meter could be implemented in various ways, including:
メーターは含めて、様々な方法で実現することができます。
- A dedicated small host, connected to a broadcast LAN (so that it can see all packets as they pass by) and running a traffic meter program. The metering point is the LAN segment to which the meter is attached.
- 専用の小型（彼らが通るよう、それはすべてのパケットを見ることができるように）放送LANに接続されたホスト、およびトラフィックメータープログラムを実行しています。計量点は、メータが取り付けられたLANセグメントです。
- A multiprocessing system with one or more network interfaces, with drivers enabling a traffic meter program to see packets. In this case the system provides multiple metering points - traffic flows on any subset of its network interfaces can be measured.
- ドライバがパケットを見るために、トラフィックメータープログラムを可能にするとともに1つ以上のネットワークインターフェースを有するマルチプロセッシングシステム。この場合、システムは、複数の計量点を提供し - トラフィックを測定することができ、そのネットワーク・インターフェースのサブセットに流れます。
- A packet-forwarding device such as a router or switch. This is similar to (b) except that every received packet should also be forwarded, usually on a different interface.
- そのようなルータやスイッチなどのパケット転送装置。これは、すべての受信パケットはまた、通常、異なるインタフェース上で、転送されるべきであることを除いて（B）と同様です。
An outline of the meter's structure is given in the following diagram:
メーターの構造の概要を次の図に示されています。
Briefly, the meter works as follows:
次のように簡単に言えば、メーターが動作します：
- Incoming packet headers arrive at the top left of the diagram and are passed to the PACKET PROCESSOR.
- 着信パケットのヘッダは、図の左上に到着するとパケットプロセッサに渡されます。
- The packet processor passes them to the Packet Matching Engine (PME) where they are classified.
- パケットプロセッサは、それらが分類されているパケットマッチングエンジン（PME）に渡します。
- The PME is a Virtual Machine running a pattern matching program contained in the CURRENT RULE SET. It is invoked by the Packet Processor, executes the rules in the current rule set as described in section 4.3 below, and returns instructions on what to do with the packet.
- PMEは、現在のルールセットに含まれるパターンマッチングプログラムを実行している仮想マシンです。これは、パケットプロセッサによって呼び出され、以下のセクション4.3で説明されるように設定された現在のルールでルールを実行し、パケットをどうするかの指示を返します。
- Some packets are classified as 'to be ignored'. They are discarded by the Packet Processor.
- 「は無視される」として、一部のパケットが分類されています。これらは、パケットプロセッサによって破棄されています。
- Other packets are matched by the PME, which returns a FLOW KEY describing the flow to which the packet belongs.
- その他のパケットは、パケットが属するフローを説明するフローキーを返しPMEにより一致しています。
- The flow key is used to locate the flow's entry in the FLOW TABLE; a new entry is created when a flow is first seen. The entry's data fields (e.g. packet and byte counters) are updated.
- フロー・キーは、フローテーブルのフローのエントリを検索するために使用されます。流れが最初に見たときに新しいエントリが作成されます。エントリのデータフィールド（例えば、パケットとバイトカウンタが）更新されます。
- A meter reader may collect data from the flow table at any time. It may use the 'collect' index to locate the flows to be collected within the flow table.
- メーター読者はいつでもフローテーブルからデータを収集することができます。これは、フローテーブル内で収集される流れを検索するために「収集」インデックスを使用してもよいです。
packet +------------------+
header | Current Rule Set |
| +--------+---------+
| |
| |
+-------*--------+ 'match key' +------*-------+
| Packet |---------------->| Packet |
| Processor | | Matching |
| |<----------------| Engine |
+--+----------+--+ 'flow key' +--------------+
| |
| |
Ignore * | Count (via 'flow key')
|
+--*--------------+
| 'Search' index |
+--------+--------+
|
+--------*--------+
| |
| Flow Table |
| |
+--------+--------+
|
+--------*--------+
| 'Collect' index |
+--------+--------+
|
*
Meter Reader
The discussion above assumes that a meter will only be running a single rule set. A meter may, however, run several rule sets concurrently. To do this the meter maintains a table of current rulesets. The packet processor matches each packet against every current ruleset, producing a single flow table containing flows from all the rule sets. One way to implement this is to use the Rule Set Number attribute in each flow as part of the flow key.
上記の議論は、メーターは、単一のルールセットを実行していることを想定しています。メーターは、しかし、同時にいくつかのルールセットを実行することができます。これを行うにはメーターは、現在のルールセットのテーブルを維持します。パケットプロセッサは、全てのルールセットからのフローを含む単一のフローテーブルを生成し、すべての現在のルールセットに対して、各パケットに一致します。これを実現する1つの方法は、フローキーの一部として、各フローにルールセットNumber属性を使用することです。
A packet may only be counted once in a rule set (as explained in section 3.3 above), but it may be counted in any of the current rulesets. The overall effect of doing this is somewhat similar to running several independent meters, one for each rule set.
パケットは、（上記セクション3.3で説明したように）だけルールセットに一度にカウントすることができるが、それは、現在のルールセットのいずれかでカウントしてもよいです。これを行うための全体的な効果は、いくつかの独立したメートル、各ルール・セットのいずれかを実行することに幾分類似しています。
Every traffic meter maintains 'flow table', i.e. a table of TRAFFIC FLOW RECORDS for flows seen by the meter. Details of how the flow table is maintained are given in section 4.5 below. A flow record contains attribute values for its flow, including:
すべてのトラフィックメータは、「フローテーブル」、メーターで見フローのトラフィックフローRECORDSのすなわちテーブルを維持します。フローテーブルが維持される方法の詳細は、以下のセクション4.5に記載されています。 ：フローレコードには、その流れの属性値が含まれています
- Addresses for the flow's source and destination. These include addresses and masks for various network layers (extracted from the packet header), and the identity of the interface on which the packet was observed.
- フローの送信元と送信先のアドレス。これらは、アドレスおよび（パケットヘッダから抽出された）は、種々のネットワーク層のためのマスク、及びパケットが観測されたインターフェースの識別を含みます。
- First and last times when packets were seen for this flow.
- まず、パケットがこの流れのために見られた最後の回。
- Counts for 'forward' (source to destination) and 'backward' (destination to source) components of the flow's traffic.
- 「前方」のカウント（目的地へのソース）とフローのトラフィックの「後方」（ソースへの宛先）のコンポーネント。
- Other attributes, e.g. state of the flow record (discussed below).
- 他の属性、例えばフローレコードの状態（後述）。
The state of a flow record may be:
フローレコードの状態は次のようになります。
- INACTIVE: The flow record is not being used by the meter.
- INACTIVE：フローレコードは計で使用されていません。
- CURRENT: The record is in use and describes a flow which belongs to the 'current flow set', i.e. the set of flows recently seen by the meter.
- CURRENT：レコードが使用中であると「現在のフローセット」、最近計で見フロー即ち集合に属するフローを記述する。
- IDLE: The record is in use and the flow which it describes is part of the current flow set. In addition, no packets belonging to this flow have been seen for a period specified by the meter's InactivityTime variable.
- IDLE：レコードが使用中であり、それは説明の流れは電流の流れセットの一部です。また、このフローに属する一切のパケットは、メーターのInactivityTime変数で指定された期間に見られていません。
Each packet header received by the traffic meter program is processed as follows:
次のようにトラフィックメータープログラムによって受信された各パケットのヘッダが処理されます。
- Extract attribute values from the packet header and use them to create a MATCH KEY for the packet.
- パケットのヘッダから属性値を抽出し、パケットのMATCHキーを作成するためにそれらを使用しています。
- Match the packet's key against the current rule set, as explained in detail below.
- 以下に詳細に説明するように、現在のルールセットに対してパケットのキーと一致します。
The rule set specifies whether the packet is to be counted or ignored. If it is to be counted the matching process produces a FLOW KEY for the flow to which the packet belongs. This flow key is used to find the flow's record in the flow table; if a record does not yet exist for this flow, a new flow record may be created. The data for the matching flow record can then be updated.
ルールセットは、パケットがカウントされたり、無視されるかどうかを指定します。それはカウントする場合のマッチング処理は、パケットが属するフローのためのフローキーを生成します。この流れキーは、フローテーブル内の流れのレコードを検索するために使用されます。記録は、まだこの流れのために存在しない場合は、新しいフローレコードを作成することができます。マッチング・フロー・レコードのデータが更新することができます。
For example, the rule set could specify that packets to or from any host in IP network 130.216 are to be counted. It could also specify that flow records are to be created for every pair of 24-bit (Class C) subnets within network 130.216.
例えば、ルールセットは、またはIPネットワーク130.216内の任意のホストからのパケットをカウントすることを指定することができます。また、フローレコードは、ネットワーク130.216内の24ビット（クラスC）のサブネットのすべてのペアのために作成されることを指定することができます。
Each packet's match key is passed to the meter's PATTERN MATCHING ENGINE (PME) for matching. The PME is a Virtual Machine which uses a set of instructions called RULES, i.e. a RULE SET is a program for the PME. A packet's match key contains source (S) and destination (D) interface identities, address values and masks.
各パケットのマッチキーがマッチングのためのメーターのパターンマッチングエンジン（PME）に渡されます。 PMEは、すなわち、ルール・セットがPMEのためのプログラムである、ルールと呼ばれる一連の命令を使用して仮想マシンです。パケットの照合キーは、ソース（S）と宛先（D）インターフェイスのID、アドレス値とマスクが含まれています。
If measured flows were unidirectional, i.e. only counted packets travelling in one direction, the matching process would be simple. The PME would be called once to match the packet. Any flow key produced by a successful match would be used to find the flow's record in the flow table, and that flow's counters would be updated.
測定された流れは、一方向に走行即ちのみカウントパケット一方向であった場合、マッチング処理は簡単であろう。 PMEは、パケットを一致させるために一度呼び出されます。成功した試合で生成どれフローキーは、フローテーブルにフローのレコードを検索するために使用されるだろう、とその流れのカウンタが更新されます。
Flows are, however, bidirectional, reflecting the forward and reverse packets of a protocol interchange or 'session'. Maintaining two sets of counters in the meter's flow record makes the resulting flow data much simpler to handle, since analysis programs do not have to gather together the 'forward' and 'reverse' components of sessions. Implementing bi-directional flows is, of course, more difficult for the meter, since it must decide whether a packet is a 'forward' packet or a 'reverse' one. To make this decision the meter will often need to invoke the PME twice, once for each possible packet direction.
流れは、前方反射、しかし、双方向性であり、プロトコル交換又は「セッション」のパケットを逆。解析プログラムは、「前方」とのセッションの「逆」のコンポーネントを一緒に収集する必要はありませんので、メーターのフローレコードにカウンターの二組を維持することは、結果のフローデータを処理するためにはるかに簡単になります。それは、パケットが「前進」パケットまたは「逆」であるかどうかを決定しなければならないので、双方向のフローを実装することは、当然のことながら、メーターのためのより困難です。この決定を行うためにメーターは、多くの場合、それぞれの可能なパケット方向のために1回、2回PMEを起動する必要があります。
The diagram below describes the algorithm used by the traffic meter to process each packet. Flow through the diagram is from left to right and top to bottom, i.e. from the top left corner to the bottom right corner. S indicates the flow's source address (i.e. its set of source address attribute values) from the packet header, and D indicates its destination address.
下の図は、各パケットを処理するために、トラフィックメータで使用するアルゴリズムを説明しています。図流れるすなわち左上隅から右下隅に、左から右、上から下にあります。 Sは、パケットヘッダからの流れのソースアドレス（ソースアドレス属性値の、すなわちそのセット）を示し、Dはその宛先アドレスを示しています。
There are several cases to consider. These are:
考慮すべきいくつかの例があります。これらは：
- The packet is recognised as one which is TO BE IGNORED.
- パケットは無視される一つとして認識されています。
- The packet would MATCH IN EITHER DIRECTION. One situation in which this could happen would be a rule set which matches flows within network X (Source = X, Dest = X) but specifies that flows are to be created for each subnet within network X, say subnets y and z. If, for example a packet is seen for y->z, the meter must check that flow z->y is not already current before creating y->z.
- パケットのいずれかの方向に一致します。これが起こる可能性がある中で一つの状況が一致したルールセットは、（出典= X、destはX =）をネットワークX内を流れるが、フローがネットワークX内の各サブネットのために作成するように指定されるだろう、y、zのサブネットは言います。例えば、パケットは、y軸のために見られ、場合> Z、メーターはその流れをチェックしなければならないのz> yはy軸> Zを作成する前に、すでに最新ではありません。
- The packet MATCHES IN ONE DIRECTION ONLY. If its flow is already current, its forward or reverse counters are incremented. Otherwise it is added to the flow table and then counted.
- パケットが一方向にのみ一致します。その流れは、すでに現在の場合は、その正逆カウンタがインクリメントされています。そうでない場合は、フローテーブルに追加し、次にカウントされます。
Ignore
--- match(S->D) -------------------------------------------------+
| Suc | NoMatch |
| | Ignore |
| match(D->S) -----------------------------------------+
| | Suc | NoMatch |
| | | |
| | +-------------------------------------------+
| | |
| | Suc |
| current(D->S) ---------- count(D->S,r) --------------+
| | Fail |
| | |
| create(D->S) ----------- count(D->S,r) --------------+
| |
| Suc |
current(S->D) ------------------ count(S->D,f) --------------+
| Fail |
| Suc |
current(D->S) ------------------ count(D->S,r) --------------+
| Fail |
| |
create(S->D) ------------------- count(S->D,f) --------------+
|
*
The algorithm uses four functions, as follows:
次のようなアルゴリズムは、4つの機能を使用しています。
match(A->B) implements the PME. It uses the meter's current rule set to match the attribute values in the packet's match key. A->B means that the assumed source address is A and destination address B, i.e. that the packet was travelling from A to B. match() returns one of three results:
マッチ（A-> B）は、PMEを実装します。これは、パケットのマッチキーの属性値と一致するようにメーターの現在のルールセットを使用しています。 A-> B）は（想定送信元アドレスは、パケットがBに一致するように走行していること、すなわち、A及び宛先アドレスBであることを意味する3つの結果のいずれかを戻します。
'Ignore' means that the packet was matched but this flow is not to be counted.
「無視」は、パケットが一致したことを意味しますが、この流れはカウントされません。
'NoMatch' means that the packet did not match. It might, however match with its direction reversed, i.e. from B to A.
「NOMATCH」は、パケットが一致しなかったことを意味します。その方向が逆で、それは、しかし、すなわちBからAへ、一致する可能性があります
'Suc' means that the packet did match, i.e. it belongs to a flow which is to be counted.
「のSuc」はパケットが一致したことを意味し、すなわち、それはカウントされるべきフローに属しています。
current(A->B) succeeds if the flow A-to-B is current - i.e. has a record in the flow table whose state is Current - and fails otherwise.
すなわち、状態電流Isフローテーブル内のレコードを持っています - - そうでなければ失敗したフローA対Bが電流である場合、現在の（A-> B）は成功します。
create(A->B) adds the flow A-to-B to the flow table, setting the value for attributes - such as addresses - which remain constant, and zeroing the flow's counters.
そのようなアドレスなど - - 一定のままであり、流れのカウンタをゼロに作成する（A-> B）は、属性の値を設定し、フローテーブルにフローA対Bを付加します。
count(A->B,f) increments the 'forward' counters for flow A-to-B. count(A->B,r) increments the 'reverse' counters for flow A-to-B. 'Forward' here means the counters for packets travelling from A to B. Note that count(A->B,f) is identical to count(B->A,r).
カウント（A-> Bは、f）はフローA対Bのための「フォワード」カウンタをインクリメントします。フローA対Bのための「逆」カウンタをインクリメントする（A-> B、r）を数えます。 「フォワード」ここでは、（B-> A、r）をカウントするために同一である（F、A-> B）をカウントB.への注意から移動するパケットのカウンタを意味します。
When writing rule sets one must remember that the meter will normally try to match each packet in the reverse direction if the forward match does not succeed. It is particularly important that the rule set does not contain inconsistencies which will upset this process.
書くときのルールは、1つのメーターが通常は前方一致が成功しない場合は逆方向に、各パケットに一致するようにしようとすることを覚えておく必要があります設定します。ルールセットは、このプロセスを混乱させるだろう矛盾を含んでいないことが特に重要です。
Consider, for example, a rule set which counts packets from source network A to destination network B, but which ignores packets from source network B. This is an obvious example of an inconsistent rule set, since packets from network B should be counted as reverse packets for the A-to-B flow.
例えば、宛先ネットワークBに元ネットワークAからのパケットをカウントルールセットを考えるが、どのネットワークBからのパケットを逆としてカウントされるべきであるので、これは、矛盾するルールセットの明らかな例であるソースネットワークBからパケットを無視A対Bのフローのためのパケット。
This problem could be avoided by devising a language for specifying rule files and writing a compiler for it, thus making it much easier to produce correct rule sets. An example of such a language is described in the 'SRL' document [RTFM-SRL]. Another approach would be to write a 'rule set consistency checker' program, which could detect problems in hand-written rule sets.
この問題は、このように、それははるかに簡単に正しいルール・セットを生成すること、ルールファイルを指定し、そのためのコンパイラを書くための言語を工夫することによって回避することが可能です。そのような言語の例は、「SRL」ドキュメント[RTFM-SRL]に記載されています。別のアプローチは、手書きのルールセットに問題を検出することができた「ルールセットの整合性チェッカー」プログラムを書くことであろう。
Normally, the best way to avoid these problems is to write rule sets which only classify flows in the forward direction, and rely on the meter to handle reverse-travelling packets.
通常、これらの問題を回避する最善の方法は、順方向に流れを分類し、逆移動するパケットを処理するためにメーターに依存しているルールセットを記述することです。
Occasionally there can be situations when a rule set needs to know the direction in which a packet is being matched. Consider, for example, a rule set which wants to save some attribute values (source and destination addresses perhaps) for any 'unusual' packets. The rule set will contain a sequence of tests for all the 'usual' source addresses, follwed by a rule which will execute a 'NoMatch' action. If the match fails in the S->D direction, the NoMatch action will cause it to be retried. If it fails in the D->S direction, the packet can be counted as an 'unusual' packet.
ルールセットは、パケットが一致している方向を知る必要があるとき時折状況が存在することができます。例えば、任意の「珍しい」パケットのためのいくつかの属性値（おそらく、送信元と送信先のアドレス）を保存したいルールセットを考えてみましょう。ルールセットは、「NOMATCH」アクションを実行するルールによってfollwedすべての「通常の」送信元アドレスのための一連のテストを、含まれています。試合は、S-> D方向に失敗した場合、NOMATCHアクションは、それが再試行されます。それはD-> S方向に失敗した場合、パケットは「珍しい」パケットとしてカウントすることができます。
To count such an 'unusual' packet we need to know the matching direction: the MatchingStoD attribute provides this. To use it, one follows the source address tests with a rule which tests whether the matching direction is S->D (MatchingStoD value is 1). If so, a 'NoMatch' action is executed. Otherwise, the packet has failed to match in both directions; we can save whatever attribute values are of interest and count the 'unusual' packet.
私たちは、一致する方向を知る必要があり、そのような「珍しい」パケットをカウントするには、次のMatchingStoD属性がこれを提供します。それを使用するためには、整合方向かどうかをテストルールに送信元アドレス試験を以下S-> D（MatchingStoD値が1である）です。その場合は、「NOMATCH」アクションが実行されます。そうでない場合、パケットは両方の方向に一致させるために失敗しました。我々は、値が関心のあるものは何でも属性保存し、「異例の」パケットをカウントすることができます。
A rule set is an array of rules. Rule sets are held within a meter as entries in an array of rule sets.
ルールセットは、ルールの配列です。ルールセットは、ルールセットのアレイ内のエントリとして計器内に保持されています。
Rule set 1 (the first entry in the rule set table) is built-in to the meter and cannot be changed. It is run when the meter is started up, and provides a very coarse reporting granularity; it is mainly useful for verifying that the meter is running, before a 'useful' rule set is downloaded to it.
ルールは、メーターに内蔵されており、変更することができない（ルールセットテーブルの最初のエントリ）1セット。メーターが起動し、非常に粗い報告粒度を提供されたときに実行されます。それは便利な "ルールセットがそれにダウンロードされる前に、メーターが、実行されていることを確認するため、主に有用です。
A meter also maintains an array of 'tasks', which specify what rule sets the meter is running. Each task has a 'current' rule set (the one which it normally uses), and a 'standby' rule set (which will be used when the overall traffic level is unusually high). If a task is instructed to use rule set 0, it will cease measuring; all packets will be ignored until another (non-zero) rule set is made current.
メーターはまた、メーターが実行されている設定どのルール指定のタスク 'の配列を維持しています。各タスクは、「現在の」ルール・セット（それが通常使用するもの）、及び（全体的なトラフィックのレベルが異常に高い場合に使用される）「スタンバイ」ルールが設定されています。タスクがルールセット0を使用するように指示されている場合は、測定を中止します。別の（非ゼロの）ルール・セットは、現在行われるまですべてのパケットは無視されます。
Each rule in a rule set is an instruction for the Packet Matching Engine, i.e. it is an instruction for a Virtual Machine. PME instructions have five component fields, forming two logical groups as follows:
ルールセット内の各ルールは、パケットマッチングエンジンのための命令である、すなわち、それは仮想マシンの命令です。 PME命令は、次のように2つの論理グループを形成し、5つのコンポーネントのフィールドを持っています：
+-------- test ---------+ +---- action -----+
attribute & mask = value: opcode, parameter;
The test group allows PME to test the value of an attribute. This is done by ANDing the attribute value with the mask and comparing the result with the value field. Note that there is no explicit provision to test a range, although this can be done where the range can be covered by a mask, e.g. attribute value less than 2048.
テストグループは、PMEは、属性の値をテストすることができます。これは、論理積をとることにより、マスクと属性値を行い、値フィールドで結果を比較しています。範囲は、マスクで覆うことができる場合にこれを行うことができるが、例えば、範囲をテストするための明示的な規定が存在しないことに注意してください2048より小さい値を属性。
The PME maintains a Boolean indicator called the 'test indicator', which determines whether or not a rule's test is performed. The test indicator is initially set (true).
PMEは、ルールのテストが行われたか否かを判断する「テストインジケータ」と呼ばれるブール指標を、維持します。テストインジケータは、最初に（真）に設定されています。
The action group specifies what action may be performed when the rule is executed. Opcodes contain two flags: 'goto' and 'test', as detailed in the table below. Execution begins with rule 1, the first in the rule set. It proceeds as follows:
アクション・グループは、ルールが実行されたときにアクションを実行することができるものを指定します。以下の表に詳述するように、「ジャンプ」と「テスト」：オペコードは、二つのフラグを含みます。実行は、ルール1、ルールセットの最初から始まります。これは次のように進行します：
If the test indicator is true: Perform the test, i.e. AND the attribute value with the mask and compare it with the value. If these are equal the test has succeeded; perform the rule's action (below). If the test fails execute the next rule in the rule set. If there are no more rules in the rule set, return from the match() function indicating NoMatch.
テストインジケータがtrueの場合：テスト、すなわちANDマスクを持つ属性の値を実行し、値と比較します。これらが等しい場合、テストは成功しました。 （下記）ルールのアクションを実行します。テストでは、ルールセット内の次のルールを実行して失敗した場合。ルール・セットに複数のルールが存在しない場合、一致（）関数を示すNOMATCHから戻ります。
If the test indicator is false, or the test (above) succeeded: Set the test indicator to this opcode's test flag value. Determine the next rule to execute. If the opcode has its goto flag set, its parameter value specifies the number of the next rule. Opcodes which don't have their goto flags set either determine the next rule in special ways (Return), or they terminate execution (Ignore, NoMatch, Count, CountPkt). Perform the action.
テストインジケータが偽である、またはテストは、（上記の）成功した場合：このオペコードのテストフラグ値にテストインジケータを設定します。実行するために次のルールを決定します。オペコードがそのジャンプフラグが設定されている場合、そのパラメータ値は、次のルールの数を指定します。どちらか彼らの後藤フラグが設定されている特別な方法（リターン）で次のルールを決定し、またはそれらは（CountPkt、カウント、NOMATCHを無視）の実行を終了していないオペコード。アクションを実行します。
The PME maintains two 'history' data structures. The first, the 'return' stack, simply records the index (i.e. 1-origin rule number) of each Gosub rule as it is executed; Return rules pop their Gosub rule index. Note that when the Ignore, NoMatch, Count and CountPkt actions are performed, PME execution is terminated regardless of whether the PME is executing a subroutine ('return' stack is non-empty) or not.
PMEは、2つの「歴史」データ構造を維持します。それが実行されるように、第1には、「戻る」スタックは、単に各GOSUBルールのインデックス（すなわち、1-原点ルール番号）を記録します。ルールはそのGOSUBルールインデックスをポップ返します。無視、NOMATCH、カウント及びCountPktアクションが実行されるとき、PMEの実行にかかわらずPMEサブルーチンを実行する（「戻る」スタックが空でない）されているか否かの終了したことに留意されたいです。
The second data structure, the 'pattern' queue, is used to save information for later use in building a flow key. A flow key is built by zeroing all its attribute values, then copying attribute number, mask and value information from the pattern queue in the order it was enqueued.
第二のデータ構造、「パターン」キューは、フローキーを構築する際に後で使用するための情報を保存するために使用されています。フロー・キーは、それがエンキューされた順にパターンキューから属性番号、マスクと値の情報をコピーし、そのすべての属性値をゼロにすることによって構築されています。
An attribute number identifies the attribute actually used in a test. It will usually be the rule's attribute field, unless the attribute is a 'meter variable'. Details of meter variables are given after the table of opcode actions below.
属性番号は、実際の試験で使用される属性を識別します。属性は、「メーター変数」でない限り、これは通常、ルールの属性フィールドになります。メーターの変数の詳細については、以下のオペコードのアクションの表の後に与えられています。
The opcodes are:
オペコードは以下のとおりです。
opcode goto test
オペコード後藤テスト
1 Ignore 0 - 2 NoMatch 0 - 3 Count 0 - 4 CountPkt 0 - 5 Return 0 0 6 Gosub 1 1 7 GosubAct 1 0 8 Assign 1 1 9 AssignAct 1 0 10 Goto 1 1 11 GotoAct 1 0 12 PushRuleTo 1 1 13 PushRuleToAct 1 0 14 PushPktTo 1 1 15 PushPktToAct 1 0 16 PopTo 1 1 17 PopToAct 1 0
2 NOMATCH 0 - - 3カウント0から4 CountPkt 0 - 1 0無視0 0 6 5戻るGOSUB 1 7 GosubAct 1 0 8アサイン1 9 AssignAct 1 0 10後藤1 1 11 GotoAct 1 0 12 PushRuleTo 1 1 13 PushRuleToAct 1 0 14 PushPktTo 1 1 15 PushPktToAct 1 0 16 PopTo 1 1 17 PopToAct 1 0
The actions they perform are:
それらが実行するアクションは次のとおりです。
Ignore: Stop matching, return from the match() function indicating that the packet is to be ignored.
無視：一致停止、パケットは無視されるべきであることを示す一致（）関数から戻ります。
NoMatch: Stop matching, return from the match() function indicating failure.
NOMATCH：失敗を示す一致（）関数からの戻り、一致を停止。
Count: Stop matching. Save this rule's attribute number, mask and value in the PME's pattern queue, then construct a flow key for the flow to which this packet belongs. Return from the match() function indicating success. The meter will use the flow key to search for the flow record for this packet's flow.
カウント：マッチングを停止します。その後、このパケットが属するフローのためのフローキーを構築し、PMEのパターン待ち行列にこのルールの属性番号、マスクと値を保存します。成功したことを示す一致（）関数から返します。メーターは、このパケットのフローのためのフローレコードを検索するためのフローキーを使用します。
CountPkt: As for Count, except that the masked value from the packet header (as it would have been used in the rule's test) is saved in the PME's pattern queue instead of the rule's value.
CountPkt：カウントとして、パケットヘッダからマスクされた値は、（それがルールのテストで使用されているように）PMEのパターン待ち行列の代わりに、ルールの値に保存されていることを除いて。
Gosub: Call a rule-matching subroutine. Push the current rule number on the PME's return stack, set the test indicator then goto the specified rule.
GOSUB：ルールマッチングサブルーチンを呼び出します。テストインジケータを設定し、PMEのリターンスタック上に現在のルール番号を押して、指定したルールを後藤。
GosubAct: Same as Gosub, except that the test indicator is cleared before going to the specified rule.
GosubAct：GOSUBと同じ、テストインジケータが指定されたルールに行く前にクリアされることを除いて。
Return: Return from a rule-matching subroutine. Pop the number of the calling gosub rule from the PME's 'return' stack and add this rule's parameter value to it to determine the 'target' rule. Clear the test indicator then goto the target rule.
戻る：ルール照合サブルーチンからの復帰を。 PMEの「復帰」から呼び出すGOSUBルールの数をポップスタックし、「ターゲット」のルールを決定することに、このルールのパラメータ値を追加します。テストインジケータは、ターゲット・ルールを後藤クリア。
A subroutine call appears in a rule set as a Gosub
rule followed by a small group of following rules.
Since a Return action clears the test flag, the
action of one of these 'following' rules will be
executed; this allows the subroutine to return a
result (in addition to any information it may save
in the PME's pattern queue).
Assign: Set the attribute specified in this rule to the parameter value specified for this rule. Set the test indicator then goto the specified rule.
割り当て：このルールに指定されたパラメータ値に、このルールで指定された属性を設定します。テストインジケータが指定するルールを後藤設定します。
AssignAct: Same as Assign, except that the test indicator is cleared before going to the specified rule.
AssignAct：テストインジケータが指定されたルールに行く前にクリアされたことを除いて、割り当てと同じです。
Goto: Set the test indicator then goto the specified rule.
テストインジケータが指定するルールを設定して後藤：後藤。
GotoAct: Clear the test indicator then goto the specified rule.
GotoAct：クリアテストインジケータが指定ルールに進みます。
PushRuleTo: Save this rule's attribute number, mask and value in the PME's pattern queue. Set the test indicator then goto the specified rule.
PushRuleTo：PMEのパターン待ち行列にこのルールの属性番号、マスクと値を保存します。テストインジケータが指定するルールを後藤設定します。
PushRuleToAct: Same as PushRuleTo, except that the test indicator is cleared before going to the specified rule.
PushRuleToAct：テストインジケータが指定されたルールに行く前にクリアされたことを除いて、PushRuleToと同じです。
PushRuleTo actions may be used to save the value
and mask used in a test, or (if the test is not
performed) to save an arbitrary value and mask.
PushPktTo: Save this rule's attribute number, mask, and the masked value from the packet header (as it would have been used in the rule's test), in the PME's pattern queue. Set the test indicator then goto the specified rule.
PushPktTo：PMEのパターンキューに、パケットヘッダ（それはルールのテストで使用されていたであろうと）からこの規則の属性番号、マスク、およびマスクされた値を保存します。テストインジケータが指定するルールを後藤設定します。
PushPktToAct: Same as PushPktTo, except that the test indicator is cleared before going to the specified rule.
PushPktToAct：テストインジケータが指定されたルールに行く前にクリアされたことを除いて、PushPktToと同じです。
PushPktTo actions may be used to save a value from
the packet header using a specified mask. The
simplest way to program this is to use a zero value
for the PushPktTo rule's value field, and to
GoToAct to the PushPktTo rule (so that it's test is
not executed).
PopTo: Delete the most recent item from the pattern queue, so as to remove the information saved by an earlier 'push' action. Set the test indicator then goto the specified rule.
PopTo：以前の「プッシュ」作用により、保存された情報を削除するように、パターンキューから最新のアイテムを削除します。テストインジケータが指定するルールを後藤設定します。
PopToAct: Same as PopTo, except that the test indicator is cleared before going to the specified rule.
PopToAct：テストインジケータが指定されたルールに行く前にクリアされたことを除いて、PopToと同じです。
As well as the attributes applying directly to packets (such as SourcePeerAddress, DestTransAddress, etc.) the PME implements several further attribtes. These are:
ならびに（等SourcePeerAddress、DestTransAddressなど）パケットに直接適用する属性がPMEは、いくつかのさらなるattribtesを実現します。これらは：
Null: Tests performed on the Null attribute always succeed.
ヌル：null属性に対して実行テストはいつも成功します。
MatchingStoD: Indicates whether the PME is matching the packet with its addresses in 'wire order' or with its addresses reversed. MatchingStoD's value is 1 if the addresses are in wire order (StoD), and zero otherwise.
MatchingStoD：PMEは、「ワイヤーため」またはそのアドレスが逆転でそのアドレスを持つパケットをマッチングされるかどうかを示します。 MatchingStoDの値は、アドレスワイヤオーダー（STOD）である場合に1であり、そうでなければゼロ。
v1 .. v5: v1, v2, v3, v4 and v5 are 'meter variables'. They provide a way to pass parameters into rule-matching subroutines. Each may hold the number of a normal attribute; its value is set by an Assign action. When a meter variable appears as the attribute of a rule, its value specifies the actual attribute to be tested. For example, if v1 had been assigned SourcePeerAddress as its value, a rule with v1 as its attribute would actually test SourcePeerAddress.
V1 .. V5：V1、V2、V3、V4とV5は 'メーター変数' です。彼らは、ルール・マッチングサブルーチンにパラメータを渡す方法を提供します。それぞれ、通常の属性の数を保持することができます。その値が割り当てアクションで設定されています。メーター変数がルールの属性として表示されたら、その値が実際の属性をテストすることを指定します。 v1は、その値としてSourcePeerAddressが割り当てられていた場合、例えば、その属性として、V1とのルールが実際にSourcePeerAddressをテストします。
SourceClass, DestClass, FlowClass, SourceKind, DestKind, FlowKind: These six attributes may be set by executing PushRuleTo actions. They allow the PME to save (in flow records) information which has been built up during matching. Their values may be tested in rules; this allows one to set them early in a rule set, and test them later.
sourceClassを、DestClass、FlowClass、SourceKind、DestKind、FlowKind：これらの6つの属性がPushRuleToアクションを実行することで設定することができます。彼らは、PMEは、（フローレコードで）一致の間に構築された情報を保存することができます。これらの値は、ルールで試験することができます。これは1つが早期にルールセットでそれらを設定し、後でそれらをテストすることができます。
The opcodes detailed above (with their above 'goto' and 'test' values) form a minimum set, but one which has proved very effective in current meter implementations. From time to time it may be useful to add further opcodes; IANA considerations for allocating these are set out in section 8 below.
（彼らの上記「ジャンプ」と「テスト」値を有する）上に詳述したオペコードは、最小セットが、電流計の実装に非常に有効であることが証明されているものを形成します。時々さらにオペコードを追加するために有用である可能性があります。これらを割り当てるためのIANA問題は、以下のセクション8に記載されています。
The flow table may be thought of as a 1-origin array of flow records. (A particular implementation may, of course, use whatever data structure is most suitable). When the meter starts up there are no known flows; all the flow records are in the 'inactive' state.
フローテーブルは、フローレコードの1由来の配列と考えることができます。 （特定の実装は、もちろん、使用どんなデータ構造が最も適していることができます）。メーターが起動すると既知のフローは存在しません。すべてのフローレコードは、「非アクティブ」状態になっています。
Each time a packet is matched for a flow which is not in a current flow set a flow record is created for it; the state of such a record is 'current'. When selecting a record for the new flow the meter searches the flow table for an 'inactive' record. If no inactive records are available it will search for an 'idle' one instead. Note that there is no particular significance in the ordering of records within the flow table.
パケットがフローレコードはそれのために作成された設定電流が流れない流れをマッチされるたびに、そのようなレコードの状態は「現在」です。新しいフローのためにレコードを選択するとメーターは「非アクティブ」のレコードのフローテーブルを検索します。非アクティブなレコードが利用できない場合は、代わりに「アイドル」1を検索します。フローテーブル内のレコードの順序には特に意味がないことに注意してください。
A meter's memory management routines should aim to minimise the time spent finding flow records for new flows, so as to minimise the setup overhead associated with each new flow.
メーターのメモリ管理ルーチンは、それぞれの新しい流れに関連したセットアップのオーバーヘッドを最小限にするように、新しいフローのフローレコードを見つけるのに費やす時間を最小限に抑えることを目指すべきです。
Flow data may be collected by a 'meter reader' at any time. There is no requirement for collections to be synchronized. The reader may collect the data in any suitable manner, for example it could upload a copy of the whole flow table using a file transfer protocol, or it could read the records in the current flow set row by row using a suitable data transfer protocol.
フローデータは、任意の時点で「メーター読者によって収集することができます。コレクションを同期するために必要はありません。リーダは、例えば、ファイル転送プロトコルを使用して、全体のフローテーブルのコピーをアップロードすることができ、またはそれは適切なデータ転送プロトコルを使用して行毎に設定された電流の流れ内のレコードを読み取ることができ、任意の適切な方法でデータを収集することができます。
The meter keeps information about collections, in particular it maintains ReaderLastTime variables which remember the time the last collection was made by each reader. A second variable, InactivityTime, specifies the minimum time the meter will wait before considering that a flow is idle.
メーターは特にそれが最後のコレクションが各リーダーによって作られた時間を覚えてReaderLastTime変数を保持し、コレクションに関する情報を保持します。第二の可変、InactivityTimeは、メーターは流れがアイドル状態であることを考慮する前に待機する最小時間を指定します。
The meter must recover records used for idle flows, if only to prevent it running out of flow records. Recovered flow records are returned to the 'inactive' state. A variety of recovery strategies are possible, including the following:
それはフローレコードの不足を防ぐために、場合にのみ、メーターは、アイドルフローに使用記録を回復する必要があります。回収されたフローレコードは、「非アクティブ」状態に戻ります。復旧戦略の多様は、次のような、可能です。
One possible recovery strategy is to recover idle flow records as soon as possible after their data has been collected by all readers which have registered to do so. To implement this the meter could run a background process which scans the flow table looking for ' current' flows whose 'last packet' time is earlier than the meter's LastCollectTime.
一つの可能な復旧戦略は、そのデータがそうするように登録されたすべての読者によって収集された後できるだけ早くアイドルフローレコードを回復することです。メーターが「現行」を探しているフローテーブルをスキャンし、バックグラウンド・プロセスを実行することができ、これを実装するには、その「最後のパケットの時刻がメーターのLastCollectTimeより早い流れ。
Another recovery strategy is to leave idle flows alone as long as possible, which would be acceptable if one was only interested in measuring total traffic volumes. It could be implemented by having the meter search for collected idle flows only when it ran low on ' inactive' flow records.
別の回復戦略は、1つの総トラフィック量を測定する際にのみ興味があった場合には許容されるであろう、できるだけ長く一人のアイドルの流れを残すことです。それは「非アクティブ」のフローレコードに低走っただけ集めアイドルフローのメーターの検索を持つことによって実現することができます。
One further factor a meter should consider before recovering a flow is the number of meter readers which have collected the flow's data. If there are multiple meter readers operating, each reader should collect a flow's data before its memory is recovered.
メーターは流れを回復する前に検討すべき一つの更なる要因は、フローのデータを収集してきたメーター読者の数です。動作する複数のメーター読者がある場合は、そのメモリを回収する前に、各リーダーは、フローのデータを収集する必要があります。
Of course a meter reader may fail, so the meter cannot wait forever for it. Instead the meter must keep a table of active meter readers, with a timeout specified for each. If a meter reader fails to collect flow data within its timeout interval, the meter should delete that reader from the meter's active meter reader table.
もちろん、メーター読者が失敗する可能性がありますので、メーターはそれを永遠に待つことができません。代わりに、メーターはそれぞれのタイムアウトを指定して、アクティブメーター読者のテーブルを保持しなければなりません。メーター読者がそのタイムアウト間隔内にフローデータを収集するために失敗した場合、メーターはメーターのアクティブ検針テーブルからそのリーダーを削除する必要があります。
Under normal conditions the meter reader specifies which set of usage records it wants to collect, and the meter provides them. If, however, memory usage rises above the high-water mark the meter should switch to a STANDBY RULE SET so as to decrease the rate at which new flows are created.
通常の条件下ではメーター読者は、それが収集したい使用状況レコードのセットを指定し、メーターがそれらを提供します。しかし、メモリ使用率が高ウォーターマークを超えて上昇する場合、新しいフローが作成される速度を減少するように計器は、スタンバイ・ルール・セットに切り替えるべきです。
When the manager, usually as part of a regular poll, becomes aware that the meter is using its standby rule set, it could decrease the interval between collections. This would shorten the time that flows sit in memory waiting to be collected, allowing the meter to free flow memory faster.
通常、定期的な世論調査の一環として、管理者は、メーターはそのスタンバイルールセットを使用していることが判明した際に、それはコレクション間の間隔を減少させることができました。これは、メーターが速くフローメモリを解放することができ、収集されるのを待っているメモリに座る流れの時間を短縮します。
The meter could also increase its efforts to recover flow memory so as to reduce the number of idle flows in memory. When the situation returns to normal, the manager may request the meter to switch back to its normal rule set.
メーターは、メモリ内のアイドルフローの数を低減するように、フローメモリを回復するための努力を増加させる可能性があります。状況が正常な状態に戻った場合、管理者は通常のルール・セットに戻すためにメーターを要求することができます。
5 Meter Readers
5本のメーター読者
Usage data is accumulated by a meter (e.g. in a router) as memory permits. It is collected at regular reporting intervals by meter readers, as specified by a manager. The collected data is recorded in stable storage as a FLOW DATA FILE, as a sequence of USAGE RECORDS.
使用データは、メモリが許す限り（例えばルータ）計器によって蓄積されます。管理者によって指定されるようにそれは、メーター読者によって定期的な報告間隔で収集されます。収集されたデータは、使用状況レコードのシーケンスとして、フローデータファイルとして安定したストレージに記録されています。
The following sections describe the contents of usage records and flow data files. Note, however, that at this stage the details of such records and files is not specified in the architecture. Specifying a common format for them would be a worthwhile future development.
次のセクションでは、使用記録とフロー・データ・ファイルの内容を説明します。この段階では、このような記録やファイルの詳細はアーキテクチャで指定されていないこと、しかし、注意してください。それらのための共通のフォーマットを指定すると、やりがいのある将来の開発になります。
Once a packet has been classified and is ready to be counted, an appropriate flow data record must already exist in the flow table; otherwise one must be created. The flow record has a flexible format where unnecessary identification attributes may be omitted. The determination of which attributes of the flow record to use, and of what values to put in them, is specified by the current rule set.
パケットを分類し計数する準備ができているれた後、適切なフローデータレコードは、フローテーブルに既に存在している必要があります。それ以外の場合は1を作成する必要があります。フローレコードは不要識別属性は省略することができる柔軟なフォーマットを有しています。決定は、使用するフローレコードの属性、およびそれらに置くためにどの値を、現在のルールセットで指定されています。
Note that the combination of start time, rule set number and flow subscript (row number in the flow table) provide a unique flow identifier, regardless of the values of its other attributes.
開始時間の組み合わせは、ルールセット番号と流れ添字（フローテーブルの行数）に関わらず、その他の属性の値の一意のフロー識別子を提供することに留意されたいです。
The current rule set may specify additional information, e.g. a computed attribute value such as FlowKind, which is to be placed in the attribute section of the usage record. That is, if a particular flow is matched by the rule set, then the corresponding flow record should be marked not only with the qualifying identification attributes, but also with the additional information. Using this feature, several flows may each carry the same FlowKind value, so that the resulting usage records can be used in post-processing or between meter reader and meter as a criterion for collection.
現在のルールセットは、例えば、追加の情報を指定することができますこのような使用のレコードの属性セクションに配置されるFlowKind、として計算された属性値。すなわち、特定のフローをルールセットにマッチしている場合、対応するフローレコードが適格識別属性を持つだけでなく、付加情報とだけでなく、マークされるべきです。得られた使用状況レコードコレクションの基準として、後処理またはメータ読取装置と計器との間で使用することができるように、この機能を使用して、複数のフローの各々は、同じFlowKind値を有していてもよいです。
The collected usage data will be stored in flow data files on the meter reader, one file for each meter. As well as containing the measured usage data, flow data files must contain information uniquely identifiying the meter from which it was collected.
収集した使用データは、メーターリーダーでフロー・データ・ファイル内の各メーターに1つのファイルに保存されます。同様に測定された使用データを含むものとして、フロー・データ・ファイルを一意それが収集されたメーターをidentifiying情報が含まれている必要があります。
A USAGE RECORD contains the descriptions of and values for one or more flows. Quantities are counted in terms of number of packets and number of bytes per flow. Other quantities, e.g. short-term flow rates, may be added later; work on such extensions is described in the RTFM 'New Attributes' document [RTFM-NEW].
利用記録は、1つ以上のフローのための説明と値が含まれています。量はパケットおよびフローごとのバイト数の数でカウントされます。他の量、例えば短期流量は、後で添加してもよいです。そのような拡張の作業はRTFM「新しい属性」ドキュメント[RTFM-NEW]に記載されています。
Each usage record contains the metered traffic group identifier of the meter (a set of network addresses), a time stamp and a list of reported flows (FLOW DATA RECORDS). A meter reader will build up a file of usage records by regularly collecting flow data from a meter, using this data to build usage records and concatenating them to the tail of a file. Such a file is called a FLOW DATA FILE.
使用法の各レコードには、メートル（ネットワークアドレスのセット）の計量されたトラフィックのグループ識別子、タイムスタンプと報告したフロー（FLOW DATA RECORDS）のリストが含まれています。メーター読者は定期的に、メーターからのフローデータを収集使用状況レコードを構築するために、このデータを使用して、ファイルの末尾にそれらを連結して使用記録のファイルを構築します。このようなファイルは、FLOWデータファイルと呼ばれています。
A usage record contains the following information in some form:
使用法レコードは、何らかの形で、以下の情報が含まれています。
+-------------------------------------------------------------------+
| RECORD IDENTIFIERS: |
| Meter Id (& digital signature if required) |
| Timestamp |
| Collection Rules ID |
+-------------------------------------------------------------------+
| FLOW IDENTIFIERS: | COUNTERS |
| Address List | Packet Count |
| Subscriber ID (Optional) | Byte Count |
| Attributes (Optional) | Flow Start/Stop Time |
+-------------------------------------------------------------------+
The usage record contents are the raison d'etre of the system. The accuracy, reliability, and security of transmission are the primary concerns of the meter/meter reader exchange. Since errors may occur on networks, and Internet packets may be dropped, some mechanism for ensuring that the usage information is transmitted intact is needed.
使用法レコードの内容は、システムの存在意義です。伝送の精度、信頼性、およびセキュリティがメートル/メートルリーダ交換の主な関心事です。エラーがネットワーク上で発生する可能性があり、そしてインターネットパケットがドロップされる可能性があるため、使用情報がそのまま送信されることを保証するための何らかのメカニズムが必要です。
Flow data is moved from meter to meter reader via a series of protocol exchanges between them. This may be carried out in various ways, moving individual attribute values, complete flows, or the entire flow table (i.e. all the active and idle flows). One possible method of achieving this transfer is to use SNMP; the 'Traffic Flow Measurement: Meter MIB' RFC [RTFM-MIB] gives details. Note that this is simply one example; the transfer of flow data from meter to meter reader is not specified in this document.
フローデータは、それらの間のプロトコル交換のシリーズを介してメーターリーダーメートルから移動されます。これは、個々の属性値を、完全な流れ、または全体フローテーブル（すなわち、すべてのアクティブおよびアイドルフロー）を移動させる、様々な方法で行うことができます。この転送を達成するための1つの可能な方法は、SNMPを使用することです。 '交通流計測：メーターMIB' RFC [RTFM-MIB]は詳細を説明します。これは単に一例であることに注意してください。メータリーダメートルからフローデータの転送は、この文書で指定されていません。
The reliability of the data transfer method under light, normal, and extreme network loads should be understood before selecting among collection methods.
光の下でデータ転送方法の信頼性が、通常、極端なネットワーク負荷が収集方法の中から選択する前に理解すべきです。
In normal operation the meter will be running a rule file which provides the required degree of flow reporting granularity, and the meter reader(s) will collect the flow data often enough to allow the meter's garbage collection mechanism to maintain a stable level of memory usage.
通常の操作ではメーターは、粒度の報告の流れの必要な程度を提供し、ルールファイルを実行され、メーターリーダー（複数可）、メモリ使用量の安定したレベルを維持するために、メーターのガベージコレクションのメカニズムを可能にする、多くの場合、十分なフローデータを収集します。
In the worst case traffic may increase to the point where the meter is in danger of running completely out of flow memory. The meter implementor must decide how to handle this, for example by switching to a default (extremely coarse granularity) rule set, by sending a trap message to the manager, or by attempting to dump flow data to the meter reader.
最悪の場合、トラフィックは、メーターが流れメモリから完全に実行されているの危険がある点まで増加する可能性があります。メーターの実装は、デフォルト（非常に粗い粒度）ルール・セットに切り替えることで、マネージャにトラップメッセージを送信することにより、またはメーターリーダーにフローデータをダンプしようとすることにより、例えば、これをどのように処理するかを決める必要があります。
Users of the Traffic Flow Measurement system should analyse their requirements carefully and assess for themselves whether it is more important to attempt to collect flow data at normal granularity (increasing the collection frequency as needed to keep up with traffic volumes), or to accept flow data with a coarser granularity. Similarly, it may be acceptable to lose flow data for a short time in return for being sure that the meter keeps running properly, i.e. is not overwhelmed by rising traffic levels.
交通流計測システムのユーザーは、慎重にその要件を分析し、正常な粒度でフローデータを収集しようとすることがより重要であるかどうかを自分自身のための評価（トラヒック量に追いつくために、必要に応じて収集頻度を上げる）、またはフローデータを受け入れるようにすべきです粗い粒度で。同様に、メーターはすなわち、正常に動作し続け上昇トラフィックレベルに圧倒されていないことを確認していると引き換えに短時間フローデータを失うことが許容可能です。
6 Managers
6つのマネージャ
A manager configures meters and controls meter readers. It does this via the interactions described below.
マネージャは、メートルを構成メータリーダを制御します。これは、下記の相互作用を介してこれを行います。
- DOWNLOAD RULE SET: A meter may hold an array of rule sets. One
of these, the 'default' rule set, is built in to the meter and
cannot be changed; this is a diagnostic feature, ensuring that
when a meter starts up it will be running a known ruleset.
All other rule sets must be downloaded by the manager. A manager may use any suitable protocol exchange to achieve this, for example an FTP file transfer or a series of SNMP SETs, one for each row of the rule set.
他のすべてのルールセットは、マネージャによってダウンロードされなければなりません。管理者は、例えば、FTPファイル転送やSNMPセット、ルールセットの各列に対して1つのシリーズをこれを達成するために、任意の適切なプロトコル交換を使用してもよいです。
- SPECIFY METER TASK: Once the rule sets have been downloaded, the manager must instruct the meter which rule sets will be the 'current' and 'standby' ones for each task the meter is to perform.
- METERのタスクを指定：ルール・セットがダウンロードされたら、管理者は、セットはメーターが実行することで、各タスクのための「現在」と「スタンバイ」のものになりますルールメーターを指示する必要があります。
- SET HIGH WATER MARK: A percentage of the flow table capacity, used by the meter to determine when to switch to its standby rule set (so as to increase the granularity of the flows and conserve the meter's flow memory). Once this has happened, the manager may also change the polling frequency or the meter's control parameters (so as to increase the rate at which the meter can recover memory from idle flows). The meter has a separate high water mark value for each task it is currently running.
- ハイウォーターマークを設定します計によって使用されるフローテーブル容量のパーセンテージは、ときにスタンバイ・ルール・セットに切り替えるために決定するために（そうフローの粒度を増加させ、メータのフローメモリを節約するように）。これが起こったならば（メーターはアイドルフローからメモリを回復することができる速度を増加させるように）、マネージャは、ポーリング頻度又はメータの制御パラメータを変更することができます。メーターは、現在実行されているタスクごとに別々の高いウォーターマーク値を持っています。
If the high traffic levels persist, the meter's normal rule set may have to be rewritten to permanently reduce the reporting granularity.
高トラフィックレベルが持続した場合、メーターの通常のルールセットは、永続的に報告粒度を減らすために書き直さなければならないことがあります。
- SET FLOW TERMINATION PARAMETERS: The meter should have the good sense in situations where lack of resources may cause data loss to purge flow records from its tables. Such records may include:
- 設定流量終了パラメータ：メーターは、リソースの不足がそのテーブルからフローレコードをパージするために、データの損失を引き起こす可能性のある状況での良識を持っている必要があります。このようなレコードが含まれることがあります。
- Flows that have already been reported to all registered meter readers, and show no activity since the last report, - Oldest flows, or - Flows with the smallest number of observed packets.
- すでに登録されているすべてのメーター読者に報告し、そして最後のレポート以来、全く活性を示されていないフローは、 - 最古の流れ、または - 観測されたパケット数の少ないフロー。
- SET INACTIVITY TIMEOUT: This is a time in seconds since the last packet was seen for a flow. Flow records may be reclaimed if they have been idle for at least this amount of time, and have been collected in accordance with the current collection criteria.
- SET無活動タイムアウト：これは、最後のパケットが流れのために見られたので、秒単位の時間です。彼らは時間の少なくともこの量のためにアイドル状態になっていると、現在の収集基準に従って収集された場合のフローレコードを再利用することができます。
It might be useful if a manager could set the FLOW TERMINATION PARAMETERS to different values for different tasks. Current meter implementations have only single ('whole meter') values for these parameters, and experience to date suggests that this provides an adequate degree of control for the tasks.
管理者が異なるタスクのために異なる値にFLOW終了パラメータを設定することができれば便利かもしれません。電流計の実装は、現在までに、このタスクのための制御の十分な程度を提供することを示唆しているだけで、単一の（「全体メートル」）これらのパラメータの値、および経験を持っています。
Because there are a number of parameters that must be set for traffic flow measurement to function properly, and viable settings may change as a result of network traffic characteristics, it is desirable to have dynamic network management as opposed to static meter configurations. Many of these operations have to do with space tradeoffs - if memory at the meter is exhausted, either the collection interval must be decreased or a coarser granularity of aggregation must be used to reduce the number of active flows.
適切に機能するためにトラフィックフローの測定のために設定されなければならないパラメータ、および生存可能な設定の数は、ネットワークのトラフィック特性の結果として変更される可能性があるので、静的メーター構成とは対照的に、動的なネットワーク管理を有することが望ましいです。これらの操作の多くは、スペースのトレードオフをしなければならない - メートルでメモリが使い果たされている場合、いずれかの収集間隔が減少しなければならないか、または凝集の粗い粒度は、アクティブフローの数を減らすために使用する必要があります。
Increasing the collection interval effectively stores data in the meter; usage data in transit is limited by the effective bandwidth of the virtual link between the meter and the meter reader, and since these limited network resources are usually also used to carry user data (the purpose of the network), the level of traffic flow measurement traffic should be kept to an affordable fraction of the bandwidth. ("Affordable" is a policy decision made by the Network
収集間隔を大きくすると効果的メートルにデータを格納します。トランジットで使用量データは、メータメータリーダとの間の仮想リンクの有効帯域幅によって制限され、これらの限られたネットワーク資源は、通常、ユーザデータを運ぶためにも使用されるので、（ネットワークの目的）、交通流計測のレベルトラフィックは、帯域幅の手頃な価格の割合に抑える必要があります。 （「手ごろな価格は、」ネットワークによって行われた政策決定であります
Operations personnel). At any rate, it must be understood that the operations below do not represent the setting of independent variables; on the contrary, each of the values set has a direct and measurable effect on the behaviour of the other variables.
運用担当者）。いずれにせよ、以下の操作が独立変数の設定を表すものではないことを理解しなければなりません。逆に、設定された値のそれぞれは、他の変数の挙動に直接的かつ測定可能な効果を有しています。
Network management operations follow:
ネットワーク管理操作は、次のとおりです。
- MANAGER and METER READER IDENTIFICATION: The manager should ensure that meters are read by the correct set of meter readers, and take steps to prevent unauthorised access to usage information. The meter readers so identified should be prepared to poll if necessary and accept data from the appropriate meters. Alternate meter readers may be identified in case both the primary manager and the primary meter reader are unavailable. Similarly, alternate managers may be identified.
- MANAGERとMETER READER IDENTIFICATION：マネージャは、メートルをメートル読者の正しいセットによって読み取られることを確認し、使用情報への不正アクセスを防止するための措置をとるべきです。そのように同定メーター読者は、必要に応じてポーリングし、適切な計器からのデータを受け入れるように準備されるべきです。代替メーター読者は主マネージャと主要メーターリーダーの両方が利用できない場合に識別することができます。同様に、代替の管理者は識別することができます。
- REPORTING INTERVAL CONTROL: The usual reporting interval should be selected to cope with normal traffic patterns. However, it may be possible for a meter to exhaust its memory during traffic spikes even with a correctly set reporting interval. Some mechanism should be available for the meter to tell the manager that it is in danger of exhausting its memory (by declaring a ' high water' condition), and for the manager to arbitrate (by decreasing the polling interval, letting nature take its course, or by telling the meter to ask for help sooner next time).
- 間隔制御を報告する：通常のレポート間隔は、通常のトラフィックパターンに対処するために選択されなければなりません。メーターがさえ正しく設定報告間隔で、トラフィックの急増時にそのメモリを排気するためしかし、それは可能かもしれません。いくつかのメカニズムは、それが（「高水」の条件を宣言することによって）そのメモリを排気する危険があることを管理者に伝えるメートルのために利用可能であるべき、とマネージャーのための自然がそのコースを取るせ、ポーリング間隔を減少させることによって（仲裁します、または早く助けのために次の時間を尋ねるためにメーターを伝えることによって）。
- GRANULARITY CONTROL: Granularity control is a catch-all for all the parameters that can be tuned and traded to optimise the system's ability to reliably measure and store information on all the traffic (or as close to all the traffic as an administration requires). Granularity:
- 粒度CONTROL：粒度制御キャッチオール確実にすべてのトラフィック（または投与を必要とするすべてのトラフィックに近い）の情報を測定して保存するシステムの能力を最適化するように調整して取引することができるすべてのパラメータのためです。粒度：
- Controls the amount of address information identifying each
flow, and
- Determines the number of buckets into which user traffic
will be lumped together.
Since granularity is controlled by the meter's current rule set, the manager can only change it by requesting the meter to switch to a different rule set. The new rule set could be downloaded when required, or it could have been downloaded as part of the meter's initial configuration.
粒度は、メーターの現在のルールセットによって制御されるので、管理者が異なるだけで、ルール・セットに切り替えるためにメーターを要求することにより、それを変更することができます。必要なときに、新しいルールセットをダウンロードすることができ、またはそれは、メーターの初期設定の一部としてダウンロードされている可能性があります。
- FLOW LIFETIME CONTROL: Flow termination parameters include timeout parameters for obsoleting inactive flows and removing them from tables, and maximum flow lifetimes. This is intertwined with reporting interval and granularity, and must be set in accordance with the other parameters.
- FLOWのライフタイムコントロール：フロー終了パラメータが非アクティブフローを時代遅れにしてテーブルからそれらを除去するためのタイムアウトパラメータ、および最大流量の寿命が含まれます。これは、レポート間隔と粒度と絡み合っており、他のパラメータに応じて設定する必要があります。
Exception conditions must be handled, particularly occasions when the meter runs out of space for flow data. Since - to prevent an active task from counting any packet twice - packets can only be counted in a single flow, discarding records will result in the loss of information. The mechanisms to deal with this are as follows:
メーターはフローデータのための領域が不足すると、例外条件は、特に機会を処理する必要があります。以来 - 二回任意のパケットをカウントからのアクティブ・タスクを防止する - パケットが単一のフローでカウントすることができ、情報の損失をもたらすであろうレコードを破棄する。次のようにこれに対処するためのメカニズムは以下のとおりです。
- METER OUTAGES: In case of impending meter outages (controlled restarts, etc.) the meter could send a trap to the manager. The manager could then request one or more meter readers to pick up the data from the meter.
- METERの停止：差し迫ったメートルの停止（制御再開など）の場合、メーターがマネージャにトラップを送信することができます。管理者は、その後、計からのデータをピックアップするために、1つ以上の検針を要求することができます。
Following an uncontrolled meter outage such as a power failure, the meter could send a trap to the manager indicating that it has restarted. The manager could then download the meter's correct rule set and advise the meter reader(s) that the meter is running again. Alternatively, the meter reader may discover from its regular poll that a meter has failed and restarted. It could then advise the manager of this, instead of relying on a trap from the meter.
停電など制御不能メートルの停止に続いて、メーターはそれが再起動したことを示すマネージャにトラップを送信することができます。管理者はその後、メーターの正しいルールセットをダウンロードして、メーターが再び実行されていることをメーターリーダー（複数可）を助言ができます。また、メーター読者はメーターが失敗し、再起動したことをその通常の世論調査から発見することがあります。それは、代わりに計からのトラップに依存するので、これの管理者に助言することができます。
- METER READER OUTAGES: If the collection system is down or isolated, the meter should try to inform the manager of its failure to communicate with the collection system. Usage data is maintained in the flows' rolling counters, and can be recovered when the meter reader is restarted.
- 検針の停止：収集システムがダウンしたり孤立している場合、メーターは収集システムと通信するためにその失敗のマネージャに通知するようにしてください。使用量データは、フローローリングカウンタに維持され、メーター読者が再起動されたときに回収することができます。
- MANAGER OUTAGES: If the manager fails for any reason, the meter should continue measuring and the meter reader(s) should keep gathering usage records.
- MANAGERの停止：管理者が何らかの理由で失敗した場合、メーターは使用状況レコードを収集しておく必要があり、測定およびメーターリーダー（複数可）を継続すべきです。
- BUFFER PROBLEMS: The network manager may realise that there is a 'low memory' condition in the meter. This can usually be attributed to the interaction between the following controls:
- バッファ問題：ネットワーク管理者は、「低メモリ」の条件がメートルであることを実現することができます。これは通常、次のコントロール間の相互作用に起因することができます。
- The reporting interval is too infrequent, or - The reporting granularity is too fine.
- レポート間隔があまりにもまれである、または - レポーティング粒度が細かすぎます。
Either of these may be exacerbated by low throughput or bandwidth of circuits carrying the usage data. The manager may change any of these parameters in response to the meter (or meter reader's) plea for help.
これらのいずれかが使用データを運ぶ回路の低スループットまたは帯域幅によって悪化されてもよいです。管理者は、ヘルプのためメートル（またはメーターリーダーの）嘆願に応じてこれらのパラメータを変更することがあります。
Although the rule table is a flexible tool, it can also become very complex. It may be helpful to develop some rule sets for common applications:
ルールテーブルには柔軟なツールですが、それはまた、非常に複雑になることができます。一般的なアプリケーションのためのいくつかのルールセットを開発するために役立つことがあります。
- PROTOCOL TYPE: The meter records packets by protocol type. This will be the default rule table for Traffic Flow Meters.
- プロトコルタイプ：メーターは、プロトコルの種類によってパケットを記録します。これは、トラフィックフローメータのデフォルトのルールテーブルになります。
- ADJACENT SYSTEMS: The meter records packets by the MAC address of the Adjacent Systems (neighbouring originator or next-hop). (Variants on this table are "report source" or "report sink" only.) This strategy might be used by a regional or backbone network which wants to know how much aggregate traffic flows to or from its subscriber networks.
- ADJACENT SYSTEMS：隣接システム（隣接発信またはネクストホップ）のMACアドレスで計レコードパケット。 （この表の変種は、「レポートソース」や「レポートシンク」のみです。）この戦略は、集約トラフィックは、その加入者ネットワークにまたはから流れどのくらい知りたい地域やバックボーンネットワークで使用される可能性があります。
- END SYSTEMS: The meter records packets by the IP address pair contained in the packet. (Variants on this table are "report source" or "report sink" only.) This strategy might be used by an End System network to get detailed host traffic matrix usage data.
- エンドシステム：メートルレコードパケットパケットに含まれるIPアドレスのペアによって。 （この表の変種は、「レポートソース」や「レポートシンク」のみです。）この戦略は、詳細なホストトラフィックマトリクスの使用状況データを取得するためにエンドシステムのネットワークで使用される可能性があります。
- TRANSPORT TYPE: The meter records packets by transport address; for IP packets this provides usage information for the various IP services.
- トランスポートタイプ：メーターは、トランスポートアドレスによるパケットを記録します。 IPパケットのために、これは、さまざまなIPサービスの利用情報を提供します。
- HYBRID SYSTEMS: Combinations of the above, e.g. for one interface report End Systems, for another interface report Adjacent Systems. This strategy might be used by an enterprise network to learn detail about local usage and use an aggregate count for the shared regional network.
- ハイブリッド系：上記の組合せ、例えば1つのインターフェースレポートエンドシステムのために、別のインターフェイスのために隣接するシステムを報告しています。この戦略は、ローカルな利用についての詳細を学び、共有し、地域ネットワークの集約数を使用するために、企業ネットワークで使用される可能性があります。
7 Security Considerations
7つのセキュリティの考慮事項
A traffic flow measurement system may be subject to the following kinds of attacks:
トラフィック流量測定システムは、攻撃の次の種類の対象であってもよいです。
- ATTEMPTS TO DISABLE A TRAFFIC METER: An attacker may attempt to disrupt traffic measurement so as to prevent users being charged for network usage. For example, a network probe sending packets to a large number of destination and transport addresses could produce a sudden rise in the number of flows in a meter's flow table, thus forcing it to use its coarser standby rule set.
- 交通METERを無効にしようとします：攻撃者は、ユーザーがネットワークの使用のために充電されないように、トラフィック測定を中断するために試みることができます。例えば、宛先および輸送アドレスの多数にパケットを送信するネットワークプローブは、したがって、その粗いスタンバイルールセットを使用するように強制的に、メータのフローテーブル内のフローの数の急激な上昇を作り出すことができます。
- UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to gain advantage or cause mischief (e.g. denial of service) by subverting any of the system elements - meters, meter readers or managers.
- システム資源の不正使用： - メートル、メートルリーダーまたはマネージャ攻撃者は、システム要素のいずれかを破壊することにより、利点又は原因のいたずら（サービスの拒否など）を獲得することを望むかもしれません。
- UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to disclosure can be read through active or passive attacks unless it is suitably protected. Usage data may or may not be of this type. Control messages, traps, etc. are not likely to be considered sensitive to disclosure.
- データの不正な開示：それは適切に保護されていない限り、開示に敏感であるすべてのデータは、能動的または受動的な攻撃を介して読み取ることができます。使用データは、あるいはこのタイプであってもなくてもよいです。制御メッセージ、トラップ、開示等の影響を受けやすいと見なされる可能性はありません。
- UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA: Similarly, any data whose integrity is sensitive can be altered, replaced/injected or deleted through active or passive attacks unless it is suitably protected. Attackers may modify message streams to falsify usage data or interfere with the proper operation of the traffic flow measurement system. Therefore, all messages, both those containing usage data and those containing control data, should be considered vulnerable to such attacks.
- 改竄、データの置換または破壊：それは適切に保護されていない限り、同様に、整合性に敏感である任意のデータを交換/能動的又は受動的攻撃を通して注入または削除、変更することができます。攻撃者は、使用データを改ざんまたはトラフィック流量測定システムの適切な動作を妨害するメッセージストリームを変更することができます。したがって、すべてのメッセージ、使用量データを含むものと、制御データを含むものの両方が、そのような攻撃に対して脆弱と見なされるべきです。
The following countermeasures are recommended to address the possible threats enumerated above:
次のような対策を施す上に列挙した可能性の脅威に対処することをお勧めします。
- ATTEMPTS TO DISABLE A TRAFFIC METER can't be completely countered. In practice, flow data records from network security attacks have proved very useful in determining what happened. The most effective approach is first to configure the meter so that it has three or more times as much flow memory as it needs in normal operation, and second to collect the flow data fairly frequently so as to minimise the time needed to recover flow memory after such an attack.
- 交通METERを無効にしようとしますが、完全に打ち消されません。実際には、ネットワークのセキュリティ攻撃からのフローデータレコードは、何が起こったのかを決定する上で非常に有用であることが分かっています。最も効果的なアプローチはかなり頻繁にした後、フローメモリを回復するために必要な時間を最小限にするようにフローデータを収集するために、それが正常に動作して必要として、それは多くのフローメモリの3倍以上になるようにメーターを設定する最初の、第二でありますこのような攻撃。
- UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use of authentication and access control services.
- システム資源の無断転用を認証およびアクセス制御サービスを使用して対抗しています。
- UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a confidentiality (encryption) service.
- データの不正な開示は、機密性（暗号化）サービスを使用することによって対抗されます。
- UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is countered through the use of an integrity service.
- データの不正な改変、交換や破壊が整合性サービスを使用して対抗しています。
A Traffic Measurement system must address all of these concerns. Since a high degree of protection is required, the use of strong cryptographic methodologies is recommended. The security requirements for communication between pairs of traffic measurmement system elements are summarized in the table below. It is assumed that meters do not communicate with other meters, and that meter readers do not communicate directly with other meter readers (if synchronization is required, it is handled by the manager, see Section 2.5). Each entry in the table indicates which kinds of security services are required. Basically, the requirements are as follows:
トラフィック測定システムは、これらの懸念のすべてに対処しなければなりません。高度の保護が必要とされているので、強力な暗号手法の使用が推奨されます。トラフィックmeasurmementシステム要素のペアの間の通信のセキュリティ要件は、以下の表にまとめます。メートル他のメーターと通信していないことが想定され、そのメーターリーダー（セクション2.5を参照して、同期が必要な場合、それは管理者によって処理される）他のメーター読者と直接通信しません。テーブルの各エントリには、セキュリティサービスの種類が必要とされているかを示します。次のように基本的には、要件は次のとおりです。
Security Service Requirements for RTFM elements
RTFM要素のためのセキュリティサービスの要件
+------------------------------------------------------------------+
| from\to | meter | meter reader | application | manager |
|---------+--------------+--------------+-------------+------------|
| meter | N/A | authent | N/A | authent |
| | | acc ctrl | | acc ctrl |
| | | integrity | | |
| | | confid ** | | |
|---------+--------------+--------------+-------------+------------|
| meter | authent | N/A | authent | authent |
| reader | acc ctrl | | acc ctrl | acc ctrl |
| | | | integrity | |
| | | | confid ** | |
|---------+--------------+--------------+-------------+------------|
| appl | N/A | authent | | |
| | | acc ctrl | ## | ## |
|---------+--------------+--------------+-------------+------------|
| manager | authent | authent | ## | authent |
| | acc ctrl | acc ctrl | | acc ctrl |
| | integrity | integrity | | integrity |
+------------------------------------------------------------------+
N/A = Not Applicable ** = optional ## = outside RTFM scope
N / A =該当なし** =オプション## = RTFMの範囲外
- When any two elements intercommunicate they should mutually authenticate themselves to one another. This is indicated by ' authent' in the table. Once authentication is complete, an element should check that the requested type of access is allowed; this is indicated on the table by 'acc ctrl'.
- 任意の二つの要素が相互に通信する場合、それらは相互にお互いに自分自身を認証する必要があります。これは、表中の「オー」によって示されています。認証が完了すると、要素は、アクセスの要求されたタイプが許可されていることを確認する必要があります。これを「ACCのCTRL」でテーブルの上に示されています。
- Whenever there is a transfer of information its integrity should be protected.
- 情報の転送があるときは常にその完全性を保護する必要があります。
- Whenever there is a transfer of usage data it should be possible to ensure its confidentiality if it is deemed sensitive to disclosure. This is indicated by 'confid' in the table.
- 使用データの転送があるときはいつでも、それは開示に敏感であるとみなされた場合、その機密性を確保することが可能でなければなりません。これは、テーブル「confid」で示されています。
Security protocols are not specified in this document. The system elements' management and collection protocols are responsible for providing sufficient data integrity, confidentiality, authentication and access control services.
セキュリティプロトコルは、この文書で指定されていません。システム要素の管理回収プロトコルは、十分なデータの整合性、機密性、認証およびアクセス制御サービスを提供する責任があります。
8 IANA Considerations
8つのIANAの考慮事項
The RTFM Architecture, as set out in this document, has two sets of assigned numbers. Considerations for assigning them are discussed in this section, using the example policies as set out in the "Guidelines for IANA Considerations" document [IANA-RFC].
RTFMアーキテクチャは、この文書に記載されたように、割り当てられた数字の2セットがあります。それらを割り当てるための考慮事項は、文書[IANA-RFC「IANAの考慮のためのガイドライン」に記載のように、例えばポリシーを使用して、このセクションで説明されています。
The Pattern Matching Engine (PME) is a virtual machine, executing RTFM rules as its instructions. The PME opcodes appear in the 'action' field of an RTFM rule. The current list of opcodes, and their values for the PME's 'goto' and 'test' flags, are set out in section 4.4 above ("Rules and Rulesets).
パターンマッチングエンジン（PME）が命令としてRTFMルールを実行する仮想マシンです。 PMEのオペコードはRTFMルールの「アクション」フィールドに表示されます。現在のオペコードのリスト、およびPMEの「ジャンプ」と「テスト」フラグのためのそれらの値は、（「ルールおよびルールセット）は、上記セクション4.4に記載されています。
The PME opcodes are pivotal to the RTFM architecture, since they must be implemented in every RTFM meter. Any new opcodes must therefore be allocated through an IETF Consensus action [IANA-RFC].
彼らはすべてのRTFMメーターで実装しなければならないので、PMEのオペコードは、RTFMアーキテクチャに極めて重要です。新しいオペコードは、従って、IETF Consensus動作[IANA-RFC]を介して割り当てられなければなりません。
Opcodes are simply non-negative integers, but new opcodes should be allocated sequentially so as to keep the total opcode range as small as possible.
オペコードは、単に負でない整数であるが、できるだけ小さい総オペコード範囲を保つように新しい命令コードを順次に割り当てられなければなりません。
Attribute numbers in the range of 0-511 are globally unique and are allocated according to an IETF Consensus action [IANA-RFC]. Appendix C of this document allocates a basic (i.e. useful minimum) set of attribtes; they are assigned numbers in the range 0 to 63. The RTFM working group is working on an extended set of attributes, which will have numbers in the range 64 to 127.
0から511の範囲の数値属性は、グローバルに一意であり、IETF Consensus動作[IANA-RFC]に従って割り当てられます。この文書の付録Cはattribtesの基本的な（すなわち、有用な最小の）セットを割り当てます。彼らは63ザRTFMワーキンググループの範囲0の番号が付されている127の範囲64の数値を有することになる属性の拡張セット、に取り組んでいます。
Vendor-specific attribute numbers are in the range 512-1023, and will be allocated using the First Come FIrst Served policy [IANA-RFC]. Vendors requiring attribute numbers should submit a request to IANA giving the attribute names: IANA will allocate them the next available numbers.
ベンダー固有の属性番号は512から1023の範囲にあり、まず最初に添えポリシー[IANA-RFC]を、是非使って割り当てられます。属性番号を必要とするベンダーは、属性名を与えるIANAに要求を提出してください：IANAは彼らに次の使用可能な番号を割り当てます。
Attribute numbers 1024 and higher are Reserved for Private Use [IANA-RFC]. Implementors wishing to experiment with further new attributes should use attribute numbers in this range.
属性番号1024以上を私用[IANA-RFC]のために予約されています。さらに、新しい属性を使って実験したい実装者は、この範囲の属性番号を使用する必要があります。
Attribute numbers are simply non-negative integers. When writing specifications for attributes, implementors must give sufficient detail for the new attributes to be easily added to the RTFM Meter MIB [RTFM-MIB]. In particular, they must indicate whether the new attributes may be:
属性番号は単に非負整数です。属性の仕様を記述する場合は、実装は簡単RTFMメーターMIB [RTFM-MIB]に追加する新しい属性のために十分な詳細を与える必要があります。特に、それらは新しい属性がかもしれかどうかを示す必要があります。
- tested in an IF statement - saved by a SAVE statement or set by a STORE statement - read from an RTFM meter
- IF文でテスト - SAVE文で保存またはSTORE文によって設定 - RTFMメートルから読みます
(IF, SAVE and STORE are statements in the SRL Ruleset Language [RTFM-SRL]).
（保存、およびSTOREはSRLルールセット言語[RTFM-SRL]内のステートメントである場合）。
9 APPENDICES
9つの付録
Internet users have extraordinarily diverse requirements. Networks differ in size, speed, throughput, and processing power, among other factors. There is a range of traffic flow measurement capabilities and requirements. For traffic flow measurement purposes, the Internet may be viewed as a continuum which changes in character as traffic passes through the following representative levels:
インターネットユーザーは非常に多様な要件があります。ネットワークは、他の要因の中でも特に、大きさ、速度、スループット、および処理能力が異なります。交通流計測機能と要件の範囲があります。トラフィック流量測定のために、インターネットトラフィックが以下の代表的なレベルを通過するように文字に変更連続として見ることができます。
International |
Backbones/National ---------------
/ \
Regional/MidLevel ---------- ----------
/ \ \ / / \
Stub/Enterprise --- --- --- ---- ----
||| ||| ||| |||| ||||
End-Systems/Hosts xxx xxx xxx xxxx xxxx
Note that mesh architectures can also be built out of these components, and that these are merely descriptive terms. The nature of a single network may encompass any or all of the descriptions below, although some networks can be clearly identified as a single type.
そのメッシュアーキテクチャはまた、これらのコンポーネントから構築、これらは単に説明的な用語であることに注意してくださいすることができます。いくつかのネットワークが明らかに単一タイプとして識別することができるが、単一のネットワークの性質は、以下の説明のいずれかまたは全てを包含することができます。
BACKBONE networks are typically bulk carriers that connect other networks. Individual hosts (with the exception of network management devices and backbone service hosts) typically are not directly connected to backbones.
バックボーンネットワークは、典型的には、他のネットワークを接続バルクキャリアです。 （ネットワーク管理装置とバックボーン・サービス・ホストを除く）個々のホストは、典型的には骨格に直接接続されていません。
REGIONAL networks are closely related to backbones, and differ only in size, the number of networks connected via each port, and geographical coverage. Regionals may have directly connected hosts, acting as hybrid backbone/stub networks. A regional network is a SUBSCRIBER to the backbone.
地域ネットワークのバックボーンに密接に関連している、とだけサイズが異なる、各ポート、および地理的なカバレッジを介して接続されたネットワークの数。リージョナルは、ハイブリッドバックボーン/スタブネットワークとして機能し、直接接続されたホストを有することができます。地域ネットワークは、バックボーンへの加入者です。
STUB/ENTERPRISE networks connect hosts and local area networks. STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone networks.
STUB /エンタープライズ・ネットワークは、ホストとローカルエリアネットワークに接続します。 STUB /エンタープライズ・ネットワークは、地域やバックボーンネットワークへの加入者です。
END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above networks.
ENDシステムは、口語HOSTS、上記のいずれかのネットワークへの加入者です。
Providing a uniform identification of the SUBSCRIBER in finer granularity than that of end-system, (e.g. user/account), is beyond the scope of the current architecture, although an optional attribute in the traffic flow measurement record may carry system-specific
トラフィック流量測定レコードのオプションの属性は、システム固有運ぶことができるが、エンドシステムのより細かい粒状度SUBSCRIBERの均一な識別を提供する、（例えば、ユーザ/アカウント）、現在のアーキテクチャの範囲を超えています
'user identification' labels so that meters can implement proprietary or non-standard schemes for the attribution of network traffic to responsible parties.
「ユーザ識別のラベルメートルは、責任政党へのネットワークトラフィックの帰属のための独自のまたは非標準のスキームを実装することが可能に。
Initial recommended traffic flow measurement conventions are outlined here according to the following Internet building blocks. It is important to understand what complexity reporting introduces at each network level. Whereas the hierarchy is described top-down in the previous section, reporting requirements are more easily addressed bottom-up.
初回の推奨交通流計測規則は、次のインターネットのビルディングブロックに応じて、ここで概説されています。複雑さの報告は、各ネットワークレベルで導入されましたかを理解することが重要です。階層は、前のセクションで、トップダウンで説明されるが、報告要件は、より簡単にボトムアップに取り組んでいます。
End-Systems
Stub Networks
Enterprise Networks
Regional Networks
Backbone Networks
END-SYSTEMS are currently responsible for allocating network usage to end-users, if this capability is desired. From the Internet Protocol perspective, end-systems are the finest granularity that can be identified without protocol modifications. Even if a meter violated protocol boundaries and tracked higher-level protocols, not all packets could be correctly allocated by user, and the definition of user itself varies widely from operating system to operating system (e.g. how to trace network usage back to users from shared processes).
END-SYSTEMSは、現在、この機能が要求される場合、エンドユーザにネットワークの使用状況を割り当てるための責任があります。インターネットプロトコルの観点から、エンドシステムは、プロトコルの変更なしに同定することができる最小単位です。メーターは、プロトコルの境界に違反し、より高いレベルのプロトコルを追跡している場合でも、すべてのパケットが正しく、ユーザーが割り当てられ、利用者自身の定義は、例えば、共有からユーザーに戻ってネットワークの使用状況を追跡する方法をオペレーティングシステム（にオペレーティング・システムから大きく変化することができませんプロセス）。
STUB and ENTERPRISE networks will usually collect traffic data either by end-system network address or network address pair if detailed reporting is required in the local area network. If no local reporting is required, they may record usage information in the exit router to track external traffic only. (These are the only networks which routinely use attributes to perform reporting at granularities finer than end-system or intermediate-system network address.)
詳細なレポートは、ローカルエリアネットワークに必要とされる場合にスタブと企業ネットワークは、通常、エンドシステムのネットワークアドレスまたはネットワークアドレスのペアのいずれかによってトラフィックデータを収集します。ローカルの報告が必要とされていない場合、彼らは唯一の外部トラフィックを追跡するために、出口ルータで使用情報を記録することができます。 （これらは日常エンドシステムまたは中間システムネットワークアドレスより細かい粒度でレポートを実行するために属性を使用するだけのネットワークです。）
REGIONAL networks are intermediate networks. In some cases, subscribers will be enterprise networks, in which case the intermediate system network address is sufficient to identify the regional's immediate subscriber. In other cases, individual hosts or a disjoint group of hosts may constitute a subscriber. Then end-system network address pairs need to be tracked for those subscribers. When the source may be an aggregate entity (such as a network, or adjacent router representing traffic from a world of hosts beyond) and the destination is a singular entity (or vice versa), the meter is said to be operating as a HYBRID system.
地域ネットワークは、中間ネットワークです。いくつかのケースでは、加入者は、中間システムのネットワークアドレスは、地域の即時加入者を識別するのに十分である場合には、企業ネットワークになります。他の場合には、個々のホストまたはホストの互いに素なグループは、加入者を構成してもよいです。そして、エンドシステムのネットワーク・アドレスのペアは、それらの加入者のために追跡する必要があります。ソースは、（ネットワーク等、又は超えてホストの世界からのトラフィックを表す隣接ルータ）集約エンティティであってもよいし、先に特異エンティティ（またはその逆）である場合、計器は、ハイブリッドシステムとして動作していると言われます。
At the regional level, if the overhead is tolerable it may be advantageous to report usage both by intermediate system network address (e.g. adjacent router address) and by end-system network address or end-system network address pair.
地域レベルでのオーバーヘッドが許容される場合、中間システムのネットワークアドレス（例えば、隣接ルータアドレス）の両方によって使用量を報告することが有利であり得る、エンドシステムネットワークアドレスまたはエンドシステムネットワークアドレスのペアによって。
BACKBONE networks are the highest level networks operating at higher link speeds and traffic levels. The high volume of traffic will in most cases preclude detailed traffic flow measurement. Backbone networks will usually account for traffic by adjacent routers' network addresses.
バックボーンネットワークは、より高いリンク速度とトラフィックレベルで動作し、最高レベルのネットワークです。大量のトラフィックは、ほとんどの場合、詳細な交通流計測を排除します。バックボーンネットワークは通常、隣接するルータのネットワークアドレスによってトラフィックを占めることになります。
This Appendix provides a checklist of the attributes defined to date; others will be added later as the Traffic Measurement Architecture is further developed.
この付録では、これまでに定義された属性のチェックリストを提供します。トラフィック測定アーキテクチャをさらに発展されると他の人が、後に追加されます。
Note that this table gives only a very brief summary. The Meter MIB [RTFM-MIB] provides the definitive specification of attributes and their allowed values. The MIB variables which represent flow attributes have 'flowData' prepended to their names to indicate that they belong to the MIB's flowData table.
このテーブルはごく簡単な要約を与えることに注意してください。メーターMIB [RTFM-MIB]は属性とその許容値の決定的な仕様を提供します。フロー属性を表すMIB変数は、「flowDataは」彼らはMIBのflowDataテーブルに属していることを示すために、自分の名前の前に付けてきました。
0 Null
0ヌル
4 SourceInterface Integer Source Address 5 SourceAdjacentType Integer 6 SourceAdjacentAddress String 7 SourceAdjacentMask String 8 SourcePeerType Integer 9 SourcePeerAddress String 10 SourcePeerMask String 11 SourceTransType Integer 12 SourceTransAddress String 13 SourceTransMask String
4 SourceInterface整数ソースアドレス5 SourceAdjacentType整数6 SourceAdjacentAddress列7 SourceAdjacentMaskストリング8 SourcePeerType整数9 SourcePeerAddressストリング10 SourcePeerMask列11 SourceTransType整数12 SourceTransAddressストリング13 SourceTransMask列
14 DestInterface Integer Destination Address 15 DestAdjacentType Integer 16 DestAdjacentAddress String 17 DestAdjacentMask String 18 DestPeerType Integer 19 DestPeerAddress String 20 DestPeerMask String 21 DestTransType Integer 22 DestTransAddress String 23 DestTransMask String
14 DestInterface整数宛先アドレス15 DestAdjacentType整数16 DestAdjacentAddress列17列DestAdjacentMask 18 DestPeerType整数19 DestPeerAddress列20列DestPeerMask 21 DestTransType整数22 DestTransAddress列23列DestTransMask
26 RuleSet Integer Meter attribute
26ルールセット整数メーター属性
27 ToOctets Integer Source-to-Dest counters 28 ToPDUs Integer 29 FromOctets Integer Dest-to-Source counters 30 FromPDUs Integer 31 FirstTime Timestamp Activity times 32 LastActiveTime Timestamp 33 SourceSubscriberID String Session attributes 34 DestSubscriberID String 35 SessionID String
27 ToOctets整数ソース - destが整数取引先・ソース32 LastActiveTimeタイムスタンプ33 SourceSubscriberIDストリングセッション34 DestSubscriberIDストリング35セッションID列を属性30 FromPDUs整数31 FIRSTTIMEタイムスタンプアクティビティ時間カウンタ28 ToPDUs整数29 FromOctetsカウンタ
36 SourceClass Integer 'Computed' attributes 37 DestClass Integer 38 FlowClass Integer 39 SourceKind Integer 40 DestKind Integer 41 FlowKind Integer
36 sourceClassを整数 'コンピュー' は37 DestClass整数38 FlowClass整数39 SourceKind整数40 DestKind整数41 FlowKind整数属性
50 MatchingStoD Integer PME variable
50 MatchingStoD整数PME変数
51 v1 Integer Meter Variables 52 v2 Integer 53 v3 Integer 54 v4 Integer 55 v5 Integer
51個のV1整数メーター変数52 V2整数53 V3整数54 V4整数55 V5整数
65 .. 'Extended' attributes (to be defined by the RTFM working group) 127
65 .. 127（RTFMワーキンググループによって定義される）属性「拡張」
Meter variables:
Flood Mark Percentage
Inactivity Timeout (seconds) Integer
'per task' variables: Current Rule Set Number Integer Standby Rule Set Number Integer High Water Mark Percentage
変数のタスクごと '：現在のルール・セット数整数スタンバイ・ルール・セット数整数ハイウォーターマークの割合
'per reader' variables: Reader Last Time Timestamp
変数の読者あたり '：読者ラスト・タイムスタンプ
The first version of the Traffic Flow Measurement Architecture was published as RFC 2063 in January 1997. The most significant changes made since then are summarised below.
交通流計測アーキテクチャの最初のバージョンは、以降に行われた最も重要な変更は以下のとおりである1997年1月にRFC 2063として発行されました。
- A Traffic Meter can now run multiple rule sets concurrently. This makes a meter much more useful, and required only minimal changes to the architecture.
- 交通メーターは今同時に複数のルールセットを実行することができます。これは、メーターがはるかに便利になり、そしてアーキテクチャにのみ最小限の変更を要求しました。
- 'NoMatch' replaces 'Fail' as an action. This name was agreed to at the Working Group 1996 meeting in Montreal; it better indicates that although a particular match has failed, it may be tried again with the packet's addresses reversed.
- 「NOMATCHは」アクションとして「失敗」を置き換えます。この名前は、モントリオールのワーキンググループ1996年会議で合意されました。それは、より良い特定のマッチが失敗しているが、それは逆に、パケットのアドレスで再び試行することができることを示しています。
- The 'MatchingStoD' attribute has been added. This is a Packet Matching Engine (PME) attribute indicating that addresses are being matched in StoD (i.e. 'wire') order. It can be used to perform different actions when the match is retried, thereby simplifying some kinds of rule sets. It was discussed and agreed to at the San Jose meeting in 1996.
- 「MatchingStoD」属性が追加されました。これにより、アドレス（すなわち「ワイヤ」）順STODに一致していることを示すパケットマッチングエンジン（PME）属性です。それによってルールセットのいくつかの種類の簡素化、一致が再試行されたときに異なる動作を実行するために使用することができます。これは、1996年にサンノゼの会議で議論され、合意されました。
- Computed attributes (Class and Kind) may now be tested within a rule set. This lifts an unneccessary earlier restriction.
- 計算さ属性（クラスと種類は）今のルールセット内で試験することができます。これは、不必要な以前の制限を持ち上げます。
- The list of attribute numbers has been extended to define ranges for 'basic' attributes (in this document) and 'extended' attributes (currently being developed by the RTFM Working Group).
- 属性番号のリストは、「基本的な」（この文書の）属性と「拡張」の属性（現在はRTFMワーキンググループによって開発されている）の範囲を定義するために拡張されました。
- The 'Security Considerations' section has been completely rewritten. It provides an evaluation of traffic measurement security risks and their countermeasures.
- 「セキュリティの考慮事項」のセクションでは、完全に書き直されました。これは、トラフィック測定セキュリティリスクとその対応策の評価を提供します。
10 Acknowledgments
10の謝辞
An initial draft of this document was produced under the auspices
of the IETF's Internet Accounting Working Group with assistance
from SNMP, RMON and SAAG working groups. Particular thanks are
due to Stephen Stibler (IBM Research) for his patient and careful
comments during the preparation of this memo.
11 References
11の参考文献
[802-3] IEEE 802.3/ISO 8802-3 Information Processing Systems - Local Area Networks - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, 2nd edition, September 21, 1990.
[802から3] IEEE 802.3 / ISO 8802-3情報処理システム - ローカル・エリア・ネットワーク - パート3：衝突検出（CSMA / CD）アクセス方式および物理層仕様、第2版、1990年9月21日とキャリア検知多重アクセス。
[ACT-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting Background", RFC 1272, November 1991.
[ACT-BKG]ミルズ、C.、ハーシュ、G.とG.ルース、 "インターネット会計の背景"、RFC 1272、1991年11月。
[IANA-RFC] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-RFC] Alvestrand、H.、およびT. Narten氏、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[IPPM-FRM]パクソン、V.、Almes、G.、Mahdavi、J.とM.マティス、 "IPパフォーマンス・メトリックのためのフレームワーク"、RFC 2330、1998年5月。
[OSI-ACT] International Standards Organisation (ISO), "Management Framework", Part 4 of Information Processing Systems Open Systems Interconnection Basic Reference Model, ISO 7498-4, 1994.
[OSI-ACT]国際標準化機構（ISO）、「管理フレームワーク」、情報処理システム開放型システム間相互接続基本参照モデル、ISO 7498から4、1994のパート4。
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RTFM-MIB]ブラウンリー、N.、 "トラフィックフロー測定：メーターMIB"、RFC 2720、1999年10月。
[RTFM-NEW] Handelman, S., Stibler, S., Brownlee, N. and G. Ruth, "RTFM: New Attributes for Traffic Flow Measurment", RFC 2724, October 1999.
[RTFM-NEW] Handelman、S.、Stibler、S.、ブラウンリー、N.およびG.ルース、 "RTFM：トラフィックフローMeasurmentのための新しい属性"、RFC 2724、1999年10月。
[RTFM-SRL] Brownlee, N., "SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups", RFC 2723, October 1999.
[RTFM-SRL]ブラウンリー、N.、 "SRL：トラフィックフローを記述し、フローグループのアクションを指定するための言語"、RFC 2723、1999年10月。
12 Authors' Addresses
12本の著者のアドレス
Nevil Brownlee Information Technology Systems & Services The University of Auckland Private Bag 92-019 Auckland, New Zealand
Nevilブラウンリー情報技術システムアンドサービスオークランド専用バッグ92から019オークランド、ニュージーランドの大学
Phone: +64 9 373 7599 x8941 EMail: n.brownlee@auckland.ac.nz
電話：+64 9 373 7599 x8941メール：n.brownlee@auckland.ac.nz
Cyndi Mills GTE Laboratories, Inc 40 Sylvan Rd. Waltham, MA 02451, U.S.A.
シンディ・ミルズGTEラボラトリーズ社40シルバンRdを。ウォルサム、MA 02451、U.S.A.
Phone: +1 781 466 4278 EMail: cmills@gte.com
電話：+1 781 466 4278 Eメール：cmills@gte.com
Greg Ruth GTE Internetworking 3 Van de Graaff Drive P.O. Box 3073 Burlington, MA 01803, U.S.A.
3ファン・デ・グラーフドライブ私書箱をインターネットワーキンググレッグ・ルースGTEボックス3073バーリントン、MA 01803、U.S.A.
Phone: +1 781 262 4831 EMail: gruth@bbn.com
電話：+1 781 262 4831 Eメール：gruth@bbn.com
13 Full Copyright Statement
13完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。