Subject: [its] Raw meeting minutes

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Apr 2016 19:46:41 -0300

Raw meeting minutes, thanks to minute takers for efforts despite echo-ey 
PA system.

Alex

------------------------------------------------------------------

Minutes for [its]

• Introduction:

– Administrative - BOF Chairs - 5 min

– ITS Goals and Success Criteria - BOF Chairs - 10 min

• Problem Space:

– Tutorial of IP in vehicular communications - Alex Petrescu - 20 min
Randel Gelland: Since there are so many MAC & PHY, they use their own
     messaging -- so could use IP.  But vehicals are using different PHY
     & MAC, so they can't communicate
Alex: But some of the radios are actually compatible

Bob Hinden: On "Topology" slide -- this is very simplified.  There will be
     many cars, with very dynamic interconnection
Alex: Yes.  Gives more examples to support contention

Dapeng Liu: Once connectivity is established,
             IP will enable better communication.

Pat Thaler: Even for compatible PHY, MACs may be different, so can't 
just day
     "use IP"

Erik Nordmark: Have people considered what the IP addressing will look like?
     In the car, the addressing is stable, but not outside the car.  How
     does one car know the address in the other car?
Alex: Yes, people are working on this.  IETF can help.

Carlos: Are people working on the addressing sheme.

Dino: We have an IP mobility problem

Dirk Kircher: Broadcast.  Semantic layer.
Alex: There may be multiple hops beween cars, and multiple hops in a car.
     May need IPv4 broadcast, or IPv6 broadcast

Dino: Even without the mobility problem, we still would have physical layer
     incompatible problems.  But that is exactly what IP solves.

– ITS use-cases C-ACC and Platooning - Alex Petrescu - 10 min
draft-petrescu-its-cacc-sdo-04

<while presenting Platooning scalability slide>
Lou Berger: Hackable.  What's the security model?
Alex: Do not have slides about this.
Eric Rescolo: Why make any representation about exceeding speedlimit.
Alex: It's just an example
Eric Rescolo: What if the police ask this question?
<comment from floor - add speed parameter>

Sandra: there is a lot of work being done on security
     = Safety part

Eric Burdick: There are a lot of privacy issues.  There is work about 
jamming.
     It's not just Mobile IP.

Erik Nordmark: There was an IETF plenary that is relevant to security.
     = Police can probaly go get the data

Eric Rescolo: Lots of work to be done -- prevent querying in the car.

– ITS V2V problem statement - Dapeng Liu - 5 min
draft-petrescu-its-problem-00

Randel Gelland: How do they know when they need to discover the other 
vehicles'
     address?
Dirk Kircher: Sub-Problem(1) needs to be characterized correctly. What is a
     realistic use case:  Answer: C-ACC

...: do you have data?
Alex: How much data do you want?

Randel Gellens: This shows how IP is useful, but it's not why IP is needed?
     So it is needed to exhibit the need, not just the use case.

Erik Nordmark: how identities (or even temporary identities) established?

Hannes Tshofenig: Is there a need for another layer for identity?

– ITS V2I problem statement - Jaehoon Paul Jeong - 5 min
draft-jeong-its-v2i-problem-statement-00

Charlie: What does it mean to "directly" connect to the RSO's network
Jaehoon: Exchange prefixes

Woman <did not understand, sorry>

Dino: a lost packet could be a catastrophe, amidst a lot of connection.
     Need to avoid chit-chat.  Should avoid multiple solutions.
     If security requires Diffie-Hellman, may not get to finally say "BRAKE"
Dino: May not be able to go get a certificate.

<....?>: May not have time to

Dirk Kircher: Question about use case...

Alex: Some operators already provide connection between RSUs, and thus
     can provide handovers

• Discussion - 10 min

Aaron Falk: Good to have the discussion.  Useful confusion [??}
Dirk Kircher: Use cases need discussion, as well as network drivers.
Carlos: Are you talking about requirements?
Dirk: Network requirements...
Erik Nordmark: Don't really grasp exactly why IP is needed for single hop.
     Will this use the same Internet?  What about the timing requirements?
Stan Ratliff: V2V could be mobile ad hoc network?
Russ: Not if it's just one hop.
<...> : Want to know what cars are closing in.  Could want to send message
     just backwards.
Dino: What if you *don't* have IP?  A lot of vehicles already have IP, so it
     is already there.  IP could simplify the automobile and the
     communications.  We will want to write applications.  Will need to have
     compatible format.  We will want open standards.
Spencer Dawkins: Was waiting for a transport question. Applications might be
     close to each other?  About updating the car.
Hannes: Applications might be running on many different computers and media,
     but still need to communicate.
Pat Thaler: Updating the car is a different sort of thing than V2I.  We will
     have updates at the service station, so you're not moving.
     Three concerns: security problem. Time constraints.
Spencer: Need to understand what the volume of data would be.
Dirk: Is it, or is it not, TCP?  There are a couple of protocols in use 
today.
Eric Burdick: Should assume that all protocols are broken.
     The control mechanisms could collapse with the number of cars.

– What documents are needed to advance this work?
http://itu.int/go/ITScomms is complete list of ITU work items

Dino: Why include trains but not planes?
Alex: O.K.
Erik Burdick: What about when get onto the ocean?
Dirk: Some of the use cases are very dissimilar.  Need to pick one problem.
Aaron from Jabber: Can assume use of certificates.
Dino: Need to look at the requirements and see if there are solutions,
     even though there are a lot of work items.
Erik Nordmark: Can we figure out what is needed for the immediate term?
Randall Gellens: What about coordination with other SDOs?  For instance
     regarding IPv6-over-foo.
Alex: With a working group we can have a channel by which to do the 
coordination
Randall: We have that with ISO, 3GPP, etc.

Closing remarks:
We will publish the charter on the working group.  In about a month we
will see if we have a rigorous charter.

---

From: Michelle Wetterwald <[email-masked]>
Date: Wed, 6 Apr 2016 21:57:22 -0300

Hi Alex, all,

Thank you for these minutes

I would like to rephrase here the two comments that I made  during the
meeting to the V2I problem statement draft and could not be captured in the
minutes:
- in the V2I case, the performance of the system and the coverage time vs.
vehicle speed should be taken into account. At the contrary of the V2V
C-ACC case you described where both cars are moving in the same direction,
which ensures some time to exchange prefixes, names, etc., in the V2I case,
the coverage time with one RSU may be short. Thus this signalling should
have a really low latency.
- Secondly, the potential congestion of the system when hundreds of cars
would be located in the same area and establishing or using V2I
communications should also be taken into account as an issue. Switching
part of the traffic to a more available channel, as was proposed, may not
always be possible. Reducing the size of the packet, however, by using
header compression technique as in 6lo, may offer a potential improvement.

Best regards,
Michelle Wetterwald
----
Senior expert in networking and telecommunications

2016-04-06 19:46 GMT-03:00 Alexandre Petrescu <[email-masked]>
:

> Pat Thaler: Even for compatible PHY, MACs may be different, so can't just
> day
>     "use IP"
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>

-- 
Michelle Wetterwald
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Apr 2016 10:45:58 -0300

Le 06/04/2016 21:57, Michelle Wetterwald a écrit :
> meeting to the V2I problem statement draft and could not be captured in
> the minutes:
> - in the V2I case, the performance of the system and the coverage time
> vs. vehicle speed should be taken into account. At the contrary of the
> V2V C-ACC case you described where both cars are moving in the same
> direction, which ensures some time to exchange prefixes, names, etc., in
> the V2I case, the coverage time with one RSU may be short. Thus this
> signalling should have a really low latency.

I fully agree, that's the case.  Dino also said things in this direction.

> part of the traffic to a more available channel, as was proposed, may
> not always be possible. Reducing the size of the packet, however, by
> using header compression technique as in 6lo, may offer a potential
> improvement.

Do you think 6lo RFC techniques are compatible with using IP in moving 
network to nearby moving or fixed network communications?

AFAIK 6lo implementations are on low-power radios (i.e. 802.15.4, 
bluetooth), and as such have very small coverage, with cells like 10m. 
Can a gar connect to it if moving at more than 10kmph?

Or is it that car uses 6lo to connect to a gas station RSU while filling 
gas?  If so it's V2I.

Or is it that driver uses 6lo NFC card to open/close doors?  That's 
_one_ fixed network (the car) and a Host (the NFC card) - it's not 
moving network to nearby moving or fixed network communications.

If we could frame it as moving network to nearby moving or fixed network 
communications for V2V and/or V2I, then it's in scope.

Alex

> 2016-04-06 19:46 GMT-03:00 Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>>:
>
>     Raw meeting minutes, thanks to minute takers for efforts despite
>     echo-ey PA system.
>
>     Alex
>
>     Eric Burdick: There are a lot of privacy issues.  There is work
>     about jamming.
>          It's not just Mobile IP.
>
>     Randel Gelland: How do they know when they need to discover the
>     other vehicles'
>          address?
>     Dirk: Is it, or is it not, TCP?  There are a couple of protocols in
>     use today.
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 8 Apr 2016 07:10:17 -0700

I am wondering if v2v can succeed better with no data-oriented commmunication (IP protocols get in the say and actually slow down reaction time). Maybe the front facing camera alone provides enough information to the computing elements in the following car to detect when its getting close to the car it is following.

The rate the image increases in size can determine the rate and distance you are to the car in front of you. 

Just wondering ...

Dino

> On Apr 8, 2016, at 6:45 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> Do you think 6lo RFC techniques are compatible with using IP in moving network to nearby moving or fixed network communications?
> 
> AFAIK 6lo implementations are on low-power radios (i.e. 802.15.4, bluetooth), and as such have very small coverage, with cells like 10m. Can a gar connect to it if moving at more than 10kmph?
> 
> Or is it that car uses 6lo to connect to a gas station RSU while filling gas?  If so it's V2I.
> 
> Or is it that driver uses 6lo NFC card to open/close doors?  That's _one_ fixed network (the car) and a Host (the NFC card) - it's not moving network to nearby moving or fixed network communications.
> 
> If we could frame it as moving network to nearby moving or fixed network communications for V2V and/or V2I, then it's in scope.
> 
> Alex
> 
>> 
>> Best regards,
>> Michelle Wetterwald
>> ----

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Apr 2016 12:05:37 -0300

Le 08/04/2016 11:10, Dino Farinacci a écrit :
> I am wondering if v2v can succeed better with no data-oriented
> commmunication (IP protocols get in the say and actually slow down
> reaction time). Maybe the front facing camera alone provides enough
> information to the computing elements in the following car

It would be wonderful if it were possible that the front camera of a
truck wirelesly sends data to rear vehicles.  But that's not possible
because the truck frame in between is blocking these waves.

That's why people plug the camera (some times IP-enabled) to an IP
router in the truck which has additional IP interface (11p) towards the
car behind.

The car behind sends IP service discovery requests, and then receives an
IP stream of video which shows what the truck sees.

But beware human behaviour: analysts say that driver is too distracted
by the realism of the image streamed by the truck - s/he believes being
_in_ the truck and hits it.

(multiple demonstrators exhibit this; the Samsung Safety Truck is shown
just because we're in Argentina and it made much publicity).

> to detect when its getting close to the car it is following.

Yes, many cars on the market today analyse the image of the front and
make multiple decisions to avoid hitting cars, pedestrians, keep lane,
and so on.

But that's an image processing problem, not communication problem.

The problems of the webcams in reocnizing obstacles is that they may
issue false positives.  That's why they're assisted by radars.  But
radars have other problems on metal bridges.  Assisted by lidars too,
but these are too big and too latent.

That's why only message exchanges (preferentially using TCP/IP
protocols) are able to improve current systems of obstacle avoidance,
lane keeping, self driving, etc.

Alex

>
> The rate the image increases in size can determine the rate and
> distance you are to the car in front of you.
>
> Just wondering ...
>
> Dino
>
>>> I would like to rephrase here the two comments that I made during
>>> the meeting to the V2I problem statement draft and could not be
>>> captured in the minutes: - in the V2I case, the performance of
>>> the system and the coverage time vs. vehicle speed should be
>>> taken into account. At the contrary of the V2V C-ACC case you
>>> described where both cars are moving in the same direction, which
>>> ensures some time to exchange prefixes, names, etc., in the V2I
>>> case, the coverage time with one RSU may be short. Thus this
>>> - Secondly, the potential congestion of the system when hundreds
>>> of cars would be located in the same area and establishing or
>>> using V2I communications should also be taken into account as an
>>> issue. Switching part of the traffic to a more available channel,
>>> as was proposed, may not always be possible. Reducing the size of
>>> the packet, however, by using header compression technique as in
>>> 6lo, may offer a potential improvement.
>>
>> Do you think 6lo RFC techniques are compatible with using IP in
>> moving network to nearby moving or fixed network communications?
>>
>> bluetooth), and as such have very small coverage, with cells like
>> 10m. Can a gar connect to it if moving at more than 10kmph?
>>
>> If we could frame it as moving network to nearby moving or fixed
>> network communications for V2V and/or V2I, then it's in scope.
>>
>> Alex
>>
>>>
>>> Best regards, Michelle Wetterwald ---- Senior expert in
>>> networking and telecommunications
>>>
Minutes for [its]
>>> – Tutorial of IP in vehicular communications - Alex Petrescu -
>>> 20 min Randel Gelland: Since there are so many MAC & PHY, they
>>> use their own messaging -- so could use IP.  But vehicals are
>>> using different PHY & MAC, so they can't communicate Alex: But
>>> some of the radios are actually compatible
>>>
>>> Bob Hinden: On "Topology" slide -- this is very simplified. There
>>> will be many cars, with very dynamic interconnection Alex: Yes.
>>> Gives more examples to support contention
>>>
>>> Dapeng Liu: Once connectivity is established, IP will enable
>>> better communication.
>>>
>>> Pat Thaler: Even for compatible PHY, MACs may be different, so
>>> can't just day "use IP"
>>>
>>> Erik Nordmark: Have people considered what the IP addressing will
>>> look like? In the car, the addressing is stable, but not outside
>>> the car.  How does one car know the address in the other car?
>>> Dirk Kircher: Broadcast.  Semantic layer. Alex: There may be
>>> multiple hops beween cars, and multiple hops in a car. May need
>>> IPv4 broadcast, or IPv6 broadcast
>>>
>>> Dino: Even without the mobility problem, we still would have
>>> physical layer incompatible problems.  But that is exactly what
>>> IP solves.
>>>
>>> <while presenting Platooning scalability slide> Lou Berger:
>>> Hackable.  What's the security model? Alex: Do not have slides
>>> about this. Eric Rescolo: Why make any representation about
>>> exceeding speedlimit. Alex: It's just an example Eric Rescolo:
>>> What if the police ask this question? <comment from floor - add
>>> speed parameter>
>>>
>>> Sandra: there is a lot of work being done on security = Safety
>>> part
>>>
>>> about jamming. It's not just Mobile IP.
>>>
>>> Erik Nordmark: There was an IETF plenary that is relevant to
>>> security. = Police can probaly go get the data
>>>
>>> other vehicles' address? Dirk Kircher: Sub-Problem(1) needs to
>>> be characterized correctly. What is a realistic use case:
>>> Answer: C-ACC
>>>
>>> ...: do you have data? Alex: How much data do you want?
>>>
>>> Randel Gellens: This shows how IP is useful, but it's not why IP
>>> is needed? So it is needed to exhibit the need, not just the use
>>> case.
>>>
>>> Charlie: What does it mean to "directly" connect to the RSO's
>>> network Jaehoon: Exchange prefixes
>>>
>>> Dino: a lost packet could be a catastrophe, amidst a lot of
>>> connection. Need to avoid chit-chat.  Should avoid multiple
>>> solutions. If security requires Diffie-Hellman, may not get to
>>> finally say "BRAKE" Dino: May not be able to go get a
>>> certificate.
>>>
>>> Alex: Some operators already provide connection between RSUs,
>>> and thus can provide handovers
>>>
>>> • Discussion - 10 min
>>>
>>> Dirk Kircher: Use cases need discussion, as well as network
>>> drivers. Carlos: Are you talking about requirements? Dirk:
>>> Network requirements... Erik Nordmark: Don't really grasp
>>> exactly why IP is needed for single hop. Will this use the same
>>> Internet? What about the timing requirements? Stan Ratliff: V2V
>>> could be mobile ad hoc network? Russ: Not if it's just one hop.
>>> <...> : Want to know what cars are closing in.  Could want to
>>> send message just backwards. Dino: What if you *don't* have IP? A
>>> lot of vehicles already have IP, so it is already there.  IP
>>> could simplify the automobile and the communications.  We will
>>> want to write applications.  Will need to have compatible format.
>>> We will want open standards. Spencer Dawkins: Was waiting for a
>>> transport question. Applications might be close to each other?
>>> About updating the car. Hannes: Applications might be running on
>>> many different computers and media, but still need to
>>> communicate. Pat Thaler: Updating the car is a different sort of
>>> thing than V2I. We will have updates at the service station, so
>>> you're not moving. Three concerns: security problem. Time
>>> constraints. Spencer: Need to understand what the volume of data
>>> would be. Dirk: Is it, or is it not, TCP?  There are a couple of
>>> protocols in use today. Eric Burdick: Should assume that all
>>> protocols are broken. The control mechanisms could collapse with
>>> the number of cars.
>>>
>>> Dino: Why include trains but not planes? Alex: O.K. Erik
>>> Burdick: What about when get onto the ocean? Dirk: Some of the
>>> use cases are very dissimilar.  Need to pick one problem. Aaron
>>> from Jabber: Can assume use of certificates. Dino: Need to look
>>> at the requirements and see if there are solutions, even though
>>> there are a lot of work items. Erik Nordmark: Can we figure out
>>> what is needed for the immediate term? Randall Gellens: What
>>> about coordination with other SDOs?  For instance regarding
>>> IPv6-over-foo. Alex: With a working group we can have a channel
>>> by which to do the coordination Randall: We have that with ISO,
>>> 3GPP, etc.
>>>
>>> Closing remarks: We will publish the charter on the working
>>> group.  In about a month we will see if we have a rigorous
>>> charter.
>>>
>>> _______________________________________________ its mailing list
>>> -- Michelle Wetterwald [email-masked]
>>> <mailto:[email-masked]>
>>
>> _______________________________________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 8 Apr 2016 14:33:17 -0700

The whole point and question is, the car, as a single unit, being self sufficient is probably the best way to solve this v2v problem.

Dino

> On Apr 8, 2016, at 8:05 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
>

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 11 Apr 2016 09:28:02 +0200

Dear ITSer,

In the different e-mails exchanged, there seems to be always reference to industrial products that would use IP (IPv6 I guess) in vehicles, as an example and justification of the need for an IPv6 solution for V2V and V2I. 

In order to give a clear overview of what the industry plans for this, I mentioned in my previous e-mail that the IETF ITS should create a WI, which would aim at referencing industrial products or vision that would foresee an IETF need in ITS, and which could not be solved by other SDOs (WAVE,...). 

As mentioned in my previous e-mail, getting a list of academic papers is only one side of the mirror, and my itself will not justify a WG...we need an industrial justification and support. 

Best Regards,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Friday 08 April 2016 23:33
To: Alexandre Petrescu
Cc: [email-masked]; Michelle Wetterwald
Subject: Re: [its] 6lo

Dino

> router in the truck which has additional IP interface (11p) towards 
> the car behind.
> 
> The car behind sends IP service discovery requests, and then receives 
> an IP stream of video which shows what the truck sees.
> 
> by the realism of the image streamed by the truck - s/he believes 
> being _in_ the truck and hits it.
> 
> (multiple demonstrators exhibit this; the Samsung Safety Truck is 
> shown just because we're in Argentina and it made much publicity).
> 
>>>> captured in the minutes: - in the V2I case, the performance of the 
>>>> system and the coverage time vs. vehicle speed should be taken into 
>>>> account. At the contrary of the V2V C-ACC case you described where 
>>>> both cars are moving in the same direction, which ensures some time 
>>>> to exchange prefixes, names, etc., in the V2I case, the coverage 
>>>> time with one RSU may be short. Thus this signalling should have a 
>>>> really low latency.
>>> 
>>>> - Secondly, the potential congestion of the system when hundreds of 
>>>> cars would be located in the same area and establishing or using 
>>>> V2I communications should also be taken into account as an issue. 
>>>> Switching part of the traffic to a more available channel, as was 
>>>> proposed, may not always be possible. Reducing the size of the 
>>>> packet, however, by using header compression technique as in 6lo, 
>>>> may offer a potential improvement.
>>> 
>>>> Best regards, Michelle Wetterwald ---- Senior expert in networking 
>>>> and telecommunications
>>>> 
>>>> 20 min Randel Gelland: Since there are so many MAC & PHY, they use 
>>>> their own messaging -- so could use IP.  But vehicals are using 
>>>> different PHY & MAC, so they can't communicate Alex: But some of 
>>>> the radios are actually compatible
>>>> 
>>>> Dapeng Liu: Once connectivity is established, IP will enable better 
>>>> communication.
>>>> 
>>>> physical layer incompatible problems.  But that is exactly what IP 
>>>> solves.
>>>> 
>>>> Sandra: there is a lot of work being done on security = Safety part
>>>> 
>>>> other vehicles' address? Dirk Kircher: Sub-Problem(1) needs to be 
>>>> characterized correctly. What is a realistic use case:
>>>> Answer: C-ACC
>>>> 
>>>> Randel Gellens: This shows how IP is useful, but it's not why IP is 
>>>> needed? So it is needed to exhibit the need, not just the use case.
>>>> 
>>>> finally say "BRAKE" Dino: May not be able to go get a certificate.
>>>> 
>>>> Alex: Some operators already provide connection between RSUs, and 
>>>> thus can provide handovers
>>>> 
>>>> • Discussion - 10 min
>>>> 
>>>> Network requirements... Erik Nordmark: Don't really grasp exactly 
>>>> why IP is needed for single hop. Will this use the same Internet? 
>>>> What about the timing requirements? Stan Ratliff: V2V could be 
>>>> mobile ad hoc network? Russ: Not if it's just one hop.
>>>> <...> : Want to know what cars are closing in.  Could want to send 
>>>> message just backwards. Dino: What if you *don't* have IP? A lot of 
>>>> vehicles already have IP, so it is already there.  IP could 
>>>> simplify the automobile and the communications.  We will want to 
>>>> write applications.  Will need to have compatible format.
>>>> many different computers and media, but still need to communicate. 
>>>> Pat Thaler: Updating the car is a different sort of thing than V2I. 
>>>> We will have updates at the service station, so you're not moving. 
>>>> Three concerns: security problem. Time constraints. Spencer: Need 
>>>> to understand what the volume of data would be. Dirk: Is it, or is 
>>>> it not, TCP?  There are a couple of protocols in use today. Eric 
>>>> Burdick: Should assume that all protocols are broken. The control 
>>>> mechanisms could collapse with the number of cars.
>>>> 
>>>> Burdick: What about when get onto the ocean? Dirk: Some of the use 
>>>> cases are very dissimilar.  Need to pick one problem. Aaron from 
>>>> Jabber: Can assume use of certificates. Dino: Need to look at the 
>>>> requirements and see if there are solutions, even though there are 
>>>> a lot of work items. Erik Nordmark: Can we figure out what is 
>>>> needed for the immediate term? Randall Gellens: What about 
>>>> coordination with other SDOs?  For instance regarding 
>>>> IPv6-over-foo. Alex: With a working group we can have a channel by 
>>>> which to do the coordination Randall: We have that with ISO, 3GPP, 
>>>> etc.
>>>> 
>>>> Closing remarks: We will publish the charter on the working group.  
>>>> In about a month we will see if we have a rigorous charter.
>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Apr 2016 09:50:01 +0200

Jérôme,

That is right.

A WI (Working Group Item) should be written for each need, and according 
to participants' interest.

Currently, there is interest in several WG items.

I will reply separately to your initial email.

Alex

Le 11/04/2016 09:28, Jérôme Härri a écrit :
> Dear ITSer,
>
> In the different e-mails exchanged, there seems to be always
> reference to industrial products that would use IP (IPv6 I guess) in
> vehicles, as an example and justification of the need for an IPv6
> solution for V2V and V2I.
>
> In order to give a clear overview of what the industry plans for
> this, I mentioned in my previous e-mail that the IETF ITS should
> create a WI, which would aim at referencing industrial products or
> vision that would foresee an IETF need in ITS, and which could not be
> solved by other SDOs (WAVE,...).
>
> As mentioned in my previous e-mail, getting a list of academic papers
> is only one side of the mirror, and my itself will not justify a
> WG...we need an industrial justification and support.
>
> Best Regards,
>
> Jérôme
>
> -----Original Message----- From: its [mailto:[email-masked]] On
> Behalf Of Dino Farinacci Sent: Friday 08 April 2016 23:33 To:
> Alexandre Petrescu Cc: [email-masked]; Michelle Wetterwald Subject: Re:
> [its] 6lo
>
> The whole point and question is, the car, as a single unit, being
> self sufficient is probably the best way to solve this v2v problem.
>
> Dino
>
>>> commmunication (IP protocols get in the say and actually slow
>>> down reaction time). Maybe the front facing camera alone provides
>>> enough information to the computing elements in the following
>>> car
>>
>> It would be wonderful if it were possible that the front camera of
>> a truck wirelesly sends data to rear vehicles.  But that's not
>> possible because the truck frame in between is blocking these
>> waves.
>>
>> router in the truck which has additional IP interface (11p)
>> towards the car behind.
>>
>> The car behind sends IP service discovery requests, and then
>> receives an IP stream of video which shows what the truck sees.
>>
>> But beware human behaviour: analysts say that driver is too
>> distracted by the realism of the image streamed by the truck - s/he
>> believes being _in_ the truck and hits it.
>>
>> Yes, many cars on the market today analyse the image of the front
>> and make multiple decisions to avoid hitting cars, pedestrians,
>> keep lane, and so on.
>>
>> The problems of the webcams in reocnizing obstacles is that they
>> may issue false positives.  That's why they're assisted by radars.
>> But radars have other problems on metal bridges.  Assisted by
>> lidars too, but these are too big and too latent.
>>
>> protocols) are able to improve current systems of obstacle
>> avoidance, lane keeping, self driving, etc.
>>
>> Alex
>>
>>>
>>>>> I would like to rephrase here the two comments that I made
>>>>> during the meeting to the V2I problem statement draft and
>>>>> could not be captured in the minutes: - in the V2I case, the
>>>>> performance of the system and the coverage time vs. vehicle
>>>>> speed should be taken into account. At the contrary of the
>>>>> V2V C-ACC case you described where both cars are moving in
>>>>> the same direction, which ensures some time to exchange
>>>>> prefixes, names, etc., in the V2I case, the coverage time
>>>>> with one RSU may be short. Thus this signalling should have
>>>>> a really low latency.
>>>>
>>>>> - Secondly, the potential congestion of the system when
>>>>> hundreds of cars would be located in the same area and
>>>>> establishing or using V2I communications should also be taken
>>>>> into account as an issue. Switching part of the traffic to a
>>>>> more available channel, as was proposed, may not always be
>>>>> possible. Reducing the size of the packet, however, by using
>>>> Do you think 6lo RFC techniques are compatible with using IP
>>>> in moving network to nearby moving or fixed network
>>>> communications?
>>>>
>>>> AFAIK 6lo implementations are on low-power radios (i.e.
>>>> 802.15.4, bluetooth), and as such have very small coverage,
>>>> with cells like 10m. Can a gar connect to it if moving at more
>>>> than 10kmph?
>>>>
>>>> Or is it that driver uses 6lo NFC card to open/close doors?
>>>> That's _one_ fixed network (the car) and a Host (the NFC card)
>>>> - it's not moving network to nearby moving or fixed network
>>>> communications.
>>>>
>>>> If we could frame it as moving network to nearby moving or
>>>> fixed network communications for V2V and/or V2I, then it's in
>>>> scope.
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> Raw meeting minutes, thanks to minute takers for efforts
>>>>> despite echo-ey PA system.
>>>>>
>>>>> Alex
>>>>>
Minutes for [its]
>>>>> – Tutorial of IP in vehicular communications - Alex Petrescu
>>>>> - 20 min Randel Gelland: Since there are so many MAC & PHY,
>>>>> they use their own messaging -- so could use IP.  But
>>>>> vehicals are using different PHY & MAC, so they can't
>>>>> communicate Alex: But some of the radios are actually
>>>>> compatible
>>>>>
>>>>> Bob Hinden: On "Topology" slide -- this is very simplified.
>>>>> There will be many cars, with very dynamic interconnection
>>>>> Pat Thaler: Even for compatible PHY, MACs may be different,
>>>>> so can't just day "use IP"
>>>>>
>>>>> Erik Nordmark: Have people considered what the IP addressing
>>>>> will look like? In the car, the addressing is stable, but not
>>>>> outside the car.  How does one car know the address in the
>>>>> other car? Alex: Yes, people are working on this.  IETF can
>>>>> help.
>>>>>
>>>>> multiple hops beween cars, and multiple hops in a car. May
>>>>> need IPv4 broadcast, or IPv6 broadcast
>>>>>
>>>>> physical layer incompatible problems.  But that is exactly
>>>>> what IP solves.
>>>>>
>>>>> – ITS use-cases C-ACC and Platooning - Alex Petrescu - 10
>>>>> min draft-petrescu-its-cacc-sdo-04
>>>>>
>>>>> Hackable.  What's the security model? Alex: Do not have
>>>>> slides about this. Eric Rescolo: Why make any representation
>>>>> about exceeding speedlimit. Alex: It's just an example Eric
>>>>> Rescolo: What if the police ask this question? <comment from
>>>>> floor - add speed parameter>
>>>>>
>>>>> Eric Burdick: There are a lot of privacy issues.  There is
>>>>> work about jamming. It's not just Mobile IP.
>>>>>
>>>>> Randel Gelland: How do they know when they need to discover
>>>>> the other vehicles' address? Dirk Kircher: Sub-Problem(1)
>>>>> needs to be characterized correctly. What is a realistic use
>>>>> case: Answer: C-ACC
>>>>>
>>>>> Randel Gellens: This shows how IP is useful, but it's not why
>>>>> IP is needed? So it is needed to exhibit the need, not just
>>>>> the use case.
>>>>>
>>>>> Charlie: What does it mean to "directly" connect to the
>>>>> RSO's network Jaehoon: Exchange prefixes
>>>>>
>>>>> solutions. If security requires Diffie-Hellman, may not get
>>>>> to finally say "BRAKE" Dino: May not be able to go get a
>>>>> certificate.
>>>>>
>>>>> Aaron Falk: Good to have the discussion.  Useful confusion
>>>>> [??} Dirk Kircher: Use cases need discussion, as well as
>>>>> network drivers. Carlos: Are you talking about requirements?
>>>>> Dirk: Network requirements... Erik Nordmark: Don't really
>>>>> grasp exactly why IP is needed for single hop. Will this use
>>>>> the same Internet? What about the timing requirements? Stan
>>>>> Ratliff: V2V could be mobile ad hoc network? Russ: Not if
>>>>> it's just one hop. <...> : Want to know what cars are closing
>>>>> in.  Could want to send message just backwards. Dino: What if
>>>>> you *don't* have IP? A lot of vehicles already have IP, so it
>>>>> communications.  We will want to write applications.  Will
>>>>> need to have compatible format. We will want open standards.
>>>>> Spencer Dawkins: Was waiting for a transport question.
>>>>> Applications might be close to each other? About updating the
>>>>> car. Hannes: Applications might be running on many different
>>>>> computers and media, but still need to communicate. Pat
>>>>> Thaler: Updating the car is a different sort of thing than
>>>>> V2I. We will have updates at the service station, so you're
>>>>> not moving. Three concerns: security problem. Time
>>>>> constraints. Spencer: Need to understand what the volume of
>>>>> data would be. Dirk: Is it, or is it not, TCP?  There are a
>>>>> couple of protocols in use today. Eric Burdick: Should assume
>>>>> that all protocols are broken. The control mechanisms could
>>>>> collapse with the number of cars.
>>>>>
>>>>> Burdick: What about when get onto the ocean? Dirk: Some of
>>>>> the use cases are very dissimilar.  Need to pick one problem.
>>>>> Aaron from Jabber: Can assume use of certificates. Dino: Need
>>>>> to look at the requirements and see if there are solutions,
>>>>> even though there are a lot of work items. Erik Nordmark: Can
>>>>> we figure out what is needed for the immediate term? Randall
>>>>> Gellens: What about coordination with other SDOs?  For
>>>>> instance regarding IPv6-over-foo. Alex: With a working group
>>>>> we can have a channel by which to do the coordination
>>>>> _______________________________________________ its mailing
>>>>> list [email-masked] <mailto:[email-masked]>
>>>> _______________________________________________ its mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>
>>>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Apr 2016 13:26:37 +0200

Michelle,

> time with one RSU may be short. Thus this signalling should have a

This looks like an IP handover performance issue, or improvement.  For 
the moment we do not look at it.

> cars would be located in the same area and establishing or using V2I
> communications should also be taken into account as an issue.

This kind of activity is typically part of IPv6-over-foo document.  For
example, look at RFC 2460 "Transmission of IPv6 Packets over Ethernet".

Do you think there is some work to do about IPv6-over-'foo'? ('foo' is a
link layer for vehicular communications.)

There can be something about leveraging 6lo techniques in IPv6-over-'foo'.

Do you know of a use-case needing 6lo techniques in vehicular networks?

Alex

> messaging -- so could use IP.  But vehicals are using different PHY &
> MAC, so they can't communicate Alex: But some of the radios are
> actually compatible
>
> will be many cars, with very dynamic interconnection Alex: Yes. Gives
> more examples to support contention
>
>  just day "use IP"
> look like? In the car, the addressing is stable, but not outside the
> car.  How does one car know the address in the other car? Alex: Yes,
> people are working on this.  IETF can help.
>
> multiple hops beween cars, and multiple hops in a car. May need IPv4
> broadcast, or IPv6 broadcast
>
> Hackable. What's the security model? Alex: Do not have slides about
> this. Eric Rescolo: Why make any representation about exceeding
> speedlimit. Alex: It's just an example Eric Rescolo: What if the
> police ask this question? <comment from floor - add speed parameter>
>
> characterized correctly. What is a realistic use case:  Answer:
> C-ACC
>
> Aaron Falk: Good to have the discussion.  Useful confusion [??} Dirk
> Kircher: Use cases need discussion, as well as network drivers.
> Carlos: Are you talking about requirements? Dirk: Network
> requirements... Erik Nordmark: Don't really grasp exactly why IP is
> needed for single hop. Will this use the same Internet?  What about
> the timing requirements? Stan Ratliff: V2V could be mobile ad hoc
> network? Russ: Not if it's just one hop. <...> : Want to know what
> cars are closing in.  Could want to send message just backwards.
> Dino: What if you *don't* have IP?  A lot of vehicles already have
> IP, so it is already there.  IP could simplify the automobile and the
> communications.  We will want to write applications.  Will need to
> have compatible format.  We will want open standards. Spencer
> Dawkins: Was waiting for a transport question. Applications might be
>  close to each other?  About updating the car. Hannes: Applications
> might be running on many different computers and media, but still
> need to communicate. Pat Thaler: Updating the car is a different
> sort of thing than V2I. We will have updates at the service station,
> so you're not moving. Three concerns: security problem. Time
> protocols are broken. The control mechanisms could collapse with the
> number of cars.
>
> Dino: Why include trains but not planes? Alex: O.K. Erik Burdick:
> What about when get onto the ocean? Dirk: Some of the use cases are
> very dissimilar.  Need to pick one problem. Aaron from Jabber: Can
> assume use of certificates. Dino: Need to look at the requirements
> and see if there are solutions, even though there are a lot of work
> items. Erik Nordmark: Can we figure out what is needed for the
> immediate term? Randall Gellens: What about coordination with other
> SDOs?  For instance regarding IPv6-over-foo. Alex: With a working
> group we can have a channel by which to do the coordination Randall:
> We have that with ISO, 3GPP, etc.
>
> Closing remarks: We will publish the charter on the working group. In
> about a month we will see if we have a rigorous charter.
>