Thomas Heide Clausen <[EMAIL PROTECTED]> writes: > > On 9/30/05, Thomas Narten <[EMAIL PROTECTED]> wrote: > >>> The MANET community has a well developed undersanding of what a MANET > >>> is, and how it differentiates itself from traditional Internet > >>> subnets. > >> > >> My question is not "what a MANET is", but what a MANET is "in the > >> context of IP". What does a MANET look like to IP? How does IP run > >> over MANET? That is, looking at this as another instance of "IP over > >> FOO" problem, what is the "IP over MANET" model? What services does > >> the "MANET part" supply, and what part does IP have to emulate on top > >> of that to make an "IP Manet subnet" work like IP over Ethernet or any > >> other technology over which IP runs? I do not have an understanding of > >> this, and I sense, neither do some other folk. Note that I am > >> supportive of doing more manet work in the IETF. But I want to be sure > >> it is done in a way that works well for IP, existing deployments, etc. > >>
> Agreed -- and good to hear that you are supportive of MANET work within > the IETF in general. This previous paragraph of yours contain a lot of > independent questions, and while we'd be happy to address each of them > individually if you'd like, I think that it is more constructive to in > this email (try to) answer -- or at least give our point of view on -- > "what the MANET subnet model is" and the related issues of "what is the > IP over MANET model" and "what does a MANET look like to IP", as raised > above. > >>> A MANET is a stub subnet as any other stub subnet, with the following > >>> exceptions: > >> > >>> - the nodes within a MANET subnet do not share a multicast > >>> - capable link > >> > >> Or broadcast. Maybe a minor distinction, but it means ARP doesn't > >> work, which isn't minor IMO!!! > >> > > > ARP works in MANETs exactly as it does in other subnets, in that it > allows a node to determine the mac address of the next-hop IP > address. Actually, I disagree with this. ARP is used to determine the link-layer address of a neighboring node on the same subnet/link. In the case of manets, a "neighbor" in the traditional IP sense may not be directly reachable. So, you must be assuming proxy ARP here. Proxy ARP is not something that the IETF has really ever blessed. It is used, but it has issues. So, to base MANETs on proxy ARP, well that is a significant assumption that needs to be documented and reviewed. > Since this it performed on a hop-by-hop basis, no forwarding is > required for ARP to discover the "next hop" -- which is, by definition, > an adjacent node. Assuming proxy ARP is being used... > >> Does an "IP Manet subet" provide broadcast capability for protocols > >> that need IP Broadcast? > >> > >> so, are you saying that IP multicast simply doesn't work on an IP > >> manet subnet? What other IP services that one normally associates with > >> an IP subnet are also not supported? > > > >>> > For protocols over IP which require manet-wide broadcast or multicast, > Simple Multicast Forwarding provides this capability. SMF is an item of > the MANET wg. Note: from IP's perspective, "manet-wide broadcast/multicast" doesn't have meaning. Applications don't know about the type of IP network they run over. They certainly don't know whether they are running over a MANET or an Ethernet. (At least, I hope not...) So, if you are saying "IP multicast/broadcast" is provided in MANETs via "Simple Multicast Forwarding", that is consistent with IP. Is this what you mean, or do you mean something else? Note: the key thing here is whether a "manet IP subnet" is providing an abstract service to higher layers that looks like standard IP. > >>> - communication within a MANET subnet implies forwarding IP > >>> - traffic, and decrementing TTL. > >> > >> The first part I think I can agree with. The second part is less clear > >> to me. Saying the TTL is decremented means that a "MANET subnet" is no > >> longer a normal IP subnet. What exactly are the differences between an > >> "IP subnet" and an "IP MANET subnet"? > > > > > This is, essentially, the difference between a MANET subnet and any > other subnets: since connectivity within a MANET subnet is ensured via > multi-hop IP forwarding/routing, and since std. behavior when > forwarding an IP datagram is to decrement TTL, a MANET node decrements > TTL when forwarding an IP datagram -- also internally within the MANET. > This is the behavior exhibited by the implementations of RFC 3626, > 3561, 3684. But this changes the IP subnet model. There are protocols that assume that the TTL will not be decremented when a packet is sent from one node to another node on the same IP subnet. Have you compiled a list of protocols that would break under this model? Do you plan to special case each of those protocols so that they can work over a MANET? Again, any change to the IP subnet model must be carefully reviewed and understood for implications to standard IP protocols. Am I repeatig myself? :-) > >> It is this aspect of MANETs that IMO is critical to understand, as it > >> scopes the work that needs to be done to make MANETs work in an IP > >> context. > >> > >> What document define/layout these issues? > > > RFC 2501 very briefly introduces the idea, while the MANET wg protocols > all use these concepts of MANET subnets. However, there is no document > which exactly defines/layout these issues in detail, and we do agree > that this is sorely needed. An issue, which has become very clear > during the AUTOCONF chartering process is, that we need to both be sure > that we share the same understanding of this, as well as communicate it > clearly. One of the first deliverables of the AUTOCONF WG would > therefore, according to the milestones proposed, be to produce this > document namely the "terminology & problem statement" document. I think I agree. But it's not just "terminology/problem statement"; we need a document that describes/defines the abstract service model that manet IP subnets provide. We need to understand how the model differs from standard IP and whether the cost of such deviations are acceptable. > >>> As a concequence, the boundaries of a MANET is the edge router, > >>> providing access between the MANET and the Internet. > >> > >> If there is one... I assume MANETs can be isolated... > > > Yes, MANETs can be deployed as an edge network to the Internet as well > as standalone network. > >> > >>> The MANET wg is currently chartered to produce: > >>> > >>> - mechanisms, which provide unicast connectivity among the > >>> already > >>> configured nodes within a MANET subnet through IP forwarding & TTL > >>> decrement > >> > >> Well, I just read the MANET charter, and I don't understand this to be > >> what the charter says. From what I read, the MANET charter talks a lot > >> about routing and routing protocols, but pretty much nothing about > >> defining an "IP subnet model". It certainly does not mention TTLs > > > The main purpose of the MANET WG is to produce MANET routing protocols > on L3 (thereby gaining the usual benefits of abstraction). Since MANETs > are multi-hop, this implies IP forwarding which, in turn, implies > decrementing the TTL (among others, this is said in RFC1812 section > 4.2.2.9). It is true, that the "subnet model" for MANETs hasn't been > explicitly documented. However it would seem that the core of the > problem here lies in the following: > (a) normally, within a subnet, TTL is not decremented > (since no L3 fwd is occurring) > (b) normally, when an IP datagram is forwarded, the TTL > is decremented (this implies typically that the datagram > transverses a subnet border) > If we agree that a L3 MANET is formed as a L3 multi-hop network where > connectivity also within the MANET requires forwarding (and I believe > that this is part of what the MANET wg was taking as premise), then: > (i) within a MANET, L3 forwarding occurs, even though the > datagram does not exit the MANET subnet and thus not > transverses a subnet border > Thus, it would seem that the MANET subnet model requires > reinterpretation of either (a) or (b). It's been MANET community > understanding that routing is done by decrementing the TTL at each hop > when forwarding an IP datagram -- also within the MANET subnet. This is > reflected in the routing protocol specifications (and not in the > charter). > I believe that this is what the MANET community implicitly has had as > working hypothesis - but this is something that should be made explicit > and widely confirmed. Most definitely. This needs to be broadly understood/confirmed, since it has implications on the basic IP subnet model. Hence, my concern, and sending this to the int-area list in addition to just the WG list. > >>> - mechanisms, providing MANET simplified best effort multicast > >>> among > >>> the already configured nodes within the MANET stub subnet. > >> > >>> A task for the AUTOCONF working group is to ensure that the IPv6 > >>> address autoconfiguration mechanism is extended to operate within > >>> these constraints -- corresponding to one of the specified > >>> deliverables. > >> > >> It is not immediately clear that IPv6 autoconf should (or needs to be) > >> extended at all. Answering this question depends on understanding what > >> the "MANET Subnet" model is. > To clarify: one possible approach for IPv6 address autoconfiguration is > to use a "reserved flag" in e.g. RA/RS messages and let them be > forwarded by the MANET nodes. The rest of NDP is supposed to work as-is > -- e.g as discussed in detail in the draft submitted by R. Wakikawa, > Charles perkins, et al > draft-wakikawa-manet-globalv6-03.txt and can be downloaded from: > http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/IETF/MANETAUTOCONF/ > draft-wakikawa-manet-globalv6-03.txt > If a DHCPv6 server is available, then one possible approach could be to > exploit the MANET node(s) which are directly connected to the server > and use the "relay agent" feature to get the addresses configured or > allow these directly connected nodes to distribute addresses among > MANET nodes in their own way. Among the AUTOCONF group there's > experimental testbeds operating in this fashion. Another would be to ensure that Manet IP Subnets provide a broadcast capability and use that. Then there might be a need for _any_ DHC changes. Wouldn't that be attractive? > >>> This understanding of MANETs, I believe, is what came out of the > >>> discussions concerning the recent rechartering of the MANET wg, and > >>> should also hold true for AUTOCONF. Integrating such description > >>> into the proposed AUTOCONF charter might be excessive, but could > >>> well be documented in the proposed problem-statement deliverable? > >>> However guidance on this issue is appreciated -- what is your > >>> recommended approach? > >> > >> Yes, this needs documenting, and it needs document ASAP, since all the > >> work being proposed depends on that. IMO, this needs to be the first > >> deliverable and is the one that should the short-term focus of > >> autoconf and/or manet. > >> > Agree. As said in a previous mail: "The problem statement document > should be completed before the details of the base protocols are > finalized" . This is reflected in the milestones. IMO, protocol work should be put on hold until the Manet IP subnet model is defined, documented and agreed upon by the broader community. Protocol work makes assumptions about the Manet IP subnet model. So let's nail that down first. Thomas _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
