Subject: [ipwave] Rechartering

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 24 Jan 2018 11:25:12 +0100

Hi,

Now that our first document is close to be shipped to the IESG for IETF
LC, the chairs and AD are starting to plan on potential rechartering
(as we anticipated in Singapore).

There are a number of things people have discussed in the past,
including the time of the BoFs. Now it is time to bring in the
ideas and suggest them on the mailing list.

Please, keep in mind some important considerations/constraints:

- We will schedule time on the f2f session in London for rechartering
discussion, _only if_ discussion has taken place on the mailing list.
So please, do not wait for the call for presentations during the
meeting to propose topics.

- Our current charter includes a "Problem Statement" item, which is
addressed in the document draft-ietf-ipwave-vehicular-networking.
Obviously, potential topics for rechartering should be covered there
(it will not make sense to work on topics that the community has not
agreed to be important and remain unsolved).

- A rechartering process will always take into account the energy level
of the WG and the completion level of the current milestones. This
means that we need to finish (submit to the IESG) our 2 documents
before we actually start working on the new topics.

Please, share your thoughts on the mailing list!

Thanks,

Carlos and Russs

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 24 Jan 2018 17:07:24 +0000

Hi Carlos,

Thanks for initiating the rechartering process. The initial work that the
group focussed on around, IPv6 over Requirements / 802.11-OCB is just the
enabler, but I tend to think we need to solve number of other problems for
Vehicular Connectivity, Road-side infra ..etc. I am very supportive of
this work and planning to contribute in the form of writing new proposals.

Regards
Sri

On 1/24/18, 2:25 AM, "its on behalf of Carlos Jesús Bernardos Cano"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>its mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/its

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Jan 2018 18:31:26 +0100

One aspect we discussed recently was the use of ND on OCB links.

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

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.

There can be an ND question between RSU and cars, and between cars, 
about the DNS server address.  Does the RA contain the address of the 
DNS server, is the DNS server in a car, or in the RSU.

Moreover, there have been several recent drafts that have -ipwave- and 
-nd- in the file names.  Maybe these drafts expose other problems on the 
use of ND on OCB.

Alex

---

From: Tony Li <[email-masked]>
Date: Wed, 24 Jan 2018 09:51:48 -0800

> 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 that there’s a problem of knowing the right OCB link to make, but that seems completely independent of ND.

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

Tony

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 25 Jan 2018 18:11:35 +0100

Hi Sri,

Can you please elaborate a bit more on specific topics you have in
mind? It'd be good to have a list of those discussed on the mailing
list over the next month, so we can have enough previous discussion by
the F2F meeting in London.

Thanks a lot!

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 25 Jan 2018 18:11:40 +0100

Hi Alex, Tony,

OK, I see the interest on looking into ND over OCB links, including
mobility and routing purposes. This is indeed interesting, but also
quite challenging (and potentially broad area). Some of these may also
need coordination with 6man.

Said that, let's keep discussing potential topics, but trying to narrow
the list down, to pieces of work that can be realistically done in 1-2
years (at typical IETF WG).

Thanks,

Carlos

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 that there’s a problem of knowing the right OCB link to make,
> but that seems completely independent of ND.
> 
> 
> > 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
> 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.
> 
> Tony
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Jan 2018 18:44:01 +0100

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

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

---

From: Jerome Haerri <[email-masked]>
Date: Thu, 25 Jan 2018 19:02:27 +0100

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?

Best Regards,

Jérôme

Envoyé de mon iPhone

> Le 25 janv. 2018 à 18:44, Alexandre Petrescu <[email-masked]> a écrit :
> 
> 
> 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.
> 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.
> 
> 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.
> 
> 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
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Jan 2018 09:20:19 +0100

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

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.

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?).

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.

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 am not sure whether this is the kind of idea you have about 'best
practice'?

Alex

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Jan 2018 11:45:09 +0100

Hi,

"802.11p" is no longer existing.  Now there is OCB mode in 802.11.

But, there are potential evolutions from the term "802.11p":

- 802.11"px" see references.
- OCB mode for 802.11ac ath10k to realize 1GBps for inter-car
   communications.  Linux kernel has an almost complete OCB mode
   in the mainstream.  Not sure it works with ath10k.
- other evolutions of 802.11 for vehicular communications.

We could consider putting IP on each of these.

Alex

References:
[18] NPRM commenting, by CAR 2 CAR Communication Consortium, Appendix
      7.1 Evolution towards IEEE 802.11px.
      Publicly available on the web.
[]   ITS(17)028012_Whitepaper_NXP-Autotalks.pdf mentions "802.11px"
      document at ETSI.
[]   NHTSA_V2V_NPRM_-_Cohda_Wireless_Comments_final.pdf
      Publicly available on the web.

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 29 Jan 2018 15:41:24 +0100

Hi Alex, All

Indeed...some on-going work in that direction...maybe simply referred to as ITS-G5 evolution (or DSRC evolutions)...

Another aspect, that actually might be controversial, but be worth at least discussing at the London meeting is C-V2X...there is no big issue to adapt IP over 3GPP LTE-V2X rel.14. All is specified...but the optimization is lacking...we are currently facing the same challenges as for pure ITS_G5 when it comes to IPv6 address configuration...and as for ITS-G5, if IETF targets a C-V2X usage over IPv6, without geonet stack (or IEEE Wave), then security comes back...

Maybe C-V2X could be worth discussing...let's see,

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday 29 January 2018 11:45
To: [email-masked]
Subject: Re: [ipwave] Rechartering - 802.11 advancements, "px", and OCB for 802.11ac in ath10k

Hi,

Alex

References:

Le 24/01/2018 à 11:25, Carlos Jesús Bernardos Cano a écrit :
> Hi,
> 
> Now that our first document is close to be shipped to the IESG for 
> IETF LC, the chairs and AD are starting to plan on potential 
> rechartering (as we anticipated in Singapore).
> 
> including the time of the BoFs. Now it is time to bring in the ideas 
> and suggest them on the mailing list.
> 
> - A rechartering process will always take into account the energy 
> level of the WG and the completion level of the current milestones. 
> This means that we need to finish (submit to the IESG) our 2 documents

---

From: François Simon <[email-masked]>
Date: Mon, 29 Jan 2018 10:45:07 -0500

Mr. Petrescu,

Be very careful here. One cannot make "names" on behalf of IEEE 802, such as "802.11px".  I do not know what is ath10K, however, as per IEEE 802.11-2016 (latest published standard), there is no synergy between 802.11 OCB and 802.11ac.  If there is such thing in the next release, I am not aware of. 

Sincerely,

Francois Simon

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday, January 29, 2018 5:45 AM
To: [email-masked]
Subject: Re: [ipwave] Rechartering - 802.11 advancements, "px", and OCB for 802.11ac in ath10k

Hi,

Alex

References:

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Jan 2018 19:46:44 +0100

Mr Simon,
Thank you for the remark.

For ath10k: it is the name of an open source driver from company Atheros 
(no advertisement).  It is very well known in the software developper 
community.  Its earlier versions - ath5k and ath9k - is what was used in 
very many prototypes of old 802.11p.

For 802.11"px": it is a name invented not by me, I just repeated it.  I 
agree it does not correspond to an official 802.11 activity (like e.g. 
802.11ax).

I do not know whether 802.11 groups consider the use of 802.11ac in OCB 
mode.  I would be curious if they did.

For 802.11p: many people in standards, software and hardware community 
related to ITS continue to say, write and label "802.11p" even though 
such thing does not exist anymore.  I think it will take time for this 
to disappear.

Alex