rfc1272.txt

RFC 的详细文档！

             almost every router is a disincentive for implementing a
             usage-based charging policy.

4.2. Meter Types

   Four possible types of metering technology are:

          o  Network monitors:
             These measure only traffic WITHIN a single network.  They
             include LAN monitors, X.25 call accounting systems and
             traffic monitors in bridges.

          o  Line monitors:
             These count packets flowing across a circuit.  They would
             be placed on inter-router trunks and on router ports.

          o  Router-integral meters:
             These are meters located within a router, implemented in
             software.  They count packets flowing through the router.

          o  Router spiders:
             This is a set of line monitors that surround a router,
             measure traffic on all of its ports and coordinate the
             results.



Mills, Hirsh, & Ruth                                           [Page 10]

RFC 1272            Internet Accounting: Background        November 1991


4.3. Meter Structure

   While topology argues in favor of meters in routers, granularity and
   security favor dedicated monitors.  The GRANULARITY of the
   accountable entity (and its attributes) affects the amount of
   overhead incurred for accounting.  Each entity/attribute/reporting
   interval combination is a separate meter.  Each individual meter
   takes up local memory and requires additional memory or network
   resources when the meter reports to the application.  Memory is a
   limited resource, and there are cost implications to expanding memory
   significantly or increasing the frequency of reporting.  The number
   of concurrent flows open in a router is controlled by

          o  the granularity of the accountable entity

          o  the granularity of the attributes and sub-categories of
             packets

          o  memory
             (the number of flows that can be stored concurrently, a
             limit which can also be expressed as the average number
             of flows existing at this granularity plus some delta,
             e.g., peak hour average plus one standard deviation, or
             ...)

          o  the reporting interval
             (the lifetime of an individual meter)

   There is a spectrum of granularity control which ranges across
   the following dimensions.  (Most administrations will probably
   choose a granularity somewhere in the middle of the spectrum.)

   ENTITY:  Entities range across the spectrum from the coarsest
   granularity, PORT (a local view with a unique designation for the
   subscriber port through which packets enter and exit "my"
   network) through NETWORK and HOST to USER (not defined here).
   The port is the minimum granularity of accounting.  HOST is the
   finest granularity defined here.  Where verification is required,
   a network should be able to perform accounting at the granularity
   its subscribers use.  Hosts are ultimately responsible for
   identifying the end user, since only the hosts have unambiguous
   access to user identification.  This information could be shared
   with the network, but it is the host's responsibility to do so,
   and there is no mechanism in place at this time (e.g., an IP
   option, discussed in section 4.).

   ATTRIBUTE:  Each new attribute requires that an additional flow
   be maintained for each entity.  The coarsest granularity is NO



Mills, Hirsh, & Ruth                                           [Page 11]

RFC 1272            Internet Accounting: Background        November 1991


   categorization of packets.  The finest granularity would be to
   maintain state information about the higher-levels protocols or
   type of service being used by communicating processes across the
   network.

   VALUES:  Values are the information which is recorded for each
   entity/attribute grouping.  Usually values are counters, such as
   packet counts and byte counts.  They may also be time stamps -
   start time and stop time, or reasons for starting or stopping
   reporting.

   REPORTING INTERVAL:  At the very finest level of granularity,
   each data packet might generate a separate accounting record.  To
   report traffic at this level of detail would require
   approximately one packet of accounting information for every data
   packet sent.  The reporting interval is then zero and no memory
   will be needed for flow record storage.  For a non-zero reporting
   interval flow records must be maintained in memory.  Storage for
   stale (old, infrequent) flows may be recycled when their data has
   been reported.  As the reporting interval increases, more and
   more stale records accumulate.

   The feasibility of a particular group of granularities varies
   with the PERFORMANCE characteristics of the network (link speed,
   link bandwidth, router processing speed, router memory), as well
   as the COST of accounting balanced against the requirement for
   DETAIL.  Since technological advances can quickly obsolete
   current technical limitations, and since the policy structure and
   economics of the Internet are in flux, meters will be defined
   with VARYING GRANULARITY which is regulated according to the
   traffic requirements of the individual network or administration
   and technical limitations.

4.4. Collection Issues

   There are two implicit assumptions about the nature of meters and
   traffic sources that they measure, both of which have substantial
   bearing on collectors.

      1.  The matrix of communicating entity pairs is large but
      sparse and, moreover, network traffic exhibits considerable
      source, destination and attribute coherence - so that lists
      can be quite compact.

      2.  Meters can be configured to generate either a static set
      of variables whose values are incremented, or a stream of
      records that must be periodically transferred and removed
      from the meter's memory.



Mills, Hirsh, & Ruth                                           [Page 12]

RFC 1272            Internet Accounting: Background        November 1991


   Meters can generate large, unstructured amounts of information
   and the essential collection issue revolves around mapping
   collection activities into an SNMP framework (or, to the extent
   that this is not successful, specifying other collection
   paradigms).

   There are three major collection concerns:

          o  data confidentiality

          o  data integrity

          o  local and remote collection control

   The prime security concern is preserving the confidentiality of usage
   data.  (See ISO 7498 Part 2, "Security Architecture," for security
   terminology used herein.)  Given that accounting data are sensitive,
   the collector should be able (or may be required) to provide
   confidentiality for accounting data at the point of collection,
   through transmission and up to the point where the data is delivered.
   The delivery function may also require authentication of the origin
   and destination and provision for connection integrity (if
   connections are utilized).  Other security services (e.g., measures
   to counter denial of service attacks) are not deemed necessary for
   internet accounting at this time.  It is assumed that security
   services can be provided by SNMP and its mechanisms.  (This will
   require further investigation.)

   In order to have an accurate monitoring system, reliable delivery of
   data should be assured through one or more of:

          o  an acknowledgement retransmission scheme;

          o  redundant reporting to multiple collectors;

          o  having backup storage located at the meter.

   There is a place for both application polling and meter traps within
   this scheme, but there are significant trade-offs associated with
   each.

   Polling means that the collection point has some control over when
   accounting data is sent, so that not all meters flood the collector
   at once.  However, polling messages, particularly when structured
   with SNMP's GET-NEXT operator, add considerable overhead to the
   network.  Meter traps are required in any case (whether or not
   polling is the preferred collection method), so that a meter may rid
   itself of data when its cache is full.



Mills, Hirsh, & Ruth                                           [Page 13]

RFC 1272            Internet Accounting: Background        November 1991


   The fundamental collection trade-off will be between primary and
   secondary storage at the meter, coupled with an efficient bulk-
   transfer protocol, versus minimal storage at the meter and a
   network-bandwidth-consuming collection discipline.

   A final collection concern is whether packets should be counted on
   entry into a router or upon exit from a router.  It is the nature of
   IP that not every packet received by a router is actually passed to
   an output port.  The Internet Protocol allows routers to discard
   packets (e.g., in times of congestion when the router cannot handle
   the offered load); it is presumed that higher level protocols (e.g.,
   TCP) will provide whatever reliable delivery service the user deems
   necessary (by detecting non- delivery and retransmitting).

   The question arises, therefore, whether an internet accounting system
   should count all packets offered to a router (since each packet
   offered consumes some router resources) or just those that are
   finally passed by the router to a network (why should a user pay for
   undelivered packets?)  Since there are good arguments for either
   position, we do not attempt to resolve this issue here.  (It should
   be noted, however, that SMDS has chosen to count on exit only.)
   Rather, we require that an internet accounting should provide ability
   for counting packets either way -- on entry to or on exit from a
   router.

5.  Examples

   Here follows a series of examples to illustrate what data may be of
   interest to service providers and consumers in a number of different
   scenarios.  In the illustrations that follow straight lines are
   interpreted as some sort of LAN.  Diagonals are point- to-point
   links. Diamonds are routers.  We assume that we are in a homogeneous
   protocol environment (IP).

5.1  A Single Segment LAN

   Consumers and providers on a single LAN service can utilize the same
   set of data:  the contribution of individual hosts to total network
   load.  A network accounting system measures flows between individual
   host pairs. (On a broadcast LAN, e.g., an Ethernet, this can be
   accomplished by a single meter placed anywhere on the LAN.)  Using
   this data, costs for the network management activity can be
   apportioned to individual hosts or the departments that own/manage
   the hosts.

   Alternately, flows can be kept by source only, rather than source-
   destination pairs.




Mills, Hirsh, & Ruth                                           [Page 14]

RFC 1272            Internet Accounting: Background        November 1991


5.2  An Extended (Campus or Facility-Wide) LAN

    128.252.100.X            128.252.150.X            128.253.220.X
  +----------------+       +----------------+      +----------------+
          |                        |                        |
          |                        |                        |
         / \                      / \                      / \
    128.252.100.10           128.252.150.10           128.253.220.10
         \ /                      \ /                      \ /
          |                        |                        |
       +--+-+----------------------+-+----------------------+-+-+