rfc2722.txt

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

   ADDRESS attributes.  For example, if a flow's address attributes were
   specified as "source address = IP address 10.1.0.1, destination
   address = IP address 26.1.0.1" then only IP packets from 10.1.0.1 to
   26.1.0.1 and back would be counted in that flow.  If a flow's address
   attributes specified only that "source address = IP address
   10.1.0.1," then all IP packets from and to 10.1.0.1 would be counted
   in that flow.

   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 address in the the next layer down
       from the peer address in a particular instantiation of protocol
       layering.  Although 'adjacent' will usually imply the link layer,
       it does not implicitly advocate or dismiss any particular form of
       tunnelling or layering.






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


       For example, if flow measurement is being performed using IP as
       the network layer on an Ethernet LAN [802-3], an adjacent address
       will normally be a six-octet Media Access Control (MAC) address.
       For a host connected to the same LAN segment as the meter the
       adjacent address will be the MAC address of that host.  For hosts
       on other LAN segments it will be the MAC address of the adjacent
       (upstream or downstream) router carrying the traffic flow.

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

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

   Reporting by adjacent intermediate sources and destinations or simply
   by meter interface (most useful when the meter is embedded in a
   router) supports hierarchical Internet reporting schemes as described
   in the 'Internet Accounting Background' RFC [ACT-BKG]. That is, it
   allows backbone and regional networks to measure usage to just the
   next lower level of granularity (i.e. to the regional and
   stub/enterprise levels, respectively), with the final breakdown
   according to end user (e.g. to source IP address) performed by the
   stub/enterprise networks.




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


   In cases where network addresses are dynamically allocated (e.g.
   dial-in subscribers), further subscriber identification will be
   necessary if flows are to ascribed to individual users.  Provision is
   made to further specify the metered traffic group through the use of
   an optional SUBSCRIBER ID as part of the flow id.  A subscriber ID
   may be associated with a particular flow either through the current
   rule set or by unspecified means within a meter.  At this time a
   subscriber ID is an arbitrary text string; later versions of the
   architecture may specify details of its contents.

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 its level of detail.  A coarser granularity means a
   greater level of aggregation; finer granularity means a greater level
   of detail.  Thus, the number of flows measured (and stored) at a
   meter can be regulated by changing the granularity of their
   attributes.  Flows are like an adjustable pipe - many fine-
   granularity streams can carry the data with each stream measured
   individually, or data can be bundled in one coarse-granularity pipe.
   Time granularity may be controlled by varying the reporting interval,
   i.e. the time between meter readings.

   Flow granularity is controlled by adjusting the level of detail for
   the following:

     - The metered traffic group (address attributes, discussed above).

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

     - The lifetime/duration of flows (the reporting interval needs to
       be short enough to measure them with sufficient precision).

   The set of rules controlling the determination of each packet's
   metered traffic group is known as the meter's CURRENT RULE SET.  As
   will be shown, the meter's current rule set forms an integral part of
   the reported information, i.e. the recorded usage information cannot
   be properly interpreted without a definition of the rules used to
   collect that information.

   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




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


   must be identifiable via a RULE SET NUMBER. Granularity of metered
   traffic groups is further specified by additional ATTRIBUTES. These
   attributes include:

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

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

   A rule set can aggregate groups of addresses in two ways.  The
   simplest is to use a mask in a single rule to test for an address
   within a masked group.  The other way is to use a sequence of rules
   to test for an arbitrary group of (masked) address values, then use a
   PushRuleTo rule to set a derived attribute (e.g. FlowKind) to
   indicate the flow's group.

   The LIFETIME of a flow is the time interval which began when the
   meter observed the first packet belonging to the flow and ended when
   it saw the last packet.  Flow lifetimes are very variable, but many -
   if not most - are rather short.  A meter cannot measure lifetimes
   directly; instead a meter reader collects usage data for flows which
   have been active since the last collection, and an analysis
   application may compare the data from each collection so as to
   determine when each flow actually stopped.

   The meter does, however, need to reclaim memory (i.e. records in the
   flow table) being held by idle flows.  The meter configuration
   includes a variable called InactivityTimeout, which specifies the
   minimum time a meter must wait before recovering the flow's record.
   In addition, before recovering a flow record the meter should be sure
   that the flow's data has been collected by all meter readers which
   registered to collect it.  These two wait conditions are desired
   goals for the meter; they are not difficult to achieve in normal
   usage, however the meter cannot guarantee to fulfil them absolutely.





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


   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

   Once a usage record is sent, the decision needs to be made whether to
   clear any existing flow records or to maintain them and add to their
   counts when recording subsequent traffic on the same flow.  The
   second method, called rolling counters, is recommended and has
   several advantages.  Its primary advantage is that it provides
   greater reliability - the system can now often survive the loss of
   some usage records, such as might occur if a meter reader failed and
   later restarted.  The next usage record will very often contain yet
   another reading of many of the same flow buckets which were in the
   lost usage record.  The 'continuity' of data provided by rolling
   counters can also supply information used for "sanity" checks on the
   data itself, to guard against errors in calculations.

   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

                         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

   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
   was then stopped (perhaps because of temporary idleness), but then
   more traffic with the same characteristics arrived so a new flow
   record was started and it quickly reached a count of 1000.  The total
   flow count from both the old and new records is 3000.

   The flow START TIMESTAMP attribute is sufficient to resolve this. In
   the example above, the CONTINUING FLOW flow record in the second
   usage record has an old FLOW START timestamp, while the NEW FLOW
   contains a recent FLOW START timestamp.  A flow which has sporadic
   bursts of activity interspersed with long periods of inactivity will
   produce a sequence of flow activity records, each with the same set
   of address attributes, but with increasing FLOW START times.



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


   Each packet is counted in at most one flow for each running ruleset,
   so as to avoid multiple counting of a single packet.  The record of a
   single flow is informally called a "bucket."  If multiple, sometimes
   overlapping, records of usage information are required (aggregate,
   individual, etc), the network manager should collect the counts in
   sufficiently detailed granularity so that aggregate and combination
   counts can be reconstructed in post-processing of the raw usage data.
   Alternatively, multiple rulesets could be used to collect data at
   different granularities.

   For example, consider a meter from which it is required to record
   both 'total packets coming in interface #1' and 'total packets
   arriving from any interface sourced by IP address = a.b.c.d', using a
   single rule set.  Although a bucket can be declared for each case, it
   is not clear how to handle a packet which satisfies both criteria.
   It must only be counted once.  By default it will be counted in the
   first bucket for which it qualifies, and not in the other bucket.
   Further, it is not possible to reconstruct this information by post-
   processing.  The solution in this case is to define not two, but
   THREE buckets, each one collecting a unique combination of the two
   criteria:

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