An Architecture For Multicasting IP Using Private Tunnel

DOI : 10.17577/IJERTV2IS70770

Download Full-Text PDF Cite this Publication

Text Only Version

An Architecture For Multicasting IP Using Private Tunnel

Amandeep Singh Sidhu Dr. Neeraj Kumar

Post Graduate Student(M.E.) Assistant Professor

Department of Computer Science & Engineering Department of Computer Science & Engineering Thapar University Thapar Universirty

Patiala, Punjab Patiala, Punjab

Abstract

Multicast IP is a very effective routing scheme for streaming same content with control or user. But it not supported fully by internet as all the ISP does not support multicast or black multicast due to hardware restriction. There are over relay network that we can use for multicast. But all have there own limitation. In this paper, we will discuss an architecture how to make own over relay network for multicasting. With the help of tools already available. Which we can configure according to our needs. Simple knowledge of networking, linux systems and router configuration we can create it.

  1. Introduction

    Internet started to exchange information mainly by text and data, but it has evolved as a stream of digital information of any form. We can reach data as in software, news and email as text, collected data in databases, graphical images, music, video, and many more. It is clear that all these forms of data are different and they might need a different approach to handle.

    Streaming can be done several ways if you talk about the use of the network. The three main ways to stream content is through unicast, multicast or broadcast. They all have their advantages and disadvantages. However not all of them are supported by the internet backbone and the Internet Service Providers. Today most of the streaming is done by a unicast connection which make a dedicated own connection. This is suitable for on-demand streaming as in case of youtube, as users are streaming stored content on a server as they were downloading a simple file.

    However when there is live content viewers access the same source and same content simultaneously. This means that the same live stream data have to be send simultaneously to different receivers. With a unicast system all those users would need a separate

    connection and all the load would be on that one server. This is not efficient as all are requesting same content and there where be multiple copy of same data and therefore there are the two other techniques: multicast and broadcast. They use the network structure itself to duplicate or multiply the live stream to the receivers, and take away the load from the server. The technique is rather simple but yet not supported or even blocked by Internet Service Providers and the internet backbone.

    It is routing that makes the internet work today. Routing decides which data goes where. To manage all this routers have routing protocols and routing schemes. Protocols are used to format data, get network topology and agree on ways of communications. Routing schemes are used to define a method for the data to be delivered to the client device, to decide how the data has to get to the destination.

    There are a couple of different types of devices in the topology of a network. The devices that deliver the content to the network are called the servers. They store the websites, data, multimedia and all other content delivered on the internet. On the other end of the line there are the clients. These are the computers that browse the websites, smart phones that display a video from YouTube or an interactive television. In between of the clients and servers we have the network devices, mainly routers, firewalls and switches. They do everything to deliver the data, called packets, sent from the servers to the clients. Firewalls control the safety and block unwanted packets. Routers route the packets to the right network and switches deliver it to the destined client, router, switch, firewall or server. There are also devices called hubs, they send all packets to all their ports.

  2. Motivation and Background

    Despite the advancement in Multicast from industry and academics contributions, Multicast faces many challenges for its worldwide adoption. The primary

    reason for not adopting the Multicasting is that many ISP doesnot support multicasting due to its increase in hardware cost. This locks multicast user to local network infrastructure. If all the ISP make their network multicast compatible on widely adopt and promote making it more easier to implement.

    Internet compatibility is missing, there are number of overlay networks available for multicast but they have there limitation for i.e. The MBONE was designed to use 500 Kbps to transmit multicasts, which is an adequate maximum bandwidth for now [5].

    Using simple and secure method of sending multicast data as unicast to cross non multicast support router. Aim of this thesis is to create simple network architecture with the use existing tools to send multicast data over internet to various users.

    1. Complex System

      All the system that has been developed for multicasting are complex to implement. As they require high level of knowledge how to deploy them. If you want multicast data for small amount of time it is not beneficial.

    2. Third Party Networks

      Multicasting will depend on 3rd party networks, if that network is down multicasting will not work. Which have their own limitation for example Mbone support only 500kbps of bandwidth [7]. If 3rd party network fails then your multicast network will too.

    3. Reliability

      Most of these logical networks running on top of IP layer are based on RTP (Real time protocol) that does not support reliability. Application running on these networks often experience poor quality due to packet lost as network configuration as per application is not present.

    4. Commercial System

      There is no commercial network that is providing multicasting over internet, all the overlay network that are running now are not developed or maintained aggressively. All are under development and evolving every day.

  3. Available System

    A lot of ISPs for example charge users by the amount of data they download, or give users a monthly bandwidth. With multicast they would not be able to see all the traffic passing through per user. Also content providers like to know how much users are watching their content. As it is much easier with unicast to count the users, which are needed for commercial income, they do not tend to use multicast over unicast. The cost of providing unicast does not weigh against the

    revenues of statistics which are valuable in the commercial world. That being said it does not mean multicast over the internet is completely impossible. We will discuss multicast data ways of multicasting data over internet.

    1. Mbone

      Mbone is a virtual network built on top of the Internet, invented by Van Jacobson, Steve Deering and Stephen Casner in 1992. The purpose of Mbone is to minimize the amount of data required for multipoint audio/video- conferencing. Mbone is free; it uses a network of mrouters that can support IP multicast, and it enables access to real-time interactive multimedia on the Internet. Many older routers do not support IP multicast. To cope with this tunnels must be set up on both ends; also known as a tunneling protocol: multicast packets are encapsulated in unicast packets and sent through a tunnel. Mbone uses a small subset of the class D IP address space (224.0.0.0 239.255.255.255) assigned for multicast traffic. Mbone uses 224.2.0.0 for multimedia conferencing [6].

    2. Mcast

      Mcast was a proect from the Vrije Universiteit Brussel trying to enable multicast access for everyone on the internet. With tunnelling technology they tried to capsulate the packets over the existing network to other multicast nodes. The configuration of the tunnel clients running on the client computers would be automatic.

      The researchers hope was to show ISPs and content providers the usefulness of multicast. If enough clients would be using multicast, they could be convinced of investigating in multicast on the ISPs network. However after the project professor Marnix Goossens said they under estimated the current business model. As for now there is nobody at the Vrije Universiteit Brussel researching multicast anymore.

    3. 6Bone

      The 6bone is an independent outgrowth of the IETF IPng project that resulted in the creation of the IPv6 protocols intended eventually to replace the current Internet network layer protocols known as IPv4. The 6bone is currently an informal collaborative project covering North America, Europe, and Japan.

      One essential part in the IPv4 to IPv6 transition is the development of an Internet-wide IPv6 backbone infrastructure that can transport IPv6 packets. As with the existing IPv4 Internet backbone, the IPv6 backbone infrastructure will be composed of many Internet Service Providers (ISPs) and user networks linked together to provide the world-wide Internet.

      Until the IPv6 protocols are widely implemented and fully tested for interoperability, production ISP and user network routers will not readily place production Internet (IPv4) routers at risk. Thus a way is needed to provide Internet-wide IPv6 transport in an organized and orderly way for early testing and early use.

      The 6bone is a virtual network layered on top of portions of the physical IPv4-based Internet to support routing of IPv6 packets, as that function has not yet been integrated into many production routers. The network is composed of islands that can directly support IPv6 packets, linked by virtual point-to-point links called "tunnels". The tunnel endpoints are typically workstation-class machines having operating system support for Ipv6.

      Over time, as confidence builds to allow production routers to carry native IPv6 packets, it is expected that the 6bone would disappear by agreement of all parties. It would be replaced in a transparent way by production ISP and user network IPv6 Internet-wide transport [8]. The 6bone is thus focused on providing the early policy and procedures necessary to provide IPv6 transport in a reasonable fashion so testing and experience can be carried out. It would not attempt to provide new network interconnect architectures, procedures and policies that are clearly the purview of ISP and user network operators. In fact, it is the desire to include as many ISP and user network operators in the 6bone process as possible to guarantee a seamless transition to IPv6.

    4. AMT-A Transparent Bridge to Full IP Multicasting

      Automatic Multicast Tunneling (AMT) technology in its Juniper Networks® Junos®operating system for MX Series 3D Universal Edge Routers overcomes the lack of multicast capability on a given device. If lack of multicast support on any device along the path prevents a particular user from joining a native multicast stream, then an AMT gateway which is built into Octoshapes powerful and resilient video distribution technology requests that an AMT – enabled router join the multicast on behalf of the user. Specifically, AMT establishes tunnels that link users on unicast-only networks with the content they want on multicast enabled networks. If you operate a multicast-enabled network, you can deploy AMT relays, i.e., AMT- enabled routers, at the edge of the network. As an AMT tunnel endpoint, the AMT relay essentially translates native IP multicast content for users on a unicast only network. Users on the unicast-only network have an AMT gatewaythe other tunnel endpointon their devices. This gateway,i.e., Octoshapes resilient video distribution technology, uses the anycast

      autodiscovery mechanism to locate the nearest AMT relay and then dynamically initiates an IP multicast tunnel to that relay.

      The AMT gateway asks the AMT relay to forward a multicast content stream through the tunnel. Upon receiving the request, the AMT relay joins the multicast content, and the multicast stream is forwarded through the multicast enabled network to the AMT relay which, in turn, forwards it via the tunnel to the users AMT gateway. Thanks to AMT technology, everyone on the network can now receive the signal via multicast, even if multicast is not supported in every part of the network, all the way down to the user. By serving as a transparent bridge that allows users to hop over unicast-only networks, AMT resolves the last-mile challenges facing:

      • Service providers, who want the maximum return on their capital expenditure investments.

      • Content providers, who want to minimize the cost they incur for delivery of their content.

      • Users, who want access to any content, regardless of whether someone delivers that content over a unicast or a multicast infrastructure.

  4. Problem Statement

    This thesis addresses four different issues in Multicasting in recent times.

    1. Multicasting data should be made easier to send over network with present system it is not easy to do as they have own methods or standards that one should follow.

    2. Creating own network to multicast should be setup so that we can manage and control it.

    3. Depending upon type of data we are sending we can have option to choose what protocol should we used is data we sending time critical or not.

    4. We should we able to use data with commercial system if any reliable network is there.

  5. An Architecture for Private Tunnel

    In this section we propose a solution to setup environment and resolve some of issues. Requirement analysis is done based on objectives of this thesis. Lastly we propose architecture for multicasting data over internet. Each component of architecture is explained in detail.

    1. Requirement Analysis

      In this section requirements are collected based on which architecture will be developed. Main focus to propose solution is to create simple multicast without 3rd party solution. These four layers are:

      1. Streaming Server: Streaming servers typically deliver files to you with or without a help from a Web server. First, you go to a Web page, which is stored on

        the Web server. You might be running some software application like VLC player that can stream content directly. When you click the file you want to use, the Web server sends a message to the streaming server, telling it which file you want. The streaming server sends the file directly to you, bypassing the Web server.

        All of this data gets to where it needs to go because of sets of rules known as protocols, which govern the way data travels from one device to another.

      2. Client Application: Application that will help us to request and receive the required multicast information from the stream server.

      3. Mrouters: An mrouter can disguise multicast packets so that they can cross unicast routers. This is done by making each multicast packet look like a unicast packet, the destination address is the next mrouter.

      When these three layers are linked through network for information exchange many issues can be resolved. For example, streaming data is multicast over internet.

  6. Design of the Network Architecture

    The Network Design is to understand how network architecture is going to be established. Help us understand different parts of the network. It is expressive way of addressing all the needed to deploy the system. With the help of network design tools we will propose the network architecture for the implementing multicastingapplication. In this we will create architectures to send multicast data to multiple receivers over internet.

    1. Multicast data over internet with blocked ISP

      We will start with the diagram to give overview of the multicast data streaming over internet

      Figure 6.1 Multicast With Blocked ISP

      .

      In figure 6.1 streaming server will send content to the requested clients PC 1 to PC 6, there are connected by two different ISP. ISP 1 router supports multicast routing and ISP 2 does not support. So when media server will stream data PC 1 to PC 3 will receive the requested data which can be audio, video or any other kind of multicast data. But PC 4 to PC 6 will not receive any data as they are connected through ISP 2.

    2. Multicast data through blocked using XORP

      We will create architecture to multicast data from streaming server to other network using tunnelling process with the help of XORP mroute.

      In this network we will send unicast data through mroute server 1 to the specific mroute server 2. Mroute server 2 will handle the unicast data and convert into specific multicast data and distribute it into its network that can handle multicast.

      Figure 6.0.2 XORP Setup

      1. XORP Setup

        XORP is an open source Internet Protocol routing software suite originally designed at the International Computer Science Institute in Berkeley, California. The name is derived from extensible open router platform. The product is designed from principles of software modularity and extensibility and aims at exhibiting stability and providing feature requirements for production use while also supporting networking research. The development project was founded by Mark Handley in 2000. Receiving funding from Intel, Microsoft, and the National Science Foundation, it released its first production software in July 2004. The project was then run by Atanu Ghosh of the International Computer Science Institute, in Berkeley, California.

        In July 2008, the International Computer Science Institute transferred the XORP technology to a new entity, XORP Inc., a commercial startup founded by the leaders of the opensource project team and backed by Onset Ventures and Highland Capital Partners. In February 2010, XORP Inc. was wound up, a victim of the recession. However the open source project continued, with the servers based at University College London. In March 2011, Ben Greear became the project maintainer and the www.xorp.org server is now hosted by Candela Technologies.

        The XORP codebase consists of around 670,000 lines of C++ and is developed primarily on Linux, but supported on FreeBSD, OpenBSD, DragonFlyBSD, NetBSD. Support for XORP on Microsoft Windows

        was recently re-added to the development tree. XORP is available for download as a Live CD or as source code via the project's homepage.

        The software suite was selected commercially as the routing platform for the Vyatta line of products in its early releases, but later has been replaced with quagga. XORP provides a command line interface for interactive configuration and operation monitoring. The interface is implemented as a distinct application called xorpsh, that may be invoked by multiple users simultaneously. It interacts via Interprocess communication with the router core modules. The command line language is modelled after that of Juniper Networks's JunOS platform.

        We need to install XROP mroute on the server that will handle the traffic, There are a few issues that must be taken care off before we run the router. First we need to have those interfaces that are specified in the configuration. This is necessary when establishing tunnels between multicast hosts separated by unicast- only networks and routers. (The mrouted is a daemon that implements the multicast routing algorithm -the routing policy- and instructs the kernel on how to route multicast datagrams).

        Step 1: Check Linux Kernel Functions CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MROUTE=y

        After this configurations, the linux kernel support IGMP, DVMRP and MOSPF. If want support PIM-SM

        , do below settings CONFIG_IP_PIMSM_V2=y

        PS: you can use vi view /boot/CONFIG-(kernel version) to confirm

        Step 2: edit /etc/sysctl.conf to enable ip_forward net.ipv4.conf.default.forwarding=1

        PS: reboot or use command sysctl -p to enable !

        Step 3: Install XORP(To compile XORP requires nearly 1.4GB of free disk space)

        Step 3.1: Download xorp-1.6.tar.gz Step 3.2: untar the xorp-1.6.tar.gz Step 3.3: ./configure

        Step 3.4: make

        Step 4: run rtrmgr/xorp_rtrmgr rtrmgr/xorpsh (A sample xorp command shell)

        Step 4.1: create user group named xorp sudo addgroup xorp

        Step 4.2: cp or edit config.boot in xorp- 1.6/rtrmgr/config.boot config.boot for our environment protocols {

        fib2mrib { disable: false

        }

        igmp { disable: false

        interface eth0 { vif eth0 { disable: false version: 3

        enable-ip-router-alert-option-check: false query-interval: 125

        query-last-member-interval: 1

        query-response-interval: 10

        robust-count: 2

        }}}}

        fea {

        unicast-forwarding4 { disable: false

        }}

        interfaces {

        restore-original-config-on-shutdown: false interface eth0 {

        disable: false discard: false

        description: TEXT default-system-config {

        }}}

        Step 4.3: xorp-1.6/rtrmgr/xorp_rtrmgr -b xorp- 1.6/rtrmgr/config.boot

        Step 5: Check Mrouter work OK

        Step 5.1: Connect eth0 to VLC Player server PC and connect etp to VLC Player client PC

        Step 5.2: Use VLC Player server PC run multicast streaming

        Step 5.3: Use VLC Player client PC to play multicast streaming by multicast URL

        Step 6: run rtrmgr/xorpsh (A sample xorp command shell)

        The steps will help configure XORP for multicast routing.

      2. Media Server Windows 2008

        We will show you how to setup windows server 2008 as media stream server with ability to handle multicast request. First the choice of which server type to install. Since Windows Media services require at least Enterprise or Datacenter to provide multicast it is important to choose at least one of those. Then we select type of service required we select stream server and webserver IIS. Next option is to play movie on demand or simply broadcast and play user at its current broadcast point as in television.

        After that we select the server option to handle request as a multicast server, then we select files to record the multicast group information. In the last part we have the file path which we want to multicast that will handle request of the incoming connection.

        Figure 6.3 Server Select

        Figure 6.4 Required Services

        Figure 6.5 Select Multicast

        Figure 6.6 Select File to Stream

  7. Conclusion & Future Scope

This paper provides a new method of multicasting data by creating own tunnelling m method without using any other service. Which is essential for the organisation as there is no set solution for tunnelling data over internet Given that benefits of the multicasting over unicast in bandwidth utilization. As future of broadcasting is multicast in IPv6 more people organisation will dig into finding solution for it. This presented architecture includes four main improvements:

  1. Setup secures tunnelling process.

  2. Easy to setup and maintain with minimum hardware requirement.

  3. Reliable as you have control of the network.

  4. Configurable as per requirement.

One of the desirable attribute of our architecture is it give users freedom to send data to using multicast protocol.

There are some future aspects of architecture that need to be discussed:

  1. If organisation wants to commercialize this architecture then they need different mechanism to handle IGMP message.

  2. Different types of files can be streamed using this method.

  3. Develpment of application architecture using SSH tunnel to connect.

    REFRENCES

    1. Beau Williamson, IP Multicast Networks., 2003.

    2. Chuck Semeria, "Introduction to IP Multicast Routing," NC State University.

    3. L. Mohamed. (1997) Carleton University Instructional Television Courses. [Online]. HYPERLINK "http://www.sce.carleton.ca/tln/ITVMBONE.htm" http://www.sce.carleton.ca/tln/ITVMBONE.htm

    4. Mike Macedonia. MBONE, the Multicast BackbONE. [Online]. HYPERLINK "http://www-

      mice.cs.ucl.ac.uk/multimedia/projects/mice/mbone

      _review.html" http://www- mice.cs.ucl.ac.uk/multimedia/projects/mice/mbone

      _review.html

    5. Abley J. (2013, March) Operation of Anycast Services. [Online]. HYPERLINK "http://tools.ietf.org/pdf/rfc4786.pdf" http://tools.ietf.org/pdf/rfc4786.pdf

    6. T. Imielinski. (1996) Network Working Group. [Online]. HYPERLINK "http://tools.ietf.org/html/draft-rfced-exp-navas- 00" http://tools.ietf.org/html/draft-rfced-exp- navas-00

    7. Bob Fink. IETF. [Online]. HYPERLINK "http://www.ietf.org/wg/concluded/6bone.html" http://www.ietf.org/wg/concluded/6bone.html

    8. Gorry Fairhurst. (2009, March) The University of Aberdeen. [Online]. HYPERLINK "http://www.erg.abdn.ac.uk/~gorry/eg3567/intro- pages/uni-b-mcast.html" http://www.erg.abdn.ac.uk/~gorry/eg3567/intro- pages/uni-b-mcast.html

    9. Xorp. [Online]. HYPERLINK "http://www.xorp.org/getting_started.html" http://www.xorp.org/getting_started.html

[10 Virtual Box. [Online]. HYPERLINK

] "https://www.virtualbox.org/" https://www.virtualbox.org/

[11 utorrent. [Online]. HYPERLINK "http://www.utorrent.com/get-started"

] http://www.utorrent.com/get-started

[12 Ubuntu Manuals. [Online]. HYPERLINK

] "http://manpages.ubuntu.com/manpages/hardy/ma n8/xorp_rtrmgr.8.html" http://manpages.ubuntu.com/manpages/hardy/man

8/xorp_rtrmgr.8.html

[13 Revolution Systems. [Online]. HYPERLINK

] "http://www.revsys.com/writings/quicktips/ssh- tunnel.html" http://www.revsys.com/writings/quicktips/ssh- tunnel.html

[14 Putty. [Online]. HYPERLINK

] "http://www.putty.org/" http://www.putty.org/

[15 OpenSSH. [Online]. HYPERLINK

] "http://www.openssh.org/" http://www.openssh.org/

[16 Microsoft Support. [Online]. HYPERLINK

] "http://support.microsoft.com/kb/963697" http://support.microsoft.com/kb/963697

[17 Media Template. [Online]. HYPERLINK

] "https://kb.mediatemple.net/questions/16/" https://kb.mediatemple.net/questions/16/

[18 Juniper. [Online]. HYPERLINK

] "http://www.juniper.net/techpubs/software/junos- es/" http://www.juniper.net/techpubs/software/junos-

es/

[19 Juniper. [Online]. HYPERLINK

] "http://www.octoshape.com/wp- content/uploads/2013/06/Juniper-Octoshape- White-Paper.pdf" http://www.octoshape.com/wp- content/uploads/2013/06/Juniper-Octoshape-

White-Paper.pdf

[20 IBM. [Online]. HYPERLINK

] "http://publib.boulder.ibm.com/infocenter/iseries/v 5r3"

http://publib.boulder.ibm.com/infocenter/iseries/v 5r3

[21 Git Hub. [Online]. HYPERLINK

] "https://github.com/greearb/xorp.ct" https://github.com/greearb/xorp.ct

[22 Fast Lane. [Online]. HYPERLINK

] "http://www.fastlaneus.com/course/ci-mcast" http://www.fastlaneus.com/course/ci-mcast

Leave a Reply