Alpt is right and... there are also other problems (ex: convergence times) and... some of them that can't be fixed with a routing protocol (ex: media congestion and frequency shifts due to the relative speed of the two radios).
MANETs are the future, but the actual Netsukuku is not enough for mobile nodes. Differentiating the nodes (SN, MN) is not a good idea; my raccomendation is to start thinking at a full mobile network (fixed nodes possibles but not needed), and thinking to mobile networks my bet is on something similar to the Zone Routing Protocol but using geodata to overcome tcp/ip stack limits (Netsukuku would be perfect for the external ring of the ZRP). ciao Michele 2007/8/17, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Alpt wrote: > > There are some problems with solution: > > 1) It is implicitly assumed that a Static network is available. For > > this reason, a net composed by only mobile nodes cannot be created. > well, yes... but a net composed only by mobiles would mean more bandwith/cpu > usage... > if this is not a real problem then i think it's not impossible for netsukuku > to get there... > > > > 2) If a MN overpass a gnode, it must change IP! > > > Right, my fault. > > > > Some ideas to be further explored: > > [...] > > > > My idea was not really NAT. the LTP idea works like this: (let's stay in the > same gnode for now) > -node 1, connected to node 2, moves onto node 3. > -node 1 send a TP that lasts 5 hops and remains in the same gnode of node 2. > this TP contains just the info "node 1 moved to node 3" > now when node 4 want to contact node 1, he looks at his map and sees that > node1 is at node2 (he didn't receive the LTP). > -node 4 sends a packet to node1. > -the nodes in the pkt-route route the pkt towards node2. > -when the pkt arrives at 5 hops from node2, the nodes are aware that node1 is > now at node3, not node2, so they route it towards node3. > -packet arrives. > So, more hops in the LTP means more efficent routes and more reliability, but > more bandwith used. > This differs from nat because nat involves a single node: what if the node > goes down? also, nat has some problems with incoming connections... > > What if something like this is done: > MN -mobile node > SN -static node > GN - gnode :) > IPM - IP of mobile node > LTP -Limited Tracer Packet... a TP that lasts few hops... 5 may be ok. LTP > remains in that gnode, it doesn't go out. > - MN connects to SN1. A CTP is sent, like if a new SN was connected, MN > updates its map and gets ip IPM1. > - MN moves: > -MN connects to SN2, same gnode(GN1). (no ip-change is required here, > right?) > -LTP is sent, only nodes contacted by the LTP know the new SN to which MN > is connected. > OR > -MN connects to SN3, GN2. > -MN gets ip IPM2, but only the GN2 is made aware of this. > -SN1 is contacted, SN1 sends LTP, so at least 5 nodes of G1(5 hops=> min > 5 nodes contacted) know the new ip of MN. This way we don't send a complete > CTP. > -When other moves occur, MN should contact SN1 to let it know the new ip it > gets, and to know how many hops away SN1 is. > This way other nodes can contact MN still at IPM1, since it's what they have > received fron the initial CTP. > A new CTP can be sent from MN when if SN1 is at more then x hops or when GN1 > (the gnode of SN1) is running out of usable ips... > > ..maybe it would be better if the ltp travels the whole gnode... and didn't > last just 5 hops... > maybe i'll do some tests when i have time... > > Luca. > _______________________________________________ > Netsukuku mailing list > [email protected] > http://lists.dyne.org/mailman/listinfo/netsukuku > _______________________________________________ Netsukuku mailing list [email protected] http://lists.dyne.org/mailman/listinfo/netsukuku
