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