rfc8677xml2.original.xml   rfc8677.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference. <?rfc sortrefs="yes"?>
RFC.2119.xml'> <?rfc compact="yes"?>
<!ENTITY rfc7665 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference. <?rfc subcompact="no"?>
RFC.7665.xml'> <?rfc private=""?>
<!ENTITY rfc8174 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference. <?rfc topblock="yes"?>
RFC.8174.xml'> <?rfc comments="no"?>
<!ENTITY rfc8300 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference. <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
RFC.8300.xml'> submissionType="independent" ipr="trust200902" category="info"
<!ENTITY rfc8279 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference. number="8677" obsoletes="" updates=""
RFC.8279.xml'> docName="draft-trossen-sfc-name-based-sff-07" xml:lang="en" tocInclude="tru
e" symRefs="true" sortRefs="true" version="3">
]> <!-- xml2rfc v2v3 conversion 2.34.0 -->
<rfc submissionType="independent" ipr="trust200902" category="info" number="XXXX
">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front> <front>
<title abbrev="Name Based SFF">Name-Based Service Function Forwarder <title abbrev="Name-Based SFF">Name-Based Service Function Forwarder
(nSFF) Component within Service Function Chaining (SFC) Framework</title> (nSFF) Component within a Service&nbsp;Function&nbsp;Chaining&nbsp;(SFC) Fra
mework</title>
<author fullname="Dirk Trossen" initials="D." surname="Trossen"> <seriesInfo name="RFC" value="8677"/>
<organization> InterDigital Europe, Ltd </organization> <author fullname="Dirk Trossen" initials="D." surname="Trossen">
<organization> InterDigital Europe, Ltd</organization>
<address> <address>
<postal> <postal>
<street>64 Great Eastern Street, 1st Floor</street> <street>64 Great Eastern Street, 1st Floor</street>
<city>London</city> <city>London</city>
<code>EC2A 3QR</code> <code>EC2A 3QR</code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>Dirk.Trossen@InterDigital.com</email> <email>Dirk.Trossen@InterDigital.com</email>
<uri> </uri> <uri> </uri>
</address> </address>
</author> </author>
<author initials="D." surname="Purkayastha" fullname="Debashish Purkayastha"
<author initials="D." surname="Purkayastha" fullname="Debashish Purkayast >
ha">
<organization>InterDigital Communications, LLC</organization> <organization>InterDigital Communications, LLC</organization>
<address> <address>
<postal> <postal>
<street>1001 E Hector St</street> <street>1001 E Hector St</street>
<city>Conshohocken</city> <city>Conshohocken</city>
<code></code> <code/>
<country>United States of America</country> <country>United States of America</country>
<region></region> <region/>
</postal> </postal>
<phone></phone> <phone/>
<email>Debashish.Purkayastha@InterDigital.com</email> <email>Debashish.Purkayastha@InterDigital.com</email>
<uri></uri> <uri/>
</address> </address>
</author> </author>
<author initials="A." surname="Rahman" fullname="Akbar Rahman"> <author initials="A." surname="Rahman" fullname="Akbar Rahman">
<organization>InterDigital Communications, LLC</organization> <organization>InterDigital Communications, LLC</organization>
<address> <address>
<postal> <postal>
<street>1000 Sherbrooke Street West</street> <street>1000 Sherbrooke Street West</street>
<city>Montreal</city> <city>Montreal</city>
<code></code> <code/>
<country>Canada</country> <country>Canada</country>
<region></region> <region/>
</postal> </postal>
<phone></phone> <phone/>
<email>Akbar.Rahman@InterDigital.com</email> <email>Akbar.Rahman@InterDigital.com</email>
<uri></uri> <uri/>
</address> </address>
</author> </author>
<date year="2019" month="November"/>
<area/>
<workgroup/>
<date year="2019" month="August" /> <keyword>service function, SF, SFF, nSFF, SFC, SFP, NSH, FQDN, 5G, NSSAI,
CCNF, NSSF, 3GPP</keyword>
<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>
<abstract> <abstract>
<t> <t>
Adoption of cloud and fog technology allows operators to deploy a single Adoption of cloud and fog technology allows operators to deploy a
"Service Function" to multiple "Execution locations". single "Service Function" (SF) to multiple "execution locations". The
The decision to steer traffic to a specific location may change freque decision to steer traffic to a specific location may change frequently
ntly based on load, proximity etc. Under the current based on load, proximity, etc. Under the current Service Function
SFC framework, steering traffic dynamically to the different execution Chaining (SFC) framework, steering traffic dynamically to the different
end points require a specific 're-chaining', i.e., execution endpoints requires a specific "rechaining", i.e., a change in
a change in the service function path reflecting the different IP endp the service function path reflecting the different IP endpoints to be
oints to be used for the new execution points. used for the new execution points. This procedure may be complex and
This procedure may be complex and take time. In order to simplify re-c take time. In order to simplify rechaining and reduce the time to
haining and reduce the time to complete the procedure, complete the procedure, we discuss separating the logical Service
we discuss separating the logical Service Function Path from the speci Function Path (SFP) from the specific execution endpoints. This can be
fic execution end points. This can be done by identifying done by identifying the SFs using a name rather than a
the Service Functions using a name rather than a routable IP endpoint routable IP endpoint (or Layer 2 address). This document describes the
(or Layer 2 address). This document describes the necessary necessary extensions, additional functions, and protocol details in SFF
extensions, additional functions and protocol details in SFF (Service (Service Function Forwarder) to handle name-based relationships.
Function Forwarder) to handle name based relationships. </t>
</t> <t>
This document presents InterDigital's approach to name-based SFC.
<t> It does not represent IETF consensus and is presented here so that
This document presents InterDigital's approach to name-based service f the SFC community may benefit from considering this mechanism and
unction chaining. It does not represent IETF consensus the possibility of its use in the edge data centers.
and is presented here so that the SFC community may benefit from consi
dering this mechanism and the possibility of its use in
the edge data centers.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
The requirements on today's networks are very diverse, enabling
multiple use cases such as the Internet of Things (IoT), Content
Distribution, Gaming, and Network functions such as Cloud Radio Access
Network (RAN) and 5G control planes based on a Service-Based
Architecture (SBA). These services are deployed, provisioned, and manage
d
using 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 provision
virtualized service endpoints through, e.g., container-based
techniques. This creates the ability to dynamically compose new
services from existing services. It also allows an operator to move a
service instance in response to user mobility or to change resource
availability. When moving from a purely "distant cloud" model to one
of localized micro data centers with regional, metro, or even street
level, often called "edge" data centers, such virtualized service
instances can be instantiated in topologically different locations
with the overall "distant" data center now being transformed into a
network of distributed ones.
<section anchor="introduction" title="Introduction"> The reaction of content providers, like Facebook, Google, NetFlix, and others,
is not just to rely on deploying content servers at the ingress of the
customer network. Instead, the trend is towards deploying multiple 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> <t>
The requirements on today's networks are very diverse, enabling multiple The Service Function Chaining (SFC) framework <xref target="RFC7665"
use cases such as IoT, Content Distribution, Gaming and Network functions such format="default"/> allows network operators as well as service
as Cloud RAN and 5G control planes based on a service-based architecture. These providers to compose new services by chaining individual "service
services are deployed, provisioned and managed using Cloud based techniques as s functions". Such chains are expressed through explicit relationships
een in the IT world. Virtualization of compute and storage resources is at the h of functional components (the SFs) realized through their direct Layer
eart of providing (often web) services to end users with the ability to quickly 2 (e.g., Media Access Control (MAC) address) or Layer 3 (e.g., IP
provisioning such virtualized service endpoints through, e.g., container based t address) relationship as defined through next-hop information that is
echniques. This creates a dynamicity with the capability to dynamically compose being defined by the network operator. See <xref target="Bkgnd"
new services from available services as well as move a service instance in respo format="default"/> for more background on SFC.
nse to user mobility or resource availability where desirable. When moving from
a pure 'distant cloud' model to one of localized micro data centers with regiona
l, metro or even street level, often called 'edge' data centers, such virtualize
d service instances can be instantiated in topologically different locations wit
h the overall 'distant' data center now being transformed into a network of dist
ributed ones. The reaction of content providers, like Facebook, Google, NetFlix
and others, are not just relying on deploying content server at the ingress of t
he customer network. Instead the trend is towards deploying multiple POPs within
the customer network, those POPs being connected through proprietary mechanisms
<xref target="Schlinker2017" /> to push content.
</t> </t>
<t> <t>
The Service Function Chaining (SFC) framework <xref target="RFC7665" /> In a dynamic service environment of distributed data centers such as
allows network operators as well as service providers to compose new services by the one outlined above, with the ability to create and recreate
chaining individual "Service Functions (SFs)". Such chains are expressed throug service endpoints frequently, the SFC framework requires
h explicit relationships of functional components (the service functions), reali reconfiguring the existing chain through information based on the new
zed through their direct Layer 2 (e.g., MAC address) or Layer 3 (e.g., IP addres relationships, causing overhead in a number of components,
s) relationship as defined through next hop information that is being defined by specifically the orchestrator that initiates the initial SFC and any
the network operator, see Section 4 for more background on SFC. possible reconfiguration.
</t> </t>
<t> <t>
In a dynamic service environment of distributed data centers as the one
outlined above, with the ability to create and recreate service endpoints frequ This document describes how such changes can be handled without involving the
ently, the SFC framework requires to reconfigure the existing chain through info initiation of new and reconfigured SFCs. This is accomplished by lifting the
rmation based on the new relationships, causing overhead in a number of componen chaining relationship from Layer 2 and Layer 3 information to that of SF
ts, specifically the orchestrator that initiates the initial service function ch "names", which can, for instance, be expressed as URIs.
ain and any possible reconfiguration.
In order to transparently support such named relationships, we propose to
embed the necessary functionality directly into the Service Function Forwarder
(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 (SFP), while enabling the selection
of 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> </t>
</section>
<section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name>
<t> <t>
This document describes how such changes can be handled without involvin The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
g the initiation of new and reconfigured SFCs by lifting the chaining relationsh IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
ip from Layer 2 and 3 information to that of service function 'names', such as n NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
ames for instance being expressed as URIs. In order to transparently support suc RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
h named relationships, we propose to embed the necessary functionality directly "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
into the Service Function Forwarder (SFF), as described in <xref target="RFC7665 be interpreted as
" />). With that, the SFF described in this document allows for keeping an exist described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref tar
ing SFC intact, as described by its service function path (SFP), while enabling get="RFC8174" format="default"/>
the selection of an appropriate service function endpoint(s) during the traversa when, and only when, they appear in all capitals, as shown here.
l 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> </t>
</section> </section>
<section anchor="Use_Case" numbered="true" toc="default">
<name>Example Use Case: 5G Control-Plane Services</name>
<t>
We exemplify the need for chaining SFs at the level
of a service name through a use case stemming from the current
3GPP Release 16 work on Service Based Architecture (SBA) <xref target
="SDO-3GPP-SBA" format="default"/>, <xref target="SDO-3GPP-SBA-ENHANCEMENT" form
at="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 protocol for exchanging suitable service
requests <xref target="SDO-3GPP-SBA" format="default"/>. With this in
mind, the
exchange between, for example, the 3GPP-defined (Rel. 15) Session
Management Function (SMF) and the Access and Mobility Management
Function (AMF) in a 5G control plane is being described as a set
of web-service-like requests that are, in turn, embedded into HTTP
requests. Hence, interactions in a 5G control plane can be
modeled based on SFCs where the relationship
is between the specific (IP-based) SF endpoints that
implement the necessary service endpoints in the SMF and AMF. The
SFs are exposed through URIs with work ongoing to
define the used naming conventions for such URIs.
</t>
<section anchor="terminology" title="Terminology"> <t>
<t> This move from a network function model (in pre-Release 15
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL systems of 3GPP) to a service-based model is motivated through
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", the proliferation of data-center operations for mobile network
"MAY", and "OPTIONAL" in this document are to be interpreted as control-plane services. In other words, typical IT-based methods
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> to service provisioning, particularly that of virtualization of
when, and only when, they appear in all capitals, as shown here. entire compute resources, are envisioned to being used in future
</t> operations of mobile networks. Hence, operators of such future
mobile networks desire to virtualize SF endpoints and direct
(control-plane) traffic to the most appropriate current service
instance in the most appropriate (local) data center. Such a data
center is envisioned as being interconnected through a
software-defined wide area network (SD-WAN). "Appropriate" here
can be defined by topological or geographical proximity of the
service initiator to the 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
operation is extended with the trend towards regionalization of
load through a "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" 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 "rechaining" of the SFC since the
relationships in said SFC are defined through Layer 2 or Layer 3
identifiers, which, in 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>
</section> <t>
Hence, when a traffic flow is forwarded over a service chain
expressed as an SFC-compliant SFP, packets in the traffic flow are
processed by the various SF instances, with each SF instance applying
an SF prior to forwarding the packets to the next
network node.
<section anchor="Use_Case" title="Example Use Case: 5G Control-Plane Service It is a service-layer concept and can possibly work over any Virtual network
s"> layer and corresponding underlay network. The underlay network can be IP or
<t> alternatively any Layer 2 technology.
We exemplify the need for chaining service functions at the level of
a service name through a use case stemming from the current 3GPP Rel 16 work on At the service layer, SFs are identified using a path identifier
Service Based Architecture (SBA) <xref target="_3GPP_SBA"/>, <xref target="_3GPP and an index. Eventually, this index is translated to an IP address (or MAC
_SBA_ENHANCEMENT"/>. In this work, mobile network control planes are proposed to address) of the host where the SF is running. Because of this,
be realized by replacing the traditional network function interfaces with a ful any change-of-service function instance is likely to require a change of the
ly service-based one. HTTP was chosen as the application layer protocol for exch path information since either the IP address (in the case of changing the
anging suitable service requests <xref target="_3GPP_SBA"/>. With this in mind, execution from one data center to another) or MAC address will change due to
the exchange between, say the 3GPP (Rel. 15) defined Session Management Function the newly selected SF instance.
(SMF) and the Access and Mobility management Function (AMF) in a 5G control pla
ne is being described as a set of web service like requests which are in turn em
bedded into HTTP requests. Hence, interactions in a 5G control plane can be mode
lled based on service function chains where the relationship is between the spec
ific (IP-based) service function endpoints that implement the necessary service
endpoints in the SMF and AMF. The service functions are exposed through URIs wit
h work ongoing to define the used naming conventions for such URIs.
</t> </t>
<t>
This move from a network function model (in pre-Rel 15 systems of 3G
PP) to a service-based model is motivated through the proliferation of data cent
er operations for mobile network control-plane services. In other words, typical
IT-based methods to service provisioning, in particular that of virtualization
of entire compute resources, are envisioned to being used in future operations o
f mobile networks. Hence, operators of such future mobile networks desire to vir
tualize service function endpoints and direct (control-plane) traffic to the mos
t appropriate current service instance in the most appropriate (local) data cent
re, such data centre envisioned as being interconnected through a software-defin
ed wide area network (SD-WAN). 'Appropriate' here can be defined by topological
or geographical proximity of the service initiator to the service function endpo
int. Alternatively, network or service instance compute load can be used to dire
ct a request to a more appropriate (in this case less loaded) instance to reduce
possible latency of the overall request. Such data center centric operation is
extended with the trend towards regionalization of load through a 'regional offi
ce' approach, where micro data centers provide virtualizable resources that can
be used in the service execution, creating a larger degree of freedom when choos
ing the 'most appropriate' service endpoint for a particular incoming service re
quest.
</t>
<t>
While the move to a service-based model aligns well with the framewo
rk of SFC, choosing the most appropriate service instance at runtime requires so
-called 're-chaining' of the SFC since the relationships in said SFC are defined
through Layer 2 or 3 identifiers, which in turn are likely to be different if t
he 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), packets in the traffic flow are
processed by the various service function instances, with each service function
instance applying a service function prior to forwarding the packets to the nex
t network node. It is a Service layer concept and can possibly work over any Vir
tual network layer and an Underlay network, possibly IP or any Layer 2 technolog
y. At the service layer, Service Functions are identified using a path identifie
r and an index. Eventually this index is translated to an IP address (or MAC add
ress) of the host where the service function is running. Because of this, any ch
ange of service function instance is likely to require a change of the path info
rmation since either IP address (in the case of changing the execution from one
data centre to another) or MAC address will change due to the newly selected ser
vice function instance.
</t>
<t>
Returning to our 5G control-plane example, a user's connection request
to access an application server in the internet may start with signaling in the
Control Plane to setup user plane bearers. The connection request may flow throu
gh service functions over a service chain in the Control plane, as deployed by n
etwork operator. Typical SFs in a 5G control plane may include "RAN termination
/ processing", "Slice Selection Function", "AMF" and "SMF". A Network Slice is a
complete logical network including Radio Access Network (RAN) and Core Network
(CN). Distinct RAN and Core Network Slices may exist. A device may access multip
le Network Slices simultaneously through a single RAN. The device may provide Ne
twork Slice Selection Assistance Information (NSSAI) parameters to the network t
o help it select a RAN and a Core network part of a slice instance. Part of the
control plane, the Common Control Network Function (CCNF), the Network Slice Sel
ection Function (NSSF) is in charge of selecting core Network Slice instances. T
he Classifier, as described in SFC architecture, may reside in the user terminal
or at the eNB. These service functions can be configured to be part of a Servi
ce Function Chain. We can also say that some of the configurations of the Servic
e Function Path may change at the execution time. For example, the SMF may be re
located as user moves and a new SMF may be included in the Service Function Path
based on user location. The following diagram in Figure 1 shows the example Ser
vice Function Chain described here.
</t>
<t>
<figure anchor="fig-sfc-1" align="center" title="Mapping SFC onto Se
rvice Function Execution Points along a Service Function Path">
<artwork align="center">
+------+ +---------+ +-----+ +-----+ <t> Returning to our 5G control-plane example, a user's connection request
to
access an application server in the Internet may start with signaling in the
control plane to set up user-plane bearers. The connection request may flow
through SFs over a service chain in the control plane, as
deployed by a network operator. Typical SFs in a 5G control plane may include
"RAN termination / processing", "Slice Selection Function", "AMF", and
"SMF". A "Network Slice" is a complete logical network including Radio Access
Network (RAN) and Core Network (CN). Distinct RAN and 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
part of a slice instance.
Part of the control plane, the Common Control Network Function (CCNF),
includes the Network Slice Selection Function (NSSF), which is in charge of
selecting core Network Slice instances.
The classifier, as described in SFC architecture, may reside in the user
terminal or at the Evolved Node B (eNB). These SFs can be
configured to be part of an SFC. We can also say that some
of the configurations of the 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 SFP based on user location. <xref
target="fig-sfc-1" format="default"/> shows the example SFC described here.
</t>
<figure anchor="fig-sfc-1">
<name>Mapping SFC onto Service Function Execution Points along a Service
Function Path</name>
<artwork align="center" name="" type="" alt=""><![CDATA[+------+ +----
-----+ +-----+ +-----+
| User | | Slice | | | | | | User | | Slice | | | | |
| App |-->| Control |->| AMF |-->| SMF |--> | App |-->| Control |->| AMF |-->| SMF |-->
| Fn | | Function| | | | | | Fn | | Function| | | | |
+------+ +---------+ +-----+ +-----+ +------+ +---------+ +-----+ +-----+]]></artwork>
</figure>
</section>
<section anchor="Bkgnd" numbered="true" toc="default">
<name>Background</name>
<t>
<xref target="RFC7665" format="default"/> describes an architecture
for the specification, creation, and ongoing maintenance of 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" numbered="true" toc="default">
<name>Relevant Part of SFC Architecture</name>
<t>
</artwork> The SFC architecture, as defined in <xref target="RFC7665"
</figure> format="default"/>, describes architectural components such
as SF, classifier, and SFF. It describes the 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 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 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" numbered="true" toc="default">
<name>Challenges with Current Framework</name>
<t>
As outlined in previous sections, the SFP defines
an ordered sequence of specific SF instances being
used for the interaction between initiator and SFs
along the SFP. These SFs are addressed by IP (or any
L2/MAC) addresses and defined as 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 SF
instances so that these (now virtualized) 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 SF along the SFP will require a
change of the SFP information (since the new SF execution
point likely carries different IP or L2 address information) and
possibly even the next-hop information in SFFs along the SFP. In case
the availability of new 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 info) will need to go through suitable
management cycles.
</t> </t>
</section>
<section anchor="Bkgnd" title="Background">
<t>
<xref target="RFC7665" /> describes an architecture for the specificat
ion, creation and ongoing maintenance of Service Function Chains (SFCs). It inc
ludes architectural concepts, principles, and components used in the constructio
n of composite services through deployment of SFCs. In the following, we outline
the parts of this SFC architecture relevant for our proposed extension, followe
d by the challenges with this current framework in the light of our example use
case.
</t>
<section anchor="Arch" title="Relevant Part of SFC Architecture">
<t> <t>
SFC Architecture, as defined in <xref target="RFC7665" />, desc
ribes architectural components such as Service Function (SF), Classifier, and Se
rvice Function Forwarder (SFF). It describes the Service Function Path (SFP) as
the logical path of an SFC. Forwarding traffic along such SFP is the responsibil
ity of the SFF. For this, the SFFs in a network maintain the requisite SFP forwa
rding information. Such SFP forwarding information is associated with a service
path identifier (SPI) that is used to uniquely identify an SFP. The service fo
rwarding state is represented by the Service Index (SI) and enables an SFF to id
entify which SFs of a given SFP should be applied, and in what order. The SFF al
so has information that allows it to forward packets to the next SFF after apply
ing local service functions.
</t>
<t>
The operational steps to forward traffic are then as follows: Tr
affic 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 encapsu
lation. After SF processing, the traffic is returned to the 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 enca
psulates 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 with Current Framework">
<t>
As outlined in previous section, the Service Function Path defines an
ordered sequence of specific Service Functions instances being used for the inte
raction between initiator and service functions along the SFP. These service fun
ctions are addressed by IP (or any L2/MAC) addresses and defined as next hop inf
ormation in the network locator maps of traversing SFF nodes.
</t>
<t>
As outlined in our use case, however, the service provider may want to pr
ovision SFC nodes based on dynamically spun up service function instances so tha
t these (now virtualized) service functions can be reached in the SFC domain usi
ng the SFC underlay layer.
</t>
<t>
Following the original model of SFC, any change in a specific execution p
oint for a specific Service Function along the SFP will require a change of the
SFP information (since the new service function execution point likely carries d
ifferent IP or L2 address information) and possibly even the Next Hop informatio
n in SFFs along the SFP. In case the availability of new service function instan
ces is rather dynamic (e.g., through the use of container-based virtualization t
echniques), the current model and realization of SFC could lead to reducing the
flexibility of service providers and increasing the management complexity incurr
ed 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 info) w
ill need to go through suitable management cycles.
</t>
<t>
To address these challenges through a suitable solution, we identify the following requirements: To address these challenges through a suitable solution, we identify the following requirements:
<list style="symbols"> </t>
<t> <ul spacing="normal">
Relations between Service Execution Points MUST be abst <li>
racted so that, from an SFP point of view, the Logical Path never changes. Relations between Service Execution Points <bcp14>MUST<
</t> /bcp14> be
<t> abstracted so that, from an SFP point of view, the
Deriving the Service Execution Points from the abstract Logical Path never changes.
SFP SHOULD be fast and incur minimum delay. </li>
</t> <li>
<!-- [rfced] In the following sentence, should RFC 2119 keyword "SHOULD not" be Deriving the Service Execution Points from the
"SHOULD NOT"? abstract SFP <bcp14>SHOULD</bcp14> be fast and incur mi
nimum delay.
</li>
Original: <li>
Identification of the Service Execution Points SHOULD not use a combination Identification of the Service Execution Points
of Layer 2 or Layer 3 mechanisms. <bcp14>SHOULD NOT</bcp14> use a combination of Layer 2
<t> or Layer 3
Identification of the Service Execution Points SHOULD n mechanisms.
ot use a combination of Layer 2 or Layer 3 mechanisms. </li>
</t> </ul>
</list> <t>
</t> The next section outlines a solution to address the issue, allowing for
<t> keeping SFC information (represented in its SFP) intact while
The next section outlines a solution to address the issue, allowing for k addressing the desired flexibility of the service provider.
eeping SFC information (represented in its SFP) intact while addressing the desi </t>
red flexibility of the service provider. </section>
</t> </section>
</section> <section anchor="nop" numbered="true" toc="default">
</section> <name>Name-Based Operation in SFF</name>
<section anchor="General" numbered="true" toc="default">
<name>General Idea</name>
<t>
The general idea is two pronged. Firstly, we elevate the definition
of an SFP onto the level of "name-based
interactions" rather than limiting SFPs to Layer 2 or Layer 3 informat
ion
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 as defined in <xref target="RFC7665"
format="default"/>. In the following sections, we outline these two
components of our solution.
</t>
<section anchor="nop" title="Name-Based Operation in SFF"> <t>
<section anchor="General" title="General Idea"> If the next-hop information in the Network Locator Map (NLM) is
<t> described using an L2/L3 identifier, the name-based SFF (nSFF) may
The general idea is two-pronged. Firstly, we elevate the definition of operate as described for (traditional) SFF, as defined in <xref
a Service Function Path onto the level of 'name-based interactions' rather than target="RFC7665" format="default"/>. On the other hand, if the
limiting SFPs to Layer 3 or Layer 2 information only. Secondly, we extend the o next-hop information in the NLM is described as a name, then the
perations of the SFF to allow for forwarding decisions that take into account su nSFF operates as described in the following sections.
ch name-based interaction while remaining backward compatible to the current SFC </t>
architecture, as defined in <xref target="RFC7665" />. In the following section <t>
s, we outline these two components of our solution.
</t>
<t>
If the next hop information in the Network Locator Map (NLM) is descr
ibed using L2/L3 identifier, the name-based SFF (nSFF) may operate as described
for [traditional] SFF, as defined in <xref target="RFC7665" />. On the other ha
nd, if the 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 solut ion. In the following sections, we outline the two components of our solut ion.
</t> </t>
</section> </section>
<section anchor="nsfp" title="Name-Based Service Function Path (nSFP)"> <section anchor="nsfp" numbered="true" toc="default">
<t> <name>Name-Based Service Function Path (nSFP)</name>
The existing SFC framework is defined in <xref target="RFC7665" / <t>
>. Section 4 outlines that the SFP information is representing path information The existing SFC framework is defined in <xref
based on Layer 2 or 3 information, i.e., MAC or IP addresses, causing the aforem target="RFC7665" format="default"/>. <xref target="Bkgnd"
entioned frequent adaptations in cases of execution point changes. Instead, we i format="default"/> outlines that the SFP information is
ntroduce the notion of a "name-based service function path (nSFP)". representing path information based on Layer 2 or Layer 3
</t> information, i.e., MAC or IP addresses, causing the
<t> aforementioned frequent adaptations in cases of
In today's networking terms, any identifier can be treated as a name b execution-point changes. Instead, we introduce the notion of a
ut we will illustrate the realization of a "Name based SFP" through extended SFF "name-based Service Function Path (nSFP)".
operations (see Section 6) based on URIs as names and HTTP as the protocol of e </t>
xchanging information. Here, URIs are being used to name for a Service Function <t>
along the nSFP. It is to be noted that the Name based SFP approach is not restri In today's networking terms, any identifier can be treated as a name,
cted to HTTP (as the protocol) and URIs (as next hop identifier within the SFP). but we will illustrate the realization of a "Name-based SFP" through
Other identifiers such as an IP address itself can also be used and are interpr extended SFF operations (see <xref target="nsfffwd" format="default"/>)
eted as a 'name' in the nSFP. IP addresses as well as fully qualified domain nam based on URIs as names and
es forming complex URIs (uniform resource identifiers), such as www.example.com/ HTTP as the protocol of exchanging information. Here, URIs are being
service_name1, are all captured by the notion of 'name' in this document. used to name for an SF along the nSFP. Note
that the nSFP approach is not restricted to HTTP (as the
protocol) and URIs (as next-hop identifier within the SFP). Other
identifiers such as an IP address itself can also be used and are
interpreted as a "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" in this document.
</t> </t>
<t> <t>
Generally, nSFPs are defined as an ordered sequence of the "name" of Ser Generally, nSFPs are defined as an ordered sequence of the "name" of
vice Functions (SF) and a typical name-based Service Function Path may look like SFs, and a typical nSFP may look like: 192.0.x.x -&gt; www.example.com
: -&gt; www.example2.com/service1 -&gt; www.example2.com/service2.
192.0.x.x -> www.example.com -> www.example2.com/service1 -> www.examp </t>
le2.com/service2. <t>
</t> Our use case in <xref target="Use_Case" format="default"/> can then be
<t> represented as an ordered named sequence. An example for a session
Our use case in Section 3 can then be represented as an ordered named se initiation that involves an authentication procedure, this could look
quence. An example for a session initiation that involves an authentication proc like 192.0.x.x -&gt; smf.example.org/session_initiate -&gt;
edure, this could look like amf.example.org/auth -&gt; smf.example.org/session_complete -&gt;
192.0.x.x -> smf.example.org/session_initiate -> amf.example.org/auth -> 192.0.x.x. (Note that this example is only a conceptual one since the
smf.example.org/session_complete -> 192.0.x.x. exact nature of any future SBA-based exchange of 5G control-plane
[Note that this example is only a conceptual one, since the exact functions is yet to be defined by standardization bodies such as
nature of any future SBA-based exchange of 5G control-plane functions is yet to 3GPP).
be defined by standardization bodies such as 3GPP]. </t>
</t> <t>
<t> In accordance with our use case in <xref target="Use_Case" format="defau
In accordance with our use case in Section 3, any of these named service lt"/>, any of these named
s can potentially be realized through more than one replicated SF instances. Thi services can potentially be realized through more than one replicated
s leads to make dynamic decision on where to send packets along the SAME service SF instance. This leads to making dynamic decisions on where to send
function path information, being provided during the execution of the SFC. Thr packets along the SAME SFP information, being
ough elevating the SFP onto the notion of name-based interactions, the SFP will provided during the execution of the SFC. Through elevating the SFP
remain the same even if those specific execution points change for a specific se onto the notion of name-based interactions, the SFP will remain the
rvice interaction. same even if those specific execution points change for a specific
</t> service interaction.
<t> </t>
The following diagram in Figure 2, describes this name-based SFP concept <t>
and the resulting mapping of those named interactions onto (possibly) replicate The following diagram in <xref target="fig-sfc-2" format="default"/> des
d instances. cribes this nSFP
<figure anchor="fig-sfc-2" align="center" title="Mapping SFC ont concept and the resulting mapping of those named interactions onto
o Service Function Execution Points along a Service Function Path based on Virtu (possibly) replicated instances.
alized Service Function Instance"> </t>
<artwork align="center"> <figure anchor="fig-sfc-2">
+---------------------------------------------------------------+ <name>Mapping SFC onto Service Function Execution Points along a Servi
|SERVICE LAYER | ce Function Path Based on Virtualized Service Function Instance</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ +------------
---------------------------------------------------+
|Service Layer |
| 192.0.x.x --> www.example.com --> www.example2.com --> | | 192.0.x.x --> www.example.com --> www.example2.com --> |
| || || | | || || |
+----------------------||--------------||-----------------------+ +----------------------||--------------||-----------------------+
|| || || ||
|| || || ||
+----------------------||--------------||-----------------------+ +----------------------||--------------||-----------------------+
| Underlay network \/ \/ | |Underlay Network \/ \/ |
| +--+ +--+ +--+ +--+ +--+ +--+ | | +--+ +--+ +--+ +--+ +--+ +--+ |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| +--+ +--+ +--+ +--+ +--+ +--+ | | +--+ +--+ +--+ +--+ +--+ +--+ |
| Compute and Compute and | | Compute and Compute and |
| storage nodes storage nodes | | storage nodes storage nodes |
+---------------------------------------------------------------+ +---------------------------------------------------------------+]]></artwork>
</figure>
</artwork> </section>
</figure> <section anchor="nnlm" numbered="true" toc="default">
</t> <name>Name-Based Network Locator Map (nNLM)</name>
</section> <t>
<section anchor="nnlm" title="Name-Based Network Locator Map (nNLM)"> In order to forward a packet within an nSFP, we need to
<t> extend the NLM as defined in <xref target="RFC8300" format="default"/>
In order to forward a packet within a name-based SFP, we need to extend with the ability to consider name relations based on URIs as well as
the network locator map as defined in <xref target="RFC8300" /> with the ability high-level transport protocols such as HTTP for means of SFC packet
to consider name relations based on URIs as well as high-level transport protoc forwarding. Another example for SFC packet forwarding could be that of
ols such as HTTP for means of SFC packet forwarding. Another example for SFC pac Constrained Application Protocol (CoAP).
ket forwarding could be that of CoAP. </t>
</t> <t>
<t> The extended NLM or name-based Network Locator Map
The extended Network Locator Map or name-based Network Locator Map (nNL (nNLM) is shown in <xref target="fig-sfc-3" format="default"/> as an ex
M) is shown in Figure 3 as an example for www.example.com being part of the nSFP ample for www.example.com being
. Such extended nNLM is stored at each SFF throughout the SFC domain with suitab part of the nSFP. Such extended nNLM is stored at each SFF throughout
le information populated to the nNLM during the configuration phase. the SFC domain with suitable information populated to the nNLM during
</t> the configuration phase.
<t> </t>
<figure anchor="fig-sfc-3" align="center" title="Name-Based Netw
ork Locator Map">
<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 |
-----------------------------------------------------------------
| | | | |
| 40 | 251 | 198.51.100.15 | GRE |
| | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | |
| 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-----------------------------+
</artwork>
</figure>
</t>
<t>
Alternatively, the extended network locator map may be defined with i
mplicit name information rather than explicit URIs as in Figure 3. In the exampl
e of Figure 4 below, the next hop is represented as a generic HTTP service witho
ut a specific URI being identified in the extended network locator map. 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 inf
ormation to determine the destination host/service.
</t>
<t>
<figure anchor="fig-sfc-4" align="center" title="Name-based Netw
ork Locator Map with Implicit Name information">
<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 | HTTP Service | HTTP |
-----------------------------------------------------------------
| | | | |
| 40 | 251 | 198.51.100.15 | GRE |
| | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | |
| 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-----------------------------+
</artwork> <table anchor="fig-sfc-3">
</figure> <name>Name-Based Network Locator Map</name>
</t> <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>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)</td>
<td>None</td>
</tr>
</tbody>
</table>
</section> <t>
Alternatively, the extended NLM may be defined with implicit name
information rather than explicit URIs as in <xref
target="fig-sfc-3" format="default"/>. In the example of <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 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>
<section anchor="nsff" title="Name-Based Service Function Forwarder (nS <table anchor="fig-sfc-4">
FF)"> <name>Name-Based Network Locator Map with Implicit Name Information</name>
<t> <thead>
It is desirable to extend the SFF of the SFC underlay to handle nSFP <tr>
s transparently and without the need to insert any service function into the nSF <th>SPI</th>
P. Such extended name-based SFF would then be responsible for forwarding a packe <th>SI</th>
t in the SFC domain as per the definition of the (extended) nSFP. <th>Next Hop(s)</th>
</t> <th>Transport Encapsulation (TE)</th>
<t> </tr>
In our exemplary realization for an extended SFF, the solution described </thead>
in this document uses HTTP as the protocol of forwarding SFC packets to the ne <tbody>
xt (name-based) hop in the nSFP. The URI in the HTTP transaction are the names i <tr>
n our nSFP information, which will be used for name based forwarding. <td>10</td>
</t> <td>255</td>
<t> <td>192.0.2.1</td>
Following our reasoning so far, HTTP requests (and more specifically the <td>VXLAN-gpe</td>
plain text encoded requests above) are the equivalent of Packets that enter the </tr>
SFC domain. In the existing SFC framework, typically an IP payload is assumed t <tr>
o be a packet entering the SFC domain. This packet is forwarded to destination n <td>10</td>
odes using the L2 encapsulation. Any layer 2 network can be used as an underlay <td>254</td>
network. This notion is now extended to packets being possibly part of a entire <td>198.51.100.10</td>
higher layer application, such as HTTP requests. The handling of any intermediat <td>GRE</td>
e layers such as TCP, IP is left to the realization of the (extended) SFF operat </tr>
ions towards the next (named) hop. For this, we will first outline the general l <tr>
ifecycle of an SFC packet in the following subsection, followed by two examples <td>10</td>
for determining next hop information in Section 6.2.3, finalized by a layered vi <td>253</td>
ew on the realization of the nSFF in Section 6.2.4. <td>HTTP Service</td>
</t> <td>HTTP</td>
</section> </tr>
<section anchor="arch" title="High-Level Architecture"> <tr>
<t> <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)</td>
<td>None</td>
</tr>
</tbody>
</table>
<figure anchor="fig-sfc-5" align="center" title="High-level arch </section>
itecture"> <section anchor="nsff" numbered="true" toc="default">
<artwork align="center"> <name>Name-Based Service Function Forwarder (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 SF into
the nSFP. Such extended 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 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 is the name in our nSFP information,
which will be used for name-based forwarding.
</t>
<t>
Following our reasoning so far, HTTP requests (and more specifically,
the plaintext-encoded requests above) are the equivalent of packets
that enter the SFC domain. In the existing SFC framework, 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
an entire higher-layer application such as HTTP requests. The handling
of any intermediate layers, such as TCP and IP, is left to the realizati
on
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 information in <xref target="localfwd" format="default"/>, fini
shed up by a layered view on
the realization of the nSFF in <xref target="httpresp" format="default"/
>.
</t>
</section>
<section anchor="arch" numbered="true" toc="default">
<name>High-Level Architecture</name>
<figure anchor="fig-sfc-5">
<name>High-Level Architecture</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+----------+ +----------+
| SF1 | +--------+ +------+ | SF1 | +--------+ +------+
| instance |\ | NR | | SF2 | | instance |\ | NR | | SF2 |
+----------+ \ +--------+ +------+ +----------+ \ +--------+ +------+
\ || || \ || ||
+------------+ \ +-------+ +---------+ +---------+ +-------+ +------------+ \ +-------+ +---------+ +---------+ +-------+
| Classifier |---| nSFF1 |---|Forwarder|---|Forwarder|---| nSFF2 | | Classifier |---| nSFF1 |---|Forwarder|---|Forwarder|---| nSFF2 |
+------------+ +-------+ +---------+ +---------+ +-------+ +------------+ +-------+ +---------+ +---------+ +-------+
|| ||
+----------+ +----------+
| Boundary | | Boundary |
| node | | node |
+----------+ +----------+]]></artwork
>
</artwork> </figure>
</figure> <t>
The high-level architecture for name-based operation shown in
<xref target="fig-sfc-5" format="default"/> is very similar to the
SFC architecture as described in <xref target="RFC7665"
format="default"/>. Two new functions are introduced, as shown in
the above diagram: namely, the nSFF and the Name Resolver (NR).
</t> </t>
<t> <t>
The high-level architecture for name based operation shown in Figure The nSFF is an extension of the existing SFF and is capable of
5 is very similar to the SFC architecture, as described in <xref target="RFC7665 processing SFC packets based on nNLM information, determining
" />. Two new functions are introduced, as shown in the above diagram, namely th the next SF where the packet should be forwarded, and the
e name-based Service Function Forwarder (nSFF) and the Name Resolver (NR). required transport encapsulation (TE). Like standard SFF operatio
</t> n,
<t> it adds TE to the SFC packet and forwards
nSFF (name-based Service Function Forwarder) is an extension of t it.
he existing SFF and is capable of processing SFC packets based on name-based net </t>
work locator map (nNLM) information, determining the next SF, where the packet s <t>
hould be forwarded and the required transport encapsulation. Like standard SFF o The NR is a new functional component, capable of
peration, it adds transport encapsulation to the SFC packet and forwards it. identifying the execution endpoints, where a "named SF" is
</t> running, triggered by suitable resolution requests sent by the
<t> nSFF. Though this is similar to DNS function, it is not
The Name Resolver is a new functional component, capable of ident same. It does not use DNS protocols or data records. A new
ifying the execution end points, where a "named SF" is running, triggered by sui procedure to determine the suitable routing/forwarding
table resolution requests sent by the nSFF. Though this is similar to DNS functi information towards the nSFF serving the next
on, but it is not same. It does not use DNS protocols or data records. A new pro hop of the SFP is used. The details are
cedure to determine the suitable routing/forwarding information towards the Nsff described later.
(name-based SFF) serving the next hop of the SFP (Service Function Path) is use </t>
d. The details is described later. <t>
</t> The other functional components, such as classifier and SF, are the same
<t> as
The other functional components such as Classifier, SF are same as descr described in SFC architecture, as defined in <xref target="RFC7665" form
ibed in SFC architecture, as defined in <xref target="RFC7665" />, while the For at="default"/>, while the Forwarders shown in the above diagram are traditional
warders shown in the above diagram are traditional Layer 2 switches. Layer 2 switches.
</t> </t>
</section> </section>
<section anchor="steps" numbered="true" toc="default">
<section anchor="steps" title="Operational Steps"> <name>Operational Steps</name>
<t> <t>
In the proposed solution, the operations are realized by the nam In the proposed solution, the operations are realized by the
e-based SFF, called nSFF. We utilize the high-level architecture in Figure 5 to name-based SFF, called "nSFF". We utilize the high-level
describe the traversal between two service function instances of an nSFP-based t architecture in <xref target="fig-sfc-5" format="default"/>
ransactions in an example chain of : 192.0.x.x -> SF1 (www.example.com) -> SF2 to describe the traversal between two SF
(www.example2.com) -> SF3 -> ... Service Function 3 (SF3)is assumed to be a cla instances of an nSFP-based transaction in an example chain
ssical Service Function, hence existing SFC mechanisms can be used to reach it a of: 192.0.x.x -&gt; SF1 (www.example.com) -&gt; SF2
nd will not be considered in this example. (www.example2.com) -&gt; SF3 -&gt; ...
</t> </t>
<t> <t>Service Function 3 (SF3) is assumed to be a classical SF;
According to the SFC lifecycle, as defined in <xref target="RFC7665" /> hence, existing SFC mechanisms can be used to reach it and will not be
, based on our example chain above, the traffic originates from a Classifier or considered in this example.
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>
<t> <t>
<list style="symbols"> According to the SFC lifecycle, as defined in <xref target="RFC7665"
<t> format="default"/>, based on our example chain above, the traffic
Step 1: At nSFF1 the following nNLM is assumed originates from a classifier or another SFF on the left. The traffic
<figure anchor="fig-sfc-6" align="center" title="nNLM at nSF is processed by the incoming nSFF1 (on the left side) through the
F1"> following steps. The traffic exits at nSFF2.
<artwork align="center"> </t>
<ol spacing="normal" type="Step %d:" group="steps" indent="9">
<li anchor="step1">
+------+------+---------------------+----------------------------+ At nSFF1, the following nNLM is assumed:</li>
| 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 (end of path) | None |
+------+------+---------------------+----------------------------+
</artwork> </ol>
</figure> <table anchor="fig-sfc-6">
<name>nNLM at 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)</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).
</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 <xref target="fig-sfc-6"
format="default"/>) based on the provided SPI/SI
information in the NSH (see <xref target="Bkgnd"
format="default"/>) in order to determine the name-based
identifier of the 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
information was identified as a generic HTTP service, as
defined in <xref target="nnlm" format="default"/>.
</li>
</t> <li anchor="step4">
<t>Step 2: nSFF1 removes the previous transport encapsulation The SF1 instance then processes the received SFC packet
(TE) for any traffic originating from another SFF or classifier (traffic from an according to its service semantics and modifies the NSH by
SF instance does not carry any TE and is therefore directly processed at the nS setting SPI = 10 and SI = 252 for forwarding the packet along the
FF). SFP. It then forwards the SFC packet to its local nSFF, i.e.,
</t> nSFF1.
<t> </li>
Step 3: nSFF1 then processes the Network Service Header (NSH) <li anchor="step5">nSSF1 processes the NSH of the SFC packet again,
information, as defined in <xref target="RFC8300" />, to identify the next SF now with the NSH modified (SPI = 10, SI = 252) by the SF1
at the nSFP level by mapping the NSH information to the appropriate entry in its instance. It retrieves the next-hop information from its
nNLM (see Figure 6) based on the provided SPI/SI information in the NSH (see Se nNLM in <xref target="fig-sfc-6" format="default"/> to be www.
ction 4) in order to determine the name-based identifier of the next hop SF. Wit example2.com. Due to this SF
h such nNLM in mind, the nSFF searches the map for SPI = 10 and SI = 253. It ide not being locally available, the nSFF consults any locally
ntifies the next hop as = www.example.com and HTTP as the protocol to be used. G available information regarding routing/forwarding towards
iven the next hop resides locally, the SFC packet is forwarded to the SF1 instan a suitable nSFF that can serve this next hop.
ce of www.example.com. Note that the next hop could also be identified from the </li>
provided HTTP request, if the next hop information was identified as a generic H <li anchor="step6">If such information exists, the Packet (plus the
TTP service, as defined in Section 5.3. NSH information) is marked to be sent towards the nSFF serving the
</t> next hop based on such information in <xref target="step8"
<t> format="none">Step 8</xref>.</li>
Step 4: The SF1 instance then processes the received SFC packet acc <li anchor="step7">If such information does not exist, nSFF1
ording to its service semantics and modifies the NSH by setting SPI = 10, SI = 2 consults the NR to determine the suitable routing/forwarding
52 for forwarding the packet along the SFP. It then forwards the SFC packet to i information towards the identified nSFF serving the next hop of the
ts local nSFF, i.e., nSFF1. SFP. For future SFC packets towards this next hop, such resolved
</t> information may be locally cached, avoiding contacting the NR for
<t>Step 5: nSSF1 processes the NSH of the SFC packet again, no every SFC packet forwarding. The packet is now marked to be sent via
w with the NSH modified (SPI = 10, SI = 252) by the SF1 instance. It retrieves t the network in <xref target="step8" format="none">Step 8</xref>.
he next hop information from its nNLM in Figure 6, to be www.example2.com. Due t </li>
o this SF not being locally available, the nSFF consults any locally available i <li anchor="step8">Utilizing the forwarding information
nformation regarding routing/forwarding towards a suitable nSFF that can serve t determined in Steps <xref target="step6"
his next hop. format="none">6</xref> or <xref target="step7"
</t> format="none">7</xref>, nSFF1 adds the suitable TE for
<t>Step 6: If such information exists, the Packet (plus the NS the SFC packet before forwarding via the forwarders in the network
H information) is marked to be sent towards the nSFF serving the next hop based towards the next nSFF22.</li>
on such information in step 8.</t>
<t>Step 7: If such information does not exist, nSFF1 consults the Nam
e Resolver (NR) to determine the suitable routing/forwarding information towards
the identified nSFF serving the next hop of the SFP. For future SFC packets to
wards this next hop, such resolved information may be locally cached, avoiding t
o contact the Name Resolver for every SFC packet forwarding. The packet is now m
arked to be sent via the network in step 8.
</t>
<t>Step 8: Utilizing the forwarding information determined in steps 6
or 7, nSFF1 adds the suitable transport encapsulation (TE) for the SFC packet b
efore forwarding via the forwarders in the network towards the next nSFF22.</t>
<t>Step 9: When the Packet (+NSH+TE) arrives at the outgoing nSFF2, i
.e., the nSFF serving the identified next hop of the SFP, removes the TE and pro
cesses the NSH to identify the next hop information. At nSFF2 the nNLM in Figure
7 is assumed. Based on this nNLM and NSH information where SPI = 10 and SI = 25
2, nSFF2 identifies the next SF as www.example2.com.
<figure anchor="fig-sfc-7" align="center" title="nNLM at SFF
2">
<artwork align="center">
+------+------+---------------------+-----------------------------+ <li anchor="step9">
| SPI | SI | Next Hop(s) | Transport Encapsulation (TE)| 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 information. At
| 10 | 252 | www.example2.com | HTTP | nSFF2 the nNLM in <xref target="fig-sfc-7" format="default"/> is
| | | | | assumed. Based on this nNLM and NSH information where SPI = 10 and
| 40 | 251 | 198.51.100.15 | GRE | SI = 252, nSFF2 identifies the next SF as www.example2.com.
| | | | | </li></ol>
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | |
| 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-----------------------------+
</artwork> <table anchor="fig-sfc-7">
</figure> <name>nNLM at SFF2</name>
</t> <thead>
<t>Step 10: If the next hop is locally registered at the nSFF, <tr>
it forwards the packet (+NSH) to the service function instance, using suitable <th>SPI</th>
IP/MAC methods for doing so.</t> <th>SI</th>
<t>Step 11: Otherwise, the outgoing nSFF adds a new TE information to <th>Next Hop(s)</th>
the packet and forwards the packet (+NSH+TE) to the next SFF or boundary node, <th>Transport Encapsulation (TE)</th>
as shown in Figure 7.</t> </tr>
</list> </thead>
</t> <tbody>
</section> <tr>
</section> <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)</td>
<td>None</td>
</tr>
</tbody>
</table>
<section anchor="nsfffwd" title="nSFF Forwarding Operations"> <ol spacing="normal" type="Step %d:" group="steps"
<t> indent="9" start="10">
This section outlines the realization of various nSFF forwarding <li anchor="step10">If the next hop is locally registered at the
operations in Section 5.6. Although the operations in Section 5 utilize the not nSFF, it forwards the packet (+NSH) to the SF
ion of name-based transactions in general, we exemplify the operations here in S instance using suitable IP/MAC methods for doing so.</li>
ection 5 specifically for HTTP-based transactions to ground our description into
a specific protocol for such name-based transaction. We will refer to the vario
us steps in each of the following sub-sections.
</t>
<section anchor="proto" title="nSFF Protocol Layers">
<t>
Figure 8 shows the protocol layers, based on the high-level arch
itecture in Figure 5.
</t>
<t>
<figure anchor="fig-sfc-8" align="center" title="Protocol layers">
<artwork align="center">
+-------+ +------+----+ +----+-----+ <li anchor="step11">If the next hop is not locally registered at the n
SFF,
the outgoing nSFF adds new TE information to the packet and
forwards the packet (+NSH+TE) to the next SFF or boundary node, as
shown in <xref target="fig-sfc-7" format="default"/>.</li>
</ol>
</section>
</section>
<section anchor="nsfffwd" numbered="true" toc="default">
<name>nSFF Forwarding Operations</name>
<t>
This section outlines the realization of various nSFF
forwarding operations in <xref target="steps" format="default"/>
. Although the
operations in <xref target="nop" format="default"/> utilize the
notion of
name-based transactions in general, we exemplify the
operations here in <xref target="nop" format="default"/> specifi
cally 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
subsections.
</t>
<section anchor="proto" numbered="true" toc="default">
<name>nSFF Protocol Layers</name>
<t>
<xref target="fig-sfc-8" format="default"/> shows the protocol layers based
on the high-level architecture in <xref target="fig-sfc-5" format="default"/>.
</t>
<figure anchor="fig-sfc-8">
<name>Protocol Layers</name>
<artwork align="center" name="" type="" alt=""><![CDATA[+-------+ +--
----+----+ +----+-----+
|App | | | | +--------+ | | | |App | | | | +--------+ | | |
|HTTP | |--------> | | NR | |nSFF----->|-- |HTTP | |--------> | | NR | |nSFF----->|--
|TCP |->| TCP |nSFF| +---/\---+ | | TCP | | |TCP |->| TCP |nSFF| +---/\---+ | | TCP | |
|IP | | IP | | || | | IP | | |IP | | IP | | || | | IP | |
+-------+ +------+----+ +---------+ +---------+ +----------+ | +-------+ +------+----+ +---------+ +---------+ +----------+ |
| L2 | | L2 |->|Forwarder|-->|Forwarder|-->| L2 | | | L2 | | L2 |->|Forwarder|-->|Forwarder|-->| L2 | |
+-------+ +------+----+ +---------+ +---------+ +----------+ | +-------+ +------+----+ +---------+ +---------+ +----------+ |
SF1 nSFF1 nSFF2 | SF1 nSFF1 nSFF2 |
+-------+ | +-------+ |
| App |/ | | App |/ |
| HTTP | -----------+ | HTTP | -----------+
| TCP |\ | TCP |\
| IP | | IP |
| L2 | | L2 |
+-------+ +-------+
SF2 SF2]]></artwork>
</figure>
</artwork> <t>
</figure> The nSFF component here is shown as implementing a full
</t> incoming/outgoing TCP/IP protocol stack towards the local SFs,
<t> while implementing the nSFF-NR and nSFF-nSFF protocols based on
The nSFF component here is shown as implementing a full incoming/out the descriptions in <xref target="localfwd" format="default"/>.
going TCP/IP protocol stack towards the local service functions, while implement </t>
ing the nSFF-NR and nSFF-nSFF protocols based on the descriptions in Section 6.2 <t>
.3. For the exchange of HTTP-based SF transactions,
</t> the nSFF terminates incoming TCP connections as well as
<t> outgoing TCP connections to local SFs, e.g., the TCP
For the exchange of HTTP-based service function transactions, th connection from SF1 terminates at nSFF1, and nSFF1 may store
e nSFF terminates incoming TCP connections from as well as outgoing TCP connecti the connection information such as socket information. It
ons to local SFs, e.g., the TCP connection from SF1 terminates at nSFF1, and nSF also maintains the mapping information for the HTTP request
F1 may store the connection information, such as socket information. It also mai such as originating SF, destination SF, and socket ID. nSFF1
ntains the mapping information for the HTTP request such as originating SF, dest may implement sending keep-alive messages over the socket to
ination SF and socket ID. nSFF1 may implement sending keep-alive messages over t maintain the connection to SF1. Upon arrival of an HTTP
he socket to maintain the connection to SF1. Upon arrival of an HTTP request fro request from SF1, nSFF1 extracts the HTTP Request and
m SF1, nSFF1 extracts the HTTP Request and forwards it towards the next node, as forwards it towards the next node as outlined in <xref target="n
outlined in Section 6.2. Any returning response is mapped onto the suitable ope sffoperation" format="default"/>. Any returning response is mapped onto the suit
n socket (for the original request) and send towards SF1. able open
</t> socket (for the original request) and sent towards SF1.
<t> </t>
At the outgoing nSFF2, the destination SF2/Host is identified from t <t>
he HTTP request message. If no TCP connection exists to the SF2, a new TCP conne At the outgoing nSFF2, the destination SF2/Host is identified
ction is opened towards the destination SF2 and the HTTP request is sent over sa from the HTTP request message. If no TCP connection exists to the
id TCP connection. The nSFF2 may also save the TCP connection information (such SF2, a new TCP connection is opened towards the destination SF2
as socket information) and maintain the mapping of the socket information to the and the HTTP request is sent over said TCP connection. The nSFF2
destination SF2. When an HTTP response is received from SF2 over the TCP connec may also save the TCP connection information (such as socket
tion, nSFF2 extracts the HTTP response, which is forwarded to the next node. nSF information) and maintain the mapping of the socket information
F2 may maintain the TCP connection through keep-alive messages. 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">
<t>
In this section, we present three key aspects of operations for the re
alization of the steps in Section 5.6, namely (i) the registration of local SFs
(for step 3 in Section 5.6), (ii) the forwarding of SFC packets to and from loca
l SFs (for step 3 and 4 as well as 10 in Section 5.6), (iii) the forwarding to a
remote SF (for steps 5, 6 and 7 in Section 5.6) and to the NR as well as (iv) f
or the lookup of a suitable remote SF (for step 7 in Section 5.6). We also cover
aspects of maintaining local lookup information for reducing lookup latency and
others issues.
</t> </t>
<section anchor="nsfnr" title="Forwarding between nSFFs and nSFF- </section>
NR"> <section anchor="nsffoperation" numbered="true" toc="default">
<t> <name>nSFF Operations</name>
Forwarding between the distributed nSFFs as well as between nSFF and N <t>
R is realized over the operator network via a path-based approach. A path-based In this section, we present three key aspects of operations for the
approach utilizes path information provided by the source of the packet for forw realization of the steps in <xref target="steps" format="default"/>, n
arding said packet in the network. This is similar to segment routing albeit dif amely, (i) the registration
fering in the type of information provided for such source-based forwarding, as of local SFs (for <xref target="step3" format="none">Step 3</xref> in
described in this section. In this approach, the forwarding information to a rem <xref target="steps"/>), (ii) the forwarding of SFC
ote nSFF or the NR is defined as a 'path identifier' (pathID) of a defined lengt packets to and from local SFs (for Steps <xref
h where said "Length" field indicates the full pathID length. The payload of the target="step3" format="none">3</xref>, <xref target="step4"
packet is defined by the various operations outlined in the following sub-secti format="none">4</xref>, and <xref target="step10" format="none">10</xre
ons, resulting in an overall packet being transmitted. With this, the generic fo f> in
rwarding format (GFF) for transport over the operator network is defined in Figu <xref target="steps" format="default"/>), (iii) the
re 9 with the length field defining the length of the pathID provided. forwarding to a remote SF (for Steps <xref target="step5"
format="none">5</xref>, <xref target="step6"
format="none">6</xref>, and <xref target="step7"
format="none">7</xref> in <xref target="steps"/>) and to the NR as well
as (iv) for the lookup
of a suitable remote SF (for <xref target="step7"
format="none">Step 7</xref> in <xref target="steps" format="default"/>)
. We also cover
aspects of maintaining local lookup information for reducing lookup
latency and other issues.
</t> </t>
<t>
<figure anchor="fig-sfc-9" align="center" title="Generic Forwa
rding Format(GFF)">
<artwork align="center">
<section anchor="nsfnr" numbered="true" toc="default">
<name>Forwarding between nSFFs and nSFF-NRs</name>
<t>
Forwarding between the distributed nSFFs as well as between nSFFs and
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 as
described in this section. In this approach, the forwarding
information to a remote nSFF or the NR is defined as a "path
identifier" (pathID) of a defined length where said length field
indicates the full pathID length. The payload of the packet is
defined by the various operations outlined in the following
subsections, resulting in an overall packet being transmitted. With
this, the generic forwarding format (GFF) for transport over the
operator network is defined in <xref target="fig-sfc-9" format="defaul
t"/> with the length field
defining the length of the pathID provided.
</t>
<figure anchor="fig-sfc-9">
<name>Generic Forwarding Format (GFF)</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+---------+-----------------+------------------------//------------+ +---------+-----------------+------------------------//------------+
| | | // | | | | // |
| Length | Path ID | Payload // | | Length | Path ID | Payload // |
|(12 bit) | | // | |(12 bits)| | // |
+---------+-----------------+--------------------//----------------+ +---------+-----------------+--------------------//----------------+]]></artwork
>
</figure>
<ul spacing="normal">
<li>
Length (12 bits): Defines the length of the pathID, i.e., up to 4096
bits
</li>
<li>
Path ID: Variable-length bit field derived from
IPv6 source and destination address
</li>
</ul>
</artwork>
</figure>
</t>
<t>
<list style="symbols">
<t> <t>
Length (12 bits): Defines the length of the pathID, i.e., up to 4096 For the pathID information, solutions such as those in <xref
bits target="Reed2016" format="default"/> can be used. Here, the
</t> IPv6 source and destination addresses are used to realize a
<t> so-called path-based forwarding from the incoming to the
Path ID (): Variable length field, Bit field derived from IPv6 outgoing nSFF or the NR. The forwarders in <xref
source and destination address target="fig-sfc-8" format="default"/> are realized via SDN
</t> (software-defined networking) switches, implementing an
AND/CMP operation based on arbitrary wildcard matching over
the IPv6 source and destination 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 TE
at the outgoing nSFF in <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
such as that of IP-based routing. As described in <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.
</list> The next-hop nSFF (see <xref target="fig-sfc-8"
</t> format="default"/>) will restore the IP header of the packet
<t> with the relevant IP information used to forward the SFC
For the pathID information, solutions such as those in <xref ta packet to SF2, or it will create suitable TE information to
rget="Reed2016" /> can be used. Here, the IPv6 source and destination addresses forward the information to another nSFF or boundary
are used to realize a so-called path-based forwarding from the incoming to the o node. Forwarding operations at the intermediary forwarders,
utgoing nSFF or the NR. The forwarders in Figure 8 are realized via SDN (softwar i.e., SDN switches, examine the pathID information through a
e-defined networking) switches, implementing an AND/CMP operation based on arbit flow-matching rule in which a specific switch-local output
rary wildcard matching over the IPv6 source and destination addresses, as outlin port is represented through the specific assigned bit
ed in <xref target="Reed2016" />. Note that in the case of using IPv6 address in position in the pathID. Upon a positive match in said rule,
formation for path-based forwarding, the step of removing the transport encapsul the packet is forwarded on said output port.
ation at the outgoing nSFF in Figure 8 is realized by utilizing the provided (ex
isting) IP header (which was used for the purpose of the path-based forwarding i
n <xref target="Reed2016" />) for the purpose of next hop forwarding, such as th
at of IP-based routing. As described in step 8 of the extended nSFF operations,
this forwarding information is used as traffic encapsulation. With the forwardin
g information utilizing existing IPv6 information, IP headers are utilized as TE
in this case. The next hop nSFF (see Figure 8) will restore the IP header of th
e packet with the relevant IP information used to forward the SFC packet to 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 thro
ugh a flow matching rule in which a specific switch-local output port is represe
nted through the specific assigned bit position in the pathID. Upon a positive m
atch in said rule, the packet is forwarded on said output port.
</t>
<t>
Alternatively, the solution in <xref target="BIER-MULTICAST"/>
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 (plus the NSH) header with BIER-based traffic encapsulation into
the BIER underlay with each of the forwarders in Figure 8 being realized as a so
-called Bit-Forwarding Router (BFR) <xref target="RFC8279"/>.
</t>
<section anchor="transport" title="Transport Protocol Considerati
ons">
<t>
Given that the proposed solution operates at the 'named transac
tion' level, particularly for HTTP transactions, forwarding between nSFFs and/or
NR SHOULD be implemented via a transport protocol between nSFFs and/or NR in or
der to provide reliability, segmentation of large GFF packets, and flow control,
with the GFF in Figure 9 being the basic forwarding format for this.
</t>
<t>
Note that the nSFFs act as TCP proxies at ingress and egress, t
hus terminating incoming and initiating outgoing HTTP sessions to SFs.
</t>
<t>
Figure 10 shows the packet format being used for the transmissi
on of data, being adapted from the TCP header. Segmentation of large transaction
s into single transport protocol packets is realized through maintaining a 'Sequ
ence number'. A 'Checksum' is calculated over a single data packet with the ones
-complement TCP checksum calculation being used. The 'Window Size' field indicat
es the current maximum number of transport packets that are allowed in-flight by
the egress nSFF. A data packet is sent without 'Data' field to indicate the end
of (e.g., HTTP) transaction.
</t> </t>
<t> <t>
Note that in order to support future named transactions based on othe Alternatively, the solution in <xref target="I-D.ietf-bier-mult
r application protocols, such as CoAP, future versions of the transport protocol icast-http-response" format="default"/> suggests using a so-called BIER
MAY introduce a 'Type' field that indicates the type of application protocol be (Binary Indexed Explicit Replication) underlay. Here, the
ing used between SF and nSFF with 'Type' 0x01 proposed for HTTP. This is being l nSFF would be realized at the ingress to the BIER underlay,
eft for future study. injecting the SFC packet header (plus the Network Service
</t> Header (NSH)) with BIER-based traffic encapsulation into the
<t> BIER underlay with each of the forwarders in <xref target="fig-
<figure anchor="fig-sfc-10" align="center" title="Transport pr sfc-8" format="default"/> being realized as a so-called
otocol data packet format"> Bit-Forwarding Router (BFR) <xref target="RFC8279" format="defa
<artwork align="center"> ult"/>.
</t>
<section anchor="transport" numbered="true" toc="default">
<name>Transport Protocol Considerations</name>
<t>
Given that the proposed solution operates at the
"named-transaction" level, particularly for HTTP
transactions, forwarding between nSFFs and/or NRs
<bcp14>SHOULD</bcp14> be implemented via a transport
protocol between nSFFs and/or NRs in order to provide
reliability, segmentation of large GFF packets, and flow
control, with the GFF in <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>
<xref target="fig-sfc-10" format="default"/> shows the packet f
ormat 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". A "Checksum" is calculated over a single
data packet with the ones-complement TCP checksum
calculation being used. The "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 a "Data" field to indicate the end of the (e.g., HTTP)
transaction.
</t>
<t>
Note that, in order to support future named transactions based on
other application protocols, such as Constrained Application Protocol
(CoAP), future versions of the
transport protocol <bcp14>MAY</bcp14> introduce a "Type" field that i
ndicates the
type of application protocol being used between SF and nSFF with
"Type" 0x01 proposed for HTTP. This is being left for future study.
</t>
| 16 bit | 16 bit | <figure anchor="fig-sfc-10">
<name>Transport Protocol Data Packet Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+----------------------------------------------+
| 16 bits | 16 bits |
+----------------------------------------------+ +----------------------------------------------+
| Sequence number | | Sequence number |
+----------------------------------------------+ +----------------------------------------------+
| Checksum | Window Size | | Checksum | Window Size |
+----------------------------------------------+ +----------------------------------------------+
| ... | | ... |
| Data (Optional) | | Data (Optional) |
+----------------------------------------------+ +----------------------------------------------+]]></artwork>
</artwork> </figure>
</figure> <t>
</t> Given the path-based forwarding being used between nSFFs,
<t> the transport protocol between nSFFs utilizes negative
Given the path-based forwarding being used between nSFFs, the t acknowledgements from the egress nSFF towards the ingress
ransport protocol between nSFFs utilizes negative acknowledgements from the egre nSFF. The transport protocol negative Acknowledgment
ss nSFF towards the ingress nSFF. The transport protocol NACK packet carries the (NACK) packet carries the number
number of NACKs as well as the specific sequence numbers being indicated as los of NACKs as well as the specific sequence numbers being
t in the 'NACK number' field(s), as shown in Figure 11. indicated as lost in the "NACK number" field(s) as shown in
</t> <xref target="fig-sfc-11" format="default"/>.
<t> </t>
<figure anchor="fig-sfc-11" align="center" title="Transport pr <figure anchor="fig-sfc-11">
otocol NACK packet format"> <name>Transport Protocol NACK Packet Format</name>
<artwork align="center"> <artwork align="center" name="" type="" alt=""><![CDATA[
+-----------------------+----------------------+
| 16 bit | 16 bit | | 16 bits | 16 bits |
+----------------------------------------------+ +----------------------------------------------+
| Number of NACKs | + | Number of NACKs | +
+----------------------------------------------+ +----------------------------------------------+
| NACK number | | NACK number |
+----------------------------------------------+ +----------------------------------------------+
+ ... NACK Number + + ... NACK number +
+----------------------------------------------+ +----------------------------------------------+]]></artwork>
</artwork> </figure>
</figure>
</t>
<t>
If the indicated number of NACKs in a received NACK packet in non-zero,
the ingress nSFF will retransmit all sequence numbers signalled in the packet, w
hile decreasing its congestion window size for future transmissions.
</t>
<t>
If the indicated number of NACKs in a received NACK packet in zero, it w
ill indicate the current congestion window as being successfully (and completely
) being transmitted, increasing the congestion window size if smaller than the a
dvertised 'Window Size' in Figure 10.
</t>
<t>
The maintenance of the congestion window is subject to realization at th
e ingress nSFF and left for further study in nSFF realizations.
</t>
</section>
</section>
<section anchor="registration" title="SF Registration">
<t>
As outlined in step 3 and 10 of Section 5.6, the nSFF needs to
determine if the SF derived from the nNLM is locally reachable or whether the
packet needs forwarding 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 t
his:
</t>
<t>
1. SF-initiated: We assume that the SF registers its FQDN to the loc
al nSFF. As local mechanisms, we foresee that either a REST-based interface over
the link-local link or configuration of the nSFF (through configuration files o
r management consoles) can be utilized. Such local registration event leads to t
he nSFF to register the given FQDN with the NR in combination with a system-uniq
ue nSFF identifier that is being used for path computation purposes in the NR. F
or the registration, the packet format in Figure 12 is used (inserted as the pay
load in the GFF of Figure 9 with the pathID towards the NR).
</t>
<t>
<figure anchor="fig-sfc-12" align="center" title="Registration
packet format">
<artwork align="center">
+---------+-----------------+------------------+
| | | |
| R/D | hash(FQDN) | nSFF_ID |
| (1 bit) | (16 bit) | (8 bit) |
+---------+-----------------+------------------+
</artwork>
</figure>
</t>
<t>
<list style="symbols">
<t> <t>
R/D: 1 bit length (0 for Register, 1 for De-register) If the indicated number of NACKs in a received NACK packet is
nonzero, the ingress nSFF will retransmit all sequence numbers
signaled in the packet while decreasing its congestion window size
for future transmissions.
</t> </t>
<t>
Hash(FQDN): 16 bit length for a hash over the FQDN of the
SF
</t>
<t> <t>
nSFF_ID: 8 bit for a system-unique identifier for the If the indicated number of NACKs in a received NACK packet is zero, it
SFF related to the SF. will indicate the current congestion window as being successfully (and
</t> completely) being transmitted, increasing the congestion window size
</list> if smaller than the advertised "Window Size" in <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" numbered="true" toc="default">
<name>SF Registration</name>
<t>
As outlined in Steps <xref target="step3"
format="none">3</xref> and <xref target="step10"
format="none">10</xref> of <xref target="steps" format="default"/>,
the nSFF needs to determine if the SF derived from the
Name-Based Network Locator (nNLM) is locally reachable or
whether the packet needs 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>
<t>
We assume that the pathID towards the NR is known to the nSFF through <ol group="my_count" spacing="normal" indent="6">
configuration means. <li>
</t> SF-initiated: We assume that the SF registers its Fully Qualified
Domain Name (FQDN) to the local nSFF. As local mechanisms, we
foresee that either a Representational State Transfer (REST-based) i
nterface over the link-local
link or configuration of the nSFF (through configuration files or
management consoles) can be utilized. Such local registration
events lead to the nSFF registering the given FQDN with the NR in
combination with a system-unique nSFF identifier that is being
used for path-computation purposes in the NR. For the
registration, the packet format in <xref target="fig-sfc-12"
format="default"/> is used (inserted as the payload in the GFF of
<xref target="fig-sfc-9" format="default"/> with the pathID
towards the NR).
</li>
</ol>
<ul empty="true">
<li>
<ul empty="true" spacing="normal">
<li>
<ul empty="true">
<li>
<figure anchor="fig-sfc-12">
<name>Registration Packet Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[+---------+-
-----------------+----------------+
| | | |
| R/D | hash(FQDN) | nSFF_ID |
| (1 bit) | (16 bits) | (8 bits) |
+---------+------------------+----------------+]]></artwork>
</figure>
<ul spacing="normal">
<li>
R/D: 1-bit length (0 for Register, 1 for Deregister)
</li>
<li>
hash(FQDN): 16-bit length for a hash over the FQDN of the SF
</li>
<li>
nSFF_ID: 8-bit length for a system-unique identifier for the SFF r
elated to the 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 configurat
ion means.
</li>
<li>
The NR maintains an internal table that associates the hash(FQDN), the nSFF_id
information, as well as the pathID information being used for communication
between nSFFs and NRs. The nSFF locally maintains a mapping of registered FQDNs
to IP addresses for the latter using link-local private IP addresses.
</li>
</ul>
</li>
</ul>
</li>
</ul>
<ol group="my_count" spacing="normal" indent="6">
<li>
Orchestration-based: In this mechanism, we assume that SFC
to be orchestrated and the chain 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.
</li>
</ol>
</section>
<section anchor="localfwd" numbered="true" toc="default">
<name>Local SF Forwarding</name>
<t> <t>
The NR maintains an internal table that associates the ha There are two cases of local SF forwarding, namely, the SF
sh(FQDN), the nSFF_id information as well as the pathID information being used f sending an SFC packet to the local nSFF (incoming requests)
or communication between nSFF and NR. The nSFF locally maintains a mapping of re or the nSFF sending a packet to the SF (outgoing requests)
gistered FQDNs to IP addresses, for the latter using link-local private IP addre as part of Steps <xref target="step3"
sses. format="none">3</xref> and <xref target="step10"
</t> format="none">10</xref> in <xref target="steps" format="default"/>. In
<t> the following,
2. Orchestration-based: in this mechanism, we assume that SFC we outline the operation for HTTP as an example-named
to be orchestrated and the chain being provided through an orchestration templa transaction.
te with FQDN information associated to a compute/storage resource that is being
deployed by the orchestrator. We also assume knowledge at the orchestrator of th
e resource topology. Based on this, the orchestrator can now use the same REST-b
ased 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>
</section>
<section anchor="localfwd" title="Local SF Forwarding ">
<t>
There are two cases of local SF forwarding, namely the SF send
ing an SFC packet to the local nSFF (incoming requests) or the nSFF sending a pa
cket to the SF (outgoing requests) as part of steps 3 and 10 in Section 5.6. In
the following, we outline the operation for HTTP as an example named transaction
.
</t>
<t>
As shown in Figure 8, incoming HTTP requests from SFs are extracted
by terminating the incoming TCP connection at their local nSFFs at the TCP level
. The nSFF MUST maintain a mapping of open TCP sockets to HTTP requests (utilizi
ng the URI of the request) for HTTP response association.
</t> </t>
<t> <t>
For outgoing HTTP requests, the nSFF utilizes the maintained As shown in <xref target="fig-sfc-8" format="default"/>, incoming HT
mapping of locally registered FQDNs to link-local IP addresses (see Section 6.2. TP requests from SFs are
2 option 1). Hence, upon receiving an SFC packet from a remote nSFF (in step 9 o extracted by terminating the incoming TCP connection at their
f Section 5.6), the nSFF determines the local existence of the SF through the re local nSFFs at the TCP level. The nSFF <bcp14>MUST</bcp14> maintain
gistration mechanisms in Section 6.2.2. If said SF does exist locally, the HTTP a mapping of
(+NSH) packet, after stripping the TE, is sent to the local SF as step 10 in Sec open TCP sockets to HTTP requests (utilizing the URI of the
tion 5.6 via a TCP-level connection. Outgoing nSFF SHOULD keep TCP connections o request) for HTTP response association.
pen to local SFs for improving SFC packet delivery in subsequent transactions.
</t>
</section>
<section anchor="httpresp" title="Handling of HTTP Responses">
<t>
When executing step 3 and 10 in Section 5.6, the SFC packet wi
ll 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 li
st of link-local connection information, e.g., sockets to the local SF and the p
athID on which the request was received. Once receiving the response, nSFF consu
lts the table to determine the pathID of the original request, forming a suitabl
e GFF-based packet to be returned to the previous nSFF.
</t>
<t>
When receiving the HTTP response at the previous nSFF, the nSFF cons
ults the table of (locally) open sockets to determine the suitable local SF conn
ection, mapping the received HTTP response URI to the stored request URI. Utiliz
ing the found socket, the HTTP response is forwarded to the locally registered S
F.
</t> </t>
</section> <t>
<section anchor="remotefwd" title="Remote SF Forwarding"> For outgoing HTTP requests, the nSFF utilizes the
<t> maintained mapping of locally registered FQDNs to
In steps 5, 6, 7, and 8 of Section 5.6, an SFC packet is forwa link-local IP addresses (see <xref target="registration" form
rded to a remote nSFF based on the nNLM information for the next hop of the nSFP at="default"/>, option
. Section 6.2.5.1 handles the case of suitable forwarding information to the rem 1). Hence, upon receiving an SFC packet from a remote nSFF
ote nSFF not existing, therefore consulting the NR to obtain suitable informatio (in <xref target="step9"
n, while Section 6.2.5.2 describes the maintenance of forwarding information at format="none">Step 9</xref> of <xref target="steps" format="default"/>)
the local nSFF, while Section 6.2.5.3 describes the update of stale forwarding i , the nSFF determines the local
nformation. Note that the forwarding described in Section 6.2.1 is used for the existence of the SF through the registration mechanisms in
actual forwarding to the various nSFF components. Ultimately, Section 6.2.5.4 d <xref target="registration" format="default"/>. If said SF do
escribes the forwarding to the remote nSFF via the forwarder network. es exist locally, the HTTP
</t> (+NSH) packet, after stripping the TE, is sent to the
<section anchor="remotedisc" title="Remote SF Discovery"> local SF as <xref target="step10"
<t> format="none">Step 10</xref> in <xref target="steps" format="default"/>
The nSFF communicates with the NR for two purposes, namely th via a TCP-level
e registration and discovery of FQDNs. The packet format for the former was show connection. Outgoing nSFFs <bcp14>SHOULD</bcp14> keep TCP con
n in Figure 10 in Section 6.2.2, while Figure 13 outlines the packet format for nections open
the discovery request. to local SFs for improving SFC packet delivery in
</t> subsequent transactions.
<t> </t>
<figure anchor="fig-sfc-13" align="center" title="Discovery packet fo </section>
rmat"> <section anchor="httpresp" numbered="true" toc="default">
<artwork align="center"> <name>Handling of HTTP Responses</name>
<t>
When executing Steps <xref target="step3"
format="none">3</xref> and <xref target="step10"
format="none">10</xref> in <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" numbered="true" toc="default">
<name>Remote SF Forwarding</name>
<t>
In Steps <xref target="step5"
format="none">5</xref>, <xref target="step6"
format="none">6</xref>, <xref target="step7"
format="none">7</xref>, and <xref target="step8"
format="none">8</xref> of <xref target="steps" format="default"/>, an S
FC
packet is forwarded to a remote nSFF based on the nNLM
information for the next hop of the nSFP. <xref target="remote
disc" format="default"/> handles the case of suitable
forwarding information to the remote nSFF not existing,
therefore consulting the NR to obtain suitable information.
<xref target="maintain" format="default"/> describes the maint
enance
of forwarding information at the local nSFF. <xref target="up
date" format="default"/> describes the update of stale forwarding
information. Note that the forwarding described in <xref targe
t="nsfnr" format="default"/> is used for the actual forwarding to the
various nSFF components. Ultimately, <xref target="fwd" forma
t="default"/>
describes the forwarding to the remote nSFF via the
forwarder network.
</t>
<section anchor="remotedisc" numbered="true" toc="default">
<name>Remote SF Discovery</name>
<t>
The nSFF communicates with the NR for two purposes: namely,
the registration and discovery of FQDNs. The packet format
for the former was shown in <xref target="fig-sfc-12" format=
"default"/> in
<xref target="registration" format="default"/>,
while <xref target="fig-sfc-13" format="default"/> outlines t
he packet format for the
discovery request.
</t>
<figure anchor="fig-sfc-13">
<name>Discovery Packet Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+--------------+-------------+ +--------+-----------------//--------+ +--------------+-------------+ +--------+-----------------//--------+
| | | | | // | | | | | | // |
| hash(FQDN) | nSFF_ID | | Length | pathID // | | hash(FQDN) | nSFF_ID | | Length | pathID // |
| (16 bit) | (8 bit) | | (4 bit)| // | | (16 bits) | (8 bits) | |(4 bits)| // |
+--------------+-------------+ +--------+-------------//------------+ +--------------+-------------+ +--------+-------------//------------+
Path Request Path Response Path Request Path Response]]></artwork>
</figure>
</artwork>
</figure>
</t>
<t>
For Path Request:
<list style="symbols">
<t> <t>
Hash(FQDN): 16 bit length for a hash over the FQDN of the SF For Path Request:
</t> </t>
<t> <ul spacing="normal">
nSFF_ID: 8 bit for a system-unique identifier for the SFF <li>
related to the SF hash(FQDN): 16-bit length for a hash over the FQDN of the SF
</t> </li>
</list> <li>
</t> nSFF_ID: 8-bit length for a system-unique identifier for the SFF r
<t> elated to the SF
</li>
</ul>
<t>
For Path Response: For Path Response:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
Length: 4-bit length that defines the length of the pathID
</li>
<li>
Path ID: Variable-length bit field derived from IPv6 source
and destination address
</li>
</ul>
<t> <t>
Length (4 bits): Defines the length of the pathID 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 <bcp14>SHOULD</bcp14> maintai
n 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>
<t> <t>
Path ID (): Variable length field, Bit field derived from The discovery request for an FQDN that has not previously been
IPv6 source and destination address served at the nSFF (or for an FQDN whose pathID information has
</t> been flushed as a result of the update operations in <xref
</list> target="update" format="default"/>) results in an initial latency
</t> incurred by this discovery through the NR, while any SFC packet
<t> sent over the same SFP in a subsequent transaction will utilize
A path to a specific FQDN is requested by sending a hash of the FQDN the nSFF-local mapping table. Such initial latency can be avoided
to the NR together with its nSFF_id, receiving as a response a pathID with a len by prepopulating the FQDN-pathID mapping proactively as part of
gth identifier. The NR SHOULD maintain a table of discovery requests that map di the overall orchestration procedure, e.g., alongside the
scovered (hash of) FQDN to the nSFF_id that requested it and the pathID that is distribution of the nNLM information to the nSFF.
being calculated as a result of the discovery request. </t>
</t> </section>
<t> <section anchor="maintain" numbered="true" toc="default">
The discovery request for an FQDN that has not previously been serve <name>Maintaining Forwarding Information at Local nSFF</name>
d at the nSFF (or for an FQDN whose pathID information has been flushed as a res
ult of the update operations in Section 6.2.5.3), results in an initial latency
incurred by this discovery through the NR, while any SFC packet sent over the sa
me SFP in a subsequent transaction will utilize the nSFF local mapping table. Su
ch initial latency can be avoided by pre-populating the FQDN-pathID mapping proa
ctively as part of the overall orchestration procedure, e.g., alongside the dist
ribution of the nNLM information to the nSFF.
</t>
</section>
<section anchor="maintain" title="Maintaining Forwarding Inform
ation at Local nSFF">
<t>
Each nSFF MUST maintain an internal table that maps the (hash
of the) FQDN information to a suitable pathID information. As outlined in step
7 of Section 5.6, if a suitable entry does not exist for a given FQDN, the pathI
D information is requested with the operations in Section 6.2.5.1 and the suitab
le entry is locally created upon receiving a reply with the forwarding operation
being executed as described in Section 6.2.1.
</t>
<t>
If such entry does exist (i.e., step 6 of Section 5.6) the pathID is
locally retrieved and used for the forwarding operation in Section 6.2.1.
</t>
</section>
<section anchor="update" title="Updating Forwarding Information
at nSFF">
<t>
The forwarding information maintained at each nSFF (see Section 6
.2.5.2) might need to be updated for three reasons:
<list style="symbols">
<t>
An existing SF is no longer reachable: In this case, th
e nSFF with which the SF is locally registered, de-registers the SF explicitly a
t the NR by sending the packet in Figure 10 with the hashed FQDN and the R/D bit
set to 1 (for de-register).
</t>
<t>
Another SF instance has become reachable in the network
(and therefore might provide a better alternative to the existing SF): in this c
ase, the NR has received another packet with format defined in Figure 11 but a d
ifferent nSFF_id value.
</t>
<t>
Links along paths might no longer be reachable: the NR
might use suitable southbound interface to transport networks to detect link fai
lures, which it associates to the appropriate pathID bit position.
</t>
</list>
</t>
<t>
For this purpose, the packet format in Figure 14 is sent from the NR
to all affected nSFFs, using the generic format in Figure 9.
</t>
<t>
<figure anchor="fig-sfc-14" align="center" title="Path update
format">
<artwork align="center">
<t>
Each nSFF <bcp14>MUST</bcp14> maintain an internal table
that maps the (hash of the) FQDN information to a suitable
pathID. As outlined in <xref target="step7"
format="none">Step 7</xref> of <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 <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 <xref target="nsfnr" format="default"/>.
</t>
<t>
If such an entry does exist (i.e., <xref target="step6"
format="none">Step 6</xref> of <xref target="steps" format="default"/>)
, the pathID
is locally retrieved and used for the forwarding operation in
<xref target="nsfnr" format="default"/>.
</t>
</section>
<section anchor="update" numbered="true" toc="default">
<name>Updating Forwarding Information at nSFF</name>
<t>
The forwarding information maintained at each nSFF (see
<xref target="maintain" format="default"/>) might need to be upda
ted for three reasons:
</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
deregisters the SF explicitly at the NR by sending
the packet in <xref target="fig-sfc-10"
format="default"/> with the hashed FQDN and the R/D
bit set to 1 (for deregister).
</li>
<li>
Another SF instance has become reachable in the
network (and, therefore, might provide a better
alternative to the existing SF): In this case, the NR
has received another packet with a format defined in
<xref target="fig-sfc-11" format="default"/> but a diffe
rent nSFF_id value.
</li>
<li>
Links along paths might no longer be reachable: The
NR might use a suitable southbound interface to
transport networks to detect link failures, which it
associates to the appropriate pathID bit position.
</li>
</ol>
<t>
For this purpose, the packet format in <xref target="fig-sfc-14" for
mat="default"/> is sent from the
NR to all affected nSFFs, using the generic format in <xref target="
fig-sfc-9" format="default"/>.
</t>
<figure anchor="fig-sfc-14">
<name>Path Update Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+---------+-----------------+--------------//----+ +---------+-----------------+--------------//----+
| | | // | | | | // |
| Type | #IDs | IDs // | | Type | #IDs | IDs // |
| (1 bit) | (8 bit) | // | | (1 bit) | (8 bits) | // |
+---------+-----------------+----------//--------+ +---------+-----------------+----------//--------+]]></artwork>
</figure>
</artwork> <ul spacing="normal">
</figure> <li>
</t> Type: 1-bit length (0 for Nsff ID, 1 for Link ID)
<t> </li>
<list style="symbols"> <li>
#IDs: 8-bit length for number of IDs in the list
</li>
<li>
IDs: List of IDs (Nsff ID or Link ID)
</li>
</ul>
<t> <t>
Type: 1 bit length (0 for Nsff ID, 1 for Link ID) 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 <xref target="registration" format="default"
/>.
</t> </t>
<t> <t>
#IDs: 8 bit length for number of IDs in the list The pathID may include the type of information being updated
</t> (e.g., node identifiers of leaf nodes or link identifiers for
<t> removed links). The node identifier itself may be a special
IDs: List of IDs (Nsff ID or Link ID) identifier to signal "ALL NODES" as being affected. The node
</t> identifier may signal changes to the network that are substantial
</list> (e.g., parallel link failures). The node identifier may trigger
</t> (e.g., recommend) purging of the entire path table (e.g., rather
<t> than the selective removal of a few nodes only).
The pathID to the affected nSFFs is computed as the binar </t>
y OR over all pathIDs to those nSFF_ids affected where the pathID information to <t>
the affected nSFF_id values is determined from the NR-local table maintained in It will include the information according to the type. The
the registration/deregistration operation of Section 6.2.2. included information may also be related to the type and length
</t> information for the number of identifiers being provided.
</t>
<t> <t>
The pathID may include the type of information being updated (e.g., In cases 1 and 2, the Type bit is set to 1 (type nSFF_id) and the
node identifiers of leaf nodes or link identifiers for removed links). The node affected nSFFs are determined by those nSFFs that have previously
identifier itself may be a special identifier to signal "ALL NODES" as being aff sent SF discovery requests, utilizing the optional table mapping
ected. The node identifier may signal changes to the network that are substanti previously registered FQDNs to nSFF_id values. If no table mapping
al (e.g., parallel link failures). The node identifier may trigger (e.g., recom the (hash of) FQDN to nSFF_id is maintained, the update is sent to
mend) purging of the entire path table (e.g., rather than the selective removal all nSFFs. Upon receiving the path update at the affected nSFF,
of a few nodes only). all appropriate nSFF-local mapping entries to pathIDs for the
</t> hash(FQDN) identifiers provided will be removed, leading to a new
<t> NR discovery request at the next remote nSFF forwarding to the
It will include the information according to the type. The included appropriate FQDN.
information may also be related to the type and length information for the numbe </t>
r of identifiers being provided. <t>
</t> In case 3, the Type bit is set to 0 (type linkID) and the affected
<t> nSFFs are determined by those nSFFs whose discovery requests have
In case 1 and 2, the Type bit is set to 1 (type nSFF_id) and the aff previously resulted in pathIDs that include the affected link,
ected nSFFs are determined by those nSFFs that have previously sent SF discovery utilizing the optional table mapping previously registered FQDNs
requests, utilizing the optional table mapping previously registered FQDNs to n to pathID values (see <xref target="remotedisc" format="default"/>).
SFF_id values. If no table mapping the (hash of) FQDN to nSFF_id is maintained, Upon receiving the node
the update is sent to all nSFFs. Upon receiving the path update at the affected identifier information in the path update, the affected nSFF will
nSFF, all appropriate nSFF-local mapping entries to pathIDs for the hash(FQDN) check its internal table that maps FQDNs to pathIDs to determine
identifiers provided will be removed, leading to a new NR discovery request at t those pathIDs affected by the link problems and remove path
he next remote nSFF forwarding to the appropriate FQDN. information that includes the received node identifier(s). For
</t> this, the pathID entries of said table are checked against the
<t> linkID values provided in the ID entry of the path update through
In case 3, the Type bit is set to 0 (type linkID) and the affected n a binary AND/CMP operation to check the inclusion of the link in
SFFs are determined by those nSFFs whose discovery requests have previously resu the pathIDs to the FQDNs. If any pathID is affected, the
lted in pathIDs which include the affected link, utilizing the optional table ma FQDN-pathID entry is removed, leading to a new NR discovery
pping previously registered FQDNs to pathID values (see Section 6.2.5.1). Upon r request at the next remote nSFF forwarding to the appropriate
eceiving the node identifier information in the path update, the affected nSFF w FQDN.
ill check its internal table that maps FQDNs to pathIDs to determine those pathI </t>
Ds affected by the link problems and remove path information that includes the r </section>
eceived node identifier(s). For this, the pathID entries of said table are check <section anchor="fwd" numbered="true" toc="default">
ed against the linkID values provided in the ID entry of the path update through <name>Forwarding to Remote nSFF</name>
a binary AND/CMP operation to check the inclusion of the link in the pathIDs to <t>
the FQDNs. If any pathID is affected, the FQDN-pathID entry is removed, leading Once Steps <xref target="step5"
to a new NR discovery request at the next remote nSFF forwarding to the appropr format="none">5</xref>, <xref target="step6"
iate FQDN. format="none">6</xref>, and <xref target="step7"
</t> format="none">7</xref> in <xref target="steps" format="default"/> are b
</section> eing executed,
<section anchor="fwd" title="Forwarding to remote nSFF"> <xref target="step8"
<t> format="none">Step 8</xref> finally sends the SFC packet to the remote
Once step 5, 6, and 7 in Section 5.6 are being executed, step nSFF,
8 finally sends the SFC packet to the remote nSFF, utilizing the pathID returne utilizing the pathID returned in the discovery request
d in the discovery request (Section 6.2.5.1) or retrieved from the local pathID (<xref target="remotedisc" format="default"/>) or retrieved f
mapping table. The SFC packet is placed in the payload of the generic forwarding rom the local pathID
format in Figure 9 together with the pathID and the nSFF eventually executes th mapping table. The SFC packet is placed in the payload of
e forwarding operations in Section 6.2.1. the generic forwarding format in <xref target="fig-sfc-9" for
</t> mat="default"/> together with
</section> the pathID, and the nSFF eventually executes the forwarding
operations in <xref target="nsfnr" format="default"/>.
</section> </t>
</section> </section>
</section> </section>
</section>
<section anchor="IANA" title="IANA Considerations"> </section>
<section anchor="IANA" numbered="true" toc="default">
<t>This document requests no IANA actions. <name>IANA Considerations</name>
<t>This document has no IANA actions.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Sections <xref target="nop" format="counter"/> and <xref target="nsfffw
<t>The operations in Sections 5 and 6 describes the forwarding of SFC pack d" format="counter"/> describe the forwarding of SFC
ets between named SFs based on URIs exchanged in HTTP messages. packets between named SFs based on URIs exchanged in HTTP messages.
For security considerations, TLS is sufficient between originating node Security is needed to protect the communications between originating
and Nsff, Nsff to Nsff, Nsff to destination. TLS handshake node and Ssff, between one Nsff and the next Nsff, and between Nsff and
allows to determine the FQDN, which in turn is enough for the service r destination. TLS is sufficient for this and <bcp14>SHOULD</bcp14> be used.
outing decision. Supporting TLS also allows the possibility of HTTPS based trans The TLS
actions.</t> handshake allows to determine the FQDN, which, in turn, is enough for the
service routing decision. Supporting TLS also allows the possibility of
HTTPS-based transactions.</t>
<t> It should be noted (per <xref target="RFC3986" format="default"/>) tha
t what a URI resolves to is not
necessarily stable. This can allow flexibility in deployment, as described in
this document, but may also result in unexpected behavior and could provide an
attack vector as the resolution of a URI could be "hi-jacked" resulting in
packets being steered to the wrong place. This could be particularly
important if the SFC is intended to send packets for processing at security
functions. Such hi-jacking is a new attack surface introduced by using a
separate NR.
</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-bier-multicast-http-response"
&rfc2119; to="BIER-MULTICAST"/>
&rfc7665; <references>
&rfc8174; <name>References</name>
&rfc8300; <references>
&rfc8279; <name>Normative References</name>
</references> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<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, is described as a use case in the
BIER Use cases document. HTTP Level Multicast is used in today's video streami
ng and delivery services such as HLS, AR/VR etc., generally realized over IP Mul
ticast as well as other use cases such as software update delivery. A realizati
on of "HTTP Multicast" over "IP Multicast" is described for the video delivery u
se case. IP multicast is commonly used for IPTV services. DVB and BBF is also
developing a reference architecture for IP Multicast service. A few problems wi
th IPMC, such as waste of transmission bandwidth, increase in signaling when the
re are few users are described. Realization over BIER, through a BIER Multicast
Overlay Layer, is described as an alternative. How BIER Multicast Overlay oper
ation improves over IP Multicast, such as reduction in signaling, dynamic creati
on 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-respo
nse-01' />
</reference>
<!-- [rfced] [Reed2016] URL provided is correct - Also found URL https://ieeexpl
ore.ieee.org/document/7511036 DOI: 10.1109/ICC.2016.7511036 -->
<reference anchor="Reed2016" target="https://arxiv.org/pdf/1511.06069.p
df">
<front>
<title> Stateless multicast switching in software defined networks </t
itle>
<author initials="M.J." surname="Reed" />
<author initials="M." surname="Al-Naday" />
<author initials="N." surname="Thomas" />
<author initials="D." surname="Trossen" />
<author initials="S." surname="Spirou" />
<date year="2016"/>
</front>
<seriesInfo name="ICC" value="2016"/>
</reference>
<!-- [rfced] [Schlinker2017] URL provided is correct - also found URL https://dl <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
.acm.org/citation.cfm?id=3098853 --> ence.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7665.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8300.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8279.xml"/>
</references>
<references>
<name>Informative References</name>
<!-- &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="Schlinker2017" target="https://research.fb.com/wp-co <reference anchor="Reed2016" target="https://ieeexplore.ieee.org/documen
ntent/uploads/2017/08/sigcomm17-final177-2billion.pdf"> t/7511036">
<front> <front>
<title> Engineering Egress with Edge Fabric, Steering Oceans of Conten <title> Stateless multicast switching in software defined networks <
t to the World </title> /title>
<author initials="B." surname="Schlinker" /> <author initials="M.J." surname="Reed"/>
<author initials="H." surname="Kim" /> <author initials="M." surname="Al-Naday"/>
<author initials="T." surname="Cui" /> <author initials="N." surname="Thomas"/>
<author initials="E." surname="Katz-Bassett" /> <author initials="D." surname="Trossen"/>
<author initials="Harsha V." surname="Madhyastha" /> <author initials="G." surname="Petropoulos"/>
<author initials="I." surname="Cunha" /> <author initials="S." surname="Spirou"/>
<author initials="J." surname="Quinn" /> <date month="May" year="2016"/>
<author initials="S." surname="Hassan" />
<author initials="P." surname="Lapukhov" />
<author initials="H." surname="Zeng" />
<date year="2017"/>
</front>
<seriesInfo name="ACM SIGCOMM" value="2017"/>
</reference>
<!-- [rfced] [_3GPP_SBA] URL provided is correct - also found https://www.etsi.o </front>
rg/deliver/etsi_ts/129500_129599/129500/15.00.00_60/ts_129500v150000p.pdf --> <seriesInfo name="DOI" value="10.1109/ICC.2016.7511036"/>
<refcontent>IEEE ICC 2016</refcontent>
</reference>
<reference anchor="_3GPP_SBA" target="http://www.3gpp.org/ftp/Specs/htm <reference anchor="Schlinker2017" target="https://research.fb.com/wp-content/up
l-info/29500.htm"> loads/2017/08/sigcomm17-final177-2billion.pdf">
<front> <front>
<title> Technical Realization of Service Based Architecture </title> <title> Engineering Egress with Edge Fabric, Steering Oceans of Cont
<author> ent to the World </title>
<organization>3GPP</organization> <author initials="B." surname="Schlinker"/>
</author> <author initials="H." surname="Kim"/>
<date day="1" month="January" year="2018"/> <author initials="T." surname="Cui"/>
</front> <author initials="E." surname="Katz-Bassett"/>
<seriesInfo name="3GPP TS 29.500" value="0.4.0"/> <author initials="Harsha V." surname="Madhyastha"/>
<format type="" target="http://www.3gpp.org/ftp/Specs/html-info/29500.ht <author initials="I." surname="Cunha"/>
m"/> <author initials="J." surname="Quinn"/>
</reference> <author initials="S." surname="Hassan"/>
<author initials="P." surname="Lapukhov"/>
<author initials="H." surname="Zeng"/>
<date month="August" year="2017"/>
</front>
<refcontent>ACM SIGCOMM 2017</refcontent>
</reference>
<!-- [rfced] [_3GPP_SBA_ENHANCEMENT] Link is to a zip file which I did not check <reference 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 month="September" year="2019"/>
</front>
</reference>
<reference anchor="_3GPP_SBA_ENHANCEMENT" target="http://www.3gpp.org/ftp/ <reference anchor="SDO-3GPP-SBA-ENHANCEMENT" target="https://www.3gpp.or
tsg_sa/WG2_Arch/TSGS2_126_Montreal/Docs/S2-182904.zip"> g/ftp/tsg_sa/WG2_Arch/TSGS2_126_Montreal/Docs/S2-182904.zip">
<front> <front>
<title> New SID for Enhancements to the Service-Based 5G System Archit <title> New SID for Enhancements to the Service-Based 5G System Arch
ecture </title> itecture </title>
<author> <seriesInfo name="3GPP" value="S2-182904"/>
<organization>3GPP</organization> <author>
</author> <organization>3GPP</organization>
<date day="26" month="February" year="2018"/> </author>
</front> <date month="February" year="2018"/>
<seriesInfo name="3GPP S2-182904" value=""/> </front>
<format type="" target="http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_12 </reference>
6_Montreal/Docs/S2-182904.zip"/> </references>
</reference>
</references> </references>
<section anchor="Ack" numbered="false" toc="default">
<section anchor="Ack" title="Acknowledgements" numbered="no"> <name>Acknowledgements</name>
<t> <t>
The authors would like to thank Dirk von Hugo and Andrew Malis for The authors would like to thank Dirk von Hugo and Andrew Malis for
their reviews and valuable comments. We would also like to thank their reviews and valuable comments. We would also like to thank
Joel Halpern, the chair of the SFC WG, and Adrian Farrel for Joel Halpern, the chair of the SFC WG, and Adrian Farrel for
guiding us through the IETF Independent Submission Editor (ISE) guiding us through the IETF Independent Submission Editor (ISE)
path. path.
</t> </t>
</section> </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> </back>
</rfc> </rfc>
 End of changes. 106 change blocks. 
1317 lines changed or deleted 1612 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/