Subject: [its] Fwd: I-D Action: draft-petrescu-its-problem-01.txt

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Oct 2015 17:48:29 +0200

Hello ITSers,

We have published a new version of the ITS Problem Statement draft see 
below.

Comments welcome.

Alex

-------- Message transféré --------
Sujet : I-D Action: draft-petrescu-its-problem-01.txt
Date : Tue, 20 Oct 2015 01:08:19 -0700
De : [email-masked]
Répondre à : [email-masked]
Pour : [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

         Title           : Problem Statement for IP in ITS use cases 
C-ACC and Platooning
         Authors         : Alexandre Petrescu
                           Dapeng Liu
                           Charles E. Perkins
	Filename        : draft-petrescu-its-problem-01.txt
	Pages           : 8
	Date            : 2015-10-19

Abstract:
    Two vehicle-to-vehicle communications use cases are discussed, namely
    Cooperative Adaptive Cruise Control (C-ACC) and Platooning.  For
    these two use cases, the problems are identified that pertain to
    development with Internet protocols and connectivity.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-petrescu-its-problem/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-petrescu-its-problem-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-petrescu-its-problem-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Oct 2015 14:31:23 +0100

Dick - thanks for the comments.

Le 24/10/2015 10:45, Richard Roy a écrit :
>
> Alex,
>
> The draft is definitely improving day by day.  Nice work.
>
> Some comments:
>
> 1) In section 3.1, what you call the link layer is really the
> physical layer.  The data link (sub)layer is above the MAC
> (sub)layer and below the network layer.

I can understand that from an ISO standpoint.  But I guess if I say
"data link sublayer" in an IETF WG it's not going to be understood.

There is comfort in saying "link layer" to mean anything below IP: a MAC 
address, a channel number, a SSID name are all parts of such a link 
layer.  And "physical layer" never used because the networking layer 
never sees it.

I may be wrong though.  We can discuss layer terminology if you wish.

> 2) Vehicles in proximity will get info about neighboring vehicles
> (including the MAC address of the 5.9GHz interface in their mobile
> routers) using CAMs and BSMs on 5.9GHz and these will NOT be sent
> using IPv6 in the network layer.  Generally, they will be sent with
> NO network layer addressing (cf. WSMP/NNTP/FNTP)

It is a valuable point of view.

A network layer IPv6 packet sent by a vehicle is typically surrounded by
a few 802.11 OCB (aka 11p): an 802.11 Data Header and an LLC Header.
These headers do contain the MAC addresses needed in discovery.

The network layer sometimes issues IP packets which carry some
information of the link layer (e.g. a Target Source Link Layer Address
of an ICMPv6 message).

But there is more to it.  Some standards such as Korea's TTA V2V, 
China's LTE-V or LTE-D2D more generally, picture IPv6 side by side with 
WSMP, not above it, nor below it.  This makes think IPv6 packets may be 
used for V2V purpose.

Second, "IPv6" has a huge set of facets.  It should be considered at its 
right facet, rather than opposing it for what may appear as a religious 
reason.

IPv6 - it is not just a future protocol to which everyone should migrate 
away from IPv4.  That's just a facet.

IPv6 - it is not just IPv6 packets, not just Mobile IPv6.  It is a huge 
set of other IPv6 protocols and applications which already run and that 
are easy to develop.

IPv6 - it is not packets without link-layer headers.  Almost each IPv6 
packet has a link-layer header.

IPv6 - it is not packets without transport and app headers.  IPv6 
packets without transport or app headers are in extremely limited use: 
they are for network control and similar.  Some consider app-header-less 
IP packets as worthless.

IPv6 - it is not incompatible with other protocols: in can encapsulate 
and be encapsulated at multiple layers and in multiple levels.

IPv6 - it is not _one_ "application": it supports an enormous set of 
multiple applications be they fast or slow. They're all scalable: 
connect to any single other IP-enabled app from close or to far through 
the Internet.

IPv6 - it is not something heavy to communicate: it is as fast as the 
link-layer on which it runs.  One can't say "IPv6 is slower than WSMP" 
for example.

IPv6 - it is not something one can prohibit to run on a particular 
frequency.  This prohibition may sound as funny as IP-over-avian-carriers.

So I would like to ask you: do you think link-layer discovery can not
happen with these IP headers accompanied by 802.11 headers?

> 3) The idea behind platooning and C-ACC is / could be to use another
> 5.9GHz service channel (not the safety channel) to exchange messages
> and there, IPv6 could be used if there were a need.

Thanks for this indication.

Do you have a pointer to this?  I would like to add it in our
C-ACC-at-SDO draft.

I am asking because I did some research.

The only place I could find telling that IPv6 is prohibited on some
particular channel is ieeep1609.4-D9-2010.  It may be outdated.

The other standards similar to IEEE P1609, e.g. ETSI G5 documents, never
prohibit explicitely "IPv6" on particular channels.

Yes, these documents do specify some kind of application to relate to
some kind of particular channel.  But that does not mean that IPv6 can
not be used to implement that application on that channel.

> Remember, unless there is a need for unicast sessions between
> members of the platoon or C-ACC group, broadcasts using a well-known
> port and with no network layer addressing would work.

YEs I remember that.  And it may work but it may not be scalable.

The unicast sessions that are needed are for example the unicast video
streams.

> 4) " Within each vehicle there is at least one subnet, but there are
>  potentially several distinct IP subnets in each vehicle." No, not
> always. There are companies that implement 5.9 radios in a module
> that includes the antenna, and the only ethernet around might be an
> adapter for test purposes. Internally, there is no subnet; it's a
> host attached to a radio in a proprietary manner.

Yes.

And one such module is added in a car which already has several IP
subnets in the vehicle.  This module can be dedicated to a particular
V2V task.  It can be disconnected from the other embedded subnets.

But at the same time, manufacturers complain about too many such modules
(one for LTE, one for 11p V2V, one for radar 60GHz, one for DAB, one
for... and so on), and about too many cables in the car.

So, in other prototype vehicles one can find one main box in charge of
all connectivity and all other boxes connected to the main box.

> 5) " The problem is how best to establish low-latency IP
> communication paths between the computer on the networks embedded in
> two or more neighboring and potentially fast-moving vehicles."

> While they may be moving fast, there are in the same platoon and
> going the same direction so the relative velocity is what matters,
> and it's approximately zero!  You can consider a platoon or a C-ACC
> group as a quasi-static set of communication nodes. Cars come and
> cars go, but not 10 times a second!

That is right, and evenso the statement still holds.

We can add a clarification as you suggest.

Alex

>
> Cheers,
>
> RR
>
>> -----Original Message----- From: Alexandre Petrescu
>> [mailto:[email-masked]] Sent: Friday, October 23,
>> 2015 8:48 AM To: [email-masked] Subject: [its] Fwd: I-D Action:
>> draft-petrescu-its-problem-01.txt
>>
>> Hello ITSers,
>>
>> We have published a new version of the ITS Problem Statement draft
>> see below.
>>
>> Comments welcome.
>>
>> Alex
>>
>>
>> -------- Message transféré -------- Sujet : I-D Action:
>> draft-petrescu-its-problem-01.txt Date : Tue, 20 Oct 2015 01:08:19
>> -0700 De : [email-masked] Répondre à :
>> [email-masked] Pour : [email-masked]
>>
>>
>> Title           : Problem Statement for IP in ITS use cases C-ACC
>> and Platooning Authors         : Alexandre Petrescu Dapeng Liu
>> Charles E. Perkins Filename        :
>> draft-petrescu-its-problem-01.txt Pages           : 8 Date :
>> 2015-10-19
>>
>> Abstract: Two vehicle-to-vehicle communications use cases are
>> discussed, namely Cooperative Adaptive Cruise Control (C-ACC) and
>> Platooning.  For these two use cases, the problems are identified
>> that pertain to development with Internet protocols and
>> connectivity.
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>>
>> _______________________________________________ I-D-Announce
>> mailing list [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
>> directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>
>>
>
>
>