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.
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.
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
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.
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
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
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.
This section defines Command-Code values that MUST be supported by
all Diameter implementations that provide Accounting services.
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.
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 ]
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.
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 ]
This section contains AVPs that describe accounting usage information
related to a specific session.
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.
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.
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.
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.
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.
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.
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.
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.
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.
