Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
{ MIPv6-Home-Agent-Address }, { MIP-Binding-Update }
the HMAC-MD5 is computed using SK[MN-AAAC.h]
4.5.2.9.4 AAAC.f to Attendant
Message:
Parameters:
AA Registration Answer foreign (ARA.f)
Session-Id
Result-Code
AAAC.h-MN-AVPs
4.5.2.10 Attendant to MN (UDP message)
Message:
Parameters :
4.5.3 Accounting DB
Mobile Node AAA Reply (MNARp)
Session-Id
Result-Code
AAAC.h-MN-AVPs
A session, that has been started after a successfully authentication and authorization, must also be
accounted for. Several AAA entities are involved in accounting e.g. attendant, AAAC.f, AAAC.h.
4.5.3.1 AAAC Client
The AAAC Client receives answers from AAAC.f for issued AA requests. In case of a negative answer
the answer is forwarded to the meter client (as usual) and no accounting takes place.
In case of a positive answer the AAAC client configures its accounting functionality according to the
accounting policies contained in the AA answer. If no such policies are present it configures accounting
according to a default configuration specified before starting the client. Accounting is configured before
the answer is forwarded to the client. If some error occurs it is open what happens. Possible solutions are:
• The AAAC client forwards answer to the meter client, session takes place as usual (may be no
accounting or missing accounting data)
• The client sends a message to AAAC.f, AAAC.f can try to get around the problem in which case the
client forwards the positive reply. In the other case it forwards the negative reply.
In the implementation the first option will be preferred and used.
After forwarding the AA answer the client immediately generates an accounting start request and sends it
to the AAAC.f.
During a session runtime the client generates interim accounting messages and sends them to AAAC.f.
If the client receives a session stop indication it generates an accounting stop request and sends it to the
AAAC.f.
The AAAC client has an interface to the metering functionality on the access router. It sends a
METER_START message containing a filter spec and all other configuration parameters when
accounting is started. It may receive a handle from the metering function. It sends a METER_STOP
message containing a filter spec or handle previously received to stop metering for that particular session.
The following information is needed as filter:
• mobile nodes IP address (CoA)
• mobile nodes ports (in case of specific QoS sessions which are flow based) (known through specific
AA request from MN).
• DSCP (either 0 for registration or specific value for QoS session; note that signalling traffic between
MN and AR is supposed to have DSCP!=0 so this traffic is not accounted which is intended).
The AAAC client must have a function to retrieve meter data for a particular session. A
GET_METER_DATA function must be supported by the metering which accepts CoA or handle and
return all current accounting information for a particular MN.
The meter data could also be stored in a DB as long as there is a logic that can handle the
GET_METER_DATA function and deliver requested data.
D0103v1.doc 118 / 168