Subject: Re: [its] ITS Charter Comments

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Sep 2016 14:50:54 +0200

Hi,

Allow me to take advantage of the message on the list to reply publicly.

Le 31/08/2016 à 22:08, Francois Simon a écrit :
> Please, find my comments on the ITS charter (embedded in the initial text).
>
> If you have any questions, please do not hesitate to contact me.
>
> Sincerely,
>
> Francois y. Simon
>
> Pilot Research, Inc.
>
> Tel: 301-404-1663
>
>
>
> *Intelligent Transportation Systems (its), Charter*
>
> *Chairs*
>
> Russ Housley
> Carlos Pignataro
>
> *Assigned Area Director*
>
> Suresh Krishnan
>
> *Mailing list*
>
> 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>
> Archive: ​https://mailarchive.ietf.org/arch/search/?email_list=its
> <https://mailarchive.ietf.org/arch/search/?email_list=its>
>
> *Additional web page*
>
> TBD
>
> *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.
>
> [Fygs: Safety applications may not always require bidirectional data
> flows.  i.e.; Most Safety applications using DSRCS use unidirectional
> flow: source to sink.]

I can agree that some if not all DSRC messages are unidirectional.

I would like to add that realization of safety can happen (in addition 
to DSRC) through non-DSRC messages: Coyote messaging 
(vehicle-to-infra-to-vehicle) is using cellular links and it signals 
various safety-related events on the road.  Other demonstrated IP-based 
bidirectional messaging is for safety too: video streaming from front to 
rear vehicle for see-through applications to prepare safe overcoming of 
a vehicle.

So, I agree with you about DSRC unidirectionality, and I also think the 
above text should stay that way unless we have strong reason to change.

> 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.
>
>
>
> 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.
>
>
>
> 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.
>
> [Fygs: “…/between a vehicle, which is often comprise of moving
> network…/”. This section of the sentence is somewhat ambiguous:
>
> Is it intended to state that a vehicle may contains devices needing
> connectivity within the confinement of the vehicle? Which can be true.

YEs, that's the intention: each vehicle is comprised of at least two 
distinct IP subnets (if not more), and there are at least 32 distinct IP 
addresses within each vehicle.

> Within a vehicle moving in relation to the “outside world” (e.g.;
> highway), may also contain moving devices requiring connectivity (in a
> relatively limited space and communication range such as Bluetooth
> device); or

There are a few cases in scope:

- vehicle moves with respect to RSU
- vehicle following other vehicles, in a homogeneous manner
- vehicle moves with respect to incoming or overcoming vehicles
- user moves around stationary vehicle (remote door open)
- vehicles moves around stationary user

There are a few clarifications:
- if both user and vehicle move then it's at relatively low speed
   (5kmph)
- the road-side units are typically fixed while operated, although they
   may move during temporary road works.

These characteristics of movement could be further described in a 
document.  Would you be interested?

>
> Is it intended to imply that clusters of vehicles (“swarms”), in motion
> or stationary which communicate within a swarm may also require
> connectivity with individual vehicle, another swarm, and stationary
> systems? If this is intended, then the charter is entrenching in the
> realm of MANET, which may not be a “rabbit whole” the group wants to be in.]

We need to avoid rabbit holes, and ratholes.

In MANET there is no clear number of hops between end nodes.  In moving 
network-to-moving network communication of this group there are at most 
3, with the innovative protocol changes happening on only 1-hop: between 
immediately neighboring vehicles.

Each one of these moving networks has a stable fixed structure (there is 
little or no mobility _inside_ a vehicle while it moves).  In MANET 
there is no such stability.

We need to stay within this 1-hop protocol innovation, at most 3 hop in 
vehicle-to-vehicle (Host=Router-Router=Host).  That would keep us from 
holes.

> 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 – “/however, IPv6 on 802.11-)OCB is not yet defined/”
>
> First, OCB which is MIB attribute within 802.11 is an 802.11 link layer
> is an option and is not related to the network layer which may use the
> OCB services.

I agree.

'IPv6-on-80211OCB' text above is supposed to read like existing 
'IPv6-on-Ethernet' text in other IETF documents.

We heard 802.11p, then told 802.11p is no longer, so needed a name for 
this link-layer technology, so we proposed 802.11-OCB.  I understand 
"802.11-OCB" is not an IEEE term like 802.11b is, but we who put IP on 
it need a short name for it.  And 'OCB MIB attribute 802.11' is not a 
short name for a link layer.

I am still interested to hear better names to replace '802.11p'?

> IEEE 802.11p standard was carefully crafted so that DSRC
> or WAVE were NOT mentioned in the 802.11p standard.
>
> Second, FYI, IPv6 is included as a network layer service in the DSRC
> protocol stack; see IEEE 1609.3-2016. Note: It may not be as detailed as
> the IETF-ITS group would like but it is specified.]

I can agree.  But here a specification means something we could freely 
give to an implementer and write open-source running code for it.  The 
way IEEE talks about putting IPv6 on a network layer of DSRC is not 
something easy to implement.  BEsides it's not freely and publicly 
available.

> 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 group will coordinate with IEEE 802.11.  Other SDOs interested
>
> in this work include ISO/TC204, ETSI TC ITS, 3GPP, and NHTSA.
>
>
>
> 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.
>
>
>
> [Fygs: FYI: DTN starts to find its way for land based ITS applications.]

I can agree, there are demonstrations.  At this time in this group there 
is no interest.

> 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: See latest IEEE 1609
> series.}
>
>
>
>
>
>
>
> 2. Potential Informational RFC "ITS General Problem Area" covering:
>
>   - What is ITS?
>
>      -- Explain V2V, V2I, and related terms
>
> [Fygs: This a hard one as the three terms mentioned have been in use for
> almost two decades worldwide. The logic would dictate that the terms
> could be re-defined for today’s views but are likely to be changed by
> tomorrow….

We could work together to make a proposal.

> ITS:
>
> “/Intelligence/”: Can include anything from “human-hands-off” to
> Artificial Intelligence (AI).

Ah!

> “/Transportation/”: It varies from invention of the wheel, to conveyor
> belt, and would include skis and horse-and-buggy J….. Attempting a
> definition change would be a waste of resources and unproductive.  Let
> it lie!]
>
> “/V2V/”: Has been historically associated with communications between
> vehicles for Safety applications. Of course one can debate to infinitum
> the definition of “vehicles” which could change every day. For the
> purpose of this charter it is proposed and certainly can be modified by
> the group as required:
>
> /“Vehicle-to-vehicle (V2V) communication enables intention sharing among
> neighboring vehicles and thereby vehicles' motion can be coordinated to
> incorporate collision (or conflict) avoidance”./Intelligent Vehicles
> Symposium (IV), 2015 IEEE
> <http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=7180136>
>
> /“V2I”/:Same as above. The following is proposed and can be modified by
> the group as required:
>
> /Vehicle-to-Infrastructure (V2I) Communications for Safety is the
> wireless exchange of critical safety and operational data between
> vehicles and roadway infrastructure, intended primarily to avoid motor
> vehicle crashes./  USDOT
>
> /“V2X”/: Is a relatively new term.
>
> ·         It started  with V2X meaning [V2V + V2I];
>
> ·         Then, V2X meant V2-pedestrian, -bikes, and -others;
>
> ·         Since IOT became a buzz word, V2X became Vehicle-to-everything;
>
> ·         Lately, a sub-set of V2X become in vogue:
>
> o   V2P – Vehicle-to-Pedestrian
>
> o   V2D – Vehicle-to-Device
>
> o   V2G – Vehicle-to-Grid
>
> In any case, the following definition seems to be the consensus for now:
> “/Vehicle-to-everything (*V2X*) communication is the passing of
> information from a vehicle to any entity that may affect the vehicle,
> and vice versa/”.

It is a good point deserving expression in addition to others.

>   - Why is IPv6 needed?
>
>      -- Explain why some traffic will not use IPv6
>
> [Fygs: As DSRC is concerned, exchange of Safety applications data must
> be done as close to “real-time” as possible. Anything which affect the
> end-to-end latency (source to sink) must be kept to minimum (data
> payload size, protocol overhead size, processing time, etc.). Note that
> a vehicle traveling at 200 km/h move toward the event horizon at 55 m/s.]

Noted.

Remark, this is the typical text we hear from many sources.  If we 
analyze the text closely we see oranges compared to apples.  If only we 
could do orange-orange.

Keeping data payload size minimum - use reduced-size IP packets and 
avoid unnecessary headers.
Protocol overhead size - what is it?
Processing time - it's a matter of CPU, and typically the compute and 
communication capabilities available inside a car are huge.  We talk 
Gbit Ethernet twisted-pair inside a car, whereas DSRC is only 16mbit/s 
outside the car.

A vehicle 200km/h with 55m/s give no direct clue about the above 
requirements.  One would have to say how many 50byte IP messages are 
possibly exchanged between two crossing vehicles during that time, at 
7Gb/s (the bandwidth of 802.11ad in OCB mode).  We dont know that.  So 
it looks like apples compared to oranges.

In no case could we say that IP is not adapted because too slow for 
200km/h vehicles.

Let's work to clarify these things in the Internet Drafts.

Alex

>
>      -- 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
>
> *Goals and 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
>
>
>
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>