Internet DRAFT - draft-kjsun-cats-lisp
draft-kjsun-cats-lisp
Network Working Group K. Sun
Internet-Draft ETRI
Intended status: Informational M. N. Tran
Expires: 25 July 2024 H. D. Phung
Y. Kim
Soongsil University
22 January 2024
Computing-Aware Traffic Steering (CATS) Using LISP
draft-kjsun-cats-lisp-01
Abstract
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.
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 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 Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sun, et al. Expires 25 July 2024 [Page 1]
Internet-Draft LISP Anycast January 2024
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Realizing CATS framework components with LISP . . . . . . . . 3
3.1. Equivalent CATS Identifiers . . . . . . . . . . . . . . . 4
3.2. Equivalent CATS Components . . . . . . . . . . . . . . . 4
3.3. Other CATS Components . . . . . . . . . . . . . . . . . . 4
3.4. CATS Control Plane . . . . . . . . . . . . . . . . . . . 5
3.5. CATS Data Plane . . . . . . . . . . . . . . . . . . . . . 5
4. Realizing CATS framework workflow with LISP . . . . . . . . . 5
4.1. Metrics Distribution . . . . . . . . . . . . . . . . . . 7
4.2. Service Demand Processing . . . . . . . . . . . . . . . . 7
5. Addressing CATS Requirements with LISP . . . . . . . . . . . 7
5.1. Support dynamic and effective selection among multiple
serivce instances . . . . . . . . . . . . . . . . . . . . 7
5.2. Support Instance Affinity . . . . . . . . . . . . . . . . 8
5.3. Support Metric Representation and Distribution . . . . . 9
5.4. Support Alternative Definition and Use of Metrics . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
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
Sun, et al. Expires 25 July 2024 [Page 2]
Internet-Draft LISP Anycast January 2024
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].
2. Terminology
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].
3. Realizing CATS framework components with LISP
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
+--------+
Sun, et al. Expires 25 July 2024 [Page 3]
Internet-Draft LISP Anycast January 2024
Figure 1: LISP in CATS framework
3.1. Equivalent CATS Identifiers
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})
Figure 2: EID-to-RLOC-set Example
3.2. Equivalent CATS Components
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.
3.3. Other CATS Components
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.
Sun, et al. Expires 25 July 2024 [Page 4]
Internet-Draft LISP Anycast January 2024
3.4. CATS Control Plane
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.
3.5. CATS Data Plane
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.
4. Realizing CATS framework workflow with LISP
Sun, et al. Expires 25 July 2024 [Page 5]
Internet-Draft LISP Anycast January 2024
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: LISP-based CATS Workflow
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.
Sun, et al. Expires 25 July 2024 [Page 6]
Internet-Draft LISP Anycast January 2024
4.1. Metrics Distribution
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.
4.2. Service Demand Processing
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].
5. Addressing CATS Requirements with LISP
In this part, we analyze how LISP-based approach can solve CATS
requirements described in [draft-ietf-cats-usecases-requirements]
5.1. Support dynamic and effective selection among multiple serivce
instances
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
Sun, et al. Expires 25 July 2024 [Page 7]
Internet-Draft LISP Anycast January 2024
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.
5.2. Support Instance Affinity
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-
Sun, et al. Expires 25 July 2024 [Page 8]
Internet-Draft LISP Anycast January 2024
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].
5.3. Support Metric Representation and Distribution
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.
Sun, et al. Expires 25 July 2024 [Page 9]
Internet-Draft LISP Anycast January 2024
5.4. Support Alternative Definition and Use of Metrics
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
Sun, et al. Expires 25 July 2024 [Page 10]
Internet-Draft LISP Anycast January 2024
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.
6. Security Considerations
TBD
7. References
7.1. Informative References
[draft-farinacci-lisp-telemetry]
Farinacci, D., Ouissal, S., and E. Nordmark, "LISP Data-
Plane Telemetry", May 2022,
<https://datatracker.ietf.org/doc/draft-farinacci-lisp-
telemetry/>.
[draft-ietf-cats-usecases-requirements]
Yao, K., Trossen, D., Boucadair, M., Contreras, LM., Shi,
H., Li, Y., Zhang, S., and Q. Zhang, "Computing-Aware
Networking (CAN) Problem Statement and Use Cases", January
2024, <https://datatracker.ietf.org/doc/draft-ietf-cats-
usecases-requirements/>.
[draft-ietf-lisp-name-encoding]
Farinacci, D., "LISP Distinguished Name Encoding",
September 2022, <https://datatracker.ietf.org/doc/draft-
ietf-lisp-name-encoding/>.
[draft-ietf-lisp-pubsub]
Rodrigues-Natal, A., Ermagan, V., Cabellos, A., Barkai,
S., and M. Boucadair, "Publish/Subscribe Functionality for
LISP", June 2021, <https://datatracker.ietf.org/doc/draft-
ietf-lisp-pubsub/>.
[draft-kowal-lisp-policy-distribution]
Kowal, M., Portoles, M., Jain, A., and D. Farinacci, "LISP
Transport for Policy Distribution", September 2022,
<https://datatracker.ietf.org/doc/draft-kowal-lisp-policy-
distribution/>.
Sun, et al. Expires 25 July 2024 [Page 11]
Internet-Draft LISP Anycast January 2024
[draft-ldbc-cats-framework]
Li, C., Du, Z., Boucadair, M., Drake, J., Huang, G., and
G. Mishra, "Dynamic-Anycast Architecture", June 2023,
<https://datatracker.ietf.org/doc/draft-ldbc-cats-
framework/>.
[draft-rodrigueznatal-lisp-multi-tuple-eids]
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,
<https://datatracker.ietf.org/doc/draft-rodrigueznatal-
lisp-multi-tuple-eids/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<https://datatracker.ietf.org/doc/rfc2119/>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013, <https://datatracker.ietf.org/doc/rfc6830/>.
[RFC9299] Cabellos, A. and D. Saucez, "An Architectural Introduction
to the Locator/ID Separation Protocol (LISP)", October
2022, <https://datatracker.ietf.org/doc/rfc9299/>.
Authors' Addresses
Kyoungjae Sun
ETRI
218, Gajeong-ro, Yuseung-gu
Dajeon
34065
Republic of Korea
Phone: +82 10 3643 5627
Email: kjsun@etri.re.kr
Minh-Ngoc Tran
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul
06978
Republic of Korea
Email: mipearlska1307@dcn.ssu.ac.kr
Sun, et al. Expires 25 July 2024 [Page 12]
Internet-Draft LISP Anycast January 2024
Ha-Duong Phung
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul
06978
Republic of Korea
Email: phunghaduong@dcn.ssu.ac.kr
Younghan Kim
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul
06978
Republic of Korea
Phone: +82 10 2691 0904
Email: younghak@ssu.ac.kr
Sun, et al. Expires 25 July 2024 [Page 13]
