idnits 2.17.1 draft-ietf-lisp-nexagon-01.txt: -(10): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 987 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 205 instances of too long lines in the document, the longest one being 54 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 109 has weird spacing: '...receive consi...' == Line 194 has weird spacing: '...through cloud...' == Line 611 has weird spacing: '...unneled and i...' == Line 843 has weird spacing: '...vehicle on ti...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 3, 2020) is 1453 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-lisp-rfc6833bis' is defined on line 854, but no explicit reference was found in the text == Unused Reference: 'RFC8378' is defined on line 870, 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 (~~), 11 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. Fernandez-Ruiz 3 Intended status: Informational S. ZionB 4 Expires: September 3, 2020 R. Tamir 5 Nexar Inc. 6 A. Rodriguez-Natal 7 F. Maino 8 Cisco Systems 9 A. Cabellos-Aparicio 10 J. Paillissé Vilanova 11 Technical University of Catalonia 12 D. Farinacci 13 lispers.net 14 May 3, 2020 16 Network-Hexagons: H3-LISP GeoState & Mobility Network 17 draft-ietf-lisp-nexagon-01 19 Abstract 21 This document specifies use of H3 and LISP to reflect status of public roads: 22 - Enabling tile by tile, indexed annotation of streets & curbs in real time 23 - Sharing: hazards, blockages, parking, weather, maintenance, inventory.. 24 - Between MobilityClients who produce and consume geo-state information 25 - Using geo-spatial IP channels for the current state of the physical world 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 4, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 64 4. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 4 65 5. Mobility Clients Network Services . . . . . . . . . . . . . . 4 66 6. Mobility Unicast-Multicast . . . . . . . . . . . . . . . . . 5 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 (1) The Locator/ID Separation Protocol (LISP) [RFC6830] splits current IP 76 addresses in two different namespaces, Endpoint Identifiers (EIDs) and 77 Routing Locators (RLOCs). LISP uses a map-and-encap approach that relies on 78 (1) a Mapping System (distributed database) that stores and disseminates 79 EID-RLOC mappings and on (2) LISP tunnel routers (xTRs) that encapsulate 80 and decapsulate data packets based on the content of those mappings. 82 (2) H3 is a geospatial indexing system using a hexagonal grid that can be 83 (approximately) subdivided into finer and finer hexagonal grids, 84 combining the benefits of a hexagonal grid with hierarchical subdivisions. 85 H3 supports sixteen resolutions. Each finer resolution has cells with one 86 seventh the area of the coarser resolution. Hexagons cannot be perfectly 87 subdivided into seven hexagons, so the finer cells are only approximately 88 contained within a parent cell. Each cell is identified by a 64bit HID. 90 (3) The Berkeley Deep Drive (BDD) Industry Consortium investigates state-of- 91 the-art technologies in computer vision and machine learning for automotive 92 applications, and, for taxonomy of published automotive scene classification. 94 These standards are combined to create an in-network state which reflects the 95 condition of each hexagonal tile (~1sqm) in every road. The lisp network maps & 96 encapsulates traffic between MobilityClient endpoint identifiers (EID), and 97 addressable tile-objects (HID=>EID). objects are aggregated by H3Service EIDs. 99 The H3-LISP mobility network bridges timing and location gaps between the 100 production and consumption of information by MobilityClients: 101 o vision, sensory, LIADR, AI applications -- information producers 102 o driving-apps, map-apps, command & control -- information consumers 104 This is achieved by putting the physical world on a shared addressable 105 geo-state grid at the edge. The tile by tile, geo-state, mobility network 106 solves key issues in vehicle to vehicle networking, where observed hazards are 107 relayed without clear, reliable convergence. Given a situation observable by 108 some end-points, it is unclear if the relevant end-points which need to know 109 will receive consistent, conflicting, multiple, or no indications whatsoever. 111 For example, when a vehicle experiences a sudden highway slow-down,"sees" many 112 brake lights or "feels" accelerometer, there is no clear way for it to share 113 this annotation with vehicles 20-30sec away to prevent a potential pile-up. 114 Or, when a vehicle crosses an intersection, observing opposite-lane 115 obstruction, construction, double-park, commercial loading or un-loading, 116 garbage truck, or stopped school-bus, there is no clear way for it to alert 117 vehicles approaching that situation as it drives away. 119 Geo-state indirection also helps communicating advanced machine vision and/or 120 radar annotations. These are constantly evolving technologies, however, 121 communicating the road enumerations they produce, using peer-to-peer protocols, 122 poses a significant interoperability challenge. It is hard to test each new 123 annotation of any sensor or OEM vendor with any other driving application. 125 These peer-to-peer limitations are inherit yet unnecessary, as in most road 126 situations vehicles are not really proper peers. They just happen to be in the 127 same place at the same time. H3-LISP mobility network solves the limitations 128 of direct vehicle-to-vehicle communication by anchoring per geo-tile: 129 timing, security, privacy, interoperability. Anchoring is achieved by 130 MobilityClients communicating through in-network addressable geo-states. 131 Addressable tiles are aggregated and maintained by LISP H3ServiceEIDs. 133 MobilityClients can provide drivers with heads-up alerts on hazards and obstacles 134 beyond the line of sight of both the drivers and in-car sensors: over traffic, 135 around blocks, far-side junction, beyond turns, and surface curvatures. 136 This highlights the importance of networks in providing road safety. 138 To summarize the H3-LISP solution outline: 140 (1) MicroPartition: 64bit indexed geo-spatial H3.r15 road-tiles 141 (2) EnumState: 64bit state values compile tile condition representation 142 (3) Aggregation: H3.r9 H3ServiceEID group individual H3.r15 road-tiles 143 (4) Channels: H3ServiceEIDs function as multicast state update channels 144 (5) Scale: H3ServiceEIDs distributed for in-network for latency-throughput 145 (6) Mapped Overlay: tunneled-network routes the mobility-network traffic 146 (7) Signal-free: tunneled overlay is used to map-register for mcast channels 147 (8) Aggregation: tunnels used between MobilityClients/H3ServiceEIDs <> edge 148 (9) Access: ClientXTRs/ServerXTRs tunnel traffic to-from the LISP EdgeRTRs 149 (10) Control: EdgeRTRs register-resolve H3ServiceEIDs and mcast subscription 151 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 152 | H3 Hexagon ID Key | 153 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 154 | H3 Hexagon State-Value | 155 |---------------------------------------------------------------| 157 ___ ___ 158 H3ServiceEIDs ___ / \ H3ServiceEIDs ___ / \ 159 ___ / | H3.r9 | ___ / | H3.r9 | 160 / | H3.r9 \ ___ / / | H3.r9 \ ___ / 161 | H3.r9 \ ___ / sXTR | H3.r9 \ ___ / sXTR 162 \ ___ / sXTR | \ ___ / sXTR | 163 sXTR | | sXTR | | 164 | | | | | | 165 | | | | | | 166 + - - + - - EdgeRTR EdgeRTR - + - + - - + 167 || ( ( (( || 168 ( ) 169 ( Network Hexagons ) 170 ( H3-LISP ) 171 ( Mobility Network ) 172 (( ) 173 || (( (()) () || 174 || || 175 = = = = = = = = = = = = = = 176 || || 177 EdgeRTR EdgeRTR 178 .. .. .. .. 179 .. .. .. .. 180 ((((|)))) ((((|)))) ((((|)))) ((((|)))) 181 /|\ RAN /|\ /|\ RAN /|\ 182 .. .. 183 .. .. 184 .. Road tiled by 1 sqm H3.r15 ID-Ed Geo-States .. 185 .. .. 186 .. ___ ___ ___ .. 187 .. .............. / \/ \/ \ << cXTR::MobilityClientB 188 .. - - - - - - - H3.r15 H3.r15 H3.r15 - - - - - - - 189 MobilityClientA::cXTR >> \ ___ /\ ___ /\ ___ /.......... 191 - MobilityClientA has seen MobilityClientB near future, and, vice versa 192 - Clients share information using addressable shared-state routed by LISP Edge 193 - ClientXTR (cXTR): tunnel encapsulation through access network to LISP Edge 194 - ServerXTR (sXTR): tunnel encapsulation through cloud network to LISP Edge 195 - The H3-LISP Mobility overlay starts in the cXTR and terminates in the sXTR 196 - The updates are routed to the appropriate tile geo-state by the LISP network 197 - EdgeRTRs perform multicast replication to edges and then native or to cXTRs 198 - Clients receive tile-by-tile geo-state updates via the multicast channels 200 Each H3.r9 hexagon is an EID Service with corresponding H3 hexagon ID. 201 Bound to that service is a LISP xTR, called a ServerXTR, specified to deliver 202 encapsulated packets to and from the H3ServiceEID and LISP Edge. EdgeRTRs are 203 used to re-tunnel packets from MobilityClients to H3ServiceEIDs. Each 204 H3ServiceEID is also a multicast source for updating MobilityClients 205 on the state of the H3.r15 tiles aggregated by the H3ServiceEID. 207 2. Requirements Language 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in [RFC2119]. 213 3. Definition of Terms 215 H3ServiceEID: Is an addressable aggregation of H3.r15 state-tiles. It is a 216 designated source for physical world reported annotations, and an (s,g) 217 source of multicast public-safety update channels. H3ServiceEID is itself 218 an H3 hexagon, large enough to provide geo-spatial conditions context, but 219 not too large as to over-burden (battery powered, cellular connected) 220 subscribers with too much information. For Mobility Network it is H3.r9. 221 It has a light-weight LISP protocol stack to tunnel packets aka ServerXTR. 222 The EID is an IPv6 EID that contains the H3 64-bit address numbering 223 scheme. See IANA consideration for details. 225 ServerXTR: Is a light-weight LISP protocol stack implementation that co-exists 226 with H3ServiceEID process. When the server roams, the xTR roams with it. 227 The ServerXTR encapsulates and decapsulates packets to/from EdgeRTRs. 229 MobilityClient: Is a roaming application that may be resident as part of an 230 automobile, as part of a navigation application, part of municipal, state, 231 of federal government command and control application, or part of live 232 street view consumer type of application. It has a light-weight LISP 233 protocol stack to tunnel packets aka ClientXTR. 235 MobilityClient EID: Is the IPv6 EID used by the Mobility Client applications 236 to source packets. The destination of such packets are only H3ServiceEIDs. 237 The EID format is opaque and is assigned as part of the MobilityClient 238 network-as-a-service (NaaS) authorization. 240 ClientXTR: Is the light-weight LISP protocol stack implementation that is 241 co-located with the Mobility Client application. It encapsulates packets 242 sourced by applications to EdgeRTRs and decapsulates packets from EdgeRTRs. 244 EdgeRTR: Is the core scale and structure of the LISP mobility network. 245 EdgeRTRs proxy H3ServiceEIDs and MobilityClient H3ServiceEID channel 246 registration. EdgeRTRs aggregate MobilityClients and H3Services using 247 tunnels to facilitate hosting-providers and mobile-hosting flexibility - 248 for accessing the nexagon mobility network. 249 EdgeRTRs decapsulate packets from ClientXTRs, ServerXTRs and re-encapsulates 250 packets to the clients and servers tunnels. EdgeRTRs glean H3ServiceEIDs 251 and glean MobilityClient EIDs when it decapsulates packets. EdgeRTRs store 252 H3ServiceEIDs and their own RLOC of where the H3ServiceEID is currently 253 reachable from in the map-cache. These mappings are registered to the LISP 254 mapping system so other EdgeRTRs know where to encapsulate for such EIDs. 255 EdgeRTRs do not register MobilityClients' EIDs at the mapping service as 256 these are temporary-renewed while using the mobility network. Enterprises 257 may provide their own client facing EdgeRTRs to mask their clients geo- 258 whereabouts while using the mobility network. 260 4. Deployment Assumptions 262 The specification described in this document makes the following 263 deployment assumptions: 265 (1) Unique 64-bit HID is associated with each H3 geo-spatial tile 266 (2) MobilityClients and H3ServiceEIDs share this well known index 267 (3) 64-bit BDD state value is associated with each H3-indexed tile 268 (4) Tile state is compiled 16 fields of 4-bits, or max 16 enums 270 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 271 0123012301230123012301230123012301230123012301230123012301230123 273 Subscription of MobilityClients to the mobility network is constantly renewed 274 while on the move and is not intended as a means of basic connectivity. This 275 is why MobilityClients use DNS/AAA to obtain temporary EIDs and EdgeRTRs 276 and why they use (LISP) data-plane tunnels to communicate using their 277 temporary EIDs with the dynamically assigned EdgeRTRs. 279 MobilityClient are otherwise unaware of the LISP network mechanism or mapping 280 system and simply regard the data-plane tunnels as an application-specific 281 virtual private network (VPN) that supports IPv6 EID addressable geo-state to 282 publish (Ucast), Subscribe (Mcast) H3Services. 284 In order to get access to the MobilityVPN, MobilityClients first authenticate 285 with the MobilityVPN AAA Server. DIAMETER based AAA is typically done at the 286 provider edge (PE) by edge gateways. However, the typical case involves several 287 types of customer equipment connected by wireline, or by wireless to a 288 specific service provider. The Mobility VPN, on the other hand, 289 potentially overlays a number of wireless networks and cloud-edge 290 providers. It also involves dozens of Car-OEM, Driving-Applications, 291 Smart-infrastructure vendors. This is why we require clients to first go 292 through AAA in order to get both a MobilityClientEID and EdgeRTR gateway RLOC 293 opened. 295 ClientXTR performs the following steps in order to use the mobility network: 296 1) obtain the address of the mobility network AAA server using DNS 297 2) obtain MobilityClientEID and EdgeRTR(s) from AAA server using DIAMETER 298 3) renew authorization from AAA while using the mobility network T1 minutes 300 MobilityClient Domain Name Server DIAMETER AAA Mobility EdgeRTR 301 | | | | 302 | nslookup nexagon | | | 303 |------------------->| | | 304 |<-------------------| | | 305 | Mobility AAA IP | | | 306 | | | | 307 | AAR(AVP:IMSI/User/Password/Toyota) | | 308 |--------------------------------------->| | 309 | | | ACR(AVP ClientEID)| 310 | | |------------------>| 311 | | |<------------------| 312 | | | ACA(AVP ClientEID)| 313 | AAA (Client::EID,EdgeRTR::RLOC) | | 314 |<---------------------------------------| | 315 | | | | 316 . . 317 . . 318 . . 319 | Publish IPv6 H3ServiceEID, Subscribe MLDv2 H3ServiceEID | . 320 |----------------------------------------------------------->| 321 . . 322 . . 323 |<-----------------------------------------------------------| 324 | Signal freeing multicast Updates from H3ServiceEIDs | 325 . . 326 . . 327 . . 328 | | | | 329 | AAR(Interim) | | 330 |--------------------------------------->| ACR (Interim) | 331 | | |------------------>| 332 | | |<------------------| 333 | | | ACA (Interim) | 334 |<---------------------------------------| | 335 | AAA (Interim) | | 337 Using this network login and re-login method we ensure that: 338 - the MobilityClientEIDs serve as credentials with the specific EdgeRTRs 339 - EdgeRTRs are not tightly coupled to H3.r9 areas for privacy/load-balance 340 - Mobility Clients do not need to update EdgeRTRs while roaming in an area 342 The same EdgeRTR may serve several H3.r9 areas for smooth ride continuity, 343 and, several EdgeRTRs may load balance an H3.r9 area with high density of 344 originating MobilityClient rides. When a MobilityClient ClientXTR is homed 345 to EdgeRTR, it is able to communicate with H3ServiceEIDs. 347 5. Mobility Clients Network Services 349 The mobility network functions as a standard LISP VPN overlay. 350 The overlay delivers unicast and multicast packets across: 351 - multiple access-networks and radio-access technologies. 352 - multiple cloud-edge providers, public, private, hybrid. 354 We use data-plane XTRs in the stack of each mobility client and server. 355 ClientXTRs and ServerXTRs are homed to one or more EdgeRTRs at the LISP edge. 356 This structure allows for MobilityClients to "show up" at any time, 357 behind any network provider in a given mobility network administrative 358 domain, and for any H3ServiceEID to be instantiated, moved, or 359 failed-over to any rack in any cloud-provider. The LISP overlay enables 360 these roaming mobility network elements to communicate un-interrupted. 361 This quality is insured by the LISP RFCs. The determination of identities for 362 MobilityClients to always refer to the correct H3ServiceEID is insured by H3 363 geo-spatial HIDs. 365 There are two options for how we associate ClientXTRs with LISP EdgeRTRs: 367 I. Semi-random load-balancing by DNS/AAA 369 In this option we assume that in a given metro edge a pool of EdgeRTRs can 370 distribute the Mobility Clients load randomly between them and that EdgeRTRs 371 are topologically more or less equivalent. Each RTR uses LISP to tunnel 372 traffic to and from other EdgeRTRs for MobilityClient with H3Service exchanges. 373 MobilityClients can (multi) home to EdgeRTRsRTRs throughout while moving. 375 II. Topological by any-cast 377 In this option we align an EdgeRTR with topological aggregation like in the 378 Evolved Packet Core (EPC) solution. Mobility Clients currently roaming in an 379 area home to that RTR and so is the H3 Server. There is only one hop across 380 the edge overlay between clients and servers and mcast replication is more 381 focused, but clients need to keep re-homing as they move. 383 To summarize the H3LISP mobility network layout: 385 (1) Mobility-Clients traffic is tunneled via data-plane ClientXTRs 386 ClientXTRs are (multi) homed to EdgeRTR(s) 387 (2) H3ServiceEID traffic is tunneled via data-plane ServerXTR 388 ServerXTRs are (multi) homed to EdgeRTR(s) 389 (3) EdgeRTRs use mapping service to resolve Ucast HIDs to RTR RLOCs 390 EdgeRTRs also register to (Source, Group) H3ServiceEID multicasts 392 MobilityClients <> ClientXTR EdgeRTR v 393 v 394 v << Map-Assisted Mobility-Network Overlay << v 395 v 396 >> EdgeRTR ServerXTR <> H3ServiceEID 398 6. Mobility Unicast and Multicast 400 Which ever way a ClientXTR is homed to an Edge RTR an authenticated 401 MobilityClient EID can send: [64bitH3.15ID :: 64bitState] annotation to the 402 H3.r9 H3ServiceEID. The H3.r9 IP HID can be calculated by clients 403 algorithmically form the H3.15 localized snapped-to-tile annotation. 405 The ClientXTR encapsulates MobilityClient EID and H3ServiceEID in a packet 406 sourced from the ClientXTR, destined to the EdgeRTR RLOC IP, Lisp port. 407 EdgeRTRs then re-encapsulate annotation packets either to remote EdgeRTR 408 (optionI) or to homed H3ServiceEID ServerXTR (option2). 409 The remote EdgeRTR aggregating H3ServiceEIDs re-encapsulates MobilityClient 410 EID to ServerXTR and from there to the H3ServiceEID. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 415 |Version| Traffic Class | Flow Label | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 417 | Payload Length | Next Header | Hop Limit | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 419 | | | 420 + + | 421 | | | 422 + Source MobilityClientEID + | 423 | | IPv6 424 + + | 425 | | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 427 | | | 428 + + | 429 | | | 430 + Dest H3ServiceEID + | 431 | | | 432 + + | 433 | | / 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Source Port = xxxx | Dest Port = xxxx | \ 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 437 | UDP Length | UDP Checksum | / 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 439 | Type |gzip | Reserved | Pair Count = X| Nexgon Header 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 441 | | 442 + 64 Bit H3-R15 ID + 443 | | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | | 446 + 64 Bit State + 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 + 64 Bit H3-R15 ID + 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 + 64 Bit State + 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 To Summarize Unicast: 460 (1) MobilityClients can send annotation state localized an H3.r15 tile 461 These annotations are sent to an H3.r9 mobility H3ServiceEIDs 462 (2) MobilityClient EID and H3ServiceEID HID are encapsulated: 463 XTR <> RTR <> RTR <> XTR 464 * RTRs can map-resolve re-tunnel HIDs 465 (3) RTRs re-encapsulate original source-dest to ServerXTRs 466 ServerXTRs decapsulate packets to H3ServiceEID 468 Each H3.r9 Server is used by clients to update H3.r15 tile state is also an IP 469 Multicast channel Source used to update subscribers on the aggregate state of 470 the H3.r15 tiles in the H3.r9 Server. 472 We use rfc8378 signal free multicast to implement mcast channels in the 473 overlay. The mobility network has many channels and relatively few 474 subscribers per each. MobilityClients driving through or subscribing to a 475 a H3.r9 area can explicitly issue an rfc4604 MLDv2 in-order to subscribe, or, 476 may be subscribed implicitly by the EdgeRTR gleaning to ucast HID dest. 478 The advantage of explicit client MLDv2 registration trigger to rfc8378 is 479 that the clients manage their own mobility mcast hand-over according to their 480 location-direction moment vectors, and that it allows for otherwise silent, or, 481 non annotating clients. The advantage of EdgeRTR implicit registration is 482 less signaling required. 484 MLDv2 signaling messages are encapsulated between the ClientXTR and the LISP 485 EdgeRTR, therefore there is no requirement for the underlying network to 486 support native multicast. If native access multicast is supported (for example 487 native 5G multicast), then MobilityClient registration to H3ServiceEID 488 safety channels may be integrated to it, in which case the evolved-packet-core 489 (EPC) element supporting it (eNB) will use this standard to register with the 490 appropriate H3.r9 channels in its area. 492 Multicast update packets are of the following structure: 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 497 |Version| Traffic Class | Flow Label | | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 499 | Payload Length | Next Header | Hop Limit | | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 501 | | | 502 + + | 503 | | | 504 + Source H3-R9 EID Address + | 505 | | IPv6 506 + + | 507 | | | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 509 | | | 510 + + | 511 | | | 512 + Group Address + | 513 | | | 514 + + | 515 | | / 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Source Port = xxxx | Dest Port = xxxx | \ 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 519 | UDP Length | UDP Checksum | / 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 521 | | Nexagons Header 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 523 ~ Nexagons Payload ~ 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Outer headers = 40 (IPv6) + 8 (UDP) + 8 (LISP) = 56 527 Inner headers = 40 (IPv6) + 8 (UDP) + 4 (Nexagon Header) = 52 529 1500 (MTU) - 56 - 52 = 1392 bytes of effective payload 531 Type 1:key-value, key-value.. 1392 / (8 + 8) = 87 pairs 532 Type 2:value, key,key,key.. (1392 - 8) / 8 = 173 H3-R15 IDs 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 537 | Type = 1 |gzip | Reserved | Pair Count = X| Nexagon Header 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 539 | | 540 + 64 Bit H3-R15 ID + 541 | | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | | 544 + 64 Bit State + 545 | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | | 548 + 64 Bit H3-R15 ID + 549 | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | | 552 + 64 Bit State + 553 | | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 559 | Type = 2 |gzip | Reserved |H3R15 Count = X| Nexagon Header 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 561 | | 562 + 64 Bit State + 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | | 566 + 64 Bit H3-R15 ID + 567 | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 + 64 Bit H3-R15 ID + 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | | 574 + 64 Bit H3-R15 ID + 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 ` The remote EdgeRTRs homing MobilityClients in-turn replicate the packet to the 579 MobilityClients registered with them. 581 We expect an average of 600 H3.r15 tiles of the full 7^6 (~100K) possible in 582 H3.r9 to be part of any road. The H3.r9 server can transmit the status of all 583 600 or just those with meaningful state based on update SLA and policy. 585 To Summarize: 587 (1) H3LISP Clients tune to H3.r9 mobility updates using rfc8378 588 H3LISP Client issue MLDv2 registration to H3.r9 HIDs 589 ClientXTRs encapsulate MLDv2 to EdgeRTRs who register (s,g) 591 (2) ServerXTRs encapsulate updates to EdgeRTRs who map-resolve (s,g) RLOCs 592 EdgeRTRs replicate mobility update and tunnel to registered EdgeRTRs 593 Remote EdgeRTRs replicate updates to registered ClientXTRs 595 7. Security Considerations 597 The nexagon layer3 v2v/v2i/c&c network is inherently more secure and private 598 then alternatives because of the indirection. No car or infrastructure element 599 ever communicates directly with MobilityClients. All information is conveyed 600 using shared / addressable geo-state. MobilityClients are supposed to receive 601 information only from the network as a trusted broker without indication as 602 to the origin of the information. This is an important step towards better 603 privacy, security, extendability, and interoperability. 605 In order to be able to use the nexagon mobility network for a given period, 606 the mobility clients go through a DNS/AAA stage by which they obtain their 607 clientEID identifiers-credentials and the RLOCs of EdgeRTRs they may use as 608 gateways to the network. This MobilityClient <> EdgeRTR is the most sensitive 609 interface in the network as far as privacy-security. 611 The traffic on the MobilityClient<>EdgeRTR interface is tunneled and its UDP 612 content may be encrypted, still, the EdgeRTR will know based on the LISP 613 headers alone the MobilityClient RLOC and H3-R9 (~0.1sqkm) geo-spatial area 614 a given client publishes in or subscribes to. 616 For this reason we envision the ability of enterprise or groups of users to 617 "bring their own" EdgeRTRs. BYO-RTR masks individual clients' IP-RLOC to 618 H3-R9 association and is pre-provisioned to be able to use the mapping system 619 and be on a white-list of EdgeRTRs aggregating H3ServiceEIDs. 621 Beyond this sensitive hop, the mapping system does not hold MobilityClientEIDs 622 and remote EdgeRTRs are only aware of MobilityClient ephemeral EIDs not their 623 actual IP RLOC or any other mobile-device identifiers. EdgeRTRs register in the 624 mapping (s,g) H3-R9 multicast groups, but which clients reside beyond which 625 EdgeRTR is not in the mapping system. The H3ServiceEIDs them selves of-course 626 decrypt and parse actual H3-R15 annotations, they also consider during this the 627 MobilityClientEID credentials to avoid "fake-news", but again these are only 628 temporary EIDs allocated to clients in-order to be able to use the mobility 629 network and not for their basic communications. 631 8. Acknowledgments 633 This work is partly funded by the ANR LISP-Lab project #ANR- 634 13-INFR-009 (https://lisplab.lip6.fr). 636 9. IANA Considerations 638 I. Formal H3 to IPv6 EID mapping 640 II. State enum fields of H3 tiles: 642 Field 0x: Traffic Direction { 643 0x - null 644 1x - Lane North 645 2x - Lane North + 30 646 3x - Lane North + 60 647 4x - Lane North + 90 648 5x - Lane North + 120 649 6x - Lane North + 150 650 7x - Lane North + 180 651 8x - Lane North + 210 652 9x - Lane North + 240 653 Ax - Lane North + 270 654 Bx - Lane North + 300 655 Cx - Lane North + 330 656 Dx - junction 657 Ex - shoulder 658 Fx - sidewalk 659 } 661 field 1x: Persistent or Structural { 662 0x - null 663 1x - pothole light 664 2x - pothole severe 665 3x - speed-bump low 666 4x - speed-bump high 667 5x - icy 668 6x - flooded 669 7x - snow-cover 670 8x - snow-deep 671 9x - construction cone 672 Ax - gravel 673 Bx - choppy 674 Cx - blind-curve 675 Dx - steep-slope 676 Ex - low-bridge 677 } 679 field 2x: Transient Condition { 680 0x - null 681 1x - pedestrian 682 2x - bike scooter 683 3x - stopped car / truck 684 4x - moving car / truck 685 5x - first responder vehicle 686 6x - sudden slowdown 687 7x - oversized over-height vehicle 688 8x - red-light-breach 689 9x - light collision (fender bender) 690 Ax - hard collision / casualty 691 Bx - collision course car/structure 692 Cx - recent collision residues 693 Dx - hard brake 694 Ex - sharp cornering 695 Fx - freeing-parking 696 } 698 field 3x: Traffic-light Cycle { 699 0x - null 700 1x - 1 seconds to green 701 2x - 2 seconds to green 702 3x - 3 seconds to green 703 4x - 4 seconds to green 704 5x - 5 seconds to green 705 6x - 6 seconds to green 706 7x - 7 seconds to green 707 8x - 8 seconds to green 708 9x - 9 seconds to green 709 Ax - 10 seconds or less 710 Bx - 20 seconds or less 711 Cx - 30 seconds or less 712 Dx - 60 seconds or less 713 Ex - green now 714 Fx - red now 715 } 717 field 4x: Impacted Tile from Neighboring { 718 0x - null 719 1x - epicenter 720 2x - light yellow 721 3x - yellow 722 4x - light orange 723 5x - orange 724 6x - light red 725 7x - red 726 8x - light blue 727 9x - blue 728 Ax - green 729 Bx - light green 730 } 732 field 5x: Transient, Cycle, Impacted, Valid for Next{ 733 0x - null 734 1x - 1sec 735 2x - 5sec 736 3x - 10sec 737 4x - 20sec 738 5x - 40sec 739 6x - 60sec 740 7x - 2min 741 8x - 3min 742 9x - 4min 743 Ax - 5min 744 Bx - 10min 745 Cx - 15min 746 Dx - 30min 747 Ex - 60min 748 Fx - 24hours 749 } 751 field 6x: LaneRightsSigns { 752 0x - null 753 1x - yield 754 2x - speedLimit 755 3x - straightOnly 756 4x - noStraight 757 5x - rightOnly 758 6x - noRight 759 7x - rightStraight 760 8x - leftOnly 761 9x - leftStraight 762 Ax - noLeft 763 Bx - noUTurn 764 Cx - noLeftU 765 Dx - bikeLane 766 Ex - HOVLane 767 Fx - Stop 768 } 770 field 7x: MovementSigns { 771 0x - null 772 1x - keepRight 773 2x - keepLeft 774 3x - stayInLane 775 4x - doNotEnter 776 5x - noTrucks 777 6x - noBikes 778 7x - noPeds 779 8x - oneWay 780 9x - parking 781 Ax - noParking 782 Bx - noStandaing 783 Cx - noPassing 784 Dx - loadingZone 785 Ex - railCross 786 Fx - schoolZone 787 } 789 field 8x: CurvesIntersectSigns { 790 0x - null 791 1x - turnsLeft 792 2x - turnsRight 793 3x - curvesLeft 794 4x - curvesRight 795 5x - reversesLeft 796 6x - reversesRight 797 7x - windingRoad 798 8x - hairPin 799 9x - pretzelTurn 800 Ax - crossRoads 801 Bx - crossT 802 Cx - crossY 803 Dx - circle 804 Ex - laneEnds 805 Fx - roadNarrows 806 } 808 field 9x: Current Tile Speed { 809 0x - null 810 1x - < 5kmh 811 2x - < 10kmh 812 3x - < 15kmh 813 4x - < 20kmh 814 5x - < 30kmh 815 6x - < 40kmh 816 7x - < 50kmh 817 8x - < 60kmh 818 9x - < 80kmh 819 Ax - < 100kmh 820 Bx - < 120kmh 821 Cx - < 140kmh 822 Dx - < 160kmh 823 Ex - > 160kmh 824 Fx - queuedTraffic 825 } 827 field Ax: Vehicle / Pedestrian Traffic { 828 0x - null 829 1x - probability of ped/vehicle on tile close to 100% 830 2x - 95% 831 3x - 90% 832 4x - 85% 833 5x - 80% 834 6x - 70% 835 7x - 60% 836 8x - 50% 837 9x - 40% 838 Ax - 30% 839 Bx - 20% 840 Cx - 15% 841 Dx - 10% 842 Ex - 5% 843 Fx - probability of ped/vehicle on tile close to 0%, empty 844 } 846 filed Bx - reserved platooning lineup 847 field Cx - reserved objects of interest 848 field Dx - reserved 849 field Ex - reserved 850 field Fx - reserved 852 10. Normative References 854 [I-D.ietf-lisp-rfc6833bis] 855 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 856 "Locator/ID Separation Protocol (LISP) Control-Plane", 857 draft-ietf-lisp-rfc6833bis-07 (work in progress), December 858 2017. 860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 861 Requirement Levels", BCP 14, RFC 2119, 862 DOI 10.17487/RFC2119, March 1997, 863 . 865 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 866 Locator/ID Separation Protocol (LISP)", RFC 6830, 867 DOI 10.17487/RFC6830, January 2013, 868 . 870 [RFC8378] Farinacci, D., Moreno, V., "Signal-Free Locator/ID Separation 871 Protocol (LISP) Multicast", RFC8378, 872 DOI 10.17487/RFC8378, May 2018, 873 . 875 Authors' Addresses 877 Sharon Barkai 878 Nexar 879 CA 880 USA 882 Email: sbarkai@gmail.com 884 Bruno Fernandez-Ruiz 885 Nexar 886 London 887 UK 889 Email: b@getnexar.com 891 S ZionB 892 Nexar 893 Israel 895 Email: sharon@fermicloud.io 897 Rotem Tamir 898 Nexar 899 Israel 901 rotem.tamir@getnexar.com 903 Alberto Rodriguez-Natal 904 Cisco Systems 905 170 Tasman Drive 906 San Jose, CA 907 USA 909 Email: natal@cisco.com 911 Fabio Maino 912 Cisco Systems 913 170 Tasman Drive 914 San Jose, CA 915 USA 917 Email: fmaino@cisco.com 919 Albert Cabellos-Aparicio 920 Technical University of Catalonia 921 Barcelona 922 Spain 924 Email: acabello@ac.upc.edu 926 Jordi Paillissé-Vilanova 927 Technical University of Catalonia 928 Barcelona 929 Spain 931 Email: jordip@ac.upc.edu 933 Dino Farinacci 934 lispers.net 935 San Jose, CA 936 USA 938 Email: farinacci@gmail.com