idnits 2.17.1 draft-ietf-lisp-nexagon-03.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 991 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 214 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 110 has weird spacing: '...receive consi...' == Line 196 has weird spacing: '...through cloud...' == Line 614 has weird spacing: '...unneled and i...' == Line 846 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 (July 1, 2020) is 1395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-lisp-rfc6833bis' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'RFC8378' is defined on line 873, 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: December 1, 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 July 1, 2020 16 Network-Hexagons: H3-LISP GeoState & Mobility Network 17 draft-ietf-lisp-nexagon-03 19 Abstract 21 This document specifies use of H3 and LISP to publish subscribe and reflect 22 real-time state and status of public spaces and public roads: 23 - Tile by tile, indexed annotation of streets & curbs in near real time 24 - Sharing hazards, blockages, parking, weather, maintenance, inventory.. 25 - Between MobilityClients who produce and consume geo-state information 26 - Using geo-spatial IP channels of current state of the physical world 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 4, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 65 4. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 4 66 5. Mobility Clients Network Services . . . . . . . . . . . . . . 4 67 6. Mobility Unicast-Multicast . . . . . . . . . . . . . . . . . 5 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 (1) The Locator/ID Separation Protocol (LISP) [RFC6830] splits current IP 77 addresses in two different namespaces, Endpoint Identifiers (EIDs) and 78 Routing Locators (RLOCs). LISP uses a map-and-encap approach that relies on 79 (1) a Mapping System (distributed database) that stores and disseminates 80 EID-RLOC mappings and on (2) LISP tunnel routers (xTRs) that encapsulate 81 and decapsulate data packets based on the content of those mappings. 83 (2) H3 is a geospatial indexing system using a hexagonal grid that can be 84 (approximately) subdivided into finer and finer hexagonal grids, 85 combining the benefits of a hexagonal grid with hierarchical subdivisions. 86 H3 supports sixteen resolutions. Each finer resolution has cells with one 87 seventh the area of the coarser resolution. Hexagons cannot be perfectly 88 subdivided into seven hexagons, so the finer cells are only approximately 89 contained within a parent cell. Each cell is identified by a 64bit HID. 91 (3) The Berkeley Deep Drive (BDD) Industry Consortium investigates state-of- 92 the-art technologies in computer vision and machine learning for automotive 93 applications, and, for taxonomy of published automotive scene classification. 95 These standards are combined to create an in-network state which reflects the 96 condition of each hexagonal tile (~1sqm) in every road. The lisp network maps 97 & encapsulates traffic between MobilityClient endpoint identifiers (EID), and 98 addressable tile-objects (HID=>EID). objects are aggregated by H3Service EIDs. 100 The H3-LISP mobility network bridges timing and location gaps between the 101 production and consumption of information by MobilityClients: 102 o vision, sensory, LIADR, AI applications -- information producers 103 o driving-apps, map-apps, command & control -- information consumers 105 This is achieved by putting the physical world on a shared addressable 106 geo-state grid at the edge. The tile by tile, geo-state, mobility network 107 solves key issues in vehicle to vehicle networking, where observed hazards are 108 relayed without clear, reliable convergence. Given a situation observable by 109 some end-points, it is unclear if the relevant end-points which need to know 110 will receive consistent, conflicting, multiple, or no indications whatsoever. 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 to prevent a potential pile-up. 115 Or, when a vehicle crosses an intersection, observing opposite-lane 116 obstruction, construction, double-park, commercial loading or un-loading, 117 garbage truck, or stopped school-bus, there is no clear way for it to alert 118 vehicles approaching that situation as it drives away. 120 Geo-state indirection also helps communicating advanced machine vision and/or 121 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. It is hard to test each new 124 annotation of any sensor or OEM vendor with any other driving application. 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. H3-LISP mobility network solves the limitations 129 of direct vehicle-to-vehicle communication by anchor brokers per geo-tile: 130 timing, security, privacy, interoperability. Anchor brokering is achieved by 131 MobilityClients communicating through in-network addressable geo-states. 132 Addressable tiles are aggregated and maintained by LISP H3ServiceEIDs. 134 MobilityClients can provide drivers with heads-up alerts on hazards and obstacles 135 beyond the line of sight of the driver and the in-car sensors: over traffic, 136 around blocks, far-side junction, beyond road turns or surface curvatures. 137 This highlights the importance of networks in providing road safety and the 138 role networks play in future AV operation support systems (AV-OSS). 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 1 sqm 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 near 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, specified 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 multicast source for updating MobilityClients 207 on the state of the H3.r15 tiles aggregated 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, 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 constantly renewed 276 while on the move and is not intended as a 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 as an application-specific 283 virtual private network (VPN) that supports IPv6 EID addressable geo-state to 284 publish (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 several 289 types of customer equipment connected by wireline, or by wireless to a 290 specific service provider. The Mobility VPN, on the other hand, 291 potentially overlays a number of wireless networks and cloud-edge 292 providers. It also involves dozens of Car-OEM, Driving-Applications, 293 Smart-infrastructure vendors. This is why we require clients to first go 294 through AAA in order to get both a MobilityClientEID and EdgeRTR gateway RLOC 295 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 nexagon | | | 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 and 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 an area 344 The same EdgeRTR may serve several H3.r9 areas for smooth ride continuity, 345 and, several EdgeRTRs may load balance an 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-networks and radio-access specifications 354 - multiple edie providers, public, private, and hybrid clouds 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, 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 uninterrupted. 363 This quality is insured by the LISP RFCs. The determination of identities for 364 MobilityClients to always refer to the correct H3ServiceEID is insured by H3 365 geo-spatial 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 EdgeRTRs while moving. 377 II. Topological by anycast 379 In this option we align an EdgeRTR with topological aggregation like in 380 Evolved Packet or 5GCore aggregation. Mobility Clients are roaming in an 381 area home to that RTR and so does 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 Regardless of the way a given ClientXTR was associated with an EdgeRTR, 403 an authenticated MobilityClient EID can send: [64bitH3.15ID :: 64bitState] 404 annotations to the H3.r9 H3ServiceEID. The H3.r9 EID can be calculated by 405 clients algorithmically from the H3.15 localized annotation snapped-to-tile. 407 The ClientXTR encapsulates MobilityClient EID and H3ServiceEID in a packet 408 sourced from the ClientXTR with the destination of the EdgeRTR RLOC LISP port. 409 EdgeRTRs then re-encapsulate annotation packets either to remote EdgeRTR 410 (option 1) or to homed H3ServiceEID ServerXTR (option 2). 411 The remote EdgeRTR aggregating H3ServiceEIDs re-encapsulates MobilityClient 412 EID to the 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 annotations which are localized to 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 also an IP Multicast channel Source used to update 471 subscribers on the aggregate state of the H3.r15 tiles in the H3.r9 Server. 472 This forms a multipoint to multipoint state channel per H3 geo-location, where 473 the H3 hairpin aggregation point has programable propagation functionality. 475 We use rfc8378 signal-free multicast to implement mcast channels in the 476 overlay. The mobility network has many channels, with only a few thousands of 477 subscribers per channel. MobilityClients driving through or subscribing to an 478 H3.r9 area can explicitly issue an rfc4604 MLDv2 in order to subscribe, or, 479 may be subscribed implicitly by the EdgeRTR gleaning to ucast HID destination. 481 The advantage of an explicit client MLDv2 registration as a trigger to rfc8378 482 is that the clients manage their own mobility mcast handover according to their 483 location-direction vectors, and that it allows for otherwise silent, or, 484 non annotating clients. The advantage of EdgeRTR implicit registration is 485 less signaling required. 487 MLDv2 signaling messages are encapsulated between the ClientXTR and the LISP 488 EdgeRTR, therefore there is no requirement for the underlying network to 489 support native multicast. If native access multicast is supported (for example 490 native 5G multicast), then MobilityClient registration to H3ServiceEID 491 safety channels may be integrated with it, in which case the mobile packet-core 492 (EPC) element supporting it (eNB) will use this standard to register with the 493 appropriate H3.r9 channels in its area. 495 Multicast update packets are of the following structure: 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 500 |Version| Traffic Class | Flow Label | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 502 | Payload Length | Next Header | Hop Limit | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 504 | | | 505 + + | 506 | | | 507 + Source H3-R9 EID Address + | 508 | | IPv6 509 + + | 510 | | | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 512 | | | 513 + + | 514 | | | 515 + Group Address + | 516 | | | 517 + + | 518 | | / 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Source Port = xxxx | Dest Port = xxxx | \ 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 522 | UDP Length | UDP Checksum | / 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 524 | | Nexagons Header 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 526 ~ Nexagons Payload ~ 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 Outer headers = 40 (IPv6) + 8 (UDP) + 8 (LISP) = 56 530 Inner headers = 40 (IPv6) + 8 (UDP) + 4 (Nexagon Header) = 52 532 1500 (MTU) - 56 - 52 = 1392 bytes of effective payload 534 Type 1:key-value, key-value.. 1392 / (8 + 8) = 87 pairs 535 Type 2:value, key,key,key.. (1392 - 8) / 8 = 173 H3-R15 IDs 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 540 | Type = 1 |gzip | Reserved | Pair Count = X| Nexagon Header 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 542 | | 543 + 64 Bit H3-R15 ID + 544 | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | | 547 + 64 Bit State + 548 | | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | | 551 + 64 Bit H3-R15 ID + 552 | | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | | 555 + 64 Bit State + 556 | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 562 | Type = 2 |gzip | Reserved |H3R15 Count = X| Nexagon Header 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 564 | | 565 + 64 Bit State + 566 | | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | | 569 + 64 Bit H3-R15 ID + 570 | | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | | 573 + 64 Bit H3-R15 ID + 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | | 577 + 64 Bit H3-R15 ID + 578 | | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 ` The remote EdgeRTRs homing MobilityClients in turn replicate the packet to the 582 MobilityClients registered with them. 584 We expect an average of 600 H3.r15 tiles of the full 7^6 (~100K) possible in 585 H3.r9 to be part of any road. The H3.r9 server can transmit the status of all 586 600 or just those with meaningful state based on update SLA and policy. 588 To Summarize: 590 (1) H3LISP Clients tune to H3.r9 mobility updates using rfc8378 591 H3LISP Client issue MLDv2 registration to H3.r9 HIDs 592 ClientXTRs encapsulate MLDv2 to EdgeRTRs who register (s,g) 594 (2) ServerXTRs encapsulate updates to EdgeRTRs who map-resolve (s,g) RLOCs 595 EdgeRTRs replicate mobility update and tunnel to registered EdgeRTRs 596 Remote EdgeRTRs replicate updates to registered ClientXTRs 598 7. Security Considerations 600 The nexagon layer3 v2v/v2i/v2x network is inherently more secure and private 601 then alternatives because of the indirection. No car or infrastructure element 602 ever communicates directly with MobilityClients. All information is conveyed 603 using shared addressable geo-state. MobilityClients are supposed to receive 604 information only from network channels as a trusted broker without indication 605 as to the origin of the information. This is an important step towards better 606 privacy, security, extendability, and interoperability. 608 In order to be able to use the nexagon mobility network for a given period, 609 the mobility clients go through a DNS/AAA stage by which they obtain their 610 clientEID identifiers-credentials and the RLOCs of EdgeRTRs they may use as 611 gateways to the network. This MobilityClient <> EdgeRTR interface is the most 612 sensitive in this network to privacy and security considerations. 614 The traffic on the MobilityClient<>EdgeRTR interface is tunneled and its UDP 615 content may be encrypted; still, the EdgeRTR will know based on the LISP 616 headers alone the MobilityClient RLOC and H3-R9 (~0.1sqkm) geo-spatial area 617 to which a given client publishes or subscribes to. 619 For this reason we envision the ability of enterprise or groups of users to 620 "bring their own" EdgeRTRs. BYO-RTR masks individual clients' IP-RLOC to 621 H3-R9 association and is pre-provisioned to be able to use the mapping system 622 and be on a white-list of EdgeRTRs aggregating H3ServiceEIDs. 624 Beyond this sensitive hop, the mapping system does not hold MobilityClientEIDs, 625 and remote EdgeRTRs are only aware of MobilityClient ephemeral EIDs, not their 626 actual IP RLOC or any other mobile-device identifiers. EdgeRTRs register in the 627 mapping (s,g) H3-R9 multicast groups, but which clients reside beyond which 628 EdgeRTR is not in the mapping system, only the AAA server is aware of that. 629 The H3ServiceEIDs themselves decrypt and parse actual H3-R15 annotations, 630 they also consider during this the MobilityClientEID credentials to avoid 631 "fake-news", but again these are only temporary EIDs allocated to clients 632 in order to be able to use the mobility network and not for their actual IP. 634 8. Acknowledgments 636 This work is partly funded by the ANR LISP-Lab project #ANR- 637 13-INFR-009 (https://lisplab.lip6.fr). 639 9. IANA Considerations 641 I. Formal H3 to IPv6 EID mapping 643 II. State enum fields of H3 tiles: 645 Field 0x: Traffic Direction { 646 0x - null 647 1x - Lane North 648 2x - Lane North + 30 649 3x - Lane North + 60 650 4x - Lane North + 90 651 5x - Lane North + 120 652 6x - Lane North + 150 653 7x - Lane North + 180 654 8x - Lane North + 210 655 9x - Lane North + 240 656 Ax - Lane North + 270 657 Bx - Lane North + 300 658 Cx - Lane North + 330 659 Dx - junction 660 Ex - shoulder 661 Fx - sidewalk 662 } 664 field 1x: Persistent or Structural { 665 0x - null 666 1x - pothole light 667 2x - pothole severe 668 3x - speed-bump low 669 4x - speed-bump high 670 5x - icy 671 6x - flooded 672 7x - snow-cover 673 8x - snow-deep 674 9x - construction cone 675 Ax - gravel 676 Bx - choppy 677 Cx - blind-curve 678 Dx - steep-slope 679 Ex - low-bridge 680 } 682 field 2x: Transient Condition { 683 0x - null 684 1x - pedestrian 685 2x - bike scooter 686 3x - stopped car / truck 687 4x - moving car / truck 688 5x - first responder vehicle 689 6x - sudden slowdown 690 7x - oversized over-height vehicle 691 8x - red-light-breach 692 9x - light collision (fender bender) 693 Ax - hard collision / casualty 694 Bx - collision course car/structure 695 Cx - recent collision residues 696 Dx - hard brake 697 Ex - sharp cornering 698 Fx - freeing-parking 699 } 701 field 3x: Traffic-light Cycle { 702 0x - null 703 1x - 1 seconds to green 704 2x - 2 seconds to green 705 3x - 3 seconds to green 706 4x - 4 seconds to green 707 5x - 5 seconds to green 708 6x - 6 seconds to green 709 7x - 7 seconds to green 710 8x - 8 seconds to green 711 9x - 9 seconds to green 712 Ax - 10 seconds or less 713 Bx - 20 seconds or less 714 Cx - 30 seconds or less 715 Dx - 60 seconds or less 716 Ex - green now 717 Fx - red now 718 } 720 field 4x: Impacted Tile from Neighboring { 721 0x - null 722 1x - epicenter 723 2x - light yellow 724 3x - yellow 725 4x - light orange 726 5x - orange 727 6x - light red 728 7x - red 729 8x - light blue 730 9x - blue 731 Ax - green 732 Bx - light green 733 } 735 field 5x: Transient, Cycle, Impacted, Valid for Next{ 736 0x - null 737 1x - 1sec 738 2x - 5sec 739 3x - 10sec 740 4x - 20sec 741 5x - 40sec 742 6x - 60sec 743 7x - 2min 744 8x - 3min 745 9x - 4min 746 Ax - 5min 747 Bx - 10min 748 Cx - 15min 749 Dx - 30min 750 Ex - 60min 751 Fx - 24hours 752 } 754 field 6x: LaneRightsSigns { 755 0x - null 756 1x - yield 757 2x - speedLimit 758 3x - straightOnly 759 4x - noStraight 760 5x - rightOnly 761 6x - noRight 762 7x - rightStraight 763 8x - leftOnly 764 9x - leftStraight 765 Ax - noLeft 766 Bx - noUTurn 767 Cx - noLeftU 768 Dx - bikeLane 769 Ex - HOVLane 770 Fx - Stop 771 } 773 field 7x: MovementSigns { 774 0x - null 775 1x - keepRight 776 2x - keepLeft 777 3x - stayInLane 778 4x - doNotEnter 779 5x - noTrucks 780 6x - noBikes 781 7x - noPeds 782 8x - oneWay 783 9x - parking 784 Ax - noParking 785 Bx - noStandaing 786 Cx - noPassing 787 Dx - loadingZone 788 Ex - railCross 789 Fx - schoolZone 790 } 792 field 8x: CurvesIntersectSigns { 793 0x - null 794 1x - turnsLeft 795 2x - turnsRight 796 3x - curvesLeft 797 4x - curvesRight 798 5x - reversesLeft 799 6x - reversesRight 800 7x - windingRoad 801 8x - hairPin 802 9x - pretzelTurn 803 Ax - crossRoads 804 Bx - crossT 805 Cx - crossY 806 Dx - circle 807 Ex - laneEnds 808 Fx - roadNarrows 809 } 811 field 9x: Current Tile Speed { 812 0x - null 813 1x - < 5kmh 814 2x - < 10kmh 815 3x - < 15kmh 816 4x - < 20kmh 817 5x - < 30kmh 818 6x - < 40kmh 819 7x - < 50kmh 820 8x - < 60kmh 821 9x - < 80kmh 822 Ax - < 100kmh 823 Bx - < 120kmh 824 Cx - < 140kmh 825 Dx - < 160kmh 826 Ex - > 160kmh 827 Fx - queuedTraffic 828 } 830 field Ax: Vehicle / Pedestrian Traffic { 831 0x - null 832 1x - probability of ped/vehicle on tile close to 100% 833 2x - 95% 834 3x - 90% 835 4x - 85% 836 5x - 80% 837 6x - 70% 838 7x - 60% 839 8x - 50% 840 9x - 40% 841 Ax - 30% 842 Bx - 20% 843 Cx - 15% 844 Dx - 10% 845 Ex - 5% 846 Fx - probability of ped/vehicle on tile close to 0%, empty 847 } 849 filed Bx - reserved platooning 850 field Cx - reserved platooning 851 field Dx - reserved platooning 852 field Ex - reserved platooning 853 field Fx - reserved platooning 855 10. Normative References 857 [I-D.ietf-lisp-rfc6833bis] 858 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 859 "Locator/ID Separation Protocol (LISP) Control-Plane", 860 draft-ietf-lisp-rfc6833bis-07 (work in progress), December 861 2017. 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, 865 DOI 10.17487/RFC2119, March 1997, 866 . 868 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 869 Locator/ID Separation Protocol (LISP)", RFC 6830, 870 DOI 10.17487/RFC6830, January 2013, 871 . 873 [RFC8378] Farinacci, D., Moreno, V., "Signal-Free Locator/ID Separation 874 Protocol (LISP) Multicast", RFC8378, 875 DOI 10.17487/RFC8378, May 2018, 876 . 878 Authors' Addresses 880 Sharon Barkai 881 Nexar 882 CA 883 USA 885 Email: sbarkai@gmail.com 887 Bruno Fernandez-Ruiz 888 Nexar 889 London 890 UK 892 Email: b@getnexar.com 894 S ZionB 895 Nexar 896 Israel 898 Email: sharon@fermicloud.io 900 Rotem Tamir 901 Nexar 902 Israel 904 rotem.tamir@getnexar.com 906 Alberto Rodriguez-Natal 907 Cisco Systems 908 170 Tasman Drive 909 San Jose, CA 910 USA 912 Email: natal@cisco.com 914 Fabio Maino 915 Cisco Systems 916 170 Tasman Drive 917 San Jose, CA 918 USA 920 Email: fmaino@cisco.com 922 Albert Cabellos-Aparicio 923 Technical University of Catalonia 924 Barcelona 925 Spain 927 Email: acabello@ac.upc.edu 929 Jordi Paillissé-Vilanova 930 Technical University of Catalonia 931 Barcelona 932 Spain 934 Email: jordip@ac.upc.edu 936 Dino Farinacci 937 lispers.net 938 San Jose, CA 939 USA 941 Email: farinacci@gmail.com