Skip to main content

LISP Support for Dynamic Anycast Routing

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors KJ Sun , Younghan Kim
Last updated 2022-04-28
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Network Working Group                                             K. Sun
Internet-Draft                                                      ETRI
Intended status: Informational                                    Y. Kim
Expires: 30 October 2022                             Soongsil University
                                                           28 April 2022

                LISP Support for Dynamic Anycast Routing


   Dynamic Anycast (Dyncast) is a new routing approach to support
   equivalent services running in distributed geolocations and connect
   to them by considering both network-related metric and service-
   related metric.  In LISP, it is possible to support anycast EIDs and/
   or anycast RLOCs without any modification, so it is suitable for
   providing dyncast routing.  In this document, it describes the LISP-
   based dyncast architecture and related standard works to meet dyncast

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 30 October 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

Sun & Kim                Expires 30 October 2022                [Page 1]
Internet-Draft                LISP Anycast                    April 2022

   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   3
   4.  Addressing Dyncast Requirements with LISP . . . . . . . . . .   6
     4.1.  Anycast-based Service Addressing  . . . . . . . . . . . .   6
     4.2.  Instance Affinity . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Encoding and Signaling of Metric  . . . . . . . . . . . .   8
     4.4.  Dynamic Routing Decisions based using Metrics . . . . . .   9
     4.5.  Supporting Service Dynamism . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   With emerging that multiple edge sites deployed at different
   locations and had different capacity to provide a service with edge
   computing, when the clients requests service, there is a requirement
   to make "best" decision to select edge node among requested service
   running simultaneously on multiple edges.  While distributing service
   requests to a specific service having multiple instances attached to
   multiple edges, one of solution is to take into account computing as
   well as service-specific metrics in the distribution decision seen as
   dynamic anycast ("dyncast", for short).

   The main feature of the dyncast described in
   [draft-liu-dyncast-ps-usecases] is that a unique service identifier
   that can be assigned to multiple instances in multiple edge
   environments should be able to be mapped as an actual routable
   unicast address.  Since this concept is similar to the Location/ID
   separation method already used in the LISP design basis, the LISP
   protocol can be considered as one of the candidate protocols that can
   implement dyncast.  This draft is proposed to design the LISP-based
   architecture for Dyncast and analyze the extension method of LISP to
   meet the requirements defined in [draft-liu-dyncast-reqs] for
   realizing dynamic anycasting between different LISP sites.

Sun & Kim                Expires 30 October 2022                [Page 2]
Internet-Draft                LISP Anycast                    April 2022

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document is to be interpreted as described in [RFC2119].  This
   document uses the terminology described in [RFC6830],
   [draft-liu-dyncast-ps-usecases], [draft-liu-dyncast-reqs].  Detailed
   definition of terminologies are written below.

   Dyncast : As defined in [draft-liu-dyncast-ps-usecases], Dynamic
   Anycast, taking the dynamic nature of computing resource metrics into
   account to steer an anycast routing decision.

   D-Router: A node supporting Dyncast functionalities as described in
   this document.  Namely it is able to understand both network-related
   and service-instances-related metrics, take forwarding decision based
   upon and manitain instance affinity, i.e., forwards packets belonging
   to the same service demand to the same instance.

   Dyncast Metric Agent (D-MA): A dyncast specific agent able to gather
   and send metric updates (from both network and instance prespective)
   but not performing forwarding decisions.  May run on a D-Router, but
   it can be also implementated as a separate module (e.g., a software
   library) collocated with a service instance.

   Dyncast Service Endpoint ID (DSEID) : Anycast IP address assigned to
   the service running on distributed locations.  DSEID cannot be routed
   globally, and it is unique for specific service.  Multiple service
   instances which are same service have a same DSEID.

   D-BID: Dyncast Binding D-Node, an address to reach a service instance
   for a given DSEID.  It is usually a unicast IP where service
   instances are attached.  Different service instances provide the same
   service identified through D-SID but with different Dyncast Binding
   IDs.  In the LISP architecture, D-BIDs of same service are replaced
   to RLOC-set of DSEID.

3.  Architecture Overview

   Figure 1 describes the LISP use-case for dynamic anycast.  In the
   LISP architecture [draft-ietf-lisp-introduction-13], each edge
   network has one or more LISP routers deployed.  For anycast address,
   [RFC6830] defines that anycast address can be assigned for both
   Endpoint ID (EID) and Routing Locator (RLOC) within each of their
   address spaces.  In this draft, we called EID for dynamic anycasting
   as Dyncast Service Endpoint ID (DSEID), which is assigned to
   equivalent services across the multiple LISP sites.  Similar to the
   common EID definition, the DSEID cannot be routed globally by itself,

Sun & Kim                Expires 30 October 2022                [Page 3]
Internet-Draft                LISP Anycast                    April 2022

   and the same DSEID cannot be assigned to different services.  In
   order to forward a packet destined for a DSEID between LISP edges,
   the addresses of the LISP Egress Tunnel Router (ETR) are used as
   RLOC-set, which was difined as a Dyncast Binding ID (D-BID) in
   [draft-li-dyncast-architecture].  Unlike D-BID which is routable and
   unique for all each service instance, RLOC-set is routable in the
   underlay but it is not unique values per each service instances.
   When multiple services are running in the same LISP site, they can be
   assigned the same RLOC which is xTR of their LISP site.  Map-server/
   resolver of the LISP control plane can manage mapping information for
   DESID-to-RLOC-set mappings together with existing EID-to-RLOC

   For resource-efficient forwarding decisions across multiple service
   instances, [draft-li-dyncast-architecture] defines Dyncast Metric
   Agent (D-MA) which collects metrics related network and service
   instances.  Actual packet forwarding is handled in the Dyncast Router
   (D-Router) based upon collected metrics with maintaining instance
   affinity.  In the LISP architecture, the D-Router and D-MA function
   can be implemented on each LISP ETR, or can be deployed as separate
   components within the edge for managing service instances.  The LISP
   control plane is logically centralized and it provides an interface
   with each LISP router to exchange mapping information.  However, it
   does not mean that the LISP control plane is located in a single
   physical location, several mechanisms for distributing the mapping
   system already have been defined.

                      |LISP Control Plane|
                               |           +--------+   +--------+
                               |        ___|LISP-ETR|---|Service1| DESID
                           .........  /    +--------+   +--------+
                         ..         ..
  +------+  +--------+  :    Core     :    +--------+   +--------+
  |Client|--|LISP ITR|-:    Network    :---|LISP-ETR|---|Service1| DESID
  +------+  +--------+  :(RLOC-space) :    +--------+   +--------+
    EID                  ..         ..
                           .........   \   +--------+   +--------+
                                        \__|LISP-ETR|---|Service1| DESID
                                           +--------+   +--------+

               Figure 1: LISP use-case for Dynamic anycast

   Figure 3 shows an example of LISP-based dyncast deployment where two
   services each deployed two instances at different edges.  In this
   scenario, two services are assigned an RLOC according to the ETR

Sun & Kim                Expires 30 October 2022                [Page 4]
Internet-Draft                LISP Anycast                    April 2022

   address of the LISP site.  Both Service_A and Service_B instances
   connected to ETR_2 are assigned RLOC2, which is the RLOC of ETR_2, as
   a binding ID.  According this figure, DSEID-to-RLOC-set mappings can
   be configured as an example below.

        DSEID                 RLOC-set
        DSEID_A          RLOC-set_A ({RLOC2, metric}, {RLOC3, metric})
        DSEID_B          RLOC-set_B ({RLOC2, metric}, {RLOC3, metric})

                    Figure 2: DSEID-to-RLOC-set Example

   In addition to these examples, the RLOC-set can also be used in the
   form of Explicit Locator Path (ELP) or Run-Length Encoding (RLE) for
   the encap-path between ETR and ITR.

   In the case of the edge where ETR_2 is located, as an edge composed
   only of service instances, the LISP Router function can be operated
   by being strongly coupled to the edge computing server.  In this
   case, the D-MA function can be implemented on the ETR to insert
   service-instance-related metrics directly into the LISP protocol
   packet.  In case that a service instance and a client co-exist like
   an edge where ETR_3 is located, the D-MA entity can be independently
   deployed proximity of the service instance is running, transparent
   from the LISP operation for clients.  Mapping information update for
   DSEID is performed through the LISP protocol Map-Register message,
   and service-instance-related metric can be delivered through in the
   LISP protocol header or other methods.  A method of inserting
   service-instance-related metric information into the LISP protocol
   will be discussed later.  When the ITR_1 receives a packet destined
   for the DSEID of the service by service request from the Host_1, the
   ITR can acquire the RLOC-set of the requested DSEID from the LISP
   control-plane through the Map-Request message.  At the control plane,
   it may select a proper RLOC on the collected metric information and
   return it to the ITR or return the RLOC-set of multiple service
   instances with metric information to the ITR so the ITR selects the
   proper RLOC in the set.  A method for determining an appropriate RLOC
   will be discussed later.

Sun & Kim                Expires 30 October 2022                [Page 5]
Internet-Draft                LISP Anycast                    April 2022

                   Map-Register              D-Router        +-|DSEID_A|
                 (DSEID_A, RLOC2, <metric>) +-------+------+ | +-------+
                 (DESID_B, RLOC2, ,metric>) | ETR_2 | D-MA |-|
                                            +-------+------+ | +-------+
                                                |            +-|DSEID_B|
                          +------------------+  | RLOC2        +-------+
   Host_1     D-Router    | +--------------+ |--+             Service_B
 +--------+  +-------+    | |     LISP     | |
 | EID_H1 |--| ITR_1 |----| | Control Plane| | Map-Register
 +--------+  +-------+    | +--------------+ |(DSEID_A, RLOC3, <metric>)
                     RLOC1|    RLOC-Space    |(DSEID_B, RLOC3, <metric>)
                          |                  |--+ RLOC3
                    <---- +------------------+  |
           Map-Reply                        D-Router      Host_2
          (DSEID_A, RLOC-set_A, <metric>)   +-------+   +--------+
          (DSEID_B, RLOC-set_B, <metric>)   | ETR_3 |---| EID_H2 |
                                            +-------+   +--------+
                                             | D-MA |
                                          |           |
                                      +-------+     +-------+
                                      |DSEID_A|     |DSEID_B|
                                      +-------+     +-------+
                                      Service_A    Service_B

             Figure 3: LISP-based Dyncast Example Scenario

4.  Addressing Dyncast Requirements with LISP

4.1.  Anycast-based Service Addressing

   To support dyncast routing, the system must provide a method for
   searching a service identifier allocated as an anycast address and
   mapping it to a specific unicast address.  From this point of view,
   the LISP is a suitable protocol for separating ID/Location of service
   and managing mapping information.  When the system allocates the same
   DSEID to each service instance for service equivalency, the LISP can
   define an anycast address space for the DSEID and assign it to
   service instances created across multiple sites.  Also, the D-BID can
   be replaced to an RLOC address of LISP xTR that can be routed between
   edges as unicast.  That is, it is necessary to define a separate

Sun & Kim                Expires 30 October 2022                [Page 6]
Internet-Draft                LISP Anycast                    April 2022

   space for anycast address within the existing EID space and to
   allocate it in advance so that it can be used in all edge networks
   where the service instances are located.  In the LISP definition, the
   EID assigned to each service has a globally unique value and, in
   particular, [RFC6830] defines that anycast address can be assigned
   within an EID or RLOC block spaces.  In each LISP site, same as the
   EID which is defined to enable internal routing, the DSEID can be
   able to be routed without the RLOC encapsulation process to the EID
   within a single site.

   One of alternative addressing solution is to use anycast-SEID-to-
   anycast-RLOC mapping.  Using this, it is required to register from
   one place (an SDN controller) or each ETR registering the same RLOC
   without any merge semantics.  So the service is chosen by destination
   address in a packet (the anycast-EID) which maps to an anycast-RLOC
   where the underlay takes you to the "closest" LISP site.  However, in
   the dyncast, routing selection is not depending on just distance but
   also computing resources of each service location.  Depending on
   dynamics of these metrics, anycast-RLOC should be registered/
   deregistered at the ETR depending on the absence of specific anycast-
   EID.  Further discussion is required which is more efficient rather
   than using indirection mapping and update it with unicast-RLOC with
   metric information.

4.2.  Instance Affinity

   For dyncast routing, it is required that the system must set
   "Instance Affinity" for one or several service requests to provide
   routing to the same service instance for the same flow.  In LISP, the
   RLOC mapping information for the destination EID is stored in a local
   cache called Map-cache in the ITR for a certain period of time, and
   it is maintained for a set time-to-live (TTL) time.  Therefore,
   mapping information for a specific service once requested from a
   client is generally maintained in the ITR until the corresponding
   session expires and can be delivered to the RLOC stored in the map-
   cache entry.  However, in order to have a flexible selection of
   service instances between different flows at the same point, it is
   additionally required to assign different RLOCs for different flows
   depending on metrics dynamically changed.  For that, it is necessary
   to enhance ITR Map-cache to maintain destination RLOC for each flow.
   In [draft-rodrigueznatal-lisp-multi-tuple-eids], it can be supported
   to store Multi-Tuple Extend-EID mappings.  With Multi-Tuple EID
   mappings, it is possible to provide RLOC affinity depending on its
   destination DSEID as well as other information such as source EID,
   protocol or port number.  For that, it is required to support multi-
   stage lookup process, where the multi-tuple EID mappings that point
   to an DSEID and then there is a DSEID mapping that points to RLOC-

Sun & Kim                Expires 30 October 2022                [Page 7]
Internet-Draft                LISP Anycast                    April 2022

   In addition, although the general TTL value in LISP ITR is defined as
   24 hours, in dyncast the system requires a shorter TTL time for
   changing network path depending on dynamically updated network-
   related and service-instance-related metrics.  The LISP support to
   send a refresh Map-Request before removing map-cache entry.  If it
   needs a shorter TTL to update the map-cache, two options are
   possible.  First option is to send Solicit Map-Request(SMR) for
   refreshing cache, and another option is to use Pub/Sub which is
   described in [draft-ietf-lisp-pubsub].

4.3.  Encoding and Signaling of Metric

   In dyncast routing, the one of most important requirements is that it
   should be able to collect various metrics of service-instances-
   related as well as network-related, and include them in-network
   routing decisions.  For that, it is necessary to define how to
   collect these metrics and forward them, and also where to make a
   decision.  In the LISP environment, since that the entire EID-RLOC
   mapping information is managed in the control plane, one possible
   scenario is that the D-MA function which collects service-instance-
   related metrics updates them to the DSEID mapping entry in the LISP
   control plane.  For that, it can be used an encoding method proposed
   in [draft-farinacci-lisp-name-encoding] that defines to insert
   specific information such as parameters for a specific EID or RLOC
   using an ASCII string.  Using that, it is possible to encode a string
   that is pre-defined of a specific metric to interpret in the control
   plane and send a Map-Request message so that the control plane can
   select an appropriate RLOC based on it.  Another possible option is
   to use policy distribution by a network controller, which is proposed
   in [draft-kowal-lisp-policy-distribution].  Using network controller,
   the ITR could receive and apply the QoS policies that would shape
   traffic to the correct rate on each ITR RLOC interface.  In order to
   insert service-instance-related metrics from the DSEID side, the D-MA
   must forward the metrics of the requested service to the LISP ITR so
   that the metric can be inserted into the header of the Map-Register
   message.  This metric information encoded into the Map-Register
   message can help the LISP control plane to make multi-tuple mapping
   entry and sent it to the requested ITR.  Once the requested ITR
   receives these information, it can make a routing decision based on
   the multi-tuple parameters.

Sun & Kim                Expires 30 October 2022                [Page 8]
Internet-Draft                LISP Anycast                    April 2022

4.4.  Dynamic Routing Decisions based using Metrics

   The dyncast system is required that in must make routing decisions
   for all service requests, and this must be done under an
   understanding of all metrics.  Routing decisions in the LISP can be
   done with two options which is done in the control plane or ITR by
   specifying priority and weight values for each RLOC.  In case that
   routing decisions are made in the control plane, the Map-Resolver
   dynamically sets the priority and weight values of each mapped RLOCs
   collected from D-MAs, selects a proper RLOC based on them, and
   forward it to the requested ITR using the Map-Reply message.
   However, since this centralized approach may not be calculated based
   on point of requested ITR, the actual routing path may not be
   optimal.  In case that routing decision is determined at the ITR, the
   LISP control plane may return one or more RLOC values for the
   requested DSEID to the ITR, including priority and weight values
   based on the collected metrics.  After receiving multiple DBIDs, the
   ITR stores them in map-cache entry and selects an appropriate one to
   forward the data packet.  For that, a mechanism for estimating
   appropriate priority and weight values based on both network-related
   and service-instance-related metrics is required for the control
   plane or ITR.  When DSEID-to-RLOC-set mapping is used, it is noted
   that if RLOCs in the set have equal priority, the ITR can load-split
   traffic across RLOCs and that cause to break session connection.  So,
   an ITR that is configured that a particular EID in its map-cache is
   an DSEID, it should be cared to use an RLOC-set above with each RLOC

   In the dyncast architecture described in
   [draft-li-dyncast-architecture], the D-Router collects metrics by
   exchanging metric information of the service identifier between
   another edge D-Routers and make a decision itself.  This approach can
   minimize the signaling for routing decisions by decentralizing the
   authority for the anycast routing decision to an entity in the actual
   packet path, but the signaling for collecting metrics between each
   D-Router is bound to increase.  In contrast, when the LISP is used,
   it can reduce effectively signaling of collecting metrics from the
   ITR since that the mapping information for DSEID and RLOC-set can be
   managed in a centralized control plane.  However, if the metrics
   change too much then the contents of the RLOC-set changes which
   requires more frequent map-cache updates.  So analyzing in depth of
   this tradeoff remains further studies.

Sun & Kim                Expires 30 October 2022                [Page 9]
Internet-Draft                LISP Anycast                    April 2022

4.5.  Supporting Service Dynamism

   For service dynamism, the dyncast system should support different
   selections for each flow according to a dynamically changing metric
   while considering various requirements in the selection of a service
   instance.  As mentioned in Section 4.2,
   [draft-rodrigueznatal-lisp-multi-tuple-eids] can provide the map-
   cache to be maintained for each flow, so the forwarding path can be
   dynamically changed to the different service instances by allocating
   target RLOC to the map-cache entry per-flow according to dynamic
   changes of metrics.  In order to refresh the DSEID-to-RLOC-set
   mapping upon changing metric, the Solicit Map-Request(SMR) message
   can be used to update so that the ITR can update the weight and
   priority for the RLOC which is already received from the Map-server.
   Additionally, as proposed in [draft-farinacci-lisp-telemetry],
   telemetry data can be collected between Encapsulating/Decapsulating
   xTRs of the current flow, which is expected to be used for dynamic
   service path reselection.

5.  Security Considerations


6.  References

6.1.  Informative References

              Farinacci, D., "LISP Distinguished Name Encoding", May
              2021, <

              Farinacci, D., Ouissal, S., and E. Nordmark, "LISP Data-
              Plane Telemetry", May 2021,

              Cabellos, A. and D. Saucez, "An Architectural Introduction
              to the Locator/ID Separation Protocol (LISP)", April 2015,

Sun & Kim                Expires 30 October 2022               [Page 10]
Internet-Draft                LISP Anycast                    April 2022

              Rodrigues-Natal, A., Ermagan, V., Cabellos, A., Barkai,
              S., and M. Boucadair, "Publish/Subscribe Functionality for
              LISP", June 2021, <

              Kowal, M., Portoles, M., Jain, A., and D. Farinacci, "LISP
              Transport for Policy Distribution", September 2021,

              Li, Y., Iannone, L., Trossen, D., and P. Liu, "Dynamic-
              Anycast Architecture", February 2021,

              Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast
              (Dyncast) Use Cases; Problem Statement", February 2021,

              Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast
              (Dyncast) Requirements", February 2021,

              Rodrigues-Natal, A., Cabellos-Aparicio, A., Barkai, S.,
              Ermagan, V., Lewis, D., Maino, F., and D. Farinacci, "LISP
              support for Multi-Tuple EIDs", October 2021,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997,

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830, January
              2013, <>.

Authors' Addresses

Sun & Kim                Expires 30 October 2022               [Page 11]
Internet-Draft                LISP Anycast                    April 2022

   Kyoungjae Sun
   218, Gajeong-ro, Yuseung-gu
   Republic of Korea
   Phone: +82 10 3643 5627

   Younghan Kim
   Soongsil University
   369, Sangdo-ro, Dongjak-gu
   Republic of Korea
   Phone: +82 10 2691 0904

Sun & Kim                Expires 30 October 2022               [Page 12]