Hello Tua,

see some responses in-line.

At 06:37 22/01/2007, #LUONG TRUNG TUAN# wrote:
>I’m a research student in field of MANET.I have been trying to add the 
>multiple interface support for Ns2 for a while but still not get any 
>results. And recently I’m very glad to see your released document about 
>Adding Multiple Interface Support in NS-2.  First of all, I would like to 
>thank you very much for your contribution for extending ns, which is a 
>great helps for student like me.

Thanks for your interest. This is really the aim we had when creating the 
document.

>Regarding your extension, I would like to ask few questions
>
>How would you specify which interface will be used for sending data 
>packet? As I see that you need a variable interface for routing entry, so 
>when we add or update an entry, this value will be modified, so by that 
>you mean this value will be manually specified when we create a new data flow?

The idea is that this should be handled from the routing agent. This is to 
say, the application (e.g. cbr) should not be aware of how the routing 
agent sends the packet; it is even unaware of the number of interfaces a 
node is managing.

>Have you tried for DSDV routing? I trying as follow your guidelines, but 
>not so sure how to specify the interface value for new entry and updating 
>existing routing entry

No, as we say in the text we worked with our own implementation; and we 
took a look on AODV according to some request we get in the ns-users 
mailing list. See:
http://mailman.isi.edu/pipermail/ns-users/2007-January/058433.html

I've taken a quick look on the dsdv code, and this is what I've found:

*** UNICAST TRANSMISSIONS
- It seems that all unicast transmissions are handled by the forwardPacket 
method, with:
>target_->recv(p, (Handler *)0);

This is different from the way aodv sends packets, but my guess would be 
that you might need to change target_ in the code above for target_[Iface] 
--- see Listing 5.4. As I said in the email referenced above, the Iface 
index need to be gathered from the route table entry.

---- Not double-checked code
if(nIfaces) {
         target_[Iface]->recv(p, (Handler *)0);
} else {
         target_->recv(p, (Handler *)0);
}

*** BROADCAST TRANSMISSIONS
- All broadcast packets are handled by the sendOutBCastPkt method, so 
instead of that one I guess you should use a modified version of Listing 
5.3, e.g. see below:

--- Not double-checked code

Scheduler &s = Scheduler::instance();
if (nIfaces) {
         for (int i = 0 ; i < nIfaces ; i++) {
                 Packet *p_copy = p->copy();
                 s.schedule(targetlist[i], p_copy, 
jitter(DSDV_BROADCAST_JITTER, be_random_));
         }
         Packet::free(pkt);
} else {
         s.schedule(target_,p,jitter(DSDV_BROADCAST_JITTER, be_random_));
}

*** CHANGES ON ROUTE TABLE ENTRY
- You need to add the index for the outgoing interface as a new member of 
the rtable_ent class, and each time you add the routing table entry you may 
also need to specify this --- see listing 5.5 and my answer on the mail 
linked above. Note that this will be afterwards used to refer to the 
appropriate interface when sending a unicast packet.

>Can your extension work for multiple interfaces of different kinds such as 
>802_11, wimax, tdma, umts together?

Currently not, or at least we haven't addressed this so far. The idea was 
to propose a flexible framework, so that extending it to support more 
technologies shouldn't be too complicated. If you are going to work on 
this, we will be happy to help/contribute to that.

>Would be very much appreciate if you could kindly address my questions

Hope that my answers are somehow helpful for you.

>Than you very much and best regards,
>Tuan

Cheers,
Ramón

Reply via email to