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

[Alexandru Petrescu <[e-mail]>]

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
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Friday, July 11, 2014 10:17 PM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> 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;
>>
>> 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
>
>
>