- FEDERICA

Transcription

- FEDERICA

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.3:
FEDERICA Usage Report
Version 0.8
Dissemination Level
Contractual Date of
Delivery
Actual Date of Delivery
Editor
Public
31st October 2010
Contributors
J. F. Riera (i2CAT)
C. Cervelló –Pastor (UPC)
M. P. de Leon (TSSG)
A. Bianco (PoliTo)
M. Hidell (KTH)
P. Sjödin (KTH)
M. Ruffini (TCD)
V. Lopez (UAM)
V. Reijs (HEAnet)
P. Kaufmann (DFN)
J. Navratil (CESNET)
S. Naegele-jackson (FAU)
M. Roesler-Lass (DFN)
C. Vassilakis (GRNET)
J. Steger (ELTE)
T. Marai (NIIF)
Reviewers
M. Campanella (GARR)
20 December 2010
P. Szegedi – TERENA
Abstract
The Networking Activity NA2 ‘Building and Consolidating the User Community’ is
focused on establishing a strong relationship with and between the users with the
objective of gathering requirements, and facilitating the flow of information and ideas
between them, especially when the users are in different research communities.
DNA2.3 is the closing deliverable of the NA2 activity including all the slice requests
(internal and external ones) and usage reports collected during the FEDERICA project
1
lifetime. This deliverable reports on the most significant user experiences from the
different types of user groups and also contains the final user segmentation considered
by FEDERICA.
2
Deliverable NA2.3:
Table of Contents
Executive summary ................................................................................................. 4 1 Introduction and motivations.......................................................................... 5 1.1 2 Document overview .................................................................................... 5 Results of the FEDERICA user segmentation ................................................ 6 2.1 Technical aspects ........................................................................................ 8 2.1.1 Network layer of usage......................................................................... 8 2.1.2 Access requirement .............................................................................. 9 2.1.3 Size of the experiment........................................................................ 10 2.1.4 Lifetime of the experiment ................................................................. 11 2.2 Non-technical aspects................................................................................ 12 2.2.1 Motivation of research........................................................................ 12 2.2.2 Rational of research............................................................................ 13 2.2.3 Exploitation of results ........................................................................ 14 3 Consolidated usage reports and user feedback............................................. 16 3.1 3.2 4 One-page slice summary of user experiments ............................................ 16 User feedback analysis .............................................................................. 19 Summary........................................................................................................ 22 Appendix I – Project internal experiments .......................................................... 23 Appendix II – Completed external experiments................................................... 29 Appendix III – Rejected/Cancelled experiments.................................................. 34 Appendix IV – On-going/Pending experiments.................................................... 36 Appendix V – List of consulted user communities ............................................... 42 3
Deliverable NA2.3:
Executive summary
Deliverable DNA2.3 is the closing report of the FEDERICA NA2 activity on
“Building and Consolidating the User Community”. During the FEDERICA project
lifetime, NA2 partners organised and actively participated in many user consultation
events (coordinated and reported by NA4 activity) on a national basis as well as on a
European scale. On those events, a number of potential user communities were
informed about FEDERICA and its virtual infrastructure services. Some selected user
groups were approached on a one-to-one basis in order to gain a better understanding
regarding their needs and to provide them the sufficient support to request a
FEDERICA slice.
All in all, about 40 user/project groups were consulted all over Europe and this finally
resulted in 10 slice requests (as of 31st October, 2010) which are to be submitted by
external users. In addition, 5 project internal user slices were also provisioned by
FEDERICA in order to contribute e.g., to the infrastructure monitoring activity and to
the various tasks of the Joint Research Activities in FEDERICA.
This deliverable contains the final result of the FEDERICA user segmentation, which
is based on both the actual slice requests (15 user experiments) and the potential
future requests (30 consulted external user groups). The aim of this segmentation is to
understand better the user communities and the type of experiments that can best
exploit the unique features of the FEDERICA virtualisation capable infrastructure.
This may help to steer the future infrastructure development/support activities and the
user gathering/consultation activities towards the right direction (if appropriate) to
better support the community’s needs.
Beside the segmentation and understanding of the FEDERICA (potential) user basis,
the collection and analysis of the tangible feedback provided by the actual
FEDERICA users are also important. The consolidated usage report and user
feedback are also summarised in this deliverable.
In the appendixes of this document, the following can be found:
•
A one-page summary per each current user experiment can be found that
contains the basic administrative information of the request
•
The definition of the experiment, the requested virtual slice topology
•
The illustration of the monitoring results of the slice usage (to proof the real use)
•
The summary of the major results
•
The user satisfaction study (based on the feedback)
•
Some major recommendations completed by the users
More detailed analysis of the user feedback is also provided in this Deliverable.
4
Deliverable NA2.3:
1
Introduction and motivations
In the last phase of the FEDERICA project, the focal point of the Networking Activity
2 (NA2) was on the segmentation, consolidation, and potential future enlargement of
the FEDERICA end-user communities. NA2 was running until the very end of the
project (30 October, 2010) in order to collect and report all the possible user
experiments (submitted to FEDERICA UPB) as well as potential future requests (if
appropriate). The overall aim was to analyse the FEDERICA user community in order
to know more about the users’ needs and the typical type of experiments that the
FEDERICA infrastructure and its virtualisation services can support.
The timely collection and efficient analysis of the consolidated usage reports and
major user feedback were also very important for the project. Beside the official user
feedback form (part of the User Policy Board documents), NA2 partners have
consulted the actual users one-to-one in order to get detailed information about their
experiences with FEDERICA. The results of these discussions with the users have
been continuously fed back to the Service Activities in order to improve the
procedures of the FEDERICA User Policy Board (UPB, dealing with non-technical
issues) as well as of the Network Operation Centre (NOC, dealing with technical
issues).
1.1
Document overview
The structure of the deliverable is as follows:
•
Section 1 is a brief introduction to the final Deliverable DNA2.3.
•
Section 2 is the detailed analysis and results of the FEDERICA user
segmentation.
•
Section 3 discusses the consolidated usage reports and user feedback gathered
during the lifetime of FEDERICA project.
•
Section 4 is a brief summary and conclusions.
•
Appendix I contains the one-page summary of all the FEDERICA project
internal slice requests.
•
Appendix II contains the one-page summary of the completed external
experiments.
•
Appendix III contains the one-page summary of the rejected or cancelled
experiments.
•
Appendix IV contains the one-page summary of the on-going or pending
experiments.
•
Appendix V is the list of consulted user communities.
5
Deliverable NA2.3:
2
Results of the FEDERICA user segmentation
The preliminary FEDERICA user segmentation was reported in Deliverable DNA2.2.
At that time based on the informal user consultations done by the NA2 participants,
three main groups of users depending on their interest areas were identified. Examples
such as:
•
communities interested in FEDERICA resources only
•
communities interested in virtualisation platforms/concepts in general
•
communities interested in peering/federating with FEDERICA
This was the basis of the preliminary user segmentation, although it was clear that the
“real” users of FEDERICA fall under the first category (at that time, there were only 3
project proposals in that category). Therefore, concentration has been only on the
first category during the final user segmentation process of which a detailed study has
been made.
The final FEDERICA user segmentation, reported in this Deliverable, is based on the
actual user slices as of 31st October, 2010 (the official end date of the extended
project).The one-page summary of all the completed and pending slice requests can
be find in Appendix I, II, III and IV.
The final user segmentation was based on two information sources:
•
The completed and pending user slices/requests as of 31st October, 2010. This
means there were15 users in total.
•
The information gathered during the various user consultation events (reported
by NA4 activity). This means roughly 30 potential user groups (listed in
Appendix V).
Among the 15 actual user slices there are 5 slices in the FEDERICA project’s internal
use (contributing to research studies mainly in JRA1 and JRA2) and 10 external user
slices. During the segmentation all 30 potential user groups were considered as
external while additional project internal slices may also be requested taking into
account the possible continuation of the FEDERICA project.
Fig. 1 shows the distribution on the project internal and external user slices based on
the actual and potential user bases. It can be seen that roughly 70% of the actual slice
requests are coming from external users and the experiments are not related to the
FEDERICA project but supporting other national or international research activities.
6
Deliverable NA2.3:
Fig. 1 Distribution on the project internal and external “real” user slices
The structure of the user segmentation is as follows. In principle, we have considered
technical and non-technical user aspects and their experiments. The technical aspects
include the quality and quantity analysis of the requested FEDERICA resources (per
user) in order to understand the composition of the virtual slices and the behaviour of
the users. This knowledge has been used for improving the project internal procedures
(i.e., UPB, NOC) and can be used during the consolidation and enlargement of the
FEDERICA user community in the future (if appropriate). The non-technical aspects
focus more on the context of the experiments and research studies in order to
understand the broader research environment and the potential implications of the
research results.
The technical aspects include:
•
The network layer of usage (where the experiment is running)
•
The access requirements to the virtual slice
•
The size of the requested slice (number of virtual resources)
•
The lifetime of the experiment
The non-technical aspects include:
•
The basic motivation of the research activity
•
The rationale behind the FEDERICA slice request
•
The exploitation of the results
The detailed results of the user segmentation can be found in the following sections.
7
Deliverable NA2.3:
2.1
Technical aspects
The technical aspects have been defined with an emphasis on the unique features of
the FEDERICA infrastructure and its virtual slice service compared to similar
virtualisation capable facilities such as PlanetLab, OneLab, Panlab,etc.
2.1.1
Net w ork layer of usa ge
One of the unique features of FEDERICA (as of 31st October, 2010) is the capability
to request not-configured virtual resources in terms of raw Ethernet connectivity, clear
virtual machines, and empty virtual routers/switches. An analysis was made of user
requests taking the network layer of usage and resource types into account. According
to this, four categories were defined:
•
IP best effort request
Users may request a fully configured IP network slice from FEDERICA. In
this case, the experiment is running on the IP layer and FEDERICA does not
ensure quality of service parameters on the provided virtual links (only
ensures the connectivity).
•
IP quality of service request
Users may request a fully configured IP network with defined quality of
service parameters for each resource. QoS IP slice is a unique feature of
FEDERICA enabled by its substrate which is fully managed by the
FEDERICA project NOC.
•
Raw resource request with IP connectivity
Users may request not-configured resources (i.e., clear Virtual Machines,
empty routers/switches) and may want to upload their own
images/configuration files to the resources. The experiments are still running
on the IP layer requiring IP connectivity (either QoS or Best Effort).
•
Raw resource request with Ethernet connectivity
Users may request totally not-configured FEDERICA slices (i.e., a set of raw
resources). In this case, the users may apply their own configuration files on
the raw resources and define the data plane protocol on the links. In principle,
FEDERICA is not aware of the studied protocol of the experiment (on top of
pure Ethernet connectivity).
The result of this segmentation can be seen in Fig. 2.
8
Deliverable NA2.3:
Fig. 2 Network layer of usage
In conclusion it can be said that 40% of the actual experiments use FEDERICA slice
as a fully configured IP network with best effort connections. There is nothing unique
in this sense, so other motivations must exist in case of the 40% figure. In contrast,
60% of the current users are using FEDERICA because of its unique feature on IP
quality of service assurance or not-configured resource provisioning. 26.6% of users
have requested raw resources and Ethernet connectivity (last column), thus all the
virtual resources are fully configured and controlled by the users.
Checking the potential broader user basis, we anticipate more user experiments in the
future which will exploit the above mentioned unique features of FEDERICA.
2.1.2
Acce s s re qu ire ment
FEDERICA users can manage their slices remotely, accessing the resources via the
User Access Server at the control plane level. However, it is also possible to connect
physical user resources (located at the users’ laboratory) at the data plane level . This
is then connected to the virtual FEDERICA slice which is temporarily owned by the
user. Technically, this access can be realised on the IP layer (e.g., using IPsec tunnels
and public IP addresses) and on the Ethernet layer by accessing the virtual slice at the
physical Point of Presence of the FEDERICA substrate.
The following segmentation aspect studies the access requirements of the users (Fig.
3).
9
Deliverable NA2.3:
Fig. 3 External access requirements to the virtual FEDERICA slice
66% of the actual FEDERICA users do not require to access their slices at the data
plane level. The virtual slice operates in the virtual space, and only control plane level
access is provided by FEDERICA NOC via the User Access Serves and Management
VLAN. 20% of the current experiments are accessing the virtual slice via IPsec
tunnels and another 13% of the experiments have data plane access at the physical
PoPs of FEDERICA. In summary, 33% of users exploit the unique FEDERICA
feature that allows the data plane level connection of external resources (located at the
users’ domain) to the FEDERICA virtual slices. In the future, we expect even more
data plane level access requirements at the physical PoPs of the infrastructure.
2.1.3
Size of the ex per iment
The basic quantity analysis of the user experiments includes the size of the requested
slice in terms of number of resources. The following categories have been defined:
•
We consider the experiments requesting less than 10 virtual resources (nodes
and links) in total as “Feasibility Studies”. In such small slices, only the
technical feasibility of a concept can be validated.
•
The slices with more than 10 but less than 40 resources are not that small
(compared to the size of the FEDERICA infrastructure). Basic technical
functionalities of novel protocols or architectures can be studied in those slices,
so they are considered as “Functionality Studies”.
•
The slices requesting close to 100 resources in total are big. In that size, closeto-real-size networking validation of the concepts can be performed. Those
experiments are considered as “Validation Studies”.
•
Finally, the slices with more than 100 resources are the biggest (hard to
manage) and might be useful for “Scalability Studies”.
The results of the segmentation can be seen in Fig. 4.
10
Deliverable NA2.3:
Fig.4. Size of the requested slices (number of virtual nodes and links)
The majority of the actual user experiments based on the requested number of
resources are a type of functionality study (second column: 66%). This size of slices
perfectly fits with the actual FEDERICA infrastructure size. Among the actual users,
only 1 experiment (PHOSPHORUS: Harmony system scalability study) requested
more than 100 resources in total. Analysing the potential future requests, major
changes in this trend are not expected.
2.1.4
Lifet i me of t he e xp eri ment
The analysis of the experiments’ lifetime shows an important feature of the
FEDERICA user community. FEDERICA users usually request virtual recourses for
relatively longer period of time (definitely not for hours or days). The complexity of
the experiments requires further time to study and manage the FEDERICA resources
since it requires technical competence and at times deep protocol knowledge. Even
the procedure of the FEDERICA slice request is quite complex as is the role of the
infrastructure itself.
11
Deliverable NA2.3:
Fig. 5 Lifetime of the experiments
Fig. 5 shows that there was no slice request for shorter than a 1 month duration and
this is not expected either. 60% of the actual requests are for longer than 3 months in
total. These trends are similar in case of potential future requests as well.
2.2
Non-technical aspects
The non-technical aspects of the user segmentation study focus more on the analysis
of the broader research environment and not its content but the context of the
experiments. In this way, more information on the current user community and
targeted future communities can be obtained.
2.2.1
M oti vat ion of re se arc h
The basic motivation of research behind the FEDERICA users’ slice requests can be
categorised as follows:
•
ICT research on networking
Users may perform research related to networking. It may include novel
networking protocols, network architectures, etc.
•
ICT research on applications and services
Users may perform research on new applications or services. This may include
the networking aspects however, the main focus of research is on the
application /services itself.
•
Applied-ICT research on applications and services
Users may perform research on application and services that are related to ICT,
but the main motivation of the user group is to exploit the results in a non-ICT
environment (e.g., medical community, environmental study, green issues,
etc.)
12
Deliverable NA2.3:
Fig. 6. Motivation of research
The results show that the majority of the actual FEDERICA users are acting in the
ICT community. There was only 1 experiment (PERIMETER: User Centric
Experiments) which was under the applied-ICT category. Our expectation for the
future is the same .
2.2.2
R ation al of re se arc h
It is interesting to investigate the basic rationale behind the slice requests. One of the
obvious reasons to use virtual networks (i.e., using Infrastructure as a Service) instead
of physical test beds is the economy of scale. Some experiments are simply not so
complex or long lived to be worth investing money in building a physical test bed for
that purpose. University researchers or PhD students sometimes have no chance to try
out their new ideas in physical (close-to-real-size) test environments. Therefore, this
motivation group is called “Budgetary use”.
Virtual test environments provide excellent scalability. To exploit the opportunity of a
large number and/or a variety of available resources, some users may request virtual
network slices instead of having physical network facilities. Therefore, this
motivation source is called “Opportunity use”.
The unique features of FEDERICA have been mentioned previously. A group of users
apply for a FEDERICA slice (instead of using other virtual facilities) because of these
unique features in order to perform detailed technical experiments. This usage is
called “Technical use”.
Lastly, the interconnection of various virtualisation infrastructures via federation is
one of the major FEDERICA features. Its virtual slices can be interconnected for
instance with other FEDERICA slices, or slices from other virtual facilities (such as
13
Deliverable NA2.3:
PlanetLab or OneLab), network domains from users’ laboratory (such as PASITO),
etc. This usage is identified as “Federated use”.
Fig. 7 Rational of research (hidden economical aspects)
It can be said that at least 47% of the actual FEDERICA users fall into the “Technical
use” category, mainly exploiting the unique technical features of the FEDERICA
virtual networking service. At least 26% of users have requested a FEDERICA slice
because it was for free and did not require initial physical infrastructure investment.
The federated features were more important than the opportunity of network
scalability and flexibility.
2.2.3
Exp l oit at i on of r esult s
The exploitation of the research results obtained by using a FEDERICA slice is also
important to analyse in order to understand the contribution of FEDERICA (and its
services) to the ICT community via the user projects. The basic categories are as
follows:
•
National project support
•
International/EC project support
•
Standardisation/open source development support
•
Commercial/private research support
14
Deliverable NA2.3:
Fig. 8 Exploitation of FEDERICA experiments’ results
The analysis (see Fig. 8) results show that around 60% of the actual FEDERICA
experiments contribute to other EC funded international research projects (such as
PHOSPHORUS, PERIMETER, GN3, OneLab, etc.) Some of these results contribute
directly or indirectly to standardisation related activities e.g., in OIF or IPsphere. Up
to now, there have been no requests by commercial or private research communities
for FEDERICA experiments but in the future some are expected.
15
Deliverable NA2.3:
3
Consolidated usage reports and user feedback
The final milestone of the Networking Activity 2 was to collect and provide a
“consolidated user feedback”. That is why the official FEDERICA User Policy Board
documents contain a feedback form and all the FEDERICA users had been asked to
provide feedback to the project about the usage of their slice. This milestone has been
achieved and reported in this Deliverable.
As of 31st October, 2010 (the official end of the project) only 60% of users (6
experiments out of 15) were able to provide detailed feedback according to the UPB
form (Fig. 9), because all the other experiments had not been completed yet.
Fig. 9 Completed user feedback forms
Despite this, all the actual FEDERICA users (all the 15 experiments) have been
approached by NA2 participants to provide some (preliminary) information about
their experiment. Beside these feedbacks, the actual usage of the slices can also be
checked via the FEDERICA monitoring system developed by CESNET.
In the appendixes of this Deliverable, a one-page summary of all the actual slices can
be found.
3.1
One-page slice summary of user experiments
In order to provide a quick and easy overview on the experiments, a one-page
summary of all the current slice requests were proposed by NA2.
The one-page summary contains the basic administrative information of the request,
the definition of the experiment, the requested virtual slice topology, the illustration of
the monitoring results of the slice usage (to proof the real usage), the summary of the
major results, the user satisfaction study (based on the feedbacks), and some major
recommendations by the users. The schema of the summary page is as follows.
16
Deliverable NA2.3:
<NAME of the slice>
Slice facts:
Brief description of the experiment:
• Status: <project internal
or external>
<research motivation>
• Contact person: <name,
affiliation>
• Duration: <months>
• Size: <number of
resources>
<This box contains the description of the slice request and the brief
explanation of the research motivation and/or expected results.>
Virtual topology:
Slice usage:
<figure on the virtual slice topology>
<graph from the slice monitoring system in
order to illustrate the real usage>
Major results:
<This box contains the brief description of the results obtained by using a FEDERICA slice.>
Customer satisfaction:
Important feedback:
Communication Services
<value 1-5>
<value 1-5>
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Overall rate:
Technicalities
<value 1-5>
<value>
17
<This box contains the major user
feedback and/or
recommendations.>
Deliverable NA2.3:
The actual FEDERICA experiments (15 slice requests in total) have been categorised
as follows:
•
Project internal users
o Test slices
FEDERICA NOC has configured a few slices for various test purposes
such as the VMware tests and the demonstration slices for user
consultation events and EC reviews. These slices are not considered as
user slices!
o Project internal experiments (Appendix I)
The FEDERICA project internal experiments have been done by
CESNET on infrastructure monitoring and by the JRA1 and JRA2
participants on various research studies related to FEDERICA. The
internal slices are as follows (see Appendix I for the one-page
summaries):
•
-
G3 – monitoring for FEDERICA by CESNET (related to SA2)
-
Meter – background measurement and repeatability by KTH
(related to JRA1)
-
ISOLDA – slice performance study by i2CAT (related to
JRA1)
-
JRA2.3 slice – Interoperability prototype testing by i2CAT
(related to JRA2)
-
VMSR – Virtual multi-stage routing by PoliTo (related to
JRA2) (on-going experiment !)
External users
o Completed experiments (Appendix II)
Only 5 experiments out of 10 external user requests had been fully
completed by 31st October, 2010. The completed external user
experiments are as follows (see Appendix II for the one-page
summaries):
-
HADES – Monitoring and measurements by FAU
-
PHOSPHORUS – Harmony scalability study by i2CAT
-
ELTE – FEDERICA/OneLab federation by ELTE
-
OIS – Optical IP Switching by TCD
-
ANFORA – Multi-layer network scenarios by UMA
o Rejected/cancelled experiments (Appendix III)
There was only one user request cancelled during the FEDERICA
project lifetime. Although this was unfortunate, lessons have been
learned and discussed in the detailed Feedback Analysis section of this
Deliverable. The cancelled user request was:
18
Deliverable NA2.3:
-
BIRD – Internet Routing Daemon by Czech Technical
University
o On-going/pending experiments (Appendix IV)
As of 31st October 2010, there was 3 on-going experiments (i.e., slices
had been configured by the NOC but the user experiments had not
been finished) and 3 pending user requests waiting for UPB decision
and/or NOC configuration. The on-going/pending experiments are as
follows (see Appendix IV for the one-page summaries):
3.2
-
PERIMETER – User-centric scenarios by TSSG
-
VMSR – Virtual multi-stage routing by PoliTo (project
internal!)
-
IDSS – Intrusion detection by AUTH
-
NANDO – Neutral Access Network Demonstrator over
OpenFlow by UPV/EHU
-
GEMBUS – GN3 Composable Network Services by Univ.
Murcia
User feedback analysis
The user feedback analysis is based on the user feedback forms and the one-to-one
consultations with users. The users have been asked about their various experiences
such as: how the communication with FEDERICA was in general; if the portfolio
presented was at the right level; if the services were easily accessible; if the provided
service supported the user project’s goals, etc.
The given answers to these questions were quite diverse in terms of nature and detail.
Therefore, the NA2 partners agreed on a consolidated but subjective evaluation
procedure (assign value of satisfaction in a 1-5 scale) and the given values have been
double-checked and confirmed by the users. Three major user experiences studied are:
•
Communication with FEDERICA bodies (UPB and NOC)
o Values: 1- Poor, 2-Acceptable, 3-Fair, 4-Good, 5-Excellent
•
FEDERICA virtual network services (service provisioning and quality)
•
Technicalities (the technical features of FEDERICA exploited by the
experiment)
The overall user/customer satisfaction index was calculated by the average of the
given values on these experiences. In Fig. 10, the user/customer satisfaction indexes
19
Deliverable NA2.3:
are depicted per these experiences. It is shown that 44% of users found the
communication good with the UPB and NOC, while 22% found it excellent. In terms
of FEDERICA services, 33% found them good while 55% found them excellent. The
technical features provided by the FEDERICA slices were found good by 33% of
users and excellent by 55% of users. Only one user project was cancelled (and
reported poor in all aspects) that was only around 10% of user experiments.
Fig. 10 User satisfaction indexes on communication, services, and technicalities
The overall customer satisfaction indexes per experiments can be seen in Fig. 11. The
HADES experiment resulted with excellent user feedback (5) on all aspects, and six
experiments reported good overall quality (4.6-4.0) of which four were external users
making this result remarkable. One user gave fair results (3.3), while only one other
user gave poor evaluation (1) of FEDERICA. The detailed feedbacks were not
available in the case of six experiments.
20
Deliverable NA2.3:
Fig. 11 Overall user satisfaction index per experiment
The only cancelled experiment (BIRD - Internet Routing Daemon), that returned a
poor result, needs some extra analysis. The reasons were twofold. The BIRD request
was one of the first slice requests coming from the Czech Technical University and
channelled into FEDERICA by CESNET. At that phase of the project, there was no
efficient User Policy Board procedure in place so CESNET directly approached the
FEDERICA NOC and started to negotiate the implementation details since there was
no other way to proceed at that time. This fact caused major communication issues
during the slice handling. The other issue was the NOC internal procedure itself was
not sufficient at that time to deliver the slice according to the initial request. This
technical problem caused timely iteration rounds continuously discussing the redefined details of the slice request. Eventually, due to the initial lack of UPB and
NOC procedures of FEDERICA, CESNET lost the student from the Czech Technical
University who would have been the actual user of the slice.
Lessons have been learned from this experience. Shortly after the failed slice request,
the detailed User Policy Board procedures (reported in DNA2.2) was implemented
and the NOC has been provided with the sufficient tools and manpower.
21
Deliverable NA2.3:
4
Summary
The Networking Activity NA2 (on “Building and Consolidating the User
Community” for FEDERICA) was operating from the beginning to the end of the
project. However, its main focus was shifting as the project evolved. While in the
early phase of the project the main focus of NA2 was on identifying, contacting, and
consulting the potential users, in the later phase the emphasis was more on the
practical user trainings and one-to-one consultations as well as on the better
understanding of the user community and their needs. In the last phase of the project,
the gathering of the usage reports and user feedback consumed more and more NA2
efforts.
By the official end of the FEDERICA project (31st October, 2010), NA2 activity
managed to build a FEDERICA user community (more than 40 potential user groups)
that resulted in the request of 5 project internal slices and 10 external user slices in
total. The overall feedback of users (based on the completed experiments) was fairgood (average 3.93) taking the project communication aspects (UPB), the service
provisioning and delivery aspects (NOC), and the technical capability (FEDERICA
SAs) aspects into account.
22
Deliverable NA2.3:
Appendix I – Project internal experiments
23
Deliverable NA2.3:
G3 - Monitoring for FEDERICA
Slice facts:
• Status: INTERNAL
ICT service/application
• Contact person:
Jiri Navratil (CESNET)
• Duration: 12M<
• Size:
o 3 VNodes
o 3 links
In order to implement, test, and further develop the G3 monitoring
system inside FEDERICA at least one user slice and some traffic
was needed at the beginning of the project. 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.
Monitored virtual topology:
Slice usage:
Major results:
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 was to get some basic information about the slices; how they are
visible on the interfaces and in the traffic demands between the nodes. The monitoring experiment
was successful. The G3 monitoring system has been used for monitoring all the realised user slices
during the project lifetime.
Important feedback:
n/a
n/a
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
n/a
Overall rate:
n/a
24
n/a
Deliverable NA2.3:
Meter – Background measurements and repeatability
Slice facts:
ICT networking
• Contact person:
Peter Sjödin (KTH)
• Duration: 3M
• Size:
o ???
The purpose of this work was to investigate tools for experimental
network research in shared infrastructures such as FEDERICA or
PlanetLab. The work dealt with problems related to running
experiments on a shared network, where other external activities
may influence the results of the experiments. KTH investigated a
method to identify time periods of comparable network conditions
based on metadata-contextual information about the environment
where the experiment was executed.
Virtual topology:
Slice usage:
n/a
n/a
Major results:
During the experiment time frame, KTH ran active background measurements to collect metadata
parameters. Experiment data was time-stamped and KTH used statistical analysis on metadata to
decide if experiment data was gathered during comparable network conditions. An important goal
was to do this without investigating the experiment data itself.
Within the slice, service degradation in terms of resource competition with experimental activities in
other slices was rarely detected. An important part of the experimental work was to detect
differences in network conditions in terms of for example, latency. The FEDERICA slice behaved as
a lightly loaded network, and artificial disturbances were introduced within the slice for experimental
purposes. Background measurements were used to identify periods of comparable network
conditions. The repeatability of the experiments was sufficient.
Important feedback:
Excellent
Excellent
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
Good
Overall rate:
4.6
25
Communication with Federica was
very easy. The services have had a
better uptime than I expected.
The only area that posed a problem
is the IO performance on the node.
When doing data entry/statistical
calculations it's clear that the
virtual node has limited
performance.
Deliverable NA2.3:
ISOLDA – Slice performance study
Slice facts:
ICT networking
• Contact person: Cristina
Cervelló-Pastor (UPC)
• Duration: 6M
• Size:
o 4 VNodes,
o 1 switch
o 6 links
The ISOLDA slice was used to perform basic network performance
and network isolation tests, in order to complete the Task TJRA1.3
activity’s objectives. Simple tests were performed to measure
bandwidth, latency, jitter and packet loss (both UDP and TCP) in
parallel slices of the FEDERICA infrastructure. The overall aim
was to proof the sufficient isolation of slices.
Virtual topology:
Slice usage:
Major results:
The measured performance parameters were isolation, bandwidth, latency, jitter, and packet loss.
Isolation of virtual machines has been proven with ping tests. The results from these tests were
affirmative, as the virtual machines on different slices were not visible to one another. The
bandwidth was measured for both TCP and UDP transmissions, where UDP transmissions achieved
a much higher bit rate. However, large packet losses occurred with UDP transmissions, especially
with higher transmitted bit rates. The jitter measured was acceptable for video and audio streams, but
packet loss was too high as this should ideally not exceed 1% and values of 40% were measured.
Latency was measured on the network using ping tests, where the round-trip times can be seen as the
latency on the network.
Network isolation on two virtual links sharing a physical link was tested successfully, and network
performance tests were satisfactory. The detailed results are reported in Deliverable DJRA1.3.
Important feedback:
Good
Good
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
Excellent
Overall rate:
4.3
26
Slice was down for some time, but
that was resolved quickly.
Deliverable NA2.3:
JRA2.3 slice – Interoperability prototype testing
Slice facts:
ICT networking
• Contact person:
Josep Pons (i2CAT)
• Duration: 3M
• Size:
o 11 VNodes
o 2 routers
o 12 links
The objective of Task TJRA2.3 was related to the establishment of
a technical collaboration framework between FEDERICA and
IPsphere. It was planned to be achieved by prototyping a gateway
for integrating the MANTICORE implementation in the IPsphere
model.
The final step was to validate the prototype over the FEDERICA
virtualised infrastructure. JRA2.3 therefore requested a slice form
FEDERICA and performed the tests using the slice.
Virtual topology:
Slice usage:
Major results:
After the creation of the complete scenario, several minor tests were performed and reported in
Deliverable DJRA2.4. The major test covered the activation of a pre-established but filtered path
between the two sides of the scenario (from one domain to the other), by means of the SMS Child
and MANTICORE interaction. Once this path has been activated a video streaming (that couldn’t be
transmitted very well before the activation of the service path) has been performed with good results.
i2CAT concluded that the prototype with this demonstration which was designed and developed
following the bases of the IPsphere Forum specifications, has a real application over experimental
facilities like FEDERICA. i2CAT also demonstrated that the IPsphere Framework is capable of
interoperating with other Management Tools or Frameworks located in the layer between itself and
the physical infrastructure.
Important feedback:
Fair
Good
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
Fair
Overall rate:
3.3
27
In addition to the initial slice
request, two other VNodes with
MANTICORE software installed
had been requested. There were
some difficulties at the time of
deploying them in the
corresponding server. Finally, the
software routers between the hosts
and the Juniper boxes had to be
passed by.
Deliverable NA2.3:
28
Deliverable NA2.3:
Appendix II – Completed external experiments
HADES - Monitoring and measurements
Slice facts:
• Status: EXTERNAL
• Contact person:
Susanne NaegeleJackson (FAU)
• Duration: 12M<
• Size:
o 5 routers
o 5 VNodes
o Full-mesh
HADES is a tool based on active measurements that produce test
traffic which delivers high resolution network performance
diagnostics. The purpose of the HADES slice experiment was to
collect and archive these IP performance metrics over an extended
period of time and make the data available to other project partners
and experiments that needed reference data as part of their
investigations on the behaviour of virtualized networks and slice
processing. The data was also used to show that FEDERICA users
had a stable network environment and repeatable conditions for
their experiments.
Measured topology:
Slice usage:
n/a
The experiment itself monitors the FEDERICA
substarte links (i.e., not inside the slices) in a
different way.
Major results:
HADES measured the FEDERICA PoPs (see topology map) in a full mesh topology; with bidirectional measurements that yielded 42 measured links. HADES was able to monitor one-way
delay, one-way delay variation and loss over some of the physical infrastructure of FEDERICA.
This statistical data has also been used within several contexts of FEDERICA, for network
operations (NOC), Quality of Service (QoS) related user assistance, as well as support for
FEDERICA research activities of all partners. FEDERICA users benefited from the performance
monitoring with HADES as they could follow up on the stability of the FEDERICA infrastructure
and its repeatable conditions for all use cases and experiments.
Important feedback:
Excellent
Excellent
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
Excellent
Overall rate:
5.0
29
Since we were measuring the
physical infrastructure, our “slice”
could also be considered to be
somewhat of a unique case, where
we were not running a typical
“external” user experiment, but
monitored the FEDERICA
infrastructure around the clock.
Deliverable NA2.3:
PHOSPHORUS – Harmony scalability study
Slice facts:
• Contact person: Jordi
Ferrer Riera (i2CAT)
• Duration: 4M
• Size:
o 15 VNodes
o Full-mesh
Harmony, the brand name of the system developed in FP6 project
PHOSPHORUS, is a multi-domain, multi-vendor network resource
brokering system.
The experiment performed over the FEDERICA slice aimed at
analyzing the performance and scalability of the different Harmony
Network Service Plane (NSP) topologies under different workloads.
Basically, the experiment focused on collecting information about
two parameters: the service provisioning time and the average rate
of blocking requests.
Virtual topologies:
Slice usage:
Major results:
FEDERICA infrastructure provided a large set of virtual hosts with good connectivity for carrying
out a set of extensive and intensive testing in FP6 project Phosphorus WP1 prototypes (Harmony
system). Therefore, large Harmony NSP emulated topologies were built and tested over these hosts.
The scalability tests, which have been performed over the FEDERICA slice, helped to reach the
project goals in studying and analysing which of the feasible architectures of the NSP developed
during the project execution. The tests showed the behaviour of the different architectures under
different stress situations.
An article has been accepted and was presented at the IEEE Globecom 2010 Workshop on
Management of Emerging Networks and Services and contains some of the preliminary results
obtained in the experiments. The whole set of results will be published after all the data is fully
analysed.
Important feedback:
Good
Good
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
Excellent
Overall rate:
4.3
30
Although services were up to the
expected level, a more detailed
Service Level Specification (SLS)
than in the requesting forms would
be really useful both for the
requestor and for FEDERICA.
With a detailed and formal SLS all
the provisioning and evaluation
phases would be faster and more
effective.
Deliverable NA2.3:
ELTE – FEDERICA/OneLab federaiton
Slice facts:
ICT networking
• Contact person:
Gábor Vattay (ELTE)
• Duration: 5M
• Size:
o 2 routers
o 1 link
The aim of this experiment was to create a very simple FEDERICA
slice to validate the scenario as follows; two end-user hosts (i.e., the
OneLab monitoring nodes), situated in the local lab connected to
the public Internet, want to communicate with each other and route
the traffic via the FEDERICA slice requested hereby.
The simple slice request contained two routers connected by one
link in between. The routers must have public IP addresses. IPsec
tunnel must be set up between one virtual router and the ELTE
measurement node in the local lab.
Virtual topology:
Slice usage:
Major results:
This simple interoperability test required only two logical routers from the FEDERICA side and a
point-to-point connection between them. Those FEDERICA resources were successfully connected
to the external resources (the OneLab monitoring nodes) situated in the ELTE laboratory connected
to the public Internet. To create the interconnection, the FEDERICA routers had to have public IP
addresses and secure IP tunnels had to be set up between the external resources and the FEDERICA
routers via the public Internet. To validate the interoperability one-way traffic was sent from one
OneLab monitoring node to the other routing the traffic via the IP tunnels through the FEDERICA
slice. The FEDERICA logical routers were accessible and fully manageable by the ELTE user
remotely via the ELTE Virtual Slice Management Server (or User Access Server).
Important feedback:
Good
Excellent
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
Excellent
Overall rate:
4.6
31
This test was just the first step
toward the further interoperability
scenarios between the OneLab2
and FEDERICA projects. The
overall aim is that the OneLab
users can smoothly request a
FEDERICA slice in case they want
to exploit the additional features of
FEDERICA.
Deliverable NA2.3:
OIS - Optical IP Switching
Slice facts:
ICT networking
• Contact person:
Marco Ruffini (TCD)
• Duration: 6M
• Size:
o 4 VNodes
o 2 routers
o 1 switch
o 6 links
The aim of this experiment was to test the OIS network architecture
that TCD had setup in their laboratory, as a core network, also
testing the interoperability between TCD test bed and other vanilla
IP domains, which would be emulated within the FEDERICA
infrastructure.
In the experiment the FEDERICA infrastructure was organized in a
way that emulates a simple access network, where user data are
aggregated by an IP router and sent towards TCD test bed. Here
packets were routed back to FEDERICA towards the destination
network.
Virtual topology:
Slice usage:
Major results:
TCD could verify how their test bed would work when connected to external legacy IP networks.
The results for example showed that UDP and TCP transmissions are not impaired when the signals
are dynamically switched from an electronic to an optical connection. Another interesting outcome
of our experiment was a consequence of the fact that flow switching is typically performed
asymmetrically, as it is usually operated only in the direction of the data stream. If congestion affects
also the direction where TCP acknowledgments travel, the optical bypass in the direction of the data
transmission alone does not improve the flow rate and can cause additional transitory impairments.
The experiment also gave TCD the opportunity to evaluate feasibility and efforts required to use
virtualized network test beds. The results of the experiment have been summarised in conference
papers (submitted to ICTON 2010 and HEAnet Conference 2010).
Important feedback:
Good
Excellent
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
Good
Overall rate:
4.3
32
Did get prompt replies to the
questions asked. The support
needed was higher because we
wanted to connect our own test bed
to the FEDERICA infrastructure.
We had a few technical issues,
which were promptly solved by the
FEDERICA helpdesk.
Deliverable NA2.3:
ANFORA - Multi-layer network scenarios
Slice facts:
ICT networking
• Contact person: Jorge
Lopez de Vergara
(UMA)
• Duration: 6M
• Size:
o 8 VNodes
o 4 routers
o 14 links
This experiment involved three infrastructures; FEDERICA, a
network infrastructure that allows the creation of virtual networks
on top of it, PASITO, a layer-2 network that connects main network
research workgroups in Spain, and OneLab, an open federated
laboratory, where researchers can have timeslots to do their
experiments on real nodes connected to Internet.
The main objectives of this experiment were: to evaluate Path
Computation Element Protocol (PCE), and to validate Multi-layer
Traffic Engineering algorithms (MTEA) over various test beds.
Virtual topology:
Slice usage:
Major results:
UAM has got OneLab nodes and provided AGROS cards to the OneLab to perform quality of
service measurement in the network. UAM is also connected to PASITO allowing a direct
connection of FEDERICA through the RedIRIS PoP.
In the first scenario, the unique interconnection of OneLab-PASITO-FEDEEICA provided a test bed
in order to successfully validate MTE algorithms. In the second scenario, monitoring software from
OneLab was installed on VNodes provided by FEDERICA. The FEDERICA slice was accessed via
GRE tunnel so it was possible to evaluate the performance of a multi-layer PCE, too.
Important feedback:
Acceptable
Excellent
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
Excellent
Overall rate:
4.0
33
When the configuration was done,
we do not receive information
about the installed programs in
each node. It could be interesting to
provide a general email with the
information for each type of node.
The NOC responded slowly.
The slice request process is clear
with the information shown in the
website. The connection was easily
done.
Deliverable NA2.3:
Appendix III – Rejected/Cancelled experiments
BIRD - Internet Routing Daemon
Slice facts:
ICT networking
• Contact person:
??? (Czech Technical
University)
• Duration: ???
• Size:
o 10 VNodes
o 2 routers
o 13 links
The slice in FEDERICA network would have been used for setting
up a test network consisting of 3-4 autonomous systems running
internally OSPF for IPv4 and RIP for IPv6 (BIRD doesn't support
OSPFv3 yet), and BGP as the inter-domain routing protocol for
both IPv4 and IPv6.
The goal of the tests was twofold: evaluate interoperability of
routing protocol implementations, and assess performance of a PC
router with BIRD in terms of raw throughput and its impact on QoS
characteristics (delay and jitter).
Virtual topology:
Slice usage:
Major results:
The slice creation started based on bilateral discussions between the NOC personnel and the NREN
being contacted by the user (at that time, the sufficient UPB procedures were not in place). Later on,
the official slice request (i.e., D7-FEDERICA-Project-Plan document) was never been received by
UPB (due to loss of interest) and the slice was never set up properly.
Cancelled experiment!
Important feedback:
Poor
Poor
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
Poor
Overall rate:
1.0
34
After half a year discussion and
exchanging emails and documents
CESNET lost students from FITCzech Technical University, who
would have been the real
researchers/users of the slice.
Deliverable NA2.3:
35
Deliverable NA2.3:
Appendix IV – On-going/Pending experiments
PERIMETER – User-centric scenarios
Slice facts:
Applied-ICT research
• Contact person:
Jerry Horgan (TSSG)
• Duration: 12M<
• Size:
o 5 VNodes
o 5 links (ring)
FP7 project PERIMETER’s main objective is to establish a new
paradigm for user-centricity in advanced networking architectures.
Much of the innovation behind PERIMETER comes from the
Quality of Experience (QoE) concept, primary driver for the
definition of user-centric seamless mobility protocols, enabling true
“Always Best Connected” (ABC) services.
The FEDERICA experiment will enable three scenarios: Usercentric, agnostic ubiquitous communication, Emergency Situation /
Health care, and Community Networks.
Virtual topology:
Slice usage:
Major results:
Currently, the infrastructure interconnections have been set in place. PERIMETER Integration WP
leaders, Waterford Institute of Technology (WIT) is currently in the process of detailing the next
steps required to utilise the FEDERICA interconnection as effectively as possible within the
PERIMETER project.
On-going experiment!
Important feedback:
n/a
n/a
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
n/a
Overall rate:
n/a
36
n/a
Deliverable NA2.3:
37
Deliverable NA2.3:
VMSR – Virtual multi-stage routing
Slice facts:
ICT networking
• Contact person:
Andrea Bianco (PoliTo)
• Duration: 3M
• Size:
o 9 VNodes
o 1 switch
o 9 links
The VMSR (Virtual Multistage Software Router) experiment
involves the definition of the distributed router architecture. The
elements of the multistage router must be coordinated and
controlled such that the full architecture behaves externally as a
single router. In these scenario functional tests will be performed.
After that PoliTo wants to perform some basic performance test,
like throughput and latency.
This experiment is part of the contribution of Politecnico di Torino
to JRA2 working package of FEDERICA project.
Virtual topology:
Slice usage:
Major results:
We considered a routing experiment involving the definition of distributed router architecture.
Distributed routers are logical devices whose functionalities are distributed on multiple physical (or
logical) servers, to achieve larger aggregate throughput and/or improved reliability.
Preliminary functional test on the control and management plane functionalities were successfully
run. We measured throughput and latencies on all the involved links while varying the packet size of
traffic generators.
On-going experiment!
Important feedback:
n/a
n/a
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
n/a
Overall rate:
n/a
38
n/a
Deliverable NA2.3:
IDSS – Intrusion detection
Slice facts:
• Contact person:
Georgios Mamalakis
(AUTH)
• Duration: 3M
• Size:
o 10 VNodes
o 2 routers
o 3 switches
o 14 links
The goal of this user project is to illustrate a three-tier network
topology that will be probed against malicious and normal traffic.
In order to achieve this, two routers will be needed to separate the
network into three sub-networks.
Throughout the project, an intelligent Host based Intrusion
Detection System (H-IDS) will be deployed, and it will be installed
on hosts belonging to all three tiers. Attacks will be conveyed
towards many directions. Later, an intelligent Network based
Intrusion Detection System (N-IDS) will be deployed that will
analyze the traffic flow.
Virtual topology:
Slice usage:
Major results:
User slice has been set up by the FEDERICA NOC, final configuration is on-going.
Pending experiment!
Important feedback:
n/a
n/a
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
n/a
Overall rate:
n/a
39
n/a
Deliverable NA2.3:
NANDO - Neutral Access Network Demonstrator over OpenFlow
Slice facts:
ICT networking
• Contact person:
Eduardo Jacob
(UPV/EHU)
• Duration: 2M
• Size:
o 7 VNodes
o 9 links
The main objective is to try a neutral access network proposal. The
experiment would consist in the deployment of an access network
based on OpenFlow switches in which two access network
providers will be deployed. Each of these network providers will
provide services to authorized users. At least one service provider
will be located in the KTH lab. The users will be represented by
processes launched from UPV/EHU Lab.
The experiment will try to compare the service setup time of
static/dynamic services and the classic pure switching approach.
over the same infrastructure.
Virtual topology:
Slice usage:
n/a
Major results:
Under FEDERICA NOC configuration.
Pending experiment!
Important feedback:
n/a
n/a
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
n/a
Overall rate:
n/a
40
n/a
Deliverable NA2.3:
GEMBUS – GN3 Composable Network Services
Slice facts:
• Contact person: Pedro
Martinez-Julia
(Univ Murcia)
• Duration: 24M
• Size:
o 5 VNodes
o 1 routre
o 5 links
The goal of this experiment (part of GN3 JRA3 T3) is to establish
seamless access to the network infrastructure, where it is possible to
use direct collaboration between network elements to provide more
complex community-oriented services through their composition.
The final result will be the availability of network middleware
(APIs) for seamless access to the network infrastructure (in the
form of composable network services) by applications.
This infrastructure has been named GEMBus that stands for
GÉANT Multi-domain Bus.
Virtual topology:
Slice usage:
n/a
Major results:
University of Murcia designed a proof-of-concept application to demonstrate how Autonomic
Computing (AC) services can be used in collaboration with eduroam infrastructure to build a crossdomain self-managed system based in GEMBus. As JRA3 T3 pretends only to show an example
application of GEMBus mechanisms, it must be clarified that this proof-of-concept should not be
used as a service or enhancement proposition due to the privacy violation this can provoke.
Under FEDERICA UPB discussion. Not yet approved experiment!
Important feedback:
n/a
n/a
5 - Excellent
4 - Good
3 - Fair
2 - Acceptable
1 - Poor
Technicalities
n/a
Overall rate:
n/a
41
n/a
Deliverable NA2.3:
Appendix V – List of consulted user communities
Potential Irish users consulted by HEAnet
Organisation
Contact person
Project / Interest area
Trinity College Dublin (TCD)
Marco Ruffini
Department of Computer Science
Dr. Donal
O’Mahony
Framework for building
a multi-layer router
architecture, by
providing typical
integrated routing,
switching and
signalling functions
Centre for Telecommunications
Value-Chain Research (CTVR)
Trinity College Dublin (TCD)
Dr. René Meier
n/a
Miguel Ponce de
Leon
n/a
Graham Williamson
Primary focus is largescale distributed
systems, middleware
and sensors
Department of Computer Science
Distributed Systems Group
Waterford Institute of
Technology (WIT)
Telecommunications Software &
Systems Group (TSSG)
University College Dublin
(UCD)
School of Computer Science and
Informatics (CSI)
42
Deliverable NA2.3:
Potential German users consulted by DFN
Phase I
Organisation
Contact person
Technische Universität Berlin
Thomas Kaschwig
Project Perimeter
DAI-Labor
Fikret Sivrikaya
Native IPv6
Technische Universität
München
Prof. Dr.-Ing. Georg
Carle
ResumeNet
Wolfgang Moll
Project ARGON
Institut für Informatik
Rheinische FriedrichWilhelms-Universität Bonn
AutoBAHN
Institut für Informatik
Friedrich-Alexander
Universität ErlangenNürnberg
Susanne NaegeleJackson
OpenFlow
Technische Universität
Kaiserslautern
Paul Mueller
Project G-Lab
Universität Passau
Herman De Meer
Project PlanetLab
Organisation
Contact person
FU Berlin
Prof. M Günes
WISEBED
Phase II
43
Deliverable NA2.3:
Uni Paderborn
Jens Lischka
OneLab
Holger Karl
4WARD
EICT GmbH
Andreas Köpsel
PanLab, PII
FOCUS FhG
Sebastian Wahle
n/a
44
Deliverable NA2.3:
Potential Spanish users consulted by RedIRIS
Organisation
Contact person
Universidad de Granada
Juan Manuel López
Soler
n/a
Sebastián Balboa
García
Security and network
infrastructure
i2BASK
Josu Arramberri
Bask Country Internet 2
network development
Universidad de Vigo
Cristina Lopez Bravo
n/a
Uniersity of Pais Vasco (EHU)
Eduardo Jacob
n/a
Universitat Politècnica de
Catalunya (UPC)
Jordi DomingoPascual
n/a
Javier Aracil Rico
OneLab2, PASITO
Dpto. Teoría de la Señal,
Telemática y Comunicaciones
ETSI Informática y de
Telecomunicación.
Centro Informático Científico
de Andalucía (CICA)
Consejería de Innovación,
Ciencia y Empresa
Junta de Andalucía
Departament d'Arquitectura de
Computadors
Universidad Autónoma de
Madrid (UAM)
High Performance Computing
and Networking Research
Group
45
Deliverable NA2.3:
Potential Swiss users consulted by SWITCH
Organisation
Contact person
Eidgenössiche Technische
Hochschule Zürich (ETHZ)
Timothy Roscoe
n/a
Ecole Polytechnique Fédérale
de Lausanne (EPFL)
Karl Aberer
n/a
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
46
Deliverable NA2.3:
Potential Hungarian users consulted by NIIF/Hungarnet and TERENA
Organisation
Contact person
University of Szeged (uszeged)
Vilmos Bilicki
Botnet detection
Dr. Laszlo Pap
Developing mobile
roaming services
Dr. Gábor Vattay
FEDERICA – OneLab2
interworking
Department of Informatics
Budapest University of
Technology and Economics
(BME)
Mobile Innovation Centre
Eötvös Loránd University
(ELTE)
Collegium Budapest
47
Deliverable NA2.3:
Potential Greek users consulted by GRNET
Organisation
Contact person
Aristotle University of
Thessaloniki
Prof. Leonidas
Georgiadis
Network infrastructure
and information security
Department of Electrical and
Computer Engineering
Georgios Mamalakis
48
Deliverable NA2.3:
Potential user projects approached by NA2 partners
Organisation/Project
Contact person
Interest area
RENATER
Franck Simon,
Interested in hosting a FEDERICA
PoP and take part in the slicing
process.
Danny Vandromme
EGEE-III project
Guillaume Cessieux
(CNRS)
Primary interest is to experience
the virtual slice creation, in
particular the guaranteed
bandwidth between nodes.
They want to experience the slice
creation.
PASITO project
Miguel Angel Sotos
(RedIRIS)
Examining platforms for analysis
of telecommunications services
and experiments.
OpenFlow initiative
Peter Sjödin (KTH)
Studying OpenFlow as a
virtualization platform for
FEDERICA.
4WARD project
Norbert Niebert
(Ericsson)
Investigating Future Internet
architectures.
ANA project
Dr. Martin May
(ETH)
ANA project’s user community
could be interested in virtualised
network architectures.
49

- FEDERICA

Transcription

Similar documents

Deliverable NA2.2: FEDERICA User Community and Requirements

columbus by the slice

9-Online-Micro-jobs - The Moonlighter`s Guide

Decoding Innovation + Design

recipe of the week - Accu Weight-loss

Color InspIratIon GUIDE

Slice 19 - Baking Industry Association of New Zealand

Slice Competition Special - Baking Industry Association of New

Issue 18 - Baking Industry Association of New Zealand

7 Quality Tools

BLUE-ETS