Service Level Agreements: An Ontological ApproachLes Green

University of Technology, SydneyPO Box 123, Broadway, 2007

NSW, Australia

lesgreen@it.uts.edu.au

ABSTRACTThis paper describes an ontology based Service Level Agreementformalisation. OWL and SWRL are chosen to express theontologies. Use of the ontologies, discussing Ontology Adoption,SLA Instance Creation and Validation is given, followed by abreakdown and discussion of the concepts. Ontologies aregrouped by generality and diagrammatic representations aregiven. The SLA ontology is discussed in context of thetelecommunications domain.

Categories and Subject DescriptorsD.2.12 [Software Engineering]: Interoperability - Datamapping

General TermsManagement, Documentation, Experimentation, Standardization,Languages, Theory, Verification.

KeywordsService Level Agreements, Telecommunications, Ontology, OWL

1 INTRODUCTIONThroughout modern history, as business expanded, greaterreliance has been placed on formalisation of deals. Until the last100 years or so, this reliance has been assured mostly throughverbal agreements.

As business size, internationalisation, scope and interdependenceincreased, formal written contracts have replaced spoken word,increasing accountability and providing strict guidelines to thegoods and services to be provided. In a service industry, thesecontracts are Service Level Agreements (SLA).

SLAs have become the defacto agreements for the service sector.In the IT domain particularly, where outsourcing is the norm,these �e-business� contracts have become pivotal to conductingbusiness.

As the notion of �quality of experience� in service deliverybecomes better understood, service management must becomedynamic and have a fine grain of control to ensure efficient use of

resources. Service Level Agreements specifying services must beflexible to support these requirements.

This work has developed from a need to express Service LevelAgreements for the telecommunications domain in a machineunderstandable format. It is performed within a project to enableautomated negotiation of telecommunication services.

The need for automatically negotiated SLAs in thetelecommunications environment is driven by future delivery ofcomplex new generation services, and by the need to reconfigureservices quickly in response to changes in requirements.

The telecommunication domain is the focus within the latersections the paper and illustrates the refinement of the genericSLA specification to a target implementation domain.

1.1 DiagramsDiagrams are used throughout this report to illustrate theontologies. The diagrams are similar in semantics andappearance to E-R diagrams. Figure 1 Describes the layout of thediagrams used throughout this report.

Figure 1. Ontological Diagram Layout

In section 2, the formalisation method used for the SLAontologies is discussed. How these ontologies are then used toform a useful Service Level Agreement Solution is presented insection 3.

Sections 4,5 and 6 follow with an outline of the ontologyspecifications. First, in section 4 is a group of generic ontologies,including the base SLA specification, which are applicable to avariety of application domains. Following in section 5 is adiscussion of how the generic ontologies can be extended andcombined to form domain specific Service Level Agreements.Section 6 concludes the specifications with an example of how afinal Service Level Agreement may be implemented.

"Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies are notmade or distributed for profit or commercial advantage and that copies bearthis notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ICEC�06, August 14�16, 2006, Fredericton, Canada.Copyright 2006 ACM 1-59593-392-1.�

The paper concludes with a summary and discussion of futurework.

All ontologies discussed in this paper, along with an example areavailable in OWL format from:

http://qdine.it.uts.edu.au/ontologies

They can be viewed in any OWL editor, such as Protégé1

2 SLA FORMALISATIONConveying a common understanding of service levels across alarge, heterogeneous environment such as the Internet, requiresboth an abstract formalism for representation in order to supportdifferent underlying service provision implementations, and astandard syntax and common understanding for expressing thespecifics of an SLA.

The CADENUS project [1] describes Service Level Agreementsas a high level of abstraction for specifying service requirementswithin a service provision framework. Such a level of abstractionand subsequent implementation independence render SLAs anappropriate format for communicating service requirementsbetween heterogeneous service provision implementations.

Much work has been done in the field of syntacticinteroperability on the web. A popular solution is through the useof XML [2]. Authors have claimed that XML is a �silver bullet�[3] for future e-business integration and automation. Otherstudies have shown that this is only partially true [4], and foreffective integration, a semantically richer framework such asRDF[5] is required.

The use of XML and RDF effectively deals with therequirements of a common syntactic framework for SLAs;however RDF only goes part way towards expressing thesemantics or �understanding� of an SLA.

Previous research has outlined the main drivers to thespecification of ontologies for a specific domain [6]:

· To share common understanding of the structure ofinformation among people or software agents.

· To enable reuse of domain knowledge.

· To make domain assumptions explicit.

· To separate domain knowledge from the operationalknowledge.

· To analyze domain knowledge

These drivers align strongly with many requirements for an SLArepresentation. The use of a suitable ontological language, alongwith a common syntactical framework may therefore beemployed to address the requirements of SLA formalisation in aheterogeneous telecommunications environment.

2.1 Web Ontology Language (OWL)OWL [7] is an ontology language designed to work seamlesslywith XML and RDF and is rapidly gaining support andacceptance in the ontological research and business community.OWL is semantically rich and builds on RDF and RDFSchema[8] adding more vocabulary for describing properties andclasses: Among others, relations between classes (e.g.Disjointedness, inheritance), cardinality (e.g. "exactly one"),equality, richer typing of properties, characteristics of properties(e.g. symmetry), and enumerated classes.[7]

1 http://protege.stanford.edu/

OWL operates under and �open world� assumption. This meansno assumption can be made on anything that cannot be inferred,or put simply �if it's not stated, it doesn't mean it's not true�. TheOWL open world assumption has the following basic rules:

� New information cannot retract previous information.

� New information can be contradictory.

� Facts and entailments can only be added, never deleted.

These basic properties of OWL makes it extremely extensibleand a suitable candidate language for the expression of SLAs.

OWL as a language has three sub languages. OWL lite, OWL DLand OWL full. OWL Lite and DL maintain both computationalcompleteness and decidability, meaning all conclusions areguaranteed to be computable and will finish in finite time2.OWL-lite is geared primarily towards users needing only aclassification hierarchy and simple constraints. OWL full allowsmaximum expressiveness but may be undecidable and hencedifficult to reason over.

Service Level Agreements specified in OWL should allowmachine validation for use in automated systems. OWL DLallows such validation whilst remaining strongly expressive.

A major advantage to OWL is the fact that it is a selfdocumenting language. Metadata can be applied to classes,properties or entire ontologies describing further information forthese components.

2.2 Semantic Web Rule Language (SWRL)Within OWL ontologies, to ensure valid knowledgerepresentation, some rules, constraints and relationships need tobe maintained which OWL alone cannot sufficiently express. TheSemantic Web Rule Language (SWRL)[9] has been adopted toexpress rules and constraints. SWRL expresses rules throughhorn like implication and has an abstract syntax in addition to theconcrete syntax for use with OWL.

2.3 Towards an appropriate format Much work has been done by various sectors of the IT industrytowards service level representations. The approach used in thisproject extends the definition of a Service Level Specification(SLS) defined originally in the TEQUILA project [10].TEQUILA has been extended by MESCAL [11] to includeService Subscription Specifications (SSS).

Service Level Specifications define succinctly the requirementsof service level agreements for telecommunications. The ServiceSubscription Specification defined in [12] outlines a requirementto aggregate these one way service specifications into asubscription offering as well as including information about thesubscriber, the service schedule, availability and reliabilityguarantees, and how the services will be started and stopped.

Alcatel in recent years has made significant progress inspecifying the requirements of a Service Level AgreementManagement framework [13][14]. Advancements made in thatwork will be used to guide this project.

Other work by IBM [15][16] and HP Labs [17] towards SLAs forWeb Services is also significant.

3 ONTOLOGY USEOwl ontologies are infinitely extensible due to their open worldassumption and semantic relatability. To create a finite SLA

2 http://www.w3.org/TR/2004/REC-owl-features-20040210/

specification from such an expressive language, a mechanism torestrict the open view into a finite, closed specification isrequired.

In this section, the process of creating a final SLA instance fromone or more OWL ontologies is discussed.

The process involves adopting a set of ontologies for use,creating an SLA instance using the adopted ontologycomponents, then checking the consistency of the created SLAinstance.

3.1 Ontology AdoptionEntities wanting to use OWL based SLAs must first choose a setof ontologies which adequately describe the concepts to beexpressed in the SLA. These may be created new or may beexisting ontologies defined for re-use.

An SLA involves two or more parties to the agreement. In orderfor all parties to understand the agreement, they must jointly�adopt� a common set of ontologies.

The act of adopting an ontology states the adopter understandsthe syntax and semantic meaning of all components specified inthe ontology and accepts the use of such components in futureSLA instances.

The procedure for adopting an ontology and advertising theadoption is an implementation concern. Depending on the targetdomain, it may involve a knowledge engineer and applicationprogrammer, or simply a user to overlook the proposed ontologyin one of the widely available OWL editors such as Protégé1.

Within OWL, an ontology may import other ontologies. When anentity states the adoption of an ontology which has importedontologies, the imported ontologies are also assumed to beadopted.

Only adopted ontologies are certain to be understood by an entityparticipating in an SLA interaction. Therefore, SLA instancescreated must only include vocabulary from mutually adoptedontologies.

Automated systems participating in ontological SLA exchangesshould understand how to process every possible valid instanceof an SLA built from its adopted ontologies.

Below is an example, used to outline the concept of ontologyadoption:

� Customer A wishes to use a service provided by Provider B.

� Customer A has previously adopted ontologies P,S,U and X.

� Provider B has adopted ontologies O,P,U,V and X.

� To create a SLA between A and B, each party must discover

the other's adopted ontologies.

� A resulting SLA may only be expressed using common

ontologies P,U and X.

The method in which ontology discovery occurs is an importantissue but along with adoption technique is implementationspecific depending on the SLA application domain.

If no satisfactory SLA can be created from the shared ontologies,either party may choose to adopt another's ontologies or adifferent provider may be chosen.

The above adoption mechanism is the first step in refining a setof open OWL ontologies into a well defined SLA specification.Concepts for use on an SLA are effectively restricted to thoseavailable on commonly adopted ontologies.

Once an entity has adopted its ontologies and resolved a sharedset of ontologies for use in a particular SLA, it can create an SLAinstance.

3.2 SLA Instance CreationThe root element of all SLAs instantiated must be a descendantof the OWL class SLA. A common ontology which must be

adopted by all Service Level Agreements is therefore theSLAOntology.

Working from the root SLA element, an SLA is built by creatingand relating SLA components and sub components as they areinstantiated from their OWL classes. As the SLA is constructed,any OWL constraints and SWRL rules specified in the appliedontologies must be satisfied.

Only when all OWL constraints and SWRL rules are satisfied foran SLA instance, can it be regarded as complete.

For example, the SLA class from the SLAOntology has a

restriction defined on the hasConsumer property, stating it

must have exactly one Consumer instance. Only once a valid

Consumer instance has been assigned to the hasConsumerslot of an SLA instance, can that SLA instance be considered

complete.

3.3 SLA ValidationService Level Agreements function as a contract between partiesfor a given service. Usually an SLA will involve some form ofremuneration for the provision of a service. An invalid SLAcould open an SLA to repudiation, cancelling any obligation forprovider remuneration. SLAs should therefore be provably valid.

An SLA instance may be submitted to numerous validationmethods, performed by one or more SLA participants before theSLA is agreed to.

Validation of an SLA occurs in many stages.

First, an ontology should be consistent. Consistency checkingensures that an ontology does not contain any contradictory facts.Ontologies used in specifying an SLA should also be satisfiable.Defining an instance in an unsatisfiable class will cause theontology to be in an inconsistent state.

Consistency of an ontology, or combination of ontologies can bechecked with a consistency checker, commonly implemented as acomponent of knowledge reasoners. Many reasoners areavailable for OWL, with some such as Hoolet3 beginning to offersupport for SWRL rule sets.

Second, an SLA instance should be syntactically correct andsatisfy all appropriate ontology constraints. OWL syntax andconstraint validators are openly available such as thevOWLidator4.

4 THE GENERIC ONTOLOGIESGeneric ontologies are designed to provide a framework forbuilding service level agreements. They are an open set ofspecifications, each providing a definition for certain concepts inthe SLA domain. However, they are designed to be generic andmay be used satisfactorily in any other knowledge domain.

Each of the generic ontologies can be viewed as a lego block;meant for use as a component in a larger specification. They

3 http://owl.man.ac.uk/hoolet/

4 http://owl.bbn.com/validator/

outline what can be done but are not meant to be an exhaustivelist of possibilities.

4.1 Unit OntologyService Level Agreements by definition are an agreement on aparticular level of service. To evaluate a level of service,comparisons should be made between the real world value of aproperty to a target value. I.e. We must be able to compare thingson an SLA. The Unit ontology is designed to formalise any thingthat is comparable, along with the operations that may beperformed on such things. Figure 2 Describes the classes andrelationships in the Unit Ontology.

4.1.1 Unit ClassA unit is simply ANY COMPARABLE THING. It is definedby the unit ontology as any particular unit of measure. Everyclass of a unit can be thought of as either an attribute describing

an object in the world, or a type of object in its pure sense. Everyinstance of a unit class can be seen as a particular value of anattribute, or a particular instance of an object.

Units are divided into two distinct subclasses; continuous or

discreet.

Continuous units all have a slot for a float value and can beeither primitive or derived from a different unit. Examples ofprimitive and derived units are second and minute respectively.Every derived unit must have the hasDerivation attribute

populated with an SWRL rule defining the relationship from thederived unit to another unit.

Discreet units have a property hasInstance which must be an

IdentifyingDiscreetUnit.

An IdentifyingDiscreetUnit instance is a self

referring unit, used as a discreet value of a discreet unit.

Figure 2. Unit Ontology

Each of the subclasses classes of the DiscreetUnit class

from which instances are created should have thehasInstance slot restricted by an AllFrom restriction,

listing all possible instances allowed for that slot in that class.

4.1.2 Comparator ClassEvery unit must be comparable with at least one comparator.They are assigned to a unit through the canBeComparedWithproperty of the Unit class.

4.1.3 Comparison ClassComparisons are instances of an operation over one or more unitsusing a Comparator. The result can either be true or false.

Three distinct subclasses of unit comparisons are: setcomparisons operating over sets of units, unary tests over oneunit or binary comparisons between exactly two units.

If both domain and range in a binary comparison are the sameclass, it is said to be a monoTypeBinaryUnitComparison,

if the units involved are of different classes, the comparison is amultiTypeBinaryUnitComparison.

A multi type binary comparison is said to be areducibleMultiTypeBinaryUnitComparison if and

only if the domain and range are both Continuous units, at

least one is a DerivedUnit, and the units are reducible to a

common class through the hasDerivation attribute.

An example of a validreducibleMultiTypeBinaryUnitComparison is a

comparison between Second and Minute.

Every comparison must use a comparator that is appropriate tothe objects being compared. This integrity constraint is expressedthrough SWRL in Formula 1.

Formula 1: Comparison Validation

4.2 Time Unit OntologyThe time unit ontology is an extension to the unit ontology in thespecific domain of temporal units. Most time units arecontinuous, with the exception of MonthOfYear; a discreet

unit comprising instances of the 12 months of the year.

The comparators Occurs and IsActive are defined in the

time unit ontology, so when an Event or Interval from the

Temporal Ontology (below) is instantiated also as a Unit, it canbe compared with those operators without them needing to be re-defined for every such use. Figure 3 describes the time unitontology.

Comparison �C � �Comparator �O� �Unit �U ��hasComparator�C ,O� � hasDomain �C , U �

� canBeComparedWith �U , O�

4.3 Temporal OntologyThe temporal ontology is an ontology designed to describe theconcepts related to instantaneous occurrences (The Eventclass) and continuums punctuated by two such events (The

Interval Class).

4.3.1 Event ClassThe Event class is designed to be a generic class, subclassed as

required by foreign ontologies to fit a desired purpose. Manythings can be an event, such as the receipt of an email or aspecific date and/or time.

A common property of all events is that they may have actionsassociated which are triggered when the event occurs. All eventsmay also have restrictions which only allow the event to occurWHILE the restrictions hold. I.e. Are true.

Although the DateTimeEvent class describes a specific event

type, it is included in the generic Temporal Ontology as it ties in

with the temporal concepts as a whole. A DateTimeEventoccurs whenever the minute, second, day of month, month, year,day of year, day of week and week of year occur. SWRL rules arein place to ensure valid numeric ranges for attributes. Forexample, if the month specified is Jan, Mar etc, the maximumvalue for the hasDays attribute is 31, if Feb then the maximum

is 29. Formulae 2 and 3 below illustrate restrictions on numericranges.

DateTimeEvent � e � � hasMinute � e , m�� greaterThanOrEqual �m, 0�

Formula 2: hasMinute lower bound

DateTimeEvent�e� � hasMinute �e , m� � lessThan �m , 60�Formula 3: hasMinute upper bound

See Figure 4 for a diagram of the temporal ontology.

Figure 3. Time Unit Ontology

Figure 4. Temporal Ontology

4.4 Currency OntologyThe currency ontology describes the currencies of the world andthe relationships between the different units of currency. Everycurrency is a subclass of unit:ContinuousUnit. SWRL is

used in the currency ontology to express the mathematicalrelationship between different units of the same currency.

Formula 4 Illustrates the relationship between an Australian

Dollar and Australian Cent, Where sameAs�c , d � means c

and d are the same object instance and

multiply �cv , dv , 100� means cv=dv�100 .

AustralianDollar �d� � AustralianCent�c� �hasFloatValue�d , dv � � hasFloatValue �c , cv � �

sameAs�c, d � � multiply �cv , dv ,100�Formula 4: Australian Cent derivation

Similarly, the derivation of EuroCent from Euro is defined in

Formula 5. Figure 5 describes the currency ontology.

Euro �e� � EuroCent �c� � hasFloatValue�e , ev � �hasFloatValue�c , cv � � sameAs �c , e�

� multiply �cv , ev ,100�Formula 5: Euro Cent derivation

Figure 5. Currency Ontology

4.5 Network Metrics OntologyThe network metrics ontology is concerned with units related totelecommunications networks and ensuring such units can bemeasured when required. Refer to Figure 7 for the ontologydiagram.

4.5.1 Network Unit ClassNetwork units express comparable things specific to thetelecommunications domain, such as network traffic volume andthroughput as well as other quality of service parameters.

Units in the network metrics ontology are all children of theSimpleUnit class in the unit ontology. Derived units are

defined through their hasDerivation property. Formula 6

below shows the SWRL derivation for the Kibibyte value.

Formula 6: KibiByte derivation

Two Example Network Units are described below.

1. Per Flow Sequence Preservation ensures packets transit thenetwork in their original sequence. This parameter isimportant for jitter sensitive traffic where an out of sequencepacket may cause a large delay in transmission. One sourceof out of sequence packets is load balancing at the packetlevel and not at the flow level. This attribute of a networkpath is conveyed by the boolean discreet unitSequentialPackets. The instance value of this unit

must be one of True or False, as restricted in the parent

class BooleanDiscreetUnit.

2. Availability can be specified at many levels including thenetwork access level and the service provision level.Availability is a continuous networking unit specified as apercentage and represented by the Availability Unit in

the Network Metrics ontology.

4.5.2 Metric ClassTo obtain a current real world value of a particular networkingunit, the unit must have defined for it some method of obtainingsuch real world measurement. The Metric class is a special

type of unit where a measurement model is defined to specifyhow the real life value of the metric is collected and by whom.On instantiation, any Unit may also be instantiated as a

Metric and have a measurement model defined.

4.5.3 Performance Level ClassA performance level is a certain type of comparison whereby thereal world value of a Metric is compared with a target value.

Table 1 Shows an example use of Metrics in a performance level.

Table 1: Performance Level Usage

Metric Unit Class MetricInstance

Operator MetricInstance

value

BitsPerSecond �SLSThroughput�

GreaterThan3

Byte�b� � KibiByte �kb� � hasFloatValue �b ,bv � �hasFloatValue �kb , kbv � � sameAs �b , kb�

� divide �kbv , bv ,1024�

The above performance level states that the �SLS Throughput�metric, which is of type BitsPerSecond has a real world

value greater than 3.

4.6 SLA OntologyThe SLA ontology is very generic, specifying only the bareminimum requirements for an SLA. It is designed to besubclassed for particular domains, adding more slots if required,and restricting the implemented slots into specific classes. Itimports no other ontologies in order to maintain highly decoupledfrom unrelated concepts.

4.6.1 SLA ClassThe SLA Class specifies the customer on the SLA, anysupporting entities to the SLA (not the provider), a period ofvalidity for the entire SLA and one or more obligations which arewhere the details of the services provided on the SLA arespecified.

4.6.2 Service Obligation ClassService obligations describe a single service obligation on anSLA. The ServiceObligation class is very generic,

including concepts which should be applicable to all service levelagreements. A Service Obligation must specify a provider for theservice, a schedule for the service, and a Service Specificationwhich fully describes the service to be provided.

Due to the generality of the base class, a service obligationshould be further restricted before use. This can be done throughany of the restricting methods available in OWL and SWRL,such as subclassing, adding properties to classes or restrictionson existing properties, or applying rules to components.

An identified extension which may not be applicable to allservice obligations, so was not included in the base specificationis the requirement of obligation dependence. A service obligationmay logically depend on fulfillment of different obligation inorder to be complete in its self. For example, an obligation onbehalf of a video service provider to deliver a streaming videoapplication may depend on a particular network SLA obligationto provide data transport.

Figure 6: SLA Ontology

Figure 7: Network Metrics Ontology

5 THE QDINE ONTOLOGIESThe SLA Ontology was developed as part of a larger projectnamed �Managing Quality of experience Delivery In Newgeneration telecommunication networks with E-negotiation�

(QDINE)[18]. Within the QDINE project, service levelagreements specific to the telecommunication domain arenegotiated automatically by electronic agents.

The QDINE Ontologies are an example of how the genericontologies are combined and extended to form a set of domainspecific ontologies. These ontologies should approach a �closedworld view�, restricting a user of an ontology to particularclasses or instances that �make sense�. An example for �notmaking sense� would be using a newly defined unary comparator�ispink� or similar on an event instance. This does not �makesense� in the telecommunications context.

The constraints required to move towards the �closed worldview� can be enforced in OWL through the use of restrictions onclasses and properties, as well as SWRL rules.

To ensure logical use of an ontology, many classes receivecovering axioms which restrict possible subclasses to a finite list.Additionally, instances of classes may be restricted to one of alist of enumerated values as in Formula 7.

Formula 7: Comparator Type Restriction

5.1 QDINE SLA OntologyThe QDINE SLA ontology subclasses both classes of the genericSLA ontology, additionally it applies many restrictions on theclass properties.

In the QDINE_SLA class, a restriction is applied on the

hasValidity property, limiting it to the Interval class

from the Temporal Ontology. This is an example of how genericclasses can be combined to for a stronger, specific SLAdescription. Additionally, the hasObligations property is

restricted to instances of the QDINE_ServiceObligationclass.

The QDINE_ServiceObligation class also has restrictions

placed on the properties inherited from its parent in the genericSLA ontology. The hasViolation property is restricted to

instances of the ViolationModel class from the QDINE

Violation Ontology.

This last restriction illustrates how a generic ontology can beextended by relation through restriction to a domain specificontology.

Figure 8: QDINE SLA Ontology

5.2 QDINE Charging OntologyNo particular charging model is specified for the QDINE project,allowing support of multiple charging models, and the decisionfor each SLA charging model to be decided as required.Accordingly, no restriction is made on thehasChargingModel property of the QDINE_Obligationclass to be of a particular type.

An example event based charging model has been defined for usein the QDINE project for solution completeness. Event basedcharging is well suited to the current trend in charging fortelecommunication services.

One benefit of using an event based approach is the fact thatService Violations can be treated as an event, so can be used totrigger a (possibly negative) charge.

Figure 9: QDINE Charging Ontology

5.3 QDINE Entity OntologyThe QDINE Entity ontology was created as a stub ontology witha set of classes for completeness. Any ontology describing a partyto an SLA may be used. Figure 10 outlines the QDINE EntityOntology.

5.4 QDINE Violation OntologyThe QDINE Violation Ontology specifies specifics relating toviolations of the obligation. Each violation model may have oneor more violation events, triggered when the performance levelspecified within the violation event becomes false. See Figure 11for the QDINE Violation Ontology diagram.

5.5 TEQUILA SLS OntologyThe OWL representation of the TEQUILA Service LevelSpecification was derived from work done by the TEQUILA[10]and MESCAL[11] projects. Specifically the from MESCALspecification of protocols document[12].

The TEQUILA SLS describes network level telecommunicationservices, designed to work with Differentiated Services(Diffserv)[19].

Outlines the TEQUILA SLS Ontology.

6 SLA IMPLEMENTATIONService providers will want to restrict service level agreementsinto a specific form for use by their customers, leaving onlyminimum variations available appropriate to end user serviceofferings. This may be done with further restriction of theontology classes and through the definition of predefined ServiceLevel Agreement template classes.

The telkstra ontology5 places a restriction on thehasChargingModel slot of a

QDINE_ServiceObligation to the

QDINE_ChargingModel and restricts the

hasServiceSpecification slot on a

QDINE_ServiceObligation to the TEQUILA_SLS.

SLA template classes are classes with restrictions placed on eachof the slots, constraining the slots to particular predefinedinstances.

5 http://qdine.it.uts.edu.au/ontologies/telkstra.owl

Comparator � unit :BinaryComparator

� unit : SetComparator

�unit :UnaryComparator

For example, if a service provider has a standard service offeringwhere the details of the service specification are the same forevery customer, apart from a few values such as �activationdate�, then the provider can instantiate an SLA with all therequired values as a template, leaving blank the values whichchange from customer to customer, in this case, the �activationdate�.

Such an SLA template greatly reduces the amount of trafficpassed across the network per SLA, as only the values which areempty need to be transferred to complete an SLA per customer.

From Figure 12, it can be seen that all the specifics of the SLAare hidden and only the details of concern are exposed. Due tothe semantic strength of OWL, every detail of the SLA can beexplored if required.

Figure 10: QDINE Entity Ontology

Figure 11: QDINE Violation Ontology

Figure 12: Example SLA Instance

ViolationModel

hasViolations: ViolationEvent = multiplehasViolationsN N

ViolationEvent

hasViolationCondition: networkMetrics#PerformanceLevel = single

(#hasViolationCondition=1)

Temporal: Event

networkMetrics: PerformanceLevel

hasViolationCondition

N

1

<?xml version="1.0" ?><!DOCTYPE rdf:RDF[

<!ENTITY sladir "http://qdine.it.uts.edu.au/ontologies/"><!ENTITY telkstra "&sladir;telkstra.owl#"><!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#"><!ENTITY billing "&sladir;billingProviderCustomerDatabase.owl#"><!ENTITY owl "http://www.w3.org/2002/07/owl#">

]><rdf:RDF

xmlns:telkstra="&telkstra;"xmlns:owl="&owl;"xmlns:sla="&sladir;SLAOntology.owl#"xmlns:unit="&sladir;UnitOntology.owl#"xml:base="telkstra;">

<owl:Ontology rdf:about=""><owl:imports rdf:resource="&telkstra"/>

</owl:Ontology>

<telkstra:Telkstra_SLA_2up2down_connectionless_agreement rdf:ID="lesgreencontract">

<sla:hasConsumer rdf:resource="&billing;LesGreen001"/></telkstra:Telkstra_SLA_2up2down_connectionless_agreement>

<rdf:Description rdf:about="&telkstra;repeating_charge_price"><unit:hasFloatValue rdf:datatype="&xsd;float"> 45.0 </unit:hasFloatValue>

</rdf:Description>

<rdf:Description rdf:about="telkstra;outbound_connectionless_obligation"><sla:hasProvider rdf:resource="&telkstra;self"/>

</rdf:Description></rdf:RDF>

7 CONCLUSIONS AND FUTURE WORKA set of ontologies, specified in a concrete XML constructs, builtfrom OWL and SWRL and illustrated diagrammatically ispresented.

The ontologies fit together to form an extensible, comprehensiveapproach to specifying Service Level Agreements generally, andmore specifically in the Telecommunications domain.

Testing on the usability of the ontologies through mapping themonto real world service level agreements has begun. InitialResults are promising, but further work is planned.

The group of generic ontologies in the project have proven to besound through instantiation of numerous and varying Service

Level Agreements. The QDINE, domain specific ontologies haveundergone minimal throughout testing to date.

An interesting component of this research is theexpression of units as a comparable and measurable thing,relatable to real world values.

This research is performed as part of an AustralianResearch Council Linkage Grant, LP0560935 betweenAlcatel and the University of Technology, Sydney. Itextends work already performed on the Negotiation ofService Level Agreements for New Generation Networks,performed as part of the Alcatel Research PartnershipProgram (ARPP).

8 REFERENCES[1] Creation and Deployment of End-User Services in PremiumIP Networks, Source: http://www.cadenus.fokus.fraunhofer.de/,Accessed: 26 November 2004

[2] Extensible Markup Language (XML), Source:http://www.w3c.org/XML/, Accessed: 26 Nov 2004

[3] Lee, J.J. & Natan, R.B. �Integrating Service LevelAgreements�, Wiley Publishing, Inc., 2002, pp 44-55

[4] Decker, S. et al., 2000, The Semantic Web: The Roles of XMLand RDF, IEEE Internet Computing, vol. 4, num. 5, pp. 63-74

[5] Resource Description Framework (RDF), Source:http://www.w3c.org/RDF/, Accessed: 26 Nov 2004

[6] Noy, N. F. & McGuinness, D. L., 2001, �OntologyDevelopment 101: A Guide to Creating Your First Ontology�,Stanford Knowledge Systems Laboratory, KSL-01

[7] OWL Web Ontology Language, Source:http://www.w3.org/TR/2004/REC-owl-guide-20040210/,Accessed: 26 Nov 2004

[8] RDF Vocabulary Description Language 1.0: RDF Schema,Source: http://www.w3.org/TR/rdf-schema/, Accessed: 26 Nov2004

[9] Semantic Web Rule Language (SWRL), Source:http://www.w3.org/Submission/SWRL/, Accessed: 02/02/2006

[10] Traffic Engineering for Quality of Service in the Internet, atLarge Scale, Source: http://www.ist-tequila.org/, Accessed: 26Nov 2004

[11] Management of End-to-end Quality of Service Across theInternet at Large, Source: http://www.mescal.org/, Accessed: 26Nov 2004

[12] MESCAL Deliverable 1.2, �Initial specification ofprotocols and algorithms for inter-domain SLS management andtraffic engineering for QoS-based IP service delivery and theirtest requirements�, 2004, Source:http://www.mescal.org/deliverables/MESCAL-D12-public-final.pdf

[13] Betge-Brezetz et al., 2002, Pro-Active SLA Assurance forNext Generation Network, World Telecommunication Congress(WTC2002), Paris, France

[14] Marilly et al., 2002, Requirements For Service LevelAgreement Management, Proceedings of the IEEE Workshop onIP Operations and Management (IPOM 2002), Dallas, TexasUSA

[15] Web Service Level Agreements (WSLA), Source:http://www.research.ibm.com/wsla/, Accessed: 26 Nov 2004

[16] Dan, A., Ludwig, H. & Pacifici, G., 2003, �Web ServicesDifferentiation with Service Level Agreements�, Tech Report,IBM Corp,

[17] Sahai, A., Durante, A., & Machiraju, V., 2002, �TowardsAutomated SLA Management for Web Services�, HP LaboratoriesPalo Alto,

[18] Managing Quality of experience Delivery In New generationtelecommunication networks with E-negotiation (QDINE),Source: http://qdine.it.uts.edu.au, Accessed: 02/04/2006

[19] Differentiated Services (Diffserv) charter, Source:http://www.ietf.org/html.charters/diffserv-charter.html,Accessed: 26 Nov 2004