Subject: [geonet/its] Internet-wide Geonetworking problem statement and challenges/open issues

From: <[email-masked]>
Date: Fri, 15 Nov 2013 05:40:48 +0000

Hi all,

Below I am giving a brief problem statement description associated with Internet-wide geonetworking. This description includes the challenges/open issues that could be worked out by the IETF in a new WG. In addition to that I am aslo listing requirements that need to be addressed in order to solve these challenges/open issues.

The goal of this email is to (1) stimulate discussion, (2) modify the description of the listed challenges/open issues, (3) add new challenges and (4) modify/add requirements.

Problem:
-------------
Standardized protocol(s) is/are needed to allow source nodes anywhere in the Internet to disseminate packets to all/any node(s) with geographic location awareness within a specified destination area.

Challenges/Open issues:
------------------------

o) Mechanisms and/or protocol solutions are needed to ensure that geographical information  is available in the addressing mechanism, such that packets can be forwarded to a target geographical area.

o) Mechanisms and protocol solutions are needed to ensure that data packets generated by source nodes placed anywhere in the Internet are forwarded over multiple hops by using, where possible, the position of the destination node(s) and the positions of 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 position of the destination node(s) and the positions of intermediate nodes for the routing decisions. This is emphasized by using the words “where possible”.)

Main requirements:
---------------------
The main requirements to be satisfied on solving the above challenges, (see also:
http://www.ietf.org/id/draft-karagiannis-problem-statement-geonetworking-01.txt):

o) Communication mode: The geoanycast, geounicast and geobroadcast communication modes MUST be supported by the Internet-wide geo-networking solution.

o) Security and privacy: The Internet-wide geo-networking solution MUST support security 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) Reliable communications: The Internet geo-networking solution SHOULD support reliable communications with the highest reliability for messages used for e.g., ITS traffic safety use cases.

Note that more requirements are listed in: http://www.ietf.org/id/draft-karagiannis-problem-statement-geonetworking-01.txt

Best regards,
Georgios

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 15 Nov 2013 11:51:33 -0800

Georgios

in the interest of
> (1) stimulate discussion, (2) modify the description

some comments.

On Fri, 2013-11-15 at 05:40 +0000, [email-masked] wrote:
> Hi all,
> 
>  
> 
> Below I am giving a brief problem statement description associated
> with Internet-wide geonetworking. 

If this is a 'definition', then you're on the right track.  But I'm
still foggy on a definition of 'geonetworking'.  More below.

>  
> 
> The goal of this email is to (1) stimulate discussion, (2) modify the
> description of the listed challenges/open issues, (3) add new
> challenges and (4) modify/add requirements.

Roger.

> 
>  
> 
> Problem:
> 
> -------------
> 
> Standardized protocol(s) is/are needed to allow source nodes anywhere
> in the Internet to disseminate packets to all/any node(s) with
> geographic location awareness within a specified destination area.

This is the part I'm having problems swallowing.

Are you positing an application layer problem (7) or a network layer
problem (3)?  It makes a whole lot of difference.

First, if you say 'both', then you have too broad a scope for an IETF
working group.  Although there may be room for a quite different working
group on a 'systems' protocol _stack_.  This would be fairly novel and I
don't know how we'd go about bounding the scope of the problem.

(Why I'm sensitive.  I've just watched about 15 years of US DoD flailing
with a similar-sized scope problem with the Joint Tactical Radio System.
The program has now been canceled, after spending $B of the taxpayers
money and it has no deliverables.  We don't want [geonet/its] to repeat
that painful exercise.)

Second.  If you confine yourself to applications that are
'geography-aware', that limits the scope acceptably but ... we've been
here before.  Different standards body (OASIS) but Common Alerting
Protocol has a mechanism for geographic semantics (and would be messages
entirely germane to [its]).  
     From your note it would appear that there is a collective
addressing problem here??

Third.  If we are after a geography-aware routing information protocol,
then what's different from OLSR in MANET?  Tying routing to earth
geography rather than internet geography is trying to square a circle.
Particularly when you account for the facts that LANs and terrestrial
WANs have about four orders of magnitude more capacity than
radio-WANs.  

Challenge: Bounding the working group scope by layer is one successful
way out of the murk (but may not be what you're after).  

> Challenges/Open issues:

... more ...

> ------------------------
> 
>  
> 
> o) Mechanisms and/or protocol solutions are needed to ensure that
> geographical information  is available in the addressing mechanism,
> such that packets can be forwarded to a target geographical area.

Packets can be frames, datagrams or messages (layers 2, 3 and 7
respectively).  This makes the format question a reprise of the scope
question above.  I'm still lost in the murk, I'm afraid.  
> 
>  
> 
> o) Mechanisms and protocol solutions are needed to ensure that data
> packets generated by source nodes placed anywhere in the Internet are
> forwarded over multiple hops by using, where possible, the position of
> the destination node(s) and the positions of intermediate nodes for
> the routing decisions, instead of using their IP addresses.

I'm gagging on the last phrase in this paragraph.  It seems to me that
you're trying to describe an addressing problem and a multicast
addressing problem at that.  With a potentially rapidly changing address
group membership list that is indeed tied to earth geography.  If so,
why do you want to not use IP addressing?  It was these kinds of
expansions that IPv6 was conceived for.
> o) Communication mode:The geoanycast, geounicast and geobroadcast
> communication modes MUST be supported by the Internet-wide
> geo-networking solution.
> 
The nature of the data you have in mind is largely multicast -- on that
I agree.  And it's much more so than is 'normal' in the existing
internet.  (This is true of military, law enforcement, emergency
services, ... in general).  Without defining 'geoanycast' et al, we can
agree that a unicast solution is not adequate.
>  
> 
> o) Security and privacy: The Internet-wide geo-networking solution
> MUST support security objectives for all supported communication
> modes. Security objectives  particularly include integrity, privacy
> and non-repudiation 

OK so far, excepting some quibbles over definitions.  Authenticity is
the term I prefer and it's a superset of integrity.  Non-repudiation is
simply authenticity plus a receipt system.  The important question is
'security of WHAT?'

> and SHOULD protect the network and transport layer protocol headers. 

Protection of headers is infrastructure protection.  Which may be a
valid requirement (I'd tend to think so).  But that says nothing about
authenticity of the DATA which strikes me as a somewhat more important
requirement (imagine some mission critical information systems, like
those navigating your car, trying to operate while somebody is inserting
bogus data).  

Another way of saying WHAT is to be protected is to ask what the scope
of the security needed is.  Layer 2 security measures (like those in
WiFi) protect a single segment.  Layer 6/7 security measures (S/MIME)
protect data end-to-end.  What is it that we need?  

> 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.

Agreed.  It turns out that if you get the authenticity scope and
requirements done properly, the confidentiality issues are fairly easily
handled (for example, same PKI works for both).  
> 
>  
> 
> o) Reliable communications: The Internet geo-networking solution
> SHOULD support reliable communications with the highest reliability
> for messages used for e.g., ITS traffic safety use cases.

This rings back to the 'what layer?' question above.  All-sudden, for
the first time, you have a transport/session layer requirement.  

First, are you confusing a need for authenticity (imaging bogus traffic
safety messages) with a need for reliability (acknowledged delivery)?  I
think your statement could be interpreted either way and both
requirements need to be nailed down.

Second.  The foundation problem in multicast transport protocols is how
one handles a late joiner -- an end system that appears in the group
after a session is started.  How much history does that late joiner
require?  The problem does not appear in TCP because of it's unicast
nature, but it certainly appears in multicast.  Let me illustrate a
couple of real world 'today' examples:
  - weather 'grids' are commonly assembled and then file-transferred to
users.  There are lots of users out there, including a lot in the
potential [its] audience so multicast is a fairly obvious need.  And the
grids are essentially useless if you don't have the whole file.  So a
'late joiner' should cause the system to restart the file transfer.  
  - a 'common operational picture' information system is one where
multiple 'plots' show track reports.  Think EMS dispatching or military
command centers.  In these cases, the cast of players is constantly
changing -- a new ship joining the piracy-control area for example.  The
'session' may be months old ... scrolling back to the start for history
is neither necessary nor feasible.  But reliable delivery to the new
customer is just as important as it is to the existing ones.  

I've been using the term 'reliable' in the internet usage.  Reliable =
transport/session reliable.  Other groups (like radio manufacturers)
mean other things with the term 'reliable' (often simply high Ao).  What
definition are you using?  Probably needs to be explicit.

(I've also gotten a full dose of this inexactness; (US) National Public
Safety Telecom Council, whose experience is emergency service radio,
uses 'reliable' to mean high availability and good coverage (without
being explicit).  The notion of end-to-end, multi-hop reliability --
what the internet, specifically TCP, provides is an alien concept).  

The meta question that this statement raises is that you now just added
a couple more layers to your scope.  Which now looks like you're trying
to reinvent the internet ... and I think extending the internet to
mobile platforms makes somewhat more sense.

Hope this helps true up your problem statement...

b

---

From: "Carl Reed" <[email-masked]>
Date: Fri, 15 Nov 2013 18:06:26 -0700

Rex -

Other than CAP, OASIS has a Geography Markup Language (GML) Simple Features 
profile for use in OASIS standards. This profile is currently used in the 
EDXL suite of OASIS standards for encoding location. The next major revision 
to CAP may as well reference this GML simple features profile. GML is also 
used in NIEM - see the OGC project titled Geo4NIEM. A GML application schema 
is used by the internet community to define what they call geodetic 
(coordinate) location objects (LO). This LO is used by numerous RFCs.

GML is an OGC standard that is also double branded as an ISO international 
standard. GML consists of a number of packages. A key package is geometry, 
which the above examples use. The geometry package is based on an abstract 
model documented in ISO 19107: Spatial Schema.

GML is an XML schema which may make GML not appropriate for the form of 
Geonetworking being considered by this group. However, how one defines 
geometries should be consistent with ISO 19107. This would make any encoding 
consistent at a data model level with geographic encodings be used by OASIS, 
the OGC, the US Government (the DISR), the European Community (INSPIRE), 
ISO, and other groups in the IETF.

Cheers

Carl Reed, PhD
CTO
OGC

-----Original Message----- 
From: Rex Buddenberg
Sent: Friday, November 15, 2013 12:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [geonet/its] Internet-wide Geonetworking problem statement and 
challenges/open issues

Georgios

in the interest of

some comments.

Roger.

... more ...

b

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

---

From: Melinda Shore <[email-masked]>
Date: Sat, 16 Nov 2013 09:43:12 -0900

Hi, Georgios:

Thanks for you work in starting to get this broken down into
digestible pieces.  I think there are still two sets of problems:
1) some statements need wordsmithing to be clearer, and 2)
some of what's in here is problematic at a technical level.

On 11/14/13 8:40 PM, [email-masked] wrote:
> Standardized protocol(s) is/are needed to allow source nodes anywhere in
> the Internet to disseminate packets to all/any node(s) with geographic
> location awareness within a specified destination area.

You might want to spell out what "with geographic location
awareness" means.  And here or elsewhere you almost certainly
need to explain why the problem you'd like to solve is
different from ecrit (and where it overlaps).

> geographical information  is available in the addressing mechanism, such
> that packets can be forwarded to a target geographical area.

I'm still not sure exactly how you envision this working.
Is it the case that you expect some sender to say "I need
to send to all entities within a certain radius of some
geographic point," and a list of the addresses of those
entities will be returned, or ... ?

> the destination node(s) and the positions of intermediate nodes for the
> routing decisions, instead of using their IP addresses.

There's a wordsmithing issue here: you probably want to say
"can be forwarded" rather than "are forwarded."  Not a wordsmithing
issue: it may not be a great idea to couple IP routing with geolocation.
To be perfectly frank after the BOF a number of people said to me
"They're solving this at the wrong layer."  It's one thing if you're
absolutely committed to doing this in this way, but if you're open
to other approaches you might consider changing or removing this
text.  Also, up above I said you should probably discuss how
this differs and/or overlaps with ecrit; here you should probably
do the same with respect to manet.

The rest take the form of requirements, and it's almost certainly
early for that.  A crisp problem statement will help identify
requirements and I don't think you're there yet.  I'd

. drop the reference to communication modes
. change the security text to something along the lines of
  "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.  Also:
  geopriv
. frame any discussion of reliability in terms of the needed
  transport characteristics.  I don't know what "reliable"
  means here and you'll need to be clearer about that in any
  event.  For example, does reliable mean guaranteed delivery
  or does it mean timely delivery?  Etc.

Melinda