## 4 IoT Service Orchestration via NDN
### Distributed Mechanisms  
A pioneering work extending NDN to support distributed in-network computations, with a special focus on IoT at the edge, is Named Function Networking (NFN) [6; 10; 46]. In NFN, a name can represent a content, a function capable of processing the content, or an expression combining both. \begin{table}
\begin{tabular}{p{85.4 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Mechanism** & **Type** & **Short description** \\ \hline NFN FoX [6] & Distributed & First, it tries to find a cached result on the path towards the data source. In case of failure, the computation is performed as close as possible to the data source or it is pushed into a node/server off-path. \\ \hline NFN EdgeFox [10] & Distributed & Customizes FoX for edge domains, where nodes advertise the availability of the functions they provide, and they are queried for the result. \\ \hline NFN FaX [10] & Distributed & The computation is started in the first available edge node, and it is stopped if a cached result is found in the meanwhile. \\ \hline IoT-NCN [7] & Distributed & The cost of IoT service execution is computed by on-path nodes, according to a weighted function that takes as input the closeness cost and the processing cost. The node with the lowest cost is selected as the executor. \\ \hline NDN edge computing [34] & Distributed & The less congested node is selected as the executor. \\ \hline CS-Man [42; 43] & Centralized & A service manager is in charge of identifying the executors of IoT services according to their capabilities. \\ \hline ICN-isapiens [44; 45] & Centralized & A software component called deployer is in charge of loading the IoT services in specific fog nodes depending on the physical IoT devices they control. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: IoT service orchestration mechanisms in NDN. The NDN forwarding engine is augmented with a \(\lambda\)-expression resolution system, which processes all interests that have the postfix name component /NFN. Interest packets that do not carry the /NFN tag in the name field are treated as legacy requests for contents. A generic NFN name consists of the following components:  
\[[ccn:nfn|\quad/name-of-content|\quad/name-of-function]\]  
For instance, a client requesting a video transcoded in a certain format can send an interest with the following NFN name [6]:  
\[[ccn:nfn|\quad/name-of-video|\quad/name-of-transonder]\]  
The default NFN service orchestration strategy is called Find-or-Execute (FoX). First, the network tries to find a cached copy of the result, i.e., the transcoded video in the above example. Therefore, the request is forwarded towards the data producer, on path, according to the component \(/name-of-media\). If this search fails, FoX tries to compute the result in the NFN node \(n\) closer to the data producer. If not locally available, this node has to retrieve the content and the function code by sending separate interests for \(/name-of-media\) and \(/name-of-transonder\). If \(n\) is not able to perform the service, it can push the computation towards another on-path node or even towards an off-path node, e.g., a cloud facility. In Reference [10], FoX is extended for orchestrating IoT services at the edge. The resulting EdgeFox strategy assumes that nodes at the network edge are NFN capable and that they may advertise the name of the functions they are able to execute. Similarly to FoX, the interest is first forwarded towards the data source to find a cached result. In case of failure, the interest is forwarded to the NFN node owning the function to check for the result there. If this search also fails, then the result is computed in the first available edge node, which should retrieve data and function codes. The main problem with FoX and EdgeFox is a potential long service provisioning time due to the different searching steps before starting the computation. This could negatively affect latency-sensitive services.