One document matched: draft-boucadair-chaining-requirements-01.xml

<?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-chaining-requirements-01"
     ipr="trust200902">
  <front>
    <title abbrev="SFC Requirements">Requirements for Service Function
    Chaining</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="Hongyu Li" initials="H." surname="Li">
      <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>

        <phone></phone>

        <email>hongyu.lihongyu@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>

    <date day="22" month="August" year="2013" />

    <abstract>
      <t>This document identifies the requirements for the Service Function
      Chaining.</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.quinn-nsc-problem-statement"></xref>. The Service Chaining
      Framework is documented in <xref
      target="I-D.boucadair-network-function-chaining"></xref>.</t>
    </section>

    <section title="Terminology">
      <t>The reader should be familiar with the terms defined in <xref
      target="I-D.boucadair-network-function-chaining"></xref>.</t>
    </section>

    <section title="Detailed Requirements List">
      <t>The following set of functional requirements should be considered for
      the design of the Service Function Chaining solution:<?rfc subcompact="no" ?><list
          hangIndent="9" style="format 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, are
          co-resident on a single addressable Network Element, or any
          combination thereof.</t>

          <t>The solution MUST NOT require any IANA registry to store the list
          of Service Functions.</t>

          <t>The solution MUST NOT assume predefined chains of particular
          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 a Service Function to be embedded in
          multiple devices (e.g., servers).<list hangIndent="11"
              style="letters">
              <t>This is used for load-balancing, load-sharing, prevent from
              failures (e.g., hot or cold standby protection mechanism),
              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 allow for multiple Service Chains to be
          simultaneously enforced within an administrative domain.</t>

          <t>The solution MUST allow the same Service Function be involved in
          multiple Service Function Chains.</t>

          <t>The solution MUST support multiple SFC-enabled domains be
          deployed 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. In particular, unidirectional Service Function Chains MUST
          be supported.</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 chains, the definition of a new chain, the
          addition of new Service Functions without having any impact on other
          existing Service Functions or other Service Function Chains.</t>

          <t>Service Function Chaining logic and related policies SHOULD NOT
          be exposed outside a given administrative domain.</t>

          <t>The solution SHOULD minimize fragmentation; in particular a
          minimal set of SFC-specific information should be conveyed in the
          data packet.</t>

          <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 NOT make any assumption on the underlying
          transport technologies used to interconnect involved Service
          Functions.<list hangIndent="11" style="letters">
              <t>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 (this is deployment-specific). An administrative
          entity, grouping its Service Functions within the same IP subnet,
          SHOULD be able to get rid of any overhead (e.g., encapsulation).</t>

          <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.<list
              style="letters">
              <t>Service Function Chaining does not require new classification
              capabilities compared to current practices.</t>

              <t>For instance, classification can rely on a subset of the
              information carried in a received packet such as 5-tuple
              classification.</t>
            </list></t>

          <t>The solution MUST support classifying traffic into Service
          Function Chains. <list style="letters">
              <t>Preferably, a single classification of packets upon their
              entry in the SFC domain SHOULD be supported, as this will save
              computation resources consumed by reclassification, and avoid
              the provisioning of classification rules into multiple
              classifiers.</t>

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

          <t>A Classifier MAY be co-located with other Service Functions.</t>

          <t>A Classifier MAY be considered as a Service Function in its
          own.</t>

          <t>The solution MAY allow reclassification at the Service Functions
          (i.e., a Service Function can also be co-located with a classifier).
          <list hangIndent="11" style="letters">
              <t>Given the risk to jeopardize the overall consistency of the
              Differentiated Forwarding policy enforced for a specific traffic
              flow or a set thereof, the administrative entity must configure
              coherent classification rules.</t>

              <t>The configuration of classification rules in such context are
              the responsibility of the administrative entity managing that
              SFC-enabled domain.</t>
            </list></t>

          <t>The solution MUST be able to forward the traffic between two
          Service Functions (involved the same Service Function Chain) without
          relying on the Destination Address.</t>

          <t>The solution MUST support the ability to invoke differentiated
          sets of policies for a Service Functions (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>Finer-grained definition of policies belonging to a Service
              Function should not be driven by the chaining marking.</t>

              <t>Finer-grained of policies should be configured directly to
              each Service Function; no need to overload the design of Service
              Function chains with policies of low-level granularity.</t>
            </list></t>

          <t>The solution MUST provide means to ensure the overall consistency
          of the procedure. For example:<list hangIndent="11" style="letters">
              <t>Ensure the completion of the forwarding actions derived from
              the contents of the SFC Map until the border node is
              reached.</t>

              <t>Coherent classification rules are installed to all
              classifiers.</t>

              <t>The correlation between the classification policies and
              forwarding actions should be verified.</t>
            </list></t>

          <t>The solution MUST prevent the same Service Function to be invoked
          multiple times in the context of the same Service Function Chain (at
          the risk of generating Service Function Loop).</t>

          <t>The solution MUST allow for load-balancing:<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 handled at the classifier. This logic should be embedded
              in the entity which is responsible for ensuring the overall
              consistency of the solution (i.e., Policy Decision Point).</t>
            </list></t>

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

          <t>The solution MUST NOT exclude means to detect the liveliness of
          involved Service Functions; nevertheless these means are not
          considered as a mandatory component of the solution.</t>

          <t>Means to dynamically discover Service Functions SHOULD be
          supported. This feature is not required for the core chaining
          functionality, but its support is of high interest for
          operators.</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.</t>
            </list></t>

          <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 SFC Map
          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>

          <t>The solution MUST be able to provide different SLAs (Service
          Level Agreements, <xref
          target="I-D.boucadair-connectivity-provisioning-profile"></xref>).
          In particular,<list style="letters">
              <t>The solution MUST allow for different levels of service to be
              provided for traffic streams (e.g., configure Classes of Service
              (CoSes)).</t>

              <t>The solution MUST be compatible with Diffserv <xref
              target="RFC2475"></xref>.</t>
            </list></t>
        </list><?rfc subcompact="no" ?></t>
    </section>

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

    <section anchor="Security" title="Security Considerations">
      <t>Below are listed some security-related requirements to be taken into
      account when designing the Service Function Chaining solution:</t>

      <t><list hangIndent="12" style="format SEC_REQ#%d:">
          <t>The solution MUST offer at least the same security protection
          level as the one provided using legacy service engineering and
          delivery practices.</t>

          <t>The solution MUST provide means to prevent leaking any
          information 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.).</t>

          <t>The solution MUST support means to defend against
          denial-of-service and theft of service (e.g., illegitimate access to
          the service). </t>

          <t>The solution MUST NOT interfere with IPsec <xref
          target="RFC4301"></xref> (in particular IPsec integrity checks).</t>

          <t>The solution MUST NOT lead to routing loops.</t>
        </list></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBC.</t>
    </section>
  </middle>

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

    <references title="Informative References">
      <?rfc include="reference.I-D.boucadair-network-function-chaining"?>

      <?rfc include='reference.I-D.boucadair-connectivity-provisioning-profile'?>

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

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

      <?rfc include="reference.I-D.quinn-nsc-problem-statement"?>
    </references>
  </back>
</rfc>