International Journal of Innovative Research in Computer and Communication Engineering

International Journal of Innovative Research in Computer and Communication Engineering

Menu

ISSN ONLINE(2320-9801) PRINT (2320-9798)

All submissions of the EM system will be redirected to Online Manuscript Submission System. Authors are requested to submit articles directly to Online Manuscript Submission System of respective journal.

A New Approach for Multicast Routing Protocol Using Branching Point

Ritesh P Vaingankar1, Mrs J Karthiyayini2
  1. Student, 2nd year M.Tech (CNE), Dept. of ISE, The Oxford College of Engineering, Bangalore, Karnataka, India
  2. Assistant Professor, Dept. of ISE, The Oxford College of Engineering, Bangalore, Karnataka, India
Related article at Pubmed, Scholar Google

Visit for more related articles at International Journal of Innovative Research in Computer and Communication Engineering

International Journal of Innovative Research in Computer and Communication Engineering

Abstract

Many issues and challenges are faced in traditional multicast routing protocol . To deal with it many Branching Point (BP) based multicast routing schemes have been introduced with better features. But these Branching Point (BP) schemes that are proposed have many issues concerning to multicast management related tasks , inefficient tree Construction and excessive lookups during forwarding process of unicast and multicast packet. In this paper we propose a new multicast architecture consisting of a new multicast management entity called as multicast controller (MC). This MC job is to handle all the multicast management related task. Also a Branching Point based Multicast routing protocol (BPM) is proposed to construct multicast tree between the routers in the network.

 

Keywords
Multicast, Branching Point.

INTRODUCTION
Multicast is a term associated with network which supports sending of a single datagram to multiple hosts on a network or internetwork. Multicasting was proposed by Deering in 1988 . Multicasting has two important component : service model and routing protocols [1]. In the service model , a single class D IP group address can be assigned to group of receiver hosts. So if any host want to send data to that group, it can do so by setting the group address in the destination address of the IP header . In multicasting receiver hosts can dynamically join and leave the group at any time. Senders and receiver does not need to keep track of the group membership information , however it is taken care by the routing protocols which maintain the membership information and help to build multicast tree information to deliver packet from sender to all receiver in the group.
Internet Protocol (IP) multicast is a technology that conserve bandwidth and thus reduces traffic by delivering a single stream of information to multiple recipients simultaneously. The applications, demanding for multicast communication has been growing at great accelerated pace. Some of the applications that benefit from multicast are videoconferencing , software distribution, online gaming, stock quotes and so on.
The multicast tree is constructed between routers and each router holds forwarding-state information for forwarding data. However in traditional multicast routing protocols, even if the router is not a member of the multicast group it maintains the forwarding-state information to forward multicast packet in the group. The complications arises when a router would be on multiple trees , thus storing such information is big. Also the forwarding-state information for each multicast group may change. So scalability is a major concern .
Several BP-based schemes have been proposed [2], [3], [4], [5] to reduces the forwarding-state information at nonbranching point router (non-BP) and to address scalability problem in traditional multicast routing protocols. The motivation for such schemes is that in a typical sparse multicast tree, the majority of routes are relay routers that forward incoming packets to the same outgoing interface. So a common goal is achieved by such schemes by releasing some of the intermediate routers from maintaining multicast related states. Also the branching points, are identified by the multicast tree and data are delivered using native unicast routing protocols from one branching point to another. This imposes an advantage over the system , by reducing the number of branching routers in the system . In the BP-based routing protocols, only BP routers keep multicast forwarding table (MFT) entries and all non-BP router use unicast for forwarding multicast data packets. Thus resulting in a less memory consumption in these protocols as compared to the traditional approaches.
One of the important features that the BP schemes provide is the incremental deployment. However in traditional multicast routing protocols, every router needs to implement the protocol functionalities . In contrast, BP-based multicast routing protocols have native support for incremental deployment. Since all packets have unicast destination addresses, routers that do not implement the protocol will forward the packets in unicast manner. In other words, although a router cannot act as a BP, it still can take part in multicast data distribution. Some of other features that these BP-based multicast routing protocol provide are , no need for domain-wide address allocation mechanisms, high tree availability, possibility of performing access control at a sender’s site, and tree construction in the forwarding direction Although the BP-based multicast protocols outperform the conventional multicast approaches in many aspects, several challenges are still open. Some of the challenges are, improving the multicast efficiency , multicast management and so on. To achieve these challenges we propose a novel multicast architecture that improve the multicast efficiency, management, and so on. In the proposed multicast architecture, a multicast controller (MC) is deployed for multicast management. It uses multicast identifiers (MIs) that contain more information than the traditional multicast IP addresses. Based on this multicast architecture, the Branching Point based Multicast routing protocol (BPM) is also proposed. Also shortest path tree (SPT) is used to establish and maintain the multicast routing between routers. A temporary state is used to immediately transmit the multicast packets, that speed up the multicast join process and support the fast mobility of multicast receivers.
The remaining of the paper is organized as follows. Section 2 highlights the problem statement. In Section 3, we surveyed some papers based on Multicast Routing Protocols and put in related work. In Section 4, we described our proposed work. This paper is concluded in Section 5.

RELATED WORK
REUNITE (REcursive UNIcast TrEes) [2] multicast routing protocol is based on the unicast routing infrastructure and used to implement multicast distribution. It separates multicast routing information in two tables. One is stored in control plane as Multicast Control Table (MCT) and another is installed in the data plane as Multicast Forwarding Table(MFT). Branching nodes keep the group information in the MFT and non-branching router keeps group information in MCT. As to reach all group members, entries are kept in MFT which are recursively created packet copies. REUNITE uses two message types: join and tree. Join message travels upstream from the receivers to the source, as tree message are used as refreshing the state of the tree and are periodically multicast by the source.
HBH (Hop-By-Hop ) [3] multicast routing protocol adopts the source-specific channel abstraction technique that is used to simplify address allocation and helps to implements data distribution using recursive unicast trees, which allows transparent support of unicast only routers. Some of the problems in REUNITE are resolved in HBH. First, REUNITE uses unicast address but HBH uses class D IP addresses for multicast sessions. Second, in REUNITE, tree maintenance becomes very complicated when the first router that was previously joined the group leaves the group Third, HBH attempted to resolve the asymmetric routing problem present in REUNITE. Finally, an HBH router does not keep the first router that join the session but only the next hop router addresses. HBH uses two tables Multicast control table (MCT) and multicast forwarding table (MFT) and does same functioning as in REUNITE. HBH has three message types : join, tree and fusion. Join message are the unicast message which are periodically sent by the receiver in the direction of source . At the receiver, join message are used to refresh the forwarding state of the routers where the receiver are connected. The branching router joins itself with the group by sending Join message to the next upstream branching router. Periodically the tree message is sent by the source to refresh the rest of the tree structure. To construct the distribution tree together with the tree message, potential branching routers send Fusion message.
Simple Explicit Multicast (SEM) [4] is one of the BP-based method which has less tree construction complexity than REUNITE and HBH. It adopts the source-specific channel address allocation, implements data distribution using unicast trees and reduces forwarding states in non branching node routers. The structure of Multicast Forwarding Table (MFTs) in SEM is similar to HBH. SEM uses the receivers list to construct Reduce Tree (RT) . The BRANCH message consist of receivers list that is inserted in its packet header. This imposes limitation in packet size that restricts the number of receivers supported. More importantly, whole multicast tree is constructed when a new member joins the multicast session or one of the existing members leaves the session. This is an intolerable drawback. It severely limits SEM application to semi-static and fully static groups.
NBM (Next Branch Multicast) [5] is another BP-based protocol named that constructs the multicast distribution tree in the forward direction. Also to protect the tree against BPs failure fault-detection and repair mechanism are implemented. NBM detects the failure of a higher level BP in the tree sooner than a lower level BP. NBM does not maintain any type of control state in non-branching routers. The NBM protocol consists of two distinct parts: tree construction and tree maintenance processes. The tree construction part uses a simple and efficient technique to distinguish BPs of RT (reduced tree). It uses Build message to find the associated BP of the new receiver. The tree construction mechanism of NBM does not need to maintain MCT or any other control state in RNs and BPs. It constructs RT gradually only with assistance of the MFT content. The tree maintenance mechanism of NBM uses an innovative technique to detect and repair failures of BPs. In NBM, Every BP refreshes its children information periodically. All children who miss three consecutive refresh messages will detect the BP failure. Then, the NBM repair mechanism locally repairs the tree and finds a new BP (or new BPs) for the orphaned receivers. For tree construction mechanism NBM has six protocol messages namely Join, Leave, Build, Unlock, Replace and Parent. The Join message of a new receiver always reaches the sender without any interception by intermediate routers. Build message to find the associated BP of the new receiver. The Unlock message is used to preserve consistency of the multicast tree against hazardous race conditions. Replace is sent in the reverse direction of corresponding Build message. Parent message is sent periodically by every BP (including sender) toward each child in its MFT. Leave message is sent by the children BP to the previous BP when they don't receive parent message.

PROPOSED WORK
In this section , we present a novel approach where we introduce Multicast controller (MC) as a management entity . and a Branching Point based Multicast routing protocol (BPM) is used for constructing multicast tree. At first, the MC should be able to process the request from the receiver for address management, group membership management [6] and multicast source authentication for multicast service. When a new receiver wants to join the multicast group, the AR(Access Router is the one which is connected to the receiver directly ) of the receiver demands with the MC for the new receiver’s authentication and “MI (Multicast source IP)” mapping query. When the receiver terminates the multicast service, the AR of the receiver reports the leaving state and accounting information to the MC. As the number of receiver increases the query increases and thus MC cannot process them and overhead is occurred. To overcome the overhead we introduce an load balancing algorithm that helps the MC to process the query at the Load balancing router(LBR) itself. Shown in Fig1 is the Proposed architecture that consist of an Load Balancing Router (LBR) that is used to overcome overhead at the MC.
Steps involved in the load balancing router selection algorithm:
Step 1: Check if (Overhead =1 ). If true then generate broadcast message from MC stating require of LBR .
Step 2: Calculates the number of neighbour MR(multicast router) connected to it. Each MR sends its calculated neighbours to MC in unicast message.
step 4: The MC receives all the neighbour count and the highest neighbour count is selected as LBR.
step 5: MC sends a unicast message to highest count MR , stating it as LBR and tells to make all its neighbours , neighbour count = 0.
step 6: LBR sends all its neighbour a unicast message stating neighbour count = 0. All its neighbour make their neighbour count =0.
step7: go to step 1.
step 8: End
Once LBR is chosen, LBR sends broadcast declaring itself as nearest load balance MC to other MR. Now other MR send the request for group to newly elected load balancing MC for creation & authentication purpose.
Every Branching Point router maintains multicast state table (MST). MST helps in establishment and maintenance of the Branching Point routers state information. Also MST is used in the construction of multicast tree. Since the Relay routers need not hold information about MST there is ease of resource utilization and hence no excess lookup to be done at the relay routers.
As shown in Fig 2 is the format for BPM header used in the construction of multicast tree. The first field is the "BPM Version", denotes which version does the protocol belongs to and is 4-bit long. The second field is the "Type" field which is 3-bit long . it defines four types of signalling messages:
o 001 for join message, sent from receiver to source and used to establish multicast tree and state refreshment.
o 010 for tree message construction sent from source to receiver and also used in the response of join message.
o 011 for select message , which used in reselect branching point routers .
o 100 for leave message ,sent from receiver to the source for multicast termination.
The third field is the "B" field is 1-bit long used to identify the node sending message is BP router if 1 denotes "yes" and 0 denotes "no". The fourth field is the timer field used during renewal of tree construction updating process . The Multicast identifier “MI” field denotes the multicast service that is associated in the BPM header queried by receiver or processed by source. The last three fields are the addresses of the downstream Branching Point router ( dBP), upstream Branching Point router (uBP) and ancestor upstream Branching Point router uBR, respectively.

SIMULATION RESULTS
Here we evaluate the performance of BPM and compare with NBM scheme. Both are based on BP-based schemes. For simulation study JAVA platform is used to evaluate and compare the performance. In the simulation we consider 150 nodes , includes MC , source . For simulation purpose we assume that for each AR in the network will be connected to only one receiver. the routers generated are randomly placed , also the receiver are randomly placed . We have single fixed MC and Multicast Source and the receiver will join these at random interval of time. This simulation is run 40 times and this presents both the protocols average results. The simulation parameters are as shown in Table shown below.
Parameter Value
No of mobile nodes (receivers) 5 to 50
No of routers 50 to 100
No of multicast node 1
No of source node 1
Mobile node position Randomly distributed
Mobile node direction Randomly moved
Data traffic Multimedia data ( video)
Speed of mobile node 4m/s
Radio range 100m
If we consider Fig 1 graph regarding maintenance cost initially both scheme consumes similar number of signalling messages , but as increase in receiver, BPM consumes more signalling message compared to NBM for construction of SPT (shortest path tree ) process. Fig 2 graph is related to join latency , we see that join latency of BPM is lower than that of NBM .This is because NBM round trip time (RTT) is between source and receiver. However join latency of BPM equals RTT between receiver and nearest BR. Fig 3 graph is related to overhead at MC. We see that without LBR the overhead at the MC increases but with LBR the MC overhead reduces. since only first request are sent to MC and rest are handled by LBR.

CONCLUSION
In this paper, we present BPM (Branching Point Multicast) routing Protocol and a novel multicast architecture with multicast controller (MC). BPM provides an efficient method to construct multicast tree and deliver multicast packets. To construct and maintain the multicast tree BPM uses four types of messages . To support multicast management, MC is introduced which makes multicast more controllable, secure, and manageable. The BPM tree construction process is similar to that in NBM. Even when the BP router fails the BPM guarantees the shortest path . The SPT can be maintained and established with a lower signalling cost.

ACKNOWLEDGEMENT
I would like to extend my deepest thanks to my guide Mrs J Karthiyayini , Assistant Professor, ISE, TOCE, Bangalore who guided me well to put my ideas in this paper.

Figures at a glance
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5

References