Subject: [its] Request for Comments for a New Draft of Problem Statement for V2I Networking

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 15 Feb 2016 11:30:30 -0500

Hi ITS Colleagues,

Title: Problem Statement for Vehicle-to-Infrastructure Networking
I-D: draft-jeong-its-v2i-problem-statement-00
Link: https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-00

Abstract
   This document specifies the problem statement for IPv6-based vehicle-
   to-infrastructure networking.  Dedicated Short-Range Communications
   (DSRC) is standardized as IEEE 802.11p for the wireless media access
   in vehicular networks.  This document addresses the extension of IPv6
   as the network layer protocol in vehicular networks and is focused on
   the networking issues in one-hop communication between a Road-Side
   Unit (RSU) and vehicle.  The RSU is connected to the Internet and
   allows vehicles to have the Internet access if connected.  The major
   issues of including IPv6 in vehicular networks are neighbor discovery
   protocol, stateless address autoconfiguration, and DNS configuration
   for the Internet connectivity over DSRC.  Also, when the vehicle and
   the RSU have an internal network, respectively, the document
   discusses the issues of internetworking between the vehicle's
   internal network and the RSU's internal network.

If you have comments or questions, please let me know.

Thanks.

Best Regards,
Paul
-- 
===========================
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: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Feb 2016 13:21:47 +0100

Hello Paul,

Thanks a lot for this draft.  This V2I problem statement covers many
things we have discussed in Yokohama.

What do the others think about this draft?

I hame some comments, see below.

Le 15/02/2016 17:30, Mr. Jaehoon Paul Jeong a écrit :
> I-D: draft-jeong-its-v2i-problem-statement-00 Link:
> https://tools.ietf.org/html/draft-jeong-its-v2i-problem-statement-00
>
> Abstract This document specifies the problem statement for
> IPv6-based vehicle- to-infrastructure networking.  Dedicated
> Short-Range Communications (DSRC) is standardized as IEEE 802.11p for
> the wireless media access in vehicular networks.  This document
> addresses the extension of IPv6 as the network layer protocol in
> vehicular networks and is focused on the networking issues in
> one-hop communication between a Road-Side Unit (RSU) and vehicle.
> The RSU is connected to the Internet and allows vehicles to have the
> Internet access if connected.  The major issues of including IPv6 in
> vehicular networks are neighbor discovery protocol, stateless
> address autoconfiguration, and DNS configuration for the Internet
> connectivity over DSRC.  Also, when the vehicle and the RSU have an
> internal network, respectively, the document discusses the issues of
> internetworking between the vehicle's internal network and the RSU's
> internal network.
>

You can use the documentation prefixes 2001:db8:1000::/63 (instead of
real addresses like 2001:1000::/63).

The term "RSU infra-node network" is something new and may need to be
present in the definitions section.

If I understand you correctly, the RSU infra-node network is a network
of IP-addressable devices which are present in the Road-Side Unit - right?

I am asking because I know some such RSUs on the market which contain
several IP-addressable devices linked together, but we dont have a name
for them.  The "RSU infra-node network" sounds good, I think.

For the term "mobile network" - we can rather use maybe
"moving network".

In section 5 "Internetworking between the Vehicle and RSU networks":
> Problems are a prefix discovery and prefix exchange.  The prefix
> discovery is defined as how routers in a mobile network discover
> prefixes in the mobile network.  The prefix exchange is defined as
> how the vehicle and the RSU exchange their prefixes with each other.

I agree with the problem of prefix exchange.

For the "prefix discovery", I have some doubts.

First, the routers inside the moving network can be pre-configured with
the prefixes inside that moving network.  If so, then there can be no
need for these routers to discover the prefixes inside the same moving
network.  But, of course, if they are not preconfigured then they have
to be discovered somehow.

Second, there is a need for one router (the mobile router?) in the
moving network to discover several parameters of a nearby moving
network, and also the parameters of a "RSU infra-node network".  These
parameters, including the IP prefix of the other network, are listed in
draft-petrescu-its-problem-01 section 3.1 "Discovery Sub-Problem".  It
would be good to use same terminology for this discovery.

> This section discusses IP addressing for V2I networking.  There are
> two policies for IPv6 addressing in vehicular networks.  The one
> policy is to use site-local IPv6 addresses for vehicular networks
> [RFC4291].

Since the site-local IPv6 addresses (fec0::) have been deprecated, it 
would be appropriate to mention "Unique Local Addresses" (ULAs) which 
can somehow play the role that seems to be needed here.  I suggest to 
substitute ULA for site-local addresses.

> The former approach is
>    usually used by Mobile Ad Hoc Networks (MANET) for a separate multi-
>    link subnet.

MANET has a certain meaning at IETF: it's the WG MANET.  I dont think 
there is any MANET draft that recommends ULAs (but maybe they recommend 
site-locals?).  Maybe ask the MANET WG what is the MANET IP Addressing 
Architecture (do they use ULAs?  do they use GUA - globals?).  If yes 
then refer to MANET WG document here.

 > Sections 7 ND, 8 address autoconf, 9 DNS

I agree with these sections 7, 8 and 9.

> 10.  IP Mobility Support
>
>    This section discusses an IP mobility support in V2I networking.  In
>    a single subnet per RSU, vehicles keep crossing the communication
>    coverages of adjacent RSUs.  During this crossing, TCP/UDP sessions
>    can be maintained through IP mobility support, such as Mobile IPv6
>    [RFC6275].  Since vehicles move fast along roadways, this high speed
>    should be configured for a parameter configuration in Mobile IPv6.
>
>    To support the mobility of a vehicle's mobile network, Network
>    Mobility (NEMO) protocol can be used [RFC3963].  Like Mobile IPv6,
>    the high speed of vehicles should be considered for a parameter
>    configuration in NEMO.

I agree.

I would like to add the following:

1. When Mobile IPv6/NEMO is used by the Mobile Router connected to
    the RSU infra-node a tunnel is established between the MR and its
    Home Agent in the TCC (Traffic Control Center).  If a node inside
    the moving network (not the MR) needs to exchange data with a node
    within the RSU infra-node network then that communication must
    go through the Home Agent.  The delays on the path to the HA may be
    too high for the reactivity needed between a vehicle and an RSU, or
    the path can even be blocked.  For this reason it is necessary to
    accommodate direct communications (skip the HA) between a node in
    the moving network and a node in the RSU infra-node network.  This
    can be achieved only if the two networks learn each other's prefixes.

2. A new method of connecting the moving network directly to the RSU
    infra-node network may lead to modifying the addressing architecture
    in the moving network.  This can become a problem to the use of
    Mobile IP, because Mobile IP relies on the addressing architecture
    controlled by the Home Agent.  This problem should be solved as well.

In section 11 Security Considerations:
> 11.  Security Considerations
>
>    The security is very important in vehicular networks for V2I
>    networking.  Only valid vehicles should be allowed to use V2I
>    networking in vehicular networks.  VIN and a user certificate can be
>    used to authenticate a vehicle and the user.
>
>    This document shares all the security issues of the neighbor
>    discovery protocol.  This document can get benefits from secure
>    neighbor discovery (SEND) [RFC3971]

Recent works in security for vehicular networks mention two additional 
things that are worth considering:

1. the use of TLS certificates for vehicle communications
    draft-lonc-tls-certieee1609-01

2. privacy considerations: a new ETSI activity may consider privacy
    aspects of identifier generation in vehicular communications.

It is worth referring to these aspects (give references).

Yours,

Alex

>
> Thanks.
>
> Best Regards, Paul -- =========================== Mr. Jaehoon (Paul)
> Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan
> University Office: +82-31-299-4957 Email: [email-masked]
> <mailto:[email-masked]>, [email-masked]
> <mailto:[email-masked]> Personal Homepage:
> http://iotlab.skku.edu/people-jaehoon-jeong.php
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Feb 2016 10:57:14 +0100

FYI - this mail seems to have not been distributed to the subscribers.

-------- Message transféré --------
Sujet : RE: [its] Comments for a New Draft of Problem Statement for V2I 
Networking
Date : Wed, 17 Feb 2016 13:24:26 -0800
De : Richard Roy <[email-masked]>
Répondre à : [email-masked]
Organisation : SRA
Pour : 'Alexandre Petrescu' <[email-masked]>, 'Mr. Jaehoon 
Paul Jeong' <[email-masked]>
Copie à : [email-masked], 'Dr. Hans-Joachim Fischer' 
<[email-masked]>, 'Thierry Ernst' <[email-masked]>, 
[email-masked]

Alex/Paul,

I suspect much of what you are thinking needs standardization below has
already been standardized.  You might want to check out ISO 21217 (ITS
station/communication architecture), followed by ISO 21210 (IPv6 networking
for ITS).  If nothing else, we already have terms for all of the
configurations you describe below (see ISO 21217).  It would be best to
stick with this now well-known terminology.

By the way, none of this depends on 802.11 5.9GHz in the data link and
physical layers.  I continue to wonder why 802.11p ever comes up.  It could
just as well be 5.4GHz BRAN, 2.4GHz ISM, IR, tin can and a string, or
whatever ...

Cheers,

RR

> -----Original Message-----
> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Wednesday, February 17, 2016 4:22 AM
> To: Mr. Jaehoon Paul Jeong
> Cc: [email-masked]
> Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I
> Networking
>
> Hello Paul,
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 24 Feb 2016 20:51:57 +0900

Hi Alex,
Thanks for your valuable comments.

I will address your comments on 01 version.

Thanks.

Best Regards,
Paul

On Wed, Feb 17, 2016 at 9:21 PM, Alexandre Petrescu <
[email-masked]> wrote:

> would be appropriate to mention "Unique Local Addresses" (ULAs) which can
> somehow play the role that seems to be needed here.  I suggest to
> Architecture (do they use ULAs?  do they use GUA - globals?).  If yes then
> refer to MANET WG document here.
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 24 Feb 2016 20:57:46 +0900

Hi Richard,
I will check the IOS standards related to ITS, which are pointed by you.

I agree with you that you need to use well-known terminology for our ITS
work.

For 802.11p, as I know, both industry and academia are considering it as
Dedicated Short-Range Communications (DSRC) for vehicular networking.

Thanks.

Best Regards,
Paul

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 24 Feb 2016 13:37:51 +0100

Hi Paul,

I follow what Dick mentioned…the strength of IP is to be above the underlying technology, so specifying a IPv6 draft specifically for a technology might be restrictive. 

What counts is the link specification (unicast, broadcast, multi-cast),  and its properties (delay, short link duration, fast link establishment…), whatever is the technology that will fulfill this(I like the string and tin can though J )…

And as a matter of fact, if you move away from the very protected ‘safety-related’ band, where BSM/CAM are transmitted (which does not seem to be your target), you reach the BRAN spectrum, and here, it is the new technology Wild West…a lot of technologies will be there for connected vehicles and ITS…DSRC probably, but also WiFi ac (and ax) as well as LTE-D LAA will surely be using these bands to connect vehicles to infrastructure and to each other….

Cheers,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Wednesday 24 February 2016 12:58
To: [email-masked]
Cc: Dr. Hans-Joachim Fischer; Alexandre Petrescu; Thierry Ernst; [email-masked]; [email-masked]
Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I Networking

Hi Richard,

I agree with you that you need to use well-known terminology for our ITS work.

Thanks.

Best Regards,

Paul

Alex/Paul,

Cheers,

RR

 

-- 

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