multicast-management

Dec-07-2015(armax): If someone is interested in pursuing it, this must be re-submitted according to guidelines defined in [1].

[1] http://docs.openstack.org/developer/neutron/policies/blueprints.html

-----------

..
 This work is licensed under a Creative Commons Attribution 3.0 Unported
 License.

 http://creativecommons.org/licenses/by/3.0/legalcode

==========================================
Dynamic multicast management solution
==========================================

The idea of this proposal is to support multicast snooping to avoid load on the
production virtual machines (VMs). This proposal provides dynamic management
of multicast group by provisioning the virtual switches which are hosted on the
KVM or ESX hypervisor.

Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/neutron/+spec/multicast-management

Problem description
===================

In existing Open stack solution, Tenant VMs hosted will receive unnecessary
multicast traffic upto the Layer of the IP Stack even though they have not
subscribed to the multicast group. ( i.e multicast packets “reaches” the L2
layer of the VM’s will be dropped at the Layer 2 since no multicast entry
exist).

With this proposal, the vSwitch will be provisioned to handle IGMP control
packets to manage multicast data packets of the unreserved multicast
data group. The reserved multicast group traffic will be always allowed
which is required for proper functioning of the network.

Proposed change
===============
To address the above challenge, the proposed solution require changes in the
L2 agent module. Flows will be added at the tunnel bridge to manage the
multicast traffic or an additional bridge will be hosted in the openvswitch
to manage the multicast groups.

The tenant VMs interested in the multicast traffic will registered the
multicast group. The kernel will send out the IGMP JOIN/LEAVE Reports for
the registered multicast groups, which reaches the OVS Switch hosted on the CN.
The OVS Switch on the CN will be provisioned with ‘FLOWS’ to allow multicast
traffic for only those VMs which are interested in the multicast traffic.

Following are Use-cases for supporting multicast in Openstack.

Tenant VM is the Multicast Group Receiver.
    The OVS Switch will be provisioned to BLOCK/ALLOW traffic from/to VMs.

Tenant VM is the Multicast Group Source.
    The OVS Switch will be provisioned to Forward the traffic to the NN
    because some Receivers might be on other side of the network(cloud)
    registered for this multicast traffic.

Tenant VM’s not being there in the multicast group but later joining the same.

Tenant VM’s being there in the multicast group but later leaving the same.

Support (S,G) entries. Source Specific multicast.
    The OVS Switch will be provisioned to support source specific entries.

NN – Querier can be deployed on it.
    NN will be provisioned for allowing the traffic or blocking the traffic
    from the outside world.

Physical Switch- Querier can be deployed on it.
    NN will be provisioned for allowing the traffic or blocking the traffic
    from the Physical Switch.