This page explains main aspects of a pilot phase of a product or a service.
Text written with Italic blue letters explains the purpose of the field and should be deleted when this template is populated for a specific pilot.
Name: Consolidated Connection Service
Start Date: 1. 4. 2018
End Date: 30.9.2018
Pilot Description:
The Consolidated Connection Service is successor of the BoD service. It provides fully transparent Ethernet circuits over the Geant network using specific software tools for automated provisioning. Key characteristic of CCS are:
- Automated provisioning based on Network Service Interface (NSI) protocol
- Provides API (SOAP, REST) which can be used by 3rd party systems to request a connection
- Enables automated multi-domain service provisioning over NSI enabled networks worldwide
- Resources reservations
The CCS is an abstraction of network functionality and some physical entity which could be pointed as "the CCS instance" is probably the Network Service Agent (NSA) - the Geant NSI aggregator. It provides the NSI interface (the API) which different other systems can use to request circuits. Such system can be a Connection Service GUI or other more complex services like GTS application, or NSAs of foreign network domains.
The pilot deployment of the CCS will cover all eight routers/locations where GTS has any resources connected to MX routers. The pilot deployment will be managed by JRA2 T1 in cooperation with SA1.
The technology used for CCS provisioning will be for the pilot time frame supported by JRA2 T1.
Pilot Category: Service
Required Infrastructure:
The CCS itself requires a little in case of physical infrastructure. Considering the IP/MPLS core network as prerequisite, the only what is need is the VM with running instances of OpenNSA. The VM is now hosted on the GTS CSF0 server in the core GTS node in Prague.
VM requirements | OpenNSA server | |
---|---|---|
Description of usage | Runs OpenNSA instances | |
Number of VMs with same specification | 1 | |
Hardware requirements (CPU, RAM, disk space) | 1CPU, 4GB RAM, 60GB HDD | |
Network connection requirements | 1 Gbps |
|
IP addressing requirements (IPv4, IPv6, public routable) | 1 Public IP | |
Naming requirements1 |
Users:
User of the CCS can be anyone (or anything - in case of other system like GTS) who (which) needs a connection between two defined termination points.
Possible currently known users are:
- Geant Testbed Service (GTS): uses the CCS for Ethernet virtual circuits
- Connection Service GUI: successor of the current BoD service portal - can be used by network operations to automatize circuit provisioning (currently done manually for Geant plus), or can be used by users directly
- Other network's NSAs (member NRENs, or partner networks around the world) which needs a connection trough Geant core for their users
Average number of circuits requested by GTS per one month is approximately 400.
Objectives:
The pilot of the CCS should prove that the service is ready for to be a successor of current Geant's connection oriented services. The pilot will be done by JRA2 T1 in cooperation with SA1 in order to prove the service as designed in real production conditions. There will be a complementary technology pilot of the OpenNSA as a future Geant's implementation of the NSI protocol for the automated circuit provisioning. The CCS uses the NSI protocol for the circuit provisioning and the connection service provided will evolve in time. The initial definition is in fact a best effort EVPL type of service. There is a plan for upgrade the service specification by allowing to specify other QoS parameters like required bandwidth and request a guarantee for meeting that parameters in next version of CCS. This depends on the further development of the OpenNSA and also on technological features available in Geant backbone.
The pilot has following main objectives with corresponding Success Factors and Key Performance Indicators.
Objective | Success Factors | Key Performance Indicators | Notes |
---|---|---|---|
To prove the service concept and its automated provisioning | |||
Collect operation experience. (to involve SA1) | |||
To test the whole provisioning system reliability |
Explain the objectives for the pilot - what does the pilot want to test / prove. Define Critical Success Factors (CSFs) and Key Performance Indicators (KPIs)
Means of verification:
How it will be checked if the pilot has met the defined objectives. Consider also conducting a survey among pilot participants. Each objective might have their own means of verification. Since this page will be used for pilot closure, the table is created with the third column stating is the objective is verified and reached or not. This should be populated before the end of the pilot and be used for pilot success assessment.
Objective | Means of verification | Status (objective verified?) |
---|---|---|
Communication plan:
The inidividual participants (JRA2 T1 -CCA as service development team, JRA2 T3 - GTS as the main user and SA1 as the network operations) will comunicate via service mailing list (with ticketing system), via project space in JIRA (for feaure requests and technical questions/issues) and using regullar VCs (once per month).
Explain how will the team communicate with pilot participants, e.g. regular (weekly/bi-weekly/...) meetings, mailing lists, instant-messaging channels,...
Additional documentation:
Consolidated Connection Service
Provide (links to) any additional documentation as needed.
If this is a pilot of a technology, provide relevant links about the technology that is being tested, previous related work in and outside of GEANT project.
If this is a pilot of a service, provide links to Service template completed for this service.