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).
email WWW phone…
SMTP HTTP R TP…
TCP UDP…
ethernet PPP…
CSMA async sonet…
copper fiber radio…
Internet
Protocol
Every Internet node
Links
Applications
browser chat…
File Stream…
Security
Strategy
IP UDP TCP BCast…
copper fiber radio…
Named
Data