APAN 29th - Sydney 10th February 2010

1. FEDERICAFederated e-Infrastructure supporting research experiments on new Internet architectures and protocolsExperience and next stepsMauro Campanella - GARRmauro.campanella@garr.it APAN 29th - Sydney 10th February 2010

2. FEDERICA introduction and user requirements Framework, architecture Infrastructure status Service model, how to access challenges Federating FEDERICA Evolution and Conclusions Agenda

3. What: European Community co-funded project in its 7th Framework Program in the area “Capacities - Research Infrastructures”, 3.7 MEuro EC contribution, 461 Person Months When: 1st January 2008 - 30 June 2010 (30 months) Who: 20 partners, based on stakeholders on network research and management: 11 National Research and Education Networks, DANTE (GÉANT), TERENA, 4 Universities, Juniper Networks, 1 small enterprise (MARTEL), 1 research centre (i2CAT) - Coordinator: GARR (Italian NREN) Where: Europe-wide e-Infrastructure, open to external connections FEDERICA at a glance

4. Virtual Infrastructures (slices) Router/Switch Host for Virtual nodes Ethernet 1 Gbps FEDERICA Physical Infrastructure GÉANT2 and NRENs Infrastructure FEDERICA • Deploy and manage an e-Infrastructure (FEDERICA) based on virtualization in bothcomputers and network elements as a fundamental tool/playground for researchers on current and Future Internet, its uses and technologies. • It allows researchers a complete control of their set of resources (a “slice”), poses a minimum number • of constraints and enables disruptive • experiments at all communication • layers over a realistic substrate. Particular care is placed in reproducibility of the experiments and in the avoidance of complexity.

5. FEDERICA Framework • The infrastructure requirements brought to 2 key framework choices for the infrastructure, at the core of design: • The simultaneous presence of computing and network physical resources. These resources form the substrate of the infrastructure. • The use of virtualization technologies applied both to computing and network resources. • Virtualization will allow creating virtual, un-configured resources. • Framework is compatible with the Infrastructure as a Service (IaaS) paradigm of “clouds”, including the network layers and it may offer also other services (e.g. PaaS and AaaS).

6. FEDERICA - Current Architecture • Two levels: • The virtualization substrate. The physical infrastructure which contains all the hardware and software capable to create the virtual resources. • The level containing all virtual infrastructures (slices). Each slice contains a set of virtual resources and their network topology. • Two elementary resource entities: • 1. Connectivity. In form of a bit pipe (point to point circuit) with or without capacity guarantees and with or without a data link protocol. • 2. A computing element and its attributes, offering the equivalent of a computer hardware containing at least RAM, CPU and one network interface, mass storage is optional. The computing element is capable of hosting various operating systems and perform also functionalities (e.g. routing). This is different from “Clouds” where storage is considered an independent entity.

7. Infrastructure Status is up and running KTH SE SUNET NORDUNET DFN DE PSNC PL HEAnet IE GARR IT CESNET CZ SWITCH CH Red.es ES GRNET ICCS GR FCCN PT i2CAT ES Hungarnet HU All links are 1 Gbps Ethernet Each PoP hosts one or more large PC and a network switch/router

8. FEDERICA substrate The Core Substrate - HW Router / Switch: Juniper MX480, Dual CPU, 1 line card with 32 ports at 1Gb Ethernet. Virtual and logical routing, MPLS, VLANs, IPv4, IPv6, 2 of the 4 line cards have hardware QoS packet-based capabilities V-Nodes: each is a 2 x Quad core AMD @ 2GHz, 32GB RAM, 7+1 network interfaces, 2x500GB disks, VMware ESXi 3.5

9. NRENs and Global Internet FEDERICA substrate The Core Substrate - IP Management plane is a single IP Autonomous System: AS 47630 : (public, no transit, all 4 core nodes peer with local NRENs which announce the AS to GN2 and Global Internet) active IP v4 : 194.132.52.0/23 (public addresses) active IP v6 : (ready - under tests)

10. The basic service model • The FEDERICA basic service (create “virtual infrastructures” with full user control) is only lightly dependent on the underlying architecture. • The project made a choice to have two characteristics of the service that imply manual intervention in the initial phase of user access: • the User Policy Board to accept, register, prioritize and counsel • the users’ proposals (AAI is included here) • the overallreproducibility requirement which requires a manual • mapping from physical to virtual resources. Advanced • brokers / technologies / overprovisioning may overcome this • limit (see ongoing work in clouds). • Once the user has access to his slice he has full control.

11. Virtual Internet Virtual to Physical resource mapping • The step to map to the physical resources the virtual resources has been chosen to be performed manually in FEDERICA. • The motivations are: • the request to ensure • reproducibility • optimization of the use • of the infrastructure.

12. FEDERICA versus other projects

13. How To Request Access • A user information pack is available in the web site, containing : • Simple Memorandum of Understanding (*) • Acceptable User Policy, Access Rules • Guide for proposals, brief Introduction to FEDERICA • Technical template(*), feedback template • Requests have to be addressed at • fed-upb (at) fp7-federica.eu • Information can be requested at • info (at) fp7-federica.eu • (*) mandatory documents

14. There are a some key challenges for the evolution of the project and tightly connected to virtualization : “Real” versus “Virtual”, i.e. reproducibility/QoS Virtualizationservice definition and automation of procedures, in particular resource mapping. Federation Complexity These areas are coupled through e.g. definition and standardization of resources, control, management and monitoring, security and policies for resiliency. Research areas (Challenges)

15. The reproducibility and the stability in time of the behaviour of the virtual resources is a fundamental requirement for quantitative evaluations of new ideas. As an example, a virtual circuit may not be capable of offering a constant, fixed amount of bit per second, and a virtual computer image may not provide a constant CPU percentage and/or a constant disk access capacity. The quality of a virtual resource can then be defined as the measured reproducibility and stability of its behaviour when external conditions change (e.g. a virtual machine is added or the total network traffic increases). The difference between the behaviour of the virtual and the physical resource is another parameter which may be considered as a scale factor. Yet the virtual machine may have a good “quality” even if it underperforms the specifications. Research areas: Real v.s. Virtual

16. FEDERICA introduction and user requirements Framework, architecture Infrastructure status Service model, how to access challenges Federating FEDERICA Evolution and Conclusions Agenda

17. Proposal to differentiate between various forms of federation: integrated ( the facilities can be used as one with a inter-domain common control plane) partially integrated (only part of the control is exchanged, e.g. calendar, AAA information) overlay (each facility just uses the services of the other without a common control plane, just a data plane. here Exchange of information related to monitoring, faults, and so on is possible) All these types present challenges. Federating FEDERICA

18. Issues for federations: Having a common control plane in a multidomain environment is very difficult, as it places many constraints to each facility (in time, technology and developments) (Integrated) Need to develop standard resources representation schemas for virtual resources and virtual resource sets to exchange services. The inter-facility exchange of information and synchronization between facilities has to scale gracefully (all schema). The Intra-facility controlplane is complex, due to resource scheduling and resources mapping from virtual topology (slice) to physical topology, especially if reproducibility or guarantees are mandated. (all schema, related to dynamic provisoning) Federating FEDERICA (cont)

19. NRENs and Global Internet FEDERICA substrate FEDERICA - Onelab pre-federation(overlay) OneLab nodes can be hosted in a slice. Those node have full control of their network interface and circuits up to the egress from FEDERICA into General Internet. Onelab Slice

20. NRENs and Global Internet FEDERICA substrate (only CORE is shown) Federating slices, e.g. FEDERICA can create a slice containing fully meshed routers. The test topology between them can be chosen by the user enabling or disabling interfaces on the routers. Virtual routers’ slice User’s management slice (VLAN)

21. Continue to federate at the slice level in the overlay model Consider brokering slices (need to understand SLA) and extend collaboration to other projects Evaluate challenges of federating at the substrate level. The main issue is the virtual resources mapping to the physical substrate (reproducibility). Agree and develop federated monitoring and resource representation Discuss user's requirements for physical interconnection including the optical layer Federating FEDERICA plans

22. FEDERICA introduction and user requirements Framework, architecture Infrastructure status Service model, how to access challenges Federating FEDERICA Evolution and Conclusions Agenda

23. Proposed e-Infrastructure evolution(under evaluation) KTH SE Univ. of ESSEX SUNET NORDUNET Janet UK HEAnet IE DFN DE PSNC PL RENATER FR GARR IT CESNET CZ Red.es ES GRNET ICCS GR FCCN PT SWITCH CH i2CAT ES Hungarnet HU FEDERICA II University of Essex as advanced optical PoP

24. Conclusions • For Future (and present) Internet research and evolution, FEDERICA-like infrastructures, enable innovative paths, exploiting virtualization both in computers and networks. • FEDERICA creates virtual infrastructures, behaving almost like real ones, which can be seen as generalised, “cloud” infrastructures. The user access is simple from any place connected to Internet. Universities, Private Enterprises even schools may benefit from such ready-to-use environment. • Many challenges and research areas are still to be explored, analyzed to create a common set of standards. • Virtualization facilitates and draws a smoother path to federation too.

25. More Information • Main source of information is http://www.fp7-federica.eu • (all deliverables and documents, user access portal redirection) • July 2008 - EURESCOM mess@ge, issue 2/2008, "The FEDERICA Project- A federated infrastructure for Future Internet research" - page 11 • Dae Young Kim, Laurent Mathy, Mauro Campanella, Rick Summerhill, James Williams, Shinji Shimojo, Yasuichi Kitamura, Hideaki Otsuki, "Future Internet: Challenges in Virtualization and Federation," aict, pp.1-8, 2009 Fifth Advanced International Conference on Telecommunications, 2009, Venice/Mestre, Italy, May 24-May 28, ISBN: 978-0-7695-3611-8 • P. Sezgedi, S. Figuerola, M. Campanella, V. Maglaris, C. Cervello-Pastor: "With Evolution for Revolution: Managing FEDERICA for Future Internet Research", IEEE Communications Magazine Vol.47 No.7 pp. 34-39, July 2009 • M.Campanella, "The FEDERICA Project: creating cloud infrastructures", In Proceedings of Cloudcomp 2009 (CloudComp), October 19-21, 2009, Munich, Germany. ISBN 978-963-9799-77-6,

26. National Research & Education Networks CESNET Czech Rep. DFN Germany FCCN Portugal GARR (coordinator) Italy GRNET Greece HEAnet Ireland NIIF/HUNGARNET Hungary NORDUnet Nordic countries PSNC Poland Red.es Spain SWITCH Switzerland Small Enterprise Martel Consulting Switzerland NRENs organizations TERENA The Netherlands DANTE United Kingdom Universities - Research Centers i2CAT Spain KTH Sweden NTUA (ICCS) Greece UPC Spain PoliTO Italy System vendors Juniper Networks Ireland FEDERICA Consortium

27. Thank you for your attention