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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 17 February 2016 12:21 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674DC1B3697 for <its@ietfa.amsl.com>; Wed, 17 Feb 2016 04:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.983
X-Spam-Level:
X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Elh0ACQ7mj8X for <its@ietfa.amsl.com>; Wed, 17 Feb 2016 04:21:50 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479AC1ACE02 for <its@ietf.org>; Wed, 17 Feb 2016 04:21:50 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u1HCLlbe020322; Wed, 17 Feb 2016 13:21:47 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7A8B42077C3; Wed, 17 Feb 2016 13:30:14 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6D6CF20342F; Wed, 17 Feb 2016 13:30:14 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u1HCLlce024827; Wed, 17 Feb 2016 13:21:47 +0100
To: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
References: <CAPK2Dex2h5RjgTP8s6eDcH9PtjeoLMKAbmpEA3wu_1fZStm24g@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <56C465DB.8060305@gmail.com>
Date: Wed, 17 Feb 2016 13:21:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAPK2Dex2h5RjgTP8s6eDcH9PtjeoLMKAbmpEA3wu_1fZStm24g@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/its/mC6looSTI7eFcgnczboEDts7BtE>
Cc: "its@ietf.org" <its@ietf.org>
Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I Networking
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ITS at IETF discussion list <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Feb 2016 12:21:53 -0000

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

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: jaehoon.paul@gmail.com
> <mailto:jaehoon.paul@gmail.com>, pauljeong@skku.edu
> <mailto:pauljeong@skku.edu> Personal Homepage:
> http://iotlab.skku.edu/people-jaehoon-jeong.php
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>
>
> _______________________________________________ its mailing list
> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>