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]