Pascal,
Please allow me to change the subject of this, to reflect the
content. It helps tracking the discussion.
Le 11/04/2019 à 04:36, Pascal Thubert (pthubert) a écrit :
Hello Brian
I meant broadcast at layer 2 not layer 3. L3 uses multicast but
it requires a service at the lower layer to implement it. This
is rarely if ever a real L2 multicast service.
I can agree.
IOW the IETF has thrown the problem over the fence to the IEEE
but it is not really solved to this day.
I think indeed there is redirection of responsability to IEEE.
Maybe IEEE does not like to do it, because of some reasons.
With respect to link-layer multicast: there is indeed no IEEE
messaging for creation or removal of link-layer multicast groups
(like in IP there is MLDv2). But there is concept of link-layer
multicast groups at IEEE. This is used extensively by mapping IP
groups into link-layer groups, and it helps IP.
Should IEEE develop a mechanism using messages (not just local
filters) for creating these link-layer groups?
In practice, the service that is performed on IEEE std 802.3 is
a broadcast over a broadcast domain, and the subnet has to be
contained within that domain.
Well yes and no.
Yes it is a broadcast on 802.3 if we talk IPv4, but it is still
link-layer multicast on 802.3 if we talk IPv6: the link-layer
addresses ofIPv6 on Ethernet are link-layer multicast addresses.
The broadcast operation is emulated on IEEE std 802.11 by the
BSS operation whereby the AP reflects the message to be
broadcasted, so the broadcast domain is that of the AP as opposed
to that of the source STA.
I agree.
By the proposed definition, if car A sees car B they are in the
same subnet. If car B sees car C they are in the same subnet.
Transitively Car A is in the same subnet as car C.
PAscal, again, this depends on how you set up the OCB interfaces on
cars A, B and C.
There are two options: - use a single OCB interface with antenna
sitting on top of each automobile. Make them all in the same
channel frequency (e.g. CCH - Control Channel). That indeed has
that A-B-C transitivity aspect. Worse, it has scalability issues:
one cant grow a convoy beyond a few tens of meters and be sure the
frontmost talks directly to the rearmost. One never knows whether
somebody in the middle repeats, or not. Or one needs to rely on
MANET protocols that may forward on a single interface. It has
some PHY issues as well, that I can describe. The powerpoint is
readily filled with my last PHY experiments of propagation. - use
multiple OCB antennas situated at some strategic places in a car.
This is in the same way as when placing the other ultra sound,
radar and lidar sensors in the automobile.
An OCB interface in the front bumper of one car forms a subnet
with another OCB interface in the rear bumper of another car, on a
particular channel (SCHx - service channel number x). The front
and rear subnets of a car are in distinct channels. There is no
A-B-C transitivity. There is IP forwarding between front and rear
interfaces of a car.
This can be described. But I dont think it should be described in
the IP-over-OCB document. It is a PHY MAC setting for OCB.
But car C may not be in the radio broadcast domain of car A, and
there is no BSS by definition of OCB to emulate a broadcast
domain between them via an AP. End result is that a DAD or a
lookup by car A will not reach car C.
That may be true, but it is true mostly in a setting where each car
uses a single OCB interface whose antenna is placed on the roof of
the car (placed at same place as the the GPS, LTE, FM or DVB-T
antennas are placed).
In settings where each car has multiple OCB interfaces and
multiple antennas placed at strategic places (strategic: places
that are relevant to PHY propagation conditions), rather than
simply on the roof, the issue you describe in the above paragraph.
Now, if you read up to here, I would like to ask you (without
claiming to be all-knowing), whether you think a car could have
several OCB interfaces?
By traditional MANET and 6lo definition, the radio broadcast
domain of a node is his link.
It is good, and I agree with it.
For my part, I do not use the traditional MANET and 6lo
definitions because I believe they are not sufficient for vehicular
environments.
In you lab you can arrange that the broadcast domains of 3 cars
fully overlap.
I agree, people do that. It is in small lab, with size in the
range of a few meters; there is much reflexion from the walls. It
is not outdoors.
In that case, the link appears to match the common sense of a
link in wires and the classical IPv6 operations will work pretty
much the same as in a BSS over that Link. It is for example easy
to place a subnet that matches that Link. It is also easy to
confuse a Link with a Subnet, which is what the definition does.
As soon as the broadcast domains start diverging, things get
hairy, see all the work by Erik about split subnet etc...
I fully agree with this paragraph.
I think if one puts several interfaces and antennas in a car, and
carefully design the use of the propagation models (e.g. avoid
'omni', consider 'directional', etc) then one can avoid many
problems forbidding IP from running on wireless.
The IETF has studied this situations for 10+ years at MANET,
6TiSCH and 6lo. We have an architecture that cover single link
and multilink subnets.
Yes, there is.
In the former case, the link is defined by one node that owns
the prefix. In the latter case, routing is required inside the
subnet and we created RPL to cover the situation.
YEs, but these are departures from what might be called traditional
IP forwarding. That forwarding happens between two distinct
interfaces.
In practice it means little software for MANET-6lo-multilink is
publicly available, and the engineer skill about them is hard to
find. This translates to equipment being very expensive.
I want to tell you that communication equipment for cars is already
very high compared to an off-the-shelf WiFi router. That high
price tag is due also to specification of things that are too
intelligent and that require high skills from few people. This is
the case of V2X stacks doing ETSI CAM with GeoNetworking and
similar. You end up with a 3000Eur IP-OBU when its underlying
hardware with linux and traditional IP forwarding costs around
700Eur.
To that 3000Eur one may need to add costs of complexity of MANET
protocols and 6lo multilink subnet moels you arrive at a cost per
communication box that is the equivalent of a small car.
This high cost is less and less acceptable.
Compare that to the 1Eur LTE-WiFi dongle retrofitted recently in
some cars.
We created RFC 8505 for an host to connect to the network in
either situation, without the requirement that the L2 broadcast
domain of the host (its Link) overlaps with that of other nodes
in the subnet (because they don't). We have made RFC 8505
abstract to the routing protocol if any, IOW without the
requirement that the host knows there is a MLSN, understands RPL
or whatever other routing is used
MLSN?
to put together the MLSN. To get there we had to abandon the
dependency that a L2 broadcast from the host reaches all nodes
in the subnet, IOW that the subnet is contained within the Link
of all of
IOW?
its members, IOW that the Links of all the nodes in the subnet
fully overlap. This meant we had to abandon the idea of using
multicast in ND for DAD and AR.
Maybe someone can explain that better than I did. I so please be
my guest. I really tried but I'm not convinced I did not waste
my time with the authors of the draft.
You did not waste your time, no more than I did.
Alex
All the best,
Pascal
-----Original Message----- From: Int-dir
<int-dir-bounces@xxxxxxxx> <mailto:int-dir-bounces@xxxxxxxx> On
Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019 09:54
To: NABIL BENAMAR <n.benamar@xxxxxxxxxxxxx>
<mailto:n.benamar@xxxxxxxxxxxxx>; Pascal Thubert (pthubert)
<pthubert@xxxxxxxxx> <mailto:pthubert@xxxxxxxxx> Cc:
ietf@xxxxxxxx <mailto:ietf@xxxxxxxx>; its@xxxxxxxx
<mailto:its@xxxxxxxx>; int-dir@xxxxxxxx
<mailto:int-dir@xxxxxxxx>; draft-ietf-ipwave-ipv6-over-
80211ocb.all@xxxxxxxx <mailto:80211ocb.all@xxxxxxxx>;
Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx>
<mailto:alexandre.petrescu@xxxxxxxxx>; Ole Troan
<otroan@xxxxxxxxxxxxx> <mailto:otroan@xxxxxxxxxxxxx> Subject:
Re: [Int-dir] Intdir early review of
draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6' -
fe80::/10 vs fe80::/64
Hi Nabil,
On 11-Apr-19 03:40, NABIL BENAMAR wrote:
Do we still talk about broadcast in IPv6 ?
No, we talk about multicast. Pascal was using shorthand. But
if multicast fails with high probability, several aspects of
IPv6 will fail too, unless the LAN provides an NBMA
(non-broadcast multiple access) emulation of multicast, or
suitable alternatives to SLAAC, ND, NUD, and RA.
An earlier draft of this spec mentioned this problem:
The operation of the Neighbor Discovery protocol (ND)
over 802.11-OCB links is different than over 802.11
links. In OCB, the link layer does not ensure that all
associated members receive all messages, because there is
no association operation. Neighbor Discovery (ND) is
used over 802.11-OCB.
but it was inconsistent and was removed. If Ole is correct
below about real-life conditions, the *problem* was not removed
and the draft is not going to work in the real world.
Brian
On Wed, Apr 10, 2019, 14:45 Pascal Thubert (pthubert)
<pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>
<mailto:pthubert@xxxxxxxxx> <mailto:pthubert@xxxxxxxxx>>
wrote:
Hello Ole:
Better remove, it is wrong anyway.
Because it is transitive, the description extends the
so-called subnet step
by step to a potentially large number of cars such that there
is no broadcast domain that covers them all. If there is no
broadcast domain and no multicast emulation like a BSS does,
how can we run ND? Yes, it works with 3 cars in a lab.
The description looks like it is confused with the MANET /
6LoWPAN
concept of link, whereby my link joins the collection of nodes
that my radio can reach.
All the best,
Pascal
-----Original Message----- From: Ole Troan
<otroan@xxxxxxxxxxxxx <mailto:otroan@xxxxxxxxxxxxx>
<mailto:otroan@xxxxxxxxxxxxx> <mailto:otroan@xxxxxxxxxxxxx>>
Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx
<mailto:alexandre.petrescu@xxxxxxxxx>
<mailto:alexandre.petrescu@xxxxxxxxx>
<mailto:alexandre.petrescu@xxxxxxxxx>>
Cc: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx
<mailto:pthubert@xxxxxxxxx>
<mailto:pthubert@xxxxxxxxx> <mailto:pthubert@xxxxxxxxx>>;
ietf@xxxxxxxx <mailto:ietf@xxxxxxxx> <mailto:ietf@xxxxxxxx>
<mailto:ietf@xxxxxxxx>;
its@xxxxxxxx <mailto:its@xxxxxxxx> <mailto:its@xxxxxxxx>
<mailto:its@xxxxxxxx>; int-dir@xxxxxxxx
<mailto:int-dir@xxxxxxxx> <mailto:int-
dir@xxxxxxxx <mailto:dir@xxxxxxxx>>;
draft-ietf-ipwave-ipv6-over-
80211ocb.all@xxxxxxxx <mailto:80211ocb.all@xxxxxxxx>
<mailto:80211ocb.all@xxxxxxxx>
<mailto:80211ocb.all@xxxxxxxx>; Brian E
Carpenter <brian.e.carpenter@xxxxxxxxx
<mailto:brian.e.carpenter@xxxxxxxxx>
<mailto:brian.e.carpenter@xxxxxxxxx>
<mailto:brian.e.carpenter@xxxxxxxxx>>
Subject: Re: [Int-dir] Intdir early review of
draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming
IPv6' - fe80::/10 vs fe80::/64
You said: if OCB is still 48bit, and if there is
bridging OCB-Ethernet, then
no
reason to be different than rfc2464.
I said: OCB is still 48bit, but there is no bridging
OCB-Ethernet.
The conclusion is: there is reason to be different from
RFC 2464.
Why?
Now, you give a different conclusion.
Excuse me, I would like to clarify this please?
Clarify what? That a link-layer that looks an awfully lot
like Ethernet should not follow
the
64-bit boundary and the definition of the link-local
address mapping of rfc2464? Section 4.5.1 is already clear
on that.
I think the only thing we are asking you is to change the
following
paragraph:
OLD: A subnet is formed by the external 802.11-OCB
interfaces of vehicles that are in close range (not by
their in-vehicle interfaces). This subnet MUST use at
least the link-local prefix fe80::/10 and the interfaces
MUST be assigned IPv6 addresses of type link-local.
NEW: A subnet is formed by the external 802.11-OCB
interfaces of vehicles that are in close range (not by
their in-vehicle interfaces). A node MUST form a link-local
address on this link.
Not quite sure what value that paragraph adds in the first
place. You
could
probable remove it.
Cheers, Ole
Alex
Le 10/04/2019 à 12:28, Ole Troan a écrit :
Alexandre, Right, so it doesn’t sound like you have
any reason to be different
from
RFC2464.
Just reference or copy that text (section 5, rfc2464).
Ole
On 10 Apr 2019, at 11:22, Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx
<mailto:alexandre.petrescu@xxxxxxxxx>
<mailto:alexandre.petrescu@xxxxxxxxx>
<mailto:alexandre.petrescu@xxxxxxxxx>> wrote:
Le 10/04/2019 à 11:04, Ole Troan a écrit :
"At least" does not mean "the value should
be at least 10" in
that
phrase.
Do you think we should say otherwise?
To me there is nothing in the actual text to
tell me that "at
least"
qualifies the "/10". I think you could
rephrase as "This subnet's prefix MUST lie
within the link-local prefix fe80::/10 ..."
However, see Jinmei's messages about
conformance with RFC
4291.
I think there might be unexpected side
effects from using an address like fe80:1::1.
What if some code uses matching with
fe80::/64 to test if an address is
link-local? I agree that would be faulty
code, but you would be the first to discover
it.
Indeed. If you absoultely must cut and paste
text from 2464:
YEs, that is how we started. We cut and paste
from 2464.
5. Link-Local Addresses The IPv6 link-local
address [AARCH] for an Ethernet interface is
formed by appending the Interface Identifier,
as defined above,
to
the prefix FE80::/64. 10 bits 54
bits 64 bits
+----------+-----------------------+----------------------------+
