Per-device Service Function Chaining for Internet of Things

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