rfc3588.txt

ietf 的dimater基本协议

1.2.  Approach to Extensibility

   The Diameter protocol is designed to be extensible, using several
   mechanisms, including:

      -  Defining new AVP values
      -  Creating new AVPs
      -  Creating new authentication/authorization applications
      -  Creating new accounting applications
      -  Application authentication procedures

   Reuse of existing AVP values, AVPs and Diameter applications are
   strongly recommended.  Reuse simplifies standardization and
   implementation and avoids potential interoperability issues.  It is
   expected that command codes are reused; new command codes can only be
   created by IETF Consensus (see Section 11.2.1).

1.2.1.  Defining New AVP Values

   New applications should attempt to reuse AVPs defined in existing
   applications when possible, as opposed to creating new AVPs.  For
   AVPs of type Enumerated, an application may require a new value to
   communicate some service-specific information.

   In order to allocate a new AVP value, a request MUST be sent to IANA
   [IANA], along with an explanation of the new AVP value.  IANA
   considerations for Diameter are discussed in Section 11.

1.2.2.  Creating New AVPs

   When no existing AVP can be used, a new AVP should be created.  The
   new AVP being defined MUST use one of the data types listed in
   Section 4.2.

   In the event that a logical grouping of AVPs is necessary, and
   multiple "groups" are possible in a given command, it is recommended
   that a Grouped AVP be used (see Section 4.4).

   In order to create a new AVP, a request MUST be sent to IANA, with a
   specification for the AVP.  The request MUST include the commands
   that would make use of the AVP.

1.2.3.  Creating New Authentication Applications

   Every Diameter application specification MUST have an IANA assigned
   Application Identifier (see Section 2.4) or a vendor specific
   Application Identifier.




Calhoun, et al.             Standards Track                    [Page 11]

RFC 3588                Diameter Based Protocol           September 2003


   Should a new Diameter usage scenario find itself unable to fit within
   an existing application without requiring major changes to the
   specification, it may be desirable to create a new Diameter
   application.  Major changes to an application include:

   -  Adding new AVPs to the command, which have the "M" bit set.

   -  Requiring a command that has a different number of round trips to
      satisfy a request (e.g., application foo has a command that
      requires one round trip, but new application bar has a command
      that requires two round trips to complete).

   -  Adding support for an authentication method requiring definition
      of new AVPs for use with the application.  Since a new EAP
      authentication method can be supported within Diameter without
      requiring new AVPs, addition of EAP methods does not require the
      creation of a new authentication application.

   Creation of a new application should be viewed as a last resort.  An
   implementation MAY add arbitrary non-mandatory AVPs to any command
   defined in an application, including vendor-specific AVPs without
   needing to define a new application.  Please refer to Section 11.1.1
   for details.

   In order to justify allocation of a new application identifier,
   Diameter applications MUST define one Command Code, or add new
   mandatory AVPs to the ABNF.

   The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see
   Section 3.2).  If the Diameter application has accounting
   requirements, it MUST also specify the AVPs that are to be present in
   the Diameter Accounting messages (see Section 9.3).  However, just
   because a new authentication application id is required, does not
   imply that a new accounting application id is required.

   When possible, a new Diameter application SHOULD reuse existing
   Diameter AVPs, in order to avoid defining multiple AVPs that carry
   similar information.

1.2.4.  Creating New Accounting Applications

   There are services that only require Diameter accounting.  Such
   services need to define the AVPs carried in the Accounting-Request
   (ACR)/ Accounting-Answer (ACA) messages, but do not need to define
   new command codes.  An implementation MAY add arbitrary non-mandatory
   AVPs (AVPs with the "M" bit not set) to any command defined in an





Calhoun, et al.             Standards Track                    [Page 12]

RFC 3588                Diameter Based Protocol           September 2003


   application, including vendor-specific AVPs, without needing to
   define a new accounting application.  Please refer to Section 11.1.1
   for details.

   Application Identifiers are still required for Diameter capability
   exchange.  Every Diameter accounting application specification MUST
   have an IANA assigned Application Identifier (see Section 2.4) or a
   vendor specific Application Identifier.

   Every Diameter implementation MUST support accounting.  Basic
   accounting support is sufficient to handle any application that uses
   the ACR/ACA commands defined in this document, as long as no new
   mandatory AVPs are added.  A mandatory AVP is defined as one which
   has the "M" bit set when sent within an accounting command,
   regardless of whether it is required or optional within the ABNF for
   the accounting application.

   The creation of a new accounting application should be viewed as a
   last resort and MUST NOT be used unless a new command or additional
   mechanisms (e.g., application defined state machine) is defined
   within the application, or new mandatory AVPs are added to the ABNF.

   Within an accounting command, setting the "M" bit implies that a
   backend server (e.g., billing server) or the accounting server itself
   MUST understand the AVP in order to compute a correct bill.  If the
   AVP is not relevant to the billing process, when the AVP is included
   within an accounting command, it MUST NOT have the "M" bit set, even
   if the "M" bit is set when the same AVP is used within other Diameter
   commands (i.e., authentication/authorization commands).

   A DIAMETER base accounting implementation MUST be configurable to
   advertise supported accounting applications in order to prevent the
   accounting server from accepting accounting requests for unbillable
   services.  The combination of the home domain and the accounting
   application Id can be used in order to route the request to the
   appropriate accounting server.

   When possible, a new Diameter accounting application SHOULD attempt
   to reuse existing AVPs, in order to avoid defining multiple AVPs that
   carry similar information.

   If the base accounting is used without any mandatory AVPs, new
   commands or additional mechanisms (e.g., application defined state
   machine), then the base protocol defined standard accounting
   application Id (Section 2.4) MUST be used in ACR/ACA commands.






Calhoun, et al.             Standards Track                    [Page 13]

RFC 3588                Diameter Based Protocol           September 2003


1.2.5.  Application Authentication Procedures

   When possible, applications SHOULD be designed such that new
   authentication methods MAY be added without requiring changes to the
   application.  This MAY require that new AVP values be assigned to
   represent the new authentication transform, or any other scheme that
   produces similar results.  When possible, authentication frameworks,
   such as Extensible Authentication Protocol [EAP], SHOULD be used.

1.3.  Terminology

   AAA
      Authentication, Authorization and Accounting.

   Accounting
      The act of collecting information on resource usage for the
      purpose of capacity planning, auditing, billing or cost
      allocation.

   Accounting Record
      An accounting record represents a summary of the resource
      consumption of a user over the entire session.  Accounting servers
      creating the accounting record may do so by processing interim
      accounting events or accounting events from several devices
      serving the same user.

   Authentication
      The act of verifying the identity of an entity (subject).

   Authorization
      The act of determining whether a requesting entity (subject) will
      be allowed access to a resource (object).

   AVP
      The Diameter protocol consists of a header followed by one or more
      Attribute-Value-Pairs (AVPs).  An AVP includes a header and is
      used to encapsulate protocol-specific data (e.g., routing
      information) as well as authentication, authorization or
      accounting information.

   Broker
      A broker is a business term commonly used in AAA infrastructures.
      A broker is either a relay, proxy or redirect agent, and MAY be
      operated by roaming consortiums.  Depending on the business model,
      a broker may either choose to  deploy relay agents or proxy
      agents.





Calhoun, et al.             Standards Track                    [Page 14]

RFC 3588                Diameter Based Protocol           September 2003


   Diameter Agent
      A Diameter Agent is a Diameter node that provides either relay,
      proxy, redirect or translation services.

   Diameter Client
      A Diameter Client is a device at the edge of the network that
      performs access control.  An example of a Diameter client is a
      Network Access Server (NAS) or a Foreign Agent (FA).

   Diameter Node
      A Diameter node is a host process that implements the Diameter
      protocol, and acts either as a Client, Agent or Server.

   Diameter Peer
      A Diameter Peer is a Diameter Node to which a given Diameter Node
      has a direct transport connection.

   Diameter Security Exchange
      A Diameter Security Exchange is a process through which two
      Diameter nodes establish end-to-end security.

   Diameter Server
      A Diameter Server is one that handles authentication,
      authorization and accounting requests for a particular realm.  By
      its very nature, a Diameter Server MUST support Diameter
      applications in addition to the base protocol.

   Downstream
      Downstream is used to identify the direction of a particular
      Diameter message from the home server towards the access device.

   End-to-End Security
      TLS and IPsec provide hop-by-hop security, or security across a
      transport connection.  When relays or proxy are involved, this
      hop-by-hop security does not protect the entire Diameter user
      session.  End-to-end security is security between two Diameter
      nodes, possibly communicating through Diameter Agents.  This
      security protects the entire Diameter communications path from the
      originating Diameter node to the terminating Diameter node.

   Home Realm
      A Home Realm is the administrative domain with which the user
      maintains an account relationship.

   Home Server
      See Diameter Server.





Calhoun, et al.             Standards Track                    [Page 15]

RFC 3588                Diameter Based Protocol           September 2003


   Interim accounting