Re: [its] Updated proposal of Charter ITS

Le 04/04/2013 03:30, Rex Buddenberg a écrit :
> 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,
[..]
> Why recite this?  Aside from the obvious overlap?

Because they all talk IP and vehicle in their confidential documents.

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

YEs.

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

If you ask me, and compared that way, I would highly give preference to
a layer 3 focus.  On another hand, other layers may come into play as
well (e.g. DNS is layer 7 but may be needed for dynamic layer-3 address
auto-configuration).

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

I agree.

>> 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 think we will first write requirements and scenarios, maybe problem 
statement, and maybe if time allows a gap analysis.

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

Ok, send it in.  We may need it.  Maybe we could write a draft with its 
contents and fit it in the Charter proposal.

Alex

> 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
>
>
> _______________________________________________ its mailing list
> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>
>