A Graphical User Interface and Monitoring Component for Sem- NaaS

(1)

Bachelor Informatica

Universiteit van Amsterdam

A Graphical User Interface and

Monitoring Component for

Sem-NaaS

Samuel Norbury

June 17, 2015

Supervisor(s): Dr. Mohamed Morsey, Dr. Paola Grosso Signed: Dr. Mohamed Morsey, Dr. Paola Grosso

Inf

orma

tica

—

Universiteit

v

an

Ams

terd

am

(2)

(3)

Abstract

Monitoring is an important aspect and component of a Semantic-powered Network-as-a-Service system. Having a monitoring system that makes use of Semantic technologies such as ontologies and reasoners allows for more automated troubleshooting, and more intuitive logging. I have implemented a monitor and interaction system for SemNaaS, on top of a software defined network, to justify the necessity of such a system. The implementation shows that it is useful to have a monitor and graphical user interface for a Network-as-a-Service system that uses Semantic technologies as it allows for an automated feedback loop on the status of both the requests made by users and the underlying network resources.

(4)

(5)

(6)

(7)

Introduction

This chapter is based on the paper “SemNaaS: Semantic Web for Network as a Service” by Mo-hamed Morsey, Hao Zhu, Isart Canyameres, Samuel Norbury, and Paola Grosso that is under revision at ISWC 2015.

Cloud computing has become the de facto ICT platform over the past few years, owing to its scalability and accessibility for groups of developers of all sizes[1]. Cloud computing is an encompassing term: it describes both the applications shown to the end user as a tool, as well as the software running at the cloud service provider’s data center. These services or provision models are often grouped into a number of types, of which examples are Software-as-a-Service[2] (by far the most general group) and Infrastructure-as-a-Service.

A service amongst the other ‘as-a-Services’ that is still somewhat novel is the Network-as-a-Service, in which, instead of having a local network, a company will “outsource” its network hardware to an infrastructure provider, and the company merely needs an internet connection to work in the network. Paolo Costa et al.[3] describe NaaS as a strategy which enables the deploy-ment of dynamic infrastructures which support various applications, wherein each application has its own network usage technique.

Network-as-a-Service entails the benefits stated before, namely scalability and accessibility: this due to the fact that scaling the network up or down can be as easy as “drag & drop”, and the hardware can be accessed on a pay-per-use basis. To create such an interface, which focuses on that kind of intuitive interaction, implementation of Semantic Web technologies has been proposed.

The idea is to apply and use ontologies on Network-as-a-Service, to create a model for the interaction both by the user and machine with the service and underlying hardware, and to reason on the viability of such a network before querying its resources (thus detecting failure). SemNaaS, as the system is called, is currently implemented as a an application to OpenNaaS, an open source NaaS stack (more on OpenNaaS in section 2.1).

SemNaaS is a novel concept and more importantly an unfinished one. A number of issues that NaaS might deal with are considered in the OpenNaaS stack, but SemNaaS must therefore rely on the implementation of certain capabilities by the stack on which it runs to carry out certain tasks, e.g. monitoring the underlying hardware. OpenNaaS claims to implement these capabilities as a core component with an interface, but these capabilities are not sufficient. More importantly, the underlying network resources have a large part in shaping the monitoring component, as the type of underlying network decides what type of status-querying can be used (more on this is section 2.2). The subject of this research is the implementation of a monitoring component in SemNaaS, and how this should leverage Semantic Web technologies: the SemNaaS system will be using ontologies to describe the provisioned network, allowing for querying and report generation on the one hand, and failure detection on the other.

1.1 Research Question

My research highlights the need of a monitoring component for SemNaaS. The research question is therefore: Why would a monitoring component for a (Semantic) NaaS system be necessary?

This translates concretely in: How can a monitoring component be implemented to extend SemNaaS, and to what extent can it be used to detect problematic conditions? To answer this

(12)

question I implemented a proof of concept model of the monitoring component to extend Sem-NaaS, and tested this monitor on a number of (simulated) resource failures.

(13)

(14)

(15)

CHAPTER 2

Background

Following the short theoretical background in section 1, this chapter will discuss some of the work related to this research, as well as go into more detail on the key technologies and ideas that this research is based upon.

2.1 OpenNaaS

Much of this section is based on information found at http: // opennaas. org .

Network-as-a-Service, in which network resources are provisioned as pay-as-you-go building blocks for consumers, is one of the main ideas this research is based upon, but never actu-ally implements directly. OpenNaaS, on which SemNaaS is built, deals with the provisioning of network resources that defines the functionality of NaaS. OpenNaaS is, like many of the tools used in this research, an open source platform, and is the outcome of the Mantychore FP7 project[4]. The original developer of OpenNaaS is noted as the i2CAT Foundation[5].

OpenNaaS describes its structure as having three main functional layers: the Platform layer, the Resource layer also known as the NaaS layer, and the Network Intelligence Layer[6, 7]. This can also be seen in figure 2.1. The Platform layer sits directly on top of the “hardware” network resources, be they real or simulated, and interacts with them. On top of that, the NaaS layer abstracts the underlying network hardware as Resources with sets of Capabilities, that allow the upper layers to easily interact with the virtual interfaces of the hardware resources. The Network Intelligence Layer allows the end users (service providers) to tweak the provisioning model of the system to their liking by introducing rules to the provisioning system in the NaaS layer. Furthermore, the Network Intelligence Layer also allows the service providers to add their own interface to the system, where in the case of SemNaaS Semantic technologies have been introduced.

The Resources used in the NaaS layer are what OpenNaaS is based around. OpenNaaS comes with a range of Resource types predefined that correspond to a number of known hardware network resource types. On top of this, developers can define their own Resource types based on the SampleResource class that ships with OpenNaaS, which is described as “the skeleton for any new Resource”[8]. OpenNaaS then uses three classes that manage the Resources from start to end. Those are the ResourceManager, a Resource type-specific ResourceRepository, and the ResourceBootstrapper. Before any of these managers are called, the user must define a hardware resource in a descriptor, stating its type and capabilities. The ResourceManager then delegates the interpretation of the Resource descriptors to the Resource type-specific ResourceRepository. The ResourceRepository has a number of responsibilities[8]:

1. Translate a user-created descriptor into a Resource (virtual abstraction of hardware); 2. Persist the descriptor;

3. Manage the life cycle of the resource.

To reiterate: a user describes an underlying network hardware resource in the Network Intel-ligence Layer that is passed to the NaaS layer. The NaaS layer sorts (ResourceManager ) these descriptors based on resource type, and delegates interpretation to a ResourceRepository. The Repository translates the descriptor into a Resource instance, that, when it is provisioned at

(16)

Figure 2.1: The OpenNaaS application layers.

run time, is initialized by the ResourceBootstrapper. The Resource usually comes with a set of Capabilities, that are specified in the descriptor of the Resource, and are interpreted by the Re-sourceRepository. Finally, when the Resource is not required anymore, the ResourceRepository deactivates and optionally removes the Resource.

OpenNaaS is also described in terms of two core code parts: the core and the extensions[5]. The core of OpenNaaS can be understood as “a provider of basic functionality”, which translates to the basic code found in the Platform, NaaS and Network Service layers. The rights to anything added to this part must be relinquished to the original developer of OpenNaaS. The extensions are then anything added on top of the functionality of the core, and may be licensed privately.

2.2 Software Defined Networking

My research focuses not only on NaaS and the practical implementations of it, but also largely on the networks that the NaaS system interacts with. In this phase of the development of SemNaaS, the underlying network is a Software Defined Network. This section gives some background on that subject, and explains how OpenNaaS and SemNaaS would be able to interact with such a network.

Software Defined Networking is defined by the Open Networking Foundation as “the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices”[9]. In other words, in a software defined network, the routing behavior of network objects is not predefined in the network objects themselves, but in an umbrella controlling machine. The benefits of this are given[9]:

• Directly programmable: Network control is directly programmable because it is decoupled from forwarding functions.

• Agile: Abstracting control from forwarding lets administrators dynamically adjust network-wide traffic flow to meet changing needs.

• Centrally managed : Network intelligence is (logically) centralized in software-based SDN controllers that maintain a global view of the network, which appears to applications and policy engines as a single, logical switch.

(17)

• Programmatically configured : SDN lets network managers configure, manage, secure, and optimize network resources very quickly via dynamic, automated SDN programs, which they can write themselves because the programs do not depend on proprietary software. • Open standards-based and vendor-neutral : When implemented through open standards,

SDN simplifies network design and operation because instructions are provided by SDN controllers instead of multiple, vendor-specific devices and protocols.

Figure 2.2 shows the basic structure of Software Defined Networking. An application at the top layer defines a set of rules for a network, that are then passed to the SDN controller. At run time, when a machine in the application layer uses the network, the behavior of the hardware network resources is either retrieved from a cache when possible, or queried from the controller.

Figure 2.2: SDN Architecture.

OpenFlow is often mistakenly referred to as the equivalent of SDN because OpenFlow is the leading mechanism that allows for SDN, but any other similar system could replace it. OpenFlow was proposed in the 2008 paper “OpenFlow: Enabling Innovation in Campus Networks” by Nick McKeown et. al., in which OpenFlow is described as “a way for researchers to run experimental protocols in the networks they use every day”[10]. The original goal of OpenFlow was thus to turn a standard network into one that can be adjusted at any time for testing purposes.

Figure 2.3: The architecture of a switch in OpenFlow.

(18)

to all switches. A single rule in the control logic is referred to as a “flow”. A switch has a number of tables for flows, which follow each other in a specific order. The usage of the flow tables is as follows:

1. A packet, containing a number of header fields (such as source and destination IP) is received at a switch;

2. The switch tries to match certain fields in the packet header to those in its first flow table; (a) If the packet header fields matches with a certain flow in the first flow table, the action corresponding to that flow is carried out. This can mean it is sent further in the network, or sent to a next flow table where the process in step 2 is run again for that specific flow table.

(b) If the packet has no matching fields, the switch communicates over a secure channel with its controller, asking for an action to carry out. At this point either an action for the switch to carry out is returned, or the packet is dropped by the switch. Figure 2.3 shows the abstracted design of OpenFlow switches that corresponds to the above behavior.

A specific type of Open Flow switch is the OpenvSwitch, used in the testing phase of this research. OpenvSwitches are virtual switches that can run on the Open Flow mechanism, and can be controlled by any variety of Open Flow controllers[11]. The specific controller used in the testing phase is the Atlassian Floodlight controller[12].

2.3 Requirements for Monitoring SDNs

The idea of expanding NaaS is not novel per se, and similar research, that is building a Net-work Intelligence application on top of OpenNaaS, has been done before. In 2013, Jos´e Ignacio Aznar et al.[13] used OpenNaaS as a base for their Management Solution for Inter-data Centers Connectivity, and also included OpenStack in their solution. Though they did not use Semantic technologies, this research is quite similar to SemNaaS in both methodology and goal.

Furthermore, Pau Minoves et al. [14] used OpenNaaS to create a whole IP NaaS, arguing that it is beneficial for Customer Premises Equipment, and that these benefits “go from equipment purchasing cost to operations expenses and efficiency”. Though this research does not have a similar goal to SemNaaS or its monitoring component, it does show that OpenNaaS is quite a good framework to extend and to create more specific NaaS implementation with. It is also clear from this researches conclusion that a cloud-alike network provisioning service generates the previously mentioned benefits, namely scalability and cost-effectiveness.

Monitoring Software Defined Networks is a topic that is currently gaining traction in net-working circles, and that this research also touches on. In 2014, both Van Adrichen et. al. and Chowdhury et. al. proposed their own methods of monitoring SDNs using OpenFlow and mininet[15, 16]. Though the SemNaaS monitor is likely to monitor actual hardware, early ver-sions including this research’s implementation might not get further than SDNs. In fact, SR. Chowdhury et al. implemented their monitoring framework using the Floodlight controller, as will be used initially in this research. It might be an idea to use this framework, called Payless, in newer version of the SemNaaS monitor to retrieve statistics of the underlying network, but translation to Semantic data does not exist in any form, and must therefore be added to that framework.

In 2013, I. Bueno et al. created a software framework solution that guarantees Quality of Service in an SDN network, and that used OpenNaaS in its implementation[17]. Their implemen-tation provisions network resources to the user and relies on network status monitoring and SDN switches, much like this research, to be able to guarantee QoS. This research aims to, in many ways, implement the network monitoring that would be needed for the same goal, namely a guar-antee of QoS, but then on top of a Semantic OpenNaaS system, and with Semantic Technologies at the core of its functionality.

Ontologies can be applied to any technological paradigm and so they have also been applied to the mobile domain. In pursuit of the greater ontological picture, Claudia Villalonga et. al. set out

(19)

to create a standardized mobile ontology, interconnecting and combining all existing ontologies in the domain[18]. Their reasoning is that it is intrinsically difficult to ”find, use, map and evolve already existing ontologies”. Indeed, in this research, the aim is to reuse existing ontologies as much as possible, but classes and properties must be added to them, leaving it unclear in what manner they must be added. This research will therefore follow the three guidelines described in their paper when developing new classes and properties:

1. The ontology must be practically relevant;

2. The ontology must incorporate existing standards and ontologies; 3. The ontology must be extensible towards future relevant domains.

In this way, the ontology used in this research can sidestep the difficulty that comes with the use of ontologies, and will allow for easier future work.

(20)

(21)

(22)

(23)

CHAPTER 3

Semantic Technologies

This chapter aims to explain Semantic Technologies and their role in SemNaaS.

3.1 The Semantic Web

The Semantic Web is a concept first proposed by Tim Berners-Lee et. al. in the paper The Semantic Web in 2001, in which the authors describe the expectation for the existing web to evolve into the Semantic Web[19]. Berners-Lee described the Semantic Web as a method to allow artificial intelligence to truly understand the information displayed on a web page as a human would, instead of “merely displaying” information. The Semantic Web was to be a framework of description languages, much like HTML, that allowed for generalized, automated, machine-deducible rule-functionality.

At its core, the Semantic Web was designed to automate features of the web that are now limited to human understanding. An example of the information that is available in the Semantic Web but wouldn’t be available in regular HTML is given: a web page is presented that shows a list of items for sale from a bookstore. In HTML, the web browser can make very simple inferred assumptions on the information that is given on the page: the page has a certain title, and for every book there must be a visual container with a certain background color (as an example). For humans, it is clear after briefly looking at the page that we are looking at a list of books for sale, with their titles, authors and prices, while the HTML page only contains the information that the book title should be followed by a dash, and then the books author. Unfortunately, there is no functionality within HTML, or single program that can work with any arbitrary HTML page that can tell what the objects on the page are. In Semantic Web formats, the so-called meta-data about those little blocks of information, the books title, author and price, is saved in the page. This meta-data enabled markup can be stored in a number of formats, including but not limited to RDFa, Turtle and N-Triples[20, 21, 22].

The Semantic Web pages therefore hold the information of real-life objects, as well as the meta-data that describes what the information is. At this point, one might wonder where the specification of these objects and their properties is defined. The answer might not come as a surprise to those with experience in web-related industries: the meta-data is distributed across thousands of databases and is constantly being expanded upon and being added to. Meta-data can best be described as object and property descriptors, and will from this point on be referred to as ontologies. Ontologies map real-life objects and the properties that belong to them to a Semantic Web format that contains enough information for a Semantic document to be as understandable to a machine as it would be to a human. An example is given in figure 3.1, where a book is mapped to a Book Object, that has properties for the number of pages, the author, and the title of the book. These properties point to a literal (integer) number of pages, an Author Object (which has its own properties not shown here), and a literal (string) representing the title, respectively. The specification, usually a type of XML file, that describes these objects and their properties, is called an ontology. Creating a new object of a certain type is referred to as creating an instance with a certain type.

Ontologies are based on namespaces, URIs (Uniform Resource Identifiers) that belong to a certain database’s owner[19]. In other words, a namespace is a personalized URI in Semantic Web technologies that the user controls, granting him or her access to creating descriptors as well as instances with that URI, and therefore keeping all instances of objects and properties unique.

(24)

Figure 3.1: Abstract example of a book ontology.

To reuse the book example, we can imagine the University of Amsterdam has the namespace http://uva.nl, and that the mapping of the book to a Book Object might be described in the ontology http://uva.nl/MyBookOntology, wherein each object and property has a URI such as http://uva.nl/MyBookOntology#BookObject and http://uva.nl/MyBookOntology# hasTitle respectively. These URIs are thus made up of namespaces, often followed by an ontology name and a class/property name. An example of a namespace that has many ontologies using it is the Dublin Core, http://purl.org/dc/terms/, which has over 400 ontologies which other namespaces have claimed are somehow connected to theirs[23]. In figure 3.2, a graphical overview is given of the largest ontology namespaces, where their size translates to the number of ontologies. Ontologies are by and large stored in the OWL (Web Ontology Language) format[24, 25] (the type of XML file previously mentioned). For an example of an ontology, refer to appendix A.

The beauty of these Semantic Web ontologies is that they have a standard structure, they are reusable, and they are constantly expanding. Anyone can create ontologies for the data structures that they need, using their own namespace. On top of that, anyone can also expand existing ontologies to create more complete ontologies; it is recommended to reuse ontologies as much as possible[24]. This does not only mean that there are more and more ontologies being created every day, but also that information can be added, and is constantly being added to the existing ontologies. In Semantic Web, multiple different ontologies can be explicitly told to describe the same real-life object, which can give the mapping for that real-life object far more information than at first, and enriching all ontologies involved. The endpoint for this functionality is that all databases containing similar ontologies (for instance, describing a book) state that they are the equivalent of each other, or that they at least refer to each other in some way. The end goal is thus a complete, interconnected ontology of all things.

Semantic technologies don’t end at ontologies. As mentioned before, Semantic Technologies have their strength in the ability to not just store a more complete data set, but also understand it; it is due to the first ability that the machine-based understanding is possible. To deal with this functionality, code parsers, known as reasoners, are used. Reasoners can walk over any given data set in an RDF format and using a given, matching ontology as a reference, infer the properties and characteristics of (instances of) objects. In the book ontology example, if an arbitrary Object is connected to the Book Object via the property “hasAuthor”, a reasoner will assume that that Object is an Author Object, which is a subclass of a Human Object. In this way, anything connected via the hasAuthor property will be assumed to be a subclass of the

(25)

Figure 3.2: A graphical overview of the largest ontology databases, shown here as their prefixes (shortened URI’s).

Human Object or, if it is obvious to the reasoner that it is not, an error will be raised.

In his paper, Berners-Lee refers to Reasoners as Agents[19]. Examples of well known reasoners are the Pellet Reasoner[26], and the HermiT Reasoner[27].

3.2 SemNaaS

A number of advantages of using a cloud-based service are given: 1. Scalability - The user can scale up or down indiscriminately;

2. Guaranteed Quality of Service - The user can receive a certain service for a certain amount of money, no matter what.

Network-as-a-Service, and all other cloud services, usually provide the first possibility, where the user can always request more user accounts from an application, or more bandwidth from a server, as long as the cloud service provider has the capabilities. The second possibility, where the service is provided no matter what, is not directly addressed by the concept of cloud-based provisioning. A cloud resource might still break down, and some type of monitoring is needed to deal with the issue in a timely manner.

Semantic Web is an added benefit in this equation as it provides a reasonably easy way to do this monitoring with reasoners and inference. To give an example of this, let us consider the topology in figure 3.3, wherein the connection between Host1 and Host2 is not self-evident to a non-Semantic Web machine: it would need to perform some type of Ping command to check for connectivity, even though it might have the network topology at hand. A Semantic reasoner understands that the links between the different nodes are transitive, i.e. if A connects to B and B connects to C, A connects to C. Therefore it can deduce that Host1 is connected to Host2.

Just reasoning is not all the monitoring component needs to do: it needs to provide actions in case a requested network-topology cannot be provided. Though implementation of this is outside of the scope of this research, having a monitor does set the stage for future work in this

(26)

Figure 3.3: An example topology where connectivity between the two hosts is not self-evident. area. To reuse the example in figure 3.3, let us look at what would happen if the link between the two switches were to fail. In figure 3.4 this has happened and the reasoner has provided a new solution for the user, without ever needing human interference: the reasoner concludes that if a link between two switches is broken, the connections depending on that link are also broken, and therefore a new connection has to be constructed.

Figure 3.4: An example topology where a broken link is automatically rerouted.

The SemNaaS monitoring will compare the data queried from the triple-store graph to the network topology a user might want to use. An example can be given as follows: if a link is left idle for enough time, the SemNaaS monitor will notice, and warn the user that a link might be down with a percentage of certainty. Furthermore, the monitor can compare the requested number of nodes and links to the available underlying network, returning an error when the user requests too large of a network. Finally, the monitor can check the throughput of each link, allowing the network administrator to monitor usage, especially when a user goes over their allocated bandwidth.

(27)

(28)

(29)

CHAPTER 4

Implementation

I implemented two components: a graphical user interface for the SemNaaS and underlying OpenNaaS system, and the monitoring component itself. Furthermore, a specialized ontology was created for the montoring data. This chapter describes the two components and the ontology.

4.1 Requirements

In network monitoring, a number of key capabilities can be defined, for instance:

1. response time, which describes how long it takes from sending a request to it being served to the user;

2. network traffic measurement, which describes the performance of a network uplink. In NaaS, it may be important that these measurements (e.g., available bandwidth between two routers) and their implications (e.g., a router is unreachable or has failed) to be visible to the user, and to the cloud service provider. This research aims to implement two key monitoring capabilities:

1. Network traffic measurement on the underlying network (each connection); 2. Availability of network resources.

The reason that these measurements are important is that a cloud service provider provides an entirely abstracted service to the client, where the client often does not want to know what goes on under the hood. Monitoring and therefore responding to failures in a timely manner secures this type of unconditional provisioning. To make sure this response is timely, reasoning with regard to the network would provide real-time, logical conclusions with regards to the necessary network topology.

The OpenNaaS framework is defined as consisting of three layers of which the “top” one, the Network Intelligence Layer, is where SemNaaS would be situated as an application willing to manage the network. This Network Intelligence Layer sits atop the NaaS Layer which acts as a Hardware Abstraction Layer and exposes user manageable resources. Under the NaaS Layer is the Platform Layer of which the NaaS layer reuses the components defined in this layer. Figure 2.1 shows the OpenNaaS stack and its three layers (more on this in section 2.1).

The monitoring component of SemNaaS would place itself outside of the SemNaaS system, in connection with the shared database, and will interact directly with the underlying hardware. On the user side of the system, it could present itself as a graphical interface in which the capabilities mentioned previously are shown. Sections 4.2 and 4.3 go into detail on the design of the graphical interface and the monitor.

To give the user an intuitive response, this research also aims to develop the graphical inter-face, previously mentioned. This graphical user interface will use “drag & drop” style interaction to allow the user to interact with his or her topology.

There is of course the question, very specific to SemNaaS, of whether the ontologies already implemented in the SemNaaS system will be sufficient to convey the necessary information, or whether new ontologies will need to implemented. The system already has a large amount of data mapped to a Semantic model, currently. This research seeks to investigate whether new ontologies are required within that part of the system that has already been built to allow for monitoring capabilities.

(30)

4.2 Graphical User Interface

4.2.1 Requirements

The front-end of the SemNaaS system is envisioned to be a network-graph-drawing web-application, that can automatically query the constructed network at the click of a button from the Sem-NaaS system. The GUI should also implement Semantic reasoning on the constructed network to ensure it is a viable hardware set-up, and should be somewhat user-friendly.

Due to OpenNaaS being a Java program, SemNaaS is also written in Java, and this probably means that the web-app also needs to be written in Java. A number of useful tools for this project, such as Apache Jena, are all Java libraries. To speed up the development of the web-application, a Java web framework is probably helpful, as it deals with all the troubles of using Java instead of PHP in what is usually a LAMP (Linux operating system, Apache HTTP Server, MySQL relational database management system, PHP programming language) environment[28]. Furthermore, using Maven with the web-application should make it a lot easier to deploy the application[29].

The GUI should allow a user to construct a network using three different types of nodes: hosts, switches and routers. The nodes can then be connected using links (click + drag). On top of creating the topology, the user should also be able to change each node’s ID and optional label, change each link’s ID, and change the namespace used for, as well as the ID of the entire topology. Namespaces and URIs are explained in detail in section 3.1. The namespace of the topology relates the topology to the user requesting the topology, therefore keeping his or her data unique and not confusing it with other topologies.

When the user exports the graph, the application should automatically validate the created topology using a reasoner, given a certain ontology. The ontology to be used is the Network Markup Language (NML) ontology, developed by the Systems and Network Engineering (SNE) group of the UvA[30]. The reason for this being so certain is that the topology holds all necessary network objects. Should the ontology not be good enough, which is to say that it misses certain descriptors, then it can be extended. The ontology is available at https://bitbucket.org/ uva-sne/indl/src/master/nml.owl. This ontology describes the different object types that could be present in the topology, and the properties connected to these objects. Examples of such objects include nodes (hosts, switches, routers), links, and ports (belonging to nodes), while properties connect links to ports and ports to nodes, for instance.

The validator thus uses the rules defined in the ontology to check the proposed network, checking for instance whether an instance is both a link and a node, which is not possible as the two types are disjoint classes[31].

Finally, after receiving the topology from SemNaaS (not currently implemented) and having the monitor fill the Virtuoso error-graph with errors found in the underlying network, the GUI could query these errors and display them in the same location as it displays its validation errors.

4.3 Monitoring Component

The SemNaaS monitoring component is intended to be an add-on to the existing SemNaaS system, in such a way that both can work independently, but also cooperatively. To this end, the monitor is present on the machine that SemNaaS is hosted on, and likely run by SemNaaS, but functionality of the monitor is as independent as possible from SemNaaS.

The monitor must check the underlying hardware resources for failures. In section 4.1 the two capabilities which this research set out to acquire were network traffic measurement on the underlying network (each connection), and availability of network resources. In other words: for each link in the network, the bandwidth has to be measured for the first capability, and the monitor has to check the reachability of each network resource periodically.

To make sure the monitor keeps working in a Semantic fashion, storage of the data acquired by the monitor is handled in a Semantic Web fashion: all information is translated to Semantic data, stored in a triple-store graph, and later queried to check functionality.

(31)

4.3.1 Requirements

Due to the interchangeability of the underlying network, the monitor needs to be coded in a generalizable manner, which allows the end-users to swap out the underlying network. In pursuit of this functionality I adopted the novel “pull-push-check”-design. In pull-push-check the functionality of the monitor is split into three parts, or steps, highlighted below:

1. pull() queries the status of network resource and bandwidth of links in the underlying network (be that of any type);

2. push() translates the data acquired in pull() to an RDF format and inserts it into an RDF graph (database);

3. check() runs a number of queries on the graph to compare the requested topologies from SemNaaS to the actual topology data from the pull()/push() steps, and checks that same data for obvious errors.

The monitor is therefore defined as a class (from now on referred to as “SemNaaSMonitor”) that is extended by a topology specific ”pull()-class” (from now on referred to as “TopologyMon-itor”).

The SemNaaSMonitor will run at a certain interval, as specified by the user in a “.ini” file, outputting its findings into SemNaaS’s triple-store, so that the system stays up to date with the underlying network. The timing of the monitor will determine how up-to-date it is: a longer time between measurements means less monitoring overhead but also less reliable status information. pull()

The pull() method is meant to be an “abstract” method that is custom made for each underlying network topology type. SemNaaSMonitor should leave this method open and empty, except for a warning message for when it is accidentally called by the TopologyMonitor.

The export format of the data acquired in pull() should be an ArrayList of Nodes and Links (both classes defined in the program) that are directly available in the SemNaaSMonitor, like static arrays. This means that none of the pull-push-check functions have return types, but that the information moving from one to the next is through the object-related ArrayLists.

push()

The push() method as well as the check() method are general in the sense that they don’t need to be extended but will likely work on every network topology. The pull() method should translate the data from push() into an RDF format and send it to the SemNaaS Virtuoso triple-store. The reason that this information is being sent to the triple-store before being queried again in check() is that doing it in this way creates a log of the topology, over time. Each time the monitor runs it outputs a new status for each network resource, and eventually all these measurements will create a log.

check()

The check() method should query the measurements taken in pull() and outputted in push() from the triple-store and compare them to the requested topologies from the front-end of SemNaaS. There are a few ways of comparing the requested topologies: the topologies can be put together and reasoned upon using a reasoner, or the underlying hardware data can be queried in such a way that return values imply failure.

In the implementation for this research, two different methods have been chosen to use in the monitor: both comparing the underlying network to the requested networks (relative monitoring), and checking the underlying network by itself (absolute monitoring). For the relative monitoring, the monitor will find the difference between the number of nodes and links requested by the user, and the number of available nodes and links in the underlying network. Should the underlying network have less objects of either type than are requested, the monitor will return an error specific to the GUI that has made that request.

(32)

In absolute measurements, there are a number of key values to look at to determine whether the underlying network is still functioning correctly, and those are the “state” field of each link, the idle times of each link, a throughput graph of each link, and the last seen field of each node. In a production model these readings on underlying networks would most preferably be mapped to the requested links and nodes in the users request. Due to OpenNaaS and therefore SemNaaS not providing this functionality yet, this seems impossible during the duration of this research. Instead, the monitor could return these “general errors” to all running GUIs, stating that they might affect the users functionality.

It is important to make use of the Semantic technologies involved in SemNaaS, and for the functionality of check() to rely on this. The functionality in this method should therefore only come straight from SPARQL, an RDF querying language that can be used for a triple-store graph [32], or from Semantic reasoners, as seen in the GUI. The check() method will mostly make use of SPARQL for its functionality.

4.4 Monitoring Ontology

The ontology used to define the monitoring data is a mixture of the previously mentioned NML ontology with some extra parts, as NML does not define monitoring concepts such as Bandwidth, or any type of Errors. Together they will form the SemNaaS-Monitoring ontology. To keep a set of data from a single run of the monitor together, the ontology defines Measurements and Readings. Measurements are a whole set of Readings, whereas Readings link the data being checked for (e.g. throughput) to a single network object (e.g. link).

The monitor must also create actual errors for network resources, or for the topology as a whole, based on the measurements performed. These errors should be distinguishable based on their type, and have a percentage of likelihood, based on for instance the time that a link is down. The errors will be subdivided into general and request-specific errors, both of which are derived from the superclass Error. Subclasses of more specific error types can then be derived from the general and request errors.

In section 2.3 a number of guidelines were given for creating an ontology. These were: 1. The ontology must be practically relevant;

2. The ontology must incorporate existing standards and ontologies; 3. The ontology must be extensible towards future relevant domains.

With regard to the first point, the ontology holds true: the NML ontology maps the hardware resources to logical classes and the properties used also make sense in comparison to a real network. Furthermore, by reusing NML, and a few other standard namespaces, the ontology shows itself to incorporate existing standards and ontologies. The Error class shows an example of how the ontology is extensible towards future relevant domains: in the event that more types of errors can be found based on (more) measurement data, then the ontology can be extended to support adding new errors. Concretely, the namespace of the generated instances can be defined in a “.ini” file of the monitor, along with the ontology types used to define the instance types.

(33)

(34)

(35)

CHAPTER 5

Results

Chapter 4 sketched the applications that needed to be implemented for this research, this chapter shows the end result of those implementation ideas. The source code for the SemNaaS graphical user interface and monitor are available at:

• GUI: https: // bitbucket. org/ samuelnorbury/ vaadin-semnaas-gui • Monitor: https: // bitbucket. org/ samuelnorbury/ semnaas-monitor .

5.1 Graphical User Interface

The graphical user interface was partially modeled after the open-source Psimulator2 graphical network simulator. The images used for hosts, switches and routers were taken directly from the application. The Psimulator2 repository can be found at: https://code.google.com/p/ psimulator/

The graphical user interface described in chapter 4 was constructed using the Vaadin open-source Java web framework[33], and the JUNG (Java Universal Network-Graph drawing) frame-work. Vaadin was chosen for its relative ease of use, and the fact that it has some community support (as opposed to other, dead, open source frameworks). JUNG was chosen because of its extensibility, which it has due to it using Java’s SWING.

The GUI went through a number of implementation changes before reaching its final shape: it was first developed in the Play Java framework, followed by the Ninja Java framework at which point Maven and Apache Jena[34] were added to it (seemingly impossible in Play), and finally ending up in Vaadin due to Vaadin allowing for better IDE support.

Figure 5.1 shows the web application in use, at its “endpoint”, which is when the web page has been loaded, the network drawer has been opened and a network has been drawn and exported/validated. The warnings in the web page are generated in the validation step, where first of all the entire topology is tested for inconsistencies with the defining ontology, and then each port is tested against each other port for at least an indirect connection. This is implemented to warn the user of unreachable parts in the topology, when there is no path between two ports. The web application has two other tabs in the page, one in which the user can upload a topology (for instance as an N-Triples file) and a final one in which the user can directly input a topology (in a number of formats). These two options are a lot less user-friendly than the network drawer, which allows the user to work intu¨ıtively with an actual image of the network, and allows for easier setting of object and topology properties, as shown in figure 5.2.

In the upper left menu, the user can choose to change between the three node types, and change to property editing-mode. In the property editing-mode, the user can change a number of fields for each component of the graph: the user can change the ID and optional label of each node; the user can change the ID, and maximum throughput (does not currently add functionality) of each link; the user can change the namespace and name of the entire topology; finally, the user can “export the graph” which is to say the user can query the network resources from the SemNaaS system, at which point the reasoner automatically verifies that the queried topology is viable. Validation means running a reasoner over the queried topology, using an OWL ontology to rule check it.

(36)

Figure 5.1: The Vaadin web application.

Figure 5.2: Editing the namespace in the network drawer.

5.2 Monitoring Component

For this research, two OpenvSwitch topologies were used. The first topology, shown in figure 5.3, is a very simple topology with two hosts and one switch in between them. This topology was chosen for its relative ease of use in fleshing out the implementation of the monitor, as I didn’t have to manually monitor ten different devices. The second topology is shown in figure 5.4. This topology is a full mesh network with three hosts and three switches. It was chosen due to its challenging structure, which gave the chance to thoroughly test the monitor.

Querying the status of underlying network resources could only be done via the OpenFlow controller, in this case a machine running Floodlight[35], using a RESTfull interface. Should SemNaaS be running on an actual network as opposed to a virtual one, then the pull() method would have to be overridden by extending the SemNaaSMonitor class. For this research, the pull() method was implemented inside of the FloodlightMonitor class that extends the SemNaaSMon-itor class. Creating and running a FloodlightMonSemNaaSMon-itor uses pull() from itself, and push()/check() from SemNaaSMonitor. The FloodlightMonitor, and all other subclass monitors, must call

(37)

super()

in their constructors.

Figure 5.3: Topology one: a direct switched link between two nodes.

To translate the data in pull() from OOP-data to an RDF format, in this case N-Triples, Apache Jena[36] was used. Apache Jena implements a simple method of creating Models with Resources and Properties (very similar to OOP), which can then be translated with a single method to N-Triples or any other RDF format. To push this information to the SemNaaS Virtuoso triple-store, the virt-jena provider[37] was used, which can push a N-Triples data set to a Virtuoso triple-store graph.

In this proof of concept model, the monitor used the JFreeChart package[38] to draw graphs of the queried monitoring results in the triple-store graph. I tested my implementation of the first topology (figure 5.3) as follows: host 1 was made to send packets to host 2 using iperf, using the following command:

iperf -c 10.0.0.2 -b 100M -t 50000

With host 2 acting as the iperf server. The switch’s flow table in between the two hosts was configured with two static flows, and at one point the link between the switch and host 1 was briefly cut, and then reinstated. What follows in figure 5.5 are the throughput values for each link. The single line links in figure 5.3 between two network objects correspond to two graphs above each other in figure 5.5. Each graph is then a certain direction of a link.

There are a number of moments in the graph where the throughput approaches zero. This is due to the fact that the counter for the number of packets received and sent in the OpenFlow controller sometimes overflows with throughputs that are too high, resulting in the signed integer that holds it to wrap around. To solve this, the value returned was made to be no less than zero. The largest interval where the throughputs approach zero, in each chart at about 1/3 of the time, is where the connection was cut.

The charts are arranged as follows: the two left charts are the input and output of the link between host 1 and the switch, and the two right charts are of the link between the switch and host 2. The left charts show the connections between the switch and host 1, where a far higher throughput is being measured towards the switch, and the right charts measure the links connecting the switch to host 2, where there is a far higher throughput from the switch to

(38)

Figure 5.4: Topology two: a full mesh network with three hosts and three switches. the host. The difference in throughputs is due to the fact that iperf sends tcp packets with a throughput indicated by the user, in this case 100Mb/s, to the server and the server only returns acknowledgment packages, resulting in a far lower throughput in the opposite direction.

To really test the SemNaaS monitor, a more complex topology was created, as shown in figure 5.4. The topology consists of three switches and three hosts, where host 1 is connected to switch 1, switch 1 is connected to switch 2 and 3, and switch 2 connects to hosts 2 and 3. Switch 3 could act as an alternate route in this topology for when the connection between switch 1 and 2 should fail.

There are twelve throughput graphs for the incoming and outgoing traffic in each link. Figure 5.6 shows these graphs, in which a number of them (characterized by a flat line in the center of the graph) were actually down at the time of testing. The graphs that are showing throughput are measuring the stay-alive packets of the Floodlight controller interacting with the OpenvSwitches.

5.2.1 Error Reporting

The monitor does not only measure throughput, it also finds actual errors as described in chap-ter 4, and pushes these towards the Virtuoso error-graph (aptly named http://errors). The SemNaaS GUI can reach this graph, and read all the errors present in the graph that are either GeneralErrors or RequestErrors (see section 5.3 for details on the type of errors defined in the monitoring ontology) that deal with the topology created by the user in particular.

Figure 5.7 shows an example of this: the user has requested a topology that is too large for the underlying network, as seen in the first “Error”-type notification in the web interface. This notification is specific to the request’s namespace and topology name, and does not have a time limit after which it will not be shown. Of course, the user can always request a different topology that is provision-able. Furthermore, a number of links in the underlying network are predicted to be broken with a certain likelihood, as seen in the “Warning”-type notifications.

(39)

Figure 5.5: The throughputs for each direction of each link in topology one: (top left ) switch towards host 1, (bottom left ) host 1 towards switch, (top right ) switch towards host 2, (bottom right ) host 2 towards switch.

These warnings are only presented when they fall inside of a certain time frame or until they are resolved. In future work, this time frame might be connected to the average time it takes for SemNaaS to either fix or reroute a connection. The likelihood measurement is very simply calculated by dividing the number of measurements where the throughput of the link is zero by the total number of measurements. A base likelihood can be defined in the programs “.ini” file, allowing only errors with a likelihood above that number to be shown.

Note that all actual error logic all takes place inside of the SPARQL queries used to re-trieve monitoring data. In the case of the idle link calculation, the calculation of the likelihood takes place during the query, and can therefore directly be outputted to the error graph where necessary.

5.3 SemNaaS-Monitoring Ontology

As stated before in the requirements of the SemNaaS-Monitoring ontology in section 4.4, the ontology used to define the monitoring data is a mix of the NML ontology, a few more standard ontologies such those defined with the “http://qudt.org/vocab/unit” namespace, and a number of self-defined classes and properties. The most important classes in the monitoring ontology were also briefly touched in section 4.3.1, namely Measurements and Readings. A base concept of Semantic data is that unless explicitly stated, data is always inclusive. This is dependent on the Open World Assumption[39]. This means that if something is reasoned to be of a type it is thought to be of that type unless explicitly stated not to be of that type (which will result in an error).

The data queried from the network is largely the same on every run: the nodes are likely still connected to the same nodes, and their ID’s, in this case created from their MAC-addresses, will not have changed, leading to lots of duplicate data. To keep the data that does change

(40)

during the period of a single monitoring run together, such as throughput, but also referencing the correct network object, a wrapper had to be created for each object, as well as the entire monitoring run. This is where the Measurements and Readings come in: Measurements define an entire monitoring run, and Readings connect network objects to temporal reading data, with the isFor and hasValue properties.

The new classes that were added to the NML ontology, with the most important properties that apply to them are given below.

Measurement: Ties a group of Readings to an Instant, so that the Readings are known to be taken at a certain time. Important properties: hasReading, takenAt.

Reading: Connects a network object, whether that is a Link or a Node, to a measured value. An example is that a Link is found to have a certain throughput, or that a Node has a certain last-seen value. Important properties: isFor, hasValue.

ActivityTracker: Holds the last-seen value of a Node as an Instant connected to it. Important properties: inXSDDateTime.

Bandwidth: Combines an integer literal value with a unit type (in this case only ever Bits Per Second ) to create a bandwidth value for a Link. Important properties: hasMaxBandwidthValue, hasUnit.

Error: Superclass of all errors that connects an error type (its own type), an Instant, a network object or topology and a likelihood. Important properties: Type, isFor, takenAt, hasLikelihood. GeneralError: The first subclass of Error that is specific for an error that cannot be mapped to a requested network object or topology. Inherits important properties from its parent. Subclasses of GeneralError include linkDownError, which as the name might suggest, implies a link is down. RequestError: The second subclass of Error that is specific for an error that can be mapped to a requested network object or topology. This error is currently given when a user requests too large of a topology for the underlying network hardware. Important properties are inherited from the parent.

Figure 5.8 shows a overview like that in figure 3.1 of the monitoring ontology, where classes are squares, literals are circles, and arrows define both object properties and data properties.

An example of this Measurement-Reading construction is shown in the following output of a single run of the monitor, where it finds a link to have a bandwidth of 100Mb/s:

1 <h t t p : / / uva . n l / t e s t −m o n i t o r#r e a d i n g 1 >

2 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l / semnaas−m o n i t o r i n g / hasValue>

3 <h t t p : / / uva . n l / t e s t −m o n i t o r#bandwidth 1> . 4 5 <h t t p : / / uva . n l / t e s t −m o n i t o r#r e a d i n g 1 > 6 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l / semnaas−m o n i t o r i n g / i s F o r > 7 <h t t p : / / uva . n l / t e s t −m o n i t o r#l i n k 1 > . 8 9 <h t t p : / / uva . n l / t e s t −m o n i t o r#r e a d i n g 1 > 10 <h t t p : / /www. w3 . o r g /1999/02/22 − r d f −s y n t a x −ns#type>

11 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l / semnaas−m o n i t o r i n g / Reading> .

12 13 <h t t p : / / uva . n l / t e s t −m o n i t o r#l i n k 1 > 14 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l /nml /2014/10# h a s S i n k N e t w o r k O b j e c t > 15 <h t t p : / / uva . n l / t e s t −m o n i t o r#node 1> . 16 17 <h t t p : / / uva . n l / t e s t −m o n i t o r#l i n k 1 > 18 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l /nml /2014/10# h a s S o u r c e N e t w o r k O b j e c t >

(41)

19 <h t t p : / / uva . n l / t e s t −m o n i t o r#node 2> . 20 21 <h t t p : / / uva . n l / t e s t −m o n i t o r#l i n k 1 > 22 <h t t p : / /www. w3 . o r g /1999/02/22 − r d f −s y n t a x −ns#type> 23 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l /nml /2014/10# Link> . 24 25 <h t t p : / / uva . n l / t e s t −m o n i t o r#measurement 1>

26 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l / semnaas−m o n i t o r i n g / hasReading>

27 <h t t p : / / uva . n l / t e s t −m o n i t o r#r e a d i n g 1 > .

28

29 <h t t p : / / uva . n l / t e s t −m o n i t o r#measurement 1>

30 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l / semnaas−m o n i t o r i n g / takenAt>

31 <h t t p : / / uva . n l / t e s t −m o n i t o r#t i m e 1 > .

32

33 <h t t p : / / uva . n l / t e s t −m o n i t o r#measurement 1>

34 <h t t p : / /www. w3 . o r g /1999/02/22 − r d f −s y n t a x −ns#type>

35 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l / semnaas−m o n i t o r i n g / Measurement> .

36 37 <h t t p : / / uva . n l / t e s t −m o n i t o r#bandwidth 1> 38 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l / semnaas−m o n i t o r i n g / h a s U ni t> 39 <h t t p : / / qudt . o r g / vocab / u n i t#B i t s P e r S e c o n d > . 40 41 <h t t p : / / uva . n l / t e s t −m o n i t o r#bandwidth 1>

42 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l / semnaas−m o n i t o r i n g / hasMaxBandWidthValue>

43 ”100000000”ˆˆ < h t t p : / /www. w3 . o r g /2001/XMLSchema#i n t e g e r > .

44

45 <h t t p : / / uva . n l / t e s t −m o n i t o r#bandwidth 1>

46 <h t t p : / /www. w3 . o r g /1999/02/22 − r d f −s y n t a x −ns#type>

47 <h t t p : / / i v i . f n w i . uva . n l / s n e / i n d l / semnaas−m o n i t o r i n g / Bandwidth> .

48 49 <h t t p : / / uva . n l / t e s t −m o n i t o r#t i m e 1 > 50 <h t t p : / /www. w3 . o r g /2006/ t i m e#inXSDDateTime> 51 ”2015−05−20T1012 : 4 4 : 3 5 . 1 1 7 ” ˆ ˆ < h t t p : / /www. w3 . o r g /2001/XMLSchema#dateTime> . 52 53 <h t t p : / / uva . n l / t e s t −m o n i t o r#t i m e 1 > 54 <h t t p : / /www. w3 . o r g /1999/02/22 − r d f −s y n t a x −ns#type> 55 <h t t p : / /www. w3 . o r g /2006/ t i m e#I n s t a n t > .

A wrapping measurement 1 (its type is defined at line 33 through 35) that is takenAt (lines 29-31) instance time 1 (line 53), which holds a literal dateTime value (lines 49-51), also contains a reading 1 (line 9), referred to with the property hasReading (lines 25-27). The reading has a property connecting it to a network object, isFor (lines 5-7), and a property connecting it to a value that belongs to the object, hasValue (lines 1-3). hasValue can refer to a number of object-specific data holders, in this case bandwidth 1 (line 45), which hasMaxBandWidthValue (line 41-43) that points to a literal value, and hasUnit (lines 37-39), which points to a predefined Unit instance (Bits Per Second ) (line 39).

For the errors that are returned by the check() function of the monitor, another few classes were created: starting with the top class Error, it branches into GeneralErrors and RequestErrors, which were referred to as “absolute monitoring” and “relative monitoring”, respectively, in section 4.3.1. GeneralErrors then branches out with the subclass linkDownError, which, as the name might imply, warns that a link might be down. The classes all inherit the same isFor property from Error as used for the Reading class to describe the object they belong to, and have an Instant instance to describe the time they were created at. Furthermore, all error types also inherit a hasLikelihood property which points to a float (percentage) literal, describing the certainty of an error, based on the monitoring data. A graphical overview of the error classes in the ontology is given in figure 5.9.

As stated in section 5.2.1, in the GUI, GeneralErrors are shown to all users as warnings, but only when they fall within the pre-defined time limit. RequestErrors, on the other hand, are shown to the user who’s request they match, for as long as it takes for those errors to be resolved.

(42)

(43)

(44)

Figure 5.7: The graphical user interface displaying errors found by the monitor.

Figure 5.8: A graphical representation of the SemNaaS-Monitoring ontology, as can be found in appendix A. Classes and instances of classes are shown as rectangles, literal values are shown as circles, and data and object properties are shown as simple arrows.

(45)

Figure 5.9: A graphical representation of the Error classes in the monitoring ontology, as can be found in appendix A. The subclass/superclass relations are shown with ”picket-fence” arrows, and imply that the properties of the superclass (Error ) are inherited by the subclasses.

(46)

(47)

(48)

(49)

CHAPTER 6

Conclusion and Future Work

Using Semantic Technologies in a NaaS system allows for the system to automatically deal with network errors in the underlying network resources. The main philosophy behind the monitor is that it needs to remain largely independent from SemNaaS in terms of functionality, so that it can always be running, even when SemNaaS fails, but it needs to make use of certain typical Semantic technologies that SemNaaS also makes use of such as the virtuoso triple-store graph. To make this happen, I implemented the developed the following applications:

SemNaaS GUI The graphical user interface allows a user to easily construct a network using drag & drop interaction, can translate graphical topologies into RDF data, can validate constructed topologies before querying them, and can show errors generated by the monitor to the user in a clear and logical way.

SemNaaS Monitor The monitor uses the novel pull-push-check design specification, in which information is queried from the underlying network in pull(), outputted as Semantic, RDF data to the triple-store in push(), and in which the checking of the underlying network status happens in check(). More importantly though, there is hardly any functionality added in check() that is not either Semantics or SPARQL based. After check(), the monitoring data and the errors that are found from it are shown to the user using the SemNaaS GUI.

It is also clear that the monitoring component and graphical user interface can create that automated feedback loop necessary for SemNaaS: the user can easily query a network in the GUI, the monitor can correctly monitor the underlying network, and the two together can show the necessary errors to the user, back in the GUI. In fact, the GUI and the monitor worked so well that all drawn networks in this research were made with the GUI, and the graphs in figure 5.6 were used to find actual failures in the underlying network.

6.1 Future Work

The SemNaaS monitor requires testing on non-VM hardware resources. For this to happen, a new subclass of the SemNaaSMonitor needs to be designed that implements a network resource-specific pull() method. Furthermore, due to the limitations of the VM hardware resources, only very little data can be queried at all: real hardware might not have those limitations and could therefore allow for far more extensive network monitoring. In future work, the pull() method could also be expanded to work directly with the OpenFlow protocol as opposed to sitting a layer above the controller. That would make it so that it could work with any OpenFlow network resources, but also means it might need to implement OpenFlow controller functionality.

In the set of programs implemented for this research, the connection between the GUI and SemNaaS, and the monitor and SemNaaS is mostly missing: this due to the fact that OpenNaaS is in an early stage and there is a lack of clarity on what is and is not possible in the system. Though it falls somewhat outside of the range of this research, it has been found that entire topology provisioning by OpenNaaS is not supported yet. In a future version of the SemNaaS monitor and GUI, the monitor would match requested network resources to hardware resources (or in fact SemNaaS/OpenNaaS would) and be able to return more request specific errors to

(50)

the GUI. Currently, broken links in the underlying network are presented to all users as general, non-specific errors.

Finally, the SemNaaS monitor only issues errors, but does not solve them. Whether or not this is something the monitoring component itself should do, is an issue that should be discussed. For the SemNaaS system to reach its full potential this functionality needs to be implemented.

(51)

(52)

(53)

Bibliography

[1] Toby Velte, Anthony Velte, and Robert Elsenpeter. Cloud computing, a practical approach. McGraw-Hill, Inc., 2009.

[2] Mark Turner, David Budgen, and Pearl Brereton. Turning software into a service. Com-puter., 36(10):38–44, 2003.

[3] Paolo Costa, Matteo Migliavacca, Peter Pietzuch, and Alexander L Wolf. Naas: Network-as-a-service in the cloud. In Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services, 2nd USENIX conference on, volume 12. USENIX, 2012.

[4] Mantychore project. http://www.mantychore.eu, 2010. [Online; accessed 02-06-2015]. [5] Contributing, licensing and copyright. http://opennaas.org/documentation/

[6] Sergi Figuerola. Opennaas: an european open source framework for the delivery of naas; an enabler for sdn and nfv. http://www.glif.is/meetings/2013/tech/ figuerola-opennaas.pdf, 2013. [Online; accessed 02-06-2015].

[7] Opennaas software community. https://www.youtube.com/watch?v=ARFE2f-jauM, 2012. [Online; accessed 02-06-2015].

[8] Create a new resource. http://opennaas.org/create-a-new-resource/. [Online; ac-cessed 02-06-2015].

[9] Software-defined networking (sdn) definition. https://www.opennetworking.org/ sdn-resources/sdn-definition, 2015. [Online; accessed 03-06-2015].

[10] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. Openflow: enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 38(2):69–74, 2008.

[11] Ben Pfaff and Bruce Davie. The open vswitch database management protocol. 2013. [12] The floodlight openflow controller, 2015. [Online; accessed 03-06-2015].

[13] José Ignacio Aznar, Manel Jara, Adrián Roselló, Dave Wilson, and Sergi Figuerola. Open-naas based management solution for inter-data centers connectivity. In Cloud Computing Technology and Science (CloudCom), 2013 IEEE 5th International Conference on, volume 2, pages 75–80. IEEE, 2013.

[14] Pau Minoves, Ole Frendved, Bo Peng, Andrew Mackarel, and Dave Wilson. Virtual cpe: Enhancing cpe’s deployment and operations through virtualization. In Cloud Computing Technology and Science (CloudCom), 2012 IEEE 4th International Conference on, pages 687–692. IEEE, 2012.

[15] Niels LM van Adrichem, Christian Doerr, and Fernando A Kuipers. Opennetmon: Network monitoring in openflow software-defined networks. In Network Operations and Management Symposium (NOMS), 2014 IEEE, pages 1–8. IEEE, 2014.

[16] Shihabur Rahman Chowdhury, Md Bari, Reaz Ahmed, Raouf Boutaba, et al. Payless: A low cost network monitoring framework for software defined networks. In Network Operations and Management Symposium (NOMS), 2014 IEEE, pages 1–9. IEEE, 2014.

(54)

[17] Iris Bueno, Jose Ignacio Aznar, Eduard Escalona, Javier Ferrer, and Joan Antoni Garcia-Espin. An opennaas based sdn framework for dynamic qos control. In Future Networks and Services (SDN4FNS), 2013 IEEE SDN for, pages 1–7. IEEE, 2013.

[18] Claudia Villalonga, Martin Strohbach, Niels Snoeck, Michael Sutterer, Mariano Belaunde, Ern¨o Kovacs, Anna V Zhdanova, Laurent Walter Goix, and Olaf Droegehorn. Mobile on-tology: Towards a standardized semantic model for the mobile domain. In Service-Oriented Computing-ICSOC 2007 Workshops, pages 248–257. Springer, 2009.

[19] Tim Berners-Lee, James Hendler, Ora Lassila, et al. The semantic web. Scientific american, 284(5):28–37, 2001.

[20] Dave Beckett and Art Barstow. N-triples. W3C RDF Core WG Internal Working Draft, 2001.

[21] Eric Prudhommeaux, Gavin Carothers, Dave Beckett, and Tim Berners-Lee. Turtle–terse rdf triple language. Candidate Recommendation, W3C, 2013.

[22] Ben Adida and Mark Birbeck. Rdfa primer: Bridging the human and data webs. Retrieved June, 20:2008, 2008.

[23] Dcmi metadata terms (dcterms). http://lov.okfn.org/dataset/lov/vocabs/dcterms. [Online; accessed 03-06-2015].

[24] Liyang Yu. Introduction to the semantic web and semantic web services. CRC Press, 2007. [25] Deborah L McGuinness, Frank Van Harmelen, et al. Owl web ontology language overview.

W3C recommendation, 10(10):2004, 2004.

[26] Evren Sirin, Bijan Parsia, Bernardo Cuenca Grau, Aditya Kalyanpur, and Yarden Katz. Pellet: A practical owl-dl reasoner. Web Semantics: science, services and agents on the World Wide Web, 5(2):51–53, 2007.

[27] Rob Shearer, Boris Motik, and Ian Horrocks. Hermit: A highly-efficient owl reasoner. In OWLED, volume 432, 2008.

[28] Jason Gerner, Elizabeth Naramore, Morgan Owens, and Matt Warden. Professional Lamp: Linux, Apache, MySQL and Php5 Web Development. John Wiley & Sons, 2006.

[29] Frederic P Miller, Agnes F Vandome, and John McBrewster. Apache maven. 2010. [30] Mattijs Ghijsen, Jeroen Van Der Ham, Paola Grosso, Cosmin Dumitru, Hao Zhu, Zhiming

Zhao, and Cees De Laat. A semantic-web approach for modeling computing infrastructures. Computers & Electrical Engineering, 39(8):2553–2565, 2013.

[31] Liyang Yu. Introduction to the semantic web and semantic web services, chapter 5.5.1 Defining equivalent and disjoint classes, pages 118–119. CRC Press, 2007.

[32] Eric PrudHommeaux, Andy Seaborne, et al. Sparql query language for rdf. W3C recom-mendation, 15, 2008.

[33] Marko Gr¨onroos. Book of Vaadin. Lulu.com, 2011.

[34] Jeremy J Carroll, Ian Dickinson, Chris Dollin, Dave Reynolds, Andy Seaborne, and Kevin Wilkinson. Jena: implementing the semantic web recommendations. In Proceedings of the 13th international World Wide Web conference on Alternate track papers & posters, pages 74–83. ACM, 2004.

[35] Alexander Shalimov, Dmitry Zuikov, Daria Zimarina, Vasily Pashkov, and Ruslan Smelian-sky. Advanced study of sdn/openflow controllers. In Proceedings of the 9th Central & Eastern European Software Engineering Conference in Russia, page 1. ACM, 2013.

(55)

[37] A. Anil Sinaci. Virtuoso-jena provider. https://github.com/srdc/virt-jena, 2014. [On-line; accessed 16-05-2015].

[38] David Gilbert. The jfreechart class library. Developer Guide. Object Refinery, 7, 2002. [39] Nick Drummond and Rob Shearer. The open world assumption. In eSI Workshop: The

(56)

A Graphical User Interface and Monitoring Component for Sem- NaaS

Bachelor Informatica

Universiteit van Amsterdam