[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09

INTERNET DRAFT                                                Jari Arkko
Category: Standards Track                              Oy LM Ericsson Ab
Title: draft-calhoun-diameter-accounting-08.txt           Pat R. Calhoun
Date: September 2000                               Sun Microsystems, Inc.
                                                            Pankaj Patel
                                                   Convergys Corporation
                                                               Glen Zorn
                                                     Cisco Systems, Inc.


                     DIAMETER Accounting Extension



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.

   This document is an individual contribution for consideration by the
   AAA Working Group of the Internet Engineering Task Force.  Comments
   should be submitted to the diameter@diameter.org mailing list.

   Distribution of this memo is unlimited.

   Copyright   (C) The Internet Society 1999.  All Rights Reserved.









Arkko et al.               expires March 2001                   [Page 1]


INTERNET DRAFT                                            September 2000


Abstract

   The DIAMETER protocol provides Authentication and Authorization for
   network access technologies, such as NASREQ, ROAMOPS and Mobile IP.
   The ROAMOPS WG has been working on an accounting data format, called
   Accounting Data Interchange Format (ADIF), as a method to transfer
   accounting information over a wide variety of transports.

   This extension describes how accounting records can be securely
   transmitted over the DIAMETER protocol. When combined with the
   Strong Security extension, accounting records MAY traverse
   intermediate proxies in a secure fashion and is compatible with
   the referral broker model. This extension allows for both
   real-time and batched accounting transfers.


Table of Contents

      1.0  Introduction
            1.1  Requirements language
            1.2  Authorization-Server Directed Model
            1.3  Protocol Messages
            1.4  Fault Resilience
            1.5  Session Records
            1.6  Accounting in brokering environments
      2.0  Command-Codes Values
            2.1  Accounting-Request (ACR) Command
            2.2  Accounting-Answer (ACA) Command
            2.3  Accounting-Poll-Ind (ACP) Command
            2.4  Accounting-Status-Ind (ASI) Command
      3.0  Mandatory AVPs
            3.1  Accounting-Record-Type AVP
            3.2  ADIF-Record AVP
            3.3  Accounting-Interim-Interval AVP
            3.4  Accounting-Delivery-Max-Batch AVP
            3.5  Accounting-Delivery-Max-Delay AVP
            3.6  Accounting-Record-Number AVP
            3.7  Accounting-State AVP
      4.0  IANA Considerations
      5.0  Security Considerations
      6.0  Acknowledgments
      7.0  References
      8.0  Authors' Addresses
      9.0  Full Copyright Statement







Arkko et al.               expires March 2001                   [Page 2]


INTERNET DRAFT                                            September 2000


1.0  Introduction

   This accounting protocol is based on an authorization-server directed
   model with capabilities for both efficient batch and fast real-time
   delivery of accounting information. Several fault resilience methods
   [11] have been built in to the protocol in order minimize loss of
   accounting data in various fault situations and under different
   assumptions about the capabilities of the used devices.


1.1  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [6].


1.2  Authorization-Server Directed Model

   The authorization-server directed model means that at authorization
   time, the device generating the accounting data gets information from
   the authorization server regarding the way accounting data shall be
   forwarded. This information includes accounting record timeliness
   requirements.

   As discussed in [11], batch transfer of accounting data is more CPU-
   and bandwidth efficient than real-time transfer.  However, there are
   many applications where real-time transfer is a requirement for at
   least some of the accounting records.  These applications include
   roaming, where most (local) accounting records can be transferred in
   batch mode, but roaming (visiting) accounting records should be
   transferred fast due to the needs of credit limit checks and fraud
   detection. For these reasons this accounting protocol defines both
   batch and real-time transfer modes, and allows their use
   simultaneously. The authorization server (chain) directs the
   selection of proper transfer strategy, based on its knowledge of the
   user and relationships of roaming partnerships. The server (or
   proxies in between) use the Accounting-Delivery-Max-Batch,
   Accounting-Delivery-Max-Delay, and Accounting-Interim-Interval AVPs
   to control the operation of the DIAMETER peer operating as a client.
   The first two AVPs set the requirements in terms of number of records
   and maximum delay before accounting data transfer for this session
   SHOULD begin. The DIAMETER peer acting as a client MAY deliver the
   data earlier due to a full batch of records, device reboot, lack of
   memory, or explicit configuration. The DIAMETER client MUST begin the
   transfer in the given limits unless prevented from doing so by
   network partitions, failures of peers, network congestion, or client
   overload.



Arkko et al.               expires March 2001                   [Page 3]


INTERNET DRAFT                                            September 2000


   The Accounting-Interim-Interval AVP, when present, instructs the
   DIAMETER node acting as a client to produce accounting records
   continuously even during a session.

   Typically, the authorization server uses a few batching/real-time
   classes, such as the local users whose data might be transferred once
   in an hour and the roaming users whose data would be transferred
   immediately. Each Accounting-Delivery-Max-Batch / Accounting-
   Delivery-Max-Delay AVP pair with different values forms one pool of
   accounting data in the DIAMETER node acting as a client.  That is, a
   new record is placed to same pool as the previous one if the
   authorization server returned same values for both AVPs and the pool
   has not been emptied in between.

   The Extension number for this draft is five (5). This value is used
   in the Extension-Id Attribute value Pair (AVP) as defined in [1].

1.3  Protocol Messages

   The DIAMETER peer, acting as a client, generating the accounting data
   will use the Accounting-Request message to send one or more
   accounting records to its peer. The receiver (server) MUST reply with
   the Accounting-Answer message with appropriate confirmations.

   It is possible that a DIAMETER Proxy breaks up a batch of accounting
   records and sends them towards different DIAMETER Home servers. In
   this case, it is possible that a separate Accounting-Answer message
   contain the response for each block.  Therefore, a DIAMETER node MUST
   be prepared to handle this scenario.

   Upon receipt of an Accounting-Request, a home DIAMETER server MUST
   generate a response. A home server is the node that "owns" the realm
   portion of the user's NAI. The response includes the Result-Code,
   which MAY contain an error if the ADIF-Record, or some other AVP, is
   not acceptable.

   Each DIAMETER Accounting protocol message MAY be compressed using
   IPComp [12] in order to reduce the used network bandwidth.  DIAMETER
   peers MUST use a negotiation mechanisms such as IKE [7] in order to
   ensure that both peers are able to handle IPComp.


1.4  Fault Resilience

   DIAMETER Base protocol [11] mechanisms are used to overcome small
   message loss and network faults of temporary nature.

   DIAMETER peers acting as clients MUST implement the use of alternate



Arkko et al.               expires March 2001                   [Page 4]


INTERNET DRAFT                                            September 2000


   servers to guard against server failures and certain network
   failures. DIAMETER peers acting as servers or related off-line
   processing systems MUST detect duplicate accounting records caused by
   the sending of same record to several servers and duplication of
   messages in transit. This detection MUST be based on the inspection
   of the Session-Id [1] and Accounting-Record-Number AVP pairs.

   DIAMETER clients MAY have non-volatile memory for the safe storage of
   accounting records over reboots or extended network failures, network
   partitions, and server failures.  If such memory is available the
   client SHOULD store new accounting records there as soon as the
   records are created and until a positive acknowledgement of their
   reception from the DIAMETER Server has been received. Upon a reboot,
   the client MUST starting sending the records in the non-volatile
   memory to the accounting server with appropriate modifications in
   termination cause, session length, and other relevant information in
   the records.

   A further extension of this protocol may include AVPs to control how
   many accounting records may at most be stored in the DIAMETER client
   without committing them to the non-volatile memory or transferring
   them to the DIAMETER server.

   The client SHOULD NOT remove the accounting data from any of its
   memory areas before the correct Accounting-Answer has been received.
   The client MAY remove oldest, undelivered or yet unacknowledged
   accounting data if it runs out of resources such as memory. It is an
   implementation dependent matter for the client to accept new sessions
   under this condition.


1.5  Session Records

   In all accounting records the Session-Id AVP, ADIF-Record AVP, and
   User-Name AVPs MUST be present. If strong authentication is required,
   as described in [9], the CMS-Data AVP may be used to authenticate the
   ADIF-Record AVP. It is not typically necessary, nor recommended, that
   the strong authentication cover any additional AVPs since the ADIF-
   Record, and associated CMS-Data, MAY need to be submitted to a third
   party (see section 1.6 below).

   However, if the accounting records are being in sent in batch mode,
   the sender can create several "blocks" of accounting records by
   encapsulating each "block" within a separate Grouped-AVP AVP, each
   with an optional CMS-Data AVP [9]. If it is known that multiple
   ADIF-Records are being sent to the same home DIAMETER server, it is
   possible to have one CMS-Data AVP cover multiple the ADIF-Records.
   This optimization reduces the crypto computation that would otherwise



Arkko et al.               expires March 2001                   [Page 5]


INTERNET DRAFT                                            September 2000


   be necessary.

   Different types of session records are sent depending on the actual
   type of accounted service and the authorization server's directions
   for interim accounting. If the accounted service is a one-time event,
   meaning that the start and stop of the event are simultaneous, then
   the Accounting-Record-Type AVP MUST be present and set to the value
   EVENT_RECORD.

   If the accounted service is of a measurable length, then the AVP MUST
   use the values START_RECORD, STOP_RECORD, and possibly,
   INTERIM_RECORD.  If the authorization server has directed interim
   accounting to be enabled for the session, but no interim interval was
   specified, two accounting records MUST be generated for each service
   of type session.  When the initial Accounting-Request is sent for a
   given session is sent, the Accounting-Record-Type AVP MUST be set to
   the value START_RECORD. When the last Accounting-Request is sent, the
   value MUST be STOP_RECORD.

   If a specified interim interval exists, the DIAMETER client MUST
   produce additional records between the START_RECORD and STOP_RECORD,
   marked INTERIM_RECORD. The production of these records is directed
   both by Accounting-Interim-Interval as well as any re-authentication
   or re-authorization of the session.  If a batch size of greater than
   1 has been specified by the authorization server, then the DIAMETER
   client MUST ensure that new interim records overwrite previous
   interim records for the same session and batch as this reduces the
   amount of memory required to store the records. In effect, this means
   that interim records are delivered at least as often as dictated by
   Accounting-Delivery-Max-Delay.


1.6  Accounting in brokering environments

   The DIAMETER base protocol [1] describes brokers that provide
   redirect services, by allowing AAA servers within a roaming
   consortium to directly communicate. Referral services can be secured
   using the strong security extension defined in [9]. Since brokers can
   also provide settlement services, they typically need to be aware of
   the accounting information exchange, and since they are no longer
   part of the message exchange, the DIAMETER protocol MUST allow the
   broker to receive the accounting record.  The strong security [9]
   provides the broker with the assurances it needs that both parties
   agreed with the accounting information submitted.

   When the local AAA server issues an Accounting-Request to the home
   AAA server, it includes an ADIF-Record AVP as well as a CMS-Data AVP
   [9], which contains the signature of the local AAA server. The home



Arkko et al.               expires March 2001                   [Page 6]


INTERNET DRAFT                                            September 2000


   server MUST add it's own signature to the CMS-Data AVP, that covers
   both the ADIF-Record and the local AAA's signature. The whole is
   submitted to the local AAA server in the Accounting-Answer. The local
   AAA server MUST submit the ADIF-Record, and associated CMS-Data AVP
   to the broker.  The broker can verify that both parties participated
   and accepted the accounting record, by validating the signatures.


2.0  Command-Codes Values

   This section defines new Command-Code [1] values that MUST be
   supported by all DIAMETER implementations that conform to this
   specification. The following Command Codes are currently defined in
   this document:

      Command-Name             Abbrev.    Code       Reference
      --------------------------------------------------------
      Accounting-Request        ACR       271           2.1
      Accounting-Answer         ACA       272           2.2
      Accounting-Poll-Ind       ACP       273           2.3
      Accounting-Status-Ind     ASI       279           2.4



2.1  Accounting-Request (ACR) Command

   The Accounting-Request command, indicated by the Command-Code field
   set to 271, is sent by a DIAMETER node, acting as a client, in order
   to exchange accounting information with a peer. The Accounting
   information is contained within an ADIF record, as described in [10].

   The Accounting-Request command MAY contain accounting information for
   more than a single session, which allows it to send batched
   accounting information. When the batch mode is used, the session-Id
   AVP [1], the ADIF-Record AVP and the optional CMS-Data AVP [9] MUST
   be encapsulated within a Grouped-AVP AVP [1]. When the Accounting-
   Request is being submitted to a broker, and includes the CMS-Data AVP
   [9], the CMS-Data AVP MUST be signed by both the local and home
   DIAMETER server using the countersignature procedures described in
   [9].











Arkko et al.               expires March 2001                   [Page 7]


INTERNET DRAFT                                            September 2000


   Message Format

      <Accounting-Request> ::= <DIAMETER Header, Command-Code = 271>
                               <Host-Name AVP>
                               <Grouped-AVP {
                                   <Session-Id AVP> &&
                                   <Accounting-Record-Type> &&
                                   <Accounting-Record-Number> &&
                                   <User-Name AVP> &&
                                   <ADIF-Record AVP> &&
                                   <CMS-Data AVP>
                               }
                               [<Timestamp AVP>
                                <Nonce AVP>
                                <Integrity-Check-Value AVP>]


2.2  Accounting-Answer (ACA) Command

   The Accounting-Answer command, indicated by the Command-Code field
   set to 272, is used to acknowledge an Accounting-Request command. The
   Accounting-Answer command contains the same Session-Id and ADIF-
   Record AVPs that were sent in the Accounting-Request command. If the
   CMS-Data AVP was present in the Accounting-Request, the corresponding
   ACA message MUST include the CMS-Data AVP signed by the responder to
   provide strong AVP authentication, which MAY be used for the purposes
   of repudiation.

   Only the target DIAMETER Server, known as the home DIAMETER Server,
   SHOULD respond with the Accounting-Answer command. However, if a
   DIAMETER node in the proxy chain stores the accounting records for
   submission to the home network in batched mode, it MUST respond to
   the request.

   If the Accounting-Request command contained more than one ADIF-Record
   AVP, the Accounting-Answer SHOULD contain the same number of ADIF-
   Record AVPs. However, it is possible for the DIAMETER Server to
   acknowledge each ADIF-Record in a separate response. This allows the
   sender of the ADIF-Records to send a batch of records, whose final
   destination are different.











Arkko et al.               expires March 2001                   [Page 8]


INTERNET DRAFT                                            September 2000


   Message Format

      <Accounting-Answer> ::= <DIAMETER Header, Command-Code = 272>
                              <Result-Code AVP>
                              <Host-Name AVP>
                              <Destination-NAI AVP>
                              <Grouped-AVP {
                                  <Session-Id AVP> &&
                                  <Accounting-Record-Number> &&
                                  <ADIF-Record AVP> &&
                                  <CMS-Data AVP>
                              }
                              [<Timestamp AVP>
                               <Nonce AVP>
                               <Integrity-Check-Value AVP>]


2.3  Accounting-Poll-Ind (ACP) Command

   The Accounting-Poll-Ind command, indicated by the Command-Code field
   set to 273, is sent by a DIAMETER Server in order to force the peer
   to send current accounting data. This data MUST include not yet sent
   accounting records from completed sessions, as well as INTERIM_RECORD
   records from all ongoing sessions.

   The receiver MUST use the Accounting-Request command to send the
   accounting data.

   The use of Accounting-Poll-Ind is useful in situations where a
   DIAMETER server comes up after an unscheduled downtime, and wishes to
   synchronize with the client(s) sooner than at the end of the next
   INTERIM_RECORD or at the end of a session.

   Warning: The use of the Accounting-Poll-Ind message is discouraged in
   roaming networks, since it is unfeasible for a server to attempt to
   poll all of it's roaming partner's DIAMETER peers.

   Message Format

      <Accounting-Poll-Ind> ::= <DIAMETER Header, Command-Code = 273>
                                <Host-Name AVP>
                                <Destination-NAI AVP>
                                [<Timestamp AVP>
                                 <Nonce AVP>
                                 <Integrity-Check-Value AVP>]


2.4  Accounting-Status-Ind (ASI) Command



Arkko et al.               expires March 2001                   [Page 9]


INTERNET DRAFT                                            September 2000


   The Accounting-Status-Ind command, indicated by the Command-Code
   field set to 279, is sent by a DIAMETER node in order to inform its
   peer of whether Accounting messages will be sent in the future. A
   DIAMETER node that is about to be taken out of service SHOULD issue
   an Accounting-Status-Ind message, with the Accounting-State AVP set
   to DISABLED. A DIAMETER node that detected that it is able to issue
   Accounting messages MUST issue an Accounting-Status-Ind message, with
   the Accounting-State AVP set to ENABLED.

   Message Format

      <Accounting-Status-Ind> ::= <DIAMETER Header, Command-Code = 279>
                                  <Host-Name AVP>
                                  [<Destination-NAI AVP>]
                                  <Accounting-State AVP>
                                  [<Timestamp AVP>
                                   <Nonce AVP>
                                   <Integrity-Check-Value AVP>]


3.0  Mandatory AVPs

   The following table describes the DIAMETER AVPs defined in the
   Accounting extension, their AVP Code values, types, possible flag
   values and whether the AVP MAY be encrypted.

                                            +---------------------+
                                            |    AVP Flag rules   |
                                            |----+-----+----+-----|----+
                   AVP    Section  Value    |    |     |SHLD| MUST|MAY |
   Attribute Name  Code   Defined  Type     |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   Accounting-      480     3.1    Integer32| M  |  P  |    |  V  | Y  |
     Record-Type                            |    |     |    |     |    |
   ADIF-Record      481     3.2    Data     | M  |  P  |    |  V  | Y  |
   Accounting-      482     3.3    Integer32| M  |  P  |    |  V  | Y  |
     Interim-Interval                       |    |     |    |     |    |
   Accounting-      483     3.4    Integer32| M  |  P  |    |  V  | Y  |
     Delivery-Max-Batch                     |    |     |    |     |    |
   Accounting-      484     3.5    Integer32| M  |  P  |    |  V  | Y  |
     Delivery-Max-Delay                     |    |     |    |     |    |
   Accounting-      485     3.6    Integer32| M  |  P  |    |  V  | Y  |
     Record-Number                          |    |     |    |     |    |
   Accounting-State 486     3.7    Integer32| M  |  P  |    |  V  | Y  |


3.1  Accounting-Record-Type AVP




Arkko et al.               expires March 2001                  [Page 10]


INTERNET DRAFT                                            September 2000


   The Accounting-Record-Type AVP (AVP Code 480) is of type Integer32
   and contains the type of accounting record that can be found in the
   corresponding ADIF-Record AVP. The following values are currently
   defined for the Accounting-Record-Type AVP:

      EVENT_RECORD                    1
         An Accounting Event Record is used to indicate that a one-time
         event has occurred (meaning that the start and end of the event
         are simultaneous).  This record contains all information
         relevant to the service, and is the only record of the service.

      START_RECORD                    2
         An Accounting Start, Interim, and Stop Records are used to
         indicate that a service of a measurable length has been given.
         An Accounting Start Record is used to initiate an accounting
         session, and contains accounting information that is relevant
         to the initiation of the session.

      INTERIM_RECORD                  3
         An Interim Accounting Record contains cumulative accounting
         information for an existing accounting session. Interim
         Accounting Records SHOULD be sent every time a re-
         authentication or re-authorization occurs.  Further, additional
         interim record triggers MAY be defined by application-specific
         DIAMETER extensions. The selection of whether to use
         INTERIM_RECORD records is directed by the Accounting-Interim-
         Interval AVP.

      STOP_RECORD                     4
         An Accounting Stop Record is sent to terminate an accounting
         session and contains cumulative accounting information relevant
         to the existing session.


3.2  ADIF-Record AVP

   The ADIF-Record AVP (AVP Code 481) is of type Data and contains the
   ADIF payload, as defined in [10].


3.3  Accounting-Interim-Interval AVP

   The Accounting-Interim-Interval AVP (AVP Code 482) is of type
   Integer32 and is sent from the DIAMETER authenticating/authorizing
   server to the DIAMETER client. The client uses information in this
   AVP to decide how and when to produce accounting records. With
   different values in this AVP, service sessions can result in one,
   two, or two+N accounting records, based on the needs of the home-



Arkko et al.               expires March 2001                  [Page 11]


INTERNET DRAFT                                            September 2000


   organization. The following accounting record production behaviour is
   directed by the inclusion of this AVP:

      1. The omission of the Accounting-Interim-Interval AVP or its
         inclusion with Value field set to 0 means that EVENT_RECORD,
         START_RECORD, and STOP_RECORD are produced, as appropriate for
         the service.

      2. The inclusion of the AVP with Value field set to a non-zero
         value means that INTERIM_RECORD records MUST be produced
         between the START_RECORD and STOP_RECORD records.  The Value
         field of this AVP is the nominal interval between these records
         in seconds. The DIAMETER node that originates the accounting
         information, known as the client, MUST produce the first
         INTERIM_RECORD record roughly at the time when this nominal
         interval has elapsed from the START_RECORD, the next one again
         as the interval has elapsed once more, and so on until the
         session ends and a STOP_RECORD record is produced.

         The client MUST ensure that the interim record production times
         are randomized so that large accounting message storms are not
         created either among records or around a common service start
         time.


3.4  Accounting-Delivery-Max-Batch AVP

   The Accounting-Delivery-Max-Batch AVP (AVP Code 483) is of type
   Integer32 and is included in an Accounting-Answer. This AVP controls
   how accounting data is transferred to the accounting server. The AVP
   sets the requirements in terms of number of locally collected records
   before accounting data transfer SHOULD begin. The DIAMETER node that
   receives this AVP MAY deliver the data earlier due to satisfying
   requirements set by Accounting-Delivery-Max-Delay, device reboot,
   lack of memory, or explicit configuration. The DIAMETER node MUST
   begin the transfer in the given limits unless prevented from doing so
   by network partitions, client or server failures, network congestion,
   or client overload.


3.5  Accounting-Delivery-Max-Delay AVP

   The Accounting-Delivery-Max-Delay AVP (AVP Code 484) is of type
   Integer32 and is included in an Accounting-Answer. This AVP controls
   how accounting data is transferred to the authorization request. The
   AVP sets the requirements in terms of maximum delay before accounting
   data transfer SHOULD begin. The DIAMETER node that receives this AVP
   MAY deliver the data earlier due to satisfying requirements set by



Arkko et al.               expires March 2001                  [Page 12]


INTERNET DRAFT                                            September 2000


   Accounting-Delivery-Max-Batch, device reboot, lack of memory, or
   explicit configuration. The DIAMETER node MUST begin the transfer in
   the given limits unless prevented from doing so by network
   partitions, client or server failures, network congestion, or client
   overload.


3.6  Accounting-Record-Number AVP

   The Accounting-Record-Number AVP (AVP Code 485) is of type Integer32
   and identifies this record within one session. As Session-Id AVPs are
   globally unique, the combination of Session-Id and Accounting-
   Record-Number AVPs is also globally unique, and can be used in
   matching accounting records with confirmations.  An easy way to
   produce unique numbers is to set the value to 0 for records of type
   EVENT_RECORD and START_RECORD, and set the value to 1 for the first
   INTERIM_RECORD, 2 for the second, and so on until the value for
   STOP_RECORD is one more than for the last INTERIM_RECORD.


3.7  Accounting-State AVP

   The Accounting-State AVP (AVP Code 486) is of type Integer32 and is
   used to communicate to a peer whether Accounting messages will be
   sent in the future. A node that issues an ASI with the Accounting-
   State AVP set to DISABLED is informing its peer that it will no
   longer be transmitting Accounting messages until a subsequent ASI
   message is sent with the Accounting-State AVP set to ENABLED.

   The following values have been defined:
      1      ENABLED
      2      DISABLED


4.0  IANA Considerations

   The command codes defined in Section 2.0 are values taken from the
   Command-Code [1] address space and extended in [2], [3] and [9].
   IANA should record the values as defined in Section 2.0.

   The AVPs defined in section 3.0 and 5.0 were alllocated from from the
   AVP numbering space defined in [1], and extended in [2], [3] and [9].
   IANA should record the values as defined in Section 3.0.

   This document introduces the Accounting-Record-Type AVP, which
   contains pre-defined values. This document defines the values 1-3.
   All remaining values are available for assignment via a Designated
   Expert [8].



Arkko et al.               expires March 2001                  [Page 13]


INTERNET DRAFT                                            September 2000


5.0  Security Considerations

   This DIAMETER extension assumes that the accounting data is secured
   either through a hop-by-hop authentication mechanism, as described in
   [1], or using a strong authentication mechanism as defined in [9].


6.0  Acknowledgments

   The authors would like to thank Nenad Trifunovic, Tony Johansson and
   Pankaj Patel for their participation in the Document Reading Party.
   Thanks to the various people that have contributed to accounting
   related requirements at the IETF's AAA Working Group and other
   related WGs.


7.0  References


   [1]  P. Calhoun, A. Rubens, H. Akhtar, E. Guttman.  "DIAMETER Base
        Protocol", draft-calhoun-diameter-17.txt, IETF work in progress,
        September 2000.

   [2]  P. Calhoun, W. Bulley, A. Rubens, J. Haag.  "DIAMETER NASREQ
        Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in
        progress, September 2000.

   [3]  P. Calhoun, C. Perkins. "DIAMETER Mobile IP Extension", draft-
        calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep-
        tember 2000.

   [4]  C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authenti-
        cation Dial In User Service (RADIUS)." RFC 2138, April 1997.

   [5]  C. Rigney, "RADIUS Accounting." RFC 2139,  April 1997.

   [6]  S. Bradner, "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [7]  D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC
        2409, November 1998.

   [8]  Narten, Alvestrand, "Guidelines for Writing an IANA Considera-
        tions Section in RFCs", BCP 26, RFC 2434, October 1998

   [9]  P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security
        Extension", draft-calhoun-diameter-strong-crypto-05.txt, IETF
        work in progress, September 2000.



Arkko et al.               expires March 2001                  [Page 14]


INTERNET DRAFT                                            September 2000


   [10] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format
        (ADIF)", draft-ietf-roamops-actng-07.txt, IETF work in progress,
        April 2000.

   [11] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting
        Management", draft-ietf-aaa-acct-06.txt, IETF work in progress,
        June 2000.

   [12] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload
        Compression Protocol (IPComp)", RFC 2393, December 1998.


8.0  Authors' Addresses

   Questions about this memo can be directed to:

      Jari Arkko
      Oy LM Ericsson Ab
      02420 Jorvas
      Finland

       Phone: +358 40 5079256
      E-Mail: Jari.Arkko@ericsson.com


      Pat R. Calhoun
      Network and Security Research Center, Sun Labs
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  +1 650-786-7733
         Fax:  +1 650-786-6445
      E-mail:  pcalhoun@eng.sun.com


      Pankaj Patel
      Convergys Corporation
      4600 Montgomery Road
      Cincinnati, OH 45212
      USA

       Phone:  +1 513-723-2018
      E-Mail:  pankaj.patel@convergys.com


      Glen Zorn



Arkko et al.               expires March 2001                  [Page 15]


INTERNET DRAFT                                            September 2000


      Cisco Systems, Inc.
      500 108th Avenue N.E., Suite 500
      Bellevue, WA 98004
      USA

       Phone:  +1 425 438 8218
      E-Mail:  gwz@cisco.com


9.0  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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 docu-
   ment 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 develop-
   ing 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 lim-
   ited 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 DIS-
   CLAIMS 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.


















Arkko et al.               expires March 2001                  [Page 16]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/