Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
Access Router
AAAC Client
Integrated
Logger
QoS Manager
Integrated
Logger
Local
Log
Audit
Trail
Auditing
Local
Log Mgmt
Central Log
Mgmt
Figure 92: Auditing and Logging Architecture
The task carried out by the Integrated Logger should not significantly affect the tasks of the hosting
entity, i.e., the AAAC Client and the QoS Manager. This is the reason why the event logs are not s ent
directly to a central Audit Trail, which may last longer due to the network communication overhead.
Since QoS Manager does not aware of NAI, a way to map a CoA to NAI needs to be found to allow for
logging of NAI in the service authorization event logs. This mapping can be done with the help of the
AAAC Client, who knows exactly which NAI a certain CoA belongs to, as long as the MN having this
CoA is currently registered by this AAAC Client. Because this is a logging issue, the required
communication will be carried out between the AAAC Client’s Integrated Logger and the QoS Manager’s
Integrated Logger. The information on CoA-NAI mapping will be provided to the Integrated Logger by
the AAAC Client.
The Local Log is not implemented as a flat file, but as a MySQL database. This requires a running
MySQL server in each Access Router. Logs that have been successfully sent to the Central Log
Management will be deleted from the Local Log. In this regard MySQL provides for a reliable and easy
manipulation of event logs.
Since each Local Log Management in each Access Router is connected to the Central Log Management,
the data transfer need to be controlled, so that no packet loss occurs due to buffer overflow.
The Audit Trail is a MySQL database, which has the same structure as the Local Log. It stores the event
logs collected from every Local Log before being processed by the Auditing module. Logs in the Audit
Trail that have been completely processed will be deleted or moved into data archives by the Auditing
module. The result of the auditing process is a report telling whether or not violation to each commitment
has occurred. This report is written into different flat files for each customer in case of user registration
and service authorization, and for each entity in case of entity availability.
4.5.6.4 Data Structures
Based on the logging requirements, five types of events have been identified, which can be separated into
three groups. The five types of events are Entity Availability Event, User Registration Request Event,
User Registration Response Event, Service Authorization Request Event, and Service Authorization
Response Event. The three groups are obviously Entity Availability Event Group, User Registration
Event Group, and Service Authorization Event Group. All event logs in a group will be stored in the same
MySQL table in the Local Log, and after being collected in the same MySQL table in the Audit Trail.
The three tables corresponding to the three groups are named SoL (Sign of Life), UsrReg (User
Registration), and SvcAuth (Service Authorization). The following subsections describe the data structure
of each table.
4.5.6.4.1 Sign of Life
MySQL Table: SoL
D0103v1.doc 137 / 168