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.
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.
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 access Send service-specific Pending
auth req auth req
Idle ASR Received for unknown session Send ASA with Idle
Result-Code =
UNKNOWN_SESSION_ID
Idle RAR Received for unknown session Send RAA with Idle
Result-Code =
UNKNOWN_SESSION_ID
Pending Successful service-specific authorization Grant Access Open
answer received with default
Auth-Session-State value
Pending Successful service-specific authorization Sent STR Discon
answer received,
but service not provided
Pending Error processing successful Sent STR Discon
service-specific authorization
answer
Pending Failed service-specific authorization Clean up Idle
answer received
Open User or client device requests access Send service-specific Open
auth req auth req
Open Successful service-specific authorization Provide service Open
answer received
Open Failed service-specific authorization Discon. user/device Idle
answer received.
Open RAR received and client will perform Send RAA with Open
subsequent re-auth Result-Code =
SUCCESS
Open RAR received and client will not perform Send RAA with Idle
subsequent re-auth Result-Code !=
SUCCESS,
Discon. user/device
Open Session-Timeout expires on access device Send STR Discon
Open ASR received, client will comply with Send ASA with Discon
request to end the session Result-Code =
SUCCESS,
Send STR.
Open ASR Received, client will not comply with Send ASA with Open
request to end the session Result-Code !=
SUCCESS
Open Authorization-Lifetime + Auth-Grace-Period Send STR Discon
expires on access device
Discon ASR received Send ASA Discon
Discon STA received Discon. user/device Idle
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 request Send successful Open
received, and user is authorized service-specific
answer
Idle Service-specific authorization request Send failed Idle
received, and user is not authorized service-specific
answer
Open Service-specific authorization request Send successful Open
received, and user is authorized service-specific
answer
Open Service-specific authorization request Send failed Idle
received, and user is not authorized service-specific
answer,
Clean up
Open Home server wants to confirm authentication Send RAR Pending
and/or authorization of the user
Pending Received RAA with a failed Result-Code Clean up Idle
Pending Received RAA with Result-Code = SUCCESS Update session Open
Open Home server wants to terminate the service Send ASR Discon
Open Authorization-Lifetime (and Auth-Grace-Period) Clean up Idle
expires on home server
Open Session-Timeout expires on home server Clean up Idle
Discon Failure to send ASR Wait, resend ASR Discon
Discon ASR successfully sent and ASA Received Clean up Idle
with Result-Code
Not Discon ASA Received None No Change
Discon Any STR Received Send STA, Clean up Idle
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 access Send service-specific Pending
auth req auth req
Pending Successful service-specific authorization Grant access Open
answer received with Auth-Session-
State set to NO_STATE_MAINTAINED
Pending Failed service-specific authorization Clean up Idle
answer received
Open Session-Timeout expires on access device Discon. user/device Idle
Open Service to user is terminated Discon. user/device Idle
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 request Send successfully Idle
received, and successfully processed processed service-
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 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 access Send accounting PendingS
accounting start req. start req.
Idle Client or device requests a one-time service Send accounting PendingE
accounting event req event req
Idle Records in storage Send record PendingB
record
PendingS Successful accounting start answer received Open
PendingS Failure to send and buffer space available Store Start Open
and real time not equal to Record
DELIVER_AND_GRANT
PendingS Failure to send and no buffer space available Open
and real time equal to GRANT_AND_LOSE
PendingS Failure to send and no buffer space available Disconnect user/dev Idle
and real time not equal to
GRANT_AND_LOSE
PendingS Failed accounting start answer received and Open
real time equal to GRANT_AND_LOSE
PendingS Failed accounting start answer received and Disconnect user/dev Idle
real time not equal to GRANT_AND_LOSE
PendingS User service terminated stop Store stop PendingS
record
Open Interim interval elapses Send accounting PendingI
interim
record
Open User service terminated Send accounting PendingL
stop req.
PendingI Successful accounting interim answer received Open
PendingI Failure to send and (buffer space available Store interim Open
or old interim record can be overwritten) record
and real time not equal to
DELIVER_AND_GRANT
PendingI Failure to send and no buffer space available Open
and real time equal to GRANT_AND_LOSE
PendingI Failure to send and no buffer space available Disconnect user/dev Idle
and real time not equal to GRANT_AND_LOSE
PendingI Failed accounting interim answer received and Open
real time equal to GRANT_AND_LOSE
PendingI Failed accounting interim answer received and Disconnect user/dev Idle
real time not equal to GRANT_AND_LOSE
PendingI User service terminated stop Store stop PendingI
record
PendingE Successful accounting event answer received Idle
PendingE Failure to send and buffer space available Store event Idle
record
PendingE Failure to send and no buffer space available Idle
PendingE Failed accounting event answer received Idle
PendingB Successful accounting answer received Delete record Idle
PendingB Failure to send Idle
PendingB Failed accounting answer received Delete record Idle
PendingL Successful accounting stop answer received Idle
PendingL Failure to send and buffer space available Store stop Idle
record
PendingL Failure to send and no buffer space available Idle
PendingL Failed accounting stop answer received Idle
SERVER, STATELESS ACCOUNTING
State Event Action New State
---------------------------------------------------------------------------------------------------
Idle Accounting start request received and Send accounting Idle
successfully processed. start answer
Idle Accounting event request received and Send accounting Idle
successfully processed. event answer
Idle Interim record received and successfully Send accounting Idle
processed. interim answer
Idle Accounting stop request received and Send accounting Idle
successfully processed stop answer
Idle Accounting request received; no space left Send accounting Idle
to store records answer;
Result-Code =
OUT_OF_SPACE
SERVER, STATEFUL ACCOUNTING
State Event Action New State
---------------------------------------------------------------------------------------------------
Idle Accounting start request received and Send accounting Open
successfully processed. start answer;
Start Ts
Idle Accounting event request received and Send accounting Idle
successfully processed. event answer
Idle Accounting request received; no space left Send accounting Idle
to store records answer;
Result-Code =
OUT_OF_SPACE
Open Interim record received and successfully Send accounting Open
processed. interim answer;
Restart Ts
Open Accounting stop request received and Send accounting Idle
successfully processed stop answer;
Stop Ts
Open Accounting request received; no space left Send accounting Idle
to store records answer;
Result-Code =
OUT_OF_SPACE;
Stop Ts
Open Session supervision timer Ts expired Stop Ts Idle
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
::= < 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.
A successful RAA message MUST be followed by an application-specific authentication and/or authorization message.
Message Format
::= < 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 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
::= < 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 ]
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
::= < 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 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
::= < 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.
Message Format
::= < 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.
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 sequence that the client can guarantee to be eternally unique; however, the following format is recommended, (square brackets [] indicate an optional element):
<high>;<low>[;<optional>]
<high> and <low> 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> 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;[email protected]
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.
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.
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].
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.
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.
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.