< draft-barkai-lisp-nexagon-02.txt   draft-barkai-lisp-nexagon-03.txt >
skipping to change at line 15 skipping to change at line 15
A. Rodriguez-Natal A. Rodriguez-Natal
F. Maino F. Maino
Cisco Systems Cisco Systems
A. Cabellos-Aparicio A. Cabellos-Aparicio
J. Paillissé Vilanova J. Paillissé Vilanova
Technical University of Catalonia Technical University of Catalonia
D. Farinacci D. Farinacci
lispers.net lispers.net
May 4 2019 May 4 2019
H3-LISP Based Mobility Network Network-Hexagons, an H3-LISP Based Mobility Network
draft-barkai-lisp-nexagon-02 draft-barkai-lisp-nexagon-03
Abstract Abstract
This document specifies combined use of H3 and LISP for mobility-networks: This document specifies combined use of H3 and LISP for mobility-networks:
- Enabling real-time tile-by-tile localized-annotation of road-conditions - Enabling real-time tile-by-tile localized-annotation of road-conditions
- Sharing of road annotations: hazards, blockages, maintenance, furniture - Sharing of road annotations: hazards, blockages, maintenance, furniture
- Between MobilityClients, which produce-consume road-tile state information - Between MobilityClients producing and consuming road-state information
- Using formal in-network-state addressable-indexed-maintained by H3Servers. - Using in-network tile-state addressable-indexed-maintained in H3Servers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
skipping to change at line 129 skipping to change at line 129
EID addressable H3Servers. An important set of use-cases involves propagation EID addressable H3Servers. An important set of use-cases involves propagation
of condition information to MobilityClients to provide drivers heads-up alerts of condition information to MobilityClients to provide drivers heads-up alerts
on hazards and obstacles beyond line of sight: over traffic, around blocks, on hazards and obstacles beyond line of sight: over traffic, around blocks,
far-side-junction, beyond turns and surface-curvatures. This highlights the far-side-junction, beyond turns and surface-curvatures. This highlights the
importance of networks in providing road-safety greater then any isolated or importance of networks in providing road-safety greater then any isolated or
autonomous vehicle safety technology. autonomous vehicle safety technology.
To summarize the H3-LISP solution outline: To summarize the H3-LISP solution outline:
(1) Partition: Geo-spatial H3.r15 (1sqm) road-tiles indexed by 64bit HIDs (1) Partition: Geo-spatial H3.r15 (1sqm) road-tiles indexed by 64bit HIDs
(2) Geo-spatial tile-state values complied to 64bit condition representation (2) State: geo-tile-state values complied to 64bit condition representation
(3) Geo-spatial H3Servers use H3.r9 resolution to aggregate H3.r15 road-tiles (3) Aggregation: H3Servers use H3.r9 resolution to group H3.r15 road-tiles
(4) H3Servers function also as multicast channels of H3.r15 state updates (4) Channels: H3Servers function multicast aggregated H3.r15 state updates
(5) H3Servers are distributed for in-network scale, latency, and throughput (5) Scale: H3Servers are distributed for in-network for latency-throughput
(6) An overlay tunneled-network is used to map the mobility-network traffic (6) Mapped: An overlay tunneled-network routes the mobility-network traffic
(7) Tunneled overlay network is used to implement signal-free mcast channels (7) Signal-free: Tunneled overlay is used to map-register for mcast channels
(8) Tunnels also used between MobilityClients/H3Servers <> and the LISP edge (8) Access: Tunnels used between MobilityClients/H3Servers <> and LISP edge
(9) ClientXTRs and ServerXTRs tunnel traffic to and from the LISP EdgeRTRs (9) Access: ClientXTRs/ServerXTRs tunnel traffic to-from the LISP EdgeRTRs
(10) EdgeRTRs register-resolve identity-location as well as mcast registration (10) Control: EdgeRTRs register-resolve identity-location as well as mcast
|-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
| H3 Hexagon ID Key | | H3 Hexagon ID Key |
|-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
| H3 Hexagon State-Value | | H3 Hexagon State-Value |
|---------------------------------------------------------------| |---------------------------------------------------------------|
___ ___ ___ ___ ___
/ \ / \ / \ H3Servers H3Servers ___ / \ H3Servers ___ / \
| H3-R9 | | H3-R9 | | | ___ / | H3.r9 | ___ / | H3.r9 |
--- \ ___ / --- --- \_____/ --- --- \____/ --- / | H3.r9 \ ___ / / | H3.r9 \ ___ /
ServerXTR ServerXTR ServerXTR | H3.r9 \ ___ / sXTR | H3.r9 \ ___ / sXTR
\ | / \ ___ / sXTR | \ ___ / sXTR |
EdgeRTRs sXTR | | sXTR | |
|| | | | | | |
<LISP MapAssisted Overlay> | | | | | |
|| + - - + - - EdgeRTR EdgeRTR - + - + - - +
EdgeRTRs || ( ( -- ||
/|\ ( )
((((|)))) ((((|)))) ( Nexagon )
/|\ /|\ ( H3-LISP Based )
RAN RAN ( Mobility Network )
(( )
|| (( __ -- ||
|| ||
|| ||
= = = = = = = = = = =
|| ||
EdgeRTR EdgeRTR
.. .. .. ..
.. .. .. ..
((((|)))) ((((|)))) ((((|)))) ((((|))))
/|\ RAN /|\ /|\ RAN /|\
.. ..
.. ___ ___ ___ ..
.. .............. / \/ \/ \ << cXTR::MobilityClient
.. - - - - - - - - H3.r15 H3.r15 H3.r15 - - - - - - -
MobilityClient::cXTR >> \ ___ /\ ___ /\ ___ /..........
..................../ \/ \/ \....<< ClientXTR cXTR: ClientXTR tunnel encapsulation through access network to LISP Edge
- - - - - - - - - - - - H3-R15 - - H3-R15 - - - - - - - Mobility Clients sXTR: ServerXTR tunnel encapsulation through cloud network to LISP Edge
ClientXTR >> ....\____/\____/\____/..........
Each H3.r9 hexagon is a server with corresponding H3 ID. Bound to that server Each H3.r9 hexagon is a server with corresponding H3 ID. Bound to that server
is a LISP xTR, called a ServerXTR, resident to deliver encapsulated packets to is a LISP xTR, called a ServerXTR, resident to deliver encapsulated packets to
and from the H3Server and the LISP Edge. EdgeRTRs are used to re-tunnel packets and from the H3Server and the LISP Edge. EdgeRTRs are used to re-tunnel packets
from MobilityClients to that H3Server. Each H3Server HID is also a source from MobilityClients to that H3Server. Each H3Server HID is also a source
multicast address for updating MobilityClients as to the state of the H3.r15 multicast address for updating MobilityClients as to the state of the H3.r15
tiles contained in the H3.r9 H3Server. tiles contained in the H3.r9 H3Server.
2. Requirements Language 2. Requirements Language
skipping to change at line 231 skipping to change at line 246
deployment assumptions: deployment assumptions:
(1) Unique 64-bit HID is associated with each H3 geo-spatial tile (1) Unique 64-bit HID is associated with each H3 geo-spatial tile
(2) MobilityClients and H3Servers share this well known index (2) MobilityClients and H3Servers share this well known index
(3) A 64-bit BDD state value is associated with each H3 tile (3) A 64-bit BDD state value is associated with each H3 tile
(4) Tile state is compiled 16 fields of 4-bits or 16 enums (4) Tile state is compiled 16 fields of 4-bits or 16 enums
|-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-| |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
0123012301230123012301230123012301230123012301230123012301230123 0123012301230123012301230123012301230123012301230123012301230123
When a MobilityClient wants to join an H3-LISP mobility network, it first A MobilityClient which needs to use an H3-LISP mobility overlay network -
instantiates a ClientXTR. It then leverages DNS resolution to find EdgeRTR(s) instantiates a ClientXTR. It leverages DNS resolution to find EdgeRTR(s)
it can home to. The ClientXTR is provisioned with an anycast address for the in order to home to. ClientXTR is provisioned with an anycast address for the
DNS resolvers, that help with the EdgeRTR discovery. The ClientXTR uses these DNS resolvers, that help with the EdgeRTR discovery. The ClientXTR uses these
anycasted DNS resolvers to resolve a query that includes the ClientXTR’s anycasted DNS resolvers to resolve a query that includes the ClientXTR’s
current H3 index at resolution 9 (e.g. h3res9.example.net). To find its current H3 index at resolution 9 (e.g. h3res9.example.net). To find its
current H3.res9 index, the ClientXTR first translates its current geo- current H3.res9 index, the ClientXTR first translates its current geo-
location to an H3 index (e.g. gps snap-to-res9-hex).As a response to the location to an H3 index (e.g. gps snap-to-res9-hex).As a response to the
query including the H3.res9 index of the ClientXTR, the DNS resolver will query including the H3.res9 index of the ClientXTR, the DNS resolver will
return the IP address of the Edge RTR that the ClientXTR can use to home to return the IP address of the Edge RTR that the ClientXTR can use to home to
the H3-LISP mobility overlay. The EdgeRTR discovery by the ClientXTR is the H3-LISP mobility overlay.
performed via DNS resolution so that 1) EdgeRTRs are not tightly coupled to
H3.r9 areas, and 2) the car does not need to update its EdgeRTR every time it The EdgeRTR discovery by the ClientXTR performed via DNS resolution so that:
roams to another H3.r9 area. In that sense, the same EdgeRTR may serve 1) EdgeRTRs are not tightly coupled to H3.r9 areas for easy load-balance
several H3.r9 areas, and, several EdgeRTRs may serve the same H3.r9 area. 2) Mobility Clients do not need to constantly update EdgeRTR when it roams
When a MobilityClient::ClientXTR is homed to an EdgeRTR it is ready to
communicate with state H3Servers and leverage/support the mobility network. In that sense, the same EdgeRTR may serve several H3.r9 areas for smooth
ride continuity, and, several EdgeRTRs may load balance a H3.r9 area with
high density of originating MobilityClient rides.
When a MobilityClient::ClientXTR is homed to an EdgeRTR it is able to
communicate with H3Servers to leverage and support the mobility network.
5. Mobility Clients-Network-Servers 5. Mobility Clients-Network-Servers
The mobility network functions as a standard LISP VPN overlay. The mobility network functions as a standard LISP VPN overlay.
The overlay delivers unicast and multicast packets across: The overlay delivers unicast and multicast packets across:
- multiple access-network providers / radio-access technologies. - multiple access-network providers / radio-access technologies.
- multiple cloud-edge hosting providers, public, private, or hybrid. - multiple cloud-edge hosting providers, public, private, or hybrid.
We use data-plane XTRs in the stack of each mobility client and server. We use data-plane XTRs in the stack of each mobility client and server.
ClientXTRs and ServerXTRs are homed to one or more EdgeRTRs at the LISP edge. ClientXTRs and ServerXTRs are homed to one or more EdgeRTRs at the LISP edge.
skipping to change at line 294 skipping to change at line 313
To summarize the H3LISP mobility network layout: To summarize the H3LISP mobility network layout:
(1) Mobility-Clients traffic is tunneled via data-plane ClientXTRs (1) Mobility-Clients traffic is tunneled via data-plane ClientXTRs
ClientXTRs are (multi) homed to EdgeRTR(s) ClientXTRs are (multi) homed to EdgeRTR(s)
(2) H3Server traffic is tunneled via data-plane ServerXTR (2) H3Server traffic is tunneled via data-plane ServerXTR
ServerXTRs are (multi) homed to EdgeRTR(s) ServerXTRs are (multi) homed to EdgeRTR(s)
(3) EdgeRTRs use mapping service to resolve Ucast HIDs to RTR RLOCs (3) EdgeRTRs use mapping service to resolve Ucast HIDs to RTR RLOCs
EdgeRTRs also register to (Source, Group) H3Server HID multicasts EdgeRTRs also register to (Source, Group) H3Server HID multicasts
MobilityClients <> ClientXTR <Network Provider > EdgeRTR MobilityClients <> ClientXTR <Access Provider > EdgeRTR v
|| v
< Map-Assisted Mobility-Network Overlay> v << Map-Assisted Mobility-Network Overlay << v
|| v
EdgeRTR <Cloud Provider> ServerXTR <> H3Servers >> EdgeRTR <Cloud Provider> ServerXTR <> H3Servers
6. Mobility Unicast and Multicast 6. Mobility Unicast and Multicast
Which ever way a ClientXTR is homed to an Edge RTR, via DNS metro load-balance Which ever way a ClientXTR is homed to an Edge RTR, via DNS metro load-balance
or via a well known geo-spatial map of IPs (a few 10Ks per large metro area), or via a well known geo-spatial map of IPs (a few 10Ks per large metro area),
an authenticated MobilityClient EID can send: [64bitH3.15ID :: 64bitState] an authenticated MobilityClient EID can send: [64bitH3.15ID :: 64bitState]
annotation to the H3.r9 HID server. The H3.r9 IP HID can be calculated by annotation to the H3.r9 HID server. The H3.r9 IP HID can be calculated by
clients algorithmically form the H3.15 localized snapped-to-tile annotation. clients algorithmically form the H3.15 localized snapped-to-tile annotation.
The ClientXTR encapsulates MobilityClient EID and the H3Server HID in a The ClientXTR encapsulates MobilityClient EID and the H3Server HID in a
skipping to change at line 330 skipping to change at line 349
* RTRs can map-resolve re-tunnel HIDs to remote RTR RLOC * RTRs can map-resolve re-tunnel HIDs to remote RTR RLOC
(3) RTRs re-encapsulate original source-dest to ServerXTRs (3) RTRs re-encapsulate original source-dest to ServerXTRs
ServerXTRs decapsulate packet and serve the original packet to H3Server ServerXTRs decapsulate packet and serve the original packet to H3Server
Each H3.r9 Server is used by clients to update H3.r15 tile state is also an IP Each H3.r9 Server is used by clients to update H3.r15 tile state is also an IP
Multicast channel Source used to update subscribers on the aggregate state of Multicast channel Source used to update subscribers on the aggregate state of
the H3.r15 tiles in the H3.r9 Server. the H3.r15 tiles in the H3.r9 Server.
We use rfc8378 signal free multicast to implement mcast channels in the We use rfc8378 signal free multicast to implement mcast channels in the
overlay. The mobility network has many channels and relatively few overlay. The mobility network has many channels and relatively few
subscribers per each one. MobilityClients driving through or subscribing to a subscribers per each. MobilityClients driving through or subscribing to a
a H3.r9 area can explicitly issue an rfc4604 MLDv2 in-order to subscribe, or, a H3.r9 area can explicitly issue an rfc4604 MLDv2 in-order to subscribe, or,
it may be subscribed implicitly by the EdgeRTR gleaning to ucast HID dest. may be subscribed implicitly by the EdgeRTR gleaning to ucast HID dest.
The advantage of explicit client MLDv2 registration trigger to rfc8378 is The advantage of explicit client MLDv2 registration trigger to rfc8378 is
that the clients manage their own mobility mcast hand-over according to their that the clients manage their own mobility mcast hand-over according to their
location-direction moment vectors, and its allows for otherwise silent, or, location-direction moment vectors, and that it allows for otherwise silent, or,
non annotating clients. The advantage of EdegRTR implicit registration is non annotating clients. The advantage of EdegRTR implicit registration is
less signaling required. At any case MLDv2 signaling messages are encapsulated less signaling required.
between the ClientXTR and the LISP EdgeRTR, therefore there is no requirement
for the underlying network to support native multicast. If native access MLDv2 signaling messages are encapsulated between the ClientXTR and the LISP
multicast is supported (for example eMBMS native 5G), then MobilityClient EdgeRTR, therefore there is no requirement for the underlying network to
registration to H3Server road-safety channels may be integrated to it, in support native multicast. If native access multicast is supported (for example
which case the evolved-packet-core (EPC) element supporting it (eNB) will use native 5G multicast), then MobilityClient registration to H3Server road-safety
this standard to register with the appropriate H3.r9 channels in its area. channels may be integrated to it, in which case the evolved-packet-core (EPC)
element supporting it (eNB) will use this standard to register with the
appropriate H3.r9 channels in its area.
EdgeRTRs note the subscribed MobilityClient stack XTRs and register as channel EdgeRTRs note the subscribed MobilityClient stack XTRs and register as channel
subscribers in the mapping system (Source, Group) entry. This is done at the subscribers in the mapping system (Source, Group) entry. This is done at the
first subscription request, if additional MobilityClients homed to the same first subscription request, if additional MobilityClients homed to the same
EdgeRTR register for the same channels the EdgeRTR registration covers them. EdgeRTR register for the same channels the EdgeRTR registration covers them.
Upon receiving a multicast packet the EdgeRTR homing H3.r9 Servers resolve Upon receiving a multicast packet the EdgeRTR homing H3.r9 Servers resolve
the (S,G) remote EdgeRTRs registered for the channel and replicates the packet. the (S,G) remote EdgeRTRs registered for the channel and replicates the packet.
` The remote EdgeRTRs homing MobilityClients in-turn replicate the packet to the ` The remote EdgeRTRs homing MobilityClients in-turn replicate the packet to the
MobilityClients registered with them. MobilityClients registered with them.
We expect an average of 600 H3.r15 tiles of the full 10K possible in H3.r9 We expect an average of 600 H3.r15 tiles of the full 7^6 (~100K) possible in
to be part of any road. The H3.r9 server can transmit the status of all H3.r9 to be part of any road. The H3.r9 server can transmit the status of all
600 or just those with meaningful state based on update SLA and policy. 600 or just those with meaningful state based on update SLA and policy.
To Summarize: To Summarize:
(1) H3LISP Clients tune to H3.r9 mobility updates using rfc8378 (1) H3LISP Clients tune to H3.r9 mobility updates using rfc8378
H3LISP Client issue IGMP-Report registration to H3.r9 HIDs H3LISP Client issue MLDv2 registration to H3.r9 HIDs
ClientXTRs encapsulate IGMP-report to EdgeRTRs who register (s,g) ClientXTRs encapsulate MLDv2 to EdgeRTRs who register (s,g)
(2) ServerXTRs encapsulate updates to EdgeRTRs who map-resolve (s,g) RLOCs (2) ServerXTRs encapsulate updates to EdgeRTRs who map-resolve (s,g) RLOCs
EdgeRTRs replicate mobility update and tunnel to registered EdgeRTRs EdgeRTRs replicate mobility update and tunnel to registered EdgeRTRs
Remote EdgeRTRs replicate updates to registered ClientXTRs Remote EdgeRTRs replicate updates to registered ClientXTRs
7. Security Considerations 7. Security Considerations
The way to provide a security association between the ITRs and the The way to provide a security association between the ITRs and the
Map-Servers must be evaluated according to the size of the Map-Servers must be evaluated according to the size of the
deployment. For small deployments, it is possible to have a shared deployment. For small deployments, it is possible to have a shared
 End of changes. 14 change blocks. 
60 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/