[要約] RFC 2724は、トラフィックフローの測定に関する新しい属性についての要約です。このRFCの目的は、ネットワークトラフィックの詳細な測定と分析を可能にするために、新しい属性を定義することです。
Network Working Group S. Handelman
Request for Comments: 2724 S. Stibler
Category: Experimental IBM
N. Brownlee
The University of Auckland
G. Ruth
GTE Internetworking
October 1999
RTFM: New Attributes for Traffic Flow Measurement
RTFM：トラフィックフロー測定の新しい属性
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes.
RTFMトラフィック測定アーキテクチャは、ネットワークトラフィックフローを説明および測定するための一般的なフレームワークを提供します。フローは、アドレス属性値の観点から定義され、「トラフィックメーター」で測定されます。このドキュメントでは、新しい属性を追加してアーキテクチャを拡張するための論理的なフレームワークを提供するために、RTFMフローとそれらが持つことができる属性について説明します。
Extensions described include Address Attributes such as DSCodePoint, SourceASN and DestASN, and Group Attributes such as short-term bit rates and turnaround times. Quality of Service parameters for Integrated Services are also discussed.
説明されている拡張機能には、DSCodePoint、SourceAsn、Destasnなどのアドレス属性、および短期ビットレートやターンアラウンド時間などのグループ属性が含まれます。統合サービスの品質パラメーターについても説明します。
Table of Contents
目次
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 RTFM's Definition of Flows . . . . . . . . . . . . . . . . 3
1.2 RTFM's Current Definition of Flows and their Attributes . . 3
1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 4
2 Flow Abstractions . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Meter Readers and Meters . . . . . . . . . . . . . . . . . 5
2.2 Attribute Types . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Packet Traces . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Aggregate Attributes . . . . . . . . . . . . . . . . . . . 8
2.5 Group Attributes . . . . . . . . . . . . . . . . . . . . . 8
2.6 Actions on Exceptions . . . . . . . . . . . . . . . . . . .10
3 Extensions to the 'Basic' RTFM Meter . . . . . . . . . . . . .10
3.1 Flow table extensions . . . . . . . . . . . . . . . . . . .10
3.2 Specifying Distributions in RuleSets . . . . . . . . . . .11
3.3 Reading Distributions . . . . . . . . . . . . . . . . . . .13
4 Extensions to the Rules Table, Attribute Numbers . . . . . . .13
5 Security Considerations . . . . . . . . . . . . . . . . . . . .15
6 References . . . . . . . . . . . . . . . . . . . . . . . . . .16
7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .17
8 Full Copyright Statement . . . . . . . . . . . . . . . . . . .18
1 Introduction
1はじめに
The Real-Time Flow Measurement (RTFM) Working Group (WG) has developed a system for measuring and reporting information about traffic flows in the Internet. This document explores the definition of extensions to the flow measurements as currently defined in [RTFM-ARC]. The new attributes described in this document will be useful for monitoring network performance and will expand the scope of RTFM beyond simple measurement of traffic volumes. A companion document to this memo will be written to define MIB structures for the new attributes.
リアルタイムフロー測定（RTFM）ワーキンググループ（WG）は、インターネットのトラフィックフローに関する情報を測定および報告するシステムを開発しました。このドキュメントでは、現在[RTFM-ARC]で定義されているように、フロー測定の拡張の定義を調査します。このドキュメントで説明されている新しい属性は、ネットワークパフォーマンスの監視に役立ち、トラフィックボリュームの単純な測定を超えてRTFMの範囲を拡大します。このメモのコンパニオンドキュメントは、新しい属性のMIB構造を定義するために書かれています。
This memo was started in 1996 to advance the work of the RTFM group. The goal of this work is to produce a simple set of abstractions, which can be easily implemented and at the same time enhance the value of RTFM Meters. This document also defines a method for organizing the flow abstractions to augment the existing RTFM flow table.
このメモは、RTFMグループの作業を進めるために1996年に開始されました。この作業の目標は、簡単な抽象化のセットを作成することです。これは簡単に実装でき、同時にRTFMメーターの値を高めることができます。このドキュメントは、既存のRTFMフローテーブルを強化するためにフロー抽象化を整理する方法も定義します。
Implementations of the RTFM Meter have been done by Nevil Brownlee in the University of Auckland, NZ, and Stephen Stibler and Sig Handelman at IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role of the Meter Reader whose role is to retrieve flow data from the Meter.
RTFMメーターの実装は、ニュージャージー州オークランド大学のNevil Brownleeと、米国ニューヨーク州ホーソーンのIBMでStephen StiblerとSig Handelmanによって行われました。RTFM WGは、メーターからフローデータを取得することであるメーターリーダーの役割も定義しています。
Note on flows and positioning of meters:
メーターのフローとポジショニングに関するメモ：
A flow as it traverses the Internet may have some of its characteristics altered as it travels through Routers, Switches, and other network units. It is important to note the spatial location of the Meter when referring to attributes of a flow. An example, a server may send a sequence of packets with a definite order, and inter packet timing with a leaky bucket algorithm. A meter reading downstream of the leaky bucket would record a set with minimal inter packet timing due to the leaky bucket. At the client's location, the packets may arrive out of sequence, with the timings altered. A meter at the client's location would record different attributes for the same flow.
インターネットを通過するフローは、ルーター、スイッチ、およびその他のネットワークユニットを介して移動する際に、その特性の一部が変更される場合があります。フローの属性を参照する場合、メーターの空間位置に注意することが重要です。たとえば、サーバーは、明確な順序でパケットのシーケンスを送信し、漏れやすいバケットアルゴリズムを使用したパケット間タイミングを送信する場合があります。漏れやすいバケツの下流のメーター読み取りは、漏れやすいバケツのために最小限のインターパケットタイミングでセットを録音します。クライアントの場所では、パケットがシーケンスから到着し、タイミングが変更される場合があります。クライアントの位置のメーターは、同じフローの異なる属性を記録します。
The RTFM Meter architecture views a flow as a set of packets between two endpoints (as defined by their source and destination attribute values and start and end times), and as BI-DIRECTIONAL (i.e. the meter effectively monitors two sub-flows, one in each direction).
RTFMメーターアーキテクチャは、フローを2つのエンドポイント間のパケットのセットとして表示します（ソースと宛先の属性値と開始時間と終了時間で定義されています）、および双方向（つまり、メーターは2つのサブフローを効果的に監視します。各方向）。
Reasons why RTFM flows are bi-directional:
RTFMフローが双方向である理由：
- The WG is interested in understanding the behavior of sessions between endpoints.
- WGは、エンドポイント間のセッションの動作を理解することに関心があります。
- The endpoint attribute values (the "Address" and "Type" ones) are the same for both directions; storing them in bi-directional flows reduces the meter's memory demands.
- エンドポイント属性の値（「アドレス」と「タイプ」の値）は、両方の方向で同じです。それらを双方向のフローに保存すると、メーターのメモリの要求が減少します。
- 'One-way' (uni-directional) flows are a degenerate case. Existing RTFM meters can handle this by using one of the computed attributes (e.g. FlowKind) to indicate direction.
- 「一方向」（単方向）フローは退化したケースです。既存のRTFMメーターは、計算された属性のいずれかを使用してこれを処理し、方向を示すことができます。
Flows, as described in the "Architecture" document [RTFM-ARC] have the following properties:
「アーキテクチャ」ドキュメント[RTFM-ARC]に記載されているように、フローには次の特性があります。
a. They occur between two endpoints, specified as sets of attribute values in the meter's current rule set. A flow is completely identified by its set of endpoint attribute values.
a. それらは、メーターの現在のルールセットで属性値のセットとして指定された2つのエンドポイントの間で発生します。フローは、そのエンドポイント属性値のセットによって完全に識別されます。
b. Each flow may also have values for "computed" attributes (Class and Kind). These are directly derived from the endpoint attribute values.
b. 各フローには、「計算された」属性（クラスと種類）の値もあります。これらは、エンドポイント属性値から直接導出されます。
c. A new flow is created when a packet is to be counted that does not match the attributes of an existing flow. The meter records the time when this new flow is created.
c. 既存のフローの属性と一致しないパケットをカウントする場合、新しいフローが作成されます。メーターは、この新しいフローが作成される時間を記録します。
d. Attribute values in (a), (b) and (c) are set when the meter sees the first packet for the flow, and are never changed.
d. （a）、（b）、および（c）の属性値は、メーターがフローの最初のパケットを見たときに設定され、決して変更されません。
e. Each flow has a "LastTime" attribute, which indicates the time the meter last saw a packet for the flow.
e. 各フローには「最後の」属性があり、メーターが最後にフローのパケットを見た時間を示します。
f. Each flow has two packet and two byte counters, one for each flow direction (Forward and Backward). These are updated as packets for the flow are observed by the meter.
f. 各フローには、2つのパケットと2つのバイトカウンターがあります。1つはフロー方向（前方と後方）です。これらは、フローのパケットがメーターによって観察されると更新されます。
g. ALL the attributes have (more or less) the same meaning for a variety of protocols; IPX, AppleTalk, DECnet and CLNS as well as TCP/IP.
g. すべての属性は、さまざまなプロトコルに対して（多かれ少なかれ）同じ意味を持っています。IPX、AppleTalk、DecNet、CLN、およびTCP/IP。
Current flow attributes - as described above - fit very well into the SNMP data model. They are either static, or are continuously updated counters. They are NEVER reset. In this document they will be referred to as "old-style" attributes.
現在のフロー属性 - 上記のように - SNMPデータモデルに非常によく適合します。それらは静的であるか、連続的に更新されたカウンターです。それらは決してリセットされません。このドキュメントでは、それらは「古いスタイルの」属性と呼ばれます。
It is easy to add further "old-style" attributes, since they don't require any new features in the architecture. For example:
アーキテクチャに新しい機能を必要としないため、さらに「古いスタイルの」属性を追加するのは簡単です。例えば：
- Count of the number of "lost" packets (determined by watching sequence number fields for packets in each direction; only available for protocols which have such sequence numbers).
- 「失われた」パケットの数のカウント（各方向のパケットのシーケンス番号フィールドを監視することにより決定されます。そのようなシーケンス番号を持つプロトコルでのみ利用可能）。
- In the future, RTFM could coordinate directly with the Flow Label from the IPv6 header.
- 将来、RTFMはIPv6ヘッダーからのフローラベルと直接調整できます。
The concept of flows has been studied in various different contexts. For the purpose of extending RTFM, a starting point is the work of the Integrated Services WG. We will measure quantities that are often set by Integrated Services configuration programs. We will look at the work of the Benchmarking/IP Performance Metrics Working Group, and also look at the work of Claffy, Braun and Polyzos [C-B-P]. We will demonstrate how RTFM can compute throughput, packet loss, and delays from flows.
フローの概念は、さまざまなコンテキストで研究されています。RTFMを拡張する目的のために、出発点は統合サービスWGの作業です。統合されたサービス構成プログラムによってしばしば設定される量を測定します。ベンチマーク/IPパフォーマンスメトリックワーキンググループの作業を検討し、Claffy、Braun、Polyzos [C-B-P]の作業も見ていきます。RTFMがフローからのスループット、パケットの損失、遅延を計算する方法を示します。
An example of the use of capacity and performance information is found in "The Use of RSVP with IETF Integrated Services" [IIS-RSVP]. RSVP's use of Integrated Services revolves around Token Bucket Rate, Token Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum Packet Size, and the Slack term. These are set by TSpec, ADspec and FLowspec (Integrated Services Keywords), and are used in configuration and operation of Integrated Services. RTFM could monitor explicitly Peak Data Rate, Minimum Policed Unit, Maximum Packet Size, and the Slack term. RTFM could infer details of the Token Bucket. The WG will develop measures to work with these service metrics. An initial implementation of IIS Monitoring has been developd at CEFRIEL in Italy [IIS-ACCT].
容量とパフォーマンス情報の使用の例は、「IETF統合サービスを使用したRSVPの使用」[IIS-RSVP]にあります。RSVPの統合サービスの使用は、トークンバケットレート、トークンバケットサイズ、ピークデータレート、最小ポリシーユニット、最大パケットサイズ、およびスラック用語を中心に展開します。これらは、TSPEC、ADSPEC、FlowsPec（統合サービスキーワード）によって設定され、統合サービスの構成と操作で使用されます。RTFMは、明示的にピークデータレート、最小ポリシーユニット、最大パケットサイズ、およびスラック用語を監視できます。RTFMは、トークンバケットの詳細を推測できます。WGは、これらのサービスメトリックを使用するための措置を開発します。IISモニタリングの最初の実装は、イタリアのCefrielで開発されました[IIS-ACCT]。
RTFM will work with several traffic measurements identified by IPPM [IPPM-FRM]. There are three broad areas in which RTFM is useful for IPPM.
RTFMは、IPPM [IPPM-FRM]によって特定されたいくつかのトラフィック測定で動作します。RTFMがIPPMに役立つ3つの広い領域があります。
- An RTFM Meter could act as a passive device, gathering traffic and performance statistics at appropriate places in networks (server or client locations).
- RTFMメーターは、ネットワーク（サーバーまたはクライアントの場所）の適切な場所にトラフィックとパフォーマンス統計を収集し、パッシブデバイスとして機能する可能性があります。
- RTFM could give detailed analyses of IPPM test flows that pass through the Network segment that RTFM is monitoring.
- RTFMは、RTFMが監視しているネットワークセグメントを通過するIPPMテストフローの詳細な分析を提供できます。
- RTFM could be used to identify the most-used paths in a network mesh, so that detailed IPPM work could be applied to these most used paths.
- RTFMを使用して、ネットワークメッシュ内の最も使用されているパスを識別できるため、詳細なIPPM作業をこれらの最も使用しているパスに適用できます。
2 Flow Abstractions
2フロー抽象化
Performance attributes include throughput, packet loss, delays, jitter, and congestion measures. RTFM will calculate these attributes in the form of extensions to the RTFM flow attributes according to three general classes:
パフォーマンスの属性には、スループット、パケット損失、遅延、ジッター、および輻輳測定が含まれます。RTFMは、これらの属性を、3つの一般クラスに従ってRTFMフロー属性の拡張機能の形で計算します。
- 'Trace', attributes of individual packets in a flow or a segment of a flow (e.g. last packet size, last packet arrival time).
- 「トレース」、フロー内の個々のパケットの属性またはフローのセグメント（例：最後のパケットサイズ、最後のパケット到着時間）。
- 'Aggregate', attributes derived from the flow taken as a whole (e.g. mean rate, max packet size, packet size distribution).
- 「集合体」、全体として取られたフローから導出された属性（たとえば、平均レート、最大パケットサイズ、パケットサイズ分布）。
- 'Group', attributes that depend on groups of packet values within the flow (e.g. inter-arrival times, short-term traffic rates).
- 「グループ」、フロー内のパケット値のグループに依存する属性（たとえば、到着間時間、短期交通率）。
Note that attributes within each of these classes may have various types of values - numbers, distributions, time series, and so on.
これらの各クラス内の属性には、数値、分布、時系列など、さまざまなタイプの値がある場合があることに注意してください。
A note on the relation between Meter Readers and Meters.
メーターリーダーとメーターの関係に関するメモ。
Several of the measurements enumerated below can be implemented by a Meter Reader that is tied to a meter with very short response time and very high bandwidth. If the Meter Reader and Meter can be arranged in such a way, RTFM could collect Packet Traces with time stamps and provide them directly to the Meter Reader for further processing.
以下に列挙されている測定値のいくつかは、非常に短い応答時間と非常に高い帯域幅でメーターに結び付けられたメーターリーダーによって実装できます。メーターリーダーとメーターをそのような方法で配置できる場合、RTFMはタイムスタンプでパケットトレースを収集し、さらに処理するためにメーターリーダーに直接提供できます。
A more useful alternative is to have the Meter calculate some flow statistics locally. This allows a looser coupling between the Meter and Meter Reader. RTFM will monitor an 'extended attribute' depending upon settings in its Rule table. RTFM will not create any "extended attribute" data without explicit instructions in the Rule table.
より便利な選択肢は、メーターにいくつかのフロー統計をローカルで計算させることです。これにより、メーターとメーターの読者の間の緩い結合が可能になります。RTFMは、ルールテーブルの設定に応じて、「拡張属性」を監視します。RTFMは、ルールテーブルに明示的な命令なしに「拡張属性」データを作成しません。
Section 2 described three different classes of attributes; this section considers the "data types" of these attributes.
セクション2では、3つの異なるクラスの属性を説明しました。このセクションでは、これらの属性の「データ型」を検討します。
Packet Traces (as described below) are a special case in that they are tables with each row containing a sequence of values, each of varying type. They are essentially 'compound objects' i.e. lists of attribute values for a string of packets.
パケットトレース（以下で説明するように）は、各行にそれぞれさまざまなタイプのシーケンスを含むテーブルであるという特別なケースです。それらは本質的に「複合オブジェクト」、つまり一連のパケットの属性値のリストです。
Aggregate attributes are like the 'old-style' attributes. Their types are:
集約属性は、「古いスタイル」の属性に似ています。それらのタイプは次のとおりです。
- Addresses, represented as byte strings (1 to 20 bytes long)
- バイト文字列として表されるアドレス（1〜20バイトの長さ）
- Counters, represented as 64-bit unsigned integers
- 64ビットの符号なし整数として表されるカウンター
- Times, represented as 32-bit unsigned integers
- 時間、32ビットの符号なし整数として表されます
Addresses are saved when the first packet of a flow is observed. They do not change with time, and they are used as a key to find the flow's entry in the meter's flow table.
アドレスは、フローの最初のパケットが観察されると保存されます。それらは時間とともに変化することはなく、メーターのフローテーブルにフローのエントリを見つけるためのキーとして使用されます。
Counters are incremented for each packet, and are never reset. An analysis application can compute differences between readings of the counters, so as to determine rates for these attributes. For example, if we read flow data at five-minute intervals, we can calculate five-minute packet and byte rates for the flow's two directions.
パケットごとにカウンターが増加し、リセットされることはありません。分析アプリケーションは、これらの属性のレートを決定するために、カウンターの測定値間の違いを計算できます。たとえば、5分間隔でフローデータを読み取ると、フローの2つの方向の5分間のパケットとバイトレートを計算できます。
Times are derived from the FirstTime for a flow, which is set when its first packet is observed. LastTime is updated as each packet in the flow is observed.
時間は、最初のパケットが観察されるときに設定されるフローの初めてから派生します。フロー内の各パケットが観察されると、最後に更新されました。
All the above types have the common feature that they are expressed as single values. At least some of the new attributes will require multiple values. If, for example, we are interested in inter-packet time intervals, we can compute an interval for every packet after the first. If we are interested in packet sizes, a new value is obtained as each packet arrives. When it comes to storing this data we have two options:
上記のすべてのタイプには、単一の値として表される共通の特徴があります。少なくともいくつかの新しい属性には、複数の値が必要になります。たとえば、パケット間の時間間隔に関心がある場合は、最初のパケット後にすべてのパケットの間隔を計算できます。パケットサイズに興味がある場合、各パケットが到着すると新しい値が得られます。このデータの保存に関しては、2つのオプションがあります。
- As a distribution, i.e. in an array of 'buckets'. This method is a compact representation of the data, with the values being stored as counters between a minimum and maximum, with defined steps in each bucket. This fits the RTFM goal of compact data storage.
- 分布として、つまり「バケツ」の配列で。この方法はデータのコンパクトな表現であり、値は最小値と最大の間のカウンターとして保存され、各バケットに定義されたステップがあります。これは、コンパクトデータストレージのRTFMの目標に適合します。
- As a sequence of single values. This saves all the information, but does not fit well with the RTFM goal of doing as much data reduction as possible within the meter.
- 単一値のシーケンスとして。これにより、すべての情報が保存されますが、メーター内でできるだけ多くのデータ削減を行うというRTFMの目標には適合しません。
Studies which would be limited by the use of distributions might well use packet traces instead.
分布の使用によって制限される研究は、代わりにパケットトレースを使用する可能性があります。
A method for specifying the distribution parameters, and for encoding the distribution so that it can be easily read, is described in section 3.2.
分布パラメーターを指定する方法、および分布を簡単に読み取ることができるようにエンコードする方法については、セクション3.2で説明します。
The simplest way of collecting a trace in the meter would be to have a new attribute called, say, "PacketTrace". This could be a table, with a column for each property of interest. For example, one could trace:
メーターでトレースを収集する最も簡単な方法は、「Packettrace」と呼ばれる新しい属性を持つことです。これはテーブルであり、関心のあるプロパティごとに列があります。たとえば、トレースできます。
- Packet Arrival time (TimeTicks from sysUpTime, or microseconds from FirstTime for the flow).
- パケットの到着時間（sysuptimeからのタイムティック、またはフローの初めてのマイクロ秒）。
- Packet Direction (Forward or Backward)
- パケット方向（前方または後方）
- Packet Sequence number (for protocols with sequence numbers)
- パケットシーケンス番号（シーケンス番号付きプロトコル用）
- Packet Flags (for TCP at least)
- パケットフラグ（少なくともTCP用）
Note: The following implementation proposal is for the user who is familiar with the writing of rule sets for the RTFM Meter.
注：次の実装提案は、RTFMメーターのルールセットの執筆に精通しているユーザー向けです。
To add a row to the table, we only need a rule which PushPkts the PacketTrace attribute. To use this, one would write a rule set which selected out a small number of flows of interest, with a 'PushPkt PacketTrace' rule for each of them. A MaxTraceRows default value of 2000 would be enough to allow a Meter Reader to read one-second ping traces every 10 minutes or so. More realistically, a MaxTraceRows of 500 would be enough for one-minute pings, read once each hour.
テーブルに行を追加するには、packettrace属性をpushpktsするルールのみが必要です。これを使用するには、それぞれに「pushpkt packettrace」ルールを使用して、関心のある少数のフローを選択したルールセットを作成します。2000のMaxtracerowsデフォルト値は、メーターリーダーが10分ごとに1秒のPingトレースを読むことができるのに十分です。より現実的には、500のMaxtracerowsでは1分間のPingで十分であり、1時間に1回読みます。
Packet traces are already implemented by the RMON MIB [RMON-MIB, RMON2-MIB], in the Packet Capture Group. They are therefore a low priority for RTFM.
パケットトレースは、パケットキャプチャグループにrmon mib [rmon-mib、rmon2-mib]によって既に実装されています。したがって、それらはRTFMの優先度が低いです。
RTFM's "old-style" flow attributes count the bytes and packets for packets which match the rule set for an individual flow. In addition to these totals, for example, RTFM could calculate Packet Size statistics. This data can be stored as distributions, though it may sometimes be sufficient to simply keep a maximum value.
RTFMの「古いスタイル」フロー属性は、個々のフローのルールセットに一致するパケットのバイトとパケットをカウントします。たとえば、これらの合計に加えて、RTFMはパケットサイズの統計を計算できます。このデータは分布として保存できますが、最大値を保持するのに十分な場合があります。
As an example, consider Packet Size. RTFM's packet flows can be examined to determine the maximum packet size found in a flow. This will give the Network Operator an indication of the MTU being used in a flow. It will also give an indication of the sensitivity to loss of a flow, for losing large packets causes more data to be retransmitted.
例として、パケットサイズを検討してください。RTFMのパケットフローを調べて、フローに見られる最大パケットサイズを決定できます。これにより、ネットワークオペレーターは、MTUがフローで使用されていることを示しています。また、大規模なパケットを失うと、より多くのデータが再送信されるため、流れの損失に対する感度の兆候が得られます。
Note that aggregate attributes are a simple extension of the 'old-style' attributes; their values are never reset. For example, an array of counters could hold a 'packet size' distribution. The counters continue to increase, a meter reader will collect their values at regular intervals, and an analysis application will compute and display distributions of the packet size for each collection interval.
集計属性は、「古いスタイル」属性の単純な拡張機能であることに注意してください。それらの値は決してリセットされません。たとえば、一連のカウンターは「パケットサイズ」分布を保持できます。カウンターは増加し続け、メーターリーダーは定期的に値を収集し、分析アプリケーションは各コレクション間隔のパケットサイズの分布を計算および表示します。
The notion of group attributes is to keep simple statistics for measures that involve more than one packet. This section describes some group attributes which it is feasible to implement in a traffic meter, and which seem interesting and useful.
グループ属性の概念は、複数のパケットを含む測定の簡単な統計を維持することです。このセクションでは、トラフィックメーターで実装することが実行可能であり、興味深く有用であると思われるいくつかのグループ属性について説明します。
Short-term bit rate - The data could also be recorded as the maximum and minimum data rate of the flow, found over specific time periods during the lifetime of a flow; this is a special kind of 'distribution'. Bit rate could be used to define the throughput of a flow, and if the RTFM flow is defined to be the sum of all traffic in a network, one can find the throughput of the network.
短期ビットレート - データは、フローの寿命の間に特定の期間に見られるフローの最大および最小データレートとして記録することもできます。これは特別な種類の「分布」です。ビットレートを使用してフローのスループットを定義できます。RTFMフローがネットワーク内のすべてのトラフィックの合計として定義されている場合、ネットワークのスループットを見つけることができます。
If we are interested in '10-second' forward data rates, the meter might compute this for each flow of interest as follows:
「10秒」のフォワードデータレートに興味がある場合、メーターは次のように、それぞれの関心のあるフローに対してこれを計算する可能性があります。
- maintain an array of counters to hold the flow's 10-second data rate distribution.
- フローの10秒のデータレート分布を保持するために、カウンターの配列を維持します。
- every 10 seconds, compute and save 10-second octet count, and save a copy of the flow's forward octet counter.
- 10秒ごとに、10秒のオクテットカウントを計算して保存し、フローの前方オクテットカウンターのコピーを保存します。
To achieve this, the meter will have to keep a list of aggregate flows and the intervals at which they require processing. Careful programming is needed to achieve this, but provided the meter is not asked to do it for very large numbers of flows, it has been successfully implemented.
これを達成するには、メーターは骨材のフローとそれらが処理が必要な間隔のリストを保持する必要があります。これを達成するには慎重なプログラミングが必要ですが、メーターが非常に多数のフローのためにそれを行うように求められていない場合、それは正常に実装されています。
Inter-arrival times. The Meter knows the time that it encounters each individual packet. Statistics can be kept to record the inter-arrival times of the packets, which would give an indication of the jitter found in the Flow.
到着間時間。メーターは、個々のパケットに遭遇する時間を知っています。統計を保持して、パケットの攻撃間時間を記録することができます。これにより、流れにあるジッターの兆候が得られます。
Turn-around statistics. Sine the Meter knows the time that it encounters each individual packet, it can produce statistics of the time intervals between packets in opposite directions are observed on the network. For protocols such as SNMP (where every packet elicits an answering packet) this gives a good indication of turn-around times.
ターンアラウンド統計。Sine The Meterは、個々のパケットに遭遇する時間を知っています。反対方向のパケット間で時間間隔の統計がネットワークで観察されることがわかります。SNMP（すべてのパケットが応答パケットを誘発する場合）などのプロトコルの場合、これはターンアラウンド時間を適切に示しています。
Subflow analysis. Since the choice of flow endpoints is controlled by the meter's rule set, it is easy to define an aggregate flow, e.g. "all the TCP streams between hosts A and B." Preliminary implementation work suggests that - at least for this case - it should be possible for the meter to maintain a table of information about all the active streams. This could be used to produce at least the following attributes:
サブフロー分析。フローエンドポイントの選択はメーターのルールセットによって制御されるため、集約フローを簡単に定義することができます。「ホストAとBの間のすべてのTCPストリーム」予備的な実装作業は、少なくともこの場合は、メーターがすべてのアクティブストリームに関する情報の表を維持できることを示唆しています。これは、少なくとも次の属性を生成するために使用できます。
- Number of streams, e.g. streams active for n-second intervals. Determined for TCP and UDP using source-dest port number pairs.
- ストリームの数、例えばn秒間隔でアクティブなストリーム。Source-Destポート番号ペアを使用してTCPおよびUDPを決定します。
- Number of TCP bytes, determined by taking difference of TCP sequence numbers for each direction of the aggreagate flow.
- Aggreagateフローの各方向のTCPシーケンス数の差を取ることによって決定されるTCPバイトの数。
IIS attributes. Work at CEFRIEL [IIS-ACCT] has produced a traffic meter with a rule set modified 'on the fly' so as to maintain a list of RSVP-reserved flows. For such flows the following attributes have been implemented (these quantities are defined in [GUAR-QOS]):
IIS属性。CEFRIEL [IIS-ACCT]での作業は、RSVPが返信されたフローのリストを維持するために、「オンザフライ」で変更されたルールセットを備えたトラフィックメーターを作成しました。このようなフローの場合、次の属性が実装されています（これらの数量は[Guar-Qos]で定義されています）：
- QoSService: Service class for the flow (guaranteed, controlled load) - QoSStyle: Reservation setup style (wildcard filter, fixed filter, shared explicit) - QoSRate: [byte/s] rate for flows with guaranteed service - QoSSlackTerm: [microseconds] Slack Term QoS parameter for flows with guaranteed service - QoSTokenBucketRate: [byte/s] Token Bucket Rate QoS parameter for flows with guaranteed or controlled load service
- Qosservice：フローのサービスクラス（保証、制御荷重） - Qosstyle：予約セットアップスタイル（ワイルドカードフィルター、固定フィルター、共有明示） - Qosrate：[保証されたサービス付きフローの[byte/s] qosslackterm：[microseconds] slack保証されたサービスを備えたフローの用語QoSパラメーター-Qostokenbucketrate：[byte/s]トークンバケットレートqos qosパラメーター保証または制御された負荷サービスを備えたフローのパラメーター
The following are also being considered:
以下も考慮されています。
- QoSTokenBucketSize: [byte] Size of Token Bucket
- Qostokenbucketsize：[byte]トークンバケットのサイズ
- QoSPeakDataRate: [byte/s] Maximum rate for incoming data
- QOSPEAKDATARATE：[BYTE/S]着信データの最大レート
- QoSMinPolicedUnit: [byte] IP datagrams less than this are counted as being this size - QoSMaxDatagramSize: [byte] Size of biggest datagram which conforms to the traffic specification 2.6 Actions on Exceptions
-qosminpolicedunit：[byte] ip datagramsよりも少ないです。
Some users of RTFM have requested the ability to mark flows as having High Watermarks. The existence of abnormal service conditions, such as non-ending flow, a flow that exceeds a given limit in traffic (e.g. a flow that is exhausting the capacity of the line that carries it) would cause an ALERT to be sent to the Meter Reader for forwarding to the Manager. Operations Support could define service situations in many different environments. This is an area for further discussion on Alert and Trap handling.
RTFMの一部のユーザーは、高い透かしを持っているとフローをマークする機能を要求しています。非送信フロー、トラフィックの特定の制限を超えるフロー（例えば、それを運ぶラインの容量を使い果たしているフロー）などの異常なサービス条件の存在は、メーターリーダーにアラートを送信します。マネージャーへの転送用。オペレーションサポートは、さまざまな環境でのサービス状況を定義できます。これは、アラートとトラップの処理に関するさらなる議論の領域です。
3 Extensions to the 'Basic' RTFM Meter
「基本」RTFMメーターへの3拡張
The Working Group has agreed that the basic RTFM Meter will not be altered by the addition of the new attributes of this document. This section describes the extensions needed to implement the new attributes.
ワーキンググループは、このドキュメントの新しい属性を追加することにより、基本的なRTFMメーターが変更されないことに同意しました。このセクションでは、新しい属性を実装するために必要な拡張機能について説明します。
The architecture of RTFM has defined the structure of flows, and this memo does not change that structure. The flow table could have ancillary tables called "Distribution Tables" and "Trace Tables," these would contain rows of values and or actions as defined above. Each entry in these tables would be marked with the number of its corresponding flow in the RTFM flow table.
RTFMのアーキテクチャはフローの構造を定義しており、このメモはその構造を変更しません。フローテーブルには、「分布テーブル」と「トレーステーブル」と呼ばれる補助テーブルがあります。これらには、上記のように値の行やアクションが含まれます。これらのテーブルの各エントリには、RTFMフローテーブルの対応するフローの数がマークされます。
Note: The following section is for the user who is familiar with the writing of rule sets for the RTFM Meter.
注：次のセクションは、RTFMメーターのルールセットの執筆に精通しているユーザー向けです。
In order to identify the data in a Packet Flow Table, the attribute name could be pushed into a string at the head of each row. For example, if a table entry has "To Bit Rate" for a particular flow, the "ToBitRate" string would be found at the head of the row. (An alternative method would be to code an identification value for each extended attribute and push that value into the head of the row.) See section 4. for an inital set of ten extended flow attributes.
パケットフローテーブル内のデータを識別するために、属性名を各行の頭の文字列に押し込むことができます。たとえば、特定のフローのテーブルエントリに「ビットレート」がある場合、「トトラート」文字列は行の頭にあります。（別の方法は、各拡張属性の識別値をコーディングし、その値を行のヘッドに押し込むことです。）セクション4を参照してください。
At first sight it would seem neccessary to add extra features to the RTFM Meter architecture to support distributions. This, however, is not neccessarily the case.
一見、分布をサポートするためにRTFMメーターアーキテクチャに追加機能を追加する必要があるように思われます。ただし、これは必ずしもそうではありません。
What is actually needed is a way to specify, in a ruleset, the distribution parameters. These include the number of counters, the lower and upper bounds of the distribution, whether it is linear or logarithmic, and any other details (e.g. the time interval for short-term rate attributes).
実際に必要なのは、ルールセットで分布パラメーターを指定する方法です。これらには、カウンターの数、分布の下限と上限、線形であろうと対数であろうと、その他の詳細（たとえば、短期レート属性の時間間隔）が含まれます。
Any attribute which is distribution-valued needs to be allocated a RuleAttributeNumber value. These will be chosen so as to extend the list already in the RTFM Meter MIB document [RTFM-MIB].
分布値である属性には、RuleAttributeNumber値を割り当てる必要があります。これらは、すでにRTFMメーターMIBドキュメント[RTFM-MIB]にリストを拡張するために選択されます。
Since distribution attributes are multi-valued it does not make sense to test them. This means that a PushPkt (or PushPkttoAct) action must be executed to add a new value to the distribution. The old-style attributes use the 'mask' field to specify which bits of the value are required, but again, this is not the case for distributions. Lastly, the MatchedValue ('value') field of a PushPkt rule is never used. Overall, therefore, the 'mask' and 'value' fields in the PushPkt rule are available to specify distribution parameters.
分布属性は多値であるため、テストすることは意味がありません。これは、分布に新しい値を追加するためにPushPkt（またはpushPkttoACT）アクションを実行する必要があることを意味します。古いスタイルの属性は、「マスク」フィールドを使用して、値のどのビットが必要かを指定しますが、繰り返しますが、これは分布の場合ではありません。最後に、PushPKTルールのMatchedValue（「値」）フィールドは使用されません。したがって、全体として、PushPKTルールの「マスク」および「値」フィールドを使用でき、分布パラメーターを指定します。
Both these fields are at least six bytes long, the size of a MAC address. All we have to do is specify how these bytes should be used! As a starting point, the following is proposed (bytes are numbered left-to-right.
これらのフィールドは両方とも、少なくとも6バイトの長さで、MACアドレスのサイズです。私たちがしなければならないのは、これらのバイトをどのように使用するかを指定することだけです！出発点として、以下が提案されています（バイトには左から右に番号が付けられています。
Mask bytes: 1 Transform 1 = linear, 2 = logarithmic 2 Scale Factor Power of 10 multiplier for Limits and Counts 3-4 Lower Limit Highest value for first bucket 5-6 Upper Limit Highest value for last bucket
マスクバイト：1変換1 =線形、2 =対数2スケール係数は、制限とカウントのための10のマルチプライヤーのパワー3-4上限第1バケットの最高値5-6最終バケツの最高値最高値
Value bytes: 1 Buckets Number of buckets. Does not include the 'overflow' bucket 2 Parameter-1 } Parameter use depends 3-4 Parameter-2 } on distribution-valued 5-6 Parameter-3 } attribute
値バイト：1バケット数のバケット。「オーバーフロー」バケット2パラメーター-1}パラメーターの使用は含まれません}分布値5-6パラメーター-3}属性に3-4パラメーター-2}依存します
For example, experiments with NeTraMet have used the following rules:
たとえば、Netrametを使用した実験では、次のルールが使用されています。
FromPacketSize & 1.0.25!1500 = 60.0!0: PushPkttoAct, Next;
ToInterArrivalTime & 2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next;
FromBitRate & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next;
In these mask and value fields a dot indicates that the preceding number is a one-byte integer, the exclamation marks indicate that the preceding number is a two-byte integer, and the last number is two bytes wide since this was the width of the preceding field. (Note that this convention follows that for IP addresses - 130.216 means 130.216.0.0).
これらのマスクおよび値フィールドでは、ドットは前の数値が1バイトの整数であることを示し、感嘆符は前の数字が2バイトの整数であり、最後の数値は幅2バイトであることを示しています。先行フィールド。（この規則は、IPアドレスの場合、130.216は130.216.0.0を意味することに注意してください）。
The first rule specifies that a distribution of packet sizes is to be built. It uses an array of 60 buckets, storing values from 1 to 1500 bytes (i.e. linear steps of 25 bytes each bucket). Any packets with size greater than 1500 will be counted in the 'overflow' bucket, hence there are 61 counters for the distribution.
最初のルールは、パケットサイズの分布を構築することを指定します。60バケツの配列を使用して、値を1〜1500バイト（つまり、各バケットの25バイトの線形ステップ）を保存します。1500を超えるサイズのパケットは「オーバーフロー」バケットでカウントされるため、分布には61のカウンターがあります。
The second rule specifies an interarrival-time distribution, using a logarithmic scale for an array of 60 counters (and an overflow bucket) for rates from 1 ms to 1.8 s. Arrival times are measured in microseconds, hence the scale factor of 3 indicates that the limits are given in milliseconds.
2番目のルールは、1ミリ秒から1.8秒のレートの60カウンター（およびオーバーフローバケット）の配列に対数スケールを使用して、到着時間間分布を指定します。到着時間はマイクロ秒で測定されるため、3のスケール係数は、制限がミリ秒単位で与えられていることを示します。
The third rule specifies a bit-rate distribution, with the rate being calculated every 5 seconds (parameter 1). A logarithmic array of 60 counters (and an overflow bucket) are used for rates from 1 kbps to 10 Mbps. The scale factor of 3 indicates that the limits are given in thousands of bits per second (rates are measured in bps).
3番目のルールは、5秒ごとにレートが計算されるビットレート分布を指定します（パラメーター1）。60カウンター（およびオーバーフローバケット）の対数配列は、1 kbpsから10 Mbpsのレートに使用されます。3のスケール係数は、制限が毎秒数千ビットで与えられていることを示します（レートはBPSで測定されます）。
These distribution parameters will need to be stored in the meter so that they are available for building the distribution. They will also need to be read from the meter and saved together with the other flow data.
これらの分布パラメーターは、分布の構築に使用できるように、メーターに保存する必要があります。また、メーターから読み取り、他のフローデータと一緒に保存する必要があります。
Since RTFM flows are bi-directional, each distribution-valued quantity (e.g. packet size, bit rate, etc.) will actually need two sets of counters, one for packets travelling in each direction. It is tempting to regard these as components of a single 'distribution', but in many cases only one of the two directions will be of interest; it seems better to keep them in separate distributions. This is similar to the old-style counter-valued attributes such as toOctets and fromOctets.
RTFMフローは双方向であるため、各分布値量（パケットサイズ、ビットレートなど）には、実際には、各方向に移動するパケット用の2つのカウンターが2セットのカウンターが必要です。これらを単一の「分布」のコンポーネントと見なすのは魅力的ですが、多くの場合、2つの方向の1つだけが興味深いものになります。それらを別々の分布に保つ方が良いようです。これは、Tooctetsやfromuctetsなどの古いスタイルの対抗属性に似ています。
A distribution should be read by a meter reader as a single, structured object. The components of a distribution object are:
分布は、メーターリーダーが単一の構造化されたオブジェクトとして読み取る必要があります。分布オブジェクトのコンポーネントは次のとおりです。
- 'mask' and 'value' fields from the rule which created the distribution
- 配布を作成したルールからの「マスク」と「値」フィールド
- sequence of counters ('buckets' + overflow)
- カウンターのシーケンス（「バケット」オーバーフロー）
These can be easily collected into a BER-encoded octet string, and would be read and referred to as a 'distribution'.
これらは、ベルエンコードのオクテット弦に簡単に収集でき、読み取り、「分布」と呼ばれます。
4 Extensions to the Rules Table, Attribute Numbers
4ルールテーブルへの拡張、属性番号
The Rules Table of "old-style" attributes will be extended for the new flow types. A list of actions, and keywords, such as "ToBitRate", "ToPacketSize", etc. will be developed and used to inform an RTFM meter to collect a set of extended values for a particular flow (or set of flows).
新しいフロータイプの「古いスタイル」属性のルールテーブルが拡張されます。アクションのリスト、および「Tobitrate」、「Topacketsize」などのキーワードが開発され、RTFMメーターに通知して、特定のフロー（またはフローのセット）の拡張値のセットを収集します。
Note: An implementation suggestion.
注：実装の提案。
Value 65 is used for 'Distributions', which has one bit set for each distribution-valued attribute present for the flow, using bit 0 for attribute 66, bit 1 for attribute 67, etc.
値65は「分布」に使用されます。「分布」には、フローに存在する分布値ごとに1つのビットセットがあり、属性66にビット0、属性67などにビット1を使用します。
Here are ten possible distribution-valued attributes numbered according to RTFM WG consensus at the 1997 meeting in Munich:
ミュンヘンで開催された1997年の会議でのRTFM WGコンセンサスに従って番号が記載されている10の分布値属性を次に示します。
ToPacketSize(66) size of PDUs in bytes (i.e. number FromPacketSize(67) of bytes actually transmitted) ToInterarrivalTime(68) microseconds between successive packets FromInterarrivalTime(69) travelling in the same direction
PDUのPDUのサイズ（つまり、実際に送信されたバイト（67）の数（67）の数字（68）のマイクロ秒の間のマイクロ秒（68）のインターリバルタイム（69）から同じ方向に移動します。
ToTurnaroundTime(70) microseconds between successive packets FromTurnaroundTime(71) travelling in opposite directions
toturnaroundtime（70）runturnaroundtime（71）からの連続したパケット間のマイクロ秒
ToBitRate(72) short-term flow rate in bits per second FromBitRate(73) Parameter 1 = rate interval in seconds
トートラート（72）1秒あたりのビットの短期流量（73）パラメーター1 =秒単位の速度間隔
ToPDURate(74) short-term flow rate in PDUs per second FromPDURate(75) Parameter 1 = rate interval in seconds
TopDurate（74）PDUの短期流量秒（75）パラメーター1 =秒単位のレート間隔
(76 .. 97) other distributions
（76 .. 97）その他の分布
It seems reasonable to allocate a further group of numbers for the IIS attributes described above:
上記のIIS属性にさらに数字のグループを割り当てることは合理的と思われます。
QoSService(98) QoSStyle(99) QoSRate(100) QoSSlackTerm(101) QoSTokenBucketRate(102) QoSTokenBucketSize(103) QoSPeakDataRate(104) QoSMinPolicedUnit(105) QoSMaxPolicedUnit(106)
Qosservice（98）Qosstyle（99）Qosrate（100）Qosslackterm（101）Qostokenbucketrate（102）Qostokenbucketsize（103）Qosminpolicedunit（104）Qosminpolicedunit（105）Qosmaxpolicedunit（106）
The following attributes have also been implemented in NetFlowMet, a version of the RTFM traffic meter:
次の属性は、RTFMトラフィックメーターのバージョンであるNetflowmetにも実装されています。
MeterID(112) Integer identifying the router producing NetFlow data (needed when NetFlowMet takes data from several routers) SourceASN(113) Autonomous System Number for flow's source SourcePrefix(114) CIDR width used by router for determining flow's source network DestASN(115) Autonomous System Number for flow's destination DestPrefix(116) CIDR width used by router for determining flow's destination network
MeterID（112）整数Netflowデータを生成するルーターを識別する（Netflowmetがいくつかのルーターからデータを取得するときに必要）Sourceasn（113）FlowのソースSourcePrefix（114）FlowのソースネットワークDestasn（115）自律自律自律型のCIDR幅（114）のCIDR幅フローの宛先DestPrefix（116）のシステム番号RouterがFlowの宛先ネットワークを決定するために使用されるCIDR幅
Some of the above, e.g. SourceASN and DestASN, might sensibly be allocated attribute numbers below 64, making them part of the 'base' RTFM meter attributes.
上記のいくつか、例えばSourceasnとdestasnは、64未満の属性番号を賢明に割り当てる可能性があり、それらを「ベース」RTFMメーター属性の一部にします。
To support use of the RTFM meter as an 'Edge Device' for implementing Differentiated Services, and/or for metering traffic carried via such services, one more attribute will be useful:
差別化されたサービスを実装するための「エッジデバイス」としてのRTFMメーターの使用をサポートするため、および/またはそのようなサービスを介して運ばれる計量トラフィックのために、もう1つの属性が役立ちます。
DSCodePoint(118) DS Code Point (6 bits) for packets in this flow
このフローのパケット用のDSCODEPOINT（118）DSコードポイント（6ビット）
Since the DS Code Point is a single field within a packet's IP header, it is not possible to have both Source- and Dest-CodePoint attributes. Possible uses of DSCodePoint include aggregating flows using the same Code Points, and separating flows having the same end-point addresses but using different Code Points.
DSコードポイントはパケットのIPヘッダー内の単一のフィールドであるため、ソースとデスティコデポイットの両方の属性を持つことはできません。DSCODEPOINTの使用の可能性には、同じコードポイントを使用してフローを集約すること、および同じエンドポイントアドレスを持つが異なるコードポイントを使用してフローを分離することが含まれます。
5 Security Considerations
5つのセキュリティ上の考慮事項
The attributes considered in this document represent properties of traffic flows; they do not present any security issues in themselves. The attributes may, however, be used in measuring the behaviour of traffic flows, and the collected traffic flow data could be of considerable value. Suitable precautions should be taken to keep such data safe.
このドキュメントで考慮される属性は、トラフィックフローの特性を表しています。彼らはそれ自体にセキュリティの問題を提示しません。ただし、属性はトラフィックフローの動作の測定に使用される場合があり、収集されたトラフィックフローデータはかなりの価値がある可能性があります。そのようなデータを安全に保つために適切な注意を払う必要があります。
6 References
6リファレンス
[C-B-P] Claffy, K., Braun, H-W, Polyzos, G., "A Parameterizable Methodology for Internet Traffic Flow Profiling," IEEE Journal on Selected Areas in Communications, Vol. 13, No. 8, October 1995.
[C-B-P] Claffy、K.、Braun、H-W、Polyzos、G。、「インターネットトラフィックフロープロファイリングのパラメーター化可能な方法論」、IEEE Journal on Communications、vol。13、No。8、1995年10月。
[GUAR-QOS] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[Guar-Qos] Shenker、S.、Partridge、C。and R. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[IIS-ACCT] Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting: Users' Guide", CEFRIEL, Milan, 5 May 1998. (See also http://www.cefriel.it/ntw)
[IIS-ACCT] Maiocchi、S：「IISアカウンティングのためのNetramet＆Nemac：ユーザーガイド」、1998年5月5日、ミラノ、Cefriel。
[IIS-RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[IIS-RSVP] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M., "Framework for IP Performance Metrics", RFC 2330, May 1998.
[IPPM-FRM] Paxson、V.、Almes、G.、Mahdavi、J。、およびMathis、M。、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[RMON-MIB] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, February 1995.
[Rmon-Mib] Waldbusser、S。、「リモートネットワーク監視管理情報ベース」、RFC 1757、1995年2月。
[RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[RMON2-MIB] Waldbusser、S。、「リモートネットワーク監視管理情報ベース2を使用したバージョン2」、RFC 2021、1997年1月。
[RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
[RTFM-ARC] Brownlee、N.、Mills、C。and G. Ruth、「トラフィックフロー測定：アーキテクチャ」、RFC 2722、1999年10月。
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RTFM-MIB]ブラウンリー、N。、「トラフィックフロー測定：Meter MIB」、RFC 2720、1999年10月。
7 Authors' Addresses
7著者の住所
Sig Handelman IBM Research Division T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598
Sig Handelman IBM Research Division T.J.ワトソン研究センターP.O.ボックス704ヨークタウンハイツ、ニューヨーク10598
Phone: +1 914 784 7626
EMail: swhandel@us.ibm.com
Stephen Stibler IBM Research Division T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598
Stephen Stibler IBM Research Division T.J.ワトソン研究センターP.O.ボックス704ヨークタウンハイツ、ニューヨーク10598
Phone: +1 914 784 7191
EMail: stibler@us.ibm.com
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
Greg Ruth GTE Internteworking 3 Van de Graaff Drive P.O. Box 3073 Burlington, MA 01803, U.S.A.
Greg Ruth Gte Internteworking 3 Van de Graaff Drive P.O.Box 3073バーリントン、マサチューセッツ州01803、米国
Phone: +1 781 262 4831
EMail: gruth@bbn.com
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エディター機能の資金は現在、インターネット協会によって提供されています。