rne

rt

proast acurreplicaefores ang prounica

ture Ivoluterati, suctiertent-and].

ization [8] allow the exible and spontaneous creation ofvirtual networks with dedicated properties. They pavethe way for a more exible networking world that is no

works, proper network architectures and protocol stacksneed to be designed and operated. This calls for suited toolsupport for shortening the development and deploymenttimes. Within the context of the EU project 4WARD [11],we developed a framework for the design, test, and evalu-ation of new protocol stacks and network architectures.The framework comprises a life-cycle as well as an exten-sible node architecture for dynamically hosting protocols.

1389-1286/$ - see front matter 2010 Elsevier B.V. All rights reserved.

Corresponding author.E-mail address: martin@kit.edu (D. Martin).

1 He was involved in the research presented in this article during histime at the Institute of Telematics.

Computer Networks 55 (2011) 910918

Contents lists available at ScienceDirect

Computer N

journal homepage: www.elsdoi:10.1016/j.comnet.2010.12.015In addition, various national and international testbedsare promoted, offering a more realistic environment toevaluate new networking ideas. The most prominent onesare PlanetLab [3] and GENI [4], but also European and na-tional activities accommodate the idea of large networksfor testing new networking technologies (e.g. FIRE [5],G-Lab [6], AKARI/JGN2plus [7]).

Furthermore, emerging solutions for network virtual-

tions. The Internet of Things addresses the fact that alleveryday appliances (e.g. refrigerator, coffee pot, goodsthat are transported) might be networked, reducing thegap between the physical and the digital world. Moreover,the Internet of Energy (or solutions regarding the SmartGrid) requires a dedicated network that operates isolatedfrom other networks with guaranteed properties.

In order to fully exploit the capabilities of virtual net-1. Introduction

Under the current buzzword Futude of research projects focus on etionary solutions for upcoming genThey address a wide range of topicsaddressing issues (e.g. locator/idennew networking paradigms (e.g. coning), inherent support for securitywell as economic considerations [1,2nternet, a multi-ionary or revolu-ons of networks.h as naming andsplit), completecentric network-management as

longer bound to a single network architecture being suitedfor all purposes. With network virtualization, multiple net-works of different natures can be rolled-out easily andoperated in parallel on the same physical infrastructure.This opens up new opportunities towards the operationof different networks tailored to certain, possibly very dif-ferent application requirements.

For instance, terms such as the Internet of Things [9] orthe Internet of Energy (e.g. [10]) reect emerging applica-tion areas that inherently require proper networking solu-Protocol evaluationProtocol selectionNetlets

2010 Elsevier B.V. All rights reserved.A exible framework for Future Inte

Denis Martin , Lars Vlker 1, Martina ZitterbaInstitute of Telematics, KIT, Karlsruhe, Germany

a r t i c l e i n f o

Article history:Received 17 May 2010Received in revised form 2 November 2010Accepted 13 December 2010Available online 19 December 2010

Keywords:Future Internet architecturesProtocol design

a b s t r a c t

Many clean-slate aparchitecture with juthe way for the consity of networked approof solution. Therof new architectureassessing competina particular command users.t design, assessment, and operation

ches for Future Internet architectures aim at replacing the currentsingle new architecture. Network virtualization, however, pavesnt support of multiple network architectures. With todays diver-tions, supporting many specialized architectures is a more future-, we propose a exible framework for the design and developmentd their concurrent operation. In addition, we provide means fortocol implementations and for selecting the most suited one fortion task, based on the requirements imposed by applications

etworks

evier .com/locate /comnet

D. Martin et al. / Computer Networks 55 (2011) 910918 9112.1. Life-cycle

With our life-cycle, we intend to push the design of pro-tocols and network architectures closer towards methodol-ogies used for thedesignof large software systems. Softwareengineers dene development processes or life-cycles with2. Integrated protocol design

Today, the design of network protocols and architec-tures is still a cumbersome and time consuming process.Complex international standardization processes coupledwith political interests contribute to the rather long timeneeded for the establishment of new standards. With vir-tual networks and a continuously increasing variety of net-worked applications, shorter development cycles aredesired. Furthermore, standardization might come to havea different role: Like in software-engineering, re-use andclever combination of existing, possibly standardized com-ponents could lead to an increased productivity regardingprotocol and network design as well as implementation.Since we envision a multitude of future network architec-tures and protocols, their development needs to be simpli-ed by fostering re-use of existing protocol mechanisms.Thanks to isolation via network virtualization, standardiza-tion processes can be relaxed as long as no interoperabilityacross networks is needed.

Inspired by component-based software developmentapproaches, we promote composition of protocols out ofso-called building blocks during design-time. These build-ing blocks can be of different granularity, ranging fromatomic protocol mechanisms (e.g. ARQ, CRC, encryption)to complete protocol stacks. They are collected within adesign repository for further re-use. When a reasonablenumber of building blocks is available to the designer, heor she is able to build and evaluate new protocols quickly.Such composites residing within a network node (either onend-systems or on intermediate systems) are called Netletsin our case.

For a design based on composition, we envision a life-cycle which integrates suited tools supporting the varioussteps. Thereby, we differentiate design-time and run-time:During design-time, the designer is able to steer Netletcomposition using his or her know-how. The integratedtest and evaluation ensures a certain degree of robustnessof the new composite before it is actually deployed. The fo-cus during run-time will be mainly on the selection of asuited, already tested Netlet from a repository on onehand, and its operation on the other hand.

The following subsections will analyze our life-cycle inmore detail, present a design tool supporting protocolcomposition, and show how we assess and select alterna-tives. A simple example illustrating the design-time com-position complements this section.This article is structured as follows. Section 2 is devotedto the life-cycle for protocol design and our approach to as-sess alternative solutions. Our proposal for a node architec-ture is described in more detail in Section 3. Related workis discussed in Sections 4, and 5 concludes the paper.concrete phases and steps. Those processes vary from com-pany to company and also change over time. Our aim is indening basic steps of such a life-cycle with respect to thedesign of network protocols and architectures.

A high-level overview of our life-cycle is outlined inFig. 1. The life-cycle starts at the upper right corner ofthe gure with an abstract model and description of theproperties of the required service. It ends with an instanti-ated implementation within a network node depicted inthe lower right corner of the gure. Thus, the upper partreects design-time considerations, while the lower partis devoted to the deployment and operation phases.

An important part of the life-cycle is formed by therepository that comprises components (e.g. buildingblocks, Netlets) which can be re-used by new designs andfrom which Netlets can be chosen for deployment.Depending on the needs of the designer or the target envi-ronment, several distinct repositories (e.g. model reposi-tory, implementation repository, node local repository, ornetwork-wide repository) are allowed. The repository canbe viewed as an important glue between the design-timepart of the life-cycle and the run-time part.

Tool-support plays a central role in simplifying thedevelopment process. Design tools have access to the repos-itory and provide assistance in designing composites andsupporting their evaluation and test. In addition, those toolsassist in transforming the abstract models and propertiesas dened during requirement analysis into a concrete de-sign of the nal components and their implementations.Those components can then be storedwithin the repository,accompanied by their descriptions and models.

Within the run-time part of the life-cycle, we not onlyconsider aspects related to the nal operation environment.Equally important are methods related to the systematicevaluation of the nal product within simulation andtestbed environments. The service deployment and cong-uration thus represents tasks such as selecting appropriateNetlets for simulation, test, or deployment purposes,whereas several constraints from the node architecture(hosting the nal Netlets), the infrastructure management,and the designer need to be considered. Experiences or re-sults gained from evaluation activities may be used for tun-ing parameters or evenmay yield feedback that can be usedfor a re-design of Netlets.

2.2. Designing Netlets

The designers task of composing Netlets out of buildingblocks can be greatly simplied with tool support as pro-posed in [12]: Here, we describe a graphical compositiontool as an Eclipse plug-in based on the Eclipse GraphicalEditing Framework (GEF). Its prototype implementationis on-going and includes initial support for (1) describingproperties of building blocks, for (2) aggregating thoseproperties to determine the composites (i.e. the Netlets)properties, and for (3) assessing and comparing the nalNetlets. Fig. 2 shows a screen-shot of the tool. The centralframes (A) are example-workspaces on which Netlets areconstructed in connecting building blocks. On the right-hand side (B), the available building block models (deningthe building blocks properties) are listed.

Fig. 1. Life-cycle.

Fig. 2. Netlet editor as an Eclipse plug-in: editing frames (A), palette with available building blocks (B), assessment and comparison frame (C).

912 D. Martin et al. / Computer Networks 55 (2011) 910918

alternatives are considered that fulll basic requirements.

set-up delayCapacity Used, available

D. Martin et al. / Computer Networks 55 (2011) 910918 913For a data source, a trafc model can be dened thatroughly estimates a typical applications behavior. Basedon the building blocks properties, the trafc model is mod-ied step-by-step on its (simulated) way to the data sink(i.e. the network access). Such properties are, for instance,processing latency and overhead in terms of control data.

With multiple Netlets at hand, the estimated results canbe used to compare those Netlets (bottom frame C in Fig. 2).For this, normalized utility values for the different proper-ties are determined. In addition, weights are associated tothem in order to allow for a prioritization of selected prop-erties. For e-mail transfer, for instance, having a strongencryption on the data path might be more important thana low latency. Transmitting a public video stream, however,does not require strong security measures, but may need alow latency jitter. The resulting overall-utility (score) isshown on the right in frame C of Fig. 2.

This comparison, however, relies on the properties de-ned within the models. For examining the new Netletsbehavior more accurately, network simulation and testbeddeployment are the tools of choice. We have thereforeintegrated support for the simulation environment OM-NeT++ [13] and the testbed environment G-Lab [6]. Withsuch an integrated approach, realistic scenario-specicproperty values can be determined.

From the Netlets composed with this tool, compile-timeconguration les can be generated in order to create run-time versions of those Netlets. This requires that for eachbuilding block model within the design tool a real imple-

Overhead Per bit, per packet, per connection

Reliability Packet loss ratio, packet duplication,bit error ratio, disordering

Energy consumption Per bit, per packet, per connection, per time

Security Effective bit strengths of key-exchange, authentication, encryption

Content quality Quality of experienceTable 1Properties as assigned to a data stream.

Category ExamplesSub-category

Service qualityLatency 1-Way delay (min,max,median), jitter,mentation exists. Currently, a few example building blocksare implemented and have model representations withinthe tool. In order to add a new building block, a Java-basedmodel dening the respective properties has to be created.In addition, the run-time code for the building block needsto be implemented for the desired execution environment.After that, it can be used for any future composites createdwith this editor.

2.3. Assessing and selecting alternatives

In order to determine the Netlet best suited for an appli-cation, their effects on the applications data stream (func-tional properties) and their side-effects on performance andcosts (non-functional properties) are compared. Some ofThis is donebyltering. If for example theuser or applicationrequires that the communication has to be encrypted, allalternatives without encryption are not further considered.

After ltering, the remaining alternatives are ranked.Since the ranking is based onmultiple communication prop-erties which are used as criteria we decided to apply theMulti Attribute Utility Theory (MAUT) [15]. MAUT com-prises several approaches among which we have chosenUtility Analysis based on its simplicity and exibility. WithUtility Analysis, we rst have to determine the utility valuesfor the respective criteria using utility functions vj. Exam-ples for specic and generic utility functions can be foundin [16]. Using the utility values, we calculate a weightedsum resulting in an overall value for an alternative ai:

vai Xm

j1wj v jcjai; 1

where wj is the weight of the criteria cj. The weights can beadjusted by the user and/or application in order to accom-modate individual preferences. After the utility analysis,the alternatives can be sorted by their overall value andthe alternative with the highest value will be selected.

2.4. Example

For a demonstration of our concepts [17], we imple-mented building blocks realizing a simple codec forstreaming compressed video data. This way, we were ableto easily visualize the effect of packet loss for a particularapplication. The decomposition of the video codec we con-structed originates from this demonstration set-up and israther ne-granular on the codec itself (Fig. 3). The mainreason for this was to keep the example as simple as pos-sible while focusing on few building blocks. The four build-ing blocks (BBs) we chose are described in the following:

(1) Converter. The Converter BB is responsible for con-verting a frame as received from the application toa common format understood by the other BBs andvice versa. It divides a frame into blocks of 8 8 pix-els or reassembles those blocks to a complete frame.those effects can be guaranteed independently of the ac-tual data stream (e.g. in-order delivery of messages), otherscan only be described statistically at best (e.g. latency).

Communication properties can be divided into severalcategories, of which Table 1 gives some examples. A selec-tion process which actually decides which Netlet is to beused for a communication task can assess the availablealternatives using such properties and eventually choosethe most suitable one. This selection takes place during de-sign-time on one hand, where the designer chooses whichNetlets should be available within a given node or archi-tecture. On the other hand, a similar selection takes placeduring run-time where concrete application requirementsand current network conditions are taken into account.Our selection process [14] includes the following steps:(1) ltering based on communication properties; (2) rank-ing of the alternatives based on utility analysis.

First, the selection process has to make sure that only

The advantage of isolating this functionality fromthe other BBs is obvious: If applications providethe video data in a new format, only the ConverterBB has to be exchanged.

(2) IDCT. The IDCT BB performs a discrete cosine trans-form (DCT) on the image data for outgoing framesand an inverse DCT for incoming frames. Making thisBB interchangeable provides the possibility to selecta DCT implementation specialized for the target sys-tem, e.g. in the case additional hardware optimiza-tions can be used.

(3) Quantizer. The Quantizer BB quantizes the DCTmatrix coefcients and regulates the (lossy) com-pression level. Exchanging this block has directinuence on the frames quality and transmissionsize, and allows use of alternative quantization

both Netlets is all that we use to score both Netlets during

protocols. In order to rapidly deploy them, the current net-

914 D. Martin et al. / Computer Networks 55 (2011) 910918matrices and compression schemes.(4) Serializer. The Serializer BB bundles the results in

packets that can be sent through the network. Dif-ferent serializers may offer different policies regard-ing bundling of the 8 8 image blocks.

Using the design tool described in Section 2.2, thosebuilding blocks were combined in the proper way andhence formed a video codec Netlet (Figs. 2 and 3), whichperforms reasonably well in local wired networks. In lossyenvironments, however, packet loss reduces the videosquality massively. To compensate this, we decided to de-velop additional BBs for sending redundant information.This allows for forward error correction (FEC), i.e. the8 8 image blocks are sent three times in total, but eachtime with a more aggressive quantization in order to limitthe additional overhead. In addition to a new Quantizer BBwith FEC, we also added a new Serializer BB with FECwhich ensures that the different versions of the imageblocks are sent in different packets.

In order to assess and compare the two alternatives, theproperties of the different BBs must be determined. All BBscause latency, either due to processing of image data,memory allocations, copy operations, or due to buffering.Some BBs also cause overhead in terms of meta data thatis to be transmitted (e.g. for frame numbers). As non-func-tional property, energy consumption due to CPU usage canbe named.

Fig. 3. Video codec Netlet with FEC (left) and without FEC (right).work stack of an operating system has to be replaced by amore dynamic one. In addition, a more general applicationinterface than todays socket API is desirable, allowing thewriting of networked applications independently fromavailable protocols.

Section 3.1 outlines a new application interface. Ourproposal for a new node architecture is summarized in Sec-tion 3.2, whereas its prototype is described in Section 3.3.

3.1. Application interface

Our vision for a new application interface requires thefollowing changes with respect to traditional applicationinterfaces: (1) address by name; (2) specication of appli-cation (and user) requirements.

Address by name will allow the application to just passthe name of the host, service, or information it wants toreach and let the system take care of the next steps.Although this implies a global naming scheme across allnetworks, this also opens up opportunities for noveladdressing schemes within individual network architec-tures. For such a global naming scheme, we envision ascheme similar to todays URI scheme, but any other hier-archical naming scheme would t as well.

Application requirements must be passed through theapplication interface if the application wants to be ableto affect the selection of, e.g. the transport service. Therun-time. Taking the actual network properties into ac-count (i.e. the current packet loss ratio), the FEC enhancedNetlet will be chosen since it provides a higher contentquality than the non-FEC version. Content quality, how-ever, might become easier to measure in the future sincecurrent research tries to tie Quality of Experience (QoE)to better measurable Quality of Service (QoS) parameters[18].

3. A Netlet-based node architecture

With facilitating protocol design based on composition,we have a means for rapidly creating application-tailoredThe FEC versions of the quantizer and serializer addadditional overhead in form of two redundant versions ofeach image block. In a scenario with no packet loss, thecontent quality with FEC BBs is the same as with thenon-FEC versions. In this regard, the video codec Netletwith FEC performs worse than without FEC since it onlyadds overhead and consumes more bandwidth and moreenergy. This is also reected in the comparison results ofFig. 2 (frame C).

In scenarios with lossy environments, the content qual-ity of both Netlets will decrease, either because parts of theframes are missing completely (Netlet without FEC) or be-cause parts of the frames have a worse quality (Netlet withFEC). In direct comparison, however, the FEC enhancedNetlet will perform signicantly better than the one with-out FEC.

Content quality often is difcult to grasp. Therefore, therelationship between the two content quality properties of

application could, for example, require encrypted andauthenticated transmission. Choosing automatically be-tween alternative protocols based on general applicationrequirements creates a major challenge in formulatingthose requirements. An overview of our work in this do-main is given in [19].

Thus, we propose to push down the application inter-face to become the newwaist of the networking hour-glassfrom the applications point of view (Fig. 4). New protocolsbelow the waist are easily deployable as Netlets, and appli-cations only need to provide protocol-independent com-munication requirements to the application interface.Those changes will allow new innovations for data trans-port and addressing apart from TCP/IP and UDP/IP whichhave become a de facto standard in todays Internet. Appli-cations are no longer bothered with name-to-address res-olution, port selection, or protocol selection, which iscommonly necessary with todays socket APIs. The prob-lems related to such tight couplings can be observed with

Multiplexers operate in parallel.

imposed by, e.g. a system-administrator or user (poli-cies), the Netlet Selection component chooses an appropri-ate Netlet. Hereby, the Netlets properties resulting fromNetlet assessment (Section 2.3) and the underlying net-works properties are taken into account. In the case ofour example (Section 2.4), the NA provides informationon the current packet loss ratio. If the packet loss ratio islow, the assessment of the two video codec Netlets resultsin a similar content quality for both, while the FEC versionrequires more overhead (in form of the two redundant im-age blocks). Thus, the non-FEC version will be chosen.However, if the packet loss ratio is high, content qualityis prioritized over overhead, which results in the selectionof the FEC enhanced version.

In addition, the Netlet Selection has to check, if the de-sired remote node or object is reachable via a specic Net-let (which might only be able to access certain networks).To obtain this information, the Name and Address Mapperhas to be queried, which, in turn, delegates the request toa Netlet responsible for name to address resolution for aparticular architecture.

The Tuning and Optimization Agent constantly monitorsthe conditions of the Netlets, the network, and theapplications. If changes in the conditions occur, it tunes

D. Martin et al. / Computer Networks 55 (2011) 910918 915As an abstraction for the connectivity to a network, theNetwork Access (NA) is used. It can be compared with to-

Fig. 4. Current hour-glass model (left) vs. new hour-glass model (right):pushing down the application interface to the waist of the hour-glassallows innovations at application-level as well as on the network level inremoving the rigid corset of TCP/IP and UDP/IP, respectively.the current transition from IPv4 to IPv6 where all applica-tions need to be adapted accordingly.

3.2. NENA

The Netlet-based Node Architecture (NENA) shown inFig. 5 is our design of end-nodes supporting a multitudeof current and future protocol stacks encapsulated in Net-lets. With the principle of hiding protocol details but yetproviding a number of properties via its interfaces, Netletscan be easily exchanged without the need to change appli-cation or network interfaces.

When running multiple Netlets in the same network,they need a basic common understanding of, e.g. the frameformat or addressing scheme. The Netlet Multiplexer usesthis basic set of network invariants to (de-) multiplexstreams of different Netlets. Since those invariants may dif-fer from network to network (e.g. sensor networks, back-bone networks, delay-tolerant networks), multipledays network interface, but provides a more exibleabstraction for any type of network (e.g. for physical net-works as well as for virtual ones). Especially in virtual net-works, more detailed information about the currentnetwork condition might be available due to the moresophisticated virtual network management infrastructure.This augmented property set can be reected in the Net-work Accesses. Connecting the Netlet Multiplexers toappropriate Network Accesses is handled by the NetworkAccess Manager.

Applications communicating through NENA need to de-ne their communication requirements as described in theprevious subsection. Based on those and on requirements

App

Netlet Selection

App

Net

let

Net

let

Net

let

Net

let

Net

let

Net

let

Net

let

Net

let

Net

let

Net

let

Name/AdrMapper

DecisionEngine UPUP

App

Tuning /OptimizationTuning /Optimization

Man

agem

ent

ARAR

Applicationrequirements

User policies fornetwork selectionUP

AR Applicationrequirements

User policies fornetwork selectionUPUP

ARAR

NA

Network Access Manager

NANA Network Accesses

Multiplexer

Fig. 5. Netlet-based node architecture (NENA) on end-systems.

The Tuning and Optimization Agent has therefore to inter-

explicitly implement concurrency mechanisms.

916 D. Martin et al. / Computer Networks 55 (2011) 910918Currently, some example building blocks and Netletsare implemented, e.g. for video encoding and transport(Section 2.4), or OLSR [21] and AODV [22] for routing inMANETs (both of the latter were kindly provided by a pro-ject partner). The code is publicly available under the con-ditions of the GPLv2 and can be downloaded from [23].

4. Related work

Protocol design based on composition is a research to-pic since many years with rst papers back in the 1980sand 1990s, e.g. [24]. It has resulted in exible implementa-tions still being successfully used for todays research [25].Around the year 2000, protocol composition was used inmany works of the Active or Programmable Networkingoperate with the management component.The Management component provides hierarchical net-

work and node management facilities [20]. It is able to ac-cess any of the other components described here to obtaininformation or to trigger tuning and conguration of themvia the Tuning and Optimization Agent.

3.3. Prototype

In order to prove the feasibility of the NENA concept, ithas been implemented as a prototype. To further prove itsbenet, we started to develop demo protocols and to portexisting protocols to Netlets. In addition, its support for asimulation environment allows easy testing and evaluationof new protocols and architectures which plays a centralrole in our life-cycle.

For easy integration of existing implementations andsimulators, C++ was chosen. The NENA daemon is the coresystem that provides the basic components such as a Net-let repository, the Netlet Selector, and the Network AccessManager. It interfaces with a system wrapper and is able toload and instantiate architecture specic multiplexers andNetlets. Both of the latter are compiled as shared libraries,which in turn are loaded by the daemon.

A system wrapper provides the necessary abstractionsto access services of the underlying operating system suchas timers, threads, or network send/receive. The currentimplementation focuses on wrappers for the network sim-ulator OMNeT++ [13] and real systems like Linux or Free-BSD. This allows us to test the code within a simulatorand to run the very same code on real systems and in test-beds such as G-Lab [6].

The different components within NENA communicateusing message passing. This enables transparent use ofmulti-threading without requiring the building blocks toconguration parameters (per Netlet or per communicationassociation) to adapt Netlets as well as possible to the newconditions. Suchparameters could be, for instance, themax-imum data unit size they are allowed to use or the encryp-tion strength to be used by Netlets supporting encryption.These parameters may need to be adapted if, for instance,the properties of the underlying network change (e.g. dueto a hand-over from a wired to a wireless connection type).community [26,27]. The need of modularity presented bythose approaches reappeared in the last few years as a fun-damental topic of the Future Internet research, e.g. withinANA [28], RNA [29], and SILO [30].

Similar to the work presented in this article, ANA de-nes a run-time framework based on message passingwith support of different static and dynamic protocol com-position approaches by the means of plug-ins. What we de-ned as building block is a Functional Block (FB) in ANAterminology. In addition, they dene an indirection systembetween FBs using Information Dispatch Points (IDPs). IDPsallow access to a service of a FB via a generic interface andallow re-organization of the communication paths in re-attaching IDPs to other FBs or remote entities. In thisway, they allow adding and using new protocols withexisting ones without the need to adapt the latter. FBsare organized in network compartments. Within a compart-ment, some compartment-specic invariants regarding, forinstance, naming, addressing, routing, and packet formatsare known to each FB but not exposed to the outside ofthe compartment. The compartment itself exposes a gener-ic interface that should allow development of compart-ment-agnostic applications that do not need to beadapted if the underlying compartment changes. Whilethis is the same goal we follow with our requirement-based application interface, ANA requires the user of acompartment to specify a context (e.g. a transport protocol)and a service (e.g. a port number), whereas we describe therequested service by means of generic communicationrequirements.

SILO focuses explicitly on cross-layer optimization andinterfaces between services which correspond roughly toour BBs or ANAs FBs. A service hereby allows differentimplementations (mechanisms) that all adhere to the ser-vices interface. In addition to the services tuning interface,a mechanism might provide additional tuning knobs thatallow conguring mechanism-specic parameters thatcan be adjusted if the SILO control agent is aware of them.In contrast to our tuning/optimization agent, SILOs controlagent also takes care of the actual composition of serviceswithin a silo (i.e. a composite) something we are alreadydoing during design-time with proper test and evaluationbefore actual deployment.

RNA does not describe an own execution framework. Itexploits the common structure of protocols in providing ameta-protocol from which protocol instances for the dis-tinct layers can be derived. This meta-protocol providesthe necessary constraints between building blocks and,thus, could also be described as a pattern on how to con-struct protocols. The building blocks supported by RNA,including knowledge about their inter-dependencies couldbe part of our repository.

Compared to those approaches, our research covers theactual life-cycle including design, test, and evaluation ofnetwork protocols prior to their deployment, and theselection between alternative composites during produc-tion use. The design-time considerations we proposed inthis article could be either applied directly to those ap-proaches (e.g. for specifying a compartment layout), orcould be used to dene preliminary dependencies (e.g.for SILOs ontology). Furthermore, these approaches could

D. Martin et al. / Computer Networks 55 (2011) 910918 917be implemented as Netlets, and operated and selected byNENA, which complements them on one hand, and empha-sizes our vision of different network architectures run side-by-side on the other hand.

5. Summary

With network virtualization techniques, viable solu-tions for operating networks with different architecturesin parallel will be available. However, more consequent de-sign-time support will be necessary in order to speed upprotocol and architecture design and to minimize recurringerrors at the same time. Software engineering methodolo-gies have a great potential for enabling partial automationof the design, test, and evaluation of protocols. As a proof-of-concept, we presented a design-tool for composing Net-lets out of building blocks and a exible node architectureas a dynamic run-time framework which allows testing,evaluating, and operating those Netlets in simulations, intestbeds, and in real networks. The repository we have pre-sented plays a central role in fostering reuse in the protocollife-cycle: Its content is key to the success of such an ap-proach and must be continuously extended. Ultimately, itcould be the AppStore (or NetStore) for protocol engi-neers, possibly resulting in new business ideas.

Acknowledgements

This work was carried out within the research projects4WARD [11] and G-Lab [6] which are funded by theEuropean Commission (within 7th Framework Pro-gramme) and the German Ministry of Education and Re-search (BMBF), respectively.

For the conceptual development of NENA, we wouldlike to thank all 4WARD partners for valuable discus-sions. Special thanks go to Ibtissam El Khayat from Erics-son GmbH Germany who was deeply involved in itsinitial design. For conceptual considerations and for theprototype development, we would like to thank our col-leagues Christoph Werle, Helge Backhaus, and Hans Wip-pel, our former colleague Peter Baumung, our studentassistants Benjamin Behringer and Timo Rohrberg, andGorka Hernando Garcia from Robotiker-Tecnalia Spain.The authors would also like to thank Joe Touch, VenkataPingali (ISI/USC), Anjing Wang (NCSU), and Reinhard Got-zhein (TU Kaiserslautern) for valuable discussions aboutservice composition.

References

[1] D.D. Clark, Toward the Design of a Future Internet, Whitepaper,Version 7, 2009.

[2] J. Day, Patterns in Network Architecture: A Return to Fundamentals,Prentice Hall, 2008.

[3] PlanetLab Project Homepage. Available from: .

[4] GENI Project Homepage. Available from: .[5] FIREworks Project Homepage. Available from: .[6] G-Lab Project Homepage. Available from: .[7] JGN2plus Project Homepage. Available from: .[8] N.M.K. Chowdhury, R. Boutaba, A survey of network virtualization,Computer Networks 54 (5) (2010) 862876. Available from: .

[9] International Telecommunication Union, ITU Internet Reports 2005:The Internet of Things, 2005.

[10] L. Tsoukalas, R. Gao, From smart grids to an energy Internet:assumptions, architectures and requirements, in: Third InternationalConference on Electric Utility Deregulation and Restructuringand Power Technologies (DRPT 2008), Nanjuing, 2008, pp.9498.

[11] 4WARD Project Homepage. Available from: .

[12] L. Vlker, D. Martin, T. Rohrberg, H. Backhaus, P. Baumung, H.Wippel, M. Zitterbart, Design process and development tools forconcurrent future networks, in: 3rd GI/ITG KuVS Workshop on theFuture Internet, GI/ITG Kommunikation und Verteilte Systeme,Munich, Germany, 2009.

[13] A. Varga, The OMNeT++ discrete event simulation system, in:Proceedings of the European Simulation Multiconference (ESM2001), 2001.

[14] L. Vlker, D. Martin, C. Werle, M. Zitterbart, I. El Khayat, Selectingconcurrent network architectures at runtime, in: Proceedings of theIEEE International Conference on Communications (ICC 2009), IEEEComputer Society, Dresden, Germany, 2009.

[15] R. Keeney, H. Raiffa, Decisions with Multiple Objectives: Preferencesand Value Tradeoffs, John Wiley, New York, 1976.

[16] L. Vlker, C. Werle, M. Zitterbart, Decision process for automatedselection of security protocols, in: Proceedings of the 33nd IEEEConference on Local Computer Networks (LCN 2008), IEEE, Montreal,QB, Kanada, 2008, pp. 223229.

[17] D. Martin, H. Backhaus, L. Vlker, H. Wippel, P. Baumung, B.Behringer, M. Zitterbart, Designing and running concurrent futurenetworks (demo), in: 34th IEEE Conference on Local ComputerNetworks (LCN 2009), Zurich, Switzerland, 2009.

[18] M. Fiedler, T. Hossfeld, P. Tran-Gia, A generic quantitativerelationship between quality of experience and quality of service,IEEE Network 24 (2) (2010) 3641.

[19] H. Backhaus, Towards a property and requirement-basedapplication interface for future networks, in: 10th WrzburgWorkshop on IP: Joint ITG, ITC, and Euro-NF Workshop Visionsof Future Generation Networks (EuroView2010), Wrzburg,Germany, 2010.

[20] H. Wippel, T. Gamer, D. Martin, A hierarchical node managementsystem for application-tailored network protocols and architectures,in: 5th GI/ITG KuVS Workshop on Future Internet, Stuttgart,Germany, 2010.

[21] T. Clausen, P. Jacquet, Optimized Link State Routing Protocol (OLSR),RFC 3626 (Experimental), 2003.

[22] C. Perkins, E. Belding-Royer, S. Das, Ad hoc On-DemandDistance Vector (AODV) Routing, RFC 3561 (Experimental),2003.

[23] D. Martin et al., Netlet-based Node Architecture Project Homepage.Available from: .

[24] D.D. Clark, D.L. Tennenhouse, Architectural considerations for a newgeneration of protocols, SIGCOMM Computer CommunicationReview 20 (4) (1990) 200208. Available from: .

[25] E. Kohler, R. Morris, B. Chen, J. Jannotti, M. Kaashoek, The clickmodular router, ACM Transactions on Computer Systems (TOCS) 18(3) (2000) 263297. Available from: .

[26] A.T. Campbell, H.G. DeMeer, M.E. Kounavis, K. Miki, J.B. Vicente, D.Villela, A survey of programmable networks, SIGCOMM ComputerCommunication Review 29 (2) (1999) 723. Available from: .

[27] T. Fuhrmann, T. Harbaum, M. Schller, M. Zitterbart, AMnet 2.0: animproved architecture for programmable networks, Active Networks(2002) 162176.

[28] A. Keller, T. Hossmann, M. May, G. Bouabene, C. Jelger, C. Tschudin, Asystem architecture for evolving protocol stacks, in: 17thInternational Conference on Computer Communications andNetworks (ICCCN), 2008.

[29] J.D. Touch, Y.-S. Wang, V. Pingali, A Recursive Network Architecture,Technical Report, ISI, ISI-TR-2006-626, 2006.

[30] R. Dutta, G.N. Rouskas, I. Baldine, A. Bragg, D. Stevenson, The SILOarchitecture for services integration, control, and optimization forthe future Internet, in: G.N. Rouskas (Ed.), Proceedings of the IEEEInternational Conference on Communications ICC07, 2007, pp.18991904.

Denis Martin graduated in computer sciencein January 2008 at Universitt Karlsruhe (TH),with Telematics and Operating Systems beinghis two majors. For his diploma thesis, hedesigned a generic mechanism to detect nodefailures in application-layer multicast trees inMANETs. Since February 2008, he workstowards his Ph.D. at the Institute of Telemat-ics, which is part of the Karlsruhe Institute ofTechnology (KIT). Until June 2010, he partici-pated in the EU FP7 project 4WARD, where hewas mainly involved in the New Architecture

Principles and Concepts workpackage. Since July 2010, he continues hisresearch on novel frameworks for Future Internet architectures in thecontext of the G-Lab project, funded by the German Ministry of Educationand Research (BMBF).

Lars Vlker graduated in computer science in2004 with a diploma degree from UniversittKarlsruhe (TH). His research interests includenetwork security, service composition, anddynamic selection of communication proto-cols. He is the author of more than 20 scien-tic publications, including journal articles,conference papers, and patent applications. Asof now he works for a well known premiumcar manufacturer and is working on innova-tive in-vehicle communication.

Martina Zitterbart is full professor in com-puter science at the Karlsruhe Institute ofTechnology (KIT), Germany. She is director ofthe Institute of Telematics. She received herdoctoral degree form the University of Kar-lsruhe in 1990 and was Visiting Scientist atthe IBM T.J. Watson Research Center, York-town-Height, NY, USA in 1991/92. From19952001 she was full professor at the TUBraunschweig. Her current research interestsinclude Future Internet, sensor networks,Internet of energy as well as architectures,

algorithms and protocols for communication systems in general. In 2002Martina Zitterbart received the Alcatel SEL research award on technicalcommunication.

918 D. Martin et al. / Computer Networks 55 (2011) 910918

A flexible framework for Future Internet design, assessment, and operationIntroductionIntegrated protocol designLife-cycleDesigning NetletsAssessing and selecting alternativesExample

A Netlet-based node architectureApplication interfaceNENAPrototype

Related workSummaryAcknowledgementsReferences