[its] Updated charter (small correction)

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 19 February 2016 18:29 UTC

Return-Path: <alexandre.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 78FA01B2A9C for <its@ietfa.amsl.com>; Fri, 19 Feb 2016 10:29:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.982
X-Spam-Level:
X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 jbOjJuJlB8Y7 for <its@ietfa.amsl.com>; Fri, 19 Feb 2016 10:29:03 -0800 (PST)
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 4D54D1ABC10 for <its@ietf.org>; Fri, 19 Feb 2016 10:29:02 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u1JIT0Qg004968 for <its@ietf.org>; Fri, 19 Feb 2016 19:29:00 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8F9162087B6 for <its@ietf.org>; Fri, 19 Feb 2016 19:29:01 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 81F0A2086B5 for <its@ietf.org>; Fri, 19 Feb 2016 19:29:01 +0100 (CET)
Received: from [132.166.84.68] ([132.166.84.68]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u1JISx5Q005710 for <its@ietf.org>; Fri, 19 Feb 2016 19:28:59 +0100
To: "its@ietf.org" <its@ietf.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <56C75EEA.6010506@gmail.com>
Date: Fri, 19 Feb 2016 19:28:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------030804010105050109030804"
Archived-At: <http://mailarchive.ietf.org/arch/msg/its/CIVK4yKJYkup5yLMRX6op3iMsR4>
Subject: [its] Updated charter (small correction)
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ITS at IETF 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: Fri, 19 Feb 2016 18:29:06 -0000

Updated charter to refer to in the BoF request.

Alex


---------------------------------------------------------------
              ITS (name to change)
                    Charter
              February 19th, 2016
          http://ietf.org/mailman/listinfo/its


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

Chairs:
    TBD

Assigned Area Director:
    TBD

Mailing list
    Address: its@ietf.org
    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 protocols for establishing
direct and secure connectivity between moving networks.

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.  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
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
- Security and Privacy Requirements for moving network to
   nearby moving network communications
- Problem Statement for moving network to infrastructure network
   communications, including DNS
- Potentially new protocol, or protocol extensions for establishing IP
   paths for 1-hop moving network to nearby moving network communications.
   With MIB and security.
- 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)

Timeline
--------
-