Ten years ago, the world of tech was waking up to three hot new technologies – Software-Defined Networking, Network Function Virtualisation, and Information-Centric Networking. The first two are now sweeping the world, but what happened to the third?
You'd be forgiven for thinking the technology had passed to a quiet grave, but an Internet Draft published in February of this year made it clear Information-Centric Networking (ICN) still has true believers. Here, The Register's networking desk speaks to one of the four authors, Dirk Trossen of InterDigital.
The concept behind ICN today is the same as it always was: to make content directly addressable, rather than the network finding a host (like a Web server), and asking the host to find the content.
“Wouldn't it be nicer if the only thing I care about is: if I have information, someone wants it, and we can bring them together?” Trossen asked.
ICN is “not packet or host-centric, as we now do IP.”
But it happened much more slowly than, for example, software-defined networking (SDN): first, there were years of research that followed up on the first ICN paper from Google; and five years ago, Trossen said, the Internet Research Task Force launched an effort to bring different communities together for a common vision of the technology.
The new draft, “Deployment Considerations for Information-Centric Networking”, is one of the fruits of that effort, and Trossen said it's designed to help “actually get ICN out there … getting things deployed and running at scale is how you get people using them”.
In particular, the Internet Research Task Force group considering ICN found what Trossen called “vertical and horizontal” differences between how ICN implementations were operating.
Some implementations treated ICN as an overlay (the horizontal view of the world), implementing the technology site-by-site and tunnelling over the Internet between sites.
Others, he said, were completely native deployments: “people lay ICN over Layer 2 – there's no IP routing any more”.
Do we need ICN?
You could argue that if a technology hasn't taken off ten years after it was proposed, nobody needs it.
However, there are plenty of examples of organisations building networks that implement ICN concepts.
When you press “play” on a Netflix movie, you're seeking the content, not the host – and that's how the movie streamer has built its network.
Netflix doesn't send movies around the world from one giant data centre. It chooses the best out of its 233 (in 2016) points of presence and/or caches installed at internet service providers, and sends the movie from there.
This focus on content is increasingly how the Internet works, Trossen said: “You want to watch the Netflix video. You have no idea what IP address you're using.”
Netflix's approach demonstrates that “applications should be much more information-centric,” he said. “The closest we have is the semantic Web, but there are not that many semantic Web applications ... Web applications are very server-centric.”
ICN needs applications, Trossen told The Register, things that would “revolutionise” content delivery not just for the giant platforms, but for the rest of the Internet.
InterDigital's contribution to the standardisation, he said, stems from its belief that the “killer application” for ICN is the Internet itself.
The company's approach is described as an underlay in the draft – the IP layer remains, but ICN is slipped in between that and Layer 2.
Other deployment models are envisaged in the draft: the clean-slate approach; or an overlay approach.
- Clean slate – this is probably the least likely deployment model, since most applications are tied to the TCP/IP protocol stack. IP routers have to be replaced with suitable routing and forwarding elements like NFD (the named data networking forwarding daemon);
- Overlay – there are several approaches to building ICN as an overlay to IP routing. The draft notes that the overlay approach can create islands of ICN that need to tunnel over the Internet, but says it's attractive for experimentation.
- Underlay – this also results in island deployments, but instead of tunnelling to connect different islands, an underlay uses proxies or protocol conversion gateways to make the connection. “Outside of the ICN island, normal IP routing protocols apply”, the draft explained, “Within the ICN island, ICN-based routing schemes apply”.
The job of the gateway is to transfer the semantic content of messages between the islands.
Trossen said underlay proposals have been developed for core network builds (such as content delivery networks), edge networks, and in the case of the Internet of Things, what he called the “very far edge” of the network.
The biggest change an admin would notice “one the wire", so to speak, is that ICN makes the host invisible.
Trossen noted that in most networks, NAT makes the host effectively invisible to the outside world anyhow – “the host identifier in IP isn't a true IP end-to-end connection, we're all on networks with numbering like 192.n.n.n”, he pointed out.
In ICN, you have a “persistent information identifier” as the addressing element that finds content: “If you want to read sensor data somewhere, that's what you read.”
There's no need to know where the content comes from
Delivery relationships (that is, the actual network connections) are transient, and from the user's point of view, there's no need to know where the content comes from, in terms of domain names or IP addresses.
Which brings us back to the parallels with how the big platforms are built: “Which content distribution network are you going to use … is how Netflix actually works. You go to the nearest point of presence for content”, Trossen said.
“ICN pushes this transient view of relationships down into the router.”
Today, this happens further up in the protocol stack, through the DNS and the redirections that send you to the nearest node, but this is relatively slow and prone to misconfiguration, Trossen said.
And it's done at a scale that's out of reach of you or I: “ICN would do this,” he added, 'it would come as part of the machinery”.
The change is most likely to happen if its complexities can be hidden, not from users, but for network builders. As late as 2010/2011, those working with ICN were “changing the end-to-end system”, and that meant replacing the forwarding elements – the routers.
“I started my research with British Telecom, because they wanted to know how their network might change”, Trossen noted, and infrastructure outfits like Cisco and Huawei have become more active as well (as well as Trossen and his colleague Akbar Rahman, two Huawei researchers, Dirk Kutscher and Ravi Ravindran, are co-authors of the deployment draft).
Today's approach no longer needs a wholesale network rebuild. Instead, you keep the existing ecosystem of IP services and applications, so “you're running something that looks like IP” but the ICN underlay means the network “runs at least as well, or better”.
And there are benefits for operators, he added.
If, for example, there's a “big show” debut on a streaming platform, “statistically this will be watched by a number of people at the same time”.
Unless there's IP multicast in the delivery chain, if there are 10,000 viewers the stream will be sent 10,000 times.
ICN would enable a layer two multicast in the core of the network, but it returns to unicast at the edge of the network.
“If you hit the pause button, you'll move off the multicast return to unicast”, he said – but the other viewers will still be on the multicast.
He said ICN is also well-aligned with operators' move to SDN and NFV, because like those, it's “just software you load on your boxes”.
In any network that's made the shift to SDN and NFV, there are already general purpose computing devices running virtualised routing; ICN is just added as another process.
At Mobile World Congress, he said, InterDigital demonstrated ICN by launching a service from a memory stick, and “it loaded into the network in less than ten minutes.” ®