Internet-Draft | draft-zhang-computing-aware-sfc-usecase- | January 2022 |
Zhang & Chen | Expires 22 July 2022 | [Page] |
- Workgroup:
- Network Working Group
- Internet-Draft:
- draft-zhang-computing-aware-sfc-usecase-00
- Published:
- Intended Status:
- Informational
- Expires:
Use Cases of Computing-aware Service Function Chaining (SFC)
Abstract
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 [RFC2119].¶
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 22 July 2022.¶
Copyright Notice
Copyright (c) 2022 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.¶
1. 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).¶
2. Use Cases of Computing-aware SFC
2.1. 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.¶
3. Security Considerations
TBD¶
4. IANA Considerations
There are no IANA considerations in this document.¶
5. Normative References
- [I-D.ietf-sfc-control-plane]
- Boucadair, M., "Service Function Chaining (SFC) Control Plane Components & Requirements", Work in Progress, Internet-Draft, draft-ietf-sfc-control-plane-08, , <https://www.ietf.org/archive/id/draft-ietf-sfc-control-plane-08.txt>.
- [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>.
- [RFC7665]
- Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, , <https://www.rfc-editor.org/info/rfc7665>.