idnits 2.17.1 draft-barkai-lisp-nexagon-05.txt: -(9): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(269): 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 3 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 687 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 166 instances of too long lines in the document, the longest one being 9 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 193 has weird spacing: '...through cloud...' == 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: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-lisp-rfc6833bis' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC8378' is defined on line 593, 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 (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 LISP Working Group S. Barkai 2 Internet-Draft B. Fernandez-Ruiz 3 Intended status: Experimental S. ZionB 4 Expires: November 30, 2019 Nexar Inc. 5 A. Rodriguez-Natal 6 F. Maino 7 Cisco Systems 8 A. Cabellos-Aparicio 9 J. Paillissé Vilanova 10 Technical University of Catalonia 11 D. Farinacci 12 lispers.net 13 June 30 2019 15 Network-Hexagons: H3-LISP Based Mobility Network 16 draft-barkai-lisp-nexagon-05 18 Abstract 20 This document specifies combined use of H3 and LISP for mobility-networks: 21 - Enabling real-time localized indexed-annotation of roads, tile by tile 22 - For sharing - hazards, blockages, conditions, maintenance, furniture.. 23 - Between MobilityClients producing and consuming road-state information 24 - Via in-network-state, an indirection by an addressable physical world grid. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 4, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 63 4. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 4 64 5. Mobility Clients-Network-Services . . . . . . . . . . . . . . 4 65 6. Mobility Unicast-Multicast . . . . . . . . . . . . . . . . . 5 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 (1) The Locator/ID Separation Protocol (LISP) [RFC6830] splits current IP 75 addresses in two different namespaces, Endpoint Identifiers (EIDs) and 76 Routing Locators (RLOCs). LISP uses a map-and-encap approach that relies on 77 (1) a Mapping System (distributed database) that stores and disseminates 78 EID-RLOC mappings and on (2) LISP tunnel routers (xTRs) that encapsulate 79 and decapsulate data packets based on the content of those mappings. 81 (2) H3 is a geospatial indexing system using a hexagonal grid that can be 82 (approximately) subdivided into finer and finer hexagonal grids, 83 combining the benefits of a hexagonal grid with hierarchical subdivisions. 84 H3 supports sixteen resolutions. Each finer resolution has cells with one 85 seventh the area of the coarser resolution. Hexagons cannot be perfectly 86 subdivided into seven hexagons, so the finer cells are only approximately 87 contained within a parent cell. Each cell is identified by a 64bit HID. 89 (3) The Berkeley Deep Drive (BDD) Industry Consortium investigates state-of- 90 the-art technologies in computer vision and machine learning for automotive 91 applications, and, for taxonomy of published automotive scene classification. 93 These standards are combined to create in-network-state which reflects the 94 condition of each one-square-meter (~1sqm) hexagon road-tile. The lisp 95 network maps & encapsulates traffic between MobilityClients endpoint- 96 identifiers (EID, and, addressable (HID=>EID) tile-states, aggregated by 97 H3Service EIDs. 99 The H3-LISP mobility network bridges timing-location gaps between the 100 production and consumption of information by MobilityClients: 101 - vision, sensory, LIADR, AI applications - info-producers 102 - driving-apps, smart-infrastructure, command & control - info-consumers 103 This is achieved by putting the physical world on a shared addressable 104 state-grid, an indirection. 106 The tile based geo-state mobility-network solves key issues in todays' vehicle 107 to vehicle networking, where observed hazards are expected to be relayed or 108 "hot-potato-tossed" (v2v) between vehicles without clear convergence i.e. 109 given a situation observable by some of traffic it is unclear if the rest of 110 the relevant traffic will receive consistent, conflicting, multiple, or non 111 what so ever peer-to-peer v2v indication. 113 For example, when a vehicle experiences a sudden highway slow-down,"sees" many 114 brake-lights or "feels" accelerometer, there is no clear way for it to share 115 this annotation with vehicles 20-30 sec away, preventing potential pile-up. 116 Or, when a vehicle crosses an intersection, observing opposite-lane 117 obstruction - construction, double-park, commercial-loading / un-loading, 118 garbage truck, or stopped school-bus - there is no clear way for it to alert 119 vehicles turning in to that lane - as it crossed and drove away. Data may be 120 replicated distorted or lost just like in a telephone-game. 122 These limitations are inherit since in most road situations vehicles are not 123 really proper peers. They just happen to be in the same place at the same time. 124 The H3-LISP mobility network solves limitations of direct vehicle to vehicle 125 communication because it anchors per this place: timing, privacy, 126 interoperability. This anchoring is done by MobilityClients (EIDs) 127 communicating through in-network road-tile geo-states. Geo-states are 128 aggregated and maintained by LISP addressable H3ServiceEIDs. 130 An important set of use-cases for state propagation of information to 131 MobilityClients is to provide drivers heads-up alerts on hazards and obstacles 132 beyond line of sight of both the drivers and in-car sensors: over traffic, 133 around blocks, far-side-junction, beyond turns, and surface-curvatures. 134 This highlights the importance of networks in providing road-safety. 136 To summarize the H3-LISP solution outline: 138 (1) Partition: 64bit indexed geo-spatial H3.r15 (~1sqm) road-tiles 139 (2) State: 64bit state values compile tile condition representation 140 (3) Aggregation: H3.r9 H3ServiceEID group individual H3.r15 road-tiles 141 (4) Channels: H3ServiceEIDs function as multicast state update channels 142 (5) Scale: H3ServiceEIDs distributed for in-network for latency-throughput 143 (6) Mapped Overlay: tunneled-network routes the mobility-network traffic 144 (7) Signal-free: tunneled overlay is used to map-register for mcast channels 145 (8) Access: tunnels used between MobilityClients/H3ServiceEIDs <> LISP edge 146 (9) Access: ClientXTRs/ServerXTRs tunnel traffic to-from the LISP EdgeRTRs 147 (10) Control: EdgeRTRs register-resolve identity-location and mcast (s,g) 149 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 150 | H3 Hexagon ID Key | 151 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 152 | H3 Hexagon State-Value | 153 |---------------------------------------------------------------| 155 ___ ___ 156 H3ServiceEIDs ___ / \ H3ServiceEIDs ___ / \ 157 ___ / | H3.r9 | ___ / | H3.r9 | 158 / | H3.r9 \ ___ / / | H3.r9 \ ___ / 159 | H3.r9 \ ___ / sXTR | H3.r9 \ ___ / sXTR 160 \ ___ / sXTR | \ ___ / sXTR | 161 sXTR | | sXTR | | 162 | | | | | | 163 | | | | | | 164 + - - + - - EdgeRTR EdgeRTR - + - + - - + 165 || ( ( (( || 166 ( ) 167 ( Network Hexagons ) 168 ( H3-LISP Based ) 169 ( Mobility Network ) 170 (( ) 171 || (( (()) () || 172 || || 173 = = = = = = = = = = = 174 || || 175 EdgeRTR EdgeRTR 176 .. .. .. .. 177 .. .. .. .. 178 ((((|)))) ((((|)))) ((((|)))) ((((|)))) 179 /|\ RAN /|\ /|\ RAN /|\ 180 .. .. 181 .. .. 182 .. Road divided by 1sqm H3.r15 ID-Ed Geo-States .. 183 .. .. 184 .. ___ ___ ___ .. 185 .. .............. / \/ \/ \ << cXTR::MobilityClientB 186 .. - - - - - - - H3.r15 H3.r15 H3.r15 - - - - - - - 187 MobilityClientA::cXTR >> \ ___ /\ ___ /\ ___ /.......... 189 - MobilityClientA has seen MobilityClientB (20-30 sec) future, and, vice versa 190 - Clients share information using addressable shared-state routed by LISP Edge 192 - ClientXTR (cXTR): tunnel encapsulation through access network to LISP Edge 193 - ServerXTR (sXTR): tunnel encapsulation through cloud network to LISP Edge 194 - The H3-LISP Mobility overlay starts in the cXTR and terminates in the sXTR 196 - The updates are routed to the appropriate tile geo-state by the LISP network 197 - EdgeRTRs perform multicast replication to edges and then native or to cXTRs 198 - Clients receive tile-by-tile geo-state updates via the multicast channels 200 Each H3.r9 hexagon is an EID Service with corresponding H3 hexagon ID. 201 Bound to that service is a LISP xTR, called a ServerXTR, resident to deliver 202 encapsulated packets to and from the H3ServiceEID and LISP Edge. EdgeRTRs are 203 used to re-tunnel packets from MobilityClients to H3ServiceEIDs. Each 204 H3ServiceEID is also a source multicast address for updating MobilityClients 205 on the state of the H3.r15 tiles aggregated-represented by the H3ServiceEID. 207 2. Requirements Language 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in [RFC2119]. 213 3. Definition of Terms 215 H3ServiceEID: Is an addressable aggregation of H3.r15 state-tiles. It is a 216 designated source for physical world reported annotations, and an (s,g) 217 source of multicast public-safety update channels. H3ServiceEID is itself 218 an H3 hexagon, large enough to provide geo-spatial conditions context, but 219 not too large as to over-burden (battery powered, cellular connected) 220 subscribers with too much information. For Mobility Network it is H3.r9. 221 It has a light-weight LISP protocol stack to tunnel packets aka ServerXTR. 222 The EID is an IPv6 EID that contains the H3 64-bit address numbering 223 scheme. See IANA consideration for details. 225 ServerXTR: Is a light-weight LISP protocol stack implementation that co-exists 226 with H3ServiceEID process. When the server roams, the xTR roams with it. 227 The ServerXTR encapsulates and decapsulates packets to/from EdgeRTRs. 229 MobilityClient: Is a roaming application that may be resident as part of an 230 automobile, as part of a navigation application, part of municipal, state, 231 of federal government command and control application, or part of live 232 street view consumer type of application. It has a light-weight LISP 233 protocol stack to tunnel packets aka ClientXTR. 235 MobilityClient EID: Is the IPv6 EID used by the Mobility Client applications to 236 source packets. The destination of such packets are only H3ServiceEIDs. 237 The EID format is opaque and is assigned as part of the MobilityClient 238 network-as-a-service (NaaS) authorization. 240 ClientXTR: Is the light-weight LISP protocol stack implementation that is 241 co-located with the Mobility Client application. It encapsulates packets 242 sourced by applications to EdgeRTRs and decapsulates packets from EdgeRTRs. 244 EdgeRTR: Is the core scale and structure of the LISP mobility network. LISP 245 RTRs decapsulate packets from ClientXTRs and ServerXTRs and re-encapsulates 246 packets to ServerXTRs and ClientXTRs. The EdgeRTRs glean H3ServiceEIDs and 247 glean MobilityClient EIDs when it decapsulates packets. EdgeRTRs store 248 H3ServiceEIDs and their own RLOC of where the H3ServiceEID is currently 249 reachable from in the map-cache. These mappings are registered to the LISP 250 mapping system so other EdgeRTRs know where to encapsulate for such EIDs. 252 4. Deployment Assumptions 254 The specification described in this document makes the following 255 deployment assumptions: 257 (1) Unique 64-bit HID is associated with each H3 geo-spatial tile 258 (2) MobilityClients and H3ServiceEIDs share this well known index 259 (3) 64-bit BDD state value is associated with each H3-indexed tile 260 (4) Tile state is compiled 16 fields of 4-bits, or max 16 enums 262 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 263 0123012301230123012301230123012301230123012301230123012301230123 265 A MobilityClient which needs to use an H3-LISP mobility overlay network - 266 instantiates a ClientXTR. It leverages DNS resolution to find EdgeRTR(s) 267 in order to home to. ClientXTR is provisioned with an address for DNS 268 resolvers, that help with the EdgeRTR discovery. The ClientXTR uses these 269 DNS resolvers to resolve a query that includes the ClientXTR’s current H3 270 index at resolution 9 (e.g. h3res9.example.net). To find its current H3.r9 271 index, the ClientXTR first translates its current geo-location to an H3 index 272 (e.g. gps snap-to-h3.r9).As a response to the query including the H3.r9 index 273 of the ClientXTR, the DNS resolver will return the IP address of the Edge RTR 274 that the ClientXTR can use to home to the H3-LISP mobility overlay. 276 The EdgeRTR discovery by the ClientXTR performed via DNS resolution so that: 277 1) EdgeRTRs are not tightly coupled to H3.r9 areas for easy load-balance 278 2) Mobility Clients do not need to constantly update EdgeRTR when it roams 280 In that sense, the same EdgeRTR may serve several H3.r9 areas for smooth 281 ride continuity, and, several EdgeRTRs may load balance a H3.r9 area with 282 high density of originating MobilityClient rides. When a MobilityClient 283 ClientXTR is homed to EdgeRTR it is able to communicate with H3ServiceEIDs. 285 5. Mobility Clients-Network-Services 287 The mobility network functions as a standard LISP VPN overlay. 288 The overlay delivers unicast and multicast packets across: 289 - multiple access-network-providers / radio-access-technologies. 290 - multiple cloud-edge hosting providers, public, private, hybrid. 292 We use data-plane XTRs in the stack of each mobility client and server. 293 ClientXTRs and ServerXTRs are homed to one or more EdgeRTRs at the LISP edge. 294 This structure allows for MobilityClients to "show-up" at any time, 295 behind any network-provider in a given mobility network administrative 296 domain (metro), and for any H3ServiceEID to be instantiated, moved, or 297 failed-over to - any rack in any cloud-provider. The LISP overlay enables 298 these roaming mobility network elements to communicate un-interrupted. 299 This quality is insured by the LISP RFCs. The determinism of identities for 300 MobilityClients to always refer to the correct H3ServiceEID is insured by H3 301 geospatial HIDs. 303 There are two options for how we associate ClientXTRs with LISP EdgeRTRs: 305 I. semi-random through DNS based load-balancing 307 In this option we assume that in a given metro edge a pool of EdgeRTRs can 308 distribute the Mobility Clients load randomly between them and that EdgeRTRs 309 are topologically more or less equivalent. Each RTR uses LISP to mesh with 310 the other RTRs in order to connect each Mobility Client with H3 Servers. 311 Mobility Clients can (multi) home to the same RTR(s) throughout a ride. 313 II. geo-spatial, where a well known any-cast RTR aggregates H3.r9 hexagons 315 In this option we align an EdgeRTR with a geo-spatial cell area, very much 316 like in Evolved Packet Core (EPC) solution. Mobility Clients currently roaming 317 in an area home to that RTR and so is the H3 Server. There is only one hop 318 across the edge overlay between clients and servers and mcast replication is 319 more focused, but clients need to keep re-homing as they move. 321 To summarize the H3LISP mobility network layout: 323 (1) Mobility-Clients traffic is tunneled via data-plane ClientXTRs 324 ClientXTRs are (multi) homed to EdgeRTR(s) 325 (2) H3ServiceEID traffic is tunneled via data-plane ServerXTR 326 ServerXTRs are (multi) homed to EdgeRTR(s) 327 (3) EdgeRTRs use mapping service to resolve Ucast HIDs to RTR RLOCs 328 EdgeRTRs also register to (Source, Group) H3ServiceEID multicasts 330 MobilityClients <> ClientXTR EdgeRTR v 331 v 332 v << Map-Assisted Mobility-Network Overlay << v 333 v 334 >> EdgeRTR ServerXTR <> H3ServiceEID 336 6. Mobility Unicast and Multicast 338 Which ever way a ClientXTR is homed to an Edge RTR, DNS metro load-balance 339 or well known geo-spatial map of IPs (a few 10Ks per large metro area), 340 an authenticated MobilityClient EID can send: [64bitH3.15ID :: 64bitState] 341 annotation to the H3.r9 H3ServiceEID. The H3.r9 IP HID can be calculated by 342 clients algorithmically form the H3.15 localized snapped-to-tile annotation. 344 The ClientXTR encapsulates MobilityClient EID and H3ServiceEID in a packet 345 sourced from the ClientXTR, destined to the EdgeRTR RLOC IP, Lisp port. 346 EdgeRTRs then re-encapsulate annotation packets either to remote EdgeRTR 347 (optionI) or to homed H3ServiceEID ServerXTR (option2). 348 The remote EdgeRTR aggregating H3ServiceEIDs re-encapsulates MobilityClient 349 EID to ServerXTR and from there to the H3ServiceEID. 351 To Summarize Unicast: 353 (1) MobilityClients can send annotation state localized an H3.r15 tile 354 These annotations are sent to an H3.r9 mobility H3ServiceEIDs 355 (2) MobilityClient EID and H3ServiceEID HID are encapsulated: 356 XTR <> RTR <> RTR <> XTR 357 * RTRs can map-resolve re-tunnel HIDs 358 (3) RTRs re-encapsulate original source-dest to ServerXTRs 359 ServerXTRs decapsulate packets to H3ServiceEID 361 Each H3.r9 Server is used by clients to update H3.r15 tile state is also an IP 362 Multicast channel Source used to update subscribers on the aggregate state of 363 the H3.r15 tiles in the H3.r9 Server. 365 We use rfc8378 signal free multicast to implement mcast channels in the 366 overlay. The mobility network has many channels and relatively few 367 subscribers per each. MobilityClients driving through or subscribing to a 368 a H3.r9 area can explicitly issue an rfc4604 MLDv2 in-order to subscribe, or, 369 may be subscribed implicitly by the EdgeRTR gleaning to ucast HID dest. 371 The advantage of explicit client MLDv2 registration trigger to rfc8378 is 372 that the clients manage their own mobility mcast hand-over according to their 373 location-direction moment vectors, and that it allows for otherwise silent, or, 374 non annotating clients. The advantage of EdgeRTR implicit registration is 375 less signaling required. 377 MLDv2 signaling messages are encapsulated between the ClientXTR and the LISP 378 EdgeRTR, therefore there is no requirement for the underlying network to 379 support native multicast. If native access multicast is supported (for example 380 native 5G multicast), then MobilityClient registration to H3ServiceEID 381 safety channels may be integrated to it, in which case the evolved-packet-core 382 (EPC) element supporting it (eNB) will use this standard to register with the 383 appropriate H3.r9 channels in its area. 385 EdgeRTRs note the subscribed MobilityClient stack XTRs and register as channel 386 subscribers in the mapping system (Source, Group) entry. This is done at the 387 first subscription request, if additional MobilityClients homed to the same 388 EdgeRTR register for the same channels the EdgeRTR registration covers them. 390 Upon receiving a multicast packet the EdgeRTR homing H3.r9 Servers resolve 391 the (S,G) remote EdgeRTRs registered for the channel and replicates the packet. 392 ` The remote EdgeRTRs homing MobilityClients in-turn replicate the packet to the 393 MobilityClients registered with them. 395 We expect an average of 600 H3.r15 tiles of the full 7^6 (~100K) possible in 396 H3.r9 to be part of any road. The H3.r9 server can transmit the status of all 397 600 or just those with meaningful state based on update SLA and policy. 399 To Summarize: 401 (1) H3LISP Clients tune to H3.r9 mobility updates using rfc8378 402 H3LISP Client issue MLDv2 registration to H3.r9 HIDs 403 ClientXTRs encapsulate MLDv2 to EdgeRTRs who register (s,g) 405 (2) ServerXTRs encapsulate updates to EdgeRTRs who map-resolve (s,g) RLOCs 406 EdgeRTRs replicate mobility update and tunnel to registered EdgeRTRs 407 Remote EdgeRTRs replicate updates to registered ClientXTRs 409 7. Security Considerations 411 The way to provide a security association between the ITRs and the 412 Map-Servers must be evaluated according to the size of the 413 deployment. For small deployments, it is possible to have a shared 414 key (or set of keys) between the ITRs and the Map-Servers. For 415 larger and Internet-scale deployments, scalability is a concern and 416 further study is needed. 418 8. Acknowledgments 420 This work is partly funded by the ANR LISP-Lab project #ANR- 421 13-INFR-009 (https://lisplab.lip6.fr). 423 9. IANA Considerations 425 I. Formal H3 to IPv6 EID mapping 427 II. State enum fields of H3 tiles: 429 Field 0x describes the "freshness" of the state { 430 0x: less than 1Sec 431 1x: less than 10Sec 432 2x: less than 20Sec 433 3x: less than 40Sec 434 4x: less than 1min 435 5x: less than 2min 436 6x: less than 5min 437 7x: less than 15min 438 8x: less than 30min 439 9x: less than 1hour 440 Ax: less than 2hours 441 Bx: less than 8hours 442 Cx: less than 24hours 443 Dx: less than 1week 444 Ex: less than 1month 445 Fx: more than 1month 446 } 448 field 1x: persistent weather or structural { 449 0x - null 450 1x - pothole 451 2x - speed-bump 452 3x - icy 453 4x - flooded 454 5x - snow-cover 455 6x - snow-deep 456 7x - construction cone 457 8x - curve 458 } 460 field 2x: transient or moving obstruction { 461 0x - null 462 1x - pedestrian 463 2x - bike 464 3x - stopped car / truck 465 4x - moving car / truck 466 5x - first responder vehicle 467 6x - sudden slowdown 468 7x - oversized-vehicle 469 8x - red-light-breach 470 } 472 field 3x: traffic-light timer countdown { 473 0x - green now 474 1x - 1 seconds to green 475 2x - 2 seconds to green 476 3x - 3 seconds to green 477 4x - 4 seconds to green 478 5x - 5 seconds to green 479 6x - 6 seconds to green 480 7x - 7 seconds to green 481 8x - 8 seconds to green 482 9x - 9 seconds to green 483 Ax - 10 seconds or less 484 Bx - 20 seconds or less 485 Cx - 30 seconds or less 486 Dx - 40 seconds or less 487 Ex - 50 seconds or less 488 Fx - minute or more left 489 } 491 field 4x: impacted tile from neighboring { 492 0x - not impacted 493 1x - light yellow 494 2x - yellow 495 3x - light orange 496 4x - orange 497 5x - light red 498 6x - red 499 7x - light blue 500 8x - blue 501 } 503 field 5x: incidents { 504 0x - clear 505 1x - light collision (fender bender) 506 2x - hard collision 507 3x - collision with casualty 508 4x - recent collision residues 509 5x - hard brake 510 6x - sharp cornering 511 } 512 field 6x - compiled tile safety rating { 514 } 515 field 7x: LaneRightsSigns { 516 0x - stop 517 1x - yield 518 2x - speedLimit 519 3x - straightOnly 520 4x - noStraight 521 5x - rightOnly 522 6x - noRight 523 7x - leftOnly 524 8x - noLeft 525 9x - noUTurn 526 10x - noLeftU 527 11x - bikeLane 528 12x - HOVLane 529 } 531 field 8x: MovementSigns { 532 0x - noPass 533 1x - keepRight 534 2x - keepLeft 535 3x - stayInLane 536 4x - doNotEnter 537 5x - noTrucks 538 6x - noBikes 539 7x - noPeds 540 8x - oneWay 541 9x - parking 542 10x - noParking 543 11x - noStandaing 544 12x - loadingZone 545 13x - truckRoute 546 14x - railCross 547 15x - School 548 } 550 field 9x: CurvesIntersectSigns { 551 0x - turnsLeft 552 1x - turnsRight 553 2x - curvesLeft 554 3x - curvesRight 555 4x - reversesLeft 556 5x - reversesRight 557 6x - windingRoad 558 7x - hairPin 559 8x - 270Turn 560 9x - pretzelTurn 561 10x - crossRoads 562 11x - crossT 563 12x - crossY 564 13x - circle 565 14x - laneEnds 566 15x - roadNarrows 567 } 568 field Ax - reserved 569 field Bx - reserved 570 field Cx - reserved 571 field Dx - reserved 572 field Ex - reserved 573 field Fx - reserved 575 10. Normative References 577 [I-D.ietf-lisp-rfc6833bis] 578 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 579 "Locator/ID Separation Protocol (LISP) Control-Plane", 580 draft-ietf-lisp-rfc6833bis-07 (work in progress), December 581 2017. 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, 585 DOI 10.17487/RFC2119, March 1997, 586 . 588 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 589 Locator/ID Separation Protocol (LISP)", RFC 6830, 590 DOI 10.17487/RFC6830, January 2013, 591 . 593 [RFC8378] Farinacci, D., Moreno, V., "Signal-Free Locator/ID Separation 594 Protocol (LISP) Multicast", RFC8378, 595 DOI 10.17487/RFC8378, May 2018, 596 . 598 Authors' Addresses 600 Sharon Barkai 601 Nexar 602 CA 603 USA 605 Email: sbarkai@gmail.com 607 Bruno Fernandez-Ruiz 608 Nexar 609 London 610 UK 612 Email: b@getnexar.com 614 S ZionB 615 Nexar 616 Israel 618 Email: sharon@fermicloud.io 620 Alberto Rodriguez-Natal 621 Cisco Systems 622 170 Tasman Drive 623 San Jose, CA 624 USA 626 Email: natal@cisco.com 628 Fabio Maino 629 Cisco Systems 630 170 Tasman Drive 631 San Jose, CA 632 USA 634 Email: fmaino@cisco.com 636 Albert Cabellos-Aparicio 637 Technical University of Catalonia 638 Barcelona 639 Spain 641 Email: acabello@ac.upc.edu 643 Jordi Paillissé-Vilanova 644 Technical University of Catalonia 645 Barcelona 646 Spain 648 Email: jordip@ac.upc.edu 650 Dino Farinacci 651 lispers.net 652 San Jose, CA 653 USA 655 Email: farinacci@gmail.com