WiFIX+: A Multicast Solution for 802.11-based Wireless Mesh Networks Rui Campos, Carlos Oliveira, José Ruela INESC Porto and Faculdade de Engenharia Universidade do Porto Rua Dr. Roberto Frias, 378 4200-465 Porto Email:
[email protected]
Abstract—IEEE 802.11 is currently one of the main wireless technologies enabling ubiquitous Internet access. With the growing demand for wireless Internet access and the limited 802.11 radio range, 802.11-based Wireless Mesh Networks have been proposed as a flexible and cost-effective solution to extend the radio coverage of existing network infrastructures. Many solutions have been proposed to create Wireless Mesh Networks automatically. However, they are either too complex or deal with multicast traffic inefficiently using pure flooding. We propose a simple and efficient solution, called WiFIX+, to forward multicast traffic over 802.11-based Wireless Mesh Networks. It is based on WiFIX, an existing solution targeted at unicast traffic and extends it with new mechanisms. WiFIX+ was implemented and evaluated in a laboratorial test-bed. The experimental results obtained show that it outperforms IEEE 802.11s, the reference solution for 802.11-based Wireless Mesh Networks, as far as data throughput, delay, and packet loss are concerned.
I. I NTRODUCTION The Internet has become the global communication infrastructure supporting a myriad of applications and services. These include multicast applications and services such as IPTV and audio/video conferencing, which increasingly require broadband access anytime, anywhere. IEEE 802.11 is the most common technology used for broadband wireless network access. However, the radio coverage provided by this technology is limited and the installation of many Access Points (APs) connected to a wired infrastructure is required to cover a wide geographical area. This may be a costly solution. In order to overcome the problem, Wireless Mesh Networks (WMNs) have been proposed as a solution. In a WMN the nodes cooperate with each other wirelessly to forward packets between source and destination nodes that are not in radio range, as shown in Fig. 1. WMNs are seen as a flexible, cost-effective solution, with low complexity. Several solutions have been proposed to create WMN automatically. IEEE 802.11s [1] is the current IEEE standard targeting 802.11-based WMNs. It uses pure flooding to deliver multicast traffic. More recently, a new solution, called Wi-Fi Network Infrastructure eXtension (WiFIX) was proposed [2]. WiFIX deals with unicast traffic more efficiently than 802.11s, but has not been optimized for multicast traffic. Specific solutions have been defined to cope with multicast over WMNs [3][4][5][6][7][8][9]. Yet, they introduce too much complexity
when it comes to the wired infrastructure extension scenario. In this paper, we propose a new solution, called WiFIX+, which extends WiFIX with new mechanisms to efficiently handle multicast traffic. In addition, it supports terminal mobility without requiring changes to the terminals attaching to the WMN. Our contribution is two-fold. Firstly, we propose a new multicast solution for WMNs. Unlike most of the state of the art solutions, which simply flood multicast traffic over the WMN, WiFIX+ defines a multicast selective forwarding mechanism, where only the nodes that belong to a multicast group receive the corresponding frames. Secondly, as part of WiFIX+, we propose a mobility management mechanism based on a new application of the DHCP snooping technique, usually employed in network access control; it does not require any modification to terminals. The rest of the paper is organized as follows. Section 2 states and illustrates the problem, Section 3 presents some background information required to understand the proposed solution, and Section 4 presents the related work. Section 5 details the WiFIX+ solution and Section 6 describes its implementation under Linux OS. Section 7 deals with the WiFIX+ evaluation and, finally, Section 8 draws the conclusions and points out future work. II. P ROBLEM S TATEMENT A WMN is used to extend the wired infrastructure to wireless terminals. Terminals shall have access to all applications and services available in the infrastructure, including multicast applications and services, which are the focus herein. From the WMN viewpoint, multicast applications and services consist of multicast flows between the wired infrastructure and the wireless terminals attaching to the WMN; here, we assume that the source of such multicast flows is always located in the wired infrastructure, since this is the major case envisioned for WMNs employed in the infrastructure extension scenario shown in Fig. 1. The problem to solve is then how to route multicast flows across the WMN towards the mobile terminals irrespectively of their location in each moment. Fig. 1 can be used to illustrate the problem using a concrete example. In this scenario, we have a WMN composed of five MAPs (Mesh Access Points). Consider that there is a multicast
Current infrastructure
Infrastructure extension
Mobile Terminal 2 UWB
WMN
MAP2 MAP3
Multicast Services
Step 1
Wi-Fi Network
MAP1
Mobile Terminal 1
Step 2
MAP4
(GMRP), but they are not used in practice. The default behavior of IEEE 802.1D bridges is to process multicast frames as broadcast frames. So, upon receiving a multicast frame an 802.1D bridge simply forwards it to all other ports except the incoming port, like they do to broadcast frames. Yet, this is not the most efficient approach, especially when only a small group of stations requested the corresponding multicast flow. B. IGMP Snooping
MAP5 Gateway Wi-Fi Network
Ethernet
Internet
Mobile Terminal 2
Figure 1: WiFIX+ reference scenario.
flow whose source is in the wired infrastruture network. This flow has to be delivered to the Mobile Terminals (MTs) 1 and 2, according to their current locations. In Step 1, MT1 is connected to MAP3 and MT2 to MAP2. Thus, within the WMN, the traffic has to be delivered to MAP2 and MAP3. In Step 2, MT1 moves to MAP4; therefore, the multicast flow has to be redirected to MAP4, as illustrated in the figure. III. BACKGROUND In this section, we review some important concepts related to WiFIX+, which uses the IEEE 802.1D forwarding mechanism, IGMP snooping to build group tables in order to support selective multicast frame forwarding and DHCP snooping for terminal mobility management. A. IEEE 802.1D Bridges IEEE 802.1D bridges [10] are ubiquitous in Ethernet switched Local Area Networks (LANs). They are also known as learning bridges since they do not define any explicit signalling messages to build and maintain the local forwarding tables. Rather, they learn the path to stations from the source address of data frames passing through. However, the use of this mechanism requires an active topology without loops, i.e. a tree. The Rapid Spanning Tree Protocol (RSTP) [10] has been defined to guarantee that the active topology is loopfree and to ensure proper operation of IEEE 802.1D bridges. RSTP deals with the automatic and dynamic configuration of an active tree network topology while ensuring redundancy. Frame forwarding is based on the analysis of the destination addresses of the frames. When a frame arrives to a bridge port, the bridge looks for the destination address in the forwarding table. If it is not found, a copy of the frame is sent to all ports, except the one it was received from. If it is found, the frame is forwarded only to the specific output port, if different from the input port; otherwise, it is discarded. IEEE 802.1D defines protocols to improve multicast frame forwarding efficiency, the Generic Attribute Registration Protocol (GARP) and the GARP Multicast Registration Protocol
The Internet Group Management Protocol (IGMP) is used by IPv4 systems to inform multicast routers about their associations or disassociations to groups. In its third version IGMP defines two types of messages: IGMP Query and IGMP Report. The IGMP Query is sent by multicast routers to inquire stations about their association state to one or more groups. The IGMP Report is sent by stations to multicast routers to report their will to receive multicast traffic related to a certain group. As a consequence of the default operation of IEEE 802.1D bridges, a new technique called IGMP snooping [11] was defined to work on IPv4 networks; a similar technique called Multicast Listener Discovery (MLD) snooping has been defined for IPv6 networks. Thus, switches that implement this technique snoop IGMP messages in order to find out where stations are located in the network. A switch is able to create a Group Table, associating group addresses to ports. Therefore, an incoming multicast frame can be forwarded only to the ports that are associated with the corresponding groups. In IGMPv3, the mechanism to build the group tables can be described as follows: • Every switch must maintain a Group Table that associates IP group addresses to ports; • When an IGMP Report (Join) message is received, the switch must add a new entry to the Group Table, associating the group address to the incoming port. If it already exists, the switch must update the entry, adding the incoming port; • Every entry must have a lifetime parameter to not depend on IGMP Report (Leave) messages to remove the entries. The data forwarding mechanism works according to the following procedure: • A data packet with the destination address type 224.0.0.X must be forwarded to all ports; • A data packet with multicast destination address different from 224.0.0.X should be forwarded according to the Group Table; • If the data packet destination address is not found in the Group Table, the packet should be forwarded to all ports, except the incoming port. If the network layer protocol is IPv6, the MLD snooping technique will be used. Further details on the operation of IGMP and MLD snooping may be found in [11]. C. DHCP Snooping When a terminal arrives to a new network, it broadcasts a DHCP DISCOVER message. In response, the terminal may
receive one or more DHCP OFFER messages. Based on the configuration parameters included in each DHCP OFFER message, the terminal selects one DHCP server. Then, the terminal broadcasts a DHCP REQUEST, in order to inform the selected DHCP server and notify the other servers that their offer was declined. Finally, the chosen DHCP server sends a DHCP ACK message with the configuration parameters, including the IP address assigned to the terminal, the default gateway address, and the DNS server address. DHCP snooping is a technique used by some switches to inspect DHCP messages and, by that means, perform network access control. Snooping switches are able to allow/deny access to a specific terminal, by analyzing the source MAC address of the DHCP message. If the corresponding MAC address is not allowed to have network access, the switch prevents the DHCP procedure from concluding successfully by filtering out the snooped DHCP message. IV. W I FIX WiFIX [2] reuses concepts such as 802.1D bridges and their simple learning mechanism for frame forwarding, and is based on a single-message protocol that enables the self-organization of the WMN. In order to support multi-hop forwarding within a WMN based on legacy IEEE 802.1D bridges, it defines a new encapsulation method, called Ethernet-over-802.11 (Eo11), which enables the creation of virtual links (Eo11 tunnels) between neighbor MAPs. The Active Topology Creation and Maintenance (ATCM) mechanism is used to create the virtual links; together they form the active tree topology rooted at the master MAP, the device directly connected to the wired infrastructure. ATCM works as follows. The master MAP periodically sends a Topology Refresh (TR) message, which is forwarded by all other MAPs, after changing some parameters (number of hops to the master, parent address, and original address of the frame). Each MAP selects a parent node in the tree rooted at the master MAP. The TR message is employed to both announce the master MAP and notify a node that it has been selected as parent in the tree. IEEE 802.1D bridges are used for packet forwarding on top of the active tree topology; they see the virtual links as common Ethernet links. WiFIX is focused on unicast traffic forwarding. However, it defines a new mechanism to deal with broadcast traffic, where only the nodes with more than one neighbor forward broadcast frames. Yet, it does not specify any particular mechanism to deal with multicast traffic. V. W I FIX+ State of the art solutions described in the literature to cope with multicast traffic in WMNs are inefficient and introduce unnecessary complexity. We propose here a new solution, called WiFIX+, which provides WiFIX with new mechanisms to deal with multicast. In addition, it considers the transport of multicast packets using unicast 802.11 frames, in order to take advantage of the higher data rates achieved in unicast1 . 1 E.g., in 802.11b the data rate for broadcast frames is 1Mbit/s, while the maximum data rate for unicast frames is 11Mbit/s.
For that purpose, it is assumed that the MAPs are deployed in a way that enables the use of the maximum unicast data rate; the location of each MAP may be set during the WMN planning phase. WiFIX+ was developed along three evolutionary phases. In the first phase, we considered the simplest mechanism, where multicast traffic is processed as broadcast and the Eo11 tunnels are used to transmit the multicast/broadcast frames. So, multicast traffic is delivered to all nodes, regardless of their association state to groups. Even though this already brings some advantages, it is not the most efficient solution. In the second phase, an improved method was defined, where only the requesting nodes receive multicast traffic for a given group. Finally, in the third phase, we introduced a further improvement to deal with mobility of terminals, which is inherently supported by the first mechanism but not supported by the one designed in the second phase. In what follows, we present the three mechanisms in detail. A. Multicast as Broadcast Taking into account the Eo11 tunnels created by WiFIX, the possibility of sending multicast frames through these tunnels was considered. This approach, called Multicast as Broadcast (MaB), has three main advantages. Firstly, in 802.11, broadcast frames are sent with the lowest bit rate defined by the given standard (802.11a/b/g/n). So, if multicast frames are encapsulated in unicast frames, they can be sent using the highest bit rate. Secondly, only one multicast/broadcast frame per link is sent, while in pure flooding every node retransmits once a broadcast frame is received. Thirdly, the use of unicast underneath implicitly guarantees reliability, provided by the IEEE 802.11 MAC layer. In MaB, when the bridge running in each MAP receives a multicast/broadcast frame, it will send a copy to each port, except the one the frame was received from. Every frame will be encapsulated using the Eo11 header and sent to each neighbor of the node. Thus, frames are not flooded in the network. Instead, they are sent to all nodes over the tree topology. B. Selective Multicast While simple, MaB has the disadvantage of sending multicast frames to all MAPs, regardless of the multicast group membership of the terminals attaching to each MAP. A more efficient solution, called Selective Multicast (SM), was then developed. SM allows the creation of multicast subtrees for each multicast group; each subtree is built upon the spanning tree created by the WiFIX ATCM mechanism by pruning the branches that do not have any terminal associated to the current multicast group. Each multicast packet is only delivered to the terminals requesting it; the spare bandwidth can be used by other flows, unicast and/or multicast, competing for the same network resources. SM can be divided in two stages, learning and forwarding. In the learning stage each MAP constructs group tables based on the IGMP/MLD snooping technique. In the forwarding stage, MAPs look up the group tables created,
so that a multicast packet is only forwarded to the ports with terminals associated to the corresponding multicast group. During the learning stage, each MAP examines the IGMP Report messages sent by terminals to multicast routers. The goal is to know from which neighbor a given MAP can reach the terminals that belong to a given group. Using IGMPv3 protocol as reference, the learning process works according to the following rules: • When a terminal wants to receive multicast traffic for a given group, it sends an IGMP Report message to multicast routers; • Upon receiving an IGMP Report (Join) message, each MAP creates a new entry in the Group Table with the following parameters: group IP address, MAC address of the neighbor the message was received from, and the entry lifetime. If the entry already exists, only the neighbor MAC address list is updated. The lifetime is set to the IGMP Query interval (by default 125 s) and is reset every time an IGMP Report message arrives to the MAP; • After updating the Group Table, each MAP forwards the IGMP Report according to the procedure used for multicast frames. Using the learning process, a multicast tree is built for each group. If every MAP supports a terminal that belongs to a given group, the multicast tree coincides with the tree created by ATCM. The multicast forwarding process works as follows: • If the destination MAC address corresponds to an IPv4 address such as 224.0.0.X, the multicast frame is forwarded to all neighbors except the one the frame was received from; • For all other multicast addresses, each MAP looks for an entry in the Group Table corresponding to the group address. If it exists, the MAP forwards the frame only to the neighbors included in that entry; • If the Group Table has no entries associated to the multicast IPv4 address of the packet, the multicast frame is dropped. For IPv6, the learning and the forwarding procedures are similar to the ones described above for IPv4. Still, MLD messages are inspected instead and IPv6 addresses are used to identify multicast groups in the Group Table. C. Selective Multicast with Mobility Support Despite its higher efficiency, SM does not support terminal mobility. When a terminal moves to a new MAP, the reacquisition of the multicast flow only occurs when a new IGMP Query sent by a multicast router triggers the terminal to send an IGMP Report that allows the update of the group tables. Thus, the flow reacquisition time is proportional to the period of the IGMP Query messages. So, a further improved mechanism built upon SM was developed. It is called Selective Multicast with Mobility Support (SMob). SMob uses the DHCP snooping technique to speed up the flow reacquisition and avoid changes in the terminals.
Upon attaching to a MAP for the first time, a terminal runs a DHCP client to configure IP connectivity automatically. If the terminal moves and re-attaches to the WMN through another MAP, it reruns the DHCP client. Since this time the terminal already has an IP address assigned, the DHCP client tries to keep the same address. It broadcasts a DHCP REQUEST including the IP address it wants to keep. Taking this into account, SMob works as follows: • When the DHCP REQUEST message arrives to the new MAP, the MAP adds a new entry in its Mobility Table with the following parameters: MAC address of the terminal, transaction ID of the DHCP message, and the entry lifetime; • When a DHCP ACK arrives, the new MAP looks up the Mobility Table using the transaction ID as primary key. If there is an entry matching the transaction ID of the DHCP ACK, the MAP creates a fake IGMP Query message and sends it to the terminal. This message forces the terminal to send an IGMP Report. Note that the fake IGMP Query is sent in unicast, at MAC level, in order to be received only by the terminal that has just attached to the new MAP. Upon the IGMP Query is sent, the new MAP removes the entry from the Mobility Table. • All frames that transport DHCP messages are forwarded according to their destination MAC addresses. In practice, some applications upon detecting a link change already send automatically an IGMP Report message. However, this is not a general procedure and is not even defined in the standard [12]. The solution presented herein allows faster multicast flow reacquisition for all applications. VI. W I FIX+ I MPLEMENTATION WiFIX+ was implemented under Linux Operating System (OS). Linux supports 802.1D bridges and provides the tools required to create virtual interfaces, which act as endpoints of the virtual links established between MAPs. Using these tools, WiFIX+ creates and deletes virtual interfaces and performs Eo11 encapsulation. The virtual interfaces act as ports from the Linux bridge2 viewpoint. Since ATCM used by WiFIX+ enforces a loop free topology, the spanning tree protocol is disabled. The WiFIX+ daemon seats between the virtual interfaces, represented by taps, and the wireless Network Interface Card (NIC). The virtual interfaces are implemented using tap interfaces enabled by the vtun module3 . Taps are virtual interfaces that behave like Layer-2 Ethernet devices for the upper layers. The WiFIX+ operation consists in reading frames from taps, processing and writing on the 802.11 physical interface, or the reverse sequence in the opposite direction; WiFIX+ accesses the physical interface using a Linux packet socket. A frame that arrives on a tap has an Ethernet header with the original source and destination MAC addresses. WiFIX+ processes the frame according to the type of destination 2 http://linux-net.osdl.org/index.php/Bridge 3 http://vtun.sourceforge.net
Figure 2: Test-bed used in the experimental tests.
MAC address (unicast, multicast, or broadcast), adds the Eo11 header, and sends it to the physical interface. In the opposite direction, when a frame arrives on the physical interface, and if the source MAC address in the Eo11 header corresponds to a neighbor, WiFIX+ removes the Eo11 header and delivers the frame to the tap associated to that neighbor. If the frame does not come from a neighbor, it is silently discarded. Afterwards, the forwarding is done according to the 802.1D bridge mechanism. Besides the taps, the bridge has, at least, the wireless interface used to serve terminals. The multicast/broadcast frame received on a tap is also forwarded to that interface by the bridge. If the frame received on the physical interface corresponds to a TR, it is not forwarded to the taps, because this is a signaling message only processed by WiFIX+. In MaB, multicast/broadcast frames are sent in unicast. When a multicast/broadcast frame arrives on the physical interface, the WiFIX+ daemon removes the Eo11 header and sends the frame to the tap related to the neighbor the frame was received from. Since the destination address is multicast/broadcast, the bridge sends a copy to all interfaces, except the tap the frame is received from. The WiFIX+ daemon verifies the taps, one at a time, encapsulates the frames in unicast and sends them to the neighbor associated to each tap. Thus, a MAP with n neighbors sends n − 1 frames. The leaf nodes do not forward any frame. In SM, the IGMP snooping technique is used to improve multicast frame forwarding. Some switches implement this technique. However, the Linux bridge does not. Thus, IGMP snooping was implemented as part of the WiFIX+ daemon, in order to avoid changes to the Linux bridge software. When a multicast frame arrives on the physical interface, WiFIX+ verifies the Ethertype value and if it is equal to 0x800 (IPv4 packet), it inspects the message inside the packet. If this message is an IGMP Report (Join), WiFIX+ adds a new entry to the Group Table with the group IP address, the tap associated to the neighbor the frame was received from, and a lifetime equal to the default IGMP Query period (125 s),
for each Group Record included in the IGMP Report (Join). If the IP address already exists in the Group Table, WiFIX+ just adds the tap associated to the neighbor the message was received from and resets the lifetime. If there is no matching, the message is ignored. After the creation of the group tables, the WiFIX+ daemon is able to selectively forward multicast frames. Thus, when a multicast frame arrives to the bridge, it will behave the same way. Nevertheless, this time the WiFIX+ daemon filters out the frames received from the taps according to the Group Table. In SMob, the WiFIX+ daemon uses the DHCP technique to know when a new terminal arrives to a MAP. Upon receiving a broadcast frame on a tap, WiFIX+ verifies the Ethertype field. If it is equal to 0x800, the packet is inspected. If it transports an UDP packet and a DHCP REQUEST message, WiFIX+ adds an entry to the Mobility Table with the transaction ID of the DHCP message, the original source MAC address of the frame, and a lifetime. This entry is kept in the table until a DHCP ACK message arrives on the physical interface. When that happens, WiFIX+ creates the fake IGMP Query message and sends it to the new terminal in unicast, using the MAC address stored in the Mobility Table. In response, the terminal sends an IGMP Report (Join) that allows the MAPs to update their group tables. VII. E VALUATION In this section, we describe the experimental setup, analyze the results and discuss the performance of WiFIX+. A. Experimental Setup The performance of WiFIX+ was evaluated by means of real experiments. Firstly, we compared MaB with IEEE 802.11s, then MaB with SM and, finally, MaB with SMob. The metrics used in the evaluation were: throughput, delay, jitter, packet loss ratio, and the multicast flow reacquisition interval. To analyze the performance of IEEE 802.11s, we used the opensource implementation open802.11s4 . A test-bed with four machines (MAPs) with Linux OS was built. These machines were all in radio range. To create the topology shown in Fig. 2, we used a technique for filtering TR messages, implemented within the WiFIX+ daemon. Otherwise, due to ATCM, we would get a tree with a parent (master MAP) and three children. We forced this tree topology to ensure that the same active topology was used in all experiments. 802.11 NICs of the four machines were set in ad hoc mode and configured in channel 3, in order to avoid the most used 802.11 channels (1, 6, and 11). We established a maximum bit rate of 11 Mbit/s, due to the limitations of the ath5 driver required by the open80211s implementation5 . Performance tests were carried out with Iperf6 and Ping. For all tests, the duration of the flows was set to 120 seconds and ten samples were obtained for each setup. In the master MAP we set a multicast traffic generator, because we intended 4 http://open80211s.org 5 http://wireless.kernel.org/en/users/Drivers/at5k 6 http://www.noc.ucf.edu/Tools/Iperf
(a) WiFIX+
(b) IEEE 802.11s
Figure 3: Throughput: two hops to the master node.
to simulate the arrival of traffic to the WMN, coming from the network infrastructure, through this node. B. Experimental Results In order to compare the performance of WiFIX+ and IEEE 802.11s, we ran the WiFIX+ daemon in all MAPs and forced the tree topology represented in Fig. 2. In all nodes, except the master MAP, we measured throughput, delay, jitter, and the packet loss ratio. Due to space limitations, here we focus on throughput and delay; the whole set of results on jitter and packet loss can be found in [13]. In the scenario of Fig. 2, the network saturation point measured in MAP3 is about 2.2 Mbit/s, for WiFIX+ MaB, while for 802.11s the network saturates at 250 kbit/s; this is a difference of one order of magnitude. This happens because WiFIX+ MaB uses unicast tunnels to send multicast frames and the maximum bit rate defined in the standard can be used (11 Mbit/s). In practice, the maximum bit rate measured for a unicast UDP flow in an ad hoc network with two nodes is about 6 Mbit/s. Considering Fig. 2, for WiFIX+, MAP1 sends two unicast frames and MAP2 retransmits one frame, also in unicast. This is equivalent to a scenario where three nodes compete for the same medium. So, the expected values were obtained, ≈ 6M bit/s . For 802.11s, the bit rate to send multicast 3 frames is the minimum defined in the standard (1 Mbit/s). In practice, this value is about 800 kbit/s. In IEEE 802.11s, all nodes retransmit a multicast frame once, so there are four nodes competing for the same wireless medium. WiFIX+ MaB always transmits one frame less. This is an advantage of WiFIX+ compared to 802.11s, together with the use of unicast frames to convey multicast traffic. The plots of Fig. 3 present the throughput measured in MAP4 (two hops to the master MAP) for WiFIX+ MaB and IEEE 802.11s. The plot of WiFIX+ MaB shows the higher throughput compared to IEEE 802.11s. For IEEE 802.11s, the throughput is about 180 kbit/s which is about 30% lower than the value measured in MAP3. This is explained by the high packet loss ratio verified in MAP4 for this solution. Taking into account Fig. 2, this behavior is explained by synchronization in frame forwarding by MAPs 2 and 3, causing frequent collisions. IEEE 802.11s does not provide an acknowledgement
mechanism for multicast/broadcast frames. So, if there is a collision, the frame is lost and there is no retransmission. Concerning packet delay, the plots of Fig. 4 show the differences between WiFIX+ MaB and IEEE 802.11s, for MAP4. We can see that WiFIX+ MaB performs better than IEEE 802.11s too. The maximum delay for WiFIX+ is about 300 ms and for IEEE 802.11s is about 1 s. The possibility to send traffic at a higher bit rate for WiFIX+ MaB allows the reduction of the delay. Thus, for a given value of offered load, WiFIX+ MaB always introduces a lower packet delay. Multicast applications with real-time requirements, such as video conferencing and radio broadcast over IP, are influenced by packet delay variation. So, the evaluation of network performance concerning jitter7 is important. For WiFIX+ MaB, with the increase of the offered load, the probability of frame collision also increases, increasing the number of retransmissions. Thus, the packet delay difference between two consecutive packets tends to increase. Besides that, the medium access protocol of 802.11 networks introduces delay variations. Before initiating a transmission, a node listens to the medium, and if it is free for a given period of time (DIFS, Distributed Inter Frame Space), sends the frame; otherwise, the node will have to wait a random time determined by a random backoff algorithm. In the network saturation zone, the network congestion and the increase of the number of lost frames are responsible for the quick increase of jitter (see Reference [13]). For IEEE 802.11s, the behavior is similar to WiFIX+ MaB. In 802.11s, for each frame sent by the master MAP, three frames are retransmitted. So, there are four frames to transmit the same information, which increases the competition for the medium. For WiFIX+ MaB, the maximum jitter measured in MAP4 is about 15 ms, while for IEEE 802.11s it is about 90 ms. Overall, the jitter in WiFIX+ is much lower than in IEEE 802.11s, even for different offered load ranges. The evaluation of the packet loss ratio is important because applications that need multicast traffic forwarding use UDP. This protocol does not support any mechanism to ensure packet delivery, so the number of lost packets is an important 7 In
this context this term means packet delay variation.
(a) WiFIX+
(b) IEEE 802.11s
Figure 4: Delay: two hops to the master node.
(a) Selective Multicast
(b) Multicast as Broadcast
Figure 5: Influence of multicast UDP flow in a unicast TCP flow.
aspect to consider. The most critical situation is verified for MAP4, with the 802.11s solution. Packet loss ratio has an oscillatory behavior even for low values of offered load. The cause of this behavior is the synchronism of MAP2 and MAP3 when sending broadcast frames. So, there are many frames that collide and MAP4 presents packet loss ratio values about 40%, even for low values of offered load. In general, the values of the packet loss ratio for WiFIX+ MaB are smaller than for IEEE 802.11s, even for higher values of offered load. Regarding the impact of the number of hops to the master MAP in this metric, MAP4 presents a maximum packet loss ratio that is higher than the value obtained in MAP2. Once MAP2 forwards the frames to MAP4, the value of the packet loss ratio for MAP4, placed two hops away from the master MAP, is affected by the lost frames in the transmission between MAP1 and MAP2 and the transmission between MAP2 and MAP4. So, the higher packet loss ratio measured in MAP4 makes sense. The plots of Fig. 5 allow comparing SM and MaB, concerning the influence of a multicast UDP flow in a unicast TCP flow. The multicast flow bit rate is 1 Mbit/s. When we use MaB, MAP1 sends two frames per multicast frame received, each one at 1 Mbit/s. MAP2 also sends one more frame per multicast frame at the same bit rate. Thus, the unicast TCP flow uses the remaining bandwidth. Therefore, the less multicast frames sent the more bandwidth the unicast
TCP flow can use. The influence of the multicast UDP flow is lower, when SM is used. The multicast frames that arrive to MAP2 and MAP3 will be in fact dropped, because these nodes did not request traffic for this group; thus, there is an unnecessary occupation of the network. Using MaB, when the multicast UDP flow is injected, the unicast TCP flow throughput decreases about 1.3 Mbit/s and the average delay is about 540 ms. On the other hand, using SM, the unicast TCP flow throughput decreases about 400 kbit/s and the average delay is about 240 ms. These results show the advantages of using selective multicast forwarding. In order to evaluate SMob, a comparison with MaB was made, concerning the multicast flow reacquisition time. The goal was to analyze the impact of the group tables update time on the total multicast flow reacquisition time. Furthermore, MaB represents the optimal mobility management solution, as a given multicast flow is available in every MAP. Thereby, when a terminal moves, the multicast flow reacquisition time is minimal. In the experimental scenario, the terminal moves from MAP4 to MAP3. In MAP1, we ran the Ping application in order to send 64 bytes multicast packets at 10 ms intervals. In the terminal, we ran an application that invokes the IGMP protocol, allowing the association to a given group. With Wireshark8 , we measured the time when the last packet arrived from MAP4 and the first packet arrived from MAP3. The 8 http://www.wireshark.org
dhclient application of Linux introduces a random time before sending a DHCP Request message, which influences the total multicast flow reacquisition time. This time was subtracted in the calculations, in order to evaluate the sole impact of SMob. The average multicast flow reacquisition times over 10 experiments for each solution was about 210 ms for MaB and 380 ms for SMob. SMob introduces a higher multicast flow reacquisition time than MaB, as expected. This difference is caused by two factors: the DHCP REQUEST and DHCP ACK messages delay and the response time of the terminal to the fake IGMP Query sent by MAP3. However, the observed values for the two mechanisms are the same order of magnitude. Overall, SMob is more advantageous, because it is more efficient in multicast traffic forwarding and does not compromise significantly the multicast flow reacquisition time, compared with MaB. Also, it is important to realize that the average value obtained for SMob is the worst case scenario, when the multicast flow is not being transmitted through the new MAP yet; if that happens, the reacquisition time will be the same as in MaB. C. Discussion In Section VI, we mentioned that the lifetime of Group Table entries was set to 125 s. This value corresponds to the default interval defined in [12] between two IGMP Query messages sent by multicast routers. However, this value is too high and compromises the efficiency of the WiFIX+ SMob solution. To solve this problem, the query interval of multicast routers and the lifetime of the group tables can be reduced. Another solution is to add the terminals’ MAC addresses to the group tables, associating them to the taps the terminal could be reached from. Thus, upon the arrival of an IGMP Report message, the MAP would verify whether the original source MAC address had already been associated to another tap. If this is true, it means that the terminal has moved from a MAP to a new one. If the MAC address was the only one associated to that tap, the tap could be removed from the corresponding Group Table entry and the traffic would not be forwarded to the corresponding branch anymore. In Section VII, we used different scales in the plots, because WiFIX+ has a much higher limit for throughput than IEEE 802.11s. In the first phase, we proved the advantage of using unicast encapsulation in multicast frames. In the second phase, the goal was to show that we could save bandwidth using SM. We injected a new TCP unicast flow and evaluated the influence of an UDP multicast flow using two multicast frame forwarding mechanisms, MaB and SM. Concerning the mobility issue, the major goal in Section VII was to confirm that SMob allows multicast flow reacquisition; however, we also proved that the multicast flow reacquisition time does not increase significantly. Finally, an advantage of WiFIX+ is the fact that it was developed considering an evolutionary approach. So, a specific mechanism can be selected according to the networking context and the specific deployment requirements.
VIII. C ONCLUSIONS Current solutions for WMNs are either too complex or deal with multicast inefficiently by means of pure flooding. Herein, we proposed a new and simple solution, called WiFIX+, to cope with multicast traffic within WMNs and support mobility of legacy terminals. Experimental results showed that WiFIX+ enables up to one order of magnitude higher throughput and up to one order of magnitude lower delay, when compared to IEEE 802.11s. In addition, by using well-known techniques from wired networks, such as IGMP snooping, we showed that the WiFIX+ performance can be further improved. On the other hand, the use of DHCP snooping as a basis for terminal mobility management proved to be a feasible solution. As future work, we shall evaluate the WiFIX+ scalability and the performance improvements obtained for other IEEE 802.11 variants (IEEE 802.11a/g/n). Additionally, we may consider the design of a new mobility management mechanism involving the mobile terminals too, so that the multicast flow reacquisition time is further reduced in the WiFIX+ SMob approach. ACKNOWLEDGMENT The work described in this paper was partially funded by FCT (Fundação para a Ciência e a Tecnologia) under the project PTDC/EEA-TEL/74471/2006 – Multicast and Mobility Management in Heterogeneous Access Networks. R EFERENCES [1] IEEE P802.11s/D2.0, draft amendment to standard IEEE 802.11: Mesh Networking, March 2008, work in progress. [2] Rui Campos, Ricardo Duarte, Filipe Sousa, Manuel Ricardo and José Ruela, Network Infrastructure Extension Using 802.1D-based Wireless Mesh Networks, Wireless Communications And Mobile Computing, January 2010 (on-line version). [3] Sung-Ju Lee, William Su and Mario Gerla, On-Demand Multicast Routing Protocol in Multihop Wireless Mobile Networks, Mobile Networks and Applications 7, 2002. [4] J. J. Garcia-Luna-Aceves and Ewerton L. Madruga, A Multicast Routing Protocol for Ad-Hoc Networks, Proc. of IEEE INFOCOM, New York, USA, March 1999. [5] Sung-Ju Lee, William Su and Mario Gerla, Ad Hoc Wireless Multicast with Mobility Prediction, Proc. of IEEE ICCCN’99, Boston, USA, October 1999. [6] W. A. Shittu, Aisha-Hassan, A. Hashim, F. Anwar and W. Al-Khateeb, A Proposed QoS Multicast Routing Framework for Next-Generation Wireless Mesh Network, IJCSNS, vol 8 No. 9, September, 2008. [7] William Su, Sung-Ju Lee and Mario Gerla, Mobility Prediction in Wireless Networks, Proc. of IEEE MILCOM, 2000. [8] Hasnaa Moustafa and Houda Labiod, A Multicast On-demand Mesh-based Routing Protocol in Multihop Mobile Wireless Networks, Proc. of IEEE 58th Vehicular Technology Conference, VTC, 2003. [9] Pedro M. Ruiz, Franciso J. Galera, Christophe Jelger and Thomas Noel, Efficient Multicast Routing in Wireless Mesh Networks Connected to Internet, Proc. of IEEE SECON’05, Santa Clara, USA, September 2005. [10] IEEE 802.1D, IEEE Standard for local and metropolitan area networks., IEEE, June 2004. [11] M. Christensen, K. Kimball and F. Solensky, Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches., IETF RFC 4541, May 2006. [12] B. Cain, S. Deering, I. Kouvelas, B. Fenner and A. Thyagarajan, Internet Group Management Protocol, Version 3, IETF RFC 3376, October 2002. [13] C. Oliveira, “Difusão Eficiente de Tráfego Multicast em Redes Emalhadas 802.11 com Suporte de Mobilidade”, University of Porto, 2010, http://paginas.fe.up.pt/∼ee05040/docs/Dissertacao_Carlos_Oliveira_vfinal.pdf (in Portuguese).
