IPv6 Multicast Explained PART3

Shinsuke Suzuki
Hitachi Corporation


PART3 discusses the challenges in existing multicast table creation, and explains Source-Specific-Multicast (SSM), a new multicast mechanism, and MLDv2, a router-to-host protocol supporting SSM.


Source-Specific-Multicast

The core of multicast route control is automatic creation of multicast route table from the sender to recipients. But router-to-host protocol only tells the address of multicast group joined by the recipient node. Therefore, routers cannot know who the sender is. Previous router-to-host protocol nor router-to-router cannot build multicast route table from the sender to the recipient automatically.

Through techniques shown in Table 2, Routers can create multicast route table from the sender to recipients, without acquiring sender information from the receiving nodes. But each of these techniques has shortcomings described in this table.


Table 2 Multicast Route Table Creation Techniques and Their Shortcomings

Characteristics of Source-Specific-Multicast

Source-Specific-Multicast (SSM) is a multicast technique in which receiving nodes specify the sender in joining a multicast group. Compared with previous multicast (Any-Source-Multicast=ASM), in which recipients do not specify the sender, SSM has the following advantages:

• Simpler Protocol
  Multicast packet sender information is given to the network from the recipient nodes, so it is very simple to build a multicast route table from the sender to the recipients.
  
  
• Improved Security at Receiving Nodes
  With SSM, receiving nodes do not accept multicast packets from senders other than the one specified by the router-to-host protocol. Therefore, legitimate multicast communication is not interfered by multicast packets from undesired sending nodes.
  
  
• Nodes and Routers Need to Support SSM
  For SSM communication, it is necessary for the recipients to be able to specify the sender through router-to-host protocol and router-to-router protocol. As for router-to-router protocol, this can be done with PIM-SM. But for router-to-host protocol, MLDv1 cannot achieve this. Therefore, you need a new router-to-host protocol MLDv2, which provides support for SSM.

A major application for multicast is video streaming, in which senders are limited to one or two nodes. Therefore, SSM is a great way to simplify the protocol with reasonable assumption. But SSM is not suitable for the type of multicast communication such as service detection protocol, in which senders cannot be pre-determined. By the way, recipients are able to know easily who the sender is, by using session control protocol or reference stream metadata.

MLDv2

In a nutshell, MLDv2 is MLDv1 plus ability to specify sender information. With MLDv2, a node sends participation information with MLD Report and MLD Done, while routers survey multicast group participation information with MLD Query, just like MLDv1. MLDv2 uses the following two types of ICMPv6 messages, just like MLDv1 (MLDv2 Done performs the same function as MLDv1 Done).

• MLDv2 Report
  Nodes send routers request to leave a particular multicast group (ICMPv6 Type=143).
  
  
• MLDv2 Query
  Router queries nodes multicast participation status (ICMPv6 Type=130)

Major differences of MLDv2 from MLDv1 are:

• Inclusion of sender information
  MLDv2 Report/Query messages can include sender information.
  
  
• MLDv1 compatible mode
  Nodes and routers supporting MLDv2 act as MLDv1 nodes/routers when MLDv1 routers or nodes are present.

I will explain them in detail below.

Inclusion of sender information

Sender information can be specified in 6 types in MLDv2 Report.
They can be grouped in two: INCLUDE mode (accepting multicast packet only from specified sender), and EXCLUDE mode (accepting multicast packet from senders other than specified one).

If a node sends MLDv2 Report specifying sender with INCLUDE mode, MLDv2 router sends group participation request directly to the sender, not to RP router. When a node sends MLDv2 Report with no sender specified, MLDv2 router considers this as a request to leave a group.

If a node sends MLDv2 Report specifying sender with EXCLUDE mode, MLDv2 router behaves as if it received MLDv2 Report with no sender specified. When the node receives a multicast packet, it compares the sender of this packet with the sender specified for EXCLUDE mode, to determine whether it wants to receive the packet or not.

MLDv1 compatible mode

When an MLDv2 node receives MLDv1 Query, the node switches to MLDv1 compatible mode at the receiving interface for a specific period of time, to respond to this MLDv1 Query with MLDv1 Report. When an MLDv2 node in MLDv1 compatible mode wishes to join another multicast group, the node makes join request with MLDv1 Report (MLDv1 Query and MLDv2 Query share the same ICMPv6 Type, therefore MLDv2 node makes distinction of the two by packet length).

When an MLDv2 router receives MLDv1 Report or MLDv1 Done, the router functions in MLDv1 compatible mode only for this group. The router also makes conversion of MLDv1 Report/Done to MLDv2 Report, and discards MLDv2 Report untranslatable to MLDv1 Report/Done. The router keeps on managing group participation through MLDv2.

When the MLDv2 router is in MLDv1 mode, the router does not send sender-specified MLDv2 Query. But you should not forget that normal MLD Query is conducted with MLDv2. It is because, if MLD Query were conducted with MLDv1, all unrelated MLDv2 nodes switch to MLDv1 compatible mode, making MLDv2 unusable.

Source-Specific-Multicast :
[1] RFC3569 An Overview of Source-Specific Multicast (SSM)
[2] RFC3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6
[3] RFC3678 Socket Interface Extensions for Multicast Source Filters