Bachelor Informatica

Evaluation of the NSI

Protocol for the

DAS-4 SystemGail Martoidjojo, 6049230

June 24, 2013

Supervisors: Dr. Paola Grosso and MSc. Ralph Koning

Signed:

Bachelor

Inform

atica—

UniversiteitvanAmsterdam

Abstract

In the past decades, cluster systems are increasing; especially around scientific environments this is an interestingdevelopment. DAS-4, designed for scientists and computer science organizations, is a six-cluster computerintended to perform research. The system has six clusters of which four are physically connected by a custom-made Fast Photonic Cross-Connect. Therefore, it is desirable to logically connect and disconnect clusters whenrequested by users and/or administrators. This project aims to investigate this potential functionality by meansof interfacing OpenNSA, an implementation of the generic protocol NSI. A recommended solution is to use thescalable OpenNSA software that implements the open standard NSI protocol. The software includes a clientand a webservice that requires a hardware specific resource manager. So, in this work the DAS-4 backend isbuilt. Furthermore, existing control code that manages the Fast Photonic Cross-Connect (FPX), is extended toallow for a more flexible functioning. For testing purposes and also because not all physical links between theclusters operate without difficulty, a simulation was created. In this way, DAS-4 backend and the extension ofthe control code can be tested and evaluated. Using this simulation, it may be stated that the NSI ConnectionProtocol and OpenNSA software are appropriate for the DAS-4 application to request and end a connectionbetween desired clusters, with variable attributes.

Contents

1 Introduction 31.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Project Background 52.1 DAS-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Python Control Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Proposed Solution 93.1 NSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 OpenNSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Code Development 144.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 Extension of the Python Control Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3 DAS-4 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4 Usage Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.5 Simulation of the WSS’s Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Evaluation 195.1 NSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 OpenNSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.3 DAS-4 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.4 Extension of the Python Control Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.5 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Conclusions 226.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

A Configuration Files DAS-4 Backend 24

2

CHAPTER 1

Introduction

The history of distributed computers originated in the 1960s and 1970s when the interest in computernetworks arose. With the purpose to enhance performance in computing, people wanted to connect computerstogether. Distributed computers were then designed to accomplish that goal [22].

DAS-4, the acronym for Distributed ASCI Supercomputer (see chapter 2.1), is a distributed system designed,however, with another intention which is providing computer scientists a common working environment toemploy research on. For example, the Parallel and Distributed Systems group of the VU University Amsterdamdid measurements on the DAS system regarding the BitTorrent peer-to-peer file sharing system, and also, PhDcandidates are doing their research on the DAS systems [12].

The DAS-4 has six clusters, located at five sites across the Netherlands, namely at the VU University,Delft University of Technology, Leiden University, the Netherlands Institute for Radio Astronomy (ASTRON)and the University of Amsterdam. This last site accommodates also the sixth The MultimediaN Consortium(UvA-MN) cluster. All clusters are connected both to the regular internet, using a Local Area Network (LAN).Four clusters are connected to SUFRnet’s photonic network, using a Wide Area Network (WAN). Because ofthis characteristic special hardware is needed to connect the clusters. For the WAN connection, each of theVU, Delft, Astron and UVA clusters are physically connected to a Wavelength Selective Switch(WSS) thatmanages the photonic data traffic. These four WSS’s are in turn linked to each other by the custom-made FastPhotonic Cross-Connect (FPX) built by the Technical University of Eindhoven (TUE) [13]. Thus, it is desirableto logically connect clusters when requested by users and/or administrators.

This project intends to investigate whether the functionality of requesting a connection between arbitraryclusters is possible, by means of interfacing the generic protocol NSI (Network Service Interface) [6] [15]. Theinterface considers a simple model of requesters on the one hand and providers on the other hand.

Another feature that the Fast Photonic Cross-Connect (FPX) permits is that a maximum of four linksbetween two clusters is feasible. With this project it is also the aim to examine the possibilities of enablingusers and administrators to allocate the desired number of links for a connection in order to increase bandwidth.

1.1 Problem Description

The DAS-4 system experiences a drawback where users and administrators are restricted in convenientlyacquiring a link between two clusters. In order to establish a communication between users and clusters, aprotocol is required. This project examines whether the OpenNSA software [21] that implements the universalprotocol NSI (Network Service Interface) [6], is suitable for the DAS-4 application.

At present there exists python code that controls the FPX and allows administrators to set up predefinedconnections between clusters [14]. However, the input to this tool is not yet generic, therefore, it is desired toextend it in order to receive arbitrary input. This way, users and administrators of the DAS-4 will be enabledto query any chosen connection. Interfacing the OpenNSA software, in other words implementing a specificDAS-4 resource managing backend, will then enable a generic functionality of the python control software.Within this project the research question is as follow:

“Is the NSI protocol suitable to manage the DAS-4 Fast Photonic Cross-Connect?”

Furthermore, subquestions are:

“How does the python control implementation work?” and

3

“Which of the OpenNSA modules are important for this project?”

A rather technical question in this thesis is:

“In which manner can the DAS-4 python control software be extended for users and admins in order to(re)configure connections between DAS-4 sites through interfacing the NSI protocol?”

1.2 Outline

The NSI, Network Service Interface, is a generic protocol that enables communication between multipleusers and resources in a heterogeneous environment [6].

This thesis presents the backend that is built on top of the webservice of OpenNSA [21], an implementationof the NSI framework, with the purpose to enable both users and administrators to acquire one or more linksbetween desired clusters on request.

Chapter 2 discusses the project background. That is, the theory behind the infrastructure of the DAS4-system (section 2.1) and the existing control code that configures the hardware of the DAS4-system (section2.2). Chapter 3 describes a proposed solution. Section 3.1 covers the theory of the NSI framework, followedby the description of OpenNSA, see section 3.2. Next, Chapter 4 describes the code development, startingwith a requirements section in 4.1. Chapter 4 covers in two sections the approach to extend the control code(section 4.2) and to develop the DAS-4 backend for the webservice of OpenNSA (4.3). Section 4.5 describesthe simulation for the developed code. Finally, the evaluation and conclusions are then respectively discussedin chapter 5 and chapter 6.

4

CHAPTER 2

Project Background

This chapter covers the project background and the motivation that led to this project. Section 2.1 describesthe DAS-4 system and some main characteristics such as its connectivity. Section 2.2 contains a description ofthe code that controls the DAS-4 hardware.

2.1 DAS-4

DAS-4 is the acronym for Distributed ASCI Supercomputer (where ASCI is the abbreviation for AdvancedSchool for Computing and Imaging) and the four indicates in which generation the system is. It is a systembuilt for the ASCI group for testing purposes and to employ computer science research on, such as experimentson new parallel and distributed algorithms and new computer systems [12] [3]. Research on large-scale multi-media content analysis, distributed, grid and cloud computing, communication software, parallel languages andprogramming systems is also being performed [12].

The ASCI group was the first Dutch graduate school in computer science to be accredited by the Royal DutchAcademy of Sciences (KNAW) and is constituted by several universities across the Netherlands such as VUUniversity (VU), Leiden University (LU), University of Amsterdam (UvA) and Delft University of Technology(TUD) [1]. Together with these academies, the MultimediaN Consortium (UvA-MN) and the NetherlandsInstitute for Radio Astronomy (ASTRON) collaborate to the realizations and achievements of the DAS-4.

In contrary to the first and second generation of the DAS, DAS-3 and DAS-4 have a hetergeneous charac-teristic. This means that the clusters are rather diverse from each other; for example, the number of nodes,storage capacity and node hard drives varies per cluster.

The clusters that compose the DAS-4 system are installed at these six organisations and are connectedexternally to the regular Internet with a LAN connection. Cluster nodes connect to the LAN through 1 Gbit/sEthernet, while the head uses 10 Gbit/s Eternet. Moreover, four clusters (at the VU, the UvA, the TUD andthe ASTRON) are also linked to one another using optical links of SURFnet’s photonic network [3]. The reasonfor this number of clusters relies on the number of transponders, and also wavelenghts, that SURFnet provisionsto the DAS-4 system [14]. Because of the network’s photonic character that permits bandwidth growth, therewas need for special hardware to dynamically configure network topologies. Configurations of these topologieswould establish an arbitrary number of links between two clusters, therefore, allowing bandwidth growth. Forthis purpose, the Technical University of Eindhoven (TUE) developed a custom-made Fast Photonic Cross-Connect (FPX) device [13] and a Labview software tool. This FPX links each cluster to one another via specialWavelength Selective Switches (so-called WSS’s) [14] and routes wavelength channels from an input port tothe desired output port. The WSS’s are then controlled by the Labview tool to configure these incoming andoutbound signals. Figure 2.1(a) depicts an overview of the architecture; the circles represent the WSS’s.

5

(a) Graphical representation of DAS4-FPX where the WSS’s are depicted bythe black circles

(b) Wavelength Division Multiplexing technique.

Figure 2.1: The DAS4-FPX and the WSS technique.

The (outer) blue rectangle indicates the clusters’ regular Internet connection and the green lines show thateach of the four clusters has a WAN connection to SURFnet’s photonic network.The diagram illustrates the logical configurations of the four clusters: VU, Astron, UvA and TUD (Delft Uni-versity of Technology) [14]. Every cluster has its own WSS, so, the FPX comprises four Wavelength SelectiveSwitches. The WSS’s principal feature is the Dense Wavelength Multiplexing functionality that realizes dy-namically routing and blocking of the light signals, also called wavelength. This DWDM technology enablestransmission of multiple wavelengths on one optical fiber; a mechanism that is proportional to bandwidthgrowth. Figure 2.1(b) depicts that a WSS has a single common input port and several output ports. The dif-ferent colors on the left indicate the different wavelengths which the WSS multiplexes to one of the ports on theright-hand side [17]. This mechanism also works in the opposite direction. In other words, multiple wavelenghtson the ports of the right-hand side can be multiplexed to the outbound port on the left. Information carrying,for example, four times the regular bandwidth, can be transmitted using the original amount of optical fibers[16].

This feature has its advantages for there is no necessity to use new fiber. Furthermore, it enables bandwidthgrowth for applications; a feature that is desired for the the DAS-4 system. On the management side, thisbandwidth aggregation is selectable: users and administrators would be able to select a desired number of linksin their connection with a particular cluster.

2.2 Python Control Code

As mentioned in section 2.1, the Technical University of Eindhoven delivered both hardware and softwareto control the WSS’s of the DAS-4 clusters. However, this software, a Labview program, did not completelysatisfy the needs to manage the FPX because it is not remotely controllable [14]. As a result, similar pythoncode was written that preserves the functionality of the Labview tool [9].

This python control code abstracts the four WSS’s in a list and labels a device by its serial number.Communication with the devices is carried out via python’s pySerial module, which makes it possible to sendcommands to (and receive from) the serial connected WSS. This is an advantage compared to the functionalityof the Labview tool because it is possible to control to hardware from a distance. Below is table 5.1 that showsthe commands.

6

Table 2.1: Used commands to communicate with the WSS’s.

SNO? Serial Number Returns the device’s serial number.

RPA? Read Pending Array Gets the pending status of the configuration.

RRA? Read Reconfiguration Array Returns the current configuration of all channels.

URA Update Reconfiguration Array Sends switching and attenuation settings to the de-vice for individual channels.

UPA Update Switch All Similar to URA but now with identical settings forall channels.

RSW Reconfigure Switch Changes configuration on a WSS.

As can be seen from table 5.1, commands with a question mark return the current status of the configurationof the channels that are allocated with different wavelengths. With the remaining commands the settings on theWSS’s can be reconfigured. Communication with the WSS’s occurs by means of a “Validated Serial Protocolwith Error Checking” to verify that commands are received correctly. The protocol ensures that commands aresent in the form of a strings that includes the correct checksum. So, prior to sending a request to the WSS’sthe control code calculates the checksum for the commands in table 5.1 and the corresponding arguments, ifany. Figure 2.2 depicts the request and responses of the WSS’s.

Figure 2.2: Diagram of the requests and responses of the WSS’s.

As can be seen, an SNO? request to a WSS is responded with a serial number of the WSS in question. Anexample of such a respond is: ^SN039874$FE20\r, where SN039874 is the serial number. The ^ $FE20\r arepart of the Validated Serial Protocol. The RPA? command in figure 2.2 is answered with a string, for example:21,2;19,2;20,2, that includes the channels used (21, 19 and 20) and the ports used (2). For clarity thechecksums have been left out of the diagram. To mention one last example: the URA commands sends theconfiguration string 22,4,0.0 to the WSS’s. In the control code this string is transformed to a dictionary, seelisting 2.1 for an example of another similar dictionary:

7

{’SN039874 ’: [[’21’, ’4’, ’0.0’], [’22’, ’4’, ’0.0’]],

’SN042680 ’: [],

’SN043946 ’: [],

’SN044017 ’: [[’21’, ’1’, ’0.0’], [’22’, ’1’, ’0.0’]]}

Listing 2.1: Example of a setting of the WSS’s.

This example contains the serial number of each WSS and the channels (21 an 22) and ports (4 and 1) tobe used. The 0.0 indicates the attenuation level of the channel meaning that this configuration should then beset on. Attenuation level 99.9 blocks a channel. The WSS’s channels with corresponding wavelengths are:

{ ’22’ : ’1558.173 nm’,

’21’ : ’1558.578 nm’,

’20’ : ’1558.983 nm’,

’19’ : ’1559.389 nm’}

Port one to four are in ascending order associated with the WSS’s of the VU, Astron, Delft and UVA. Then,with the URA command the control code can send these settings to the four devices in order to reconfigure theWSS’s to this state.

In listing 2.1, the functionality of the array is to connect cluster VU (WSS SN039874) with cluster UVA(WSS SN044017) using two links. To explain the array on according to the given example, the table next showsthe ports used and which serial number represents which DAS-4 clusters.

"SN039874" : "VU", 1

"SN042680" : "ASTRON" ,2

"SN043946" : "DELFT", 3

"SN044017" : "UVA", 4

So, the first line in listing 2.1 instructs the VU cluster to set up two links with the UVA cluster using thearbitrary chosen channels 21 and 22 and fixed port 4 because this port connects to the UVA WSS. Vice versa,the last line in the example links the UVA cluster with the VU cluster twice making use of port 1 (because thisis the VU port) and the exact same channels that are used in the first line. It is demanded to use the samechannel for the bidirectional connection between the WSS’s. The hardware’s characteristic also requires thatone channel per connection is used or two channels per two connections etc.

The arguments to the control code is a predefined set of such a dictionary. Similar dictionaries are definedas entries of a predefined list that is programmed hard-coded and of limited scope. However, with four devices,four channels and four ports, numerous permutations are possible.

8

CHAPTER 3

Proposed Solution

This chapter describes the suggested solution for the problem of the DAS-4 system requiring a resourcemanaging system. The NSI protocol offers us a way out. Section 3.1 describes it in detail and section 3.2 givesan overview of OpenNSA, one of NSI’s software implementation.

3.1 NSI

The NSI (Network Service Interface) protocol is the result of the collaboration of various groups and indi-viduals participating in the NSI Work Group of the Open Grid Forum. It is an open standard meaning that themembers are people from different organizations. For example, network engineers, computer scientists and/orresearchers, network theorists and network operators are involved in the realization of the NSI.

Interoperability issues is what has driven the Open Grid Forum to install the NSI Work Group whose focusis to formulate a generic network service interface. These recommendations concern several aspects such as theoperational environment and required messages and protocols. Figure 3.1 shows the old and current networkset up.

Figure 3.1: Interoperability issues of today’s network models [6].

This situation lacks a common service interface. As can be seen in the diagram, network service requesterssuch as Unicore [11] and GLOBUS [5] require so-called wrappers to request services from multiple networkservice providers. A suggested solution is depicted in figure 3.2 [6] where common requesters and providerssolve the problem of heterogeneity in the network. It is the aim of NSI to offer equal service capabilities andinterfaces everywhere.

NSI is a framework and offers a standardized way of requesting network services from network serviceproviders. It is the purpose for these (connection-oriented) services to interoperate on a global basis in aninter-domain provisioning manner. These service setups, then, need intra-domain configuration of the localnetwork resources [6]. So, the NSI allows communication between hetergeneous networks in an unambiguous

9

Figure 3.2: Interoperability solution [6].

way while specific hardware provisioning is still feasible. Another important feature of the NSI is that it dealswith inter-domain protocols. This means that a set of existing protocols are incorporated without modifyingthem in order to collaboratively establish end-to-end connection services. Furthermore, NSI’s framework adoptsa simple scalable network model with the following abstract elements:

1. Network service domainIn NSI a network is defined as a “service domain” that connects end points via a joint service.

2. NSAA Network Service Agent is a software module implementation that represents an NSI “service domain”and communicates with other NSA’s through NSI’s protocols. Depending on the network’s architecture,an NSA may be a Provider Agent or a Requesting Agent.

3. STPThe network service domain architecture includes Service Termination Points as endpoints through whichconnections can be allocated. In this way, user data may enter or exit the network through these points.In the context of intra-domain topology an STP distinguishes incoming data within one service domainbecause an NSI service domain may have multiple STP’s.

4. SDPA Service Demarcation Point is a pair of STP’s of two adjacent service domains. Accordingly, two STP’sof such a tuple correspond with one another and specifies a network-to-network interconnection betweentwo different NSI networks. The two STP’s have distinguishing names but are topologically similar (withmatching characteristics) because they represent the same point between networks.

5. ConnectionA logical path between two STP’s of one network service domain. By extension, end-to-end multi-domainconnections can be created because SDP’s enable linking two adjacent NSI connections to one another,see figure 3.3(a).

6. TopologyThe NSI topology defines a series of linked NSI service domains and STP’s and SDP’s necessary to set upconnections.

7. NRMFor intra-domain provisioning purposes a Network Resource Manager is necesarry since NSI only interfereswith inter-domain protocols. This NRM provides the internal resource managing.

This abstract network model is depicted in diagram 3.3(a).

10

(a) Abstract NSI’s service domains, STP’s and SDP’s (b) Peer model of requester and provider [18].

Figure 3.3: Abstract NSI network model.

Figure 3.3(b) gives a basic overview of NSI’s interface between a Requesting Agent and a Provider Agentof the peer model. It can also be seen where an NSA and a Network Resource Manager fits in the overview.Thus, an NSA may be a Requesting Agent or a Provider Agent. Fact is that the Provider Agent cooperateswith the NRM in order to reserve and provision network resources [18]. Again, this NRM does not belong toNSI’s definitions. However, communication between two NSA’s occurs by means of NSI’s firstly standardizedprotocol: the NSI Connection Service Protocol v1.0 . This NSI-CS is a webservice and includes the followingprimitives:

• ReserveA reservation request is sent by a Requesting Agent to the Provider Agent to instantiate a connection andreserve the resources with the specified attributes (time, performance or capacity requirements such asbandwidth). The Provider Agent sends a ReserveConfirm back as a respons. A Reserve request is usuallyfollowed by a Provision request.

• ProvisionThe Requesting Agent sends a Provision request to the Provider Agent when the specified connectionneeds to be allocated physically by the hardware. When confirmed by the Provider Agent data trafficmay then start. A Provision request may only occur after a Reservation.

• ReleaseThis request is sent by the requester if a connection can be pulled out of service because data trafficis not desired i.e. the reservation itself is torn down while the hardware configuration for the previousconnection stays intact (Terminate request terminates the hardware configuration). So, either a Reserveand Provision command may follow or a Terminate request.

• TerminateIf the connection is still in service it is first released so that the hardware data path that was reserved forthe connection can be freed.

Although NSI’s framework is theoretic, it has been implemented into several software packages such asOpenDRAC [7], AutoBAHN [2]and OpenNSA [18]. For this project, we work with the OpenNSA NSI softwareimplementation. A reason for this choice is that we prefer the python programming language which is also thelanguage of the OpenNSA software.

3.2 OpenNSA

OpenNSA is a Network Service Agent, one of the seven software implementations of the NSI framework [18]and thus, adopts the NSI abstract model. This assertion is reflected in the software modules that contain atopology database and parser, a client, protocol handlers and a webservice. A feature of the OpenNSA softwareis its scalability, meaning that it is suitable for any hardware infrastructure. In the context of intra-domainprovisioning, OpenNSA has several NRM’s (Network Resource Managers) interfaces such as: DUD (virtualdata plane), FTOS (Force10), Argia (a User Controlled LightPath UCLP tool), Brocade and JunOS (JuniperNetworks hardware) [21]. These interfaces form the backend for various hardware applications and handle the

11

intra-domain configuration of the local resources. So, OpenNSA’s webservice relies on an infrastructure specificbackend that configures the hardware. Like any other NRM’s mentioned earlier, we require a DAS-4 backendfor our DAS-4 resource manager.

The software and the backends mentioned earlier are available online and can be cloned from the githubrepository, see [21]. The software can be run with following installation dependencies:

* Python 2.6 or newer

* Twisted [10], a network engine based on events and callbacks.

* SUDS [8], a python SOAP client for webservices.

OpenNSA’s terminal-based client allows us to locally use the DUD virtual switch to execute the NSI-CS:reserve, reserveprovision, provision, release, terminate and query. Furthermore, (static) setupfiles are needed, such as: a mapping (.nrm), a topology (.owl), webservice description (.wsdl) and a config-uration file (.conf). A client specific file contains attributes a user fills in prior to requesting a connection.The .nrm file is a mapping from OpenNSA STP’s to backend ports. The .owl file is XML-alike and describesthe topology of the interconnected networks. A .tac file contains the start-up configurations of the serverand can be used with following command: twistd -n start_opennsa.tac where -n specifies the programto be executed on the foreground. The OpenNSA client’s name is onsa and can be run with, for example,the command: onsa reserve -p provider -r requester -s source-stp -d destination-stp. The com-mand onsa --help returns all the options the client offers.

Referring back to NSI’s concept of a “connection”, this feature is embedded in OpenNSA: a connection inOpenNSA is set up between two STP’s of one network. Reserving a complete path between two networks isaccomplished by reserving connections between the STP’s of adjacent networks. The same applies to provision-ing, releasing and terminating a connection. These four primitives are also state-transitions of the OpenNSAstate machine where the essential states are Reserved, Provisioned, Released and Terminated. Figure 3.4 givesa simplified overview of the state machine. Intermediate states such as Reserving, Scheduled and Released areleft out.

Figure 3.4: Reservation State Machine.

As mentioned before, the OpenNSA’s client recognizes several arguments of which the basic NSI ConnectionService primitives are a few [18]: reserve, provision, release and terminate. The reserveprovision

is also implemented to first execute the reserve command and then the provision command. OpenNSA’sscheduling system knows four essential states and these are explanained according to the essential NSI primitives:

1. ReserveAssociated arguments are:-r resourceprovider -s sourcestp -d destinationstp -a starttime -e endtime -b bandwidth,where the last three arguments are optional, the default starttime is the current time, the endtime is un-specified and the bandwidth is 10Gb. The “Reserve” command sets up a logical connection between twoNSI STP’s, reserves the resources and returns the reservation attributes (connectionID and globalID)to the user. OpenNSA includes a scheduler module and uses NSI-CS state machines to transition theconnection state, see figure 3.4 [18]. Thus, important state transitions for a logical NSI connection is the“Reserving” state which can lead to either a “Reserved” state when successful, or a “Reserved Failed”when unsuccessful.

12

2. ReleaseRequired arguments:-c connectionID -g globalID.This command may only be executed after a reservation (or reservation and provisioning) has been doneand requires the two types of reservationID’s: a reservationID and a globalID. The logical connection willthen be undone, while the resources will still be reserved.

3. ProvisionArguments:-c connectionID -g globalID.Considering NSI’s path creation, OpenNSA first sets connections up between STP’S of each involvedservice domain. In this way, a complete reservation and provision between networks (and thus clusters)can be created, see figure 3.3(a). In order to provision a connection first a reservation must be made towhich a connection-ID and global-ID are assigned. These ID’s are the required attributes to provision theconnection.

Furthermore, OpenNSA’s client adopts a reserveprovision command that performs both operations.

4. TerminateAssociated arugments:-c connectionID -g globalID.Here, the provisioned resources are freed. Almost similar to the release command: a termination can onlyexplicitly be requested if the reservation state is provisioned or released. However, the connection’s statemay also be transitioned to “Terminated” if a “Reserve” or “Provision” request fails.

13

CHAPTER 4

Code Development

This chapter covers the code developed in order to investigate whether requesting connections betweenclusters of the DAS-4 is feasible by interfacing the NSI protocol. The approach is to study both the pythoncontrol code and the OpenNSA functionality in order to find matching input and outputs of the tools. Boththe control and OpenNSA code are written in python, so it is evident to use this programming language forfurther code development.

First, section 4.1 formulates the requirements to which the program must comply. Next, the extension tothe control code is described in section 4.2 and section 4.3 describes the DAS-4 backend for the OpenNSAwebservice. The following figure 4.1 gives an overview of the set up where blue rectangles depict the projectfocus.

Figure 4.1: Architecture overview where the blue rectangles represent the project focus.

4.1 Requirements

In order to achieve the purpose of this project the developed code must satisfy the following requirements:

• With the OpenNSA’s client it should be possible to query a reservation, provision, reserveprovision, releaseor terminate between DAS-4 clusters with desired bandwidth and specified start and endtime. Witharbitrary given source, destination and channels given to the program, the proper connection between theappropriate clusters must be able to be reserved, provisioned, released and terminated.

• Service Termination Points are associated with channels.

• With a “zero” STP the program is given the opportunity to choose arbitrary channels. According tospecified bandwidth the program determines how many links and channels should be set up and used forthe connection.

• The limit of four wavelengths should be reflected in the number of links (and thus channels) that areavailable in the system and vacant channels must be announced to the user when an occupied channelwas desired.

• Error handling must be caught well and properly. Carefully planning the asynchronous code is necessary.

• The possibility to request three and four connections in one request must be excluded. We assume thatthe user has knowledge of the system and when a connection of three or four links is required he or shehas the ability and possibility to request one connection three times in a row instead.

• Extend the control code with a scheduler for the connections to be set up in the DAS-4 system. OpenNSA,on the other hand, also has a scheduler which can be used for the DAS-4 backend.

14

4.2 Extension of the Python Control Code

Section 2.2 presented a comprehensive description of the “original” control program; here we give a shortexplanation. The control code communicates with the WSS’s and reconfigures their settings such as changingthe topology. Both the ““original” and extended control code are terminal-based and the argument to the““original” control code is an entry of a predefined topology list. The entries of this list are dictionariesindicating the WSS’s configurations i.e. the topologies. So, a dictionary, in turn, consists of the serial numberof all WSS’s and the channels and ports to be used. An example of the two required arguments to this codewere: --set 3 -v, where 3 is the third entry (dictionary) in the topology list and v indicates the verbose level.Subsequently, using this code requires knowledge of how this list is composed.

The first implementation effort is to modify the argument to this code and make its functionality moregeneric. This can be achieved by introducing a function make_topo that constructs a dictionary according tothe arbitrary given source and destination cluster, the given number of links (which is optional with a defaultvalue of 1) and chosen channels, also optional. The source and destination are required. In case less channelsthan the number of connections are given, the remaining channels are chosen by the program. Arguments tothe control code are now, for example,

VU UVA --n 3 --w 19 20

where n stands for the number of connections between the source cluster (here, VU) and the destination cluster(here, UvA). Then, the associated WSS’s configuration array is:

dictionary A

{’SN039874’: [[’21’, ’4’, ’0.0’], [’20’, ’4’, ’0.0’],[’19’, ’4’, ’0.0’]],

’SN042680’: [],

’SN043946’: [],

’SN044017’: [[’21’, ’1’, ’0.0’], [’20’, ’1’, ’0.0’],[’19’, ’1, ’0.0’]]},

Section 2.2 presented the explanation to such an array. Creating a new dictionary requires keeping track ofthe serial number of the WSS’s that belongs to the source and destination clusters, the associated ports to theclusters and which channels are already in use. Keeping track of the channels used is necessary because it is anoptional argument to the code and it is allowed to give less channels than necessary. Also, occupied channelsmay not be used for another connection. The same applies to the ports used. A newly constructed dictionaryis saved into a topology list which is read by the rest of the modules that control the WSS’s configuration.Further communication with the WSS’s is done by the existing control code.

A second function that is added to the original control code is a sub provision 1 that calls the make_topo

function to create the new dictionary. This sub provision function also retrieves the current state that isreturned by the WSS’s. Next, it merges this current state with the new state that was returned by themake_topo function. For example, if the current state is dictionary A and the new state is a connectionbetween the Astron and UVA cluster:

dictionary B

{’SN039874’: [[’21’, ’4’, ’0.0’], [’20’, ’4’, ’0.0’],[’19’, ’4’, ’0.0’]],

’SN042680’: [[’22’, ’4’, ’0.0’]],

’SN043946’: [],

’SN044017’: [[’22’, ’2’, ’0.0’]]}

Then the resulting state of the WSS’s is:

dictionary C

{’SN039874’: [[’21’, ’4’, ’0.0’], [’20’, ’4’, ’0.0’],[’19’, ’4’, ’0.0’]],

’SN042680’: [[’22’, ’4’, ’0.0’]],

’SN043946’: [],

’SN044017’: [[’21’, ’1’, ’0.0’], [’20’, ’1’, ’0.0’],[’19’, ’1, ’0.0’],[’22’, ’2’, ’0.0’]]}

Because there are already three connections set up, only one is left be used. This also applies to thechannels. In dictionary B it can be seen that the same channel is used for both WSS’s and that the AstronWSS (SN042680) connects to UVA’s port (4). For the counterpart, the UVA WSS (SN044017) connects toAstron’s port (2). Merging this dictionary with the current one will give dictionary C.

1This is called sub provision because the DAS-4 backend also has a provision method.

15

Dictionary C will be the resulting state of the WSS’s and sending this state to the hardware is necessarybecause sending only dictionary B will block the state that corresponds to dictionary A. Next, both newdictionaries B and C are saved into a topology list.

Another essential function is the sub terminate function 2 which does the opposite of the sub provision

function. Given the source, destination, channels and number of connections, the corresponding dictionarycan be looked up in the topology list. Here, an implementation decision was made since it was also possibleto construct the dictionary, again (because it was already created in the sub provision function). Doingthe opposite of the sub provision function means retrieving the current WSS’s state in order to extract thedictionary that corresponds to the connection to be terminated. According to the given example above: if thecurrent state was represented by dictionary C and the connection between the Astron cluster and UVA clusterneeds to be terminated (dictionary B), then the state that will be sent to the WSS’s is dictionary A.

Thus, during provisioning the extended control code saves the dictionary into the topology list and retrievesit back when terminating. These “ingoing” and “outgoing” dictionaries represent the state that are to be sentto the hardware.

4.3 DAS-4 Backend

As mentioned in chapter 3.2, OpenNSA’s webservice relies on an interface that provides local resourcemanaging. The same applies to the DAS-4 system. Section 4 contains a diagram of the set up (figure 4.1). Forour client side we also use OpenNSA’s client which is explained in section 3.2.

The first step is to change the OpenNSA required configuration files for the DAS-4 application; these filesare:

1. das.nrmThis file defines the mapping of the OpenNSA available ports, also called STP’s (Service TerminationPoints), to physical backend ports for the network topology. For the DAS-4 application we have defined20 STP’s: five per cluster. For example urn:ogf:network:stp:DAS4:VU22 "VU_22" represents themapping of STP 22 of the VU cluster to the VU 22 DAS-4 backend port.

2. das.owlIn the context of NSI, this is the topology file with an XML presentation syntax that specifies the set ofinterconnected Network Service domains. For the OpenNSA software (and also the DAS-4 application),this file defines the interconnected clusters and STPS’s. In contrast to the definition of NSI’s abstractmodel, we do neither define four NSI “service domains” nor SDP’s. The das.owl configuration file definesone NSI network: the DAS-4, which has the five STP’s of each cluster. Instead of diagram 3.3(a) in section3.1 that includes NSI’s service domains, STP’s and SDP’s, we now have the DAS-4 setup as follow:

Figure 4.2: Network model of the DAS-4 backend.

3. opennsa.confThis file is a standard OpenNSA file and contains the configurations for the server. The only change is tospecify the DAS-4 backend.

Finally, a client file specifies client specific options which can also be entered in the terminal.Given that the OpenNSA software is implemented using the open source twisted defer library, and the DAS-4

backend will be its resource managing system, knowledge of this defer callback mechanism is required. That is

2Also called sub because the DAS-4 backend has a terminate method.

16

because error and callback handling should occur carefully. For the DAS-4 backend the classes DAS4Backend,DASConnectionManager and DASConnection are implemented:

• DAS4backendhas attributes such as a DASConnectionManager object and a PXC object, class methods are:

– createConnection calls canAllocateLink and creates a DASConnection object.

– canAllocateLink checks if the reservation can be made and returns True if so.

• DASConnectionManagerupdates the log of the DAS-4 backend and has the following methods:

– setupLink writes a message to the log that a link between the source and destination port has beenset up.

– teardownLink similar to setupLink but now for the teardown case.

• DASConnectionmanages a connection state with attributes like: source port, destination port, state, a scheduler and apxc. This class also uses OpenNSA’s scheduling module. Class methods are:

– reserve tries to switch the initial state first to the reserving state and then to the reserved state.This is because an initial state can only be transitioned to the reserving state. Upon success,the reservation is scheduled using OpenNSA’s scheduling module after which the state is scheduled.The reserve method also keeps track of the (number of vacant) channels used and reports errorswhen:a the maximum number of links is reachedb differing STP’s are requestedc an occupied channel is requested

b fails because of the association of STP’s with channels and the hardware demands one channel forone connection. c reports the vacant channels back to the user.

– provision first does a time check of whether the end time has not already passed. This case reportsan error. The start time is also checked and when it has already passed, an immediate doProvisioncall is made, else a state transition is done. This transition calls doProvision when the current timeis equal to the start time.doProvision extracts the source, destination, list of channels and number of links, does some validchecking and calls the sub provision function in the extended control code which does the remainingcommunication with the WSS’s.

– release tries to switch the scheduled or provisioned state to the releasing state. Upon success,the connection’s state is scheduled, else the state is terminated and an error is returned. Thismeans that a connection can be released after it has been reserved or provisioned.

– terminate extracts the attributes needed to feed it to the sub terminate function that carries outremaining work. The connection’s state is transitioned to terminated after which the connectionstate is cleaned up.

The provision and terminate method, then, respectively call the sub provision function and sub terminate

function of the extension of the control code. Figure 4.3 gives a short overview of the developed code.

17

Figure 4.3: Architecture of the developed code.

4.4 Usage Instructions

The developed code is available online and can cloned from bitbucket’srepository https://bitbucket.org/gailm/bachelor.git [4]. Running the code can be done using the simu-lation. Installation requirements are: python 2.6 or 2.7, pySerial and argparse (for python 2.6 it’s includedin 2.7). Both can be installed using easy install or pip [9]. The code includes OpenNSA’s software [21] whichrequires: Twisted [10] and SUDS [8].

User dependent atributes should be changed in the opennsa-cli file and should reside in the home directory.In the OpenNSA’s client file onsa the path to the opennsa-cli file and wsdl directory should be changed. Thewsdl directory can be found in the cloned code. Starting OpenNSA’s webservice can be done with the command:twistd -y opennsa-test.tac. To reserve a connection between, for example UVA and VU, OpenNSA’s clienthas the command: python onsa reserve -s DAS4:UVA21 -d DAS4:VU21. This reservation has default valueof 10Gigabyte and is made for now with no endtime. The -s argument specifies the source STP and is aDAS-4 attribute defined in the das.owl topology file, see appendix A. The same applies to the -d argument thatspecifies the destination STP.

4.5 Simulation of the WSS’s Responses

The simulation captures the responses of the WSS’s by imitating the python’s pyserial module used in thecontrol code. Important components of this module are the read and write methods through which communi-cation with the serial connected WSS’s occurs. The read method reads bytes from the serial port and the writemethod writes string data to the port. A replication of these pyserial’s read and write methods are adjustedto capture WSS’s responses and requests locally. Then, instead of communicating with the WSS’s, the controltool communicates with the simulated code, for the convenience called pSerial.

The pSerial write method now receives strings from the contol code containing a command with optionalarguments; important commands are: SNO?, RRA, URA, RSW, UPA and RPA (see section 2.2 for an extensivedescription). When the control code sends an SNO? (Serial Number) request, the original pyserial write methodwrites this request to the port of the WSS’s after which pyserial’s read method can read the correct serialnumber. In the simulation, this string is identified by the pSerial write method and the corresponding WSS’sserial number is written to a local variable which can then be returned by pSerial ’s read. The RSW (ReconfigureSWitch), UPA (UPdate switch All) and URA (Update Reconfiguration aRray) commands return a "^OK$FF66"

signal, where FF66 is the checksum of the OK response. RRA? (Read Reconfiguration aRray) and RPA? returnthe appropriate topology dictionary in the form of a string with corresponding checksum. This dictionary issaved in a topology list which is read by the control code modules, see section 4.2. Furthermore, the returnedstring is, of course, captured by the “original” python control code. Reading via the simulation is evident: themethod returns the value of the local variable which was written by the write method. Figure 2.2 in section 2.2depicts the request and respons flow of the control code and the pSerial functions.

18

CHAPTER 5

Evaluation

This section gives a conceptual evaluation of the proposed solution: the NSI and the OpenNSA. See re-spectively section 5.1 [6] [18] and 5.2. Next, the developed code for the DAS-4 backend is evaluated in section5.3. Section 5.4 evaluates the extension of the control code and finally section 5.5 contains an evaluation of thesimulation used for testing the DAS-4 backend and the extension of the control code.

5.1 NSI

The purpose of NSI v1.0 is to provide a generic Connection Service (CS v1.0) protocol for network services.Adopting this protocol would save developing wrappers for various service providers.

NSI defines abstract notions of Service Termination Points and service domain. Within a service domaina STP is allowed to be used one at a time, meaning that one STP cannot be part of two connections. In theDAS-4 backend the STP’s are associated with channels, which are in turn associated with wavelengths. Becauseof hardware and physical reasons it is allowed to use one wavelength for one connection. For two connections,two (various) wavelengths are allowed, etc. NSI’s restriction of allowing STP’s to be used one at a time, leadsto the condition in the DAS-4 backend of using one wavelength at a time.

Another abstract notion the NSI defines is a simple but scalable topology that is represented in an XML-likefile. Decisions of the DAS-4 network model could easily be changed by modifying the entries in the topologyfile. This possibility is one of the reasons NSI is appropriate for the DAS-4 backend.

Furthermore, the NSI-CS v1.0 protocol defines primitives such as reserve, provision, release and termi-nate. For the DAS-4 application, these primitives are essential since it is an aim to enable DAS-4 users andadministrators to reserve, request and end a connection.

5.2 OpenNSA

OpenNSA is one of the NSI’s software implementations and provides a client and webservice. Since NSIaims for scalability, OpenNSA’s webservice is scalable. It can be applied to any hardware infrastructure andrequires merely a hardware specific resource manager. The scalability is convenient for the DAS-4 application,since the DAS-4 backend is the one main component that needs to be implemented. OpenNSA’s webserviceand client are two other useful components for the DAS-4 application.

OpenNSA also implements the main primitives of the NSI-CS protocol but since the NSI-CS v2.0 is a work inprogress [15] [20] NSI’s additional primitives such as modify and notify are not yet implemented in OpenNSA. Atpresent OpenNSA’s client does not support retrieving and modifying connection attributes. As a result, DAS-4users may not be able to request current connection states and attributes. Also, the client lacks robustnesssince incorrect arguments are not handled properly.

5.3 DAS-4 Backend

This section argues to what extent the requirements of the DAS-4 backend are met. Implementing theDAS-4 backend started with changing the default configuration files: .nrm, .owl and .conf. In the .conf fileit was only needed to specify which backend is desired, in our case: the DAS-4. For the .nrm and .owl files,however, it must be considered how many STP’s and NSI service domains the DAS-4 backend should have.Figure 3.3(a) depicts the theoretical design of 4 NSI domains but the design did not apply conveniently to theDAS-4 backend implementation. This is because 4 NSI service domains includes path creation between STP’s.

19

Error checking when reserving a connection between 2 STP’s of 2 service domains could only be done after theentire path has been created. A more convenient design is to define 1 NSI service domain: the DAS-4. Eachcluster was assigned 5 STP’s and are distinguished by the names, see figure 4.2. This is allowed and worksmore conveniently because error checking could immediately be done when reserving a connection. There wasno need for intermediate STP’s because all DAS-4 connections consist of only 2 STP’s. Appendix A shows the.owl file.

Error checking for connection set up was first done during the provision phase. This was not appropriatesince provisioning a connection could only be done after a reservation has been made. The provision commandrequires only connection-ID’s as its arguments. Therefore, failure during the provision phase (because connectionattributes were not correct) requires cancelling the reservation. Changing the connection atttributes can not bedone with a provision command; it requires releasing the reservation and reserving a new connection with thenew and correct attributes. So, an optimal solution was to move error checking to the reservation phase. Thisway, when the connection attributes were not right, a reservation was not even allowed to be created.

In order to test the DAS-4 backend and to obtain an impression of the possibilities several scenarios aregiven. With the simulated pSerial functionality it is now possible to run and test the DAS-4 backend locally.This way, we are able to check the correctness of the program by means of the obtained results. Proposedscenarios that are tested can be seen in table 5.1.

Table 5.1: Test cases.

case result

1 reserve and/or provision with a bandwidth thatexceeds the current number of links

negative, report back how many remaining linksare vacant

2 reserve and/or provision n links if number of used links is 4 - n: positive

3 reserve and/or provision five links negative

4 reserve and/or provision a connection with an oc-cupied channel

negative, report back vacant channels.

5 reserve and/or provision a connection with differ-ing channels

negative, report back that only similar channelscan be used.

6 reserve and/or provision, release and provisionagain

if one of the first four cases are satisfied: positive

7 reserve, terminate positive

8 reserve, provision, terminate, reserve again if one of the first four cases are satisfied: positive

9 reserve, provision, release, terminate, reserveagain

if one of the first four cases are satisfied: positive

In all cases it is necessary to extract the source, destination and desired channel in the correct form, switch tothe correct state, to report potential errors properly, keep track of the number of used connections and removeany redundant scheduled reservations of connections. For case 4 it is necessary to also track which channels arein vacant. Reporting errors is done with function errbacks, since the OpenNSA’s software is based on Twisted’sdefer callback mechanism. For example, when a reservation has already been made in OpenNSA’s webservicebut fails because conditions in the DAS4 backend have not been satisfied, the errback mechanism cleans up thenow false reservation. There, error handling must be done carefully also to capture future reservations flawlessly.Reserving and provisioning a connection can be either done separately or combined with the reserveprovisonprimitive. Both options work well and switching between states also works without difficulties.

An additional attribute a DASConnection object may contain is its corresponding dictionary/WSS state.Such an object is created when a reservation is made and can therefore be provisioned and terminated. So,during the provision phase, the extension of the control code returns the WSS topology settings in the form of adictionary. These settings are then provisioned by the hardware. Adding the dictionary to its DASConnectionobject may have saved troubles in the extenstion of the control code, see next section.

Furthermore, DAS-4 users are limited in their running time on the clusters. It is a rule to occupy clusters

20

for a maximum of 15 minutes [3]. However, the DAS-4 backend does not take this constrain into consideration.Fortunately, it is a small modification in the code.

5.4 Extension of the Python Control Code

One of the functions of the extended control code is to construct a dictionary containing the source, des-tination, channel and port. Such a complex dictionary represents a topology setting for the WSS’s. When anew connection is provisioned, the current WSS’s state is merged with the incoming state. This merging occurswithout difficulty and both the incoming and resulting state are recorded in a list instead of in an object. Adrawback of this (easy) approach is that the list may enlarge as new connections are provisioned. However,connections will also be terminated. When terminating a connection the terminating state is extracted fromthe current state. Then, the resulting dictionary is the resulting state of the WSS’s. The problem of a possiblygrowing list is solved by removing the associated dictionaries (the terminating state and the resulting one) fromthe list when a connection is terminated. Therefore, a balance is made by shrinking the list.

A proper solution would rather be adding the dictionary to its corresponding DASConnection object (seefigure 4.3 and preceding section). The current WSS’s state can be returned by the WSS’s, and for simulationpurposes the current state can be held in the PXC object (The PXC class is part of the “original” control code).For the live-test saving the current state in the PXC object may also be an advantage because the WSS’s havea slow respond time. So, another possible extension to the control code was to add the states of the WSS’s tothe class PXC of the control code.

Attaching the current state of the WSS’s to the PXC class would save the trouble of updating the list ofdictionaries. For example, when terminating a connection the corresponding dictionary must be found in thelist because it was saved during the provision phase. For safety reasons, if the entry is not present in the list,a new dictionary is created. The difference between the current state and the terminating state may then beextracted.

5.5 Simulation

Since only the physical link between the VU and UVA cluster operates without complications, live-tests onthe whole system are not possible. So, both the extended control code and DAS-4 backend are tested using asimulation. In this way, it can be retraced how the requirements can be met.

The simulation is a replication of pyserial’s write and read methods and should imitate the responses of theWSS’s. One of the WSS’s responses are returning the current state. In the simulation this state is tranformed toa dictionary and saved to a list. Running the program in the simulation first worked well because an arbitraryrequest gave correct output. An arbitrary request could be reserve, provision, release or terminate with allpossible allowed attributes. A reservation followed by a provision request gave the corresponding dictionary.For a provision the provision dictionary and the new current state were saved in the list. The simulation isdependent of this list, making the list essential for the simulation.

However, running the DAS-4 backend on the real hardware, the WSS’s, there were some complicationsconcerning the original pyserial write method. These complications were not known before because the simulatedpSerial did not imitate the responses of WSS correctly.

Adding the WSS’s state to the PXC class of the “original” control code would also save a lot of work forthe list that contains the topology dictionaries and would also ease writing the code for the simulation.

21

CHAPTER 6

Conclusions

This work investigated whether the NSI protocol is suitable for the DAS-4 system by developing a resourcemanager for the OpenNSA software, an implementation of the NSI framework. The OpenNSA software includesa webservice and like how the NSI protocol defines: the software must be suitable for any hardware architecture.This characteristic of NSI is one of the reasons it is appropriate for the DAS-4 system.

For the resource managing system we developed a DAS-4 backend on which OpenNSA’s webservice runs.Also, the DAS-4 hardware (Wavelength Selective Switches, WSS’s) was delivered with a graphical programmingsoftware tool. This tool was later on coded in the python programming language to control the WSS’s. In orderto link the DAS-4 backend with the hardware, we extended this existing control code to bridge the gap betweenthe resource managing system and the communication with the WSS’s. This extension includes a funtion toreceive arbitrary input and create the proper status to send to the hardware.

The main requirements for the DAS-4 resource manager is to reserve, provision, release and terminatean arbitrary connection between one of the DAS-4 clusters. Together with the extension of the control codethis functionality has been realized. Also, these primitives are defined by the NSI protocol and these arealso implemented in OpenNSA’s client. It is now possible to use OpenNSA’s webservice and client to worktogether with the DAS-4 backend and the extension of the control code. It may be concluded that NSI’s definedprimitives, and thus the protocol itself, is convenient for our DAS-4 application.

However, the requirement of excluding the possibility of requesting three connections in one hit has not beenimplemented. It is, fortunately, allowed to request one connection three times in a row. Also, a required maincomponent in the software is a separate scheduler for the extended control code. This project has used theOpenNSA’s scheduler which works well for the DAS-4 backend but leaves out the potential of building otherclients beside the OpenNSA client. Finally, we will continue solving the drawback of the simulation code toperfectly match the real WSS’s responses.

6.1 Future Work

At the moment, basic features have been implemented for the DAS-4 resource managing system. These,however, may be used as a basis for further developing. Additional functionalities may be:

• A (separate) scheduler for the control code.

• Several types of (graphical) clients.

If the first aspect has been fulfilled, the second one will then be possible to implement. With a separatescheduler the control code would be independent of the OpenNSA software which includes the possiblity todevelop other clients besides the existing (current) client. Since the OpenNSA software is open source it isallowed to use its scheduler as an additional component for the control code. The new clients can extend theexisting functionality of the DAS-4 backend by allowing commands such as requesting vacant channels andconnections.

Furthermore, extending the DAS-4 backend request commands will be feasible because NSI’s development(and thus also OpenNSA’s) is in progress. NSI’s additional primitives are: modify (the reservation characteristicssuch as bandwidth and end time), query (reservation attributes) and notify (error handling) [18]. The queryfunctionality would be very convenient for the DAS-4 application because it is not yet possible to request,for example, the connections’s attributes and the current state of the WSS’s. Both OpenNSA v2 and NSI-Connection Service Protocol v2 are work in progress [15] [19].

22

Bibliography

[1] ASCI - Advanced School for Computing and Imaging. http://www.asci.tudelft.nl.

[2] AutoBAHN - Supporting the Geant Service Portfolio. http://geant3.archive.geant.net/service/

autobahn/about_autoBAHN/Pages/About_autoBAHN.aspx.

[3] Distributed ASCI Supercomputer 4. http://www.cs.vu.nl/das4/home.shtml.

[4] gailm. https://bitbucket.org/gailm/bachelor.git.

[5] Globus Online. https://www.globusonline.org.

[6] NSI - OGF Network Service Interface. http://www.terena.org/activities/e2e/ws2/slides2/11_NSI_Eduard.pdf.

[7] OpenDRAC. https://www.opendrac.org/?page_id=178.

[8] SUDS. https://github.com/htj/suds-htj.

[9] das4 pxc. https://bitbucket.org/myzt/das4_pxc.git.

[10] Twisted. http://twistedmatrix.com/trac/.

[11] Unicore. http://www.unicore.eu/.

[12] Dick Epema. Computer science as an experimental science. EEMCS Faculty Magazine Quadraad, (2),2011.

[13] Prasanna A. Gamage, Roeland Nuijts, and Huug De Waardt. Degree-4 Photonic Cross-Connect for FlexibleProvision of Logical Configurations. 2011.

[14] Ralph Koning and Paola Grosso. Deployment of the DAS4 switch. Technical report, System and NetworkEngineering, University of Amsterdam, 2012.

[15] Tomohiro Kudoh, Guy Roberts, and Inder Monga. Network Services Interface - An Interface for RequestingDynamic Inter datacenter Networks. http://redmine.ogf.org/dmsf/nsi-wg?folder_id=6550.

[16] Jason Maassen, Paola Grosso, and Li XU. Het starplane-project: Applicatiespecifiek management vanoptische netwerken. Informatie Magazine, 2006.

[17] Dan M. Marom, Senior Member, IEEE, and David Sinefeld. Beyond Wavelength-Selective ChannelSwitches: Trends in Support of Flexible/Elastic Optical Networks. 2012.

[18] Inder Monga, Tomohiro Kudoh, Jeroen van der Ham, and Jerry Sobieski. Network Services Interface, Net-work Engineering Tutorial. https://github.com/jeroenh/NSI-Tutorial-Topologies/blob/master/

slides, January 2013.

[19] Guy Roberts, Tomohiro Kudoh, Inder Monga, Jerry Sobieski, John MacAuley, and Chin Guok. Nsiconnection service v2.0. http://redmine.ogf.org/dmsf/nsi-wg?folder_id=6526.

[20] Jerry Sobieski. The Network Service Interface - An Overview and Demonstration of: NSI Framework,SNI version 2.0 implementations, GLIF Automated GOLE. http://www.glif.is/meetings/2012/tech/slides/20121012-OGF36-NSI-AG.pdf.

[21] Jeroen van der Ham. Opennsa. https://github.com/jeroenh/OpenNSA.

[22] Barry Wilkinson. Grid Computing: Techniques and Applications, p. 4. Chapman and Hall, 2010.

23

APPENDIX A

Configuration Files DAS-4 Backend

The das.owl is an XML-like file that defines the NSI network topology. For the DAS-4 backend we havedecided to specify one network: the DAS-4 network. This is because it is possible and works more convenient.STP’s associated with a certain cluster can be merely distinguished by its name. We have STP 0 to 4 for eachcluster, see following code snippet:

<?xml version="1.0"?>

<rdf:RDF xmlns="http://www.glif.is/working-groups/tech/dtox#"

xml:base="http://www.glif.is/working-groups/tech/dtox"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:owl="http://www.w3.org/2002/07/owl#"

xmlns:xsd="http://www.w3.org/2001/XMLSchema#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dtox="http://www.glif.is/working-groups/tech/dtox#">

<owl:Ontology rdf:about="http://www.glif.is/working-groups/tech/dtox"/>

...

<owl:Class rdf:about="http://www.glif.is/working-groups/tech/dtox#STP"/>

<!-- urn:ogf:network:stp:DAS4:VU0 -->

<owl:NamedIndividual rdf:about="urn:ogf:network:stp:DAS4:VU0">

<rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/>

</owl:NamedIndividual>

...

<!-- urn:ogf:network:stp:DAS4:VU22 -->

<owl:NamedIndividual rdf:about="urn:ogf:network:stp:DAS4:VU22">

<rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/>

</owl:NamedIndividual>

<!-- urn:ogf:network:stp:DAS4:Astron0 -->

<owl:NamedIndividual rdf:about="urn:ogf:network:stp:DAS4:Astron0">

<rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/>

</owl:NamedIndividual>

...

<!-- urn:ogf:network:stp:DAS4:UVA0 -->

<owl:NamedIndividual rdf:about="urn:ogf:network:stp:DAS4:UVA0">

<rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/>

</owl:NamedIndividual>

24

...

<!-- urn:ogf:network:stp:DAS4:UVA22 -->

<owl:NamedIndividual rdf:about="urn:ogf:network:stp:DAS4:UVA22">

<rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/>

</owl:NamedIndividual>

<!-- urn:ogf:network:nsnetwork:DAS4 -->

<owl:NamedIndividual rdf:about="urn:ogf:network:nsnetwork:DAS4">

<rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#NSNetwork"/>

<rdfs:label xml:lang="en">DAS4</rdfs:label>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:VU0"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:Astron0"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:Delft0"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:UVA0"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:VU19"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:VU20"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:VU21"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:VU22"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:Astron19"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:Astron20"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:Astron21"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:Astron22"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:Delft19"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:Delft20"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:Delft21"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:Delft22"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:UVA19"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:UVA20"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:UVA21"/>

<hasSTP rdf:resource="urn:ogf:network:stp:DAS4:UVA22"/>

<managedBy rdf:resource="urn:ogf:network:nsa:DAS4"/>

</owl:NamedIndividual>

<!-- urn:ogf:network:nsa:DAS4 -->

<owl:NamedIndividual rdf:about="urn:ogf:network:nsa:DAS4">

<rdf:type rdf:resourc1e="http://www.glif.is/working-groups/tech/dtox#NSA"/>

<managing rdf:resource="urn:ogf:network:nsnetwork:DAS4" />

<adminContact rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

DAS4 network</adminContact>

<csProviderEndpoint rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

http://localhost:9080/NSI/services/ConnectionService</csProviderEndpoint>

</owl:NamedIndividual>

</rdf:RDF>

25