What type of communication will send a message to all devices on a local area network a multicast?

Multicast networking is based on the simple concept that a single packet can be sent by a server and it will be received by many receivers. Multicast is different from broadcast because it’s more selective.

Where broadcast packets are received by all receivers in a particular network segment (or broadcast domain), multicast packets are received only by receivers that want them. Also, multicast receivers can be distributed throughout a larger network behind routers.

Primary uses for multicast networking

In IPv6 networks, there’s no such thing as broadcast. Multicast is used for everything that broadcast was previously used for, including a number of standard network infrastructure things like router discovery, address allocation, and neighbour discovery (which replaces ARP).

Multicast has a couple of fundamental characteristics that dictate how it’s used. Because a server only needs to send each packet once and will reach all of the recipients, it’s useful for situations where a large number of receivers need to receive the same data. Since the replication and distribution of these packets is done by the network rather than the head end server, it scales well to extremely large numbers of receivers.
But because the multicast is one-way, any responses would need to be implemented using a separate protocol. This also means that dropped packets must either be unimportant, or the recovery mechanisms for lost data must be built separately. There are two really common places where these characteristics are great strengths.

Photo: Unsplash

1. Distributing AV data streams

The first is in distributing audio/visual data streams identically to a large number of users. This is the case, for example, with modern IP-based cable TV networks. The set-top box subscribes to a multicast data stream that represents a program or a channel, and the network starts forwarding that data stream to it. Change the channel and the set-top box unsubscribes from that data stream and subscribes to another. If a packet’s lost, it’s not usually even noticeable, although losing several packets in a row can cause that blocky choppy video effect we’re all familiar with.

2. Providing real-time stock-market data

The second common application is real-time stock market data. In this scenario, all market participants must receive the same information at the same time to ensure the market is fair, so multicast is an ideal way of distributing the data. But in this case, lost packets are a potentially serious problem since they all contain important data about prices and transactions. So these types of data streams are accompanied by other systems that allow market participants to recover lost data over standard TCP unicast protocols.

Multicast would also theoretically be useful for things like internet gaming, in which real-time game information needs to be distributed to a large number of players. However, I’m not aware of any internet services that provide multicast forwarding capabilities. The reason for this is obvious: If you could cause the network to arbitrarily replicate packets, this could be abused to create denial of service attacks.

Essential problems with multicast networking

There are two essential problems with delivering multicast data streams. The first is how to allow receivers to subscribe to the multicast data they want and how to unsubscribe from data they no longer want to receive. The second is how to forward those packets from the server to all of the receivers so each packet is forwarded once and only once, regardless of how things are inter-connected.

We solve these problems using two protocols. IGMP (Internet Group Management Protocol) handles the joining and leaving of multicast streams for individual receivers.

PIM (Protocol Independent Multicast) is the protocol that Layer 3 network devices such as routers use to build and manage the multicast delivery tree structures across the network.

1. IGMP

The first thing to mention about IGMP is, although the multicast IP addresses that appear in the “destination” field of the multicast packet header look like normal IPv4 or IPv6 addresses, they’re actually “group” addresses that refer to all of the members of the group.

A device can join a group by sending an IGMP “membership report” message to the group IP address. This packet is received by a multicast router on the segment, and the router does whatever is necessary to start forwarding the data stream to this device.

IGMP membership report packets are always sent with a TTL value of 1 so they can’t leave the current network segment.

There are three versions of IGMP: Version 1 provides the basic functionality of allowing devices to subscribe to multicast groups. Version 2 introduced the ability to also leave a multicast group. And in Version 3, devices were given the ability to request a multicast stream from a specific source device (Source Specific Multicast), instead of just generically from any sending device.

2. IGMP snooping

An important Layer 2 adjunct to IGMP is called IGMP snooping. This isn’t a protocol so much as a feature. With IGMP Snooping enabled, a Layer 2 device like an Ethernet switch listens to IGMP membership reports as well as the router. The switch then is able to use this information to ensure that only those devices that actually want to receive this multicast group get the data, instead of all devices on the segment.

In many implementations of IGMP Snooping, the switch also intercepts the membership reports and keeps track of which groups are required on each VLAN. It can become a proxy “querier” on behalf of the VLAN, requesting groups that are required and delivering them only to the right end devices. At the same time, it can keep track of when no devices on the segment are still interested in each group, and send a “leave” IGMP report up to the multicast router to tell it to stop forwarding this group.

Some Cisco switches implement a protocol called CGMP (Cisco Group Management Protocol), which uses the CDP (Cisco Discovery Protocol) to communicate group membership between the switch and the router. This is only relevant if you have Cisco switches and routers deployed on your network. CGMP was sort of a “stop gap” solution to some of the shortcomings of IGMP Version 1, and it should probably be avoided in favour of standard protocols now.

3. PIM

Photo: Unsplash

Because IGMP membership report packets are always sent with a TTL value of 1, they can’t be used to find a source on a different network segment. For that, we use PIM (Protocol Independent Multicast). The “protocol independence” here means that it can use any IP routing protocol, including static routes if need be. It doesn’t need to distribute its own routes or maintain a separate multicast routing table.

Routers take part in PIM. Each router uses its unicast routing table to discover the shortest path back to the multicast source. This is called RPF (Reverse Path Forwarding). Using RPF, each router is able to decide which interface it should receive the multicast group through. As long as all of the routers in the network agree on the unicast routing table, this will form a reliable tree structure that, like spanning tree, will be free from loops.

PIM has two operating modes: dense mode and sparse mode. I don’t really recommend using dense mode except for the very smallest and simplest of multicast networks. It doesn’t use network resources as efficiently as sparse mode.

The biggest practical difference to configuring coarse mode is the requirement for a “Rendezvous Point.”

4. Rendezvous Points

The Rendezvous Point (RP) in a PIM-sparse mode network exists to find the multicast group and source. A multicast router has received a request to forward some multicast group out through a particular interface. This could have come from a directly connected device via IGMP or from a downstream router via PIM. If the router already has this multicast stream, then it can simply start forwarding it to the destination. But if it doesn’t know anything about this group, it needs to somehow find it first.

The RP is another router on the network. When the source device starts sending its multicast packets, the first router, on the same segment as the source, picks up that packet and forwards it to the RP router. This first step, which is called “registration,” is done using unicast.
The first hop router already knows the address of the RP. There are several mechanisms for this information to be learned, but the simplest and arguably the most effective and secure is to just configure it statically in each router.

Each multicast group has a RP. It’s common to have a single device act as the RP for a large number of multicast groups. The RP has two functions: It maintains a table of all of the sources for each group, and it also receives and redistributes all of the groups that it is responsible for.
When another router on the network receives a request for a multicast group that it doesn’t already know about, it sends a PIM “join-group” message to the next upstream router in the direction of the RP. That upstream router does the same, and the process continues until the chain of routers reaches all the way to the RP. The RP then starts forwarding the group along that path, and ultimately the device that made the request using IGMP starts to receive the multicast group as well.

As soon as the first multicast packets from the RP arrive at the “first hop” router, the one that received the original IGMP join request from the receiving device, that first hop router has an important new piece of information—it now knows the source IP address for the group.

Now that it knows the real source IP address, it can get the multicast data stream directly from the source, instead of from the RP. So it uses PIM joins to create a new multicast tree that goes directly to the source IP (the “source-rooted tree”). And, if the RP-rooted multicast tree uses a different interface from the source-rooted tree, then it will tear down the RP-rooted tree to avoid receiving multiple copies of the multicast packets.

There are other various adaptations to this process such as Source-Specific Multicast and Bi-directional PIM, which use other tricks to improve the efficiency in finding the source and creating the source-rooted tree, but the ultimate goal is the same.

How to create a multicast application on your network

As I mentioned earlier, multicast group IP addresses look like regular addresses. They’re different because they come from a special range. In IPv4, that range is 224.0.0.0/4 (224.0.0.0 – 239.255.255.255). Any packet that’s addressed to one of these IP addresses is automatically assumed to be a multicast, and is delivered according to the multicast forwarding tables in the router (or dropped if there’s no known multicast recipient for this group, or if multicast isn’t configured).

Within this broad range, some multicast addresses and ranges of addresses are reserved for specific purposes and you’re prohibited from using them for other purposes. For example, the first block, 224.0.0.0/24, is reserved for well-defined standard multicast protocols that are constrained to the local segment, such as OSPF and EIGRP. The general allocation of IPv4 multicast addresses is documented here.

If you plan to create a multicast application on your local network, you can do it in one of three ways.

1. Local scope

The first way—which is useful in purely local environments and labs—is to use the organization local scope from the administratively scoped ranges, 239.192.0.0/14. These addresses are similar to the private IP address ranges such as 10.0.0.0/8 in that anybody can use them locally within their own network. However, network admins are expected to ensure that they don’t leave the local network. For more information on these addresses, please refer to RFC 2365.

2. GLOP addressing

The second way is to use GLOP addressing (GLOP isn’t an acronym, it just means glop). This scheme, which is defined in RFC 3180, uses a registered BGP ASN to create a multicast address range.

Since BGP ASNs were originally two bytes long, the GLOP scheme takes the 233.0.0.0/8 range of addresses and encodes that 2-byte ASN into the second and third bytes of the address. So, if you had a BGP ASN of 65525, the GLOP range would be 233.255.245.0/24. This is because 65525 in hex would be FFF5. FF equals 255 and F5 equals 245, giving the second and third octets of the address.

The problem with GLOP addressing is that it assumes that your BGP ASN is the old-style 2-byte ASN. It doesn’t work well with the newer expanded ASN values. So RFC 6034 introduced another way of accomplishing the same thing using registered public IP addresses instead of ASNs.

3. Permanently assigned addresses

And the third way to get a permanently assigned address in the ranges 224.0.2.0-224.0.255.0 and 224.1.0.0-224.1.255.255 by applying to the IANA. These addresses are in relatively short supply, though. So, unless you have a multicast application that you intend to share with a large number of downstream clients, it’s probably better to use one of the other methods.

What type of communication will send a message to all devices on a local area network that implements IPv6?

What type of communication will send a message to a selected set of hosts on a local area network?

Which message delivery option is used when all devices need to receive the same message simultaneously?