A GENERIC SERVICE INTERFACE FOR CLOUD NETWORKS

M. Sifalakis, C. Tschudin

Computer Science Department, University of Basel, CH-4056 Basel, Switzerland

S. Martin

Department of Electrical Engineering and Computer Science, University of Liege, B-4000 Liege, Belgium

L. S. Ferreira, L. M. Correia

Instituto Superior T´ecnico, Technical University of Lisbon, 1049-001 Lisboa, Portugal

Keywords:

Cloud computing, Network services, Future internet, Service interface.

Abstract:

Two major challenges for enabling the vision of cloud computing regard (a) the generic and multi-purpose

access to (virtualised) resources, and (b) the ﬂexible, dynamic, and on-demand composition of services verti-

cally from the physical link level, all the way “up” to the application level. Both aspects require a respective

ﬂexibility and expressibility from the interfaces in-place, which is missing from the current static socket (and

other) interfaces below the application level. In this position paper, we propose, explain and exemplify an al-

ternative generic service interface (GSi) that borrows from object oriented design to enable properties such as

polymorphic access, generic service composition, introspection and dynamic reconﬁgurability, of in-network

resources; opening in this way the path for ﬂexible creation of service clouds.

1 INTRODUCTION

For a cloud service user the ability to conﬁgure-and-

use and then pay-as-you-go a utility-like service, will

be of similar importance as will be for the cloud

provider the manageability (introspection and cus-

tomisability) of the resources comprising an offered

service. To what extend is this possible today?

An observation regarding Internet related engi-

neering is that, by antithesis to technologicalprogress,

little advancement has been made in terms of improv-

ing, standardising, and evolving our programming in-

terfaces and design patterns. One has to take a sec-

ond and ponder how much ﬂexibility and customis-

ability can be attained below the transport level for

on-demand or dynamic allocation or federation of

ﬂow-resources (ﬂow-based routing schemes, proto-

col translators, network coding, assign mobility an-

chors, split/merge ﬂows for distributing processing

and caching), expression of service requirements (e.g.

relative prioritisation of service ﬂows, per service se-

curity level adjustment, data-ﬂow processing), or ex-

pression of user policy (e.g. with regard to service

path selection to avoid in-transit use of an expensive

provider’s network, or an episodic path).

In several of these cases, mechanisms to attain

such objectives may be available (or might soon

emerge), but they cannot be accessed and employed

programmaticaly or on-demand, due to the lack of

sufﬁcient expressibility in the available programming

and user interfaces. At the top-most layer (appli-

cation) of the OSI model a variety of middleware

solutions, which built on top of the socket inter-

face(Stevens et al., 2003), eased application devel-

opment by aspiring more usable interfaces than the

sockets API. Yet, they inevitably cannot offer more

expressibility and functionality beyond what sockets

provide, and at the same time they are highly pro-

prietary, essentially lacking interoperability. These

interface-levelissues contributein two of the most im-

portant obstacles for the adoption of cloud computing

as pointed in (Armbrust et al., 2009), namely service

availability and data lock-in.

To serve the needs of cloud computing, for re-

sponding to service demand that varies with time,

there will be strong demand for more dynamic, func-

tionally richer and more extensible programming and

control interfaces. Such interfaces should (a) leverage

110

Sifalakis M., Tschudin C., Martin S., S. Ferreira L. and M. Correia L..

A GENERIC SERVICE INTERFACE FOR CLOUD NETWORKS.

DOI: 10.5220/0003449501100119

In Proceedings of the 1st International Conference on Cloud Computing and Services Science (CLOSER-2011), pages 110-119

ISBN: 978-989-8425-52-2

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

dynamic federation of resources and composition of

services (within and across cloud providers), and (b)

allow introspection of service state and on-demand

customisation of service conﬁguration.

Starting from this tenet we explore the potential

of adopting object orientation for describing network

functions and services. We present the Generic Ser-

vice abstraction and interface (GSi) as an alternative

to the legacy socket API, that provides constructs for

describing in-network processing and transportation

services on data ﬂows and across (heterogeneous)net-

work(s). We explain how it is possible through this

framework, to preserve service modularity, enable ab-

straction, provide access to the dynamic state in the

network (and in doing so effect cross layering), re-

use algorithms, and compose network-based services

in a structured and accountable way.

In the remaining of this article we ﬁrst motivate

our work (section 2) by sketching the shortcomings

of the socket API for the purposes of cloud com-

puting. Then in section 3, we advocate the beneﬁts

of object-orientation for the design of cloud services

and then we present and exemlify the Generic Service

framework and interface. In section 4 we provide a

use case and early proof-of-concept validation for a

service cloud that provides multi-hop Wireless Mesh

Network (WMN) paths as services. In section 5 we

provide an exploration of the literature and ﬁnally in

section 6 we conclude this paper.

2 MOTIVATION

TCP/IP was initially intended and served as a least

common denominator for heterogeneous networks al-

lowing application inter-operation across them, thus

anticipating and necessitating a global deployment

everywhere. As a result of this global adoption, the

socket interface enabling access and conﬁgurability

to the services of a TCP/IP stack, became a common

denominator and the only de-facto standard API for

building network services. However, today’s reality is

somewhat more complex. Network convergence, re-

source virtualisation and multi-tenancy in cloud com-

puting, require more than mere bridging of different

link-level transports, with a common overlay. One,

cannot factor out the additional diversity and hetero-

geneity of applications and system resources.

The socket interface appears to be rather restric-

tive in expressing the dynamism and plasticity nec-

essary for engineering custom services, integrating

new methodologies (Akyildiz and Wang, 2008; Chi-

ang et al., 2007) and diverse technologies, and embed-

ding new functions in the network stack. Regarding

the last, it is worth noting that most operating systems

today provide frameworks for enriching a systems

network functionality, but is enabled through propri-

etary interfaces not programmatically expressed at the

socket level. In this section we explore the main lim-

itations of the socket API that need to be addressed

in a “modern” API suitable for the purposes of cloud

computing and network convergence.

Static coupling of mechanism and function. The

ﬁrst problem we see with the socket interface is that it

is tailored to the mechanism (TCP/IP protocol suite)

and not the functionality it serves (network commu-

nication). This is due to the protocol-centric evolu-

tion of the Internet under the domination of TCP/IP,

which led to a static interface that cannot be easily

extended to accommodate new conﬁguration options

and parameters, beyond those that are available for

the current TCP/IP stack. This in turn has led to tech-

nological dependencies, which are difﬁcult to get rid

of, the most probably prominent of which is the loca-

tor/identiﬁer coupling: for example separating the lo-

cation from the endpoint of a communication has not

been feasible without re-engineering of the interface.

Lack of modularity. A second problem is the lack

of modularity since a socket expresses in a mono-

lithic way the functionality of a complete stack (and

therefore a ﬁxed set of functions). However, today

it has become more apparent that a full-ﬂedged pro-

tocol suite is neither necessary nor suitable every-

where: Grids of very small devices such as sensors

and RFIDs may not have the resources to operate a

complete TCP/IP stack, or they may not need it (e.g.

full mesh networks do not require routing). In other

cases the underlying network technologies may al-

ready have their own transport level and network level

functionality (Howell, ; Joel, 1993). Reinforcing TCP

and IP overthem for facilitating network-convergence

can be far from efﬁcient and complicating for man-

agement. At the same time this means that any alter-

native composition of network functions and federa-

tion of network services cannot be expressed.

Opacity. Another important problem is that the

sole perspective expressed in the socket interface is

an end-to-end transport level view of the network.

All other functions and their parameters are indirectly

(and insufﬁciently as it is) represented in transport

level options and abstractions. This does not allow

deep introspection and ﬁne grained control or con-

ﬁgurability of the individual functions in the stack,

which is why cross-layer designs rely on additional

ad-hocly deﬁned interfaces.

Limited expressibility. As illustrated in Figure

1(b) the layered design of the TCP/IP stack considers,

and expresses in the socket interface, the interactions

A GENERIC SERVICE INTERFACE FOR CLOUD NETWORKS

111

user

application

inf.objects

hardware

infra.

software

netdriver

application

inf.objects

lossylossless

-1userprofile

-1classofapps

(texthandling)

-2inf.objectclasses

-1networkdriver

- infrastructuretypesN

software

netdriver

hardware

infra.

user

application

inf.

objects

- userprofiles

- classofapps

(texthandling)

- inf.objectclasses

- networkdrivers

- infrastructuretypes

(a) (b)

Figure 1: Old versus today’s interaction models.

between two entities as communication determinants:

(a) the user application, which is the user’s interface

and policy broker towards the network; generating in-

formation objects and selecting how they should be

delivered, and (b) the hardware infrastructure over

which communication is provided.

The challenge faced today however, is more real-

istically depicted in Figure 1(b): the number of com-

munication determinants and the possible interactions

is larger and the scope of these interactions is more

dynamic. Multimedia trafﬁc has introduced a dy-

namic set of (often mutually interacting) information

objects with more diverse delivery requirements than

lossy/lossless, including timeliness and spatial syn-

chronisation. Moreover, these information objects of-

ten interact with the network beyond the context of

mere forwarding (e.g. caching, transcoding or other

in-network manipulation functions). The application

is not always under explicit user control and interacts

with the network in other roles than as a source or sink

of information objects (e.g. for handling of mobility).

The user (or service initiator), on the other hand, of-

ten directly interacts with the network driver (e.g. es-

tablishing vpn connections, setting routing rules, per-

forming admission and rate control, selecting inter-

faces, etc). Finally, new infrastructure technologies

permit customisability based on continuous feedback

from the network driver for better adapting to service

requirements (e.g. soft and cognitive radio, error con-

trol, security, etc). And, as a result, the network driver

in order to serve effectivelythis immense diversity ne-

cessitates dynamicity beyond routing path selection,

in the order to employ appropriate service functions

and utilise effectively a physical infrastructure, richer

and more diverse than ever before (wired, wireless,

multi-hop, ad-hoc, infrastructured, etc).

3 GENERIC SERVICE

INTERFACE (GSi)

In this section we try to bash into the aspects dis-

cussed so far by considering object orientation as an

approach and proposing a modular programming and

user interface for dynamically composing and access-

ing network services.

3.1 Object Orientation in the Design of

Network Interfaces

Object orientation provides a generic and structured

way for separating functionality from mechanism: a

(abstract) class provides the representation and spec-

iﬁcation of a type of function or service, while its in-

terface represents generic semantics for accessing a

mechanism that implements this function. Derived

typed class objects then, embody different mecha-

nisms. This distinction allows a clear separation of

incentives and roles for a user and a provider of a net-

work service. A user for example can concentrate on

the service provided as opposed to the intrinsics of the

service fabric. Encapsulation of mechanism in ser-

vice classes, in this way, also promotes the invariance

of mechanisms (e.g. different providers may offer the

same service, that a user can access invariably).

Selective information hiding, at the class inter-

face, allows controlled access to the intrinsics of a

mechanism and helps the tractability of cross de-

pendencies between different services. Combined

with Polymorphism, it allows “deep” introspection of

state, explicit invocation of service functions across

intermediating functions, and provides a consistent

methodology for representing and extending the in-

teractions among service functions. This practise en-

ables a consistent way of acquiring “cross-layer” in-

formation in an entire composite service and allevi-

ates one of the major concerns currently, against the

adoption of many proposed cross-layer optimisations;

namely the ad-hoc and intractable nature of interac-

tions that they create.

Function overloading can be used to extend the

deﬁnition and semantics of an operation or service

function, in order to group a set of semantically re-

lated services under a common usage framework (and

interface). It also enables other attractive capabilities

that empower cloud services, such as creating new

services from existing ones (to leverage composition),

encouraging algorithmic and functional reuse at dif-

ferent levels of abstraction (to assist virtualisation),

integrating and importing new functional features into

services in non-disruptive ways, etc.

Several of these features have been already ex-

ploited at and above the application level to improve

the usability of application platforms, albeit in propri-

etary ways and without much intend for standardisa-

tion. One only needs to explorethe multitude of appli-

cation level middleware platforms. On the other hand,

CLOSER 2011 - International Conference on Cloud Computing and Services Science

112

less intend has been seen below the socket boundary,

living the space inside the network stack rigid and un-

touchable to any customisability and optimisability.

3.2 Formalising Network Services

The Generic Service interface (GSi) opts to express in

a universal way network servicing at different levels.

In order to account for all types of services however,

we ﬁrst need a network service formalisation, so that a

common interface can be applied to them. Fortunately

this does not seem to be so difﬁcult.

From a high-level view a network service corre-

sponds to the handling of data as they ﬂow across

a network, which typically involves processing P(·)

and/or transportation T(·) operations. For example,

an Ethernet link implements a service that applies a

transportation operation on data, while a VPN ser-

vice involves two processing operations (encryption

and decryption) in combination with a transportation

operation (e.g. PPTP (Hamzeh et al., 1999)). We can

therefore symbolically represent a network service on

data x as

S(x) = {P

(x) , T

(x)} , i = 1..n j = 1..m (1)

It draws that every P

and T

in this deﬁnition may be

regarded as another lower-level (or more basic) net-

work service, which immediately allows us to sym-

bolically express the dependency of complex (com-

posed) services in terms of simpler ones as

(x) = {S

(x) , S

(x)} , i = 1..n, j = 1..m (2)

or equivalently in a more convenient recursive sym-

bolism (not having to distinguish transportation from

processing services)

(x) = {S

k−1

(x) , S

k−2

(x), ..} (3)

Finally, to represent service composition in this for-

malisation, all we need is to specify a composition

function f

(·) that describes how the complex service

is provided from its dependants.

= f

k−1

, S

k−2

, ..) (4)

Such a composition function is likely to express the

integration of the dependant services in terms of in-

terfacing, ordering, or other criteria, lending to sys-

tematic ways of expressing federation (for example in

(Sifalakis et al., 2011) f

is reduced to a declarative

description of data ﬂows, while in (Cobbs, 2011) it is

expressed by a functional program).

Following this simple high-level formalisation

we are now ready to introduce the object oriented

Generic Service interface (GSi) structure.

3.3 The Generic Service Interface

Our aim is to provide programming and control prim-

itives for generic and implicit access to data manipu-

lation and transportation operations, conﬁgurable pa-

rameters and service state, such as the underlying ser-

vice mechanisms may permit. Following an object

oriented design strategy, service speciﬁc functionality

is encapsulated in subclasses of an abstract base class

that deﬁnes the generic interface. Figure 2 shows the

structure of the base GSiclass containing a list of ele-

ments (Items), which may be one of the following:

I/O Points. They represent data inputs/outputs of

the service. These may be identiﬁable protocol end-

points, such as a network address, a port number,

a medium access control channel, or a service han-

dler, ﬁle descriptor and other system local constructs

used to send/receive data. They provide access to

the data plane of a service and they can also be used

in “plumbing” operations between service functions

(dynamic service composition), besides data I/O.

Mediation Point. The data inputs and outputs of

generic services that compose higher order services

are plumbed together at mediation points. Exposing

this construct at the interface level provides a broker

interface for (re-)conﬁguring on-demand the compo-

sition of a service and the federation of resources. For

example if the GSirepresents a routing service or ﬂow

aggregation service in the network of a provider, the

mediation point would provide a control interface for

installing or modifying routing rules/ﬁlters. By anal-

ogy, if the GSirepresents a network storage service

purchased by a user, the mediation point would be an

interface to a virtual array of disk slices, where he

may release some of them to reduce the cost encoun-

tered for the service.

Composing Generic Service List. An optional list

of lower order service functions/resources (symbol-

ised as S

(·) and S

(·) earlier) on which the generic

service depends. The composition function (see f

(·)

earlier) that speciﬁes how these service functions inte-

grate together to provide the higher order service may

also need to be known, in which case it can be re-

vealed in the Attribute List next.

Generic Service Attributes. A list of conﬁgurable pa-

rameters and state values related to the service pro-

vided. They may be parameters for indirectly modi-

fying or customising the service or state values corre-

sponding to information available e.g. for monitoring

the operation or quality of the service. Depending on

the type of service or function that the GSiexpresses,

they may related to a physical or virtual interface, pro-

A GENERIC SERVICE INTERFACE FOR CLOUD NETWORKS

113

+inspect()

+config()

+send()

BaseGSi

+virtualsetKnob()

+virtualreadDial()

+typeof()

Item

Composing

GSiList

+link()

+unlink()

+mux()

+getInfo()

MedPointList AttributeList

+setInput()

+getInput()

+setOutput()

+getOutput()

IOPointList

+setAttrib()

+getAttrib()

Figure 2: Base GSi class layout.

tocol state, service quality, and so forth.

It is worth noting that while the I/O points provide

access to the data plane of a service, the attribute list

on the other hand, exposes the control plane, and a

mediation point provides management plane access.

Therefore, one interface empowers combined opera-

tions across all three planes.

A number of interesting capabilities stem from the

object oriented design of the GSi.

First, all Items, may export a set of Knobs and Di-

als

, as generic conﬁguration and introspection ca-

pabilities across the different Item types and GSi-

classes. By employing polymorphism (object oriented

design), one can set conﬁguration information or read

attributes in a generic service class and recursively to

all its composing sub services as one operation. In

this manner, a conﬁguration parameter expressed at a

high level has a simultaneous effect on a number of

other parameters across an entire system. Similarly,

monitoring a state value at a high level resolves in

deep introspection across the service stack, naturally

supporting cross-layer design.

Second, through the virtual function mechanism it

becomes possible to dynamically associate attributes

of a generic service class to respective attributes of

its Items and sub services without compromising the

modularity of the services. For example it is possible

to relate a user level qualitative metric of a service

(e.g. good, secure, stable, etc) to state information

from the underlying infrastructure (e.g. throughput

levels, end-to-end encryption, error-rates, etc).

Third, although interoperability and compatibility

across services is guaranteed through the uniﬁed in-

terface of the abstract generic service class, still at

the same time, a provider of a service has the ﬂexi-

bility to decide what level of access will be allowed

for the service user (both regarding state information

and access for conﬁguration) by offering the service

in typed subclasses with reduced attribute lists or re-

duced functionally interface primitives.

The metaphor of knobs and dials is inspired by (Calvert

et al., 2007).

Finally, and very importantly, once we have man-

aged to generalise the interface of services, it be-

comes possible to also generically express and im-

plement service composition as a set of operations

over a set of Generic Service classes (e.q. 1 earlier).

This can be done by means of the object-oriented

notion of generic operators, which represent algo-

rithms that implement operations on abstract elements

(operands). They can be developed agnostically to

the nature of their inputs and outputs, which makes

highly re-usable mechanisms possible for any set of

objects that respect certain interface rules. Generic

operators may provide a common framework for ex-

pressing data ﬂow manipulations (such as network

coding, aggregation, etc), or resource federation op-

erations (e.g. clustering, mirroring, etc) for virtuali-

sation. When combined with meta descriptions that

extensively specify the interfacing potential between

different types of I/O points, they empower a dynamic

and extensible compositional capability for services.

3.4 Compartments and Clouds of

Generic Services

According to (Armbrust et al., 2009) the novelty in

cloud computing lies in (a) the illusion of an inﬁ-

nite computing resource available on demand, (b) the

elimination of an up-front commitment by cloud users

that allows one to start small and increase resources

following their needs, and (c) the ability to pay-as-

you-go for the use of resources on a short-term ba-

sis. From these assumptions stem the feature require-

ments for a cloud: it should deﬁne and appear as one

homogeneous resource/service pool, that has speciﬁc

policy and account rules, and its own local dynamics

and resource management/pooling mechanisms (iso-

lation). These requirements do not undermine the in-

teroperability across clouds; rather they prescribe the

self-consistent and dynamic nature of a cloud, which

is therefore more than an administrative domain (it in-

cludes separation of mechanisms), or an autonomous

system (it encompasses more than routing dynamics),

or a service layer (it integrates vertically different re-

sources and network functions/services). This means

that the cloud concept requires a new contextualisa-

tion abstraction and also an interface representation at

a resource level that allows to request and access ser-

vices. Moreover, to leverage interoperability across

clouds, this interface must successfully embed the

cloud features but should not interfere with the mech-

anisms that implement them.

The Compartment construct and interface in

(Bouabene et al., 2010; Randriamasy, 2009) offers

a suitable abstraction that captures the essence of a

CLOSER 2011 - International Conference on Cloud Computing and Services Science

114

cloud. Compartments contextualise communication

and information services of different scales or func-

tional complexity (from a single link, a domestic net-

work, an enterprise network, to large federated struc-

tures). At the same time they reﬂect the presence of

policy domains for decisions (Paul et al., 2008). On

the other hand, how a speciﬁc service is implement in

a Compartment does not impact the service users, nor

does it impact decisions on policy, access control and

quality of service, in other Compartments.

In the context of Generic Services and their ob-

ject oriented design, compartments act as extended

namespaces for addressing/accessing generic services

and control elements that need to be locally identiﬁ-

able. Moreover, a Compartment provides the cloud

interface that one may use to request a generic ser-

vice by means of two primitives: (a) one for register-

ing service points, and (b) another for accessing ser-

vices at these service points. In this way modularity is

preserved at the policy level and the functional level.

In summary, Generic Services create a premise for

functional plasticity, service composition and virtual-

isation, while Compartments provide the context for

virtualisation and the demarcation of cloud domains.

The example that follows will introduce the Compart-

ment interface as a interface for clouds, and will high-

light its use with Generic Services.

3.5 Programming with the GSi

In the scenario of Figure 3, two applications establish

a voice call over a telephony service cloud (cVoice),

which integrates the underlying services of two can-

didate technologies (called Skype and GSM); in turn

provided by respective clouds providers. Initially,

the voice communication between two named enti-

ties in the cVoice cloud uses a carrier service from the

cSkype cloud. When the observed quality drops be-

low a threshold level, the carrier service transparently

switches from the cSkype cloud and to the cGSM

cloud. Access and conﬁgurability of the different ser-

vice components is effected through the GSiinterface.

A user requests for a cloud service (i.e. creation

and initial access to the service) through the Compart-

ment interface as exempliﬁed in the code fragment

4(a). A publish call (line 2) requests association with

the cloud (registration) of the name

sylvain

, and is

used as the listening end for connection requests. The

registration of the name

manos

(Figure 3) would be

performed in a similar way. A resolve call (line 3)

is used to request a voice connection to

manos

cVoice. The successful activation of the service re-

turns a GSiobject gM which can be used (line 4,5) for

accessing and managing the service resources (in this

Figure 3: an abstract cVoice cloud (compartment), fed-

erating cSkype and cGSM infrastructure clouds (compart-

ments).

1: Cloud cV = System.getCloud(”cVoice”);

2: cV.publish(”sylvain”, IncomingCallHandler());

3: GSi gM = cV.resolve(”manos”);

while (gM.getAttr(CALL STATUS) == CONNECTED)

4: Sound.play(gM.getInput(AS STREAM).read(25ms));

5: gM.getOutput(AS STREAM).write(Sound.capture(25ms));

(a) Simple client voice application

1: Cloud cS = System.getCloud(”cSkype”);

2: Cloud cG = System.getCloud(”cGSM”);

3: MediationPoint m = System.getMediationPoint(LOCAL);

while (1)

4: GSi eA = resolve requests.dequeue();

5: String skypeID = lookup name(eA.getAttr(REMOTE), SKYPE);

6: GSi pS = cS.resolve(skypeID);

7: m.link(eA, pS);

8: set monitor(eA, pS);

(b) Voice compartment, call establishment

periodic monitor()

1: [GSi eA, GSi pS] = monitored.dequeue();

2: int latency = pS.getDial(LATENCY);

3: int goal = eA.getAttr(MAX LATENCY);

4: if (!acceptable(latency, goal))

5: String telno = lookup name(eA.getAttr(REMOTE), GSMNet);

6: GSi pG = cG.resolve(telno);

7: m.unlink(eA, pS); m.link(eA, pG);

Figure 4: GSi and compartment API example.

example using the I/O points to send and receive voise

samples).

At the provider end (the cVoice cloud) the code

that services the user request is shown in Figure 4(b).

Upon receiving the service request, a voice connec-

tion needs to be established over one of the infras-

tructure clouds cSkype or cGSM. In line 4, the ser-

vice request by the user (resolve call in 4(a)) results

in preparing up a GSiobject (eA) that will be passed

to the user when the service is activated. This is anal-

ogous to creating an unconnected socket for commu-

nicating with the network stack. Next, the call request

manos

is looked-up and recursively resolved in the

cSkype cloud (line 5-6). In other words, the cVoice

cloud is now requesting (as a user) a service from

the cSkype cloud, which results in the instantiation of

the pS GSiobject when the connection is established.

The process is completed (line 7), when the local me-

diation point is used to link the GSiobject from the

cSkype cloud to the GSiobject that will be returned to

A GENERIC SERVICE INTERFACE FOR CLOUD NETWORKS

115

the user by the cVoice cloud. This involves interfac-

ing the I/O points (data-plane plumbing) and linking

through any service attributes (control plane set up).

Finally, in Figure 4(c) we show the ease for au-

tomating service re-composition through the GSi, in

order to satisfy dynamically user requirements for

service quality. A call quality monitor function (ac-

tivated in line 8 of 4(b)) reads the attribute in the

GSiobject of the cSkype cloud that holds latency mea-

surements (line 2), and compares them to a quality

threshold set by the user (in an attribute of the cVoice

GSiobject). When quality drops below the set thresh-

old level, the mediation point is used to transparently

replace the cSkype service with a new one (similarly

established and accessed by means of the GSi) in the

cGSM cloud (line 5-7).

4 A USE-CASE IN WIRELESS

MESH NETWORKS

WMNs lay on the evolutionary path of wireless

networks, by extending the single-hop access wire-

less paradigm to multi-hop ad-hoc (backhaul) net-

works that combine heterogeneous radio access tech-

nologies. In this sense, WMNs intend to pro-

vide cloud-like services by federating different wire-

less link resources under a uniﬁed dynamic wire-

less multihop infrastructure. In the achievement of

this goal a number of challenges manifest the need

for cross-layer design (Akyildiz and Wang, 2008)

in order to integrate effectively the diverse wireless

network technologies (802.11 (IEEESTD.5307322,

2009), 802.16 (IEEESTD.265774, 2005), LTE (LTE-

SAE, 2008)) and radio communication solutions

(multiradio/multichannel nodes, directional antennas,

etc), in face of heterogeneous QoS constraints, multi-

hop relaying, and variability in link capacity. A sec-

ond challenge is presented as a requirement for dis-

tributed management and dynamic coordination, in

order to allow the network to self-conﬁgure (“plug-

and-play” fashion), organise and optimise its servic-

ing capacity, and incorporate self-healing capabilities

in case of failures.

A typical example regards the effective allocation

and federation of non-interfering radio channels in or-

der to improve mesh node communication and mul-

tipath capabilities in a dynamic network topology.

A promising research direction considers the use of

mesh nodes, equipped with several radio interfaces

operating simultaneously on multiple radio channels

in combination with a channel allocation strategy that

effectively assigns channels/carriers to radio inter-

faces, in order to maximise channel utilisation and

minimise interference. A ﬁxed wireless channel as-

signment among mesh nodes results in statically en-

forced topologies, analogous to the wired ones, how-

ever, with variable quality or episodic connectivity

(due to the susceptibility of the medium to noise and

interference). Hybrid and dynamic solutions on the

other hand, where some or all radios switch dynam-

ically channels, increase inter-connectedness at the

cost of management and algorithmic complexity.

In (Ferreira et al., 2010) a novel distributed co-

operation framework is presented, which allows the

network to take advantage of the local resources and

characteristics of nodes (communication capabilities,

surrounding environment, mobility pattern, persis-

tence, energy, computation capacity) in an oppor-

tunistic fashion. Each node may assume any net-

work role in the mesh (resource management, net-

work gateway, forwarding, address assignment), con-

tributing in the collective optimisation of the network.

In (Randriamasy, 2009), a hybrid channel as-

signment strategy is proposed, where every node as-

signs channels to its interfaces following an interfer-

ence minimisation model. It enables self-organization

and provides stable interconnection by pooling the

per-technology channel frequencies (cloud resource)

into equivalence classes, and allocating them in

a way that minimises a cost function (resource

virtualisation/multi-tenancy strategy).

In the following sections we show how the use of

the Generic Service interface can ease the design of a

WMN cloud service which combines the ideas from

(Ferreira et al., 2010; Randriamasy, 2009) to provide

stable wireless paths as cloud resources.

4.1 Wireless Resource Abstractions and

Interfaces

In order to exploit multiple wireless network inter-

faces simultaneously, we eventually have to address

the heterogeneity of the different wireless technolo-

gies. Moreover, radio channel resources must be

partitioned in the physical dimensions of time, fre-

quency, space and/or code to allow multiple logically-

independent communications to take place simultane-

ously (resource pooling and distribution).

This necessitates two steps of composition, one

for the federation of different wireless link technolo-

gies and a second for the virtualisation (temporal,

spatial and frequency multiplexing) and allocation of

radio channels over them along a multi-hop wire-

less path. The modularisation and abstraction of the

WMN cloud functionality can be therefore imple-

mented in three levels: (a) at the lowest level a GSiin-

terface (GSi

wLLC

) provides access and management of

CLOSER 2011 - International Conference on Cloud Computing and Services Science

116

the wireless interfaces, (b) at the middle level another

GSiinterface (GSi

rMAC

) multiples the wireless inter-

faces and abstract them in virtual channel interfaces,

and (c) at the top layer a third GSiinterface (GSi

WMN

)

abstracts the federation of channel links in WMN ser-

vice paths. The last represents the interface to the ser-

vice delivered to the cloud user.

As shown in Figure 5 different GSi

wLLC

class ob-

jects (WiFi, LTE, WiMAX, etc) are interchangeably

federatable in the list of Composing Generic Services

of a GSi

rMAC

class and can be controlled by means of

software radio techniques and using internal (in the

GSi

rMAC

) multiplexing strategies. Figure 5 schemati-

cally exempliﬁes also common attributes in all wire-

less link technologies, which may be exposed in the

attributes of the generic GSi

rMAC

interface.

WiFi GP

+inspect()

+config()

+send()

+Knobs/Dials...

Item

+ ...

MedPointList AttributeList

+ ...

IOPointList

+inspect()

+config()

+send()

GSi

rMAC

+Knobs/Dials...

Item

Composing

GSiList

+ ...

MedPointList AttributeList

+ ...

IOPointList

+Freq

+Gainin

+Gainout

+ TxPower

+Pmcs

+Pathatten.

+Long,Lat

+ Txrate

+Mode

+SSID

+Encryption

+SNR

+FrmErr.

+ Assoc.

...

GSi

LTE

GSi

WIMAX

GSi

WIFI

GSi

wLLC

Composing

GSiList

Figure 5: A GSi

rMAC

object providing virtual access to mul-

tiple GSi

wLLC

objects.

4.2 Dynamic Channel Allocation and

Path Resource Management

Having localised and abstracted the various

technology-speciﬁc mechanisms (GSi

wLLC

) and

virtualised them as single-channel resources

(GSi

rMAC

), one can then develop ﬂexible, dynamic

and technology-agnostic resource management

mechanisms for a cloud service. Although in this

case study we have concentrated on a channel

management strategy, other cloud mechanisms may

as well include routing schemes, power/rate control,

coding frameworks, QoS frameworks, etc.

The active topology is established through a set

of instantiated GSi

rMAC

service objects that hold

the dynamic interconnection state in the cloud.

Such dynamic information includes estimates of the

average channel activity and utilisation/contention,

queue associations, received power/noise estimates

from competing wireless clusters, hop-distances to

gateways and respective path attenuation, queue

occupancy, and other. Most of this information being

estimated relies heavily on information acquired,

through the same recursive API, by the active

wireless link interfaces, (i.e. GSi

wLLC

objects).

Within the WMN cloud, and for purposes of

management and control, an GSi

rMAC

object and an

encapsulated GSi

wLLC

objects provide access to the

same wireless link resource, enabling joint customi-

sation though either of two different but parallel inter-

faces, each serving a different management objective:

On one hand, the GSi

wLLC

object provides exclusive

technology-oriented management of the wireless in-

terface and through it to the link services it provides

to different ﬂows. On the other hand, the GSi

rMAC

ob-

ject permits customisation of the wireless interface on

a per-channel basis and the temporal virtualisation a

radio channel across multiple wireless interfaces.

Regarding the user perspective of the cloud ser-

vice, all mesh nodes along an active WMN path,

can be identiﬁable and accessible in the context of

a WMN generic service (not in terms of its physi-

cal location, but rather through the GSi

WMN

object)

as a Mediation point. They in turn, maintain up-

to-date dynamic information, which is useful to the

cloud provider (and optionally to the cloud user) in-

cluding the distributed data structures for routing and

neighbour tables, channel usage, as well as informa-

tion about the node locality or operation environment

(e.g. geo-position, power decay and shadowing, gaus-

sian noise, and other).

4.3 Proof-of-Concept

In an early proof-of-concept validation

of the

aforementioned design and the channel management

mechanism from (Randriamasy, 2009) we created a

mesh topology, where 13 nodes (MAPs) form a back-

haul WMN network compartment, and each node lies

in the communication range of three others. One of

the mesh nodes provides gateway connectivity to the

Internet. Each MAP is equipped with 3 wireless inter-

faces (accessed through GSi

wLLC

classes): one IEEE

802.11b for providing connectivity to end-users, and

two IEEE 802.11a for backhaul interconnection with

other MAPs. The two IEEE 802.11a interfaces on ev-

ery node were thus available to the GSi

rMAC

classes

for channel management. The gateway establishes

WMN paths (GSi

WMN

objects) to each MAP, for

sending ﬂows of UDP packets (servicing end users),

Using the OPNET Modeler simulator

A GENERIC SERVICE INTERFACE FOR CLOUD NETWORKS

117

of average size 1500 bytes, and constant rate 12 Mbps

for 802.11a interfaces and 11 Mbps for 802.11b.

In the proposed channel assignment strategy, by

changing the GSiattribute (in the GSi

rMAC

objects) for

the number of available channels for mesh forward-

ing, from 3 to 6, improves the observed quality of the

service at the GSi

WMN

service objects. This is shown

in Figure 6 for the per-node throughput, where going

from from 3 to 5 channels, results in an increase from

1 Mbps to 1.6 Mbps. Using more than 5 channels does

not increase further the performance of the network,

because of the upper limit of the channel capacity at

the gateway.

The maximum theoretical throughput at the gate-

way node, with its two radios operating at 12 Mbps,

and considering an overhead of 15% introduced by

the MAC and PHY layers, is 20,4 Mbps. The use of

5 channels in the simulation, serves 12 multiplexed

ﬂows of 1.6 Mbps, totaling an effective throughput

of 19,2 Mbps. This means that 96% of the theoret-

ical capacity of the WMN is exploited eliminating

almost completely channel interference problems on

the wireless medium of such a multi-hop network.

Figure 6: Per-node throughput, for increasing number of

channels.

These results, of course do not suggest that virtu-

alisation and dynamic channel management is only

possible through the Generic Service framework.

Nevertheless, they demonstrate how easy it becomes

to introduce or remove dynamic functionality without

substantial re-engineering effort for adapting the in-

terfaces, in a non-disruptive way.

5 RELATED WORK

A large number of efforts have appeared in the lit-

erature that aim to address the lack of dynamicity in

the Internet architecture. Many of them provide solu-

tions at the mechanism level within the current archi-

tecture, and several focus on interfacing and extensi-

bility within or across certain layers (e.g. cross-layer

design literature and active networking). Few other

have proposed alternative architectures and commu-

nication paradigms as a solution. As a general com-

ment our main difference to those approaches is that

we do not advocate a new Internet architecture, or the

modiﬁcation of speciﬁc interfaces in order to enable

dynamicity for one mechanism or another. Rather,

we take a more distanced approach proposing an (ad-

ditional or alternative) interface for service mecha-

nisms, which is generic everywhere. It will inevitably

lead engineers to re-consider the way new services are

designed and implemented, but does not necessitate

the re-engineering of existing mechanisms.

In the role-based architecture (Braden et al.,

2002), the authors consider a component-basedmodel

founded on service roles as an alternative to the cur-

rent layer model. Although an important step is be-

ing made towards more modular, ﬂexible and exten-

sible model, the authors do not go as far as proposing

the adoption of object orientation. A step towards the

opposite direction is taken in the NIPCA architecture

(Day, 2007), whereby a process-based modelling of

network communication is advocated, leading also to

a recursive or uniﬁed interface across different lev-

els of abstraction, however such a ﬂat procedural-

programming style API is not less static than sockets

(Stevens et al., 2003).

In i3 (Stoica et al., 2004), the authors adopt in-

direction as a fundamental construct for on-demand

inter-stitching of network services, by means of a

publish-subscribe interface. Similarly to the i3 model

the earlier work in Plutarch (Crowcroft et al., 2003)

also promotes indirection and additionally locali-

sation of service functionality in policy domains,

whereby global inter-network services can be estab-

lished across service contexts. Both, propose inter-

faces that can be useful as an alternative to the Com-

partment interface we consider in this paper, for re-

questing and associating the end user to cloud ser-

vices (as GSi objects). The power of indirection has

been also exploited, more intuitively programmati-

cally, in the network pointers model (Tschudin and

Gold, 2002), and has been adopted in the ANA archi-

tecture (Bouabene et al., 2010). Although, this inter-

face is not object oriented and neither as expressive as

GSi, the network pointers model achieves functional

polymorphism and dynamic service composition at a

very low level.

Another aspect of object orientation, namely ab-

stract services and recursion of protocol functional-

ity is being architecturally explored in the Recursive

Network Architecture (Touch et al., 2006), whereby

layer functionality is organised and developed in pro-

CLOSER 2011 - International Conference on Cloud Computing and Services Science

118

tocol containers. This work goes beyond the interfac-

ing level to enforce a certain engineering practice in

order to be adopted.

6 CONCLUSIONS

We have proposed the adoption of object orientation

in the design of a new generic interface (model) for

network services, alternative to sockets and all pro-

prietary solutions above the application level. Our ap-

proach builds on the generalisation of a network ser-

vice captured in a simple construct and a set of primi-

tives that promote extensibility and support (at the in-

terface level) dynamic federation/composition of ser-

vices; for creating higher order services and virtual

resources. We presented the most important aspects

of the Generic Service model and exempliﬁed its use.

In the end we carried out an engineering exercise for

the design of a service cloud that provides wireless

multi-hop paths as services, which comprise of inter-

layer resources and rely on distributed resource man-

agement and cross-layer information exchange; ap-

proaching in this way as close as possible the cloud

reality.

Our aim in follow-up work is to experiment more

extensively with the Generic Service interface model

and declarative formalisation, in different cloud ser-

vice contexts, so as to improve its expressibility and

establish its plasticity.

REFERENCES

Akyildiz, I. and Wang, X. (2008). Cross-layer design in

wireless mesh networks. Vehicular Technology, IEEE

Transactions on, 57(2):1061 –1076.

Armbrust, M., Fox, A., Grifﬁth, R., Joseph, A. D., Katz,

R. H., Konwinski, A., Lee, G., Patterson, D. A.,

Rabkin, A., Stoica, I., and Zaharia, M. (2009). Above

the clouds: A berkeley view of cloud computing.

Technical Report UCB/EECS-2009-28, EECS De-

partment, University of California, Berkeley.

Bouabene, B., Jelger, C., Tschudin, C., Schmid, S., Keller,

A., and May, M. (2010). The autonomic network ar-

chitecture (ana). IEEE Journal on Selected Areas in

Communications, 28(1):4–14.

Braden, R., Faber, T., and Handley, M. (2002). From proto-

col stack to protocol heap - role-based architecture. In

1st ACM Workshop on Hot Topics in Networks.

Calvert, K., Grifﬁoen, J., and Poutievski, L. (2007). Sepa-

rating routing and forwarding: A clean-slate network

layer design. In Broadnets 2007 Conference.

Chiang, M., Low, S., Calderbank, A., and Doyle, J. (2007).

Layering as optimization decomposition: A mathe-

matical theory of network architectures. Proceedings

of the IEEE, 95(1):255 –312.

Cobbs, A. (2011). All About NetGraph. accessed 30 Jan

2011: http://people.freebsd.org/ julian/netgraph.html.

Crowcroft, J., Hand, S., Mortier, R., and Roscoe, T. (2003).

A warﬁeld, plutarch: an argument for network plural-

ism. Computer Communication Review, 33(4).

Day, J. (2007). Patterns in Network Architecture: A Return

to Fundamentals. Prentice Hall.

Ferreira, L., De Amorim, M., Iannone, L., Berlemann, L.,

and Correia, L. (2010). Opportunistic management

of spontaneous and heterogeneous wireless mesh net-

works [accepted from open call]. Wireless Communi-

cations, IEEE, 17(2):41–46.

Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.,

and G., Z. (1999). Point-to-Point Tunneling Protocol

(PPTP). IETF RFC 2637.

Howell, A. Mobile radio interface Layer 3 speciﬁcation;

Core network protocols; General Packet Radio Ser-

vice (GPRS), technical speciﬁcation 24.008 edition.

IEEESTD.265774 (2005). Approved Draft IEEE Stan-

dard for Local and metropolitan area networks Cor-

rigendum to IEEE Standard for Local and Metropoli-

tan Area Networks-Part 16: Air Interface for Fixed

Broadband Wireless Access Systems (Incorporated

into IEEE Std 802.16e-2005 and IEEE Std 802.16-

2004/Cor 1-2005 E).

IEEESTD.5307322 (2009). IEEE Standard for Informa-

tion technology–Telecommunications and information

exchange between systems–Local and metropolitan

area networks–Speciﬁc requirements Part 11: Wire-

less LAN Medium Access Control (MAC) and Physical

Layer (PHY) Speciﬁcations Amendment 5: Enhance-

ments for Higher Throughput.

Joel, Amos E., J. (1993). Asynchronous Transfer Mode, ieee

press edition.

LTE-SAE (2008). UTRA-UTRAN Long Term Evolution

(LTE) and 3GPP System Architecture Evolution.

Paul, S., Jain, R., and Pan, J. (2008). A vision of the next

generation internet: A policy oriented view. In British

Computer Society conference on Visions of Computer

Science.

Randriamasy, S. (2009). Mechanisms for Generic Paths,

deliverable d-5.2 edition. 4WARD project, European

Commission FP7 ICT-2007.1.1 programme.

Sifalakis, M., Louca, A., Bouabene, G., Fry, M., Mauthe,

A., and Hutchison, D. (2011). Functional composition

in future networks. Computer Networks, 55(4):987–

998.

Stevens, W. R., Fenner, B., and Rudoff, A. M. (2003). UNIX

Network Programming Volume 1, Third Edition: The

Sockets Networking API. Addison Wesley, 3rd edition.

Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and Surana,

S. (2004). Internet indirection infrastructure. In

IEEE/ACM Transactions on Networking (TON).

Touch, J., Wang, Y., and Pingali, V. (2006). Recursive

network architecture. Technical Report ISI-TR-2006-

626, ISI.

Tschudin, C. and Gold, R. (2002). Network pointers. In 1st

ACM Workshop on Hot Topics in Networks.

A GENERIC SERVICE INTERFACE FOR CLOUD NETWORKS

119