Subject: [its] Charter Comments

From: "Francois Simon" <[email-masked]>
Date: Fri, 19 Aug 2016 16:09:05 -0400

>From Francois Simon

Charter Comments

CHARTER

Automobiles and vehicles of all types are increasingly connected to the
Internet.  Comfort-enhancing entertainment applications, road safety
applications using bidirectional data flows, 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, not to
be mistaken with V2Internet) communications are still being developed.

Some vehicle and infrastructure communications will use IP and others will
not.  Multiple applications need to share one data link, including
non-IP-based protocols sharing the data link with IP-based protocols.

Fygs - It is assumed that "data link" here is per ISO/IEC 7498-1 standard
definition and not a particular medium channel. Multiple data link instances
may use a common medium channel, as well as a single data link instance my
use multiple media.

This group will work on V2V and V2I use-cases where IP is well-suited as a
networking technology, supporting also applications that involve exchanges
of safety-related messages between vehicles and infrastructure if necessary.

Fygs - Safety-related messages may require to be prioritized based on the
source application requirements. (e.g,. announcement of weather conditions
10 km ahead will not have the same urgency than a stopped vehicle 300 m
ahead). Depending on the application's priority, decision to use IP or other
protocol needs to be assessed.

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.

Moving network to nearby moving or fixed network communications may involve
various kinds of link layers: 802.11-OCB (Outside the Context of a Basic
Service Set, also called 802.11p), 802.15.4 with 6lowpan, 802.11ad, 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.

Fygs - This paragraph brings in a vast array of questions related to the
actual scope of the group developing "IP-based protocols to establish
connectivity" between entities in motion and/or stationary. It is not the
intention here to open a philosophical discussion of the various entities
that may or may not be in scope, but merely to point out the need for
precise definitions of entities involved in the "connectivity". Follow are
few question examples which comes to mind (no particular order):

*         Does the entities in motion are related to vehicles only?

*         Does living entities and/or "things" in motion capable of
establishing IP connectivity are excluded?

o   One can argue that a conveyor belt is a "transportation system".  

*         Which mobile entities are excluded from the scope?

*         The same type of questions can apply to stationary systems:

o   Tethered or wireless land connectivity (i.e.; Free Space Optics (FSO)

*         Etc.

The list can be extensive.

The group will work only on IPv6 solutions.

The group will leverage on technologies for Internet of Things (IoT) which
are developed in other IETF and IRTF efforts: 6lo WG, LP-WAN WG, and T2T RG.
Co-existence with techniques of infrastructure mobility management will be
coordinated with the DMM WG, LISP WG, and other mobility solutions.

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

This group will not work on V2V or V2I use-cases where IP is not
well-suited.  Without re-chartering, this group will not work on
Delay-Tolerant Networking nor on Information-Centric Networking.

If the group is successful in accomplishing its first goals, then it can be
rechartered to work on other things (examples include but are not limited
to: a 1-hop mechanism of IP prefix exchange between moving networks, an
n-hop extension, naming for moving networks; generalization for trains, air,
unmanned and space use-cases).

WORK ITEMS

1. Standards Track RFC "IPv6 over 802.11p"

Fygs - As reference - It is believed that the actual IEEE Std 802.11p is no
longer available. This standard was the amendment of IEEE Std 802.11-2007.
The amendment has been incorporated in the current IEEE Std 802.11-2012.
Note that the clause references in 802.11-2012 are not in line with
802.11p-2010.

2. Potential Informational RFC "ITS General Problem Area" covering:
 - What is ITS?
    -- Explain V2V, V2I, and related terms
 - Why is IPv6 needed?
    -- Explain why some traffic will not use IPv6
    -- Explain why other traffic will use IPv6
 - Use-cases, illustrating the expected areas for initial focus
 - Informative references, relationship with other SDOs

3. Potential Informational RFC "Problem Statement" covering:
  - Problem statement
  - Security considerations
  - Privacy considerations

MILESTONES

Oct 2016 - Draft for "IPv6 over 802.11-OCB" adopted by WG

Dec 2016 - Draft for "ITS General Problem Area" adopted by WG

Mar 2017 - Draft for "Problem Statement" adopted by WG

May 2017 - Submit "IPv6 over 802.11-OCB" to IESG

Oct 2017 - Submit "ITS General Problem Area" to IESG

May 2018 - Submit "Problem Statement" to IESG

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 23 Aug 2016 17:19:33 +0200

Some comments...

> CHARTER

[...]

> Some vehicle and infrastructure communications will use IP and others
> will not.  Multiple applications need to share one data link,
> including non-IP-based protocols sharing the data link with IP-based
> protocols.
>
> */Fygs - It is assumed that “data link” here is per /**/ISO/IEC
> 7498-1 standard definition and not a particular medium channel.
> Multiple data link instances may use a common medium channel, as
> well as a single data link instance my use multiple media./**//*

ISO/IEC 7498-1 may be a good definition of a data link.

One can see data link also as an Ethernet cable, or a pipe, on which
_packets_ are multiplexed.

A single data link would not be run simultaneously on multiple channels.
  If interested in that, there is a 'banana' effort at IETF that deals
with such aspects.  (ietf.org/mailman/listinfo/banana).

If you are suggesting one should use here the term 'medium channel'
instead of 'data link', I think both are equal in my mind.

> This group will work on V2V and V2I use-cases where IP is
> well-suited as a networking technology, supporting also applications
> that involve exchanges of safety-related messages between vehicles
> and infrastructure if necessary.
>
> */Fygs – Safety-related messages may require to be prioritized based
> on the source application requirements. (e.g,. announcement of
> weather conditions 10 km ahead will not have the same urgency than a
> stopped vehicle 300 m ahead). Depending on the application’s
> priority, decision to use IP or other protocol needs to be
> assessed./** *

This prioritization may be a topic in the future.  I dont think at this
time anyone committed to work on prioritization.

Prioritization work can happen here after we got IP-over-80211-OCB right
(the first step), otherwise any other prioritization will be
specific to that particular SDO: MAC prioritization at IEEE, LTE
prioritization at 3GPP, and so on.

> 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.
>
>
> Moving network to nearby moving or fixed network communications may
> involve various kinds of link layers: 802.11-OCB (Outside the
> Context of a Basic Service Set, also called 802.11p), 802.15.4 with
> 6lowpan, 802.11ad, 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.
>
> */Fygs – This paragraph brings in a vast array of questions

The list of link layer technologies (instead of just one) is there to
suggest that this is heterogeneity and IP should be able to run on any
one of these, in the future.

Remark also we did not list any link layer technology that is not
pertinent to vehicular communications (e.g. FSO).

Again, _if_ IPv6-over-80211-OCB gets done, then people may get
interested in doing moving network to moving network communications
(direct vehicle-to-vehicle, IP direct over MAC); _if_ so there can be
interest in doing moving network to moving network using other than
802.11-OCB technology: send IP over Visible Light Communications between
vehicles, instead of blinking lights.

> related to the actual scope of the group developing “IP-based
> protocols to establish connectivity” between entities in motion
> and/or stationary. It is not the intention here to open a
> philosophical discussion of the various entities that may or may not
> be in scope, but merely to point out the need for precise
> definitions of entities involved in the “connectivity”. Follow are
> few question examples which comes to mind (no particular order):/*
>
> ·         */Does the entities in motion are related to vehicles
> only?/*

At this time the main thrust comes from the automobile industry.  But
the technology can well be applied in other objects that move with
respect to each other, provided they use IP (Internet Protocol).  Water,
air and space systems have been mentioned on the list.

> ·         */Does living entities and/or “things” in motion capable of
> establishing IP connectivity are excluded?/*

Well, living entities would first need to implement IP, which is not
known other than in April's fool fictitious IP-over-avian-carriers.

Things, like in Internet-of-Things, or car-as-a-sensor are in scope.

> o   */One can argue that a conveyor belt is a “transportation
> system”.  /*
>
> ·         */Which mobile entities are excluded from the scope?/*

At this time, some mobile entities are known to not implement
802.11-OCB, and no perspective: smartphones.

> ·         */The same type of questions can apply to stationary
> systems:/*
>
> o   */Tethered or wireless land connectivity (i.e.; Free Space Optics
> (FSO)/*

FSO sounds like it needs sides precisely aligned.  During Earthquake
their communication would stop, without any possible help from software,
but rather re-align the mechanics.  For this reason I think they're out
of scope here.

> ·         */Etc./*
>
> */The list can be extensive./*

We can see.

[...]

> */Fygs – As reference - It is believed that the actual IEEE Std
> 802.11p is no longer available. This standard was the amendment of
> IEEE Std 802.11-2007.  The amendment has been incorporated in the
> current IEEE Std 802.11-2012.  Note that the clause references in
> 802.11-2012 are not in line with 802.11p-2010/**.*

Yes, there is awareness of this movement away from the 802.11p term.

That begs a related question: would one consider the new 802.11ad
standard in 'old 11p' conditions such as Out of the Context of BSSID, in
a 5.9GHz channel, and with a half-rate encoding?  That would give an
attractive 3.5Gbit/s instead of 16Mbit/s of existing 11p trials.

Alex