Multicast overview
Sometimes, distribution needs individual IP packets be delivered to multiple destinations (like audio or video streaming broadcasts). Multicast is a method of distributing datagrams sourced from one or more hosts to a set of receivers that may be distributed over different (sub) networks. This makes the delivery of multicast datagrams significantly more complex.
Multicast sources can send a single copy of data using a single address for the entire group of recipients. The routers between the source and recipients route the data using the group address route. Multicast packets are delivered to a multicast group. A multicast group specifies a set of recipients who are interested in a particular data stream and is represented by an IP address from a specified range. Data addressed to the IP address is forwarded to the group members. A source host sends data to a multicast group by specifying the multicast group address in the datagram’s destination IP address. A source does not have to register to send data to a group, nor do they need to be a member of the group.
Routers and Layer 3 switches use the Internet Group Management Protocol (IGMP) to manage membership for a multicast session. When a host wants to receive one or more multicast sessions, it sends a join message for each multicast group it wants to join. When a host wants to leave a multicast group, it sends a leave message.
The SR Linux routers primarily use a combination of the following protocols:
-
Internet Gateway Multicast Protocol (IGMP)
- Multicast Listener Discovery Protocol (MLDP)
-
Protocol Independent Multicast (Sparse Mode) (PIM-SM)
Multicast models
SM
Sparse Mode Multicast (SM) is the IP multicast service model defined in RFC 7761,
Host Extensions for IP Multicasting. An IP datagram is transmitted to a
host group, a set of zero or more end-hosts, identified by a single IP destination
address within the range 224.0.0.0 to 239.255.255.255 for IPv4 and FF00::/8 for
IPv6. End-hosts can join and leave the group at any time, and there is no limitation
on their location or number. This model supports multicast groups with arbitrarily
many senders. Any end-host can transmit to a host group even if it is not a member.
Any Source Multicast (ASM) is represented by (*, G) notation. The
* (wildcard) indicates that the multicast group can receive
traffic from any source. G represents the multicast group
address.
SSM
The Source-Specific Model (SSM) is also explained in RFC 7761 and it allow a receiver to select the group it wants to receive and the sources from which it wants to receive the data. This extension is intended to give administrators greater control over senders in the multicast network. The source-specific multicast range (232.0.0.0/8) includes addresses reserved for use with the PIM SSM model.
The source-specific model defines a channel identified by an (S, G) pair, where S is a source address and G is an SSM destination address. In contrast to the ASM model, SSM only provides network-layer support for one-to-many delivery.
The SSM service model attempts to alleviate the following deployment problems that SM has presented:
-
address allocation
SSM defines channels on a per-source basis. For example, the channel (S1, G) is distinct from the channel (S2, G), where S1 and S2 are source addresses, and G is an SSM destination address. This averts the problem of global allocation of SSM destination addresses and makes each source independently responsible for resolving address collisions for the various channels it creates.
-
access control
SSM provides an efficient solution to the access control problem. When a receiver subscribes to an (S, G) channel, it receives data sent only by the source S. In contrast, any host can transmit to an ASM host group. At the same time, when a sender picks a channel (S, G) to transmit on, it is automatically ensured that no other sender is transmitting on the same channel (except in the case of malicious acts such as address spoofing). This makes it harder to spam an SSM channel than an SM multicast group.
-
handling of well-known sources
SSM requires only source-based forwarding trees, eliminating the need for a shared tree infrastructure. In terms of the IGMP, PIM-SM, Multicast Source Discovery Protocol (MSDP), and Multiprotocol BGP (MBGP) protocol suite, this implies that neither the Rendezvous Point (RP)-based shared tree infrastructure of PIM-SM nor the MSDP protocol is required. Thus, the complexity of the multicast routing infrastructure for SSM is low, making it viable for immediate deployment. MBGP is still required to distribute multicast reachability information.
Multicast protocols
| Protocols | Layer | Usage | IPv4/IPv6 |
|---|---|---|---|
| IGMP | Layer 3 | Handles host and multicast device communication | IPv4 |
| MLD | Layer 3 | Handles host and multicast device communication | IPv6 |
| PIM | Layer 3 | Manages multicast routing | IPv4/IPv6 |
Multicast routing configurations are applicable to both default and non-default network-instances.
In the following example, the Base Band Units (BBUs), such as 4G/5G/hotel BBUs, are connected to the cell site router.
These BBUs support IGMP or MLD to indicate their intent to join or leave a multicast group, with signaling typically being source-specific multicast (<S, G>).
In some scenarios, older equipment at the cell site, such as cameras, can signal <*, G>. In these scenarios, the <*, G> signal can either be translated to <S, G> via IGMP/MLD translation or PIM ASM with Rendezvous Point (RP) configuration can be used to signal joins and prunes to the RP.
The cell site router translates these IGMP or MLD join or prunes into PIM join or prunes on the Network-to-Network Interface (NNI), signaling the multicast to the source.
Multicast policies
Multicast traffic can be restricted from specific source addresses by creating routing policies. When a multicast policy is applied to IGMP, MLD, or PIM, the multicast parameters in the policy statement are compared to the (S,G) or (*, G) in the incoming join or prune messages for the protocol. If a match is found, the join or prune message is accepted or denied based on the policy action. The same policy can be applied to multiple protocols.