Mantychore FP7: IP Networks as a Service

This text has been submited as Extended Abstract at TERENA 2010. You can visit the project website here, and join our public mailing list here.
Current National Research and Education Networks (NRENs) in Europe provide connectivity services to their main customers: the research and education community. Traditionally these services have been delivered on a manual basis, although some efforts towards automating the service setup and operation have been initiated. At the same time, more focus is being put in the ability of the community to control some characteristics of these connectivity services, so that users can change some of the service characteristics without having to renegotiate with the service provider. Mantychore FP7 is the natural evolution of its parent projects: MANTICORE[1] and MANTICORE II. MANTICORE implemented a proof of concept which proves the idea of IP network and router as a Service (IPNaaS), all this management in Layer 3 where MANTICORE works. MANTICORE II continued its steps to implement stable software with the feedback, expertise and know-how received. Also, MANTICORE II added new and improved capabilities to the software and run a success pilot project where MANTICORE II partners got the chance to run some trials on their own network and equipment. The Mantychore FP7 [2] project wants to consolidate this trend and allow the NRENs to provide a complete, flexible IP network service that allows research communities to create an IP network under their control, where they can configure: i) Layer 1, Optical links. Users will be able to get permissions over optical devices like optical switches, and configure some important properties of its cards and ports. Mantychore will integrate the Argia framework [3] which provides complete control of optical resources. ii) Layer 2, Ethernet and MPLS. Users will be able to get permission over Ethernet and MPLS (Layer 2.5) switches, and configure different services. In this aspect, Mantychore will integrate ETHER project and its capabilities for the management of Ethernet and MPLS resources. iii) Layer 3, Mantychore FP7 suite includes set of features for:
  1. Configuration of virtual networks.
  2. Configuration of physical interfaces.
  3. Support of routing protocols, both internal (RIP, OSPF) and external (BGP).
  4. Support of QoS and firewall services.
  5. Creation, modification and deletion of virtual resources: logical interfaces, logical routers.
  6. Support of IPv6. It allows the configuration of IPv6 in interfaces, routing protocols, networks,
In order to streamline the software suite and provide a better coupling with day-to-day NREN and research communities’ usage, much emphasis is put on gathering requirements and feedback not only at the beginning but through all the length of the project. The Service Activity 3 (SA3) members (i2CAT and UPC), in the context of T4.2, have assumed the unprecedented compromise to release a new deployable version of the software each month. This monthly deployment will both incorporate previous feedback and serve as new baseline for further refinement and enhancement of the software suite. Mantychore FP7 will carry out pre-operational deployments of the IP network service at two NRENS: HEAnet [4] and NORDUnet [5]. Initially three communities of researchers will benefit from this service: the Nordic Health Data Network, the British Advance High Quality Media Services and the Irish Grid effort [6]. Part of the project effort will be dedicated to consolidate and enhance the community of providers (NRENs but also commercial) and users of the IP network service. It includes a first phase to get requirements of each Mantychore users, and a second phase to define necessary use cases.

In order to improve IaaS service some alternative but very interesting topics will be researched. Framed as Joint Research Activities (JRAs), an infrastructure resource marketplace and the use of renewable energy sources to power e-Infrastructures will be liaised, enriching both the user community and the roadmap of the Mantychore project. A marketplace provides a single venue that facilitates the sharing of information about resources and services between providers and customers. It provides an interface through which consumers are able to access the discovered resources from their respective providers. The Mantychore FP7 marketplace represents a virtual resource pool that provides a unified platform in which multiple infrastructure providers can advertise their network resources and characteristics to be discovered by potential consumers of the resource. Thus, the Marketplace involves three types of entities. (a) the customers that use the resources.  These customers may be end-users, service providers or other providers who wish to extend their point of presence, (b) the infrastructure providers, that provide information about the state of their underlying infrastructure to satisfy the demands of customers, and (c) the matchmaking entity that is used to lookup and locate relevant resources as requested by the customer. The matchmaking entity mediates among the providers and the customer and uses a matching algorithm that parses requests into queries, evaluates the queries over the resources in the marketplace repository and returns the relevant resources. These algorithms are implemented on a generic manner using quality of service parameters suitable to both Layer 3, 2 and 1. Also, as a part of a JRA, the Mantychore FP7 project will start collaborating with the GreenStar Network project (GSN) [7], a CANARIE [8] funded initiative. The GSN project will develop a practical carbon footprint exchange standard for Information & Communication Technology (ICT) services, will carry out studies on the feasibility of powering e-Infrastructures with unstable renewable energy sources, such as solar or wind, and will also develop management & technical policies that leverage virtualization to migrate virtual infrastructure resources from one site to another based on power availability to facilitate use of renewable energy within the GreenStar Network. The principal objective of this collaboration relies on providing an IaaS management tool and integrating the NREN infrastructures with the GSN network that is formed by a set of green nodes where each one is powered by renewable energy source. The benefits obtained from this collaboration are reflected on the emergence of new and rare use cases where energy considerations are taken into account. Among other topics of research, how to move virtual services without suffering connectivity interruptions and how the physical location can influence in that relocation. In addition to the two JRA, NA3 is working towards incorporating new users and communities to enrich the user base. The Mantychore FP7 project is committed to incorporate as much viewpoints and uses as possible in order to reach a more complete and valuable software and expertise pool. In that regard, and taking to account that the project is developed inside a research framework, coordination channels and infrastructure tools have been setup around an open model that not only allows but welcomes expert participation at all levels. For this reason, the project resources (technical discussions, contributions, official documents) are open and available for any interested individual or community to join. In addition, Mantychore FP7 is very much open to receive feedback and collaborations with other research fields.

Join us in our public mailing list! We want to hear from you!

References [1] Eduard Grasa, Xavier Hesselbach, Sergi Figuerola, Victor Reijs, Dave Wilson, Jean Marc Uze, Lars Fishcer, Tomás de Miguel, “The MANTICORE Project: Providing users with a Logical IP Network Service”, TERENA Networking Conference 2008 [2] Mantychore FP7 project website [Online]. Available at http://www.mantychore.eu/ [3] E. Grasa, S. Figuerola, A. Forns, G. Junyent, J. Mambretti; “Extending the Argia software with a dynamic optical multicast service to support high performance digital media”. Optical Switching and Networking, Vol 6, Issue 2, pp. 120-128. April 2009. [4] HEAnet website [Online]. Available at http://www.heanet.ie/ [5] NORDUnet website [Online]. Available at http://www.nordu.net [6] OPsCentre website [Online]. Available at http://grid.ie/opscentre.html [7] GreenStar Network project website [Online]. Available at http://www.greenstarnetwork.com/ [8] CANARIE website [Online]. Available at http://www.canarie.ca/

Funding . Duration January, 1970 - January, 1970
Partners

Future Internet Research Between Brazil and Europe - FIBRE

The main goal of the FIBRE project is the design, implementation and validation of a shared Future Internet research facility, supporting the joint experimentation of European and Brazilian researchers. FIBRE is a coordinated project, unifying under the same umbrella the efforts done in the FIBRE-EU and FIBRE-BR projects.

Funding EU FP7 (FIBRE-EU). Duration October, 2011 - March, 2014
Partners i2CAT, University of Essex, Nextworks, Université Pierre et Marie Curie, University of Thessaly, National ICT Australia (FIBRE-EU) UFPA, CPqD, RNP, UFF, UFG, UFRJ, UFSCar, UNIFACS, USP (FIBRE-BR)

Mantychore

Mantychore will follow the Infrastructure as a Service (IAAS) paradigm to enable National Research and Education Networks (NRENs) and other e-Infrastructure providers to enhance their service portfolio by building and deploying software and tools to provide infrastructure resources like routers, switches, optical devices, and IP networks as a service to virtual research communities.

Funding EU FP7. Duration December, 2011 - December, 2011
Website http://www.mantychore.eu/
Partners i2CAT, HEAnet, NORDUnet, University of Essex, UNI-C, Telefónica I+D, Trinity College Dublin

Rapid Application Innovation for SMEs - RAISME

RAISME enables high-tech organisations with niche skills to rapidly build and scale innovative ICT applications. This is achieved through the collaborative use of advanced “mashup” technology and cloud computing. The RAISME SMEs are at the vanguard of a new business paradigm where the end-user becomes part of the product development lifecycle, thus accelerating it, and where collaboration allows faster exploitation of knowledge and productivity. Initial RAISME partners who have already developed state-of-the-art visualisation, optimisation and integration tools that will be able boot-strap a series of new applications and then deliver highly innovative knowledge services to the market.

Funding EU FP7. Duration December, 2011 - December, 2011
Website http://www.raisme.eu/
Partners DRTS, INRIA, i2CAT, GAMCO, VISup, University of Sheffield

OpenFlow in Europe, Linking Infrastructure and Applications - OFELIA

The aim of the OFELIA project is to create a unique experimental facility that allows researchers to not only experiment ‘on’ a test network but to control the network itself precisely and dynamically. To achieve this, the OFELIA facility is based on OpenFlow, a currently emerging networking technology that allows to virtualize and control the network environment through secure and standardized interfaces. In a nutshell, OpenFlow enables experimenters to change the behavior of the network as part of the experiment rather than, if at all, as part of the experiment setup. OFELIA will provide high-performance OpenFlow equipment to enable experiments at scale and to ensure that the facility is based on mature technology.

Funding EU FP7. Duration October, 2011 - September, 2013
Website http://www.fp7-ofelia.eu/
Partners EICT, Deutsche Telekom, University of Essex, i2CAT, TUB, NEC, IBBT, ETH-Zurich, Adva, University of Standord

RINA Prototype

RINA -Recursive InterNetwork Architecture-, developed by the Internet pioneer John Day in his book ‘Patterns in Network Architecture’, provides a general theory about networking. This theory clarifies what is really the layered structure of networking protocols: there is only a single type of layer, which is configurable, and this layer can be repeated as many times as required to optimally solve the network resource allocation problem. This model opens the door to multiple parallel Internets (not only the single, global, flat network that today’s Internet is), provides a structure that inherently supports multi-homing, mobility and multicast without the need for special protocols, is more secure, and allows distributed applications to use the network to communicate without having to know network internal details such as the addressing. In this project the network technologies cluster collaborates with the Irish research centre TSSG, the Boston University and the American startup TRIA Network Systems to develop the first RINA prototype.

Funding Self-funded. Duration September, 2010 - September, 2012
Website http://rina.tssg.org/
Partners Boston University, i2CAT, TRIA Network Systems, TSSG
See related news

Networking Innovations Over Virtualized Infrastructures - NOVI

NOVI (Networking innovations Over Virtualized Infrastructures) research concentrates on efficient approaches to compose virtualized e-Infrastructures towards a holistic Future Internet (FI) cloud service. Resources belonging to various levels, i.e. networking, storage and processing are in principle managed by separate yet interworking providers. NOVI will concentrate on methods, information systems and algorithms that will enable users with composite isolated slices, baskets of resources and services provided by federated infrastructures.

Funding EU FP7. Duration September, 2010 - March, 2013
Website http://www.fp7-novi.eu/
Partners NTUA, Martel, UPMC, GARR, UvA, i2CAT, DFN, INRIA, ELTE, PSNC, Cisco, Fraunhofer, UPC

Building Service Testbeds on FIRE - BONFIRE

  BONFIRE will design, build an operate a multi-site Cloud prototype FIRE facility to support research across applications, services and systems at all stages of the R&D lifecycle, targeting the services research community on Future Internet. The BONFIRE vision is to give researchers in these areas access to a facility that supports large scale multy-disciplinary experimentation on their systems and applications addressing all aspects of researchs across all layers. Our overall goal is to encourage new communities of experimenters to take advantadge of the opportunities offered by the FIRE infrastructure to guide the development of the Future Internet from a service-based applications standpoint.

Funding EU FP7. Duration June, 2010 - December, 2013
Website http://www.bonfire-project.eu/
Partners Atos, University of Edinburgh, SAP, University of Stuttgart, Fraunhofer, IBBT, Universidad Complutense de Madrid, i2CAT, HP, The 451 Group, TUB, University of Southampton, INRIA

Generalised Architecture for Dynamic Infrastructure Services - GEYSERS

GEYSERS’s vision is to qualify optical infrastructure providers and network operators with a new architecture, to enhance their traditional business operations. Optical network infrastructure providers will compose logical infrastructures and rent them out to network operators; network operators will run cost-efficient, dynamic and mission-specific networks by means of integrated control and management techniques. GEYSERS’s concept is that high-end IT resources at users’ premises are fully integrated with the network services procedures, both at the infrastructure-planning and connection-provisioning phases. Following this vision, GEYSERS will specify and implement a novel optical-network architecture able to support ‘Optical Network + Any-IT’ resource provisioning seamlessly and efficiently. Energy-consumption metrics for the end-to-end service routing are part of this efficiency.

Funding EU FP7. Duration January, 2010 - December, 2012
Website http://www.geysers.eu/
Partners Interoute, Martel, Adva, SAP, Alcatel-Lucent, Telefonica, PTT, PSNC, Nextworks, INRIA, i2CAT, UvA, University of Essex, AIT, TUBS, IBBT, IIT

Internet Future Architectures for Media Independent Services and Protocols

This project will tackle the Future of Internet from both a revolutionary and evolutionary perspective, in order to understand the benefits and disadvantages of each approach and be able to compare them. Additionally, the project will take into account solutions thought to improve three important lacks of the current Internet: energy efficiency, heterogeneity of information and coexistence of networks. In order to do so, two technologies have been identified as potential solutions to some of these problems: i) Media Independence and ii) Virtualization. On the one hand, Media Independence enables the decoupling of physical and overlay infrastructure by introducing an abstraction layer between link and network layers. On the other hand Virtualization enables the creation of overlay networks spanning multiple technologies and realms, hence being a very useful tool for context-aware service composition.

Funding MICINN (CICYT). Duration January, 2010 - December, 2012
Partners UPC, i2CAT, Universidad Carlos III

GEANT3

The objective of this proposal is the creation of a leading edge network supporting a much enhanced range of services, both network and added value services, targeted at end-users across the GÉANT service area. A principal goal will be to create a portfolio of seamless multi domain services. In contrast to GN2, its predecessor project, much more emphasis is placed on service development and service introduction.

Funding EU FP7. Duration May, 2009 - April, 2013
Website http://www.geant.net/
Partners DANTE, TERENA, ACOnet, AMRES, ARNES, BELNET, BREN, CARNET, CESNET, CYNET, DFN, EENET, FCCN, GARR, GRNET, HEAnet, IUCC, JANET, KTU-LINET, MARNET, MREN, NIIFI, NORDUNET, PIONIER, RedIRIS (i2CAT is a 3rd party), RENATER, RESTENA, RoEduNet, SANET, SigmaNet, SURFnet, SWITCH, ULAKBIM, UoM

Improving network utilization in cloud computing environments

Cloud computing  relies on the network as an elementary service. An increasing number of distributed computing applications pose highly-demanding requirements for dynamicity and flexibility in network and computing resource control (e.g. automated scaling up/down). However, network services are still treated by applications as “always-on” and the application layer is unable to exploit the automatic control potentialities of the current  network technologies. The computing resources dynamics are completely uncorrelated from the network ones and there is a common trend to over-provision network services. This leads to inefficient resource utilization in the network. Briefly, BonFIRE offers a multi-site cloud testbed that supports large scale testing of applications, services and systems over multiple, geo-graphically distributed, heterogeneous cloud testbeds. BonFIRE targets the Internet of Services community and offers a test infrastructure that is ideal for performing experiments relating to distributed applications and services.

One of the key features of BonFIRE is to give experimenters the ability to control some of the many variables that affect the performance of distributed applications. For example, BonFIRE allows experimenters to control network quality of service parameters such as latency, delay and packed loss using IBBT’s Virtual Wall network emulation facility. Further control of network performance between geographically distributed infrastructures in anticipated through future interconnection with the FEDERICA and AutoBahn facilities, trying to improve the relation between the cloud sites and the network services mentoined previously.

FEDERICA was a European Project of the 7th Framework Program. Its main goal was to deploy an e-Infrastructure for researchers on Future Internet. This infrastructure is physically distributed around the whole Europe and it is composed by routers, switches and servers. Currently, access to a subset of FEDERICA infrastructure is possible through collaboration with NOVI FP7 STREP project. AutoBAHN (Automated Bandwidth Allocation across Heterogeneous Networks) is the GÉANT Bandwidth on Demand system. It reserves resources in heterogeneous, multi-domain environments, allowing immediate and advance circuit reservations. Among the NRENs participating in the AutoBAHN pilot in GÉANT there is PSNC (PL), Janet (UK), Renateur (FR). Our current work consist on extending BonFIRE architecture to allow federation with NOVI and be able to request and allocate FEDERICA network resources and to extend BonFIRE architecture to be able to request circuits with guaranteed bandwidth trough AutoBAHN service tool.The final goal is to provide an improved network control/provision to BonFIRE experimenters. If you are interested in the topic, keep reading our blog for further updates about how we integrate network control on BonFIRE multi-cloud scope !    
 

One of the key features of BonFIRE is to give experimenters the ability to control some of the many variables that affect the performance of distributed applications. For example, BonFIRE allows experimenters to control network quality of service parameters such as latency, delay and packed loss using IBBT’s Virtual Wall network emulation facility. Further control of network performance between geographically distributed infrastructures in anticipated through future interconnection with the FEDERICA and AutoBahn facilities.[ACH1]

 

[ACH1]TODO: ensure IBBT, I2CAT, PSNC AND NWX are happy with this chapter. Also need referemces.

Could maybe mention an increase in realism here and cite that paper that talks about it.

Funding . Duration January, 1970 - January, 1970
Partners

Marketplace in Mantychore FP7

In previous posts (links: description, requeriments, security, related projects), we commented that Mantychore FP7 has two main objectives:

  • Mantychore FP7 as a module within OpenNaaS [a]. It will provide a set of services and tools to manage cloud services around the different layers:  layer 1 (physical layer), layer 2 (data link layer), layer 3 (network layer).
  • Exploit this Infrastructure as a Service (IaaS) paradigm to enable National Research and Education Networks (NRENs) and other e-Infrastructure Providers to enhance their service portfolio by building and deploying the software and tools to provide Networks as a Service.
[caption id="attachment_2201" align="aligncenter" width="640" caption="Mantychore external architecture"][/caption] About this last topic and as part of the Mantychore FP7 project, the marketplace work package expects to design and develop an infrastructure to trade different Mantychore resources.  This marketplace will facilitate the exchange among different administrators and users.  In Mantychore FP7, we can difference three different roles that will be represented in our scenario.
  • Infrastructure Provider (InP) or infrastructure owner (IO): This user can assign permissions to the infrastructure resources he owns so that external users can control it. Infrastructure instances can be either physical (e.g. a physical router) or virtual (e.g. a logical router). In the Mantychore FP7 case, NRENs are the Infrastructure Providers, offering their infrastructure to user communities.
  • Service Provider (SP) or Virtual Operator (VO): This user can harvest infrastructure instances from one or more Infrastructure Providers and integrate them into his management domain (e.g. he can integrate several routers into an IP network). He can also act as an Infrastructure Provider and reassign the permissions on “his” infrastructure instances so that other Service Providers can control them (it is a recursive process). He normally uses the infrastructure instances of his domain to provide some kind of service to end users (e.g. an IP Network service). In the Mantychore FP7 scenario, an international community of researchers could create a virtual organisation with their own dedicated IP network (built using resources from different NRENs). One partner of this international research community would adopt the role of the “Service Provider” – typically the leader of the testbed Work Package in a European project, for example.
  • End User (EU): Uses the services offered by the Virtual Operator. These users belong to a virtual community that receives several infrastructure resources and creates one or more IP Networks out of them. Users are empowered to change some attributes of the IP network service (such as internal routing, IP addressing, peering, create circuits between endpoints, firewalls), but wouldn’t be able to modify the number of resources in the network. In any case, it would be their virtual operator the one controlling the permissions of each individual user (hence the definition of different user profiles is possible).
Motivation for the marketplace In the architecture which Mantychore FP7 has developed, without  a resource broker in place, the business agreement between SPs and Infrastructure Providers would be an out of band manual process as follows:
  1. Users request infrastructure resources i.e. virtual infrastructure.
  2. The Service Provider (SP) of the user responds by asking what he/she needs.
  3. The Infrastructure Provider (InP) uses the Mantychore tools to check the inventory of physical devices. He/she looks at the current utilisation, and, if he/she can fulfil the request, agrees with the user’s SP in the provision of the virtual Infrastructure resources. A negotiation about the price and the characteristics of these instances (e.g. routers and switches) starts between the SP and InPs.
  4. Users’ SP may accept the offer from an InP, or may further negotiates with it.
  5. If a user agrees, the InP uses Mantychore tools to substrate the virtual Infrastructure resources and assign permissions to the SP. The SP uses Mantychore tools to check the infrastructure resources assigned to him/her, the SP can also assign the resources to IP networks and carry out the configurations.
  6. If the SP needs more infrastructure resources, he/she needs to repeat this process with other InPs.
  7. Finally, if these resources will be allocated to end users (EU) who will use the IP network services which SP providers.
Although this negotiation is simple to implement and works in the real world, it is clearly not optimal because:
  • The SP has to contact each InPs individually.
  • The SP only knows what is available when he/she negotiates with the each individual InP.
  • The InP allocates infrastructure resources manually, which may not use the physical infrastructure resource efficiently in terms of resource utilisation.
Solution Therefore, the possibility to automate above process, or some parts of it, would be a useful enhancement to the Mantychore. In order to achieve this goal, a mechanism named Marketplace is proposed. The proposed marketplace is a resource broker that mediates between InPs and SPs/users. The Marketplace provides a set of services and tools designed to reduce costs and enhance the efficiency in the marketing of IP network services. In order to solve this design problem, Mantychore FP7 has designed the marketplace architecture: [caption id="attachment_2200" align="aligncenter" width="640" caption="Mantychore marketplace"][/caption]

 

  1. InP gets resource information (1) to publish the resource in the marketplace (MP).
  2. Publish resource information in the MP (2).
  3. Resource information is added in the MP module (3).
  4. The MP module gets all the necessary information from the Mantychore framework (Mchore) (4).
  5. SP needs a set of virtual resources. It sends a request  to the MP (5).
  6. The reservation module searches available resources (6)  among different Mchores (7).
  7. It is replied the available resources with all the necessary information (f.e: connectivity information)  to the SP (8).
Future and conclusions The ideas and necessary steps to implement the Mantychore FP7 marketplace are consolidated; the next objective is the implementation. In these steps, the Mantychore FP7 team are designing and discussing which parameters have to have defined in each published resource (for instance: Capacity, CPU or bandwidth) and which model representation standard will be able to come up all the requeriments. Currently,  Mantychore FP7 is cooperating using the CIM and NDL modeling tools.  Finally, Mantychore FP7 will finish its marketplace implementation and it will provide the necessary functionalities to manage the registered resources. To get more information, please visit our project page: project link - http://www.mantychore.eu/ wiki link - http://jira.i2cat.net:8090/display/MANTECH/Home Keywords a.- OPENNAAS. Framework with the objective to create a project neutral software community that allows several stakeholders to contribute and benefit from a common NaaS software stack.

Funding . Duration January, 1970 - January, 1970
Partners

How to build a FIBRE island (I)

This is the first of several posts where you can follow the process of choosing, installation and configuration of the components for the FIBRE Project i2CAT’s island testbed. As it was said in the previous post about the FIBRE project, one of the objectives of the project is to enhance the FP7 OFELIA facility with new equipment. In this first post we will present the several choices we are considering for the hardware we want to purchase, based on which is the objective of the FIBRE project. In later posts we list the purchased equipment, how it is installed in the i2CAT’s premises in the labs at Castelldefels and how it is configured to work properly. According to the FIBRE Project Document of Work, the i2CAT OFELIA island enhancement will “install some new OpenFlow-enabled switches to the existing infrastructure. It will also add a small subset (3-4) Wi-Fi access points, and consider the acquisition of traffic generator(s) and analyser(s). i2CAT may also be deploying the equipment to implement the European hub of the FIBRE facility, as it is one of the potential locations to play this role”. At the moment of writing this post, the acquisition of traffic generator(s) and analyser(s) is almost discarded due to budget limitations. The possibility of implementing the European hub of the FIBRE facility is being discussed by the European partners, and if finally i2CAT island is assigned as the European hub, the actual connection to RedIris will be used, so in principle no additional hardware should be necessary. [caption id="attachment_2270" align="alignleft" width="261" caption="SuperMicro SuperServer 6016T-T"]SuperMicro SuperServer 6016T-T[/caption] That leaves us with the issue in servers, switches and Wi-Fi access points. The servers will probably be 3 SuperMicro SuperServer 6016T-T. Each server will have 2 Intel Xeon E5620 processors, with 6GB RAM memory, 2TB of hard disk capacity and a 10/100/1000 Ethernet card. This is a similar configuration to the OFELIA servers, which have shown a good performance for the purpose of the project. Regarding the switches, the straightforward solution would be to acquire more units of the switches actually used in the OFELIA island. We are experienced with them; we know how to configure them and how to work with them. But one of the implicit purposes of the FIBRE project is to evaluate the performance of different OpenFlow implementations, and this solution would not contribute with new knowledge so we discarded it. We are considering acquiring three PRONTO TN3290 switches. According to the distributor specifications, these switches support OpenFlow right out of the box. It is one of the options available when the switch is booted up. Each switch has 48 10/ 100/ 1000BASE-T RJ45 ports and 4 10Gbps SFP+ uplink ports, so we will add at least two SFP Transceivers to each switch, but if final budged allows it, we will add four of them. [caption id="attachment_2271" align="aligncenter" width="468" caption="Switch PRONTO TN3290"]Switch PRONTO TN3290[/caption] Finally, regarding to the Wi-Fi access points, we do not look specifically for OpenFlow enabled devices. Instead of this, we will use the OpenWrt technology. OpenWrt allows turning a cheap commercial wireless router and access point into an OpenFlow enabled switch with a WebUI and a CLI. This solution will help us to avoid purchasing expensive OpenFlow-enabled equipment. That is the equipment that is being considered to purchase. Once it is acquired, it will be installed in the i2CAT lab premises at Castelldefels, where the i2CAT’s OFELIA island is deployed.  

Funding . Duration January, 1970 - January, 1970
Partners

How can a look back get us closer to the future

In his paper “Timer-Based Mechanisms in Reliable Transport Protocol Connection Management,” published in 1981, Richard Watson provides a fundamental theory for achieving reliable transport connection management. But what is connection management about? Transport protocols designed for reliable transmission provide one or more error-controlled channels between transport address pairs (associations). A connection is said to exist and state information is maintained in connection records at each end of an association. The process of proper synchronization and evolution of the connection records in the face of the possible transmission delays, errors, end-node crashes is called connection management. Connection management has three logical phases:

  1. Initializing (opening) of the connection records at each end
  2. Evolving the state of the connection records during ongoing data transfer
  3. Terminating (closing) state information when no further data requires transferring
Watson formulates the logical conditions that need to be met in order to achieve reliable transport connection management during the opening and closing phases: Opening
  • O1:  If no connection exists, then no packets from a previously closed connection should open a connection.
  • O2:  If a connection exists, then no packets from a previously closed connection should be accepted.
Closing
  • C1:  A receiving side must not close until it has received all of the sender’s retransmissions and can unambiguously respond to them.
  • C2:  Sending side must not close until it has received all acknowledgments (Acks) or allowed time for an Ack of its final retransmission to return before reporting a failure.
Ambiguity exists if a sender does not receive an Ack of some data sent. It will not know whether the data or the Ack got lost. All reliable transport protocols require explicit or clearly understood implicit bounds on three lifetime factors:
  • MPL (maximum packet lifetime): Maximum time a packet is allowed to live inside a network.
  • R: The maximum time a sender requiring a positive Ack will keep trying to retransmit a packet before ceasing retransmission.
  • A: The maximum time a receiver will hold a packet before sending an Ack.
[caption id="attachment_2326" align="aligncenter" width="478" caption="Three lifetime factors that need to be bound for reliable transport "][/caption] Then, three conditions are sufficient to assure perfect error control:
  • A1: An identifier (sequence number, SN) of an information unit used for assurance is never reused, while one or more copies (duplicates) of that unit or its Ack exist.
  • A2:  The assurance state or redundant information maintained at each end is never lost or damaged.
  • A3:   The assurance control information transmitted between each end is itself perfectly error controlled.
Watson compares how TCP and Delta-t, a transport protocol he developed at Lawrence Livermore Lab, deal with the three aforementioned conditions and relate them to the opening and closing conditions. TCP uses three separate management mechanisms to achieve assurance: 1) exchange of connection management (syn, fin) messages and associated state transitions, 2) careful choice of an initial sequence numbers and 3) assurance timers that implicitly bound MPL, A and R. On the other hand, Delta-t relies on a single timer mechanism that explicitly bounds MPL, A and R. This classifies Delta-t as a pure soft-state (SS) protocol, i.e., the state of a connection at the sender and receiver can be safely removed once the connection-state timers expire without the need for explicit removal messages. TCP’s approach can be viewed as a hybrid hard-state/soft-state (HS+SS) protocol. The comparison is done in terms of complexity (special mechanisms and transition states required), message overhead and connection-record resources requires by both protocols. Watson proves that explicitly bounding MPL, R and A are necessary and sufficient conditions for synchronization. Delta-t achieves transport-connection management reliably and reduces the number of messages and the resources required to maintain a connection’s state providing a mechanism far simpler than in TCP. Amongst Watson’s findings was also the decoupling of port allocation and synchronization, recognizing the distinction between the two functions. [caption id="attachment_2293" align="aligncenter" width="626" caption="Decoupling port allocation from synchronization"][/caption] So, why was TCP selected to replace NCP and not Delta-t? As John Day writes in his book “Patterns in Network Architecture: A return to fundamentals”: “Probably the foremost factor in the choice was that the Internet was a DoD (US Department of Defense) project and TCP was paid for by the DoD. This reflects nothing more than the usual realities of interagency rivalries in large bureaucracies and that the majority of reviewers were DARPA contractors”. Delta-t was a radically new idea in protocols with a more robust timer-based synchronization mechanism that essentially eliminated connection establishment and closing phases as new connections were established without an explicit handshaking or closing sequence. It also used separate PDU types for Ack and flow control and separated the transport and network functions. Now, Recursive InterNetwork Architecture (RINA) uses a soft state data transfer protocol, the Error and Flow Control Protocol (EFCP) that is built around Watson’s Delta-t protocol. The principles proven by Watson were held intact. The main difference is that EFCP guided by another fundamental principle, the separation of mechanism and policy, is split into two independent protocol machines (Data Transfer Protocol and Data Transfer Control Protocol), loosely coupled through a state vector. This gives EFCP the ability to cover a wide range of operation by plugging different policies. Gursun et al. in “Performance and Robustness of Managing Reliable Transport Connections” provided a performance comparison study that compares the hybrid HS+SS approach of TCP against the SS approach of Delta-t. The results show that the SS approach is more robust, and has lower message overhead and higher goodput, making it the best choice for reliable applications. Also, Boddapati et al. in “Assessing the Security of a Clean-Slate Internet Architecture” proved that Delta-t is also more secure than TCP by comparing the security of RINA to the current Internet architecture. And that takes us to the future... All these simply mean that the transport protocol of the future can be more efficient, more robust, more secure, more flexible and simpler.

Funding . Duration January, 1970 - January, 1970
Partners

WSO2 Stratos as a cloud platform

The RAISME platform will be an open source platform and form the basis of an open-source community consisting of individuals, teams and organizations working to build a world-class and innovative open source mash-up platform that allow users to integrate services and build their desired work-flows with them. Users will be able to create analyses and different visualizations of the data, they will be able to create their own mashups through different services creating their own application. The RAISME Web site offers several ways that allow visitors/users to get involved and contribute to the community. 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.

Funding . Duration January, 1970 - January, 1970
Partners

Research projects in OFELIA

OFELIA facility has been open to the research community for free for some months already. First projects performed on it were mainly related with testing of the same facility, intra-federation of the individual islands, presentation to the FP7 FIBRE project's partners in Brazil and so on. 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

EULEROn 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.

Funding . Duration January, 1970 - January, 1970
Partners

On Network Management and Virtualisation

Traditionally, network management has been developed around three main tasks: node management, node control (or configuration) and node monitoring. In a conceptual plane, this approach is still valid, but is clearly limited in scope: the bounded network domain (or simply 'network', in the sense of 'administrative network domain'). However, being this so tightly related to the node and its technology, makes it difficult to focus on the network service provisioning and management. Things even go worse when considering inter-network services, which have to tackle inter-domain scenarios, user profiling and interfacing, and the distributed nature of present and future computing paradigms. It is precisely in the latter where, as a matter of fact and business, virtualisation has revolted IT service provisioning, materialising in Cloud Computing and making more evident that network management is not prepared for it. 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.   [caption id="attachment_2465" align="aligncenter" width="720" caption="PC HAL compared to an approach to Network Virtualisation"][/caption] 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?

Funding . Duration January, 1970 - January, 1970
Partners

About Joan A. García-Espín

M.Sc. Joan A. García-Espín (joan.antoni.garcia@i2cat.net) is a research project manager at the Distributed Applications and Networks Area (DANA) of the i2CAT Foundation. He received his Telecommunication Engineering degree from the Technical University of Catalonia (UPC) in 2007. He wrote his Master Thesis in design and implementation of TE-enabled, DiffServ-aware MPLS networks for providing end-to-end QoS, also in 2007. He is a PhD candidate in the Telematics Engineering Department of the UPC. He is currently working in European projects FP7 GEYSERS (WP3 Leader) and GÉANT3. He has also participated in various European projects such as FP6 PHOSPHORUS and FP7 FEDERICA, and national (Spanish) projects including Enigma, Enigma Enhanced (Enigma II) and E3MS. He owns experience in optical networking, dynamic switching and management systems for networks, QoS and DiffServ for MPLS networks and infrastructure virtualisation. He is an active contributor to the NSI-wg and ISOD-rg gropus in the Open Grid Forum. His main research interests are cooperative agent interaction for network service provisioning, infrastructure virtualisation and network resource sharing and allocation.

OpenNaaS Announcement

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).

[caption id="attachment_2667" align="aligncenter" width="423" caption="The Functional Layered Model"]The Functional Layered Model[/caption]

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.
  • Bamboo (Mantychore members only): continuous integration server and release management.
  • GitHub: hosting service where find the source code and the releases.

Funding . Duration January, 1970 - January, 1970
Partners

The successful BonFIRE first OpenCall

BonFIRE facility has been opened to incorporate experiments into the project. The possibility to run experiments funded by BonFIRE consortium was advertised through an Open Call. A group of external evaluators selected from the amount of candidates, the five proposals that fulfilled better the scope of the Open Call.

[caption id="attachment_2713" align="aligncenter" width="940" caption="BonFIRE infrastructure"][/caption]

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!

Funding . Duration January, 1970 - January, 1970
Partners

Going Agile in FP7 research projects

(This post is a summary of the material I had the opportunity to present at EGI TF Lyon 2011, thanks to Marc-Elian, check it out) 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:

Individuals and interactions over processes and toolsFp7 projects are done by collaborative consortia distributed all over Europe. This often leads to distributed development teams, shared dedication spread over a 30 months time line.
Working software over comprehensive documentationDeliverables and Milestones are the primary tool the EC uses to track the progress of a project. Unfortunately documentation deliverables and milestones are a one-shot snapshot of the state of the project and do not match well with evolving documentation.
Customer collaboration over contract negotiationYou probably have your end user as part of the consortium. You also have a contract, not with them, but with the EC. This can get twisted.
Responding to change over following a planFp7 projects are approved and executed over a work plan. The central axis of this work plan is a Gantt chart that coverts a 20-30 month time line. To make matters worst, there can be almost a year of delay between the final Gantt draft and the actual start of the project. If you want to iterate, you'll have to iterate on those constrains.
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)
[caption id="attachment_2733" align="aligncenter" width="640" caption="Mantychore FP7 work plan task classification"][/caption]

 

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

The third group will be composed of the different development teams. Here you will want to have as less fragmentation as possible. While this is not something that can be easily avoided, distributed development has always a high performance cost. Be aware of it. You might be tempted to join all the developers from different organizations into a single distributed team. We have found this to be a bad idea, sprints will be dragged down by communication overhead. Moreover, a team is, by definition, a group of people with shared goals and objectives. According to your project's description of work, each organization will have defined different complimentary goals. Treat every organization developers as an independent team, fully responsible of their own sprints, even if it is just one person, or half. You should also identify the main development team. This is the one that is central to the development, will take care of integrating the different parts and, most likely, concentrates most of the effort. You will need the Scrum Master to be there. Two thirds of implementing SCRUM is coaching the team into it. Having a Scrum Master that is co-located with the team and spends time with them is key to success. Before we move into the Scrum Master role, let me emphasize the importance of having a consortium-wide demo. The Product Owner, and any interested end user, should join the team over a video-conference to inspect the latest release and provide feedback.

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!

Funding . Duration January, 1970 - January, 1970
Partners

LTE & ETHERNET FUTURE OPPORTUNITIES

Network convergence has been one of the hot topics in industrial and scientific conferences and congresses during the last years. In this sense, IP technologies seem to be the industry election for matching the application requirements and network operator’s constraints. For instance, IMS (IP Multimedia Subsystem) is a wide implemented platform which is been commercially adopted for service delivery. 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.

Funding . Duration January, 1970 - January, 1970
Partners