<?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" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5693 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>

<?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. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?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="4"?>
<!-- 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-fu-sfc-topology-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Topology for SFC">The topology of service function chaining</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Qiao Fu" initials="Q.F" role="editor" surname="Fu">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>Xuanwumenxi Ave. No.32</street>

          <!-- Reorder these if your country does things differently -->

          <city>Beijing</city>

          <region/>

          <code/>

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

        <phone/>

        <email>fuqiao1@outlook.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
 <author fullname="Joel. Halpern" initials="J.H" surname="Halpern">
      <organization>Ericsson</organization>

      <address>
 

        <phone/>

        <email>jmh@joelhalpern.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author> 
    <author fullname="Hui Deng" initials="H.D" surname="Deng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>Xuanwumenxi Ave. No.32</street>

          <!-- Reorder these if your country does things differently -->

          <city>Beijing</city>

          <region/>

          <code/>

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

        <phone/>

        <email>denghui@chinamobile.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>    

   
    

    <date month="October" year="2015"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>APP</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <!---->

    <abstract>
      <t>This document proposes a deployment topology of Service Function 
      	Chaining(SFC). The topology is in accordance with the SFC architecture 
      	in <xref target="I-D.ietf-sfc-architecture"/>. Currently,  such 
      	architecture only includes architectural concepts, principles, and
   			components used in the construction of composite services through
   			deployment of SFCs, without any instruction for the field deployment. 
   			It is still difficult to map from the architecture to a real deployment 
   			of SFC. In this document, we propose this topology which will give 
   			instructions for the field deployments. We further propose a VCPE usecase
   			of SFC in the transport network, which explains the details of the deployment
   			topology.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The definition and instantiation of an ordered set of service functions 
      	and subsequent 'steering' of traffic through them is termed as Service Function
   			Chaining (SFC). The definition of SFC can be found in 
   			<xref target="I-D.ietf-sfc-problem-statement"/>. In 
   			<xref target="I-D.ietf-sfc-architecture"/>, an architecture for SFC is
   			proposed, which includes the basic architectural concepts, principles, 
   			and components used in the construction of SFCs. The high level logical
   			architecture of SFC is shown in Figure.1, and a detailed architecture
   			is shown in Figure.2. The definition and functions for the components in
   			these figures can be found in <xref target="I-D.ietf-sfc-architecture"/>.
   			</t> 
   			
   			<figure anchor="fig.arch1" title="High Level Logical Architecture for SFC">
        <artwork align="center"><![CDATA[  
      o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
      .  +--------------+                  +------------------~~~
      .  |   Service    |       SFC        |  Service  +---+   +---+
      .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
   +---->|   Function   |+---------------->|   Path    +---+   +---+
      .  +--------------+                  +------------------~~~
      . SFC-enabled Domain
      o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

]]></artwork>
      </figure>
  
  
  <figure anchor="fig.arch2" title="Detailed Architecture for SFC">
        <artwork align="center"><![CDATA[  

         +----------------+                        +----------------+
         |   SFC-aware    |                        |  SFC-unaware   |
         |Service Function|                        |Service Function|
         +-------+--------+                        +-------+--------+
                 |                                         |
           SFC Encapsulation                       No SFC Encapsulation
                 |                  SFC                    |
    +---------+  +----------------+ Encapsulation     +---------+
    |SFC-Aware|-----------------+  \     +------------|SFC Proxy|
    |    SF   | ... ----------+  \  \   /             +---------+
    +---------+                \  \  \ /
                              +-------+--------+
                              |   SF Forwarder |
                              |      (SFF)     |
                              +-------+--------+
                                      |
                              SFC Encapsulation
                                      |
                          ... SFC-enabled Domain ...
                                      |
                          Network Overlay Transport
                                      |
                                  _,....._
                               ,-'        `-.
                              /              `.
                             |     Network    |
                             `.              /
                               `.__     __,-'
                                   `''''

]]></artwork>
      </figure>    
      
      <t>However, the architecture proposed in <xref target="I-D.ietf-sfc-architecture"/>
      	provides little instructions for field deployment of SFC. The definitons
      	for each component are abstract and are difficult to be mapped to current 
      	network. Therefore, in this document, a topology of field deployment of SFC 
      	is proposed. We further propose a usecase of vCPE using SFC to fully explain
      	the topology.</t>
 </section>
 
     <section title="Terminology">
      <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"/>.</t>
    </section>
    
 <section title="Topology of SFC in current network">
 	
 	  <t>Figure.3 shows the topology of deployment of SFC in the current network. 
 	  	In general, there are two choices of the deployment of the SFs. One is 
 	  	to locate in the data centers of Operators. And the other is to co-locate with 
 	  	the Openrator Gateways(GWs). Such GWs can be in the aggregate networks or 
 	  	the core networks. These two deployments both have their advantages. For 
 	  	the first one, the traffic do not need to travel to the DC and back. For 
 	  	the second one, it will be easier for us to manage and maintain these SFC 
 	  	devices. </t>
 	  	
 	  	<t>The Operator GWs should act as SCF(Service Classification Function) and
 	  	SFF (Service function Forwarder) in the SFC architecture. This SFF should be 
 	  	responsible for adding SFC-header to the packets. Multiple SFFs can be deployed
 	  	after the GW in large scale use cases, so as to avoid large volume of traffic 
 	  	returning to the GW continiously.</t>
 	  	
 	  	<t>The deployment topology of colocating the SCF and SFF will simplify the 
 	  	classification and forwarding. SFF can add the SFC header to the traffic 
 	  	flow directly according to the SCF result, and can support re-classification 
 	  	easily. In the meantime, in some usecases, the SCF can act as classifier of 
 	  	traffic flows so as to classify the traffic that need to go through the SFC 
 	  	region and the others that do not need. In the following VCPE usecase, we can 
 	  	show the colocation of the GW with the SCF and the SFF can greatly simplify 
 	  	the network deployment. However, such topology will complicate the Operator 
 	  	GW. There are other deployments that the SCF and/or the SFF are located 
 	  	outside the GW, in which case interaction and interface between the GW, the 
 	  	SCF, and the SFF is required.</t>
 	    
 	    <figure anchor="fig.arch3" title="Topology for SFC in the Mobile Networks">
        <artwork align="center"><![CDATA[  
                                     +---------------+      
                                     |SFC Unaware SF3| 
                                     +------+--------+ 
                                            |
                                            |
             +-----+      +-----+      +----+----+   
             | SF1 |      | SF2 |      |SFC Proxy|
             +--+--+      +--+--+      +--+------+    
                |            |            |
                +------+     |      +-----+
                       |     |      |
                    +--+-+ +-+--+ +-+--+
                    |SFF1| |SFF2| |SFF3|
                    +--+-+ +-+--+ +-+--+
                       |     |      |
                     +-+-----+------+--+
                     |GW               |
+------+             | +-----+ +-----+ |           +----------+
| User +-------------+-+ SCF +-+ SFF +-+-----------+ Internet |
+------+             | +-----+ +-----+ |           +----------+
                     +-----------------+
]]></artwork>
      </figure>    
      
 	  
 	</section>
 	
 	<section title="vCPE usecase of SFC">
 	       
      <t> In this document, we also propose a usecase of Service Function Chaining
      	 (SFC) to realize virtual CPE in the Transport Network. Such VCPE would 
      	 provide value-added services, including L4-L7 network functions to the
      	 traditional transport network customers. In order to flexibly control 
      	 the traffic flow, we also introduce SDN-controller (Software Define 
      	 Network Controller) into the transport network. The SDN-controller is 
      	 responsible for directing the traffic of certain enterprise customer, 
      	 who has paid for the VCPE services, to the VCPE servers.</t>

      <t>The concept of VCPE is to shift most of the networking and service 
   			functionalities from the customer side to the network side.  In this way, 
   			the customer side's equipment, that is the CPE, can be simplified. The 
   			VCPE refers to one or a set of equipments at the network side to execute 
   			the networking and service functionalities used to be executed at the CPE. 
   			In such architecture, the CPE can be a simple L2 switch, which is only 
   			responsible for forwarding packets to a certain next hop. The VCPE can 
   			be realized by a SFC in the physical network or the virtual network, 
   			in which the traffic of each customer is directed to one or several 
   			Service Founctions (SF) specified by the customer.</t>
   			
   		
      </section>
      



    

   
    <section title="Topology of VCPE Deployment">
      <t>Following the topology given in the previous section, we will propose a
      	usecase of VCPE deployment in the current Transport network. The traditional 
      	transport network uses static allocation mechanism in general. In order to 
      	provide network connection between different locations for the enterprise 
      	customers, traditional transport network should allocate dedicated lines 
      	between each pair of the locations. Such architecture is not suitable when 
      	the enterprise customers require LAN access, and moreover, L3-L7 functions 
      	among different locations. Therefore, we introduce Virtual Customer Premise 
      	Equipment (VCPE) into the Transport network. By utilizing SFC, the VCPE can 
      	provide value-added services, such as firewall (FW), NAT, and etc., to the 
      	traditional transport network customers. With the emergance of the NFV 
      	technologies, these services can be one or a set of VNFs on the VCPE servers. 
      	Such architecture provides an agile mechanism for operators to launch 
      	value-added services for the transport network.</t>
     
      <t>Figure 4 shows the topology of deployment of the usecase for VCPE in
      	the transport network. The solid lines indicate data traffic flows, while
      	the dash lines indicate control traffic flows. In this architecture, 
      	the CPEs are located at different branches of the enterprise customer,
      	and act as L2 forwarding switches. The VCPE is located at the DC, or 
      	co-located with the aggregate GW.</t> 
      	
      	 <figure anchor="fig.arch4" title="Topology of Deployment of VCPE in the transport network">
        <artwork align="center"><![CDATA[
        	 
           +-----------------------+
      .....+    SDN-Controller     +............
      :    +----+------------------+           :
      :         :                              :
      :         : +------------------------+   :
      :         : | VCPE                   |   :
      :         : | +---+   +---+   +---+  |   :                         
      :         : | |SF1|   |SF2|   |SF3|  |   :
      :         : | +-+-+   +-+-+   +-+-+  |   :
      :         : |   |       |       |    |   :
      :         : | +-+--+  +-+--+  +-+--+ |   :
      :         : | |SFF1|  |SFF2|  |SFF3| |   :
      :         : + +-+--+  +-+--+  +-+--+ |   :
      :         : +---+-------+-------+----+   :
      :         :     +---+   |   +---+        :
      :         :         |   |   |            :
  +---+------+  :      +--+---+---+-+     +----+-----+
  | +-+---+  |  .......++---+  +---+|     |  +-+---+ |
  | | CPE +--+---------++SCF+--+SFF++-----+--+ CPE | |
  | +-----+  |         |+---+  +---+|     |  +-----+ |
  |Enterprise|         |  Aggregate |     |Enterprise|
  |  Branch  |         | Network GW |     |  Branch  |
  +----------+         +------------+     +----------+
 
]]></artwork>
      </figure>
      
      <t>All of the CPEs and the Aggregate Network GW can be controlled by the 
      	SDN-controller. When the enterprise customer selects a set of the 
      	value-added services, the SDN-controller will inform the CPE of the 
      	customer to direct the traffic flow to a certain Aggregate Network GW 
      	connected to the VCPE. The GW acts as SCF and SFF in the SFC region. It
      	is responsible for classifing the traffic flow of the customers and adding
      	SFC header. And then it will act as SFF and forward the traffic tothe other
      	SFFs in the VCPE based on the SFP (Service Function Path). When finishing 
      	the SFP, the GW will remove the SFC header and forward the traffic flow
      	to the destination CPE. All these traffic flows are directed under the
      	control of the SDN controller.</t>
      	
      <t>There could be another architecture without the SDN controller, in which
      	case, the SCF is used to classify which flow shoud go through the VCPE and
      	enter the SFC region, and which flow should follow the traditional transport 
      	network routine and should be forwarded directly to the destination CPE. </t>
    </section>

    <section title="Details of VCPE deployment in the MPLS-TP Network">
     	
      <t>Since MPLS-TP is widely used in the current transport network, we are going 
      	to propose this usecase based on the MPLS-TP transport network. The traditional
      	transport network is only responsible for providing MPLS-TP connection between
      	each two destinations. No L3-L7 services can be provided based on it. By 
      	introducing VCPE at the aggregate/core network, and using SFC, multiple 
      	L3-L7 services can be provided using the widely deployed MPLS-TP network.</t>
      <t>In the MPLS-TP packet, the PW lable, adhere to the packet by the CPE device at 
      	the customer side of the PTN network, can be used to classify service type. 
      	Such information can be used for Service Clasification Function. Extra 
      	label can also be added into the PW lable to indicate user/network specifics. 
      	Therefore, the SFC can do the service clasification mapping based on the 
      	PW lable in the MPLS-TP packets. In the meantime, MPLS-TP packets should 
      	also be transfered to L3 packets before entering the Service Function 
      	Region, and should be re-encapsulated to the MPLS-TP packets after leaving 
      	the Service Function Region. According to the deployment topology, the 
      	aggregate GW is acting as both ingress and egress GW of the SFC region. 
        In this case, the aggregate GW should record the mapping relationship
        of the IP address and PW/LSP label of each packet, and should make sure
        pf adding the exact same MPLS-TP header to the packets when they finish
        the SFP and exit the SFC region, so that the packet can continue its path
        in the transport network using the MPLS-TP header. Therefore, in the 
        MPLT-TP network, the aggregate GW shoule follow the following steps when 
        an MPLS-TP packet arrives at the aggregate network.</t>

      <t>1) Mapping PW lable to a certain Service Founction Path</t>
      
      <t>2) Recording mapping between IP address and PW/LSP lable, so as to 
      	re-encapsulate the L3 packets with a certain IP address.</t>
      	
      <t>3) Transfering MPLS-TP packets to L3 packets by taking off the MPLS-TP header.</t>
      
      <t>4) Adding SFC header into the L3 packets.</t>
      
      <t>5) Acting as the SFF by forwarding the L3 packets according to the SFP.</t>
      
      <t>6) Taking off the SFC header when the SFP finishes.</t>
      
      <t>7) Transfering the L3 packets to MPLS-TP packets by adding corresponding MPLS-TP
      	header according to the recorded mapping.</t> 
      	
      <t>8) Forwarding the MPLS-TP Packets to the destination.</t>
      
      <t>For step 2, the following table should be maintained by the GW, in which
      	SFP indicates Service Function Path.</t>
      
        <figure anchor="fig1.arch5" title="Mapping table in the GW">
        <artwork align="center"><![CDATA[  
 IP address | LSP label |PW label | SFP 
 -----------+-----------+---------+------
     IP1    |    LSP1   |    PW1  | SFP1
     IP2    |    LSP2   |    PW2  | SFP2 
     IP3    |    LSP3   |    PW3  | SFP3  
 
]]></artwork>
      </figure>    	
      	
      <t>This proposed approach can	reuse the existing MPLS-TP network, so that 
      	operators can use the same transport network platform to support both 
      	the traditional private line service and value added NFV services. From
      	the proposed steps, we can see that colocate the SCF and the SFF with the
      	GW can greatly simplify the whole deployment, since we don't need to 
      	coordinate the mapping info between the SCF and the GW and the SFF. </t> 
      	
      	     
    </section>
    
    <section title="Conclusion">
    	<t>In this document, a topology of SFC is proposed. Such topology follows 
    		the definition and components of the SFC architecture in 
    		<xref target="I-D.ietf-sfc-architecture"/>. Comparing with the abstract
    		architecture proposed, such topology provides deployable guidelines for 
    		SFC.</t>
    	
    	<t>A usecase of VCPE using SFC in the MPLS-TP transport network is further
    		proposed to detailed the deployment topology. Such usecase provides an 
    		agile mechanism for launching new value-added services in the transport 
    		network. SFC is used in the VCPE to chain different SFs for different 
    		flows according to the customers' specification. In the meantime, traffic 
    		flows are directed with the help of the SDN-controller according to the 
    		customers' specification.</t>
    		
    		</section>
    

    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

    <?rfc needLines="8" ?>

    <!-- Possibly a 'Contributors' section ... -->
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'?>

      <?rfc include='reference.I-D.ietf-sfc-architecture.xml'?>
      
      <?rfc include='reference.I-D.ietf-sfc-problem-statement.xml'?>


  

      <!-- A reference written by by an organization not a person. -->
    </references>

    <!-- -->
  </back>
</rfc>
