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

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

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


On Thu, Feb 18, 2016 at 6:24 AM, Richard Roy <[e-mail]> wrote:

> 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:[e-mail]]
> > Sent: Wednesday, February 17, 2016 4:22 AM
> > To: Mr. Jaehoon Paul Jeong
> > Cc: [e-mail]
> > Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I
> > Networking
> >
> > 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>