SoylentNews

frojack writes:

Named Data Networking (NDN) is a new approach to network traffic that focuses on the content, not the endpoints.

TCP/IP is focused on the endpoints, data comes from somewhere and goes to somewhere. Its built on a COMMUNICATIONS model. Multiple individual end-to-end connections, for the same web page.

NDN is all about the content, without much concern for where it comes from, or where it is going, or how it gets there. Its build on a DISTRIBRUTION model, think streaming (anything).

The Named Data Networking (NDN) project aims to develop a new Internet architecture that can capitalize on strengths — and address weaknesses — of the Internet’s current host-based, point-to-point communication architecture in order to naturally accommodate emerging patterns of communication. By naming data instead of their locations, NDN transforms data into a first-class entity. The current Internet secures the data container. NDN secures the contents, a design choice that decouples trust in data from trust in hosts, enabling several radically scalable communication mechanisms such as automatic caching to optimize bandwidth.

All this sounds daft, until you take the time to read through the Executive Summary and the FAQ, and the Motivation and Details. There are BIG names behind this project, and many of the new commercial members have deep pockets.

Communication in NDN is driven by the receiving end. You don't go to a website to find something. You just ask for it by name, without regard for where it comes from. To receive data, a consumer sends out an Interest packet, which carries the name of the desired data. (Think directory structured names: /movies/historical/Apollo-13). The router remembers the interface from which the request comes, and then forwards the Interest packet by looking up the name in its a name-based routing protocol, to all of those sources that handle movies. The router stores in a Pending Interest Table (PIT) all the Interests waiting for returning Data packets. When multiple Interests for the same data are received from downstream, only the first one is sent upstream towards the data source (flood protection). Subsequent requests are appended to the first entry.

Once the Interest Packet reaches a node that has the requested data, a Data packet is sent back, which carries both the name and the content of the data (or the first portion thereof). When a Data packet arrives, the router finds the matching PIT entry and forwards the data to all the interfaces listed in that PIT entry.

So far that sounds a lot like TCP/IP, but it is fundamentally different because each router only knows the where something came from and where it is going next. It has no idea of the end points. It might receive data from 1 to N upstreams, and it might forward it to 1 or N downstreams.

And each router is expected to cache. Live events might be sent exactly once from the source, massively cached throughout the network, and delivered to a million targets without ever transmitting more than once over any given network segment. Depending on cache size and longevity, it might still be cached only a single hop away for the next several days for late requests. Popular songs might live in router cache for months. The medium has the message. (Marshall would be proud)

Content is signed in every packet, encrypted as desired. The only place you can reliably monitor is near the origin, or near the destination, and in each case you won't know anything about the opposite end. This architecture can coexist on the current internet along with TCP/IP. The project started in 2010, but it has now reached the stage where large scale testing will start.