Le 16/04/2019 à 12:06, Pascal Thubert (pthubert) a écrit :
Hello Sri
If the document was clearly scoped to P2P link local communication it
would need correcting, like stop paraphrasing IEEE but it would
eventually pass.
I do not know what do you mean by P2P.
In my experiments we also used three cars with IP on a single subnet OCB.
The term I may be using is something like
P
P2P
if such a multidimensional term can exist.
Beyond that scope it is a matter of use cases and solutions. I do not
know what the WG decided for the former. The latter starts with
applicability of existing work, in particular WiND.
If the group needs such functions I claim that we can already do hub
and spoke subnets with either a single node as hub (a BSS at L3) or
several nodes (that would be RSUs) connected by a high speed transit
link. This can be done using Wireless ND and can be described in a
few pages.
I claim we can already do mesh in relatively stable situations, e.g.,
relaying over cars in a parking lot to the RSU that provides
Internet.
It's great to know.
Did it use OCB?
(we define IP-RSU to be an RSU that does OCB.)
Alex
I claim we can couple that with NEMO in the car and maintain global
reachability while on the road.
What’s harder is to figure what’s reachable at which time. DNA and
when to form new addresses. Discover services. How to use the fixed
infrastructure to relay between cars while driving. These are some of
the real and interesting problems left to be solved by the WG whereas
reinventing the wheels could be a waste of time.
All the best,
Pascal
Le 16 avr. 2019 à 05:11, Sri Gundavelli (sgundave)
<sgundave@xxxxxxxxx> a écrit :
I am no expert, but I do know some physics, and it seems pretty
clear to me that if there are multiple lanes of traffic, a large
truck can easily shield signals between two cars and the
shielding will be intermittent, regardless of how much wireless
power is allowed, depending on traffic movement. So it's a highly
dynamic mesh network.
Part of the problem is that we have not clearly put some limits on
the use-cases. These unbounded limits is opening up these
discussions on ad-hoc full mesh network formations and the
resulting challenging ND scenarios. But, again I always assumed
this discussion is for the ND document and there should be no
bearing on this document.
V2X communications involves V2V, V2I and V2P communication modes.
From the point of view of vehicular safety, its about exchange of
BSM (Basic Safety Messages) between vehicles as per SAEJ735
standard. These safety communications is always one-hop
communication and for very good reason IEEE WAVE standards did not
bother to require IPv6 transport for carrying these messages. The
WSMP message which carries these safety elements are defined to be
carried over layer-2 payloads. Personally, I never thought we will
replace this L2 safety communication mode with layer-3 mode
(IPv6-over-80211-OCB). But the use of IPv6 is more for allowing
applications in the vehicle to communicate with the infrastructure.
For example, a vehicle using DSRC radio to access some traffic
application in the cloud.
In one sense, this is like a mobile node using 802.11-OCB like any
other radio technology (CDMA, LTE, Wi-Fi), and use IPv6 for its
communications. In this context, its always about vehicle to
infrastructure communications. Now, there are other interesting
peer to peer use-cases, where one vehicle is streaming some video
to another vehicle without using any infrastructure. While these
later examples are very cool, personally, I did not expect this WG
to solve those use-cases day-1. For us to support those use-cases,
we need to figure out many more things including approaches for
exchanges prefixes between two vehicles that come in proximity. In
my mind, these are very forward looking and the only relevant
application is platooning. I am not interested in solving this V2V
problem, but was more interested to enable V2I communications,
where the focus is about link model, prefix hosting approaches,
mobility support (building a large L2 domain over RSU’s, or routed
approaches with mobile IP type protocols) ..etc. In one
realization, there may be a P2P link assumption between the vehicle
and the RSU, eliminating most of these ND issues. But, those
discussions are for the other document and that clearly should
remove these ND concerns from this document.
Sri
On 4/15/19, 2:04 PM, "Brian E Carpenter"
<brian.e.carpenter@xxxxxxxxx> wrote:
Excuse top posting.
As I've said, I am no expert, but I do know some physics, and it
seems pretty clear to me that if there are multiple lanes of
traffic, a large truck can easily shield signals between two cars
and the shielding will be intermittent, regardless of how much
wireless power is allowed, depending on traffic movement. So it's
a highly dynamic mesh network. That's a very interesting problem
that has been much studied, and it's fundamentally different from
the ND design scenario.
So I find it hard to believe that nobody can write the TBD text.
Regards Brian
On 15-Apr-19 23:26, Alexandre Petrescu wrote: Hi Brian,
Le 14/04/2019 à 22:49, Brian E Carpenter a écrit : Hi
Alexandre,
On 15-Apr-19 04:38, Alexandre Petrescu wrote: Brian,
Le 14/04/2019 à 04:20, Brian E Carpenter a écrit :
All we need is a simple statement in the spec which
puts some scope limits, w.r.t the missing ND pieces
and issues.
Yes, that is clearly essential, as well as an associated
health warning that implementers must not rush ahead
because of the risk of non-interoperability.
There is already paragraph, and an Appendix, about
potential ND issues. I think that text qualifies as an
associated health warning.
I do not know what do you mean about the risk of
interoperability. This ND that works is interoperable
between several OCB cards, IP Road Side Units, and linuces.
(I can cite brands that I al familiar with and that
interoperate.
This is the current paragraph and Appendix that qualify as
a warning that you suggest:
The baseline Neighbor Discovery protocol (ND) [RFC4861]
MUST be used over 802.11-OCB links. Transmitting ND
packets may prove to have some performance issues. These
issues may be exacerbated in OCB mode. Solutions for
these problems SHOULD consider the OCB mode of operation.
The best of current knowledge indicates the kinds of
issues that may arise with ND in OCB mode; they are
described in Appendix J.
That's exactly the text that I find problematic. I can't
write a new version because I lack your expert knowledge, but
IMHO it should be more specific:
The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST
be used over 802.11-OCB links. However, as on any wireless
link, transmission of multicast ND packets may fail in OCB.
In particular, scenarios where TBD TBD TBD are likely to be
unreliable and SHOULD NOT be deployed until an alternative
standardised solution is available. The best of current
knowledge indicates the kinds of issues that may arise with
ND in OCB mode; they are described in Appendix J.
I can agree with that formulation and put it in the text.
But I need an indicat that TBD is defined soon. The time
commitments of Pascal seem to be saying he is no longer
interested in writing that TBD.
I wait a little for this to clarify.
Also I don't like this phrasing in Appendix J:
Early experiences indicate that it should be possible to
exchange IPv6 packets over OCB while relying on IPv6 ND alone
for DAD and AR (Address Resolution).
Could you rather say the opposite:
Early experience indicates that it is possible to exchange
IPv6 packets over OCB while relying on IPv6 ND alone for DAD
and AR (Address Resolution) in good conditions. However, this
does not apply if TBD TBD TBD...
This is an appendix. I could put TBD there now.
Alex
Regards Brian
Alex
Regards Brian
On 14-Apr-19 13:58, NABIL BENAMAR wrote: +1 Sri
On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave)
<sgundave@xxxxxxxxx <mailto:sgundave@xxxxxxxxx>>
wrote:
I understand your point Brian, but IMO there are
enough reasons not to delay this work.
There are many use-cases/applications where there is a
stable topology of RSU¹s and OBU¹s. The regulations
around 5.9 Ghz (DSRC) band allows the channel use for
non-priority/non-traffic safety related applications.
For example, a vehicle in a gas station can receive a
coupon from the 802.11-OCB radio (AP/RSU) in the gas
station. There, its a stable topology that classic ND
is designed for. In this operating mode, its perfectly
reasonable to use classic ND and it works. The authors
have shown enough lab data on the same.
Ideally, I agree with you that it makes lot more sense
to publish both the specs at the same time. But, for
what ever reasons the WG went on this path. Authors
have spent incredible amount of efforts in getting the
draft this far and we cannot ignore that. You can see
the efforts from the version number; when did we last
see a draft version -037?
We also need to distill the recent ND discussions and
filter out the threads that are clearly motivated to
insert a ND protocol that is designed for a totally
different operating environment. An argument that a
protocol designed for low-power environments is the
solution for vehicular environments requires some
serious vetting. Looking at the characteristics,
always-sleeping, occasional internet connectivity,
low-power, no memory, no processing power, no mobility
..etc, meeting vehicular requirements is some thing
most people in the WG do not get it.
Bottom line, IMO, we should move this forward and
publish the document. All we need is a simple statement
in the spec which puts some scope limits, w.r.t the
missing ND pieces and issues. There are other
proposals in the WG that will address the gaps and
bring closure to the work.
Sri
On 4/12/19, 1:28 PM, "Brian E Carpenter"
<brian.e.carpenter@xxxxxxxxx
<mailto:brian.e.carpenter@xxxxxxxxx>> wrote:
On 13-Apr-19 02:59, Sri Gundavelli (sgundave)
wrote: If you go back and check 2017 archives, I
did raise many of
these
issues. But, we clearly decided to limit the
scope
excluding address
configuration, DAD, ND aspect, link models. When
there is
such a scope
statement, it should clearly move these comments to
the
draft that
defines how ND works for 802.11-OCB links.
This is of course possible. In general the IETF
hasn't done
that, but has
followed the lead set by RFC 2464 with the complete
specification of
IPv6-over-foo in one document.
However, I don't believe that publishing an RFC about
the
frame format
without *simultaneously* publishing an RFC about ND
etc
would be a good
idea. That would leave developers absolutely unable
to write
useful
code, and might easily lead to incompatible
implementations.
Since
we'd presumably like Fords to be able to communicate
with
Peugeots,
that seems like a bad idea.
Regards Brian
.
