<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<rfc category="info" docName="draft-boucadair-sfc-requirements-06"
     ipr="trust200902">
  <front>
    <title abbrev="SFC Requirements">Requirements for Service Function
    Chaining (SFC)</title>

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

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

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

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

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

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

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

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

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

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

    <author fullname="Yuanlong Jiang" initials="Y." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd.</organization>

      <address>
        <postal>
          <street>Bantian, Longgang district</street>

          <city>Shenzhen 518129,</city>

          <region></region>

          <code></code>

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

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

    <author fullname="Ron Parker" initials="R." surname="Parker">
      <organization>Affirmed Networks</organization>

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

          <city>Acton,</city>

          <region></region>

          <code>MA</code>

          <country>USA</country>
        </postal>

        <email>Ron_Parker@affirmednetworks.com</email>
      </address>
    </author>

    <author fullname="Kengo Naito" initials="K." surname="Naito">
      <organization>NTT</organization>

      <address>
        <postal>
          <street>Midori-Cho 3-9-11</street>

          <city>Musashino-shi, Tokyo 180-8585</city>

          <region></region>

          <country>Japan</country>
        </postal>

        <email>naito.kengo@lab.ntt.co.jp</email>
      </address>
    </author>

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

    <workgroup>SFC</workgroup>

    <abstract>
      <t>This document identifies the requirements for the Service Function
      Chaining (SFC).</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document identifies the requirements for the Service Function
      Chaining (SFC).</t>

      <t>The overall problem space is described in <xref
      target="I-D.ietf-sfc-problem-statement"></xref>.<!--[[Service Function Discovery has been removed as per as comment from J. Halper. The issue can be revived in the future to have more feedback
   REQ#29:  Means to dynamically discover Service Functions SHOULD be
            supported.
]]--></t>
    </section>

    <section title="Terminology">
      <t>The reader should be familiar with the terms defined in <xref
      target="I-D.ietf-sfc-problem-statement"></xref>.</t>

      <t>The document makes use of the following terms:</t>

      <t><list style="symbols">
          <t>SFC-enabled domain: denotes a network (or a region thereof) that
          implements SFC.</t>

          <t>Service Function Loop: If a Service Function Chain is structured
          to not invoke Service Functions multiple times, a loop is the error
          that occurs when the same Service Function is invoked several times
          when handling data bound to that Service Function Chain. In other
          words, a loop denotes an error that occurs when a packet handled by
          a Service Function, forwarded onwards, and arrives once again at
          that Service Function while this is not allowed by the Service
          Function Chain it is bound to.</t>

          <t>Service Function Spiral: denotes a Service Function Chain in
          which data is handled by a Service Function, forwarded onwards, and
          arrives once again at that Service Function. <list style="symbols">
              <t>Note that some Service Functions support built-in functions
              to accommodate spirals; these service-specific functions may
              require that the data received in a spiral should differ in a
              way that will result in a different processing decision than the
              original data. This document does not make such assumption.</t>

              <t>A Service Function Chain may involve one or more Service
              Function Spirals.</t>

              <t>Unlike Service Function loop, spirals are not considered as
              errors.</t>
            </list></t>
        </list></t>
    </section>

    <section anchor="gen" title="Detailed Requirements List">
      <t>The following set of functional requirements should be considered for
      the design of the Service Function Chaining solution.</t>

      <section anchor="sf"
               title="Instantiating and Invoking Service Functions">
        <t><?rfc subcompact="no" ?><list hangIndent="11"
            style="format SF_REQ#%d:">
            <t>The solution MUST NOT make any assumption on whether Service
            Functions (SF) are deployed directly on physical hardware, as one
            or more Virtual Machines, or any combination thereof.</t>

            <t>The solution MUST NOT make any assumption on whether Service
            Functions each reside on a separate addressable Network Element,
            or as a horizontal scaling of Service Functions, or are
            co-resident in a single addressable Network Element, or any
            combination thereof. <list hangIndent="11" style="empty">
                <t>Note: Communications between Service Functions having the
                same locator are considered implementation-specific. These
                considerations are therefore out of scope of the SFC
                specification effort.</t>
              </list></t>

            <t>The solution MUST NOT require any IANA registry for Service
            Functions.</t>

            <t>The solution MUST allow multiple instances of a given Service
            Function ( i.e., instances of a Service Function can be embedded
            in or attached to multiple Network Elements). <list
                hangIndent="11" style="letters">
                <t>This is used for load-balancing, load-sharing, to minimize
                the impact of failures (e.g., by means of a hot or cold
                standby protection design), to accommodate planned maintenance
                operations, etc.</t>

                <t>How these multiple devices are involved in the service
                delivery is deployment-specific.</t>
              </list></t>

            <t>The solution MUST separate SF-specific policy
            provisioning-related aspects from the actual handling of packets
            (including forwarding decisions).</t>
          </list><?rfc subcompact="no" ?></t>
      </section>

      <section anchor="sfc" title="Chaining Service Functions">
        <t><?rfc subcompact="no" ?><list hangIndent="12"
            style="format SFC_REQ#%d:">
            <t>The solution MUST NOT assume any predefined order of Service
            Functions. In particular, the solution MUST NOT require any IANA
            registry to store typical Service Function Chains.</t>

            <t>The identification of instantiated Service Function Chains is
            local to each administrative domain; it is policy-based and
            deployment-specific.</t>

            <t>The solution MUST allow for multiple Service Chains to be
            simultaneously enforced within an administrative domain.</t>

            <t>The solution MUST allow the same Service Function to belong to
            multiple Service Function Chains.</t>

            <t>The solution MUST support the ability to deploy multiple
            SFC-enabled domains within the same administrative domain.</t>

            <t>The solution MUST be able to associate the same or distinct
            Service Function Chains for each direction (inbound/outbound) of
            the traffic pertaining to a specific service. In particular,
            unidirectional Service Function Chains, bi-directional Service
            Function Chains, or any combination thereof MUST be
            supported.<list style="empty">
                <t>Note, the solution must allow to involve distinct SFC
                Boundary Nodes for upstream and downstream. Multiple SFC
                Boundary Nodes may be deployed within an administrative
                domain.</t>
              </list></t>

            <t>The solution MUST be able to dynamically enforce Service
            Function Chains. In particular, the solution MUST allow the update
            or the withdrawal of existing Service Function Chains, the
            definition of a new Service Function Chain, the addition of new
            Service Functions without having any impact on other existing
            Service Functions or other Service Function Chains.</t>

            <t>The solution MUST provide means to control the SF-inferred
            information to be leaked outside an SFC-enabled domain. In
            particular, an administrative entity MUST be able to prevent the
            exposure of the Service Function Chaining logic and its related
            policies outside the administrative domain.</t>

            <t>The solution MUST prevent infinite Service Function Loops.<list
                hangIndent="11" style="letters">
                <t>Service Functions MAY be invoked multiple times in the same
                Service Function Chain (denoted as SF Spiral), but the
                solution MUST prevent infinite forwarding loops.</t>
              </list></t>
          </list><?rfc subcompact="no" ?></t>
      </section>

      <section anchor="mtu" title="MTU Requirements">
        <t>Packet fragmentation can be very expensive in SFC environment where
        fragmented packets have to be reassembled before sending to each SF on
        the chain. It is also worth noting that IPv6 traffic can only be
        fragmented by the end systems.</t>

        <t><?rfc subcompact="no" ?><list hangIndent="12"
            style="format MTU_REQ#%d:">
            <t>The solution SHOULD minimize fragmentation; in particular, a
            minimal set of SFC-specific information should be conveyed in the
            data packet.</t>

            <t>Traffic forwarding on a SFC basis MUST be undertaken without
            relying on dedicated resources to treat fragments. In particular,
            Out of order fragments MUST be forwarded on a per-SFC basis
            without relying on any state.</t>

            <t>Some SFs (e.g., NAT) may require dedicated resources (e.g.,
            resources to store fragmented packets) or they may adopt a
            specific behavior (e.g, limit the time interval to accept
            fragments). The solution MUST NOT interfere with such
            practices.</t>
          </list><?rfc subcompact="no" ?></t>
      </section>

      <section anchor="un"
               title="Independence from the Underlying Transport Infrastructure Requirements">
        <t><?rfc subcompact="no" ?><list hangIndent="11"
            style="format UN_REQ#%d:">
            <t>The solution MUST NOT make any assumption on how RIBs (Routing
            Information Bases) and FIBs (Forwarding Information Bases) are
            populated. Particularly, the solution does not make any assumption
            on protocols and mechanisms used to build these tables.</t>

            <t>The solution MUST be transport independent.<list
                hangIndent="11" style="letters">
                <t>The Service Function Chaining should operate regardless of
                the network transport used by the administrative entity. In
                particular, the solution can be used whatever the switching
                technologies deployed in the underlying transport
                infrastructure.</t>

                <t>Techniques such as MPLS are neither required nor
                excluded.</t>
              </list></t>

            <t>The solution MUST allow for chaining logics where involved
            Service Functions are not within the same layer 3 subnet.</t>

            <t>The solution MUST NOT exclude Service Functions to be within
            the same IP subnet (because this is deployment-specific).</t>
          </list><?rfc subcompact="no" ?></t>
      </section>

      <section anchor="class" title="Traffic Classification Requirements">
        <t><?rfc subcompact="no" ?><list hangIndent="11"
            style="format TC_REQ#%d:">
            <t>The solution MUST NOT make any assumption on how the traffic is
            to be bound to a given chaining policy. In other words,
            classification rules are deployment-specific and policy-based. For
            instance, classification can rely on a subset of the information
            carried in a received packet such as 5-tuple classification, be
            subscriber-aware, be driven by traffic engineering considerations,
            or any combination thereof. <list style="empty">
                <t>Because a large number (e.g., 1000s) of classification
                policy entries may be configured, means .Means to reduce
                classification look-up time such as optimizing the size of the
                classification table (e.g., aggregation) should be supported
                by the Classifier.</t>
              </list></t>

            <t>The solution MUST NOT require every Service Function to be
            co-located with a SFC Classifier; this is a deployment-specific
            decision.</t>

            <t>The solution MAY allow traffic re-classification at the level
            of Service Functions (i.e., a Service Function can also be
            co-located with a Classifier). The configuration of classification
            rules in such context are the responsibility of the administrative
            entity that operates the SFC-enabled domain.</t>

            <t>The solution MUST allow Service Function Nodes to be configured
            (or pushed) with the detailed policies on which local Service
            Functions to invoke for packets associated with some Service
            Function Chains. The solution MUST allow those steering policies
            to be updated based on demand.</t>
          </list><?rfc subcompact="no" ?></t>
      </section>

      <section anchor="dp" title="Data Plane Requirements">
        <t><?rfc subcompact="no" ?><list hangIndent="11"
            style="format DP_REQ#%d:">
            <t>The solution MUST be able to forward traffic between two
            Service Functions (involved in the same Service Function Chain)
            without relying upon the destination address field of the a data
            packet.</t>

            <t>The solution MUST allow for the association of a context with
            the data packets. In particular:<list hangIndent="11"
                style="letters">
                <t>The solution MUST support the ability to invoke
                differentiated sets of policies for a Service Function (such
                sets of policies are called Profiles). A profile denotes a set
                of policies configured to a local Service Function (e.g.,
                content-filter-child, content-filter-adult).<list
                    hangIndent="11" style="letters">
                    <t>Few profiles should be assumed per Service Function to
                    accommodate the need for scalable solutions.</t>

                    <t>A finer granularity of profiles may be configured
                    directly to each Service Function; there is indeed no need
                    to overload the design of Service Function Chains with
                    policies of low-level granularity.</t>
                  </list></t>
              </list></t>

            <t>Service Functions may be reachable using IPv4 and/or IPv6. The
            administrative domain entity MUST be able to define and enforce
            policies with regards to the address family to be used when
            invoking a Service Function. <list hangIndent="11" style="letters">
                <t>A Service Function Chain may be composed of IPv4 addresses,
                IPv6 addresses, or a mix of both IPv4 and IPv6 addresses.</t>

                <t>Multiple Service Functions can be reachable using the same
                IP address. Each of these Service Functions is unambiguously
                identified with a Service Function Identifier.</t>
              </list></t>

            <t></t>
          </list><?rfc subcompact="no" ?></t>
      </section>

      <section anchor="oam" title="OAM Requirements">
        <t><?rfc subcompact="no" ?><list hangIndent="12"
            style="format OAM_REQ#%d:">
            <t>The solution MUST allow for Operations, Administration, and
            Maintenance (OAM) features <xref target="RFC6291"></xref>. In
            particular, the solution MUST:<list hangIndent="11"
                style="letters">
                <t>Support means to verify the completion of the forwarding
                actions until the SFC Border Node is reached (see Section
                3.4.1 of <xref target="RFC5706"></xref>).</t>

                <t>Support means to ensure coherent classification rules are
                installed in and enforced by all the Classifiers of the SFC
                domain.</t>

                <t>Support means to correlate classification policies with
                observed forwarding actions.</t>

                <t>Support in-band liveliness and functionality checking
                mechanisms for the instantiated Service Function Chains and
                the Service Functions that belong to these chains.</t>
              </list></t>

            <t>The solution MUST support means to detect the liveliness of
            Service Functions of an SFC-enabled domain. In particular, the
            solution MUST support means to (dynamically) detect that a Service
            Function instance is out of service and notify the relevant
            elements accordingly (PDP and Classifiers, for one).</t>

            <t>Detailed diagnosis requirements are listed below:<list
                hangIndent="11" style="letters">
                <t>The solution MUST allow to assess the status of the
                serviceability of a Service Function (i.e., the Service
                Function provides the service(s) it is configured for).</t>

                <t>The solution MUST NOT rely only on IP reachability to
                assess whether a Service Function is up and running.</t>

                <t>The solution MUST allow to diagnose the availability of a
                Service Function Chain (including the availability of a
                particular Service Function Path bound to a given Service
                Function Chain).</t>

                <t>The solution MUST allow to retrieve the set of Service
                Function Chains that are enabled within a domain.</t>

                <t>The solution MUST allow to retrieve the set of s Service
                Function Chains in which a given Service Function is
                involved.</t>

                <t>The solution MUST allow to assess whether an SFC-enabled
                domain is appropriately configured (including the configured
                chains are matching what should be configured in that
                domain).</t>

                <t>The solution MUST allow to assess the output of the
                classification rule applied on a packet presented to a
                Classifier of an SFC-enabled domain.</t>

                <t>The solution MUST support the correlation between a Service
                Function Chain and the actual forwarding path followed by a
                packet matching that SFC.</t>

                <t>The solution MUST allow to diagnose the availability of a
                segment of a Service Function Chain, i.e., a subset of Service
                Functions that belong to the said chain.</t>

                <t>The solution MUST support means to notify the PDPs whenever
                some events occur (for example, a malfunctioning Service
                Function instance).</t>

                <t>The solution MUST allow for local diagnostic procedures
                specific to each Service Function (i.e., SF built-in
                diagnostic procedures).</t>

                <t>The solution MUST allow for customized service
                diagnostic.</t>
              </list></t>

            <t>Liveness status records for all Service Functions (including
            Service Function instances), Service Function Nodes, Service
            Function Chains (including the Service Function Paths bound to a
            given chain) MUST be maintained.</t>

            <t>SFC-specific counters and statistics MUST be provided. These
            data include (but not limited to): <list style="symbols">
                <t>Number of flows ever and currently assigned to a given
                Service Function Chain and a given Service Function Path.</t>

                <t>Number of flows, packets, bytes dropped due to policy.</t>

                <t>Number of packets and bytes in/out per Service Function
                Chain and per Service Function Path.</t>

                <t>Number of flows, packets, bytes dropped due to unknown
                Service Function Chain or Service Function Path (this is valid
                in particular for a Service Function Node).</t>
              </list></t>
          </list><?rfc subcompact="no" ?></t>
      </section>

      <section anchor="lb" title="Recovery and Load Balancing Requirements ">
        <t><?rfc subcompact="no" ?><list hangIndent="11"
            style="format LB_REQ#%d:">
            <t>The solution MUST allow for load-balancing among multiple
            instances of the same Service Function.<list hangIndent="11"
                style="letters">
                <t>Load-balancing may be provided by legacy technologies or
                protocols (e.g., make use of load-balancers)</t>

                <t>Load-balancing may be part of the Service Function
                itself.</t>

                <t>Load-balancer may be considered as a Service Function
                element.</t>

                <t>Because of the possible complications, load balancing
                SHOULD NOT be driven by the SFC Classifier.</t>
              </list></t>

            <t>The solution MUST separate SF-specific policy
            provisioning-related aspects from the actual handling of packets
            (including forwarding decisions).</t>

            <t>The solution SHOULD support protection of the failed or
            over-utilized Service Function instances. The protection mechanism
            can rely on local decisions among the nodes that are connected to
            both active/standby Service Function instances.</t>
          </list><?rfc subcompact="no" ?></t>
      </section>

      <section anchor="bw"
               title="Compatibility with Legacy Service Functions  Requirements">
        <t><?rfc subcompact="no" ?><list hangIndent="12"
            style="format LEG_REQ#%d:">
            <t>The solution MUST allow for gradual deployment in legacy
            infrastructures, and therefore coexist with legacy technologies
            that cannot support SFC-specific capabilities, such as Service
            Function Chain interpretation and processing. The solution MUST be
            able to work in a domain that may be partly composed of opaque
            elements, i.e., elements that do not support SFC-specific
            capabilities.</t>
          </list><?rfc subcompact="no" ?></t>
      </section>

      <section anchor="qos" title="QoS Requirements ">
        <t><?rfc subcompact="no" ?><list hangIndent="12"
            style="format QoS_REQ#%d:">
            <t>The solution MUST be able to provide different SLAs (Service
            Level Agreements, <xref target="RFC7297"></xref>). In
            particular,<list style="letters">
                <t>The solution MUST allow for different levels of service to
                be provided for different traffic streams (e.g., configure
                Classes of Service (CoSes)).</t>

                <t>The solution MUST be able to work properly within a
                Diffserv domain <xref target="RFC2475"></xref>.</t>

                <t>The solution SHOULD support the two modes defined in <xref
                target="RFC2983"></xref>.</t>
              </list></t>

            <t>ECN re-marking, when required, MUST be performed according to
            <xref target="RFC6040"></xref>.</t>
          </list><?rfc subcompact="no" ?></t>
      </section>

      <section anchor="sec" title="Security Requirements">
        <t><?rfc subcompact="yes" ?><list hangIndent="12"
            style="format SEC_REQ#%d:">
            <t>The solution MUST provide means to prevent any information
            leaking that would be used as a hint to guess internal engineering
            practices (e.g., network topology, service infrastructure
            topology, hints on the enabled mechanisms to protect internal
            service infrastructures, etc.).<list style="empty">
                <t>The solution MUST support means to protect the SFC domain
                as a whole against attacks that would lead to the discovery of
                Service Functions enabled in a SFC domain.</t>

                <t>In particular, topology hiding means MUST be supported to
                avoid the exposure of the SFC-enabled domain topology
                (including the set of the service function chains supported
                within the domain and the corresponding Service Functions that
                belong to these chains).</t>
              </list></t>

            <t>The solution MUST support means to protect the SFC-enabled
            domain against any kind of denial-of-service and theft of service
            (e.g., illegitimate access to the service) attack. <list
                style="empty">
                <t>For example, a user should not be granted access to
                connectivity services he/she didn't subscribe to (including
                direct access to some SFs), at the risk of providing
                illegitimate access to network resources.</t>
              </list></t>

            <t>The solution MUST NOT interfere with IPsec <xref
            target="RFC4301"></xref> (in particular IPsec integrity
            checks).<?rfc subcompact="no" ?></t>
          </list></t>
      </section>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Some security-related requirements to be taken into account when
      designing the Service Function Chaining solution are listed in <xref
      target="sec"></xref>. These requirements do not cover the provisioning
      interface used to enforce policies into the Classifier, Service
      Functions, and Service Function Nodes.</t>
    </section>

    <section title="Contributors">
      <t>The following individuals contributed text to the document:<figure>
          <artwork><![CDATA[   Hongyu Li
   Huawei Technologies Co., Ltd.
   Bantian, Longgang district
   Shenzhen 518129,
   China

   EMail: hongyu.lihongyu@huawei.com

   Jim Guichard
   Cisco Systems, Inc.
   USA

   EMail: jguichar@cisco.com

   Paul Quinn
   Cisco Systems, Inc.
   USA

   Email: paulq@cisco.com


   Linda Dunbar
   Huawei Technologies
   5430 Legacy Drive, Suite #175
   Plano  TX
   USA

   EMail: linda.dunbar@huawei.com]]></artwork>
        </figure></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Many thanks to K. Gray, N. Takaya, H. Kitada, H. Kojima, D. Dolson,
      B. Wright, and J. Halpern for their comments.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

      <reference anchor="RFC7297">
        <front>
          <title>IP Connectivity Provisioning Profile (CPP)</title>

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

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

                <city>Rennes</city>

                <region></region>

                <code>35000</code>

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

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

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

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

                <city>Rennes</city>

                <region></region>

                <code>35000</code>

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

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

          <author fullname="Ning Wang" initials="N." surname="Wang">
            <organization>University of Surrey</organization>

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

                <city>Guildford</city>

                <region></region>

                <code></code>

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

              <email>n.wang@surrey.ac.uk</email>
            </address>
          </author>

          <date month="July" year="2014" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
