Open Stack

----- Original Message -----
> From: "Calum Loudon" <Calum.Loudon at metaswitch.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> 
> 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

Hi Calum,

Thanks for contributing this, I think as a concrete example it's very helpful and I like the breakdown. I've taken the liberty of adding it to the Wiki for further editing/discussion (it appears Chris has not split the pages as yet so for now on the meetings page):

    https://wiki.openstack.org/wiki/Teams/NFV#Session_Border_Controller

The content itself seems fine, I think however for brevity - particularly as we add more - we need to come up with a way to condense the amount of space taken up by the requirements list. I notice for the ETSI use cases a column was added to the blueprints table to track how they aligned, I am wondering if the same column should be reused/abused for the user contributed use cases such as the one you provided or we should add another column? 

Thanks,

Steve