rfc2975.txt

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

   Where the accounting proxy is not trusted, it may be difficult to
   verify that the proxy is issuing correct session records based on the
   accounting messages it receives, since the original accounting
   messages typically are not forwarded along with the session records.
   Therefore where trust is an issue, the proxy typically forwards the
   accounting packets themselves.  Assuming that the accounting protocol
   supports data object security, this allows the end-points to verify
   that the proxy has not modified the data in transit or snooped on the
   packet contents.


























Aboba, et al.                Informational                      [Page 6]

RFC 2975         Introduction to Accounting Management      October 2000


   The diagram below illustrates the accounting management architecture:

        +------------+
        |            |
        |   Network  |
        |   Device   |
        |            |
        +------------+
              |
   Accounting |
   Protocol   |
              |
              V
        +------------+                               +------------+
        |            |                               |            |
        |   Org B    |  Inter-domain session records |  Org A     |
        |   Acctg.   |<----------------------------->|  Acctg.    |
        |Proxy/Server|   or accounting protocol      |  Server    |
        |            |                               |            |
        +------------+                               +------------+
              |                                            |
              |                                            |
   Transfer   | Intra-domain                               |
   Protocol   | Session records                            |
              |                                            |
              V                                            V
        +------------+                               +------------+
        |            |                               |            |
        |  Org B     |                               |  Org A     |
        |  Billing   |                               |  Billing   |
        |  Server    |                               |  Server    |
        |            |                               |            |
        +------------+                               +------------+

1.4.  Accounting management objectives

   Accounting Management involves the collection of resource consumption
   data for the purposes of capacity and trend analysis, cost
   allocation, auditing, billing.  Each of these tasks has different
   requirements.

1.4.1.  Trend analysis and capacity planning

   In trend analysis and capacity planning, the goal is typically a
   forecast of future usage.  Since such forecasts are inherently
   imperfect, high reliability is typically not required, and moderate
   packet loss can be tolerated.  Where it is possible to use
   statistical sampling techniques to reduce data collection



Aboba, et al.                Informational                      [Page 7]

RFC 2975         Introduction to Accounting Management      October 2000


   requirements while still providing the forecast with the desired
   statistical accuracy, it may be possible to tolerate high packet loss
   as long as bias is not introduced.

   The security requirements for trend analysis and capacity planning
   depend on the circumstances of data collection and the sensitivity of
   the data.  Additional security services may be required when data is
   being transferred between administrative domains.  For example, when
   information is being collected and analyzed within the same
   administrative domain, integrity protection and authentication may be
   used in order to guard against collection of invalid data.  In
   inter-domain applications confidentiality may be desirable to guard
   against snooping by third parties.

1.4.2.  Billing

   When accounting data is used for billing purposes, the requirements
   depend on whether the billing process is usage-sensitive or not.

1.4.2.1.  Non-usage sensitive billing

   Since by definition, non-usage-sensitive billing does not require
   usage information, in theory all accounting data can be lost without
   affecting the billing process.  Of course this would also affect
   other tasks such as trend analysis or auditing, so that such
   wholesale data loss would still be unacceptable.

1.4.2.2.  Usage-sensitive billing

   Since usage-sensitive billing processes depend on usage information,
   packet loss may translate directly to revenue loss.  As a result, the
   billing process may need to conform to financial reporting and legal
   requirements, and therefore an archival accounting approach may be
   needed.

   Usage-sensitive systems may also require low processing delay.  Today
   credit risk is commonly managed by computerized fraud detection
   systems that are designed to detect unusual activity.  While
   efficiency concerns might otherwise dictate batched transmission of
   accounting data, where there is a risk of fraud, financial exposure
   increases with processing delay.  Thus it may be advisable to
   transmit each event individually to minimize batch size, or even to
   utilize quality of service techniques to minimize queuing delays.  In
   addition, it may be necessary for authorization to be dependent on
   ability to pay.






Aboba, et al.                Informational                      [Page 8]

RFC 2975         Introduction to Accounting Management      October 2000


   Whether these techniques will be useful varies by application since
   the degree of financial exposure is application-dependent.  For
   dial-up Internet access from a local provider, charges are typically
   low and therefore the risk of loss is small.  However, in the case of
   dial-up roaming or voice over IP, time-based charges may be
   substantial and therefore the risk of fraud is larger.  In such
   situations it is highly desirable to quickly detect unusual account
   activity, and it may be desirable for authorization to depend on
   ability to pay.  In situations where valuable resources can be
   reserved, or where charges can be high, very large bills may be rung
   up quickly, and processing may need to be completed within a defined
   time window in order to limit exposure.

   Since in usage-sensitive systems, accounting data translates into
   revenue, the security and reliability requirements are greater.  Due
   to financial and legal requirements such systems need to be able to
   survive an audit.  Thus security services such as authentication,
   integrity and replay protection are frequently required and
   confidentiality and data object integrity may also be desirable.
   Application-layer acknowledgments are also often required so as to
   guard against accounting server failures.

1.4.3.  Auditing

   With enterprise networking expenditures on the rise, interest in
   auditing is increasing.  Auditing, which is the act of verifying the
   correctness of a procedure, commonly relies on accounting data.
   Auditing tasks include verifying the correctness of an invoice
   submitted by a service provider, or verifying conformance to usage
   policy, service level agreements, or security guidelines.

   To permit a credible audit, the auditing data collection process must
   be at least as reliable as the accounting process being used by the
   entity that is being audited.  Similarly, security policies for the
   audit should be at least as stringent as those used in preparation of
   the original invoice.  Due to financial and legal requirements,
   archival accounting practices are frequently required in this
   application.

   Where auditing procedures are used to verify conformance to usage or
   security policies, security services may be desired.  This typically
   will include authentication, integrity and replay protection as well
   as confidentiality and data object integrity.  In order to permit
   response to security incidents in progress, auditing applications
   frequently are built to operate with low processing delay.






Aboba, et al.                Informational                      [Page 9]

RFC 2975         Introduction to Accounting Management      October 2000


1.4.4.  Cost allocation

   The application of cost allocation and billback methods by enterprise
   customers is not yet widespread.  However, with the convergence of
   telephony and data communications, there is increasing interest in
   applying cost allocation and billback procedures to networking costs,
   as is now commonly practiced with telecommunications costs.

   Cost allocation models, including traditional costing mechanisms
   described in [21]-[23] and activity-based costing techniques
   described in [24] are typically based on detailed analysis of usage
   data, and as a result they are almost always usage-sensitive.
   Whether these techniques are applied to allocation of costs between
   partners in a venture or to allocation of costs between departments
   in a single firm, cost allocation models often have profound
   behavioral and financial impacts.  As a result, systems developed for
   this purposes are typically as concerned with reliable data
   collection and security as are billing applications.  Due to
   financial and legal requirements, archival accounting practices are
   frequently required in this application.

1.5.  Intra-domain and inter-domain accounting

   Much of the initial work on accounting management has focused on
   intra-domain accounting applications.  However, with the increasing
   deployment of services such as dial-up roaming, Internet fax, Voice
   and Video over IP and QoS, applications requiring inter-domain
   accounting are becoming increasingly common.

   Inter-domain accounting differs from intra-domain accounting in
   several important ways.  Intra-domain accounting involves the
   collection of information on resource consumption within an
   administrative domain, for use within that domain.  In intra-domain
   accounting, accounting packets and session records typically do not
   cross administrative boundaries.  As a result, intra-domain
   accounting applications typically experience low packet loss and
   involve transfer of data between trusted entities.

   In contrast, inter-domain accounting involves the collection of
   information on resource consumption within an administrative domain,
   for use within another administrative domain.  In inter-domain
   accounting, accounting packets and session records will typically
   cross administrative boundaries.  As a result, inter-domain
   accounting applications may experience substantial packet loss.  In
   addition, the entities involved in the transfers cannot be assumed to
   trust each other.





Aboba, et al.                Informational                     [Page 10]

RFC 2975         Introduction to Accounting Management      October 2000


   Since inter-domain accounting applications involve transfers of
   accounting data between domains, additional security measures may be
   desirable.  In addition to authentication, replay and integrity
   protection, it may be desirable to deploy security services such as
   confidentiality and data object integrity.  In inter-domain
   accounting each involved party also typically requires a copy of each
   accounting event for invoice generation and auditing.

1.6.  Accounting record production

   Typically, a single accounting record is produced per session, or in
   some cases, a set of interim records which can be summarized in a
   single record for billing purposes.  However, to support deployment
   of services such as wireless access or complex billing regimes, a
   more sophisticated approach is required.

   It is necessary to generate several accounting records from a single
   session when pricing changes during a session.  For instance, the
   price of a service can be higher during peak hours than off-peak.
   For a session continuing from one tariff period to another, it
   becomes necessary for a device to report "packets sent" during both
   periods.

   Time is not the only factor requiring this approach.  For instance,
   in mobile access networks the user may roam from one place to another
   while still being connected in the same session.  If roaming causes a
   change in the tariffs, it is necessary to account for resource
   consumed in the first and second areas.  Another example is where
   modifications are allowed to an ongoing session.  For example, it is
   possible that a session could be re-authorized with improved QoS.
   This would require production of accounting records at both QoS
   levels.

   These examples could be addressed by using vectors or multi-
   dimensional arrays to represent resource consumption within a single
   session record.  For example, the vector or array could describe the
   resource consumption for each combination of factors, e.g. one data
   item could be the number of packets during peak hour in the area of