Adding Multiple Interface Support in NS-2

Adding Multiple Interface Support in NS-2
Ram on Ag uero Calvo University of Cantabria ramon@tlmat.unican.es Jes us P erez Campo University of Cantabria jesus@tlmat.unican.es
January, 2007
Copyright (c) 2007 Ram on Ag uero. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.
Acknowledgments
The author would like to thank all the people who have contributed to enhance this document with their comments and suggestions. Ram on Ag uero would like to acknowledge the help provided by Rub en Ans otegui Boada, who compiled all the changes which were needed on the AODV code, and helped to build the corresponding section on the document.
Contents
1 Introduction 1.1 Related Work . . . . . . . . 1.1.1 MITF . . . . . . . . 1.1.2 TENS . . . . . . . . 1.1.3 Hyacinth . . . . . . 1.2 Objective of the Document 1.3 Structure of the Document 1.4 Disclaimer . . . . . . . . . . 8 8 8 9 9 10 10 10 11 11 13 15 15 15 21 33 33 33 34 35 36 36 36 39 39 39 40 57 60 63
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
2 Multiple Interface Model 2.1 Requirements and Working Assumptions . . . . . . . . . . . . . . . . . . . . . 2.2 Multiple Interface Node Model . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Changes on Tcl Code 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Changes on ns-lib.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Changes on ns-mobilenode.tcl . . . . . . . . . . . . . . . . . . . . . . . . . 4 Changes on C++ Code 4.1 Introduction . . . . . . . . . . . . 4.2 Changes on mobilenode.[cc,h] 4.3 Changes on channel.cc . . . . . 4.4 Changes on mac-802 11.cc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Changes on Routing Protocol Code 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Changes on routing agent implementation . . . . . . . . . 5.3 Changes on the Route Table . . . . . . . . . . . . . . . . . 5.4 Illustrative example: AODV . . . . . . . . . . . . . . . . . 5.4.1 Changes in aodv.h . . . . . . . . . . . . . . . . . . 5.4.2 Changes in aodv.cc . . . . . . . . . . . . . . . . . 5.4.3 Changes on the routing table implementation aodv 6 Scenario Script 7 Future Work
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rtable.[cc,h]
CONTENTS
A GNU Free Documentation License
65
List of Figures
2.1 2.2 MobileNode Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modied MobileNode architecture, with multiple interface support . . . . . . . 12 14
Listings
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 4.1 4.2 4.3 4.4 4.5 4.6 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 (ns-lib.tcl) Procedure to change the number of interfaces . . . . . . . . . . (ns-lib.tcl) Procedure to add an interface on a node . . . . . . . . . . . . . (ns-lib.tcl) Procedure to get the number of interfaces . . . . . . . . . . . . (ns-lib.tcl) Procedure to add multiple interfaces as an argument to nodecong label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (ns-lib.tcl) Changes on node-cong procedure . . . . . . . . . . . . . . . . (ns-lib.tcl) Changes on create-wireless-node procedure . . . . . . . . . . . (ns-mobilenode.tcl) Changes on add-target procedure . . . . . . . . . . . . (ns-mobilenode.tcl) Changes on add-target-rtagent procedure . . . . . . . (ns-mobilenode.tcl) Changes on add-interface procedure . . . . . . . . . . . (ns-mobilenode.tcl) MobileNode init procedure . . . . . . . . . . . . . . . . (ns-mobilenode.tcl) MobileNode reset procedure . . . . . . . . . . . . . . . (mobilenode.h) New declaration of MobileNode lists within MobileNode class (mobilenode.h) New getLoc method declaration within MobileNode class . . (mobilenode.cc) getLoc method denition . . . . . . . . . . . . . . . . . . . (channel.cc) Accessing the appropriate MobileNode list . . . . . . . . . . . . (channel.cc) affectedNodes method from the channel class . . . . . . . . . (mac-802 11.cc) Registering the correct MAC receiving interface within the recv method of the Mac802 11 class . . . . . . . . . . . . . . . . . . . . . . . (routingAgent.h) New class members to manage multiple interfaces . . . . . (routingAgent.cc) Changes on command method of the routing agent class . (routingAgent.cc) Sending a broadcast packet . . . . . . . . . . . . . . . . . (routingAgent.cc) Sending a unicast packet . . . . . . . . . . . . . . . . . . (routingAgent.cc) Getting the interface index . . . . . . . . . . . . . . . . . (aodv.h) Declaring the MAX IF constant . . . . . . . . . . . . . . . . . . . . (aodv.h) New members of the AODV class . . . . . . . . . . . . . . . . . . . (aodv.h) New members of the AODV class . . . . . . . . . . . . . . . . . . . (aodv.cc) Changes on the AODV constructor . . . . . . . . . . . . . . . . . . (aodv.cc) Changes on the command method . . . . . . . . . . . . . . . . . . (aodv.cc) Changes on the sendRequest method . . . . . . . . . . . . . . . . . (aodv.cc) Changes on the sendError method . . . . . . . . . . . . . . . . . . (aodv.cc) Changes on the sendHello method . . . . . . . . . . . . . . . . . . (aodv.cc) Changes on the sendReply method . . . . . . . . . . . . . . . . . . (aodv.cc) Changes on the forward method . . . . . . . . . . . . . . . . . . . (aodv.cc) Changes on the recvRequest method . . . . . . . . . . . . . . . . . (aodv.cc) Changes on the recvReply method . . . . . . . . . . . . . . . . . . (aodv.cc) Changes on the rt update method . . . . . . . . . . . . . . . . . . 6 15 16 16 16 16 18 22 24 26 31 32 33 34 34 34 34 35 36 37 38 38 38 39 39 40 41 41 43 45 47 48 49 51 54 57
LISTINGS
5.19 5.20 6.1 6.2 6.3 6.4 6.5 6.6
(aodv rtable.h) Changes on the aodv rt entry class denition . . . . . . . . (aodv rtable.cc) Changes on the aodv rt entry constructor . . . . . . . . . (scen-script) Initialization of simulation variables . . . . . . . . . . . . . . . (scen-script) Creation of wireless channels . . . . . . . . . . . . . . . . . . . (scen-script) Initialization of the god . . . . . . . . . . . . . . . . . . . . . (scen-script) node-config . . . . . . . . . . . . . . . . . . . . . . . . . . . (scen-script) Creating a number of nodes with the same number of interfaces associated to the same wireless channels . . . . . . . . . . . . . . . . . . . . . (scen-script) Creating two nodes with dierent number of interfaces . . . .
57 58 60 60 60 61 61 61
Chapter 1
Introduction
There is now commonly accepted that the presence of multi-interface enabled devices is going to be very likely in the near future. The rapid growth of IEEE 802.11 technology has eased the sharp decrease of the corresponding products prices and therefore, their presence is each day more and more common. This has gathered the interest of the Network Simulator (ns ) community, since a lot of researchers are willing to extend their simulation models to incorporate multiple interfaces. This document aims at being a guide for all researchers that want to incorporate multiple channel support to the core of the current version of the simulator ns, ns-2. In this sense, there has been quite a lot of discussion about this topic in the corresponding mailing-lists and fora. There are some other people who have already addressed the same aspect; however, our understanding is that the available information is not complete or it is very specic to certain problems, so our goal is to provide a more generic solution, allowing the user to have complete exibility when conguring the scenario.
1.1
Related Work
As has been mentioned before, we have seen quite a lot of interest from the ns community in trying to accommodate multiple interfaces in the simulator model. Some of the approaches that have been used are, or have been, public available. In the remaining of this section, we will analyze three of the most relevant approaches. Although none of them completely fullled our requirements, they denitively provided us with interesting ideas. Below we discuss the main characteristics of each of them, enumerating also the main drawbacks they had, according to our view.
1.1.1
MITF
This is a project not longer active, which was carried out at the University of R o de Janeiro. The goal was to implement multiple interfaces, and to adapt the AODV routing protocol accordingly, and it was done using ns-2.28. However, since the project stopped, it was not possible to fully evaluate concrete results of this research. Most of the modications that were made on the simulator were within its C++ les. More specically, for all the dierent modules which are part of the MobileNode architecture (see Chapter 1.3, e.g. LL, ARP, MAC, etc, arrays (lists of variables) with as many elements
Chapter 1. Introduction
as the maximum number of channels that could be simulated were used, instead of simple variables, which is the original approach used by the simulator. In this way, it was possible to refer to the appropriate module (array model) using the correct channel as an index to locate the corresponding target within the aforementioned list. In addition, two new arrays were created in the MobileNode class, so as to manage the lists of nodes associated to each channel, again using the channel as the index to access these two new arrays. On the other hand, both the Tcl and the implementation of the AODV routing agent were modied so that the multi-interface capability could be exploited from the routing protocol. Although the development was not completely nished, we got a number of interesting ideas, which we partially used in our own development.
1.1.2
TENS
This project [1] was done at the Indian Institute of Technology of Kanpur, India. Its main objective was to improve the ns-2.1b9a implementation of the IEEE 802.11 protocol on various aspects, like the MAC and physical layers model, as well as adding multiple interface support for that specic ns version. The implemented multi-interface model is based on multiplexing, within the C++ implementation of the physical layer; a channel number, specied from the Tcl script, was used to select the appropriate channel. This multi-interface model aimed at emulating the dierent channels used by the DSSS version of the IEEE 802.11 standard (also accounting for the interference) and does not really reect the requirements we originally had (see Chapter 2), since we were willing to create a number of orthogonal interfaces, mainly on Tcl, bringing about the possibility of implementing heterogenous interfaces. This implementation modied dierent C++, as well as Tcl, les. One of the most important aspects was the way dierent interfaces were incorporated into the node from the Tcl code; the approach is quite similar to the one used by the Hyacinth project (see Section 1.1.3). In this case a loop was added to the add-interface procedure of the ns-mobilenode.tcl le, so as to create more than one complete physical layers, i.e. embracing MAC, LL and IFQ (see Chapter 2), per node. This method is of particular interest in our implementation, as will be discussed later.
1.1.3
Hyacinth
This is probably the closest work to ours. The corresponding project was originally carried out at the the State University of New York for ns-2.1b9a [2], and there is available information on how to use it over ns-2.29 [3, 4]. Its main drawback is that it provides quite a static conguration, in which all nodes within the scenario need to incorporate up to 5 dierent interfaces; in addition, a static (manual congurable) routing agent was implemented to use this multi-channel capability, and according to our best knowledge, there is not available information on how to modify existing routing agents (e.g. AODV) so as to be able to use the multi-interface capability. After dening up to 11 dierent channels (thus emulating the IEEE 802.11b physical layer) in the simulator script, ve of them are assigned to each node, by means of the node-config command. Hence, the corresponding procedures were added within the ns-lib.tcl le. Afterwards, the create-wireless-node procedure, also within the the same le, calls ve times the add-interface procedure, each of them with a dierent channel. To our best knowledge, these code segments are always executed, no matter whether the user was interested in having
Chapter 1. Introduction
such number of interfaces within an specic node. Looking at the changes that are required at the mac-802 11.cc le, it seems that in order to guarantee a correct behavior, all nodes within the scenario need to have the same number of interfaces (5 in this case), and, in addition, there is a strong relationship between them, since they are always ordered according to the channel they belong to. On the other hand, as has been already mentioned, the original work was based on a static, manual routing agent, which was congured (i.e. processes to add and delete routes) from the scenario script. Therefore, it is not straightforward extending the use of multiple interfaces to dierent routing protocols.
1.2
Objective of the Document
We have seen in the previous section that there is not a comprehensive, documented, way to extend ns-2 model (at least according to our best knowledge) to add multiple interfaces on a exible way, nor instructions on how to modify routing protocols so as to be able to use this new feature. Hence, the main goal of this technical report is to provide a extensive, though concise, set of changes that need to be performed on the simulator framework, so as to allow, rst, to use a exible number of interfaces per node (i.e. not all nodes within the same scenario need to employ the same interfaces) and, second, to modify routing protocols (existing and new ones) so as to be able to benet from this capability. On the other hand, the document assumes some basic knowledge about the ns framework. The most comprehensive information can probably be found at its manual [5], but there are several other sources available.
1.3
Structure of the Document
The report is organized as follows: next Chapter presents the revised architecture that we implement, based on the original MobileNode, Chapter 3 describes the changes that are required in the Tcl code of the simulator, while Chapter 4 discusses which changes are required in the C++ les. The latter does not include how routing agents need to be adapted so as to use multiple interfaces, since this is discussed in Chapter 5. Chapter 6 describes a potential scenario script that could be used so as to introduce the multi-interface support in the simulation, while Chapter 7 introduces some open future working items, which appear after introducing the capability to incorporate multiple interfaces on the simulator architecture.
1.4
Disclaimer
We do not guarantee the correct operation of these instructions over all ns-2 versions, nor its straightforward usage; interested users may need to perform some additional changes and modications. We will appreciate any feedback on the information provided within the text, so as to make this report as thorough as possible.
10
Chapter 2
Multiple Interface Model

As we have discussed in the previous chapter, one of the results of our research about the current situation on the extension of the Network Simulator framework to include multiple interfaces was that none of the existing solutions completely fullled with our requirements. In this chapter we will describe the architecture of the new MobileNode model that we have implemented, based on the aspects we would like to have in the simulation. It is worth mentioning that although the simulator has two dierent models for mobile nodes, we will just focus on MobileNode, since the other one (SRNode ) is only used by the DSR protocol. However, we understand that the information provided within this document should be enough so as to face the required changes also within the SRNode. Figure 2.1 shows the original architecture of the MobileNode, which consists, below the Routing Agent, of a chain of modules, emulating the dierent protocol stack entities that any host would have in the real life: Link Layer, MAC Protocol, ARP, Interface Queue, Network Interface, all of them connected to the same shared wireless channel. In addition, the Propagation Model is used so as to simulate the eect of the real wireless channels on the transmitted signal; more specically, the propagation loss is modeled, either on a deterministic or a random way.
2.1
Requirements and Working Assumptions
In this section we present all the requirements that we would like to fulll with our development, and we also enumerate the working assumptions that we have made. First, we opted for using dierent instances of the wireless channels at the Tcl level, rather than multiplexing them on a single object (as was done e.g. by the TENS project, see Section 1.1.2), since this is probably better aligned with the intrinsic architecture of the simulator. Using dierent instances of the channel at the Tcl level provides also a greater exibility and eases the changes that are required within the corresponding C++ les. Another additional advantage of this approach is that in this way it is easier to change their characteristics (e.g. transmitting power or energy levels) from the scenario script. Hence, one aspect that will not be added to our implementation is the inter-channel interference. Furthermore, and in contrast with the previous works on this issue, one of the most relevant aspects of our implementation is that it should allow the user to dene a dierent number of interfaces per node, i.e. not all nodes need to implement the same number of interfaces. In addition, the number of channels used in a single simulation could also be parameterized and nodes should be able to randomly connect to a subset of the dened wireless channels, 11
Chapter 2. Multiple Interface Model
Application
255
Routing Agent
Link Layer
ARP
Interface Queue
MAC
Propagation Model
Network Interface
Channel
Figure 2.1: MobileNode Architecture
thus giving a complete exibility to the user. We understand that this level of exibility, that needs to be accomplished from the scenario script, would be really important so as to evaluate dierent types of situations. In addition, our intention is that the modied model could be used with any of the existing (or new) routing agents (but the ones based on the SRNode ), but it would also be nice being able to maintain the legacy behavior of the simulator, so that already existing scripts would still be valid. One of the drawbacks that we observed on the previous works on this aspect is that they usually force the simulations to use their particular characteristics or, otherwise, the simulator will not probably work properly. Taking all the above into consideration we can summarize the requirements we would like to cope with as follows: [REQ.1] The number of channels in a particular scenario should be modiable.
12
[REQ.2] The number of interfaces per node is variable, and do not need to be the same for all nodes within a single scenario. [REQ.3] Each node within the same scenario could connect to a dierent number of channels (of the ones that had been previously dened). [REQ.4] Routing agents may take advantage of the modied model, but legacy operation of the simulator must be preserved, so as to ensure backwards compatibility.
2.2
Multiple Interface Node Model
Taking the discussion of the previous section into consideration, Figure 2.2 presents the high level architecture of the modied MobileNode. As can be seen, each node would have as many copies of the original chain of entities (the one shown before) as many interfaces it has. In addition, the single module which is not repeated is the Propagation Model, since our initial assumption was to work exclusively with IEEE 802.11 networks, in which nodes could use more than one channel at the same time; in these circumstances, the use of a single propagation model is sensible. However, it should not be too complicated being able to extend the current model so as to be able to add exibility also on the number and types of propagation models to be used. For incoming trac, there are not many dierences to the original operation of the simulator. Incoming packets arrive through the corresponding channel and travel through the dierent entities in ascending order; since the last module of every interface, the Link Layer is connected to the same common point (the Address Multiplexer, all packets are handled by the appropriate agent (either the routing protocol or the application), independently of the interface the originally arrived through. On the other hand, for outgoing trac, it is worth highlighting that the intelligence of selecting the appropriate interface needs to be within the routing agent; as can be seen, this is the point in which the decision needs to take place. In Chapter 5, the changes that are required in their C++ implementation to be able to select the appropriate interface are extensively discussed. The following chapters describe the changes that are required in the simulator implementation so as to use the described model. As has been already mentioned, most of the changes are carried out within the Tcl code (see Chapter 3), but in addition some C++ les need to be modied (see chapter 4).
13
Application
255
Routing Agent
Propagation Model
Iface 0
Iface 1
Iface 2
Channel 0 Channel 1 Channel 2
Figure 2.2: Modied MobileNode architecture, with multiple interface support
14
Chapter 3
Changes on Tcl Code

3.1 Introduction
As has been discussed within Chapter 2, we decided to base the multi-interface extension mostly on the Tcl implementation of the simulator, since we believed that this would probably better t the intrinsic operation of the ns architecture. Most of the used Tcl procedures are either within the tcl/lib/ns-lib.tcl or tcl/lib/ns-mobilenode.tcl les. In this chapter we detail the changes that are required within each of them so as to extend the simulator to be able to add multiple interfaces per node.
3.2
Changes on ns-lib.tcl
One aspect that is worth mentioning is that the developments described herewith do require creating the channel before calling the node-config procedure (providing it as an argument), instead of specifying the type of channel within the node-config call. Chapter 6 extensively discusses the script that needs to be used so as to simulate multiple interfaces. We need to create four new procedures. The rst one change-numifs (see Listing 3.1) is called before creating the wireless node, and allows the user to specify a dierent number of interfaces per node. Obviously, if called only once, it will aect all nodes. This procedure, as will be seen later, is called from the scenario script, and needs one argument, being the number of interfaces that a particular node has. Listing 3.1: (ns-lib.tcl) Procedure to change the number of interfaces
S i m u l a t o r i n s t p r o c change numifs { newnumifs } { $ s e l f instvar numifs s e t n u m i f s $newnumifs }
The second one allows to add an interface (channel) to a node; it must be called, also from the scenario script, before the node is created, and requires two arguments: the rst one is the index of such interface within the node, while the second one is the channel itself (Tcl object previously created). The third procedure we have added within the ns-lib.tcl does not need to be called from the scenario script, but is required so that we can gather the number of interfaces from 15
Chapter 3. Changes on Tcl Code
Listing 3.2: (ns-lib.tcl) Procedure to add an interface on a node

S i m u l a t o r i n s t p r o c add channel { i n d e x c h ch } { $ s e l f i n s t v a r chan s e t chan ( $ i n d e x c h ) $ch }
other parts of the Tcl architecture, as will be seen later. It is called get-numifs and it is shown in Listing 3.3. Listing 3.3: (ns-lib.tcl) Procedure to get the number of interfaces
S i m u l a t o r i n s t p r o c get numifs { } { $ s e l f instvar numifs i f [ i n f o e x i s t s numifs ] { return $numifs } else { return } }
Last, we need to create another procedure, so that we can add the number of interfaces as an argument to the node-config command of the Tcl script, as will be seen in Chapter 6. Listing 3.4: (ns-lib.tcl) Procedure to add multiple interfaces as an argument to node-cong label
S i m u l a t o r i n s t p r o c ifNum { v a l } { $ s e l f s e t n u m i f s $val}
In addition to the new ones shown above, two of the already existing procedures need to be modied. The rst one is node-config, in which we have to initialize the chan variable, either as a single variable, if normal operation is being used, or as an array, when the multiinterface is enabled. Furthermore, we add the numifs variable to the list of arguments passed to the method. The changes are shown on Listing 3.5. Listing 3.5: (ns-lib.tcl) Changes on node-cong procedure
S i m u l a t o r i n s t p r o c no de co nfig a r g s { # O b j e c t : : i n i t v a r s {} i s d e f i n e d i n t c l c l / t c l o b j e c t . t c l . # I t i n i t i a l i z e s a l l d e f a u l t v a r i a b l e s in the f o l l o w i n g way: # 1 . Look f o r p a i r s o f {cmd v a l } i n a r g s # 2. I f $ s e l f $cmd $ v a l i s not v a l i d then put i t i n a l i s t of # arguments t o be r e t u r n e d t o t h e c a l l e r . # # S i n c e we do not ha ndle u n d e f i n e d {cmd v a l } p a i r s , we ignore # r e t u r n v a l u e from i n i t v a r s {} . set args [ eval $ s e l f initvars $args ]
16
$ s e l f i n s t v a r addressType r o u t i n g A g e n t propType macTrace \ r o u t e r T r a c e a g e n t T r a c e movementTrace cha nnelType c h a n n e l numifs \ chan t o p o I n s t a n c e p r o p I n s t a n c e m o b i l e I P rxPower \ # change wrt Mike s co de txPower i d l e P o w e r satNodeType e o t T r a c e i f [ i n f o e x i s t s macTrace ] { S i m u l a t o r s e t MacTrace $macTrace } i f [ info e xi s ts routerTrace ] { S i m u l a t o r s e t Ro uter Tr a ce $ r o u t e r T r a c e } i f [ i n f o e x i s t s agentTrace ] { S i m u l a t o r s e t Ag entTr a ce $ a g e n t T r a c e } i f [ i n f o e x i s t s movementTrace ] { S i m u l a t o r s e t MovementTrace $movementTrace } # change wrt Mike s co de i f [ i n f o e x i s t s eotTrace ] { S i m u l a t o r s e t E o tTr a ce }
$eotTrace
# h a c k i n g f o r matching o l d cmu a d d i n t e r f a c e # not good s t y l e , f o r ba ck co mpa bility ONLY # # Only c r e a t e 1 i n s t a n c e o f prop i f {[ info e x i st s propInstance ]} { i f { [ i n f o e x i s t s propType ] && [ S i m u l a t o r s e t p r o p I n s t C r e a t e d ] == 0 } { warn Both propType and p r o p I n s t a n c e a r e s e t . propType is ignored. } } else { i f { [ i n f o e x i s t s propType ] } { s e t p r o p I n s t a n c e [ new $propType ] Simulator s e t propInstCreated 1 } } # Add m u l t i i n t e r f a c e s u p p o r t : # User can o n l y s p e c i f y e i t h e r cha nnelType ( s i n g l e i n t e r f a c e as # before ) or channel ( m u l t i i n t e r f a c e ) # I f both v a r i a b l e s a r e s p e c i f i e d , e r r o r ! i f { [ i n f o e x i s t s cha nnelType ] && [ i n f o e x i s t s c h a n n e l ] } { e r r o r Can t s p e c i f y both c h a n n e l and c h a n n e l T y p e , e r r o r ! } e l s e i f { [ i n f o e x i s t s cha nnelType ] && ! [ i n f o e x i s t s satNodeType ] } {
17
# Single channel, s ing le inter fa ce warn P l e a s e use channel a s shown i n t c l / ex / wirelessmitf.tcl i f { ! [ i n f o e x i s t s chan ] } { s e t chan [ new $ cha nnelType ] } } e l s e i f {[ i n fo e x i s t s channel ]} { # Multiple channel, multiple i n t e r f a c e s i f { [ i n f o e x i s t s numifs ] } { s et chan(0) $channel } else { s et chan $channel } } i f [ info ex i s ts topoInstance ] { $propInstance to po g r a phy $ t o p o I n s t a n c e } # s e t a d d r e s s t y p e , h i e r a r c h i c a l o r expanded i f { [ s t r i n g compare $ a d d r e s s T y p e ] != 0 } { $ s e l f set a ddr ess fo r ma t $ a d d r e s s T y pe } # s e t mo bileIP f l a g i f { [ i n f o e x i s t s m o b i l e I P ] && $ m o b i l e I P == ON } { Simulator s e t m o b i l e i p 1 } else { i f { [ i n f o e x i s t s mobileIP ] } { Simulator s e t m o b i l e i p 0 } } }
The changes are highlighted with bold font on the above listing. As can be seen, we maintain the legacy operation of the simulator, and we do only modify it provided that the multi-interface extension has been set from the scenario script. Listing 3.6 shows the other procedure which needs to be modied, create-wireless-node. In this case, when the extension is being used, the add-interface procedure, which is dened in the ns-mobilenode.tcl le, has to be called as many times as the number of interfaces the node has, and a for loop is used for this. Listing 3.6: (ns-lib.tcl) Changes on create-wireless-node procedure
Simulator i n s t p r o c createwirelessnode args { $ s e l f i n s t v a r routingAgent wiredRouting pr o pInsta nce llType \ macType i f q T y p e i f q l e n phyType chan antType ener g yMo del \ i n i t i a l E n e r g y txPower rxPower i d l e P o w e r \ topoInstance l e v e l 1 l e v e l 2 inerrProc outerrProc FECProc numifs S i m u l a t o r s e t IMEPFlag OFF
18
# c r e a t e node i n s t a n c e s e t node [ e v a l $ s e l f c r e a t e n o d e i n s t a n ce $ a r g s ] # basestation address s e tti n g i f { [ i n f o e x i s t w i r e d R o u t i n g ] && $ w i r e d R o u t i n g == ON } { $node b a s e s t a t i o n [ AddrParams a d d r 2 i d [ $node node addr ] ] } s w i t c h exact $ r o u t i n g A g e n t { DSDV { s e t r a g e n t [ $ s e l f create dsdv agent $node ] } DSR { $ s e l f a t 0 . 0 $node s t a r t d s r } AODV { s e t r a g e n t [ $ s e l f create aodv agent $node ] } TORA { S i m u l a t o r s e t IMEPFlag ON s e t r a g e n t [ $ s e l f c r e a t e t o r a a g e nt $node ] } DIFFUSION/RATE { e v a l $node addr $ a r g s s e t r a g e n t [ $ s e l f c r e a t e d i f f u s i o n r a t e a g e n t $node ] } DIFFUSION/PROB { e v a l $node addr $ a r g s set ragent [ $ s e l f creatediffusionprobabilityagent $node ] } Directed Diffusion { e v a l $node addr $ a r g s s e t r a g e n t [ $ s e l f c r e a t e c o r e d i f f u s i o n r t g a g e n t $node ] } FLOODING { e v a l $node addr $ a r g s s e t r a g e n t [ $ s e l f c r e a t e f l o o d i n g a g e n t $node ] } OMNIMCAST { e v a l $node addr $ a r g s s e t r a g e n t [ $ s e l f create omnimcast agent $node ] } DumbAgent { s e t r a g e n t [ $ s e l f create dumb agent $node ] } default { puts Wrong node r o u t i n g a g ent ! exit } }
19
# e r r P r o c and FECProc a r e an o p t i o n u n l i k e o t h e r # p a r a m e t e r s f o r node i n t e r f a c e i f ! [ info exist inerrProc ] { s e t i n e r r P r o c } i f ! [ info exist outerrProc ] { s e t o ute r r P r o c } i f ! [ i n f o e x i s t FECProc ] { s e t FECProc } # Adding I n t e r f a c e i f { [ i n f o e x i s t numifs ] } { for { s et i 0} { $i < $numifs } { i ncr i } { # Add one i n t e r f a c e per channel $node add interface $chan( $i ) $propInstance $llType $macType \ $ifqType $ i f q l e n $phyType $antType $topoInstance \ $inerrProc $outerrProc $FECProc } } else { $node add interface $chan $propInstance $llType $macType \ $ifqType $ i f q l e n $phyType $antType $topoInstance \ $inerrProc $outerrProc $FECProc } # Attach a g ent i f { $ r o u t i n g A g e n t != DSR } { $node a t t a c h $ r a g e n t [ Node s e t r t a g e n t p o r t ] } i f { $ r o u t i n g A g e n t == DIFFUSION/RATE | | $ r o u t i n g A g e n t == DIFFUSION/PROB | | $ r o u t i n g A g e n t == FLOODING | | $ r o u t i n g A g e n t == OMNIMCAST | | $ r o u t i n g A g e n t == D i r e c t e d D i f f u s i o n } { $ r a g e n t port dmux [ $node demux ] $node i n s t v a r l l $ r a g e n t a dd ll $ l l ( 0 ) } i f { $ r o u t i n g A g e n t == DumbAgent } { $ r a g e n t port dmux [ $node demux ] }
# Bind r o u t i n g a g ent and mip a g ent i f e x i s t i n g b a s e s t a t i o n # address s e tti n g i f { [ i n f o e x i s t w i r e d R o u t i n g ] && $ w i r e d R o u t i n g == ON } { i f { $ r o u t i n g A g e n t != DSR } { $node mip ca ll $ r a g e n t
20
} } # # This Trace Ta r g et i s used t o l o g cha ng es i n d i r e c t i o n # and v e l o c i t y f o r t h e mo bile n o d e . # set tracefd [ $ s e l f getnstraceall ] i f { $ t r a c e f d != } { $node n o d e t r a c e $ t r a c e f d $node a g e n t t r a c e $ t r a c e f d } s e t na mtr a cefd [ $ s e l f g et na m tr a cea ll ] i f { $ na mtr a cefd != } { $node namattach $ na mtr a cefd } i f [ i n f o e x i s t s ener g yMo del ] { if [ info exists level1 ] { set l1 $level1 } else { set l1 0.5 } if [ info exists level2 ] { set l2 $level2 } else { set l2 0.2 } $node addenergymodel [ new $ ener g yMo del $node \ $initialEnergy $l1 $l2 ] } i f [ i n f o e x i s t s txPower ] { $node s e t P t $txPower } i f [ i n f o e x i s t s rxPower ] { $node s e t P r $rxPower } i f [ i n fo e x i s t s idlePower ] { $node s e t P i d l e $ i d l e P o w e r } $node to po g r a phy $ t o p o I n s t a n c e r e t u r n $node }
3.3
Changes on ns-mobilenode.tcl
In this case no new procedures were required, but rather some modications have to be performed to some of the already existing ones. These are explained in the remaining of this section. The rst procedure which was modied is the add-target, which can be seen on List21
ing 3.7. First of all, the get-numifs procedure that was discussed before is called, so that we can assess whether we are using the multi-interface extension and, if such is the case, the number of interfaces that the current node has. Later, this number is used to call the new if-queue command of the routing agent (see Chapter 5) as many times as the number of interfaces the node has. Listing 3.7: (ns-mobilenode.tcl) Changes on add-target procedure
Node/ MobileNode i n s t p r o c a dd ta r g et { a g ent p o r t } { $ s e l f i n s t v a r dmux imep to r a Debug s e t ns [ S i m u l a t o r i n s t a n c e ] s e t newapi [ $ns imep support ] $ a g ent s e t s p o r t $port
# We get the number of i n t e r f a c e s from the simulator object s et numIfsSimulator [ $ns getnumifs ] # s p e c i a l p r o c e s s i n g f o r TORA/IMEP node s e t t o r a o n l y [ s t r i n g f i r s t TORA [ $ a g ent i n f o c l a s s ] ] i f { $ t o r a o n l y != 1 } { $ a g ent if queue [ $ s e l f s e t i f q ( 0 ) ] ;# i f q between LL and MAC # # XXX: The r o u t i n g p r o t o c o l and t h e IMEP a g e n t s needs handles # t o ea ch o t h e r . # $ a g ent imep agent [ $ s e l f s e t imep ( 0 ) ] [ $ s e l f s e t imep ( 0 ) ] r t a g e n t $ a g ent } # S p e c i a l p r o c e s s i n g f o r AODV s e t a o dvo nly [ s t r i n g f i r s t AODV [ $ a g ent i n f o c l a s s ] ] i f { $ a o dvo nly != 1 } { $ a g ent if queue [ $ s e l f s e t i f q ( 0 ) ] ;# i f q between LL and MAC } # <z h e n g : add> # S p e c i a l p r o c e s s i n g f o r ZBR #s e t z b r o n l y [ s t r i n g f i r s t ZBR [ $ a g ent i n f o c l a s s ] ] #i f { $ z b r o n l y != 1 } { # $ a g ent if queue [ $ s e l f s e t i f q ( 0 ) ] ;# i f q between LL and MAC #} #</z h e n g : add> i f { $ p o r t == [ Node s e t r t a g e n t p o r t ] } { # Special processing when multiple i n t e r f a c e s are supported i f { $numIfsSimulator != } {
22
for { s et i 0} { $i < [ $ s e l f s et n i f s ] } { i ncr i } { $agent if queue $i [ $ s e l f s et i f q ( $i ) ] } } # Ad hoc r o u t i n g a g ent s e t u p needs s p e c i a l h a n d l i n g $ s e l f a dd ta r g et r ta g ent $ a g ent $ p o r t return } # A t t a c h i n g a normal a g ent s e t namfp [ $ns g et na m tr a cea ll ] i f { [ S i m u l a t o r s e t Ag entTr a ce ] == ON } { # # Send Ta r g et # i f { $newapi != } { s e t sndT [ $ s e l f m o b i l i t y t r a c e Send AGT ] } else { s e t sndT [ cmu trace Send AGT $ s e l f ] } i f { $namfp != } { $sndT namattach $namfp } $sndT t a r g e t [ $ s e l f e n t r y ] $ a g ent t a r g e t $sndT # # Recv Ta r g et # i f { $newapi != } { s e t rcvT [ $ s e l f m o b i l i t y t r a c e Recv AGT ] } else { s e t rcvT [ cmu trace Recv AGT $ s e l f ] } i f { $namfp != } { $rcvT namattach $namfp } $rcvT t a r g e t $ a g ent $dmux i n s t a l l $ p o r t $rcvT } else { # # Send Ta r g et # $ a g ent t a r g e t [ $ s e l f e n t r y ] # # Recv Ta r g et # $dmux i n s t a l l $ p o r t $ a g ent } }
The second procedure that needs to be modied is the add-target-rtagent, which is
23
called from the previous one, when the agent is attached to the RT PORT port and, thus it is a routing agent. As we did before, we use the get-numifs procedure to get the number of interfaces that the node has (provided that the multi-hop extension is being used) and we later use this variable so as to link the routing agent with the corresponding link layer (ll ) entities, which were initialized before, after the subsequent calls to the add-interface procedure. The variable numIfsSimulator allows us to preserve the original behavior of the simulator, since the legacy code is still used when this variable does not have a valid value. We do this both when the tracing support is activated and when it is not. Listing 3.8: (ns-mobilenode.tcl) Changes on add-target-rtagent procedure
Node/ MobileNode i n s t p r o c a dd ta r g et r ta g ent { a g ent p o r t } { $ s e l f i n s t v a r imep to r a Debug s e t ns [ S i m u l a t o r i n s t a n c e ] s e t newapi [ $ns imep support ] s e t namfp [ $ns g et na m tr a cea ll ] s e t dmux [ $ s e l f demux ] set c l a s s i f i e r [ $ s e l f entry ] # We see whether we have multiple i n t e r f a c e s in the simulation s et numIfsSimulator [ $ns getnumifs ] # l e t t h e r o u t i n g a g ent know about t h e p o r t dmux $ a g ent port dmux $dmux i f { [ S i m u l a t o r s e t Ro uter Tr a ce ] == ON } { # # Send Ta r g et # i f { $newapi != } { s e t sndT [ $ s e l f m o b i l i t y t r a c e Send RTR ] } else { s e t sndT [ cmu trace Send RTR $ s e l f ] } i f { $namfp != } { $sndT namattach $namfp } i f { $newapi == ON } { $ a g ent t a r g e t $imep ( 0 ) $imep ( 0 ) s e n d t a r g e t $sndT # seco nd t r a c e r t o s e e t h e a c t u a l # t y p e s o f t o r a p a c k e t s b e f o r e imep pa cks them i f { [ i n f o e x i s t s to r a Debug ] && $ to r a Debug == ON } { s e t sndT2 [ $ s e l f m o b i l i t y t r a c e Send TRP ] $sndT2 t a r g e t $imep ( 0 ) $ a g ent t a r g e t $sndT2 } $sndT target [ $ s e l f s et l l (0) ] } e l s e { ;# no IMEP i f { $numIfsSimulator != } {
24
for { s et i 0} { $i < [ $ s e l f s et n i f s ] } { i ncr i } { s et sndT [ cmutrace Send RTR $ s e l f ] $agent target $i $sndT $sndT target [ $ s e l f s et l l ( $i ) ] } } else { $agent target $sndT $sndT target [ $ s e l f s et l l (0) ] } } # # Recv Ta r g et # i f { $newapi != } { s e t rcvT [ $ s e l f m o b i l i t y t r a c e Recv RTR ] } else { s e t rcvT [ cmu trace Recv RTR $ s e l f ] } i f { $namfp != } { $rcvT namattach $namfp } i f { $newapi == ON } { [ $ s e l f s e t l l ( 0 ) ] up target $imep ( 0 ) $classifier d e f a u l t t a r g e t $ a g ent # need a seco nd t r a c e r t o s e e t h e a c t u a l # t y p e s o f t o r a p a c k e t s a f t e r imep unpacks them # no need t o s u p p o r t any h i e r node i f { [ i n f o e x i s t s to r a Debug ] && $ to r a Debug == ON } { s e t rcvT2 [ $ s e l f m o b i l i t y t r a c e Recv TRP ] $rcvT2 t a r g e t $ a g ent $classifier d e f a u l t t a r g e t $rcvT2 } } else { $rcvT t a r g e t $ a g ent $classifier d e f a u l t t a r g e t $rcvT $dmux i n s t a l l $ p o r t $rcvT } } else { # # Send Ta r g et # # i f t o r a i s used i f { $newapi == ON } { $ a g ent t a r g e t $imep ( 0 ) # seco nd t r a c e r t o s e e t h e a c t u a l # t y p e s o f t o r a p a c k e t s b e f o r e imep pa cks them i f { [ i n f o e x i s t s to r a Debug ] && $ to r a Debug == ON } { s e t sndT2 [ $ s e l f m o b i l i t y t r a c e Send TRP ] $sndT2 t a r g e t $imep ( 0 ) $ a g ent t a r g e t $sndT2 } $imep ( 0 ) s e n d t a r g e t [ $ s e l f s e t l l ( 0 ) ]
25
} e l s e { ;# no IMEP i f { $numIfsSimulator != } { for { s et i 0} { $i < [ $ s e l f s et n i f s ] } { i ncr i } { $agent target $i [ $ s e l f s et l l ( $i ) ] } } else { $agent target [ $ s e l f s et l l (0) ] } } # # Recv Ta r g et # i f { $newapi == ON } { [ $ s e l f s e t l l ( 0 ) ] up target $imep ( 0 ) $classifier d e f a u l t t a r g e t $ a g ent # need a seco nd t r a c e r t o s e e t h e a c t u a l # t y p e s o f t o r a p a c k e t s a f t e r imep unpacks them # no need t o s u p p o r t any h i e r node i f { [ i n f o e x i s t s to r a Debug ] && $ to r a Debug == ON } { s e t rcvT2 [ $ s e l f m o b i l i t y t r a c e Recv TRP ] $rcvT2 t a r g e t $ a g ent [ $ s e l f s e t c l a s s i f i e r ] d e f a u l t t a r g e t $rcvT2 } } else { $classifier d e f a u l t t a r g e t $ a g ent $dmux i n s t a l l $ p o r t $ a g ent } } }
The last procedure that needs to be modied is the add-interface; originally we did not touch this one, since the multi-interface support was brought about by the for loop that was added into the create-wireless-node procedure. However, if no changes were made, the model that has been presented on Figure 2.2 would not have been completely accurate, since the original add-interface method would have just created one ARP table per node, instead of one ARP table per interface. Although it could be argued that having one ARP per node would have been closer to a realistic case, we noticed that this could lead to a wrong behavior. E.g. if a node has already used one interface to communicate with another one, it will not be possible trying to use another interface, as the request to the ARP entity would be answered with previous entry, which would not be longer valid. Hence, functionality-wise it is more appropriate having one ARP table per interface. To achieve this, as already mentioned, we needed to make some changes on the add-interface procedure, as shown on Listing 3.9. Listing 3.9: (ns-mobilenode.tcl) Changes on add-interface procedure
Node/ MobileNode i n s t p r o c a d d i n t e r f a c e { c h a n n e l pmodel l l t y p e mactype qtype q l e n i f t y p e a n t t y p e to po i n e r r p r o c o u t e r r p r o c fecproc} { $ self instvar arptable outerr fec nifs netif mac ifq ll imep inerr
26
s e t ns [ S i m u l a t o r i n s t a n c e ] s e t i m e p f l a g [ $ns imep support ] set t $nifs incr nif s set set set set n e t i f ( $ t ) [ new $ i f t y p e ] ;# i n t e r f a c e mac ( $ t ) [ new $mactype ] ;# mac l a y e r i f q ( $t ) [ new $ qtype ] ;# i n t e r f a c e queue ;# l i n k l a y e r l l ( $ t ) [ new $ l l t y p e ] set ant ( $t ) [ new $ a n t t y p e ]
$ns mac type $mactype s e t i n e r r ( $ t ) i f { $ i n e r r p r o c != } { set i n e r r ( $t ) [ $ iner r pr o c ] } s e t o u t e r r ( $t ) i f { $ o u t e r r p r o c != } { set o uter r ( $t ) [ $outerrproc ] } s e t f e c ( $t ) i f { $ f e c p r o c != } { set f e c ( $t ) [ $fecproc ] } s e t namfp [ $ns g et na m tr a cea ll ] i f { $ i m e p f l a g == ON } { # IMEP l a y e r s e t imep ( $ t ) [ new Agent /IMEP [ $ s e l f i d ] ] s e t imep $imep ( $ t ) s e t drpT [ $ s e l f m o b i l i t y t r a c e Drop RTR ] i f { $namfp != } { $drpT namattach $namfp } $imep dr o p ta r g et $drpT $ns a t 0 . [ $ s e l f i d ] $imep ( $ t ) s t a r t ;# s t a r t beacon timer } # # Local Variables # s e t n u l l A g e n t [ $ns s e t n u l l A g e n t ] set n e t i f $ n e t i f ( $t ) s e t mac $mac ( $ t ) set i f q $ i f q ( $t ) set l l $ l l ( $t ) set i n e r r $ i n e r r ( $t ) set outerr $ o uter r ( $t ) set f e c $ f e c ( $t ) # We al s o create one ARP table per i n t e r f a c e
27
s et arptable ( $t ) [new ARPTable $ s e l f $mac] s et arptable $arptable ( $t ) i f { $ i m e p f l a g != } { s e t drpT [ $ s e l f m o b i l i t y t r a c e Drop IFQ ] } else { s e t drpT [ cmu trace Drop IFQ $ s e l f ] } $arptable drop target $drpT i f { $namfp != } { $drpT namattach $namfp } # # Link Layer # $ l l arptable $arptable $ l l mac $mac $ l l down target $ i f q i f { $ i m e p f l a g == ON } { $imep r e c v t a r g e t [ $ s e l f e n t r y ] $imep s e n d t a r g e t $ l l $ l l up target $imep } else { $ l l up target [ $ s e l f e n t r y ] } # # I n t e r f a c e Queue # $ i f q t a r g e t $mac $ i fq set l i m i t $qlen i f { $ i m e p f l a g != } { s e t drpT [ $ s e l f m o b i l i t y t r a c e Drop IFQ ] } else { s e t drpT [ cmu trace Drop IFQ $ s e l f ] } $ i f q dr o p ta r g et $drpT i f { $namfp != } { $drpT namattach $namfp } # # Mac Layer # $mac n e t i f $ n e t i f $mac up target $ l l i f { $ o u t e r r == && $ f e c == } { $mac down target $ n e t i f } e l s e i f { $ o u t e r r != && $ f e c == } { $mac down target $ o u t e r r $outerr target $netif } e l s e i f { $ o u t e r r == && $ f e c != } {
28
$mac $fec } else { $mac $fec $err }
down target $ f e c down target $ n e t i f down target $ f e c down target $ o u t e r r target $netif
s e t g o d [ God i n s t a n c e ] i f { $mactype == Mac/802 1 1 } { $mac no des [ $ g o d num nodes ] } # # Network I n t e r f a c e # #i f { $ f e c == } { # $ n e t i f up target $mac #} e l s e { # $ n e t i f up target $ f e c # $ f e c up target $mac #} $ n e t i f channel $channel i f { $ i n e r r == && $ f e c == } { $ n e t i f up target $mac } e l s e i f { $ i n e r r != && $ f e c == } { $ n e t i f up target $ i n e r r $ i n e r r t a r g e t $mac } e l s e i f { $ e r r == && $ f e c != } { $ n e t i f up target $ f e c $ f e c up target $mac } else { $ n e t i f up target $ i n e r r $inerr target $fec $ f e c up target $mac } $ n e t i f p r o p a g a t i o n $pmodel ;# P r o p a g a t i o n Model $ n e t i f node $ s e l f ;# Bind node < > interface $ n e t i f antenna $ a n t ( $ t ) # # P h y s i c a l Channel # $channel addif $ n e t i f # List ba sed improvement # For no des t a l k i n g t o m u l t i p l e c h a n n e l s t h i s s h o u l d # be c a l l e d m u l t i p l e t i m e s f o r ea ch c h a n n e l $ c h a n n e l add node $ s e l f # l e t to po keep ha ndle o f c h a n n e l $ to po c h a n n e l $ c h a n n e l # ============================================================
29
i f { [ S i m u l a t o r s e t MacTrace ] == ON # # Trace RTS/CTS/ACK P a c k e t s # i f { $ i m e p f l a g != } { s e t rcvT [ $ s e l f m o b i l i t y t r a c e } else { s e t rcvT [ cmu trace Recv MAC } $mac l o g t a r g e t $rcvT i f { $namfp != } { $rcvT namattach $namfp } # # Trace Sent P a c k e t s # i f { $ i m e p f l a g != } { s e t sndT [ $ s e l f m o b i l i t y t r a c e } else { s e t sndT [ cmu trace Send MAC } $sndT t a r g e t [ $mac down target ] $mac down target $sndT i f { $namfp != } { $sndT namattach $namfp } # # Trace R e c e i v e d P a c k e t s # i f { $ i m e p f l a g != } { s e t rcvT [ $ s e l f m o b i l i t y t r a c e } else { s e t rcvT [ cmu trace Recv MAC } $rcvT t a r g e t [ $mac up target ] $mac up target $rcvT i f { $namfp != } { $rcvT namattach $namfp } # # Trace Dropped P a c k e t s # i f { $ i m e p f l a g != } { s e t drpT [ $ s e l f m o b i l i t y t r a c e } else { s e t drpT [ cmu trace Drop MAC } $mac dr o p ta r g et $drpT i f { $namfp != } { $drpT namattach $namfp } } else {
} {
Recv MAC ] $self ]
Send MAC ] $self ]
Recv MAC ] $self ]
Drop MAC ] $self ]
30
$mac l o g t a r g e t [ $ns s e t n u l l A g e n t ] $mac dr o p ta r g et [ $ns s e t n u l l A g e n t ] } # change wrt Mike s co de i f { [ S i m u l a t o r s e t E o tTr a ce ] == ON } { # # Also t r a c e end o f t r a n s m i s s i o n time f o r p a c k e t s # i f { $ i m e p f l a g != } { s e t eotT [ $ s e l f m o b i l i t y t r a c e EOT MAC ] } else { s e t eoT [ cmu trace EOT MAC $ s e l f ] } $mac e o t t a r g e t $eotT }
# ============================================================ $ s e l f addif $netif }
This latter change aects the way the MobileNode is created (see Listing 3.10) and reset (see Listing 3.11). Listing 3.10: (ns-mobilenode.tcl) MobileNode init procedure
Node/ MobileNode i n s t p r o c i n i t a r g s { # # I don t c a r e about a d d r e s s c l a s s i f i e r ; i t s not my b u s i n e s s # # A l l I do i s t o s e t u p p o r t c l a s s i f i e r so we can do b r o a d c a s t , # # and t o s e t up i n t e r f a c e s t u f f . # $ s e l f attach node $node # $node p o r t n o t i f y $ s e l f e v a l $ s e l f next $ a r g s $ s e l f i n s t v a r n i f s a r p t a b l e X Y Z nodetype set X 0.0 set Y 0.0 set Z 0.0 # s et arptable ;# no ARP table yet set ni fs 0 ;# number o f network i n t e r f a c e s # Mobile IP node p r o c e s s i n g $ s e l f makemip New$nodetype }
31
Listing 3.11: (ns-mobilenode.tcl) MobileNode reset procedure

Node/ MobileNode i n s t p r o c r e s e t {} { $ self instvar arptable n if s n e t i f mac i f q l l imep f o r { s e t i 0} { $ i < $ n i f s } { i n c r i } { $netif ( $i ) reset $mac ( $ i ) r e s e t $ ll ( $i ) reset $ifq ( $i ) reset i f { [ i n f o e x i s t s opt ( imep ) ] && $ o pt ( imep ) == ON } { $imep ( $ i ) r e s e t } i f { $arptable ( $i ) != } { $arptable ( $i ) res et } } }
32
Chapter 4
Changes on C++ Code

4.1 Introduction
As we have already said, most of the changes have been done within the Tcl implementation of the simulator. However, some modications need to be done, also within the C++ les, basically to be able to adapt to the new framework. Most of the changes aect how the simulator deals with the MobileNode class and are discussed in the remaining of this section.
4.2
Changes on mobilenode.[cc,h]
After creating the multiple interface structures for mobile nodes on Tcl, it is necessary to correctly associate them to the appropriate channel. The simulator controls the nodes which are connected to a channel by means of a list which is managed using two pointers (one to the previous and another one to the next node on the list). These pointers were originally simple variables; however, if we wish to manage several channels, it is required to create two arrays of pointers with as many elements as channels exist within the simulation scenario. In this sense, it becomes easy managing the nodes of one particular channel, i.e. referring to it using the channel number as the array index, thus being able to move to either the previous or the next element of the list. These modications are made in the mobilenode.h le as shown in Listing 4.1; obviously the MAX CHANNELS variable needs to be dened before. Listing 4.1: (mobilenode.h) New declaration of MobileNode lists within MobileNode class
... / For l i s t k e e p e r / MobileNode nextX [MAX CHANNELS] ; MobileNode prevX [MAX CHANNELS] ; ...
After performing all the changes needed to adapt to the new denitions of the nextX and prevX variables (see next Section) we detected quite a weird behavior on the simulator. The call to the original getLoc method, which was declared as inline within the MobileNode class did not work properly, as it always returned a zero distance, thus leading to wrong packet receptions, no matter the real distance between nodes. In order to solve this problem, we changed the method declaration, so that it was not inline anymore, as shown in Listing 4.2.
33
Chapter 4. Changes on C++ Code
Listing 4.2: (mobilenode.h) New getLoc method declaration within MobileNode class
... void s t a r t ( void ) ; void getLoc ( double x , double y , double z ) ; i n l i n e v o i d g e t V e l o ( do uble dx , do uble dy , do uble dz ) { dx = dX s p e e d ; dy = dY s p e e d ; dz = 0 . 0 ; } ...
In addition, we added the method denition within the mobilenode.cc le (see Listing 4.3). Listing 4.3: (mobilenode.cc) getLoc method denition
void MobileNode : : g etLo c ( do uble x , do uble y , do uble z ) { update position () ; x = X ; y = Y ; z = Z ; }
4.3
Changes on channel.cc
The two arrays mentioned above are used within the channel.cc le so as to manage the corresponding node lists (e.g. attaching a new node to a channel, removing, updating, etc). In order to refer to the appropriate list, the index of the corresponding channel has to be used, as shown in Listing 4.4, where this->index() refers to the correct one. Note that this has to be changed throughout the whole channel.cc le. Listing 4.4: (channel.cc) Accessing the appropriate MobileNode list
nextX [ t h i s >i n d e x ( ) ] prevX [ t h i s >i n d e x ( ) ]
Furthermore, when a packet is sent, a previous evaluation procedure is performed so as to ensure that it is sent to the correct destination. The rst step is to assess which nodes are close enough to the source and are also connected to the channel that will be used for this communication (this last condition is automatically checked because the right list of nodes for this channel had been previously selected, thanks to the management changes explained before). Then, the packet could be sent to all of the interfaces in the destination node. However, this makes little sense, since the packet should only be received from the interface connected to the appropriate channel. In this sense, we had to add a new condition so as to check which of the interfaces of the destination node is connected to the same channel that will be used to transmit the packet. The code already modied in channel.cc is shown in Listing 4.5.
34
Chapter 4. Changes on C++ Code
Listing 4.5: (channel.cc) affectedNodes method from the channel class

a f f e c t e d N o d e s = g e t A f f e c t e d N o d e s ( mtnode , distCST &numAffectedNodes ) ; f o r ( i =0; i < numAffectedNodes ; i ++) { r no de = a f f e c t e d N o d e s [ i ] ; i f ( r no de == tno de ) continue ; newp = p>copy ( ) ; p r o p d e l a y = g e t p d e l a y ( tnode , r no de ) ; r i f p = ( rnode > i f h e a d ( ) ) . l h f i r s t ; f o r ( ; r i f p ; r i f p = r i f p >nextno de ( ) ) { i f ( r i f p >channel () == t h i s ) { s . s c h e d u l e ( r i f p , newp , p r o p d e l a y ) ; } } } delete [ ] affectedNodes ; + / s a f e t y / 5 ,
4.4
Changes on mac-802 11.cc
The last change in the C++ code is needed so as to be able to identify the interface which a message was received through. This is mandatory for the correct handling of multiple interfaces by the routing agents, as will be explained in Chapter 5. The code which is shown in Listing 4.6 needs to be added to the mac-802 11.cc le. Listing 4.6: (mac-802 11.cc) Registering the correct MAC receiving interface within the recv method of the Mac802 11 class
... i f ( t x a c t i v e && hdr> e r r o r ( ) == 0 ) { hdr> e r r o r ( ) = 1 ; } hdr >i f a c e () = addr () ; i f ( r x s t a t e == MAC IDLE) { ...
35
Chapter 5
Changes on Routing Protocol Code

5.1 Introduction
It goes without saying that the nal goal of implementing the multi-interface model is to make use of it. Hence, external agents from the simulator architecture must be changed so as to use this new feature. In this section we show how a routing agent needs to be adapted in order to use the multiple interface structure previously discussed, so that it is possible to assess the benets of the modied model. These changes have been tested on a proprietary implementation of an ad-hoc routing protocol, which follows the same approach as the original AODV implementation from the simulator does. Nonetheless, they are generic enough, so it should not be too complicated extending them to other agents. In order to fully understand the discussions of this chapter, a good knowledge of how routing protocols are implemented within the simulator is required. The reader may refer to [6] for a good overview on this issue.
5.2
Changes on routing agent implementation
Since we want the number of interfaces per node to be exible, and furthermore, we want to maintain the legacy behavior of the simulator, it is required that the routing agent keeps track of the number of interfaces it is managing. A new member of the routing agent class, nIfaces, is declared so as to keep this information. In our approach, the interfaces will be dened stepwise from the scenario script (see Chapter 6), so at the beginning its value is set to 0 (i.e. in the constructor of the agent). As can be seen on Figure 2.2, it is the routing agent that needs to decide upon the outgoing interface it needs to pass the packet to. Instead of using the traditional single ifqueue and target that any routing agent may use, we declare two arrays, targetlist and ifqueuelist. The rst one stores the LL modules for all the interfaces a particular node has, whilst the second one keeps their corresponding queues. Listing 5.1 shows the lines that are required to be added within the header le of the routing agent (within the class declaration). MAX IF needs to be declared beforehand. Listing 5.1: (routingAgent.h) New class members to manage multiple interfaces
int nIfaces ;
36
Chapter 5. Changes on Routing Protocol Code
NsObject t a r g e t l i s t [ MAX IF ] ; PriQueue i f q u e u e l i s t [ MAX IF ] ;
The next step would be to modify the command method of the routing agent class, so as to initialize the values of the aforementioned variables from the Tcl script and to make use of them. Listing 5.2 shows how the aforementioned arrays, ifqueuelist and targetlist get populated, taking the corresponding values while the interfaces are being created in the nodes. At the same time we increase the value of the variable that maintains the number of interfaces used by the node, for each of the interfaces which are added. Listing 5.2: (routingAgent.cc) Changes on command method of the routing agent class
e l s e i f ( a r g c == 4 ) { i f ( strcmp ( a r g v [ 1 ] , i f queue ) == 0 ) { PriQueue i f q = ( PriQueue ) T c l O b j e c t : : lo o kup ( a r g v [ 3 ] ) ; i n t temp = a t o i ( a r g v [ 2 ] ) ; i f ( temp == n I f a c e s ) { n I f a c e s ++; } i f q u e u e l i s t [ temp ] = i f q ; i f ( i f q u e u e l i s t [ temp ] ) { r e t u r n TCL OK ; } else { r e t u r n TCL ERROR; } } i f ( strcmp ( a r g v [ 1 ] , t a r g e t ) == 0 ) { i n t temp = a t o i ( a r g v [ 2 ] ) ; i f ( temp == n I f a c e s ) { n I f a c e s ++; } t a r g e t l i s t [ temp ] = ( NsObject ) T c l O b j e c t : : lo o kup ( a r g v [ 3 ] ) ; i f ( t a r g e t l i s t [ temp ] ) { r e t u r n TCL OK ; } else { r e t u r n TCL ERROR; } } }
With all the previous changes it is indeed possible to create multi-interface nodes. The next thing is to add the required intelligence within the routing agent implementation, so that it can decide the interface which needs to transmit each packet. On the other hand, it is also well known that the use of broadcast transmissions is quite relevant in routing protocols for ad hoc networks (e.g. during the Route Discovery process); when there is more than one available interface, a broadcast packet (typically a Route Request ) needs to be transmitted through all the interfaces a node has. Listing 5.3 shows how this can be accomplished. We use a loop to send the packet through all the interfaces, adding some random time to avoid collisions. Note that for each of the interfaces a copy of the original packet is sent, since their route through the simulator entities will be dierent onwards. In addition, to preserve 37
the traditional behavior of the simulator, the new code is only executed if the multi-interface extension has been initialized from the scenario script, i.e. nIfaces = 0. If such is not the case, the routing agent performs the broadcast transmission as it would have done without the extension. Listing 5.3: (routingAgent.cc) Sending a broadcast packet
i f ( nIfaces ) { f o r ( i n t i = 0 ; i < n I f a c e s ; i ++){ Packet p co py = pkt >copy ( ) ; S c h e d u l e r : : i n s t a n c e ( ) . s c h e d u l e ( t a r g e t l i s t [ i ] , p copy , JITTER ) ; } Packet : : f r e e ( pkt ) else { S c h e d u l e r : : i n s t a n c e ( ) . s c h e d u l e ( t a r g e t , pkt , JITTER) ; }
On the other hand, for unicast transmissions, an index Iface (see Listing 5.4) is used so as to select the appropriate target (i.e. the LL entity of the interface the packet needs to be sent to). This value must be carefully selected and it needs to be kept at the routing table, together with the rest of information that needs to be therein (see Section 5.3). In this sense, the method used to create a new routing table entry needs to be updated so as to indicate the output interface that has to be used to reach the destination. It obviously belongs to the range of interfaces that are used by the particular node (Iface [0, nIfaces 1]). Note that, as was done for the broadcast case, we apply the multi-interface extension only when the user had previously initialized such extension. Listing 5.4: (routingAgent.cc) Sending a unicast packet
i f ( nIfaces ) { S c h e d u l e r : : i n s t a n c e ( ) . s c h e d u l e ( t a r g e t l i s t [ I f a c e ] , pkt , 0 ) ; } else { S c h e d u l e r : : i n s t a n c e ( ) . s c h e d u l e ( t a r g e t , pkt , 0 ) ; }
The challenge is to be able to associate the interface with the Iface index, e.g. when a new entry has to be introduced within the route table. In order to accomplish this, Listing 5.5 shows the code that needs to be used. cmn->iface() stores the address of the incoming interface, as discussed in Section 4.4; on the other hand the second term is the address of the rst interface of the node. Taking advantage from the fact that the interfaces are gradually added (see Chapter 6), this simple expression allows us to easily refer to the appropriate interface. If the multi-interface extension is not being used, we assign the index a non-valid value. Listing 5.5: (routingAgent.cc) Getting the interface index
i f ( nIfaces ) { I f a c e = cmnh> i f a c e ( ) ((Mac ) i f q u e u e l i s t [0] > t a r g e t ( ) )>addr ( ) ; } else {
38
I f a c e = 1; }
5.3
Changes on the Route Table
We have just seen how the routing agent is able to ascertain the interface from which any packet had been received. This information must be stored in the route table entry for the corresponding destination so that it can be used on future transmissions; that is to say, in order to route a packet to a destination it is not enough to know the next hop, but the routing agent must be aware of which output interface it needs to use so as to reach it. Hence, a new variable interface must be added to the route entry denition. This variable stores the index for the corresponding interface, so as to be able to refer to the appropriate array member, as has been previously explained. Using the corresponding method the entry is created or updated, including this information for multi-interface support in the route table.
5.4
Illustrative example: AODV
One of the most used routing protocols within the Network Simulator framework is AODV. The main reason for this is that it is included, by default, in the dierent ns-2 distributions. It is sensible, thus, to compile all the changes which are needed in such routing protocol, following the guidelines provided before in this section.
5.4.1
Changes in aodv.h
Following Listing 5.1, there are two changes which are needed in the AODV class declaration. First, we need to dene a new constant MAX IF, as shown in Listing 5.6, since it is used afterwards (see Listing 5.7) to declare the arrays which handle the list of targets and interface queues. Listing 5.6: (aodv.h) Declaring the MAX IF constant
// We d e c l a r e t h e maximum number o f i n t e r f a c e s #d e f i n e MAX IF 11
Once we have dened the new constant we need to add the new members at the end of the AODV class declaration, as shown in Listing 5.7. Listing 5.7: (aodv.h) New members of the AODV class
... / A p o i n t e r t o t h e network i n t e r f a c e queue t h a t s i t s between t h e c l a s s i f i e r and t h e l i n k l a y e r . / PriQueue ifqueue ; /
39
Lo g g ing s t u f f / void l o g l i n k d e l ( nsaddr t dst ) ; void l o g l i n k b r o k e ( Packet p ) ; void l o g l i n k k e p t ( nsaddr t dst ) ; / f o r p a s s i n g p a c k e t s up t o a g e n t s / P o r t C l a s s i f i e r dmux ;
// New members required for the multii n t e r f a c e extension i nt nIfaces ; NsObject t a r g e t l i s t [MAX IF] ; PriQueue i f q u e u e l i s t [MAX IF] ; };
Another change which needs to be applied in this le deals with how the routing table needs to be handled. As was explained before, each routing table entry must also incorporate an index so that the routing agent is able to identify the interface through which the packet needs to be forwarded; in this case, we need to change the way the rt update is called, as shown in Listing 5.8. Listing 5.8: (aodv.h) New members of the AODV class
... / Route Table Management / void r t r e s o l v e ( Packet p ) ; void rt update ( aodv rt entry rt , u i n t 3 2 t seqnum , u i n t 1 6 t m e t r i c , n s a d d r t nexthop , do uble e x p i r e t i m e , u i nt8 t interface ) ; void r t do wn ( a o d v r t e n t r y r t ) ; void l o c a l r t r e p a i r ( a o d v r t e n t r y r t , Packet p) ; public : void void protected : void void Packet ... r t l l f a i l e d ( Packet p ) ; h a n d l e l i n k f a i l u r e ( nsaddr t id ) ; rt purge ( void ) ; enque ( a o d v r t e n t r y r t , Packet p ) ; deque ( a o d v r t e n t r y r t ) ;
5.4.2
Changes in aodv.cc
In this case we need to apply those changes which are depicted in Listings 5.2, 5.3, 5.4, 5.5. Some of them need to be applied in more than one AODV method, while there are other 40
additional places in which the interface with the routing table needs to be adjusted accordingly. It is also convenient to ensure that the number of interfaces per node is initialized in the constructor, so as to maintain the legacy behavior of the AODV protocol. This can be seen in Listing 5.9. Listing 5.9: (aodv.cc) Changes on the AODV constructor
AODV : :AODV( n s a d d r t i d ) : Agent (PT AODV) , btimer ( t h i s ) , htimer ( t h i s ) , ntimer ( t h i s ) , r t i m e r ( t h i s ) , l r t i m e r ( t h i s ) , r queue ( ) { index = id ; seqno = 2 ; bid = 1 ; LIST INIT(&nbhead ) ; LIST INIT(& bihea d ) ; logtarget = 0; ifqueue = 0; nIfaces = 0; }
Before describing the changes which are required on those methods which deal with the transmission and reception of packets, the command method needs to be modied, in order to adapt it to the new architecture, as it was previously discussed in Listing 5.2. As can be seen in Listing 5.10, the modications are very much the same for the case of the AODV agent. Listing 5.10: (aodv.cc) Changes on the command method
int AODV : : command( i n t a r g c , c o n s t cha r c o n s t a r g v ) { i f ( a r g c == 2 ) { Tcl& t c l = Tcl : : i n s t a n c e ( ) ; i f ( s t r n c a s e c m p ( a r g v [ 1 ] , i d , 2 ) == 0 ) { t c l . r e s u l t f ( %d , i n d e x ) ; r e t u r n TCL OK ; } i f ( s t r n c a s e c m p ( a r g v [ 1 ] , s t a r t , 2 ) == 0 ) { btimer . ha ndle ( ( Event ) 0 ) ; #i f n d e f AODV LINK LAYER DETECTION htimer . ha ndle ( ( Event ) 0 ) ; ntimer . ha ndle ( ( Event ) 0 ) ; #e n d i f // LINK LAYER DETECTION r t i m e r . ha ndle ( ( Event ) 0 ) ; r e t u r n TCL OK ; } }
41
e l s e i f ( a r g c == 3 ) { i f ( strcmp ( a r g v [ 1 ] , i n d e x ) == 0 ) { index = a t o i ( argv [ 2 ] ) ; r e t u r n TCL OK ; } e l s e i f ( strcmp ( a r g v [ 1 ] , l o g t a r g e t ) == 0 | | strcmp ( a r g v [ 1 ] , t r a c e t a r g e t ) == 0 ) { l o g t a r g e t = ( Trace ) T c l O b j e c t : : lo o kup ( a r g v [ 2 ] ) ; i f ( l o g t a r g e t == 0 ) r e t u r n TCL ERROR; r e t u r n TCL OK ; } e l s e i f ( strcmp ( a r g v [ 1 ] , drop t a r g e t ) == 0 ) { i n t s t a t = r queue . command( a r g c , a r g v ) ; i f ( s t a t != TCL OK) r e t u r n s t a t ; r e t u r n Agent : : command( a r g c , a r g v ) ; } e l s e i f ( strcmp ( a r g v [ 1 ] , i f queue ) == 0 ) { i f q u e u e = ( PriQueue ) T c l O b j e c t : : lo o kup ( a r g v [ 2 ] ) ; i f ( i f q u e u e == 0 ) r e t u r n TCL ERROR; r e t u r n TCL OK ; } e l s e i f ( strcmp ( a r g v [ 1 ] , po r t dmux ) == 0 ) { dmux = ( P o r t C l a s s i f i e r ) T c l O b j e c t : : lo o kup ( a r g v [ 2 ] ) ; i f ( dmux == 0 ) { f p r i n t f ( s t d e r r , %s : %s lo o kup o f %s f a i l e d \ n , FILE , argv [ 1 ] , argv [ 2 ] ) ; r e t u r n TCL ERROR; } r e t u r n TCL OK ; } } e l s e i f ( argc == 4) { i f (strcmp ( argv [ 1 ] , i f queue)==0) { PriQueue i f q = (PriQueue ) TclObject : : lookup( argv [ 3 ] ) ; i nt temp = atoi ( argv [ 2 ] ) ; i f (temp == nIfaces ) { nIfaces++; } i f q u e u e l i s t [ temp ] = i f q ; i f ( i f q u e u e l i s t [ temp ] ) { return TCL OK; } else { return TCL ERROR; } } i f (strcmp ( argv [ 1 ] , target ) == 0) { i nt temp = atoi ( argv [ 2 ] ) ; i f (temp == nIfaces ) {
42
nIfaces++; } t a r g e t l i s t [ temp ] = (NsObject ) TclObject : : lookup ( argv [ 3 ] ) ; i f ( t a r g e t l i s t [ temp ] ) { return TCL OK; } else { return TCL ERROR; } } } r e t u r n Agent : : command( a r g c , a r g v ) ; }
Listing 5.3 has to be used whenever the AODV needs to send a broadcast packet, which happens, as far as we can tell, in the following methods of the aodv.cc le: sendRequest, sendError and sendHello. The corresponding changes are highlighted in the following listings. Listing 5.11: (aodv.cc) Changes on the sendRequest method
void AODV : : sendRequest ( n s a d d r t d s t ) { // A l l o c a t e a RREQ p a c k e t Packet p = Packet : : a l l o c ( ) ; s t r u c t hdr cmn ch = HDR CMN( p ) ; s t r u c t h d r i p i h = HDR IP ( p ) ; s t r u c t h d r a o d v r e q u e s t r q = HDR AODV REQUEST( p ) ; aodv rt entry rt = rtable . rt lookup ( dst ) ; assert ( rt ) ; / Rate l i m i t s e n d i n g o f Route Requests . We a r e ver y c o n s e r v a t i v e about s e n d i n g out r o u t e r e q u e s t s . / i f ( r t > r t f l a g s == RTF UP) { a s s e r t ( r t > r t h o p s != INFINITY2) ; Packet : : f r e e ( ( Packet ) p ) ; return ; } i f ( r t > r t r e q t i m e o u t > CURRENT TIME) { Packet : : f r e e ( ( Packet ) p ) ; return ; } // r t r e q c n t i s t h e no . o f t i m e s we d i d network wide b r o a d c a s t // RREQ RETRIES i s t h e maximum number we w i l l a l l o w b e f o r e // g o i n g t o a l o n g timeo ut .
43
i f ( r t > r t r e q c n t > RREQ RETRIES) { r t > r t r e q t i m e o u t = CURRENT TIME + MAX RREQ TIMEOUT; r t > r t r e q c n t = 0 ; Packet b u f p k t ; w h i l e ( ( b u f p k t = r queue . deque ( r t > r t d s t ) ) ) { drop ( b u f p k t , DROP RTR NO ROUTE) ; } Packet : : f r e e ( ( Packet ) p ) ; return ; } #i f d e f DEBUG f p r i n t f ( s t d e r r , (%2d ) %2d s e n d i n g Route Request , d s t : %d \ n , ++r o u t e r e q u e s t , index , r t > r t d s t ) ; #e n d i f // DEBUG // Determine t h e TTL t o be used t h i s time . // Dynamic TTL e v a l u a t i o n SRD r t > r t r e q l a s t t t l = max( r t > r t r e q l a s t t t l , r t > rt last hop count ) ; i f ( 0 == r t > r t r e q l a s t t t l ) { // f i r s t time quer y b r o a d c a s t ih > t t l = TTL START; } else { // Expanding r i n g s e a r c h . i f ( r t > r t r e q l a s t t t l < TTL THRESHOLD) ih > t t l = r t > r t r e q l a s t t t l + TTL INCREMENT ; else { // network wide b r o a d c a s t ih > t t l = NETWORK DIAMETER; r t > r t r e q c n t += 1 ; } } // remember t h e TTL used f o r t h e next time r t > r t r e q l a s t t t l = ih > t t l ; // // // // PerHopTime i s t h e The f a c t o r 2 . 0 i s Also no te t h a t we done network wide r o u n d t r i p time per hop f o r r o u t e r e q u e s t s . j u s t t o be s a f e . . SRD 5/22/99 a r e making t i m e o u t s t o be l a r g e r i f we have broadcast before . PerHopTime ( r t ) ;
r t > r t r e q t i m e o u t = 2 . 0 ( do uble ) ih > t t l i f ( r t > r t r e q c n t > 0 ) r t > r t r e q t i m e o u t = r t > r t r e q c n t ; r t > r t r e q t i m e o u t += CURRENT TIME;
// Don t l e t t h e timeo ut t o be t o o l a r g e , however . . SRD 6/8/99 i f ( r t > r t r e q t i m e o u t > CURRENT TIME + MAX RREQ TIMEOUT) r t > r t r e q t i m e o u t = CURRENT TIME + MAX RREQ TIMEOUT;
44
r t > r t e x p i r e = 0 ; #i f d e f DEBUG f p r i n t f ( s t d e r r , (%2d ) %2d s e n d i n g Route Request , d s t : %d , t o u t %f ms \ n , ++r o u t e r e q u e s t , index , r t > r t d s t , r t > r t r e q t i m e o u t CURRENT TIME) ; #e n d i f // DEBUG
// F i l l out t h e i d p a c k e t // ch>u i d ( ) = 0 ; ch>ptype ( ) = PT AODV; ch> s i z e ( ) = IP HDR LEN + rq > s i z e ( ) ; ch> i f a c e ( ) = 2; ch> e r r o r ( ) = 0 ; ch>a d d r t y p e ( ) = NS AF NONE ; // AODV hack ch>p r e v h o p = i n d e x ; ih >sa ddr ( ) ih >daddr ( ) ih > s p o r t ( ) ih >dpo r t ( ) = = = = index ; IP BROADCAST; RT PORT; RT PORT;
// F i l l up some more f i e l d s . rq > r q t y p e = AODVTYPE RREQ; rq >r q h o p c o u n t = 1 ; rq > r q b c a s t i d = b i d++; rq > r q d s t = d s t ; rq > r q d s t s e q n o = ( r t ? r t > r t s e q n o : 0 ) ; rq > r q s r c = i n d e x ; seqno += 2 ; a s s e r t ( ( seqno %2) == 0 ) ; rq > r q s r c s e q n o = seqno ; rq >r q timesta mp = CURRENT TIME; i f ( nIfaces ) { for ( i nt i =0; i <nIfaces ; i++) { Packet p copy = p >copy () ; Scheduler : : instance () . schedule ( t a r g e t l i s t [ i ] , p copy , 0. 0) ; } Packet : : f r e e (p) ; } else { Scheduler : : instance () . schedule ( target , p , 0. 0) ; } }
Listing 5.12: (aodv.cc) Changes on the sendError method

void
45
AODV : : s e n d E r r o r ( Packet p , b o o l j i t t e r ) { s t r u c t hdr cmn ch = HDR CMN( p ) ; s t r u c t h d r i p i h = HDR IP ( p ) ; s t r u c t h d r a o d v e r r o r r e = HDR AODV ERROR( p ) ; #i f d e f ERROR f p r i n t f ( s t d e r r , s e n d i n g E r r o r from %d a t %.2 f \ n , index , S c h e d u l e r : : instance () . clock () ) ; #e n d i f // DEBUG r e > r e t y p e = AODVTYPE RERR; // r e > r e s e r v e d [ 0 ] = 0 x00 ; r e > r e s e r v e d [ 1 ] = 0 x00 ; // DestCount and l i s t o f u n r e a c h a b l e d e s t i n a t i o n s a r e a l r e a d y filled // ch>u i d ( ) = 0 ; ch>ptype ( ) = PT AODV; ch> s i z e ( ) = IP HDR LEN + r e > s i z e ( ) ; ch> i f a c e ( ) = 2; ch> e r r o r ( ) = 0 ; ch>a d d r t y p e ( ) = NS AF NONE ; ch>n e x t h o p = 0 ; ch>p r e v h o p = i n d e x ; // AODV hack ch> d i r e c t i o n ( ) = hdr cmn : :DOWN; // impo r ta nt : change t h e packet s d i r e c t i o n ih >sa ddr ( ) = ih >daddr ( ) = ih > s p o r t ( ) = ih >dpo r t ( ) = ih > t t l = 1 ; index ; IP BROADCAST; RT PORT; RT PORT;
if ( jitter ) { i f ( nIfaces ) { for ( i nt i =0; i <nIfaces ; i++) { Packet p copy = p >copy () ; Scheduler : : instance () . schedule ( t a r g e t l i s t [ i ] , p copy , 0.01 Random : : uniform () ) ; } Packet : : f r e e (p) ; } else { Scheduler : : instance () . schedule ( target , p , 0.01 Random : : uniform() ) ; } } else { i f ( nIfaces ) { for ( i nt i =0; i <nIfaces ; i++) { >copy () ; Packet p copy = p Scheduler : : instance () . schedule ( t a r g e t l i s t [ i ] , p copy , 0. 0) ; }
46
Packet : : f r e e (p) ; } else { Scheduler : : instance () . schedule ( target , p , 0. 0) ; } } }
Listing 5.13: (aodv.cc) Changes on the sendHello method

void AODV : : s e n d H e l l o ( ) { Packet p = Packet : : a l l o c ( ) ; s t r u c t hdr cmn ch = HDR CMN( p ) ; s t r u c t h d r i p i h = HDR IP ( p ) ; s t r u c t h d r a o d v r e p l y rh = HDR AODV REPLY( p ) ; #i f d e f DEBUG f p r i n t f ( s t d e r r , s e n d i n g H e l l o from %d a t %.2 f \ n , index , S c h e d u l e r : : instance () . clock () ) ; #e n d i f // DEBUG rh >r p t y p e = AODVTYPE HELLO; // rh > r p f l a g s = 0 x00 ; rh >r p h o p c o u n t = 1 ; rh > r p d s t = i n d e x ; rh > r p d s t s e q n o = seqno ; rh > r p l i f e t i m e = ( 1 + ALLOWED HELLO LOSS) HELLO INTERVAL; // ch>u i d ( ) = 0 ; ch>ptype ( ) = PT AODV; ch> s i z e ( ) = IP HDR LEN + rh > s i z e ( ) ; ch> i f a c e ( ) = 2; ch> e r r o r ( ) = 0 ; ch>a d d r t y p e ( ) = NS AF NONE ; ch>p r e v h o p = i n d e x ; // AODV hack ih >sa ddr ( ) = ih >daddr ( ) = ih > s p o r t ( ) = ih >dpo r t ( ) = ih > t t l = 1 ; index ; IP BROADCAST; RT PORT; RT PORT;
i f ( nIfaces ) { for ( i nt i =0; i <nIfaces ; i++) { Packet p copy = p >copy () ; Scheduler : : instance () . schedule ( t a r g e t l i s t [ i ] , p copy , 0. 0) ; } Packet : : f r e e (p) ; }
47
else { Scheduler : : instance () . schedule ( target , p , 0. 0) ; } }
Additionally we also need to take into account the changes which are required whenever a unicast transmission needs to be performed (see Listing 5.4). For the AODV case, these included the sendReply method and the forward method, which also includes some broadcast mechanisms. Note that in both cases, we change the Iface index with the one which is provided by the routing table entry. Listing 5.14: (aodv.cc) Changes on the sendReply method
void AODV : : sendReply ( n s a d d r t i p d s t , u i n t 3 2 t hop count , n s a d d r t r pdst , u i n t 3 2 t r pseq , u i n t 3 2 t l i f e t i m e , do uble timestamp ) { Packet p = Packet : : a l l o c ( ) ; s t r u c t hdr cmn ch = HDR CMN( p ) ; s t r u c t h d r i p i h = HDR IP ( p ) ; s t r u c t h d r a o d v r e p l y rp = HDR AODV REPLY( p ) ; aodv rt entry rt = rtable . rt lookup ( ipdst ) ; #i f d e f DEBUG f p r i n t f ( s t d e r r , s e n d i n g Reply from %d a t %.2 f \ n , index , S c h e d u l e r : : instance () . clock () ) ; #e n d i f // DEBUG assert ( rt ) ; rp >r p t y p e = AODVTYPE RREP; // rp > r p f l a g s = 0 x00 ; rp >r p h o p c o u n t = ho p co unt ; rp > r p d s t = r p d s t ; rp > r p d s t s e q n o = r p s e q ; rp > r p s r c = i n d e x ; rp > r p l i f e t i m e = l i f e t i m e ; rp >r p timesta mp = timestamp ; // ch>u i d ( ) = 0 ; ch>ptype ( ) = PT AODV; ch> s i z e ( ) = IP HDR LEN + rp > s i z e ( ) ; ch> i f a c e ( ) = 2; ch> e r r o r ( ) = 0 ; ch>a d d r t y p e ( ) = NS AF INET ; ch>n e x t h o p = r t >r t n e x t h o p ; ch>p r e v h o p = i n d e x ; // AODV hack ch> d i r e c t i o n ( ) = hdr cmn : :DOWN; ih >sa ddr ( ) = i n d e x ; ih >daddr ( ) = i p d s t ; ih > s p o r t ( ) = RT PORT; ih >dpo r t ( ) = RT PORT; ih > t t l = NETWORK DIAMETER;
48
i f ( nIfaces ) { Scheduler : : instance () . schedule ( t a r g e t l i s t [ rt >r t i n t e r f a c e ] , p , 0) ; } else { Scheduler : : instance () . schedule ( target , p , 0) ; } }
Listing 5.15: (aodv.cc) Changes on the forward method

void AODV : : f o r w a r d ( a o d v r t e n t r y r t , Packet p , do uble d e l a y ) { s t r u c t hdr cmn ch = HDR CMN( p ) ; s t r u c t h d r i p i h = HDR IP ( p ) ; i f ( ih > t t l == 0 ) {
#i f d e f DEBUG f p r i n t f ( s t d e r r , %s : c a l l i n g drop ( ) \ n , #e n d i f // DEBUG drop ( p , DROP RTR TTL) ; return ; }
PRETTY FUNCTION ) ;
i f ( ch>ptype ( ) != PT AODV && ch> d i r e c t i o n ( ) == hdr cmn : : UP && ( ( u i n t 3 2 t ) ih >daddr ( ) == IP BROADCAST) | | ( ih >daddr ( ) == h e r e . a d d r ) ) { dmux >r e c v ( p , 0 ) ; return ; } i f ( rt ) { a s s e r t ( r t > r t f l a g s == RTF UP) ; r t > r t e x p i r e = CURRENT TIME + ACTIVE ROUTE TIMEOUT; ch>n e x t h o p = r t >r t n e x t h o p ; ch>a d d r t y p e ( ) = NS AF INET ; ch> d i r e c t i o n ( ) = hdr cmn : :DOWN; // impo r ta nt : change t h e packet s d i r e c t i o n } e l s e { // i f i t i s a b r o a d c a s t p a c k e t // a s s e r t ( ch>ptype ( ) == PT AODV) ; // maybe a d i f f pkt type l i k e gaf a s s e r t ( ih >daddr ( ) == ( n s a d d r t ) IP BROADCAST) ; ch>a d d r t y p e ( ) = NS AF NONE ; ch> d i r e c t i o n ( ) = hdr cmn : :DOWN; // impo r ta nt : change t h e packet s d i r e c t i o n } i f ( ih >daddr ( ) == ( n s a d d r t ) IP BROADCAST) { // I f i t i s a b r o a d c a s t p a c k e t
49
a s s e r t ( r t == 0 ) ; i f ( ch>ptype ( ) == PT AODV) { / J i t t e r t h e s e n d i n g o f AODV b r o a d c a s t p a c k e t s by 10ms / i f ( nIfaces ) { for ( i nt i =0; i <nIfaces ; i++) { Packet p copy = p >copy () ; Scheduler : : instance () . schedule ( t a r g e t l i s t [ i ] , p copy , 0.01 Random : : uniform () ) ; } Packet : : f r e e (p) ; } else { Scheduler : : instance () . schedule ( target , p , 0.01 Random : : uniform () ) ; } } else { i f ( nIfaces ) { for ( i nt i =0; i <nIfaces ; i++) { Packet p copy = p >copy () ; Scheduler : : instance () . schedule ( t a r g e t l i s t [ i ] , p copy , 0. 0) ; } Packet : : f r e e (p) ; } else { Scheduler : : instance () . schedule ( target , p , 0. 0) ; } } } e l s e { // Not a b r o a d c a s t p a c k e t i f ( delay > 0.0) { i f ( nIfaces ) { Scheduler : : instance () . schedule ( t a r g e t l i s t [ rt > r t i n t e r f a c e ] , p , delay ) ; } else { Scheduler : : instance () . schedule ( target , p , delay ) ; } }else { // Not a b r o a d c a s t pa cket , no dela y , send i m m e d i a t e l y i f ( nIfaces ) { Scheduler : : instance () . schedule ( t a r g e t l i s t [ rt > r t i n t e r f a c e ] , p , 0) ; } else { Scheduler : : instance () . schedule ( target , p , 0) ; } } } }
The last group of changes need to be made in order to correctly manage the routing table. In particular, and as it was already described before (see Listing 5.5), whenever we add an entry to the routing table we must include the interface which corresponds to such entry. We 50
need to make the corresponding changes in the recvRequest and recvReply methods (see Listings 5.16 and 5.17, respectively). Note that we also need to modify the handling of the routing table, since we have to include the interface as an argument to the rt update method. Listing 5.16: (aodv.cc) Changes on the recvRequest method
void AODV : : r e c v R e q u e s t ( Packet p ) { s t r u c t h d r i p i h = HDR IP ( p ) ; s t r u c t hdr cmn ch = HDR CMN( p ) ; s t r u c t h d r a o d v r e q u e s t r q = HDR AODV REQUEST( p ) ; u i nt8 t I f a c e ; aodv rt entry rt ;
/ Drop i f : I m t h e s o u r c e I r e c e n t l y hea r d t h i s r e q u e s t . / //DBG INFO( Node %d r e c e i v e s r e q u e s t from %d , addr ( ) , rq > r q s r c ) ; i f ( rq > r q s r c == i n d e x ) { #i f d e f DEBUG f p r i n t f ( s t d e r r , %s : g o t my own REQUEST\ n , FUNCTION ) ; #e n d i f // DEBUG Packet : : f r e e ( p ) ; return ; } i f ( i d l o o k u p ( rq > r q s r c , rq > r q b c a s t i d ) ) { #i f d e f DEBUG f p r i n t f ( s t d e r r , %s : d i s c a r d i n g r e q u e s t \ n , #e n d i f // DEBUG Packet : : f r e e ( p ) ; return ; } / Cache t h e b r o a d c a s t ID / i d i n s e r t ( rq > r q s r c , rq > r q b c a s t i d ) ;
FUNCTION ) ;
/ We a r e e i t h e r g o i n g t o f o r w a r d t h e REQUEST o r g e n e r a t e a REPLY. B e f o r e we do a nything , we make s u r e t h a t t h e REVERSE route i s in the route t a b l e . / a o d v r t e n t r y r t 0 ; // r t 0 i s t h e r e v e r s e r o u t e
51
r t 0 = r t a b l e . r t l o o k u p ( rq > r q s r c ) ; i f ( r t 0 == 0 ) { / i f not i n t h e r o u t e t a b l e / // c r e a t e an e n t r y f o r t h e r e v e r s e r o u t e . r t 0 = r t a b l e . r t a d d ( rq > r q s r c ) ; } r t 0 > r t e x p i r e = max( r t 0 > r t e x p i r e , (CURRENT TIME + REV ROUTE LIFE) ) ; i f ( ( rq > r q s r c s e q n o > r t 0 > r t s e q n o ) | | ( ( rq > r q s r c s e q n o == r t 0 > r t s e q n o ) && ( rq >r q h o p c o u n t < r t 0 > r t h o p s ) ) ) { // I f we have a f r e s h e r s e q no . o r l e s s e r #hops f o r t h e // same s e q no . , update t h e r t e n t r y . E l s e don t b o t h e r . i f ( nIfaces ) { I f a c e = ch >i f a c e () ((Mac ) i f q u e u e l i s t [0] > target () )>addr () ; } else { I f a c e = 1; } r t u p d a t e ( r t 0 , rq > r q s r c s e q n o , rq >r q h o p c o u n t , ih >sa ddr ( ) , max( r t 0 > r t e x p i r e , (CURRENT TIME + REV ROUTE LIFE) ) , Iface ) ; i f ( r t 0 > r t r e q t i m e o u t > 0 . 0 ) { // Reset t h e s o f t s t a t e and // S e t e x p i r y time t o CURRENT TIME + ACTIVE ROUTE TIMEOUT // This i s b e c a u s e r o u t e i s used i n t h e f o r w a r d d i r e c t i o n , // but o n l y s o u r c e s g e t b e n e f i t e d by t h i s change r t 0 > r t r e q c n t = 0 ; r t 0 > r t r e q t i m e o u t = 0 . 0 ; r t 0 > r t r e q l a s t t t l = rq >r q h o p c o u n t ; r t 0 > r t e x p i r e = CURRENT TIME + ACTIVE ROUTE TIMEOUT; } / Find out whether any b u f f e r e d p a c k e t can b e n e f i t from t h e reverse route . May need some change i n t h e f o l l o w i n g co de Mahesh 09/11/99 / a s s e r t ( r t 0 > r t f l a g s == RTF UP) ; Packet b u f f e r e d p k t ; w h i l e ( ( b u f f e r e d p k t = r queue . deque ( r t 0 > r t d s t ) ) ) { i f ( r t 0 && ( r t 0 > r t f l a g s == RTF UP) ) { a s s e r t ( r t 0 > r t h o p s != INFINITY2) ; f o r w a r d ( r t 0 , b u f f e r e d p k t , NO DELAY) ; } } } // End f o r p u t t i n g r e v e r s e r o u t e i n r t t a b l e
52
/ We have ta ken c a r e o f t h e r e v e r s e r o u t e s t u f f . Now s e e whether we can send a r o u t e r e p l y . / r t = r t a b l e . r t l o o k u p ( rq > r q d s t ) ; // F i r s t check i f I am t h e d e s t i n a t i o n . . i f ( rq > r q d s t == i n d e x ) { #i f d e f DEBUG f p r i n t f ( s t d e r r , %d %s : d e s t i n a t i o n s e n d i n g r e p l y \ n , index , FUNCTION ) ; #e n d i f // DEBUG
// J u s t t o be s a f e , I use t h e max . Somebody may have // i n c r e m e n t e d t h e d s t seqno . seqno = max( seqno , rq > r q d s t s e q n o ) +1; i f ( seqno %2) seqno++; sendReply ( rq > r q s r c , 1, index , seqno , MY ROUTE TIMEOUT, rq >r q timesta mp ) ; Packet : : f r e e ( p ) ; } // I am not t h e d e s t i n a t i o n , but I may have a f r e s h enough r o u t e . e l s e i f ( r t && ( r t > r t h o p s != INFINITY2) && ( r t > r t s e q n o >= rq > r q d s t s e q n o ) ) { // a s s e r t ( r t > r t f l a g s == RTF UP) ; a s s e r t ( rq > r q d s t == r t > r t d s t ) ; // i s t h e seqno even ? // a s s e r t ( ( r t > r t s e q n o %2) == 0 ) ; sendReply ( rq > r q s r c , r t > r t h o p s + 1 , rq >r q d s t , r t >r t s e q n o , ( u i n t 3 2 t ) ( r t > r t e x p i r e CURRENT TIME) , // r t > r t e x p i r e CURRENT TIME, rq >r q timesta mp ) ; // I n s e r t nextho ps t o RREQ s o u r c e and RREQ d e s t i n a t i o n i n t h e // p r e c u r s o r l i s t s o f d e s t i n a t i o n and s o u r c e r e s p e c t i v e l y r t > p c i n s e r t ( r t 0 >r t n e x t h o p ) ; // nexthop t o RREQ s o u r c e r t 0 > p c i n s e r t ( r t >r t n e x t h o p ) ; // nexthop t o RREQ d e s t i n a t i o n #i f d e f RREQ GRAT RREP // // // // // // IP D e s t i n a t i o n Hop Count Dest IP Address Dest Sequence Num Lifetime timestamp
53
sendReply ( rq >r q d s t , rq >r q h o p c o u n t , rq > r q s r c , rq > r q s r c s e q n o , ( u i n t 3 2 t ) ( r t > r t e x p i r e CURRENT TIME) , // r t > r t e x p i r e CURRENT TIME, rq >r q timesta mp ) ; #e n d i f // TODO: send g r a t RREP t o d s t i f G f l a g s e t i n RREQ u s i n g rq > r q s r c s e q n o , rq >rq hop counT // DONE: I n c l u d e d g r a t u i t o u s r e p l i e s t o be s e n t a s per IETF aodv d r a f t s p e c i f i c a t i o n . As o f now , G f l a g has not been d y n a m i c a l l y used and i s a lwa ys s e t o r r e s e t i n aodvp a c k e t . h Anant Utg ika r , 0 9 / 1 6 / 0 2 . Packet : : f r e e ( p ) ; } / Can t r e p l y . So f o r w a r d t h e Route Request / else { ih >sa ddr ( ) = i n d e x ; ih >daddr ( ) = IP BROADCAST; rq >r q h o p c o u n t += 1 ; // Maximum s e q u e n c e number s e e n en r o u t e i f ( r t ) rq > r q d s t s e q n o = max( r t >r t s e q n o , rq > r q d s t s e q n o ) ; f o r w a r d ( ( a o d v r t e n t r y ) 0 , p , DELAY) ; } }
Listing 5.17: (aodv.cc) Changes on the recvReply method

void AODV : : r e c v R e p l y ( Packet p ) { s t r u c t hdr cmn ch = HDR CMN( p ) ; s t r u c t h d r i p i h = HDR IP ( p ) ; s t r u c t h d r a o d v r e p l y rp = HDR AODV REPLY( p ) ; u i nt8 t I f a c e ; aodv rt entry rt ; cha r s u p p r e s s r e p l y = 0 ; do uble d e l a y = 0 . 0 ; #i f d e f DEBUG f p r i n t f ( s t d e r r , %d %s : r e c e i v e d a REPLY\ n , index , ); #e n d i f // DEBUG
FUNCTION
54
Got a r e p l y . So r e s e t t h e s o f t s t a t e ma inta ined f o r r o u t e r e q u e s t s i n t h e r e q u e s t t a b l e . We don t r e a l l y have have a s e p a r a t e r e q u e s t t a b l e . I t i s j u s t a p a r t o f t h e routing table i t s e l f . / // Note t h a t r p d s t i s t h e d e s t o f t h e da ta p a c k e t s , not t h e // t h e d e s t o f t h e r e p l y , which i s t h e s r c o f t h e da ta p a c k e t s . //DBG INFO( R e c e i v e r e p l y from ih > s r c ( ) ) ; r t = r t a b l e . r t l o o k u p ( rp > r p d s t ) ; / I f I don t have a r t e n t r y t o t h i s h o s t . . . a dding / i f ( r t == 0 ) { r t = r t a b l e . r t a d d ( rp > r p d s t ) ; } / Add a f o r w a r d r o u t e t a b l e e n t r y . . . h e r e I am f o l l o w i n g P e r k i n s Royer AODV pa per a lmo st l i t e r a l l y SRD 5/99 / // newer r o u t e i f ( ( r t > r t s e q n o < rp > r p d s t s e q n o ) | | ( ( r t > r t s e q n o == rp > r p d s t s e q n o ) && ( r t > r t h o p s > rp >r p h o p c o u n t ) ) ) { // s h o r t e r o r b e t t e r route // Update t h e r t e n t r y i f ( nIfaces ) { I f a c e = ch >i f a c e () ((Mac ) i f q u e u e l i s t [0] > target () )>addr () ; } else { I f a c e = 1; } r t u p d a t e ( r t , rp > r p d s t s e q n o , rp >r p h o p c o u n t , rp > r p s r c , CURRENT TIME + rp > r p l i f e t i m e , I f a c e ) ; // r e s e t t h e s o f t s t a t e r t > r t r e q c n t = 0 ; r t > r t r e q t i m e o u t = 0 . 0 ; r t > r t r e q l a s t t t l = rp >r p h o p c o u n t ; i f ( ih >daddr ( ) == i n d e x ) { // I f I am t h e o r i g i n a l s o u r c e // Update t h e r o u t e d i s c o v e r y l a t e n c y s t a t i s t i c s // rp >r p timesta mp i s t h e time o f r e q u e s t o r i g i n a t i o n r t > r t d i s c l a t e n c y [ ( u n s i g n e d cha r ) r t > h i s t i n d x ] = ( CURRENT TIME rp >r p timesta mp ) / ( do uble ) rp > rp hop count ; // i n c r e m e n t indx f o r next time
55
r t > h i s t i n d x = ( r t > h i s t i n d x + 1 ) % MAX HISTORY ; } / Send a l l p a c k e t s queued i n t h e s e n d b u f f e r d e s t i n e d f o r this destination . XXX o b s e r v e t h e seco nd use o f p . / Packet b u f p k t ; w h i l e ( ( b u f p k t = r queue . deque ( r t > r t d s t ) ) ) { i f ( r t > r t h o p s != INFINITY2) { a s s e r t ( r t > r t f l a g s == RTF UP) ; // Delay them a l i t t l e t o h e l p ARP. O ther wise ARP // may drop p a c k e t s . SRD 5/23/99 forward ( rt , buf pkt , delay ) ; d e l a y += ARP DELAY ; } } } else { suppress reply = 1; } / I f r e p l y i s f o r me , d i s c a r d i t . / i f ( ih >daddr ( ) == i n d e x | | s u p p r e s s r e p l y ) { Packet : : f r e e ( p ) ; } / O ther wise , f o r w a r d t h e Route Reply . / else { // Find t h e r t e n t r y a o d v r t e n t r y r t 0 = r t a b l e . r t l o o k u p ( ih >daddr ( ) ) ; // I f t h e r t i s up , f o r w a r d i f ( r t 0 && ( r t 0 > r t h o p s != INFINITY2 ) ) { a s s e r t ( r t 0 > r t f l a g s == RTF UP) ; rp >r p h o p c o u n t += 1 ; rp > r p s r c = i n d e x ; f o r w a r d ( r t 0 , p , NO DELAY) ; // I n s e r t t h e nexthop to wa r ds t h e RREQ s o u r c e t o // t h e p r e c u r s o r l i s t o f t h e RREQ d e s t i n a t i o n r t > p c i n s e r t ( r t 0 >r t n e x t h o p ) ; // nexthop t o RREQ s o u r c e } else { // I don t know how t o f o r w a r d . . drop t h e r e p l y . #i f d e f DEBUG f p r i n t f ( s t d e r r , %s : dr o pping Route Reply \ n , FUNCTION ) ; #e n d i f // DEBUG drop ( p , DROP RTR NO ROUTE) ;
56
} } }
Last, but not least, we must adapt the rt update method, according to the new denition which was shown in Listing 5.8. Listing 5.18: (aodv.cc) Changes on the rt update method
void AODV : : r t u p d a t e ( a o d v r t e n t r y r t , u i n t 3 2 t seqnum , u i n t 1 6 t m e t r i c , n s a d d r t nexthop , do uble e x p i r e t i m e , u i nt8 t interface ) { r t > r t r t > r t r t > r t r t >r t r t > r t rt >r t } s e q n o = seqnum ; hops = metric ; f l a g s = RTF UP ; n e x t h o p = nexthop ; expire = expire time ; interface = interface ;
5.4.3
Changes on the routing table implementation aodv rtable.[cc,h]
As already anticipated before, the way the routing table is handled must be adapted according to the multi-interface extension. The only change which needs to be done is to uncommment the interface component of the route table entry (aodv rt entry). Listing 5.19: (aodv rtable.h) Changes on the aodv rt entry class denition
c l a s s aodv rt entry { friend c l a s s aodv rtable ; f r i e n d c l a s s AODV; f r i e n d c l a s s Lo ca lRepa ir Timer ; public : aodv rt entry () ; aodv rt entry () ; void AODV Neighbor void AODV Precursor void void bool do uble another req u int8 t requests nb insert ( nsaddr t id ) ; nb lo o kup ( n s a d d r t i d ) ; pc pc pc pc pc i n s e r t ( nsaddr t id ) ; lookup ( nsaddr t id ) ; delete ( nsaddr t id ) ; d e l e t e ( void ) ; empty ( v o i d ) ; // when I can send // number o f r o u t e
rt req timeout ; rt req cnt ;
57
protected : LIST ENTRY( a o d v r t e n t r y ) r t l i n k ; nsaddr t rt dst ; u int32 t rt seqno ; u i nt8 t rt interface ; u int16 t rt hops ; int rt last hop count ; co unt rt nexthop ; nsaddr t address / l i s t o f p r e c u r s o r s / aodv precursors r t p c l i s t ; do uble rt expire ; expires u int8 t rt flags ; #d e f i n e RTF DOWN 0 #d e f i n e RTF UP 1 #d e f i n e RTF IN REPAIR 2 / Must r e c e i v e 4 e r r o r s w i t h i n 3 t h e r o u t e down . u int8 t rt errors ; // do uble rt error time ; #d e f i n e MAX RT ERROR 4 // #d e f i n e MAX RT ERROR TIME 3 // /
// hop co unt // l a s t v a l i d hop // next hop IP
// when e n t r y
s e c o n d s i n o r d e r t o mark e r r o r co unt errors seconds
3 #d e f i n e MAX HISTORY do uble r t d i s c l a t e n c y [MAX HISTORY ] ; cha r hist indx ; int rt req last ttl ; // l a s t t t l v a l u e used // l a s t few r o u t e d i s c o v e r y l a t e n c i e s // do uble r t l e n g t h [MAX HISTORY ] ; // l a s t few r o u t e l e n g t h s / a l i s t o f neighbors that are using t h i s route . / a o dv nca che rt nblist ; };
And, in order to ensure a correct operation, we should initialize this member to 255 (non-valid value) in the corresponding constructor. Listing 5.20: (aodv rtable.cc) Changes on the aodv rt entry constructor
aodv rt entry : : aodv rt entry () {
58
int i ; rt req timeout = 0.0; rt req cnt = 0; rt dst = 0; rt seqno = 0; r t i n t e r f a c e = 255; r t h o p s = r t l a s t h o p c o u n t = INFINITY2 ; rt nexthop = 0; LIST INIT(& r t p c l i s t ) ; rt expire = 0.0; r t f l a g s = RTF DOWN; / rt errors = 0; rt error time = 0.0; / f o r ( i =0; i < MAX HISTORY ; i ++) { rt disc latency [ i ] = 0.0; } hist indx = 0; r t r eq la s t t t l = 0; LIST INIT(& r t n b l i s t ) ; }
59
Chapter 6
Scenario Script
One of the cornerstones of this work has been to create a exible multi-interface model where the number of interfaces per node, as well as the overall number of channels which is being used within the scenario can be easily congured by the user, by tweaking the Tcl script which establishes the simulation scenario. At the beginning of the script we must initialize the values that will be used afterwards as arguments to the node-config command, as it is usually done. Obviously, one of the parameters that must be included is the channel type, which has to be set to WirelessChannel. Furthermore, there is a new parameter, required to set the maximum number of interfaces that the nodes within the scenario may use. In the example below, this parameter is set to 3. Listing 6.1: (scen-script) Initialization of simulation variables
s e t v a l ( chan ) s et val ( ni ) s e t v a l ( nn ) Channel / W i r e l e s s C h a n n e l 3 20 ; ; ;
As has been already mentioned, the creation of several channels is done from the tcl scenario script. Listing 6.2 shows how channels are created (as many as the maximum number of interfaces previously established), using a for loop. Listing 6.2: (scen-script) Creation of wireless channels
f o r { s e t i 0} { $ i < $ v a l ( n i ) } { i n c r i } { s e t cha n ( $ i ) [ new $ v a l ( chan ) ] }
In order to ensure that an appropriate memory management is performed, the initialization of the god has to include as many interfaces as there may be overall, as shown below: Listing 6.3: (scen-script) Initialization of the god
cr ea te g o d [ expr $ v a l ( nn ) $ v a l ( n i ) ]
As we explained in Chapter 3, a new procedure, to allow the inclusion of the number of interfaces as an argument to node-config, was added to the ns-lib.tcl. Listing 6.4 shows how the number of interfaces is included as a new argument. It is also worth mentioning that 60
Chapter 6. Scenario Script
we do not specify the type of channel, but rather one channel, this was done so as not to require too many changes within the corresponding tcl procedure and, as will be seen later, the channels are added afterwards, before actually creating the wireless node. Listing 6.4: (scen-script) node-config
$ns no de co nfig adhocRouting $ v a l ( rp ) \ llType $ v a l ( l l ) \ macType $ v a l ( mac ) \ ifqType $ v a l ( i f q ) \ ifqLen $ v a l ( i f q l e n ) \ antType $ v a l ( ant ) \ propType $ v a l ( prop ) \ phyType $ v a l ( n e t i f ) \ channel $ cha n ( 0 ) \ t o p o I n s t a n ce $ to po \ agentTrace ON \ r o uter Tr a ce ON \ macTrace OFF \ movementTrace OFF \ ifNum $val ( ni )
Indeed, before creating a node we need to indicate how many interfaces it has, using the new procedure change-numifs, as well as associating them with the corresponding channel, i.e. by means of the add-channel procedure. These procedures have been added into the ns-lib.tcl le, and have been described in Chapter 3. Thanks to the model exibility, we can perform quite a broad range of combinations. For instance, Listing 6.5 shows an easy way to congure all nodes so as they use the same number of interfaces, connected to all previously dened wireless channels. Listing 6.5: (scen-script) Creating a number of nodes with the same number of interfaces associated to the same wireless channels
$ n s change numifs $ v a l ( n i ) f o r { s e t i 0} { $ i < $ v a l ( n i ) } { i n c r i } { $ n s add channel $ i $ cha n ( $ i ) } f o r { s e t i 0 } { $ i < $ v a l ( nn ) } { i n c r i } { s e t no de ( $ i ) [ $ n s node ] $ no de ( $ i ) random motion 0 }
However, we may want to have a more exible conguration, in which some nodes have a dierent number of interfaces than the others, connected to dierent wireless channels. As an example, Listing 6.6 shows a possible conguration, in which the rst node has 2 interfaces (associated to channels 0 and 2), while the second one only has one interface, associated to channel 2. Listing 6.6: (scen-script) Creating two nodes with dierent number of interfaces
$ns $ns change numifs 2 add channel 0 $ cha n ( 0 )
61
Chapter 6. Scenario Script
$ n s add channel 1 $ cha n ( 2 ) s e t no de ( 0 ) [ $ n s node ] $ no de ( 0 ) random motion 0 $ n s change numifs 1 $ n s add channel 0 $ cha n ( 2 ) s e t no de ( 1 ) [ $ n s node ] $ no de ( 1 ) random motion 0
62
Chapter 7
Future Work
The work that has been accomplished is, already, quite exible; the dierent interfaces can be accessed from the Tcl script, bringing about the possibility to modify some of their working parameters (e.g. transmission power or coverage, etc) on a rather straightforward way. One additional aspect that might be quite interesting would be the extension of the whole model so as to really include multiple technologies, and not only dierent interfaces belonging to the same technology, as has been our case. Another topic which may be of interest would be to address the same changes on the SRNode architecture, so that source routing protocols could also benet from the new feature. Anyhow, new ideas to improve the current model and to extend its capabilities are more than welcome.
63
Bibliography
[1] The Enhanced Network Simulator. http://www.cse.iitk.ac.in/users/braman/tens. [2] Tzi cker Chiueh, Ashish Raniwala, Rupa Krishnan, and Kartik Gopalan. Hyacinth: An IEEE 802.11-based Multi-channel Wireless Mesh Network. http://www.ecsl.cs. sunysb.edu/multichannel, October 2005. [3] Bo Wang. NS2 Notebook: Multi-channel Multi-interface Simulation in NS2 (2.29). http: //www.cse.msu.edu/~wangbo1/ns2/nshowto8.html. [4] Dapeng Wang. Make hyacinth run on Debian NS-2.29.2. http://my.opera.com/ HenryFD/blog/show.dml/202861, March 2006. [5] The VINT Project. The ns Manual, December 2000. [6] Francisco J. Ros and Pedro M. Ruiz. Implementing a new MANET unicast routing protocol in ns2. Technical report, University of Murcia, December 2004.
64
Appendix A
GNU Free Documentation License

Version 1.2, November 2002 Copyright c 2000,2001,2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the eective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modications made by others. This License is a kind of copyleft, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The Document, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as you. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. 65
Appendix A. GNU Free Documentation License
A Modied Version of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modications and/or translated into another language. A Secondary Section is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Documents overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The Invariant Sections are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not t the above denition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The Cover Texts are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A Transparent copy of the Document means a machine-readable copy, represented in a format whose specication is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent le format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modication by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not Transparent is called Opaque. Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modication. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The Title Page means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, Title Page means the text near the most prominent appearance of the works title, preceding the beginning of the body of the text. A section Entitled XYZ means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specic section name mentioned below, such as Acknowledgements, Dedications, Endorsements, or History.) To Preserve the Title of such a section when you modify the Document means that it remains a section Entitled XYZ according to this denition. 66
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no eect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Documents license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to t legibly, you should put the rst ones listed (as many as t reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
67
You may copy and distribute a Modied Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modied Version under precisely this License, with the Modied Version lling the role of the Document, thus licensing distribution and modication of the Modied Version to whoever possesses a copy of it. In addition, you must do these things in the Modied Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modications in the Modied Version, together with at least ve of the principal authors of the Document (all of its principal authors, if it has fewer than ve), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modied Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modied Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Documents license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled History, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modied Version as given on the Title Page. If there is no section Entitled History in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modied Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the History section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. For any section Entitled Acknowledgements or Dedications, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
68
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled Endorsements. Such a section may not be included in the Modied Version. N. Do not retitle any existing section to be Entitled Endorsements or to conict in title with any Invariant Section. O. Preserve any Warranty Disclaimers. If the Modied Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modied Versions license notice. These titles must be distinct from any other section titles. You may add a section Entitled Endorsements, provided it contains nothing but endorsements of your Modied Version by various partiesfor example, statements of peer review or that the text has been approved by an organization as the authoritative denition of a standard. You may add a passage of up to ve words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modied Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modied Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms dened in section 4 above for modied versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodied, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but dierent contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled History in the various original documents, forming one section Entitled History; likewise combine any sections Entitled Acknowledgements, and any sections Entitled Dedications. You must delete all sections Entitled Endorsements.
69
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an aggregate if the copyright resulting from the compilation is not used to limit the legal rights of the compilations users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Documents Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modication, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled Acknowledgements, Dedications, or History, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
70
10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may dier in detail to address new problems or concerns. See http: //www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document species that a particular numbered version of this License or any later version applies to it, you have the option of following the terms and conditions either of that specied version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
71

Adding Multiple Interface Support in NS-2

Uploaded by

Copyright:

Available Formats

Adding Multiple Interface Support in NS-2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Adding Multiple Interface Support in NS-2

Uploaded by

Copyright:

Available Formats

Adding Multiple Interface Support in NS-2

A GNU Free Documentation License

5.19 5.20 6.1 6.2 6.3 6.4 6.5 6.6

Objective of the Document

Structure of the Document

Multiple Interface Model

Requirements and Working Assumptions

Chapter 2. Multiple Interface Model

Figure 2.1: MobileNode Architecture

Chapter 2. Multiple Interface Model

Multiple Interface Node Model

Chapter 2. Multiple Interface Model

Channel 0 Channel 1 Channel 2

Figure 2.2: Modied MobileNode architecture, with multiple interface support

Changes on Tcl Code

Chapter 3. Changes on Tcl Code

Listing 3.2: (ns-lib.tcl) Procedure to add an interface on a node

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

The second procedure that needs to be modied is the add-target-rtagent, which is

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

Chapter 3. Changes on Tcl Code

$mac $fec } else { $mac $fec $err }

Chapter 3. Changes on Tcl Code

Recv MAC ] $self ]

Send MAC ] $self ]

Recv MAC ] $self ]

Drop MAC ] $self ]

Chapter 3. Changes on Tcl Code

# ============================================================ $ s e l f addif $netif }

Chapter 3. Changes on Tcl Code

Listing 3.11: (ns-mobilenode.tcl) MobileNode reset procedure

Changes on C++ Code

Chapter 4. Changes on C++ Code

Chapter 4. Changes on C++ Code

Listing 4.5: (channel.cc) affectedNodes method from the channel class

Changes on mac-802 11.cc

Changes on Routing Protocol Code

Changes on routing agent implementation

Chapter 5. Changes on Routing Protocol Code

NsObject t a r g e t l i s t [ MAX IF ] ; PriQueue i f q u e u e l i s t [ MAX IF ] ;

Chapter 5. Changes on Routing Protocol Code

Chapter 5. Changes on Routing Protocol Code

Changes on the Route Table

Illustrative example: AODV

Chapter 5. Changes on Routing Protocol Code

Chapter 5. Changes on Routing Protocol Code

Chapter 5. Changes on Routing Protocol Code

Chapter 5. Changes on Routing Protocol Code

Chapter 5. Changes on Routing Protocol Code