idnits 2.17.1 draft-farinacci-lisp-geo-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 82 has weird spacing: '...o-Point is a ...' == Line 85 has weird spacing: '...-Prefix forms...' -- The document date (October 12, 2016) is 2751 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-12 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-name-encoding-00 == Outdated reference: A later version (-02) exists of draft-jeong-its-v2i-problem-statement-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental October 12, 2016 5 Expires: April 15, 2017 7 LISP Geo-Coordinate Use-Cases 8 draft-farinacci-lisp-geo-01 10 Abstract 12 This draft describes how Geo-Coordinates can be used in the LISP 13 Architecture and Protocols. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 15, 2017. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 2 51 3. Geo-Points in RLOC-records . . . . . . . . . . . . . . . . . 3 52 4. Geo-Prefixes in EID-records and RLOC-records . . . . . . . . 3 53 5. Geo-Prefix and Geo-Point Encodings . . . . . . . . . . . . . 5 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 58 8.2. Informative References . . . . . . . . . . . . . . . . . 6 59 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6 60 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 6 61 B.1. Changes to draft-farinacci-lisp-geo--01.txt . . . . . . . 6 62 B.2. Changes to draft-farinacci-lisp-geo--00.txt . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 The LISP architecture and protocols [RFC6830] introduces two new 68 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 69 (RLOCs) which are intended to replace most use of IP addresses on the 70 Internet. To provide flexibility for current and future 71 applications, these values can be encoded in LISP control messages 72 using a general syntax that includes Address Family Identifier (AFI) 73 [RFC1700]. 75 This specification introduces the use of Geo-Coordinates that can be 76 used in EID-records and RLOC-records of LISP control messages. The 77 encoding format is specified in [LCAF] as the "Geo-Coordinates LCAF 78 Type". 80 2. Definition of Terms 82 Geo-Point is a Geo-Coordinate according to [GEO] that defines a 83 point from parameters Latitude, Longitude, and Altitude. 85 Geo-Prefix forms a circle of a geographic area made up of a Geo- 86 Point and a Radius. A Geo-Point is known to be "more-specific" 87 than a Geo-Prefix when its physical location is within the 88 geographic circle. 90 3. Geo-Points in RLOC-records 92 Geo-Points can accompany an RLOC-record to determine the physical 93 location of an ETR or RTR. This can aid in determining geographical 94 distance when topological distance is inaccurate or hidden. When 95 Geo-Points are encoded in RLOC-records with RLOC addresses the LCAF 96 AFI-List Type should be used. 98 Geo-Points can be used as the sole piece of information in an RLOC- 99 record when an EID maps to a Geo-Coordinate. If it is desirable to 100 find the geographical location of any EID, this method can be 101 convienent. 103 Here is a high-level use-case where an EID that maps to a Geo- 104 Coordinate can be used. Lets say that am EID is assigned to a 105 physical shipping package by a package delivery company. And the EID 106 is encoded as an IPv6 address where the tracking number is embedded 107 in an IPv6 EID. The network has LISP nodes deployed in many 108 locations that are configured with their respective Geo-Coordinates. 109 As the package roams, the LISP node that discovers the EID, registers 110 it to the LISP mapping system. The EID-to-RLOC mapping is EID=IPv6 111 and RLOC=Geo-Coordinate. If someone does a mapping database lookup 112 on the IPv6 EID, what is returned is the Geo-Coordinate. As the EID 113 roams, new registrations with different Geo-Coordinates are stored, 114 allowing the physical tracking of the package. 116 4. Geo-Prefixes in EID-records and RLOC-records 118 A Geo-Prefix is defined to be a Geo-Coordinate point and a Radius. 119 This allows a circle to be drawn on a geographic map. The Geo-Prefix 120 can describe a coarse physical location for an RLOC when encoded in 121 an RLOC-record. So an RLOC could be registered in the mapping 122 database indicating it is in a city or country versus the exact 123 location where a Geo-Point would locate it. 125 A Geo-Prefix could allow a Distinguished-Name [DIST-NAME] to be 126 registered as an EID with an RLOC that contains a Geo-Prefix. For 127 example EID="San Francisco", with RLOC=geo-prefix could be stored in 128 the mapping system. 130 A Geo-Prefix, when encoded in an EID-record, could be registered as 131 an EID-prefix and when a Geo-Point is used as an EID lookup key, a 132 sort of longest match could be looked up. If the Geo-Point is in the 133 Circle described by the Geo-Prefix, an entry is returned to the Map- 134 Requestor. 136 You could take a combination of mappings from the above examples to 137 ask the question: "Is the package in San Francisco"? This could be 138 done with two lookups to the mapping system: 140 Contents of Mapping Database: 141 EID= 142 RLOC= 144 EID= 145 RLOC= 147 EID= 148 RLOC= 150 Map-Request for package: 151 EID= 152 Mapping system returns: 153 RLOC= 155 Map-Request for geo-point: 156 EID= 157 Mapping system longest-match lookup returns: 158 EID= 159 RLOC= 161 If the package was not in San Francisco, the second mapping table 162 lookup would fail. 164 Another application is concentric rings of WiFi access-points. The 165 radius of each ring corresponds to the Wifi signal strength. An EID 166 could be located in any on the inner rings but possibly on the edge 167 of a ring. A WiFi access-point RLOC can be selected to encapsulate 168 packets to because it will have better signal to the current EID 169 location. And when there are intersecting circles, it can be 170 determined that when the EID is in the intersection of the circles, 171 it would be a good time to transition radios to closer APs or base 172 stations. 174 When assigning EIDs to vehicles [V2I], a Geo-Prefix could be used to 175 create a "reachability set" of Road-Side-Units (RSUs). So an ITR 176 could encapsulate to multiple RLOCs in the Geo-Prefix to try to 177 create connectivity to the vehicle while roaming. This makes use of 178 predictive RLOCs that can be used when the direction of the roaming 179 EID is known (a train track or single direction road, but not a 180 flight path of a plane). 182 5. Geo-Prefix and Geo-Point Encodings 184 When a Geo-Prefix or a Geo-Point are encoded in an EID-record, it is 185 encoded solely with the Geo-Coordinates LCAF Type format when VPNs 186 are not in use. When VPNs are used, the Geo-Coordinate LCAF Type is 187 encoded within an Instance-ID LCAF Type. 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | AFI = 16387 | Rsvd1 | Flags | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Type = 5 | Radius-high | 12 + n | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |N| Latitude Degrees | Minutes | Seconds | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |E| Longitude Degrees | Minutes | Seconds | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Radius-low | Altitude | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | AFI = x | Address ... | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 This draft proposes to change the "Rsvd2" field from [LCAF] to 206 "Radius-high" and take 8 bits from "Altitude" for Radius-low to make 207 up a 16-bit value. When "Radius" is 0 the Geo-Coordinate encoding is 208 a Geo-Point. When non-zero, it is the radius of the circle in 209 kilometers. The maximum value is 65535 kilometers which is almost 210 twice the distance of the earth's circumference. 212 The Altitude field in [LCAF] indicates that a value of 0x7fffffff is 213 set when there is no Altitude encoded. Since the width of the 214 Altitude field is shortened in this document, the value 0x7fffff is 215 set to indicate no Altitude is encoded. 217 6. Security Considerations 219 The use of Geo-Coordinates in any application must be considered 220 carefully to not violate and privacy concerns about physical 221 location. 223 7. IANA Considerations 225 At this time there are no specific requests for IANA. 227 8. References 229 8.1. Normative References 231 [GEO] Geodesy and Geophysics Department, DoD., "World Geodetic 232 System 1984", NIMA TR8350.2, January 2000, . 235 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 236 Address Format", draft-ietf-lisp-lcaf-12.txt (work in 237 progress). 239 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 240 DOI 10.17487/RFC1700, October 1994, 241 . 243 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 244 Locator/ID Separation Protocol (LISP)", RFC 6830, 245 DOI 10.17487/RFC6830, January 2013, 246 . 248 8.2. Informative References 250 [DIST-NAME] 251 Farinacci, D., "LISP Distinguished Name Encoding", draft- 252 farinacci-lisp-name-encoding-00.txt (work in progress). 254 [V2I] Jeong, J. and T. Oh, "Problem Statement for Vehicle-to- 255 Infrastructure Networking", draft-jeong-its-v2i-problem- 256 statement-00 (work in progress). 258 Appendix A. Acknowledgments 260 The author would like to thank the LISP WG for their review and 261 acceptance of this draft. 263 Appendix B. Document Change Log 265 [RFC Editor: Please delete this section on publication as RFC.] 267 B.1. Changes to draft-farinacci-lisp-geo--01.txt 269 o Posted October 2016. 271 o Clarify that the Geo-Coordinates LCAF type should be encoded 272 inside an Instance-ID LCAF type when VPNs are used. 274 o Indiate what the value of the Altitude field is when not included 275 in a message. Since this draft shortens the field, a new value is 276 specified in this draft for not conveying an Altitude value in a 277 message. 279 B.2. Changes to draft-farinacci-lisp-geo--00.txt 281 o Initial draft posted April 2016. 283 Author's Address 285 Dino Farinacci 286 lispers.net 287 San Jose, CA 288 USA 290 Email: farinacci@gmail.com