<?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 topblock="yes"?>
<rfc category="info" docName="draft-boucadair-sfc-design-analysis-03"
     ipr="trust200902">
  <front>
    <title abbrev="Design Analysis">Service Function Chaining: Design
    Considerations, Analysis &amp; Recommendations</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="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="Linda Dunbar" initials="L." surname="Dunbar">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>5430 Legacy Drive, Suite #175</street>

          <city>Plano</city>

          <region></region>

          <code>TX</code>

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

        <email>linda.dunbar@huawei.com</email>
      </address>
    </author>

    <date day="22" month="October" year="2014" />

    <workgroup>SFC</workgroup>

    <abstract>
      <t>This document aims at analyzing the various design options and
      providing a set of recommendations for the design of Service Function
      Chaining solution(s). Note:<list style="symbols">
          <t>The analysis does not claim to be exhaustive. The list includes a
          preliminary set of potential solutions; other proposals can be added
          to the analysis if required.</t>

          <t>The analysis is still ongoing. The analysis text will be updated
          to integrate received comments and inputs.</t>

          <t>Sketched recommendations are not frozen. These recommendations
          are provided as proposals to kick-off the discussion and to
          challenge them.</t>

          <t>The analysis does not cover any application-specific solution
          (e.g., HTTP header) because of the potential issues inherent to
          (TLS) encrypted traffic.</t>

          <t>The analysis will be updated to take into account the full set of
          SFC requirements.</t>
        </list></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 aims at analyzing the various design options and
      providing a set of recommendations for the design of Service Function
      Chaining solution(s). The conclusions of this analysis, once stable,
      will be recorded in the framework document.</t>

      <t>The overall problem space is described in <xref
      target="I-D.ietf-sfc-problem-statement"></xref>. A list of requirements
      is available at <xref
      target="I-D.boucadair-sfc-requirements"></xref>.</t>
    </section>

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

    <section title="Scope">
      <t>This document identifies potential solutions to fulfill the design
      requirements documented in <xref
      target="I-D.boucadair-sfc-requirements"></xref>. Particularly, it
      focuses on the following design objectives:<list style="numbers">
          <t>Which information to include in the SFC header? (see <xref
          target="content"></xref>)</t>

          <t>How to mark packets to indicate they belong to a given Service
          Function Chain (SFC) (see <xref target="format"></xref>) and in
          which channel the SFC header is to be conveyed (see <xref
          target="where"></xref>)?</t>

          <t>How to select a differentiated set of policies at a given Service
          Function (SF)? (see <xref target="format"></xref>)</t>

          <t>How to select the forwarding path of a given flow that needs to
          be processed according to a set of Service Functions which must be
          invoked in a given order? (see <xref target="steer"></xref>)</t>
        </list></t>

      <t>Other design issues will be documented in future versions if
      required.</t>
    </section>

    <section anchor="content" title="Service Function Chaining Header">
      <t>This section identifies the main design points to be agreed upon so
      as to guide the forthcoming specification effort of the Service Function
      Chaining Header.</t>

      <section title="Why a Subscriber Identifier Does Not Need to be part of the Header?">
        <t>Current deployment practices rely on per-subscriber policies
        enforcement on few service nodes (especially in the access network
        segment). If the same design approach is preserved when SFC is in use,
        per-subscriber policies are likely to not be supported by all involved
        (SF) nodes.</t>

        <t>Conveying the SF Map Index, that is an unique value to represent
        different service chains, is sufficient to guide specific sequence of
        Service Functions for a given packet that belongs to a flow. Some of
        involved Service Functions may enforce a per-subscriber policy. The
        enforcement of such policies can be driven by a subset of the
        information contained in the packets (e.g., source IP address, IPv6
        prefix, etc.).</t>

        <t>In some deployment contexts implying a correlation between the
        assigned IP address and a subscriber identifier, complications may
        arise in the following cases:<list style="symbols">
            <t>Overlapping IP address pools are in use. In such context,
            multiple subscribers will be allocated the same internal IP
            address: an extra identifier is needed to distinguish the traffic
            belonging to each of these subscribers or enable multi instances
            of the same service nodes (i.e., subscribers assigned with the
            same internal IP address will be serviced by distinct service
            nodes).</t>

            <t>NAT function is not collocated with the GGSN or BNG. The NAT
            function will need an extra identifier to distinguish packets
            belonging to a given subscriber.</t>
          </list></t>

        <t>Enforcing for instance per-subscriber port quota requires an
        additional information to uniquely disambiguate hosts having the same
        address (called HOST_ID, <xref target="RFC6967"></xref>). This problem
        is not specific to the Service Function Chaining, but it is
        encountered in many other use cases (<xref
        target="I-D.boucadair-intarea-host-identifier-scenarios"></xref>).</t>

        <t>Within the context of SFC, two solutions can be adopted:<list
            style="numbers">
            <t>Implement a solution similar to what is specified in <xref
            target="RFC6674"></xref>. This means that the subscriber-ID is
            passed only to the node that enforces the per-subscriber policies
            without leaking it to other downstream SFs. In such case, the node
            that inserts the subscriber-ID is not part of the SFC-enabled
            domain. This solution does not require the insertion of the
            subscriber-ID in the SFC header.</t>

            <t>Define a subscriber-ID optional field in the SFC header. This
            optional field can be defined as an optional 64-bit field to
            accommodate the mobile case (e.g., inject an IMSI (International
            Mobile Subscriber Identity) identifier as a subscriber-ID).</t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| It is NOT RECOMMENDED to encode a subscriber-ID                   |
| as a mandatory field of the SFC header.                           |
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section title="Fixed vs. Variable Length of the SFC Map Index">
        <t>The number of Service Chains to be instantiated is
        deployment-specific. It depends on the business context and
        engineering practices that are internal to each administrative entity.
        To ensure a better flexibility as a function of the service chains
        that are theoretically supported, a first design consideration is to
        decide whether there is a need for a fixed field or a variable length
        field.</t>

        <t>A field with a variable length is flexible enough to accommodate as
        many Service Function Chains as required for each deployment context.
        An administrative entity will need to tweak the length of this field
        to meet its own deployment requirements (e.g., set the length in all
        involved nodes to 8 bits, 16 bits, 32 bits or even more).</t>

        <t>A field with a fixed length would lead to a better performance
        (mainly because of a simplified processing).</t>
      </section>

      <section anchor="len" title="Recommended Length">
        <t>An 8-bit field would be sufficient to accommodate deployment
        contexts that assume a reasonable set of SF Maps. A 16-bit field would
        be more flexible and would allow to enable large service chains (e.g.,
        to accommodate the requirement discussed in <xref
        target="I-D.boucadair-sfc-requirements"></xref>). A 32-bit field would
        fulfill the needs for deployments with very large Service Function
        Chains.</t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| It is RECOMMENDED to use a 32-bit field to encode                 |
| the SF Map Index                                                  |
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section title="Extensibility">
        <t>The header can be extended in the future, based on the experience
        that will be gained during operational deployments. As such, the
        header does not need to include any protocol version field nor any
        reserved bits to disambiguate between two variants of the header.</t>

        <t>Implementations supporting the service chaining solution can be
        upgraded following current best practices in the field.</t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| It is NOT RECOMMENDED to reserve bits to anticipate future        |
| extension needs. Backward compatibility between two versions of   |
| the header can be ensured by consistent system                    |
| setup & configuration.                                            |
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>
    </section>

    <section anchor="format"
             title="Format of the Service Function Chaining Header">
      <t>This section proposes and discusses some formats to encode the
      Service Chaining Header. An analysis is also included in this section.
      <list style="empty">
          <t>[NOTE: Other proposals may be added to this section.]</t>
        </list></t>

      <section anchor="format1" title="Format 1: Single Marking Code Point">
        <t>The RBNF format <xref target="RFC5511"></xref> of the header is
        shown in <xref target="f1"></xref>:</t>

        <t><figure align="center" anchor="f1"
            title="Single Marking Code Point">
            <artwork><![CDATA[<SFC Header> ::=  <SF Map Index>]]></artwork>
          </figure></t>

        <t>This format is characterized as follows:<list style="symbols">
            <t>The necessary information on how to steer data packets
            associated with the SF Map Index has to be provisioned to each SF
            Node either by in-band messages or out-of-band messages. For a SF
            Node that contains multiple service functions, the detailed list
            and the specific sequence of Service Functions associated with the
            SF Map Index have to be provisioned to the SF node. If the SF node
            is connected to multiple SF nodes, the next hop SF node for the
            packets associated with SF Map Index has to be provisioned. This
            provisioning can be implemented using a SFC policy table. This SFC
            policy table includes the locator(s) of the possible SF next hop
            and the SF Map Index list to help detect any Service Function
            Loop.</t>

            <t>Classifiers are provisioned with classification rules to decide
            which code point to use for a received packet.</t>

            <t>Fragmentation risk is minimized because the header is
            compacted.</t>

            <t>Multiple profiles can be supported per SF Node; each profile is
            identified with a Service Function Identifier.</t>

            <t>The classifier behavior is simplified.</t>

            <t>Separating the policies channel from the marking behavior
            prevents potential DDoS (e.g., common to any source routing
            scheme.)</t>

            <t>The lookup in the SFC Policy Table is not a concern because it
            is not expected to provision SFC Policy Tables with an amount of
            information (e.g., like the size of the global routing table).</t>
          </list></t>
      </section>

      <section title="Format 2: Marking Code Point &amp; Profile Index">
        <t>The RBNF format of the header is shown in <xref
        target="f2"></xref>:</t>

        <t><figure align="center" anchor="f2"
            title="Marking Code Point &amp; Profile Index">
            <artwork><![CDATA[<SFC Header> ::=  <SF Map Index>
                  <Service Function Map>

<Service Function Map> ::= <Service Function> ...

<Service Function> ::=  <Service Function Identifier>
                        <Profile Identifier>]]></artwork>
          </figure>This format is characterized as follows:<list
            style="symbols">
            <t>The list of SF Locator(s) is provisioned out of band to each SF
            Node.</t>

            <t>Classifiers are provisioned with classification rules to decide
            which code point is to be used for a received packet.</t>

            <t>Fragmentation risks are not minimized.</t>

            <t>The classifier needs to be configured with a list of
            profiles/contexts per Service Function.</t>

            <t>The classifier behavior is not simplified since it must also
            encode in each incoming packet the full list of functions to be
            performed by each Service Function hop.</t>
          </list></t>
      </section>

      <section title="Format 3: Explicit Route List">
        <t>The RBNF format of the header is shown in <xref
        target="f3"></xref>:</t>

        <t><figure anchor="f3" title="Explicit Route List">
            <artwork><![CDATA[<SFC Header> ::=  <Total number of Service Function hops>
                  <Current hop Index>
                  <Service Function Map>

<Service Function Map> ::= <Service Function> ...

<Service Function> ::=  <IP ADDRESS>
                        <Profile Identifier>]]></artwork>
          </figure></t>

        <t>The procedure at a non-reclassifying node is to validate that the
        IP address of the SF at the current index matches one of the SF's own
        IP addresses and then to find the profile identifier by its indicated
        identifier. Once the local Service Function is invoked, if the packet
        needs to be forwarded to the next Service Function hop, the local node
        simply increments the current hop index and rewrites the outer IP
        header with the next hop's IP address.</t>

        <t>This format is characterized as follows:<list style="symbols">
            <t>Classifiers are provisioned with classification rules to decide
            which code point is to be used for a received packet.</t>

            <t>Fragmentation risks are not minimized.</t>

            <t>The classifier needs to be configured with a list of
            profiles/contexts per Service Function.</t>

            <t>The classifier is also responsible for load balancing. This
            makes the classifier more complex.</t>

            <t>The classifier behavior is not simplified since it must also
            encode in each incoming packet the full list of policies to be
            performed by each Service Function node.</t>
          </list></t>
      </section>

      <section title="Format 4: Compact Explicit Route List">
        <t>A variant of the previous format is depicted in the RBNF format of
        the header shown in <xref target="f4"></xref>. Instead of including
        the explicit route list (<xref target="f3"></xref>), IP addresses of
        SFs are configured out of band but each of these addresses is
        identified with a unique identifier. These identifiers are indicated
        in the Service Chaining Header. <figure align="center" anchor="f4"
            title="Compact Explicit Route List">
            <artwork><![CDATA[<SFC Header> ::=  <Total number of Service Function hops>
                  <Current hop Index>
                  <Service Function List>

<Service Function List> ::= <Service Function> ...

<Service Function> ::=  <IP Address ID>
                        <Profile Identifier>]]></artwork>
          </figure></t>

        <t>This proposal suffers from the same drawbacks as the previous
        format.</t>
      </section>

      <section title="Analysis">
        <t>Given the design motto that says: <list style="empty">
            <t>"A protocol design is complete not when you can't think of any
            more things to add, but when you have removed everything you can
            and you can&rsquo;t see how to remove any more",</t>
          </list></t>

        <t>the proposed format must be as simple as possible while meeting the
        requirements discussed in <xref
        target="I-D.boucadair-sfc-requirements"></xref>. The simplicity
        argument is further discussed in <xref target="RFC3439"></xref> and
        <xref target="Robust"></xref>.</t>

        <t>Based on the above analysis, the proposal that is simple, minimizes
        fragmentation, optimizes the behavior of the classifier and SF Nodes,
        and that prevents potential DDoS attacks is the one discussed in <xref
        target="format1"></xref>.</t>
      </section>
    </section>

    <section anchor="where"
             title="Where To Convey the Chaining Marking Information In A Packet?">
      <t>This section lists a set of candidate solutions to convey the Service
      Chaining Header.</t>

      <section title="Use IPv6 Flow Label">
        <t>The use of the 20-bit Flow Label field in the IPv6 header <xref
        target="RFC6437"></xref> can be considered as a candidate solution to
        convey the SF Map Index.</t>

        <t>The following comments can be made for this candidate
        solution:<?rfc subcompact="yes" ?><list style="symbols">
            <t>This proposal requires all packets are transported over IPv6.
            This should not be considered as a limitation for some
            deployments.</t>

            <t>Intermediate Nodes must not alter the content of the Flow Label
            field.</t>

            <t>This proposal can apply to any transport protocol.</t>

            <t>The use of the IPv6 Flow Label may interfere with other usages
            of the flow label such as Equal Cost Multipath (ECMP) or Link
            Aggregation (LAG) <xref target="RFC6438"></xref>. The Flow Label
            bits need to be combined at least with bits from other sources
            within the packet, so as to produce a constant hash value for each
            flow and a suitable distribution of hash values across flows <xref
            target="RFC6437"></xref>.</t>

            <t>A 20-bit field to convey the SF Map Index allows to enable
            Service Function Chains of a large size range.</t>

            <t>This proposal does not allow to convey additional information
            than the SF Map Index (if needed).</t>

            <t>The Flow Label is present in all fragments, SF Nodes do not
            need to maintain any state to handle a fragmented packet.</t>

            <t>Altering the value of the Flow Label field does not interfere
            with the use of IPsec <xref target="RFC6438"></xref>.</t>

            <t>Carrying the SF Map Index in the IPv6 Flow Label allows
            to:<list style="symbols">
                <t>De-correlate packet marking from forwarding
                constraints.</t>

                <t>Avoid requiring an internal tagging mechanism to each SF
                Node to preserve the same marking in the outgoing interface as
                the one received in an incoming interface.<?rfc subcompact="no" ?></t>
              </list></t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| It is tempting to use the Flow Label, but the 20-bit length of    |
| the Flow Label field is conflicting with the recommended 32-bit   |
| length discussed in Section 4.3.                                  |
|                                                                   |
| The use of Flow Label is NOT RECOMMENDED.                         |
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section title="Use the DS Field">
        <t>Another alternative to convey the SF Map Index is to use the
        Differentiated Services (DS) field <xref target="RFC2474"></xref>
        <xref target="RFC2475"></xref> (for both IPv4 and IPv6).</t>

        <t>The following comments can be made for this proposal:<?rfc subcompact="yes" ?><list
            style="symbols">
            <t>This proposal overloads the semantics of the DS field.</t>

            <t>Having 64 possible values may not accommodate deployments with
            a large number of service chains (see <xref
            target="len"></xref>).</t>

            <t>This proposal can apply to any transport protocol.</t>

            <t>The use of the DS field for service chaining purposes may
            interfere with other usages such as Traffic Engineering (TE) or
            Quality of Service (QoS).<list style="symbols">
                <t>This issue can be mitigated by fragmenting the DS space
                into to distinct set of values; each set dedicated for a
                specific usage. An administrative entity can use the first
                bits for service chaining and other remaining bits for QoS for
                instance.</t>

                <t>Splitting the DS space reduces the number of possible
                service chains to be configured per administrative
                domain.<?rfc subcompact="no" ?></t>
              </list></t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| The use of DS field is NOT RECOMMENDED.                           |
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section title="Use IP Identification Field">
        <t>The IPv4 ID (Identification field of IP header, i.e., IP-ID) can be
        used to insert the SF Map Index. The classifier rewrites the IP-ID
        field to insert the SF Map Index (16 bits). The classifier must follow
        the rules defined in <xref target="RFC6864"></xref>; in particular,
        the same SF Map Index is not reassigned during a given time interval.
        Note:<?rfc subcompact="yes" ?><list style="symbols">
            <t>This usage is not consistent with the fragment reassembly use
            of the Identification field <xref target="RFC0791"></xref> or the
            updated handling rules for the Identification field <xref
            target="RFC6864"></xref>.</t>

            <t>Complications may arise if the packet is fragmented before
            reaching the Classifier. To appropriately handle those packet
            fragments, the classifier will need to maintain a lot of
            state.</t>

            <t>Preserving the same value when crossing all intermediate SFs
            may be difficult (e.g., an invoked SF can be a NAT).</t>

            <t>This proposal assumes packets are transported over IPv4 (plain
            or encapsulated mode). This may not be considered as a limitation
            for some deployments.<?rfc subcompact="no" ?></t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| Using the IP-ID as a channel to convey the SF Map Index is NOT    |
| RECOMMENDED.                                                      |
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section title="Use IPv4 SSRR/LSRR Option">
        <t>Another candidate channel to convey the Service Chaining Header is
        to use the IPv4 SSRR/LSRR options <xref target="RFC0791"></xref>.
        These options can be inserted by the classifier following the
        pre-configured classification rules. Note:<?rfc subcompact="yes" ?><list
            style="symbols">
            <t>Some general recommendations documented in <xref
            target="RFC7126"></xref> and <xref target="RFC6192"></xref> need
            to be taken into account.</t>

            <t>This proposal assumes packets are transported over IPv4 (plain
            or encapsulated mode). This may not be considered as a limitation
            for some deployments.</t>

            <t>This proposal can apply to any transport protocol.</t>

            <t>Encoding the full list of intermediate SF Nodes will exacerbate
            fragmentation issues.</t>

            <t>Injecting an additional IP option by the classifier introduces
            some implementation complexity in the following cases: The packet
            has the MTU size (or is close to it), and the option space is
            exhausted.</t>

            <t>Legacy nodes must be configured to not strip this option.</t>

            <t>Processing the IP option may degrade the performance of
            involved SF nodes.<?rfc subcompact="no" ?></t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| Using the IPv4 SSRR/LSRR options as a channel to convey           |
| the Service Chaining Header is NOT RECOMMENDED.                   |
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section anchor="option"
               title="Define a new IPv4 Option and IPv6 Extension Header">
        <t>Another candidate solution to convey the Service Chaining Header is
        to define a new IPv4 option <xref target="RFC0791"></xref> and a new
        IPv6 extension header <xref target="RFC6564"></xref>. The IPv4
        option/IPv6 extension header can be inserted by the classifier
        following the pre-configured classification rules. Note:<?rfc subcompact="yes" ?><list
            style="symbols">
            <t>This proposal is valid for any transport protocol.</t>

            <t>This proposal offers the same functionality in both IPv4 and
            IPv6.</t>

            <t>Some general recommendations documented at <xref
            target="RFC7126"></xref>, <xref target="RFC6192"></xref>, and
            <xref target="RFC7045"></xref> are to be taken into account.
            Nevertheless, these security threats do not apply for this usage
            since the Ingress Node is the entity that is responsible for
            injecting the new option. Therefore, malicious usage of this
            option is unlikely.</t>

            <t>Injecting an additional IP option by the classifier introduces
            some implementation complexity in the following cases: The packet
            is at or close to the MTU size, and the option space is
            exhausted.</t>

            <t>The option can be designed to be compact and therefore avoid
            inducing fragmentation.</t>

            <t>Despite it is widely known that routers and middleboxes filter
            IP options (e.g., drop IP packets with unknown IP options, strip
            unknown IP options, etc.), this concern does not apply for the
            Service Function Chaining case because the support of new IP
            options can be enabled within a domain operated by the same
            administrative domain.</t>

            <t>Intermediary Nodes must not strip this IPv4 option/IPv6
            extension header.</t>

            <t>The use of an IPv4 option or IPv6 Extension Header to drive the
            processing of an incoming packet may alter the performance of SF
            Nodes.<list style="symbols">
                <t>Some vendors claim the use of Extension Headers (other than
                Hop-by-Hop) does not impact the overall performance of their
                IPv6 implementation (e.g., <xref target="Report"></xref>).</t>

                <t>Some studies revealed an increase of the single-hop delay
                when IP options are included (e.g., <xref
                target="Delay"></xref>).</t>

                <t>The severity of the overall performance degradation is to
                be further assessed (<xref target="RFC5180"></xref>).</t>
              </list></t>

            <t>Carrying the Service Chaining Header as an IPv4 option/IPv6
            extension header allows to:<list style="symbols">
                <t>De-correlate packet marking from forwarding
                constraints.</t>

                <t>Avoid requiring an internal tagging mechanism to each SF
                Node to preserve the same marking in the outgoing interface as
                the one received through the incoming interface.<?rfc subcompact="no" ?></t>
              </list></t>
          </list><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| Define a new IPv4 option and IPv6 extension header                |
| as an Experimental track RFC document. This approach is pragmatic,|
| assuming further experiments can be conducted to:                 |
|                                                                   |
| 1. Assess the impact on performance.                              |
|                                                                   |
| 2. Compare the impact of using the IPv4 option and the IPv6       |
|    extension header vs. an encapsulation mode (i.e., in contexts  |
|    where no encapsulation is required to reach the next SF hop).  |
|                                                                   |
| 3. Assess to what extent the use of an IPv4 option/IPv6 extension |
|    header simplify internal tagging mechanisms specific to each SF|
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section title="Define a New TCP Option">
        <t>This proposal consists in defining a new TCP option to convey the
        Service Chaining Header. The drawbacks of this proposal are listed
        below:</t>

        <t><list style="symbols">
            <t>Encapsulating every received packet in TCP SYN messages may
            impact the performance of SF nodes.</t>

            <t>Injecting a TCP option by intermediate nodes will interfere
            with end-to-end (E2E) issues. One example of such interference
            would be terminating and re-originating TCP connections not
            belonging to the transit device.</t>

            <t>Injecting this TCP option introduces some implementation
            complexity if the options space is exhausted. TCP option space is
            limited and might be consumed by the TCP client.</t>

            <t>SF Nodes may need to maintain a lot of state entries to handle
            fragments.</t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| Defining a new TCP option as a channel to convey the Service      |
| Chaining Header is NOT RECOMMENDED.                               |
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section anchor="gre" title="Use the GRE Key">
        <t><xref target="RFC2890"></xref> defines key and security extensions
        to GRE (Generic Routing Encapsulation, <xref
        target="RFC2784"></xref>). GRE Key and sequence number fields are
        optional. This section investigates how a GRE Key optional field can
        be used to convey a 32-bit SF Map Index.<?rfc subcompact="yes" ?></t>

        <t><list style="symbols">
            <t>GRE Checksum and Sequence Number fields are not required. These
            fields must not be included.</t>

            <t>Relying on GRE optional field to drive the processing of
            received packets may impact the performance of SF Nodes.</t>

            <t>This proposal does not allow to convey additional information
            than the SF Map Index (if needed).</t>

            <t>In cases where GRE would already have been used, it is
            preferable to rely on this scheme and avoid yet another
            encapsulation overhead.</t>

            <t>An SF Node must rely on an internal tagging procedure to
            preserve the same header be positioned at the outgoing interface
            of an SF node.</t>

            <t>Further experiments may be required to compare the performance
            that would result in activating this solution vs. the performance
            observed when an IPv4 option or IPv6 extension header is used
            jointly with IP-in-IP encapsulation <xref
            target="RFC2003"></xref>.<?rfc subcompact="no" ?></t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| To be completed                                                   |
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section anchor="ipipsfc" title="Define a New IP-in-IP Scheme">
        <t>This proposal is compliant with <xref target="RFC1853"></xref>. It
        consists in adding a fixed header as shown in <xref
        target="sfcipinip"></xref>:</t>

        <t><figure align="center" anchor="sfcipinip">
            <artwork><![CDATA[                                    +---------------------------+
                                    |      Outer IP Header      |
                                    +---------------------------+
                                    |        SFC Header         |
+---------------------------+       +---------------------------+
|         IP Header         |       |      Inner IP Header      |
+---------------------------+ ====> +---------------------------+
|                           |       |                           |
|         IP Payload        |       |         IP Payload        |
|                           |       |                           |
+---------------------------+       +---------------------------+
]]></artwork>
          </figure>The following comments can be made:<list style="symbols">
            <t>This proposal covers both IPv4 and IPv6 deployment cases.</t>

            <t>An SF Node must rely on an internal tagging procedure to
            preserve the same header be positioned at the outgoing interface
            of an SF node.</t>

            <t>This header can be extended easily to accommodate new
            requirements.</t>

            <t>Because the SFC Header is part of the mandatory header, the
            performance are likely to not be severely impacted compared to
            other tunneling modes such as the joint use of IP-in-IP and an
            IPv4 option/IPv6 extension header.</t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| To be completed                                                   |
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>

      <section title="MAC-based SFC Forwarding">
        <t>The SFC Classifier capability introduced in <xref
        target="I-D.ietf-sfc-architecture"></xref> can be for instance
        supported by a GGSN node of a mobile network that also embeds the PCEF
        (Policy Charging Enforcement Function) function. A generic description
        of the related Gi Interface use case is discussed in <xref
        target="I-D.liu-sfc-use-cases"></xref>.</t>

        <t>This candidate solution assumes the following:<list style="symbols">
            <t>The SFC Classifier node is connected to various SF Nodes via a
            tunnel (e.g., VxLAN or L2VPN tunnel).</t>

            <t>A large block of MAC addresses are allocated to the SFC
            Classifier node.</t>

            <t>The SFC Classifier node can use different MAC addresses in the
            Source Address field of the data frame to identify different
            SFCs.</t>

            <t>Out-of-band message(s) can be exchanged between a SFC
            Classifier node and SF Nodes to signal the SFC associated to each
            Source MAC address.</t>
          </list></t>

        <t>The following comments can be made for this candidate
        solution:<?rfc subcompact="yes" ?><list style="symbols">
            <t>It can apply to any transport protocol.</t>

            <t>A large block of MAC addresses has to be allocated to the SFC
            Classifier node. The SFC Classifier node must have the extra logic
            of using different MAC addresses for different SF chains.</t>

            <t>Each SF node needs to be provisioned with instructions or
            policies provided to and relayed by the classifier on where to
            send a packet based on the source MAC address associated to a
            specific SFC.</t>

            <t>It is designed for topologies where Classifier and SF nodes can
            be connected by tunnels to maintain their Layer 2 connections. In
            particular, these tunnels are used to convey SFC-specific
            instructions and policies to the SF nodes. From that standpoint,
            the proposal is only applicable to such topologies.</t>

            <t>The proposed scheme requires that all traffic traverses the
            Classifier node first. The return path doesn't have to go back to
            the SFC Classifier node because all the SF Nodes forward traffic
            based on the instructions and policies provided to and relayed by
            the Classifier, instead of making forwarding decisions based upon
            the destination addresses.</t>

            <t>When multiple SFs that are part of a given SFC are co-located
            in the same device, the SFC Classifier may have trouble to decide
            which SF needs to be invoked in which order. A solution to avoid
            such complication is to use different source addresses to indicate
            which SFs and in which order. SF nodes (or Proxy Nodes) may need
            policies from the PDP, classification nodes, or control plane on
            how to steer packets based on source address to their designated
            SFs.</t>

            <t><!--CJ: I'm still unclear about the above statement. My understanding is that SF nodes will make their forwarding decisions based upon the policies they have been provisioned and according to the source MAC addrses of the L2 frame. As such, I'm not sure how co-located SF functions are a problem.-->The
            mechanism may be exposed to an overlapping MAC address situation
            whenever some of these MAC addresses need to be locally
            administered.</t>
          </list><?rfc subcompact="no" ?></t>

        <t><figure>
            <artwork><![CDATA[+-------------------------------------------------------------------+
| Proposed Recommendation                                           |
+-------------------------------------------------------------------+
| The MAC-based SFC forwarding is designed for specific topologies  |
| and assumes strong requirements on the SFC Classifier Node.       |
|                                                                   |
| The use of MAC-based SFC forwarding is only feasible when Service |
| Functions and the Classifier nodes are interconnected via         | 
| an Ethernet or other 802.1-based link layer. However, MAC-based   |
| SFC forwarding is not suitable as a generic SFC mechanism because |
| of its dependency on the specific link layer interconnection      |
| among SF classifier node and SF nodes.                            | 
+-------------------------------------------------------------------+]]></artwork>
          </figure></t>
      </section>
    </section>

    <section anchor="steer" title="Steer Paths To Cross Specific SF Nodes">
      <section title="Need for a Mandatory Encapsulation Scheme">
        <t>For interoperability reasons, one encapsulation mode MUST be
        defined. Refer to <xref target="RFC3439"></xref> for more discussion
        on the design principles.</t>
      </section>

      <section title="Candidate Solutions">
        <t>Given the requirements identified in <xref
        target="I-D.boucadair-sfc-requirements"></xref>, IP-based
        encapsulation schemes should be considered. From this standpoint, the
        following encapsulation candidate solutions are identified so
        far:<?rfc subcompact="yes" ?><list style="numbers">
            <t>Simple IP-in-IP &amp; a SFC header in the inner packet (e.g.,
            IPv4 option, IPv6 extension header)</t>

            <t>IP-in-IP with a fixed SFC header (<xref
            target="ipipsfc"></xref>).</t>

            <t>GRE &amp; GRE Key as a channel to convey the SF Map Index
            (<xref target="gre"></xref>)<?rfc subcompact="no" ?></t>
          </list></t>
      </section>

      <section title="Discussion">
        <t>The following table summarizes the main characteristics for each
        mode:</t>

        <texttable style="all">
          <ttcol align="center">Mode</ttcol>

          <ttcol align="center">Simple IP-in-IP &amp; a SFC header in the
          inner packet</ttcol>

          <ttcol align="center">IP-in-IP with a fixed SFC header</ttcol>

          <ttcol align="center">GRE &amp; GRE Key</ttcol>

          <c>Encapsulation overhead when the next hop SF is in the same
          subnet</c>

          <c>No</c>

          <c>Yes</c>

          <c>Yes</c>

          <c>A proprietary internal tagging mechanism is required</c>

          <c>No</c>

          <c>Yes</c>

          <c>Yes</c>

          <c>Natural extensibility</c>

          <c>Yes</c>

          <c>Yes</c>

          <c>No</c>

          <c>Risk to strip the header by intermediate nodes</c>

          <c>Yes</c>

          <c>No</c>

          <c>No</c>

          <c>Possible Impact on Performance</c>

          <c>Med to High</c>

          <c>Low to Med</c>

          <c>Med</c>
        </texttable>

        <t>The following comments can be made:<?rfc subcompact="yes" ?><list
            style="symbols">
            <t>Both "IP-in-IP with a fixed SFC header" and "GRE &amp; GRE Key"
            present almost the same characteristics except "IP-in-IP with a
            fixed SFC header" can be easily extended. Note, "GRE &amp; GRE
            Key" can also be extended with new optional fields but this may
            induce some performance degradation.</t>

            <t>"Simple IP-in-IP &amp; a SFC header in the inner packet" is
            more flexible:<list style="symbols">
                <t>It allows to convey the SFC header separately from the
                encapsulation header.</t>

                <t>It allows to avoid encapsulation overhead when adjacent SFs
                in a SFC sequence are in the same subnet.</t>

                <t>No internal tagging is needed within a SF Node.</t>

                <t>The SFC header can be extended in the future (if
                needed).</t>
              </list></t>

            <t>Indicated values for "Possible Impact on Performance" are
            hypothetical. These values are inspired from some experiments such
            as <xref target="Delay"></xref>. Ideally, further testing should
            be conducted to better qualify the impact on performance of these
            proposals under the same configuration and setup. <?rfc subcompact="no" ?></t>
          </list></t>

        <texttable>
          <ttcol>Proposed Recommendations</ttcol>

          <c>(1) Adopt the IP-in-IP with a fixed SFC header solution (<xref
          target="ipipsfc"></xref>). This mode is to be used as the MANDATORY
          encapsulation scheme for service chaining purposes. The main
          selection criteria for this proposed recommendation is to minimize
          performance impacts on involved nodes.</c>

          <c></c>

          <c>(2) To accommodate deployment cases where encapsulation is not
          required, allow to rely exclusively on a dedicated tagging field in
          the inner packet. This extension is to be defined in the
          EXPERIMENTAL track (e.g., <xref target="option"></xref>).</c>

          <c></c>

          <c>(3) Experimental specifications can be obsoleted or promoted to
          be in the Standard Tracks based on the conclusions from significant
          experiments.</c>
        </texttable>
      </section>
    </section>

    <section title="Summary">
      <t>As a consequence of the above analysis, the following recommendations
      are made:<list style="symbols">
          <t>**** TO BE COMPLETED ONCE THE ANALYSIS IS STABLE ****</t>
        </list></t>
    </section>

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

    <section anchor="Security" title="Security Considerations">
      <t>Security considerations related to Service Function Chaining are
      discussed in <xref target="I-D.ietf-sfc-architecture"></xref>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks to J. Halpern and P.Chuong for the coments on the
      subscriber-ID.</t>
    </section>
  </middle>

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

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

      <?rfc include='reference.RFC.0791'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-sfc-architecture'?>

      <?rfc include='reference.I-D.boucadair-sfc-requirements'?>

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

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

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

      <?rfc include='reference.I-D.boucadair-intarea-host-identifier-scenarios'?>

      <?rfc include='reference.I-D.liu-sfc-use-cases'?>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      <reference anchor="Report"
                 target="http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf">
        <front>
          <title>IPv6 Extension Headers Review and Considerations</title>

          <author initials="" surname="">
            <organization>Cisco</organization>

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

          <date />
        </front>
      </reference>

      <reference anchor="Delay">
        <front>
          <title>Measurement and Analysis of Single-Hop Delay on an IP
          Backbone Network</title>

          <author fullname="Konstantina Papagiannaki" initials="K."
                  surname="Papagiannaki">
            <organization></organization>
          </author>

          <author fullname="Sue Moon" initials="S." surname="Moon">
            <organization></organization>

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

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

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

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

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

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

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

          <date month="August" year="2003" />
        </front>
      </reference>

      <reference anchor="Robust"
                 target="http://netlab.caltech.edu/publications/JDoylepart1_vers42002.pdf">
        <front>
          <title>Robustness and the Internet: Design and evolution</title>

          <author fullname="Walter Willinger" initials="W."
                  surname="Walter Willinger">
            <organization></organization>
          </author>

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

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

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

          <date month="March" year="2002" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
