Use Cases of Computing-aware Service Function Chaining (SFC)
Shuai Zhang
China Unicom
Beijing
China
zhangs366@chinaunicom.cn
Xia Chen
Huawei Technologies
Beijing
China
jescia.chenxia@huawei.com
25 July 2022
Multiple occurrences of the same service function(SF) can exist in the same administrative domain and each occurrence of SF is called SF instance. A Service Function Path(SFP) is determined by composing selected SF instances and overlay links. The SF instances are selected according to the computing power of SFs in addition to the network information and this is defined as the computing-aware SFC in this document.
This document describes the use cases for computing-aware Service Function Chaining(SFC).

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

Introduction
[RFC7665]defines the architecture for SFC and mentions load-balancing considerations of the scenario that is same service function may be reachable through multiple SFFs.The selection of which SFF to use to reach SF may be made by the control logic in defining the SFP, or may be left to the SFFs themselves, depending upon policy, solution, and deployment constraints.
[I-D.ietf-sfc-control-plane] indicates that implementing a (logically) centralized path computation engine requires information to be dynamically communicated to the central SFC Control Element, such as the list of available SF instances, SFF locators, load status, SFP availability, etc. SF load update information such as the performance threshold or stress level of SF can be exchanged between an SF and the SFC control plane to establish or adjust an SFP.
In this document the computing power of SF includes computing resources and computing load of SF. For example, the compute resource can be the vCPUs allocated to SF, and the compute load can be the CPU utilization of SF or the ratio of the number of SFPs currently using SF to the maximum number of SFPs supported by SF.
Multiple instances of the same service function(SF) can exist in the same administrative domain. A Service Function Path(SFP) is determined by composing selected SF instances and overlay links.The SF instances can be selected according to the computing power of SFs in addition to the network information and this is defined as the computing-aware SFC.
This document describes the use cases for computing-aware Service Function Chaining(SFC).

Use Cases of Computing-aware SFC

Computing-aware SFC in multiple data centers(DCs)
In carrier networks, operators may deploy multiple data centers or computing resource pools dispersed geographically. These data centers can host diverse types of value-added services(VASes) such as FW(Firewall), IPS(Intrusion Prevention System), WOC(Web Optimization Control) and VO(Video Optimizer) shared by the enterprise leased line services, internet services etc.
Each data center may have different types of service functions. For example, high usage service functions are deployed in edge or regional data centers while other low usage service functions are deployed in global or central data centers. So SFCs with different types of service functions may span multiple data centers.
The same service function can be deployed in multiple data centers. In such deployments the SF in one data center is called a SF instance. SFPs are constructed with the ordered chain of SFs each of which is from specific data center.
The path computation of SFP should consider the computing load of SFs and the cost or latency of network paths between the DCs hosting the SFs in order to get the good service experience of SFs and the optimal end to end network path.
In Figure 1, A enterprise tenant orders SFC with a chain of two value-added services for its access to internet service. The sequenced services of SFC are FW and VO.
            +------+   +------+   +------+
            |DC1   |   |DC2   |   |DC3   |
            |      |   |      |   |      |
            |  FW  |   |  FW  |   |  VO  |
            +------+   +------+   +------+
               |          |          |
               +          +          +
             +----+     +----+     +----+     +----+
     CPE+--->| R1 |+--->| R2 |+--->| R3 |+--->| R4 |+-->internet
             +----+     +----+     +----+     +----+

    Figure 1: Illustration of Computing-aware SFC
The current computing load status of the FW SFs in DC1 and DC2 is as follows: each SF uses 6 vCPUs. The load of DC1 is 50%. The load of DC2 is 20%. Considering lightly loaded SF the computed SFP is represented as: DC2 FW -> DC3 VO. Traffic follows the path: CPE -> R1 -> R2 -> DC2 FW -> R2 -> R3 ->DC3 VO -> R3 -> R4 -> internet
The procedures for SFP creation according to computing power of SFs and network topology may be handled by the control plane as follows:
1.Collect computing power which are computing resources and computing load of of SFs in DCs
2.Associate the DC location and computing power of the available SFs with topological information of network connecting all the data centers to allow control plane to construct the overall map
The following potential solutions could be considered:
- Collect the SF's location and computing power by BGP-LS or Netconf from the router connecting the data centers and dynamically get the association relationship.
- Independently collect the SF location and computing power by other means and statically configure the association with the network on the control plane.
3.Compute the actual sequence of specific routers and selected SFs in the network for SFP
If the same SF is deployed in multiple data centers the control plane selects one SF instance for SFP considering the computing load of SF and the cost or latency of network paths between the DCs hosting the SFs.
4.Deliver the actual computed path called Rendered Service Path (RSP) [RFC7665] to the routers to steer the traffic from classifier to destination
In some cases SFP adjustments can be handled. For example, a SF in the selected DC fails, the load of the same SF in each DC varies greatly, and the delay is caused among routers connected to the DC.

Security Considerations
TBD

IANA Considerations
There are no IANA considerations in this document.

Normative References
[RFC7665]
[I-D.ietf-sfc-control-plane]