On Fri, 2005-10-07 at 18:52 +0300, Charles E. Perkins wrote: > 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.
Unless we have a common, well-defined, clear and written description of the model of MANET operation, we can't have a constructive conversation about any aspects of MANET, such as address assignment. We can have, if you'll excuse the pun, an ad hoc discussion about the MANET experiments that have been conducted to date. The purpose of research is to develop understanding, concepts and abstractions. Without a written description of those results, we can't make any forward progress. > > - 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. It appears we may not even have a common vocabulary or understanding to start from. Perhaps Thomas asked an irrelevant or nonsensical (in the sense of "not making sense in the context of MANET") question. Without a common set of abstractions, we have no way to talk about the particular problem of address assignment... > > - how are packets forwarded within a subnet? > > > Not germane to address allocation. See [manet] for a lot of ideas. What is "[manet]"? > > How is address > > resolution done? > > > Not germane to address allocation. Sorry, you've lost me here. How can address resolution not be germane to address assignment? > > 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. And what is [autoconf]? > > > > > >>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. Sorry, now I'm lost...seems the conversation is (here's that bad pun again) way too ad hoc for me. > 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. OK, so let me try getting at this model issue another way. Where is the line drawn above which there are no changes to the TCP/IP protocol model? Is an application that uses TCP and UDP aware that it's running on a MANET? Does UDP run under different rules in a MANET? Does a MANET provide Ethernet emulation so there are no changes to IP? > >>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. Who is "we" and how does someone who is not "we" come to an understanding 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. IP is a lot more than establishing connectivity. IP is an unreliable, host-to-host data delivery service. We have to know if multicast is available to know how to make existing address assignment mechanisms work. > Regards, > Charlie P. - Ralph > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
