<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-kim-bmwg-sfc-benchmark-00"
     ipr="trust200902">
  <front>
    <title abbrev="considerations for benchmarking sfc">Considerations for Benchmarking Service Function Chain</title>

    <author fullname="Taekhee Kim" initials="T.Kim" surname="Kim">
     <organization abbrev="KT">
       KT
     </organization>
      <address>
	  <postal>
      <street>Infra R&amp;D Lab. KT</street>
          <street>17 Woomyeon-dong, Seocho-gu</street>
          <city>Seoul</city>
          <code>137-792</code>
          <country>Korea</country>
      </postal>
      <phone>+82-2-526-6688</phone>
      <facsimile>+82-2-526-5200</facsimile>
      <email>taekhee.kim@kt.com</email>
      </address>
    </author>
    <author fullname="Bummo Koo" initials="B.Koo" surname="Koo">
        <organization abbrev="KT">
            KT
        </organization>
        <address>
            <postal>
                <street>Infra R&amp;D Lab. KT</street>
                <street>17 Woomyeon-dong, Seocho-gu</street>
                <city>Seoul</city>
                <code>137-792</code>
                <country>Korea</country>
            </postal>
            <phone>+82-2-526-6688</phone>
            <facsimile>+82-2-526-5200</facsimile>
            <email>bm.koo@kt.com</email>
        </address>
    </author>
    <author fullname="Jisu Park" initials="J.Park" surname="Park">
        <organization abbrev="KT">
            KT
        </organization>
        <address>
            <postal>
                <street>Infra R&amp;D Lab. KT</street>
                <street>17 Woomyeon-dong, Seocho-gu</street>
                <city>Seoul</city>
                <code>137-792</code>
                <country>Korea</country>
            </postal>
            <phone>+82-2-526-6688</phone>
            <facsimile>+82-2-526-5200</facsimile>
            <email>jisu.park@kt.com</email>
        </address>
    </author>
    <author initials="E. Paik" surname="Paik" fullname="EunKyoung Paik">
  <organization abbrev="KT">
    KT
  </organization>
<address>
      <postal>
      <street>Infra R&amp;D Lab. KT</street>
          <street>17 Woomyeon-dong, Seocho-gu</street>
          <city>Seoul</city>
          <code>137-792</code>
          <country>Korea</country>
      </postal>
      <phone>+82-2-526-5233</phone>
      <facsimile>+82-2-526-5200</facsimile>
      <email>eun.paik@kt.com</email>
      <uri>http://mmlab.snu.ac.kr/~eun/</uri>
</address>
</author>

    <date day="03" month="July" year="2017"/>

    <abstract>
      <t>Service Function Chain(SFC) is a ordered set of service functions. Packets flow restrictively at the service functions according to the order. To enable a network service, operator composes the service function chain logically. Though SFC is efficient where network/service requirements are dynamically changing, the reliability of SFC should be guaranteed. This memo describes the considerations for benchmarking SFC reliability.</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>

      <t/>
    </note>
  </front>

  <middle>

<!-- -->
<!--SECTION 1: Introduction                  -->
<!-- -->

    <section title="Introduction">
      <t>As Service Function Chain(SFC) is the ordered set of service functions. It is logically defined on demand of a service. To enable the service, SDN controller set flow rules at each physical/virtual switch which belongs to the SFC. SFC is efficient where the network/service requirements are keep changing dynamically. The number of physical/virtual switches which will accept the flow rules is differ from the size of the domain or service.</t>

      <t>As an operator perspective, at the stage of SFC creation, modification, and deletion, the reliability of SFC should always be guaranteed. To apply the change of the SFC, SDN controller will set flow rules at some switches and delete flow rules at other switches. For certain reasons such as the heavy traffic on the target switches which should accept new rules or the link failure between the target switches and the SDN controller, the new SFC may not be applied properly.</t>

      <t>This draft memo describes considerations for benchmarking Service Function Chain reliability.</t>
	  </section>
<!-- -->
<!--SECTION 2: SCOPE   -->
<!-- -->
    <section title="Scope">
        <t>At the time of writing this memo, SFC standardization is now in progress. But operators and vendors are implementing SFC their own way. This memo does not target NSH enabled architecture and target general operation circumstances. The scope of SFC reliability benchmark is when the initial SFC is already provisioned and the traffic also flows over the certain SFCs, and SFC needs to be updated. Also, SFC is made over multi-domain network, which covers the whole country.</t>
        <t>This figure is an example of the network.</t>
        
        <t><figure align="center">
            <artwork>
                                    +----------------+
                                    | SDN Controller |
                                    +----------------+
                                        /         \
                                       /           \
                                      /             \
                                     /               \
                Domain A            /                 \          Domain B
    +--------------------------------+              +--------------------------------+
    |                                |              |                                |
    |  +---------+    +----------+   |              |  +---------+     +---------+   |
    |  | vSwitch |    | vSwitch  |   |              |  | pSwitch |     | vSwitch |   |
    |  +---------+    +----------+   |              |  +---------+     +---------+   |
    |                                |              |                                |
    |  +---------+    +----------+   |              |  +---------+     +---------+   |
    |  | pSwitch |    | pSwitch  |   |              |  | vSwitch |     | pSwitch |   |
    |  +---------+    +----------+   |              |  +---------+     +---------+   |
    |              ...               |              |              ...               |
    +--------------------------------+              +--------------------------------+
                
                
            </artwork>
        </figure></t>
    </section>
    <!-- -->
    <!--SECTION 3: Considerations for Benchmarking SFC Reliability                    -->
    <!-- -->
    <section title="Considerations for Benchmarking SFC Reliability">
        <t>This section defines and lists considerations which must be addressed to benchmark the reliability of SFC</t>
        
        <!-- -->
    <!--SECTION 3.1: Configuration Parameters for Benchmarking Test   -->
    <!-- -->
      <section title="Configuration Parameters for Benchmarking Test">
        <t>This section lists the parameters affecting the SFC reliability. To apply new SFC, SDN controller set rules to the target switches. Depending on the status of the swithes and the network, the new SFC can be applied right as intended, or not. The right operation of SFC as intended includes the right time of the operation activates.</t>
        <t><list style="symbols">
           	<t>Types of Switches : Virtual switch or Physical switch
            </t>

            <t>The number of switches in target SFC domain
                <list style="symbols">
                <t>Depending on the composition of the target SFC, the number of switches which need to update their flow tables is different.</t>
                </list>
            </t>
            
            <t>The Usage of Flow table of the target switch
                <list style="symbols">
                    <t>When the new SFC rule needs to setup, if the flow table entries are not enought and have to stored elsewhere,not TCAM, the usage of flow table can affect the reliability of SFC.
                    <list style="symbols">
                        <t>TCAM Usage</t>
                        <t>Flow table Entries</t>
                        </list>
                    </t>
                    
                </list>

            </t>
            <t>The physical distances between the Controller and Switch
                 <list style="symbols">
                     <t> As the network grows broad, the delay is same as propagation delay. And this make SFC Activation time different.</t>
                </list>
            </t>
            
            <t>The traffic loads on the target switch
                 <list style="symbols">
                <t>The limitaion of the CPU, when the target switch needs to process large amount of the traffic, the new SFC rules setup cannot be done in intended time.
                </t></list>
            </t>
            
          </list></t>

      </section>
      <!-- -->
      <!--SECTION 3.2: Testing Parameter Benchmarking Test   -->
      <!-- -->
      <section title=" Testing Parameter Benchmarking Test">
          <t>This section describes the testing parameter for Benchmark SFC Reliability. In terms of operation, the reliability of SFC is "operate the SFC in right time and at right path." </t>
          <t>Rule Activation Time
              <list style="symbols">
                  <t>The time interval from the new flow rule setup requests to the time when packets start to flow following the new matched rule.
                  </t></list>
          </t>
          <t>TBD</t>
          
</section>
    </section>





<!-- -->
<!--SECTION 4: Security Considerations    -->
<!-- -->
  

    <section title="Security Considerations">
     <t>
		TBD.
	</t>
    </section>
<!-- -->
<!--SECTION 5: IANA Considerations   -->
<!-- -->
  
    <section anchor="IANA" title="IANA Considerations">
      <t>No IANA Action is requested at this time.</t>
    </section>
  
  </middle>
<!-- -->
<!--SECTION 6: References   -->
<!-- -->

  <back>
    <references title="Normative References">
      <?rfc ?>

      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.2544"?>
      <?rfc include="reference.RFC.7665"?>


    </references>

  </back>
</rfc>
