Per-device Service Function Chaining for Internet of Things
IntroductionSFC - 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) . 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.
WoT architecture can help to extend SFC to the edge of the network. WoT concept of virtual device, named “WoT Servient” , 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.
Standard for SFCIn 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
- Network address translation
- Intrusion and malware detection
- Parental controls
- Lawful intersection
- Monitoring and analytic probes
- WAN/TCP optimizer
- Video optimizer
- HTTP header enrichment
- Content filtering
- Content caching
ArchitectureThe 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.
Deployment scenariosWoT 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.
- 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.
ConclusionWe 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.