CATS based on Real Locator

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. 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. 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. 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 .

The realization of CATS Framework in this document adheres to and 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. 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.

As described in Section 3.4 of , CATS can be deployed in a distributed model, centralized model, or a hybrid model. The following description is about distributed model.

This section is the same as Section 3.2.1 of .

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.

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: Tunnel mode: The packet with destination IP being anycast IP is encapsulated to the tunnel with destination address set to real locator. 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.

This section is the same as Section 3.2.4 of .