rfc2924.txt

radius服务器

       Contains an integer, decimal valued identifier assigned to a
       specific authorized transaction.

   <!ELEMENT Unit (#PCDATA)>
       Indicates the units by which pricing is measured or usage
       recorded.  It shall contain one of the following values:
           s      seconds
           p      packets (datagrams)
           byte   bytes

   <!Element UsageDetail ( Service, Amount, Increment, Unit ) >
       Collects information describing the usage of a service.

6.2.  MSIX

   MSIX [MSIX-SPEC] is an XML-based protocol transported by HTTP that is
   used to make accounting service definitions and transmit service
   usage information.  As its service definitions are parameterized and
   dynamic, it makes no definition of services or attributes itself, but
   allows implementors to make their own.  It specifies only the base
   data types that attributes may take: STRING, UNISTRING, INT32, FLOAT,
   DOUBLE, BOOLEAN, TIMESTAMP.

7.  Accounting File and Record Formats

7.1.  ASN.1 Records

7.1.1.  RTFM and AToMMIB

   RTFM and AToMMIB use ASN.1 Basic Encoding Rules (BER) to encode lists
   of attributes into accounting records.  RTFM uses SNMP to retrieve
   such records as BER strings, thus avoiding having to have an object
   identifier for every object.






Brownlee & Blount            Informational                     [Page 19]

RFC 2924        Accounting Attributes and Record Formats  September 2000


   AToMMIB carries this a stage further by defining an accounting file
   format in ASN.1 and making it available for retrieval by a file
   transfer protocol, thereby providing a more efficient alternative to
   simply retrieving the records using SNMP.

7.1.2.  Q.825

   A Q.825 Call Record is an ASN.1 SET containing a specified group of
   the Q.825 attributes.  Call records would presumably be encoded as
   BER strings before being collected for later processing.

7.2.  Binary Records

7.2.1.  RADIUS

   Radius packets carry a sequence of attributes and their values, as
   (Type, Length, Value) triples.  The format of the value field is one
   of four data types.

      string   0-253 octets

      address  32 bit value, most significant octet first.

      integer  32 bit value, most significant octet first.

      time     32 bit value, most significant octet first -- seconds
               since 00:00:00 GMT, January 1, 1970.  The standard
               Attributes do not use this data type but it is presented
               here for possible use within Vendor-Specific attributes.

7.2.2.  DIAMETER

   Each DIAMETER message consists of multiple AVP's that are 32-bit
   aligned, with the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |     Reserved        |P|T|V|R|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Vendor ID (opt)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Tag (opt)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+



Brownlee & Blount            Informational                     [Page 20]

RFC 2924        Accounting Attributes and Record Formats  September 2000


      Code
         The AVP Code identifies the attribute uniquely.  If the Vendor-
         Specific bit is set, the AVP Code is allocated from the
         vendor's private address space.

         The first 256 AVP numbers are reserved for backward
         compatibility with RADIUS and are to be interpreted as per
         RADIUS [RAD-PROT].  AVP numbers 256 and above are used for
         DIAMETER, which are allocated by IANA.

      AVP Length
         A 16-bit field contains the total object length in bytes.
         Must always be a multiple of 4, and at least 8.

      AVP Flags
         P                      Protected bit
         T                      Tag bit
         V                      Vendor-ID bit
         R                      Reserved (MUST be set to 0)
         M                      Mandatory bit

7.3.  Text Records

7.3.1.  ROAMOPS

   ADIF (Accounting Data Interchange Format [ROAM-ADIF]) presents a
   general, text-based format for accounting data files, described in a
   straightforward BNF grammar.  Its file header contains a field
   indicating the default protocol from which accounting attributes are
   drawn.  If an attribute from another protocol is to be used, it is
   preceded by its protocol name, for example rtfm//27 would be RTFM's
   "forward bytes" attribute.  Comments in an ADIF file begin with a
   cross-hatch.

   Example: An ADIF file encoding RADIUS accounting data

        version: 1
        device: server3
        description: Accounting Server 3
        date: 02 Mar 1999 12:19:01 -0500
        defaultProtocol: radius

        rdate: 02 Mar 1999 12:20:17 -0500
        #NAS-IP-Address
        4: 204.45.34.12
        #NAS-Port
        5: 12
        #NAS-Port-Type



Brownlee & Blount            Informational                     [Page 21]

RFC 2924        Accounting Attributes and Record Formats  September 2000


        61: 2
        #User-Name
        1: [e-mail]
        #Acct-Status-Type
        40: 2
        #Acct-Delay-Time
        41: 14
        #Acct-Input-Octets
        42: 234732
        #Acct-Output-Octets
        43: 15439
        #Acct-Session-Id
        44: 185
        #Acct-Authentic
        45: 1
        #Acct-Session-Time
        46: 1238
        #Acct-Input-Packets
        47: 153
        #Acct-Output-Packets
        48: 148
        #Acct-Terminate-Cause
        49: 11
        #Acct-Multi-Session-Id
        50: 73
        #Acct-Link-Count
        51: 2

8.  AAA Requirements

8.1.  A Well-Defined Set of Attributes

   AAA needs a well-defined set of attributes whose values are to be
   carried in records to or from accounting servers.

   Most of the existing sets of documents described above include a set
   of attributes, identified by small integers.  It is likely that these
   sets overlap, i.e. that some of them have attributes which represent
   the same quantity using different names in different sets.  This
   suggests it might be possible to produce a single combined set of
   "universal" accounting attributes, but such a "universal" set does
   not seem worthwhile.

   The ADIF approach of specifying a default protocol (from which
   attributes are assumed to come) and identifying any exceptions seems
   much more practical.  We therefore propose that AAA should use the





Brownlee & Blount            Informational                     [Page 22]

RFC 2924        Accounting Attributes and Record Formats  September 2000


   ADIF convention (or something like it) to identify attributes,
   together with all the sets of attributes covered by the [ASG-NBR]
   document.

8.2.  A Simple Interchange Format

   AAA needs a simple interchange file format, to be used for accounting
   data.  Several schemes for packaging and transporting such data have
   been described above.

   The SNMP-based ones fit well within the context of an SNMP-based
   network management system.  RTFM and AToMMIB provide ways to reduce
   the SNMP overhead for collecting data, and AToMMIB defines a complete
   file format.  Both provide good ways to collect accounting data.

   As an interchange format, however, ASN.1-based schemes suffer from
   being rather complex binary structures.  This means that one requires
   suitable tools to work with them, as compared to plain-text files
   where one can use existing text-based utilities.

   The binary schemes such as RADIUS and DIAMETER have simpler
   structures, but they too need purpose-built tools.  For general use
   they would need to be extended to allow them to use attributes from
   other protocols.

   From the point of view of being easy for humans to understand, ADIF
   seems very promising.  Of course any processing program would need a
   suitable ADIF input parser, but using plain-text files makes them
   much easier to understand.

   TIPHON's record format is specified by an XML DTD.  While XML
   representations have the advantages of being well-known, they are
   limited by XML's inability to specify type or other validity checking
   for information within the tags.  This situation will likely be
   improved by the XML Schema [XML-SCHM] efforts that are underway, but
   a stable reference is not yet available.

9.  Issues

   It is generally agreed that there is a need for a standard record
   format and transport protocol for communication between Service
   Elements and Accounting Servers.

   There is less agreement on the following issues:

      o  Separate or integral record format and transport protocol
      o  Standard set of base data types
      o  Service definitions: part of the protocol or separately defined



Brownlee & Blount            Informational                     [Page 23]

RFC 2924        Accounting Attributes and Record Formats  September 2000


      o  Service definition namespace management

   The following sections address these issues.

9.1.  Record Format vs. Protocol

   All known Internet-centric billing protocols to date have an integral
   record format.  That is, the collection of Properties that describe a
   Usage Event are specified as an integral part of the protocol,
   typically as a part of a "submit" message that is used to transmit a
   Usage Event from a Service Entity to an Accounting Server.

   It may be advantageous to define a record format that is independent
   of the transport protocol.  Such a record format should support both
   representation of individual records and records in bulk, as Usage
   Events are often aggregated and transmitted in bulk.

   A separate record format is useful for record archiving and temporary
   file storage.  Multiple transport protocols may be defined without
   affecting the record format.  The task of auditing is made easier if
   a standard file format is defined.  If a canonical format is used,
   bulk records may be hashed with MD5 [MD5] or a similar function, for
   reliability and security purposes.

                                  +------------+
                                  |  transport |
                                  |   header   |
            +------------+        +------------+
            |            |        |            |
            |   Usage    |        |   Usage    |
            |  Event(s)  |        |  Event(s)  |
            |            |        |            |
            |            |        |            |
            +------------+        +------------+
                                  |  trailer   |
                                  +------------+

            record format       transport protocol

   If the protocol is written such that it can transmit Usage Events in
   the record format, no record rewriting for transport is required.

9.2.  Tagged, Typed Data

   Record formats and protocols use a combination of data locality and
   explicit tagging to identify data elements.  Mail [RFC822], for
   instance, defines a header block composed of several Attribute-Value
   Pairs, followed by a message body.  Each header field is explicitly



Brownlee & Blount            Informational                     [Page 24]

RFC 2924        Accounting Attributes and Record Formats  September 2000


   tagged, but the order of the AVPs is undefined.  The message body is
   not tagged (except with an additional preceding blank line), and is
   found through its position in the message, which must be after all
   header fields.

   Some record formats make no use of tags--data elements are identified
   only by their position within a record structure.  While this
   practice provides for the least amount of record space overhead, it
   is difficult to later modify the record format by adding or removing
   elements, as all record readers will have to be altered to handle the
   change.  Tagged data allows old readers to detect unexpected tags and
   to detect if required data are missing.  If the overhead of carrying
   explicit tags can be borne, it is advantageous to use explicitly
   tagged data elements where possible.

   An AVP approach has proven useful in accounting.  RADIUS [RADIUS]
   uses numeric data type identifiers.  ETSI's TIPHON [TIPHON] uses XML
   markup.