Interactive Multicast Framework Between Wireless Mesh Networks

Published Date: 02 Nov 2017

Optimize the performance of the wireless mesh network must take into account dealing with other networks such as the Internet, Therefore necessary to make a Framework allows for linking networks in efficient way, In this paper we present an interactive Multicast Framework linking Wired Internet and wireless mesh networks .The proposed structure will work in a complementary and appropriate way between the two networks

Keywords

Multicasting, WMN, Optimal, Framework

1.INTRODUCTION

WMN consist of mesh routers, mesh hosts and access point which acts the interaction between WMN and Wired Internet therefore such technique which join between the networks has to be exist, The contribution of the paper is :

Transparency of hosts’ locations. Communications between an Internet host and a mesh host require assistance from access points. On the other hand, mesh hosts located in the same WMN may send data to each other via mesh routers without involving the access points (APs). These two routing scenarios imply that we would need a mechanism to signify the locations of the communicating hosts (i.e., in the Internet, in the same WMN or in another WMN) in order to use the appropriate routing method (i.e., with or without assistance from APs). One such mechanism would be to create different IP address formats for hosts in the Internet and hosts in WMNs respectively. This approach would require efforts to define the address formats and to standardize them. An alternative would be to let a host advertise its location (in the Internet or in a WMN) to other hosts. This mechanism would create traffic overhead in both the Internet and WMNs. Considering the above disadvantages, we designed a multicast framework that does not require any knowledge of host locations. Yet it effectively supports communications between the Internet hosts and mesh hosts via access points, and multi-hop ad hoc communications between mesh hosts residing in the same WMN.

No changes to Internet multicast routing. The framework does not require any modifications to the current IP multicast model in the Internet, nor to the existing multicast routing protocols in the Internet. Multicast routing in the wired network can use any of the existing Internet routing protocols such as DVMRP, MOSP, PIM, or CBT. This enables the framework to be deployed quickly and interact seamlessly with the IP multicast and the existing Internet multicast routing protocols.

2.The Multicast Framework

We first present the network model used to design on multicast framework and multicast protocols. Then, we describe the multicast framework in detail.

2.1 Network Model

The WMN consists of wireless mesh routers, which form the mesh backbone, and wireless mesh hosts located at the edge of the mesh backbone. The mesh backbone is connected to the Internet via access points (or gateways). An access point (AP) communicates with Internet routers/hosts via its wired interface(s), and with mesh routers in the same WMN via the wireless interface(s). There may be more than one access point (AP) in an WMN, depending on the size of the WMN, so that the task of relaying data between the Internet and the WMN does not overload a single AP. When there are multiple APs in a WMN, each AP may be assigned to serve as a gateway for a set of particular mesh routers. We call this AP the serving AP of those mesh routers. A set of mesh hosts "connected" to a mesh router may form a wireless LAN or a mobile ad-hoc network (MANET). In this paper, we assume wireless LANs at the edge of a mesh backbone for the sake of simplicity. When a mesh router and its attached the mesh hosts form a wireless LAN, the mesh hosts express their desires of joining/leaving a multicast group using a protocol similar to IGMP (Internet Group Management Protocol) [1].

Each mesh host is assigned an IP address, and similarly for each mesh router. A multicast session is assigned a multicast group ID (a multicast IP address) as currently done with multicasting on the Internet [2]. A receiver, either an Internet host or a mesh host, needs to know the multicast group ID of a multicast session in order to join or leave the multicast group. A sender, either an Internet host or a mesh host, simply multicasts the data without requiring any knowledge of group membership. This scalable multicast model is currently used in IP multicast. Multicasting in the wired network can use IGMP [1], IP multicast, overlay multicast [3], and any of the existing multicast routing protocol such as DVMRP, MOSPF, PIM or CBT. Multicast inside the mesh backbone is supported by the MeshSPT protocol [4], as shown in the figure 1.

Figure1: the hierarchical level of multicast routing , Hierarchy assists scalability

2.2 The Multicast Framework

In this section, we present a framework that supports multicast routing between the Internet and WMNs. We can use any of the existing Internet multicast protocols such as DVMRP, MOSPF, PIM, or CBT for multicast routing in the wired network. Multicast routing inside a mesh backbone employs the proposed MeshSPT protocol. The framework specifies the interactions between access points, Internet hosts and mesh hosts to provide multicast services between the Internet and WMNs. In wired networks, IGMP [1] is used by Internet hosts to join/leave multicast groups. We assume mesh hosts use a similar mechanism to inform their direct mesh routers of their intention to join/leave a multicast group. Specifically, a mesh router connected to one or more mesh hosts periodically broadcasts IGMP like queries to its hosts. A mesh host wishes to join (or leave) a multicast group indicates its wish in the replies to its direct mesh router as in IGMP. A mesh host may also send an "out-of-order" join or leave request to its direct mesh router in order to speed up the join/leave process. We consider the following issues in designing the multicast framework:

Transparency of members’ locations.

If the sender of a multicast group is an Internet host and a receiver is a mesh host (or vice versa), data from the sender must go through an AP of the WMN in which the mesh host resides. On the other hand, if both the sender and the receiver are located within the same WMN, then no AP would need to be involved in forwarding data packets from the sender to the receiver. (APs are concentrated traffic points between the Internet and WMNs; thus any task that can be moved away from an AP enhances the scalability of AP functionality). This would require some mechanism, such as different IP address formats for members in the Internet and members in WMNs respectively, to indicate where a multicast group member is located. (This mechanism would limit the flexibility of assigning IP addresses to multicast groups and/or senders. Also, the standardization of IPv6 IP addressing format is still in progress [5],and we are not able to make any assumptions about the address formats.) Therefore, we designed our multicast framework and the MeshSPT protocol in such a way that they do not require knowledge of the members’ locations.

No changes to Internet multicast routing.

Multicast routing on the Internet should be kept as same as it is. That is, no modifications to the existing Internet routing protocols or IP multicast are needed.Following is the detailed description of the multicast framework. Assume a multicast group G with a sender S. We consider all cases in which senders and receivers can be either Internet hosts or a mesh hosts:

Case 1: The sender is an Internet host

Case 1(a): A receiver is an Internet host

Case 1(b): A receiver is a mesh host in a WMN

Case 2: The sender is a mesh host

Case 2(a): Some receivers are mesh hosts in the same WMN as the sender

Case 2(b): Some receivers are Internet hosts

Case 2(c): Some receivers are mesh hosts in other WMNs

Following are the procedures for establishing a path between a sender and a receiver as dictated by the above cases.

Case 1: The sender is an Internet host.

A receiver may reside in the Internet or a WMN.

Case 1(a): If a receiver is an Internet host, it joins the multicast group by responding to the IGMP messages sent by its direct router [1]. Any existing Internet multicast routing protocol, such as DVMRP, MOSPF, PIM, or CBT, can then be used to enable the receiver to receive data from the sender. No modifications to the routing protocol or IP multicast are required.

Case 1(b): If a receiver is a mesh host in a WMN, it sends a join request to its serving AP. The AP sends back a reply to let the mesh host know that the AP will be the source of a multicast tree in the mesh backbone. The AP then joins the multicast session in the wired network using an Internet multicast routing protocol (e.g., MOSPF). The receiver invokes the proposed MeshSPT protocol [4] to build a path from the AP to itself in a multicast tree in the mesh backbone. After the AP receives data packets from the Internet sender, the AP multicasts them to the mesh host using the multicast tree constructed by the MeshSPT protocol. Figure 2 shows an example of Case 1(b) in which four mesh hosts R1, R2, R3 and R4 wish to join the multicast session whose sender is the Internet host S. Access points AP1 and AP2 join the multicast group in the Internet via their wired interface. AP1 then becomes the source of a multicast group in the WMN whose receivers are R1 and R2. The multicast tree rooted at AP1 is built by the MeshSPT protocol. Similarly, AP2 is the source of multicast receivers R3 and R4. Note that in the above example, the WMN has two APs so that the task of relaying data between the Internet and the WMN is distributed among them for best performance. A mesh router can select a serving AP statically or dynamically based on some criterion such as shortest path (static), least overloaded AP or least congested path (dynamic).

Figure 2: The sender is an Internet host; receivers are in the WMN (Case 1(b))

Case 2: The sender is a mesh host.

The sender must first send a message to its serving AP in the mesh backbone, indicating its intention to start a multicast group by giving the AP the multicast group ID and its IP address. This AP then multicasts the information to the other APs in the same WMN via the wired interface.

Case 2(a): If there are receivers who are mesh hosts in the same WMN as the sender, we will establish a multicast routing tree that is rooted at the sender and reaches these mesh hosts. This is done as follows. Such a receiver will send a join

request to its serving AP that contains the multicast group ID. The AP replies with a message telling the receiver that the sender is a host residing in the same mesh and provides the sender’s IP address. After receiving the reply, the receiver invokes the MeshSPT protocol to establish a path from the sender to the receiver in the multicast tree. Figure 3 illustrates an example for the above scenario. The sender is mesh host S, which S first sends a message to its serving AP, AP2, to inform the AP of the multicast group ID and its IP address. AP2 forwards this information to AP1. When R1 wants to join the multicast group, it sends a join message to its serving AP, AP1, which will reply that the sender S is located in the same WMN and provides the ID of sender S. R1 then invokes the MeshSPT protocol to establish a path from S to R1 in the multicast tree. Mesh host R2 also joins the multicast group in a similar manner. Figure 2 shows a source-based tree rooted at S. Note that in this case the APs need not be involved in relaying the data from the sender S to the receivers. The purpose is to reserve their processing time and storage for communications between the Internet and the WMN.

Figure 3: The sender and receivers are in the same WMN (Case 2(a))

Case 2(b): If there are receivers, which are Internet hosts, then the AP serving the sender becomes the source of a multicast session in the wired network for those receivers. This multicast session can use any Internet multicast routing protocol (e.g., DVMRP, MOSPF, PIM, CBT). The AP is in turn a receiver of a multicast tree in the WMN that is rooted at the sender S. The AP receives data from sender S, and then multicasts it to the receivers in the wired network. Using the proposed MeshSPT protocol, the AP can join the multicast tree in the WMN when it has receivers in the Internet, and leaves the multicast tree when there are none. In Figure 4, AP2, the AP serving sender S, is the source of an Internet multicast session with Internet receivers R3 and R4. At the same time, AP2 is a receiver of a multicast group in the WMN whose source is sender S. After receiving data from S, AP2 multicasts the data to R3 and R4 via its wired interface.

Figure 4: The sender is a mesh host; receivers (R3 and R4) are Internet hosts (Case 2(b))

Case 2(c): If there are receivers who are mesh hosts in other WMNs, they send join requests to their serving APs, which will join the Internet multicast session whose source is the AP serving the sender. After receiving data packets from this source, the relaying APs then multicasts them to their mesh hosts. In summary, when the sender is a mesh host, the AP serving the sender and receivers residing in the same WMN join a multicast tree rooted at the sender. The AP then forwards the data received from the sender to Internet hosts or

mesh hosts in other WMNs. When the sender is an Internet host, a receiver in a WMN joins a multicast tree rooted at its serving AP, which relays data from the Internet sender to the receiver. The proposed multicast framework simplifies the interactions between mesh hosts and Internet hosts: we do not need a mechanism to distinguish whether a sender/receiver is an Internet host or a mesh host. Note that all unicast messages used in the above framework must be delivery guaranteed. We assume that there is a transport protocol that supports reliable

delivery of these unicast messages.

Conclusion

In this paper, We describe the proposed multicast framework that supports the interaction in multicasting between the Internet nodes and the mesh nodes in WMNs. The framework requires neither any knowledge of multicast members’ locations or any modifications to the existing Internet multicast routing protocols or IP multicast. This allows the proposed framework to be incorporated quickly and seamlessly into the existing Internet multicast mechanisms.