[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.
- [geonet/its] charter proposal Alexandru Petrescu