| Internet-Draft | draft-shi-cats-with-real-locator-01 | February 2024 |
| Shi, et al. | Expires 1 September 2024 | [Page] |
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.¶
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].¶
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 1 September 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.¶
[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].¶
This document makes use of the terms defined in [I-D.ldbc-cats-framework] and [I-D.lbdd-cats-dp-sr].¶
+------+
|Client|
+------+
|
+-------------+
| 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¶
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.¶
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.¶
This section is the same as Section 3.2.1 of [I-D.lbdd-cats-dp-sr].¶
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 [I-D.lbdd-cats-dp-sr].¶
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.¶
TBD¶
There are no IANA considerations in this document.¶