Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6733

Diameter Base Protocol

Pages: 152
Proposed Standard
Errata
Obsoletes:  35885719
Updated by:  70758553
Part 1 of 5 – Pages 1 to 20
None   None   Next

Top   ToC   RFC6733 - Page 1
Internet Engineering Task Force (IETF)                   V. Fajardo, Ed.
Request for Comments: 6733                        Telcordia Technologies
Obsoletes: 3588, 5719                                           J. Arkko
Category: Standards Track                              Ericsson Research
ISSN: 2070-1721                                              J. Loughney
                                                   Nokia Research Center
                                                            G. Zorn, Ed.
                                                             Network Zen
                                                            October 2012


                         Diameter Base Protocol

Abstract

The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6733.
Top   ToC   RFC6733 - Page 2
Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

1. Introduction ....................................................7 1.1. Diameter Protocol ..........................................9 1.1.1. Description of the Document Set ....................10 1.1.2. Conventions Used in This Document ..................11 1.1.3. Changes from RFC 3588 ..............................11 1.2. Terminology ...............................................12 1.3. Approach to Extensibility .................................17 1.3.1. Defining New AVP Values ............................18 1.3.2. Creating New AVPs ..................................18 1.3.3. Creating New Commands ..............................18 1.3.4. Creating New Diameter Applications .................19 2. Protocol Overview ..............................................20 2.1. Transport .................................................22 2.1.1. SCTP Guidelines ....................................23 2.2. Securing Diameter Messages ................................24 2.3. Diameter Application Compliance ...........................24 2.4. Application Identifiers ...................................24 2.5. Connections vs. Sessions ..................................25 2.6. Peer Table ................................................26
Top   ToC   RFC6733 - Page 3
      2.7. Routing Table .............................................27
      2.8. Role of Diameter Agents ...................................28
           2.8.1. Relay Agents .......................................30
           2.8.2. Proxy Agents .......................................31
           2.8.3. Redirect Agents ....................................31
           2.8.4. Translation Agents .................................32
      2.9. Diameter Path Authorization ...............................33
   3. Diameter Header ................................................34
      3.1. Command Codes .............................................37
      3.2. Command Code Format Specification .........................38
      3.3. Diameter Command Naming Conventions .......................40
   4. Diameter AVPs ..................................................40
      4.1. AVP Header ................................................41
           4.1.1. Optional Header Elements ...........................42
      4.2. Basic AVP Data Formats ....................................43
      4.3. Derived AVP Data Formats ..................................44
           4.3.1. Common Derived AVP Data Formats ....................44
      4.4. Grouped AVP Values ........................................51
           4.4.1. Example AVP with a Grouped Data Type ...............52
      4.5. Diameter Base Protocol AVPs ...............................55
   5. Diameter Peers .................................................58
      5.1. Peer Connections ..........................................58
      5.2. Diameter Peer Discovery ...................................59
      5.3. Capabilities Exchange .....................................60
           5.3.1. Capabilities-Exchange-Request ......................62
           5.3.2. Capabilities-Exchange-Answer .......................63
           5.3.3. Vendor-Id AVP ......................................63
           5.3.4. Firmware-Revision AVP ..............................64
           5.3.5. Host-IP-Address AVP ................................64
           5.3.6. Supported-Vendor-Id AVP ............................64
           5.3.7. Product-Name AVP ...................................64
      5.4. Disconnecting Peer Connections ............................64
           5.4.1. Disconnect-Peer-Request ............................65
           5.4.2. Disconnect-Peer-Answer .............................65
           5.4.3. Disconnect-Cause AVP ...............................66
      5.5. Transport Failure Detection ...............................66
           5.5.1. Device-Watchdog-Request ............................67
           5.5.2. Device-Watchdog-Answer .............................67
           5.5.3. Transport Failure Algorithm ........................67
           5.5.4. Failover and Failback Procedures ...................67
      5.6. Peer State Machine ........................................68
           5.6.1. Incoming Connections ...............................71
           5.6.2. Events .............................................71
           5.6.3. Actions ............................................72
           5.6.4. The Election Process ...............................74
Top   ToC   RFC6733 - Page 4
   6. Diameter Message Processing ....................................74
      6.1. Diameter Request Routing Overview .........................74
           6.1.1. Originating a Request ..............................75
           6.1.2. Sending a Request ..................................76
           6.1.3. Receiving Requests .................................76
           6.1.4. Processing Local Requests ..........................76
           6.1.5. Request Forwarding .................................77
           6.1.6. Request Routing ....................................77
           6.1.7. Predictive Loop Avoidance ..........................77
           6.1.8. Redirecting Requests ...............................78
           6.1.9. Relaying and Proxying Requests .....................79
      6.2. Diameter Answer Processing ................................80
           6.2.1. Processing Received Answers ........................81
           6.2.2. Relaying and Proxying Answers ......................81
      6.3. Origin-Host AVP ...........................................81
      6.4. Origin-Realm AVP ..........................................82
      6.5. Destination-Host AVP ......................................82
      6.6. Destination-Realm AVP .....................................82
      6.7. Routing AVPs ..............................................83
           6.7.1. Route-Record AVP ...................................83
           6.7.2. Proxy-Info AVP .....................................83
           6.7.3. Proxy-Host AVP .....................................83
           6.7.4. Proxy-State AVP ....................................83
      6.8. Auth-Application-Id AVP ...................................83
      6.9. Acct-Application-Id AVP ...................................84
      6.10. Inband-Security-Id AVP ...................................84
      6.11. Vendor-Specific-Application-Id AVP .......................84
      6.12. Redirect-Host AVP ........................................85
      6.13. Redirect-Host-Usage AVP ..................................85
      6.14. Redirect-Max-Cache-Time AVP ..............................87
   7. Error Handling .................................................87
      7.1. Result-Code AVP ...........................................89
           7.1.1. Informational ......................................90
           7.1.2. Success ............................................90
           7.1.3. Protocol Errors ....................................90
           7.1.4. Transient Failures .................................92
           7.1.5. Permanent Failures .................................92
      7.2. Error Bit .................................................95
      7.3. Error-Message AVP .........................................96
      7.4. Error-Reporting-Host AVP ..................................96
      7.5. Failed-AVP AVP ............................................96
      7.6. Experimental-Result AVP ...................................97
      7.7. Experimental-Result-Code AVP ..............................97
   8. Diameter User Sessions .........................................98
      8.1. Authorization Session State Machine .......................99
      8.2. Accounting Session State Machine .........................104
Top   ToC   RFC6733 - Page 5
      8.3. Server-Initiated Re-Auth .................................110
           8.3.1. Re-Auth-Request ...................................110
           8.3.2. Re-Auth-Answer ....................................110
      8.4. Session Termination ......................................111
           8.4.1. Session-Termination-Request .......................112
           8.4.2. Session-Termination-Answer ........................113
      8.5. Aborting a Session .......................................113
           8.5.1. Abort-Session-Request .............................114
           8.5.2. Abort-Session-Answer ..............................114
      8.6. Inferring Session Termination from Origin-State-Id .......115
      8.7. Auth-Request-Type AVP ....................................116
      8.8. Session-Id AVP ...........................................116
      8.9. Authorization-Lifetime AVP ...............................117
      8.10. Auth-Grace-Period AVP ...................................118
      8.11. Auth-Session-State AVP ..................................118
      8.12. Re-Auth-Request-Type AVP ................................118
      8.13. Session-Timeout AVP .....................................119
      8.14. User-Name AVP ...........................................119
      8.15. Termination-Cause AVP ...................................120
      8.16. Origin-State-Id AVP .....................................120
      8.17. Session-Binding AVP .....................................120
      8.18. Session-Server-Failover AVP .............................121
      8.19. Multi-Round-Time-Out AVP ................................122
      8.20. Class AVP ...............................................122
      8.21. Event-Timestamp AVP .....................................122
   9. Accounting ....................................................123
      9.1. Server Directed Model ....................................123
      9.2. Protocol Messages ........................................124
      9.3. Accounting Application Extension and Requirements ........124
      9.4. Fault Resilience .........................................125
      9.5. Accounting Records .......................................125
      9.6. Correlation of Accounting Records ........................126
      9.7. Accounting Command Codes .................................127
           9.7.1. Accounting-Request ................................127
           9.7.2. Accounting-Answer .................................128
      9.8. Accounting AVPs ..........................................129
           9.8.1. Accounting-Record-Type AVP ........................129
           9.8.2. Acct-Interim-Interval AVP .........................130
           9.8.3. Accounting-Record-Number AVP ......................131
           9.8.4. Acct-Session-Id AVP ...............................131
           9.8.5. Acct-Multi-Session-Id AVP .........................131
           9.8.6. Accounting-Sub-Session-Id AVP .....................131
           9.8.7. Accounting-Realtime-Required AVP ..................132
   10. AVP Occurrence Tables ........................................132
      10.1. Base Protocol Command AVP Table .........................133
      10.2. Accounting AVP Table ....................................134
Top   ToC   RFC6733 - Page 6
   11. IANA Considerations ..........................................135
      11.1. AVP Header ..............................................135
           11.1.1. AVP Codes ........................................136
           11.1.2. AVP Flags ........................................136
      11.2. Diameter Header .........................................136
           11.2.1. Command Codes ....................................136
           11.2.2. Command Flags ....................................137
      11.3. AVP Values ..............................................137
           11.3.1. Experimental-Result-Code AVP .....................137
           11.3.2. Result-Code AVP Values ...........................137
           11.3.3. Accounting-Record-Type AVP Values ................137
           11.3.4. Termination-Cause AVP Values .....................137
           11.3.5. Redirect-Host-Usage AVP Values ...................137
           11.3.6. Session-Server-Failover AVP Values ...............137
           11.3.7. Session-Binding AVP Values .......................137
           11.3.8. Disconnect-Cause AVP Values ......................138
           11.3.9. Auth-Request-Type AVP Values .....................138
           11.3.10. Auth-Session-State AVP Values ...................138
           11.3.11. Re-Auth-Request-Type AVP Values .................138
           11.3.12. Accounting-Realtime-Required AVP Values .........138
           11.3.13. Inband-Security-Id AVP (code 299) ...............138
      11.4. _diameters Service Name and Port Number Registration ....138
      11.5. SCTP Payload Protocol Identifiers .......................139
      11.6. S-NAPTR Parameters ......................................139
   12. Diameter Protocol-Related Configurable Parameters ............139
   13. Security Considerations ......................................140
      13.1. TLS/TCP and DTLS/SCTP Usage .............................140
      13.2. Peer-to-Peer Considerations .............................141
      13.3. AVP Considerations ......................................141
   14. References ...................................................142
      14.1. Normative References ....................................142
      14.2. Informative References ..................................144
   Appendix A. Acknowledgements .....................................147
     A.1. This Document .............................................147
     A.2. RFC 3588 ..................................................148
   Appendix B. S-NAPTR Example ......................................148
   Appendix C. Duplicate Detection ..................................149
   Appendix D. Internationalized Domain Names .......................151
Top   ToC   RFC6733 - Page 7

1. Introduction

Authentication, Authorization, and Accounting (AAA) protocols such as TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to provide dial-up PPP [RFC1661] and terminal server access. Over time, AAA support was needed on many new access technologies, the scale and complexity of AAA networks grew, and AAA was also used on new applications (such as voice over IP). This led to new demands on AAA protocols. Network access requirements for AAA protocols are summarized in Aboba, et al. [RFC2989]. These include: Failover [RFC2865] does not define failover mechanisms and, as a result, failover behavior differs between implementations. In order to provide well-defined failover behavior, Diameter supports application-layer acknowledgements and defines failover algorithms and the associated state machine. Transmission-level security RADIUS [RFC2865] defines an application-layer authentication and integrity scheme that is required only for use with response packets. While [RFC2869] defines an additional authentication and integrity mechanism, use is only required during Extensible Authentication Protocol (EAP) [RFC3748] sessions. While attribute hiding is supported, [RFC2865] does not provide support for per- packet confidentiality. In accounting, [RFC2866] assumes that replay protection is provided by the backend billing server rather than within the protocol itself. While [RFC3162] defines the use of IPsec with RADIUS, support for IPsec is not required. In order to provide universal support for transmission-level security, and enable both intra- and inter- domain AAA deployments, Diameter provides support for TLS/TCP and DTLS/SCTP. Security is discussed in Section 13. Reliable transport RADIUS runs over UDP, and does not define retransmission behavior; as a result, reliability varies between implementations. As described in [RFC2975], this is a major issue in accounting, where packet loss may translate directly into revenue loss. In order to
Top   ToC   RFC6733 - Page 8
      provide well-defined transport behavior, Diameter runs over
      reliable transport mechanisms (TCP, Stream Control Transmission
      Protocol (SCTP)) as defined in [RFC3539].

   Agent support

      RADIUS does not provide for explicit support for agents, including
      proxies, redirects, and relays.  Since the expected behavior is
      not defined, it varies between implementations.  Diameter defines
      agent behavior explicitly; this is described in Section 2.8.

   Server-initiated messages

      While server-initiated messages are defined in RADIUS [RFC5176],
      support is optional.  This makes it difficult to implement
      features such as unsolicited disconnect or re-authentication/
      re-authorization on demand across a heterogeneous deployment.  To
      address this issue, support for server-initiated messages is
      mandatory in Diameter.

   Transition support

      While Diameter does not share a common protocol data unit (PDU)
      with RADIUS, considerable effort has been expended in enabling
      backward compatibility with RADIUS so that the two protocols may
      be deployed in the same network.  Initially, it is expected that
      Diameter will be deployed within new network devices, as well as
      within gateways enabling communication between legacy RADIUS
      devices and Diameter agents.  This capability enables Diameter
      support to be added to legacy networks, by addition of a gateway
      or server speaking both RADIUS and Diameter.

   In addition to addressing the above requirements, Diameter also
   provides support for the following:

   Capability negotiation

      RADIUS does not support error messages, capability negotiation, or
      a mandatory/non-mandatory flag for attributes.  Since RADIUS
      clients and servers are not aware of each other's capabilities,
      they may not be able to successfully negotiate a mutually
      acceptable service or, in some cases, even be aware of what
      service has been implemented.  Diameter includes support for error
      handling (Section 7), capability negotiation (Section 5.3), and
      mandatory/non-mandatory Attribute-Value Pairs (AVPs)
      (Section 4.1).
Top   ToC   RFC6733 - Page 9
   Peer discovery and configuration

      RADIUS implementations typically require that the name or address
      of servers or clients be manually configured, along with the
      corresponding shared secrets.  This results in a large
      administrative burden and creates the temptation to reuse the
      RADIUS shared secret, which can result in major security
      vulnerabilities if the Request Authenticator is not globally and
      temporally unique as required in [RFC2865].  Through DNS, Diameter
      enables dynamic discovery of peers (see Section 5.2).  Derivation
      of dynamic session keys is enabled via transmission-level
      security.

   Over time, the capabilities of Network Access Server (NAS) devices
   have increased substantially.  As a result, while Diameter is a
   considerably more sophisticated protocol than RADIUS, it remains
   feasible to implement it within embedded devices.

1.1. Diameter Protocol

The Diameter base protocol provides the following facilities: o Ability to exchange messages and deliver AVPs o Capabilities negotiation o Error notification o Extensibility, required in [RFC2989], through addition of new applications, commands, and AVPs o Basic services necessary for applications, such as the handling of user sessions or accounting All data delivered by the protocol is in the form of AVPs. Some of these AVP values are used by the Diameter protocol itself, while others deliver data associated with particular applications that employ Diameter. AVPs may be arbitrarily added to Diameter messages, the only restriction being that the Command Code Format (CCF) specification (Section 3.2) be satisfied. AVPs are used by the base Diameter protocol to support the following required features: o Transporting of user authentication information, for the purposes of enabling the Diameter server to authenticate the user o Transporting of service-specific authorization information, between client and servers, allowing the peers to decide whether a user's access request should be granted
Top   ToC   RFC6733 - Page 10
   o  Exchanging resource usage information, which may be used for
      accounting purposes, capacity planning, etc.

   o  Routing, relaying, proxying, and redirecting of Diameter messages
      through a server hierarchy

   The Diameter base protocol satisfies the minimum requirements for a
   AAA protocol, as specified by [RFC2989].  The base protocol may be
   used by itself for accounting purposes only, or it may be used with a
   Diameter application, such as Mobile IPv4 [RFC4004], or network
   access [RFC4005].  It is also possible for the base protocol to be
   extended for use in new applications, via the addition of new
   commands or AVPs.  The initial focus of Diameter was network access
   and accounting applications.  A truly generic AAA protocol used by
   many applications might provide functionality not provided by
   Diameter.  Therefore, it is imperative that the designers of new
   applications understand their requirements before using Diameter.
   See Section 1.3.4 for more information on Diameter applications.

   Any node can initiate a request.  In that sense, Diameter is a peer-
   to-peer protocol.  In this document, a Diameter client is a device at
   the edge of the network that performs access control, such as a
   Network Access Server (NAS) or a Foreign Agent (FA).  A Diameter
   client generates Diameter messages to request authentication,
   authorization, and accounting services for the user.  A Diameter
   agent is a node that does not provide local user authentication or
   authorization services; agents include proxies, redirects, and relay
   agents.  A Diameter server performs authentication and/or
   authorization of the user.  A Diameter node may act as an agent for
   certain requests while acting as a server for others.

   The Diameter protocol also supports server-initiated messages, such
   as a request to abort service to a particular user.

1.1.1. Description of the Document Set

The Diameter specification consists of an updated version of the base protocol specification (this document) and the Transport Profile [RFC3539]. This document obsoletes both RFC 3588 and RFC 5719. A summary of the base protocol updates included in this document can be found in Section 1.1.3. This document defines the base protocol specification for AAA, which includes support for accounting. There are also a myriad of applications documents describing applications that use this base specification for Authentication, Authorization, and Accounting. These application documents specify how to use the Diameter protocol within the context of their application.
Top   ToC   RFC6733 - Page 11
   The Transport Profile document [RFC3539] discusses transport layer
   issues that arise with AAA protocols and recommendations on how to
   overcome these issues.  This document also defines the Diameter
   failover algorithm and state machine.

   "Clarifications on the Routing of Diameter Request Based on the
   Username and the Realm" [RFC5729] defines specific behavior on how to
   route requests based on the content of the User-Name AVP (Attribute
   Value Pair).

1.1.2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

1.1.3. Changes from RFC 3588

This document obsoletes RFC 3588 but is fully backward compatible with that document. The changes introduced in this document focus on fixing issues that have surfaced during the implementation of Diameter (RFC 3588). An overview of some the major changes are given below. o Deprecated the use of the Inband-Security AVP for negotiating Transport Layer Security (TLS) [RFC5246]. It has been generally considered that bootstrapping of TLS via Inband-Security AVP creates certain security risks because it does not completely protect the information carried in the CER/CEA (Capabilities- Exchange-Request/Capabilities-Exchange-Answer). This version of Diameter adopts the common approach of defining a well-known secured port that peers should use when communicating via TLS/TCP and DTLS/SCTP. This new approach augments the existing in-band security negotiation, but it does not completely replace it. The old method is kept for backward compatibility reasons. o Deprecated the exchange of CER/CEA messages in the open state. This feature was implied in the peer state machine table of RFC 3588, but it was not clearly defined anywhere else in that document. As work on this document progressed, it became clear that the multiplicity of meaning and use of Application-Id AVPs in the CER/CEA messages (and the messages themselves) is seen as an abuse of the Diameter extensibility rules and thus required simplification. Capabilities exchange in the open state has been re-introduced in a separate specification [RFC6737], which clearly defines new commands for this feature.
Top   ToC   RFC6733 - Page 12
   o  Simplified security requirements.  The use of a secured transport
      for exchanging Diameter messages remains mandatory.  However, TLS/
      TCP and DTLS/SCTP have become the primary methods of securing
      Diameter with IPsec as a secondary alternative.  See Section 13
      for details.  The support for the End-to-End security framework
      (E2E-Sequence AVP and 'P'-bit in the AVP header) has also been
      deprecated.

   o  Changed Diameter extensibility.  This includes fixes to the
      Diameter extensibility description (Section 1.3 and others) to
      better aid Diameter application designers; in addition, the new
      specification relaxes the policy with respect to the allocation of
      Command Codes for vendor-specific uses.

   o  Clarified Application Id usage.  Clarify the proper use of
      Application Id information, which can be found in multiple places
      within a Diameter message.  This includes correlating Application
      Ids found in the message headers and AVPs.  These changes also
      clearly specify the proper Application Id value to use for
      specific base protocol messages (ASR/ASA, STR/STA) as well as
      clarify the content and use of Vendor-Specific-Application-Id.

   o  Clarified routing fixes.  This document more clearly specifies
      what information (AVPs and Application Ids) can be used for making
      general routing decisions.  A rule for the prioritization of
      redirect routing criteria when multiple route entries are found
      via redirects has also been added (see Section 6.13).

   o  Simplified Diameter peer discovery.  The Diameter discovery
      process now supports only widely used discovery schemes; the rest
      have been deprecated (see Section 5.2 for details).

   There are many other miscellaneous fixes that have been introduced in
   this document that may not be considered significant, but they have
   value nonetheless.  Examples are removal of obsolete types, fixes to
   the state machine, clarification of the election process, message
   validation, fixes to Failed-AVP and Result-Code AVP values, etc.  All
   of the errata filed against RFC 3588 prior to the publication of this
   document have been addressed.  A comprehensive list of changes is not
   shown here for practical reasons.

1.2. Terminology

AAA Authentication, Authorization, and Accounting.
Top   ToC   RFC6733 - Page 13
   ABNF

      Augmented Backus-Naur Form [RFC5234].  A metalanguage with its own
      formal syntax and rules.  It is based on the Backus-Naur Form and
      is used to define message exchanges in a bi-directional
      communications protocol.

   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).

   Attribute-Value Pair (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.

   Command Code Format (CCF)

      A modified form of ABNF used to define Diameter commands (see
      Section 3.2).

   Diameter Agent

      A Diameter Agent is a Diameter node that provides relay, proxy,
      redirect, or translation services.
Top   ToC   RFC6733 - Page 14
   Diameter Client

      A Diameter client is a Diameter node that supports Diameter client
      applications as well as the base protocol.  Diameter clients are
      often implemented in devices situated at the edge of a network and
      provide access control services for that network.  Typical
      examples of Diameter clients include the Network Access Server
      (NAS) and the Mobile IP Foreign Agent (FA).

   Diameter Node

      A Diameter node is a host process that implements the Diameter
      protocol and acts as either a client, an agent, or a server.

   Diameter Peer

      Two Diameter nodes sharing a direct TCP or SCTP transport
      connection are called Diameter peers.

   Diameter Server

      A Diameter server is a Diameter node that handles authentication,
      authorization, and accounting requests for a particular realm.  By
      its very nature, a Diameter server must support Diameter server
      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 Diameter client.

   Home Realm

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

   Home Server

      A Diameter server that serves the Home Realm.

   Interim Accounting

      An interim accounting message provides a snapshot of usage during
      a user's session.  Typically, it is implemented in order to
      provide for partial accounting of a user's session in case a
      device reboot or other network problem prevents the delivery of a
      session summary message or session record.
Top   ToC   RFC6733 - Page 15
   Local Realm

      A local realm is the administrative domain providing services to a
      user.  An administrative domain may act as a local realm for
      certain users while being a home realm for others.

   Multi-session

      A multi-session represents a logical linking of several sessions.
      Multi-sessions are tracked by using the Acct-Multi-Session-Id.  An
      example of a multi-session would be a Multi-link PPP bundle.  Each
      leg of the bundle would be a session while the entire bundle would
      be a multi-session.

   Network Access Identifier

      The Network Access Identifier, or NAI [RFC4282], is used in the
      Diameter protocol to extract a user's identity and realm.  The
      identity is used to identify the user during authentication and/or
      authorization while the realm is used for message routing
      purposes.

   Proxy Agent or Proxy

      In addition to forwarding requests and responses, proxies make
      policy decisions relating to resource usage and provisioning.
      Typically, this is accomplished by tracking the state of NAS
      devices.  While proxies usually do not respond to client requests
      prior to receiving a response from the server, they may originate
      Reject messages in cases where policies are violated.  As a
      result, proxies need to understand the semantics of the messages
      passing through them, and they may not support all Diameter
      applications.

   Realm

      The string in the NAI that immediately follows the '@' character.
      NAI realm names are required to be unique and are piggybacked on
      the administration of the DNS namespace.  Diameter makes use of
      the realm, also loosely referred to as domain, to determine
      whether messages can be satisfied locally or whether they must be
      routed or redirected.  In RADIUS, realm names are not necessarily
      piggybacked on the DNS namespace but may be independent of it.
Top   ToC   RFC6733 - Page 16
   Real-Time Accounting

      Real-time accounting involves the processing of information on
      resource usage within a defined time window.  Typically, time
      constraints are imposed in order to limit financial risk.  The
      Diameter Credit-Control Application [RFC4006] is an example of an
      application that defines real-time accounting functionality.

   Relay Agent or Relay

      Relays forward requests and responses based on routing-related
      AVPs and routing table entries.  Since relays do not make policy
      decisions, they do not examine or alter non-routing AVPs.  As a
      result, relays never originate messages, do not need to understand
      the semantics of messages or non-routing AVPs, and are capable of
      handling any Diameter application or message type.  Since relays
      make decisions based on information in routing AVPs and realm
      forwarding tables, they do not keep state on NAS resource usage or
      sessions in progress.

   Redirect Agent

      Rather than forwarding requests and responses between clients and
      servers, redirect agents refer clients to servers and allow them
      to communicate directly.  Since redirect agents do not sit in the
      forwarding path, they do not alter any AVPs transiting between
      client and server.  Redirect agents do not originate messages and
      are capable of handling any message type, although they may be
      configured only to redirect messages of certain types, while
      acting as relay or proxy agents for other types.  As with relay
      agents, redirect agents do not keep state with respect to sessions
      or NAS resources.

   Session

      A session is a related progression of events devoted to a
      particular activity.  Diameter application documents provide
      guidelines as to when a session begins and ends.  All Diameter
      packets with the same Session-Id are considered to be part of the
      same session.

   Stateful Agent

      A stateful agent is one that maintains session state information,
      by keeping track of all authorized active sessions.  Each
      authorized session is bound to a particular service, and its state
      is considered active either until it is notified otherwise or
      until expiration.
Top   ToC   RFC6733 - Page 17
   Sub-session

      A sub-session represents a distinct service (e.g., QoS or data
      characteristics) provided to a given session.  These services may
      happen concurrently (e.g., simultaneous voice and data transfer
      during the same session) or serially.  These changes in sessions
      are tracked with the Accounting-Sub-Session-Id.

   Transaction State

      The Diameter protocol requires that agents maintain transaction
      state, which is used for failover purposes.  Transaction state
      implies that upon forwarding a request, the Hop-by-Hop Identifier
      is saved; the field is replaced with a locally unique identifier,
      which is restored to its original value when the corresponding
      answer is received.  The request's state is released upon receipt
      of the answer.  A stateless agent is one that only maintains
      transaction state.

   Translation Agent

      A translation agent (TLA in Figure 4) is a stateful Diameter node
      that performs protocol translation between Diameter and another
      AAA protocol, such as RADIUS.

   Upstream

      Upstream is used to identify the direction of a particular
      Diameter message from the Diameter client towards the home server.

   User

      The entity or device requesting or using some resource, in support
      of which a Diameter client has generated a request.

1.3. Approach to Extensibility

The Diameter protocol is designed to be extensible, using several mechanisms, including: o Defining new AVP values o Creating new AVPs o Creating new commands o Creating new applications
Top   ToC   RFC6733 - Page 18
   From the point of view of extensibility, Diameter authentication,
   authorization, and accounting applications are treated in the same
   way.

   Note: Protocol designers should try to reuse existing functionality,
   namely AVP values, AVPs, commands, and Diameter applications.  Reuse
   simplifies standardization and implementation.  To avoid potential
   interoperability issues, it is important to ensure that the semantics
   of the reused features are well understood.  Given that Diameter can
   also carry RADIUS attributes as Diameter AVPs, such reuse
   considerations also apply to existing RADIUS attributes that may be
   useful in a Diameter application.

1.3.1. Defining New AVP Values

In order to allocate a new AVP value for AVPs defined in the Diameter base protocol, the IETF needs to approve a new RFC that describes the AVP value. IANA considerations for these AVP values are discussed in Section 11.3. The allocation of AVP values for other AVPs is guided by the IANA considerations of the document that defines those AVPs. Typically, allocation of new values for an AVP defined in an RFC would require IETF Review [RFC5226], whereas values for vendor-specific AVPs can be allocated by the vendor.

1.3.2. Creating New AVPs

A new AVP being defined MUST use one of the data types listed in Sections 4.2 or 4.3. If an appropriate derived data type is already defined, it SHOULD be used instead of a base data type to encourage reusability and good design practice. 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). The creation of new AVPs can happen in various ways. The recommended approach is to define a new general-purpose AVP in a Standards Track RFC approved by the IETF. However, as described in Section 11.1.1, there are other mechanisms.

1.3.3. Creating New Commands

A new Command Code MUST be allocated when required AVPs (those indicated as {AVP} in the CCF definition) are added to, deleted from, or redefined in (for example, by changing a required AVP into an optional one) an existing command.
Top   ToC   RFC6733 - Page 19
   Furthermore, if the transport characteristics of a command are
   changed (for example, with respect to the number of round trips
   required), a new Command Code MUST be registered.

   A change to the CCF of a command, such as described above, MUST
   result in the definition of a new Command Code.  This subsequently
   leads to the need to define a new Diameter application for any
   application that will use that new command.

   The IANA considerations for Command Codes are discussed in
   Section 3.1.

1.3.4. Creating New Diameter Applications

Every Diameter application specification MUST have an IANA-assigned Application Id (see Section 2.4). The managed Application ID space is flat, and there is no relationship between different Diameter applications with respect to their Application Ids. As such, there is no versioning support provided by these Application Ids themselves; every Diameter application is a standalone application. If the application has a relationship with other Diameter applications, such a relationship is not known to Diameter. Before describing the rules for creating new Diameter applications, it is important to discuss the semantics of the AVP occurrences as stated in the CCF and the M-bit flag (Section 4.1) for an AVP. There is no relationship imposed between the two; they are set independently. o The CCF indicates what AVPs are placed into a Diameter command by the sender of that command. Often, since there are multiple modes of protocol interactions, many of the AVPs are indicated as optional. o The M-bit allows the sender to indicate to the receiver whether or not understanding the semantics of an AVP and its content is mandatory. If the M-bit is set by the sender and the receiver does not understand the AVP or the values carried within that AVP, then a failure is generated (see Section 7). It is the decision of the protocol designer when to develop a new Diameter application rather than extending Diameter in other ways. However, a new Diameter application MUST be created when one or more of the following criteria are met:
Top   ToC   RFC6733 - Page 20
   M-bit Setting

      An AVP with the M-bit in the MUST column of the AVP flag table is
      added to an existing Command/Application.  An AVP with the M-bit
      in the MAY column of the AVP flag table is added to an existing
      Command/Application.

      Note: The M-bit setting for a given AVP is relevant to an
      Application and each command within that application that includes
      the AVP.  That is, if an AVP appears in two commands for
      application Foo and the M-bit settings are different in each
      command, then there should be two AVP flag tables describing when
      to set the M-bit.

   Commands

      A new command is used within the existing application because
      either an additional command is added, an existing command has
      been modified so that a new Command Code had to be registered, or
      a command has been deleted.

   AVP Flag bits

      If an existing application changes the meaning/semantics of its
      AVP Flags or adds new flag bits, then a new Diameter application
      MUST be created.

   If the CCF definition of a command allows it, an implementation may
   add arbitrary optional AVPs with the M-bit cleared (including vendor-
   specific AVPs) to that command without needing to define a new
   application.  Please refer to Section 11.1.1 for details.



(page 20 continued on part 2)

Next Section