NFV in the Cloud CPE Solution
The Cloud CPE Solution uses the following components for the NFV environment:
For the centralized deployment:
Network Service Orchestrator provides ETSI-compliant management of the life cycle of network service instances.
This application includes RESTful APIs that you can use to create and manage network service catalogs.
Contrail OpenStack provides the following functionality:
Underlying software-defined networking (SDN) to dynamically create logical service chains that form the network services
NFV infrastructure (NFVI).
Virtualized infrastructure manager (VIM)
For the distributed deployment:
Network Service Orchestrator, together with Network Service Controller, provides ETSI-compliant management of the life cycle of network service instances.
Network Service Controller provides service-chaining and the VIM.
The CPE device provides the NFV infrastructure (NFVI).
Other CSO components connect to Network Service Orchestrator through its RESTful API:
Administration Portal, which you use to set up and manage your virtual network and customers through a graphical user interface (GUI).
Administration Portal offers role-based access control for administrators and operators. Administrators can make changes; however, operators can only view the portal.
Customer Portal, a GUI that your customers use to manage sites, CPE devices, and network services for their organizations.
Customer Portal offers role-based access control for administrators and operators. Administrators can make changes; however, operators can only view the portal.
Designer Tools:
Configuration Designer, which you use to create configuration templates for virtualized network functions (VNFs). When you publish a configuration template, it is available for use in Resource Designer.
Resource Designer, which you use to create VNF packages. A VNF package consists of a configuration template and specifications for resources. You use configuration templates that you create with Configuration Designer to design VNF packages. When you publish a VNF package, it is available for use in Network Service Designer.
Network Service Designer, which you use to create a network service package. The package offers a specified performance and provides one or more specific network functions, such as a firewall or NAT, through one or more specific VNFs.
Service and Infrastructure Monitor, which works with Icinga, an open source enterprise monitoring system to provide real-time data about the Cloud CPE solution, such as the status of virtualized network functions (VNFs), virtual machines (VMs), and physical servers; information about physical servers’ resources; components of a network service (VNFs and VMs hosting a VNF); counters and other information for VNFs.
The Cloud CPE solution extends the NFV model through the support of physical network elements (PNEs). A PNE is a networking device in the deployment that you can configure through CSO, but not use in a service chain. Configuration of the PNE through CSO as opposed to other software, such as Contrail or Junos OS, simplifies provisioning of the physical device through automation. Combining provisioning and configuration for PNEs and VNFs provides end-to-end automation in network configuration workflows. An example of a PNE is the MX Series router that acts as an SDN gateway in a centralized deployment.
In the distributed deployment, VNFs reside on a CPE device located at a customer site. The NFX250 is a switch that hosts the vSRX application to enable routing and IPSec VPN access with the service provider’s POP. MX Series routers, configured as provider edge (PE) routers, provide managed Layer 1 and Layer 2 access and managed MPLS Layer 3 access to the POP. Network Service Controller provides the VIM, NFVI, and device management for the NFX250. Network Service Controller includes Network Activator, which enables remote activation of the NFX Series device when the site administrator connects the device and switches it on.
Figure 1 illustrates how the components in the Cloud CPE solution interact and how they comply with the ETSI NFV MANO model.
OSS/BSS applications and Contrail Service Orchestration (CSO) components with OSS/BSS capabilities send requests to Network Service Orchestrator through its northbound REST API. Network Service Orchestrator then communicates through its southbound API to the northbound API of the appropriate, directly connected, component. Subsequently, each component in the deployment communicates through its southbound API to the northbound API of the next component in the hierarchy. Components send responses in the reverse direction.
The following process describes the interactions of the components when a customer requests the activation of a network service:
- Customers send requests for activations of network services through Customer Portal or OSS/BSS applications.
- Service and Infrastructure Monitor is continuously tracking the software components, hardware components, and processes in the network.
- Network Service Orchestrator receives requests through
its northbound RESTful API and:
For the centralized deployment:
Accesses information about the network service and associated VNFs from their respective catalogs, and communicates this information to the VIM, which is provided by Contrail OpenStack.
Sends information about the VNF to VNF Manager.
For the distributed deployment, accesses information about the network service and associated VNFs from their respective catalogs, and communicates this information to the Network Service Controller.
- The VIM receives information from Network Service Orchestrator and:
For the centralized deployment:
The VIM creates the service chains and associated VMs in the NFVI, which is provided by the servers and Ubuntu. Contrail OpenStack creates one VM for each VNF in the service chain.
VNF Manager starts managing the VNF instances while the element management system (EMS) performs element management for the VNFs.
For the distributed deployment, Network Service Controller creates the service chains and associated VMs in the NFVI, which is provided by the CPE device.
- The network service is activated for the customer.
The PNE fits into the NFV model in a similar, though not identical, way to the VNFs.
For the centralized deployment:
Network Service Orchestrator receives the request through its northbound RESTful API and sends information about the PNE to PNE/VNF Manager.
PNE/VNF Manager receives information from Network Service Orchestrator and sends information about the PNE to the EMS.
VNF Manager starts managing the VNF instances and the EMS starts element management for the VNFs.
The PNE becomes operational.
For the distributed deployment:
Network Service Orchestrator receives the request through its northbound RESTful API.
Network Service Controller receives information from Network Service Orchestrator and starts managing the PNE.
The PNE becomes operational.