ENCOR Journey – Multicast Background

Unless otherwise specified, I think it is easy to go into a routing scenario or situation assuming that the traffic flows are unicast. What do I mean by this? Unicast traffic flows are what I will call the “typical” end user type communications in a network. One device needs to talk to another device. The source IP is the address of the originating host and destination IP is the address of the “far end” device (for example, server). Let’s give an example of a unicast traffic flow. A person opens up a web browser and types http://www.bogusexamplewebsite.com (I don’t know if this is real or not, this is just an example) into the address bar. As we flow down the stack (or OSI model) from Layer 7 (Application Layer), in order for the packets to be delivered, a destination IP address needs to be known. In this case, DNS will be leveraged to translate the website name into an IP address. Once that process is complete, we now have our unicast conversation, one source IP address to one destination IP address. This is a basic unicast conversation on a network. This seems fairly straightforward, this must be the way that all conversations should happen on a network, right? Well, not always.

Let’s bring another example in. Let’s say that an organization has a need to deliver real-time, streaming video to employees for “daily check-in” meetings. A server gets set up for this, and every day at 9:00 AM, live video is streamed to the organization, and employees can use an application on their devices to “tune in” to this stream if they wish. This could get out of hand in a hurry if we had to leverage unicast for this method of streaming video delivery. If unicast was used, there would be a separate session for every client from the server that requested the stream. This does not scale well as it could heavily consume computing resources on the server and bandwidth on the network. See the example diagram below that gives a visual for how this stream would look if unicast was leveraged for packet delivery.

In the image above, there are four total workstations in the network that request the video stream. With unicast, the video server receives four different requests and sends the same stream four different times. This method can be resource intensive and may not scale well in large environments. Thankfully, another option exists. When leveraging multicast, we can have a streaming traffic flow that looks more like this image below.

While unicast gives us a “one-to-one” packet delivery mechanism, multicast is leveraged to support “one-to-many” use cases. The case of the “daily check-in” meetings is definitely a scenario in which a one-to-many delivery mechanism makes sense. Well, this sounds great, let’s just “turn it on” and walk away, right!? As with most things, there is more to it than that. First off, what are the requirements to support multicast?

• The end user applications must be programmed to request data from a multicast group address.
• The server application must be programmed to send data to a multicast group.
• The network must configured to support multicast routing.

In the requirements listed above, I made reference to a multicast group address. A multicast sender (server) sends data to a multicast group address instead of individual client unicast IP addresses. Multicast receivers (end user applications) “subscribe” to a multicast group and request to receive data that is sent to that multicast group address from the multicast sender. The routers in between facilitate the multicast registration and packet delivery. Multicast addresses live in the Class D IP space of 224.0.0.0/4, which gives a range of addresses from 224.0.0.0 to 239.255.255.255. Within the Class D space, different ranges are specified for different purposes of multicast.

Conclusion

Multicast provides us the ability for more efficient packet delivery for certain use cases. These use cases include applications that provide a “one-to-many” functionality. An example use case is a server delivering streaming video to clients. When applications support multicast, and someone opens the app to request a stream, in modern multicast deployments, the application “subscribes” to a multicast group, which registers the device to it’s local router saying “Hey, please send me traffic destined to multicast IP address X.X.X.X”. The local router then registers itself to upstream routers requesting subscription to receive multicast packets to that specified multicast group. Then, as the stream is sent to that multicast group address, it is forwarded down the multicast distribution tree (MDT) to routers that have registered. Those routers keep track of the downstream interfaces from which the multicast requests were generated, and continue forwarding the packets to their destination. There is more to come, as there is a lot to unpack with multicast! Please join me in future posts.