<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e., [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-zhang-computing-aware-sfc-usecase-01"
     ipr="trust200902">
  <front>
    <title abbrev="draft-zhang-computing-aware-sfc-usecase-01">Use Cases of
    Computing-aware Service Function Chaining (SFC)</title>

    <author fullname="Shuai Zhang" initials="S." surname="Zhang">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <country>China</country>
        </postal>

        <email>zhangs366@chinaunicom.cn</email>
      </address>
    </author>

    <author fullname="Xia Chen" initials="X." surname="Chen">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <email>jescia.chenxia@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date day="25" month="July" year="2022"/>

    <!---->

    <keyword/>

    <abstract>
      <t>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.</t>

      <t>This document describes the use cases for computing-aware Service
      Function Chaining(SFC).</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t><xref target="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.</t>

      <t><xref target="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.</t>

      <t>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.</t>

      <t>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.</t>

      <t>This document describes the use cases for computing-aware Service
      Function Chaining(SFC).</t>
    </section>

    <section title="Use Cases of Computing-aware SFC">
      <section title="Computing-aware SFC in multiple data centers(DCs)">
        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.<figure>
            <artwork align="center"><![CDATA[            +------+   +------+   +------+
            |DC1   |   |DC2   |   |DC3   | 
            |      |   |      |   |      |
            |  FW  |   |  FW  |   |  VO  |
            +------+   +------+   +------+  
               |          |          |
               +          +          +
             +----+     +----+     +----+     +----+   
     CPE+--->| R1 |+--->| R2 |+--->| R3 |+--->| R4 |+-->internet
             +----+     +----+     +----+     +----+   

    Figure 1: Illustration of Computing-aware SFC]]></artwork>
          </figure></t>

        <t>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 -&gt; DC3 VO. Traffic follows the path: CPE
        -&gt; R1 -&gt; R2 -&gt; DC2 FW -&gt; R2 -&gt; R3 -&gt;DC3 VO -&gt; R3
        -&gt; R4 -&gt; internet</t>

        <t>The procedures for SFP creation according to computing power of SFs
        and network topology may be handled by the control plane as
        follows:</t>

        <t>1.Collect computing power which are computing resources and
        computing load of of SFs in DCs</t>

        <t>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</t>

        <t>The following potential solutions could be considered:<list
            style="symbols">
            <t>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.</t>

            <t>Independently collect the SF location and computing power by
            other means and statically configure the association with the
            network on the control plane.</t>
          </list></t>

        <t>3.Compute the actual sequence of specific routers and selected SFs
        in the network for SFP</t>

        <t>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.</t>

        <t>4.Deliver the actual computed path called Rendered Service Path
        (RSP) <xref target="RFC7665"/> to the routers to steer the traffic
        from classifier to destination</t>

        <t>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.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Contributors" title="IANA Considerations">
      <t>There are no IANA considerations in this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.7665'?>

      <?rfc include='reference.I-D.ietf-sfc-control-plane'?>
    </references>
  </back>
</rfc>
