This is my first blog post within the Data Center and Cloud technology area. I recently joined the Openstack@Cisco team under Lew Tucker focusing on advanced OpenStack System research as a Cloud Architect. As part of this role I performed a gap analysis on the functionality (or the lack thereof) of multicast within an OpenStack based private Cloud. Coming from Advanced Services I have seen multicast as a critical component of many datacenters providing group based access to data (streaming content, video conferencing, etc.) . Within a Cloud environment this requirement is almost if not more as critical as it is for enterprise data centers.
This blog will be the first in a series highlighting the current state of multicast capabilities within OpenStack. Here, I focused the analysis on OpenStack Icehouse running on top of Redhat 7 with OVS and a VLAN based network environment. I would like to thank the OpenStack Systems Engineering team for their great work on lying the foundation for this effort (preliminary tests on Ubuntu and Havana).
I used a virtual traffic generator called TeraVM to generate multicast based video traffic allowing for Mean Opinion Score calculation. The Mean Opinion Score or MOS is a calculated value showing the quality of video traffic based on latency, jitter, out of order packets and other network statistics. Historically, the MOS value was based on human perception of the quality of voice calls, hence the word opinion. Since then it has developed to an industry standardized way of measuring the quality of video and audio in networks. It is therefore a good way to objectively measure the performance of multicast on an OpenStack based Cloud. The MOS value ranges from 1 (very poor) to 5 (excellent). Anything above ~4.2 is typically acceptable for Service Provider grade video transmission.
I performed the multicast testing on a basic controller/compute node OpenStack environment, with neutron handling network traffic. In this blog, I focus my analysis solely on opensource components of OpenStack with Cisco products (CSR and N1K) being discussed in a follow-up blog. The tenant/provider networks are separated using VLANs. A Nexus 3064-X is used as the top of rack switch providing physical connectivity between the compute nodes. The nodes are based on UCS-C servers.
Multicast functionality can be split into two parts. The first defines how multicast traffic is handled within a Layer-2 domain and relates to the IGMP snooping capabilities of a Switch. The second part is used to define the Layer-3 multicast tree for anysource-specific(ASM) or source-specific multicast (SSM). This is mainly defined by the switches Protocol Independent Multicast (PIM) functionality. Based on those two main multicast protocols I defined the following three test scenarios:
My small test environment revealed the following results:
In summary, I found that OpenStack using the L3 agent and OpenvSwitch does not provide common multicast features. To enable a basic video streaming environment IGMP snooping is required. At the moment, OpenStack is not suitable for multicast specific applications.
As a little sneak preview in part 2 of this series I will be showing how to use Cisco products such as the Nexus 1000V or the Cloud Service Router (CSR) 1000V to introduce multicast functionality. Part 3 will look into an implementation of IGMP within OVS.