The Internet is more than 45 years old, and it’s starting to show its age. To be sure, it has served us wonderfully well. Its underlying technologies delivered the World Wide Web (still a young adult at around 28 years old) and our global communications network. Even as its user base has swelled to 3.4 billion, these technologies have scaled admirably.
Today, however, all of those users demand a level of performance that the Internet was never designed to deliver. Now, people spend far more time streaming Netflix movies. Oftentimes, one piece of content must be distributed to hundreds of thousands or millions of users simultaneously—and in real time. With its growth and shifts in usage, the Internet is being severely strained. That’s why you’re often stuck watching a “buffering” message when you’re trying to watch a viral video.
Increasingly, network engineers find themselves scrambling for patches to improve performance or searching for ways to squeeze slightly more capacity from this creaky infrastructure. Looking ahead to what it hopes will be a golden era for the internet, Cisco Systems expects global traffic to grow by 22 percent per year through 2020. It’s hard to imagine that happening, however, if the original framework remains in place.
As the Internet stretches to its next billion users, all of whom will want to stream videos and upload content to their heart’s content, it’s time for us to rethink the way the Internet was built. Although we don’t expect CCN to completely replace the Internet’s protocols, we are convinced that an alternative architecture can offer better performance and security in many cases.
The origins of the modern Internet were largely patterned on technologies that support the public telephony system. Just like the telephone system, the early Internet needed a set of addresses to identify users and instructions to spell out how information should be routed and protected throughout the network. Over time, many of the same methods that had been used to make telephone calls reliable and secure, and which enabled the telephone system to scale up, were reproduced in the Internet.
That strategy wasn’t perfect, though, because early telephones relied on circuit-switched networks. In such a network, users sent a stream of information over a single connection established at the start of a call. The Internet is a packet-switched network, which means it separates the many bits that make up a piece of content into smaller pieces (packets) of data. On the Internet, packets can be sent over different paths on the network and are reassembled into the original piece of content at its destination.
Each piece of online content is stored on a user’s server (known as a host), often that of the content’s creator. To retrieve the content, other users must navigate to that server with their requests. Then the packets must be sent back to the requestor.
Along the way, routers must constantly juggle these packets. To help routers direct packets, the Internet’s founders came up with a clever system of assigning a unique IP address to every computer or server. The IP address is similar to a phone number. Routers move information along by reading bits on an incoming content packet that indicate its intended destination, looking up the recipient’s IP address in routing tables, and forwarding the packet in the recipient’s direction.
Whenever an Internet user types in a URL or email address, a Domain Name System translates those characters into the matching IP address. The DNS system is basically a phone book for the Internet. To enable packets to travel between hosts once a user has the correct IP address, the Internet’s founders also built a shared network architecture. It has four basic layers, each with a distinct function. The first layer is the physical link over which information is sent, such as copper wires, fiber-optic cables, cellular towers, and home routers. The second and third layers are governed by common rules known as protocols that define how information is named and routed. Here, the main protocols are the Internet Protocol, which manages addresses for packets and hosts, and the Transmission Control Protocol, which describes how information is transferred. The upper layer has to do with specific applications, with more protocols that translate information for display within different Internet browsers and other programs.
A new way to route
These basic protocols have supported the Internet for more than four decades of growth. But they do have some shortcomings. For example, they don’t always organize content in the most efficient way. Nor do they incorporate security prescriptions such as encryption by default. While these functions can be accomplished by adding more protocols, doing so can increase latency and further burden the network with additional traffic.
With CCN, we’ve developed a new architecture based on how information is organized within the network, rather than the IP addresses of hosts. That’s why it’s called content-centric networking—it’s based on how content is named and stored, instead of where it is located. We’ve designed new protocols that can find and retrieve content from wherever it happens to be in the network at a given time and also perform many additional tasks that could make networks faster, more resilient, and more secure.
To understand how all of this works, we’ll walk you through how a CCN network finds and retrieves a content packet for a user who is interested in reading an article or watching a video on the Web.
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.
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 its 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 build its own content store, a node can grab any packet that travels through it, keep a copy of it, and add that copy to its store to fill future requests. This ability means that content isn’t stuck on the server where it was originally created. Content can move throughout the network and be stored where it’s needed most, which could potentially enable faster delivery.
Currently, large companies such as Netflix pay a lot of money to store extra copies of their most popular content on content delivery networks built from regional data centers. With CCN, the entire Internet could act like one big content delivery network. Any server with available memory—not just the servers that Netflix manages—could store the first 3 seconds of a popular Netflix film. Later, we’ll explain how special security precautions built into the most basic layer of CCN make it possible to securely copy and store content in this way.
Power to the node
Servers and routers can find content packets located anywhere on a CCN network by consulting two specialized tables: the pending interest table and the forwarding information base. The FIB lists where content is currently stored, while the PIT traces how past requests were forwarded. Nodes can also pluck content packets they’ve cached in their own content store (CS) to satisfy requests.
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.
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.