Internet DRAFT - draft-ahn-its-geo-problem
draft-ahn-its-geo-problem
MANET Working Group Sanghyun Ahn
Internet Draft University of Seoul
Expires: June 11, 2017 December 19, 2016
Problem Statements of IPv6-based Geographical Forwarding for ITS
draft-ahn-its-geo-problem-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 11, 2017.
Copyright Notice
Copyright (c) 2016 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.
Ahn Expires June 11, 2017 [Page 1]
Internet-Draft Problem Statements of IPv6-based Geographic December 2016
Abstract
For the support of IPv6-based ITS applications, ITS data packets are
required to be delivered based on the geographical location
(longitude and latitude) information of the destination ITS node
or area. Therefore, geographical forwarding mechanisms are preferred
in the ITS environment. In this draft, we define the issues
to be considered in delivering IPv6 ITS data based on geographical
location.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statements of ITS Geographical Forwarding . . . . . . 4
5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 6
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Ahn Expires June 11, 2017 [Page 2]
Internet-Draft Problem Statements of IPv6-based Geographic December 2016
1. Requirements notation
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 [RFC2119].
2. Introduction
For the support of IPv6-based ITS (Intelligent Transportation System)
applications, ITS data packets are required to be delivered based
on the geographical location (longitude and latitude) information of
the destination ITS node (e.g., vehicle)or area.
Since ITS nodes tend to move at high speed, data packet delivery
based on the IPv6 address may not work efficiently.
Hence, geographical forwarding (or routing) mechanisms such as
Greedy Forwarding (GF) [GF] and Contention-Based Forwarding
(CBF) [CBF] are preferred in the ITS environment.
In this draft, we define the issues to be considered in delivering
IPv6 datagrams from a source ITS node to a destination ITS node or
to the ITS nodes in a given destination area based on
geographical location.
3. Terminology
ITS node
A vehicle or a device that may generate ITS-related data
in the form of IPv6 datagrams
Geo-location
The location of an ITS node represented in the form of
longitude and latitude. The geo-location information
is represented in the form of the World Geodetic System 1984
(WGS84) [WGS-84] formatted coordinates.
Geographical Forwarding
IPv6 datagram forwarding based on the geo-location information
of the source and the destination ITS node or area.
Geographical unicast/broadcast and geocast belong to geographical
forwarding.
Ahn Expires June 11, 2017 [Page 3]
Internet-Draft Problem Statements of IPv6-based Geographic December 2016
Geographical Unicast (Geo-unicast)
IPv6 datagram forwarding based on geo-location information
to a specific single target ITS node which can be a vehicle or
roadside unit (RSU) or any type of an IPv6 node.
Geo-Broadcast
IPv6 datagram broadcasting to all the ITS nodes within a specific
geographical area based on geo-location information.
It can be done by flooding, etc.
Geocast
IPv6 datagram forwarding from an ITS node to the ITS nodes
in a specific target destination area based on geo-location
information. Geocast is performed by geographical unicast to
the center point of the destination area and, then, geographical
broadcast within the destination area.
Destination Area
The geographical area in which this IPv6 datagram needs to be
forwarded by geocast; that is, all the ITS nodes in the
destination area are supposed to receive this IPv6 datagram.
4. Problem Statements of ITS Geographical Forwarding
For IPv6-based geographical forwarding, the following issues are to
be considered:
- Inclusion of geographical information:
For the sake of simplicity, instead of adding a new shim header for
geographical forwarding such as the GeoNetworking protocol [Geo],
adding geographical information in the IPv6 header is more
desirable. An extra header or layer for the geographical forwarding
increases the frame size and may incur redundant information.
In the GeoNetworking protocol, the ITS Network and Transport Layer
with the IPv6-Adaptation Sub-Layer (GN6ASL) is defined under the
IPv6 Network layer, which requires an extra shim header for
geographical forwarding. The GeoNetworking protocol defines
the GeoNetworking header and the 8-byte GeoNetworking address.
In this case, the destination IPv6 address capability is almost
dummy from the perspective of routing functionality.
Also, the Common header has the Traffic Class and the Hop Limit
fields which are similar to the Traffic Class and the Hop Limit
fields of the IPv6 header. Therefore, we propose to use
the IPv6 extension header for the support of geographical
forwarding based only on the IPv6 functionality.
Ahn Expires June 11, 2017 [Page 4]
Internet-Draft Problem Statements of IPv6-based Geographic December 2016
Because the geo-location information of a destination node are to
be checked at each intermediate node for the decision of forwarding
the datagram, the destination geo-location information must be
included in the IPv6 Hop-by-Hop Options extension header of
the datagram [2460]. RFC 6564 [6564] mandates not to create or specify
any new options for the existing Hop-by-Hop Options extension
header unless no alternative solution is feasible because of
security reasons and/or processing speed. However, in the
vehicle-to-vehicle (V2V) communication-based ITS environment
with geographical forwarding capability, the Hop-by-Hop Option
header with the destination geo-location information should be
used to allow every intermediate node to check on the possibility
of forwarding the packet to the destination geo-location.
- IPv6 address range(s) for geographical forwarding:
For geographical forwarding to work, the IPv6 address ranges
for geographical forwarding are required to be assigned by
the Internet Assigned Numbers Authority (IANA). If the destination
IPv6 address belongs to any geographical address ranges,
the node receiving the IPv6 datagram forwards it accordingly
by processing the IPv6 Hop-by-Hop option for geographical
forwarding.
- Shape of destination areas of geocasting [Geocast]:
For geocasting, the shape of the destination area needs to be
considered. According to the shape of the road and the
transmission range of vehicles equipped with the IEEE 802.11p
capability, the shape of the target area is almost rectangular.
In order to specify the rectangular shape, at least two coordinates
of the diagonal of the destination area are required.
That is, the latitude and longitude information of the two points
of the diagonal of the destination area are to be included in
the IPv6 Hop-by-Hop option. On the other hand, if we assume that
the shape of the destination area is circular, then only the
coordinate of the center point of the destination area and the
radius information are sufficient. Specifying the coordinate is
more complicate and burdensome compared with specifying the radius.
Even if we assume that the shape of the destination area is
circular, in practice, it becomes rectangular. Hence, it is not
necessary to be strict in specifying the shape of the destination
area; that is, the circular shape of the destination area is
sufficient.
- Detail forwarding mechanism of geocasting:
Geocasting of an IPv6 datagram means that the IPv6 datagram is
supposed to be delivered to all the ITS-related nodes in the
destination area. Based on the above-mentioned consideration on
the shape of the destination area (that is, the circular shape of
the destination area), geocasting of an IPv6 datagram can be
achieved by, firstly, forwarding the datagram to the center point
of the destination area and, then, from the center point,
the IPv6 datagram is broadcast to the entire destination area.
Ahn Expires June 11, 2017 [Page 5]
Internet-Draft Problem Statements of IPv6-based Geographic December 2016
- Geo-location information to be included:
We can classify geographical forwarding mechanisms into two
categories, the sender-based and the receiver-based mechanisms.
In the sender-based mechanisms like GF, the sender decides
the next-hop node based on the geo-location information of
its neighbors (obtained by exchanging beacons with neighbors)
and the destination geo-location. In the case of GF, only the
geo-location information of the destination need be delivered
to the chosen next-hop node. That is, the sender geo-location
information is not necessary any more by the next-hop node.
On the other hand, the receiver-based mechanisms like CBF
make each receiver (neighbor) decide whether it can be
the next-hop node or not based on its own geo-location,
the sender geo-location and the destination geo-location.
That is, in CBF, the sender geo-location and the destination
geo-location have to be delivered to the neighbors
(next-hop candidates). All these implicate that the sender
geo-location information is optional. However, in the GeoUnicast
packet header format of the GeoNetworking protocol, the sender
position vector (SO PV, the sender geo-location) is not optional.
5. Other Considerations
TBD.
References
[GF] B. N. Karp, H. T. Kung, "GPSR: Greedy Perimeter Stateless
Routing for Wireless Networks", ACM/IEEE International
Conference on Mobile Computing and Networking (MobiCom), 2000.
[CBF] H. Fu.b.ler, J. Widmer, M. Ka.semann, M. Mauve, H. Hartenstein,
"Contention-based Forwarding for Mobile Ad Hoc Networks",
Ad Hoc Networks, 2003.
[WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic
System 1984", January 2000, <http://earth-info.nga.mil/
GandG/publications/tr8350.2/wgs84fin.pdf>.
[Geonet] "Intelligent Transport Systems (ITS); Vehicular
Communications; Geonetworking; Part4: Geographical Addressing and
Forwarding for Point-to-Point and Point-to-Multipoint
Communications; Sub-part1: Media-Independent Functionality",
ETSI TS 102 636-4-1 V1.1.1, 2011.
[2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification," RFC 2460, December 1998.
[6564] S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland and M. Bhatia,
"A Uniform Format for IPvt Extension Headers," RFC 6564,
April 2012.
Ahn Expires June 11, 2017 [Page 6]
Internet-Draft Problem Statements of IPv6-based Geographic December 2016
[Geocast] J.C. Navas, T. Imielinski, "GeoCast - Geographic Addressing
and Routing. The 3rd Annual ACM/IEEE International Conference on
Mobile Computing and Networking, 1997.
Author's Address
Sanghyun Ahn
University of Seoul
90, Cheonnong-dong, Tongdaemun-gu
Seoul 130-743
Korea
Email: ahn@uos.ac.kr
Ahn Expires June 11, 2017 [Page 7]
