wARP-Path: Implications of adapting the Ethernet-based ARP-Path bridging protocol to a wireless environment

03/07/2018 ∙ by Elisa Rojas, et al. ∙ Universidad de Alcalá AUT 0

The ARP-Path protocol has flourished as a promise for wired networks, creating shortest paths with the simplicity of pure bridging and competing directly with TRILL and SPB. After analyzing different alternatives of ARP-Path and creating the All-Path family, the idea of migrating the protocol to wireless networks appeared to be a good alternative to protocols such as a AODV. In this article, we check the implications of adapting ARP-Path to a wireless environment, and we prove that good ideas for wired networks might not be directly applicable to wireless networks, as not only the media differs, but also the characterization of these networks varies.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 4

page 5

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The All-Path family [1] comprises diverse routing protocols running on layer 2, leveraging the well-known advantages of Ethernet in wired networks. All-Path protocols are based on the simple and basic mechanism of backward address learning used by bridges/switches, extended with a lock mechanism to prevent loops. Paths are discovered and built based on minimum latency and may be created per destination host (ARP-Path), per communication flow or host pair (Flow-Path), per destination bridge (Bridge-Path) or even combining parameters from different layers, such as TCP (TCP-Path [2]).

The first protocol, and origin of the whole All-Path family, was ARP-Path [3], already implemented in multiple and diverse platforms like Linux, NetFPGA, OpenFlow, or OMNeT++ [4]. Its main competitors are protocols using layer 2 variants of the IS-IS protocol such as SPB [5] or TRILL RBridges [6, 7]. The approach for ARP-Path is to discover low latency paths via network exploration with broadcast frames, while in SPB and TRILL paths are computed based on the network topology obtained after an initial exchange of data at link level.

In its origins, the All-Path family was inspired by the Ad hoc On-Demand Distance Vector (AODV) routing 

[8, 9], designed for wireless networks. Both create paths following a reactive routing approach. Therefore, one of the challenges was to adapt this family of bridging protocols from a wired environment to a wireless one, in order to analyze and compare them to AODV.

This paper is organized as follows. Chapter I introduces the topic, followed by the related work in Chapter II. Afterwards, Chapter III explains the implication of moving ARP-Path to a wireless environment and defines wARP-Path. Chapter IV describes the implementation in the OMNeT++ simulator, later on evaluated in Chapter V. Finally, Chapter VI discusses the topic and Chapter VII concludes the article.

Ii Related Work

There is a vast literature related to routing protocols applied to wireless networks. More specifically, one of the most prominent research fields that has thoroughly studied this problem is the one linked to ad hoc networks, and more specially wireless mesh networks (WMNs). A seminal paper related to routing strategies in wireless networks is [10]

, where authors propose and evaluate two competitive proposals for routing, called fisheye state routing and hierarchical state routing. However, probably the most well-known routing protocols for routing in wireless networks are Ad hoc On-Demand Distance Vector (AODV) and Dynamic Source routing (DSR), as they are both standardized by IETF.


AODV is described in RFC 3561 [8] and is based in using destination sequence numbers to avoid loops even in such situations where there are anomalous delivery of routing control messages. To our purpose, it is also very interesting the work in [9], as it describes some of the most interesting evolutions of AODV that have improved issues like performance, robustness or scalability and sheds light on future evolutions for the protocols. In fact, AODV features are the grounds of the All-Path family protocols.
The second standardized protocol is DSR protocol and is defined in RFC 4728 [11]. DSR is a distributed protocol able to work in multi-hop wireless networks and it discovers and maintains routes by means of two mechanisms: route discovery and route maintenance. More specifically, route discovery in DSR is based on source routing and route caches, maintaining multiple routes per destination. A performance comparison between AODV and DSR can be found in [12].

Other routing protocols that focus on improving different issues have been proposed in the literature –since the proposal of AODV and DSR– are Source Node Compute Routing (SNCR) [13] or Protection AODV (P-AODV) [14]. In the first case, SNCR aims to improve overhead and efficiency proposing a quick computation of the best metric for arriving from the source node to any destination, combining proactive and on-demand modes to adapt to different traffic settings. On the other hand, P-AODV focuses on improving reliability in wireless networks by means of building a protection path. Another important issue in routing in wireless routing is related to the link quality evaluation. In this sense, it must be highlighted the work in [15], where authors propose a link quality prediction (LQP) model to sense the link state.

Finally, the comparison of bridging and routing techniques in wireless networks is also a topic aligned with our proposal. In [16], authors compare wireless bridging and routing, concluding that bridging performs better than routing in terms of throughput both in TCP and UDP. Moreover, authors in [17] study the consequences of using pure bridging based solutions in wireless networks and present an enhanced bridged-based implementation for providing dynamic, self-configuration and self-healing features avoiding a routing protocol.

Iii From ARP-Path to wARP-Path

In this section, we evaluate the key aspects for the transition from ARP-Path (wired and strictly Ethernet-based) to wARP-Path (wireless and potentially implemented using different layer-two protocols). For this purpose, we start by summarizing ARP-Path, then explaining the basics of wARP-Path (with emphasis on the differences), and finally analyze the implications of the frame format.

Iii-a ARP-Path

The ARP-Path protocol creates minimum latency paths at request, based on path exploration instead of computation [3, 1]. ARP-Path does not require any modification of the Ethernet frame, and it only needs a small new feature in standard switches: a lock. The lock is a mechanism that prevents the switch from learning more than once (in a certain period of time) the same MAC address, which in the end prevents network routing loops [1] and allows any broadcast frame to explore the whole network as a probe, creating a source-based routing tree in its way.

Fig. 1 summarizes the operation of ARP-Path in an example Ethernet network that connects two hosts and . Before any communication in IPv4, sends and ARP Request, which is leveraged to explore the topology and create the shortest paths. The difference with a standard switch is shown in switch 6, which only saves the first MAC address arriving –the one from switch 3– and locks the association of this MAC to the input port. Therefore, when the ARP Request arrives at a different port –from switch 5–, the frame is discarded, thus avoiding the potential loop, which would not happen in a standard Ethernet switch. Accordingly, only the fastest copy of the ARP Request arrives at .

The learning process continues from to with the ARP Reply. This time, the unicast ARP Reply is forwarded towards , already known by the different hops –switches– in the network. Hence it crosses switches 6, 3, 2 and 1, respectively, until arriving at . In the meantime, these switches save the input port for the ARP Reply, eventually generating the path towards .

(a) Learning process for path to when the ARP Request is broadcast
(b) Learning process for path to when the ARP Reply is sent from to
Fig. 1: ARP-Path operation in an Ethernet-based network

Although ARP-Path takes it name from the ARP protocol and bases its exploration in the ARP frames, it could be applied to non-ARP based networks, such as IPv6 networks. The only difference is that ARP-Path should use a specific frame for the exploration in that case.

Iii-B wARP-Path

The wARP-Path protocol follows the same basics for creating paths to reach final hosts than ARP-Path. However, there are three main differences:

  1. Locking mechanism: The ARP-Path protocol locks the input port with the source MAC address in the arriving ARP message. In wireless networks there are no links and therefore no ports, so the locking mechanism saves the {MAC address, next hop’s MAC address} tuple instead of the {MAC address, port} one. Basically, wARP-Path locks nodes instead of input ports.

  2. Flooding: To explore the network and reach the destination, the ARP-Path protocol broadcast frames through all ports but the input one. However, this concept is not directly applicable to wireless forwarding devices, which always broadcast frames in the whole radio coverage area.

  3. Forwarding nodes: The ARP-Path protocol is used in bridge-based networks. However, wARP-Path can be applied to any ad hoc wireless network. For this reason, intermediate nodes can be final hosts at the same time, and therefore they might implement more communication layers than bridges (up to layer two only). This causes that ARP messages already have a default processing by intermediate nodes that should be slightly modified, i.e. intermediate nodes should discard only sARP messages not directed to them and not all of them (which is done in ARP-Path by default).

Fig. 2 shows and example of a network, consisting of six intermediate nodes and two final hosts, in which wARP-Path can be applied. A circular dotted line represents the range or coverage area of each forwarding node. The range of final hosts is not represented, but we considered they reach only the closest node, for the sake of simplicity.

(a) Learning process for path to when the ARP Request is broadcast
(b) Learning process for path to when the ARP Reply is sent from to
Fig. 2: wARP-Path operation in a wireless network

In this example, there are two possible paths between host and host , same ones than in the example in Fig. 1. When host emits the ARP Request message to start the communication, it first reaches node 1 which saves the tuple A’s MAC address, A’s MAC address since transmitter address of the frame received from host is regarded as the next hop address in host 1(i.e. in this case, the next hop is directly A). Later on, other nodes receive the frame, such as node 3, which saves the tuple A’s MAC address, 2’s MAC address, indicating that node 2 is locked as the next hop for the path to reach . Eventually, several frames arrive to node 6, which only locks the MAC address of the first node from which it received the frame and discards the rest.

Differently to ARP-Path, in wARP-Path many nodes receive back multiple copies of the frame and need to discard them. This is because wireless nodes emit in their range and cannot avoid emitting back to the previous sender as in wired networks, where it is possible to flood through all ports but the incoming one.

Finally, host receives the ARP Request message and emits the ARP Reply message with destination . This ARP Reply message can follow the path just created to and, at the same time, it creates the path to . Therefore the communication between and can start now, which will use the path involving nodes 1-2-3-6.

The pseudocode of the wARP-Path protocol is summarized in Listing 1.

When a wARP-Path node receives a frame from another node:
01:if (src_mac ==  nodes MAC address) then
02:    discard frame
03:else
04:    eth_frame = convertToEthernetFrame(frame)
05:    next_hop = wARP-Path table(eth_frame, input_hop)
06:    If (dst_mac ==  nodes MAC address) then
07:        send frame to upper layers of the node
08:    else if (dst_mac ==  BCAST && next_hop) then
09:        send frame to upper layers of the node
10:    If (next_hop) then
11:        send frame to the next hop
12:    else
13:        discard frame
Listing 1: Pseudocode of the wARP-Path protocol

Iii-C From a wired to a wireless frame format

Apart from the implications previously mentioned, the implementation of wARP-Path requires another one related to the frame format.
ARP-Path leverages the fact that Ethernet is the most commonly used layer 2 protocol, and reuses the Ethernet frame for its purpose. However, wARP-Path depends on the type of network that relies beneath and their corresponding frame format.

Therefore, for the sake of simplicity, we considered wireless local area networks, following the standards defined by IEEE802.11 [18].

Iv Implementation

Fig. 3: Implementation of the AdhocHostAPB module in OMNeT++ 4.2.2 and INET 2.0.0

As mentioned in the introduction, the ARP-Path protocol had been previously implemented in different platforms. However, most of them are intended for wired networks. Therefore, we decided to implement wARP-Path in the OMNeT++ simulator, which was the fastest alternative to check the suitability of the protocol for wireless networks.

Iv-a Implementation in OMNeT++ 4.2.2 and INET 2.0.0

The wARP-Path was first developed by modifying some parts of the modules defined for ad hoc networks in the INET framework for OMNeT++, specifically the modification was done in the so-called AdHocHost module which was converted into the a new module called AdHocHostAPB by adding a relay submodule in it, as it can be seen in Fig. 4.

The AdHocHost module implements, as it name recalls, a host for wireless ad hoc communications. This module is composed of several submodules. For instance, in the lower part, we can see several submodules directly related to the physical layer (wlan, eth, ppp, etc), while in the upper part there are modules associated to the application (tcpApp, udpApp, etc) and transport (tcp, udp, etc) layer. At the same time, most of the submodules are connected to the network layer submodule (called networkLayer), which is responsible of routing decisions and it can apply different protocols for it, such as AODV. The module developed for implementing the wARP-Path PoC was called AdHocHostAPB, which is shown in Fig. 4, and it is an extension of the AdHocHost, which simply adds and intermediate module between the network layer and the physical layer, and it is called relayUnit. The relayUnit submodule applies learning and forwarding based on the frames received from the wlan submodule, specifically it applies the pseudocode shown before in Listing 1 for any frame received from wlan.

Iv-B Implementation in OMNeT++ 5.2 and INET 3.6.3

Lately, the wARP-Path protocol was reimplemented using the latest version of OMNeT++ and INET framework (code available in [19]). The reason behind is that INET is quickly updated, and it covers a wide variety of protocols and components, and also, it is taken as a base for several other simulation frameworks [20].

Most of the differences in the two implementations are due to the evolution of the INET framework. In the recent versions of INET framework, the forwarding table (macTable) has been separated from the MAC relay unit (MACRelayUnit). Based on this, in this new implementation, the Learning/Lookup Table (LT) and Blocking/Broadcast Table (BT) are separated from the MACRelayUnit and placed beside the MACRelayUnit as two independent modules to provide the service to the MACRelayUnit, as it can be seen in Fig. 4. All steps of the algorithm excluding line 05 (as shown in Listing 1) are implemented in the Ieee80211MgmtAdhocAPB module, and line 05 is implemented in the MACRelayUnitWAPB module.

Fig. 4: Implementation of the AdhocHostAPB module in OMNeT++ 5.2 and INET 3.6.3

There are two addresses for forwarding between two sequential hops (physical addresses) and two other addresses to indicate the beginning and end of the path (logical addresses). All four address fields embedded in the IEEE 802.11 MAC frame format (as shown in Fig. 4(a)) are used, which are receiver address as physical receiver, transmitter address as physical transmitter, destination address as logical receiver, and source address as logical transmitter respectively (as shown in Fig. 4(c)). The physical addresses change in each hop, and the logical addresses do not change in the intermediate nodes, but in the final destination. To achieve the transparency required for the upper layer, the logical addresses are put in the physical address space before decapsulating the frame.

(a) IEEE 802.11 frame format
(b) Interpretation of the MAC Addresses in the Ad-hoc mode
(c) Interpretation of the MAC Addresses in wARP-Path
Fig. 5: Applying the address fields of IEEE 802.11 frame format in wARP-Path

Iv-C Regarding OMNeT++/INET and their implementation of media access control in wireless networks

In OMNeT++, frames are usually flooded at the same exact simulated time. Accordingly, when there is more than a single path to reach destination and the frame is being flooded for path exploration as in wARP-Path, it is high probability that some nodes will simultaneously broadcast this frame, e.g. an ARP Request. Since there is no unique receiver for sending the broadcast packets, no control packets (Request-to-Send (RTS) and Clear-to-Send (CTS)) are used and only carrier sense on the transmitter is performed because of the lack of coordination of the receivers and the possibility of a collision between the CTSs [21]. If a broadcast packet collides, in addition to wasting a further capacity of the channel since the broadcast packets are larger than the control packets, it also has a negative impact on the quality of the explored paths. Therefore, a solution to this problem is necessary.

In the AODV implementation of INET framework, using a random jitter before sending protocol control packets such as hello, Route Request (RREQ), and Route Reply (RREP) messages according to RFC 5148 [22] has been adopted to overcome this problem. In this way, two random jitter has been used. First, when AODV generates the periodic hello messages in INET framework, for this type of simultaneity in RFC 5148, a random value (jitter) is subtracted from the time interval between two consecutive transmission of the same type messages(MESSAGE_INTERVAL). Using subtract instead of sum prevents excessive delay in receiving messages. Second, when AODV generates the RREQ and RREP messages in INET framework, since these messages are not periodic messages, there is not any (MESSAGE_INTERVAL) to calculate the delay. In this type of simultaneity, RFC 5148 introduces jitter in an interval between zero and MAXJITTER.

We use the same approach to overcome the simultaneously broadcast problem in wARP-Path, with the difference that the control messages in this protocol are the standard ARP packets. Therefore, the mechanisms mentioned above apply to these packets similarly.

V Evaluation

This chapter is devoted to evaluate wARP-Path. An initial thought was to compare it with AODV, but we found a bug in the implementation of AODV in the INET framework 111More specifically, some RREQ packets are deleted, and it has a negative impact on the end-to-end delay and quality of discovered routes of AODV.. Therefore, we finally decided to exclude the evaluation of AODV (as results were not reliable) from our analysis.

In this evaluation, we first define the test cases and scenarios. We then briefly compare wARP-Path and ARP-Path, and finally we analyze wARP-Path in terms of goodput ratio and average end-to-end delay.

V-a Definition of test cases and scenarios

In order to evaluate the wARP-Path protocol, our model was inspired by [23] and [24]

. We defined 50 nodes uniformly distributed within a fixed-size area of 1500 * 1500. To manage centralized behaviors such as: (1) the uniform election of a source and destination node between all nodes to start a session, (2) the selection of traffic for a session based on Table 

I, or (3) the computation of the average metrics for all nodes and flows in the network, we defined a module called flowGenerator in the simulation. Interval time of the simulation is 600s and the first session is started at time 0.2s. Next session is started after 10 seconds and other sessions are started after the same time, periodically. By using a fixed time (i.e. 10s) instead of a random time in an interval, we adopted enough interval between the flows so that we can analyze the effect of the ARP Request messages on other flows. The total number of sessions in the simulation is 10.

Parameter S_DATA VOICE
Transport protocol UDP UDP
Session interval Geometric (mean 900) Geometric (mean 600)
Packet size 64 Bytes 160 Bytes
Packet send interval 20 ms 20 ms
TABLE I: Traffic Parameters

Two types of traffic will be analyzed: S_DATA (that stands for small data) and VOICE, as defined in [23].
To generate S_DATA traffic, as it can be seen in Table I, data packets contain 64 bytes, and inter-arrival time of data packets is 20 ms. Therefore, this traffic is produced with a rate of 25,6 Kbps in each selected host as a source per session.
To generate VOICE traffic, as also illustrated in Table I, we suppose that quality of voice is telephony, so sampling frequency is 8 KHz. Since each sample is expressed with 1 byte, each selected host as a source per session produces a traffic with rate of 64 Kbps. Given that each packet is generated every 20 ms, the packet size is 160 bytes.

Each node has one transmitter and one receiver, and all nodes use the same channel model. Their physical and MAC layers are based on IEEE 802.11 [18], considering the Distributed Coordination Function (DCF) mode, whose properties are shown in Table II.

Parameter Value
Simulation time 600 s
Traffic generation start time 0.2 s
Traffic generation start time 600 s
wARP-Path
LT aging time 120 s
BT blocking time 1 s
MAXJITTER 5 ms
Jitter uniform(0, MAXJITTER)
ARP protocol
ARP retry count 5
ARP retry timeout 200 ms
ARP cache timeout 120 s
MAC layer
IEEE802.11 type IEEE802.11 g
Maximum size of queue 14
MAC retry limit 7
CW min (for S_DATA) 15 time slots
CW min (for VOICE) 20 time slots
Phy layer
Carrier frecuency 2.4 GHz
Bandwidth 2 MHz
Modulation scheme BPSK + DSSS
Bit rate 1 Mbps
Transmit Power 2 mW
Receiver sensitivity -85 dBm
SINR threshold 4dB
Energy detection threshold -85 dBm
Path loss type Free Space Path Loss
Background noise power -110 dBm
TABLE II: Simulation Parameters

V-B Comparison with ARP-Path

The wARP-Path protocol is quite similar to ARP-Path. But in wARP-Path, since intermediate nodes are hosts (not only switches) that can create a new session to each destination, they can use the paths explored by each node that is not an intermediate node. According to computation of forwarding state in the ARP-Path protocol [1], in the worst case of ARP-Path, when all nodes (non-intermediate) communicated with each other, the paths between some non-intermediate nodes and some intermediate nodes had been creating. Now, in wARP-Path, since intermediate nodes have the capability to start a session with non-intermediate nodes, they can start some additional sessions without adding new entries in the forwarding tables, and this amount of communications without inserting a new entry in tables is a payoff of wARP-Path against ARP-Path protocol. Briefly, with the same number of entries in forwarding tables, wARP-Path might have a higher number of active communications than ARP-Path.

V-C Goodput Ratio

(a) S_DATA
(b) VOICE
Fig. 6: Achieved Goodput Ratio
S_DATA Traffic
Session # Source Destination Amount of Traffic Start Time End Time # ARP Requests # ARP Replies Path Discovered
1 Host 42 Host 24 3.5424e+006 B 0.2 s 1107.2 s 163 19
2 Host 3 Host 8 2.0576e+006 B 10.2 s 653.2 s 5 5
3 Host 21 Host 19 6.5216e+006 B 20.2 s 2058.2 s 3165 (flows 3, 5) 0 -
4 Host 43 Host 41 665600 B 30.2 s 238.2 s 2 2
5 Host 21 Host 38 1.6704e+006 B 40.2 s 562.2 s 3165 (flows 3, 5) 29
6 Host 20 Host 44 451200 B 50.2 s 191.2 s 51 7
7 Host 39 Host 14 3.0144e+006 B 60.2 s 1002.2 s 71 16
8 Host 26 Host 17 1.2544e+006 B 70.2 s 462.2 s 2000 0 -
9 Host 22 Host 2 2.5696e+006 B 80.2 s 883.2 s 6 6
10 Host 1 Host 26 860800 B 90.2 s 359.2 s 1375 0 -
VOICE Traffic
Session # Source Destination Amount of Traffic Start Time End Time # ARP Requests # ARP Replies Path Discovered
1 Host 42 Host 24 5.904e+006 B 0.2 s 738.2 s 18 5
2 Host 3 Host 8 3.424e+006 B 10.2 s 438.2 s 2 2
3 Host 21 Host 19 1.0864e+007 B 20.2 s 1378.2 s 2818 (flows 3, 5) 0 -
4 Host 43 Host 41 1.112e+006 B 30.2 s 169.2 s 1 1
5 Host 21 Host 38 2.784e+006 B 40.2 s 388.2 s 4 (flows 3, 5) 4
6 Host 20 Host 44 752000 B 50.2 s 144.2 s 16 3
7 Host 39 Host 14 5.016e+006 B 60.2 s 687.2 s 54 8
8 Host 26 Host 17 2.088e+006 B 70.2 s 331.2 s 525 0 -
9 Host 22 Host 2 4.28e+006 B 80.2 s 615.2 s 2 2
10 Host 1 Host 26 1.432e+006 B 90.2 s 269.2 s 360 0 -
TABLE III: Generated flows

The goodput ratio is calculated over the entire network when a host generates or receives a packet on the network. Therefore, goodput ratio is a function of time in the simulation time interval, and we denote it as follows:


where is the number of bytes in packets generated by the application layer of hosts from the start time of the simulation until time , and is the number of bytes in packets received by the application layer of hosts from the start time of simulation until time . The reason of using number of bytes instead of the number of packets is because the last packet of each session might vary in size, depending of the session, although this situation did not occur in our traffic.

Figures 5(a) and 5(b)

respectively show the achieved goodput ratio as a function of time for S_DATA and VOICE traffic with 10 sessions. As depicted in the figures, at the initial moments of the simulation, goodput ratio is low since source hosts only generated packets, and no destination host received packets. After this small interval, once destinations received packets, the goodput ratio increasingly grows near to 100%. This situation is stable until the number of sessions and broadcasts increase.


Although using jitter is a good approach to overcome broadcast problems, this problem can still cause collision with other broadcast (simultaneously forwarding), RTS (simultaneously forwarding), CTS (when the RTS sender is hidden from broadcast sender), or even ACK or data (when CTS has collided and a node that is hidden from the RTS sender sends a broadcast) packets in dense and high broadcast scenarios. Therefore, when the number of broadcasts increases in the network, as mentioned in previous section, it negatively affects on the channel capacity and quality of the explored paths (and even a path can not be discovered though it exists), which causes reduction of the goodput ratio.
Time interval between two consecutive packets is the same in both traffic types, but since VOICE packets are bigger than S_DATA packets, the probability of collision increases with VOICE packets, and the loss of a packet has a greater impact on its respective goodput ratio.

The traffic is UDP, connection-less and unreliable transport protocol, and there is no hand shaking, so traffic is continuously injected to lower layer. As shown in Table III (i.e. sessions 3, 8, and 10 in both traffic types), a lot of traffic is wasted before a path is found (or there is no path at all), which causes that the goodput ratio stays at the same low value. For S_DATA traffic, they produce 3970560 bytes until the end of simulation. If we reduce this value (i.e. total sent bytes in Table IV), the goodput ratio is increased up to 48.12%.

As shown in Table III, another impact of the injected traffic to lower layers are the ARP Request messages, which are frequently sent to the network. Collisions resulting from these broadcasts will negatively affect the goodput ratio and the delay. Collision of the broadcast packets with control and data packets will cause the MAC layer to increase CW and select a back-off value in a larger range. Therefore, delay increases in the interval in which ARP Request messages enter the network, and also using the jitter will cause a delay in starting a transmission.

V-D End-to-end Delay

(a) Average end-to-end delay computed in each interval for all hosts
(b) Average end-to-end delay of all hosts
(c) Average end-to-end delay of each host
Fig. 7: Achieved end-to-end delay for S_DATA traffic
(a) Average end-to-end delay computed in each interval for all hosts
(b) Average end-to-end delay of all hosts
(c) Average end-to-end delay of each host
Fig. 8: Achieved end-to-end delay for VOICE traffic
S_DATA VOICE
Goodput ratio 34.22% 26.99%
Average end-to-end delay 0.0431 s 0.0579 s
Average end-to-end delay last intvl 0.0081 s 0.0316 s
Total sent bytes 1.3742848E7 2.95056E7
Total sent packets 214732 184410
Total received bytes 4702784 7964160
Total received packets 73481 49776
TABLE IV: Results at the end of simulation

Additionally, we computed the average end-to-end delay of the network based on the following equation for both each host and all possible destinations in the network.

Considering the equation, is a packet received to the host for which we want to calculate average end-to-end delay, is the arrival time of packet at the application layer, denotes the end-to-end delay of packet which is obtained by subtracting the arrival time of the packet () from the generation time of the packet (), and is the number of elements in the set. In case of calculating the average end-to-end delay of all the network, is the packet received by one host.

Figures 6(c) and 7(c) respectively show the average end-to-end delay of each host for the traffics of S_DATA and VOICE for 10 sessions. Figures 6(b) and 7(b) respectively show the average end-to-end delay of all the network for the traffics of S_DATA and VOICE with 10 sessions.

The values just mentioned give us good information about the overall and current state of the network. To calculate end-to-end delay, since there are peaks at the end-to-end delay of the network and in order to balance these peaks, we obtain the average end-to-end delay in the small intervals (for example, this interval we will denoted by , and it is 1 second in our simulation) based on the following equation, instead of pure end-to-end delay (as shown in Figures 6(a) and 7(a)).

Vi Discussion

Finally, we discuss different aspects of the wARP-Path protocol. Particularly, in some of the topics we compare wARP-Path to AODV, which we consider the most similar protocol, as they are both reactive routing protocols for layer 2 and layer 3, respectively.

Layer 2 vs. Layer 3
wARP-Path acts on Layer 2, and since this protocol tries to find the shortest paths with the least load and delay, so it can as well take advantages of this layer on the network, such as higher speed and lack of processing latency due to layer 3 routing.
Since on-demand routings are based on query reply, they endure a delay to find a route [10]. However, ARP-Path uses standard ARP Request and ARP Reply packets for exploring a path, it does not include this delay.

Scalability
In on-demand protocols, when a node wants to communicate with a destination, the route is computed. Therefore, they do not store route information for all destinations permanently, so this feature increases their scalability to be used in large networks [10]. Despite this common feature in both wARP-Path and AODV, each protocol has unique features which cause differences in their scalability. In spite of the mentioned advantages of Layer 2 for wARP-Path, this protocol uses the flat addressing structure in layer 2, and AODV uses the hierarchical structure of IP addressing in Layer 3. Hierarchical routing increasingly reduces the size of routing tables and processing overhead [10], whereas using the flat addressing structure raises the problem of increasing the number of entries in the forwarding tables.
In general, we found that scalability was the first issue when migrating the ARP-Path protocol to wireless networks.

Stability vs Mobility
Wired networks are more stable than wireless networks due to their nature in using fixed nodes and links. This is one of the reasons why the protocols used in these two types of networks are different. Since the All-Path protocols have been designed for wired networks, they are inherently stable. ARP-Path, as one of these protocols, tries to maintain the stability of the path until the end of each communication unless network physical stability is lost. In this case, by sending the path recovery messages, it starts to discover the path in the unstable parts of the network. The stability of paths is maintained by refreshing the lifetime of the entries in the forwarding tables until the end of a communication.
But in AODV, designed for using wireless networks, this bound of stability seen in the ARP-Path is not seen here. The discovered routes in AODV are not necessarily kept to the end of communication, and life time of the routes in the routing tables are not updated by transferring data packets, they are updated only by transferring protocol packets such as RREQ and RREP. The existence of this feature in AODV increases its efficiency to overcome the unstable state of nodes and links in wireless networks.

Path repair
Another issue found when migrating the protocol was path repair. In wired networks, link failure detection is direct, as usually the physical layer provides this feature. However, link failure detection in wireless networks requires additional mechanisms, not only to probe if neighbors are still available, but also to guarantee if packets are effectively reaching their destinations.
Additionally, the path repair mechanism in ARP-Path requires broadcasting and might be too costly for wireless networks, especially when their nodes have mobility. So simple methods such as broadcasting might be more efficient. That is the main reason why we did not implement and test path repair in wARP-Path.

Wireless frame format
ARP-Path leverages the fact that the most common frame format in wired networks is Ethernet. However, in wireless, there is a wide range of layer 2 frames and protocols, such as WiFi, WiFi-Direct, Bluetooth, Bluetooth SMART or BLE [25], LR-WPAN (802.15.4) or Zigbee.
This diversity affects the implementation of wARP-Path, which might have variations depending on the layer 2 implemented.

Software-Defined Networking
Software-Defined Networking (SDN) [26] is flourishing rapidly and, although the initial deployments were based on wired networks, wireless networks are also targeted as part of the SDN spectrum, which makes harder the appearance of new distributed protocols.
Thus, wARP-Path is not good enough to beat the advantages of SDN and a more disruptive approach to wireless networks should be applied, instead of a simple migration of a protocol from wired to wireless.

Vii Conclusion

Along the article we have studied the implications of adapting a wired bridging protocol to a wireless environment. Apart from the specificities of the implementation, we have discovered to main drawbacks during the migration:

  1. Frame format: Wired bridging protocols are mainly Ethernet-based, while in wireless the frame format is diverse and we had to choose one to continue the implementation (i.e. moving from one frame format to other might not be necessarily straightforward). This affects our protocol as is based on layer 2, but it would not affect layer 3 routing protocols.

  2. Flooding and scalability: While broadcast in wired networks might be relatively useful in some scenarios, in wireless networks might be totally unacceptable. More specifically, wireless networks always flood the information per se (the radio signal is received by all nodes in the range), so adding an overhead to the forwarding protocol should imply –at least– saving time in processing the frame, i.e. avoiding broadcasting the frame whenever possible.

Additionally, some mechanisms such as path repair are not applicable to wireless networks, which imply redesigning parts of the protocol (e.g. to define some type of keep-alive or mobility-awareness mechanism).

Therefore, although ARP-Path is a simple and efficient protocol for wired bridging, wARP-Path did not show the equivalent benefits for wireless networks. The main conclusion is that wireless bridging protocols should be more efficient than routing protocols in different aspects (for example, drastically decreasing table size), with a groundbreaking approach, otherwise protocols as AODV or even applying SDN might still be more suitable for wireless networks.

Acknowledgment

This work has been supported by Comunidad de Madrid through project TIGRE5-CM (S2013/ICE-2919).

References

  • [1] E. Rojas, G. Ibáñez, J. M. Gimenez-Guzman, J. A. Carral, A. Garcia-Martinez, I. Martinez-Yelmo, and J. M. Arco, “All-Path bridging: Path exploration protocols for data center and campus networks,” Computer Networks, vol. 79, pp. 120 – 132, 2015. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1389128615000055
  • [2] J. Alvarez-Horcajo, D. Lopez-Pajares, J. M. Arco, J. A. Carral, and I. Martinez-Yelmo, “TCP-path: Improving load balance by network exploration,” in 2017 IEEE 6th International Conference on Cloud Networking (CloudNet), Sept 2017, pp. 1–6.
  • [3] G. Ibáñez, J. A. Carral, J. M. Arco, D. Rivera, and A. Montalvo, “ARP-Path: ARP-Based, Shortest Path Bridges,” Communications Letters, IEEE, vol. 15, no. 7, pp. 770–772, 2011.
  • [4] G. Ibañez, J. Naous, E. Rojas, D. Rivera, J. A. Carral, and J. M. Arco, “A Simple, Zero Configuration, Low Latency Bridging Protocol,” IEEE LCN Demos, 2010.
  • [5] D. Allan and N. Bragg, 802.1 aq Shortest Path Bridging Design and Evolution: The Architect’s Perspective.   John Wiley & Sons, 2012.
  • [6] R. Perlman, D. E. Eastlake, D. G. Dutt, S. Gai, and A. Ghanwani, “Routing Bridges (RBridges): Base Protocol Specification,” RFC 6325, Jul. 2011. [Online]. Available: https://rfc-editor.org/rfc/rfc6325.txt
  • [7] R. Perlman, “Introduction to TRILL,” The Internet Protocol Journal, vol. 4, no. 3, pp. 2–20, 2011.
  • [8] S. R. Das, C. E. Perkins, and E. M. Belding-Royer, “Ad hoc On-Demand Distance Vector (AODV) Routing,” RFC 3561, Jul. 2003. [Online]. Available: https://rfc-editor.org/rfc/rfc3561.txt
  • [9] E. M. Belding-Royer and C. E. Perkins, “Evolution and future directions of the ad hoc on-demand distance-vector routing protocol,” Ad Hoc Networks, vol. 1, no. 1, pp. 125 – 150, 2003. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1570870503000167
  • [10] A. Iwata, C.-C. Chiang, G. Pei, M. Gerla, and T.-W. Chen, “Scalable routing strategies for ad hoc wireless networks,” IEEE Journal on Selected Areas in Communications, vol. 17, no. 8, pp. 1369–1379, Aug 1999.
  • [11] Y.-C. Hu, D. A. Maltz, and D. B. Johnson, “The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4,” RFC 4728, Feb. 2007. [Online]. Available: https://rfc-editor.org/rfc/rfc4728.txt
  • [12] S. R. Das, C. E. Perkins, and E. M. Royer, “Performance comparison of two on-demand routing protocols for ad hoc networks,” in Proceedings IEEE INFOCOM 2000. Conference on Computer Communications. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies (Cat. No.00CH37064), vol. 1, 2000, pp. 3–12 vol.1.
  • [13] L. He, J. Huang, and F. Yang, “A noval hybrid wireless routing protocol for WMNs,” in 2010 International Conference on Electronics and Information Engineering, vol. 1, Aug 2010, pp. V1–281–V1–285.
  • [14] L. Zhu, C. Lin, K. Meng, and Y. Dong, “P-AODV: A protection routing mechanism in wireless mesh networks,” in 2013 15th IEEE International Conference on Communication Technology, Nov 2013, pp. 505–510.
  • [15] L. Hong, X. Liu, L. Zhang, and W. Chen, “Towards sensitive link quality prediction in ad hoc routing protocol based on grey theory,” Wireless Networks, vol. 21, no. 7, pp. 2315–2325, Oct 2015. [Online]. Available: https://doi.org/10.1007/s11276-015-0918-z
  • [16] I. M. Suliman, T. Saarinen, T. M. Hautala, W. Cheng, and T. Braysy, “A comparison study between wireless bridging and routing,” in International Workshop on Wireless Ad-Hoc Networks, 2004., May 2004, pp. 140–144.
  • [17] S. Maurina, J. Fitzpatrick, L. Trifan, and L. Murphy, “An enhanced bridged-based multi-hop wireless network implementation,” in 2010 The 5th Annual ICST Wireless Internet Conference (WICON), March 2010, pp. 1–9.
  • [18] “ IEEE 802.11TM WIRELESS LOCAL AREA NETWORKS.” [Online]. Available: http://www.ieee802.org/11/
  • [19] “wARP-Path.” [Online]. Available: https://github.com/gistnetserv-uah/AllPath-OMNeT/
  • [20] “INET Framework.” [Online]. Available: https://inet.omnetpp.org/
  • [21] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang, “MACAW: a media access protocol for wireless LAN’s,” ACM SIGCOMM Computer Communication Review, vol. 24, no. 4, pp. 212–225, 1994.
  • [22] T. Clausen, C. Dearlove, and B. Adamson, “Jitter Considerations in Mobile Ad Hoc Networks (MANETs),” RFC 5148, 2008. [Online]. Available: https://rfc-editor.org/rfc/rfc5148.txt
  • [23] C. Perkins and E. Royer, “Ad-hoc on-demand distance vector routing,” in Proceedings Of the 2 IEEE workshop on Mobile Computing System and Applications.   IEEE, 1999, pp. 90–100.
  • [24] J. Broch, D. A. Maltz, D. B. Johnson, Y.-C. Hu, and J. Jetcheva, “A performance comparison of multi-hop wireless ad hoc network routing protocols,” in Proceedings of the 4th annual ACM/IEEE international conference on Mobile computing and networking.   ACM, 1998, pp. 85–97.
  • [25] C. Gomez, J. Oller, and J. Paradells, “Overview and evaluation of bluetooth low energy: An emerging low-power wireless technology,” Sensors, vol. 12, no. 9, pp. 11 734–11 753, 2012. [Online]. Available: http://www.mdpi.com/1424-8220/12/9/11734
  • [26] D. Kreutz, F. M. V. Ramos, P. E. Verissimo, C. E. Rothenberg, S. Azodolmolky, and S. Uhlig, “Software-Defined Networking: A Comprehensive Survey,” Proceedings of the IEEE, vol. 103, no. 1, pp. 14–76, Jan 2015.