|
Written by Hemanshu Patel
|
|
Tuesday, 06 November 2007 |
|
Page 9 of 13
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.
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.
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'.
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
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
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
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
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
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
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
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
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.
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.
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
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 ]
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
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.
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.
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):
<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;
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
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.
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:
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:
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.
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
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.
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.
|
|
| |
|
|
Diameter Protocol 
