0 Replies Latest reply: Aug 2, 2017 6:36 AM by Juan RSS

    Multicast Listener Discovery


      From the design point of view, we must be aware of the different kind of control protocols involved in multicast distribution. Control protocols help to be aware of the receivers interested in receiving multicast data and to build the multicast distribution tree that enable the data stream flow from senders to receivers.


      Multicast control protocols can be classified into two big categories:


      • Host-router: used for signaling purposes between the receiver and its first hop router (FHR).
      • Router-router: used for signaling purposes between routers to build a multicast distribution tree (MDT).


      MLD fits in the first category and it helps to identify receivers interested in multicast groups.




      MLD General concepts


      As we already said, MLD is a protocol used between the receiver and its FHR to signal the presence of multicast listeners, i.e., to discover listeners. It enables multicast enabled routers to learn which multicast groups have listeners on each of its directly attached links. Technically speaking MLD it’s not a protocol by itself but it’s integrated in ICMPv6.






      All MLD packets are sent with source address (SA) matching the interface link-local unicast address and with the Hop Limit parameter set to 1.


      There are two versions available. MLDv1 is covered under RFC 2710 and MLDv2 under RFC 3810. MLDv1 was designed to be used in ASM environments, where the receivers join the multicast group G without knowledge about the sources. With MLDv2 receivers can signal the FHR their interest in receiving data from a multicast group, and optionally, from some specific source S. MLDv2 is designed to be backwards compatible with MLDv1.


















      The first version of MLD is used by receivers to signal the interest in receiving data from a given group without any source filtering, i.e., it’s used to join and leave (*,G).


      There are tree kind of multicast listener (ML) messages in this version: ML Query, ML Report and ML Done:


      • ML Query: sent to query in General about all multicast groups via General Query or about some specific group G via Multicast Address Specific (MAS) Query.
      • ML Report: sent to join groups (*,G)
      • ML Done: sent to leave groups (*,G)





      Multicast Listener message


      IP destination

      Multicast address field



      Join Group





      Leave Group




      General Query

      General Query




      MAS Query

      Specific Query





      The MLD Querier Election Process ensures that there will be only one MLD Querier per shared network segment. When MLD routers go online, they start by sending ML Queries to the shared segment and the device with the lowest IP address become the Querier. All the other routers receiving a Query from another device attached to the same segment with a higher IP address become Non-querier and stop sending Query messages to the shared network segment.







      Once the MLD Querier is selected, receivers can safely signal join operations to the FHR. They do so by sending a ML Report to Join the group G. The message is sent with the multicast address G as the Destination of the IP datagram and in the Multicast Address Field of the MLD message.






      When the receivers are not interested in receiving information sent to some group G, they can signal that circumstance to the FHR by sending a ML Done to leave the group G. The message format is similar to the previous case with some minor changes in the IP Destination Address (IP DA).



      Once the FHR receives the leave for (*,G) from some receiver, sends himself a ML MAS Query to ask if there are other receivers interested in receiving information from group G. If there is still some receivers interested in the group, they (only one because of the report suppression feature) will inform of that by sending a ML Report to keep the multicast information flowing in the shared segment.


      MLDv1 has a feature named ML Report message suppression. This feature allows to suppress all subsequent ML Report messages sent by receivers when they listen that a partner in the same shared network segment already answered.


      General Queries are sent periodically into the shared segment and not in response to a change in the state of the receivers.

      I hope you find it useful.