Moby Dick Consolidated System Integration Plan
Moby Dick Consolidated System Integration Plan
Moby Dick Consolidated System Integration Plan
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
D0103v1.doc Version 1 6.7.2003<br />
4.5.6 Auditing<br />
Auditing objectives need to be determined in advance in order to be able to specify the auditing and<br />
logging requirements. Auditing requirements determine what tasks to be accomplished to meet the<br />
auditing objectives, whereas logging requirements determine which events need to be logged by whom<br />
and when. The auditing objective of <strong>Moby</strong><strong>Dick</strong> is to detect violation of Service Level Guarantees (SLGs)<br />
between a customer and a provider. An SLG is the part of Service Level Agreement (SLA) which<br />
specifies a provider’s commitment on quality level of services it will deliver.<br />
Furthermore it is assumed that <strong>Moby</strong><strong>Dick</strong> auditing objectives do NOT include following goals:<br />
• Detection of security breaches<br />
• Detection of failure in design and implementation of <strong>Moby</strong><strong>Dick</strong> entities<br />
• Detection of AAAC’s policies violation. AAAC policies represent the provider’s policies in<br />
determining the behavior of AAAC entities in performing authentication, authorization,<br />
accounting, and charging.<br />
It is important to note here, that security breaches, failure in design and/or implementation, and policies<br />
violation may lead to SLG violation.<br />
4.5.6.1 <strong>Moby</strong><strong>Dick</strong> SLG<br />
A <strong>Moby</strong><strong>Dick</strong> Service Level Agreement (SLA) reflects the contract between a customer and <strong>Moby</strong><strong>Dick</strong><br />
service provider. This section does not describe the whole detail of SLA, but only the guarantees<br />
specified within an SLA, termed SLG.<br />
Three commitments are specified within <strong>Moby</strong> <strong>Dick</strong>:<br />
? Entity Availability<br />
? Success of User Registration<br />
? Success of Service Authorization<br />
Entity Availability defines the guaranteed availability of <strong>Moby</strong> <strong>Dick</strong> key entities (in particular AAAC<br />
Clients and QoS Managers) in unit of time or in percentage within each period of a pre-defined length.<br />
The usual period is a calendar month or a billing period.<br />
Success of User Registration defines the guaranteed successful of a valid registration request with a valid<br />
NAI and credentials within minute, at least after retries of ‘approximately uniform’ interval, if<br />
the user is currently in the home domain.<br />
Success of Service Authorization defines the guaranteed acceptance of a valid service request from a<br />
registered home user within minutes, at least after retries of ‘approximately uniform’ interval. In<br />
<strong>Moby</strong> <strong>Dick</strong>, services offered to customers are network transport services. These services enable IPv6<br />
packets to be transported with a certain QoS within the operator network. The QoS parameters in <strong>Moby</strong><br />
<strong>Dick</strong> are restricted to bandwidth and a priority number. The network transport services are characterized<br />
by any combination of the CoA/HomeAddr, DestAddr, and DSCP. A particular service in <strong>Moby</strong> <strong>Dick</strong> is<br />
implicitly requested with the arrival of the first packet marked with the corresponding DSCP.<br />
Different situations and conditions can lead to violations of the abovementioned commitments:<br />
? Implementation errors of one or more of the involving entities.<br />
? Configuration errors of one or more of the involving entities.<br />
? Data communication errors.<br />
? The respective entities are compromised.<br />
? The database which holds the required information e.g., user profile, is corrupted.<br />
? Network is overloaded<br />
The entity unavailability does not include unavailability due to:<br />
? scheduled maintenance<br />
? failures of users’ own devices and/or applications<br />
? force majeure<br />
D0103v1.doc 135 / 168