Speaker
Mr
Ruslan Smeliansky
(ARCCN)
Description
Modern research cloud infrastructures purposed to help researcher to prepare virtual environment that satisfy various specific requirements. The focus could be set on a network topology and providing different network functions (NAT, Firewall, IDS, vSwitch etc.) in order to provide testbed for network research, or a network device testing. Another focus could be set on compute resources providing researcher the computational cluster, for example Hadoop-cluster. Regardless of purposes the researcher uses the cloud infrastructure we need the unified system that manages and orchestrates all types of cloud infrastructure resources.
Network Function Virtualization (NFV) techniques separates network function logic from the hardware, which executes the first. There are several basic use cases for NFV. The network function (NF) lifecycle is stage process, that means that each NF passed through deployed stage, initialization stage, configuration stage, execution stage and undeploying stage. In our Demo the NF lifecycle managing and orchestration in DC will be demonstration.
We would like to present a cloud platform architecture that adheres to the reference implementation ETSI NFV MANO model. As we will show the platform architecture and design successfully meet the requirements of researcher cloud VNFs. We call our platform Cloud Conductor or C2. The C2 platform provides the full VNF life-cycle support: initialization, configuration, execution and uninitialization.
The C2 Platform provides virtual network services (VNS) to researchers by CPE virtualization. Virtual customer premise equipment (vCPE) is a way to deliver network services such as routing, firewall security and access to computational resources by using software rather than dedicated hardware devices. By virtualizing the CPE, the C2 Platform can simplify and accelerate service delivery, remotely configuring and managing devices and allowing researchers to order new services or adjust existing ones on demand.
Especially will be discussed the CloudGW module solution, that is aimed to provide an entry border point for traffic from researcher to a virtual cloud infrastructure for further processing, depending on required virtual infrastructure (DBaaS, Hadoop, classic IaaS and etc.).
The main value of a general service-oriented platform is the diversity of the predefined VNFs that can be deployed on this platform and the quality of service this cloud platform guarantees to researchers. We believe it is fundamentally wrong to create dedicated VNFs for a specific cloud platform. All VNF descriptions should be done based on a standard domain-specific language (DSL) to provide isolation between a cloud platform API and a VFN implementation.
For the purposes of VNF specification we use TOSCA (Topology and Orchestration Specification for Cloud Applications). This description, called TOSCA-template, is everything that is needed to describe a VNF. It covers the structure of a cloud application, its management policies, specifies an OS image and scripts, which can start, stop and configure the application that implements the VNF. The C2 platform assumes that a cloud manager should provide the TOSCA-template as a zip or tar archive with predetermined structure.
We’d like to share the results of over NFV MANO platform overheads analysis and discuss our future plans.
Primary author
Mr
Vitaly Antonenko
(ARCCN)
Co-author
Mr
Ruslan Smeliansky
(ARCCN)
