Contents
Abstract
The Technical Product Description describes the architecture, functions, configurations, interfaces, operation, and maintenance of the Ericsson Virtual Service-Aware Policy Controller (Virtual SAPC) 1.
The Virtual SAPC is the Telco Cloud ready version of the Ericsson SAPC. The Virtual SAPC is an already proven component in the Ericsson Virtual Evolved Packet Core (Virtual EPC) solution.
1 Introduction
1.1 Document Purpose and Scope
The Technical Product Description document aims to provide a technical and functional description of the Ericsson Virtual Service-Aware Policy Controller (Virtual SAPC) 1. The Virtual SAPC provides the same functions as the physical SAPC, but architectured for being deployed as a Virtualized Network Function (VNF) on a Network Function Virtualization Infrastructure (NFVI) .
This document includes description of the following areas:
- The cloud environment, surrounding the Virtual SAPC.
- The Virtual SAPC architecture.
- The Virtual SAPC management and orchestration.
- Characteristics and dimensioning.
- Requirements on the cloud system the Virtual SAPC imposes.
This document does not provide a description on the common functions shared by the SAPC and the Virtual SAPC. For such information, see Reference [1].
1.2 Revision Information
| A | This is the first release of this document. | |
| B | The document is updated with the content included in Virtual SAPC 1.1. | |
| C | The document is updated with the content included in Virtual SAPC 1.2. | |
| D | The document is updated with the content included in Virtual SAPC 1.3. | |
2 NFV Environment
The Virtual SAPC virtualization architecture allows the deployment of the Virtual SAPC in a NFV system. Therefore the Virtual SAPC becomes a VNF, which requires virtual resources (vCPU, memory, vNICs, storage) to a cloud infrastructure. The setup of the needed virtual resources is then managed through a Cloud Orchestration System and a NFVI. The NFVI is the responsible of assigning the virtual resources (vCPU, memory, etc.) the Virtual SAPC requires for its operation
This section describes supported NFV environments for Virtual SAPC deployment.
2.1 NFVI
2.1.1 Ericsson Cloud Execution Environment (CEE)
The Virtual SAPC can be deployed on Ericsson CEE. Ericsson CEE provides a carrier grade NFVI cloud infrastructure and a Virtualized Infrastructure Manager (VIM). The CEE is based on OpenStack components and the Kernel-based Virtual Machine (KVM) hypervisor. The CEE supports Ericsson or third-party Commercial Off-The-Self (COTS) HW for compute, storage, and networking.
For further information, see Reference [7].
2.1.2 VMware
The Virtual SAPC SW is delivered for being deployed on VMware vSphere 5.5, 6.0 or 6.5 NFVI. The VMware components required to deploy the Virtual SAPC are vCenter or vCloud Director.
The Virtual SAPC is a VMware NFV 2.0 Certified application.
2.1.3 Red Hat OpenStack
The Virtual SAPC SW can be deployed on Red Hat OpenStack.
The Virtual SAPC is a Red Hat OpenStack 10 Certified application.
2.1.4 Other OpenStack based NFVI
System integration with a third-party NFVI cloud infrastructure based on OpenStack is possible. The Virtual SAPC has no explicit direct interface toward the cloud infrastructure. However, the Virtual SAPC has dependencies to the following:
- The Virtual Machine (VM) environment exposed by the hypervisor (KVM).
- The infrastructure networking solution.
- The performance, characteristics, and robustness of the infrastructure.
The Virtual SAPC has been already verified with the OpenStack based HPE Helion.
For requirements on the cloud infrastructure, see Section Section 6.2.
2.2 NFV Management and Orchestration System
2.2.1 Ericsson Cloud Manager (ECM)
ECM provides management and orchestration of virtual resources across multiple VIMs, and G-VNFM functionality for generic life cycle management of VNFs. ECM supports VNF descriptors in Open Virtualization Format (OVF) and Heat Orchestration Template (HOT).
Because of the Virtual SAPC supports OVF and HOT, ECM can be used for its management and orchestration.
For further information on ECM, see Reference [8].
2.2.2 Third-Party Cloud Management System
System integration with a third-party cloud management system is possible.
The Virtual SAPC has no direct interface toward the cloud management system. However, the Virtual SAPC has dependencies to the following:
- The VM image and the VNF Descriptor supported by the cloud management system. For instance, the provided OVF package may be translated, if needed, to a different one (e.g. TOSCA).
- Procedures for lifecycle management: The Virtual SAPC is pre-integrated with Ericsson OSS-RC and Ericsson Network Manager (ENM). A third-party VNF Manager (VNFM) would require system integration.
- The policy requirements for the Virtual SAPC deployment: For instance, the Virtual SAPC requires anti-affinity rules (see Section 3.3.2).
For requirements on the cloud management system, see Section 6.1.
2.3 VNF Manager
The Virtual SAPC has the same northbound interfaces as the physical SAPC. Therefore Either OSS-RC or ENM may be used as the Element Manager (EM) for both the physical and the Virtual SAPC.
OSS-RC and ENM also provide S-VNFM functionality for specific life cycle management of Ericsson VNFs, including the Virtual SAPC.
3 Virtual SAPC Architecture
3.1 Virtualization Architecture
The Virtual SAPC virtualization architecture consists of several VMs taking different function roles.
- System Controllers (SC) VMs: 2 VMs implementing system controllers function. These VMs provide the north-bound access to the Virtual SAPC and the cluster membership and control.
- Traffic Processors (TP) VMs: “n” (at least
2, maximum 34) VMs for providing the Policy Server implementation.
This VMs are also referred as Payload (PL) VMs.
Both the 2 SC VMs and the TP VMs configure the Virtual SAPC cluster. However, the SW delivery includes an additional and optional type of VM:
- Virtual Router (VR): 4 VMs providing the Virtual Routing Service (based on Vyatta VR). These VMs are optional. 2 of the VR VM are responsible for Operation and Maintenance (OAM) tasks, and the other 2 for addressing the control plane traffic the Virtual SAPC manages.
Figure 1 displays the described the Virtual SAPC virtualization architecture.
3.2 Deployment Types
The Virtual SAPC provides validated deployment types. The validated deployment types specify VM sizes, number of VMs, and distribution of VMs over the available compute hosts of the Virtual SAPC.
- Multi-host Virtual SAPC: This deployment targets scalability and high capacity, with full SW and HW redundancy.
- Single-host Virtual SAPC This deployment targets small footprint with limited capacity. The deployment has small VM sizes, all collocated on one compute host . It supports full SW redundancy including VM redundancy. The deployment does not support HW redundancy. However, network level redundancy can be achieved through a pair of the Virtual SAPC instances configured as 1+1 IP Geographical Redundant.
- Note:
- The VM sizes and numbers in Table 1 and Table 2 have been validated. However, other VM sizes and numbers can be used, depending on the dimensioning needs.
|
VM Role |
Number of VMs |
vCPU |
RAM Memory (GB) |
Hard Disk (GB) |
|
2 |
2 |
6 |
40 | |
|
2-34 |
2 |
10 |
0 | |
|
VR (optional) |
4 |
2 |
1 |
4 |
|
VM Role |
Number of VMs |
vCPU |
RAM Memory (GB) |
Hard Disk (GB) |
|
2 |
4 |
6 |
60 | |
|
2-34 |
16 |
20 |
0 | |
|
VR (optional) |
4 |
2 |
1 |
4 |
The Virtual SAPC is also part of Ericsson Virtual EPC offerings. Virtual EPC deployments are not described in this document.
3.3 Resilience and Redundancy
All the Virtual SAPC software components are supervised by the Virtual SAPC middleware. Recovery actions for SW components are triggered by the Virtual SAPC middleware when needed. Supervision and redundancy handling does not depend on specific HW failure notifications from the virtualization and infrastructure layers. This means that mechanisms such as session resilience work the same way as they do in the SAPC Physical Node Function (PNF).
3.3.1 VM Redundancy
The VM redundancy models are as follows:
|
VM Role |
Redundancy Model |
|
1+1 active-standby | |
|
1+1 active-active | |
|
1+1 active standby | |
|
VR Traffic (optional) |
1+1 active standby |
3.3.2 Anti-affinity rules
High availability implementation requires the definition of anti-affinity rules. These rules must be considered for any Multi-host Virtual SAPC deployment (as it was defined in Section 3.2).
- The 2 SC must not be collocated in the same physical host.
- Each TP must be collocated in a different physical host.
- The 2 optional VR for OAM must not be collocated in the same physical host.
- The 2 optional VR for Traffic must not be collocated in the same physical host.
In case the anti-affinity rules are not implemented, the consequences are the following:
- The Virtual SAPC reboots in case of physical host failure: This happens if either the 2 SC are down for more than 15 minutes, or at least 2 TP VM are collocated in the failing physical host.
- If the optional VR VM are used: Lack of external connectivity towards the Virtual SAPC because of either the 2 VR for OAM, or the 2 VR for Traffic are in the failing physical host.
3.3.3 Physical Link Redundancy
The Virtual SAPC is not aware of the cloud network topology. Therefore, it does not perform failover between two virtual NICs (vNICs) on the same VM. It is the responsibility of the cloud infrastructure to provide physical link redundancy.
3.3.4 Storage Redundancy
The Virtual SAPC has redundant storage on the SC VMs.
3.4 Networking
3.4.1 Internal networking
The detailed description of the Virtual SAPC internal networking is available in the SAPC VNF Network Configuration Guide (Reference [6]).
3.4.2 External networking
The detailed description of the Virtual SAPC external networking is available in the SAPC VNF Network Configuration Guide (Reference [6]).
3.4.3 Characteristics per Virtual Network
The following table specifies the purpose and characteristics of the different Virtual Networks (VN) used by the Virtual SAPC.
|
Internal VNs |
External Traffic VNs | ||
|
Purpose of VNs |
The Virtual SAPC VM-to-VM. |
OAM. |
The Virtual SAPC external traffic. |
|
No. |
No. |
No. | |
|
Externally connected to networks outside the cloud |
No. |
Yes. |
Yes. |
|
vNIC IP address assignment |
SC VM will do IP address assignments using the internal DHCP. |
Configured through cloud injected file in the Virtual SAPC. |
Configured through cloud injected file in the Virtual SAPC. |
|
Supported IP versions |
IPv4. |
IPv4. IPv6. |
IPv4. IPv6. |
|
IP MTU size |
Manually configured Default: 1500 bytes. |
Manually configured Default: 1500 bytes. |
Manually configured Default: 1500 bytes. |
|
IP routing |
Handled internally by the Virtual SAPC. |
Through static routes via the Virtual SAPC High Availability Front Ends (recommended). |
Through static routes via the Virtual SAPC High Availability Front Ends (recommended). |
|
vNIC MAC address assignment |
Dynamic MAC address assignment by the NFVI. |
Dynamic MAC address assignment by the NFVI. |
Dynamic MAC address assignment by the NFVI. |
|
Support for application VLAN tagging (trunk vNIC) |
No. |
Not provided by default. |
Not provided by default. |
3.5 Storage
The Virtual SAPC storage is on the SC VM root disk, thus the VM disk image, which is used to boot the VM. The storage includes SW data, configuration data, backup information, log files and performance monitoring files.
The optional VR VMs also includes storage. The storage includes just the Vyatta VR SW image.
The TP VMs use only the local VM disk image for booting. They do not write to the local disk, but manage their data (both provisioning and dynamic) in memory.
If the Virtual SAPC is deployed in VMware NFVI, it is possible to configure the Small Computer System Interface (SCSI) controller type to either Paravirtual or LSI Logic.
The Virtual SAPC storage capacity can be modified at deployment time, but cannot be changed during operation. For information about storage requirements on the cloud infrastructure, see Section 6.2.
The cloud infrastructure is responsible for implementing the storage back end, which is transparent to the Virtual SAPC.
3.6 Security
The Virtual SAPC is delivered with default hardening. For more information about hardening and security of the Virtual SAPC, see Reference [2].
The port security can be enabled or disable at the HOT VNF-D, when the Virtual SAPC is going to be deployed in an OpenStack NFVI based on IPv4 networks.
The security of the Virtual SAPC strongly depends on the underlying security of the cloud infrastructure.
4 Management and Orchestration
The main OAM functions (Configuration Management, Data Provisioning, Fault Management, Performance Management, log management, backup & restore, troubleshooting and upgrade) are the same ones in the SAPC PNF and in the Virtual SAPC. However, there are some differences in other OAM functions. They are described in the following sections.
4.1 Onboarding and Instantiation
There are two methods to deploy the Virtual SAPC.
- An OVF package is created using a tool (script) and the Virtual SAPC SW images from the delivered SW. The OVF package is then deployed in the cloud manager. Different OVF packages are provided for ECM or VMware vCloud Director/vSphere/vCenter.
- OpenStack Orchestration (Heat): A HOT is created using a tool (script) and the Virtual SAPC SW images from the delivered SW. The Virtual SAPC SW images are uploaded to OpenStack (Glance), and the HOT is then applied in OpenStack.
The Virtual SAPC provides HOT and vCloud Director VNF Lifecycle Manager (VNF-LCM) workflows, and ECM driven (direct-mode or Or-Vnfm) workflows for VNF onboarding and instantiation.
When the cloud system boots the VMs, the Virtual SAPC automatically starts to run on the SW that is pre-installed on the SW images.
Configuration information can be injected into the VNF at deployment time by cloud injection.
Detailed information is available in Reference [3] and Reference [4].
4.2 HW Management
The Virtual SAPC is a NFV-ready SW, so it has no direct coupling to the physical HW it is deployed on. Therefore the Virtual SAPC cannot provide any status, alarms, or counters related to the physical HW. The cloud infrastructure needs to provide this information for the operator.
However, the VMs in the Virtual SAPC are considered as equipment. So the VMs can be monitored and can for example, be restarted, locked, and unlocked.
4.3 Scaling
The Virtual SAPC can be scaled-out or scaling-in dynamically due to application capacity needs. The scaling out consists of adding additional TP VMs to the Virtual SAPC. The scaling-in means to remove TP VMs from the Virtual SAPC. The maximum and minimum sizes for scaling-out/in is indicated in Section 3.1.
After scaling-out or scaling-in, the traffic is automatically rebalanced across all the TP VMs in seconds.
The Virtual SAPC provides HOT and vCloud Director VNF-LCM workflows for manual and automatic scaling-out, and administrative scaling-in.
Scaling-up (increasing dynamically the VM size) and scaling-down (decreasing dynamically the VM size) is not supported.
4.4 Auto-healing
The auto-healing function restores the full capacity and redundancy of the Virtual SAPC within minutes. However, the management and minimization of the traffic impact of a failure is handled independently of auto-healing by the Virtual SAPC resilience mechanisms described in Section 3.3.
The Virtual SAPC automatically recovers from failures in the application and its guest OS by internal recovery mechanisms. The Virtual SAPC on CEE also supports the KVM watchdog device, which reboots a VM if the guest OS hangs. The Virtual SAPC on VMware supports with the same aim the vSphere High Availability (HA).
Auto-hailing for Failures on cloud infrastructure level must be orchestrated outside the VNF.
The Virtual SAPC auto-healing function can be orchestrated by one of the cloud management functions listed below:
- VIM on Ericsson CEE: The Continuous Monitoring High Availability (CM-HA) feature is supported.
- VIM on VMware vSphere: the vSphere HA feature is supported.
- VNFM: The S-VNFM can be instructed to react on VM alarms from the Virtual SAPC, and recover a VM by sending requests to the Cloud Management System. This can be achieved by System Integration activities.
Ericsson recommends auto-healing orchestrated by the VIM, when available.
4.5 Live migration
The live migration is a NFV procedure whose target is to enable the movement of a VM instance from a compute host to a different one. It is usually applied when a compute host requires maintenance, and the VNF is requested to maintain its service operation conditions.
This procedure implies the memory, the storage, and the network connectivity of the VM instance are transferred from the original compute host to the destination compute host, and with almost no VM instance downtime.
The Virtual SAPC provides live migration support for VMware NFVI deployments by using vSphere vMotion.
4.6 Decommissioning
The Virtual SAPC can be easily decommissioned from operation in just seconds. This is done via VNF de-instantiation through the cloud management system.
The Virtual SAPC provides HOT and vCloud Director VNF-LCM workflows, and ECM driven (direct-mode or Or-Vnfm) workflows, for decommissioning
4.7 VMware Tools
The Virtual SAPC includes Open VM Tools (OVT) in the guest OS. OVT is an open source implementation of VMware Tools. It consists of virtualization utilities that improve the functionality and management of VMs within a VMware environment.
Table 5 describes how the Virtual SAPC supports OVT.
|
OVT Feature |
Support in the Virtual SAPC |
|
Synchronize the guest OS clock with the virtual infrastructure |
Disabled. SAPC synchronizes the clock with an external NTP server |
|
Enable the virtual infrastructure to perform graceful shutdown of the VM |
Enabled |
|
Enable the virtual infrastructure to quiesce the file system of the VM before taking a VM snapshot |
Disabled |
|
Provide a heartbeat from the guest to the virtual infrastructure to support vSphere High Availability |
Enabled |
|
Publish information about the guest OS to the virtual infrastructure, including resource use and networking information |
Enabled |
|
Provide a secure and authenticated mechanism to perform various operations within the guest OS from the virtual infrastructure |
Disabled. The Virtual SAPC OAM interfaces provide accountability logging and enforcement of role-based access rights on VNF level, and must therefore be used |
|
Customize the guest OS when deploying a new VM |
Disabled |
|
Improve the interaction with the guest desktop environment |
Disabled. The Virtual SAPC does not provide a desktop environment |
5 Characteristics and Dimensioning
Ericsson has a set of tools for capacity planning, including dimensioning guidelines and a dimensioning calculation tool. The tools are available for Ericsson personnel who can assist the customer with capacity planning scenarios. Inputs for the dimensioning are cloud system and HW characteristics, control plane and user plane traffic models, and the used the Virtual SAPC feature set.
The dimensioning calculation tool has reference models of the cloud system and hardware. Deviations from the reference model and the cloud system requirements can have an impact on the Virtual SAPC characteristics and lead to degraded performance. The requirements are described in Section 6. Each deviation compared to the stated requirements can require more HW resources than the reference model indicates, or can require system integration work to fill any performance gaps.
For more information about characteristics and dimensioning, see Reference [5].
6 Requirements on the Cloud System
This section describes the requirements on the cloud system components.
Deviations from the requirements can have an impact on the Virtual SAPC characteristics and can risk both performance and robustness. Deviation from the requirements can require system integration to fill any design gaps.
6.1 Cloud Management System Requirements
The Virtual SAPC has the following requirements on the cloud management system:
- Support VM anti-affinity policies or a solution to control the VM placement on the physical compute hosts.
- Optionally support OpenStack configuration drive using ISO 9660 file system for injection of configuration data.
- Only cloud management system users with appropriate authority should have access to the Virtual SAPC and its virtual resources.
6.2 Cloud Infrastructure Requirements
6.2.1 Compute
- Cloud service model: IaaS.
- Deployment unit: VM.
- Hypervisors: KVM or VMware ESXi 6.0/6.5.
- The cloud infrastructure must not overcommit CPU, memory, or disk resources.
For optimal performance of the Virtual SAPC, the recommendation is to enable the hyper-threading.
6.2.2 Networking
- VM vNIC Ethernet adapter types: ◦KVM: VirtIO; VMware ESXi: vmxnet3.
- Minimum number of vNICs per VM: 3 per VR VM (optional); 3 per TP VM; 3 for SC1 VM and 3 for SC2 VM.
- Number of vNICs for the smallest the Virtual SAPC cluster configuration: 12 (24 with VR VM).
- L2 virtual networks must be supported.
- The cloud infrastructure must provide physical Ethernet link redundancy for each vNIC.
- Recommended maximum link failover time in the cloud infrastructure: 0.5 seconds.
6.2.3 Storage
- VM virtual disk controller: KVM: VirtIO; VMware ESXi: SCSI (LSI Logic or paravirtual).
- If centralized storage is used, it must provide High Availability in all aspects including the SAN network.
- If local storage is used, see Section 6.3 for detailed storage requirements.
6.3 Compute Host HW Requirement
This section specifies the compute host HW requirements for the Virtual SAPC.
- CPU architecture: x86_64.
- Minimum number of logical CPUs (hyper-threads) for VM use: 2.
- Minimum amount of RAM for VM use: 1 GB per VR VM (optional VM), 6 GB per SC VM, 10 GB per TP VM.
- Minimum disk space for VM use: 4 GB per VR VM (optional VM), 40 GB per SC VM, 0 GB per TP VM.
One the Virtual SAPC instance must be deployed on compute hosts within the same site. All the compute hosts should be connected to the same switch, or at least with minimal number of network hops between the compute hosts.
6.4 Additional considerations
Being a control plane application, the Virtual SAPC is not a performance critical telecommunications application. Then it does not require Single Root Input/Output Virtualization (SR-IOV), Data Plane Development Kit (DPDK) or similar utilities.
The Virtual SAPC is not Non-Uniform Memory Access (NUMA) aware. Therefore it is not recommended to define VMs whose size may imply the VM is deployed in more than one NUMA cell.
Glossary
| CEE |
| Cloud Execution Environment |
| COTS |
| Commercial Off-The-Self |
| DHCP |
| Dynamic Host Configuration Protocol |
| DPDK |
| Data Plane Development Kit |
| ECM |
| Ericsson Cloud Manager |
| EM |
| Element Manager |
| ENM |
| Ericsson Network Manager |
| EPC |
| Evolved Packet Core |
| G-VNFM |
| Generic VNFM |
| HOT |
| Heat Orchestration Template |
| HW |
| Hardware |
| IP |
| Internet Protocol |
| KVM |
| Kernel-based Virtual Machine |
| MAC |
| Media Access Control |
| MTU |
| Maximum Transmission Unit |
| NFV |
| Network Functions Virtualization |
| NFVI |
| NFV Infrastructure |
| NIC |
| Network Interface Card |
| NUMA |
| Non-Uniform Memory Access |
| OAM |
| Operation and Maintenance |
| OSS |
| Operations Support Systems |
| OVF |
| Open Virtualization Format |
| OVT |
| Open VM Tools |
| PL |
| Payload |
| PNF |
| Physical Node Function |
| SC |
| System Controller |
| SCSI |
| Small Computer System Interface |
| SR-IOV |
| Single Root Input/Output Virtualization |
| S-VNFM |
| Specific VNFM |
| SW |
| Software |
| TP |
| Traffic Processor |
| vCPU |
| Virtual Central Processing Unit |
| VIM |
| Virtualized Infrastructure Manager |
| Virtual SAPC |
| Ericsson Virtual Service-Aware Policy Controller |
| VLAN |
| Virtual Local Area Network |
| VM |
| Virtual Machine |
| VN |
| Virtual Networks |
| VNF |
| Virtualized Network Function |
| VNF-LCM |
| (VNF Lifecycle Manager) |
| VNFM |
| VNF Manager |
| vNIC |
| Virtual Network Interface Card |
| VR |
| Virtual Router |
Reference List
| Ericsson Documents |
|---|
| [1] Technical Product Description: Service-Aware Policy Controller 1, 1/221 02-FGC 101 3390/1 Uen |
| [2] Security Management Guide, Service-Aware Policy Controller, 29/1553-AXB 901 33/7 Uen |
| [3] SAPC VNF Deployment Instruction for OpenStack, 3/1531-AXB 901 33/7 Uen |
| [4] SAPC VNF Deployment Instruction for VMware, 4/1531-AXB 901 33/7 Uen |
| [5] SAPC 1 Network Impact Report, 109 48-FGC 101 3390/1 Uen |
| [6] SAPC VNF Network Configuration Guide, 20/1553-AXB 901 33/7 Uen |
| [7] CEE Technical Description, 221 02-FGC 101 3270 Uen |
| [8] Product Overview. Ericsson Cloud Manager, 1/1550-CSH 109 232 Uen |