[要約] RFC 2722は、トラフィックフローの測定に関するアーキテクチャについての要約です。このRFCの目的は、ネットワークトラフィックの測定方法とデータの収集方法を提案することです。
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.
Copyright（c）The Internet Society（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].
原則として、より高いレイヤーのアドレス属性を定義するかもしれませんが、一般的な方法でこれを行うことは非常に困難です。ただし、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.
トラフィック測定モデルの中心には、トラフィックメーターと呼ばれるネットワークエンティティがあります。メーターは、ネットワークを通過する途中で単一のポイントを通過し、特定のグループに分類するパケットを観察します。このようなグループごとに、メーターは特定の属性、たとえばグループで観察されるパケットとバイトの数など、蓄積されます。これらのメーターのトラフィックグループは、メーターの構成に応じて、ユーザー、ホストシステム、ネットワーク、ネットワークのグループ、特定のトランスポートアドレス（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.
トラフィックフロー測定の目的のために、交通フローの概念を定義します。これは、コールまたは接続に相当する人為的な論理的なものです。フローは、上記の計量された交通グループの1つに属する開始時間と停止時間によって区切られたトラフィックの一部です。フローに関連する属性値（ソース/宛先アドレス、パケットカウント、バイトカウントなど）は、開始時間と停止時間の間の期間中に発生するイベントを反映した総量です。流れの開始時間は、特定のフローに対して固定されています。停止時間は、流れの年齢とともに増加する可能性があります。
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.
流れやメーターに加えて、トラフィックフロー測定モデルには、マネージャー、メーターリーダー、および分析アプリケーションが含まれます。これらのアプリケーションは、次のセクションで説明されています。それらの間の関係は、以下の図で示されています。図の数字は、このドキュメントのセクションを参照してください。
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.
- マネージャー：トラフィック測定マネージャーは、「メーター」エンティティを構成し、「メーターリーダー」エンティティを制御するアプリケーションです。構成コマンドをメーターに送信し、各メーターおよびメーターリーダーの適切な操作を監督します。単一のネットワークエンティティ内のメーターリーダーとマネージャーの関数を組み合わせるのは便利かもしれません。
- 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 READER: A meter reader transports usage data from meters so that it is available to analysis applications.
- メーターリーダー：メーターリーダーはメートルから使用データを輸送して、分析アプリケーションで利用できるようにします。
- 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.
メーターリーダーは、1メートル以上の使用データを収集する場合があります。データはいつでもメーターから収集される場合があります。コレクションを何らかの形で同期する要件はありません。
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].
サンプリングに関するメモ：測定アーキテクチャの現在の経験は、慎重に設計され実装されたメーターがデータを十分にうまく圧縮し、通常のサンプリングが必要な場合はめったに必要なことはないことを示しています。このため、サンプリングアルゴリズムはアーキテクチャによって規定されていません。サンプリングが必要な場合、例えば細粒のフローで非常に高速ネットワークを測定するには、結果にバイアスをかけないように、サンプリング手法を慎重に選択する必要があります。このトピックの適切な紹介については、IPPMワーキンググループのRFC「IPパフォーマンスメトリックのフレームワーク」[IPPM-FRM]を参照してください。
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.
メーターは、1人以上のマネージャーに代わって同時にいくつかのルールセットを実行でき、マネージャーは1メートルにフロー仕様のセット（つまり「ルールセット」）をダウンロードできます。個々のルールセットに適用される制御パラメーターは、そのルールセットをダウンロードした後、マネージャーが設定する必要があります。
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.
いくつかのユニークに識別されたメーターは、1人以上のメーターの読者に報告する場合があります。上の図は、複数のメーターとメーターの読者をどのように使用できるかの例を示しています。
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は、同じネットワークセグメントのトラフィックを測定します。そのうちの1つは、セグメントの使用データを収集する他の人を残すことができない場合があります。メーター2と3は、メーターリーダーAおよびメーターリーダーBによって読み取られます。1つのメーターリーダーが失敗した場合、もう1メートルからの使用データを収集し続けます。
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は両方とも同じ間隔で使用データを収集することができますが、同時に否定的にはそうではありません。コレクションは非同期であるため、2つの異なるメーターリーダーからの使用レコードが正確に同意する可能性は低いことに注意してください。
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メートル以上から取得することはできないことに注意してください。
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.
- このフローでパケットが見られた最初と最後の時間、つまり、フローの「作成」と「最後のアクティビティ」時間。
- 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.
フローのメータートラフィックグループは、アドレス属性の値によって指定されます。たとえば、フローのアドレス属性が「ソースアドレス= IPアドレス10.1.0.1、宛先アドレス= IPアドレス26.1.0.1」として指定された場合、10.1.0.1から26.1.0.1のIPパケットのみがそのフローでカウントされます。。フローのアドレス属性が「ソースアドレス= IPアドレス10.1.0.1」のみを指定した場合、そのフローではすべてのIPパケットが10.1.0.1にカウントされます。
The addresses specifying a flow's address attributes may include one or more of the following types:
フローのアドレス属性を指定するアドレスには、次のタイプの1つ以上が含まれる場合があります。
- 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.
- 隣接するアドレス、つまり、特定のプロトコル階層化のインスタンス化におけるピアアドレスから次のレイヤーのアドレス。「隣接」は通常、リンク層を意味しますが、特定の形式のトンネルまたは階層化を暗黙的に提唱または却下することはありません。
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）アドレスになります。メーターと同じ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.
トラフィック測定アーキテクチャの重要な機能の1つは、属性が異なるプロトコルに対して本質的に同じ意味を持つため、分析アプリケーションがすべてのプロトコルに対して同じレポート形式を使用できることです。これは、ピアアドレスにとって簡単です。アドレスの形式はさまざまなプロトコルで異なりますが、「ピアアドレス」の意味は同じままです。この対応を高レイヤーで維持することが難しくなります。たとえば、ネットワークレイヤーIP、Novell 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.
各パケットのメータートラフィックグループの決定を制御するルールのセットは、メーターの現在のルールセットとして知られています。示されているように、Meterの現在のルールセットは、報告された情報の不可欠な部分を形成します。つまり、記録された使用情報は、その情報を収集するために使用されるルールの定義なしでは適切に解釈できません。
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.
- 他の属性値から派生した情報を記録する属性。これらのうち6つは定義されています（Sourcelass、Destclass、Flowclass、SourceKind、Destkind、Flowkind）、その意味はメーターのルールセットによって決定されます。たとえば、ソースまたは宛先のピアアドレスがネットワークの任意のリストのメンバーであるかどうかを決定するルールセットにサブルーチンを持つことができ、ソース/デスピアアドレスがリストに載っている場合、またはSourceClass/DestClassを1つに設定できます。それ以外の場合はゼロに。
- 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つの方法でアドレスのグループを集約できます。最も簡単なのは、単一のルールでマスクを使用して、マスクされたグループ内のアドレスをテストすることです。もう1つの方法は、一連のルールを使用して（マスクされた）アドレス値の任意のグループをテストし、プッシュルレートルールを使用して派生属性（flowキンドなど）を設定してフローのグループを示します。
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.
フローの寿命は、メーターがフローに属する最初のパケットを観察したときに始まり、最後のパケットを見たときに終了する時間間隔です。フローの寿命は非常に変動しますが、多くではないにしても、多くはかなり短いです。メーターは寿命を直接測定することはできません。代わりに、メーターリーダーは、最後のコレクション以来アクティブになっているフローの使用データを収集し、分析アプリケーションは各コレクションのデータを比較して、各フローが実際に停止した時期を決定することができます。
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と呼ばれる変数が含まれています。これは、フローのレコードを回復する前にメーターが待つ必要がある最小時間を指定します。さらに、フローレコードを回復する前に、メーターは、収集するために登録されたすべてのメーターリーダーによってフローのデータが収集されていることを確認する必要があります。これらの2つの待機条件は、メーターの望ましい目標です。通常の使用法で達成することは難しくありませんが、メーターはそれらを絶対に満たすことを保証することはできません。
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.
使用記録が送信されたら、既存のフローレコードをクリアするか、それらを維持し、同じフローの後続のトラフィックを記録するときにカウントに追加するかどうかを決定する必要があります。ローリングカウンターと呼ばれる2番目の方法が推奨され、いくつかの利点があります。その主な利点は、より大きな信頼性を提供することです - システムは、メーターリーダーが故障して後で再起動した場合に発生する可能性のある使用可能な使用レコードの損失に耐えることができるようになりました。次の使用記録には、失われた使用記録にある同じフローバケットの多くのさらに別の読み取りが含まれます。ローリングカウンターによって提供されるデータの「連続性」は、計算のエラーを防ぐために、データ自体の「正気」チェックに使用される情報を提供することもできます。
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
継続的な流れの古い流れ、そして新しい流れ
start time = 1 start time = 1
Usage record N: flow count = 2000 flow count = 2000 (done)
start time = 1 start time = 5
Usage record N+1: flow count = 3000 new flow count = 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.
継続的なフローの場合、そのカウントが2000年、再び3000で同じフローが報告されました。これまでの合計カウントは3000です。古い/新しい場合、古いフローは2000年のカウントでした。停止しましたが（おそらく一時的なアイドルのため）、同じ特性を持つトラフィックが増えたため、新しいフローレコードが開始され、すぐに1000のカウントに達しました。古いレコードと新しいレコードの両方からの合計フローカウントは3000です。
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.
フロースタートタイムスタンプ属性は、これを解決するのに十分です。上記の例では、2番目の使用率レコードの継続的なフローフローレコードには古いフロースタートタイムスタンプがあり、新しいフローには最近のフロースタートタイムスタンプが含まれています。散発的な活動のバーストが長い期間の不活性に散らばっているフローは、それぞれ同じアドレス属性のセットを持つ一連のフローアクティビティレコードを生成しますが、フロー開始時間が増加します。
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つのバケットを定義することです。それぞれが2つの基準のユニークな組み合わせを収集します。
Bucket 1: Packets which came in interface 1, AND were sourced by IP address a.b.c.d
バケット1：インターフェイス1に入ったパケット、IPアドレス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に登場する合計パケット」はバケット1と2を追加することで見つけることができ、「IPアドレスA.B.C.Dで供給された合計パケット」は、バケツ1と3を追加することで見つけることができます。その情報は興味がありませんが、ここでは完全性のために括弧内に提供されます。
Alternatively, the above could be achieved by running two rule sets (A and B), as follows:
あるいは、上記は、次のように2つのルールセット（AとB）を実行することで達成できます。
Bucket 1: Packets which came in interface 1; counted by rule set A.
バケット1：インターフェイス1に入ったパケット。ルールセット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つの方法は、フローキーの一部として各フローのルールセット番号属性を使用することです。
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で説明されているように、ルールセットで1回だけカウントされる場合がありますが、現在のルールセットのいずれでもカウントされる場合があります。これを行うことの全体的な効果は、ルールセットごとに1つの独立したメーターを実行することに多少似ています。
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:
すべてのトラフィックメーターは、「フローテーブル」、つまりメーターで見られるフローのトラフィックフローレコードのテーブルを維持します。フローテーブルの維持方法の詳細については、以下のセクション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.
- 非アクティブ：フローレコードはメーターでは使用されていません。
- 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.
- 現在：レコードは使用されており、「現在のフローセット」に属するフロー、つまり最近メーターで見られたフローのセットを説明しています。
- 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.
- アイドル：レコードが使用されており、それが説明するフローは現在のフローセットの一部です。さらに、このフローに属するパケットは、メーターの非活動時間変数によって指定された期間にわたって見られませんでした。
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 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のプログラムです。パケットの一致キーには、ソースと宛先（d）インターフェイスのアイデンティティ、アドレス値、マスクが含まれています。
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は、パケットに一致するように1回呼び出されます。成功した一致によって生成されたフローキーは、フローテーブルでフローのレコードを見つけるために使用され、そのフローのカウンターは更新されます。
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.
ただし、プロトコルインターチェンジまたは「セッション」の前方パケットと逆パケットを反映して、フローは双方向です。メーターのフローレコードに2セットのカウンターを維持すると、結果のフローデータの処理がはるかに簡単になります。分析プログラムでは、セッションの「フォワード」コンポーネントと「逆」コンポーネントを収集する必要がないためです。パケットが「フォワード」パケットか「逆」パケットであるかを決定する必要があるため、もちろん、双方向フローの実装は、メーターにとってより困難です。この決定を下すために、メーターは多くの場合、可能なパケット方向ごとに1回、PMEを2回呼び出す必要があります。
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.
- パケットはどちらの方向にも一致します。これが発生する可能性のある状況の1つは、ネットワークX（Source = X、Dest = X）内のフローに一致するルールセットですが、ネットワークX内の各サブネット（サブネットYとZなどの各サブネット）が作成されることを指定します。たとえば、y-> zに対してパケットが見られる場合、メーターはy-> zを作成する前にフローz-> yがまだ電流ではないことを確認する必要があります。
- 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を実装します。Meterの現在のルールセットを使用して、パケットのマッチキーの属性値を一致させます。a-> bは、想定されるソースアドレスがaと宛先アドレスbであることを意味します。つまり、パケットがaからBから移動していたことを意味します。
'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.
流れa-t-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）create a-to-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).
count（a-> b、f）フローa-to-bの「フォワード」カウンターを増加させます。count（a-> b、r）フローa-to-bの「逆」カウンターを増加させます。ここでの「フォワード」とは、aからBまで走行するパケットのカウンターを意味します。カウント（> b、f）はcount（b-> a、r）と同じであることに注意してください。
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.
書き込みルールを設定するとき、メーターは通常、フォワードマッチが成功しない場合、各パケットを逆方向に一致させようとすることを覚えておく必要があります。ルールセットに、このプロセスを混乱させる矛盾が含まれていないことが特に重要です。
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.
たとえば、ソースネットワークAから宛先ネットワークBへのパケットをカウントするルールセットを検討しますが、ネットワーク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.
時には、ルールセットがパケットが一致している方向を知る必要がある場合に、状況がある場合があります。たとえば、「珍しい」パケットの属性値（おそらくソースと宛先アドレス）を保存したいルールセットを検討してください。ルールセットには、すべての「通常の」ソースアドレスの一連のテストが含まれ、「ノマッチ」アクションを実行するルールが続きます。一致が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.
このような「珍しい」パケットを数えるには、一致する方向を知る必要があります。一致する属性はこれを提供します。それを使用するには、一致する方向がs-> dであるかどうかをテストするルールを使用して、ソースアドレステストに従います（一致するストッド値は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の指示には5つのコンポーネントフィールドがあり、次のように2つの論理グループを形成します。
+-------- 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は属性の値をテストできます。これは、属性値をマスクでandingし、結果を値フィールドと比較することによって行われます。範囲をテストするための明示的な規定はないことに注意してください。ただし、これは範囲をマスクでカバーできる場合に実行できます。属性値は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は、「テストインジケーター」と呼ばれるブールインジケーターを維持し、ルールのテストが実行されるかどうかを決定します。テストインジケーターは最初に設定されています（TRUE）。
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:
アクショングループは、ルールが実行されたときに実行できるアクションを指定します。Opcodesには、以下の表に詳述されているように、「GoTo」と「テスト」の2つのフラグが含まれています。実行は、ルールセットの最初のルール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の場合：テスト、つまりマスクで属性値を実行し、値と比較します。これらが等しい場合、テストは成功しました。ルールのアクションを実行します（以下）。テストが失敗した場合、ルールセットの次のルールを実行します。ルールセットにこれ以上のルールがない場合は、Nomatchを示すMatch（）関数から戻ります。
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.
テストインジケーターがfalseの場合、またはテスト（上記）が成功した場合：テストインジケーターをこのOpcodeのテストフラグ値に設定します。実行する次のルールを決定します。OpCodeにGOTOフラグが設定されている場合、そのパラメーター値は次のルールの数を指定します。gotoフラグが設定されていないオペコードは、特別な方法で次のルールを決定するか、実行を終了します（Ingrore、nomatch、count、countpkt）。アクションを実行します。
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つの「履歴」データ構造を維持しています。最初の「リターン」スタックは、実行される各GoSubルールのインデックス（つまり、1-Originルール番号）を単純に記録します。ReturnルールはGOSUBルールインデックスをポップします。Ingrore、Nomatch、Count、および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.
2番目のデータ構造である「パターン」キューは、フローキーを構築する際に後で使用するための情報を保存するために使用されます。フローキーは、すべての属性値をゼロにして、属性番号、マスク、および値情報をパターンキューからコピーして囲まれた順序で構築されます。
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
OPCODE GOTOテスト
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
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のパターンキューに保存し、このパケットが属するフローのフローキーを作成します。Match（）関数から戻り、成功を示します。メーターはフローキーを使用して、このパケットのフローのフローレコードを検索します。
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).
サブルーチンの呼び出しは、GOSUBルールとして、次のルールの小さなグループが続くルールセットに表示されます。リターンアクションがテストフラグをクリアするため、これらの「次の」ルールのいずれかのアクションが実行されます。これにより、サブルーチンは結果を返すことができます（PMEのパターンキューに保存する可能性のある情報に加えて）。
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.
assight：Assignと同じですが、指定されたルールに移動する前にテストインジケーターがクリアされていることを除きます。
Goto: Set the test indicator then goto the specified rule.
goto：テストインジケーターを設定し、指定されたルールをGOTOに設定します。
GotoAct: Clear the test indicator then goto the specified rule.
gotoact：テストインジケーターをクリアし、指定されたルールをgotoします。
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.
PushRuletoアクションを使用して、テストで使用される値とマスク、または（テストが実行されていない場合）任意の値とマスクを保存するために使用できます。
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).
Pushpkttoアクションを使用して、指定されたマスクを使用してパケットヘッダーから値を保存できます。これをプログラムする最も簡単な方法は、Pushpkttoルールの値フィールドにゼロ値を使用し、PushPkttoルールにgotoAct（テストが実行されないように）を使用することです。
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:
PMEは、パケット（SourcePeerAddress、Dest TransAddressなど）に直接適用する属性と同様に、さらにいくつかの属性を実装しています。これらは：
Null: Tests performed on the Null attribute always succeed.
null：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がマッチング中に構築された（フローレコード内の）情報を保存できるようにします。それらの値はルールでテストされる場合があります。これにより、ルールセットの早い段階でそれらを設定し、後でテストすることができます。
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.
上記で詳述されているオペコード（上記の「goto」値と「テスト」値が最小セットを形成しますが、現在のメーターの実装では非常に効果的であることが証明されています。時々、さらにオペコードを追加すると便利かもしれません。これらを割り当てるための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.
パケットが流れにないフローと一致するたびに、フローレコードが作成されます。そのようなレコードの状態は「現在」です。新しいフローのレコードを選択するとき、メーターはフローテーブルを「非アクティブ」レコードのために検索します。非アクティブなレコードが利用できない場合、代わりに「アイドル」レコードを検索します。フローテーブル内のレコードの順序に特に意味がないことに注意してください。
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変数を維持します。2番目の変数である非アクティブタイムは、フローがアイドル状態であると考える前に、メーターが待つ最小時間を指定します。
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.
考えられる回復戦略の1つは、登録したすべての読者によってデータが収集された後、できるだけ早くアイドルフローレコードを回復することです。これを実装するために、メーターは、「最後のパケット」時間がメーターの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.
別の回復戦略は、アイドルフローをできるだけ長く放置することです。これは、総交通量の測定にのみ関心がある場合に受け入れられます。収集されたアイドルフローのメーター検索で、「非アクティブ」フローレコードで低く走った場合にのみ実装できます。
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.
フローを回復する前に、メーターが考慮すべきもう1つの要因は、フローのデータを収集したメーターリーダーの数です。複数のメーターリーダーが動作している場合、各リーダーはメモリが回復する前にフローのデータを収集する必要があります。
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.
パケットが分類され、カウントされる準備ができたら、フローテーブルに適切なフローデータレコードが既に存在する必要があります。それ以外の場合は、作成する必要があります。フローレコードには、不必要な識別属性が省略される可能性のある柔軟な形式があります。使用するフローレコードの属性の決定、およびそれらにどのような値を置くかの決定は、現在のルールセットによって指定されます。
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.
現在のルールセットは、追加情報を指定する場合があります。Flowキンドなどの計算された属性値。これは、使用レコードの属性セクションに配置されます。つまり、特定のフローがルールセットによって一致する場合、対応するフローレコードは、適格な識別属性だけでなく、追加情報もマークする必要があります。この機能を使用すると、いくつかのフローがそれぞれ同じフローキンド値を運ぶ可能性があります。そのため、結果の使用レコードは、ポストプロセッシングまたはメーターリーダーとメーターの間で、収集の基準として使用できます。
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つのファイル、メーターリーダーのフローデータファイルに保存されます。測定された使用データを含めるだけでなく、フローデータファイルには、収集されたメーターを一意に識別する情報を含める必要があります。
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.
各使用レコードには、メーターのメーターのトラフィックグループ識別子（ネットワークアドレスのセット）、タイムスタンプ、報告されたフローのリスト（フローデータレコード）が含まれています。メーターリーダーは、メーターからフローデータを定期的に収集し、このデータを使用して使用レコードを構築し、ファイルのテールに連結することにより、使用レコードのファイルを構築します。このようなファイルは、フローデータファイルと呼ばれます。
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を使用することです。「トラフィックフロー測定：Meter 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.
- ダウンロードルールセット：メーターはルールセットの配列を保持する場合があります。これらの1つである「デフォルト」ルールセットは、メーターに組み込まれており、変更することはできません。これは診断機能であり、メーターが起動したときに既知のルールセットを実行することを保証します。
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.
- メータータスクの指定：ルールセットがダウンロードされたら、マネージャーは、メーターが実行する各タスクの「現在」のセットであるルールセットになるメーターに指示する必要があります。
- 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.
- 非アクティブなタイムアウトを設定：これは、フローの最後のパケットが見られてから数秒での時間です。フロー記録は、少なくともこの時間はアイドル状態であり、現在のコレクション基準に従って収集されている場合、回収される可能性があります。
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.
マネージャーが異なるタスクのフロー終了パラメーターを異なる値に設定できる場合に役立つ場合があります。現在のメーターの実装には、これらのパラメーターの単一の（「全体のメーター」）値しかありません。これまでの経験は、これがタスクに適切な程度の制御を提供することを示唆しています。
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.
- マネージャーおよびメーターリーダーの識別：マネージャーは、メーターが正しいメーターリーダーのセットによって読み取られることを確認し、使用情報への不正アクセスを防ぐための措置を講じる必要があります。そのように特定されたメーターの読者は、必要に応じて投票し、適切なメーターからのデータを受け入れる準備をする必要があります。プライマリマネージャーとプライマリメーターリーダーの両方が利用できない場合に、代替メーターリーダーが識別される場合があります。同様に、代替マネージャーが特定される場合があります。
- 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:
- Granularity Control：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.
- フローライフタイムコントロール：フロー終了パラメーターには、非アクティブフローを廃止し、テーブルからそれらを除去するためのタイムアウトパラメーター、および最大フロー寿命が含まれます。これは、報告間隔と粒度と絡み合っており、他のパラメーターに従って設定する必要があります。
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:
例外条件は、特にメーターがフローデータのためにスペースがなくなる場合に処理する必要があります。なぜなら、アクティブなタスクがパケットを2回カウントするのを防ぐために、パケットは単一のフローでのみカウントできますが、レコードを破棄すると情報が失われます。これに対処するメカニズムは次のとおりです。
- 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.
- メーターの停止：差し迫ったメーターの停止（制御された再起動など）の場合、メーターはマネージャーにtrapを送信できます。その後、マネージャーは、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.
- メーターリーダーの停止：コレクションシステムがダウンまたは分離されている場合、メーターはマネージャーにコレクションシステムとの通信の失敗を通知しようとする必要があります。Flowsのローリングカウンターで使用データが維持され、メーターリーダーが再起動されると回復できます。
- MANAGER OUTAGES: If the manager fails for any reason, the meter should continue measuring and the meter reader(s) should keep gathering usage records.
- マネージャーの停止：何らかの理由でマネージャーが失敗した場合、メーターは測定を続け、メーターリーダーは使用記録を収集し続ける必要があります。
- 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.
- 隣接するシステム：METERは、隣接するシステムの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つのインターフェイスレポートENDシステムの場合、別のインターフェイスレポートに隣接するシステムをレポートします。この戦略は、エンタープライズネットワークで使用されて、ローカルの使用に関する詳細を学び、共有された地域ネットワークに集計カウントを使用する場合があります。
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.
- トラフィックメーターを無効にしようとする試み：攻撃者は、ネットワークの使用に対してユーザーが請求されるのを防ぐために、トラフィックの測定を混乱させようとする場合があります。たとえば、ネットワークプローブが多数の宛先と輸送アドレスにパケットを送信すると、メーターのフローテーブルのフロー数が突然増加する可能性があるため、粗いスタンバイルールセットを使用することが強制されます。
- 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.
- トラフィックメーターを無効にしようとすると、完全に反論することはできません。実際には、ネットワークセキュリティ攻撃からのフローデータレコードは、何が起こったのかを判断するのに非常に役立ちました。最も効果的なアプローチは、最初にメーターを構成して、通常の動作で必要なフローメモリの3倍以上のフローメモリを備え、2つ目はフローデータをかなり頻繁に収集して、フローメモリを回復するために必要な時間を最小限に抑えるためにかなり頻繁に収集することです。そのような攻撃。
- 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:
トラフィック測定システムは、これらすべての懸念に対処する必要があります。高度な保護が必要であるため、強力な暗号化方法の使用が推奨されます。トラフィック測定システム要素のペア間の通信のセキュリティ要件を以下の表にまとめます。メーターは他のメーターと通信せず、メーターリーダーは他のメーターリーダーと直接通信しないと想定されています（同期が必要な場合は、マネージャーによって処理されます。セクション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
- 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'.
- 2つの要素が相互に通信する場合、相互に自らを認証する必要があります。これは、テーブルの「信頼」で示されています。認証が完了したら、要素が要求されたタイプのアクセスが許可されていることを確認する必要があります。これは、「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.
このドキュメントでは、セキュリティプロトコルは指定されていません。System Elementsの管理プロトコルは、十分なデータの整合性、機密性、認証、およびアクセス制御サービスを提供する責任があります。
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の考慮事項のガイドライン」文書[IANA-RFC]に記載されているポリシーの例を使用します。
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ルールの「アクション」フィールドに表示されます。Opcodesの現在のリストとPMEの「GOTO」フラグと「テスト」フラグの値は、上記のセクション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].
PMEオペコードは、すべてのRTFMメーターで実装する必要があるため、RTFMアーキテクチャに極めて重要です。したがって、新しいオペコードは、IETFコンセンサスアクション[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コンセンサスアクション[IANA-RFC]に従って割り当てられます。このドキュメントの付録Cでは、基本的な（つまり、有用な最小値）属性セットを割り当てます。これらは、0〜63の範囲に割り当てられています。RTFMワーキンググループは、64〜127の範囲に数値を持つ拡張属性セットに取り組んでいます。
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の範囲にあり、First Come First Server Policy [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ステートメントでテストされた - 保存ステートメントによって保存されているか、ストアステートメントによって設定されている - RTFMメーターから読む
(IF, SAVE and STORE are statements in the SRL Ruleset Language [RTFM-SRL]).
（保存して保存して、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/Enterprise Networksは、ホストとローカルエリアネットワークを接続します。Stub/Enterprise Networksは、地域およびバックボーンネットワークの加入者です。
END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above networks.
口語的ホストであるエンドシステムは、上記のネットワークのいずれかのサブスクライバーです。
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
エンドシステム（ユーザー/アカウントなど）よりも細かい粒度でサブスクライバーの均一な識別を提供することは、現在のアーキテクチャの範囲を超えていますが、トラフィックフロー測定レコードのオプションの属性はシステム固有のものを運ぶ可能性があります。
'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 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).
エンドシステムは現在、この機能が必要な場合、エンドユーザーにネットワーク使用を割り当てる責任があります。インターネットプロトコルの観点から見ると、エンドシステムは、プロトコルの変更なしで識別できる最高の粒度です。メーターがプロトコルの境界に違反し、高レベルのプロトコルを追跡したとしても、すべてのパケットがユーザーによって正しく割り当てられるわけではなく、ユーザー自体の定義がオペレーティングシステムごとに大きく異なります（たとえば、ネットワークの使用量を共有からユーザーにトレースする方法プロセス）。
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.)
StubおよびEnterpriseネットワークは通常、ローカルエリアネットワークで詳細なレポートが必要な場合、エンドシステムネットワークアドレスまたはネットワークアドレスペアのいずれかによってトラフィックデータを収集します。ローカルレポートが不要な場合、外部トラフィックのみを追跡するために出口ルーターに使用情報を記録する場合があります。（これらは、属性を日常的に使用して、エンドシステムまたは中間システムのネットワークアドレスよりも細かい粒度でレポートを実行する唯一のネットワークです。）
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.
このテーブルは非常に簡単な要約のみを提供していることに注意してください。Meter 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 Integer Sourceアドレス5 SourceadjacentType Integer 6 SourceadjacentAddress String 7 Sourceadjacentmask String 8 SourcePeertype Integer 9 SourcePeerAddress String 10 SourcePeermask String SourcetranStype Integer 12 SourcetransAddress String 13 Sourcetransmask String String
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
26 RuleSet Integer Meter attribute
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
36 SourceClass Integer 'Computed' attributes
37 DestClass Integer
38 FlowClass Integer
39 SourceKind Integer
40 DestKind Integer
41 FlowKind Integer
50 MatchingStoD Integer PME variable
50 MatchingStod Integer PME変数
51 v1 Integer Meter Variables
52 v2 Integer
53 v3 Integer
54 v4 Integer
55 v5 Integer
65 .. 'Extended' attributes (to be defined by the RTFM working group) 127
65 ..「拡張」属性（RTFMワーキンググループによって定義される）127
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.
この文書の最初のドラフトは、SNMP、RMON、およびSAAGワーキンググループの支援を受けて、IETFのインターネット会計ワーキンググループの後援の下で作成されました。特に感謝しているのは、スティーブン・スティブラー（IBM Research）の患者とこのメモの準備中の慎重なコメントです。
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] Mills、C.、Hirsch、G。and G. Ruth、「インターネット会計の背景」、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] Paxson、V.、Almes、G.、Mahdavi、J。およびM. Mathis、「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] International Standards Organization（ISO）、「Management Framework」、情報処理システムのパート4オープンシステムの相互接続基準参照モデル、ISO 7498-4、1994。
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RTFM-MIB]ブラウンリー、N。、「トラフィックフロー測定：Meter 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.、Brownlee、N。and G. Ruth、「RTFM：トラフィックフロー測定の新しい属性」、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] Brownlee、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 Brownlee Information Technology Systems＆Servicesオークランド大学プライベートバッグ92-019オークランド、ニュージーランド
Phone: +64 9 373 7599 x8941
EMail: n.brownlee@auckland.ac.nz
Cyndi Mills GTE Laboratories, Inc 40 Sylvan Rd. Waltham, MA 02451, U.S.A.
Cyndi Mills Gte Laboratories、Inc 40 Sylvan Rd。ウォルサム、マサチューセッツ州02451、米国
Phone: +1 781 466 4278
EMail: cmills@gte.com
Greg Ruth GTE Internetworking 3 Van de Graaff Drive P.O. Box 3073 Burlington, MA 01803, U.S.A.
Greg Ruth GTEインターネットワーク3 van de Graaff Drive P.O.Box 3073バーリントン、マサチューセッツ州01803、米国
Phone: +1 781 262 4831
EMail: gruth@bbn.com
13 Full Copyright Statement
13完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。