EK-DYMOv6: Implementation of DYMO with

PacketBB Conformance in IPv6 Environment

Sutaek Oh #1 , Dongkyun Kim #2 , Hong-Jong Jeong #3
#
Dept. of Computer Engineering, Kyungpook National University
1370 Sankyuk-dong, Buk-gu, Daegu 702-701, Korea
1
stoh@monet.knu.ac.kr
2
dongkyun@knu.ac.kr
3
hjjeong@monet.knu.ac.kr

Abstract— In this paper we present our real-world DYMO
implementation, called EK-DYMOv6. EK-DYMOv6 is the first
DYMO implementation trial with two features: (a) conforming to
recent DYMO (DYMO-05) and PacketBB (PacketBB-01) drafts,
and (b) running on the Linux in IPv6 environment. EK-DYMOv6
was implemented with two parts: (a) a kernel module with Net-
filter hooks and (b) a user-space routing daemon. We introduce
the implementation detail, especially in a point of view of routing
table location and PacketBB parser, and analyze the performance
of our implementation through real test-bed experiments.
packet size with path accumulation enabled.
The rest of this paper is organized as follows: Section II
introduces the basics of DYMO and PacketBB. In Section
III, we survey routing protocol implementation techniques and
existing DYMO implementations. Details of our EK-DYMOv6
implementation is described in Section IV. Section V shows
the experimental results from our real test-bed. Finally, Sec-
tion VI closes this paper.

I. I NTRODUCTION II. BACKGROUND

Mobile ad hoc networks (MANETs) are autonomous multi-
hop wireless networks consisting of mobile nodes without
any existing infrastructure, where each node acts as a router.
Since the efficient routing protocols in the MANETs are
essential, the Internet Engineering Task Force (IETF) MANET
working group [1] has attempted to make standards for the
routing protocols. The Dynamic MANET On-demand routing
(DYMO) [4] protocol, a direct descendant of AODV [2], has
attracted much attention in standardization progress as a new
standard of a reactive routing protocol.
Hence, we believe that a real-world implementation plays
an important role in standardization to validate the operation
of a protocol and acquire new suggestions from implementer.
However, there are only a few real-world DYMO implemen-
tations, as compared to other routing protocols. Most of all,
no existing real-world implementation runs on IPv6 environ-
ment and conforms to generalized MANET packet/message
format [3] (PacketBB), which is recently applied to DYMO.
It motivates us to implement our DYMO protocol (ETRI-
KNU DYMO implementation in IPv6 environment, called
EK-DYMOv6) with the conformance to the recent draft and
PacketBB, particularly in IPv6 environment.
Main contributions presented in this paper are as follows:
• We provide the implementation model of a PacketBB
parser for DYMO.
• We discuss the efficiency of implementation alternatives,
depending on the location of routing table in the ap-
proaches using both kernel-module and user-space rout-
ing daemon, and verify them through experiments.
• We analyze the impact of PacketBB on DYMO with
respect to parsing overhead and a variation of control
A. DYMO Protocol Overview
MANET routing protocols can be classified into two cat-
egories: (a) proactive and (b) reactive. Reactive routing pro-
tocols initiate route discovery upon demand, unlike proactive
routing protocols with periodic updates of routing information.
The basic operation of DYMO, one of reactive routing proto-
cols, is similar to that of AODV. DYMO works as follows:
When a node has a packet to send to a destination, it
initiates route discovery process and starts to flood a Route
Request (RREQ) message. Each intermediate node which
receives the RREQ is able to set up a reverse path to the
RREQ originator. When the RREQ reaches its destination,
the destination responds with a Route Reply (RREP) unicast
toward the RREQ originator. The RREP is propagated through
the reverse path and each intermediate node on that path can
set up a forward path to the destination. Eventually the RREQ
originator receives the RREP and furthermore a bidirectional
path between the source (RREQ originator) and the destination
is established.
All nodes should monitor their active links in order to react
to any change in topology. When a node detects a broken
link, it sends a Route Error (RERR) broadcast to inform nodes
utilizing the broken link that the path is no longer valid.
For simplicity, DYMO eliminates the complex functions of
AODV, such as local repair, which do not give significant
improvement. Especially, DYMO is strongly characterized
by a path accumulation capability. When a node forwards
RREQ or RREP, it appends its address to the control message.
Hence, this enables other nodes which will receive the control
message to know the path toward the forwarding node. The
path accumulation may reduce future route discovery, but may

1-4244-0979-9/07/$25.00 © 2007 IEEE 627 IEEE ISWCS 2007

Authorized licensed use limited to: Pondicherry University-Ananda Rangapillai Library. Downloaded on August 13,2010 at 01:04:18 UTC from IEEE Xplore. Restrictions apply.
 TABLE I
1) Full Kernel-Space Code: In this design, program code
D IFFERENCE B ETWEEN AODV AND DYMO
is all located in the kernel-space. This design can react to
Feature AODV DYMO network events very quickly, so the processing delay can be
Local Repair Yes No minimized. Especially, the forwarding decision is made in the
Precursor RERR is unicasted No. RERR is kernel-space. However, the kernel-space code is difficult to
List along the precursor list broadcasted. write and maintain.
Intermediate Default Optional. Added
Node RREP since 7th draft 2) Kernel Module with Netfilter Hooks and User-Space
Path No Optional Routing Daemon: In this design, a minimum amount of code
Accumulation needed is located in the kernel-space as a kind of kernel
PacketBB No Yes module, while others are located in the user-space. The kernel
Conformance module triggers routing events by sniffing on-going packets
using Netfilter [11]. When the user-space routing daemon
receives these triggers through inter-process communication
cause packet bloat problem. Table I summaries the difference (IPC), it starts appropriate routing protocol operations, e.g.
between DYMO and AODV. route discovery. This design is highly flexible and easy to
write, maintain, and understand. The major weakness is the
B. PacketBB Overview
overhead caused by IPC, but it is usually negligible compared
Control messages in MANET routing protocols usually to overall network delay. Our EK-DYMOv6 takes this design.
include common elements, such as originator address, destina-
tion address and other attributes associated with them. Hence, B. Existing Implementations
PacketBB specifies a common packet framework for MANET Since the Linux is an open source operating system and
protocols. Recently, all MANET protocols are required to con- can be modified on various platforms, it is the most suitable
form to PacketBB. DYMO has also conformed to PacketBB platform to develop routing protocols. Hence, most of imple-
from its 4th draft (DYMO-04). Although the PacketBB is mentations, including our EK-DYMOv6, run on the Linux.
highly flexible and extensible, the parsing logic for PacketBB 1) NIST-DYMO: NIST-DYMO [6] is developed at the Na-
is difficult to implement. Furthermore, it is not suitable for tional Institute of Standard and Technology (NIST) and is
small low-energy devices whose maximum allowable packet written in C. It uses the full kernel-space code design which is
size is small. discussed in Section III-A. The main characteristics of NIST-
Figure 1 shows an example of DYMO IPv4 RREQ packet DYMO are as follows:
which conforms to PacketBB-01 draft. Note that all numbers • It runs on Linux (both 2.4.x and 2.6.x) and in IPv4
are in binary format. Refer to [3] and [4] for details. environment.
• It has been tested on ARM platforms.
0 8 16 24 32
<message> • It supports a gatewaying capability to the internet.
<msg-header> <msg-header-info>
<msg-type> = RREQ <msg-semantics>=0001 <msg-size> = 10111 <hop-limit> NIST-DYMO conforms to DYMO-03 draft, thus it does not
use PacketBB yet.
<tlv-block>: message header tlv block
<tlv-length> = 0
2) DYMOUM: DYMOUM [7] is developed at the Uni-
versity of Murcia, Spain. It consists of a kernel module
<addr-block>
with Netfilter hooks and a user-space routing daemon, as
<num-addr> = 10 1 <head-length> = 10 <head>
<mid> = Target.Tail <mid> = Orig.Tail described in Section III-A. Since it is inspired on AODV-
UU [8] implementation, it runs on both the ns2 [10] and the
<tlv-block>: address block tlv block <tlv>
<tlv-length> = 111 <tlv-type>=SeqNum <tlv-semantics>=1000
Linux. It uses IPv4 as its address system. The latest version
<index-start> = 1 <index-stop> = 1 <length> = 10 <value> = of DYMOUM conforms to DYMO-05 draft, but it does not
Orig.SeqNum make use of PacketBB.
Fig. 1. Example of an IPv4 RREQ packet which conforms to PacketBB-01 IV. EK-DYMOV 6 D ESIGN AND I MPLEMENTATION
IPv6 has salient features such as a large address space,
stateless auto-configuration and simplified header formats.
III. R ELATED W ORKS
Hence, it is believed that protocols for MANETs can be
In this section, we introduce two designs of state-of-the- easily implemented in IPv6 environment. It motivated us to
art routing protocols and two existing real-world DYMO implement our EK-DYMOv6 in IPv6 environment.
implementations.
A. Overall Structure
A. Design Choices Figure 2 shows the overall structure of our implementation
When implementing on-demand reactive routing protocols and its relationship with the Linux. As mentioned before, we
on the Linux, there are several design alternatives. We present take the well-known design using the kernel module with
two well-known approaches of them. (Refer to [5] for details). Netfilter and user-space routing daemon.

628
Authorized licensed use limited to: Pondicherry University-Ananda Rangapillai Library. Downloaded on August 13,2010 at 01:04:18 UTC from IEEE Xplore. Restrictions apply.
 Every packet created in the local application is intercepted
by Netfilter before forwarding decision of the Linux kernel
is made and the packet is passed to our kernel module. And
then, our kernel module makes a forwarding decision instead
of the Linux kernel. If a route to destination of the intercepted
packet is known, the Linux kernel will forward the packet. In
contrast, if the route is unknown, the kernel module queues
the packet and sends a route discovery request to the user-
space routing daemon through netlink (one of inter-process
communication mechanism that is supported in the Linux).
Upon receiving the route discovery request, the user-space
routing daemon performs a route discovery process. When an
appropriate RREP is received, the routing daemon updates the
Linux kernel routing table and notifies the kernel module of
it. Finally the kernel module is informed that the route has
been established and the queued packet can be passed to the
normal packet flow.
Network Interface
Our Implementation
User-space Routing
Daemon
Netlink Kernel Module
Routing Table Destination List
Packet Flow
Netfilter
DYMO control message
over UDP
Alter routing table
using ioctl()
Linux
Kernel
Routing Table
Fig. 2. The basic structure of EK-DYMOv6
B. Location of Routing Table
One of the well-known implementation choices in the
approaches using both kernel module and user-space routing
daemon is the location of routing table, which has great impact
on efficiency. Consider that a routing table is located only in
the user-space routing daemon. To decide whether to forward
or not, the kernel module needs to look up the routing table. In
this case, the kernel module should send a look-up request to
the user-space routing daemon through IPC, which makes the
forwarding process slow. It has an advantage of minimizing
the size of kernel module. In contrast, when a routing table is
located only in the kernel module, the size of kernel module
may be large since it should be capable of routing table
management. Obviously, this does not fulfill our design goal
which pursues for a small-size kernel module.
One promising technique, which our EK-DYMOv6 takes
and has been first introduced in [8], is to let both kernel
module and user-space routing daemon have their own routing
table. However, both tables do not need to have whole routing
entries. For example, the kernel module routing table maintains
a list of valid destinations. Moreover, the kernel module does
629
Authorized licensed use limited to: Pondicherry University-Ananda Rangapillai Library. Downloaded on August 13,2010 at 01:04:18 UTC from IEEE Xplore. Restrictions apply.
not require additional information such as hop count and
timeout values. It is enough that the validation check of
the destination is performed at the kernel module during the
forwarding decision process. In contrast, the user-space routing
table should have whole entries since the user-space routing
daemon performs all DYMO operations.
This technique also has its own weakness: the overhead for
synchronizing these two routing tables. When a routing table
entry is updated, the user-space routing daemon must inform
the kernel module of it. However, since it does not occur in
the forwarding decision process, the forwarding delay is not
affected. We evaluate this issue in Section V-D.
C. PacketBB Parser
Due to the complexity of PacketBB, it is important that an
efficient parser/generator is used. Parser/generator produces
overhead dramatically when path accumulation is enabled;
address blocks and their associated type-length-value (tlv)
blocks are necessary to be reconstructed.
The first PacketBB parser/generator was implemented by
[9] as a part of protean protocol prototyping library (protolib).
This implementation introduced an efficient general-purpose
PacketBB parser/generator. However, we use a different ap-
proach, which is more specialized for DYMO to guarantee
efficiency. Our approach is based on the observation that only
the address blocks and their associated tlv blocks change fre-
quently in DYMO. EK-DYMOv6 PacketBB parser/generator
works as follows:
When parsing a packet, our parser builds a simple parse
tree only for address and tlv blocks, rather than all elements
of PacketBB. If the address and tlv blocks are needed to
change, it updates the parse tree. Accordingly, the packet also
is updated to contain the modified address and tlv blocks,
which can be obtained from the parse tree. In contrast, a naive
parsing and modification approach is taken for the other parts
because of simplicity of their structure.
In contrast, when generating a new packet, the generator
first prepares some pre-defined packet, rather than creating it
naively. Subsequently, it puts the required information such as
originator address, target address and their sequence number
into the packet. In Section V-E, we evaluate the efficiency of
our parser by the comparison with protolib.
V. E XPERIMENTAL R ESULTS
In this section, we investigate the performance of our EK-
DYMOv6 implementation through real-world experiments.
A. Experimental Setup
We set up a 3-hop chain topology with four laptops; all
laptops have 802.11g compliant wireless adaptor and they
act on ad-hoc mode with 54Mbps bit-rate. Table II shows
the details of each laptop. In order to form a 3-hop chain
network in our laboratory, we use iptables [11] which provides
MAC layer packet filtering mechanism. To measure time in
microsecond precision, we use time stamp counter (TSC timer)
with dynamic voltage management turned off.
 TABLE II TABLE III
D ETAILS OF O UR L APTOPS P ROCESSING D ELAY OF E ACH M ODULE D URING ROUTE D ISCOVERY

Laptop No. Spec. (CPU, RAM, Wireless Adaptor and OS) Factor Delay (µs)
Intel Pentium T2400 (1.83GHz) with 1GB RAM Kernel Module 13
A Inel Pro/Wireless 3945ABG adaptor IPC (Kernel Module to User-space) 14.4
Linux Kernel 2.6.20-15 IPC (User-space to Kernel Module) 3.8
Intel Pentium M 1.5GHz with 256MB RAM User-space Daemon 1339
B Inel Pro/Wireless 2200BG adaptor
Linux Kernel 2.6.12-10 TABLE IV
Intel Pentium M 1.73GHz with 512MB RAM F ORWARDING D ELAY W. R . T ROUTING TABLE L OCATION
C Inel Pro/Wireless 2200BG adaptor
Linux Kernel 2.6.20-15 Routing Table Location Delay (µs)
Intel Pentium M 1.73GHz with 1GB RAM Only in User-space 24.99
D Ralink 802.11b/g wireless adaptor Kernel Module + User-space 9.89
Linux Kernel 2.6.20-15
TABLE V
RREQ G ENERATION AND PARSING D ELAY OF EK-DYMOV 6 AND
B. Route Discovery Delay P ROTOLIB
First, we measured time that a source takes to discover a
EK-DYMOv6 Protolib
route and compared it with ping round trip time (ping-RTT). RREQ Generation (µs) 3.28 12.34
We plotted graphs with averages from ten runs. RREQ Parsing (µs) 8.54 11.92
As shown in Figure 3, route discovery time is larger than
ping-RTT because every intermediate node spends time in
processing control messages, while ping is just forwarded to slower than the message delivery time from user-space to
next hop. When measuring the ratio of route discovery delay kernel module. User-space routing daemon requires relatively
to ping-RTT, we observe that as the hop count increases, the larger processing time than kernel module and IPC, because
ratio decreases. This implies that the kernel module of our EK- it performs most of DYMO and socket operations.
DYMOv6 makes a fast forwarding decision and the user-space
routing daemon efficiently processes the tasks needed during D. Impact of Routing Table Location
route discovery, such as packet parsing and routing table To examine the impact of routing table location, we first
operations. Hence, the processing delay from a route discovery measured the delay that it takes to execute packet forwarding
process is negligible when compared to overall network delay. process with two routing tables after route discovery. Then,
we modified our implementation so that only the user-space
45 routing daemon maintains a routing table. Table IV shows the
ping-RTT
40 Route Discovery result with two different routing table locations. The delay
of the single routing table approach requires two kinds of
35
IPC delay (one is taken by route lookup request from kernel
30 module to user-space, and the one by route lookup reply from
Time (ms)

25 user-space to kernel module), a routing table lookup delay at

20 user-space routing daemon, and a queuing delay at the kernel
module. Thus, two routing tables approach is much faster
15
than the single routing table approach. Since a forwarding
10 decision is made for all packets, this significantly improves
5 the efficiency of the routing protocol.
0 Compared with the result in [5], our result shows that the
1 2 3 two routing table approach is as efficient as full kernel-space
Number of Hops code approach.
Fig. 3. Route discovery time vs. ping round trip time
E. Efficiency of PacketBB Parser
To verify the efficiency of our PacketBB parser which is
C. Processing Delay of Each Module specialized for DYMO, we compared RREQ generation and
Next, we measured the delay that each module of our parsing times of our PacketBB parser with those of protolib’s
EK-DYMOv6 takes during route discovery. (see Table III) PacketBB parser. First we manually created an RREQ and
Since our user-space routing daemon receives the inter-process measured the time. Next we measured the time taken during
message using socket calls, while kernel module receives it parsing process for the created RREQ. The result is shown in
directly from the Linux kernel, the delivery time of inter- Table V. Due to the same reason mentioned in Section IV-C,
process message from kernel module to user-space is much our PacketBB parser has low delay as compared with protolib.

630
Authorized licensed use limited to: Pondicherry University-Ananda Rangapillai Library. Downloaded on August 13,2010 at 01:04:18 UTC from IEEE Xplore. Restrictions apply.
 F. Variation of RREQ Message Size with Path Accumulation
C1
When the path accumulation is enabled, the size of control C2
88 C3
messages such as RREQ and RREP increases linearly with the
83
number of hop count. However, if intermediate nodes append

RREQ Message Size

their own tlvs, the size of control message gets unpredictable
due to the indexing mechanism of tlv block. We measured the
variation of RREQ message size with three different scenarios
(denoted by C1, C2, C3 in Figure 4, respectively) in order to
estimate the impact of PacketBB on DYMO when the path
accumulation is enabled.
In C1, all nodes append their address and sequence number
tlv only. In C2, they also append their hop count tlv. Finally, in
C3, only the first and third hop nodes append their hop count
tlv. Note that 0 hop means the initial size of RREQ (which is
43 bytes long).
As mentioned above, the size of RREQ increases linearly
in C1. This also applies to C2 after the first hop, since only
the first hop node appends a new hop count tlv block and
the second and the third node can use it rather than create a
new one. In C3, however, the first hop node creates a new hop
count tlv block, but the second node does not use it. Therefore,
the third node cannot use the hop count tlv block since the
address block indexing mechanism for tlv blocks requires the
index to be sequential. Thus, the third node appends a new
hop count tlv block. Hence, the size of RREQ non-linearly
increases. This gets even worse when various tlvs are used.
We can address this problem by reordering addresses. If the
third node puts its address in front of the second node, the hop
count tlv block created at the first node can be used. In this
case, the size of RREQ will be reduced by 5 bytes. (note that
we didn’t implement address reordering yet and this value is
theoretically calculated.)
VI. C ONCLUSIONS
To the best of our knowledge, EK-DYMOv6 is the first trial
of DYMO implementation with two features: (a) conforming
to PacketBB and (b) running in IPv6 environment. Through
real test-bed experiments, we observed that our implementa-
tion had low delay overhead for forwarding, and generated
or parsed PacketBB packets efficiently. In the future, we
are planning to perform an inter-operability test with other
implementations.
78
73
68
63
58
53
48
43
0 1 2 3
Number of Hops
Fig. 4. A variation of the RREQ message size
ACKNOWLEDGMENT
This work is supported by the Electronics & Telecommuni-
cation Research Institute (ETRI) and Brain Korea 21 (BK21)
project, Korea.
R EFERENCES
[1] The IETF MANET working group charter website. [Online]. Available:
http://www.ietf.org/html.charters/manet-charter.html
[2] Charles E. Perkins, Elizabeth M. Belding-Royer, and Samir R. Das,
“Ad hoc On-demand Distance Vector (AODV) routing,” RFC 3561, July,
2003.
[3] Thomas H. Clausen, Christopher M. Dearlove, Justin W. Dean, and
Cedric Adjih, “Generalized MANET Packet/Message Format,” draft-ietf-
manet-packetbb-01, Internet Draft, Feb., 2006.
[4] Ian D. Chakeres, and Charles E. Perkins, “Dynamic MANET On-
demand (DYMO) Routing,” draft-ietf-manet-dymo-05, Internet Draft,
June, 2006.
[5] Ian D. Chakeres, and Elizabeth M. Belding-Royer, “AODV Routing
Implementation Design and Performance Evaluation,” International
Journal of Wireless and Mobile Computing (IJWMC), Issue 2/3, 2005.
[6] Luke Klien-Bernt. (2005) NIST-DYMO project site. [Online]. Available:
http://sourceforge.net/projects/nist-dymo/
[7] Francisco J. Ros. (2006) DYMOUM project site. [Online]. Available:
http://masimum.dif.um.es/?Software:DYMOUM/
[8] Erik Nordström. (2007) AODV-UU project site. [Online]. Available:
http://core.it.uu.se/core/index.php/AODV-UU/
[9] (2007) Naval Research Laboratory, Networks and Com-
munication Systems Branch website. [Online]. Available:
http://cs.itd.nrl.navy.mil/products/
[10] VINT Group. “UCB/LBNL/VINT The Network Simulator ns (ver-
sion2),” [Online]. Available: http://www.isi.edu/nsnam/ns/
[11] Harald Welte, Jozsef Kadlecsik, Martin Josefsson, Patrick McHardy
and Yasuyuki Kozakai. The netfilter/iptables project website. [Online].
Available: http://www.netfilter.org/

631
Authorized licensed use limited to: Pondicherry University-Ananda Rangapillai Library. Downloaded on August 13,2010 at 01:04:18 UTC from IEEE Xplore. Restrictions apply.