| Internet-Draft | LISP Anycast | January 2024 |
| Sun, et al. | Expires 25 July 2024 | [Page] |
This document describes the usage of Locator/ID Separation Protocol (LISP) as a solution to implement Computing-Aware Traffic Steering (CATS). How LISP meets CATS requirements and how it fits to the control plane and data plane of CATS framework are presented.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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 25 July 2024.¶
Copyright (c) 2024 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 (https://trustee.ietf.org/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 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.¶
When a service has been distributed over many locations in the network, providing service by utilizing computing resources hosted in various servers is required to consider supporting delay-sensitive service and optimizing network loads. For that reason, Computing-Aware Traffic Steering (CATS) is a new routing approach to balance services using service-specific metrics instead of simply dispatching the service request in a static way or optimizing solely connectivity metrics [draft-ietf-cats-usecases-requirements]¶
To realize the CATS concept, CATS framework is described in [draft-ldbc-cats-framework]. A main feature of the CATS framework is the usage of a unique service identifier for multiple service instances in different locations. Since this concept is similar to the Locator/ID Separation protocol (LISP) described in [RFC6830], this protocol can be considered as one of the candidate protocols to implement CATS.¶
This draft dyncast proposed the CATS framework control plane and data plane design based on LISP and analyze the extension method of LISP to meet the CATS requirements defined in [draft-ietf-cats-usecases-requirements].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document is to be interpreted as described in [RFC2119]. This document uses the terminology described in [RFC6830], [RFC9299], [draft-ldbc-cats-framework].¶
Figure Figure 1 shows how LISP fits into CATS framework design¶
+------------------+
|CATS Control Plane|
| +--------------+ |
| |Mapping System| |
| +--------------+ | +--------+
| +------+ | |Service2| EID-B
| | C-PS | | |Contact | :
| +------+ | |Instance| RLOC1
+--------+---------+ +-+--------+
| |
| +---------+ | +--------+
....+... | C-SMA | | |Service1| EID-A
.. .. +---------+ | |Contact | :
: +-------+ : ___|LISP-ETR1|-+-|Instance| RLOC1
: | C-NMA | : / +---------+ +--------+
: +-------+ :/
+------+ +-------------+ : Underlay : +---------+ +--------+
|Client|--| LISP ITR |-:Infrastructure:----|LISP-ETR2|-+-|Service1| EID-A
+------+ +------+------+ : (RLOC-space) : +----+----+ | |Contact | :
| C-TC | C-PS | : (Overlay) : | | |Instance| RLOC2
+-------------+ ... .. +---+---+ | +--------+
........ | C-SMA | |
+-------+ +-+--------+
|Service2| EID-B
|Contact | :
|Instance| RLOC2
+--------+
LISP Endpoint ID (EID) is equivalent to CATS Service ID (CS-ID). It is an unique IPv4 or IPv6 address to identify a single service. It represents multiple instances of a service.¶
LISP Routing Locator (RLOC) is equivalent to CATS Instance Selector ID (CIS-ID). It is an IPv4 or IPv6 address of the Egress LISP Router that is connected to the a service instance. It is used as an identifier between multiple instance of the same service.¶
Each service’s set of possible service instances is represented by an EID-to-RLOC set mapping. Each RLOC set of an EID contains all possible service instances’ RLOCs. Different services connecting to the same Egress LISP router have the same RLOC. To support collected computing-aware metrics of each service instance, corresponding metrics can be mapped to each RLOC. An example of EID-to-RLOC set mapping are shown in the Figure 2 below.¶
Anycast EID RLOC-set
-----------------------------------------------------------
EID_A RLOC-set_A ({RLOC1, metric}, {RLOC2, metric})
EID_B RLOC-set_B ({RLOC1, metric}, {RLOC2, metric})
LISP Ingress and Egress Tunnel Routers (ITR and ETR) are equivalent to Ingress CATS-Forwarder and Egress CATS-Forwarder. They acts as gateways for clients and service instances. Based on the EID-RLOC mapping, the ITR route the packets to the corresponding ETR that has the specified RLOC in the mapping. LISP ITR and ETR are required to support LISP encapsulation.¶
To collect metrics and select optimized paths for a service request, other CATS framework components (C-TC, C-PS, C-NMA, C-SMA) remains the same as in [draft-ldbc-cats-framework]. C-SMA and C-PS can be implemented inside or outside LISP Routers. C-TC can be implemented inside LISP ITR.¶
The CATS control plane can use the LISP Mapping System for managing the mapping between each service and its candidate service instances alongside with their corresponding computing-aware metrics. LISP Mapping System is the logically centralized database component of LISP that store mapping between EIDs, RLOCs and their metrics. Similar to DNS, it allows ETRs to register service mappings, and ITRs to retrieve them when deciding the destination service of a service.¶
C-PS can be implemented in the LISP control plane or in the LISP ITR. If C-PS is inside the LISP control plane, C-PS decide the optimized path based on the information in the LISP Mapping System and reply only the best path to ITR. If C-PS is inside the ITR, ITR gets the EID-to-RLOC set mapping from the control plane. Then C-PS calculates and configures the best path for ITR.¶
LISP creates an RLOC space overlay network to the underlying Internet infrastructure. LISP routers forward packets via the RLOC space based on the optimized CATS paths.¶
Service_A
CATS +-------+
Map-Register Forwarder +---| EID_A |
(EID_A, RLOC2, <metric>) +-------+ | +-------+
(EID_B, RLOC2, ,metric>) | ETR_2 |-|
+-------+ | +-------+
| +---| EID_B |
CATS +------------------+ | RLOC2 +-------+
Host_1 Forwarder | +--------------+ |--+ Service_B
+--------+ +-------+ | | LISP | |
| EID_H1 |--| ITR_1 |----| | Control Plane| | Map-Register
+--------+ +-------+ | +--------------+ |(EID_A, RLOC3, <metric>)
RLOC1| RLOC-Space |(EID_B, RLOC3, <metric>)
| |--+ RLOC3
<---- +------------------+ |
Map-Reply CATS
(EID_A, RLOC-set_A, <metric>) Forwarder Host_2
(EID_B, RLOC-set_B, <metric>) +-------+ +--------+
| ETR_3 |---| EID_H2 |
+-------+ +--------+
|
+-----+-----+
| |
+-------+ +-------+
| EID_A | | EID_B |
+-------+ +-------+
Service_A Service_B
Figure 3 shows an example of CATS framework workflow when using LISP-based dyncast deployment where two services each deployed two instances at different sites. In this scenario, two services are assigned an RLOC according to the ETR address of the LISP site. Both Service_A and Service_B instances connected to ETR_2 and ETR_3 are assigned RLOC2 and RLOC3 as the binding CIS-ID, respectively ID. According to this figure, the CATS’s Metrics Distribution and Service Demand Processing workflow can be explained below. As for service announcement, as stated in [draft-ldbc-cats-framework], a rendezvous service such as DNS can be used.¶
Service-instance-related metrics collected by C-SMA can be distributed from the LISP ETR to the LISP Control Plane Mapping System via the LISP Map-Register message. The default Map-Register message includes the corresponding service’s Anycast EID and the RLOC. Metrics can be inserted into the LISP protocol using several methods such as using header (Details of these methods are discussed in later sections). As shown in the example in Figure 3, after collecting metrics, each ETR send the Map-Register messages to the control plane to update the metrics of each service that are connecting to the ETR.¶
At the LISP ITR, when it recieves a service demand, the C-TC classifies the request. If a matching entry is found, the request is forwarded via the path decided by the C-PS. C-PS retrieves the candidate paths for an anycast EID from the LISP Control Plane via the LISP Map-Request/Reply message. As described above, C-PS can be implemented at ITR or at the control plane. In the example in Figure 3, when the ITR_1 receives a packet destined for the EID of the service by service request from the Host_1, if the C-PS is at ITR, the ITR can acquire the RLOC-set of the requested EID from the LISP control plane through the LISP Map-Request message. Then from the LISP Map-Reply information, the C-PS chooses the best path and configures the ITR. Otherwise if the C-PS is at the control plane, only the best RLOC from the RLOC set is sent to the ITR via the LISP Map-Reply message.¶
After resolving the path, the ITR encapsulates the data packets with the RLOC of the destined ETR and forwards the packet to that ETR through the RLOC space as described in [RFC9299].¶
In this part, we analyze how LISP-based approach can solve CATS requirements described in [draft-ietf-cats-usecases-requirements]¶
To support dynamic service instance selection, the system must provide a method for searching a service identifier 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 EID to each service instance for service equivalency, the LISP can define an anycast address space for the Anycast EID and assign it to service instances created across multiple sites. Also, the CIS-ID 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 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 CS-ID 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-EID-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 CATS, 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.¶
To maintain “Instance Affinity”, it is required 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 EID 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 anycast EID mapping that points to RLOC-set.¶
In addition, although the general TTL value in LISP ITR is defined as 24 hours, the CATS 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].¶
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 controller function which collects service-instance-related metrics updates them to the EID mapping entry in the LISP control plane. For that, it can be used an encoding method proposed in [draft-ietf-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 EID side, the agent function may be needed to 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.¶
CATS system is required to make routing decisions for all service requests, and this must be done by 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 (equals to C-PS) dynamically sets the priority and weight values of each mapped RLOCs, 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 EID to the ITR, including priority and weight values based on the collected metrics. After receiving these metrics, 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 EID-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 breaking session connection. So, for a particular EID in ITR's map-cache, it should be cared to use an RLOC-set above with each RLOC priority=1.¶
In the decentralized CATS architecture described in [draft-ldbc-cats-framework], the CATS-Forwarder can collect metrics by exchanging metric information of the service identifier between another CATS-Forwarders 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 CATS-Forwarder 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 EID 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.¶
For service dynamism, the 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 5.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 EID-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.¶
TBD¶