<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Processing Instructions can be placed here but if you are editing 
     with XMLmind (and maybe other XML editors) they are better placed
     after the rfc element start tag as shown below. -->
<!-- Information about the document.
     category values: std, bcp, info, exp, and historic
     For Internet-Drafts, specify attribute "ipr".
     (ipr values are: full3667, noModification3667, noDerivatives3667),
     Also for Internet-Drafts, can specify values for
     attributes "docName" and, if relevant, "iprExtract".  Note
     that the value for iprExtract is the anchor attribute
     value of a section (such as a MIB specification) that can be 
     extracted for separate publication, and is only
     useful whenhe value of "ipr" is not "full3667". -->
<!-- TODO: verify which attributes are specified only
               by the RFC editor.  It appears that attributes
               "number", "obsoletes", "updates", and "seriesNo"
               are specified by the RFC editor (and not by
               the document author). -->
<rfc category="info" ipr="trust200902" docName="draft-wu-sfc-scheduling-implementation-report-00" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.15.3 -->
  <!-- Processing Instructions- PIs (for a complete list and description,
          see file http://xml.resource.org/authoring/README.html and below... -->

    <!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
    
    <!-- Try to enforce the ID-nits conventions and DTD validity -->
    <!-- Items used when reviewing the document -->
    <!-- Controls display of <cref> elements -->
    <!-- When no, put comments at end in comments section,
                                 otherwise, put inline -->
    <!-- When yes, insert editing marks: editing marks consist of a 
                                 string such as <29> printed in the blank line at the 
                                 beginning of each paragraph of text. -->

    <!-- Create Table of Contents (ToC) and set some options for it.  
         Note the ToC may be omitted for very short documents,but idnits insists on a ToC 
         if the document has more than 15 pages. --> 
   <!-- If "yes" eliminates blank lines before main section entries. -->
   <!-- Sets the number of levels of sections/subsections... in ToC --> 

    <!-- Choose the options for the references. 
         Some like symbolic tags in the references (and citations) and others prefer 
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. --> 
    <!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. -->

    <!-- These two save paper: Just setting compact to "yes" makes savings by not starting each 
         main section on a new page but does not omit the blank lines between list items. 
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
    <!-- end of list of popular I-D processing instructions -->

    <!-- ***** FRONT MATTER ***** -->
<front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 42 characters -->
    <title abbrev="SFC Scheduling Algorithm">Implementation Report for Service Function Chain Scheduling Algorithm</title>
    <seriesInfo name="Internet-Draft" value="draft-wu-sfc-scheduling-implementation-report-00"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->
	<author fullname="Xiaochun Wu" initials="X." surname="Wu">
      <organization>Zhejiang Gongshang University</organization>
      <address>
        <postal>
          <street>18 Xuezheng Str., Xiasha University Town </street>
          <!-- Reorder these if your country does things differently-->
                    <city>Hangzhou</city>
          <region/>
          <code>310018</code>
          <country>P.R.China</country>
        </postal>
        <phone>+86 13067732553</phone>
        <email>spring-403@zjgsu.edu.cn</email>
        <!-- uri and facsimile elements may also be added-->
            </address>
    </author>
    <author fullname="Chen Hong" initials="C." surname="Hong">
      <organization>Zhejiang Gongshang University</organization>
      <address>
        <postal>
          <street>18 Xuezheng Str., Xiasha University Town </street>
          <!-- Reorder these if your country does things differently-->
                    <city>Hangzhou</city>
          <region/>
          <code>310018</code>
          <country>P.R.China</country>
        </postal>
        <phone>+86 19157703315</phone>
        <email>20020090025@pop.zjgsu.edu.cn</email>
        <!-- uri and facsimile elements may also be added-->
            </address>
    </author>
    <author fullname="Chuanhuang Li" initials="C." surname="Li">
      <organization>Zhejiang Gongshang University</organization>
      <address>
        <postal>
          <street>18 Xuezheng Str., Xiasha University Town </street>
          <!-- Reorder these if your country does things differently-->
                    <city>Hangzhou</city>
          <region/>
          <code>310018</code>
          <country>P.R.China</country>
        </postal>
        <phone>+86 571 28877723</phone>
        <email>chuanhuang_li@zjsu.edu.cn</email>
        <!-- uri and facsimile elements may also be added-->
            </address>
    </author>
    <!-- Another author who claims to be an editor -->
    <!--author fullname="Jiadong Xuan" 
            initials=" " 
            surname="Xuan"
            role="editor">
      <organization>Folly Consulting</organization>

      <address>
        <postal>
          <street></street>

          <city>Soham</city>

          <region></region>

          <code></code>

          <country>UK</country>
        </postal>

        <phone>+44 7889 488 335</phone>

        <facsimile></facsimile>

        <email>elwynd@dial.pipex.com</email>

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

    <date year="2022" month="December" day="23"/>
    <!-- month="March" is no longer necessary
                                           note also, day="30" is optional -->
    <!-- WARNING: If the month and year are the current ones, xml2rfc will fill in the day for 
         you. If only the year is specified, xml2rfc will fill in the current day and month 
         irrespective of the day.  This silliness should be fixed in v1.31. -->
         
    <!-- Meta-data Declarations -->
    
    <!-- Notice the use of &amp; as an escape for & which would otherwise
         start an entity declaration, whereas we want a literal &. -->
    <area>networking</area>
    <!-- WG name at the upperleft corner of the doc,
         IETF fine for individual submissions.  You can also
         omit this element in which case in defaults to "Network Working Group" -
         a hangover from the ancient history of the IETF! -->
    <workgroup>SFC</workgroup>
    <!-- The DTD allows multiple area and workgroup elements but only the first one has any
         effect on output.  -->
    <!-- You can add <keyword/> elements here.  They will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff output. -->   
    
    <abstract>
      <t>This document provides the application examples of mapping and deployment
		algorithms to address the problems of large resource overhead and end-to-end
		latency in Service Function Chain(SFC) that cannot meet the requirements of 
		latency-sensitive applications in terms of both latency optimization and 
		resource optimization.In terms of delay-optimized mapping and deployment of 
		SFC, the application example of granularity-variable SFC mapping algorithm
		based on microservice architecture reduces the number of instantiated
		microservice units and the number of end-to-end routing hops by merging redundant
		microservice units within the service function chain and reusing microservice
		units between the service function chains.In terms of resource-optimized mapping
		and deployment of SFC, the application example of SFC mapping algorithm based on
		improved gray wolf optimization algorithm optimizes the mapping of SFC through two
		strategies of reverse learning initialization and nonlinear convergence	factor,
		and improves the efficiency of the mapping scheme.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>In Network Function Virtualization (NFV) environment, user's service is done
		by Service Function Chain (SFC) composed by Virtual Network Function (VNF) in a
		certain order, so user's request can be called SFC Request ( SFC Request, SFCR).
		Given a series of SFCRs, it requires instantiating and deploying the corresponding
		VNFs to complete these services. The software features of VNFs allow more flexibility
		in the selection of deployment locations and resource allocation. In addition, during
		the process of SFCR mapping, it is necessary to consider the sequential constraints
		of the VNFs that make up its SFCs to avoid additional bandwidth usage as much as possible.
		Thus, in the process of SFC scheduling and VNF deployment, it is necessary to design an
		optimal solution to improve the resource utilization of the network, which is also known
		as the SFC scheduling and VNF deployment problem.</t>
      <t>The scheduling of service function chains and deployment of virtual network functions
		include three main parts: determination of the mapping scheme, deployment and management,
		among which the determination of the mapping scheme as a key step in the scheduling will
		affect the costs associated with the subsequent processes. How to reasonably deploy each
		virtual network function which constitutes the service function chain in the physical topology
		and reduce the overhead of physical resources is a major challenge for the current mapping
		scheme determination problem. In addition, with the development of emerging technologies such
		as 5G, many latency-sensitive applications such as virtual reality, augmented reality, and
		autonomous driving have emerged, which put forward high requirements on the end-to-end latency
		of Service Function Chain, and how to reduce the end-to-end latency of Service Function Chain
		to a certain extent is another major optimization goal and challenge of the mapping problem.</t>
    </section>
    <section anchor="section_Terminology" numbered="true" toc="default">
      <name>Terminology</name>
      <t>
	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 <xref target="RFC2119" format="default">RFC 2119</xref> <xref target="RFC8174" format="default">RFC 8174</xref>.
      </t>
      <t>This document uses the following terms from <xref target="RFC7665" format="default">RFC 7665</xref> <xref target="RFC8763" format="default">RFC 8763</xref>:
      </t>
      <ul>
        <li>Network Function Virtualization (NFV)</li>
        <li>Virtualize Network Function (VNF)</li>
        <li>Service Function (SF)</li>
        <li>Service Function Chain (SFC)</li>
        <li>Service Function Chains (SFCs)</li>
        <li>Service Function Chain Request (SFCR)</li>
      </ul>
      <t>This document introduces the following terms:
      </t>
      <ul>
        <li>Grey Wolf Optimizer (GWO)</li>
        <li>Improved Grey Wolf Optimization (IMGWO):Improved standard gray wolf optimization
		  algorithm using a reverse learning-based population initialization strategy and a
		  convergence factor nonlinear optimization strategy.</li>
        <li>IMGWO-SFCM:This document proposes a service function chain mapping method based on
		  the improved GWO algorithm for the service function chain mapping and deployment resource
		  optimization problems.</li>
        <li>VG-SFCM:This document proposes a granular variable service function chain mapping
		  algorithm based on microservice architecture for service function chain mapping and
		  deployment latency optimization problems.</li>
        <li>AtomNF:It is defined as a fine-grained microservice unit that represents the smallest
		  logical unit that operates on data after the virtual network function has been split in
		  the service function chain.</li>
      </ul>
    </section>
    <section anchor="sect2" numbered="true" toc="default">
      <name>Example of SFC scheduling implementation algorithm</name>
      <t>Network resources in network topology are limited, and Network Function Virtualization (NFV)
		presents new challenges in terms of how to efficiently map and deploy Service Function Chain (SFC)
		based on user's Service Function Chain Request (SFCR) while saving operators' cost. This document
		presents examples of Variable Granularity Service Function Chain Mapping(VG-SFCM) based on microservices architecture 
		algorithm and Improved Grey Wolf Optimization Service Function Chain Mapping ( IMGWO-SFCM ) algorithm for
		both latency optimization and resource optimization respectively.</t>
      <section numbered="true" toc="default">
        <name>Mapping algorithm of granularity variable SFC based on microservice architecture</name>
        <t>There are many logical functions that are repeatedly performed between different individual
			VNFs within a single SFC, such as packet input and output, message classification, etc. In the
			process of SFC mapping, considering the minimum granularity of the mapping and performing microservice
			splitting and merging can effectively remove these redundant logical functions and reduce the end-to-end
			delay and resource overhead incurred during deployment according to the mapping solution. Considering
			the splitting and optimization of VNFs within SFCs, we propose a Variable Granularity Service Function
			Chain Mapping algorithm (VG-SFCM) based on microservice architecture.
        </t>
        <t>Firstly, the set of microservice units (AtomNFs) constituting the original SFC is obtained by fast
			splitting based on typical VNF, and then the redundant AtomNFs within a single SFC are merged by applying
			the merging strategy of redundant AtomNFs and drawn to form a new SFC service graph, then finally, the
			instantiation of AtomNFs is further reduced by the AtomNF reuse strategy among SFCs.
        </t>
        <t>The splitting of VNFs is mainly based on the set of VNFs and their corresponding logical functions, and the VNFs
			are split into several fine-grained AtomNFs, which cannot be fully automated at this stage due to the different functions
			provided by different VNFs, and still requires a lot of manual work to complete the logical analysis and AtomNF definition.
			In order to realize the fast splitting of SFC and reduce the resource overhead caused by the splitting, the fast splitting
			based on typical VNF prepares the logical analysis and splitting work in advance by logically analyzing the VNFs that appear
			more frequently and preparing the AtomNF image file corresponding to the high-frequency VNFs in advance and putting them into
			the repository. When a SFCR arrives, it can quickly find and directly pull the relevant mirror according to the relevant VNF
			splitting scheme. If there is a VNF in SFC that is not pre-split, we do not split it and treat it as a coarse-grained single unit.
        </t>
        <t>
			Different VNF may get several identical AtomNF after splitting, and repeated execution of the same AtomNF does not bring actual
			changes to the data flow instead it increases the resource overhead and end-to-end delay of the corresponding mapping nodes, so
			we can analyze and merge these multi-occurring AtomNF. Referring to the classification rules of MicroNF, AtomNF is classified
			into six categories: endpoint, classification, modification, reconfiguration, flow control and static for merging. In order to
			ensure that the new SFC after merging can provide the same services as before merging, while minimizing the end-to-end latency,
			the merging of AtomNF needs to comply with the following principles.
        </t>
        <ul spacing="normal">
          <li>The packets must undergo the same processing steps as the original SFC, but some of the redundant
				steps may be performed less frequently.
				</li>
          <li>Each AtomNF with multiple executions is subject to a merge likelihood analysis that seeks to compress
				the end-to-end length of the SFC as much as possible.
				</li>
          <li>The location of an AtomNF in the new SFC can be changed, but the change cannot cause the data flow to
				change compared to the original SFC.
				</li>
        </ul>
        <t>The reuse of VNF or AtomNF instances can currently be realized by multi-tenancy technology, which enables a single software
			instance to provide corresponding services for multiple tenants. Compared with the traditional non-reusable mapping scheme, the
			node resource utilization can be effectively improved by providing services for SFCRs through one reusable AtomNF instance in SFC
			mapping process. In order to realize the reuse of subsequent requests, the first arriving SFCR need to determine the best mapping
			scheme through IMGWO-SFCM. After the subsequent arriving SFCRs complete the initial scheduling and splitting and merging work,
			they judge the intersection of their AtomNF sets with the AtomNF sets of the previous SFCR, and the resulting intersection is
			the reusable AtomNFs, and then perform the reusability judgment of the relevant microservice unit mapping nodes.After the
			screening of reusable AtomNFs is completed, the corresponding node is checked for resources to determine whether the remaining
			resources of the node can carry the remaining non-reusable AtomNFs of the SFC. If it cannot, the relevant AtomNFs are deployed
			to the neighboring nodes with sufficient resources. When there is no available resource in the neighboring nodes to meet the relevant
			demand, the mapping scheme is determined by IMGWO-SFCM for the SFC again.
        </t>
        <t>Using splitting, merging and multiplexing strategies for SFC, VG-SFCM reduces the instantiation of AtomNF, and effectively reduces
			ends-to-ends latency of SFC, which can also minimize the cost of network deployment to a certain extent.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Improved Grey Wolf Optimization Service Function Chain Mapping</name>
        <t>For SFCR initiated by users at the application layer, the control layer needs to orchestrate it into SFC after receiving it. The
			SFC deployed according to different mapping schemes consume different computing resources, memory resources and bandwidth resources,
			and also incur different node activation costs and deployment costs.
        </t>
        <t>The mapping and deployment of SFC needs to obey the following four basic principles.
        </t>
        <ul spacing="normal">
          <li>The end-to-end latency of SFC after deployment needs to be within the maximum
				acceptable latency of user requests.
				</li>
          <li>The computing resources provided by the physical node selected for SFC after
				deployment need to be greater than what is required by all VNFs deployed in that node.
				</li>
          <li>The bandwidth of the link through which the data flow between the physical nodes
				selected by SFC needs to meet the bandwidth requirements of SFC.
				</li>
          <li>The direction of the data flow needs to strictly follow the order of SFC constructed
				for user requests.
				</li>
        </ul>
        <t>First, we search the first K paths between the source and destination nodes by the loop-free
			KSP search algorithm and search the possible mapping schemes according to the first K shortest
			paths and the number of VNFs to be deployed in the SFC. Subsequently, the matching of individual
			gray wolves with the mapping scheme is completed by mapping scheme coding. Then, we initialize
			the gray wolf population according to the backward learning strategy of Improved Gray Wolf
			Optimization algorithm (IMGWO), select the dominant gray wolf individuals according to the
			optimization function, i.e., the fitness function, and then enhance the global search and local
			search ability of the algorithm in the early stage by the nonlinear convergence strategy of the
			convergence factor. Finally, we determine the final mapping scheme by iteration.
        </t>
        <t>The standard gray wolf optimization algorithm suffers from slow late convergence and easily
			falls into local optimum, so an improved gray wolf optimization algorithm (IMGWO) is proposed
			by improving the standard gray wolf optimization algorithm through the group initialization strategy
			based on reverse learning and the convergence factor nonlinear optimization strategy. The gray wolf
			optimization group initialization based on the backward learning strategy first randomly generates
			the initial wolf group and generates the reverse wolf group based on the initial wolf group. Subsequently,
			the top three individuals with the highest fitness in the two groups are determined according to the
			fitness function. Meanwhile, in order to improve the global search ability and local search ability of the standard GWO algorithm and avoid falling
			into local optimal solutions, the nonlinear optimization strategy is applied to the convergence factor a.
        </t>
        <t>The group initialization strategy based on backward learning and the convergence factor nonlinear
			optimization strategy make IMGWO algorithm a good balance of global search and local search ability,
			which can accelerate the overall convergence speed of the algorithm.	
        </t>
        <t>The IMGWO algorithm can be divided into seven steps as follows.
        </t>
        <ol spacing="normal" type="1"><li>Set the initialization size of gray wolf population, the
				maximum number of iterations, initialization and other parameters.
				</li>
          <li>Generate the initial group based on the results of random initialization
				using reverse learning.
				</li>
          <li>Calculate the fitness value of each individual gray wolf in the group, select
				the top three dominant wolves according to the fitness value, and record their positions.
				</li>
          <li>Update the value of convergence factor according to the convergence factor nonlinear optimization
				strategy and update the values of each parameter.</li>
          <li>Update the individual positions of gray wolves.
				</li>
          <li>Calculate the group fitness value after updating the individual positions of gray wolves and update
				the dominant wolves and their positions.</li>
          <li>Judge whether the constraint of the algorithm is reached, or the maximum number of iterations is
				reached, if it is met, the algorithm ends and the optimal solution is output; if it is not met, return
				and re-execute steps 3 to 6.
				</li>
        </ol>
        <t>The steps of the implementation of IMGWO-SFCM algorithm are as follows.
        </t>
        <ol spacing="normal" type="1"><li>First, the physical node resources, computing resources and bandwidth resources required for SFC
				are calculated based on the network topology and SFC service diagram, and whether a single-node
				deployment can be performed based on the corresponding resource status. If the node has sufficient
				resources for SFC deployment, it further determines whether the end-to-end delay after deployment
				can meet the lowest delay requirement of users. For the case where multiple nodes meet the lowest
				latency requirement for individual deployment, the physical nodes are mapped according to the principle
				of minimizing the end-to-end delay of SFC.
				</li>
          <li>After finishing the judgment of single-node mapping possibility, the algorithm starts to perform the
				steps related to the determination of multi-node mapping scheme. Firstly, according to the source and
				destination nodes of SFC, it applies the qualified loop-free KSP algorithm to perform the screening of
				the first K shortest paths, and then it performs further search of possible mapping schemes through the
				single-link mapping scheme, which enables the initialization range of gray wolf group to be determined.
				Finally, the best mapping scheme is output through the IMGWO related process.
				</li>
        </ol>
      </section>
    </section>
    <!--section title="Using Typed Artwork">
        <t>The <spanx style='verb'>artwork</spanx> element from RFC&nbsp;2629 supports an 
        optional <spanx style='verb'>type</spanx> attribute. While most possible values are 
        just ignored, including the special case where the attribute is unspecified or just 
        empty, some values are recognized. In particular, 
        <spanx style='verb'>type='abnf'</spanx> can be used if the 
        <spanx style='verb'>artwork</spanx> contains an Augmented Backus-Naur Form (ABNF)
        syntax specification&nbsp;<xref target='RFC4234' />. As a special extension in its 
        <spanx style='emph'>behavior</spanx>, <spanx style='strong'>xml2rfc</spanx> will 
        attempt to validate the syntax and colorize the HTML output of ABNF, since it is so 
        widely used in RFCs. It does this colorizing by relying on the full parsing it does 
        right before, not on a quick and partial (e.g., line-by-line) pattern-based hack.
        ABNF is the only artwork type to benefit from this kind of internal support at this 
        time. If the <spanx style='verb'>strict</spanx> rfc-PI directive is activated, 
        invalid ABNF content will cause <spanx style='strong'>xml2rfc</spanx> to abort with an 
        error message. Omitting the <spanx style='verb'>type</spanx> attribute altogether 
        is the obvious way to avoid having this validation and colorizing performed.</t>
    
        <figure align='left'>
            <preamble>For example (to be viewed in HTML):</preamble>
            <artwork align='center' type='abnf'><![CDATA[
char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                       ; quoted string of SP and VCHAR
                          without DQUOTE

num-val        =  "%" (bin-val / dec-val / hex-val)

bin-val        =  "b" 1*BIT
                  [ 1*("." 1*BIT) / ("-" 1*BIT) ]
                       ; series of concatenated bit values
                       ; or single ONEOF range

dec-val        =  "d" 1*DIGIT
                  [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]

hex-val        =  "x" 1*HEXDIG
                  [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]

prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
                       ; bracketed string of SP and VCHAR
                          without angles
                       ; prose description, to be used as
                          last resort
]]>
            </artwork>
            <postamble>This is from the original RFC on ABNF&nbsp;<xref target='RFC2234' />, 
            with its minor mistakes in manually folded comment lines purposely left intact, 
            for illustration. Since the result is still valid ABNF (but incorrect with respect 
            to what was intended), this showcases how colorizing might give a human author
            (or editor or reader) a better chance to spot the three mistakes (and correct them, 
            e.g., with extra semicolons, as has been done in a more recent 
            version&nbsp;<xref target='RFC4234' /> of the ABNF specification). Note that it is 
            the white space characters at the beginning of the subsequent lines (including the 
            commented ones) that conspire to extend the reach of those rules across several 
            lines.</postamble>
        </figure>
    </section-->
    
    <!--section title="Decrypting XML2RFC Parsing errors">
        <t>The most common form of xml2rfc parsing errors are those where a
        closing tag has been expected to be present before a new kind of tag is
        specified.  In the example below, Introduction section's last paragraph was
        missing the closing t-element.  The rest of the error messages can be rather
        easily understood as well by reading it carefully and examining the context.
        The reason is typically a missing tag somewhere.</t>
        <figure>
            <artwork>
<![CDATA[
======8<=========
end tag "section" does not match open element "t" around line 65

Context: 
    <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="full3667" category="info" 
         docName="draft-ietf-template-edu-full-00.txt" 
         updates="1,2"
         obsoletes="3">
    <middle>
    <section title="Introduction">
    <t>
=======8<========
]]>
            </artwork>
        </figure>
    </section-->
    <!--section title="Example of code or MIB module to be extracted"
             anchor="codeExample">
        <figure>
            <artwork>
<![CDATA[
/**** an example C program */

#include <stdio.h>

void
main(int argc, char *argv[])
{
    int i;

    printf("program arguments are:\n");
    for (i = 0; i < argc; i++) {
        printf("%d: \"%s\"\n", i, argv[i]);
    }

    exit(0);
} /* main */

/* end of file */
]]>
            </artwork>
        </figure>
    </section-->
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to Hong Chen and Zhang Junnan for the first draft.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->
<back>
    <!-- References split to informative and normative -->
	
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119" target="http://xml.resource.org/public/rfc/html/rfc2119.html">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement 
                Levels</title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner">
            <organization>Harvard University</organization>
          </author>
          <date year="1997" month="March"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <!-- <reference anchor="RFC8300" target="https://www.rfc-editor.org/info/rfc8300"> -->
            <!-- <front> -->
				<!-- <title>Network Service Header (NSH)</title> -->
				<!-- <author initials="P." surname="Quinn" fullname="P. Quinn" role="editor"> -->
					<!-- <organization/> -->
				<!-- </author> -->
				<!-- <author initials="U." surname="Elzur" fullname="U. Elzur" role="editor"> -->
					<!-- <organization/> -->
				<!-- </author> -->
				<!-- <author initials="C." surname="Pignataro" fullname="C. Pignataro" role="editor"> -->
					<!-- <organization/> -->
				<!-- </author> -->
				<!-- <date year="2018" month="January"/> -->
			<!-- </front> -->
			<!-- <seriesInfo name="RFC" value="8300"/> -->
			<!-- <seriesInfo name="DOI" value="10.17487/RFC8300"/> -->
		<!-- </reference> -->
		
		<reference anchor="RFC7665" target="https://www.rfc-editor.org/info/rfc7665">
        <front>
          <title>Service Function Chaining (SFC) Architecture</title>
          <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern"/>
          <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/>
          <date month="October" year="2015"/>
        </front>
        <seriesInfo name="RFC" value="7665"/>
        <seriesInfo name="DOI" value="10.17487/RFC7665"/>
      </reference>
      <reference anchor="RFC8763" target="https://www.rfc-editor.org/info/rfc8763">
        <front>
          <title>Deployment Considerations for Information-Centric Networking (ICN)</title>
          <author fullname="A. Rahman" initials="A." surname="Rahman"/>
          <author fullname="D. Trossen" initials="D." surname="Trossen"/>
          <author fullname="D. Kutscher" initials="D." surname="Kutscher"/>
          <author fullname="R. Ravindran" initials="R." surname="Ravindran"/>
          <date month="April" year="2020"/>
        </front>
        <seriesInfo name="RFC" value="8763"/>
        <seriesInfo name="DOI" value="10.17487/RFC8763"/>
      </reference>
    </references>
    <!-- <references title="Informative References"> -->
        <!-- A reference written by by an organization not a persoN. -->
        <!--reference anchor="RFC7498" target="https://www.rfc-editor.org/info/rfc7498">
            <front>
				<title>Problem Statement for Service Function Chaining</title>
				<author initials="P." surname="Quinn" fullname="P. Quinn" role="editor">
					<organization/>
				</author>
				<author initials="T." surname="Nadeau" fullname="T. Nadeau" role="editor">
					<organization/>
				</author>
				<date year="2015" month="April"/>
			</front>
			<seriesInfo name="RFC" value="7498"/>
			<seriesInfo name="DOI" value="10.17487/RFC7498"/>
		</reference-->
		
		<!-- <reference anchor="RFC7665" target="https://www.rfc-editor.org/info/rfc7665"> -->
            <!-- <front> -->
				<!-- <title>Service Function Chaining (SFC) Architecture</title> -->
				<!-- <author initials="J." surname="Halpern" fullname="J. Halpern" role="editor"> -->
					<!-- <organization/> -->
				<!-- </author> -->
				<!-- <author initials="C." surname="Pignataro" fullname="C. Pignataro" role="editor"> -->
					<!-- <organization/> -->
				<!-- </author> -->
				<!-- <date year="2015" month="October"/> -->
			<!-- </front> -->
			<!-- <seriesInfo name="RFC" value="7665"/> -->
			<!-- <seriesInfo name="DOI" value="10.17487/RFC7665"/> -->
		<!-- </reference> -->
		
    <!-- </references> -->
</back>
</rfc>
