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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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 <
[e-mail]> wrote:

> 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: [phone] Email: [e-mail]
>> <mailto:[e-mail]>, [e-mail]
>> <mailto:[e-mail]> Personal Homepage:
>> http://iotlab.skku.edu/people-jaehoon-jeong.php
>> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>>
>>
>> _______________________________________________ its mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/its
>>
>>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>