Subject: Re: [its] Please select area scoping the Charter

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Jul 2013 18:46:58 +0200

Romain, thank you for the email.

In this sense, do you think we should rather work on Mobile IPv6/80211p
handover aspects, rather than on IPv6-over-80211p (and rather than
working on V2V and 'geo-' aspects)?

Alex

Le 28/06/2013 09:51, Romain KUNTZ a écrit :
> Hello,
>
> On Jun 27, 2013, at 17:54 , Alexandru Petrescu
> <[email-masked]> wrote:
>> 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>
>>>> 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).
>>>
>>> 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?
>
> 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
>
>
>> 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:
>>>
>>> o  There might be multiple routers on the same link, thus hearing
>>> a new router does not necessarily constitute an L3 handover.
>>
>> 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.
>
> I think this can be solved by performing NUD (which is standard) as
> UMIP does.
>
> Best, Romain Kuntz (UMIP maintainer)
>
>
>> There is also DNA.
>>
>>> 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.
>>
>> 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)
>>> http://masimum.inf.um.es/fjrm/
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Jul 2013 18:51:25 +0200

Le 27/06/2013 19:07, Rex Buddenberg a écrit :
> 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.

Right, not to mention that IPv6 wouldn't need to run directly on a
communication channel PHY, but rather over a MAC.  The question then is
whether that MAC is 802.11p, or 802.11p plus something else.

Another question one is asked is whether it is reasonable to send
40bytes of IPv6 header, when that data is something short (4bytes) but
important (heading of the vehicle approaching).

Alex

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 3 Jul 2013 11:57:19 -0500

The question then is
whether that MAC is 802.11p, or 802.11p plus
> something else.

Another question one is asked is whether it is reasonable to
> send
40bytes of IPv6 header, when that data is something short (4bytes)
> but
important (heading of the vehicle

The Aeronautical Telecommunication Network (ATN) protocols had similar
questions. However, they were trying hard to save bits because the links
were extremely bandwidth limited (8 kbps shared).  But, there is a tendency
to forget about security.  I need to authenticate the message or it is worse
than worthless, it can cause harm and make systems react to none-existent
situations.

- Will

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Jul 2013 13:06:12 -0400

> questions. However, they were trying hard to save bits because the
    > links were extremely bandwidth limited (8 kbps shared).  But, there is
    > a tendency to forget about security.  I need to authenticate the
    > message or it is worse than worthless, it can cause harm and make
    > systems react to none-existent situations.

Once you include security and the need to identify senders and receivers,
suddendly the 40 bytes doesn't seem like such a big deal.

--
]               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: Romain KUNTZ <[email-masked]>
Date: Thu, 4 Jul 2013 09:13:47 +0200

Hello Alex,

On Jul 3, 2013, at 18:46 , Alexandru Petrescu <[email-masked]> wrote:
> handover aspects,

I don't think so, unless someone can point clear issues that arise when MIPv6 is running over 802.11p. So far I do not see any, but I would be happy to hear other's opinions.

Best,
Romain

> rather than on IPv6-over-80211p (and rather than

---

From: Andreas Festag <[email-masked]>
Date: Thu, 11 Jul 2013 08:02:22 +0000

Dear Alex,

Re the area scoping:

- I think the 1st option is relevant and to be done, e.g. enabling cars to discover their in-vehicle networks. It could run over ETSI TC ITS IPv6 over GeoNetworking.

- Option 3 sounds interesting, but I am not aware of a solution that can be standardized right away. So, this would require some research and analysis.

Kind regards,

Andreas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Tuesday, June 25, 2013 5:48 PM
To: [email-masked]
Subject: [its] Please select area scoping the Charter

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

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

---

From: <[email-masked]>
Date: Wed, 17 Jul 2013 05:20:41 +0000

Hi Alex,

Agree with Andreas that the 1st option is relevant, but I am also in favour of working on option 3, see the presentations that I gave on this topic on previous IETF ITS meetings.

This in favour for option 1 and 3!

Best regards,

Georgios

________________________________
Van: [email-masked] [[email-masked]] namens Andreas Festag [[email-masked]]
Verzonden: donderdag 11 juli 2013 10:02
To: Alexandru Petrescu; [email-masked]
Onderwerp: Re: [its] Please select area scoping the Charter

Dear Alex,

Re the area scoping:

Kind regards,

Andreas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Tuesday, June 25, 2013 5:48 PM
To: [email-masked]
Subject: [its] Please select area scoping the Charter

Yours,

Alex

---

From: Andreas Festag <[email-masked]>
Date: Wed, 17 Jul 2013 15:09:04 +0000

Hi Georgios,

Re option 3, I thought that this might be relevant not only for ITS use cases. Therefore it might be worth looking at existing requirements and solutions beyond ITS and take this into account. In any case, I share your favorites.

Kind regards,

Andreas

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 17, 2013 7:21 AM
To: [email-masked]; [email-masked]
Cc: Andreas Festag
Subject: RE: [its] Please select area scoping the Charter

Hi Alex,

Best regards,

Georgios

________________________________
Van: [email-masked]<mailto:[email-masked]> [[email-masked]] namens Andreas Festag [[email-masked]]
Verzonden: donderdag 11 juli 2013 10:02
To: Alexandru Petrescu; [email-masked]<mailto:[email-masked]>
Onderwerp: Re: [its] Please select area scoping the Charter
Dear Alex,

Re the area scoping:

Kind regards,

Andreas

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Tuesday, June 25, 2013 5:48 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [its] Please select area scoping the Charter

Yours,

Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jul 2013 10:15:54 +0200

> exactly this (and a lot more).

Rex,

Let me bring back this topic.

I agree that IP is agnostic with respect to the kinds of applications.
Applications of any level of criticality (less or most demanding) are
way above up the stack.  A UDP stream as much as an RTP real time video
stream are situated well above IP.

And, a road telecom wireless infrastructure operator would certainly be
interested in deploying highly available communications.

But traditional non-telecom operators - like cellular - rely extensively
on the use of Anchor points, i.e. Base Stations.  They make use of these
anchors which are, in fact, single points of failure.  This would
suggest to bring in another line to the above 3 principles of high
availability engineering, which contradicts the single point of failure.
  Or maybe another explanation.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jul 2013 11:37:05 +0200

Hello,

Thanks to everybody who expressed oppinion towards scoping the activity.
  Until now, the first topic of establishment of IP networking between
neighboring vehicles and vehicle-to-fixed-ITS-station seems to get most
support.

We need more discussion around scoping the Charter.

If you have not already done so, please prioritize one topic among the
three below, in order to scope the Charter.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jul 2013 14:08:55 +0200

> But traditional non-telecom operators - like cellular - rely extensively
                  ^non-vehicular telecom operators that is.

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 24 Jul 2013 08:37:25 -0700

Alex,

>From below:

> > anchors which are, in fact, single points of failure. 

There are two ways that I can quickly think of to 
deal with base stations.  They are single points 
of failure only if you let them.

One way to ameliorate the problem is to increase the density of base
stations so that the router in the vehicle has two or more base stations
to talk with.  

The other way (these are not mutually exclusive) is to relay (v2v) until
a vehicle is under a base station's footprint.  As others have noted,
this is highly volatile and dependent on (automobile) traffic density
but it can work.  

Both qualify is elimination of single points of failure. 

But they do highlight the need to observe the second principle: reliable
crossover.  Because you'll be doing lots of crossovers!  There are few
problems at layer 3 because of the connectionless nature of IP.  But
some layer 2 protocols contain some state; as do, of course, transport
layer connections.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 28 Jul 2013 18:46:41 +0200

Quick reminder - for the bar BoF it would be good if we have at least a
rough idea about which of the three areas to pursue with.

If you have not already expressed a preference, please do so, among the
options below:

Alex

Le 24/07/2013 11:37, Alexandru Petrescu a écrit :
> Hello,
>
> Thanks to everybody who expressed oppinion towards scoping the
> activity. Until now, the first topic of establishment of IP
> networking between neighboring vehicles and
> vehicle-to-fixed-ITS-station seems to get most support.
>
> If you have not already done so, please prioritize one topic among
> the three below, in order to scope the Charter.
>
> Alex
>
>> During recent discussions we mentioned 3 different areas to work
>> on. They are too many for a meaningful detail work.
>>
>> 1. establishment of IP networking between neighboring vehicles
>> using either MANET protocols or 1-hop ICMP protocol.
>>
>> 3. IPv6-based network-layer distribution of content in a
>> geographic area.
>>
>> Yours,
>>
>> Alex
>>
>>

---

From: Nabil Benamar <[email-masked]>
Date: Sun, 28 Jul 2013 16:56:34 +0000

---------- Forwarded message ----------
From: Nabil Benamar <[email-masked]>
Date: Sun, Jul 28, 2013 at 4:55 PM
Subject: Re: [its] Continue - select area scoping the Charter
To: Alexandru Petrescu <[email-masked]>

Hi Alexandru,

    The three topics are of interest...and if it's necessary to choose one
among the list, I vote for :
 layering of IPv6 over IEEE 802.11p communication technology.

On Sun, Jul 28, 2013 at 4:46 PM, Alexandru Petrescu <
[email-masked]> wrote:

>>> ______________________________**_________________ its mailing list
>>> [email-masked] https://www.ietf.org/mailman/**listinfo/its<https://www.ietf.org/mailman/listinfo/its>
>>>
>>>
>>>
>>
>> ______________________________**_________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/**listinfo/its<https://www.ietf.org/mailman/listinfo/its>
>>
>>
>>
>
> ______________________________**_________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/its<https://www.ietf.org/mailman/listinfo/its>
>

-- 
*Regards*
*Nabil Benamar*
*
*
**

*
--------------------------------------------------------------------------------
*

-- 
*Regards*
*Nabil Benamar*
*
*
**

*
--------------------------------------------------------------------------------
*

---

From: <[email-masked]>
Date: Sun, 28 Jul 2013 20:55:12 +0200

Dear all,
My faces are IPv6 over 11p - followed by car2car IP (MANET/ICMP).
Thanks
Regards
Dirk
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Sonntag, 28. Juli 2013 18:47
To: [email-masked]
Subject: Re: [its] Continue - select area scoping the Charter

Quick reminder - for the bar BoF it would be good if we have at least a rough idea about which of the three areas to pursue with.

If you have not already expressed a preference, please do so, among the options below:

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

Alex

Le 24/07/2013 11:37, Alexandru Petrescu a écrit :
> activity. Until now, the first topic of establishment of IP networking 
> between neighboring vehicles and vehicle-to-fixed-ITS-station seems to 
> get most support.
>