Subject: [geonet/its] mobile access routers and geoaware intermediate routers

From: Alison Chaiken <[email-masked]>
Date: Mon, 11 Nov 2013 22:14:27 -0800

I've just finished watching the video from the BoF, although I haven't
quite caught up with the email yet.

One possible objection to geonetworking as described in Georgios'
slides stems from the implicit suggestion (slide 4) that only source
nodes and access routers need to know about lat/lon position.
Geoaware routers can exist at intermediate points in the routing, and
making this possibility explicit may help to clarify the proposal.   I
suspect that having potentially geoaware routers at each stage of the
chain is Georgios' intention, but he has omitted this possibility for
simplicity in his illustrations.

Another way of considering the problem is to create a taxonomy of
geoaware routers.     There are geoaware sources, geoaware recipients,
and geoaware intermediate routers.  One obvious type of geoaware
intermediate routers is access routers.      QUESTION: are there
intended to be geoaware intermediate routers that are not access
points?

Considering only source and access routers to be geoaware, the
question arises, why don't these endpoints simply use a high-level
protocol to exchange IP addresses or hostnames?   If both sources and
access routers are permanently installed infrastructure nodes, then
assuredly they can learn each others' hostnames and not worry about
geoawareness more than one time.

Mobile access routers present a more intriguing use case.   Consider
an airplane flying over a forest with many embedded sensors.    The
airplane will serve as an access router for the sensors but its own
coordinates are dynamic.   Once the plane returns to the hangar, its
access router role is effectively irrelevant.  Equivalently, consider
a parade on a city street.   Police cars that are directing traffic
around the closed streets that host a parade are a similar case, as
are emergency vehicles.   The reasons why these mobile access routers
will benefit from a geonetworking protocol is clear.

-- 
Alison Chaiken                           [email-masked]
650-279-5600                            http://{she-devel.com,
exerciseforthereader.org}
It's a bug that cars were invented before computers.    -- Eric Schmidt

---

From: Melinda Shore <[email-masked]>
Date: Mon, 11 Nov 2013 21:53:56 -0900

> simplicity in his illustrations.

This was a really useful piece of email and there were
some extremely important points in it, and I'm going to
reframe them in terms of process issues, with an eye
towards the things that need to be done and the conditions
which need to be satisfied to get some work chartered.
(I really like the proposal to work on a taxonomy of
geoaware routers.)

The main thing is that there needs to be a crisp problem
statement, and while you need to make the case that
the problem *can* be solved and it can be solved by
the set of people involved in advancing the work (in
concert with other interested IETF participants), it's
a good idea to stay away from particular solutions,
particularly when they're as problematic as putting new
function into DNS.  It's good and necessary to describe
the characteristics of a needed directory service, but
that's not the same thing as describing how DNS is going
to be used.

Another thing is making sure that you've got a credible
set of real-world use cases, and this is where your
email was particularly valuable.  It may be worth more
discussion with remote sensing specialists.

But again, it's extremely important to have a clear,
crisp problem statement in which you lay out a high-level
description of the problem and then break it down into
component problems which would need to be solved - those
are potential work items.  Figure out what's a must-have
and what's a nice-to-have.  Right now the problem statement
is too closely meshed with a particular solution (one that
has already encountered resistance) and I think the first
job is getting the problem statement extricated from
what's been written so far, and boiling it down to a few
clear, coherent points.

Melinda

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Nov 2013 15:15:26 +0100

Hi Alison,

Le 12/11/2013 07:14, Alison Chaiken a écrit :
[...]
> geoaware routers.

Terminology discussion can only help towards a common problem statement.

Something like this:

geo-aware router : a router which knows its geographical position
                    (either by live or pre-configured means).

There may be other needed terms.

> There are geoaware sources, geoaware recipients, and geoaware
> intermediate routers.  One obvious type of geoaware intermediate
> routers is access routers.

Right, this taxonomy sounds as a classificaton me.

We could capture this somewhere.

> QUESTION: are there intended to be geoaware intermediate routers
> that are not access points?

Good question.  One may wonder what is an access point as well (is it
the same as the 'Access Point' defined in RFC3753 'Mobility-Related
Terminology' page 13?).

> protocol to exchange IP addresses or hostnames?   If both sources
> and access routers are permanently installed infrastructure nodes,
> then assuredly they can learn each others' hostnames and not worry
> about geoawareness more than one time.

This is intriguing.

> Mobile access routers present a more intriguing use case.

A person at the BoF told me in private about 'mobile RSU'.  There is an
ongoing project about it.  I was surprised and questioned: is it mobile
or is it RSU? (because in my mind RSU is fixed by definition).  There is
an answer to that, and it deserves being captured.

> Consider an airplane flying over a forest with many embedded sensors.
> The airplane will serve as an access router for the sensors but its
> own coordinates are dynamic.   Once the plane returns to the hangar,
> its access router role is effectively irrelevant.

This is a use-case that deserves being captured in the use-cases
discussion, brainstorming document.

If by this you imply a 'mobile access router', please allow me to tell
you that the other person who spoke 'mobile RSU' did not mean planes at all.

> Equivalently, consider a parade on a city street.   Police cars that
> are directing traffic around the closed streets that host a parade
> are a similar case, as are emergency vehicles.   The reasons why
> these mobile access routers will benefit from a geonetworking
> protocol is clear.

YEt another use-case.

I do not worry them being too many.  I am happy they are mentioned here,
and I think they should be captured.  There must be a reason behind each
of these use-cases being mentioned here.

(I am speaking from experience with ETSI ITS documents: they _do_ list
very many use-cases in one place, and it is useful.)

Alex

---

From: <[email-masked]>
Date: Wed, 13 Nov 2013 15:29:35 +0000

Hi all,

Sorry, but all these discussions that you are having below, are solution discussions and not problem statement related discussions.

Before going to solution and architecture discusiions  (e.g., which entities are used, etc.) we need to identify the challenges that need to be worked out by the Geonet WG.

Note that these challenges are part of a problem statement description and can be seen as descriptions of open issues and/or subproblems that could be worked out by the Geonet WG.

In the current problem statement draft several challenges are described, which were probably (from what I understood after the BOF) directing to a narrow scope of solutions, including the extended DNS and GoeServer solutions. This needs to be changed to also include the views of other participants, such as the vews of Dino, Ran and Brian.

I will start a threat on identifying the challenges that need to be worrked out by the Geonet WG!

The first bullets will represnt a subset of the challenges that are currently identified in the current version of the problem statement draft.

It will be great if other participants will enlarge this list with more challenges, which will express their views.

Best regards,

Georgios

________________________________
Van: [email-masked] [[email-masked]] namens Alexandru Petrescu [[email-masked]]
Verzonden: woensdag 13 november 2013 15:15
To: Alison Chaiken
Cc: [email-masked]
Onderwerp: Re: [geonet/its] mobile access routers and geoaware intermediate routers

Hi Alison,

Something like this:

This is intriguing.

YEt another use-case.

Alex

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

---

From: "Wissingh, B.F. (Bastiaan)" <[email-masked]>
Date: Thu, 28 Nov 2013 15:58:29 +0000

Hi Alexandru, Alison,

It was me, Bastiaan Wissingh from TNO Netherlands, who spoke to Alexandru
about the ³Mobile RSU² concept. I also think that the 'Mobile RSU¹ concept
could be an interesting use case to be added to the list. It partly
depends on your definition of ³Mobile², but let me briefly explain what we
see as a Mobile RSU. In the more regular case a RSU is placed somewhere at
the side of a road and gets a static geographical location which will most
likely not be changed until the device either reaches it's end of life or
is not longer needed at that location and therefor "teared down" (other
cases may applyŠ). 

In our case, we designed a RSU that is portable meaning that among other
things it¹s geographical position adjusts according to the location it is
positioned. To show why this can be useful, we implemented a Road Works
Warning application based on the ETSI DENM ASN.1 specification. So for
example when at some location among a highway there is some ongoing Road
Works, a surface man could take a Mobile RSU, position it on his car
somewhere at the Road Works and start sending Road Works Warning messages
with information about the Road Works.

I hope this clarifies the 'Mobile RSU¹ concept a bit.

Bastiaan

>very many use-cases in one place, and it is useful.)

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.