<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wang-msv-using-virtual-line-card-02"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="no" ?>

  <front>
    <title abbrev="SFC CP">Service Function Chain Control Plane
    Overview</title>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

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

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <author fullname="Danhua Wang" initials="D." surname="Wang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

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

        <email>wangdanhua@huawei.com</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M" surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street>Rennes 35000</street>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C" surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street>Rennes 35000</street>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <author fullname="XianGuo Zhang" initials="X." surname="Zhang">
      <organization>Huawei</organization>

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

          <city>Beijing</city>

          <region></region>

          <code>100085</code>

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

        <email>zhangxianguo09@huawei.com</email>
      </address>
    </author>

    <author fullname="Yang Shi" initials="Y." surname="Shi">
      <organization>Huawei</organization>

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

          <city>Beijing</city>

          <region></region>

          <code>100085</code>

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

        <email>shiyang1@huawei.com</email>
      </address>
    </author>

    <date year="2014" />

    <area></area>

    <workgroup></workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword></keyword>

    <abstract>
      <t>As described in [I.D-boucadair-sfc-framework], the dynamic
      enforcement of a Service-derived, adequate forwarding policy for packets
      entering a network that supports such advanced Service Functions has
      become a key challenge for operators and service providers.</t>

      <t>This document is based on [I.D-boucadair-sfc-framework] and focusing
      on discussing how the Service Functions are discovered and provisioned
      and how Service Function Chaining path is setup.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Service Function Chaining(SFC) refers to the delivery of added value
      services by invoking, in a given order, a set of Service Functions along
      the forwarding path towards a specific destination [I.D-quinn-
      sfc-problem-statement]. Service functions involved in a given SFC may
      include advanced Service Functions such as load-balancing, firewalling,
      intrusion prevention. A given SFC domain may involve several instances
      of the same Service Functions. Service Function instances can be
      automatically added or removed to an SFC. Service functions can be
      co-located on the same physical node or be embedded in distinct physical
      nodes.</t>

      <t>As described in [I.D-boucadair-sfc-framework], the dynamic
      enforcement of a SF-derived, adequate forwarding policy for packets
      entering a network that supports such advanced Service Functions has
      become a key challenge for operators and service providers.</t>

      <t>This document is based on [I.D-boucadair-sfc-framework]and is
      focusing on discussing how the set of available Service Functions
      (including several instances of the same Service Function) are
      discovered and provisioned and how Service Function Chaining path is
      setup.</t>
    </section>

    <section title="Conventions used in this document">
      <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">RFC2119</xref>.</t>
    </section>

    <section title="SFC Control Plane Overview">
      <t>The Service Function Chain Control plane Overview proposed in this
      document includes a topology server, policy decision point(PDP), and
      service Function(SF) Nodes, SFC Ingress Node, SFC Egress Node. Service
      functions can be co-located on one SF Node or physically separated
      across several SF Nodes with each having one or more Service Functions.
      The Topology server(Topo Server for short) is used to locate SF Nodes in
      the network as needed. The PDP is a central control/management plane
      entity and used to maintain SFC Policy Tables defined in figure 1 of
      [I.D- boucadair-sfc-framework], and generating and communicating
      appropriate policies in SF Nodes and SFC Ingress/Egress Nodes. To create
      SF map in the SFC Policy tables, PDP may interact with the Topo Server
      using SF node discovery protocol to build SF maps. To communicate
      policies in SF nodes, either fully centralized approach, or half
      centralized approach or distributed approach can be used. <list
          style="symbols">
          <t>In the fully centralized approach, Communication between PDP and
          Topo Server can be used to return computed path information . I2RS
          signaling can be used communicate policy between PDP and SF Node or
          between PDP and SF Ingress/Egress Node. </t>

          <t>In the distributed approach, The Topo server communicate with SFC
          Ingress Node and returns computed path in the Explicit Route Object
          in the response [I.D-wu-pce-traffic-steering-sfc]. SFC Ingress Node
          then can use RSVP-TE to initiate signaling and communicate policy
          with each SF Node and establish the service Function Chaining
          path.</t>

          <t>In the half centralized approach, The Topo server communicate
          with SFC Ingress Node and return the path computation results to SFC
          Ingress Node and then SFC Ingress Node uses RSVP-TE to populate the
          Path profile Identifier in each SF node
          [I.D-wu-pce-traffic-steering-sfc]. Then each SF node can use Path
          Profile Identifier to request PDP for SF path profile.</t>
        </list></t>

      <figure>
        <artwork>                           +-------------+
     +---------------------|             |
     | (e.g.,PCEP, ALTO..) | Topo Server |
     |  +------------------|             |
     |  |                  +----A--------+
     |  |                       |     |
     |  |                       |     |(e.g.,PCEP, ALTO..)
     |  |      Netconf..   +----|-----V--+
     |  |   +--------------&gt;     PDP     &lt;------------------+
     |  |   |              |             &lt;---+              |
     |  |   |              +-A-----------+   |              |
     |  |   |                |               |              |
     |  |   |                |               |              |
     |  |   |  RSVP-TE..     |               |              |
   +-V--V---V--+     +-------V-+      +------V--+     +-----V------+
   |SFC Ingress|     |   SF    |      |  SF     |     | SFC Egress |
   |  Node     |----&gt;|  Node1  |-----&gt;| Node2   |----&gt;|    Node    |
   |           |&lt;----|         |&lt;---- |         |&lt;----|            |
   +-----------+     | SF1 SF2 |      | SF3 SF4 |     +------------+
                     +---------+      +---------+
</artwork>
      </figure>
    </section>

    <section title="Signaling procedure">
      <section title="Building Service Topology ">
        <t>Network topology information can be collected from network by using
        IGP or BGP-LS [I.D-draft-idr-ls-distribution].</t>

        <t>Not all SF Nodes can be directly connected. The Service overlay
        creates a forwarding path between SF Nodes or connected graph for
        these SF Nodes. SF nodes can be co-located on the same physical node
        or be embedded in distinct physical nodes. A service specific overlay
        utilized by SFC creates the service topology. Service topology
        information includes SF Identifier, SF Locator, Service Function
        administration information (Packet rate utilization,Bandwidth
        utilization per CoS,Packet rate utilization per Cos,Memory
        utilization, RIB utilization per address family, FIB utilization per
        address family,,available memory,CPU utilization,Available storage)or
        Service Function capability information(e.g.,supported ACLnumbers,
        virtual context number,supported-packet-rate) Service topology
        information can be collected by the Topo server using either I2RS
        interface or routing protocol. The Topo Server can be collocated with
        PDP or physically separated from the entity that supports the PDP.</t>

        <t>Within the service topology, an ordered set of SF nodes will be
        invoked for each packet that belongs to a given flow for which a SFC
        will be applied. Adding new Service Functions to SF Node in the
        Service topology is easily accomplished, and no underlying network
        changes are required. Furthermore, additional service Functions or
        Service Function instances, for redundancy or load distribution
        purpose, can be added or removed to the service topology as
        required.</t>
      </section>

      <section title="Service Function Discovery">
        <t>When service topology is created by a service-specific overlay
        utilized by Service Function Chaining, each Service Function type is
        assigned with a unique SF identifier and can be located using SF
        locator. There are one approache for Service Function Discovery <list
            style="symbols">
            <t>PDP initiated Service Function Discovery <list>
                <t>Upon receiving service request, PDP send path computation
                request to Topo server.</t>
              </list><vspace blankLines="1" /></t>
          </list></t>

        <t>The Service request carries various constraint information or
        resource requirements(e.g., SF location constraint, SF order
        constraint, SF capability information) The topo Server looks up
        service topology information and returns either computed path or path
        profile Identifier to the PDP. In the centralized approach, the Topo
        server will return computed path to the PDP. In the distributed
        approach, the Topo server will send computed path to the SF Ingress
        Node. In the half centralized approach, the Topo server will only
        return path profile Identifier to the SF Ingress Node. </t>
      </section>

      <section title="Service Function Map Selection">
        <t>In either PDP initiates Service Function Discovery or SF Ingress
        Node Initiated Service Function Discovery, PDP will compose the
        Service Function Map based on the returned computed path. If there are
        multiple Service Functions or Service Function Instances can satisfy
        service requirements, the PDP will select appropriate Service Function
        based on Service Functions capability info or local policy to build
        Service Function Map.</t>
      </section>

      <section title="Building Service Function Chaining (SFC) Policy Tables">
        <t>In case of SFC ingress node initiated Service Function Discovery,
        the SFC ingress node retrieves path profile Identifier in the half
        centralized approach and retrieves service Function Map and associated
        Service Function Map index from the Topo server in the distributed
        approach. The SFC ingress Node can create entries in the Policy Table
        based on Service Function Map obtained from the Topo server.</t>

        <t>In case of PDP initiated Service Function Discovery, the PDP
        retrieve computed path information from topo server and compose
        service Function Map based on computed path information and create
        entries in the Policy Table .</t>
      </section>

      <section title="Service Function Chaining Path Setup and Policy configuration">
        <t>In case of SFC ingress node initiated Service Function Discovery,
        SFC ingress node initiate signaling to establish the service chaining
        path. Path Profile ID can be carried in the RSVP-TE message and
        populated to each SF Node in the Service Function Chain. When each SF
        node receives Path Profile ID, it will pull policy table based on Path
        Profile ID from PDP.</t>

        <t>In case of PDP initiated Service Function Discovery, PDP will use
        I2RS interface and communicate policy with each SF node in the Service
        Function Chain. A set of policy templates can be pre-defined, as shown
        in Figure 3. By applying policy template, different service chains are
        pre- provisioned and provided to users. For example, the "DATA_SEC"
        template defined in Figure 3 implies you can choose random
        combinations of these services provided in the "Service-chain"
        list.</t>

        <figure>
          <artwork>
       Policy Template               Service-chain list
                                          DLP            
           DATA_SEC                       AV       
                                          IPS      
                                          DPI      
                                          SIP      

                     Figure 3 Policy Template
</artwork>
        </figure>
      </section>

      <section title="Service Availability">
        <t>In order to check service Function availability for each SF node,
        the control channel should be setup between service function and
        monitoring system to keep track of state change or performance issue.
        The monitoring system can be either collocated with <list
            style="symbols">
            <t>PDP</t>

            <t>or NFVPool Manager</t>

            <t>or vswitch as SF node or overlay node in the service
            overlay.</t>
          </list></t>

        <t>When one service Function is not a mandatory service function(e.g.,
        HTTP optimization service function) in the Service Function Chain and
        break down, this service function can be bypassed from service
        Function chain, the service will not be interrupted since other
        service functions still work well, but service provided by service
        function chain is in the degraded mode. When the service function is a
        mandatory service function (e.g., firewall) in the Service Function
        Chain and break down, the service will be interrupted before this
        service function recovers from failing.</t>

        <figure>
          <artwork>                                                  
                                                  
                                       ^          ^
                                       |          |
                                    +--|----------|--+             
                 ___________________|__|          |  | 
                |                   |             |  |
        +--------+   Heartbeat      |             |  |
        | vFW    |-----------------&gt;|    vSwitch  |  |
        +--------+                  |   (SF Node) |  |
                | __________________|__           |  |        
                      Fail          |  |          |  |
                                    +--|----------|--+
                                       |          |
                                       |          |
                                       |          | 
                                 Security       Failure
                                 Detection ----&gt;
                                 Process        Bypass

                  Figure 4 Heartbeat Monitoring Process</artwork>
        </figure>
      </section>
    </section>

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

    <section title="Acknowledgements">
      <t>The author would like to thank LAC Chidung for his review and
      comments that help improvement to this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>+1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997" />

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <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 RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="I.D-boucadair-sfc-framework">
        <front>
          <title>Service Function Chaining: Framework &amp;
          Architecture</title>

          <author fullname="M. Boucadair" initials="M." surname="Boucadair">
            <organization></organization>
          </author>

          <date month="October" year="2013" />
        </front>

        <seriesInfo name="ID" value="draft-boucadair-sfc-framework-00" />
      </reference>

      <reference anchor="I.D-quinn-sfc-problem-statement">
        <front>
          <title>Network Service Chaining Problem Statement</title>

          <author fullname="P. Quinn" initials="P." surname="Quinn">
            <organization></organization>
          </author>

          <date month="August" year="2013" />
        </front>

        <seriesInfo name="ID" value="draft-quinn-nsc-problem-statement-03" />
      </reference>

      <reference anchor="I.D-wu-pce-traffic-steering-sfc">
        <front>
          <title>PCEP Extensions for traffic steering support in Service
          Function Chaining </title>

          <author fullname="Q.Wu" initials="Q." surname="Wu">
            <organization></organization>
          </author>

          <author fullname="D. Dhody" initials="D." surname="Dhody">
            <organization></organization>
          </author>

          <author fullname="M. Boucadair" initials="M." surname="Boucadair">
            <organization></organization>
          </author>

          <author fullname="C. Boucadair" initials="C." surname="Boucadair">
            <organization></organization>
          </author>

          <author fullname="J. Tantsura" initials="J." surname="Tantsura">
            <organization></organization>
          </author>

          <date month="Feburary" year="2014" />
        </front>

        <seriesInfo name="ID" value="draft-wu-pce-traffic-steering-sfc-02" />
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="RFC4655">
        <front>
          <title>A Path Computation Element (PCE)-Based Architecture</title>

          <author fullname="A.Farrel" initials="A." surname="Farrel">
            <organization></organization>
          </author>

          <date month="August" year="2006" />
        </front>

        <seriesInfo name="RFC" value="4655" />
      </reference>

      <reference anchor="ALTO">
        <front>
          <title>ALTO Protocol</title>

          <author fullname="Y.Yang" initials="Y." surname="Yang">
            <organization></organization>
          </author>

          <date month="May" year="2013" />
        </front>

        <seriesInfo name="ID"
                    value="http://tools.ietf.org/html/draft-ietf-alto-protocol-16" />
      </reference>
    </references>
  </back>
</rfc>
