Deliverable NA2.2 FEDERICA User Community and Requirements

Document Sample
Deliverable NA2.2 FEDERICA User Community and Requirements Powered By Docstoc
					Federated E-infrastructure Dedicated to European Researchers
Innovating in Computing network Architectures

Co-funded by the European Commission within the Seventh Framework
Programme. Grant Agreement No. RI-213107




Deliverable NA2.2:
FEDERICA User Community and
Requirements
Version 0.6

Dissemination Level         Public
Contractual Date of         30 September 2008
Delivery
Actual Date of Delivery     6 April 2009
Editor                      P. Szegedi – TERENA
Contributors                J. Navratil – CESNET
                            P. Sjödin, M. Hidell – KTH
                            J. Ferrer - i2CAT
                            V. Reijs – HEAnet
                            S. Naegele-Jackson – FAU
                            M. Rösler-Lass, P. Kaufman – DFN
                            M. A. Sotos – RedIRIS
                            K. Meynell - TERENA
Reviewers                   M. Campanella – GARR

Abstract

NA2 ”Building and consolidating the User Community” is focused on establishing a
strong relationship with users and between the users to the scope of gathering
requirements, and facilitating the flow of information and ideas between users, in
particular when the users are in different research communities. The deliverable
DNA2.2 is a revised and expanded version of DNA2.1, based on the initial feedback
loop from users involved in the project. The document also contains a preliminary
segmentation of the user community.




                                         1
Deliverable NA2.2:
FEDERICA User Community and Requirements


Table of Contents

1    Introduction and motivations............................................................................ 3
    1.1    Basic motivations for the current work.......................................................... 3
    1.2    Document overview ...................................................................................... 4
2    FEDERICA UPB procedures ............................................................................ 5
    2.1    User Policy Board......................................................................................... 5
    2.2    Procedures and basic documents ................................................................... 6
    2.3    Internal user trial........................................................................................... 7
3    First user proposals ........................................................................................... 9
    3.1 G3 system – The monitoring test slice (CESNET)......................................... 9
      3.1.1 Requirements ......................................................................................... 9
    3.2 Phosphorus – The scalability study slice (i2CAT) ....................................... 10
      3.2.1 Test cases (in different slices)............................................................... 11
      3.2.2 Overall requirements ............................................................................ 15
    3.3 OpenFlow – The protocol experiment slices (FAU/DFN, GARR, KTH) ..... 16
      3.3.1 OpenFlow protocol tests....................................................................... 16
      3.3.2 OpenFlow as virtualization platform..................................................... 17
4    Preliminary user segmentation ....................................................................... 19
    4.1    Users interested in FEDERICA resources ................................................... 20
    4.2    Users interested in virtualisation platforms/concepts ................................... 23
    4.3    Users interested in peering/federating with FEDERICA .............................. 24
5    Conclusions and further work......................................................................... 25
    5.1    Conclusions ................................................................................................ 25
    5.2    Plans for user consultation events................................................................ 25
    5.3    Further work ............................................................................................... 26
References .............................................................................................................. 27
Appendix I – UPB documents ............................................................................... 28
    D1-FEDERICA-Letter-Introduction-v2.2.doc...................................................... 28
    D2-FEDERICA-Basic-User-Information-v2.1.doc............................................... 30
    D3-FEDERICA-Access-Rules-v2.1.doc .............................................................. 38
    D4-FEDERICA-Acceptable-Use-Policy-v1.0.doc................................................ 41
    D5-FEDERICA-Resource-Description-v0.3.doc.................................................. 44
    D6-FEDERICA-MoU-v1.0.doc ........................................................................... 47
    D7-FEDERICA-Project-Plan-v0.2.doc ................................................................ 50
    D8-FEDERICA-User-Feedback-v1.0.doc ............................................................ 53




                                                             2
Deliverable NA2.2:
FEDERICA User Community and Requirements



1          Introduction and motivations

NA2 ”Building and Consolidating the User Community” was established as one of the
key activities within the FEDERICA project. The aim is to identify potential users of
the infrastructure, understand their needs and requirements, and feed these back into
the development process. The deliverable DNA2.2 is a revised and expanded version
of DNA2.1, based on the initial feedback loop from users involved in the project.


    1.1    Basic motivations for the current work

It was proposed in DNA2.1 (March 2008) to divide the user consultation process into
four distinct phases. The phases with the updated time frames are as follows:
     1.   Preliminary user consultation (January 2008 – October 2008)
     2.   Internal feedback (November 2008 – March 2009)
     3.   Selected external user feedback (April 2009 – December 2009)
     4.   Third-party trials (January 2010 – June 2010)
The current deliverable has been postponed to March 2009 hence it covers the first
two phases of the consultation process.
The aim of the first phase (Preliminary user consultation) was to define the internal
project requirements and primarily involves the FEDERICA participants, as well as
selected network researchers in the research and education community with whom
they have previously collaborated (known as internal users). The internal user groups
have been consulted by the FEDERICA NA2 partners and the preliminary
requirements/findings have been reported in DNA2.1 (March 2008). Those
requirements are fed back to the development process, performed by the Service
Activities. During the first phase of the NA2 activity the User Policy Board was set up
and the basic procedures and documents were defined and prepared.
The preliminary consultation phase was ended by the successful launch event of the
FEDERICA infrastructure in November 2008, held in Lyon, France. At that time the
FEDERICA core network was up and running and able to accommodate the first
slices as was demonstrated during the event. Not just the technical conditions but the
administrative procedures were ready to introduce FEDERICA to the internal and
external users.
The aim of the second phase (Internal feedback) was primarily to consult the internal
users and test the early implementations of the FEDERICA infrastructure: the
application process for a slice (handled by the User Policy Board) and the technical
slice creation process (done by the Network Operation Centre). The experiences have
been used to help the SAs to debug and improve the implementation, and NAs to
refine the specifications that can be offered to the external users.
This deliverable summarises the findings of the NA2 consultation process’ first two
phases and defines the following steps towards the external users and third-party
trials.


                                           3
Deliverable NA2.2:
FEDERICA User Community and Requirements




 1.2     Document overview

In general, the NA2 activity focuses on the policy and administrative aspects of the
application and slice creation processes (i.e. giving tailored support to the users and
gathering requirements, feedback from them) while SA2 activity describes the
technical aspects of the provisioning process (i.e. slice creation by the NOC).
The structure of the deliverable is as follows:
   •   Section 2 describes the User Policy Board and its procedural rules. The
       procedures have been tested by the internal users. This section also reports the
       first observations, remarks from a ‘naive user’ point of view.
   •   Section 3 contains the first proposals for requesting a FEDERICA slice. These
       internal user proposals may lead to 2-5 FEDERICA slices in the near future.
   •   Section 4 lists the external users who have been approached by the NA2
       partners (up to March 2009) and defines the preliminary segmentation of the
       users.
   •   Section 5 concludes the deliverable and defines the future steps. The plans for
       the first user consultation events are explained, as well.
   •   Appendix I includes all the UPB documents (to be updated regularly).




                                            4
Deliverable NA2.2:
FEDERICA User Community and Requirements



2           FEDERICA UPB procedures

By definition, the FEDERICA User Policy Board (UPB), comprising members
elected by the General Assembly, is responsible for user governance. It examines and
prioritises requests for network use according to the network capabilities and the work
plan of the external researchers. It defines an Acceptable Use Policy (AUP) to allow
access to the infrastructure and defines a set of actions to ensure user privacy, IPR
(Intellectual Property Rights) guarantees and user obligations.
In this section the UPB, its processes and documents are introduced, then the first
feedback on the UPB processes provided by the Irish users are summarised.


    2.1     User Policy Board

The FEDERICA User Policy Board was set up during the General Assembly meeting
in June 2008, held in Barcelona, Spain. The main responsibility of the UPB was to
define the procedures, policy and prepare all the basic documents that are needed to
submit a FEDERICA slice request by an external user. The members of the UPB were
elected by the GA with an initial mandate of two years. The list of the UPB members
can be found in Table 1.


                    Table 1: FEDERICA User Policy Board members
          Member                                     Affiliation
          Peter Kaufmann, Chair                      DFN
          Victor Reijs                               HEAnet
          Cristina Cervelló-Pastor                   UPC
          Alexander Gall                             SWITCH
          Björn Pehrson                              KTH
          Mauro Campanella                           GARR
          Vasilis Maglaris                           NTUA
          Peter Szegedi                              TERENA


The main role of UPB in the first user consultation phase was to define and prepare
the FEDERICA UPB documents that can be provided to the potential users. Stepping
into the second phase (after the successful launch event) the main role of the UPB has
been changed. It regularly updates and maintains the UPB documents, of course, but
the main role now is to examine and prioritise requests for network use according to
the network capabilities and the proposed work plan. The UPB makes a technical (not
scientific) peer review evaluation of all research projects that request to use or be


                                           5
Deliverable NA2.2:
FEDERICA User Community and Requirements


connected to the FEDERICA e-Infrastructure, ensuring essentially that the use is non-
commercial, the sources and destinations are reachable, interfaces are compatible and
the use is compatible with the infrastructure capabilities at the requested time. EC
funded projects will be treated with priority.
It is also the role of the UPB to ensure user privacy (if needed) and to manage the
need of reporting the infrastructure use, providing feedback and acknowledging the
use of the infrastructure by the user.


 2.2    Procedures and basic documents

To access FEDERICA, formal procedures have been defined. The procedures are
needed to address both the evaluation of the technical requirements of the proposal
and the agreement on the conditions of the resource usage.
First of all, the user has to file the request to the e-mail address fed-upb@fp7-
federica.eu, attaching the relevant forms. The UPB has created five documents just for
information and three main forms that require response or interaction form the users:
Documents for information:
   •   “D1-FEDERICA-Letter-Introduction” gives a brief introduction to the UPB
       processes.
   •   “D2-FEDERICA-Basic-User-Information” provides a detailed introduction to
       the FEDERICA project.
   •   “D3-FEDERICA-Access-Rules-and-Guidelines” describes conditions for the
       access to FEDERICA (technically, financially and politically).
   •   “D4-FEDERICA-Acceptable-Use-Policy” (AUP) describes the usage
       conditions specific to FEDERICA.
   •   “D5-FEDERICA-Ressource-Description-and-Guidelines” describes the
       available resources and services within FEDERICA.
Documents (forms) for response or interaction:
   •   “D6-FEDERICA-Memorandum-of-Understanding” (MoU) presents the
       common understanding for the formal conditions to access FEDERICA. This
       document must be signed by the user and returned back to FEDERICA during
       the application process.
   •   “D7-FEDERICA-Project-Plan” presents guidelines for a project description.
       The application to FEDERICA requires a (brief) technical description of the
       user’s request and planned work.
   •   “D8-FEDERICA-User-Feedback” provides a template for the user’s feedback
       about using FEDERICA. It should be returned back at the end of the
       experiment within FEDERICA.
The full documents can be found in Appendix I and can also be downloaded from the
FEDERICA website (http://www.fp7-federica.eu).


                                          6
Deliverable NA2.2:
FEDERICA User Community and Requirements


The information received are analysed by the User Policy Board, in particular the
“D7-FEDERICA-Project-Plan” is needed to start the evaluation (The detailed
evaluation criteria can be found in Appendix I). During the evaluation process a
responsible UPB member interacts with the user. One of the most important
documents is the signed version of the “D6-FEDERICA-Memorandum-of-
Understanding”.
After the acceptance of the proposed project, the UPB transfers the documentation to
the technical activity (SA1 / NOC) for implementation.
At the end of the infrastructure usage, FEDERICA needs to receive a short report
from the user about the use of the resources, the communication with the project and
also achieved results (if publicly available) using the document “D8-FEDERICA-
User-Feedback”.


 2.3     Internal user trial

By the end of the first user consultation phase (November 2008) the FEDERICA core
infrastructure was up and running and the UPB processes and documents were ready
to use. In the second phase (Internal feedback) NA2 was focusing on the internal
users. The aim was to test/audit the UPB documents and the NOC slice creation
processes primarily with the internal users before we offer the service to the external
ones.
HEAnet and the Irish users applied for the trial. All the Irish users (listed in Table 2)
officially have the responsibility to take part in user requirement specification activity
of NA2 with 0.4 man month each. HEAnet is the coordinator of the Irish user
community and the contact point for them in the UPB.


          Table 2: HEAnet and Irish users participating in the UPB trial
   Affiliation                                             Contact person
   HEAnet                                                  Victor Reijs (0.4 MM)
   Coordinating the Irish user community                   UPB contact point
   Trinity College Dublin (TCD)                            Marco Ruffini (0.4 MM)
   Department of Computer Science
   Centre for Telecommunications Value-Chain
   Research (CTVR)
   Trinity College Dublin (TCD)                            Dr. René Meier (0.4 MM)
   Department of Computer Science
   Distributed Systems Group
   Waterford Institute of Technology (WIT)                 Miguel Ponce de Leon (0.4
   Telecommunications Software & Systems Group             MM)




                                            7
Deliverable NA2.2:
FEDERICA User Community and Requirements


   (TSSG)
   University College Dublin (UCD)                       Graham Williamson (0.4
   School of Computer Science and Informatics            MM)
   (CSI)


The Irish users have provided the first feedback as follows:
   •   The UPB documents (see Appendix) are fine in general but there is a lack of
       information about how external test beds can be connected to FEDERICA and
       its technical possibility is not clearly described.
   •   It is not explained well what kind of additional user services are available
       provided by FEDERICA. For instance, the availability of traffic
       generators/sinks or simulated user traffic inside the user slice.
The Irish users also suggested some requirements regarding the monitoring capability
of the FEDERICA infrastructure what could be useful from the users’ point of view.
   •   For Layer 3: the possibility to collect the routing messages that were
       exchanged, packet loss in the router queues, and possibility to monitor queue
       status (number and latency time of packets in the queue) is needed.
   •   In addition, some synchronized packet tracking mechanism that can trace the
       exact moment a packet enters and exits the routers on its path would be useful.
   •   For Layer 4: it would be very useful to have the possibility to monitor the
       behaviour of the TCP protocol at the source and sink nodes (as current Linux
       implementations do not give such possibility). This might be out of
       FEDEIRCA’s scope.
   •   For Layer 2: There is nothing to add at the moment.


These suggestions/remarks will be fed back into the NA2 activity (particularly into
the UPB) to enhance the processes and the documentation. The more detailed audit
process is ongoing.




                                           8
Deliverable NA2.2:
FEDERICA User Community and Requirements



3           First user proposals

In this section the first (internal) user proposals experimenting with FEDERICA are
introduced. The FEDERICA partners and the selected user groups with whom they
have previously collaborated are considered as internal users. The internal users have
proposed some research activities in their fields which have led or may lead to a
FEDERICA slice creation soon. The interested internal users are as follows: CESNET,
UPC/i2CAT, KTH, FAU/DFN, GARR and PoliTo.
The three proposals discussed in this section are at different stages: one of them has
already got a FEDERICA slice for testing purposes, one of them is close to submitting
the official slice request using the UPB documents, and one of them is only in the
planning phase.


    3.1     G3 system – The monitoring test slice (CESNET)

CESNET is responsible for the monitoring of the FEDERICA infrastructure including
all the active slices. The potential candidates for the SNMP-based monitoring solution
have been evaluated and finally the G3 System has been selected by CESNET. G3
was developed by CESNET (it is being used for monitoring the CESNET network) so
it is relatively easy to customise the system for additional FEDERICA requirements.
The aim is to provide both node-centric and slice-centric information to the NOC and
the end users about the FEDERICA’s actual usage.
To implement, test and further develop the G3 monitoring system inside FEDERICA
at least one user slice and some traffic is needed. Therefore, CESNET has requested
the NOC to create the first FEDERICA slice for testing purposes (since there was no
user slice in FEDERICA at that time). The test slice allows CESNET to generate
sample traffic and to analyse the G3 system capabilities.

    3.1.1   Requirements


The first test slice was set up and handed over to CESNET on 13 February, 2009. (It
is important to note that the CESNET request was sent directly to the NOC, i.e., the
official UPB processes were not considered.) The main purpose of the usage is to get
some basic information about the slices; how they are visible on the interfaces and in
the traffic demands between the nodes. The requested slice contains 3 nodes in the
first step, when only the core nodes are ready to participate in the slicing process. In
the next step, when the non-core nodes are also available, 2 additional non-core nodes
will be attached to the slice. The topology of the test slice can be seen in Figure 1.




                                           9
Deliverable NA2.2:
FEDERICA User Community and Requirements




            Fig.1: CESNET slice for testing the G3 monitoring system


However, CESNET’s plan for the future is to create a slice that will be presented in
all physical sites of FEDERICA. This slice could be converted into a complex
platform called CESNET CDN (Content Delivery Network). From monitoring point
of view, the traffic in the CESNET CDN is just the subject of measurement i.e.,
verifying the traffic volumes in the G3 monitoring statistics.


 3.2    Phosphorus – The scalability study slice (i2CAT)

i2CAT has proposed a potential collaboration between the FP6-Phosphorus and FP7-
FEDERICA projects testing the scalability of the Harmony architecture over the
FEDERICA infrastructure. When the official request (using the UPB forms) is sent to
the FEDERICA UPB this slice will be the first user slice not for internal tests but
performing real research work.
Harmony is a multi-domain Network Service Architecture, developed by the
Phosphorus project, enabling interoperability among various Network Resource
Provisioning Systems (NRPS). Harmony architecture has evolved from a centralised
Network Service Plane (NSP) model to a distributed NSP model, passing through a
mid stage, the multi-level, hierarchical NSP model.
In the early prototypes of Phosphorus the centralised model (see Figure 2a) was
deployed over a test bed with five underlying administrative domains. That attempt


                                         10
Deliverable NA2.2:
FEDERICA User Community and Requirements


became a good proof of concept but lacked scalability when dealing with a high
number of Harmony NRPS Adapters (HNA) due to signalling load. In order to solve
this problem, a hierarchical model was also implemented (see Figure 2b). This model
solved scalability deficiency of the original approach, but the performance of
Harmony’s NSP was still not good when the number of domains increased, due to
signalling bottlenecks appearing in large hierarchies. Finally, the third approach was
prototyped and consists of a distributed NSP model (see Figure 2c). This model has
been deployed over a virtual test-bed (where NRPS works in a virtual mode,
emulating physical equipment) and preliminary results showed an improvement of
performance and scalability in Harmony.




                          Fig. 2: Architectures in Harmony


Tests, performed in Phosphorus, have proved some expectations in NSP behaviour
depending on the models applied. However, all tests carried out over real and virtual
test beds have not enough results to select the best solution for large topologies
(production environment) due to the emulation environment limitations when creating
middle/large-size topologies.
The FEDERICA infrastructure can provide a large set of virtual hosts with good
connectivity for carrying out a set of extensive and intensive tests in the Harmony
architectures.

3.2.1   Test cases (in different slices)


Each test case represents one service plane model of the system (centralised,
hierarchical and distributed). The tests can be performed using dummy Harmony
NRPS i.e., there will be neither real NRPS deployed nor any physical equipment.
Instead, Phosphorus has created a prototype for a special HNA emulating a dummy
NRPS below. Thus, responses from dummy-HNAs will be generated automatically
inside the HNA and forwarded to the IDB (Inter-Domain Broker).


    1. Centralized architecture




                                           11
Deliverable NA2.2:
FEDERICA User Community and Requirements


The first test case considers a centralised architecture with one IDB controlling 30
different administrative domains. Each administrative domain is emulated with one
dummy-HNA (see Figure 3).




                    Fig. 3: Test case one: centralized NSP model


As there is only one IDB in the service plane, the system only has one point of entry.
It means that all the requests will enter the system via the IDB #1 and that all inter-
domain network resources requested will be controlled by this main IDB.


          Table 3: Requirements for test case one (centralised NSP model)

                                 Computing
   NSP                                                  Networking Requirements
             Constraints        Requirements
   Item                                                         per VM
                                  per VM
  1 IDB         1 VM        512 MB RAM – 20 GB         1x NIC with public IP address
                                   HDD                 1x NIC with private IP address
                                                       (LAN)
 30 HNA      1 VM per 4      1 GB RAM – 50 GB          1x NIC with private IP address
                HNA                HDD                 (LAN)
 TOTAL         9 VM                                    Interconnection between VMs
                                                       is only needed for signalling
                                                       purposes. No high
                                                       performance/BW links needed.




                                           12
Deliverable NA2.2:
FEDERICA User Community and Requirements


   2. Hierarchical architecture
The second test case considers a hierarchical architecture with three levels of IDBs
(see Figure 4). This NSP topology should be expanded, increasing the number of
stacked IDBs. In this test case, there are several points of entry to the system, since
there are 14 IDBs populating the service plane. The complexity in this test case lies on
the distribution of request arrivals over the several points of entry. The aim in this test
is to evaluate how performance is affected when increasing the number of IDBs
stacked.




                Fig. 4: Test case two: hierarchical NSP architecture


In order to approximate the tests to real behaviour, when the system is deployed in a
real environment, some formal definitions and considerations must be taken into
account (i.e., the probability of reserving a resource in the correct IDB or the
probability of not having to forward the request to the upper hierarchy level).


          Table 4: Requirements for test case two (hierarchical NSP model)

                                  Computing
   NSP                                                     Networking Requirements
             Constraints         Requirements
   Item                                                            per VM
                                   per VM
 14 IDB       1 VM – 3        1 GB RAM – 60 GB           Desired:
                IDB                 HDD                  1x NIC with public IP address
                                                         1x NIC with private IP
                                                         address (LAN)
                                                         Minimum:


                                            13
Deliverable NA2.2:
FEDERICA User Community and Requirements


                                                         1x NIC with public IP address
                                                         per VM
                                                         1x VM with public IP address
 30 HNA      1 VM per 4        1 GB RAM – 50 GB          1x NIC with private IP
                HNA                  HDD                 address (LAN)
 TOTAL         13 VM                                     Interconnection between VMs
                                                         is only needed for signalling
                                                         purposes. No high
                                                         performance/BW links
                                                         needed.


   3. Distributed architecture
The third test case aims to emulate the distributed NSP model, which is initially
planned to be composed of 20 IDBs sharing inter-domain topology information via
flooding protocol implemented for this operating mode in Harmony. Each IDB
controls one administrative domain emulated using dummy-HNA (see Figure 5).




                   Fig. 5: Test case three: distributed architecture


In this test case, there are also several points of entry to the NSP. However, in this test
case, the modelling of the tests is different, since each IDB has information about the
whole topology. In this sense, when a request is received in one IDB and the
resources requested are not under the control of such IDB, the broker only has to look
into its database and forward the request to the peer in charge of them.



                                            14
 Deliverable NA2.2:
 FEDERICA User Community and Requirements




          Table 5: Requirements for test case three (distributed NSP model)

                                   Computing
                                                          Networking Requirements
NSP Item Constraints              Requirements
                                                                  per VM
                                    per VM
 20 IDB       1 VM – 3        1 GB RAM – 60 GB         Desired:
                IDB                 HDD                1x NIC with public IP address
                                                       1x NIC with private IP address
                                                       (LAN)
                                                       Minimum:
                                                       1x NIC with public IP address per
                                                       VM
                                                       1x VM with public IP address
20 HNA       1 VM per 4       1 GB RAM – 50 GB         1x NIC with private IP address
                HNA                 HDD                (LAN)
TOTAL          13 VM                                   Interconnection between VMs is
                                                       only needed for signalling
                                                       purposes. No high
                                                       performance/BW links needed.



  3.2.2    Overall requirements


 The following table (Table 6) shows a summary of computing and networking
 resources needed in the three tests cases. Software requirements will be in charge of
 Phosphorus staff.


             Table 6: Software and hardware requirements for each VM

                              Virtual Machine Resources
Number                                              15 VM
Storage capacity                                700 GB max.
                                          (40 up to 150 GB per VM)
RAM                                             Minimum: 512 GB
(per VM)                                          Desired: 1 GB
                                                 Optimum: 2 GB
Networking                •   Public IP addresses are needed for VMs
                          •   Private LAN is needed for interconnecting VMs
                              (signalling)
                          •   No high performance networking needed.


                                           15
 Deliverable NA2.2:
 FEDERICA User Community and Requirements


OS to be installed by             Debian [Deb] GNU/Linux release 4.0 (etch)
Phosphorus WP1
Software to be used       •   Apache-tomcat.6.x or later [Atomcat]
by Phosphorus WP1         •   Mysql Server 5.0 or later [MySql]
                          •   Java 6 or later [Java]
                          •   Apache-ant-1.7.0* [Aant]
                          •   Sun JAXB 2.0.5* or later (used within the HSI module)
                              [Jaxb]
                          •   Apache Muse 2.2.0* or later (used within the HSI
                              module) [Amuse]


 i2CAT is planning to submit the official slice request(s) to FEDERICA using the UPB
 documents.


  3.3     OpenFlow – The protocol experiment slices (FAU/DFN, GARR, KTH)

 The FEDERICA partners have proposed two different experiments in connection with
 OpenFlow initiative.
 The first FEDERICA-OpenFlow proposal is a collaboration effort to join the Stanford
 initiative as a European partner. The plan is to deploy OpenFlow on the college
 campus of the University of Erlangen-Nuremberg, Germany, and within the
 FEDERICA infrastructure in cooperation with GARR, Italy.
 The second proposal aims to investigate OpenFlow as potential virtualization
 architecture for FEDERICA. (Note that this work is part of the JRA2 research activity
 in FEDERICA proposed by KTH.)

  3.3.1   OpenFlow protocol tests


 The Friedrich-Alexander University (FAU) of Erlangen-Nuremberg is planning to test
 the OpenFlow protocol on several switch types, depending on if the appropriate
 OpenFlow prototype patches can be obtained. Possible switch hardware includes the
 Cisco 6509 switch, the Juniper MX-480 switch and possibly a HP ProCurve switch of
 the 5400 series. All switches are part of the campus network with the exception of the
 Juniper MX-480 switch, which is part of the FEDERICA test bed. The FAU’s
 connection to FEDERICA is currently based on 4 x 1 Gigabit/s. With its support of
 both traditional campus network environments as well as innovative research
 infrastructures, the campus network of the University of Erlangen-Nuremberg can
 serve as a typical representative for university interconnectivity issues.
 In connection with an OpenFlow infrastructure FAU is aiming at studying
 performance and security issues in context with global and vendor independent access
 list handling. If possible, FAU would also like to gain insight into accumulated traffic



                                            16
Deliverable NA2.2:
FEDERICA User Community and Requirements


statistics of flows coming from several switches rather than having only statistics of
one single switch at hand.
Planned experiments in detail:
   •     The FAU is currently making plans to test the OpenFlow protocol on the
         FEDERICA infrastructure involving the Juniper MX-480. The experiments
         will include the installation of the required Juniper patch to allow OpenFlow
         processing within a network environment involving a small number of nodes
         and links. Investigations will also aim at performance measurements and
         security issues.
   •     The WiN-Labor of DFN at the Friedrich-Alexander University (FAU)
         Erlangen-Nuremberg has extensive related experience in network performance
         monitoring. Comparing performance data of the virtual FEDERICA
         infrastructure to a real measurement infrastructure, and testing the
         performance of other new developments like the OpenFlow protocol will be of
         great interest to the community. Investigations of this kind are planned with
         existing and new hardware components. Measurements of performance data
         (one way delay, delay variation, packet loss and available bandwidth) will be
         performed with the existing tools HADES (Hades Active Delay Evaluation
         System) and BWCTL (Bandwidth Test Controller). The controlled insertion of
         test traffic produces high resolution data revealing network performance
         essentials.
The OpenFlow environment will be setup gradually and will at first only involve a
subset of the indicated switches; more switches will be added later once the initial
tests have shown to be successful.



 3.3.2    OpenFlow as virtualization platform


From a virtualization point of view, OpenFlow could be seen as a slicing method. It is
a more general and flexible way of slicing compared to current methods, since it is not
confined to slicing by VLAN, MPLS tunnel, VPN, etc. Instead, since OpenFlow
allows slicing on a per-flow basis, OpenFlow virtual networks could be defined in
terms of groups of flows. Another feature of OpenFlow is a control and management
model where switches are controlled by an external entity over a secure channel. This
separation of control and switching gives a large degree of freedom in how switches
are controlled, which offers interesting potential in terms of user defined control
policies and algorithms.
KTH has proposed to investigate how virtualization architectures can be designed
based on OpenFlow, as a virtualisation layer that can support different virtualisation
paradigms. The purpose is to investigate novel virtualisation techniques using
OpenFlow, with focus on how OpenFlow could be used as a slicing mechanism for
FEDERICA (this activity is part of the JRA2 research work in FEDERICA).




                                           17
Deliverable NA2.2:
FEDERICA User Community and Requirements




               Fig. 6: Testing OpenFlow as virtualization platform


The overall goal is to explore OpenFlow as an architecture for network virtualisation.
Since OpenFlow is not primarily designed with virtualisation in mind, the first step is
to design a virtualisation layer on top of OpenFlow. This layer will provide a
virtualisation service interface to the user, and implement the service by mapping it
into OpenFlow operations. This also implies that the virtualisation layer will maintain
a virtual network abstraction, and the definition of this abstraction is one of the key
components of this work.
The architecture should be designed by identifying the components in an OpenFlow
network virtualisation architecture, and defining interfaces between them. The design
should be evaluated through an experimental study, where chosen key components in
the design are implemented and evaluated. The experimental platform could start
from an implementation in a Linux environment, using the software reference
implementation of OpenFlow. As the next step, experimental evaluation can be done
on a larger scale in FEDERICA, in case OpenFlow-enabled equipment (commercial
or open source) is available.


The OpenFlow proposals are in the planning phase and may lead to create some
FEDERICA slices soon.




                                          18
Deliverable NA2.2:
FEDERICA User Community and Requirements



4        Preliminary user segmentation

The users involved in the preliminary user consultation phase have been listed in the
fist deliverable DNA2.1 (March 2008). Since then, the NA2 partners have approached
many potential user groups and provided them the actual information about
FEDERICA. Obviously, until the successful launch event and the definition of the
UPB processes, it was not possible to give detailed technical and administrative
guidelines to the users. But still, we were able to identify some potential users
contacting the FEDERICA partners in their countries across Europe. We were also
able to contact with parallel projects, under the FIRE initiative and FIA, interested in
the FEDERICA services.
During the informal user consultations it was realised that we can differentiate at least
three main groups of users depending on their interest areas. We can use these groups
as the basis of the preliminary user segmentation that can be further studied and
refined. The identified user groups are as follows:
    1. Users interested in FEDERICA resources only
        This category is in the primary focus of NA2 activity. It contains all the
        potential users (internal and external) who want to apply for a FEDERICA
        slice to perform their own research work inside the slice.
    2. Users interested in virtualisation platforms/concepts
        There are some users/projects interested not only in the FEDERICA resources
        but in the whole virtualisation process. They want to know more about the
        virtualisation concept applied by FEDERICA, maybe they want to be a part of
        the slicing process and host a FEDERICA PoP.
    3. Users interested in peering/federating with FEDERICA
        In this group we can have the similar/parallel activities to FEDERICA dealing
        with the virtual infrastructure issues. It might be possible that FEDERICA can
        peer or federate with them. This activity is covered by NA3.
It can be seen that the above mentioned groups require different approaches, ways of
communication and details of background information from the NA2 activity’s point
of view. Our main objective is to give user support tailored to the specific group of
users.
In this section the users identified in all the three categories are listed and, where it
was possible, the interest areas and potential collaborations are mentioned. NA2 is
going to update/revise the list regularly and make a decision where to put the main
focus to build and consolidate the FEDERICA user community.




                                             19
Deliverable NA2.2:
FEDERICA User Community and Requirements


 4.1     Users interested in FEDERICA resources

The potential users interested in the FEDERICA virtual network resources have been
contacted by the NA2 partners. In the following tables, those user groups are listed
who have responded to the preliminary FEDERICA information kit.


The Irish users have been contacted by HEAnet (Table 7). They can be considered as
internal users since they officially have the responsibility to take part in the user
requirement specification activity of NA2. However, from the practical side, the Irish
users are handled by FEDERICA as ‘normal users’ i.e., they have to fill in and submit
the official UPB documents for requesting a network slice. Several of the users are
really into network protocol developments and are looking into the scalability of such
ideas on a larger scale.


                   Table 7: Irish users (expected in March 2009)
Organisation                          Contact person          Project / Interest area
Trinity College Dublin (TCD)          Marco Ruffini           Framework for building
Department of Computer Science        Dr. Donal               a multi-layer router
                                      O’Mahony                architecture, by
Centre for Telecommunications                                 providing typical
Value-Chain Research (CTVR)                                   integrated routing,
                                                              switching and signalling
                                                              functions.
                                                              Experiments in
                                                              IP/optical networks.
Trinity College Dublin (TCD)          Dr. René Meier          n/a
Department of Computer Science
Distributed Systems Group
Waterford Institute of                Miguel Ponce de         n/a
Technology (WIT)                      Leon
Telecommunications Software &
Systems Group (TSSG)
University College Dublin             Graham Williamson       Primary focus is large-
(UCD)                                                         scale distributed
School of Computer Science and                                systems, middleware
Informatics (CSI)                                             and sensors


The German users were contacted by DFN (Table 8). The following users replied to
the first call but, of course, more iteration rounds are needed before they will be ready
to request a FEDERICA slice.



                                           20
Deliverable NA2.2:
FEDERICA User Community and Requirements




                 Table 8: German users (expected in March 2009)
Organisation                       Contact person            Project / Interest area
Technische Universität Berlin      Thomas Kaschwig           Project Perimeter
DAI-Labor                          Fikret Sivrikaya          Native IPv6


Technische Universität             Prof. Dr.-Ing. Georg      n/a
München                            Carle
Institut für Informatik
Rheinische Friedrich-              Wolfgang Moll             Project ARGON
Wilhelms-Universität Bonn                                    AutoBAHN
Institut für Informatik

Friedrich-Alexander                Susanne Naegele-          OpenFlow protocol tests
Universität Erlangen-              Jackson
Nürnberg
Technische Universität             Paul Mueller              Project G-Lab
Kaiserslautern


Universität Passau                 Herman De Meer            Project PlanetLab



The Spanish users were contacted by RedIRIS (Table 9). The first user consultation
event, organised during the TERENA Networking Conference on 7 June, 2009, will
be held in Malaga, Spain. So, the Spanish users are the primary focus of that event.


                  Table 9: Spanish users (expected in March 2009)
Organisation                       Contact person            Project / Interest area
i2CAT                              Joan A. Garcia Espin,     PHOSPHORUS
                                   Jordi Ferrer, Sergi       Harmony system
                                   Figuerola                 architecture scalability
                                                             study
Universidad de Granada             Juan Manuel López         Massive deployment of
Dpto. Teoría de la Señal,          Soler                     applications based on the
Telemática y Comunicaciones                                  Data Distribution Service
                                                             (DDS) standard.
ETSI Informática y de
Telecomunicación.
Centro Informático Científico      Sebastián Balboa          Multicast IPv4 & IPv6


                                          21
Deliverable NA2.2:
FEDERICA User Community and Requirements


de Andalucía (CICA)                 García                     tests
Consejería de Innovación,                                      QoS for VoIP and video
Ciencia y Empresa
Junta de Andalucía
i2BASK                              Josu Arramberri            Bask Country Internet 2
                                                               network development
                                                               End-to-end provisioning
                                                               system
Universidad de Vigo                 Cristina Lopez Bravo       Novel massive data
                                                               transfer protocols
Uniersity of Pais Vasco (EHU)       Eduardo Jacob              n/a


Universitat Politècnica de          Jordi Domingo-Pascual      n/a
Catalunya (UPC)
Departament d'Arquitectura de
Computadors


The Swiss users were contacted by SWITCH (Table 10.) In general, they need to
know more about FEDERICA to be able to submit a potential slice request, so
SWITCH will take care of further consultations.


                  Table 10: Swiss users (expected in March 2009)
Organisation                        Contact person             Project / Interest area
Eidgenössiche Technische            Timothy Roscoe             n/a
Hochschule Zürich (ETHZ)
Ecole Polytechnique Fédérale        Karl Aberer                n/a
de Lausanne (EPFL)                  Rachid Guerraoui
                                    Jean-Yves Le Boudec
                                    Patrick Thiran
Universität Basel                   Christian Tschudin         n/a
Universität Berne                   Torsten Braun              n/a
Universität Zürich                  Burkhard Stiller           n/a


The Hungarian users were contacted by NIIF/HUNGARNET (Table 11). The next
coming NIIF national conference (NIIF Networkshop’09, on 15-17 April, 2009)
provides a good opportunity to organise a small consultation meeting and to meet
with the potential Hungarian users in person. The possibilities are being investigated.


                                           22
Deliverable NA2.2:
FEDERICA User Community and Requirements




               Table 11: Hungarian users (expected in March 2009)
Organisation                        Contact person             Project / Interest area
Eötvös Loránd University            Dr. Gábor Vattay           FEDERICA – OneLab2
(ELTE)                                                         interworking
Collegium Budapest


The identification and consultation of the potential user groups are at different stages
in the FEDERICA partners’ countries. The aforementioned users are already
identified but there are some on-going activities in other countries like Greece,
Norway, Italy, Czech Republic and Poland.


 4.2     Users interested in virtualisation platforms/concepts

When we started to approach not just the individual organisations but the potential
user projects and initiatives it was realised that some of the projects are really
interested in the whole virtualisation concept used by FEDERICA. Those user groups
may not want to use the FEDERICA resources at all, but want to understand and
examine the virtualization processes in general.
The following table (Table 12) contains the potential users who want to know more
about the networking and computing resource virtualisation concepts, platforms and
solutions.


Table 12: Users/Projects interested in virtualization concepts (expected in March
                                      2009)
Organisation/Project      Contact person            Interest area
RENATER                   Franck Simon,             Interested in hosting a FEDERICA
                          Danny Vandromme           PoP and take part in the slicing
                                                    process.
KTH                       Peter Sjödin,             Studying OpenFlow as a
                          Markus Hidell             virtualization platform for
                                                    FEDERICA.
EGEE-III project          Guillaume Cessieux        Primary interest is to experience the
                          (CNRS)                    virtual slice creation, in particular
                                                    the guaranteed bandwidth between
                                                    nodes.
                                                    They want to experience the slice
                                                    creation.
PASITO project            Miguel Angel Sotos        Examining platforms for analysis of
                                                    telecommunications services and


                                           23
Deliverable NA2.2:
FEDERICA User Community and Requirements


                         (RedIRIS)                experiments.

4WARD project            Norbert Niebert          Investigating Future Internet
                         (Ericsson)               architectures.
ANA project              Dr. Martin May           ANA project’s user community
                         (ETH)                    could be interested in virtualised
                                                  network architectures.


 4.3      Users interested in peering/federating with FEDERICA

The third group of users contains the infrastructure developers or owners working in
parallel with FEDERICA. They are not interested in the FEDERICA services (i.e.,
requesting a slice) but they may have some knowledge/experience in virtualised
network infrastructures. What they really want is to extend the boundaries of their
infrastructure, peering or federating with other infrastructures.
Here we can list the potential peering/federating partners of FEDERICA (Table 13),
but we note that the coordination of this activity is part of NA3.


   Table 13: Infrastructures for peering/federating (expected in March 2009)
Organisation/Project Contact person               Potential collaboration
GENI project         n/a.                         Very similar US initiative to
protoGENI                                         FEDERICA with much broader
                                                  scope.
G-LAB
VINI                    Andy Bavier               VINI is aiming at building a similar
                        (Princeton University)    infrastructure over Internet2/NLR.
National Institute of   Toshio Soumiya,           Building a similar network/service
Information and         Toshiaki Suzuki           in Japan.
Communications
Technology of Japan
(NIICT)
FIRE test beds          Georgios Tselentis        Collecting a matrix of users and
Unit F4                                           FIRE test beds.

FIA                     Paulo de Sousa            Some projects are waiting to use
Unit D                                            FEDERICA.

EURESCOM,               Anastasius Gavras         n/a.
FIREWORKS and
PII




                                           24
Deliverable NA2.2:
FEDERICA User Community and Requirements



5         Conclusions and further work


    5.1   Conclusions

The NA2’s aim is to identify potential users of the FEDERICA infrastructure,
understand their needs and requirements, and feed these back into the development
process. This requires an iterative approach and the first round of user consultations
has just been started.
In this deliverable we described the UPB administrative processes and included the
official documents/forms needed to request a FEDERICA slice. We summarised some
of the internal user requests that have been proposed. They are in different phases at
the moment but finally they may lead to 2-5 FEDERICA slices soon. Then, we listed
all the potential users who we have been contacted by and proposed the preliminary
segmentation of those users.


    5.2   Plans for user consultation events

It is important to note that the potential user groups are not considered as external
entities to be addressed only with questionnaires or to be informed on the FEDERICA
concept only. NA2 partners are planning to work closely with selected user groups,
visit their locations, understand the scope of their research and explain and design
with them how FEDERICA can be used.
In closed cooperation with NA4 dissemination activities, NA2 is planning to organise
a technical training and user consultation seminar immediately prior to the TERENA
Networking Conference on 7 June 2009, in Malaga, Spain. This would target network
engineers and potential users of the FEDERICA infrastructure, and would provide an
overview of the technical capabilities of this infrastructure, whilst providing
information on how to access it. It would also outline the procedures for requesting
slices, and what can be done with these. This would not only fulfil the requirements of
the NA4.3 training activity, but would also provide the opportunity to discuss with the
users the type of activities they might use FEDERICA for. This would allow their
requirements to be incorporated into the project plan.
It has been agreed with all the FEDERICA partners that NA2 will also organise
smaller, distributed user consultation events inviting local users during the project
lifetime. The best opportunity for that is to organise BoFs (Birds of a Feathers) during
the NREN events across Europe.
The next national NREN conference will be held on 15-17 April, 2009, in Szeged,
Hungary called NIIF Networkshop’09. NIIF and TERENA together have organised a
BoF on the first day of the conference inviting the potential Hungarian users. The plan
is that the technical details of the FEDERICA infrastructure will be explained by NIIF
(including the access to the local PoP) then, the UPB processes and the required
documents will be explained by TERENA, as member of the UPB and leader of NA2.


                                           25
Deliverable NA2.2:
FEDERICA User Community and Requirements


Finally, the users will have chance to ask technical and administrative question in an
interactive way.
The full list of potential face-to-face user consultation BoF events will be investigated
by NA4.


 5.3     Further work

As it was mentioned before, the iterative user consultation process has just been
started in some FEDERICA partners’ countries. The further steps could be as follows:
   •   Start to identify more user groups all over Europe and beyond (approaching
       FIRE, FIA, FIREWORKS, EURESCOM, etc.)
   •   Provide the latest information to the already identified users about the current
       status of the infrastructure and the official UPB processes.
   •   Based on the initial feedback, compile a matrix with the user organisations and
       projects to identify the potential focus points of NA2. Identifying the
       geographical locations of various users working on the same project could
       help the Service Activities to create a FEDERICA slice choosing the proper
       physical machines.
   •   Organise small, face-to-face user consultation events (i.e., BoFs during the
       national NREN conferences).
   •   Provide feedback to SA and NA activities.




                                           26
Deliverable NA2.2:
FEDERICA User Community and Requirements



References

[Aant]        http://ant.apache.org
[Amuse]       http://ws.apache.org/muse
[Atomcat]     http://tomcat.apache.org
[Fede-01]     http://fp7-federica.eu
[GAAA-tk]     http://staff.science.uva.nl/~demch/projects/aaauthreach/index.html
[Java]        http://java.sun.com
[Jaxb]        https://jaxb.dev.java.net/
[MySql]       http://www.mysql.com
[Phos-D1.8]   Phosphorus Deliverable 1.8: “Network Service Plane
              enhancements”.




                                           27
Deliverable NA2.2:
FEDERICA User Community and Requirements



Appendix I – UPB documents

 D1-FEDERICA-Letter-Introduction-v2.2.doc

                        Short introduction: How to apply
                           (9th March 2009, Version 2.2)


Dear User,
Thank you for your interest in using the FEDERICA-infrastructure for your future
Internet network R&D work. Accessing the infrastructure requires that we receive
additional information from you and a simple application procedure. This introduction
will help you to proceed in the process. The request will be examined by the
FEDERICA User Policy Board, whose goal is to examine and prioritize requests for
the use of the infrastructure use according to the resource availability and the
proposed technical work plan of the applicant. You may retrieve latest information
about the FEDERICA project and its status at the FEDERICA-Web-site
(http://www.fp7-federica.eu).
The following documents (attached or downloadable from the FEDERICA web site)
will be needed. Some documents are just for information, some documents need a
response or interaction.


Documents for Information:
   •   “D2-FEDERICA-Basic-User-Information” provides a detailed introduction to
       the FEDERICA project.
   •   “D3-FEDERICA-Access-Rules-and-Guidelines” describes conditions for the
       access to FEDERICA (technically, financially and politically).
   •   “D4-FEDERICA-Acceptable-Use-Policy” (AUP) describes the usage
       conditions specific to FEDERICA.
   •   “D5-FEDERICA-Ressource-Description-and-Guidelines” describes the
       available resources and services within FEDERICA.


Documents for Response or Interaction:
   •   “D6-FEDERICA-Memorandum-of-Understanding” (MoU) presents the
       common understanding for the formal conditions to access FEDERICA. This
       document must be signed and returned to FEDERICA during the application
       process.
   •   “D7-FEDERICA-Project-Plan” presents guidelines for a project description.
       The application to FEDERICA requires a (short) technical description of your
       request and planned work.


                                         28
Deliverable NA2.2:
FEDERICA User Community and Requirements


   •   “D8-FEDERICA-User-Feedback” provides a template of your feedback about
       using FEDERICA. It should be returned at the end of your activity within
       FEDERICA.


Application procedure
The user has to file the request to the e-mail address fed-upb@fp7-federica.eu,
attaching the relevant forms. The information received will be analysed by the User
Policy Board, in particular the “D7-FEDERICA-Project-Plan” is needed to start the
evaluation. During the evaluation process a responsible UPB member will interact
with the user. After the acceptance of the proposed project, the UPB will transfer the
documentation to the technical activity for implementation.


Final evaluation
At the end of your use of the infrastructure FEDERICA would like to receive a short
report from you about the use of the resources, the communication with the project
and also achieved results (if publicly available) using the document “D8-FEDERICA-
User-Feedback” .


                         The FEDERICA User Policy Board




                                          29
Deliverable NA2.2:
FEDERICA User Community and Requirements



    D2-FEDERICA-Basic-User-Information-v2.1.doc

                                Basic User Information
                             (9th March 2009, Version 2.1)


1       Information about FEDERICA for users
1.1     An EC project to ‘slice up’ networks for research
Researchers who would like to conduct disruptive experiments, that shape the future
Internet and other network infrastructures related topics, have a safe and flexible
'environment' for their work. An European Community co-funded project called
FEDERICA can create 'slices' of its network infrastructure, which can be allocated to
researchers as a virtual resource for their experiments.


The Federated E-infrastructure Dedicated to European Researchers Innovating in
Computing network Architectures project – otherwise known as FEDERICA – started
on 1 January 2008 and runs until 30 June 2011.


1.2     Unique Approach
The combination of virtualisation techniques with network control/management
mechanisms is a unique aspect of the FEDERICA project. The concept of running
virtual overlay networks (for example, Virtual Private Networks (VPNs)) is well
established, but FEDERICA also allows researchers to access the lower network
layers (L2) in order to allow specific parts of the physical substrate to be allocated as
virtual resources.




                              Fig. 1 FEDERICA concept




                                            30
Deliverable NA2.2:
FEDERICA User Community and Requirements


In the first phase, the project will focus on creating the Europe-wide infrastructure,
and on developing and testing mechanisms that achieve virtualisation, or ‘slicing’, of
the network resources, as well as mechanisms to control these processes. The project
infrastructure is operational since end of November 2008.
The second phase of the project will implement a ‘tool-bench’ that will integrate these
mechanisms in order to provide more automated and on-demand allocation of ‘slices’
to researchers.


In the last phase, the tool-bench will study to ultimately enable control of resources
across multiple domains, allowing the FEDERICA concept to be extended to
communities other than Europe’s research and education sector, which is the primary
target user group.


1.3       Experimental users
Users of the FEDERICA infrastructure will include individual researchers, PhD
students, groups in universities or research centres, EC project participants and
equipment manufacturers’ research laboratories. Their research is expected not just to
use the network as a tool, but as primary subject of their work. Training for users is
included in the project.


FEDERICA’s experimental network infrastructure is neutral as to the types of
protocols, services and applications that may be trialled, while allowing disruptive
experiments to take place without adverse effect on existing production networks.


1.4       Summary of the objectives of the project
      •   Support the research on new Internet architectures and protocols
             o create a European wide ‘technology agnostic’ infrastructure based on a
               mesh of 1 Gb/s MPLS and Gbps circuits from NREN/GÉANT and
               virtualization nodes providing virtualized network/computing facilities
               (in form of ‘slices’) to end-users, allowing disruptive emulations
             o open to host researchers’ hardware and applications
             o Simultaneous use by more than one research group
             o provide full control of the network up the data link layer (later lower
               layers) and access to monitoring data
      •   Develop experience and a model for managing and using virtual
          infrastructures as a combination of networks and systems
      •   Exploit at their best the existing NREN/GÉANT networks and tools
      •   Facilitate technical discussion amongst specialists, in particular when based on
          experimental results, and disseminate knowledge and NREN experience



                                             31
Deliverable NA2.2:
FEDERICA User Community and Requirements




1.4.1 Goals in Scope
      •   Act as a forum and support for researchers/projects on ‘Future Internet’
      •   Support of experimental activities to validate theoretical concepts, scenarios,
          architectures, control & management solutions; users have control of their
          virtual slice
      •   Provide network and system agnostic e-infrastructure on European scale to be
          deployed in phases. Provide its operation, maintenance and on-demand
          configuration
      •   Validate and gather experimental information for the next generation of
          research networking also through basic tool validation
      •   Dissemination and favour cooperation of NRENs and User community
      •   Contribution to standards in form of requirements and experience


1.4.2 Goals out of Scope
      •   Extended research, e.g. advanced optical technology developments
      •   Development and explicit support of Grid applications
      •   Offer computing power
      •   Offer transit capacity


1.5       Potential Use Cases for external users (examples)


Use Case 1: ‘User does research on networked applications’
      •   The user who wants to try his distributed application needs a set of physical
          and or logical routers and a set of virtual hosts interconnected on which to
          install his application.
      •   He would ask FEDERICA for a slice containing an IP routed network that best
          suits his needs (including capacity for each circuit).
      •   The user would ask FEDERICA to create VMs (Virtual Machines) and upload
          his application software, or provide preconfigured system images to be
          installed in the slice. Then he would be able to see how his application
          behaves in the slice, including a possible communication with nodes in
          Internet through the IP peering with the NRENs.
      •   At a certain point the user could decide to change the IP network topology or
          parameters to see how this affects the performance of his application.


Use Case 2: ‘User does research on Layer 3’



                                             32
Deliverable NA2.2:
FEDERICA User Community and Requirements


      •   The user wants to do research at the network layer 3 (with a new stack of
          routing protocols). He could get 5 Virtual Machines and some physical ports
          on Ethernet switches (the user can only execute the FEDERICA services over
          the resources he has received).
      •   He would ask FEDERICA to setup a slice with circuits that linked his 5 or 6
          Virtual Machines creating a chosen topology (for instance a ring).
      •   He would upload his routing software; thus converting the 5 Virtual Machines
          into 5 routers. The user can also choose to install his preconfigured system
          images.


2         FEDERICA infrastructure
2.1       Capabilities
What FEDERICA proposes to offer to the users can be summarized as follows:
      •   The possibility to request a virtual infrastructure composed by a
          combination of circuits (up to 1Gb) and V-nodes (the operating system
          default is Linux, or just a ‘placeholder’ for a user supplied ‘image’)
          The slice can contain: routed IP circuits (IPv4, IPv6 unicasting and
          multicasting) and/or system(s) and/or routers. Optional routed connection to
          Internet is possible.
      •   The slice can be a set of L2 circuits and system images (no IP
          configuration, just Ethernet framing).
          FEDERICA is based on 1 Gbps Ethernet circuits from GÉANT2. Those can
          be sliced either using VLAN technology or using MPLS L2 LSPs. In both case
          the framing stays Ethernet. (SDH is out of scope in the first phase of
          FEDERICA)
      •   Circuits may have capacity assurances on request.
          There are various options to provision capacity assurances:
          o Plain 1 GbE dedicated link
          o Up to 4 classes (users) per interface with guaranteed capacity using 802.1p
          o Premium IP (3 classes, but with known capacity patterns so no packet loss
            can be assured)
          o Characteristics of 2 Line Cards in the Juniper MX240 (Q type) which have
            up to 4K shapers (optional only in Juniper)
      •   Some basic monitoring on the slice can be provided (i.e. some statistics
          through a web page).
          FEDERICA will collect monitoring information when requested (to be defined
          in detail). The information can be exported raw or using the web via
          presentation tools. The web page is also a portal for user support.
      •   The user will have initially access to the network and system using SSH.


                                            33
Deliverable NA2.2:
FEDERICA User Community and Requirements


          Access to the slice is provided through a gateway host which can connect both
          to the general Internet and the specific user’s slice. The circuits provided
          should be seen as fixed pipes. The user can play ‘inside’ his pipes as much as
          he wants. In that case he has to instantiate a virtual node that plays the role of
          a router or switch (e.g., in some cases it is possible to configure logical routers
          in the Juniper physical routers and provide the user full access to it.)


2.2       Typical procedures
Typical defaults and procedures for the users to access FEDERICA:
      •   The user has to submit a proposal to the UPB (User Policy Board) and be
          approved and discuss technical details beforehand.
      •   The initial maximum time duration for the slice is 90 days.
      •   The user has to sign an AUP (Acceptable Use Policy) see Appendix III.
      •   There is an obvious scaling limit to be assessed.
      •   Slice configuration will initially be semi-automatic and will require a few days.


2.3       The FEDERICA Infrastructure Network footprint
Topology design principles:
      •   A highly physically meshed infrastructure to allow easier slicing in complex
          topologies
      •   Deploy a large number of circuits
      •   Define a full mesh core based on Juniper MX480 nodes and V-Nodes
      •   Distribute Juniper in NRENs which have management responsibilities
      •   Do not force the circuits to follow the physical hops, but use the possibility to
          directly interconnect distant NRENs
      •   MPLS L2 LSPs on GÉANT2 may be added in case native GbE is not available
          or to increase meshing
      •   Avoid more than 3 circuits for each PoP (4 for core nodes)


3         FEDERICA’s users
3.1       Classification of the users
The target users of the infrastructure are the researchers and the activities engaged in
research ‘on’ networking, using networks not just as the ‘tool’ but primarily as the
‘subject’ of their work. User groups will include EC projects, research groups in
universities or research centres, equipment manufacturers and telecommunications
research labs or even individuals (e.g. PhD students).




                                              34
Deliverable NA2.2:
FEDERICA User Community and Requirements


Potential users:
      •   FEDERICA partners to initially contact research groups
      •   FEDERICA partners to later liaise with research groups and researchers in
          their communities
      •   EC projects: potential users, along with FP7 initiatives, e.g. FIRE test beds
      •   research groups in universities or research centres
      •   equipment manufacturers
      •   individuals (e.g. PhD students).


Note that site visits are planned to key researchers to discuss requirements in-depth. In
particular, the PlanetLab ‘slice’ database (https://www.planet-
lab.org/db/pub/slices.php) will be used, along with personal contacts to sort-out the
network research customer base within FEDERICA's service area.


Users of the FEDERICA infrastructure will be distinguished between ‘configurators’
(i.e. being able to modify -in a controlled way- their allocated virtual slice or part of
the slice properties, configuration, software) and ‘consumers’ (i.e. those who are
simply using a FEDERICA slice or layer to do higher layer or application layer
testing).




                 Fig. 3 Network layers (functions) available to the user


3.2       Type of users
The user communities will be segmented according to the level of use the
infrastructure. The following four types of users are envisaged:
      •   Type 1: Researchers who request a stable network with standard protocols and
          IP connectivity. The topology might be of their choice, but they accept or are
          willing to share the network slice with other users and experiments.




                                             35
Deliverable NA2.2:
FEDERICA User Community and Requirements


   •   Type 2: Researchers who request a stable network with standard protocols and
       IP connectivity, but with dedicated and guaranteed capacity.
   •   Type 3: Researchers who want a network with standard protocols and IP
       connectivity and wish to experiment their own packet processing element and
       protocols in a private or shared slice. The experimenter has complete control
       of how data is routed and processed over the network and the control plane of
       the virtual slice.
   •   Type 4: Researchers who want a topology made of circuits and computing
       elements, but without any configuration, as they would test new architectures
       and protocols. Bandwidths on demand within the topology may be setup and
       removed dynamically.


Further information about FEDERICA project


The FEDERICA infrastructure will use the Points of Presence (PoP) of the pan-
European GÉANT2 network, as well as those of participating National Research and
Education Networks (NRENs). Using the NRENs’ and GÉANT2 networks will create
a long-distance, multi-domain infrastructure that will provide a real-world
environment for undertaking end-to-end network experiments.


The FEDERICA infrastructure will cover a significant part of Europe through
participating NRENs, although access can be granted to any user with an Internet
connection. Furthermore, FEDERICA will establish connections with other similar
infrastructures such as the PlanetLab, EMUlab and OneLab overlay networks, the
NSF GENI initiative in the United States, NREN testbeds, and telco experimental
facilities. While the initial testing phase will be limited to selected users, the
infrastructure will be made available to other EC projects during the final year of the
project.


The FEDERICA project started on 1 January 2008 and runs until 30 June 2011.


The project represents a total investment of EUR 5,178,111. The European Union’s
Integrated Infrastructure Initiative (http://cordis.europa.eu/infrastructures/i3.htm) has
funded 71% of this.


PARTNERS:


FEDERICA involves twenty-one partners from the academic, research and
commercial sectors, coordinated by the Italian national research network organization
Consortium GARR. More detailed information about the partners is available on the
FEDERICA project website - http://www.fp7-federica.eu/partners.php


                                            36
Deliverable NA2.2:
FEDERICA User Community and Requirements




Consortium GARR (Italy); CESNET (Czech Republic); DANTE (based in UK); DFN
(Germany); FCCN (Portugal); GRNET (Greece); HEAnet (Ireland); HUNGARNET
(Hungary); Fundació i2CAT (Spain); ICCS (Greece); Juniper Networks, Inc.; KTH
Royal Institute of Technology (Sweden); Martel Consulting (Switzerland);
NORDUnet (based in Denmark); Politecnico di Torino (Italy); PSNC (Poland);
RedIRIS (Spain); SWITCH (Switzerland); TERENA (based in Netherlands); UPC
(Spain);


Contact information


Coordinator:
Mauro Campanella (Consortium GARR)
Mauro.Campanella@garr.it
http://www.garr.it/garr-b-home-engl.shtml


FEDERICA-Web-Site:                            http://www.fp7-federica.eu
User Policy Board:                            fed-upb@fp7-federica.eu
FEDERICA Network Operation Centre (NOC):      federica-noc@fp7-federica.eu




                                        37
Deliverable NA2.2:
FEDERICA User Community and Requirements



    D3-FEDERICA-Access-Rules-v2.1.doc

           Access Rules and Guidelines for the FEDERICA infrastructure
                           FEDERICA User Policy Board
                           (9th March 2009, Version 2.1)

1         Introduction
This document provides rules and guidelines that need to be followed by applicants to
request access to the FEDERICA infrastructure as well as the criteria that are applied
by the User Policy Board (UPB) to evaluate and prioritize these proposals.
The FEDERICA project is dedicated to research on the "Internet of the future". While
there is no unique definition of this term, we adopt the one given in [1] as a guideline.
Compliance to this objective is the main criteria for the prioritization of a proposal.
On the other hand, the scientific merit of a proposal is not normally explicitly
included in the evaluation criteria.
In general, the infrastructure will be available to both the academic and private sector,
but due to its own status within FP7, research projects under the FIRE initiative [2]
will be preferred.
As a general rule, the evaluation process should not prevent proposals to be accepted
when a minimal set of requirements are met and resources for the requested
timeframe are available. However, the UPB reserves the right to reassess a proposal
and possibly reallocate resources during the lifetime of a project.


2         Formal requirements
To access FEDERICA a formal procedure has been defined. The procedure is needed
to address both the technical requirements of the proposal and ensure agreement on
the conditions of use of the resources provided. The formal process is outlined in the
introduction document [D1]:
      •   The list of documents to be exchanged is:
      •   Memorandum of Understanding
      •   Acceptable User Policy
      •   Project Plan


2.1       Main evaluation criteria
The evaluation of the proposals from user/projects will be along the following two
main criteria:
          a) A user/project can utilize the FEDERICA service, if acceptable reasons are
          provided why he/she/it in particular wants to use the FEDERICA services..
          The main aim of FEDERICA is to implement and get feedback on how to
          provide virtualised services at various communication layers like layer 2 (e.g.
          Ethernet), 3 (IP) and higher (applications). Users/projects are thus encouraged


                                            38
Deliverable NA2.2:
FEDERICA User Community and Requirements


       to use these virtualised services for research on future Internet and provide
       feedback.


       b) A certain level of operational flexibility needs to be agreed between
       users/projects and FEDERICA. The services are actively managed and the
       greatest care will be given to provide the services as defined. As it is not a
       commercial service, there is a limited amount of resources available
       (manpower, time, virtual links, nodes, etc.). Although time-sharing will
       optimize the use of the available virtual resources, FEDERICA only provides
       a best effort services. If services need to be timed shared beyond the original
       planned period, FEDERICA will communicate with its users/projects to try to
       achieve the optimal configuration for all projects/users involved.


The evaluation of the proposals will be checked on the two main criteria above. For
evaluating the above, the user/project will have to provide a project/test plan with a
certain amount of content (as described in section 2). In the following paragraphs
some guidelines will be given how the rating of the criteria will be done.


2.2    Project/Test plan evaluation
The project/test plan needs to provide sufficient details to make standalone evaluation
by the UPB possible using the Request Technical Description template [D7]. In the
following section the major aspects are discussed.


2.2.1 General description of the request
This description will need to describe the project in such a way that a stand alone
evaluation by the UPB is possible. The evaluation of this description will be along the
two points described in section 2.1: a) reasons why using FEDERICA services and b)
supportive to operational flexibility. The proposal will need to give enough
information about these two criteria, so that the FEDERICA User Policy Board (UPB)
can properly evaluate the request.


2.2.2 Proposed project time line
A time line with a maximum of three months per experiment is recommended. This
guideline is to guarantee that a fair amount of projects can utilize the FEDERICA
services and that the underlying infrastructure is efficiently shared. Longer proposals
are possible, provided detailed reasons are added which are complementary to the two
main criteria as mentioned in section 2.1.


2.2.3 Description of resources
A list of FEDERICA resources needs to be provided in the proposal (and support is
also one of the resources) examples of resources are: virtual routers/switches/circuits,


                                           39
Deliverable NA2.2:
FEDERICA User Community and Requirements


access/peering with other slices or General/Commodity Internet, virtual machines to
load software, storage, support, co-location space/power requirements, etc. For each
resource the following context needs to be provided and detailed in D7-Project-Plan:
the amount, specific characteristics, expected support needs, expected load over time
and operational flexibility.
The UPB will evaluate the usage of the resources by looking also at the importance of
the results for the FEDERICA project itself and it will check that the least conflict
will occur with other projects. Depending on the possible operational flexibility, it
might be possible that some conditions will need to be met, depending on other
projects.


2.3    Billing by FEDERICA
For the FEDERICA services, normally no costs will be incurred to the user/project
(FEDERICA is a partly EC funded project). If exceptional demands are requested and
can be made available easily (like excessive support, a lot of co-location space/power,
connectivity to networks/users/projects), FEDERICA might charge for some of the
costs. The level of these costs will be determined on a case by case basis.


2.4    References:
[1]    http://cordis.europa.eu/fp7/ict/future-networks/home_en.html
[2]    http://cordis.europa.eu/fp7/ict/fire/event-23-240407-sum_en.html
[D1]   D1 FEDERICA Letter Introduction
[D7]   D7 FEDERICA Project Plan




                                          40
Deliverable NA2.2:
FEDERICA User Community and Requirements



 D4-FEDERICA-Acceptable-Use-Policy-v1.0.doc

                         FEDERICA Acceptable Use Policy
                        FEDERICA User Policy Board (UPB)
                            (9th March 2009, Version 1.0)


Background and Definitions
1. FEDERICA (Federated E-infrastructure Dedicated to European Researchers
Innovating in Computing network Architectures) is an experimental network
infrastructure for trialling new networking technologies.
FEDERICA network nodes are capable of virtualising hosts (e.g., open source routers,
switches, end nodes, etc.). Virtual slices of the FEDERICA network (referred as
Slice) may be allocated to users for testing even with disruptive experiments within a
large production substrate. The users will have control on the allocated virtual links
and virtual hosts within their slice(s) and also access to the network monitoring
information related to the slice(s). The main service of FEDERICA is to provide a
Slice.
This document contains the acceptable use policy (referred as Policy) of the
FEDERICA virtual network Slice as a service.
2. The FEDERICA network is designed, developed and operated by the FEDERICA
project consortium. The project is coordinated by GARR, the Italian Research and
Education Network, the other partners of the consortium are: CESNET, DANTE,
DFN, FCCN, GRNET, HEAnet, NIIF, i2CAT, ICCS, Juniper Networks, KTH, Martel
Consulting, NORDUnet, PoliTo, PSNC, RedIRIS, SWITCH, TERENA, UPC (for
more details see: http://www.fp7-federica.eu/)
3. The acceptable use policy of FEDERICA is controlled by the User Policy Board
(referred as UPB). The submissions, questions, policy violation reports have to be
addressed to the UPB: fed-upb@federica.eu
4. This Policy applies in the first instance to any research
organisation/project/individual authorised to use FEDERICA (referred as User or
User Organisation). It is the responsibility of User Organisations to ensure that
members of their own user communities use FEDERICA services in an acceptable
manner and in accordance with current legislation.
5. It is therefore recommended that each User Organisation makes known this Policy
to its members. If material from this document is included, this must be done in such a
way as to ensure that there is no misrepresentation of the intent of this Policy.
6. In general, FEDERICA provides absolutely no privacy guarantees with regard to
packets sent to/from Slice(s). FEDERICA also does not provide any guarantees with
respect to the reliability of individual nodes, which may be rebooted or reinstalled any
time.



                                          41
Deliverable NA2.2:
FEDERICA User Community and Requirements


Acceptable Use
7. A User Organisation may use FEDERICA to create a Slice for experimental
research, and to connect other resources which are reachable via interworking
agreements operated by FEDERICA partners (see Article 2).
8. The use of internal, existing FEDERICA resources inside the Slice is “for free”,
interconnection to external resources using the IP best effort service through the
FEDERICA peering is also possible at no cost. Physical interconnection requests,
special requirements may be satisfied according to the real cost. Any provision of
service must be authorised in advance.
9. Subject to the following paragraphs, FEDERICA may be used for any legal activity
that is in furtherance of the aims and policies of the User Organisation.


Unacceptable Use
10. FEDERICA may not be used for any of the following:
       a. the creation or transmission (other than for properly supervised and lawful
       research purposes) of any offensive, obscene or indecent images, data or other
       material, or any data capable of being resolved into obscene or indecent
       images or material;
       b. the creation or transmission of material which is designed or likely to cause
       annoyance, inconvenience or needless anxiety;
       c. the creation or transmission of defamatory material;
       d. the transmission of material such that this infringes the copyright of another
       person;
       e. the transmission of unsolicited commercial or advertising material either to
       other User Organisations, or to organisations connected to other networks,
       save where that material is embedded within, or is otherwise part of, a service
       to which the member of the User Organisation has chosen to subscribe;
       f. deliberate unauthorised access to facilities or services accessible via
       FEDERICA;
       g. deliberate activities with any of the following characteristics:
       •   wasting staff effort or networked resources, including time on end systems
           accessible via FEDERICA and the effort of staff involved in the support of
           those systems;
       •   corrupting or destroying other users’ data;
       •   violating the privacy of other users;
       •   disrupting the work of other users;
       •   using FEDERICA in a way that denies service to other users;




                                           42
Deliverable NA2.2:
FEDERICA User Community and Requirements


       •   continuing to use an item of networking software or hardware after UPB
           has requested that use cease because it is causing disruption to the correct
           functioning of FEDERICA;
       •   other misuse of FEDERICA or networked resources, such as the
           introduction of ‘viruses’.
11. Any breach of industry good practice, or of the acceptable use policies of other
networks, that is likely to damage the reputation of the FEDERICA network may be
regarded as a breach of this Policy.


Consequences
12. Violation of this Policy may result in any of the following:
       a. informing the administration of the User Organisation
       b. disabling the user account(s)
       c. withdrawing the service (i.e., removing the Slice)


Passing on and Resale of FEDERICA Service
13. It is not permitted to provide access to FEDERICA for third parties without the
prior agreement of UPB.
14. A third party, where an individual, means someone who is not acting as a member
of the User Organisation. Where it applies to a separate organisation, this is defined to
be any organisation that is in law a separate entity to the User Organisation.


Compliance
15. It is the responsibility of the User Organisation to take all reasonable steps to
ensure compliance with the conditions set out in this Policy document, and to ensure
that unacceptable use of FEDERICA does not occur. The discharge of this
responsibility must include informing those at the organisation with access to
FEDERICA of their obligations in this respect.
16. Where necessary, service may be withdrawn from the User.
17. Where violation of these conditions is illegal or unlawful, or results in loss or
damage to FEDERICA partners or FEDERICA resources or the resources of third
parties accessible via FEDERICA, the matter may be referred for legal action.
18. It is preferable for misuse to be prevented by a combination of responsible
attitudes to the use of FEDERICA Slice on the part of users and appropriate
disciplinary measures taken by their organisations.




                                           43
Deliverable NA2.2:
FEDERICA User Community and Requirements



    D5-FEDERICA-Resource-Description-v0.3.doc

                Resource Description for the Federica Infrastructure
                                       Draft version
                              (9th March 2009, Version 0.3)


1        Definitions
This section provides a basic set of definitions regarding the resources available
within FEDERICA at Layer 2. The definitions given in this section are concepts that
the user can request for use in his project. This set of definitions might be adapted
over time, as developments within FEDERICA are still ongoing.
The user can request the following concepts to serve its needs:
     •   Virtual Infrastructure (VI): a VI is a specific set of Virtual Resources with
         selected control capabilities. The user can request a VI consisting of selected
         resources and the capabilities it should offer.
     •   Virtual Resource (VR): an abstraction of a physical network resource (PR),
         which forms part of the Virtual Infrastructure. From the user’s point of view a
         VR appears to function as a physical resource. A VR can represent a single
         partition of a physical resource (a slice), or a collection of physical resources
         (cluster). The following concepts are all examples of Virtual Resources:
         Virtual Links, Virtual Nodes, Virtual Switches, Virtual LAN.
     •   Virtual Link (V-Link): an abstraction of one or more physical links, seen by
         the user as a single link between two Virtual Resources. The user can request
         specific demands to these links, such as required bandwidth, loss probability,
         etc.
     •   Virtual Node (V-Node): one or more partitions of a physical node, which can
         be seen from the user’s point of view as a single network node. In other words,
         this is a Virtual Machine, with the specified user image.
     •   Virtual Switch (VS): a partition of a physical switch, which the user can
         configure and use as if it were a physical switch. From the user’s point of view,
         the VS is seen as a physical switch, offering the same functionalities as a
         physical switch.
     •   Virtual Local Area Network (VLAN): a specific set of Virtual Resources that
         can be configured so that they appear to be a single network or domain. A
         VLAN can be configured with specific characteristics; this will be described
         later in this document. A VLAN can be offered as a Virtual Resource, if
         requested by the user, but can also be implemented as a Virtual Service, when
         implemented by the user on the offered Virtual Infrastructure.
Along with the Virtual Resources, the Virtual Infrastructure also offers Virtual
Network Services. A Virtual Network Service (VNS) is a service that can be
implemented by the user on top of the Virtual Infrastructure. An example is the


                                            44
Deliverable NA2.2:
FEDERICA User Community and Requirements


implementation of a VLAN. The concept of virtual services will be described later in
this document.


2       Layer 2 virtual resources
The user can request a virtual infrastructure (VI) at L2 of different complexity, where
a virtual network service (VNS) can be deployed. The requested VI will be composed
by different virtual resources (VR). The user can request for the following VRs at L2:
    •   Virtual switch (VS)
    •   Virtual link (V-link)
    •   Virtual node (V-node)
    •   Virtual LAN (VLAN): The user can ask for one level of preconfigured
        VLANs
    •   Class of service specifications (CoS): The user can request for some CoS
        specifications related to some virtual resources:
           o Specified bandwidth
           o Burst size
           o Priorities
           o Loss probability
           o Schedulers
           o Congestion management mechanisms
Once the user disposes of the virtual infrastructure, he can configure the following
parameters:
    •   One level of VLAN
    •   V-nodes behaviour
    •   Class of service specifications (CoS): The user should be able to configure
        some CoS specifications, inside the limits of the requested configuration:
           o Specified bandwidth
           o Burst size
           o Priorities
           o Loss probability
           o Schedulers
           o Congestion management mechanisms


3       Layer 3 virtual resources
To be studied.



                                          45
Deliverable NA2.2:
FEDERICA User Community and Requirements


   •   Logical routers (LR)
   •   Software routers (V-node)
   •   Hosts (V-node)




                                    46
Deliverable NA2.2:
FEDERICA User Community and Requirements



 D6-FEDERICA-MoU-v1.0.doc

                       Memorandum of Understanding (MoU)
           between FEDERICA and ??? [other project/group/person name]
                             (9th March 2009, Version 1.0)


1. Purpose
The purpose of this MoU is to formalise the access and use of the FEDERICA
infrastructure by ???, called further on “partner”. It briefly outlines the access
policies, the timeframe and any associated conditions.
The MoU represents one of the three key documents that describe the collaboration,
namely:
       1. The Memorandum of Understanding: This document, formalising the
       collaboration, the timeframe and listing the mandatory information to be
       exchanged
       2. The Acceptable Use Policy: The rules defining the responsibilities of each
       party, the type of traffic that can be carried, the nature of acceptable
       experiments, respect of private and confidential information from FEDERICA
       and/or parallel experiments and taking due care not to intentionally disrupt the
       infrastructure;
       3. The Project Plan: The technical description of the planned use of the
       FEDERICA infrastructure by the partner. It details the resource request in
       form of a “slice”, if the case, where and when and how physical equipment is
       integrated into the FEDERICA infrastructure, how the connectivity is
       achieved, what services are provided by FEDERICA (bandwidth, equipment,
       processing resources and personal support), what experiments will be
       performed, how feedback of the use will be provided, how the results may be
       shared, etc.


2. FEDERICA
FEDERICA is a project of the 7th Framework Program of the European Commission,
grant no. RI-213107, which duration is from January the 1st, 2008 to June the 30th,
2010.
The project has the goal to set up an infrastructure made of virtual resources (circuits,
nodes and network equipment) which researchers may request for their experiments.
Resources are offered in an isolated, dedicated environment named a “slice”. The
researchers receive control on the assigned resources and the possibility to access
them from general Internet through a gateway.
The up-to-date information on the infrastructure topology and request and access
guidelines are available on the web site www.fp7-federica.eu and on the information
kit provided at the time of registration.


                                            47
Deliverable NA2.2:
FEDERICA User Community and Requirements




3. Partner
The partner is active in the area of ….. [a few sentences to be written by the partner]


4. The use of the infrastructure


4.1 Technical details
The technical details of the use of infrastructure are explained in the agreed document
“FEDERICA-Project-Plan”.


4.2 Timeline
The timeline for the collaboration is shown below:
       2008                        2009                                2010
        12     1 2      3 4   5   6 7 8     9 10     11   12   1   2   3 4 5 6



4.3 Partner Obligations
The partner agrees:
   •   to share the results of any experiments performed on both their equipment and
       FEDERICA, to the extent that the information is anonymous and non-
       confidential. This may be done, for example, through a workshop, or by giving
       access to the relevant deliverable or publication in a journal.
   •   to provide feedback on the use of the infrastructure, using the provided
       template (FEDERICA-User-Feedback).
   •   to acknowledge the use of FEDERICA in all publications and talks.


4.4 Data privacy
The partner agrees by default to a non-disclosure agreement on data, experiment
details and results and it will ensure to its best such privacy.


5. Partnership
Nothing in this MOU implies any partnership between the parties.


6. Financing
Each party is responsible for financing its own participation in this collaboration.




                                           48
Deliverable NA2.2:
FEDERICA User Community and Requirements


No charge is made by FEDERICA for the services and resources (bandwidth,
equipment, processing resources and personal support) it provides in accordance with
its commitments to the EC and the separate agreed Project Plan between the parties.
In case the agreement requires specific expenses, they will be quoted here with the
financial agreement between FEDERICA and the partner.


7. Term and Termination
This MoU shall become effective upon signature by both party and shall remain in
force initially until xx.yy.zz. Either party may cancel the MoU by notifying the other
party in writing with one week’s notice. The MoU may be extended by mutual
agreement.


8. Signatures
Two originals to be signed; one for each party.


FEDERICA                                       ???
Co-ordinator                                   [Title]


Mauro Campanella                               XXX


Signature:                                     Signature:


Date:                                          Date:




                                          49
Deliverable NA2.2:
FEDERICA User Community and Requirements



    D7-FEDERICA-Project-Plan-v0.2.doc

                                       Project Plan
                   for the usage of the FEDERICA infrastructure
                                 (9th March, Version 0.2)


A technical project plan has to be detailed and agreed to access to the FEDERICA
infrastructure. This document contains information how to structure this project plan.
The project plan has to include management information, a description of the planned
work and a description of the required and available resources.
These information form the basis for the FEDERICA User Policy Board (UPB) to
assess the feasibility of the access to FEDERICA.


1        Required Information
     •   Name of the Project.
     •   Participating institutions (name, location) with participating persons (name,
         phone, e-mail), including the head of the project.
     •   Planned starting time and planned length of time of the project.
     •   Short project description (1-2 pages of text).
     •   Description of the usage scenario of FEDERICA (1 page text) with a slice
         topology map.
     •   Required resources from FEDERICA.
         This information has the goal to specify the configuration of the slice (or the
         slices) in terms of the resources which FEDERICA can provide:
            •   V-Nodes as a computing resource capable of executing a system image
                and which can be connected to one or more circuits
            •   Virtual IP router functionality provided by the network elements
            •   Point to point circuits between the V-Nodes or the network equipment
            •   Access points and bandwidth.
         The possible requirements (not exhaustive) to the network properties and to
         the service elements in FEDERICA are listed in the below requirement table.
     •   Required connectivity to third parties (outside of FEDERICA), e.g. other test
         environments. However, such connectivity to third parties is in the
         responsibility of the user, who has to provide a plan to establish such
         connectivity.
     •   Available resources of the project partners.




                                            50
Deliverable NA2.2:
FEDERICA User Community and Requirements


2         Requirements table
This table should be seen as a support to formulate the requirements with respect to
FEDERICA. Maybe FEDERICA can not fulfill all requirements. Not all rows must be
completed!
FEDERICA-service-related requirements
(For each required FEDERICA service use an extra table)
    CATEGORY           PARAMETER            DESCRIPTION         REQUIREMENT
    Research on        Layer 2              Research on what    [choice]
    network layers /   Layer 3              layer?
    Transparency       Layer 4+
    Time of usage      Short (hours)        Typical time of     [value]
                       Mid (days)           usage?
                       Long (months)
    Type of usage      Off-line             Experiments on      [choice]
                       On-line              the background or
                                            live?
    Response /         Provisioned          Expected service    [choice]
    Provisioning       Scheduled            response time?
    time               On-demand
    Level of control   No                   Control on the      [choice]
                       Semi                 service?
                       Full
    Level of           Off-line reports   Monitoring of the     [choice]
    monitoring /       Interactive debug  elements and/or
    measurement                           traffic?
    Scalability        Number and size of Typical number        [value]
                       the network slices and size of
                                          network slices?
    Reliability /      R/A of the network Expected number       [value]
    Availability       slices             of nines?
    Security/          Internal risks     Importance of         [Y/N]
    Authentication     External threats   security level?


Network-related requirements (Network slices)
    CATEGORY           PARAMETER            DESCRIPTION         REQUIREMENT
    Traffic matrix /   Point-to-point       Typical usage?      [choice]
    Connection         Point-to-multi
    topology           point
                       Multi point-to-
                       multi point
    Bandwidth          High                 Typical             [value]
                       cap./Narrowband      bandwidth?
    QoS level          Best Effort          Level of QoS?       [choice]


                                           51
Deliverable NA2.2:
FEDERICA User Community and Requirements


                        Quality of Service
    Delay                                     Expected delay?      [value]
    Jitter                                    Expected jitter?     [value]
    Loss rate                                 Expected loss?       [value]
    Fairness                                  Expected fairness?   [value]
    Type of IP          Close network         Require public IP    [choice]
    network             Open network          addresses?
    Network             Fault                 Importance of        [Y/N]
    management          Performance           network
                        Topology              management?
    Traffic             Bandwidth             Importance of        [Y/N]
    management          CAC                   traffic
                        Policing              management?
    Accounting                                Importance?          [Y/N]
    Cost                                      Importance?          [Y/N]

Application-related requirements (Virtual Machines/software packages)
    CATEGORY            DESCRIPTION                                REQUIREMENT
    Processing power    Typical processing power?                  [value]
    Memory              Typical memory?                            [value]
    Storage resources   Typical storage?                           [value]
    Operating           Are you interested in a particular         [Y/N]
    Systems             Operating System?

3        Slice Topology Map
(a topology example to be included)




                                             52
Deliverable NA2.2:
FEDERICA User Community and Requirements



    D8-FEDERICA-User-Feedback-v1.0.doc

                                    User Feedback
                          for the FEDERICA infrastructure
                             (9th March 2009, Version 1.0)


1        Introduction
This document contains the scope of the User Feedback which helps to gain feedback
on the experience gotten from the FEDERICA infrastructure.
The User Feedback is used to document the experience of the users on FEDERICA’s
services. So aspects like; How was the communication in general with FEDERICA?
Was the portfolio presented at the right level? Were the services easily accessible?
Did the provided service support your project goals, etc.
The procedure for the User Feedback can split in two parts:
     •   How to get the feedback information from the FEDERICA infrastructure users
         (section 2)
     •   A form that describes the information FEDERICA wants to gain from the User
         (section 3)


2        Procedure for User Feedback
The feedback from the User will be at many levels and thus a very direct link with the
User is needed during the interview. The best way to guarantee this is that a
FEDERICA representative talks (using phone of videoconferencing) with the User
and gets the feedback through a structured interview. The interview will be structured
along the points mentioned in section 3.
The FEDERICA representative should facilitate an open atmosphere to abstract as
much information from the User about any experience with the FEDERICA services.
So some yes/no question will be there, but mainly open questions will be used in this
process.
The procedure is as follows:
     •   FEDERICA representative organises with the User an interview as soon as the
         project does not use any more the FEDERICA services
     •   The User will send all results (related to the FEDERICA services) to the
         FEDERICA representative, so he/she can prepare the interview
     •   The User checks the User Feedback document (this document: D9-
         FEDERICA-User-Feedback) to make sure he/she know what the scope is of
         the interview.
     •   The interview will be held in an open atmosphere, using the subjects
         mentioned in Section 3


                                           53
Deliverable NA2.2:
FEDERICA User Community and Requirements


      •   The FEDERICA representative will summarize the results from the interview
          and send them for verifications to the User.
      •   The resulting (mutually agreed) User Feedback will be part of the delivery


3         The User Feedback form
3.1       General questions
      •   What do you think about the whole communication process with FEDERICA?
          Please explain further and if possible provide suggestions to improve.


3.2       Service specific questions
      •   Were the services up to the expected level/standards?               Yes/No
          Please explain further and if possible provide suggestions to improve:


      •   Would you have expected a Service Level Specification?              Yes/No
      •   And for which services?                                 All/Layer 1/2/3/appl
          Please explain further and if possible provide suggestions to improve:


      •   Were you able to manage your slice properly?                        Yes/No
      •   Was extensive help from FEDERICA needed?                            Yes/No
          Please explain further and if possible provide suggestions to improve:


      •   Were there gaps in the operational management of the FEDERICA service?
                                                                              Yes/No
          Please explain further and if possible provide suggestions to improve:


      •   What results of your project were achieved mainly due to FEDERICA
          services?


      •   Were the peering arrangements with other slices satisfactory?       Yes/No
      •   Were the isolation arrangements between other slices satisfactory? Yes/No
      •   Was the Commodity Internet connectivity satisfactory?               Yes/No
          Please explain further and if possible provide suggestions to improve:


      •   What other services should be provided by FEDERICA?


                                            54
Deliverable NA2.2:
FEDERICA User Community and Requirements




   •   Was the physical connectivity towards the FEDERICA service easy to
       implement?
                                                                          Yes/No
       Please explain further and if possible provide suggestions to improve:




                                         55

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:5
posted:7/9/2011
language:English
pages:55