Subject: [its] Scenarios, potential topics...

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Mar 2012 13:38:49 +0100

Welcome to the ITS list at IETF, an informal discussion.

Earlier at IETF discussions related to vehicular communications happened
in several groups (MEXT, AUTOCONF, 6MAN, to name but a few), drafts were
published [*].  At times people expressed interest to meet f2f.  Now
there is this email list.

Participants are solicited to work on the topic of using IP in
Intelligent Transportation Systems.  The term ITS is a placeholder that,
in my oppinion, is generic enough to cover many aspects of vehicular
communications; vehicles may be wheeled, watered, flown.  Ambulance,
fire engine, coastal ship are particular examples.

Scenario :  A router deployed in a moving vehicle, uses its egress
interface to connect to larger-area access network(s) or to other
vehicles.  Should it use IPv6-over-LTE?  Should it use Mobile IP?

Example potential work items:
- Reqs for IPv6 in vehicular networks
- V2V with RA
- V2R(oadside)
- VIN and IPv6 addressing
- ULA and IPv6 for vehicles
- IPv6 multicast
- ISO TC204
- IPv6 over 802.11p (IPv6-over-foo).
- open.

I am told about other vehicular drafts and discussions, that I have not
cited, existed and still exist (about e.g. ecall).  I am interested to
learn about all the vehicular activities at IETF.

Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO.

Open to discussion: what are the scenarios?  What are the potential work
items?  What might be needed, if anything at all?

Alex
[*]
draft-ietf-mext-nemo-ro-automotive-req-02
draft-jhlee-mext-mnpp-00.txt, October 2009.
draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009.
draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010.
draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008.
draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011.
draft-petrescu-mip4-tuntype-change-00.txt, March 2011.
draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010.
draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010
draft-rosen-ecrit-ecall-04.txt, March 2010.
draft-singh-simple-vehicle-info, July 2007.
draft-sijeon-mext-nemo-pmip6-00, Oct. 2010.
draft-bauer-mext-aero-solspace, Sep. 2009.
draft-bauer-mext-aero-topology, Sep. 2009.
draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008.
draft-rosen-ecrit-ecall-05.txt, March 2012.

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 16 Mar 2012 09:56:27 -0400

> items?  What might be needed, if anything at all?

Hi Alex (and others).  In my opinion, there are ways to use
existing mechanisms with acceptable results under nominal
conditions.  By "nominal", I mean where we always have at
least one link available and handoffs between access
networks can be phased in time cleanly enough that the
mobility signaling all happens and has time to do its job
without the applications noticing.

In cases where their are temporal gaps in connectivity
that are long enough for the applications to notice, I
don't think anything can be done in the network layer,
which is where much ITS work has focused.  Unfortunately,
it seems that applications behave in strange and
unexpected ways visible to the user in these cases,
and to some extent, I think this is because they don't
necessarily have good APIs or ways of knowing what's
going on down below.

Given an expectation that connectivity is widespread, but
not 100% pervasive, I think a useful contribution at this
point is to discuss and work on upper-layer mechanisms that
can look at an API from lower layers and do intelligent
things or give the user a little bit more insight about
what's going on in terms of the application.

Since in ITS scenarios, the router may be separate from
where the applications are running, or may have interfaces
to radios that are a hop away from it, some form of
relaying connectivity information through the ITS network
would be useful.  This is related to, but maybe an
extension of, the kind of problem discussed in:
http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-00

-- 
Wes Eddy
MTI Systems

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Mar 2012 19:38:46 +0100

Hello Wes, and participants,

Let me comment on some aspects.

If I understand correctly, the main point you make is that work may be
needed for vehicular at application layers, and maybe not that much at
network layer.  The reason you mention is that often a wide-area network
is available in most places where a vehicle may be.  And because of that
the handovers may not be that important to look at.

On one hand I agree that many scenarios I have looked at, especially in
the ETSI ITS domain, ressemble to what applications and services would
do, and not necessarily the networking IP layer.

These kinds of application-layer services may indeed be needed.  If
there is interest in looking at them, let us be vocal about it and see
whether something is needed.

Second, you cite a draft draft-ivancic-mobopts-modemlpa-00 that I
quickly looked at.  In a sense, this is looks to me more about how to
connect a modem to a router.  In some aspects to which I have interest
there is indeed a need to connect a modem to a router in a more
automatic way.  This is often the case when new link layers come to life
(as is LTE nowadays) - there is a lapse of time during which the
respective modem is not yet widespread use nor standard.  Other case is
when each of those modems is a PC in itself, at which point one may look
at building bigger Mobile Routers made of small routers, for various
reasons (one has a SIM, other has the satellite, and so forth).  To make
them interact in a dynamic way maybe yes some formatted data exchange
protocol is needed.

Third, I do think that working at IP layer for vehicular communications
does make sense.  Let me cite one particular example: when building on
paper a network of vehicles one often starts with the phrase "the IP
addresses are hardcoded by the manufacturer of the vehicle" - but how is
that done?

Other potential works at IP layer is about how to exchange routes
between vehicles, without assistance of the infrastructure.

Finally, it may be possible to use existing IP networking mechanisms
with acceptable results, as you say, but I think there may be a need for
integration between these technologies, as things may not be
straightforward.   I have in mind these ULA addresses - yes, there are
RFCs and implementations about them - but how would they work in a
vehicular scenario where infrastructure is not available (some times).

I am listening to comments.

Just some thoughts,

Alex

Le 16/03/2012 14:56, Wesley Eddy a écrit :
>> Open to discussion: what are the scenarios?  What are the potential
>> work items?  What might be needed, if anything at all?
>
> Hi Alex (and others).  In my opinion, there are ways to use existing
> mechanisms with acceptable results under nominal conditions.  By
> "nominal", I mean where we always have at least one link available
> and handoffs between access networks can be phased in time cleanly
> enough that the mobility signaling all happens and has time to do its
> job without the applications noticing.
>
> In cases where their are temporal gaps in connectivity that are long
> enough for the applications to notice, I don't think anything can be
> done in the network layer, which is where much ITS work has focused.
> Unfortunately, it seems that applications behave in strange and
> unexpected ways visible to the user in these cases, and to some
> extent, I think this is because they don't necessarily have good APIs
> or ways of knowing what's going on down below.
>
> Given an expectation that connectivity is widespread, but not 100%
> pervasive, I think a useful contribution at this point is to discuss
> and work on upper-layer mechanisms that can look at an API from lower
> layers and do intelligent things or give the user a little bit more
> insight about what's going on in terms of the application.
>
> Since in ITS scenarios, the router may be separate from where the
> applications are running, or may have interfaces to radios that are a
> hop away from it, some form of relaying connectivity information
> through the ITS network would be useful.  This is related to, but
> maybe an extension of, the kind of problem discussed in:

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 19 Mar 2012 15:23:42 -0400

Alex,

If we're going to discuss the MLPA draft, we also need to include DLEP  
from the MANET working group. I'll be interested in attending your  
discussion in Paris.

Regards,
Stan

On Mar 19, 2012, at 2:38 PM, Alexandru Petrescu wrote:

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

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 19 Mar 2012 14:02:08 -0500

> the handovers may not be that important to look at.

Actually, that is not what modemLPA is about.  It is about providing physical-layer and link-layer situational awareness to the upper layers, be it the network layer, or perhaps even the application layer and providing this information to entities that may not be directly connected to the modem (or crypto device). Such information could aid in handovers or suspend or awaken store-carry-and-forward processing when links go down or come up or reroute when link become unstable.

- Will

More comments below
 
VVV
 VV
  V

> vehicular scenario where infrastructure is not available (some times).

Alex, do you have some sort of Concept of Operations document on what you want the vehicle to be able to do and what types of information will be passes around?  Thanks,

- Will

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Mar 2012 21:07:09 +0100

FYI, Will just said below text.

-------- Message original --------
Sujet: Re: [its] Scenarios, potential topics...
Date : Mon, 19 Mar 2012 14:02:08 -0500
De : Ivancic, William D. (GRC-RHN0) <[email-masked]>
Pour : Alexandru Petrescu <[email-masked]>
Copie à : Wesley Eddy <[email-masked]>, "[email-masked]" <[email-masked]>

> the handovers may not be that important to look at.

Actually, that is not what modemLPA is about.  It is about providing 
physical-layer and link-layer situational awareness to the upper layers, 
be it the network layer, or perhaps even the application layer and 
providing this information to entities that may not be directly 
connected to the modem (or crypto device). Such information could aid in 
handovers or suspend or awaken store-carry-and-forward processing when 
links go down or come up or reroute when link become unstable.

- Will

More comments below

VVV
  VV
   V

> vehicular scenario where infrastructure is not available (some times).

Alex, do you have some sort of Concept of Operations document on what 
you want the vehicle to be able to do and what types of information will 
be passes around?  Thanks,

- Will