This use-case can be solved by encoding a 64-bit H3 Hex-Tile identifier as a Distinguished-Named EID and the RLOC record encodes the lat-long with LCAF Geo-Coordinates encoding. This encoding, with the pubsub draft, provides a solution that requires no new changes.
Agree? And with a Geo-Prefix encoding you encode the size of the hexagonal grid (it whould be spherical but close enough to an hexagon). Speaking of spherical, is there a requirement to be 3 dimensional? The LCAF Geo-Coordinate does encode Altitude with centimeter granularity. Dino > On Feb 5, 2019, at 5:01 AM, Sharon <[email protected]> wrote: > > Dear lispers, > > In recent years been discussing - with Dino, Fabio, Albert, Alberto.. - the > use of lisp to support a serverless-network design pattern. > > In this pattern the EIDs are typically mobile highly functional clients, > communicating not with any specific server nor peer-to-peer but rather with > States embedded in the network. > > “Talking” to a state typically invokes a virtual network function at the > state RLOC wrapping it with proper access methods. > > During past months in Fermi then Nexar our team has brought a specific use > case as above to production. An automotive application which will greatly > benefit from standardization - since it is inherently multi vendor. > > In this use case in-network states represent the geo-spatial hexagon tiles > forming our roads - lanes, shoulders, junctions. > The network hexagons are indexed using H3. > > Moving EIDs communicating with moving HIDs invoke publish and subscribe > methods at the RLOC. Publish when vision&sensory clients identify hazards > snapped to small-hexagon-grid. Subscribe when clients wish to be aware of > beyond line-of-site spotted hazards, snapped to a larger area hexagon grid. > > Enclosed initial draft for the use-case. > Interested parties include - car makers, adas-cam makers, > municipalities-highwayAuth-gov, navigation-mapping vendors, > smart-infrastructure/lidar/active-led vendors. > > Hope to present for discussion next ietf meeting, and requesting a 10-15 min > slot. > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 > > Begin forwarded message: > >> From: [email protected] >> Date: February 5, 2019 at 11:19:49 AM GMT+2 >> To: "Alberto Rodriguez-Natal" <[email protected]>, "Ohad Serfaty" >> <[email protected]>, "Fabio Maino" <[email protected]>, "Albert >> Cabellos-Aparicio" <[email protected]>, "Sharon Barkai" >> <[email protected]> >> Subject: New Version Notification for draft-barkai-lisp-nexagon-00.txt >> >> >> A new version of I-D, draft-barkai-lisp-nexagon-00.txt >> has been successfully submitted by Sharon Barkai and posted to the >> IETF repository. >> >> Name: draft-barkai-lisp-nexagon >> Revision: 00 >> Title: Distributed Geo-Spatial LISP Blackboard for Automotive >> Document date: 2019-02-04 >> Group: Individual Submission >> Pages: 7 >> URL: >> https://www.ietf.org/internet-drafts/draft-barkai-lisp-nexagon-00.txt >> Status: https://datatracker.ietf.org/doc/draft-barkai-lisp-nexagon/ >> Htmlized: https://tools.ietf.org/html/draft-barkai-lisp-nexagon-00 >> Htmlized: >> https://datatracker..ietf.org/doc/html/draft-barkai-lisp-nexagon >> >> >> Abstract: >> This document specifies the use of LISP Blackboard for distributed >> Geo-Spatial Publish/Subscribe automotive applications. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
