[10] Hans Eriksson, âMbone: the multicast backbone,â Com- munications of the ACM, vol. 37, no. 8, pp. 54â60, 1994. [11] Ivano Guardini, Paolo Fasano, and ...
Exploiting Relative Addressing and Virtual Overlays in Ad Hoc Networks with Bandwidth and Processing Constraints Marco Aur´elio Spohn
J.J. Garcia-Luna-Aceves
Computer Science Department University of California at Santa Cruz Santa Cruz, CA 95064
Computer Engineering Department University of California at Santa Cruz Santa Cruz, CA 95064
Abstract—The suitability of using relative addressing to help support the deployment of customized protocols or reduce the communication and processing overhead of signaling packets is explored. The basic approach consists of breaking the signaling used for routing into an addressing component and a routing component, and establishing virtual networks that use relative addressing and customized protocols within such networks. Specific examples of how routing update mechanisms can be expedited with relative addressing are presented. A specific approach to make AODV support address mappings for “virtual networks” is described. The performance of an ad hoc network running IPv4 and an example customized protocol (called TIP) is discussed. Simulation results in GloMoSim illustrate that significant savings can be attained using relative addressing in scenarios with low bandwidth and traffic mostly composed of small packets, both of which are expected in ad hoc networks of sensors. Index Terms— Network address translation in wireless networks, overlay networks, sensor networks, relative addressing
I. I NTRODUCTION The Internet architecture today follows the catenet model [1] for the interconnection of heterogeneous networks, and the Internet Protocol (IP) has become the envelope with which signaling and user data are exchanged in networks participating in the Internet. IP assumes that address spaces are global and hence serve the purposes of naming each network in the Internet. In spite of its success, Marco A. Spohn is supported by CNPq, Brazil.
applying the catenet model to ad hoc networking environments in which bandwidth and processing constraints are severe, and in which communicating nodes are highly specialized (in terms of their functions and the parties with which they need to communicate) poses a number of limitations. To illustrate this point, consider the case of an ad hoc network with hundreds of nodes, and assume that only a few nodes are communicating among each other. This still incurs all the extra overhead imposed by IP (i.e., at least 20 bytes headers) and more control data exchanged among the nodes for routing purposes. The ideal situation would be to have these nodes communicating among each other using another network protocol tailored for their purposes, with a small address space and a routing table that only needs to consider the few nodes out of the hundreds of nodes that need to communicate. This paper addresses the use of relative addressing and virtual overlays in ad hoc networks with severe bandwidth and processing constraints to reduce the signaling overhead and the communication and processing overhead incurred in switching packets compared to the use of IPv4 as the only network-level protocol. Section II presents our approach using AODV (Ad-hoc On-demand Distance Vector routing) [7] with our extensions to support relative addressing (AODV-RA) as an example of how relative addressing and virtual overlays can be instantiated in order to reduce bandwidth and processing overheard in ad hoc networks. Section III compares the performance of ad hoc networks run ning and AODV with the performance of
the same networks running tiny IP (a sample customized protocol) and AODV with support for relative addressing (AODV-RA), in terms of end-toend delays and packet-delivery ratios. II. I MPLEMENTING R ELATIVE A DDRESSING A network protocol can be customized according to the expected number of nodes that will have to run the protocol; e.g., if it is known in advance that only six nodes will be talking to each other for a period of time, then we use network addresses of only three bits (we will show later that we can address even more “sessions” using such a few bits for network addresses). What we need is a mechanism that allows us to build the virtual network and that guarantees the correct delivery of packets into the virtual network. Accomplishing this can be done via a combination of active networks and overlay networks. The active network component encompasses the capability of deploying or calling new network protocols on demand over all the nodes used as routers by the communicating nodes. The overlay network component is the virtual network established among the nodes speaking the new network protocol. There are two main types of unicast routing protocols in wireless ad hoc networks. Pro-active protocols determine routes independently of traffic pattern; in this category we have the traditional link state and distance vector routing protocols, and some examples in the wireless world are the Wireless Routing Protocol (WRP) [4] and the Destination-Sequenced Distance Vector (DSDV) protocol [5]. Reactive protocols maintain routes only if necessary (i.e., keep routes only to active destinations). Dynamic Source Routing (DSR) [6] and the Ad-hoc On-Demand Distance Vector Routing (AODV) [7] are two examples into this category. In addition, some combine proactive and on-demand mechanisms. For example, the Zone Routing Protocol (ZRP) [8] acts pro-actively on the node’s local neighborhood, and the reactive procedure is executed only for routes to destinations far-away. Instead of devising a new routing protocol, our approach to support on-demand overlay networks is based on reusing protocols available and simply adapting them for our needs.
Our approach to the building of overlay networks using IP as the baseline signaling protocol makes the following assumptions: IP is used as the common signaling plane. Each node is assigned a unique IP address that serves as its global name. IP is used in a global basis, since local identifiers are valid only into a particular virtual network. A number of delivery protocols can be called at each node on demand. Defining the common signaling entails: Establishing the mapping of IP addresses with which nodes are globally known to the identifiers used in the virtual network. Developing the virtual net joining mechanisms. Depending on the unicast routing protocol this can be part of the routing protocol itself. An overlay network can be defined as any network built on top of an existing network infrastructure. It is not a new idea, the Internet itself was initially built over the telephone network [9]. Overlays are useful for deploying new protocols and applications over virtual networks, for hiding and simplifying the underlying topology, for increasing the fault tolerance by allowing virtual networks to overlap, and for providing dynamic relocation of network resources. So far, several overlay networks have been built over the Internet to provide other services not available in the current Internet architecture ([10], [11], [12], [9]). Because a node can participate actively or as a relay in multiple “virtual networks”, it is necessary to have a mapping of IP addresses (which are unique accordingly to our first assumptions) to “virtual” (and transient) addresses used into a particular overlay network. We have adapted our address mapping mechanism to the AODV protocol and focus only on those changes applied to AODV that make the address mapping possible. The address mapping mechanism is a specialized version of NAT (Network Address Translation); therefore, it can be easily adapted to any other routing protocol. A. Path Discovery The AODV route discovery works as our virtual net joining mechanism. We assume bidirectional
links. IP is used only for control packets: route request (RREQ), route reply (RREP), and route error (RERR). IP works as the common signaling plane, and it has to be that way because only IP addresses are known globally. Local virtual addresses do not have any meaning for nodes located far away. It will be shown later that only one-hop neighbors need to know locally assigned virtual addresses. Nodes assign virtual addresses to a new session when initiating a RREQ and when relaying a RREQ. The address mapping mechanism must guarantee that virtual addresses are unique for any given session. Because the address translation takes place before a packet is forwarded to the next hop toward the destination, we only need to ensure consistent translation on a hop-by-hop basis. All active nodes keep a Neighbor Address Mapping Table (NAMT) for every neighbor participating in any valid session. An NAMT table is tagged with both the IP address and MAC address of the corresponding node. In AODV, a neighbor is considered active if it is currently used to reach a given destination and at least one packet for that destination has been sent to or received from the neighbor within the most recent active timeout period [7]. Besides the NAMT table for every active neighbor, a node keeps an NAMT table for itself to store session mappings assigned locally (when the node is the initiator or is relaying a RREQ). Virtual addresses are assigned on a session basis per next hop towards the destination. To provide a distributed address assignment mechanism we need to make sure that there is no possibility of conflicts. That is, the address assignment mechanism must be consistent by producing a unique pair of addresses for every given session shared among neighbors. Considering network addresses of bits, we have the following possible session identi
fiers: to to to .. .. . . .. . to "!# $!% Addresses with the format are naturally excluded because they have the same identifiers for both source and destination. Addresses within the
"!# & "!# $!'( range to they
are $!% excluded "!)*because $!% conflict with identifiers to assigned by a neighbor. Hence, with network +$,)-/. addresses 4365 01 of bits we can address up to 2 . -/.87 9: sessions. For example, with network addresses of bits a node can theoretically address up to sessions per neighbor. However, this does not implythat
a node is guaranteed to initiate or respond to session requests. The intermediary nodes impose a limit on the maximum number of sessions in which a node can participate. If an intermediary node has already reached the maximum number of sessions allowed, then any subsequent session request will have to be delayed or denied. The reasons for not using a single value as the session identifier are that (a) addresses are assigned by nodes independently of each other, and (b) a pair of values can be swapped depending on the direction of the packet. If two nodes within reach of each other assign address ; to two distinct sessions, there is no way to know to each session a packet belongs to when a data packet is received. In other words, we have to be prepared to handle situations where a pair of neighbors assign the same local virtual addresses to different sessions. The way in which we can differentiate between them is based on the direction of the packet. For >?: 7"= $instance, assume that node < assigned address to session @ . , node A assigned the same address to session @ + , and that both nodes are on the path for the given sessions. Packets 7"= $>?: sent by node < to A 7 >B will have the format for session @ . and = : for session @ + . For node A we have the opposite, 7 >B = : i.e., when sending 7"= $>?: packets to < , A assigns to @ . and to session @ + . If we had chosen to go with a single value as the identifier, a conflict would have occurred and nodes < and A would have no way of knowing to which session an incoming packet belongs. The information about the session mapping is included in the RREQ packet. We have modified the RREQ packet that presents the following fields (with the exception of the fields SVA and DVA, the source and destination virtual addresses respectively, the other fields are the same as those
in AODV [7]): C source addr, source sequence #, RREQ id, dest addr, dest sequence #, hop cnt, SVA, DVA D When a node receives a RREQ, it first checks the NAMT table corresponding to the node from which the RREQ was received. If there is no entry for the requested session, a new entry is created using the information provided in the RREQ packet (source, destination, SVA, and DVA). In AODV, a RREQ triggers a RREP in the following situations: 1) The RREQ reaches the proper destination. 2) The intermediate node has a route to the destination with a sequence number that is greater than or equal to that presented in the RREQ. In the second case, the way in which RREPs are sent needs to be modified. Besides a valid route to the destination, the proper mapping of virtual to global addresses is required. That is, before replying to a RREQ a node must ensure that the next hop towards the destination already has a mapping for the given session. In this case, the node needs to search the NAMT table corresponding to the next hop towards the destination. If there is no session record in the NAMT table, then the node needs to assign addresses to the session and record this information in its own NAMT table before relaying the RREQ. The local assigned addresses are stored in the SVA and DVA fields before relaying a RREQ packet. An entry for the requested session in the next-hop NAMT table will be created only upon receiving the corresponding RREP. If a node does not have information about a session but there is an active route to the destination, the RREQ is unicasted towards the destination instead of broadcasting it. The RREQ eventually reaches the destination or an intermediate node that is aware of the requested session, and triggers a RREP towards the source. Route changes may affect session mapping availability. In those cases in which there is no mapping for a given session due to route changes, a RREQ packet is unicasted to the next hop towards the destination and it is relayed as necessary, i.e., until it reaches the proper destination or a node with the correct session mapping. Therefore, the session mapping is guaranteed to be available over
the entire new path. An active node has its own NAMT table and an NAMT table for every neighbor used to reach a node taking part in an active session. An entry in the own NAMT table specifies how the session must be represented when sending a packet, and entries in the other tables specify how sessions are recognized when the node receives a data packet. Figure 1 illustrates how this process works. Assume EF HG9that node < receives a RREQ for session . First of all, the NAMT table corresponding to the node sending the RREQ is updated with the information provided in the RREQ packet (we omitted this part given that the following steps are enough to explain how the address mapping works). Before relaying the RREQ packet, node < needs to assign a virtual address to the session. Suppose this is the first session on < ’s NAMT table. In this
case, the session will be assigned addresses (Figure Node A receives a I' &JK1a). RREQ for session , updates its own table and broadcasts the RREQ packet updated with the locally assigned virtual addresses. Figure 1b shows the resulting NAMT tables after nodes < and A process the RREQ packet received from each other. In a similar manner, nodes < and A assign local virtual addresses to the new sessions and update the corresponding SVA and DVA fields before relaying the RREQ packet. Note that even though nodes < and A have assigned the same virtual addresses to different sessions, no conflict occurs because addresses are interpreted depending on the direction of the packet. B. Address Translation The address translation process takes place when a data packet is received, and before a packet is forwarded to the next hop towards the destination. Only after the packet is processed by the NAT module it can be sent out to the next hop towards the destination or delivered to the upper layer (when the receiving node is the proper destination). A node receiving a data packet needs the virtual addresses available in the packet header and the MAC address of the node from which the data packet was received (because we do not have the IP address of the sender) in order to proceed with the address translation. For every active neighbor
NAMT B
To B :
NAMT A
To A From A :
RREQ
III. E XPERIMENTS
From B
NAMT A
RREQ
A
To A From A : :
A
B
B
NAMT B
NAMT B
To B :
From B
To B : :
From B
NAMT A
To A From A :
(a)
(b)
Fig. 1. Address mapping example: (a) node B is broadcasting a RREQ for session LNMPO QSR , and node A is broadcasting a RREQ for session LNTUOWV#R ; (b) shows the state of the NAMT tables for both nodes A and B after processing the RREQ packet received from each other and after updating their own NAMT tables.
there is an NAMT table providing the mappings from virtual addresses to global addresses. Therefore, the NAT process is a matter of searching the appropriate NAMT table when receiving or sending out a data packet. Basically, the address translation encompasses the following steps: 1) The NAMT table is located based on the MAC address of the sender. 2) The table is searched for an entry that matches the pair of virtual addresses available from the network header. 3) If the node itself is not the destination, the NAMT table corresponding to the next hop towards the destination is located. 4) The table is searched for an entry that matches the session in order to update the virtual addresses in the packet header. What we have proposed so far is a modified NAT scheme adapted to an ad hoc wireless network. That is, there is no translation to global addresses at all, since only the next-hop node needs to handle the translated packet. The process continues until the packet reaches the proper destination. Because the address translation happens on a hopby-hop basis, the route repairing mechanism provided by AODV naturally updates the NAMT tables (i.e., entries in the NAMT tables are removed or added depending on the new configuration).
In this section we compare standard AODV (draft 10) to our AODV-RA using the GloMoSim [13] simulator. We use simulation scenarios meant only to illustrate the benefits of relative addressing. In the simulations, we use Tiny IP (TIP), a shorter version of IP designed merely to show the impact of shorter headers and smaller host addresses. X YNZ was adapted to perform the corresponding multiplexing to handle both IP and TIP. IP packets are given priority over TIP packets in order to prioritize control packets. The TIP header is only bytes long, and it is comprised of [ fields: protocol version (2 bits), transport protocol (6 bits), total packet length (1 byte), Time to Live (1 byte), source address (4 bits), and destination address (4 bits). Sources generate continuous bit rate (CBR) traffic. A reduction on packet header is expected to have significant impact only for small payloads. Therefore, we have chosen to use only 32-byte data packets, considering that we are not willing to evaluate the performance of AODV but rather get an idea about the overall impact of reducing the header overhead for data packets. For the same reason, we do not consider mobility for the simulations run in these experiments. We evaluate two important performance metrics: packet delivery fraction, the ratio of data packets delivered to the destinations to those generated by the CBR sources; and average end-to-end delay of data packets, which includes all possible waiting time since the moment a packet is sent by the source until the packet is received by the destination. A. 20-Node Scenario In the first experiment we consider a network of 20 nodes. Results are presented for 5 and 10 sources. The nodes are uniformly distributed over X Z Z
; meter field. The source-destination a pairs are chosen randomly amongZthe Znodes
Z ]\W^`_ in the network. TheZ bandwidth is set to for 5 Z Z \W^`_ sources and a for 10 sources. The radiorange is set to [ , and the total simulation duration is set to b seconds. The data_ packet d Z inter_ departure time is varied from c to .
We repeat this process 10 times keeping the number of sources constant, and each simulation is run 3 times with different seed values. Figure 3 presents the results obtained in this experiment.
Average end-to-end delay (s)
2.2 2 TIP IP
1.8 1.6 1.4 1.2 1 0.8 0.6 0.4 0.2 0 20
25
30 Number of sources
35
40
35
40
(a)
1 TIP IP
0.9 Packet delivery fraction
For the scenario with 5 sources we randomly select 20 different sets of 5 source-destination pairs for each value of data packet rate, and each simulation is run c times with different seed values. For the scenario with 10 sources we randomly select 10 different sets of 10 source-destination pairs for each value of data packet rate, and each simulation is run c times with different seed values. Figure 2 presents the results of these simulations. When we have 10 sources (Figure 2a and Zb) TIP_ improves the end-to-end delay by about most of the time compared to IP, and by at least
Z
_ c for 5_ sources a and_ inter-departure time between c and . At the same time the packet delivery fraction is improved by almost ce most of the time for 10 sources, and by the same amount for 5_ sources a and_ inter-departure time between c and . As the inter-departure time increases less packets are generated and consequently most of the packets are successfully delivered to the destination. Hence, we can see that the difference between TIP and IP reduces to a point where the savings are meaningless. Smaller packets require less time to be transmitted, consequently the network gets less congested and more packets are successfully transmitted. For both 5 and 10 sources we observe a large end-to-end delay when packets are generated at a rate that the network cannot handle (Figure 2a and c). The network gets congested and most of the packets are dropped. But even having half the available bandwidth in the 5 source scenario compared to the 10 source scenario, we observe that
e more packets are successfully delivered when there is only 5 sources _ aand
the _ inter-departure time is between c and (Figure 2d).
0.8 0.7 0.6 0.5 0.4 0.3 0.2 20
25
30 Number of sources
(b) Fig. 3. 100 nodes, varying the number of sources: (a) endto-end delay; (b) packet delivery ratio
As expected, for a small number of sources (Figure 3a and b) we do not see any improvement by using TIP. But as the number of sources increases, the Z end-to-end delay reduces significantly _ for 30 sources, situation in which by about
we also observe an improvement of almost e in the packet delivery ratio. For larger number of sources the savings reduce as the network gets more and more congested. For nodes the packet delivery ratio is almost the same for ZTIP
_ and IP, but the end-to-end delay is still about lower for TIP packets.
B. 100-Node Scenario The second set of experiments concerns a network Z with Z 100 nodes uniformly distributed over a cZ Z; Z f\Wc ^`_ meter field. The bandwidth a is set to , the radio-range is set to Z [g , and seconds. the total simulation duration is set to We vary the number of sources from 20 to 50 with_ increments Zof 5. Sources generate packets h (packets of bytes). Source-destination pairs are randomly chosen among the nodes in the network.
IV. C ONCLUSION The construction of overlay networks over wireless IP networks is feasible; nevertheless, it requires a novel architecture to fully support the dynamic incorporation of new protocols into the network. Given that IP is widely deployed, IP is used as the common signaling plane to instantiate new protocols on nodes. A NAT approach is applied to solve the problem of mapping global IP addresses
3 2.5 2 1.5 1
4
0.9
3.5
0.85 0.8 0.75
TIP IP
0.7 0.65 0.6 0.55
0.5 0
0.5 50
55
60
65 70 75 80 85 Inter-departure time (ms)
90
95 100
(a) 20 nodes, 10 sources: end-to-end delay
1
TIP IP
0.95 Packet delivery fraction
3.5
0.95 Average end-to-end delay (s)
TIP IP
4
Packet delivery fraction
Average end-to-end delay (s)
5 4.5
3 2.5 2 1.5 1
55
60
65 70 75 80 85 90 Inter-departure time (ms)
95 100
(b) 20 nodes, 10 sources: delivery ratio
TIP IP
0.8 0.75 0.7
0.5 0
50
0.9 0.85
0.65 50
55
60
65 70 75 80 85 Inter-departure time (ms)
90
95 100
(c) 20 nodes, 5 sources: end-to-end delay
50
55
60
65 70 75 80 85 90 Inter-departure time (ms)
95 100
(d) 20 nodes, 5 sources: delivery ratio
Fig. 2. Performance comparison for a network with 20 nodes varying the number of CBR sources: (a,b) presents the end-to-end delay and packet delivery ratio for 10 sources; (c,d): presents the end-to-end delay and packet delivery ratio for 5 sources
to the identifiers used in the virtual network. We have extended AODV to support the address mapping mechanism. The solution is scalable, and requires only minor modifications to the standard AODV or similar on-demand routing protocols for ad hoc wireless networks. Our preliminary analysis by simulation shows that a customized network protocol (e.g., Tiny IP) can reduce considerably the end-to-end delay and increase the packet delivery ratio. We have shown that the performance improvement strictly depends on scenarios characterized by low bandwidth and traffic mostly composed of small packets, both of which are expected in ad hoc networks of sensors. R EFERENCES [1] V. Cerf, “The catenet model for internetworking,” Defense Advanced Research Projects Agency, Information Processing Techniques Office, IEN 48, 1978. [2] V. Fuller, T. Li, J. Yu, and K. Varadhan, “Rfc1519: Classless inter-domain routing: an address assignment and aggregation strategy,” september 1993. [3] Y. Rekhter et.al, “Rfc1918: Address allocation for private internets,” february 1996. [4] Shree Murthy and J. J. Garcia-Luna-Aceves, “A routing protocol for packet radio networks,” in Mobile Computing and Networking, 1995, pp. 86–95. [5] Charles E. Perkins and Pravin Bhagwat, “Dsdv routing over a multihop wireless network of mobile computers,” in Ad hoc networking, pp. 53–74. Addison-Wesley Longman Publishing Co., Inc., 2001. [6] David B Johnson and David A Maltz, “Dynamic source routing in ad hoc wireless networks,” in Mobile Computing, Imielinski and Korth, Eds., vol. 353. Kluwer Academic Publishers, 1996. [7] C. Perkins, “Ad-hoc on-demand distance vector routing,” in Second IEEE Workshop on Mobile Computing Systems and Applications, 1999.
[8] Z. Haas, “A new routing protocol for the reconfigurable wireless network,” in Proc. of the IEEE Int. Conf. on Universal Personal Communications, october 1997. [9] David Andersen, Hari Balakrishnan, Frans Kaashoek, and Robert Morris, “Resilient overlay networks,” in Proceedings of the 18th symposium on Proceedings of the 18th ACM symposium on operating systems principles. 2001, pp. 131–145, ACM Press. [10] Hans Eriksson, “Mbone: the multicast backbone,” Communications of the ACM, vol. 37, no. 8, pp. 54–60, 1994. [11] Ivano Guardini, Paolo Fasano, and Guglielmo Girardi, “Ipv6 operational experience within the 6bone,” in Proc. Internet Society (INET), july 2000. [12] Joe Touch, “Dynamic internet overlay deployment and management using the x-bone,” Computer Networks, vol. 36, july 2001. [13] Lokesh Bajaj, Mineo Takai, Rajat Ahuja, Ken Tang, Rajive Bagrodia, and Mario Gerla, “Glomosim: A scalable network simulation environment,” 1999.
