The Ofelia Control Framework (OCF), as the automated testbed management tool being used in OFELIA FP7 and FIBRE FP7 projects, is no exception to that. As a result of the set of requirements comming from the OCF and within joint activities in OFELIA and FIBRE FP7 projects the pyPElib library has been developed, in order to have an homogeneous flexible policy enforcement code base.

In a nutshell pyPElib is a small python library to help programmers use the abstractions provided to apply rule-based policy enforcement in certain scopes of the application.

pyPElib library main features are:

• Rule-based policy enforcement
• Rule-based action triggering, logging
• Multiple scope support within an application
• Pluggable multi-syntax support.
• Flexible syntax customization (Resolver and mappings)
• Pluggable persistence backends.

Quick overview

The library is meant to provide Rule-based policy enforcement mechanisms; one could easily find similarities with iptables. The main interface for the programmer to do so is using so-called RuleTable abstraction.

RuleTable

Each RuleTable instance is meant to encapsulate a set of policies to be applied in a certain scope (e.g. provisioning interface requests). The result of an evaluation will always be a DENY/ACCEPT value. Each table has also a default policy (DENY/ACCEPT), in case no rules match.

Example (syntax is pseudo-code).

Each rule may evaluate a simple or a complex condition, and either return ACCEPT/DENY and optionally execute an action, or only execute an action ( so called action rules or non-terminal rules). Conditions may involve checking of any part of the request, application or external context.

Adaptability: mappings

It is also of particular interest to expose how using the mappings functionality provided by pyPElib, and regardless of the syntax module, rules can be customized in order to check whatever kind of context information, hence be used in any kind of application.

Consider the following rule definition, specifically the condition clause (RegexParser):

if  vm.memory > 256  then DENY denyMessage Memory limit is 256MB

Indeed one can use this simple notation to access vm.memory field, without having to explicitely modify anything from pyPElib, not even the parser, thanks to the mappings and the Resolver class.

Mappings are the key element that allow defining custom labels or keywords to retrieve application specific context (e.g. in a Virtual Machine provisioning system, the requested VM memory, the server memory or the number of VMs in a server) . Consider the following mappings for the example above:

_mappings = {
"vm.name":"metaObj['name']",  #metaObj is the object passed to evaluate() routine of RuleTable
"vm.memory":"metaObj['memory']",
#...
}

Mappings are RuleTable instance dependant, hence adapting at the scope that policies have to be applied, and are used as follows:

myTable = RuleTable("My Engine",_mappings,defaultParser=RegexParser, pType=False)

Note that you can easily point these keywords to any object contained in the metObj(object sent to RuleTable.evaluate), a static value or any global function that returns a value, without touching the parsing modules. Another example of mappings:

_mappings = {
"vm.name":"metaObj['name']",
"vm.memory":"metaObj['memory']",
"project.vms":app.models.Project.getVms #function must be defined as "def getVms(metaObj)"
"staticValue": 10,
#...
}

The next steps

At the time this article is being written version 0.1A is publicly avaliable. It is expected that final 0.1 stable version is released within the next month, containing mostly bug-fixing.

It would be also interesting to see plugins/extensions in the following areas:

• More persistence backends (currently a Django backend is under development)
• More (and better) parsing modules
• Integration (via mappings) with user management frameworks.

More information&code:

Project is open to everyone willing to contribute, and is released in Google Code under GPL license: http://code.google.com/p/pypelib/

Within the Long Term Evolution (LTE) adoption, Ethernet will provide an end-to-end convergence scenario as Ethernet will be the transmission layer for backhaul, aggregation, backbone and core networks. LTE provides a packet-based network for easy service deployment. This allows Telecom operators to easy match application and service requirements depending on the access technology.

Nevertheless, some improvements have to be done on Ethernet equipment in order to fully support 3rd Generation Partnership Project (3GPPP) and Metro Ethernet Forum (MEF) services, such as new mechanisms of synchronization to offer voice oriented channels with low latency requirements for end-to-end connections. Actually, synchronized Ethernet is a key technology in order to develop efficient data transport over LTE systems.

For further information read G.8262: Timing characteristics of a synchronous Ethernet equipment slave clock.

The Distributed Application and Network Area from i2CAT research lines cover the following technologies related to network convergence:

• Network infrastructure management applications
  • Management interfaces: TL-1, vendor-specific CLI, Netconf, SNMP
  • Recursive access rights delegation (IaaS)
  • Automated network provisioning, bandwidth on demand (NSI)
  • Extensible, modular and pluggable multi-vendor applications
  • Early prototyping of standards (TMF IPsphere, OGF NSI)
  • Software Defined Network (OpenFlow).
• Recursive InterNetwork Architecture (RINA)
  • Full replacement for the current networking stack (from TCP down to the physical level)
• Interoperable testbed management solutions based on SFA (Slice-based Facility Architecture)

On the other hand, i2CAT EXPERIMENTA platform offers the following MEF Services in order to develop proof of concepts and validation activities using a real network.

• MEF 9 Ethernet Services
• MEF 14 Traffic Management
• E-LINE, E-LAN, E-TREE Services
• Ethernet OAM
• E2E QoS & VLANs Connections

–      1G/10G L2 ports

–      Up to 10 Gbps Ethernet Services

• Functionalities: Native VLAN ID/Priority, LAG, Shaper, Policer; VLAN; Policies; QoS

i2CAT EXPERIMENTA open testbed allows access to network resources as a service at different network layers. Users can configure the network to fulfill their needs. The optical validation platform is designed to support multivendor equipment. i2CAT EXPERIMENTA platform offers multi-layer services to test network applications and devices at different OSI layers on a real environment. Physical network substrate is virtualized to offer virtual isolated slices to final users.

Users can manage and configure their virtual substrate through a dedicated software tool which deals with hardware particularities and manages concurrency. By virtualizing the network, parallel disruptive tests are supported running above the same physical infrastructure. The collaborative platform environment promotes research, development and innovation between public and private (PPP) entities.

Finally, Barcelona will be the Mobile World Capital until 2018 and it brings an ideal opportunity to local industry, administration and research institutes for creating an open innovation ecosystem.

Dootrip Algorithm

Dootrips are trips registered by the users of the social network, in which they declare to have enough space at their luggage to transport a set of laptops [1]. Using all available dootrips of the system, we wanted to find all the existing combinations that allow to ship as many laptops as possible, using the minimum number of dootrips resources. That is, the shortest paths between  the original location of the laptops and the destination ones should be found. The formal definition of the problem is the following:

Given:

• A set of laptops S sorted around the world.

• A set of destination projects T waiting to receive a defined number of laptops.

• A set of dootrips D, each of them having a capacity (in number of laptops), a departure and arrival date.

• A set of hubs H where laptops can be stored between dootrips.

Example of resources location. Blue circles represent laptops, and the red ones stay for destination projects.

Graph obtained from the resources location, in which the algorithm will be executed. Each edge has its own capacity (c), departure date (Dd) and arrival date (Da).

The algorithm should find all paths allowing to transport the maximum number of laptops using the minimum number of dootrips. We decided to adapt an existing max-flow algorithm to resolve this problem, choosing finally the Dinitz’ Algorithm [2], conceived by Yefim Dinitz at 1970. It looks for the maximum flow of a network using the shortest existing paths. There ‘re some important restrictions needed to be considered:

• The flow send through an edge can’t be higher than it’s capacity.

• The set of dootrips d1-d2 can belong to a final solution only if the departure date of d2 is after the arrival date of d1, and both users can meet each other in order to deliver/receive the laptop(s).

• The set of dootrips d1-d2 can belong to a final solution if the departure date of d2 is after the arrival date of d1, both users can’t meet each other, but there’s a hub at this city where the laptops can be stored.

The original graph gets simplified twice before searching all the possible solutions. At the first phase of the transformation, the Residual Graph is constructed, which doesn’t include any edge violating the mentioned restrictions. Once the Residual Graph is built, it’s converted into the Level Graph. The BFS algorithm is executed to find the minimum distance between every node of it. Given an edge between nodes u-v, the Level Graph will include it if distance(s,v) = distance(s,u)+1. It means that the edge will be present only if it’s part of the shortest path between the initial node “s” and “v”. The objective of this transformation is to facilitate the search in every iteration by deleting unnecessary edges.

Finally, the algorithm looks for the maximum flow in the level graph, ensuring that, if it’s shipped from node “s” to node “v”, there’s no shorter path between both of them. The whole process is repeated until there ‘re no more possible solutions. Taking into account that this process was made manually by Labdoo members, the new Dootrip algorithm will improve route calculation efficiency in terms of quality, time and integrity.

Barcelona Hub

Furthermore, i2CAT provides its infrastructure to store laptops if necessary, and also its members prepare them before they are sent to one of the schools Labdoo collaborates with. A hub is an entity that collaborates with Labdoo by storing and sanitizing the donated laptops [1].

Laptops sanitazion at i2CAT

i2CAT represents the Barcelona Hub. Users and enterprises located near Barcelona area can deliver to us their unused laptops. All of them, including the ones donated by ourselves when our devices get replaced by newer ones, are checked at Labdoo’s QGP events. Hubs all around the world get synchronized to check their available laptops hardware and to install the educational platform Edubuntu on it. All devices get tagged in order to trace it state and location during the whole laptops lifecycle. If a laptop is no longer usable, we take the working components from it and the rest of them are sent to a recycling center. In addition, we’re connected to the Labdoo QGP chat room during the QGP sessions, so every person preparing a donated laptop can receive our support immediately.

Once a laptop is assigned to one of the schools, we deliver this dooject to the user of the social network who is going to transport it from Barcelona. Nowadays, laptops that has been sanitized at i2CAT has arrived to different projects located at Ecuador, Thailand, Argentina and Cambodia, for example [3].

Next steps

• This afternoon, i2CAT will organize the 9th QGP coordinated with the Rome hub. Our objective is to prepare ten laptops that will be added to the ones sanitized at Rome before they are sent to “La Escuelita” school, in Ecuador.

• In a few days, the module in which the algorithm is included will be integrated at Labdoo website. After the software gets tested by the Labdoo members, it will be uploaded to Drupal repository, so every organization can use it for similar purposes.

• A white paper explaining the algorithm implementation and the problem it solves will be published between June and July. Remember to have a look at it in case you want to know more about the dootrip algorithm!

Stay tuned for more news on Labdoo!

References:

• [1] Labdoo Website.

• [2] Dinitz’ Algorithm Whitepaper. Yefim Dinitz. Ben Gurion University of the Negev, Israel.

• [3] Labdoo Photo Gallery, including images from dootrips, QGP and schools with the sanitazed laptops.

Three years ago, I had the fantastic opportunity to study the confluence of Open Source community developments and large enterprise Agile setups at Ericsson. It was tough work but very fun. A year later, at i2CAT Foundation, we where kicking off the Mantychore FP7 project. Mantychore FP7 is a quite software intensive project, with ambitious NaaS objectives. Beyond that, the project also presented an interesting project management challenge itself: it was meant to be run as a consortium-wide SCRUM implementation. Later on, we could re-apply lessons learned to the RAISME Fp7 project, and learn a bunch of new ones. In this posts I’ll try to provide an overview of the lessons learned with the hope that it will helps others draft and run better and more successful research projects.

An innovation project is a perfect candidate for an Agile methodology:there is a lot of uncertainty, users available and eager to deploy, unplanned liaisons, etc. However, the very same nature of Fp7 program projects is make them a very arid place for agility. Some examples:

But don’t lose your hope. Agile in an Fp7 can be done, with good results.

However, there is one advice I would like to arise over the top: talk to your Project Officer. The Agile way of working is counter intuitive to the straight FP7 project orientation and you’ll need his buy-in. Make sure he understands what you want to do and the benefits of it. You’ll need him on board.

The Work Plan

As said above, you will have to operate agile inside the constrains of the work plan. In that regard, the project will only be able to properly iterate when this 3 tasks happen concurrently:

• Requirements elicitation and refinement.
• Development.
• Deployment and user feedback.

In Mantychore Fp7, deployment is a complex tasks that involves specialized personal and expensive equipment. This is why we consider a task on its own, apart of requirements. You mileage may vary here, but anyhow, they both fall under Product Owner’s responsibility.

Classify your projects work packages and tasks in three groups:

1. Those who you want out of the iteration loop (management and dissemination work packages, most probably).
2. Those who evaluate releases (generate requirements and feedback).
3. Those who contribute to releases (architecture, design, development, etc)

Mantychore FP7 work plan task classification

Let’s analyse the second and third groups in detail, as they are the ones that fall into SCRUM scope’s:

Product Owner Committee

Consortia are complex to manage and the project will most likely need a Product Owner committee. Consider having a face to face meeting just to bootstrap this committee. Even if expensive, the shared vision and momentum such a meeting will bring can save a lot of trouble and waste of efforts later. Take into account that partners come from very different backgrounds and may have divergent visions and expectations on the project outcomes.

Still, there must be a single person appointed as Product Owner that provides a single point of contact, specially in front on the development team. An unresponsive Product Owner can severely impact the project performance. Availability, as well as familiarity with project’s vision, should be the key indicators to decide who it best fitted to take this role.

The Product Owner is responsible of the project road map. When other projects or institutions get interested in one of your outcomes, the Product Owner should be the one giving them realistic estimates, not the development team. If these institutions get interested to the point where they would like to contribute requirements and feedback, the Product Owner can invite them to the Product Owner committee.

Development Teams

Scrum Master

Co-locating with the main development team and knowledge and experience with SCRUM are key characteristics for a successful SCRUM master. However, unlike a regular industry settings, his work cannot remain purely indoor.

Most likely, a big part of the consortium will not be familiar with development methodologies or the Agile concepts. A big chunk of the Scrum Master’s role will be teaching other institutions to interact on an Agile way, both with the development teams and among them. If this can be challenging inside a company’s four walls, a consortium can take it to the next level. For this reason, it is important that the Scrum Master holds a position in the project with both visibility and authority to perform such task. In Mantychore FP7 the Scrum Master happens to chair the TEC, who supervises work package progress. Two responsibilities that certainly go well together.

Deliverables and Milestones.

The key difference between FP7 and Agile is a different risk model. Projects are monitored for sticking to a contract made of deadlines, while Agile proposes an exploratory and evolutive approach. Specially difficult are those deliverables that are closely tied to the iterations, like requirements documents or user manuals. In those cases, the deliverable will become a snapshot of the document at a given time.

An approach that Mantychore FP7 is implementing is a set of Key Performance Indicators. They show the evolutive nature of key project aspects, while providing to the EC the monitoring capabilities they need in order to ensure the proper investment of public funds. However, a KPI implementation is complex and out of the scope of this post.

Whatever you do, make sure you are at par with the Project Officer!

BonFIRE infrastructure

The five selected partners for running experiments on top of BonFIRE are: CESGA, RedZinc, Manchester 1824, Cloudium Systems and CETIC. From September, they are performing the set of activities they have detailed in their proposals during the lifetime of one year.

The interest is twofold. From one side, external parties get to run experiments on top of the multi-cloud BonFIRE infrastructure to perform their research activities and obtain a profit for their organizations. From the other side, BonFIRE receives feedback from real experimenters using the BonFIRE service performance and usefulness. This feedback is a valuable and rich input to influence the implementation of new functionalities of BonFIRE software for the next releases and in to get ideas for the future sustainability of the facility.

At this moment, they consumed approximately the half of the year of their experimentation, and they have already provided BonFIRE architects with a great amount of useful feedback. A clear result of their feedback importance is that BonFIRE decided to release 2.1 version (which was not planned) to address the key missing functionalities. These functionalities are the support for groups, support for user quota, support for shared storage and improved logging functionality. It was also planned to support usage statistics, with due the lack of time it will be included in the following release.

A second Open Call round is ongoing currently. We have collected a set of proposals and the external evaluators are choosing the ones that will be funded. In this second Open Call we are looking for three experiments (focused if possible in network controlled aspects which is the brand new functionality to provide in release 3) and one cloud provider.

Hopefully this second Open Call round will be as much productive as the first one from the experimenters and BonFIRE point of view!

In order for NRENs (National Research and Education Networks) and operators to be able to deploy and operate the innovative NaaS offerings, an appropriate toolset has been created, OpenNaaS.

It has been envisioned as a multi-project software community that allows several stakeholders to contribute and benefit from a common NaaS software stack. The first objective of the OpenNaaS effort is enable NRENs to provide IP Network as a Service offerings to the research communities they serve.

On a longer term, OpenNaaS targets the following goals:

• Enable researchers to do development on top and reuse past research outcomes easily.

• Have a base functionality that can be trusted on a production environment. On the field usage of OpenNaaS will not only validate its functionality but increase the project’s lifespan.

• Released as open source software with a LGPLv3 license, OpenNaaS is open to the community in order to participate, enhance knowledge and discuss design and road map.

OpenNaaS‘s vision is on-demand, commonly user-triggered, provisioning of network resources. These managed resources must allow a recursive delegation schema of rights, so operation is decoupled from infrastructure ownership.

The software is based in lightweight abstracted data model for the resources layer. This allows for abstraction from actual vendor-specific details. This abstraction is flexible enough to accommodate different designs or orientations and still fixed enough so common tools can be built and reused across plugins (security, life-cycle, monitoring, deployment and upgrade).

In the functional layered model (see picture below) is divided principally into three parts, the platform (orange), the resources layer (green) and the network intelligence (red).

The Functional Layered Model

The resources are abstracted from concrete devices and technologies vendor details. This is a prerequisite to being able to build rich network intelligence orchestration on top of it, as required by the NaaS approach. These resources have capabilities that implement the actual network functionality.

The network intelligence is the layer where all the components that use the application reside and consume the resources. It can be populated with simple scripting code or even complex web services to various middlewares (like VMware, OpenNebula, OpenStack, etc).

The platform layer provides the technology foundation and building blocks for the upper layers.

In order to facilitate the development, contribution and OpenNaaS project monitoring some community resources and channels exist as detailed below:

• JIRA (Mantychore members only): shows the project development and the flow of the issues.

• User Documentation: social collaboration where find technical documentation.

• Bamboo (Mantychore members only): continuous integration server and release management.

• GitHub: hosting service where find the source code and the releases.

• Mailing lists(you can subscribe if you’d like):
  • dev@lists.opennaas.org
  • user@lists.opennaas.org

One of the most valuable features virtualisation has is resource capability abstraction. Indeed, it has been the main enabler for IaaS business models in IT [1], permitting a clear separation between computing infrastructure services (legacy) and servicing the infrastructure itself (IaaS). But this complicates network management: not only legacy network services were difficult to manage and automate [2], but also network IaaS (aka NaaS) requires a set of resource/technology abstraction functions that tend to be complex to deal with when considering the different layers in a network [3]. Notwithstanding the complexity of the problem, network virtualisation and NaaS are seen as the means for letting networks be part of the future ICT world, where coordinated IT and network services allow flexible and dynamic ICT infrastructures to be deployed, even issuing energy efficiency and application awareness.

Needless to say, capability abstraction allows flexible manipulation of the resource.  An appropriate functional decomposition of resource capabilities allows creating virtual instances of it with the sufficient level of granularity. On its turn, this allows the infrastructure provider to offer operable virtual resources (VRs) as a service, that is, configurable and monitorable VRs, as the basis for NaaS. The operator then has to deploy the control logic on top of them. One may argue this is not new, it has been happening for years since the Hardware Abstraction Layer (HAL) was designed for some Operating Systems running on PCs. And it’s true: back in 1979, R. W. Watson and J. G. Fletcher already had dissertations on the feasibility of designing network architectures for supporting network operating systems (NOSs). A good analogy can be found in HAL resources + device drivers in a PC OS compared to virtualised network resource + node controllers in networks (but, aren’t Future Networks big scale, distributed computer buses?). For this purpose, some research projects are creating tools to make network virtualisation easy to handle from a provider/operator perspective. A couple of European projects DANA contributes to in this area are EU Mantychore and EU GEYSERS. The former targets a deployment of a NaaS service over European National Research and Education Networks (NRENs) by means of the so-called OpenNaaS framework. This framework not only implements tools to model and expose capabilities of network resources, but also offers high-level services such as Bandwidth on Demand (BoD) and IT virtualisation tools connectors (i.e. OpenNebula). The latter, GEYSERS, creates the so called Logical Infrastructure Composition Layer (LICL), which hides the complexity of the infrastructure virtualisation to the operator. The LICL allows infrastructure providers to focus on the abstraction/management functions and to provide interfaces for control and monitoring, which are used by the operator.

PC HAL compared to an approach to Network Virtualisation

Nowadays, network equipment vendors are incorporating virtualisation capabilities to their products, of course not limited to VLANs, but rather Virtual Route Forwarding capabilities, multiple Virtual Router/Switch inside the same box, etc. This embedding process follows a natural evolution, but most of the operators are still not ready to work with such advantages. In some cases, it has been seen as major drawback, since network boxes could be even more difficult to manage than before (i.e. creating virtual networks inside a single box). In some other cases, the difficulty relies on the different approaches to network virtualisation vendors are doing, which are not fully compatible with each other in many cases, thus breaking the resource access hegemony HAL provides to OSs [4].

To sum up, a track is open ahead for network virtualisation and its implications in network management are to be considered (if not yet). A number of stakeholders take place on this process, ranging from vendors, to application providers, passing through infrastructure providers and operators, in their wide scope (both IT and network). Models already exist in the computing world, at different scales (HAL and device drivers in PCs; cloud computing and service middlewares…), which indeed are a big step ahead network virtualisation and its management.

Keep on reading us!

Notes and References:

1. Check my previous blogpost On keywords related to cloud, services and virtualisation for further information.
2. A proof can be found in the number of standards that have appeared last years for network management: TMF’s NGOSS TNA and eTOM, TMF’s IPsphere, ITU-T’s Y2001/2007/2011 for NGN architecture, ETSI’s TISPAN, etc.
3. The cross-layer implications of virtualisation is a well-known matter for study that I will leave out of scope of this post.
4. Can you imagine a buying a new PCI card for your PC from vendor A, which requires a software/hardware adaptation of PCI bus messaging because your motherboard has a slightly different implementation of PCI, made by vendor B?

But it seems time for more research projects is arriving. The i2CAT’s island in Barcelona was recently used by a student finishing the Telecommunications career at Polytechnic University of Catalonia (UPC) to prove and showcase his degree thesis on Power Aware Routing taking advantage of the SDN paradigm and OpenFlow technology.

Power Aware Routing

Following there is a short description of the work performed by the student Sergio Jiménez Feijóo and his advisor David Rincón, from the Department of Telematic Engineering (ENTEL) of UPC, obtained from the abstract of the document available here.

A growing interest is emerging around optimization techniques in computer networks with the purpose of enabling new features such as load balancing or power saving. This optimization task can be achieved through linear programming, a powerful mathematical tool which allows to solve certain problems. One way to apply linear programming to the optimization of computer networks is through Software-Defined Networks (SDNs).

This degree thesis is intended to be a first contact with Software-Defined Networks and power consumption optimization techniques. This document introduces the SDN model and explains in detail the differences between legacy and SDN networks. The OpenFlow protocol is introduced as one of the technologies which follow the SDN model. Also, the application of linear programming to the optimization of SDNs is deeply analyzed. This thesis describes some examples of how to apply SDN and linear
programming to implement certain features such as lowest-cost path routing and load-balancing routing.

Finally, the case of an SDN which performs power-aware routing is analyzed in detail and all the steps of the design process of a C/C++ application for the Openflow NOX controller that performs this function are described. This application has been tested in two testbeds, one with low-end devices (domestic linux-powered routers and access points) and another with high-end devices (Ethernet switches from OFELIA project).

UPC relationship

In addition, relationships with David Rincón in order to continue using the testbed in order to continue the work done by Sergio Jiménez Feijóo and think about new projects in form of degree thesis are nowadays running smooth.

FIRE EULER Project

On the other hand, conversations with the UPC team participating in the  FIRE Euler project have been carried out in order to study the possibility of using the testbed to test the new routing algorithms that Euler will produced.

It is great to see that the OFELIA facility in general and the i2CAT’s island in particular are providing a useful service to the research community and the future looks quite good in this sense.

The RAISME core is based on WSO2 Stratos, so it has a key role in the project. First of all, we are going to see an explanation about what Stratos is and later the benefits it gives to the project.

WSO2 Stratos is an open-source cloud middleware platform for cloud-based enterprise applications. It is a Java Paas (Platform as a service) where applications can be in a public or private cloud.

The main Stratos components which are interesting for the RAISME project are: Application server, DataServices server, ESB, Identity Server, Governance Registry and Business Activity Monitor.

• Application server: Hosts applications available on the platform.
• DataServices server: File application services are at the core data of the platform.
• Enterprise Service Bus (ESB): Is an asynchronous, non-blocking Service Bus with support for streaming and based on the Apache Synapse mediation engine.
• Identity Server: Is the component used to identify and bill the customers.
• Governance Registry: Centralized registry for information and meta-data information. Supports other modules.
• Business Activity Monitor: Can perform advanced monitoring and reporting operations if required.

Stratos allows to move applications and services accross various cloud providers and platforms with little extra work. It gives a lot of flexibility to companies which do not want to be stuck in a specific provider and may get into a lot a trouble if their needs change and want to change to another cloud provider. Some of the accepted providers are as important as Eucalyptus, Ubuntu Enterprise Cloud, Amazon Elastic Computing Cloud (EC2) and VMware ESX.

Stratos has a Web-based management portal where users can configure, manage and govern independent, but consistent, servers for each department, or for each stage of a system’s lifecycle. Each server is completely virtual, scaling up automatically to handle the required load, and metered and billed according to use. Stratos has a billing module that allows companies generating monthly bills and send email notifications.

Stratos is a cloud platform, as such it allows developers to build their own SaaS Web applications and use the multi-tenant WSO2 as a service to manage tenant identities. It also integrates readily with Google Apps user directories, enabling OpenID SSO into WSO2 Statos using an authorized Google Apps user name and password. Stratos also supports metering and throttling to manage tenant’s capacity levels.

Why is Stratos the best choice for the RAISME project?

License is a very important issue and Stratos has an Open Source Apache License. It is actually a good choice for a license in a commercial project, specially if you have not decided yet which license you would like to have. Open Source Apache License lets you modify the project and change the license to the one you prefer.

The RAISME project needed to be able to store and manage large amounts of datasets in its  own servers or in the client servers as well as the datasets services. Stratos allows  to access datasets and services in either their own server or in the client servers through an URL. As it can be done from a URL, it means it can be invoked from the portal website where user will interact. When the user accesses the URL, the web service is invoked through the ESB (which is the common entry point).

The RAISME project also needed to have a module to monitor services and bill the services according to their use. This feature allows the project to have a pay per use system in which every user will have some datasets and services for free and others that will have to pay. Therefore, it is important to have the business activity monitor service and ESB to restrict and monitor which users have access to which datasets and to which services.

Stratos has a big active community of developers, therefore we can be sure the project will continue and there will probably be new features which may be applied to the RAISME project.

Last but not least having multitenancy is good for the project because it reduces the time spent and the resources needed to process the requests in the server.

For the above reasons and some others, Stratos was chosen as the best middleware for the RAISME project. On the Stratos platform, RAISME services are deployed in order to have an extensible cloud platform that allows the integration of third party services in an easy and scalable way.

I presented the plans for RINA prototyping and the current status of the Java prototype that is being developed based on the TINOS network experimentation framework. The objective of the prototype is twofold:

1. Allow the validation of the draft RINA specifications that are currently being worked out. Provide feedback to the specifications about details that are hard to sort out without the level of detailed thinking that usually requires an implementation.
2. Once it is complete enough, enable interested researchers to try their policies for the specific parts of RINA they are interested in (authentication, routing, resource allocation, data transfer, flow control, …)

Our initial prototyping goal is to implement a DIF that can provide an equivalent IPC service to what TCP/UDP + IP do together; with all the advantages that RINA provides. The initial prototype is an overlay to IP. UDP/IP can be seen as an underlying DIF, with the advantage of having a well defined, common interface (sockets) with SDKs available for most of the programming languages. IP is also basically universal nowadays, enabling a lot of different deployment scenarios that are easy to setup. Commercial RINA products
over UDP/IP (such as completely customizable VPNs) can be interesting and increase the incentives for RINA deployments at the lower layers.  The RINA prototype treats IP as what it is: a network interface technology – not an internetworking technology -, essentially playing the same role as Ethernet. Summing up, although a RINA deployment over IP over Ethernet has unnecessary overhead, it is an effort-effective way for the initial prototyping efforts to develop the DIF machinery and create a valuable result that can encourage the investment of further RINA deployments in the lower layers, as shown in the next figure.

RINA Adoption Strategy

If you want to follow the evolution of the prototype and/or know more about it, you can take a look to the prototype wiki at github. We expect to have a first complete version of it by the last quarter of 2012. Follow the DANA blog for future information!