Information-centric networking (ICN) ticks many of the requirements boxes for 5G, driven by the proliferation of software-defined networking (SDN) and network function virtualization (NFV). But what are those issues that ICN improves over the current internet? And how does it do it?
Today’s internet has seen significant changes. With forecasts for 2020 predicting 50 billion IoT devices, the scale of connectivity is ever increasing with nearly every computing device today providing some form of connectivity option.
This will have a tremendous impact on the size of IP routing tables. This is not a problem in your typical home router on the edge of the internet. But as you move up to the core (into the so called Default Free Zone), the nodes in this part of the network literally need to store the whole internet in their routing tables. This is driving up memory costs in each IP router, as well as increasing processing complexity and power consumption. Even in SDN-enabled environments, this trend can be observed through increasing flow matching tables (growing similarly as the IP routing tables in the traditional internet), leading to an arms’ race between vendors for ever larger and costly table memory.
+ More on Network World: Demystifying the information-centric network +
In addition to pervasive connectivity, most devices have become predominantly mobile. The distributed nature of IP routing tables’ calls for so-called anchor-based mobility management solutions that preserve the view of a stationary main contact while the users' devices roams about. This leads to inefficiencies in routing packets, caused by the triangular nature of any packet exchange with a mobile device.
User requirements in a 5G world
User requirements have also changed since the early days of the internet and will continue to change in 5G, particularly with respect to latency, with new applications predicted to dominate 5G—from augmented reality to autonomous driving to industrial control applications. Latency is kept low today through a myriad of redirections, which directs our initial request to alternative replicas. Key to these redirections are skilful manipulations of the Domain Name System (DNS), which are prone to misconfigurations and long convergence times for changes in those redirections. Ever pervasive mobility and the desire to limit latency to a few hops will only increase the strain on the DNS.
Such redirections are particularly difficult when trying to accommodate policy-based decisions. Such policies are highly dependent on aspects such as the users, a country’s legislative framework, and even more dynamic conditions, such as desired network load. While solutions exist for policy-based routing between networks, application-specific policies, such as legal interception, need expensive deep packet inspection (DPI) that manipulates the flow of traffic on the fly, increasing the overall complexity of the network and therefore ultimately its costs.
+ More on Network World: 5G wireless standard getting more real +
In addition, content consumption has become increasingly personalized through the proliferation of video sites such as YouTube, BBC iPlayer and the like. As a consequence, such content is delivered via individual web-based connections to every end user, even in situations where many users are watching the same content at the same time.
The better alternative to this unicast approach is multicast. Multicast delivery is generally recognized as the most efficient delivery of the same content to many users at the same time, but today its application is limited to only live coverage of large-scale events.
How ICN helps
How does ICN help fix those issues? To shed light on this, let us outline a strawman ICN architecture that might make sense in a 5G vision. In this vision, ingress and egress points to the ICN network are clearly defined by backward-compatible gateway points that provide interworking between the legacy application/IP system and the ICN system. In the ICN publish-subscribe model, all that is required is that the network send packets along logically defined network paths.
These shortest path computations can be done via traditional mechanisms in each node. These paths are directly defined in the packet as a bit field of information. This bit field of information denotes every link in the network as a unique bit position, therefore defining a specific path as a unique bit field that combines all those bit positions of the links along the path. You might think this bit field would have to be enormous, but practically a field size of 256 is all that is really needed—assuming typical internet zoning principles are applied.
Forwarders merely need to check the presence of their output ports in the provided bit field of each packet. In this way, IP routing tables are wholly replaced by this in-packet bit field check, eliminating the need for expensive routing tables and limiting forwarding to a simple binary operation. ICN makes this efficiency improvement possible.
Of course, IP addresses as well as web names (URLs) still need to be mapped onto such path bit fields, but this mapping can now be performed in a virtual appliance that can be provided scalably in a data center at lower costs than in every router along the path. No such equivalent optimization is possible given how packets are routed in the traditional internet.
A virtual appliance approach also allows for load balancing, such as in the case of mobility where paths need to be recalculated for a direct path routing of the request, avoiding the triangular packet routing in IP. Protocol mappings in the ingress/egress points interpret HTTP requests/responses as a named data exchange. This ensures that HTTP requests are always routed to nearest replicas without the need for DNS-level redirections by announcing the availability of a new replica as a change of routing information with faster reaction times than observed for changes in today’s DNS.
Extending such simple shortest path routing in the node ultimately allows for rich policy/constraint-based decisions without the need for expensive DPI elements by exchanging the constraint algorithm used for path computation—usually optimized for shortest path—with other constraints, such as latency or application policy.
Lastly, the simple forwarding operation can deliver HTTP responses, e.g., individual chunks of a video, to many clients via the native ICN multicast capability. This is achieved by taking the individual bit fields describing a unicast path to each client and combining them through a simply binary OR into a multicast bit field.
In a nutshell, ICN is an implicit multicast system that by default delivers all the performance benefits enjoyed by such an approach, which will be significant when such a system is operated at large scale. Intuitively, this performance gain grows linearly with the number of video clients involved in the system, delivering possibly orders of magnitude improvements over current systems.
Too good to be true? Standard SDN switches already allow for the aforementioned bit field operation at virtually constant memory costs, while virtualized path computation elements are common in such SDN environments. What is needed is the ingress/egress mapping for a backward-compatible support of IP services in such an ICN vision. This is a problem that is being solved in ongoing research efforts, and we may see these results make it into our 5G world.
This article is published as part of the IDG Contributor Network. Want to Join?