ONOS MFWD Architecture

The ONOS MFWD multicast architecture is composed of 4 primary functionalities: the Mulitcast Route Table that maintains Multicast ASM (*, G) and SSM (S, G) forwarding state within the ONOS controller, the MulticastForwarding module which responds to live multicast data traffic, the MulticastIntentManager responsible for interacting with the ONOS IntentService which in turn establishes paths through the network. Finally we have the MFWD CLI & REST API which allow external operators and applications to examine and modify existing mfwd state.

The following paragraphs we will breakdown each of the components and provide a couple graphics to help visualize these relationships.

Multicast Route Table (MRT)

The Multicast Route Table (MRT) which may also be referred to at times as the Multicast Routing Information Base (MRIB), is essentially the repository for Multicast Routes maintained by ONOS.

The MRT manages the set(s) of multicast routes (forwarding state) on behalf of external inputs that include:

 

Multicast Route Table implementation

The multicast route table is java class defined in the following file exposing the corresponding API:

Multicast Routes

The multicast routes are divided into two categories: a group route (*, G), also known as Any Source Multicast (ASM). There are also source routes (S, G) also known as Source Specific Multicast (SSM).

Structure of Multicast Routes are comprised of the follow Java classes and Interfaces. For the official MFWD API refer to the ONOS API documents. The class can be found with the corresponding java file.

How the MRT Stores Multicast routes

The MRT maintains a set of McastRouteGroup groups corresponding to each IPv4 or IPv6 group MFWD is maintaining state for.

The McastRouteGroup serves two purposes, first to maintain forwarding state for (*, G) ASM as well as a parent container for all McastRouteSource (S, G) routes that share the same multicast group address G.

ConnectPoints

ConnectPoints are an ONOS construct consisting of a switch name and port number. For the purpose of multicast we use the ConnectPoints to determine where multicast data enters (ingress) the SDN network, as well as the set of ConnectPoints the multicast data leaves (egress) the network.  Egress ConnectPoints will have a receiver attached to that connect point or forward multicast traffic into a network outside of the given SDN segment.

McastRouteBase, the parent of both (*, G) and (S, G) routes allow a single ingress ConnectPoint and set of egressConnectPoints.  The corresponding API will allow various connect points to be added and removed from the route base.  

Note: in the case of (*, G) the ingress ConnectPoint maybe NULL due to the fact that, by definition, the source of the multicast group is not known.  How Any Source Multicast is handled is dependent upon the use case and the specific implementation.  Currently we don't have any requirements to provide ASM support, however MFWD was designed as to not preclude ASM support.  

Both McastRouteGroup and McastRouteSource leverage the base class implementation of ingress and egress management functions, both classes provide additional functionality required for their respective needs.

Multicast Intent Manager

The McastIntentManager is responsible for registering with the ONOS IntentService, formulating and changing intents based on specific McastRoute State. The intent manager is also responsible for withdrawing intents and cleaning up after MFWD when the application is deactivated.

The McastIntentManager will register a SinglePointToMultiPointIntent for each multicast route which is used to forward multicast state.

The McastIntentManager relies on the following ONOS services:

The McastIntentManager.java provides the following:

Multicast Forwarding

The MulticastForwarding module is responsible for handling live multicast data.  For incoming multicast packets that do not match an existing multicast forwarding entry, the module will create a multicast forwarding entry with the ingress ConnectPoint with no egress ConnectPoints.  The state will be ready when and if receivers indicate interest.

When live multicast data arrives for which an entry does exist, if that entry also has one or more egress ConnectPoints, the entry is completed with the ingress ConnectPoint and handed to the MulticastIntentManager, which subsequently creates a SinglePointToMultiPointIntent that then is used to install the corresponding flow paths through the relevant switches.

 

flow in the OpenFlow switch and hence are passed upstream to the controller.

If no multicast forwarding state exists, the McastForwarding module will create multicast state.