Content-Centric Networking

In today’s Internet, there is only one kind of data packet—one that carries both content and requests for content between users. But in a CCN network, there are two types: content packets and interest packets. They work together to bring information to users. Content packets are most like traditional data packets. The bits in a content packet may specify part of an ad on a Web page, a piece of a photo in an article, or the first few seconds of a video. Interest packets, on the other hand, are like golden retrievers that a user sends out onto the network to find a specific content packet and bring it back.

When you visit a Web page, your computer needs to fetch about 100 pieces of content on average. A piece of content could be a block of text, a photo, or a headline. With CCN, when you navigate to a website or click on a link, you automatically send out interest packets to specify the content you would like to retrieve. Typing in a single URL, or Web address, can trigger a user’s browser to automatically send out hundreds of interest packets to search for the individual components that make up that page.

Both interest and content packets have labels, each of which is a series of bits that indicate which type of packet it is, the time it was generated, and other information. The label on a content packet also includes a name that designates what bits of content it holds, while the label on an interest packet indicates which content it wishes to find. When a user clicks on a link, for example, and generates a flurry of interest packets, the network searches for content packets with matching names to satisfy that request.

The name on a packet’s label is called a uniform resource identifier (URI), and it has three main parts. The first part is a prefix that routers use to look up the general destination for a piece of content, and the second part describes the specific content the packet holds or wishes to find. The third part lists any additional information, such as when the content was created or in what order it should appear in a series.

Suppose a Web surfer’s browser is using CCN to navigate to this article on IEEE ­Spectrum’s website. The network must find and deliver all the content packets that make up the complete article. To make that process easier, URIs use a hierarchical naming system to indicate which packets are needed for the page, and in what order. For example, one content packet might be named spectrum.ieee/2017/April/ver=2/chunk=9:540. In this example, spectrum.ieee is the routable prefix for the second version of the article, and the specific packet in question is the ninth packet of 540 that make up the complete article.

Once a CCN user has clicked that link or typed it in as a Web address, the user’s machine dispatches an interest packet into the network in search of that content, along with other interest packets to search for packets 10 and 11. As the interest packet for number 9 travels along, each router or server it encounters must evaluate that interest packet and determine whether it holds the content packet that can satisfy its request. If not, that node must figure out where in the network to forward the interest packet next.

To do all of this, every node relies on a system known as a CCN forwarder. The forwarder operates on components that are similar to what you’d find in a traditional router. A CCN forwarder requires a processor, memory, and storage to manage requests. The forwarder also runs a common software program called a forwarding engine. The forwarding engine decides where to store content, how to balance loads when traffic is heavy, and which route between two hosts is best.

The forwarding engine in a CCN network has three major components: the content store, the pending interest table, and the forwarding information base. Broadly speaking, CCN works like this: A node’s forwarding engine receives interest packets and then checks to see if they are in its content store. If not, the engine next consults the pending interest table and, as a last resort, searches its forwarding information base. While it’s routing information, the engine also uses algorithms to decide which content to store, or cache, for the future, and how best to deliver content to users.

To understand how that system improves on our existing Internet protocols, consider what happens when a new interest packet arrives at a node. The forwarding engine first looks for the content in the content store, which is a database that can hold thousands of content packets in its memory for quick and easy access, like the cache memory in a conventional router. But CCN has a key difference. Unlike the traditional Internet protocols, which permit content to be stored only with the original host or on a limited number of dedicated servers, CCN permits any node to copy and store any content anywhere in the network.

To return to our example, if the forwarder finds the content it’s looking for in the node’s content store, the system sends that content packet back to the user through the same “face,” or gateway, by which the interest packet entered the system. However, when an interest packet arrives, that node might not hold a copy of the needed content in its content store. So for its next step, the forwarding engine consults the pending interest table, a logbook that keeps a running tally of all the interest packets that have recently traveled through the node and what content they were seeking. It also notes the gateway through which each interest packet arrived and the gateway it used to forward that content along.

By checking the pending interest table (PIT) whenever a new interest packet arrives, the forwarding engine can see whether it has recently received any other interest packets for the same—or similar—content. If so, it can choose to forward the new interest packet along the exact same route. Or it can wait for that content to travel back on its return trip, make a copy, and then send it to all users who expressed interest in it.

The idea here is that these PIT records create a trail of bread crumbs for each interest packet, tracing its route through the network from node to node until it finds the content it’s seeking. This is very different from conventional networks, where routers immediately “forget” information they’ve forwarded. Then, that forwarder consults the PIT at each node to follow the reverse path back to the original requester.

Suppose, though, that an interest packet arrives at a node and the forwarding engine can’t find a copy of the requested content in its content store, nor any entry for it in the pending interest table. At this point, the node turns to the forwarding information base—its last resort when trying to satisfy a new request.

Ideally, the forwarding information base (FIB) is an index of all the URI prefixes, or routable destinations, in the entire network. When an interest packet arrives, the forwarding engine checks this index to find the requested content’s general whereabouts. Then it sends the interest packet through whatever gateway will move it closer to that location and adds a new entry to the pending interest table for future reference. In reality, the FIB for the entire Internet would be too large to store at every node, so just like today’s routing tables, it is distributed throughout the network.

In a traditional network, routers perform a similar search to find the IP address of the server that holds the bits of information a user wishes to retrieve and figure out which gateway to send the request through. The difference here is that with CCN, the forwarding information base finds the current location of the information itself on the network rather than the address of the server where it’s stored.

By focusing on the location of content rather than tracking down the address of its original host, a CCN network can be more nimble and responsive than today’s networks. In fact, our studies indicate that the CCN model will outperform [PDF] traditional IP-based networks in three key aspects: reliability, scalability, and security.

CCN improves reliability by allowing any content to be stored anywhere in the network. This feature is particularly useful in wireless networks at points where bit-error rates tend to be high, such as when data is transmitted from a smartphone to a cell tower, or broadcast from a Wi-Fi access point. Current Internet protocols leave error recovery to higher levels of the protocol stack. By keeping a copy of a content packet for a short while after sending it along, a CCN node reduces the upstream traffic for packets that need to be retransmitted. If a packet fails to transmit to the next node, the previous node does not need to request it again from the original host because it has its own copy on hand to retransmit.

The pending interest table can also make it easier for networks to scale. By grouping similar interest packets together, it can reduce the bandwidth needed to satisfy each request. Instead of sending a new request back to the original host for each identical interest packet that arrives, a node could satisfy all those requests for interest packets with identical copies of the content it has stored locally. If the record shows that there has been a lot of demand for a viral cat video, the algorithms within that node may prompt it to keep an extra copy of all those packets in its content store to more quickly satisfy future requests.

Boosting reliability and making it easier to scale networks are two important benefits. But to us, the most important advantage of CCN is the extra securityit offers. In traditional networks, most security mechanisms focus on protecting routes over which information travels (similar to the strategies used in early ­circuit-switched telephone networks). In contrast, CCN protects individual packets of information, no matter where they flow.

Currently, two users can establish a secure connection through established Internet protocols. The two most common of these are HTTPS and Transport Layer Security. With HTTPS, a user’s system examines a digital certificate issued by a third party, such as Symantec Corp., to verify that the other user is who she claims to be. Through TLS, users negotiate a set of cryptographic keys and encryption algorithms at the start of each session that they both use to transfer information securely to each other.

With CCN, every content packet is encrypted by default, because each content packet also comes with a digital signature to link it back to its original creator. Users can specify in their interest packets which creator they would like to retrieve content from (for example, Netflix). Once they find a content packet with that creator’s matching signature, they can check that signature against a record maintained by a third party to verify that it is the correct signature for that piece of content.

With this system in place, creators can allow other users to copy and store their content, because packets will always remain encrypted and verifiable. As long as users can verify the signature, they know that the content packet originated with the creator and that users can securely access the content—a motion picture, say—from anywhere it happens to be.

This security feature brings another bit of good news: Distributed denial-of-service attacks—in which hackers send a large volume of requests to a website or server in order to crash it—are more difficult to execute in CCN. Unusual traffic patterns are easier to discern in a CCN network and can be shut down quickly. On the other hand, clever attackers may just try to figure out a way to flood the network with interest packets instead. This security challenge would have to be solved before CCN could be widely adopted.

Another significant challenge [PDF] is figuring out how to integrate CCN’s protocols into routers running at the speeds used on current networks. Analysts are especially concerned that routers in a CCN system would have to store rather large FIB and PIT tables to track the many moving content objects on the network, which will present major computational and memory-related challenges. However, researchers are now working on this problem at Cisco, Huawei, PARC, and Washington University in St. Louis, which have all demonstrated prototype routers supporting various elements of the CCN protocols.

 

Leave a Reply

Your email address will not be published. Required fields are marked *