RFC2724 日本語訳
2724 RTFM: New Attributes for Traffic Flow Measurement. S. Handelman,S. Stibler, N. Brownlee, G. Ruth. October 1999. (Format: TXT=37951 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループS.ハンデルマンの要求をネットワークでつないでください: 2724秒間Stiblerカテゴリ: 実験的なIBMのN.ブラウンリーオークランド大学G.ルースGTEインターネットワーキング1999年10月
RTFM: New Attributes for Traffic Flow Measurement
RTFM: 交通流量測定のための新しい属性
Status of this Memo
この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.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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 Traffic Measurement Architectureはネットワーク交通の流れを説明して、測定するのに一般的な枠組みを提供します。 流れは、それらのAddress Attribute値で定義されて、'交通Meter'によって測定されます。 このドキュメントはそれらが持つことができる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などのAddress Attributes、および短期的なビット伝送速度やターンアラウンドタイムなどのGroup Attributesを含んでいます。 また、Integrated ServicesのためのServiceパラメタの品質について議論します。
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
.21.1RTFMのFlowsの1序論Definition、Flowsと彼らのAttributesに関する.31.2RTFMのCurrent Definition、.31.3RTFM Flows、Integrated Services、IPPM、およびResearchコネFlows4 2Flow Abstractions…; .52.1メーター読者とメーター. . . . . . . . . . . . . . . . . 5 2.2の属性タイプ. . . . . . . . . . . . . . . . . . . . . . 6 2.3パケット跡. . . . . . . . . . . . . . . . . . . . . . . 7 2.4は属性. . . . . . . . . . . . . . . . . . . 8に集められます。
Handelman, et al. Experimental [Page 1] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[1ページ]RFC2724RTFM: 新しい属性1999年10月
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
2.5がAttributesを分類する、'基本的な'RTFM Meter. . . . . . . . . . . . .10 3.1Flowへの.3Extensionsがテーブルの上に置くExceptionsの上の.82.6Actions、拡大、RuleSets. . . . . . . . . . .11 3.3Reading Distributionsの…….3.2Specifying Distributions; 規則テーブルへの.4の拡大、属性No.. . . . . . .13 5セキュリティ問題. . . . . . . . . . . . . . . . . . . .15 6参照. . . . . . . . . . . . . . . . . . . . . . . . . .16 7作者のアドレス. . . . . . . . . . . . . . . . . . . . . .17 8の完全な著作権宣言文.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.
レアル-時間Flow Measurement(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.
このメモは、1996年にRTFMグループの仕事を進めるために始動されました。 この仕事の目標は、簡単な抽象化を起こして、同時にRTFM Metersの値を高めることです。(容易に、抽象化を実行できます)。 また、このドキュメントは流れ抽象化が既存の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 Meterの実現がホーソーン、ニューヨーク、米国でIBMでオークランド大学、NZ、スティーブンStibler、およびSigハンデルマンでネヴィル・ブラウンリーによって行われました。 また、RTFM WGはMeterからフロー・データを検索する役割がことであるMeter読者の役割を定義しました。
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
インターネットを横断するとき、Routers、Switches、および他のネットワーク部隊を通って移動するので、流れは特性のいくつかを変更させるかもしれません。 流れの属性について言及するとき、Meterの空間的な位置に注意するのは重要です。 例、サーバは確定注文と共にパケットの系列を送って、水漏れするバケツアルゴリズムでパケットタイミングを埋葬するかもしれません。 水漏れするバケツの検針川下は水漏れするバケツのため最小量の間のパケットタイミングでセットを記録するでしょう。 クライアントの位置に、パケットは順序が狂って到着するかもしれません。
Handelman, et al. Experimental [Page 2] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[2ページ]RFC2724RTFM: 新しい属性1999年10月
the timings altered. A meter at the client's location would
record different attributes for the same flow.
タイミングは変わりました。 クライアントの位置の1メーターは同じ流れのために異なった属性を記録するでしょう。
1.1 RTFM's Definition of Flows
1.1 RTFMの流れの定義
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 Meter構造は2つの終点(彼らのソース、目的地属性値、始め、および終わりの時代によって定義されるように)の間と、そして、BI-DIRECTIONALとして1セットのパケットであると流れをみなします(事実上、すなわち、メーターは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.
- '片道(uni方向の)'の流れは堕落したケースです。 既存のRTFMメーターは、指示を示すのに計算された属性(例えば、FlowKind)の1つを使用することによって、これを扱うことができます。
1.2 RTFM's Current Definition of Flows and their Attributes
1.2 Flowsと彼らのAttributesに関するRTFMのCurrent Definition
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。 また、各流れには、「計算された」属性(クラスとKind)のための値があるかもしれません。 終点属性値からこれらを直接得ます。
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。 各流れには、"LastTime"属性があります。(それは、メーターが最後に流れに関してパケットを見た時を示します)。
Handelman, et al. Experimental [Page 3] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[3ページ]RFC2724RTFM: 新しい属性1999年10月
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バイトのカウンタ、それぞれの流れ指示のためのもの(フォワードとBackward)があります。 流れのためのパケットがメーターによって観察されるようにこれらをアップデートします。
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。 すべての属性に、さまざまなプロトコルのための同じ意味が(多少)あります。 TCP/IPと同様にIPX、AppleTalk、DECnet、およびCLNS。
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ヘッダーからの直接Flow Labelと釣合うことができました。
1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows
1.3 流れにおけるRTFM流れ、統合サービス、IPPM、および研究
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を広げる目的のために、出発点はIntegrated Services WGの仕事です。 私たちはIntegrated Services構成プログラムでしばしば設定される量を測定するつもりです。私たちは、Benchmarking/IPパフォーマンスMetrics作業部会の仕事を見て、また、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].
容量と性能情報の使用に関する例は「IETFの統合サービスとのRSVPの使用」[IIS-RSVP]で見つけられます。 Integrated ServicesのRSVPの使用はToken Bucket Rate、Token Bucket Size、Peak Data Rate、Minimum Policed Unit、Maximum Packet Size、およびSlack用語頃に回転します。 これらは、TSpec、ADspec、およびFLowspec(統合Services Keywords)によって設定されて、Integrated Servicesの構成と操作に使用されます。 RTFMは明らかにPeak Data Rate、Minimum Policed Unit、Maximum Packet Size、およびSlack用語をモニターできました。 RTFMはToken Bucketの細部を推論できました。 WGはこれらのサービス測定基準で働く手段を発展させるでしょう。 IIS Monitoringの初期の実現はイタリア[IIS-ACCT]のCEFRIELのdevelopdです。
Handelman, et al. Experimental [Page 4] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[4ページ]RFC2724RTFM: 新しい属性1999年10月
RTFM will work with several traffic measurements identified by IPPM [IPPM-FRM]. There are three broad areas in which RTFM is useful for IPPM.
いくつかのトラフィック測定がIPPM[IPPM-FRM]によって特定されている状態で、RTFMは働くでしょう。 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 Meterは受動素子、集会交通、および性能統計として適切な場所でネットワーク(サーバかクライアント位置)で機能できました。
- RTFM could give detailed analyses of IPPM test flows that pass
through the Network segment that RTFM is monitoring.
- RTFMはRTFMがモニターしているNetworkセグメントを通り抜ける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:
パフォーマンス属性はスループット、パケット損失、遅れ、ジター、および混雑測定を含んでいます。 3つの一般的なクラスによると、RTFMは拡大の形で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.
様々なタイプの値がそれぞれのこれらのクラスの中の属性にあるかもしれないことに注意してください--数、配、時系列など。
2.1 Meter Readers and Meters
2.1メーター読者とメーター
A note on the relation between Meter Readers and Meters.
Meter読者と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.
非常に短い応答時間とまさしくその高帯域がある1メーターに限られるMeter読者は以下に列挙されたいくつかの測定値を実行できます。 そのような方法でMeter読者とMeterをアレンジできるなら、RTFMはタイムスタンプでPacket Tracesを集めて、さらなる処理のために直接Meter読者にそれらを提供するかもしれません。
Handelman, et al. Experimental [Page 5] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[5ページ]RFC2724RTFM: 新しい属性1999年10月
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.
より役に立つ代替手段はMeterにいくつかの流れ統計について局所的に計算させることです。 これはMeterとMeter読者の間の、よりゆるいカップリングを許容します。 Ruleテーブルでの設定によって、RTFMは'拡張属性'をモニターするでしょう。 RTFMはRuleテーブルでの明白な指示なしで少しの「拡張属性」データも作成しないでしょう。
2.2 Attribute Types
2.2 属性タイプ
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.
彼らが値(異なったタイプ各人)の系列を含む各列があるテーブルであるので、パケットTraces(以下で説明されるように)は特別なケースです。 それらは本質的にはすなわち、属性のリストが一連のパケットのために評価する'合成物'です。
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.
流れのためにFirstTimeから回を得ます。(最初のパケットが観察されるとき、それは、設定されます)。 流れにおける各パケットが観察されるようにLastTimeをアップデートします。
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:
彼らが共通点ですが、シングルが評価するように言い表されて、上のタイプが持っているすべて。 少なくとも新しい属性のいくつかが複数の値を必要とするでしょう。 例えば、相互パケット時間間隔に関心があるなら、私たちは1日以降にあらゆるパケットのために間隔を計算できます。 私たちはパケットサイズに関心があるなら、各パケットが到着するとき、新しい値を得ます。 このデータを格納することとなると、私たちには、2つのオプションがあります:
Handelman, et al. Experimental [Page 6] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[6ページ]RFC2724RTFM: 新しい属性1999年10月
- 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で説明されます。
2.3 Packet Traces
2.3 パケット跡
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"と呼ばれる新しい属性を持つだろうことです。 これは興味があるそれぞれの特性のためのコラムがあるテーブルであるかもしれません。 例えば、1つは以下をたどるかもしれません。
- Packet Arrival time (TimeTicks from sysUpTime, or microseconds
from FirstTime for the flow).
- パケットArrival時間(sysUpTimeからのTimeTicks、または流れのためのFirstTimeからのマイクロセカンド)。
- Packet Direction (Forward or Backward)
- パケット指示(前方か後方に)
- Packet Sequence number (for protocols with sequence numbers)
- パケットSequence番号(一連番号があるプロトコルのための)
- 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 Meterに、規則セットの書くことに詳しいユーザのためのものです。
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.
テーブルに列を加えるために、私たちはPushPkts PacketTraceが結果と考える規則を必要とするだけです。 これを使用するために、人は外で興味がある流れの少ない数を選択した規則セットに書くでしょう、それぞれのそれらのための'PushPkt PacketTrace'規則で。 2000年のMaxTraceRowsデフォルト値は、Meter読者がおよそ10分毎に2分の1のピング跡を読むのを許容するために十分でしょう。 より現実的に、それぞれの毎時の一度読まれた1分のピングには、500のMaxTraceRowsは十分でしょう。
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.
パケット跡はPacket Capture GroupのRMON MIB[RMON-MIB、RMON2-MIB]によって既に実行されます。 したがって、それらはRTFMに、低い優先度です。
Handelman, et al. Experimental [Page 7] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[7ページ]RFC2724RTFM: 新しい属性1999年10月
2.4 Aggregate Attributes
2.4 集合属性
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はPacket Size統計について計算できました。 単に最大値を保つのが時々十分であるかもしれませんが、配としてこのデータを格納できます。
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.
例と、Packet Sizeを考えてください。 流れで見つけられた最大のパケットサイズを決定するためにRTFMのパケット流れを調べることができます。 これは、流れに使用されることでMTUのしるしをNetwork Operatorに与えるでしょう。 また、それは、再送されるために損をしている大きいパケット原因のための流れの損失への感度のしるしにより多くのデータを与えるでしょう。
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.
集合属性が'古いスタイル'属性の単純拡大であることに注意してください。 それらの値は決してリセットされません。 例えば、カウンタのアレイは'パケットサイズ'分配を保持するかもしれません。 カウンタが、増加し続けていて、メーター読者が一定の間隔を置いてそれらの値を集めて、分析アプリケーションは、それぞれの収集間隔の間、パケットサイズの配を計算して、表示するでしょう。
2.5 Group Attributes
2.5 グループ属性
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.
グループ属性の概念は1つ以上のパケットが組み込まれている法案のために簡単な統計を保つことです。 このセクションは交通メーターで実行するのが可能であり、おもしろく役に立つように見えるいくつかのグループ属性について説明します。
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年の'前進の2番目のデータ信号速度に関心があるなら、メーターは以下の興味があるそれぞれの流れのためにこれを計算するかもしれません:
- 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秒の八重奏カウントを計算して、救ってください、そして、流れの前進の八重奏カウンタのコピーを保存してください。
Handelman, et al. Experimental [Page 8] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[8ページ]RFC2724RTFM: 新しい属性1999年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.
相互到着時間。 Meterはそれぞれの個々のパケットに遭遇する時間を知っています。 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.
ターンアラウンド統計。 それぞれの個々のパケットに遭遇して、パケットの間で時間間隔の統計を作成できる時間の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:
Subflow分析。 例えば、「ホストAとB.の間のすべてのTCPの流れ」Preliminary実現仕事は少なくともこのような場合それを示します--流れ終点の選択が計器規則セットによって制御されるので、集合流れを定義するのが簡単である、メーターがすべての活発な流れの情報のテーブルを維持するのは、可能であるべきです。少なくとも以下の属性を作り出すのにこれは使用できました:
- Number of streams, e.g. streams active for n-second intervals.
Determined for TCP and UDP using source-dest port number pairs.
- 流れ、例えば、n-第2間隔の間、活発な流れの数。 TCPとUDPのために、ソース-destポートナンバー組を使用することで、決定します。
- 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]で定義されます):
Handelman, et al. Experimental [Page 9] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[9ページ]RFC2724RTFM: 新しい属性1999年10月
- 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: [バイト/s] 保証されたサービスがある流れの速度--QoSSlackTerm、: [マイクロセカンド] 保証されたサービスがある流れのための低調なTerm QoSパラメタ--QoSTokenBucketRate、: 保証されたか制御された負荷サービスがある流れのための[バイト/s]象徴Bucket Rate QoSパラメタ
The following are also being considered:
また、以下は考えられています:
- QoSTokenBucketSize: [byte] Size of Token Bucket
- QoSTokenBucketSize: [バイト] 象徴バケツのサイズ
- QoSPeakDataRate: [byte/s] Maximum rate for incoming data
- QoSPeakDataRate: 受信データのための[バイト/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: [バイト] このこれにみなされたサイズより少ないIPデータグラム--QoSMaxDatagramSize、: [バイト] Exceptionsの上の2.6Actionsを交通仕様に従わせる最も大きいデータグラムのサイズ
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のユーザの中にはマークする能力がHigh Watermarksを持っているとして流れるよう要求した人もいました。 非結末流動などの異常な運転条件の存在、交通(例えば、それを運ぶ線の容量がくたくたになっている流れ)における与えられた限界を超えている流れはマネージャへの推進のためにMeter読者にALERTを送らせるでしょう。 操作Supportは多くの異なった環境でサービス状況を定義できました。 これはAlertのさらなる議論とTrap取り扱いのための領域です。
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 Meterがこのドキュメントの新しい属性の添加で変更されないのに同意しました。 このセクションは新しい属性を実行するのに必要である拡大について説明します。
3.1 Flow table extensions
3.1 フロー・テーブル拡大
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,"
RTFMの構造は流れの構造を定義しました、そして、このメモはその構造を変えません。 フロー・テーブルは「分配テーブルと跡のテーブル」と呼ばれる付属のテーブルを持っているかもしれません。
Handelman, et al. Experimental [Page 10] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[10ページ]RFC2724RTFM: 新しい属性1999年10月
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フロー・テーブルの対応する流れの数で示されるでしょう。
Note: The following section is for the user who is familiar with the writing of rule sets for the RTFM Meter.
以下に注意してください。 以下のセクションはRTFM Meterに、規則セットの書くことに詳しいユーザのためのものです。
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.
Packet Flow Tableのデータを特定するために、それぞれの列のヘッドで属性名をストリングに押し込むことができました。 例えば、テーブル項目に特定の流れのための「ビット伝送速度」があるなら、"ToBitRate"ストリングは列のヘッドで見つけられるでしょう。 (別法は、各拡張属性のために識別値をコード化して、列のヘッドにその値を押し込むだろうことです。) 10の拡張流れ属性のinitalセットに関してセクション4を見てください。
3.2 Specifying Distributions in RuleSets
3.2 RuleSetsで配を指定すること。
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 Meter構造に付加的特徴を追加するのはneccessaryに思えるでしょう。 しかしながら、これはケースをneccessarilyしないことです。
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).
実際に必要であるものはrulesetで分配パラメタを指定する方法です。 これらはカウンタ、下側の数と分配、それが直線的であるか、または対数であるか、そして、およびいかなる他の詳細の上限(例えば、短い長期料率属性のための時間間隔)も含んでいます。
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 Meter 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アドレスのサイズです。 私たちがしなければならないのは、これらのバイトがどう使用されるべきであるかを指定することです! 出発点として、以下は提案されます。(付番されたバイトは右にいなくなりました。
Handelman, et al. Experimental [Page 11] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[11ページ]RFC2724RTFM: 新しい属性1999年10月
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は最後のバケツのためにLimitsのための10乗数と最初に、バケツ5-6Upper Limit Highest値のためのカウンツ3-4Lower Limit Highest価値の対数の2Scale Factor Powerと等しいです。
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バケツNumber。 'オーバーフロー'バケツ2Parameter-1を含んでいません。 パラメタ使用が3-4による、Parameter-2、分配で貴重な5-6Parameter-3、属性
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).
これらのマスクと値の分野で、ドットは、前の数が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番目の規則はinterarrival-時間分配を指定します、レートのための60台のカウンタ(そして、オーバーフローバケツ)の配列に1msから1.8秒間まで対数目盛を使用して。 到着時間はマイクロセカンドのときに測定されます、したがって、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).
レートが5秒(パラメタ1)毎に計算されている状態で、3番目の規則は少し評価している分配を指定します。 カウンタ(そして、オーバーフローバケツ)が使用される60の対数の勢ぞろいは1つのキロビット毎秒から10Mbpsまで評価します。 3の位取り因数は、限界が何千ものbpsで与えられているのを示します(レートはビーピーエスで測定されます)。
Handelman, et al. Experimental [Page 12] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[12ページ]RFC2724RTFM: 新しい属性1999年10月
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.
これらの分配パラメタが、メーターに保存される必要があるので、それらは分配を組み込むのに利用可能です。 また、彼らは、メーターから読まれて、他のフロー・データと共に保存される必要があるでしょう。
3.3 Reading Distributions
3.3 読み込み配
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つの方向の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).
「古いスタイル」属性のRules Tableは新しい流れタイプのために広げられるでしょう。 動作のリスト、および"ToBitRate"、"ToPacketSize"などのキーワードは、特定の流れ(または、流れのセット)のために1セットの拡張値を集めるために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:
ここに、RTFM WGコンセンサスに従って1997年のミーティングで付番された10の可能な分配で評価された属性がミュンヘンにあります:
ToPacketSize(66) size of PDUs in bytes (i.e. number
FromPacketSize(67) of bytes actually transmitted)
バイトで表現されるPDUsのToPacketSize(66)サイズ(実際に伝えられたバイトのすなわち、数のFromPacketSize(67))
Handelman, et al. Experimental [Page 13] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[13ページ]RFC2724RTFM: 新しい属性1999年10月
ToInterarrivalTime(68) microseconds between successive packets
FromInterarrivalTime(69) travelling in the same direction
同じ方向に旅行する連続したパケットFromInterarrivalTime(69)の間のToInterarrivalTime(68)マイクロセカンド
ToTurnaroundTime(70) microseconds between successive packets
FromTurnaroundTime(71) travelling in opposite directions
それぞれ反対の方向に旅行する連続したパケットFromTurnaroundTime(71)の間のToTurnaroundTime(70)マイクロセカンド
ToBitRate(72) short-term flow rate in bits per second
FromBitRate(73) Parameter 1 = rate interval in seconds
秒のパラメタ1=レート間隔の間のbps FromBitRate(73)のToBitRate(72)の短期的な流速
ToPDURate(74) short-term flow rate in PDUs per second
FromPDURate(75) Parameter 1 = rate interval in seconds
秒のパラメタ1=レート間隔の間の第2FromPDURate(75)あたりのPDUsのToPDURate(74)の短期的な流速
(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
幅が流れの目的地DestPrefix(116) CIDR幅のための自治のSystem Numberが流れの送信先ネットワークを決定するのにルータで使用した流れのソースネットワークDestASN(115)を決定するのにルータで使用した流れのソースSourcePrefix(114) CIDRのためにNetFlowデータ(NetFlowMetがいくつかのルータからデータを取るのが必要である)のSourceASN(113)の自治のSystem Numberを生産するルータを特定するMeterID(112)整数
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.
分別よく'ベース'RTFMメーター属性のそれらを離れさせる64未満の属性番号を上記の或るもの(例えば、SourceASNとDestASN)に割り当てるかもしれません。
Handelman, et al. Experimental [Page 14] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[14ページ]RFC2724RTFM: 新しい属性1999年10月
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:
Differentiated Servicesを実装するトラフィックを計量するための'縁のDevice'がそのようなサービスで運んだのでRTFMメーターの使用をサポートするために、もうひとつの属性が役に立ちます:
DSCodePoint(118) DS Code Point (6 bits) for packets in this flow
この流れにおけるパケットのためのDSCodePoint(118) DS Code Point(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 Code PointがパケットのIPヘッダーの中のただ一つの分野であるので、SourceとDest-CodePoint属性の両方を持っているのは可能ではありません。 DSCodePointの可能な用途は、流れに集めるのを同じCode Pointsを使用することで含んでいます、そして、分離は、同じエンドポイントアドレスを持っていますが、異なったCode Pointsを使用することで流れます。
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.
本書では考えられた属性は交通の流れの特性を表します。 彼らは自分たちの少しの安全保障問題も提示しません。 しかしながら、属性は交通の流れのふるまいを測定する際に使用されるかもしれません、そして、集まっているトラフィックフロー・データには、かなりの価値があるかもしれません。 適当な注意は、そのようなデータを安全に保つために払われるべきです。
Handelman, et al. Experimental [Page 15] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[15ページ]RFC2724RTFM: 新しい属性1999年10月
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.、「インターネット交通の流れのためのParameterizable方法論は輪郭を描い」て、コミュニケーションの選択された領域に関するIEEEジャーナル、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.
[グアー-QOS] ShenkerとS.とヤマウズラとC.とR.ゲラン、「保証されたサービスの質の仕様」、RFC2212、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、ミラノ1998年5月5日。 (参照、 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.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[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パフォーマンス測定基準のためのフレームワーク」、RFC2330)は1998がそうするかもしれません。
[RMON-MIB] Waldbusser, S., "Remote Network Monitoring Management
Information Base", RFC 1757, February 1995.
[RMON-MIB] Waldbusser、S.、「リモートネットワーク監視管理情報ベース」、RFC1757、1995年2月。
[RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", RFC 2021,
January 1997.
[RMON2-MIB] Waldbusser、S.、「1997年1月にSMIv2"、RFC2021を使用するリモートネットワーク監視管理情報ベースバージョン2。」
[RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2722, October 1999.
[RTFM-アーク] ブラウンリー、N.、工場、C.、およびG.ルース、「流量測定を取引してください」 「アーキテクチャ」、RFC2722、1999年10月。
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC
2720, October 1999.
[RTFM-MIB]ブラウンリー、N.、「流量測定を取引してください」 「メーターMIB」、1999年10月のRFC2720。
Handelman, et al. Experimental [Page 16] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[16ページ]RFC2724RTFM: 新しい属性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ハンデルマンIBM研究事業部T.J.ワトソン研究所私書箱704ヨークタウンの高さ、10598
Phone: +1 914 784 7626 EMail: swhandel@us.ibm.com
以下に電話をしてください。 +1 7626年の914 784メール: 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ヨークタウンの高さ、10598
Phone: +1 914 784 7191 EMail: stibler@us.ibm.com
以下に電話をしてください。 +1 7191年の914 784メール: stibler@us.ibm.com
Nevil Brownlee Information Technology Systems & Services The University of Auckland Private Bag 92-019 Auckland, New Zealand
ネヴィルブラウンリー情報技術システムとServicesオークランド大学の個人的なBag92-019オークランド(ニュージーランド)
Phone: +64 9 373 7599 x8941 EMail: n.brownlee@auckland.ac.nz
以下に電話をしてください。 +64 9 373 7599x8941 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.
グレッグルースGTE Internteworking3バン・デ・グラーフDrive P.O. Box3073バーリントン、MA 01803、米国
Phone: +1 781 262 4831 EMail: gruth@bbn.com
以下に電話をしてください。 +1 4831年の781 262メール: gruth@bbn.com
Handelman, et al. Experimental [Page 17] RFC 2724 RTFM: New Attributes October 1999
ハンデルマン、他 実験的な[17ページ]RFC2724RTFM: 新しい属性1999年10月
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Handelman, et al. Experimental [Page 18]
ハンデルマン、他 実験的[18ページ]
一覧
スポンサーリンク
