Deployment Types

The Cisco Provider Connectivity Assurance Sensor Control can be provisioned for these deployment types:

• NFV TWAMP: 4 CPU cores, 8 GB RAM
• Direct PM Actuation with i350: 1 CPU core, 4 GB RAM
• Direct PM Actuation in SR-IOV Mode: 1 CPU core, 4 GB RAM
• Reduced NFV PM Footprint: 1 CPU core, 4 GB RAM

NFV TWAMP

This scenario supports 500 VCEs on a single module, or divided between 500 modules. It is supported on both KVM and VMware.

The NFV TWAMP definition:

• Supports 4k sessions per Sensor Control instance in IPv4 and IPv6
• Supports 4k TWAMP control sessions at the same time for both IPv4 or IPv6
• Supports 2k sessions per module in IPv4 or IPv6

Resource Requirements:

• CPU pinning (affinity) of 4 CPU cores per Sensor Control instance
• Assign 8 GB of RAM per Sensor Control instance
• Policies of all timer elements must be set to catchup

Direct PM Actuation with i350

This scenario focuses on generating session probes from the host. Sensor Control does not manage any modules in this configuration. It is supported on both KVM and VMware.

The Direct PM Actuation with i350 definition:

• Supports 4k sessions per Sensor Control in IPv4 and IPv6
• Supports 4k TWAMP control sessions at the same time for both IPv4 or IPv6
• Supports these i350 adapters:
  • HPE Ethernet, I350-T4V2 Adapter (HPE Ethernet 1Gb 4-port 366T Adapter - PCI Express 2.1 x4 - 4 Port(s) - 4 - Twisted Pair - 10/100/1000Base-T - Plug-in Card)
  • Embedded FlexibleLOM 1 Port n : HP Ethernet 1Gb 4-port 366FLR Adapter
• Does not support sessions on module

Resource Requirements:

• CPU pinning (affinity) of 1 CPU core per Sensor Control instance
• Assign 4 GB of RAM per Sensor Control instance
• Sensor Control instance must be configured to support PCI Passthrough model type with the following considerations:
  • Remove the interface in XML config of eth port to the Sensor Control instance
  • Add hostdev to XML configuration for the virtual machine based on the bus info of eth port to the Sensor Control instance. Ex: eth1
• Policies of all timer elements must be set to catchup

Direct PM Actuation in SR-IOV Mode

This scenario focuses on generating session probes from the host. Sensor Control does not manage any modules in this configuration. It is supported on both KVM and VMware.

Unlike the Direct PM Actuation with i350 definition, which uses PCI passthrough, the NIC is configured with the Direct PM Actuation in SR-IOV Mode definition.

The SR-IOV definition:

• Supports 4k sessions per Sensor Control in IPv4 and IPv6
• Supports 4k TWAMP control sessions at the same time for both IPv4 or IPv6
• Does not support sessions on module

Resource requirements:

• CPU pinning (affinity) of 1 CPU core per Sensor Control instance
• Assign 4 GB of RAM per Sensor Control instance
• Policies of all timer elements must be set to catchup

Reduced NFV PM Footprint

This scenario applies to the KVM Hypervisor deployments and VMware. To support 500 VCEs on a single module, or divided between five modules, you must create an XML file defining proper virtual machine properties for the KVM or apply the equivalent setting in VMware.

The Reduced NFV PM Footprint supports:

• 4k sessions per Sensor Control in IPv4 and IPv6
• 4k TWAMP control sessions at the same time for both IPv4 or IPv6
• 4k sessions per module in IPv4 or IPv6
• a maximum of 5 managed remote devices
• a maximum of 1 hop and 2 ms RTT between Sensor Control and the module

The following diagram illustrates the topology for reducing the NFV PM footprint. This specific optimized TWAMP configuration uses one CPU, as shown below:

Resource Requirements:

• CPU pinning (affinity) of 1 CPU core per Sensor Control instance
• Assign 4 GB of RAM per Sensor Control instance
• Sensor Control instance must be configured to support PCI Passthrough model type with the following considerations:
  • Remove the interface in XML config of eth port to the Sensor Control instance.
  • Add hostdev to XML configuration for the virtual machine based on the bus info of eth port to the Sensor Control instance. Ex: eth1.
• Policies of all timer elements must be set to catchup