Internet-Draft Analysis for Multiple Data Plane Solutio August 2024
Fu, et al. Expires 2 March 2025 [Page]
Workgroup:
CATS
Internet-Draft:
draft-fu-cats-muti-dp-solution-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
H. Fu
ZTE Corporation
B. Liu
China Mobile
Z. Li
China Mobile
D.H. Huang
ZTE Corporation
D. Yuan
ZTE Corporation
L. Ma
ZTE Corporation
W. Duan
ZTE Corporation

Analysis for Multiple Data Plane Solutions of Computing-Aware Traffic Steering

Abstract

This document presents an overall framework for the data plane of Computing-Aware Traffic Steering (CATS). In particular, it illustrates several optional and possible data plane solutions, compares their key features and main differences, and analyzes their corresponding applicable scenarios.

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 2 March 2025.

1. Introduction

As described in [I-D.ietf-cats-usecases-requirements], traffic steering which takes computing resource conditions and metrics into account would benefit computing-related services, including latency-sensitive services which rely upon the use of augmented reality or virtual reality (AR/VR) techniques.

Computing-Aware Traffic Steering (CATS) [I-D.ietf-cats-framework] aims to solve the problem that how the network edge can steer traffic between clients of a service and sites offering the service. To enable the computing- and network-aware traffic steering decisions, awareness of computing information and network information are fundamental premises. The CATS architecture is an overlay framework for the selection of the most appropriate service contact instance for placing a service request. However, the CATS framework does not assume any specific data plane and control plane solutions.

This document proposes several potential data plane solutions for the realization of CATS, and compares their key features and main application scenarios. These solutions use an anycast IP address or digital identification as the Computing-aware Service ID (CS-ID) associated with a service.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

This document makes use of the terms defined in [I-D.ietf-cats-framework].

4. Overview

As illustrated in Figure 1, underlay network infrastructure and devices are deployed between an ingress CATS-Router and service contact instances, where corresponding CATS functionality is deployed at the ingress CATS-Router 1 and egress CATS-Router 2/3. An egress CAT-router connects to multiple service sites. At a specific service site, single service contact instance or multiple service contact instances are deployed.

CATS overlay encapsulation is established from the ingress CATS-Router to the egress CATS-Router connected to the service site. For ease of description in this document, it is assumed that a specific tunnel between CATS-Routers is an SRv6 Policy[RFC8986].


                   +--------+
                   | Client | <---------------------------
                   +----+---+
                        |                        Phase 1
               +--------+-------+ <-----------------------
               |      C-TC      |
               +---------+------+
               |         | C-PS |
               |         +------+
+--------------+ CATS-Router 1  +--------------+
|              +----------------+              |
|             Underlay Infrastructure          |  Phase 2
|                  SRv6 Encap                  |
| +----------------+        +----------------+ |
+-+  CATS-Router 2 +--------+  CATS-Router 3 +-+
  +----------------+        +----------------+
  |     C-SMA      |        |     C-SMA      |
  +--------+-------+        +--------+-------+ <----------
           |                         |
           |                         |
      +----+-----+               +---+------+     Phase 3
   +--+--------+ |            +--+--------+ |
   |  Service  | |            |  Service  | |
   | instance  +-+            | instance  +-+
   +-----------+ <------------+-----------+ <-------------
    Edge site1                  Edge site2


Figure 1: CATS Data Plane Workflow

Control plane: The ingress CATS-Router ("CATS-Router 1") receives service routes from the egress CATS-Routers ("CATS-Router 2/3") , including network and computing indicators. The C-PS determines an associated egress CATS-Router by selecting the most appropriate service site and corresponding network forwarding path based on routing strategies and policies, utilizing collected network and computing metrics. The ingress CATS-Router generates the SRv6 tunnel encapsulation from itself to the egress CATS router based on a calculated and matched SR policy.

Data plane: From the client to the service contact instance, packet processing and handling procedures are generally divided into at least the following successive three phases:

  • Phase I: A service request carrying a CATS Service ID (CS-ID) needs to be routed to the ingress CATS-Router through the access network. The CS-ID can be carried in multiple methods: 1) placing the CS-ID in the destination address field, where the destination address would be encoded with the CS-ID as spcific anycast IPs; 2) placing the CS-ID in an IPv6 extension header, and the destination address would inherit the IP address of the ingress CATS-Router.
  • Phase II: When packets of a service request are received by an ingress CATS-Router, it is classified and determined by the C-TC component. When a matching entry of service routes is found for this request, the ingress CATS-Router encapsulates it and forwards the packets to the C-PS selected egress CATS-Router via the matching SR tunnel.
  • Phase III: At egress CATS-Router, the packets are decapsulated and successively forwarded according to local entries, and the packets are sent to a corresponding selected service contact instance.

5. Solution 1: Service ID carried in an anycast IP with bidirectional address translation mode


                                                          +----+
+------+   +-------------------+  +-------------------+   |IP1 +-+
|Client|   |Ingress CATS-Router|  |Engress CATS-Router|   +-+ IP2|
+------+   +-------------------+  +-------------------+     +----+
   |                 |                      |                 |
   |                 |  +---------------+   |                 |
   |                 |  |     DATA1     |   |                 |
   |                 |  +---------------+   |                 |
   |                 |  |  inner header |   |                 |
   |                 |  | +-----------+ |   |                 |
   |                 |  | |SA=clientIP| |   |                 |
   | +-------------+ |  | +-----------+ |   |                 |
   | |    DATA1    | |  | |  DA=Sid1  | |   |                 |
   | +-------------+ |  | +-----------+ |   |                 |
   | | inner header| |  +---------------+   |                 |
   | |+-----------+| |  |  outer header |   | +-------------+ |
   | ||SA=clientIP|| |  | +-----------+ |   | |    DATA1    | |
   | |+-----------+| |  | |   SRH     | |   | +-------------+ |
   | ||  DA=Sid1  || |  | +-----------+ |   | | inner header| |
   | |+-----------+| |  | |  SA=C-R-I | |   | |+-----------+| |
   | +-------------+ |  | +-----------+ |   | ||SA=clientIP|| |
   |                 |  | |  DA=C-R-E | |   | |+-----------+| |
   |                 |  | +-----------+ |   | ||  DA=IP1   || |
   |                 |  +---------------+   | |+-----------+| |
   +---------------->|                      | +-------------+ |
   |    Phase 1      +--------------------->|                 |
   |                 |       Phase 2        +---------------->|
   |                 |                      |    Phase 3      |
   |                 |                      |                 |


Figure 2: CATS Dataplane Workflow for solution 1

Figure 2 illustrates successive phases of workflow in Solution 1

  • Phase I: The packet of a service request carries a CS-ID in its destination address field. The destination address is encoded as an anycast IP address and would be routable within the access network. This prerequisite requires that anycast prefix routes are distributed throughout the access network. Service packets can be forwarded to the ingress CATS-Router for processing in a successive Phase II.
  • Phase II: The ingress CATS-Router looks up with the corresponding service routing table indexed by the service ID in the destination address of the packets, determines appropriate service route entries and routes the packet to the SR policy by encapsulating the SRH tunnel header, and forwards the packet to the egress CATS-Router for afterwards procedures in phase III.
  • Phase III: The egress CATS-Router decapsulates the SRH tunnel encapsulation of the packets. Since there might be multiple service instances which provide the same service deployed under the same CATS-Router, the packets carrying anycast IP addresses cannot be directly routed to a corresponding service contact instance. NAT (Network Address Translation) needs to be performed for the packets, and the packets are forwarded to the corresponding service contact instance by the lookup among service routes entries and a corresponding translation of destination address.

Anycast IP is used as the destination address of the end-to-end session. Since the destination address of the user packet is translated to the IP address of the service contact instance in phase III. After the service contact instance receives the packet, the service contact instance correspondingly utilizes the incoming source address as the destination address of the response packet, and uses the IP address of the service contact instance as the source address. To eliminate influences on the host protocol stack for service contact and session establishment, the source address of the response packet must be translated to the corresponding upstream destination address, for which an SNAT process should be performed for the response packets in a downstream workflow.

Specifically, the NAT (Network Address Translation) function can be provided by either the egress CATS-Router or the ingress CATS-Router. In the case of the egress CATS-Router, a special SID (Segment ID) needs to be extended to indicate the NAT translation. However, for the ingress CATS-Router, no such special SID is required; it can determine the need for NAT based on the context. This allows for flexibility in choosing different solutions based on actual circumstances.

6. Solution 2: Service ID carried in the IPv6 EH with unidirectional address translation mode

Among up-to-date application scenarios, some newly introduced transport protocols would support the change of connecting IP address without interrupting the traffic flows and disconnecting the connection session. In these cases, the CATS-Routers would modify the destination address of the corresponding packets to the IP address of the selected service contact instance when the client sends its upstream packet, and establish a connection through the downstream response packet from the service instance even the IP address is modified. Corresponding capable transport protocols are outside the scope of this document.


                                                          +----+
+------+   +-------------------+  +-------------------+   |IP1 +-+
|Client|   |Ingress CATS-Router|  |Engress CATS-Router|   +-+ IP2|
+------+   +-------------------+  +-------------------+     +----+
   |                 |                      |                 |
   |                 |  +---------------+   |                 |
   |                 |  |     DATA1     |   |                 |
   |                 |  +---------------+   |                 |
   |                 |  |  inner header |   |                 |
   |                 |  | +-----------+ |   |                 |
   |                 |  | |SA=clientIP| |   |                 |
   | +-------------+ |  | +-----------+ |   |                 |
   | |    DATA1    | |  | |  DA=Sid1  | |   |                 |
   | +-------------+ |  | +-----------+ |   |                 |
   | | inner header| |  +---------------+   |                 |
   | |+-----------+| |  |  outer header |   | +-------------+ |
   | ||SA=clientIP|| |  | +-----------+ |   | |    DATA1    | |
   | |+-----------+| |  | |   SRH     | |   | +-------------+ |
   | ||  DA=Sid1  || |  | +-----------+ |   | | inner header| |
   | |+-----------+| |  | |  SA=C-R-I | |   | |+-----------+| |
   | +-------------+ |  | +-----------+ |   | ||SA=clientIP|| |
   |                 |  | |  DA=C-R-E | |   | |+-----------+| |
   |                 |  | +-----------+ |   | ||  DA=IP1   || |
   |                 |  +---------------+   | |+-----------+| |
   +---------------->|                      | +-------------+ |
   |    Phase 1      +--------------------->|                 |
   |                 |       Phase 2        +---------------->|
   |                 |                      |    Phase 3      |
   |                 |                      |                 |

Figure 3: CATS Dataplane Workflow for solution 2

Figure 3 illustrates successive phases of workflow in Solution 2

  • Phase I: Forward packets to the ingress CATS-Router, the destination address of the packet might be set to the ingress CATS-Router's IP address, and the CS-ID is carried in the IPv6 extension header. The packet is then forwarded through the access network to the ingress CATS-Router, at which it is processed in phase II.
  • Phase II: The ingress CATS-Router looks up with the corresponding service routing table indexed by the service ID in the IPv6 extension header of the packets, determines appropriate service route entries and routes the packet to the SR policy by encapsulating the SRH tunnel header, and forwards the packet to the egress CATS-Router for afterwards procedures in phase III.
  • Phase III: The egress CATS-Router decapsulates the SRH tunnel encapsulation of the packets. The destination address in the packet needs to be replaced with the IP address of the corresponding service contact instance. The packet is then forwarded to the corresponding service contact instance.

In order to adapt to the destination address modification on the terminal and service host side, the protocol stack should be correspondingly modified and upgraded. As a result, downstream packets do not need SNAT translation. In the above condition, there is only unidirectional address translation process in Solution 2. In this case, the CATS-Router does not even need to maintain and administer session status for traffic flows including unidirectional translation entries, etc.

7. Solution 3: Service ID carried in an anycast IP with TUNNEL/MAC mode


                                                             +----+
+------+    +-------------------+ +-------------------+      |IP1 +-+
|Client|    |Ingress CATS-Router| |Engress CATS-Router|      +-+--+2|
+--+---+    +----------+--------+ +--------+----------+        +--+-+
   |                   |                   |                      |
   |                   |                   |  Option 1:           |
   |                   | +---------------+ |  +---------------+   |
   |                   | |     DATA1     | |  |     DATA1     |   |
   |                   | +---------------+ |  +---------------+   |
   |                   | |  inner header | |  |  inner header |   |
   |                   | | +-----------+ | |  | +-----------+ |   |
   |                   | | |SA=clientIP| | |  | |SA=clientIP| |   |
   | +---------------+ | | +-----------+ | |  | +-----------+ |   |
   | |     DATA1     | | | |  DA=Sid1  | | |  | |  DA=Sid1  | |   |
   | +---------------+ | | +-----------+ | |  | +-----------+ |   |
   | |  inner header | | +---------------+ |  +---------------+   |
   | | +-----------+ | | |  outer header | |  |  outer header |   |
   | | |SA=clientIP| | | | +-----------+ | |  | +-----------+ |   |
   | | +-----------+ | | | |   SRH     | | |  | |   SRH     | |   |
   | | |  DA=Sid1  | | | | +-----------+ | |  | +-----------+ |   |
   | | +-----------+ | | | |  SA=C-R-I | | |  | |  SA=C-R-E | |   |
   | +---------------+ | | +-----------+ | |  | +-----------+ |   |
   |                   | | |  DA=C-R-E | | |  | |  DA=IP1   | |   |
   |                   | | +-----------+ | |  | +-----------+ |   |
   |                   | +---------------+ |  +---------------+   |
   |                   |                   |                      |
   |                   |                   |   Option 2:          |
   |                   |                   |  +--------------+    |
   |                   |                   |  |    DATA1     |    |
   |                   |                   |  +--------------+    |
   |                   |                   |  | inner header |    |
   |                   |                   |  |+------------+|    |
   |                   |                   |  ||SA=clientIP ||    |
   |                   |                   |  |+------------+|    |
   |                   |                   |  ||  DA=Sid1   ||    |
   |                   |                   |  |+------------+|    |
   |                   |                   |  ||DMAC=IP1-MAC||    |
   |                   |                   |  |+------------+|    |
   |                   |                   |  +--------------+    |
   +------------------>|                   |                      |
   |     Phase 1       +------------------>|                      |
   |                   |      Phase 2      +--------------------->|
   |                   |                   |     Phase 3          |
   |                   |                   |                      |



Figure 4: CATS Dataplane Workflow For solution 3

Figure 4 illustrates successive phases of workflow in Solution 3

  • Phase I: The packet of a service request carries a CS-ID in its destination address field. The destination address is encoded as an anycast IP address and would be routable within the access network. This prerequisite requires that anycast prefix routes are distributed throughout the access network. Service packets can be forwarded to the ingress CATS-Router for processing in a successive Phase II.
  • Phase II: The ingress CATS-Router looks up with the corresponding service routing table indexed by the service ID in the destination address of the packets, determines appropriate service route entries and routes the packet to the SR policy byencapsulating the SRH tunnel header, and forwards the packet to the egress CATS-Router for afterwards procedures in phase III.
  • Phase III: The egress CATS-Router decapsulates the SRH tunnel encapsulation of the packets. Since there might be multiple service instances which provide the same service deployed under the same CATS-Router, the packets carrying anycast IP addresses cannot be directly routed to a corresponding service contact instance. Two optional methods can be applied to forward service packets to the service contact instance: 1) Based on the IP addresses of the CATS-Router and service instance, a bidirectional tunnel (such as GRE and GIF) would be directly established between them for forwarding packets to the service instance. This method can be capable for both L2/L3 network;2) With the learned ARPs in accordance with the service instance IP addresses, and utilizes the corresponding ARP MAC as the destination MAC addresses of user packets, and deliver the packets to the service instance through layer-2 switching. This method can only be capable for the L2 network.

It should be noted that the client and service host stacks of this solution are not modified, and there is no IP address translation process in the above solution. However, the service instance needs to support a mentioned tunneling model, and some protocol stacks might not support the tunneling functionality.

8. Solution Comparison Analysis

Table 1: CATS Dataplane Comprehensive Comparison of Solutions
  Solution 1 Solution 2 Solution 3
CATS router requirement High Middle Middle
Client requirement None Middle None
Service host requirement None Middle Low
Forwarding Performance Low High High

As illustrated in Table 1, different solutions have disparate requirements for clients, service hosts, and CATS-Routers, ultimately resulting in different forwarding performances. Generally, solution 1 has the lowest requirements for terminals and service hosts, yet its forwarding performance may be the worst. Solution 2 has the most strict requirements for terminals and service hosts. In most cases, protocol stack modification is applicable to new host protocol stacks. Solution 3 requires the service host's anycast IP to be configured and deployed, and a protocol stack to support tunnels. Both solution 2 and solution 3 can provide satisfying forwarding performance. Additionally, in solution 2 and 3, CATS-Routers are not required to support the full and standard functionality of NAT.

To be added.

9. Security Considerations

TBD.

10. Acknowledgements

To be added upon contributions, comments and suggestions.

12. References

12.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754]
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <https://www.rfc-editor.org/info/rfc8754>.
[RFC8986]
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, , <https://www.rfc-editor.org/info/rfc8986>.

12.2. Informative References

[I-D.huang-service-aware-network-framework]
Huang, D., Tan, B., and D. Yang, "Service Aware Network Framework", Work in Progress, Internet-Draft, draft-huang-service-aware-network-framework-01, , <https://datatracker.ietf.org/doc/html/draft-huang-service-aware-network-framework-01>.
[I-D.ietf-cats-framework]
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-ietf-cats-framework-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-cats-framework-02>.
[I-D.ietf-cats-usecases-requirements]
Yao, K., Trossen, D., Contreras, L. M., Shi, H., Li, Y., Zhang, S., and Q. An, "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", Work in Progress, Internet-Draft, draft-ietf-cats-usecases-requirements-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-cats-usecases-requirements-03>.
[I-D.lbdd-cats-dp-sr]
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-02, , <https://datatracker.ietf.org/doc/html/draft-lbdd-cats-dp-sr-02>.
[I-D.li-dyncast-architecture]
Li, Y., Iannone, L., Trossen, D., Liu, P., and C. Li, "Dynamic-Anycast Architecture", Work in Progress, Internet-Draft, draft-li-dyncast-architecture-08, , <https://datatracker.ietf.org/doc/html/draft-li-dyncast-architecture-08>.
[RFC1631]
Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, DOI 10.17487/RFC1631, , <https://www.rfc-editor.org/info/rfc1631>.
[RFC7094]
McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, , <https://www.rfc-editor.org/info/rfc7094>.

Authors' Addresses

Huakai Fu
ZTE Corporation
Wuhan
China
Bo Liu
China Mobile
Beijing
China
Zhenqiang Li
China Mobile
Beijing
China
Daniel Huang
ZTE Corporation
Nanjing
China
Dongyu Yuan
ZTE Corporation
Nanjing
China
Liwei Ma
ZTE Corporation
Nanjing
China
Wei Duan
ZTE Corporation
Nanjing
China