Subject: [its] Please select area scoping the Charter

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Jun 2013 17:48:28 +0200

Hello participants to ITS email list,

During recent discussions we mentioned 3 different areas to work on.
They are too many for a meaningful detail work.

Please select area scoping the Charter, prioritizing according to the
environment you work on.

1. establishment of IP networking between neighboring vehicles using
     either MANET protocols or 1-hop ICMP protocol.

2. layering of IPv6 over IEEE 802.11p communication technology.

3. IPv6-based network-layer distribution of content in a geographic
    area.

Yours,

Alex

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2013 13:54:08 -0400

> either MANET protocols or 1-hop ICMP protocol.

Do you mean address allocation or routing?

    > 2. layering of IPv6 over IEEE 802.11p communication technology.

I am not convinced this isn't a nop. (empty set)

    > 3. IPv6-based network-layer distribution of content in a geographic

This interests me the most. *MY* use cases are idiosyncratic and very
anarcho-syndicalist, and as such suffer from "no way to make a buck" problem.

I think that it does not require, at this point, standardization, as I am not
convinced the parties who want/need to do this are actually at the IETF table yet.

I think that a group of funded researchers could prototype such a thing using
existing well defined protocols, and having demostrated such a thing to an
appropriate set of equipment (by this, I mean, "vehicle") vendors.  At that
point, a specification would ensue.

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

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 26 Jun 2013 07:40:49 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Richardson
> 

[[DR]] I was actually asking myself the same question. Did anybody do an analysis / requirements about what work needs to be done here? Assuming it's not a nop - is this something specific to its? Or rather in a broader scope (intarea?)

Regards,

Dan

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Jun 2013 15:08:08 +0200

Hello Michael,

Thank you for the message.

> Do you mean address allocation or routing?

I think it depends on what discussion may bring in here, if interest is 
expressed.

I personally think about a concept like in this video, in which vehicles 
passing each other do IPv6 exchanges:
http://youtu.be/RqC0a9bYQCE?t=5m49s

E.g. the siren scenario, or the video from the front vehicle allowing 
driver to see.

> point, a specification would ensue.

Well, if interest is expressed in this as well, it could be further framed.

The 'geo-' aspect is deeply rooted in vehicular electronics, given the 
wide availability of GPS data.  However, how would that integrate with 
networking concepts is multi-faceted.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Jun 2013 16:55:09 +0200

Le 26/06/2013 09:40, Romascanu, Dan (Dan) a écrit :
>
>
>
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Michael Richardson
>>
> [[DR]] I was actually asking myself the same question. Did anybody
> do an analysis / requirements about what work needs to be done here?
>  Assuming it's not a nop - is this something specific to its? Or
> rather in a broader scope (intarea?)

First, I am interested in what do the others think about this topic?

I guess I may be the only apparent voice about this topic, but here is
how I see the situation.

Doing IPv6-over-80211p is relatively straightforward in implementation.

There may be some modifications needed to a driver 802.11a to become a
802.11p; these are link-layer driver modifications.

There may be some modifications needed in government legislation about
the limit of power levels, and interpretation of the relationship
between 'IP' and 'safety apps'.  E.g. if I am not wrong US has limits
like 40dBm whereas EU has 33dBm (imagine a vehicle imported from here
there), and both consider IP is not about safety but rather entertainment.

There may be modifications to ICMP needed such that the movement
detection procedure of Mobile IPv6 works ok on a non-BSSID channel (the
802.11p has no BSSID, hence no subnet structure).  Currently this doesnt
work because the UMIP software gets random behaviour when hearing two
different prefixes on the same link (they are supposed to be 2 different
links).  To address this there are several directions of solutions
possible: (1) use 'geo-' concepts, e.g. by GPS know you're closer to
that RSU than the other, so trigger Mobile IP movement detection
procedure accordingly, (2) have RSU RAs enhanced with non 'geo-'
relationships such to overcome the limits of GPS non working in tunnels,
(3) others yet to imagine.

An Internet-Draft about IPv6-over-802.11p-without-mobility could be very
simple: just state IP over 80211p works fine is already a huge step
forward from the current informal statements that IP is prohibited on
80211p.

These modifications may not impact at all the IP stack software, or just
a little bit.

In this sense, this indeed may be an activity that requires little work
specific to vehicular communications, but which may relate to intarea,
to 6man WG, and to Mobile IPv6 protocol.

This is my biased opinion,

Alex

---

From: Francisco Javier Ros Muñoz <[email-masked]>
Date: Thu, 27 Jun 2013 17:20:11 +0200

Hi Alex,

El 27/06/2013, a las 16:55, Alexandru Petrescu escribió:
<snip>
> links).

This seems to be an implementation issue in uMIP, and not an 802.11p-specific problem. RFC 3775 warns us about such situation:
o  There might be multiple routers on the same link, thus hearing a
      new router does not necessarily constitute an L3 handover.

o  When there are multiple routers on the same link they might
      advertise different prefixes.  Thus even hearing a new router with
      a new prefix might not be a reliable indication of an L3 handover.
Best,
fran
--
Francisco J. Ros, PhD
Dept. of Information and Communications Engineering
University of Murcia, Murcia (Spain)
http://masimum.inf.um.es/fjrm/

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Jun 2013 17:54:55 +0200

Hi Francisco,

Le 27/06/2013 17:20, Francisco Javier Ros Muñoz a écrit :
> Hi Alex,
>
> El 27/06/2013, a las 16:55, Alexandru Petrescu escribió: <snip>
>> detection procedure of Mobile IPv6 works ok on a non-BSSID channel
>>  (the 802.11p has no BSSID, hence no subnet structure).  Currently
>>  this doesnt work because the UMIP software gets random behaviour
>> when hearing two different prefixes on the same link (they are
>> supposed to be 2 different links).
>
> This seems to be an implementation issue in uMIP,

Has one seen this issue solved somehow?  How can I get Mobile IPv6
handovers between two different 802.11p Access Points?

What do you think?

This may only be an implementation issue.  Maybe largely identified
within uMIP code.  But it may be that this gets redirected to one other
kind of issue: source-selection, multiple source address, multiple
Care-of Address.  It may be that uMIP people say that's a much
larger issue than just Mobile IP, which uMIP excells at.

> and not an 802.11p-specific problem.

I tend to agree, it is largely a problem with multiple prefixes on the
same link, not necessarily 802.11p.

However, one may note that among all 802 wireless links the .11p is the
only one which has no structure naturally leading to a subnet (no
'broadcast domain', no ESSID, no messages to create/delete such link, or
to associate to one).  This is so in purpose, of course, to realize very
fast exchanges - avoid the need to first Associate to a network, and all
3 subsequent messages.

> RFC 3775 warns us about such situation:
>

Right, and in that case there should exist a logic for a Host to choose
between these links, and to determine whether a handover is really
present or not.

This logic has been implemented under various forms by various people.
None is standard.

There is also DNA.

> advertise different prefixes.  Thus even hearing a new router with a
>  new prefix might not be a reliable indication of an L3 handover.

That is right.  RFC3775 warns about that situation.

However, in a 802.11p deployment of RSUs (Road Side Unit), there are few
constants:
- there are no multiple prefixes on the same link.
- each prefix is actually belonging to one particular RSU, and that
   particular RSU is in a different subnet.
- hearing a different prefix means a different subnet.
- there are no two same prefixes on the same subnet.

The link-layer problem is that there is no link, one can't distinguish it.

I suppose that this is also a reason why ETSI and earlier came up with
GeoNetworking, because GPS data can help disambiguate (although it does
not work when there is no GPS data).

Alex

>
> Best, fran -- Francisco J. Ros, PhD Dept. of Information and
> Communications Engineering University of Murcia, Murcia (Spain)

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 27 Jun 2013 10:07:28 -0700

On Thu, 2013-06-27 at 16:55 +0200, Alexandru Petrescu wrote:
> and both consider IP is not about safety but rather entertainment.

???  This makes no sense.  IP is about a set of communications
protocols.

'safety' usually implies some high availability requirements.  There are
three principles of high availability engineering:

- elimination of single points of failure.  In comms systems this
usually boils down to altroutes and backup power.  Provisioning issue,
has nothing to do with choices of technology ('IP' or non-IP).  

- reliable crossover.  In redundant systems the crossover switch itself
can become a single point of failure.  And this is where IP shines:
routers do reliable crossover all day every day.  I don't know of any
other comms technology that solves this problem by protocol design or
solves it as elegantly.

- detection of failures as they occur.  The function of a management
system, particularly fault management.  SNMP is designed to do exactly
this (and a lot more).  

Meet these principles for the most demanding applications (remember that
'IP' is application-agnostic) and you have a super-solution for
everything else.

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Fri, 28 Jun 2013 11:05:22 +0900

Hi all,

I support to have the topic "establishment of IP networking between
neighboring vehicles" that is one of essential requirements. But, I'm
willing to extend it. In other words, we should not limit it only to
vehicles. So, I suggest to revise the text as:

"establishment of IP networking between neighboring nodes including
vehicles and infrastrcutures"

Cheers.

On Thu, Jun 27, 2013 at 10:08 PM, Alexandru Petrescu <
[email-masked]> wrote:

> http://youtu.be/RqC0a9bYQCE?t=**5m49s<http://youtu.be/RqC0a9bYQCE?t=5m49s>
>
> ______________________________**_________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/its<https://www.ietf.org/mailman/listinfo/its>
>

-- 
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/

---

From: Romain KUNTZ <[email-masked]>
Date: Fri, 28 Jun 2013 09:51:21 +0200

Hello,

> handovers between two different 802.11p Access Points?

This problem can be solved using the "MnRouterProbes" and "MnRouterProbeTimeout" options of UMIP, which makes UMIP avoiding switching to another router if the current one is still reachable. This behaviour is disabled by default. More below (from the UMIP manpage):

MnRouterProbes " "number" ";"

 Indicates how many times the MN should send Neighbor Unreachability
 Detection (NUD) probes to its old router after receiving a Router
 Advertisement (RA) from a new one. If the option is set to zero or
 the new router advertises a strictly higher default preference value
 than the old one (as defined in RFC 4191), the MN will move to the new
 router straight away.
 
 Default: 0

"MnRouterProbeTimeout " "decimal" ";"
 
 Indicates how long (in seconds) the MN should wait for a reply during
 a access router Neighbor Unreachability Detection probe.  If set, it
 overrides any default Neighbor Solicitation Retransmit Timer value
 greater than MnRouterProbeTimeout.  For example, if the interface
 Retransmit Timer is 1 second, but MnRouterProbeTimeout is just 0.2
 seconds, the MN will only wait 0.2 seconds for a Neighbor Advertisement
 before proceeding with the handoff.

 Default: 0.0

> This logic has been implemented under various forms by various people.

I think this can be solved by performing NUD (which is standard) as UMIP does.

Best,
Romain Kuntz (UMIP maintainer)

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

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 28 Jun 2013 08:07:53 -0500

Agree.  One bit of advices / history lesson.  After the tcpsat working group, I believe there was a lot of reluctance to establish working groups at IETF to solve particular industry specific problems.  I certainly agree as generally problems that initially may appear to be industry specific actually occur in many places. For example in tcpsat the initial problem was how to get TCP to work better over long delays.  But, in reality, the problem is (delay x bandwidth) and is certainly not unique to satellite communications.

I guess the point I am trying to make is to  think beyond ITS when looking at the problem space so that any solutions are more general.

-- Will

________________________________
From: Jong-Hyouk Lee <[email-masked]>
Date: Thu, 27 Jun 2013 21:05:22 -0500
To: Alexandru Petrescu <[email-masked]>
Cc: Michael Richardson <[email-masked]>, Jong-Hyouk Lee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [its] Please select area scoping the Charter

Hi all,

I support to have the topic "establishment of IP networking between neighboring vehicles" that is one of essential requirements. But, I'm willing to extend it. In other words, we should not limit it only to vehicles. So, I suggest to revise the text as:

"establishment of IP networking between neighboring nodes including vehicles and infrastrcutures"