Minutes for ITS at IETF-95
minutes-95-its-4

IETF 95
Buenos Aires, April 3 - 8, 2016

Intelligent Transportation Systems (ITS) BOF

14:00-16:00, Wednesday Afternoon session I, Room Buen Ayre C

Meet echo Recording:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_ITS&chapter=chapter_1
Jabber Log: http://www.ietf.org/jabber/logs/its/2016-04-06.html

Scribes: Charles Perkins.

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 Rescorla: Why make any representation about exceeding speedlimit.
Alex: It's just an example
Eric Rescorla: 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 Rescorla: 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

Michelle Wetterwald:
- 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.

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
  What documents are needed to advance this work?

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 Gellens: We have that with ISO, 3GPP, etc.

~~~~~~~~

Closing remarks:
===============

As a wrap-up, we have a two-step plan:
1. Discuss the Charter text on the list, with thorough discussion needed, and
2. (if and only if #1 happens) hold an interim.