Re: [its] Updated proposal of Charter ITS

apparently this got mislaid.  reposted:

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

What I did do -- comment in line.  
What I did not do -- reorganize.  

On Sun, 2013-03-17 at 19:39 +0100, Alexandru Petrescu wrote:
> Dears,
> 
> In Orlando we discussed with several participants, 

>               Intelligent Transportation Systems at IETF
>                         Draft Charter Proposal
>                          March 17th, 2013
>                  http://ietf.org/mailman/listinfo/its
> 
> 
> Intelligent Transportation Systems (its)
> ----------------------------------------
> Current Status: Informal bar BoF
> 
> Chairs:
>   TBD
>   TBD
> 
> Assigned Area Director:
>   TBD ()
> 
> Mailing list
>   Address: its@ietf.org
>   To Subscribe: https://www.ietf.org/mailman/listinfo/its
>   Archive:
>   http://www.ietf.org/mail-archive/web/its/current/maillist.html
> 
> Draft Charter Proposal:
> 
> Context
> -------
> Intelligent Transportation Systems (ITS) are composed of
> interconnected systems of machines; vehicles, mobile devices and fixed
> embedded devices (actuator and sensors).  These machines communicate
> with fixed access points which are are deployed along terrestrial
> roads (e.g. Road-Side Units), and along shores of water paths;
> alternatively, mobile or fixed access points may be deployed above
> ground; they all offer wireless communications to equipment deployed
> in mobile vehicles (e.g.  On-Board Units), in a secure manner.  

I'd feel better with language a bit like this:

ITS is about several aspects of extending the internet to mobile
platforms.  

> The
> entire system may be connected to the Internet; in certain cases the
> vehicles are disconnected from the Internet yet are inter-connected to
> each another, in an ad-hoc manner.  

ok.  The characteristics here include
 - presence of radio-WANs (WAN meaning router-router interconnect, as
opposed to LANs -- topological difference)

But also:
 - lower capacity, higher noise than customary internet plumbing
 - presence of mission critical needs and applications.
 - volatile topology as vehicles (and the routers they contain) move.

The internet's major engineering contribution is to provide perfect
delivery (e.g. bit-perfect, in order) over imperfect infrastructure.
There's no better place to take advantage of these characteristics than
here.

> Each moving vehicle may use
> disjoint and heterogeneous radio systems (e.g. a vehicle employs two
> or more different radios which may be used simultaneously, or
> alternatively).
> 
The reality of radio is lower capacity than wired internet (by four
orders of magnitude) coupled with higher error rates than experienced in
a wired internet (also by orders of magnitude).  

Lower per-link capacity and the mission-critical availability needs
strongly indicate that multiple radio-WANs used in parallel must be
supported.

The volatile topology also indicates that vehicle-to-vehicle daisy
chains should be supported.
> 
> Communication security requirements are of paramount importance in the
> context of vehicular communications.

['Security' covers lots of territory.  In order for the charter to be at
all useful, we need to narrow things down a little and mapping onto the
ISO model is a good way to do that.]

Layer 6/7.  Security of the content data is important: authenticity is a
universal, ubiquitous requirement -- the implications of spoofed data
(such as bogus position reports or bogus traffic controls) should be
obvious.  Equally important, some data, such as medical (e.g. the
ambulance use case) must be confidential.  Scope of this requirement is
end-to-end; there should be no place short of end systems where the
content data is not protected.  

Layer 3.  Authenticity of routing information protocol messages is
important; spoofing would distort the internetwork topology.

>   Using IP should not introduce
> new risks, especially when safety-specific applications are involved.

Compared to what?
> 
> For example, crash avoidance inter-vehicle communication systems
> should be secured (safety of humans is at stake); as another practical
> example, within the vehicle, introducing IP communications to an
> otherwise non-IP rearview camera should not allow for attacker IP
> devices to DoS the displafy, or turn the volume to a sudden high.
> 
The above is a use case demonstrating need for content-level
authenticity.  

> Certain security requirements may be generic IP communications
> security, whereas others may be specific to vehicular communications.
> 
Layer 6/7 (content authenticity and confidentiality) are indeed
media-independent.   (and platform independent).
> 
> Due to the mobile nature of the system, several problems exist with
> respect to IP addressing and route establishment such that IP
> communications can be realized.  In the case of 1-hop
> Vehicle-to-Vehicle communications (V2V), without infrastructure, there
> is a problem in identifying which subnets and addresses are used on
> the link between two vehicles; also there is a problem in deciding how
> one vehicle learns the prefix deployed in a vehicle in close vicinity.
> In the case of n-hop V2V2V communications there is a need of
> identification which address configuration and dynamic routing
> protocol should be employed.  In the case of Vehicle-to-Infrastructure
> (V2I) communications, there is a problem in propagating the prefix
> contained in a vehicle to the routers of the infrastructures without
> destabilizing the Internet routing (a typical IP network is using
> mostly IP addresses topologically valid at a single point, and
> relatively stable routing system).
> 
> One particular use case is under the form of an instrumented
> ambulance.  The ambulance is connected to the Internet and offers
> wireless and wired access to a large number of individual equipments
> deployed in-vehicle.  The ambulance may move through a traffic jam and
> signal its presence to nearby vehicles with visual means and also with
> communication packets.
> 
> Automatic driving through traffic jams involves wireless
> communications between vehicles.  Constant links between vehicles
> constitute good support for establishing IP communications.  An IP
> device in one vehicle may signal its actual speed to another IP device
> in the vehicle nearby.
> 
> The smart-city use case is also important for networking country- and
> world-wide transports. 

I don't know how 'smart-city' is defined.  (Possibly related to that is
'smart grid' in the US -- it's equally undefined.).  Use cases like this
are valuable if we can distill requirements from them; if the use case
is so foggy that we can't distill requirements, then you have clutter.

>  The use case should lead to development of
> requirements and services for transports within cities, or countries,
> making them smart.  The ITS technologies may use techniques from MANET
> and from RoLL adapted to this smart-city use case.  One may need to
> consider ETSI IPv6 over GeoNetworking, and also add OLSRv2 as used in
> community networks.  A hybrid routing protocol could be used.
> 
You skipped from use case to potential solution.  This omits the
requirements step between.  And, IMHO, trespasses on what the working
group, not its charter, should be doing.  
> 
> Several Standards Development Organizations outside IETF work towards
> developing protocols for vehicular communications.  In some cases IP
> protocols are used for transport, in other cases IP protocols are
> modified for purposes particular to vehicular communications (such as
> the use of geonetworking at ETSI, or 6lowpan intermediate layers at
> IPSO).  The relevant SDOs and respective groups are: ETSI ITS, ISO TC
> 204, IEEE 802.11p,

You should include several other relevant here, if you're going to list
any at all:
- IEEE 802.16
- IEEE 802.22
- TIA LTE
- any relevant satcom stds bodies (this area is horribly confused)

And it gets worse, much worse.  In US, there are several entities
dealing with comms to vehicles:
- US Congress has passed legislation that includes 1) some $ and 2)
direction to Commerce Department to charter FirstNet, an autonomous
corporation within the deparment (don't ask me what that means) to
provide emergency services communications.  
- Commerce already has National Institute of Standards and Technology
(NIST); the legislation gives NIST charter for public safety comms
R&D.  
- NIST, in turn, has a cozy relationship with National Public Safety
Telecommunications Council which has recently written up a Statement of
Requirements for 'broadband' communications.  It's really about
extending the internet to emergency services platforms, but you can't
use that heretical language with this group.  (and the statement of
requirements, IMHO, isn't very good).  

Why recite this?  Aside from the obvious overlap?  If you look at NPSTC,
they have two major faults: 1) operators, not planners and 2) locked
into looking at extending the internet to mobile platforms through the
narrowband voice radio experience.  We gotta do better. 

Of the standards bodies that could possibly get the emergency services
aspect of reach to mobile, IETF has the best chance.  Expertise and
perspective.  

>  AUTOSAR, IPSO.  Opportunities exist to develop
> liaisons with these SDOs.
> 
How many of these are communications standards?  And how many are
something else (like position/nav?).  

> 
> A number of IETF protocols are being considered in the context of
> Intelligent Transportation Systems - most notably IPv6, Mobile IPv6,
> ND, ULA, DHCPv6, RPL, PMIPv6.  Others, such as Global HAHA, are not
> excluded.  At IETF several Working Groups such as 6MAN, V6OPS, DHC,
> MIF, MANET, DMM, RoLL, NETEXT, LISP produce work which is highly
> pertinent to the ITS context. 

These are all layer 3 RFCs, aren't they?  

This gives rise to a scope question: some of the issues you raise above
are not layer 3 issues (end-end security for example).  Are you
intending to confine to layer 3 or worry about higher/lower layer issues
within [its]?  The peril of 'all layers' is focus; the peril of layer 3
is the one already raised -- what are you doing that, say, MANET, isn't
already?  Said another way, what's the product?  (Liaison with 101 other
standards bodies isn't a legitimate end, although it may be a necessary
means).

>  A gap analysis should be performed to
> identify whether work in these groups can be reused for vehicular
> communications.  A problem statement draft should be written.
> 
> New efforts at IETF are also relevant: 6TSCH.  The 6TSCH effort
> dealing with time-synchronized 802.15.4 link layers may have
> pertinence to safety applications of ITS, and it should be clarified
> whether it pertains to long-range communication between vehicles.
> 
> Potential new work items
> ------------------------
> The following potential work items exist:
> 
> Scenarios and requirements for vehicular communications will be
> developed which introduce at IETF the terms V2V, V2I, V2R and
> intra-vehicular paradigms.  Define various possible scenarios for IP
> vehicular communications and identify requirements that are essential
> to support the defined scenarios.
> 
> Practices and gap analysis for IP vehicular communications: document
> practices for the deployment of existing IP protocols and identify any
> limitation of the existing IP protocols to fulfill the scenarios and
> requirements for IP vehicular communications.  If limitations are
> identified as part of the above deliverable, specify new protocols or
> extensions to existing protocols that removes the identified
> limitations to achieve IP vehicular communications.
> 
> A problem statement draft should be written which documents the
> existing protocols, analyses the gaps of their behaviour in 1-hop V2V
> networks and expresses the need for a new solution.
> 
> Supplementary work items
> ------------------------
> Infrastructure-less 1-hop route exchanges between vehicles, or between
> vehicles and road-side units which are disconnected from the
> infrastructure.  A widely-used link-scoped IP protocol should be
> reused for prefix exchanges between vehicles in close vicinity; a
> single subnet is used between such vehicles, which are otherwise
> disconnected from the infrastructure.
> 
> IEEE 802.11p is a link layer technology specific to vehicular
> communications, and which may be used for IP for ITS.  In certain
> places this link layer technology is named "G5".  Several trials of
> using IP directly over 802.11p links (without intermediate layers)
> have been performed in laboratory environments.
> 
> A vehicle may have a multiplicity of interfaces, and a multiplicity of
> addresses outside and inside the vehicle, at the same time, for
> different purposes.
> 
> For the use of IPv6 addresses inside a vehicle it is necessary the
> addressing schemes which couled be employed, and which address
> auto-configuration mechanism(s) (or a combination thereof) should be
> employed such that to be inline with the in-vehicle application
> requirements scenarios.

There is a host of issues here; needs a sort.  If you are going to have
a vehicle disconnected (or tenuously, intermittently connected) to the
internet, then there are several services that it either must do
without, do with but with delay, or provide itself.  DHCP seems to be
what you had in mind here.  But DNS and white pages (PKI) access is also
required (there are probably more ... and some are dependent on just
what apps you intend to support).  
> 
> 
> For outside the vehicle, the use of IPv6 addresses in a subnet formed
> by the egress interfaces of the vehicles, in a 1-hop ad-hoc manner, is
> considered.
> 
> For the fixed network deployed outside the vehicle - the use of Proxy
> Mobile IPv6 protocol on the fixed mobility management entities may
> prove advantageous to offer mobility to a moving network deployed in a
> vehicle.
> 
> For the security inside the vehicular on-board network, requirements
> specific to vehicular communications should be formulated.
> 
> For the security on the link between two vehicles, a secure Neighbor
> Discovery mechanism should be used.
> 
> Milestones:
>   Mar 2013 - Meet in Orlando done
>   Jul 2013 - Meet in Berlin
>   Jul 2013 - Present drafts "Scenarios and Requirements for IP in
>              Intelligent Transportation Systems", and Gap Analysis

Is this the task you envision?  

[its] is, of course, interesting (why I signed up to the newsgroup).
But I'm having a hard time figuring out what the intended goals are.

I built about half the course I used to teach around what I called
Plowshares into Swords Internet -- what are the differences between
garden variety internet (office, residence) and what we need ('we' can
be either military or emergency services, the analysis works the same).
The differences sort into four (only) bins:
 - availability and survivability
 - security
 - reach to mobile platforms
 - QoS Control
Which sets you up for about 8 hours of lecture.

Suggest that that might fit here.

On Fri, 2013-03-29 at 12:03 +0100, Alexandru Petrescu wrote:
> Discussions happened briefly in private about this Charter proposal.
> 
> See attached for the new version.
> 
> Most notably
> 
> - it now mentions the URL of a web page
>    http://www.lara.prd.fr/ietf-its
>    cotnains documents presented at earlier meetings at IETF.
> 
> - reflects a little bit better the potential work with respect to
>    MANET/RoLL: write first requirements, then identify gaps, then if new
>    work is needed, otherwise do work in conjunction with the group which
>    'owns' the existing protocol.
> 
> I agree it is still a relatively large text.
> 
> Comments welcome.
> 
> Alex
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its