rfc2722.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,433 行 · 第 1/5 页

   way provides an economical and practical way to measure network
   traffic and subdivide it into well-defined groups.

   Usage information which is not derivable from traffic flows may also
   be of interest.  For example, an application may wish to record
   accesses to various different information resources or a host may
   wish to record the username (subscriber id) for a particular network
   session.  Provision is made in the traffic flow architecture to do
   this.  In the future the measurement model may be extended to gather
   such information from applications and hosts so as to provide values
   for higher-layer flow attributes.

   As well as FLOWS and METERS, the traffic flow measurement model
   includes MANAGERS, METER READERS and ANALYSIS APPLICATIONS, which are
   explained in following sections.  The relationships between them are
   shown by the diagram below.  Numbers on the diagram refer to sections
   in this document.

                      MANAGER
                     /       \
                2.3 /         \ 2.4
                   /           \
                  /             \                      ANALYSIS
              METER  <----->  METER READER  <----->   APPLICATION
                       2.2                    2.7


     - MANAGER: A traffic measurement manager is an application which
       configures 'meter' entities and controls 'meter reader' entities.
       It sends configuration commands to the meters, and supervises the
       proper operation of each meter and meter reader.  It may well be
       convenient to combine the functions of meter reader and manager
       within a single network entity.

     - METER: Meters are placed at measurement points determined by
       Network Operations personnel.  Each meter selectively records
       network activity as directed by its configuration settings.  It
       can also aggregate, transform and further process the recorded
       activity before the data is stored.  The processed and stored
       results are called the 'usage data'.

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







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


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

         - FLOW RATE FREQUENCY DISTRIBUTIONS, summarizing flow rates
           over a period of time.

         - USAGE DATA showing the total traffic volumes sent and
           received by particular hosts.

   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

   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.

   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.

2.3  Interaction Between MANAGER and METER

   A manager is responsible for configuring and controlling one or more
   meters.  Each meter's configuration includes information such as:

     - Flow specifications, e.g. which traffic flows are to be measured,
       how they are to be aggregated, and any data the meter is required
       to compute for each flow being measured.

     - Meter control parameters, e.g. the 'inactivity' time for flows
       (if no packets belonging to a flow are seen for this time the
       flow is considered to have ended, i.e. to have become idle).





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


     - Sampling behaviour.  Normally every packet will be observed.  It
       may sometimes be necessary to use sampling techniques so as to
       observe only some of the packets (see following note).

   A note about sampling: Current experience with the measurement
   architecture shows that a carefully-designed and implemented meter
   compresses the data sufficiently well that in normal LANs and WANs of
   today sampling is seldom, if ever, needed.  For this reason sampling
   algorithms are not prescribed by the architecture.  If sampling is
   needed, e.g. for metering a very-high-speed network with fine-grained
   flows, the sampling technique should be carefully chosen so as not to
   bias the results.  For a good introduction to this topic see the IPPM
   Working Group's RFC "Framework for IP Performance Metrics" [IPPM-
   FRM].

   A meter may run several rule sets concurrently on behalf of one or
   more managers, and any manager may download a set of flow
   specifications (i.e. a 'rule set') to a meter.  Control parameters
   which apply to an individual rule set should be set by the manager
   after it downloads that rule set.

   One manager should be designated as the 'master' for a meter.
   Parameters such as sampling behaviour, which affect the overall
   operation of the meter, should only be set by the master manager.

2.4  Interaction Between MANAGER and METER READER

   A manager is responsible for configuring and controlling one or more
   meter readers.  A meter reader may only be controlled by a single
   manager.  A meter reader needs to know at least the following for
   every meter it is collecting usage data from:

     - The meter's unique identity, i.e. its network name or address.

     - How often usage data is to be collected from the meter.

     - Which flow records are to be collected (e.g. all flows, flows for
       a particular rule set, flows which have been active since a given
       time, etc.).

     - Which attribute values are to be collected for the required flow
       records (e.g. all attributes, or a small subset of them)

   Since redundant reporting may be used in order to increase the
   reliability of usage data, exchanges among multiple entities must be
   considered as well.  These are discussed below.





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


2.5  Multiple METERs or METER READERs

                    -- METER READER A --
                   /         |          \
                  /          |           \
          =====METER 1     METER 2=====METER 3    METER 4=====
                              \          |           /
                               \         |          /
                                -- METER READER 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.

   In the diagram above meter 1 is read by meter reader A, and meter 4
   is read by meter reader B. Meters 1 and 4 have no redundancy; if
   either meter fails, usage data for their network segments will be
   lost.

   Meters 2 and 3, however, measure traffic on the same network segment.
   One of them may fail leaving the other collecting the segment's usage
   data.  Meters 2 and 3 are read by meter reader A and by meter reader
   B.  If one meter reader fails, the other will continue collecting
   usage data from both meters.

   The architecture does not require multiple meter readers to be
   synchronized.  In the situation above meter readers A and B could
   both collect usage data at the same intervals, but not necesarily at
   the same times.  Note that because collections are asynchronous it is
   unlikely that usage records from two different meter readers will
   agree exactly.

   If identical usage records were required from a single meter, a
   manager could achieve this using two identical copies of a ruleset in
   that meter.  Let's call them RS1 and RS2, and assume that RS1 is
   running.  When a collection is to be made the manager switches the
   meter from RS1 to RS2, and directs the meter reader(s) to read flow
   data for RS1 from the meter.  For the next collection the manager
   switches back to RS1, and so on.  Note, however, that it is not
   possible to get identical usage records from more than one meter,
   since there is no way for a manager to switch rulesets in more than
   one meter at the same time.

   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



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


   traffic volume was sufficient to 'roll over' counters for some flows
   during the failure; this is addressed in the section on 'Rolling
   Counters'.

2.6  Interaction Between MANAGERs (MANAGER - MANAGER)

   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.

2.7  METER READERs and APPLICATIONs

   Once a collection of usage data has been assembled by a meter reader
   it can be processed by an analysis application.  Details of analysis
   applications - such as the reports they produce and the data they
   require - are outside the scope of this architecture.

   It should be noted, however, that analysis applications will often
   require considerable amounts of input data.  An important part of
   running a traffic flow measurement system is the storage and regular
   reduction of flow data so as to produce daily, weekly or monthly
   summary files for further analysis.  Again, details of such data
   handling are outside the scope of this architecture.

3  Traffic Flows and Reporting Granularity

   A flow was defined in section 2.1 above in abstract terms as follows:

       "A TRAFFIC FLOW is an artifical logical equivalent to a call or
       connection, belonging to a (user-specieied) METERED TRAFFIC
       GROUP."

   In practical terms, a flow is a stream of packets observed by the
   meter as they pass across a network between two end points (or from a
   single end point), which have been summarized by a traffic meter for
   analysis purposes.

3.1  Flows and their 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:




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


     - ADDRESSES for the flow's source and destination.  These comprise
       the protocol type, the source and destination addresses at
       various network layers (extracted from the packet header), and
       the number of the interface on which the packet was observed.

     - First and last TIMES when packets were seen for this flow, i.e.
       the 'creation' and 'last activity' times for the flow.