Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
LoggerID VARCHAR (255) “arc.ethz.ch:qosmanager”
LogTime DATETIME “2002-12-31 22:40:11”
EventID
TINYINT UNSIGNED
(Value 0 to 255)
CoA VARCHAR (255) “2000::1:2:3:4”
DestAddr VARCHAR (255) “2000::7:7:7:4”
NAI VARCHAR (255) “hasan@ethz.ch”
DSCP
ResultCode
TINYINT UNSIGNED
(Value 0 to 255)
INT UNSIGNED
(32 bit unsigned)
21
22
2
Globally unique identity of
the entity which creates the
log. Possible format:
:qosmanager
Creation timepoint of the
log
Globally unique identity of
the event:
21 for Service
Authorization Request and
22 for Service
Authorization Response
0 for Service
Authorization Request
Other values are for
Service Authorization
Response according to the
QoS Broker
implementation
Table 42: Service Authorization Table
4.5.6.5 Event Log Transfer
The transfer of the event logs stored in the Local Log to the central Audit Trail is carried out by the Local
Log Management and Central Log Management. An event can be conveniently represented as a set of
Attribute Value Pairs (AVPs).
OpenDiameter provides a library to generate and parse messages containing AVPs, which lead to the
decision of using this library. The message format will therefore be the same as all DIAMETER
messages. The main advantage of DIAMETER message format is the flexibility and extensibility. To
allow for correct interpretation of these new messages, new command codes and AVP codes are defined
for the transfer of Availability Event Logs, User Registration Event Logs, and Service Authorization
Event Logs. An attribute can be defined optional, so that a message needs not contain the corresponding
AVP, as in the case of User Registration Events, where the ResultCode is only relevant for Response
Events.
Log messages are transferred over TCP in a client/server fashion, where the Local Log Management can
be seen as a client that initiates a TCP connection upon startup, and the Central Log Management as a
server, which is waiting for new connections from the clients.
4.5.6.6 Audit Report
The Auditor is implemented in C++. A process is started for each type of commitment: Entity
Availability, Success of User Registration, and Success of Service Authorization. The result of the
violation detection process is written in a flat file. For each entity respectively customer, and each
commitment, a report file is generated. The report tells whether an entity is available during the predefined
interval in case of availability guarantee. In the case of guarantees on success of user registration
and service authorization, the report shows for a particular customer, whether the respective provider’s
commitment is fulfilled or not. A commitment violation is considered to happen, if no response has been
received or if negative response is received, which is caused by network generated errors.
An examp le report of the availability investigation of the QoS Manager in the Access Router
ksat72.ipv6.rus.uni-stuttgart.de for April 2003 looks like:
D0103v1.doc 139 / 168