Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term - localisation sensors

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sun, 12 February 2017 17:46 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA8D129994 for <its@ietfa.amsl.com>; Sun, 12 Feb 2017 09:46:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNALgEFATvKv for <its@ietfa.amsl.com>; Sun, 12 Feb 2017 09:45:50 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE533129993 for <its@ietf.org>; Sun, 12 Feb 2017 09:45:49 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1CHjl4N026693; Sun, 12 Feb 2017 18:45:47 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A3A51203A19; Sun, 12 Feb 2017 18:45:47 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9260B201B4B; Sun, 12 Feb 2017 18:45:47 +0100 (CET)
Received: from [132.166.84.20] ([132.166.84.20]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1CHjk6Y018243; Sun, 12 Feb 2017 18:45:47 +0100
To: Rex Buddenberg <buddenbergr@gmail.com>, Jérôme Härri <jerome.haerri@eurecom.fr>, 'Michelle Wetterwald' <mlwetterwald@gmail.com>
References: <148052970170.9607.12043916621198119260.idtracker@ietfa.amsl.com> <d3cdd725-160f-b3cc-540b-00bbcec797c7@cea.fr> <CAF5de8t4TjMK5uLc4XK6O7WAsrd6LPCM29=UoNNg7VZS+6VVYQ@mail.gmail.com> <9fe84c68-897b-d5e3-ec5f-ba4e5af62f78@gmail.com> <011901d28393$c03d4e00$40b7ea00$@eurecom.fr> <1486752760.2398.15.camel@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <37e1edb8-7bb7-751c-b19f-268817dbd131@gmail.com>
Date: Sun, 12 Feb 2017 18:45:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <1486752760.2398.15.camel@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/2YY7N19kGf7q2qWS1TGa1ZxiFyU>
Cc: its@ietf.org
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term - localisation sensors
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Feb 2017 17:46:00 -0000

If the app-level data generated by these sensors (lat/long/alt, time) 
are put in UDP or other payloads of IP then it makes sense to talk about 
these sensors in these RSUs routers.

But, up to now, ITS deployments do this:
- POI over something else than IP
- TSA is not mandatory (Time Stamp Advertisement).

Alternatively, one would do something like this:
- POI as PIDF-LO data (RFC5491) over IP
- IP Router Advertisements containing timestamps (to be defined)
- NTP over IP to send timestamps.

Then we can talk here about location sensors in RSU router boxes...

Alex

Le 10/02/2017 à 19:52, Rex Buddenberg a écrit :
> Box <> function.
>
> If you understand the fragility and warts in radionav systems (GPS,
> Galileo, Glonass, Loran) then differential overlays to these systems
> makes a lot of sense.  And the most attractive place to put the
> differential reference receivers is in the roadside boxes.  The
> reference receiver function is a sensor function, not a routing one.
> But probably belongs in the same box.
>
>
> On Fri, 2017-02-10 at 12:49 +0100, Jérôme Härri wrote:
>> Hi Alex,
>>
>> It could actually be two different terms, depending of what we want
>> to say in the draft. The RSU is no longer a pure C-ITS name, as even
>> LTE-V2X adopted the LTE-UE operating in RSU mode for LTE-V2V
>> communications (meaning you do not need to be a eNB/base station to
>> be a RSU).
>> I would tend to think that the RSU is more a function/service than an
>> actual technology...but as I think the debate could be complex and
>> suggest to follow Michelle suggestion to keep the RSU as a 'bigger'
>> entity, and if you need it, a RSR as a potential sub-set of a RSU. As
>> Michelle said, a RSU is not a router  by default...
>>
>> BR,
>>
>> Jérôme
>>
>> -----Original Message-----
>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre
>> Petrescu
>> Sent: Friday 10 February 2017 12:37
>> To: Michelle Wetterwald
>> Cc: its@ietf.org
>> Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU
>> term
>>
>> Hi Michelle,
>>
>> Thank you for the suggestion.
>>
>> But making RSR a component of RSU is different than making RSU a
>> component of RSR, right?
>>
>> Despite the widespread belief that RSU would have something to do
>> with IP and Internet, rarely if ever was there an RSU connected to
>> Internet that forwarded IP packets - most RSUs are disconnected from
>> the Internet (the supposedly 'slaves' at FHWA) and the ones that are
>> connected to the Internet (supposedly the 'masters' at FHWA) are so
>> only in order to be SNMP-managed remotely, but not to forward.
>>
>> If we know of some RSU which has this 'forwarding' flag set to 1,
>> then we should talk about it, and call it a Router.
>>
>> The "ITS station" term is not a term at IETF.  We could re-use the
>> term "ITS station", but I would like to know whether "ITS Station" is
>> a Router or a Host?
>>
>> Yours,
>>
>> Alex
>>
>> Le 10/02/2017 à 12:18, Michelle Wetterwald a écrit :
>>>
>>> Hi Alex,
>>>
>>> Actually, an RSU is generally more than an RSR as it is an ITS
>>> station
>>> per se and may contain upper (e.g. service or even
>>> application) layers. I suggest to keep the definition of RSU in
>>> the
>>> text, as it is a widely used term, but clarify that an RSR could
>>> be
>>> one of the components of an RSU.
>>>
>>> Best regards, Michelle
>>>
>>> 2017-02-10 11:34 GMT+01:00 Alexandre Petrescu
>>> <alexandre.petrescu@gmail.com
>>> <mailto:alexandre.petrescu@gmail.com>>:
>>>
>>> draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term
>>>
>>> Hello IPWAVErs,
>>>
>>> We received multiple comments about the RSU term.  The strongest
>>> issue
>>> is that apparently there are conflicts between our assumption of
>>> RSU
>>> to be a router and FHWA(?) thinking RSU is more like an interface
>>> to a
>>> router, or something like a master-RSU controlling
>>> (slave?) RSUs. Unless FHWA tells us they agree RSU is a router, I
>>> will
>>> modify the following:
>>>
>>> Old:
>>>
>>> 2.  Terminology
>>>
>>> [...]
>>>
>>> RSU: Road Side Unit.
>>>
>>>
>>> New:
>>>
>>> RSR: Road Side Router; an IP router equipped with, or connected to,
>>> at
>>> least one interface that is 802.11 and that is an interface that
>>> operates in OCB mode.
>>>
>>>
>>> and substitute RSR for RSU throughout.
>>>
>>> This old 'RSU' term, now RSR, is absolutely needed in the draft
>>> when
>>> discussing IP handovers and Mobile IP.
>>>
>>> Alex
>>>
>>>
>>> _______________________________________________ its mailing list
>>> its@ietf.org <mailto:its@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/its
>>> <https://www.ietf.org/mailman/listinfo/its>
>>>
>>>
>>>
>>>
>>> -- Michelle Wetterwald michelle.wetterwald@gmail.com
>>> <mailto:michelle.wetterwald@gmail.com>
>> _______________________________________________
>> 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
>