Subject: [its] Updated charter - please comment

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Feb 2016 14:20:43 +0100

Hi,

Please see below the updated charter text.  Please comment.

Alex

-----------------------------------------------------------------------

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

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

Chairs:
    TBD

Assigned Area Director:
    TBD

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:

Goal
----
The goal of this group is to standardize IP protocols for establishing
direct and secure connectivity between moving networks.

Moving Network to Moving Network Communications
-----------------------------------------------
The group is concerned with all situations involving moving network to
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 commonly seen as
winning sale arguments for automobiles to hit the roads from now to
year 2020.  Emergency apps for new instrumented ambulances carry many
benefits both to the users and to society in general.

Why IP?
-------
Whereas the Vehicle-to-Internet technologies are considered completed
and deployed in automobiles currently on the roads (e.g. car tethering
through driver's cellular smartphone, live traffic data displayed on
the dashboard, - use of NAT/DHCP and potentially Mobile IP), the
Vehicle-to-Vehicle and Vehicle-to-Infrastructure communications are
still in an infancy stage: primitive link-specific data exchanges are
limited to a non-harmonized set of applications, such as ETSI's
CAM/DENM presence signalling; worse, some link-specific messages
exhibit behaviour assimilated to IP behaviour but the systems are
incompatible with the Internet without involving specific gatewaying.
The industry needs to employ IP data exchanges between vehicles, and
between vehicles and the immediate infrastructure, rather than
link-specific exchanges, in order to benefit from advantages such as
(1) short delays, (2) fast forwarding through short paths of dumb
routers (2) ease of reusing of a huge number of a desktop Internet
applications in a vehicular environment (extend the Internet to mobile
platforms).

Moving network to moving network communications involve link layers
such as: 802.11 OCB, 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 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).

What kind of requirements?
--------------------------
The requirements for mechanisms for moving network to 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 moving network applications
involve IP multicast mechanisms (e.g. virtual siren); thus C-ACC the
1-hop IP moving network to moving netowrk mechanisms will need to
gracefully support IP multicast.

Due to the inherent characteristics of safety-related communications,
all new moving network to 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 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 version of the IP protocol is IPv6 (witness 10% IPv6 penetration
as of early 2016, mobile operators evolving to IPv6-only, government
IPv6 push, IPv4 exhaust at RIRs); this acommodates the current
generation of Internet protocols.  For backwards compatibility, IPv4
may be considered as well, but not exclusively.  Link-local IPv6
addresses will be used.

What SDOs may need this work?
-----------------------------
The requirements and standards for moving network to 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 moving network communications
- Problem Statement for moving network to moving network communications
- Security and Privacy Requirements for moving network to
   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 moving network communications.
   With MIB and security.
- IPv6-over foo, where foo is pertinent for moving network to moving
   network communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)

Timeline
--------
-

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Feb 2016 13:36:05 -0500

Alex:

Below are my comments on the proposed charter text.

Russ

Editorial:  s/automated driving, are/automated driving are/

> benefits both to the users and to society in general.

I think that the "winning sales arguments" is not needed here.  Instead, I think it
would be valuable to say that these features are coming, and that the safety
features are expected to become required.

> applications in a vehicular environment (extend the Internet to mobile

I think this paragraph take too long to get to the main point, which is
why IP is a goog thing in this environment.  I suggest:

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 avoid 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
(1) short delays, (2) fast forwarding through short paths of routers,
(3) ease of reuse of existing Internet applications in a vehicular
environment.

> Moving network to moving network communications involve link layers

Add "nearby" here.  I think it is important to the scope.

> Light Communications), IrDA, LTE-D.  Only the IP protocols are capable

s/802.11 OCB/802.11p OCB (Outside the Context of a BSS)/

> in an interoperable manner.

Add "nearby" here.  I think it is important to the scope.

> notably AODV and derivates).

My understanding from the phone call was that we were going to focus on the 1-hop
protocols in this proposed working group, but leverage work from other groups for the
n-hop situation.

I think we need to say something here about the duration of some of the communications.
a vehicle traveling at 80 Km/h is not going to have communications with a roadside
device for very long.

> What kind of requirements?

Add "nearby" here.  I think it is important to the scope.

> In addition, some moving network to moving network applications

Add "nearby" here.  I think it is important to the scope.

> Current version of Internet protocols

This it too long.  Just say that the groups will only work on IPv6 solutions.

> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Feb 2016 18:47:57 +0100

Le 17/02/2016 23:15, Richard Roy a écrit :
> My comments are inline below ...
>
> RR
>
> ------------------------------------------------------------------------
>
>
>
*From:*Russ Housley [mailto:[email-masked]] *Sent:* Wednesday,
> February 17, 2016 10:36 AM *To:* Alexandre Petrescu *Cc:*
> [email-masked] *Subject:* Re: [its] Updated charter - please comment
>
> Alex:
>
ITS (name to change) Charter February 15th, 2016
> ---------------------------------------- Current Status: WG forming
>
> Chairs: TBD
>
> Assigned Area Director: TBD
>
> Mailing list Address: [email-masked] <mailto:[email-masked]> To
> Subscribe: https://www.ietf.org/mailman/listinfo/its Archive:
> Additional web page TBD
> Goal ---- The goal of this group is to standardize IP protocols for
> establishing direct and secure connectivity between moving networks.
>
> */[RR>] Hard to believe that IP protocols need standardizing.  Isn't
> the real issue one of an appropriate "profile" for using already
> existing RFCs to implement IPv6 networking "between moving
> subnets"?/*

Well profiles are for Bluetooth if you wish (which is below IP, or above
IP) but I can say "adapt" or "improve" IP protocols.

BEcause I havent much seen the word "profile" in RFCs for the IP layer.

> ----------------------------------------------- The group is
> concerned with all situations involving moving network to moving
> network communications.  For example: vehicle-to-vehicle
> homenet, vehicle-to-infrastructure communications, wagon-to-wagon in
> a train, or train-to-intersection signalling.
>
> ------------------------------------------------ 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 commonly seen as
>
> */[RR>] Many of the apps to which you allude do not require IPv6
> networking.  If you feel the need to provide use cases, make sure
> they require IPv6 networking in a mobile context./*

I will try to do that.

I would like you - if possible - to suggest other use case which
requires IPv6 networking in a mobile context?  Thanks.

Let me explain the reasoning in the paragraph above by listing a few key
items for IPv6 networking in V2V and V2I, pick one:

I experienced the need for IP between cells of vehicles moving together.
  The need was there urgent: the programmer in the back car had
absolutely to flush the data in the middle car and the LTE connection
was down.  If no flush then risk of accident.  The computer that flushes
is windows with TCP IP on WiFi.  The computer to be flushed is a linux
variant on a CAN network.  The only way to have that flush work is to
network the two computers IP networked together.

There is no standard in vehicular communications which requires IPv4.
If ever IP is mentioned it is IPv6.

The example C-ACC use case is typical illustration of a direct
vehicle-to-vehicle communication of data (as opposed to entertainment
apps which are Vehicle-to-Internet, and 'radar' communication which is
bouncing signals not data).

A C-ACC standard currently under definition by ETSI is using CAM and
DENM messages.  The CAM and DENM messages are understood by some at the
link-layer and by others at the application-layer.  If they are
application-layer, then there is a need of a networking layer.  The only
networking layer is IPv6.

Vehicles connected to the Internet can only use IPv6 as networking
layer.  If we want V2V and V2I to make a V2V2I the only possibility
again is to use IPv6 as the networking layer.

If we dont use IPv6 as the networking layer in V2V and V2I then we risk
end up with incompatibilities, seggregation in the deployed vehicles.
This is what happened with WAP in the mobile phone world until IP
arrived.  This is what happens these days with consumer electronics
standards which include more and more IP technology as a networking
layer after initial deployments of specific apps without networking layers.

> Why IP? ------- Whereas the Vehicle-to-Internet technologies are
> considered completed and deployed in automobiles currently on the
> roads (e.g. car tethering through driver's cellular smartphone, live
> traffic data displayed on the dashboard, - use of NAT/DHCP and
> potentially Mobile IP), the Vehicle-to-Vehicle and
> Vehicle-to-Infrastructure communications are still in an infancy
> stage: primitive link-specific data exchanges are limited to a
> non-harmonized set of applications, such as ETSI's CAM/DENM presence
> signalling;
>
> */[RR>] Using the term non-harmonized here is not only incorrect,
> but inflammatory.  Please remove such ill-advised terminology from
> the draft./*

Ok sorry if offense.

>
> worse, some link-specific messages exhibit behaviour assimilated to
> IP behaviour
>
> */[RR>] Not sure what the point is here.  Messages don't have
> "behaviors", they have information content./*

Ok.

>
> but the systems are incompatible with the Internet without involving
> specific gatewaying.
>
> */[RR>] Gateway functionality is above the transport layer, and
> hence out of scope of this effort. /*

Ok, removed it for clarification.  I agree with you.  I think I meant
routing.

> applications in a vehicular environment (extend the Internet to
> mobile platforms).
>
> */[RR>] This list is contradictory and the "necessity of employing"
> is not obvious.  If you want fast forwarding, you don't do IP, you
> do MAC bridging at the data link layer where possible.

It sounds intuitive, but measuring it may surprise:

Apps running directly on link layer vs on a networking layer are not
necessarily faster.  The round-trip time of 1280-byte packets on 802.11p
is sensibly the same whether or not the 40bytes of the IPv6 header is used.

The compute parts of an IP layer does not introduce much delay compared
to the compute parts of the Ethernet link layer.  The comparison of the
compute-intensive parts in the two layers are the following:
- the CRC is optional in IP but mandatory in Ethernet.
- the table lookup is longest-match in IP (faster in simpler 1-hop
   topologies employing default routes) and exact-match in Ethernet
   (always same cost regardless topology size and complexity).

> If you want short delays, make the packets smaller and the
> processing overhead minimal, both of which argue AGAINST IPv6
> networking protocols.

I should have been clearer:

Using IPv6 as networking layer in a string of vehicles allows for fast
and deterministic communications between the frontmost and rearmost
vehicle regardless the size of the string - it scales.  Only with an
802.11p link layer (no IP)  that string is bound to a small size of a
few hundred meters, and additional propagation delays due to radio
propagation uncertainties - it doesnt scale.

> The advantage of IPv6 pure and simple is that using that particular
> networking protocol, most of the rest of the world can be reached!
> There is little debate on this point, and it is sufficient to
> justify pursuing this work. Why not leave it at that?? /*

I agree Richard.

> still
> */[RR>] I would avoid any discussion of link-specific data exchanges
> because they are being mandated, and they have no bearing on this
> work. I'd simply state the obvious advantage of being able to
> leverage off the already deployed Internet and leave it at that./*

Improved the text.

>> of running on each of these links and establish IP paths across
>> them in an interoperable manner.
>>
>> */[RR>] Fair enough ... see comment above.  Clearly there is no
>> need to focus on the data link and physical layers, other than to
>> state the obvious that if a particular MAC&PHY doesn't support the
>> requisite MTU sizes (e.g. 802.15.4), then some accommodations
>> (e.g. 6LoWPAN) will have to be made if possible. Noe of that
>> should affect the work of this group if I understand the goals
>> correctly. /*
>>
>>
>>
>> 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.
>>
>>  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.
>>
>> */[RR>] The issue of trains and subnets thereon is tricky and the
>> topic of several investigations ongoing in Europe (including ETSI
>> TC RT and ITS (RT-JTFIR)).  We may want to steer clear of such use
>> cases for the time being until the dust settles./*

There is a person from a router manufacturer who expressed high interest
in the technology for rails.  We may get a presentation in Buenos Aires
to help clarify.

>>
>>
>>
>> What kind of solutions? ----------------------- The current
>> technical solutions considered to achieve moving network to moving
>> network communications are of two kinds: IP routing
>>
> */[RR>] Are these protocol modfications/additions, or simply
> profiles on existing protocols?  I suspect it's the later, but you
> are the experts:^))/*

It's improving a protocol if possible (tweak its timers, extend some
header) or otherwise make a new one.

I am not sure about profiling protocols.  I need to understand better
this term profiling.

> What kind of requirements? -------------------------- The
> requirements for mechanisms for moving network to moving network
>
> */[RR>] ITS communication security is being addressed in various
> venues (most notably IEEE 1609 and ETSI TC ITS).  We should be
> careful not to reinvent the wheel.  For example, while there is no
> theoretical problem using IPsec, to secure IPv6 management messages
> as well as data exchanges at the network layer, you might find using
> 1609.2 security functions work just as well if not better, and such
> mechanisms are/will be mandated in all "vehicles", so why not use
> them./*

YEs, I agree.  We need to reuse from 1609, ETSI TC ITS and others.  When
studying some of them we may realize some may come from IETF (the cert
parts is an example).  We need to identify the right source of reuse.

> */[RR>] All this has been and continues to be addressed in other
> venues. The solutions derived there are being / will be mandated by
> regulators.  We should carefully follow and contribute to those
> efforts here appropriate, but otherwise not try to build a separate
> sand castle! /*

I agree.  We will strive to synchronize with regulators.

> */[RR>] Not sure why this is a concern.

It's technical: in a car the Mobile Router can only have one default
route.  Many V2I trials have that default route used by Mobile IP these
days (forward everything to the HA).  If we come up with a new technique
for more direct V2V and V2I communications we must make sure we dont
disturb that Mobile IP part.  It's a typical multihoming problem.

> 1-hop V2V doesn't require and in many cases does not use ANY
> networking at all (cf. FNTP, WSMP, HSMP, NNTP, whatever name you want
> to give the null-networking protocol whcih has been standardized in
> IEEE and ISO (cf. IEEE 1609.3, ISO 16460, ISO 29281-1, etc.)./*

What hop do you think about?

I think about IP hop.  Should I call it 1-IP-hop V2V?

> ------------------------------------- The version of the IP protocol
> is IPv6 (witness 10% IPv6 penetration as of early 2016, mobile
> operators evolving to IPv6-only, government IPv6 push, IPv4 exhaust
> at RIRs); this acommodates the current generation of Internet
> protocols.  For backwards compatibility, IPv4 may be considered as
> well, but not exclusively.  Link-local IPv6 addresses will be used.
>
> */[RR>] Yes. Simpler is better!/*

Thanks, I agree.  Modified accordingly.

Alex

>
>
>
>
> What SDOs may need this work? ----------------------------- The
> requirements and standards for moving network to moving network
> 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 moving
> network communications - Problem Statement for moving network to
> moving network communications - Security and Privacy Requirements
> for moving network to 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
> moving network communications. With MIB and security. - IPv6-over
> foo, where foo is pertinent for moving network to moving network
> communications (e.g. 802.11 OCB, VLC, LTE-D, 802.11ad)
>
> */[RR>] The real issue is using IPv6 networking to connect mobile
> LAN subnets ... the data link and physical layer technology is NOT
> directly relevant.  Simpler is better!/*
>
>
>
> Timeline -------- -
>
> _______________________________________________ its mailing list
> [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Feb 2016 10:59:00 +0100

It seems this mail too from Richard was not distributed to subscribers.

Alex

-------- Message transféré --------
Sujet : Re: [its] Updated charter - please comment
Date : Thu, 18 Feb 2016 18:47:57 +0100
De : Alexandre Petrescu <[email-masked]>
Pour : [email-masked], 'Russ Housley' <[email-masked]>
Copie à : 'Dr. Hans-Joachim Fischer' <[email-masked]>, 
[email-masked], 'Thierry Ernst' <[email-masked]>, 
[email-masked]

I will try to do that.

Ok sorry if offense.

Ok.

I agree Richard.

Improved the text.

Alex