Subject: Re: [geonet/its] Comments on Geonet problemstatement

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Jun 2014 15:05:30 +0200

Hi Bastiaan,

Sorry for late reply.  I hoped participants to reply to your comments. 
Absent that please allow me to reply.

Le 04/03/2014 16:33, Wissingh, B.F. (Bastiaan) a écrit :
> Hi Alex, Melinda, All:
>
> After the discussions about the geonet charter held yesterday during the
> side meeting, I wanted to post some additional comments I have related
> to the current version of the geonet problemstatement to the mailing
> list in order to try and improve the problemstatement. Some of the
> comments are more related to textual improvements, while some are more
> content related. I’ve copied the related parts of the problem statement
> below.
>
> o) Mechanisms and protocol solutions are needed for
>     the accurate representation of geographic areas using (1)
>     geo-locators such as names and (2) geographiic physical coordinates.
>
>
> In the last sentence above, geographic is misspelled in the above part.

Right.  I think it is no longer the case in the geonet problem statement 
draft.

> o) Mechanisms and protocol solutions are needed to ensure
>     that the IP addresses of access routers, roadside unit
>     (RSUs), and so on can be accurately mapped to geographic
>     area information (geo-locators, names, and geographic
>     physical coordinates). Mapping data bases can be
>     maintained at the source nodes, intermediate or edge
>     nodes, and at specific IP locator nodes.
>
>
> Seems like it should be “roadside units” on the second line in the above
> part.

Right.

> o) Mechanisms and protocol solutions are needed to ensure
>     that data packets generated by source nodes placed
>     arbitrarily in the Internet can be forwarded over
>     multiple hops by using, where possible, geographic
>     physical coordinates of (1) the destination node(s)
>     and/or (2) the intermediate nodes for the routing
>     decisions, instead of using their IP addresses. (Note
>     that in order to solve the above challenge it is NOT
>     mandated that all nodes located on the path from source
>     to destination nodes are able to forward packets using
>     the geo-coordinates of (1) the destination node(s) and/or
>     (2) the intermediate nodes for the routing
>     decisions. This is emphasized by using the words "where
>     possible".)
>
>
> As came forward a bit during the discussion yesterday, the above bullet
> seems to me that it suggests we want to be defining a new Routing
> Protocol or something. Maybe it’s just me, but as it was also suggested
> during the discussion yesterday would it be good to reformulate the
> above bullet tekst?

Yes, this worry about Routing Protocol may be a blocking issue.  I will 
extract this in a separate email.

> o) MUST be able to provide accurate representation of
>     geographic areas using (1) standardized geolocators where
>     available and/or (2) geographic physical coordinates.
>
> o) MUST be able to ensure that geographical area information
>     (geo-locators, names and geographic physical coordinates)
>     is accurately mapped to an IP address, even if the
>     relation between geographical area information and IP
>     address is not a one-to-one relationship.
>
> o) MUST be able to ensure that an IP address can be
>     accurately mapped to a geographic area information
>     (geo-locators, names and geographic physical
>     coordinates), even if the relation between locator and
>     geographical information is not a one-to-one
>     relationship.
>
>
> It is a bit unclear/vague to me what exactly is meant by the term
> “accurate”. Is it more related to having the mapping up-to-date, or for
> example that the mapping needs to be “square-meter” or
> “square-centimeter” precise? What are the ideas on this?

The square-meter/centimeter would be "precision".  Here at IETF we would 
not focus on higher and higher precision.  In a sense, IP addresses are 
already 100% precise.

Accuracy would be as simple as knowing where a particular IP address is 
situated (compared to today's situation where we dont know  much about 
it), and maybe to have the mapping up-to-date.

Or, otherwise, we can discuss the word accuracy, and see the levels of 
accuracy of current system (we know some IP addresses belong to some 
countries - accuracy==hundred square kilometers), and targeted levels of 
accuracy (to equal that of GPS, of Galileo, of Baidou, or that of 
imagery sattelites).

>
> o) Dissemination to a particular area
>
> In this use case a source node, which may be located anywhere, sends
> packets to a wireless access router through the Internet. Those
> wireless access routers are selected based on geographical location
> information, and traffic is routed to them using the IPv6 address of
> the router and conventional IP routing. Each of the destination
> access routers then copies and broadcasts the received packets to
> listeners within its radio coverage area.
>
>
> Do we really need to explicitly mention the using of the IPv6 address
> here? Or can we make it more general and call it an IP address?

I would agree to call it an IP address.

> o) Vehicular Traffic Safety, Efficiency, Management and Infotainment
>
> A source node, which may be located anywhere, sends traffic safety,
> traffic efficiency and management, and infotainment type of vehicular
> information to Road Side Units (RSUs) through the Internet.
>
> Those RSUs are preselected based on the geographical location
> information of the destination geographic area. The vehicular data
> traffic is routed to a RSU using its IPv6 address.
>
>
> Regarding the terminology throughout the Charter and the Problem
> statement, I don’t think we need to put definitions for all the terms we
> use yet, but at least be consistent in the terminology. For example the
> term "Roadside Unit” has passed the documents in multiple manners, e.g.
> Road-side unit, Road Side Unit, as well as Roadside Unit. I would “vote”
> for using the latter one, so Roadside Unit.

I agree.  It is good to have "Roadside Unit" throughout.

> And again, do we need to explicitly state the IPv6 address, or can we
> just say IP address?

IP address should be fine.

> Below, I’ve “tuned” the Mobile RSU use-case a bit, see below. Does it
> need some additional text explaining why an geonet mapping is important
> for this use-case?
>
> o) Mobile RSU
>
> Typically a Roadside Unit (RSU) is placed somewhere alongside a road for
> vehicles; an RSU gets a static
> geographical location which will most likely not be changed until the
> device either reaches its end of
> life or is no longer needed at that location; at that time it would be
> "torn down” before moving to another
> location (other cases may apply).
>
> A so called 'Mobile Roadside Unit' on the other hand is portable and not
> “torn down" while moving, meaning
> that among other settings its geographical position adjusts according to
> the location where it is positioned.
> Such a 'Mobile Roadside Unit’ is very flexible for use in multiple
> situations. Examples of such situations include
> when a permanently installed unit fails and needs a temporarily backup
> unit or during road construction. In the
> latter case when at some location along a road there is ongoing road
> works, an operator could take a 'Mobile
> Roadside Unit', position it on a car at the beginning of the road works
> site, and start sending so called
> 'Road Works Warning’ messages with detailed information about the road
> works. Furthermore, in some cases the
> geographical position of it could change if the road works are slowly
> moving.
>
> Additionally, while data traffic could be forwarded along mobile RSUs in
> a multi-hop manner, less congested paths
> May use the fixed edge geonet-enabled routers of the Internet (off-loading).
>
>
> Last time the Mobile RSU use-case has been discussed, it has been
> decided to combine an additional use-case I mentioned about
> “off-loading” with the Mobile RSU use-case. In the meantime I have been
> thinking some more about that off-loading case, and as it is not
> explicitly related to a Mobile RSU I am wondering whether we should
> combine it or take it as separate use case? Let me give a brief example
> again:
>
> For example, a car detects an accident in front of him on a certain
> high-way. In response it sends a “warning" message via 802.11p to the
> nearest roadside unit. Maybe there is some logic there that predicts a
> traffic jam based on that info and based on that wants to forward the
> warning message to a certain geographical location (for example earlier
> on the high-way where for example the high-way splits up), so that cars
> arriving at that  geographical location can make a decision to continue
> their way and end up in the traffic jam, or take the split and avoid the
> traffic jam.

Bastiaan - is the I-D "Dissemination to RSU" including your description 
above?  The description above makes sense to me.

>
> The LISP WG mainly focusses mainly on network-layer-based protocol
> solutions that enable the separation of routing locators (where you
> are attached to the network) and identifiers (who you are) in one
> number space. Geonet mainly focusses on how IP routing and addressing
> uses geography parameters, like geographical coordinates to
> disseminate packets sent by a sender located anywhere in the Internet
> to nodes that are located in the area specified by these geography
> parameters.
>
> The ECRIT WG mainly focusses mainly on how location data and call
> routing information are used to enable communication between a user
> and a relevant emergency response center. In particular, the ECRIT WG
> has specified protocols to map emergency services identifiers and
> geodetic or civic location information to service contact URIs.
> Geonet mainly focusses on how IP routing and addressing uses geodetic
> or civic location information to disseminate packets sent by a sender
> located anywhere in the Internet to nodes that are located in the area
> specified by this geodetic or civic location information.
>
>
> Both the above paragraphs contain the word “mainly” one time too much in
> the first sentence.

I agree.  It is too much use of word "mainly".  I think we should modify 
the Internet Draft:
http://tools.ietf.org/html/draft-karagiannis-geonet-problem-statement-00

Alex

>
> Hope this helps in getting forward, also if I can be of any help, please
> let me know!
>
> Bastiaan
>
> https://github.com/MelindaShore/geonet/blob/master/problemstatement.txt
>
> **
>
>
> 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: Mon, 23 Jun 2014 15:10:38 +0200

Hi Carl,

Thank you for the comment.  Please see below my comments.

Le 04/03/2014 17:13, Carl Reed a écrit :
> Alex and Melinda
> Another minor nit for “mechanisms and protocol” sentence. remove
> “physical”. This is redundant. The definition of a geographic coordinate
> system is:
> “a coordinate system that enables every location on the Earth to be
> specified by a set of numbers or letters.”

That makes sense.  I will ask Georgios to update this in the current 
problem statement draft.
http://tools.ietf.org/html/draft-karagiannis-geonet-problem-statement-00

> Also, the PIDF Location Object (LO) uses the term “geodetic coordinate”
> (https://tools.ietf.org/html/rfc5491). Not sure if you wish to be
> consistent.

I think we should be consistent.  I think we should agree between the 
name geographic coordinate system, and geodetic coordinate.

I think the latter would make more sense.

Additionally, I have another comment about this.  I worry about "Geo" in 
geodetic/geographic refering to planet Earth.  But IP is known to work 
outside that space (e.g. in space near and far), at which point our 
'geonet' work would not be inapplicable.

Alex

> Regards
>
> Carl
> *From:* Wissingh, B.F. (Bastiaan) <mailto:[email-masked]>
> *Sent:* Tuesday, March 04, 2014 8:33 AM
> *To:* Melinda Shore <mailto:[email-masked]> ; Alexandru
> Petrescu <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* [geonet/its] Comments on Geonet problemstatement
> Hi Alex, Melinda, All:
> ------------------------------------------------------------------------
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: "Wissingh, B.F. (Bastiaan)" <[email-masked]>
Date: Wed, 25 Jun 2014 14:00:40 +0000

Hi Alex,

No problem at all, thanks for your reply!

> above?  The description above makes sense to me.

About the ³off-loading² cases, it is currently not described within the
I-D ³Dissemination to RSU² as I¹m not sure whether it is specifically for
RSU¹s as there might be other use-cases. But we can add it to a next
version.

Best regards,
Bastiaan

Op 23-06-14 15:05 schreef Alexandru Petrescu
<[email-masked]>:

>> content related. I¹ve copied the related parts of the problem statement
>> below.
>>
>> Seems like it should be ³roadside units² on the second line in the above
>> part.
>
>Right.
>
>> Protocol or something. Maybe it¹s just me, but as it was also suggested
>> ³accurate². Is it more related to having the mapping up-to-date, or for
>> example that the mapping needs to be ³square-meter² or
>> ³square-centimeter² precise? What are the ideas on this?
>
>> statement, I don¹t think we need to put definitions for all the terms we
>> term "Roadside Unit² has passed the documents in multiple manners, e.g.
>> Road-side unit, Road Side Unit, as well as Roadside Unit. I would ³vote²
>> Below, I¹ve ³tuned² the Mobile RSU use-case a bit, see below. Does it
>> "torn down² before moving to another
>> ³torn down" while moving, meaning
>> Such a 'Mobile Roadside Unit¹ is very flexible for use in multiple
>> 'Road Works Warning¹ messages with detailed information about the road
>> ³off-loading² with the Mobile RSU use-case. In the meantime I have been
>> high-way. In response it sends a ³warning" message via 802.11p to the
>> Both the above paragraphs contain the word ³mainly² one time too much in
>> the first sentence.
>

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: <[email-masked]>
Date: Sun, 29 Jun 2014 09:47:23 +0000

Hi Bastiaan,

Thanks! 
I agree, before we update the problem statement draft we need to find out if the "off-loading" case is a new use case or not!

Best regards,
Georgios

________________________________________
Van: its [[email-masked]] namens Wissingh, B.F. (Bastiaan) [[email-masked]]
Verzonden: woensdag 25 juni 2014 16:00
Aan: Alexandru Petrescu; Melinda Shore
CC: [email-masked]
Onderwerp: Re: [geonet/its] Comments on Geonet problemstatement

Hi Alex,

Best regards,
Bastiaan