Skip to main content

Minutes IETF101: ipwave
minutes-101-ipwave-01

Meeting Minutes IP Wireless Access in Vehicular Environments (ipwave) WG
Date and time 2018-03-19 09:30
Title Minutes IETF101: ipwave
State Active
Other versions plain text
Last updated 2018-03-23

minutes-101-ipwave-01
IPWAVE WG meeting at IETF 101
MONDAY, 19 March 2018 at 0930-1200, Sandringham

Chairs: Russ Housley, Carlos J. Bernardos
Minute takers: Dorothy Stanley, Sri Gundavelli
Jabber scribe: Sri Gundavelli 


------------------------------------------------------------------------
9:30 Administrativia
     Presenters: Russ Housley (RH) and Carlos Bernardos (CB)
------------------------------------------------------------------------

CB:  We hope that the IPv6-over-OCB document is ready
right after this meeting.  If the pending issue is resolved today, then
the next step is review by the 6man WG, and then submit to IESG.

CB: We need review on the Use Cases, Survey and Problem Statement
document; without more discussion on the mail list, it cannot move
forward.

RH: The working group received a Liaison Statement: "LS on Establishment
of SAE Cellular V2X Technical Committee and Associated Task Forces".  No
response is needed since the IPWAVE WG is not taking on any work related
to 5G or LTE.

CB: There was a meeting on Collaboration on ITS Communication Standards
on March 9th.  CB participated remotely, and he provided an overview of
the work going on in the IPWAVE WG.


------------------------------------------------------------------------
** IPWAVE WG documents

Transmission of IPv6 Packets over IEEE 802.11 Networks in mode 
Outside the Context of a Basic Service Set (IPv6-over-80211ocb)
     Presenter: Alex Petrescu (AP)
     Draft: draft-ietf-ipwave-ipv6-over-80211ocb-21
------------------------------------------------------------------------

AP reviewed changes to the document since Singapore, and then he proposed
text to resolve the open issue.

Chair: are there any comments on the changes proposed?

Comment: Concern with non-QoS for certain high priority frames.

AP: Use of background is to compare with other traffic in the network
that is not IP traffic.  In some use cases, adaptive cruise control and
platooning scenarios, should have a priority higher than background.
However, possible to have background value for IP.  We can consider a
change to that in the future.

Chair: I see agreement on the text proposed for the document. Once the
draft is updated, we will sent it to the 6MAN WG for review (as required
by the charter).  Once that review is complete, it will be sent to the
IESG.


------------------------------------------------------------------------
IP-based Vehicular Networking: Use Cases, Survey and Problem Statement
      Presenter: Jaehoon Paul Jeong (JPJ)
      Draft: draft-ietf-ipwave-vehicular-networking-02
------------------------------------------------------------------------

JPJ presented the latest revision of the draft.  The next steps are:
    - Synchronize with IPv6-over-802.11ocb
    - Enhance use case section
    - WG Last call

Justin Dean (JD) [MANET WG chair]: Document does not clearly state the
problems that need to be solved, but it does describe a set of solutions. 

Suresh Krishnan (SK) [Area Director]: Have a goal of reducing the number
of purely informational documents.  We have not seen a lot of discussion
on this document.  If problem statement document does not advance; it can
still be viewed as a resource for the IPWAVE WG.  That said, we want the
WG to agree on the set of problems to be solved.

JD and SG volunteers to review the document in 2-3 weeks.

------------------------------------------------------------------------
** Rechartering discussion
------------------------------------------------------------------------

SK introduces the goals for the rechartering discussion. Routing
protocols are out of scope. Work on the PS document is a pre-condition
to do rechartering. Discussion on the PS is needed in the WG.

------------------------------------------------------------------------
IP Interfaces for RSU Manageability
      Presenter: Sri Gundavelli
------------------------------------------------------------------------

Sri Gundavelli (SG): Focus has been on how to transmit a packet, but
there has been no discussion of neighbor discovery.  Several gaps in
protocols related to security and manageability.

Tony Li (TL): Current solution works; no special version of neighbor
discovery is needed.

Erik Nordmark (EN): There is question on handover behaviour.  Every 1K
meters have a transfer to roadside unit.  Maybe some components can be
optimized.

Comment: About semantics: Yes, it works.  Does it work efficiently?
Neighbor table may change very rapidly.  Maybe we can improve efficiency
in highly mobile environment.

Comment: In cellular, we have large network infrastructure that manages
IP addresses, and we want to see equivalent components here.

Comment: IETF does protocols, not architectures. Let other SDOs work on
the architecture.  Are there specific pain points that we need to fix? 

SG: A set of questions about IPv6 ND for 802.11-OCB
    - What exactly defines an IPv6 link for such environments?
    - What is the impact of fast moving nodes?
    - how IPv6 prefixes hosted?
      -- Need explanation of system view, especially vehicle versus RDU.

Comment: Any prefixes hosted in the vehicle will be NATed. Router is
advertising the RAs.

Comment: No NAT in the car.

Jabber Comment: RSUs are not required for communication.

SK: That is a deployment question.  We do not need to do it here.
Similar to roaming on WLAN; we do not define how the roaming works.
Questions are valid, but it does not need to be done here.  Talking
about a mobility problem belongs in other IETF WGs, these are not a
problem of running IPv6 over OCB.

Comment: If we discover a problem with multicast, do we do that here?

SK: Yes, but do not pre-suppose a link model.

Comment: OCB is for a particular environment.

SK: Vehicle to Vehicle – a MANET problem.  Need to be very specific.

Comment: Neighbor environment is very dynamic, including hidden
terminals. V2V with no RSU in path. How do identities map for
security?

Comment: 802.11 considering evolution of PHY mechanisms.  It will be
backwards compatible, enable future extensions, and new use cases.

SG: Vehicular Mobility Anchor – Do we need to introduce the concept of
an anchor for vehicular networks.

Comment: Need to provide guidance on services and applications – what
applications/traffic is central gateway used for?

Comment: As soon as support IPv6, you get all internet applications.
They all just work because it is IP.  Nothing fancy needed; just pass
the packets.

Comment: How many links does the vehicle pass?

Comment: Care about V2V.

Comment: Crossing mobility domains difficult – not sure want to take
that on.

Comment: Vehicle network architecture – reduce delay.

Comment: OCB support all identified use cases today.  New IEEE 802.11
PHY work for longer range, higher throughput – IEEE 802.11-NGV Study
Group started work on the Next Generation V2X.


------------------------------------------------------------------------
Potential new work item: Mapping IP to Access Category in 802.11-OCB
      Presenter: Jérôme Härri (JH)
------------------------------------------------------------------------

TL: I do not think how this works operationally.  We do not have
security today on DSCP.  How do prevent DSCP from being forged?  We do
not have a way to prevent it.  There are no mechanisms out there today. 

JH explained the 3 steps that can be used for solving this (see slides).

AP: With respect to DSCP not being secure, any one on the Internet can
replace it in the middle.  This could be secured with IPSec.

SK: Its not clear from the presentation on what you are proposing.  We
need some justification on why it needs done and what needs to be done.

JH: We need to have some default mappings.

SK: I understand you want to define some defaults.  Take IPWAVE traffic
and map it to some DSCP values. You want to define those values?

JH: Yes.


------------------------------------------------------------------------
Prefix/Service Discovery, DNS Naming and Seamless IP Networking
      Presenter: Jaehoon Paul Jeong (JPJ)
      Drafts: draft-jeong-ipwave-vehicular-neighbor-discovery-02
              draft-jeong-ipwave-iot-dns-autoconf-02
------------------------------------------------------------------------

JPJ suggested three new work items for the IPWAVW WG:
   - Vehicular Neighbor Discovery for V2X Networking
     - Prefix Discovery
     - Service Discovery
   - DNS Naming Services
   - Seamless IP Networking


------------------------------------------------------------------------
IP for V2V and V2I
      Presenter: Alex Petrescu (AP)
------------------------------------------------------------------------

AP: A movement detection procedure that measures the signal strength of
IP messages that can be used as 'Beacons'.  These Beacon IP messages
should contain enough IP and L2 information for a mobile router to
decide whether to change the subnet and send a Binding Update.  Note
that the MAC address of IP-RSU and prefix of the link are not
sufficient.

EN: Asked how the DNS naming works and why its needs.  Use of DNS, or
re-creating the same steps for this use case of two neighboring cars
which will stay together for 2 seconds is starting on a wrong premise.

AP: Agreed with Erik's comment.  We need to think about boot strapping
of communication between vehicles.

TL: We seem to be taking about things that are not OCB specific.  There
are already other zero-conf and other approaches.  Lets not re-invent the
vehicle please.

JH: There is going to be strong specifications from SAE and ITU


------------------------------------------------------------------------
Rechartering discussion and open mic
------------------------------------------------------------------------

JPJ: Current document survey many topics, we need to focus on few
problems.  After mail list discussion, we should discuss what topics we
should work on and then I will update the document.

TL: IP lacks security and by design.  Do not look at IETF for help.
Rotating MAC address will break every thing.

SK reminded people about MAC randomization experiments.

Sandra: We need to focus on specific problems based on the survey
document.  Maybe we supposed to include link models and mobility
problems.