idnits 2.17.1 draft-ahn-its-geo-problem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 203 has weird spacing: '...warding mecha...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 19, 2016) is 2685 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 70, but not defined == Missing Reference: 'Geo' is mentioned on line 135, but not defined == Unused Reference: 'Geonet' is defined on line 238, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GF' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBF' -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS-84' -- Possible downref: Non-RFC (?) normative reference: ref. 'Geonet' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'Geocast' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MANET Working Group Sanghyun Ahn 2 Internet Draft University of Seoul 3 Expires: June 11, 2017 December 19, 2016 5 Problem Statements of IPv6-based Geographical Forwarding for ITS 6 draft-ahn-its-geo-problem-00.txt 8 Status of this Memo 10 This Internet-Draft is submitted to IETF in full conformance with the 11 provisions of BCP 78 and BCP 79. This document may not be modified, 12 and derivative works of it may not be created, except to format it 13 for publication as an RFC or to translate it into languages other 14 than English. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on June 11, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 For the support of IPv6-based ITS applications, ITS data packets are 48 required to be delivered based on the geographical location 49 (longitude and latitude) information of the destination ITS node 50 or area. Therefore, geographical forwarding mechanisms are preferred 51 in the ITS environment. In this draft, we define the issues 52 to be considered in delivering IPv6 ITS data based on geographical 53 location. 55 Table of Contents 57 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Problem Statements of ITS Geographical Forwarding . . . . . . 4 61 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Requirements notation 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Introduction 73 For the support of IPv6-based ITS (Intelligent Transportation System) 74 applications, ITS data packets are required to be delivered based 75 on the geographical location (longitude and latitude) information of 76 the destination ITS node (e.g., vehicle)or area. 77 Since ITS nodes tend to move at high speed, data packet delivery 78 based on the IPv6 address may not work efficiently. 79 Hence, geographical forwarding (or routing) mechanisms such as 80 Greedy Forwarding (GF) [GF] and Contention-Based Forwarding 81 (CBF) [CBF] are preferred in the ITS environment. 83 In this draft, we define the issues to be considered in delivering 84 IPv6 datagrams from a source ITS node to a destination ITS node or 85 to the ITS nodes in a given destination area based on 86 geographical location. 88 3. Terminology 90 ITS node 91 A vehicle or a device that may generate ITS-related data 92 in the form of IPv6 datagrams 94 Geo-location 95 The location of an ITS node represented in the form of 96 longitude and latitude. The geo-location information 97 is represented in the form of the World Geodetic System 1984 98 (WGS84) [WGS-84] formatted coordinates. 100 Geographical Forwarding 101 IPv6 datagram forwarding based on the geo-location information 102 of the source and the destination ITS node or area. 103 Geographical unicast/broadcast and geocast belong to geographical 104 forwarding. 106 Geographical Unicast (Geo-unicast) 107 IPv6 datagram forwarding based on geo-location information 108 to a specific single target ITS node which can be a vehicle or 109 roadside unit (RSU) or any type of an IPv6 node. 111 Geo-Broadcast 112 IPv6 datagram broadcasting to all the ITS nodes within a specific 113 geographical area based on geo-location information. 114 It can be done by flooding, etc. 116 Geocast 117 IPv6 datagram forwarding from an ITS node to the ITS nodes 118 in a specific target destination area based on geo-location 119 information. Geocast is performed by geographical unicast to 120 the center point of the destination area and, then, geographical 121 broadcast within the destination area. 123 Destination Area 124 The geographical area in which this IPv6 datagram needs to be 125 forwarded by geocast; that is, all the ITS nodes in the 126 destination area are supposed to receive this IPv6 datagram. 128 4. Problem Statements of ITS Geographical Forwarding 130 For IPv6-based geographical forwarding, the following issues are to 131 be considered: 133 - Inclusion of geographical information: 134 For the sake of simplicity, instead of adding a new shim header for 135 geographical forwarding such as the GeoNetworking protocol [Geo], 136 adding geographical information in the IPv6 header is more 137 desirable. An extra header or layer for the geographical forwarding 138 increases the frame size and may incur redundant information. 139 In the GeoNetworking protocol, the ITS Network and Transport Layer 140 with the IPv6-Adaptation Sub-Layer (GN6ASL) is defined under the 141 IPv6 Network layer, which requires an extra shim header for 142 geographical forwarding. The GeoNetworking protocol defines 143 the GeoNetworking header and the 8-byte GeoNetworking address. 144 In this case, the destination IPv6 address capability is almost 145 dummy from the perspective of routing functionality. 146 Also, the Common header has the Traffic Class and the Hop Limit 147 fields which are similar to the Traffic Class and the Hop Limit 148 fields of the IPv6 header. Therefore, we propose to use 149 the IPv6 extension header for the support of geographical 150 forwarding based only on the IPv6 functionality. 152 Because the geo-location information of a destination node are to 153 be checked at each intermediate node for the decision of forwarding 154 the datagram, the destination geo-location information must be 155 included in the IPv6 Hop-by-Hop Options extension header of 156 the datagram [2460]. RFC 6564 [6564] mandates not to create or specify 157 any new options for the existing Hop-by-Hop Options extension 158 header unless no alternative solution is feasible because of 159 security reasons and/or processing speed. However, in the 160 vehicle-to-vehicle (V2V) communication-based ITS environment 161 with geographical forwarding capability, the Hop-by-Hop Option 162 header with the destination geo-location information should be 163 used to allow every intermediate node to check on the possibility 164 of forwarding the packet to the destination geo-location. 165 - IPv6 address range(s) for geographical forwarding: 166 For geographical forwarding to work, the IPv6 address ranges 167 for geographical forwarding are required to be assigned by 168 the Internet Assigned Numbers Authority (IANA). If the destination 169 IPv6 address belongs to any geographical address ranges, 170 the node receiving the IPv6 datagram forwards it accordingly 171 by processing the IPv6 Hop-by-Hop option for geographical 172 forwarding. 173 - Shape of destination areas of geocasting [Geocast]: 174 For geocasting, the shape of the destination area needs to be 175 considered. According to the shape of the road and the 176 transmission range of vehicles equipped with the IEEE 802.11p 177 capability, the shape of the target area is almost rectangular. 178 In order to specify the rectangular shape, at least two coordinates 179 of the diagonal of the destination area are required. 180 That is, the latitude and longitude information of the two points 181 of the diagonal of the destination area are to be included in 182 the IPv6 Hop-by-Hop option. On the other hand, if we assume that 183 the shape of the destination area is circular, then only the 184 coordinate of the center point of the destination area and the 185 radius information are sufficient. Specifying the coordinate is 186 more complicate and burdensome compared with specifying the radius. 187 Even if we assume that the shape of the destination area is 188 circular, in practice, it becomes rectangular. Hence, it is not 189 necessary to be strict in specifying the shape of the destination 190 area; that is, the circular shape of the destination area is 191 sufficient. 192 - Detail forwarding mechanism of geocasting: 193 Geocasting of an IPv6 datagram means that the IPv6 datagram is 194 supposed to be delivered to all the ITS-related nodes in the 195 destination area. Based on the above-mentioned consideration on 196 the shape of the destination area (that is, the circular shape of 197 the destination area), geocasting of an IPv6 datagram can be 198 achieved by, firstly, forwarding the datagram to the center point 199 of the destination area and, then, from the center point, 200 the IPv6 datagram is broadcast to the entire destination area. 202 - Geo-location information to be included: 203 We can classify geographical forwarding mechanisms into two 204 categories, the sender-based and the receiver-based mechanisms. 205 In the sender-based mechanisms like GF, the sender decides 206 the next-hop node based on the geo-location information of 207 its neighbors (obtained by exchanging beacons with neighbors) 208 and the destination geo-location. In the case of GF, only the 209 geo-location information of the destination need be delivered 210 to the chosen next-hop node. That is, the sender geo-location 211 information is not necessary any more by the next-hop node. 212 On the other hand, the receiver-based mechanisms like CBF 213 make each receiver (neighbor) decide whether it can be 214 the next-hop node or not based on its own geo-location, 215 the sender geo-location and the destination geo-location. 216 That is, in CBF, the sender geo-location and the destination 217 geo-location have to be delivered to the neighbors 218 (next-hop candidates). All these implicate that the sender 219 geo-location information is optional. However, in the GeoUnicast 220 packet header format of the GeoNetworking protocol, the sender 221 position vector (SO PV, the sender geo-location) is not optional. 223 5. Other Considerations 225 TBD. 227 References 229 [GF] B. N. Karp, H. T. Kung, "GPSR: Greedy Perimeter Stateless 230 Routing for Wireless Networks", ACM/IEEE International 231 Conference on Mobile Computing and Networking (MobiCom), 2000. 232 [CBF] H. Fu.b.ler, J. Widmer, M. Ka.semann, M. Mauve, H. Hartenstein, 233 "Contention-based Forwarding for Mobile Ad Hoc Networks", 234 Ad Hoc Networks, 2003. 235 [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic 236 System 1984", January 2000, . 238 [Geonet] "Intelligent Transport Systems (ITS); Vehicular 239 Communications; Geonetworking; Part4: Geographical Addressing and 240 Forwarding for Point-to-Point and Point-to-Multipoint 241 Communications; Sub-part1: Media-Independent Functionality", 242 ETSI TS 102 636-4-1 V1.1.1, 2011. 243 [2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) 244 Specification," RFC 2460, December 1998. 245 [6564] S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland and M. Bhatia, 246 "A Uniform Format for IPvt Extension Headers," RFC 6564, 247 April 2012. 249 [Geocast] J.C. Navas, T. Imielinski, "GeoCast - Geographic Addressing 250 and Routing. The 3rd Annual ACM/IEEE International Conference on 251 Mobile Computing and Networking, 1997. 253 Author's Address 255 Sanghyun Ahn 256 University of Seoul 257 90, Cheonnong-dong, Tongdaemun-gu 258 Seoul 130-743 259 Korea 260 Email: ahn@uos.ac.kr