Skip to main content

12. Multicast Operation

This section describes a multicast routing operation over an IPv6 RPL network and, specifically, how unicast DAOs can be used to relay group registrations. The same DODAG construct can be used to forward unicast and multicast traffic. This section is limited to a description of how group registrations may be exchanged and how the forwarding infrastructure operates. It does not provide a full description of multicast within an LLN and, in particular, does not describe the generation of DODAGs specifically targeted at multicast or the details of operating RPL for multicast -- that will be the subject of further specifications.

The multicast group registration uses DAO messages that are identical to unicast except for the type of address that is transported. The main difference is that the multicast traffic going down is copied to all the children that have registered with the multicast group, whereas unicast traffic is passed to one child only.

Nodes that support the RPL Storing mode of operation SHOULD also support multicast DAO operations as described below. Nodes that only support the Non-Storing mode of operation are not expected to support this section.

The multicast operation is controlled by the MOP field in the DIO.

  • If the MOP field requires multicast support, then a node that joins the RPL network as a router must operate as described in this section for multicast signaling and forwarding within the RPL network. A node that does not support the multicast operation required by the MOP field can only join as a leaf.

  • If the MOP field does not require multicast support, then multicast is handled by some other way that is out of scope for this specification. (Examples may include a series of unicast copies or limited-scope flooding).

A router might select to pass a listener registration DAO message to its preferred parent only; in which case, multicast packets coming back might be lost for all of its sub-DODAGs if the transmission fails over that link. Alternatively, the router might select copying additional parents as it would do for DAO messages advertising unicast destinations; in which case, there might be duplicates that the router will need to prune.

As a result, multicast routing states are installed in each router on the way from the listeners to the DODAG root, enabling the root to copy a multicast packet to all its children routers that had issued a DAO message including a Target option for that multicast group.

For a multicast packet sourced from inside the DODAG, the packet is passed to the preferred parents, and if that fails, then to the alternates in the DODAG. The packet is also copied to all the registered children, except for the one that passed the packet. Finally, if there is a listener in the external infrastructure, then the DODAG root has to further propagate the packet into the external infrastructure.

As a result, the DODAG root acts as an automatic proxy Rendezvous Point for the RPL network and as source towards the non-RPL domain for all multicast flows started in the RPL domain. So, regardless of whether the root is actually attached to a non-RPL domain, and regardless of whether the DODAG is grounded or floating, the root can serve inner multicast streams at all times.

Last updated on