install/uninstall routing protocol

[vahid Saber]

Hello,

I have a VANET scenario where each simulation node follows its own path within the area and may temporarily stop at some locations to form MANET with other nodes nearby.(which means at each instance of time, there can be multiple isolated MANETs in the simulation)

After sometime, each node moves again (leave the current MANET) and stop at another location to form another MANET with other group of nearby nodes.

To achieve this, I would like to redo IP address assignment and routing installation on each node multiple times during a simulation run. 

Does ns-3 support uninstallation/reinstllation of -routing- protocols? Any suggestions would be highly appreciated.

Thank you

[Tommaso Pecorella]

Hi,

there are two ways to reply to your question. One is the straightforward one (what ns-3 can and can not do) and another one is more complex. I'll start with the first one.

IP address assignment: check the manual and the API documentation, you can easily assign new IP addresses to an interface and remove the old ones.

Routing protocol add / removal: this is not supported. The best (and only) thing you can have is to stop and start the ones you have installed already. Still, not all protocols are compliant with start and stop. Check the protocol you want to use (the manual and the code).

Now the more complex answer.

What you are trying to do is possible, but you're missing some extremely important pieces, and whiteout them it won't be possible to do anything.

You can add and remove an address, but who's responsible for this ? DHCP is not (yet) available.

Moreover, adding and removing IP addresses is kinda dangerous, as a node is known for its IP address. Adding and removing it will result in a node changing its identity.

Shortly put, what you describe is lacking in terms of overall design. Perhaps you did not write everything, but what you didn't write could be quite hard to simulate, and yet be extremely important for a correct simulation result.

My 2 cents is to not overlook at potential problems.

Have fun,

T.

[vahid Saber]

Hi Tommaso,

And thanks for the answer. I have some comments and solutions based on your key points:

IP assignment:

Although it would be great and ideal to have all the aspects of the scenario correctly simulated, the IP provision is the side piece of my puzzle for delegating route solicitation/advertisement in a Mobile IP scenario.I don't know if I should bother you with the details. But what I think I should do is to listen to your warning and stick to the normal ns-3 way of address assignment: manually, initially, never changing during simulation. I will write another question related to this issue soon.

Routing Protocol Change:

This one is much more important. Your answer scared me, especially because there is no start/stop method available in OLSR. I am ready to get my hands dirty as I can't skip this one like IP assignment. Being relatively new to this environment, I just had a look at the ns-3, list routing and OLSR code. For changing the routing object, I can see the following points:

-- I don't think I want to mess with ns-3's underlying aggregation mechanism to delete and replace the routing object. I will sink in it.

-- I just have to get past the ListRouting and get to the OLSR object and ...and press a reset button which does not exist (yet).

-- What that seems to be doable is to create a controlled "reset" button for OLSR that:

 1. leaves some of the settings which are supplied by base classes and other interacting classes(like those hard-coded attributes in the a base method called GetTypeId() )  and the IP settings (supplied by SetIpv4() ) .

 2. clear the rest of internal settings.

 3. cancel all internal timers.

 4. call OLSR's private DoStart() in a clean way.

What do you think? is this a common way of doing things in ns-3 ? 

If this seems a hack or the over all design seems suspicious, kindly let me know so that we can discuss with more details. Your suggestions will be highly appreciated.

Thanks again

Vahid

[Tommaso Pecorella]

Hi,

answers in line...

On Tuesday, January 5, 2016 at 7:10:43 PM UTC+1, vahid Saber wrote:

Hi Tommaso,

And thanks for the answer. I have some comments and solutions based on your key points:

IP assignment:

Although it would be great and ideal to have all the aspects of the scenario correctly simulated, the IP provision is the side piece of my puzzle for delegating route solicitation/advertisement in a Mobile IP scenario.

Ouch. You just gave me an important info, and you didn't realize how important is. RS/RA -> you're playing with IPv6 !

Address assignment for IPv6 is MUCH more dynamic than for IPv4. If you use the RADVD program (it's in internet-apps) you'll have dynamically assigned global IP addresses.

I don't know if I should bother you with the details. But what I think I should do is to listen to your warning and stick to the normal ns-3 way of address assignment: manually, initially, never changing during simulation. I will write another question related to this issue soon.

Always keep your focus narrow enough to have a good answer, but broad enough to have a meaningful one :)

 

Routing Protocol Change:

This one is much more important. Your answer scared me, especially because there is no start/stop method available in OLSR. I am ready to get my hands dirty as I can't skip this one like IP assignment. Being relatively new to this environment, I just had a look at the ns-3, list routing and OLSR code. For changing the routing object, I can see the following points:

-- I don't think I want to mess with ns-3's underlying aggregation mechanism to delete and replace the routing object. I will sink in it.

Yes, you would. Objects can not be deleted once they have been created, trying to do that would break ns-3 in bad and nasty ways.

 

-- I just have to get past the ListRouting and get to the OLSR object and ...and press a reset button which does not exist (yet).

There's something worse. OLSR works with IPv4, and you said "RA/RS"... anyway, adding a start/stop to OLSR should be easy enough.

 

-- What that seems to be doable is to create a controlled "reset" button for OLSR that:

 1. leaves some of the settings which are supplied by base classes and other interacting classes(like those hard-coded attributes in the a base method called GetTypeId() )  and the IP settings (supplied by SetIpv4() ) .

 2. clear the rest of internal settings.

 3. cancel all internal timers.

 4. call OLSR's private DoStart() in a clean way.

That's what a start/stop would do. The stop should (only) stop the timers, so the protocol doesn't start trying to send packets when the node is not connected to any network.

 

What do you think? is this a common way of doing things in ns-3 ? 

Yes, totally. Moreover, if you add Start/Stop methods to OLSR, please provide the patch :)

Note that Start/Stop is a functionality still being developed. Thus, it is not yet used in the code. However, the basic idea is the one we said: Stop should... stop all the object activities (like timers, etc.) and start should let it restart its normal operations.

It could be debatable if "start" should mean a clean start (i.e., reset all the internal timers, flush the queues, etc.) or a less clean start (e.g., restart the timers but keep the queues). I guess it will depend on the protocol.

Anyway, some things can be decided only by trying.

 

If this seems a hack or the over all design seems suspicious, kindly let me know so that we can discuss with more details. Your suggestions will be highly appreciated.

It's not a hack, but you should decide if you want to work with IPv6 or IPv4...

Cheers,

T.

[vahid Saber]

Hi Tommaso,

Thanks for the suggestions, I will send a patch when I completed OLSR modifications's tests.

About ipv4/6 selection, it is definitely ipv6. So I figured the next apparent move would be to create OLSR-ipv6. I thought it would be just the matter of  using IPv6 instead of ipv4 but I saw 2 papers from someone called wakikawa saying otherwise.

The problem is, I cant find any other ipv6 routing in ns-3 except static routing. Am I right? I saw Global routing for ipv6 still in code review phase.

I guess I have two options here:

1-Write a new OLSR for ipv6,

2- complete what I am doing in OLSR ipv4 and use its routing tables to create naive temporary ns-3 ipv6-static routes as and when required.

Any suggestions?

Thanks

Vahid  

[Tommaso Pecorella]

Hi Vahid,

there's also RipNg, but it's not wise to use it for an ad-hoc network. Moreover, there's an AODV for IPv6 being developed.

I'd say that modifying OLSR to be IPv6 compliant is the best approach, but I'm not sure if there's an RFC about that. Moreover, I'm not totally sure if ns-3 OLSR is v1 or v2, I'd check.

Cheers,

T.