LISP Predictive RLOCslispers.netSan JoseCAUSAfarinacci@gmail.comIndependentSan ClaraCAUSApadma.ietf@gmail.com
Routing
Network Working GroupLISP; EID; RLOC; privacyThis specification describes a method to achieve near-zero
packet loss when an EID is roaming quickly across RLOCs.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in .The LISP architecture specifies two
namespaces, End-Point IDs (EIDs) and Routing Locators (RLOCs). An
EID identifies a node in the network and the RLOC indicates the
EID's topological location. When an node roams in the network, its
EID remains fixed and unchanged but the RLOCs associated with it
change to reflect its new topological attachment point. This
specification will focus EIDs and RLOCs residing in separate
nodes. An EID is assigned to a host node that roams while the
RLOCs are assigned to network nodes that stay stationary and are
part of the network topology. For example, a set of devices on an
aircraft are assigned EIDs, and base stations on the ground
attached to the Internet infrastructure are configured as LISP
xTRs where their RLOCs are used for the bindings of the EIDs on
the aircraft up in the air.The scope of this specification will not emphasize general
physical roaming as an aircraft would do in the sky but in a
direction that is more predictable such as a train traveling on a
track or vehicle that travels along a road.is a network node that moves from
one topological location in the network to another. The network
node uses the same EID when it is roaming. That is, the EID
address does not change for reasons of mobility. A roaming-EID
can also be a roaming EID-prefix where a set of EIDs covered by
the prefix are all roaming and fate-sharing the same set of
RLOCs at the same time.is a set of ordered RLOCs in a
list each assigned to LISP xTRs where the next RLOC in the list
has high probability it will be the next LISP xTR in a physical
path going in a single predictable direction.is a network node that
acts as a router, more specifically as a LISP xTR. The xTR
automatically discovers roaming-EIDs that come into network
connectivity range and relays packets to and from the
roaming-EID. RSUs are typically deployed along a directional
path like a train track or road and are in connectivity range of
devices that travel along the directional path.The goal of this specification is to describe a
make-before-break EID-mobility mechanism that offers near-zero
packet loss. Offering minimal packet loss, not only allows
transport layers to operate more efficiently, but because an EID
does not change while moving, transport layer session continuity
is maintained. To achieve these requirements, a mechanism that
reacts to the mobility event is necessary but not sufficient. So
the question is not that there isn't a reaction but when it
happens. By using some predictive algorithms, we can guess with
high probability where the EID will roam to next. We can achieve
this to a point where packet data will be at the new location when
the EID arrives.First we should examine both the send and receive directions
with respect to the roaming-EID. Refer to for discussion. We show a network node with
a fixed EID address assigned to a roaming-EID moving along a train
track. And there are LISP xTRs deployed as Road-Side-Units to
support the connectivity between the roaming-EID and the
infrastructure or to another roaming-EID.
====//====//====//====//====//====//====//====//===//====//====//====
// // // // // // // // // // //
====//====//====//====//====//====//====//====//===//====//====//====
xTR xTR xTR xTR xTR xTR
A B C D E F
]]>For the send direction from roaming-EID to any destination can
be accomplish as a local decision. As long as the roaming-EID is
in signal range to any xTR along the path, it can use it to
forward packets. The LISP xTR, acting as an ITR, can forward
packets to destinations in non-LISP sites as well as to stationary
and roaming EIDs in LISP sites. This is accomplished by using the
LISP overlay via dynamic packet encapsulation. When the
roaming-EID sends packets, the LISP xTR must discover the EID and
MAY register the EID with a set of RLOCs to the mapping system
. The discovery
process is important because the LISP xTR, acting as an ETR for
decapsulating packets that arrive, needs to know what local ports
or radios to send packets to the roaming-EID.Much of the focus of this design is on the packet direction to
the roaming-EID. And how remote LISP ITRs find the current
location (RLOCs) quickly when the roaming-EID is moving at high
speed. This specification solves the fast roaming with the
introduction of the Predictive-RLOCs algorithm.Since a safe assumption is that the roaming-EID is going in one
direction and cannot deviate from it allows us to know a priori
the next set of RLOCs the roaming-EID will pass by. Referring to
, if the roaming-EID is in range near
xTR-A, then as it moves, it will at some point pass by xTR-B and
xTR-C, and so on. As the roaming-EID moves, one could time when
the EID is mapped to RLOC A, and when it should change to RLOC B
and so on. However, the speed of movement of the roaming-EID won't
be constant and the variables involved in consistent timing cannot
be relied on. Furthermore, timing the move is not a
make-before-break algorithm, meaning the reaction of the binding
happens at the time the roaming-EID is discovered by an xTR. One
cannot achieve fast hand-offs when message signaling will be
required to inform remote ITRs of the new binding.The Predictive RLOCs algorithm allows a set of RLOCs, in an
ordered list, to be provided to remote ITRs so they have the
information available and local for when they need to use it.
Therefore, no control-plane message signaling occurs when the
roaming-EID is discovered by LISP xTRs.Predictive RLOCs accommodates for encapsulated packets to be
delivered to Road-Side-Unit LISP xTRs regardless where the
roaming- EID is currently positioned.Referring to , the following
sequence is performed:The Predictive RLOCs are registered to the mapping system as
a LCAF encoded Replication List Entry (RLE) Type . The registration can happen by
one or more RSUs or by a third-party. When registered by an RSU,
and when no coordination is desired, they each register their
own RLOC with merge-semantics so the list can be created and
maintained in the LISP Map-Server. When registered by a
third-party, the complete list of RLOCs can be included in the
RLE.There can be multiple RLEs present each as different RLOC-
records so a remote ITR can select one RLOC-record versus the
other based in priority and weight policy .When a remote ITR receives a packet destined for a
roaming-EID, it encapsulates and replicates to each RLOC in the
RLE thereby delivering the packet to the locations the
roaming-EID is about to appear. There are some cases where
packets will go to locations where the roaming-EID has already
been, but see for packet delivery
optimizations.When the ETR resident RSU receives an encapsulated packet, it
decapsulates the packet and then determines if the roaming-EID
had been previously discovered. If the EID has not been
discovered, the ETR drops the packet. Otherwise, the ETR
delivers the decapsulated packet on the port interface the
roaming-EID was discovered on.The LCAF Replication List
Entry (RLE) will be used to encode the Predictive RLOCs in an
RLOC-record for Map-Registers, Map-Reply, and Map-Notify
messages .When the RLOC-record contains an RLE with RLOC entries all
with the same level value, it means the physical order listed is
the directional path of the RSUs. This will typically be the
result of a third-party doing the registration where it knows
ahead of time the RSU deployment.When each RSU is registering with merge-semantics on their
own, the level number is used to place them in an ordered
list. Since the registrations come at different times and
therefore arrive in different order than the physical RSU path,
the level number creates the necessary sequencing. Each RSU
needs to know its position in the path relative to other
RSUs. For example, in xTR-B, it would register with level 1
since it is after xTR-A (and before xTR-C). So if the
registration order was xTR-B with level 1, xTR-C with level 2,
and xTR-A with level 0, the RLE list stored in the mapping
system would be (xTR-A, xTR-B, xTR-C). It is recommended that
level numbers be assigned in increments of 10 so latter
insertion is possible.The use of Geo-Prefixes and Geo-Points can be used to compare the
physical presence of each RSU with respect to each other, so
they can choose level numbers to sequence themselves. Also if
the xTRs register with a Geo-Point in an RLOC-record, then
perhaps the Map-Server could sequence the RLE list.Since the remote ITR will replicate to all RLOCs in the RLE,
a situation is created where packets go to RLOCs that don't need
to. For instance, if the roaming-EID is along side of xTR-B and
the RLE is (xTR-A, xTR-B, xTR-C), there is no reason to
replicate to xTR-A since the roaming-EID has passed it and the
the signal range is weak or lost. However, replicating to xTR-B
and xTR-C is important to deliver packets to where the
roaming-EID resides and where it is about to go to.A simple data-plane option, which converges fairly quickly is
to have the remote xTR, acting as an ETR, when packets are sent
from the roaming-EID, examine the source RLOC in the outer
header of the encapsulated packet. If the source RLOC is xTR-B,
the remote xTR can determine that the roaming-EID has moved past
xTR-A and no longer needs to encapsulate packets to xTR-A's
RLOC.In addition, the remote ITR can use RLOC-probing to determine
if each RLOC in the RLE is reachable. And if not reachable,
exclude from the list of RLOCs to replicate to.This solution also handles the case where xTR-A and xTR-B may
overlap in radio signal range, but the signal is weak from the
roaming-EID to xTR-A but stronger to xTR-B. In this case, the
roaming-EID selects xTR-B to send packets that inform the remote
xTR that return packets should not be encapsulated to xTR-A.There are also situations where the RSUs are in signal range
of each other in which case they could report reachability
status of each other. The use of the Locator-Status-Bits of the
LISP encapsulation header could be used to convey this
information to the remote xTR. This would only occur when the
roaming-EID was discovered by both xTR-A and xTR-B so it was
possible for either xTR to reach the roaming-EID. Either an IGP
like routing protocol would be required to allow each xTR to
know the other could reach the roaming-EID or a path trace tool
(i.e. traceroute) could be originated by one xTR targeted for
the roaming-EID but MAC-forwarded through the other xTR. These
and other roaming-EID reachability mechanisms are work in
progress and for further study.When a remote ITR is doing "Directional Mobility" and
replicating to the last RLOC in the RLE list, it has a decision
to guess where the roaming-EID will move to next.
Conservatively, an ITR can replicate to the entire set of RLOCs
in the RLE list and wait to see if the roaming-EID moves to one
of the RLOCs in the RLE list.Or more liberally, the remote ITR can assume the new roaming
direction. For example, with an RLE list of (xTR-A, xTR-B,
xTR-C, xTR-D) and the roaming-EID is at D, the remote ITR can
replicate to all of A, B, C and D to determine where the
roaming-EID will move to next. If the roaming-EID moves to C after it
was at D, it is possible that the EID is moving in the opposite
direction from C to B to A. This would be known as "Back-n-Forth
Mobility". If an implementation is configured to support this
for a particluar EID, the remote ITR could replicate in this
sequence as the roaming-EID moves from A to D and back to A: (A,
B, C, D), (B, C, D), (C, D), (D, C, B, A), (C, B, A), (B, A),
and again (A, B, C, D).The roaming-EID could be doing "Circular Mobility" where it
moves from A to D directionally, next from D-to-A, and then back
to A to D directionally again. This form of mobility is just as
predicatable as "Back-n-Forth Mobility" since a consistent
pattern can be relied on. Both of these mobility forms can be
achieved with near-zero packet loss.On the other hand, the roaming-EID can be roaming arbitrarily
using "Random Mobility" where it could roam in the following
combinations: A-to-B, A-to-C, A-to-D, B-to-A, B-to-C, B-to-D,
C-to-A, C-to-B, C-to-D, D-to-A, D-to-B, or D-to-C. In this
situation, when a return packet arrives at the ITR, it could
then just replicate to where the roaming-EID is at rest and
do so for a short period of time before it replciates to
the entire RLE list again. Using the wrong time period could lead
to packet loss. All these types of mobility can be supported by
the remote ITR in a local manner without consulting or depending
on any other LISP system. It is left for further study, if any
of the mobility types above should be encoded in the mapping
system.If RLE lists are large, packet replication can occur to
locations well before the roaming-EID arrives. Making RLE lists
small is useful without sacrificing hand-off issues or incurring
packet loss to the application. By having overlapping RLEs in
separate RLOC-records we a simple mechanism to solve this
problem. Here is an example mapping entry to illustrate the
point:, RLOC-records:
RLOC = (RLE: xTR-A, xTR-B)
RLOC = (RLE: xTR-B, xTR-C, xTR-D, xTR-E)
RLOC = (RLE: xTR-E, xTR-F)
]]>When the remote ITR is encapsulating to xTR-B as a decision
to use the first RLOC-record, it can decide to move to use the
second RLOC-record because xTR-B is the last entry in the first
RLOC-record and the first entry in the second RLOC-record. When
there are overlapping RLEs, the remote ITR can decide when it is
more efficient to switch over. For example, when the roaming-EID
is in range of xTR-A, the remote ITR uses the first RLOC-record
so the wasted replication cost is to xTR-B only versus a worse
cost when using the second RLOC-record. But when the roaming-EID
is in range of xTR-B, then replicating to the other xTRs in the
second RLOC-record may be crucial if the roaming-EID has
increased speed. And when the roaming-EID may be at rest in a
parked mode, then the remote ITR encapsulates to only xTR-F
using the third RLOC-record since the roaming-EID has moved past
xTR-E.In addition, to eliminate unnecessary replication to xTRs
further down a directional path, GEO-prefixes can be used so only nearby
xTRs that the roaming-EID is about to come in contact with are
the only ones to receive encapsulated packets.Even when replication lists are not large, we can reduce the
cost of replication that the entire network bears by moving the
replicator away from the the source (i.e. the ITR) and closer to
the RSUs (i.e. the ETRs). See the use of RTRs for Replication
Engineering techniques in .A roaming-EID could be registered to the mapping system with
the following nested RLE mapping:, RLOC-records:
RLOC = (RLE: xTR-A, xTR-B, xTR-C, (RLE: xTR-X, xTR-Y, xTR-Z),
(RLE: xTR-I, xTR-J, xTR-K), xTR-D, xTR-E)
]]>The mapping entry above describes 3 directional paths where the
ordered list has encoded one-level of two nested RLEs to denote
intersections in a horizontal path. Which is drawn as: | |
--------------------------------------- ------------------------------
--------------------------------------- ------------------------------
xTR-A xTR-B xTR-C | | xTR-D xTR-E
| |
| | xTR-X
| |
| |
| | xTR-Y
| |
| |
| | xTR-Z
]]>When the roaming-EID is on the horizontal path, the remote-ITRs
typically replicate to the rest the of the xTRs in the ordered
list. When a list has nested RLEs, the replication should occur to
at least the first RLOC in a nested RLE list. So if the remote-ITR
is replicating to xTR-C, xTR-D, and xTR-E, it should also
replicate to xTR-X and xTR-I anticipating a possible turn at the
intersection. But when the roaming-EID is known to be at xTR-D (a
left or right hand turn was not taken), replication should only
occur to xTR-D and xTR-E. Once either xTR-I or xTR-X is determined
to be where the roaming-EID resides, then the replication occurs
on the respective directional path only.When nested RLEs are used it may be difficult to get
merge-semantics to work when each xTR registers itself. So it is
suggested a third-party registers nested RLEs. It is left to
further study to understand better how to automate this.In this design, the remote ITR is receiving a unicast packet
from an EID and replicating and encapsulating to each RLOC in an
RLE list. This form of replication is no different than a
traditional multicast replication function. So replicating
multicast packets in the same fashion is a fallout from this
design.If there are multiple roaming-EIDs joined to the same multicast
group but reside at different RSUs, a merge has to be done of any
pruned RLEs used for forwarding. So if roaming-EID-1 resides at
xTR-A and roaming-EID-2 resides at xTR-B and the RLE list is
(xTR-A, xTR-B, xTR-C), and they are joined to the same multicast
group, then replication occurs to all of xTR-A, xTR-B, and xTR-C.
Even since roaming-EID-2 is past xTR-A, packets need to be
delivered to xTR-A for roaming-EID-1. In addition, packets need to
be delivered to xTR-C because roaming-EID-1 and roaming-EID-2 will
get to xTR-C (and roaming-EID-1 may get there sooner if it is
traveling faster than roaming-EID-2).When a roaming-EID is a multicast source, procedures from are used to deliver packets to multicast group
members anywhere in the network. The solution requires no
signaling to the RSUs. When RSUs receive multicast packets from a
roaming-EID, they do a (roaming-EID,G) mapping database lookup to
find the replication list of ETRs to encapsulate to.Note that roaming-EIDs can be assigned IPv6 EID addresses while
the RSU xTRs could be using IPv4 RLOC addresses. Any combination
of address-families can be supported as well as for multicast
packet forwarding, where (S,G) are IPv6 addresses entries and
replication is done with IPv4 RLOCs in the outer header.One can imagine there will be a large number of roaming-EIDs.
So there is a strong desire to efficiently store state in the
mapping database and the in remote ITRs map-caches. It is likely,
that roaming-EIDs may share the same path and move at the same
speed (EID devices on a train) and therefore share the same
Predictive RLOCs. And since EIDs are not reassigned for mobility
purposes or may be temporal , they will not be
topologically aggregatable, so they cannot compress into a single
EID-prefix mapping entry that share the same RLOC-set.By using a level of indirection with the mapping system this
problem can be solved. The following mapping entries could exist
in the mapping database:, RLOC-records:
RLOC = (afi=: "am-train-to-paris")
EID = , RLOC-records:
RLOC = (afi=: "am-train-to-paris")
EID = , RLOC-records:
RLOC = (afi=: "am-train-to-paris")
EID = "am-train-to-paris", RLOC-records:
RLOC = (afi=lcaf/RLE-type: xTR-A, xTR-B, xTR-C)
EID = "am-train-to-paris-passengers", RLOC-records:
RLOC = (afi=lcaf/afi-list-type: , , )
]]>Each passenger that boards a train has their EID registered to
point to the name, see for details, of the train
"am-train-to-paris". And then the train with EID
"am-train-to-paris" stores the Predictive RLOC-set. When a
remote-ITR wants to encapsulate packets for an EID, it looks up
the EID in the mapping database gets the name "am-train-to-paris"
returned. Then the remote-ITR does another lookup for the name
"am-train-to-paris" to get the RLE list returned.When new EIDs board the train, the RLE mapping entry does not
need to be modified. Only an EID-to-name mapping is registered for
the specific new EID. Optionally, another name
"am-train-to-paris-passengers" can be registered as an EID to
allow mapping to all specific EIDs which are on the train. This
can be used for inventory, billing, or security purposes.This optimization comes at a cost of a 2-stage lookup. However,
if both sets of mapping entries are registered to the same
Map-Server, a combined RLOC-set could be returned. This idea is
for further study.LISP has procedures for supporting both control-plane security
and data-plane security .At this time there are no requests for IANA.The author would like to thank the LISP WG for their review and
acceptance of this draft.[RFC Editor: Please delete this section on publication as RFC.]Posted September 2024.Update references and document timer.Posted February 2024.Update references and document timer.Posted August 2023.Update references (to proposed standard documents) and document timer.Posted March 2023.Update references (to propsed standard documents) and document timer.Posted September 2022.Update draft-ietf-lisp-name-encdoing reference.Posted April 2022.Update document timer and references.Posted October 2021.Update document timer and references.Posted March 2021.Update document timer and references.Posted November 2020.Update document timer and references.Posted May 2020.Update document timer and references.Posted November 2019.Update document timer and references.Posted May 2019.Update document timer and references.Posted November 2018.Update document timer and references.Posted May 2018.Update document timer and references.Posted November 2017.Update document timer and references.Reflect comments from Prague meeting presentation. There is
no need for "RLE Usage Types" as suggested. The ITR can treat
what RLOCs it replicates to as a local matter via
implementation configuration. RLE Directional is
default. Circular rotation, back-n-forth, and random selection
of RLOCs is up to the ITR.Posted June 2017.Make this specification a working group document. It is a
copy of draft-farinacci-lisp-predictive-rlocs-02.Posted May 2017 to update document timer.Posted November 2016 to update document timer.Initial post April 2016.