<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc7665 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7665.xml'>
<!ENTITY rfc8174 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml'>
<!ENTITY rfc8300 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8300.xml'>
<!ENTITY rfc8279 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8279.xml'>

]>

<rfc submissionType="independent" ipr="trust200902" category="info" number="XXXX"> "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     submissionType="independent" ipr="trust200902" category="info"
     number="8677" obsoletes="" updates=""
     docName="draft-trossen-sfc-name-based-sff-07" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.34.0 -->
  <front>
    <title abbrev="Name Based abbrev="Name-Based SFF">Name-Based Service Function Forwarder
    (nSFF) Component within Service Function Chaining (SFC) a Service&nbsp;Function&nbsp;Chaining&nbsp;(SFC) Framework</title>
    <seriesInfo name="RFC" value="8677"/>
    <author fullname="Dirk Trossen" initials="D." surname="Trossen">
      <organization> InterDigital Europe, Ltd </organization> Ltd</organization>
      <address>
        <postal>
          <street>64 Great Eastern Street, 1st Floor</street>
          <city>London</city>
          <code>EC2A 3QR</code>
          <country>United Kingdom</country>
        </postal>
        <email>Dirk.Trossen@InterDigital.com</email>
        <uri> </uri>
      </address>
    </author>
    <author initials="D." surname="Purkayastha" fullname="Debashish Purkayastha">
      <organization>InterDigital Communications, LLC</organization>
      <address>
        <postal>
          <street>1001 E Hector St</street>
          <city>Conshohocken</city>
          <code></code>
          <code/>
          <country>United States of America</country>
          <region></region>
          <region/>
        </postal>
        <phone></phone>
        <phone/>
        <email>Debashish.Purkayastha@InterDigital.com</email>
        <uri></uri>
        <uri/>
      </address>
    </author>
    <author initials="A." surname="Rahman" fullname="Akbar Rahman">
      <organization>InterDigital Communications, LLC</organization>
      <address>
        <postal>
          <street>1000 Sherbrooke Street West</street>
          <city>Montreal</city>
          <code></code>
          <code/>
          <country>Canada</country>
          <region></region>
          <region/>
        </postal>
        <phone></phone>
        <phone/>
        <email>Akbar.Rahman@InterDigital.com</email>
        <uri></uri>
        <uri/>
      </address>
    </author>
    <date year="2019" month="August" />

    <area></area>
    <workgroup></workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword> month="November"/>
    <area/>
    <workgroup/>

    <keyword>service function, SF, SFF, nSFF, SFC, SFP, NSH, FQDN, 5G, NSSAI,
    CCNF, NSSF, 3GPP</keyword>

    <abstract>
      <t>
       Adoption of cloud and fog technology allows operators to deploy a
       single "Service Function" (SF) to multiple "Execution "execution locations".  The
       decision to steer traffic to a specific location may change frequently
       based on load, proximity proximity, etc. Under the current
	   SFC Service Function
       Chaining (SFC) framework, steering traffic dynamically to the different
       execution end points require endpoints requires a specific 're-chaining', "rechaining", i.e., a change in
       the service function path reflecting the different IP endpoints to be
       used for the new execution points.  This procedure may be complex and
       take time. In order to simplify re-chaining rechaining and reduce the time to
       complete the procedure, we discuss separating the logical Service
       Function Path (SFP) from the specific execution end points. endpoints. This can be
       done by identifying the Service Functions SFs using a name rather than a
       routable IP endpoint (or Layer 2 address). This document describes the
       necessary extensions, additional functions functions, and protocol details in SFF
       (Service Function Forwarder) to handle name based name-based relationships.
      </t>
      <t>
	   This document presents InterDigital's approach to name-based service function chaining. SFC.
	   It does not represent IETF consensus and is presented here so that
	   the SFC community may benefit from considering this mechanism and
	   the possibility of its use in the edge data centers.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        The requirements on today's networks are very diverse, enabling
        multiple use cases such as IoT, the Internet of Things (IoT), Content
        Distribution, Gaming Gaming, and Network functions such as Cloud RAN Radio Access
        Network (RAN) and 5G control planes based on a service-based architecture. Service-Based
        Architecture (SBA). These services are deployed, provisioned provisioned, and managed
        using Cloud based Cloud-based techniques as seen in the IT world. Virtualization
        of compute and storage resources is at the heart of providing (often
        web) services to end users with the ability to quickly provisioning such provision
        virtualized service endpoints through, e.g., container based container-based
        techniques. This creates a dynamicity with the capability ability to dynamically compose new
        services from available services as well as existing services. It also allows an operator to move a
        service instance in response to user mobility or to change resource availability where desirable.
	availability. When moving from a pure 'distant cloud' purely "distant cloud" model to one
        of localized micro data centers with regional, metro metro, or even street
        level, often called 'edge' "edge" data centers, such virtualized service
        instances can be instantiated in topologically different locations
        with the overall 'distant' "distant" data center now being transformed into a
        network of distributed ones.

The reaction of content providers, like Facebook, Google, NetFlix NetFlix, and others, are
is not just relying to rely on deploying content server servers at the ingress of the
customer network. Instead Instead, the trend is towards deploying multiple POPs Point of
Presences (POPs) within the customer network, those POPs being connected
through proprietary mechanisms <xref target="Schlinker2017" /> format="default"/>
to push content.
      </t>
      <t>
        The Service Function Chaining (SFC) framework <xref target="RFC7665" />
        format="default"/> allows network operators as well as service
        providers to compose new services by chaining individual "Service Functions (SFs)". "service
        functions". Such chains are expressed through explicit relationships
        of functional components (the service functions), SFs) realized through their direct Layer
        2 (e.g., MAC Media Access Control (MAC) address) or Layer 3 (e.g., IP
        address) relationship as defined through next hop next-hop information that is
        being defined by the network operator, see Section 4 operator. See <xref target="Bkgnd"
        format="default"/> for more background on SFC.
      </t>
      <t>
         In a dynamic service environment of distributed data centers such as
         the one outlined above, with the ability to create and recreate
         service endpoints frequently, the SFC framework requires to reconfigure
         reconfiguring the existing chain through information based on the new
         relationships, causing overhead in a number of components,
         specifically the orchestrator that initiates the initial service function chain SFC and any
         possible reconfiguration.
      </t>
      <t>

This document describes how such changes can be handled without involving the
initiation of new and reconfigured SFCs SFCs.  This is accomplished by lifting the
chaining relationship from Layer 2 and Layer 3 information to that of service function 'names', such as names SF
"names", which can, for instance being instance, be expressed as URIs.

In order to transparently support such named relationships, we propose to
embed the necessary functionality directly into the Service Function Forwarder (SFF),
(SFF) as described in <xref target="RFC7665" />). format="default"/>. With that,
the SFF described in this document allows for keeping an existing SFC intact,
as described by its service function path Service Function Path (SFP), while enabling the selection
of an appropriate service function endpoint(s) during the traversal of packets
through the SFC. This document is an Independent Submission to the RFC
Editor. It is not an output of the IETF SFC WG.
      </t>
    </section>
    <section anchor="terminology" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
    "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/>
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section anchor="Use_Case" title="Example numbered="true" toc="default">
      <name>Example Use Case: 5G Control-Plane Services"> Services</name>
      <t>
	    We exemplify the need for chaining service functions SFs at the level
	    of a service name through a use case stemming from the current
	    3GPP Rel Release 16 work on Service Based Architecture (SBA) <xref target="_3GPP_SBA"/>, target="SDO-3GPP-SBA" format="default"/>, <xref target="_3GPP_SBA_ENHANCEMENT"/>. target="SDO-3GPP-SBA-ENHANCEMENT" format="default"/>. In
	    this work, mobile network control planes are proposed to be
	    realized by replacing the traditional network function interfaces
	    with a fully service-based one. HTTP was chosen as the application layer
	    application-layer protocol for exchanging suitable service
	    requests <xref target="_3GPP_SBA"/>. target="SDO-3GPP-SBA" format="default"/>. With this in mind, the
	    exchange between, say for example, the 3GPP 3GPP-defined (Rel. 15) defined Session
	    Management Function (SMF) and the Access and Mobility management Management
	    Function (AMF) in a 5G control plane is being described as a set
	    of web service like web-service-like requests which are that are, in turn turn, embedded into HTTP
	    requests. Hence, interactions in a 5G control plane can be modelled
	    modeled based on service function chains SFCs where the relationship
	    is between the specific (IP-based) service function SF endpoints that
	    implement the necessary service endpoints in the SMF and AMF. The service functions
	    SFs are exposed through URIs with work ongoing to
	    define the used naming conventions for such URIs.
      </t>

      <t>
	     This move from a network function model (in pre-Rel pre-Release 15
	     systems of 3GPP) to a service-based model is motivated through
	     the proliferation of data center data-center operations for mobile network
	     control-plane services. In other words, typical IT-based methods
	     to service provisioning, in particular particularly that of virtualization of
	     entire compute resources, are envisioned to being used in future
	     operations of mobile networks.  Hence, operators of such future
	     mobile networks desire to virtualize service function SF endpoints and direct
	     (control-plane) traffic to the most appropriate current service
	     instance in the most appropriate (local) data centre, such center. Such a data centre
	     center is envisioned as being interconnected through a
	     software-defined wide area network (SD-WAN). 'Appropriate'  "Appropriate" here
	     can be defined by topological or geographical proximity of the
	     service initiator to the service function SF endpoint. Alternatively, network or
	     service instance compute load can be used to direct a request to
	     a more appropriate (in this case less loaded) instance to reduce
	     possible latency of the overall request. Such data center centric data-center-centric
	     operation is extended with the trend towards regionalization of
	     load through a 'regional office' "regional office" approach, where micro data
	     centers provide virtualizable resources that can be used in the
	     service execution, creating a larger degree of freedom when
	     choosing the 'most appropriate' "most appropriate" service endpoint for a particular
	     incoming service request.
      </t>
      <t>
	     While the move to a service-based model aligns well with the
	     framework of SFC, choosing the most appropriate service instance
	     at runtime requires so-called 're-chaining' "rechaining" of the SFC since the
	     relationships in said SFC are defined through Layer 2 or Layer 3
	     identifiers, which which, in turn turn, are likely to be different if the
	     chosen service instances reside in different parts of the network
	     (e.g., in a regional data center).
      </t>

      <t>
         Hence, when a traffic flow is forwarded over a service chain
         expressed as an SFC-compliant Service Function Path (SFP), SFP, packets in the traffic flow are
         processed by the various service function SF instances, with each service function SF instance applying a service function
         an SF prior to forwarding the packets to the next
         network node.

It is a Service layer service-layer concept and can possibly work over any Virtual network
layer and an Underlay network, possibly corresponding underlay network.  The underlay network can be IP or
alternatively any Layer 2 technology.

At the service layer, Service Functions SFs are identified using a path identifier
and an index. Eventually Eventually, this index is translated to an IP address (or MAC
address) of the host where the service function SF is running. Because of this,
any change of service change-of-service function instance is likely to require a change of the
path information since either the IP address (in the case of changing the
execution from one data centre center to another) or MAC address will change due to
the newly selected service function SF instance.
      </t>

      <t> Returning to our 5G control-plane example, a user's connection request to
 access an application server in the internet Internet may start with signaling in the Control Plane to setup user
 control plane to set up user-plane bearers. The connection request may flow
 through service functions SFs over a service chain in the Control control plane, as
 deployed by a network operator. Typical SFs in a 5G control plane may include
 "RAN termination / processing", "Slice Selection Function", "AMF" "AMF", and
 "SMF". A Network Slice "Network Slice" is a complete logical network including Radio Access
 Network (RAN) and Core Network (CN). Distinct RAN and Core Network CN Slices may exist. A
 device may access multiple Network Slices simultaneously through a single
 RAN. The device may provide Network Slice Selection Assistance Information
 (NSSAI) parameters to the network to help it select a RAN and a Core network Network
 part of a slice instance.

Part of the control plane, the Common Control Network Function (CCNF),
includes the Network Slice Selection Function (NSSF) (NSSF), which is in charge of
selecting core Network Slice instances.

The Classifier, classifier, as described in SFC architecture, may reside in the user
terminal or at the eNB. Evolved Node B (eNB).  These service functions SFs can be
configured to be part of a Service Function Chain. an SFC. We can also say that some
of the configurations of the Service Function Path SFP may change at the execution
time. For example, the SMF may be relocated as the user moves and a new SMF
may be included in the Service Function Path SFP based on user location. The following diagram in Figure 1 <xref
target="fig-sfc-1" format="default"/> shows the example Service Function Chain SFC described here.
      </t>
	  <t>
      <figure anchor="fig-sfc-1" align="center" title="Mapping anchor="fig-sfc-1">
        <name>Mapping SFC onto Service Function Execution Points along a Service Function Path"> Path</name>
        <artwork align="center">

+------+ align="center" name="" type="" alt=""><![CDATA[+------+   +---------+  +-----+   +-----+
| User |   | Slice   |  |     |   |     |
| App  |-->| Control |->| AMF |-->| SMF |-->
| Fn   |   | Function|  |     |   |     |
+------+   +---------+  +-----+   +-----+

                 </artwork>   +-----+]]></artwork>
      </figure>
        </t>
    </section>
    <section anchor="Bkgnd" title="Background"> numbered="true" toc="default">
      <name>Background</name>
      <t>
	   <xref target="RFC7665" /> format="default"/> describes an architecture
	   for the specification, creation creation, and ongoing maintenance of Service Function Chains (SFCs). SFCs.
	   It includes architectural concepts, principles, and components used
	   in the construction of composite services through deployment of
	   SFCs. In the following, we outline the parts of this SFC
	   architecture relevant for our proposed extension, followed by the
	   challenges with this current framework in the light of our example
	   use case.
      </t>
      <section anchor="Arch" title="Relevant numbered="true" toc="default">
        <name>Relevant Part of SFC Architecture"> Architecture</name>
        <t>

		  The SFC Architecture, architecture, as defined in <xref target="RFC7665" />,
		  format="default"/>, describes architectural components such
		  as Service Function (SF), Classifier, SF, classifier, and Service Function Forwarder (SFF). SFF. It describes the Service Function Path (SFP) SFP as the
		  logical path of an SFC. Forwarding traffic along such an SFP
		  is the responsibility of the SFF. For this, the SFFs in a
		  network maintain the requisite SFP forwarding information.
		  Such SFP forwarding information is associated with a service
		  path identifier (SPI) that is used to uniquely identify an
		  SFP.  The service forwarding state is represented by the
		  Service Index (SI) and enables an SFF to identify which SFs
		  of a given SFP should be applied, and in what order. The SFF
		  also has information that allows it to forward packets to
		  the next SFF after applying local service functions. SFs.
        </t>
        <t>
		 The operational steps to forward traffic are then as follows:
		 Traffic arrives at an SFF from the network.  The SFF
		 determines the appropriate SF the traffic should be forwarded
		 to via information contained in the SFC encapsulation.  After
		 SF processing, the traffic is returned to the SFF, SFF and, if
		 needed, is forwarded to another SF associated with that SFF.
		 If there is another non-local hop (i.e., to an SF with a
		 different SFF) in the SFP, the SFF further encapsulates the
		 traffic in the appropriate network transport protocol and
		 delivers it to the network for delivery to the next SFF along
		 the path.  Related to this forwarding responsibility, an SFF
		 should be able to interact with metadata.
        </t>
      </section>
      <section anchor="Challenges" title="Challenges numbered="true" toc="default">
        <name>Challenges with Current Framework"> Framework</name>
        <t>
	   As outlined in previous section, sections, the Service Function Path SFP defines
	   an ordered sequence of specific Service Functions SF instances being
	   used for the interaction between initiator and service functions SFs
	   along the SFP. These service functions SFs are addressed by IP (or any
	   L2/MAC) addresses and defined as next hop next-hop information in the
	   network locator maps of traversing SFF nodes.
        </t>
        <t>
       As outlined in our use case, however, the service provider may want to
       provision SFC nodes based on dynamically spun up service function spun-up SF
       instances so that these (now virtualized) service functions SFs can be
       reached in the SFC domain using the SFC underlay layer.
        </t>
        <t>
       Following the original model of SFC, any change in a specific execution
       point for a specific Service Function SF along the SFP will require a
       change of the SFP information (since the new service function SF execution
       point likely carries different IP or L2 address information) and
       possibly even the Next Hop next-hop information in SFFs along the SFP. In case
       the availability of new service function SF instances is rather dynamic
       (e.g., through the use of container-based virtualization techniques),
       the current model and realization of SFC could lead to reducing the
       flexibility of service providers and increasing the management
       complexity incurred by the frequent changes of (service) forwarding
       information in the respective SFF nodes. This is because any change of
       the SFP (and possibly next hop next-hop info) will need to go through suitable
       management cycles.
        </t>
        <t>
	    To address these challenges through a suitable solution, we identify the following requirements:

		  <list style="symbols">
		   <t>

        </t>
        <ul spacing="normal">
          <li>
			  Relations between Service Execution Points MUST <bcp14>MUST</bcp14> be
			  abstracted so that, from an SFP point of view, the
			  Logical Path never changes.
		   </t>
		   <t>
		   </li>
          <li>
			  Deriving the Service Execution Points from the
			  abstract SFP SHOULD <bcp14>SHOULD</bcp14> be fast and incur minimum delay.
		   </t>
<!-- [rfced] In the following sentence, should RFC 2119 keyword "SHOULD not" be "SHOULD NOT"?

Original:
   Identification of the Service Execution Points SHOULD not use a combination
   of Layer 2 or Layer 3 mechanisms.
-->
		   <t>
		   </li>

          <li>
			  Identification of the Service Execution Points SHOULD not
			  <bcp14>SHOULD NOT</bcp14> use a combination of Layer 2 or Layer 3
			  mechanisms.
		   </t>
		  </list>
       </t>
		   </li>
        </ul>
        <t>
       The next section outlines a solution to address the issue, allowing for
       keeping SFC information (represented in its SFP) intact while
       addressing the desired flexibility of the service provider.
        </t>
      </section>
    </section>
    <section anchor="nop" title="Name-Based numbered="true" toc="default">
      <name>Name-Based Operation in SFF"> SFF</name>
      <section anchor="General" title="General Idea"> numbered="true" toc="default">
        <name>General Idea</name>
        <t>
	   The general idea is two-pronged. two pronged. Firstly, we elevate the definition
	   of a Service Function Path an SFP onto the level of 'name-based interactions' "name-based
	   interactions" rather than limiting SFPs to Layer 3 2 or Layer 2 3 information
	   only. Secondly, we extend the operations of the SFF to allow for
	   forwarding decisions that take into account such name-based
	   interaction while remaining backward compatible to the current SFC architecture,
	   architecture as defined in <xref target="RFC7665" />.
	   format="default"/>. In the following sections, we outline these two
	   components of our solution.
        </t>

        <t>
	    If the next hop next-hop information in the Network Locator Map (NLM) is
	    described using an L2/L3 identifier, the name-based SFF (nSFF) may
	    operate as described for [traditional] (traditional) SFF, as defined in <xref
	    target="RFC7665" />. format="default"/>.  On the other hand, if the next hop
	    next-hop information in the NLM is described as a name, then the
	    nSFF operates as described in the following sections.
        </t>
        <t>
	    In the following sections, we outline the two components of our solution.
        </t>
      </section>
      <section anchor="nsfp" title="Name-Based numbered="true" toc="default">
        <name>Name-Based Service Function Path (nSFP)"> (nSFP)</name>
        <t>
		The existing SFC framework is defined in <xref
		target="RFC7665" />. Section 4 format="default"/>. <xref target="Bkgnd"
		format="default"/> outlines that the SFP information is
		representing path information based on Layer 2 or Layer 3
		information, i.e., MAC or IP addresses, causing the
		aforementioned frequent adaptations in cases of execution point
		execution-point changes. Instead, we introduce the notion of a
		"name-based service function path Service Function Path (nSFP)".
        </t>
        <t>
         In today's networking terms, any identifier can be treated as a name name,
         but we will illustrate the realization of a "Name based "Name-based SFP" through
         extended SFF operations (see Section 6) <xref target="nsfffwd" format="default"/>) based on URIs as names and
         HTTP as the protocol of exchanging information. Here, URIs are being
         used to name for a Service Function an SF along the nSFP. It is to be noted Note
         that the Name based SFP nSFP approach is not restricted to HTTP (as the
         protocol) and URIs (as next hop next-hop identifier within the SFP). Other
         identifiers such as an IP address itself can also be used and are
         interpreted as a 'name' "name" in the nSFP. IP addresses as well as fully
         qualified domain names forming complex URIs (uniform resource
         identifiers), such as www.example.com/service_name1, are all captured
         by the notion of 'name' "name" in this document.

        </t>
        <t>
        Generally, nSFPs are defined as an ordered sequence of the "name" of Service Functions (SF)
        SFs, and a typical name-based Service Function Path nSFP may look like: 192.0.x.x -> -&gt; www.example.com ->
        -&gt; www.example2.com/service1 -> -&gt; www.example2.com/service2.
        </t>
        <t>
        Our use case in Section 3 <xref target="Use_Case" format="default"/> can then be
        represented as an ordered named sequence. An example for a session
        initiation that involves an authentication procedure, this could look
        like 192.0.x.x -> -&gt; smf.example.org/session_initiate -> -&gt;
        amf.example.org/auth -> -&gt; smf.example.org/session_complete -> -&gt;
        192.0.x.x.
		[Note  (Note that this example is only a conceptual one, one since the
        exact nature of any future SBA-based exchange of 5G control-plane
        functions is yet to be defined by standardization bodies such as 3GPP].
        3GPP).
        </t>
        <t>
        In accordance with our use case in Section 3, <xref target="Use_Case" format="default"/>, any of these named
        services can potentially be realized through more than one replicated
        SF instances. instance. This leads to make making dynamic decision decisions on where to send
        packets along the SAME service function path SFP information, being
        provided during the execution of the SFC.  Through elevating the SFP
        onto the notion of name-based interactions, the SFP will remain the
        same even if those specific execution points change for a specific
        service interaction.
        </t>
        <t>
        The following diagram in Figure 2, <xref target="fig-sfc-2" format="default"/> describes this name-based SFP nSFP
        concept and the resulting mapping of those named interactions onto
        (possibly) replicated instances.
        </t>
        <figure anchor="fig-sfc-2" align="center" title="Mapping anchor="fig-sfc-2">
          <name>Mapping SFC onto Service Function Execution Points along a Service Function Path based Based on Virtualized Service Function Instance"> Instance</name>
          <artwork align="center"> align="center" name="" type="" alt=""><![CDATA[ +---------------------------------------------------------------+
 |SERVICE LAYER
 |Service Layer                                                  |
 | 192.0.x.x --> www.example.com --> www.example2.com -->        |
 |                      ||              ||                       |
 +----------------------||--------------||-----------------------+
                        ||              ||
                        ||              ||
 +----------------------||--------------||-----------------------+
 | Underlay network
 |Underlay Network      \/              \/                       |
 |               +--+ +--+ +--+    +--+ +--+ +--+                |
 |               |  | |  | |  |    |  | |  | |  |                |
 |               +--+ +--+ +--+    +--+ +--+ +--+                |
 |               Compute and       Compute and                   |
 |               storage nodes     storage nodes                 |
 +---------------------------------------------------------------+

         </artwork>
 +---------------------------------------------------------------+]]></artwork>
        </figure>
	   </t>
      </section>
      <section anchor="nnlm" title="Name-Based numbered="true" toc="default">
        <name>Name-Based Network Locator Map (nNLM)"> (nNLM)</name>
        <t>
        In order to forward a packet within a name-based SFP, an nSFP, we need to
        extend the network locator map NLM as defined in <xref target="RFC8300" /> format="default"/>
        with the ability to consider name relations based on URIs as well as
        high-level transport protocols such as HTTP for means of SFC packet
        forwarding. Another example for SFC packet forwarding could be that of CoAP.
        Constrained Application Protocol (CoAP).
        </t>
        <t>
         The extended Network Locator Map NLM or name-based Network Locator Map
         (nNLM) is shown in Figure 3 <xref target="fig-sfc-3" format="default"/> as an example for www.example.com being
         part of the nSFP. Such extended nNLM is stored at each SFF throughout
         the SFC domain with suitable information populated to the nNLM during
         the configuration phase.
        </t>
	   <t>
		 <figure anchor="fig-sfc-3" align="center" title="Name-Based

<table anchor="fig-sfc-3">
  <name>Name-Based Network Locator Map">
         <artwork align="center">

  +------+------+---------------------+-----------------------------+
  | SPI  | SI   | Next Hop(s)         | Transport Map</name>
  <thead>
    <tr>
      <th>SPI</th>
      <th>SI</th>
      <th>Next Hop(s)</th>
      <th>Transport Encapsulation (TE)|
  +------+------+---------------------+-----------------------------+
  | 10   | 255  | 192.0.2.1           | VXLAN-gpe                   |
  |      |      |                     |                             |
  | 10   | 254  | 198.51.100.10       | GRE                         |
  |      |      |                     |                             |
  | 10   | 253  | www.example.com     | HTTP                        |
   -----------------------------------------------------------------
  |      |      |                     |                             |
  | 40   | 251  | 198.51.100.15       | GRE                         |
  |      |      |                     |                             |
  | 50   | 200  | 01:23:45:67:89:ab   | Ethernet                    |
  |      |      |                     |                             |
  | 15   | 212  | Null (TE)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>10</td>
      <td>255</td>
      <td>192.0.2.1</td>
      <td>VXLAN-gpe</td>
    </tr>
    <tr>
      <td>10</td>
      <td>254</td>
      <td>198.51.100.10</td>
      <td>GRE</td>
    </tr>
    <tr>
      <td>10</td>
      <td>253</td>
      <td>www.example.com</td>
      <td>HTTP</td>
    </tr>
    <tr>
      <td>40</td>
      <td>251</td>
      <td>198.51.100.15</td>
      <td>GRE</td>
    </tr>
        <tr>
      <td>50</td>
      <td>200</td>
      <td>01:23:45:67:89:ab</td>
      <td>Ethernet</td>
	</tr>
	        <tr>
      <td>15</td>
      <td>212</td>
      <td>Null (end of path)  | None                        |
  +------+------+---------------------+-----------------------------+

         </artwork>
         </figure>
	   </t> path)</td>
      <td>None</td>
    </tr>
  </tbody>
</table>

        <t>
	    Alternatively, the extended network locator map NLM may be defined with implicit name
	    information rather than explicit URIs as in Figure 3. <xref
	    target="fig-sfc-3" format="default"/>. In the example of Figure 4 below, <xref
	    target="fig-sfc-4" format="default"/>, the next hop is represented
	    as a generic HTTP service without a specific URI being identified
	    in the extended network locator map. NLM. In this scenario, the SFF
	    forwards the packet based on parsing the HTTP request in order to
	    identify the host name or URI. It retrieves the URI and may apply
	    policy information to determine the destination host/service.
        </t>
	   <t>
		 <figure anchor="fig-sfc-4" align="center" title="Name-based

<table anchor="fig-sfc-4">
  <name>Name-Based Network Locator Map with Implicit Name information">
         <artwork align="center">

  +------+------+---------------------+-----------------------------+
  | SPI  | SI   | Next Hop(s)         | Transport Information</name>
  <thead>
    <tr>
      <th>SPI</th>
      <th>SI</th>
      <th>Next Hop(s)</th>
      <th>Transport Encapsulation (TE)|
  +------+------+---------------------+-----------------------------+
  | 10   | 255  | 192.0.2.1           | VXLAN-gpe                   |
  |      |      |                     |                             |
  | 10   | 254  | 198.51.100.10       | GRE                         |
  |      |      |                     |                             |
  | 10   | 253  | HTTP Service        | HTTP                        |
   -----------------------------------------------------------------
  |      |      |                     |                             |
  | 40   | 251  | 198.51.100.15       | GRE                         |
  |      |      |                     |                             |
  | 50   | 200  | 01:23:45:67:89:ab   | Ethernet                    |
  |      |      |                     |                             |
  | 15   | 212  | Null (TE)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>10</td>
      <td>255</td>
      <td>192.0.2.1</td>
      <td>VXLAN-gpe</td>
    </tr>
    <tr>
      <td>10</td>
      <td>254</td>
      <td>198.51.100.10</td>
      <td>GRE</td>
    </tr>
    <tr>
      <td>10</td>
      <td>253</td>
      <td>HTTP Service</td>
      <td>HTTP</td>
    </tr>
    <tr>
      <td>40</td>
      <td>251</td>
      <td>198.51.100.15</td>
      <td>GRE</td>
    </tr>
        <tr>
      <td>50</td>
      <td>200</td>
      <td>01:23:45:67:89:ab</td>
      <td>Ethernet</td>
	</tr>
	        <tr>
      <td>15</td>
      <td>212</td>
      <td>Null (end of path)  | None                        |
  +------+------+---------------------+-----------------------------+

         </artwork>
         </figure>
	   </t> path)</td>
      <td>None</td>
    </tr>
  </tbody>
</table>

      </section>
      <section anchor="nsff" title="Name-Based numbered="true" toc="default">
        <name>Name-Based Service Function Forwarder (nSFF)"> (nSFF)</name>
        <t>
	     It is desirable to extend the SFF of the SFC underlay to handle
	     nSFPs transparently and without the need to insert any service function SF into
	     the nSFP. Such extended name-based SFF nSFFs would then be responsible
	     for forwarding a packet in the SFC domain as per the definition
	     of the (extended) nSFP.
        </t>
        <t>
        In our exemplary example realization for an extended SFF, the solution
        described in this document uses HTTP as the protocol of forwarding SFC
        packets to the next (name-based) hop in the nSFP.

	The URI in the HTTP transaction are is the names name in our nSFP information,
	which will be used for name based name-based forwarding.
        </t>
        <t>
        Following our reasoning so far, HTTP requests (and more specifically specifically,
        the plain text encoded plaintext-encoded requests above) are the equivalent of Packets packets
        that enter the SFC domain. In the existing SFC framework, typically an
        IP payload is typically assumed to be a packet entering the SFC domain. This
        packet is forwarded to destination nodes using the L2
        encapsulation. Any layer 2 network can be used as an underlay
        network. This notion is now extended to packets being possibly part of a
        an entire higher layer application, higher-layer application such as HTTP requests. The handling
        of any intermediate layers layers, such as TCP, IP TCP and IP, is left to the realization
        of the (extended) SFF operations towards the next (named) hop. For
        this, we will first outline the general lifecycle of an SFC packet in
        the following subsection, followed by two examples for determining next hop
        next-hop information in Section 6.2.3, finalized <xref target="localfwd" format="default"/>, finished up by a layered view on
        the realization of the nSFF in Section 6.2.4. <xref target="httpresp" format="default"/>.
        </t>
      </section>
      <section anchor="arch" title="High-Level Architecture">
	   <t> numbered="true" toc="default">
        <name>High-Level Architecture</name>
        <figure anchor="fig-sfc-5" align="center" title="High-level architecture"> anchor="fig-sfc-5">
          <name>High-Level Architecture</name>
          <artwork align="center"> align="center" name="" type="" alt=""><![CDATA[
+----------+
| SF1      |                 +--------+                  +------+
| instance |\                |   NR   |                  | SF2  |
+----------+ \               +--------+                  +------+
              \                  ||                         ||
+------------+ \ +-------+   +---------+   +---------+   +-------+
| Classifier |---| nSFF1 |---|Forwarder|---|Forwarder|---| nSFF2 |
+------------+   +-------+   +---------+   +---------+   +-------+
                                                            ||
                                                        +----------+
                                                        | Boundary |
                                                        |  node    |
                                                        +----------+

         </artwork>
                                                        +----------+]]></artwork>
        </figure>
        </t>
        <t>
	    The high-level architecture for name based name-based operation shown in Figure 5
	    <xref target="fig-sfc-5" format="default"/> is very similar to the
	    SFC architecture, architecture as described in <xref target="RFC7665" />.
	    format="default"/>. Two new functions are introduced, as shown in
	    the above diagram, namely diagram: namely, the name-based Service Function Forwarder (nSFF) nSFF and the Name Resolver (NR).
        </t>
        <t>
		The nSFF (name-based Service Function Forwarder) is an extension of the existing SFF and is capable of
		processing SFC packets based on name-based network locator map (nNLM) nNLM information, determining
		the next SF, SF where the packet should be forwarded forwarded, and the
		required transport encapsulation. encapsulation (TE). Like standard SFF operation,
		it adds transport encapsulation TE to the SFC packet and forwards
		it.
        </t>
        <t>
		The Name Resolver NR is a new functional component, capable of
		identifying the execution end points, endpoints, where a "named SF" is
		running, triggered by suitable resolution requests sent by the
		nSFF. Though this is similar to DNS function, but it is not
		same. It does not use DNS protocols or data records. A new
		procedure to determine the suitable routing/forwarding
		information towards the Nsff (name-based SFF) nSFF serving the next
		hop of the SFP (Service Function Path) is used. The details is are
		described later.
        </t>
        <t>
        The other functional components components, such as Classifier, SF classifier and SF, are the same as
        described in SFC architecture, as defined in <xref target="RFC7665" />, format="default"/>, while the Forwarders shown in the above diagram are traditional
        Layer 2 switches.
        </t>
      </section>
      <section anchor="steps" title="Operational Steps"> numbered="true" toc="default">
        <name>Operational Steps</name>

        <t>
		 In the proposed solution, the operations are realized by the
		 name-based SFF, called nSFF. "nSFF". We utilize the high-level
		 architecture in Figure 5 <xref target="fig-sfc-5" format="default"/>
		 to describe the traversal between two service function SF
		 instances of an nSFP-based transactions transaction in an example chain of :
		 of: 192.0.x.x -> -&gt; SF1 (www.example.com) -> -&gt; SF2
		 (www.example2.com) -> -&gt; SF3 -> -&gt; ... Service
	</t>
<t>Service Function 3 (SF3)is (SF3) is assumed to be a classical Service Function, hence SF;
hence, existing SFC mechanisms can be used to reach it and will not be
considered in this example.
        </t>
        <t>
         According to the SFC lifecycle, as defined in <xref target="RFC7665" />,
         format="default"/>, based on our example chain above, the traffic
         originates from a Classifier classifier or another SFF on the left. The traffic
         is processed by the incoming nSFF1 (on the left side) through the
         following steps. The traffic exits at nSFF2.
        </t>
		<t>
		<list style="symbols">
		   <t>
		     Step 1:
        <ol spacing="normal" type="Step %d:" group="steps" indent="9">
          <li anchor="step1">

		     At nSFF1 nSFF1, the following nNLM is assumed
		     <figure anchor="fig-sfc-6" align="center" title="nNLM assumed:</li>

	</ol>
<table anchor="fig-sfc-6">
  <name>nNLM at nSFF1">
             <artwork align="center">

   +------+------+---------------------+----------------------------+
   | SPI  | SI   | Next Hop(s)         | Transport Encapsulation(TE)|
   +------+------+---------------------+----------------------------+
   | 10   | 255  | 192.0.2.1           | VXLAN-gpe                  |
   |      |      |                     |                            |
   | 10   | 254  | 198.51.100.10       | GRE                        |
   |      |      |                     |                            |
   | 10   | 253  | www.example.com     | HTTP                       |
   |      |      |                     |                            |
   | 10   | 252  | www.example2.com    | HTTP                       |
   |      |      |                     |                            |
   | 40   | 251  | 198.51.100.15       | GRE                        |
   |      |      |                     |                            |
   | 50   | 200  | 01:23:45:67:89:ab   | Ethernet                   |
   |      |      |                     |                            |
   | 15   | 212  | Null nSFF1</name>
  <thead>
    <tr>
      <th>SPI</th>
      <th>SI</th>
      <th>Next Hop(s)</th>
      <th>Transport Encapsulation (TE)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>10</td>
      <td>255</td>
      <td>192.0.2.1</td>
      <td>VXLAN-gpe</td>
    </tr>
    <tr>
      <td>10</td>
      <td>254</td>
      <td>198.51.100.10</td>
      <td>GRE</td>
    </tr>
    <tr>
      <td>10</td>
      <td>253</td>
      <td>www.example.com</td>
      <td>HTTP</td>
    </tr>
    <tr>
      <td>10</td>
      <td>252</td>
      <td>www.example2.com</td>
      <td>HTTP</td>
    </tr>
        <tr>
      <td>40</td>
      <td>251</td>
      <td>198.51.100.15</td>
      <td>GRE</td>
	</tr>
	    <tr>
      <td>50</td>
      <td>200</td>
      <td>01:23:45:67:89:ab </td>
      <td>Ethernet</td>
	    </tr>
	        <tr>
      <td>15</td>
      <td>212</td>
      <td>Null (end of path)  | None                       |
   +------+------+---------------------+----------------------------+

              </artwork>
              </figure>

		   </t>
		   <t>Step 2: nSFF1 path)</td>
      <td>None</td>
    </tr>
  </tbody>
</table>
	        <ol spacing="normal" type="Step %d:" group="steps" indent="9">
          <li anchor="step2">nSFF1 removes the previous transport
		   encapsulation (TE) for any traffic originating from another
		   SFF or classifier (traffic from an SF instance does not
		   carry any TE and is therefore directly processed at the
		   nSFF).
		   </t>
		   <t>
		    Step 3:
		   </li>
          <li anchor="step3">
		    nSFF1 then processes the Network Service Header (NSH)
		    information, as defined in <xref target="RFC8300" />,
		    format="default"/>, to identify the next SF at the nSFP
		    level by mapping the NSH information to the appropriate
		    entry in its nNLM (see Figure 6) <xref target="fig-sfc-6"
		    format="default"/>) based on the provided SPI/SI
		    information in the NSH (see Section 4) <xref target="Bkgnd"
		    format="default"/>) in order to determine the name-based
		    identifier of the next hop next-hop SF. With such nNLM in mind, the
		    nSFF searches the map for SPI = 10 and SI = 253. It
		    identifies the next hop as = www.example.com and HTTP as
		    the protocol to be used. Given that the next hop resides
		    locally, the SFC packet is forwarded to the SF1 instance
		    of www.example.com. Note that the next hop could also be
		    identified from the provided HTTP request, if the next hop next-hop
		    information was identified as a generic HTTP service, as
		    defined in Section 5.3.
           </t>
		   <t>
             Step 4: <xref target="nnlm" format="default"/>.
           </li>

         <li anchor="step4">
             The SF1 instance then processes the received SFC packet
             according to its service semantics and modifies the NSH by
             setting SPI = 10, 10 and SI = 252 for forwarding the packet along the
             SFP. It then forwards the SFC packet to its local nSFF, i.e.,
             nSFF1.
		   </t>
		   <t>Step 5: nSSF1
		   </li>
          <li anchor="step5">nSSF1 processes the NSH of the SFC packet again,
		   now with the NSH modified (SPI = 10, SI = 252) by the SF1
		   instance. It retrieves the next hop next-hop information from its
		   nNLM in Figure 6, <xref target="fig-sfc-6" format="default"/> to be www.example2.com. Due to this SF
		   not being locally available, the nSFF consults any locally
		   available information regarding routing/forwarding towards
		   a suitable nSFF that can serve this next hop.
		   </t>
		   <t>Step 6: If
		   </li>
         <li anchor="step6">If such information exists, the Packet (plus the
         NSH information) is marked to be sent towards the nSFF serving the
         next hop based on such information in step 8.</t>
           <t>Step 7: If <xref target="step8"
         format="none">Step 8</xref>.</li>
          <li anchor="step7">If such information does not exist, nSFF1
          consults the Name Resolver (NR) NR to determine the suitable routing/forwarding
          information towards the identified nSFF serving the next hop of the
          SFP.  For future SFC packets towards this next hop, such resolved
          information may be locally cached, avoiding to contact contacting the Name Resolver NR for
          every SFC packet forwarding. The packet is now marked to be sent via
          the network in step 8.
		   </t>
           <t>Step 8: Utilizing <xref target="step8" format="none">Step 8</xref>.
		   </li>
           <li anchor="step8">Utilizing the forwarding information
	   determined in steps 6 Steps <xref target="step6"
	  format="none">6</xref> or 7, <xref target="step7"
	  format="none">7</xref>, nSFF1 adds the suitable transport encapsulation (TE) TE for
           the SFC packet before forwarding via the forwarders in the network
           towards the next nSFF22.</t>
           <t>Step 9: nSFF22.</li>

           <li anchor="step9">
            When the Packet (+NSH+TE) arrives at the outgoing nSFF2, i.e., the
            nSFF serving the identified next hop of the SFP, it removes the TE
            and processes the NSH to identify the next hop next-hop information. At
            nSFF2 the nNLM in Figure 7 <xref target="fig-sfc-7" format="default"/> is
            assumed. Based on this nNLM and NSH information where SPI = 10 and
            SI = 252, nSFF2 identifies the next SF as www.example2.com.
		     <figure anchor="fig-sfc-7" align="center" title="nNLM
            </li></ol>

<table anchor="fig-sfc-7">
  <name>nNLM at SFF2">
             <artwork align="center">

  +------+------+---------------------+-----------------------------+
  | SPI  | SI   | Next Hop(s)         | Transport SFF2</name>
  <thead>
    <tr>
      <th>SPI</th>
      <th>SI</th>
      <th>Next Hop(s)</th>
      <th>Transport Encapsulation (TE)|
  +------+------+---------------------+-----------------------------+
  |      |      |                     |                             |
  | 10   | 252  | www.example2.com    | HTTP                        |
  |      |      |                     |                             |
  | 40   | 251  | 198.51.100.15       | GRE                         |
  |      |      |                     |                             |
  | 50   | 200  | 01:23:45:67:89:ab   | Ethernet                    |
  |      |      |                     |                             |
  | 15   | 212  | Null (TE)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>10</td>
      <td>252</td>
      <td>www.example2.com</td>
      <td>HTTP</td>
    </tr>
    <tr>
      <td>40</td>
      <td>251</td>
      <td>198.51.100.15</td>
      <td>GRE</td>
    </tr>
    <tr>
      <td>50</td>
      <td>200</td>
      <td>01:23:45:67:89:ab</td>
      <td>Ethernet</td>
    </tr>
    <tr>
      <td>15</td>
      <td>212</td>
      <td>Null (end of path)  | None                        |
  +------+------+---------------------+-----------------------------+

              </artwork>
              </figure>
		   </t>
		   <t>Step 10: If path)</td>
      <td>None</td>
    </tr>
  </tbody>
</table>

           <ol spacing="normal" type="Step %d:" group="steps"
	       indent="9" start="10">
          <li anchor="step10">If the next hop is locally registered at the
		   nSFF, it forwards the packet (+NSH) to the service function instance, SF
		   instance using suitable IP/MAC methods for doing so.</t>
           <t>Step 11: Otherwise, so.</li>

          <li anchor="step11">If the next hop is not locally registered at the nSFF,
           the outgoing nSFF adds a new TE information to the packet and
           forwards the packet (+NSH+TE) to the next SFF or boundary node, as
           shown in Figure 7.</t>
		</list>
		</t> <xref target="fig-sfc-7" format="default"/>.</li>
        </ol>
      </section>
    </section>
    <section anchor="nsfffwd" title="nSFF numbered="true" toc="default">
      <name>nSFF Forwarding Operations"> Operations</name>
      <t>
		 This section outlines the realization of various nSFF
		 forwarding operations in Section 5.6. <xref target="steps" format="default"/>. Although the
		 operations in Section 5 <xref target="nop" format="default"/> utilize the notion of
		 name-based transactions in general, we exemplify the
		 operations here in Section 5 <xref target="nop" format="default"/> specifically for
		 HTTP-based transactions to ground our description into a
		 specific protocol for such name-based transaction. We will
		 refer to the various steps in each of the following sub-sections.
		 subsections.
      </t>
      <section anchor="proto" title="nSFF numbered="true" toc="default">
        <name>nSFF Protocol Layers"> Layers</name>
        <t>
		 Figure 8
 <xref target="fig-sfc-8" format="default"/> shows the protocol layers, layers based
 on the high-level architecture in Figure 5. <xref target="fig-sfc-5" format="default"/>.
        </t>
		<t>
        <figure anchor="fig-sfc-8" align="center" title="Protocol layers"> anchor="fig-sfc-8">
          <name>Protocol Layers</name>
          <artwork align="center">

+-------+ align="center" name="" type="" alt=""><![CDATA[+-------+  +------+----+                              +----+-----+
|App    |  |      |    |   +--------+                 |    |     |
|HTTP   |  |-------->  |   |  NR    |                 |nSFF----->|--
|TCP    |->| TCP  |nSFF|   +---/\---+                 |    | TCP | |
|IP     |  | IP   |    |       ||                     |    | IP  | |
+-------+  +------+----+  +---------+   +---------+   +----------+ |
|   L2  |  |      L2   |->|Forwarder|-->|Forwarder|-->|   L2     | |
+-------+  +------+----+  +---------+   +---------+   +----------+ |
  SF1           nSFF1                                     nSFF2    |
                                              +-------+            |
                                              | App   |/           |
                                              | HTTP  | -----------+
                                              | TCP   |\
                                              | IP    |
                                              | L2    |
                                              +-------+
                                                SF2

           </artwork>
                                                SF2]]></artwork>
        </figure>
       </t>
        <t>
	     The nSFF component here is shown as implementing a full
	     incoming/outgoing TCP/IP protocol stack towards the local service functions, SFs,
	     while implementing the nSFF-NR and nSFF-nSFF protocols based on
	     the descriptions in Section 6.2.3. <xref target="localfwd" format="default"/>.
        </t>
        <t>
		 For the exchange of HTTP-based service function SF transactions,
		 the nSFF terminates incoming TCP connections from as well as
		 outgoing TCP connections to local SFs, e.g., the TCP
		 connection from SF1 terminates at nSFF1, and nSFF1 may store
		 the connection information, information such as socket information. It
		 also maintains the mapping information for the HTTP request
		 such as originating SF, destination SF SF, and socket ID. nSFF1
		 may implement sending keep-alive messages over the socket to
		 maintain the connection to SF1. Upon arrival of an HTTP
		 request from SF1, nSFF1 extracts the HTTP Request and
		 forwards it towards the next node, node as outlined in Section 6.2. <xref target="nsffoperation" format="default"/>. Any returning response is mapped onto the suitable open
		 socket (for the original request) and send sent towards SF1.
        </t>
        <t>
	     At the outgoing nSFF2, the destination SF2/Host is identified
	     from the HTTP request message. If no TCP connection exists to the
	     SF2, a new TCP connection is opened towards the destination SF2
	     and the HTTP request is sent over said TCP connection. The nSFF2
	     may also save the TCP connection information (such as socket
	     information) and maintain the mapping of the socket information
	     to the destination SF2. When an HTTP response is received from
	     SF2 over the TCP connection, nSFF2 extracts the HTTP response,
	     which is forwarded to the next node. nSFF2 may maintain the TCP
	     connection through keep-alive messages.

        </t>
      </section>
      <section anchor="nsffoperation" title="nSFF Operations"> numbered="true" toc="default">
        <name>nSFF Operations</name>
        <t>
          In this section, we present three key aspects of operations for the
          realization of the steps in Section 5.6, namely <xref target="steps" format="default"/>, namely, (i) the registration
          of local SFs (for step 3 <xref target="step3" format="none">Step 3</xref> in Section 5.6), <xref target="steps"/>), (ii) the forwarding of SFC
          packets to and from local SFs (for step 3 Steps <xref
	  target="step3" format="none">3</xref>,  <xref target="step4"
	  format="none">4</xref>, and 4 as well as 10 <xref target="step10" format="none">10</xref> in Section 5.6),
          <xref target="steps" format="default"/>), (iii) the
	  forwarding to a remote SF (for steps 5, 6 Steps <xref target="step5"
	  format="none">5</xref>, <xref target="step6"
	  format="none">6</xref>, and 7 <xref target="step7"
	  format="none">7</xref> in Section 5.6) <xref target="steps"/>) and to the NR as well as (iv) for the lookup
          of a suitable remote SF (for step 7 <xref target="step7"
	  format="none">Step 7</xref> in Section 5.6). <xref target="steps" format="default"/>). We also cover
          aspects of maintaining local lookup information for reducing lookup
          latency and others other issues.
        </t>

        <section anchor="nsfnr" title="Forwarding numbered="true" toc="default">
          <name>Forwarding between nSFFs and nSFF-NR"> nSFF-NRs</name>
          <t>
          Forwarding between the distributed nSFFs as well as between nSFF nSFFs and NR
          NRs is realized over the operator network via a path-based
          approach. A path-based approach utilizes path information provided
          by the source of the packet for forwarding said packet in the
          network. This is similar to segment routing albeit differing in the
          type of information provided for such source-based forwarding, forwarding as
          described in this section. In this approach, the forwarding
          information to a remote nSFF or the NR is defined as a 'path identifier' "path
          identifier" (pathID) of a defined length where said "Length" length field
          indicates the full pathID length. The payload of the packet is
          defined by the various operations outlined in the following sub-sections,
          subsections, resulting in an overall packet being transmitted. With
          this, the generic forwarding format (GFF) for transport over the
          operator network is defined in Figure 9 <xref target="fig-sfc-9" format="default"/> with the length field
          defining the length of the pathID provided.
          </t>
		<t>
          <figure anchor="fig-sfc-9" align="center" title="Generic anchor="fig-sfc-9">
            <name>Generic Forwarding Format(GFF)"> Format (GFF)</name>
            <artwork align="center"> align="center" name="" type="" alt=""><![CDATA[
+---------+-----------------+------------------------//------------+
|         |                 |                       //             |
| Length  | Path ID         |  Payload             //              |
|(12 bit) | bits)|                 |                     //               |
+---------+-----------------+--------------------//----------------+

           </artwork>
+---------+-----------------+--------------------//----------------+]]></artwork>
          </figure>
		</t>
		<t>
         <list style="symbols">
          <t>
          <ul spacing="normal">
            <li>
            Length (12 bits): Defines the length of the pathID, i.e., up to 4096 bits
          </t>
		  <t>
          </li>
            <li>
		   Path ID (): Variable length field, Bit ID: Variable-length bit field derived from
		   IPv6 source and destination address
		  </t>

         </list>
        </t>
		  </li>
          </ul>

          <t>
		  For the pathID information, solutions such as those in <xref
		  target="Reed2016" /> format="default"/> can be used. Here, the
		  IPv6 source and destination addresses are used to realize a
		  so-called path-based forwarding from the incoming to the
		  outgoing nSFF or the NR. The forwarders in Figure 8 <xref
		  target="fig-sfc-8" format="default"/> are realized via SDN
		  (software-defined networking) switches, implementing an
		  AND/CMP operation based on arbitrary wildcard matching over
		  the IPv6 source and destination addresses, addresses as outlined in
		  <xref target="Reed2016" />. format="default"/>. Note that in the
		  case of using IPv6 address information for path-based
		  forwarding, the step of removing the transport encapsulation TE
		  at the outgoing nSFF in Figure 8 <xref target="fig-sfc-8"
		  format="default"/> is realized by utilizing the provided
		  (existing) IP header (which was used for the purpose of the
		  path-based forwarding in <xref target="Reed2016" />)
		  format="default"/>) for the purpose of next hop forwarding, next-hop forwarding
		  such as that of IP-based routing. As described in step 8 <xref
		  target="step8" format="none">Step 8</xref> of the extended
		  nSFF operations, this forwarding information is used as
		  traffic encapsulation. With the forwarding information
		  utilizing existing IPv6 information, IP headers are utilized
		  as TE in this case.

		  The next hop next-hop nSFF (see Figure 8) <xref target="fig-sfc-8"
		  format="default"/>) will restore the IP header of the packet
		  with the relevant IP information used to forward the SFC
		  packet to SF2 SF2, or it will create a suitable TE (Transport Encapsulation) information to
		  forward the information to another nSFF or boundary
		  node. Forwarding operations at the intermediary forwarders,
		  i.e., SDN switches, examine the pathID information through a flow matching
		  flow-matching rule in which a specific switch-local output
		  port is represented through the specific assigned bit
		  position in the pathID. Upon a positive match in said rule,
		  the packet is forwarded on said output port.
          </t>
          <t>
		  Alternatively, the solution in <xref target="BIER-MULTICAST"/> target="I-D.ietf-bier-multicast-http-response" format="default"/> suggests using a so-called BIER
		  (Binary Indexed Explicit Replication) underlay. Here, the
		  nSFF would be realized at the ingress to the BIER underlay,
		  injecting the SFC packet header (plus the NSH) header Network Service
		  Header (NSH)) with BIER-based traffic encapsulation into the
		  BIER underlay with each of the forwarders in Figure 8 <xref target="fig-sfc-8" format="default"/> being realized as a so-called
		  Bit-Forwarding Router (BFR) <xref target="RFC8279"/>. target="RFC8279" format="default"/>.
          </t>
          <section anchor="transport" title="Transport numbered="true" toc="default">
            <name>Transport Protocol Considerations"> Considerations</name>
            <t>
		  Given that the proposed solution operates at the 'named transaction'
		  "named-transaction" level, particularly for HTTP
		  transactions, forwarding between nSFFs and/or NR SHOULD NRs
		  <bcp14>SHOULD</bcp14> be implemented via a transport
		  protocol between nSFFs and/or NR NRs in order to provide
		  reliability, segmentation of large GFF packets, and flow
		  control, with the GFF in Figure 9 <xref target="fig-sfc-9"
		  format="default"/> being the basic forwarding format for
		  this.
            </t>
            <t>
		  Note that the nSFFs act as TCP proxies at ingress and
		  egress, thus terminating incoming and initiating outgoing
		  HTTP sessions to SFs.
            </t>
            <t>
		  Figure 10
		  <xref target="fig-sfc-10" format="default"/> shows the packet format being
		  used for the transmission of data, being adapted from the
		  TCP header. Segmentation of large transactions into single
		  transport protocol packets is realized through maintaining a 'Sequence number'.
		  "Sequence number". A 'Checksum' "Checksum" is calculated over a single
		  data packet with the ones-complement TCP checksum
		  calculation being used. The 'Window Size' "Window Size" field indicates
		  the current maximum number of transport packets that are
		  allowed in-flight by the egress nSFF. A data packet is sent
		  without 'Data' a "Data" field to indicate the end of the (e.g., HTTP)
		  transaction.
            </t>
            <t>
           Note that that, in order to support future named transactions based on
           other application protocols, such as CoAP, Constrained Application Protocol (CoAP), future versions of the
           transport protocol MAY <bcp14>MAY</bcp14> introduce a 'Type' "Type" field that indicates the
           type of application protocol being used between SF and nSFF with 'Type'
           "Type" 0x01 proposed for HTTP. This is being left for future study.
            </t>
		  <t>

            <figure anchor="fig-sfc-10" align="center" title="Transport protocol data packet format"> anchor="fig-sfc-10">
              <name>Transport Protocol Data Packet Format</name>
              <artwork align="center"> align="center" name="" type="" alt=""><![CDATA[
    +----------------------------------------------+
    |         16 bit bits       |        16 bit bits       |
    +----------------------------------------------+
    |              Sequence number                 |
    +----------------------------------------------+
    |       Checksum        |      Window Size     |
    +----------------------------------------------+
    |                      ...                     |
    |                Data (Optional)               |
    +----------------------------------------------+
           </artwork>
    +----------------------------------------------+]]></artwork>
            </figure>
		 </t>
            <t>
		  Given the path-based forwarding being used between nSFFs,
		  the transport protocol between nSFFs utilizes negative
		  acknowledgements from the egress nSFF towards the ingress
		  nSFF. The transport protocol NACK negative Acknowledgment
		  (NACK) packet carries the number
		  of NACKs as well as the specific sequence numbers being
		  indicated as lost in the 'NACK number' field(s), "NACK number" field(s) as shown in Figure 11.
		  <xref target="fig-sfc-11" format="default"/>.
            </t>
         <t>
            <figure anchor="fig-sfc-11" align="center" title="Transport protocol anchor="fig-sfc-11">
              <name>Transport Protocol NACK packet format"> Packet Format</name>
              <artwork align="center"> align="center" name="" type="" alt=""><![CDATA[
    +-----------------------+----------------------+
    |         16 bit bits       |        16 bit bits       |
    +----------------------------------------------+
    |    Number of NACKs    |                      +
    +----------------------------------------------+
    |                   NACK number                |
    +----------------------------------------------+
    +                ... NACK Number number               +
    +----------------------------------------------+
           </artwork>
    +----------------------------------------------+]]></artwork>
            </figure>
		</t>
            <t>
        If the indicated number of NACKs in a received NACK packet in non-zero, is
        nonzero, the ingress nSFF will retransmit all sequence numbers signalled
        signaled in the packet, packet while decreasing its congestion window size
        for future transmissions.
            </t>
            <t>
        If the indicated number of NACKs in a received NACK packet in is zero, it
        will indicate the current congestion window as being successfully (and
        completely) being transmitted, increasing the congestion window size
        if smaller than the advertised 'Window Size' "Window Size" in Figure 10. <xref target="fig-sfc-10" format="default"/>.
            </t>
            <t>
        The maintenance of the congestion window is subject to realization at
        the ingress nSFF and left for further study in nSFF realizations.
            </t>
          </section>
        </section>
        <section anchor="registration" title="SF Registration"> numbered="true" toc="default">
          <name>SF Registration</name>
          <t>
		   As outlined in step 3 Steps <xref target="step3"
	  format="none">3</xref> and 10 <xref target="step10"
	  format="none">10</xref> of Section 5.6, <xref target="steps" format="default"/>,
		   the nSFF needs to determine if the SF derived from the nNLM
		   Name-Based Network Locator (nNLM) is locally reachable or
		   whether the packet needs forwarding to be forwarded to a remote SFF. For
		   this, a registration mechanism is provided for such local
		   SF with the local nSFF. Two mechanisms can be used for
		   this:
          </t>
		  <t>
            1.

          <ol group="my_count" spacing="normal" indent="6">
            <li>
            SF-initiated: We assume that the SF registers its FQDN Fully Qualified
            Domain Name (FQDN) to the local nSFF. As local mechanisms, we
            foresee that either a REST-based Representational State Transfer (REST-based) interface over the link-local
            link or configuration of the nSFF (through configuration files or
            management consoles) can be utilized.  Such local registration event leads
            events lead to the nSFF to register registering the given FQDN with the NR in
            combination with a system-unique nSFF identifier that is being
            used for path computation path-computation purposes in the NR.  For the
            registration, the packet format in Figure 12 <xref target="fig-sfc-12"
            format="default"/> is used (inserted as the payload in the GFF of Figure 9
            <xref target="fig-sfc-9" format="default"/> with the pathID
            towards the NR).
          </t>
		  <t>
            </li>
           </ol>
<ul empty="true">

<li>
<ul empty="true" spacing="normal">

<li>
<ul empty="true">

<li>
          <figure anchor="fig-sfc-12" align="center" title="Registration packet format"> anchor="fig-sfc-12">
            <name>Registration Packet Format</name>
            <artwork align="center">

+---------+-----------------+------------------+ align="center" name="" type="" alt=""><![CDATA[+---------+------------------+----------------+
|         |                  |                |
|   R/D   |    hash(FQDN)    |    nSFF_ID     |
| (1 bit) |    (16 bit) bits)     |    (8 bit) bits)    |
+---------+-----------------+------------------+

           </artwork>
+---------+------------------+----------------+]]></artwork>
          </figure>
		  </t>
		  <t>
           <list style="symbols">
            <t>

 <ul spacing="normal">
   <li>
               R/D: 1 bit 1-bit length (0 for Register, 1 for De-register)
            </t>
		    <t>
		       Hash(FQDN): 16 bit Deregister)
            </li>
            <li>
	       hash(FQDN): 16-bit length for a hash over the FQDN of the SF
		    </t>
            <t>
		    </li>
            <li>
	       nSFF_ID: 8 bit 8-bit length for a system-unique identifier for the SFF related to the SF.
			</t>
           </list>
          </t>
		  <t> SF
	   </li>
          </ul>
   </li>
  </ul>

</li>

<li>

<ul empty="true">
<li>
We assume that the pathID towards the NR is known to the nSFF through configuration means.
		  </t>
          <t>
</li>

<li>
The NR maintains an internal table that associates the hash(FQDN), the nSFF_id information
information, as well as the pathID information being used for communication
between nSFF nSFFs and NR. NRs. The nSFF locally maintains a mapping of registered FQDNs
to IP addresses, addresses for the latter using link-local private IP addresses.
		  </t>
		  <t>
		    2.
</li>
</ul>

</li>

</ul>

</li>
</ul>
          <ol group="my_count" spacing="normal" indent="6">
            <li>
		    Orchestration-based: in In this mechanism, we assume that SFC
		    to be orchestrated and the chain being to be provided through an
		    orchestration template with FQDN information associated to
		    a compute/storage resource that is being deployed by the
		    orchestrator. We also assume knowledge at the orchestrator
		    of the resource topology. Based on this, the orchestrator
		    can now use the same REST-based protocol defined in option
		    1 to instruct the NR to register the given FQDN, as
		    provided in the template, at the nSFF it has identified as
		    being the locally servicing nSFF, provided as the
		    system-unique nSFF identifier.
		  </t>
		  </li>
          </ol>
        </section>
        <section anchor="localfwd" title="Local numbered="true" toc="default">
          <name>Local SF Forwarding  "> Forwarding</name>
          <t>
		   There are two cases of local SF forwarding, namely namely, the SF
		   sending an SFC packet to the local nSFF (incoming requests)
		   or the nSFF sending a packet to the SF (outgoing requests)
		   as part of steps 3 Steps <xref target="step3"
	  format="none">3</xref> and 10 <xref target="step10"
	  format="none">10</xref> in Section 5.6. <xref target="steps" format="default"/>. In the following,
		   we outline the operation for HTTP as an example named example-named
		   transaction.
          </t>
          <t>
            As shown in Figure 8, <xref target="fig-sfc-8" format="default"/>, incoming HTTP requests from SFs are
            extracted by terminating the incoming TCP connection at their
            local nSFFs at the TCP level. The nSFF MUST <bcp14>MUST</bcp14> maintain a mapping of
            open TCP sockets to HTTP requests (utilizing the URI of the
            request) for HTTP response association.
          </t>
          <t>
		    For outgoing HTTP requests, the nSFF utilizes the
		    maintained mapping of locally registered FQDNs to
		    link-local IP addresses (see Section 6.2.2 <xref target="registration" format="default"/>, option
		    1). Hence, upon receiving an SFC packet from a remote nSFF
		    (in step 9 <xref target="step9"
	  format="none">Step 9</xref> of Section 5.6), <xref target="steps" format="default"/>), the nSFF determines the local
		    existence of the SF through the registration mechanisms in Section 6.2.2.
		    <xref target="registration" format="default"/>. If said SF does exist locally, the HTTP
		    (+NSH) packet, after stripping the TE, is sent to the
		    local SF as step 10 <xref target="step10"
	  format="none">Step 10</xref> in Section 5.6 <xref target="steps" format="default"/> via a TCP-level
		    connection. Outgoing nSFF SHOULD nSFFs <bcp14>SHOULD</bcp14> keep TCP connections open
		    to local SFs for improving SFC packet delivery in
		    subsequent transactions.
          </t>
        </section>
        <section anchor="httpresp" title="Handling numbered="true" toc="default">
          <name>Handling of HTTP Responses"> Responses</name>
          <t>
		   When executing step 3 Steps <xref target="step3"
	  format="none">3</xref> and 10 <xref target="step10"
	  format="none">10</xref> in Section 5.6, <xref target="steps" format="default"/>, the SFC packet
		   will be delivered to the locally registered next hop. As
		   part of the HTTP protocol, responses to the HTTP request
		   will need to be delivered on the return path to the
		   originating nSFF (i.e., the previous hop). For this, the
		   nSFF maintains a list of link-local connection information,
		   e.g., sockets to the local SF and the pathID on which the
		   request was received. Once receiving the response, nSFF
		   consults the table to determine the pathID of the original
		   request, forming a suitable GFF-based packet to be returned
		   to the previous nSFF.
          </t>
          <t>
            When receiving the HTTP response at the previous nSFF, the nSFF
            consults the table of (locally) open sockets to determine the
            suitable local SF connection, mapping the received HTTP response
            URI to the stored request URI. Utilizing the found socket, the
            HTTP response is forwarded to the locally registered SF.
          </t>
        </section>
        <section anchor="remotefwd" title="Remote numbered="true" toc="default">
          <name>Remote SF Forwarding"> Forwarding</name>
          <t>
		   In steps 5, 6, 7, Steps <xref target="step5"
	  format="none">5</xref>, <xref target="step6"
	  format="none">6</xref>, <xref target="step7"
	  format="none">7</xref>, and 8 <xref target="step8"
	  format="none">8</xref> of Section 5.6, <xref target="steps" format="default"/>, an SFC
		   packet is forwarded to a remote nSFF based on the nNLM
		   information for the next hop of the nSFP. Section 6.2.5.1 <xref target="remotedisc" format="default"/> handles the case of suitable
		   forwarding information to the remote nSFF not existing,
		   therefore consulting the NR to obtain suitable information, while Section 6.2.5.2 information.
		   <xref target="maintain" format="default"/> describes the maintenance
		   of forwarding information at the local nSFF, while Section 6.2.5.3 nSFF.  <xref target="update" format="default"/> describes the update of stale forwarding
		   information. Note that the forwarding described in Section 6.2.1 <xref target="nsfnr" format="default"/> is used for the actual forwarding to the
		   various nSFF components.  Ultimately, Section 6.2.5.4 <xref target="fwd" format="default"/>
		   describes the forwarding to the remote nSFF via the
		   forwarder network.
          </t>
          <section anchor="remotedisc" title="Remote numbered="true" toc="default">
            <name>Remote SF Discovery"> Discovery</name>

            <t>
		    The nSFF communicates with the NR for two purposes, namely purposes: namely,
		    the registration and discovery of FQDNs. The packet format
		    for the former was shown in Figure 10 <xref target="fig-sfc-12" format="default"/> in Section 6.2.2,
		    <xref target="registration" format="default"/>,
		    while Figure 13 <xref target="fig-sfc-13" format="default"/> outlines the packet format for the
		    discovery request.
            </t>
		   <t>
            <figure anchor="fig-sfc-13" align="center" title="Discovery packet format"> anchor="fig-sfc-13">
              <name>Discovery Packet Format</name>
              <artwork align="center"> align="center" name="" type="" alt=""><![CDATA[
+--------------+-------------+ +--------+-----------------//--------+
|              |             | |        |                //         |
|   hash(FQDN) |  nSFF_ID    | | Length | pathID        //          |
|   (16 bit) bits)  |  (8 bit)    | bits)   | (4 bit)| |(4 bits)|              //           |
+--------------+-------------+ +--------+-------------//------------+
        Path Request                     Path Response

           </artwork> Response]]></artwork>
            </figure>
		  </t>

            <t>
           For Path Request:
            <list style="symbols">
            <t>
               Hash(FQDN): 16 bit
            </t>
            <ul spacing="normal">
              <li>
               hash(FQDN): 16-bit length for a hash over the FQDN of the SF
            </t>
		    <t>
            </li>
              <li>
	       nSFF_ID: 8 bit 8-bit length for a system-unique identifier for the SFF related to the SF
		    </t>
            </list>
		  </t>
		    </li>
            </ul>
            <t>
           For Path Response:
            <list style="symbols">
            <t>
               Length (4 bits): Defines
            </t>
            <ul spacing="normal">
              <li>
               Length: 4-bit length that defines the length of the pathID
            </t>
		    <t>
            </li>
              <li>
	       Path ID (): Variable length field, Bit ID: Variable-length bit field derived from IPv6 source
	       and destination address
		    </t>
            </list>
          </t>
		    </li>
            </ul>
            <t>
           A path to a specific FQDN is requested by sending a hash of the
           FQDN to the NR together with its nSFF_id, receiving as a response a
           pathID with a length identifier. The NR SHOULD <bcp14>SHOULD</bcp14> maintain a table of
           discovery requests that map discovered (hash of) FQDN to the
           nSFF_id that requested it and the pathID that is being calculated
           as a result of the discovery request.
            </t>
            <t>
            The discovery request for an FQDN that has not previously been
            served at the nSFF (or for an FQDN whose pathID information has
            been flushed as a result of the update operations in Section 6.2.5.3), <xref
            target="update" format="default"/>) results in an initial latency
            incurred by this discovery through the NR, while any SFC packet
            sent over the same SFP in a subsequent transaction will utilize
            the nSFF local nSFF-local mapping table. Such initial latency can be avoided
            by pre-populating prepopulating the FQDN-pathID mapping proactively as part of
            the overall orchestration procedure, e.g., alongside the
            distribution of the nNLM information to the nSFF.
            </t>
          </section>
          <section anchor="maintain" title="Maintaining numbered="true" toc="default">
            <name>Maintaining Forwarding Information at Local nSFF"> nSFF</name>

            <t>
		    Each nSFF MUST <bcp14>MUST</bcp14> maintain an internal table
		    that maps the (hash of the) FQDN information to a suitable pathID information.
		    pathID. As outlined in step 7 <xref target="step7"
		    format="none">Step 7</xref> of Section 5.6, <xref target="steps"
		    format="default"/>, if a suitable entry does not exist for
		    a given FQDN, the pathID information is requested with the
		    operations in Section 6.2.5.1 <xref target="remotedisc" format="default"/>
		    and the suitable entry is locally created upon receiving a
		    reply with the forwarding operation being executed as
		    described in Section 6.2.1. <xref target="nsfnr" format="default"/>.
            </t>
            <t>
            If such an entry does exist (i.e., step 6 <xref target="step6"
	  format="none">Step 6</xref> of Section 5.6) <xref target="steps" format="default"/>), the pathID
            is locally retrieved and used for the forwarding operation in Section 6.2.1.
            <xref target="nsfnr" format="default"/>.
            </t>
          </section>
          <section anchor="update" title="Updating numbered="true" toc="default">
            <name>Updating Forwarding Information at nSFF"> nSFF</name>
            <t>
	        The forwarding information maintained at each nSFF (see Section 6.2.5.2)
	        <xref target="maintain" format="default"/>) might need to be updated for three reasons:
		   <list style="symbols">
		   <t>
            </t>
            <ol spacing="normal" indent="6">
              <li>
			  An existing SF is no longer reachable: In this case,
			  the nSFF with which the SF is locally registered, de-registers registered
			  deregisters the SF explicitly at the NR by sending
			  the packet in Figure 10 <xref target="fig-sfc-10"
			  format="default"/> with the hashed FQDN and the R/D
			  bit set to 1 (for de-register).
		   </t>
		   <t> deregister).
		   </li>
              <li>
			 Another SF instance has become reachable in the
			 network (and therefore (and, therefore, might provide a better
			 alternative to the existing SF): in In this case, the NR
			 has received another packet with a format defined in Figure 11
			 <xref target="fig-sfc-11" format="default"/> but a different nSFF_id value.
		   </t>
		   <t>
		   </li>
              <li>
			  Links along paths might no longer be reachable: the The
			  NR might use a suitable southbound interface to
			  transport networks to detect link failures, which it
			  associates to the appropriate pathID bit position.
		   </t>
		   </list>
           </t>
		   </li>
            </ol>
            <t>
            For this purpose, the packet format in Figure 14 <xref target="fig-sfc-14" format="default"/> is sent from the
            NR to all affected nSFFs, using the generic format in Figure 9. <xref target="fig-sfc-9" format="default"/>.
            </t>
		   <t>
            <figure anchor="fig-sfc-14" align="center" title="Path update format"> anchor="fig-sfc-14">
              <name>Path Update Format</name>
              <artwork align="center"> align="center" name="" type="" alt=""><![CDATA[
+---------+-----------------+--------------//----+
|         |                 |             //     |
|   Type  |     #IDs        |  IDs       //      |
| (1 bit) |    (8 bit) bits)     |           //       |
+---------+-----------------+----------//--------+

           </artwork>
+---------+-----------------+----------//--------+]]></artwork>
            </figure>
		  </t>
          <t>
		   <list style="symbols">
            <t>
            <ul spacing="normal">
              <li>
               Type: 1 bit 1-bit length (0 for Nsff ID, 1 for Link ID)
            </t>
		    <t>
            </li>
              <li>
		       #IDs: 8 bit 8-bit length for number of IDs in the list
		    </t>
			<t>
		    </li>
              <li>
			  IDs: List of IDs (Nsff ID or Link ID)
			</t>
           </list>
          </t>
			</li>
            </ul>
            <t>
			The pathID to the affected nSFFs is computed as the
			binary OR over all pathIDs to those nSFF_ids affected
			where the pathID information to the affected nSFF_id
			values is determined from the NR-local table
			maintained in the registration/deregistration
			operation of Section 6.2.2. <xref target="registration" format="default"/>.
            </t>
            <t>
            The pathID may include the type of information being updated
            (e.g., node identifiers of leaf nodes or link identifiers for
            removed links). The node identifier itself may be a special
            identifier to signal "ALL NODES" as being affected.  The node
            identifier may signal changes to the network that are substantial
            (e.g., parallel link failures).  The node identifier may trigger
            (e.g., recommend) purging of the entire path table (e.g., rather
            than the selective removal of a few nodes only).
            </t>
            <t>
           It will include the information according to the type.  The
           included information may also be related to the type and length
           information for the number of identifiers being provided.
            </t>
            <t>
            In case cases 1 and 2, the Type bit is set to 1 (type nSFF_id) and the
            affected nSFFs are determined by those nSFFs that have previously
            sent SF discovery requests, utilizing the optional table mapping
            previously registered FQDNs to nSFF_id values. If no table mapping
            the (hash of) FQDN to nSFF_id is maintained, the update is sent to
            all nSFFs.  Upon receiving the path update at the affected nSFF,
            all appropriate nSFF-local mapping entries to pathIDs for the
            hash(FQDN) identifiers provided will be removed, leading to a new
            NR discovery request at the next remote nSFF forwarding to the
            appropriate FQDN.
            </t>
            <t>
            In case 3, the Type bit is set to 0 (type linkID) and the affected
            nSFFs are determined by those nSFFs whose discovery requests have
            previously resulted in pathIDs which that include the affected link,
            utilizing the optional table mapping previously registered FQDNs
            to pathID values (see Section 6.2.5.1). <xref target="remotedisc" format="default"/>). Upon receiving the node
            identifier information in the path update, the affected nSFF will
            check its internal table that maps FQDNs to pathIDs to determine
            those pathIDs affected by the link problems and remove path
            information that includes the received node identifier(s). For
            this, the pathID entries of said table are checked against the
            linkID values provided in the ID entry of the path update through
            a binary AND/CMP operation to check the inclusion of the link in
            the pathIDs to the FQDNs. If any pathID is affected, the
            FQDN-pathID entry is removed, leading to a new NR discovery
            request at the next remote nSFF forwarding to the appropriate
            FQDN.
            </t>
          </section>
          <section anchor="fwd" title="Forwarding numbered="true" toc="default">
            <name>Forwarding to remote nSFF"> Remote nSFF</name>
            <t>
		    Once step 5, 6, Steps <xref target="step5"
	  format="none">5</xref>, <xref target="step6"
	  format="none">6</xref>, and 7 <xref target="step7"
	  format="none">7</xref> in Section 5.6 <xref target="steps" format="default"/> are being executed, step 8
		    <xref target="step8"
	  format="none">Step 8</xref> finally sends the SFC packet to the remote nSFF,
		    utilizing the pathID returned in the discovery request (Section 6.2.5.1)
		    (<xref target="remotedisc" format="default"/>) or retrieved from the local pathID
		    mapping table. The SFC packet is placed in the payload of
		    the generic forwarding format in Figure 9 <xref target="fig-sfc-9" format="default"/> together with
		    the pathID pathID, and the nSFF eventually executes the forwarding
		    operations in Section 6.2.1. <xref target="nsfnr" format="default"/>.
            </t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document requests has no IANA actions.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations">

      <t>The operations in Sections 5 numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Sections <xref target="nop" format="counter"/> and 6 describes <xref target="nsfffwd" format="counter"/> describe the forwarding of SFC
      packets between named SFs based on URIs exchanged in HTTP messages.
	  For security considerations, TLS
      Security is sufficient needed to protect the communications between originating
      node and Nsff, Ssff, between one Nsff to and the next Nsff, and between Nsff to and
      destination. TLS is sufficient for this and <bcp14>SHOULD</bcp14> be used. The TLS
      handshake allows to determine the FQDN, which which, in turn turn, is enough for the
      service routing decision. Supporting TLS also allows the possibility of HTTPS based
      HTTPS-based transactions.</t>

    </section>

  </middle>

  <back>
    <references title="Normative References">
	  &rfc2119;
	  &rfc7665;
	  &rfc8174;
	  &rfc8300;
	  &rfc8279;
	</references>

    <references title="Informative References">

<!-- &I-D.ietf-bier-multicast-http-response; I-D Exists -->

<reference anchor='BIER-MULTICAST'>
<front>
<title>Applicability of BIER Multicast Overlay for Adaptive Streaming Services</title>

<author initials='D' surname='Trossen' fullname='Dirk Trossen'>
    <organization />
</author>

<author initials='A' surname='Rahman' fullname='Akbar Rahman'>
    <organization />
</author>

<author initials='C' surname='Wang' fullname='Chonggang Wang'>
    <organization />
</author>

<author initials='T' surname='Eckert' fullname='Toerless Eckert'>
    <organization />
</author>

<date month='June' day='28' year='2019' />

<abstract><t>HTTP Level multicast, using BIER,
      <t> It should be noted (per <xref target="RFC3986" format="default"/>) that what a URI resolves to is described not
necessarily stable.  This can allow flexibility in deployment, as a use case described in the BIER Use cases document.  HTTP Level Multicast is used
this document, but may also result in today's video streaming unexpected behavior and delivery services such as HLS, AR/VR etc., generally realized over IP Multicast as well as other use cases such could provide an
attack vector as software update delivery.  A realization the resolution of "HTTP Multicast" over "IP Multicast" is described for a URI could be "hi-jacked" resulting in
packets being steered to the video delivery use case.  IP multicast wrong place.  This could be particularly
important if the SFC is commonly used intended to send packets for IPTV services.  DVB and BBF processing at security
functions.  Such hi-jacking is also developing a reference architecture for IP Multicast service.  A few problems with IPMC, such as waste of transmission bandwidth, increase in signaling when there are few users are described.  Realization over BIER, through new attack surface introduced by using a BIER Multicast Overlay Layer, is described as an alternative.  How BIER Multicast Overlay operation improves over IP Multicast, such as reduction in signaling, dynamic creation of multicast groups to reduce signaling and bandwidth wastage is described.  We conclude with few next steps.</t></abstract>

</front>

<seriesInfo name='Work in Progress,' value='draft-ietf-bier-multicast-http-response-01' />
</reference>
separate NR.
</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-bier-multicast-http-response"
		      to="BIER-MULTICAST"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <!-- [rfced] [Reed2016] URL provided is correct - Also found URL https://ieeexplore.ieee.org/document/7511036  DOI: 10.1109/ICC.2016.7511036 &I-D.ietf-bier-multicast-http-response; I-D Exists -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bier-multicast-http-response.xml"/>

        <reference anchor="Reed2016" target="https://arxiv.org/pdf/1511.06069.pdf"> target="https://ieeexplore.ieee.org/document/7511036">
          <front>
            <title> Stateless multicast switching in software defined networks </title>
            <author initials="M.J." surname="Reed" /> surname="Reed"/>
            <author initials="M." surname="Al-Naday" /> surname="Al-Naday"/>
            <author initials="N." surname="Thomas" /> surname="Thomas"/>
            <author initials="D." surname="Trossen" /> surname="Trossen"/>
            <author initials="G." surname="Petropoulos"/>
            <author initials="S." surname="Spirou" /> surname="Spirou"/>
            <date month="May" year="2016"/>

 </front>
         <seriesInfo name="ICC" value="2016"/> name="DOI" value="10.1109/ICC.2016.7511036"/>
          <refcontent>IEEE ICC 2016</refcontent>
        </reference>

<!-- [rfced] [Schlinker2017] URL provided is correct - also found URL https://dl.acm.org/citation.cfm?id=3098853 -->

 <reference anchor="Schlinker2017" target="https://research.fb.com/wp-content/uploads/2017/08/sigcomm17-final177-2billion.pdf">
          <front>
            <title> Engineering Egress with Edge Fabric, Steering Oceans of Content to the World </title>
            <author initials="B." surname="Schlinker" /> surname="Schlinker"/>
            <author initials="H." surname="Kim" /> surname="Kim"/>
            <author initials="T." surname="Cui" /> surname="Cui"/>
            <author initials="E." surname="Katz-Bassett" /> surname="Katz-Bassett"/>
            <author initials="Harsha V." surname="Madhyastha" /> surname="Madhyastha"/>
            <author initials="I." surname="Cunha" /> surname="Cunha"/>
            <author initials="J." surname="Quinn" /> surname="Quinn"/>
            <author initials="S." surname="Hassan" /> surname="Hassan"/>
            <author initials="P." surname="Lapukhov" /> surname="Lapukhov"/>
            <author initials="H." surname="Zeng" /> surname="Zeng"/>
            <date month="August" year="2017"/>
          </front>
        <seriesInfo name="ACM SIGCOMM" value="2017"/>
          <refcontent>ACM SIGCOMM 2017</refcontent>
        </reference>

<!-- [rfced] [_3GPP_SBA] URL provided is correct - also found https://www.etsi.org/deliver/etsi_ts/129500_129599/129500/15.00.00_60/ts_129500v150000p.pdf -->

        <reference anchor="_3GPP_SBA" target="http://www.3gpp.org/ftp/Specs/html-info/29500.htm"> anchor="SDO-3GPP-SBA" target="https://www.3gpp.org/ftp/Specs/html-info/29500.htm">
          <front>
            <title> Technical Realization of Service Based Architecture </title>
            <seriesInfo name="3GPP" value="TS 29.500 V15.5.0"/>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="1" month="January" year="2018"/> month="September" year="2019"/>
          </front>
        <seriesInfo name="3GPP TS 29.500" value="0.4.0"/>
        <format type="" target="http://www.3gpp.org/ftp/Specs/html-info/29500.htm"/>
        </reference>

<!-- [rfced] [_3GPP_SBA_ENHANCEMENT] Link is to a zip file which I did not check  -->

        <reference anchor="_3GPP_SBA_ENHANCEMENT" target="http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_126_Montreal/Docs/S2-182904.zip"> anchor="SDO-3GPP-SBA-ENHANCEMENT" target="https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_126_Montreal/Docs/S2-182904.zip">
          <front>
            <title> New SID for Enhancements to the Service-Based 5G System Architecture </title>
            <seriesInfo name="3GPP" value="S2-182904"/>
            <author>
              <organization>3GPP</organization>
            </author>
            <date day="26" month="February" year="2018"/>
          </front>
        <seriesInfo name="3GPP S2-182904" value=""/>
        <format type="" target="http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_126_Montreal/Docs/S2-182904.zip"/>
        </reference>
      </references>
    </references>
    <section anchor="Ack" title="Acknowledgements" numbered="no"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
	   The authors would like to thank Dirk von Hugo and Andrew Malis for
	   their reviews and valuable comments.  We would also like to thank
	   Joel Halpern, the chair of the SFC WG, and Adrian Farrel for
	   guiding us through the IETF Independent Submission Editor (ISE)
	   path.
      </t>
    </section>
<!-- [rfced] This document uses both "Control Plane" (uppercase) and "control
plane" (lowercase) seemingly without a difference. Should these be made
uniform?

Original:
   ...may start with signaling in the Control Plane to setup user plane
   bearers.
   ...
   Part of the control plane, the Common Control Network Function (CCNF)...
-->

  </back>
</rfc>