Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
4.5.6.2 Requirements
4.5.6.2.1 Auditing Requirements
There are three tasks to be accomplished to detect SLG violation:
? Determine the downtime of MobyDick entities
? Determine whether all consecutive registration attempts of a user currently in the home
domain, fail within the pre-defined time interval . Failures due to invalid NAI and credentials
do not violate SLG. To perform this task it is necessary to query the customer database to check,
whether the NAI is valid (is a home user). The validity check of the credentials supplied by the
user will rely on the response coming from the AAAC server. This response is reflected in the
AAAC client’s response to the mobile terminal. This means correct implementation and
behaviour of the AAAC server and client is assumed and expected.
? Determine whether all consecutive service requests of an authenticated user are rejected or
ignored within the pre-defined time interval .
4.5.6.2.2 Logging Requirements
Downtime determination requires Moby Dick entities to periodically send a sign of life. The sign of life
contains the identity of the entity (EntityID) and a Timestamp. The time interval must be configurable.
To determine whether registration attempts are successful following events need to be logged:
? Each valid registration request must be logged by the AAAC Client,
? Each registration response must be logged by the AAAC Client.
The receipt of a valid registration request must be logged and the log must contain the following
information: EventID, Timestamp, CoA, and NAI. EventID identifies uniquely the event that occurs; in
this case the arrival of a valid registration request.
The arrival of a valid registration request will trigger a sequence of message exchange in the provider’s
network to carry out the registration process. In the end the AAAC Client will receive a response from the
AAAC Server or a request timeout will occur. This will lead to AAAC Client sends a registration
response containing the result of the request to the MN. Note here that communication errors can lead to
missing response. MN should perform registration retries, if no positive answer is received after a certain
timeout. The following information needs to be logged after sending a response to the MN: EventID,
Timestamp, CoA, NAI, and ResultCode. The ResultCode should tell whether the registration is successful
or not, and if not due to what reason.
To determine whether service requests are accepted following events need to be logged:
• Each service request sent to QoS broker must be logged by the QoS Manager,
• Each corresponding response coming from QoS broker must be logged by the QoS Manager.
After detecting that a new service is requested by a MN (MN sends a packet marked with a DSCP not
being used), the QoS Manager in the access router needs to log the following information regarding this
event: EventID, Timestamp, DSCP, DestAddr, CoA, and NAI. EventID identifies the arrival of a service
request.
The arrival of a service request will trigger a sequence of message exchange between QoS Manager and
QoS Broker. In the end the QoS Manager will receive a response from the QoS Broker or a request
timeout will occur. This will lead to QoS Manager configures the Access Router to forward or drop the
packets of this requested service. The following information needs to be logged: EventID, Timestamp,
DSCP, DestAddr, CoA, NAI, and ResultCode. The ResultCode states whether the requested service is
accepted or not, and if not due to what reason.
4.5.6.3 Architecture
The following figure depicts the logging and auditing architecture. As described in the section on
Logging Requirements, in addition to availability events, AAAC Clients have to log user registration
events, while QoS Managers have to log service authorization events. Both entities, the AAAC Client and
the QoS Manager, reside in each Access Router. Events to be logged will first be stored in the Local Log
via an Integrated Logger. This Local Log will be managed by Local Log Management module, which has
the responsibility to transfer the logs to the Central Log Management module. The Central Log
Management module will store the logs in the Audit Trail before being fetched by the Auditing module to
be examined with respect to the given commitments.
D0103v1.doc 136 / 168