G. Carle
Internet Draft                                                S. Zander
Document: <draft-irtf-aaaarch-pol-acct-02.txt>                 T. Zseby
Category: Informational                                       GMD FOKUS
                                                             March 2001


                        Policy-based Accounting


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This draft describes policy-based accounting which is aimed at the
   provisioning of flexibility for accounting architectures. Accounting
   policies describe the configuration of an accounting architecture in
   a standardized way. They are used to instrument the accounting
   architecture and can be exchanged between AAA entities in order to
   share configuration information.

   This draft describes building blocks and message sequences for
   policy-based accounting in AAA. Examples are given for the usage of
   accounting policies in different scenarios. Furthermore it is shown
   how accounting components can be integrated into the authorization
   framework. This draft does not propose a language for the
   description of accounting policies. It is rather assumed that a
   suitable policy language can be chosen from existing or upcoming
   standards.








Carle, Zander, Zseby        Expires September 2001            [Page 1]


Internet Draft             Policy-based Accounting          March 2001


Table of Contents

   1.   Introduction.................................................2
   2.   Terminology..................................................3
   3.   Impact of Provider Network Characteristics to Accounting.....4
   4.   Business roles and relations.................................5
   5.   Reference Model and Building Blocks..........................8
   6.   Accounting Policies.........................................10
   7.   Accounting Services.........................................14
   7.1  Integrated Accounting.......................................14
   7.2  Discrete Accounting.........................................15
   7.3  Intra-Domain Accounting.....................................17
   7.4  Inter-Domain Accounting.....................................17
   8.   Accounting with different Authorization Models..............19
   8.1  Agent Sequence..............................................19
   8.2  Pull Sequence...............................................20
   8.3  Push Sequence...............................................20
   8.4  Roaming.....................................................21
   9.   Examples....................................................22
   9.1  Printing Service Example....................................22
   9.1.1Intra-Domain Accounting.....................................22
   9.1.2Inter-Domain Accounting.....................................22
   9.1.3User Accounting Indication..................................23
   9.2  Mobile/Roaming Example......................................24
   9.3  Diffserv Example............................................26
   9.4  User Accounting Indication Example..........................28
   10.  Security Considerations.....................................30
   11.  References..................................................32
   12.  Acknowledgments.............................................32
   13.  Author's Addresses..........................................33
   14.  Full Copyright Statement....................................33

1. Introduction

   Even if we will have much more bandwidth in the future than now, the
   control of network resource utilization remains essential for the
   support of applications with special demands and for the prevention
   of (malicious or accidental) waste of bandwidth. Charging provides a
   possibility to control utilization and sharing of network resources.
   Charging in multi-service networks can be done based on the reserved
   or the actual used resources. Charging on reserved resources makes
   sense since reservation usually precludes other users from using the
   reserved resources. Nevertheless, if charging is limited to
   reservation parameters only, the applied charge depends on the
   ability of the user to give a good prediction of the expected
   traffic characteristics. This can be extenuated by using a charging
   scheme that is based on both the reserved and the used resources. In
   order to support usage-based charging, the collection of information
   about the resource reservation and utilization is required. The
   collection of data about resource usage is called accounting.
   Accounting management architectures and objectives as well as the
   transport of accounting records are discussed in [2] and not further


Carle, Zander, Zseby        Expires September 2001            [Page 2]


Internet Draft             Policy-based Accounting          March 2001


   explained here. This document concentrates on the configuration of
   the accounting architecture and measurement devices.

   Service providers have various options for service differentiation,
   charging schemes and the provisioning of accounting services. Users
   introduce various traffic profiles and may have individual
   preferences regarding the accounting services (like itemized
   invoices, accounting indications, spending limits etc.). In order to
   support the different accounting requirements that result from these
   variability an accounting architecture has to be flexible with
   regard to the data collection and distribution process. To support
   the configuration of such an architecture in a standardized way we
   propose to use accounting policies that are exchanged between the
   different entities involved in the accounting process.

   This document describes the structure and usage of accounting
   policies. It shows how the characteristics of the provider network
   influences the requirements for accounting. The relations between
   the different roles that are involved in the accounting process and
   the required building blocks for an accounting architecture are
   introduced.

   Furthermore it is shown how different accounting services can be
   provided in intra- and inter-domain scenarios. Examples are given
   for the usage of accounting policies in different scenarios. They
   show how accounting components can be integrated into the
   authorization framework proposed in [1]. This draft does not propose
   a language for the description of accounting policies. It is rather
   assumed that a suitable policy language can be chosen from existing
   or upcoming standards.

2. Terminology

   Accounting Indication/Confirmation
        Accounting indication messages are pushed from the originating
        AAA Server (the server where the accounting information was
        generated) to the recipient which can be a AAA Server or a
        customer/user application. Accounting indications contain
        accounting records which describe the resource consumption for
        a service. Accounting indications messages can also contain
        aggregated information for multiple services. There can be
        interim and end-of-session accounting indication messages.
        Interim indications are delivered in specified intervals to the
        recipient during the service session while end-of-session
        indications are given to the recipient at the end of the
        session only. Accounting indications should be acknowledged by
        accounting confirmations to provide reliability.

   Accounting Request/Answer
        Accounting Requests can be sent by a AAA Server to another AAA
        Server to request the current accounting information for a
        particular session set (polling). The request is answered with
        a accounting answer which contains the accounting records.

Carle, Zander, Zseby        Expires September 2001            [Page 3]


Internet Draft             Policy-based Accounting          March 2001



   Accounting Policies
        Accounting policies describes rules for generation, transport
        and storage of accounting data. These rules are used for the
        configuration of the accounting process.

   Application Specific Module (ASM)
        An ASM provides the functionalities required by a specific
        application for the provisioning of a service. It gets
        application specific information (ASI)(e.g. for configuration)
        from the AAA server either in a generic format or in an
        application specific format encapsulated in a standard message
        sent to the ASM. The ASM either extracts the application
        specific information (ASI) from the message or converts
        information given in a generic format into the appropriate
        application specific format. Further information on how the ASM
        is used can be found in [3].

   Charging Scheme
        A charging scheme is an instruction for calculating a charge.
        Usually a charging scheme is represented by a formula that
        consists of charging variables (e.g. volume, time, reserved
        peak rate) and charging coefficients (e.g. price per time
        unit). The charging variables are usually filled by information
        from accounting data.

   QoS Auditing
        QoS Auditing is the process of evaluating whether a given
        quality of service guarantee (e.g. thresholds for QoS
        parameters given in an SLA) has been met during the service
        provisioning.

3. Impact of Provider Network Characteristics to Accounting

   There are many options for future service providers for the
   realization of service differentiation and provisioning. Therefore
   provider networks can vary with respect to several characteristics
   that impact accounting and charging:

   - Size and Purpose
   A small ISP that deals with individual customers may charge
   individual users based on single flows. Backbone operator have small
   ISPs and large corporations as customers, and usually charge based
   on traffic aggregates instead of individual flows.

   - QoS provisioning technique
   DiffServ accounting requirements differ from IntServ accounting
   requirements (e.g. meter granularity).

   - Service classes
   The definition of service classes within a network and the degree of
   freedom that customers are given (e.g. gold/silver/bronze service
   vs. a free choice of individual traffic profile parameters) is

Carle, Zander, Zseby        Expires September 2001            [Page 4]


Internet Draft             Policy-based Accounting          March 2001


   important, e.g. for the flow classification within the network, and
   influences the accounting functions required.

   - Charging scheme
   There exists a wide variety of charging schemes using tariff
   variables based on different technical and/or economical models. The
   chosen charging scheme(s) influence the accounting requirements for
   the provider. While some charging schemes lead to zero or only few
   accounting requirements, other charging schemes may be highly
   demanding. For instance flat rate charging schemes require no
   accounting infrastructure at all. In contrast to this volume-based
   charging schemes require the measurement of the transmitted volume
   and with this increases the complexity for accounting. Tariffs that
   introduce variable prices may require to provide the users regularly
   with accounting information (e.g. by interim accounting
   indications).

   - Accounting Services
   Providers may offer different accounting services (e.g. accounting
   indication, itemized invoice, etc.)

   - Accounting agreements with other providers
   Providers may have agreements with other providers in order to share
   accounting tasks and distribute accounting data so that, e.g.,
   metering has to be done only once. For this it may be useful if
   providers can not only exchange accounting data but also information
   on the configuration of accounting modules (e.g. meters).

   - Exploiting Capabilities of Existing Infrastructure (meters, data
   collection points)
   Providers may already have functions within the network that can
   provide accounting functions (e.g. MIB objects, profile meters,
   proprietary accounting solutions). In order to avoid duplicated
   functionality, it should be possible to use these accounting
   resources. Therefore the configuration of different types of
   accounting modules (e.g. meters) should be possible. A common
   language to express accounting module configurations would be useful
   for this purpose.

4. Business roles and relations

   In investigating service provision in the current and forthcoming
   Internet we identified different business roles which are part of
   the service usage lifecycle. In this section we first define the
   term service. Afterwards the different roles and their relationships
   are defined. The business roles in this model are used in the later
   examples.

   - Service
   A service is a set of capabilities offered by a provider to a
   customer. In this definition provider and customer can be one of the
   business roles defined later. Different kinds of services have to be
   recognized.

Carle, Zander, Zseby        Expires September 2001            [Page 5]


Internet Draft             Policy-based Accounting          March 2001



        - Information services handle the delivery of information to
        the customer on top of transport services. In content-based
        services the service subscriber pays for the content (e.g. for
        a file, an image, a video, etc.). In communication-based
        services the service subscriber pays for the provisioning of a
        certain form of communication (e.g. videoconferencing or IP
        telephony).

        - Transport services describe the provisioning of pure
        transportation of IP packets. At the IP layer this may include
        the differentiation of packets (e.g. number of packets with a
        certain DSCP), Intserv based reservation or other methods for
        QoS enhancement (e.g. ARQ, FEC). A transport service may as
        well include mechanisms on other layers for improving the
        transport (e.g. MPLS).

        - Management services are responsible for the management of
        resources (e.g. configuration, accounting, security).
        Accounting services describe the provisioning of data about the
        current or previous resource reservation and usage. Accounting
        services are needed by providers to generate a bill or by users
        to monitor their resource usage.

   - Service Subscriber
   The service subscriber is the entity that has subscribed to a
   service and thus has a contractual relationship with a service
   provider and a network provider which provides the underlying
   transport service. A service subscriber can also act as a service
   user. The service subscriber might have a relationship with a broker
   which provides service relevant information.

   - Service User
   The service user is the entity that uses the service. The service
   user can be identical with the service subscriber. In cases where
   subscriber and user are not identical, the service subscriber should
   be able to control the service usage for all service users he or she
   is responsible for.

   - Network Provider
   A network provider is the entity that provides the underlying
   network infrastructure for the service user, service subscriber,
   service provider and broker. A network provider provides transport
   services. The services are delivered on top of the network
   infrastructure. The service provider has a contractual relationship
   with service subscriber and service provider (and the broker). The
   transport network of a network provider is probably not a global
   network which connects all subscribers, providers and brokers. The
   transport network is segmented into a number of sub-networks or
   domains controlled by different network providers with business
   relations existing between them. Each domain is responsible for
   intra-domain management and accounting. For inter-domain management


Carle, Zander, Zseby        Expires September 2001            [Page 6]


Internet Draft             Policy-based Accounting          March 2001


   and accounting appropriate communication interfaces between network
   providers must exist.

   - Service Provider
   A service provider entity provides a service. A service provider can
   offer a service directly to the service subscriber/user. A service
   provider can also act like a wholesaler selling a service to another
   service provider (retailer) which resells the service to the service
   subscriber. The service provider has contractual relationships with
   other service providers, subscribers, brokers and network provider.
   A service provider provides information services on top of
   transport services provided by network providers.

   - Broker
   The broker entity allows the other roles to access the information
   controlled by the broker. The broker can provide different
   information to different business roles. For example a service
   subscriber can get references to appropriate service providers
   and/or network providers (e.g. a broker gives the subscriber a
   reference to a network provider which can provide bandwidth as
   required by the subscriber). A broker can also interact with other
   brokers to complete their information. In this case broker-to-broker
   business relationships exist.

   Figure 1 depicts the different roles and the business relations
   between them.
                                     +----+
                                     V    |
                       +---------------+  |
                       |  Broker       |<-+
               +------>|               |<-----------------+
               |       +---------------+                  |
               |               ^                          |
               |               |                          |
               |               V                          V
               |       +------------------+        +---------------+
               |       |  Service         |        |   Service     |
               |       |  Subscriber      |<------>|   Provider    |
               |       |                  |        |               |<-+
               |       | +--------------+ |        +---------------+  |
               |       | | Service User | |               ^      ^    |
               |       | +--------------+ |               |      +----+
               |       +------------------+               |
               |               ^                          |
               |               |                          |
               |               V                          |
               |       +---------------+                  |
               +------>|  Network      |<-----------------+
                       |  Provider     |<-+
                       +---------------+  |
                                     ^    |
                                     +----+


Carle, Zander, Zseby        Expires September 2001            [Page 7]


Internet Draft             Policy-based Accounting          March 2001


   Figure 1: Roles and business relations

   The following examples show how this business relationship model can
   be applied to different services.

   Example 1: This example describes an Internet printing scenario
   according to the "print-by-reference" model [4]. The subscriber is a
   company, the users are the employees of that company. The file
   server and print server belong to two different service providers.
   The company subscribes to the print server service which acts as
   reseller for the file service. The file server service chooses the
   appropriate transport service (maybe based on user preference), thus
   the file server has a contract with a network provider using the
   offered transport service for downloading the data from the given
   location and sending them to the print server.

   Example 2: A company (service subscriber) has a contract with a
   video archive (service provider). An employee can download clips in
   different qualities from the archive. The employee can use different
   transport mechanisms for the download. For getting the appropriate
   transport the user contacts an agency (broker) that returns a
   reference to a network provider which provides the required
   transport service. As an alternative the content (video) can be
   delivered in different qualities via different transport mechanisms
   by the service provider. The service provider chooses a appropriate
   network provider which provides a transport service compliant with
   the conditions the service provider offers to the subscribers. In
   this case the service provider can use the facilities of a broker to
   get a reference to appropriate network providers.

5. Reference Model and Building Blocks

   We have developed a reference model for describing the interactions
   between the different metering, accounting and charging processes
   and their configuration via policies. This reference model is shown
   in Figure 2. At the right side five layers show the different
   building blocks. The blocks are layered according to the processing
   of the data from the bottom level metering via accounting up to the
   final billing process. Data aggregation is not exclusively done at
   the collection layer it is probably also done at the other layers.
   The building blocks on the different layers are configured through
   the policies shown on the left side. Higher layer policies are
   translated into lower layer policies. The configuration parameters
   are extracted from the policy and passed to the corresponding
   building block. The tasks of the different building blocks are as
   follows:

   - Metering
   Meters are needed for capturing data about resource consumption in
   the network (e.g. transmitted volume). They will probably be placed
   at the edges of the network. Two types of meters can be
   distinguished: Static meters, and configurable meters. In case of
   static meters all flows are measured with a fixed granularity, not

Carle, Zander, Zseby        Expires September 2001            [Page 8]


Internet Draft             Policy-based Accounting          March 2001


   distinguishing if a subsequent charging process needs the specific
   meter data or not. In most cases the huge amount of captured data
   makes a filtering stage after the metering necessary. In case of a
   configurable meter, the meter collects meter data only for flows
   specified by metering policies.

   For configuration of the meter process the following issues must be
   addressed: (a) metering scope (whether to meter all flows or only
   selected flows), (b) metered flow attributes (i.e. which data is to
   be collected for a specific flow), and (c) meter granularity
   (measurement intervals etc.)

   - Collection
   The data gathered by the meter(s) has to be collected for further
   processing. Collection of meter data can be initiated by the meter
   itself (push model), or by a collector entity (pull model).
   Collected data can be aggregated before passed to the accounting
   layer. Metering policies define how collection and aggregation is
   done.

   - Accounting
   Accounting describes the collection of data about resource
   consumption. This includes the control of data gathering (via
   metering), transport and storage of accounting data. For subsequent
   charging, the metered data must be associated with a user that is
   the initiator of a flow, and a customer (service subscriber) that is
   responsible for payment. For initiation of an accounting process, a
   user or foreign provider must be authenticated and authorized. These
   three functions can be performed by the AAA server. The accounting
   process is configured through accounting policies.

   - Charging
   The Charging derives non-monetary costs for accounting data sets
   based on service and customer specific tariff parameters. Different
   cost metrics may be applied to the same accounting records even in
   parallel. Charging policies define the tariffs and parameters which
   are applied.

   - Billing
   The Billing translates costs calculated by the Charging into
   monetary units and generates a final bill for the customer. Billing
   policies define the type (e.g. invoice, credit card), the form (e.g.
   itemized or not, partial anyomization, etc.) of the bill and the
   time for billing (e.g. weekly, monthly, etc.).










Carle, Zander, Zseby        Expires September 2001            [Page 9]


Internet Draft             Policy-based Accounting          March 2001








         POLICY          CONFIGURATION          BUILDING BLOCKS

     +---------------+                   +-------------------------+
     |               |------------------>|        Billing          |
     |  Billing &    |                   +-------------------------+
     |  Charging     |                            ^ charging
     |               |                             | data
     |               |                   +-------------------------+
     |               |------------------>|        Charging         |
     +---------------+                   +-------------------------+
             |                                     ^ acct
             V                                     | data
     +---------------+                   +-------------------------+
     |  Accounting   |                   |                         |
     |               |------------------>|        Accounting       |
     +---------------+                   +-------------------------+
             |                                     ^ aggr. meter
             V                                     | data
     +---------------+                   +-------------------------+
     |               |------------------>|        Collection       |
     |  Metering     |                   |                         |
     |               |                   +-------------------------+
     |               |                             ^ meter
     |               |                             | data
     |               |                   +-------------------------+
     |               |------------------>|        Metering         |
     +---------------+                   +-------------------------+

   Figure 2: Reference Model

   We propose to use policies expressed in a standardized way to
   configure the meter, meter data collection and accounting processes
   appropriately.

6. Accounting Policies

   Accounting policies describe rules for generation, transport and
   storage of accounting data. They can  be exchanged between AAA
   instances at the user or provider premises. They give a standardized
   representation of policies that can be converted into the
   appropriate settings for different elements of the accounting
   infrastructures (e.g. different meters).

   Accounting Policies reside in the AAA server (local policies) or are
   received from neighbor AAA servers. Two different models of
   obtaining accounting policies can be differentiated: push and pull
   model.

Carle, Zander, Zseby        Expires September 2001            [Page 10]


Internet Draft             Policy-based Accounting          March 2001



   Push Model
   In the push model accounting policies are pushed from another AAA
   server in order to establish the policies in the local accounting
   infrastructure. The permission of pushed policies requires special
   security considerations. The evaluation of the policy should not
   take place without an appropriate security check of the policy in
   advance. Also the evaluation of the condition can lead to unwanted
   actions in the AAA server. If the condition contains critical data
   either intentionally (to attack the system) or by accident. Even the
   evaluation of the condition can cause problems (e.g. DoS). Therefore
   not only the action but also the condition has to be checked in
   accordance to potential security hazards before it is evaluated.

   Pull Model
   In the pull model the AAA server requests the policy from a remote
   AAA server by sending accounting policy request. The remote AAA
   server sends an accounting policy reply as an answer that contains
   the appropriate policy.

   An accounting policy consists of a condition part and an action
   part. The condition part expresses under which condition the policy
   should be enforced. Possible condition variables in accounting
   policies are the following:

   - user ID or customer ID
   The user ID can be used to select an appropriate accounting
   configuration. For example it can be user-dependent whether
   accounting indications are send to the user or not.

   - IP address
   The address of the hosts or subnet can be used to select accounting
   strategies specific to the customer or a user group. (e.g. all
   customers of an ISP all public terminals etc.)

   - service class
   The service class that has been chosen by the customer/user can have
   a significant impact on the desired accounting configuration. For
   instance in DiffServ networks the meters need to know what DSCPs are
   expected to derive an appropriate configuration for the
   classification. Furthermore it makes sense to depend the level of
   detail for the accounting records and the report interval from the
   reserved class. For instance to provide more detailed accounting
   records for higher prioritized services than for standards services.

   - accounting type
   Accounting types can be used to provide predefined settings for the
   accounting infrastructure. For instance the combination of high
   granular accounting records with short report intervals under a
   keyword (e.g. Ÿcomprehensive accounting÷) or less frequent
   generation of less detailed records accessed by another key
   (standard accounting÷). This can help to simplify the configuration
   process if providers agree on keywords.

Carle, Zander, Zseby        Expires September 2001            [Page 11]


Internet Draft             Policy-based Accounting          March 2001



   The action part defines the action that takes place if the condition
   is true. The action for an accounting policy is usually the
   configuration of the accounting infrastructure. This can already
   include settings for meters and collection entities. Settings for
   the following variables of the accounting infrastructure can be set
   in accounting policies:

   - accounting record type/structure
   The required accounting data depends on the charging scheme.
   Therefore different accounting records should be supported. There
   are two possibilities. Either different record types are defined or
   a flexible record is used that consists of a variable set of
   accounting attributes. Accounting policies can be used to
   communicate to neighbor providers which kind of accounting record is
   needed to provide appropriate data for the charging scheme. The
   specification of the required accounting attributes can influence
   the settings of different components of the accounting architecture
   (e.g. which attributes have to be measured). An overview of
   accounting attributes and records can be found in [5].

   - accounting record destination
   The accounting record destination describes to which entities
   accounting records are sent. The accounting record destination can
   be a charging entity, a neighbor provider, a user entity or a
   specific database. In these cases authentication and authorization
   mechanisms have to be applied in order to prevent that unauthorized
   entities can get access to confidential data.

   - report interval
   The report interval specifies in what time intervals accounting
   records are generated and sent. This influences the configuration of
   meters and collectors in the accounting architecture.

   - storage time
   If the accounting record destination is a database or a log file the
   storage time specifies how long the accounting records have to be
   stored.

   - access list
   The access list specifies who has the permission to read the stored
   accounting records.

   Accounting policies are enforced by configuring the accounting
   architecture in the appropriate way. They influence the following
   settings in the accounting architecture:

   - meter configuration (meter accuracy and granularity, relevant
   attributes, meter intervals )

   - data collection process (from which meters data has to be
   collected, how often, which post-processing has to be applied)


Carle, Zander, Zseby        Expires September 2001            [Page 12]


Internet Draft             Policy-based Accounting          March 2001


   - accounting record distribution (when are which accounting records
   sent to whom)

   - accounting record storage (location, expiration time, access list)

   - accounting data aggregation (when which records should be
   aggregated and how aggregation is done)

   An example how accounting policies can be used to configure
   different meters is given below. The accounting policy is sent from
   the AAA server to the ASM and there converted to the appropriate
   configuration information for the used meter. If NeTraMet is used,
   the policy is converted into a NeTraMet ruleset that contains the
   relevant flows, attributes and reader instructions for the data
   collection. This information is passed to the NeTraMet manager that
   configures meter and meter reader in accordance to the given
   configuration.

     +------------------+
     |     AAA          |
     |                  |
     +------------------+
           |         ^
    Policy |         | Accounting Records
           V         |
     +------------------+
     |     ASM          |
     |                  |
     +------------------+
         |           ^
         |           |
         | config    +-----------------+
         |                             |
    +-------------------------------+  |
    |    |       Accounting         |  |
    |    V                          |  |
    | +----------------+            |  |
    | | Meter Manager  |            |  | Accounting Records
    | +----------------+            |  |
    |    |      \                   |  |
    |  SNMP      \                  |  |
    |  (conf)+---------------+      |  |
    |    |   | Meter Reader  |---------+
    |    |   +---------------+      |
    |    |              ^           |
    |    V              |           |
    | +-----------+     |           |
    | |   Meter   |-----+           |
    | +-----------+    SNMP(DATA)   |
    |                               |
    +-------------------------------+

   Figure 4: Policy based Accounting with NeTraMet

Carle, Zander, Zseby        Expires September 2001            [Page 13]


Internet Draft             Policy-based Accounting          March 2001



   If NetFlow is used as a meter, the meter policies are translated by
   the ASM into filter instructions for the flow collector. The meter
   itself is static and therefore is not affected by the configuration
   information.
     +------------------+
     |    AAA           |
     |                  |
     +------------------+
           |         ^
    Policy |         | Accounting Records
           V         |
     +------------------+
     |     ASM          |
     |                  |
     +------------------+
         |           ^
         |           |
         | config    | Accounting Records
         |           |
    +-------------------------------+
    |    |    Accounting            |
    |    |                          |
    |    |  +---------------------+ |
    |    |  | Flow Collector      | |
    |    |  |      +------------+ | |
    |    |  |      | Filter     | | |
    |    |  |      | Aggregator | | |
    |    +->|      +------------+ | |
    |       +---------------------+ |
    |                   ^           |
    |                   |           |
    | +-----------+     |           |
    | |   Meter   |-----+           |
    | +-----------+   UDP (DATA)    |
    |                               |
    +-------------------------------+

   Figure 5: Policy based Accounting with NetFlow

7. Accounting Services

   Accounting can be seen as part of the service provisioning process
   (integrated accounting) or as a separate service (discrete
   accounting). The different views and their impact on the accounting
   architecture are described below.

7.1 Integrated Accounting

   In the integrated accounting model the accounting is seen as part of
   the provisioned service. That means the accounting is coupled to a
   specific service. Therefore the accounting process is tailored to
   the specific service and might collect accounting information by

Carle, Zander, Zseby        Expires September 2001            [Page 14]


Internet Draft             Policy-based Accounting          March 2001


   directly exploiting some service specific entity. For example
   accounting for IP telephony could use call signaling information
   from a SIP server. The configuration of the accounting architecture
   is done as part of the service equipment configuration. Accounting
   policies are defined as part of the service provisioning agreement.
   The ASM converts the instructions from the AAA server into the
   appropriate service equipment configuration including settings for
   the accounting architecture.

            +---------------------+
   <---1--->|  Generic AAA Server |<---1--->
            |                     |            ............
            |  Rule based engine  |<----|----->:  Policy  :
            |                     |    3|      :..........:
            +---------------------+<----|--+   ............
                        ^                  +-->:  Events  :
                        |                      :..........:
                        2
                        |
                        V
            +----------------------+       ...............
            | Application specific |<--3-->: Acct Policy :
            |         Module       |       :.............:
            +----------------------+
                        ^
                        |
                        5
                        |
                        V
         +-------------------------------------+
         | Service                             |
         | +-----------+    +----------------+ |     ..............
         | | Service   |<-->|  Accounting/   |<--3-->: Accounting :
         | | Provision |    |  Metering      | |     : Data       :
         | +-----------+    +----------------+ |     :............:
         +-------------------------------------+

   Figure 8: AAA Server with Integrated Accounting

   Data about the resource consumption is sent back to the AAA Server
   via the ASM. The accounting within process within the service
   converts the metered data into accounting records which are sent to
   the AAA server. For generating accounting records data conversion,
   aggregation and filtering of data might be performed.

7.2 Discrete Accounting

   In contrast to the integrated accounting approach, accounting can
   also be seen as a separate or discrete service on its own. In this
   case the accounting does not have to be coupled to a specific
   service. Discrete Accounting can be used for outsourcing the
   accounting task. The accounting service can be provided by a general
   accounting system which is able to account for different services.

Carle, Zander, Zseby        Expires September 2001            [Page 15]


Internet Draft             Policy-based Accounting          March 2001


   For example a generalized meter can do accounting for web traffic,
   FTP traffic and voice over IP traffic. If accounting is a separate
   service one provider can do the accounting (charging and billing)
   for several other service providers. Accounting is offered just like
   any other service. This means authentication and authorization might
   be required prior to the service provisioning.

   A service provider that has outsourced the accounting service has to
   request the accounting service from an accounting service provider.
   The generated accounting records are send from the accounting
   provider to the service provider who may make modifications to the
   records before sending them to the customer. Having such a general
   accounting service might speed up the creation of new services “
   especially specialized content services - in the Internet. This
   separation is also beneficial to support special accounting services
   (e.g. sending accounting indications to users) that are not directly
   coupled to a network service. Furthermore this separation is useful
   if the same set of accounting strategies can be applied to different
   services (e.g. different tariffs which can be used for a set of
   services).

            +---------------------+
   <---1--->|  Generic AAA Server |<---1--->
            |                     |            ............
            |  Rule based engine  |<----|----->:  Policy  :
            |                     |    3|      :..........:
            +---------------------+<----|--+   ............
                ^             ^            +-->:  Events  :
                |             |                :..........:
                2             2
                |             |
                V             V
        +-------------+    +--------------+       ...............
        | Application |    | Application  |<--3-->: Acct Policy :
        | Specific    |    | Specific     |       :.............:
        | Module      |    | Module       |
        +-------------+    +--------------+
               ^                  ^
               |                  |
               5                  5
               |                  |
               V                  V
        +-------------+    +---------------+       ..............
        |  Service    |    |  Accounting/  |<--3-->: Accounting :
        |             |    |  Metering     |       : Data       :
        +-------------+    +---------------+       :............:

   Figure 9: AAA Server with Discrete Accounting

   Another option is to outsource only the metering service. The meter
   service provider generates meter data and sends them to the service
   provider who has requested them. The service provider then generates
   accounting records based on the received meter data. A separate

Carle, Zander, Zseby        Expires September 2001            [Page 16]


Internet Draft             Policy-based Accounting          March 2001


   accounting or metering service provider can be used to validate the
   accounting data generated by a service provider. If the customer
   does not trust a service provider or in the case of a legal action a
   trusted accounting or metering provider should be able to validate
   the correctness of the accounting data generated by the service
   provider.

7.3 Intra-Domain Accounting

   In Intra-Domain accounting [2] the data about the resource
   consumption is collected in one administrative domain for the usage
   in that domain. Accounting policies are locally enforced. Since no
   exchange of accounting data with other domains is required in this
   scenario accounting policies do not need to be exchanged with other
   entities.

                                +-------------+
                                |   Billing   |
                                +-------------+
                                        ^
                                        |
                                +-------------+
                                |     ASM     |
                                +-------------+
                                        ^
                                        |            ..............
                                +--------------+     : Accounting :
                                |    AAA       |<--->: Policies   :
                                +--------------+     :............:
                                     |      ^
                                     |      |
                                     V      |
                                +--------------+
                                |     ASM      |
                                +--------------+
                                     |      ^
                              config |      | Accounting Records
                                     V      |
   +------------+               +-----------|----------+
   |            | Service usage |  +--------+-------+  |
   | End System |-------------->|  | Accounting     |  |
   |            |               |  +----------------+  |
   +------------+               |                      |
                                |  Service             |
                                +----------------------+

        User                            Provider

   Figure 10: Intra-Domain Accounting

7.4 Inter-Domain Accounting



Carle, Zander, Zseby        Expires September 2001            [Page 17]


Internet Draft             Policy-based Accounting          March 2001


   For Inter-Domain Accounting at least two administratively separated
   networks are involved in the accounting process. These can be a
   Home- and a Foreign-Provider in a Roaming/Mobile IP Scenario or a
   chain of providers if service provisioning involves data transfer
   and/or services from different domains. In these scenarios the
   exchange of accounting policies between providers is necessary if
   accounting tasks are delegated to one provider or shared among
   multiple providers. The exchange of accounting policies is done by
   the AAA servers like shown in the figure below.


                                                    |     +-----------+
                                                    |     |  Billing  |
                                                    |     +-----------+
                                                    |           ^
                                                    |           |
                                                    |     +-----------+
                                                    |     |    ASM    |
                                                    |     +-----------+
                                                    |           ^
                                                    |           |
                        +------------------+ 1. AccPolInd +-----------+
                        |                  |<-------------|           |
                        |                  |        |     |           |
                        |     AAAF         | 2.AccPolConf |   AAAH    |
                        |                  |------------->|           |
                        |                  |        |     |           |
                        |                  | 3. AccRec    |           |
                        |                  |------------->|           |
                        +------------------+        |     +-----------+
                    config  |       ^               |           ^
                            |       |               |           |
                            V       |               |           V
                        +--------------+            |     .............
                        |     ASM      |            |     : Acct.     :
                        +--------------+            |     : Policies  :
                            |       ^               |     :...........:
                            |       |               |
                            |       | Acct. Records |
                 Service    V       |               |
   +------------+ usage +-----------|----------+    |
   |            |       |  +--------+-------+  |    |
   | End System |------>|  | Accounting     |  |    |
   |            |       |  +----------------+  |    |
   +------------+       |                      |    |
                        |  Service             |    |
                        +----------------------+    |

        User                   Foreign-Provider         Home-Provider

   Figure 11: Inter-Domain Accounting (Roaming Example)



Carle, Zander, Zseby        Expires September 2001            [Page 18]


Internet Draft             Policy-based Accounting          March 2001


   In this example the foreign provider takes over the collection of
   accounting data. The home provider is responsible for applying a
   charging scheme and sending the bill. Therefore the home provider
   needs accounting data from the foreign provider. In order to
   instruct the foreign provider about the desired accounting record
   type and report frequency the home AAA server sends an accounting
   policy request to the foreign AAA server. The request contains the
   accounting policy. Instead of sending a request the accounting
   policies could also be piggybacked onto an authorization reply. If
   the foreign AAA server is able to enforce the desired policy (e.g.
   the meters are capable of metering the requested attributes) the
   accounting policy request is acknowledged. In case the requested
   policy cannot be enforced, the accounting service is denied. Reasons
   to deny the enforcement of a specific accounting policy could be
   e.g. because the meter is not capable to measure the requested
   attributes or the frequency of records cannot be provided, or the
   home provider is not authorized to get the requested detailed data.
   In this case procedures would be useful to negotiate the smallest
   common denominator for the involved AAA servers regarding the
   provisioning of accounting data.

8. Accounting with different Authorization Models

   [1] introduces different message sequences for authorization. The
   integration of configurable accounting services for the message
   sequences can be done as described in the following sections.

8.1 Agent Sequence

   The appropriate accounting policy for the authorized service is
   either stored together with the authorization policy or in a
   separate repository. The configuration of the accounting
   infrastructure can be done together with the setup of the service
   equipment (message 1 in Figure 13). Setting up the service equipment
   and the accounting infrastructure configuration might involve the
   transfer of configuration data to multiple entities in the network
   (e.g. to different routers for setting up QoS provisioning or to
   dedicated accounting meters).

                             +-------------------------+
               +------+      | Service Provider        |
               |      |   1  |  +-------------------+  |
               |      |------+->|    AAA Server     |  |
               |      |<-----+--|                   |  |
               |      |   4  |  +-------------------+  |
               | User |      |       |  /|\  /|\       |
               |      |      |       |2  |3   |AcctRec |
               |      |      |      \|/  |    |        |
               |      |      |  +-------------------+  |
               |      |      |  |      Service      |  |
               |      |      |  |     Equipment     |  |
               |      |      |  +-------------------+  |
               +------+      |                         |

Carle, Zander, Zseby        Expires September 2001            [Page 19]


Internet Draft             Policy-based Accounting          March 2001


                             +-------------------------+

   Figure 13: Accounting and Agent Sequence

   In the agent sequence it is possible to allow the user to send an
   accounting policy request (e.g. for accounting indications) together
   with the authorization request to the AAA server. Figure 13 shows
   the agent sequence authorization and accounting messages.

8.2 Pull Sequence

   The configuration of the accounting infrastructure can be done
   similar to the agent sequence during the setup of the service
   equipment. Since the pull sequence does not involve the sending of a
   specific authorization request (e.g. if the service equipment is a
   NAS and the authorization sequence simply starts with the dial-in
   process) it would need additional communication to support
   accounting policy requests from users. This can be for instance
   achieved by a hybrid model of agent and pull sequence where the user
   sends an accounting policy request to the AAA server in addition to
   the messages exchange for the pull sequence. Figure 14 shows the
   pull sequence authorization and accounting messages.

                              +-------------------------+
               +------+       | Service Provider        |
               |      |AccPolInd +-------------------+  |
               |      |.........>|    AAA Server     |  |
               |      |<.........|                   |  |
               |      |       |  +-------------------+  |
               | User |       |      /|\  |  /|\        |
               |      |       |       |2  |3  |AcctRec  |
               |      |       |       |  \|/  |         |
               |      |   1   |  +-------------------+  |
               |      |-------+->|      Service      |  |
               |      |<------+--|     Equipment     |  |
               |      |   4   |  +-------------------+  |
               +------+       |                         |
                              +-------------------------+

   Figure 14: Accounting and Pull Sequence

8.3 Push Sequence

   In the push sequence there is no direct connection between the AAA
   server and the service equipment. In this sequence there are three
   possibilities for setting up the accounting infrastructure:

   a) A standard fixed accounting procedure is used, that has been
   assigned in advance for the specific combination of authorized user
   and service.




Carle, Zander, Zseby        Expires September 2001            [Page 20]


Internet Draft             Policy-based Accounting          March 2001


   b) The ticket (message 3 in Figure 17) contains information about
   the accounting policies used (e.g. different tickets for the same
   service with different accounting policies).

   c) The ticket acts as a kind of digital coin and no further
   accounting is needed. This model also supports the anonymous usage
   of a service.

   Figure 15 shows push sequence authorization and accounting messages.

                               +-------------------------+
                 +------+      | Service Provider        |
                 |      |   1  |  +-------------------+  |
                 |      |------+->|    AAA Server     |  |
                 |      |<-----+--|                   |  |
                 |      |   2  |  +-------------------+  |
                 | User |      |             /|\        |
                 |      |      |              | AcctRec  |
                 |      |      |              |          |
                 |      |   3  |  +-------------------+  |
                 |      |------+->|      Service      |  |
                 |      |<-----+--|     Equipment     |  |
                 |      |   4  |  +-------------------+  |
                 +------+      |                         |
                               +-------------------------+

   Figure 15: Accounting and Push Sequence

8.4 Roaming

   If the provisioning of the service and the final authentication/
   authorization process is done by different organizations, accounting
   is rather coupled to the service provisioning process than to the
   authentication/authorization process. Since the data doesn't have to
   traverse the home providers network, the home provider has no
   possibility to collect data about the resource consumption.
   Therefore accounting will usually take place in the foreign provider
   domain (i.e. in the domain that does the service provisioning).
   Nevertheless, in order to ensure consistency of the authentication,
   authorization and accounting processes (e.g. allocation of user IDs
   to accounting records) and to produce a bill a connection between
   the accounting process in the service provisioning domain and the
   deciding authentication/authorization process (e.g. at the home
   provider) is needed.

   A possibility to do this is that the foreign provider gets the
   accounting policies from the home provider and sets up the
   accounting architecture in accordance to the given policies. The
   foreign provider generates accounting records and sends them back to
   the home provider. The home provider then can apply charging and can
   produce a bill. An example for this is given in section 9.2.



Carle, Zander, Zseby        Expires September 2001            [Page 21]


Internet Draft             Policy-based Accounting          March 2001


9. Examples

9.1 Printing Service Example

   The Internet Printing Protocol (IPP) [4], and especially the "print-
   by-reference" model, provides a very interesting example scenario
   for accounting and the interaction between authorization and
   accounting. We will describe possible solutions for the accounting
   of this service and how the accounting is triggered by the
   authorization. We will show how the model presented above can be
   used for this example.

   IPP "print-by-reference" allows a user to request a print service to
   print a particular file. The file to be printed is not on the client
   system but rather on a public server. That is, the clients print
   request can contain a reference, or pointer, to the document instead
   of the actual document itself. The print service must then read the
   file to a file server (used for spooling) prior to the printing.
   There are two possible setups: The file and print server either
   belong to a single organization (Intra-Domain Accounting) or to two
   different organizations (Inter-Domain Accounting). In the first case
   the user must be authorized by a single service provider for service
   usage. In the second case two different possibilities for
   establishing a trust relationships between the involved entities
   have to be distinguished [6].

9.1.1   Intra-Domain Accounting

   In the case of a single organization the file and print service is
   provided by a single service provider. The service subscriber and
   user role are either one entity (e.g. private home user) or
   different entities (e.g. company as subscriber, employee as user).
   For data transport via the underlying network the transportation
   service of a network provider is used. In this case the AAA Server
   of the provider controls both the file and the print server. This
   means the AAA server enforces the accounting policies and collects
   accounting data for both servers.

9.1.2   Inter-Domain Accounting

   If two different organizations are involved there are two
   possibilities for trust relationships as shown in [6]:

   1. The User has an agreement with the Print Server; the print
      server has an agreement with the file server.
   2. The user has agreements with both print and file server.

   In case 1, the user is first authorized by the print service and the
   request is forwarded to the file server. The file server authorizes
   the print server and determines if the printer is allowed to access
   the file. In this case the accounting policies from the user arrive
   at the print service AAA server. The print service AAA server has to
   decide which policies can be enforced locally and which must be

Carle, Zander, Zseby        Expires September 2001            [Page 22]


Internet Draft             Policy-based Accounting          March 2001


   passed further to the file service AAA server. The print service can
   add additional accounting policies. In case the file server does not
   support the desired accounting policies the print server must notify
   the users AAA server and some policy conflict resolution must occur.
   After the file server has transferred the file to the print service
   it generates an accounting record according to the accounting policy
   and gives it to the print service. The print service generates the
   final accounting record for the service session based on his own and
   the file service data after finishing printing. This record will be
   used for the later billing process. Additionally the print server
   can send the final record to the users AAA server. There it can be
   used for later authorization decisions based on used resources i.e.
   if the customer is a company and the user is an employee.

    USER DOMAIN     PRINT SERVICE DOMAIN         FILE SERVICE DOMAIN

                |                            |
     +------+   |                            |
     |      |   |                            |
     |      |   |                            |
     |      |   |   +--------------------+   |   +-------------------+
     | User |---1-->| Print Service      |---1-->| File Service      |
     |      |<--2---| AAA Server         |<--2---| AAA Server        |
     |      |   |   +--------------------+   |   +-------------------+
     |      |   |   | Print Server       |   |   | File Server       |
     |      |   |   |  and Printer       |   |   |                   |
     +------+   |   +--------------------+   |   +-------------------+

     1: AccPolInd
     2: AccPolConf

   Figure 16: Inter-Domain Accounting and Printing Service

   In case 2, the customer AAA server has an agreement with file and
   print server. In this case the users AAA server sends accounting
   policies to the file and the print server. After finishing the
   service both servers generate accounting records for the delivered
   services which are used for later billing. As in the former case the
   accounting data can be send to the user AAA server for use in later
   authorization decisions. The user AAA server can tie both accounting
   records together and assign them to the user using audited session
   information (authorization and accounting messages for a particular
   session could be coupled via a session id) and policies which define
   what activities a certain session is composed of.

9.1.3   User Accounting Indication

   For the printing service there are a number of possible options for
   sending accounting indications to the user. Accounting indications
   gives the user an indication on how much resources have been used
   until the time of the indication. A user can receive accounting
   indications or not depending on the accounting policy for the user.


Carle, Zander, Zseby        Expires September 2001            [Page 23]


Internet Draft             Policy-based Accounting          March 2001


   For Internet printing with the "print-by-reference" model such
   indications would be very helpful for the user. Since the file is
   not on the clients site the user might not have information on the
   file size or the number of pages that will be printed. This means
   the user has no idea of the costs of the service usage. If user and
   subscriber are a single entity accounting indications would help the
   user to avoid exceeding his spending limit. Additional accounting
   indications give the user a hint what resource usage has caused the
   charges. This can be compared to an itemized telephony bill where
   not only the monetary sum per month is printed but in addition
   information for every call (start time, duration, distance etc.) and
   the corresponding amount of money.

9.2 Mobile/Roaming Example

   In this section the "Dial-in with Roaming" example from the
   authorization examples draft [6] is used to show how accounting
   functions could interact with authorization functions. It gives just
   one example from a variety of possibilities. The accounting modules
   (e.g. collectors and meters) are seen here as part of the service
   equipment which is in this example located at the visited ISP
   premises. The basis configuration of the accounting modules would be
   probably done by the visited ISP itself, but the visited ISP can
   allow the home ISP to influence certain parameters (like report
   interval or accounting record format). This is useful if the home
   provider generates the invoice and therefore needs appropriate
   accounting records to calculate the prices.

   The exchange of authorization data corresponds to the example in the
   draft [6]. As an additional component we introduce an ASM between
   home AAA and service equipment for the conversion of the service
   parameters to the appropriate configuration information.
   Steps (1), (2) and (3) describe the forwarding of an
   authentication/authorization request from the user via the AAA sever
   of the visited ISP to the home AAA server. In step (4) service
   parameters are given to the visited ISP's AAA server and are
   forwarded to the service equipment (5). The service parameters could
   additionally include the desired policies for the configuration of
   the accounting infrastructure of the visited ISP. An accounting
   policy could be for instance "for user X one accounting record of
   type x has to be generated all 30 seconds " This accounting policy
   is used by the visited ISP to configure his modules (e.g. metering,
   data collection).











Carle, Zander, Zseby        Expires September 2001            [Page 24]


Internet Draft             Policy-based Accounting          March 2001






      User |         Visited ISP           |        Home  ISP
           |                               |
           |                               |  +-----------+  ..........
    <--------------------12----------------|  | Charging, |<-:charging:
           |                               |  | Billing   |  :policies:
           |                               |  +-----------+  :........:
           |                               |        ^
           |                               |        |
           |                               |  +-----------+
           |                               |  |    ASM    |
           |                               |  +-----------+
           |                               |        ^
           |                               |        |11
           |                               |        |
           |          +------------+       |  +-------------+
           |          |            |       |  |             |
           |          |            |---10---->|             |
           |          |            |       |  |             |
           |   AR's   | AAAF Server|----3---->| AAAH Server |
    <-----------------|            |<---4-----|             |
           |          |            |       |  |             |
           |          |            |       |  |             |
           |          +------------+       |  +-------------+
           |           ^  |      ^         |
           |           |  |      |         |
           |           |  5      9         |
           |           |  |      |         |
           |           |  V      |         |
           |           | +----------------+|
           |           | |     ASM        ||
           |           2 |                ||
           |           | +----------------+|
           |           |  |      ^         |
           |           |  |      |         |
           |           |  6      8         |
           |           |  |      |         |
           | +------------+------+-------+ |
        7  | |  Service   |      |       | |
    <--------| Equipment  |  +----------+| |
        1  | |            |->|Accounting|| |
    -------->|            |  +----------+| |
           | |     config |      |       | |
           | |            |  +---------+ | |
           | |            +->| Meters  | | |
           | |               +---------+ | |
           | +---------------------------+ |
           |                               |

   Figure 17: Roaming Example

Carle, Zander, Zseby        Expires September 2001            [Page 25]


Internet Draft             Policy-based Accounting          March 2001




   Service parameters are converted by the ASM into the appropriate
   configuration information (6). Then  the user is informed about the
   completed authentication/authorization process (7). The accounting
   architecture starts metering the resource usage and sends metering
   records to the ASM (8). The ASM uses the metered data to fill the
   required accounting records and sends them to the visited ISP's AAA
   server (9). The visited ISP can either post-process the data or
   directly forward them to the home ISP (10). With this data as input
   an invoice is generated by the charging and billing modules within
   the home providers domain (11) by using charging policies (tariff
   formulas) and then sent to the user/customer (12).

   As an additional option accounting records can be offered also to
   the user (accounting indication) as a special service. For this
   special service a separate authorization is required.

9.3 Diffserv Example

   This example explains how integrated accounting is configured via
   policies for a Diffserv service. The service is the transport of
   packets with a higher priority and the service includes accounting
   and QoS auditing.  shows the service setup. The user issues a
   Service Request (SR) for a Diffserv service to the AAA server. The
   request contains a user ID and the parameter for the desired service
   class.

   User->AAA: user-x@nw-a, service=diffserv, class=gold,
              amount=2Mbit, dest= nw-b

   In this example user-x is located at network A (nw-a) and requests a
   gold class service for all flows from this network to the
   destination network B (nw-b). After authentication and authorization
   has completed successfully, the AAA server extracts the Application
   Specific Information (ASI) from the request and passes them to the
   ASM of the Diffserv service.

   AAA->ASM: service=diffserv, class=gold, amount=2Mbit, src=nw-a
             dest=nw-b

   The ASM takes over the task of translating the application specific
   information into appropriate configuration information for the
   service equipment. For the given Diffserv example the service
   equipment consists of three components: accounting equipment, the
   QoS auditing equipment and the bandwidth broker architecture. The
   ASM has to address all three components to set up the requested
   service. The translation of the ASI into configuration information
   for the components can be done by evaluating service provisioning
   policies. As example the ASM could have the following service
   provisioning policy:



Carle, Zander, Zseby        Expires September 2001            [Page 26]


Internet Draft             Policy-based Accounting          March 2001






        if class==gold {
          set bw-request.class = gold
          set accounting.type = comprehensive
          set qos-audit.metric = one-way-delay
          ...
        }

   This results in sending a bandwidth request to the BB which asks for
   a gold service with the given parameters. Furthermore the ASM issues
   a request to the accounting equipment for comprehensive accounting
   and a request to the QoS auditing equipment for a one-way-delay
   measurement between the given networks.

   ASM->BB: BW-request(gold, src=nw-a, dest=nw-b, amount=2Mbit)

   ASM->Acct: Acct-request(comprehensive, src=nw-a)

   ASM->QoS: QoS-audit-request(one-way-delay, src=nw-a, dest=nw-b)

   The bandwidth broker then sets up the Diffserv infrastructure to
   provide the prioritized forwarding. This is done in accordance to
   the used bandwidth broker architecture and not further considered
   here. For the Accounting Configuration and the QoS Audit Control
   local configuration policies exists for setting up the service.

   Accounting-Policy:
               if type==comprehensive {
                 set meter-location = access-point(nw-a)
                 set record type =detailed
                  set report interval = 120 s
                  set report target = 193.175.12.8
                }

   QoS-Measurement-Policy:
               if metric==one-way-delay {
                 set method = passive
                 set timestampsize = 16 bit
                 set ingress-meter-location = access-point(nw-a)
                 set egress-meter-location = access-point(nw-b)
                  }

   In this case the local accounting policy sets the meter location to
   the network access point of network A. It states that for a
   comprehensive accounting a detailed record type is required with an
   report interval of 120 ms. The resulting records have to be sent to
   the given report target. The QoS measurement policy sets the
   measurement method to passive measurement. It sets the size used for
   timestamp representation to 16 bit. As meter locations the meters at
   the access points of network A and network B are used.

Carle, Zander, Zseby        Expires September 2001            [Page 27]


Internet Draft             Policy-based Accounting          March 2001



   After evaluating these policies the instructions for the meter
   configuration are passed down to the measurement infrastructure. In
   our example the accounting configuration instructs the meter at the
   first measurement point (MP1) to add a new rule with the given flow
   attributes and settings for storage and reporting of results.

   Acct->MI: MP1: add rule dscp=23, src=a.a.a/24, dest=b.b.b.b/24
                  save volume
                  set report interval = 120 s
                  set report target = 193.175.12.8

   The QoS audit control instructs two meters (at MP1 and MP2) to set
   up a passive one-way-delay measurement.

   QoS->MI: MP1: add rule dscp=23, src=a.a.a.a/24 dest=b.b.b.b/24,
                 save timestamp-16
            MP2: add rule dscp=23, src=a.a.a.a/24, dest=b.b.b.b/24,
                 save timestamp-16


              SR          +-------+
   User ----------------->|  AAA  |
                          +-------+
                              |
                              | ASI
                              V
                          +-------+
        +-----------------|  ASM  |--------------+--------------+
        |       Policy    +-------+  Policy      |   BW Request |
        |       Parameters           Parameters  |              |
        |                                        |              |
   -----|----------------------------------------|--------------|-----
        |       Service Equipment                |              |
        V                                        V              V
   +---------------+    ..............    +-----------+   +-----------+
   | Accounting    |<-->: Local      :<-->| QoS       |   | Bandwidth |
   |               |    : Policies   :    | Auditing  |   | Broker    |
   +---------------+    :............:    +-----------+   +-----------+
        |                                        |
        | Meter Instructions                     | Measurement Setup
        V                                        V
   +--------------------------------------------------+
   |  Measurement                                     |
   |  Infrastructure                                  |
   +--------------------------------------------------+

   Figure 19: Diffserv Service Provision Setup

9.4 User Accounting Indication Example

   This example explains how discrete accounting can be used to provide
   accounting indications for the user. Accounting indications are sent

Carle, Zander, Zseby        Expires September 2001            [Page 28]


Internet Draft             Policy-based Accounting          March 2001


   to the user in order to inform the user about the current resource
   consumption. The accounting indication is a special accounting
   service that can be provided in addition to the standard accounting
   performed by the provider. Like for any other service an
   authorization should take place before the accounting indication
   service provisioning. Therefore the accounting here is seen as a
   separate service. That means the accounting service is independent
   of the main service and therefore can be applied to different
   services. It might be used as an addition to an integrated standard
   accounting that is part of the service. Like other services, an
   accounting service has to be authorized prior to the service
   provisioning. The authorization process is out of the scope of this
   document and therefore not further explained here.

   Figure 21 illustrates the configuration message sequence for setting
   up the accounting service. First the user sends an Accounting
   Service Request (ASR) to the AAA server which includes desired
   parameters for the provisioning of the accounting service (e.g.
   report interval).

   user->AAA: user-x@nw-a, service= accounting indications,
              report interval= 60 s

   The AAA server passes the Application Specific Information (ASI) to
   the ASM of the accounting service after the user has been
   authenticated and authorized for the service usage.

   AAA->ASM: user-x@nw-a, service=accounting indications,
             report interval= 60 s


              ASR       +-------+
   User --------------->|  AAA  |
                        +-------+
                            |
                            | ASI
                            V
                        +-------+
                        |  ASM  |
                        +-------+
                            |
   -------------------------|---------------------------
   Service Equipment        | Accounting Policy
                            V
                    +-----------------+      ..............
                    |  Accounting     |<---->: Local Acct :
                    |                 |      : Policies   :
                    +-----------------+      :............:
                            |
                            | Meter Instructions
                            V
                    +-----------------+
                    |  Measurement    |

Carle, Zander, Zseby        Expires September 2001            [Page 29]


Internet Draft             Policy-based Accounting          March 2001


                    |  Infrastructure |
                    +-----------------+

   Figure 21: Accounting Indication Configuration

   The ASM generates an accounting policy based on the ASI and passes
   this policy to the Accounting Configuration.

   ASM->Acct: If src=a.a.a.x {
                acc-indication = on
                report interval = 60s
                report target= a.a.a.x
              }

   The Accounting Configuration generates meter instructions according
   to the accounting policies from the ASM and local accounting
   policies and passes them to the measurement infrastructure.

   local Acct-Policy: if acc-indication {
                       record type = compact
                      }

   Acct->MI: MP1: set report interval = 60 s
                  add report target = a.a.a.x

10.    Security Considerations

   Accounting services provide the basis for billing. Therefore the
   incentives (mainly saving money) and potential for fraud is
   extremely high in the field of configuration of the accounting
   architecture and the collection of accounting data.

   In the presented framework two types of data communications are
   required, the exchange of accounting policies and the collection of
   accounting records. Both communications introduces potential
   security hazards. The main hazard is that users try to forge
   accounting data in a way that the final bill shows a lower charge
   than actually occurred. This can be done indirectly by modifying the
   accounting policies or directly by altering accounting records.

   The following potential security hazards can be identified:

   - Forgery of accounting policies and accounting record information
   Both accounting policies and accounting records can be the target
   for information forgery. Accounting policies contain configuration
   information. Modifying this information can lead to a mal-configured
   accounting and metering system which either allows data to traverse
   the accounting system undetected (without being counted) (e.g. by
   changing the classification rules of a meter) or produces bogus
   accounting records. Accounting records contain data about the
   resource consumption and provide the basis for billing. Modifying
   accounting records leads to erroneous bills. Furthermore it should


Carle, Zander, Zseby        Expires September 2001            [Page 30]


Internet Draft             Policy-based Accounting          March 2001


   be prevented that policies or accounting records are redirected or
   removed or forged policies or records are inserted.



   - Eavesdropping
   It might be desired to keep accounting policies and accounting
   records confidential between the involved parties.

   - Denial of Service (DoS) attacks
   Both the AAA server and the accounting/metering subsystem can be the
   target of denial of service attacks. A denial of service attack
   against the AAA server may lead to malfunction and even breakdown of
   the server. This means the server will not be able to provide proper
   authentication, authorization and accounting functionality. The
   service provided by the AAA server will become unavailable or
   unusable. Especially if multiple services use one AAA server an
   attack to the server can be worse than an attack to the service
   equipment itself. An attack against the accounting/metering system
   will cause loss of metering data and/or loss of accounting records.

   This leads to the following security requirements:

   - Secrecy of accounting policies and accounting data
   Unauthorized entities should not be able to read or modify
   accounting policies or accounting records. This can be achieved with
   standard encryption methods.

   - Authentication of accounting data and accounting policy sources
   It should be ensured that the data is originated by the original
   source. Source-authentication can be achieved by using digital
   signatures.

   - Protection of the integrity of accounting policies and accounting
   records
   It should be ensured that the data was not modified on the way from
   sender to receiver. Data-authentication can also be achieved with
   digital signatures.

   - Verify correctness of generated accounting data
   It must be ensured that the accounting data generated by the service
   provider is correct. A provider may generate incorrect accounting
   records either deliberately (i.e. forging) or unintentionally (e.g.
   faulty configuration). These incorrect accounting records probably
   have the consequence of incorrect bills. A customer can verify the
   correctness of the accounting data through own measurements and/or
   through data collected by a trusted third party. A trusted third
   party can be an independent accounting service provider as described
   in section 7.2 or a more general entity providing an auditing
   service.

   - Prevention and protection against Denial of Service attacks


Carle, Zander, Zseby        Expires September 2001            [Page 31]


Internet Draft             Policy-based Accounting          March 2001


   The AAA protocol and all building blocks should be designed and
   implemented in a way most resistant to denial of service attacks.
   Furthermore a component can be added to the meter system which is
   able to detect an unusual high packet rate. Upon detection further
   actions can be taken according to a defined policy.

   The prevention of these hazards is one requirement for the protocols
   used for accounting policy exchange and the transportation of
   accounting records. Since the needed security requirements
   (authentication, transmission level security, data object
   confidentiality and integrity) are addressed in the criteria for AAA
   protocol evaluation [7] we assume that the future AAA protocol(s)
   will be suited for secure accounting record transfer and probably
   also for secure accounting policy transport. Furthermore we assume
   that existing or upcoming solutions for secure transportation and
   enforcement of policies can be used.

11.    References

   [1]     J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross,
           B. de Bruijn, C. de Laat, M. Holdrege, D. Spence, "AAA
           Authorization Framework", Informational RFC 2904, August
           2000.

   [2]     Bernard Aboba, Jari Arkko, David Harrington, "Introduction
           to Accounting Management", Informational RFC 2975, October
           2000.

   [3]     C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence,
           "Generic AAA Architecture", Experimental RFC 2903, August
           2000.

   [4]     Roger deBry, "Internet Printing Protocol/1.0: Model and
           Semantics", RFC 2566, April 1999.

   [5]     Nevil Brownlee, Alan Blount, "Accounting Attributes and
           Record Formats", Informational RFC 2924, September 2000.

   [6]     J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross,
           B. de Bruijn, C. de Laat, M. Holdrege, D. Spence, et al,
           "AAA Authorization Application Examples", Informational RFC
           2905, August 2000.

   [7]     Bernard Aboba, et al, "Criteria for Evaluating AAA Protocols
           for Network Access, draft-ietf-aaa-na-reqts-07.txt, Work in
           Progress, August 2000

12.    Acknowledgments

   The authors would like to thank the members of the AAAARCH research
   group for the fruitful discussions and comments.



Carle, Zander, Zseby        Expires September 2001            [Page 32]


Internet Draft             Policy-based Accounting          March 2001


13.    Author's Addresses

   Georg Carle
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany
   Phone: +49-30-34 63 7149
   Email: carle@fokus.gmd.de

   Sebastian Zander
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany
   Phone: +49-30-34 63 7287
   Email: zander@fokus.gmd.de

   Tanja Zseby
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany
   Phone: +49-30-34 63 7153
   Email: zseby@fokus.gmd.de

14.    Full Copyright Statement

   Copyright (C) The Internet Society (2000). All Rights Reserved. This
   document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Carle, Zander, Zseby        Expires September 2001            [Page 33]