This
article describes how Service Function Chaining (SFC) can be applied to
enhance per-device flow control among the Internet of Things. This
approach aim to enable a custom chain of Virtual Network Function (VNF)
for every single IoT device. This article addresses the challenge
related to the expansion of Software Defined Networking (SDN) to IoT
devices over Internet. The contribution presented by this article is the
extension of the Web of Things (WoT) architecture to support OpenFlow
and enable integration of WoT virtual devices to the SDN network.
Introduction
SFC - RFC 7665 - is an approach that provides the ability to define
an ordered list of a network services (Firewalls - L4-7, Network Address
Translation - NAT, Intrusion Protection and Detection Systems - IDS
& IPS) [1]. These services are then "composed" together in a virtual
chain. SFC is a capability that uses SDN to create a service chain to
set up suites or catalogs of connected services that enable the use of a
single network connection for many services, with different
characteristics.
 |
Figure 1 |
SDN is the enabler of SFC as illustrated in Figure 1. The idea behind
such an approach is to pipe the flows between two networks with
different chaining according to the requirement associated with each
single flow. The flow is forwarded to a set of middle-boxes that are
implementations of VNFs.
WoT architecture can help to extend SFC to the edge of the network.
WoT concept of virtual device, named “WoT Servient” [2], provides the
access to, control and get the status and values from IoT physical
devices. It offers a runtime and an API to build applications that runs
on multiple environments according to the deployment scenarios. The
virtual device is mainly composed from three layers:
- Protocol binding: to communicate with the other devices and users
- Runtime environment: offers an API for creating server functions
which accepts request through WoT Interface from other clients.
- Applications: user code that can access to the hardware resources.
it contains the logic and uses the API provided by the runtime to
communicate with other devices.
The challenge addressed by this article is the extension of the SFC
to the edge of the network. WoT virtual devices are good candidates to
support this extension. To do so, we propose to adapt the runtime
environment to make it OpenFlow aware. More over, we propose to build
micro network functions as applications and pipe flows between them
according to the flow rules.
 |
Figure 2 |
As illustrated in Figure 2, extending SDN and VNF to the edge can
enable a new degree of granularity in the control of the flow for every
single device. Moreover, some functions can be deployed on the virtual
device to implement device specific controls such as the Manufacturer
Usage Description (MUD).
Standard for SFC
In the Internet Engineering Task Force (IETF) SFC working group
started a standardization effort relative to the categorization of these
middle-boxes. The mobile use case (informational) draft by Haeffner et
al. put these into 3 categories. Category 1 are general propose
functions used by all services. This category includes:
- Deep packet inspection
- Firewall
- Network address translation
- Load-balancer
Category 2 are value added services that are specific to the cloud or the Internet service providers that includes:
- Intrusion and malware detection
- Parental controls
- Lawful intersection
- Monitoring and analytic probes
Category 3 are mobile-specific that enhance the application for SFC is in mobile networks that includes:
- WAN/TCP optimizer
- Video optimizer
- HTTP header enrichment
- Content filtering
- Content caching
Architecture
The primary advantage of SFC is to automate the way virtual network
connections can be set up to handle traffic flows for connected
services. The WoT architecture introduces some capabilities we can
leverage to extend the chain of function to the devices. One of the main
components introduces by the WoT is WoT servient which is a virtual
component associated with IoT devices. It enables accessing to the
device's function as a web resource. WoT aims to normalize the access to
the devices as web resources by both humans and other devices. WoT
servient can be used to extend the VNF platform to the edge of the
network. Virtual device (WoT Servient) can host lightweight or micro
network functions. Moreover, virtual device should be aware of OpenFlow
to enable chaining the local micro-functions with the remote network
functions as illustrated in Figure 3.
 |
Figure 3 |
The virtual devices are first class citizen in SDN in this
architecture. the service classification consider the function available
in both locally on the virtual device and on the remote location. The
runtime environment should support integration with the SDN controller
and act according the the rules pushed from the controller. the
objective is not to implement a high throughput forwarder, the objective
is to have a lightweight module that can pipe the flows between
applications. knowing that the applications use an API to communicate
between each others.
 |
Figure 4 |
The architecture proposed by WoT is still accurate as the layers
defined by the WoT still apply. Unlike the reference implementation, the
runtime environment on this architecture limits the communications
from/to the application according to the flow tables. this tables are
filled by the SDN controller to enforce a specific SFC composed from the
local and remote VNF. Figure 4 illustrate an example of integration
with a controllers in the cloud. Deployment is not limited to the cloud
as the controller and the functions can be deployed and managed by the
Internet service provider.
Deployment scenarios
WoT virtual devices are used on this architecture as a building block
of the VNF platform. Deployment scenarios follows WoT scenarios with
the three levels of deployment: end-devices, edge/fog, and cloud as
illustrated in Figure 5. On all three levels, devices can communicate
only with their corresponding virtual devices. All external
communications uses the API provided by runtime environment.
 |
Figure 5 |
Three scenarios are introduced by the extension of SDN to the virtual
devices. According to the use case, flows can use local VNF, remote
VNF, or a mix in hybrid mode. Specific networking infrastructure is
required for every scenario.
- Local VNF: No integration with a remote SDN network is needed at
the data plane. A link at the control plane is need to get the chaining
configuration for the flows. As the all the chaining happens locally on
the virtual device, the data plane is limited to the virtual device
boundaries.
- Remote VNF: Requires integration with both data and control
planes. Even if the virtual device does not apply any VNF to the flow,
the runtime environment need to get the first remote VNF in the chain to
forward the traffic to it from the applications.
- Hybrid mode: It requires also integration with both data and
control planes. Runtime environment pipes the traffic to the local VNF
before forwarding it to the first remote VNF on the chain.
Conclusion
We discussed in this article the extension of SDN control plane to
the WoT virtual devices to enhance the granularity of the control on IoT
devices. I will update this article with implementation details and
results.
References
[1]
https://tools.ietf.org/html/rfc7665
[2]
https://w3c.github.io/wot/architecture/wot-architecture.html
What you are proposing is an abstract set of service functions that can be placed either in the provider network or network edge (if the capability is available to place them there). These network functions can work together to achieve a goal. The functions would be placed according to some affinity rules (i.e. you can determine what functions need to live together and chain those using DPDK (tight coupling) or you can use IP to send the data to where the function resides). So this would be a distributed VNF platform.
ReplyDeleteIs this an accurate summary of the proposal?
Thanks for sharing the best information and suggestions, If you are looking for the best IOT Solutions, then visit Emflair Technologies. Highly energetic blog, I’d love to find out some additional information.
ReplyDelete