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, . [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]