## 4 In-Network Computing via ICN
### Service Naming and Messages  
The first steps in enabling in-network computing via NDN is to define an effective naming scheme that can identify both the requested processing function and the data to be processed and define the communication primitives in addition to the standard NDN request and response packets, i.e., Interest and Data. Over the years, various solutions have been proposed to address these needs, as summarized in Table 3 and discussed in the following. Named Function Networking (NFN) [58] was the first proposal extending NDN by integrating data processing capabilities alongside data retrieval. In NFN, names can represent data content, a function for processing the content, or even an expression that combines both. Consequently, an Interest packet can carry complex expressions that refer to named data, named functions, or a combination of the two. The network is responsible for resolving these expressions and identifying the node that will execute the required function. This process seamlessly integrates expression resolution with name-based forwarding. \begin{table}
\begin{tabular}{p{56.9 pt} p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Approach** & **Ref.** & **Name Format** & **Key Features** \\ \hline \multirow{3}{*}{**NFN**} & \multirow{3}{*}{[58; 59]} & Names represent data and functions with \(\lambda\)-expressions. The postfix name component /_NFN_ denotes the computation request. & \(\bullet\) & Interest packets can carry complex expressions combining data and functions \\  & & & & \\ \hline \multirow{3}{*}{**NCN**} & \multirow{3}{*}{[4, 60]} & Hierarchical names identify both data and functions. The tag /_NCN_ is used as a delimiter between the two name parts. & \(\bullet\) & Compatible with legacy NDN forwarding supports execution parameters in service names \\ \hline \multirow{3}{*}{**ICedge**} & \multirow{3}{*}{[48; 61]} & \multirow{3}{*}{[48; 61]} & \multirow{3}{*}{
\begin{tabular}{} \end{tabular} } & Discovery Interest mechanism for finding available services \\  & & & & Metadata like location-aware clustering for reuse of compute results \\  & & & & Controls Interest lifetime to manage responses; supports dynamic service discovery \\ \hline \multirow{3}{*}{**NFaas**} & \multirow{3}{*}{[62]} & Names include the main prefix _/exec/_ for execution requests. Application requirements are carried as name components. & \(\bullet\) & Functions implemented as unikernels to enable lightweight processing \\  & & & & Hash-based suffixes to distinguish between different requests \\ \hline \multirow{3}{*}{**RICE**} & \multirow{3}{*}{[63]} & Functions named hierarchically or via \(\lambda\)-expressions. _Thunk_ names identify ongoing computations. & \(\bullet\) & Supports long-running computations with trunk-based targeting \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Comparison of service naming and messaging approaches. To achieve this, the NDN forwarding plane is enhanced with a \(\lambda-\)expression resolution engine, which processes all Interests with the postfix name component/NFN, allowing the system to identify and execute functional requests dynamically. In [59], the NFN architecture is augmented with a set of _request-to-computation_, commands to allow the consumers control long-running in-network computations, including pausing, resuming, stopping, or fetching intermediate results. These commands also address challenges such as timeout management by introducing keep-alive messages and support dynamic reconfiguration of computations, making NFN more suitable for real-time and resource-constrained environments. In the Named Computation Networking (NCN) approach [4; 60], both data and functions are assigned hierarchical names, with the function name appended to the data name. The prefix NCN is used as a delimiter between the data name and the function name. If the NCN tag is absent, IoT-NCN nodes treat the Interest as a traditional NDN content request. This structure ensures compatibility with legacy NDN forwarding mechanisms.