2012/3/16 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:
William Herrin wrote:
As LS requires less intelligence than DV, it converges faster.
I do believe that's the first time I've heard anybody suggest that a link state routing protocol requires "less intelligence" than a distance vector protocol.
I mean "intelligence as intermediate systems".
DV is a distributed computation by intelligent intermediate systems, whereas, with LS, intermediate systems just flood and computation is by each end.
That's basically wrong. Both systems perform computation on each router. Link State performs much more complex computation to arrive at its export to the forwarding information base. In fact, Distance Vector's calculation is downright trivial in comparison. The difference is that Link State shares the original knowledge, which it can do before recomputing its own tables. Distance Vector recomputes its own state first and then shares each router's state with the neighbors rather than sharing the original knowledge. The result is that the knowledge propagates faster with Link State and each router recomputes only once for each change. In some cases, distance vector will have to recompute several times before the system settles into a new stable state, delaying the process even further.
Here is an exercise for you insisting on DNS, an intermediate system.
What if DNS servers, including root ones, are mobile?
DNS' basic bootstrapping issues don't change, nor do the solutions.
The resovlers find the roots via a set of static well-known layer 3 address
You failed to deny MH know layer 3 address of its private HA.
Here's a tip for effective written communication: the first time in any document that you use an abbreviation that isn't well known, spell it out.
It's waste of resource for MH have well known IP address of root servers and domain names of its private DNS server and security keys for dynamic update only to avoid to know IP address of its private HA.
There's no reason for the Mobile Host to know the IP addresses of the root servers. Like any other host, including MH in your plan, it already knows its domain name and the IP addresses of its private DNS servers. That leaves only the security key. So, by your own accounting I swap knowledge of a topology-independent element (the security key) for a topology-dependent element (an IP address) which may change any time you adjust your home agent's required-to-be-landed network with all of today's vagaries around the renumbering problem.
For that matter, how do you solve the problem with your home agent approach? Is it even capable of having multiple home agents active for each node? How do you keep them in sync?
I actually designed and implemented such a system. Multiple home agents each may have multiple addresses.
If some address of HA does not work, MH tries other addresses of HA.
If some HA can not communicate with MH, CH may try to use other HA.
There is nothing mobility specific. Mobile protocols are modified just as other protocols are modified for multiple addresses.
In practice, however, handling multiple addresses is not very useful because selection of the best working address is time consuming unless hosts have default free routing tables.
In your home agent architecture, it doesn't matter if they can have multiple addresses. It matters if they can have the same address. Otherwise you're pushing off the generalized continuity of operations problem. One which my DNS add/drop approach handles seamlessly and at a granularity of the individual services on the mobile host. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004