tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3588

 
 
 

Diameter Base Protocol

Part 4 of 5, p. 90 to 124
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 90 
8.  Diameter User Sessions

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

Top      Up      ToC       Page 91 
   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 use 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 the home realm is willing to be fiscally
   responsible for.  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.

   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 is used to terminate user
   sessions.  These are used to allow servers that maintain state
   information to free resources.

Top      Up      ToC       Page 92 
   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.

8.1.  Authorization Session State Machine

   This section contains a set of finite state machines, representing
   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 as an error
   condition, and an answer, if applicable, MUST be returned to the
   originator of the message.

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

Top      Up      ToC       Page 93 
   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

   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

   Pending   Failed Service-specific        Cleanup    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      Session-Timeout Expires on     Send STR   Discon
             Access Device

Top      Up      ToC       Page 94 
   Open      ASR Received,                  Send ASA   Discon
             client will comply with        with
             request to end the session     Result-Code
                                            = SUCCESS,
                                            Send STR.

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

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

   Discon    ASR Received                   Send ASA   Discon

   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             serv.
                                            specific answer

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

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

   Open      Service-specific authorization Send       Idle
             request received, and user     failed serv.
             is not authorized              specific
                                            answer,
                                            Cleanup

   Open      Home server wants to           Send ASR   Discon
             terminate the service

Top      Up      ToC       Page 95 
   Open      Authorization-Lifetime (and    Cleanup    Idle
             Auth-Grace-Period) expires
             on home server.

   Open      Session-Timeout expires on     Cleanup    Idle
             home server

   Discon    Failure to send ASR            Wait,      Discon
                                            resend ASR

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

   Not       ASA Received                   None       No Change.
   Discon

   Any       STR Received                   Send STA,  Idle
                                            Cleanup.

   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        Cleanup    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 96 
   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 serv. Idle
             request received, and          specific
             successfully processed         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 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.
   Both base Diameter AVPs as well as application specific AVPs MAY 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 limits 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, and hence
   accounting connectivity problems are required to cause the serviced
   user to be disconnected.  Otherwise, records produced by the client

Top      Up      ToC       Page 97 
   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, which the 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 have an effect also
   to 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 98 
   PendingS  Successful accounting                     Open
             start answer received

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

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

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

   PendingS  Failed accounting start answer            Open
             received and realtime equal
             to GRANT_AND_LOSE

   PendingS  Failed accounting start answer Disconnect Idle
             received and realtime 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 record  interim
             can be overwritten) and        record
             realtime not equal to
             DELIVER_AND_GRANT

   PendingI  Failure to send and no buffer             Open
             space available and realtime
             equal to GRANT_AND_LOSE

Top      Up      ToC       Page 99 
   PendingI  Failure to send and no buffer  Disconnect Idle
             space available and realtime   user/dev
             not equal to GRANT_AND_LOSE

   PendingI  Failed accounting interim                 Open
             answer received and realtime
             equal to GRANT_AND_LOSE

   PendingI  Failed accounting interim      Disconnect Idle
             answer received and realtime   user/dev
             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

   PendingL  Failure to send and no buffer             Idle
             space available

   PendingL  Failed accounting stop answer             Idle
             received

Top      Up      ToC       Page 100 
                    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

                         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

Top      Up      ToC       Page 101 
   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

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 pre-paid 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 a RAR message with 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 service-initiated re-auth is
   supported, since some applications do not allow access devices to
   prompt the user for re-auth.

Top      Up      ToC       Page 102 
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 indicates the disposition of
   the request.

   A successful RAA message MUST be followed by an application-specific
   authentication and/or authorization message.

Top      Up      ToC       Page 103 
   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-Host-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
   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

Top      Up      ToC       Page 104 
   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 expires 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 the access
   device 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 105 
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 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
   credit or other reasons that were not anticipated when the session
   was first authorized.  On the other hand, an operator may maintain a
   management server for the purpose of issuing ASRs to administratively
   remove users from the network.

   An access device that receives an ASR with Session-ID equal to a
   currently active session MAY stop the session.  Whether the access

Top      Up      ToC       Page 106 
   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
   respond with an Abort-Session-Answer, including a Result-Code AVP to
   indicate what action it took.

   Note that if the access device does stop the session upon receipt of
   an ASR, it issues an STR to the authorizing server (which may or may
   not be the agent issuing the ASR) just as it would if the session
   were terminated for any other reason.

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 server 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, Result-Code is set to DIAMETER_SUCCESS.  If the session
   is not currently active, Result-Code is set to
   DIAMETER_UNKNOWN_SESSION_ID.  If the access device does not stop the
   session for any other reason, Result-Code is set to
   DIAMETER_UNABLE_TO_COMPLY.

Top      Up      ToC       Page 107 
   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

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

   By including Origin-State-Id in CER/CEA messages, an access device
   allows a next-hop server to determine immediately upon connection
   whether the device has lost its sessions since the last connection.

   By including Origin-State-Id in request messages, an access device
   also allows a server with which it communicates via proxy to make
   such a determination.  However, a server that is not directly
   connected with the access device will not discover that the access
   device has been restarted unless and until it receives a new request
   from the access device.  Thus, use of this mechanism across proxies
   is opportunistic rather than reliable, but useful nonetheless.

   When a Diameter server receives an Origin-State-Id that is greater
   than the Origin-State-Id previously received from the same issuer, it
   may assume that the issuer has lost state since the previous message
   and that all sessions that were active under the lower Origin-State-
   Id have been terminated.  The Diameter server MAY clean up all
   session state associated with such lost sessions, and MAY also issues
   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 108 
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 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 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 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.4).  The remainder of the
   Session-Id is delimited by a ";" character, and MAY be any sequence
   that the client can guarantee to be eternally unique; however, the
   following format is recommended, (square brackets [] indicate an
   optional element):

Top      Up      ToC       Page 109 
   <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, 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 may include a modem's
   device Id, a layer 2 address, timestamp, etc.

   Example, in which there is no optional value:
      accesspoint7.acme.com;1876543210;523

   Example, in which there is an optional value:
      accesspoint7.acme.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 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.  Great 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.  This is typically used in cases where multiple
   authentication methods are used, and a successful auth response with
   this AVP set to zero is used to signal that the next authentication
   method is to be immediately initiated.  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.

   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.

Top      Up      ToC       Page 110 
   An Authorization-Lifetime AVP MAY be present in re-authorization
   messages, and 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.  However, the server MAY
   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.
   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:

Top      Up      ToC       Page 111 
   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) [RADIUS] 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.9).

   A Session-Timeout AVP MAY be present in a re-authorization answer
   message, and 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) [RADIUS] is of type UTF8String, which
   contains the User-Name, in a format consistent with the NAI
   specification [NAI].

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 following values are defined:

Top      Up      ToC       Page 112 
   DIAMETER_LOGOUT                   1
      The user initiated a disconnect

   DIAMETER_SERVICE_NOT_PROVIDED     2
      This value is used when the user disconnected prior to the receipt
      of the authorization answer message.

   DIAMETER_BAD_ANSWER               3
      This value indicates that the authorization answer received by the
      access device was not processed successfully.

   DIAMETER_ADMINISTRATIVE           4
      The user was not granted access, or was disconnected, due to
      administrative reasons, such as the receipt of a Abort-Session-
      Request message.

   DIAMETER_LINK_BROKEN              5
      The communication to the user was abruptly disconnected.

   DIAMETER_AUTH_EXPIRED             6
      The user's access was terminated since its authorized session time
      has expired.

   DIAMETER_USER_MOVED               7
      The user is receiving services from another access device.

   DIAMETER_SESSION_TIMEOUT          8
      The user's session has timed out, and service has been terminated.

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.

Top      Up      ToC       Page 113 
   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 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 messages for this session MUST be sent
   to the same authorization server.  This AVP MAY also specify that a
   Session-Termination-Request message for this session MUST be sent to
   the same authorizing server.

   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

Top      Up      ToC       Page 114 
   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.

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

Top      Up      ToC       Page 115 
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.

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 [ACCMGMT] have been built in to 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 [ACCMGMT], 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 applications.

   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.

Top      Up      ToC       Page 116 
   The Diameter accounting server MAY override the interim interval or
   the realtime 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.

9.2.  Protocol Messages

   A Diameter node that receives a successful authentication and/or
   authorization messages from the Home AAA server MUST collect
   accounting information for the session.  The Accounting-Request
   message is used to transmit the accounting information to the Home
   AAA 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.  A rejected Accounting-Request message MAY cause
   the user's session to be terminated, depending on the value of the
   Accounting-Realtime-Required AVP received earlier for the session in
   question.

   Each Diameter Accounting protocol message MAY be compressed, in order
   to reduce network bandwidth usage.  If IPsec and IKE are used to
   secure the Diameter session, then IP compression [IPComp] MAY be used
   and IKE [IKE] MAY be used to negotiate the compression parameters.
   If TLS is used to secure the Diameter session, then TLS compression
   [TLS] MAY be used.

9.3.  Application document requirements

   Each Diameter application (e.g., NASREQ, MobileIP), MUST define their
   Service-Specific AVPs that MUST be present in the Accounting-Request
   message in a section entitled "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 this section.

9.4.  Fault Resilience

   Diameter Base protocol mechanisms are used to overcome small message
   loss and network faults of 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 same record to several servers and duplication of messages

Top      Up      ToC       Page 117 
   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 starting sending the records in the non-volatile
   memory to the accounting server with 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
   how many accounting records may at most 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 oldest, undelivered or 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
   client.  If strong authentication across agents is required, end-to-
   end security may be used for authentication purposes.

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

Top      Up      ToC       Page 118 
   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
   the START_RECORD and STOP_RECORD, marked INTERIM_RECORD.  The
   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
   session.

   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_RECORD 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

   The Diameter protocol's Session-Id AVP, which is globally unique (see
   Section 8.8), is used during the authorization phase to identify a
   particular session.  Services that do not require any authorization
   still use the Session-Id AVP to identify sessions.  Accounting
   messages MAY use a different Session-Id from that sent in
   authorization messages.  Specific applications MAY require different
   a Session-ID for accounting messages.

   However, there are certain applications that require multiple
   accounting sub-sessions.  Such applications would send messages with
   a constant Session-Id AVP, but a different Accounting-Sub-Session-Id
   AVP.  In these cases, correlation is performed using the Session-Id.
   It is important to note that receiving a STOP_RECORD 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.

   Furthermore, there are certain applications where a user receives
   service from different access devices (e.g., Mobile IPv4), each with
   their own unique Session-Id.  In such cases, the Acct-Multi-Session-
   Id AVP is used for correlation.  During authorization, a server that

Top      Up      ToC       Page 119 
   determines that a request is for an existing session SHOULD include
   the Acct-Multi-Session-Id AVP, which the access device MUST include
   in all subsequent accounting messages.

   The Acct-Multi-Session-Id AVP MAY include the value of the original
   Session-Id.  It's contents are implementation specific, but MUST be
   globally unique across other Acct-Multi-Session-Id, 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 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.

   One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
   MUST be present.  If the Vendor-Specific-Application-Id grouped AVP
   is present, it must have an Acct-Application-Id inside.

   The AVP listed below SHOULD include service specific accounting AVPs,
   as described in Section 9.3.

Top      Up      ToC       Page 120 
   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 ]
                [ 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 and includes the usage AVPs only
   if CMS is in use when sending this command.  Note that the inclusion
   of the usage AVPs when CMS is not being used leads to unnecessarily
   large answer messages, and can not be used as a server's proof of the
   receipt of these AVPs in an end-to-end fashion.  If the Accounting-
   Request was protected by end-to-end security, then the corresponding
   ACA message MUST be protected by end-to-end security.

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

   One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
   MUST be present.  If the Vendor-Specific-Application-Id grouped AVP
   is present, it must have an Acct-Application-Id inside.

   The AVP listed below SHOULD include service specific accounting AVPs,
   as described in Section 9.3.

Top      Up      ToC       Page 121 
   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-Reporting-Host ]
                [ 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:

   EVENT_RECORD                    1
      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 is the only record of the service.

   START_RECORD                    2
      An 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.

Top      Up      ToC       Page 122 
   INTERIM_RECORD                  3
      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.

   STOP_RECORD                     4
      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

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

Top      Up      ToC       Page 123 
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 together 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 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.

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.

Top      Up      ToC       Page 124 
   DELIVER_AND_GRANT                           1
      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.

   GRANT_AND_STORE                             2
      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.

   GRANT_AND_LOSE                              3
      The AVP with Value field set to GRANT_AND_LOSE means that service
      SHOULD be granted even if the records can not be delivered or
      stored.



(page 124 continued on part 5)

Next RFC Part