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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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メーターの実装は、オークランド、NZの大学でNevilブラウンリー、スティーブン・StiblerとホーソーンにあるIBMのシグHandelman、NY、USAによって行われています。 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つのエンドポイント間のパケットの集合としての流れを見て、双方向（すなわち計は有効二つのサブ流れ、内の1つを監視します各方向）。
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メーターは方向を示すために計算された属性（例えばFlowKind）のいずれかを使用してこれを処理することができます。
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.
電子。各フローはメーターが最後のフローのためのパケットを見た時間を示す「LastTime」属性を持っています。
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.
グラム。すべての属性は、さまざまなプロトコルのために（多かれ少なかれ）と同じ意味を持っています。 IPX、AppleTalkの、のDECnetとCLNSだけでなく、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、ブラウンと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].
容量とパフォーマンス情報の使用例は、[IIS-RSVP]「IETF統合サービスとRSVPの使用」で発見されました。統合サービスのRSVPの使用は、トークンバケットレート、トークンバケットサイズ、ピークデータレート、最小ポリシングユニット、最大パケットサイズ、およびスラック用語を中心に展開します。これらはTSpecの、ADSPECおよびフロースペック（統合サービスキーワード）によって設定され、統合サービスの構成および動作で使用されています。 RTFMは、明示的にピークデータレート、最小ポリシングユニット、最大パケットサイズ、およびスラック用語を監視することができます。 RTFMは、トークンバケットの内容を推測することができます。 WGは、これらのサービスメトリクスと連携するための措置を開発します。 IISの監視の初期の実装は、イタリアのCEFRIEL [IIS-ACCT]でdevelopdされています。
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.
- 詳細なIPPM作業は、これらの最も使用されるパスに適用できるようにRTFMは、ネットワークメッシュで最もよく使用されるパスを識別するために使用することができます。
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分間隔でフローデータを読み込む場合たとえば、私たちは流れの二つの方向のための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).
- パケット到着時間（流れのためFIRSTTIMEからのsysUpTimeからのTimeTicks、またはマイクロ秒）。
- 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のデフォルト値はメーターReaderが1秒のpingが10分ごとかそこらをトレース読めるようにするには十分だろう。もっと現実的に、500のMaxTraceRowsは1時間に1回を読んで、1分のpingのために十分だろう。
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フローは、ネットワーク内のすべてのトラフィックの合計になるように定義されている場合、1は、ネットワークのスループットを見つけることができます。
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.
ターンアラウンドの統計。サインメーターが、それは個々のパケットを検出した時間を知っている、それがネットワーク上で観測されている反対方向にパケット間の時間間隔の統計情報を生成することができます。そのような（すべてのパケットが応答パケットを引き出す）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:
サブフロー分析。フローのエンドポイントの選択は、メーターのルールセットによって制御されるので、例えば、集約フローを定義することは容易です「全てのTCPは、ホストAとBとの間でストリーム」少なくともこのような場合のために - - メーターがすべてのアクティブなストリームに関する情報のテーブルを維持することが可能であるべき予備的な実装作業があることを示唆しています。これは、少なくとも以下の属性を製造するために使用することができます。
- Number of streams, e.g. streams active for n-second intervals. Determined for TCP and UDP using source-dest port number pairs.
- ストリームの数、例えばN秒間隔でアクティブなストリーム。ソース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属性。 RSVP予約フローのリストを維持するようにCEFRIEL [IIS-ACCT]での作業は、「オンザフライ」変更されたルールセットでトラフィック計を生産しています。このようなために（これらの量は、[グアー-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：保証型サービスとフローの[バイト/秒]レート - QoSSlackTerm：[マイクロ秒]保証サービスとフローのスラック用語QoSパラメータ - QoSTokenBucketRate：保証または制御負荷サービスとフローの[バイト/秒]トークンバケットレートのQoSパラメータ
The following are also being considered:
以下も考慮されています：
- QoSTokenBucketSize: [byte] Size of Token Bucket
- QoSTokenBucketSize：トークンバケットの[バイト]のサイズ
- QoSPeakDataRate: [byte/s] Maximum rate for incoming data
- QoSPeakDataRate：着信データのための[バイト/秒]最大レート
- 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：[バイト] IPデータグラム以下、これよりもこのサイズであるとしてカウントされます - QoSMaxDatagramSize：例外のトラフィック仕様2.6アクションに準拠し、最大データグラムの[バイト]のサイズ
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の一部のユーザーは、ハイウォーターマークを持つものとしてフローをマークする機能を要求しました。このような非終了フロー、トラフィックの指定された限界（それを運ぶラインの容量を排出され、例えば流量）を超える流量などの異常サービス条件の存在は、ALERTがメーターリーダーに送信させるだろうマネージャに転送します。オペレーション・サポートは、多くの異なる環境でのサービスの状況を定義することができます。これは、アラートおよびトラップの取り扱いに関するさらなる議論のための領域です。
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.
パケットフローテーブル内のデータを識別するために、属性名は、各行の先頭の文字列内に押し込むことができます。テーブルエントリは、特定のフローのための「ビットレート」を有する場合、例えば、「ToBitRate」列は、行の先頭に見出されるであろう。 （別の方法は、それぞれの拡張属性の識別値を符号化し、行の先頭に、その値をプッシュすることであろう。）10の拡張フロー属性のinitalセットに関してセクション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.
これらのフィールドの両方が、長いMACアドレスのサイズは、少なくとも6バイトです。私たちがしなければならないのは、これらのバイトが使用されるべき方法を指定しています！出発点として、以下が提案されている（バイトは、左から右へ番号が付けられています。
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 =線形、10乗算器の2 =対数2スケールファクタ電力を変換し、最後のバケットの最初のバケット5-6上限最大値3-4下限最高値をカウント
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;
FromPacketSize＆1.0.25 1500 = 60.0 0：！！PushPkttoAct、次。
ToInterArrivalTime & 2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next;
ToInterArrivalTime＆2.3.1 1800 = 60.0.0 0：PushPkttoAct、次;！
FromBitRate & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next;
FromBitRate＆2.3.1 10000 = 60.5.0 0：！！PushPkttoAct、次。
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).
これらのマスク値のドットが先行する数は一バイトの整数であることを示すフィールド、感嘆符は、先行する数が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.
最初のルールは、パケットサイズの分布を構築することを指定します。これは、1から1500バイト（25バイト各バケットの即ちリニアステップ）に値を格納し、60個のバケットのアレイを使用します。 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.
二番目のルールは、1.8秒〜1秒から速度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のカウンタ（オーバーフローバケット）の対数アレイは10 Mbpsに1 kbpsのレートからのために使用されます。 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フローは双方向であるので、各分布値の量（例えば、パケットサイズ、ビットレート、等）は、実際のカウンタの二組、それぞれの方向に移動するパケットのための1つが必要になります。単一の「ディストリビューション」の構成要素としてこれらを考えるために魅力的ですが、多くの場合、唯一の二つの方向のは、興味を持ってもらえるでしょう。別のディストリビューションでそれらを保つために良さそうです。これは、toOctetsやfromOctetsとして古いスタイルのカウンタ値属性に似ています。
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'.
これらは容易BERエンコードオクテットストリングに収集することができ、そして読み、「配布」と呼ばれるであろう。
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は、属性66のビット0を使用して、フローのための現在の属性、等、属性67のための1ビットの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)
バイト単位のPDUのToPacketSize（66）のサイズ（バイト数即ちFromPacketSize（67）は、実際に送信）
ToInterarrivalTime(68) microseconds between successive packets FromInterarrivalTime(69) travelling in the same direction
連続するパケットのFromInterarrivalTime間ToInterarrivalTime（68）マイクロ（69）と同じ方向に進みます
ToTurnaroundTime(70) microseconds between successive packets FromTurnaroundTime(71) travelling in opposite directions
連続するパケットのFromTurnaroundTime間ToTurnaroundTime（70）マイクロ（71）と反対方向に走行
ToBitRate(72) short-term flow rate in bits per second FromBitRate(73) Parameter 1 = rate interval in seconds
ToBitRate秒FromBitRateあたりのビット数（72）短期流量秒（73）パラメータ1 =レート間隔
ToPDURate(74) short-term flow rate in PDUs per second FromPDURate(75) Parameter 1 = rate interval in seconds
第FromPDURateあたりのPDUにToPDURate（74）短期流量秒（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）QoSPeakDataRate（104）QoSMinPolicedUnit（105）QoSMaxPolicedUnit（106）
The following attributes have also been implemented in NetFlowMet, a version of the RTFM traffic meter:
以下の属性もNetFlowMet、RTFMトラフィックメータのバージョンで実装されています：
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
フローのソースネットワークDestASN（115）自律的に決定するためにルータにより使用されるフローのソースSourcePrefix（114）CIDR幅のために（NetFlowMetは、いくつかのルータからデータを取得する際に必要）NetFlowデータを生成SourceASN（113）自律システム番号をルータを識別MeterID（112）整数フローの宛先ネットワークを決定するためにルータにより使用されるフローの宛先DestPrefixためのシステム番号（116）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は、賢明にそれらを「ベース」RTFMメーターの属性の一部を作り、64を下回る属性番号が割り当てられている可能性があります。
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ヘッダ内の単一のフィールドであるので、ソース - とDestは、コードポイントの両方の属性を持ってすることはできません。 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.、ブラウン、H-W、Polyzos、G.、 "インターネットトラフィックフロープロファイリングのためのパラメータ化手法、" VOL通信において、選択分野に関するIEEEジャーナル。 13、第8号、1995年10月。
[GUAR-QOS] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[グアー-QOS] Shenker、S.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、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：ユーザーのガイド"、CEFRIEL、ミラノ、5月5日、1998年（もhttp://www.cefriel.it/ntw参照）
[IIS-RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[IIS-RSVP] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M., "Framework for IP Performance Metrics", RFC 2330, May 1998.
[IPPM-FRM]パクソン、V.、Almes、G.、Mahdavi、J.及びマティス、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のSMIv2を使用して"、RFC 2021、1997年1月。
[RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
[RTFM - ARC]ブラウンリー、N.、ミルズ、C.およびG.ルース、 "トラフィックフロー測定：アーキテクチャ"、RFC 2722、1999年10月。
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RTFM-MIB]ブラウンリー、N.、 "トラフィックフロー測定：メーター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
シグHandelman IBM研究部門T.J。ワトソン研究所の私書箱ボックス704ヨークタウンハイツ、NY 10598
Phone: +1 914 784 7626 EMail: swhandel@us.ibm.com
電話：+1 914 784 7626 Eメール：swhandel@us.ibm.com
Stephen Stibler IBM Research Division T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598
スティーブンStibler IBM研究部門T.J。ワトソン研究所の私書箱ボックス704ヨークタウンハイツ、NY 10598
Phone: +1 914 784 7191 EMail: stibler@us.ibm.com
電話：+1 914 784 7191 Eメール：stibler@us.ibm.com
Nevil Brownlee Information Technology Systems & Services The University of Auckland Private Bag 92-019 Auckland, New Zealand
Nevilブラウンリー情報技術システムアンドサービスオークランド専用バッグ92から019オークランド、ニュージーランドの大学
Phone: +64 9 373 7599 x8941 EMail: n.brownlee@auckland.ac.nz
電話：+64 9 373 7599 x8941メール：n.brownlee@auckland.ac.nz
Greg Ruth GTE Internteworking 3 Van de Graaff Drive P.O. Box 3073 Burlington, MA 01803, U.S.A.
グレッグ・ルースGTE Internteworking 3バンデグラフドライブ私書箱ボックス3073バーリントン、MA 01803、U.S.A.
Phone: +1 781 262 4831 EMail: gruth@bbn.com
電話：+1 781 262 4831 Eメール：gruth@bbn.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。