rfc2063.txt

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

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

  - 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


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

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


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





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


   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.

   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.

   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.

   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.

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

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.



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


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

   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.

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:

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

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

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

   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.




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


   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.

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

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

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

   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.

   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


   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.

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