Subject: [its] charter ITS

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Apr 2016 18:45:25 -0300

ITSers,

Please see below the current charter.

- the two Problem Statements drafts V2V and V2I joined, so there is less 
text in charter.
- added an Item on "List of Research papers..."

Erik: did I understand you correctly that there should be some item on 
discussing whether link-local addressing is sufficient, whether prefix 
exchange is necessary?

Dino: should LISP be included in the gap analysis draft which includes 
C-ACC use-case?  OR should we separate a dedicated I-D only with gap 
analysis including ND, MIP, AODVv2, LISP?

Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle 
interface illustrated good enough by the words "moving network to nearby 
moving network communications"?  Or is it better to say "the 1-IP-hop 
between nearby moving networks must be self-configured"?

Nabil, Sandra: is it ok to have a working group item "List of Research 
Papers for IP in V2V and V2I communications"?

Other comments?

Alex

------------------------------------------------------------------

              ITS (name to change)
                    Charter
              April 6th, 2016
          http://ietf.org/mailman/listinfo/its

Intelligent Transportation Systems (its)
----------------------------------------
Current Status: WG forming

Chairs:
    TBD

Assigned Area Director:
    TBD

Mailing list
    Address: [email-masked]
    To Subscribe: https://www.ietf.org/mailman/listinfo/its
    Archive:
    http://www.ietf.org/mail-archive/web/its/current/maillist.html

Additional web page
    TBD

Charter:

Goal
----
The goal of this group is to standardize IP-based protocols for
establishing direct and secure connectivity between moving networks,
some of which could be fixed permanently or temporarily.

Moving Network to Nearby Moving Network Communications
------------------------------------------------------
The group is concerned with all situations involving moving network to
nearby moving network communications.  For example: vehicle-to-vehicle
communications, nomadic user wearing a PAN and communicating to a
homenet, vehicle-to-infrastructure communications, wagon-to-wagon in a
train, or train-to-intersection signalling.

Example from the automobile communications space
------------------------------------------------
Automobiles and vehicles of all types are increasingly connected to
the Internet, either as vehicle-to-vehicle, vehicle-to-infra or
vehicle-to-Internet.  Entertainment apps enhancing comfort, reliable
data exchanges for road safety, and automated driving are features
coming in automobiles to hit the roads from now to year 2020.
Highlighting increased safety as an immediate result of
hyper-connectivity applied to vehicles, public authorities worldwide
are increasingly mandating secure communication technology
requirements in vehicles.

Emergency apps for new instrumented ambulances carry many benefits
both to the users and to society in general.

Why IP?
-------
Today, there are several deployed Vehicle-to-Internet technologies,
including car tethering through driver's cellular smartphone.
However, Vehicle-to-Vehicle and Vehicle-to-Infrastructure
communications are still being developed.  To improve on a situation
of link-specific data exchanges, and enable independent application
sets to share the same links, IP data exchanges are needed. Enabling
IP communication between vehicles (V2V), and between vehicles and the
immediate infrastructure (V2I), will provide (0) ability to reach the
rest of the world on the Internet (1) short and deterministic delays,
(2) fast forwarding through scalable paths of routers, (3) ease of
reuse of existing Internet applications in a vehicular environment.

Moving network to nearby moving network communications involve link
layers such as: 802.11p OCB (Outside the Context of a Basic Service
Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible Light
Communications), IrDA, LTE-D.  Only the IP protocols are capable of
running on each of these links and establish IP paths across them in
an interoperable manner.

Scenarios?
----------
There are a few scenarios exhibiting the need to communicate from one
moving network to another nearby moving network.

In the automobile space, the Cooperative Adaptive Cruise Control and
Platooning features consider that vehicles close to each other
exchange data describing their kinematic status.  At the cross-roads,
the moving network inside a vehicle exchanges data with the moving
network in the red-light pole.

Several public safety scenarios involve moving networks.  Distinct
organizations deploy different moving networks (in-vehicle, on-person)
at an incident scene.  These networks need to interoperate in order to
more effectively understand and deal with the incident scene.

In connected rail scenarios the moving network deployed in trains
communicate with other moving networks at the cross-points.

What kind of solutions?
-----------------------
The current technical solutions considered to achieve moving network
to nearby moving network communications are of two kinds: IP routing
protocols for n-hop path management and 1-hop link-scoped IP protocol
enhancements.  The 1-hop link-scoped protocols include the protocols
for route establishment involving ICMP Router Advertisements.  The
n-hop path management protocols include n-hop path establishment
protocols (e.g. Babel, OSPF) and n-hop path search protocols (most
notably AODV and derivates).

In this proposed Working Group the focus is on 1-hop protocols, and
leverage from other Working Groups for the n-hop situations.

In some of the moving network applications the window of opportunity
for exchanging data with the immediate infrastructure may be very
short.  For example, a car driving near a road-side unit may have only
5s to exchange with that RSU (depending on speed, RSU range and
number). (ephemeral connections).

What kind of requirements?
--------------------------
The requirements for mechanisms for moving network to nearby moving
network communications are focusing on low delays of the data paths,
reduced number of messages for path establishment, application
friendly, resilience to attacks, compatibility with DHCP and Mobile
IP.

In addition, some moving network to nearby moving network applications
involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving network to nearby moving netowrk mechanisms will need
to gracefully support IP multicast.

Due to the inherent characteristics of safety-related communications,
all new moving network to nearby moving network mechanisms must afford
authenticity and confidentiality where necessary.  Dynamically
establishing ephemeral communication paths between automobiles in
public areas must offer privacy safeguards for the end users
(passengers).

Establishing 1-hop IP V2V paths must not break the existing on-board
protocols and applications which communicate with the Internet,
possibly via multiple radios.

In a moving network deployed in an automobile, typically one exit
point connects the moving network to other moving networks. However,
in a more general manner (and to support reliability) any new
mechanism of moving network to nearby moving network communications
should support multi-homing: one router to use multiple interfaces
towards outside the moving network, or multiple routers.

Current version of Internet protocols
-------------------------------------
The group will only work on IPv6 solutions.

What SDOs may need this work?
-----------------------------
The requirements and standards for moving network to nearby moving
network communications, often involving IPv6, and novel V2V and
V2Infra concepts, are developed mainly at ISO TC204 "Intelligent
Transport Systems", 3GPP, ETSI, NHTSA and IEEE.  For
Vehicle-to-Internet communications, 3GPP LTE and other cellular
technologies represent the long-range connectivity method; for
Vehicle-to-Vehicle communications, LTE Direct is currently specified,
as well as OCB mode of IEEE 802.11.  Several use-cases exhibit a need
for IPv6 data exchanges between vehicles: ETSI's Cooperative Adaptive
Cruise Control and Platooning.  The IEEE developed a popular link for
short-range communications - IEEE 802.11p "WAVE".  The NHTSA wrote a
set of requirements for V2V communications.

Work Items
----------
- use-cases for moving network to nearby moving network communications
- Problem Statement for moving network to nearby moving network 
communications
   including V2V, V2I and DNS.
- Security and Privacy Requirements for moving network to
   nearby moving network communications
- Solutions, which might include new protocols or extensions to
   existing protocols.  With MIB.
- IPv6-over foo, where foo is pertinent for moving network to nearby
   moving network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
- List of Research Papers in the V2V domain, identifying which uses IP.

Timeline
--------
-

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Apr 2016 15:57:37 -0700

> On Apr 6, 2016, at 2:45 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> ITSers,
> 
> - the two Problem Statements drafts V2V and V2I joined, so there is less text in charter.
> Erik: did I understand you correctly that there should be some item on discussing whether link-local addressing is sufficient, whether prefix exchange is necessary?
> 
> Dino: should LISP be included in the gap analysis draft which includes C-ACC use-case?  OR should we separate a dedicated I-D only with gap analysis including ND, MIP, AODVv2, LISP?

LISP is an architecture that can be used for IP (EID) mobility. So I would say yes.

Dino

> 
> Person from mediatek: is the 'zeroconf' need in the vehicle-to-vehicle interface illustrated good enough by the words "moving network to nearby moving network communications"?  Or is it better to say "the 1-IP-hop between nearby moving networks must be self-configured"?
> 
> Nabil, Sandra: is it ok to have a working group item "List of Research Papers for IP in V2V and V2I communications"?
> 
> Other comments?
> 
> Alex
> 
> - Problem Statement for moving network to nearby moving network communications
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 7 Apr 2016 01:11:01 +0200

Dear ITSers,  Dear Alex,

Here are some comments on the updated charter:

1)      Can we keep a reference to IEEE 802.11p, considering it does not exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of course. 

2)      Should we really keep C-ACC (or Platooning) in the charter explicitly as use case, considering it is a seriously controversial aspect with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry mentions traffic efficiency/infotainment applications, such as in-signage applications...

a.       We might have to aim at less controversial use cases to attract automotive industries

3)      One potential WI I could think of (rather a basic one): definition of a vehicular wireless ‘link’ in an automotive context

a.       To me, this is  a fundamental brick in the larger IETF WG ITS house..

4)      I would suggest to be more explicit in the foreseen challenges of this WG, instead of mentioning general use case (which end up be controversial)

a.       Example: maintaining IPv6 connectivity in fast and asymmetric wireless links; also under quickly changing topologies (actually suggested by Dick Roy on the chat room)

b.      Example: IPv6 addressing in link-local scope..

c.       Example: guaranteeing privacy in IPv6 moving networks etc..

5)      Before listing academic papers referring to IPv6 in vehicles, I would suggest to first try to list commercial products/solutions that are in vehicles and are using IPv6, possibly suffering from a silo limitations (ex. restricted to a single technology, single use case…)

a.       I think we need to get to products first, before academic visions

My two cents..

Best Regards,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday 06 April 2016 23:45
To: [email-masked]
Subject: [its] charter ITS

ITSers,

Other comments?

Alex

             ITS (name to change)
                   Charter
             April 6th, 2016

Chairs:
   TBD

Assigned Area Director:
   TBD

Mailing list
   Address: [email-masked]

Additional web page
   TBD

Charter:

Goal
----

Why IP?
-------

Scenarios?
----------

What kind of solutions?
-----------------------

Work Items
----------

Timeline
--------
-

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Apr 2016 20:11:33 -0300

> LISP is an architecture that can be used for IP (EID) mobility. So I would say yes.

'Yes' means that you would prefer one I-D which is dedicated to gap 
analysis? (and that includes considerations of IP (EID)?

This gap analysis draft would not describe C-ACC/Platooning use-case. 
It would just do gap analysis.

Alex

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Apr 2016 16:21:49 -0700

> 'Yes' means that you would prefer one I-D which is dedicated to gap analysis? (and that includes considerations of IP (EID)?

We know how to do the v2i piece with LISP. Yes, with one static EID per vehicle. We have some production deployments that use the same solution in the data center and other sectors.

> This gap analysis draft would not describe C-ACC/Platooning use-case. It would just do gap analysis.

For the v2v case, LISP isn’t appropriate because it would need to depend on infrastructure and that signalling would kill the responsive the v2v needs for motion critical actions.

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Apr 2016 20:44:19 -0300

Le 06/04/2016 20:21, Dino Farinacci a écrit :
> We know how to do the v2i piece with LISP. Yes, with one static EID
> per vehicle. We have some production deployments that use the same
> solution in the data center and other sectors.

Any new solution designed in this group must not alter what you know to 
do v2i with LISP.  For example, if there is prefix exchange between 
vehicle and an RSU that must not break LISP from doing v2i (vehicle to 
Internet) through that same RSU.  There is a similar problem in Mobile IP.

If so, then this should be described so in the gap analysis or in a 
requirements draft.  Which one would you prefer?

(RSU: Road Side Unit: a set of computers linked by Ethernet and situated 
in a box along the road, to control traffic lights and other embedded 
sensors, and also do 802.11p to the vehicle; an RSU is connected to the 
Internet by either ADSL or its own cellular link).

> For the v2v case, LISP isn’t appropriate because it would need to
> depend on infrastructure and that signalling would kill the
> responsive the v2v needs for motion critical actions.

That sounds like text to be put in a gap analysis draft.

So I think what I propose is to have a separate gap analysis draft, and 
a separate requirements draft.

Is this ok with you?

Alex

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 6 Apr 2016 20:54:10 -0300

Hi Alex,

Yes, I agree that listing the research papers related to V2I and V2V is a
working item.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

http://nabilbenamar.ipv6-lab.net/

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Apr 2016 19:05:51 -0700

> Any new solution designed in this group must not alter what you know to do v2i with LISP.  For example, if there is prefix exchange between vehicle and an RSU that must not break LISP from doing v2i (vehicle to Internet) through that same RSU.  There is a similar problem in Mobile IP.

LISP doens’t have a prefix exchange. The vehicle would be assigned a static IPv6 EID address. There won’t be any broad changes to the LISP protocol to support this because we support such use-cases already. 

That is, an EID can move around when another device is the RLOC. So the RSU is the RLOC and encap/decaps packets to and from the EID (the car) that roams. The EIDs that come in range of the RSU are registered dynamically to the mapping system.

We do this for LISP-MN when LISP runs in a smartphone. And we do this when VM roams from one type-of-rack switch to another in the data center. In the former case, the EID and RLOC in are in the same node. In the latter case, the EID and RLOC are in separate nodes.

So we (the LISP WG) can present the solution and the ITS group can decide what the gaps are.

> If so, then this should be described so in the gap analysis or in a requirements draft.  Which one would you prefer?
> 
> (RSU: Road Side Unit: a set of computers linked by Ethernet and situated in a box along the road, to control traffic lights and other embedded sensors, and also do 802.11p to the vehicle; an RSU is connected to the Internet by either ADSL or its own cellular link).

And as I mentioned in the BOF. We solved this with planes. Where the EIDs were end-systems on the plane that had session continuity requirements. When the planes flew over routers on the ground, the routers were the RLOCs for the EIDs on the plane. Very much like cars driving by RSUs.

If you think it would be useful, we could even demonstrate this for the ITS group.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 7 Apr 2016 06:58:18 -0700

> I get the feeling that people are thinking ITS needs from the IETF a global
> IP solution to ALL it services and applications.  Let me assure you nothing

Richard, I think it how much control each individual auto-maker will want. If security and control of the multitude of computer systems is important and if they feel a proprietary way is the only way to achieve it, then the market will decide that.

I think the big question and what remains to be seen is if the auto-makers will want to interoperate with each other and at what layer of a communication stack.

But as I mentiond at the mic, if a car wants to talk to the Internet, they have to use IP based protocols. There should be no argument there. As for mobility, if RF cells are enmourous, then IP addresses in the cars don’t need to change. We find this with our smartphones today. If RF cells are small or supported by different service providers with different addressing, then we need IP mobility.

This is why provider-assigned (PA) addresses have so many disadvantages when you want to address something independent on how they are connected. You know, those cars are going to be connected via their smartphone hotspots too. So we can be assured that multi-home to the car across service providers is going to happen.

And the next question is, is there a session continuity requirement across these connections.

> could be further from the truth.  The discussions today's on use cases were
> interesting, however when it focused on V2V safety apps, they were somewhat
> off track.  We, the ITS community, are not looking for IPv6 solutions to all

Yes, I believe I agree.

> our issues and challenges, just those for which IP is well-suited.  ITS
> communications is in the 21rst century (the ITS station!) and flexibility is
> the key!  IP will be used when appropriate, and not, when not.

Right, if IP is going to make the solution more complex, or is simply not needed, or gets in the way, it should NOT be used.

Dino

> 
> Cheers,
> 
> RR
> 
>> -----Original Message-----
>> From: Dino Farinacci [mailto:[email-masked]]
>> Sent: Wednesday, April 06, 2016 4:22 PM
>> To: Alexandre Petrescu
>> Cc: [email-masked]
>> Subject: Re: [its] charter ITS
>> 
>> We know how to do the v2i piece with LISP. Yes, with one static EID per
>> vehicle. We have some production deployments that use the same solution in
>> the data center and other sectors.
>> 
>> For the v2v case, LISP isn't appropriate because it would need to depend
>> on infrastructure and that signalling would kill the responsive the v2v
>> needs for motion critical actions.
>> 
>> Dino
>> 
> 
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 8 Apr 2016 01:13:49 -0300

Hi ITSers,
For a proposed charter item of "List of Research Papers in the V2V domain,
identifying which uses IP",
I agree that this item should be included into our ITS charter.

Nabil Benamar, Sandra Céspedes, and I agreed on the drafting for this item
into an I-D.

Thanks.

--
Paul
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: José Santa Lozano <[email-masked]>
Date: Fri, 8 Apr 2016 11:22:02 +0200

Dear all,

From my group we could also contribute, in general, with information about papers in the area using IP(v6) in both V2V and V2I.

Regards,

-- 
José Santa Lozano
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
30100 Murcia, Spain
Telf: +34-868-888771 / +34-868-884455
Fax: +34-868-884151
Web: http://ants.inf.um.es/~josesanta <http://ants.inf.um.es/~josesanta>

> El 8 abr 2016, a las 6:13, Mr. Jaehoon Paul Jeong <[email-masked]> escribió:
> 
> Hi ITSers,
> For a proposed charter item of "List of Research Papers in the V2V domain, identifying which uses IP", 
> Nabil Benamar, Sandra Céspedes, and I agreed on the drafting for this item into an I-D.
> 
> Thanks.
> 
> --
> Paul
> Email: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
> 
> On Wed, Apr 6, 2016 at 6:45 PM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
> ITSers,
> 
>          http://ietf.org/mailman/listinfo/its <http://ietf.org/mailman/listinfo/its>
> 
> 
>    Address: [email-masked] <mailto:[email-masked]>
>    To Subscribe: https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
>    Archive:
>    http://www.ietf.org/mail-archive/web/its/current/maillist.html <http://www.ietf.org/mail-archive/web/its/current/maillist.html>
> 
> Additional web page
>    TBD
> 
> Charter:
> 
> Goal
> ----
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
> 
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 8 Apr 2016 09:59:06 -0300

Hi José,

Sure, you are welcome to the contribution for a list of papers for IP-based
V2V and V2I.

Thanks.

--

Paul

2016. 4. 8. 오전 6:22에 "José Santa Lozano" <[email-masked]>님이 작성:

> Dear all,
>
> From my group we could also contribute, in general, with information about
> papers in the area using IP(v6) in both V2V and V2I.
>
> Regards,
>
> --
> José Santa Lozano
> Web: http://ants.inf.um.es/~josesanta
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Apr 2016 10:54:56 -0300

Le 06/04/2016 23:05, Dino Farinacci a écrit :
>> Any new solution designed in this group must not alter what you
>> know to do v2i with LISP.  For example, if there is prefix exchange
>> between vehicle and an RSU that must not break LISP from doing v2i
>> (vehicle to Internet) through that same RSU.  There is a similar
>> problem in Mobile IP.
>
> LISP doens’t have a prefix exchange. The vehicle would be assigned a
> static IPv6 EID address. There won’t be any broad changes to the LISP
> protocol to support this because we support such use-cases already.

It is good that LISP can work ok when prefix exchanges happen near it. 
This kind of text can easily make part of a gap analysis draft.

If a car uses LISP for its V2I, and car uses a prefix exchange to a 
nearby car, you may want that people in the Internet reach this latter 
car via former's car LISP V2I.  In that case, one may want LISP to 
accept a prefix coming from another car, into the LISP system, maybe tag 
it differently.

That would express that prefix exchanges can work fully independently of 
LISP.

> That is, an EID can move around when another device is the RLOC. So
> the RSU is the RLOC and encap/decaps packets to and from the EID (the
> car) that roams. The EIDs that come in range of the RSU are
> registered dynamically to the mapping system.
>
> We do this for LISP-MN when LISP runs in a smartphone. And we do this
> when VM roams from one type-of-rack switch to another in the data
> center. In the former case, the EID and RLOC in are in the same node.
> In the latter case, the EID and RLOC are in separate nodes.
>

Ok.

Now the question is also whether there is someone from the LISP 
community intent in contributing text to a WG item in ITS, called 'gap 
analysis'.

>> (RSU: Road Side Unit: a set of computers linked by Ethernet and
>> situated in a box along the road, to control traffic lights and
>> other embedded sensors, and also do 802.11p to the vehicle; an RSU
>> is connected to the Internet by either ADSL or its own cellular
>> link).
>
> And as I mentioned in the BOF. We solved this with planes. Where the
> EIDs were end-systems on the plane that had session continuity
> requirements. When the planes flew over routers on the ground, the
> routers were the RLOCs for the EIDs on the plane. Very much like cars
> driving by RSUs.
>

Thank you for the offer!  Demonstrators are always welcome.

But, we are not there yet.  Let's discuss charter now and in 1 month 
we'll see.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Apr 2016 11:05:50 -0300

Paul,

Thank you.

I will consider a WG item in the charter containing "List of Research 
Papers in the V2V domain, identifying which uses IP".

Please keep watching this list during the next month, as there will be 
some iterations of the charter text.

Alex

Le 08/04/2016 01:13, Mr. Jaehoon Paul Jeong a écrit :
> Email: [email-masked] <mailto:[email-masked]>,
> [email-masked] <mailto:[email-masked]>
> On Wed, Apr 6, 2016 at 6:45 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     ITSers,
>
>     Erik: did I understand you correctly that there should be some item
>     on discussing whether link-local addressing is sufficient, whether
>     prefix exchange is necessary?
>
>     Dino: should LISP be included in the gap analysis draft which
>     includes C-ACC use-case?  OR should we separate a dedicated I-D only
>     with gap analysis including ND, MIP, AODVv2, LISP?
>
>     Person from mediatek: is the 'zeroconf' need in the
>     vehicle-to-vehicle interface illustrated good enough by the words
>     "moving network to nearby moving network communications"?  Or is it
>     better to say "the 1-IP-hop between nearby moving networks must be
>     self-configured"?
>
>     Nabil, Sandra: is it ok to have a working group item "List of
>     Research Papers for IP in V2V and V2I communications"?
>
>     Other comments?
>
>     Alex
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 8 Apr 2016 07:06:53 -0700

CC’ing the LISP working group since you are soliciting help.

LISP WG folks, please comment. Thanks in advance.

> It is good that LISP can work ok when prefix exchanges happen near it. This kind of text can easily make part of a gap analysis draft.
> 
> If a car uses LISP for its V2I, and car uses a prefix exchange to a nearby car, you may want that people in the Internet reach this latter car via former's car LISP V2I.  In that case, one may want LISP to accept a prefix coming from another car, into the LISP system, maybe tag it differently.

There should be no prefix exchange. It takes too long to do signalling when you want to move application data. The car should have an EID that is preassigned (and based on the VIN number of the car - auto-makers have asked for this requirement).

When the car moves in signal range of an RSU, it uses it immmediately to send traffic. Return traffic needs to be encapsulated to the RSU, so the EID to RSU-RLOC binding needs to go to the mapping database as fast as possible.

We can take advantage of a liner physical path and do predictive RLOCs. So encapsulated traffic can go to the current RSU, or the one the car is about to approach, or both at the same time to minimize packet loss.

> That would express that prefix exchanges can work fully independently of LISP.

Or avoided all together because it will serve no purpose.

> Now the question is also whether there is someone from the LISP community intent in contributing text to a WG item in ITS, called 'gap analysis’.

We will get someone to do it.

> Thank you for the offer!  Demonstrators are always welcome.

We can show solutions and architectures for better understanding through demos.

> But, we are not there yet.  Let's discuss charter now and in 1 month we'll see.
> 
> Alex

Ack.

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Apr 2016 10:14:24 +0200

Jérôme,

Le 07/04/2016 01:11, Jérôme Härri a écrit :
> 1)Can we keep a reference to IEEE 802.11p, considering it does not
> exist anymore? It is now fully integrated into IEEE 802.11-2012 as
> OCB mode (and 10Mhz @5.9Ghz) of course.

The question is relevant.

Let's use "802.11-OCB" instead of "802.11p" everywhere.  Do you agree?

> 2)Should we really keep C-ACC (or Platooning) in the charter
> explicitly as use case, considering it is a seriously controversial
> aspect with some SDOs (ex. In Automotive SDOs)? In the ISO
> presentation, Thierry mentions traffic efficiency/infotainment
> applications, such as in-signage applications...

C-ACC and Platooning are use-cases exhibiting the need for V2V.  There
are more use-cases needing V2V: e.g. "V2V emergency vehicle warning",
"V2V emergency stop use cases" documented at 3GPP.  I dont think it's 
worth documenting all of them, because their salient V2V characteristics 
are all exhibited by only one.

For Thierry's note: I think you mean "In-Vehicle Signage (IVS)" case
study (slide 14 of "ISO TC204 needs" at
https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf )

If yes, that is a typical V2I use-case.  Maybe, "I2V" - Infrastructure
to Vehicle communications.  It follows the same moving network to nearby
moving or fixed network paradigm: more precisely expressed as:  fixed
network to nearby moving network communications.

> a.We might have to aim at less controversial use cases to attract
> automotive industries

Which one use-case would you think of?

Does it follow the paradigm of moving network to nearby moving or fixed
network communications?

> 3)One potential WI I could think of (rather a basic one): _definition
> of a vehicular wireless ‘link’ in an automotive context_
>
> a.To me, this is  a fundamental brick in the larger IETF WG ITS
> house..

I think that is right.

There seems to be interest in precisely defining what that 'link' is in
an automotive context.

This interest was illustrated by the IPv6 over 802.11-OCB discussion.

Such a link is used in V2V and V2I and I2V.

We should work on this, but within certain conditions: (1) we should not
create new link characteristics, but describe the existing ones, (2) we
should describe how the link layer is interfaced with the IP layer.

The title of such a WG item should be "IPv6 over foo".

That said, how do you see the work on a potential WI talking about the
definition of a vehicular wireless link in an automotive context?

>
> 4)I would suggest to be more explicit in the foreseen challenges of
> this WG, instead of mentioning general use case (which end up be
> controversial)
>
> a.Example: maintaining IPv6 connectivity in fast and asymmetric
> wireless links; also under quickly changing topologies (actually
> suggested by Dick Roy on the chat room)

Yes, that's a long-term challenge: maintaining IPv6 connectivity in fast
and asymmetric wireless links, and under quivkly changing topologies.

The near term objective is: moving network to nearby moving or fixed
network communications.

>
> b.Example: IPv6 addressing in link-local scope..

I agree.  Erik also said something about potential work on an addressing
architecture for the V2V topology.

Do you think there is enough interest in IPv6 addressing architecture
for the V2V topology such as to propose a WG item for it?

> c.Example: guaranteeing privacy in IPv6 moving networks etc..

I agree.  For this there is ongoing discussion with people inclined on
security work.

>
> 5)Before listing academic papers referring to IPv6 in vehicles, I
> would suggest to first try to list commercial products/solutions that
> are in vehicles and are using IPv6, possibly suffering from a silo
> limitations (ex. restricted to a single technology, single use
> case…)

Sounds relevant.  But too many separate items?

How about _one_ item with two sections: section with list of papers, and
section with list of commercial products.

> a.I think we need to get to products first, before academic visions

It's debatable.  How about answering first the above question, and then
we'll see.

Alex

>
> My two cents..
>
> Best Regards,
>
> Jérôme
>
> *From:*its [mailto:[email-masked]] *On Behalf Of *Alexandre
> Petrescu *Sent:* Wednesday 06 April 2016 23:45 *To:* [email-masked]
> *Subject:* [its] charter ITS
>
> ITSers,
>
> - the two Problem Statements drafts V2V and V2I joined, so there is
> less text in charter. - added an Item on "List of Research
> papers..."
>
> ITS (name to change) Charter April 6th, 2016
> ---------------------------------------- Current Status: WG forming
>
> Chairs: TBD
>
> Assigned Area Director: TBD
>
> Mailing list Address: [email-masked] <mailto:[email-masked]> To
> Subscribe: https://www.ietf.org/mailman/listinfo/its Archive:
> Additional web page TBD
> Goal ---- The goal of this group is to standardize IP-based protocols
> for establishing direct and secure connectivity between moving
> networks, some of which could be fixed permanently or temporarily.
>
> ------------------------------------------------------ The group is
> concerned with all situations involving moving network to nearby
> moving network communications.  For example: vehicle-to-vehicle
> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in
> a train, or train-to-intersection signalling.
>
> ------------------------------------------------ Automobiles and
> vehicles of all types are increasingly connected to the Internet,
> either as vehicle-to-vehicle, vehicle-to-infra or
> Why IP? ------- Today, there are several deployed Vehicle-to-Internet
> technologies, including car tethering through driver's cellular
> smartphone. However, Vehicle-to-Vehicle and
> Vehicle-to-Infrastructure communications are still being developed.
> To improve on a situation of link-specific data exchanges, and enable
> independent application sets to share the same links, IP data
> exchanges are needed.  Enabling IP communication between vehicles
> (V2V), and between vehicles and the immediate infrastructure (V2I),
> will provide (0) ability to reach the rest of the world on the
> Internet (1) short and deterministic delays, (2) fast forwarding
> through scalable paths of routers, (3) ease of reuse of existing
> Internet applications in a vehicular environment.
>
> Scenarios? ---------- There are a few scenarios exhibiting the need
> to communicate from one moving network to another nearby moving
> network.
>
> exchange data describing their kinematic status.  At the
> cross-roads, the moving network inside a vehicle exchanges data with
> the moving network in the red-light pole.
>
> organizations deploy different moving networks (in-vehicle,
> on-person) at an incident scene.  These networks need to interoperate
> in order to more effectively understand and deal with the incident
> scene.
>
> What kind of solutions? ----------------------- The current technical
> solutions considered to achieve moving network to nearby moving
> network communications are of two kinds: IP routing protocols for
> n-hop path management and 1-hop link-scoped IP protocol enhancements.
> The 1-hop link-scoped protocols include the protocols for route
> establishment involving ICMP Router Advertisements.  The n-hop path
> management protocols include n-hop path establishment protocols (e.g.
> Babel, OSPF) and n-hop path search protocols (most notably AODV and
> derivates).
>
> short.  For example, a car driving near a road-side unit may have
> only 5s to exchange with that RSU (depending on speed, RSU range and
> What kind of requirements? -------------------------- The
> requirements for mechanisms for moving network to nearby moving
> In addition, some moving network to nearby moving network
> applications involve IP multicast mechanisms (e.g. virtual siren);
> thus C-ACC the 1-hop IP moving network to nearby moving netowrk
> mechanisms will need to gracefully support IP multicast.
>
> Due to the inherent characteristics of safety-related
> communications, all new moving network to nearby moving network
> mechanisms must afford authenticity and confidentiality where
> necessary.  Dynamically establishing ephemeral communication paths
> between automobiles in public areas must offer privacy safeguards for
> the end users (passengers).
>
> point connects the moving network to other moving networks.
> However, in a more general manner (and to support reliability) any
> new mechanism of moving network to nearby moving network
> communications should support multi-homing: one router to use
> multiple interfaces towards outside the moving network, or multiple
> routers.
>
> ------------------------------------- The group will only work on
> IPv6 solutions.
>
> What SDOs may need this work? ----------------------------- The
> requirements and standards for moving network to nearby moving
> Vehicle-to-Vehicle communications, LTE Direct is currently
> specified, as well as OCB mode of IEEE 802.11.  Several use-cases
> exhibit a need for IPv6 data exchanges between vehicles: ETSI's
> Cooperative Adaptive Cruise Control and Platooning.  The IEEE
> developed a popular link for short-range communications - IEEE
> 802.11p "WAVE".  The NHTSA wrote a set of requirements for V2V
> communications.
>
> Work Items ---------- - use-cases for moving network to nearby moving
> network communications - Problem Statement for moving network to
> nearby moving network communications including V2V, V2I and DNS. -
> Security and Privacy Requirements for moving network to nearby moving
> network communications - Solutions, which might include new protocols
> or extensions to existing protocols.  With MIB. - IPv6-over foo,
> where foo is pertinent for moving network to nearby moving network
> communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad) - List of
> Research Papers in the V2V domain, identifying which uses IP.
>
> Timeline -------- -
>

---

From: "Dr. Karan Verma" <[email-masked]>
Date: Mon, 11 Apr 2016 14:17:49 +0530

Hello Everyone,

I also contribution for a list of papers for IP-based V2V and V2I, still
i'm writing final revive comments. I will as send as soon as possible.

Thank You

-- 
Best Regards

Dr. Karan Verma
Assistant Professor
Computer Science and Engineering Dept.
Central University Rajasthan, India
Website: www.drkaranverma.com
Phone: +917568169258

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 14 Apr 2016 10:22:19 +0900

Hi Jérôme,
I have an opinion on your comment 5) below.

I think that a list of high-quality papers about IP-based V2V and V2I
can teach very useful lessons to software designers of IP in V2V and V2I
in the industry.
Multiple people are working for this IP-based V2V and V2I
(including Sandra Cespedes and me) in academia and
more people(including Nabil Benamar) are willing to work for this area.

I think we need to utilize the list of such papers as the ground for our
ITS group
through a WI. Note that the draft of the list will include the summary of
the main
ideas of the papers.

For the industry current activities for this area, I believe that you can
share them
as references through our ITS mailing list rather than through a WI.

Could you join my team that are making efforts for a list of such papers?

Thanks.

Best Regards,
Paul

On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri <[email-masked]>
wrote:

> 1)      Can we keep a reference to IEEE 802.11p, considering it does not
> exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode
> (and 10Mhz @5.9Ghz) of course.
>
>
>
> 2)      Should we really keep C-ACC (or Platooning) in the charter
> explicitly as use case, considering it is a seriously controversial aspect
> with some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry
> mentions traffic efficiency/infotainment applications, such as in-signage
> applications...
>
> 3)      One potential WI I could think of (rather a basic one): *definition
> of a vehicular wireless ‘link’ in an automotive context*
>
> 4)      I would suggest to be more explicit in the foreseen challenges of
> a.       Example: maintaining IPv6 connectivity in fast and asymmetric
> wireless links; also under quickly changing topologies (actually suggested
> by Dick Roy on the chat room)
>
> 5)      Before listing academic papers referring to IPv6 in vehicles, I
> would suggest to first try to list commercial products/solutions that are
> in vehicles and are using IPv6, possibly suffering from a silo limitations
> (ex. restricted to a single technology, single use case…)
>
> *From:* its [mailto:[email-masked]] *On Behalf Of *Alexandre
> Petrescu
> *Sent:* Wednesday 06 April 2016 23:45
> *To:* [email-masked]

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 14 Apr 2016 09:09:39 +0200

Hi Paul,

Thanks for your feedback. Do not get me wrong, I am an academic and with my team, we also work on IP-based V2V and V2I, in particular related to mobility management with DMM, but also in the context of vehicular IoT. 

I just have the feeling that people are perfectly aware of the fact that IP can be used for V2V and V2I, but does not ‘need’ to be used as other solutions already perfectly fit their need. Listing papers will not change this awareness. 

So, as a complement to academic papers, it would help to be able to pin-point which industrial activities are using or are strongly planning (short term I mean) to use pure IPv6 system in vehicles. 

My feeling here is we have a different eco-system that the Automotive industry (and automotive industry-related SDO)..more likely the IoT industry…and as such, we should not need to have the (direct) involvement of automotive industry in the Charter. If we can make this clear by an industry-based ‘survey’, that would help make the case for the WG.

Btw, you can count on me your draft..we can add some IP-based V2V and V2I for mobility management and also IoT.

Cheers,

Jérôme

From: Mr. Jaehoon Paul Jeong [mailto:[email-masked]] 
Sent: Thursday 14 April 2016 03:22
To: Jérôme Härri
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [its] charter ITS

Hi Jérôme,

in the industry.

I think we need to utilize the list of such papers as the ground for our ITS group

through a WI. Note that the draft of the list will include the summary of the main 

ideas of the papers.

For the industry current activities for this area, I believe that you can share them

Thanks.

Best Regards,

Paul

On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri <[email-masked]> wrote:

Dear ITSers,  Dear Alex,

My two cents..

Best Regards,

Jérôme

ITSers,

Other comments?

Alex

             ITS (name to change)
                   Charter
             April 6th, 2016

Chairs:
   TBD

Assigned Area Director:
   TBD

Mailing list
   Address: [email-masked]

Additional web page
   TBD

Charter:

Goal
----

Why IP?
-------

Scenarios?
----------

What kind of solutions?
-----------------------

Work Items
----------

Timeline
--------
-

 

-- 

===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked],  <mailto:[email-masked]> [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 14 Apr 2016 16:36:21 +0900

Jérôme,
I missed that you are also an academic person.
I got it :-)

I understand your points for industry activity related to vehicular
networking.
Your observation seems true.

BTW, I will invite you to my team for the draft for a list of academic
papers for V2V and V2I
by a personal message.

Thanks.

Paul

On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri <[email-masked]>
wrote:

> Hi Paul,
>
>
>
> Thanks for your feedback. Do not get me wrong, I am an academic and with
> my team, we also work on IP-based V2V and V2I, in particular related to
> mobility management with DMM, but also in the context of vehicular IoT.
>
>
>
> I just have the feeling that people are perfectly aware of the fact that
> IP *can* be used for V2V and V2I, but does not ‘*need*’ to be used as
> other solutions already perfectly fit their need. Listing papers will not
> change this awareness.
>
>
>
> So, as a complement to academic papers, it would help to be able to
> pin-point which industrial activities are using or are strongly planning
> (short term I mean) to use pure IPv6 system in vehicles.
>
>
>
> My feeling here is we have a different eco-system that the Automotive
> industry (and automotive industry-related SDO)..more likely the IoT
> industry…and as such, we should not need to have the (direct) involvement
> of automotive industry in the Charter. If we can make this clear by an
> industry-based ‘survey’, that would help make the case for the WG.
>
> *From:* Mr. Jaehoon Paul Jeong [mailto:[email-masked]]
> *Sent:* Thursday 14 April 2016 03:22
> *To:* Jérôme Härri
> *Cc:* Alexandre Petrescu; [email-masked]
> *Subject:* Re: [its] charter ITS
>
>
>
> Hi Jérôme,
>

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 14 Apr 2016 09:42:57 +0200

Paul,

Thanks. Btw, when I mentioned ‘people’ are aware of IP V2V but not see the need (so far), I referred to the automotive SDOs (led by automotive industries)…, although there are always ‘minority reports’ J 

Cheers,

Jérôme

From: Mr. Jaehoon Paul Jeong [mailto:[email-masked]] 
Sent: Thursday 14 April 2016 09:36
To: Jérôme Härri
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [its] charter ITS

Jérôme,

I got it :-)

I understand your points for industry activity related to vehicular networking.

BTW, I will invite you to my team for the draft for a list of academic papers for V2V and V2I

by a personal message.

Thanks.

Paul

On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri <[email-masked]> wrote:

Hi Paul,

Cheers,

Jérôme

Hi Jérôme,

in the industry.

ideas of the papers.

Thanks.

Best Regards,

Paul

Dear ITSers,  Dear Alex,

My two cents..

Best Regards,

Jérôme

ITSers,

Other comments?

Alex

             ITS (name to change)
                   Charter
             April 6th, 2016

Chairs:
   TBD

Assigned Area Director:
   TBD

Mailing list
   Address: [email-masked]

Additional web page
   TBD

Charter:

Goal
----

Why IP?
-------

Scenarios?
----------

What kind of solutions?
-----------------------

Work Items
----------

Timeline
--------
-

 

-- 

 

--

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 14 Apr 2016 16:48:03 +0900

Jérôme,
Thanks for your clarification.

Paul

On Thu, Apr 14, 2016 at 4:42 PM, Jérôme Härri <[email-masked]>
wrote:

> Paul,
>
>
>
> Thanks. Btw, when I mentioned ‘people’ are aware of IP V2V but not see the
> need (so far), I referred to the automotive SDOs (led by automotive
> industries)…, although there are always ‘minority reports’ J
>
>
>
> Cheers,
>
>
>
> Jérôme
>
>
>
> *Sent:* Thursday 14 April 2016 09:36
>
> *To:* Jérôme Härri

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Apr 2016 10:06:18 +0200

Le 14/04/2016 09:42, Jérôme Härri a écrit :
> Paul,
>
> Thanks. Btw, when I mentioned ‘people’ are aware of IP V2V but not see
> the need (so far), I referred to the automotive SDOs (led by automotive

Jérôme,

Along the automotive SDO discussion.

Which other SDO is not sure about using IP for C-ACC but maybe for other 
use-cases.?

Alex

>
> Cheers,
>
> Jérôme
>
> *From:*Mr. Jaehoon Paul Jeong [mailto:[email-masked]]
> On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Hi Paul,
>
> IP _can_ be used for V2V and V2I, but does not ‘_need_’ to be used as
> other solutions already perfectly fit their need. Listing papers will
> not change this awareness.
>
> industry…and as such, we should not need to have the (direct)
> involvement of automotive industry in the Charter. If we can make this
> clear by an industry-based ‘survey’, that would help make the case for
> the WG.
>
> Btw, you can count on me your draft..we can add some IP-based V2V and
> V2I for mobility management and also IoT.
>
> Cheers,
>
> Jérôme
>
> *From:*Mr. Jaehoon Paul Jeong [mailto:[email-masked]
> <mailto:[email-masked]>]
> *Cc:* Alexandre Petrescu; [email-masked] <mailto:[email-masked]>
> On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Dear ITSers,  Dear Alex,
>
> 1)Can we keep a reference to IEEE 802.11p, considering it does not exist
> anymore? It is now fully integrated into IEEE 802.11-2012 as OCB mode
> 2)Should we really keep C-ACC (or Platooning) in the charter explicitly
> as use case, considering it is a seriously controversial aspect with
> some SDOs (ex. In Automotive SDOs)? In the ISO presentation, Thierry
> mentions traffic efficiency/infotainment applications, such as
> in-signage applications...
>
> 3)One potential WI I could think of (rather a basic one): _definition of
> a vehicular wireless ‘link’ in an automotive context_
>
> a.To me, this is  a fundamental brick in the larger IETF WG ITS house..
>
> 4)I would suggest to be more explicit in the foreseen challenges of this
> WG, instead of mentioning general use case (which end up be controversial)
>
> a.Example: maintaining IPv6 connectivity in fast and asymmetric wireless
> links; also under quickly changing topologies (actually suggested by
> Dick Roy on the chat room)
>
> 5)Before listing academic papers referring to IPv6 in vehicles, I would
> suggest to first try to list commercial products/solutions that are in
> vehicles and are using IPv6, possibly suffering from a silo limitations
> *From:*its [mailto:[email-masked] <mailto:[email-masked]>]
> *On Behalf Of *Alexandre Petrescu
> *To:* [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Apr 2016 10:42:19 +0200

ITSers,

We work on a more rigorous ITS charter text.

Now we propose four work items:

1. "Problem statement for IP in V2V and V2I"
    including "IP addressing architecture for V2V and V2I"
    and including "Gap Analysis: IP protocols suited and gaps"
    and including "Use-cases for IP in V2V and V2I moving network to
                   nearby moving or fixed network"

2. "Threat Analysis for IP prefix exchanges in V2V and V2I context"

3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document[*],
    including connectivity in fast and asymmetric conditions, coverage
    area vs speed diagrams, below-IP congestion management.

4. "List of papers and _products_ using IP in V2V and V2I"

What do you think?

Please respond by next Monday, April 18th.

Alex and Dapeng
[*] a typical IP-over-foo document is, for example, RFC2464
     "Transmission of IPv6 Packets over Ethernet Networks", where
     "foo" is instantiated as "Ethernet".  Other IPv6-over-foo documents
     are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more.

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 14 Apr 2016 11:34:50 +0200

Hi Alex,

So far, CAR 2 CAR and ETSI ITS, both mentioned that can do without. 

Best,

Jérôme

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Thursday 14 April 2016 10:06
To: Jérôme Härri; 'Mr. Jaehoon Paul Jeong'
Cc: [email-masked]
Subject: Re: [its] charter ITS

Le 14/04/2016 09:42, Jérôme Härri a écrit :
> the need (so far), I referred to the automotive SDOs (led by 
> automotive industries)…, although there are always ‘minority reports’ 
> J

Jérôme,

Which other SDO is not sure about using IP for C-ACC but maybe for other use-cases.?

Alex

> On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Hi Paul,
>
> Thanks for your feedback. Do not get me wrong, I am an academic and 
> with my team, we also work on IP-based V2V and V2I, in particular 
> related to mobility management with DMM, but also in the context of vehicular IoT.
>
> I just have the feeling that people are perfectly aware of the fact 
> that IP _can_ be used for V2V and V2I, but does not ‘_need_’ to be 
> used as other solutions already perfectly fit their need. Listing 
> papers will not change this awareness.
>
> pin-point which industrial activities are using or are strongly 
> planning (short term I mean) to use pure IPv6 system in vehicles.
>
> exist anymore? It is now fully integrated into IEEE 802.11-2012 as OCB 
> mode (and 10Mhz @5.9Ghz) of course.
>
> limitations (ex. restricted to a single technology, single use case…)
>
> less text in charter.
> interface illustrated good enough by the words "moving network to 
> nearby moving network communications"?  Or is it better to say "the 
> 1-IP-hop between nearby moving networks must be self-configured"?
>
> [email-masked] <mailto:[email-masked]> Personal Homepage: 
> http://iotlab.skku.edu/people-jaehoon-jeong.php
> [email-masked] <mailto:[email-masked]> Personal Homepage: 
> http://iotlab.skku.edu/people-jaehoon-jeong.php

---

From: "Huangjing (A)" <[email-masked]>
Date: Thu, 14 Apr 2016 09:46:42 +0000

Hi, Alex,

Comments below.

James

>Sent: Thursday, April 14, 2016 4:42 PM
>To: [email-masked]
>Subject: [its] charter ITS - proposed work items
>
>ITSers,
>

It may be useful to further distinguish which use cases are 1-hop connection and which are multi-hop connection.
My perception is, the discussion in the list and at the IETF meeting involved quite some issues that are multi-hop related, such as mobility, address allocation and management, routing algorithm, etc.
If this group only focus on 1-hop, we probably do not have to care about these issues; but if multi-hop scenarios have to be considered (maybe in the future), then we may have to think about them.
The papers and _products_ MIGHT be able to give us some hints on hop(s) related issues.

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Sun, 17 Apr 2016 21:07:40 +0900

Hi Alex

Just to clarify.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: [email-masked]
#webpage: https://sites.google.com/site/hurryon

> On Apr 14, 2016, at 5:42 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> ITSers,
> 
>                  nearby moving or fixed network”

Are you intending to have one document that includes those three parts?

> 
> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I context”

Is this mean that this group first go for this and later considers a general security document (e.g., security requirements for ITS) ?

Cheers.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Apr 2016 08:52:50 +0200

Hi Jong-Hyouk,

Le 17/04/2016 14:07, Jong-Hyouk Lee a écrit :
> Hi Alex
>
> Just to clarify. -- Jong-Hyouk Lee, living somewhere between
> /dev/null and /dev/random Protocol Engineering Lab., Sangmyung
> University
>
> #email: [email-masked] #webpage:
> https://sites.google.com/site/hurryon
>
>> 1. "Problem statement for IP in V2V and V2I" including "IP
>> addressing architecture for V2V and V2I" and including "Gap
>> Analysis: IP protocols suited and gaps" and including "Use-cases
>> for IP in V2V and V2I moving network to nearby moving or fixed
>> network”
>

Yes.

Because we need to reduce the number of items.  Because one of the
remarks during BoF was that the scope was too large.

> Is this mean that this group first go for this and later considers a
> general security document (e.g., security requirements for ITS) ?

For now it is "Threat Analysis for IP prefix exchanges in V2V and V2I 
context".

"General security requirements for ITS" seems very broad - what do you 
mean more precisely?

Alex

>> Alex and Dapeng [*] a typical IP-over-foo document is, for example,
>> RFC2464 "Transmission of IPv6 Packets over Ethernet Networks",
>> where "foo" is instantiated as "Ethernet".  Other IPv6-over-foo
>> documents are RFC4944 "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP"
>> and more.
>>
>>> Thanks. Btw, when I mentioned ‘people’ are aware of IP V2V but
>>> not see the need (so far), I referred to the automotive SDOs (led
>>> by automotive industries)…, although there are always ‘minority
>>> reports’ J
>>>
>>> Cheers,
>>>
>>> Jérôme
>>>
>>> *Sent:* Thursday 14 April 2016 09:36 *To:* Jérôme Härri *Cc:*
>>> Alexandre Petrescu; [email-masked] *Subject:* Re: [its] charter
>>> ITS
>>>
>>> Jérôme,
>>>
>>> Thanks for your feedback. Do not get me wrong, I am an academic
>>> and with my team, we also work on IP-based V2V and V2I, in
>>> particular related to mobility management with DMM, but also in
>>> the context of vehicular IoT.
>>>
>>> I just have the feeling that people are perfectly aware of the
>>> fact that IP _can_ be used for V2V and V2I, but does not ‘_need_’
>>> to be used as other solutions already perfectly fit their need.
>>> Listing papers will not change this awareness.
>>>
>>> So, as a complement to academic papers, it would help to be able
>>> to pin-point which industrial activities are using or are
>>> strongly planning (short term I mean) to use pure IPv6 system in
>>> vehicles.
>>>
>>> My feeling here is we have a different eco-system that the
>>> Automotive industry (and automotive industry-related SDO)..more
>>> likely the IoT industry…and as such, we should not need to have
>>> the (direct) involvement of automotive industry in the Charter.
>>> If we can make this clear by an industry-based ‘survey’, that
>>> would help make the case for the WG.
>>>
>>> Btw, you can count on me your draft..we can add some IP-based V2V
>>> and V2I for mobility management and also IoT.
>>>
>>> Cheers,
>>>
>>> Jérôme
>>>
>>> <mailto:[email-masked]>] *Sent:* Thursday 14 April 2016
>>> 03:22 *To:* Jérôme Härri *Cc:* Alexandre Petrescu; [email-masked]
>>> <mailto:[email-masked]> *Subject:* Re: [its] charter ITS
>>>
>>> Hi Jérôme,
>>>
>>> On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri
>>> 1)Can we keep a reference to IEEE 802.11p, considering it does
>>> not exist anymore? It is now fully integrated into IEEE
>>> 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of course.
>>>
>>> explicitly as use case, considering it is a seriously
>>> controversial aspect with some SDOs (ex. In Automotive SDOs)? In
>>> the ISO presentation, Thierry mentions traffic
>>> efficiency/infotainment applications, such as in-signage
>>> applications...
>>>
>>> a.We might have to aim at less controversial use cases to
>>> attract automotive industries
>>>
>>> 3)One potential WI I could think of (rather a basic one):
>>> _definition of a vehicular wireless ‘link’ in an automotive
>>> context_
>>>
>>> 4)I would suggest to be more explicit in the foreseen challenges
>>> of this WG, instead of mentioning general use case (which end up
>>> be controversial)
>>>
>>> would suggest to first try to list commercial products/solutions
>>> that are in vehicles and are using IPv6, possibly suffering from
>>> a silo limitations (ex. restricted to a single technology, single
>>> use case…)
>>>
>>> *From:*its [mailto:[email-masked]
>>> <mailto:[email-masked]>] *On Behalf Of *Alexandre Petrescu
>>> *Sent:* Wednesday 06 April 2016 23:45 *To:* [email-masked]
>>> <mailto:[email-masked]> *Subject:* [its] charter ITS
>>>
>>> ITSers,
>>>
>>> - the two Problem Statements drafts V2V and V2I joined, so there
>>> is less text in charter. - added an Item on "List of Research
>>> papers..."
>>>
>>> Erik: did I understand you correctly that there should be some
>>> item on discussing whether link-local addressing is sufficient,
>>> whether prefix exchange is necessary?
>>>
>>> includes C-ACC use-case?  OR should we separate a dedicated I-D
>>> only with gap analysis including ND, MIP, AODVv2, LISP?
>>>
>>> "moving network to nearby moving network communications"?  Or is
>>> it better to say "the 1-IP-hop between nearby moving networks
>>> must be self-configured"?
>>>
ITS (name to change)
>>> Charter April 6th, 2016 http://ietf.org/mailman/listinfo/its
>>>
>>>
>>> Goal ---- The goal of this group is to standardize IP-based
>>> protocols for establishing direct and secure connectivity between
>>> moving networks, some of which could be fixed permanently or
>>> temporarily.
>>>
>>> ------------------------------------------------------ The group
>>> is concerned with all situations involving moving network to
>>> nearby moving network communications.  For example:
>>> vehicle-to-vehicle communications, nomadic user wearing a PAN and
>>> communicating to a homenet, vehicle-to-infrastructure
>>> communications, wagon-to-wagon in a train, or
>>> train-to-intersection signalling.
>>>
>>> vehicle-to-Internet.  Entertainment apps enhancing comfort,
>>> reliable data exchanges for road safety, and automated driving
>>> are features coming in automobiles to hit the roads from now to
>>> year 2020. Highlighting increased safety as an immediate result
>>> of hyper-connectivity applied to vehicles, public authorities
>>> worldwide are increasingly mandating secure communication
>>> technology requirements in vehicles.
>>>
>>> Emergency apps for new instrumented ambulances carry many
>>> benefits both to the users and to society in general.
>>>
>>> Why IP? ------- Today, there are several deployed
>>> Vehicle-to-Internet technologies, including car tethering through
>>> driver's cellular smartphone. However, Vehicle-to-Vehicle and
>>> Vehicle-to-Infrastructure communications are still being
>>> developed.  To improve on a situation of link-specific data
>>> exchanges, and enable independent application sets to share the
>>> same links, IP data exchanges are needed.  Enabling IP
>>> communication between vehicles (V2V), and between vehicles and
>>> the immediate infrastructure (V2I), will provide (0) ability to
>>> reach the rest of the world on the Internet (1) short and
>>> deterministic delays, (2) fast forwarding through scalable paths
>>> of routers, (3) ease of reuse of existing Internet applications
>>> in a vehicular environment.
>>>
>>> Moving network to nearby moving network communications involve
>>> link layers such as: 802.11p OCB (Outside the Context of a Basic
>>> Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC (Visible
>>> Light Communications), IrDA, LTE-D.  Only the IP protocols are
>>> capable of running on each of these links and establish IP paths
>>> across them in an interoperable manner.
>>>
>>> Scenarios? ---------- There are a few scenarios exhibiting the
>>> need to communicate from one moving network to another nearby
>>> moving network.
>>>
>>> In the automobile space, the Cooperative Adaptive Cruise Control
>>> and Platooning features consider that vehicles close to each
>>> other exchange data describing their kinematic status.  At the
>>> cross-roads, the moving network inside a vehicle exchanges data
>>> with the moving network in the red-light pole.
>>>
>>> Several public safety scenarios involve moving networks.
>>> Distinct organizations deploy different moving networks
>>> (in-vehicle, on-person) at an incident scene.  These networks
>>> need to interoperate in order to more effectively understand and
>>> deal with the incident scene.
>>>
>>> In connected rail scenarios the moving network deployed in
>>> trains communicate with other moving networks at the
>>> cross-points.
>>>
>>> What kind of solutions? ----------------------- The current
>>> technical solutions considered to achieve moving network to
>>> nearby moving network communications are of two kinds: IP
>>> routing protocols for n-hop path management and 1-hop link-scoped
>>> IP protocol enhancements.  The 1-hop link-scoped protocols
>>> include the protocols for route establishment involving ICMP
>>> Router Advertisements.  The n-hop path management protocols
>>> include n-hop path establishment protocols (e.g. Babel, OSPF) and
>>> n-hop path search protocols (most notably AODV and derivates).
>>>
>>> In this proposed Working Group the focus is on 1-hop protocols,
>>> and leverage from other Working Groups for the n-hop situations.
>>>
>>> In some of the moving network applications the window of
>>> opportunity for exchanging data with the immediate infrastructure
>>> may be very short.  For example, a car driving near a road-side
>>> unit may have only 5s to exchange with that RSU (depending on
>>> speed, RSU range and number). (ephemeral connections).
>>>
>>> network communications are focusing on low delays of the data
>>> paths, reduced number of messages for path establishment,
>>> application friendly, resilience to attacks, compatibility with
>>> DHCP and Mobile IP.
>>>
>>> applications involve IP multicast mechanisms (e.g. virtual
>>> siren); thus C-ACC the 1-hop IP moving network to nearby moving
>>> netowrk mechanisms will need to gracefully support IP multicast.
>>>
>>> necessary.  Dynamically establishing ephemeral communication
>>> paths between automobiles in public areas must offer privacy
>>> safeguards for the end users (passengers).
>>>
>>> Establishing 1-hop IP V2V paths must not break the existing
>>> on-board protocols and applications which communicate with the
>>> Internet, possibly via multiple radios.
>>>
>>> In a moving network deployed in an automobile, typically one
>>> exit point connects the moving network to other moving networks.
>>> However, in a more general manner (and to support reliability)
>>> any new mechanism of moving network to nearby moving network
>>> multiple interfaces towards outside the moving network, or
>>> multiple routers.
>>>
>>> Work Items ---------- - use-cases for moving network to nearby
>>> moving network communications - Problem Statement for moving
>>> network to nearby moving network communications including V2V,
>>> V2I and DNS. - Security and Privacy Requirements for moving
>>> network to nearby moving network communications - Solutions,
>>> which might include new protocols or extensions to existing
>>> protocols.  With MIB. - IPv6-over foo, where foo is pertinent for
>>> moving network to nearby moving network communications (e.g.
>>> 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research Papers in
>>> the V2V domain, identifying which uses IP.
>>>
>>> Timeline -------- -
>>>
>>>
>>> _______________________________________________ its mailing list
>>> =========================== Mr. Jaehoon (Paul) Jeong, Ph.D.
>>> Assistant Professor Department of Software Sungkyunkwan
>>> University Office: +82-31-299-4957 Email: [email-masked]
>>> <mailto:[email-masked]>, [email-masked]
>>> <mailto:[email-masked]> Personal Homepage:
>>> =========================== Mr. Jaehoon (Paul) Jeong, Ph.D.
>>> Assistant Professor Department of Software Sungkyunkwan
>>> University Office: +82-31-299-4957 Email: [email-masked]
>>> <mailto:[email-masked]>, [email-masked]
>>> <mailto:[email-masked]> Personal Homepage:
>> _______________________________________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Mon, 18 Apr 2016 16:32:25 +0900

Thx, plz see inline.

> On Apr 18, 2016, at 3:52 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi Jong-Hyouk,
> 

Hum…then, the document will be too broad. We may need people to work on each part.

> For now it is "Threat Analysis for IP prefix exchanges in V2V and V2I context”.

Ok. For the document “Threat Analysis of IP prefix exchanges in V2V and V2I”, I just started to work on. Soon I will post. 

> 
> "General security requirements for ITS" seems very broad - what do you mean more precisely?

We may later need one document describing general security requirements for ITS that corresponds the document “PS for IP in V2V and V2I”. We will be later. ;)

Good day!

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Apr 2016 09:52:02 +0200

Le 18/04/2016 09:32, Jong-Hyouk Lee a écrit :
> #email: [email-masked] <mailto:[email-masked]>
>> On Apr 18, 2016, at 3:52 PM, Alexandre Petrescu
>>> #email: [email-masked] <mailto:[email-masked]> #webpage:

Yes.  There are already a few drafts for this item.  Their authors are 
interested and agreed on joining some of the efforts.

Are you interested in some part of this big document?

>> context”.
> Ok. For the document “Threat Analysis of IP prefix exchanges in V2V and
> V2I”, I just started to work on. Soon I will post.

I take it as agreement from you, and it will be in the proposed charter 
text.

> We may later need one document describing general security requirements
> for ITS that corresponds the document “PS for IP in V2V and V2I”. We
> will be later. ;)

Ok.

Alex

>>>>> Alexandre Petrescu; [email-masked] <mailto:[email-masked]> *Subject:*
>>>>> Re: [its] charter
>>>>> ITS
>>>>>
>>>>> Jérôme,
>>>>>
>>>>> <[email-masked] <mailto:[email-masked]>
>>>>> <mailto:[email-masked]>
>>>>> <[email-masked] <mailto:[email-masked]>
>>>>> <mailto:[email-masked]>
>>>>> Mailing list Address: [email-masked] <mailto:[email-masked]>
>>>>> <mailto:[email-masked]> To

---

From: Nabil Benamar <[email-masked]>
Date: Mon, 18 Apr 2016 08:54:50 +0100

Hi All,

I agree on the current charter since these are the points discussed during
the BoF! However there were some replies in this list mentioning to
probably add IoT as an exemple of IP based communications.  I think that we
should keep the focus on vehicular communications/networks and do not
diverge from this topic. IoT is fundamentally different from vehicular
networks in many aspects such as routing, energy consumption, mac layer,
etc...

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Mon, 18 Apr 2016 19:07:31 +0900

Hi Alex

Thx for your prompt message. Plz see inline.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

> On Apr 18, 2016, at 4:52 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> Yes.  There are already a few drafts for this item.  Their authors are interested and agreed on joining some of the efforts.

Which ones? Can you kindly give pointers?

> Are you interested in some part of this big document?

Sure, I am interested in this work. I suppose that the gap analysis part is a good start point for us and for me as well. I am waiting for your pointers to the exiting drafts relevant with this work item. If the existing drafts are not covering yet the gap analysis, then I’ll go for this.

> I take it as agreement from you, and it will be in the proposed charter text.

Yes, plz. I will soon post.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Apr 2016 13:23:37 +0200

Hi Jong-Hyouk,

Le 18/04/2016 12:07, Jong-Hyouk Lee a écrit :
> Hi Alex
>
> Thx for your prompt message. Plz see inline. -- Jong-Hyouk Lee,
> living somewhere between /dev/null and /dev/random Protocol
> Engineering Lab., Sangmyung University
>
>>> Thx, plz see inline. -- Jong-Hyouk Lee, living somewhere between
>>>> <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> Hi Jong-Hyouk,
>>>>
>>>>> /dev/null and /dev/random Protocol Engineering Lab.,
>>>>> Sangmyung University
>>>>>
>>>>>> addressing architecture for V2V and V2I" and including
>>>>>> "Gap Analysis: IP protocols suited and gaps" and including
>>>>>> "Use-cases for IP in V2V and V2I moving network to nearby
>>>>>> moving or fixed network”
>>>>>
>>>> Because we need to reduce the number of items.  Because one of
>>>> the remarks during BoF was that the scope was too large.
>>>
>> Yes.  There are already a few drafts for this item.  Their authors
>> are interested and agreed on joining some of the efforts.
>

There are two Problem Statements, one for V2V and one for V2I:
draft-petrescu-its-problem-01.txt
draft-jeong-its-v2i-problem-statement-00
Their authors agreed to join.

There is a section titled 'Gap Analysis' in:
draft-petrescu-its-cacc-sdo-04.txt
We could extract that section.

There is some useful text that can be used for 'use-cases for IP in V2V 
and V2I moving network to nearby moving or fixed network':
draft-liu-its-scenario-00
draft-petrescu-its-cacc-sdo-04.txt
I expect authors to agree.

If that is not enough, we can ask members of the ITS at IETF email list 
whether they can write use-case text for this latter part.

The use-case is any use-case that makes use of the following topology:

                Vehicle 1                             Vehicle 2
                                     e.g.
                               o)) LTE D2D, ((o
                               |   802.11p,   |
                               |     LiFi     |
                               |              |
          +------+          +--+--+        +--+--+     +----------+
          |GPS PC|          | eR1 |        | eR2 |     |Braking PC|
          +--+---+          +--+--+        +--+--+     +-----+----+
             |                 |              |              |
             |                 |              |              |
             |    Ethernet     |              |  Ethernet    |
            -+-----------------+-          ---+--------------+-----
              2001:db8:1::/40                      2001:db8:2::/40

> Sure, I am interested in this work. I suppose that the gap analysis
> part is a good start point for us and for me as well. I am waiting
> for your pointers to the exiting drafts relevant with this work item.
> If the existing drafts are not covering yet the gap analysis, then
> I’ll go for this.

Look at the gap analysis:
https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-04#section-14

Alex

>>>>> Is this mean that this group first go for this and later
>>>>> considers a general security document (e.g., security
>>>>> requirements for ITS) ?
>>>>
>>> Ok. For the document “Threat Analysis of IP prefix exchanges in
>>> V2V and V2I”, I just started to work on. Soon I will post.
>>
>>> We may later need one document describing general security
>>> requirements for ITS that corresponds the document “PS for IP in
>>> V2V and V2I”. We will be later. ;)
>>
>> Ok.
>>
>> Alex
>>
>>>
>>> Good day!
>>>
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> Cheers.
>>>>>
>>>>>>
>>>>>> 3. "IP over DSRC (802.11-OCB)" typical IP-over-foo
>>>>>> document[*], including connectivity in fast and asymmetric
>>>>>> conditions, coverage area vs speed diagrams, below-IP
>>>>>> congestion management.
>>>>>>
>>>>>> Alex and Dapeng [*] a typical IP-over-foo document is, for
>>>>>> example, RFC2464 "Transmission of IPv6 Packets over
>>>>>> Ethernet Networks", where "foo" is instantiated as
>>>>>> "Ethernet".  Other IPv6-over-foo documents are RFC4944
>>>>>> "IPv6 over 802.15.4" RFC5072 "IPv6 over PPP" and more.
>>>>>>
>>>>>>> Thanks. Btw, when I mentioned ‘people’ are aware of IP
>>>>>>> V2V but not see the need (so far), I referred to the
>>>>>>> automotive SDOs (led by automotive industries)…, although
>>>>>>> there are always ‘minority reports’ J
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Jérôme
>>>>>>>
>>>>>>> *From:*Mr. Jaehoon Paul Jeong
>>>>>>> [mailto:[email-masked]] *Sent:* Thursday 14 April
>>>>>>> 2016 09:36 *To:* Jérôme Härri *Cc:* Alexandre Petrescu;
>>>>>>> [email-masked] <mailto:[email-masked]> *Subject:* Re: [its]
>>>>>>> charter ITS
>>>>>>>
>>>>>>> Jérôme,
>>>>>>>
>>>>>>> Thanks for your feedback. Do not get me wrong, I am an
>>>>>>> academic and with my team, we also work on IP-based V2V
>>>>>>> and V2I, in particular related to mobility management
>>>>>>> with DMM, but also in the context of vehicular IoT.
>>>>>>>
>>>>>>> I just have the feeling that people are perfectly aware
>>>>>>> of the fact that IP _can_ be used for V2V and V2I, but
>>>>>>> does not ‘_need_’ to be used as other solutions already
>>>>>>> perfectly fit their need. Listing papers will not change
>>>>>>> this awareness.
>>>>>>>
>>>>>>> So, as a complement to academic papers, it would help to
>>>>>>> be able to pin-point which industrial activities are
>>>>>>> using or are strongly planning (short term I mean) to use
>>>>>>> pure IPv6 system in vehicles.
>>>>>>>
>>>>>>> My feeling here is we have a different eco-system that
>>>>>>> the Automotive industry (and automotive industry-related
>>>>>>> SDO)..more likely the IoT industry…and as such, we should
>>>>>>> not need to have the (direct) involvement of automotive
>>>>>>> industry in the Charter. If we can make this clear by an
>>>>>>> Btw, you can count on me your draft..we can add some
>>>>>>> IP-based V2V and V2I for mobility management and also
>>>>>>> IoT.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Jérôme
>>>>>>>
>>>>>>> <mailto:[email-masked]>] *Sent:* Thursday 14
>>>>>>> April 2016 03:22 *To:* Jérôme Härri *Cc:* Alexandre
>>>>>>> Petrescu; [email-masked] <mailto:[email-masked]>
>>>>>>> 1)Can we keep a reference to IEEE 802.11p, considering it
>>>>>>> does not exist anymore? It is now fully integrated into
>>>>>>> IEEE 802.11-2012 as OCB mode (and 10Mhz @5.9Ghz) of
>>>>>>> course.
>>>>>>>
>>>>>>> 2)Should we really keep C-ACC (or Platooning) in the
>>>>>>> charter explicitly as use case, considering it is a
>>>>>>> seriously controversial aspect with some SDOs (ex. In
>>>>>>> Automotive SDOs)? In the ISO presentation, Thierry
>>>>>>> mentions traffic efficiency/infotainment applications,
>>>>>>> such as in-signage applications...
>>>>>>>
>>>>>>> a.We might have to aim at less controversial use cases
>>>>>>> to attract automotive industries
>>>>>>>
>>>>>>> 3)One potential WI I could think of (rather a basic
>>>>>>> one): _definition of a vehicular wireless ‘link’ in an
>>>>>>> automotive context_
>>>>>>>
>>>>>>> 4)I would suggest to be more explicit in the foreseen
>>>>>>> challenges of this WG, instead of mentioning general use
>>>>>>> case (which end up be controversial)
>>>>>>>
>>>>>>> a.Example: maintaining IPv6 connectivity in fast and
>>>>>>> asymmetric wireless links; also under quickly changing
>>>>>>> topologies (actually suggested by Dick Roy on the chat
>>>>>>> room)
>>>>>>>
>>>>>>> 5)Before listing academic papers referring to IPv6 in
>>>>>>> vehicles, I would suggest to first try to list commercial
>>>>>>> products/solutions that are in vehicles and are using
>>>>>>> IPv6, possibly suffering from a silo limitations (ex.
>>>>>>> restricted to a single technology, single use case…)
>>>>>>>
>>>>>>> <mailto:[email-masked]>] *On Behalf Of *Alexandre
>>>>>>> Petrescu *Sent:* Wednesday 06 April 2016 23:45 *To:*
>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>> - the two Problem Statements drafts V2V and V2I joined,
>>>>>>> so there is less text in charter. - added an Item on
>>>>>>> "List of Research papers..."
>>>>>>>
>>>>>>> Erik: did I understand you correctly that there should be
>>>>>>> some item on discussing whether link-local addressing is
>>>>>>> sufficient, whether prefix exchange is necessary?
>>>>>>>
>>>>>>> Dino: should LISP be included in the gap analysis draft
>>>>>>> which includes C-ACC use-case?  OR should we separate a
>>>>>>> dedicated I-D only with gap analysis including ND, MIP,
>>>>>>> AODVv2, LISP?
>>>>>>>
>>>>>>> vehicle-to-vehicle interface illustrated good enough by
>>>>>>> the words "moving network to nearby moving network
>>>>>>> communications"?  Or is it better to say "the 1-IP-hop
>>>>>>> Nabil, Sandra: is it ok to have a working group item
>>>>>>> "List of Research Papers for IP in V2V and V2I
>>>>>>> communications"?
>>>>>>>
>>>>>>> Other comments?
>>>>>>>
>>>>>>> Alex
>>>>>>>
ITS (name to change)
>>>>>>> <mailto:[email-masked]> To Subscribe:
>>>>>>> https://www.ietf.org/mailman/listinfo/its Archive:
Additional web page TBD
>>>>>>>
>>>>>>> Charter:
>>>>>>>
>>>>>>> Goal ---- The goal of this group is to standardize
>>>>>>> IP-based protocols for establishing direct and secure
>>>>>>> connectivity between moving networks, some of which could
>>>>>>> be fixed permanently or temporarily.
>>>>>>>
>>>>>>> The group is concerned with all situations involving
>>>>>>> moving network to nearby moving network communications.
>>>>>>> For example: vehicle-to-vehicle communications, nomadic
>>>>>>> user wearing a PAN and communicating to a homenet,
>>>>>>> vehicle-to-infrastructure communications, wagon-to-wagon
>>>>>>> in a train, or train-to-intersection signalling.
>>>>>>>
>>>>>>> Automobiles and vehicles of all types are increasingly
>>>>>>> connected to the Internet, either as vehicle-to-vehicle,
>>>>>>> vehicle-to-infra or vehicle-to-Internet.  Entertainment
>>>>>>> apps enhancing comfort, reliable data exchanges for road
>>>>>>> safety, and automated driving are features coming in
>>>>>>> automobiles to hit the roads from now to year 2020.
>>>>>>> hyper-connectivity applied to vehicles, public
>>>>>>> authorities worldwide are increasingly mandating secure
>>>>>>> communication technology requirements in vehicles.
>>>>>>>
>>>>>>> Emergency apps for new instrumented ambulances carry
>>>>>>> many benefits both to the users and to society in
>>>>>>> general.
>>>>>>>
>>>>>>> Vehicle-to-Internet technologies, including car tethering
>>>>>>> through driver's cellular smartphone. However,
>>>>>>> Vehicle-to-Vehicle and Vehicle-to-Infrastructure
>>>>>>> communications are still being developed.  To improve on
>>>>>>> a situation of link-specific data exchanges, and enable
>>>>>>> independent application sets to share the same links, IP
>>>>>>> data exchanges are needed.  Enabling IP communication
>>>>>>> between vehicles (V2V), and between vehicles and the
>>>>>>> immediate infrastructure (V2I), will provide (0) ability
>>>>>>> to reach the rest of the world on the Internet (1) short
>>>>>>> and deterministic delays, (2) fast forwarding through
>>>>>>> scalable paths of routers, (3) ease of reuse of existing
>>>>>>> Moving network to nearby moving network communications
>>>>>>> involve link layers such as: 802.11p OCB (Outside the
>>>>>>> Context of a Basic Service Set), 802.15.4 with 6lowpan,
>>>>>>> 802.11ac, VLC (Visible Light Communications), IrDA,
>>>>>>> LTE-D.  Only the IP protocols are capable of running on
>>>>>>> each of these links and establish IP paths across them in
>>>>>>> an interoperable manner.
>>>>>>>
>>>>>>> Scenarios? ---------- There are a few scenarios
>>>>>>> exhibiting the need to communicate from one moving
>>>>>>> network to another nearby moving network.
>>>>>>>
>>>>>>> In the automobile space, the Cooperative Adaptive Cruise
>>>>>>> Control and Platooning features consider that vehicles
>>>>>>> close to each other exchange data describing their
>>>>>>> kinematic status.  At the cross-roads, the moving network
>>>>>>> inside a vehicle exchanges data with the moving network
>>>>>>> in the red-light pole.
>>>>>>>
>>>>>>> (in-vehicle, on-person) at an incident scene.  These
>>>>>>> networks need to interoperate in order to more
>>>>>>> effectively understand and deal with the incident scene.
>>>>>>>
>>>>>>> In connected rail scenarios the moving network deployed
>>>>>>> in trains communicate with other moving networks at the
>>>>>>> cross-points.
>>>>>>>
>>>>>>> What kind of solutions? ----------------------- The
>>>>>>> current technical solutions considered to achieve moving
>>>>>>> network to nearby moving network communications are of
>>>>>>> two kinds: IP routing protocols for n-hop path management
>>>>>>> and 1-hop link-scoped IP protocol enhancements.  The
>>>>>>> 1-hop link-scoped protocols include the protocols for
>>>>>>> route establishment involving ICMP Router Advertisements.
>>>>>>> The n-hop path management protocols include n-hop path
>>>>>>> establishment protocols (e.g. Babel, OSPF) and n-hop path
>>>>>>> search protocols (most notably AODV and derivates).
>>>>>>>
>>>>>>> In this proposed Working Group the focus is on 1-hop
>>>>>>> protocols, and leverage from other Working Groups for the
>>>>>>> n-hop situations.
>>>>>>>
>>>>>>> opportunity for exchanging data with the immediate
>>>>>>> infrastructure may be very short.  For example, a car
>>>>>>> driving near a road-side unit may have only 5s to
>>>>>>> exchange with that RSU (depending on speed, RSU range and
>>>>>>> What kind of requirements? --------------------------
>>>>>>> The requirements for mechanisms for moving network to
>>>>>>> nearby moving network communications are focusing on low
>>>>>>> delays of the data paths, reduced number of messages for
>>>>>>> path establishment, application friendly, resilience to
>>>>>>> attacks, compatibility with DHCP and Mobile IP.
>>>>>>>
>>>>>>> In addition, some moving network to nearby moving
>>>>>>> network applications involve IP multicast mechanisms
>>>>>>> (e.g. virtual siren); thus C-ACC the 1-hop IP moving
>>>>>>> network to nearby moving netowrk mechanisms will need to
>>>>>>> gracefully support IP multicast.
>>>>>>>
>>>>>>> communications, all new moving network to nearby moving
>>>>>>> network mechanisms must afford authenticity and
>>>>>>> confidentiality where necessary.  Dynamically
>>>>>>> establishing ephemeral communication paths between
>>>>>>> automobiles in public areas must offer privacy safeguards
>>>>>>> for the end users (passengers).
>>>>>>>
>>>>>>> Establishing 1-hop IP V2V paths must not break the
>>>>>>> existing on-board protocols and applications which
>>>>>>> communicate with the Internet, possibly via multiple
>>>>>>> radios.
>>>>>>>
>>>>>>> In a moving network deployed in an automobile, typically
>>>>>>> one exit point connects the moving network to other
>>>>>>> moving networks. However, in a more general manner (and
>>>>>>> to support reliability) any new mechanism of moving
>>>>>>> network to nearby moving network communications should
>>>>>>> support multi-homing: one router to use multiple
>>>>>>> interfaces towards outside the moving network, or
>>>>>>> multiple routers.
>>>>>>>
>>>>>>> ------------------------------------- The group will only
>>>>>>> work on IPv6 solutions.
>>>>>>>
>>>>>>> ----------------------------- The requirements and
>>>>>>> standards for moving network to nearby moving network
>>>>>>> communications, often involving IPv6, and novel V2V and
>>>>>>> V2Infra concepts, are developed mainly at ISO TC204
>>>>>>> "Intelligent Transport Systems", 3GPP, ETSI, NHTSA and
>>>>>>> IEEE.  For Vehicle-to-Internet communications, 3GPP LTE
>>>>>>> and other cellular technologies represent the long-range
>>>>>>> connectivity method; for Vehicle-to-Vehicle
>>>>>>> communications, LTE Direct is currently specified, as
>>>>>>> well as OCB mode of IEEE 802.11.  Several use-cases
>>>>>>> exhibit a need for IPv6 data exchanges between vehicles:
>>>>>>> ETSI's Cooperative Adaptive Cruise Control and
>>>>>>> Platooning.  The IEEE developed a popular link for
>>>>>>> short-range communications - IEEE 802.11p "WAVE".  The
>>>>>>> NHTSA wrote a set of requirements for V2V
>>>>>>> communications.
>>>>>>>
>>>>>>> Work Items ---------- - use-cases for moving network to
>>>>>>> nearby moving network communications - Problem Statement
>>>>>>> for moving network to nearby moving network
>>>>>>> communications including V2V, V2I and DNS. - Security and
>>>>>>> Privacy Requirements for moving network to nearby moving
>>>>>>> network communications - Solutions, which might include
>>>>>>> new protocols or extensions to existing protocols.  With
>>>>>>> MIB. - IPv6-over foo, where foo is pertinent for moving
>>>>>>> network to nearby moving network communications (e.g.
>>>>>>> 802.11 OCB, VLC, LTE-D, 802.11ad) - List of Research
>>>>>>> Papers in the V2V domain, identifying which uses IP.
>>>>>>>
>>>>>>> Timeline -------- -
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ its
>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>>> =========================== Mr. Jaehoon (Paul) Jeong,
>>>>>>> Ph.D. Assistant Professor Department of Software
>>>>>>> Sungkyunkwan University Office: +82-31-299-4957 Email:
>>>>>>> [email-masked] <mailto:[email-masked]>,
>>>>>>> =========================== Mr. Jaehoon (Paul) Jeong,
>>>>>>> Ph.D. Assistant Professor Department of Software
>>>>>>> Sungkyunkwan University Office: +82-31-299-4957 Email:
>>>>>>> [email-masked] <mailto:[email-masked]>,
>>>>>> _______________________________________________ its mailing
>>>>>> list [email-masked] <mailto:[email-masked]>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Mon, 18 Apr 2016 20:39:19 +0900

Super! 

Let me work on the gap analysis. Soon I will post this. 

Cheers!

> On Apr 18, 2016, at 8:23 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi Jong-Hyouk,
> 
> There is some useful text that can be used for 'use-cases for IP in V2V and V2I moving network to nearby moving or fixed network':
> If that is not enough, we can ask members of the ITS at IETF email list whether they can write use-case text for this latter part.
> 
> https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-04#section-14 <https://tools.ietf.org/html/draft-petrescu-its-cacc-sdo-04#section-14>
> 
> Alex
> 
>> 
>>> 
>>>>>>>> [mailto:[email-masked]

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 18 Apr 2016 14:51:52 +0000

Alex - Inline ..

To: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [its] charter ITS - proposed work items

ITSers,

[Sri] Agree. This is a good starting point. Use-Cases document is needed. On the Gap Analysis document, it should be stated as how the gaps are captured and in relation to what technology. Is it NEMO, MANET, some other protocols ?

[Sri] If my starting point is #1, not sure how to read this ? Prefix exchanges appears more like a solution. In MANET there is exchange of prefixes, in NEMO we don't inject those prefixes and so I do not know if this work item is valid at this time.

[Sri] Not clear what the deliverable is.

What do you think?

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 19 Apr 2016 00:22:30 +0900

Hi Sri,

Just one comment regarding IP prefix exchanges. Plz see inline.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> Alex – Inline ..
> 
> 
> 
> To: Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> [Sri] If my starting point is #1, not sure how to read this ? Prefix exchanges appears more like a solution. In MANET there is exchange of prefixes, in NEMO we don’t inject those prefixes and so I do not know if this work item is valid at this time.

You are right. That is a missing part. We need to have a solution for "IP prefix exchanges in V2V and V2I” The need of IP prefix exchanges is clear and well presented in PS documents for IP in V2V and V2I. Then, there are 2 documents already existing as below:

1. https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00
2. https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00

The above 2 documents are the early effort to establish IP direction communications between vehicles and also between a vehicle and a road side unit. 

I officially request that we should have a solution for IP prefix exchanges as a work item.

Cheers!

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 18 Apr 2016 15:56:43 +0000

Hi Jong-Hyouk,

> I officially request that we should have a solution for IP prefix exchanges as a work item.

This is one specific approach. The description for the work item can be bit more generic.

Sri

From: Jong-Hyouk Lee <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 18, 2016 at 8:22 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [its] charter ITS - proposed work items

Hi Sri,

#email: [email-masked]<mailto:[email-masked]>
#webpage: https://sites.google.com/site/hurryon

On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:

Alex - Inline ..

ITSers,

You are right. That is a missing part. We need to have a solution for "IP prefix exchanges in V2V and V2I" The need of IP prefix exchanges is clear and well presented in PS documents for IP in V2V and V2I. Then, there are 2 documents already existing as below:

Cheers!

What do you think?

_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Apr 2016 19:00:41 +0200

Sri,

Thanks for the reply.

Le 18/04/2016 16:51, Sri Gundavelli (sgundave) a écrit :
> Alex – Inline ..
>
>
>
> To: Alexandre Petrescu <[email-masked]
> <mailto:[email-masked]>> Cc: "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> Subject:
> Re: [its] charter ITS - proposed work items
>
>
> ITSers, We work on a more rigorous ITS charter text. Now we propose
> four work items: 1. "Problem statement for IP in V2V and V2I"
> including "IP addressing architecture for V2V and V2I" and including
> "Gap Analysis: IP protocols suited and gaps" and including "Use-cases
> network"
> [Sri] Agree. This is a good starting point. Use-Cases document is
> needed.

Noted.

> On the Gap Analysis document,

"Gap Analysis" would be a section, not a document, we agree.

> it should be stated as how the gaps are captured and in relation to
> what technology. Is it NEMO, MANET, some other protocols ?

For MANET - it's AODVv2.  We have gap analysis text about AODVv2.

For NEMO - the 'gap analysis' perspective is that NEMO can not solve the
problem: as you say, NEMO does not inject routes.  _If_ there is
interest about NEMO in a V2V context then we must make sure that any new
solution developped by this group does not stop NEMO from working.  For
example, one does not want a default route present within a car to point
to another car, but to point to the "NEMO tunnel", otherwise NEMO breaks.

Similar principle - dont break existing protocols - may apply to other
related protocols, like LISP, although recently we have been told that
LISP can be completely independent of any new solution designed here.

How about a PMIP gap analysis: would PMIP continue working even though
vehicles were exchanging routes?  Explaining that makes sense in a 'gap
analysis' section.  What do you think?

> [Sri] If my starting point is #1, not sure how to read this ? Prefix
> exchanges appears more like a solution.

Yes.

> In MANET there is exchange of prefixes,

Intuitively, one may think so at first.

But in details: AODVv2 is not doing prefix exchange, but route discovery
by sending messages to explore paths.  OLSR is a way too complex
protocol and implementations for the simple 1-hop topologies in V2V
(e.g. OLSR 2-hop sets are useless here).

For the moment we have a subsection on AODVv2 gap analysis.  There is 
little tract (if any) in the ITS community for more MANET than just that.

> in NEMO we don’t inject those prefixes and so I do not know if this
> work item is valid at this time.

Right - with NEMO we dont inject routes, that's why we dont consider
NEMO to solve the problem statement.  Something else is needed.

[...]

Alex

>
>
> What do you think? Please respond by next Monday, April 18th.
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Apr 2016 19:01:12 +0200

Le 18/04/2016 17:22, Jong-Hyouk Lee a écrit :
>> On Apr 18, 2016, at 11:51 PM, Sri Gundavelli (sgundave)
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Alex – Inline ..
>>
>>
>>
>> <mailto:[email-masked]>>
>> for IP in V2V and V2I moving network to nearby moving or fixed network"
>> needed. On the Gap Analysis document, it should be stated as how the
>> gaps are captured and in relation to what technology. Is it NEMO,
>> MANET, some other protocols ?
>>
>> exchanges appears more like a solution. In MANET there is exchange of
>> prefixes, in NEMO we don’t inject those prefixes and so I do not know
>> if this work item is valid at this time.
>
> You are right. That is a missing part. We need to have a solution for
> "IP prefix exchanges in V2V and V2I” The need of IP prefix exchanges is
> clear and well presented in PS documents for IP in V2V and V2I. Then,
> there are 2 documents already existing as below:
>
> The above 2 documents are the early effort to establish IP direction
> communications between vehicles and also between a vehicle and a road
> side unit.
>

Noted.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Apr 2016 19:12:51 +0200

> This is one specific approach. The description for the work item can be

Thanks, but I would need a title for it.

How about:

"Solution for 1-hop IP V2V"?

"Solution to establish a 1-hop IP path between nearby moving networks or 
between nearby moving networks and an immediate fixed network"

"Solution for Moving/Fixed Network Discovery and 1-hop Path
  Establishment"?

"Solution for end-to-end path establishment in a star topology
  with 1-hop fragile core and n-hop stable edges"?

Alex

>
>
> Sri
>
>
> From: Jong-Hyouk Lee <[email-masked] <mailto:[email-masked]>>
> To: Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
> Cc: Alexandre Petrescu <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: Sandra Céspedes <[email-masked]>
Date: Mon, 18 Apr 2016 19:11:20 -0300

+1

Regards,

Sandra Céspedes.

De: its [mailto:[email-masked]] En nombre de Nabil Benamar
Enviado el: lunes, 18 de abril de 2016 4:55
Para: Alexandre Petrescu <[email-masked]>
CC: [email-masked]
Asunto: Re: [its] charter ITS - proposed work items

Hi All,

I agree on the current charter since these are the points discussed during the BoF! However there were some replies in this list mentioning to probably add IoT as an exemple of IP based communications.  I think that we should keep the focus on vehicular communications/networks and do not diverge from this topic. IoT is fundamentally different from vehicular networks in many aspects such as routing, energy consumption, mac layer, etc...

Best regards

Nabil Benamar

-------------------

نبيل بنعمرو

On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]> > wrote:

ITSers,

What do you think?

Alex and Dapeng

Paul,

Cheers,

Jérôme

*From:*Mr. Jaehoon Paul Jeong [mailto:[email-masked] <mailto:[email-masked]> ]
*Sent:* Thursday 14 April 2016 09:36
*To:* Jérôme Härri
*Cc:* Alexandre Petrescu; [email-masked] <mailto:[email-masked]> 
*Subject:* Re: [its] charter ITS

Jérôme,

I got it :-)

by a personal message.

Thanks.

Paul

On Thu, Apr 14, 2016 at 4:09 PM, Jérôme Härri <[email-masked] <mailto:[email-masked]> 
<mailto:[email-masked] <mailto:[email-masked]> >> wrote:

Hi Paul,

Cheers,

Jérôme

*From:*Mr. Jaehoon Paul Jeong [mailto:[email-masked] <mailto:[email-masked]> 
<mailto:[email-masked] <mailto:[email-masked]> >]
*Sent:* Thursday 14 April 2016 03:22
*To:* Jérôme Härri
*Cc:* Alexandre Petrescu; [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
*Subject:* Re: [its] charter ITS

Hi Jérôme,

in the industry.

through a WI. Note that the draft of the list will include the summary
of the main

ideas of the papers.

For the industry current activities for this area, I believe that you
can share them

Thanks.

Best Regards,

Paul

On Thu, Apr 7, 2016 at 8:11 AM, Jérôme Härri <[email-masked] <mailto:[email-masked]> 
<mailto:[email-masked] <mailto:[email-masked]> >> wrote:

Dear ITSers,  Dear Alex,

My two cents..

Best Regards,

Jérôme

*From:*its [mailto:[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >]
*On Behalf Of *Alexandre Petrescu
*Sent:* Wednesday 06 April 2016 23:45
*To:* [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
*Subject:* [its] charter ITS

ITSers,

Other comments?

Alex

              ITS (name to change)
                    Charter
              April 6th, 2016

Chairs:
    TBD

Assigned Area Director:
    TBD

Mailing list
    Address: [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
    To Subscribe: https://www.ietf.org/mailman/listinfo/its
    Archive:
http://www.ietf.org/mail-archive/web/its/current/maillist.html

Additional web page
    TBD

Charter:

Goal
----

Why IP?
-------

Scenarios?
----------

What kind of solutions?
-----------------------

Work Items
----------

Timeline
--------
-

_______________________________________________
its mailing list
[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
https://www.ietf.org/mailman/listinfo/its

--

===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957 <tel:%2B82-31-299-4957> 
Email: [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >,
[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

--

===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957 <tel:%2B82-31-299-4957> 
Email: [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >,
[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 19 Apr 2016 07:51:06 +0900

Alex,

> On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> "Solution to establish a 1-hop IP path between nearby moving networks or between nearby moving networks and an immediate fixed network"
> 
> with 1-hop fragile core and n-hop stable edges”?

We may refer the ISO/TC204 liaison link: https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf

As presented at the slide #13 above: ISO/TC204 calls "Direct communication between ITS stations” Its need has been well presented and as expressed at the slides, ISO/TC204 says…"Generically applicable IETF standard is sought on this otherwise ISO will develop its own” Thierry would have a better idea. Let me him in this loop.

Note that the request of the development of a solution for direct communication between ITS stations has a long history and as you may know because of this request the mnpp protocol (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00 <https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00>) was developed as a result of FP7 EU project, Geonet (design and development of Geoneworking over IPv6). At that time, there was no place to make it as RFC at the IETF due to not matured ITS activities at the IETF.

Cheers.

---

From: Jérôme Härri (EURECOM) <[email-masked]>
Date: Tue, 19 Apr 2016 09:26:03 +0200

Dear Nabil, Dear All,

I am one of the supporters of having IoT in the charter, and I disagree with your statement on IoT. 

There are plenty of interpretation of what IoT is or is not...the same stands for vehicular communications...

IoT will be transiting via vehicular communication - we have a testbed, where IoT traffic from embedded sensors (CAN or non-CAN) are sent to an IoT server on Internet via ITS-G5/DSRC communication. IoT here is the architecture (oneM2M) that is above a specific technology, not a technology itself (you are maybe referring to SigFox or LTE-sensors I guess)..so, our system works if we use another technology and would even need to work if we have multiple technologies on the path between the sensors and the  ‘cloud’…here, IPv6 take all of its sense.

The IoT differences in ‘routing, energy consumption, mac layer’ as you said are actually either fully relevant to the charter, as referring to IPv6-over-foo or fully irrelevant to IPv6 (as based on IoT application-level traffic). 

Instead of debating whether we should add IoT or keep vehicular communication, we should debate of what kind of traffic (M2M-like, stream?, unicast/multicast etc..) will be transiting through IPv6 communication from a ‘vehicle’ to either Internet or another ‘vehicle’. 

And I would like to mention that my suggestion is not to reduce the focus, but actually to focus on an aspect, where IPv6 does not have a competitor and can really make a difference.

Said simple: if the charter addresses primarily IPv6 for critical safety communications, this will be difficult to sell, as other simpler solutions already work without IPv6. 

I would therefore support and even propose to have a draft  formulating the problem related to “IoT-over-IPv6 on moving networks”. 

Best Regards,

Jérôme

Envoyé de mon iPad

De: its [ <mailto:[email-masked]> mailto:[email-masked]] En nombre de Nabil Benamar
Enviado el: lunes, 18 de abril de 2016 4:55
Para: Alexandre Petrescu < <mailto:[email-masked]> [email-masked]>
CC:  <mailto:[email-masked]> [email-masked]
Asunto: Re: [its] charter ITS - proposed work items

Hi All,

Best regards

Nabil Benamar

-------------------

نبيل بنعمرو

On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu <[email-masked]> wrote:

ITSers,

What do you think?

Alex and Dapeng

Paul,

Cheers,

Jérôme

Jérôme,

I got it :-)

by a personal message.

Thanks.

Paul

Hi Paul,

Cheers,

Jérôme

Hi Jérôme,

in the industry.

ideas of the papers.

Thanks.

Best Regards,

Paul

Dear ITSers,  Dear Alex,

My two cents..

Best Regards,

Jérôme

ITSers,

Other comments?

Alex

              ITS (name to change)
                    Charter
              April 6th, 2016

Chairs:
    TBD

Assigned Area Director:
    TBD

Mailing list

Additional web page
    TBD

Charter:

Goal
----

Why IP?
-------

Scenarios?
----------

What kind of solutions?
-----------------------

Work Items
----------

Timeline
--------
-

--

--

 

  _____  

 <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Avast logo

El software de antivirus Avast ha analizado este correo electrónico en busca de virus. 
www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 19 Apr 2016 16:43:19 +0900

+1

> On Apr 19, 2016, at 4:26 PM, Jérôme Härri (EURECOM) <[email-masked]> wrote:
> 
> Dear Nabil, Dear All,
>  
>> De: its [mailto:[email-masked] <mailto:[email-masked]>] En nombre de Nabil Benamar
>> Para: Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>
>> CC: [email-masked] <mailto:[email-masked]>
>> http://nabilbenamar.ipv6-lab.net/ <http://nabilbenamar.ipv6-lab.net/>
>>  
>> On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
>>> ITSers,
>>> 
>>>> *From:*Mr. Jaehoon Paul Jeong [mailto:[email-masked] <mailto:[email-masked]>]
>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>> 
>>>> Hi Paul,
>>>> 
>>>> <mailto:[email-masked] <mailto:[email-masked]>>]
>>>> *Cc:* Alexandre Petrescu; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>> 
>>>> Dear ITSers,  Dear Alex,
>>>> 
>>>> *From:*its [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>]
>>>> *To:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>     Address: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>> Email: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>,
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://iotlab.skku.edu/people-jaehoon-jeong.php>
>>>> <http://cpslab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>>
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Email: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>,
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://iotlab.skku.edu/people-jaehoon-jeong.php>
>>>> <http://cpslab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>>
>>>> 
>>> 
>>  <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>	
>> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>_______________________________________________
> its mailing list

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Apr 2016 13:52:47 +0200

Le 19/04/2016 00:51, Jong-Hyouk Lee a écrit :
> Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null and
> /dev/random Protocol Engineering Lab., Sangmyung University
>
>> On Apr 19, 2016, at 2:12 AM, Alexandre Petrescu
>>>> I officially request that we should have a solution for IP
>>>> prefix
>>> exchanges as a work item.
>>>
>> "Solution to establish a 1-hop IP path between nearby moving
>> networks or between nearby moving networks and an immediate fixed
>> network"
>>
>> "Solution for end-to-end path establishment in a star topology with
>> 1-hop fragile core and n-hop stable edges”?
>
> We may refer the ISO/TC204 liaison link:
> https://www.ietf.org/proceedings/95/slides/slides-95-its-7.pdf
>
> As presented at the slide #13 above: ISO/TC204 calls "Direct
> communication between ITS stations”

What is an "ITS Station"?  Can't we use "Mobile Router" instead?

Alex

> Its need has been well presented and as expressed at the slides,
> ISO/TC204 says…"Generically applicable IETF standard is sought on
> this otherwise ISO will develop its own” Thierry would have a better
> idea. Let me him in this loop.
>
> Note that the request of the development of a solution for direct
> communication between ITS stations has a long history and as you may
>  know because of this request the mnpp protocol
> (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was developed
> as a result of FP7 EU project, Geonet (design and development of
> Geoneworking over IPv6). At that time, there was no place to make it
> as RFC at the IETF due to not matured ITS activities at the IETF.
>
> Cheers.
>
>>
>> Alex
>>
>>>
>>>
>>> Sri
>>>
>>>
>>> From: Jong-Hyouk Lee <[email-masked]
>>> <mailto:[email-masked]> <mailto:[email-masked]>> Date:
>>> Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli
>>> <[email-masked] <mailto:[email-masked]>
>>> <mailto:[email-masked]>> Cc: Alexandre Petrescu
>>> <mailto:[email-masked]>
>>> <mailto:[email-masked]> <mailto:[email-masked]>" <[email-masked]
>>> <mailto:[email-masked]> <mailto:[email-masked]>> Subject: Re: [its]
>>> charter ITS - proposed work items
>>>
>>> Hi Sri,
>>>
>>> -- Jong-Hyouk Lee, living somewhere between /dev/null and
>>> /dev/random Protocol Engineering Lab., Sangmyung University
>>>
>>> <mailto:[email-masked]> #webpage:
>>>> <[email-masked] <mailto:[email-masked]>
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> Alex – Inline ..
>>>>
>>>>
>>>>
>>>> <mailto:[email-masked]>
>>>> <mailto:[email-masked]> <mailto:[email-masked]>" <[email-masked]
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> Subject: Re: [its]
>>>> charter ITS - proposed work items
>>>>
>>>>
>>>> ITSers, We work on a more rigorous ITS charter text. Now we
>>>> propose four work items: 1. "Problem statement for IP in V2V
>>>> and V2I" including "IP addressing architecture for V2V and V2I"
>>>> and including "Gap Analysis: IP protocols suited and gaps" and
>>>> including "Use-cases for IP in V2V and V2I moving network to
>>>> nearby moving or fixed network" [Sri] Agree. This is a good
>>>> starting point. Use-Cases document is needed. On the Gap
>>>> Analysis document, it should be stated as how the gaps are
>>>> captured and in relation to what technology. Is it NEMO, MANET,
>>>> some other protocols ?
>>>>
>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and V2I
>>>> context" [Sri] If my starting point is #1, not sure how to read
>>>> this ? Prefix exchanges appears more like a solution. In MANET
>>>> there is exchange of prefixes, in NEMO we don’t inject those
>>>> prefixes and so I do not know if this work item is valid at
>>>> this time.
>>>
>>> You are right. That is a missing part. We need to have a solution
>>> for "IP prefix exchanges in V2V and V2I” The need of IP prefix
>>> exchanges is clear and well presented in PS documents for IP in
>>> V2V and V2I. Then, there are 2 documents already existing as
>>> below:
>>>
>>> 1.
>>> https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00
>>>
>>>
>>>
>>> The above 2 documents are the early effort to establish IP
>>> direction communications between vehicles and also between a
>>> vehicle and a road side unit.
>>>
>>>> list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 19 Apr 2016 21:16:27 +0900

> On Apr 19, 2016, at 8:52 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

Alex, come on! How don’t you know the term used in ISO/TC204. ;)

>>>> prefix exchanges as a work item.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Cheers!
>>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Apr 2016 14:35:33 +0200

I know.  But at IETF we use the term "Mobile Router" extensively.

I guess we need a Terminology section which says:
ITS Station == Mobile Router  == modem(s)

because some car manufacturers use the term "modem" extensively even today.

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Tue, 19 Apr 2016 14:39:59 +0200

Hi Alex, All,

I would not say Mobile Router == ITS-S == Modem 

We need to look at the functions. The ITS-S the overall 'system' consisting
of the ITS stack (at least at ETSI, but I guess similar at ISO), while the
MR is the routing layer and the modem is the Access Layer. But it could be
nice to try to come to a joint naming across SDOs...maybe another WI??

Cheers,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Tuesday 19 April 2016 14:36
To: Jong-Hyouk Lee
Cc: Thierry Ernst; [email-masked]; Sri Gundavelli (sgundave)
Subject: Re: [its] charter ITS - proposed work items

Alex

>>>>>> propose four work items: 1. "Problem statement for IP in V2V and 
>>>>>> V2I" including "IP addressing architecture for V2V and V2I"
>>>>>> starting point. Use-Cases document is needed. On the Gap Analysis 
>>>>>> document, it should be stated as how the gaps are captured and in 
>>>>>> relation to what technology. Is it NEMO, MANET, some other 
>>>>>> protocols ?
>>>>>>
>>>>>> prefixes and so I do not know if this work item is valid at this 
>>>>>> time.
>>>>>
>>>>>> including connectivity in fast and asymmetric conditions, 
>>>>>> coverage area vs speed diagrams, below-IP congestion management.
>>>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Apr 2016 14:43:38 +0200

> I would not say Mobile Router == ITS-S == Modem

The problem is that for each of these terms, there are strong defenders:
IETF RFC, ISO/TC204 document, and car manufacturer.

> We need to look at the functions.

I agree.

> The ITS-S the overall 'system' consisting of the ITS stack (at least
> at ETSI, but I guess similar at ISO), while the MR is the routing
> layer and the modem is the Access Layer. But it could be nice to try
> to come to a joint naming across SDOs...maybe another WI??

The terminology direction you give is relevant.

However, no new WI because there are already too many.

IETF documents have a Terminology section...

Alex

>
> Cheers,
>
> Jérôme
>
> -----Original Message----- From: its [mailto:[email-masked]] On
> Behalf Of Alexandre Petrescu Sent: Tuesday 19 April 2016 14:36 To:
> Jong-Hyouk Lee Cc: Thierry Ernst; [email-masked]; Sri Gundavelli
> (sgundave) Subject: Re: [its] charter ITS - proposed work items
>
>
>
>>>> Alex, -- Jong-Hyouk Lee, living somewhere between /dev/null
>>>> and /dev/random Protocol Engineering Lab., Sangmyung
>>>> University
>>>>
>>>>>>> I officially request that we should have a solution for
>>>>>>> IP prefix
>>>>> networks or between nearby moving networks and an immediate
>>>>> fixed network"
>>>>>
>>>>> "Solution for end-to-end path establishment in a star
>>>>> topology with 1-hop fragile core and n-hop stable edges"?
>>>>
>>>> communication between ITS stations"
>>>
>> Alex, come on! How don't you know the term used in ISO/TC204. ;)
>
> I guess we need a Terminology section which says: ITS Station ==
> Mobile Router  == modem(s)
>
>>>> Its need has been well presented and as expressed at the
>>>> slides, ISO/TC204 says."Generically applicable IETF standard is
>>>> sought on this otherwise ISO will develop its own" Thierry
>>>> would have a better idea. Let me him in this loop.
>>>>
>>>> Note that the request of the development of a solution for
>>>> direct communication between ITS stations has a long history
>>>> and as you may know because of this request the mnpp protocol
>>>> (https://tools.ietf.org/html/draft-jhlee-mext-mnpp-00) was
>>>> developed as a result of FP7 EU project, Geonet (design and
>>>> development of Geoneworking over IPv6). At that time, there was
>>>> no place to make it as RFC at the IETF due to not matured ITS
>>>> activities at the IETF.
>>>>
>>>> Cheers.
>>>>
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>>
>>>>>> Sri
>>>>>>
>>>>>>
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>> Date: Monday, April 18, 2016 at 8:22 AM To: Sri Gundavelli
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> Subject: Re:
>>>>>> [its] charter ITS - proposed work items
>>>>>>
>>>>>> Hi Sri,
>>>>>>
>>>>>> Just one comment regarding IP prefix exchanges. Plz see
>>>>>> inline. -- Jong-Hyouk Lee, living somewhere between
>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>"
>>>>>>> <[email-masked] <mailto:[email-masked]>
>>>>>>> <mailto:[email-masked]>> Subject: Re: [its] charter ITS -
>>>>>>> proposed work items
>>>>>>>
>>>>>>>
>>>>>>> ITSers, We work on a more rigorous ITS charter text. Now
>>>>>>> we propose four work items: 1. "Problem statement for IP
>>>>>>> in V2V and V2I" including "IP addressing architecture for
>>>>>>> V2V and V2I" and including "Gap Analysis: IP protocols
>>>>>>> suited and gaps" and including "Use-cases for IP in V2V
>>>>>>> and V2I moving network to nearby moving or fixed network"
>>>>>>> [Sri] Agree. This is a good starting point. Use-Cases
>>>>>>> document is needed. On the Gap Analysis document, it
>>>>>>> should be stated as how the gaps are captured and in
>>>>>>> relation to what technology. Is it NEMO, MANET, some
>>>>>>> other protocols ?
>>>>>>>
>>>>>>> 2. "Threat Analysis for IP prefix exchanges in V2V and
>>>>>>> V2I context" [Sri] If my starting point is #1, not sure
>>>>>>> how to read this ? Prefix exchanges appears more like a
>>>>>>> solution. In MANET there is exchange of prefixes, in NEMO
>>>>>>> we don't inject those prefixes and so I do not know if
>>>>>>> this work item is valid at this time.
>>>>>>
>>>>>> You are right. That is a missing part. We need to have a
>>>>>> solution for "IP prefix exchanges in V2V and V2I" The need
>>>>>> of IP prefix exchanges is clear and well presented in PS
>>>>>> documents for IP in V2V and V2I. Then, there are 2
>>>>>> documents already existing as below:
>>>>>>
>>>>>> 1.
>>>>>> https://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routi
>>>>>>
>>>>>>
ng-00
>>>>>> direction communications between vehicles and also between
>>>>>> a vehicle and a road side unit.
>>>>>>
>>>>>>> document[*], including connectivity in fast and
>>>>>>> asymmetric conditions, coverage area vs speed diagrams,
>>>>>>> below-IP congestion management.
>>>>>>>
>>>>>>> 4. "List of papers and _products_ using IP in V2V and
>>>>>>> V2I" [Sri] Not clear what the deliverable is.
>>>>>>>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 19 Apr 2016 21:46:20 +0900

Plz see inline.

> On Apr 19, 2016, at 9:35 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

Hmmmmm…I agree we need the terminology section in one document (I do not know which one would be good for the terminology section). Anyway, what you said is wrong. 

There are 4 types of cooperative ITS stations: Personal ITS station (e.g., smartphone), Vehicle ITS station, Roadside ITS station, and Central ITS station. Then, for example, at a vehicle ITS station, a vehicle ITS station gateway, ITS station host, and ITS station router may exist. Those are connected each other on the ITS station internal network. The vehicle ITS station gateway is connected to ECUs on propriety in-vehicle network. The ITS station router is the one used to connect to other side (e.g., Roadside ITS station or Internet). So, the mobile router we are calling here at the IETF is the ITS station router at the ISO/TC 204 standardisations. 

Cheers.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Apr 2016 15:11:32 +0200

Jérôme,

I agree with many things that you say below.

The platform that you have looks very interesting - you send data from 
CAN things through 802.11-OCB, all the way to the Internet (V2Internet); 
IPv6 has its perfect place there.

You ask whether the draft proposes IPv6 mainly for safety-criticial 
apps: no, the current text uses other motivators for IPv6.

But,

I can't suggest an IoT work item right now in the Charter.  We never 
talked about it and there are already 5 items.

Maybe you want us to just use some "IoT" text in the charter? like in 
saying to leverage other IETF IoT-related work like 6lo and LP-WAN?  If 
yes, we'll see that in a few days when we announce the preliminary 
charter.  Please keep "IoT" in mind.

Otherwise, if you really want an IoT work item, you may do:
- ask Jong-Hyouk and others to join your effort.
- write an Internet Draft as individual submission (not work item) that
   would answer some questions, among which:
- is IoT-over-IP an application?  Which application?
   For example, an application is remote software update of Things in a
   vehicle.  What Thing more precisely?  The map storer?  The airbag
   controller?

- what is the relationship between IoT-over-IP and V2V, V2I, I2V,
   V2Internet?

- is "I" losing meaning if IoT is in moving network to
   moving network fully disconnected from the Internet?

- can we use just "T" (Things) in order to realize some relevant V2V
   use-cases?
   For example, at IETF they created this T2T (thing to thing) effort.

- if "IoT" is a Colgate barcode, what is a car license plate?

- present.

... and see where is the tract.

Alex

Le 19/04/2016 09:26,  Jérôme Härri (EURECOM)  a écrit :
> IoT will be transiting via vehicular communication - we have a testbed,
> where IoT traffic from embedded sensors (CAN or non-CAN) are sent to an
> IoT server on Internet via ITS-G5/DSRC communication. IoT here is the
> architecture (oneM2M) that is above a specific technology, not a
> technology itself (you are maybe referring to SigFox or LTE-sensors I
> guess)..so, our system works if we use another technology and would even
> need to work if we have multiple technologies on the path between the
> sensors and the  ‘cloud’…here, IPv6 take all of its sense.
>
> The IoT differences in ‘routing, energy consumption, mac layer’ as you
> said are actually either fully relevant to the charter, as referring to
> IPv6-over-foo or fully irrelevant to IPv6 (as based on IoT
> application-level traffic).
>
> Instead of debating whether we should add IoT or keep vehicular
> communication, we should debate of what kind of traffic (M2M-like,
> stream?, unicast/multicast etc..) will be transiting through IPv6
> communication from a ‘vehicle’ to either Internet or another ‘vehicle’.
>
> And I would like to mention that my suggestion is not to reduce the
> focus, but actually to focus on an aspect, where IPv6 does not have a
> competitor and can really make a difference.
>
> Said simple: if the charter addresses primarily IPv6 for critical safety
> communications, this will be difficult to sell, as other simpler
> solutions already work without IPv6.
>
> I would therefore support and even propose to have a draft  formulating
> the problem related to “IoT-over-IPv6 on moving networks”.
>
> Best Regards,
>
> Jérôme
>
>
>
> Envoyé de mon iPad
>
>     *De:*its [mailto:[email-masked]] *En nombre de *Nabil Benamar
>     *Enviado el:* lunes, 18 de abril de 2016 4:55
>     *Para:* Alexandre Petrescu <[email-masked]
>     *CC:* [email-masked] <mailto:[email-masked]>
>     *Asunto:* Re: [its] charter ITS - proposed work items
>
>     Hi All,
>
>     I agree on the current charter since these are the points discussed
>     during the BoF! However there were some replies in this list
>     mentioning to probably add IoT as an exemple of IP based
>     communications.  I think that we should keep the focus on vehicular
>     communications/networks and do not diverge from this topic. IoT is
>     fundamentally different from vehicular networks in many aspects such
>     as routing, energy consumption, mac layer, etc...
>
>
>     Best regards
>
>     Nabil Benamar
>
>     -------------------
>
>     نبيل بنعمرو
>
>     On Thu, Apr 14, 2016 at 9:42 AM, Alexandre Petrescu
>         coverage
>             automotive
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>> wrote:
>
>             Hi Paul,
>
>             academic and with
>             Automotive
>             IP-based V2V and
>             <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>> wrote:
>
>             Dear ITSers,  Dear Alex,
>
>             does not exist
>             explicitly
>             _definition of
>             challenges of this
>             asymmetric wireless
>             vehicles, I would
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>]
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             some item on
>             which includes
>             vehicle-to-vehicle
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             vehicle-to-vehicle
>             connected to
>             reliable
>             benefits
>             involve link
>             Control and
>             cross-roads,
>             Distinct
>             on-person)
>             trains
>             protocols, and
>             opportunity
>             applications
>             communications,
>             automobiles in
>             on-board
>             exit
>             However,
>             specified,
>             Email: [email-masked]
>             <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>,
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             Personal Homepage:
>             Email: [email-masked]
>             <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>,
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             Personal Homepage:
>     ------------------------------------------------------------------------
>
>     Avast logo
>     www.avast.com

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Apr 2016 15:20:10 +0200

Jong-Hyouk,

Le 19/04/2016 14:46, Jong-Hyouk Lee a écrit :
>> On Apr 19, 2016, at 9:35 PM, Alexandre Petrescu
>>>> On Apr 19, 2016, at 8:52 PM, Alexandre Petrescu
> Hmmmmm…I agree we need the terminology section in one document (I do not
> know which one would be good for the terminology section).

This is the current list.  Maybe in 1.

1. "Problem statement for IP in V2V and V2I"
    including "IP addressing architecture for V2V and V2I"
    and including "Gap Analysis: IP protocols suited and gaps"
    and including "Use-cases for IP in V2V and V2I moving network
    To nearby moving or fixed network"
2. "Threat Analysis for IP prefix exchanges in V2V and V2I
    Context"
3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document,
    including connectivity in fast and asymmetric conditions,
    coverage area vs speed diagrams, below-IP congestion
    management.
4. "List of papers and _products_ using IP in V2V and V2I"
5. "Solution for direct communication between Mobile Routers"

> Anyway, what
> you said is wrong.
>
> There are 4 types of cooperative ITS stations: Personal ITS station
> (e.g., smartphone), Vehicle ITS station, Roadside ITS station, and
> Central ITS station. Then, for example, at a vehicle ITS station, a
> vehicle ITS station gateway, ITS station host, and ITS station router
> may exist.

ITS station gateway - does not sound correct order of words(?)

What's the difference between ITS station router and ITS station gateway?

> Those are connected each other on the ITS station internal
> network. The vehicle ITS station gateway is connected to ECUs on
> propriety in-vehicle network. The ITS station router is the one used to
> connect to other side (e.g., Roadside ITS station or Internet). So, the
> mobile router we are calling here at the IETF is the ITS station router
> at the ISO/TC 204 standardisations.

Makes sense.

Alex

>>>>>>> <mailto:[email-masked]>
>>>>>>> <mailto:[email-masked]>
>>>>>>> <[email-masked] <mailto:[email-masked]>
>>>>>>> <mailto:[email-masked]>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 19 Apr 2016 22:32:16 +0900

Plz see inline, Alex.

> On Apr 19, 2016, at 10:20 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Jong-Hyouk,
> 
> 5. "Solution for direct communication between Mobile Routers”

Noted.

And, if needed, when I write the gap analysis part, I will provide the terminology section that lists up the terminologies being used at ETSI/ISO with corresponding terminologies being used at the IETF. 

> ITS station gateway - does not sound correct order of words(?)

That’s been written at ISO documents. ;)

> What's the difference between ITS station router and ITS station gateway?

The ITS station router is the router used to connect to outside (e.g., to other vehicles’s ITS station router, or to the Internet via the roadside ITS station). In other words, the ITS station router is the mobile router (with the NEMO concept). The ITS station gateway is the gateway connecting to ECUs on a propriety in-vehicle network (e.g., CAN). As I mentioned, on the ITS station internal network, the three entities (i.e., ITS station router, ITS station gateway, and ITS station host) are connected.

Cheers.

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 19 Apr 2016 15:32:04 +0100

Dear Jerome,

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

> stands for vehicular communications...

​I do not think so! All the IoT definitions mention things or objects and
in the majority of cases these things will be energy constrained , which is
not the case of vehicular networks. As far as I know, the MAC layer for
vehicular networks have been standardized by IEEE (among others), which is
IEEE802.11p (doesn't exist anymore !). Is this the case for IoT ?

> where IoT traffic from embedded sensors (CAN or non-CAN) are sent to an IoT
> server on Internet via ITS-G5/DSRC communication. IoT here is the
> architecture (oneM2M) that is above a specific technology, not a technology
> itself (you are maybe referring to SigFox or LTE-sensors I guess)..
>

​I can agree in this case!
​

so, our system works if we use another technology and would even need to
work if we have multiple technologies on the path between the sensors and
the  ‘cloud’…here, IPv6 take all of its sense.

​makes sens!

​

The IoT differences in ‘routing, energy consumption, mac layer’ as you said
are actually either fully relevant to the charter, as referring to
IPv6-over-foo or fully irrelevant to IPv6 (as based on IoT
application-level traffic).

Instead of debating whether we should add IoT or keep vehicular
communication, we should debate of what kind of traffic (M2M-like, stream?,
unicast/multicast etc..) will be transiting through IPv6 communication from
a ‘vehicle’ to either Internet or another ‘vehicle’.

​This is another debate indeed.​

And I would like to mention that my suggestion is not to reduce the focus,
but actually to focus on an aspect, where IPv6 does not have a competitor
and can really make a difference.

Said simple: if the charter addresses primarily IPv6 for critical safety
communications, this will be difficult to sell, as other simpler solutions
already work without IPv6.

I would therefore support and even propose to have a draft  formulating the
problem related to “IoT-over-IPv6 on moving networks”.

​It's an interesting work but outside the current charter ​

​!​

Best Regards,

Jérôme

Envoyé de mon iPad

*De:* its [mailto:[email-masked] <[email-masked]>] *En nombre
de *Nabil Benamar
*Enviado el:* lunes, 18 de abril de 2016 4:55
*Para:* Alexandre Petrescu <[email-masked]>
*CC:* [email-masked]
*Asunto:* Re: [its] charter ITS - proposed work items

Hi All,

Best regards

Nabil Benamar

-------------------

نبيل بنعمرو

ITSers,

What do you think?

Alex and Dapeng

Paul,

Cheers,

Jérôme

Jérôme,

I got it :-)

by a personal message.

Thanks.

Paul

Hi Paul,

Cheers,

Jérôme

Hi Jérôme,

in the industry.

ideas of the papers.

Thanks.

Best Regards,

Paul

Dear ITSers,  Dear Alex,

My two cents..

Best Regards,

Jérôme

ITSers,

Other comments?

Alex

              ITS (name to change)
                    Charter
              April 6th, 2016

Chairs:
    TBD

Assigned Area Director:
    TBD

Mailing list

Additional web page
    TBD

Charter:

Goal
----

Why IP?
-------

Scenarios?
----------

What kind of solutions?
-----------------------

Work Items
----------

Timeline
--------
-

--

--

------------------------------

El software de antivirus Avast ha analizado este correo electrónico en
busca de virus.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 19 Apr 2016 14:04:51 -0700

> What's the difference between ITS station router and ITS station

Gateway, router and hub used to be synonymous (back in '70s).  But

- gateway usually means layer 7 gateway -- a translation between
internet (i.e. IP) and something else.  The most ubiquitous layer 7
gateways are those in telco central offices which translate from IP to
POTS phone (to keep the local loop unchanged).

- router.  Eats IP datagrams, spits them back out another port.
 Strictly layer 3 functions.  Terminology abuse usually results from
mixing in layer 1/2 functions.  

- switch.  layer 2 bridge.

IEEE 802.16 (and probably mirrored in TIA LTE) is the notion of
subscriber station and base station.  SS and BS.  This is strictly a
layer 2 issue, nothing to do with routing.
     Important because radio is a shared medium and most of terrestrial
internet is point-to-point.  

IEEE 802.11 has similar namecalling: what 802.16 calls BS is called
access point (AP).  What you don't want to do is fall into the
marketing trap of a 'wifi router'.  Both AP and routing functions are
bundled into the same box.  That's a packaging issue, not a protocol
one.  

Getting >1 layer function into a definition is probably a poor idea
because then you can't change one thing without addressing all of them.
 Life cycle maintainability ran around on modularity shortcomings.
 (terms like 'road side units' have this shortcoming because they have
multiple layer (usually 2 and 3) functions in the box.  It's ok to
manufacture this way, but it's not a good way to write the protocols.

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Thu, 21 Apr 2016 13:10:15 +0900

Hi 

> On Apr 21, 2016, at 7:44 AM, Richard Roy <[email-masked]> wrote:
> 
> To expand a bit on Rex's comments, an ITS station (mobile) router is an
> entity that manages (IP(v6)) connectivity at layer 3 in an ITS-S.  An ITS
> station gateway is a component of an ITS-S that has two main functions: 1)
> network and transport layer protocol translation where necessary (as noted
> below), and most importantly, 2) firewall (security) provisioning which
> prevents unauthorized access to the ITS-S (which is DEFINED AS a bounded,
> secure, managed domain!).

Just to be clear, the ITS station gateway cannot provide the firewall function to the ITS station host and router; it provides the firewall function to the ECUs on the proprietary in-vehicle network.

J.

>  It is this security functionality that is
> critical to the success of many envisaged ITS services.
> 
> Hope this helps ...
> 
> RR
> 
>> From: Rex Buddenberg [mailto:[email-masked]]
>> Sent: Tuesday, April 19, 2016 2:05 PM
>> To: Alexandre Petrescu; Jong-Hyouk Lee

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Apr 2016 10:26:08 +0200

Hi,

The terms of "ITS station" will need to be agreed on, and defined in the 
Terminology section of a draft.

But now, when writing charter text, I need the following terms:

V2V - vehicle to vehicle communications
V2Internet - vehicle to Internet-at-large communications
V2I - vehicle to immediate infrastructure communications
I2V - infrastructure to a vehicle passing by

I hope these terms make sense to you too.

Alex

Le 21/04/2016 06:10, Jong-Hyouk Lee a écrit :
> Hi -- Jong-Hyouk Lee, living somewhere between /dev/null and
>> To expand a bit on Rex's comments, an ITS station (mobile) router
>> is an entity that manages (IP(v6)) connectivity at layer 3 in an
>> ITS-S.  An ITS station gateway is a component of an ITS-S that has
>> two main functions: 1) network and transport layer protocol
>> translation where necessary (as noted below), and most importantly,
>> 2) firewall (security) provisioning which prevents unauthorized
>> access to the ITS-S (which is DEFINED AS a bounded, secure, managed
>> domain!).
>
> Just to be clear, the ITS station gateway cannot provide the firewall
> function to the ITS station host and router; it provides the firewall
> function to the ECUs on the proprietary in-vehicle network.
>
> J.
>
>> It is this security functionality that is critical to the success
>> of many envisaged ITS services.
>>
>> Hope this helps ...
>>
>> RR
>>
>>> -----Original Message----- From: Rex Buddenberg
>>> [mailto:[email-masked]] Sent: Tuesday, April 19, 2016 2:05
>>> PM To: Alexandre Petrescu; Jong-Hyouk Lee Cc: Thierry Ernst;
>>> [email-masked]; Sri Gundavelli (sgundave) Subject: Re: [its]
>>> internet (i.e. IP) and something else.  The most ubiquitous layer
>>> 7 gateways are those in telco central offices which translate
>>> from IP to POTS phone (to keep the local loop unchanged).
>>>
>>> Strictly layer 3 functions.  Terminology abuse usually results
>>> from mixing in layer 1/2 functions.
>>>
>>> subscriber station and base station.  SS and BS.  This is
>>> strictly a layer 2 issue, nothing to do with routing. Important
>>> because radio is a shared medium and most of terrestrial internet
>>> is point-to-point.
>>>
>>> IEEE 802.11 has similar namecalling: what 802.16 calls BS is
>>> called access point (AP).  What you don't want to do is fall into
>>> the marketing trap of a 'wifi router'.  Both AP and routing
>>> functions are bundled into the same box.  That's a packaging
>>> issue, not a protocol one.
>>>
>>> Getting >1 layer function into a definition is probably a poor
>>> idea because then you can't change one thing without addressing
>>> all of them. Life cycle maintainability ran around on modularity
>>> shortcomings. (terms like 'road side units' have this shortcoming
>>> because they have multiple layer (usually 2 and 3) functions in
>>> the box.  It's ok to manufacture this way, but it's not a good
>>> way to write the protocols.
>>>
>>>
>>
>>
>
>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Thu, 21 Apr 2016 17:31:48 +0900

To me, those are fine.

> On Apr 21, 2016, at 5:26 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi,
> 
> The terms of "ITS station" will need to be agreed on, and defined in the Terminology section of a draft.
>

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 21 Apr 2016 09:46:44 +0100

Hi All,

I agree on the terms proposed and defined by Alex.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Apr 2016 11:49:22 -0400

> You ask whether the draft proposes IPv6 mainly for safety-criticial apps: no, the current text uses other motivators for IPv6.

I think that the answer to this question belongs in an update to the Goals in the draft charter text.

At the BOF, I heard several people point out that there are many safety communications that will not use IPv6.  The charter text needs to recognize this situation by saying that those single-hop V2V and V2I communications are out of scope for this effort.  After all, those are being standardized elsewhere, and this effort should not overlap with them.

The current draft charter says that the goal of this effort is to:

I throw this out to start discussion:

   Some vehicle communications will not use IP, including safety
   messages with other vehicles and infrastructure.  Other vehicle
   communications will be IP-based protocols, especially when multiple
   applications need to share one data link.  This group will develop
   IP-based protocols to establish direct and secure connectivity
   between a vehicle, which are often comprised of moving networks,
   and other vehicles and stationary systems.  Some communications will
   be extremely short lived, but others will last for many hours or days.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Apr 2016 16:54:41 -0400

Richard:

>> At the BOF, I heard several people point out that there are many safety
>> communications that will not use IPv6.  The charter text needs to
>> recognize this situation by saying that those single-hop V2V and V2I
>> communications are out of scope for this effort.  After all, those are
>> being standardized elsewhere, and this effort should not overlap with them.
>> 
> [RR>] Fair enough, however to indicate that a "moving network" is "fixed
> permanently" begs the question of the definition of a "moving network":^))
> That is: How can a "moving network" be "permanently fixed"???

I think that the text proposed below resolves this point you raise.

> [RR>] Perhaps it would make sense just to focus on those use cases where IP
> has value and simply ignore those where it may not be used. By mentioning
> applications and services to which IP is not well-suited just confuses
> people without adding any value to the discussion or the effort. Also, I
> believe in several places above where there is reference to communication
> life-times what is really meant is "communication session" life-times and
> "session (layer) continuity using IP networking”.

I think the we need to declare that as out oaf scope for this effort in some place in the charter.  If you do not think that is the goals section, please suggest another place that makes more sense to you.

Russ

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 22 Apr 2016 13:55:27 +0200

Le 21/04/2016 22:54, Russ Housley a écrit :
> Richard:
>
>>
>>>
>>>> You ask whether the draft proposes IPv6 mainly for
>>>> safety-criticial apps: no, the current text uses other
>>>> motivators for IPv6.
>>>
>>> At the BOF, I heard several people point out that there are many
>>> safety communications that will not use IPv6.  The charter text
>>> needs to recognize this situation by saying that those single-hop
>>> V2V and V2I communications are out of scope for this effort.
>>> After all, those are being standardized elsewhere, and this
>>> effort should not overlap with them.
>>>
>>> establishing direct and secure connectivity between moving
>> [RR>] Fair enough, however to indicate that a "moving network" is
>> "fixed permanently" begs the question of the definition of a
>> "moving network":^)) That is: How can a "moving network" be
>> "permanently fixed"???
>
>>> communications will be IP-based protocols, especially when
>>> multiple applications need to share one data link.  This group
>>> will develop IP-based protocols to establish direct and secure
>>> connectivity between a vehicle, which are often comprised of
>>> moving networks, and other vehicles and stationary systems.  Some
>>> communications will be extremely short lived, but others will
>>> last for many hours or days.
>>>
>>> Russ
>>
>> [RR>] Perhaps it would make sense just to focus on those use cases
>> where IP has value and simply ignore those where it may not be
>> used. By mentioning applications and services to which IP is not
>> well-suited just confuses people without adding any value to the
>> discussion or the effort. Also, I believe in several places above
>> where there is reference to communication life-times what is really
>> meant is "communication session" life-times and "session (layer)
>> continuity using IP networking”.
>
> I think the we need to declare that as out oaf scope for this effort
> in some place in the charter.  If you do not think that is the goals
> section, please suggest another place that makes more sense to you.

I propose the following paragraph towards the end of the Charter:

This group will not work on V2V or V2I use-cases where IP is not 
well-suited, including safety messages with other vehicles and 
infrastructure.

Is it ok?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 22 Apr 2016 13:57:14 +0200

Le 22/04/2016 01:53, Richard Roy a écrit :
> I'd like to suggest that the strict focus on ITS may be leading the
> discussion astray somewhat.  ITS is clearly an important use case
> (and should be highlighted as such in the "reasons for doing this
> work" document), but IPv6 mobility is generally important in other
> application areas as well.

I agree.

To that end we may say 'moving network' rather than 'in-vehicle network'.

And we accommodate networks deployed in trains as well: wagon-to-wagon
IP communications is similar to vehicle-to-vehicle communications.

And there is interest in PAN-to-homenet, as much as there is interest in
PAN-to-car communications.

> Furthermore, doing an ITS TVRA is clearly out of scope of any IETF
> effort I would think.

(TVRA - Threat Vulnerability Risk Assessment?).

Certainly no generic ITS TVRA to be performed here - it is too much, and 
too specific to many other protocol layers of vehicular communications: 
PHY, MAC, transport, applications.

But as with any new IETF protocol (not necessarily ITS), we need to be 
explicit about the new security threats induced by that new protocol.

In particular, if we assume for a moment IP prefix exchanges between
moving networks: this creates a new privacy risk in which a nearby
moving network learns all IP addresses of this moving network; a car
learns all IP addresses of the other car.

Similarly, if we assume for a moment the use of (m)DNS between moving 
networks, there may be new threats introduced (compared to the current 
situation where a vehicle uses a DNS server fixed in the infrastructure).

These two aspects must be part of the Threat Analysis work item.

> I'd suggest using ITS communications as a key use case, then going on
> to leave ITS behind and simply discuss the need for IPv6 mobility
> support in rapidly varying RF and topological environments along with
> a general need to address security issues, and leave it at that.

It makes sense.

But beware the term "IP mobility".  It has a particular meaning at IETF: 
it means the Mobile IP protocol.  The Mobile IP protocol can not be used 
in a V2V setting.

"IP mobility" at IETF may also be understood as the DMM working group 
(Distributed Mobility Management).  That deals mainly with 
infrastructure entities, not moving networks.  Especially no direct 
links between moving networks in DMM.

Alex

> My two cents ...
*From:*Jong-Hyouk Lee [mailto:[email-masked]] *Sent:* Monday,
> April 18, 2016 12:32 AM *To:* Alexandre Petrescu *Cc:* [email-masked]
> *Subject:* Re: [its] charter ITS - proposed work items
>
> Thx, plz see inline.
>
> -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
>>> context”
>> Is this mean that this group first go for this and later considers
>> a general security document (e.g., security requirements for ITS)
>> ?
>>
>>
> Ok. For the document “Threat Analysis of IP prefix exchanges in V2V
> and V2I”, I just started to work on. Soon I will post.
>
>
>
>
> requirements for ITS that corresponds the document “PS for IP in V2V
> and V2I”. We will be later. ;)
>
> Good day!
>
>
>
>
> Alex
>
>
>
> Cheers.
>
>
>
> RFC2464 "Transmission of IPv6 Packets over Ethernet Networks", where
> Thanks. Btw, when I mentioned ‘people’ are aware of IP V2V but not
> see the need (so far), I referred to the automotive SDOs (led by
> automotive industries)…, although there are always ‘minority
> reports’ J
>
> Cheers,
>
> Jérôme
>
> Alexandre Petrescu; [email-masked] <mailto:[email-masked]> *Subject:* Re:
> [its] charter ITS
>
> Jérôme,
>
> likely the IoT industry…and as such, we should not need to have the
> (direct) involvement of automotive industry in the Charter. If we can
> make this clear by an industry-based ‘survey’, that would help make
> the case for the WG.
>
> <mailto:[email-masked]> <mailto:[email-masked]> *Subject:* Re: [its]
> charter ITS
>
> Hi Jérôme,
>
> _definition of a vehicular wireless ‘link’ in an automotive context_
>
> that are in vehicles and are using IPv6, possibly suffering from a
> silo limitations (ex. restricted to a single technology, single use
> case…)
>
> <mailto:[email-masked]> <mailto:[email-masked]> *Subject:* [its] charter
> ITS
>
> ITSers,
>
>>>  vehicles of all types are increasingly connected to the
>>> Internet, either as vehicle-to-vehicle, vehicle-to-infra or

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 22 Apr 2016 14:12:07 +0200

ITSers,

This is the latest charter text.

Yours,

Alex

-----------------------------------------------------------------
       Intelligent Transportation Systems (its)

Chairs:
    Russ Housley
    Carlos Pignataro

Assigned Area Director:
    Suresh Krishnan

Mailing list
    Address: [email-masked]

Additional web page
    TBD

Charter

Automobiles and vehicles of all types are increasingly connected to the 
Internet.  Comfort-enhancing entertainment applications, road safety 
applications based on data exchanges, and connected automated driving 
are but a few new features expected in automobiles to hit the roads from 
now to year 2020.

Today, there are several deployed Vehicle-to-Internet technologies 
(V2Internet) that make use of embedded Internet modules, or through 
driver's cellular smartphone (mirrorlink, carplay, android auto). 
However, Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) 
communications are still being developed.

Some vehicle communications will not use IP, including safety messages 
with other vehicles and infrastructure.  Other vehicle communications 
will be IP-based protocols, especially when multiple applications need 
to share one data link.  This group will develop IP-based protocols to 
establish direct and secure connectivity between a vehicle, which is 
often comprised of moving networks, and other vehicles and stationary 
systems.  Some communications will be extremely short lived, but others 
will last for many hours or days.

The group is concerned with situations involving moving network to 
nearby moving (or fixed) network communications (V2V, V2I, I2V).  For 
example: a moving network in a vehicle communicating to another moving 
network in a nearby vehicle (C-ACC, Platooning, or temporarily fixed at 
an incident scene); a personal area network carried by a user and 
connecting to an in-house fixed network (homenet); an in-car networked 
device receiving messages from a road-side display when passing by, 
wagon-to-wagon range extension in a train; train-to-intersection 
signalling.  In these loop-free 1-IP-hop topologies there is a problem 
of establishing IP paths quickly and reliably.

Improved safety is an immediate result of hyper-connectivity of 
vehicles; as such public authorities worldwide are increasingly 
mandating secure communication technology requirements in vehicles. 
Emergency applications for instrumented ambulances carry many benefits 
both to the users and to society in general.  For these reasons, a 
solution to the problem of establishing IP paths between nearby moving 
networks will be resilient to threats such as eavesdropping.

Moving network to nearby moving or fixed network communications
may involve several kinds of link layers: 802.11-OCB (Outside the 
Context of a Basic Service Set), 802.15.4 with 6lowpan, 802.11ac, VLC 
(Visible Light Communications), IrDA, LTE-D, LP-WAN.  One of the most 
used link layers for vehicular networks is IEEE 802.11-OCB, as a basis 
for DSRC.  However, IPv6 on 802.11-OCB is not yet  defined.

The group will leverage on technologies for Internet of Things (IoT) 
which are developed in other IETF efforts: 6lo, LP-WAN, T2T.

The SDOs interested in this work are: ISO/TC204, ETSI TC ITS, 3GPP, 
NHTSA and more.

If the group is successful in designing a simple 1-IP-hop solution for 
V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then 
future extensions for n-IP-hop V2V2I may be considered.

Work items

3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document,
    including connectivity in fast and asymmetric conditions,
    Coverage area vs speed diagrams, below-IP congestion
    management.

5. “Solution for direct communication between Mobile Routers”

Goals and milestones

Oct 2016 - submit “Problem Statement” to WG
Oct 2016 - submit “List of papers and products” to WG
Feb 2017 - submit “Threat Analysis” to WG
Feb 2017 - submit “IP over DSRC (802.11-OCB)” to WG
Jun 2017 - submit “Solution for direction communication between
                    Mobile Routers” to WG
Oct 2017 - start submitting to IESG

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Apr 2016 12:53:27 +0000

> On Apr 22, 2016, at 7:55 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

I particularly liked the clarification at the top in the relevant paragraph, and not at the end — unless this final sentences is intended to be a recap.

> This group will not work on V2V or V2I use-cases where IP is not well-suited, including safety messages with other vehicles and infrastructure.
> 

What is “well-suited”? And how is that determined?

To me, there’s two areas to narrow-scope the effort. First, a small but concrete set of areas like the one in this discussion — but not a broad brush of ‘where not well-suited’; and second, where other SDOs are working on it.

Thanks,

Carlos.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Apr 2016 13:44:04 +0200

Le 22/04/2016 18:46, Richard Roy a écrit :
>> Sent: Friday, April 22, 2016 4:57 AM
>> To: [email-masked]; 'Jong-Hyouk Lee'
>> Cc: [email-masked]
> [RR>] Since the wagons don't change relative position while in use, networks
> in trains are local area networks that change their point of attachment to
> WANs at a rate related to their velocity (it's really more like V2I in that
> context.)

In principle yes, that's more like V2Internet.

On another hand:
- in some wagons there is a need to avoid add new Ethernet cable
   between wagons.  This leads to use WiFi to inter-connect wagons, in
   addition to the WiFi given to passengers.  That's more of the kind
   V2V than V2Internet.
- on-board networked equipment sending messages when passing at
   fixed network equipment ("beaconing") can not happen with a
   V2Internet technique, because of latency.  It needs to happen in a
   more V2V straight manner.

My point is that if someone intends to apply the technology developped 
by this group in train communications one can spot precisely some of the 
pertinent areas: wireless wagon-to-wagon communications, train to 
crossroads communications, etc.

[..]

> [RR>] Interesting ... sounds like whatever the ITS group does should be
> liaised/coordinated with the DMM WG perhaps?

Noted: coordinated.

Alex

>>> Hum.then, the document will be too broad. We may need people to work
>>> on each part.
>>>
>>>>
>>>>
>>>>> context"
>>>> For now it is "Threat Analysis for IP prefix exchanges in V2V and
>>>> V2I context".
>>>>
>>> Ok. For the document "Threat Analysis of IP prefix exchanges in V2V
>>> and V2I", I just started to work on. Soon I will post.
>>>
>>>
>>>
>>>
>>> requirements for ITS that corresponds the document "PS for IP in V2V
>>> and V2I". We will be later. ;)
>>>
>>> Good day!
>>>
>>>
>>>
>>>
>>> Alex
>>>
>>>
>>>
>>> Cheers.
>>>
>>>
>>>
>>> Thanks. Btw, when I mentioned 'people' are aware of IP V2V but not
>>> automotive industries)., although there are always 'minority
>>> reports' J
>>>
>>> Cheers,
>>>
>>> Jérôme
>>>
>>> that IP _can_ be used for V2V and V2I, but does not '_need_' to be
>>> likely the IoT industry.and as such, we should not need to have the
>>> make this clear by an industry-based 'survey', that would help make
>>> the case for the WG.
>>>
>>> _definition of a vehicular wireless 'link' in an automotive context_
>>>
>>> case.)

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Apr 2016 13:52:26 +0200

Le 22/04/2016 18:38, Richard Roy a écrit :
> If you want to add something like:
>
> " This group will not work on V2V or V2I use-cases where IP is not
> infrastructure."
> might I suggest:
> "This group will work on V2V and V2I use-cases where IP is
> well-suited as a networking technology, including applications involving
> exchange of safety-related messages with other vehicles and
> infrastructure where use of IP is advantageous."
>
> No need to be negative.  Stating all the things the project will NOT do
> would be a "never-ending story" and is really not useful.

Noted, included.

(without being negative, it's good in a charter and in documents to
  state what it does _and_ what it does not)

Alex

>> Sent: Friday, April 22, 2016 4:55 AM
>> To: Russ Housley; [email-masked]
>> Cc: [email-masked]
>>>> continuity using IP networking".
>>>