SemNaaS: Semantic Web for Network as a Service

Mohamed Morsey

, Hao Zhu

, Isart Canyameres

, Samuel Norbury

Paola Grosso

and Miroslav Zivkovic

Informatics Institute, University of Amsterdam, 1098 XH Amsterdam, The Netherlands

i2CAT Foundation, 08034 Barcelona, Spain

Keywords:

Cloud Computing, Network as a Service, Network Markup Language, Semantic Web.

Abstract:

Cloud Computing has several provisioning models, namely Infrastructure as a service (IaaS), Platform as a

service (PaaS), and Software as a service (SaaS). However, cloud users (tenants) have limited or no control over

the underlying network resources and services. Network as a Service (NaaS) is emerging as a novel model to

bridge this gap. However, NaaS requires an approach capable of modeling the underlying network resources

and capabilities in abstracted and vendor-independent form. In this paper we elaborate on SemNaaS, a Semantic

Web based approach for supporting network management in NaaS systems. Our contribution is three-fold. First,

we adopt and improve the Network Markup Language (NML) ontology for describing NaaS infrastructures.

Second, based on that ontology, we develop a network modeling system that is integrated with the existing

OpenNaaS framework. Third, we demonstrate the beneﬁts that Semantic Web adds to the Network as a Service

paradigm by applying SemNaaS operations to a speciﬁc NaaS use case.

1 INTRODUCTION

Cloud infrastructures and cloud services are becom-

ing the de facto architecture to support operations of

large web infrastructures, to process Big Data and to

provide users with ubiquitous and scalable computing

and storage services. This model of operation is prov-

ing effective thanks to its scalability and the associated

economic advantages. Still there are less explored chal-

lenges for an optimal operation: one of them being the

delivery of tailored network services.

New frameworks are emerging to deﬁne and create

such dynamic network services; they effectively pro-

vide easy APIs to deﬁne services at the network level,

while leveraging new capabilities such as Software

Deﬁned Networking methods and Network Virtualiza-

tion techniques. These frameworks in essence support

Network as a Service (NaaS) operations.

There are several deﬁnitions for NaaS:

•

(Costa et al., 2012) deﬁnes it as a modern Cloud

Computing paradigm in which the user has access

to the network infrastructure. Via NaaS, the user

can apply custom forwarding according to his/her

application requirements.

•

In (Minoves et al., 2012), the authors deﬁne NaaS

as a strategy which enables the deployment of dy-

namic infrastructures which support various ap-

plications, with each application having its own

network usage technique. The NaaS methodol-

ogy offers virtual infrastructures to the user via

software and/or web services.

The common element among the above deﬁnitions is

that NaaS provides dynamicity and better matching

between network performance and application require-

ments.

1.1 Beneﬁts of Semantic Web for NaaS

The emerging NaaS software systems require power-

ful and rich vocabularies, such as the ones that can be

provided by Semantic Web ontologies. Those vocabu-

laries should hide the network implementation details

from the user. Thus, NaaS users can fully express their

needs in terms of services, without having to know the

details of physical network devices. This is particu-

larly signiﬁcant when the requested network services

span multiple domains that need to interoperate. OWL

ontologies provide three main advantages as models

for NaaS:

1. they are easy to extend;

they allow for automatic validation of both requests

and provisioned services;

3. they enhance network resource discovery.

Morsey, M., Zhu, H., Canyameres, I., Norbury, S., Grosso, P. and Zivkovic, M.

SemNaaS: Semantic Web for Network as a Service.

In Proceedings of the 6th International Conference on Cloud Computing and Services Science (CLOSER 2016) - Volume 1, pages 27-36

ISBN: 978-989-758-182-3

The last advantage is the most distinguishing factor

in adopting them as models for NaaS. Network users

often request network resources providing different

software programmability levels and different hard-

ware conﬁgurations. An example would be a request

for programmable network paths that use different

links depending on the application data being passed

between a sender and a receiver. This illustrates that

discovering suitable resources that match high user/ap-

plication dependent requirements is really a difﬁcult

task. However, the representation of this metadata in

the ontology supports the keyword-based discovery of

resources that often miss relatively capable resources.

With semantic descriptions of resources, NaaS can not

only discover the resource that exactly matches with

that of the request, but also retrieves resources that

exhibit subsumption relation when the exact match is

not found.

Furthermore, RDF is a graph-based data model which

promotes it for modeling computer networks, as a

network forms a graph of interconnected nodes. This is

quite advantageous for connectivity checking and path

ﬁnding at early stage, i.e. prior to the actual network

provisioning, which ultimately lowers the reservation

cost (cf. Section 5).

1.2 The SemNaaS approach

We propose a novel approach to tackle the problem of

augmenting NaaS for clouds with a semantic dimen-

sion. In the following we highlight:

our novel Semantic Web-based approach for NaaS,

called SemNaaS;

our methods to empower the interconnection of

distributed NaaS instances;

the application of our approach to OpenNaaS

an example framework supporting NaaS;

a demonstration of a real world use case, which

shows SemNaaS in operation.

The rest of the paper is structured as follows. First,

we discuss related work in Section 2. Afterwards, we

elaborate on the SemNaaS approach in 3. In 4, Open-

NaaS is discussed in detail, which we use as the NaaS

provider. In Section 5, we discuss the architecture

of the SemNaaS system, and elaborate the SemNaaS

features in Section 6. Finally, we evaluate our system

using a use case showing the beneﬁts of Semantic Web

to NaaS in Section 7, before we conclude in Section 8.

http://opennaas.org

2 RELATED WORK

Many disciplines leverage Semantic Web technology,

including networks and Cloud Computing, in order to

model their computing infrastructures. Peter Haase et

al. (Haase et al., 2010) introduce a strategy for man-

aging enterprise Cloud environments. They utilize Se-

mantic Web to tackle the challenges involved in man-

agement of enterprise Cloud systems. They develop a

product called eCloudManager, which depends on an

ontology for modeling eCloudManager data. However,

the system and its ontology only focus on the man-

agement aspect of Cloud systems. Furthermore, They

do not address the problem of how various computing

components are interconnected to each other.

Santana-P

erez et al. (Santana-P

erez and Perez-

Hern

andez, 2012) propose a scheduling approach for

federated hybrid Cloud systems, based on semantic

technologies, capable of scheduling and allocating

tasks to the most suitable resource(s). The approach

reuses and modiﬁes the UCI project ontologies

, which

comprise the information model. Although the ontolo-

gies cover a wide spectrum of details, they do not

cover the interconnection between the various Cloud

components.

Haak et al. (Haak and Grimm, 2011) present an

ontology-based optimization framework that enables

the Cloud service providers to ﬁgure out the best suit-

ing resource combination that fulﬁlls the user’s request.

The approach focuses only on the resource composi-

tion optimization without addressing the issue of using

semantic technologies for administering the Cloud en-

vironments.

(Dastjerdi et al., 2010; Ngan and Kanagasabai, 2012)

propose ontology-based methodologies for discover-

ing and brokering Cloud services. Both works use

semantics for user requirements and Cloud provider

advertisements, and then apply a matchmaking algo-

rithm to ﬁnd the match between a requirement list and

the list of advertised units. Both deﬁne multiple levels

of matching, ranging from exact match to no match.

Nevertheless, both concentrate only on Infrastructure

as a Service (IaaS) provisioning.

Semantic Web Service (SWS) discovery (Junghans

et al., 2010; Stollberg et al., 2007) tackles the problem

of automated discovery of Web Services that fulﬁll the

given requirements. The discovery process devotes a

matchmaking algorithm for ﬁnding usable Web Ser-

vices for solving the problem at hand. However, these

approaches can not be applied on complex intercon-

nected computing infrastructures.

Generally, all these approaches neither address the

networking strategy, nor deﬁne a Network as a Service.

http://code.google.com/p/uniﬁedcloud

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

This leads to the necessity of new methodology that

gives the user more control over the networking and

network resource reservation.

3 SemNaaS APPROACH

SemNaaS aims to improve OpenNaaS using Semantic

Web technologies. The main advantage of SemNaaS

is that it is a generic system in which OpenNaaS is

a pluggable component. In other words, SemNaaS

exposes its functionality as a set of APIs and RESTful

web services, which OpenNaaS consumes. Hence, if

OpenNaaS is replaced with any other Network as a

Service platform, the latter can still beneﬁt from the

semantic capabilities SemNaaS offers. Furthermore,

SemNaaS provides the capability to track and monitor

the process of network resources provisioning at its

various stages starting from resource(s) request to the

release of those resource(s). SemNaaS is also open

source

The main objective of SemNaaS is to add a semantic

dimension to OpenNaaS, and subsequently to Network

as a Service paradigm. That includes several potential

improvement aspects for OpenNaaS:

•

Support of network request validation and network

connectivity check;

•

System monitoring and failure condition detection;

•

Capability of constructing distributed and intercon-

nected OpenNaaS instances;

• Complex status report generation.

3.1 Preliminaries on RDF and SPARQL

1.1

According to the abstract treatments of RDF (Arenas

et al., 2012; P

erez et al., 2006), we assume

, and

be three pairwise disjoint sets denoting the sets of

IRIs, blank nodes, and literals respectively.

Deﬁnition 1

(RDF Triple)

An RDF triple

is a tuple

(s, p, o) ∈ (I ∪ B) ×I × (I ∪ B ∪ L)

where s, p, o are

called subject, predicate and object, respectively.

Deﬁnition 2

(RDF Graph)

An RDF

graph is a ﬁnite set of RDF triples

G =

{

, p

, o

), (s

, p

, o

), ..., (s

, p

, o

)

}

where s

is the subject, p

is the predicate and o

is the object of

triple τ

Deﬁnition 3

(SPARQL Graph Pattern)

A SPARQL

triple pattern is a tuple of the form

(I ∪ V ) × (I ∪

V ) × (I ∪ L ∪ V )

where

is the set of IRIs,

http://github.com/dana-i2cat/semnaas

the set of literals, and

being the set of variables.

SPARQL basic graph pattern (BGP) is a ﬁnite set of

triple patterns.

Deﬁnition 4

(SPARQL Property Path)

According

to (Harris and Seaborne, 2013) a property path can

be deﬁned as: (1) if

i ∈ I −→ i

is a property path, and

(2) if p and q are property paths, then (ˆp), (p/q), (p

q),

), and (p

) are property paths as well, where ˆ de-

notes inverse, / denotes sequence,

denotes alternative,

* is Kleene star, and + is Kleene plus.

3.2 Network Markup Language (NML)

The NML ontology is at the core of the SemNaaS

system, as it constitutes the main concepts required to

create, deﬁne and link various network nodes. We have

reused and improved the Network Markup Language

(NML)

ontology (van der Ham et al., 2013). NML

is an ontology constituting the information model for

describing and deﬁning computer networks. The de-

velopers of NML kept it abstract with the possibility

of extension in order to customize it for certain use

cases.

In order to use NML for NaaS, we have enhanced the

ontology in order to permit the creation of complex

network topologies

. The enhancements include de-

vising more classes and properties and improving the

existing ones as well.

New Classes and Properties.

A path between two

network nodes is simply an ordered list of links, start-

ing from the start node and ending at the end node.

Hence, in order to represent a path between two

Node

instances, we added two classes, namely

ListItem

which is the parent class of

Link

and

LinkGroup

We also added class

Path

which denotes an ordered

list of

ListItem

s. Furthermore, we added prop-

erties

hasSourceNetworkObject

and

hasSinkNet-

workObject

and declared them as the inverse of prop-

erties

isSource

and

isSink

respectively. Those prop-

erties assist in connectivity checking (cf. Section 5).

Improved Classes and Properties.

Basically, the

network provisioned by OpenNaaS might span

multiple geographical locations, thus we declared

Location

as a subclass of

geo:SpatialThing

Property

locatedAt

is declared as subproperty of

geo:location

, and its domain is

NetworkObject

http://www.ogf.org/documents/GFD.206.pdf

The ontology is available at http://bitbucket.org/uva-

sne/indl/src/master/nml.owl

http://www.w3.org/2003/01/geo/wgs84˙pos#

SemNaaS: Semantic Web for Network as a Service

xsd:

decimal

rdf:type owl:Class

rdf:type owl:DatatypeProperty

rdf:type owl:ObjectProperty

Legend

nml:NetworkObject

owl:Thing

nml:Node

nml:isSource

rdfs:subClassOf

nml:Port

nml:Link

nml:Group

nml:LinkGroup

nml:Topology

rdfs:subClassOf

geo:SpatialThing

nml:Location

rdfs:subClassOf

time:TemporalEntity

nml:Lifetime

rdfs:subClassOf

nml:isSink

rdfs:subClassOf

nml:hasInboundPort

nml:hasOutboundPort

nml:hasSourceNetworkObject

nml:hasSinkNetworkObject

rdfs:subClassOf

time:Instant

rdfs:subClassOf

time:hasEnd

time:hasBeginning

xsd:

dateTime

time:inXSDDateTime

rdfs:domain

owl:unionOf

Figure 1: The key concepts and properties NML ontology.

and its range is

Location

. Furthermore, class

Life-

time

represents the time period during which a

Net-

workObject

is active, and it is quite helpful in case

of Network as a Service, as the network resources

are reserved for a speciﬁc amount of time.

Lifetime

is declared as a subclass of

time:TemporalEntity

of the W3C Time ontology (Hobbs and Pan, 2006).

We also utilized properties

time:hasBeginning

and

time:hasEnd

to denote start and end times of a reser-

vation respectively.

1 illustrates the key classes and properties of NML.

4 OpenNaaS

OpenNaaS, i.e.

Open N

etwork

a S

ervice, is an open

source framework for network resources provision-

ing

. It enables the deployment, management, and

conﬁguration of dynamic network infrastructures. Fur-

thermore, it deﬁnes vendor-independent interface to

access and administer services provided by those net-

work resources (Minoves et al., 2012; Aznar et al.,

2013).

OpenNaaS was ﬁrst conceived over the NaaS paradigm

as a key enabler to offer virtual infrastructure ser-

vices to third parties. It supports the creation of a vir-

tual representation of a physical resource (e.g. router,

switch), based on an abstract model of it which is often

achieved by partitioning or aggregation.

It is built upon a set of core concepts, which are mainly

resources, model, and capabilities. These concepts can

be summarized as follows:

•

Resources: The manageable units of OpenNaaS.

They are the entities the user can own, manage and

operate, e.g. a switch and a router.

•

Model: The resource exposes a model that enables

checking state and capabilities of this resource.

The source code of OpenNaaS is available at

https://github.com/dana-i2cat/opennaas/

Any change in resource state is reﬂected on its

model.

•

Capabilities: A capability is an interface to a re-

source functionality, e.g. Open Shortest Path First

(OSPF) conﬁguration capability for a router re-

source. A resource may contain several capabili-

ties exposing its functionality.

In summary, resources represent physical and virtual

devices, as well as networks. Resources use a model

to represent their state and expose capabilities, which

are vendor neutral interfaces to a given resource func-

tionality. Each resource has a deﬁned lifecycle, which

deﬁnes its current state, e.g. active and inactive. Only

when the resource is active, all its capabilities are ini-

tialized and available for its use. The same also applies

to the resource model.

4.1 OpenNaaS Architecture

The OpenNaaS system consists of three layers, namely

the platform layer, the NaaS layer, and the network

intelligence layer, as illustrated in 2.

Network

Intelligence

Layer

NaaS Layer

Platform

Layer

Figure 2: The OpenNaaS framework architecture.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

The Platform Layer.

The platform layer, marked in

orange in OpenNaaS architecture diagram, is the Open-

NaaS technological framework. It is the foundation of

the NaaS layer. The platform layer:

•

is embeddable and interoperable. It can be a com-

ponent of a bigger middleware (i.e. a cloud man-

agement infrastructure);

•

provides reusable concepts across plugins, such as

the deﬁnition for Resources, Capabilities, Actions,

and their lifecycle. A command toolset is built

around these concepts;

•

handles lifecycle and persistence, it maintains pro-

tocol session lifecycle, with an eye on session

reusability.

The NaaS Layer.

The NaaS layer, highlighted in

green, reuses platform deﬁned components to expose

user manageable resources. This layer offers support

for concrete resource types, functionalities (called ca-

pabilities) and device types. Resources and capabilities

are exposed to the user abstracted from implementa-

tion details and from hardware speciﬁcations. Hence,

this layer acts as a Hardware Abstraction Layer. Ca-

pability implementation for speciﬁc devices (called

drivers) are also part of this layer.

The Network Intelligence Layer.

On top of the ab-

straction provided by the NaaS layer, applications will-

ing to manage the network may be built. These ap-

plications compose the Network Intelligence layer,

illustrated in red. It receives this name as it is where

managing policies may be deﬁned and actions based

on them applied to the network using OpenNaaS. The

OpenNaaS architecture is discussed in detail in (man,

2013). From the OpenNaaS perspective, SemNaaS

system introduced in this paper is an application be-

longing to this layer.

5 SemNaaS ARCHITECTURE

The SemNaaS system consists of four components:

Request validation and connectivity checking com-

ponent;

2. Monitoring component;

3. Report generator component;

OpenNaaS component, which is a pluggable com-

ponent, that supports the network resources provi-

sioning.

SemNaaS architecture is illustrated in 3. The Open-

NaaS component was discussed in Section 4, the re-

maining components are discussed in the following

subsections.

Triplestore

Network

SemNaaS

Request

Validator

Monitoring

Controller

Report

Generator

OpenNaaS

Figure 3: The SemNaaS general system architecture.

Request Generator and Validation.

A crucial

NaaS function is to provide users with a network on de-

mand with a speciﬁed topology. The users can indepen-

dently use the network to do experiments or execute

jobs. In order to acquire a network topology, the user

should formulate a request, which can be generated

via the SemNaaS user interface. That request contains

information about the various network components,

e.g. ports and links, that should be created by Open-

NaaS and their interconnection together. The NML

ontology is used to formulate that request properly (cf.

Section 3.2). Example network topology is shown in 4,

which is described in NML (in Turtle format) as indi-

cated in 3. SemNaaS enables the user to graphically

create her topology, and validate it to detect any errors

and/or warnings. 5 indicates the generated request,

and the output of its validation. On other hand, Sem-

NaaS also enables the tenant to create his/her required

topology graphically, using drag & drop. Via this in-

terface, he/she can set the namespace and component

IDs, which will contribute to the generated URIs of

various components.

SemNaaS performs two levels of validation, namely

Link

Host

Figure 4: A network topology example.

Figure 5: SemNaaS system validating a topology request.

SemNaaS: Semantic Web for Network as a Service

request validation, and connectivity check. The ﬁrst

level ensures that the request is syntactically correct,

i.e. no syntactic error exists in the request. Further,

SemNaaS uses the Pellet reasoner (Sirin et al., 2007) to

validate the request with respect to the NML ontology.

In other words, it checks that the request adheres to

the NML vocabulary, and no violation exists, e.g. no

component is declared as a port and as link at the same

time, as those concepts are disjoint.

The second level of validation, is the connectivity val-

idation, in which SemNaaS validates the request and

detects if a network node is unreachable from another

node. That is how to detect the inaccessibility of some

components at early stage, which helps in avoiding

that problem when the resources are allocated. We uti-

lize SPARQL (Harris and Seaborne, 2013) queries to

detect any unreachability problems among the various

nodes of the requested network.

Deﬁnition 5

(Connectivity Check)

. ∀n

, n

∈

N, ∃p

, n

)

where

, n

are the start node and end

nodes respectively,

is the set of all nodes and

represents the property path between n

and n

Based on 5, SPARQL query in 1, retrieves each node

along with all other nodes reachable from that node.

After the request is validated, it is passed to OpenNaaS

for provisioning. Moreover, the request is saved in

RDF to Virtuoso triplestore (Erling and Mikhailov,

2007) for later use. That helps in report generation

and for system utilization analysis, i.e. it helps in

tracking OpenNaaS utilization. After performing this

two-level validation on the user’s request, a list of

errors and/or warnings, in case one exits, is returned

to the user. An error represents a violation of an NML

rule, which prevents the request from fulﬁllment. Thus

the request is neither passed to OpenNaaS, nor stored

in the triplestore. In case an unreachability between

two or more nodes is detected, it is just returned as a

warning to the user in order for him/her to ﬁx.

Monitoring Controller Component.

Once the re-

quest is sent, OpenNaaS determines whether the re-

quested resources can be granted immediately or the

user should wait till those resources can be granted.

During normal operation, a resource passes through

several states, which represent its current state, e.g.

active. However, the resource may experience failure

conditions as well, e.g. network connectivity failure.

All those states should also be tracked and monitored,

thus the system administrator can later analyze and

calibrate those problems.

Whenever a change occurs in the resource status,

SemNaaS tracks that change. So that the SemNaaS

data always reﬂects the most recent status of Open-

NaaS resources. OpenNaaS has a core component

called ”Resource Manager” via which the user can

create, update, and/or delete resource. Furthermore,

the user can retrieve and/or change the resource sta-

tus. The resource manager provides all of its ser-

vice as RESTful web services, which enables query-

ing those services online. For example, in order

to get the current status of a resource you can use

http://www.i2cat.net/resources/resourceId/status, and

just replace resourceId with the local resource ID.

SemNaaS can utilize this interface, to regularly contact

OpenNaaS to get the status of each resource reserved

in a request. Thus, SemNaaS data always reﬂects the

most up-to-date state of the whole system. This also

assists in determining whether there are free resources

OpenNaaS has, which can be used to fulﬁll a new

request.

It is worth noting that there is a minimal dependency

from SemNaaS on OpenNaaS web services to retrieve

the status of various resources. Consequently, if Open-

NaaS is replaced by another NaaS provider, it should

provide an interface to SemNaaS for resource status

retrieval.

1 SELECT DISTINCT ? S t art N o de ? En d Nod e

2 WHERE { ? S t art N o de n ml : has O u t b ound P o r t ?

Sta r t Por t .

3 ? S t a rtPo r t ( nml : isS o u rce / nml :

hasS i n k N e twork O b j e c t )+ ? End P ort .

4 ? E n dNo d e nml : h asIn b o u n dPor t ? E n dPo r t }

5 ORDER BY ? S t art N o de ? En d Nod e

Listing 1: SPARQL query to check the connectivity

between the various nodes of a sample topology.

1 SELECT ? netw o r k R esou r c e ? s t art T i me

2 WHERE {? netw o r k R esou r c e nm l : e x ists D u r ing ?

lif e tim e . ? l ifet i me time: h a s Begi n n ing ?

star t T i m eIns t a n t . ? s t artTi m e I n stan t time:

inX S D D ateT i m e ? s tart T ime .

3 FILTER((? sta r t Tim e > "2014-10-01T00:00:00Z"ˆˆ

xs d : d ate T ime ) && (NOT EXISTS {? l ife t i me time:

ha s End ? e n dti m e }) )}

4 ORDER BY ? s t art T i me

Listing 2: SPARQL query to list all active resources

reserved after the beginning of October.

Report Generator Component.

SemNaaS empow-

ers OpenNaaS, and any other NaaS framework if en-

gaged in place of OpenNaaS, to create complex reports

about the whole resource reservation process. Those

reports enable the system administrator to identify the

problematic resources of OpenNaaS, monitor the re-

source failure conditions, and identify the lifetime of

any resource, i.e. the time from its creation until re-

lease.

Deﬁnition 6

(Unreleased Resources Check)

. ∀

∈ R

∃

∈ L

, nml: existsDuring(r, l)

∧

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

time:hasBeginning(

l, t

) ∧ ¬

time:hasBeginning(

l, t

)

where

is the network resource set,

is the lifetime

set, and t

, t

are the start and end times respectively.

1 nml - re s o urc e : ho st1 a n ml : N ode ;

2 nm l : e x ist s D u ring nml - re s ourc e :

Rese r v a t i onLif e T i m e ;

3 nm l : h a sInb o u n dPor t nml - re s ourc e : p o rt_ A ;

4 nm l : h a sOut b o u n dPor t nml - re s ourc e : p o rt_ A .

5 nml - re s o urc e : s w1 a n ml : N ode ;

6 nm l : e x ist s D u ring nml - re s ourc e :

Rese r v a t i onLif e T i m e ;

7 nm l : h a sInb o u n dPor t nml - re s ourc e : p o rt_ B ;

8 nm l : h a sOut b o u n dPor t nml - re s ourc e : p o rt_ B .

9 nml - re s o urc e : s w2 a n ml : N ode ;

10 nm l : h a sInb o u n dPor t nml - re s ourc e : p o rt_ C ;

11 nm l : h a sOut b o u n dPor t nml - re s ourc e : p o rt_ C .

12 nml - re s o urc e : po rt_ A a n ml : P ort ;

13 nm l : isS i nk nml - re s o urc e : link1 , nml -

res o urc e : li nk2 ;

14 nm l : i sSo u rce nml - re s o urc e : link1 , nml -

res o urc e : li nk2 .

15 nml - re s o urc e : Rese r v a t i onLif e T i m e a nml :

Lif e tim e ;

16 time: h a sEn d nml - r eso u rce : s tar t T ime ;

17 time: ha s B e gin i n g nml - r eso u rce : enT i me .

18 nml - re s o urc e : st a r tTi m e a time: I nst a nt ;

19 time: in X S D D ate T i m e "2014-10-05T14

:00:00+00:00"ˆˆ xsd : d a teT i me .

20 nml - re s o urc e : en Tim e a time: I nst a nt ;

21 time: in X S D D ate T i m e "2014-10-05T15

:30:00+00:00"ˆˆ xsd : d a teT i me .

Listing 3: Example topology expressed in Turtle

(preﬁxes are omitted).

Various network components are connected to

Reser-

vationLifeTime

which is of type

Lifetime

, to in-

dicate the lifetime of those nodes. This represents a

reservation of network resources for certain duration.

For example, in 3 the reservation is for one and half

hours between

14:00:00

and

15:30:00

. Based on

this data, a system administrator can view all unre-

leased network resources which have been reserved

after the beginning of October and are still active, in

order to release them. Unreleased resources can be

checked as in 6, which is translated into SPARQL in 2.

6 SemNaaS FEATURES

Interconnection of Distributed NaaS Instances.

One signiﬁcant feature that Semantic Web adds to

NaaS, is the support of establishing multiple dis-

tributed NaaS instances and interconnecting their re-

spective components with ease. One major challenge

OpenNaaS has faced before SemNaaS, was how to

maintain the uniqueness of the IDs assigned to the

various network components, in order to interconnect

them whenever required. In other words, each net-

work component, e.g. network node, has an ID that is

only unique within the boundaries of the OpenNaaS

instance in which it resides. That introduces an ob-

stacle in connecting the components of two remote

OpenNaaS instances. Semantic Web depends on using

URIs (Uniform Resource Identiﬁer) as an enabling

technology. Since we use the NML ontology to de-

scribe networks provisioned by OpenNaaS, we should

assign a unique URI to each component, which plays

the role of a global identiﬁer.

In our case we use

http://ivi.fnwi.uva.nl/sne/

and

http://www.i2cat.net/

as base namespaces

for the OpenNaaS instances hosted in the University

of Amsterdam and i2CAT respectively. So, for

host1

as an example, the respective URIs will be

http://ivi.fnwi.uva.nl/sne/resource/host1

and

http://www.i2cat.net/resource/host1

Thus, those nodes instantiated by distant OpenNaaS

instances can be interconnected with no problem.

URIs Minting.

As mentioned before, URIs en-

able interconnecting several NaaS instances together.

Therefore, the process of minting those URIs should

be handled very carefully. SemNaaS also provides a

RESTful web service for creating URIs, which can be

used for referencing individual objects in the network

OpenNaaS provides.

The generated URI is based on the domain name

currently registered for SemNaaS. Thus, if the

NaaS provider can provide a locally unique iden-

tiﬁers, e.g. link1, the service can generate a

URI like http://ivi.fnwi.uva.nl/sne/resource/link1. On

the other hand, if the NaaS provider does not

provide such an identiﬁer, the service can cre-

ate the URI from scratch with the help of the

current timestamp. Example URI generated is

http://ivi.fnwi.uva.nl/sne/resource/1412684412000.

7 EVALUATION AND

EXPERIMENT

To demonstrate the advantages of SemNaaS, we dis-

cuss an example on how SemNaaS is used to meet

the speciﬁc challenges in a NaaS use case. The use

case shows how SemNaaS improves the functionality

of network resource provisioning and path ﬁnding of

OpenNaaS. This request passes several phases to get

fulﬁlled:

1. The user sends a request with the required details,

e.g. source and destination nodes, as illustrated

in Figure 6(a). The request is formulated in NML

SemNaaS: Semantic Web for Network as a Service

nml:topology

nml:Host1

nml:Location1

nml:Host2

nml:Location2

Amsterdam

Barcelona

nml:hasNode

nml:locationAt

nml:address

nml:locationAt

00:00:64:87:88:

58:f6:57

nml:DPID

00:00:24:37:84:

58:f8:77

nml:DPID

(a)

nml:topology

nml:Host1

nml:Host2

nml:Link1

nml:SW1

nml:hasNode

nml:isSink

nml:isSource

nml:Link6

nml:SW4

nml:link7

nml:SW5

nml:hasNode

nml:link8

nml:isSink

nml:isSource

nml:Path

nml:belongToList

nml:next

nml:belongToList

nml:next

(b)

Figure 6: An example request (a), and reply (b) in the virtual routing function use case.

and user should use the resource URIs, generated

via SemNaaS to refer to various network elements;

SemNaaS receives the request, validates it, and

uses SPARQL to check the connectivity of the

nodes, in order to make sure there is a certain path

between those nodes (cf. Section 5);

SemNaaS forwards the path ﬁnding request to

OpenNaaS for fulﬁllment, as discussed in the Sec-

tion 7.1;

After OpenNaaS calculates the path between

nodes, SemNaaS formulates the output response

in NML using Path class.

7.1 Virtual Routing Function

OpenNaaS interworks several types of OpenFlow con-

trollers to orchestrate network services on top of Open-

Flow infrastructures. An OpenFlow controller is an

application that manages ﬂow control in a SDN envi-

ronment.

The Virtual Routing Function use case aims to imple-

ment inter-domain routing through OpenNaaS over an

OpenFlow infrastructure. VRF ﬁnds out a routing path

according to the routing mode such as static, Dijkstra,

and then invoke the controllers to dynamically create

ﬂow tables of the switches on the path.

We developed a prototype to show the VRF function-

ality of OpenNaaS. The prototype includes a web

client GUI, which communicates with the capabili-

ties of OpenNaaS through REST APIs. We emulated

a Mininet network with a topology of 5 OpenFlow

switches and 3 hosts, shown in 4. The switches had

the same network capacity and controlled by Flood-

light controllers.

7 presents the sequence diagram of use case in our

emulated environment. A provider (SemNaaS in our

case) creates a set of abstract OpenFlow resources and

loads the OpenFlow capabilities for the resources us-

ing OpenNaaS (Step 1). After creating the resources,

the provider sets the controller information for the

network to build the connections between switches

and the controllers (Step 2). After that, the provider

sets the routing mode e.g. static or Dijkstra (Step 3).

At this point the provider submits a routing request

to OpenNaaS for a path between a source and a des-

tination (Step 4). OpenNaaS calculates the routing

path according to the speciﬁc routing mode (Step 4.1).

Then OpenNaaS interacts with the OFCs to create ﬂow

forwarding rules in the switches (Step 4.2). The SDN

controller ﬁnishes the ﬂow conﬁguration by executing

the modiﬁcation of the Route Table of switches. In the

end, the unstructured route path information is instan-

tiated by NML and returns to the provider if the ﬂow

rules are successfully created (Step 4.3 and 5).

4. Routing request

4.2 Create flow forwarding rules

4.4 Return the path

5. Path return

1. Create abstract network

2. Set SDN controller info

4.3 Modify the FlowTable

4.1 Calculate a path

3. Set routing mode

SemNaaS

OpenNaaS

OpenFlow

Switch

SDN

Controller

Figure 7: Sequence diagram for VRF functionality using

SemNaaS.

Both VRF request and reply require an information

model describing resources. SemNaaS can use NML

to describe resources in the request and reply. Fig-

ure 6(a) shows an example of a possible basic request

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

in the VRF use case. The request contains a start host

and a destination host. The nodes have different prop-

erties, e.g. location and IP address. As Figure 6(b)

shows, the reply from OpenNaaS components formu-

lated in NML, which is a routing path consisting of a

set of links and switches. Besides the description of re-

quest and reply, SemNaaS also validates the request for

users. It also avoids the VRF use case from receiving

wrong request and performing serious behavior.

8 CONCLUSIONS AND FUTURE

WORK

In this paper we described SemNaaS, an open source

Semantic Web based system for supporting Network

as a Service (NaaS). NaaS is a modern Cloud Comput-

ing paradigm which gives users easy control over the

networking resources. SemNaaS utilizes the Semantic

Web to add new features to NaaS systems, e.g. connec-

tivity checking. It fuses Semantic Web with Network

as a Service to develop an intelligent NaaS system.

The current version of SemNaaS uses OpenNaaS for

network provisioning, a free and open source NaaS

system. However, SemNaaS uses OpenNaaS only as

a pluggable component, i.e. it can be replaced by any

other NaaS provisioning framework. Furthermore, we

have also elaborated a use case, to show SemNaaS in

action, and demonstrate its various features for NaaS

provisioning.

We plan to continue our work on SemNaaS, and extend

it in several directions. First, SemNaaS uses URIs for

uniquely identifying the network components, which

opens up the door for interlinking those components

to the Linking Open Data (LOD) cloud (Bizer et al.,

2009). This is quite impressive because using the LOD

cloud, the metadata of a network resource is enriched

dramatically. For instance, for a router resource when

linked to the LOD cloud, the speciﬁcations registered

in SemNaaS will increase signiﬁcantly. Internet Topol-

ogy Data Kit (ITDK)

is an example potential dataset

for interlinking.

Moreover, we are contributing to the OpenMultinet

initiative (Willner et al., ), which leverages ontolo-

gies for interlinking heterogeneous networks

. That

enables describing various interconnected computing

infrastructures and cloud systems in RDF, thus help-

ing SemNaaS to control and manage heterogeneous

networks. It can also support the federation of multi-

ple testbeds, which might be in distant geographical

locations.

http://datahub.io/dataset/itdk

http://open-multinet.info

ACKNOWLEDGMENTS

This work was supported by the Dutch national pro-

gram COMMIT and by funding from the European

Community Seventh Framework Programme under

grant agreement n. 605243 (GN3plus).

REFERENCES

(2013). Deliverable D4.2 Software Development Report.

Project Deliverable Mantychore.

Arenas, M., Conca, S., and P

erez, J. (2012). Counting Be-

yond a Yottabyte, or How SPARQL 1.1 Property Paths

will Prevent Adoption of the Standard. In Proceedings

of the 21st international conference on World Wide

Web, pages 629–638. ACM.

Aznar, J. I., Jara, M., Rosello, A., Wilson, D., and Figuerola,

S. (2013). OpenNaaS Based Management Solution

for Inter-data Centers Connectivity. In IEEE 5th Inter-

national Conference on Cloud Computing Technology

and Science, CloudCom 2013, Bristol, United King-

dom, December 2-5, 2013, Volume 2.

Bizer, C., Heath, T., and Berners-Lee, T. (2009). Linked

Data - The Story So Far. International Journal on

Semantic Web and Information Systems, 5.

Costa, P., Migliavacca, M., Pietzuch, P., and Wolf, A. L.

(2012). Naas: Network-as-a-service in the cloud. In

Proceedings of the 2nd USENIX conference on Hot

Topics in Management of Internet, Cloud, and Enter-

prise Networks and Services, Hot-ICE, volume 12.

Dastjerdi, A. V., Tabatabaei, S. G. H., and Buyya, R. (2010).

An Effective Architecture for Automated Appliance

Management System Applying Ontology-Based Cloud

Discovery. In 10th IEEE/ACM International Confer-

ence on Cluster, Cloud and Grid Computing (CCGrid),

2010. IEEE.

Erling, O. and Mikhailov, I. (2007). RDF Support in the

Virtuoso DBMS. In Conference on Social Semantic

Web, volume 113 of LNI. GI.

Haak, S. and Grimm, S. (2011). Towards Custom Cloud

Services - Using Semantic Technology to Optimize

Resource Conﬁguration. In Proceedings of the 8th

Extended Semantic Web Conference, ESWC 2011.

Haase, P., Math

aß, T., Schmidt, M., Eberhart, A., and

Walther, U. (2010). Semantic Technologies for En-

terprise Cloud Management. In International Semantic

Web Conference.

Harris, S. and Seaborne, A. (2013). SPARQL 1.1 query

language. W3C Recommendation.

Hobbs, J. R. and Pan, F. (2006). Time Ontology in OWL.

Working draft.

Junghans, M., Agarwal, S., and Studer, R. (2010). Towards

Practical Semantic Web Service Discovery. In ESWC

(2), volume 6089 of Lecture Notes in Computer Sci-

ence, pages 15–29. Springer.

Minoves, P., Frendved, O., Peng, B., Mackarel, A., and

Wilson, D. (2012). Virtual CPE: Enhancing CPE’s

SemNaaS: Semantic Web for Network as a Service

deployment and operations through Virtualization. In

CloudCom.

Ngan, L. D. and Kanagasabai, R. (2012). OWL-S Based

Semantic Cloud Service Broker. In 2012 IEEE 19th

International Conference on Web Services, Honolulu,

HI, USA, June 24-29, 2012.

erez, J., Arenas, M., and Gutierrez, C. (2006). Semantics

and Complexity of SPARQL. In The Semantic Web-

ISWC 2006, pages 30–43. Springer.

Santana-P

erez, I. and Perez-Hern

andez, M. S. (2012). A

semantic scheduler architecture for federated hybrid

clouds. In Cloud Computing (CLOUD), 2012 IEEE

5th International Conference on. IEEE.

Sirin, E., Parsia, B., Grau, B. C., Kalyanpur, A., and Katz, Y.

(2007). Pellet: A Practical OWL-DL Reasoner. Web

Semantics: science, services and agents on the World

Wide Web, 5(2).

Stollberg, M., Keller, U., Lausen, H., and Heymans, S.

(2007). Two-Phase Web Service Discovery Based on

Rich Functional Descriptions. In Franconi, E., Kifer,

M., and May, W., editors, Proceedings of the 4th Euro-

pean Semantic Web Conference (ESWC), volume 4519

of Lecture Notes in Computer Science, pages 99–113.

Springer.

van der Ham, J., Dijkstra, F.,

apacz, R., and Zurawski, J.

(2013). The Network Markup Language (NML) A

Standardized Network Topology Abstraction for Inter-

domain and Cross-layer Network Applications. In Pro-

ceedings of the 13th Terena Networking Conference.

Willner, A., Papagianni, C., Giatili, M., Grosso, P., Morsey,

M., Al-Hazmi, Y., and Baldin, I. The Open-Multinet

Upper Ontology Towards the Semantic-based Man-

agement of Federated Infrastructures. In Proceed-

ings of 10th International Conference on Testbeds and

Research Infrastructures for the Development of Net-

works & Communities (TRIDENTCOM2015).

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science