Subject: [geonet/its] Minutes Geonet side meeting IETF 90 Toronto

From: "Wissingh, B.F. (Bastiaan)" <[email-masked]>
Date: Wed, 27 Aug 2014 11:05:29 +0000

Hi all,

As Georgios already mentioned in an earlier e-mail from 25th of July, we
where in the process of gathering the minutes of the side meeting of the
IETF 90 Toronto. Please find them below:

===============================================

Minutes of the Geonet informal meeting on Wednesday 23 July at 20:30
Location: IETF registration desk;
5 people were present.
Dino, Bastiaan, Ray Bellis, Victor Moreno and Georgios Karagiannis

===============================================

The discussion focused on the main issues seen by the people that were
attending the meeting and on the next steps.

===============================================

The following items have been discussed:
Work in Geopriv done related to, ³given this is my IP address, where am
I?² Just like a directory lookup.

But such a deployment of a location server in each access network seems
very far from happening today.

There seems currently no demand for such a server within each access
network except for emergency services use case.

>From geolocation back to ip address is even more difficult.

You should not make assumptions on the network connection that is being
used (wired, wireless, etc.), it should be acrostic of the layer 2
connectivity.

It seems like not all the use cases have the same paradime, can be solved
with the same solution.

What we are asking for needs to seem like it is somewhat solvable.

Produce some diagrams explaining what theoretically might be possible to
solve, to get insight in the steps that are missing. Flows of how
information is flowing.

Emergency broadcast example, let terminals in a certain area contact a
broadcast emergency server an keep a connection open to receive data. Not
the other way around that a broadcast emergency server needs to setup a
connection with all nodes in a certain area.

Use a multicast address to disseminate traffic.

In GeoNet we would like to make a mapping between gateways that are
responsible for a certain area and the IP address on which that gateway is
reachable from the service provider.

Such a mapping can be done with DNS, but it is far far from scalable.

How do you trigger the joining to such dissemination channels, from the
gateways.

Protocols exist for, given my location, what is the right channel to join.

Mapping from a geographical location back to lisp gateways seems like a
problem.

LISP example; mapping database distributed in a DNS like hierarchy for
mapping location info to an IPv4, IPv6 or MAC address. These can be used
as lookup keys. Why not a 2-tupel with geo-coordinates and radius to
define physical location, use that as lookup key?

How do they get into the database? These devices come up, know what there
coordinates are, should all register with the same thing. How do we know
that we have the same name or id.

Is this expandable?

Not sure how the lookup on the other side worksŠ

Lisp can be deployed in phases, no need to deploy all at once.

===============================================

Way forward basically two options:
There are two options on moving forward with the Geonet activity:

== Option 1: Try to create an IETF BOF/WG, by first modifying the
following: ==

1) The scope is too large:
Adjust the use-cases, align them more and make sure they all ³require² the
same solution, or have the same problem statement. E.g, the precise goods
tracking use case seems very different from the other use cases.
Narrow further the scope

2) show in detail how Geonet can be applied to one or more use cases,
using message sequence diagrams, etc.

3) dissemination of packets within a geographical area should be layer 2
technology agnostic

4) show how geographical areas, including overlapping areas, can be
possible mapped to IP addresses
Ray Bellis mentioned that this is a very hard problem to solve and
therefore it might be required to bring Geonet to IRTF and not IETF.

== Option 2: Try to go for a Researching Group instead of a Working Group.
==
Advantage is that the problem statement, use cases, etc. can be more vague
as it is a research topic. Take it to Lars?

===============================================

Please provide your opinion on the proposed options on the way forward.

Best regards,
 
B.F. (Bastiaan) Wissingh MSc
TNO Netherlands

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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 28 Aug 2014 15:03:02 +0200

Hi Bastiaan,

Thank you for compiling the minutes, they are valuable reading for those 
who could not attend, including myself.

In the message you are asking for feedback.  Here is some feedback.

Please comment.

Le 27/08/2014 13:05, Wissingh, B.F. (Bastiaan) a écrit :
[...]

> == Option 1: Try to create an IETF BOF/WG,

I agree with this option 1.

> by first modifying the

I agree about adjusting the use-cases.  Currently  there are 4 use-cases 
documented in draft-karagiannis-geonet-problem-statement-00:

1. Dissemination of IP packets to geographical areas
2. Precise tracking of package positions during a shipping process
3. Dissemination of ITS (Intelligent Transportation System) information
    to fixed and mobile RSUs via Internet
4. Tracking and communicating with people or objects located in certain
    geographical areas

There are some immediately clear similarities but also discrepancies. 
For example, (1), (3) and (4) may use the same mechanism, although the 
mobile RSU part of (3) may be a bit different because the RSU is mobile.

The (2) use-case - precise tracking - seems a bit more different from 
the others, although the use-case may read similar.  The difference lies 
in the fact that it is the IP address of the end-node that is associated 
with the coordinates of the assumed-to-be-RSU, whereas in use-cases (1), 
(3) and (4) it is the IP address of the RSU itself which is associated 
with the coordinates.

Given these aspects, I also think we need to refine the use-cases such 
as to stress the similarities and reduce the discrepancies.

> using message sequence diagrams, etc.

I agree.  A first message sequence diagram would be useful.  Could you 
please draw a message exchange geonet/its?  It should be something like 
this:

                                         RSU            Vehicle's MR
    Client         Server            at lat/long/alt    close to RSU
      |               |                   |                |
      |               |                   |                |
      |-------------->|                   |                |
      | IP address of |                   |                |
      | RSU at lat/lon|                   |                |
      |  /alt/prec?   |                   |                |
      |<--------------|                   |                |
      |    RSU-IP     |                   |                |
      |               |                   |                |
      |---------------------------------->|                |
      |      Message-to-RSU-IP            |        /       |
      |               |                   |-------/
      |               |                   |       \"broadcast"all in area
      |               |                   |        \

> 3) dissemination of packets within a geographical area should be layer 2

I agree.  We should be careful with the words:
- dissemination
- broadcast
- multicast

because they could easily clash.

Multicast can be "IP multicast", some-link-layer multicast (e.g. WiFi 
multicast).  But can not be "radio multicast".

Broadcast can be "IP broadcast, 255.255.255.255", sone-link-layer 
broadcast (e.g. ff:ff:ff:ff:ff:ff in WiFi) and can be "radio broadcast", 
or even "TV broadcast".

Dissemination is ambiguous with respect to all.  There is no such term 
as "IP dissemination", nor "some-link-layer dissemination".  HEnce, we 
could be free to define it.  We could say that geonet dissemination is a 
sequence of IP multicast packets which are radop-broadcasted in area no 
larger than 50 square kilometers.

What do you think?

> therefore it might be required to bring Geonet to IRTF and not IETF.

I fully agree.  It is hard in the computational sense in that decisions 
of member appartenance to sets is NP-complete.

> as it is a research topic. Take it to Lars?

This option could be explored as well.

What do you think?

Alex

[...]