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

[Jérôme Härri <[e-mail]>]

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:[e-mail]] On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Wednesday 24 February 2016 12:58
To: [e-mail]
Cc: Dr. Hans-Joachim Fischer; Alexandre Petrescu; Thierry Ernst; [e-mail]; [e-mail]
Subject: Re: [its] Comments for a New Draft of Problem Statement for V2I Networking

 

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],  <mailto:[e-mail]> [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>