Elsevier Editorial System(tm) for Expert Systems With Applications Manuscript Draft Manuscript Number: Title: An Ontology for Managing Network Services Quality Article Type: Full Length Article Keywords: Ontology; Multiservice IP Networks; Network Service Management; SLA/SLS; Semantics Corresponding Author: Prof. Paulo Carvalho, Ph.D. Corresponding Author's Institution: University of Minho First Author: Carlos Rodrigues, MSc Order of Authors: Carlos Rodrigues, MSc; Solange Rito Lima, Ph.D.; Luis Alvarez Sabucedo, Ph.D.; Paulo Carvalho, Ph.D. Highlights "An Ontology for Managing Network Services Quality" (Full length article) > Managing Internet services and resources urges for a formal and systematic approach. > Semantic description of network services fosters interoperability and self- management. > We propose an ontological model for multiservice IP networks. > Dynamic negotiation and auditing of network service contracts are improved. > An API is provided to allow service management platforms to access ontological contents. Highlights An Ontology for Managing Network Services Quality Carlos Rodrigues Department of Informatics, University of Minho Solange Rito Lima Department of Informatics, University of Minho Luis M. Álvarez Sabucedo Telematic Engineering Department, University of Vigo Paulo Carvalho Department of Informatics, University of Minho Preprint submitted to Expert Systems with Applications April 7, 2011 *Manuscript Click here to view linked References http://ees.elsevier.com/eswa/viewRCResults.aspx?pdf=1&docID=12406&rev=0&fileID=118483&msid={83070562-258D-42A8-8D62-36F27A54CEA1} An Ontology for Managing Network Services Quality Carlos Rodrigues Department of Informatics, University of Minho Solange Rito Lima Department of Informatics, University of Minho Luis M. Álvarez Sabucedo Telematic Engineering Department, University of Vigo Paulo Carvalho Department of Informatics, University of Minho Abstract The evolution of IP networks to a service-oriented paradigm poses new challenges to service providers regarding the management and auditing of network services. The road toward ubiquity, heterogeneity and virtualization of network services and resources urges for a formal and systematic approach to network management tasks. In this context, the semantic characterization and modeling of services provided to users assumes an essential role in fostering autonomic service management, service negotiation and configuration. The semantic and formal description of services and resources is also relevant to assist paradigms such as cloud computing, where a large diversity of resources have to be described and managed in a highly dynamic way. This paper is centered on the definition of an ontology for multiservice IP networks which intends to address multiple service management goals, namely: (i) to foster client and service provider interoperability; (ii) to man- age network service contracts, facilitating the dynamic negotiation between clients and ISPs; (iii) to access and query SLA/SLSs data on a individual or aggregated basis to assist service provisioning in the network; and (iv) to sus- tain service monitoring and auditing. In order to take full advantage of the proposed semantic model, a service model API is provided to allow service Preprint submitted to Expert Systems with Applications April 7, 2011 management platforms to access the ontological contents. This ontological development also takes advantage of SWRL to discover new knowledge, en- riching the possibilities of systems described using this support. Keywords: Ontology, Multiservice IP Networks, Network Service Management, SLA/SLS, Semantics 1. Introduction The evolution of the Internet as a convergent communication infrastruc- ture supporting a wide variety of applications and services poses new chal- lenges and needs to network management, which has to be more focused on managing services instead of network equipment. This approach requires the capability of viewing the network as a large distributed system, offering an encompassing set of services to users. Commonly, the type of service, its Quality of Service (QoS) requirements and other technical and administrative issues are settled between customers and Internet Service Providers (ISPs) through the establishment of Service Level Agreements (SLA). The technological component of this agreement is defined through Service Level Specifications (SLS). SLSs provide a valuable guidance to service deployment on network infrastructures and monitoring of contracts’ compliance. Attending to the ever growing number of home and business customers, contracted services and network heterogeneity, the implementation and management of network services are very demanding tasks for ISPs. Besides the inherent complexity, this process may lead to inefficient policy implementation and poor resource management. In fact, under the current variety of services offered, e.g. IP telephony, 3-play or 4-play solutions, the interaction between service providers and end customers is rigid and rather limitative regarding service negotiation and auditing tasks. For instance, from a user point-of-view, the possibility of a short-term upgrade on his access bandwidth to the Internet or a tight quality control of the subscribed service would be of undeniable relevance. From a service provider perspective, providing this sort of facilities, would clearly improve the level of service being offered, increasing competitiveness and resource management efficiency. These aspects are impelling ISPs to pursue autonomic solutions for service negotiation, configuration and management. Although several proposals exist in the literature toward achieving dy- namic service negotiation and management (D’Arienzo et al., 2004; Sarangan 3 and Chen, 2006; Cheng et al., 2008; Zaheer et al., 2010), the lack of a strong formal ground in addressing these tasks is evident and overcoming it is essen- tial (Atkinson and Floyd, 2004). A formal specification of network services management semantics is required as the building blocks to create reasoning mechanisms to allow developing self-managed ISPs. By using a knowledge based formal framework and an inference engine capable of reasoning over concepts, relations and changes of state, it is possible to create a more flexible and robust ground for specifying and implementing autonomic and adaptive management tasks. As a contribution in this context, this work proposes an ontology speci- fication in the domain of multiservice networks, which formally specifies the contractual and technical contents of SLAs, the network service management processes and their orchestration, promoting service autonomic management and configuration. This model provides support for a Service Management Platform that facilitates client and service provider interoperability, service contracts management including service data querying by the provider and, at some levels, by the client. This is enabled through a developed Service- Model API, which allows the applicational use of the proposed ontology. The multiservice network semantic model is developed in Web Ontology Language (OWL), assisted by the Protégé-OWL tool. The use of Seman- tic Web technologies enhances service management modeling expansiveness and reusability. This paper is structured as follows: research work on ontologies related to service definition and QoS is debated in Section 2; the developed model and each of its modules are presented in Section 3; the way semantics are applied based on the developed API is discussed in Section 4; examples of practical usage of the proposed model are provided in Section 5; the conclusions and future work are included in Section 6. 2. Related work Ontologies are being commonly used to bring semantics to the World- Wide Web (WWW). The WWW Consortium (W3C) developed the Resource Description Framework (RDF) (Brickley and Guha, 1999), a language for encoding knowledge on Web pages to make it understandable to electronic agents searching for information. The Defense Advanced Research Projects Agency (DARPA), in conjunction with the W3C, developed DARPA Agent Markup Language (DAML) by extending RDF with more expressive con- 4 structs aimed at facilitating agent interaction on the Web (Hendler and McGuinness, 2000). More recently, the W3C Web Ontology Working Group developed OWL (Web Ontology Language) (Bechhofer et al., 2004) based on description logic, maintaining as much compatibility as possible with the existing languages, including RDF and DAML. In the context of this work, several research studies focusing on ontologies for network services support and QoS are found within the research commu- nity. QoSOnt (Dobson et al., 2005) is an OWL ontology that centers on com- parative QoS metrics and requirements definition. For the purpose of us- ability and extensibility, the ontology is divided into different layers: the base layer, the domain usage layer, the attribute layer and the units layer. This structure allows replacing layers according to user needs. Although this ontology supplies the correct semantics for matchmaking, this was never demonstrated due to datatype limitations in OWL 1.0. To overcome this problem, a pure XML based solution was used, losing all of the virtues of OWL (Dobson and Sanchez-Macian, 2006). DAML-QoS (Zhou et al., 2004) is a QoS metrics ontology for Web Services (WS) developed in DAML+ OIL, with the aim of integrating the DAML-S framework (which evolved to OWL-S). The ontology is divided in three lay- ers: QoSProfile Layer, QoS Property Definition Layer and QoS Metrics Layer. The applicational scenario is defined in the QoSProfile, where customer in- quiring, QoS advertisement and templates’ definition can take place. The QoS properties domain rules are defined in the QoS Property Layer. The range of domain properties classes are defined in the QoS Metrics Layer. In (Zhou et al., 2005) a new Service Level Objective (SLO) concept, met- rics’ monitoring and statistical calculation semantics are presented. Through comparing SLOs, it is possible to infer that the initial WS performance ob- jectives are being met. For matchmaking bound restrictions, it is used the cardinality constraint of the ontology. The use of cardinality to express bounds upon QoS metrics is a misuse of ontology construction (Dobson and Sanchez-Macian, 2006). The second problem pointed to this model is the inexistent relation between the metrics definition and what they measure (Dobson and Sanchez-Macian, 2006) (Prudencio et al., 2009). MOQ (Kim et al., 2007) is another proposal of a QoS semantics model for WS, but it is not exactly an ontology. It only specifies axioms and does not present a taxonomy structure or a dictionary of concepts. This proposal covers in depth the concepts of composite requirements and service trace- 5 ability. It is divided into requirements ontology, measurement ontology and traceability ontology. The use of axioms allows requirement matching, re- quirement complexity identification, requirements compliance (through the establishment of conformance points) and service activities traceability. MonONTO (Moraes et al., 2008) ontology aims at creating a knowledge base to support a client recommendation system. The ontology serves as a support to a decision recommendation tool by providing high-level infor- mation to the user about the compliance of the network facing the service level demands. This process is primarily accomplished through the match- making of NetworkCharacteristics against ServiceCharacteristics individuals. These individuals are essentially concepts of QoS metrics. Some of the Net- workCharacteristics individuals relates to MeasurementTool individuals for monitoring tools conceptualization. This ontology was designed using OWL and SWRL (Semantic Web Rule Language). In (Alípio et al., 2006), it is proposed an ontology which aims at the au- tomation of network services management and mapping of services’ require- ments into the network. The ontology is viewed from three perspectives: the network service classification, the service level specification, the deploy- ment of network services. The network service categorization and the service level specification concepts follow (Babiarz et al., 2006) and Tequila (Goderis et al., 2003) guidelines. This ontology was developed in Flora-2 (based on F-Logic and Transaction Logic frameworks). Although being a more power- ful language, F-Logic lacks the interoperability and reusability of Semantic Web languages such as OWL. A group of generic ontologies to provide a framework for building SLAs is presented in (Green, 2006). The Unit Ontology contains all the comparable elements on SLA, with the intention of supporting the creation of any type of measurable unit. It also allows the definition of unit supported comparators and the creation of comparison operations. The other examples of avail- able ontologies are: the Temporal Ontology for temporal occurrences such as events and intervals; The Network Units Ontology for units related to telecommunications networks; and the SLA Ontology for basic SLA specifi- cation. Therefore, rather than a QoS ontology, it is proposed a set of reusable ontologies for providing support for other QoS semantic model implementa- tions. In (Royer et al., 2008), it is proposed an SLA ontology covering essentially Authentication, Authoring and Accounting (AAA) issues. It is applied a Profile-based solution, where the authorization for service use is dictated by 6 the user profile. A set of user profiles of a Customer entity are mapped into a set of SLAs. A user profile can be constrained to a defined SLS. For scalability reasons, users with the same user profile are settled into groups. There is also the notion of differentiated SLS and quantitative or qualitative type of metrics. Expressed through OWL, this ontology deepens the concepts of QoS Control Admission, which are not addressed by most of other QoS ontologies. The OWL developed ontology NetQoSOnt (Prudencio et al., 2009) in- tends mainly to be the support of a reasoning tool for service requirements matchmaking. It promotes the definition of SLSs containing quality param- eters that belong to the following levels: the Quality of Experience, the Quality in the Application Level, the Quality in the Network Level and the Quality in the Link Level. NetQoSOnt presents the concept of Layer and a separate module is created for each Layer defined. The layered structure of NetQoSOnt emulates the TCP/IP stack. A Base Module provides the skele- ton for layer creation. For QoS specification units, it is used the Measurement Units Ontology (MUO), a units specialized ontology. In the proposals discussed above, the lack of an unified and encompass- ing approach for semantic modeling of services and corresponding contracts in a multiservice environment is clear. In fact, most of the proposals are more focused on specification of network services metrics than on integrated service management. As mentioned, the focus is mainly on aspects such as: (i) the specification and characteristics of metrics; (ii) the process of met- ric compression and matchmaking; and (iii) description of services through metrics. In the present work, a holistic model for modeling multiservice networks is provided paying special attention to the characterization and auditing of services quality. This ontology focuses on service contracts to assist network services’ implementation by specifying how the defined contract elements are deployed in the network infrastructure, a feature not considered in the re- viewed works. Thus, the present ontology model provides a service contract description involving not only metrics, but other relevant entities to service management and network deployment, providing closer relations between classes of service and service contracts, and between service contracts and network infrastructure. Its modular structure leaves room to model expan- sion and integration with other proposals. 7 3. Multiservice Network Ontology The proposed model is divided in two main modules: the service man- agement module and the network module. As illustrated in Figure 1, these modules are organized as a layered structure where the upper layer has a dependency relation with the lower layer. This structure mimics real life where the management component is, indeed, above the physical network. This formal representation of a network is expressed in formal terms using the support of OWL, following the principles from Methontology (Fernández- López, M. et al., 1997). [Figure 1 about here.] The network module, as stated above, acts as the base layer. It includes concepts of network node, network interface and network equipment config- uration elements related to the implementation of contracted services in the network. The management module covers the domain network service man- agement related to service contracts, including service monitoring rules. This module uses several elements of the network module. Services are categorized by relating them to a type of SLS (Morand et al., 2005; Diaconescu et al., 2003; Goderis et al., 2003). According to recommendations from (Babiarz et al., 2006), ITU Y.1541 and 3GPP standards, current service types include: real-time services, multimedia services, data services, and default traffic ser- vice. Another important component of the proposed service model regards to multiservice monitoring (see Figure 1). This implies the definition of the main monitoring issues to include in the multiservice ontology to assist the auditing of Internet services both from an ISP and customer perspective. To service providers, it will also allow a tight control of services, network resources and related configuration procedures. On top of the Multiservice Ontology, a complete ServiceModel API offers to a Service Management Platform the access to the ontological contents. Without detailing the construction of the ontology at this point, it is relevant to highlight the identification of competence questions. These are the first and the last step in this methodology and fulfill the need to establish the requirements and the outcomes of the ontology itself, i.e., which questions the ontology will be able to answer. In the present case, the definition of an ontology for multiservice IP networks intends to address multiple service- oriented goals. Possible competence questions include: 8 (i) from a customer perspective: Which type of service packs are available for subscription at present? Which is the available bandwidth for a particular service from a specific access point? Is my contracted service being delivery within the negotiated QoS? (ii) from an ISP perspective: At an aggregate level, which is the allo- cated bandwidth for a particular service type? Which are the negotiated parameters per SLS? Which are the configuration parameters on each inter- face of edge network node and the available bandwidth per interface? Which services are supported between specific ingress and egress interfaces? Are the QoE/QoS requirements of a particular service being accomplished? On which points of the network are occurring QoS violations? In the description of modules provided in the sections below, a top-down approach will be followed to allow a broad view of the multiservice ontology. 3.1. Management Module The management module is where service contracts or SLAs are defined and managed. The first concept is the Client which identifies the customer part of the contract and stores all client information. A client is related to at least one SLA which represents a service contract. An SLA can have more than one SLS. The SLS structure, illustrated in Figure 2, follows the recommendations in (Morand et al., 2005; Diaconescu et al., 2003; Goderis et al., 2003), and is briefly described below. [Figure 2 about here.] • SLS Identification: This field identifies the SLS for management pur- poses, being used by both provider and customer. It is composed of a unique SLS id parameter and a Service id parameter, allowing to identify multiple SLSs within the same service. • Scope: The scope specifies the domain boundaries over which the ser- vice will be provided and managed, and where policies specified in a service contract are applied. Normally, SLSs are associated with uni- directional flows between at least one network entry point and at least one exit point. To cover bidirectionality, more than one SLS is associ- ated with a service. The entry points and the exit points are expressed through ingress and egress interfaces, respectively (see Section 3.2). At least two Interfaces (ingress and egress) instances must be specified. 9 The interface identification must be unique and is not restricted to the IP address (the identification can be defined at other protocol layer). • Traffic Classifier: The Traffic Classifier specifies how the nego- tiated service flows are identified for differentiated service treatment. Following Diffserv terminology, multifield (MF) classification and be- havior aggregate (BA) classification are supported (see Section 3.2). Usually, BA classification takes place over previously marked traffic, e.g. in network core nodes or, in the case of SLSs, between ISPs. Two traffic classifiers can be specified, an ingress traffic classifier and op- tionally an egress one. The ingress/egress classifier is then applied to each ingress/egress interface within the scope of the SLS. • Traffic Conditioner: This field specifies the policies and mechanisms applied to traffic flows in order to guarantee traffic conformance with the traffic profiles previously specified. Traffic conditioning occurs after traffic classification, so there is always a relation between the traffic classifier and the traffic conditioner specified within a SLS. An unlimited number of TrafficConditioner instances can be spec- ified. As in the traffic classifier property, the conditioners are divided into ingress and egress depending on their role. The ingress/egress conditioner is articulated with the ingress/egress classifier on each in- terface defined in the SLS scope as an ingress/egress QoS policy. This property is not mandatory. • Performance Guarantees: The Performance Guarantee fields specify the guarantees of service quality and performance provided by the ISP. Four quality metrics are considered: delay, jitter, bandwidth and packet loss, expressed through instances of the Bandwidth, Delay, Jitter and PacketLoss Metric subclasses. The definition of at least one instance of these Metric subclasses is mandatory, except on the Default Service type of SLS. Whenever there is a performance guarantee specification, a traffic conditioning action must also be specified. Delay and jitter are usually specified by their maximum allowed value or by a pair consisting of a maximum upper bound and a quantile. Packet loss (edge-to-edge) is represented by the ratio between the packet loss detected at the egress node and the number of packets sent at ingress node. Instead of quantitative, quality and performance parameters can also be specified in a qualitative manner. 10 • Reliability: The Reliability is usually specified by the mean downtime (MDT) and by the maximum allowed time to repair (TTR). The no compliance of the negotiated parameters may result in a penalty for the ISP. • Service Schedule: The Service Schedule defines the time period of service availability associated with an SLS. While a start date is al- ways specified, an end date is only specified in case of a reservation, ReservedServiceSchedule, in which the client requests the service during a specific period of time. In the default case, StandardService- Schedule, only the service start date is specified, i.e., the contract must be explicitly terminated by the client. • Monitoring: Monitoring refers to SLS’ performance parameters mon- itoring and reporting. For that purpose, a measurement period, a reporting date and a threshold notification are specified. Other pa- rameters such as the maximum outage time, total number of outage occurrences, reporting rules and reporting destination may be speci- fied. • Type of Service: The type of service is described by the Service class. This class allows the definition of services offered by the ISP to cus- tomers from a business-oriented perspective. Offered services are de- scribed through a set of qualitative metrics. The mapping from a qual- itative service description to a quantitative service specification is as- sured by the ISP. The Service class allows to relate the SLS with a specific instance of service offering. It also helps establishing SLS tem- plates on an application level. Services can be offered as a package (e.g. triple or quadruple play services) through the ServicePack class. 3.2. Network Module At present, an ISP is represented as a cloud network, where only edge (ingress and egress) nodes are visible. The abstract representation of domain internal nodes and inherent internal service configuration mechanisms are left for future work. Therefore, instead of representing configuration elements at per-hop level, the model is focused on a per-domain level. In this module (see Figure 3) there are three key elements: [Figure 3 about here.] 11 • Node: The Node class represents a network node (on the current model, corresponds to a domain border node). It is related to a set of Interface class instances. • Interface: The Interface class represents ingress and egress points of the ISP domain. Specifically it allows the mapping of external network interfaces or entry/exit points of ISP border nodes. The interface sup- ports a two-way traffic flow. It is possible to attach layer 2 and layer 3 addresses to the interface concept in order to relate it to a real net- work interface in the ISP domain. Each interface has a total bandwidth capacity and a reserved bandwidth capacity specified dynamically for ingress traffic and egress traffic. For QoS purposes, it is possible to specify a set of QoS policies. In this case, a QoS policy is a relation between a traffic classifier instance and a set of traffic conditioner in- stances applied to traffic classified by the former. A QoS policy can be an ingress policy or an egress policy. The Interface class, as illustrated in Figure 3, is defined by an iden- tifier, link and network layer addresses and total bandwidth capacity both downstream and upstream. It includes two counters for ingress and egress reserved bandwidth of all contracted services applied to this interface. Each instance can be related to a set of QoS policies applied on incoming and outgoing traffic. A boolean value is also defined for interface state indication. [Figure 4 about here.] • Traffic Classifier: The TrafficClassifier class, as represented in Fig- ure 4, has two subclasses: MF and BA. The BA class instances, applied to previously marked traffic, only have one field, a relation with a Mark class instance. The Mark class contemplates all forms of aggregated traffic marking (such as DSCP, IPv6 FlowLabel, MPLS Exp, etc.). The MF class allows the definition of traffic classification rules with multiple fields. There are no constraints on the number of allowed fields and these are divided into: link, network and transport header fields. This means that several types of fields can be used: IPv4 and IPv6 addresses, IPv6 Flow Label, ATM VPI/VCI and MPLS Labels. The fields used in the classification rule are combined through a logic operator rep- resented through the LogicOperator class instances AND and OR. For 12 a more complex classifying rule definition, other TrafficClassifier class instances can be stated as fields, working as nested classification rules. [Figure 5 about here.] • Traffic Conditioner: The traffic conditioner is designed to measure traf- fic flows against a predetermined traffic profile and, depending on the type of conditioner, take a predefined action based on that measure- ment. Traffic conditioning is important to ensure that traffic flows enter the ISP network in conformance with the established service profile. It is also an important policy for handling packets according to their con- formity level facing a certain traffic profile with the purpose of differen- tiating them in the network. According to their features, there are three TrafficConditioner subclasses (see Figure 5): the Marker, Policer and Shaper classes. The policer usually takes an immediate action on packets according to their compliance against predefined traffic pro- file. A Policer class instance must have a set of traffic measurement parameters and at least two levels of actions defined. Three different policers are defined in the current model. The TokenBucketPolicer represents a single rate policer with two level actions (for in profile and out of profile traffic). The SingleRateThreeColorMarker and TwoRateThreeColorMarker are examples of policers with three levels of conformance actions. The Shaper is the only conditioner subclass where no immediate action is taken on traffic flows. Instead, all pack- ets are buffered until traffic profile compliance is verified. The Marker class is a special type of conditioner which performs traffic marking and may be combined with other traffic conditioner elements. 3.3. Multiservice Monitoring Module As illustrated in Figure 1, the aim of the monitoring system to develop is twofold: (i) to monitor and control SLSs parameters in order to ensure that mea- sured values are in conformance with the negotiated service quality levels. This auditing purpose involves a prior characterization of each service re- quirements, monitoring parameters and corresponding metrics, and the defi- nition of appropriate measurement methodologies and tools to report multi- level QoS and performance metrics to users and system administrators; 13 (ii) to measure and control the usage of network resources. This includes the identification of network configuration aspects impacting on services per- formance, namely scheduling and queuing strategies on network nodes. In fact, monitoring network resources and triggering traffic control mechanisms accordingly will allow to maintain consistent quality levels for the supported services and the fulfillment of the negotiated SLSs. The monitoring process should provide measures reflecting the real status of services’ performance without introducing significant overhead or interfer- ing with network operation. Therefore, measurements have to be accurate, fast and carried out on a regular basis, while minimizing intrusion. For im- proving monitoring scalability, network services with identical QoS require- ments should be grouped and monitored as an aggregate, minimizing specific or customer dependent information. Another main concern of this task is to congregate users and ISPs perspec- tives regarding the description and control of services quality. This means that the perceived service quality for users (Quality of Experience - QoE), commonly expressed through subjective parameters, has to be identified and mapped into objective and quantifiable QoS parameters, able to be effec- tively controlled by network service providers. Therefore, the articulation of QoE and QoS, and the identification of appropriate measurement methodolo- gies for evaluating and controlling service quality levels in both perspectives (users and ISPs) is a main concern to cover in the present module. In this context, multiservice monitoring is expected to provide a clear identification and layering of all monitoring issues to include in the multi- service ontology to assist auditing and control of negotiated service levels through the proposed Service Management Platform. 3.4. The VoIP Service as Example As mentioned before, a service provider may describe each provided ser- vice through a set of qualitative metric values, which are then mapped to quantitative values to assist, for instance, configuration and service control. For example, a VoIP type of service can be described as: VoIP Service Bandwidth: Low_Bandwidth = at least 1 Mbps Delay: VeryLow_Delay = at most 100 ms Jitter: VeryLow_Jitter = at most 50 ms Packet Loss: VeryLow_Loss = at most 0.001 % of lost packets 14 This type of service description is used for SLS classification in accordance with the specified metrics. In other way, SLSs can be built based on the type of service description when required. An example of an SLS instance for the VoIP service is shown in Figure 6. [Figure 6 about here.] When the SLS instance is set, the TrafficClassifer and TrafficConditioner specified lead to QoS policy instances. A relation is then established between each QoS policy and network interfaces instances specified in the scope of the SLS (Figure 6). This policy information is useful for automating the deploy- ment of QoS mechanisms in the ISP network infrastructure. By establishing relations among all these entities, a change in one of them affects all other related entities. For example, a change in an SLS parameter is spread through all the corresponding SLS configurations in the network infrastructure. 4. Applying semantics This section discusses how the presented model is converted into an on- tological support. Thus, the characterization of the multiservice domain can be used in further software solutions ranging from web contents to complex software agents responsible for decision making. This ontology was devel- oped according to the basis proposed by Methontology (Fernández-López, M. et al., 1997). In this way, it is guaranteed its conformance with a set of methodological rules and the final product can be traced to its origin and reused in a simple and cost-effective manner. The proposed ontology provides the main concepts and properties re- quired to describe multiple services levels and corresponding quality in a network domain. For its implementation, according to the terminology pro- posed in Methontology, it was used Protégé to generate the OWL represen- tation. This representation uses not only classes and properties, but it also includes restrictions on the values of the previous ones. Therefore, it is en- sured the conformance of current contents and future pieces of information to the established parameters of the system. Besides per-class restrictions, a set of general rules are defined for es- tablishing new rule-based relations between individuals. These rules are ex- pressed using SWRL and they are applied to check information in order to 15 discover new possible instances and properties within the system. So far, there are defined rules for: • validation of interfaces capacity included on a contract scope; • compliance verification of monitored metrics in relation to service con- tract specifications; • changing interfaces network status; • qualitative classification of performance metrics; • classification of SLSs according to the type of service. For example, the following rule states that if all SLS performance metrics have qualitative values matching a definition of a type of service then the SLS specifies a service of that type. SLS(?sls)∧Service(?service) ∧ includesBandwidth(?sls, ?bandwidth) ∧ includesBandwidthQualV alue(?service, ?qualiBandwidth) ∧ includesDelay(?sls, ?delay) ∧ includesDelayQualV alue(?service, ?qualiDelay) ∧ includesJitter(?sls, ?jitter) ∧ includesJitterQualV alue(?service, ?qualiJitter) ∧ includesLossQualV alue(?service, ?qualiLoss) ∧ includesPacketLoss(?sls, ?loss) ∧ includesQualitativeV alue(?bandwidth, ?qualiBandwidth) ∧ includesQualitativeV alue(?delay, ?qualiDelay) ∧ includesQualitativeV alue(?jitter, ?qualiJitter) ∧ includesQualitativeV alue(?loss, ?qualiLoss) → definesSLS(?service, ?sls) Additional rules are defined for the above mentioned issues. Nevertheless, for other purposes, it is suggested to define rules at application level due to the complexity and limitations of SWRL (Zwaal et al., 2006) at using knowledge from different sources and involving advanced logical checks. On the top of the provided ontology, it is developed a complete software API. This API, referred as the ServiceModel API, is implemented following the diagram presented in Figure 7. 16 [Figure 7 about here.] The Jena Framework (McBride, 2002) plays a major role in the devel- oped software. It provides support for working with RDF and OWL based archives. The handling of OWL entities (classes, individuals and restrictions) is provided by the Jena Ontology API. Recall that the ontological content can be accessed from the local computer or from a remote server. The Pellet (Sirin et al., 2007) engine is the reasoner used due to its SWRL (Horrocks et al., 2004) support. Working on top of the Jena framework, the Jena beans API binds RDF resources (in this case, OWL classes) to Java beans simplifying the process of Java-to-RDF conversion. This feature enables users to work with individuals as Java objects. The persistence of the knowledge is guaranteed by the TDB (Owens et al., 2008) technology, which is clearly simpler and more efficient than the SDB solution (uses SQL databases for storing RDF datasets). However, the API integration of an SDB solution is not totally abandoned. The ServiceModel APl intents to assist future projects in several goals: (i) to foster client and service provider interoperability; (ii) to manage network service contracts, facilitating the dynamic negotiation between clients and ISPs; (iii) to access and query SLA/SLSs data on a individual or aggregated basis to assist service provisioning in the network; and (iv) to assist service monitoring and auditing. Therefore, this API, aimed to sustain further de- velopments, supports in a straight-forward manner for software developers the following features: • the insertion and removal of information on the Knowledge Base (cre- ating/destroying individuals); • the validation of the Knowledge Base information (classification and realization); • establishment of more complex rules based relations (not possible through SWRL); • Knowledge Base querying. This feature is implemented through SPARQL (Prud’hommeaux and Seaborne, 2008) and the ARQL Jena API; • Knowledge Base persistence. 17 5. Practical Application Once the semantic model for fully describing SLAs/SLSs is set, services on their top can be provided. Semantics is not, in general, an end by itself. On the contrary, its use is motivated by achieving further goals. In the case of this proposal, it is generated a framework to boost interoperability and advanced data mining features. Bearing that in mind, services were derived as proof-of- concept. Firstly, it is suggested a RDFa support to introduce annotations on xhtml descriptions about SLAs and SLSs. Afterwards, it is suggested the use of a semantic engine to recover information from a repository of information regarding the formers. RDFa (Birbeck and Adida, 2008) is a semantic technology that empowers users to include semantic annotations on XML (or xhtml) contents. These annotations are invisible for human user but easily recovered for software agents using GRDDL (Connolly, Editor). It is important to keep in mind that both technologies are official recommendations from W3C. Taking as a basis the provided OWL model for describing the system, annotations can be included in xhtml describing SLAs and SLSs. For the sake of clarity, it is included the following example: 1

2 The provided connection under the i n t e r f a c e 3 Service1 , 4 provides a t o t a l bandwidth of 5 6 100 Mbps. 7

As shown in this xhtml snippet, a network interface and some of its properties are described. This definition of capacities of the Network Module can be directly recovered using GRDDL. The use case expected for this functionality is related to the web pages of ISPs. Service providers, when offering their services, can include this information into their web pages. Users will be able to recover this information through software agents on their behalf, and include it into a data repository for further decisions. Once these pieces of information are included in a Semantic Database, re- gardless of its origin, either from GRDDL extraction or from other sources, it is possible to get added-value services. Using SPARQL Queries (Prud’hommeaux 18 and Seaborne, 2008), for example, it is possible to locate SLAs/SLSs fulfill- ing specific properties the user is interested in. The only requirement is to identify the graph matching the desired properties and implement the corre- sponding SPARQL query. Authors successfully tested this feature by means of the API provided. It is actually rather simple to deploy a software tool that looks for, for instance, the cheapest SLA in the market or the one offering the fastest network access, among other features. 6. Conclusions and Future Work This paper has presented an innovative approach to the development of a semantic model in the domain of multiservice networks. This model for- mally specifies concepts related to service and SLS definition, network service management, configuration and auditing, creating the reasoning mechanisms to ground the development self-managed ISPs. Although being conceptually aligned with the differentiated service model, the solution is generic without being tied to a specific QoS paradigm. The usefulness of the present semantic service modeling has been pointed out for multiple applications in the context of multiservice management. In particular, aspects such as dynamic service negotiation between service provides and end customers, and auditing of Internet services being provided may be strongly improved as consequence of using the proposed ontology. Possibilities and features from this ontology are also presented to soft- ware developers by means of a ServiceModel API. The functionality within this library can be used for the above mentioned goals. Due to the modular schema for this software component, its inclusion on future projects consti- tutes a simple task that will provide a useful support in further developments. References M. D’Arienzo, A. Pescapè, G. Ventre, Dynamic Service Management in Het- erogeneous Networks, Journal of Network and System Management 12 (2). V. Sarangan, J. Chen, Comparative Study of Protocols for Dynamic Service Negotiation in Next Generation Internet, IEEE Communications Magazine 44 (3) (2006) 151–156. Y. Cheng, A. Leon-Garcia, I. Foster, Toward an Autonomic Service Man- agement Framework: A Holistic Vision of SOA, AON, and Autonomic 19 Computing, IEEE Communications Magazine 46 (5) (2008) 138–146, URL http://dx.doi.org/10.1109/MCOM.2008.4511662. F.-E. Zaheer, J. Xiao, R. Boutaba, Multi-provider Service Negotiation and Contracting in Network Virtualization, in: IEEE NOMS’10, 471–478, 2010. E. Atkinson, E. Floyd, IAB Concerns and Recommendations Regarding Internet Research and Evolution, RFC 3869, Internet Engineering Task Force, URL http://www.rfc-editor.org/rfc/rfc3869.txt, 2004. D. Brickley, R. Guha, Resource Description Framework (RDF) Schema Spec- ification, URL http://www.w3.org/TR/rdf-schema,W3C, 1999. J. Hendler, D. McGuinness, DARPA Agent Markup Language, IEEE Intel- ligent Systems 15 (6). S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, , L. A. Stein, OWL Web Ontology Language Refer- ence, W3C, 2004. G. Dobson, R. Lock, I. Sommerville, QoSOnt: a QoS Ontology for Service- Centric Systems, in: EUROMICRO ’05: Proceedings of the 31st EUROMI- CRO Conference on Software Engineering and Advanced Applications, IEEE Computer Society, Washington, DC, USA, ISBN 0-7695-2431-1, 80– 87, URL http://dx.doi.org/10.1109/EUROMICRO.2005.49, 2005. G. Dobson, A. Sanchez-Macian, Towards Unified QoS/SLA Ontologies, in: SCW ’06: Proceedings of the IEEE Services Computing Workshops, IEEE Computer Society, Washington, DC, USA, ISBN 0-7695-2681-0, 169–174, URL http://dx.doi.org/10.1109/SCW.2006.40, 2006. C. Zhou, L.-T. Chia, B.-S. Lee, DAML-QoS Ontology for Web Services, in: IEEE International Conference on Web Services, IEEE Computer So- ciety, Los Alamitos, CA, USA, ISBN 0-7695-2167-3, URL http://doi. ieeecomputersociety.org/10.1109/ICWS.2004.1314772, 2004. C. Zhou, L.-T. Chia, B.-S. Lee, QoS Measurement Issues with DAML-QoS Ontology, in: IEEE International Conference on E-Business Engineering, IEEE Computer Society, Los Alamitos, CA, USA, ISBN 0-7695-2430-3, 395–403, URL http://doi.ieeecomputersociety.org/10.1109/ICEBE. 2005.100, 2005. 20 A. C. Prudencio, R. Willrich, M. Diaz, S. Tazi, Quality of Service Spec- ifications: A Semantic Approach, IEEE International Symposium on Network Computing and Applications (2009) 219–226URL http://doi. ieeecomputersociety.org/10.1109/NCA.2009.36. H. M. Kim, A. Sengupta, J. Evermann, MOQ: Web services ontologies for QoS and general quality evaluations, Int. Journal of Metadata, Semantics and Ontologies 2 (3) (2007) 195–200, ISSN 1744-2621, URL http://dx. doi.org/10.1504/IJMSO.2007.017612. P. Moraes, L. Sampaio, J. Monteiro, M. Portnoi, MonONTO: A Domain Ontology for Network Monitoring and Recommendation for Advanced In- ternet Applications Users, in: Network Operations and Management Sym- posium Workshops, IEEE NOMS 2008, 116–123, URL http://dx.doi. org/10.1109/NOMSW.2007.21, 2008. P. Alípio, J. Neves, P. Carvalho, An Ontology for Network Services., in: International Conference on Computational Science (3), 240–243, URL http://dx.doi.org/10.1007/11758532_33, 2006. J. Babiarz, K. Chan, F. Baker, Configuration Guidelines for DiffServ Ser- vice Classes, RFC 4594 (Informational), URL http://www.ietf.org/ rfc/rfc4594.txt, 2006. D. Goderis, Y. T’joens, C. Jacquenet, G. Memenious, G. Pavlou, R. Egan, D. Griffin, P. Georgatsos, L. Georgiadis, P. V. Heuven, Service Level Spec- ification Semantics, Parameters, and Negotiation Requirements, Internet- Draft, drafttequila-sls-03.txt, 2003. L. Green, Service level agreements: an ontological approach, in: ICEC ’06: Proceedings of the 8th international conference on Electronic commerce, ACM, New York, NY, USA, ISBN 1-59593-392-1, 185–194, URL http: //doi.acm.org/10.1145/1151454.1151490, 2006. J. C. Royer, R. Willrich, M. Diaz, User Profile-Based Authorization Poli- cies for Network QoS Services, in: IEEE International Symposium on Network Computing and Applications, IEEE Computer Society, Los Alamitos, CA, USA, ISBN 978-0-7695-3192-2, 68–75, URL http://doi. ieeecomputersociety.org/10.1109/NCA.2008.39, 2008. 21 Fernández-López, M., Gómez-Pérez, A, Juristo, N., METHONTOLOGY: From Ontological Art Towards Ontological Engineering., Symposium on Ontological Art Towards Ontological Engineering of AAAI. (1997) 33–40. P. Morand, M. Boucadair, R. E. P. Levis, H. Asgari, D. Griffin, J. Griem, J. Spencer, P. Trimintzios, M. Howarth, N. Wang, P. Flegkas, K. Ho, S. Georgoulas, G. Pavlou, P. Georgatsos, T. Damilatis, Mescal D1.3 - Final Specification of Protocols and Algorithms for Inter-domain SLS Manage- ment and Traffic Engineering for QoS-based IP Service Delivery and their Test Requirements , Mescal Project IST-2001-37961, 2005. A. Diaconescu, S. Antonio, M. Esposito, S. Romano, M. Potts, Cadenus D2.3 - Resource Management in SLA Networks, Cadenus Project IST- 1999-11017, 2003. H. Zwaal, M. Hutschemaekers, M. Verheijen, Manipulating context informa- tion with SWRL, A-MUSE Deliverable D3.12, 2006. B. McBride, Jena: a Semantic Web Toolkit, IEEE Internet Computing 6 (6) (2002) 55–59, ISSN 1089-7801, URL http://dx.doi.org/10.1109/MIC. 2002.1067737. E. Sirin, B. Parsia, B. Grau, A. Kalyanpur, Y. Katz, Pellet: A practical OWL-DL reasoner, Journal of Web Semantics 5 (2) (2007) 51–53, ISSN 1570-8268. I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean, SWRL: A Semantic Web Rule Language Combining OWL and RuleML, W3C Member Submission, W3C, URL http://www.w3.org/Submission/ SWRL, 2004. A. Owens, A. Seaborne, N. Gibbins, mc schraefel, Clustered TDB: A Clus- tered Triple Store for Jena, in: WWW 2009, URL http://eprints.ecs. soton.ac.uk/16974/, 2008. E. Prud’hommeaux, A. Seaborne, SPARQL Query Language for RDF, W3C Recommendation, W3C, URL http://www.w3.org/TR/2008/ REC-rdf-sparql-query-20080115/, 2008. M. Birbeck, B. Adida, RDFa Primer, W3C Note, W3C, URL http://www. w3.org/TR/2008/NOTE-xhtml-rdfa-primer-20081014/, 2008. 22 D. Connolly(Editor), Gleaning Resource Descriptions from Dialects of Lan- guages (GRDDL), W3C Recommendation, W3C, URL http://www.w3. org/TR/grddl, 2007. 23 List of Figures 1 Service model diagram . . . . . . . . . . . . . . . . . . . . . . 25 2 SLS class diagram . . . . . . . . . . . . . . . . . . . . . . . . . 26 3 Interface class diagram . . . . . . . . . . . . . . . . . . . . . . 27 4 Classifier class diagram . . . . . . . . . . . . . . . . . . . . . . 28 5 Conditioner class diagram . . . . . . . . . . . . . . . . . . . . 29 6 SLS example diagram . . . . . . . . . . . . . . . . . . . . . . . 30 7 ServiceModel API structure diagram . . . . . . . . . . . . . . 31 24 Figure 1: Service model diagram 25 -i d : s tr in g -n a m e : s tr in g -e m a il : s tr in g -c o u n tr y : s tr in g -s tr e e tA d d re s s : s tr in g -t e le p h o n e : i n t C li e n t -m e tr ic V a lu e : f lo a t -u n it : s tr in g -u n it C o n v e rs io n : f lo a t -b a s e U n it : s tr in g M e tr ic -i d : s tr in g S L A -i d : s tr in g S L S -s ta rt D a te S e rv ic e S c h e d u le -i n c lu d e s S L A 0 .. * -i n c lu d e d S L A B y 1 -i n c lu d e s S L S 0 .. * -includedSLSBy 1 -i n c lu d e s S c o p e 1 .. * 1 -includesPerformanceGuarantees 1 1 -i s M o n it o re d B y 0 .. * -m o n it o ri z e s S L S 1 -i n c lu d e s S e rv ic e S c h e d u le 1 1 -i d : s tr in g N e tw o rk M o d u le :: T ra ff ic C la s s if ie r -i d : s tr in g N e tw o rk M o d u le :: T ra ff ic C o n d it io n e r -i d : s tr in g -n a m e : s tr in g -i n c lu d e s T o ta lB a n d w id th C a p a c it y : f lo a t -i n c lu d e s R e s e rv e d In g re s s B a n d w id th C a p a c it y : f lo a t -i n c lu d e s R e s e rv e d E g re s s B a n d w id th C a p a c it y : f lo a t -i n c lu d e s L a y e r2 A d d re s s : s tr in g -i n c lu d e s L a y e r3 A d d re s s : s tr in g -i s A c ti v e : b o o l N e tw o rk M o d u le :: In te rf a c e -i n c lu d e s C la s s if ie r 1 .. 2 1 -i n c lu d e s C o n d it io n e r * * -i s In C o n fo rm it y : b o o l M o n it o rS L S -s e rv ic e N a m e : s tr in g S e rv ic e -d e fi n e s S L S 0 .. * 1 -n a m e : s tr in g S e rv ic e P a c k -i n c lu d e s S e rv ic e 1 .. * * -i n c lu d e s P e rf o rm a n c e G u a ra n te e s 11 Figure 2: SLS class diagram 26 -i d : s tr in g -n a m e : s tr in g -i n c lu d e s T o ta lB a n d w id th C a p a c it y : f lo a t -i n c lu d e s R e s e rv e d In g re s s B a n d w id th C a p a c it y : f lo a t -i n c lu d e s R e s e rv e d E g re s s B a n d w id th C a p a c it y : f lo a t -i n c lu d e s L a y e r2 A d d re s s : s tr in g -i n c lu d e s L a y e r3 A d d re s s : s tr in g -i s A c ti v e : b o o l In te rf a c e -i d : s tr in g -n a m e : s tr in g N o d e -i d : s tr in g P o li c y -i d : s tr in g T ra ff ic C la s s if ie r -i d : s tr in g T ra ff ic C o n d it io n e r -i n c lu d e s In te rf a c e 0 .. * -i n c lu d e d In te rf a c e B y 1 -i n c lu d e s In g re s s P o li c ie s 0 .. * 1 -i n c lu d e s E g re s s P o li c ie s 0 .. * 1 N e tw o rk -i n c lu d e s N o d e 0 .. * 1 -includesClassifier 0 .. * 1 -includesConditioner 0 .. * * Figure 3: Interface class diagram 27 Mark -id : string TrafficClassifier BA -includesLayer2AddressSpec : string -includesLayer3AddressSpec : string -includesLayer4AddressSpec : string -includesProtocolID : string MF -in c lu d e s C la s s ific a tio n M a rk 1 * LogicOperator -includesLogicOperator 1 1 -includesNestedClassifier 0..* 1 Figure 4: Classifier class diagram 28 A c ti o n M A R K D R O P -i d : s tr in g T ra ff ic C o n d it io n e r M a rk e r S h a p e r -i n c lu d e s C o n fo rm a n c e L e v e l1 1 -i n c lu d e s O u tP ro fi le L e v e l1 1 -i n c lu d e s C IR : f lo a t -i n c lu d e s C B S : f lo a t -i n c lu d e s E B S : f lo a t S in g le R a te T h re e C o lo rM a rk e r -i n c lu d e s C IR : f lo a t -i n c lu d e s C B S : f lo a t -i n c lu d e s P IR : f lo a t -i n c lu d e s P B S : f lo a t T w o R a te T h re e C o lo rM a rk e r -i n c lu d e s E x c e e d P ro fi le L e v e l1 1 -i n c lu d e s S R : f lo a t -i n c lu d e s B S : f lo a t T o k e n B u c k e tP o li c e r -i n c lu d e s B S : f lo a t T o k e n B u c k e tS h a p e r -i n c lu d e s S R : f lo a t L e a k y B u c k e t T R A N S M IT -i n c lu d e s E x c e e d P ro fi le L e v e l 1 1 P o li c e r -i n c lu d e s In P ro fi le L e v e l1 1 Figure 5: Conditioner class diagram 29 id : s tr in g = S L S 1S L S 1 : S L S id : s tr in g = N 1 I1 n a m e : s tr in g = e th 0 in c lu d e s T o ta lB a n d w id th C a p a c it y : f lo a t = 1 0 0 0 0 0 0 in c lu d e s R e s e rv e d In g re s s B a n d w id th C a p a c it y : f lo a t = 1 0 2 4 in c lu d e s R e s e rv e d E g re s s B a n d w id th C a p a c it y : f lo a t = 0 in c lu d e s L a y e r2 A d d re s s : s tr in g = 0 0 :0 0 :0 0 :0 0 :0 0 :0 1 in c lu d e s L a y e r3 A d d re s s : s tr in g = 1 0 .0 .0 .1 is A c ti v e : b o o l = t ru e N 1 I1 : N e tw o rk M o d u le :: In te rf a c e id : s tr in g = N 2 I1 n a m e : s tr in g = e th 0 in c lu d e s T o ta lB a n d w id th C a p a c it y : f lo a t = 1 0 0 0 0 0 0 in c lu d e s R e s e rv e d In g re s s B a n d w id th C a p a c it y : f lo a t = 0 in c lu d e s R e s e rv e d E g re s s B a n d w id th C a p a c it y : f lo a t = 1 0 2 4 in c lu d e s L a y e r2 A d d re s s : s tr in g = 0 0 :0 0 :0 0 :0 0 :0 0 :0 2 in c lu d e s L a y e r3 A d d re s s : s tr in g = 1 0 .1 .0 .1 is A c ti v e : b o o l = t ru e N 2 I1 : N e tw o rk M o d u le :: In te rf a c e id : s tr in g = C l1 in c lu d e s L a y e r2 A d d re s s S p e c : s tr in g in c lu d e s L a y e r3 A d d re s s S p e c : s tr in g = 1 0 .0 .0 .5 1 in c lu d e s L a y e r4 A d d re s s S p e c : s tr in g = 1 2 3 4 5 in c lu d e s P ro to c o lI D : s tr in g C l1 : N e tw o rk M o d u le :: M F id : s tr in g = T k 1 in c lu d e s S R : f lo a t = 1 0 2 4 in c lu d e s B S : f lo a t = 1 5 0 0 T k 1 : N e tw o rk M o d u le :: T o k e n B u c k e tP o li c e r m e tr ic V a lu e : f lo a t = 1 0 2 4 u n it : s tr in g = b p s u n it C o n v e rs io n : f lo a t = 1 b a s e U n it : s tr in g = b p s B d 1 : B a n d w id th m e tr ic V a lu e : f lo a t = 1 0 0 u n it : s tr in g = m s u n it C o n v e rs io n : f lo a t = 1 b a s e U n it : s tr in g = m s D l1 : D e la y m e tr ic V a lu e : f lo a t = 5 0 u n it : s tr in g = m s u n it C o n v e rs io n : f lo a t = 1 b a s e U n it : s tr in g = m s J t1 : J it te r m e tr ic V a lu e : f lo a t = 0 .0 0 1 u n it : s tr in g = % u n it C o n v e rs io n : f lo a t = 1 b a s e U n it : s tr in g = % P L 1 : L o s s m e tr ic V a lu e : f lo a t = 9 9 u n it : s tr in g = % u n it C o n v e rs io n : f lo a t = 1 b a s e U n it : s tr in g = % R l1 : R e li a b il it y s ta rt D a te = 0 1 /0 1 /1 0 S c h d 1 : S ta n d a rd S e rv ic e S c h e d u le in c lu d e s In g re s s In te rf a c e in c lu d e s E g re s s In te rf a c e in c lu d e s In g re s s C la s s if ie r in c lu d e s In g re s s C o n d it io n e r in c lu d e s P e rf o rm a n c e G u a ra n te e s in c lu d e s S e rv ic e S c h e d u le in c lu d e s R e li a b il it y T k 1 A 1 : N e tw o rk M o d u le :: M A R K D R O P : N e tw o rk M o d u le :: D R O P in c lu d e s In P ro fi le A c ti o n in c lu d e s O u tP ro fi le A c ti o n E F : N e tw o rk M o d u le :: D S C P in c lu d e s R e s u lt in g M a rk id : s tr in g = S L S 1 P S L S 1 P : N e tw o rk M o d u le :: P o li c y in c lu d e s C la s s if ie r in c lu d e s C o n d it io n e r in c lu d e s In g re s s P o li c y Figure 6: SLS example diagram 30 PelletJena Framework JenaBeans TDB ServiceModel API Figure 7: ServiceModel API structure diagram 31