Hello all
At Wednesday's meeting I promised to supply specific examples to help
illustrate the NFV use cases and also show how they map to some of the
blueprints. Here's my first example - info on our session border
controller, which is a data plane app. Please let me know if this is
the sort of example and detail the group are looking for, then I can
add it into the wiki and send out info on the second, a vIMS core.
Use case example
----------------
Perimeta Session Border Controller, Metaswitch Networks. Sits on the
edge of a service provider's network and polices SIP and RTP (i.e. VoIP)
control and media traffic passing over the access network between
end-users and the core network or the trunk network between the core and
another SP.
Characteristics relevant to NFV/OpenStack
-----------------------------------------
Fast & guaranteed performance:
- fast = performance of order of several million VoIP packets (~64-220
bytes depending on codec) per second per core (achievable on COTS hardware)
- guaranteed via SLAs.
Fully HA, with no SPOFs and service continuity over software and hardware
failures.
Elastically scalable by adding/removing instances under the control of the
NFV orchestrator.
Ideally, ability to separate traffic from different customers via VLANs.
Requirements and mapping to blueprints
--------------------------------------
Fast & guaranteed performance - implications for network:
- the packets per second target -> either SR-IOV or an accelerated
DPDK-like data plane
- maps to the SR-IOV and accelerated vSwitch blueprints:
- "SR-IOV Networking Support"
(https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov)
- "Open vSwitch to use patch ports"
(https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use)
- "userspace vhost in ovd vif bindings"
(https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost)
- "Snabb NFV driver"
(https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver)
- "VIF_SNABB"
(https://blueprints.launchpad.net/nova/+spec/vif-snabb)
Fast & guaranteed performance - implications for compute:
- to optimize data rate we need to keep all working data in L3 cache
-> need to be able to pin cores
- "Virt driver pinning guest vCPUs to host pCPUs"
(https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning)
- similarly to optimize data rate need to bind to NIC on host CPU's bus
- "I/O (PCIe) Based NUMA Scheduling"
(https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling)
- to offer guaranteed performance as opposed to 'best efforts' we need
to control placement of cores, minimise TLB misses and get accurate
info about core topology (threads vs. hyperthreads etc.); maps to the
remaining blueprints on NUMA & vCPU topology:
- "Virt driver guest vCPU topology configuration"
(https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology)
- "Virt driver guest NUMA node placement & topology"
(https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement)
- "Virt driver large page allocation for guest RAM"
(https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages)
- may need support to prevent 'noisy neighbours' stealing L3 cache -
unproven, and no blueprint we're aware of.
HA:
- requires anti-affinity rules to prevent active/passive being
instantiated on same host - already supported, so no gap.
Elastic scaling:
- similarly readily achievable using existing features - no gap.
VLAN trunking:
- maps straightforwardly to "VLAN trunking networks for NFV"
(https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks et al).
Other:
- being able to offer apparent traffic separation (e.g. service
traffic vs. application management) over single network is also
useful in some cases
- "Support two interfaces from one VM attached to the same
network" (https://blueprints.launchpad.net/nova/+spec/2-if-1-net)
regards
Calum
Calum Loudon
Director, Architecture
+44 (0)208 366 1177
METASWITCH NETWORKS
THE BRAINS OF THE NEW GLOBAL NETWORK
www.metaswitch.com
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
