[geonet/its] charter proposal

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 16 July 2015 12:20 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E951A896F for <its@ietfa.amsl.com>; Thu, 16 Jul 2015 05:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.283
X-Spam-Level:
X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o7-HHVvNKcL for <its@ietfa.amsl.com>; Thu, 16 Jul 2015 05:20:36 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672151A896D for <its@ietf.org>; Thu, 16 Jul 2015 05:20:36 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6GCKU87030462; Thu, 16 Jul 2015 14:20:30 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DDE33203CC0; Thu, 16 Jul 2015 14:23:57 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D089C203BF4; Thu, 16 Jul 2015 14:23:57 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6GCKTgk025757; Thu, 16 Jul 2015 14:20:30 +0200
To: "its@ietf.org" <its@ietf.org>
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Message-ID: <55A7A18D.4020407@gmail.com>
Date: Thu, 16 Jul 2015 14:20:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/its/epfyQZkywJsg7FxtnS-BmtLJh8I>
Cc: "刘大鹏(鹏成)" <max.ldp@alibaba-inc.com>
Subject: [geonet/its] charter proposal
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GeoNet BoF discussion list." <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2015 12:20:43 -0000

Hello,

We will discuss this charter proposal in Prague.

Alex

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

Goal
----
Establishing direct and secure IP connectivity between a few vehicles
in close range is the goal of this group.

Intro
-----
Automobiles and vehicles of all types are increasingly connected to
the Internet.  Entertainment apps enhancing comfort on-board, reliable
data exchanges for road safety, and automated driving, are highly
appreciated marketing arguments for automobiles to hit the roads from
now to year 2020.  Emergency apps for new instrumented ambulances
carry many benefits both to the users and to society in general.

Why IP?
-------
Whereas the Vehicle-to-Infrastructure technologies are considered
completed and deployed in currently sold automobiles (e.g. car
tethering through driver's cellular smartphone, or SIM in On-Board
Unit, or cellular USB dongle, with NAT/DHCP and potentially Mobile
IP), the Vehicle-to-Vehicle communications are still in an infancy
stage: primitive link-specific data exchanges are limited to a
non-harmonized and limited set of applications, such as ETSI's
CAM/DENM presence signalling.  On another hand, the industry needs to
employ IP data exchanges between vehicles rather than link-specific
exchanges, in order to benefit from the reuse of a huge number of a
desktop Internet applications in a vehicular environment (extend the
Internet to mobile platforms).

Scenarios?
----------
Some of the scenarios needing IP V2V communications are: Cooperative
Adaptive Cruise Control and Platooning of vehicles.  In the emergency
landscape other applications exhibiting a need for V2V comms are also
important: virtual siren - emergency vehicle multicasting a radio
warning to nearby vehicles to make place.

How is V2V vs V2I?
------------------
Establishing direct and secure IP connectivity between a few vehicles
in close range is the goal of this group.  V2V is more than simply
connecting a vehicle to the Internet (V2I).  Because it needs a
peer-to-peer manner of IP route establishment between equally-potent
Routers in vehicles, in such a way to not disturb the V2I
communications already in place.  This manner is a step forward from
known V2I Host-to-Router or Client-to-Server paradigms (protocols
Neighbor Discovery, DHCP, ppp, Mobile IP, and similar).

What kind of solutions?
-----------------------
The current technical solutions considered to achieve IP V2V
communications are of two kinds: IP routing protocols for n-hop path
establishment between vehicles (e.g. Babel, OSPF, others) and 1-hop
link-scoped IP protocol enhancements (such as route establishment with
ICMP Router Advertisements).

There is a concern in sending IPv6 packets over the current ETSI
geonetworking protocols, with risks of the channel being swamped due
to inefficiencies of the protocol, or simply due to communication
abuse.

What kind of requirements?
--------------------------
The keyhole applications C-ACC, Platooning and virtual siren involve
IP multicast mechanisms.  The 1-hop IP V2V paths will gracefully
support IP multicast.  Due to the inherent characteristics of
safety-related communications, all new V2V 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 infrastructure, possibly via multiple radios.

Current version of Internet protocols
-------------------------------------
The version of the IP protocol is IPv6, to acommodate the current
generation of Internet protocols.  For backwards compatibility, IPv4
may be considered as well, but not exclusively.  Link-local addresses
will be used.

What SDOs may need this work?
-----------------------------
The requirements and standards for an Internet of Vehicles are
developed mainly at 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.
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-case and scenarios of C-ACC and Platooning at SDOs
- Problem Statement for IP V2V application communications
- Security and Privacy Requirements for IP V2V communications
- Potentially new protocol, or protocol extensions for establishing IP
   paths for 1-hop V2V communications.  With MIB and security.

Timeline
--------
- BoF in Yokohama
- Couple of work items submitted to IESG in November 2016.
- recharter to work on solution for IP V2V.