The UEM manages all of the major components of the USP architecture. Conforming to ETSI MANO, the UEM is modeled as the element management system (EMS) for the USP which is a complex VNF comprised of multiple VNFCs. The UEM and the complex VNF are represented to the Management and Orchestration (MANO) infrastructure through their own VNF descriptors (VNFDs).

Figure 3. Ultra Element Manager Composition

Although comprised of multiple modules, the UEM provides a single northbound interface (NBI) to external elements such as the OSS/BSS and Ultra Web Service (UWS).

The UEM provides the following network management functions:

• Configuration

• Fault management

• Usage accounting

• Performance measurement

• Security management

• Operational state of VNF

The northbound interface exposes all the information collected, aggregated and exposed through an API interface. All the interactions with entities northbound of the UEM happen via a single programmable API interface (e.g. REST, NETCONF, SNMP, etc.) for the purpose of collecting:

• Configuration data for platform services and for Day-N configuration of its various components

• Operational data pertaining to the system such as topology (VDU creation and organization) and different levels of VDU and service liveliness and KPIs based on the topology

• Event streams (NETCONF notifications) that used by the UEM to asynchronously notify northbound entities

• Remote Procedure Calls (RPCs) used to expose some of the functionalities offered by the platform or its components such as packet tracing or mirroring

• Asynchronous notifications:When an event that is relevant to northbound, is received from southbound, the SCM relays the event via a Netconf notification

These functions are provided via several different modules that comprise the UEM:

• Lifecycle Manager (LCM): The LCM exposes a single and common interface to the VNFM (Ve-Vnfm) that is used for performing life-cycle management procedures on a VNF. As a component within the UEM, it supports the various middleware application programming interfaces (APIs) required to interact with VNF and its components. Refer toLife Cycle Managerfor more information.

• Service Configuration Manager (SCM): Leverages a YANG-based information model for configuration to provide configuration information to the VNFC Control Function (CF) VMs and other third-party components. It performs this functionality via NETCONF interfaces using pre-configured templates/network element drivers (NEDs). Configuration information is stored in the configuration database (CDB) and passed to the CF VM over the configuration interface via ConfD.

• Service Level Agreement Manager (SLA-M): Provides timely access to information such as key performance indicators (KPIs), serviceability events, and diagnostic and troubleshooting information pertaining to components within the USP VNF instance such as:

  • The Lifecycle Manager

  • The Control Function (CF)

  • VMs that are part of the VNFCs

  • Any third-party applications related to USF service chains (depending on the VNFC)

  The SLA-M passes the information it collects over the northbound interface of the UEM.

• USP Control Function (CF): Based on the StarOSTM, the CF is a central sub-system of the VNF that interacts with other sub-systems like service functions (SFs), network functions (NFs), and Application Functions (AFs) using field-tested software tasks that provide robust operation, scalability, and availability. It is equipped with a corresponding CDB for storing configuration information provided by the SCM via ConfD and/or CLI over the management interface.

High-availability (HA) is ensured across all of these components by the UEM-HA framework via a light-weight protocol that monitors the CF and SLA-M over the High-availability interface. All components are deployed redundantly. In the event of an issue, functions will be switched-over to the standby host. The SLA-M also uses the NETCONF interface to pull KPIs and event/log information from the CF.

The Control Function (CF) is a StarOSTM-based central sub-system of the VNF. It interacts with other sub-systems such as service functions (SFs), network functions (NFs), and Application Functions (AFs), and uses field-tested software tasks that provide robust operation, scalability, and availability. The VNFD and VNFR are equipped with a corresponding configuration database (CDB) for storing configuration information provided by the SCM via ConfD and/or CLI NEDs over the management interface.

The CF also communicates over the High-availability (HA) interface for communicating with the LCM and to provide KPIs and event logs to the SLA-M.

Two CF VMs act as an active:standby (1:1) redundant pair. Within the StarOS, each CF VM is viewed as a virtual card and is responsible for the following functions:

• Hosting Controller tasks

• Hosting the Local context VPNMGR

• Hosting Local context (MGMT) and DI-Network vNICs

• Managing System boot image and configuration storage on vHDD

• Facilitating record storage on vHDD

• Providing Out-of-Band (OOB) management (vSerial and vKVM) for CLI and logging

• Working with the LCM to:

  • Bring VDUs online or offline during system initialization, request more VDUs for scale-out, return VDUs for scale-in lifecycle operations using VPD

  • Facilitate VDU internal management and configuration using predefined artifacts

• Providing KPI, event, and log information to the SLA-M as requested/needed

Figure 4. Control Function VM

Note	The Intel Data Plane Development Kit (DPDK) Internal Forwarder task (IFTASK) is used to enhance VPC system performance. It is required for system operation. Upon CF instantiation, DPDK allocates a certain proportion of the CPU cores to IFTASK depending on the total number of CPU cores.

SF VMs provide service context (user I/O ports) and handle protocol signaling and session processing tasks. One UGP instance can contain up to 30 SF VMs.

Each SF VM dynamically takes on one of three roles as directed by the CF:

• Demux VM (flow assignments)

• Session VM (traffic handling)

• Standby VM (n+1 redundancy)

An SF is responsible for the following functions:

A minimum configuration for one UGP instance requires four SFs two active, one demux and one standby.

Figure 5. Service Function VM

Note	The Intel Data Plane Development Kit (DPDK) Internal Forwarder task (IFTASK) is used to enhance VPC system performance. It is required for system operation. Upon CF instantiation, DPDK allocates a certain proportion of the CPU cores to IFTASK depending on the total number of CPU cores.

When deployed in support of the Ultra Services Framework (USF), the SF facilitates the StarOS software tasks pertaining to the IP Services Gateway (IPSG) traffic detection function (TDF). The IPSG receives subscriber policy information from the Policy and Charging Rules Function (PCRF) over the Gx/Gx+ interface. It uses this policy information to steer subscriber session traffic received over the Gi/SGi interface through the SFC as required.

The Network Function (NF) is a virtual machine that is dedicated as a networking adapter between a DI system and external routers. The NF can be used to aggregate the VNF external connection points to a consolidated set of external interfaces. NF virtual machines are typically used for larger DI systems to limit the number of external interfaces to those present on a smaller set of virtual machines. The NF facilitates the building of large scale, high performance systems by providing the virtual equivalent of specialized Network Processing Unit (NPU) hardware.

The NF provides the following functions:

• Serves as a dedicated system for performing high speed traffic classification and flow/counter aggregation based on policies (n-tuple; each NF has access to complete set of policies)

• Limits the number of external interfaces required by aggregating external connection points to a consolidated set of high speed interfaces

• Operates as networking adapter between USP VNFs and external routers

• Subscriber awareness and stickiness as part of flow classification

• Traffic classification and load balancing

The NF deploys a FAST-PATH architecture leveraging the NPU Manager and NPU SIM software tasks to ensure performance and scalability.

Figure 6. Network Function VM

The mobility/DPDK internal forwarder (IF) is the core functional block for the USP architecture. It runs NPUSIM with DPDK into NF. The main functions of the mobility forwarder are:

• Performing the flow classification for each incoming packet, based on pre-configured rules

• Deriving the service chain that needs to be associated with a flow

• Maintaining the subscriber stickiness - Meaning all the flows of a subscriber should land on the same service path (service path maps to AF)

• Performing the NSH encapsulation/ decapsulation. It uses NSH for communicating the service chain information across the nodes.

The Application Function (AF) is a virtual machine that is dedicated for Ultra Service Framework within a Gi-LAN Service Function Chain. The CF manages the system initialization, resource management, and high availability of the AF virtual machines. Packets that will be routed through a service function are encapsulated by the NF using NSH chain and routed to the AF. The AF learns of the specific service chain from the NSH header and routes the un-encapsulated packets through the Ultra Service Components (USCs) that comprise the chain. Once the packets are serviced, they’re re-encapsulated and routed back to the NF.

Figure 7. Application Function Network

The AF VM maps the service chain identifier to a local tag representing the link/path between the NF and service component. The service path consists of a single service function, chain of different service functions, or service path spawned over multiple hosts. Like the NF, the AF deploys a FAST-PATH architecture leveraging the NPU (network processing unit) Manager and NPU SIM software tasks to ensure performance and scalability.

Figure 8. Application Function VM

Services within the USP are supported through various VNF Components (VNFC)s. Each VNFC consists of multiple virtual machines (VMs) of different types. The following VNFCs are available:

• Ultra Gateway Platform (UGP): The UGP provides virtualized instances of the various 3G and 4G mobile packet core (MPC) gateways that enable mobile operators to offer enhanced mobile data services to their subscribers. The UGP addresses the scaling and redundancy limitations of VPC-SI (Single Instance) by extending the StarOS boundaries beyond a single VM. UGP allows multiple VMs to act as a single StarOS instance with shared interfaces, shared service addresses, load balancing, redundancy, and a single point of management.

• Ultra Policy Platform (UPP): Delivers next generation policy and subscriber management functionality by leveraging the Cisco Policy Suite (CPS). CPS is carrier-grade policy, charging, and subscriber data management solution. It helps service providers rapidly create and bring services to market, deliver a positive user experience, and optimize network resources.

  Note: UPP is not supported in this release.

• Ultra Service Framework (USF): The USF enables enhanced processing through traffic steering capabilities for subscriber inline services. USF Gi-LAN Service Function Chains (SFC) classify and steer traffic enabling mobile operators to quickly and deploy new services and applications to their subscribers.

The USP VNF relies on the underlying hardware and hypervisor for overall system redundancy and availability.

The hardware and hypervisor should provide:

• Redundant hardware components where practical (such as power supplies and storage drives)

• Redundant network paths (dual fabric/NICs, with automatic failover)

• Redundant network uplinks (switches, routers, etc.)

High availability can be achieved only if the underlying infrastructure (hosts, hypervisor, and network) can provide availability and reliability that exceeds expected values. The USP VNF is only as reliable as the environment on which it runs.

Inter-Chassis Session Recovery (ICSR) is also recommended to improve availability and recovery time in the case of a non-redundant hardware failure (such as CPU, memory, motherboard, hypervisor software). ICSR provides redundancy at the session level for gateways only. See ICSR Support for more information.

By default, three UEM VMs are deployed as part of a HA cluster which are 1:n redundant for overall management and inter-VNFM communications. The three VMs are deployed as follows: 1 leader or master (active), 1 follower or slave (standby), and 1 follower (standby).

The UEM framework leverages Apache ZooKeeper™ to form the HA cluster. When the HA cluster is formed, the UEM VM with the lowest IP address becomes the master. UEM processes run on the master and on the follower/slave VM.

The UEM VMs can be deployed on same host as the OpenStack Controllers or on the servers hosting other VNF management components.

By default, the UEM deploys two CF VMs which are 1:1 redundant for control of the USP VNF and the local context/management port. This is the recommended configuration.

The management port vNIC on both CFs are 1:1 redundant for each other and must be placed in the same VLAN in the infrastructure. Only one management port is active at a time.

Note	The two CF VMs must not run on the same physical host (server or blade) to achieve redundancy in case of the failure of the host or hypervisor.

SFs are deployed using 1:N redundancy. It is recommended that you have at least 2 active and 1 standby SF, however, the number of SF instances will change according to your deployment requirements.

Each SF VM provides network connectivity for service ports. Each SF provides one or more ports and associated interfaces, but the SFs do not provide 1:1 port redundancy as they are not paired together. Redundancy of SF ports should be achieved using ECMP or another supported L3 protocol.

The total throughput required of the USP VNF Instance should not exceed N-2 SFs with session recovery enabled so that any single SF can fail while the others take over its load. Use of loopback interfaces for service IP addresses is highly recommended.

Cisco recommends that you use Bidirectional Forwarding Detection (BFD) and Link Aggregation Group (LAG) for detection of path failures between an SF and the peer router so ECMP paths are excluded in the event of a failure.

1:1 session redundancy within a VNF and Interchassis Session Recovery (ICSR) between VNFs is supported. Note that the session state is check-pointed at various call points within a call flow. Although session state is check-pointed in the UGP, the IP flow state and connection tracking tables are not mirrored. Therefore, any state associated with an IP flow will be lost.

When session recovery is enabled, one VM becomes the VPN/Demux and the remainder are session processing VMs. A standby SF can provide redundancy for any other SF.

Note	Each NF VM must run on a different physical host to achieve redundancy in case of the failure of the host or hypervisor.

NFs are deployed using 1:N redundancy. You may adjust the number of NF instances according to your deployment requirements.

Note	Each NF VM must run on a different physical host to achieve redundancy in case of the failure of the host or hypervisor.

AFs are deployed using 1:N redundancy. You may adjust the number of AF instances according to your deployment requirements.

Note	Each AF VM must run on a different physical host to achieve redundancy in case of the failure of the host or hypervisor.

The Ultra Services Components (USCs) used in the USF are deployed along with the AF into a MANO construct called an Element Group (EG). An EG is is set of VDUs arranged for a unit of redundancy. As such, redundancy is available at the EGs-level and not for the individual USCs. An N:1 redundancy model is supported for Element groups.

USP VNFs support Inter-Chassis Session Recovery (ICSR) between two VNF instances for services that support Layer 3 ICSR in the StarOS software release. When more than one service type is in use, only those services that support ICSR will be able to use ICSR.

ICSR supports redundancy for Site/row/rack/host outages, and major software faults. To do so, the two USP VNF instances should be run on non-overlapping hosts and network interconnects. ICSR is supported only between like-configured UGP instances.

Note	ICSR between a USP VNF instance and another type of platform (such as an ASR 5500) is not supported.

For additional information, refer to the Inter-Chassis Session Recovery chapter in the UGPSystem Administration Guide.