Subject: [its] latest charter text

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Apr 2016 14:01:03 +0200

ITSers,

You will find below the latest charter text.

It includes changes issued from discussions with Dick.

Alex
--------------------------------------------------------------------
Intelligent Transportation Systems (its)

Chairs:
    Russ Housley
    Carlos Pignataro

Assigned Area Director:
    Suresh Krishnan

Mailing list
    Address: [email-masked]
    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

Automobiles and vehicles of all types are increasingly connected to
the Internet.  Comfort-enhancing entertainment applications, road
safety applications based on 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.

In the future, some vehicle communications may not use IP for
exchanging safety messages with other vehicles and infrastructure.
Other vehicle communications may involve IP-based protocols,
especially when multiple applications need to share one data link.

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.

In general, this group is concerned with situations involving moving
network to nearby moving, or fixed, network communications (V2V, V2I,
I2V).  For example: a moving network in a vehicle communicating to
another moving network in a nearby vehicle (for C-ACC, Platooning, or
at an incident scene); a personal area network carried by a user and
connecting to an in-house fixed network (homenet); an in-car networked
device receiving messages from a road-side display when passing by,
wagon-to-wagon range extension in a train; train-to-intersection
signalling.  In these loop-free 1-IP-hop topologies there is a problem
of establishing IP paths quickly and reliably.

Improved safety is an immediate result of hyper-connectivity of
vehicles; as such public authorities worldwide are increasingly
mandating secure communication technology requirements in vehicles.
Emergency applications for instrumented ambulances carry many benefits
both to the users and to society in general.  For these reasons, a
solution to the problem of establishing IP paths between nearby moving
networks will be resilient to threats such as eavesdropping.

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

The group will only work on IPv6 solutions.

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

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.

If the group is successful in designing a simple 1-IP-hop solution for
V2V/V2I/I2V, and if deployments prove useful, in reasonable time, then
future extensions for n-IP-hop V2V2I may be considered.

Work items
1. "Problem statement for IP in V2V and V2I"
    including "IP addressing architecture for V2V and V2I"
    and including "Gap Analysis: IP protocols suited and gaps"
    and including "Use-cases for IP in V2V and V2I moving network
    To nearby moving or fixed network"

2. "Threat Analysis for IP prefix exchanges in V2V and V2I
    Context"

3. "IP over DSRC (802.11-OCB)" typical IP-over-foo document,
    including connectivity in fast and asymmetric conditions,
    Coverage area vs speed diagrams, below-IP congestion
    management.

4. "List of papers and _products_ using IP in V2V and V2I"

5. "Solution for direct communication between moving networks"

Goals and milestones
Oct 2016 - submit “Problem Statement” to WG
Oct 2016 - submit “List of papers and products” to WG
Feb 2017 - submit “Threat Analysis” to WG
Feb 2017 - submit “IP over DSRC (802.11-OCB)” to WG
Jun 2017 - submit “Solution for direction communication between
                    moving networks” to WG
Oct 2017 - start submitting to IESG

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Mon, 25 Apr 2016 21:45:01 +0900

Hi Alex,

As the work item “Solution for direction communication between moving networks” is one of explicit requests from ISO TC204, it is better to put the work item on a priority.

J. 
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: [email-masked]
#webpage: https://sites.google.com/site/hurryon

> On Apr 25, 2016, at 9:01 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> ITSers,
> 
>    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>
> 
> Additional web page
>    TBD
> 
> Charter
> 
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Apr 2016 15:30:13 +0000

Hi Alex,

Will there be work items covering civil aviation and unmanned air system
use cases?

Thanks - Fred

From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday, April 25, 2016 5:01 AM
To: [email-masked]
Subject: [its] latest charter text

ITSers,

Alex

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
   Archive:
   http://www.ietf.org/mail-archive/web/its/current/maillist.html

Additional web page
   TBD

Charter

Work items

Goals and milestones

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Mon, 25 Apr 2016 17:09:16 +0000

>From what I see, ITS is IPv6 ONLY items.

Not DTN, but IPv6 provides potential discovery and validation.
Not Information Centric Networking.
Not others that are not IPv6 related.

I was at IETF-95, but MP-TCP and ITS were at the same time.  :-(

It would be nice to fix ADS-B In.  But you probably don’t need IPv6 to do it.  But you could.

I was at the Integrated Communications, Navigation and Surveillance (I-CNS) conference last week and ask the FAA manager for the Next Generation Airspace System (NextGen) about ADS-B In and got a " ….. Well…. Perhaps we can’t discuss it in this forum. "

Really good overview.
https://media.blackhat.com/bh-us-12/Briefings/Costin/BH_US_12_Costin_Ghosts_In_Air_Slides.pdf

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwiWjdL1oarMAhWPQD4KHT0pCG0QtwIIKTAC&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DmY2uiLfXmaI&usg=AFQjCNGnegT_l8lQ7MLE74MYFG5VZv4iMQ&sig2=XD6tloGhoGfFQvu3vgFFvg

Will

From: its <[email-masked]<mailto:[email-masked]>> on behalf of "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 25, 2016 at 11:30 AM
To: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [its] latest charter text

Hi Alex,

Thanks - Fred

From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday, April 25, 2016 5:01 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [its] latest charter text

ITSers,

Alex

Chairs:
   Russ Housley
   Carlos Pignataro

Assigned Area Director:
   Suresh Krishnan

Mailing list

Additional web page
   TBD

Charter

Work items

Goals and milestones

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Apr 2016 17:18:47 +0000

Hi Will,

Yes, we have been thinking about ADS-B too. A proposal we came up with was
to include position and heading information in an IPv6 extension header:

https://datatracker.ietf.org/doc/draft-skeen-6man-ipv6geo/

That way, we can include both user data and position/heading information
in a single IPv6 packet instead of having to send multiple packets. And, unlike
ADS-B, it can be secured using IP and/or link-layer security mechanisms.

Thanks - Fred

From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]]
Sent: Monday, April 25, 2016 10:09 AM
To: Templin, Fred L <[email-masked]>; Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [its] latest charter text

It would be nice to fix ADS-B In.  But you probably don't need IPv6 to do it.  But you could.

I was at the Integrated Communications, Navigation and Surveillance (I-CNS) conference last week and ask the FAA manager for the Next Generation Airspace System (NextGen) about ADS-B In and got a " ..... Well.... Perhaps we can't discuss it in this forum. "

Really good overview.

Will

Hi Alex,

Thanks - Fred

ITSers,

Alex

Chairs:
   Russ Housley
   Carlos Pignataro

Assigned Area Director:
   Suresh Krishnan

Mailing list

Additional web page
   TBD

Charter

Work items

Goals and milestones
Oct 2016 - submit "Problem Statement" to WG
Oct 2016 - submit "List of papers and products" to WG
Feb 2017 - submit "Threat Analysis" to WG
Feb 2017 - submit "IP over DSRC (802.11-OCB)" to WG
Jun 2017 - submit "Solution for direction communication between
                   moving networks" to WG
Oct 2017 - start submitting to IESG

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 26 Apr 2016 10:28:25 +0200

> Will there be work items covering civil aviation and unmanned air system

Hi Fred,

The aviation use-case was expressed at the mic during the BoF as well.

In my understanding, a use-case involving IP moving networks in planes, 
or in unmanned air systems, do make sense.  Because it is similar to 
drones docked on automobiles, which have been demonstrated often.

However, the IESG suggestion is to focus now on ITS (V2V/V2I) and IPv6 
over DSRC.

For "later" (if successful with the above):
- are there use-cases of civil aviation and unmanned air systems which
   involve DSRC;
- is civil aviation considering IPv6 in use-cases of Plane-to-Ground or
   Plane-to-Plane communications.
- what is the name of links that are specific to civil aviation and
   unmanned air systems and has IPv6 been run on it.

Alex

>
> Thanks - Fred
>
> *From:*its [mailto:[email-masked]] *On Behalf Of *Alexandre Petrescu
> *Sent:* Monday, April 25, 2016 5:01 AM
> *To:* [email-masked]
> *Subject:* [its] latest charter text
>
> ITSers,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 26 Apr 2016 10:34:02 +0200

Hi Jong-Hyouk,

You have seen the recommendation from IESG.

The ISO TC204 request can be understood together with the IESG 
recommendation, if we try.

We can write IPv6-over-DSRC such as to satisfy some parts of the ISO 
TC204 request as well.

You were one of the earliest to say, verbally, that IPv6 runs ok over 
802.11p - why dont you put that in an I-D?

Otherwise, we can save the MNPP behaviour for later anyways.

Alex

Le 25/04/2016 14:45, Jong-Hyouk Lee a écrit :
> Hi Alex,
>
> As the work item “Solution for direction communication between moving
> networks” is one of explicit requests from ISO TC204, it is better to
> put the work item on a priority.
>
> J.
> --
> #email: [email-masked] <mailto:[email-masked]>
>> On Apr 25, 2016, at 9:01 PM, Alexandre Petrescu
>> <[email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>> ITSers,
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 26 Apr 2016 10:45:07 +0200

Le 25/04/2016 19:09, Ivancic, William D. (GRC-LCA0) a écrit :
[...]
> It would be nice to fix ADS-B In.  But you probably don’t need IPv6 to
[...]

ADS-B: Automatic dependent surveillance – broadcast; a method by which 
plane tells everybody around where it is (such that we dont find 
ourselves again desperately seeking MH370).

This is an application which can be run over UDP, and over IP.  If you 
do it with IP (rathern than just radio broadcast) then you get some 
advantages, e.g. easy integration in databases and immediate 
availability to qualified experts.  Seismographic data, thunder strike 
data, and similar, are other examples which moved from analogous to 
Internet.

This can be possible if we have IP-over-ADS-B.  ButI suppose ADS-B is 
very much different than DSRC?

Alex

>
> I was at the Integrated Communications, Navigation and Surveillance
> (I-CNS) conference last week and ask the FAA manager for the Next
> Generation Airspace System (NextGen) about ADS-B In and got a " …..
> Well…. Perhaps we can’t discuss it in this forum. "
>
>
> Really good overview.
> From: its <[email-masked] <mailto:[email-masked]>> on behalf
> of "Templin, Fred L" <[email-masked]
> <mailto:[email-masked]>>
> To: Alexandre Petrescu <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *To:* [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 26 Apr 2016 15:04:24 +0200

ITSers,

This is the latest charter text.

The list of work items is updated (2 instead of 5), a generic paragraph 
removed, added DTN and ICN as non focus, and added a perspective of 
rechartering conditioned by accomplishment.

Yours,

Alex

------------------------------------------------------------------------
Intelligent Transportation Systems (its)

Chairs:
    Russ Housley
    Carlos Pignataro

Assigned Area Director:
    Suresh Krishnan

Mailing list
    Address: [email-masked]

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.

In the future, some vehicle communications may not use IP for exchanging 
safety messages with other vehicles and infrastructure.  Other vehicle 
communications may involve IP-based protocols, especially when multiple 
applications need to share one data link.

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.

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

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

This group will not work on V2V or V2I use-cases where IP is not 
well-suited.  It 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. Informational RFC "ITS Primer" covering
    - What is ITS?
      - Explain V2V, V2I, V2-X
    - Why is IPv6 needed?
     - Explain why some traffic will not use IPv6
     - Explain why other traffic will use IPv6
    - Problem statement
    - Use-cases
    - Security considerations
    - Privacy considerations

2. Standards Track RFC "IPv6 over DSRC"

Goals and milestones
Oct 2016 - submit "ITS Primer" to WG
Dec 2016 - submit "IPv6 over DSRC" to WG
Jun 2017 - submit "ITS Primer" to IESG
Jun 2017 - submit "IPv6 over DSRC" to IESG
Sep 2017 - re-charter

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 Apr 2016 22:37:33 +0000

Hi Alex,

Here is some proposed text for the charter. Please let me know if
this can be accommodated.

Thanks - Fred
---
The International Civil Aviation Organization (ICAO) is designing the
Aeronautical Telecommunications Network for Internet Protocol
Services (ATN-IPS) which will be based on IPv6 from its inception.
IPv6 will run over various aviation data links including VHF data link,
L-DACS, AeroMACS and several varieties of SATCOM (e.g., Inmarsat
SwiftBroadBand, Iridium NEXT, etc.). Similarly, other aviation entities
are considering air traffic management services for Unmanned Air
Systems (UAS) as UAS proliferation within the global airspace
continues. Air-to-air and air-to-ground IPv6-based communications
are in scope for both manned and unmanned aviation.

> -----Original Message-----
> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Tuesday, April 26, 2016 1:28 AM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 28 Apr 2016 20:06:45 +0200

Hi Fred,

This is very tempting.

We know we must make technology that is applied in as many settings as 
possible.  TCP works as much in my office PC as in that plane's server.

However, at this time we have not yet identified L-DACS, AeroMACS nor 
what is Iridium NEXT going to use next.  It's the first time we hear 
about them.  I suppose L-DACS is very different than 802.11p.

I am tempted to believe that at this time we keep the air suggestion 
below as a very good perspective.  We will need to ask the chairs.

Maybe when we're done with IP-over-DSRC and V2I/V2V documents then we 
contemplate re-charter and study L-DACS more.

(maybe until then we'll have cheap L-DACS cards, free L-DACS linux 
kernel drivers, and wireshark dissectors for L-DACS)

(and are L-DACS, VHF, AeroMACS below IP directly between planes, or is 
it something else between planes that may need IP)

Yours,

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 28 Apr 2016 12:28:51 -0700

Alex, 

Fred gets a big +1.  Get the tunnel vision off.

reasoning within:

On Thu, 2016-04-28 at 20:06 +0200, Alexandre Petrescu wrote:
> possible. 

Aircraft are mobile platforms.  Automobiles are mobile platforms.  

Indeed there are reasons for interoperability between them.  For
example, a USCG helicopter with a casualty that it is med-evacing is
functioning as an ambulance.  When it lands, the casualty is
transferred to another ambulance, this mobile platform drives on the
highways instead of flying, but the necessary vehicle-to-internet
function is the same.  

>  TCP works as much in my office PC as in that plane's server.

slightly different subject -- beyond use case (but within scope). Some
of the obsolescences of TCP get worse in any radio environment
(timeouts, lack of early open, and inability to multicast).   

> what is Iridium NEXT going to use next. 

If they are routable networks, you don't need to.  (and if they're not,
you can't)

>  It's the first time we hear 

A routable network can interconnect routers and that's what we need.
 The specifics of these different radio-WANs are unimportant as long as
they have the right interface at top of layer 2.  

If a drone and an airliner are trying to occupy the same air space (one
on the news last week in UK -- collision) they need to communicate with
each other.  Expecting a transAtlantic airliner and a helicopter drone
to have the same radio network is unrealistic.  What we need is that
they both be routable networks so they can communicate with each other.
 Singling up on a single radio network technology is exactly what we
don't want to do and exactly what IP gets us away from.

(There are a small handful of characteristics that differentiate a
radio network from a wired one.  But all radio networks share them:
  - shared medium -- radio.  Wired network plumbing is most often
point-point (e.g. fiber).  This is blessing and curse: 1) the payoff to
multicast increases and 2) the radio-WAN needs a MAC (DWDM, for
example, doesn't).
  - physics-limited capacity.  At about four orders of magnitude less
than wired.  Further, the capacity is prorated across all the
subscribers in the network segment. 
)

> it something else between planes that may need IP)
The FAA has been mincing around the need to communicate between various
entities (not just air traffic control) on the ground and aircraft,
both on the ground and aloft.  ... for at least a quarter century.
 They're still defaulting to voice radio (which unmanned aircraft can't
do), English language and flight levels in feet.  1) the aircrraft
sector needs, 2) interoperability between aircraft and other mobile
platforms is a requirement.

> > > > may

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Apr 2016 18:21:49 +0000

> be coordinated with the DMM Working Group and with LISP Working Group.

Add to this:

  Other infrastructure mobility management solutions such as AERO will
  also be considered.

Thanks - Fred