The currently gating items on the bis work is RFC 6834bis. We are
working to get that done.
We will work on nexagon when the base documents are done.
Yours,
Joel
On 5/23/2021 2:59 AM, Sharon Barkai wrote:
The LISP-Nexagon interface is being used in this AECC TR (Toyota, Oracle) to
express mobility transient data management requirements, LISP itself is used
as basis for requirements for P2P / P2MP mobility edge service continuity.
1. Mobility Transient Data Management
* these are deviation from the HDMaps, that will update the map (new signs) or
remain transient (parking, blockages).
- the addressable (EID) interface allows for low-latency high-yield (resolution-less,
connectionless) vehicle<> edge exchange.
- the geo-spatial indexing allows for representation of transient data as
enumeration w/o frequent distributed creation/ deletion.
- the object interface allow for stable interoperable construct while allowing
flexible/differentiated: ingest, curation, propagation.
2. Mobility Edge Service Continuity
* this is the distributed compute network between many vehicles and edge
compute locations in a major metro area.
- allow for P2P P2MP sessions between EIDs to continue as IOT modems switch
carriers due to reception change while driving.
- allow for P2P P2MP session between EIDs while addressable (low-latency)
services migrate between edge servers/ locations.
- allow for lode-balanced highly available anchoring of roaming clients and
services per each private enterprise mobility network.
When can we expect RFC numbers for bis and nexagons?
It can really help specifications and references.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp