## 3 PF-ClusterCache: Popularity and Freshness-Aware Collaborative Cache Management
Consumer C2 sends a request (an Interest) to its edge router \(R1\) asking for content name \(Data1\), as indicated by the red arrow \((1)\) in both figures. \(R1\) starts by hashing the requested content name \(Data1\) to find out the corresponding Surrogate Caching Node (SCN) within the local cluster. The hashing function maps \(Data1\) to \(R3\) as the unique SCN where \(Data1\) could be cached. Router \(R1\) then takes the requested content name (\(Data1\)) from Interest.name1 and puts it in Interest.name2. Then, it places the  
Figure 2 illustrates the case where the requested content \(Data1\) is to be fetched from its producer as there is no copy of it already cached within the cluster. \(R3\) first exchanges Interest.name1 and Interest name2 and then forwards the Interest using its FIB. The Interest is consequently forwarded to \(R4\) and then to \(R7\) and so on up until reaching the producer. The insertion of the name of the SCN \(R3\) in Interest.name2 is meant to avoid the caching of the content on its way back from the producer to the consumer. The only router allowed to cache a copy is this SCN. When receiving the Interest, the producer responds by sending the requested content after putting the content name (\(Data1\)) in Data.name1 and the SCN name \(R3\), which has been received in Interest.name2, in Data.name2. As such, the Data packet will follow the reverse path towards consumer C2 as prescribed by the PITs. On its way to C2, the Data packet passes by its SCN \(R3\), which consults its popularity table PT to verify whether this name \(Data1\) has a popularity count greater than or equal to the PF-ClusterCache threshold (\(PopThreshold\); see Algorithm 4). As this is the case, \(R3\) first caches a copy in its CS, as illustrated in green in Figure 2, and then forwards the Data packet towards consumer C2 according to its PIT. The second case is when there is indeed a cached copy of the requested content in the CS of the SNC \(R3\). This is illustrated in Figure 3. Node \(R3\) responds with its cached copy, which contains the content name in Data.name1. The Data packet follows the reverse path towards consumer C2, as indicated by the PITs of \(R3\), and \(R1\). This is illustrated in Figure 3 by green arrows (3) and (4) successively. Algorithm 2 illustrates the PF-ClusterCache strategy at any given router in the network upon the arrival of an Interest packet. The router first checks whether the Interest comes directly from an attached consumer. In the affirmative, it applies the predefined hashing function H to map the content name (Interest.name1) to its Surrogate Caching Node (SCN). Then, it places the received content name in Interest.name2 and the SCN name in Interest.name1. Then, it forwards the Interest normally according to its FIB. Since Interest.name1 contains the SCN name, the Interest will consequently be directed toward the SCN router. However, if the incoming Interest is not from an attached consumer, the receiving router checks whether it itself is the designated SCN. In the affirmative, it first verifies whether Interest.name2 (which is the name of the requested data) has already an entry in the popularity table PT. If so, it increments its count; otherwise, it creates a new entry with a popularity count equal to 1. Then, it performs either of the above-described cases depending on whether or not its CS contains a cached copy of the requested data content. Recall that the popularity table PT is managed as a finite-capacity LPF storage system. Algorithm 2 calls Algorithm 3 for this very purpose. Furthermore, note that the last step in Algorithm 2 represents the case of a receiving router that is neither the SCN nor the consumer of the requested data content. This type of router normally forwards the Interest according to its FIB. This ensures that Interest forwarding is always accomplished using Interest.name1 in synergy with the specification of the Network Forwarding Daemon of the NDN.