written_report.tex

AODV version of Uppsala University

To be able to build the project and integrate it with the NS-Miracle framework, we created project specific Makefiles and added support for our project into NS-Miracle specific Makefiles. We then tried to build the project and fix build errors.

\subsubsection{VERIFY FUNCTIONALITY}
To verify functionality of the ported code we wrote test cases. We moved from basic tests to more advanced. If the behavior did not meet our expectations we changed or fixed the concerned code parts.

\subsection{CODE CHANGES}
In this section we present a list of changes that was needed in the original code to complete the port. The list contains both small changes in the API and big conceptual changes.

\subsubsection{AGENT TO MODULE}
The most basic, and possible the most obvious change is the conversion from a NS-2 agent (section \ref{nsagent}) to a NS-Miracle module (section \ref{miraclemodule}). As the concept of agents does not exist in NS-Miracle we had to convert the AODV-UU routing agent into one of the basic entities that exist in NS-Miracle. Those entities are \texttt{PlugIn} (section \ref{miracleplugin}), \texttt{Module} (section \ref{miraclemodule}) and \texttt{ChannelModule} (section \ref{miraclemodule}).

The original AODV-UU code (section \ref{aodvuudesc}) use Linux built in routing capability at the network layer and runs the AODV logic as a separate daemon. Mapping this structure to NS-Miracle would result in AODV-UU as a \texttt{PlugIn} communicating with an existing routing module. However, NS-Miracle does not include a routing module with enough capabilities to support this kind of routing. The options left is to extend the existing routing module, or simply make the whole AODV-UU package as a \texttt{Module}. The latter one needs less changes, and since the available time for this project was quite limited, we chose this approach.

\subsubsection{PACKET TYPES AND HEADERS}
In NS-2 packet types and packet headers are statically declared in NS-2 header files. Since NS-Miracle links dynamically, new packet types and headers can also be dynamically loaded and are therefore declared together with the modules using them.

AODV-UU adds one new packet type (\texttt{PT\_AODVUU}), and one new packet header (\texttt{PacketHeader / AODVUU}). Those declarations were extracted from the patch supplied in the AODV-UU package and added to the source code of the new AODV-UU module.

\subsubsection{PACKET HANDLING}
In NS-2 every object has one or more pointers pointing to targets up and down the stack (e.g. where to send packets). In NS-Miracle this is abstracted with the \texttt{SAP}s (section \ref{miraclesap}) and the methods \texttt{void sendUp(Packet* p)} and \texttt{void sendDown(Packet* p)}. We had to change every occurrence of \texttt{target\_->recv(packet)} with the corresponding NS-Miracle method.

The \texttt{recv()}-method is similar in NS-2 and NS-Miracle although there is some difference in the method signature. NS-Miracle does not make use of the \textit{function callback pointer} specified as the second argument to \texttt{recv()} in NS-2. The default \texttt{recv()}-method (the one which needs to be re-implemented in every sub-class of \texttt{Module}) in NS-Miracle is therefore \texttt{void recv(Packet*)} as opposite to \texttt{void recv(Packet*, Handler*)} in NS-2.

\subsubsection{ADD MULTIPLE INTERFACE}
\label{codechangesmultiinterface}
In the NS-2 port of AODV-UU (section \ref{aodvuuns}) the support for multiple interfaces was excluded because it was not directly applicable in NS-2. In NS-Miracle the support for multiple interfaces is better, and therefore it is desirable to re-implement the multiple interface feature in the port of AODV-UU for NS-Miracle.

To be able to determine which IP-interfaces that shall be part of the AODV routing, new functionality is needed. This can be solved using cross layer messages (section \ref{clmessages}), where AODV-UU poll its underlying IP-interface modules, or by explicit define participating interfaces in the simulation configuration (OTcl script). We chose the latter approach since no cross layer messages are defined for the existing IP-interface class and because of difficulties to differentiate between Internet gateway interfaces and regular interfaces. In code this means that we added a new TCL command \texttt{add-if}.

AODV-UU also modifies the interface queue which is placed on top of a MAC-module in the stack. AODV-UU can move packets from one queue to another if a specific route change interface, or remove packets if a route invalidates. Since no queue-module is available for NS-Miracle the queues in NS-2 are used for NS-Miracle as well. This left us with no other possibility than to explicit add knowledge about queues from the simulation configuration, which is implemented with the command \texttt{if-queue}.

\subsubsection{MODIFY INTERNET GATEWAY}
The implementation of \textit{Internet gateway mode} in AODV-UU for NS-2 relies on the address classifier (section \ref{nsnodes}) to pass packets to an external wired interface. In NS-Miracle this can be much more flexible since it is possible to use multiple interfaces. By defining one underlying IP-interface as the gateway interface this is easy accomplished. We added a new TCL command, \texttt{add-gw-if}, that adds an Internet gateway interface, just as \texttt{add-if} did with a regular ad hoc-interface.

Except for the above conceptual changes we also had to add code that set the \textit{source address} and \textit{ttl} on data-packets that is to be encapsulated (section \ref{aodvuudesc}). In the NS-2 version of AODV-UU this is done in \texttt{Agent}-specific code.

\section{TESTING}
To be able to verify the functionality of the ported code, we have written different test scenarios and performed simulations. The more advanced test scenario consists of several wireless nodes (single and multihomed) and one gateway node. This section will describe the mentioned test scenario in detail.

\subsection{INTRODUCTION}
The test scenario simulates a wireless ad-hoc network (figure \ref{testcasefig}) with 802.11 nodes and one wired external node. All of the wireless nodes have AODV routing capabilities. For details, please refer to the Tcl script \textit{aodv-uu\_mesh\_plus\_wired.tcl} which can be found in the directory \textit{samples} in the source code. The simulation environment includes the following entities:
\begin{itemize}
 \item A shared backbone network
 \item Three access networks (CH 1, CH 11 and CH 6)
 \item Three multihomed nodes (B\_1, B\_2 and B\_3) that connect the access and backbone networks
 \item Four singlehomed (1\_1, 1\_2, 11\_1, 6\_1) nodes connected to different access networks
 \item One external node (node B\_3 is configured as an Internet gateway)
\end{itemize}
\begin{figure}
\includegraphics[scale=0.3,keepaspectratio=true]{testcase.eps}
\caption{Ad-hoc test scenario\label{testcase}}
\label{testcasefig}
\end{figure}
\subsection{SCENARIO}
Given the previously described simulation setup, this scenario simulates a ping request from node 11\_1 to node 6\_1. Node 6\_1 answers with a ping reply. No routes are established prior to the ping request. The following sequence diagram (figure \ref{scenariofig}) shows the AODV control traffic that are needed to establish the required routes. The ping request that triggers the route discovery is also shown in the diagram.
\begin{figure}
\includegraphics[scale=0.3,keepaspectratio=true]{scenario1.eps}
\caption{Ping test scenario showing AODV control traffic\label{scenario}}
\label{scenariofig}
\end{figure}
\subsection{SOME NOTES}
The sequence diagram shown in (figure \ref{scenariofig}) is created from AODV-UU debug information and the simulation trace file. We feel that the AODV routing traffic that was generated during the simulation follows the expected behavior. We have also done tests where node 1\_1 ping the external node (and vice versa).

\section{OPEN ISSUES}
Although the porting process was overall successful, there is still some issues that need to be solved before the AODV-UU module for NS-Miracle ``just works''. In this section those issues are listed and described. In some cases a proposed solution is also provided.

\subsection{INTERFACE QUEUE NOT RECOGNIZING AODV-UU PACKETS}
Since NS-Miracle does not include any interface queue modules, the interface queues from NS-2 are still used. At least one of the queues in NS-2 \\(\texttt{Queue/DropTail/PriQueue}) are able to prioritize routing specific packets. The packet types recognized as routing packets by the queue are hard-coded in the source code. AODV-UU for NS-2 comes with a patch that add the packet type \texttt{PT\_AODVUU} to the source code.

Since NS-2 should be totally unaware of NS-Miracle modules it is not an option to distribute this kind of patch together with the AODV-UU module for NS-Miracle. One option is to write new interface queue modules for NS-Miracle, which however force changes in every NS-Miracle module which use the old NS-2 queues.

\subsection{ONLY TESTED FOR 802.11}
The new module is only tested together with the 802.11 modules in NS-Miracle. This is mainly because of the limited time frame of this project. There might be reasonable or unreasonable function assumptions for modules in lower layers that is not fulfilled. One example of such an assumption is described in section \ref{issueRoutingLoops}.

If unreasonable assumptions are made, the code for AODV-UU should be changed.

\subsection{DETECTING ROUTING LOOPS}
\label{issueRoutingLoops}
AODV-UU relies on a hop-counter (\texttt{num\_forwards()}) in the common packet header to detect routing loops. This counter should be increased for every node a packet pass through. The 802.11 MAC module is the only module in NS-Miracle that increments \texttt{num\_forwards()}, and thus the only MAC-module that works correctly with AODV-UU.

The easiest, and probably the most correct solution to this problem is to let AODV-UU keep track of the hop-count independently of other modules, or by detecting routing loops in another way.

\section{FUTURE WORK}
In this section we propose some new features that we think should be implemented in further versions of AODV-UU for NS-Miracle.

\subsection{EXTENDED TRACING}
The tracing functionality for the ported AODV-UU module is quite limited. This functionality can be extended to supply the user with more useful trace logs. TCL commands for printing routing-tables etc. should also be implemented.

\subsection{ADD AP-MODE}
In a real world scenario an AODV-router might work in mixed mode, letting mobile clients without AODV capabilities connect in regular infrastructure mode. This can probably be implemented in AODV-UU by generalize the \textit{Internet gateway} function to act as a gateway for a list of hosts (the AP clients).

\subsection{AUTOMATIC IP-INTERFACE DETECTION}
As stated in ADD MULTIPLE INTERFACE in section \ref{codechangesmultiinterface} underlying interfaces can be detected automatically via cross layer messages. This assumes however that the IP-interface module is able to handle such cross layer messages, which is not the case at the moment. Another problem to solve is how to distinguish between regular interfaces and an Internet gateway interface.

\section{SUMMARY}
This project has resulted in an AODV-UU module for NS-Miracle. We feel that the port was successful, although more tests are needed to verify functionality in different scenarios. Compared to the NS-2 version of AODV-UU we have re-enabled multiple interface support. We have also identified some features that are subject for further implementation.

The project was finished within the given time frame. We hope that our work can be useful in future research projects at Karlstad University.

\bibliography{bibl}

\end{document}