RFC2063 日本語訳

2063 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G.Ruth. January 1997. (Format: TXT=89092 bytes) (Obsoleted by RFC2722) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                        N. Brownlee
Request for Comments: 2063                    The University of Auckland
Category: Experimental                                          C. Mills
                                            BBN Systems and Technologies
                                                                 G. Ruth
                                                  GTE Laboratories, Inc.
                                                            January 1997

コメントを求めるワーキンググループN.ブラウンリーの要求をネットワークでつないでください: 2063 オークランド大学カテゴリ: 実験的なC.は研究所Inc.1997年1月にBBNシステムと技術G.ルースGTEを製粉します。

                Traffic Flow Measurement:  Architecture

交通の流れ測定: アーキテクチャ

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Abstract

要約

   This document describes an architecture for the measurement and
   reporting of network traffic flows, discusses how this relates to an
   overall network traffic flow architecture, and describes how it can
   be used within the Internet.  It is intended to provide a starting
   point for the Realtime Traffic Flow Measurement Working Group.

このドキュメントが測定のためにアーキテクチャについて説明して、ネットワークトラフィックの報告は、流れて、これがどう総合的なネットワークトラフィック流れアーキテクチャに関連するかについて議論して、インターネットの中でどうそれを使用できるかを説明します。 Realtime Traffic Flow Measurement作業部会に出発点を提供するのは意図しています。

Table of Contents

目次

 1 Statement of Purpose and Scope                                     2
 2 Traffic Flow Measurement Architecture                              4
   2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . .   4
   2.2 Interaction Between METER and METER READER . . . . . . . . .   6
   2.3 Interaction Between MANAGER and METER  . . . . . . . . . . .   6
   2.4 Interaction Between MANAGER and METER READER . . . . . . . .   7
   2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . .   7
   2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . .   8
   2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . .   8
 3 Traffic Flows and Reporting Granularity                            9
   3.1 Flows and their Attributes . . . . . . . . . . . . . . . . .   9
   3.2 Granularity of Flow Measurements . . . . . . . . . . . . . .  11
   3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only  . .  13
 4 Meters                                                            15
   4.1 Meter Structure  . . . . . . . . . . . . . . . . . . . . . .  15
   4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . .  17
   4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . .  17
   4.4 Rules and Rule Sets  . . . . . . . . . . . . . . . . . . . .  21
   4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . .  24
   4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . .  25

1 目的説明書と範囲2 2はマネージャとメーターとの流量測定アーキテクチャ4 2.1メーター、間の.42.2相互作用が計量する交通の流れ、およびメーター読者.62.3相互作用を取引します…; マネージャとメーター読者.72.5倍数との.62.4相互作用は、読者のためにマネージャ(マネージャ--マネージャ)の.82.7メーターの読者とアプリケーションとの.72.6相互作用を計量するか、または計量します; .8 3トラフィックFlowsとReporting Granularity、9、3.1Flows、彼らのFlow Measurements.113.3Rolling Counters、Timestamps、あるバケツだけの中のReport. . 13 4Meters15 4.1Meter Structure. . . . . . . . . . . . . . . . . . . . . . 15 4.2Flow Table.174.3Packet Handling、Packet Matching. . . . . . . . . . . . . . 17 4.4Rules、およびRuのAttributes.93.2Granularityle Sets. . . . . . . . . . . . . . . . . . . . 21 4.5Maintaining Flow Table. . . . . . . . . . . . . . . . . 24 4.6Handling Increasing Traffic Levels. . . . . . . . . . . . . 25

Brownlee, et. al.             Experimental                      [Page 1]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[1ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

 5 Meter Readers                                                     26
   5.1 Identifying Flows in Flow Records  . . . . . . . . . . . . .  26
   5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . .  27
   5.3 Meter to Meter Reader:  Usage Record Transmission. . . . . .  27
 6 Managers                                                          28
   6.1 Between Manager and Meter:  Control Functions  . . . . . . .  28
   6.2 Between Manager and Meter Reader:  Control Functions   . . .  29
   6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . .  31
   6.4 Standard Rule Sets   . . . . . . . . . . . . . . . . . . . .  32
 7 APPENDICES                                                        33
   7.1 Appendix A: Network Characterisation . . . . . . . . . . . .  33
   7.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 34
   7.3 Appendix C: List of Defined Flow Attributes  . . . . . . . .  35
   7.4 Appendix D: List of Meter Control Variables  . . . . . . . .  36
 8 Acknowledgments                                                   36
 9 References                                                        37
10 Security Considerations                                           37
11 Authors' Addresses                                                37

5メーターの読者26 5.1が流れ記録. . . . . . . . . . . . . 26 5.2用法記録における流れを特定して、フロー・データファイル. . . . . . . . . . . . . . . 27 5.3は読者を計量するために計量されます: 用法レコード転送。 . . . . . 27 マネージャとメーターの間の6人のマネージャ28 6.1: マネージャとメーター読者の間の機能. . . . . . . 28 6.2を制御してください: コントロール機能. . . 29 6.3例外条件. . . . . . . . . . . . . . . . . . . . 31 6.4 標準の規則は.327個の付録33 7.1付録A:を設定します。 特殊化. . . . . . . . . . . . 33 7.2付録Bをネットワークでつないでください: お勧めの交通の流れ測定能力34 7.3付録C: 定義された流れ属性. . . . . . . . 35 7.4付録Dのリスト: メーター制御変数. . . . . . . . 36 8承認36 9つの参照箇所37 10のセキュリティ問題37 11作者のアドレス37のリスト

1 Statement of Purpose and Scope

1 目的説明書と範囲

   This document describes an architecture for traffic flow measurement
   and reporting for data networks which has the following
   characteristics:

このドキュメントはトラフィック流量測定とデータ網を届け出るための以下の特性を持っているアーキテクチャについて説明します:

     - The traffic flow model can be consistently applied to any
       protocol/application at any network layer (e.g.  network,
       transport, application layers).

- どんなネットワーク層でもどんなプロトコル/アプリケーションにも交通の流れモデルを一貫して適用できます(例えば、ネットワーク、輸送、アプリケーションは層にされます)。

     - 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.

- 交通の流れ属性は複数のネットワークプロトコル・スタックに、それらが有効であり、交通の流れ測定実装がMULTI-プロトコル環境で役に立つような方法で定義されます。

     - Users may specify their traffic flow measurement requirements
       in a simple manner, 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 reduces the volume of data to be
       obtained (and transmitted across the network for storage),
       and minimises the amount of processing required in traffic
       flow analysis applications.

- 生産するデータ整理取り組みは、交通の流れ情報が置かれるよう要求しました。できるだけネットワーク測定ポイントに近いです。 これは、得る(そして、ストレージのためにネットワークの向こう側に伝えられる)ためにデータ量を減少させて、交通の流れ分析アプリケーションで必要である処理の量を最小とならせます。

Brownlee, et. al.             Experimental                      [Page 2]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[2ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   The architecture specifies common metrics for measuring traffic
   flows.  By using the same metrics, traffic flow data can be exchanged
   and compared across multiple platforms.  Such data is useful for:

アーキテクチャは測定交通の流れに一般的な測定基準を指定します。 同じ測定基準を使用することによって、複数のプラットホームの向こう側にトラフィックフロー・データを交換して、比較できます。そのようなデータは以下の役に立ちます。

     - Understanding the behaviour of existing networks,

- 既存のネットワークのふるまいを理解しています。

     - Planning for network development and expansion,

- ネットワーク開発と拡張の計画を立てます。

     - Quantification of network performance,

- ネットワーク性能の定量化

     - Verifying the quality of network service, and

- そしてネットワーク・サービスの品質について確かめる。

     - Attribution of network usage to users.

- ユーザへのネットワーク用法の属性。

   The traffic flow measurement architecture is deliberately structured
   so that specific protocol implementations may extend coverage to
   multi-protocol environments and to other protocol layers, such as
   usage measurement for application-level services.  Use of the same
   model for both network- and application-level measurement may
   simplify the development of generic analysis applications which
   process and/or correlate any or all levels of traffic and usage
   information.  Within this docuemt the term 'usage data' is used as a
   generic term for the data obtained using the traffic flow measurement
   architecture.

交通の流れ測定アーキテクチャは特定のプロトコル実装がマルチプロトコル環境と、そして、他のプロトコル層に適用範囲を広げることができるように、故意に構造化されます、アプリケーションレベルサービスのための用法測定などのように。 同じモデルのネットワークとアプリケーションレベル測定の両方の使用はいずれかすべてのレベルのトラフィックと用法情報を処理する、そして/または、関連させるジェネリック分析アプリケーションの開発を簡素化するかもしれません。 このdocuemtの中では、'用法データ'という用語は交通の流れ測定アーキテクチャを使用することで得られたデータに総称として使用されます。

   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 'Traffic Flow Measurement:  Background' RFC [1].

基礎的な情報('Flow Measurementを取引してください'このアプローチが選択された理由が提供されると説明して、) 'バックグラウンド'RFC[1]。

Brownlee, et. al.             Experimental                      [Page 3]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[3ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

2 Traffic Flow Measurement Architecture

2 交通の流れ測定アーキテクチャ

   A traffic flow measurement system is used by network Operations
   personnel for 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).

交通の流れ測定システムは、ネットワークを経営していて、発展させるのにネットワークOperations人員によって使用されます。 それはネットワークの交通の流れを測定して、理解しているのにツールを提供します。 この情報はセクション1(above)で言及されるように多くの目的の役に立ちます。

   The following sections outline a model for traffic flow measurement,
   which draws from working drafts of the OSI accounting model [2].
   Future extensions are anticipated as the model is refined to address
   additional protocol layers.

以下のセクションはトラフィック流量測定のためにモデルについて概説します。(それは、OSI会計モデル[2]の概要版から描かれます)。 モデルが追加議定書層を扱うために洗練されるとき、今後の拡大は予期されます。

2.1 Meters and Traffic Flows

2.1 Metersと交通の流れ

   At the heart of the traffic measurement model are network entities
   called traffic METERS. Meters count certain attributes (such as
   numbers of packets and bytes) and classify them as belonging to
   ACCOUNTABLE ENTITIES using other attributes (such as source and
   destination addresses).  An accountable entity is someone who (or
   something which) is responsible for some activitiy on the network.
   It may be a user, a host system, a network, a group of networks, etc,
   depending on the granularity specified by the meter's configuration.

トラフィックMetersと呼ばれるネットワーク実体はトラフィック測定モデルの中心です。 メーターは、ある属性(パケットとバイトの数などの)を数えて、他の属性(ソースや送付先アドレスなどの)を使用することでACCOUNTABLE ENTITIESに属すとしてそれらを分類します。 責任がある実体がだれかである、だれ、(例えば、どれ、)、ネットワークのいくらかのactivitiyに責任があるか。 それはユーザ、ホストシステム、ネットワーク、ネットワークのグループであるかもしれませんなど、計器構成によって指定された粒状によって。

   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 'Traffic Flow
   Measurement:  Background' RFC [1].  An important aspect of meters is
   that they provide a way of succinctly aggregating entity usage
   information.

私たちはネットワーク中のルータかトラフィックモニターがメーターで器具を取り付けられて、トラフィックを測定すると思います。 'トラフィックFlow Measurementでメータープレースメントの選択を囲む問題について議論します:、' 'バックグラウンド'RFC[1]。 メーターの重要な一面は簡潔に実体用法情報に集める方法を提供するということです。

   For the purpose of traffic flow measurement we define the concept of
   a TRAFFIC FLOW, which is an artificial logical equivalent to a call
   or connection.  A flow is a portion of traffic, delimited by a start
   and stop time, that was generated by a particular accountable entity.
   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 end time may increase with the age of the flow.

トラフィック流量測定の目的のために、私たちはTRAFFIC FLOWの概念を定義します。(TRAFFIC FLOWは呼び出しか接続と人工の論理的な同等物です)。 流れは特定の責任がある実体によって生成された始めと停止時間までに区切られたトラフィックの部分です。 流れに関連している属性値(ソース/送付先アドレス、パケットカウント、バイト・カウントなど)は始めと停止時間の間の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.             Experimental                      [Page 4]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[4ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   which flow they belong to.  Classifying packets into 'flows' in this
   way provides an economical and practical way to measure network
   traffic and ascribe it to accountable entities.

彼らはどの流れに属しますか? このようにパケットを'流れ'に分類すると、ネットワークトラフィックを測定して、それを責任がある実体のせいにする経済的で実用的な方法は提供されます。

   Usage information which is not deriveable 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 will 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 APPLICAIONS, 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 APPLICAIONSを入れます。(ANALYSIS APPLICAIONSは以下の章で説明されます)。 それらの間の関係は以下のダイヤグラムで示されます。 ダイヤグラムの数は本書ではセクションを示します。

                    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 uses the data requirements of analysis applications to determine
    the appropriate configurations for each meter, and the proper
    operation of each 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.'

- 以下を計量してください。 メーターはネットワークOperations人員で決定している測定ポイントに置かれます。 各メーターは構成設定によって指示されているとして選択的にネットワーク活動を記録します。 また、データが保存される前に、それは、記録された活動を集めて、変えて、さらに、処理できます。 処理されて保存された結果は'用法データ'と呼ばれます。

  - METER READER: A meter reader reliably transports usage data from
    meters so that it is available to analysis applications.

- 読者を計量してください: メーター読者がメーターからの用法データを確かに輸送するので、それは分析アプリケーションに利用可能です。

Brownlee, et. al.             Experimental                      [Page 5]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[5ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

  - 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, indicating how flow
         rates vary with 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.  At the time of writing a meter can only be controlled by a
   single manager; in the future this restriction may be relaxed.  Each
   meter's configuration includes information such as:

マネージャは1個以上のメーター以上を構成して、制御するのに責任があります。 独身のマネージャはこれを書いている時点で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 maximum size of its flow table,
    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.             Experimental                      [Page 6]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[6ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

  - Sampling rate.  Normally every packet will be observed.  It may
    sometimes be necessary to use sampling techniques to observe only
    some of the packets.  (Sampling algorithms are not prescribed by
    the architecture; it should be noted that before using sampling one
    should verify the statistical validity of the algorithm used).
    Current experience with the measurement architecture shows that a
    carefully-designed and implemented meter compresses the data such
    that in normal LANs and WANs of today sampling is really not
    needed.

- 標本抽出率。 通常あらゆるパケットが観察されるでしょう。 いくつかのパケットだけを観察するのにサンプリング技法を使用するのが時々必要であるかもしれません。 (標本抽出アルゴリズムはアーキテクチャによって定められません; 標本抽出を使用する前に使用されるアルゴリズムの統計的な正当性について確かめるべきであることに注意されるべきです。) 測定アーキテクチャの現在の経験は、入念に設計されて実装しているメーターが標準では、今日の標本抽出のLANとWANは本当に必要でないようにデータを圧縮するのを示します。

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 is is collecting usage data from:

マネージャは1メーター以上の読者を構成して、監督するのに責任があります。 メーター読者は独身のマネージャによって監督されるだけであるかもしれません。 読者が少なくともあらゆるメーター以下を知るために必要とする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 active flows, the
    whole flow table, flows seen 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.

余分な報告が用法データの信頼性を増強するのに使用されているかもしれないので、また、複数の実体の中の交換を考えなければなりません。 以下でこれらについて議論します。

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メーター以上の読者に報告するかもしれません。 上のダイヤグラムはどう複数のメーターとメーター読者を使用できたかに関する例を出します。

Brownlee, et. al.             Experimental                      [Page 7]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[7ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年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 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.

しかしながら、メーター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 neccesarily 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は、同じ時にともに同じ間隔を置いて用法データを集めますが、neccesarilyに集めることができませんでした。 収集が非同期であるので2人の異なったメーター読者からの用法記録がまさに同意するのが、ありそうもないことに注意してください。

   If precisely synchronized collections are required this can be
   achieved by having one manager request each meter to begin collecting
   a new set of flows, then allowing all meter readers to collect the
   usage data from the old sets of flows.

正確に連動している収集が必要であるなら、各メーター単位で新しい流れを集め始めるために1つのマネージャ要求を持っていることによって、これを達成できます、次に、すべてのメーター読者が古い流れから用法データを集めるのを許容して。

   If there is only one meter reader and it fails, the meters continue
   to run.  When the meter reader is restarted it can collect all of the
   accumulated flow data.  Should this happen, time resolution will be
   lost (because of the missed collections) but overall traffic flow
   information will not.  The only exception to this would occur if the
   traffic volume was sufficient to 'roll over' counters for some flows
   during the failure; this is addressed in the section on 'Rolling
   Counters.'

1メーターだけの読者がいて、失敗するなら、メーターは、稼働し続けています。 メーター読者が再出発されるとき、それは蓄積されたフロー・データのすべてを集めることができます。 これが起こると、時間解決は失われるでしょうが(逃された収集のために)、総合的な交通の流れ情報は失われるというわけではないでしょう。 交通量がいくつかの流れのために失敗の間、カウンタを'ひっくり返らせる'ために十分であるなら、これへの唯一の例外が起こるでしょうに。 これは'回転している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.

用法データの収集がメーター読者によっていったん組み立てられると、分析アプリケーションでそれを処理できます。 このアーキテクチャの範囲の外にそれらが製作するレポートや彼らが必要とするデータなどの分析アプリケーションの詳細があります。

Brownlee, et. al.             Experimental                      [Page 8]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[8ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   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 an ACCOUNTABLE ENTITY."

「TRAFFIC FLOWはACCOUNTABLE ENTITYに属す呼び出しか接続とartificalの論理的な同等物です。」

   In practical terms, a flow is a stream of packets passing across a
   network between two end points (or being sent 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の値を保持します。 これらの属性は以下を含むかもしれません。

  - 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), 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.  information computed by the meter.

- OTHER属性、例えばメーターによって計算された情報。

   A flow's ACCOUNTABLE ENTITY is specified by the values of its ADDRESS
   attributes.  For example, if a flow's address attributes specified
   only that "source address = IP address 10.1.0.1," then all IP packets
   from and to that address would be counted in that flow.  If a flow's
   address list were specified as "source address = IP address 10.1.0.1,
   destination address = IP address 26.1.0.1" then only IP packets
   between 10.1.0.1 and 26.1.0.1 would be counted in that flow.

流れのACCOUNTABLE ENTITYはADDRESS属性の値によって指定されます。 例えば、流れのアドレス属性がその「ソースアドレス=IPアドレス10.1.0.1」だけ、を指定するなら、アドレスとそのアドレスへのすべてのIPパケットがその流れで数えられるでしょうに。 流れの住所録として指定された、「ソースアドレスがIPアドレスと等しい、10.1、.0、.1、送付先アドレス=IPが、次に、唯一の.00.1インチIPが10.1の間のパケットであると26.1に扱う、.0、.1と26.1、流れる.1が数えられる.0、」

Brownlee, et. al.             Experimental                      [Page 9]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[9ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   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 [n-1] layer address of the
    immediate source or destination on the path of the packet.  For
    example, if flow measurement is being performed at the IP layer on
    an Ethernet LAN [3], an adjacent address is 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.

- ADJACENT ADDRESS(すなわち、パケットの経路の即座のソースか目的地の[n-1]層のアドレス)。 例えば、流量測定がIP層でイーサネットLAN[3]に実行されているなら、隣接しているアドレスは6八重奏のメディアAccess Control(MAC)アドレスです。 隣接しているアドレスはメーターと同じLANセグメントに接続されたホストにとってのそのホストのMACアドレスになるでしょう。 それは他のLANセグメントのホストにとっての、交通の流れを運ぶ隣接している(上流か川下)ルータのMACアドレスになるでしょう。

  - The PEER ADDRESS, which identifies the source or destination of the
    PEER-LEVEL packet.  The form of a peer address will depend on the
    network-layer protocol in use, and the network layer [n] at which
    traffic measurement is being performed.

- PEER ADDRESS。(そのPEER ADDRESSはPEER-LEVELパケットのソースか目的地を特定します)。 同輩アドレスのフォームは使用中のネットワーク層プロトコル、およびトラフィック測定が実行されているネットワーク層[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.  Further work is needed here, particularly in
   selecting attributes which will be suitable for the higher layers of
   the OSI reference model.

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. Further work is needed here, particularly in selecting attributes which will be suitable for the higher layers of the OSI reference model.

Brownlee, et. al.             Experimental                     [Page 10]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 10] RFC 2063 Traffic Flow Measurement: Architecture January 1997

   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 'Traffic Flow Measurement:  Background' RFC [1].  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.

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 'Traffic Flow Measurement: Background' RFC [1]. 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.

   In cases where network addresses are dynamically allocated (e.g.
   mobile subscribers), further subscriber identification will be
   necessary if flows are to ascribed to individual users.  Provision is
   made to further specify the accountable entity 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 proprietary means within a meter, for example via protocol
   exchanges with one or more (multi-user) hosts.  At this time a
   subscriber ID is an arbitrary text string; later versions of the
   architecture may specify its contents on more detail.

In cases where network addresses are dynamically allocated (e.g. mobile subscribers), further subscriber identification will be necessary if flows are to ascribed to individual users. Provision is made to further specify the accountable entity 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 proprietary means within a meter, for example via protocol exchanges with one or more (multi-user) hosts. At this time a subscriber ID is an arbitrary text string; later versions of the architecture may specify its contents on more detail.

3.2 Granularity of Flow Measurements

3.2 Granularity of Flow Measurements

   GRANULARITY is the 'control knob' by which an application and/or the
   meter can trade off the overhead associated with performing usage
   reporting against the level of detail supplied.  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 the accountable entity, the attributes, or the time intervals.
   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.

GRANULARITY is the 'control knob' by which an application and/or the meter can trade off the overhead associated with performing usage reporting against the level of detail supplied. 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 the accountable entity, the attributes, or the time intervals. 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.

   Flow granularity is controlled by adjusting the level of detail at
   which the following are reported:

Flow granularity is controlled by adjusting the level of detail at which the following are reported:

  - The accountable entity (address attributes, discussed above).

- The accountable entity (address attributes, discussed above).

  - The categorisation of packets (other attributes, discussed below).

- 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 lifetime/duration of flows (the reporting interval needs to be short enough to measure them with sufficient precision).

Brownlee, et. al.             Experimental                     [Page 11]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 11] RFC 2063 Traffic Flow Measurement: Architecture January 1997

   The set of rules controlling the determination of each packet's
   accountable entity 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.

The set of rules controlling the determination of each packet's accountable entity 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.

   Settings for these granularity factors may vary from meter to meter.
   They are determined by the meter's current rule set, so they will
   change if network Operations personnel reconfigure the meter to use a
   new rule set.  It is expected that the collection rules will change
   rather infrequently; nonetheless, the rule set in effect at any time
   must be identifiable via a RULE SET ID. Granularity of accountable
   entities is further specified by additional ATTRIBUTES. These
   attributes include:

Settings for these granularity factors may vary from meter to meter. They are determined by the meter's current rule set, so they will change if network Operations personnel reconfigure the meter to use a new rule set. It is expected that the collection rules will change rather infrequently; nonetheless, the rule set in effect at any time must be identifiable via a RULE SET ID. Granularity of accountable entities is further specified by additional ATTRIBUTES. These attributes include:

     - Meter variables such as the index of the flow's record in the flow
       table and the rule set id 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.

- Meter variables such as the index of the flow's record in the flow table and the rule set id 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.

     - 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.

- 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.

     - Administratively specified attributes such as Quality Of Service
       and Priority, etc.  These are not defined at this time.

- Administratively specified attributes such as Quality Of Service and Priority, etc. These are not defined at this time.

     - Higher-layer (especially application-level) attributes.  These are
       not defined at this time.

- Higher-layer (especially application-level) attributes. These are not defined at this time.

   Settings for these granularity factors may vary from meter to meter.
   They are determined by the meter's current rule set, so they will
   change if network Operations personnel reconfigure the meter to use a
   new rule set.

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.

   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

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

Brownlee, et. al.             Experimental                     [Page 12]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 12] RFC 2063 Traffic Flow Measurement: Architecture January 1997

   application may compare the data from each collection so as to
   determine when each flow actually stopped.

application may compare the data from each collection so as to determine when each flow actually stopped.

   The meter does, however, need to reclaim memory (i.e.  records in the
   flow table) being held by idle flows.  The meter configuration
   includes a variable called InactivityTimeout, which specifies the
   minimum time a meter must wait before recovering the flow's record.
   In addition, before recovering a flow record the meter must be sure
   that the flow's data has been collected by at least one meter reader.

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 must be sure that the flow's data has been collected by at least one meter reader.

   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.

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.

3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only

3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only

   Once an 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.

Once an 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.

   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.

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, then NEW FLOW

                         start time = 1            start time = 1
   Usage record N:       flow count = 2000      flow count = 2000 (done)

start time = 1 start time = 1 Usage record N: flow count = 2000 flow count = 2000 (done)

                         start time = 1            start time = 5
   Usage record N+1:     flow count = 3000      new flow count = 1000

start time = 1 start time = 5 Usage record N+1: flow count = 3000 new flow count = 1000

   Total count:                 3000                    3000

Total count: 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

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

Brownlee, et. al.             Experimental                     [Page 13]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 13] RFC 2063 Traffic Flow Measurement: Architecture January 1997

   was then stopped (perhaps because of temporary idleness, or MAX
   LIFETIME policy), 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.

was then stopped (perhaps because of temporary idleness, or MAX LIFETIME policy), 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.

   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.

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.

   Each packet is counted in one and only one flow, 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.

Each packet is counted in one and only one flow, 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.

   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.'
   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:

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.' 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:

        Bucket 1:  Packets which came in interface 1,
                   AND were sourced by IP address a.b.c.d

Bucket 1: Packets which came in interface 1, AND were sourced by IP address a.b.c.d

        Bucket 2:  Packets which came in interface 1,
                   AND were NOT sourced by IP address a.b.c.d

Bucket 2: Packets which came in interface 1, AND were NOT sourced by IP address a.b.c.d

        Bucket 3:  Packets which did NOT come in interface 1,
                   AND were sourced by IP address a.b.c.d

Bucket 3: Packets which did NOT come in interface 1, AND were sourced by IP address a.b.c.d

       (Bucket 4:  Packets which did NOT come in interface 1,
                   AND NOT sourced by IP address a.b.c.d)

(Bucket 4: Packets which did NOT come in interface 1, AND NOT sourced by IP address 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.

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.

Brownlee, et. al.             Experimental                     [Page 14]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 14] RFC 2063 Traffic Flow Measurement: Architecture January 1997

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.

A traffic flow meter is a device for collecting data about traffic flows at a given point within a network; we will call this the METERING POINT. The header of every packet passing the network metering point is offered to the traffic meter program.

   A meter could be implemented in various ways, including:

A meter could be implemented in various ways, including:

  - A dedicated small host, connected to a 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.

- A dedicated small host, connected to a 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.

  - 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.

- 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.

  - 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.

- 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.

   The discussion in the following sections assumes that a meter may
   only run a single rule set.  It is, however, possible for a meter to
   run several rule sets concurrently, matching each packet against
   every active rule set and producing a single flow table with flows
   from all the active rule sets.  The overall effect of doing this
   would be similar to running several independent meters, one for each
   rule set.

The discussion in the following sections assumes that a meter may only run a single rule set. It is, however, possible for a meter to run several rule sets concurrently, matching each packet against every active rule set and producing a single flow table with flows from all the active rule sets. The overall effect of doing this would be similar to running several independent meters, one for each rule set.

4.1 Meter Structure

4.1 Meter Structure

   An outline of the meter's structure is given in the following
   diagram.

An outline of the meter's structure is given in the following diagram.

   Briefly, the meter works as follows:

Briefly, the meter works as follows:

  - Incoming packet headers arrive at the top left of the diagram and
    are passed to the PACKET PROCESSOR.

- Incoming packet headers arrive at the top left of the diagram and are passed to the PACKET PROCESSOR.

  - The packet processor passes them to the Packet Matching Engine
    (PME) where they are classified.

- The packet processor passes them to the Packet Matching Engine (PME) where they are classified.

  - The PME is a Virtual Machine running a pattern matching program
    contained in the CURRENT RULE SET. It is invoked by the Packet
    Processor, and returns instructions on what to do with the packet.

- The PME is a Virtual Machine running a pattern matching program contained in the CURRENT RULE SET. It is invoked by the Packet Processor, and returns instructions on what to do with the packet.

Brownlee, et. al.             Experimental                     [Page 15]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 15] RFC 2063 Traffic Flow Measurement: Architecture January 1997

  - Some packets are classified as 'to be ignored.'  They are discarded
    by the Packet Processor.

- Some packets are classified as 'to be ignored.' They are discarded by the Packet Processor.

  - Other packets are matched by the PME, which returns a FLOW KEY
    describing the flow to which the packet belongs.

- Other packets are matched by the PME, which returns a FLOW KEY describing the flow to which the packet belongs.

  - 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
    packet and byte counters are updated.

- 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 packet and byte counters are updated.

  - A meter reader may collect data from the flow table at any time.
    It may use the 'collect' index to locate the flows to be collected
    within the flow table.

- 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 |
                    |                   +--------+---------+
                    |                            |
           +--------*---------+       +----------*-------------+
           | Packet Processor |<----->| Packet Matching Engine |
           +--+------------+--+       +------------------------+
              |            |
       Ignore *            | Count via flow key
                           |
                        +--*--------------+
                        | 'Search' index  |
                        +--------+--------+
                                 |
                        +--------*--------+
                        |                 |
                        |   Flow Table    |
                        |                 |
                        +--------+--------+
                                 |
                        +--------*--------+
                        | 'Collect' index |
                        +--------+--------+
                                 |
                                 *
                            Meter Reader

packet +------------------+ header | Current Rule Set | | +--------+---------+ | | +--------*---------+ +----------*-------------+ | Packet Processor |<----->| Packet Matching Engine | +--+------------+--+ +------------------------+ | | Ignore * | Count via flow key | +--*--------------+ | 'Search' index | +--------+--------+ | +--------*--------+ | | | Flow Table | | | +--------+--------+ | +--------*--------+ | 'Collect' index | +--------+--------+ | * Meter Reader

Brownlee, et. al.             Experimental                     [Page 16]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 16] RFC 2063 Traffic Flow Measurement: Architecture January 1997

4.2 Flow Table

4.2 Flow Table

   Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for
   flows seen by the meter.  A flow record contains attribute values for
   its flow, including:

Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for flows seen by the meter. A flow record contains attribute values for its flow, including:

  - Addresses for the flow's source and destination.  These include
    addresses and masks for various network layers (extracted from the
    packet), and the number of the interface on which the packet was
    observed.

- Addresses for the flow's source and destination. These include addresses and masks for various network layers (extracted from the packet), and the number of the interface on which the packet was observed.

  - First and last times when packets were seen for this flow.

- First and last times when packets were seen for this flow.

  - Counts for 'forward' (source to destination) and 'backward'
    (destination to source) components of the flow's traffic.

- 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).

- Other attributes, e.g. state of the flow record (discussed below).

   The state of a flow record may be:

The state of a flow record may be:

  - INACTIVE: The flow record is not being used by the meter.

- 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.

- 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.

- 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.

4.3 Packet Handling, Packet Matching

4.3 Packet Handling, Packet Matching

   Each packet header received by the traffic meter program is processed
   as follows:

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.

- Extract attribute values from the packet header and use them to create a MATCH KEY for the packet.

  - Match the packet's key against the current rule set, as explained
    in detail below.

- 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 counts
   for the matching flow record can then be incremented.

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 counts for the matching flow record can then be incremented.

Brownlee, et. al.             Experimental                     [Page 17]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 17] RFC 2063 Traffic Flow Measurement: Architecture January 1997

   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.

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.

   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 an interface number, source
   address (S) and destination address (D) values.  It does not,
   however, contain any attribute masks for its attributes, only their
   values.

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 an interface number, source address (S) and destination address (D) values. It does not, however, contain any attribute masks for its attributes, only their values.

   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.

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.

   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.

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.

   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, and D indicates
   its destination address.

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, and D indicates its destination address.

   There are several cases to consider.  These are:

There are several cases to consider. These are:

  - The packet is recognised as one which is TO BE IGNORED.

- The packet is recognised as one which is TO BE IGNORED.

  - The packet MATCHES IN BOTH DIRECTIONS. 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.

- The packet MATCHES IN BOTH DIRECTIONS. 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.

Brownlee, et. al.             Experimental                     [Page 18]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 18] RFC 2063 Traffic Flow Measurement: Architecture January 1997

  - 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.

- 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.

   The algorithm uses four functions, as follows:

The algorithm uses four functions, as follows:

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:

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:

   'Ignore' means that the packet was matched but this flow is not
            to be counted.

'Ignore' means that the packet was matched but this flow is not to be counted.

   'Fail' means that the packet did not match.  It might, however
            match with its direction reversed, i.e. from B to A.

'Fail' means that the packet did not match. It might, however match with its direction reversed, i.e. from B to A.

   'Suc'  means that the packet did match, i.e. it belongs to a flow
            which is to be counted.

'Suc' means that the packet did match, i.e. it belongs to a flow which is to be counted.

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.

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.

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.

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.

count(A->B,f) increments the 'forward' counters for flow A-to-B.
count(A->B,r) increments the 'reverse' counters for flow A-to-B.
   'Forward' here means the counters for packets travelling from
   A to B.  Note that count(A->B,f) is identical to count(B->A,r).

count(A->B,f) 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).

Brownlee, et. al.             Experimental                     [Page 19]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 19] RFC 2063 Traffic Flow Measurement: Architecture January 1997

                    Ignore
    --- match(S->D) -------------------------------------------------+
         | Suc   | Fail                                              |
         |       |          Ignore                                   |
         |      match(D->S) -----------------------------------------+
         |       | Suc   | Fail                                      |
         |       |       |                                           |
         |       |       +-------------------------------------------+
         |       |                                                   |
         |       |             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) --------------+
                                                                     |
                                                                     *

Ignore --- match(S->D) -------------------------------------------------+ | Suc | Fail | | | Ignore | | match(D->S) -----------------------------------------+ | | Suc | Fail | | | | | | | +-------------------------------------------+ | | | | | 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) --------------+ | *

   When writing rule sets one must remember that the meter will normally
   try to match each packet in both directions.  It is particularly
   important that the rule set does not contain inconsistencies which
   will upset this process.

When writing rule sets one must remember that the meter will normally try to match each packet in both directions. It is particularly important that the rule set does not contain inconsistencies which will upset this process.

   Consider, for example, a rule set which counts packets from source
   network A to destination network B, but which ignores packets from
   source network B. This is an obvious example of an inconsistent rule
   set, since packets from network B should be counted as reverse
   packets for the A-to-B flow.

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.

   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.  Another approach would be to write a
   'rule set consistency checker' program, which could detect problems
   in hand-written rule sets.

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. Another approach would be to write a 'rule set consistency checker' program, which could detect problems in hand-written rule sets.

   In the short term the best way to avoid these problems is to write
   rule sets which only clasify flows in the forward direction, and rely
   on the meter to handle reverse-travelling packets.

これらの問題を避ける短期で最も良い方法は、順方向にclasifyされるだけである規則セットに流れを書いて、逆旅行しているパケットを扱うためにメーターを当てにすることです。

Brownlee, et. al.             Experimental                     [Page 20]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[20ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

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.  One member of this array is the
   CURRENT RULE SET, in that it is the one which is currently being used
   by the meter to classify incoming packets.

規則セットは規則の勢ぞろいです。 規則セットは規則セットの配列におけるエントリーとしての1メーター以内で持たれています。 この配列の1人のメンバーがCURRENT RULE SETです、それが現在メーターによって使用されている、入って来るパケットを分類するものであるので。

   Rule set 1 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をメーターに造って、変えることができません。 メーターが立ち上げられていて、非常に粗い報告粒状を提供するとき、それは実行されます。 '役に立つ'規則セットをそれにダウンロードする前にメーターが動いていることを確かめることのそれは主に役に立ちます。

   If the meter is instructed to use rule set 0, it will cease
   measuring; all packets will be ignored until another (non-zero) rule
   set is made current.

メーターが規則セット0を使用するよう命令されると、測定するのをやめるでしょう。 すべてのパケットが別の(非ゼロ)規則セットを現在にするまで無視されるでしょう。

   Each rule in a rule set is structured as follows:

規則セットにおける各規則は以下の通り構造化されます:

   +-------- test ---------+    +---- action -----+
   attribute & mask = value:    opcode,  parameter;

+-------- テスト---------+ +---- 動作-----+ 属性とマスク=価値: opcode、パラメタ。

   Opcodes contain two flags:  'goto' and 'test.'  The PME maintains a
   Boolean indicator called the 'test indicator,' which is initially set
   (on).  Execution begins with rule 1, the first in the rule set.  It
   proceeds as follows:

Opcodesは2個の旗を含んでいます: 'goto'と'テスト'PMEは初めは設定された(on)である'テストインジケータ'と呼ばれるブールインディケータを維持します。 実行は規則1、規則セットにおける1番目で始まります。 それは以下の通り続きます:

   If the test indicator is on:
      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 failure.

テストインジケータがオンであるなら: テスト、すなわち、属性がマスクで評価するANDを実行してください、そして、値とそれを比べてください。 これらが等しいなら、テストは成功しました。 規則の動作(below)を実行してください。 テストが失敗するなら、規則セットで次の規則を実行してください。 規則セットにそれ以上の規則が全くなければ、失敗を示すマッチ()機能から、戻ってください。

   If the test indicator is off, or the test (above) succeeded:
      Set the test indicator to this rule'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, Fail, Count,
            CountPkt).
      Perform the action.

テストインジケータがオフであるか、またはテスト(above)が成功したなら: この規則のテスト旗の価値にテストインジケータを設定してください。 次の規則が実行することを決定します。 opcodeがgoto旗を設定させるなら、パラメタ値は次の規則の数を指定します。 それらのgoto旗を設定させないOpcodesが特別な方法で次の規則を決定するか(戻ってください)、または実行を終える、(無視、Fail、Count、CountPkt) 動作を実行してください。

Brownlee, et. al.             Experimental                     [Page 21]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[21ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   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.  The second, 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 and
   mask information from the pattern stack in the order it was enqueued.

PMEは2つの'歴史'データ構造を維持します。 それが実行されるとき、1('リターン'スタック)番目は単に、それぞれのGosub規則のインデックス(すなわち、1元の規則番号)を記録します。 リターン規則はそれらのGosub規則インデックスを飛び出させます。 2番目('パターン'待ち行列)は、流れキーを組立てることにおける後の使用のための情報を保存するのに使用されます。 流れキーはすべての属性値のゼロを合わせることによって、組立てられます、属性とマスク情報がそしてそれが待ち行列に入れられたオーダーにおけるパターンスタックを回避して。

   The opcodes are:

opcodesは以下の通りです。

         opcode         goto    test

opcode gotoテスト

      1  Ignore           0       -
      2  Fail             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

1 0を無視してください--2はGosub1 1 7GosubAct1 0 8が1 1 9AssignAct1 0 10ゴトー1 1 11GotoAct1 0 12PushRuleTo1 1 13PushRuleToAct1 0 14PushPktTo1 1 15PushPktToAct1 0を割り当てる0--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.

無視します: 合っているのを止めてください、そして、マッチから戻ってください。() パケットが無視されることになっているのを示す機能。

   Fail:           Stop matching, return from the match() function
                   indicating failure.

失敗します: 合っているのを止めてください、そして、マッチから戻ってください。() 失敗を示す機能。

   Count:          Stop matching.  Save this rule's attribute name,
                   mask and value in the PME's pattern queue, then
                   construct a flow key for the flow to which this
                   this packet belongs.  Return from the match()
                   function indicating success.  The meter will use
                   the flow key to locate the flow record for this
                   packet's flow.

以下を数えてください。 合っているのを止めてください。 流れに、主要な流れをこの規則の属性名を保存して、マスクをかけて、PMEのパターン待ち行列で評価して、次に、構成する、どれ、これ、このパケットは属するか。 マッチから、戻ってください。() 成功を示す機能。 メーターはこのパケットの流れに流れ記録の場所を見つけるように主要な流れを使用するでしょう。

   CountPkt:       As for Count, except that the masked value from
                   the packet is saved in the PME's pattern queue
                   instead of the rule's value.

CountPkt: Countに関して、パケットからの仮面の値がPMEのパターンで節約されるのを除いて、規則の値の代わりに、列を作ってください。

Brownlee, et. al.             Experimental                     [Page 22]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[22ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   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
                   value specified in 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 name, 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.             Experimental                     [Page 23]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[23ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   PushPktTo:      Save this rule's attribute name, mask, together
                   with the masked value from the packet, in the
                   PME's pattern queue.  SET the test indicator then
                   goto the specified rule.

PushPktTo: パケットからPMEのパターン待ち行列でこの規則の属性名、仮面の値に伴うマスクを取っておいてください。 SET、そして、テストインジケータは指定された規則を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 using a specified mask.  The test in
                   PushPktTo rules will almost never be executed.

PushPktTo動作は、パケットから指定されたマスクを使用することで値を節約するのに使用されるかもしれません。 PushPktTo規則に基づくテストはほとんど実行されないでしょう。

   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属性に実行されたテストはいつも成功します。

   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 name 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は'メーター変数'です。Theyは規則に合うサブルーチンにパラメタを通過する方法を提供します。 それぞれが正常な属性の名前を保持するかもしれません。 値はAssign動作で設定されます。 メーター変数が規則の属性として現れると、値は、テストされるために実際の属性を指定します。 例えば、SourcePeerAddressが値としてv1に割り当てられたなら、属性としてのv1がある規則は実際にSourcePeerAddressをテストするでしょう。

   SourceClass, DestClass, FlowClass,
   SourceKind, DestKind, FlowKind:
               These six attributes may be set by executing PushRuleto
               actions.  They allow the PME to save (in flow records)
               information which has been built up during matching.
               Since their values are only defined when matching is
               complete (and the flow key is built) their values may
               not be tested in rules.

SourceClass、DestClass、FlowClass、SourceKind、DestKind、FlowKind: これらの6つの属性が、PushRuleto動作を実行することによって、設定されるかもしれません。 彼らはPMEにマッチングの間に確立されている情報を保存させます(流れ記録で)。 それらの値が定義されるだけであるので、マッチングが完全であるときに(流れキーは組立しています)、それらの値は規則でテストされないかもしれません。

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 seen for a flow which is not in the current
   flow set a flow record is set up 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 a 'inactive' record - there is no

現在の流れにはない流れが流れ記録を設定したので、パケットが見られる各回はそれに設定されます。 そのような記録の状態は'現在です'。新しい流れのためのメーターが'不活発な'記録のためにそこをフロー・テーブルを捜すという記録を選択するWhenはそうではありません。

Brownlee, et. al.             Experimental                     [Page 24]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[24ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   particular significance in the ordering of records within the table.

テーブルの中の記録の注文における特定の意味。

   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 a LastCollectTime variable which remembers the time the
   last collection was made.  A second variable, InactivityTime,
   specifies the minimum time the meter will wait before considering
   that a flow is idle.

メーターは収集の情報を保って、特に、それは最後の収集をしたとき覚えていられるLastCollectTime変数を維持します。 2番目の変数(InactivityTime)はメーターが流れが活動していないと考える前に待っている最小の時代に指定します。

   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.  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.  This would be suitable for use
   when one was interested in measuring flow lifetimes.

1つの可能な回復戦略はそれらのデータを集めてある後にできるだけ早く無駄な流れ記録を回復することです。 これがメーターであると実装するのが'最後のパケット'時間が計器LastCollectTimeより初期である'現在'の流れを探しながらフロー・テーブルをスキャンするバックグラウンドで実行中のプロセスを実行するかもしれません。 1つが関心があるので、測定では、寿命が流れているということであったときに、これは使用に適しているでしょう。

   Another recovery strategy is to leave idle flows alone as long as
   possible, which would be suitable 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 out of
   '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, network Operations
   personnel should be able to specify the minimum number of meters - or
   perhaps a specific list of meters - which should collect a flow's
   data before its memory can be recovered.  This issue will be further
   developed in the future.

流れを回復するのがメーター読者について数になる流れのデータを集めた前にさらなる1メーターあたり1つの要素が考えるべきです。 働いている複数のメーター読者がいれば、ネットワークOperations人員はメモリを回復できる前に流れのデータを集めるはずであるメーター(恐らくメーターの特定のリスト)の最小の数を指定できるべきです。 この問題は将来、さらに開発されるでしょう。

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 memory usage rises above the high-water mark the meter should
   switch to a STANDBY RULE SET so as to increase the granularity of

メーターが粒状を増強するためにa STANDBY RULE SETに切り換えるはずである最高水位線を超えて用法が上昇するメモリです。

Brownlee, et. al.             Experimental                     [Page 25]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[25ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   flow collection and decrease the rate at which new flows are created.
   When the manager, usually as part of a regular poll, becomes aware
   that the meter is using its standby rule set, it could decrease the
   interval between collections.  The meter should also increase its
   efforts to recover flow memory so as to reduce the number of idle
   flows in memory.  When the situation returns to normal, the manager
   may request the meter to switch back to its normal rule set.

そして、流れ集める、新しい流れが引き起こされるレートを減少させてください。 マネージャが通常定期的な投票の一部としてメーターが予備規則セットを使用しているのを意識するようになると、それは収集の間隔を減少させるかもしれません。 また、メーターは、メモリにおける活動していない流れの数を減少させるために流れメモリを回復するためにさらに努力するはずです。 状況が標準に戻るとき、マネージャは、正常な規則セットに元に戻るようメーターに要求するかもしれません。

5 Meter Readers

5メーターの読者

   Usage data is accumulated by a meter (e.g.  in a router) as memory
   permits.  It is collected at regular reporting intervals by meter
   readers, as specified by a manager.  The collected data is recorded
   in a disk file called a FLOW DATA FILE, as a sequence of USAGE
   RECORDS.

メモリが可能にするとき、1メーター(例えば、ルータにおける)によって用法データは蓄積されます。 マネージャによって指定されるようにそれはメーター読者によって一定の報告間隔で、集められます。 集まっているデータはUSAGE RECORDSの系列としてFLOW DATA FILEと呼ばれるディスクファイルに記録されます。

   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 id and 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値を運ぶかもしれません、収集のための評価基準としての後工程かメーター読者とメーターの間で結果として起こる用法記録を使用できるように。

Brownlee, et. al.             Experimental                     [Page 26]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[26ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

5.2 Usage Records, Flow Data Files

5.2 用法記録、フロー・データファイル

   The collected usage data will be stored in flow data files on the
   meter reader, one file for each meter.  As well as containing the
   measured usage data, flow data files must contain information
   uniquely identifiying the meter from which it was collected.

集まっている用法データはメーター読者のフロー・データファイル、各メーター単位の1個のファイルに保存されるでしょう。 測定用法データを含むことと同様に、流れデータファイルは唯一、それが集められたメーターをidentifiyingする情報を含まなければなりません。

   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.  Each usage record contains the entity
   identifier of the meter (a network address), 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.

USAGE RECORDが1のための記述と値を含んでいるか、または以上は流れます。 量は1流れあたりのパケットの数とバイト数で数えられます。 それぞれの用法記録はメーターに関するエンティティ識別名(ネットワーク・アドレス)、タイムスタンプ、および報告された流れのリスト(FLOW DATA RECORDS)を含んでいます。 メーター読者は1メーターからフロー・データを定期的に集めることによって、用法記録のファイルを確立するでしょう、用法記録を築き上げるのにこのデータを使用して、ファイルのテールにそれらを連結して。 そのようなファイルはFLOW DATA FILEと呼ばれます。

   A usage record contains the following information in some form:

用法記録は何らかのフォームに以下の情報を含んでいます:

   +-------------------------------------------------------------------+
   |    RECORD IDENTIFIERS:                                            |
   |      Meter Id (& digital signature if required)                   |
   |      Timestamp                                                    |
   |      Collection Rules ID                                          |
   +-------------------------------------------------------------------+
   |    FLOW IDENTIFIERS:            |    COUNTERS                     |
   |      Address List               |       Packet Count              |
   |      Subscriber ID (Optional)   |       Byte Count                |
   |      Attributes (Optional)      |    Flow Start/Stop Time         |
   +-------------------------------------------------------------------+

+-------------------------------------------------------------------+ | 識別子を記録してください: | | Idを計量してください、(デジタル署名、必要なら)| | タイムスタンプ| | 収集はIDを統治します。| +-------------------------------------------------------------------+ | 流れ識別子: | カウンタ| | 住所録| パケットカウント| | 加入者ID(任意の)| バイト・カウント| | 属性(任意の)| 流れ始め/停止時間| +-------------------------------------------------------------------+

5.3 Meter to Meter Reader:  Usage Record Transmission

5.3 計量して、読者を計量してください: 用法レコード転送

   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 flows).  One possible method
   of achieving this transfer is to use SNMP; the 'Traffic Flow
   Measurement:  Meter MIB' document [4] gives details.  Note that this
   is simply one example; the transfer of flow data from meter to meter
   reader is not specified in this document.

フロー・データは、それらの間の一連のプロトコル交換で読者を計量するので、メーターから動かされます。 これがいろいろ行われるかもしれません、個々の属性値、完全な流れ、または全体のフロー・テーブル(すなわち、すべてのアクティブな流れ)を動かして。 この転送を達成する1つの可能なメソッドはSNMPを使用することです。 'トラフィック流量測定:' 'メーターMIB'というドキュメント[4]は詳細を述べます。 これが単に1つの例であることに注意してください。 読者を計量するメーターからのフロー・データの転送は本書では指定されません。

Brownlee, et. al.             Experimental                     [Page 27]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[27ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   The reliability of the data transfer method under light, normal, and
   extreme network loads should be understood before selecting among
   collection methods.

軽くて、正常で、極端なネットワーク負荷の下におけるデータ転送方式の信頼性は収集方法の中の選択の前に理解されるべきです。

   In normal operation the meter will be running a rule file which
   provides the required degree of flow reporting granularity, and the
   meter reader(s) will collect the flow data often enough to allow the
   meter's garbage collection mechanism to maintain a stable level of
   memory usage.

通常の操作では、メーターは粒状を報告する必要な度合いの流れを供給する規則ファイルを動かすでしょう、そして、メーター読者は計器ガーベージコレクションメカニズムが安定したレベルのメモリ使用量を維持するのを許容できるくらいのしばしばフロー・データを集めるでしょう。

   In the worst case traffic may increase to the point where the meter
   is in danger of running completely out of flow memory.  The meter
   implementor must decide how to handle this, for example by switching
   to a default (extremely coarse granularity) rule set, by sending a
   trap 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.

そして、Traffic Flow Measurementシステムのユーザが慎重に彼らの要件を分析するべきである、自分たちのために、正常な粒状(交通量について行くために必要に応じて収集頻度を増強する)でフロー・データを集めるか、または、より粗い粒状でフロー・データを受け入れるのを試みるのが、より重要であるか否かに関係なく、評価します。 同様に、メーターが保たれるのを確信していることのお返しに適切にすなわち、動くのが上昇しているトラフィックレベルによって圧倒されない短い間フロー・データを失うのは許容できるかもしれません。

6 Managers

6人のマネージャ

   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 マネージャとメーターの間で: コントロール機能

  - 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; the others 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.

- 規則セットをダウンロードしてください: 1メーターは規則セットの配列を保持するかもしれません。 これらの1つ('デフォルト'規則セット)をメーターに建てて、変えることができません。 マネージャは他のものをダウンロードしなければなりません。 マネージャは、これ、例えば、FTPファイル転送または一連のSNMP SETs(規則セットの各行あたり1つ)を達成するのにどんな適当なプロトコル交換も使用するかもしれません。

  - SWITCH TO SPECIFIED RULE SET: Once the rule sets have been
    downloaded, the manager must instruct the meter which rule set it
    is to actually run (i.e.  which is to be the current rule set), and
    which is to be the standby rule set.

- 指定された規則セットに切り替わってください: いったん規則セットをダウンロードすると、マネージャは、それが実際にどの規則セットを経営していることになっているようメーターに命令しなければなりません、そして、(すなわち、どれによる現在の規則であるかはセットしました)どれによる予備規則であることになっているかはセットしました。

  - SET HIGH WATER MARK: A percentage value interpreted by the meter
    which tells the meter when to switch to its standby rule set, so as
    to increase the granularity of the flows and conserve the meter's

- 最高水位線を設定してください: いつ予備規則に切り替わるかをメーターに言うメーターによって解釈された割合値はセットしました、流れの粒状を増強して、計器を保存するために

Brownlee, et. al.             Experimental                     [Page 28]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[28ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

    flow memory.  Once this has happened, the manager may also change
    the polling frequency or the meter's control parameters (so as to
    increase the rate at which the meter can recover memory from idle
    flows).

流れメモリ。 一度、これは起こったことがあります、また、マネージャが世論調査頻度か計器管理パラメータを変えるかもしれません(メーターが活動していない流れからメモリを取り戻すことができるレートを増強するために)。

    If the high traffic levels persist, the meter's normal rule set may
    have to be rewritten to permanently reduce the reporting
    granularity.

高いトラフィックレベルが持続しているなら、正常な規則が設定した計器は、永久に報告粒状を減少させるために書き直されなければならないかもしれません。

  - SET FLOW TERMINATION PARAMETERS: The meter should have the good
    sense in situations where lack of resources may cause data loss to
    purge flow records from its tables.  Such records may include:

- 流れ終了パラメタを設定してください: メーターには、データの損失が財源不足で流れ記録からテーブルから追放するかもしれない状況における良識があるはずです。 そのような記録は以下を含むかもしれません。

      -  Flows that have already been reported to at least one meter
         reader, and show no activity since the last report,

- 既に少なくとも1つに報告された流れは、読者を計量して、最後のレポート以来の活動を全く示していません。

      -  Oldest flows, or

- または最も古い流れ。

      -  Flows with the smallest number of unreported 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.

- 不活発タイムアウトを設定してください: 最後のパケットが流れに関して見られて以来、これは秒の時間です。 流れ記録を、それらが少なくともこの時間に活動していないなら取り戻されるかもしれなくて、現在の収集評価基準に従って、集めてあります。

6.2 Between Manager and Meter Reader:  Control Functions

6.2 マネージャとメーター読者の間で: コントロール機能

   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 reporting
   interval must be decreased or a coarser granularity of aggregation
   must be used so that more data fits into less space.

トラフィック流量測定を適切に機能させるように設定しなければならない多くのパラメタがあって、実行可能な設定がネットワークトラフィックの特性の結果、変化するかもしれないので、静的なメーター構成と対照的にダイナミックなネットワークマネージメントを持っているのは望ましいです。 メーターでの記憶が疲れ果てるならこれらの操作の多くがスペース見返りと関係がなければならないか、報告間隔が減少しなければならないか、または集合の、より粗い粒状を使用しなければならないので、より多くのデータが、より少ないスペースに収まります。

   Increasing the reporting interval effectively stores data in the
   meter; usage data in transit is limited by the effective bandwidth of
   the virtual link between the meter and the meter reader, and since
   these limited network resources are usually also used to carry user
   data (the purpose of the network), the level of traffic flow
   measurement traffic should be kept to an affordable fraction of the
   bandwidth.  ("Affordable" is a policy decision made by the network
   Operations personnel).  At any rate, it must be understood that the
   operations below do not represent the setting of independent
   variables; on the contrary, each of the values set has a direct and
   measurable effect on the behaviour of the other variables.

有効に報告間隔を増強すると、メーターのデータは保存されます。 トランジットにおける用法データはメーターとメーター読者との仮想のリンクの有効な帯域幅によって制限されます、そして、また、これらの限られたネットワーク資源が利用者データ(ネットワークの目的)を運ぶのに通常使用されるので、交通の流れ測定トラフィックのレベルは帯域幅の手頃な部分に保たれるべきです。 (「手頃」であることは、ネットワークOperations人員によってされた政策決定です。) いずれにせよ、以下での操作が自変数の設定を表さないのを理解しなければなりません。 これに反して、それぞれの値のセットは他の変数のふるまいにダイレクトで測定できる影響を与えます。

Brownlee, et. al.             Experimental                     [Page 29]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

etブラウンリー、アル。 実験的な[29ページ]RFC2063トラフィック流量測定: アーキテクチャ1997年1月

   Network management operations follow:

ネットワークマネージメント操作は続きます:

  - MANAGER and METER READER IDENTIFICATION: The manager should ensure
    that meters report to the correct set of collection stations, and
    take steps to prevent unauthorised access to usage information.
    The collection stations so identified should be prepared to poll if
    necessary and accept data from the appropriate meters.  Alternate
    collection stations may be identified in case both the primary
    manager and the primary collection station 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 must
    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).

- 間隔コントロールを報告します: 普通の報告間隔が正常なトラフィック・パターンに対処するのが選択されるべきです。 しかしながら、メモリがトラフィックスパイクの間、1メーターで正しく設定された報告間隔があってもくたくたになるのは、可能であるかもしれません。 メーターが、それにはメモリ('最高水位'状態を宣言するのによる)を消耗させるという危険があるとマネージャに言って、マネージャが仲裁する(自然の成り行きに任せて、ポーリングインタバルを減少させるか、または次回より早く助けを求めるようにメーターに言うことによって)ように、何らかのメカニズムが利用可能でなければなりません。

  - 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 flow-id granularities for each interface, and

- そしてそれぞれのためのコントロール流れイド粒状が連結する。

      -  Determines the number of buckets into which user traffic will
         be lumped together.

- ユーザトラフィックが一括されるバケツの数を測定します。

    Since granularity is controlled by the meter's current rule set,
    the manager can only change it by requesting the meter to switch to
    a different rule set.  The new rule set could be downloaded when
    required, or it could have been downloaded as part of the meter's
    initial configuration.

粒状が現在の規則が設定した計器によって制御されるので、異なった規則セットに切り替わるようメーターに要求することによって、マネージャはそれを変えることができるだけです。 必要であると、新しい規則セットをダウンロードしたかもしれませんか、または計器の初期の構成の一部としてそれをダウンロードしたかもしれません。

  - FLOW LIFETIME CONTROL: Flow termination parameters include timeout
    parameters for obsoleting inactive flows and removing them from
    tables and maximum flow lifetimes.  This is intertwined with
    reporting interval and granularity, and must be set in accordance
    with the other parameters.

- 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.

Brownlee, et. al.             Experimental                     [Page 30]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 30] RFC 2063 Traffic Flow Measurement: Architecture January 1997

6.3 Exception Conditions

6.3 Exception Conditions

   Exception conditions must be handled, particularly occasions when the
   meter runs out of buffer space.  Since, to prevent counting any
   packet twice, packets can only be counted in a single flow at any
   given time, 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 buffer space. Since, to prevent counting any packet twice, packets can only be counted in a single flow at any given time, 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
    crashes, etc.)  the meter could send a trap to the manager.  The
    manager could then request one or more meter readers to pick up the
    usage record from the meter.

- METER OUTAGES: In case of impending meter outages (controlled crashes, etc.) the meter could send a trap to the manager. The manager could then request one or more meter readers to pick up the usage record 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,

- The reporting interval is too infrequent,

      -  The reporting granularity is too fine, or

- The reporting granularity is too fine, or

      -  The throughput/bandwidth of circuits carrying the usage
         data is too low.

- The throughput/bandwidth of circuits carrying the usage data is too low.

    The manager may change any of these parameters in response to the
    meter (or meter reader's) plea for help.

The manager may change any of these parameters in response to the meter (or meter reader's) plea for help.

Brownlee, et. al.             Experimental                     [Page 31]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 31] RFC 2063 Traffic Flow Measurement: Architecture January 1997

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.

Brownlee, et. al.             Experimental                     [Page 32]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 32] RFC 2063 Traffic Flow Measurement: Architecture January 1997

7 APPENDICES

7 APPENDICES

7.1 Appendix A: Network Characterisation

7.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

International | Backbones/National --------------- / \ Regional/MidLevel ---------- ---------- / \ \ / / \ Stub/Enterprise --- --- --- ---- ---- ||| ||| ||| |||| |||| End-Systems/Hosts xxx xxx xxx xxxx xxxx

   Note that mesh architectures can also be built out of these
   components, and that these are merely descriptive terms.  The nature
   of a single network may encompass any or all of the descriptions
   below, although some networks can be clearly identified as a single
   type.

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 networks are typically bulk carriers that connect other networks. Individual hosts (with the exception of network management devices and backbone service hosts) typically are not directly connected to backbones.

   REGIONAL networks are closely related to backbones, and differ only
   in size, the number of networks connected via each port, and
   geographical coverage.  Regionals may have directly connected hosts,
   acting as hybrid backbone/stub networks.  A regional network is a
   SUBSCRIBER to the backbone.

REGIONAL networks are closely related to backbones, and differ only in size, the number of networks connected via each port, and geographical coverage. Regionals may have directly connected hosts, acting as hybrid backbone/stub networks. A regional network is a SUBSCRIBER to the backbone.

   STUB/ENTERPRISE networks connect hosts and local area networks.
   STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone
   networks.

STUB/ENTERPRISE networks connect hosts and local area networks. STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone networks.

   END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above
   networks.

END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above networks.

   Providing a uniform identification of the SUBSCRIBER in finer
   granularity than that of end-system, (e.g.  user/account), is beyond
   the scope of the current architecture, although an optional attribute

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

Brownlee, et. al.             Experimental                     [Page 33]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 33] RFC 2063 Traffic Flow Measurement: Architecture January 1997

   in the traffic flow measurement record may carry system-specific
   "accountable (billable) party" labels so that meters can implement
   proprietary or non-standard schemes for the attribution of network
   traffic to responsible parties.

in the traffic flow measurement record may carry system-specific "accountable (billable) party" labels so that meters can implement proprietary or non-standard schemes for the attribution of network traffic to responsible parties.

7.2 Appendix B: Recommended Traffic Flow Measurement Capabilities

7.2 Appendix B: Recommended Traffic Flow Measurement Capabilities

   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.

Initial recommended traffic flow measurement conventions are outlined here according to the following Internet building blocks. It is important to understand what complexity reporting introduces at each network level. Whereas the hierarchy is described top-down in the previous section, reporting requirements are more easily addressed bottom-up.

        End-Systems
        Stub Networks
        Enterprise Networks
        Regional Networks
        Backbone Networks

End-Systems Stub Networks Enterprise Networks Regional Networks Backbone Networks

   END-SYSTEMS are currently responsible for allocating network usage to
   end-users, if this capability is desired.  From the Internet Protocol
   perspective, end-systems are the finest granularity that can be
   identified without protocol modifications.  Even if a meter violated
   protocol boundaries and tracked higher-level protocols, not all
   packets could be correctly allocated by user, and the definition of
   user itself varies too widely from operating system to operating
   system (e.g.  how to trace network usage back to users from shared
   processes).

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 too widely from operating system to operating system (e.g. how to trace network usage back to users from shared processes).

   STUB and ENTERPRISE networks will usually collect traffic data either
   by end- system network address or network address pair if detailed
   reporting is required in the local area network.  If no local
   reporting is required, they may record usage information in the exit
   router to track external traffic only.  (These are the only networks
   which routinely use attributes to perform reporting at granularities
   finer than end-system or intermediate-system network address.)

STUB 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.)

   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 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.

Brownlee, et. al.             Experimental                     [Page 34]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 34] RFC 2063 Traffic Flow Measurement: Architecture January 1997

   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.

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 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.

7.3 Appendix C: List of Defined Flow Attributes

7.3 Appendix C: List of Defined Flow Attributes

   This Appendix provides a checklist of the attributes defined to date;
   others will be added later as the Traffic Measurement Architecture is
   further developed.

This Appendix provides a checklist of the attributes defined to date; others will be added later as the Traffic Measurement Architecture is further developed.

   0  Null
   1  Flow Subscript                Integer    Flow table info
   2  Flow Status                   Integer

0 Null 1 Flow Subscript Integer Flow table info 2 Flow Status Integer

   4  Source Interface              Integer    Source Address
   5  Source Adjacent Type          Integer
   6  Source Adjacent Address       String
   7  Source Adjacent Mask          String
   8  Source Peer Type              Integer
   9  Source Peer Address           String
  10  Source Peer Mask              String
  11  Source Trans Type             Integer
  12  Source Trans Address          String
  13  Source Trans Mask             String

4 Source Interface Integer Source Address 5 Source Adjacent Type Integer 6 Source Adjacent Address String 7 Source Adjacent Mask String 8 Source Peer Type Integer 9 Source Peer Address String 10 Source Peer Mask String 11 Source Trans Type Integer 12 Source Trans Address String 13 Source Trans Mask String

  14  Destination Interface         Integer    Destination Address
  15  Destination Adjacent Type     Integer
  16  Destination Adjacent Address  String
  17  Destination AdjacentMask      String
  18  Destination PeerType          Integer
  19  Destination PeerAddress       String
  20  Destination PeerMask          String
  21  Destination TransType         Integer
  22  Destination TransAddress      String
  23  Destination TransMask         String

14 Destination Interface Integer Destination Address 15 Destination Adjacent Type Integer 16 Destination Adjacent Address String 17 Destination AdjacentMask String 18 Destination PeerType Integer 19 Destination PeerAddress String 20 Destination PeerMask String 21 Destination TransType Integer 22 Destination TransAddress String 23 Destination TransMask String

  24  Packet Scale Factor           Integer    'Other' attributes
  25  Byte Scale Factor             Integer
  26  Rule Set Number               Integer
  27  Forward Bytes                 Counter    Source-to-Dest counters
  28  Forward Packets               Counter

24 Packet Scale Factor Integer 'Other' attributes 25 Byte Scale Factor Integer 26 Rule Set Number Integer 27 Forward Bytes Counter Source-to-Dest counters 28 Forward Packets Counter

Brownlee, et. al.             Experimental                     [Page 35]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 35] RFC 2063 Traffic Flow Measurement: Architecture January 1997

  29  Reverse Bytes                 Counter    Dest-to-Source counters
  30  Reverse Packets               Counter
  31  First Time                    TimeTicks  Activity times
  32  Last Active Time              TimeTicks
  33  Source Subscriber ID          String     Session attributes
  34  Destination Subscriber ID     String
  35  Session ID                    String

29 Reverse Bytes Counter Dest-to-Source counters 30 Reverse Packets Counter 31 First Time TimeTicks Activity times 32 Last Active Time TimeTicks 33 Source Subscriber ID String Session attributes 34 Destination Subscriber ID String 35 Session ID String

  36  Source Class                  Integer    'Computed' attributes
  37  Destination Class             Integer
  38  Flow Class                    Integer
  39  Source Kind                   Integer
  40  Destination Kind              Integer
  41  Flow Kind                     Integer

36 Source Class Integer 'Computed' attributes 37 Destination Class Integer 38 Flow Class Integer 39 Source Kind Integer 40 Destination Kind Integer 41 Flow Kind Integer

  51  V1                            Integer    Meter variables
  52  V2                            Integer
  53  V3                            Integer
  54  V4                            Integer
  55  V5                            Integer

51 V1 Integer Meter variables 52 V2 Integer 53 V3 Integer 54 V4 Integer 55 V5 Integer

7.4 Appendix D: List of Meter Control Variables

7.4 Appendix D: List of Meter Control Variables

      Current Rule Set Number       Integer
      Standby Rule Set Number       Integer
      High Water Mark               Percentage
      Flood Mark                    Percentage
      Inactivity Timeout (seconds)  Integer
      Last Collect Time             TimeTicks

Current Rule Set Number Integer Standby Rule Set Number Integer High Water Mark Percentage Flood Mark Percentage Inactivity Timeout (seconds) Integer Last Collect Time TimeTicks

8 Acknowledgments

8 Acknowledgments

   This document was initially produced under the auspices of the IETF's
   Internet Accounting Working Group with assistance from SNMP, RMON and
   SAAG working groups.  This version documents the implementation work
   done by the Internet Accounting Working Group, and is intended to
   provide a starting point for the Realtime Traffic Flow Measurement
   Working Group.  Particular thanks are due to Stephen Stibler (IBM
   Research) for his patient and careful comments during the preparation
   of this memo.

This document was initially produced under the auspices of the IETF's Internet Accounting Working Group with assistance from SNMP, RMON and SAAG working groups. This version documents the implementation work done by the Internet Accounting Working Group, and is intended to provide a starting point for the Realtime Traffic Flow Measurement Working Group. Particular thanks are due to Stephen Stibler (IBM Research) for his patient and careful comments during the preparation of this memo.

Brownlee, et. al.             Experimental                     [Page 36]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997

Brownlee, et. al. Experimental [Page 36] RFC 2063 Traffic Flow Measurement: Architecture January 1997

9 References

9 References

   [1] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
   Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian
   Technology Corporation, November 1991.

[1] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian Technology Corporation, November 1991.

   [2] International Standards Organisation (ISO), "Management
   Framework," Part 4 of Information Processing Systems Open
   Systems Interconnection Basic Reference Model, ISO 7498-4,
   1994.

[2] International Standards Organisation (ISO), "Management Framework," Part 4 of Information Processing Systems Open Systems Interconnection Basic Reference Model, ISO 7498-4, 1994.

   [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.

[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.

   [4] Brownlee, N., "Traffic Flow Measurement:  Meter MIB",
   RFC 2064, The University of Auckland, January 1997.

[4] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2064, The University of Auckland, January 1997.

10 Security Considerations

10 Security Considerations

   Security issues are not discussed in detail in this document.  The
   meter's management and collection protocols are responsible for
   providing sufficient data integrity and confidentiality.

Security issues are not discussed in detail in this document. The meter's management and collection protocols are responsible for providing sufficient data integrity and confidentiality.

11 Authors' Addresses

11 Authors' Addresses

   Nevil Brownlee
   Information Technology Systems & Services
   The University of Auckland

Nevil Brownlee Information Technology Systems & Services The University of Auckland

   Phone: +64 9 373 7599 x8941
   EMail: n.brownlee @auckland.ac.nz

Phone: +64 9 373 7599 x8941 EMail: n.brownlee @auckland.ac.nz

   Cyndi Mills
   BBN Systems and Technologies

Cyndi Mills BBN Systems and Technologies

   Phone: +1 617 873 4143
   EMail: cmills@bbn.com

Phone: +1 617 873 4143 EMail: cmills@bbn.com

   Greg Ruth
   GTE Laboratories, Inc

Greg Ruth GTE Laboratories, Inc

   Phone: +1 617 466 2448
   EMail: gruth@gte.com

Phone: +1 617 466 2448 EMail: gruth@gte.com

Brownlee, et. al.             Experimental                     [Page 37]

Brownlee, et. al. Experimental [Page 37]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

border-left 左ボーダーのスタイル・太さ・色を指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る