Configuring IGMP in a Local Area Network
to Control Multicast IPTV Streams
To transmit TV channels over local area networks it is usually used IP multicast. The peculiarity of this technology is that all multimedia streams are always output into the network regardless of the number of subscribers watching TV at the moment. For example, to tramsit 20 TV channels at the average bitrate of 4 Mb/s per channel it is required to have at least ~4*20=80 Mb/s of total bandwidth. These 80 Mb/s are output into the network even if no one of the subscribers is connected.
Multicasting multimedia content into a LAN is concerned with the necessity to strictly control which packets should be delivered and to which
recipient. It is required to avoid the case when all packets are delivered to all subscribers. In this case the client devices are spending their
resources on processing unbidden packets and, as a result, are not able to cope. The subscriber should receive only packets of the stream he has
requested. For that the subscriber's equipment makes a query via IGMP to enter a certain multicast group. After that this request is registered on
the router; in terms of IGMP this device is called "Querier". After successful registration, the Ethernet switch begins copying multicast packets
destined for this group to the port the subscriber is connected to. Due to IGMP, Ethernet switches can determine which multicast packets should
be copied to the subscriber's port and which should not.
In the present article configuring of IGMP in a LAN with Ethernet switch Cisco Catalyst 2950T and a Linux-based DVB to IP gateway, produced by
NetUP, is discussed. The clients' devices used are Amino AmiNET110 IP set-top box and a PC with Windows or Linux OS and multimedia player VLC [1].
IGMP Description
Currently three versions of the protocol exist: IGMP v1 [2], IGMP v2 [3], IGMP v3 [4]. The most popular is version 2.
Format of an IGMPv2 packet:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Message type | Maximum response time | Checksum | |||||||||||||||||||||||||||||
| Multicast group address | |||||||||||||||||||||||||||||||
The group address is a multicast IP address the content is sent to. For example, 224.200.200.205.
For IGMPv2 the following message types exist:
- Group Membership Query
- Membership Report
- Leave Group
Let's examine purpose of these messages in detail. On connecting to an IGMP group, a client device sends an IGMP "Membership Report" packet to the network, i.e. declares that wants to receive packets for the group. On exiting the group the device sends an IGMP "Leave Group" packet. The router (querier) is periodically sending IGMP "Group Membership Query" packet to find out the group membership at the moment. If no response comes from the clients' devices then the router disables the group and sends no more packets for the group.
General Network Layout
Let's examine the work of IGMP on the test stand of NetUP Inc. The general network layout is presented in the Figure 1.
Figure 1. Test stand. General layout of the network for multicasting IPTV using IGMP.
As the IP STB it was used AmiNET110 (Figure 2).
Figure 2. Client's set-top box
By default, after loading the IP STB shows the WEB browser start page and invites to enter an URL. To view the media content broadcast in the multicast group 224.200.200.205 (on the test stand this is a TV channel "Rossiya") it is required to enter the following address:
igmp://224.200.200.205:1234
At that the IP STB sends an IGMP query to join the group 224.200.200.205. If the IGMP works correctly in the network, then the subscriber's device can receive the stream. On pressing "Esc", the IP STB stops playing the stream. At that, an IGMP query to leave the group is sent.
From the position of IGMP, VLC works similarly to the IP STB AmiNET110.
Capable of intercepting and analyzing IGMP packets. This feature is called "igmp snooping". This is the analysis of passing IGMP packets that lets the switch know the ports the subscribers are connected to and to which groups the subscribers belong.
To enable this option it is required to enter the following commands in the switch settings:
catalyst2950#configure terminal catalyst2950(config)#ip igmp snooping
To analyze the work of "igmp snooping" on the switch, the following commands can be used:
catalyst2950#debug ip igmp snooping catalyst2950#terminal monitor
At that moment the switch outputs to the console the data on intercepted IGMP packets, and also the information on the actions that were attempted. For example, receiving of IGMP message from a client to join the group 224.200.200.205 looks as follows:
9w3d: IGMPSN: group: Received V2 report for group 224.200.200.205 received on Vlan 1, port Fa0/2 9w3d: IGMPSN: group: Adding client ip 10.1.2.16, port_id Fa0/2, on vlan 1 for proxy reporting 9w3d: IGMPSN: group: Created group 224.200.200.205 9w3d: IGMPSN: group: Added port Fa0/2 to group 224.200.200.205
As it can be seen from these debug messages, the switch recorded the joining of the subscriber 10.1.2.16 connected to the port Fa0/2 to the group 224.200.200.205. According to this information, now only packets for 224.200.200.205 come to the port Fa0/2.
On exiting the group the console displays the following messages:
9w3d: IGMPSN: group: Leave for group 224.200.200.205 received on Vlan 1, port Fa0/2 9w3d: IGMPSN: group: Adding client ip 10.1.2.16, port_id Fa0/2, on vlan 1 for proxy reporting 9w3d: IGMPSN: group: Created leave port on port Fa0/22, for group 224.200.200.205 on Vlan 1 9w3d: IGMPSN: timer: Vlan 1, group 224.200.200.205, port Fa0/2 leave port timer expired 9w3d: IGMPSN: group: Deleting leave port on port Fa0/2, for 224.200.200.205 on Vlan 1 9w3d: IGMPSN: group: Deleting port Fa0/2 from group 224.200.200.205 on Vlan 1 9w3d: IGMPSN: group: Deleting group 224.200.200.205
As it can be seen from these messages, the switch excluded the subscriber from the group 224.200.200.205 and also deleted the group, as fat as there left no more active subscribers in the group.
It is noteworthy that the switch only analyzes passing IGMP packets. It doesn't act as a router (querier). For these purposes it is required to set up a Cisco router or to use a Linux-based server with the package 'mrouted'.
One more important detail is that "igmp snooping" wasn't set, the switch sends all multicast packets to all ports. If the number of streams is high, this can cause overloading of the client set-top boxes connected to the switch. From the experience of NetUP specialists, a multicast stream ~20 Mbps is able to hang some wireless access points, that is certainly inadmissible. That is why disabling of IGMP in the network should be avoided.
This device, produced by NetUP, is a high performance all-in-one DVB receiver, decoder and IP streamer. As a source of multimedia data it can be used satellite channels (DVB-S), analog video inputs for video cameras (RCA-in), transport streams (ASI-in) and etc. The outputs are two Gigabit Ethernet ports for sending formed transport streams into the IP network. The packets are streamed in the multicast mode.
The streamer is built on basis of Linux OS. Due to this it's possible to set up additionally required services. As it was mentioned above, the switch doesn't perform routing of multicast packets (i.e. the switch is not a querier), that is why this function is given to the streamer. For that the package 'mrouted' should be installed and started. The configuration file /etc/mrouted.conf can be kept with the default values. It is noteworthy that two network interfaces should be enabled in the system, otherwise the process 'mrouted' won't start.
The current state can be checked by sending the signal USR1. For that use the command:
kill -USR1 `cat /var/run/mrouted.pid `
As a result, the process "mrouted" writes the current state to the file /var/tmp/mrouted.dump. An example of the file content is below:
mrouted version 3.9-beta3 up 0:08:30 Sat Jul 7 14:44:07 2007
vifs_with_neighbors = 0
Virtual Interface Table
Vif Name Local-Address M Thr Rate Flags
0 eth2 10.1.11.10 subnet: 10.1/16 1 1 0 querier leaf
group host (time left): 224.200.200.205 10.1.2.16 ( 0:04:15)
224.200.200.150 10.1.4.233 ( 0:03:40)
224.0.0.4 10.1.11.10 ( 0:03:39)
224.0.0.2 10.1.11.10 ( 0:03:39)
IGMP querier: 10.1.11.10 (this system)
Nbr bitmaps: 0x0000000000000000
pkts/bytes in : 2773302/3593651956
pkts/bytes out: 0/0
1 eth3 172.16.16.16 subnet: 172.16.16/24 1 1 0 querier leaf
group host (time left): 224.0.0.4 172.16.16.16 ( 0:03:44)
224.0.0.2 172.16.16.16 ( 0:03:44)
IGMP querier: 172.16.16.16 (this system)
Nbr bitmaps: 0x0000000000000000
pkts/bytes in : 0/0
pkts/bytes out: 0/0
Multicast Routing Table (2 entries)
Origin-Subnet From-Gateway Metric Tmr Fl In-Vif Out-Vifs
172.16.16/24 1 110 .. 1 0*
10.1/16 1 110 .. 0 1*
As it can be seen from the file, on the interface eth2 there is a multicast group 224.200.200.205 with the subscriber 10.1.2.16 included.
In case there are two or more IGMP queriers in the network, the role of querier takes the one with a lower IP address. Due to this logic it is possible to duplicate the functions between two or more multicast routers for better fault tolerance.
Correctness of work of IGMP can be checked on an Ethernet switch Cisco Catalyst. For that use the following commands:
catalyst2950#show ip igmp snooping querier Vlan IP Address IGMP Version Port --------------------------------------------------- 1 10.1.11.10 v2 Fa0/1 catalyst2950#show ip igmp snooping group Vlan Group Version Port List --------------------------------------------------------- 1 224.200.200.205v2 Fa0/2
According to the output of these commands, the switch has correctly found the router (querier) and presence of the group224.200.200.205 in the network. Also, the subscriber connected to the group and his port is shown. Hence the packets for the group 224.200.200.205 are sent only to this port. Packets for other multicast groups are deleted on the switch and are not sent to any of the ports, as there are no more active subscribers.
Noteworthy is that the streamer sends all channels into the network, regardless of the number of active subscribers. The streams can be checked by using the following command on the streamer:
/usr/bin/trafshow -ni eth2 port 1234
The output contains the table of active multicast streams, bitrate and number of transferred bytes:
From Address To Address Proto Bytes CPS ================================================================================== 10.1.11.10..32795 224.200.200.202..1234 udp 8537028 375494 10.1.11.10..32788 224.200.200.212..1234 udp 7952044 407992 10.1.11.10..32790 224.200.200.209..1234 udp 7094228 279341 10.1.11.10..32787 224.200.200.213..1234 udp 7043440 351231 10.1.11.10..32784 224.200.200.210..1234 udp 7008084 280157 10.1.11.10..32782 224.200.200.215..1234 udp 6508896 314706 10.1.11.10..32785 224.200.200.207..1234 udp 5925792 231584 10.1.11.10..32794 224.200.200.200..1234 udp 5906572 200676 10.1.11.10..32793 224.200.200.211..1234 udp 6047448 326328 10.1.11.10..32796 224.200.200.205..1234 udp 5881424 306071 10.1.11.10..32783 224.200.200.216..1234 udp 5758480 393428 10.1.11.10..32798 224.200.200.201..1234 udp 5570160 321016 10.1.11.10..32797 224.200.200.204..1234 udp 5365592 284411 10.1.11.10..32791 224.200.200.217..1234 udp 5195216 207687 10.1.11.10..32786 224.200.200.206..1234 udp 5297696 296824 10.1.11.10..32799 224.200.200.203..1234 udp 4779076 203542 10.1.11.10..32792 224.200.200.214..1234 udp 3279980 161183 10.1.11.10..32789 224.200.200.208..1234 udp 3144896 131500 10.1.11.10..32800 224.200.200.250..1234 udp 512616 22896 10.1.11.10..32801 224.200.200.251..1234 udp 364532 28590 (eth2) 100217 kb/total 4057 pkts/sec 5250733 bytes/sec Page 1/1
As it can be seen in the output, the streamer constantly broadcasts 20 streams (18 TV channels and 2 radio stations). At that, as it was said earlier, the number of active subscribers can eventually vary. Due to IGMP each subscriber receives only the stream he requested.
In case of using a Cisco router (on the stand of NetUP Inc it was used Cisco 7140-2FE, IOS 12.3) the routing of multicast streams can be enabled by using the following commands:
c7140(config)#ip multicast-routing c7140(config)#interface FastEthernet0/0 c7140(config-if)#ip pim sparse-mode c7140(config-if)#ip igmp version 2
The multicast groups can be checked by using the command:
c7140#show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.200.200.150 FastEthernet0/0 00:02:40 00:02:59 10.1.2.37 224.200.200.205 FastEthernet0/0 00:02:41 00:01:53 10.1.4.233
References
- VLC project - http://www.videolan.org
- IGMPv1 RFC - http://tools.ietf.org/html/rfc1112
- IGMPv2 RFC - http://tools.ietf.org/html/rfc2236
- IGMPv3 RFC - http://tools.ietf.org/html/rfc3376