Subject: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-02.txt

From: [email-masked]
Date: Mon, 05 Mar 2018 10:20:08 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF.

        Title           : IP-based Vehicular Networking: Use Cases, Survey and Problem Statement
        Author          : Jaehoon Paul Jeong
	Filename        : draft-ietf-ipwave-vehicular-networking-02.txt
	Pages           : 52
	Date            : 2018-03-05

Abstract:
   This document discusses use cases, survey, and problem statement on
   IP-based vehicular networks, which are considered a key component of
   Intelligent Transportation Systems (ITS).  The main topics of
   vehicular networking are vehicle-to-vehicle (V2V), vehicle-to-
   infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking.
   First, this document surveys use cases using V2V and V2I networking.
   Second, this document deals with some critical aspects in vehicular
   networking, such as vehicular network architectures, standardization
   activities, IP address autoconfiguration, routing, mobility
   management, DNS naming service, service discovery, and security and
   privacy.  For each aspect, this document discusses problem statement
   to analyze the gap between the state-of-the-art techniques and
   requirements in IP-based vehicular networking.  Finally, this
   document articulates discussions including the summary and analysis
   of vehicular networking aspects and raises deployment issues.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-vehicular-networking-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 6 Mar 2018 23:17:50 +0900

Hi IPWAVE WG members,
I have posted the 02-version of the IPWAVE Vehicular Networking WG document:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02

The major changes from the 01-version are based on the comments
in the last IETF-100 IPWAVE WG meeting as follows:

o  In Section 1, the following sentence is added: The Federal
   Communications Commission (FCC) in the US allocated wireless
   channels for Dedicated Short-Range Communications (DSRC) [DSRC],
   service in the Intelligent Transportation Systems (ITS Radio
   Service in the 5.850 - 5.925 GHz band (5.9 GHz band).

o  In Section 2, the definition of Road-Side Unit (RSU) is modified
   as a node that has physical communication devices (e.g., DSRC,
   Visible Light Communication, 802.15.4, etc.) for wireless
   communication with vehicles and is also connected to the Internet
   as a router or switch for packet forwarding.

o  In Section 2, DMM is defined as the acronym for "Distributed
   Mobility Management" [DMM].

o  In Section 3.1, the following sentence is clarified along with
   relevant references: The current RAN is mainly constructed by 4G-
   LTE for the communication between a vehicle and an infrastructure
   node (i.e., V2I) [FirstNet-Annual-Report-2017], but DSRC-based
   vehicular networks can be used for V2I in near future [DSRC].

o  In Section 4.1.1, the following sentences are clarified along with
   relevant references: The standard WAVE [WAVE-1609.0][WAVE-1609.3]
   does not support Duplicate Address Detection (DAD) of IPv6
   Stateless Address Autoconfiguration (SLAAC) [RFC4862] by having
   its own efficient IP address configuration mechanism based on a
   WAVE Service Advertisement (WSA) management frame [WAVE-1609.3].
   It does not support both seamless communications for Internet
   services and multi-hop communications between a vehicle and an
   infrastructure node (e.g., RSU), either.

Before this IETF-101 meeting, could you take a look at this revision and
give our authors your comments on it?

This document will be a good cornerstone for our WG's rechartering in this
IETF meeting.

Thanks.

Best Regards,
Paul

On Tue, Mar 6, 2018 at 3:20 AM, <[email-masked]> wrote:

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

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 9 Mar 2018 00:00:00 +0900

Hi Richard,
First of all, thanks for your constructive comments on our revision.

I will revise our document according to your comments.
I put my answer inline below.

On Wed, Mar 7, 2018 at 7:55 AM, Dick Roy <[email-masked]> wrote:

> Comments inline below …
>
>
> ------------------------------
>
> *From:* its [mailto:[email-masked]] *On Behalf Of *Mr. Jaehoon Paul
> Jeong
> *Sent:* Tuesday, March 6, 2018 6:18 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; Mr. Jaehoon Paul Jeong
> *Subject:* Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-ne
> tworking-02.txt
>
>
>
> Hi IPWAVE WG members,
>
>    Communications Commission (FCC) in the US allocated frequency for
> Dedicated Short-Range Communications (DSRC) [DSRC],
>

     => I replace "allocated frequency for" with " allocated a frequency
range for ".

> *[RR] RSUs should not be required to e connected to the “Internet” nor to
> “act as routers”.  There will be RSUs (already are) in places where there
> is NO access to other networks!*
>
>
     => Even though the current RSU has no Internet connectivity, the RSU
may have Internet connectivity in near future.
          Thus,  I revise the definition of RSU as below:

         In Section 2, the definition of Road-Side Unit (RSU) is modified

         communication with vehicles and may have the connectivity to the
Internet

         as a router or switch for packet forwarding in the Internet.

> *[RR] I have NO idea why you are discussing ANYTHING related to LTE in
> this document!  They have NO CLUE about OCB operations, and that is ALL
> this document should be about!  I’d remove any and all such references to
> LTE of any flavor!*
>

       => Since this document deals with the survey of IP-based vehicular
networking,
            we authors believe that LTE can be a tentative communication
technology
            before the DSRC will be deployed popularly.

> *[RR] This paragraph is wrong on many counts and should be completely
> rewritten.  The WAVE standards say NOTHING about IPv6 support other than
> it’s optional, and if you implement it, you shall implement IPv6.
> EVERYTHING IPv6 does is fair game! The WSA optionally can transmit a local
> IPv6 prefix, which can be used for SLAAC as I understand it.  The WAVE
> standards absolutely “support” seamless comms for Internet (IPv6) services,
> exactly as ANY other Wi-Fi device does … very well if you are stationary
> and connected, and increasing poorly as you “move faster”!  You can not
> multi-hop between just two nodes!  Assuming you meant the equivalent of
> mesh networks in IEEE 802.11, it’s true mesh can be supported in OCB
> because the those writing the .11p standard required ToDS and FromDS to be
> 0 which means the 4-address format can not be used. That said, FNTP, the
> ISO equivalent of WAVE, DOES have n-hop forwarding as an extension of
> null-networking!  Use FNTP instead and you’ll have it!  *
>
>
>
     => I suggest the following paragraphs to reflect your comments:
  ------------------------------------------------------------
------------------------------------------------------------
-----------------------------------------------
The standard WAVE [WAVE-1609.0][WAVE-1609.3] defines a WAVE Service
Advertisement (WSA) frame
to support IPv6 [RFC4862]. WAVE devices send WSA frames via WAVE Short
Message Protocol (WSMP)
to announce IPv6 services. The WAVE Routing Advertisement (WRA) in a WSA
frame announces several
IP service-related information (e.g., Router Lifetime, IP Prefix, Prefix
Length, and DNS Server Addresses).

Each WAVE device supports link-local, global, and multicast IPv6 addresses
[RFC4291]. WAVE devices can
support dynamic IP addressing by calculating global IPv6 addresses via
Stateless Address Autoconfiguration
(SLAAC)[RFC4862] with their MAC address and the announced IP prefix.
However, since the MAC address
of a WAVE device may be altered for its pseudonym for privacy at any time,
this MAC address change may let
Duplicate Address Detection (DAD) fail or it brings a significant burden to
WAVE devices.

Another issue is that some IP services (e.g., Internet access and route
management services) shall be provided
across the entire WAVE networks. DAD guarantees the uniqueness of the IP
address of a WAVE device in
its current local link, but when the WAVE device moves to another local
link or an area using a different SCH
with the same WRA, the uniqueness of the IP address can be broken, so the
seamless communication for
those IP services can also be interrupted.

Finally, the IP packet relay can enable multi-hop communications among WAVE
devices instead of just one-hop
connections, which may enhance the connectivity of WAVE devices into RSUs.
Fast Networking & Transport Layer
Protocol (FNTP)[FNTP:ISO29281-1] defining a multi-hop communication method
for non-IP networking can be
used as an alternative for multi-hop communications, but it is a non-IP
service, so it may not be able provide
IP-based seamless services to users.
  ------------------------------------------------------------
------------------------------------------------------------
-----------------------------------------------

Thanks.

Best Regards,
Paul

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 8 Mar 2018 18:09:50 +0100

Le 08/03/2018 à 16:00, Mr. Jaehoon Paul Jeong a écrit :
[...]

> The WSA optionally can transmit a local IPv6 prefix, which can be
> used for SLAAC as I understand it.

Well I dont think any computer uses WSA, instead of an RA, to configure 
an address with the SLAAC protocol.  It would be straight layer 
violation if the IP stack interpreted a non-IP message (the WSA).

Or maybe we should not call it 'SLAAC' but something else.

Alex

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 9 Mar 2018 23:42:48 +0900

Hi Alex,
Thanks for your point.
For the IPv6 address autoconfiguration based on WSA, we may call it
WSA-based Stateless Address Autoconfiguration (WSLAAC).

Sandra (as the 1st author of the VIP-WAVE paper for the above text) and
others,
Is there any other better name?
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02#section-4.1.1

Best Regards,
Paul

On Fri, Mar 9, 2018 at 2:09 AM, Alexandre Petrescu <
[email-masked]> wrote:

> Well I dont think any computer uses WSA, instead of an RA, to configure an
> address with the SLAAC protocol.  It would be straight layer violation if
> the IP stack interpreted a non-IP message (the WSA).
>

---

From: Sandra Céspedes U. <[email-masked]>
Date: Wed, 14 Mar 2018 15:19:16 -0300

Hi Alex

On 08-03-2018 14:09, Alexandre Petrescu wrote:
> Well I dont think any computer uses WSA, instead of an RA, to 
> configure an address with the SLAAC protocol.  It would be straight 
> layer violation if the IP stack interpreted a non-IP message (the WSA).

As strange as it sounds, that is what the IEEE 1609.3 standard mandates. 
In section 6.4 - IPv6 configuration, subsection 6.4.1 it says: "For WAVE 
devices supporting dynamic IP addressing, the WME shall calculate the 
global IPv6 address via a stateless configuration procedure. This is the 
procedure described in IETF RFC 4862, except the WAVE device uses its 
MAC address in conjunction with the IP Prefix received in the 
WaveRoutingAdvertisement, rather than that received in an IETF RFC 4861 
Router Advertisement message. WAVE provides this IP configuration 
information in the WSA to reduce the need for neighbor and router 
discovery with their associated overhead and latency."

In that sense, we (at IETF) are trying to be careful not to mandate 
things related to "below IP" layers, but in this standard of IEEE they 
have specified a behavior for IP devices that do not follow RFC 4862 for 
IP addressing configuration.  The question then is, if in this group we 
specify something different (perhaps WAVE devices following what 
standard RFCs already mandate for IPv6 support) how do we avoid the 
conflict between the two standards?

> Or maybe we should not call it 'SLAAC' but something else.
The 1609.3 does say it is SLAAC as defined by RFC 4862 but with 
"exceptions" in the type of messages employed for prefix advertisement.
> Alex

Regards,

-- 

Sandra L. Céspedes, Ph.D. | Profesora Asistente
Departamento de Ingeniería Eléctrica
Universidad de Chile
Av. Tupper 2007, Santiago, Chile. 8370451
Tel. +56 (2) 29784093 | Of. 504
URL:http://www.cec.uchile.cl/~scespedes <http://www.cec.uchile.cl/%7Escespedes>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Sandra Céspedes U. <[email-masked]>
Date: Wed, 14 Mar 2018 15:24:37 -0300

Hi Paul

> WSA-based Stateless Address Autoconfiguration (WSLAAC).
I guess we can give it that name to differentiate it from the standard 
procedure using RAs as per RFC 4862. How is this going to co-exists in a 
WAVE device that has to process both WSA with IP prefix advertisement 
and RAs remains an open question.

Regards,
Sandra.

> Sandra (as the 1st author of the VIP-WAVE paper for the above text) 
> and others,
> On Fri, Mar 9, 2018 at 2:09 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>
>
>     configure an address with the SLAAC protocol.  It would be
>     straight layer violation if the IP stack interpreted a non-IP
>     message (the WSA).
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
>
>
>
>
> -- 
> Email: [email-masked] <mailto:[email-masked]>, 
> [email-masked] <mailto:[email-masked]>

-- 

---

---

From: Tony Li <[email-masked]>
Date: Wed, 14 Mar 2018 11:28:11 -0700

> On Mar 14, 2018, at 11:19 AM, Sandra Céspedes U. <[email-masked]> wrote:
> 
> 
> As strange as it sounds, that is what the IEEE 1609.3 standard mandates. In section 6.4 - IPv6 configuration, subsection 6.4.1 it says: "For WAVE devices supporting dynamic IP addressing, the WME shall calculate the global IPv6 address via a stateless configuration procedure. This is the procedure described in IETF RFC 4862, except the WAVE device uses its MAC address in conjunction with the IP Prefix received in the WaveRoutingAdvertisement, rather than that received in an IETF RFC 4861 Router Advertisement message. WAVE provides this IP configuration information in the WSA to reduce the need for neighbor and router discovery with their associated overhead and latency."
> 
> In that sense, we (at IETF) are trying to be careful not to mandate things related to "below IP" layers, but in this standard of IEEE they have specified a behavior for IP devices that do not follow RFC 4862 for IP addressing configuration.  The question then is, if in this group we specify something different (perhaps WAVE devices following what standard RFCs already mandate for IPv6 support) how do we avoid the conflict between the two standards?

Previously the way we avoided these conflicts was quite simple: the IEEE spec’ed the link layer, the IETF spec’ed the network layer. And there was no crossover.

This represents a violation of that modus operandi, which is seriously troubling.

I think we (ipwave) should reconsider and either explicitly endorse what 1609.3 is doing or reverse it.

Tony

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 14 Mar 2018 12:00:02 -0700

in line

On Wed, 2018-03-14 at 11:28 -0700, Tony Li wrote:
> > As strange as it sounds, that is what the IEEE 1609.3 standard
> > mandates. In section 6.4 - IPv6 configuration, subsection 6.4.1 it
> > says: "For WAVE devices supporting dynamic IP addressing, the WME
> > shall calculate the global IPv6 address via a stateless
> > configuration procedure. This is the procedure described in IETF
> > RFC 4862, except the WAVE device uses its MAC address in
> > conjunction with the IP Prefix received in the
> > WaveRoutingAdvertisement, rather than that received in an IETF RFC
> > 4861 Router Advertisement message. WAVE provides this IP
> > configuration information in the WSA to reduce the need for
> > neighbor and router discovery with their associated overhead and
> > latency."
> > 
> > things related to "below IP" layers, but in this standard of IEEE
> > they have specified a behavior for IP devices that do not follow
> > RFC 4862 for IP addressing configuration.  The question then is, if
> > in this group we specify something different (perhaps WAVE devices
> > following what standard RFCs already mandate for IPv6 support) how
> > do we avoid the conflict between the two standards?
> 
> Previously the way we avoided these conflicts was quite simple: the
> IEEE spec’ed the link layer, the IETF spec’ed the network layer. And
> there was no crossover.
> 
Tony, almost.  Since the early 1990s, this handshake division of labor
did (and does) exist, but it was between IETF and IEEE 802.  Not IEEE
in general.  

> This represents a violation of that modus operandi, which is

Yep.

---

From: Jerome Haerri <[email-masked]>
Date: Wed, 14 Mar 2018 20:54:09 +0100

Dear All,

I do not think it is a violation of operandi. What happens is there is one non-IP L3 stack which assists another IP L3  stack to get configured..it is just that this time, an IP configuration has been done outside the context of the IETF. Although it should have been linked to IETF (maybe), there  were good reasons to do this in that way (similar issues with IP configuration on C-V2X in ad-hoc mode are also appearing)...

Another remark: although the name of the group is called IPWAVE, it is not WAVE and there are other stacks that WAVE. So mentioning to endorse or not endorse WAVE does not solve our coexistence issues..in EU, we have Geonet.

In this group there was one question that was asked and answered more than a year ago: would IPWAVE use WAVE or Geonet for IPv6 over OCB. The answer was ‘no’. 
But it was soecified that it must not violate ‘any’ existing WAVE or Geonet functions and must not create ‘any’ harmful interference with their transmissions on the 5.9Ghz.

So, would the answer be ‘yes’ there would be no business to be done in IPWAVE or at least not in the current IDs being discussed, as there are no functional issues in using IPv6 with WAVE or GEONET..maybe some performance reduction. 

We need stakeholders and OEMs in the loop to provide system descriptions they have/produce/sell that could not use either Geonet or WAVE (and why), or be inefficient with them. We need that :-)

See you next week,

BR,

Jérôme

Maybe we should re-ask this question next week, 

Envoyé de  mon iPhone
lve
> Le 14 mars 2018 à 20:00, Rex Buddenberg <[email-masked]> a écrit :
> 
> in line
>