idnits 2.17.1 draft-ietf-lisp-nexagon-06.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 1040 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 240 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 113 has weird spacing: '...receive consi...' == Line 218 has weird spacing: '...through cloud...' == Line 638 has weird spacing: '...unneled and i...' == Line 893 has weird spacing: '...vehicle on ti...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-lisp-rfc6833bis' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'RFC8378' is defined on line 920, 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: April 17, 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 17,2020 16 Network-Hexagons: H3-LISP GeoState & Mobility Network 17 draft-ietf-lisp-nexagon-06 19 Abstract 21 This document specifies use of H3 and LISP to publish subscribe and reflect 22 the 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 state-grid typically at the edge. Tile by tile geo-state sharing using a 107 brokered-network solves key issues in vehicle to vehicle information sharing. 108 Challenges such as vision sensors when there are multiple perspectives, 109 privacy and cyber when clients are directly communicating when they do not have 110 to, and global geo pub-sub scenarios. 112 Given a situation observable by some end-points, it is unclear if the relevant 113 end-points which need to know will receive consistent, conflicting, multiple, 114 or no indications whatsoever. For example, when a vehicle experiences a sudden 115 highway slow-down,"sees" many brake lights or "feels" accelerometer, there is 116 no clear way for it to share this annotation with vehicles 20-30sec away to 117 prevent a potential pile-up. Or, when a vehicle crosses an intersection, 118 observing opposite-lane obstruction, construction, double-park, commercial 119 loading, garbage truck, or stopped school-bus, there is no clear way for it to 120 alert vehicles approaching that situation as it drives away. 122 Geo-state indirection also helps communicate advanced machine vision and/or 123 radar annotations. These are constantly evolving technologies, and relaying 124 road enumerations they produce, using peer-to-peer protocols, poses a 125 significant interoperability challenge. It is hard to test each new 126 annotation of any sensor or OEM vendor with any other driving application. 127 Brokered IP multicast channels are themed, subscribing means interoperating. 129 These peer-to-peer limitations are inherent yet unnecessary, as in most road 130 situations vehicles are not really proper peers. They just happen to be in the 131 same place at the same time. H3-LISP mobility network solves the limitations 132 of direct vehicle-to-vehicle communication by anchor brokers per geo-tile: 133 timing, security, privacy, interoperability. Anchor brokering is achieved by 134 MobilityClients communicating through in-network addressable geo-states. 135 Addressable tiles are aggregated and maintained by LISP H3ServiceEIDs. 137 MobilityClients can provide drivers with heads-up alerts on hazards and obstacles 138 beyond the line of sight of the driver and the in-car sensors: over traffic, 139 around blocks, far-side junction, beyond road turns or surface curvatures. 140 This highlights the importance of networks in providing road safety and the 141 role networks play in future AV operation support systems (AV-OSS). 143 Beyond sharing use cases like finding freed-up curb-parking and help avoid 144 construction zones, a mission critical use case for global geo-pub-sub has to 145 do with supporting autonomous vehicle (AV) fleets. 147 Its now a consensus that as specific AV fleets start to role out, or regular 148 cars with AV abilities become more perversive, that they need remote operations 149 and remote take-over support. This means that for every M such cars there needs 150 to be N human remote drivers ready to take over. These AV-OSS are put together 151 by consortiums of multiple companies and are measured by their N/M. 153 Nexagon geo-channels role in this context is two fold: 155 1. flag tiles where the AV got confused because of current condition which is 156 requiring remote intervention, so to steer other AVs away from this tile. 157 This so not to pull-in more and more humans to intervene as more cars arrive. 158 2. fleets will heavily rely on platoons, convoys assembled on the road on the 159 fly, driven at the head by a remote operator or human driver. AVs need to 160 lock-on. Geo channels are used pub-sub these platoons as they drive by. 162 To summarize the H3-LISP solution outline: 164 (1) MicroPartition: 64bit indexed geo-spatial H3.r15 road-tiles 165 (2) EnumState: 64bit state values compile tile condition representation 166 (3) Aggregation: H3.r9 H3ServiceEID group individual H3.r15 road-tiles 167 (4) Channels: H3ServiceEIDs function as multicast state update channels 168 (5) Scale: H3ServiceEIDs distributed for in-network for latency-throughput 169 (6) Mapped Overlay: tunneled-network routes the mobility-network traffic 170 (7) Signal-free: tunneled overlay is used to map-register for mcast channels 171 (8) Aggregation: tunnels used between MobilityClients/H3ServiceEIDs <> edge 172 (9) Access: ClientXTRs/ServerXTRs tunnel traffic to-from the LISP EdgeRTRs 173 (10) Control: EdgeRTRs register-resolve H3ServiceEIDs and mcast subscription 175 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 176 | H3 Hexagon ID Key | 177 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 178 | H3 Hexagon State-Value | 179 |---------------------------------------------------------------| 181 ___ ___ 182 H3ServiceEIDs ___ / \ H3ServiceEIDs ___ / \ 183 ___ / | H3.r9 | ___ / | H3.r9 | 184 / | H3.r9 \ ___ / / | H3.r9 \ ___ / 185 | H3.r9 \ ___ / sXTR | H3.r9 \ ___ / sXTR 186 \ ___ / sXTR | \ ___ / sXTR | 187 sXTR | | sXTR | | 188 | | | | | | 189 | | | | | | 190 + - - + - - EdgeRTR EdgeRTR - + - + - - + 191 || ( ( (( || 192 ( ) 193 ( Network Hexagons ) 194 ( H3-LISP ) 195 ( Mobility Network ) 196 (( ) 197 || (( (()) () || 198 || || 199 = = = = = = = = = = = = = = 200 || || 201 EdgeRTR EdgeRTR 202 .. .. .. .. 203 .. .. .. .. 204 ((((|)))) ((((|)))) ((((|)))) ((((|)))) 205 /|\ RAN /|\ /|\ RAN /|\ 206 .. .. 207 .. .. 208 .. Road tiled by 1 sqm H3.r15 ID-Ed Geo-States .. 209 .. .. 210 .. ___ ___ ___ .. 211 .. .............. / \/ \/ \ << cXTR::MobilityClientB 212 .. - - - - - - - H3.r15 H3.r15 H3.r15 - - - - - - - 213 MobilityClientA::cXTR >> \ ___ /\ ___ /\ ___ /.......... 215 - MobilityClientA has seen MobilityClientB near future, and, vice versa 216 - Clients share information using addressable shared-state routed by LISP Edge 217 - ClientXTR (cXTR): tunnel encapsulation through access network to LISP Edge 218 - ServerXTR (sXTR): tunnel encapsulation through cloud network to LISP Edge 219 - The H3-LISP Mobility overlay starts in the cXTR and terminates in the sXTR 220 - The updates are routed to the appropriate tile geo-state by the LISP network 221 - EdgeRTRs perform multicast replication to edges and then native or to cXTRs 222 - Clients receive tile-by-tile geo-state updates via the multicast channels 224 Each H3.r9 hexagon is an EID Service with corresponding H3 hexagon ID. 225 Bound to that service is a LISP xTR, called a ServerXTR, specified to deliver 226 encapsulated packets to and from the H3ServiceEID and LISP Edge. EdgeRTRs are 227 used to re-tunnel packets from MobilityClients to H3ServiceEIDs. Each 228 H3ServiceEID is also a multicast source for updating MobilityClients 229 on the state of the H3.r15 tiles aggregated by the H3ServiceEID. 231 2. Requirements Language 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in [RFC2119]. 237 3. Definition of Terms 239 H3ServiceEID: Is an addressable aggregation of H3.r15 state-tiles. It is a 240 designated source for physical world reported annotations, and an (s,g) 241 source of multicast public-safety update channels. H3ServiceEID is itself 242 an H3 hexagon, large enough to provide geo-spatial conditions context, but 243 not too large as to over-burden (battery powered, cellular connected) 244 subscribers with too much information. For Mobility Network it is H3.r9. 245 It has a light-weight LISP protocol stack to tunnel packets aka ServerXTR. 246 The EID is an IPv6 EID that contains the H3 64-bit address numbering 247 scheme. See IANA consideration for details. 249 ServerXTR: Is a light-weight LISP protocol stack implementation that co-exists 250 with H3ServiceEID process. When the server roams, the xTR roams with it. 251 The ServerXTR encapsulates and decapsulates packets to/from EdgeRTRs. 253 MobilityClient: Is a roaming application that may be resident as part of an 254 automobile, as part of a navigation application, part of municipal, state, 255 of federal government command and control application, or part of live 256 street view consumer type of application. It has a light-weight LISP 257 protocol stack to tunnel packets aka ClientXTR. 259 MobilityClient EID: Is the IPv6 EID used by the Mobility Client applications 260 to source packets. The destination of such packets are only H3ServiceEIDs. 261 The EID format is opaque and is assigned as part of the MobilityClient 262 network-as-a-service (NaaS) authorization. 264 ClientXTR: Is the light-weight LISP protocol stack implementation that is 265 co-located with the Mobility Client application. It encapsulates packets 266 sourced by applications to EdgeRTRs and decapsulates packets from EdgeRTRs. 268 EdgeRTR: Is the core scale and structure of the LISP mobility network. 269 EdgeRTRs proxy H3ServiceEIDs and MobilityClient H3ServiceEID channel 270 registration. EdgeRTRs aggregate MobilityClients and H3Services using 271 tunnels to facilitate hosting-providers and mobile-hosting flexibility - 272 for accessing the nexagon mobility network. 273 EdgeRTRs decapsulate packets from ClientXTRs, ServerXTRs and re-encapsulates 274 packets to the clients and servers tunnels. EdgeRTRs glean H3ServiceEIDs 275 and glean MobilityClient EIDs when it decapsulates packets. EdgeRTRs store 276 H3ServiceEIDs and their own RLOC of where the H3ServiceEID is currently 277 reachable from in the map-cache. These mappings are registered to the LISP 278 mapping system so other EdgeRTRs know where to encapsulate for such EIDs. 279 EdgeRTRs do not register MobilityClients' EIDs at the mapping service as 280 these are temporary-renewed while using the mobility network. Enterprises 281 may provide their own client facing EdgeRTRs to mask their clients geo- 282 whereabouts while using the mobility network. 284 4. Deployment Assumptions 286 The specification described in this document makes the following 287 deployment assumptions: 289 (1) Unique 64-bit HID is associated with each H3 geo-spatial tile 290 (2) MobilityClients and H3ServiceEIDs share this well known index 291 (3) 64-bit BDD state value is associated with each H3-indexed tile 292 (4) Tile state is compiled 16 fields of 4-bits, or max 16 enums 294 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 295 0123012301230123012301230123012301230123012301230123012301230123 297 Subscription of MobilityClients to the mobility network is constantly renewed 298 while on the move and is not intended as a means of basic connectivity. This 299 is why MobilityClients use DNS/AAA to obtain temporary EIDs and EdgeRTRs 300 and why they use (LISP) data-plane tunnels to communicate using their 301 temporary EIDs with the dynamically assigned EdgeRTRs. 303 MobilityClient are otherwise unaware of the LISP network mechanism or mapping 304 system and simply regard the data-plane tunnels as an application-specific 305 virtual private network (VPN) that supports IPv6 EID addressable geo-state to 306 publish (Ucast), Subscribe (Mcast) H3Services. 308 In order to get access to the MobilityVPN, MobilityClients first authenticate 309 with the MobilityVPN AAA Server. DIAMETER based AAA is typically done at the 310 provider edge (PE) by edge gateways. However, the typical case involves several 311 types of customer equipment connected by wireline, or by wireless to a 312 specific service provider. The Mobility VPN, on the other hand, 313 potentially overlays a number of wireless networks and cloud-edge 314 providers. It also involves dozens of Car-OEM, Driving-Applications, 315 Smart-infrastructure vendors. This is why we require clients to first go 316 through AAA in order to get both a MobilityClientEID and EdgeRTR gateway RLOC 317 opened. 319 ClientXTR performs the following steps in order to use the mobility network: 320 1) obtain the address of the mobility network AAA server using DNS 321 2) obtain MobilityClientEID and EdgeRTR(s) from AAA server using DIAMETER 322 3) renew authorization from AAA while using the mobility network T1 minutes 324 MobilityClient Domain Name Server DIAMETER AAA Mobility EdgeRTR 325 | | | | 326 | nslookup nexagon | | | 327 |------------------->| | | 328 |<-------------------| | | 329 | Mobility AAA IP | | | 330 | | | | 331 | AAR(AVP:IMSI/User/Password/Toyota) | | 332 |--------------------------------------->| | 333 | | | ACR(AVP ClientEID)| 334 | | |------------------>| 335 | | |<------------------| 336 | | | ACA(AVP ClientEID)| 337 | AAA (Client::EID,EdgeRTR::RLOC) | | 338 |<---------------------------------------| | 339 | | | | 340 . . 341 . . 342 . . 343 | Publish IPv6 H3ServiceEID, Subscribe MLDv2 H3ServiceEID | . 344 |----------------------------------------------------------->| 345 . . 346 . . 347 |<-----------------------------------------------------------| 348 | Signal freeing multicast Updates from H3ServiceEIDs | 349 . . 350 . . 351 . . 352 | | | | 353 | AAR(Interim) | | 354 |--------------------------------------->| ACR (Interim) | 355 | | |------------------>| 356 | | |<------------------| 357 | | | ACA (Interim) | 358 |<---------------------------------------| | 359 | AAA (Interim) | | 361 Using this network login and re-login method we ensure that: 362 - the MobilityClientEIDs serve as credentials with the specific EdgeRTRs 363 - EdgeRTRs are provisioned to whitelist MobilityClient EIDs assigned to them 364 - EdgeRTRs are not tightly coupled to H3.r9 areas for privacy/load-balance 365 - Mobility Clients do not need to update EdgeRTRs while roaming in an area 367 The same EdgeRTR may serve several H3.r9 areas for smooth ride continuity, 368 and, several EdgeRTRs may load balance an H3.r9 area with high density of 369 originating MobilityClient rides. When a MobilityClient ClientXTR is homed 370 to EdgeRTR, it is able to communicate with H3ServiceEIDs. 372 5. Mobility Clients Network Services 374 The mobility network functions as a standard LISP VPN overlay. 375 The overlay delivers unicast and multicast packets across: 376 - multiple access-networks and radio-access specifications 377 - multiple edie providers, public, private, and hybrid clouds 379 We use data-plane XTRs in the stack of each mobility client and server. 380 ClientXTRs and ServerXTRs are homed to one or more EdgeRTRs at the LISP edge. 381 This structure allows for MobilityClients to "show up" at any time, 382 behind any network provider in a given mobility network administrative 383 domain, and for any H3ServiceEID to be instantiated, moved, or 384 failed-over to any rack in any cloud-provider. The LISP overlay enables 385 these roaming mobility network elements to communicate uninterrupted. 386 This quality is insured by the LISP RFCs. The determination of identities for 387 MobilityClients to always refer to the correct H3ServiceEID is insured by H3 388 geo-spatial HIDs. 390 There are two options for how we associate ClientXTRs with LISP EdgeRTRs: 392 I. Semi-random load-balancing by DNS/AAA 394 In this option we assume that in a given metro edge, a pool of EdgeRTRs can 395 distribute the Mobility Clients load randomly between them and that EdgeRTRs 396 are topologically more or less equivalent. Each RTR uses LISP to tunnel 397 traffic to and from other EdgeRTRs for MobilityClient with H3Service exchanges. 398 MobilityClients can (multi) home to EdgeRTRs while moving. 400 II. Topological by anycast 402 In this option we align an EdgeRTR with topological aggregation like in 403 Evolved Packet or 5GCore aggregation. Mobility Clients are roaming in an 404 area home to that RTR and so is the H3 Server. There is only one hop across 405 the edge overlay between clients and servers and mcast replication is more 406 focused, but clients need to keep re-homing as they move. 408 To summarize the H3LISP mobility network layout: 410 (1) Mobility-Clients traffic is tunneled via data-plane ClientXTRs 411 ClientXTRs are (multi) homed to EdgeRTR(s) 412 (2) H3ServiceEID traffic is tunneled via data-plane ServerXTR 413 ServerXTRs are (multi) homed to EdgeRTR(s) 414 (3) EdgeRTRs use mapping service to resolve Ucast HIDs to RTR RLOCs 415 EdgeRTRs also register to (Source, Group) H3ServiceEID multicasts 417 MobilityClients <> ClientXTR EdgeRTR v 418 v 419 v << Map-Assisted Mobility-Network Overlay << v 420 v 421 >> EdgeRTR ServerXTR <> H3ServiceEID 423 6. Mobility Unicast and Multicast 425 Regardless of the way a given ClientXTR was associated with an EdgeRTR, 426 an authenticated MobilityClient EID can send: [64bitH3.15ID :: 64bitState] 427 annotations to the H3.r9 H3ServiceEID. The H3.r9 EID can be calculated by 428 clients algorithmically from the H3.15 localized annotation snapped-to-tile. 430 The ClientXTR encapsulates MobilityClient EID and H3ServiceEID in a packet 431 sourced from the ClientXTR with the destination of the EdgeRTR RLOC LISP port. 432 EdgeRTRs then re-encapsulate annotation packets either to remote EdgeRTR 433 (option 1) or to homed H3ServiceEID ServerXTR (option 2). 434 The remote EdgeRTR aggregating H3ServiceEIDs re-encapsulates MobilityClient 435 EID to the ServerXTR and from there to the H3ServiceEID. 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 440 |Version| Traffic Class | Flow Label | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 442 | Payload Length | Next Header | Hop Limit | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 444 | | | 445 + + | 446 | | | 447 + Source MobilityClientEID + | 448 | | IPv6 449 + + | 450 | | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 452 | | | 453 + + | 454 | | | 455 + Dest H3ServiceEID + | 456 | | | 457 + + | 458 | | / 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Source Port = xxxx | Dest Port = xxxx | \ 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 462 | UDP Length | UDP Checksum | / 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 464 | Type |gzip | Reserved | Pair Count = X| Nexgon Header 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 466 | | 467 + 64 Bit H3-R15 ID + 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | | 471 + 64 Bit State + 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | | 475 + 64 Bit H3-R15 ID + 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | | 479 + 64 Bit State + 480 | | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 To Summarize Unicast: 485 (1) MobilityClients can send annotations which are localized to an H3.r15 tile 486 These annotations are sent to an H3.r9 mobility H3ServiceEIDs 487 (2) MobilityClient EID and H3ServiceEID HID are encapsulated: 488 XTR <> RTR <> RTR <> XTR 489 * RTRs can map-resolve re-tunnel HIDs 490 (3) RTRs re-encapsulate original source-dest to ServerXTRs 491 ServerXTRs decapsulate packets to H3ServiceEID 493 Each H3.r9 Server is also an IP Multicast channel Source used to update 494 subscribers on the aggregate state of the H3.r15 tiles in the H3.r9 Server. 495 This forms a multipoint to multipoint state channel per H3 geo-location, where 496 the H3 hairpin aggregation point has programable propagation functionality. 498 We use rfc8378 signal-free multicast to implement mcast channels in the 499 overlay. The mobility network has many channels, with only a few thousands of 500 subscribers per channel. MobilityClients driving through or subscribing to an 501 H3.r9 area can explicitly issue an rfc4604 MLDv2 in order to subscribe, or, 502 may be subscribed implicitly by the EdgeRTR gleaning to ucast HID destination. 504 The advantage of an explicit client MLDv2 registration as a trigger to rfc8378 505 is that the clients manage their own mobility mcast handover according to their 506 location-direction vectors, and that it allows for otherwise silent, or, 507 non annotating clients. The advantage of EdgeRTR implicit registration is 508 less signaling required. 510 MLDv2 signaling messages are encapsulated between the ClientXTR and the LISP 511 EdgeRTR, therefore there is no requirement for the underlying network to 512 support native multicast. If native access multicast is supported (for example 513 native 5G multicast), then MobilityClient registration to H3ServiceEID 514 safety channels may be integrated with it, in which case the mobile packet-core 515 (EPC) element supporting it (eNB) will use this standard to register with the 516 appropriate H3.r9 channels in its area. 518 Multicast update packets are of the following structure: 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 523 |Version| Traffic Class | Flow Label | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 525 | Payload Length | Next Header | Hop Limit | | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 527 | | | 528 + + | 529 | | | 530 + Source H3-R9 EID Address + | 531 | | IPv6 532 + + | 533 | | | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 535 | | | 536 + + | 537 | | | 538 + Group Address + | 539 | | | 540 + + | 541 | | / 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Source Port = xxxx | Dest Port = xxxx | \ 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 545 | UDP Length | UDP Checksum | / 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 547 | | Nexagons Header 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 549 ~ Nexagons Payload ~ 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Outer headers = 40 (IPv6) + 8 (UDP) + 8 (LISP) = 56 553 Inner headers = 40 (IPv6) + 8 (UDP) + 4 (Nexagon Header) = 52 555 1500 (MTU) - 56 - 52 = 1392 bytes of effective payload 557 Type 1:key-value, key-value.. 1392 / (8 + 8) = 87 pairs 558 Type 2:value, key,key,key.. (1392 - 8) / 8 = 173 H3-R15 IDs 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 563 | Type = 1 |gzip | Reserved | Pair Count = X| Nexagon Header 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 565 | | 566 + 64 Bit H3-R15 ID + 567 | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 + 64 Bit State + 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | | 574 + 64 Bit H3-R15 ID + 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | | 578 + 64 Bit State + 579 | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 585 | Type = 2 |gzip | Reserved |H3R15 Count = X| Nexagon Header 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 587 | | 588 + 64 Bit State + 589 | | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | | 592 + 64 Bit H3-R15 ID + 593 | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | | 596 + 64 Bit H3-R15 ID + 597 | | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | | 600 + 64 Bit H3-R15 ID + 601 | | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 ` The remote EdgeRTRs homing MobilityClients in turn replicate the packet to the 605 MobilityClients registered with them. 607 We expect an average of 600 H3.r15 tiles of the full 7^6 (~100K) possible in 608 H3.r9 to be part of any road. The H3.r9 server can transmit the status of all 609 600 or just those with meaningful states based on updated SLA and policy. 611 To Summarize: 613 (1) H3LISP Clients tune to H3.r9 mobility updates using rfc8378 614 H3LISP Client issue MLDv2 registration to H3.r9 HIDs 615 ClientXTRs encapsulate MLDv2 to EdgeRTRs who register (s,g) 617 (2) ServerXTRs encapsulate updates to EdgeRTRs who map-resolve (s,g) RLOCs 618 EdgeRTRs replicate mobility update and tunnel to registered EdgeRTRs 619 Remote EdgeRTRs replicate updates to registered ClientXTRs 621 7. Security Considerations 623 The nexagon layer3 v2n network is inherently more secure and private 624 then peer to peer alternatives because of the indirection. No car or 625 infrastructure element communicates directly with MobilityClients. 626 All information is conveyed using shared addressable geo-state. 627 MobilityClients receive information only from network channels published by 628 a trusted broker. MobilityClients have no indication as to the origin of the 629 information. This is an important step towards better privacy, security, 630 extendability, and interoperability compared with legacy layer2 protocols. 632 In order to be able to use the nexagon mobility network for a given period, 633 the mobility clients go through a DNS/AAA stage by which they obtain their 634 clientEID identifiers-credentials and the RLOCs of EdgeRTRs they may use as 635 gateways to the network. This MobilityClient <> EdgeRTR interface is the most 636 sensitive in this network to privacy and security considerations. 638 The traffic on the MobilityClient<>EdgeRTR interface is tunneled and its UDP 639 content may be encrypted; still, the EdgeRTR will know based on the LISP 640 headers alone the MobilityClient RLOC and H3-R9 (~0.1sqkm) geo-spatial area 641 to which a given client publishes or subscribes to. 643 For this reason we envision the ability of enterprise or groups of users to 644 "bring their own" EdgeRTRs. BYO-RTR masks individual clients' IP-RLOC to 645 H3-R9 association and is pre-provisioned to be able to use the mapping system 646 and be on a white-list of EdgeRTRs aggregating H3ServiceEIDs. 648 Beyond this sensitive hop, the mapping system does not hold MobilityClientEIDs, 649 and remote EdgeRTRs are only aware of MobilityClient ephemeral EIDs, not their 650 actual IP RLOC or any other mobile-device identifiers. EdgeRTRs register in the 651 mapping (s,g) H3-R9 multicast groups, but which clients reside beyond which 652 EdgeRTR is not in the mapping system, only the AAA server is aware of that. 653 The H3ServiceEIDs themselves decrypt and parse actual H3-R15 annotations; 654 they also consider during this the MobilityClientEID credentials to avoid 655 "fake-news", but again these are only temporary EIDs allocated to clients 656 in order to be able to use the mobility network and not for their actual IP. 658 In summary of main risk mitigations for the lisp-nexagon interface we can say: 660 (1) tapping: all communications are through dynamic tunnels therefore may be 661 encrypted using IP-Sec or other supported point to point underlay standards. 662 These are not static tunnels but lisp re-tunneling routers (RTRs) perform all 663 nexagon Overlay aggregation. 665 (2) spoofing: it is very hard to guess a MobilityClientEID valid for a short 666 period of time. Clients and H3Services EIDs are whitelisted in EdgeRTRs, 667 Clients using the AAA procedure, H3Services via dev-ops. 669 (3) impersonating: efforts to use MobilityClients and H3Services RLOCs should 670 be caught by the underlying service provider edge and access networks. EID 671 impersonating is caught by EdgeRTR EID RLOC whitelist mismatch. 673 (4) credibility: the interface crowd-sources geo-state and does not assume to 674 trust single detections. Credit history track to MobilityClientEIDs by as part 675 of normal H3Services fact checking, aggregate scores affect AAA credentials. 677 (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and geo-location, 678 only AAA is aware of client IDs credentials and credit but not geo-location. 679 aggregate credit score span all H3Services administratively without source. 681 8. Acknowledgments 683 This work is partly funded by the ANR LISP-Lab project #ANR- 684 13-INFR-009 (https://lisplab.lip6.fr). 686 9. IANA Considerations 688 I. Formal H3 to IPv6 EID mapping 690 II. State enum fields of H3 tiles: 692 Field 0x: Traffic Direction { 693 0x - null 694 1x - Lane North 695 2x - Lane North + 30 696 3x - Lane North + 60 697 4x - Lane North + 90 698 5x - Lane North + 120 699 6x - Lane North + 150 700 7x - Lane North + 180 701 8x - Lane North + 210 702 9x - Lane North + 240 703 Ax - Lane North + 270 704 Bx - Lane North + 300 705 Cx - Lane North + 330 706 Dx - junction 707 Ex - shoulder 708 Fx - sidewalk 709 } 711 field 1x: Persistent or Structural { 712 0x - null 713 1x - pothole light 714 2x - pothole severe 715 3x - speed-bump low 716 4x - speed-bump high 717 5x - icy 718 6x - flooded 719 7x - snow-cover 720 8x - snow-deep 721 9x - construction cone 722 Ax - gravel 723 Bx - choppy 724 Cx - blind-curve 725 Dx - steep-slope 726 Ex - low-bridge 727 } 729 field 2x: Transient Condition { 730 0x - null 731 1x - pedestrian 732 2x - bike scooter 733 3x - stopped car / truck 734 4x - moving car / truck 735 5x - first responder vehicle 736 6x - sudden slowdown 737 7x - oversized over-height vehicle 738 8x - red-light-breach 739 9x - light collision (fender bender) 740 Ax - hard collision / casualty 741 Bx - collision course car/structure 742 Cx - recent collision residues 743 Dx - hard brake 744 Ex - sharp cornering 745 Fx - freeing-parking 746 } 748 field 3x: Traffic-light Cycle { 749 0x - null 750 1x - 1 seconds to green 751 2x - 2 seconds to green 752 3x - 3 seconds to green 753 4x - 4 seconds to green 754 5x - 5 seconds to green 755 6x - 6 seconds to green 756 7x - 7 seconds to green 757 8x - 8 seconds to green 758 9x - 9 seconds to green 759 Ax - 10 seconds or less 760 Bx - 20 seconds or less 761 Cx - 30 seconds or less 762 Dx - 60 seconds or less 763 Ex - green now 764 Fx - red now 765 } 767 field 4x: Impacted Tile from Neighboring { 768 0x - null 769 1x - epicenter 770 2x - light yellow 771 3x - yellow 772 4x - light orange 773 5x - orange 774 6x - light red 775 7x - red 776 8x - light blue 777 9x - blue 778 Ax - green 779 Bx - light green 780 } 782 field 5x: Transient, Cycle, Impacted, Valid for Next{ 783 0x - null 784 1x - 1sec 785 2x - 5sec 786 3x - 10sec 787 4x - 20sec 788 5x - 40sec 789 6x - 60sec 790 7x - 2min 791 8x - 3min 792 9x - 4min 793 Ax - 5min 794 Bx - 10min 795 Cx - 15min 796 Dx - 30min 797 Ex - 60min 798 Fx - 24hours 799 } 801 field 6x: LaneRightsSigns { 802 0x - null 803 1x - yield 804 2x - speedLimit 805 3x - straightOnly 806 4x - noStraight 807 5x - rightOnly 808 6x - noRight 809 7x - rightStraight 810 8x - leftOnly 811 9x - leftStraight 812 Ax - noLeft 813 Bx - noUTurn 814 Cx - noLeftU 815 Dx - bikeLane 816 Ex - HOVLane 817 Fx - Stop 818 } 820 field 7x: MovementSigns { 821 0x - null 822 1x - keepRight 823 2x - keepLeft 824 3x - stayInLane 825 4x - doNotEnter 826 5x - noTrucks 827 6x - noBikes 828 7x - noPeds 829 8x - oneWay 830 9x - parking 831 Ax - noParking 832 Bx - noStandaing 833 Cx - noPassing 834 Dx - loadingZone 835 Ex - railCross 836 Fx - schoolZone 837 } 839 field 8x: CurvesIntersectSigns { 840 0x - null 841 1x - turnsLeft 842 2x - turnsRight 843 3x - curvesLeft 844 4x - curvesRight 845 5x - reversesLeft 846 6x - reversesRight 847 7x - windingRoad 848 8x - hairPin 849 9x - pretzelTurn 850 Ax - crossRoads 851 Bx - crossT 852 Cx - crossY 853 Dx - circle 854 Ex - laneEnds 855 Fx - roadNarrows 856 } 858 field 9x: Current Tile Speed { 859 0x - null 860 1x - < 5kmh 861 2x - < 10kmh 862 3x - < 15kmh 863 4x - < 20kmh 864 5x - < 30kmh 865 6x - < 40kmh 866 7x - < 50kmh 867 8x - < 60kmh 868 9x - < 80kmh 869 Ax - < 100kmh 870 Bx - < 120kmh 871 Cx - < 140kmh 872 Dx - < 160kmh 873 Ex - > 160kmh 874 Fx - queuedTraffic 875 } 877 field Ax: Vehicle / Pedestrian Traffic { 878 0x - null 879 1x - probability of ped/vehicle on tile close to 100% 880 2x - 95% 881 3x - 90% 882 4x - 85% 883 5x - 80% 884 6x - 70% 885 7x - 60% 886 8x - 50% 887 9x - 40% 888 Ax - 30% 889 Bx - 20% 890 Cx - 15% 891 Dx - 10% 892 Ex - 5% 893 Fx - probability of ped/vehicle on tile close to 0%, empty 894 } 896 filed Bx - reserved 897 field Cx - reserved 898 field Dx - reserved 899 field Ex - reserved 900 field Fx - reserved 902 10. Normative References 904 [I-D.ietf-lisp-rfc6833bis] 905 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 906 "Locator/ID Separation Protocol (LISP) Control-Plane", 907 draft-ietf-lisp-rfc6833bis-07 (work in progress), December 908 2017. 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, 912 DOI 10.17487/RFC2119, March 1997, 913 . 915 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 916 Locator/ID Separation Protocol (LISP)", RFC 6830, 917 DOI 10.17487/RFC6830, January 2013, 918 . 920 [RFC8378] Farinacci, D., Moreno, V., "Signal-Free Locator/ID Separation 921 Protocol (LISP) Multicast", RFC8378, 922 DOI 10.17487/RFC8378, May 2018, 923 . 925 Authors' Addresses 927 Sharon Barkai 928 Nexar 929 CA 930 USA 932 Email: sbarkai@gmail.com 934 Bruno Fernandez-Ruiz 935 Nexar 936 London 937 UK 939 Email: b@getnexar.com 941 S ZionB 942 Nexar 943 Israel 945 Email: sharon@fermicloud.io 947 Rotem Tamir 948 Nexar 949 Israel 951 rotemtamir@getnexar.com 953 Alberto Rodriguez-Natal 954 Cisco Systems 955 170 Tasman Drive 956 San Jose, CA 957 USA 959 Email: natal@cisco.com 961 Fabio Maino 962 Cisco Systems 963 170 Tasman Drive 964 San Jose, CA 965 USA 967 Email: fmaino@cisco.com 969 Albert Cabellos-Aparicio 970 Technical University of Catalonia 971 Barcelona 972 Spain 974 Email: acabello@ac.upc.edu 976 Jordi Paillissé-Vilanova 977 Technical University of Catalonia 978 Barcelona 979 Spain 981 Email: jordip@ac.upc.edu 983 Dino Farinacci 984 lispers.net 985 San Jose, CA 986 USA 988 Email: farinacci@gmail.com