Our proposed hash-routing framework comprises two types of functional entities: Proxy and Routing Functions (PRF) and Caching Functions (CF). PRF and CF entities can be physically separated or co-located, but since they provide in principle separate functionalities we describe them separately.
Proxy and Routing Functions (PRF) are the first entities traversed by content requests when entering the cache network and they are in charge of forwarding them to relevant CF instances. They have knowledge of all CF instances in the network and their addresses (but do not need to know which content items are stored at each CF) and share a common hash function to map content identifiers to CF instances.
REQUESTER ORIGIN (a) Symmetric REQUESTER ORIGIN (b) Asymmetric REQUESTER ORIGIN (c) Multicast
PRF CF AUTH CF REQUEST DATA
Figure 4.1: Hash-routing schemes
Such a hash function does not need to be collision-resistant. Instead, it is desirable for its output to be produced incurring minimal processing overhead. Consistent hashing techniques [100] may also be used in order to minimise the number of content items being remapped as a result of CF addition or removal. Caching Functions (CF) are simply in charge of serving and storing the content items mapped to them by the shared hash function. PRFs can be physically deployed in access nodes with CFs in both access and core nodes or, in another deployment scenario, PRFs and CFs can co-exist in points of presence (PoPs). The operation of the scheme is illustrated in Fig. 4.1a. When a requester issues a request for a content item, the request is forwarded to the closest PRF. The PRF identifies the CF responsible for that content by computing the hash function on the content identifier and forwards the request to that CF. If such CF has the requested content, it returns it to the user via the PRF. Otherwise, the request is forwarded towards the content origin through an egress PRF without looking up any other cache along the path. When the content item is returned by the content origin, the egress PRF forwards it to the authoritative cache that stores it and finally forwards it to the requesting user.
This solution can be easily implemented in both the Network CDN and ICN cases using common techniques. In the Network CDN case, user requests are forwarded to the closest PRF as a result of a DNS lookup, as commonly done in current CDNs [38]. Both PRFs and CFs operate as reverse HTTP proxies with persistent TCP connections running among them, which are used to forward HTTP requests among them. Differently, in the ICN case, user requests are forwarded to the closest PRF through name-based routing, which can be achieved by inserting appropriate forwarding entries in the FIBs of access ICN
routers. A PRF can then redirect a request to the authoritative CF by encapsulating the request packet with a header containing a name that identifies the authoritative cache. For example, if a request needs to be forwarded to CF A, the PRF can prepend a request header for name /_cache/_a. All ICN routers on the path are configured to route names with /_cache/_a prefix to the location of CF A. When CF A receives the request packet, it removes the prepended header and processes the encapsulated packet. This is a standard approach, commonly used in ICN request routing to steer packets through instances of network functions [10]. There is no need for encapsulation to route content packets through the authoritative CF in case of cache miss. In fact, content packets are forwarded on the reverse path taken by request packets, and hence through the authoritative cache, using information stored in the PIT of intermediate routers. It should be noted that, since content packets are not modified, this technique does not affect the verification of content signatures.
The design of this hash-routing scheme exhibits two interesting properties. First, since a content item can be cached only by the CF instance resulting from the hash calculation, a specific content item can be cached at most in one node of the network. This maximises the number of distinct items cached within the ISP network and therefore reduces inter-domain traffic and load at origins. Second, localised spikes in traffic occurring in a network region are implicitly spread across links and caching nodes by the hash computation in a way similar in principle to Valiant Load Balancing (VLB) [172]. In Sec. 4.4.2 and 4.6.3 we show that our scheme can indeed achieve very good load balancing under common operational conditions.
As explained previously, a possible deployment model would consist in the co-location of PRFs and CFs at (a subset of) the operator’s PoPs. PRFs could also be deployed separately from CFs. For example, they may be deployed in the access network (e.g., in an EnodeB in the case of an LTE network or in a DSLAM or BRAS in an xDSL fixed broadband access network). In this case, the PRFs deployed at the edge may also be equipped with a small caching space which is operated autonomously, i.e., it can cache any content. We elaborate on this aspect in Sec. 4.3.2.
We model this framework analytically in Sec. 4.4. In the following section we present extensions to this base design that support additional desirable properties and provide knobs to fine-tune the performance. It is worth noting that, by nature, these extensions add some complexity to the overall design and cannot, as such, be analytically modelled. Therefore, their performance is only evaluated numerically.