The following is a screen cast of a presentation given by Patsy at FutureNet May 2010 on Code-N-Play: Deployable Network Stacks.
This presentation will start by providing an insight of the EU ICT project 4WARD, a three year pan-European large scale research project for Future Internet Architectures.
The rest of the presentation focuses on one of the main results of 4WARD, which is a component-based virtual network that realises parts of the RINA vision as laid out by John Day (BostonU).
Patsy demonstrates the software platform and some of its core features, which support the design and development of networking protocols and applications. The last part of the presentation will demonstrate how a complete virtual network can be developed, deployed and monitored. The platform we present and demonstrate uses Spring DM (Eclipse Virgo) for deployment and Java development, JNode for legacy hw/sw (device/protocol) integration and the OSGi component framework.

Click here to watch the presentation in WideScreen mode (evil popup window).
What you will see in the presentation is that CBA is

• Java based development, deployment and execution
• No C/C++, No OS Kernel (User space), No pain
• Removal of barrier to entry
• Cross platform – OS independent.
• Off the shelf (free/community tools / platform)
• Applying Industry practises / tooling
• Design–Develop–Deploy
• Its Software – Nothing is impossible!
• Network Protocol(s) / Stack implementation / testing
• Network & Node configuration & deployment
• Complete Programmatic Control – Repeat Scenarios

From an application point of view, the CBA prototype enables real-time management of large-scale networks. In this presentation a major scenario involving an emergency scenario is shown. The scenario is characterised by dynamicity and the need for timely adaptation and this demo shows where selected functions can be deployed in the future Internet.
For example, the network can be thought of in conditions after a natural disaster, where emergency teams need to provide relief, but the network infrastructure is heavily damaged. Multiple network domains can be bootstrapped, and a SLA negotiation is undertaken to transit the medical team node traffic between two domains.
The prototype bootstraps 4 distinct domains: (i) Fixed Operator (FO) Network, (ii) Emergency Medical Teams (EMT) Network, (iii) Ad Hoc Disaster Recovery (AHDR) Network and (iv) Medical Team Node 1.


The challenges in this scenario is related to the establishment and maintenance of a good Quality of Service to guarantee a reliable connection to the emergency team.
Traditionally the Internet would be used as instrument for reliable connection in emergency conditions, but legacy phone lines would be reserved. The major limitation is that instruments for dynamic reconfiguration are not put in place in the network. The enhanced architecture presented here increases the performances of the network.
The knowledge and governance stratum are used to enforce the necessary control loops on various area of the network. Monitoring algorithms implemented in the INM entities assure the necessary scalability to control in real-time a large scale network like the one depicted in the scenario. The SLA manager is in charge of the negotiation between different domains. The integration of the distributed management capabilities within the CBA architecture guarantees reliability in the emergency.
For the SLA negotiation, the “SLA Manager” performs inter-domain negotiation (showing interoperability) thus creating a SLA between the EMT network and the FO network on behalf of medical team 1 client node. The “INM Monitoring” module of the prototype is used to monitor SLA compliance.
Watch a video of the demo

Click here to watch the presentation in WideScreen mode (evil popup window).
Conclusion
The real-time adaptation in emergency prototype has shown the self-organising and self-deployment of a network domain through the holistic and systematic approach of the strata architecture.
The prototype also shows how CBA provides a service orientated architecture based network stack, which allows for more flexible and modular networking functionality. This approach provides the following advantages to network developers (protocol or functions):
a) Java environment which is not tied to any operating system,
b) shortened revise/test cycle (no kernel reboots),
c) easier debugging – full access to the latest java application toolsets,
d) improved stability – user level development, unstable protocol components only affects the application not the overall system.
Finally interoperability via SLA negotiation at a domain level is highlighted in the prototype with the SLA switched networking enabled via Strata encapsulation of the differing network architectures at a domain level.

Overview:
In essence, the CBA prototype consists of a fully functional componentised IPv4 network stack and the ancillary supporting infrastructure. The network stack is implemented as a set of software components. A component typically is a well-defined unit such as a protocol e.g. TCP is a single component. These components are then deployed as an OSGi based application within an application server (Spring DM Server).
The CBA network components (ARP, IP, TCP, UDP,…) have been ported from the JNode operating system. These OSGi components are then grouped into an application instance for deployment within the SpringDM [spring-09] application server. These application instances are entirely isolated and self-contained from each other in the application server allowing for multiple network stack instances to co-exist in isolation – in other words multiple network stacks running independently. The underlying network medium “ethernet” is provided by using Extensible Messaging and Presence Protocol (XMPP) as a network network overlay across which the stacks can communicate.
The CBA network stack applications function as completely independent and isolated virtual nodes. Further components (e.g. traffic generators) can be added into the OSGi applications which then use the CBA stack to perform the inter-node network communication.
Java New Operating system Design Effort (JNode) [jnode-09] is an open-source project to create a Java platform operating system. The project has taken the unique direction of creating all the software in java itself, with the exception of some assembly language to boot and load the system. JNode has an entirely java based Internet Protocol, version 4 (IPv4) network stack which has been proven in the field.
The OSGi framework [All07] is a module system for Java that implements a complete and dynamic component model, something that does not exist in standalone Java Virtual Machine (JVM) environments. Applications or components (coming in the form of bundles for deployment) can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot; management of Java packages/classes is specified in great detail. Life cycle management is done via APIs which allow for remote downloading of management policies. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly.
License
LGPL : http://www.gnu.org/licenses/lgpl.html
The reason behind the selection of the LGPL license is based primarily on the code base that has been ported from the JNode project. The JNode project uses the LGPL license. All modified source code must remain under this license and it is efficient to keep additional source code contributed by WIT under the same license as they may be intermixed within the same organisational packages.
This license has also facilitated the fostering of partnership with the JNode project for future development and cooperation. The JNode project can import code updates from the WIT code base and vice versa in order to progress network protocol functionality.
The LGPL license will apply to all users of the code base. This also includes the partners within 4WARD as the LGPL already applies to existing (modified) code from the JNode project.
Availability
The source code for the CBA prototype is contained under the url of the readme file: https://www2.tssg.org/4WARD/opensource/README.txt
At this location a set of jar files for the protoytpe are stored in the directory. All that’s provided here is either 4WARD written code or code which has been modified from the JNode open source project.
org.tssg.actions.ping-sources-1.0.0.jar
org.tssg.bootstrap.agent-sources-1.0.0.jar
org.tssg.bootstrap.api-sources-1.0.0.jar
org.tssg.bootstrap.driver-sources-1.0.0.jar
org.tssg.config.dao-sources-1.0.0.jar
org.tssg.config.stack-sources-1.0.0.jar
org.tssg.driver.net.idrive-sources-1.0.0.jar
org.tssg.org.jnode.driver.net.loopback-sources-1.0.0.jar
org.tssg.org.jnode.net.arp-sources-1.0.0.jar
org.tssg.org.jnode.net.ethernet-sources-1.0.0.jar
org.tssg.org.jnode.net.ipv4-sources-1.0.0.jar
org.tssg.org.jnode.net.ipv4.config-sources-1.0.0.jar
org.tssg.org.jnode.net.ipv4.icmp-sources-1.0.0.jar
org.tssg.org.jnode.net.ipv4.layer-sources-1.0.0.jar
org.tssg.org.jnode.net.ipv4.resolver-sources-1.0.0.jar
org.tssg.org.jnode.net.ipv4.tcp-sources-1.0.0.jar
org.tssg.org.jnode.net.ipv4.udp-sources-1.0.0.jar
org.tssg.org.jnode.net.support-sources-1.0.0.jar
org.tssg.socket.tcp-sources-1.0.0.jar
org.tssg.socket.udp-sources-1.0.0.jar
org.tssg.support.jnode-sources-1.0.0.jar
org.tssg.transport.im-sources-1.0.0.jar
org.tssg.transport.im.configmanager-sources-1.0.0.jar
org.tssg.transport.im.logger-sources-1.0.0.jar
References:
[jnode-09] JNode Open Source Project. 2009. url: http://www.jnode.org.
[All07] OSGi Alliance. OSGi Service Platform, Core Specification, Release 4, Version 4.1.
OSGi Alliance, 2007. isbn: 9789079350018.
[spring-09] SpringDM – OSGi based Application Server. 2009. url: http://www.springsource. com/products/dmserver
4WARD Partners Involved:
WP2: WIT (TSSG) – Sole Generator of code-base.
CBA lead Patsy Phelan commented on today’s release “Awesome”.

The deliverable D-2.3.1 Final Architectural Framework is available for review and comment.
The 4WARD WP2 main objective is the development of an Architecture Framework to represent and design future network architectures within families of interoperable networks. The developed set of solutions, concepts, and procedures can be used to model current networks, 4WARD networking solutions and future networks.
This Architecture Framework comprises architectural concepts as well as a Design Process. With respect to the architectural concepts we followed a macroscopic view on network architectures as well as a microscopic view in order to develop the basic constructs of the Architecture Framework. The macroscopic view introduces the concept of Strata as a flexible way to layer the services of the network that inherently supports cross-layer information exchange. The microscopic view concentrates more on the functions needed within a network node in a certain network architecture. These functions are encapsulated in so-called Netlets. The Node Architecture provides a generic framework for Netlets. It can flexibly host Netlets, which possibly belong to different network architectures. Within the Node Architecture, Netlets are considered as black-boxes that provide a certain service and that can be exchanged on- the-fly if needed.
This document, D2.3.1, focuses on the work provided during the last six months of the project. Both deliverables together, i.e. D2.3.0 and D2.3.1 describe the Architecture Framework developed within the 4WARD project and provide evaluation results. The focus during the last six months of the project was mainly on two directions:
Complementing the Architecture Framework with a focus on the Design Process and the Design Repository
Evaluation of selected parts of the Architecture Framework
Since this deliverable concentrates on the work performed during 2010, i.e., during the last period of the project, it naturally has some focus on evaluation. Additionally, the basic constructs and concepts have been complemented with further details. Clearly, main focus was on the Design Process, especially the Design Repository and examples for Design Patterns. In the following, an overview of the complements and conclusions is given.
The strata concept (i.e., the macroscopic view) eases cross-layer information exchange, especially due to the availability of vertical strata. Additionally, it provides an increased flexibility since it avoids strictly hierarchical layering. Prototyping activities around the CBA- based prototype can be seen as a feasibility proof of the strata concept.
The Node Architecture (i.e., the microscopic view) should be seen as a framework for a network node that runs multiple network architectures concurrently. It could be shown that Netlets can be exchanged on the fly and that the selection process of a suited Netlet does not become a bottleneck. Example Netlets for end systems and intermediate nodes are presented, reflecting the advantages of the flexible composition approach. In order to support dynamic configuration of network architectures, some alternatives regarding the associated signalling and negotiation are discussed. Various demonstrators and prototype implementations have underlined the practicability of the concepts around the Node Architecture and the Netlets.
Considering the Design Process a major focus was on the Design Repository during this phase of the project. It promotes reusability and avoids that the Network Architect reinvents the wheel every time a new network architecture is being designed. It contains, for example, the basic constructs (Strata, Netlets), Design Patterns, and software components. Security aspects related to the Design Repository are discussed. The security built into the Design Repository is closely related to how it will be used.
Three Design Patterns were developed: The Interdomain Interface, the Association and Composition of Functionalities. With the Interdomain Interface, a minimal implementation of the SGP (Strata Gatewaying Point) is provided that is to be implemented at all interconnection points between domains. The Association provides support for proper modelling of a variety of communication paradigms. Furthermore, the Composition of Functionalities describes a way on how a Network Architect can compose functionalities, in addition to the application of SOA- based concepts to the composition of functionalities.
The second part of this deliverable documents the validation and implementation work in this last working period. Different methods have been applied for evaluation and validation purposes: use cases, modelling, simulation experiments, and prototyping (including demonstrators).
The Design Process has been validated through the application of a use case related to an AdHoc Community. Different types of requirements (business requirements and technical requirements) are derived as first steps, followed by the identification of network functionalities at the macroscopic level (i.e., strata) and, along with this, the logical nodes. Then Netlets are identified. In order to derive an implementation of the designed network architecture, the software components are then selected, combined and, eventually, deployed. This validation effort has underlined the general usefulness of the Design Process and its applicability. Further support by appropriate tools, however, will be needed for practical applications. The Netlet Editor developed earlier within the project can serve as a simple example for that since it provides some support for the design and evaluation of Netlets. The same holds for the Acme-based modelling activities as described in the following.
A formal model of the network architecture from a macroscopic point of view is provided in addition to a model from a microscopic point of view that has been developed earlier in the project. The modelling was done in Acme. Armani predicate rules were applied to validate the correctness of the modelled scenario. It could be shown that this way of modelling network architectures supports the Network Architect during the design of a network architecture. The validity of the scenario as well as the fulfilment of properties can be proven.
The practicability of the selected concepts of the Architecture Framework was mainly validated through prototyping activities that also resulted in different demonstrators. These demonstrators were presented at the project review in Aachen in 2010.
• Integrated WP2/WP4 demonstrator:
This demonstrator integrates concepts of In-Network Management (WP4) with basic constructs (Strata, Component-Based Architecture) of the Architecture Framework. Easy deployment of networks, real-time monitoring and self-adaptation within network domains were demonstrated. Another important issue was on the interoperability between different network domains based on the strata SGPs (Strata Gatewaying Points).
• Integrated WP2/WP3 demonstrator:
This demonstrator integrates virtual networks (WP3) with basic constructs (Node Architecture, Netlets) of the Architecture Framework. It shows the design and test of Netlets as well as the deployment of the Node Architecture (including Netlets) into a virtual network. Dynamic adaptations of Netlets as well as the virtual network were successfully demonstrated.
Both prototypes, the CBA-based prototype as well as the Node Architecture prototype, were enhanced during the last period of the project.
• The CBA-based prototype was extended with an implementation of the Association Design Pattern as well as with a sequence to elaborate on a novel name resolution and routing scheme.
The Node Architecture prototype was extended with Routing Netlets (AODV-based, OLSR-based) supporting different types of mobile ad hoc networks (MANETs) with individually suited routing services. Additionally, a protocol for dynamically switching between these Routing Netlets as reaction to changes in the networking situation has been designed and implemented. Regarding the Node Architecture it could be shown that both, fine tuning of parameters as well as dynamic switching of similar Netlets is supported. Generally, this underlines the flexibility and extensibility of the Node Architecture.
The switching protocol was tested and evaluated in a simulation environment. It could be shown that the proper parameter tuning improves the convergence time, as expected.
• The Node Architecture prototype was further extended with QoS blocks. The validity of the implementation was tested through network measurements.
Furthermore, signalling in multi-access networks has been designed and incorporated into the integrated macroscopic/microscopic view and investigated through simulation experiments.
• Two tuning/optimization algorithms have been developed to optimize the packets size for WLAN transmissions. It could be shown that throughputs with controlled packets size are significantly higher than with fixed packets sizes. The number of concurrent users in WLANs can be increased.
• The selection of the network interface within a multi-access network was also investigated. Based on the proper interface selection, delay and throughput can be improved.

The deliverable D-4.5 Evaluation of the in-network management approach is available for review and comment.
Work Package 4 (WP4) of 4WARD has worked towards the definition of novel management instruments to operate the future Internet. In-Network Management, (INM), utilizes decentralization, self- organization and autonomy as its basic enabling concepts. The idea is that, contrary to the legacy centralized approach, the management tasks are embedded in the network. The managed system now executes management functions on its own. The INM concepts and its design are detailed in 4WARD WP4 deliverables D4.2 In-Network Management Concept ] and D-4.3 In-network management design].
Deliverable D4.1 described scenarios and use cases for the Future Internet, and for each scenario, derived requirements to enable it. This deliverable compiles a comprehensive list of requirements from all the scenarios, and uses them as a basis for evaluating the INM design concepts developed by all WP4 tasks.
The evaluation process follows a WP4-adapted V-model, in which the INM implementation is checked against its testing results in a top-down approach, from the full system down to each of its components. This methodology facilitates an evaluation without the need for a comprehensive implementation of all NM functionality, a valuable feature for this clean-slate conceptual project. The evaluation effort is split into three separated topics that match the structure of the WP4 activities: framework, algorithms and a demonstrator. Depending on the extent of the implementation, different evaluation instruments are used.
The analysis utilizes two agreed templates, one for the framework and one for the algorithms. The framework is evaluated for scalability, robustness, reduced integration effort, and reduction of complexity. Each INM algorithm from tasks 4.3 and 4.4 is evaluated with the algorithm template.
Special attention was given for the evaluation of cross WP activities: INM for NewAPC (cross WP2/4), INM for VNET (cross WP3/4), INM for GPs (cross WP4/5), and INM for NetInf (cross WP4/6). The business aspects of INM (includes cross WP1/4) were also studied.
The evaluation analysis demonstrates that every requirement identified in Deliverable D4.1 was addressed by some algorithms in D4.2 ] and D-4.3 ]. The degree of coverage of each requirement varies, and explanations are given for those that are lightly addressed. Compared with legacy management systems, INM design is shown to be scalable and robust. Moreover it facilitates reduction of integration effort and reduction of complexity. Most importantly, INM is beneficial for NewAPC, VNets, GPs and NetInf, and it demonstrates business incentives that are realized with potentially reduced OPEX and increased EBITDA values.
In summary, the evaluation analysis of the simulation results shows that the INM design is beneficial for the Future Internet. The next step is to test the feasibility of INM concepts in real experimental networks.

The deliverable D-4.4 In-Network Management System Demonstrator is available for review and comment.
4WARD proposes a novel approach of network management, called In-Network Management (INM). Its basic enabling concepts are decentralization, self-organization, and autonomy. The design of key INM functions has been reported in the previous D-4.3 In-network management design.
This D4.4 document reports the results of the prototyping activity of WP4 in 4WARD. The objectives are twofold. First, it provides an analysis of potential exploitation scenarios of INM in the future Internet. Second, it reports the experience of an integrated implementation of the INM algorithms and provides a refinement of the INM design with detailed information flows.
Three scenarios have been identified as results of the joint activities between WP4 and the other Workpackages in 4WARD. The first scenario is about dynamic deployment of connectivity in emergency situations, where the interoperability function of WP2 is integrated with the INM real-time monitoring. The second scenario considers integration of INM cross- layer metrics with adaption function of the Generic Path considered in WP5: network coding is considered in our implementation as adaptation function. The third scenario applies INM function to virtual networks as considered in WP3. Here INM objectives are used to configure adaptive actions in case of congestion and therefore support operators’ business models. The document briefly discusses the benefits of the INM approach in these discussions, which can be summarized in three major items: reduction of integration effort, simplification of management operations and support for operator’s business.
The scenarios have implemented through a selected set of INM functions. To offer a unified view of the operations in INM, we describe first the organisation interface and we show then its configuration for objectives as well as controlling properties of the INM algorithms. This interface allows also for composition of INM algorithms and construction of workflows at local level (e.g. anomaly detection and triggering of adaptation function) and at domain level (e.g. construction of aggregated key performance indicators).
As experience of our implementation work, we provide details about specific INM algorithms: INM Runtime, Clustering, Anomaly Detection, Monitoring, cross-layer QoS. For these algorithms we describe a decomposition into functional modules and interaction diagrams. These instruments show how the functions designed can be implemented and mapped to the message flow in accordance to the INM interfaces.
This deliverable is one of the two final deliverables of WP4 and is complementary to D-4.5, which reports evaluation studies.

The deliverable D-4.3 In-network management design is available for review and comment.
This deliverable D-4.3 reports on 4WARDs work developing the novel paradigm of In-network Management (INM), aimed specifically at the effective management of large, dynamic networks.
Its basic enabling concepts are decentralization, self-organization, and autonomy. The idea is that management tasks are delegated from management stations outside the network to the network itself. The INM approach therefore involves embedding management intelligence in the network, or, in other words, making the network more intelligent. The managed system now executes management functions on its own. It performs, for instance, reconfiguration or self-healing in an autonomic manner.
This deliverable describes the main results of WP4 achieved during the second year of the 4WARD project and it complements deliverable D-4.1, which presents use cases illustrating the potential of INM capabilities. First, it contains the design of the INM framework, an enabler of management functions that defines a set of architectural elements from which any distributed and embedded management structure can be created. Second, it presents algorithms for situation awareness in real-time and self-adaptation that provide a subset of management functions that we regard as important and challenging for the management of the future Internet. Third, it outlines our work towards an INM prototype due in June 2010.
Finally, the document reports on the results of WP4 INMs close collaboration with other WPs in the 4WARD project.

This summer school programme was devised by the 4WARD team to provide courses, labs, presentations, PhD poster sessions, panel discussion, and invited talks on the topic of the Future Internet, by leading experts from European projects and other international partners.

Links to the presentations and invited talks can be found on the main website for the summer school. which include
* Future Internet Architecture by: Martina Zitterbart, Universität Karlsruhe (TH), Germany;
* Views on the Future Internet by: Norbert Niebert, Ericsson, Germany;
* Future Internet Research in Europe by: Paulo de Sousa, European Commission;
* Special Invited Plenary Short Course: (CCN) Content Centric Networking by: Van Jacobson, PARC Research, USA;
* Security and Dependability Issues of the Future Internet by: Syed Naqvi, CETIC, Belgium;
* Network Virtualization by: Stephan Baucke, Ericsson EDD, Germany;
* What QoS for the Future Internet? by: James Roberts, Orange Labs, France;
* Accessing WiFi Networks from Moving Vehicles by: Samir R. Das, Stony Brook, University SUNY, NY U.S.A.,
* Recursive Network Archtitecture by: Joe Touch, USC/ISI, USA;
Some of the course material is also avaialble on
* ORBIT Hands-on-Tutorial by: Ivan Seskar, WINLAB, Rutgers University, USA
* Mobility and Multiaccess in Emerging Internet Architectures by: Kostas Pentikousis, VTT Technical Research Centre of Finland, Finland
Towards a Network of Information by: Kostas Pentikousis, VTT Technical Research Centre of Finland, Finland
* Delay Tolerant Networking by: Carsten Bormann, University of Bremen, Germany; and Ioannis Psaras, University of Surrey, United Kingdom
* ANA – ‘Autonomic Network Architecture’ Tutorial and Lab by: Christian Tschudin; Christophe Jelger; and Ghazi Bouabene, University of Basel
* Network Virtualization by: Panagiotis Papadimitriou, Lancaster University, United Kingdom; Yasir Zaki, University of Bremen, Germany; Liang Zhao, University of Bremen, Germany, Asanga Udugama, University of Bremen; Ingo Grothues, Ericsson EDD, Germany; and Carmelita Görg, University of Bremen, Germany
* From Distributed Management to In-Network Management by: Rolf Stadler, KTH Royal Institute of Technology, Stockholm, Sweden; and Danny Raz, The Technion, Haifa, Israel
* Interdomain Routing and Traffic Engineering by: Pedro A. Aranda Gutiérrez, Telefónica I+D, Spain
Business Models of the Future Internet by: Mario Kind, Deutsche Telekom AG, Laboratories, Germany
* Interference Management in Wireless Networks by: Samir R. Das, Stony Brook University, SUNY, NY U.S.A.
* The Generic Path by: Hagen Woesner, TU Berlin, TKN, Germany

The deliverable D-2.3.0 Architectural Framework: new release and first evaluation results is available for review and comment.
4WARD WP2 main objective is the development of the Architecture Framework to represent and design future networks architectures within families of interoperable networks. This set of concepts and procedures can be used to model current networks, 4WARD networking solutions and future networks. The reader should notice that WP2 does not aim to specify the 4WARD Architecture (i.e. to define the network architecture that integrates the different approaches under study in the different 4WARD work packages); in fact, this is the goal of the project wide activity “Architecture Task Force” to which WP2 is also an active contributor.
This deliverable presents an advanced draft of the 4WARD Architecture Framework being developed in WP2. While the previous deliverable ([2]) was more focused on the specification of the concepts being developed in WP2, this deliverable is more focused on the presentation of the validation activities being carried out in WP2, which have helped to review the concepts presented in the previous deliverable.
To model new Network Architectures, WP2 has defined the concepts, terms and the basic constructs. This Architecture Framework provides two levels of views on network architectures: (i) the macroscopic view mainly focuses on structuring the network at a higher level of abstraction and introduces the concept of Strata as a flexible way to layer the services of the network that can enable the usage of information across different layers; and (ii) the microscopic view concentrates more on the functions needed in the network nodes, their selection and composition to Netlets that are instantiated in the Node Architecture that allows the dynamic coupling of applications and network protocols not easily possible in today’s networks. In this deliverable, the Functional Blocks are presented as the common points between the two views of the architecture. The Component Based Architecture constructs and principles are used as the basis to provide reusable frameworks that minimise the design and development times of new network architectures.
The Network Architect (which is defined as the responsible(s) of designing new networks) uses the Architecture Framework to design and develop new Network Architectures. The methodology to be followed is represented in the Design Process; which considers 3 main phases: (i) detailed requirement analysis, (ii) the Abstract Service Design and (iii) the Component Design Phase. This proposal does not aim to substitute the current design processes available in different organisations but it presents a proposal which links the communication system design and the software development principles. The Design Process is complemented with a so-called Design Repository which provides guidelines, design patterns and the like in order to support the Network Architect. In this context, the document presents a methodology to compose different functionalities. Moreover, the Interoperability among different networks has been considered in some detail and some best practices are provided that allow for flexible interworking in Future Internet environments.
All these concepts are being validated using different strategies: use cases are used to develop and validate the proposed concepts; the prototyping of the proposed constructs demonstrates that they can be implemented and deployed; the modelling activities demonstrate the specified properties and they provide the tools that can be used for future implementation; finally, simulations are used to validate specific algorithms and provide design patterns for specific problems. All these strategies have been followed to validate the different concepts as explained next:
In order to validate the Strata concept, the Component Based Prototype has been developed. This prototype is designed, a first version is available and it can be used to implement several use cases such as the bootstrapping of new networks or to integrate WP4 concepts. Additionally, the Agent Based Prototype has been also implemented in order to show the functionalities from the Governance and Knowledge strata that could be deployed in the nodes. By simulation, a discovery protocol has been evaluated and some results are expected to be included as part of the Design Repository. Finally, the stratum modelling activities can be reused by the Network Architect during the specification of the Strata.
The Node Architecture/Netlets concepts are validated from different perspectives. The implementation of the Node Architecture Daemon validates the proposed architecture and constitutes a tool that can be used to easily prototype new functionalities in a node. This Node Architecture prototype will be used to show specific use cases where the WP3 VNet framework is used. Simulation studies are being conducted to validate the signalling capabilities that should be integrated in the Node Architecture in order to deal with the wireless media. The different Netlets and capabilities will be simulated in OMNeT++. Finally, an early version of a modelling tool (the Netlet Editor) to support the design of the Netlets (that also provides the way to visualise the composition of functionalities inside a Netlet) is provided. This activity will show the general feasibility and utility of tool-supported Netlet design.
The Interoperability concepts are being validated thanks to the implementation of the SLA Module to be integrated in the Strata prototype. This prototype is being built considering the models developed in the SLA Modelling work that has produced a general model for the contract that provides the information about the parties involved in the service negotiation and the functionalities to be provided.
The Composition of Functionalities is a concept available in basically all the activities. Just to highlight, the CBA prototype assumes the composition of different functionalities as well as the Netlets running inside the Node Architecture prototype.
For the validation of the Design Process, we basically rely on the Use Case about Ad-Hoc communities initially defined by WP1 and that WP2 has refined in close cooperation with that WP to validate the different phases of the process. This an activity that it is still in progress; thanks to the close analysis of the business requirements and the inference of technical requirements, WP2 has provided a good input to WP1 in order to refine the business value of transit carriers in the Network of Information. Finally, as part of the validation of the Design Process, the result of the rest of validation activities (patterns for signalling in wireless access, results from Netlets, etc.) can be considered part of the Design Repository, which contains all those principles, constructs and best practices to be reused during the design of new networks.
This deliverable presents the current status of all these validation activities which are not in their final stage but that, for the time being, have demonstrated the feasibility of the proposed concepts as well as the inference of design patterns for the design of discovery protocols or signalling capabilities that can be reused during the design of new networks. It should be also noticed that in all these activities, WP2 has collaborated with the different WPs, in particular: WP2 has taken as an input a scenario defined by WP1 in order to apply the Design Process and has helped to clearly identify the business benefit that should be derived from the required new functionalities/services to be provided by the different stakeholders, in this scenario WP2 will apply concepts from WP6; WP3 VNet framework is being used to instantiate the Node Architecture daemon and the Strata prototype is incorporating concepts from WP4.
Following the main document, there are some annexes that provide additional information mainly related to the validation activities in order to provide more technical details about the use of the WP2 framework.

The deliverable D4.2 In-Network Management Concept is available for review and comment.
This deliverable reports on our progress towards developing the paradigm of In-network Management (INM), a clean-slate approach to network management, aimed specifically at the effective management of large, dynamic networks, where a low rate of interaction between an outside management entity and the network will be required. The idea is that management tasks are delegated from management stations outside the network to a self-organizing management plane inside the managed system. This is enabled through decentralization, self- organization, embedding of functionality and autonomy. Under this paradigm, the managed system executes functions –locally or end-to-end– on its own and performs, for instance, reconfiguration or self-healing in an autonomic manner. It reports results of its action to an outside management system or triggers exceptions if intervention from outside is needed.
The deliverable describes the main results of WP4 achieved during the first year of the project and it complements deliverable D-4.1, which presents use cases illustrating the potential of INM capabilities. It contains a first version of the INM framework design, which defines the structure of the management plane inside the network, supports the embedding of management functions and provides reusable components to compose collaborating self- managed entities. Second, it presents a set of algorithms and concepts developed for real- time management, with emphasis on distributed monitoring in large-scale dynamic environments. Third, it reports on work that demonstrates the feasibility of rapid re- configurability for selected management algorithms and functions under the INM paradigm. Extensive simulations have demonstrated the effectiveness of the approach and have quantified key trade-offs.
The report ends with an outlook of the project plans for the second year, where effort will be devoted to proving the technical feasibility through prototype implementation of selected functions and integration of the work with that other WPs.