An XL-Based Data Link Layer Routing Protocol for Wireless Mesh Networks

Ngoc Minh Le Department of Systems and Networking

Faculty of Computer Science and Engineering Ho Chi Minh City University of Technology

minhle@cse.hcmut.edu.vn

Tran Minh Hung Department of Systems and Networking

Faculty of Computer Science and Engineering Ho Chi Minh City University of Technology

minhhung1902@yahoo.com

Abstract — We present a simple link-state routing protocol called DLL-XL that provides packet routing at the link layer for ad-hoc 802.11s-based networks. DLL-XL can be considered as a deployment of the Approximate Link state algorithm XL proposed by Levchenko et al. By building upon the XL algorithm, the DLL-XL routing protocol achieves routing efficiency by suppressing flooding of link-cost changes when appropriate to tradeoff between message flooding overhead and path costs. The correctness of DLL-XL is inherited from the formal correctness of the XL algorithm. We evaluate the performance of DLL-XL by simulation using the ns-2 network simulator.

Keywords — IEEE 802.11s; Approximate Link State; Flooding

I. INTRODUCTION In this paper, we refer to a wireless mesh network (WMN)

as an IEEE 802.11-based network of wireless nodes and its generalizations. WMNs can be considered as a variant of mobile ad-hoc networks (MANET), and thus, are also characterized by the lack of a prebuilt communication infrastructure [4]. In WMNs, packets are sent from a node to another over multihop paths using a cooperative packet-forwarding mechanism at each node. Therefore, WMNs can be deployed in unpredictable or spontaneous situations where an infrastructure cannot be built in advance or in situations where an infrastructure is expensive.

In MANETs, packet routing is usually implemented in the network layer, which however can lead to certain disadvantages. Consider e.g. the AODV protocol; as pointed out in [14] such disadvantages may be: overhead, dependence on the ARP protocol, operating system kernel modification, or need of a separate kernel module.

Above-mentioned disadvantages can be avoided if packet routing is implemented in the data link layer, e.g. as specified in Draft IEEE 802.11s. We note that, in 802.11s, routing in the data link layer is called ‘path selection’. Current 802.11s-related projects such as those in [9] [13] demonstrate the feasibility of the path selection concept.

Draft IEEE 802.11s has specified that the default routing protocol of 802.11s is the Hybrid Wireless Mesh Protocol (HWMP) to guarantee interoperability between 802.11s devices implemented by possibly different producers. An optional routing protocol is the Radio Aware Optimized Link

State Routing Protocol (RA-OLSR). Draft IEEE 802.11s allows additional optional routing protocols.

This paper presents the design of a routing protocol for WMNs, called DLL-XL, and its simulation-based performance evaluation. The protocol is termed ‘DLL’ (data link layer) because it is a path selection protocol in the IEEE 802.11s framework, and ‘XL’ because it is based on the Approximate Link State, or XL, routing algorithm [7].

We organize the rest of the paper as follows. Section II describes the technique of selective link cost flooding — the core of the routing algorithm XL. Details of the routing protocol DLL-XL are given in Section III. Section IV presents simulation results on the performance of DLL-XL. We conclude in Section V.

II. PACKET FLOODING AND THE XL ALGORITHM

A. Packet Flooding Techniques In this paper, we refer to broadcasting as the transmission

of a packet by a node to all of its direct neighbors and to flooding as an algorithm to propagate a packet to a desired set of nodes, which might consist of all network nodes in the extreme case.

An example of flooding is naïve flooding, in which each node rebroadcasts every packet that it receives. Naïve flooding generates a large number of messages. Therefore, the efficiency of a routing protocol depends largely on how well the message flooding overhead is reduced. Several techniques for reducing the message flooding overhead have been developed. Some of these techniques are:

� Assign each packet a sequence number to help avoid flooding messages containing old or already processed information. This technique is used in almost every routing protocol, e.g. OLSR [1] and AODV.

� Artificially divide the network into separate smaller flooding areas. Within each of them flooding may be applied, and routing between them is the task of special nodes connecting the areas. This method is applied in the routing protocol OSPF [8].

� Limit the flooding radius by using a ‘Time to Live’ attribute in the packet. The value of ‘Time to Live’ specifies how far, i.e. the maximal number of hops,

3rd IEEE Intelligent Vehicular Communications System Workshop (IVCS'11)

978-1-4244-8790-5/11/$26.00 ©2011 IEEE 80

the packet can travel in the network. Examples of protocols that use this technique are Fisheye and OLSR.

� Only a selected subset of the nodes is allowed to rebroadcast messages; other nodes may receive but won’t rebroadcast messages. This technique is used in the routing protocol OLSR.

Recently, a new technique for reducing network flooding overhead, which is called selective link cost flooding, has been designed by Levchenko et al. and used in the so-called XL algorithm (XL stands for approximate link state) [7]. The selective link cost flooding enables the trade-off between the message flooding overhead and the cost of a path from a source to a destination node by propagating only selected messages while suppressing other messages. The message selection is controlled by rules and a nonnegative scalar parameter, say �, at each node. The rules are procedures that check when a link cost change should be propagated. By applying these rules it is guaranteed that the cost to any destination does not exceed (1 + �) times the optimal path cost. Specifically, if � = 0, then XL is a usual link-state routing algorithm. The mentioned rules will be described in Section B. Despite using selective link cost flooding, the XL algorithm is correct, which was formally proved in [7].

B. The XL Routing Algorithm The routing algorithm of Levchenko et al. differs from

other algorithms in that it implements packet flooding by propagating packets selectively. Essentially, XL flooding is controlled by rules on what link costs a node should share with its neighbors to trade off between message overhead and optimal path cost. The three rules can be formulated as follows [7] (We denote them by the same labels as in [7]):

� Rule S1. If the link cost change is an increase then propagate it to the neighbor under consideration.

� Rule S2. If the link whose cost has changed is an edge of a shortest path tree rooted at the node then propagate the update only to the next (i.e. 1-hop) node on the path to the link.

� Rule C1. If the link cost change implies that the cost of a shortest path to some destination in the external view will become more than 1 + � times the cost of a shortest path to that destination in the internal view, then propagate it to the node under consideration; � � 0 is a parameter of the algorithm.

The XL algorithm was formally proved to be sound and complete [7]. Moreover, it has stretch 1 + �, i.e., after the network becomes stationary, the cost to any reachable destination does not exceed (1 + �) times the cost of the optimal path. We note that � need not be the same at each node.

III. THE DLL-XL PROTOCOL

A. Design The DLL-XL protocol builds upon the XL algorithm,

especially upon the technique of selective link cost flooding

used in XL. One could also consider DLL-XL as a deployment of XL for 802.11s-based networks.

In DLL-XL, checking the rules S1, S2 and C1 described in II.B is supported by a database at each node that includes an ‘external view’ for each of the neighbors and a single ‘internal view’ for the node itself. The notions internal view and external view are basic concepts in the XL algorithm [7]. The external view for a neighbor contains link cost information that the node shares with that neighbor. The sharing of external views is implemented by sending and receiving messages between nodes. For simplicity, we have assumed the same � at each node.

B. Database at each Node Each node, say u, maintains a database consisting of the

following data structures:

� Neighbor table. This table stores the MAC address of each neighbor of the node.

� Neighbor connectivity table. An entry of this table contains information about a link that is incident on node u, i.e., directed edge beginning from or ending at u. The main attributes of a link are link cost and link cost sequence number. Another link attribute is link duration.

� External view. For each neighbor v, the node u maintains an external view, which is a table containing selective network data that u shares with v. External-view entries store link costs and their sequence numbers that the node u has communicated to v, thus shares them with v.

� Internal view. Each node’s internal view is a table in which the node stores the most recent link costs that it has gained itself or received from its neighbors together with corresponding sequence numbers. A part of the internal view is derived from the neighbor connectivity table. The internal view will be used to compute the forwarding table.

� Forwarding table. The node will use this table to forward a packet to the next hop on a path to the destination. This data structure is derived from a shortest-path tree that is computed from the internal view using e.g. the Dijkstra algorithm.

C. Message Format In the protocol DLL-XL, control packets are used to

transmit HELLO and TC messages. In Draft 802.11s [6], similar messages are already described. Therefore we can reuse their frame formats in DLL-XL, with modifications if necessary. The general Mesh MAC frame format can be found in [6].

D. HELLO Messages For simplicity, the XL algorithm assumes that nodes and

links of the network are fixed and known in advance. In practice, it is necessary for each node to continuously monitor its communications channels to discover new nodes or to maintain current neighbor connectivity. Standard procedures

81

for neighbor discovery are specified in Draft IEEE 802.11s [6]. Here we use hello messages.

Each node periodically broadcasts specific control messages, so-called HELLO messages, to advertise its presence in the network or to inform its known neighbors on link costs. The reception of a HELLO message at a node indicates the availability of a network link from a neighbor or, indirectly, the availability of a link to the neighbor transmitting that HELLO message. If HELLO messages are not received from a neighbor within a fixed time lapse that equals e.g. the double of the HELLO-message broadcast period, then the node can assume a loss of connectivity between it and the neighbor. Upon receiving a HELLO message the node, say u, updates the neighbor table and the neighbor connectivity table.

� If the neighbor table does not have yet an entry for the node, say v, that has broadcast the HELLO message, then the receiving node u adds v to the neighbor table and a unidirectional link v � u to the neighbor connectivity table. Prepare a feedback notification for the neighbor in the HELLO message.

� If the HELLO message contains in the field ‘Neighbor Address’ an address that equals u, then u creates a bidirectional link between u and v in the neighbor connectivity table.

� Update the internal view using the neighbor connectivity table.

E. TC Messages Nodes send TC messages to propagate selective link costs

to other ones. TC messages are transmitted in a broadcast manner. Basically, TC message contain following fields: ‘Begin Address’ is the MAC address of the link begin node, ‘End Address’ is the MAC address of the link end node, ‘Neighbor Address’ is the MAC address of the neighbor, ‘Metric’ is the link cost, and ‘Seq’ is the sequence number associated to the link.

To implement the packet flooding technique of [7], when a node receives a TC message, it will proceed through the following steps:

� Update the corresponding link costs in the local external view for the TC-message originator. Update the internal view if the link costs are more recent than the ones in the internal view.

� Recompute the shortest-path tree from the internal view.

� Update other external views: For each neighbor found in the neighbor table, the node proceeds as follows. It examines the links stored in the internal view and checks if the link cost satisfies any of the rules; if this is the case, an update for the link cost will be added to the TC message buffer that will be broadcast later upon the node has finished iterating over the set of its neighbors. The whole step is described with more details in the algorithm COMPUTE-NEW-EXTERNAL-

VIEWS given below. (We use pseudocode conventions described in [15].)

COMPUTE-NEW-EXTERNAL-VIEWS for each node v in neighbor table

do for each link (x,y) in internal view do if external_view_link_cost(v,x,y) <

internal_view_link_cost(x,y) then add link (x,y) to TC message for v

if link (x,y) in internal-view shortest path to node y and next_node(y) = v

then add link (x,y) to TC message for v do for each link (x,y) in internal view do if link (x,y) in an internal-view shortest path from u to w and external_view_link_cost(v,u,w) > (1+� ) × internal_view_link_cost(u,w)

then add (x,y) to TC message for v broadcast TC message

Although several optimizations to the algorithm COMPUTE-NEW-EXTERNAL-VIEWS are possible, we choose to not describe them here to simplify the exposition.

IV. SIMULATION AND EVALUATION To evaluate the performance of the DLL-XL protocol, we

simulated it using the popular ns-2 network simulator [3]. Ns-2 offers modules for simulating wireless physical layers and various radio models, including an implementation for the IEEE 802.11 specification.

We simulated the DLL-XL protocol using the grid topology and the random network topology as generated by ns-2. The link costs for the networks in the simulation are the hop count and the airtime metric. The procedure for calculating the airtime metric for a link is described in [6]. For performance comparison, existing ns-2 modules for simulating the routing protocols OLSR and DSDV were used.

Because of computing resource limitations and the complexity of the physical model in ns-2, we were able to simulate only small networks.

Figure 1: Number of messages for initializing the network

The first simulation configuration is as follows: the network topology is a grid; the simulated protocols are OLSR, DSDV, and DLL-XL; the link costs are hop counts. Figure 1 shows the number of messages that have been sent to establish

82

routing tables at network nodes as a function of the network size. Figure 1 indicates that DLL-XL behaves better than OLSR and DSDV in terms of the number of messages.

Figure 2: Number of messages for varying node density

The second simulation configuration is the following: the network topology is a random network; the simulated protocols are DSDV and DLL-XL; the link costs are the airtime metric. In simulating DLL-XL, the parameter values � = 0.0 and � = 0.5 have been used. Figure 2 depicts the number of messages as a function of the node density. The graphs show that DLL-XL with both � = 0.0 and � = 0.5 needs fewer messages than DSDV does.

Figure 3: Number of messages for varying number of link cost changes

The third simulation configuration is as follows: the network topology is a random network; the simulated protocols are DSDV and DLL-XL; the link costs are the airtime metric. In simulating DLL-XL, we have used the parameter values � = 0.0 and � = 0.5. Figure 3 shows the number of messages as a function of the number of link cost changes for the random network. We observe that DLL-XL for both � = 0.0 and � = 0.5 takes fewer messages than DSDV does.

Our simulation configurations may seem oversimplified in several aspects, e.g. only few network parameters are taken into account. Therefore, more simulation scenarios should be designed and conducted so that we can gain a more differentiated comparison between the protocols. We also need to consider to compare DLL-XL with HWMP, the default protocol in 802.11s networks. Note however the different natures of DLL-XL and HWMP: the former is proactive,

whereas the latter is a hybrid protocol that combines both proactive and on-demand routing techniques.

V. CONCLUSIONS The design of the routing protocol DLL-XL is based on the

selective link cost flooding technique developed by Levchenko et al. [7] and follows closely the IEEE 802.11s Draft [6]. Performance evaluation for DLL-XL was performed using the ns-2 network simulator. We observed that DLL-XL performs well for WMNs with high node density or high link cost variation. However, simulations for networks with a bigger number of nodes need to be conducted to evaluate DLL-XL in large networks.

Although our simulation configurations may seem rough, we believe that our simulations provide results that might accurately describe the behavior of an implemented real network. Currently we are implementing the DLL-XL protocol on a Linux platform to validate — in a practical sense — our design in a real-world setting. This continues our previous work on implementation of a (AODV-like) routing protocol at data link layer for 802.11 networks [18]. Also more simulations with the right parameters need to be designed so that we can gain a more differentiated evaluation of the protocol DLL-XL.

REFERENCES [1] T. Clausen and P. Jacquet (Eds.), “RFC 3626: Optimized Link State

Routing Protocol (OLSR),” October 2003.

[2] G. Pei, M. Gerla, and T. Chen, “Fisheye State Routing: A Routing Scheme for Ad Hoc Wireless Networks,” in Proceedings of ICC 2000, pp. 70–74, 2000.

[3] Kevin Fall and Kannan Varadhan (Eds.), The ns Manual (formerly ns Notes and Documentation), The VINT Project. http://www.isi.edu/nsnam/ns/doc/

[4] Ekram Hossain and Kin K. Leung (Eds.), Wireless Mesh Networks: Architectures and Protocols, Springer, 2007.

[5] J. Jaffe and F. Moss, “A responsive distributed routing algorithm for computer networks,” IEEE Transactions on Communications, COM-30(7):1758–1762, July 1982.

[6] Joint SEE-Mesh/Wi-Mesh Proposal to 802.11 TGs, 27 Feb 2006.

[7] K. Levchenko et al., “XL: An Efficient Network Routing Algorithm,” SIGCOMM’08, August 17–22, 2008, Seattle, Washington, USA.

[8] J. Moy, “RFC 2328: OSPF Version 2,” April 1998.

[9] One Laptop Per Child (OLPC) Project, http://laptop.org.

[10] C. Perkins, E. Belding-Royer and S. Das, “RFC 3561: Ad hoc On-Demand Distance Vector (AODV) Routing,” July 2003.

[11] The Open Mesh Project, http://www.open-mesh.net

[12] http://grouper.ieee.org/groups/802/11/Reports/tgs_update.htm

[13] http://www.open80211s.org/

[14] Ian Chakeres and Elizabeth Belding-Royer, “AODV Implementation Design and Performance Evaluation,” International Journal of Wireless and Mobile Computing, Issue 2/3, 2005.

[15] Josh Broch, David A. Maltz, David B. Johnson, Yih-Chun Hu, Jorjeta Jetcheva, “A Performance Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols,” in Proceedings of the Fourth Annual ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom’98), October 25–30, 1998, Dallas, Texas, USA.

[16] Cormen et al., Introduction to Algorithms, MIT Press.

83

[17] Thomas Zahn, Greg O'Shea and Antony Rowstron, “An Empirical Study of Flooding in Mesh Networks,” Technical Report MSR-TR-2009-37 http://www.research.microsoft.com

[18] Ngoc Minh Le et al., “Implementation of a Routing Protocol at Layer 2 for Wireless Mesh Networks,” in Proceedings of The Fifth International Conference on Information Technology in Education and Training (IT@EDU2008), Dec 2008, HCMC, 49–54.

84