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