Subject: [its] ITS Charter Comments

From: "Francois Simon" <[email-masked]>
Date: Wed, 31 Aug 2016 16:08:36 -0400

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:  <mailto:[email-masked]> ​[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.]

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. 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

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.]

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.  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.] 

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.]

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….

ITS:

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

“Transportation”: It varies from invention of the wheel, to conveyor belt, and would include skis and horse-and-buggy :)….. 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”.  <http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=7180136> Intelligent Vehicles Symposium (IV), 2015 IEEE

“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”.

  - 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.]   

     -- 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