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

["Carl Reed" <[e-mail]>]

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: [e-mail]
Cc: [e-mail]
Subject: Re: [geonet/its] Internet-wide Geonetworking problem statement and 
challenges/open issues

Georgios

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

some comments.


On Fri, 2013-11-15 at 05:40 +0000, [e-mail] 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.
>
>
> ---------------------
>
> 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.
>
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


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