Subject: [Autoconf] draft-clausen-manet-linktype

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 4 Nov 2008 10:51:09 +0100

Folks,

As you know, we need to make progress on the architectural issues,  
before we can hope to make progress on other matters within this WG.  
One of the requests that have been made to us has been to "describe  
the MANET Link Type", and so I have written together a strawman text  
to this effect:

	http://www.ietf.org/internet-drafts/draft-clausen-manet-linktype-00.txt

Feedback is, obviously, welcome -- preferably on the list such that  
we could be prepared spend time on this also in MN.

Note, however, that this is an individual I-D.

I'd also like to draw your collective attention to:

	http://www.ietf.org/internet-drafts/draft-iab-ip-model-evolution-01.txt

Which has served as a source of inspiration for the linktype text.

Thanks,

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

---

From: mase <[email-masked]>
Date: Sun, 16 Nov 2008 11:13:48 +0900

Dear Thomas,

I think that your document is very useful to deepen understanding 
about what is MANETs.

I have some commnets.
I think that Sec. 4 MANET Interface discusses more than MANET 
interface, that is, MANET link type. This section may present 
essences of the MANET link type.
I almost agree what are written here, but hope that we could a little 
bit clearer the essence of MANET link type. I would propose the 
following remark to be included in the texts.

The set of neighbors of each MANET interface may be position 
(attachment to a link)- and time-dependent.
The nature of position-dependency in MANETs is clearly described in 
Sec. 4. Time-dependency occurs for example due to interference in 
wireless environment. This is different from things discussed in Sec. 
5. Note that , in the Ethernet-like link, the set of neighbors of 
each MANET interface is position- and time-independent in principle.

The word "position" is used in Sec. 5. So, the remark above also 
contributes to improves consistency.

I also would propose that Sec. 6 is entitled "The MANET link Type 
Characteristics". It should be noted in Sec. 6 that  the most of 
characteristics of MANET link type, listed here, occur as the result 
of the nature of MANET link type proposed above.

Thanks,
Kenichi

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Nov 2008 12:24:57 +0100

> we could be prepared spend time on this also in MN.

Hi ThomasC,

I went quickly through the draft, thank you for posting it.  I also
think gathering a good description on the link types addressed by MANETs
is helpful towards profiling AUTOCONF goals.

I have one minor feedback, in general - could we list, perhaps in a
separate section, the names of the link layer technologies considered as
MANET, and targeted by AUTOCONF and IPv6 goals.

I could start with:

IEEE 802.11
IEEE 802.15         IEEE 802.15.4-2006
Bluetooth SIG       BLUETOOTH SPECIFICATION Version 2.1 + EDR
Wireless USB
WirelessHD
ANT
W.I.N.D.
Other?

What do you think?

Otherwise, just some suggestions of clarifications of some possible nits:
> IPv6 Link Local Multicast (FFx2::) are specified to not be forwarded

That's right, but for better readability probably saying "IPv6 multicast
  address with link-local scope (prefixed by FF02:: or FF12::)" would be
better because, for example, there's no IPv6 multicast address with
link-local scope prefixed by FF22:: - only FF02:: and FF12:: could
exist, as of RFC3513.

> While the MANET interfaces of nodes B and C in Figure 5 may not be 
> configured with addresses from within the same subnet, these may 
> still communicate e.g. as point-to-point links where the two 
> endpoints have addresses from unrelated address spaces.

Let me try to understand the last part: two endpoints on a
point-to-point link have addresses from unrelated address spaces?  For
example on a ptp link node A has address 1::1/64 and node B has address
2::1/64?  I think that's not possible, because the ptp link has a common
subnet prefix and the ends need to have addresses like 1::1/64 and
1::2/64 (same 'address space' 1::/64 subnet address); ptp links often
have same subnet address, eg IPv6 over PPP stateless autoconfiguration.

Or maybe I don't understand well the 'address space' in this context here.

Nit, Figure 3:
>             -------+-------     ---+-------             Transmission
>      ------+------- -------+------- -------+-------         Ranges
> 
>           \|/     \|/     \|/     \|/     \|/
>            |       |       |       |       |
>          +-+-+   +-+-+   +-+-+   +-+-+   +-+-+
>          | A |   | B |   | C |   | D |   | E |
>          +---+   +---+   +---+   +---+   +---+
>
> In this simple network, a transmission by the node C reaches only 
> nodes B and D on the MANET link, due to the limited transmission 
> range of the wireless broadcast interface. Similarly, a transmission 
> from node B reaches only nodes A and C and a transmission by node D 
> reaches only node E- the latter might be due to environmental
>   interference or obstacles, transmission power levels or antenna
>   properties of node C or D (e.g. directional antennas on either or
>   both of C and D).

The picture makes think there's a directional antenna only on D, not on 
C, and oriented towards E.

Also I wanted to ask whether this picture depicts an on-off kind of 
behaviour (no packet sent by D reaches C, whereas all from C reach D) or 
is it more like an uneven bandwidth (D-to-C 1Mbit/s whereas C-to-D 
10Mbit/s).  This uneven behaviour is typical in wifi... but not sure 
which link-layer technology is thought of in the Figure 3's example?

Just some notes...

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://www.ietf.org/mailman/listinfo/autoconf

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 17 Nov 2008 12:41:07 +0100

Alex,

Thanks for your comments. See below.

On Nov 17, 2008, at 12:24 PM, Alexandru Petrescu wrote:

>> before we can hope to make progress on other matters within this  
>> WG. One of the requests that have been made to us has been to  
>> "describe the MANET Link Type", and so I have written together a  
>> strawman text to this effect:
>> Feedback is, obviously, welcome -- preferably on the list such  
>> that we could be prepared spend time on this also in MN.
>
> Hi ThomasC,
>

I am actually not a fan of listing explicitly such. In part, because  
I do not think that this list necessarily complete neither now nor  
"in the immediate future", and in part because I think that we are  
trying at a more generic description than a specific L2.

> link-local scope prefixed by FF22:: - only FF02:: and FF12:: could

Good point, I'll do that in an update.

> Or maybe I don't understand well the 'address space' in this  

No, you understand it quite well. It is quite possible to run links  
between routers in this way (and, I know of at least one case in the  
IETF wherein the link between a router and hosts is also run in that  
way).

>> range of the wireless broadcast interface. Similarly, a  
>> transmission from node B reaches only nodes A and C and a  
>> transmission by node D reaches only node E- the latter might be  
>> due to environmental
> The picture makes think there's a directional antenna only on D,  
> not on C, and oriented towards E.

That could be the case, yes.
> behaviour (no packet sent by D reaches C, whereas all from C reach D)

I'd say "yes"

> or is it more like an uneven bandwidth (D-to-C 1Mbit/s whereas C-to- 
> D 10Mbit/s).

I'd say "yes" again.

> This uneven behaviour is typical in wifi... but not sure which link- 
> layer technology is thought of in the Figure 3's example?

No specific L2, fig. 3 is trying to describe a "general type of  
behavior, which a MANET protocol must be designed to accommodate".

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 17 Nov 2008 14:47:36 +0100

> That could be the case, yes.

Directional antennas provide beam forming for transmit and receive.
It could be the case that there is a directional antenna, but directional
antennas do NOT introduce unidirectional reachability. Or physical laws are
updated recently...

Perhaps D sends with lower power than C, or there is noise or interference
on C. Or C has low sensitive receiver.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Nov 2008 14:50:12 +0100

Thomas Heide Clausen wrote:
[listing specific link-layer types]
> 
> I am actually not a fan of listing explicitly such. In part, because I 
> do not think that this list necessarily complete neither now nor "in the 
> immediate future", and in part because I think that we are trying at a 
> more generic description than a specific L2.

It was not the intention to make it complete, but to have a start list 
of such things.  To make it more complete one would simply add more 
items.  Which link you think is not and needs to be present on that list?

[...]
> IETF wherein the link between a router and hosts is also run in that way).

I think a point-to-point link between routers still has a common subnet 
address, or otherwise one should disable DAD and other ND parameters. 
It could be advantageous to say so, because it also brings in an 
opportunity to talk about ND, otherwise absent from the draft.

>> The picture makes think there's a directional antenna only on D, not 
>> on C, and oriented towards E.
> 

In that case one wouldn't say 'either or both of C and D', just 'on D'.

>> behaviour (no packet sent by D reaches C, whereas all from C reach D)

Well I think that's a UDLR link, and in this case it should be qualified 
as such.  UDLR may be useful to cite here, there are RFCs about it, 
mostly from the satellite links worlds.

>> or is it more like an uneven bandwidth (D-to-C 1Mbit/s whereas C-to-D 
>> 10Mbit/s).
> 
> I'd say "yes" again.

Sorry, can't be both.  A link is either UDLR (like satellite) or 
asymmetric (like ADSL).  There don't exist links which are both UDLR and 
ADSL at the same time.

>> This uneven behaviour is typical in wifi... but not sure which 
>> link-layer technology is thought of in the Figure 3's example?
> 

I do subscribe to the generic aspect, and the intention to have IP run 
over all types of links pertinent to MANET.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 17 Nov 2008 13:58:07 -0000

> items.

I agree with Thomas, attempting to list possible systems is not a
good idea. Quoting one or two examples (e.g. 802.11) to give an
example of the problems is useful. But any attempt to provide anything
comprehensive is doomed to double failure. Failure to catch everything,
and failure in that it might suggest things that aren't listed aren't
included. That does mean that when quoting an example, it is important
to make clear it is just that and no more.

> Which link you think is not and needs to be present on that list?

I can think of some. But I don't intend to list them.

********************************************************************
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.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Nov 2008 15:02:52 +0100

> to make clear it is just that and no more.

I wouldnt go as far as trying to make it comprehensive list, of course. 
  But doing my best - yes.  I really would list the links which concerns 
us.  E.g. I'm concerned by WiFi and Bluetooth in my work - none is UDLR, 
thus no need to mention the on-off kind of behaviour.  I'm not concerned 
by satellite.

You'd be concerned by other links, welcome to add it.

Hiding my head in the sand about which link layer I'm using, in a 
document about link layer types... risks me being taken not seriously.

> I can think of some. But I don't intend to list them.

Why?  Is it because the confidentiality of the type of work?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Nov 2008 15:13:32 +0100

> on C. Or C has low sensitive receiver.

I kind of agree Teco.  My issue is just to have a coherent description 
with a particular case with the particular whys, coherent, 
non-contradictory.

For example, we could say: for equally distanced B-C-D, a packet sent by 
C arrives faster to B than to D; this is so because of noise 
interference on D.  An ND implication is that DAD timers on C and D may 
need to reflect this difference (be different).

But I'm not keen on saying: packets from C to B may sometimes arrive 
whereas from D to B may not, because some interference may happen or 
because D's or C's antennas may be more directional than others.  This 
description _is_ generic, but is it helpful enough to setting AUTOCONF 
goals?

This would also give an opportunity to mention DAD, otherwise not 
mentioned in the draft.

Just some thoughts...

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 17 Nov 2008 14:16:55 -0000

> document about link layer types

It's not a document about link layer types. It's a document about
the broad characteristics of wireless links, and how they differ
from typical wired links. What's important is that there are some
widely use links (and just 802.11 would be sufficient for this to
be true) that do not behave like an Ethernet. And, despite that IP
was originally intended to be a network layer running over a link
layer without knowing what that link layer is, protocols have
developed assuming that all the world is like an Ethernet. But
(and it's pretty elementary stuff to anyone who works with radio
systems) all the world is not like an Ethernet. However it is
clear that this has to be said, and spelled out. And as I (not
an author of this document of course) see it, that's the job of
this document. Then (the architecture document) if links are not
all like Ethernets, what are the consequences? Precisely what
long list of wireless systems have those consequences isn't the
point.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 17 Nov 2008 16:16:10 +0100

On Nov 17, 2008, at 15:02 PM, Alexandru Petrescu wrote:

>>> of such things.  To make it more complete one would simply add  
>>> more items.
> I wouldnt go as far as trying to make it comprehensive list, of  
> course.  But doing my best - yes.  I really would list the links  
> which concerns us.  E.g. I'm concerned by WiFi and Bluetooth in my  
> work - none is UDLR, thus no need to mention the on-off kind of  
> behaviour.  I'm not concerned by satellite.
>

I think that this is not a matter of "hiding ones heads" anywhere,  
Alex. The intent is to say that "Here's the abstract set of L2  
properties that we're designing MANET protocols to. Any link-layer  
providing this (or better), will work."

I'm on board with Chris on the "cite one or two examples", however I  
do not believe that we can do a reasonable job of enumerating all  
possible L2s that exist, has existed and will exist. I think that  
we're better served by being a notch more abstract.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 17 Nov 2008 16:17:41 +0100

> long list of wireless systems have those consequences isn't the

Chris is right on the spot with these remarks, at least as far as the  
intent of the author of the document.

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 17 Nov 2008 15:20:00 -0000

> I'm on board with Chris on the "cite one or two examples"

What I didn't say however, was that, while 802.11 is the
most obvious example, a second example that's significantly
different, while still being clearly appropriate, would have
the advantage of making it clear that this is not just about
802.11. 802.15.4 might serve, or possibly a non-IEEE example.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 17 Nov 2008 08:20:39 -0800

Hello folks,

I also agree that it would be a mistake to try to list those
wireless media for which <draft-clausen-manet-linktype>
would apply.

In fact, the problem is really quite difficult, if not intractable.
Are 802.11a and 802.11b two different physical media?
For the purposes of such a list, do different frequency bands
present two different media?  Two different codes?

I remember a previous discussion about horizontal versus
vertical handovers.  That discussion was terminated by fiat
without being able to provide a normative description about
whether such media were similar enough to have horizontal
handovers.  Rough consensus seemed to be that it was time
to publish the document anyway :-)

We shouldn't go there with this document.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Nov 2008 18:04:53 +0100

> present two different media?  Two different codes?

If the a/b difference is a problem then the solution is at their level 
and not above.  I.e. IP can't fix the differences in coding or frequency.

IP can't solve Figure3 B-C-D MANET Interface problems related to antenna 
directionality, radio interference and transmission range 
samedistance-differentdelays problems.

I may be way off the common thought here...

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 17 Nov 2008 17:22:33 -0000

> and not above.  I.e. IP can't fix the differences in coding or
frequency.

I think you've missed Charlie's point, which isn't that
802.11a/b is a problem as a link layer, it's that whether
802.11a and 802.11b are one standard or two (or more) is
not clear, in fact it's not even a well-defined question.

According to http://www.theregister.co.uk/2008/11/13/wimax_again/
the FDD and TDD modes of IEEE 802.16e-2005 are being considered
as separate standards by the ITU for IMT-2000 inclusion. This
is not directly relevant to this document, but illustrates that
"how many standards" is not just a technical question.

However please note that, of my knowledge, this report may or may
not be accurate, I have no personal knowledge of the issue.

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 17 Nov 2008 19:12:07 +0100

> not clear, in fact it's not even a well-defined question.

[Teco:] 
Agreed.
By the way, the 11a / 11b are "retired" amendments, both are "rolled into"
in IEEE 802.11-2007.
Terms "retired" and "rolled into" are out of 802.11-2007.

Far more important is the two modes 802.11 can operate in: IBSS and BSS.
The MANET link would only apply to IBSS:
>>> IEEE 802.11-2007:
3.5 ad hoc network: Often used as a venacular term for an independent basic
service set (IBSS).
<<<

An IBSS is NOT equivalent with a MANET:
>>> IEEE 802.11-2007:
An IBSS consists of STAs that are directly connected.
<<<
The target of MANET routing is repairing connectivity problems when STAs are
out of reach from each other. But this implies that the topology is not in
line with the service definition for IBSS.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 17 Nov 2008 19:14:47 +0100

> samedistance-differentdelays problems.

Again: the unidirectional problem CANNOT be caused by directional antennas.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Nov 2008 19:32:32 +0100

Christopher, please allow me top-posting in this case.

I do not agree with this document.  Although I may have seen in practice 
some of the problems mentioned in this document (e.g. the B-C-D 
asymetricity in Figure 2) the solutions were not at IP level but below 
(e.g. MAC repeater, antenna range extender).  IPv6 works ok over WiFi.

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 17 Nov 2008 19:40:48 +0100

Alex,

You are absolutely right, IP works fine over some classic WiFi  
configurations, such as hosts-accesspoints or a fully connected graph  
of hosts. The kind of connectivity that this document is describing  
is, however, neither of these two.

Thomas

On Nov 17, 2008, at 19:32 PM, Alexandru Petrescu wrote:

> I do not agree with this document.  Although I may have seen in  
> practice some of the problems mentioned in this document (e.g. the  
> B-C-D asymetricity in Figure 2) the solutions were not at IP level  
> but below (e.g. MAC repeater, antenna range extender).  IPv6 works  
> ok over WiFi.
>
> Alex
>

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 17 Nov 2008 20:03:17 +0100

> IPv6 works ok over WiFi.

Alex,

Are you trying to confuse us?
Please read my posting on IBSS and the requirement on direct STA - STA
connectivity.
Where is described how to run IPv6 over a network that isn't?
There are many solutions, and running a MANET routing protocol is just one
of them.

Teco.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 17 Nov 2008 20:33:00 +0100

Hi Teco,

> line with the service definition for IBSS.

I'm not sure I got this right. AFAIK, in a practical deployment of an
IBSS wireless network, you might end up with nodes that are not directly
reachable but belong to the same IBSS. Since there is no central entity
(like the AP), there is no way of ensuring that all nodes from the same
IBSS have direct connectivity to each other, right?

Carlos

-- 
 Carlos Jesús Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 17 Nov 2008 21:35:12 +0100

> > The target of MANET routing is repairing connectivity problems when
> > STAs are out of reach from each other. But this implies that the
> > topology is not in line with the service definition for IBSS.
> 
> IBSS wireless network, you might end up with nodes that are not
> directly reachable but belong to the same IBSS. Since there is no
> central entity (like the AP), there is no way of ensuring that all
> nodes from the same IBSS have direct connectivity to each other, right?

I agree on that theory and real world problems could deviate.
But I think that it is important to make clear what the IEEE standard
describes.

And can someone help me what "venacular" means? Maybe it is a typo and
should be "vernacular".

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Nov 2008 23:24:01 +0100

Teco Boot wrote:
[...]
> An IBSS consists of STAs that are directly connected.
<<<<
> STAs are out of reach from each other.

I don't agree.  When STAs are out of reach of each other it's because
they're too far away one from the other.  When STAs are too distanced
routing protocols don't help.  One needs basic connectivity when things
are too far away.  To obtain connectivity between STAs too distanced
(more than 50m typically) one adds a longer range directional antenna,
or higher-power amplifiers or repeaters (this latter tool being the same
as with too long Ethernet cables).  O'Reilly published some time ago
some text in a book about practicals how to make wifi community networks
over wider, kilometer-range areas, none uses  MANET protocols but
antennas in chips tins yes, if you wish.

> But this implies that the topology is not in line with the service 
> definition for IBSS.

I don't understand... actually I don't know what's the service of an
IBSS (Independent Basic Service Set), I just know IBSS is like when we
want to run a set of STAs without AP... but not sure what's that
service... maybe it's a link-layer term that is irrelevant here.

Alex

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Mon, 17 Nov 2008 23:24:13 +0100

Hi,

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Carlos Jesús 
> Bernardos Cano
> Sent: maandag 17 november 2008 20:33
> To: Teco Boot
> Cc: [email-masked]
> Subject: Re: [Autoconf] draft-clausen-manet-linktype
> 
> Hi Teco,
> 
> I'm not sure I got this right. AFAIK, in a practical 
> deployment of an IBSS wireless network, you might end up with 
> nodes that are not directly reachable but belong to the same 
> IBSS. Since there is no central entity (like the AP), there 
> is no way of ensuring that all nodes from the same IBSS have 
> direct connectivity to each other, right?

That's just because people are extending 802.11 IBSS mode beyond IEEE's originally intended model of usage. MANET is indeed the solution by which connectivity can be achieved even if STA are not in direct reach of each other. However, you might be facing some nasty problems with IBSS splits and merges, Time Stamp Function synchronisation, etc. Whether you come across these is dependent on how well your particular devices / implementations deal with this beyond-the-spec usage.

IEEE 802.11s is another story, of course...

Ronald

> > Teco.
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: Mon, 17 Nov 2008 23:26:51 +0100

> Are you trying to confuse us?

Teco: no, I'm not trying to confuse anybody, sorry for this impression, 
let me try to clarify.

> Please read my posting on IBSS and the requirement on direct STA -
> STA connectivity.

I read it replied separately.

> Where is described how to run IPv6 over a network that isn't?

I think I agree.  One first needs to build a link-layer network before
being able to run IP over it.  This draft's Figure 3 B-C-D is not such a
link-layer network.

> There are many solutions, and running a MANET routing protocol is
> just one of them.

I don't agree.  MANET routing protocol runs at IP layer.  IP layer can't
be used to build link-layer networks.  To build link-layer networks one
uses link-layer tools.  A humble opinion that is.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 17 Nov 2008 23:36:51 +0100

> antennas in chips tins yes, if you wish.

Sorry, I can't follow.
If you want to discuss what functionality the MANET Routing should provide,
please post on MANET ML.

> service... maybe it's a link-layer term that is irrelevant here.

Please read standards before posting.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 17 Nov 2008 23:42:11 +0100

Hi Thomas,

Another topic on your draft.
You suggest using /62 or /63 on non-MANET interfaces. (typo in figure 7, p:3
is /63).

By using these prefix lengths, you exclude SLAAC. SLAAC requires /64 prefix
lengths (RFC2462).
I am not sure this was intended or not.

Regards, Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 17 Nov 2008 23:50:14 +0100

Hi Teco,

Uhmm, I think that was unintended -- fat fingers and all. Sorry.

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 18 Nov 2008 00:01:42 +0100

> One first needs to build a link-layer network before
> being able to run IP over it.  This draft's Figure 3 B-C-D is not such
> a link-layer network.

The manet-linktype I-D describes the behavior as briefly discussed in
RFC4861 section 2.2. Link Types, asymmetric reachability. (check also
errata, http://www.rfc-editor.org/errata_search.php?rfc=4861)
Figure 3 B-C-D is such a link-layer network.

> uses link-layer tools.  A humble opinion that is.

MANET routing protocols provide L3 connectivity over link-layer types with
asymmetric reachability.
No one said that MANET routing protocols would be used for to build
link-layer networks

See also RFC4861 Appendix B, last item, on ND over link types with
asymmetric and non-transitive reachability.

Teco.

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Tue, 18 Nov 2008 00:02:38 +0100

Hi Alex, 

<snip>
> 
> I don't agree.  MANET routing protocol runs at IP layer.  IP 
> layer can't be used to build link-layer networks.  To build 
> link-layer networks one uses link-layer tools.  A humble 
> opinion that is.

IP is well suited for connecting together different links into a
network. That's what it does. Say node A is running PPP over one piece
of wire to node B and PPP over another piece of wire to node C. These
are different links even though the underlying L2 technology is the
same. IP connects the links. The more I think about it, the more I am
inclined to say that there is no such thing as "a MANET link". Instead,
a node sees a time-varying collection of links, one per node it can
reach. The slightly odd thing (and infinite source of confusion) is that
several of these links can be accessed through the same physical
interface.

My 2 cents,
Ronald

---

From: mase <[email-masked]>
Date: Tue, 18 Nov 2008 08:24:38 +0900

>several of these links can be accessed through the same physical

And this single interface can work as that of the router carrying 
packets between these links (This does not occur in wired network).

Kenichi

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 18 Nov 2008 00:50:26 +0100

> packets between these links (This does not occur in wired network).

There are examples of non-fully-meshed wired link-layer networks also, e.g.
NBMA such as X.21, FR and ATM and some broadband access systems. Using
logical interfaces for each P2P link is one way solving problems, but this
could have disadvantages like increased resources on routers.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Nov 2008 02:34:53 +0100

Hi Ronald,

Velt, R. (Ronald) in 't wrote:
> Hi Alex,
> 
> <snip>
>> I don't agree.  MANET routing protocol runs at IP layer.  IP layer 
>> can't be used to build link-layer networks.  To build link-layer 
>> networks one uses link-layer tools.  A humble opinion that is.
> 
> network. That's what it does.

YEs, well suited for connecting one well-formed link to another 
well-formed link.

> Say node A is running PPP over one piece of wire to node B and PPP 
> over another piece of wire to node C.

YEs, ok.

> These are different links even though the underlying L2 technology is
>  the same.

I think you mean to say 'the same technology' to mean it has the same 
name, like úsb', like a ptp link1 over usb and another ptp link2 over 
another usb.  I think you didn't mean to say that two point to point 
links connect over the same medium which looks as ptp from some point to 
another of its points, but shared from some other points to other points 
within same medium.  Such a medium doesn't exist.  Or it's a badly 
formed incomprehensible medium.

> IP connects the links.

Yes, provided the links are each well formed.  Cables that
intermittently connect because of false contacts are not links well
formed and IP can't help with it.

> The more I think about it, the more I am inclined to say that there
> is no such thing as "a MANET link". Instead, a node sees a
> time-varying collection of links, one per node it can reach. The
> slightly odd thing (and infinite source of confusion) is that several
> of these links can be accessed through the same physical interface.

That gets indeed complex :-)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Nov 2008 02:49:20 +0100

Teco Boot wrote:
>> One first needs to build a link-layer network before being able to 
>> run IP over it.  This draft's Figure 3 B-C-D is not such a 
>> link-layer network.
> 
>  RFC4861 section 2.2. Link Types, asymmetric reachability.

I've always wondered what does the rfc4861 asymetricity mean in practice
with respect to IPv6 over Ethernet rfc2464 and wifi.

> MANET routing protocols provide L3 connectivity over link-layer types
>  with asymmetric reachability. No one said that MANET routing 
> protocols would be used for to build link-layer networks

Figure 3 B-C-D of draft-clausen doesn't say an 'asymmetric' link but 
more like an on-off diode type of link whereby B can reach C, C D but B 
can not reach D.  For wifi that's a badly formed link, needs a mac 
repeater or a longer range device.  MANET routing protocols are not for it.

For that matter, the draft doesn't say 'asymmetric' anywhere...

The appendix of rfc4861 ND says:
> Possible extensions for future [ND] study are:
[...]
>     o Adding additional procedures for links where asymmetric and non-
>       transitive reachability is part of normal operations.  Such
>       procedures might allow hosts and routers to find usable paths on,
>       e.g., radio links.

Draft-clausen doesn't cite ND rfc4861.

AUTOCONF tries to autoconfigure stuff, not to improve ND.

It looks difficult to discern.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 18 Nov 2008 04:52:46 +0100

> I think you didn't mean to say that two point to point

Strongly disagree.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 18 Nov 2008 05:13:05 +0100

> with respect to IPv6 over Ethernet rfc2464 and wifi.

There is more on this planet that you are aware of:-)

> can not reach D.

OK, multiple terms are used for the same meaning. Asymmetric is used where
others use unidirectional. See recent postings on this topic.

> For wifi that's a badly formed link, needs a mac

Strongly disagree.

> For that matter, the draft doesn't say 'asymmetric' anywhere...

Strongly disagree.
Please reread the draft, especially section 6.

> It looks difficult to discern.

ND RFC is cited in the Autoconf charter, so is SLAAC (RFCs 2461, 2462).

I think you have "traditional IP networks" (cited from charter) in mind.
Please try to understand what a MANET really is.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 18 Nov 2008 09:51:40 -0000

> repeater or a longer range device.  MANET routing protocols are not
for it.

In many scenarios we don't have the luxury of installing MAC repeaters
etc. we have to live with what we have and make best use of it. In this
context, make best use means construct a MANET.

That MANET may not use asymmetrically available links. But it will
have to cope with that they may exist. In particular 802.11 broadcast
(which you may need to find otherwise unknown neighbours) may have such
propagation.

OLSRv2, for example, creates a network that only uses symmetric links.
But the NHDP component of it has to work even though links may be
asymmetric. NHDP would be a lot simpler if node A, on receiving
from node B could know that it could send to node B without having
to verify that. But of course it can't.

---

From: Ian Chakeres <[email-masked]>
Date: Tue, 18 Nov 2008 06:57:51 -0500

I'd like to start a discussion thread on the naming of this draft/ 
linktype.

I don't think that MANET should be in the name of the linktype. The  
characteristics and constraints of a linktype are not MANET specific.

(I'd also like to repeat that MANET routing protocols will work quite  
happily over other link types as well.)

I would rather describe these links as "non-reflexive and non- 
transitive (wireless) links". I'd also be happy with a nice acronym,  
like NBMA or UDLR.

I'm interested in your thoughts. How do you think we should refer to  
this linktype?

Ian

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 18 Nov 2008 17:47:49 +0100

On Nov 18, 2008, at 12:57 PM, Ian Chakeres wrote:

> (I'd also like to repeat that MANET routing protocols will work  
> quite happily over other link types as well.)
>

Just to point out: the above is explicitly stated in the document, so  
I hope that the parenthesis that Ian bring up is clear enough since  
it's a very important point.

> transitive (wireless) links". I'd also be happy with a nice  
> acronym, like NBMA or UDLR.
>
> I'm interested in your thoughts. How do you think we should refer  
> to this linktype?

In truth, I have no feelings either way on this matter.

As it is, the document is only an individual submission, and does as  
such not represent any official position of the IETF or indeed of any  
working group.

Should a working group wish to adopt the document (and I note from  
the autoconf mailing list discussions that, at least to this IETF  
participant, there seems to be no clear consensus in that direction  
within the autoconf working group, at least), and should that working  
group wish for an alternative name, I would a priori not have any  
objections.

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 18 Nov 2008 16:51:31 -0000

> characteristics and constraints of a linktype are not MANET specific.

This is true.

> happily over other link types as well.)

Except that the definition here is inclusive, i.e. it (by intent)
includes those linktypes.

> transitive (wireless) links". I'd also be happy with a nice acronym,  

Except that the point (I believe) is to support the MANET architecture
document, so it can't be just about the difficult links. And links may
be
non-symmetric (not non-reflexive, see earlier posts) and/or
non-transitive,
they don't have to be both. (A fully acknowledgement based L2 might
be symmetric but non-transitive, for example. I have to admit I don't
have a non-contrived non-symmetric but transitive example.)

I think you're in danger of simultaneously narrowing and widening the
scope (narrower, because only talking about the "bad" links, wider
because not just talking about MANETs) so that it isn't obviously
supporting the MANET architecture document.

What I don't know is if the intent is to agree on "this is what MANET
links are like, and turn it into an RFC the architecture document
depends on, or to use it as a stalking horse to get agreement on what
a MANET link is, and then incorporate that into the MANET architecture
document. In the latter case, considering anything but MANET links is
a red herring, in the former case, yes, it could (but doesn't have to
be) less MANET specific.

---

From: mase <[email-masked]>
Date: Wed, 19 Nov 2008 05:23:43 +0900

At 20:57 08/11/18, Ian Chakeres wrote:
>I'd like to start a discussion thread on the naming of this draft/ linktype.
>

I don't think that the introduction/definition of such a special 
link type is useful for MANET discussions, since MANET protocols can 
work on other link types such as the Ethernet. I rather think that 
it is important to make clear link assumptions or requirements to be 
used for MANET in general.

My sugestions are as follows:

MANET protocols work on any link models,  where each interface has 
at least one other interface to/from which it can send/receive 
packets. These neighbors may change over time.

The link models given above of course inculde the Ethernet model as 
the special case. They also inculde non-reflexive and /or 
non-transitive links you defined.

Kenichi

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Tue, 18 Nov 2008 21:54:45 +0100

Hi Ian, 

> [mailto:[email-masked]] On Behalf Of Ian Chakeres
> Sent: dinsdag 18 november 2008 12:58
> To: [email-masked]
> Cc: Thomas Heide Clausen
> Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming
> 

Shouldn't we agree first that there actually is a link type "previously
known as MANET link"? My working definition for a link would be the one
Dave Thaler gives in draft-iab-ip-model-evolution-01:

"A "link" in the IP service model refers to the topological area within
which a packet with an IPv4 TTL or IPv6 Hop Limit of 1 can be
delivered." (Inherited from RFC4903, but reworded slightly).

Non-transitivity does not seem to fit this definition?
 
> 
> I don't think that MANET should be in the name of the 
> linktype. The characteristics and constraints of a linktype 
> are not MANET specific.

Strictly speaking, you are right. But: "what's in a name?".

> 
> (I'd also like to repeat that MANET routing protocols will 
> work quite happily over other link types as well.)

IMHO, that point has been made ad nauseam in previous Autoconf sessions.
(In Philadelphia, in particular). It is true of course, but what does it
prove? We already had those other link types covered; they are not what
MANET protocols were designed for. MANET protocols come into their own
when used over these special <new name> links.
 
> 
> I would rather describe these links as "non-reflexive and 
> non- transitive (wireless) links". I'd also be happy with a 
> nice acronym, like NBMA or UDLR.
> 
> I'm interested in your thoughts. How do you think we should 
> refer to this linktype?

Sorry, can't think of a cute acronym right now...

Ronald
> > Feedback is, obviously, welcome -- preferably on the list 
> such that we 
> > could be prepared spend time on this also in MN.
> >

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 18 Nov 2008 22:00:02 +0100

>> characteristics and constraints of a linktype are not MANET specific.

I agree too. Here's one way to see things:

what is special about these links, is that their properties vary more
than usual:
(i) over time, and
(ii) between different instances of links of the type.

So all the protocols running above these links must be more
"opportunistic" than usual. Which basically means: within a short window
of opportunity, detect and take advantage (as much as possible)  of the
properties of such a link.

So maybe we could simply call this category of link "opportunistic
links"? What do you guys think?

Emmanuel

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 19 Nov 2008 09:42:21 -0000

> (ii) between different instances of links of the type.

I think those are of secondary importance. It's the (possible)
non-symmetry, non-transitivity that's of primary importance.

---

From: mase <[email-masked]>
Date: Wed, 19 Nov 2008 21:11:25 +0900

>non-symmetry, non-transitivity that's of primary importance.

The real problem (or confusion), I think, is that when you say 
non-transitivity, you assume that all three nodes are on the same 
link. However, there are others who don't think that they are.

Kenichi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 19 Nov 2008 12:23:49 -0000

> link. However, there are others who don't think that they are.

I don't think that's my assumption.

It's more fundamental than what you call a link. It's that if
A's transmissions can reach B, and B's transmissions can reach C,
but A's transmissions can't reach C, then we have non-transitivity.
That's the usual case with wireless transmissions (to be precise,
it's the usual case that A's transmissions may or may not reach C).

Thus either A, B and C can't be on one link (if your model of a
link is as Ethernet) or you need a different model of what a link
is, and can consider A and B to have a link, and B and C to have
a link (but not A and C). For MANETs the latter may be more useful.
But the non-transitivity is there, whatever definitions you choose.

---

From: mase <[email-masked]>
Date: Wed, 19 Nov 2008 22:35:45 +0900

>But the non-transitivity is there, whatever definitions you choose.

If there is the non-transitivity regardless of the link model or 
assumption, how does it help to discuss or define any link model for MANETs?

Kenichi

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 19 Nov 2008 14:41:42 +0100

> But the non-transitivity is there, whatever definitions you choose.

Agreed this a definition issue.
In the Autoconf meeting, there was consensus on defining a xxx link type
(name tbd), where different links are on the same interface. I think we can
assume that the medium is shared (we are on the same electro-magnetic
spectrum), but the degree of interference is not known on forehand (e.g.
TDMA vs. CSMA/CA).

The 802 series of standards could be helpful as a reference. The STDs refer
to RFCs, why do we have some asymmetry here?

Useful ones:

IEEE802.1-2001 (section 6.3.3.describes usage of routers and the IP
protocol)

IEEE802.11-2007 (too many sections to list here)

This is an interesting one:
>>> 3.16 basic service set (BSS):
<skip>   Membership in a BSS does not imply
that wireless communication with all other members of the BSS is possible.
<<<

And this one:
>>> 3.76 link:
In the context of an IEEE 802.11 medium access control (MAC) entity, a
physical path consisting
of exactly one traversal of the wireless medium (WM) that is used to
transfer an MAC service data unit
(MSDU) between two stations (STAs).
<<<
(this would exclude broadcast MSDU, which is not the case)

Another comment on naming:
I think we have two task. One of them is describing this "ad hoc wireless
link". 802.11 definitions could be used, maybe some can come up with other
refs. But in a MANET, multiple link types can be used. Think of an Ethernet
cable connecting two radios "back-to-back" or using alternative radios with
lower frequency / lower bandwidth / more Tx power / increased range. I think
it helps to write down something on "MANET topologies".

Just repeating myself:
Lets postpone IP addressing and ND issues until we are familiar with MANETs
that are out there.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 19 Nov 2008 13:45:10 -0000

> assumption, how does it help to discuss or define any link model

First you recognise that you have non-transitivity.
Then you decide what your link model should be that handles that.

This is as opposed to when you have transitivity (and symmetry).
Then you have a wider range of possible link models.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Nov 2008 15:23:47 +0100

Dearlove, Christopher (UK) wrote:
> It's more fundamental than what you call a link. It's that if A's
> transmissions can reach B, and B's transmissions can reach C, but A's
> transmissions can't reach C, then we have non-transitivity.

In that sense, and from ND perspective, Internet is non-transitive:
one's laptop reaches one's router, router reaches its next-hop router,
but one's latop doesn't reach that latter router.

I think it largely depends on where from we look at problems, from phy
layer, from mac layer, from network layer, etc.  One could find problems
if crossing layers, and cross-layer solutions, it's very sensitive.

Alex

> Thus either A, B and C can't be on one link (if your model of a link
> is as Ethernet) or you need a different model of what a link is, and
> can consider A and B to have a link, and B and C to have a link (but
> not A and C). For MANETs the latter may be more useful. But the
> non-transitivity is there, whatever definitions you choose.
> 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 19 Nov 2008 14:27:59 -0000

> but one's latop doesn't reach that latter router.

True, but there are small pieces of it that are transitive (and
other good things). And those are the small pieces (e.g. one
Ethernet) that are considered links, set up as subnets, run ND,
and all those things.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Nov 2008 15:41:25 +0100

Dearlove, Christopher (UK) wrote:
>>  one's laptop reaches one's router, router reaches its next-hop 
>> router, but one's latop doesn't reach that latter router.
> 
> True, but there are small pieces of it that are transitive (and other
>  good things). And those are the small pieces (e.g. one Ethernet)
> that are considered links, set up as subnets, run ND, and all those 
> things.

I don't think we can consider an Ethernet cable to be transitive.

We can question the transitivity of two Ethernet cables: if they're
connected by a hub (mac repeater) then Ethernet is transitive.  If
they're connected by a PC not running forwarding nor bridging then the
two Ethernet cables are non-transitive.

It depends how they're connected.  For every wired and wireless
technology there are connectors solving the non-transitivity problems at
their particular layer.  YOu said previously  that in some instances
such connectors are not available.  Maybe we can insist describing these 
cases, thus motivating the need.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 19 Nov 2008 15:57:15 +0100

> cases, thus motivating the need.

Work is already been done in IEEE.
Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 19 Nov 2008 15:00:44 -0000

Alexander OPetrescu wrote:
>> And those are the small pieces (e.g. one Ethernet)

> We can question the transitivity of two Ethernet cables:

I didn't say two, I said one. (OK, I didn't qualify by cable. Put it
in if you want it. And yes, of course one fails if too long, or badly
configured, but that's not the case I'm referring to either.)

> For every wired and wireless technology there are connectors solving
> the non-transitivity problems at their particular layer.

There may be connectors that may be available. They may not be.

> YOu said previously  that in some instances
> such connectors are not available.

I did, and I do. For any radio system with a range X (yes, I know
things aren't usually that simple) if we deploy A, B, C in a line
at a spacing of 3X/4, A and C can't communicate directly. And there
are many cases where that's the problem, you can't add anything else.
But A and C need to communicate. Fine, that's what the whole MANET
concept is about. But if we are going to do it using IP, we need,
if we are going to do it in an IETF-specified way, to go down the
route we're on to define interfaces and link types and all those
things. But whatever we do, there's one thing we are stuck with,
and that is that A and C can't communicate directly. At the physical
layer, up to whatever layer we implement the MANET at, there will
be two transmissions to get information from A to C. If the MANET
is at L2, most of the L3 problems are solved (but they are still
someone's problem). But the MANET WG, and by extension the Autoconf
WG, is about doing the MANET at L3, and hence we have the problem.

I think this branch has become a blind alley, and I'll leave it
here.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Nov 2008 16:21:05 +0100

Dearlove, Christopher (UK) wrote:
>>> And those are the small pieces (e.g. one Ethernet) that are 
>>> considered links, set up as subnets, run ND, and all those 
>>> things.
>  in if you want it. And yes, of course one fails if too long, or
> badly configured, but that's not the case I'm referring to either.)
> 
>> For every wired and wireless technology there are connectors 
>> solving the non-transitivity problems at their particular layer.
> 
>> YOu said previously  that in some instances such connectors are not
>>  available.
> 
> things aren't usually that simple) if we deploy A, B, C in a line at 
> a spacing of 3X/4, A and C can't communicate directly.

I agree.  And for any digital wired system they have max lenghts of
transmission; eg Ethernet maximum is 150m IIRC - if we deploy a cable
longer than 150m with a host in the middle there's non-transitivity issue.

Fiber has similar limitations in cable length above which one needs
repeater.  USB and FireWire too.

If when we say 'radio' we think signals travel through copper as radio
waves, because they are waves with frequencies, then we equate the
non-transitivity issue to cables too - which is a paradox: cables are
non-transitive radio systems?  This is where I believe it's biting its 
queue, because a too strong belief in that radio is something different 
may lead to paradoxes.

For clarification: I believe despite its mentioning in
authoritative books, the non-transitivity aspects are irrelevant to WiFi 
and IP.

> And there are many cases where that's the problem, you can't add 
> anything else. But A and C need to communicate. Fine, that's what the
>  whole MANET concept is about. But if we are going to do it using IP,
>  we need, if we are going to do it in an IETF-specified way, to go 
> down the route we're on to define interfaces and link types and all 
> those things. But whatever we do, there's one thing we are stuck 
> with, and that is that A and C can't communicate directly. At the 
> physical layer, up to whatever layer we implement the MANET at, there
>  will be two transmissions to get information from A to C. If the 
> MANET is at L2, most of the L3 problems are solved (but they are 
> still someone's problem).
>
> But the MANET WG, and by extension the Autoconf WG, is about doing
> the MANET at L3, and hence we have the problem.

This is where we may may have another big misunderstanding.  If AUTOCONF 
is all about MANET WG then I think I should stop posting here.

> I think this branch has become a blind alley, and I'll leave it here.

Well, I believe too, thanks for the mail.  I think I'm not in 
disagreement with you to say that we completely disagree on the 
non-transitivity being or not being an issue.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 19 Nov 2008 16:01:57 -0000

> is all about MANET WG then I think I should stop posting here.

Again, you misinterpret what I said. I said Autoconf is about
MANETs at L3, not about MANET WG. Though right now the Autoconf
task is a MANET architecture, and that must be consistent with
the MANET WG (or if you prefer, the MANET WG should be consistent
with it). Obviously Autoconf will do different work to the MANET WG.

---

From: Paul Lambert <[email-masked]>
Date: Wed, 19 Nov 2008 13:50:26 -0800

> non-symmetry, non-transitivity that's of primary importance.

I find this issue and the document in discussion to be quite confusing.  I see no reason to define such special links.  A link never has any guarantee of 'transitivity'.  It appears that the mental model being used is biased to experiences with LANs where the 'links' provide a fully connected graph of connectivity.  In general this is the special case. Transitivity is an unnecessary concept - it is however the type of connectivity that is the interesting edge condition for MANETs

Regards,

Paul

PS - only recently lurking so please excuse me if my confusion is due to lack of full context.