Subject: RE: [Int-area] Re: AUTOCONF charter

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 10 Oct 2005 13:54:07 +0100

> Just re-read RFC 2501, and  I don't see mention of "multi-hop
subnets".
> Can you point out where this is described?

I don't think RFC 2501 is strong on that the networks
it describes are subnets in the Internet sense, although
that's widely assumed in the IETF MANET community, see for
example Section 7 of RFC 3561 or Section 11.1 of RFC 3626.
Multi-hop of course is covered in RFC 2501 - the first
paragraph of the Introduction introduces the point for
the first time.

That a MANET should be a subnet (common prefix) is
primarily for the benefit of the Internet to which it
is attached, the MANET itself generally derives little
benefit from this (although there's an exception in
OLSRv2 for example, it will allow more efficient messages,
but that's still only secondary). Of course this benefit
to the Internet is important, which is one reason why
Autoconf should be useful.

I would agree that spelling this out in a single document,
son-of-RFC-2501 if you like, would be beneficial. That
should be a task of the Autoconf WG and/or the Manet WG
(there's a major overlap of participants of course) rather
than a hurdle to forming an Autoconf WG and starting its
work however in my/our (for some value of "our") opinion.

>> One additional point I'd note, is that MANETs attached to the
>> Internet are almost exclusively viewed as stub networks (for
>> reasons of bandwidth and reliability at the least).

> Is it an assumption that a MANET will only function as a stub network,
or
> is it an enforceable restriction?  For example, is there a mechanism
> that can be used to prevent a MANET from becoming attached at multiple

> points, becoming a transit network?

A MANET may be attached at multiple points and still not be
a transit network; this is generally assumed. Current MANET
routing protocols are dealing with the issue inside the
MANET, and can handle the concept of multiple gateways.
Ensuring that the MANET isn't used as a transit network
is down to the gateways not putting any entries in their
routing tables for non-MANET destinations with next hop
in the MANET. This is down to the gateways knowing which
are MANET addresses (or those MANET addresses being unknown
to the non-MANET routing protocol used by the gateway
on its Internet side). This may be pre-configured in some
systems, but existing MANET autoconf work on which work
will be based assumes that if we have multiple gateways
that some sort of coordination between them is needed,
this would be easily picked up from that.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 10 Oct 2005 10:20:06 -0400

First MANET is an overloaded term.  A network can be Ad Hoc and not
mobile.  Also Bernard's questions are absolutely on target, each point
is like a specific thread I believe for discussion.  In another forum
and body that is working the deployment of mobile networks for defense
and disaster relief I am part of we have removed the term MANET
completely for technical clarity and analysis, and replaced it with two
terms being Network and Node Mobility and then Ad Hoc Networks.  The two
are orthogonal.  This is not a negative to the fine work in MANET WG,
the terminology was proper given the start date of this in the IETF many
years ago. Also there are two commercial forces that affect deployment
which will come back to us in some form as a standards body.  First SI
solutions that build ad hoc nets today and assume base station exists
with radios, which I questioned at Autconf MANET in Paris and believe
that assumption should change. The reason is sensor technology can now
develop tiny base stations that can act as APs for the radios, thus
changing how multi-hop convergence is approached (routing vs. node
discovery)  Second force are vendors building MESH network solutions
using peer-to-peer mode.  These two forces are not using Ad Hoc networks
in the same way.  

Also in the above referenced body we have removed the connotation of a
"stub" network from both the lexicon or architecture view perspectives.
The reason is that it implies a connection is permanent to a fixed
network and that is not a good view for emerging Ad Hoc Networks that
are also mobile.  

Regarding using Ad Hoc networks as transit networks is very important
discussion, and the views in industry are mixed.  I personally believe
this must be supported for emergency preparedness reasons and I can come
up with many others, and that the IETF community needs to develop Ad Hoc
network specs, ops views, etc that include viewing Ad Hoc nets as
transit providers.  This will have much debate is my guess.

The question I have now is what do we do with conversations from this
list regarding feedback to IETF WGs?

thanks
/jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Dearlove, Christopher (UK)
> Sent: Monday, October 10, 2005 8:54 AM
> To: Bernard Aboba; [email-masked]
> Subject: RE: [Int-area] Re: AUTOCONF charter
> 
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 10 Oct 2005 15:48:18 +0100

> transit providers.  This will have much debate is my guess.

I would separate this into two cases, one being an AHN that is a transit
to another AHN, which I would be interested in (or more generally,
AHNs which collectively are a stub, but individually may be transit
networks), the other being an AHN with multiple connections to the
fixed Internet (or any other network with significantly greater
stability, reliability and/or - usually and - bandwidth) the AHN acting
as a transit for the other network. The latter I'd be happy to exclude.
I'd postpone considering the former too if it helped the process along
(or include it if that helped the proces along, but that seems less
likely).

[Incidentally I take your point about there being a logical difference
between MANETs and AHNs and have used the latter above. However in
practice the distinction blurs, I've presented results from a real
network which had non-mobile nodes, but was a non-static network
- and that was before allowing nodes to fail. I think what you really
want are protocols that can be adapted - or better yet adapt themeselves
- to the range of conditions, and I hope at least some of this will
come out in Standards Track routing protocols. But that's off the point
here I think, hence the brackets.]