Subject: Re: [ipwave] Rechartering

From: Nabil Benamar <[email-masked]>
Date: Mon, 29 Jan 2018 10:45:08 +0000

Hi Alex, Jerome

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Mon, Jan 29, 2018 at 8:20 AM, Alexandre Petrescu <
[email-masked]> wrote:

>
>
> Le 25/01/2018 à 19:02, Jerome Haerri a écrit :
>
>> Hi Alex, All,
>>
>> from the various e-mails, there is indeed issues or challenges to
>> use IPv6 and underlying protocol for distributed, large scale and
>> dynamic vehicular neyworks.
>>
>> However, I also see, again from e-mails, that there seem to always
>> be a solution for each issue, weather it solves it optimaly or not.
>> And most of the time, it seems to require strategies from different
>> IETF WG.
>>
>> So, as IPWAVE might be seen as an entry point for IPv6 issues in
>> vehicular environments, it could be interesting and helpful for the
>> community to have a  best practice document summarizing the issues,
>> introducing  a potential solution and linking to the right IETF workgroup.
>>
>> Of course, we can also propose enhancement, but it could be good to have
>> such best practice document, no?
>>
>
> Hi Jérôme,
>
> I would need to better understand what do you mean by a 'best practice'
> document.  I think you did not mean BCP like some RFCs are, but just
> best practice.
>
> In that sense, I could think of needs of IP in OCB networks for
> vehicular communications.  Most people dont agree precisely how to make
> an IP topology in vehicular networks.
>

​I agree. This critical point should be examined in a futur document.

>
> Whereas an RSU - to - OBU topology is often easily agreed (a Router to a
> Host), other cases like vehicle - to - vehicle, or traffic light to
> pedestrian to vehicle are less clear (who is Router? what is the subnet?).
>

​Very interesting. Is there any IETF document that mention the involves
pedestrians is an ITS context?
In most cases, pedestrian is considered as an obstacle to avoid rather than
a road user!​

>
> The vehicular networks are still dominated by topologies little known in
> IP networks: every car 'broadcasts' CAM every 500ms and every other car
> tries to understand it.  There is no IP network topology for it, but
> that's the predominating ways in which vehicular networks do.
>
> Things are changing with the arrival of IoT and C-V2X: a car sends a CAM
> to an IoT platform in the cloud, and the other cars look for it there,
> instead of direct 'broadcasts'.  That's with IP.
>

​Fog/Edge computing is also ​a raising star in this context!

>
> Along this line of thought, it could be possible to write something
> about 'best practices' of using IP in vehicular networks, including OCB.
> If _I_ were to write, but how about others?
>

​I can collaborate in the write up of such a document.​

>
> I am not sure whether this is the kind of idea you have about 'best
> practice'?
>
> Alex
>
>
>
>> Best Regards,
>>
>> Jérôme
>>
>> Envoyé de mon iPhone
>>
>> Le 25 janv. 2018 à 18:44, Alexandre Petrescu <
>>> [email-masked]> a écrit :
>>>
>>>
>>> On Wed, 2018-01-24 at 09:51 -0800, Tony Li wrote:
>>>>
>>>>> One particular aspect of ND on OCB links is how to make ND support
>>>>>> SLAAC and Mobile IP between a Road-Side Unit and an On-Board Unit.  On WiFi
>>>>>> links, a Host (role of OBU) receives an RA with a prefix and configures an
>>>>>> address, which becomes a Care-of Address and triggers a BU.  But on OCB
>>>>>> links, the Host may receive RA from distinct RSUs, without knowing
>>>>>> which is the 'right' RSU to connect to.  (on wifi the Host
>>>>>> knows which is the 'right' Access Point because the user sets
>>>>>> an ESSID to connect to; in OCB there is on ESSID, or,
>>>>>> otherwise put, there is a single ESSID for everybody, called
>>>>>> '*’).
>>>>>>
>>>>>
>>>>>
>>>>> This assumes that the Wi-Fi AP and the router are co-located, which is
>>>>> definitely not required.  You can easily have a Wi-FI topology with
>>>>> multiple routers sending RAs where the routers sit behind the AP or are
>>>>> clients themselves.
>>>>>
>>>>
>>> I agree, but whereas in WiFi the Access Points have an option to
>>> 'bridge', in 802.11 OCB trials the Road-Side Units are rarely bridges, and
>>> are often routers.  But I agree it is possible to
>>> make RSUs as Access Points, and the RA to come from single router.
>>>
>>>> I agree that there’s a problem of knowing the right OCB link
>>>>> to make, but that seems completely independent of ND.
>>>>>
>>>>
>>> Well, it depends how those (new?) 802.11 OCB unrouter Access
>>> Points are made.  If they are wrongly made to bridge an NA from the
>>> Router by substituting its the src MAC address for the Router's,
>>> _and_ not include a SLLA option (source link-layer address) of the
>>> ND protocol, then we have a problem.
>>>
>>> The solution would be to recommend to 80211 OCB AP bridge makers
>>> to MUST include SLLA if they substitute the src.
>>>
>>> I have seen this problem in the past with other bridges.
>>>
>>> And no, this would not indeed solve the problem of OBU deciding which is
>>> the right OCB to connect to.
>>>
>>> But I think that if there is something that could help the OBU to decide
>>> which OCB to connect to, then it must be in the ND, because that's the
>>> first protocol run.
>>>
>>> Another aspect of ND on OCB links relates to the use of OCB between two
>>>>>> vehicles (not between the vehicle and the RSU). On such an OCB link there
>>>>>> may be no RA dedicated to SLAAC, and the addresses used are link-local
>>>>>> addresses.  But there could be RA to exchange the prefixes that are
>>>>>> configured _inside_ the cars.  And, the use of MLDv2 is mandatory on these
>>>>>> OCB links between two cars.
>>>>>>
>>>>>
>>>>>
>>>>> One might also consider using a routing protocol, as exchanging
>>>>> prefix reachability is the purpose of routing protocols.  Even
>>>>> RIP would suffice for this application.
>>>>>
>>>>
>>> I agree.
>>>
>>> There a few Internet Drafts for ND for prefix exchanges between
>>> the cars.  But I lost my implementation(s), I forgot where they
>>> are.
>>>
>>> As such I asked a colleague to solve the problem of car to car
>>> communications without prefixes in ND and he came up with...
>>> Babel. It's open source, stored somewhere well known and apparently
>>> it works in practice, on a table.
>>>
>>> We may need to see whether it, Babel, scales well with a 10- or 100-car
>>> convoy of vehicles aligned, or whether it has too heavy in computing needs
>>> for small in-car platforms, or whether it can help to _form_ the convoy
>>> (cars joining each other, or car pulling
>>> other cars for fleet rebalancing).
>>>
>>> Alex
>>>
>>>
>>>>> Tony
>>>>>
>>>>> _______________________________________________ its mailing list
>>>>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>>>
>>>>
>>> _______________________________________________ its mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>
>>
>>
>>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Jan 2018 12:02:15 +0100

Le 29/01/2018 à 11:45, Nabil Benamar a écrit :
> Hi Alex, Jerome
> 
> 
> 
> Best regards
> Nabil Benamar
> -------------------
> نبيل بنعمرو
> 
> 
> 
> 
> 
> 
> On Mon, Jan 29, 2018 at 8:20 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>         vehicular environments, it could be interesting and helpful for
>         the community to have a  best practice document summarizing the
>         issues, introducing  a potential solution and linking to the
>         right IETF workgroup.
> 
>         Of course, we can also propose enhancement, but it could be good
>         to have such best practice document, no?
> 
> 
>     Hi Jérôme,
> 

I have not seen an IETF document in this context.

I meant the use-case of traffic lights webcam detecting the pedestrian 
and warning the approaching car.

There are many products that do this.  Last I saw was from Neavia.

> In most cases, pedestrian is considered as an obstacle to avoid rather 
> than a road user!​

YEs, a car's camera or radar detects obstacles and avoids them, or makes 
an emergency break.  There's only in-car communication to achieve it.

But when it's the webcam on the traffic lights pole (not on the car) 
that detects the pedestrian then that signal has to be transmitted to 
the car.  That uses communication from traffic light to the car.

I agree.

>     about 'best practices' of using IP in vehicular networks, including
>     OCB.  If _I_ were to write, but how about others?
> 
> 

Let us see.

Alex

>             Le 25 janv. 2018 à 18:44, Alexandre Petrescu
>             <[email-masked]
>             <mailto:[email-masked]>> a écrit :
> 
> 
>                         One particular aspect of ND on OCB links is how
>                         to make ND support SLAAC and Mobile IP between a
>                         Road-Side Unit and an On-Board Unit.  On WiFi
>                         links, a Host (role of OBU) receives an RA with
>                         a prefix and configures an address, which
>                         becomes a Care-of Address and triggers a BU. 
>                         But on OCB links, the Host may receive RA from
>                         distinct RSUs, without knowing
>                     This assumes that the Wi-Fi AP and the router are
>                     co-located, which is definitely not required.  You
>                     can easily have a Wi-FI topology with multiple
>                     routers sending RAs where the routers sit behind the
>                     AP or are clients themselves.
> 
> 
>             I agree, but whereas in WiFi the Access Points have an
>             option to 'bridge', in 802.11 OCB trials the Road-Side Units
>             are rarely bridges, and are often routers.  But I agree it
>             is possible to
>             And no, this would not indeed solve the problem of OBU
>             deciding which is the right OCB to connect to.
> 
>             But I think that if there is something that could help the
>             OBU to decide which OCB to connect to, then it must be in
>             the ND, because that's the first protocol run.
> 
>                         Another aspect of ND on OCB links relates to the
>                         use of OCB between two vehicles (not between the
>                         vehicle and the RSU). On such an OCB link there
>                         may be no RA dedicated to SLAAC, and the
>                         addresses used are link-local addresses.  But
>                         there could be RA to exchange the prefixes that
>                         are configured _inside_ the cars.  And, the use
>                         of MLDv2 is mandatory on these OCB links between
>                         two cars.
> 
> 
> 
>             As such I asked a colleague to solve the problem of car to
>             car communications without prefixes in ND and he came up with...
>             We may need to see whether it, Babel, scales well with a 10-
>             or 100-car convoy of vehicles aligned, or whether it has too
>             heavy in computing needs for small in-car platforms, or
>             whether it can help to _form_ the convoy (cars joining each
>             other, or car pulling
>                     _______________________________________________ its
>                     mailing list [email-masked] <mailto:[email-masked]>
>                     <https://www.ietf.org/mailman/listinfo/its>
> 
> 
>             _______________________________________________ its mailing
>             list [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
> 
>