IPv6 Multicast Explained PART2

Shinsuke Suzuki
Hitachi Corporation


With multicast, routers use two types of protocols, router-to-host protocol and router-to-router protocol in building route table. PART2 explains the two types of protocols in detail.


Router-to-host Protocol

Routers use router-to-host protocol to know the existence of nodes participating in multicast groups. Router-to-host protocol used in IPv6 is Multicast Listener Discovery Protocol (MLD).

MLDv1

MLD has two versions: MLDv1, which offer no Source-Specific-Multicast (SSM) support, and MLDv2, with SSM support. I will explain MLDv1 here.

MLDv1 protocol defines three messages as shown in Table 1.


Êê
ble 1 MLDv1 protocol messages

All of these messages have ICMPv6 header, followed by queried multicast group address.

When a node interface begins participating in multicast group G1, for example, the node sends MLDv1 Report message about G1 to this interface. MLDv1 Report message includes Router-Alert option, so routers can receive MLDv1 Report message, irrespective of the destination (G1 in this case). MLDv1 messages sent from a node get processed by the router on the same link. A router, upon receiving Report message, notifies to router-to-router protocol that it received a request to participate in multicast address G1.

Router sends an MLDv1 Query message (General Query) to FF02::1 (all-node link-local multicast address) in order to find out multicast group participation by nodes. After receiving General Query, nodes use MLDv1 Report to advertise all multicast addresses on these interfaces. Periodical queries enable routers to monitor multicast group participation by nodes real time. When a router has not received response from a node interface to its General Query for a specific period of time, the router decides that multicast group participation by the node interface is ended, and notifies that to router-to-router protocol. When two or more routers are present on the same segment, the router with the smallest link-local address sends MLDv1 Query (Querier).

When a node ends its participation to multicast group G1, it sends MLDv1 Done message, in the same way as when it began participation. When a router receives MLDv1 Done message, it sends a MLDv1 Query message for G1 (Group-Specific Query) to the interface which received the MLDv1 message. If the interface has other nodes participating in G1, it gets MLDv1 Report response to Group Specific Query. If the router receives no MLDv1 Report response to Group Specific Query for a specific period of time, the router decides that the interface has no G1 participant any more, and tells that to router-to-router protocol (Figure 8).


Figure 8 MLD Protocol Handshake

MLD Snooping

Normally on Ethernet, multicast frames are sent to all the nodes on the same Ethernet link. Therefore, multicast frames are sent to nodes that do not wish to receive multicast packets. Such irrelevant multicast frames are unfavorable because they inflict large burdens on low-resource nodes or lower-speed Ethernet like wireless LAN.

MLD Snooping is a technology to solve this problem. Specifically, when a switch receives multicast frames, the switch sends these frames to nodes that need to receive them. I will explain MLD Snooping using MLDv1, but it is generally the same with MLDv2.

MLD Snooping is realized through monitoring of MLD Report from a node to a router by the switch in between. In the case of Figure 9, the router sends MLD Query and PC1 responds to it with MLD Report to G1. MLD Snooping switch then sends MLD Report to the port connected to the router, while it memorizes that G1 is the only multicast address to forward frames to Port1. When PC1 ends participation to G1, the MLD Snooping switch stops forwarding packets for G1 to Port1.


Figure 9 MLD Snooping


Router-to-router Protocol

Router-to-router protocol is used by routers to build multicast route table. Router-to-router protocol mainly used in IPv6 is Protocol Independent Multicast (PIM). PIM offers two modes: Sparse-Mode and Dense-Mode. I will explain Sparse-Mode (PIM-SM) here, as it is widely used.

Building Multicast Route Table in PIM-SM

PIM-DM forwards received multicast packets first to all interfaces and then terminate forwarding to interfaces that do not require forwarding. On the other hand, PIM-SM builds multicast route table by exchanging multicast route information.

PIM-SM establish neighbor relationship through PIM Hello packet exchange, and build three type of multicast route table for different multicast packet volume: RP Tree, Register-Stop and Shortest-Path Tree.

RP Tree

This is a pattern that multicast packets are sent to a PIM-SM router (Rendezvous Point (RP)) by unicast and then forwarded to actual recipients from RP.

As shown in Figure 10, when PC2 and PC3 send MLDv1 Report to multicast group G1, Router5, connected to PC2 and PC3, sends PIM join, a group participation request, to a PIM-SM router (=Router4) that is positioned toward G1 RP (=Router3). At the same time, it creates multicast route table entry to take packets from Router4 with any source addresses destined to G1 and forwards them to the interface leading to PC2 and PC3.


Figure 10 RP Tree

In the same manner, Router4 sends PIM Join to Router3, and it creates multicast route table entry to take packets from Router3 with any source addresses destined to G1 and forwards them to the interface leading to PC1 and Router5.

When Router3 receives PIM Join from Router4, it creates a multicast route table entry to take packets arrived at RP with any source addresses destined to G1 and forwards them to Router4. The router itself is RP, so PIM Join is not sent to routers further than Router3.

When PC1 sends packets to G1, Router1, connected to PC1, forwards the multicast packets to Router3, which is RP. But PIM Join from Router5 does not reach Router1, so at this point, normal multicast packet forwarding is not possible.

Therefore, Router1 sends multicast packets directly by unicast to Router3, capsuling them in PIM Register packets. Router3 decapsules PIM Register packets it receives, and forwards the multicast packets inside to Router4 and Router5, based on multicast route table created as above.

Register-Stop

This is similar to RP-Tree, but in this case, data transmission to RP is sent over multicast, without capsuling.

When packet from PC1 to G1 gets increased and PIM Register packet volume to Router3 (an RP router) rises, Router3 sends PIM Join for Group G1 to upstream PIM-SM router (=Router2) towards PC1 router. At the same time, Router1 and Router2, creating multicast table entry to forward packets from Router2 destined to G1 to Router4, sends PIM Join to G1 and creates multicast route entry for packets from PC1 to G1. RP knows PC1 is the source of multicast packets because it already forwarded multicast packets from PC1 once. Therefore, multicast route table created in Router1 and Router2 includes PC1 source IP address.


Figure 11 Register-Stop

Such process is repeated to establish multicast forwarding path from Router1 through Router3 to recipients. Right when multicast packets get forwarded on this path, Router2, the RP router, sends Router1 PIM Register-Stop message to request the end of tunneling with PIM-Register packets.

This enables multicast packets from PC1 to be forwarded through Router3, without being encapsulated.

Shortest-Path Tree

This is for multicast transmission of packets with the shortest path from sender to recipients.

When multicast packets from PC1 increases further, and more multicast packets goes through Router3, Router5, on the path to receiving nodes, sends PIM Join toward PC1 to upstream PIM-SM router (Router1), as shown in Figure 12. When Router1 receives the PIM Join, it starts sending multicast packets from PC1 destined to G1 toward Router2 and Router5. When Router5 receives multicast packets destined to G1 from RP router (Router4), during direct multicast forwarding from Router1, then Router5 sends request to leave G1 (PIM Prune) toward RP router.

Such Join toward source address and Prune toward RP create multicast route table which enables shortest-path multicast forwarding.


Figure 12 Shortest-Path Tree

PIM-SM protcol

In the above explanation, all PIM-SM routers are supposed to support the following two points:

• They can calculate RP and upstream PIM-SM router toward sending node (Reverse Path Forwarding = RPF)
• They know the address of RP that corresponds to multicast address

I will explain how these are realized.

RPF

RPF is usually realized through unicast route table lookup. In other words, the router calculates the Next-Hop address to reach RP and sending node IPv6 address, and considers that this Next-Hop address is the address of upstream PIM-SM router.

But if all routers on the network do not support PIM-SM, the router found through unicast route table may not be PIM-SM router. In order to avoid such problems, some implementations realize RPF by looking up RPF-only route table. Static routing is often used for static configuration, but dynamic configuration is possible, using RPF-only route control protocols, such as MBGP.

When RPF result changes due to unicast path change or RPF route table setting change, PIM-SM router re-sends PIM Join toward new RPF. Thus PIM-SM behavior can be complex, because unicast path change as well as packet volume changes can change the behavior of protocol.

Correlating Group Address with RP Router Address

This is realized through static correlation setting between group address and RP router (Static-RP), or through dynamic correlation setting with Bootstrap Router (BSR) mechanism enabled at all routers. I will explain BSR mechanism below.

PIM-SM network using BSR requires at least one of PIM-SM routers on the network as BSR. BSR sends BSR information (BSR address, correlation between RP address and group address) to all PIM-SM routers with neighbor relationship (BSR message). PIM-SM router which received BSR information advertises the information to all neighboring routers. This way, all PIM-SM routers get BSR information.

RP router gets BSR information with the procedure like the above, and sends its RP information (correlation between RP address and group address) to BSR address included in BSR information, by unicast (Cand-RP message). This renews BSR information owned by BSR. BSR advertises the renewed BSR information through the above procedure, to tell RP router information to all PIM-SM routers.

MLD Proxy

MLD Proxy is a multicast forwarding technique based only on MLD messages. Unlike PIM-SM, it works only on a simple topology that allows clear identification of upstream and downstream, but the protocol is simpler than PIM-SM. Therefore, it is particularly suited for SOHO routers. I will explain the example with MLDv1 only, but it is the same with MLDv2.

MLD Proxy router has upstream interface and downstream interface. Upstream interface receives multicast packets, and downstream interface, connected to the nodes, receives MLD Report and MLD Done. MLD Proxy interface cannot work as upstream and downstream interface at the same time.

MLD Proxy router works as a node that sends MLD Report/Done on upstream interface, and it works as a router that sends MLD Query and receives MLD Report/Done on downstream interface. In the case of Figure 13, port1 receives MLD Report to G1 and G3, and port2 receives MLD Report to G1 and G2. Then MLD Proxy router sends MLD Report destined to G1, G2 and G3 to port0. It creates multicast route entry at the same time, and when multicast packets destined to G1, G2 or G3 arrives, they are forwarded to the port from which MLD Report of corresponding group is received.


Figure 13 MLD Proxy

When MLD Proxy router receives multicast packets from downstream interface, the packets are forwarded to downstream interfaces from which corresponding MLD Report is received, and upstream interface.

Reference
Router-to-host Protocol:
[1]RFC2710 Multicast Listener Discovery(MLD)for IPv6
[2]RFC3590 Source Address Selection for the Multicast Listener Discovery(MLD)Protocol
[3]draft-ietf-magma-snoop-11.txt Considerations for IGMP and MLD Snooping Switches

Router-to-router Protocol
[1]draft-ietf-pim-sm-v2-new-10.txt Protocol Independent Multicast - Sparse Mode(PIM-SM): Protocol Specification(Revised)
[2]draft-ietf-pim-sm-bsr-04.txt Bootstrap Router(BSR)Mechanism for PIM Sparse Mode
[3]draft-ietf-magma-igmp-proxy-06.txt IGMP/MLD-based Multicast Forwarding(IGMP/MLD Proxying)