Service providers can automate the creation of cloud based business services by using YANG-based service models in the orchestration engine software modules, and service function chaining of the required virtual network functions (VNFs) to enable those services.
As MSX evolves the architecture continues to modularize components, creating a clear demarcation points between various layers in the solution allowing maximum flexibility in both commercial and deployment models.
■Service Interface (SI)—Customer Facing Level
The Service Interface consists of two modules, a customer facing Front-End and service intent to service request processing Back-End.
The SI Front-End is the Self-Service User Interface; from here the end-customer can select the Service Package that meets their VNF requirements. At that point, the end-customer can construct MSX services consistent with the Service Package, in this example, the Advance Service Package is selected.
The SI Back-End is separate module that constructs the service request based on the service intent that is determined by the end-customer choices in the From-End module.
■MSX Platform—Resource Facing Level
The MSX Platform mirrors the ETSI MANO Standard for a virtualization orchestration model. The NFV Manager or Network Service Orchestrator provisions services that is based on service packs that logically mirror CFS level Service Packages. Service packs are internal software modules that house the service models and Fastmap execution logic that define specific Service Packages. Based on these service models, the NSO uses the internal Fastmap code to provision the service components through the Elastic Service Controller (ESC).
The ESC is the VNF Lifecycle Manager, based in request from the NSO, this component will execute Create, Read, Update, and Destroy (CRUD) operations, resulting in the operation request to the Virtual Infrastructure Manager.
Architecture and ETSI Mano Standards
The ETSI NFV Management and Orchestration (MANO) standards define a method of orchestration whereby the components of orchestration of compartmentalized to specific functions. MSX Uses ETSI Mano Architecture for Orchestration shows the ETSI MANO model. The layers are broken into Orchestrator (NFVO), Life Cycle Management (VNF-M), and virtual interface management (VIM). The NFV orchestrator is responsible for understanding the overall service being instantiated. The life cycle management is for the management and monitoring of virtual network functions (VNFs). Finally, the VIM handles interconnecting physically and virtual network and compute infrastructure.
Figure 3 MSX Uses ETSI Mano Architecture for Orchestration
The Cisco Network Services Orchestrator (NSO) orchestration engine software modules handle the NFVO functions. The Elastic Services Controller (ESC) software modules are responsible for VNF life cycle management (VNF-M). OpenStack networking software plug-ins modules provide virtual infrastructure management (VIM) functionality.
Cisco Network Services Orchestrator
Cisco Network Services Orchestrator (NSO) is a model-driven orchestrator which uses YANG for modeling the services, and can use various methods such as NETCONF, SSH, REST, and APIs to provision the devices. NSO receives a service intent request through the open API interface presented northbound to the service interface (or customer OSS/BSS).
The Service Manager software subcomponent of NSO processes the service intent, corresponding to a particular service model. The purpose of the Service Manager is to analyze the service request, then interpret the request to a specific set of configuration asks. Similarly, the Device Manager is used to abstract out the infrastructure that is also based on a modeling language. A Mapping Controller is responsible for moving service models to device models. This is discussed in more detail in later sections.
A transaction database that is known as the “CDB” stores all elements related to configuration and devices. For all services intended to be instantiated, NSO has a Yang service definition model that is loaded into the transaction database to handle such a request.
Network Element Driver (NED) software modules are used to abstract out the different physical and network devices to which service configuration data may be pushed. As such the NED allows the service definition models to apply to equipment from different vendors.
NSO runs as a container in the MSX solution. The NSO container is deployed in one of the Kubernetes nodes and monitored by the Kubernetes master. Each Service pack has an NSO container.
Multi-NSO Orchestrator Support in MSX shows the individual service intent modules.
Figure 4 Multi-NSO Orchestrator Support in MSX
Cisco NSO as the Plug-and-Play Server
The Plug-and-Play (PnP) Server software element is used to handle and achieve zero touch deployment (ZTD) for CPEs coming online and wanting to utilize the services configured orchestration engine. In the MSX solution, NSO also functions as the PnP server. The site CPE deployments are supported in MSX by a PnP service, which is accessible as an NSO PnP Resource Facing Service (RFS) API. Once a CPE device is connected to the Internet, a “call home” protocol communicates with the NSO PnP RFS API via a secure PnP Configuration Manager that is located in the Service Provider MSX Cloud. The CPE device is fully configure using a four-step process:
■Day-(-1) —Initial config of CPE to find PnP Server
■Day-0 —Configuration of the device management interface
■Day-1 —System configuration, basic interface and system configuration
■Day-2 —Service configuration, service-specific configuration
Inclusion of the PnP service in the MSX Solution removes costly truck-rolls from the service deployment model, which are required to install and configure each CPE device. The removal of this activity greatly reduces the cost of service deployment, a cost that has long haunted traditional Managed Services.
The following illustration depicts the device registration process.
Figure 5 Registering a Device or CPE