Computing-Aware Traffic Steering (CATS) Using Segment Routing

Solution Overview This section describes the details of realizing CATS identifiers, CATS components, and realted workflow.

Realization of CATS Framework Components

CATS Identifiers A CATS Service ID (CS-ID) is an anycast IPv4 or IPv6 address. Such an IP address is associated with a specific service that is reachable via one or multiple service contact instances. The CATS overlay encapsulation is established from an Ingress CATS-Forwarder to an Egress CATS-Forwarder connected to a service contact instance. The service contact instance is typically hosted in a service site. As defined in the CATS framework, a CSCI-ID is the identifier of a specific service contact instance. Depending on the deployment requirements, a CSCI-ID may be needed to indicate where to forward the packet in the case that multiple sites connect to the same Egress CATS-Forwarder.

CATS Components In the context of this document, CATS-Forwarders are required to support SR encapsulation, including SR-MPLS and SRv6 . The CATS Traffic Classifier (C-TC) is assumed to be running on Ingress CATS-Forwarders. For each service site, one or multiple C-SMAs can be implemented within the site to collect the metrics of the service instances.

Realization of the CATS Framework Workflow

Service Announcement The service's anycast IP address may be announced by using a rendezvous service (DNS, for example). Clients can obtain the CS-ID of the service from the rendezvous service used by the application. It is out of scope of this document to provide a comprehensive list of all candidate rendezvous services.

Metrics Distribution As per the CATS framework, CS-ID routes with metrics are distributed among the overlay CATS-Forwarders. 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 CS-ID routes with metrics. In the case of the C-SMA running as a stand-alone entity outside an Egress CATS-Forwarder, the C-SMA collects the metrics of computing resource within a service site and distributes the CS-ID routes with the collected metrics to the Egress CATS-Forwarder. Egress CATS-Forwarders will redistribute the CS-ID routes to Ingress CATS-Forwarders. In the case of the C-SMA running as a logic entity on an Egress CATS-Forwarder, the same process will be performed inside the Egress CATS-Forwarder. As described in , CATS can be deployed in a distributed model, a centralized model, or a hybrid model. In a centralized model or a hybrid model, the routes with metrics may be collected by centralized controllers. BGP-LS may be a candidate solution to collect the route with metrics from CATS-Forwarders to controllers; the use of BGP-LS is however out of the scope of this document. A centralized controller may also install forwarding policies on Ingress CATS-Forwarders to steer the traffic; how these policies are communicated to the CATS-Forwarders is out of the scope of this document.

Service Access Processing Two SR data plane approaches are supported: SRv6 and SR-MPLS . This section introduces a solution based upon SRv6 and SR-MPLS as data planes for CATS purposes. An Ingress CATS-Forwarder generates SRv6/SR-MPLS encapsulations from itself to Egress CATS-Forwarders according to the SR policy received from a controller. An Ingress CATS-Forwarder receives service routes with computing-related metrics from Egress CATS-Forwarders. A C-PS will select the best service site according to the received service routes and routing policies. Once the best service site is selected, the associated Egress CATS-Forwarder can be determined and the appropriate SR encapsulation from an Ingress CATS-Forwarder to the C-PS-computed Egress CATS-Forwarder can be selected. When a service access packet is received by an Ingress CATS-Forwarder, it is classified by the C-TC component. When a matching classification entry is found for this service access packet, the Ingress CATS-Forwarder encapsulates and forwards it to the C-PS selected Egress CATS-Forwarder via the matching SR tunnel.

SRv6 As shown in , SRv6 tunnels are established from Ingress CATS-Forwarders to Egress CATS-Forwarders. There may be multiple encapsulations from a single Ingress CATS-Forwarder to different Egress CATS-Forwarders so that the ingress can choose the best Egress CATS-Forwarder connected to the target site. Furthermore, there may be multiple tunnels from a single Ingress CATS-Forwarder to a single Egress CATS-Forwarder, e.g., to provide different connectivity performance guarantees.

Using SRv6 in CATS In some cases, multiple service sites may be connected to a single Egress CATS-Forwarder. To demux these sites, a specific attachment circuit could 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. When the traffic reaches the Egress CATS-Forwarder, the SRv6 packet is decapsulated and the traffic is forwarded to the service contact instance. How the packet is handled beyond that point is out of the scope.

SR-MPLS Similarly, SR-MPLS can be used as the overlay CATS encapsulation. The forwarding path is encoded as an MPLS label stack, and a potential VPN label can be included as the last label to indicate to steer the traffic through a specific interface to a target service contact instance in the case multiple service sites connect to the same Egress CATS-Forwarder.

Service Instance Affinity As per , different services may have different notions of what constitutes a 'flow' and may thus identify a flow differently. Typically, a flow is identified by the 5-tuple transport coordinates (source and destination addresses, source and destination port numbers, and protocol). For a service that requires service instance affinity, the Ingress CATS-Forwarder needs to forward all the packets in a flow to the same service instance. Section 3.2.3 describes the general procedure of how to steer the packets of a flow to the same SR tunnel. When the packet is the first packet in the flow, the flow characteristics might not be matched in the C-TC, and a forwarding entry will be created for this flow. When the flow characteristics can be matched in the C-TC, the packet will be forwarded to the same tunnel selected by the previous packet in the flow, so that the service instance affinity can be guaranteed.

Operational and Manageability Considerations For the routes of the anycast IP address, there may be multiple candidate routes on the Ingress CATS-Forwarder, which have different Egress CATS-Forwarders as the next hop. According to related computing metrics and network metrics, each candidate route can be associated with a dynamic weight. There may also be multiple SR policies between the Ingress CATS-Forwarder and the target Egress CATS-Forwarder. For a CATS service, it should have an intent for the selecting or mapping of an SR policy. For example, the intent or objective can be low-latency, which appears as the color in an SR policy tuple <Headend, Color, Endpoint> . After a service contact instance or an Egress CATS-Forwarder is selected for a CATS flow considering weights of candidate routes, the Ingress CATS-Forwarder needs to associate the flow with a proper SR policy between the Ingress CATS-Forwarder and the Egress CATS-Forwarder. Some accounting requirements are listed below to record the amount of CATS traffic in the operation.

An Ingress CATS-Forwarder MUST be able to account the amount of the CATS traffic along the selected SR policy.
An Egress CATS-Forwarder MUST be able to account the amount of the CATS traffic received from a selected SR policy.

The weight of a route will be changed in operation, therefore, some weight changing requirements are listed below. It is assuming that multiple service instances in different service sites form a load balance group at the Ingress CATS-Forwarder for a CATS service.

Large weight SHOULD be configured to the route to the service site that can serve more clients.
When the service site is busy, for example, certain essential recourse is about to be exhausted, the related route for it on the Ingress CATS-Forwarder should lower its weight, or even leave the load balance group temperately.
If the latency of a specific SR tunnel bearing the CATS traffic exceeds a threshold, its related route on the Ingress CATS-Forwarder should lower its weight, or even leave the load balance group temperately.