< draft-trossen-sfc-name-based-sff-04.txt   draft-trossen-sfc-name-based-sff-05.txt >
Network Working Group D. Trossen Network Working Group D. Trossen
Internet-Draft InterDigital Europe, Ltd Internet-Draft InterDigital Europe, Ltd
Intended status: Informational D. Purkayastha Intended status: Informational D. Purkayastha
Expires: October 19, 2019 A. Rahman Expires: November 16, 2019 A. Rahman
InterDigital Communications, LLC InterDigital Communications, LLC
April 17, 2019 May 15, 2019
Name-Based Service Function Forwarder (nSFF) component within SFC Name-Based Service Function Forwarder (nSFF) component within SFC
framework framework
draft-trossen-sfc-name-based-sff-04 draft-trossen-sfc-name-based-sff-05
Abstract Abstract
Many stringent requirements are imposed on today's network, such as Adoption of cloud and fog technology allows operators to deploy a
low latency, high availability and reliability in order to support single "Service Function" to multiple "Execution locations". The
several use cases such as IoT, Gaming, Content distribution, Robotics decision to steer traffic to a specific location may change
etc. Adoption of cloud and fog technology at the edge of the network frequently based on load, proximity etc. Under the current SFC
allows operator to deploy a single "Service Function" to multiple framework, steering traffic dynamically to the different execution
"Execution locations". The decision to steer traffic to a specific end points require a specific 're-chaining', i.e., a change in the
location may change frequently based on load, proximity etc. Under service function path reflecting the different IP endpoints to be
the current SFC framework, steering traffic dynamically to the used for the new execution points. This procedure may be complex and
different execution end points require a specific 're-chaining', take time. In order to simplify re-chaining and reduce the time to
i.e., a change in the service function path reflecting the different complete the procedure, we discuss separating the logical Service
IP endpoints to be used for the new execution points. This procedure Function Path from the specific execution end points. This can be
may be complex and take time. In order to simplify re-chaining and done by identifying the Service Functions using a name rather than a
reduce the time to complete the procedure, we discuss separating the routable IP endpoint (or Layer 2 address). This draft describes the
logical Service Function Path from the specific execution end points. necessary extensions, additional functions and protocol details in
This can be done by identifying the Service Functions using a name SFF (Service Function Forwarder) to handle name based relationships.
rather than a routable IP endpoint (or Layer 2 address). This draft
describes the necessary extensions, additional functions and protocol
details in SFF (Service Function Forwarder) to handle name based
relationships.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 19, 2019.
This Internet-Draft will expire on November 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Example use case: 5G control plane services . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Example use case: 5G control plane services . . . . . . . . . 4
3.1. Relevant part of SFC architecture . . . . . . . . . . . . 6 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Challenges with current framework . . . . . . . . . . . . 7 4.1. Relevant part of SFC architecture . . . . . . . . . . . . 6
4. Name based operation in SFF . . . . . . . . . . . . . . . . . 8 4.2. Challenges with current framework . . . . . . . . . . . . 7
4.1. General Idea . . . . . . . . . . . . . . . . . . . . . . 8 5. Name based operation in SFF . . . . . . . . . . . . . . . . . 8
4.2. Name-Based Service Function Path (nSFP) . . . . . . . . . 8 5.1. General Idea . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Name Based Network Locator Map (nNLM) . . . . . . . . . . 10 5.2. Name-Based Service Function Path (nSFP) . . . . . . . . . 8
4.4. Name-based Service Function Forwarder (nSFF) . . . . . . 11 5.3. Name Based Network Locator Map (nNLM) . . . . . . . . . . 10
4.5. High Level Architecture . . . . . . . . . . . . . . . . . 12 5.4. Name-based Service Function Forwarder (nSFF) . . . . . . 12
4.6. Operational Steps . . . . . . . . . . . . . . . . . . . . 13 5.5. High Level Architecture . . . . . . . . . . . . . . . . . 13
5. nSFF Forwarding Operations . . . . . . . . . . . . . . . . . 15 5.6. Operational Steps . . . . . . . . . . . . . . . . . . . . 14
5.1. nSFF Protocol Layers . . . . . . . . . . . . . . . . . . 15 6. nSFF Forwarding Operations . . . . . . . . . . . . . . . . . 16
5.2. nSFF Operations . . . . . . . . . . . . . . . . . . . . . 17 6.1. nSFF Protocol Layers . . . . . . . . . . . . . . . . . . 16
5.2.1. Forwarding between nSFFs and nSFF-NR . . . . . . . . 17 6.2. nSFF Operations . . . . . . . . . . . . . . . . . . . . . 18
5.2.2. SF Registration . . . . . . . . . . . . . . . . . . . 19 6.2.1. Forwarding between nSFFs and nSFF-NR . . . . . . . . 18
5.2.3. Local SF Forwarding . . . . . . . . . . . . . . . . . 20 6.2.2. SF Registration . . . . . . . . . . . . . . . . . . . 20
5.2.4. Handling of HTTP responses . . . . . . . . . . . . . 20 6.2.3. Local SF Forwarding . . . . . . . . . . . . . . . . . 21
5.2.5. Remote SF Forwarding . . . . . . . . . . . . . . . . 21 6.2.4. Handling of HTTP responses . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6.2.5. Remote SF Forwarding . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Informative References . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The requirements on today's networks are very diverse, enabling The requirements on today's networks are very diverse, enabling
multiple use cases such as IoT, Content Distribution, Gaming and multiple use cases such as IoT, Content Distribution, Gaming and
Network functions such as Cloud RAN and 5G control planes based on a Network functions such as Cloud RAN and 5G control planes based on a
service-based architecture . These services are deployed, provisioned service-based architecture. These services are deployed, provisioned
and managed using Cloud based techniques as seen in the IT world. and managed using Cloud based techniques as seen in the IT world.
Virtualization of compute and storage resources is at the heart of Virtualization of compute and storage resources is at the heart of
providing (often web) services to end users with the ability to providing (often web) services to end users with the ability to
quickly provisioning such virtualized service endpoints through, quickly provisioning such virtualized service endpoints through,
e.g., container based techniques. This creates a dynamicity with the e.g., container based techniques. This creates a dynamicity with the
capability to dynamically compose new services from available capability to dynamically compose new services from available
services as well as move a service instance in response to user services as well as move a service instance in response to user
mobility or resource availability where desirable. When moving from mobility or resource availability where desirable. When moving from
a pure 'distant cloud' model to one of localized micro data centers a pure 'distant cloud' model to one of localized micro data centers
with regional, metro or even street level, often called 'edge' data with regional, metro or even street level, often called 'edge' data
centers, such virtualized service instances can be instantiated in centers, such virtualized service instances can be instantiated in
topologically different locations with the overall 'distant' data topologically different locations with the overall 'distant' data
center now being transformed into a network of distributed ones. The center now being transformed into a network of distributed ones. The
reaction of content providers, like Facebook, Google, NetFlix and reaction of content providers, like Facebook, Google, NetFlix and
others, are not just relying on deploying content server at the others, are not just relying on deploying content server at the
ingress of the customer network. Instead the trend is towards ingress of the customer network. Instead the trend is towards
deploying multiple POPs within the customer network, those POPs being deploying multiple POPs within the customer network, those POPs being
connected through proprietary mechanisms [Schlinker2017] to push connected through proprietary mechanisms [Schlinker2017] to push
content. content.
The Service Function Chaining (SFC) framework [RFC7665] allows Nnetwork operators as well as service providers, follow the Service
Function Chaining (SFC) framework, as defined in [RFC7665] allows
network operators as well as service providers to compose new network operators as well as service providers to compose new
services by chaining individual "Service Functions (SFs)". Such services by chaining individual "Service Functions (SFs)". Such
chains are expressed through explicit relationships of functional chains are expressed through explicit relationships of functional
components (the service functions), realized through their direct components (the service functions), realized through their direct
Layer 2 (e.g., MAC address) or Layer 3 (e.g., IP address) Layer 2 (e.g., MAC address) or Layer 3 (e.g., IP address)
relationship as defined through next hop information that is being relationship as defined through next hop information that is being
defined by the network operator, see Section 3 for more background on defined by the network operator, see Section 4 for more background on
SFC. SFC.
In a dynamic service environment of distributed data centers as the In a dynamic service environment of distributed data centers as the
one outlined above, with the ability to create and recreate service one outlined above, with the ability to create and recreate service
endpoints frequently, the SFC framework requires to reconfigure the endpoints frequently, the SFC framework requires to reconfigure the
existing chain through information based on the new relationships, existing chain through information based on the new relationships,
causing overhead in a number of components, specifically the causing overhead in a number of components, specifically the
orchestrator that initiates the initial service function chain and orchestrator that initiates the initial service function chain and
any possible reconfiguration. any possible reconfiguration.
This document describes how such changes can be handled without This document describes how such changes can be handled without
involving the initiation of new and reconfigured SFCs by lifting the involving the initiation of new and reconfigured SFCs by lifting the
chaining relationship from Layer 2 and 3 information to that of chaining relationship from Layer 2 and 3 information to that of
service function 'names', such as names for instance being expressed service function 'names', such as names for instance being expressed
as URIs. In order to transparently support such named relationships, as URIs. In order to transparently support such named relationships,
we propose to embed the necessary functionality directly into the we propose to embed the necessary functionality directly into the
Service Function Forwarder (SFF, see [RFC7665]). With that, the SFF Service Function Forwarder (SFF), as described in [RFC7665]). With
described in this document allows for keeping an existing SFC intact, that, the SFF described in this document allows for keeping an
as described by its service function path (SFP), while enabling the existing SFC intact, as described by its service function path (SFP),
selection of an appropriate service function endpoint(s) during the while enabling the selection of an appropriate service function
traversal of packets through the SFC. endpoint(s) during the traversal of packets through the SFC.
2. Example use case: 5G control plane services 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Example use case: 5G control plane services
We exemplify the need for chaining service functions at the level of 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 a service name through a use case stemming from the current 3GPP Rel
16 work on Service Based Architecture (SBA) [_3GPP_SBA], 16 work on Service Based Architecture (SBA) [_3GPP_SBA],
[_3GPP_SBA_ENHANCEMENT]. In this work, mobile network control planes [_3GPP_SBA_ENHANCEMENT]. In this work, mobile network control planes
are proposed to be realized by replacing the traditional network are proposed to be realized by replacing the traditional network
function interfaces with a fully service-based one. HTTP was chosen function interfaces with a fully service-based one. HTTP was chosen
as the application layer protocol for exchanging suitable service as the application layer protocol for exchanging suitable service
requests [_3GPP_SBA]. With this in mind, the exchange between, say requests [_3GPP_SBA]. With this in mind, the exchange between, say
the 3GPP (Rel. 15) defined Session Management Function (SMF) and the the 3GPP (Rel. 15) defined Session Management Function (SMF) and the
skipping to change at page 5, line 50 skipping to change at page 6, line 11
A device may access multiple Network Slices simultaneously through a A device may access multiple Network Slices simultaneously through a
single RAN. The device may provide Network Slice Selection single RAN. The device may provide Network Slice Selection
Assistance Information (NSSAI) parameters to the network to help it Assistance Information (NSSAI) parameters to the network to help it
select a RAN and a Core network part of a slice instance. Part of select a RAN and a Core network part of a slice instance. Part of
the control plane, the Common Control Network Function (CCNF), the the control plane, the Common Control Network Function (CCNF), the
Network Slice Selection Function (NSSF) is in charge of selecting Network Slice Selection Function (NSSF) is in charge of selecting
core Network Slice instances. The Classifier, as described in SFC core Network Slice instances. The Classifier, as described in SFC
architecture, may reside in the user terminal or at the eNB. These architecture, may reside in the user terminal or at the eNB. These
service functions can be configured to be part of a Service Function service functions can be configured to be part of a Service Function
Chain. We can also say that some of the configurations of the Chain. We can also say that some of the configurations of the
Service Function Path may change at the execution time. E.g. SMF Service Function Path may change at the execution time. For example,
may be relocated as user moves and a new SMF may be included in the the SMF may be relocated as user moves and a new SMF may be included
Service Function Path based on user location. The following diagram in the Service Function Path based on user location. The following
in Figure 1 shows the example Service Function Chain described here. diagram in Figure 1 shows the example Service Function Chain
described here.
+------+ +---------+ +-----+ +-----+ +------+ +---------+ +-----+ +-----+
| User | | Slice | | | | | | User | | Slice | | | | |
| App |-->| Control |->| AMF |-->| SMF |--> | App |-->| Control |->| AMF |-->| SMF |-->
| Fn | | Function| | | | | | Fn | | Function| | | | |
+------+ +---------+ +-----+ +-----+ +------+ +---------+ +-----+ +-----+
Figure 1: Mapping SFC onto Service Function Execution Points along a Figure 1: Mapping SFC onto Service Function Execution Points along a
Service Function Path Service Function Path
3. Background 4. Background
[RFC7665] describes an architecture for the specification, creation, Service Function Chains (SFCs) shall be specified, created and
and ongoing maintenance of Service Function Chains (SFCs). It maintained as described in [RFC7665]. It includes architectural
includes architectural concepts, principles, and components used in concepts, principles, and components used in the construction of
the construction of composite services through deployment of SFCs. composite services through deployment of SFCs. In the following, we
In the following, we outline the parts of this SFC architecture outline the parts of this SFC architecture relevant for our proposed
relevant for our proposed extension, followed by the challenges with extension, followed by the challenges with this current framework in
this current framework in the light of our example use case. the light of our example use case.
3.1. Relevant part of SFC architecture 4.1. Relevant part of SFC architecture
SFC Architecture [RFC7665], describes architectural components such SFC Architecture, as defined in [RFC7665], describes architectural
as Service Function (SF), Classifier, and Service Function Forwarder components such as Service Function (SF), Classifier, and Service
(SFF). It describes the Service Function Path (SFP) as the logical Function Forwarder (SFF). It describes the Service Function Path
path of an SFC. Forwarding traffic along such SFP is the (SFP) as the logical path of an SFC. Forwarding traffic along such
responsibility of the SFF. For this, the SFFs in a network maintain SFP is the responsibility of the SFF. For this, the SFFs in a
the requisite SFP forwarding information. Such SFP forwarding network maintain the requisite SFP forwarding information. Such SFP
information is associated with a service path identifier (SPI) that forwarding information is associated with a service path identifier
is used to uniquely identify an SFP. The service forwarding state is (SPI) that is used to uniquely identify an SFP. The service
represented by the Service Index (SI) and enables an SFF to identify forwarding state is represented by the Service Index (SI) and enables
which SFs of a given SFP should be applied, and in what order. The an SFF to identify which SFs of a given SFP should be applied, and in
SFF also has information that allows it to forward packets to the what order. The SFF also has information that allows it to forward
next SFF after applying local service functions. packets to the next SFF after applying local service functions.
The operational steps to forward traffic are then as follows: Traffic The operational steps to forward traffic are then as follows: Traffic
arrives at an SFF from the network. The SFF determines the arrives at an SFF from the network. The SFF determines the
appropriate SF the traffic should be forwarded to via information appropriate SF the traffic should be forwarded to via information
contained in the SFC encapsulation. After SF processing, the traffic contained in the SFC encapsulation. After SF processing, the traffic
is returned to the SFF, and, if needed, is forwarded to another SF 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., 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 to an SF with a different SFF) in the SFP, the SFF further
encapsulates the traffic in the appropriate network transport encapsulates the traffic in the appropriate network transport
protocol and delivers it to the network for delivery to the next SFF protocol and delivers it to the network for delivery to the next SFF
along the path. Related to this forwarding responsibility, an SFF along the path. Related to this forwarding responsibility, an SFF
should be able to interact with metadata. should be able to interact with metadata.
3.2. Challenges with current framework 4.2. Challenges with current framework
As outlined in previous section, the Service Function Path defines an As outlined in previous section, the Service Function Path defines an
ordered sequence of specific Service Functions instances being used ordered sequence of specific Service Functions instances being used
for the interaction between initiator and service functions along the for the interaction between initiator and service functions along the
SFP. These service functions are addressed by IP (or any L2/MAC) SFP. These service functions are addressed by IP (or any L2/MAC)
addresses and defined as next hop information in the network locator addresses and defined as next hop information in the network locator
maps of traversing SFF nodes. maps of traversing SFF nodes.
As outlined in our use case, however, the service provider may want As outlined in our use case, however, the service provider may want
to provision SFC nodes based on dynamically spun up service function to provision SFC nodes based on dynamically spun up service function
skipping to change at page 7, line 40 skipping to change at page 7, line 50
virtualization techniques), the current model and realization of SFC virtualization techniques), the current model and realization of SFC
could lead to reducing the flexibility of service providers and could lead to reducing the flexibility of service providers and
increasing the management complexity incurred by the frequent changes increasing the management complexity incurred by the frequent changes
of (service) forwarding information in the respective SFF nodes. of (service) forwarding information in the respective SFF nodes.
This is because any change of the SFP (and possibly next hop info) This is because any change of the SFP (and possibly next hop info)
will need to go through suitable management cycles. will need to go through suitable management cycles.
To address these challenges through a suitable solution, we identify To address these challenges through a suitable solution, we identify
the following requirements: the following requirements:
o Relations between Service Execution Points MUST be abstracted so o Relations between Service Execution Points must be abstracted so
that, from an SFP point of view, the Logical Path never changes. that, from an SFP point of view, the Logical Path never changes.
o Deriving the Service Execution Points from the abstract SFP SHOULD o Deriving the Service Execution Points from the abstract SFP should
be fast and incur minimum delay. be fast and incur minimum delay.
o Identification of the Service Execution Points SHOULD not use a o Identification of the Service Execution Points should not use a
combination of Layer 2 or Layer 3 mechanisms. combination of Layer 2 or Layer 3 mechanisms.
The next section outlines a solution to address the issue, allowing The next section outlines a solution to address the issue, allowing
for keeping SFC information (represented in its SFP) intact while for keeping SFC information (represented in its SFP) intact while
addressing the desired flexibility of the service provider. addressing the desired flexibility of the service provider.
4. Name based operation in SFF 5. Name based operation in SFF
4.1. General Idea 5.1. General Idea
The general idea is two-pronged. Firstly, we elevate the definition The general idea is two-pronged. Firstly, we elevate the definition
of a Service Function Path onto the level of 'name-based of a Service Function Path onto the level of 'name-based
interactions' rather than limiting SFPs to Layer 3 or Layer 2 interactions' rather than limiting SFPs to Layer 3 or Layer 2
information only. Secondly, we extend the operations of the SFF to information only. Secondly, we extend the operations of the SFF to
allow for forwarding decisions that take into account such name-based allow for forwarding decisions that take into account such name-based
interaction while remaining backward compatible to the current SFC interaction while remaining backward compatible to the current SFC
architecture [RFC7665]. In the following sections, we outline these architecture, as defined in [RFC7665]. In the following sections, we
two components of our solution. outline these two components of our solution.
If the next hop information in the Network Locator Map (NLM) is If the next hop information in the Network Locator Map (NLM) is
described using L2/L3 identifier, the name-based SFF (nSFF) may described using L2/L3 identifier, the name-based SFF (nSFF) may
operate as described for [traditional] SFF in [RFC7665]. On the operate as described for [traditional] SFF, as defined in [RFC7665].
other hand, if the next hop information in the NLM is described as a On the other hand, if the next hop information in the NLM is
name, then the nSFF operates as described in the following sections. described as a name, then the nSFF operates as described in the
following sections.
In the following sections, we outline the two components of our In the following sections, we outline the two components of our
solution. solution.
4.2. Name-Based Service Function Path (nSFP) 5.2. Name-Based Service Function Path (nSFP)
In the existing SFC framework [RFC7665], as outlined in Section 3, The existing SFC framework is defined in [RFC7665]. Section 4
the SFP information is representing path information based on Layer 2 outlines that the SFP information is representing path information
or 3 information, i.e., MAC or IP addresses , causing the based on Layer 2 or 3 information, i.e., MAC or IP addresses, causing
aforementioned frequent adaptations in cases of execution point the aforementioned frequent adaptations in cases of execution point
changes. Instead, we introduce the notion of a 'name-based service changes. Instead, we introduce the notion of a "name-based service
function path (nSFP)' function path (nSFP)".
In today's networking terms, any identifier can be treated as a name In today's networking terms, any identifier can be treated as a name
but we will illustrate the realization of a "Name based SFP" through but we will illustrate the realization of a "Name based SFP" through
extended SFF operations (see Section 5) based on URIs as names and extended SFF operations (see Section 6) based on URIs as names and
HTTP as the protocol of exchanging information . Here, URIs are being HTTP as the protocol of exchanging information. Here, URIs are being
used to name for a Service Function along the nSFP. It is to be used to name for a Service Function along the nSFP. It is to be
noted that the Name based SFP approach is not restricted to HTTP (as noted that the Name based SFP approach is not restricted to HTTP (as
the protocol) and URIs (as next hop identifier within the SFP). the protocol) and URIs (as next hop identifier within the SFP).
Other identifiers such as an IP address itself can also be used and Other identifiers such as an IP address itself can also be used and
are interpreted as a 'name' in the nSFP . With this, our notion of are interpreted as a 'name' in the nSFP. IP addresses as well as
the nSFP goes beyond the initial proposals made in
[I-D.purkayastha-sfc-service-indirection], which limited the notion
of a 'name' to a URL (uniform resource locator), commonly used in the
addressing of HTTP requests. In other words, IP addresses as well as
fully qualified domain names forming complex URIs (uniform resource fully qualified domain names forming complex URIs (uniform resource
identifiers), such as www.foo.com/service_name1, are all captured by identifiers), such as www.example.com/service_name1, are all captured
the notion of 'name' in this draft. by the notion of 'name' in this draft.
Generally, nSFPs are defined as an ordered sequence of the "name" of Generally, nSFPs are defined as an ordered sequence of the "name" of
Service Functions (SF) and a typical name-based Service Function Path Service Functions (SF) and a typical name-based Service Function Path
may look like: 192.168.x.x -> www.foo.com -> www.foo2.com/service1 -> may look like: 192.0.x.x -> www.example.com -> www.example2.com/
www.foo2.com/service2 service1 -> www.example2.com/service2.
Our use case in Section 2 can then be represented as an ordered named Our use case in Section 3 can then be represented as an ordered named
sequence. An example for a session initiation that involves an sequence. An example for a session initiation that involves an
authentication procedure, this could look like 192.168.x.x -> authentication procedure, this could look like 192.0.x.x ->
smf.3gpp.org/session_initiate -> amf.3gpp.org/auth -> smf.3gpp.org/ smf.example.org/session_initiate -> amf.example.org/auth ->
session_complete -> 192.168.x.x [Note that this example is only a smf.example.org/session_complete -> 192.0.x.x. [Note that this
conceptual one, since the exact nature of any future SBA-based example is only a conceptual one, since the exact nature of any
exchange of 5G control plane functions is yet to be defined by future SBA-based exchange of 5G control plane functions is yet to be
standardization bodies such as 3GPP] defined by standardization bodies such as 3GPP].
In accordance with our use case in Section 2, any of these named In accordance with our use case in Section 3, any of these named
services can potentially be realized through more than one replicated services can potentially be realized through more than one replicated
SF instances. This leads to make dynamic decision on where to send SF instances. This leads to make dynamic decision on where to send
packets along the SAME service function path information, being packets along the SAME service function path information, being
provided during the execution of the SFC. Through elevating the SFP provided during the execution of the SFC. Through elevating the SFP
onto the notion of name-based interactions, the SFP will remain the onto the notion of name-based interactions, the SFP will remain the
same even if those specific execution points change for a specific same even if those specific execution points change for a specific
service interaction. service interaction.
The following diagram in Figure 2, describes this name-based SFP The following diagram in Figure 2, describes this name-based SFP
concept and the resulting mapping of those named interactions onto concept and the resulting mapping of those named interactions onto
(possibly) replicated instances. (possibly) replicated instances.
+---------------------------------------------------------------+ +---------------------------------------------------------------+
|SERVICE LAYER | |SERVICE LAYER |
| 192.168.x.x --> www.foo.com --> www.foo2.com --> www.fooN.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 |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 2: Mapping SFC onto Service Function Execution Points along a Figure 2: Mapping SFC onto Service Function Execution Points along a
Service Function Path based on Virtualized Service Function Instance Service Function Path based on Virtualized Service Function Instance
4.3. Name Based Network Locator Map (nNLM) 5.3. Name Based Network Locator Map (nNLM)
In order to forward a packet within a name-based SFP, we need to In order to forward a packet within a name-based SFP, we need to
extend the network locator map as originally defined in [RFC8300] extend the network locator map as defined in [RFC8300] with the
with the ability to consider name relations based on URIs as well as ability to consider name relations based on URIs as well as high-
high-level transport protocols such as HTTP for means of SFC packet level transport protocols such as HTTP for means of SFC packet
forwarding. Another example for SFC packet forwarding could be that forwarding. Another example for SFC packet forwarding could be that
of CoAP. of CoAP.
The extended Network Locator Map or name-based Network Locator Map The extended Network Locator Map or name-based Network Locator Map
(nNLM) is shown in Figure 3 as an example for www.foo.com being part (nNLM) is shown in Figure 3 as an example for www.example.com being
of the nSFP. Such extended nNLM is stored at each SFF throughout the part of the nSFP. Such extended nNLM is stored at each SFF
SFC domain with suitable information populated to the nNLM during the throughout the SFC domain with suitable information populated to the
configuration phase nNLM during the configuration phase.
+------+------+---------------------+-----------------------------+ +------+------+---------------------+-----------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation (TE)| | SPI | SI | Next Hop(s) | Transport Encapsulation (TE)|
+------+------+---------------------+-----------------------------+ +------+------+---------------------+-----------------------------+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe | | 10 | 255 | 192.0.2.1 | VXLAN-gpe |
| | | | | | | | | |
| 10 | 254 | 198.51.100.10 | GRE | | 10 | 254 | 198.51.100.10 | GRE |
| | | | | | | | | |
| 10 | 253 | www.foo.com | HTTP | | 10 | 253 | www.example.com | HTTP |
----------------------------------------------------------------- -----------------------------------------------------------------
| | | | | | | | | |
| 40 | 251 | 198.51.100.15 | GRE | | 40 | 251 | 198.51.100.15 | GRE |
| | | | | | | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet | | 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | | | | | | |
| 15 | 212 | Null (end of path) | None | | 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-----------------------------+ +------+------+---------------------+-----------------------------+
Figure 3: Name-based Network Locator Map Figure 3: Name-based Network Locator Map
skipping to change at page 11, line 25 skipping to change at page 12, line 25
| 40 | 251 | 198.51.100.15 | GRE | | 40 | 251 | 198.51.100.15 | GRE |
| | | | | | | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet | | 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | | | | | | |
| 15 | 212 | Null (end of path) | None | | 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-----------------------------+ +------+------+---------------------+-----------------------------+
Figure 4: Name-based Network Locator Map with Implicit Name Figure 4: Name-based Network Locator Map with Implicit Name
information information
4.4. Name-based Service Function Forwarder (nSFF) 5.4. Name-based Service Function Forwarder (nSFF)
While [I-D.purkayastha-sfc-service-indirection] outlined the It is desirable to extend the SFF of the SFC underlay to handle nSFPs
realization of forwarding packets in URL-based interaction through transparently and without the need to insert any service function
HTTP via a specific function (called Service Request Routing (SRR) in into the nSFP. Such extended name-based SFF would then be
[I-D.purkayastha-sfc-service-indirection] ), it is desirable to
extend the SFF of the SFC underlay in order to handle nSFPs
transparently and without the need to insert a special (SRR) service
function into the nSFP. Such extended name-based SFF would then be
responsible for forwarding a packet in the SFC domain as per the responsible for forwarding a packet in the SFC domain as per the
definition of the (extended) nSFP. definition of the (extended) nSFP.
In our exemplary realization for an extended SFF, the solution In our exemplary realization for an extended SFF, the solution
described in this document uses HTTP as the protocol of forwarding 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 SFC packets to the next (name-based) hop in the nSFP. The URI in the
HTTP transaction are the names in our nSFP information, which will be HTTP transaction are the names in our nSFP information, which will be
used for name based forwarding. used for name based forwarding.
Following our reasoning so far, HTTP requests (and more specifically Following our reasoning so far, HTTP requests (and more specifically
skipping to change at page 12, line 7 skipping to change at page 13, line 4
that enter the SFC domain. In the existing SFC framework, typically that enter the SFC domain. In the existing SFC framework, typically
an IP payload is assumed to be a packet entering the SFC domain. an IP payload is assumed to be a packet entering the SFC domain.
This packet is forwarded to destination nodes using the L2 This packet is forwarded to destination nodes using the L2
encapsulation. Any layer 2 network can be used as an underlay encapsulation. Any layer 2 network can be used as an underlay
network. This notion is now extended to packets being possibly part network. This notion is now extended to packets being possibly part
of a entire higher layer application, such as HTTP requests. The of a entire higher layer application, such as HTTP requests. The
handling of any intermediate layers such as TCP, IP is left to the handling of any intermediate layers such as TCP, IP is left to the
realization of the (extended) SFF operations towards the next (named) realization of the (extended) SFF operations towards the next (named)
hop. For this, we will first outline the general lifecycle of an SFC hop. For this, we will first outline the general lifecycle of an SFC
packet in the following subsection, followed by two examples for packet in the following subsection, followed by two examples for
determining next hop information in Section 5.2.3, finalized by a determining next hop information in Section 6.2.3, finalized by a
layered view on the realization of the nSFF in Section 5.2.4 layered view on the realization of the nSFF in Section 6.2.4.
4.5. High Level Architecture 5.5. High Level Architecture
+----------+ +----------+
| SF1 | +--------+ +------+ | SF1 | +--------+ +------+
| instance |\ | NR | | SF2 | | instance |\ | NR | | SF2 |
+----------+ \ +--------+ +------+ +----------+ \ +--------+ +------+
\ || || \ || ||
+------------+ \ +-------+ +---------+ +---------+ +-------+ +------------+ \ +-------+ +---------+ +---------+ +-------+
| Classifier |---| nSFF1 |---|Forwarder|---|Forwarder|---| nSFF2 | | Classifier |---| nSFF1 |---|Forwarder|---|Forwarder|---| nSFF2 |
+------------+ +-------+ +---------+ +---------+ +-------+ +------------+ +-------+ +---------+ +---------+ +-------+
|| ||
skipping to change at page 13, line 8 skipping to change at page 14, line 6
The Name Resolver is a new functional component, capable of The Name Resolver is a new functional component, capable of
identifying the execution end points, where a "named SF" is running, identifying the execution end points, where a "named SF" is running,
triggered by suitable resolution requests sent by the nSFF. Though triggered by suitable resolution requests sent by the nSFF. Though
this is similar to DNS function, but it is not same. It does not use this is similar to DNS function, but it is not same. It does not use
DNS protocols or data records. A new procedure to determine the DNS protocols or data records. A new procedure to determine the
suitable routing/forwarding information towards the Nsff (name-based suitable routing/forwarding information towards the Nsff (name-based
SFF) serving the next hop of the SFP (Service Function Path) is used. SFF) serving the next hop of the SFP (Service Function Path) is used.
The details is described later. The details is described later.
The other functional components such as Classifier, SF are same as The other functional components such as Classifier, SF are same as
described in SFC architecture [RFC7665], while the Forwarders shown described in SFC architecture, as defined in [RFC7665], while the
in the above diagram are traditional Layer 2 switches. Forwarders shown in the above diagram are traditional Layer 2
switches.
4.6. Operational Steps 5.6. Operational Steps
In the proposed solution, the operations are realized by the name- In the proposed solution, the operations are realized by the name-
based SFF, called nSFF. We utilize the high-level architecture in based SFF, called nSFF. We utilize the high-level architecture in
Figure 5 to describe the traversal between two service function Figure 5 to describe the traversal between two service function
instances of an nSFP-based transactions in an example chain of : instances of an nSFP-based transactions in an example chain of :
192.168.x.x -> SF1 (www.foo.com) -> SF2 (www.foo2.com) -> SF3 -> ... 192.0.x.x -> SF1 (www.example.com) -> SF2 (www.example2.com) -> SF3
Service Function 3 (SF3)is assumed to be a classical Service -> ... Service Function 3 (SF3)is assumed to be a classical Service
Function, hence existing SFC mechanisms can be used to reach it and Function, hence existing SFC mechanisms can be used to reach it and
will not be considered in this example. will not be considered in this example.
According to the SFC lifecycle [RFC7665] and based on our example According to the SFC lifecycle, as defined in [RFC7665], based on our
chain above, the traffic originates from a Classifier or another SFF example chain above, the traffic originates from a Classifier or
on the left. The traffic is processed by the incoming nSFF1 (on the another SFF on the left. The traffic is processed by the incoming
left side) through the following steps. The traffic exits at nSFF2. nSFF1 (on the left side) through the following steps. The traffic
exits at nSFF2.
o Step 1: At nSFF1 the following nNLM is assumed o Step 1: At nSFF1 the following nNLM is assumed
+------+------+---------------------+----------------------------+ +------+------+---------------------+----------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation(TE)| | SPI | SI | Next Hop(s) | Transport Encapsulation(TE)|
+------+------+---------------------+----------------------------+ +------+------+---------------------+----------------------------+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe | | 10 | 255 | 192.0.2.1 | VXLAN-gpe |
| | | | | | | | | |
| 10 | 254 | 198.51.100.10 | GRE | | 10 | 254 | 198.51.100.10 | GRE |
| | | | | | | | | |
| 10 | 253 | www.foo.com | HTTP | | 10 | 253 | www.example.com | HTTP |
| | | | | | | | | |
| 10 | 252 | www.foo2.com | HTTP | | 10 | 252 | www.example2.com | HTTP |
| | | | | | | | | |
| 40 | 251 | 198.51.100.15 | GRE | | 40 | 251 | 198.51.100.15 | GRE |
| | | | | | | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet | | 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | | | | | | |
| 15 | 212 | Null (end of path) | None | | 15 | 212 | Null (end of path) | None |
+------+------+---------------------+----------------------------+ +------+------+---------------------+----------------------------+
Figure 6: nNLM at nSFF1 Figure 6: nNLM at nSFF1
o Step 2: nSFF1 removes the previous transport encapsulation (TE) o Step 2: nSFF1 removes the previous transport encapsulation (TE)
for any traffic originating from another SFF or classifier for any traffic originating from another SFF or classifier
(traffic from an SF instance does not carry any TE and is (traffic from an SF instance does not carry any TE and is
therefore directly processed at the nSFF). therefore directly processed at the nSFF).
o Step 3: nSFF1 then processes the Network Service Header (NSH) o Step 3: nSFF1 then processes the Network Service Header (NSH)
[RFC8300] information to identify the next SF at the nSFP level by information, as defined in [RFC8300], to identify the next SF at
mapping the NSH information to the appropriate entry in its nNLM the nSFP level by mapping the NSH information to the appropriate
(see Figure 6) based on the provided SPI/SI information in the NSH entry in its nNLM (see Figure 6) based on the provided SPI/SI
(see Section 3) in order to determine the name-based identifier of information in the NSH (see Section 4) in order to determine the
the next hop SF. With such nNLM in mind, the nSFF searches the name-based identifier of the next hop SF. With such nNLM in mind,
map for SPI = 10 and SI = 253. It identifies the next hop as = the nSFF searches the map for SPI = 10 and SI = 253. It
www.foo.com and HTTP as the protocol to be used. Given the next identifies the next hop as = www.example.com and HTTP as the
hop resides locally , the SFC packet is forwarded to the SF1 protocol to be used. Given the next hop resides locally, the SFC
instance of www.foo.com. Note that the next hop could also be packet is forwarded to the SF1 instance of www.example.com. Note
identified from the provided HTTP request, if the next hop that the next hop could also be identified from the provided HTTP
information was identified as a generic HTTP service, as defined request, if the next hop information was identified as a generic
in Section 5.3. HTTP service, as defined in Section 5.3.
o Step 4: The SF1 instance then processes the received SFC packet o Step 4: The SF1 instance then processes the received SFC packet
according to its service semantics and modifies the NSH by setting according to its service semantics and modifies the NSH by setting
SPI = 10, SI = 252 for forwarding the packet along the SFP. It SPI = 10, SI = 252 for forwarding the packet along the SFP. It
then forwards the SFC packet to its local nSFF, i.e., nSFF1. then forwards the SFC packet to its local nSFF, i.e., nSFF1.
o Step 5: nSSF1 processes the NSH of the SFC packet again, now with o Step 5: nSSF1 processes the NSH of the SFC packet again, now with
the NSH modified (SPI = 10, SI = 252) by the SF1 instance. It the NSH modified (SPI = 10, SI = 252) by the SF1 instance. It
retrieves the next hop information from its nNLM in Figure 6, to retrieves the next hop information from its nNLM in Figure 6, to
be www.foo2.com. Due to this SF not being locally available , the be www.example2.com. Due to this SF not being locally available,
nSFF consults any locally available information regarding routing/ the nSFF consults any locally available information regarding
forwarding towards a suitable nSFF that can serve this next hop. routing/forwarding towards a suitable nSFF that can serve this
next hop.
o Step 6: If such information exists, the Packet (plus the NSH o Step 6: If such information exists, the Packet (plus the NSH
information) is marked to be sent towards the nSFF serving the information) is marked to be sent towards the nSFF serving the
next hop based on such information in step 8. next hop based on such information in step 8.
o Step 7: If such information does not exist, nSFF1 consults the o Step 7: If such information does not exist, nSFF1 consults the
Name Resolver (NR) to determine the suitable routing/forwarding Name Resolver (NR) to determine the suitable routing/forwarding
information towards the identified nSFF serving the next hop of information towards the identified nSFF serving the next hop of
the SFP. For future SFC packets towards this next hop, such the SFP. For future SFC packets towards this next hop, such
resolved information may be locally cached , avoiding to contact resolved information may be locally cached, avoiding to contact
the Name Resolver for every SFC packet forwarding. The packet is the Name Resolver for every SFC packet forwarding. The packet is
now marked to be sent via the network in step 8. now marked to be sent via the network in step 8.
o Step 8: Utilizing the forwarding information determined in steps 6 o Step 8: Utilizing the forwarding information determined in steps 6
or 7, nSFF1 adds the suitable transport encapsulation (TE) for the or 7, nSFF1 adds the suitable transport encapsulation (TE) for the
SFC packet before forwarding via the forwarders in the network SFC packet before forwarding via the forwarders in the network
towards the next nSFF22. towards the next nSFF22.
o Step 9: When the Packet (+NSH+TE) arrives at the outgoing nSFF2, o 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 i.e., the nSFF serving the identified next hop of the SFP, removes
the TE and processes the NSH to identify the next hop information. the TE and processes the NSH to identify the next hop information.
At nSFF2 the nNLM in Figure 7 is assumed. Based on this nNLM and At nSFF2 the nNLM in Figure 7 is assumed. Based on this nNLM and
NSH information where SPI = 10 and SI = 252, nSFF2 identifies the NSH information where SPI = 10 and SI = 252, nSFF2 identifies the
next SF as www.foo2.com. next SF as www.example2.com.
+------+------+---------------------+-----------------------------+ +------+------+---------------------+-----------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation (TE)| | SPI | SI | Next Hop(s) | Transport Encapsulation (TE)|
+------+------+---------------------+-----------------------------+ +------+------+---------------------+-----------------------------+
| | | | | | | | | |
| 10 | 252 | www.foo2.com | HTTP | | 10 | 252 | www.example2.com | HTTP |
| | | | | | | | | |
| 40 | 251 | 198.51.100.15 | GRE | | 40 | 251 | 198.51.100.15 | GRE |
| | | | | | | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet | | 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | | | | | | |
| 15 | 212 | Null (end of path) | None | | 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-----------------------------+ +------+------+---------------------+-----------------------------+
Figure 7: nNLM at SFF2 Figure 7: nNLM at SFF2
o Step 10: If the next hop is locally registered at the nSFF, it o Step 10: If the next hop is locally registered at the nSFF, it
forwards the packet (+NSH) to the service function instance, using forwards the packet (+NSH) to the service function instance, using
suitable IP/MAC methods for doing so. suitable IP/MAC methods for doing so.
o Step 11: Otherwise, the outgoing nSFF adds a new TE information to o Step 11: Otherwise, the outgoing nSFF adds a new TE information to
the packet and forwards the packet (+NSH+TE) to the next SFF or the packet and forwards the packet (+NSH+TE) to the next SFF or
boundary node, as shown in Figure 7. boundary node, as shown in Figure 7.
5. nSFF Forwarding Operations 6. nSFF Forwarding Operations
This section outlines the realization of various nSFF forwarding This section outlines the realization of various nSFF forwarding
operations in Section 4.6. Although the operations in Section 4 operations in Section 5.6. Although the operations in Section 5
utilize the notion of name-based transactions in general, we utilize the notion of name-based transactions in general, we
exemplify the operations here in Section 5 specifically for HTTP- exemplify the operations here in Section 5 specifically for HTTP-
based transactions to ground our description into a specific protocol based transactions to ground our description into a specific protocol
for such name-based transaction. We will refer to the various steps for such name-based transaction. We will refer to the various steps
in each of the following sub-sections. in each of the following sub-sections.
5.1. nSFF Protocol Layers 6.1. nSFF Protocol Layers
Figure 8 shows the protocol layers, based on the high-level Figure 8 shows the protocol layers, based on the high-level
architecture in Figure 5. architecture in Figure 5.
+-------+ +------+----+ +----+-----+ +-------+ +------+----+ +----+-----+
|App | | | | +--------+ | | | |App | | | | +--------+ | | |
|HTTP | |--------> | | NR | |nSFF----->|-- |HTTP | |--------> | | NR | |nSFF----->|--
|TCP |->| TCP |nSFF| +---/\---+ | | TCP | | |TCP |->| TCP |nSFF| +---/\---+ | | TCP | |
|IP | | IP | | || | | IP | | |IP | | IP | | || | | IP | |
+-------+ +------+----+ +---------+ +---------+ +----------+ | +-------+ +------+----+ +---------+ +---------+ +----------+ |
skipping to change at page 16, line 28 skipping to change at page 17, line 28
| IP | | IP |
| L2 | | L2 |
+-------+ +-------+
SF2 SF2
Figure 8: Protocol layers Figure 8: Protocol layers
The nSFF component here is shown as implementing a full incoming/ The nSFF component here is shown as implementing a full incoming/
outgoing TCP/IP protocol stack towards the local service functions, outgoing TCP/IP protocol stack towards the local service functions,
while implementing the nSFF-NR and nSFF-nSFF protocols based on the while implementing the nSFF-NR and nSFF-nSFF protocols based on the
descriptions in Section 5.2.3. descriptions in Section 6.2.3.
For the exchange of HTTP-based service function transactions, the For the exchange of HTTP-based service function transactions, the
nSFF terminates incoming TCP connections from as well as outgoing TCP nSFF terminates incoming TCP connections from as well as outgoing TCP
connections to local SFs, e.g., the TCP connection from SF1 connections to local SFs, e.g., the TCP connection from SF1
terminates at nSFF1, and nSFF1 may store the connection information, terminates at nSFF1, and nSFF1 may store the connection information,
such as socket information. It also maintains the mapping such as socket information. It also maintains the mapping
information for the HTTP request such as originating SF, destination information for the HTTP request such as originating SF, destination
SF and socket ID. nSFF1 may implement sending keep-alive messages SF and socket ID. nSFF1 may implement sending keep-alive messages
over the socket to maintain the connection to SF1. Upon arrival of over the socket to maintain the connection to SF1. Upon arrival of
an HTTP request from SF1, nSFF1 extracts the HTTP Request and an HTTP request from SF1, nSFF1 extracts the HTTP Request and
forwards it towards the next node, as outlined in Section 5.2. Any forwards it towards the next node, as outlined in Section 6.2. Any
returning response is mapped onto the suitable open socket (for the returning response is mapped onto the suitable open socket (for the
original request) and send towards SF1. original request) and send towards SF1.
At the outgoing nSFF2, the destination SF2/Host is identified from At the outgoing nSFF2, the destination SF2/Host is identified from
the HTTP request message. If no TCP connection exists to the SF2, a the HTTP request message. If no TCP connection exists to the SF2, a
new TCP connection is opened towards the destination SF2 and the HTTP new TCP connection is opened towards the destination SF2 and the HTTP
request is sent over said TCP connection. The nSFF2 may also save request is sent over said TCP connection. The nSFF2 may also save
the TCP connection information (such as socket information) and the TCP connection information (such as socket information) and
maintain the mapping of the socket information to the destination maintain the mapping of the socket information to the destination
SF2. When an HTTP response is received from SF2 over the TCP SF2. When an HTTP response is received from SF2 over the TCP
connection, nSFF2 extracts the HTTP response, which is forwarded to connection, nSFF2 extracts the HTTP response, which is forwarded to
the next node. nSFF2 may maintain the TCP connection through keep- the next node. nSFF2 may maintain the TCP connection through keep-
alive messages. alive messages.
5.2. nSFF Operations 6.2. nSFF Operations
In this section, we present three key aspects of operations for the In this section, we present three key aspects of operations for the
realization of the steps in Section 4.6, namely (i) the registration realization of the steps in Section 5.6, namely (i) the registration
of local SFs (for step 3 in Section 4.6), (ii) the forwarding of SFC of local SFs (for step 3 in Section 5.6), (ii) the forwarding of SFC
packets to and from local SFs (for step 3 and 4 as well as 10 in packets to and from local SFs (for step 3 and 4 as well as 10 in
Section 4.6), (iii) the forwarding to a remote SF (for steps 5, 6., Section 5.6), (iii) the forwarding to a remote SF (for steps 5, 6 and
and 7 in Section 4.6) and to the NR as well as (iv) for the lookup of 7 in Section 5.6) and to the NR as well as (iv) for the lookup of a
a suitable remote SF (for step 7 in Section 4.6). We also cover suitable remote SF (for step 7 in Section 5.6). We also cover
aspects of maintaining local lookup information for reducing lookup aspects of maintaining local lookup information for reducing lookup
latency and others issues. latency and others issues.
5.2.1. Forwarding between nSFFs and nSFF-NR 6.2.1. Forwarding between nSFFs and nSFF-NR
Forwarding between the distributed nSFFs as well as between nSFF and Forwarding between the distributed nSFFs as well as between nSFF and
NR is realized over the operator network via a path-based approach. NR is realized over the operator network via a path-based approach.
A path-based approach utilizes path information provided by the A path-based approach utilizes path information provided by the
source of the packet for forwarding said packet in the network. This source of the packet for forwarding said packet in the network. This
is similar to segment routing albeit differing in the type of is similar to segment routing albeit differing in the type of
information provided for such source-based forwarding, as described information provided for such source-based forwarding, as described
in this section. In this approach, the forwarding information to a 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 remote nSFF or the NR is defined as a 'path identifier' (pathID) of a
defined length where said length indicates the overall pathID length defined length where said length indicates the overall pathID length
as the 2 to the power of 'length', i.e., maximum 2^16 bits as path as the 2 to the power of 'length', i.e., maximum 2^16 bits as path
information. The payload of the packet is defined by the various information. The pathID length is known for most deployment
operations outlined in the following sub-sections, resulting in an scenarios. It might be omitted in environments where the pathID
overall packet being transmitted. With this, the generic forwarding length is known, such as in SDN environments. In SDN environments,
format (GFF) for transport over the operator network is defined in the length is fixed to 256 bits in alignment to the IPv6 source/
Figure 9 with the length field defining the length of the pathID destination matching field being used for path-based forwarding. The
provided. payload of the packet is defined by the various operations outlined
in the following sub-sections, resulting in an overall packet being
transmitted. With this, the generic forwarding format (GFF) for
transport over the operator network is defined in Figure 9 with the
length field defining the length of the pathID provided.
+---------+-----------------+------------------------//------------+ +---------+-----------------+------------------------//------------+
| | | // | | | | // |
| Length | Path ID | Payload // | | Length | Path ID | Payload // |
| (4 bit) | | // | | (4 bit) | | // |
+---------+-----------------+--------------------//----------------+ +---------+-----------------+--------------------//----------------+
Figure 9: Generic Forwarding Format(GFF) Figure 9: Generic Forwarding Format(GFF)
o Length (4 bits): Defines the length of the pathID o Length (4 bits): Defines the length of the pathID
skipping to change at page 18, line 34 skipping to change at page 19, line 37
with the relevant IP information used to forward the SFC packet to with the relevant IP information used to forward the SFC packet to
SF2 or it will create a suitable TE (Transport Encapsulation) SF2 or it will create a suitable TE (Transport Encapsulation)
information to forward the information to another nSFF or boundary information to forward the information to another nSFF or boundary
node. Forwarding operations at the intermediary forwarders, i.e., node. Forwarding operations at the intermediary forwarders, i.e.,
SDN switches, examine the pathID information through a flow matching SDN switches, examine the pathID information through a flow matching
rule in which a specific switch-local output port is represented rule in which a specific switch-local output port is represented
through the specific assigned bit position in the pathID. Upon a through the specific assigned bit position in the pathID. Upon a
positive match in said rule, the packet is forwarded on said output positive match in said rule, the packet is forwarded on said output
port. port.
Alternatively, the solution in [I-D.purkayastha-bier-multicast-http] Alternatively, the solution in
suggests using a so-called BIER (Binary Indexed Explicit Replication) [I-D.ietf-bier-multicast-http-response] suggests using a so-called
underlay. Here, the nSFF would be realized at the ingress to the BIER (Binary Indexed Explicit Replication) underlay. Here, the nSFF
BIER underlay, injecting the SFC packet (plus the NSH) header with would be realized at the ingress to the BIER underlay, injecting the
BIER-based traffic encapsulation into the BIER underlay with each of SFC packet (plus the NSH) header with BIER-based traffic
the forwarders in Figure 8 being realized as a so-called Bit- encapsulation into the BIER underlay with each of the forwarders in
Forwarding Router (BFR) [RFC8279]. Figure 8 being realized as a so-called Bit-Forwarding Router (BFR)
[RFC8279].
5.2.1.1. Transport Protocol Considerations 6.2.1.1. Transport Protocol Considerations
Given that the proposed solution operates at the 'named transaction' Given that the proposed solution operates at the 'named transaction'
level, particularly for HTTP transactions, forwarding between nSFFs level, particularly for HTTP transactions, forwarding between nSFFs
and/or NR SHOULD be implemented via a transport protocol between and/or NR should be implemented via a transport protocol between
nSFFs and/or NR in order to provide reliability, segmentation of nSFFs and/or NR in order to provide reliability, segmentation of
large GFF packets, and flow control. The details of this protocol large GFF packets, and flow control. The details of this protocol
will be outlined at a later stage, with the GFF in Figure 9 being the will be outlined at a later stage, with the GFF in Figure 9 being the
basic forwarding format for this. basic forwarding format for this.
5.2.2. SF Registration 6.2.2. SF Registration
As outlined in step 3 and 10 of Section 4.6, the nSFF needs to 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 determine if the SF derived from the nNLM is locally reachable or
whether the packet needs forwarding to a remote SFF. For this, a whether the packet needs forwarding to a remote SFF. For this, a
registration mechanism is provided for such local SF with the local registration mechanism is provided for such local SF with the local
nSFF. Two mechanisms can be used for this: nSFF. Two mechanisms can be used for this:
1. SF-initiated: We assume that the SF registers its FQDN to the 1. SF-initiated: We assume that the SF registers its FQDN to the
local nSFF. As local mechanisms, we foresee that either a REST-based local nSFF. As local mechanisms, we foresee that either a REST-based
interface over the link-local link or configuration of the nSFF interface over the link-local link or configuration of the nSFF
(through configuration files or management consoles) can be utilized. (through configuration files or management consoles) can be utilized.
Such local registration event leads to the nSFF to register the given Such local registration event leads to the nSFF to register the given
skipping to change at page 20, line 11 skipping to change at page 21, line 16
orchestrated and the chain being provided through an orchestration orchestrated and the chain being provided through an orchestration
template with FQDN information associated to a compute/storage template with FQDN information associated to a compute/storage
resource that is being deployed by the orchestrator. We also assume resource that is being deployed by the orchestrator. We also assume
knowledge at the orchestrator of the resource topology. Based on knowledge at the orchestrator of the resource topology. Based on
this, the orchestrator can now use the same REST-based protocol 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 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 provided in the template, at the nSFF it has identified as being the
locally servicing nSFF, provided as the system-unique nSFF locally servicing nSFF, provided as the system-unique nSFF
identifier. identifier.
5.2.3. Local SF Forwarding 6.2.3. Local SF Forwarding
There are two cases of local SF forwarding, namely the SF sending an There are two cases of local SF forwarding, namely the SF sending an
SFC packet to the local nSFF (incoming requests) or the nSFF sending SFC packet to the local nSFF (incoming requests) or the nSFF sending
a packet to the SF (outgoing requests) as part of steps 3 and 10 in a packet to the SF (outgoing requests) as part of steps 3 and 10 in
Section 4.6. In the following, we outline the operation for HTTP as Section 5.6. In the following, we outline the operation for HTTP as
an example named transaction. an example named transaction.
As shown in Figure 8, incoming HTTP requests from SFs are extracted As shown in Figure 8, incoming HTTP requests from SFs are extracted
by terminating the incoming TCP connection at their local nSFFs at by terminating the incoming TCP connection at their local nSFFs at
the TCP level. The nSFF MUST maintain a mapping of open TCP sockets the TCP level. The nSFF must maintain a mapping of open TCP sockets
to HTTP requests (utilizing the URI of the request) for HTTP response to HTTP requests (utilizing the URI of the request) for HTTP response
association. association.
For outgoing HTTP requests, the nSFF utilizes the maintained mapping For outgoing HTTP requests, the nSFF utilizes the maintained mapping
of locally registered FQDNs to link-local IP addresses (see of locally registered FQDNs to link-local IP addresses (see
Section 5.2.2 option 1). Hence, upon receiving an SFC packet from a Section 6.2.2 option 1). Hence, upon receiving an SFC packet from a
remote nSFF (in step 9 of Section 4.6), the nSFF determines the local remote nSFF (in step 9 of Section 5.6), the nSFF determines the local
existence of the SF through the registration mechanisms in existence of the SF through the registration mechanisms in
Section 5.2.2. If said SF does exist locally, the HTTP (+NSH) Section 6.2.2. If said SF does exist locally, the HTTP (+NSH)
packet, after stripping the TE, is sent to the local SF as step 10 in packet, after stripping the TE, is sent to the local SF as step 10 in
Section 4.6 via a TCP-level connection. Outgoing nSFF SHOULD keep Section 5.6 via a TCP-level connection. Outgoing nSFF should keep
TCP connections open to local SFs for improving SFC packet delivery TCP connections open to local SFs for improving SFC packet delivery
in subsequent transactions. in subsequent transactions.
5.2.4. Handling of HTTP responses 6.2.4. Handling of HTTP responses
When executing step 3 and 10 in Section 4.6, the SFC packet will be When executing step 3 and 10 in Section 5.6, the SFC packet will be
delivered to the locally registered next hop. As part of the HTTP delivered to the locally registered next hop. As part of the HTTP
protocol, responses to the HTTP request will need to be delivered on 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 the return path to the originating nSFF (i.e., the previous hop).
this, the nSFF maintains a list of link-local connection information, For this, the nSFF maintains a list of link-local connection
e.g., sockets to the local SF and the pathID on which the request was information, e.g., sockets to the local SF and the pathID on which
received. Once receiving the response, nSFF consults the table to the request was received. Once receiving the response, nSFF consults
determine the pathID of the original request, forming a suitable GFF- the table to determine the pathID of the original request, forming a
based packet to be returned to the previous nSFF. suitable GFF-based packet to be returned to the previous nSFF.
When receiving the HTTP response at the previous nSFF, the nSFF When receiving the HTTP response at the previous nSFF, the nSFF
consults the table of (locally) open sockets to determine the consults the table of (locally) open sockets to determine the
suitable local SF connection, mapping the received HTTP response URI suitable local SF connection, mapping the received HTTP response URI
to the stored request URI. Utilizing the found socket, the HTTP to the stored request URI. Utilizing the found socket, the HTTP
response is forwarded to the locally registered SF. response is forwarded to the locally registered SF.
To be added later: Handling of semi-synchronous responses from To be added later: Handling of semi-synchronous responses from
different chains to the same SF (with multicast capability) different chains to the same SF (with multicast capability)
[I-D.purkayastha-bier-multicast-http]. [I-D.ietf-bier-multicast-http-response].
5.2.5. Remote SF Forwarding 6.2.5. Remote SF Forwarding
In steps 5, 6, 7, and 8 of Section 4.6, an SFC packet is forwarded to In steps 5, 6, 7, and 8 of Section 5.6, an SFC packet is forwarded to
a remote nSFF based on the nNLM information for the next hop of the a remote nSFF based on the nNLM information for the next hop of the
nSFP. Section 5.2.5.1 handles the case of suitable forwarding nSFP. Section 6.2.5.1 handles the case of suitable forwarding
information to the remote nSFF not existing, therefore consulting the information to the remote nSFF not existing, therefore consulting the
NR to obtain suitable information, while Section 5.2.5.2 describes NR to obtain suitable information, while Section 6.2.5.2 describes
the maintenance of forwarding information at the local nSFF, while the maintenance of forwarding information at the local nSFF, while
Section 5.2.5.3 describes the update of stale forwarding information. Section 6.2.5.3 describes the update of stale forwarding information.
Note that the forwarding described in Section 5.2.1 is used for the Note that the forwarding described in Section 6.2.1 is used for the
actual forwarding to the various nSFF components. Ultimately, actual forwarding to the various nSFF components. Ultimately,
Section 5.2.5.4 describes the forwarding to the remote nSFF via the Section 6.2.5.4 describes the forwarding to the remote nSFF via the
forwarder network forwarder network.
5.2.5.1. Remote SF Discovery 6.2.5.1. Remote SF Discovery
The nSFF communicates with the NR for two purposes, namely the The nSFF communicates with the NR for two purposes, namely the
registration and discovery of FQDNs. The packet format for the registration and discovery of FQDNs. The packet format for the
former was shown in Figure 10 in Section 5.2.2, while Figure 11 former was shown in Figure 10 in Section 6.2.2, while Figure 11
outlines the packet format for the discovery request. outlines the packet format for the discovery request.
+--------------+-------------+ +--------+-----------------//--------+ +--------------+-------------+ +--------+-----------------//--------+
| | | | | // | | | | | | // |
| hash(FQDN) | nSFF_ID | | Length | pathID // | | hash(FQDN) | nSFF_ID | | Length | pathID // |
| (16 bit) | (8 bit) | | (4 bit)| // | | (16 bit) | (8 bit) | | (4 bit)| // |
+--------------+-------------+ +--------+-------------//------------+ +--------------+-------------+ +--------+-------------//------------+
Path Request Path Response Path Request Path Response
Figure 11: Discovery packet format Figure 11: Discovery packet format
For Path Request: For Path Request:
o Hash(FQDN): 16 bit length for a hash over the FQDN of the SF o Hash(FQDN): 16 bit length for a hash over the FQDN of the SF
o nSFF_ID: 8 bit for a system-unique identifier for the SFF related o nSFF_ID: 8 bit for a system-unique identifier for the SFF related
to the SF. to the SF
For Path Response: For Path Response:
o Length (4 bits): Defines the length of the pathID o Length (4 bits): Defines the length of the pathID
o Path ID (): Variable length field, Bit field derived from IPv6 o Path ID (): Variable length field, Bit field derived from IPv6
source and destination address source and destination address
A path to a specific FQDN is requested by sending a hash of the FQDN 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 to the NR together with its nSFF_id, receiving as a response a pathID
with a length identifier. The NR should maintain a table of with a length identifier. The NR should maintain a table of
discovery requests that map discovered (hash of) FQDN to the nSFF_id 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 that requested it and the pathID that is being calculated as a result
of the discovery request. of the discovery request.
The discovery request for an FQDN that has not previously been served The discovery request for an FQDN that has not previously been served
at the nSFF (or for an FQDN whose pathID information has been flushed at the nSFF (or for an FQDN whose pathID information has been flushed
as a result of the update operations in Section 5.2.5.3), results in as a result of the update operations in Section 6.2.5.3), results in
an initial latency incurred by this discovery through the NR, while an initial latency incurred by this discovery through the NR, while
any SFC packet sent over the same SFP in a subsequent transaction any SFC packet sent over the same SFP in a subsequent transaction
will utilize the nSFF local mapping table. Such initial latency can will utilize the nSFF local mapping table. Such initial latency can
be avoided by pre-populating the FQDN-pathID mapping proactively as be avoided by pre-populating the FQDN-pathID mapping proactively as
part of the overall orchestration procedure, e.g., alongside the part of the overall orchestration procedure, e.g., alongside the
distribution of the nNLM information to the nSFF. distribution of the nNLM information to the nSFF.
5.2.5.2. Maintaining Forwarding Information at Local nSFF 6.2.5.2. Maintaining Forwarding Information at Local nSFF
Each nSFF MUST maintain an internal table that maps the (hash of the) Each nSFF must maintain an internal table that maps the (hash of the)
FQDN information to a suitable pathID information. As outlined in FQDN information to a suitable pathID information. As outlined in
step 7 of Section 4.6, if a suitable entry does not exist for a given step 7 of Section 5.6, if a suitable entry does not exist for a given
FQDN, the pathID information is requested with the operations in FQDN, the pathID information is requested with the operations in
Section 5.2.5.1 and the suitable entry is locally created upon Section 6.2.5.1 and the suitable entry is locally created upon
receiving a reply with the forwarding operation being executed as receiving a reply with the forwarding operation being executed as
described in Section 5.2.1. described in Section 6.2.1.
If such entry does exist (i.e., step 6 of Section 4.6) the pathID is 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 locally retrieved and used for the forwarding operation in
Section 5.2.1. Section 6.2.1.
5.2.5.3. Updating Forwarding Information at nSFF 6.2.5.3. Updating Forwarding Information at nSFF
The forwarding information maintained at each nSFF (see The forwarding information maintained at each nSFF (see
Section 5.2.5.2) might need to be updated for three reasons: Section 6.2.5.2) might need to be updated for three reasons:
o An existing SF is no longer reachable: In this case, the nSFF with o An existing SF is no longer reachable: In this case, the nSFF with
which the SF is locally registered, de-registers the SF explicitly which the SF is locally registered, de-registers the SF explicitly
at the NR by sending the packet in Figure 10 with the hashed FQDN at the NR by sending the packet in Figure 10 with the hashed FQDN
and the R/D bit set to 1 (for de-register). and the R/D bit set to 1 (for de-register).
o Another SF instance has become reachable in the network (and o Another SF instance has become reachable in the network (and
therefore might provide a better alternative to the existing SF): therefore might provide a better alternative to the existing SF):
in this case, the NR has received another packet with format in this case, the NR has received another packet with format
defined in Figure 11 but a different nSFF_id value. defined in Figure 11 but a different nSFF_id value.
o Links along paths might no longer be reachable: the NR might use o Links along paths might no longer be reachable: the NR might use
suitable southbound interface to transport networks to detect link suitable southbound interface to transport networks to detect link
failures, which it associates to the appropriate pathID bit failures, which it associates to the appropriate pathID bit
position position.
For this purpose, the packet format in Figure 12 is sent from the NR For this purpose, the packet format in Figure 12 is sent from the NR
to all affected nSFFs, using the generic format in Figure 9. to all affected nSFFs, using the generic format in Figure 9.
+---------+-----------------+--------------//----+ +---------+-----------------+--------------//----+
| | | // | | | | // |
| Type | #IDs | IDs // | | Type | #IDs | IDs // |
| (1 bit) | (8 bit) | // | | (1 bit) | (8 bit) | // |
+---------+-----------------+----------//--------+ +---------+-----------------+----------//--------+
skipping to change at page 23, line 34 skipping to change at page 24, line 36
o Type: 1 bit length (0 for Nsff ID, 1 for Link ID) o Type: 1 bit length (0 for Nsff ID, 1 for Link ID)
o #IDs: 8 bit length for number of IDs in the list o #IDs: 8 bit length for number of IDs in the list
o IDs: List of IDs (Nsff ID or Link ID) o IDs: List of IDs (Nsff ID or Link ID)
The pathID to the affected nSFFs is computed as the binary OR over The pathID to the affected nSFFs is computed as the binary OR over
all pathIDs to those nSFF_ids affected where the pathID information all pathIDs to those nSFF_ids affected where the pathID information
to the affected nSFF_id values is determined from the NR-local table to the affected nSFF_id values is determined from the NR-local table
maintained in the registration/deregistration operation of maintained in the registration/deregistration operation of
Section 5.2.2. Section 6.2.2.
The pathID may include the type of information being updated (e.g., The pathID may include the type of information being updated (e.g.,
node identifiers of leaf nodes or link identifiers for removed node identifiers of leaf nodes or link identifiers for removed
links). The node identifier itself may be a special identifier to links). The node identifier itself may be a special identifier to
signal "ALL NODES" as being affected. The node identifier may signal signal "ALL NODES" as being affected. The node identifier may signal
changes to the network that are substantial (e.g., parallel link changes to the network that are substantial (e.g., parallel link
failures). The node identifier may trigger (e.g., recommend) purging failures). The node identifier may trigger (e.g., recommend) purging
of the entire path table (e.g., rather than the selective removal of of the entire path table (e.g., rather than the selective removal of
a few nodes only). a few nodes only).
skipping to change at page 24, line 16 skipping to change at page 25, line 19
the (hash of) FQDN to nSFF_id is maintained, the update is sent to the (hash of) FQDN to nSFF_id is maintained, the update is sent to
all nSFFs. Upon receiving the path update at the affected nSFF, all all nSFFs. Upon receiving the path update at the affected nSFF, all
appropriate nSFF-local mapping entries to pathIDs for the hash(FQDN) appropriate nSFF-local mapping entries to pathIDs for the hash(FQDN)
identifiers provided will be removed, leading to a new NR discovery identifiers provided will be removed, leading to a new NR discovery
request at the next remote nSFF forwarding to the appropriate FQDN. request at the next remote nSFF forwarding to the appropriate FQDN.
In case 3, the Type bit is set to 0 (type linkID) and the affected In case 3, the Type bit is set to 0 (type linkID) and the affected
nSFFs are determined by those nSFFs whose discovery requests have nSFFs are determined by those nSFFs whose discovery requests have
previously resulted in pathIDs which include the affected link, previously resulted in pathIDs which include the affected link,
utilizing the optional table mapping previously registered FQDNs to utilizing the optional table mapping previously registered FQDNs to
pathID values (see Section 5.2.5.1). Upon receiving the node pathID values (see Section 6.2.5.1). Upon receiving the node
identifier information in the path update, the affected nSFF will identifier information in the path update, the affected nSFF will
check its internal table that maps FQDNs to pathIDs to determine check its internal table that maps FQDNs to pathIDs to determine
those pathIDs affected by the link problems and remove path those pathIDs affected by the link problems and remove path
information that includes the received node identifier(s). For this, information that includes the received node identifier(s). For this,
the pathID entries of said table are checked against the linkID the pathID entries of said table are checked against the linkID
values provided in the ID entry of the path update through a binary values provided in the ID entry of the path update through a binary
AND/CMP operation to check the inclusion of the link in the pathIDs AND/CMP operation to check the inclusion of the link in the pathIDs
to the FQDNs. If any pathID is affected, the FQDN-pathID entry is to the FQDNs. If any pathID is affected, the FQDN-pathID entry is
removed, leading to a new NR discovery request at the next remote removed, leading to a new NR discovery request at the next remote
nSFF forwarding to the appropriate FQDN. nSFF forwarding to the appropriate FQDN.
5.2.5.4. Forwarding to remote nSFF 6.2.5.4. Forwarding to remote nSFF
Once step 5, 6, and 7 in Section 4.6 are being executed, step 8 Once step 5, 6, and 7 in Section 5.6 are being executed, step 8
finally sends the SFC packet to the remote nSFF, utilizing the pathID finally sends the SFC packet to the remote nSFF, utilizing the pathID
returned in the discovery request (Section 5.2.5.1) or retrieved from returned in the discovery request (Section 6.2.5.1) or retrieved from
the local pathID mapping table. The SFC packet is placed in the the local pathID mapping table. The SFC packet is placed in the
payload of the generic forwarding format in Figure 9 together with payload of the generic forwarding format in Figure 9 together with
the pathID and the nSFF eventually executes the forwarding operations the pathID and the nSFF eventually executes the forwarding operations
in Section 5.2.1. in Section 6.2.1.
6. IANA Considerations 7. IANA Considerations
This document requests no IANA actions. This document requests no IANA actions.
7. Security Considerations 8. Security Considerations
The operations in Section 4 and 5 describes the forwarding of SFC The operations in Sections 5 and 6 describes the forwarding of SFC
packets 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 For security considerations, TLS is sufficient between originating
node and Nsff, Nsff to Nsff, Nsff to destination. TLS handshake node and Nsff, Nsff to Nsff, Nsff to destination. TLS handshake
allows to determine the FQDN, which in turn is enough for the service allows to determine the FQDN, which in turn is enough for the service
routing decision. Supporting TLS also allows the possibility of routing decision. Supporting TLS also allows the possibility of
HTTPS based transactions. HTTPS based transactions.
8. Acknowledgement 9. Acknowledgement
The authors will like to thank Dirk Hugo for his review and valuable
comments. We will also like to thank Joel Halpren, the chair of the
SFC WG,and Adrian Farrel for guiding us through the ISE path.
9. Informative References
[_3GPP_SBA]
3GPP, "Technical Realization of Service Based
Architecture", 3GPP TS 29.500 0.4.0, January 2018,
<http://www.3gpp.org/ftp/Specs/html-info/29500.htm>.
[_3GPP_SBA_ENHANCEMENT] The authors would like to thank Dirk Hugo and Andrew Malis for their
3GPP, "New SID for Enhancements to the Service-Based 5G reviews and valuable comments. We would also like to thank Joel
System Architecture", 3GPP S2-182904 , February 2018, <htt Halpern, the chair of the SFC WG, and Adrian Farrel for guiding us
p://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_126_Montreal/ through the IETF Independent Submission Editor (ISE) path.
Docs/S2-182904.zip>.
[I-D.purkayastha-bier-multicast-http] 10. References
Purkayastha, D., Rahman, A., and D. Trossen, "Multicast
HTTP using BIER", draft-purkayastha-bier-multicast-http-00
(work in progress), March 2018.
[I-D.purkayastha-sfc-service-indirection] 10.1. Normative References
Purkayastha, D., Rahman, A., Trossen, D., Despotovic, Z.,
and R. Khalili, "Alternative Handling of Dynamic Chaining
and Service Indirection", draft-purkayastha-sfc-service-
indirection-02 (work in progress), March 2018.
[Reed2016] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Reed, M., Al-Naday, M., Thomas, N., Trossen, D., and S. Requirement Levels", BCP 14, RFC 2119,
Spirou, "Stateless multicast switching in software defined DOI 10.17487/RFC2119, March 1997,
networks", ICC 2016, 2016. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
10.2. Informative References
[_3GPP_SBA]
3GPP, "Technical Realization of Service Based
Architecture", 3GPP TS 29.500 0.4.0, January 2018,
<http://www.3gpp.org/ftp/Specs/html-info/29500.htm>.
[_3GPP_SBA_ENHANCEMENT]
3GPP, "New SID for Enhancements to the Service-Based 5G
System Architecture", 3GPP S2-182904 , February 2018, <htt
p://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_126_Montreal/
Docs/S2-182904.zip>.
[I-D.ietf-bier-multicast-http-response]
Purkayastha, D., Rahman, A., Trossen, D., and T. Eckert,
"Applicability of BIER Multicast Overlay for Adaptive
Streaming Services", draft-ietf-bier-multicast-http-
response-00 (work in progress), February 2019.
[Reed2016]
Reed, M., Al-Naday, M., Thomas, N., Trossen, D., and S.
Spirou, "Stateless multicast switching in software defined
networks", ICC 2016, 2016,
<https://arxiv.org/pdf/1511.06069.pdf>.
[Schlinker2017] [Schlinker2017]
Schlinker, B., Kim, H., Cui, T., Katz-Bassett, E., Schlinker, B., Kim, H., Cui, T., Katz-Bassett, E.,
Madhyastha, Harsha., Cunha, I., Quinn, J., Hassan, S., Madhyastha, Harsha., Cunha, I., Quinn, J., Hassan, S.,
Lapukhov, P., and H. Zeng, "Engineering Egress with Edge Lapukhov, P., and H. Zeng, "Engineering Egress with Edge
Fabric, Steering Oceans of Content to the World", ACM Fabric, Steering Oceans of Content to the World", ACM
SIGCOMM 2017, 2017. SIGCOMM 2017, 2017, <https://research.fb.com/wp-
content/uploads/2017/08/sigcomm17-final177-2billion.pdf>.
Authors' Addresses Authors' Addresses
Dirk Trossen Dirk Trossen
InterDigital Europe, Ltd InterDigital Europe, Ltd
64 Great Eastern Street, 1st Floor 64 Great Eastern Street, 1st Floor
London EC2A 3QR London EC2A 3QR
United Kingdom United Kingdom
Email: Dirk.Trossen@InterDigital.com Email: Dirk.Trossen@InterDigital.com
 End of changes. 116 change blocks. 
276 lines changed or deleted 297 lines changed or added

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