Subject: [Autoconf] Multicast confusion between MANET Arch and AUTOCONF Problem Statement

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 16:19:41 +0100

I think there may be a confusion with respect to the interpretation of
multicast in draft-ietf-autoconf-manetarch-07.txt vs
draft-ietf-autoconf-statement-02.txt.

It seems as if the manetarch accepts that link-layers have a well 
defined multicast behaviour whereas the problem statement doesn't.

autoconf-statement:
> Traditional solutions assume that a broadcast directly reaches every 
> router or host on the subnetwork, whereas this generally is not the 
> case in MANETs (see [2]).

So a broadcasted message (a special case of multicast) will not reach
every host on the MANET subnet.

[2] autoconf-manetarch:
> Link-local Multicast/Broadcast Scope On a MANET interface, a packet
> sent to a link-local multicast or all-ones broadcast address reaches
> the MANET interfaces of neighboring MANET routers...

So it actually does.

I personally think that the autoconf-manetarch definition is more inline
with how I see relationships between link-layer multicast and IP multicast.

Or maybe we could define 'subnet' to be a set of hosts and routers
linked together by the same link-layer technology where a multicast
behaviour is well defined.  Or similar?

What do you think?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 16:40:22 +0100

I think the confusion is related with having two models, e.g. 802.11 BSS/ESS
and IBSS. BSS/ESS has coordination function and the IP subnet model works
quite well. IBSS is also called ad-hoc mode.

With IBSS, fully mesh is not guaranteed. Here we use the MANET protocols for
end-to-end connectivity.

Now, the MANET protocols are evolved and can be used to connect nodes on
different segments, like classical IP routing protocols.

Maybe the two documents are describing the IBSS / ad-hoc mode. I agree on
adding text that there is a need for ad-hoc networking for the other mode
also. 
Just look at your desk and see the need for this;-)

Teco.

> -----Oorspronkelijk bericht-----
> Van: Alexandru Petrescu [mailto:[email-masked]]
> Verzonden: dinsdag 20 november 2007 16:20
> Aan: [email-masked]
> Onderwerp: [Autoconf] Multicast confusion between MANET Arch and
> AUTOCONF Problem Statement
>

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Tue, 20 Nov 2007 16:49:02 +0100

Hi Alex, 

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: dinsdag 20 november 2007 16:20
> To: [email-masked]
> Subject: [Autoconf] Multicast confusion between MANET Arch 
> and AUTOCONFProblem Statement
> 
> I think there may be a confusion with respect to the 
> interpretation of multicast in 
> draft-ietf-autoconf-manetarch-07.txt vs 
> It seems as if the manetarch accepts that link-layers have a 
> well defined multicast behaviour whereas the problem 
> statement doesn't.
> 
> autoconf-statement:
> So a broadcasted message (a special case of multicast) will 
> not reach every host on the MANET subnet.

"link" versus "subnetwork" are distinct notions, aren't they? What is
left of a "subnetwork" in an environment where \128 (\32 for IPv4)
prefixes are configured on MANET interfaces? If your local interface is
the only one in the subnet, then all interfaces in the subnet are
trivially reachable :-) "Link" is something else...

> > the MANET interfaces of neighboring MANET routers...

No, not all interfaces of all MANET routers. Just those of the
*neighbo(u)ring* MANET routers. See MANET architecture for a definition
of neighbo(u)r.
 
> I personally think that the autoconf-manetarch definition is 
> more inline with how I see relationships between link-layer 
> multicast and IP multicast.
> 
> Or maybe we could define 'subnet' to be a set of hosts and 
> routers linked together by the same link-layer technology 
> where a multicast behaviour is well defined.  Or similar?
> 
> What do you think?
> 
> Alex

Just my 2 cents,
Ronald

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 16:51:18 +0100

Thanks Teco, sounds as what I would suppose too... but I'll wait for 
comments from authors see what the intended meaning was.

> quite well. IBSS is also called ad-hoc mode.

I think in wifi's both adhoc and infrastructure modes the link-layer's 
multicast behaviour is well defined.

If a more-than-50meters extension of an adhoc wifi network not 
accompanied by the right IP subnet structuring then there's obviously a 
problem with the IP subnet structuring: every 50m there should be one 
different IP subnet and there should be routers in between the 50meters 
areas.

> Maybe the two documents are describing the IBSS / ad-hoc mode.

I doubt so too, let's see from authors.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 17:11:58 +0100

Velt, R. (Ronald) in 't wrote:
> Hi Alex,
> 
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: dinsdag 20 november
>> 2007 16:20 To: [email-masked] Subject: [Autoconf] Multicast
>> confusion between MANET Arch and AUTOCONFProblem Statement
>> 
>> I think there may be a confusion with respect to the interpretation
>> of multicast in draft-ietf-autoconf-manetarch-07.txt vs 
>>> router or host on the subnetwork, whereas this generally is not
>>> the case in MANETs (see [2]).
>> So a broadcasted message (a special case of multicast) will not
>> reach every host on the MANET subnet.
> 
> prefixes are configured on MANET interfaces? If your local interface
> is the only one in the subnet, then all interfaces in the subnet are 

Right... :-)

But this sounds as special cases.

Maybe simple a 1-1 mapping between link and subnet would be easier.
Just have a link and a subnet be the same, and a simple prefix assigned
to it.  And see these problems first.

The MANET I'd build would surely have a prefix for a subnet on a link 
and /128 addresses for each entity.  This should work.

>> [2] autoconf-manetarch:
>>> Link-local Multicast/Broadcast Scope On a MANET interface, a
>>> packet sent to a link-local multicast or all-ones broadcast
>> address reaches
> *neighbo(u)ring* MANET routers. See MANET architecture for a
> definition of neighbo(u)r.

Ok, manetarch:
> Neighbor In the context of routing, two routers are neighbors if one
> can send/receive routing protocol IP packets to the other without 
> passing through any intermediaries at the same layer.

Ok but in the Internet Area a Neighbor is from rfc4861:
> neighbors   - nodes attached to the same link.

This different 'Neighbor' definition is potentially  another source of
confusion when talking to each other.

I think manetarch may mean actually that a Neighbor is an entity within
a close physical distance, whereas an RFC4861 Neighbor is not
necessarily close by.

BEsides, the definition above is unclear because of that "at the same
layer".  Which layer?  IP?  Link?  Would a link-layer device bridging
messages to a remote-distance entity make this latter a Neighbor?

Wouldn't it sound better like: "CloseEntity: two routers are
closeentities if one can send/receive link-layer multicast messages
to/from the other".

If we don't clarify this it will always pop up as a confusing item when
saying 'Neighbor'.

Thanks,

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 17:28:45 +0100

> If we don't clarify this it will always pop up as a confusing item when

Now you are confusing me.
Neighbors on satcom link could not be that close, but can hear each other.
If not, they are not neighbors.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 17:43:11 +0100

Teco Boot wrote:
>> If we don't clarify this it will always pop up as a confusing item
>> when saying 'Neighbor'.
> 
> Now you are confusing me. Neighbors on satcom link could not be that
> close, but can hear each other.

Right, and that's the Internet Area ND rfc4861 definition of a Neighbor.

> If not, they are not neighbors.

Right, and they can't be "closeentities" because they're remote :-)

How else can we define 'Neighbor' in accordance to rfc4861?

How else can we define new AUTOCONF entity terms?

Does SATCOM or IP-over-DVB/MPEG2 or IP-over-UDLR have a definition one
could reuse?

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 17:49:40 +0100

> Verzonden: dinsdag 20 november 2007 17:43
> Aan: Teco Boot
> CC: 'Velt, R. (Ronald) in 't'; [email-masked]
> Onderwerp: Re: [Autoconf] Multicast confusion between MANET Arch and
> AUTOCONFProblem Statement
> 
> Teco Boot wrote:

Let's stick on MANET and use for example NHDP definition:

   Symmetric link  - A link where both MANET interfaces are heard by the
      other.

   1-hop neighbor  - A node X is a 1-hop neighbor of a node Y if a MANET
      interface of node X is heard by a MANET interface of node Y.

   Symmetric 1-hop neighbor  - A node X is a symmetric 1-hop neighbor of
      a node Y if a symmetric link exists between a MANET interface on
      node X and a MANET interface on node Y.

   Symmetric 2-hop neighbor  - A node X is a symmetric 2-hop neighbor of
      a node Y if node X is a symmetric 1-hop neighbor of a symmetric
      1-hop neighbor of node Y, but is not node Y itself.

   1-hop neighborhood  - The 1-hop neighborhood of a node X is the set
      of the 1-hop neighbors of node X.

   Symmetric 1-hop neighborhood  - The symmetric 1-hop neighborhood of a
      node X is the set of the symmetric 1-hop neighbors of node X.

   Symmetric 2-hop neighborhood  - The symmetric 2-hop neighborhood of a
      node X is the set of the symmetric 2-hop neighbors of node X.
      (This may include nodes in the 1-hop neighborhood, or even in the
      symmetric 1-hop neighborhood, of node X.)

Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 18:23:28 +0100

>       interface of node X is heard by a MANET interface of node Y.

Risking to say 'neighbor' abbreviating '1-hop neighbor' and confusing 
that 'neighbor' with a Neighbor of RFC 4861.

What does 'hearing' mean.  It sounds as a radio concept.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 18:31:23 +0100

> that 'neighbor' with a Neighbor of RFC 4861.

Yes, I would say "neighbor" is "Symmetric 1-hop neighbor" unless otherwise
specified.
In many cases, it is just a generic term for some node that is somewhat
reachable.

> What does 'hearing' mean.  It sounds as a radio concept.

Not by definition.
I would imagine IP over acoustics.
Then we can hear how chatty a protocol is!

Teco.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 20 Nov 2007 18:42:07 +0100

I agree with Ronald. If there was already an easy definition of what is 
a "MANET link" then the architecture document would not be needed, would it?
Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 19:54:05 +0100

Teco Boot wrote:
>>> Symmetric link  - A link where both MANET interfaces are heard by
>>> 
>>> 
>> the
>>> other.
>>> 
>> Risking to say 'neighbor' abbreviating '1-hop neighbor' and 
>> confusing that 'neighbor' with a Neighbor of RFC 4861.
> 
> Yes, I would say "neighbor" is "Symmetric 1-hop neighbor" unless 
> otherwise specified. In many cases, it is just a generic term for 
> some node that is somewhat reachable.

That is your opinion and I respect it.

My opinion is that a Neighbor is something that runs ND.  And whenever
I'll say that your Symmetric 1-hop neighbor multicasts a RS or receives
a multicast RA you'll say this autoconfig doesn't work in MANET -
_because_ a MANET Neighbor is different :-)

This is a strong sign to me that I can't understand and be understood in
this space.

> Not by definition. I would imagine IP over acoustics. Then we can 
> hear how chatty a protocol is!

Acoustics? Hehe :-)

Somebody interested in wireless high quality audio will not run IP over
it, not even a MAC - not these days. (compare the audio output by a 5GHz
MAC-free wireless headphone to that of a bluetooth MAC-based audio
profile headphones).  Electronics need to develop more to create a need
for MAC and for IP over acoustics :-)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 20:11:53 +0100

Emmanuel Baccelli wrote:
> I agree with Ronald. If there was already an easy definition of what 
> is a "MANET link" then the architecture document would not be needed,
>  would it?

I agree with Ronald too that more special mappings between subnets and
links can be made: two subnets on one link, or two links on one subnet.

But I would like the description of the link we're dealing with to be
more precisely described.  We can't simply say that we deal with all
types of wireless and wired links.  That's way too generic.

Saying a link is asymmetric (X reaches Y, Y reaches Z but Z doesn't
reach X) without saying at _what_ layer is it asymmetric: IP or MAC? I
suppose you mean WiFi MAC adhoc mode being asymmetric (3 laptops with
wifi cards in adhoc mode placed linearly at 50m between each).

That is a problem for the link-layer, which can be solved by using a
802.1d bridge on the Y node.

If we want to solve that problem at IP layer then the first thought is
to make a subnet between X and Y and another one between Y and Z.  I
think this is a good IP solution.

But obviously if one makes an IP datagram repeater on Y we obviously get
a link-layer structuring problem with too many packets in the air and no
multicast structure.

I'm trying to say there are simple solutions to that asymmetric
reachability problem that only involve good simple address planning, not
any new protocol.

But if we don't have good agreed definitions then it all turns round and
round.

Sorry, I can't seem to make myself clear...

Alex

>> "link" versus "subnetwork" are distinct notions, aren't they? What 
>> is left of a "subnetwork" in an environment where \128 (\32 for 
>> IPv4) prefixes are configured on MANET interfaces? If your local 
>> interface is the only one in the subnet, then all interfaces in the
>>  subnet are trivially reachable :-) "Link" is something else...
>> 
>>> [2] autoconf-manetarch:
>>> I personally think that the autoconf-manetarch definition is more
>>>  inline with how I see relationships between link-layer multicast
>>>  and IP multicast.
>>> 
>>> routers linked together by the same link-layer technology where a
>>>  multicast behaviour is well defined.  Or similar?
>>> 
>>> What do you think?
>>> 
>>> Alex
>> 
>> Just my 2 cents, Ronald
>> 
>> 
>> _______________________________________________ Autoconf mailing 
>> list [email-masked] 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www1.ietf.org/mailman/listinfo/autoconf
>

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 20:19:24 +0100

Hi Alex,

I think we agree on that the current PS is focused on "classical MANET". And
it misses another ad-hoc network type, e.g. using ad-hoc multihop
connectivity to the Internet.
But don't say the term Neighbor is not clearly defined in a "classical
MANET" context.

I am with you on the fact that the term Neighbor is well defined in NDP
context also.
This shall be included as the other type of ad-hoc network is described.
Maybe we need consensus in Autoconf working on this type of network first.

Teco.

> Verzonden: dinsdag 20 november 2007 19:54
> Aan: Teco Boot
> CC: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 20:39:10 +0100

> Maybe we need consensus in Autoconf working on this type of network first.

I completely disagree with you on this topic.

I think we should look for consensus in the WG.

My preferred question is whether people agree that the Neighbor runs 
Neighbor Discovery.

Other questions can be formulated.

Alex

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 21 Nov 2007 10:17:45 +0100

> connectivity to the Internet.

I do not agree with this judgement. Can you tell me what is the 
difference between the connected MANET scenario explicitely described in 
th scope of the PS, and what you mean by"ad hoc multihop connectivity to 
the Internet"?

Emmanuel