This solution is a merge of the two previously presented, in order to improve its efficiency and reduce the load. It uses a modified version of the forward-on-content principle. The pool of identifiers is divided into several smaller pools, every cache having its dedicated pool. These pools can be subdivided to separate the content types. For example, the n first bytes indicate the cache, the y next bytes indicate the type of the content and the remaining bytes identify the content. Thus, the identifier is unique per cache and per content type. For instance, if we use duplication, on different caches, the same content would be identified differently. [2]
In this solution, the rules can be aggregated per cache. Hence, there would be static rules to forward the packets to each cache, on all the switches, using masks to match only the bytes identifying the cache of the content identifier. A single rule is needed to match all the packets for a cache, instead of one rule per object as proposed in the SDN-based solution.
Figure 24 presents the process of the mobile’s request. When retrieving a new object, a proxy would be given the identifier of the content that includes the cache where it will be located. The proxy would thus be able to fetch it without installing new rules since the rules matching the content identifier on the bytes identifying the cache are already installed (static rules).
Figure 25 presents the relocation process for this solution. The relocation could be performed in two ways. The first one would consist in changing the mappings in the cache controller, without pushing it to the proxies, and setting rules with higher priority in the switches to redirect this content identifier to the new cache location, overriding the rules matching with masks for these identifiers. The rules would exist only for the remaining time the mappings are cached in the proxies. Or the relocation could be performed by pushing the update to all the proxies needing it. The decision on which method should be used shall be based on the number of operations required and the load it would induce on the different services, so on the efficiency of the operations. It could also be based on some parameters given by the users in order to promote a method over the other [2].
Figure 24: Process of the request for the hybrid solution [2]
Advantages This solution presents some advantages from both previous solutions :
• This system reduces the time needed to perform the relocation operation by choosing the most efficient method.
• It reduces the overall load on the whole system by increasing the efficiency. • The parameters could be tunable in order to promote one technique over the
other. This has been designed to best fit the reality.
But it also presents some drawbacks, either from the previous versions or specific to this new version. The first drawback is that more computation and time are needed to determine what would be the most efficient way to relocate. This should be estimated more precisely in some further work, depending on the relocation triggering algorithm. Moreover, some of the drawbacks of the first version apply here, such as the problem of the non-SDN switches islands. They could be integrated using the proposed technique, changing the mac address to the next-SDN-hop or tunneling the content.
Rules needed In this solution, several rules would be needed :
• A first static rule is needed per base station to redirect the http traffic to the proxy.
• Static rules, one per cache per switch to forward to the cache on each switch using masks to match the identifiers.
• One rule per redirection per switch where it is needed, with a timeout slightly longer than the time the cache controller reply is cached.
Table 26 presents the rules used for this solution.
Caching system requirements As runtime operations, the SDN controller will have to set redirection rules in some of the relocation cases. The system will have more requirements :
• Full knowledge about the whole network • Full knowledge of the content of each cache
• Stateful knowledge about the rules set for the path (memory requirements) • Fast computation of the best location and shortest path (computation require-
ments), always needed to compare the cost of the operations
• Full knowledge of the requests processed for a defined time for pushing the updates
• Unspecified number of SDN switches, at least as many as the proxy-based solution.
Switch Match Action Aim First after the UE TCP, port 80 Set dst IP and
Mac to proxy, out- put, learn [match (TCP, dst IP = src IP, dst port = src port, input port = output), action set src IP, set src Mac]
Redirect to the proxy, learn a rule to set back the original IP based on the src IP and port
All between proxy and cache
Dst IP (with mask), TCP, port X
Output Forward to the
cache Last before the
cache
Dst IP, TCP, port X
Set dst IP and Mac to cache, set port 80, out- put, learn [match (TCP, dst IP = src IP, dst port = src port, input port = output), action set src IP, set src Mac]
Forward to the cache, learn a rule to set back the original src IP and Mac address of the reply
First after the cache
Dst Mac, IP and port, input port
Set src IP, Mac and port
Set the content identifier as source IP (learned rule) Last before the
UE
Dst Mac, IP and port, input port
Set src IP, Mac and port
Set the webserver IP as src IP (learned rule)
Any Dst IP, TCP, port
X
output Redirection rule
(higher priority) Figure 26: rules on the SDN switches for the hybrid solution