As nMANET intents to be compatible with NDN, nMANET also utilises the NDN interest and data packets that were described in Section 3.4.2. However, as nMANET has introduced new features, packet types and tables, it also needs to modify the logic of exchange of packets between nodes. Figure 4.2 and Figure 4.4 depict how nMANET treats interest and data packets when they arrive at a forwarder. Note that these packet processing represents one important difference compared with the traditional NDN packet flow presented in Section 3.4.4.
request for a specific content and packets that contains control commands such as registration or node status requests. Section 4.4.1 presents these details and the decisions that nMANET makes in cases such as naming comparison against information of internal tables and how forwarding strategies are applied when the requested content is not available locally.
Similarly, and in the case of data packets. nMANET makes a distinction between data packets that carry specific requested content and packets that carry control commands such as node status. Section 4.4.2 presents in detail all these decisions and how forwarding information is updated into internal tables in order to be used for further request.
4.4.1
Interest packet processing
Figure 4.2 describes how interest packets are processed in nMANET. It starts when an interest packet arrives at a forwarder and nMANET verifies whether the interest is a control command. If it is a control command, then it verifies whether is it a prefix registration request or a node status request. In the first case, nMANET updates FIB entries, and replies to the requester with a registration acknowledgement. In the case that it is not a prefix registration request, then it corresponds to a node status request, which means that neighbours are requesting the forwarder to provide information about the status of the node. In this case, the forwarder collects information about the status of the node and sends it to the requester.
In the case that the name is not a control command, nMANET checks whether the name is already in the local cache (CS), in which case the content is retrieved from the local cache and sent back to the requester. In this case, the name is not inserted in the PIT as the name has already been satisfied by sending the cached content.
If the content of the name was not cached in the CS, nMANET checks if it was already requested by other nodes by looking whether the name is present in the PIT table. In the case that it is present, nMANET verifies that the interest packet does not correspond to a loop by checking the nonce. If the interest packet does not correspond to a loop, the PIT is updated.
Note that nMANET utilises the nonce value in combination with the name to identified loops. In the case that a second name and nonce arrives and has the same values as the ones stored in the PIT, this interest packet is considered as a loop and it is discarded.
Finally, having a name that was not cached in CS and that is also not present in the PIT causes nMANET to conclude that the name is new for the forwarder. The PIT gets updated and the interest packet is forwarded using the active forwarding strategy.
Figure 4.2:Interest packet flow in an nMANET forwarder
correspond to the outcomes after checking whether the name is a registration request or node status request.
Prefix registration in the interest packet flow A registration packet is a type of control message that contains the prefix of the content available in a producer. In the case that a registration packet arrives at the forwarder and nMANET finds that the prefix is already in the FIB table, only the connection from where this packet came is updated in the corresponding entry for this prefix. On the other hand, if the prefix is not present in the FIB table, nMANET adds a new entry to FIB as a pair of the prefix and the connection from where the registration packet comes. Like NDN, nMANET replies to each prefix registration request with a registration acknowledgement.
Node status in the interest packet flow Node status packets are a type of control message introduced by nMANET. Node status packets are interest and data packets with a dedicated
name, which is ”/localhop/nfd/rib/nodestatus”. In nMANET, a forwarder broadcasts node status request packets to nearby nodes to request information about the status of the node. This request is an interest packet under the name “/localhop/nfd/rib/nodestatus”. On the other side, each receiver of a node status request collects its own local node status information and loads it into a data packet with the same name. This node status response is then sent to the requesters.
Figure 4.3: Flow of the nMANET forwarding strategy for interest packets.
Figure 4.3 shows how the next hop selection and prefix discovery work together to effectively and efficiently forward interests to nodes – fowarders or producers – that can satisfy the interest. Sections 4.5 and 4.6 describe how a forwarder utilises node status information from neighbours in order to select the next hop and discover available prefixes in nearby nodes.
4.4.2
Data packet processing
Figure 4.4 shows how a data packet is processed in an nMANET forwarder. nMANET checks if it is a control request response packet, which in this case means that it is a node status response
that is then used to update the node status table and the FIB. The FIB is updated with prefixes contained in the node status and with the sending node as the next hop. On the other hand, in the case that the name is not a control command, the name of the content is compared with the entries in the local cache (CS). If the name is already in the CS then the data packet is a duplicate and can be discarded.
If the name of the data packet is not present in the CS, nMANET verifies whether this name matches the entries in the PIT. From this comparison, there are two possible outcomes: one outcome is when the PIT does not contain the name, in which case the data packet is considered as not requested. However, it is cached as it can be used for further requests in cases such as the one discussed in Section 4.7.7. The second outcome is in the case that the name matches one or more of the entries in the PIT, in which case nMANET executes the following: updates the FIB and CS with the prefix and the content respectively, retrieves from PIT the connections towards the nodes who requested this name, and after sending the data packet to the nodes that requested the content, nMANET clears all matching PIT entries.