idnits 2.17.1 draft-barkai-lisp-nexagon-04.txt: -(9): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(253): 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 671 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 158 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 182 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 561, but no explicit reference was found in the text == Unused Reference: 'RFC8378' is defined on line 577, 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: October 22, 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 May 22 2019 15 Network-Hexagons: H3-LISP Based Mobility Network 16 draft-barkai-lisp-nexagon-04 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 and 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 traffic between MobilityClients endpoint identifiers (EID), and, 96 addressable (HID=>EID) tile-states, aggregated by H3Service EIDs. 98 The H3-LISP mobility network bridges timing-location gaps between the 99 production and consumption of information, both by MobilityClients: 100 - vision, sensory, LIADR, AI applications - information producers 101 - driving-apps, smart-infrastructure, command & control - consumers 102 This is achieved by putting the physical world on a shared addressable 103 state-grid, an indirection. 105 The tile-state anchored mobility network solves key issues in todays' vehicle 106 to vehicle networking, where observed hazards are expected to be relayed or 107 "hot-potato-tossed" (v2v) between vehicles without clear convergence. 108 For example, when a vehicle experiences a sudden highway slow-down, many 109 brake-lights or accelerometer, there is no clear way for it to share this 110 annotation with vehicles 20-30 sec away, preventing (icy-fog) major pile-ups. 112 Or, when a vehicle crosses an intersection, observing opposite-lane 113 obstruction - construction, double-park, commercial-loading / un-loading, 114 garbage truck, or stopped school-bus - there is no clear way for it to alert 115 vehicles turning in to that lane - as it crossed and drove away. 117 The H3-LISP mobility network solves limitations of direct vehicle to vehicle 118 communication - time, location, privacy interoperability. This is done by 119 MobilityClients (EIDs) communicating through in-network road-tile-states. 120 These states are aggregated-maintained by LISP addressable H3ServiceEIDs. 122 An important set of use-cases for state propagation of information to 123 MobilityClients is to provide drivers heads-up alerts on hazards and obstacles 124 beyond line of sight of both the drivers and in-car sensors: over traffic, 125 around blocks, far-side-junction, beyond turns, and surface-curvatures. 126 This highlights the importance of networks in providing road-safety. 128 To summarize the H3-LISP solution outline: 130 (1) Partition: 64bit indexed geo-spatial H3.r15 (~1sqm) road-tiles 131 (2) State: 64bit state values compile tile condition representation 132 (3) Aggregation: H3.r9 H3ServiceEID group individual H3.r15 road-tiles 133 (4) Channels: H3ServiceEIDs function as multicast state update channels 134 (5) Scale: H3ServiceEIDs distributed for in-network for latency-throughput 135 (6) Mapped Overlay: tunneled-network routes the mobility-network traffic 136 (7) Signal-free: tunneled overlay is used to map-register for mcast channels 137 (8) Access: tunnels used between MobilityClients/H3ServiceEIDs <> LISP edge 138 (9) Access: ClientXTRs/ServerXTRs tunnel traffic to-from the LISP EdgeRTRs 139 (10) Control: EdgeRTRs register-resolve identity-location and mcast (s,g) 141 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 142 | H3 Hexagon ID Key | 143 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 144 | H3 Hexagon State-Value | 145 |---------------------------------------------------------------| 147 ___ ___ 148 H3ServiceEIDs ___ / \ H3ServiceEIDs ___ / \ 149 ___ / | H3.r9 | ___ / | H3.r9 | 150 / | H3.r9 \ ___ / / | H3.r9 \ ___ / 151 | H3.r9 \ ___ / sXTR | H3.r9 \ ___ / sXTR 152 \ ___ / sXTR | \ ___ / sXTR | 153 sXTR | | sXTR | | 154 | | | | | | 155 | | | | | | 156 + - - + - - EdgeRTR EdgeRTR - + - + - - + 157 || ( ( (( || 158 ( ) 159 ( Network Hexagons ) 160 ( H3-LISP Based ) 161 ( Mobility Network ) 162 (( ) 163 || (( (()) () || 164 || || 165 || || 166 = = = = = = = = = = = 167 || || 168 EdgeRTR EdgeRTR 169 .. .. .. .. 170 .. .. .. .. 171 ((((|)))) ((((|)))) ((((|)))) ((((|)))) 172 /|\ RAN /|\ /|\ RAN /|\ 173 .. .. 174 .. ___ ___ ___ .. 175 .. .............. / \/ \/ \ << cXTR::MobilityClientB 176 .. - - - - - - - H3.r15 H3.r15 H3.r15 - - - - - - - 177 MobilityClientA::cXTR >> \ ___ /\ ___ /\ ___ /.......... 179 - MobilityClientA has seen MobilityClientB (20-30 sec) future, and, visa versa 180 - Clients share information using addressable shared-state routed by LISP Edge 181 - ClientXTR (cXTR): tunnel encapsulation through access network to LISP Edge 182 - ServerXTR (sXTR): tunnel encapsulation through cloud network to LISP Edge 184 Each H3.r9 hexagon is an EID Service with corresponding H3 hexagon ID. 185 Bound to that service is a LISP xTR, called a ServerXTR, resident to deliver 186 encapsulated packets to and from the H3ServiceEID and LISP Edge. EdgeRTRs are 187 used to re-tunnel packets from MobilityClients to H3ServiceEIDs. Each 188 H3ServiceEID is also a source multicast address for updating MobilityClients 189 on the state of the H3.r15 tiles aggregated-represented by the H3ServiceEID. 191 2. Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [RFC2119]. 197 3. Definition of Terms 199 H3ServiceEID: Is an addressable aggregation of H3.r15 state-tiles. It is a 200 designated source for physical world reported annotations, and an (s,g) 201 source of multicast public-safety update channels. H3ServiceEID is itself 202 an H3 hexagon, large enough to provide geo-spatial conditions context, but 203 not too large as to over-burden (battery powered, cellular connected) 204 subscribers with too much information. For Mobility Network it is H3.r9. 205 It has a light-weight LISP protocol stack to tunnel packets aka ServerXTR. 206 The EID is an IPv6 EID that contains the H3 64-bit address numbering 207 scheme. See IANA consideration for details. 209 ServerXTR: Is a light-weight LISP protocol stack implementation that co-exists 210 with H3ServiceEID process. When the server roams, the xTR roams with it. 211 The ServerXTR encapsulates and decapsulates packets to/from EdgeRTRs. 213 MobilityClient: Is a roaming application that may be resident as part of an 214 automobile, as part of a navigation application, part of municipal, state, 215 of federal government command and control application, or part of live 216 street view consumer type of application. It has a light-weight LISP 217 protocol stack to tunnel packets aka ClientXTR. 219 MobilityClient EID: Is the IPv6 EID used by the Mobility Client applications to 220 source packets. The destination of such packets are only H3ServiceEIDs. 221 The EID format is opaque and is assigned as part of the MobilityClient 222 network-as-a-service (NaaS) authorization. 224 ClientXTR: Is the light-weight LISP protocol stack implementation that is 225 co-located with the Mobility Client application. It encapsulates packets 226 sourced by applications to EdgeRTRs and decapsulates packets from EdgeRTRs. 228 EdgeRTR: Is the core scale and structure of the LISP mobility network. LISP 229 RTRs decapsulate packets from ClientXTRs and ServerXTRs and re-encapsulates 230 packets to ServerXTRs and ClientXTRs. The EdgeRTRs glean H3ServiceEIDs and 231 glean MobilityClient EIDs when it decapsulates packets. EdgeRTRs store 232 H3ServiceEIDs and their own RLOC of where the H3ServiceEID is currently 233 reachable from in the map-cache. These mappings are registered to the LISP 234 mapping system so other EdgeRTRs know where to encapsulate for such EIDs. 236 4. Deployment Assumptions 238 The specification described in this document makes the following 239 deployment assumptions: 241 (1) Unique 64-bit HID is associated with each H3 geo-spatial tile 242 (2) MobilityClients and H3ServiceEIDs share this well known index 243 (3) 64-bit BDD state value is associated with each H3-indexed tile 244 (4) Tile state is compiled 16 fields of 4-bits, or max 16 enums 246 |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| 247 0123012301230123012301230123012301230123012301230123012301230123 249 A MobilityClient which needs to use an H3-LISP mobility overlay network - 250 instantiates a ClientXTR. It leverages DNS resolution to find EdgeRTR(s) 251 in order to home to. ClientXTR is provisioned with an address for DNS 252 resolvers, that help with the EdgeRTR discovery. The ClientXTR uses these 253 DNS resolvers to resolve a query that includes the ClientXTR’s current H3 254 index at resolution 9 (e.g. h3res9.example.net). To find its current H3.r9 255 index, the ClientXTR first translates its current geo-location to an H3 index 256 (e.g. gps snap-to-h3.r9).As a response to the query including the H3.r9 index 257 of the ClientXTR, the DNS resolver will return the IP address of the Edge RTR 258 that the ClientXTR can use to home to the H3-LISP mobility overlay. 260 The EdgeRTR discovery by the ClientXTR performed via DNS resolution so that: 261 1) EdgeRTRs are not tightly coupled to H3.r9 areas for easy load-balance 262 2) Mobility Clients do not need to constantly update EdgeRTR when it roams 264 In that sense, the same EdgeRTR may serve several H3.r9 areas for smooth 265 ride continuity, and, several EdgeRTRs may load balance a H3.r9 area with 266 high density of originating MobilityClient rides. When a MobilityClient 267 ClientXTR is homed to EdgeRTR it is able to communicate with H3ServiceEIDs. 269 5. Mobility Clients-Network-Services 271 The mobility network functions as a standard LISP VPN overlay. 272 The overlay delivers unicast and multicast packets across: 273 - multiple access-network-providers / radio-access-technologies. 274 - multiple cloud-edge hosting providers, public, private, hybrid. 276 We use data-plane XTRs in the stack of each mobility client and server. 277 ClientXTRs and ServerXTRs are homed to one or more EdgeRTRs at the LISP edge. 278 This structure allows for MobilityClients to "show-up" at any time, 279 behind any network-provider in a given mobility network administrative 280 domain (metro), and for any H3ServiceEID to be instantiated, moved, or 281 failed-over to - any rack in any cloud-provider. The LISP overlay enables 282 these roaming mobility network elements to communicate un-interrupted. 283 This quality is insured by the LISP RFCs. The determinism of identities for 284 MobilityClients to always refer to the correct H3ServiceEID is insured by H3 285 geospatial HIDs. 287 There are two options for how we associate ClientXTRs with LISP EdgeRTRs: 289 I. semi-random through DNS based load-balancing 291 In this option we assume that in a given metro edge a pool of EdgeRTRs can 292 distribute the Mobility Clients load randomly between them and that EdgeRTRs 293 are topologically more or less equivalent. Each RTR uses LISP to mesh with 294 the other RTRs in order to connect each Mobility Client with H3 Servers. 295 Mobility Clients can (multi) home to the same RTR(s) throughout a ride. 297 II. geo-spatial, where a well known any-cast RTR aggregates H3.r9 hexagons 299 In this option we align an EdgeRTR with a geo-spatial cell area, very much 300 like in Evolved Packet Core (EPC) solution. Mobility Clients currently roaming 301 in an area home to that RTR and so is the H3 Server. There is only one hop 302 across the edge overlay between clients and servers and mcast replication is 303 more focused, but clients need to keep re-homing as they move. 305 To summarize the H3LISP mobility network layout: 307 (1) Mobility-Clients traffic is tunneled via data-plane ClientXTRs 308 ClientXTRs are (multi) homed to EdgeRTR(s) 309 (2) H3ServiceEID traffic is tunneled via data-plane ServerXTR 310 ServerXTRs are (multi) homed to EdgeRTR(s) 311 (3) EdgeRTRs use mapping service to resolve Ucast HIDs to RTR RLOCs 312 EdgeRTRs also register to (Source, Group) H3ServiceEID multicasts 314 MobilityClients <> ClientXTR EdgeRTR v 315 v 316 v << Map-Assisted Mobility-Network Overlay << v 317 v 318 >> EdgeRTR ServerXTR <> H3ServiceEID 320 6. Mobility Unicast and Multicast 322 Which ever way a ClientXTR is homed to an Edge RTR, DNS metro load-balance 323 or well known geo-spatial map of IPs (a few 10Ks per large metro area), 324 an authenticated MobilityClient EID can send: [64bitH3.15ID :: 64bitState] 325 annotation to the H3.r9 H3ServiceEID. The H3.r9 IP HID can be calculated by 326 clients algorithmically form the H3.15 localized snapped-to-tile annotation. 328 The ClientXTR encapsulates MobilityClient EID and H3ServiceEID in a packet 329 sourced from the ClientXTR, destined to the EdgeRTR RLOC IP, Lisp port. 330 EdgeRTRs then re-encapsulate annotation packets either to remote EdgeRTR 331 (optionI) or to homed H3ServiceEID ServerXTR (option2). 332 The remote EdgeRTR aggregating H3ServiceEIDs re-encapsulates MobilityClient 333 EID to ServerXTR and from there to the H3ServiceEID. 335 To Summarize Unicast: 337 (1) MobilityClients can send annotation state localized an H3.r15 tile 338 These annotations are sent to an H3.r9 mobility H3ServiceEIDs 339 (2) MobilityClient EID and H3ServiceEID HID are encapsulated: 340 XTR <> RTR <> RTR <> XTR 341 * RTRs can map-resolve re-tunnel HIDs 342 (3) RTRs re-encapsulate original source-dest to ServerXTRs 343 ServerXTRs decapsulate packets to H3ServiceEID 345 Each H3.r9 Server is used by clients to update H3.r15 tile state is also an IP 346 Multicast channel Source used to update subscribers on the aggregate state of 347 the H3.r15 tiles in the H3.r9 Server. 349 We use rfc8378 signal free multicast to implement mcast channels in the 350 overlay. The mobility network has many channels and relatively few 351 subscribers per each. MobilityClients driving through or subscribing to a 352 a H3.r9 area can explicitly issue an rfc4604 MLDv2 in-order to subscribe, or, 353 may be subscribed implicitly by the EdgeRTR gleaning to ucast HID dest. 355 The advantage of explicit client MLDv2 registration trigger to rfc8378 is 356 that the clients manage their own mobility mcast hand-over according to their 357 location-direction moment vectors, and that it allows for otherwise silent, or, 358 non annotating clients. The advantage of EdegRTR implicit registration is 359 less signaling required. 361 MLDv2 signaling messages are encapsulated between the ClientXTR and the LISP 362 EdgeRTR, therefore there is no requirement for the underlying network to 363 support native multicast. If native access multicast is supported (for example 364 native 5G multicast), then MobilityClient registration to H3ServiceEID 365 safety channels may be integrated to it, in which case the evolved-packet-core 366 (EPC) element supporting it (eNB) will use this standard to register with the 367 appropriate H3.r9 channels in its area. 369 EdgeRTRs note the subscribed MobilityClient stack XTRs and register as channel 370 subscribers in the mapping system (Source, Group) entry. This is done at the 371 first subscription request, if additional MobilityClients homed to the same 372 EdgeRTR register for the same channels the EdgeRTR registration covers them. 374 Upon receiving a multicast packet the EdgeRTR homing H3.r9 Servers resolve 375 the (S,G) remote EdgeRTRs registered for the channel and replicates the packet. 376 ` The remote EdgeRTRs homing MobilityClients in-turn replicate the packet to the 377 MobilityClients registered with them. 379 We expect an average of 600 H3.r15 tiles of the full 7^6 (~100K) possible in 380 H3.r9 to be part of any road. The H3.r9 server can transmit the status of all 381 600 or just those with meaningful state based on update SLA and policy. 383 To Summarize: 385 (1) H3LISP Clients tune to H3.r9 mobility updates using rfc8378 386 H3LISP Client issue MLDv2 registration to H3.r9 HIDs 387 ClientXTRs encapsulate MLDv2 to EdgeRTRs who register (s,g) 389 (2) ServerXTRs encapsulate updates to EdgeRTRs who map-resolve (s,g) RLOCs 390 EdgeRTRs replicate mobility update and tunnel to registered EdgeRTRs 391 Remote EdgeRTRs replicate updates to registered ClientXTRs 393 7. Security Considerations 395 The way to provide a security association between the ITRs and the 396 Map-Servers must be evaluated according to the size of the 397 deployment. For small deployments, it is possible to have a shared 398 key (or set of keys) between the ITRs and the Map-Servers. For 399 larger and Internet-scale deployments, scalability is a concern and 400 further study is needed. 402 8. Acknowledgments 404 This work is partly funded by the ANR LISP-Lab project #ANR- 405 13-INFR-009 (https://lisplab.lip6.fr). 407 9. IANA Considerations 409 I. Formal H3 to IPv6 EID mapping 411 II. State enum fields of H3 tiles: 413 Field 0x describes the "freshness" of the state { 414 0x: less than 1Sec 415 1x: less than 10Sec 416 2x: less than 20Sec 417 3x: less than 40Sec 418 4x: less than 1min 419 5x: less than 2min 420 6x: less than 5min 421 7x: less than 15min 422 8x: less than 30min 423 9x: less than 1hour 424 Ax: less than 2hours 425 Bx: less than 8hours 426 Cx: less than 24hours 427 Dx: less than 1week 428 Ex: less than 1month 429 Fx: more than 1month 430 } 432 field 1x: persistent weather or structural { 433 0x - null 434 1x - pothole 435 2x - speed-bump 436 3x - icy 437 4x - flooded 438 5x - snow-cover 439 6x - snow-deep 440 7x - construction cone 441 8x - curve 442 } 444 field 2x: transient or moving obstruction { 445 0x - null 446 1x - pedestrian 447 2x - bike 448 3x - stopped car / truck 449 4x - moving car / truck 450 5x - first responder vehicle 451 6x - sudden slowdown 452 7x - oversized-vehicle 453 8x - red-light-breach 454 } 456 field 3x: traffic-light timer countdown { 457 0x - green now 458 1x - 1 seconds to green 459 2x - 2 seconds to green 460 3x - 3 seconds to green 461 4x - 4 seconds to green 462 5x - 5 seconds to green 463 6x - 6 seconds to green 464 7x - 7 seconds to green 465 8x - 8 seconds to green 466 9x - 9 seconds to green 467 Ax - 10 seconds or less 468 Bx - 20 seconds or less 469 Cx - 30 seconds or less 470 Dx - 40 seconds or less 471 Ex - 50 seconds or less 472 Fx - minute or more left 473 } 475 field 4x: impacted tile from neighboring { 476 0x - not impacted 477 1x - light yellow 478 2x - yellow 479 3x - light orange 480 4x - orange 481 5x - light red 482 6x - red 483 7x - light blue 484 8x - blue 485 } 487 field 5x: incidents { 488 0x - clear 489 1x - light collision (fender bender) 490 2x - hard collision 491 3x - collision with casualty 492 4x - recent collision residues 493 5x - hard brake 494 6x - sharp cornering 495 } 496 field 6x - compiled tile safety rating { 498 } 499 field 7x: LaneRightsSigns { 500 0x - stop 501 1x - yield 502 2x - speedLimit 503 3x - straightOnly 504 4x - noStraight 505 5x - rightOnly 506 6x - noRight 507 7x - leftOnly 508 8x - noLeft 509 9x - noUTurn 510 10x - noLeftU 511 11x - bikeLane 512 12x - HOVLane 513 } 515 field 8x: MovementSigns { 516 0x - noPass 517 1x - keepRight 518 2x - keepLeft 519 3x - stayInLane 520 4x - doNotEnter 521 5x - noTrucks 522 6x - noBikes 523 7x - noPeds 524 8x - oneWay 525 9x - parking 526 10x - noParking 527 11x - noStandaing 528 12x - loadingZone 529 13x - truckRoute 530 14x - railCross 531 15x - School 532 } 534 field 9x: CurvesIntersectSigns { 535 0x - turnsLeft 536 1x - turnsRight 537 2x - curvesLeft 538 3x - curvesRight 539 4x - reversesLeft 540 5x - reversesRight 541 6x - windingRoad 542 7x - hairPin 543 8x - 270Turn 544 9x - pretzelTurn 545 10x - crossRoads 546 11x - crossT 547 12x - crossY 548 13x - circle 549 14x - laneEnds 550 15x - roadNarrows 551 } 552 field Ax - reserved 553 field Bx - reserved 554 field Cx - reserved 555 field Dx - reserved 556 field Ex - reserved 557 field Fx - reserved 559 10. Normative References 561 [I-D.ietf-lisp-rfc6833bis] 562 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 563 "Locator/ID Separation Protocol (LISP) Control-Plane", 564 draft-ietf-lisp-rfc6833bis-07 (work in progress), December 565 2017. 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, 570 . 572 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 573 Locator/ID Separation Protocol (LISP)", RFC 6830, 574 DOI 10.17487/RFC6830, January 2013, 575 . 577 [RFC8378] Farinacci, D., Moreno, V., "Signal-Free Locator/ID Separation 578 Protocol (LISP) Multicast", RFC8378, 579 DOI 10.17487/RFC8378, May 2018, 580 . 582 Authors' Addresses 584 Sharon Barkai 585 Nexar 586 CA 587 USA 589 Email: sharon.barkai@getnexar.com 591 Bruno Fernandez-Ruiz 592 Nexar 593 London 594 UK 596 Email: b@getnexar.com 598 S ZionB 599 Nexar 600 Israel 602 Email: sharon@fermicloud.io 604 Alberto Rodriguez-Natal 605 Cisco Systems 606 170 Tasman Drive 607 San Jose, CA 608 USA 610 Email: natal@cisco.com 612 Fabio Maino 613 Cisco Systems 614 170 Tasman Drive 615 San Jose, CA 616 USA 618 Email: fmaino@cisco.com 620 Albert Cabellos-Aparicio 621 Technical University of Catalonia 622 Barcelona 623 Spain 625 Email: acabello@ac.upc.edu 627 Jordi Paillissé-Vilanova 628 Technical University of Catalonia 629 Barcelona 630 Spain 632 Email: jordip@ac.upc.edu 634 Dino Farinacci 635 lispers.net 636 San Jose, CA 637 USA 639 Email: farinacci@gmail.com