Communications of the ACM

supports local names intended for local use (for example, to refer to “the light switch in this room.”) So while all communication in NDN relies on data names, name mechanics will vary based on application context.

Request/response data exchange for multicast delivery. NDN dictates a closed-loop communication model based on packet-by-packet request and response (Figure 2). The model resembles Web semantics but at a per-packet granularity. A consumer sends an Interest packet specifying the name of data she wishes to receive. NDN routers may be able to use cached data to answer that Interest. All data that has previously passed through an NDN router can be cached in its Content Store. (IP routers also have packet buffers due to statistical multiplexing, however a buffered packet is removed from the buffer once it is forwarded to the intended destination). If an Interest cannot be answered with data from an NDN node’s Content Store, the node’s Forwarding Interest Base (FIB) defines where to send the Interest. Nodes use longest prefix matching to match data names requested in Interests to data names in the Content Store, and then forward Interests toward nodes that have registered data name prefixes, analogous to IP forwarding.

Each node also uses a Pending Interest Table (PIT) to record the interface, or face in NDN parlance, from which it received the Interest. Unlike the FIB and Content Store, the PIT is a fundamentally new entity without an analogy in IP. PIT entries track Interest packets that have been forwarded, to enable data to be returned along the path taken by the Interests. Each PIT entry records the requested data name, the incoming face(s) of the Interest(s), and the outgoing face(s) to which the Interest has been forwarded. Interest propagation creates a hop-by-hop trail of “ breadcrumbs” back to the consumer for each path the Interest takes. When the Interest packet reaches a node with matching data, the node responds with a data packet, which is forwarded back along the trail, consuming (such as, deleting) the PIT breadcrumbs along the way.

The request/response model of
NDN enables inherent multicast data
delivery, as requests for the same data
packet from multiple consumers are
security, privacy, and anonymity, while
raising new challenges regarding data
retention and forgetting. We will ad-
dress impacts for governments and
content industries caused by changing
the way networked data is identified,
handled, and routed as well as exam-
ine how these changes raise new chal-
lenges and possibilities for ensuring
neutrality across public networks. Tak-
en together, this anticipatory analysis
suggests research questions and areas
of technical focus for ongoing NDN re-
search, and helps us better understand
the potential consequences of infor-
mation-centric networking.

Fundamental Architectural
Components of NDN

A team led by Principal Investigators
(PIs) from UCLA, and involving Co-PIs,
staff, and students from U.S. institu-
tions and international collaborators,b
is designing and evaluating the NDN
architecture, which could serve as a
new foundational layer of the Internet
(see Figure 1). Today, the Internet Pro-
tocol (IP) relies on host addresses to
route packets across the network. In
contrast, NDN delivers based on data
names directly, without using host ad-
b For a full list of participants and collabora-
tors, see the Named Data Networking website:
http://named-data.net/.
dresses of either source or destination.
Rather than forwarding packets based
on the where of IP, NDN focuses on the
what: the named data itself. NDN relies
on four key architectural components
to achieve secure, efficient data deliv-
ery: names, request/response data ex-
change, data signatures, and in-network
storage, described in detail in Zhang. 31

Names: The crux of NDN. In NDN, applications name data at packet granularity. For example, /edu/ucla/cs/ CS217/video1/v2/s3 could refer to segment 3 of version 2 of “video1” published by the teacher of course CS217 in the UCLA-provided namespace.c The NDN design assumes that application developers will develop standard naming conventions, such as content versioning and segmenting, to aid interoperability and code reuse. NDN also supports hierarchical name structures to facilitate trust management and scalable routing, similar to how hierarchical IP address allocation has enabled global scaling of Internet routing. Globally unique names will require coordinated management and governance,d but the architecture also

c Our examples show hierarchical, human-read-able NDN names, though the architecture supports arbitrary byte sequences.

d Just as IP address governance is not a part of the IP architecture, global namespace governance is not an explicit part of the NDN architecture.

Figure 1. NDN (right) replaces the “thin waist” of the Internet; in its design, the common protocol is the exchange of named, signed data packets instead of IP packets (left).