idnits 2.17.1 draft-ahn-its-geounicast-hbh-option-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 19, 2016) is 2678 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 69, but not defined -- Possible downref: Normative reference to a draft: ref. 'Geo-Problem' -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS-84' -- Possible downref: Non-RFC (?) normative reference: ref. 'GF' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBF' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 6 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 The IPv6 Hop-by-Hop Option for Geographical Unicast 6 draft-ahn-its-geounicast-hbh-option-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 IPv6-based ITS applications, ITS data packets are required to 48 be delivered to a specific destination ITS node. 49 In this draft, a new IPv6 Hop-by-Hop option, the IPv6 Geo-unicast 50 Hop-by-Hop option, with the geographical information of the 51 destination ITS node and the forwarding mechanism information 52 is defined. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Hop-by-Hop Option for Geographical Unicast . . . . . . . . . . 4 60 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Requirements notation 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 2. Introduction 72 For the support of IPv6-based ITS (Intelligent Transportation System) 73 applications, ITS data packets are required to be delivered based 74 on the geographical location (longitude and latitude) information of 75 the destination ITS node or area. We call the former geographical 76 unicast (in short, geo-unicast). 78 From the considerations in [Geo-Problem], in this draft, we define 79 the new IPv6 Geo-unicast Hop-by-Hop option with the geo-location 80 information of the destination ITS node. Also, the IPv6 Geo-unicast 81 Hop-by-Hop option has the field for the geographical unicast 82 mechanism from the originator to the destination ITS node. 84 3. Terminology 86 ITS node 87 A vehicle or a device that may generate ITS-related data 88 in the form of IPv6 datagrams 90 Geo-location 91 The location of an ITS node represented in the form of 92 longitude and latitude. The geo-location information 93 is represented in the form of the World Geodetic System 1984 94 (WGS84) [WGS-84] formatted coordinates. 96 Geographical Forwarding 97 IPv6 datagram forwarding based on the geo-location information 98 of the source and the destination ITS node or area. 99 Geographical unicast/broadcast and geocast belong to geographical 100 forwarding. 102 Geographical Unicast (Geo-unicast) 103 IPv6 datagram forwarding based on geo-location information 104 to a specific single target ITS node which can be a vehicle or 105 roadside unit (RSU) or any type of an IPv6 node. 107 Originator 108 The source ITS node that has generated this IPv6 datagram. 110 Sender 111 The previous hop ITS node that has forwarded this IPv6 datagram. 113 4. Hop-by-Hop Option for Geographical Unicast 115 The format of the Geocast Hop-by-Hop option is as follows: 117 0 1 2 3 118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Option Type | Opt Data Len | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 |C|GU Type|N|E|S|O|U| Reserved | Location Uncertainty | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Timestamp | Reserved | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Destination Latitude | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Destination Longitude | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Sender Latitude | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Sender Longitude | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Originator Latitude | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Originator Longitude | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 IPv6 Source Address 140 The Source IPv6 Address field of the IPv6 datagram is set to 141 the IPv6 address of the originator. 143 IPv6 Destination Address 144 The Destination IPv6 Address field of the IPv6 datagram is set to 145 the geo-unicast address to be assigned by IANA. 147 Option Type 148 The IPv6 Option Type code for IPv6 geo-unicast; to be assigned 149 by IANA. 151 Option Data Length 152 The number of octets of the option data field of this option. 154 C Flag 155 This indicates the geographical casting type. 'C = 0' implies 156 geographical unicast and 'C = 1' implies geocast. 157 Thus, in this case, C = 0. 159 Geo-Unicast Type 160 This indicates the geo-unicast forwarding type used 161 for the delivery of the IPv6 datagram from the originator to 162 the destination ITS node; e.g., Greedy Forwarding (GF) [GF], 163 Contension-Based Forwarding (CBF) [CBF], Greedy Perimeter 164 Stateless Routing (GPSR), Geographic Source Routing (GS), etc. 166 N Flag 167 If N = 1, it indicates the latitude is north relative to the 168 Equator. Otherwise, it indicates the latitude is south of 169 the Equator. 171 E Flag 172 If E = 1, it indicates the longitude is east of the Prime 173 Meridian. Otherwise, it indicates the longitude is west of 174 the Prime Meridian. 176 S Flag 177 If S = 1, the Sender Latitude Degree and the Sender Longitude 178 Degree fields are specified. Otherwise, those fields do not exist. 180 O Flag 181 If O = 1, the Originator Latitude Degree and the Originator 182 Longitude Degree fields are specified. Otherwise, those fields 183 do not exist. 185 U Flag 186 If U = 1, the Location Unicertainty field is specified. 187 Otherwise, the field is not specified. 189 Reserved 190 The reserved field for further extensions of this option. 192 Location Unicertainty 193 The uncertainty of the location (in centimeters). 195 Timestamp 196 Time when this IPv6 datagram was generated in seconds since 197 the epoch (00:00:00 UTC on 1 January 1970). 199 Destination Latitude 200 A range of 0 - 90 degrees (in 1/10 micro degrees) north or 201 south of the Equator (northern or southern hemisphere, 202 respectively) of the destination ITS node. 204 Destination Longitude 205 A range of 0 - 180 degrees (in 1/10 micro degrees) east or 206 west of the Prime Meridian of the destination ITS node. 208 Sender Latitude 209 A range of 0 - 90 degrees (in 1/10 micro degrees) north or 210 south of the Equator (northern or southern hemisphere, 211 respectively) of the sender. 213 Sender Longitude 214 A range of 0 - 180 degrees (in 1/10 micro degrees)s east or 215 west of the Prime Meridian of the sender. 217 Originator Latitude 218 A range of 0 - 90 degrees (in 1/10 micro degrees) north or 219 south of the Equator (northern or southern hemisphere, 220 respectively) of the originator. 222 Originator Longitude 223 A range of 0 - 180 degrees (in 1/10 micro degrees) east or 224 west of the Prime Meridian of the originator. 226 5. Other Considerations 228 TBD. 230 References 232 [Geo-Problem] S. Ahn, "Problem Statements of IPv6-based Geographical 233 Forwarding for ITS", IETF Draft draft-ahn-its-geo-problem-00.txt, 234 2016. 235 [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic 236 System 1984", January 2000, . 238 [GF] B. N. Karp, H. T. Kung, "GPSR: Greedy Perimeter Stateless 239 Routing for Wireless Networks", ACM/IEEE International 240 Conference on Mobile Computing and Networking (MobiCom), 2000. 241 [CBF] H. Fu.b.ler, J. Widmer, M. Ka.semann, M. Mauve, H. Hartenstein, 242 "Contention-based Forwarding for Mobile Ad Hoc Networks", 243 Ad Hoc Networks, 2003. 245 Author's Address 247 Sanghyun Ahn 248 University of Seoul 249 90, Cheonnong-dong, Tongdaemun-gu 250 Seoul 130-743 251 Korea 252 Email: ahn@uos.ac.kr