Deliverable NA2.2: FEDERICA User Community and Requirements

Transcription

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
Contractual Date of
Delivery
Actual Date of Delivery
Editor
Contributors
Reviewers
Public
30 September 2008
6 April 2009
P. Szegedi – TERENA
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
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
1.2
2
FEDERICA UPB procedures ............................................................................ 5
2.1
2.2
2.3
3
Basic motivations for the current work.......................................................... 3
Document overview ...................................................................................... 4
User Policy Board......................................................................................... 5
Procedures and basic documents ................................................................... 6
Internal user trial........................................................................................... 7
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
4.2
4.3
5
Users interested in FEDERICA resources ................................................... 20
Users interested in virtualisation platforms/concepts ................................... 23
Users interested in peering/federating with FEDERICA .............................. 24
Conclusions and further work......................................................................... 25
5.1
5.2
5.3
Conclusions ................................................................................................ 25
Plans for user consultation events................................................................ 25
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:
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.
2.
3.
4.
Preliminary user consultation (January 2008 – October 2008)
Internal feedback (November 2008 – March 2009)
Selected external user feedback (April 2009 – December 2009)
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:
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:
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
Peter Kaufmann, Chair
Affiliation
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:
connected to the FEDERICA e-Infrastructure, ensuring essentially that the use is noncommercial, 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@fp7federica.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:
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-ofUnderstanding”.
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-FEDERICAUser-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
HEAnet
Contact person
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)
Dr. René Meier (0.4 MM)
Distributed Systems Group
Waterford Institute of Technology (WIT)
Telecommunications Software & Systems Group
7
Miguel Ponce de Leon (0.4
MM)
Deliverable NA2.2:
(TSSG)
University College Dublin (UCD)
School of Computer Science and Informatics
(CSI)
Graham Williamson (0.4
MM)
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:
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:
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 FP7FEDERICA 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:
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:
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 interdomain network resources requested will be controlled by this main IDB.
Table 3: Requirements for test case one (centralised NSP model)
Computing
Requirements
per VM
NSP
Item
Constraints
Networking Requirements
per VM
1 IDB
1 VM
512 MB RAM – 20 GB
HDD
1x NIC with public IP address
1x NIC with private IP address
(LAN)
30 HNA
1 VM per 4
HNA
1 GB RAM – 50 GB
HDD
(LAN)
TOTAL
9 VM
Interconnection between VMs
is only needed for signalling
purposes. No high
performance/BW links needed.
12
Deliverable NA2.2:
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)
NSP
Item
14 IDB
Constraints
Computing
Requirements
per VM
1 VM – 3
IDB
1 GB RAM – 60 GB
HDD
13
per VM
Desired:
1x NIC with private IP
address (LAN)
Minimum:
Deliverable NA2.2:
per VM
1x VM with public IP address
30 HNA
1 VM per 4
HNA
TOTAL
13 VM
1 GB RAM – 50 GB
HDD
1x NIC with private IP
address (LAN)
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:
Table 5: Requirements for test case three (distributed NSP model)
Computing
Requirements
per VM
NSP Item Constraints
per VM
20 IDB
1 VM – 3
IDB
1 GB RAM – 60 GB
HDD
Desired:
(LAN)
Minimum:
1x NIC with public IP address per
VM
1x VM with public IP address
20 HNA
1 VM per 4
HNA
1 GB RAM – 50 GB
HDD
(LAN)
TOTAL
13 VM
3.2.2
Interconnection between VMs is
only needed for signalling
purposes. No high
performance/BW links needed.
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
(per VM)
Networking
Minimum: 512 GB
Desired: 1 GB
Optimum: 2 GB
•
•
•
Public IP addresses are needed for VMs
Private LAN is needed for interconnecting VMs
(signalling)
No high performance networking needed.
15
Deliverable NA2.2:
OS to be installed by
Phosphorus WP1
Software to be used
by Phosphorus WP1
Debian [Deb] GNU/Linux release 4.0 (etch)
•
•
•
•
•
•
Apache-tomcat.6.x or later [Atomcat]
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:
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:
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:
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:
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
Marco Ruffini
Dr. Donal
O’Mahony
Centre for Telecommunications
Value-Chain Research (CTVR)
Project / Interest area
Framework for building
a multi-layer router
architecture, by
providing typical
integrated routing,
switching and signalling
functions.
Experiments in
IP/optical networks.
Dr. René Meier
n/a
Miguel Ponce de
Leon
n/a
Graham Williamson
Primary focus is largescale distributed
systems, middleware
and sensors
Distributed Systems Group
Waterford Institute of
Technology (WIT)
Telecommunications Software &
Systems Group (TSSG)
University College Dublin
(UCD)
School of Computer Science and
Informatics (CSI)
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:
Table 8: German users (expected in March 2009)
Organisation
Technische Universität Berlin
Contact person
Thomas Kaschwig
Project Perimeter
DAI-Labor
Fikret Sivrikaya
Native IPv6
Technische Universität
München
Prof. Dr.-Ing. Georg
Carle
n/a
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 protocol tests
Technische Universität
Kaiserslautern
Paul Mueller
Project G-Lab
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
i2CAT
Universidad de Granada
Dpto. Teoría de la Señal,
Telemática y Comunicaciones
Contact person
Joan A. Garcia Espin,
Jordi Ferrer, Sergi
Figuerola
PHOSPHORUS
Juan Manuel López
Soler
Massive deployment of
applications based on the
Data Distribution Service
(DDS) standard.
Sebastián Balboa
Multicast IPv4 & IPv6
ETSI Informática y de
Telecomunicación.
Centro Informático Científico
21
Harmony system
architecture scalability
study
Deliverable NA2.2:
de Andalucía (CICA)
García
Consejería de Innovación,
Ciencia y Empresa
tests
QoS for VoIP and video
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
Catalunya (UPC)
Jordi Domingo-Pascual
n/a
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
Eidgenössiche Technische
Hochschule Zürich (ETHZ)
Contact person
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
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:
Table 11: Hungarian users (expected in March 2009)
Organisation
Eötvös Loránd University
(ELTE)
Contact person
Dr. Gábor Vattay
FEDERICA – OneLab2
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
RENATER
Contact person
Franck Simon,
Danny Vandromme
KTH
Peter Sjödin,
Studying OpenFlow as a
virtualization platform for
FEDERICA.
Markus Hidell
EGEE-III project
Interest area
Interested in hosting a FEDERICA
PoP and take part in the slicing
process.
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
23
Examining platforms for analysis of
telecommunications services and
Deliverable NA2.2:
(RedIRIS)
experiments.
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.
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
GENI project
n/a.
Potential collaboration
Very similar US initiative to
FEDERICA with much broader
scope.
protoGENI
G-LAB
VINI
Andy Bavier
(Princeton University)
VINI is aiming at building a similar
infrastructure over Internet2/NLR.
National Institute of
Information and
Communications
Technology of Japan
(NIICT)
Toshio Soumiya,
Building a similar network/service
in Japan.
FIRE test beds
Georgios Tselentis
Collecting a matrix of users and
FIRE test beds.
Paulo de Sousa
Some projects are waiting to use
FEDERICA.
Anastasius Gavras
n/a.
Toshiaki Suzuki
Unit F4
FIA
Unit D
EURESCOM,
FIREWORKS and
PII
24
Deliverable NA2.2:
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:
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:
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:
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:
•
“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-FEDERICAUser-Feedback” .
The FEDERICA User Policy Board
29
Deliverable NA2.2:
D2-FEDERICA-Basic-User-Information-v2.1.doc
Basic User Information
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:
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:
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:
•
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:
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:
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.planetlab.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:
•
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 panEuropean 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:
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:
D3-FEDERICA-Access-Rules-v2.1.doc
Access Rules and Guidelines for the FEDERICA infrastructure
FEDERICA User Policy Board
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]:
2.1
•
The list of documents to be exchanged is:
•
Memorandum of Understanding
•
Acceptable User Policy
•
Project Plan
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:
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:
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]
[2]
[D1]
[D7]
http://cordis.europa.eu/fp7/ict/future-networks/home_en.html
http://cordis.europa.eu/fp7/ict/fire/event-23-240407-sum_en.html
D1 FEDERICA Letter Introduction
D7 FEDERICA Project Plan
40
Deliverable NA2.2:
D4-FEDERICA-Acceptable-Use-Policy-v1.0.doc
FEDERICA Acceptable Use Policy
FEDERICA User Policy Board (UPB)
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:
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:
•
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:
D5-FEDERICA-Resource-Description-v0.3.doc
Resource Description for the Federica Infrastructure
Draft version
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:
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:
•
Logical routers (LR)
•
Software routers (V-node)
•
Hosts (V-node)
46
Deliverable NA2.2:
D6-FEDERICA-MoU-v1.0.doc
Memorandum of Understanding (MoU)
between FEDERICA and ??? [other project/group/person name]
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:
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
12
1 2
3 4
5
2009
6 7 8
9 10
11
12
1
2
2010
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 nonconfidential. 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:
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:
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:
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
Research on
network layers /
Transparency
Time of usage
Type of usage
Response /
Provisioning
time
Level of control
Level of
monitoring /
measurement
Scalability
Reliability /
Availability
Security/
Authentication
PARAMETER
Layer 2
Layer 3
Layer 4+
Short (hours)
Mid (days)
Long (months)
Off-line
On-line
Provisioned
Scheduled
On-demand
No
Semi
Full
Off-line reports
Interactive debug
DESCRIPTION
Research on what
layer?
REQUIREMENT
[choice]
Typical time of
usage?
[value]
Experiments on
the background or
live?
Expected service
response time?
[choice]
Control on the
service?
[choice]
Monitoring of the
elements and/or
traffic?
Number and size of Typical number
the network slices
and size of
network slices?
R/A of the network Expected number
slices
of nines?
Internal risks
Importance of
security level?
External threats
[choice]
[choice]
[value]
[value]
[Y/N]
Network-related requirements (Network slices)
CATEGORY
Traffic matrix /
Connection
topology
Bandwidth
QoS level
PARAMETER
Point-to-point
Point-to-multi
point
Multi point-tomulti point
High
cap./Narrowband
Best Effort
DESCRIPTION
Typical usage?
REQUIREMENT
[choice]
Typical
bandwidth?
Level of QoS?
[value]
51
[choice]
Deliverable NA2.2:
Quality of Service
Delay
Jitter
Loss rate
Fairness
Type of IP
network
Network
management
Traffic
management
Close network
Open network
Fault
Performance
Topology
Bandwidth
CAC
Policing
Accounting
Cost
Expected delay?
Expected jitter?
Expected loss?
Expected fairness?
Require public IP
addresses?
Importance of
network
management?
Importance of
traffic
management?
Importance?
Importance?
[value]
[value]
[value]
[value]
[choice]
[Y/N]
[Y/N]
[Y/N]
[Y/N]
Application-related requirements (Virtual Machines/software packages)
CATEGORY
Processing power
Memory
Storage resources
Operating
Systems
3
DESCRIPTION
Typical processing power?
Typical memory?
Typical storage?
Are you interested in a particular
Operating System?
Slice Topology Map
(a topology example to be included)
52
REQUIREMENT
[value]
[value]
[value]
[Y/N]
Deliverable NA2.2:
D8-FEDERICA-User-Feedback-v1.0.doc
User Feedback
for the FEDERICA infrastructure
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: D9FEDERICA-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:
•
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?
•
And for which services?
Yes/No
All/Layer 1/2/3/appl
•
Were you able to manage your slice properly?
Yes/No
•
Was extensive help from FEDERICA needed?
Yes/No
•
Were there gaps in the operational management of the FEDERICA service?
Yes/No
•
What results of your project were achieved mainly due to FEDERICA
services?
•
Were the peering arrangements with other slices satisfactory?
•
Were the isolation arrangements between other slices satisfactory? Yes/No
•
Was the Commodity Internet connectivity satisfactory?
Yes/No
Yes/No
•
What other services should be provided by FEDERICA?
54
Deliverable NA2.2:
•
Was the physical connectivity towards the FEDERICA service easy to
implement?
Yes/No
55

Deliverable NA2.2: FEDERICA User Community and Requirements

Transcription

Similar documents

- FEDERICA

columbus by the slice

Decoding Innovation + Design

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

Cycle 7 / Lecture 14

BLUE-ETS

recipe of the week - Accu Weight-loss

Harnessing Innovapon in city development for social equity and

Slice 19 - Baking Industry Association of New Zealand

CONCERTOUR_Deliverable5.2_FINAL (Other project deliverable)