A Study of Multicast Routing on IPv4 and IPv6 (Protocol) in LAN Networks

A Study of Multicast Routing on IPv4 and IPv6 (Protocol) in LAN Networks

Alok Sahu

Research Scholar, MGCGV Chitrakoot Satna M.P

2Dr. Bharat Mishra,

Associate Professo, MGCGV Chirakoot Satna M.P

Abstract- Multicast is an important term between network to network communication and routing decides the network path. Network communication depends upon the protocol category. A major issue is that always occurs in multicast communication. In this paper analysis configure IPv4 and IPv6 via an experimental with multicast tools. In developing world of technology, multimedia applications and voice/video conferencing are fast verdict their ways into the Internet and commercial networks [2,3]. Multicast routing protocols run over unicast routing protocols to provide efficient routing of such applications. This paper is aimed at understanding how the changeover from IPv4 to IPv6 would impact multicast routing. The multicast routing protocol-(PIM SM)/IGMP were used over both IPv4 and IPv6 networks.

Keywords- IGMP, PIM-SM, IGMP, IPv4, IPv6

1. INTRODUCTION:

   The Internet has grown extremely over the last few years. Large numbers of users subscribe to online multimedia services such as video streaming. Information exchange can broadly be classified as unicast (one-to-one), broadcast (one-to-all) and multicast (one-to-many) [1]. In unicast routing, the server sends out a packet to each of the receivers [20]. It is a one-to-one-of-many distribution. A protocol was always major pillar in the flow controls of packet in the network [15]. It observes some challenges in

   the flow of packets using different versions IPv4 and IPv6.It analyzed the packet flow with IPv4 and IPv6 with a experimental setup using Jperf-2.0.2. In this setup expressly using protocol Independent Multicast (PIM) is the multicast routing protocol preferred by most enterprise network administrators, since it is independent of the underlying multicast routing protocol in the network [9]. This network was maintained by IPv4 network and IPv6 network.

2. IPV4 MULTICAST WITH IGMP

   In IPv4, host membership to multicast group(s) is governed by the Internet Group Management

   Protocol (IGMP) [4]. The switches that the hosts connect to should have IGMP enabled (fig. 1). The multicast querying router is a chosen router on the network that periodically sends out group membership queries to all hosts connected to its local network [6]. Any host that is interested in joining a multicast group sends a join request or membership report to that group. Any traffic destined to that multicast group address is then sent to the host. IP multicast is very dynamic and any host can join or leave a group at any time [12]. A querying router need not be aware of all the hosts that belong to a fastidious multicast group.

3. EXPERIMENTAL SETUP

   The hardware used for the lab experiments is as in the table below:

   Figure 1: Wire-shark capture showing IGMPv2 Membership Report

   From the circled portions, it can be seen that the host 192.168.1.2-255 sends a membership report to the multicast group 239.255.255.250.

   Table 1: Hardware setup

   Device	Quantity
   Router	(CISCO 891-24X- ROUTER)-01
   D-Link 10/100 Mbps Switches	D-Link -05 Ports-01
   Windows 7/Window Server 2008	02

   The lab setup consisted of connecting one Cisco 891 routers back-to-back using serial connections. Net-Gear switch connected to the fast Ethernet interface on Routers. Router, PCs connected to it via the switch. One of the PCs was the source of the multicast traffic and other hand second PCs is receiver. PIM-SM was configured on all the

   interfaces on all four routers. Jperf-2.0.2 was used as the multicast traffic generator. The throughput and jitter were obtained using jperf, the Java based graphical front-end of iperf. For each scenario, jperf was run for ten 10-minute periods and two 1-hour periods. For each test, jperf was transmitting 122 Kbytes per second at 1000 kbps.

   In jperf-2.0.2 terminology, the client is the source of the multicast traffic and the servers are receivers of the multicast traffic. Also, it should be noted that the receivers have to join the multicast group before the source starts sending traffic, so that each of the receivers receives all the multicast traffic that was sent by the source and there is no packet loss.

4. EXPERIMENTAL SCENARIOS: IT CONDUCTED IN TWO DIFFERENT SCENARIOS

1. The present IPv4 networks

2. The anticipated future IPv6 networks.

   1. IPv4 only network

      The network diagram and the IP addressing scheme for the IPv4 only network were as depicted in the figure 2 below:

      Figure 2: IPv4 only network diagram

      The source of the multicast traffic was 192.168.1.1 and the other three PCs were the receivers 192.168.1.2-255.The time-to-live (TTL) on the source was set to 10.

   2. IPv6 only network

   The IPv6 network connectivity and addressing scheme are shown in the figure 3 below:

   Figure 3: IPv6 only network diagram

   The source of the multicast traffic was 2001:175::10 and the other second PCs were the receivers. The time-to-live (TTL) on the source was set to 10.

   1. EXPERIMENTAL RESULTS AND ANALYSIS

      1. IPv4 only network Throughput and Jitter

         From the output obtained from jperf-2.0.2, it was seen that in all the ten 10-minute test periods there was no packet loss and the throughput was 100%. The jitter showed some variation. The jitter varied from 0 ms in some tests to a maximum of 7.792 ms.

         The multicast group address is 239.255.255.250 to which the local host (10.10.20.10) binds. The graphical output from jperf was captured at different points during the 10- minute period. It provides a real-time graph of the bandwidth and jitter (fig. 4).

         The last 10 seconds of the jperf output captured from a multicast receiver:

         Figure 4: 10-second jperf output from IPv4 multicast receiver

         It can be observed from the output above, that over the 10- minute period, 73.244 MB of data was transferred at 1 Mbps. The jitter was 7.792 ms. The packet loss is 0% which implies a 100% throughput.

      2. IPv6 only network Throughput and Jitter

      The multicast group address is ff06::6. As in the case of the IPv4 only network, results were obtained from a multicast receiver for ten 10-minute tests and two 1-hour tests. It can be inferred from the results that IPv6 multicast does not introduce any significantly higher jitter or packet loss than in the case of an IPv4 only network. During the ten 10- minute tests, the jitter ranged from 0 ms to 9.487 ms. the throughput was 100% in all the ten tests (fig 5).

      Figure 5: 10-second jperf output from IPv6 multicast receiver

      From the output, it can be seen that over the 10-minute period, 73.244 MB of data was transferred at 1 Mbps with 0% packet loss. The jitter was 7.305 ms (Fig 6).

      Figure 6: Sample jperf screenshot from IPv6 multicast receiver

      From the obtained screenshots it can be seen that for every interval of packet transmission, there is some packet loss. Two 1-hour tests were also conducted and packet loss was observed in both the test cases. The table below shows the throughput for an IPv4 multicast receiver and an IPv6 multicast receiver for all the ten 10-minute tests:

      Graph of Thoughput % for IPv4 and IPv6 in LAN

      94.95

      94.9

      94.85

      94.8

      94.75

      0 1 2 3 4 5 6 7 8 9 10

      IPv4 multicast receiver throughput (%) IPv6 multicast receiver throughput (%)

      Figure 7: Throughput analyses for IPv4 and IPv6 receivers in LAN network

      1. RESULT AND DISCUSSION

         From the studied analysis (graph -1) of IPv4 and IPv6 handled the data effectively. But the flow of packet can be varying according to the networks, so IPv6 performance is better than IPv4. Moreover, since IPv6 was designed as a replacement for IPv4, it was designed to be better than IPv4. The IPv6 header is simpler than an IPv4 header. For instance, the options field, which is included in the IPv4 header, is an extension in the IPv6 header. So without any options, the IPv6 header is not as complex as an IPv4 header. Checksum, for error detection in IPv4, is eliminated in IPv6.

      2. CONCLUSIONS

         In the experiments conducted the load in the case of IPv4 and IPv6 was kept constant. In the case of IPv4, there was no fragmentation, whereas in IPv6 the fragmentation was handled by the host. Even with the additional task of fragmentation, there was no deterioration in the performance of the IPv6 network, which proves that IPv6 handled the fragmentation efficiently. A future study could be conducted with varying packet sizes across the network and see how it affects the performance.

      3. REFERENCES

1. S.E. Deering, Multicast routing in internetworks and extended LANs. Stanford, CA: ACM, 1988, pp. 55-64

2. Iperf http://iperf.sourceforge.net/

3. Iperf The Easy Tutorial http://openmaniak.com/iperf.php

4. RFC 2236 Internet Group Management Protocol, Version 2,

   November 1997 http://www.ietf.org/rfc/rfc2236.txt

5. RFC 3376 Internet Group Management Protocol, Version 3,

   October 2002 http://tools.ietf.org/rfc/rfc3376.txt

6. RFC 2710 Multicast Listener Discovery (MLD) for IPv6,

   October 1999 http://tools.ietf.org/rfc/rfc2710.txt

7. RFC 1112 Host extensions for IP multicasting, August 1989 http://www.ietf.org/rfc/rfc1112.txt

8. RFC 1584 Multicast extensions to OSPF, March 1994 http://www.rfc-editor.org/rfc/rfc1584.txt

9. Deborah Estrin, Ahmed Helmy and David Thaler, PIM Multicast Border Router (PMBR) specification for connecting PIM SM domains to a DVMRP backbone, 1997 http://www.cise.ufl.edu/~helmy/papers/PMBR- spec.pdf

10. Li-wei H. Lehman, Stephen J. Garland and David L. Tennenhouse, Active Reliable Multicast http://web.mit.edu/lilehman/www/paper/arm.pdf

11. Yuji IMAI, Hiro KISHIM0TO, Myung-Ki SHIN and Young- Han KIM, XCAST6: eXplicit Multicast on IPv6, in Proceedings of the 2003 Symposium On Applications and the Internet Workshops, 2003, pp. 238

12. RFC 4966 Reasons to Move the Network Address Translator

    Protocol Translator (NAT-PT) to Historic Status http://www.rfc-editor.org/rfc/rfc4966.txt

13. Kazuaki Tsuchiya, An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (MTP), presented at 52nd IETF MAGMA Meeting, Salt Lake City, Utah, and December 2001.

    http://www.ietf.org/proceedings/52/slides/magma-4.pdf

14. S. Venaas, An IPv4 IPv6 Multicast Gateway, IETF Draft, February 2003.

15. http://www.6net.org/publications/standards/draft-venaas- mboned-v4v6mcastgw-00.txt

16. Performance-Comparison Testing of IPv4 and IP v6 Throughput and Latency on Key Cisco

17. Router Platforms, a Cisco White Paperhttp://www.cisco.com/web/strategy/docs/gov/IPv6perf

    _wp1f.pdf

18. Narayan, S., Kolahi, S.S., Sunarto, Y., Nguyen, D. and Mani, P, Performance comparison of IPv4 and IPv6 on various Windows Operating Systems, in Computer and Information Technology, 11th International Conference, 2008, pp. 663- 668

19. RFC 3973 Protocol Independent Multicast Dense Mode (PIM DM): Protocol Specification (Revised), January 2005 http://www.ietf.org/rfc/rfc3973.txt

20. RFC 4601 Protocol Independent Multicast – Sparse Mode (PIM SM): Protocol Specification (Revised), August 2006 51 http://www.rfc-editor.org/rfc/rfc4601.txt

21. PIM SM Multicast Routing Protocol http://technet.microsoft.com/en-us/library/bb742462.aspx

22. RFC 2460 Internet Protocol, Version 6 (IPv6), December 1998 http://www.ietf.org/rfc/rfc2460.txt