[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits] [IPR]
Versions: 00 01 02 03 04 05 06 07
Network Working Group D. Trossen
Internet-Draft D. Purkayastha
Intended status: Informational A. Rahman
Expires: December 29, 2018 InterDigital Communications, LLC
June 27, 2018
Name-Based Service Function Forwarder (nSFF) component within SFC
framework
draft-trossen-sfc-name-based-sff-00
Abstract
Many stringent requirements are imposed on today's network, such as
low latency, high availability and reliability in order to support
several use cases such as IoT, Gaming, Content distribution, Robotics
etc.
Adoption of cloud and fog technology at the edge of the network
allows operator to deploy a single "Service Function" to multiple
"Execution locations". The decision to steer traffic to a specific
location may change frequently based on load, proximity etc. Under
the current SFC framework, steering traffic dynamically to the
different execution end points require a specific 're-chaining',
i.e., a change in the service function path reflecting the different
IP endpoints to be used for the new execution points. In order to
address this, we discuss separating the logical Service Function Path
from the specific execution end points. This can be done by
identifying the Service Functions using a name rather than a routable
IP endpoint (or Layer 2 address). This draft describes the necessary
extensions to the various concepts and methods of SFC, specifically
the SFF, in order to handle such name based relationships.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Trossen, et al. Expires December 29, 2018 [Page 1]
Internet-Draft Name Based SFF June 2018
This Internet-Draft will expire on December 29, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Example use case: 5G control plane services . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Basic Definitions . . . . . . . . . . . . . . . . . . . . 5
3.2. Chaining of Service Functions . . . . . . . . . . . . . . 7
3.3. Operations for Traversing SFCs . . . . . . . . . . . . . 8
3.4. Operations inside an SFF . . . . . . . . . . . . . . . . 8
4. Challenges with current framework . . . . . . . . . . . . . . 11
5. Name based operation in SFF . . . . . . . . . . . . . . . . . 12
5.1. General Idea . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Name-Based Service Function Path (nSFP) . . . . . . . . . 12
5.3. Name Based Network Locator Map (nNLM) . . . . . . . . . . 14
5.4. Name-based Service Function Forwarder (nSFF) . . . . . . 16
5.4.1. Lifecycle of a Packet . . . . . . . . . . . . . . . . 17
5.4.2. Determining Suitable Forwarding Information . . . . . 21
5.4.3. Layered View of Realizing nSFF . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Informative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
The requirements on today's networks are very diverse, enabling
multiple use cases such as IoT, Content Distribution, Gaming, Network
functions such as Cloud RAN. Every use case imposes certain
requirements on the network. These requirements vary from one
extreme to other and often they are in a divergent direction.
Network operator and service providers are pushing many functions
Trossen, et al. Expires December 29, 2018 [Page 2]
Internet-Draft Name Based SFF June 2018
towards the edge of the network in order to be closer to the users.
This reduces latency and backhaul traffic, as user request can be
processed locally.
It becomes more challenging for the network when user mobility as
well as non-deterministic availability of compute and storage
resources are considered. The impact is felt most at the edge of the
network because as users move, their point of attachment changes
frequently, which results in (at least partially) relocating the
service as well as the service endpoint. Furthermore, network
functions are pushed more and more towards the edge, where compute
and storage resources are constrained and availability is non-
deterministic.
In such a dynamic network environment, the capability to dynamically
compose new services from available services as well as move a
service instance in response to user mobility or resource
availability is desirable.
The Service Function Chaining (SFC) framework [RFC7665] allows
network operators as well as service providers to compose new
services by chaining individual "Service Functions". Such chains are
expressed through explicit relationships of functional components
(the service functions), realized through their direct Layer 2 (e.g.,
MAC address) or Layer 3 (e.g., IP address) relationship as defined
through next hop information that is being defined by the network
operator, see Section 3 for more background on SFC.
A dynamic service environment as the one outlined above, i.e.
utilizing edge-based services, requires that service end points are
created and recreated frequently. Within the SFC framework, it means
to reconfigure the existing chain through information based on the
new relationships, causing overhead in a number of components,
specifically the orchestrator that initiates the initial service
function chain and any possible reconfiguration.
This document describes how such changes can be handled without
involving the initiation of new and reconfigured SFCs by embedding
the necessary functionality directly into the Service Function
Forwarder. In other words, the SFF described here allows for keeping
an existing SFC intact, as described by its service function path
(SFP), while enabling the selection of an appropriate service
function endpoint(s) during the traversal of packets through the SFC.
Trossen, et al. Expires December 29, 2018 [Page 3]
Internet-Draft Name Based SFF June 2018
2. Example use case: 5G control plane services
As stated above, we can formulate the problem of keeping a service
function chain intact while providing selection of the specific
service function endpoints that are traversed at any point in time.
We exemplify the need for such a solution through a use case stemming
from the current 3GPP Rel 16 work on Service Based Architecture (SBA)
[_3GPP_SBA], [_3GPP_SBA_ENHANCEMENT]. In this work, a change in
designing mobile network control planes is motivated by replacing the
traditional network function interfaces with a fully service-based
one. HTTP was chosen as the application layer protocol for
exchanging suitable service requests [_3GPP_SBA]. With this in mind,
the exchange between, say the session management function (SMF) and
the authentication management function (AMF) in a 5G control plane is
being described as a set of web service like requests which are in
turn embedded into HTTP requests. Hence, interactions in a 5G
control plane can be modelled based on service function chains where
the relationship is between the specific (IP-based) service function
endpoints that implement the necessary service endpoints in the SMF
and AMF.
Motivating the move from a network function model (in pre-Rel 15
systems of 3GPP) to a service-based model is the proliferation of
data center operations for mobile network control plane services. In
other words, typical IT-based methods to service provisioning, in
particular that of virtualization of entire compute resources, are
envisioned to being used in future operations of mobile networks.
Hence, operators of such future mobile network desire to virtualize
service function endpoints and direct (control plane) traffic to the
most appropriate current service instance. 'Appropriate' here can be
defined by topological or geographical proximity of the service
initiator to the service function endpoint. Alternatively, network
or service instance compute load can be used to direct a request to a
more appropriate (in this case less loaded) instance to reduce
possible latency of the overall request. Such data centre centric
operation is extended with the trend towards regionalization of load
through a 'regional office' approach, where micro data centres
provide virtualizable resources that can be used in the service
execution, creating a larger degree of freedom when choosing the
'most appropriate' service endpoint for a particular incoming service
request.
While the move to a service-based model aligns well with the
framework of SFC, choosing the most appropriate service instance at
runtime requires so-called 're-chaining' of the SFC since the
relationships in said SFC are defined through Layer 2 or 3
identifiers, which in turn are likely to be different if the chosen
Trossen, et al. Expires December 29, 2018 [Page 4]
Internet-Draft Name Based SFF June 2018
service instances reside in different parts of the network (e.g., in
a regional data center).
3. Background
3.1. Basic Definitions
We first start with few basic definitions, according to [RFC7665]:
o A Service Function (SF) is responsible for specific treatment of
received packets. A Service Function can act at various layers of
a protocol stack (e.g., at the network layer or other OSI layers).
As a logical component, a service function can be realized as a
virtual element or be embedded in a physical network element.
o The ordered series of Service Functions is defined through the
Service Function Chain (SFC).
o Service Function Path (SFP) defines the specific execution of an
SFC in specific Service Function instances. The SFP reflects the
mechanism used by service chaining to express the result of
applying more granular policy and operational constraints to the
abstract requirements of a service chain (SFC).
o The SFP is identified by the Service Path Identifier (SPI) and the
Service index (SI).
o A Network Locator Map exists at each SFF that translates the SPI
and SI information into a Next Hop information within the SFC
domain.
Trossen, et al. Expires December 29, 2018 [Page 5]
Internet-Draft Name Based SFF June 2018
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe |
| | | | |
| 10 | 254 | 198.51.100.10 | GRE |
| | | | |
| 10 | 251 | 198.51.100.15 | GRE |
| | | | |
| 40 | 251 | 198.51.100.15 | GRE |
| | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | |
| 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-------------------------+
Figure 1: Network Locator Map in SFC
o Network Service Header (NSH) [RFC8300] is a distinct identifiable
plane that can be used across all transports to create a service
chain and exchange metadata along the chain. A Network Service
Header (NSH) contains service path information and optionally
metadata that are added to a packet or frame and used to create a
service plane. A control plane is required in order to exchange
NSH values with participating nodes, and to provision the same
nodes with requisite information such as service path ID to
overlay mapping
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier (SPI) | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NSH Service Path Header
o Service Classifier / Service Classification is responsible for
directing incoming packets from a user or another network towards
an identified SFP, therefore forwarding the packet to the
respective service functions specified in the SFP. For this, the
service classifier adds the NSH header, which contains the
respective (SPI, SI) to identify the Service Function Path.
Additional context information such as UserID, ApplicationID maybe
added. Finally, the service classifier determines the suitable
transport and adds transport encapsulation for delivery to the
SFF.
Trossen, et al. Expires December 29, 2018 [Page 6]
Internet-Draft Name Based SFF June 2018
o Service Function Forwarder (SFF at the router) executes the
following functions:
* Remove Transport encapsulation
* Inspect NSH header to find SPI/SI, determine the next SF1,
which is the Firewall function in our example above.
* Forward the Packet and NSH encapsulation to appropriate SF,
here SF1 in our example
3.2. Chaining of Service Functions
When a traffic flow is forwarded over a service chain, packets in the
traffic flow are processed by the various service function instances,
with each service function instance applying a service function
(e.g., firewall, network access translation (NAT), deep packet
inspection (DPI), etc.) prior to forwarding the packets to the next
network node. It is a Service layer concept and can possibly work
over any Virtual network layer and an Underlay network, possibly IP
and any Layer 2 technology. At the service layer, Service Functions
are identified using a path identifier and an index. Eventually this
index is translated to an IP address (or MAC address) of the host
where the service function is running.
As an example, a user's request to access a video server from his
home over a fixed network, may flow through several service functions
over a service chain, as deployed by network operator. The CPE
accepts the request, pass it on through a firewall, video optimizer
and video server. These service functions define a Service Function
Chain. The following diagram in Figure 3 shows the example Service
Function Chain described here.
+------+ +------+ +----------+ +-----------------+
| User |-->| CPE |--->| Firewall |--->| Video Optimizer |--->
+------+ +------+ +----------+ +-----------------+
Figure 3: Mapping SFC onto Service Function Execution Points along a
Service Function Path
[RFC7665] describes an architecture for the specification, creation,
and ongoing maintenance of Service Function Chains (SFCs). It
includes architectural concepts, principles, and components used in
the construction of composite services through deployment of SFCs.
Trossen, et al. Expires December 29, 2018 [Page 7]
Internet-Draft Name Based SFF June 2018
3.3. Operations for Traversing SFCs
The following diagram in Figure 4 fits the architectural concepts and
operation of SFC to the use case described above. How packets are
encapsulated and de-capsulated, as it traverses through the service
functions, is also shown.
The CPE may act as a Service Classifier. The Service Function
Forwarder (SFF) is the router or gateways in the network. SF1
represents the Firewall function. SF2 represents Video Optimization
function and Video server function.
+------------+ +------+ +-----+
| Controller | | SF1 | | SF2 |
+----|-------+ +--/\--+ +-/\--+
Configuration|--------------||------- ||
| \ || \ ||
+------------+ \+------+ \+------+
------>| Classifier |--->| vTOR |----->| vTOR |------>
Packet +------------+ | | SFF | | | SFF | Packet
| +------+ | +------+
+---------+ +---------+
| L2 HDR | | L2 HDR |
+---------+ +---------+
| NSH HDR | | NSH HDR |
+---------+ +---------+
| Packet | | Packet |
+---------+ +---------+
Figure 4: Processing of an SFC Packet along an SFP
3.4. Operations inside an SFF
The following diagram in Figure 5 describes the functions inside an
SFF.
Trossen, et al. Expires December 29, 2018 [Page 8]
Internet-Draft Name Based SFF June 2018
+----------+
----| SF |/----
| +----------+\---|
| |
+----------------|-------------------|--------------+
| SFF | | |
| | | |
| +------------+ \/ +--------------+ | +------+ |
------>| Remove prev|--->| Process nsh |----->| Add |------>
TE+NSH | TE | | identify next| | TE |Packet
+PKT | +------------+ | SF | | |+NSH+TE
| +--------------+ +------+ |
| nsh+pkt nsh+pkt |
+---------------------------------------------------+
Figure 5: Processing an incoming SFC Packet in an SFF
Service Function Forwarder (SFF at the router) executes the following
functions:
o Remove TE (RTE): SFF first removes the Transport Encapsulation
(TE) and forwards the Packet with NSH header to the next sub-
function
o Process NSH (PNSH):
* Based on the NSH header, a possibly local service function is
identified as next SF. If it is reachable from the same SFF,
the SFF then forwards the packet. The packet is processed by
service function. It is returned to SFF with updated NSH
header. SFF processes the NSH header again to identify next SF
(e.g., the Video Optimization and Delivery function in
Figure 3. This SF is not reachable by the same SFF, it needs
to be sent to the next SFF.
* The "Process NSH (PNSH)" sub-function may process the following
information: NSH header, Service Function Graph, Network
locator map available at SFF
* The SPI (Service Path ID) and SI (Service Index) from NSH
header may be used to identify the current position in the
Service Function Graph [RFC7665]. From that, PNSH function
determines the next Service Function, which needs to be
reached.
Trossen, et al. Expires December 29, 2018 [Page 9]
Internet-Draft Name Based SFF June 2018
* As an example, let us examine the following Service Function
Graphs available at the SFF node. Each graph may be
identified/associated with a SPI.
+-------------------------------------------------------+
| ,-+-. ,---. ,---. ,---. |
| / \ / \ / \ / \ |
|( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) |
| \ / \ / \ / \ / |
| `---' `---' SPI = 10 `---' `---' |
+-------------------------------------------------------+
,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \
( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 )
\ / \ / \ / \ / \ /
`---' `---' `---' `---' `---'
,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \
( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 )
\ / \ / \ / \ / \ /
`---' `---' `---' `---' `---'
Figure 6: Example of mapping SFCs onto SPI/SI Information
* Let us assume that PNSH determines from NSH header that SPI =
10 and SI = 254. SPI value of 10 indicates that the first
graph (inside dotted line) in the above diagram is referenced.
The SI value indicates the location in the graph. Generally at
the beginning of the graph, SI is set to 255 and decremented by
1 as the packet traverses each node. In this case, e.g. a
value of 254 indicates that 1 nodes (e.g. Firewall function)
have been traversed and the next SF to reach is 2 (e.g. the
Video Optimizer / Video delivery function).
* Next SPI may be used as an index in the Network Locator Map
[RFC8300] (see Figure 1) to identify the next hop .
* SPI = 10 and SI = 254 indicates next hop is 192.51.100.10. It
indicates to reach the next SF, the packet needs to reach the
host with the address and use GRE as Layer 2 encapsulation.
o Add TE (ATE): The third sub-function is to identify the Transport
encapsulation (TE) for the Packet and NSH. The transport
encapsulation is added to the packet and NSH. SFF puts the
encapsulated packet in the network to be forwarded to the next SF.
Trossen, et al. Expires December 29, 2018 [Page 10]
Internet-Draft Name Based SFF June 2018
Service functions (SF, SF1, ....SFn) act on an incoming packet based
on the NSH context information. E.g. SF1, i.e. Firewall function
apply policy based on UserID and decides if the packet should be
forwarded or not. The SF then decrements SI, add the NSH back into
packet and forwards to SFF. The local SFF then looks into NSH and
forwards in a similar way to next service function.
The SFC architecture [RFC7665] does not mandate how the SFP is
compiled or how SFCs are defined in general. For the compilation of
SFC, it is envisioned that the network operator identifies the
Service Functions (SFs), that a packet need to traverse, to compose
or offer a specific service. Other alternatives are the
specification of SFCs through standardization bodies, reflecting a
standardized exchange that represent a standardized service that can
be deployed in operator network.
It is envisioned that the network operator or the service provider
defines the Service Function Path for a given SFC. The specific SFP
can be decided based on policy, network deployment, services to be
offered, how a packet related to an user or a service needs to be
processed or served. Through the selection of the specific SFP for a
given SFC, the network operator has full control over how to realize
the given SFC.
For the distribution of the SFC forwarding information, i.e., the
Network Locator Map, a controller is envisioned to provide the
necessary information to the SFC nodes (i.e., the classifier and
SFF). The configuration information and provisioning may be done
using Netconf, CLI and it includes "Network Locator Map". This
configuration information may be provided to the SFC nodes during
initialization, periodic refresh or when required. Realizations of
such 'controller' could be a Northbound SDN controller application.
It is this management level distribution of configuration
information, such as the Next Hop information to the SFF nodes, that
impede flexibility by requiring any change to, for instance, Next Hop
information to be distributed to the suitable SFF node in cases of
changing the specific Service Function instance which should be used
for the next transactions traversing this SFF node. In the following
chapters, we formalize this problem and provide a solution for it.
4. Challenges with current framework
As outlined in Section 3, the Service Function Path defines an
ordered sequence of specific Service Functions instances being used
for the interaction between initiator and service functions along the
SFP. These service functions are addressed by IP addresses and
Trossen, et al. Expires December 29, 2018 [Page 11]
Internet-Draft Name Based SFF June 2018
defined as next hop information in the network locator maps of
traversing SFF nodes.
As outlined in the use case, however, the service provider may want
to provision SFC nodes based on dynamically spun up service function
instances so that these (now virtualized) service functions can be
reached in the SFC domain using the SFC underlay layer.
Following the original model of SFC, any change in a specific
execution points for a specific Service Function along the SFP will
require a change of the SFP information (since the new service
function execution points likely carries different IP or L2 address
information) and possibly even the Next Hop information in SFFs along
the SFP. In case the availability of new service function instances
is dynamic (e.g., through the use of container-based virtualization
techniques), the current model and realization of SFC reduces the
flexibility of the service providers and increases the management
complexity incurred by the frequent changes of (service) forwarding
information in the respective SFF nodes. This is because any change
of the SFP (and possibly next hop info) will need to go through
suitable management cycles.
The next section outlines a solution to address the issue, allowing
for keeping SFC information (represented in its SFP) intact while
addressing the flexibility desire of the service provider.
5. Name based operation in SFF
5.1. General Idea
The general idea is two-pronged. Firstly, we elevate the definition
of a Service Function Path onto the level of 'name-based
interactions' rather than limiting SFPs to Layer 3 or Layer 2
information only. Secondly, we extend the operations of the SFF to
allow for forwarding decisions that take into account such name-based
interaction while remaining backward compatible to the current SFC
architecture [RFC7665]. In the following sections, we outline these
two components of our solution.
5.2. Name-Based Service Function Path (nSFP)
In the existing SFC framework [2], as outlined in Section 3, the SFP
information encapsulates forwarding information based on Layer 2 or 3
information, i.e., MAC or IP addresses. We introduce the notion of a
'name-based service function path (nSFP)'.
In today's networking terms, any identifier can be treated as a name.
The realization of "Name based SFP" through extended SFF operations
Trossen, et al. Expires December 29, 2018 [Page 12]
Internet-Draft Name Based SFF June 2018
(see Section 5.4) is illustrated using HTTP transactions. Here, URIs
are being 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 the protocol) and URIs (as next hop identifier within the
SFP). Other identifiers such as an IP address itself can also be
used and are interpreted as a 'name' in the nSFP . With this, our
notion of the nSFP goes beyond the initial proposals made in [7],
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 identifiers), such as www.foo.com/
service_name1, are all captured by the notion of 'name' in this
draft.
Generally, nSFPs are defined as an ordered sequence of the "name" of
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 ->
www.foo2.com/service2
Our use case in Section 2 can then be represented as an ordered named
sequence. An example for a session initiation that involves an
authentication procedure, this could look like 192.168.x.x ->
smf.3gpp.org/session_initiate -> amf.3gpp.org/auth -> smf.3gpp.org/
session_complete -> 192.168.x.x
In accordance with our use case in Section 2, any of these named
services can potentially be realized through more than one replicated
SF instances. This leads to make dynamic decision on where to send
packets along the SAME service function path information, being
provided during the execution of the SFC. Through elevating the SFP
onto the notion of name-based interactions, the SFP will remain the
same even if those specific execution points change for a specific
service interaction.
The following diagram describes this name-based SFP concept and the
resulting mapping of those named interactions onto (possibly)
replicated instances.
Trossen, et al. Expires December 29, 2018 [Page 13]
Internet-Draft Name Based SFF June 2018
+---------------------------------------------------------------+
|SERVICE LAYER |
| 192.168.x.x --> www.foo.com --> www.foo2.com --> www.fooN.com |
| || || |
+----------------------||--------------||-----------------------+
|| ||
|| ||
+----------------------||--------------||-----------------------+
| Underlay network \/ \/ |
| +--+ +--+ +--+ +--+ +--+ +--+ |
| | | | | | | | | | | | | |
| +--+ +--+ +--+ +--+ +--+ +--+ |
| Compute nodes Compute nodes |
+---------------------------------------------------------------+
Figure 7: Mapping SFC onto Service Function Execution Points along a
Service Function Path based on Virtualized Service Function Instance
5.3. Name Based Network Locator Map (nNLM)
In order to forward a name-based SFC, we need to extend the network
locator map as originally defined in [RFC8300] with the ability to
consider name relations based on URIs as well as high-level transport
protocols such as HTTP for mean of packet forwarding.
The extended Network Locator Map or name-based Network Locator Map
(nNLM) is shown in Figure 8 as an example for www.foo.com being part
of the nSFP. Such extended nNLM is stored at each SFF throughout the
SFC domain with suitable information populated to the nNLM during the
configuration phase.
Trossen, et al. Expires December 29, 2018 [Page 14]
Internet-Draft Name Based SFF June 2018
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe |
| | | | |
| 10 | 254 | 198.51.100.10 | GRE |
| | | | |
| 10 | 253 | www.foo.com | HTTP |
-----------------------------------------------------------
| | | | |
| 40 | 251 | 198.51.100.15 | GRE |
| | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | |
| 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-------------------------+
Figure 8: Name-based Network Locator Map
Alternatively, the extended network locator map may be defined with
implicit name information rather than explicit URIs as in Figure 8.
In the example of Figure 9 below, the next hop is represented as a
generic HTTP service without a specific URI being identified in the
extended network locator map. In this scenario, the SFF forwards the
packet based on parsing the HTTP request in order to identify the
host name or URI . It retrieves the URI and may apply policy
information to determine the destination host/service.
Trossen, et al. Expires December 29, 2018 [Page 15]
Internet-Draft Name Based SFF June 2018
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe |
| | | | |
| 10 | 254 | 198.51.100.10 | GRE |
| | | | |
| 10 | 253 | HTTP Service | HTTP |
-----------------------------------------------------------
| | | | |
| 40 | 251 | 198.51.100.15 | GRE |
| | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | |
| 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-------------------------+
Figure 9: Name-based Network Locator Map with Implicit Name
information
5.4. Name-based Service Function Forwarder (nSFF)
While [I-D.purkayastha-sfc-service-indirection] outlined the
realization of forwarding packets in URL-based interaction through
HTTP via a specific function (called Service Request Routing in
[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 definition of the
(extended) nSFP.
In our exemplary realization for an extended SFF, the solution
described in this document uses HTTP transactions, i.e., HTTP as an
example bearer protocol for the next hop information. The URI in the
HTTP transaction are the names in our nSFP information, which will be
used for name based forwarding, while the HTTP requests are encoded
in plain text, e.g.,
GET / HTTP/1.1 Host: www.foo.com Accept-Language: en
Following our reasoning so far, HTTP requests (and more specifically
the plain text encoded requests above) are the equivalent of Packets
that enter the SFC domain . The handling of any intermediate layers
such as TCP, IP is left to the realization of the (extended) SFF
operations towards the next (named) hop. For this, we will first
outline the general lifecycle of an SFC packet in the following
Trossen, et al. Expires December 29, 2018 [Page 16]
Internet-Draft Name Based SFF June 2018
subsection, followed by two examples for determining next hop
information in Section 5.4.2, finalized by a layered view on the
realization of the nSFF in Section 5.4.3.
5.4.1. Lifecycle of a Packet
With reference to the SFC architecture, the lifecycle of packet is
shown in Figure 10 below, following the steps outlined in Section 3:
+----------------+
| NSH | HTTP GET |
OUTSIDE | +----------------+
SFC DOMAIN | /\ SF
| ||
+----------+ | +----------+----------+ || +----+----------+
| HTTP GET | _ | | | _ | | |
| Host: |--|_|->| TE + NSH | HTTP GET |---|_|-->| TE | HTTP GET |
| Accept | | | HOST: | SFF | + | HOST: |
| Lang: en | Class | | Acc : | | NSH| Acc : |
+----------+ ifier +----------+----------+ +---||+---------+
||
\/
SFF _
---|_|-->
-------------- ||
OUTSIDE SFC +-----\/---+
DOMAIN | HTTP GET |
| Host: |
| Accept |
| Lang: en |
+----------+
Figure 10: Lifecycle of an SFC Packet traversing SFC Domain
It is also possible that within an SFC domain there may be mix of
routing decisions at the SFF. Conceptually, all routing is done by
interpreting the SFP information as 'names'. The routing decisions
themselves are either based on well-known, e.g., IP routing methods,
or they utilize methods such as those outlined in [EuCNC] (for IP-
addressed SFC packets) or [H2020POINT] (for URI-addressed SFC
packets).
In the proposed solution, the respective operations shown in Figure 5
of Section 3.4 are realized by the name-based SFF, called nSFF in the
following. The following diagram in Figure 11 describes the
traversal between two service function instances of an nSFP-based
Trossen, et al. Expires December 29, 2018 [Page 17]
Internet-Draft Name Based SFF June 2018
transactions in an example chain of: 192.168.x.x -> SF1 (www.foo.com)
-> SF2 (www.foo2.com) -> SF3 -> ...
According to the lifecycle in Figure 10 and based on our example
chain above, the following figure shows an example traffic flow in an
nSFP with nSFF and nNLM.
+----------+
| SF1 | +--------+ +------+
| instance |\ | NR | | SF2 |
+----------+ \ +---/\---+ +------+
\ || ||
+------------+ \ +-------+ +---------+ +---------+ +-------+
| Classifier |-->| nSFF1 |-->|Forwarder|-->|Forwarder|-->| nSFF2 |
+------------+ +-------+ +---------+ +---------+ +-------+
||
+----------+
| Boundary |
| node |
+----------+
Figure 11: Operations at extended SFF
Traffic originates from a Classifier or another SFF on the left.
Traffic is processed by the incoming nSFF1 (on the left side) through
the following steps. The operations described in Figure 4 are
extended and the traffic exits at nSFF2:
o Step 1: At nSFF1 the nNLM in Figure 12 is assumed
Trossen, et al. Expires December 29, 2018 [Page 18]
Internet-Draft Name Based SFF June 2018
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe |
| | | | |
| 10 | 254 | 198.51.100.10 | GRE |
| | | | |
| 10 | 253 | www.foo.com | HTTP |
| | | | |
| 10 | 252 | www.foo2.com | HTTP |
| | | | |
| 40 | 251 | 198.51.100.15 | GRE |
| | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | |
| 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-------------------------+
Figure 12: nNLM at SFF1
o Step 2: nSFF1 removes the previous transport encapsulation (TE)
for any traffic originating from another SFF or classifier
(traffic from an SF instance does not carry any TE and is
therefore directly processed at the nSFF).
o Step 3: nSFF1 then processes the NSH information to identify the
next SF at the nSFP level by mapping the NSH information to the
appropriate entry in its nNLM (see Figure 12) based on the
provided SPI/SI information in the NSH (see Section 3) in order to
determine the name-based identifier of the next hop SF. With such
nNLM in mind, the nSFF searches the map for SPI = 10 and SI = 253.
It identifies the next hop as = www.foo.com and HTTP as the
transport. Given the next hop resides locally, the SFC packet is
forwarded to the SF1 instance of www.foo.com (see Figure 11).
o Step 4: The SF1 instance then processes the received SFC packet
according to its service semantics and modifies the NSH by setting
SPI = 10, SI = 252 for forwarding the packet along the SFP. It
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
the NSH modified (SPI = 10, SI = 252) by the SF1 instance. It
retrieves the next hop information from its nNLM in Figure 12, to
be www.foo2.com. Due to this SF not being locally available, the
nSFF consults any locally available information regarding the
routing/forwarding information towards a suitable nSFF that can
serve this next hop.
Trossen, et al. Expires December 29, 2018 [Page 19]
Internet-Draft Name Based SFF June 2018
o Step 6: If such information exists, the Packet (plus the NSH
information) is marked to be sent towards the nSFF serving the
next hop based on such information in step 8.
o Step 7: If such information does not exist, nSFF1 consults the
Name Resolver (NR) to determine the suitable routing/forwarding
information towards the identified nSFF serving the next hop of
the SFP. For future SFC packets towards this next hop, such
resolved information may be locally cached, avoiding to contact
the Name Resolver for every SFC packet forwarding. The packet is
now marked to be sent via the network described in next step 8.
o Step 8: Utilizing the forwarding information determined in steps 6
or 7, nSFF1 adds the suitable transport encapsulation (TE) for the
SFC packet before forwarding via the forwarders in the network
towards the next nSFF i.e. 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, it
removes the TE and processes the NSH to identify the next hop
information. At nSFF2 the nNLM in Figure 13 is assumed. Based on
the nNLM in Figure 13 and NSH information where SPI = 10 and SI =
252, nSFF2 identifies the next SF as www.foo2.com.
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| | | | |
| 10 | 252 | www.foo2.com | HTTP |
| | | | |
| 40 | 251 | 198.51.100.15 | GRE |
| | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | |
| 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-------------------------+
Figure 13: nNLM at SFF2
o Step 10: If the next hop is locally registered at the nSFF, it
forwards the packet (+NSH) to the service function instance, using
suitable IP/MAC methods for doing so.
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
boundary node, as shown in Figure 11.
Trossen, et al. Expires December 29, 2018 [Page 20]
Internet-Draft Name Based SFF June 2018
5.4.2. Determining Suitable Forwarding Information
The extended operations of the nSFF rely on determining suitable
forwarding information in step 3, 5, 6 and 7 as well as adding this
forwarding information as traffic encapsulation in steps 8 and 10 of
the previous section. We describe details of the extended nSFF
operations in the following sections.
5.4.2.1. DNS-based Resolution
The SFF-Name Resolver (NR) communication in Figure 11, i.e., step 7,
may be realized through a DNS lookup towards the next hop information
derived from the (extended) network locator map.
Hence, the NR is the first DNS resolver configured at the nSFF for
any such lookup. The NR will return the suitable IP address of the
SF instance provided in the lookup. The NR may also propagate any
received lookup in case a NR-local setup cannot be done. Examples
for the protocol used between nSFF and NR are the available DNS
protocol.
Upon receiving the NR response, the nSFF uses IP-based communication
to send the SFC packet to the next hop, i.e., IP is being used for
the traffic encapsulation of steps 8 and 10, while the forwarders in
Figure 11 are standard IP routers.
For registration of the local SF instances at each nSFF, methods such
as management consoles (mapping IP addresses onto DNS names) or DNS
registrations (with nSFF intercepting such registrations) can be used
to build an nSFF-local knowledge of all locally available service
functions at the level of a named function.
One problem arises, however, with caching NR (i.e., Name Resolver)
responses in step 5 since this requires dealing with stale DNS
entries when such DNS entries might change due to new instances of
service functions becoming available
5.4.2.2. IP/HTTP-over-ICN
The methods in [EuCNC], [H2020POINT] describe steps to interpret IP
or HTTP level communication from an incoming service instance
(residing on, for instance, an IP-based device such as an UE or a
server or a network component) as ICN (information-centric
networking) based communication.
Here, the NR in Figure 11 is implemented by the functions of
Rendezvous (RV) and Topology Management (TM) in [EuCNC],
Trossen, et al. Expires December 29, 2018 [Page 21]
Internet-Draft Name Based SFF June 2018
[H2020POINT]. The nSFF in Figure 11 is implemented by the methods in
the Network Attachment Point (NAP) in [EuCNC], [H2020POINT].
Hence, after having removed any transport encapsulation of the
incoming SFC packet (in case of receiving the packet from a
classifier) and the determination of an SFC packet as being sent to
another SFF (see steps of the nSFF described earlier), the nSFF
publishes a suitable ICN packet with the HTTP or IP packet (depending
on the next hop information in the nNLM) as well as the NSH as
payload.
If no suitable local forwarding information exists at the nSFF for
this publication, a path computation request is sent to the NR (i.e.,
the combination of RV and TM in [EuCNC], [H2020POINT] ) and suitable
forwarding information is returned to the nSFF. This forwarding
information is used to publish the SFC packet (i.e., either an IP
packet or an HTTP plain text request, depending on the next hop
information in the nNLM) to the suitable nNLM by using this
forwarding information as traffic encapsulation towards the next
nSFF. As the next nSFF for the specific next hop information, said
nSFF has previously subscribed to the named SFP information, e.g.,
www.foo.com or the next hop IP address. It will therefore receive
the forwarded SFC packet + NSH, published in the previous step.
For the forwarding information provided by the NR in the initial
publication, solutions such as those in [Reed2016] can be used.
Here, the IPv6 source and destination addresses are used to realize a
so-called path-based forwarding from the incoming to the outgoing
nSFF. The forwarders in Figure 11 are realized via SDN (software-
defined networking) switches, implementing an AND/CMP operation based
on arbitrary wildcard matching over the IPv6 source and destination
addresses, as outlined in [Reed2016] . As described in step 8 of the
extended nSFF operations, this forwarding information is used as
traffic encapsulation. With the forwarding information utilizing
existing IPv6 information, IP headers are utilized as TE in this
case. The next hop nSFF (see Figure 11) will restore the IP header
of the packet with the relevant IP information used to forward the
SFC packet to SF2 or it will create a suitable TE information to
forward the information to another nSFF or boundary node.
Alternatively, the solution in [I-D.purkayastha-bier-multicast-http]
suggests using a so-called BIER (Binary Indexed Explicit Replication)
underlay. Here, the nSFF would be realized at the ingress to the
BIER underlay, injecting the SFC packet (plus the NSH) header with
BIER-based traffic encapsulation into the BIER underlay with each of
the forwarders in Figure 11 being realized as a so-called Bit-
Forwarding Router (BFR) [RFC8279].
Trossen, et al. Expires December 29, 2018 [Page 22]
Internet-Draft Name Based SFF June 2018
Various registration methods can be used to bind next hop information
to a specific nSFF, such as a management console, DNS interception,
or a local registration interface. All of those methods eventually
result in a suitable subscription of the outgoing nSFF to the next
hop information, this subscription being sent to the NR, which in
turns allows the NR to determine suitable forwarding from an incoming
nSFF to said outgoing (next hop) nSFF.
5.4.3. Layered View of Realizing nSFF
In Figure 14 below, we present a layered view on realizing the nSFF
with a focus on the layers that are present at the incoming and
outgoing nSFF based on well known protocols being used but not
limiting to those only. For the sake of simplicity, we here assume
SDN being used as a Layer 2 technology although the implementation
approach equally applies to a BIER-based approach. We also show only
a sub-chain from one SF to another, leaving out the reception from
another SFF at the incoming SFF.
Here we assume the use of HTTP as the bearer protocol over the
operator (transport) network. As indicated in Section 5.2, one could
also realize named services that would normally run over a TCP-based
connection only, such as a BitTorrent type of protocol with named
chunks of content.
As also shown in the figure, IP-level SFCs can also be realized via
this implementation approach, utilizing methods such as those in
[EuCNC] by interpreting IP addresses as names. With this in mind,
the HTTP, TCP or IP level transactions originating from SF1 on the
left of Figure 12 are terminated at the incoming nSFF and then mapped
onto the Layer 2 exchange over the transport network, while the right
nSFF restores the suitable transaction and forwards the SFC packet to
SF2.
Trossen, et al. Expires December 29, 2018 [Page 23]
Internet-Draft Name Based SFF June 2018
+-------+ +------+----+ +----+-----+
|App | |App | | +--------+ | | APP |
|HTTP | |and ----> | | NR | | | and |
|TCP |->|OTHER |nSFF| +---/\---+ |nSFF -> |--
|IP | |prot | | || | |other| |
+-------+ +------+----+ +---------+ +---------+ | |proto| |
| L2 | | L2 |->|Forwarder|-->|Forwarder|-->+----------+ |
+-------+ +------+----+ +---------+ +---------+ | L2 | |
SF1 nSFF1 +----------+ |
+-------+ nSFF2 |
| App |/ |
| HTTP | -----------+
| TCP |\
| IP |
| L2 |
+-------+
SF2
Figure 14: Layered View of Realizing a Service Router as Part of
extended SFF
6. IANA Considerations
This document requests no IANA actions.
7. Security Considerations
TBD.
8. 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>.
[EuCNC] Trossen, D. and et al., "POINT: IP Over ICN - The Better
IP?", European Conference on Networks and Communications
(EuCNC), , 2015.
Trossen, et al. Expires December 29, 2018 [Page 24]
Internet-Draft Name Based SFF June 2018
[H2020POINT]
EU, "H2020 POINT project, First Platform Design", D 3.1,
2015, <https://www.point-h2020.eu/wp-
content/uploads/2015/12/
POINT_D3.1-First_Platform_Design_v1.01.pdf>.
[I-D.purkayastha-bier-multicast-http]
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]
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]
Reed, M., Al-Naday, M., Thomas, N., Trossen, D., and S.
Spirou, "Stateless multicast switching in software defined
networks", ICC 2016, 2016.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
Authors' Addresses
Dirk Trossen
InterDigital Communications, LLC
64 Great Eastern Street, 1st Floor
London EC2A 3QR
United Kingdom
Email: Dirk.Trossen@InterDigital.com
URI: http://www.InterDigital.com/
Trossen, et al. Expires December 29, 2018 [Page 25]
Internet-Draft Name Based SFF June 2018
Debashish Purkayastha
InterDigital Communications, LLC
Conshohocken
USA
Email: Debashish.Purkayastha@InterDigital.com
Akbar Rahman
InterDigital Communications, LLC
Montreal
Canada
Email: Akbar.Rahman@InterDigital.com
Trossen, et al. Expires December 29, 2018 [Page 26]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/