Subject: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk

From: <[email-masked]>
Date: Sat, 12 Jul 2014 05:16:43 +0000

Agenda GeoNet informal meeting
==========================

Date and time: Wednesday 23 July at 20:30
Location: IETF registration desk; 

I) Current version of charter, see attached document
=============

II) Current status of documents
==============

Currently the following drafts are produced:
http://www.ietf.org/id/draft-karagiannis-geonet-problem-statement-00.txt
http://www.ietf.org/id/draft-karagiannis-geonet-dissemination-geo-areas-00.txt
http://www.ietf.org/id/draft-wissingh-disseminate-to-rsu-00.txt

The following two use cases Internet drafts are planned to be written soon after the 
IETF 90 (Dino is the main author of these two drafts; Dimitri will also participate; More volunteers?):

=> Precise tracking of package positions during a shipping process:
A good delivered by a shipping organization has a provider-independent IP address. 
This good is tracked in that its geographical position is known to end-users continuously throughout the entire delivery process. 
The IP address of the good is associated to the geographical coordinates of the router to which it connects. Using IP addresses enables very finely grained and precise tracking. 

=> Tracking and communicating with people or objects located within geographical areas, e.g., Oiler Rigger
Oil companies want to track employees in the field, where the conditions can be dangerous so they want to verify their safety. Such a dangerous situation can be the explosion (or the high risk of explosion) of an oiler rigger. In this situation the Oil company needs to be able to disseminate recovery instructions to all employees that are located in the neighborhood of the explosion within a certain radius (e.g., 1 mile) from the explosion.

III) Possible blocking points on moving forward
========================

1. The re-use of DNS is perceived as a blocking point; a possible way
    out is to propose a system-specific resolution mechanism, with a
    loose-coupling hook to DNS?

2. Forwarding/L3 packet processing based on GeoNet (rather than IP
    addresses) is a blocking point; the best we could expect is a
    overlay style mechanism à la multicast or Mobile IP, or LISP where (one or more gateways)
    "gateway function" would be required?

3. Relationship to Geopriv WG may block because it suggests the
    functions we propose in GeoNet are maybe more adequate at
    application layer; maybe Geopriv may deliver an encoding-independent
    document which would enable consistence in the representation of
    geolocators and areas?

IV) What are the next steps on forming the GeoNET WG?
==============================

Best regards,
Georgios

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Fri, 25 Jul 2014 17:56:44 +0000

Hi All,

I couldn't participate to the side-meeting on Wednesday evening but would like to share from the feedback received my suggestion in order to move forward based of my understanding of the current situation:

- We know a couple of technical challenges/key issues have to be further investigated (see point iii) here below) 

- There are different alternatives we have to explore before moving to an IETF protocol chartered group

- Several initiatives have been already explored/specified in addressing contiguous problems and we have to figure out which one could fit our needs, which one require extension or enhancement, etc.

To this end, moving towards a proposed RG seems to be the more suited approach. 

Any other opinion ? Thoughts ?

Cheers,
-dimitri.

> -----Original Message-----
> From: its [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Saturday, July 12, 2014 7:17 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July
> at 20:30; IETF registration desk
> 
> I) Current version of charter, see attached document =============
> 
> 
> The following two use cases Internet drafts are planned to be written soon
> after the IETF 90 (Dino is the main author of these two drafts; Dimitri
> will also participate; More volunteers?):
> 
> This good is tracked in that its geographical position is known to end-
> users continuously throughout the entire delivery process.
> The IP address of the good is associated to the geographical coordinates
> of the router to which it connects. Using IP addresses enables very finely
> grained and precise tracking.
> 
> => Tracking and communicating with people or objects located within
> geographical areas, e.g., Oiler Rigger Oil companies want to track
> employees in the field, where the conditions can be dangerous so they want
> to verify their safety. Such a dangerous situation can be the explosion
> (or the high risk of explosion) of an oiler rigger. In this situation the
> Oil company needs to be able to disseminate recovery instructions to all
> employees that are located in the neighborhood of the explosion within a
> certain radius (e.g., 1 mile) from the explosion.
> 
> 
> III) Possible blocking points on moving forward ========================
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 31 Jul 2014 12:16:21 +0200

Le 25/07/2014 19:56, Papadimitriou, Dimitri (Dimitri) a écrit :
[...]
> Any other opinion ? Thoughts ?

I would like to discuss further this aspect.

There are a number of big unknowns in geonetworking rendering it 
researchy.  How many geo-points relate to one IP address, and 
vice-versa?  IP forwarding is known through routers but not through 
geo-points: which translation could achieve that?  IP is universal, but 
geographical coordinates are part of various incompatible geography 
systems and projections. Etc.

On another hand, there are number of vehicular industry needs of sending 
app-layer IP packets to Routers situated in geographically-determined areas.

And, there are a number of standardized products sending non-IP messages 
containing geographical coordinates.  The main reason behind these being 
non-IP instead of IP is a fallacy.  That fallacy says that sending IP 
messages is not reliable, nor fast enough.

There are a number of advantages in sending IP messages, instead of 
non-IP messages, in a vehicular environment: interoperability, 
availability of open-source software, tapping in a much larger software 
developper base, cheap hardware.

I would like to discuss further along these lines.  What is more WG and 
what is more RG?  Thoughts?

Alex

>
> Cheers, -dimitri.
>
>
>
>> -----Original Message----- From: its [mailto:[email-masked]]
>> On Behalf Of [email-masked] Sent: Saturday, July 12, 2014
>> 7:17 AM To: [email-masked] Cc: [email-masked];
>> [email-masked]; [email-masked] Subject: [geonet/its]
>> Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF
>> registration desk
>>
>> Agenda GeoNet informal meeting ==========================
>>
>> Date and time: Wednesday 23 July at 20:30 Location: IETF
>> registration desk;
>>
>> II) Current status of documents ==============
>>
http://www.ietf.org/id/draft-karagiannis-geonet-dissemination-geo-areas-
>> 00.txt
>> The following two use cases Internet drafts are planned to be
>> written soon after the IETF 90 (Dino is the main author of these
>> two drafts; Dimitri will also participate; More volunteers?):
>>
>> => Precise tracking of package positions during a shipping
>> process: A good delivered by a shipping organization has a
>> provider-independent IP address. This good is tracked in that its
>> geographical position is known to end- users continuously
>> throughout the entire delivery process. The IP address of the good
>> is associated to the geographical coordinates of the router to
>> which it connects. Using IP addresses enables very finely grained
>> and precise tracking.
>>
>> => Tracking and communicating with people or objects located
>> within geographical areas, e.g., Oiler Rigger Oil companies want to
>> track employees in the field, where the conditions can be dangerous
>> so they want to verify their safety. Such a dangerous situation can
>> be the explosion (or the high risk of explosion) of an oiler
>> rigger. In this situation the Oil company needs to be able to
>> disseminate recovery instructions to all employees that are located
>> in the neighborhood of the explosion within a certain radius (e.g.,
>> 1 mile) from the explosion.
>>
>>
>> 1. The re-use of DNS is perceived as a blocking point; a possible
>> way out is to propose a system-specific resolution mechanism, with
>> a loose-coupling hook to DNS?
>>
>> overlay style mechanism à la multicast or Mobile IP, or LISP where
>> (one or more gateways) "gateway function" would be required?
>>
>> application layer; maybe Geopriv may deliver an
>> encoding-independent document which would enable consistence in the
>> representation of geolocators and areas?
>>
>>
>> Best regards, Georgios

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 31 Jul 2014 15:00:03 +0200

Le 29/07/2014 22:56, Richard Roy a écrit :
>
> All,
>
> With regard to the text in geonet-03.txt, I think the following should be
> considered.
>
> IMHO what is described in that doc is not geo-networking, rather
> geodissemnination of information using IP protocols.  Geo-networking,
> logically, would involve a new networking protocol, including new addressing
> schemes, discovery, and all those other mechanisms IP deals with (and
> possibly more!). That's networking.
>
> What the group seems to be addressing (and it's fine) is how to figure out
> how to get packets from one IP address (where the transmitter is in some geo
> location) to a set of IP addresses located in some other geo-location(s).
> This is better termed "geodissemination of information using IP protocols".
> Naturally, it's the extension of the IP protocols to allow for this that is
> the interesting/challenging work to be done.
>
> As has been pointed out before on this thread, geodissemination could be
> achieved above layer 4 using all the information gathered by the node from
> various sources and all the resources available at the node.

I tend to agree that one important topic is how to get packets from one 
IP address to a set of IP addresses located at some other geo-location.

The problem is how to know that at a particular geo-location a 
particular IP address is situated.  From this problem, the question is 
whether or not a _mapping_ mechanism [IP address, geo-location] is a 
sufficient tool to address that problem - be it solved at layer 4 or other.

What do you think - is a mapping mechanism sufficient?

A mapping mechanism could be DNS or other mapping mechanism.

An alternative to a mapping mechanism could be an IP multicast 
mechanism: an IP addressable host joins an IP multicast group 
ff10::coordinatex:coordinatey which designates an halph-sphere centered 
on these coordinates and radius 10meter (an average precision these 
days).  Senders send packets to ff10:coordinatex::y and are sure the IP 
receivers are in that area.

These mechanisms could be for a use-case I am concerned with in the 
electric vehicle ecosystem:

Some Road-Side Units are distributed along a road.  Each RSU has to 
announce the location of the nearest C/S (Charging Spot for electric 
vehicles).  These RSUs are manageable remotely and the manager needs a 
tool to 'flock' (group together) a group of RSUs closest geographically 
to one C/S and update only these RSUs with electrical charge 
availability at each C/S.

If the management tool had a mapping mechanism, then it could identify 
which RSUs are close to a particular C/S, send the geographical 
coordinates of that C/S to these particular RSUs, and the RSUs would in 
turn broadcast the geographical coordinates of the C/S to the vehicles 
passing by.  In this way, the vehicles may plan their route depending on 
the electrical charge availability at the nearest C/Ss.

Alex

   The diagram
> Thierry has shown on several occasions with cellular, backhaul, and ad-hoc
> networks shows this clearly.
>
> Cheers,
>
> RR
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Friday, July 11, 2014 10:17 PM
>> To: [email-masked]
>> after the
>> geographical areas, e.g., Oiler Rigger
>> Oil companies want to track employees in the field, where the conditions
>> can be dangerous so they want to verify their safety. Such a dangerous
>> situation can be the explosion (or the high risk of explosion) of an oiler
>> rigger. In this situation the Oil company needs to be able to disseminate
>> recovery instructions to all employees that are located in the
>> neighborhood of the explosion within a certain radius (e.g., 1 mile) from
>> the explosion.
>>
>>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 31 Jul 2014 07:31:05 -0700

> The problem is how to know that at a particular geo-location a particular IP address is situated.  From this problem, the question is whether or not a _mapping_ mechanism [IP address, geo-location] is a sufficient tool to address that problem - be it solved at layer 4 or other.

We have this in the LISP mapping database today. The enclosed screen shot is a mapping entry registered with a LISP map-server in my lispers.net implementation.

Dino

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 31 Jul 2014 16:36:24 +0200

Le 31/07/2014 16:31, Dino Farinacci a écrit :
> We have this in the LISP mapping database today. The enclosed screen
> shot is a mapping entry registered with a LISP map-server in my
> lispers.net <http://lispers.net> implementation.

Thanks for the pointer.

I wonder whether you see any problem with the mapping:
geo: 40-35-18-N 73-40-3-W
elp: 199.123.123.123(Rps)

Could this mapping be used to geo-disseminate IP packets to a particular 
geographical area?

Alex

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 31 Jul 2014 07:59:56 -0700

> elp: 199.123.123.123(Rps)

I do not. Right now the implementaiton puts geo-coordinates in RLOC records, but as I was saying in our impromtu meeting in Toronto, I envision "geo prefixes" which can be a circle, triangle, square or multi-point geometric shape be used as an EID record.

So I could describe a geo-prefix to be the "New York" area. That is registered that can yield a list of RLOC addresses of ETRs an ITR could encapsulate to. So when someone wants to know if Alex is in new york, we take your geo-coorindate "point" and do a longest match lookup and find the EID-prefix "New York". 

I have working through how to change the LISP Geo-Coordiante LCAF type to accommodate different "shapes'.

The only missing piece is how an overlay device, like a LISP xTR knows what to lookup. This could be a control-plane play only.

> Could this mapping be used to geo-disseminate IP packets to a particular geographical area?

Only when the geo-coordinate is used as an EID lookup into the LISP mapping database.

Dino

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 31 Jul 2014 09:01:03 -0600

Alex -

I am not familiar with your LISP mapping database.

However, a couple of suggestions.

1. Specifying a lat/long coordinate in the form 40-35-18-N 73-40-3-W is 
unusual. The vast majority of encodings for geographic coordinates is done 
in decimal degrees. While the format you show is perhaps nice for human 
reading it is not the norm. Also check out 
http://en.wikipedia.org/wiki/ISO_6709
2. I would check out other lightweight encodings such as Open GeoSMS 
(https://portal.opengeospatial.org/files/?artifact_id=44146) or how geo is 
encoded in vcard and icalendar and in the location object (LO) for PIDF and 
other internet RFCs.
3. You will notice in the ISO 6709 discussion (and in all OGC standards) the 
need to specify the CRS (coordinate reference system) being used. For 
lat/long, the typical CRS is EPSG 4326, WGS 84 2d. The CRS information can 
be in the documentation and not necessary in the physical encoding.

Regards

Carl Reed, PhD
CTO
Open Geospatial Consortium

-----Original Message----- 
From: Alexandru Petrescu
Sent: Thursday, July 31, 2014 8:36 AM
To: Dino Farinacci
Cc: [email-masked] ; <[email-masked]> ; [email-masked] ; 
<[email-masked]> ; <[email-masked]>
Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd 
July at 20:30; IETF registration desk

Thanks for the pointer.

Alex

> Dino

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