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