1. Configuration Guide
  2. System Configuration
  3. Configuring The Oracle Communications Session Border Controller as a Virtual Machine (VM)

Configuring The Oracle Communications Session Border Controller as a Virtual Machine (VM)

Operating the Oracle Communications Session Border Controller as a VM introduces configuration requirements that define resource utilization by the virtual machine. The applicable configuration elements allow the user to optimize resource utilization based on the application's needs and VM resource sharing.

Oracle Communications Session Border Controller configuration for VM includes settings to address:

media-manager — Set media manager configuration elements to constrain bandwidth utilization, based on traffic type. See Media Manager Configuration for Virtual Machines in the Realms and Nested Realms Chapter.

system-config, [core configuration parameters] — Set these parameters to specify CPU resources available to DoS, forwarding and transcoding processes. This configuration applies to initial deployment and tuning tasks. You may need to change the default core configuration for functionality purposes during deployment; you may decide to change core configuration for performance purposes after deployment.

Note:

Early versions of this software used the bootparameter named other, set to isolcpus=[value]. Remove this setting for this and all ensuing versions of Oracle Communications Session Border Controller software.

CPU Core Configuration

You can configure CPU core settings using system-config parameters. This configuration is based on the specific needs of individual implementations. These parameters allow you to set and change the number of cores you want to assign to forwarding, DoS, and transcoding functionality. The system determines which cores perform those functions automatically.

You can determine and manage your core configuration based on the services you need. The system allocates cores to signaling upon installation. You can add forwarding cores to match your needs for handling media. You can also add DoS and transcoding cores if you need those functions in your deployment. If you want to reduce the size of your SBC deployment footprint or if you do not need the maximum number of cores and amount of memory available, you can deploy the SBC virtually with fewer cores and memory requirements. For smaller scale deployments, the VNF software supports a deployment with 2 virtual cores, 2 GB RAM, 20GB storage, and 2 interfaces.

Note the following:

  • By default, core 0 is always set to signaling.
  • The system selects cores based on function. You cannot assign core functions.
  • The system sets unassigned cores to signaling, with a maximum of 24.

    Note:

    Your hyperthreading configuration may impact these assignments.
  • You must reboot the system for core configuration changes to take effect.

When you make core assignments, the (SBC) provides an error message if the system detects an issue. In addition, the system performs a check when you issue the verify-config command to ensure that the total number of forwarding, plus DOS, plus transcoding cores does not exceed the maximum number of physical cores. After you save and activate a configuration that includes a change to the core configuration, the system displays a prompt to remind you that a reboot is required for the changes to take place.

You can verify core configuration from the ACLI, using the show datapath-config command or after core configuration changes during the save and activation processes. The SBC uses the following lettering (upper- and lower-case) in the ACLI to show core assignments:

  • S - Signaling
  • D - DoS
  • F - Forwarding
  • X - Transcoding

When using hyperthreading, which divides cores into a single physical (primary) and a single logical (secondary) core, this display may differ. SBC rules for displaying cores include:

  • Physical cores (no hyperthreading) in upper-case letters
  • "Primary" hyperthreaded sibling cores in upper-case letters
  • "Secondary" hyperthreaded sibling cores in lower-case letters
  • Stale (unused) hyperthreaded cores using the lower-case letter "n"

The system-config element includes the following parameters for core assignment:

  • dos-cores— Sets the number of cores the system must allocate for DOS functionality. A maximum of one core is allowed.
  • forwarding-cores—Sets the number of cores the system must allocate for the forwarding engine.
  • transcoding-cores—Sets the number of cores the system must allocate for transcoding. The default value is 0.
  • use-sibling-core-datapath—Enables the SBC to utilize the platform's SMT capability, impacting how the SBC uses sibling cores.

The SBC does not have a maximum number of cores, but your deployment does, based on host resources. The system checks CPU core resources before every boot, as configuration can affect resource requirements. Examples of such resource requirement variations include:

  • There are at least 2 CPUs assigned to signaling (by the system).
  • If DoS is required, then there are at least 1 CPU assigned to forwarding and 1 to DoS.
  • If DoS is not required, then there is at least 1 CPU assigned to forwarding.

    Note:

    Poll mode drivers, including vmxnet3, failsafe, MLX4 and Ixgbvf, only support a number of rxqueues that is a power of 2. When using these drivers, you should configure the number of forwarding cores to also be a power of 2. If there is a mismatch, the system changes the number of forwarding cores that it uses to the nearest power of 2 value. The remaining cores become stale; stale cores remain reserved by the system, but are not used.

The system performs resource utilization checks every time it boots for CPU, memory, and hard-disk to avoid configuration and resource conflicts.

Core configuration is supported by HA. For HA systems, resource utilization on the backup must be the same as the primary.

Note:

The hypervisor always reports the datapath CPU usage as fully utilized. This isolates a physical CPU to this work load, but may cause the hypervisor to generate a persistent alarm indicating that the VM is using an excessive amount of CPU. The alarm may trigger throttling. Oracle recommends that you configure the hypervisor monitoring appropriately, to avoid throttling.

In HA environments, when the primary node's core configuration changes, the SBC raises an alarm to warn that a reboot is required. After the configuration syncs, the secondary node raises the same alarm to warn that a reboot is required.

System Shutdown

Use the system's halt command to gracefully shutdown the VNF. 

ACMEPACKET# halt

-------------------------------------------------------
WARNING: you are about to halt this SD!
-------------------------------------------------------

Halt this SD [y/n]?:

See the ACLI Reference Guide for further information about this command.

Session Router Session Capacity Enhancement

You can increase the Session Router's session capacity on X8-2 servers with the sip-threads option by adding it to the system-config. The number of sipd threads is calculated based on number of CPUs available and hence you can spawn more sip-threads with this option.

  • Default: Based on the number of CPUs
  • Values: Min: 1 / Max: 30

Enabling the sip-threads option

To enable this option:

ORACLE(system-config)# options +sip-threads=value
If you type the option without the plus sign, you overwrite any previously configured options. To append the new option to the options list, prepend the new option with a plus sign as shown in the previous example.

Note:

Contact Oracle Support for assistance with setting the sip-threads option.