Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6733


Diameter Base Protocol

Part 5 of 5, p. 123 to 152
Prev RFC Part


prevText      Top      Up      ToC       Page 123 
9.  Accounting

   This accounting protocol is based on a server directed model with
   capabilities for real-time delivery of accounting information.
   Several fault resilience methods [RFC2975] have been built into the
   protocol in order minimize loss of accounting data in various fault
   situations and under different assumptions about the capabilities of
   the used devices.

9.1.  Server Directed Model

   The server directed model means that the device generating the
   accounting data gets information from either the authorization server
   (if contacted) or the accounting server regarding the way accounting
   data shall be forwarded.  This information includes accounting record
   timeliness requirements.

   As discussed in [RFC2975], real-time transfer of accounting records
   is a requirement, such as the need to perform credit-limit checks and
   fraud detection.  Note that batch accounting is not a requirement,
   and is therefore not supported by Diameter.  Should batched
   accounting be required in the future, a new Diameter application will
   need to be created, or it could be handled using another protocol.
   Note, however, that even if at the Diameter layer, accounting
   requests are processed one by one; transport protocols used under
   Diameter typically batch several requests in the same packet under
   heavy traffic conditions.  This may be sufficient for many

   The authorization server (chain) directs the selection of proper
   transfer strategy, based on its knowledge of the user and
   relationships of roaming partnerships.  The server (or agents) uses
   the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to
   control the operation of the Diameter peer operating as a client.
   The Acct-Interim-Interval AVP, when present, instructs the Diameter
   node acting as a client to produce accounting records continuously
   even during a session.  Accounting-Realtime-Required AVP is used to
   control the behavior of the client when the transfer of accounting
   records from the Diameter client is delayed or unsuccessful.

   The Diameter accounting server MAY override the interim interval or
   the real-time requirements by including the Acct-Interim-Interval or
   Accounting-Realtime-Required AVP in the Accounting-Answer message.
   When one of these AVPs is present, the latest value received SHOULD
   be used in further accounting activities for the same session.

Top      Up      ToC       Page 124 
9.2.  Protocol Messages

   A Diameter node that receives a successful authentication and/or
   authorization message from the Diameter server SHOULD collect
   accounting information for the session.  The Accounting-Request
   message is used to transmit the accounting information to the
   Diameter server, which MUST reply with the Accounting-Answer message
   to confirm reception.  The Accounting-Answer message includes the
   Result-Code AVP, which MAY indicate that an error was present in the
   accounting message.  The value of the Accounting-Realtime-Required
   AVP received earlier for the session in question may indicate that
   the user's session has to be terminated when a rejected Accounting-
   Request message was received.

9.3.  Accounting Application Extension and Requirements

   Each Diameter application (e.g., NASREQ, Mobile IP) SHOULD define its
   service-specific AVPs that MUST be present in the Accounting-Request
   message in a section titled "Accounting AVPs".  The application MUST
   assume that the AVPs described in this document will be present in
   all Accounting messages, so only their respective service-specific
   AVPs need to be defined in that section.

   Applications have the option of using one or both of the following
   accounting application extension models:

   Split Accounting Service

      The accounting message will carry the Application Id of the
      Diameter base accounting application (see Section 2.4).
      Accounting messages may be routed to Diameter nodes other than the
      corresponding Diameter application.  These nodes might be
      centralized accounting servers that provide accounting service for
      multiple different Diameter applications.  These nodes MUST
      advertise the Diameter base accounting Application Id during
      capabilities exchange.

   Coupled Accounting Service

      The accounting message will carry the Application Id of the
      application that is using it.  The application itself will process
      the received accounting records or forward them to an accounting
      server.  There is no accounting application advertisement required
      during capabilities exchange, and the accounting messages will be
      routed the same way as any of the other application messages.

   In cases where an application does not define its own accounting
   service, it is preferred that the split accounting model be used.

Top      Up      ToC       Page 125 
9.4.  Fault Resilience

   Diameter base protocol mechanisms are used to overcome small message
   loss and network faults of a temporary nature.

   Diameter peers acting as clients MUST implement the use of failover
   to guard against server failures and certain network failures.
   Diameter peers acting as agents or related off-line processing
   systems MUST detect duplicate accounting records caused by the
   sending of the same record to several servers and duplication of
   messages in transit.  This detection MUST be based on the inspection
   of the Session-Id and Accounting-Record-Number AVP pairs.  Appendix C
   discusses duplicate detection needs and implementation issues.

   Diameter clients MAY have non-volatile memory for the safe storage of
   accounting records over reboots or extended network failures, network
   partitions, and server failures.  If such memory is available, the
   client SHOULD store new accounting records there as soon as the
   records are created and until a positive acknowledgement of their
   reception from the Diameter server has been received.  Upon a reboot,
   the client MUST start sending the records in the non-volatile memory
   to the accounting server with the appropriate modifications in
   termination cause, session length, and other relevant information in
   the records.

   A further application of this protocol may include AVPs to control
   the maximum number of accounting records that may be stored in the
   Diameter client without committing them to the non-volatile memory or
   transferring them to the Diameter server.

   The client SHOULD NOT remove the accounting data from any of its
   memory areas before the correct Accounting-Answer has been received.
   The client MAY remove the oldest, undelivered, or as yet
   unacknowledged accounting data if it runs out of resources such as
   memory.  It is an implementation-dependent matter for the client to
   accept new sessions under this condition.

9.5.  Accounting Records

   In all accounting records, the Session-Id AVP MUST be present; the
   User-Name AVP MUST be present if it is available to the Diameter

   Different types of accounting records are sent depending on the
   actual type of accounted service and the authorization server's
   directions for interim accounting.  If the accounted service is a

Top      Up      ToC       Page 126 
   one-time event, meaning that the start and stop of the event are
   simultaneous, then the Accounting-Record-Type AVP MUST be present and
   set to the value EVENT_RECORD.

   If the accounted service is of a measurable length, then the AVP MUST
   use the values START_RECORD, STOP_RECORD, and possibly,
   INTERIM_RECORD.  If the authorization server has not directed interim
   accounting to be enabled for the session, two accounting records MUST
   be generated for each service of type session.  When the initial
   Accounting-Request for a given session is sent, the Accounting-
   Record-Type AVP MUST be set to the value START_RECORD.  When the last
   Accounting-Request is sent, the value MUST be STOP_RECORD.

   If the authorization server has directed interim accounting to be
   enabled, the Diameter client MUST produce additional records between
   production of these records is directed by Acct-Interim-Interval as
   well as any re-authentication or re-authorization of the session.
   The Diameter client MUST overwrite any previous interim accounting
   records that are locally stored for delivery, if a new record is
   being generated for the same session.  This ensures that only one
   pending interim record can exist on an access device for any given

   A particular value of Accounting-Sub-Session-Id MUST appear only in
   one sequence of accounting records from a Diameter client, except for
   the purposes of retransmission.  The one sequence that is sent MUST
   be either one record with Accounting-Record-Type AVP set to the value
   EVENT_RECORD or several records starting with one having the value
   START_RECORD, followed by zero or more INTERIM_RECORDs and a single
   STOP_RECORD.  A particular Diameter application specification MUST
   define the type of sequences that MUST be used.

9.6.  Correlation of Accounting Records

   If an application uses accounting messages, it can correlate
   accounting records with a specific application session by using the
   Session-Id of the particular application session in the accounting
   messages.  Accounting messages MAY also use a different Session-Id
   from that of the application sessions, in which case, other session-
   related information is needed to perform correlation.

   In cases where an application requires multiple accounting sub-
   sessions, an Accounting-Sub-Session-Id AVP is used to differentiate
   each sub-session.  The Session-Id would remain constant for all sub-
   sessions and is used to correlate all the sub-sessions to a
   particular application session.  Note that receiving a STOP_RECORD

Top      Up      ToC       Page 127 
   with no Accounting-Sub-Session-Id AVP when sub-sessions were
   originally used in the START_RECORD messages implies that all sub-
   sessions are terminated.

   There are also cases where an application needs to correlate multiple
   application sessions into a single accounting record; the accounting
   record may span multiple different Diameter applications and sessions
   used by the same user at a given time.  In such cases, the Acct-
   Multi-Session-Id AVP is used.  The Acct-Multi-Session-Id AVP SHOULD
   be signaled by the server to the access device (typically, during
   authorization) when it determines that a request belongs to an
   existing session.  The access device MUST then include the Acct-
   Multi-Session-Id AVP in all subsequent accounting messages.

   The Acct-Multi-Session-Id AVP MAY include the value of the original
   Session-Id.  Its contents are implementation specific, but the MUST
   be globally unique across other Acct-Multi-Session-Ids and MUST NOT
   change during the life of a session.

   A Diameter application document MUST define the exact concept of a
   session that is being accounted, and it MAY define the concept of a
   multi-session.  For instance, the NASREQ DIAMETER application treats
   a single PPP connection to a Network Access Server as one session and
   a set of Multilink PPP sessions as one multi-session.

9.7.  Accounting Command Codes

   This section defines Command Code values that MUST be supported by
   all Diameter implementations that provide accounting services.

9.7.1.  Accounting-Request

   The Accounting-Request (ACR) command, indicated by the Command Code
   field set to 271 and the Command Flags' 'R' bit set, is sent by a
   Diameter node, acting as a client, in order to exchange accounting
   information with a peer.

   In addition to the AVPs listed below, Accounting-Request messages
   SHOULD include service-specific accounting AVPs.

Top      Up      ToC       Page 128 
      Message Format

         <ACR> ::= < Diameter Header: 271, REQ, PXY >
                   < Session-Id >
                   { Origin-Host }
                   { Origin-Realm }
                   { Destination-Realm }
                   { Accounting-Record-Type }
                   { Accounting-Record-Number }
                   [ Acct-Application-Id ]
                   [ Vendor-Specific-Application-Id ]
                   [ User-Name ]
                   [ Destination-Host ]
                   [ Accounting-Sub-Session-Id ]
                   [ Acct-Session-Id ]
                   [ Acct-Multi-Session-Id ]
                   [ Acct-Interim-Interval ]
                   [ Accounting-Realtime-Required ]
                   [ Origin-State-Id ]
                   [ Event-Timestamp ]
                 * [ Proxy-Info ]
                 * [ Route-Record ]
                 * [ AVP ]

9.7.2.  Accounting-Answer

   The Accounting-Answer (ACA) command, indicated by the Command Code
   field set to 271 and the Command Flags' 'R' bit cleared, is used to
   acknowledge an Accounting-Request command.  The Accounting-Answer
   command contains the same Session-Id as the corresponding request.

   Only the target Diameter server, known as the home Diameter server,
   SHOULD respond with the Accounting-Answer command.

   In addition to the AVPs listed below, Accounting-Answer messages
   SHOULD include service-specific accounting AVPs.

Top      Up      ToC       Page 129 
      Message Format

         <ACA> ::= < Diameter Header: 271, PXY >
                   < Session-Id >
                   { Result-Code }
                   { Origin-Host }
                   { Origin-Realm }
                   { Accounting-Record-Type }
                   { Accounting-Record-Number }
                   [ Acct-Application-Id ]
                   [ Vendor-Specific-Application-Id ]
                   [ User-Name ]
                   [ Accounting-Sub-Session-Id ]
                   [ Acct-Session-Id ]
                   [ Acct-Multi-Session-Id ]
                   [ Error-Message ]
                   [ Error-Reporting-Host ]
                   [ Failed-AVP ]
                   [ Acct-Interim-Interval ]
                   [ Accounting-Realtime-Required ]
                   [ Origin-State-Id ]
                   [ Event-Timestamp ]
                 * [ Proxy-Info ]
                 * [ AVP ]

9.8.  Accounting AVPs

   This section contains AVPs that describe accounting usage information
   related to a specific session.

9.8.1.  Accounting-Record-Type AVP

   The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated
   and contains the type of accounting record being sent.  The following
   values are currently defined for the Accounting-Record-Type AVP:


      An Accounting Event Record is used to indicate that a one-time
      event has occurred (meaning that the start and end of the event
      are simultaneous).  This record contains all information relevant
      to the service, and it is the only record of the service.

Top      Up      ToC       Page 130 

      Accounting Start, Interim, and Stop Records are used to indicate
      that a service of a measurable length has been given.  An
      Accounting Start Record is used to initiate an accounting session
      and contains accounting information that is relevant to the
      initiation of the session.


      An Interim Accounting Record contains cumulative accounting
      information for an existing accounting session.  Interim
      Accounting Records SHOULD be sent every time a re-authentication
      or re-authorization occurs.  Further, additional interim record
      triggers MAY be defined by application-specific Diameter
      applications.  The selection of whether to use INTERIM_RECORD
      records is done by the Acct-Interim-Interval AVP.


      An Accounting Stop Record is sent to terminate an accounting
      session and contains cumulative accounting information relevant to
      the existing session.

9.8.2.  Acct-Interim-Interval AVP

   The Acct-Interim-Interval AVP (AVP Code 85) is of type Unsigned32 and
   is sent from the Diameter home authorization server to the Diameter
   client.  The client uses information in this AVP to decide how and
   when to produce accounting records.  With different values in this
   AVP, service sessions can result in one, two, or two+N accounting
   records, based on the needs of the home organization.  The following
   accounting record production behavior is directed by the inclusion of
   this AVP:

   1.  The omission of the Acct-Interim-Interval AVP or its inclusion
       with Value field set to 0 means that EVENT_RECORD, START_RECORD,
       and STOP_RECORD are produced, as appropriate for the service.

   2.  The inclusion of the AVP with Value field set to a non-zero value
       means that INTERIM_RECORD records MUST be produced between the
       START_RECORD and STOP_RECORD records.  The Value field of this
       AVP is the nominal interval between these records in seconds.
       The Diameter node that originates the accounting information,
       known as the client, MUST produce the first INTERIM_RECORD record
       roughly at the time when this nominal interval has elapsed from

Top      Up      ToC       Page 131 
       the START_RECORD, the next one again as the interval has elapsed
       once more, and so on until the session ends and a STOP_RECORD
       record is produced.

       The client MUST ensure that the interim record production times
       are randomized so that large accounting message storms are not
       created either among records or around a common service start

9.8.3.   Accounting-Record-Number AVP

   The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32
   and identifies this record within one session.  As Session-Id AVPs
   are globally unique, the combination of Session-Id and Accounting-
   Record-Number AVPs is also globally unique and can be used in
   matching accounting records with confirmations.  An easy way to
   produce unique numbers is to set the value to 0 for records of type
   EVENT_RECORD and START_RECORD and set the value to 1 for the first
   INTERIM_RECORD, 2 for the second, and so on until the value for
   STOP_RECORD is one more than for the last INTERIM_RECORD.

9.8.4.  Acct-Session-Id AVP

   The Acct-Session-Id AVP (AVP Code 44) is of type OctetString is only
   used when RADIUS/Diameter translation occurs.  This AVP contains the
   contents of the RADIUS Acct-Session-Id attribute.

9.8.5.  Acct-Multi-Session-Id AVP

   The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String,
   following the format specified in Section 8.8.  The Acct-Multi-
   Session-Id AVP is used to link multiple related accounting sessions,
   where each session would have a unique Session-Id but the same Acct-
   Multi-Session-Id AVP.  This AVP MAY be returned by the Diameter
   server in an authorization answer, and it MUST be used in all
   accounting messages for the given session.

9.8.6.  Accounting-Sub-Session-Id AVP

   The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type
   Unsigned64 and contains the accounting sub-session identifier.  The
   combination of the Session-Id and this AVP MUST be unique per sub-
   session, and the value of this AVP MUST be monotonically increased by
   one for all new sub-sessions.  The absence of this AVP implies no
   sub-sessions are in use, with the exception of an Accounting-Request
   whose Accounting-Record-Type is set to STOP_RECORD.  A STOP_RECORD
   message with no Accounting-Sub-Session-Id AVP present will signal the
   termination of all sub-sessions for a given Session-Id.

Top      Up      ToC       Page 132 
9.8.7.   Accounting-Realtime-Required AVP

   The Accounting-Realtime-Required AVP (AVP Code 483) is of type
   Enumerated and is sent from the Diameter home authorization server to
   the Diameter client or in the Accounting-Answer from the accounting
   server.  The client uses information in this AVP to decide what to do
   if the sending of accounting records to the accounting server has
   been temporarily prevented due to, for instance, a network problem.


      The AVP with Value field set to DELIVER_AND_GRANT means that the
      service MUST only be granted as long as there is a connection to
      an accounting server.  Note that the set of alternative accounting
      servers are treated as one server in this sense.  Having to move
      the accounting record stream to a backup server is not a reason to
      discontinue the service to the user.


      The AVP with Value field set to GRANT_AND_STORE means that service
      SHOULD be granted if there is a connection, or as long as records
      can still be stored as described in Section 9.4.

      This is the default behavior if the AVP isn't included in the
      reply from the authorization server.


      The AVP with Value field set to GRANT_AND_LOSE means that service
      SHOULD be granted even if the records cannot be delivered or

10.  AVP Occurrence Tables

   The following tables present the AVPs defined in this document and
   specify in which Diameter messages they MAY or MAY NOT be present.
   AVPs that occur only inside a Grouped AVP are not shown in these

   The tables use the following symbols:

   0     The AVP MUST NOT be present in the message.

   0+    Zero or more instances of the AVP MAY be present in the

Top      Up      ToC       Page 133 
   0-1   Zero or one instance of the AVP MAY be present in the message.
         It is considered an error if there are more than one instance
         of the AVP.

   1     One instance of the AVP MUST be present in the message.

   1+    At least one instance of the AVP MUST be present in the

10.1.  Base Protocol Command AVP Table

   The table in this section is limited to the non-Accounting Command
   Codes defined in this specification.

                       |                  Command Code                 |
   Acct-Interim-       |0  |0  |0  |0  |0  |0  |0-1|0  |0  |0  |0  |0  |
     Interval          |   |   |   |   |   |   |   |   |   |   |   |   |
   Accounting-Realtime-|0  |0  |0  |0  |0  |0  |0-1|0  |0  |0  |0  |0  |
     Required          |   |   |   |   |   |   |   |   |   |   |   |   |
   Acct-Application-Id |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Auth-Application-Id |0+ |0+ |0  |0  |0  |0  |1  |0  |1  |0  |1  |0  |
   Auth-Grace-Period   |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Auth-Request-Type   |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Auth-Session-State  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Authorization-      |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
     Lifetime          |   |   |   |   |   |   |   |   |   |   |   |   |
   Class               |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0+ |0+ |
   Destination-Host    |0  |0  |0  |0  |0  |0  |1  |0  |1  |0  |0-1|0  |
   Destination-Realm   |0  |0  |0  |0  |0  |0  |1  |0  |1  |0  |1  |0  |
   Disconnect-Cause    |0  |0  |1  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Error-Message       |0  |0-1|0  |0-1|0  |0-1|0  |0-1|0  |0-1|0  |0-1|
   Error-Reporting-Host|0  |0  |0  |0  |0  |0  |0  |0-1|0  |0-1|0  |0-1|
   Failed-AVP          |0  |0-1|0  |0-1|0  |0-1|0  |0-1|0  |0-1|0  |0-1|
   Firmware-Revision   |0-1|0-1|0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Host-IP-Address     |1+ |1+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Inband-Security-Id  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Multi-Round-Time-Out|0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |

Top      Up      ToC       Page 134 
   Origin-Host         |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |
   Origin-Realm        |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |
   Origin-State-Id     |0-1|0-1|0  |0  |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
   Product-Name        |1  |1  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Proxy-Info          |0  |0  |0  |0  |0  |0  |0+ |0+ |0+ |0+ |0+ |0+ |
   Redirect-Host       |0  |0  |0  |0  |0  |0  |0  |0+ |0  |0+ |0  |0+ |
   Redirect-Host-Usage |0  |0  |0  |0  |0  |0  |0  |0-1|0  |0-1|0  |0-1|
   Redirect-Max-Cache- |0  |0  |0  |0  |0  |0  |0  |0-1|0  |0-1|0  |0-1|
     Time              |   |   |   |   |   |   |   |   |   |   |   |   |
   Result-Code         |0  |1  |0  |1  |0  |1  |0  |1  |0  |1  |0  |1  |
   Re-Auth-Request-Type|0  |0  |0  |0  |0  |0  |1  |0  |0  |0  |0  |0  |
   Route-Record        |0  |0  |0  |0  |0  |0  |0+ |0  |0+ |0  |0+ |0  |
   Session-Binding     |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Session-Id          |0  |0  |0  |0  |0  |0  |1  |1  |1  |1  |1  |1  |
   Session-Server-     |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
     Failover          |   |   |   |   |   |   |   |   |   |   |   |   |
   Session-Timeout     |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Supported-Vendor-Id |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Termination-Cause   |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |1  |0  |
   User-Name           |0  |0  |0  |0  |0  |0  |0-1|0-1|0-1|0-1|0-1|0-1|
   Vendor-Id           |1  |1  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Vendor-Specific-    |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
     Application-Id    |   |   |   |   |   |   |   |   |   |   |   |   |

10.2.  Accounting AVP Table

   The table in this section is used to represent which AVPs defined in
   this document are to be present in the Accounting messages.  These
   AVP occurrence requirements are guidelines, which may be expanded,
   and/or overridden by application-specific requirements in the
   Diameter applications documents.

Top      Up      ToC       Page 135 
                                    |  Command  |
                                    |    Code   |
      Attribute Name                | ACR | ACA |
      Acct-Interim-Interval         | 0-1 | 0-1 |
      Acct-Multi-Session-Id         | 0-1 | 0-1 |
      Accounting-Record-Number      | 1   | 1   |
      Accounting-Record-Type        | 1   | 1   |
      Acct-Session-Id               | 0-1 | 0-1 |
      Accounting-Sub-Session-Id     | 0-1 | 0-1 |
      Accounting-Realtime-Required  | 0-1 | 0-1 |
      Acct-Application-Id           | 0-1 | 0-1 |
      Auth-Application-Id           | 0   | 0   |
      Class                         | 0+  | 0+  |
      Destination-Host              | 0-1 | 0   |
      Destination-Realm             | 1   | 0   |
      Error-Reporting-Host          | 0   | 0+  |
      Event-Timestamp               | 0-1 | 0-1 |
      Failed-AVP                    | 0   | 0-1 |
      Origin-Host                   | 1   | 1   |
      Origin-Realm                  | 1   | 1   |
      Proxy-Info                    | 0+  | 0+  |
      Route-Record                  | 0+  | 0   |
      Result-Code                   | 0   | 1   |
      Session-Id                    | 1   | 1   |
      Termination-Cause             | 0   | 0   |
      User-Name                     | 0-1 | 0-1 |
      Vendor-Specific-Application-Id| 0-1 | 0-1 |

11.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the
   Diameter protocol, in accordance with [RFC5226].  Existing IANA
   registries and assignments put in place by RFC 3588 remain the same
   unless explicitly updated or deprecated in this section.

11.1.  AVP Header

   As defined in Section 4, the AVP header contains three fields that
   require IANA namespace management: the AVP Code, Vendor-ID, and Flags

Top      Up      ToC       Page 136 
11.1.1.  AVP Codes

   There are multiple namespaces.  Vendors can have their own AVP Codes
   namespace that will be identified by their Vendor-ID (also known as
   Enterprise-Number), and they control the assignments of their vendor-
   specific AVP Codes within their own namespace.  The absence of a
   Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF AVP
   Codes namespace, which is under IANA control.  The AVP Codes and
   sometimes possible values in an AVP are controlled and maintained by
   IANA.  AVP Code 0 is not used.  AVP Codes 1-255 are managed
   separately as RADIUS Attribute Types.  Where a Vendor-Specific AVP is
   implemented by more than one vendor, allocation of global AVPs should
   be encouraged instead.

   AVPs may be allocated following Expert Review (by a Designated
   Expert) with Specification Required [RFC5226].  A block allocation
   (release of more than three AVPs at a time for a given purpose)
   requires IETF Review [RFC5226].

11.1.2.  AVP Flags

   Section 4.1 describes the existing AVP Flags.  The remaining bits can
   only be assigned via a Standards Action [RFC5226].

11.2.  Diameter Header

11.2.1.  Command Codes

   For the Diameter header, the Command Code namespace allocation has
   changed.  The new allocation rules are as follows:

      The Command Code values 256 - 8,388,607 (0x100 to 0x7fffff) are
      for permanent, standard commands, allocated by IETF Review

      The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are
      reserved for vendor-specific Command Codes, to be allocated on a
      First Come, First Served basis by IANA [RFC5226].  The request to
      IANA for a Vendor-Specific Command Code SHOULD include a reference
      to a publicly available specification that documents the command
      in sufficient detail to aid in interoperability between
      independent implementations.  If the specification cannot be made
      publicly available, the request for a vendor-specific Command Code
      MUST include the contact information of persons and/or entities
      responsible for authoring and maintaining the command.

Top      Up      ToC       Page 137 
      The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe
      - 0xffffff) are reserved for experimental commands.  As these
      codes are only for experimental and testing purposes, no guarantee
      is made for interoperability between Diameter peers using
      experimental commands.

11.2.2.  Command Flags

   Section 3 describes the existing Command Flags field.  The remaining
   bits can only be assigned via a Standards Action [RFC5226].

11.3.  AVP Values

   For AVP values, the Experimental-Result-Code AVP value allocation has
   been added; see Section 11.3.1.  The old AVP value allocation rule,
   IETF Consensus, has been updated to IETF Review as per [RFC5226], and
   affected AVPs are listed as reminders.

11.3.1.  Experimental-Result-Code AVP

   Values for this AVP are purely local to the indicated vendor, and no
   IANA registry is maintained for them.

11.3.2.  Result-Code AVP Values

   New values are available for assignment via IETF Review [RFC5226].

11.3.3.  Accounting-Record-Type AVP Values

   New values are available for assignment via IETF Review [RFC5226].

11.3.4.  Termination-Cause AVP Values

   New values are available for assignment via IETF Review [RFC5226].

11.3.5.  Redirect-Host-Usage AVP Values

   New values are available for assignment via IETF Review [RFC5226].

11.3.6.  Session-Server-Failover AVP Values

   New values are available for assignment via IETF Review [RFC5226].

11.3.7.  Session-Binding AVP Values

   New values are available for assignment via IETF Review [RFC5226].

Top      Up      ToC       Page 138 
11.3.8.  Disconnect-Cause AVP Values

   New values are available for assignment via IETF Review [RFC5226].

11.3.9.  Auth-Request-Type AVP Values

   New values are available for assignment via IETF Review [RFC5226].

11.3.10.  Auth-Session-State AVP Values

   New values are available for assignment via IETF Review [RFC5226].

11.3.11.  Re-Auth-Request-Type AVP Values

   New values are available for assignment via IETF Review [RFC5226].

11.3.12.  Accounting-Realtime-Required AVP Values

   New values are available for assignment via IETF Review [RFC5226].

11.3.13.  Inband-Security-Id AVP (code 299)

   The use of this AVP has been deprecated.

11.4.  _diameters Service Name and Port Number Registration

   IANA has registered the "_diameters" service name and assigned port
   numbers for TLS/TCP and DTLS/SCTP according to the guidelines given
   in [RFC6335].

      Service Name:         _diameters

      Transport Protocols:  TCP, SCTP

      Assignee:             IESG <>

      Contact:              IETF Chair <>

      Description:          Diameter over TLS/TCP and DTLS/SCTP

      Reference:            RFC 6733

      Port  Number:         5868, from the User Range

Top      Up      ToC       Page 139 
11.5.  SCTP Payload Protocol Identifiers

   Two SCTP payload protocol identifiers have been registered in the
   SCTP Payload Protocol Identifiers registry:

    Value | SCTP Payload Protocol Identifier
     46   | Diameter in a SCTP DATA chunk
     47   | Diameter in a DTLS/SCTP DATA chunk

11.6.  S-NAPTR Parameters

   The following tag has been registered in the S-NAPTR Application
   Protocol Tags registry:

   Tag                | Protocol
   diameter.dtls.sctp | DTLS/SCTP

12.  Diameter Protocol-Related Configurable Parameters

   This section contains the configurable parameters that are found
   throughout this document:

   Diameter Peer

      A Diameter entity MAY communicate with peers that are statically
      configured.  A statically configured Diameter peer would require
      that either the IP address or the fully qualified domain name
      (FQDN) be supplied, which would then be used to resolve through

   Routing Table

      A Diameter proxy server routes messages based on the realm portion
      of a Network Access Identifier (NAI).  The server MUST have a
      table of Realm Names, and the address of the peer to which the
      message must be forwarded.  The routing table MAY also include a
      "default route", which is typically used for all messages that
      cannot be locally processed.

   Tc timer

      The Tc timer controls the frequency that transport connection
      attempts are done to a peer with whom no active transport
      connection exists.  The recommended value is 30 seconds.

Top      Up      ToC       Page 140 
13.  Security Considerations

   The Diameter base protocol messages SHOULD be secured by using TLS
   [RFC5246] or DTLS/SCTP [RFC6083].  Additional security mechanisms
   such as IPsec [RFC4301] MAY also be deployed to secure connections
   between peers.  However, all Diameter base protocol implementations
   MUST support the use of TLS/TCP and DTLS/SCTP, and the Diameter
   protocol MUST NOT be used without one of TLS, DTLS, or IPsec.

   If a Diameter connection is to be protected via TLS/TCP and DTLS/SCTP
   or IPsec, then TLS/TCP and DTLS/SCTP or IPsec/IKE SHOULD begin prior
   to any Diameter message exchange.  All security parameters for TLS/
   TCP and DTLS/SCTP or IPsec are configured independent of the Diameter
   protocol.  All Diameter messages will be sent through the TLS/TCP and
   DTLS/SCTP or IPsec connection after a successful setup.

   For TLS/TCP and DTLS/SCTP connections to be established in the open
   state, the CER/CEA exchange MUST include an Inband-Security-ID AVP
   with a value of TLS/TCP and DTLS/SCTP.  The TLS/TCP and DTLS/SCTP
   handshake will begin when both ends successfully reach the open
   state, after completion of the CER/CEA exchange.  If the TLS/TCP and
   DTLS/SCTP handshake is successful, all further messages will be sent
   via TLS/TCP and DTLS/SCTP.  If the handshake fails, both ends MUST
   move to the closed state.  See Section 13.1 for more details.

13.1.  TLS/TCP and DTLS/SCTP Usage

   Diameter nodes using TLS/TCP and DTLS/SCTP for security MUST mutually
   authenticate as part of TLS/TCP and DTLS/SCTP session establishment.
   In order to ensure mutual authentication, the Diameter node acting as
   the TLS/TCP and DTLS/SCTP server MUST request a certificate from the
   Diameter node acting as TLS/TCP and DTLS/SCTP client, and the
   Diameter node acting as the TLS/TCP and DTLS/SCTP client MUST be
   prepared to supply a certificate on request.

   Diameter nodes MUST be able to negotiate the following TLS/TCP and
   DTLS/SCTP cipher suites:


   Diameter nodes SHOULD be able to negotiate the following TLS/TCP and
   DTLS/SCTP cipher suite:


Top      Up      ToC       Page 141 
   Note that it is quite possible that support for the
   TLS_RSA_WITH_AES_128_CBC_SHA cipher suite will be REQUIRED at some
   future date.  Diameter nodes MAY negotiate other TLS/TCP and DTLS/
   SCTP cipher suites.

   If public key certificates are used for Diameter security (for
   example, with TLS), the value of the expiration times in the routing
   and peer tables MUST NOT be greater than the expiry time in the
   relevant certificates.

13.2.  Peer-to-Peer Considerations

   As with any peer-to-peer protocol, proper configuration of the trust
   model within a Diameter peer is essential to security.  When
   certificates are used, it is necessary to configure the root
   certificate authorities trusted by the Diameter peer.  These root CAs
   are likely to be unique to Diameter usage and distinct from the root
   CAs that might be trusted for other purposes such as Web browsing.
   In general, it is expected that those root CAs will be configured so
   as to reflect the business relationships between the organization
   hosting the Diameter peer and other organizations.  As a result, a
   Diameter peer will typically not be configured to allow connectivity
   with any arbitrary peer.  With certificate authentication, Diameter
   peers may not be known beforehand and therefore peer discovery may be

13.3.  AVP Considerations

   Diameter AVPs often contain security-sensitive data; for example,
   user passwords and location data, network addresses and cryptographic
   keys.  The following AVPs defined in this document are considered to
   be security-sensitive:

   o  Acct-Interim-Interval

   o  Accounting-Realtime-Required

   o  Acct-Multi-Session-Id

   o  Accounting-Record-Number

   o  Accounting-Record-Type

   o  Accounting-Session-Id

   o  Accounting-Sub-Session-Id

   o  Class

Top      Up      ToC       Page 142 
   o  Session-Id

   o  Session-Binding

   o  Session-Server-Failover

   o  User-Name

   Diameter messages containing these or any other AVPs considered to be
   security-sensitive MUST only be sent protected via mutually
   authenticated TLS or IPsec.  In addition, those messages MUST NOT be
   sent via intermediate nodes unless there is end-to-end security
   between the originator and recipient or the originator has locally
   trusted configuration that indicates that end-to-end security is not
   needed.  For example, end-to-end security may not be required in the
   case where an intermediary node is known to be operated as part of
   the same administrative domain as the endpoints so that an ability to
   successfully compromise the intermediary would imply a high
   probability of being able to compromise the endpoints as well.  Note
   that no end-to-end security mechanism is specified in this document.

14.  References

14.1.  Normative References

              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Binary Floating-Point Arithmetic, ANSI/IEEE
              Standard 754-1985", August 1985.

              IANA, "Address Family Numbers",

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, March 2003.

Top      Up      ToC       Page 143 
   [RFC3539]  Aboba, B. and J. Wood, "Authentication, Authorization and
              Accounting (AAA) Transport Profile", RFC 3539, June 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", RFC 3958, January 2005.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4004]  Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
              P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
              August 2005.

   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
              "Diameter Network Access Server Application", RFC 4005,
              August 2005.

   [RFC4006]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
              Loughney, "Diameter Credit-Control Application", RFC 4006,
              August 2005.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Top      Up      ToC       Page 144 
   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5729]  Korhonen, J., Jones, M., Morand, L., and T. Tsou,
              "Clarifications on the Routing of Diameter Requests Based
              on the Username and the Realm", RFC 5729, December 2009.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891, August 2010.

   [RFC6083]  Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
              Transport Layer Security (DTLS) for Stream Control
              Transmission Protocol (SCTP)", RFC 6083, January 2011.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6408]  Jones, M., Korhonen, J., and L. Morand, "Diameter
              Straightforward-Naming Authority Pointer (S-NAPTR) Usage",
              RFC 6408, November 2011.

14.2.  Informative References

   [ENTERPRISE]  IANA, "SMI Network Management Private Enterprise

   [IANATCV]     IANA, "Termination-Cause AVP Values (code 295)",

   [RFC1492]     Finseth, C., "An Access Control Protocol, Sometimes
                 Called TACACS", RFC 1492, July 1993.

   [RFC1661]     Simpson, W., "The Point-to-Point Protocol (PPP)",
                 STD 51, RFC 1661, July 1994.

   [RFC2104]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
                 Keyed-Hashing for Message Authentication", RFC 2104,
                 February 1997.

Top      Up      ToC       Page 145 
   [RFC2782]     Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
                 for specifying the location of services (DNS SRV)",
                 RFC 2782, February 2000.

   [RFC2865]     Rigney, C., Willens, S., Rubens, A., and W. Simpson,
                 "Remote Authentication Dial In User Service (RADIUS)",
                 RFC 2865, June 2000.

   [RFC2866]     Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC2869]     Rigney, C., Willats, W., and P. Calhoun, "RADIUS
                 Extensions", RFC 2869, June 2000.

   [RFC2881]     Mitton, D. and M. Beadles, "Network Access Server
                 Requirements Next Generation (NASREQNG) NAS Model",
                 RFC 2881, July 2000.

   [RFC2975]     Aboba, B., Arkko, J., and D. Harrington, "Introduction
                 to Accounting Management", RFC 2975, October 2000.

   [RFC2989]     Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann,
                 P., Shiino, H., Walsh, P., Zorn, G., Dommety, G.,
                 Perkins, C., Patil, B., Mitton, D., Manning, S.,
                 Beadles, M., Chen, X., Sivalingham, S., Hameed, A.,
                 Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu,
                 R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba,
                 S., and E. Jaques, "Criteria for Evaluating AAA
                 Protocols for Network Access", RFC 2989, November 2000.

   [RFC3162]     Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
                 RFC 3162, August 2001.

   [RFC3748]     Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
                 H. Levkowetz, "Extensible Authentication Protocol
                 (EAP)", RFC 3748, June 2004.

   [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
                 Internet Protocol", RFC 4301, December 2005.

   [RFC4690]     Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review
                 and Recommendations for Internationalized Domain Names
                 (IDNs)", RFC 4690, September 2006.

   [RFC5176]     Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
                 Aboba, "Dynamic Authorization Extensions to Remote
                 Authentication Dial In User Service (RADIUS)",
                 RFC 5176, January 2008.

Top      Up      ToC       Page 146 
   [RFC5461]     Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
                 February 2009.

   [RFC5905]     Mills, D., Martin, J., Burbank, J., and W. Kasch,
                 "Network Time Protocol Version 4: Protocol and
                 Algorithms Specification", RFC 5905, June 2010.

   [RFC5927]     Gont, F., "ICMP Attacks against TCP", RFC 5927,
                 July 2010.

   [RFC6335]     Cotton, M., Eggert, L., Touch, J., Westerlund, M., and
                 S. Cheshire, "Internet Assigned Numbers Authority
                 (IANA) Procedures for the Management of the Service
                 Name and Transport Protocol Port Number Registry",
                 BCP 165, RFC 6335, August 2011.

   [RFC6737]     Kang, J. and G. Zorn, "The Diameter Capabilities Update
                 Application", RFC 6737, October 2012.

Top      Up      ToC       Page 147 
Appendix A.  Acknowledgements

A.1.  This Document

   The authors would like to thank the following people that have
   provided proposals and contributions to this document:

   To Vishnu Ram and Satendra Gera for their contributions on
   capabilities updates, predictive loop avoidance, as well as many
   other technical proposals.  To Tolga Asveren for his insights and
   contributions on almost all of the proposed solutions incorporated
   into this document.  To Timothy Smith for helping on the capabilities
   Update and other topics.  To Tony Zhang for providing fixes to
   loopholes on composing Failed-AVPs as well as many other issues and
   topics.  To Jan Nordqvist for clearly stating the usage of
   Application Ids.  To Anders Kristensen for providing needed technical
   opinions.  To David Frascone for providing invaluable review of the
   document.  To Mark Jones for providing clarifying text on vendor
   command codes and other vendor-specific indicators.  To Victor
   Pascual and Sebastien Decugis for new text and recommendations on
   SCTP/DTLS.  To Jouni Korhonen for taking over the editing task and
   resolving last bits from versions 27 through 29.

   Special thanks to the Diameter extensibility design team, which
   helped resolve the tricky question of mandatory AVPs and ABNF
   semantics.  The members of this team are as follows:

   Avi Lior, Jari Arkko, Glen Zorn, Lionel Morand, Mark Jones, Tolga
   Asveren, Jouni Korhonen, and Glenn McGregor.

   Special thanks also to people who have provided invaluable comments
   and inputs especially in resolving controversial issues:

   Glen Zorn, Yoshihiro Ohba, Marco Stura, Stephen Farrel, Pete Resnick,
   Peter Saint-Andre, Robert Sparks, Krishna Prasad, Sean Turner, Barry
   Leiba, and Pasi Eronen.

   Finally, we would like to thank the original authors of this

   Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman, and Glen Zorn.

   Their invaluable knowledge and experience has given us a robust and
   flexible AAA protocol that many people have seen great value in
   adopting.  We greatly appreciate their support and stewardship for
   the continued improvements of Diameter as a protocol.  We would also
   like to extend our gratitude to folks aside from the authors who have

Top      Up      ToC       Page 148 
   assisted and contributed to the original version of this document.
   Their efforts significantly contributed to the success of Diameter.

A.2.  RFC 3588

   The authors would like to thank Nenad Trifunovic, Tony Johansson and
   Pankaj Patel for their participation in the pre-IETF Document Reading
   Party.  Allison Mankin, Jonathan Wood, and Bernard Aboba provided
   invaluable assistance in working out transport issues and this was
   also the case with Steven Bellovin in the security area.

   Paul Funk and David Mitton were instrumental in getting the Peer
   State Machine correct, and our deep thanks go to them for their time.

   Text in this document was also provided by Paul Funk, Mark Eklund,
   Mark Jones, and Dave Spence.  Jacques Caron provided many great
   comments as a result of a thorough review of the spec.

   The authors would also like to acknowledge the following people for
   their contribution in the development of the Diameter protocol:

   Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell,
   David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy
   Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien,
   Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin,
   Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht, and
   Jeff Weisberg.

   Finally, Pat Calhoun would like to thank Sun Microsystems since most
   of the effort put into this document was done while he was in their

Appendix B.  S-NAPTR Example

   As an example, consider a client that wishes to resolve aaa:  The client performs a NAPTR query for that domain,
   and the following NAPTR records are returned:

    ;;        order pref flags service   regexp replacement
    IN NAPTR  50    50   "s"   "aaa:diameter.tls.tcp" ""
    IN NAPTR  100   50   "s"   "aaa:diameter.tcp"     ""
    IN NAPTR  150   50   "s"   "aaa:diameter.sctp"    ""

   This indicates that the server supports TLS, TCP, and SCTP in that
   order.  If the client supports TLS, TLS will be used, targeted to a

Top      Up      ToC       Page 149 
   host determined by an SRV lookup of
   That lookup would return:

    ;;       Priority  Weight  Port    Target
    IN SRV   0         1       5060
    IN SRV   0         2       5060

   As an alternative example, a client that wishes to resolve aaa:  The client performs a NAPTR query for that domain,
   and the following NAPTR records are returned:

    ;;        order pref flags service   regexp replacement
    IN NAPTR  150   50   "a"   "aaa:diameter.tls.tcp"  ""
    IN NAPTR  150   50   "a"   "aaa:diameter.tls.tcp"  ""

   This indicates that the server supports TCP available at the returned
   host names.

Appendix C.  Duplicate Detection

   As described in Section 9.4, accounting record duplicate detection is
   based on session identifiers.  Duplicates can appear for various

   o  Failover to an alternate server.  Where close to real-time
      performance is required, failover thresholds need to be kept low.
      This may lead to an increased likelihood of duplicates.  Failover
      can occur at the client or within Diameter agents.

   o  Failure of a client or agent after sending a record from non-
      volatile memory, but prior to receipt of an application-layer ACK
      and deletion of the record to be sent.  This will result in
      retransmission of the record soon after the client or agent has

   o  Duplicates received from RADIUS gateways.  Since the
      retransmission behavior of RADIUS is not defined within [RFC2865],
      the likelihood of duplication will vary according to the

   o  Implementation problems and misconfiguration.

   The T flag is used as an indication of an application-layer
   retransmission event, e.g., due to failover to an alternate server.
   It is defined only for request messages sent by Diameter clients or
   agents.  For instance, after a reboot, a client may not know whether

Top      Up      ToC       Page 150 
   it has already tried to send the accounting records in its non-
   volatile memory before the reboot occurred.  Diameter servers MAY use
   the T flag as an aid when processing requests and detecting duplicate
   messages.  However, servers that do this MUST ensure that duplicates
   are found even when the first transmitted request arrives at the
   server after the retransmitted request.  It can be used only in cases
   where no answer has been received from the server for a request and
   the request is sent again, (e.g., due to a failover to an alternate
   peer, due to a recovered primary peer or due to a client re-sending a
   stored record from non-volatile memory such as after reboot of a
   client or agent).

   In some cases, the Diameter accounting server can delay the duplicate
   detection and accounting record processing until a post-processing
   phase takes place.  At that time records are likely to be sorted
   according to the included User-Name and duplicate elimination is easy
   in this case.  In other situations, it may be necessary to perform
   real-time duplicate detection, such as when credit limits are imposed
   or real-time fraud detection is desired.

   In general, only generation of duplicates due to failover or re-
   sending of records in non-volatile storage can be reliably detected
   by Diameter clients or agents.  In such cases, the Diameter client or
   agents can mark the message as a possible duplicate by setting the T
   flag.  Since the Diameter server is responsible for duplicate
   detection, it can choose whether or not to make use of the T flag, in
   order to optimize duplicate detection.  Since the T flag does not
   affect interoperability, and it may not be needed by some servers,
   generation of the T flag is REQUIRED for Diameter clients and agents,
   but it MAY be implemented by Diameter servers.

   As an example, it can be usually be assumed that duplicates appear
   within a time window of longest recorded network partition or device
   fault, perhaps a day.  So only records within this time window need
   to be looked at in the backward direction.  Secondly, hashing
   techniques or other schemes, such as the use of the T flag in the
   received messages, may be used to eliminate the need to do a full
   search even in this set except for rare cases.

   The following is an example of how the T flag may be used by the
   server to detect duplicate requests.

      A Diameter server MAY check the T flag of the received message to
      determine if the record is a possible duplicate.  If the T flag is
      set in the request message, the server searches for a duplicate
      within a configurable duplication time window backward and
      forward.  This limits database searching to those records where
      the T flag is set.  In a well-run network, network partitions and

Top      Up      ToC       Page 151 
      device faults will presumably be rare events, so this approach
      represents a substantial optimization of the duplicate detection
      process.  During failover, it is possible for the original record
      to be received after the T-flag-marked record, due to differences
      in network delays experienced along the path by the original and
      duplicate transmissions.  The likelihood of this occurring
      increases as the failover interval is decreased.  In order to be
      able to detect duplicates that are out of order, the Diameter
      server should use backward and forward time windows when
      performing duplicate checking for the T-flag-marked request.  For
      example, in order to allow time for the original record to exit
      the network and be recorded by the accounting server, the Diameter
      server can delay processing records with the T flag set until a
      time period TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after
      the closing of the original transport connection.  After this time
      period, it may check the T-flag-marked records against the
      database with relative assurance that the original records, if
      sent, have been received and recorded.

Appendix D.  Internationalized Domain Names

   To be compatible with the existing DNS infrastructure and simplify
   host and domain name comparison, Diameter identities (FQDNs) are
   represented in ASCII form.  This allows the Diameter protocol to fall
   in-line with the DNS strategy of being transparent from the effects
   of Internationalized Domain Names (IDNs) by following the
   recommendations in [RFC4690] and [RFC5890].  Applications that
   provide support for IDNs outside of the Diameter protocol but
   interacting with it SHOULD use the representation and conversion
   framework described in [RFC5890], [RFC5891], and [RFC3492].

Top      Up      ToC       Page 152 
Authors' Addresses

   Victor Fajardo (editor)
   Telcordia Technologies
   One Telcordia Drive, 1S-222
   Piscataway, NJ  08854

   Phone: +1-908-421-1845

   Jari Arkko
   Ericsson Research
   02420 Jorvas

   Phone: +358 40 5079256

   John Loughney
   Nokia Research Center
   955 Page Mill Road
   Palo Alto, CA  94304

   Phone: +1-650-283-8068

   Glen Zorn (editor)
   Network Zen
   227/358 Thanon Sanphawut
   Bang Na, Bangkok  10260

   Phone: +66 (0) 87-0404617