rfc2924.txt

radius服务器

   For an AAA accounting record format, the authors suggest that each
   Property be named by a textual or numeric identifier and carry a
   value and a data type indicator, which governs interpretation of the
   value.  It may also be useful for each Property to carry a units of
   measure identifier.  The TIPHON specification takes this approach.
   TS 101 321 also carries an Increment field, which denominates the
   Property's Unit of Measure field.  Whether this additional
   convenience is necessary is a matter for discussion.

   It is not strictly necessary for each data record to carry data type,
   units of measure, or increments identifiers.  If this information is
   recorded in a record schema document that is referenced by each data
   record, each record may be validated against the schema without the
   overhead of carrying type information.

9.2.1.  Standard Type Definitions

   It is useful to define a standard set of primitive data types to be
   used by the record format and protocol.  Looking at the prior art,
   DIAMETER supports Data (arbitrary octets), String (UTF-8), Address
   (32 or 128 bit), Integer32, Integer64, Time (32 bits, seconds since
   1970), and Complex.  MSIX [MSIX-SPEC] supports String, Unistring,
   Int32, Float, Double, Boolean, and Timestamp.  SMIv2 [SMI-V2] offers
   ASN.1 types INTEGER, OCTET STRING, and OBJECT IDENTIFIER, and the
   application-defined types Integer32, IpAddress, Counter32, Gauge32,
   Unsigned32, TimeTicks, Opaque, and Counter64.






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


   An appropriate set would likely include booleans, 32 and 64 bit
   signed integers, 32 and 64 bit floats, arbitrary octets, UTF-8 and
   UTF-16 strings, and ISO 8601:1988 [ISO-DATE] timestamps.  Fixed-
   precision numbers capable of representing currency amounts (with
   precision specified on both sides of the decimal point) have proven
   useful in accounting record formats, as they are immune to the
   precision problems that are encountered when one attempts to
   represent fixed-point amounts with floating point numbers.

   It may be worthwhile to consider the datatypes that are being
   specified by the W3C's "XML Schema Part 2: Datatypes" [XML-DATA]
   document.  That document specifies a rich set of base types, along
   with a mechanism to specify derivations that further constrain the
   base types.

9.3.  Transaction Identifiers

   Each Usage Event requires its own unique identifier.

   It is expedient to allow Service Elements to create their own unique
   identifiers.  In this manner, Usage Events can be created and
   archived without the involvement of an Accounting Server or other
   central authority.

   A number of methods for creating unique identifiers are well known.
   One popular identifier is an amalgamation of a monotonically
   increasing sequence number, a large random value, a network element
   identifier, and a timestamp.  Another possible source of entropy is a
   hash value of all or part of the record itself.

   RFC 822 [MAIL], RFC 1036 [NEWS], and RFC 2445 [ICAL-CORE] give
   guidance on the creation of good unique identifiers.

9.4.  Service Definitions

   A critical differentiator in accounting record formats and protocols
   is their capability to account for arbitrary service usage.  To date,
   no accounting record format or protocol that can handle arbitrary
   service definitions has achieved broad acceptance on the Internet.

   This section analyzes the issues in service definition and makes a
   case for a record format and protocol with the capability to carry
   Usage Events for rich, independently-defined services.








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


9.4.1.  Service Independence

   It is informative to survey a number of popular Internet protocols
   and document encodings and examine their capacities for extension.
   These protocols can be categorized into two broad categories--"fully
   specified" protocols that have little provision for extension and
   "framework" protocols that are incomplete, but provide a basis for
   future extension when coupled with application documents.

   Examples of fully-specified protocols are NTP [NTP], NNTP [NNTP],
   RADIUS Accounting [RAD-ACT], and HTML [HTML].

   Aside from leaving some field values "reserved for future use", all
   of Network Time Protocol's fields are fixed-width and completely
   defined.  This is appropriate for a simple protocol that solves a
   simple problem.

   Network News Transfer Protocol [NEWS-PROT] specifies that further
   commands may be added, and requests that non-standard implementations
   use the "X-" experimental prefix so as to not conflict with future
   additions.  The content of news is 7-bit data, with the high-order
   bit cleared to 0.  Nothing further about the content is defined.
   There is no in-protocol facility for automating decoding of content
   type.

   We pay particular attention to RADIUS Accounting [RAD-ACT].  Perhaps
   the second most frequently heard complaint (after security
   shortcomings) about RADIUS Accounting is its preassigned and fixed
   set of "Types".  These are coded as a range of octets from 40 to 51
   and are as follows:

         40      Acct-Status-Type
         41      Acct-Delay-Time
         42      Acct-Input-Octets
         43      Acct-Output-Octets
         44      Acct-Session-Id
         45      Acct-Authentic
         46      Acct-Session-Time
         47      Acct-Input-Packets
         48      Acct-Output-Packets
         49      Acct-Terminate-Cause
         50      Acct-Multi-Session-Id
         51      Acct-Link-Count

   These identifiers were designed to account for packet-based network
   access service.  They are ill-suited for describing other services.
   While extension documents have specified additional types, the base




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


   protocol limits the type identifier to a single octet, limiting the
   total number of types to 256.

   HTML/2.0 [HTML] is mostly a fully-specified protocol, but with W3C's
   HTML/4.0, HTML is becoming more of a framework protocol.  HTML/2.0
   specified a fixed set of markups, with no provision for addition
   (without protocol revision).

   Examples of "framework" protocols and document encodings are HTTP,
   XML, and SNMP.

   HTTP/1.1 [HTTP] is somewhat similar to NNTP in that it is designed to
   transport arbitrary content.  It is different in that it supports
   description of that content through its Content-Type, Content-
   Encoding, Accept-Encoding, and Transfer-Encoding header fields.  New
   types of content can be designated and carried by HTTP/1.1 without
   modification to the HTTP protocol.

   XML [XML] is a preeminent general-purpose framework encoding.  DTD
   publishing is left to users.  There is no standard registry of DTDs.

   SNMP presents a successful example of a framework protocol.  SNMP's
   authors envisioned SNMP as a general management protocol, and allow
   extension through the use of private MIBs.  SNMP's ASN.1 MIBs are
   defined, published, and standardized without the necessity to modify
   the SNMP standard itself.  From "An Overview of SNMP" [SNMP-OVER]:

      It can easily be argued that SNMP has become prominent mainly from
      its ability to augment the standard set of MIB objects with new
      values specific for certain applications and devices.  Hence, new
      functionality can continuously be added to SNMP, since a standard
      method has been defined to incorporate that functionality into
      SNMP devices and network managers.

   Most accounting protocols are fully-specified, with either a
   completely defined service or set of services (RADIUS Accounting) or
   with one or more services defined and provision for "extension"
   services to be added to the protocol later (TIPHON).  While the
   latter is preferable, it may be preferable to take a more SNMP-like
   approach, where the accounting record format and protocol provide
   only a framework for service definition, and leave the task of
   service definition (and standardization) to separate efforts.  In
   this manner, the accounting protocol itself would not have to be
   modified to handle new services.







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


9.4.2.  Versioned Service Definitions

   Versioning is a naming and compatibility issue.  Version identifiers
   are useful in service definition because they enable service
   definitions to be upgraded without a possibly awkward name change.
   They also enable possible compatibility between different versions of
   the same service.

   An example could be the service definition of a phone call.  Version
   1 might define Properties for the start time, duration, and called
   and calling party numbers.  Later, version 2 is defined, which
   augments the former service definition with a byte count.  An
   Accounting Server, aware only of Version 1, may accept Version 2
   records, discarding the additional information (forward
   compatibility).  Alternately, if an Accounting Server is made aware
   of version 2, it could optionally still accept version 1 records from
   Service Elements, provided the Accounting Sever does not require the
   additional information to properly account for service usage
   (backward compatibility).

9.4.3.  Relationships Among Usage Events

   Accounting record formats and protocols to date do not sufficiently
   addressed "compound" service description.

   A compound service is a service that is described as a composition of
   other services.  A conference call, for example, may be described as
   a number of point-to-point calls to a conference bridge.  It is
   important to account for the individual calls, rather than just
   summing up an aggregate, both for auditing purposes and to enable
   differential rating.  If these calls are to be reported to the
   Accounting Server individually, the Usage Events require a shared
   identifier that can be used by the Accounting Server and other back-
   end systems to group the records together.

   In order for a Service Element to report compound events over time as
   a succession of individual Usage Events, the accounting protocol
   requires a facility to communicate that the compound event has
   started and stopped.  The "start" message can be implicit--the
   transmission of the first Usage Event will suffice.  An additional
   semaphore is required to tell the Accounting Server that the compound
   service is complete and may be further processed.  This is necessary
   to prevent the Accounting Server from prematurely processing compound
   events that overlap the end of a billing period.







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


   RADIUS Accounting has some provision for this sort of accounting with
   its "Acct-Multi-Session-Id" field.  Unfortunately, RADIUS
   Accounting's other shortcomings preclude it from being used in
   general purpose service usage description.

9.4.4.  Service Namespace Management

   "Framework" protocols, as previously mentioned, do not define
   complete schema for their payload.  For interoperability to be
   achieved, it must be possible for:

      (1) content definers to specify definitions without conflicting
          with the names of other definitions

      (2) protocol users to find and use content definitions

   Condition (1) can be readily managed through IANA assignment or by
   using an existing namespace differentiator (for example, DNS).

   Condition (2) is harder, and places considerable burden on the
   implementors.  Their clients and servers must be able, statically or
   dynamically, to find and validate definitions, and manage versioning
   issues.

   As previously mentioned, the XML specification provides no facility
   for DTD discovery or namespace management.  XML specifies only a
   document format, and as such does not need to specify support for
   more "protocol" oriented problems.

   For an accounting record format and protocol, an approach closer to
   SNMP's is useful.  SNMP uses an ISO-managed dotted-decimal namespace.
   An IANA-managed registry of service types is a possibility.  Another
   possibility, used by MSIX [MSIX-SPEC], is for Service Element
   creators to identify their services by concatenation of a new service
   name with existing unique identifier, such as a domain name.

   A standard record format for service definitions would make it
   possible for Service Element creators to directly supply accounting
   system managers with the required definitions, via the network or
   other means.

10.  Encodings

   It may be useful to define more than one record encoding.

   A "verbose" XML encoding is easily implemented and records can be
   syntactically verified with existing tools.  "Human-readable"
   protocols tend to have an edge on "bitfield" protocols where ease of



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


   implementation is paramount and the application can tolerate any
   additional processing required to generate, parse, and transport the
   records.

   A alternative "compressed" encoding that makes minimal use of storage
   and processing may be useful in many contexts.

   There are disadvantages to supporting multiple encodings.
   Optionally-supported multiple encodings mandate the requirement for
   capabilities exchange between Service Element and Accounting Server.
   Also, implementations can tend to "drift apart", with one encoding
   better-supported than another.  Unless all encodings are mandatory,
   implementors may find they are unable to interoperate because they
   picked the wrong encoding.

11.  Security Considerations

   This document summarises many existing IETF and ITU documents; please
   refer to the original documents for security considerations for their
   particular protocols.

   It must be possible for the accounti