<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-wu-pce-traffic-steering-sfc-12"
     ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
     xml:lang="en">
  <front>
    <title abbrev="PCEP for SFC">PCEP Extensions for Service Function Chaining
    (SFC)</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="Dhruv Dhody" initials="D." surname="Dhody">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>Leela Palace</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560008</code>

          <country>INDIA</country>
        </postal>

        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</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="Jacquenet">
      <organization>Orange</organization>

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

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

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

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

      <address>
        <postal>
          <street>2330 Central Expressway</street>

          <city>Santa Clara</city>

          <region>CA</region>

          <code>95050</code>

          <country>US</country>
        </postal>

        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2017"/>

    <area>Routing Area</area>

    <workgroup>PCE Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>PCE</keyword>

    <abstract>
      <t>This document provides an overview of the usage of Path Computation
      Element (PCE) to dynamically structure service function chains. Service
      Function Chaining (SFC) is a technique that is meant to facilitate the
      dynamic enforcement of differentiated traffic forwarding policies within
      a domain. Service function chains are composed of an ordered set of
      elementary Service Functions (such as firewalls, load balancers) that
      need to be invoked according to the design of a given service.
      Corresponding traffic is thus forwarded along a Service Function Path
      (SFP) that can be computed by means of PCE.</t>

      <t>This document specifies extensions to the Path Computation Element
      Protocol (PCEP) that allow a stateful PCE to compute and instantiate
      Service Function Paths.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Service Function Chaining (SFC) enables the creation of composite
      services that consist of an ordered set of Service Functions (SF) that
      must be applied to packets and/or frames and/or flows selected as a
      result of service-inferred traffic classification as described in <xref
      target="RFC7665"/>. A Service Function Path (SFP) is a path along which
      traffic that is bound to a specific service function chain will be
      forwarded. Packets typically follow a Service Function Path from a
      classifier through the Service Functions (SF) that need to be invoked
      according to the SFC instructions. Forwarding decisions are made by
      Service Function Forwarders (SFF) according to such instructions.</t>

      <t><xref target="RFC5440"/> describes the Path Computation Element
      Protocol (PCEP) as the protocol used by a Path Computation Client (PCC)
      and a Path Control Element (PCE) to exchange information, thereby
      enabling the computation of Multiprotocol Label Switching (MPLS) for
      Traffic Engineering Label Switched Path (TE LSP), in particular.</t>

      <t><xref target="I-D.ietf-pce-stateful-pce"/> specifies extensions to
      PCEP to enable a stateful control of MPLS TE LSPs. <xref
      target="I-D.ietf-pce-pce-initiated-lsp"/> provides the extensions needed
      for stateful PCE-initiated LSP instantiation.</t>

      <t>This document specifies PCEP extensions that allow a stateful PCE to
      compute and instantiate traffic-engineered Service Function Paths
      (SFP).</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>

      <t>This document makes use of these acronyms:</t>

      <t><list style="hanging">
          <t hangText="PCC:">Path Computation Client.</t>

          <t hangText="PCE:">Path Computation Element.</t>

          <t hangText="PCEP:">Path Computation Element Protocol.</t>

          <t hangText="PDP:">Policy Decision Point.</t>

          <t hangText="SF:">Service Function.</t>

          <t hangText="SFC:">Service Function Chain.</t>

          <t hangText="SFP:">Service Function Path.</t>

          <t hangText="RSP:">Rendered Service Path.</t>

          <t hangText="SFF:">Service Function Forwarder.</t>

          <t hangText="UNI:">User-Network Interface.</t>
        </list></t>
    </section>

    <section title="Service Function Paths and PCE">
      <t>Service function chains are constructed as a sequence of SFs, where a
      SF can be virtualized or embedded in a physical network element. One or
      several SFs may be supported by the same physical network element. A SFC
      creates an abstracted view of a service and specifies the set of
      required SFs as well as the order in which they must be executed.</t>

      <t>When an SFC is created, it is necessary to select the specific
      instances of SFs that will be used. A service function path for that SFC
      will then be established (notion of rendered service path) or can be
      precomputed, based upon the sequence of SFs that need to be invoked by
      the corresponding traffic, i.e., the traffic that is bound to the
      corresponding SFC. Note that a SF instance can be serviced by one or
      multiple SFFs. One or multiple SF instances can be serviced by one SFF.
      Thus, the instantiation of an SFC results in the establishment of a
      Service Function Path, either in a hop-by-hop fashion, or by means of
      traffic-engineering capabilities. In the latter case, the SFP is
      precomputed, i.e., an SFP is an instantiation of the defined SFC as
      described in <xref target="RFC7665"/>.</t>

      <t>The computation, the selection, and the establishment of a
      traffic-engineered SFP can rely upon a set of (service-specific)
      policies (forwarding and routing, QoS, security, etc., or a combination
      thereof). Stateful PCE with appropriate SFC-aware PCEP extensions can be
      used to compute traffic-engineered SFPs.</t>

      <figure align="left" alt="" anchor="SEC_FIG1" height=""
              suppress-title="false" title="PCE-based SFP instantiation"
              width="">
        <artwork align="left" alt="" height="" name="" type="" width=""
                 xml:space="preserve">                    SFC Control Plane
               +------------------------+
               |PCE based Controller    |
         I2    | +-------++-------+     |
  +------------- |Policy || TE-DB |     |
  |      I1    | +-------++-------+     &lt;----+
  | +----------|      +-------------+   |    |
  | |SFP       |      |LSP-DB/SFP-DB|   |    |I2
  | |Instan-   |      +-------------+   |    |
  | |tiation   +-----------^------------+    |policy-provisioning
  | |PCEP                  |                 |information/
  | |Signaling          I2 |                 |Carried by NETCONF,
  | |                      |                 |BGP, for example
  | |                      |                 |
  | |                      |                 |
  | |               +------V+           +----+--+
  V V               |       |           |       |
 +-----+  Forwarding|       | Forwarding|       | Forwarding
 | SFC |-----------&gt;| SFF-1 | ---------&gt;| SFF-2 |-----------&gt;
 Classifier         |       |           |       |
 |     |            |       |           |       |
 +-----+            ++-----++           +-----+-+
                     |     |                  |
                  +--+--+ ++----+          +--+--+
                  |SF-1 | |SF-2 |          |SF-3 |
                  |     | |     |          |     |
                  +--+--+ +---+-+          +--+--+
                     |I2      |I2             |I2
                     V        V               V</artwork>
      </figure>

      <t>In Figure 1, the PCE-based Controller [I-D.ietf-teas-pce-central-
      control] in the SFC Control plane is responsible for computing the path
      for a given service function chain. This PCE-based controller can
      operate as a stateful PCE ([I-D.draft_ietf-stateful-pce]) that will
      provide a classifier (a headend from a PCE standpoint) with the
      PCEP-formatted information to instantiate a given SFP. As a consequence,
      the PCE-based controller derives the set of policy-provisioning
      information (namely SFP configuration information and traffic
      classification rules) that will be provided to the various elements
      (Classifier, SFF) involved in the establishment of the SFP.</t>

      <t>By doing so, SFC Classifier can bind a flow to a service function
      chain and forward such flow along the corresponding SFP. The SFC Control
      Plane [I-D.ietf-sfc-control-plane] is also responsible for defining the
      appropriate policies (traffic classification, forwarding and routing,
      etc.) that will be enforced by SFC Classifiers,SFF Nodes and SF Nodes,
      as described in [RFC7665]. From that standpoint, the SFC Control Plane
      embeds a Policy Decision Point that is responsible for defining the SFC
      policies. SFC policies will be provided by the PDP and enforced by SFC
      components like classifiers and SFFs by means of policy-provision
      information. A protocol like NETCONF, BGP can be used to carry such
      policy-provisioning information.</t>
    </section>

    <section title="Overview of PCEP Operation in SFC-Enabled Networks">
      <t>A PCEP speaker indicates its ability to support PCE-computed SFP
      paths during the PCEP Initialization phase via a mechanism described in
      <xref target="SEC_CA"/>. A PCE may initiate SFPs only for PCCs that
      advertised this capability; a PCC follows the procedures described in
      this document only for sessions where the PCE advertised this
      capability.</t>

      <t>As per Section 5.1 of <xref
      target="I-D.ietf-pce-pce-initiated-lsp"/>, the PCE sends a Path
      Computation LSP Initiate Request (PCInitiate) message to the PCC to
      instantiate or delete a LSP. The Explicit Route Object (ERO) is used to
      encode either a full sequence of SF instances or a specific sequence of
      SFFs and SFs to establish an SFP. If the said SFFs and SFs are
      identified with an IP address, the IP sub-object can be used as a SF/SFF
      identification means. This document makes no change to the PCInitiate
      message format but extends LSP objects described in <xref
      target="SEC_LSP"/>.</t>

      <t>Editor's note: In case a PCE-Initiated signaling mechanism is used to
      set up the service function path, does the classifier / PCE-Initiated
      signaling protocol need to understand whether an IP address is assigned
      to a SFF or a SF, or the signaling protocol is only used to signal IP
      addresses for SFs?</t>

      <t>To prevent multiple classifiers assign the same SFP ID to one Service
      Function Path(SFP ID assignment conflict),in this document, we assume
      SFP ID can be predetermined and assigned by stateful PCE when stateful
      PCE can be used to compute traffic-engineered SFPs.</t>

      <section anchor="SEC_INST" title="SFP Instantiation" toc="default">
        <t>The instantiation of a SFP is the same as defined in Section 5.3 of
        <xref target="I-D.ietf-pce-pce-initiated-lsp"/>. Rules for processing
        and error codes remain unchanged.</t>
      </section>

      <section title="SFP Withdrawal" toc="default">
        <t>The withdrawal of an SFP is the same as defined in Section 5.4 of
        <xref target="I-D.ietf-pce-pce-initiated-lsp"/>: the PCE sends an LSP
        Initiate Message with an LSP object carrying the PLSP-ID of the SFP
        and the SFP Identifier to be removed, as well as an SRP object with
        the R flag set (LSP-REMOVE as per Section 5.2 of <xref
        target="I-D.ietf-pce-pce-initiated-lsp"/>). Rules for processing and
        error codes remain unchanged.</t>
      </section>

      <section title="SFP Delegation and Cleanup" toc="default">
        <t>SFP delegation and cleanup operations are similar to those defined
        in Section 6 of <xref target="I-D.ietf-pce-pce-initiated-lsp"/>. Rules
        for processing and error codes remain unchanged.</t>
      </section>

      <section title="SFP State Synchronization" toc="default">
        <t>State Synchronization operations described in Section 5.4 of <xref
        target="I-D.ietf-pce-stateful-pce"/> can be applied to SFP state
        maintenance as well.</t>
      </section>

      <section title="SFP Update and Report" toc="default">
        <t>A PCE can send an SFP Update request to a PCC to update one or more
        attributes of an SFP and to re-signal the SFP with the updated
        attributes. A PCC can send an SFP state report to a PCE, and which
        contains the SFP State information. The mechanism is described in
        <xref target="I-D.ietf-pce-stateful-pce"/> and can be applied to SFPs
        as well.</t>
      </section>
    </section>

    <section title="Object Formats">
      <section anchor="SEC_CA" title="The OPEN Object">
        <t>The optional TLV shown in <xref target="SEC_FIG2"/> is defined for
        use in the OPEN Object to indicate the PCEP speaker's Service Function
        Chaining capability.</t>

        <t>The SFC-PCE-CAPABILITY TLV is an optional TLV to be carried in the
        OPEN Object to advertise the SFC capability during the PCEP
        session.</t>

        <figure align="left" alt="" anchor="SEC_FIG2" height=""
                suppress-title="true" title="SFC-PCE-CAPABILITY TLV Format"
                width="">
          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"> 
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Type=TBD           |            length=4           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                   
|            Reserved           |             Flags             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     
                   </artwork>
        </figure>

        <t>The code point for the TLV type is to be defined by IANA (see <xref
        target="iana"/>). The TLV length is 4 octets.</t>

        <t>As per <xref target="I-D.ietf-pce-stateful-pce"/>, a PCEP speaker
        advertises the capability of instantiating PCE-initiated LSPs via the
        Stateful PCE Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) carried
        in an Open message. The inclusion of the SFC-PCE-CAPABILITY TLV in an
        OPEN object indicates that the sender is SFC-capable. Both mechanisms
        indicate the SFP instantiation capability of the PCEP speaker.</t>
      </section>

      <section anchor="SEC_LSP" title="The LSP Object">
        <t>The LSP object is defined in <xref
        target="I-D.ietf-pce-pce-initiated-lsp"/> and included here for
        reference (<xref target="SEC_FIG3"/>).</t>

        <figure align="left" alt="" anchor="SEC_FIG3" height=""
                suppress-title="true" title="LSP Object Format" width="">
          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"> 
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                PLSP-ID                | Flags |F|C|  O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                        TLVs                                 //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                   
   </artwork>
        </figure>

        <t>A new flag, called the SFC flag (F-bit), is introduced. The F-bit
        set to "1" indicates that this LSP is actually an SFP. The C flag will
        also be set to indicate it was created via a PCInitiate message.</t>

        <section title="SFP Identifiers TLV">
          <t>As described in section 4, SFP ID is predetermined and assigned
          by stateful PCE. The SFP Identifiers TLV MUST be included in the LSP
          object for SFPs. The SFP Identifier TLV is used by the classifier to
          select the SFP along which some traffic will be forwarded, according
          to the traffic classification rules applied by the classifier <xref
          target="RFC7665"/>. The SFP Identifier is part of the SFC metadata
          carried in packets and is used by the SFF to invoke service
          functions and identify the next SFF.</t>

          <t>The format of the SFP Identifier TLV is shown in <xref
          target="sfpid"/>.<figure anchor="sfpid">
              <artwork>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Service Path ID                      | Service Index |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Service Path ID (SPI): 24 bits 
   Service Index (SI): 8 bits</artwork>
            </figure></t>

          <t>SPI: identifies a service path. The same ID is used by the
          participating nodes for path setup/selection. An administrator can
          use the SPI for reporting and troubleshooting packets along a
          specific path. SPI along with PLSP-ID is used by PCEP to identify
          the Service Path. <vspace blankLines="1"/>SI: provides location
          within the service path.</t>
        </section>
      </section>
    </section>

    <section title="Backward Compatibility">
      <t>The SFP instantiation capability defined as a PCEP extension and
      documented in this draft MUST NOT be used if PCCs or the PCE did not
      advertise their stateful SFP instantiation capability,<xref
      target="SEC_CA"> </xref>. If this is not the case and stateful
      operations on SFPs are attempted, then a PCErr message with error-type
      19 (Invalid Operation) and error-value TBD needs to be generated.</t>

      <t>[Editor's note: more information on exact error value is needed]</t>
    </section>

    <section title="SFP Instantiation Signaling and Forwarding Considerations">
      <t>The PCE-initiated SFP instantiation signaling described in this
      document is exchanged between PCE server and SFC Classifier and does not
      assume any specific mechanism to exchange SFP information(e.g.,path
      identification information,metadata <xref target="I-D.ietf-sfc-nsh"/>)
      between SFFs or between SFF and SF, or between the controller and SFF
      and establish SFP in the data plane throughout a SFC domain. For
      example, such mechanism can rely upon the use of the SFC Encapsulation
      defined in <xref target="I-D.ietf-sfc-nsh"/> to exchange SFP information
      between SFFs or rely upon the use of BGP Control plane defined in <xref
      target="I-D.ietf-bess-nsh-bgp-control-plane"/> to exchange SFP
      information between the Controller and SFF.</t>

      <t>Likewise, <xref target="I-D.ietf-teas-pce-central-control"/> can use
      the signaling mechanism described in this draft to enforce SFC-inferred
      traffic engineering policies and provide load balancing between service
      function nodes. The approach that relies upon the Segment Routing
      technique <xref target="I-D.ietf-pce-segment-routing"/> can also take
      advantage of the signaling mechanism described in this document to
      support Service Path instantiation, which does not require any
      additional specific extension to the Segment Routing machinery.</t>
    </section>

    <section title="Security Considerations">
      <t>The security considerations described in <xref target="RFC5440"/> and
      <xref target="I-D.ietf-pce-pce-initiated-lsp"/> are applicable to this
      specification. This document does not raise any additional security
      issue.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>IANA is requested to allocate a new code point in the PCEP TLV Type
      Indicators registry, as follows:<figure>
          <artwork>   Value   Meaning                      Reference
   ------- ---------------------------- --------------
   TBD     SFC-PCE-CAPABILITY           This document</artwork>
        </figure></t>

      <t/>
    </section>

    <section title="Acknowledgements">
      <t>Many thanks to Ron Parker, Hao Wang, Dave Dolson, Jing Huang, and
      Joel M. Halpern for the discussion about the content for the
      document.</t>
    </section>
  </middle>

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

      <?rfc include="reference.I-D.ietf-pce-stateful-pce"?>

      <?rfc include="reference.RFC.5440" ?>

      <?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>

      <?rfc include="reference.I-D.ietf-teas-pce-central-control"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.2753" ?>

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

      <?rfc include="reference.RFC.5394" ?>

      <?rfc include="reference.I-D.ietf-sfc-control-plane"?>

      <?rfc include="reference.I-D.ietf-pce-segment-routing"?>

      <?rfc include="reference.I-D.ietf-sfc-nsh"?>

      <?rfc include="reference.I-D.ietf-bess-nsh-bgp-control-plane"?>
    </references>
  </back>
</rfc>
