Internet DRAFT - draft-karagiannis-geonet-problem-statement
draft-karagiannis-geonet-problem-statement
Internet Engineering Task Force Georgios Karagiannis
Internet-Draft University of Twente
Intended status: Informational Alexandru Petrescu
Expires: December 15, 2014 CEA
Dimitri Papadimitriou
Alcatel-Lucent
Bastiaan Wissingh
TNO
June 15, 2014
Problem Statement for Internet-wide Geo-networking
draft-karagiannis-geonet-problem-statement-00
Abstract
This document describes the need of intertwining of IP networking
with geographical addressing. As used today, IP routing and
addressing are completely unaware of geographic parameters such as
coordinates or postal addresses. Possible applications of future
Internet-wide geo-networking mechanisms include, but are not limited
to, dissemination of IP packets to geographical areas, or precise
tracking of package positions during a shipping process, with more
use-cases under discussion.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 15, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Karagiannis, et al. Expires December 15, 2014 [Page 1]
Internet-Draft Problem statement for GeoNet June 2014
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Challenges and main goal . . . . . . . . . . . . . . . . . . . .4
3. Internet-wide Geo-networking use cases . . . . . . . . . . . . 5
4. Assumptions and Requirements . . . . . . . . . . . . . . . . . 6
5. Relationships between GeoNet and other IETF Working Groups . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
10. Informative References . . . . . . . . . . . . . . . . . . . 9
11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . 10
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Internet-based applications are currently using IP addresses to
address interfaces of a node that can be for example a host, a
server or a router. IP routing and addressing are completely unaware
of geographic parameters such as coordinates or postal addresses.
Future applications and use cases have been identified that need to
support among others the (1) dissemination IP packets to geographical
areas, (2) precise tracking of package positions during a shipping
process, (3)dissemination of traffic safety, traffic efficiency &
management, and infotainment type of vehicular information to fixed
and mobile Road Side Units (RSUs) through the Internet, (4) tracking
and communicating with people or objects located in certain
geographical areas, e.g., Oiler Riggers, where Oil companies want to
track employees in the field, where the conditions can be dangerous
and the employee's safety needs to be verified.
In order to support such future applications and use cases Internet-
wide Geo-networking solutions need to be specified within the context
of the new and to be started GeoNet IETF working group.
Internet-wide Geo-networking can be considered as the solution space
that includes mechanisms and protocols used to disseminate packets
sent by authorized source nodes located anywhere in the Internet to
other nodes in areas described by geographical parameters.
An example scenario that can be used for the support of
Internet-wide geo-networking is shown in Figure 1. This scenario
shows a source node, which can be located anywhere in the Internet,
and is interconnected with access routers via the Internet. The
packets generated by the source are disseminated through the Internet
to other nodes in areas described by geographical parameters.
Karagiannis, et al. Expires December 15, 2014 [Page 2]
Internet-Draft Problem statement for GeoNet June 2014
Coverage
Area
- ~ -
` `
' '
+------+ ` `
___|Access|____` `
+----------+ / |Router| +`-----------------`+
/ \ / +------+ | ` O ` |
+------+ / \/ | ' - ~ - ' |
|Source|___/ Internet \ | ` O ` |
| Node | \ / | ' - ~ - ' |
+------+ \ /\ +------+ | ` ` |
\ / \____|Access|____, O `|
+----------+ |Router| |` `|
+------+ | ` ` |
| ' ' |
| ` - ~ - ` |
| Destination Area |
+-------------------+
O Destination Nodes
Figure 1: Internet-wide geo-networking scenario
1.2. Terminology
Internet-wide Geo Networking
the solution space that includes mechanisms and protocols used to
disseminate packets sent by authorized source nodes located
anywhere in the Internet to other nodes in areas described by
geographical parameters.
Geographic coordinate system:
a coordinate system that enables every location on the Earth to be
specified by a set of numbers or letters.
Road Side Unit (RSU)
equipment located along highways, at traffic intersections and
other type of locations where timely communications with vehicles
are needed. Each RSU includes DSRC (Direct Short Range Radio,
e.g., IEEE 802.11p) radio, a positioning system and a router to
route packets back through the infrastructure network. RSU is
also known as RSE (Road Side Equipment)
Traffic safety application
application that is primarily applied to decrease the probability
of traffic accidents and the loss of life of the occupants of
vehicles.
Karagiannis, et al. Expires December 15, 2014 [Page 3]
Internet-Draft Problem statement for GeoNet June 2014
Traffic efficiency & management application:
application that is primarily applied to improve vehicle traffic
flow, traffic coordination and traffic assistance and provide
updated local information, maps and in general, messages of
relevance bounded in space and/or time
Infotainment applications:
all other types of Internet based applications, for example media
downloading
1.4. Organization of This Document
This document is organized as follows. Section 2 describes several
challenges and open issues associated with Internet-wide Geo-
networking solutions. Furthermore, Section 2 emphasizes the main goal
of the GeoNet IETF working group. Section 3 provides a brief
description of Internet-wide Geo-networking use cases. Section 4
lists the Internet-wide Geo-networking assumptions and
requirements. The relationships between GeoNet and other IETF working
groups are given in Section 5. Section 6 describes the security
considerations. The IANA considerations are listed in Section 7.
Section 8 provides the acknowledgements.
2 Challenges and main goal
2.1 Challenges and open issues
The challenges and open issues that need to be addressed by Internet-
wide Geo-networking solutions are:
o) Mechanisms and protocol solutions are needed for the accurate
(i.e., precise and up to date) representation of geographic areas
using (1) geo-locators such as names and (2) geographic
coordinates.
o) Mechanisms and protocol solutions are needed to ensure that
geographical area information (e.g. geo-locators, names,
geographic coordinates) is accurately mapped to an IP
locator, i.e. an IP address. Mapping data bases can be maintained
at the source nodes, intermediate or edge nodes, and at specific
IP locator nodes.
o) Mechanisms and protocol solutions are needed to ensure that the IP
addresses of access routers, Road Side Units (RSUs), and so on can
be accurately mapped to geographic area information (geo-locators,
names, and geographic coordinates). Mapping data bases
can be maintained at the source nodes, intermediate or edge nodes,
and at specific IP locator nodes.
Karagiannis, et al. Expires December 15, 2014 [Page 4]
Internet-Draft Problem statement for GeoNet June 2014
o) Mechanisms and protocol solutions are needed to ensure that data
packets generated by source nodes placed arbitrarily in the
Internet can be disseminated over multiple hops by using, where
possible, geographic 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".
2.2 Goal
Mechanisms and IETF protocols are needed for authorized source nodes
anywhere in the Internet to disseminate packets to other nodes in
areas described by geographical parameters, all while respecting
privacy concerns of sender and receiver. Parameters such as
geographical coordinates and other geo-locators such as civic
addresses should be used.
3. Internet-wide Geo-networking use cases
This section provides a brief description of the Internet-wide Geo-
networking use cases. The detailed description of each of these use
cases is provided in separate Internet drafts.
3.1 Dissemination of IP packets to geographical areas
A source node, which may be located anywhere, sends packets to a
an access router through the Internet. Those access
routers are selected based on geographical location information, and
traffic is routed to them using the IP 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
(1) radio coverage for wireless access routers or (2) IP subnet for
wired access routers.
3.2 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. An
important issue that needs to be taken into consideration in this use
case is the protection of privacy, i.e., provide confidentiality to
personal data and protect leaking information through protocol
behavior, such as relation between identifier and location.
3.3 Dissemination of ITS (Intelligent Transportation System) information
to fixed and mobile RSUs via Internet
Karagiannis, et al. Expires December 15, 2014 [Page 5]
Internet-Draft Problem statement for GeoNet June 2014
In this use case traffic safety, traffic efficiency & management, and
infotainment type of vehicular information is disseminated to fixed
and mobile Road Side Units (RSUs) through the Internet. Most RSUs are
placed at a fixed geographical location that will most likely not be
changed until the device either reaches its end of life or is no
longer needed at that location. A so called 'Mobile RSU' 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 RSU'
is very flexible for use in multiple situations. Examples of such
situations include the case that a permanently installed unit fails
and needs a temporarily backup unit or during road construction. In
the latter case, a road worker could take a Mobile RSU, position it
somewhere at the road works site, and start sending warning messages
to approaching vehicles. The next day the mobile RSU can be
positioned elsewhere. The protection of privacy is an important issue
for this use case and needs to be taken into consideration.
3.4 Tracking and communicating with people or objects located in certain
geographical areas
Companies, like Oil companies want to track employees in the field,
where the conditions can be dangerous and the employee's safety needs
to be verified. Such a dangerous situation can be the explosion (or
the high risk of explosion) of an Oil rigger. In such a situation the
Oil company needs to be able to disseminate recovery instructions to
all employees that are within a certain radius of the explosion
(e.g., 1 mile).
4. Assumptions and Requirements
This section includes the assumptions and the requirements that need
to be fulfilled by Internet-wide Geo-networking solutions.
4.1 Assumptions
The assumptions associated with the Internet-wide geo-networking
solutions are:
o) The destination nodes can be static or moving entities, such as
hosts, vehicles, goods sensors and actuators, that are spread
in a certain target/destination geographic area.
o) existing IETF mechanisms and protocols like the ones
specified and standardized by the IETF WGs: LISP [LISP],
GEOPRIV [GEOPRIV], ECRIT [ECRIT] will be taken into
consideration during the design phase.
Karagiannis, et al. Expires December 15, 2014 [Page 6]
Internet-Draft Problem statement for GeoNet June 2014
o) The document "ISO 19107: Geographic information - Spatial
Schema" [ISO19107] will be considered for the representation of
spatial characteristics of geographic features (including
geometries), and a set of spatial operations consistent with
these schemas. This document treats of vector geometry and
topology of up to three dimensions. Geometries range from
point, multipoint, to polygon, to Bezier curves and to
Clothoids.
o) Documents from IEEE P1609.2 [IEEE1609.2] may be considered for
security and privacy support on IEEE 802.11p [IEEE802.11p]
links.
4.2 Requirements
The specified Internet-wide geo-networking 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 for
selection of receivers
o) MUST be able to disseminate the information from senders to the
destination nodes located in the destination geographic area in
a point to multipoint manner.
o) SHOULD be able to scale, leveraging stable and deterministic
under-layers when available, and maintain its performance and
precision to acceptable levels even if it is applied in
contexts of:
(1) global coverage with small destination geographic areas,
(2) large traffic volumes or large flows,
(3) large number of simultaneously active sources.
o) MUST be able to provide accurate representation of geographic
areas using: (1) standardized geo-locators 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.
Karagiannis, et al. Expires December 15, 2014 [Page 7]
Internet-Draft Problem statement for GeoNet June 2014
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 a
particular attention must be paid to security and privacy. A
thorough threat analysis should be conducted, and mitigations
specified; this applies to any protocol documents in this
context, for any communication modes. Security objectives
particularly include integrity, privacy and non-repudiation and
SHOULD protect the network and transport layer protocol
headers. In addition any potential Internet-wide geo-
networking solution MUST also protect privacy, i.e. provide
confidentiality to personal data and protect leaking
information through protocol behavior, such as the relation
between identifier and location.
o) SHOULD support timely and guaranteed delivery of information.
5. Relationships between GeoNet and other IETF Working Groups
Any new use-cases that the GeoNet WG comes up with that require
protocol changes for any overlay technology, such as LISP, can be
done in the appropriate protocol working groups, such as the LISP WG.
The following relationships between GeoNet and other IETF WGs have
been identified:
o) The GEOPRIV WG [GEOPRIV] concentrates on protocols that allow
applications to represent location/geography objects and to
allow users to express policies on how these representations
are exposed and used. Moreover, the GEOPRIV WG analyses the
authorization, integrity, and privacy requirements that must be
met when these representations of location/geography are
created, stored, and used. GeoNet mainly focuses on how IP
routing and addressing uses such location/geography
representations.
o) The LISP WG [LISP] mainly focuses 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
focuses 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.
o) The ECRIT WG [ECRIT] mainly focuses on how location data and
call routing information are used to enable communication
between a user and a relevant emergency response center.
Karagiannis, et al. Expires December 15, 2014 [Page 8]
Internet-Draft Problem statement for GeoNet June 2014
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 focuses 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.
6. Security Considerations
Due to the sensitivity of location data and the possibility of the
technology being used in emergency and/or road traffic management
scenarios a particular attention must be paid to security and
privacy. Security objectives particularly include integrity, privacy
and non-repudiation and SHOULD protect the network and transport
layer protocol headers. In addition any potential Internet-wide Geo-
networking solution MUST also protect privacy, i.e. provide
confidentiality to personal data and protect leaking
information through protocol behavior, such as the relation between
identifier and location.
7. IANA Considerations
No IANA considerations are considered in this document.
8. Acknowledgments
We would like to thank the members of the IETF ITS and GeoNet
community for their comments and discussions. In particular, we would
like than the following contributors: Melinda Shore, Dino Farinacci,
Geert Heijenk, Andreas Festag, Alison Chaiken, Duan Shihui, Rex
Buddenberg, Carl Reed, Brian Rosen, Yong-Geun Hong, Robert Moskowitz,
Ray Bellis.
9. Normative References
10. Informative References
[ISO19107] International standard ISO 19107, "Geographic information
- Spatial Schema", International Standards Organization (ISO), 01-05-
2003
[IEEE1609.2] IEEE 1609.2, "Trial-Use Standard for Wireless
Access in Vehicular Environments - Security Services for Applications
and Management Messages", IEEE, (date Original version) July 6 2006;
Revised on October 17, 2013
[IEEE802.11p] IEEE Std 802.11p(TM)-2010, "IEEE Standard for
Information Technology - Telecommunications and information exchange
between systems - Local and metropolitan area networks -Specific
requirements, Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications, Amendment 6: Wireless Access in
Vehicular Environments", IEEE, 2010, document freely available at URL
http://standards.ieee.org/getieee802/download/802.11p-2010.pdf
Karagiannis, et al. Expires December 15, 2014 [Page 9]
Internet-Draft Problem statement for GeoNet June 2014
[ECRIT] official website of IETF WG ECRIT (Emergency Context
Resolution with Internet Technologies),
http://datatracker.ietf.org/wg/ecrit/
[GEOPRIV] official website of IETF WG GEOPRIV (Geographic
Location/Privacy), http://datatracker.ietf.org/wg/geopriv/
[LISP] official website of IETF WG LISP (Locator/ID Separation
Protocol), http://datatracker.ietf.org/wg/lisp/
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11. Authors' Address
Georgios Karagiannis
University of Twente
P.O. Box 217
7500 AE Enschede,
The Netherlands
EMail: g.karagiannis@utwente.nl
Alexandru Petrescu
CEA
Communicating Systems Laboratory, Point Courrier 173
Palaiseau, F-91120
France
Phone: +33(0)169089223
Email: alexandru.petrescu@cea.fr
Dimitri Papadimitriou
Alcatel-Lucent
Copernicuslaan, 50
2018 Antwerpen, Belgium
Phone: +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel-lucent.com
Bastiaan Wissingh
TNO
Brassersplein 2
Delft 2612CT
the Netherlands
EMail: bastiaan.wissingh@tno.nl
12. Contributors
Melinda Shore
No Mountain Software
PO Box 16271
Two Rivers, AK 99716
US
Phone: +1 907 322 9522
EMail: melinda.shore@nomountain.net
Karagiannis, et al. Expires December 15, 2014 [Page 10]
Internet-Draft Problem statement for GeoNet June 2014
Dino Farinacci
lispers.net
San Jose, California
USA
Phone: 408-718-2001
Email: farinacci@gmail.com
Geert Heijenk
University of Twente
P.O. Box 217
7500 AE Enschede,
The Netherlands
EMail: geert.heijenkg@utwente.nl
Andreas Festag
Technical University Dresden & NEC Laboratories Europe
Germany
Email: andreas.festag@ifn.et.tu-dresden.de?;
Alison Chaiken
Mentor Embedded Software Division
46871 Bayside Parkway
Fremont, CA 94538
USA Email: alison@she-devel.com
Duan Shihui
RITT
EMail: duanshihui@ritt.cn
Rex Buddenberg
EMail: buddenbergr@gmail.com
Carl Reed
Open Geospatial Consortium (OGC)
EMail: creed@opengeospatial.org
Brian Rosen
Neustar
470 Conrad Dr
Mars, PA 16046
USA
EMail: br@brianrosen.net
Yong-Geun Hong
ETRI
218 Gajeong-ro Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 6557
Email: yghong@etri.re.kr
Karagiannis, et al. Expires December 15, 2014 [Page 11]
Internet-Draft Problem statement for GeoNet June 2014
Robert Moskowitz
Verizon
1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA
USA
EMail: robert.moskowitz@verizon.com
Robert Moskowitz
Verizon
1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA
USA
EMail: robert.moskowitz@verizon.com
Ray Bellis
Nominet UK
Edmund Halley Road
Oxford OX4 4DQ
United Kingdom
Phone: +44 1865 332211
Email: ray.bellis@nominet.org.uk
Karagiannis, et al. Expires December 15, 2014 [Page 12]
