idnits 2.17.1 draft-barkai-lisp-nexagon-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 383 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 44 instances of too long lines in the document, the longest one being 8 characters in excess of 72. 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. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-lisp-rfc6833bis' is defined on line 305, but no explicit reference was found in the text == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-07 ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 LISP Working Group S. Barkai 2 Internet-Draft B. Frenandez-Ruiz 3 Intended status: Experimental O. Serfaty 4 Expires: September 4, 2019 Nexar Inc. 5 A. Rodriguez-Natal 6 F. Maino 7 Cisco Systems 8 A. Cabellos-Aparicio 9 Technical University of Catalonia 10 February 4 2019 12 Distributed Geo-Spatial LISP Blackboard for Automotive 13 draft-barkai-lisp-nexagon-00 15 Abstract 17 This document specifies the use of LISP Blackboard for distributed 18 Geo-Spatial Publish/Subscribe automotive applications. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 4, 2018. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3 57 4. Nexagon Publish Procedure . . . . . . . . . . . . . . . . . . 4 58 5. Nexagon Subscribe Procedure . . . . . . . . . . . . . . . . 5 59 6. XTR Sharding-Handover tunnel . . . . . . . . . . . . . . . . 7 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 (1) The Locator/ID Separation Protocol (LISP) [RFC6830] splits current IP 69 addresses in two different namespaces, Endpoint Identifiers (EIDs) and 70 Routing Locators (RLOCs). 71 LISP uses a map-and-encap approach that relies on (1) a Mapping System 72 (basically a distributed database) that stores and disseminates EID-RLOC 73 mappings and on (2) LISP tunnel routers (xTRs) that encapsulate and 74 decapsulate data packets based on the content of those mappings. 76 (2) H3 is a geospatial indexing system using a hexagonal grid that can be 77 (approximately) subdivided into finer and finer hexagonal grids, 78 combining the benefits of a hexagonal grid with hierarchical subdivisions. 79 H3 supports sixteen resolutions. Each finer resolution has cells with one 80 seventh the area of the coarser resolution. Hexagons cannot be perfectly 81 subdivided into seven hexagons, so the finer cells are only approximately 82 contained within a parent cell. Each cell is identified by a 64bit int. 84 (3) The Berkeley Deep Drive (BDD) Industry Consortium investigates state-of- 85 the-art technologies in computer vision and machine learning for automotive 86 applications. BDD based taxonomy of published automotive scene classification. 88 These standards are combined to create an in-network key-value blackboard - 89 reflecting the state of each 1sqm hexagon tile of road. The lisp network maps 90 traffic form vehicle endpoint IP identifiers (EID) to the routing location 91 (RLOC) of h3 hexagon identifier (HID). 93 Th lisp network blackboard bridges the time-space gap between vision & sensory 94 (publishers) - and - driving apps/smart-infrastructure (subscribers). 95 Drivers (EID) communicate with blackboard tiles (HID), EID<=> RLOC <=> HID, 96 small tiles to publish, large tiles to subscribe to regional information. 98 One of of the key use-cases is providing drivers with 20-30 seconds preemptive 99 heads-up on potential hazards and obstacles; across traffic, around the block, 100 beyond turns and curvatures, in a nutshell beyond sensory line-of-site. 102 (1) LISP blackboard keys are 64bit H3 IDs referring to ~1sqm H3 level 13 103 (2) LISP blackboard values are 64bit compiled-states of each H3 road-tile 104 (3) LISP blackboard pub-sub regions are at H3 level-9 containing l13 tiles 105 (4) LISP Blackboard is sharded to scale state-updates and edge propagation 106 (5) Edge LISP XTRs use the H3 IDs to map publish-subscribe to right shard 107 (6) Edge XTRs are also used to replicate bulk state updates to clients 108 (7) Bulk updates Multicast-replication can use native access multicast 110 / \ / \ / \ H3-level9 111 | H3-l9 | | H3-l9 | | | . 112 --- \ ___ / --- --- \_____/ --- --- \____/ --- . 113 v v v v . 114 v v \ | / v v . 115 v ((((|)))) >>> EDGE XTR <<< ((((|)))) . 116 /|\ /|\ . 117 RAN RAN . 118 v v v v H3-level13 119 v v v v 120 ............/\/\/\/\/\/\/\/\/\/ \/ \/\/\/ \/\/\/\..<> \/\/\/\____/\____/\/\/\____/.......... 124 2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. Deployment Assumptions 132 The specification described in this document makes the following 133 deployment assumptions: 135 (1) A unique 64-bit H3 Hex-Tile identifier is associated with each lang-lat 136 (2) Clients (Publisher/Subscriber) and network (Blackboard) share this index 137 (3) A 64-bit automotive BDD state value is associated with each hexagon tile 138 (4) Hexagon state is combined by 16 fields of 4-bit (nibble) up-to 16 enums 140 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 141 0123012301230123012301230123012301230123012301230123012301230123 143 (5) The following fields describe state information for a given tile 145 Field 0x describes the "freshness" of the state eg last published { 146 0x: less than 10Sec 147 1x: less than 20Sec 148 2x: less than 40Sec 149 3x: less than 1min 150 4x: less than 2min 151 5x: less than 5min 152 6x: less than 15min 153 7x: less than 30min 154 9x: less than 1hour 155 Ax: less than 2hours 156 Bx: less than 8hours 157 Cx: less than 24hours 158 Dx: less than 1week 159 Ex: less than 1month 160 Fx: more than 1month 161 } 163 field 1x: persistent weather or structural { 164 0x - null 165 1x - pothole 166 2x - speed-bump 167 3x - icy 168 4x - flooded 169 5x - snow-cover 170 6x - snow-deep 171 7x - construction cone 172 8x - curve 173 } 175 field 2x: transient or moving obstruction { 176 0x - null 177 1x - pedestrian 178 2x - bike 179 3x - stopped car / truck 180 4x - moving car / truck 181 5x - first responder vehicle 182 6x - sudden slowdown 183 7x - oversized-vehicle 184 } 186 field 3x: traffic-light timer countdown { 187 0x - green now 188 1x - 1 seconds to green 189 2x - 2 seconds to green 190 3x - 3 seconds to green 191 4x - 4 seconds to green 192 5x - 5 seconds to green 193 6x - 6 seconds to green 194 7x - 7 seconds to green 195 8x - 8 seconds to green 196 9x - 9 seconds to green 197 Ax - 10 seconds or less 198 Bx - 20 seconds or less 199 Cx - 30 seconds or less 200 Dx - 40 seconds or less 201 Ex - 50 seconds or less 202 Fx - minute or more left 203 } 205 field 4x: impacted tile from neighboring { 206 0x - not impacted 207 1x - light yellow 208 2x - yellow 209 3x - light orange 210 4x - orange 211 5x - light red 212 6x - red 213 7x - light blue 214 8x - blue 215 } 217 field 5x: incidents { 218 0x - clear 219 1x - light collision (fender bender) 220 2x - hard collision 221 3x - collision with casualty 222 4x - recent collision residues 223 5x - hard break 224 6x - sharp cornering 225 } 226 field 6x - compiled tile safety rating { 228 } 229 field 7x - reserved 230 field 8x - reserved 231 field 9x - reserved 232 field Ax - reserved 233 field Bx - reserved 234 field Cx - reserved 235 field Dx - reserved 236 field Ex - reserved 237 field Fx - reserved 239 (7) Publish packet contains 1 key-value tuple: 241 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 242 | H3 Hexagon ID Key | 243 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 244 | H3 Hexagon State-Value | 245 |---------------------------------------------------------------| 247 (8) Any number of fields published in a state can be set to a value 248 (9) If a field is not being addressed by than it should be set to 0x-null 249 (10) Subscribe packets are the same as publish with the entire state set null 251 4. Nexagon Publish-Procedure 253 (1) Publisher observation 254 (2) Snap to hex accuracy bar 255 (3) Compiling a Publish Packet 256 (4) Publish Packet Source IP 257 (5) Publish Packet Destination IP 259 5. Nexagon Subscribe Procedure 261 (1) Subscribe to zone hierarchy 262 (2) Subscribe Packet 263 (3) Zone state update packet of upto 100 hexagon tiles 265 1 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 266 | H3 Hexagon ID Key | 267 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 268 | H3 Hexagon State-Value | 269 |---------------------------------------------------------------| 270 . . 271 . . 272 . . 273 . . 274 100|-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 275 | H3 Hexagon ID Key | 276 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 277 | H3 Hexagon State-Value | 278 |---------------------------------------------------------------| 280 6. XTR Sharding and Handover to blackboard tunnels 282 (1) Map-Resolve hexagon ID to shard location 283 (2) Multicast replication to subscribed EIDs 285 7. Security Considerations 287 The way to provide a security association between the ITRs and the 288 Map-Servers must be evaluated according to the size of the 289 deployment. For small deployments, it is possible to have a shared 290 key (or set of keys) between the ITRs and the Map-Servers. For 291 larger and Internet-scale deployments, scalability is a concern and 292 further study is needed. 294 8. Acknowledgments 296 This work is partly funded by the ANR LISP-Lab project #ANR- 297 13-INFR-009 (https://lisplab.lip6.fr). 299 9. IANA Considerations 301 This document makes no request to IANA. 303 10. Normative References 305 [I-D.ietf-lisp-rfc6833bis] 306 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 307 "Locator/ID Separation Protocol (LISP) Control-Plane", 308 draft-ietf-lisp-rfc6833bis-07 (work in progress), December 309 2017. 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 317 Locator/ID Separation Protocol (LISP)", RFC 6830, 318 DOI 10.17487/RFC6830, January 2013, 319 . 321 Authors' Addresses 323 Sharon Barkai 324 Nexar 325 CA 326 USA 328 Email: sharon.barkai@getnexar.com 330 Bruno Fernandez-Ruiz 331 Nexar 332 London 333 UK 335 Email: b@getnexar.com 337 Ohad Serfaty 338 Nexar 339 Israel 341 Email: ohad@getnexar.com 343 Alberto Rodriguez-Natal 344 Cisco Systems 345 170 Tasman Drive 346 San Jose, CA 347 USA 349 Email: natal@cisco.com 351 Fabio Maino 352 Cisco Systems 353 170 Tasman Drive 354 San Jose, CA 355 USA 357 Email: fmaino@cisco.com 359 Albert Cabellos-Aparicio 360 Technical University of Catalonia 361 Barcelona 362 Spain 364 Email: acabello@ac.upc.edu