idnits 2.17.1 draft-ietf-lisp-nexagon-36.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2022) is 670 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 R. Tamir 4 Expires: September 10, 2022 Nexar Inc. 5 A. Rodriguez-Natal 6 F. Maino 7 Cisco Systems 8 A. Cabellos-Aparicio 9 J. Paillisse Vilanova 10 Technical University of Catalonia 11 D. Farinacci 12 lispers.net 13 June 26, 2022 15 Network-Hexagons:Geolocation Mobility Edge Network Based On H3 and LISP 16 draft-ietf-lisp-nexagon-36 18 Abstract 20 This informational document describes the combination of LISP and the 21 H3 geospatial hierarchical grid forming a Geolocation mobility edge 22 network. When vehicles with AI cameras detect objects of interest 23 on the road, they use their GPS to calculate their high-resolution 24 grid-tile position. They then use this tile to calculate the 25 high-resolution tile of the detection. The low-resolution (big) 26 grid-tile containing the detection tile identifier is used as basis to 27 IPv6 LISP endpoint identifier (EID). This EID is the queue destination 28 of Geolocation process consolidating detections form all vehicles in 29 that area. Geolocation processes use their EID as source of channels 30 consolidating per theme of all ongoing road situations in their area. 31 Vehicles driving or navigating to an area subscribe to these channels. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 10, 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 67 3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 7 68 4. Mobility Clients-Services Networking . . . . . . . . . . . . 8 69 5. Mobility Unicast and Multicast . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 10. Normative References . . . . . . . . . . . . . . . . . . . . 28 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 77 1. Introduction 79 This informational document describes the combination of LISP and the 80 H3 geospatial hierarchical grid forming a Geolocation mobility edge 81 network. When vehicles with AI cameras detect objects of interest 82 on the road, they use their GPS to calculate their high-resolution 83 grid-tile position. They then use this tile to calculate the 84 high-resolution tile of the detection. The low-resolution (big) 85 grid-tile containing the detection tile identifier is used as basis to 86 IPv6 LISP endpoint identifier (EID). This EID is the queue destination 87 of Geolocation process consolidating detections form all vehicles in 88 that area. Geolocation processes use their EID as source of channels 89 consolidating per theme of all ongoing road situations in their area. 90 Vehicles driving or navigating to an area subscribe to these channels. 92 Geolocation processes are delegated dynamically to compute locations 93 according road activity in their area. This services dynamics combined 94 with clients' IP Anchor dynamics causes key-issues resolved by LISP: 96 - Coherency of Geolocation processes' IPs cached by vehicle clients 97 - Context-switching between Geolocation processes per driving client 98 - Geo-privacy and tracking of clients interacting with geo-processes 99 - Client subscription continuity switching IP Anchors while driving 100 Resolving these key-issues is achievable by address virtualization: 102 - Addresses virtualization for clients and services communicating 103 - Algorithmic services addressing based on geospatial grid identifiers 104 - Algorithmic clients addressing based on an authorization procedure 106 Virtual addressing based on LISP EIDs is applied to Geolocation: 108 - Addressable queues for uploads from mobility clients 109 - Addressable channels for subscribed mobility clients 111 In addition to queues and channels Geolocations Services include 112 application state and functions. Functions are available in all 113 compute locations, geospatial-situation state regenerates. 114 ___ 115 / \ 116 Addressable >> State >> Addressable 117 Upload Queues \ ___ / Channels 118 /\ Functions() \/ 120 Figure 1: Geolocation schematics: queues, channels, states, functions 122 Address virtualization based on LISP EIDs includes: 124 - EID addressing of Geolocation queues based on H3 identifiers 125 - EID addressing of detection channels, H3-ID sources and topics 126 - EID addressing of mobility clients, assigned-renewed periodically 128 Service EIDs enable portability of Geolocation queues and channels. 129 Client EIDs enable channel-subscription continuity, for when mobile 130 cellular or wifi carriers are switched for reception or other reasons. 131 Client EIDs are temporary and make it difficult to track by services. 133 EIDs, geospatial-service and temporary-clients, allow for dynamic and 134 portable service allocation, algorithmic context switching between 135 processes while driving, subscription continuity, and IP geo-privacy. 137 Note 1: The breakdown of Geolocations Services to processes is done 138 based on geospatial grid lines known to both mobility clients and 139 Geolocation Services. We use H3 [H3] hierarchical hexagonal grid 140 because of its clear tile adjacency properties. Each grid-tile 141 in each resolution has a unique 64bit identifier (HID). HIDs are 142 mapped to EIDs algorithmically. In addition to shards, the same grid 143 at higher resolution (smaller tiles) is used to localize detections. 144 We refer to h3.rB as the lower resolution shard big tile, and h3.rS as 145 the detection location, higher resolution small tile. 147 Mappings: GPS => h3.rS => H3.rB => EID are therefore algorithmic. 148 Sizeof (h3.rB) / Sizeof (h3.rS) x density-factor / MTU ~ number of 149 messages needed to convey big-tile shard a snapshot of small-tiles. 151 Off-Peak Allocation 152 Packed on less compute 153 _ _ _ _ 154 / \/ \ / \/ \ ---- 155 \_/\_/ \_/\_/ ---- Peak Geolocation Allocation 156 / \/ \ / \/ \ ---- Geospatial shards spread on more compute 157 \_/\_/ \_/\_/ ---- _ _ _ _ _ _ _ _ 158 / \/ \ / \/ \ ---- / \/ \ / \/ \ / \/ \ / \/ \ ---- 159 \_/\_/ \_/\_/ ---- \_/\_/ \_/\_/ \_/\_/ \_/\_/ ---- 160 / \/ \ / \/ \ ---- / \/ \ / \/ \ / \/ \ / \/ \ ---- 161 \_/\_/ \_/\_/ ---- \_/\_/ \_/\_/ \_/\_/ \_/\_/ ---- 162 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 163 Site Site Standby Site Site Site Site Standby 165 Figure 2: Geolocation dynamic allocation per geospatial activity 167 Note 2: LISP solution for address virtualization is an application 168 network. In order for clients and services to use it there needs to be 169 a formal provisioning step. For the clients this step will require 170 Authentication Authorization and Accounting (AAA) procedure by which 171 clients are assigned and renew EIDs and XTRs to be used to interact 172 with services. This process may be done in various vendor specific 173 methods, or multivendor AAA service. AAA procedure is described as 174 a life-cycle example. 176 Note 3: In order to make the notion of geospatial detection concrete, 177 we add to the 64bit HID of "where" is a detection, 64bit of "what" is 178 the detection or situation. These 64bits are detailed in a bit-mask 179 based on a taxonomy defined by Berkeley Deep Drive [BDD]. It is meant 180 as a baseline that can be extended or overridden depending on need. 182 2. Definition of Terms 184 Based on [I-D.ietf-lisp-rfc6830bis][I-D.ietf-lisp-rfc6833bis] 186 H3ServiceEID: Is an EID addressable Geolocation Service shard. 187 It is a designated destination for geospatial detections, 188 and an (S,G) source of multicast of themed detection channels. 189 It has a light-weight LISP protocol stack to tunnel packets 190 via ServerXTR. The EID is IPv6 and contains HID in the lower bits. 192 ServerXTR: Is a data-plane only LISP protocol stack implementation, it 193 is co-located with H3ServiceEID process. ServerXTR encapsulates and 194 decapsulates packets to and from EdgeRTRs. 196 MobilityClient: Is an application that may be a part of a vehicle 197 system, part of a navigation application, gov-muni application etc. 198 It has light-weight LISP data-plane stack to packets via ClientXTR. 200 MobilityClientEID: Is the IPv6 EID used by the Mobility Clients. 201 The destination of such packets are H3ServiceEIDs. The EID format 202 is assigned as part of the MobilityClient mobility-network AAA. 204 ClientXTR: Is a data-plane only LISP protocol stack implementation 205 co-located with the Mobility Client application. It encapsulates 206 and decapsulates packets to and from EdgeRTRs. 208 EdgeRTR: EdgeRTR network connects MobilityClients to H3ServiceEIDs. 209 EdgeRTRs manage MobilityClients multicast registrations [RFC8378]. 210 EdgeRTRs aggregate MobilityClients/H3Services using tunnels to 211 facilitate hosting-providers and mobile-providers in accessing the 212 LISP based Geolocation mobility-network. 213 EdgeRTRs decapsulate packets from ClientXTRs and ServerXTRs, 214 and re-encapsulates packets to clients and servers. 215 EdgeRTRs glean H3ServiceEIDs and MobilityClient EIDs when 216 they decapsulates packets. EdgeRTRs store H3ServiceEIDs and route- 217 locations (RLOC) using map-caches. Mappings are registered to the 218 LISP mapping system [I-D.ietf-lisp-rfc6833bis]. Mappings may be 219 provisioned when H3Services are assigned EdgeRTRs. EdgeRTRs do not 220 register MobilityClients' EIDs. 221 Enterprises may provide their own EdgeRTRs to protect geo-privacy. 223 h3.rB routed-shards grid tiles 224 ___ ___ 225 H3ServiceEIDs ___ / \ H3ServiceEIDs ___ / \ 226 ___ / | h3.rB | ___ / | h3.rB | 227 / | h3.rB \ ___ / / | h3.rB \ ___ / 228 | h3.rB \ ___ / sXTR | h3.rB \ ___ / sXTR 229 \ ___ / sXTR || \ ___ / sXTR || 230 sXTR || || sXTR || || 231 || || || || || || 232 || || || || || || 233 = = = = = = EdgeRTR EdgeRTR = = = = = 234 || (( () )) || 235 ( Geolocation ) 236 ( Mobility Network ) 237 ( Based on LISP ) 238 ( || (( (()) () || ) 239 || || 240 = = = = = = = = = = = = = = 241 || || 242 EdgeRTR EdgeRTR 243 .. .. .. .. 244 .. .. .. .. 245 ((((|)))) ((((|)))) ((((|)))) ((((|)))) 246 /|\ RAN /|\ /|\ RAN /|\ 247 || || 248 || || 249 Uploads Upstream || 250 Channels Downstream || 251 || ___ ___ ___ || 252 || << movment << / \/ \/ \<> \ ___ /\ ___ / >> movement >> ....... 256 Figure 3: Geolocation clients and services interaction layout 258 Figure 3 above describes: 260 - MobilityClientA detections used by MobilityClientB, and vice versa 261 - Clients: share information only via Geolocation Services 263 - ClientXTR (cXTR):encapsulates packets over access network to EdgeRTR 264 - ServerXTR (sXTR):encapsulates packets over edge network to EdgeRTR 266 - Uploads: routed to appropriate Geolocation Service by EdgeRTRs 267 - Channels: originate from Geolocation Services replicated by EdgeRTRs 269 3. Deployment Assumptions 271 I. We assume detections can be localized to h3.rS tiles and can be 272 enumerated. Compact detection enumeration format is described bellow: 274 0 1 2 3 4 5 6 7 275 +-------+-------+-------+-------+-------+-------+-------+-------+ 276 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 277 |012301230123012301230123 Index 01230123012301230123012301230123 278 +---------------------------------------------------------------+ 280 Figure 4: Nibble based compact representation of tile detection state 282 Detections are in 16 fields x 16 enumerations. Nibbles are named using 283 hexadecimal index according to the position where the most significant 284 nibble has index 0. Values based on [BDD] are defined in section 8. 286 II. Authorization of MobilityClients to mobility-network is renewed 287 while driving. DNS/AAA procedure described bellow can be used as an 288 example to obtain EIDs/EdgeRTRs and for enabling use of the network. 289 Diameter [RFC6733] based AAA can be used to accommodate many types 290 of mobility clients in a rich eco-system: vehicle systems, driving 291 and navigation applications, smart-city and consumer applications. 292 Example procedure for ClientXTRs to use the mobility-network: 294 1) obtain the address of the mobility-network AAA using DNS 295 2) obtain MobilityClientEIDs and EdgeRTRs from AAA procedure 296 3) renewed periodically from AAA while using the network 298 MobilityClient DomainNameServer AAA Server MobilityEdgeRTR 299 | | | | 300 | lookup AAA Server | | | 301 |------------------->| | | 302 |<-------------------| | | 303 | AAA Server IP | | | 304 | | | | 305 | Client identifier and credentials | | 306 |--------------------------------------->| | 307 | | |Provision Client EID| 308 | | |------------------->| 309 | | |<-------------------| 310 | | | Ack Provisioed EID | 311 | Send ClientEID,EdgeRTR RLOC | | 312 |<---------------------------------------| | 313 . . 314 . Use The H3-LISP Geolocation Mobility Network . 315 . . 316 |<----------------------------------------------------------->| 317 . . 318 . Renew AAA ClientEID and EdgeRTR provisioning . 320 Figure 5: Example exchange for mobility-network usage 322 4. Mobility Clients-Services Networking 324 The mobility-network functions as a standard LISP overlay. 325 The overlay delivers unicast and multicast packets across: 326 Data-plane XTRs are used in the stack of each mobility client/server. 327 ClientXTRs and ServerXTRs are associated with EdgeRTRs. 329 This structure allows for MobilityClients to "show up" at any of 330 mobility-network location behind any network provider or network 331 address translation domain. It allows for any H3ServiceEID to be 332 instantiated, delegated, or failed-over to any compute location. 334 In this specification we assume semi-random association between 335 ClientXTRs and EdgeRTRs - assigned in AAA procedure. We assume in 336 any given metro area a pool of EdgeRTRs to distribute the Mobility 337 Clients load. We assume EdgeRTRs are topologically equivalent. 338 EdgeRTRs use LISP to encapsulate traffic to and from other EdgeRTRs. 340 MobilityClient == ClientXTR ClientXTR == MobilityClient 341 (Encryption and Decryption) || || (Encryption and Decryption) 342 || || 343 EdgeRTR X EdgeRTR 344 || || 345 (Encryption and Decryption) || || (Encryption and Decryption) 346 H3ServiceEID == ServerXTR ServerXTR == H3ServiceEID 348 Figure 6: LISP network connecting MobilityClients and H3ServiceEIDs 350 Note: there may be more than one ClientEID in the same process using the 351 same ClientXTR. For example multiple layers of map or heads-up display. 352 Such vendor specific multiplexing implementation is unspecified here. 354 5. Mobility Unicast and Multicast 356 The day in a life of unicast detection upload: 358 1. A client detects condition of interest using AI camera 359 2. The client uses its GPS to establish its h3.rS location 360 3. It then estimates the h3.rS location of the detection 361 4. Detection h3.rS is used to calculate h3.rB => H3ServerEID 362 5. Client sends (encrypted) location-detection via its ClientXTR 364 Outer Header src/dest: ClientXTR RLOC, EdgeRTR RLOC 365 Inner Header src/dest: ClientEID, H3ServiceEID 367 6. EdgeRTR gleans and caches ClientEID and ClientXTR RLOC 368 7. EdgeRTR resolves RLOC of remote EdgeRTR, and re-tunnels: 370 Outer Header src/dest: EdgeRTR RLOC, remote EdgeRTR RLOC 371 Inner Header src/dest: ClientEID, H3ServiceEID 373 8. Remote EdgeRTR lookups H3ServerEID ServerXTR RLOC, re-tunnels: 375 Outer Header src/dest: EdgeRTR RLOC, ServerXTR RLOC 376 Inner Header src/dest: ClientEID, H3ServiceEID 378 9. ServerXTR delivers ClientEID message to H3ServiceEID 380 The detection message headers consist of the following fields: 382 - Outer headers size = 40 (IPv6) + 8 (UDP) + 8 (LISP) = 56 383 - Inner headers size = 40 (IPv6) + 8 (UDP) + 4 (Nexagon Header) = 52 384 - 1500 (MTU) - 56 - 52 = 1392 bytes of effective payload size 386 Nexagon Header allows for key-value (kv) tuples or value-key,key 387 ..(vkkk) using the same formats of key and value outlined bellow 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 390 | Type |gzip | Reserved | Pair Count = X|Nexagon 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 393 Figure 7: Nexagon header format 395 Nexagon Header Type 0:reserved (*) 396 Type 1:key-value, key-value.. 1392 / (8 + 8) = 87 pairs 397 Type 2:value, key,key,key.. (1392 - 8) / 8 = 173 h3.rS IDs 398 Type 3-255: unassigned 399 Nexagon Header GZIP field: 0x000 no compression, or (**) GZIP version. 400 Nexagon Header Reserved bits 401 Nexagon Header key and value count (in any format kv or vkkk) 403 (*) Reserved fields are specified as being set to 0 on transmission, 404 ignored when received. 405 (**) GZIP refers to entire kv or vkkk payload and major GZIP version, 406 packets with unsupported GZIP version are dropped 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 411 |Version| Traffic Class | Flow Label | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 413 | Payload Length | Next Header | Hop Limit | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 415 | | | 416 + + | 417 | | | 418 + Source MobilityClientEID + | 419 | | IPv6 420 + + | 421 | | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 423 | | | 424 + + | 425 | | | 426 + Dest H3ServiceEID + | 427 | | | 428 + + | 429 | | / 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Source Port = xxxx | Dest Port = xxxx | \ 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 433 | UDP Length | UDP Checksum | / 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 435 | Type |gzip | Reserved | Pair Count = X|Nexagon 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 437 | | 438 + 64bit h3.rS ID + 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | | 442 + 64bit State + 443 | | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | | 446 + 64bit h3.rS ID + 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 + 64bit State + 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Figure 8: Uploaded detections packet format 456 Each H3Service is also an IP Multicast Source used to update 457 subscribers on the state of the h3.rS tiles in the h3.rB area. 458 We use [RFC8378] signal-free multicast to implement overlay channels. 459 Mobility-networks have many channels with thousands subscribers each. 460 MobilityClients driving through/subscribing to an h3.rB area issue 461 group address report based on any mechanism supported by [RFC8378]. 462 Example report formats are specified in [RFC4604]. 463 Report messages are encapsulated between ClientXTRs and EdgeRTRs. 465 The day in a life of multicast update: 467 1. H3ServiceEID determines change or timing requiring an update 468 2. H3ServiceEID sends (S,G) update message via its ServerXTR 470 Outer Header src/dest: ServerXTR RLOC, EdgeRTR RLOC 471 Inner Header (S,G): H3ServerEID, EID chosen for theme 473 3. EdgeRTR resolves subscribed remote EdgeRTRs, replicates 475 Outer Header src/dest: EdgeRTR RLOC, remote EdgeRTR RLOC 476 Inner Header (S,G): H3ServerEID, EID chosen for theme 478 4. EdgeRTRs lookups subscribed ClientEIDs ClientXTRs RLOCs, replicates 480 Outer Header src/dest: EdgeRTR RLOC, ClientXTR RLOC 481 Inner Header (S,G): H3ServerEID, EID chosen for theme 483 5. ClientXTR delivers multicast channel update message to clientEID 484 Multicast update packets are of the following structure: 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 489 |Version| Traffic Class | Flow Label | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 491 | Payload Length | Next Header | Hop Limit | | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 493 | | | 494 + + | 495 | | | 496 + Source H3ServiceEID + | 497 | | IPv6 498 + + | 499 | | | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 501 | | | 502 + + | 503 | | | 504 + Group Address + | 505 | | | 506 + + | 507 | | / 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Source Port = xxxx | Dest Port = xxxx | \ 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 511 | UDP Length | UDP Checksum | / 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 513 | |Nexagon 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 515 ~ Nexagons Payload ~ 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Figure 9: multicast update packet header 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 | Type = 1 |gzip | Reserved | Pair Count = X|Nexagon 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 525 | | 526 + 64bit h3.rS ID + 527 | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | | 530 + 64bit State + 531 | | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | | 534 + 64bit h3.rS ID + 535 | | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | | 538 + 64bit State + 539 | | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Figure 10: multicast update payload, key-value, key-value.. 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 547 | Type = 2 |gzip | Reserved |H3R15 Count = X|Nexagon 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 549 | | 550 + 64bit State + 551 | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | | 554 + 64bit h3.rS ID + 555 | | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | | 558 + 64bit h3.rS ID + 559 | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | | 562 + 64bit h3.rS ID + 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 11: multicast update payload, value, key, key.. for larger areas 568 6. Security Considerations 570 The LISP mobility-network is inherently secure and private. 571 All information is conveyed to clients using provisioned Geolocation 572 Services. MobilityClients receive information only via geospatial 573 channels originating at provisioned services, replicated by EdgeRTRs. 575 7. Privacy Considerations 577 MobilityClients have no indication as to the origin of the raw data. 578 In order to be able to use the mobility-network for a given period, 579 the mobility clients go through a DNS/AAA stage by which they obtain 580 temporary clientEID and RLOCs of EdgeRTRs. 582 This MobilityClient to EdgeRTR interface is the most sensitive from 583 privacy perspective. The traffic on this interface is tunneled, its 584 detection content may be encrypted between ClientXTR to EdgeRTR. 585 Still, the EdgeRTR will know based on headers the client RLOC, and 586 the h3.rB area a client engages with. 588 Enterprises such as vehicle OEMs or carriers can "bring their own" 589 EdgeRTRs (BYO_RTR). BYO_RTRs are pre-provisioned to be able to use the 590 mapping system and are put on the approved list of the other EdgeRTRs. 591 A carrier offering EdgeRTR services on multiaccess edge compute (MEC) 592 is optimal for security and for traffic steering-replication. 594 Beyond client to EdgeRTR hop, the mapping system does not hold 595 MobilityClientEIDs info. Remote EdgeRTRs are only aware of clients 596 temporary EIDs. When EdgeRTRs register in the mapping for channels, 597 they do not register which clients use which EdgeRTR. 599 The H3ServiceEIDs decrypt and parse actual h3.rS detections. They also 600 consider MobilityClientEID credentials encoded in the client EID and 601 assigned by AAA. This helps avoid "fake-news", e.g. poorly made or 602 poorly localized detections. 604 In summary the privacy risk mitigations are: 606 (1) tapping: all communications are through tunnels therefore 607 may be encrypted using IP-Sec or other supported point to point 608 underlay standards. 610 (2) spoofing: it is very hard to guess a MobilityClientEID valid for 611 a short period of time. Clients and H3Services EIDs are provisioned 612 in EdgeRTRs, Clients using the AAA procedure, H3Services via dev-ops. 614 (3) credibility: the interface crowd-sources geo-state and does not 615 assume to trust single detections. Credit history track to 616 MobilityClientEIDs by as part of normal H3Services fact checking, 617 aggregate scores affect AAA credentials. 619 (4) geo-privacy: Only EdgeRTRs are aware of both clients' RLOC and 620 geo-location, only AAA is aware of client IDs credentials and credit 621 but not geo-location. Ongoing client credit score adjustments can span 622 all H3Services administratively to AAA without specific geo-source. 624 7. Acknowledgments 626 We would like to kindly thank Joel Halperin for helping structure the 627 AAA section and Geo-Privacy provisions, Luigi Lannone for promoting 628 such LISP Compute First Networking (CFN) use-cases, helping structure 629 the IANA section, and shepherding this draft to completion. We would 630 like to thank George Ericson for help clarifying Geolocation Services 631 terminology through joint work on the AECC specifications and papers, 632 and Lei Zhong for mobility dataflow virtualization terminology. 634 8. IANA Considerations 636 This section provides guidance to the Internet Assigned Numbers 637 Authority (IANA) regarding registration of values related to the LISP 638 specification, in accordance with BCP 26 [RFC8126]. 639 IANA is asked to create a registry named NEXAGON Parameters. 640 Such registry should be populated with the following sub registries. 642 Nexagon Header Bits 643 +----------+------------------+----------+---------------------------+ 644 | Spec | IANA Name | Bit | Description | 645 | Name | | Position | | 646 +----------+------------------+----------+---------------------------+ 647 | Type | nexagon-type | 0-7 | Type of key-value encoding| 648 | gzip | nexagon-gzip | 8-10 | gzip major version used | 649 | PairCount| nexagon-paircount| 24-31 | key-value pair count | 650 +----------+------------------+----------+---------------------------+ 652 State Enumeration Field 0x0: Traffic Direction: 653 +-------+--------------------+-----------------+ 654 | Value | Description | Reference | 655 +-------+--------------------+-----------------+ 656 | 0x0 | Null | [This Document] | 657 | | | | 658 | 0x1 | Lane North | [This Document] | 659 | | | | 660 | 0x2 | Lane North + 30 | [This Document] | 661 | | | | 662 | 0x3 | Lane North + 60 | [This Document] | 663 | | | | 664 | 0x4 | Lane North + 90 | [This Document] | 665 | | | | 666 | 0x5 | Lane North + 120 | [This Document] | 667 | | | | 668 | 0x6 | Lane North + 150 | [This Document] | 669 | | | | 670 | 0x7 | Lane North + 180 | [This Document] | 671 | | | | 672 | 0x8 | Lane North + 210 | [This Document] | 673 | | | | 674 | 0x9 | Lane North + 240 | [This Document] | 675 | | | | 676 | 0xA | Lane North + 270 | [This Document] | 677 | | | | 678 | 0xB | Lane North + 300 | [This Document] | 679 | | | | 680 | 0xC | Lane North + 330 | [This Document] | 681 | | | | 682 | 0xD | Junction | [This Document] | 683 | | | | 684 | 0xE | Shoulder | [This Document] | 685 | | | | 686 | 0xF | Sidewalk | [This Document] | 687 +-------+--------------------+-----------------+ 688 State Enumeration Field 0x1: Persistent Condition: 689 +-------+--------------------+-----------------+ 690 | Value | Description | Reference | 691 +-------+--------------------+-----------------+ 692 | 0x0 | Null | [This Document] | 693 | | | | 694 | 0x1 | Pothole Light | [This Document] | 695 | | | | 696 | 0x2 | Pothole Deep | [This Document] | 697 | | | | 698 | 0x3 | Speed-bump Low | [This Document] | 699 | | | | 700 | 0x4 | Speed-bump High | [This Document] | 701 | | | | 702 | 0x5 | Icy | [This Document] | 703 | | | | 704 | 0x6 | Flooded | [This Document] | 705 | | | | 706 | 0x7 | Snow-cover | [This Document] | 707 | | | | 708 | 0x8 | Deep Snow | [This Document] | 709 | | | | 710 | 0x9 | Cone | [This Document] | 711 | | | | 712 | 0xA | Gravel | [This Document] | 713 | | | | 714 | 0xB | Choppy | [This Document] | 715 | | | | 716 | 0xC | Blind-Curve | [This Document] | 717 | | | | 718 | 0xD | Steep | [This Document] | 719 | | | | 720 | 0xE | Low-bridge | [This Document] | 721 | | | | 722 | 0xF | Other | [This Document] | 723 +-------+--------------------+-----------------+ 724 State Enumeration Field 0x2: Transient Condition: 725 +-------+--------------------+-----------------+ 726 | Value | Description | Reference | 727 +-------+--------------------+-----------------+ 728 | 0x0 | Null | [This Document] | 729 | | | | 730 | 0x1 | Jaywalker | [This Document] | 731 | | | | 732 | 0x2 | Bike or Scooter | [This Document] | 733 | | | | 734 | 0x3 | Stopped Vehicle | [This Document] | 735 | | | | 736 | 0x4 | Moving on Shoulder | [This Document] | 737 | | | | 738 | 0x5 | First Responder | [This Document] | 739 | | | | 740 | 0x6 | Sudden Slowdown | [This Document] | 741 | | | | 742 | 0x7 | Oversize Vehicle | [This Document] | 743 | | | | 744 | 0x8 | Light/Sign Breach | [This Document] | 745 | | | | 746 | 0x9 | Collision Light | [This Document] | 747 | | | | 748 | 0xA | Collision Severe | [This Document] | 749 | | | | 750 | 0xB | Collision Debris | [This Document] | 751 | | | | 752 | 0xC | Collision Course | [This Document] | 753 | | | | 754 | 0xD | Vehicle Hard Brake | [This Document] | 755 | | | | 756 | 0xE | Vehicle Sharp Turn | [This Document] | 757 | | | | 758 | 0xF | Freed-up Parking | [This Document] | 759 +-------+--------------------+-----------------+ 760 State Enumeration Field 0x3: Traffic-light Counter: 761 +-------+--------------------+-----------------+ 762 | Value | Description | Reference | 763 +-------+--------------------+-----------------+ 764 | 0x0 | Null | [This Document] | 765 | | | | 766 | 0x1 | 1 Second to Green | [This Document] | 767 | | | | 768 | 0x2 | 2 Second to Green | [This Document] | 769 | | | | 770 | 0x3 | 3 Second to Green | [This Document] | 771 | | | | 772 | 0x4 | 4 Second to Green | [This Document] | 773 | | | | 774 | 0x5 | 5 Second to Green | [This Document] | 775 | | | | 776 | 0x6 | 6 Second to Green | [This Document] | 777 | | | | 778 | 0x7 | 7 Second to Green | [This Document] | 779 | | | | 780 | 0x8 | 8 Second to Green | [This Document] | 781 | | | | 782 | 0x9 | 9 Second to Green | [This Document] | 783 | | | | 784 | 0xA | 10 Second to Green | [This Document] | 785 | | | | 786 | 0xB | 20 Second to Green | [This Document] | 787 | | | | 788 | 0xC | 30 Second to Green | [This Document] | 789 | | | | 790 | 0xD | 60 Second to Green | [This Document] | 791 | | | | 792 | 0xE | Green Now | [This Document] | 793 | | | | 794 | 0xF | Red Now | [This Document] | 795 +-------+--------------------+-----------------+ 796 State Enumeration Field 0x4: Impacted Tile: 797 +-------+--------------------+-----------------+ 798 | Value | Description | Reference | 799 +-------+--------------------+-----------------+ 800 | 0x0 | Null | [This Document] | 801 | | | | 802 | 0x1 | Epicenter | [This Document] | 803 | | | | 804 | 0x2 | 2 Tiles Away | [This Document] | 805 | | | | 806 | 0x3 | 3 Tiles Away | [This Document] | 807 | | | | 808 | 0x4 | 4 Tiles Away | [This Document] | 809 | | | | 810 | 0x5 | 5 Tiles Away | [This Document] | 811 | | | | 812 | 0x6 | 6 Tiles Away | [This Document] | 813 | | | | 814 | 0x7 | 7 Tiles Away | [This Document] | 815 | | | | 816 | 0x8 | 8 Tiles Away | [This Document] | 817 | | | | 818 | 0x9 | 9 Tiles Away | [This Document] | 819 | | | | 820 | 0xA | 10 Tiles Away | [This Document] | 821 | | | | 822 | 0xB | 20 Tiles Away | [This Document] | 823 | | | | 824 | 0xC | 30 Tiles Away | [This Document] | 825 | | | | 826 | 0xD | 60 Tiles Away | [This Document] | 827 | | | | 828 | 0xE | <100 Tiles Away | [This Document] | 829 | | | | 830 | 0xF | <200 Tiles Away | [This Document] | 831 +-------+--------------------+-----------------+ 832 State Enumeration Field 0x5: Expected Duration: 833 +-------+--------------------+-----------------+ 834 | Value | Description | Reference | 835 +-------+--------------------+-----------------+ 836 | 0x0 | Null | [This Document] | 837 | | | | 838 | 0x1 | Next 1 Second | [This Document] | 839 | | | | 840 | 0x2 | Next 5 Seconds | [This Document] | 841 | | | | 842 | 0x3 | Next 10 Seconds | [This Document] | 843 | | | | 844 | 0x4 | Next 20 Seconds | [This Document] | 845 | | | | 846 | 0x5 | Next 40 Seconds | [This Document] | 847 | | | | 848 | 0x6 | Next 60 Seconds | [This Document] | 849 | | | | 850 | 0x7 | Next 2 Minutes | [This Document] | 851 | | | | 852 | 0x8 | Next 3 Minutes | [This Document] | 853 | | | | 854 | 0x9 | Next 4 Minutes | [This Document] | 855 | | | | 856 | 0xA | Next 5 Minutes | [This Document] | 857 | | | | 858 | 0xB | Next 10 Minutes | [This Document] | 859 | | | | 860 | 0xC | Next 15 Minutes | [This Document] | 861 | | | | 862 | 0xD | Next 30 Minutes | [This Document] | 863 | | | | 864 | 0xE | Next 60 Minutes | [This Document] | 865 | | | | 866 | 0xF | Next 24 Hours | [This Document] | 867 +-------+--------------------+-----------------+ 868 State Enumeration Field 0x6: Lane Right Sign: 869 +-------+--------------------+-----------------+ 870 | Value | Description | Reference | 871 +-------+--------------------+-----------------+ 872 | 0x0 | Null | [This Document] | 873 | | | | 874 | 0x1 | Yield | [This Document] | 875 | | | | 876 | 0x2 | Speed Limit | [This Document] | 877 | | | | 878 | 0x3 | Straight Only | [This Document] | 879 | | | | 880 | 0x4 | No Straight | [This Document] | 881 | | | | 882 | 0x5 | Right Only | [This Document] | 883 | | | | 884 | 0x6 | No Right | [This Document] | 885 | | | | 886 | 0x7 | Left Only | [This Document] | 887 | | | | 888 | 0x8 | No Left | [This Document] | 889 | | | | 890 | 0x9 | Right Straight | [This Document] | 891 | | | | 892 | 0xA | Left Straight | [This Document] | 893 | | | | 894 | 0xB | No U Turn | [This Document] | 895 | | | | 896 | 0xC | No Left or U | [This Document] | 897 | | | | 898 | 0xD | Bike Lane | [This Document] | 899 | | | | 900 | 0xE | HOV Lane | [This Document] | 901 | | | | 902 | 0xF | Stop | [This Document] | 903 +-------+--------------------+-----------------+ 904 State Enumeration Field 0x7: Movement Sign: 905 +-------+--------------------+-----------------+ 906 | Value | Description | Reference | 907 +-------+--------------------+-----------------+ 908 | 0x0 | Null | [This Document] | 909 | | | | 910 | 0x1 | Keep Right | [This Document] | 911 | | | | 912 | 0x2 | Keep Left | [This Document] | 913 | | | | 914 | 0x3 | Stay in Lane | [This Document] | 915 | | | | 916 | 0x4 | Do Not Enter | [This Document] | 917 | | | | 918 | 0x5 | No Trucks | [This Document] | 919 | | | | 920 | 0x6 | No Bikes | [This Document] | 921 | | | | 922 | 0x7 | No Peds | [This Document] | 923 | | | | 924 | 0x8 | One Way | [This Document] | 925 | | | | 926 | 0x9 | Parking | [This Document] | 927 | | | | 928 | 0xA | No Parking | [This Document] | 929 | | | | 930 | 0xB | No Standing | [This Document] | 931 | | | | 932 | 0xC | No Passing | [This Document] | 933 | | | | 934 | 0xD | Loading Zone | [This Document] | 935 | | | | 936 | 0xE | Rail Crossing | [This Document] | 937 | | | | 938 | 0xF | School Zone | [This Document] | 939 +-------+--------------------+-----------------+ 940 State Enumeration Field 0x8: Curves & Intersections: 941 +-------+--------------------+-----------------+ 942 | Value | Description | Reference | 943 +-------+--------------------+-----------------+ 944 | 0x0 | Null | [This Document] | 945 | | | | 946 | 0x1 | Turns Left | [This Document] | 947 | | | | 948 | 0x2 | Turns Right | [This Document] | 949 | | | | 950 | 0x3 | Curves Left | [This Document] | 951 | | | | 952 | 0x4 | Curves Right | [This Document] | 953 | | | | 954 | 0x5 | Reverses Left | [This Document] | 955 | | | | 956 | 0x6 | Reverses Right | [This Document] | 957 | | | | 958 | 0x7 | Winding Road | [This Document] | 959 | | | | 960 | 0x8 | Hair Pin | [This Document] | 961 | | | | 962 | 0x9 | Pretzel Turn | [This Document] | 963 | | | | 964 | 0xA | Cross Roads | [This Document] | 965 | | | | 966 | 0xB | Cross T | [This Document] | 967 | | | | 968 | 0xC | Cross Y | [This Document] | 969 | | | | 970 | 0xD | Circle | [This Document] | 971 | | | | 972 | 0xE | Lane Ends | [This Document] | 973 | | | | 974 | 0xF | Road Narrows | [This Document] | 975 +-------+--------------------+-----------------+ 976 State Enumeration Field 0x9: Tile Traffic Speed: 977 +-------+--------------------+-----------------+ 978 | Value | Description | Reference | 979 +-------+--------------------+-----------------+ 980 | 0x0 | Null | [This Document] | 981 | | | | 982 | 0x1 | < 1 m/sec | [This Document] | 983 | | | | 984 | 0x2 | < 2 m/sec | [This Document] | 985 | | | | 986 | 0x3 | < 3 m/sec | [This Document] | 987 | | | | 988 | 0x4 | < 4 m/sec | [This Document] | 989 | | | | 990 | 0x5 | < 5 m/sec | [This Document] | 991 | | | | 992 | 0x6 | < 6 m/sec | [This Document] | 993 | | | | 994 | 0x7 | < 7 m/sec | [This Document] | 995 | | | | 996 | 0x8 | < 8 m/sec | [This Document] | 997 | | | | 998 | 0x9 | < 9 m/sec | [This Document] | 999 | | | | 1000 | 0xA | < 10 m/sec | [This Document] | 1001 | | | | 1002 | 0xB | < 20 m/sec | [This Document] | 1003 | | | | 1004 | 0xC | < 30 m/sec | [This Document] | 1005 | | | | 1006 | 0xD | < 40 m/sec | [This Document] | 1007 | | | | 1008 | 0xE | < 50 m/sec | [This Document] | 1009 | | | | 1010 | 0xF | > 50 m/sec | [This Document] | 1011 +-------+--------------------+-----------------+ 1012 State Enumeration Field 0xA: Pedestrian Curb Density: 1013 +-------+--------------------+-----------------+ 1014 | Value | Description | Reference | 1015 +-------+--------------------+-----------------+ 1016 | 0x0 | Null | [This Document] | 1017 | | | | 1018 | 0x1 | 100% | [This Document] | 1019 | | | | 1020 | 0x2 | 95% | [This Document] | 1021 | | | | 1022 | 0x3 | 90% | [This Document] | 1023 | | | | 1024 | 0x4 | 85% | [This Document] | 1025 | | | | 1026 | 0x5 | 80% | [This Document] | 1027 | | | | 1028 | 0x6 | 70% | [This Document] | 1029 | | | | 1030 | 0x7 | 60% | [This Document] | 1031 | | | | 1032 | 0x8 | 50% | [This Document] | 1033 | | | | 1034 | 0x9 | 40% | [This Document] | 1035 | | | | 1036 | 0xA | 30% | [This Document] | 1037 | | | | 1038 | 0xB | 20% | [This Document] | 1039 | | | | 1040 | 0xC | 15% | [This Document] | 1041 | | | | 1042 | 0xD | 10% | [This Document] | 1043 | | | | 1044 | 0xE | 5% | [This Document] | 1045 | | | | 1046 | 0xF | No Peds | [This Document] | 1047 +-------+--------------------+-----------------+ 1049 State enumeration fields 0xB, 0xC, 0xD, 0xE, 0xF, are unassigned. 1050 IANA can assign them on a "First Come First Served" basis 1051 according to [RFC8126]. 1053 9. Normative References 1055 [I-D.ietf-lisp-rfc6830bis] 1056 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1057 Cabellos-Aparicio, "The Locator/ID Separation Protocol 1058 (LISP)", draft-ietf-lisp-rfc6830bis-38 (work in progress), 1059 May 2020. 1061 [I-D.ietf-lisp-rfc6833bis] 1062 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 1063 "Locator/ID Separation Protocol (LISP) Control-Plane", 1064 draft-ietf-lisp-rfc6833bis-31 (work in progress), May 1065 2020. 1067 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1068 Group Management Protocol Version 3 (IGMPv3) and Multicast 1069 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1070 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 1071 August 2006, . 1073 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1074 Ed., "Diameter Base Protocol", RFC 6733, 1075 DOI 10.17487/RFC6733, October 2012, 1076 . 1078 [RFC8126] Cotton, M., Leiba, B., Narten, T., "Guidelines for 1079 Writing an IANA Considerations Section in RFCs", RFC8126, 1080 DOI 10.17487/RFC8126, June 2017, 1081 . 1083 [RFC8378] Farinacci, D., Moreno, V., "Signal-Free Locator/ID 1084 Separation Protocol (LISP) Multicast", RFC8378, 1085 DOI 10.17487/RFC8378, May 2018, 1086 . 1088 [H3] Uber Technologies Inc. [n.d.]. H3: Ubers Hexagonal 1089 Hierarchical Spatial Index, May 2021, 1090 . 1092 [BDD] Fisher Yu, Wenqi Xian, Yingying Chen, Fangchen Liu, Mike 1093 Liao, Vashisht Madhavan, and Trevor Darrell. BDD100K: A 1094 diverse driving video database with scalable annotation 1095 tooling. arXiv:1805.04687, 2018. 2, 3 1096 1098 Authors' Addresses 1100 Sharon Barkai 1101 Nexar 1102 CA 1103 USA 1105 Email: sbarkai@gmail.com 1107 Bruno Fernandez-Ruiz 1108 Nexar 1109 London 1110 UK 1112 Email: b@getnexar.com 1114 Rotem Tamir 1115 Nexar 1116 Israel 1118 rotemtamir@getnexar.com 1120 Alberto Rodriguez-Natal 1121 Cisco Systems 1122 170 Tasman Drive 1123 San Jose, CA 1124 USA 1126 Email: natal@cisco.com 1128 Fabio Maino 1129 Cisco Systems 1130 170 Tasman Drive 1131 San Jose, CA 1132 USA 1134 Email: fmaino@cisco.com 1135 Albert Cabellos-Aparicio 1136 Technical University of Catalonia 1137 Barcelona 1138 Spain 1140 Email: acabello@ac.upc.edu 1142 Jordi Paillisse-Vilanova 1143 Technical University of Catalonia 1144 Barcelona 1145 Spain 1147 Email: jordip@ac.upc.edu 1149 Dino Farinacci 1150 lispers.net 1151 San Jose, CA 1152 USA 1154 Email: farinacci@gmail.com