Subject: Re: [its] Updated proposal of Charter ITS

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Apr 2013 16:48:59 -0400

1) Let's drop the details of enumerated use cases from the charter.
   They should be mentioned, but they don't need to be enumerated.
   (in particular the spacesuit example doesn't belong in the charter, 
   but it may well be important in a use case document)

2) this paragraph is too big:

> The smart-city use case is also important for networking country- and
> world-wide transports.  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.

Instead, let's write:

+ The smart-city use case should lead to development of
+ requirements and services for transports within cities, scaling 
+ up to the size of a country or state highway/public-transit system.

and then:

+ ITS will consider and MAY profile technologies from MANET
+ and/or from ROLL adapted to this smart-city use case.  Extensions 
+ to routing protocols are out of scope, but requirements for those
+ extensions are in scope. 
+ ETSI IPv6 over GeoNetworking is specifically in scope.

(OLSRv2 is in scope because you said that MANET is in scope)

The following is, I think, content-free in a charter, remove it.

>It is considered that several existing IETF protocols could and should
>be reused in the communication scenarios described above.  For the
>V2V2V scenarios - the protocols OLSR, AODV and RPL should be
>considered.  For the IP addressing and mobility aspects of in-vehicle
>subnetworks, single-subnet V2V, and single-subnet V2I, the following
>protocols should be considered: IPv6, Mobile IPv6, ND, DHCPv6, PMIPv6.

instead write:

+ For the IP addressing and mobility aspects of in-vehicle subnetworks,
+ single-subnet V2V, and single-subnet V2I, the WG will consider and 
+ if necessary, profile, existing IPv6 network protocols.

Under Potential new work items, remove any mention of extensions.
That won't fly.  If an extension is necessary, this group will either be
rechartered, or the work done in the other WG.

I think that IP-over-FOO where FOO=802.11p should be stated explicitely.
It might be a NOOP, just use IP-over-802.3, or it might not.  Many think
that we made a mistake not having IP over 802.11.

I think that other supplementary work items list is unnecessary.

The bar bof in Orlando does not constitute a meeting. Don't count it.
That way you get two BOF opportunities.

It's better to have fewer focused goals and an opportunity to recharter.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Apr 2013 20:52:35 +0000

> It's better to have fewer focused goals and an opportunity to recharter.

+1

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 3 Apr 2013 02:14:11 +0200

> (OLSRv2 is in scope because you said that MANET is in scope)
The OLSR should not be in scope, as we may agree of using geonetwork
for ITS then I think it is not manet.

AB

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Apr 2013 17:00:00 +0200

Le 02/04/2013 22:48, Michael Richardson a écrit :
[...]
> + ETSI IPv6 over GeoNetworking is specifically in scope.

would another method of disseminating the information geographically be 
specifically in scope as well.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Apr 2013 11:42:39 -0400

>>>>> "Abdussalam" == Abdussalam Baryun <[email-masked]> writes:

    Abdussalam> The OLSR should not be in scope, as we may agree of
    Abdussalam> using geonetwork 
    Abdussalam> for ITS then I think it is not manet.

OLSR is RFC3626, a MANET product, and OLSRv2 is a MANET draft.
So, my point is that ITS does not need to list OLSR (or DYMO or...) as
in scope if it lists MANET product as in scope.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Apr 2013 11:45:35 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:

    Alexandru> would another method of disseminating the information
    Alexandru> geographically be 
    Alexandru> specifically in scope as well.

I think it is important to list GeoNetworking, because we know about it,
and we know how to liase with ETSI and how and who shall hold change
control over an ETSI specification.

If another mechanism is proposed, the question about could it be used
would depend upon whether we need to make any changes to that mechanism,
and if we had to, how would we do it.  That might require an amendment
to the charter, or it might not.  Don't try to anticipate every
situation with policy,  let the chairs and ADs apply common sense.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Apr 2013 18:11:48 +0200

> control over an ETSI specification.

Right.

> situation with policy,  let the chairs and ADs apply common sense.

Ok.

Alex

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 3 Apr 2013 21:50:14 +0200

> in scope if it lists MANET product as in scope.

I think it is better not making MANET product or others in charter as
well. We need first to be sure to produce for ITS, because other
groups don't consider all ITS requirements. IMO, the ITS needs a
product that is able to work in an environment of many transport nodes
communicating with many Lossy nodes and many mobile nodes,

AB

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Apr 2013 20:25:17 -0400

>> in scope if it lists MANET product as in scope.

    Abdussalam> I think it is better not making MANET product or others
    Abdussalam> in charter as well. We need first to be sure to produce
    Abdussalam> for ITS, because other groups don't consider all ITS
    Abdussalam> requirements. IMO, the ITS needs a product that is able
    Abdussalam> to work in an environment of many transport nodes 
    Abdussalam> communicating with many Lossy nodes and many mobile nodes,

If it is not in the charter, they it won't be clear to others that we 
intend to talk about it, and the charter will flounder.

If we charter to create another OLSRv2 or RPL or DYMO without being
clear why we can't use those (by being chartered to look at them and do
gap analysis!), then we will be told: no, go to MANET.

That's why the charter references technologies that we will build upon
and possibly create requirements to improve.

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 03 Apr 2013 18:30:55 -0700

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: [email-masked]
>   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.
> 
> 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
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 4 Apr 2013 21:08:03 +0200

Hi Michael,

I agree with you. I agree that all charters in IETF are able to make
use of all IETF products (MANET, ROLL, 6MAN, etc), so I think the ITS
charter may use any other WG product by default, but not need to
mention. I agree that we need to be clear why we don't use some or why
some will not be used in ITS industry.

AB

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 08 Apr 2013 15:16:07 +0200

Le 04/04/2013 02:25, Michael Richardson a écrit :
> Abdussalam> using geonetwork Abdussalam> for ITS then I think it is
> not manet.
>
>>> So, my point is that ITS does not need to list OLSR (or DYMO
>>> or...) as in scope if it lists MANET product as in scope.
>
> If it is not in the charter, they it won't be clear to others that
> we intend to talk about it, and the charter will flounder.
>
> clear why we can't use those (by being chartered to look at them and
> do gap analysis!), then we will be told: no, go to MANET.
>
> That's why the charter references technologies that we will build
> upon and possibly create requirements to improve.

So Michael - what you're saying is that we should say 'MANET' in the
Charter proposal, and should not say 'OLSR' nor 'RPL' etc.

I think Abdussalam says that the protocols we may work on may be MANET
protocols (OLSR, RPL) or not.

That means that saying 'MANET' in charter is fine, and avoid saying
'OLSR' in charter.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 08 Apr 2013 15:36:50 +0200

Le 04/04/2013 03:30, Rex Buddenberg a écrit :
> What I did do -- comment in line. What I did not do -- reorganize.
>
>
>
>> Intelligent Transportation Systems at IETF Draft Charter Proposal
>> March 17th, 2013 http://ietf.org/mailman/listinfo/its
>>
>>
>> ---------------------------------------- Current Status: Informal
>> bar BoF
>>
>> Chairs: TBD TBD
>>
>> Assigned Area Director: TBD ()
>>
>> Mailing list Address: [email-masked] To Subscribe:
>> https://www.ietf.org/mailman/listinfo/its Archive:
>> 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.
>
>> 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.
>
> 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).
>>
> orders of magnitude) coupled with higher error rates than experienced
> in a wired internet (also by orders of magnitude).
>
>> 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.
>
>> Using IP should not introduce new risks, especially when
>> safety-specific applications are involved.
>
> Compared to what?
>>
>> 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.
>>
>> Due to the mobile nature of the system, several problems exist
>> with respect to IP addressing and route establishment such that IP
>> 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).
>>
>> 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.
>>
>> 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
> 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.
>>
>> 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.
>

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

I think we will first write requirements and scenarios, maybe problem 
statement, and maybe if time allows a gap analysis.

> 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

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

>> http://www.lara.prd.fr/ietf-its cotnains documents presented at
>> earlier meetings at IETF.
>>
>> 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.
>>
>> Alex _______________________________________________ its mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Apr 2013 10:33:57 +0200

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

Some of the SDOs see participants that are subscribed to this list as
well.  Some participants expressed interest in participating here:
provide feedback, and ask for feedback relevant to that SDO.

Not all SDOs listed above are interested in participating at IETF.  I am
trying to understand which ones are most likely to do so.  To that end I
will have to contact the liaison managers at IETF.

As a side note, I was pointed to an additional emerging group about
automotive at W3C:
http://www.w3.org/community/autowebplatform/

Alex

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 9 Apr 2013 13:21:41 +0200

Hi Rex,

I think ITS is concerned with L4 and above, so Layer 3 (L3) will be
based on the IP  geonetwork other standards, comment below,

> ITS is about several aspects of extending the internet to mobile

Where did you ignore the intelligence, in MANET mostly no intelligence
is requirement, but in ITS it is requirement (MUST).

Regards
AB