Subject: Distributed Directories, master/slave, MADHCP, ... not!

From: Charles Perkins <[email-masked]>
Date: Sat, 7 Mar 1998 08:02:49 -0800 (PST)

Bora,

> The idea is that the temporary address is assigned through a MADHCP process
> and
> the newly assigned address is reported to a distributed directory service
> from which the
> interested parties can obtain routing and temporary address information.

This raises a number of issues:

- Why is routing information part of a distributed directory service?
- How temporary are the addresses?
- How important is it for the design of the link topology maintenance
  algorithm that the addresses are temporary?
- What other kinds of information are in the distributed directory
  service?
- Are all the directory entries subject to timing constraints as
  (I assume) you expect the routing entries to be?

> If there is a MANET
> gateway to the net in contact then the gatewat may assign the address
> otherwise the hosts can decide on any address themselves like AppleTalk.

But, Appletalk may be the wrong model.  I have usually worked on the
assumption that reducing chat is important.  Appletalk is somewhat
famous for violating that assumption.

More to the point, to avoid address duplication, there will be a lot
of tricky issues to resolve.  Just getting it right in the first place
will take some work.  After that, whenever _any_ node establishes a
new link with _any other_ node, Duplicate Address Detection (DAD)
will have to be performed again (for every node in the connected
graph containing the new link!), because it could be the case that
the new link connects two nodes which were previously unconnected
when DAD was run before.

This is obviously unscalable to the Nth degree.

One alternative would be to make MADHCP already responsible (by
administrative preconfiguration) for ensuring global uniqueness
in the first place.  But that implies a very strong degree of
administrative control and stability.  In this case, I claim:

1) It won't affect the ad-hoc routing stuff at all, and
2) for the purposes of discussing the effects of mobility,
   it doesn't matter whether we have static IP address assignment
   or MADHCP.

> If there are multiple GWs, then a slave/master server
> scheme can be used.

Can you expand on this point?  How are the masters appointed?  How
are the pathways between masters and slaves established?  What
happens when two ad-hoc clouds start to touch, or one ad-hoc cloud
breaks in two?  Is the "gateway" a gateway to an infrastructure
intranet or the global Internet?

My strong intuition is that any master/slave relationship for
topology maintenance or address assignment is almost unworkable.

> Since there was no gateway in their network then the inability to update the
> distributed directory service
> in the latter case does not matter.

What was the latter case that is referenced here?  Maintenance of
distributed directories will be challenging in the extreme in the
ad-hoc case.  When you say "gateway", should I infer that you mean
that the directory service _is not_ actually maintained in the
ad-hoc network?

Regards,
Charlie P.

---

From: Chip Elliott <[email-masked]>
Date: Sun, 08 Mar 1998 09:04:24 -0500

>famous for violating that assumption.

Charlie,

I don't usually disagree with you, but here I will.

I've used AppleTalk and IP networks for many, many years,
and AppleTalk wins hands-down in the "usability" category.

I'd be willing to pay a fair amount of bandwidth to
get a network that "just works".

Hopefully we can do that in MANET _without_ paying a big
bandwidth price, but if we have to choose, I'd vote
for something that is a HELL OF A LOT EASIER to set up
than a typical IP network.

-- Chip

PS. And I think if we come up with a solution that implicitly
requires anything to be configured by hand, we've not done
a great job. (Here I'm motivated by the continuing woes of
trying to get IP addresses, default routers, TTLs, DNS, etc,
all straightened out for a network, not to mention trying to
configure OSPF and BGP parameters. One can argue the merits
of DHCP or PPP, but I prefer them over hand configuration!)