tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6733

 
 
 

Diameter Base Protocol

Part 4 of 5, p. 87 to 122
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 87 
7.  Error Handling

   There are two different types of errors in Diameter; protocol errors
   and application errors.  A protocol error is one that occurs at the
   base protocol level and MAY require per-hop attention (e.g., a
   message routing error).  Application errors, on the other hand,
   generally occur due to a problem with a function specified in a
   Diameter application (e.g., user authentication, missing AVP).

   Result-Code AVP values that are used to report protocol errors MUST
   only be present in answer messages whose 'E' bit is set.  When a
   request message is received that causes a protocol error, an answer
   message is returned with the 'E' bit set, and the Result-Code AVP is
   set to the appropriate protocol error value.  As the answer is sent
   back towards the originator of the request, each proxy or relay agent
   MAY take action on the message.

Top      Up      ToC       Page 88 
                          1. Request        +---------+ Link Broken
                +-------------------------->|Diameter |----///----+
                |     +---------------------|         |           v
         +------+--+  | 2. answer + 'E' set | Relay 2 |     +--------+
         |Diameter |<-+ (Unable to Forward) +---------+     |Diameter|
         |         |                                        |  Home  |
         | Relay 1 |--+                     +---------+     | Server |
         +---------+  |   3. Request        |Diameter |     +--------+
                      +-------------------->|         |           ^
                                            | Relay 3 |-----------+
                                            +---------+

        Figure 7: Example of Protocol Error Causing Answer Message

   Figure 7 provides an example of a message forwarded upstream by a
   Diameter relay.  When the message is received by Relay 2, and it
   detects that it cannot forward the request to the home server, an
   answer message is returned with the 'E' bit set and the Result-Code
   AVP set to DIAMETER_UNABLE_TO_DELIVER.  Given that this error falls
   within the protocol error category, Relay 1 would take special
   action, and given the error, attempt to route the message through its
   alternate Relay 3.

            +---------+ 1. Request  +---------+ 2. Request  +---------+
            | Access  |------------>|Diameter |------------>|Diameter |
            |         |             |         |             |  Home   |
            | Device  |<------------|  Relay  |<------------| Server  |
            +---------+  4. Answer  +---------+  3. Answer  +---------+
                       (Missing AVP)           (Missing AVP)

           Figure 8: Example of Application Error Answer Message

   Figure 8 provides an example of a Diameter message that caused an
   application error.  When application errors occur, the Diameter
   entity reporting the error clears the 'R' bit in the Command Flags
   and adds the Result-Code AVP with the proper value.  Application
   errors do not require any proxy or relay agent involvement;
   therefore, the message would be forwarded back to the originator of
   the request.

   In the case where the answer message itself contains errors, any
   related session SHOULD be terminated by sending an STR or ASR
   message.  The Termination-Cause AVP in the STR MAY be filled with the
   appropriate value to indicate the cause of the error.  An application
   MAY also send an application-specific request instead of an STR or
   ASR message to signal the error in the case where no state is
   maintained or to allow for some form of error recovery with the
   corresponding Diameter entity.

Top      Up      ToC       Page 89 
   There are certain Result-Code AVP application errors that require
   additional AVPs to be present in the answer.  In these cases, the
   Diameter node that sets the Result-Code AVP to indicate the error
   MUST add the AVPs.  Examples are as follows:

   o  A request with an unrecognized AVP is received with the 'M' bit
      (Mandatory bit) set causes an answer to be sent with the Result-
      Code AVP set to DIAMETER_AVP_UNSUPPORTED and the Failed-AVP AVP
      containing the offending AVP.

   o  A request with an AVP that is received with an unrecognized value
      causes an answer to be returned with the Result-Code AVP set to
      DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing the
      AVP causing the error.

   o  A received command that is missing AVPs that are defined as
      required in the commands CCF; examples are AVPs indicated as
      {AVP}.  The receiver issues an answer with the Result-Code set to
      DIAMETER_MISSING_AVP and creates an AVP with the AVP Code and
      other fields set as expected in the missing AVP.  The created AVP
      is then added to the Failed-AVP AVP.

   The Result-Code AVP describes the error that the Diameter node
   encountered in its processing.  In case there are multiple errors,
   the Diameter node MUST report only the first error it encountered
   (detected possibly in some implementation-dependent order).  The
   specific errors that can be described by this AVP are described in
   the following section.

7.1.  Result-Code AVP

   The Result-Code AVP (AVP Code 268) is of type Unsigned32 and
   indicates whether a particular request was completed successfully or
   an error occurred.  All Diameter answer messages in IETF-defined
   Diameter application specifications MUST include one Result-Code AVP.
   A non-successful Result-Code AVP (one containing a non-2xxx value
   other than DIAMETER_REDIRECT_INDICATION) MUST include the Error-
   Reporting-Host AVP if the host setting the Result-Code AVP is
   different from the identity encoded in the Origin-Host AVP.

   The Result-Code data field contains an IANA-managed 32-bit address
   space representing errors (see Section 11.3.2).  Diameter provides
   the following classes of errors, all identified by the thousands
   digit in the decimal notation:

Top      Up      ToC       Page 90 
   o  1xxx (Informational)

   o  2xxx (Success)

   o  3xxx (Protocol Errors)

   o  4xxx (Transient Failures)

   o  5xxx (Permanent Failure)

   An unrecognized class (one whose first digit is not defined in this
   section) MUST be handled as a permanent failure.

7.1.1.  Informational

   Errors that fall within this category are used to inform the
   requester that a request could not be satisfied, and additional
   action is required on its part before access is granted.

   DIAMETER_MULTI_ROUND_AUTH 1001

      This informational error is returned by a Diameter server to
      inform the access device that the authentication mechanism being
      used requires multiple round trips, and a subsequent request needs
      to be issued in order for access to be granted.

7.1.2.  Success

   Errors that fall within the Success category are used to inform a
   peer that a request has been successfully completed.

   DIAMETER_SUCCESS 2001

      The request was successfully completed.

   DIAMETER_LIMITED_SUCCESS 2002

      When returned, the request was successfully completed, but
      additional processing is required by the application in order to
      provide service to the user.

7.1.3.  Protocol Errors

   Errors that fall within the Protocol Error category SHOULD be treated
   on a per-hop basis, and Diameter proxies MAY attempt to correct the
   error, if it is possible.  Note that these errors MUST only be used
   in answer messages whose 'E' bit is set.

Top      Up      ToC       Page 91 
   DIAMETER_COMMAND_UNSUPPORTED 3001

      This error code is used when a Diameter entity receives a message
      with a Command Code that it does not support.

   DIAMETER_UNABLE_TO_DELIVER 3002

      This error is given when Diameter cannot deliver the message to
      the destination, either because no host within the realm
      supporting the required application was available to process the
      request or because the Destination-Host AVP was given without the
      associated Destination-Realm AVP.

   DIAMETER_REALM_NOT_SERVED 3003

      The intended realm of the request is not recognized.

   DIAMETER_TOO_BUSY 3004

      When returned, a Diameter node SHOULD attempt to send the message
      to an alternate peer.  This error MUST only be used when a
      specific server is requested, and it cannot provide the requested
      service.

   DIAMETER_LOOP_DETECTED 3005

      An agent detected a loop while trying to get the message to the
      intended recipient.  The message MAY be sent to an alternate peer,
      if one is available, but the peer reporting the error has
      identified a configuration problem.

   DIAMETER_REDIRECT_INDICATION 3006

      A redirect agent has determined that the request could not be
      satisfied locally, and the initiator of the request SHOULD direct
      the request directly to the server, whose contact information has
      been added to the response.  When set, the Redirect-Host AVP MUST
      be present.

   DIAMETER_APPLICATION_UNSUPPORTED 3007

      A request was sent for an application that is not supported.

   DIAMETER_INVALID_HDR_BITS 3008

      A request was received whose bits in the Diameter header were set
      either to an invalid combination or to a value that is
      inconsistent with the Command Code's definition.

Top      Up      ToC       Page 92 
   DIAMETER_INVALID_AVP_BITS 3009

      A request was received that included an AVP whose flag bits are
      set to an unrecognized value or that is inconsistent with the
      AVP's definition.

   DIAMETER_UNKNOWN_PEER 3010

      A CER was received from an unknown peer.

7.1.4.  Transient Failures

   Errors that fall within the transient failures category are used to
   inform a peer that the request could not be satisfied at the time it
   was received but MAY be able to satisfy the request in the future.
   Note that these errors MUST be used in answer messages whose 'E' bit
   is not set.

   DIAMETER_AUTHENTICATION_REJECTED 4001

      The authentication process for the user failed, most likely due to
      an invalid password used by the user.  Further attempts MUST only
      be tried after prompting the user for a new password.

   DIAMETER_OUT_OF_SPACE 4002

      A Diameter node received the accounting request but was unable to
      commit it to stable storage due to a temporary lack of space.

   ELECTION_LOST 4003

      The peer has determined that it has lost the election process and
      has therefore disconnected the transport connection.

7.1.5.  Permanent Failures

   Errors that fall within the permanent failures category are used to
   inform the peer that the request failed and should not be attempted
   again.  Note that these errors SHOULD be used in answer messages
   whose 'E' bit is not set.  In error conditions where it is not
   possible or efficient to compose application-specific answer grammar,
   answer messages with the 'E' bit set and which comply to the grammar
   described in Section 7.2 MAY also be used for permanent errors.

Top      Up      ToC       Page 93 
   DIAMETER_AVP_UNSUPPORTED 5001

      The peer received a message that contained an AVP that is not
      recognized or supported and was marked with the 'M' (Mandatory)
      bit.  A Diameter message with this error MUST contain one or more
      Failed-AVP AVPs containing the AVPs that caused the failure.

   DIAMETER_UNKNOWN_SESSION_ID 5002

      The request contained an unknown Session-Id.

   DIAMETER_AUTHORIZATION_REJECTED 5003

      A request was received for which the user could not be authorized.
      This error could occur if the service requested is not permitted
      to the user.

   DIAMETER_INVALID_AVP_VALUE 5004

      The request contained an AVP with an invalid value in its data
      portion.  A Diameter message indicating this error MUST include
      the offending AVPs within a Failed-AVP AVP.

   DIAMETER_MISSING_AVP 5005

      The request did not contain an AVP that is required by the Command
      Code definition.  If this value is sent in the Result-Code AVP, a
      Failed-AVP AVP SHOULD be included in the message.  The Failed-AVP
      AVP MUST contain an example of the missing AVP complete with the
      Vendor-Id if applicable.  The value field of the missing AVP
      should be of correct minimum length and contain zeroes.

   DIAMETER_RESOURCES_EXCEEDED 5006

      A request was received that cannot be authorized because the user
      has already expended allowed resources.  An example of this error
      condition is when a user that is restricted to one dial-up PPP
      port attempts to establish a second PPP connection.

   DIAMETER_CONTRADICTING_AVPS 5007

      The Home Diameter server has detected AVPs in the request that
      contradicted each other, and it is not willing to provide service
      to the user.  The Failed-AVP AVP MUST be present, which contain
      the AVPs that contradicted each other.

Top      Up      ToC       Page 94 
   DIAMETER_AVP_NOT_ALLOWED 5008

      A message was received with an AVP that MUST NOT be present.  The
      Failed-AVP AVP MUST be included and contain a copy of the
      offending AVP.

   DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009

      A message was received that included an AVP that appeared more
      often than permitted in the message definition.  The Failed-AVP
      AVP MUST be included and contain a copy of the first instance of
      the offending AVP that exceeded the maximum number of occurrences.

   DIAMETER_NO_COMMON_APPLICATION 5010

      This error is returned by a Diameter node that receives a CER
      whereby no applications are common between the CER sending peer
      and the CER receiving peer.

   DIAMETER_UNSUPPORTED_VERSION 5011

      This error is returned when a request was received, whose version
      number is unsupported.

   DIAMETER_UNABLE_TO_COMPLY 5012

      This error is returned when a request is rejected for unspecified
      reasons.

   DIAMETER_INVALID_BIT_IN_HEADER 5013

      This error is returned when a reserved bit in the Diameter header
      is set to one (1) or the bits in the Diameter header are set
      incorrectly.

   DIAMETER_INVALID_AVP_LENGTH 5014

      The request contained an AVP with an invalid length.  A Diameter
      message indicating this error MUST include the offending AVPs
      within a Failed-AVP AVP.  In cases where the erroneous AVP length
      value exceeds the message length or is less than the minimum AVP
      header length, it is sufficient to include the offending AVP
      header and a zero filled payload of the minimum required length
      for the payloads data type.  If the AVP is a Grouped AVP, the
      Grouped AVP header with an empty payload would be sufficient to
      indicate the offending AVP.  In the case where the offending AVP
      header cannot be fully decoded when the AVP length is less than

Top      Up      ToC       Page 95 
      the minimum AVP header length, it is sufficient to include an
      offending AVP header that is formulated by padding the incomplete
      AVP header with zero up to the minimum AVP header length.

   DIAMETER_INVALID_MESSAGE_LENGTH 5015

      This error is returned when a request is received with an invalid
      message length.

   DIAMETER_INVALID_AVP_BIT_COMBO 5016

      The request contained an AVP with which is not allowed to have the
      given value in the AVP Flags field.  A Diameter message indicating
      this error MUST include the offending AVPs within a Failed-AVP
      AVP.

   DIAMETER_NO_COMMON_SECURITY 5017

      This error is returned when a CER message is received, and there
      are no common security mechanisms supported between the peers.  A
      Capabilities-Exchange-Answer (CEA) message MUST be returned with
      the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY.

7.2.  Error Bit

   The 'E' (Error Bit) in the Diameter header is set when the request
   caused a protocol-related error (see Section 7.1.3).  A message with
   the 'E' bit MUST NOT be sent as a response to an answer message.
   Note that a message with the 'E' bit set is still subjected to the
   processing rules defined in Section 6.2.  When set, the answer
   message will not conform to the CCF specification for the command;
   instead, it and will conform to the following CCF:

      Message Format

      <answer-message> ::= < Diameter Header: code, ERR [, PXY] >
                        0*1< Session-Id >
                           { Origin-Host }
                           { Origin-Realm }
                           { Result-Code }
                           [ Origin-State-Id ]
                           [ Error-Message ]
                           [ Error-Reporting-Host ]
                           [ Failed-AVP ]
                           [ Experimental-Result ]
                         * [ Proxy-Info ]
                         * [ AVP ]

Top      Up      ToC       Page 96 
   Note that the code used in the header is the same than the one found
   in the request message, but with the 'R' bit cleared and the 'E' bit
   set.  The 'P' bit in the header is set to the same value as the one
   found in the request message.

7.3.  Error-Message AVP

   The Error-Message AVP (AVP Code 281) is of type UTF8String.  It MAY
   accompany a Result-Code AVP as a human-readable error message.  The
   Error-Message AVP is not intended to be useful in an environment
   where error messages are processed automatically.  It SHOULD NOT be
   expected that the content of this AVP be parsed by network entities.

7.4.  Error-Reporting-Host AVP

   The Error-Reporting-Host AVP (AVP Code 294) is of type
   DiameterIdentity.  This AVP contains the identity of the Diameter
   host that sent the Result-Code AVP to a value other than 2001
   (Success), only if the host setting the Result-Code is different from
   the one encoded in the Origin-Host AVP.  This AVP is intended to be
   used for troubleshooting purposes, and it MUST be set when the
   Result-Code AVP indicates a failure.

7.5.  Failed-AVP AVP

   The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
   debugging information in cases where a request is rejected or not
   fully processed due to erroneous information in a specific AVP.  The
   value of the Result-Code AVP will provide information on the reason
   for the Failed-AVP AVP.  A Diameter answer message SHOULD contain an
   instance of the Failed-AVP AVP that corresponds to the error
   indicated by the Result-Code AVP.  For practical purposes, this
   Failed-AVP would typically refer to the first AVP processing error
   that a Diameter node encounters.

   The possible reasons for this AVP are the presence of an improperly
   constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
   value, the omission of a required AVP, the presence of an explicitly
   excluded AVP (see tables in Section 10) or the presence of two or
   more occurrences of an AVP that is restricted to 0, 1, or 0-1
   occurrences.

   A Diameter message SHOULD contain one Failed-AVP AVP, containing the
   entire AVP that could not be processed successfully.  If the failure
   reason is omission of a required AVP, an AVP with the missing AVP
   code, the missing Vendor-Id, and a zero-filled payload of the minimum
   required length for the omitted AVP will be added.  If the failure
   reason is an invalid AVP length where the reported length is less

Top      Up      ToC       Page 97 
   than the minimum AVP header length or greater than the reported
   message length, a copy of the offending AVP header and a zero-filled
   payload of the minimum required length SHOULD be added.

   In the case where the offending AVP is embedded within a Grouped AVP,
   the Failed-AVP MAY contain the grouped AVP, which in turn contains
   the single offending AVP.  The same method MAY be employed if the
   grouped AVP itself is embedded in yet another grouped AVP and so on.
   In this case, the Failed-AVP MAY contain the grouped AVP hierarchy up
   to the single offending AVP.  This enables the recipient to detect
   the location of the offending AVP when embedded in a group.

   AVP Format

         <Failed-AVP> ::= < AVP Header: 279 >
                       1* {AVP}

7.6.  Experimental-Result AVP

   The Experimental-Result AVP (AVP Code 297) is of type Grouped, and
   indicates whether a particular vendor-specific request was completed
   successfully or whether an error occurred.  This AVP has the
   following structure:

   AVP Format

         Experimental-Result ::= < AVP Header: 297 >
                                 { Vendor-Id }
                                 { Experimental-Result-Code }

   The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP identifies
   the vendor responsible for the assignment of the result code that
   follows.  All Diameter answer messages defined in vendor-specific
   applications MUST include either one Result-Code AVP or one
   Experimental-Result AVP.

7.7.  Experimental-Result-Code AVP

   The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32
   and contains a vendor-assigned value representing the result of
   processing the request.

   It is recommended that vendor-specific result codes follow the same
   conventions given for the Result-Code AVP regarding the different
   types of result codes and the handling of errors (for non-2xxx
   values).

Top      Up      ToC       Page 98 
8.  Diameter User Sessions

   In general, Diameter can provide two different types of services to
   applications.  The first involves authentication and authorization,
   and it can optionally make use of accounting.  The second only makes
   use of accounting.

   When a service makes use of the authentication and/or authorization
   portion of an application, and a user requests access to the network,
   the Diameter client issues an auth request to its local server.  The
   auth request is defined in a service-specific Diameter application
   (e.g., NASREQ).  The request contains a Session-Id AVP, which is used
   in subsequent messages (e.g., subsequent authorization, accounting,
   etc.) relating to the user's session.  The Session-Id AVP is a means
   for the client and servers to correlate a Diameter message with a
   user session.

   When a Diameter server authorizes a user to implement network
   resources for a finite amount of time, and it is willing to extend
   the authorization via a future request, it MUST add the
   Authorization- Lifetime AVP to the answer message.  The
   Authorization-Lifetime AVP defines the maximum number of seconds a
   user MAY make use of the resources before another authorization
   request is expected by the server.  The Auth-Grace-Period AVP
   contains the number of seconds following the expiration of the
   Authorization-Lifetime, after which the server will release all state
   information related to the user's session.  Note that if payment for
   services is expected by the serving realm from the user's home realm,
   the Authorization-Lifetime AVP, combined with the Auth-Grace-Period
   AVP, implies the maximum length of the session for which the home
   realm is willing to be fiscally responsible.  Services provided past
   the expiration of the Authorization-Lifetime and Auth-Grace-Period
   AVPs are the responsibility of the access device.  Of course, the
   actual cost of services rendered is clearly outside the scope of the
   protocol.

   An access device that does not expect to send a re-authorization or a
   session termination request to the server MAY include the Auth-
   Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint
   to the server.  If the server accepts the hint, it agrees that since
   no session termination message will be received once service to the
   user is terminated, it cannot maintain state for the session.  If the
   answer message from the server contains a different value in the
   Auth-Session-State AVP (or the default value if the AVP is absent),
   the access device MUST follow the server's directives.  Note that the
   value NO_STATE_MAINTAINED MUST NOT be set in subsequent re-
   authorization requests and answers.

Top      Up      ToC       Page 99 
   The base protocol does not include any authorization request
   messages, since these are largely application-specific and are
   defined in a Diameter application document.  However, the base
   protocol does define a set of messages that are used to terminate
   user sessions.  These are used to allow servers that maintain state
   information to free resources.

   When a service only makes use of the accounting portion of the
   Diameter protocol, even in combination with an application, the
   Session-Id is still used to identify user sessions.  However, the
   session termination messages are not used, since a session is
   signaled as being terminated by issuing an accounting stop message.

   Diameter may also be used for services that cannot be easily
   categorized as authentication, authorization, or accounting (e.g.,
   certain Third Generation Partnership Project Internet Multimedia
   System (3GPP IMS) interfaces).  In such cases, the finite state
   machine defined in subsequent sections may not be applicable.
   Therefore, the application itself MAY need to define its own finite
   state machine.  However, such application-specific state machines
   SHOULD follow the general state machine framework outlined in this
   document such as the use of Session-Id AVPs and the use of STR/STA,
   ASR/ASA messages for stateful sessions.

8.1.  Authorization Session State Machine

   This section contains a set of finite state machines, which represent
   the life cycle of Diameter sessions and which MUST be observed by all
   Diameter implementations that make use of the authentication and/or
   authorization portion of a Diameter application.  The term "Service-
   Specific" below refers to a message defined in a Diameter application
   (e.g., Mobile IPv4, NASREQ).

   There are four different authorization session state machines
   supported in the Diameter base protocol.  The first two describe a
   session in which the server is maintaining session state, indicated
   by the value of the Auth-Session-State AVP (or its absence).  One
   describes the session from a client perspective, the other from a
   server perspective.  The second two state machines are used when the
   server does not maintain session state.  Here again, one describes
   the session from a client perspective, the other from a server
   perspective.

   When a session is moved to the Idle state, any resources that were
   allocated for the particular session must be released.  Any event not
   listed in the state machines MUST be considered an error condition,
   and an answer, if applicable, MUST be returned to the originator of
   the message.

Top      Up      ToC       Page 100 
   In the case that an application does not support re-auth, the state
   transitions related to server-initiated re-auth, when both client and
   server sessions maintain state (e.g., Send RAR, Pending, Receive
   RAA), MAY be ignored.

   In the state table, the event "Failure to send X" means that the
   Diameter agent is unable to send command X to the desired
   destination.  This could be due to the peer being down or due to the
   peer sending back a transient failure or temporary protocol error
   notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the
   Result-Code AVP of the corresponding Answer command.  The event 'X
   successfully sent' is the complement of 'Failure to send X'.

   The following state machine is observed by a client when state is
   maintained on the server:

                              CLIENT, STATEFUL
      State     Event                          Action       New State
      ---------------------------------------------------------------
      Idle      Client or device requests      Send         Pending
                access                         service-
                                               specific
                                               auth req

      Idle      ASR Received                   Send ASA     Idle
                for unknown session            with
                                               Result-Code =
                                               UNKNOWN_
                                               SESSION_ID

      Idle      RAR Received                   Send RAA     Idle
                for unknown session            with
                                               Result-Code =
                                               UNKNOWN_
                                               SESSION_ID

      Pending   Successful service-specific    Grant        Open
                authorization answer           Access
                received with default
                Auth-Session-State value

      Pending   Successful service-specific    Sent STR     Discon
                authorization answer received,
                but service not provided

      Pending   Error processing successful    Sent STR     Discon
                service-specific authorization
                answer

Top      Up      ToC       Page 101 
      Pending   Failed service-specific        Clean up     Idle
                authorization answer received

      Open      User or client device          Send         Open
                requests access to service     service-
                                               specific
                                               auth req

      Open      Successful service-specific    Provide      Open
                authorization answer received  service

      Open      Failed service-specific        Discon.      Idle
                authorization answer           user/device
                received.

      Open      RAR received and client will   Send RAA     Open
                perform subsequent re-auth     with
                                               Result-Code =
                                               SUCCESS

      Open      RAR received and client will   Send RAA     Idle
                not perform subsequent         with
                re-auth                        Result-Code !=
                                               SUCCESS,
                                               Discon.
                                               user/device

      Open      Session-Timeout expires on     Send STR     Discon
                access device

      Open      ASR received,                  Send ASA     Discon
                client will comply             with
                with request to end the        Result-Code =
                session                        = SUCCESS,
                                               Send STR.

      Open      ASR Received,                  Send ASA     Open
                client will not comply         with
                with request to end the        Result-Code !=
                session                        != SUCCESS

      Open      Authorization-Lifetime +       Send STR     Discon
                Auth-Grace-Period expires on
                access device

      Discon    ASR received                   Send ASA     Discon

Top      Up      ToC       Page 102 
      Discon    STA received                   Discon.      Idle
                                               user/device

   The following state machine is observed by a server when it is
   maintaining state for the session:

                             SERVER, STATEFUL
      State     Event                          Action       New State
      ---------------------------------------------------------------
      Idle      Service-specific authorization Send         Open
                request received, and          successful
                user is authorized             service-
                                               specific
                                               answer

      Idle      Service-specific authorization Send         Idle
                request received, and          failed
                user is not authorized         service-
                                               specific
                                               answer

      Open      Service-specific authorization Send         Open
                request received, and user     successful
                is authorized                  service-
                                               specific
                                               answer

      Open      Service-specific authorization Send         Idle
                request received, and user     failed
                is not authorized              service-
                                               specific
                                               answer,
                                               Clean up

      Open      Home server wants to confirm   Send RAR     Pending
                authentication and/or
                authorization of the user

      Pending   Received RAA with a failed     Clean up     Idle
                Result-Code

      Pending   Received RAA with Result-Code  Update       Open
                = SUCCESS                      session

      Open      Home server wants to           Send ASR     Discon
                terminate the service

Top      Up      ToC       Page 103 
      Open      Authorization-Lifetime (and    Clean up     Idle
                Auth-Grace-Period) expires
                on home server

      Open      Session-Timeout expires on     Clean up     Idle
                home server

      Discon    Failure to send ASR            Wait,        Discon
                                               resend ASR

      Discon    ASR successfully sent and      Clean up     Idle
                ASA Received with Result-Code

      Not       ASA Received                   None         No Change
      Discon

      Any       STR Received                   Send STA,    Idle
                                               Clean up

   The following state machine is observed by a client when state is not
   maintained on the server:

                              CLIENT, STATELESS
      State     Event                          Action       New State
      ---------------------------------------------------------------
      Idle      Client or device requests      Send         Pending
                access                         service-
                                               specific
                                               auth req

      Pending   Successful service-specific    Grant        Open
                authorization answer           access
                received with Auth-Session-
                State set to
                NO_STATE_MAINTAINED

      Pending   Failed service-specific        Clean up     Idle
                authorization answer
                received

      Open      Session-Timeout expires on     Discon.      Idle
                access device                  user/device

      Open      Service to user is terminated  Discon.      Idle
                                               user/device

Top      Up      ToC       Page 104 
   The following state machine is observed by a server when it is not
   maintaining state for the session:

                              SERVER, STATELESS
      State     Event                          Action       New State
      ---------------------------------------------------------------
      Idle      Service-specific authorization Send         Idle
                request received, and          service-
                successfully processed         specific
                                               answer

8.2.  Accounting Session State Machine

   The following state machines MUST be supported for applications that
   have an accounting portion or that require only accounting services.
   The first state machine is to be observed by clients.

   See Section 9.7 for Accounting Command Codes and Section 9.8 for
   Accounting AVPs.

   The server side in the accounting state machine depends in some cases
   on the particular application.  The Diameter base protocol defines a
   default state machine that MUST be followed by all applications that
   have not specified other state machines.  This is the second state
   machine in this section described below.

   The default server side state machine requires the reception of
   accounting records in any order and at any time, and it does not
   place any standards requirement on the processing of these records.
   Implementations of Diameter may perform checking, ordering,
   correlation, fraud detection, and other tasks based on these records.
   AVPs may need to be inspected as a part of these tasks.  The tasks
   can happen either immediately after record reception or in a post-
   processing phase.  However, as these tasks are typically application
   or even policy dependent, they are not standardized by the Diameter
   specifications.  Applications MAY define requirements on when to
   accept accounting records based on the used value of Accounting-
   Realtime-Required AVP, credit-limit checks, and so on.

   However, the Diameter base protocol defines one optional server side
   state machine that MAY be followed by applications that require
   keeping track of the session state at the accounting server.  Note
   that such tracking is incompatible with the ability to sustain long
   duration connectivity problems.  Therefore, the use of this state
   machine is recommended only in applications where the value of the
   Accounting-Realtime-Required AVP is DELIVER_AND_GRANT; hence,
   accounting connectivity problems are required to cause the serviced
   user to be disconnected.  Otherwise, records produced by the client

Top      Up      ToC       Page 105 
   may be lost by the server, which no longer accepts them after the
   connectivity is re-established.  This state machine is the third
   state machine in this section.  The state machine is supervised by a
   supervision session timer Ts, whose value should be reasonably higher
   than the Acct_Interim_Interval value.  Ts MAY be set to two times the
   value of the Acct_Interim_Interval so as to avoid the accounting
   session in the Diameter server to change to Idle state in case of
   short transient network failure.

   Any event not listed in the state machines MUST be considered as an
   error condition, and a corresponding answer, if applicable, MUST be
   returned to the originator of the message.

   In the state table, the event "Failure to send" means that the
   Diameter client is unable to communicate with the desired
   destination.  This could be due to the peer being down, or due to the
   peer sending back a transient failure or temporary protocol error
   notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or
   DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting
   Answer command.

   The event "Failed answer" means that the Diameter client received a
   non-transient failure notification in the Accounting Answer command.

   Note that the action "Disconnect user/dev" MUST also have an effect
   on the authorization session state table, e.g., cause the STR message
   to be sent, if the given application has both authentication/
   authorization and accounting portions.

   The states PendingS, PendingI, PendingL, PendingE, and PendingB stand
   for pending states to wait for an answer to an accounting request
   related to a Start, Interim, Stop, Event, or buffered record,
   respectively.

                            CLIENT, ACCOUNTING
      State     Event                          Action       New State
      ---------------------------------------------------------------
      Idle      Client or device requests      Send         PendingS
                access                         accounting
                                               start req.

      Idle      Client or device requests      Send         PendingE
                a one-time service             accounting
                                               event req

      Idle      Records in storage             Send         PendingB
                                               record

Top      Up      ToC       Page 106 
      PendingS  Successful accounting                       Open
                start answer received

      PendingS  Failure to send and buffer     Store        Open
                space available and real time  Start
                not equal to DELIVER_AND_GRANT Record

      PendingS  Failure to send and no buffer               Open
                space available and real time
                equal to GRANT_AND_LOSE

      PendingS  Failure to send and no         Disconnect   Idle
                buffer space available and     user/dev
                real time not equal to
                GRANT_AND_LOSE

      PendingS  Failed accounting start answer              Open
                received and real time equal
                to GRANT_AND_LOSE

      PendingS  Failed accounting start answer Disconnect   Idle
                received and real time not     user/dev
                equal to GRANT_AND_LOSE

      PendingS  User service terminated        Store        PendingS
                                               stop
                                               record

      Open      Interim interval elapses       Send         PendingI
                                               accounting
                                               interim
                                               record

      Open      User service terminated        Send         PendingL
                                               accounting
                                               stop req.

      PendingI  Successful accounting interim               Open
                answer received

      PendingI  Failure to send and (buffer    Store        Open
                space available or old         interim
                record can be overwritten)     record
                and real time not equal to
                DELIVER_AND_GRANT

Top      Up      ToC       Page 107 
      PendingI  Failure to send and no buffer               Open
                space available and real time
                equal to GRANT_AND_LOSE

      PendingI  Failure to send and no         Disconnect   Idle
                buffer space available and     user/dev
                real time not equal to
                GRANT_AND_LOSE

      PendingI  Failed accounting interim                   Open
                answer received and real time
                equal to GRANT_AND_LOSE

      PendingI  Failed accounting interim      Disconnect   Idle
                answer received and            user/dev
                real time not equal to
                GRANT_AND_LOSE

      PendingI  User service terminated        Store        PendingI
                                               stop
                                               record
      PendingE  Successful accounting                       Idle
                event answer received

      PendingE  Failure to send and buffer     Store        Idle
                space available                event
                                               record

      PendingE  Failure to send and no buffer               Idle
                space available

      PendingE  Failed accounting event answer              Idle
                received

      PendingB  Successful accounting answer   Delete       Idle
                received                       record

      PendingB  Failure to send                             Idle

      PendingB  Failed accounting answer       Delete       Idle
                received                       record

      PendingL  Successful accounting                       Idle
                stop answer received

      PendingL  Failure to send and buffer     Store        Idle
                space available                stop
                                               record

Top      Up      ToC       Page 108 
      PendingL  Failure to send and no buffer               Idle
                space available

      PendingL  Failed accounting stop answer               Idle
                received


                       SERVER, STATELESS ACCOUNTING
      State     Event                          Action       New State
      ---------------------------------------------------------------

      Idle      Accounting start request       Send         Idle
                received and successfully      accounting
                processed.                     start
                                               answer

      Idle      Accounting event request       Send         Idle
                received and successfully      accounting
                processed.                     event
                                               answer

      Idle      Interim record received        Send         Idle
                and successfully processed.    accounting
                                               interim
                                               answer

      Idle      Accounting stop request        Send         Idle
                received and successfully      accounting
                processed                      stop answer

      Idle      Accounting request received;   Send         Idle
                no space left to store         accounting
                records                        answer;
                                               Result-Code =
                                               OUT_OF_
                                               SPACE

Top      Up      ToC       Page 109 
                            SERVER, STATEFUL ACCOUNTING
      State     Event                          Action       New State
      ---------------------------------------------------------------

      Idle      Accounting start request       Send         Open
                received and successfully      accounting
                processed.                     start
                                               answer;
                                               Start Ts

      Idle      Accounting event request       Send         Idle
                received and successfully      accounting
                processed.                     event
                                               answer
      Idle      Accounting request received;   Send         Idle
                no space left to store         accounting
                records                        answer;
                                               Result-Code =
                                               OUT_OF_
                                               SPACE

      Open      Interim record received        Send         Open
                and successfully processed.    accounting
                                               interim
                                               answer;
                                               Restart Ts

      Open      Accounting stop request        Send         Idle
                received and successfully      accounting
                processed                      stop answer;
                                               Stop Ts

      Open      Accounting request received;   Send         Idle
                no space left to store         accounting
                records                        answer;
                                               Result-Code =
                                               OUT_OF_
                                               SPACE;
                                               Stop Ts

      Open      Session supervision timer Ts   Stop Ts      Idle
                expired

Top      Up      ToC       Page 110 
8.3.  Server-Initiated Re-Auth

   A Diameter server may initiate a re-authentication and/or re-
   authorization service for a particular session by issuing a Re-Auth-
   Request (RAR).

   For example, for prepaid services, the Diameter server that
   originally authorized a session may need some confirmation that the
   user is still using the services.

   An access device that receives an RAR message with the Session-Id
   equal to a currently active session MUST initiate a re-auth towards
   the user, if the service supports this particular feature.  Each
   Diameter application MUST state whether server-initiated re-auth is
   supported, since some applications do not allow access devices to
   prompt the user for re-auth.

8.3.1.  Re-Auth-Request

   The Re-Auth-Request (RAR), indicated by the Command Code set to 258
   and the message flags' 'R' bit set, may be sent by any server to the
   access device that is providing session service, to request that the
   user be re-authenticated and/or re-authorized.


    Message Format

         <RAR>  ::= < Diameter Header: 258, REQ, PXY >
                    < Session-Id >
                    { Origin-Host }
                    { Origin-Realm }
                    { Destination-Realm }
                    { Destination-Host }
                    { Auth-Application-Id }
                    { Re-Auth-Request-Type }
                    [ User-Name ]
                    [ Origin-State-Id ]
                  * [ Proxy-Info ]
                  * [ Route-Record ]
                  * [ AVP ]

8.3.2.  Re-Auth-Answer

   The Re-Auth-Answer (RAA), indicated by the Command Code set to 258
   and the message flags' 'R' bit clear, is sent in response to the RAR.
   The Result-Code AVP MUST be present, and it indicates the disposition
   of the request.

Top      Up      ToC       Page 111 
   A successful RAA message MUST be followed by an application-specific
   authentication and/or authorization message.

    Message Format

         <RAA>  ::= < Diameter Header: 258, PXY >
                    < Session-Id >
                    { Result-Code }
                    { Origin-Host }
                    { Origin-Realm }
                    [ User-Name ]
                    [ Origin-State-Id ]
                    [ Error-Message ]
                    [ Error-Reporting-Host ]
                    [ Failed-AVP ]
                  * [ Redirect-Host ]
                    [ Redirect-Host-Usage ]
                    [ Redirect-Max-Cache-Time ]
                  * [ Proxy-Info ]
                  * [ AVP ]

8.4.  Session Termination

   It is necessary for a Diameter server that authorized a session, for
   which it is maintaining state, to be notified when that session is no
   longer active, both for tracking purposes as well as to allow
   stateful agents to release any resources that they may have provided
   for the user's session.  For sessions whose state is not being
   maintained, this section is not used.

   When a user session that required Diameter authorization terminates,
   the access device that provided the service MUST issue a Session-
   Termination-Request (STR) message to the Diameter server that
   authorized the service, to notify it that the session is no longer
   active.  An STR MUST be issued when a user session terminates for any
   reason, including user logoff, expiration of Session-Timeout,
   administrative action, termination upon receipt of an Abort-Session-
   Request (see below), orderly shutdown of the access device, etc.

   The access device also MUST issue an STR for a session that was
   authorized but never actually started.  This could occur, for
   example, due to a sudden resource shortage in the access device, or
   because the access device is unwilling to provide the type of service
   requested in the authorization, or because the access device does not
   support a mandatory AVP returned in the authorization, etc.

   It is also possible that a session that was authorized is never
   actually started due to action of a proxy.  For example, a proxy may

Top      Up      ToC       Page 112 
   modify an authorization answer, converting the result from success to
   failure, prior to forwarding the message to the access device.  If
   the answer did not contain an Auth-Session-State AVP with the value
   NO_STATE_MAINTAINED, a proxy that causes an authorized session not to
   be started MUST issue an STR to the Diameter server that authorized
   the session, since the access device has no way of knowing that the
   session had been authorized.

   A Diameter server that receives an STR message MUST clean up
   resources (e.g., session state) associated with the Session-Id
   specified in the STR and return a Session-Termination-Answer.

   A Diameter server also MUST clean up resources when the Session-
   Timeout expires, or when the Authorization-Lifetime and the Auth-
   Grace-Period AVPs expire without receipt of a re-authorization
   request, regardless of whether an STR for that session is received.
   The access device is not expected to provide service beyond the
   expiration of these timers; thus, expiration of either of these
   timers implies that the access device may have unexpectedly shut
   down.

8.4.1.  Session-Termination-Request

   The Session-Termination-Request (STR), indicated by the Command Code
   set to 275 and the Command Flags' 'R' bit set, is sent by a Diameter
   client or by a Diameter proxy to inform the Diameter server that an
   authenticated and/or authorized session is being terminated.

    Message Format

        <STR>  ::= < Diameter Header: 275, REQ, PXY >
                   < Session-Id >
                   { Origin-Host }
                   { Origin-Realm }
                   { Destination-Realm }
                   { Auth-Application-Id }
                   { Termination-Cause }
                   [ User-Name ]
                   [ Destination-Host ]
                 * [ Class ]
                   [ Origin-State-Id ]
                 * [ Proxy-Info ]
                 * [ Route-Record ]
                 * [ AVP ]

Top      Up      ToC       Page 113 
8.4.2.  Session-Termination-Answer

   The Session-Termination-Answer (STA), indicated by the Command Code
   set to 275 and the message flags' 'R' bit clear, is sent by the
   Diameter server to acknowledge the notification that the session has
   been terminated.  The Result-Code AVP MUST be present, and it MAY
   contain an indication that an error occurred while servicing the STR.

   Upon sending or receipt of the STA, the Diameter server MUST release
   all resources for the session indicated by the Session-Id AVP.  Any
   intermediate server in the Proxy-Chain MAY also release any
   resources, if necessary.

    Message Format

         <STA> ::= < Diameter Header: 275, PXY >
                    < Session-Id >
                    { Result-Code }
                    { Origin-Host }
                    { Origin-Realm }
                    [ User-Name ]
                  * [ Class ]
                    [ Error-Message ]
                    [ Error-Reporting-Host ]
                    [ Failed-AVP ]
                    [ Origin-State-Id ]
                  * [ Redirect-Host ]
                    [ Redirect-Host-Usage ]
                    [ Redirect-Max-Cache-Time ]
                  * [ Proxy-Info ]
                  * [ AVP ]

8.5.  Aborting a Session

   A Diameter server may request that the access device stop providing
   service for a particular session by issuing an Abort-Session-Request
   (ASR).

   For example, the Diameter server that originally authorized the
   session may be required to cause that session to be stopped for lack
   of credit or other reasons that were not anticipated when the session
   was first authorized.

   An access device that receives an ASR with Session-ID equal to a
   currently active session MAY stop the session.  Whether the access
   device stops the session or not is implementation and/or
   configuration dependent.  For example, an access device may honor
   ASRs from certain agents only.  In any case, the access device MUST

Top      Up      ToC       Page 114 
   respond with an Abort-Session-Answer, including a Result-Code AVP to
   indicate what action it took.

8.5.1.  Abort-Session-Request

   The Abort-Session-Request (ASR), indicated by the Command Code set to
   274 and the message flags' 'R' bit set, may be sent by any Diameter
   server or any Diameter proxy to the access device that is providing
   session service, to request that the session identified by the
   Session-Id be stopped.

    Message Format

         <ASR>  ::= < Diameter Header: 274, REQ, PXY >
                    < Session-Id >
                    { Origin-Host }
                    { Origin-Realm }
                    { Destination-Realm }
                    { Destination-Host }
                    { Auth-Application-Id }
                    [ User-Name ]
                    [ Origin-State-Id ]
                  * [ Proxy-Info ]
                  * [ Route-Record ]
                  * [ AVP ]

8.5.2.  Abort-Session-Answer

   The Abort-Session-Answer (ASA), indicated by the Command Code set to
   274 and the message flags' 'R' bit clear, is sent in response to the
   ASR.  The Result-Code AVP MUST be present and indicates the
   disposition of the request.

   If the session identified by Session-Id in the ASR was successfully
   terminated, the Result-Code is set to DIAMETER_SUCCESS.  If the
   session is not currently active, the Result-Code is set to
   DIAMETER_UNKNOWN_SESSION_ID.  If the access device does not stop the
   session for any other reason, the Result-Code is set to
   DIAMETER_UNABLE_TO_COMPLY.

Top      Up      ToC       Page 115 
    Message Format

         <ASA>  ::= < Diameter Header: 274, PXY >
                    < Session-Id >
                    { Result-Code }
                    { Origin-Host }
                    { Origin-Realm }
                    [ User-Name ]
                    [ Origin-State-Id ]
                    [ Error-Message ]
                    [ Error-Reporting-Host ]
                    [ Failed-AVP ]
                  * [ Redirect-Host ]
                    [ Redirect-Host-Usage ]
                    [ Redirect-Max-Cache-Time ]
                  * [ Proxy-Info ]
                  * [ AVP ]

8.6.  Inferring Session Termination from Origin-State-Id

   The Origin-State-Id is used to allow detection of terminated sessions
   for which no STR would have been issued, due to unanticipated
   shutdown of an access device.

   A Diameter client or access device increments the value of the
   Origin-State-Id every time it is started or powered up.  The new
   Origin-State-Id is then sent in the CER/CEA message immediately upon
   connection to the server.  The Diameter server receiving the new
   Origin-State-Id can determine whether the sending Diameter client had
   abruptly shut down by comparing the old value of the Origin-State-Id
   it has kept for that specific client is less than the new value and
   whether it has un-terminated sessions originating from that client.

   An access device can also include the Origin-State-Id in request
   messages other than the CER if there are relays or proxies in between
   the access device and the server.  In this case, however, the server
   cannot discover that the access device has been restarted unless and
   until it receives a new request from it.  Therefore, this mechanism
   is more opportunistic across proxies and relays.

   The Diameter server may assume that all sessions that were active
   prior to detection of a client restart have been terminated.  The
   Diameter server MAY clean up all session state associated with such
   lost sessions, and it MAY also issue STRs for all such lost sessions
   that were authorized on upstream servers, to allow session state to
   be cleaned up globally.

Top      Up      ToC       Page 116 
8.7.  Auth-Request-Type AVP

   The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is
   included in application-specific auth requests to inform the peers
   whether a user is to be authenticated only, authorized only, or both.
   Note any value other than both MAY cause RADIUS interoperability
   issues.  The following values are defined:

   AUTHENTICATE_ONLY 1

      The request being sent is for authentication only, and it MUST
      contain the relevant application-specific authentication AVPs that
      are needed by the Diameter server to authenticate the user.

   AUTHORIZE_ONLY 2

      The request being sent is for authorization only, and it MUST
      contain the application-specific authorization AVPs that are
      necessary to identify the service being requested/offered.

   AUTHORIZE_AUTHENTICATE 3

      The request contains a request for both authentication and
      authorization.  The request MUST include both the relevant
      application-specific authentication information and authorization
      information necessary to identify the service being requested/
      offered.

8.8.  Session-Id AVP

   The Session-Id AVP (AVP Code 263) is of type UTF8String and is used
   to identify a specific session (see Section 8).  All messages
   pertaining to a specific session MUST include only one Session-Id
   AVP, and the same value MUST be used throughout the life of a
   session.  When present, the Session-Id SHOULD appear immediately
   following the Diameter header (see Section 3).

   The Session-Id MUST be globally and eternally unique, as it is meant
   to uniquely identify a user session without reference to any other
   information, and it may be needed to correlate historical
   authentication information with accounting information.  The
   Session-Id includes a mandatory portion and an implementation-defined
   portion; a recommended format for the implementation-defined portion
   is outlined below.

   The Session-Id MUST begin with the sender's identity encoded in the
   DiameterIdentity type (see Section 4.3.1).  The remainder of the
   Session-Id is delimited by a ";" character, and it MAY be any

Top      Up      ToC       Page 117 
   sequence that the client can guarantee to be eternally unique;
   however, the following format is recommended, (square brackets []
   indicate an optional element):

      <DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]

   <high 32 bits> and <low 32 bits> are decimal representations of the
   high and low 32 bits of a monotonically increasing 64-bit value.  The
   64-bit value is rendered in two part to simplify formatting by 32-bit
   processors.  At startup, the high 32 bits of the 64-bit value MAY be
   initialized to the time in NTP format [RFC5905], and the low 32 bits
   MAY be initialized to zero.  This will for practical purposes
   eliminate the possibility of overlapping Session-Ids after a reboot,
   assuming the reboot process takes longer than a second.
   Alternatively, an implementation MAY keep track of the increasing
   value in non-volatile memory.


   <optional value> is implementation specific, but it may include a
   modem's device Id, a Layer 2 address, timestamp, etc.

   Example, in which there is no optional value:

      accesspoint7.example.com;1876543210;523

   Example, in which there is an optional value:

     accesspoint7.example.com;1876543210;523;mobile@200.1.1.88

   The Session-Id is created by the Diameter application initiating the
   session, which, in most cases, is done by the client.  Note that a
   Session-Id MAY be used for both the authentication, authorization,
   and accounting commands of a given application.

8.9.  Authorization-Lifetime AVP

   The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
   and contains the maximum number of seconds of service to be provided
   to the user before the user is to be re-authenticated and/or re-
   authorized.  Care should be taken when the Authorization-Lifetime
   value is determined, since a low, non-zero value could create
   significant Diameter traffic, which could congest both the network
   and the agents.

   A value of zero (0) means that immediate re-auth is necessary by the
   access device.  The absence of this AVP, or a value of all ones
   (meaning all bits in the 32-bit field are set to one) means no re-
   auth is expected.

Top      Up      ToC       Page 118 
   If both this AVP and the Session-Timeout AVP are present in a
   message, the value of the latter MUST NOT be smaller than the
   Authorization-Lifetime AVP.

   An Authorization-Lifetime AVP MAY be present in re-authorization
   messages, and it contains the number of seconds the user is
   authorized to receive service from the time the re-auth answer
   message is received by the access device.

   This AVP MAY be provided by the client as a hint of the maximum
   lifetime that it is willing to accept.  The server MUST return a
   value that is equal to, or smaller than, the one provided by the
   client.

8.10.  Auth-Grace-Period AVP

   The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and
   contains the number of seconds the Diameter server will wait
   following the expiration of the Authorization-Lifetime AVP before
   cleaning up resources for the session.

8.11.  Auth-Session-State AVP

   The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and
   specifies whether state is maintained for a particular session.  The
   client MAY include this AVP in requests as a hint to the server, but
   the value in the server's answer message is binding.  The following
   values are supported:

   STATE_MAINTAINED 0

      This value is used to specify that session state is being
      maintained, and the access device MUST issue a session termination
      message when service to the user is terminated.  This is the
      default value.

   NO_STATE_MAINTAINED 1

      This value is used to specify that no session termination messages
      will be sent by the access device upon expiration of the
      Authorization-Lifetime.

8.12.  Re-Auth-Request-Type AVP

   The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and
   is included in application-specific auth answers to inform the client
   of the action expected upon expiration of the Authorization-Lifetime.

Top      Up      ToC       Page 119 
   If the answer message contains an Authorization-Lifetime AVP with a
   positive value, the Re-Auth-Request-Type AVP MUST be present in an
   answer message.  The following values are defined:

   AUTHORIZE_ONLY 0

      An authorization only re-auth is expected upon expiration of the
      Authorization-Lifetime.  This is the default value if the AVP is
      not present in answer messages that include the Authorization-
      Lifetime.

   AUTHORIZE_AUTHENTICATE 1

      An authentication and authorization re-auth is expected upon
      expiration of the Authorization-Lifetime.

8.13.  Session-Timeout AVP

   The Session-Timeout AVP (AVP Code 27) [RFC2865] is of type Unsigned32
   and contains the maximum number of seconds of service to be provided
   to the user before termination of the session.  When both the
   Session-Timeout and the Authorization-Lifetime AVPs are present in an
   answer message, the former MUST be equal to or greater than the value
   of the latter.

   A session that terminates on an access device due to the expiration
   of the Session-Timeout MUST cause an STR to be issued, unless both
   the access device and the home server had previously agreed that no
   session termination messages would be sent (see Section 8).

   A Session-Timeout AVP MAY be present in a re-authorization answer
   message, and it contains the remaining number of seconds from the
   beginning of the re-auth.

   A value of zero, or the absence of this AVP, means that this session
   has an unlimited number of seconds before termination.

   This AVP MAY be provided by the client as a hint of the maximum
   timeout that it is willing to accept.  However, the server MAY return
   a value that is equal to, or smaller than, the one provided by the
   client.

8.14.  User-Name AVP

   The User-Name AVP (AVP Code 1) [RFC2865] is of type UTF8String, which
   contains the User-Name, in a format consistent with the NAI
   specification [RFC4282].

Top      Up      ToC       Page 120 
8.15.  Termination-Cause AVP

   The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and
   is used to indicate the reason why a session was terminated on the
   access device.  The currently assigned values for this AVP can be
   found in the IANA registry for Termination-Cause AVP Values
   [IANATCV].

8.16.  Origin-State-Id AVP

   The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a
   monotonically increasing value that is advanced whenever a Diameter
   entity restarts with loss of previous state, for example, upon
   reboot.  Origin-State-Id MAY be included in any Diameter message,
   including CER.

   A Diameter entity issuing this AVP MUST create a higher value for
   this AVP each time its state is reset.  A Diameter entity MAY set
   Origin-State-Id to the time of startup, or it MAY use an incrementing
   counter retained in non-volatile memory across restarts.

   The Origin-State-Id, if present, MUST reflect the state of the entity
   indicated by Origin-Host.  If a proxy modifies Origin-Host, it MUST
   either remove Origin-State-Id or modify it appropriately as well.
   Typically, Origin-State-Id is used by an access device that always
   starts up with no active sessions; that is, any session active prior
   to restart will have been lost.  By including Origin-State-Id in a
   message, it allows other Diameter entities to infer that sessions
   associated with a lower Origin-State-Id are no longer active.  If an
   access device does not intend for such inferences to be made, it MUST
   either not include Origin-State-Id in any message or set its value to
   0.

8.17.  Session-Binding AVP

   The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and it
   MAY be present in application-specific authorization answer messages.
   If present, this AVP MAY inform the Diameter client that all future
   application-specific re-auth and Session-Termination-Request messages
   for this session MUST be sent to the same authorization server.

Top      Up      ToC       Page 121 
   This field is a bit mask, and the following bits have been defined:

   RE_AUTH 1

      When set, future re-auth messages for this session MUST NOT
      include the Destination-Host AVP.  When cleared, the default
      value, the Destination-Host AVP MUST be present in all re-auth
      messages for this session.

   STR 2

      When set, the STR message for this session MUST NOT include the
      Destination-Host AVP.  When cleared, the default value, the
      Destination-Host AVP MUST be present in the STR message for this
      session.

   ACCOUNTING 4

      When set, all accounting messages for this session MUST NOT
      include the Destination-Host AVP.  When cleared, the default
      value, the Destination-Host AVP, if known, MUST be present in all
      accounting messages for this session.

8.18.  Session-Server-Failover AVP

   The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated
   and MAY be present in application-specific authorization answer
   messages that either do not include the Session-Binding AVP or
   include the Session-Binding AVP with any of the bits set to a zero
   value.  If present, this AVP MAY inform the Diameter client that if a
   re-auth or STR message fails due to a delivery problem, the Diameter
   client SHOULD issue a subsequent message without the Destination-Host
   AVP.  When absent, the default value is REFUSE_SERVICE.

   The following values are supported:

   REFUSE_SERVICE 0

      If either the re-auth or the STR message delivery fails, terminate
      service with the user and do not attempt any subsequent attempts.

Top      Up      ToC       Page 122 
   TRY_AGAIN 1

      If either the re-auth or the STR message delivery fails, resend
      the failed message without the Destination-Host AVP present.

   ALLOW_SERVICE 2

      If re-auth message delivery fails, assume that re-authorization
      succeeded.  If STR message delivery fails, terminate the session.

   TRY_AGAIN_ALLOW_SERVICE 3

      If either the re-auth or the STR message delivery fails, resend
      the failed message without the Destination-Host AVP present.  If
      the second delivery fails for re-auth, assume re-authorization
      succeeded.  If the second delivery fails for STR, terminate the
      session.

8.19.  Multi-Round-Time-Out AVP

   The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32 and
   SHOULD be present in application-specific authorization answer
   messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH.
   This AVP contains the maximum number of seconds that the access
   device MUST provide the user in responding to an authentication
   request.

8.20.  Class AVP

   The Class AVP (AVP Code 25) is of type OctetString and is used by
   Diameter servers to return state information to the access device.
   When one or more Class AVPs are present in application-specific
   authorization answer messages, they MUST be present in subsequent re-
   authorization, session termination and accounting messages.  Class
   AVPs found in a re-authorization answer message override the ones
   found in any previous authorization answer message.  Diameter server
   implementations SHOULD NOT return Class AVPs that require more than
   4096 bytes of storage on the Diameter client.  A Diameter client that
   receives Class AVPs whose size exceeds local available storage MUST
   terminate the session.

8.21.  Event-Timestamp AVP

   The Event-Timestamp (AVP Code 55) is of type Time and MAY be included
   in an Accounting-Request and Accounting-Answer messages to record the
   time that the reported event occurred, in seconds since January 1,
   1900 00:00 UTC.


Next RFC Part