rfc2924.txt

radius服务器

   DIAMETER defines a base protocol that specifies the header formats,
   security extensions and requirements as well as a small number of
   mandatory commands and AVPs.  A new service can extend DIAMETER by
   extending the base protocol to support new functionality.

   One key differentiator with DIAMETER is its inherent support for
   Inter-Server communication.  Although this can be achieved in a
   variety of ways, the most useful feature is the ability to "proxy"
   messages across a set of DIAMETER servers (known as a proxy chain).

   The DIAMETER Accounting Extension document [DIAM-ACT] extends
   DIAMETER by defining a protocol for securely transferring accounting
   records over the DIAMETER base protocol.  This includes the case
   where accounting records may be passed through one or more
   intermediate proxies, in accordance with the 'referral broker' model.

   The DIAMETER accounting protocol [DIAM-ACT] defines DIAMETER records
   for transferring an ADIF record (see below).  It introduces five new
   attributes (480..485) which specify the way in which accounting
   information is to be delivered between DIAMETER servers.

4.2.1.  DIAMETER Attributes

   DIAMETER AVPs are identified by a 16-bit number defined in [DIAM-
   AUTH].  Since most of the AVPs found in that document were copied
   from the RADIUS protocol [RAD-PROT], it is possible to have both
   RADIUS and DIAMETER servers read the same dictionary and users files.

   The backward compatibility that DIAMETER offers is intended to
   facilitate deployment.  To this end, DIAMETER inherits the RADIUS
   attributes, and adds only a few of its own.

   In the list below attribute numbers which are used for RADIUS
   attributes but not for DIAMETER are indicated with a star (*).
   RADIUS attributes used by DIAMETER are not listed again here.

   The DIAMETER attributes are:

       4      (unassigned, *)
      17      (unassigned)
      21      (unassigned)
      24      (unassigned, *)
      25      (unassigned, *)
      27      (unassigned, *)
      32      (unassigned, *)
      33      (unassigned, *)
     280      Filter-Rule
     281      Framed-Password-Policy



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


     480      Accounting-Record-Type
     481      ADIF-Record
     482      Accounting-Interim-Interval
     483      Accounting-Delivery-Max-Batch
     484      Accounting-Delivery-Max-Delay
     485      Accounting-Record-Number

     600      SIP-Sequence
     601      SIP-Call-ID
     602      SIP-To
     603      SIP-From

4.3.  ROAMOPS

   [ROAM-IMPL] reviews the design and functionality of existing roaming
   implementations.  "Roaming capability" may be loosely defined as the
   ability to use any one of multiple Internet service providers (ISPs),
   while maintaining a formal customer-vendor relationship with only
   one.  One requirement for successful roaming is the provision of
   effective accounting.

   [ROAM-ADIF] proposes a standard accounting record format, the
   Accounting Data Interchange Format (ADIF), which is designed to
   compactly represent accounting data in a protocol-independent manner.
   As a result, ADIF may be used to represent accounting data from any
   protocol using attribute value pairs (AVPs) or variable bindings.

   ADIF does not define accounting attributes of its own.  Instead, it
   gives examples of accounting records using the RADIUS accounting
   attributes.

4.4.  RTFM

   The RTFM Architecture [RTFM-ARC] provides a general method of
   measuring network traffic flows between "metered traffic groups".
   Each RTFM flow has a set of "address" attributes, which define the
   traffic groups at each of the flow's end-points.

   As well as address attributes, each flow has traffic-related
   attributes, e.g. times of first and last packets, counts for packets
   and bytes in each direction.

   RTFM flow measurements are made by RTFM meters [RTFM-MIB] and
   collected by RTFM meter readers using SNMP.  The MIB uses a
   "DataPackage" convention, which specifies the attribute values to be
   read from a flow table row.  The meter returns the values for each





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


   required attribute within a BER-encoded sequence.  This means there
   is only one object identifier for the whole sequence, greatly
   reducing the number of bytes required to retrieve the data.

4.4.1.  RTFM Attributes

   RTFM attributes are identified by a 16-bit attribute number.

   The RTFM Attributes are:

    0  Null
    1  Flow Subscript                Integer    Flow table info

    4  Source Interface              Integer    Source Address
    5  Source Adjacent Type          Integer
    6  Source Adjacent Address       String
    7  Source Adjacent Mask          String
    8  Source Peer Type              Integer
    9  Source Peer Address           String
   10  Source Peer Mask              String
   11  Source Trans Type             Integer
   12  Source Trans Address          String
   13  Source Trans Mask             String

   14  Destination Interface         Integer    Destination Address
   15  Destination Adjacent Type     Integer
   16  Destination Adjacent Address  String
   17  Destination AdjacentMask      String
   18  Destination PeerType          Integer
   19  Destination PeerAddress       String
   20  Destination PeerMask          String
   21  Destination TransType         Integer
   22  Destination TransAddress      String
   23  Destination TransMask         String

   26  Rule Set Number               Integer    Meter attribute

   27  Forward Bytes                 Integer    Source-to-Dest counters
   28  Forward Packets               Integer
   29  Reverse Bytes                 Integer    Dest-to-Source counters
   30  Reverse Packets               Integer
   31  First Time                    Timestamp  Activity times
   32  Last Active Time              Timestamp
   33  Source Subscriber ID          String     Session attributes
   34  Destination Subscriber ID     String
   35  Session ID                    String





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


   36  Source Class                  Integer    "Computed" attributes
   37  Destination Class             Integer
   38  Flow Class                    Integer
   39  Source Kind                   Integer
   40  Destination Kind              Integer
   41  Flow Kind                     Integer

   50  MatchingStoD                  Integer    PME variable

   51  v1                            Integer    Meter Variables
   52  v2                            Integer
   53  v3                            Integer
   54  v4                            Integer
   55  v5                            Integer

   65-127 "Extended" attributes
             (to be defined by the RTFM working group)

4.5.  ISDN MIB

   The ISDN MIB [ISDN-MIB] defines a minimal set of managed objects for
   SNMP-based management of ISDN terminal interfaces.  It does not
   explicitly define anything related to accounting, however it does
   define isdnBearerChargedUnits as

      The number of charged units for the current or last connection.
      For incoming calls or if charging information is not supplied by
      the switch, the value of this object is zero.

   This allows for an ISDN switch to convert its traffic flow data (such
   as Call Connect Time) into charging data.

4.5.1.  ISDN Attributes

   The relevant object in the MIB is the ISDN bearer table, which has
   entries in the following form:

   IsdnBearerEntry ::=
       SEQUENCE {
           isdnBearerChannelType           INTEGER,
           isdnBearerOperStatus            INTEGER,
           isdnBearerChannelNumber         INTEGER,
           isdnBearerPeerAddress           DisplayString,
           isdnBearerPeerSubAddress        DisplayString,
           isdnBearerCallOrigin            INTEGER,
           isdnBearerInfoType              INTEGER,
           isdnBearerMultirate             TruthValue,
           isdnBearerCallSetupTime         TimeStamp,



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


           isdnBearerCallConnectTime       TimeStamp,
           isdnBearerChargedUnits          Gauge32
           }

4.6.  AToMMIB

   The "ATM Accounting Information MIB" document [ATM-ACT] describes a
   large set of accounting objects for ATM connections.  An
   administrator may select objects from this set using a selector of
   the form (subtree, list) where "subtree" specifies an object
   identifier from the AToMMIB.  For each subtree there is a table
   holding values for each ATM connection.  The required connections are
   indicated by setting bits in "list", which is an octet string.  For
   example, the set containing the number of received cells for the
   first eight ATM connections would be selected by
   (atmAcctngReceivedCells, 0xFF).

   The Connection-Oriented Accounting MIB document [ATM-COLL] defines a
   MIB providing managed objects used for controlling the collection and
   storage of accounting information for connection-oriented networks
   such as ATM.  The accounting data is collected into files for later
   retrieval via a file transfer protocol.  Records within an accounting
   file are stored as BER strings [ASN1, BER].

4.6.1.  AToMMIB Attributes

   Accounting data objects within the AToMMBIB are identified by the
   last integer in their object identifiers.

   The ATM accounting data objects are:

      1   atmAcctngConnectionType
      2   atmAcctngCastType
      3   atmAcctngIfName
      4   atmAcctngIfAlias
      5   atmAcctngVpi
      6   atmAcctngVci
      7   atmAcctngCallingParty
      8   atmAcctngCalledParty
      9   atmAcctngCallReference
     10   atmAcctngStartTime
     11   atmAcctngCollectionTime
     12   atmAcctngCollectMode
     13   atmAcctngReleaseCause
     14   atmAcctngServiceCategory
     15   atmAcctngTransmittedCells
     16   atmAcctngTransmittedClp0Cells
     17   atmAcctngReceivedCells



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


     18   atmAcctngReceivedClp0Cells
     19   atmAcctngTransmitTrafficDescriptorType
     20   atmAcctngTransmitTrafficDescriptorParam1
     21   atmAcctngTransmitTrafficDescriptorParam2
     22   atmAcctngTransmitTrafficDescriptorParam3
     23   atmAcctngTransmitTrafficDescriptorParam4
     24   atmAcctngTransmitTrafficDescriptorParam5
     25   atmAcctngReceiveTrafficDescriptorType
     26   atmAcctngReceiveTrafficDescriptorParam1
     27   atmAcctngReceiveTrafficDescriptorParam2
     28   atmAcctngReceiveTrafficDescriptorParam3
     29   atmAcctngReceiveTrafficDescriptorParam4
     30   atmAcctngReceiveTrafficDescriptorParam5
     31   atmAcctngCallingPartySubAddress
     32   atmAcctngCalledPartySubAddress
     33   atmAcctngRecordCrc16

4.7.  QoS: RSVP and DIFFSERV

   As we move towards providing more than simple "best effort"
   connectivity, there has been a tremendous surge of interest in (and
   work on) protocols to provide managed Quality of Service for Internet
   sessions.  This is of particular interest for the provision of
   "Integrated Services", i.e. the transport of audio, video, real-time,
   and classical data traffic within a single network infrastructure.

   Two approaches to this have emerged so far:

   -  the Integrated Services architecture (intserv) [IIS-ARC], with its
      accompanying signaling protocol, RSVP [RSVP-ARC], and RSVP's
      Common Open Policy Service protocol, COPS [RAP-COPS]

   -  the Differentiated Services architecture (diffserv) [DSRV-ARC]

   RSVP is a signaling protocol that applications may use to request
   resources from the network.  The network responds by explicitly
   admitting or rejecting RSVP requests.  Certain applications that have
   quantifiable resource requirements express these requirements using
   intserv parameters [IIS-SPEC].

   Diffserv networks classify packets into one of a small number of
   aggregated flows or "classes", based on the diffserv codepoint (DSCP)
   in the packet's IP header.  At each diffserv router, packets are
   subjected to a "per-hop behavior" (PHB), which is invoked by the
   DSCP.  Since RSVP is purely a requirements signalling protocol it can
   also be used to request connections from a diffserv network [RS-DS-
   OP].




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


4.7.1.  RSVP and DIFFSERV Attributes

   A set of parameters for specifying a requested Quality of Service are
   given in [IIS-SPEC].  These have been turned into accounting
   attributes within RTFM [RTFM-NEWA] and within the RSVP MIB [RSVP-
   MIB].