## 4 In-Network Computing via ICN
### Service Naming and Messages
Service names can also include a limited set of input parameters for execution. For example, an Interest with the name _/unirc/buildingEngineering/temp/NCN/avg/p1=10_ requests the calculation of an average over the last 10 temperature values collected from building Engineering at the University of Reggio Calabria. Nodes without computing capabilities retain information only about the data name prefix (e.g., / unirc) and route the packet accordingly. In the ICedge scheme [48], service names are structured hierarchically and carry semantic meaning. The first name component is the _service name_, which identifies the type of service being requested, e.g., _/Yolo_ for an image annotation service. The second name component may include _compute-aware convention_ metadata, which help the network to detect if a similar task has been processed recently and enable compute reuse. For example, for location-aware services, the naming convention might include geographic coordinates to cluster tasks related to specific areas on a map. Users send \"discovery\" Interests under the namespace _/discovery_ to find out which services are available in the edge network. Edge nodes respond with details about available services, naming conventions and metadata, and wait for specific service requests from consumers. The latter can also set a lifetime for the discovery Interest to effectively control the number of responses [61]. In the Named Function as a Service (NFaaS) approach [62], the authors assume that processing functions are lightweight virtual machines implemented as unikernels. Consumers can request the function code by sending Interests including the name of the function to be processed. In parallel, they can also request the execution of a function, by including the prefix _/exec/_ followed by an indicator for application requirements, such as _/exec/delay/_ for delay-sensitive applications, or _/exec/bandwidth/_ for bandwidth-hungry applications. Each request name may also include a hash-based suffix to differentiate between consecutive requests with different input parameters and optional Type-Length-Value (TLV) fields to set a task deadline. In the RICE proposal [63], functions can be named hierarchically or via _lambda_-expressions, uniquely identifying the computation and its parameters. In addition, _thunk_ names identify specific service instances already being run on a specific node and they are used to retrieve long-running computations. A thumb is composed of three main components: (i) the name of the in-network executor, (ii) the name of the instantiated function, and (iii) the name of the function's internal state. A client uses the thumb name to directly target the executor, without the need of maintaining a state in intermediate nodes. In RICE, a four-way handshake protocol is introduced for authenticating clients before starting a computation, thus preventing denial-of-service attacks. The handshake begins with the client sending an initial Interest message, which includes a unique identifier and a function name to be executed. This message establishes temporary state in the PITs of intermediate nodes to ensure correct routing of subsequent messages. Upon receiving the request, the executor replies with another Interest message that is used for authenticating the client and transmit additional instructions. The client responds with a Data message, which contains authentication credentials and input parameters needed for the computation. Once the server validates the client and prepares to allocate resources, it concludes the handshake with a confirmation Data message, which also provides a unique thumb name, allowing the computation results to be retrieved later.