Hello Thomas,
I have some possible answers to your questions.
But first, a little background. In our group, we implemented a
number of ad hoc networks, and wanted the nodes to be able to
have addresses. So we devised a way for them to get addresses.
It worked. Other people noticed the same problem, and designed
other ways that worked. We got together, had a couple of BOFs,
and put together a charter that seemed to make sense to the
practitioners who wanted to agree on a standard method for
getting addresses. So that's where I'm coming from.
ext Thomas Narten wrote:
yes. But this is not enough to communicate. There also needs to be a
model/framework/architecture that defines an "ad hoc subnet":
Not necessarily, at least not in any formalized rigid way. People who are
building these things like crazy don't seem to have any terrible problems
getting the devices to communicate.
- what is the subnet model? I.e., for a collection of links, what
are the boundaries of a "subnet", where each node is part of the
same ad hoc network?
Often, there is no subnet model. If there is one, then it's a matter of
debate
how to best impose it. For the purposes of my initial interest, you could
consider the whole ad hoc network as having no hierarchical addressing.
You could also say that the extent of the subnet is the same as the extent
of the ad hoc network, but this is only one possible model.
- how are packets forwarded within a subnet?
Not germane to address allocation. See [manet] for a lot of ideas.
How is address
resolution done?
Not germane to address allocation.
How does a sender decide whether a destination on
the "subnet" is directly reachable, or is reachable through a
forwarding node?
You could try a route discovery. See [manet]. Alternatively, in a future
discussion, you could explore the ramifications of whatever subnet model
is imposed on the network.
- How is multicast traffic distributed within the subnet?
Nobody's doing multicast.
- in IPv6, how are RAs distributed?
That's a topic for gateway management, and is not the first
order of business. However I think it is interesting in the context
of [autoconf], and a lot of different ideas have been proposed.
Ad hoc nodes may also need to configure globally routable addresses,
in order to communicate with devices on the Internet.
Depending on the answers to the questions above, this may not be an
issue at all. I.e., global addresses could be distributed via RAs. Why
(or why not) is this insufficient?
Well, I think you answered your own question here. But we don't know how
best to distribute RAs.
From the IP layer perspective, ad hoc networks present severa
challenges. Unlike in the traditional IP networks, each ad hoc node,
besides being a traffic end-point,
should be capable of forwarding traffic destined for other hosts.
This would seem to be making assumptions about what the subnet model
is. I.e., how one delivers packets to other destinations on the same
"ad hoc" subnet. How is that done? Is that what this WG needs to
decide, or has this already been decided? If the latter, where is that
documented?
The assumption is that nobody is going to impose an assumption.
But as you point out that is just an assumption, and maybe someone
will impose an assumption. I think it would be ill-considered to do so.
I do not understand why you insist on knowing how packets
are forwarded and delivered. If you followed [manet], you would
know that there is a lot of interesting work in progress to answer
this question. In the meantime, people want to get some addresses.
Additionally, nodes constituting an ad-hoc network do not share access
to a single multicast-capable link for signaling.
so a key architectural question is whether an "ad hoc subnet" will
emulate multicast service. And if not, what the implications are and
whether that is actually a desirable direction to go in.
I'd rather say that multicast is not the focus of the effort, and any
multicast
semantics will be imposed for the very specific purposes of whatever is
needed or address allocation.
Has this issue already been decided? Is this WG supposed to figure
this out and come up with an approach/solution?
Nothing is decided to my knowledge.
A reason my previous question is so critical is whether we are better
off emulating multicast (so all multicast applications work as is), or
whether every higher-layer protocol that uses multicast has to be
rewritten to work over an "ad hoc subnet"? I sure hope we aren't
doing the latter...
I agree that a single multicast model is basically desirable, except that
some multicast groups require more maintenance than others. For instance,
it's silly to have signaling to maintain a multicast group that every node
has to belong to.
IMO, this above is the tip of the iceberg, and it is the larger
questions that must be dealt with. The addressing part is just one
component of the bigger picture, and without a coherent bigger
picture, none of this makes sense.
I totally disagree with this because:
(1) We already have credible solutions that work
(2) Your statement requires that we must all go into paralysis
(3) We need to have a "Proposed Standard" to get
get some experience and convergence
(4) There is not today any coherent all-inclusive bigger picture
(5) Nevertheless, we are able to make a lot of sense out of
our pieces of it.
The ad hoc nodes under consideration are,
once configured, expected to be able to support multi-hop
communication by running the MANET routing protocol developed by the
IETF MANET WG.
Which document is this? Is there just one?
There are two. They're called OLSRv2 and DYMO. They have different
applicability statements. This is according to the [manet] charter.
And, is this a routing protocol that carries unicast, or is this the
definition of the abstract service an "ad hoc subnet" provides?
IP is not a "service". It's a way to establish network connectivity.
Current proposals focus on unicast. I do not see that anyone is
suggesting that we should allocate multicast addresses as part of
the work chartered for [autoconf]. We want one way to dynamically
allocate IP addresses in ad hoc networks. We currently have many
ways.
Regards,
Charlie P.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
