Printer Friendly

Accurate performance evaluation of internet multicast architectures: hierarchical and fully distributed vs. service-centric.

1. Introduction

There are three fundamental methods for transmitting data over a network: unicast, broadcast, and multicast. Unicast can be defined as traffic sent to a single specific destination such as a host computer, web server, or a particular end user. Broadcast can be defined as traffic forwarded to all users of a network. Multicast traffic can be defined as traffic delivered to a specific subset of the network users. The implementation of both unicast and broadcast traffic is easy for networks. This is because the data packets will either be delivered to a single unique destination, or they will be propagated throughout the network for all end users. The implementation of multicast traffic is considerably more complex because users must be identified, and traffic must be sent to their specific locations. The network should also refrain from sending traffic to unnecessary destinations to maintain security and to avoid wasting valuable bandwidth. Internet Service Providers (ISPs) are concerned about the effects of multicast traffic on their networks. However, multicast traffic is increasing over the Internet [1], [2], [3], [4], [5]. Applications such as data casting, video and audio transmissions, and training seminars all depend on multicast technology. These applications are designed to deliver identical packets to a large number of receivers and these packets must be replicated at an exponential rate. The resulting bandwidth requirements and routing overhead associated with these applications can be quite daunting [6].

The paper proceeds as follows; Section 2 introduces the related work. In Section 3, the new hierarchical architecture is demonstrated. In Section 4, the new fully distributed architecture is demonstrated. In Section 5, general aspects for the two proposed architectures are introduced. A comparison between the current and the proposed architectures is showed in Section 6. The simulation of our two proposed architectures is introduced in Section 7. Finally, the conclusion and the future work are demonstrated in Sections 8, and 9 respectively.

2. Related Work

In recent years, there has been more research in the area of multicast routing. Traditional multicast routing protocols are classified into two classes: Shortest Path Tree (SPT) based multicast routing protocols and Shared Tree (ST) based multicast routing protocols. SPT based protocols build a separate multicast tree for each (source, group) pair rooted at the source. Both Distance-Vector Multicast Routing Protocol (DVMRP) [7] and Multicast Extensions to Open Shortest Path First (MOSPF) protocol [8], [9] are SPT-based protocols. SPT-based protocols minimize end-to-end delay. However, there are three problems in SPT-based multicast routing protocols. These problems can be stated as follows, scalability problem for a large network, adopting DVMRP or MOSPF wastes a large portion of the network bandwidth due to flooding, and multicast trees generated in DVMRP or MOSPF are shortest path trees, which may not be the lowest cost multicast trees [10].

The scalability and bandwidth wasting problems are handled by proposing the ST-based multicast routing protocols. Core-Based Tree (CBT) [11], Protocol-Independent Multicast Sparse Mode (PIM-SM) [12] and Simple Multicast (SM) [13], [14] are ST-Based protocols [15]. However, the ST-based multicast routing protocols introduce new problems. These problems are; the less efficient multicast communication mechanism from a source to a multicast groups specially in terms of multicast tree cost and communication delay, the elected core has the same architecture as any other routers in the network, thus has limited computing and packet forwarding capability, and the ST-based approach may cause traffic jam around the core. In addition, the traffic concentration will cause the problems of packet loss and longer communication delay. Finally, the multicast communication between a source and a multicast group cannot tolerate the core failure [7].

Other routing protocols in mobile and wireless networks were also introduced. The most popular protocols are On-demand Distance Vector (AODV), Destination-Sequenced Distance Vector Routing Protocol (DSDV), and Dynamic Source Routing Protocol (DSR). These protocols are evaluated in [16], [17]. Furthermore, LEAR is a multimedia protocol for wireless multimedia sensor networks [18], and is considered as a special purpose protocol.

In addition, there are special purpose techniques and algorithms for multicast routing tree construction. Hachisuka et al. proposed in [19] a new multicast tree algorithm for hierarchical optical path networks that develop wave band routing. It defines a relation between node groups that identifies adjacent destination groups. Also, this algorithm establishes a minimum weight waveband tree. Wang et al. introduced in [20] a new shared tree-mesh framework that collects mesh and tree topologies. The idea of this trial is to define a group of regular nodes to create a tree-based backbone, which is called Treebone, with most of the transmitted data over this backbone. These regular nodes, together with other nodes, are organized through a supplementary mesh overlay, which help the Treebone to make nodes dynamic and the available bandwidth between overlay nodes is efficiently used. Polishchuk et al. demonstrated in [21] a scalable multicast architecture to adapt the Hybrid Error Correction (AHEC) scheme in the multicast scenarios for potentially large overlay networks. This proposed multicast architecture notably reduces the redundant information which is transmitted in large overlay networks. De Oliveira Silva et al. presented in [22] a corroboration of OpenFlow based implementation of the Entity Title Architecture (ETA). This architecture is used for future Internet where mobility and multicast are faultlessly presented. It considered concepts of its previous work; Entity Title Model (ETM), in addition to benefits of Software Defined Networking (SDN). Jardim proposed in [23] an extension of the Multi-User Aggregated Resource Allocation (MARA) technique. This proposed technique is called Multi-User Aggregated Resource Allocation Multi Ingress (MARA-MI). It can deal with associate multicast aggregated path. It supports the adaptation of reserved patterns at all running nodes to pass up QoS violation which may occur over a time. Also, it maintains an accepted quality level as regards multi-user sessions. Atlas et al. proposed two types of multicast protections general methods; internally and externally [24]. These methods used alternate-trees and depend on maximally unneeded trees. The fast re-route technique is an example of internal protection and the live to live multicast technique is an example of external protection.

In a more closed approach called service-centric multicast architecture proposed by yang [10], a powerful router, called m-router, collects multicast-related information and processes multicast requests based on the collected information. The m-router handles most of multicast related tasks, while other routers only need to perform routing minimum functions. The m-router is designed to be able to handle simultaneous many-to-many communications efficiently. The Service-Centric Multicast Protocol (SCMP) builds a dynamic shared multicast tree rooted at the m-router for each group. The tree construction is performed by a special type of self-routing packets [10]. However, the centralization idea raises some problems.

The study and analysis of the service-centric approach extracted the following drawbacks; hardware complexity is high, the m-router needs lot of bandwidth to handle the multicast functions and this requirement may not be available, the fault tolerance idea is straightforward and is not clarified in details, the multicast architecture in service-centric approach is costly, the tree message is too complex to transfer from one level to another in the multicast routing tree, what will be done if the tree message is lost?, and the changing between the architecture messages (Branch and Tree) within the multicast tree management is ambiguous.

3. Proposed Hierarchical Architecture

The proposed hierarchical architecture [25], has N management routers. In this paper, N equals three. The architecture management routers are called basic router, m1-router, and m2-router. The domain of ISP is divided into two parts. The first part is for m1-router and the second one is for m2-router. Other system routers are distributed depending on three factors; the link delay, the link cost, and the load balance. When a new router or host needs to login the ISP domain, it should communicate with the m1 router or the m2 router. The routers should send a unicast message to the up-level m-routers. Consequently, the m1 router sends an upgrading aggregation message to the basic router. Regarding the aggregation message infrastructure, see Section 5.

At the m-routers level, a sub-multicast tree for each domain part is constructed. Each router on the sub-domain considers its m-router as a root of its sub-tree. Each m-router sends its sub-tree to the high level router that is called basic router. The basic router merges the two sub-trees in one multicast tree. Hence, the root of the multicast tree will be considered the basic router. The merging process is accomplished using the technique which is found at [26].

In the following subsections, the architecture components, the load balance and the fault tolerance aspects, the multicast tree construction, the relation between the basic router and domain routers, and a case study which describes the architecture operations are discussed.

Routers are organized into levels of areas such that an area at level X is called an X-area. The basic router forms 0-area, the m1 router forms 1-area, and the m2 router forms 2-area. In case of overlapping areas, each router can belong to one or more areas at each level in the hierarchy routing tree . A router, which has a direct connectivity with the boundary routers in other areas, is called a border router. The distance from a source router to its remote routers represents global shortest path length of this router as regards the routing tree. Similarly, the distance from a router to another router in the same area is called local shortest path distance. The distance from a router to itself can be considered 0. Routers send their routing sub-trees by communicating only the hierarchical system from lower to upper levels direction. The distance between the router and its' up-level routers in the same area should be considered.

3.1 Architecture Components

Our proposed architecture consists of three different management levels. The first level contains a powerfull router which is called basic router. This basic router is considered a main manager in the multicast tree construction system. It has two inputs and two outputs leading to low hardware complexity. The basic router functions are session management, merging the multicast sub-trees in one tree, and recovering the m-routers in case of failure occurrence.

The second level of our proposed architecture contains two management routers called m1 router and m2 router. These two routers share the basic router in the management processes. Each router is responsible for the domain part. The main functions of this level are to construct the multicast sub-trees, collect hosts or routers information in its sub-domain, transfer the messages between connected domain routers and the basic router, and in case of the basic router failure, it can be replaced by one m-router (m1 or m2). To solve this tip, at the system start-up, one of the m-routers is elected as an alternative to the basic router to complete the tree management functions. The election process depends on the load on each m-router. (i.e. the load balance factor between management routers should be existed).

3.2 Load Balance Aspect

Two points of view as regards the load balance in the proposed hierarchy architecture should be demonstrated. The first one considers how other system routers will be distributed on the m1 and m2 management routers. The second is how the management functions will be distributed on the architecture main components. To clarify the first aspect, every m-router in the domain should have a general variable (counter) in its configuration file. This general variable will be incremented when the new router is connected to either m1 router or m2 router. Also, the link and the delay costs are taken in consideration. The last values of the general variable will be stored at the basic router to determine with which m-router the new host will communicate. The following algorithm describes the process:


1--Assume that router1 is connected to m1 router
2--The m1 router will increment its counter and send the new value
   to the basic router.
3--If ((m1.counter <= m2.counter) && (link delay and link cost are
    3.1 The basic router will send a confirmation message to m1
      router informing with a correct connection for the new
   4.1 The basic router sends a failure message to the m1 router
     informing it that the new router should communicate with m2
4.2 The m1 router sends a failure message of the basic router to
   the new router for changing its connection to m2 router.
5. End

Regarding the second load balance aspect, every m-router contains the application software to run its main function. Also, the m-routers contain applications to run a session and a group membership functions, but the state of these applications should be inactive and will be changed to be active at a recovery process only (i.e., at the basic router failure). In addition, the basic router contains applications for managing the multicast session and group membership. On the same idea, the basic router contains the inactive m-routers applications (note: inactive applications don't represent an overload on the system complexity).

3.3 Fault Tolerance Aspect

Firstly, one of the m-routers is elected from the basic router to recover it in case of failure occurrence. The election process depends on the load balance factor (i.e., each m-router). Assume that the m1 router is elected for this target (recovery of the basic router). The m1 router will communicate with m2 router using its IP address. The m1 router fires its inactive applications to manage the multicast session till the basic router is repaired. The m2 router sends its multicast sub-tree to the m1 router. The tree message, which is stated in the service-centric approach, is used for transferring the m2 multicast sub-tree to the m1 router. Hence, the m1 router merges the two sub-trees (m1 sub-tree and m2 sub-tree) in one multicast tree and the root of that tree will be the m1 router. Also, the m2 router sends a multicast message to its downstream routers informing them with the new state.

3.4 Multicast Tree Construction in Hierarchical Architecture

In the service-centric technique, the multicast tree is constructed virtually at the m-router. Consequently, the m-router sends a tree message to the downstream routers to start the physical construction of multicast tree. The main disadvantage of this technique is the complexity of the tree message. This complexity may lead to the loss of the tree message that causes a distortion in a multicast tree. So, our proposed idea is focused on how the multicast tree is constructed from downstream routers to upstream routers. Each router constructs a simple multicast tree and sends it to the upstream router that merges its downstream trees in one tree. This operation continues till the m-routers level. The m1 router and the m2 router construct their multicast trees. Consequently, the basic router will receive the two multicast trees from the m-routers and merge them. When a new host needs to join a group, it sends a group join message to its' upstream router and this message should be in continuous transferring until it finds the router that is responsible for the target group. This router will be called the target router. The target router upgrades its routing entry and sends a message to the m-router (m1 or m2). Accordingly, the m-router (the root of the new host) sends a message to the basic router informing it with the change that should be done in the multicast tree and routing entries. The construction of the simple trees and group joining operations will be done simultaneously.

3.5 Basic Router vs. Domain Routers

The contact of system routers occurs only in relation to the m-routers (m1 and m2). When a communication between a system router and its m-router fails, it takes a permission to contact the basic router to recover the error by changing the m-router for that router or recover the failed connection (i.e. domain routers are not authorized to contact the basic router except in case of a failure occurrence). So, each router should have the IP address of the basic router under conditional communication. The communication permission and restriction are built in the configuration file that will be installed at each system router. These permissions are adapted to be inactive in the stability state, but they are fired in the failed communication state.

3.6 Case Study for Hierarchical Architecture

To investigate our idea, a case study for constructing the multicast tree is demonstrated. A simple internet topology that may be found at any ISP is assumed. This can describe how the three management routers accomplish their functions in the multicast tree. The Delay Constrained Dynamic Multicast (DCDM) algorithm is used to construct a multicast tree with link delay and link cost considerations. It is known that the DCDM algorithm can resolve the loops resulting in the supposed tree topology [7]. The output of DCDM algorithm execution is two multicast sub-trees; one for each m-router. Group joining and leaving is also discussed. The proposed topology contains 9 nodes, numbered from 4 to 13, with 3 management routers that are numbered as follows: 0 for the basic router, 1 for the m1 router, and 2 for m2 router. The topology contains three groups called G1 {4, 7, 12}, G2 {5, 8, 9}, and G3 {6, 10, 11}. The values of delay and cost on each link are denoted, as shown in Fig. 1.a. To apply our idea in this case study, two steps should be clarified: 1- Extraction of multicast tree using the DCDM algorithm and solving the resulting loops, see Fig. 1.b. 2- Transformation of the multicast tree into two sub-trees one for each m-router, see Fig. 1.c. It's notable that the loops in the supposed topology, which are extracted after applying the DCDM, are (m1, m2), (m1, 5), (4, 5), (8, 9), (9, 10), (10, 11), (11, 12), and (7, 12) (denoted with dotted line). After the loops are deleted, the multicast tree is extracted. Therefore, the resulting tree is transformed into two sub-trees, taking into consideration three factors: the load balance, the link delay, and the link cost. So, the first sub-tree is for m1 router and contains nodes 4, 7, 8, and 12. The second sub-tree, which resulted by division too, is for m2 router and contains nodes 5, 6, 9, 10, and 11. Assume that the router number 13 needs to join G2. It should contact the router number 8 for load balance factor and without neglecting the other two important factors (the link delay and the link cost). The general variables, which stored at the basic router (B0), determine the number of routers (or hosts) at each m-router. If a new router tries to contact router 5 or router 9, it will be redirected to router 8 by m2 router, see Fig. 1.d. Suppose that the router 11 needs to leave the group G3 it should send a prune message to the router 6 that is considered the group manager (or tracer). Hence; the router 6 sends an update message to m2 router that sends the same type of message to the basic router, see Fig. I.e. By using this technique each sub-tree will be upgraded to the new state.

4. Our Fully Distributed Architecture

It's notable that the service-centric architecture is fully centralized and the hierarchical architecture is considered semi-centralized due to the basic management router idea. So, architecture with no centralization idea should be proposed and compared to the service-centric and the hierarchical architectures. The third architecture, which have been proposed in [25], is called fully distributed.

4.1 Architecture Components

Simply, the proposed fully distributed architecture has three m-routers. The domain of ISP is divided into three parts. The first part is for the first management router (m1); the second part is for the second management router (m2); and the third part is for the third management router (m3). The privileges and the restrictions are equal in the three management routers. Also, the factors that should be taken in consideration during other system routers distribution are the link cost, the link delay, and the load balance. When a new router needs to connect the system, it should send a multicast message to its up-level routers for changing its multicast sub-tree. This operation is done persistently till one of the management routers sense the last updates in the routing tree. Each management router constructs its multicast sub-tree (i.e. it is considered a root for the constructed routing sub-tree). A master and its alternative management routers are elected from the three management routers simultaneously. The election process for fault tolerance aspect depends mainly on the load balance factor. After the election process, a multicast message, which contains master and spare management routers addresses, is sent to other routers in the system. The load balance aspect in the fully distributed architecture is the same as in the hierarchical architecture.

4.2 Multicast Tree Construction in Fully Distributed Architecture

Each router in the system constructs a simple multicast tree (sub-tree) and sends it to the upstream router that merges its downstream trees in one tree. This operation continues till the m-routers level. Each m-router constructs its sub-tree. The elected master m-router receives the two sub-multicast trees from other management routers (considered m2 and m3 if m1 is the master management router) and merges them. When a new host needs to join a group it sends a group join message to the upstream router and this message continues transferring until it finds the router that is responsible for the target group. This router will be called the target router. The target router upgrades its routing entry and sends a message to the m-routers.

4.3 Case Study for Fully Distributed Architecture

The proposed topology contains 13 nodes, numbered from 1 to 13, with 3 management routers that are called m1, m2, and m3. Similarly, the values of delay and cost on each link are denoted, as shown in Fig. 2.a. Firstly, the routers are normally distributed on the three management routers. As shown in Fig. 2.a, m1 manages routers 5, 12, 2, 1, and 4, m2 manages routers 11, 6, 9, and 3, and m3 manages routers 13, 7, 10, and 8. The topology contains three groups called G1, G2, and G3 (G1 {7, 8, 0, 12, 5}, G2 {9, 6, 11, 13}, and G3 {1, 2, 3, 4}). Fig. 2.b shows the resulting tree after the DCDM algorithm is applied. Assuming that the m1 router is elected as a master router, the resulting multicast tree constructed by m1 router is shown in Fig. 2.c. The new routers connection and deletion processes are the same as in the hierarchical architecture case study.

5. General Aspects for the Proposed Architectures

In this section, the shared aspects for the two proposed architectures are demonstrated. These aspects are; the additional architectures messages, the routers configuration upgrades, and the architectures advantages.

5.1 Architectures Messages

The proposed architectures contain three new types of messages; the multicast tree construction message, the tip message, and the fail message. These messages should be simple to guarantee that the demonstrated architectures don't cause an overload when compared with the service-centric approach.

* Multicast tree construction message

This message is sent from the downstream router(s) to the upstream router(s). This message contains the IP addresses of the downstream routers. This type of message is sent in unicast mode.

* Tip message

This message is sent to the system routers in two cases. The first case: when one from m-routers is failed, the basic router or the elected master router sends this message to the domain routers to inform them with the new state. The second case: when the basic router or the elected master router is failed, the alternative router that recovers the basic router sends this message to its domain routers informing them with the new management state. This type of message is sent in multicast mode.

* Fail message

The basic (or master) router sends this message to the m1 router informing it that the new router should communicate with m2 router. This message contains the IP address of the new router and identity field. This type of message is sent in unicast mode.

5.2 Router Configuration Upgrades

There are upgrades that should be done in the configuration file of system routers. The IP addresses that should be added to this file of domain routers are; the basic router or the elected master router IP address that will be used only at the recovery process in addition to m1 router or m2 router address that will be used to connect the sub-domain. Also, the IP addresses that should be added to the configuration file of the management routers (in case of many management levels). To complete the management functions, and recovery process, each router in the three management routers should have the IP addresses of other two routers. There is a general variable that is inserted only at the basic router or the elected master router, and will be incremented with one when a new router is connected to the domain.

In addition, for simplicity, the routing table, which is constructed in each router, should logically contain two main parts; Local Level Routing Table (LLRT) and Global Level Routing Table (GLRT). The LLRT contains information about routers and destinations in the same area with which each router is found. The GLRT contains information about routers in the higher levels areas. Both routing table parts are dynamically updated. Trees, which are constructed in the up-levels routers, should consider a shortest path for each router in the internetworking system. The shortest path should provide a feasible and a reliable connection to destination. The routing table entry should be reduced to decrease the complexity of sub-trees merging process especially in large networks.

5.3 The Advantages of the Proposed Architectures

* Fault tolerance guarantee

The proposed architectures have an alternative for each management router (ml, m2, and basic). Hence, if the basic router or the master router is failed, m 1 router or m2 router can take place. Also, if one m-router is failed the basic router can manage its sub-domain till repairing process is accomplished.

* Scalable architectures

It is notable that our architectures idea is built on division of ISP domain into two or three parts one for each m-router. So, they can receive duplicated number of routers comparable to the service-centric idea. Also, the simulation proof that the maximum end-to-end delay is approximately fixed while the group size increases, see Section 7.

* Low hardware complexity

The basic or the elected master router needs only two ports to communicate with the downstream routers (m-routers). The m-routers need n/2 (n/3 for fully distributed architecture) ports to manage its sub-domain routers, where n is the number of routers in the ISP domain.

* Low required bandwidth

It is notable in the two proposed architectures that the load on each m-router is decreased. Consequently, the number of management messages will be decreased, hence; the required bandwidth for this link also will be decreased. In addition, the tree message, which is used in the service-centric approach, is too large. Hence; it requires more bandwidth than our system messages.

* No centralization drawbacks

The main drawback of centralized architecture is that all the system functions are accomplished by one node (i.e., the scalability, reliability, and performance analysis of the system relies on the m-router). In our proposed architectures the management functions are distributed in balance with m1, m2, and m3 routers.

6. Summarization Table

7. Simulation and Evaluation

In the following subsections, the simulation environment that will be used to evaluate the hierarchical and the fully distributed architectures is introduced. In addition, the comparison between the two proposed architectures and service-centric architecture is demonstrated. Also, the obtained results are showed and discussed.

7.1 Simulation Setup

The general infrastructure of the simulation environment is taken from [27] with some minor changes that enhance the evaluation process. The topology that is used in the simulation setup is random topology generated by NS2 simulation package [28]. The network size is 1000 nodes. There is a source node sending one multicast packet per second. The group size varies from 10 to 100 and the group members are picked randomly. The total simulation time is 1 hour. Our simulation parameters are the tree cost, the tree delay, the end-to-end delay, and the protocol overhead with different delay environments. Nodes are randomly arranged in a square area with uniformly distributed values for x and y. The size of the square is 45,831 by 45,831 m2. x and y are random integers between 0 and 45,831. The probability that exists an edge and connecting a pair of nodes u and v is P(u,v) = [beta] * e -d(u,v)/[alpha]L where d(u,v) is the Manhattan distance between u and v. d(u,v) = [absolute value of xu-xv] + [absolute value of yu-yv]. L is the maximum Manhattan distance between any two nodes, which is 2 * 45,831. [alpha] and [beta] are two adaptive parameters. The relation between [alpha] and the number of edges among far away nodes is a direct correlation. Also, the relation between [beta] and the degree of each node is a direct correlation. The link cost value of an edge is equal to the Manhattan distance between the two nodes, and the link delay value of an edge is equal to uniformly distributed random variable between 0 and the link cost value of the edge. In our simulation, [alpha] = 0.32, and [beta] = 0.3. The figures are plotted based on an average of 10 values from 10 different simulations. The delay constraint has two levels: tight and moderate [27]. The tightest level means that there is no multicast tree satisfying the delay constraint. The moderate level means that part of multicast sub-trees can satisfy the delay constraint.

7.2 Results

This subsection discusses the obtained results. The parameters used to test the three architectures are; tree delay, tree cost, data overhead, and maximum end-to-end delay.

* Tree delay

The first simulation parameter is the tree delay. Fig. 3 shows that regardless the level of delay constraints (tight and moderate), the two proposed architectures have shorter delay than the service-centric. As the group size increases, the tree delay of the hierarchical and the fully distributed architectures increases with rates less than the service-centric architecture. Fig. 3.a doesn't notably differentiate between the two proposed architectures when the delay constraint level is tight. But, at Fig. 3.b it is notable that tree delay of the fully distributed architecture is much shorter than the hierarchical architecture in case of moderate delay constrain level. This is due to the complete elimination of the centralization idea from the fully distributed architecture.

* Tree cost

The second parameter is the tree cost. From Fig. 4 it is clear that the tree cost for the three multicast architectures increases as the group size increases. The service-centric architecture has the highest increase while the fully distributed architecture has the lowest. Fig. 4.a shows that there is a minor difference between the hierarchical and the fully distributed architectures in case of tight delay constraint level. Fig. 4.b shows that the difference in tree cost between the two proposed architectures is increased in case of moderate delay level.

* Data overhead

Data overhead can be defined as the network bandwidth used by the data packets. A data packet going through one link contributes the link cost units to the data overhead. Fig. 5 shows the difference between the three multicast architectures as regards data overhead. It is notable that the fully distributed architecture has the lowest data overhead. This is due to the sub-trees construction sent from routers at a certain level to routers at an upper level. Also, Fig. 5 shows a minor difference between the hierarchical architecture and fully distributed architecture. This is because, for the fully distributed architecture a multicast tree is constructed with cooperation between the three management routers and the elected master router already has a part from the final tree that decrease the transmitted data overhead. But, in case of the hierarchical architecture, the multicast tree is constructed at the basic router from scratch which requires additional data packets. As the group size increases, the difference between the two proposed architectures increases and this is notable at node degree 3 (i.e. point number 3).

* Maximum end-to-end delay

Maximum end-to-end delay is defined as the maximum delay experienced by the packets from the source to the group members. The maximum end-to-end delay is tested with different group sizes. Fig. 6 shows that the maximum end-to-end delay resulted by the hierarchical architecture is lower than the service-centric architecture and slightly higher than the fully distributed architecture. This is because in the service-centric architecture, packets are sent first to the core router if the source node is not on the tree, while in the two proposed architectures, packets are sent from the source node directly to the up-level router that is responsible for group members. The minor difference between the proposed architectures is due to the communication between the system routers and basic router in case of the hierarchical architecture, and the communication between the three management routers and other system routers in case of the fully distributed architecture. Also, it is clear from Fig. 6 that the maximum end-to-end delay is approximately fixed while the group size increases. The fixed maximum end-to-end delay means that the two proposed architectures are scalable.

8. Conclusion

Multicasting is a key service for many internet applications. Traditional multicast architectures have the difficulty of building efficient multicast tree due to lack of complete information about the network structure. Service-centric approach treats some drawbacks of traditional approach, but suffers from the drawbacks of the centralization idea. This work proposes two new modifications in the service-centric multicast architecture; namely: hierarchical and fully distributed architectures. The proposed modification replaces the service-centric m-router by three sub m-routers with specific functions, management, and interconnection strategies. Simulation results showed that the performance of the proposed architectures outperforms that of the service-centric approach for all the test parameters. The average tree cost is enhanced by 8.31986 % for tight delay constraint level and 14.13483 % for moderate delay constraint level. The average tree delay is enhanced by 17.45544 % for tight delay constraint level and 19.57238 % for moderate delay constraint level. The average data overhead is enhanced by 20.38053 %. The average of maximum end-to-end delay is enhanced by 16.15881% and it is nearly while the group size increases. In all cases, it was found that the performance of the fully distributed architecture is better than that of both hierarchical and service-centric architectures.

9. Future Work

To further improve this work, mathematical models for the service-centric, the hierarchical, and the fully distributed architectures should be proposed. Hence, the simulation results will be compared with those of mathematical models.

Received May 5, 2013; revised July 31, 2013; accepted September 4, 2013; published September 30, 2013

This paper is an extention of another paper, which was published at International Arab Conference on Information Technology (ACIT), 2011 and more than 30 percent substantial new contributions added in the manuscript.


[1] C. Chen, L. Jia and B. Loo, "Wenchao Zhou, Reduction-based security analysis of Internet routing protocols," IEEE International Conference on Network Protocols (ICNP), Austin, USA, pp.1-6, Oct. 30 to Nov. 2, 2012. Article (CrossRef Link).

[2] J. Xu and X. Zhu, "Aware Routing Protocol for MANET Accessing Internet," in Proc. of Eighth IEEE International Conference on Dependable, Autonomic and Secure Computing, Chengdu, China, pp. 571-574, 2009. Article (CrossRef Link).

[3] S. Malik, K. Srinivasan and S. Khan, "Convergence time analysis of open shortest path first routing protocol in internet scale networks," IEEE Electronics Letters, vol. 48, no. 19, pp. 1188 1190, 2012. Article (CrossRef Link).

[4] O. Schoeneich and M. Golanski, "Mesh Cluster Based Routing Protocol: Enhancing Multi-hop Internet Access using Cluster paradigm," in Proc. of the International Conference on Computer as a Tool, Warsaw, Canada, pp. 962-965, 2007. Article (CrossRef Link).

[5] L. Lin, "Multicast routing algorithm for DSN network," in Proc. of the IEEE International Conference on Computer Application and System Modeling (ICCASM), China, pp. 516-520, 2010. Article (CrossRef Link).

[6] B. K., "Multicast Communications Supporting Shared Applications," Product Manager Spirent Communications, 2005.

[7] D.Waitzman and C. Partridge, "Distance Vector Multicast Routing Protocol," RFC 1075, 1988. http://www.ietf. org/rfc/rfc1075.txt

[8] J. Moy, "Multicast Extension to OSPF," RFC 1584, 1994.

[9] J. Moy, "OSPF version 2," RFC 2328, 1998.

[10] Y. Yang, et. al., "A Service-Centric Multicast Architecture and Routing Protocol," IEEE Transactions on Parallel and Distributed Systems, vol. 19, no. 1, pp. 35-51, 2008. Article (CrossRef Link).

[11] A. Ballardie, B. Cain and Z. Zhang, "Core Based Trees (CBT version 3) Multicast Routing," Internet draft, 1998.

[12] S. Deering et al., "Protocol Independent Multicast-Sparse Mode (PIM-SM): Motivation and Architecture," 1996.

[13] R. Perlman et al., "Simple Multicast: A Design for Simple, Low-Overhead Multicast," Internet draft, 1999.

[14] P. Wg, A. Adams, J. Nicholas and W. Siadak, "Protocol independent multicast-dense mode (PIM-DM): protocol specification," Internet draft, 2004.

[15] B. Waxman, "Routing of multipoint connections," IEEE Journal Selected Areas in Communications (JSAC), vol. 6, no. 9, pp. 1617-1622, 1988. Article (CrossRef Link).

[16] L. Shrivastava, S. Dauria and G.Tomar, "Performance Evaluation of Routing Protocols in MANET with different traffic loads", in Proc. of IEEE International Conference on Communication Systems and Network Technologies, Jammu, India, pp. 13-16, 2011. Article (CrossRef Link).

[17] S. Santhi and G. Sadasivam, "Performance Evaluation of Different Routing Protocols to Minimize Congestion in Heterogeneous Network" in Proc. of IEEE International Conference on Recent Trends in Information Technology, India, pp. 336-341, 2011. Article (CrossRef Link).

[18] C. Ionela, V. Croitoru1 and A. Popescu2, "Comparative Performance Evaluation of IPSAG and HC-IPSAG Cognitive Radio Routing Protocols," International Symposium on Signals, Circuits and Systems (ISSCS), Romania, PP. 1-4, 2011. Article (CrossRef Link).

[19] Y. Hachisuka, H. Hasegawa and K. Sato, "Design algorithm of waveband multicast tree in hierarchical optical path networks that utilizes grouping of destination node sets," SPIE Proceedings Hierarchical and Heterogeneous Optical Networks, China, pp. 1-6, 2011. Article (CrossRef Link).

[20] F. Wang, Y. Xiong and J. Liu, "mTreebone: A Collaborative Tree-Mesh Overlay Network for Multicast Video Streaming," IEEE Transactions on RANSACTIONS ON Parallel and Distributed Systems, vol. 21, no. 3, pp. 379-392, 2010. Article (CrossRef Link).

[21] T. Polishchuk et al., "Scalable Architecture for Multimedia Multicast Internet Applications," IEEE International Symposium, World of Wireless, Mobile and Multimedia Networks (WoWMoM), San Francisco, Canada, pp. 1-6, June 25-28, 2012. Article (CrossRef Link).

[22] F. Silva et al., "On the Analysis of Multicast Traffic over the Entity Title Architecture," in Proc. of IEEE International Conference on Networks (ICON), Singapore, pp. 30-35, Dec. 12-14, 2012. Article (CrossRef Link).

[23] S. Jardim, "Enhancing Dependability in Future Internet Systems by Applying Over-Provisioning Centric Resource Allocation Control," IEEE International Conference on Computing, Networking and Communications (ICNC), San Diego, CA, pp. 1134-1138, Jan. 28-31, 2013. Article (CrossRef Link).

[24] A. Atlas et al., "An Architecture for Multicast Protection Using Maximally Redundant Trees," Internet Draft, July 12, 2013.

[25] O. Said, A. Ghiduk and S. Aljahdali, "On Internet Multicast Architectures: Full Distributed and Hierarchical Vs Service-Centric," in Proc. of the international Arab Conference on Information Technology (ACIT), Riyadh, KSA, pp.13-19, 2011. content&task=view&id=328&Itemid=524

[26] L. Xiao-yong and G. Xiao-lin, "Merging Source and Shared Trees Multicast in MPLS Networks," in Proc. of Seventh International Conference on Parallel and Distributed Computing, Applications and Technologies (PDCAT'06), Taiwan, pp. 23-28, 2006. Article (CrossRef Link).

[27] M. Yang and Y. Yang, "Constructing Minimum Cost Dynamic Multicast Trees Under Delay Constraint," in Proc. of 14th IEEE International Conference on Computer Communications and Networks (ICCCN), USA, pp. 133-138, 2005. Article (CrossRef Link).

[28] The Network Simulator-ns-2, 2011, doc.pdf

Omar Said

Department of Computer Science, College of Science, Menofia University

Menofia 32511-Egypt.


* Corresponding author: Omar Said

Omar Said has earned BS degree from Menofia University in Egypt, Master's degree in Computer Science from Menofia University, Egypt in 2002 and Ph.D degree from the Menofia University, Egypt in 2005. He has served as an Assistant Professor in Computer Science Department, College of Computers and Information Technology, Taif University, KSA. Now he is with College of Science, Menofia University, Egypt as Assistant Professor in Dept. of Computer Science. His interested research areas are: Internetworking, Internet of Things, Sensor Network, Routing Protocols, Real Time Communication, and Network Management.

Table 1. Comparison between the service-centric, the hierarchical,
and the fully distributed architectures

Parameter             Service-    Hierarchical          Fully
                      Centric                        Distributed

Centralization          Yes            No                 No
Fault Tolerance          No            Yes               Yes
Load Balance             No            Yes               Yes
Simplicity              Yes            Yes               Yes
Tree Construction       Yes            Yes               Yes
Hardware Complexity     High        Less than         Less than
                                 Service-Centric     hierarchical
                                                   [Moderate Delay]
COPYRIGHT 2013 KSII, the Korean Society for Internet Information
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2013 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Said, Omar
Publication:KSII Transactions on Internet and Information Systems
Article Type:Report
Date:Sep 1, 2013
Previous Article:Autonomous deployment in mobile sensor systems.
Next Article:Compressed sensing-based multi-layer data communication in smart grid systems.

Terms of use | Privacy policy | Copyright © 2022 Farlex, Inc. | Feedback | For webmasters |