1. IGMP Protocol and Versions
Now, in this video, our main focus will be on IGMP protocol. But before we go ahead with IGMP, let’s quickly summarize what we discussed in the previous sections. Let’s say there is a multicast server sending a multicast traffic to some of the receivers on the remote network. Now, there are two major protocols which will allow to do that. Now, the one protocol is your IGMP protocol. Now, IGMP protocol is going to inform to the local router informing what is for which group it has to receive the multicast staffing. And then the other protocol is the multicast routing protocol. That is a pim protocol is responsible for figuring out the server based on some multicast routing and so that the multicast traffic will come back here. And that’s how it works. So in this section, we’ll talk about IGMP.
Now, IGMP stands for Internet Group Management Protocol. Now, this protocol is responsible for communication between the end devices and the router. So let’s say I got a land here, and in this land, I got some users in the land and the end host and the router communication is done by this IGMP protocol. Now, there are two major goals of this IGMP protocol. The first goal is to inform the local multicast router. Like every receiver, if they want to receive the multicast traffic, they need to inform to the local router that they want to receive the multicast traffic for a group address 224 five. So they need to tell that I need to receive the multicast traffic for this group, and the router has to figure out where is that group server which is hosting that multicast application.
Okay, so to inform the local multicast router that the host want to receive the multicast traffic and to inform the local multicast routers that the hosts want to leave the group. Now, once they receive the multicast traffic, probably the IGMP protocol is again responsible for informing the local router that they want to leave the group when you close the application. So there are three different versions in IGMP. We got version one, version two, and version three. Now, all the three versions works. There are common behavior in these three versions with some slight enhancements in the next versions. Now, version two is the one which works by default. So first, let’s talk about how IGMP is going to work. In any of these three versions, it’s going to use some report and query messages.
Now, report messages are used by the client to join the group. So let’s say there is a server which is hosting a multicast application for 2240 zero five. Now, I got a host here who is also running multicast application, and it wants to receive the multicast traffic for 224 five. Now, it’s going to send out a report message to the router saying that, hello router, I want to receive the multicast traffic for this group, and I got that application. Now I want to receive the multicast traffic for this group. Now the router is going to send router is going to communicate with that particular server based on some routing protocols, multicast routing protocols called pim. We are not getting into pim details as of now here and then get the multicast traffic and then the router will send it back to the host.
Now, similar way the same thing happens for the remaining receivers if you have in your land. Now, once the router is sending the multicast traffic, it’s going to use some query messages. Now the query messages are used by the router to the host asking do you want to receive the multicast traffic still or not. So it’s just like a verification that the router is doing whether the host connected in the lamb still want multicast traffic or not. And it’s going to send on 2240 zero one that the multicaster is used by the host in the listen on this address. So one is report messages. Report message is used by the host to requesting that it wants to join the group or receive the multicast traffic and the query message used by the router for querying whether that particular host still want to receive the multicast traffic or not.
Now, one of the major drawback with the IGMP version one is there is a periodical query messages sent for every 60 seconds. Now let’s say there is a router here the router one is sending a multicast traffic for three host, host one, host two and host three. And let’s say the host three do not want to receive the multicast traffic. Let’s say I have closed the application. Now maybe you are using some multicast application and once you close the application or once you close the window, it will automatically close the multicast traffic but the router is not aware of this particular user. Don’t no more want the multicast traffic. It’s going to send out a periodical query messages for every 60 seconds and probably these two h one, host one and host two will reply to those query messages but this host three will not reply again.
So it’s going to wait for around 180 seconds before it stops sending the multicast traffic. So which means for 180 seconds it is still sending the multicast traffic for the host three. Now, there is no information. Whenever a host do not want to receive the multicast traffic, he is not going to inform to the router, he simply leave the group silently. So that’s one of the major drawback with the version one that has led to the new version called version two. Now version two is the one which is used more commonly and which is default. Now version two will have something called addition to the leave group message. Now this is one of the major enhancement in the version two when you compare with version one.
Now let’s say I got three receivers, there are two receivers, there is receiver one and the receiver two. Now the receiver two do not want the multicast traffic. In case if you do not want the multicast traffic, if you close the application, multicast application, probably it is going to generate a leave message, IGMP live message informing to the local router saying that I no longer want to receive the multicast traffic and I’m leaving the group as of now. Then the router is going to send out a query for the remaining routers or the remaining host, sorry it’s going to send out a query to the remaining host do you still want to receive the traffic? And then whichever the host replies and the multicast streaming will be sent only to that particular host and it will be stopped for the host who don’t reply.
So that’s one of the major enhancement in the version two which has some live group message from host to router apart from report and query messages. Now we still have those two report and query messages in version two as well, but there is a live message added to that and apart from that the default timers for the timers for the periodical query is 60 seconds. But that can be tunable in the version two. And then we can also do something called query election. Like let’s say if you have more than one router probably you can decide which router to send out the query messages. We have something called configurable parameters to do this. We can configure some query election priority kind of stuff.
And apart from that the query messages are sent to a specific group. Now specific group means let’s say there are some receivers in my land and there are two users who are receiving the multiple traffic for 224 five and there is another group 224 six. Now the query messages can be group specific if you, if you want to send out a query, we are going to send out a query only for this group, not for the other groups. So that’s one more major enhancement in the version two. Whereas in the version one we don’t have live messages and we it doesn’t support query group specific queries as well. Now here you can see the same thing what I discussed here. Whenever a client wants to leave the group they will send IGMP live message to 2240 zero two, that is to the router.
So it’s going to say I want to leave the group. Then the router is going to will query the query out to the remaining routers that sending a query message as long as at least there is one client in the group who wants to receive the multicast traffic, it’s going to forward the multicast traffic for that particular host. Again, the other thing which I discussed is group specific queries. In version one the query is sent to all the host but whereas in the version two the query can be sent only to that particular group, a specific group also. Now, in case of version three, version three there is one more enhancement. We call it as a source specific multicast. Now the source specific multicast allows you to select the multicast server from where you want to receive the multicast traffic.
Now we’ll talk about more in detail about source specific multicast, how it works and how can it can be configured in the lateral sessions. But here I’m just giving you some overview on how it’s going to work. So let’s say I have a group, I have a two servers which are hosting the same multicast group address. Probably I have a server one and I have a server two and this particular two servers are or sending the multicast traffic for, for same group or different group. Now here I can define from which source you want to reach the multicast traffic. I can specifically define that I want the multicast traffic like 234 one, one, two, that’s a group address, multicast class D address. I want to receive the multicast traffic for this group which is hosted by two servers, server and as well as server two.
So just let’s ignore this one, okay? And then now and it is hosted by two different servers, one into 161 one and 182-1612. Now we can specifically define from which source you want to receive the multicast traffic. Now that something can be done if you’re implementing source specific multicast. Now, if I want from this server, you will get the multicast traffic only from that server. Now probably we’ll talk about this more in detail like there is something called S Kamaji where we can define from which source address like 190 to 161 two is the source address of the particular server, the normal layer three address and then the group address 234 one, two.
Now, in general in a normal IGMP version, version two, it works something like this star kamachi, where the group addresses will be 234 one or two and it, it can be coming from any server, it depends. But here you can select a specific source. So when you talk about version three, it supports source specific multicast and there is a special address reserved for source specific multicast which, which comes under 232 range 232 x. Now, IGMP is the protocol which is responsible for host router communication. And the host who want to receive the multicast traffic are going to send a report message that they want to receive the multicast traffic for so and so multicast group address and the router is going to send out a query messages, which is a verification done by the router whether they still want to receive the multicast traffic or not. Now, in that IGMP, we got three different versions.
Version two runs by default and the major difference between these three versions is in the version one there is a periodical checkups and there is no leave message. We can say it’s simple and there is a periodical messages sent by the router, the periodical query messages sent by the router for every 6 seconds. But whereas in case of IGMP version two we have something called leave message, whenever a host want to leave the group, he’s going to send a leave message saying that informing the local router that you don’t want to receive the multicast traffic. Based on that, the router can send out a query to the remaining ones to figure out whether they want or not. And in case of version three it supports a source specific multicast feature where you can get the multicast address from selected source address as well.
2. Protocol Independent Mutlcast-PIM
Now, in this video we’ll talk about pim protocol, protocol independent multicast. Like if you quickly revise what we discussed in the previous sections. In the previous section we have seen some igmp protocol. Now igmp is a protocol which is used to communicate between the host, the receivers and the router. So whichever the receiver wants to receive the multicast traffic, probably they need to join, then send some join messages to the router. And now the question is that router, how it is going to reach the server from where it is expected to receive the multicast routing. Now, the router has to figure out how to reach the server. So which means we need some kind of routing to be done here. And that is what multicast routing comes at a picture here. Now, the multicast routing is done by different protocols.
We can use like distance vector, multicast routing protocol and multicast osf protocol. These two protocols are legacy which are no more used. And in today’s network we generally use something called Pin protocol independent multicast. Now, this Pin protocol is responsible for routing multicast routing or used by the router to figure out how to reach a multicast server or how the multicast traffic should come from the particular server on the van. Now, Pin stands for protocol independent multicast. It provides a loop free router to router communication and it is not going to advertise the routes just like we did in Rap Hrpospo here. We are not going to advise any routes here, but instead it is going to still rely on the igp protocol to figure out a loop free multicast starting.
So it’s going to figure out based on some rpf check. We’ll talk about rpf check more in detail in the next sections and it’s not going to advertise the routes throughout the network like igp. So pim is going to operate in two different modes and there is something called pim dense mode and sparse mode. So let’s try to see the difference between the dense mode and the sparse mode here. Now, the mode exactly tells how the multicast traffic is going to be sent from the sender to receiver. So let’s say I have a sender who is sending the multicast traffic and I got some receivers somewhere here and how the multicast traffic is going to be sent. Now, the pim operates in two different modes. The first one is a dense mode. Dense mode is a simple and very straightforward concept which works based on flattened prune behavior.
So let us get into more in details on how they exactly operate. Now, in case of dense mode the server is going to send, it works with something called implicit join, where all the portion of the multicast network will receive the traffic from all the servers unless you specifically say you don’t want it. Like, let’s say I have a server here. Initially, if this server is sending a multicast traffic for specific group address. Let’s say it’s going to send out of all the interfaces and the router is going to send out of all the interfaces. Again, it will send out of all the interfaces and in case if there is no receiver here, I have no member who wants to receive the multicast from this so and so group, it’s going to send a prune message and then the router will stop the multicast traffic.
Now, that’s what we call as implicit join and it is going to use something called flood and prune behavior where the multicast traffic is initially flooded out of all the ports and if you don’t have a receiver it’s going to be pruned automatically. Now, this design is not really applicable for very large networks because it is something not efficient to send out the traffic everywhere to figure out again where it doesn’t want the traffic. Now, the next mode we have something called sparse mode. Now, in the case of sparse mode it’s not going to work based on flood in four flood behavior. Let’s say I have a receiver here and I have a sender who is sending the multicast traffic server. Now here the router is not going to flood the traffic. Instead they both will join us to something called Randevo point.
Now, we are going to configure something called some router or a device referred as a rando point. Now, this random point is the root of the forwarding path and where all your joint messages will go. And this random point, the rp will decide how the traffic should go from the source to receiver. Now, if you have any receiver who wants to receive the multicast traffic they need to send a join message probably to the rp and the sender will join to this. Now, rp will decide how the traffic has to go between the sender to receiver. So we’ll be getting into some more in details about these modes with a practical verification by enabling it probably just there are two different modes where we can run the protocol pim. Either we can go with the dense mode or sparse mode.
Now the dense mode initially it is going to work with something called flood and prune behavior, where the multicast traffic is initially flooded. And if anyone do not want it’s going to be sent a prune message where the router is going to stop the multicast traffic for that particular group. And that is something not applicable for big size networks. Whereas in case of sparse mode we are going to configures something called randevoo point which is like a route and it’s going to decide how the traffic has to be sent from sender to receiver. Now, it’s like the sender and the receiver has to register themselves with the rp and the rp will decide the actual forwarding path from sender to receiver.
3. PIM Modes – Trees
Now, one major difference between the pim dense mode and the sparse mode is the way it’s forward the traffic. In case of dense mode, it’s going to flood the traffic out of all the ports, means all the device is going to flood. It’s going to work with flood and prone. That’s what we discussed. Once it is flooded, all the routers comes to know about that source address. Like, let’s say the IP address of this server is one eight to 161 one and it’s going to maintain the group address. And the group address, let’s say it is 224 five. Now, each and every device is going to maintain this information on how to reach the server. And probably this router also knows how to reach the server. And if this particular router do not have any host who wants to receive the multicast traffic for this group, it’s going to send a prude message.
But each and every router here knows or exactly maintains S comma g entries where how to reach that particular server if they want to receive the multicast traffic for this particular group. Now, that’s what it uses, something called shortest path to reach that particular server. And this method of this tree or the forwarding path which is built, we call it as a source tree, we call this as a source tree. Now, source tree is the one which it uses the shortest path from sender to receiver based on the flat endpoint behavior which generally happens in your dense mode. Now, in case of sparse mode, also it’s going to use the same way. But in case of sparse mode, if you remember we discussed that it’s not going to do flat and prune.
Instead they are going to register with an rp router and the multicast receiver will join with the rp. And whereas the server also is going to join with rp and the rp is going to maintain the information about both the sender and the receiver. And rp is going to provide the information how the forwarding has to go from sender to receiver. Now, in this kind of scenarios, initially the traffic will be going from the source to the rp and the rp will send it to receiver. And this forwarding of the path or the tree which is built here, we call this as a share tree. Now, Shadery, in simple words, we can say it’s via rp, whereas on the sorts tree it’s going to be is it a shade tree or so? Yeah. So they both look similar in all. So if anything shade tree, probably it’s going to be via rp.
When you say source tree, it’s going to directly go from source to the receiver without any rp. Now, initially, if you’re using sparse mode, initially the traffic is flooded via rp, it’s going to go via rp. But later on, once the receiver knows the source address, probably it uses the shortest path. So if you’re using sparse mode, it’s going to use the shade tree initially that is via rp and then later on it’s going to build the shortest path and it uses sorts tree. But whereas in case of dense mode there is no rp. So probably it’s going to flood traffic where every router is going to maintain as kama G entries. Now, that’s a major difference between how the forwarding happens in the dense mode or the sparse mode.
Now, the dense mode generally uses only uses dense mode generally uses only Sort street, whereas the sparse mode it’s going to use initially source tree, later on, initially it’s going to use shade tree, later on it uses source tree. Now, the major difference here shade tree means it’s via rp. Here the shortest path from Sender to rp and from rp to receiver. And it works only in the sparse mode because we have a rp configuration only comes in the sparse mode. So one of the major advantage in the shade tree is it’s going to eliminate the flooding and the pruning and makes much more scalable. So probably in the production networks we prefer to use sparse mode which is most commonly used. And this pass mode initially uses sort stream and later on it’s going to use Share.
Now, the modes are actually the way the forwarding happens in general, but the actual forwarding like the tree. Now, here the forwarding mechanism we call refer the math trees tree, this source tree and Trace is just the mechanism which it uses, but the actual modes which they operates, we call them as dense mode or sparse mode. Now, probably in our next sections we’ll try to get into more in detail on how the actual forwarding happens. Here, like here, just not discuss the source tree, it just uses the shortest path because all the routers knows the shortest path to the source because it’s going to work based on flood and prone. Whereas in case of shade tree it goes via rb. Now, if you compare these two trees, probably the advantages of the source tree is it’s going to use the shortest path from source to receiver.
But whereas the shade tree it goes via rp. So which means it is not. Carefully we need to consider the rp because the path between the source and the receiver may not be the best path because it is going via rp if we do not place the rp properly. But the disadvantage is the additional overhead because the router has to maintain the path information for each and every source. Whereas Shadery lowers the overall memory requirements here, but at the end we use commonly the sparse mode which uses initially it uses the source tree. Probably later on it fall backs to the shade tree by other shortest path. First it uses the shade tree initially, later on it fall back to the source tree. The shortest path here.
