rfc2722.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        N. Brownlee
Request for Comments: 2722                    The University of Auckland
Obsoletes: 2063                                                 C. Mills
Category: Informational                            GTE Laboratories, Inc
                                                                 G. Ruth
                                                     GTE Internetworking
                                                            October 1999


                 Traffic Flow Measurement: Architecture

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document provides a general framework for describing network
   traffic flows, presents an architecture for traffic flow measurement
   and reporting, discusses how this relates to an overall network
   traffic flow architecture and indicates how it can be used within the
   Internet.

Table of Contents

   1  Statement of Purpose and Scope                                   3
      1.1  Introduction . . . . . . . . . . . . . . . . . . . . . . .  3

   2  Traffic Flow Measurement Architecture                            5
      2.1  Meters and Traffic Flows . . . . . . . . . . . . . . . . .  5
      2.2  Interaction Between METER and METER READER . . . . . . . .  7
      2.3  Interaction Between MANAGER and METER  . . . . . . . . . .  7
      2.4  Interaction Between MANAGER and METER READER . . . . . . .  8
      2.5  Multiple METERs or METER READERs . . . . . . . . . . . . .  9
      2.6  Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . 10
      2.7  METER READERs and APPLICATIONs . . . . . . . . . . . . . . 10

   3  Traffic Flows and Reporting Granularity                         10
      3.1  Flows and their Attributes . . . . . . . . . . . . . . . . 10
      3.2  Granularity of Flow Measurements . . . . . . . . . . . . . 13
      3.3  Rolling Counters, Timestamps, Report-in-One-Bucket-Only  . 15




Brownlee, et al.             Informational                      [Page 1]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999


   4  Meters                                                          17
      4.1  Meter Structure  . . . . . . . . . . . . . . . . . . . . . 17
      4.2  Flow Table . . . . . . . . . . . . . . . . . . . . . . . . 19
      4.3  Packet Handling, Packet Matching . . . . . . . . . . . . . 20
      4.4  Rules and Rule Sets  . . . . . . . . . . . . . . . . . . . 23
      4.5  Maintaining the Flow Table . . . . . . . . . . . . . . . . 28
      4.6  Handling Increasing Traffic Levels . . . . . . . . . . . . 29

   5  Meter Readers                                                   30
      5.1  Identifying Flows in Flow Records  . . . . . . . . . . . . 30
      5.2  Usage Records, Flow Data Files . . . . . . . . . . . . . . 30
      5.3  Meter to Meter Reader:  Usage Record Transmission  . . . . 31

   6  Managers                                                        32
      6.1  Between Manager and Meter:  Control Functions  . . . . . . 32
      6.2  Between Manager and Meter Reader:  Control Functions . . . 33
      6.3  Exception Conditions . . . . . . . . . . . . . . . . . . . 35
      6.4  Standard Rule Sets . . . . . . . . . . . . . . . . . . . . 36

   7  Security Considerations                                         36
      7.1  Threat Analysis  . . . . . . . . . . . . . . . . . . . . . 36
      7.2  Countermeasures  . . . . . . . . . . . . . . . . . . . . . 37

   8  IANA Considerations                                             39
      8.1  PME Opcodes  . . . . . . . . . . . . . . . . . . . . . . . 39
      8.2  RTFM Attributes  . . . . . . . . . . . . . . . . . . . . . 39

   9  APPENDICES                                                      41
      Appendix A: Network Characterisation  . . . . . . . . . . . . . 41
      Appendix B: Recommended Traffic Flow Measurement Capabilities . 42
      Appendix C: List of Defined Flow Attributes . . . . . . . . . . 43
      Appendix D: List of Meter Control Variables . . . . . . . . . . 44
      Appendix E: Changes Introduced Since RFC 2063 . . . . . . . . . 45

   10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 45
   11 References  . . . . . . . . . . . . . . . . . . . . . . . . . . 46
   12 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . 47
   13 Full Copyright Statement  . . . . . . . . . . . . . . . . . . . 48













Brownlee, et al.             Informational                      [Page 2]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999


1  Statement of Purpose and Scope

1.1  Introduction

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

     - The traffic flow model can be consistently applied to any
       protocol, using address attributes in any combination at the
       'adjacent' (see below), network and transport layers of the
       networking stack.

     - Traffic flow attributes are defined in such a way that they are
       valid for multiple networking protocol stacks, and that traffic
       flow measurement implementations are useful in multi-protocol
       environments.

     - Users may specify their traffic flow measurement requirements by
       writing 'rule sets', allowing them to collect the flow data they
       need while ignoring other traffic.

     - The data reduction effort to produce requested traffic flow
       information is placed as near as possible to the network
       measurement point.  This minimises the volume of data to be
       obtained (and transmitted across the network for storage), and
       reduces the amount of processing required in traffic flow
       analysis applications.

   'Adjacent' (as used above) is a layer-neutral term for the next layer
   down in a particular instantiation of protocol layering. Although
   'adjacent' will usually imply the link layer (MAC addresses), it does
   not implicitly advocate or dismiss any particular form of tunnelling
   or layering.

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

     - Understanding the behaviour of existing networks,

     - Planning for network development and expansion,

     - Quantification of network performance,

     - Verifying the quality of network service, and

     - Attribution of network usage to users.



Brownlee, et al.             Informational                      [Page 3]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999


   The traffic flow measurement architecture is deliberately structured
   using address attributes which are defined in a consistent way at the
   Adjacent, Network and Transport layers of the networking stack,
   allowing specific implementations of the architecture to be used
   effectively in multi-protocol environments.  Within this document the
   term 'usage data' is used as a generic term for the data obtained
   using the traffic flow measurement architecture.

   In principle one might define address attributes for higher layers,
   but it would be very difficult to do this in a general way.  However,
   if an RTFM traffic meter were implemented within an application
   server (where it had direct access to application-specific usage
   information), it would be possible to use the rest of the RTFM
   architecture to collect application-specific information.  Use of the
   same model for both network- and application-level measurement in
   this way could simplify the development of generic analysis
   applications which process and/or correlate both traffic and usage
   information.  Experimental work in this area is described in the RTFM
   'New Attributes' document [RTFM-NEW].

   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.

   Background information explaining why this approach was selected is
   provided by the 'Internet Accounting Background' RFC [ACT-BKG].








Brownlee, et al.             Informational                      [Page 4]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999


2  Traffic Flow Measurement Architecture

   A traffic flow measurement system is used by Network Operations
   personnel to aid in managing and developing a network.  It provides a
   tool for measuring and understanding the network's traffic flows.
   This information is useful for many purposes, as mentioned in section
   1 (above).

   The following sections outline a model for traffic flow measurement,
   which draws from working drafts of the OSI accounting model [OSI-
   ACT].

2.1  Meters and Traffic Flows

   At the heart of the traffic measurement model are network entities
   called traffic METERS.  Meters observe packets as they pass by a
   single point on their way through the network and classify them into
   certain groups.  For each such group a meter will accumulate certain
   attributes, for example the numbers of packets and bytes observed for
   the group.  These METERED TRAFFIC GROUPS may correspond to a user, a
   host system, a network, a group of networks, a particular transport
   address (e.g. an IP port number), any combination of the above, etc,
   depending on the meter's configuration.

   We assume that routers or traffic monitors throughout a network are
   instrumented with meters to measure traffic.  Issues surrounding the
   choice of meter placement are discussed in the 'Internet Accounting
   Background' RFC [ACT-BKG]. An important aspect of meters is that they
   provide a way of succinctly aggregating traffic information.

   For the purpose of traffic flow measurement we define the concept of
   a TRAFFIC FLOW, which is like an artificial logical equivalent to a
   call or connection.  A flow is a portion of traffic, delimited by a
   start and stop time, that belongs to one of the metered traffic
   groups mentioned above.  Attribute values (source/destination
   addresses, packet counts, byte counts, etc.)  associated with a flow
   are aggregate quantities reflecting events which take place in the
   DURATION between the start and stop times.  The start time of a flow
   is fixed for a given flow; the stop time may increase with the age of
   the flow.

   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



Brownlee, et al.             Informational                      [Page 5]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999


   which flow they belong to.  Classifying packets into 'flows' in this
   way provides an economical and practical way to measure network
   traffic and subdivide it into well-defined groups.

   Usage information which is not derivable from traffic flows may also
   be of interest.  For example, an application may wish to record
   accesses to various different information resources or a host may
   wish to record the username (subscriber id) for a particular network
   session.  Provision is made in the traffic flow architecture to do