|
Pascal,
Do you agree there can
be multiple IP OCB interfaces in one car?
Alex
Le 11/04/2019 à 11:23, Alexandre
Petrescu a écrit :
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>
On Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019 09:54
To:
NABIL BENAMAR <n.benamar@xxxxxxxxxxxxx>; Pascal Thubert
(pthubert)
<pthubert@xxxxxxxxx> Cc: ietf@xxxxxxxx; its@xxxxxxxx;
int-dir@xxxxxxxx; draft-ietf-ipwave-ipv6-over-
80211ocb.all@xxxxxxxx; Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx>; Ole Troan
<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>>
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>>
Sent: mercredi 10 avril 2019 20:41
To: Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx
<mailto:alexandre.petrescu@xxxxxxxxx>>
Cc: Pascal Thubert (pthubert)
<pthubert@xxxxxxxxx
<mailto:pthubert@xxxxxxxxx>>; 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>; Brian E
Carpenter <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>> 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
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface
Identifier |
+----------+-----------------------+----------------------------+
I presume there is
support for bridging 802.11p and
other 802.3
links?
In the IP-OBUs that I know there is IP forwarding
between
802.11-
OCB
(earlier 802.11p) and 802.3, not
bridging.
In some IP-OBU (Internet Protocol On-Board Unit)
some non-OCB
interfaces are indeed bridged. E.g. the Ethernet
interface is
bridged to
the
WiFi interface; that helps with
DHCP, tcpdump and others to see
one a
single -
bridged - interface.
Bridging may be, but it is not a MUST. There is no
necessarily any
bridging
between the 802.11-OCB interface and
other interface, neither bridging between the multiple
802.11-OCB interfaces that might
be present in
the
same computer.
Do you assume bridging of 802.11-OCB interface to
Ethernet
interface is
always there?
Note: I also heard many comments suggesting that EAL
is akin to
'bridging'. I do not know whether you refer to that
perspective. If yes,
we can
discuss it separately.
Alex
[...]
And that the MAC address
length of this link type is also 48 bits?
YEs, the length of MAC address on 802.11 mode
OCB is
also 48.
If the two assumptions
above hold, then I see zero
justification
for
pushing the 64 bit boundary in this
draft.
Let me try to understand the first assumption.
Ole
_______________________________________________
Int-dir mailing list Int-dir@xxxxxxxx
<mailto:Int-dir@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/int-dir
_______________________________________________ Int-dir
mailing list Int-dir@xxxxxxxx
<mailto:Int-dir@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/int-dir
_______________________________________________ Int-dir
mailing list Int-dir@xxxxxxxx
https://www.ietf.org/mailman/listinfo/int-dir
|
