rfc1272.txt

RFC 的详细文档！

   In other cases USAGE-SENSITIVE charges may be preferred or required
   by a local administration's policy.  Government regulations or the
   wishes of subscribers with low or intermittent traffic patterns may
   force the issue (note: FLAT FEES are beneficial for heavy network
   users.  USAGE SENSITVE charges generally benefit the low-volume
   user).  Where usage-sensitive accounting is used, cost ceilings and
   floors may still be established by static parameters, such as "pipe
   size" for fixed connections or "connection time" for dial-up
   connection, to satisfy the need for some predictability.




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


   Different billing schemes may be employed depending on network
   measures of distance.  For example, local network traffic may be
   flat-rate and remote internet traffic may be usage-based, analogous
   to the local and long distance billing policies adopted by the
   telephone companies.

   The ANRG is independently investigating policy models and
   infrastructure economics for billing and cost recovery.

3.3. The Nature of Usage Accounting

   Although the exact requirements for internet usage accounting will
   vary from one network administration to the next and will depend on
   policies and cost trade-offs, it is possible to characterize the
   problem in some broad terms and thereby bound it.  Rather than try to
   solve the problem in exhaustive generality (providing for every
   imaginable set of accounting requirements), some assumptions about
   usage accounting are posited in order to make the problem tractable
   and to render implementations feasible.  Since these assumptions form
   the basis for our architectural and design work, it is important to
   make them explicit from the outset and hold them up to the scrutiny
   of the Internet community.

3.3.1. A Model for Internet Accounting

   We begin with the assumption that there is a "network administrator"
   or "network administration" to whom internet accounting is of
   interest.  He "owns" and operates some subset of the internet (one or
   more connected networks)that may be called his "administrative
   domain".  This administrative domain has well defined boundaries.


                        our domain X
                     -------------------
                    /    |   |   |   |
                   /                 |           C
                  /                ------       /
             Network A            /    | \     /
              -----     (diagonals        \___/____
              | | |      cross admin.      domain B
                         boundaries)


   The network administrator is interested in 1) traffic within his
   boundaries and 2) traffic crossing his boundaries.  Within his
   boundaries he may be interested in end-system to end-system
   accounting or accounting at coarser granularities (e.g., department
   to department).



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


   The network administrator is usually not interested in accounting for
   end-systems outside his administrative domain; his primary concern is
   accounting to the level of other ADJACENT (directly connected)
   administrative domains.  Consider the viewpoint of the administrator
   for domain X of the internet.  The idea is that he will send each
   adjacent administrative domain a bill (or other statement of
   accounting) for its use of his resources and it will send him a bill
   for his use of its resources.  When he receives an aggregate bill
   from Network A, if he wishes to allocate the charges to end users or
   subsystems within his domain, it is HIS responsibility to collect
   accounting data about how they used the resources of Network A.  If
   the "user" is in fact another administrative domain, B, (on whose
   behalf X was using A's resources) the administrator for X just sends
   his counterpart in B a bill for the part of X's bill attributable to
   B's usage.  If B was passing traffic for C, them B bills C for the
   appropriate portion X's charges, and so on, until the charges
   percolate back to the original end user, say G. Thus, the
   administrator for X does not have to account for G's usage; he only
   has to account for the usage of the administrative domains directly
   adjacent to himself.

   This paradigm of recursive accounting may, of course, be used WITHIN
   an administrative domain that is (logically) comprised of sub-
   administrative domains.

   The discussion of the preceding paragraphs applies to a general mesh
   topology, in which any Internet constituent domain may act as a
   service provider for any connected domain.  Although the Internet
   topology is in fact such a mesh, there is a general hierarchy to its
   structure and hierarchical routing (when implemented) will make it
   logically hierarchical as far as traffic flow is concerned.  This
   logical hierarchy permits a simplification of the usage accounting
   perspective.

   At the bottom of the service hierarchy a service-consuming host sits
   on one of many "stub" networks.  These are interconnected into an
   enterprise-wide extended LAN, which in turn receives Internet
   service, typically from a single attachment to a regional backbone.
   Regional backbones receive national transport services from national
   backbones such as NSFnet, Alternet, PSInet, CERFnet, NSInet, or
   Nordunet.  In this scheme each level in the hierarchy has a
   constituency, a group for which usage reporting is germane, in the
   level underneath it.  In the case of the NSFnet the natural
   constituency, for accounting purposes at least, is the regional nets
   (MIDnet, SURAnet,...).  For the regionals it will be their member
   institutions; for the institutions, their stub networks; and for the
   stubs, their individual hosts.




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


3.3.2. Implications of the Model

   The significance of the model sketched above is that Internet
   accounting must be able to support accounting for adjacent
   (intermediate) systems, as well as end-system accounting.  Adjacent
   system accounting information cannot be derived from end-system
   accounting (even if complete end-system accounting were feasible)
   because traffic from an end-system may reach the administrative
   domain of interest through different adjacent domains, and it is the
   adjacent domain through which it passes that is of interest.

   The need to support accounting for adjacent intermediate systems
   means that internet accounting will require information not present
   in internet protocol headers (these headers contain source and
   destination addresses of end-systems only).  This information may
   come from lower layer protocols (network or link layer) or from
   configuration information for boundary components (e.g., "what system
   is connected to port 5 of this IP router").

4. Meters

   A METER is a process which examines a stream of packets on a
   communications medium or between a pair of media.  The meter records
   aggregate counts of packets belonging to FLOWs between communicating
   entities (hosts/processes or aggregations of communicating hosts
   (domains)).  The assignment of packets to flows may be done by
   executing a series of rules.  Meters can reasonably be implemented in
   any of three environments -- dedicated monitors, in routers or in
   general-purpose systems.

   Meter location is a critical decision in internet accounting.  An
   important criterion for selecting meter location is cost, i.e.,
   REDUCING ACCOUNTING OVERHEAD and MINIMIZING THE COST OF
   IMPLEMENTATION.

   In the trade-off between overhead (cost of accounting) and detail,
   ACCURACY and RELIABILITY play a decisive role.  Full accuracy and
   reliability for accounting purposes require that EVERY packet must be
   examined.  However, if the requirement for accuracy and reliability
   is relaxed, statistical sampling may be more practical and
   sufficiently accurate, and DETAILED ACCOUNTING is not required at
   all.  Accuracy and reliability requirements may be less stringent
   when the purpose of usage-reporting is solely to understand network
   behavior, for network design and performance tuning, or when usage
   reporting is used to approximate cost allocations to users as a
   percentage of total fees.

   Overhead costs are minimized by accounting at the coarsest acceptable



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


   GRANULARITY, i.e., using the greatest amount of AGGREGATION possible
   to limit the number of accounting records generated, their size, and
   the frequency with which they are transmitted across the network or
   otherwise stored.

   The other cost factor lies in implementation.  Implementation will
   necessitate the development and introduction of hardware and software
   components into the internet.  It is important to design an
   architecture that tends to minimize the cost of these new components.

4.1. Meter Placement

   In the model developed above, the Internet may be viewed as a
   hierarchical system of service providers and their corresponding
   constituencies.  In this scheme the service provider accounts for the
   activity of the constituents or service consumers.  Meters should be
   placed to allow for optimal data collection for the relevant
   constituency and technology.  Meters are most needed at
   administrative boundaries and data collected such that service
   provider and consumer are able to reconcile their activities.

   Routers (and/or bridges) are by definition and design placed
   (topologically) at these boundaries and so it follows that the most
   generally convenient place to position accounting meters is in or
   near the router.  But again this depends on the underlying transport.
   Whenever the service-providing network is broadcast (e.g., bus-
   based), not extended (i.e., without bridging or routing), then meter
   placement is of no particular consequence.  If one were generating
   usage reports for a stub LAN, meters could reasonably be placed in a
   router, a dedicated monitor, or a host at any point on the LAN.
   Where an enterprise-wide network is a LAN, the same observation
   holds.  At the boundary between an enterprise and a regional network,
   however, in or near a router is an appropriate location for meters
   that will measure the enterprise's network activity.

   Meters are placed in (or near) routers to count packets at the
   Internet Protocol Level.  All traffic flows through two natural
   metering points: hosts and routers (Internet packet switches).  Hosts
   are the ultimate source and sink of all traffic.  Routers monitor all
   traffic which passes IN or OUT of each network.  Motivations for
   selecting the routers as the metering points are:

          o  Minimization of cost and overhead.
             (by concentrating the accounting function).  Centralize
             and minimize in terms of number of geographical or
             administrative regions, number of protocols monitored,
             and number of separate implementations modified.  (Hosts
             are too diverse and numerous for easy standardization.



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


             Routers concentrate traffic and are more homogeneous.)

          o  Traffic control.
             When and if usage sensitive quotas are involved, changes
             in meter status (e.g., exceeding a quota) would result in
             an active influence on network traffic (the router starts
             denying access).  A passive measuring device cannot
             control network access in response to detecting state.

          o  Intermediate system accounting.
             As discussed above, internet accounting includes both
             end-system and intermediate system accounting.  Hosts see
             only end-system traffic; routers see both the end-systems
             (internet source and destination) and the adjacent
             intermediate systems.

   Therefore, meters should be placed at:

          o  administrative boundaries
             only for measuring inter-domain traffic;

          o  stub networks
             for measuring intra-domain traffic.  For intra-domain
             traffic, the requirement for performing accounting at