Subject: [geonet/its] Mobile RSU and Multihop with Offload use-case text for a 2nd BoF geonet

From: "Wissingh, B.F. (Bastiaan)" <[email-masked]>
Date: Thu, 16 Jan 2014 17:01:01 +0000

Hi Alexandru, All,

On request of Alexandru, I¹ve written two brief paragraphs related to use
cases 'Mobile Roadside Unit' and Multihop with offloading.

The Mobile RSU use case:
In the more regular case a Roadside Unit is placed somewhere alongside 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 no longer
needed at that location and therefor "teared down" (other cases may
apply). A so called 'Mobile Roadside Unit¹ on the other hand is portable,
meaning that among other settings, it¹s geographical position adjusts
according to the location it is positioned. Such a 'Mobile Roadside Unit¹
is very usable in multiple situations, for example when a permanently
installed unit fails and needs a temporarily backup unit or during Road
Works. In that case when at some location among a highway there is some
ongoing Road Works, a surface man could take a 'Mobile Roadside Unit',
position it on his car somewhere at the Road Works and start sending Road
Works Warning messages with information about the Road Works. In some
cases the geographical position of the could change when the Road Works
are moving slowly.

The other use case I was referring to is related to Multihop with
offloading:
When on a certain highway (equipped with Roadside Units) a multihop
message is send out, this message wil be forwarded by all Roadside Units
until it reaches its destination. This consumes resources on all Roadside
Units along the way. A more efficient way of reaching it¹s destination
would be by offloading the message to the Internet in order for it to be
delivered to Roadside Unit nearest to the destination of the Multihop
message. This saves resources in the Roadside Units along the highway.

Please feel free to add any comments/questions.

Regards,
Bastiaan Wissingh

Op 15-01-14 15:38 schreef Alexandru Petrescu
<[email-masked]>:

>Hello Bastiaan,
>
>Would you be interested in writing a brief paragraph about the 'mobile
>RSU' use-case?  This would be for drafting a Charter proposal for this
>Friday January 17th, to maybe make a BoF request.
>
>Our ongoing description is pasted at the end of this email.
>
>We would need something like this:
>
>Mobile RSU use-case
>-------------------
>Contrary to the typical RSU deployments where RSUs are fixed along the
>road,
>
>(reference:
>http://www.ietf.org/mail-archive/web/its/current/msg00696.html)
>
>Thanks in advance,
>
>Alex
>
>>
>>
>> Hi all,
>>
>> I have used the discussions that we have had up to now and updated the
>>"Geonet" problem statement, challenges, requirements and assumptions.
>>
>> Please note that we need to have a new version of the problem statement
>>draft ready before the 17th of January!
>> Alex, Melinda is this right?
>>
>> For this purpose, I have used the discussions that the following people
>>have had in the geonet/its mailing list:
>> Alexandru Peterscu, Melinda Shore, Dino Farinacci, Brian Dickson,
>>Dimitri Papadimitriou, Carl Reed, , Rex Buddenberg, Alison Chaiken,
>>Georgios Karagiannis.
>>
>> Please note that we need volunteers to complete some issues associated
>>with the description of use cases and with the differences between
>>Geonet and other IETF working groups:
>> (1)   ecrit, (2) LISP and (3) geopriv. Need volunteers for this!
>> Regarding the use cases I have assigned some volunteers (I hope that
>>this is acceptable):
>>
>> o) Dissemination to a particular area:
>> Volunteer: Georgios (old use cases that were described in v.01 of the
>>problem statement draft, rewritten in few paragraphs)
>>
>> o) Goods Tracking
>> Volunteer: Dino Farinacci?
>>
>> o) Traffic Safety and Traffic Efficiency and Traffic Management
>> Volunteer: Georgios
>>
>> o) Mobile RSU
>> Volunteer: Brian Dickson?
>>
>> o) Identification of originating area (network operator, CDN)
>> Volunteer: needed?
>>
>>
>> Below you can find all these descriptions:
>>
>> Geonet Problem:
>> =============
>>
>> Mechanisms and IETF Standardized  protocol(s) is/are needed to allow
>>source  nodes anywhere in the Internet to disseminate packets to all/any
>>node(s) using geographical area information, such as (1) geo-locators
>>(names) and/or (2) geographic (physical) coordinates, within a specified
>> target geographic area.
>>
>>
>> Geonet Challenges/Open issues:
>> ===============
>>
>> o) Mechanisms and/or protocol network layer solutions are needed for
>>the accurate representation of geographic areas using (1) geo-locators
>>(names) and/or (2) geographic (physical) coordinates.
>>
>> o) Mechanisms and/or protocol network layer solutions are needed to
>>ensure that geographical area information (geo-locators (names) and/or
>>geographic (physical) coordinates) is accurately mapped to an IP
>>locator, e.g., an IP address. Mapping data bases can be maintained at
>>the source nodes, IP locator nodes, or intermediate nodes (e.g., edge
>>nodes).
>>
>> o) Mechanisms and/or protocol network layer solutions are needed to
>>ensure that an IP locator, e.g., an IP address can be accurately mapped
>>to a geographic area information (geo-locators (names) and/or geographic
>>(physical) coordinates). Mapping data bases can be maintained at the
>>source nodes, IP locator nodes, or intermediate nodes (e.g., edge nodes).
>>
>> o) Mechanisms and protocol network layer solutions are needed to ensure
>>that data packets generated by source nodes placed anywhere 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".)
>>
>>
>> Geonet Requirements
>> ===========
>>
>> The specified mechanisms and protocol solutions:
>> o) SHOULD ideally support IPv4 and IPv6
>> o) MUST at a minimum support IPv6
>> o) MUST be able to use and insert geographic area information at the
>>network layer.
>> o) MUST be able to disseminate the information from senders to the
>>destination nodes located in the target/destination geographic area in a
>>point to multipoint manner.
>> o) SHOULD be able to be scalable and maintain its performance to
>>acceptable levels even it is applied to: (1) global coverage with small
>>target/destination geographic areas, (2) large traffic volumes (large
>>flows), (3) large number of active sources
>> o) MUST be able to provide accurate representation of geographic areas
>>using (1) geo-locators (names) and/or (2) geographic (physical)
>>coordinates.
>> o) MUST be able to ensure that geographical area information
>>(geo-locators (names) and/or geographic (physical) coordinates) is
>>accurately mapped to an IP locator, e.g., an IP address, even if the
>>relation between geographical area information and IP locator is not a
>>one-to-one relationship.
>> o) MUST be able to ensure that an IP locator, e.g., an IP address can
>>be accurately mapped to a geographic area information (geo-locators
>>(names) and/or geographic (physical) coordinates), even if the relation
>>between locator and geographical information is not a one-to-one
>>relationship.
>> o) MUST be able to ensure that the used mapping data bases of IP
>>locators to a geographic area information are up to date.
>> o) MUST support security and privacy: Given the sensitivity of location
>>data and the possibility of the technology being used in emergency
>>and/or road traffic management scenarios we will pay particular
>>attention to security and privacy.  A thorough threat analysis will be
>>conducted, and mitigations specified in any protocol documents which are
>>developed objectives for all supported communication modes. Security
>>objectives particularly include integrity, privacy and non-repudiation
>>and SHOULD protect the network and transport layer protocol headers.  In
>>addition the Internet-wide geo-networking solution MUST also protect
>>privacy, i.e. provide confidentiality to personal data such as relation
>>between node identifier and location.
>> o) SHOULD support timely and guaranteed delivery of information.
>>
>>
>> Geonet Assumptions:
>> ============
>> o) The mechanisms and protocol solutions SHOULD be able to use and
>>insert geographic area information at the network layer.
>> o) The destination nodes can be any static or moving entities, such as
>>hosts, vehicles, sensors and actuators, goods, that are spread/located
>>in a certain target/destination geographic area.
>> o) existing IETF mechanism and protocols like LISP, geopriv, ecrit and
>>reverse 911 will be taken into consideration during the design phase
>> o) The ISO 19107: Spatial Schema will be considered for the
>>representation of spatial characteristics of geographic features
>>(including geometries), and a set of spatial operations consistent with
>>these schemas. ISO 19107 treats vector geometry and topology up to three
>>dimensions.. Geometries range from point, multipoint, to polygon, to
>>Bezier curves, to Clothoids.
>> o) The IEEE 1609.2, see below, will be considered  for security and
>>privacy support 
>>(https://standards.ieee.org/findstds/standard/1609.2-2013.html
>>
>>
>>
>>
>> Geonet Use Cases (no particular order)
>> ===========================
>> Please one paragraph per use case should be provided
>>
>> o) Dissemination to a particular area:
>> Volunteer: Georgios (old use cases that were described in v.01 of the
>>problem statement draft, rewritten in few paragraphs)
>>
>> o) Goods Tracking
>> Volunteer: Dino Farinacci?
>>
>> o) Traffic Safety and Traffic Efficiency and Traffic Management
>> Volunteer: Georgios
>>
>> o) Mobile RSU
>> Volunteer:
>>
>> o) Identification of originating area (network operator, CDN)
>> Volunteer: needed?
>>
>> Differences between Geonet and othet IETF working groups:
>> =======================================
>> Text need to be written that emphasizes that are the main differences
>>between Geonet and at least (1) ecrit, (2) LISP and (3) geopriv. Need
>>volunteers for this!
>>
>>
>> Best regards,
>> Georgios
>>
>>
>> _______________________________________________
>> its mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/its
>>
>>
>

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: Thu, 16 Jan 2014 17:09:31 +0000

Hi Bastiaan,

Thank you for sending us the descriptions of these two use cases.

The decription of the mobile RSU use case includes geographical information in its description. I assume that a sender on the Internet can reach the mobile RSU using its geographical coordinates.

However, the dscription of the offloading use case does not include any description of how the geographic inforamtion can be used to locate nodes, etc.

Can you inlcude this information in the offloading use case?

Best regards,

Georgios

________________________________
Van: Wissingh, B.F. (Bastiaan) [[email-masked]]
Verzonden: donderdag 16 januari 2014 18:01
To: Alexandru Petrescu
Cc: Karagiannis, G. (EWI); Melinda Shore; Alison Chaiken; [email-masked]
Onderwerp: [geonet/its] Mobile RSU and Multihop with Offload use-case text for a 2nd BoF geonet

Hi Alexandru, All,

The Mobile RSU use case:

Regards,
Bastiaan Wissingh

Op 15-01-14 15:38 schreef Alexandru Petrescu
<[email-masked]>:

>>(<about:blank>https://standards.ieee.org/findstds/standard/1609.2-2013.html
>>
>>
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Jan 2014 18:57:04 +0100

Right, I agree.

Maybe this off-loading-via-fixed-Internet of an otherwise 
RSU-multi-hopped data traffic could be considered if the Internet edge 
routers had geographical coordinates.

True, IP addresses have no notion of physical proximity, but closer 
geographical proximity would not always mean better connection either.

Alex

Le 16/01/2014 18:09, [email-masked] a écrit :
> The decription of the mobile RSU use case includes geographical
> information in its description. I assume that a sender on the Internet
> can reach the mobile RSU using its geographical coordinates.
>
> However, the dscription of the offloading use case does not include any
> description of how the geographic inforamtion can be used to locate
> nodes, etc.
>
> ------------------------------------------------------------------------
> *Van:* Wissingh, B.F. (Bastiaan) [[email-masked]]
> *Verzonden:* donderdag 16 januari 2014 18:01
> *To:* Alexandru Petrescu
> *Cc:* Karagiannis, G. (EWI); Melinda Shore; Alison Chaiken; [email-masked]
> *Onderwerp:* [geonet/its] Mobile RSU and Multihop with Offload use-case
> text for a 2nd BoF geonet
>
> Hi Alexandru, All,
>
> 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, 20 Jan 2014 15:04:07 +0100

Le 19/01/2014 03:15, Richard Roy a écrit :
[...]
> For those who are interested, ISO 21217 (communication architecture)
> and (ISO 21210 IPv6 communications), where the concepts of mobile and
> portable ITS stations are defined for ITS communications, the
> distinction from a networking point of view is simple.  Mobile units
> can change their point of attachment to the network at any time while
> portable/fixed units do not. Simply stated, once a portable unit
> starts to move, it disconnects from any access point ("it powers
> down"). Portable units get (static) IP addresses that do not need to
> change during a continuous interval of operation, while mobile units
> can move and change their IP addresses (assuming proper mobility
> handling in the network of course) quasi-continuously "on the fly".

Hi Richard,

Allow me some comments.

I agree that Mobile RSU may not be the best term one could come up with,
even though it does have an intuitive meaning.

On another hand, a 'portable' unit would be a unit that could be carried
by one person, and without wheels.  I think the device that Bastiaan
talks about would be on two wheels and would be tracted/pushed, but not
carried, by a person.

Second, defining a mobility term in relationship with the dynamics of
acquiring its IP address does make some sense, although the result could
also be dubious.

That's why one may think about these terms as well:

- IP-mobile unit: a unit which changes its attachment point to the
   Internet, and where route updates are not used.  It could be moving
   or static.
- IP-fixed unit: a unit which does not change its attachment point to
   the Internet.  It could be moving (mobile) or static.

Third, I have been pointed out in private that the 'RSU' term may not be
used anylonger at ETSI nor ISO.

Alex

>
>
> With regard to the requirement:
>
> "o) MUST be able to ensure that the used mapping data bases of IP
> locators to a geographic area information are up to date."
>
> I suggest that it is NOT feasible unless you also require that only a
> small and finite set of geographical areas be created and only those
> are allowed (which is NOT reasonable IMO).  To do so would obviate
> the usefulness of the concept and its implementation from the outset.
> The challenge is that there is an uncountably infinite number or
> geographical regions that can be specified (OK ... countably infinite
> if you constrain real numbers to have only a finite number of bits in
> their representations, however that's still a large number ...
> infinity).  The only theoretical way of handling this problem is to
> quantize all of the physical space in which this communication system
> is to operate (e.g. the volume of space (a shell) consisting of the
> entire surface of the earth as modeled in the WWGS84 geoid, the inner
> radius of which is the mean radius of the geoid minus X km, and the
> outer radius is the mean geoid radius plus Y km (X,Y on the order of
> a few 10s to 100s of kms perhaps). Quantize here means divide this
> volume of space into a countable number of "space chunks" ("spunks")
> which are mutually exclusive (non-overlapping) and collectively
> exhaustive (cover the entire space). What would then be required is a
> dynamic database (kept up in real time and available/discoverable to
> all forwarding nodes) of "who is where" (which IPv6 addresses are in
> which spunks, and a mechanism for assessing spunk membership in an
> arbitrarily defined geographic region. While this is theoretically
> possible, I believe it's easy to see how intractable it is. Among
> other things, it involves continuous communication connectivity
> among all spunks which is just not going to happen because no one
> will pay for the infrastructure.  Note that just having an IPv6 node
> in a spunk is not sufficient; it must be connected to the network so
> it's presence in that spunk can be "recorded in the database".  This
> is just one of the infeasible consequences of the requirement.
> Secondly, the size of the spunks has huge implications obviously on
> system feasibility versus system efficacy.  Too small and the system
> can not be deployed; too large and the deployed system is useless.
> Where's Goldilocks when you need her??? :^))
>
> With regard to the "offload" case, this is really just a case of
> "intelligent routing" at the network layer.  RSUs will very likely
> be outfitted with more than one communication media (e.g., a 5.9
> module, a Wi_Fi module, an ethernet adapter, a 3G module, etc.).
> Which media is used to get packets from their source to the
> destination will depend on a large number of factors, obviously
> including whether the media is "available" at the "present time".
> Cost and other communication requirements/objectives such as data
> rate, reliability, etc. also come into play (see ISO 17419, ISO
> 17423, IS) 17429, ISO 24102-6 ... some currently in preparation).
> Protocols for geodissemination of information should be designed to
> take this into transparently.  The objective is get information from
> one physical location to another in the most effective and efficient
> manner WHEN possible, noting that at times it may NOT be possible to
> meet this objective at all!  There is NO guarantee that a node in a
> particular spunk can reach a ndoe in some other spunk ... that is,
> globally reachability of all spunks at all time can NOT be guaranteed
> in a practical network (see above).  Even if there is connectivity,
> there can be no guarantee that when the message arrives at its
> destination, there will be any nodes there to receive it.
>
> This brings up the very important issue of TIME. When delivering
> information to a place and not a known node, time MUST be a parameter
> in the addressing scheme.  That is, it is insufficient to just
> deliver information based on location; the address MUST involve some
> concept of time (time-to-live, validity-time, etc.) otherwise, among
> other tings, there will be unbounded storage requirements in the
> network.
>
> When sending a packet to a location, it's logical to assume the
> sender does NOT know the identity (e.g. the network layer address) of
> the intended recipient, only some properties thereof like its
> location. If it did  know a network layer address (e.g. an IPv6
> address) of the intended recipient, it would use different protocols
> to get the message to its destination since recipient location is
> generally not known (having all nodes continuously know the locations
> of all nodes they might want to connect to has HUGH privacy concerns
> even if it were tractable which it is not!). This means that the
> objective of "sending a packet to a location" is incomplete and
> therefore can not be achieved.  A properly formed objective has to
> read, for example:
>
> "Deliver this packet to all receivers with which it is possible to
> connect (i.e. that have one of a given set of media with which to
> connect) in a given geographic region during the specified time
> interval."
>
> and the interval MUST be specified logically as part of the address).
> The interval could be infinite by the way, although it's hard to
> imagine how that would be useful.  Space and time are intimately
> connected in geodissemination of information. Geoaddresses are
> space-time quantities!
>
> Food for thought ...
>
> RR
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Thursday, January 16,
>> 2014 6:57 PM To: [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: [geonet/its] Mobile RSU and Multihop with Offload
>> use-case text for a 2nd BoF geonet
>>
>> Right, I agree.
>>
>> RSU-multi-hopped data traffic could be considered if the Internet
>> edge routers had geographical coordinates.
>>
>> True, IP addresses have no notion of physical proximity, but
>> closer geographical proximity would not always mean better
>> connection either.
>>
>> Alex
>>
>>> information in its description. I assume that a sender on the
>>> Internet can reach the mobile RSU using its geographical
>>> coordinates.
>>>
>>> However, the dscription of the offloading use case does not
>>> include any description of how the geographic inforamtion can be
>>> used to locate nodes, etc.
>>>
>>> *Verzonden:* donderdag 16 januari 2014 18:01 *To:* Alexandru
>>> Petrescu *Cc:* Karagiannis, G. (EWI); Melinda Shore; Alison
>>> Chaiken; [email-masked] *Onderwerp:* [geonet/its] Mobile RSU and
>>> Multihop with Offload use-case text for a 2nd BoF geonet
>>>
>>> Hi Alexandru, All,
>>>
>>> On request of Alexandru, I¹ve written two brief paragraphs
>>> related to
>> use
>>> The Mobile RSU use case: In the more regular case a Roadside Unit
>>> is placed somewhere alongside 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 no
>>> longer needed at that location and therefor "teared down" (other
>>> cases may apply). A so called 'Mobile Roadside Unit¹ on the other
>>> hand is
> portable,
>>> meaning that among other settings, it¹s geographical position
>>> adjusts according to the location it is positioned. Such a
>>> 'Mobile Roadside
>> Unit¹
>>> is very usable in multiple situations, for example when a
>>> permanently installed unit fails and needs a temporarily backup
>>> unit or during Road Works. In that case when at some location
>>> among a highway there is some ongoing Road Works, a surface man
>>> could take a 'Mobile Roadside Unit', position it on his car
>>> somewhere at the Road Works and start sending
>> Road
>>> Works Warning messages with information about the Road Works. In
>>> some cases the geographical position of the could change when the
>>> Road Works are moving slowly.
>>>
>>> The other use case I was referring to is related to Multihop
>>> with offloading: When on a certain highway (equipped with
>>> Roadside Units) a multihop message is send out, this message wil
>>> be forwarded by all Roadside Units until it reaches its
>>> destination. This consumes resources on all
>> Roadside
>>> Units along the way. A more efficient way of reaching it¹s
>>> destination would be by offloading the message to the Internet in
>>> order for it to be delivered to Roadside Unit nearest to the
>>> destination of the Multihop message. This saves resources in the
>>> Roadside Units along the highway.
>>>
>>> Regards, Bastiaan Wissingh
>>>
>>>> Would you be interested in writing a brief paragraph about the
>>>> 'mobile RSU' use-case?  This would be for drafting a Charter
>>>> proposal for this Friday January 17th, to maybe make a BoF
>>>> request.
>>>>
>>>> Mobile RSU use-case ------------------- Contrary to the typical
>>>> RSU deployments where RSUs are fixed along the road,
>>>>
>>>> (reference:
Thanks in advance,
>>>>
>>>> Alex
>>>>
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I have used the discussions that we have had up to now and
>>>>> updated the "Geonet" problem statement, challenges,
>>>>> requirements and assumptions.
>>>>>
>>>>> Please note that we need to have a new version of the
>>>>> problem
>> statement
>>>>> draft ready before the 17th of January! Alex, Melinda is this
>>>>> right?
>>>>>
>>>>> For this purpose, I have used the discussions that the
>>>>> following
>> people
>>>>> have had in the geonet/its mailing list: Alexandru Peterscu,
>>>>> Melinda Shore, Dino Farinacci, Brian Dickson, Dimitri
>>>>> Papadimitriou, Carl Reed, , Rex Buddenberg, Alison Chaiken,
>>>>> Georgios Karagiannis.
>>>>>
>>>>> Please note that we need volunteers to complete some issues
>>>>> associated with the description of use cases and with the
>>>>> differences between Geonet and other IETF working groups: (1)
>>>>> ecrit, (2) LISP and (3) geopriv. Need volunteers for this!
>>>>> Regarding the use cases I have assigned some volunteers (I
>>>>> hope that this is acceptable):
>>>>>
>>>>> o) Dissemination to a particular area: Volunteer: Georgios
>>>>> (old use cases that were described in v.01 of the problem
>>>>> statement draft, rewritten in few paragraphs)
>>>>>
>>>>> o) Goods Tracking Volunteer: Dino Farinacci?
>>>>>
>>>>> o) Traffic Safety and Traffic Efficiency and Traffic
>>>>> Management Volunteer: Georgios
>>>>>
>>>>> o) Mobile RSU Volunteer: Brian Dickson?
>>>>>
>>>>> o) Identification of originating area (network operator,
>>>>> CDN) Volunteer: needed?
>>>>>
>>>>>
>>>>> Geonet Problem: =============
>>>>>
>>>>> Mechanisms and IETF Standardized  protocol(s) is/are needed
>>>>> to allow source  nodes anywhere in the Internet to
>>>>> disseminate packets to
>> all/any
>>>>> node(s) using geographical area information, such as (1)
>>>>> geo-locators (names) and/or (2) geographic (physical)
>>>>> coordinates, within a
>> specified
>>>>> target geographic area.
>>>>>
>>>>>
>>>>> Geonet Challenges/Open issues: ===============
>>>>>
>>>>> o) Mechanisms and/or protocol network layer solutions are
>>>>> needed for the accurate representation of geographic areas
>>>>> using (1) geo-locators (names) and/or (2) geographic
>>>>> (physical) coordinates.
>>>>>
>>>>> o) Mechanisms and/or protocol network layer solutions are
>>>>> needed to ensure that geographical area information
>>>>> (geo-locators (names) and/or geographic (physical)
>>>>> coordinates) is accurately mapped to an IP locator, e.g., an
>>>>> IP address. Mapping data bases can be maintained at the
>>>>> o) Mechanisms and/or protocol network layer solutions are
>>>>> needed to ensure that an IP locator, e.g., an IP address can
>>>>> be accurately mapped to a geographic area information
>>>>> (geo-locators (names) and/or
>> geographic
>>>>> (physical) coordinates). Mapping data bases can be maintained
>>>>> at the source nodes, IP locator nodes, or intermediate nodes
>>>>> (e.g., edge
>> nodes).
>>>>>
>>>>> o) Mechanisms and protocol network layer solutions are needed
>>>>> to
>> ensure
>>>>> that data packets generated by source nodes placed anywhere
>>>>> 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".)
>>>>>
>>>>>
>>>>> Geonet Requirements ===========
>>>>>
>>>>> The specified mechanisms and protocol solutions: o) SHOULD
>>>>> ideally support IPv4 and IPv6 o) MUST at a minimum support
>>>>> IPv6 o) MUST be able to use and insert geographic area
>>>>> information at the network layer. o) MUST be able to
>>>>> disseminate the information from senders to the destination
>>>>> nodes located in the target/destination geographic area in
>> a
>>>>> point to multipoint manner. o) SHOULD be able to be scalable
>>>>> and maintain its performance to acceptable levels even it is
>>>>> applied to: (1) global coverage with small target/destination
>>>>> geographic areas, (2) large traffic volumes (large flows),
>>>>> (3) large number of active sources o) MUST be able to provide
>>>>> accurate representation of geographic areas using (1)
>>>>> geo-locators (names) and/or (2) geographic (physical)
>>>>> coordinates. o) MUST be able to ensure that geographical area
>>>>> information (geo-locators (names) and/or geographic
>>>>> (physical) coordinates) is accurately mapped to an IP
>>>>> locator, e.g., an IP address, even if the relation between
>>>>> geographical area information and IP locator is not a
>>>>> one-to-one relationship. o) MUST be able to ensure that an IP
>>>>> locator, e.g., an IP address can be accurately mapped to a
>>>>> geographic area information (geo-locators (names) and/or
>>>>> geographic (physical) coordinates), even if the relation
>>>>> between locator and geographical information is not a
>>>>> one-to-one relationship. o) MUST be able to ensure that the
>>>>> used mapping data bases of IP locators to a geographic area
>>>>> information are up to date. o) MUST support security and
>>>>> privacy: Given the sensitivity of
>> location
>>>>> data and the possibility of the technology being used in
>>>>> emergency and/or road traffic management scenarios we will
>>>>> pay particular attention to security and privacy.  A thorough
>>>>> threat analysis will be conducted, and mitigations specified
>>>>> in any protocol documents which
>> are
>>>>> developed objectives for all supported communication modes.
>>>>> Security objectives particularly include integrity, privacy
>>>>> and non-repudiation and SHOULD protect the network and
>>>>> transport layer protocol headers.
>> In
>>>>> addition the Internet-wide geo-networking solution MUST also
>>>>> protect privacy, i.e. provide confidentiality to personal
>>>>> data such as relation between node identifier and location.
>>>>> Geonet Assumptions: ============ o) The mechanisms and
>>>>> protocol solutions SHOULD be able to use and insert
>>>>> geographic area information at the network layer. o) The
>>>>> destination nodes can be any static or moving entities, such
>>>>> as hosts, vehicles, sensors and actuators, goods, that are
>>>>> spread/located in a certain target/destination geographic
>>>>> area. o) existing IETF mechanism and protocols like LISP,
>>>>> geopriv, ecrit and reverse 911 will be taken into
>>>>> consideration during the design phase o) The ISO 19107:
>>>>> Spatial Schema will be considered for the representation of
>>>>> spatial characteristics of geographic features (including
>>>>> geometries), and a set of spatial operations consistent with
>>>>> these schemas. ISO 19107 treats vector geometry and topology
>>>>> up to
>> three
>>>>> dimensions.. Geometries range from point, multipoint, to
>>>>> polygon, to Bezier curves, to Clothoids. o) The IEEE 1609.2,
>>>>> see below, will be considered  for security and privacy
>>>>> support
>>>>> (<about:blank>https://standards.ieee.org/findstds/standard/1609.2-
>>
>>>>>
2013.html
>>>>> =========================== Please one paragraph per use case
>>>>> should be provided
>>>>>
>>>>> o) Dissemination to a particular area: Volunteer: Georgios
>>>>> (old use cases that were described in v.01 of the problem
>>>>> statement draft, rewritten in few paragraphs)
>>>>>
>>>>> o) Goods Tracking Volunteer: Dino Farinacci?
>>>>>
>>>>> o) Traffic Safety and Traffic Efficiency and Traffic
>>>>> Management Volunteer: Georgios
>>>>>
>>>>> o) Mobile RSU Volunteer:
>>>>>
>>>>> o) Identification of originating area (network operator,
>>>>> CDN) Volunteer: needed?
>>>>>
>>>>> ======================================= Text need to be
>>>>> written that emphasizes that are the main differences between
>>>>> Geonet and at least (1) ecrit, (2) LISP and (3) geopriv.
>>>>> Need volunteers for this!
>>>>>
>>>>>
>>>>> Best regards, Georgios
>>>>>
>>>>>
>>>>> _______________________________________________ its mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>
>>
>
>
>
>