Internet-Draft draft-shi-cats-with-real-locator-01 February 2024
Shi, et al. Expires 1 September 2024 [Page]
Network Working Group
Intended Status:
H. Shi
Huawei Technologies
X. Chen
Huawei Technologies
Z. Li
Huawei Technologies
X. Yi
China Unicom
K. Yao
China Mobile

CATS based on Real Locator


This document describes a solution framework that adheres to the CATS framework. The solution uses anycast IP addresses as the CATS service identifier and real locator of the service contact instance as the CATS Instance Selection ID.

Requirements Language

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 [RFC2119].

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 1 September 2024.

1. Introduction

[I-D.ldbc-cats-framework]defines a framework for Computing-Aware Traffic Steering (CATS). Such a framework defines an approach for making compute- and network-aware traffic steering decisions in networking environments where services are deployed in many locations.

[I-D.lbdd-cats-dp-sr] proposes a data plane solution for the realization of CATS. The solution uses an anycast IP address as the Computing-aware Service ID (CS-ID) associated with a service. Also, the solution uses Segment Routing (SR) as the data plane encapsulation from an ingress CATS-Router to an egress CATS-Router.

[I-D.lbdd-cats-dp-sr] describes the scenario with multiple service sites connected to a single egress CATS-Router. To demultiplex these sites, a specific attachment circuit must be provided to indicate the specific target service. In order to explicitly indicate the interface towards a site, an END.DX is encoded as the last segment in the SRv6 encapsulation[RFC8986]. The associated END.DX is learned from the control plane.

In the case that there are multiple service contact instances connected to the same interface of the egress, the selected specific service contact instance can not be distiguished only by END.DX and anycast IP. This document proposes real locator of the service contact instance acting as the CIS-ID in [I-D.ldbc-cats-framework].

2. Terminology

This document makes use of the terms defined in [I-D.ldbc-cats-framework] and [I-D.lbdd-cats-dp-sr].

3. Solution Overview

                             |    C-TC     |
                             |     | C-PS  |
       ......................|     +-------|....................
       :                     |CATS-Router 2|                   :
       :                     +-------------+                   :
       :                                                       :
       :                         Underlay                      :
       :                      Infrastructure                   :
       : SRv6 Encap 1                            SRv6 Encap 2  :
       :                                                       :
       :   +-------------+                +-------------+      :
       :   |CATS-Router 1|                |CATS-Router 3|      :
       :...|             |................|             |......:
           +-------------+                +-------------+
           |    C-SMA    |                |    C-SMA    |
           +-------------+                +-------------+
     END.DX SID1  |              END.DX SID2 |         | END.DX SID3
           ...................             ......    ......
           :                 :             :    :    :    :
           ...................             ......    ......
             | Real IP1    |Real IP2         |         |
         +-----------+  +----------+   +----------+  +----------+
         |  Service  |  | Service  |   | Service  |  | Service  |
         |  contact  |  | contact  |   | contact  |  | contact  |
         |  instance |  | instance |   | instance |  | instance |
         +-----------+  +----------+   +----------+  +----------+

                 Edge site 1           Edge site 2   Edge site 3

    Figure 1: Using SRv6 and Real Locator in CATS

3.1. Realization of CATS Framework Components

The realization of CATS Framework in this document adheres to [I-D.ldbc-cats-framework] and [I-D.lbdd-cats-dp-sr] and adds some additional description.

As in Figure 1, there is underlay infrastructure between an egress CATS-Router and service contact instances. One egress CATS-Router can connect multiple service site. One service site has only one service contact instance or multiple service contact instances.

In the realization of CATS framework, CATS service ID is anycast IP and CATS Instance Selector ID is the real locator of the CATS service contact instance.

The CATS overlay encapsulation is established from an ingress CATS-Router to an egress CATS-Router connected to a service site.To describe conveniently in this document the tunnel between CATS-Router assumes SRv6[RFC8986].

As in Figure 1, only one service contact instance is hosted in the edge site2. The solution proposed in I-D.lbdd-cats-dp-sr is enough. The solution is only use END.DX or END.DT without real locator.

But as in Figure 1, the edge site1 has two service contact instances. As described in [I-D.ldbc-cats-framework] if the egress CATS-Router executes per-instance computing-related metric distribution the real locator should be advertised with the service ID too. And when the packet is forwarded according to the computing result of CATS PATH Selector the real locator of selected service contact instance should be carried besides END.DX or END.DT. The following section will describe the detail of process.

3.2. Realization of CATS Framework Workflow

As described in Section 3.4 of [I-D.ldbc-cats-framework], CATS can be deployed in a distributed model, centralized model, or a hybrid model. The following description is about distributed model.

3.2.1. Service Announcement

This section is the same as Section 3.2.1 of [I-D.lbdd-cats-dp-sr].

3.2.2. Metrics Distribution

As per the CATS framework, CS-ID routes with metrics and CIS-ID are distributed among the overlay CATS-Routers for per-instance metric distribution. The detailed control plane solutions of metrics distribution are out of the scope of this document. However, a sample procedure is provided for the readers convenience.

For example, BGP can be used to distribute anycast IP route of the service with additional metrics and real locator.

In the case of the C-SMA running as stand alone outside an egress CATS-Router, the C-SMA collects the metrics of computing resource for the service per one service contact instance and distributes the anycast IP route of the service with the collected metrics and real locator to the egress CATS-Router. Egress CATS-Routers will generate new metrics combining the network metrics and computing-related metrics, and redistribute the anycast IP route with the new metrics and real locator to ingress CATS-Routers. In the case of the C-SMA running as a logic entity on an egress CATS-Router, the same process will be performed inside the egress CATS-Router.

3.2.3. Service Demand processing

In a distributed model an ingress CATS-Router receives the packet with destination address being anycast IP of the service. The ingress CATS-Router determines the special service contact instance to serve this packet and get the IP address of the egress CATS-Router the service contact instance is connected to, END.DX or END.DT for SRv6 and real locator.

The ingress CATS-Router generates SRv6 encapsulations from itself to the egress CATS-Router with real locator carried in the outer IPv6 extension header. Egress CATS-Router decapsulates the outer tunnel header and get the real locator. It determines the service site according to END.DX or END.DT and forwards the packet to the specific service contact instance according to the real locator.

There are two typical ways to forward the packet from the egress CATS-Router to the service contact instance:

  1. Tunnel mode: The packet with destination IP being anycast IP is encapsulated to the tunnel with destination address set to real locator.

  2. IP mode: The packet should be IPv6 packet with the real locator carried in the IPv6 extension header. The CATS-Router and the underlay infrastructure should forward the packet according to the real locator. And the real locator in the IPv6 extension header can be inserted to the packet in the ingress or egress CATS-Router.

3.2.4. Service Instance Affinity

This section is the same as Section 3.2.4 of [I-D.lbdd-cats-dp-sr].

4. Requirements

This section describes the requirements of protocol extensions about the real locator used in CATS .

[REQ01] IPv6 extension header should be used to carry real locator.

[REQ02] Protocol extensions should be defined to advertise real locator from C-SMA running as stand alone to an egress CATS-Router.

[REQ03] Protocol extensions should be defined to advertise real locator from an egress CATS-Router to an ingress CATS-Router in a distributed model.

5. Security Considerations


6. IANA Considerations

There are no IANA considerations in this document.

7. Normative References

Li, C., Boucadair, M., Du, Z., and J. Drake, "Computing-Aware Traffic Steering (CATS) Using Segment Routing", Work in Progress, Internet-Draft, draft-lbdd-cats-dp-sr-01, , <>.
Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-ldbc-cats-framework-06, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <>.

Authors' Addresses

Hang Shi
Huawei Technologies
Xia Chen
Huawei Technologies
Zhenbin Li
Huawei Technologies
Xinxin Yi
China Unicom
Kehan Yao
China Mobile