The History Of The Multicast Communication Mode

Published Date: 02 Nov 2017

Multicasting is type of communication between computer networks that enables a user to send one stream of data to many end users without interrupting users that are not interested. In other words multiple users may tune to same stream of data in a transmitted network by using multicast medium access control and Internet protocol. For these reasons multicasting has become more popular for the transmission of multimedia and distributed application which typically uses lots of bandwidth.

Multicasting does not only optimizes the performance of the network, but also provides enhanced efficiency by controlling the traffic on the network and reducing the loads on network devices. Multicasting uses simultaneous delivery for a group of receivers when required.

1 INTRODUCTION

Multicasting solves the problem of scenario one to many communication. We can accomplish one to many communications with the help of unicast model, but problem occurs. If host A wants to send a packet to ten hosts using unicast model then in this case host A would needs to send same packet to ten different addresses, as shown in the Figure 1.1. As the number of receivers increases more and more packets needs would to be send which cause depletion in the bandwidth.

Figure 1-1 Unicast model to achieve one to many comm. [Parkhurst 1999]

On the other side one to many communication can be achieved via broadcast model but the problem still occurs because every host would needs to be process Ethernet frame in order to determine that if frame is intended for the host or not. There would be wastage of processing time and wastage of bandwidth of network for those hosts which are not expecting data.

In the multicasting model, two types of addresses are used, IP multicasts address and an Ethernet multicast address. A group of receivers identifies by an IP multicast address that want to receive traffic destined for the group and all IP packets are encapsulated in the Ethernet frames, that’s why multicast Ethernet address is required. Those hosts are assigned for same multicast IP address and multicast Ethernet address would receive same multicast traffic, which would greatly reduce the traffic, which results in efficient use of bandwidth of networks as shown in Fig1.2.

Figure 1-2 Multicast Communication Model [Parkhurst 1999]

Summary

IP multicast is a much more efficient means of delivering content where a single sender needs to deliver the content to multiple receivers. This task may be achieved through the use of multicast groups.

2 MULTICAST GROUP ADDRESSES

A multicast group address is the combination of the high-order (MSB) 4 bits of 1110 and multicast group ID. Multicast addresses are in the range 224.0.0.0 through 239.255.255.255.The format of a class D IP address shown in Figure 2.1.

Figure 2-1 Format of class D IP address [Stevens 1994]

Some multicast group addresses are assigned as well-known addresses by the IANA (Internet Assigned Numbers Authority). These are called permanent host groups. For example, 224.0.0.1 means "all systems on this subnet," and 224.0.0.2 means "all routers on this subnet."

2.1 Converting Multicast Group Addresses to Ethernet Addresses

The Ethernet addresses corresponding to IP multicasting are in the range 01:00:5e:00:00:00 through 01:00:5e:7f: ff:ff.

The allocation allows for 23 bits in the Ethernet address to correspond to the IP multicast group ID. Mapping of low-order 23 bits of the multicast group ID into these 23 bits of the Ethernet address. This is shown in Figure 2.2(a) and Figure 2.2(b).

And the upper 5 bits of the multicast group ID are ignored in this mapping. Thirty-two different multicast group IDs are map to each Ethernet address. For example, the multicast addresses 224.128.64.32 (hexe0.80.40.20) and 224.0.64.32 (hex e0.00 40.20) both map into the Ethernet addresses 01:00:5e:00:40:20.

Figure 2-2(a) Mapping of a class D IP address into Ethernet multicast address [scrib.com]

Figure 2-2(b) Mapping of a class D IP address into Ethernet multicast address [scrib.com]

The mapping in between 48-bit Ethernet address and class D IP address is not one-to-one. Multicasting is better than broadcasting, despite this imperfect hardware filtering, and address mapping.

2.2 Multicasting on Physical Network

Destination IP address that is a multicast address specifies by sending process and driver converts multicast address into corresponding Ethernet address, and sends it. For a given multicast address the receiving processes must notify their IP layers. When a multicast datagram is received by a receiver, it must deliver a copy to all the processes that belong to that multicast group.

2.3 Summary

A class D IP address is called a multicast group address. It is converted to an Ethernet address by placing its lower 23 bits into a fixed Ethernet address. The mapping is not unique, requiring additional filtering by one of the protocol modules.

3 INTERNET GROUP MANAGEMENT PROTOCOL

To support multicasting the Internet Group Management Protocol (IGMP) is used between hosts and routers. IGMP is the mechanism used by hosts on a network to which multicast group(s) the host wants to either join or leave. Multicast routers use IGMP to determine if any members of the multicast groups are located on any of their attached networks. Multicast routers can then join a particular multicast group, if group members are present and forward multicast traffic to hosts that have joined the group(s).

IGMP messages are transmitted in IP datagrams. IGMP has a fixed-size message. Figure 3.1 shows the encapsulation of an IGMP message within an IP datagram.

http://i.technet.microsoft.com/dynimg/IC195370.gif

Figure 3-1 Encapsulation of an IGMP message within an IP datagram [TechNet. Microsoft]

3.1 IGMP Message

Figure 3.2 shows the format of the 8-byte IGMP message.

http://www.cisco.com/warp/public/cc/techno/tity/ipmu/tech/ipcas_dg/ipcas_d7.jpg

Figure3-2 Format of IGMP message [cisco.com]

Type of 1 is a query sent by a multicast router.

Type of 2 is a response sent by a host.

The default TTL value is 1 to prevent the IGMP traffic from leaving the host's network. The host has the responsibility only transmit multicast traffic on one of the directly connected networks and routers have the responsibility of forwarding multicast traffic to other networks.

A host implementation must not only examine the Ethernet address of the received multicast Ethernet frame at layer 2 but must also examine the multicast IP address at layer 3 to determine if the packet is destined for a group that the host has joined.

3.2 IGMP Protocol

Membership in a multicast group on a given interface changes over time as processes join and leave the group. A host keeps a table of all the groups that at least one process belongs.

When a host decides to join a multicast group, it does not know if any other hosts are on the networks that are members of the group. If this host is the first member and the host waits for a Host Membership Query from the router, the host will wait forever. Therefore, when a host decides to join a multicast group, it should immediately send a Host Membership Report. The query message send by router shown in figure 3.3 and report send by host shown in Figure 3.4

Figure 3-3 IGMP Host Membership Query messages [Garbani]

Figure3-4 IGMP Host Membership Reports [Garbani]

3.4 Internet Group Management Protocol, IGMP Version 2

IGMP version 2 messages have the format shown in Figure 3-5.

https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQ2ZxRm-m8lkp5RgRWoQejkXnP9rmlCknh2WsN6jbR_i9RtjVjGcg

Figure 3.5 IGMP version 2 format [cisco.com]

Membership Query messages of type 0X11, are in two types. The first is a General Query which is used to determine which groups on a network have active members. The second is a

Group-Specific Query which is used to determine if a particular multicast group has active members.

In IGMP version 2, there is a feature added that enables routers to determine which router is responsible for sending Membership Query messages with the other routers becoming Non-Query routers.

When a host receives a General Query message from the router, the host sets a delay timer for each multicast group of which the host is a member. These delay values are chosen at random from the range 0 to Maximum Response Time (specified in the IGMP version 2 packet), and the value zero is not used. If any of these timers counts down to zero before the host has heard a Membership Report for a particular group, the host sends a Membership Report to the multicast group. If a host receives a Membership Report from another host for a group that the host is a member, the timer and report for that group is canceled. If a host receives a Membership Query for a group that the host already has a timer running, the timer is reset only if the remaining value of the timer is greater than the value of the Maximum Response Time contained in the IGMP packet.

When an IGMP-enabled multicast router receives a Membership Report from a host, the router checks the table of multicast groups for which the router is forwarding multicast traffic. If the group being reported by the host is not in the router's table, the router adds this group to the table. For each multicast group in the router's table, a periodic timer is set to the value Group Membership Interval. Whenever a router receives a Membership Report from a host for a multicast group, the timer associated with that group is reset to the value Group Membership. When the Group Membership Interval timer counts down to zero, meaning that no

Membership Reports have been received from a host during this time period, the router assumes that hosts on the network no longer want to receive multicast traffic for that particular group, and the router does not forward multicast traffic for it.

3.5 Summary

IGMPv2 is a protocol used by multicast clients to join a multicast group.

4 CISCO GROUP MANAGEMENT PROTOCOL

The Cisco Group Management Protocol (CGMP) is a proprietary layer 2 protocol that is used between Cisco routers and switches to limit multicast traffic on a virtual LAN (VLAN). To limit multicast traffic Layer-three multicast routing protocols are used to networks that have receivers which have indicated their desire to receive the traffic.

In Figure 4-1, one of the hosts on VLAN 1 is now a multicast sender and one host from VLAN 2 has joined the multicast group using IGMP. What will happen when the source sends a multicast packet?

Figure 4-1Forwarding of multicast traffic on VLANs [Parkhurst 1999]

VLAN 2 did not receive the broadcast traffic from VLAN 1. The problem is that the switch (at least for now) treats multicast traffic like it was broadcast traffic, but the router does not. Therefore, the multicast traffic on VLAN 1 is forwarded to all hosts on VLAN 1 and the router. The router has state for the multicast group on VLAN 2 because there is a receiver on VLAN 2. The router forwards the multicast traffic to VLAN2, which treats the traffic as a broadcast and forwards it to every host on the VLAN

In Figure 4-2, it looks as if the host is sending the IGMP packets directly to the router and by passing the switch. This is a logical diagram and, of course, the IGMP packet must pass through the switch. The diagram shows that IGMP is a protocol used between hosts and routers, and CGMP is the protocol used between routers and switches. The fundamental operation when using IGMP and CGMP is as follows:

1. A host sends an IGMP Join to the router for a particular IP multicast group.

2. The router, if CGMP is enabled, sends a message to the switch containing the unicast Ethernet address of the host and the multicast Ethernet address of the group the host is joining.

3. The switch, if CGMP is enabled, installs the entry in the CAM table.

Figure 4-2 Logical relationship between IGMP and CGMP [realccielab.org]

The format of a CGMP packet is given in Figure 4—10.

Figure 4-10 CGMP packet format [realccielab.org]

5 DISTANCE VECTOR ROUTING PROTICOL

In this chapter, we will begin with multicast routing protocols, which are designed to efficiently determine a path from multicast sources to multicast receivers.

5.1 Reverse Path Forwarding

If the destination address is a multicast or Class D IP address multicast—there may be multiple receivers with the same address, possibly on different networks, as shown in Figure 5.1. Host that wants to receive multicast traffic for group 225.65.10.154 will use IGMP to inform the local router using a Join message. When the multicast packet reaches router A, the router determines that the packet is multicast because the address is Class D. The IGMP table is consulted and router A sees that at least one host on a directly attached network (172.16.2.0) has joined the group so the packet is forwarded onto that network. If downstream hosts are to receive the multicast traffic, then router A must forward the traffic on the serial interface and so must router B. If there are no downstream receivers, then it does not make sense for router A to forward the traffic to B because this is a waste of valuable bandwidth.

Figure 5-2 Routing of a multicast packet from source to receivers

Therefore, a multicast router needs a mechanism to determine on which interfaces to forward multicast traffic. One method is to simply forward the multicast traffic out all interfaces except for the interface on which the traffic was received. What could possibly go wrong? The network in Figure 5.2 illustrates a problem that can occur if multicast traffic is simply forwarded out all interfaces except for the one on which the traffic was received:

1. The sender sends a multicast packet to router A.

2. Router A forwards the traffic to routers B and C.

3. Routers B and C forward the traffic to router D and to the attached receivers.

4. Router D forwards the traffic to the receiver and then back to routers B and C.

This is probably not a good idea.

Figure 5-3 Formation of a multicast routing loop

A multicast routing protocol examines both the source and destination IP addresses when a forwarding decision is being made. The destination address, along with the IGMP table, is used to determine if any hosts require the traffic on a particular interface. The RPF technique is used to see if the multicast packet was received on the interface that would be used to send a unicast packet to the source. If the multicast packet was received on the interface that would be used to forward a packet to the source, then the multicast packet is forwarded out the appropriate interfaces. If the multicast packet was not received on the interface that would be used to send a packet to the source, then the multicast packet is discarded. Figure 5-4 shows the flow of multicast packets when RPF is employed.

The router interface that is the RPF back to the source is indicated for each router. Router D has two equal paths back to the multicast source, one through router B and one through router C. We will assume that the interface back to router B is chosen as the RPF interface. Soon we will see how a particular interface is chosen as the RPF interface.

With RPF, the sequence of events in Figure 5-4 is as follows:

1. The multicast source sends a packet to router A.

2. Router A determines that the multicast packet was received on the RPF interface; thus, router A forwards the packet out all interfaces except for the one on which the packet was received.

3. Routers B and C receive the multicast packet on their RPF interfaces, so the packet is forwarded out all interfaces except for the one on which the packet was received.

4. Router D receives the multicast packet on two interfaces but only accepts the packet from the

RPF interface. Router D then forwards the packet out the interface to router C and the interface to the attached receiver. However, router C rejects the multicast packet from router D because it did not arrive on the RPF interface.

Figure 5-4 Using Reverse Path Forwarding (RPF) to eliminate multicast routing loops [William1999]

5.2 DVMRP Operation

The basic operation of DVMRP consists of four processes.

1. Neighbor discovery

2. Route exchange

3. Networks are added to the forwarding list using Graft messages. (DVMRP Grafting)

4. Networks are removed from the forwarding list using Prune messages. (DVMRP Pruning)

5.2.1 Neighbor discovery

The purpose of neighbor discovery is to locate other DVMRP routers that are directly connected in order to determine the capabilities of neighbor routers and to enable a keep-alive function. Routers that have tagged a neighbor as down are required to follow the actions listed in the following steps.

Any routes that have been learned from the dead neighbor are placed in the hold-down state.

2. If traffic was being forwarded to this router (it was a down-stream router), then this dependency should be removed.

If the dead neighbor was the designated forwarder on a multi-access network, then a new designated forwarder needs to be elected.

If the dead neighbor was an upstream router, then forwarding entries must be flushed.

If Grafts from this neighbor need to be acknowledged, then they can be canceled.

6. If the neighbor is the last downstream router on the interface and no other receivers are on the network, then the interface should be pruned.

http://www.cisco.com/en/US/i/000001-100000/40001-45000/45001-45500/45145.jpg

Figure 5-5 Networks to illustrate the DVMRP neighbor discovery process [cisco.com]

5.2.2 DVMRP Route Exchange

DVMRP initially advertises directly connected networks. As other networks are learned through the route advertisement process and routes are added to the local DVMRP routing table, more routes may be advertised. The processing of DVMRP route reports is much more complex than RIP route processing. The rules that follow dictate how a DVMRP router will treat the routes received in a route report:

If the route is received from a neighbor, then accept it. If the route report is received from a router for which a two-way adjacency was not established (not a neighbor), then reject the route report.

If the metric of a route in the report plus the metric of the receiving router is greater than or equal to infinity (32), then set the metric to infinity (32).

If the metric of a route in the report is greater than or equal to infinity, then no change to the metric will be made (we will see why).

If a route is not in the routing table (a new route) and the metric plus the metric of the receiving router is less than infinity (32), then the route is added to the routing table.

If a route is in the routing table, then another set of rules comes into effect.

5.2.3 DVMRP Pruning

DVMRP uses prunes and grafts to dynamically alter the structure of the source-based trees. Prune Message format shown in Figure 5.6

Figure 5-6 Prune Message format [ip-multicasting.pdf]

Prunes are also necessary when hosts need to receive multicast traffic on an attached network.

The actions that a router must take when a Prune message is received are as follows:

If the Prune is received from a router that the receiving router has not formed a two-way adjacency with, then discard the message.

Examine the Prune message and determine if the message is the proper format.

If the Prune message does not apply to source information active on the router, then discard the message.

If the neighbor that sent the prune is not a dependent neighbor for the network to be pruned, then discard the message.

If there is an active Prune from this neighbor for the indicated source network and group, then reset the timer to the value received in the Prune message.

If there is not an active Prune from this neighbor for the indicated source network and group, then set a time-out using the value in the Prune message.

If all dependent downstream routers on this network have been sent Prunes, then determine if any group members are on the network. If there are no group members, then send a Prune message to the upstream router.

The actions a router must take when sending a prune are as follows:

If the upstream router cannot receive Prunes, then do not send a Prune. This can be determined from the neighbor's DVMRP version and capabilities.

If any Graft messages need to be acknowledged, cancel them.

5.2.4 DVMRP Grafting

Grafting is the opposite of pruning. Graft messages are sent upstream until they reach the source tree for the particular multicast source and are acknowledged at each hop. Graft messages are sent under the following conditions:

If a host joins a multicast group (using IGMP) on a network that has been pruned for that group.

A DVMRP router is enabled on a pruned network and is dependent on the upstream router.

A router on a pruned network restarts.

If a Graft acknowledgment is not received for a previous Graft message.

The format of the Graft and Graft acknowledgment packets are shown in Figures 5-7.

Figure 5-7 Graft Message format [ip-multicasting.pdf]

6 PIM— DENSE MODE AND SPARSE MODE

PIM-DM relies on the configured unicast routing protocol. This means that you can use any of the IP routing protocols (RIP, IGRP, EIGRP, or OSPF) with PIM-DM. A dense mode protocol operates in an environment where the multicast sources and multicast receivers are located in the same area, such as a local area network (LAN). PIM-DM is independent of the IP routing protocol chosen to run on your network, hence the name, Protocol Independent Multicast. This also means that in the same network DVMRP and PIM could possibly construct divergent source based delivery trees. PIM-DM is, in some ways actually, dependent on the selected unicast routing protocol since the source based delivery tree can be different depending on the protocol used.

6.1 Working of PIM in Dense Mode

According to the figure 6-1 Router A receives a multicast packet from the source and examines the source IP address of the packet to see if the packet was received on the Reverse Path Forwarding (RPF) interface. The RPF interface is used to send a unicast packet back to the source. Because the source is directly attached to router A, the interface is the RPF. Router A then floods the packet on all interfaces except for the interface on which the packet was received. When router B receives the packet from router A, router B will determine if the packet was received on the RPF interface for the particular source. The packet passes the RPF test and so the packet is forwarded to router C and receiver 1. Router C performs the same RPF on the packet and forwards the packet to router B and receiver 2. When B receives the packet from C and C receives the packet from B, the RPF test fails since the packet was not received on the interface that is on the shortest path back to the source. The packet is then discarded. If we take a close look at Figure 6-1, we can see that we have a source tree for each receiver that connects each receiver to the source.

Figure 6-1Dynamically created source-based trees [William]

6.2 Packet Forwarding

When a PIM-DM router receives the initial multicast packet from a source, the packet is flooded onto all interfaces in the output interface list. The output interface list is populated with those interfaces on which neighbors were discovered or on interfaces that have multicast receivers that have indicated their desire to receive the traffic using IGMP. Figure 6-9 shows the various possibilities for forwarding of multicast traffic. Router A has discovered a PIM-DM neighbor on interface S0. A host has signaled that it wishes to receive multicast traffic for a particular group. The host doesn't care where the multicast traffic originates, so any packets for this group from any source reaching router A will be forwarded to the host on E0. PIM-DM uses whatever IP routing protocol has been configured on the router to determine the RPF technique. We will see how to deal with situations involving a network running more than one IP routing protocol.

6.3 Pruning

When the output interface list for a particular interface becomes null, there are no downstream PIM-DM routers or multicast receivers attached to the network. The interface does not need to transmit multicast traffic and can, therefore, be pruned from the source-based delivery tree. In Figure 6-13, router A initially receives multicast traffic from the source and floods the traffic onto all interfaces. Router B is a PIM-DM-enabled router, but has no attached downstream PIM-DM routers or multicast receivers. Router B will send a prune message to its upstream router for this particular multicast source. When router A receives the prune from router B, router A's list for the serial link will become null, halting the forwarding of multicast traffic to router B. The packet format used for Prune, Join, or Graft messages is illustrated in Figure 6-2.

http://technet.microsoft.com/en-us/library/Bb742462.pimsm220_big(l=en-us).gif Figure 6-2 PIM Join/Prune Packet Format [tech.net]

6.4 Grafting

PIM-DM graft messages are the only messages that are acknowledged. The graft messages are acknowledged using the packet format shown in Figure 6-3. Pruned from the list for a router interface can be added back into the source-based tree for a multicast source using PIM-DM graft messages. Router A is forwarding multicast traffic to router B (step 1). Since router B has no downstream PIM-DM neighbors or multicast receivers, router B sends a prune message to router A (step 2). The list for the S1 interface on router A is now null and a prune timer has been set using the timer value in the prune message. If a multicast receiver attached to the Ethernet on router B wishes to receive traffic, an IGMP join message is sent to router B (step 3). Router B can either wait for the prune timer on router A to expire, which will cause router A to add interface S1 to the list for the source, or router B can send a graft message to router A (step 4). The serial interface on router A is in the prune state for the source and has a prune lifetime timer running.

Figure 6-3PIM-DM interface pruning and grafting message flow.

Prunes have a limited lifetime, router B would again be sent multicast traffic from router A. Router B would again send a prune to A, which would timeout, and cause A to forward to B. This triggers a prune, and so it goes. If you are certain that multicast traffic does not need to go to a particular router, then don't enable PIM-DM on the interfaces.

6.5 Sparse Mode

PIM-SM cannot be used in a LAN environment but implies that sparse mode protocols operate more efficiently over Wide Area Networks (WAN). Dense mode protocols, on the other hand, use a broadcast and prune methodology, whereas multicast routers assume everyone wants to receive multicast traffic. Under this model, traffic from a multicast source is sent on all downstream interfaces until an interface is pruned from the multicast tree. An interface has a limited prune time, after which the interface is grafted back onto the multicast delivery tree and multicast traffic is again flooded onto the network. Sparse mode protocols use an explicit join model in which multicast traffic is only forwarded onto an interface if receivers downstream have joined the group. Dense mode protocols, however, use source trees that are dynamically created for each source using the Reverse Path Forwarding (RPF) technique. PIM-SM uses shared trees for the delivery of multicast traffic. A shared tree contains a central point to which all senders of a particular multicast group send their traffic 1). Each sender routes traffic along the shortest path to the central point, which then distributes the traffic to all receivers of the group along the shortest path. The group central point in PIM-SM is referred to as the Rendezvous Point (RP). Multiple RPs can exist in network, but there should only be one RP for a particular multicast group. PIM-SM version one has a mechanism called Auto-RP and PIM-SM version 2 uses candidate RP advertisements. All the PIM-SM routers know the location of the RP. As with PIM-DM, the trees are constructed by using the routes in the unicast routing table.