named data networking next phase (ndn-np) project may 2015 ...€¦ · fia-np: collaborative...
TRANSCRIPT
Named Data Networking Next Phase (NDN-NP) Project
May 2015 - April 2016 Annual Report
Principal Investigators
Van Jacobson, Jeffrey Burke, and Lixia ZhangUniversity of California, Los Angeles
Tarek AbdelzaherUniversity of Illinois at Urbana-Champaign
Beichuan ZhangUniversity of Arizona
kc claffyUniversity of California, San Diego
Patrick CrowleyWashington University
J. Alex HaldermanUniversity of Michigan
Christos PapadopoulosColorado State University
Lan WangUniversity of Memphis
Contents
Executive Summary 1
1 Introduction 2
2 Network Environments / Applications 42.1 Enterprise Building Automation and Management . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Progress towards milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Open mHealth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 NDNFit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Progress towards milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Mobile multimedia: ndnrtc (NDN real-time conferencing tool) . . . . . . . . . . . . . . . . . . 112.4 Scientific Data Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Climate modeling applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.2 NDN in High Energy Particle Physics (HEP) . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Information Maximization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.1 ndn-cxx: NDN C++ library with eXperimental eXtensions . . . . . . . . . . . . . . . 142.6.2 NDN-CCL: Common Client Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Open Challenges Raised by Network Environment Development . . . . . . . . . . . . . . . . . 16
3 Security 193.1 Name-based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 NDN DeLorean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Content Poisoning Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Plan For Next Year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Distributed Dataset Synchronization 254.1 Chronosync and iSync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Round-Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3 PartialSync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Summary and Plan for Next Year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Networking 305.1 NDN Forwarding Daemon (NFD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.1 NDN Link Protocol v2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.1.2 NFD Management Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.1.3 Automatic Prefix Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.1.4 Supporting Mobility and FIB Scaling with LINK . . . . . . . . . . . . . . . . . . . . . 325.1.5 Permanent Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.1.6 NFD on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2.1 NLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2.2 Hyperbolic Routing with Adaptive Forwarding Strategy . . . . . . . . . . . . . . . . . 35
i
5.3 Scalable Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 NDN/OSCARS Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.5 Plans for the Next Year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6 Evaluation 406.1 NDN Testbed: Deployment, Management, Expansion . . . . . . . . . . . . . . . . . . . . . . . 40
6.1.1 Lessons Learned from Testbed Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.2 Mini-NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7 Impact: Education 427.1 Education Efforts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1.1 UCLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.1.2 University of Memphis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.1.3 Colorado State University . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.1.4 Washington University in St. Louis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 NDN Tutorial at ICN 2015 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.3 NDN Weekly Seminars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8 Impact: Expansion of NDN Community 468.1 The Second NDN Community meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.2 Expansion of the NDN Consortium and Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 468.3 The 2nd ACM Information Centric Networking Conference . . . . . . . . . . . . . . . . . . . 478.4 NDN-Related Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9 NDN Presentations 48
10 Publications 51
ii
FIA-NP: Collaborative Research: Named Data Networking Next Phase (NDN-NP) 2016Report
Executive Summary
The heart of the current Internet architecture is a simple, universal network layer (IP) which implementsall the functionality necessary for global interconnectivity. This thin waist was the key enabler of theInternet’s explosive growth, but its design choice of naming communication endpoints is also the cause ofmany of today’s persistently unsolved problems. NDN retains the Internet’s hourglass architecture butevolves the thin waist to enable the creation of completely general distribution networks. The core elementof this evolution is removing the restriction that packets can only name communication endpoints. As faras the network is concerned, the name in an NDN packet can name anything – an endpoint, a data chunkin a movie or a book, a service, or a command to turn on some lights. This conceptually simple changeallows NDN networks to use almost all of the Internet’s well-tested engineering properties to solve not onlycommunication problems but also digital distribution and control problems.
Our first several years of NDN design and development efforts tackled the challenge of turning thisvision into an architectural framework capable of solving real problems. Our application-driven architecturedevelopment efforts force us to fill in details, as well as verify and shape the architecture. We translated ourvision into a simple and elegant packet format design, a modular and extensible NDN forwarding daemon,and a set of supporting libraries. This next phase of the project has focused on deploying and evaluatingthe NDN architecture in four environments: building automation management systems, mobile health,multimedia real-time conferencing tools, and scientific data applications. The implementation and testing ofpilot applications in these network environments further demonstrated our research progress in namespacedesign, trust management, and encryption-based access control. Highlights from this year include:
• Continued evolution the NDN Forwarding Daemon (NFD), to support application-driven experimen-tation with new NDN protocol features.
• Development of an Android version of NFD to promote NDN experimentation on mobile platforms.
• Implementation of a new transport protocol (InfoMax) that can intelligently filter streams of informa-tion in order to reduce transmitted data volume, while minimizing loss of information.
• A growing portfolio of supporting software libraries, including new APIs, transport mechanisms (Sync,information maximization), and security functionality, that leverage inherent capabilities of NDN, e.g.,schematized trust, name-based access control.
• Demonstration of extremely scalable forwarding implementation using a billion synthetic names.
• Implementation and evaluation of hyperbolic routing performance to understand its feasibility in sup-porting NDN’s interdomain routing.
• Multi-faceted evaluation of the architecture, from instrumentation of applications on the testbed, touses of ndnSIM and the Mini-NDN emulator environment.
• Continued uses of NDN in the four courses taught by principal investigators.
• The second annual NDN Community meeting hosted by the NDN Consortium to promote a vibrantopen source ecosystem of research and experimentation around NDN.
We have made tremendous progress in the last five years, and a larger community of information-centricnetworking research has evolved in parallel. We also helped NIST prepare an NDN workshop hosted byNIST at end of May 2016. Our progress revealed the importance of demonstrating NDN capabilities in IoTand big data environments, and highlighted the need for accessible software platform support and emulationcapabilities to facilitate R&D on both the NDN architecture and applications that leverage it. We havereceived a year of supplement funding to complete four tasks: 1) completing and disseminating native NDNapplications and associated design patterns, 2) demonstrating NDN scalability; 3) documenting and releasingreference implementations, and 4) documenting NDN design decisions and lessons learned.
1
Chapter 1
Introduction
This report summarizes our accomplishments during the second year of the “Named Data Networking NextPhase (NDN-NP)” project. This phase of the project focuses on deploying and evaluating the NDN architec-ture in four environments: building automation management systems, mobile health, multimedia real-timeconferencing tools, and scientific data applications.
The first two environments represent critical areas in the design space for health IT and cyberphysical/IoTsystems, respectively. For the building automation pilot application, we are in the process of demonstratingtwo uses on the UCLA campus: real-time monitoring from a web browser via basic Interest-Data exchange,and general SQL query support against historical data for report generation. For the mHealth applica-tion, we completed an initial end-to-end design and implementation of the NDNFit application, including arevised namespace design that supports named-based access control. We also developed an identity man-agement Android application based on schematized trust, designed and implemented data transportationprotocols, designed and implemented NFN integration mechanism, and implemented name-based access con-trol (NAC). Mobility support in this application has driven several practical elements of the architecture:autoconfiguration, prefix registration, identity management, and encapsulation / LINK support.
Our real-time conferencing application has enjoyed the most real-world testing from the NDN collab-orators at various campuses, as we forced ourselves to use it for some of our regular NDN seminars andproject meetings to thoroughly stress-test it (and us!). The feedback was invaluable, revealing the need forapplications to fully exploit, and verify, network-layer features in supporting the detection of latest dataavailable, adaptive consumer retrieval, and performance optimizations.
The scientific data management environment emerged during the original FIA project as an ideal use case,and came with enthusiastic collaborators who enabled us to show immediate practical use of our researchideas to make their day jobs easier. A complementary project at one of the NDN campuses (UIUC) finalizeda new transport protocol that intelligently filters streams of information in order to reduce transmitted datavolume, while minimizing loss of information.
This application-driven approach compelled several concrete and fundamental architecture advances,but also required the development and extension of a set of software libraries that not only instantiatethe evolving core of the NDN network architecture, but also support the experimentation that informs itsevolution. To allow broader experimentation with NDN technology, and in particular experimentation inreal mobile environments, we made a prototype port of our reference forwarding daemon implementationon Android platform (NFD-Android). We also implemented two different approaches to routing in NDNnetworks (link-state and hyperbolic routing with adaptive forwarding) to support comparative evaluation ofthese approaches in various scenarios.
The software development dimension of this project exceeded even our high expectations – but in theprocess we created a lasting and powerful artifact of the FIA program: a patent-free and open source softwarecode base to encourage further architecture research experimentation and collaboration with around theworld. We made one major and several minor releases of our core NDN forwarder (NFD) and supportinglibraries, and support living documentation as well as a mailing list of over 100 people.
2
Some of the most fundamental architectural advances in the last year have related to security; specifically,codifying the previous year’s invention of a security-conscious approach to namespace design that we callschematized trust, application of this approach to name-based access control, and development of mechanismsto support the authenticity of long-lived data, i.e., packets whose digital signature may have expired at thetime of data consumption.
We continued progress on data synchronization as a significant NDN communication primitive. In NDN,data synchronization between multiple nodes supports basic services, such as public key distribution, filesharing, and route distribution. In addition to ChronoSync (which uses log-based representations of informa-tion) and iSync (which uses a two-level invertible Bloom filter structure to speed up dataset synchronization),this year we developed PartialSync, which enables individual consumers to synchronize with selected part ofthe dataset namespace, a popular usage pattern in publish-subscribe systems.
In the area of scalable forwarding, we completed our software implementation and evaluation of a scalableFIB longest name prefix lookup design based on the binary search of hash tables. We demonstrated 10 Gbpsforwarding throughput with one billion synthetic longest name prefix matching rules, each containing up toseven name components. To the best of our knowledge, this is the largest dataset that has been studied forlongest name prefix lookup.
We continued our commitment to multi-faceted evaluation of the architecture, from deployment andinstrumentation of applications on the expanding NDN testbed, use of applications by team members, touses of ndnSIM and the Mini-NDN emulator environment. We also documented four campuses use of NDNin the classroom and curriculum, and the growing NDN consortium to facilitate private and public sectorengagement with the NDN project. We ended the second year of NDN-NP project with ten submissions toICN 2016 conference, which report on various results of the project.
We have made tremendous progress in the last five years, but unexpected collaborations have revealedthe value of further demonstrating NDN capabilities in IoT and big data environments, and highlightedneeds for accessible software platform support and emulation capabilities to facilitate R&D on both theNDN architecture and applications that leverage it. We are honored to have recently received a year ofNSF supplement funding to complete four tasks: 1) completing and disseminating native NDN applicationsand associated design patterns, 2) demonstrating NDN scalability; 3) documenting and releasing referenceimplementations, and 4) documenting NDN design decisions and lessons learned. We also hope to use thiscoming year to further organize and inspire the growing research community to develop new applicationsaround NDN. We plan to offer a whole-day tutorial on NDN application development at the ICN conference,focused on enabling others to build on our success with application-driven architectural research.
3
Chapter 2
Network Environments / Applications
ContributorsPIs . . . . . . . . . . . . . . . Jeffrey Burke, Van Jacobson & Lixia Zhang (UCLA), Tarek Abdelzaher (UIUC), Christos
Papadopoulos (Colorado State)
Grad Students . . Dustin O’Hara, Ilya Moiseenko, Wentao Shang, Yingdi Yu, Haitao Zhang (UCLA);
Jongdeog Lee, Shiguang Wang (UIUC)
Undergrads . . . . . . Akash Kapoor, Yang Sheng (UIUC)
Staff . . . . . . . . . . . . . Adeola Bannis, Jiawen Chen, Peter Gusev, Alex Horn, Jeff Thompson, Zhehao Wang,
(UCLA); Researcher: Alex Afanasyev (UCLA)
As part of the NDN “Next Phase” research, the NDN project team proposed two network environments,Enterprise Building Automation & Management and Open mHealth, and one application cluster,Mobile Multimedia, to drive our research, verify the architecture design, and ground evaluation of the nextphase of our project. The two environments represent critical areas in the design space for next-generationHealth IT and Cyberphysical Systems, respectively. They also extend work started in the previous NDN FIAproject on participatory sensing and instrumented environments to focus on specific application ecosystemswhere we believe NDN can address fundamental challenges that are unmet by IP.
2.1 Enterprise Building Automation and Management
For our purposes, Enterprise Building Automation and Management covers the intersection of three criticalsub-areas: industrial control systems (ICS), including supervisory control and data acquisition (SCADA) andso-called smart grid [5], enterprise networking, and the Internet of Things (IOT) movement [2]. Our pilotapplication for this network environment is an initial NDN-based building monitoring system (NDN-BMS)deployment at UCLA. We are building an NDN-based collection, storage, and query system for real UCLAFacilities Management data collected from UCLA’s Siemens building monitoring system. (As of April 2016,we have bridged a few hundred live data points from UCLA’s campus monitoring to the NDN testbed. Weare targeting several thousand points at up to 1Hz sample rate per point by the end of the project.) Weare initially focusing on read-only access to sensing data. The 800 or so points of monitoring that we willhave access to in 2016 generates 24M rows per year and cover a few buildings and a few data types. Theyinclude data from electrical, chilled water, and heating-ventilation-air-conditioning (HVAC) systems, as wellas other sensors.
Our high level objectives for the pilot application are to support two dominant uses for this data on theUCLA campus: real-time monitoring from a web browser via basic Interest-Data exchange, and general SQLquery support against historical data for report generation. This section summarizes our progress on storageand query support of building management data.
4
Data namespace
User namespace
/ndn/app/bms
UCLA/PublicHealth/A203/xfmr-6.dmd.inst
data/ElectricityDemand/aggregation/avg
20150825T000000/20150826T000000
Application prefix
Hierarchical location
Data type
Timestamp
/ndn/app/bms/user “User” prefix
[email protected] User identity
Access control namespace
/ndn/app/bms/read Access control prefix
ucla/Melnitz/data/electricity Group name
Figure 2.1: Example BMS data name
Mini-BMS [13] extends the NDN building automation management system work. This year’s workincorporates data aggregation, schematized trust [14], name-based access control [15], and a visualizationunit. Mini-BMS uses Mini-NDN to emulate nodes in a larger BMS network driven by real data from theUCLA campus. Each node keeps outstanding Interests for the data produced by its child nodes to gatherthe data for aggregation in a fixed time window. The system uses a hierarchical trust schema in which thecertificate of a child node is signed by its parent, and a predetermined root of trust installed on each node.Figure 2.1 gives an example of the naming conventions for BMS data, and Figure 2.2 illustrates the structureof the deployed system, which makes historical raw and aggregated BMS data from UCLA campus availableon the NDN testbed.
2.1.1 Progress towards milestones
We summarize progress toward our proposed milestones for this specific environment:
• Review limitations in current IP-based architecture, for Facilities Management needs. (Y1) In progress,continued in supplement work. Some of the insights from this process are captured in [9].
• Design NDN namespace, repository, trust and communication model for use cases, such as energymanagement, new building commissioning, feedback control. (Y1; updated in Y2) Schematized trustwas designed and implemented in Year 2, along with an initial design for name-based access control.Because our EBAMS data starts in hierarchical namespaces on the application side, these approacheswork well, though present some limitations, also described most recently in [9].
• Implement low-level NDN applications, such as energy management data gathering. (Y1) In progress,to be continued in supplement work. Our expectation in the supplment period is to bridge IoTconsiderations inspiring for new types of EBAMS with the infrastructure-based systems that we havestarted with.
• Preliminary embedded platform support. (Y2) Completed, described in the previous report. We con-tinue to explore support for embedded platform through hackathons and other efforts outside of theNP funding, which has provided valuable insight into how the NDN approach can be adapted for
5
Aleph
UCLA
Dentistry Franz_Hall
A3-063 83-055 C417 A173
sensor1 sensor2 sensor1 sensor2 sensor1 sensor2 sensor1 sensor2
BMS gateway node …
Testbed
Browser consumer node
Testbed nodes
Mini-ndn nodes
Visualization nodes
BMS gateway nodes
Figure 2.2: BMS deployment structure
constrained and embedded platforms.
• Integrate UCLA building data (10-20 buildings) into NDN testbed, (Y2) Done, with a paper forthcomingduring the supplement period on the Mini-BMS project described above.
• Implement high-level NDN application for enterprise building monitoring, applying distributed 3D vi-sualization work done in the first FIA project. (Y2) UCLA will complete visualization work duringthe supplement period, with an initial namespace visualizer in September 2016.
2.2 Open mHealth
Figure 2.3: The Open mHealth architecture uses adata-centric hourglass model, where the interoperabil-ity layer (“thin waist”) is based on standardized dataexchange. [3]
Mobile health (mHealth) has emerged as an impor-tant market and a key area of Health IT, a nationalpriority. The Open mHealth project [3] led by Deb-orah Estrin (Cornell) and Ida Sim (UC San Fran-cisco) proposes a thin waist of open data interchangestandards (Figure 2.3) to enable an ecosystem ofsensing, storage, analysis, and user interface com-ponents to support medical discovery and evidence-based care. Specifically, the Open mHealth archi-tecture includes standardized personal data vaultsand health specific data exchange as the architec-ture’s narrow waist, which provides health-specificsyntactic and semantic data standards, patient iden-tity standards, core data processing functions suchas feature extraction and analytics and data storesthat allow for selective, patient-controlled sharing.
The focus on data exchange as the backbone ofthe application ecosystem makes Open mHealth anexcellent network environment to both drive andevaluate NDN. The NDN architecture embeds dataexchange as its narrow waist, which provides a stan-dard way to manage identity and trust relationship,provides provenance via the signature, and securesdata at generation, with data owners directly con-trolling data sharing.
6
Figure 2.4: data flow for a single user of NDNfit
Our high level goal is to build a pilot NDN-basedfitness application and system, which is compatiblewith Open mHealth paradigm, to capture, processand visualize users’ time-location data. Figure 2.4shows the data flow for a single user who uses NDNFit to retrieve: 1) fitness/activity metrics, 2) walking orrunning path visualizations, and 3) location-based content during exercise - all through the same ecosystem,but from different content providers.
This year, eight sites are collaborating on design and development of this application:
• UCLA REMAP - application design; library support; web-based visualization; values in design.
• UCLA IRL - architecture implications; repository; library and forwarder support; trust and security
• University of Arizona - forwarder support.
• University of Michigan - trust and security.
• University of Basel - data flow processing using NFN (Named Function Networking).
• Anyang - Ohmage capture application port.
• WUSTL - testbed support.
• UCSD - project management support.
2.2.1 NDNFit
This year, we completed an initial end-to-end design and implementation for the Open mHealth networkenvironment, moving forward with the initial design developed last year. We revised the namespace designbased on peer review and to support name-based access control, implemented the mobile capture application,designed and implemented an identity management Android application based on schematized trust, designedand implemented data transportation protocols, designed and implemented NFN integration mechanism, andimplemented name-based access control (NAC) [15]. We also started to revise the previous autoconfigurationsupport mechanism required to deploy this application in the wild. This work is implemented in a demosystem running on the testbed supporting a capture application, a data storage unit (DSU) and two dataprocessing units (DPUs): one NFN DPU and one native NDN DPU.
Namespace
Figure 2.5 shows the second version of the proposed data namespace. Over the last year, we updatedthis namespace based on the requirements of name-based access control. The user publishes encrypted
7
/org/openmhealth
<user-id> <service-id>(DPU, DVU)
key
<version>
key
<version>
<group-id>
key
<version>
<member-id>(user-id of the members)
key
<version>
devices
<device-id>
key
<version>
Dataread
fitness
Physical_activity
D-KEY E-KEYfitness
Physical_activity D-KEY E-KEY
D-KEY E-KEY
<start_timestamp_hour> <start_timestamp_hour>
<end_timestamp_hour> <end_timestamp_hour>
for
<consumer-id>
ENCRYPTED PRIVATE KEY
PUBLIC KEYDATA OBJECT
time_location bout
<timestamp> catalog C-KEY
<segment>(opt.)
DATA OBJECT
<timestamp>
<version>
DATA OBJECT
<start_timestamp_hour>
<end_timestamp_hour>
<E-KEY name>
SYM KEY ENCRYPTED BY
E-KEY
catalog
<timestamp>
<version>
DATA OBJECT
<timestamp>
statistic type
<begin> <end>
source
running walkiing stitingDATA OBJECT
Calories expended, etc.
C-KEY
<start_timestamp_hour>
<end_timestamp_hour>
<E-KEY name>
SYM KEY ENCRYPTED BY
E-KEY
bout
D-KEY E-KEY
Figure 2.5: NDNFit Namespace, version 2.
health data under data branch and publish keys under corresponding entries in the read branch. The firstimplementation of NDNFit captures and processes time-location data. Data is fetched by time range, anddata names include the timestamp as the last component.
NDNFit Android Application
Anyang University and UCLA IRL have built NDNFit, an Android application (interface depicted in Figure2.6), that captures time-location data, produces Data packets and temporarily stores these Data locally. Ituses the NDNFit application protocol (Section 2.2.1) to upload data to the DSU.
Identity manager
The NDNFit application is one of the first where we explore user-facing application management of the chainof identities (expressed in certificates) used for signing of data packets. The NDNFit application as currentlyimplemented uses three types of identities: user, device, and application. An Android-based identity manager(ID manager) handles user and device identity generation, signature requests, and signing of certificates forthese identities as needed. A new user requests their own subnamespace in the Open mHealth top-levelnamespace, and an authority for that namespace grants the request by signing a certificate correspondingto the user identity. In the current implementation of the system, the Android ID manager generates theuser identity and employs web services to request an authority server sign the certificate, using email foruser authentication. Lower-value keys are then authorized by the high-value key that is part of the useridentity. For example, after the user identity is created, the ID manager generates a per-device identity forthe phone it is running on, and the user identity signs the device identity. Then, the NDNFit generates anapplication identity upon its first launch, which it requests that the ID manager sign with the device identity.(The application then generates an instance identity on startup or every few hours, which is signed by theapplication identity, though this is not implemented yet.) The lower value keys actually sign data, whichcan be verified as an authorized part of the Open mHealth namespace by walking the trust chain all theway back to the Open mHealth authority’s signature on the user identity. Figure 2.7 illustrates an exampletrust relationship. The application certificates, device certificates, and user certificates are all published inthe DSU to ensure they are available for verification.
8
Figure 2.6: NDNFit Application UI
/org/openmhealth
/org/openmhealth/somebody
/org/openmhealth/somebody/someIMEI
signs
signs
/org/openmhealth/somebody/someIMEI/ndnfitsigns
Open mHealth root
User identity
Device identity
Application identity
Figure 2.7: User, device, and app identity for NDNFit application
9
Figure 2.8: Use packet encapsulation to convert NDN packets to NFN packets
Data transport protocol
As part of finalizing the application design, we developed specific data transport protocols for cases wherebasic Interest-Data exchange was insufficient, including notification of new data and efficient retrieval ofdata with unpredictable names using catalogs (manifests). The approach taken in implementing the protocoladdresses three challenges for communication between mobile devices and data storage units (DSUs): (1)intermittent connectivity; (2) fetching patterns for data named with a timestamp component that can’t bepredicted by the consumers; (3) power and storage constraints. The DSU implements an application patternin which permanent storage “watches” namespaces of interest for new data, and then issues Interests toretrieve that data, which it stores and republishes. Briefly, the specific approach includes a signal interestthat a mobile devices uses to notify a DSU of new data, a catalog the mobile provides to the DSU so theDSU knows what names to fetch, and a confirmation request Interest.
NFN integration mechanism
An interesting research challenge motivated by the Open mHealth environment is how to support distributeddata processing. NDNFit uses NFN (Named Function Networking) [12] to implement DPUs. This year, weexplored approaches to integrating NFN with NDN. The current implement of NDNFit provides a servicethat rewrites and translates packets from the NDN to NFN formats while preserving the trust relationshipsand access control used in NDNFit. Figure 2.8 shows a concrete translation example.
2.2.2 Progress towards milestones
We summarize progress toward our proposed milestones for this specific environment:
• Review limitations in current IP-based architecture for Open mHealth needs. (Y1) Completed previ-ously.
• Design namespace, repository, trust and communication model for use cases, e.g., diabetes or PTSDtreatment (Y1; updated in Y2) Finalized and implemented the complete design for the fitness use case.
• Repository implementation providing backing storage for prototype applications. (Y1) Complete alongwith supporting security components.
• Integrate named data networking into the Ohmage mobile data collection framework. (Y2) Done onthe mobile side. For server-side integration, after further experimentation we deemed it unnecessaryto generate a complete application; instead, we designed and integrated a native NDN approach fordata processing in collaboration with the University of Basel and Prof. C. Tschudin’s group.
10
PC1
C2
L1 L2
L3
DRD1 = L1+L2
DRD2 = L3
R
Figure 2.9: Data Retrieval Delays in 1-to-2 RTSD fetching scenario: C2 experiences smaller DRD valuewhen it starts fetching after the C1 and receives cached data from the R.
• Pilot user-facing application using NDN, for testing by Open mHealth team. (Y2) We completed allcomponents and integrated them into a demo system; we plan further work during the supplement tovisualize the underlying system operation.
2.3 Mobile multimedia: ndnrtc (NDN real-time conferencing tool)
This year, we continued to develop and evaluate ndn-rtc, a complete real-time videoconferencing applicationbased on the WebRTC library and VP8 codec. This application is helping us understand the challenges of low-latency communication over NDN. We are using it to explore the potential to shift real-time communicationmodels from push-based to pull-based. In ndn-rtc, the producer’s main task is to acquire video and audio datafrom media inputs, encode it, pack into network packets and buffer it to respond to incoming Interests. TheNDN model shifts capability and control to the consumer, which selects streams based on user requirementsand performance, leveraging NDN to enable scalable delivery at the network layer.
In addition to the ndn-rtc library, we built ndncon, GUI application on top of NDN-RTC that we hopecan serve the NDN community’s audio-video conferencing needs while leveraging the NDN Testbed. Wehad the ambitious goal of the NDN team using of ndncon for internal weekly meetings and seminars by theend of the project. We have been testing the software since April 2016 in order to improve and fine-tuneour algorithms, and to better understand performance on the NDN testbed. We elaborate on the followingaspects of testing further in this year’s joint publication with Panasonic Research [6]:
• Detecting the latest data available. For real-time applications, we have set the design goal thatconsumers should be able to retrieve the latest data available from a producer without requiring theirinterests to directly reach that producer. This enables scaling up the number of consumers withoutimpact on the producers. Conceptually, consumers aim to retrieve the most recent data from thenetwork rather than from the producer. At a high level, this approach works: our experiments suggestthat in multi-consumer scenarios for real-time data, only one consumer typically retrieves data directlyfrom the the original producer, while others receive cached data (Figure 2.9). However, a challengeremains in how to most quickly and accurately establish the latest data available from the network whenstream consumption is bootstrapped or when network connectivity changes. We refined techniques thisyear based on detecting stable values of inter-arrival delays of incoming packets. (Intuitively, cacheddata arrives as a function of network performance while fresh data arrives according to the originalsignal sample rate.)
• Adaptive consumer retrieval. New Interest pacing techniques enable consumers to tune interestexpressions in order to adapt to changing conditions, like buffer starvation or old data arrival.
• Performance improvements. We improved overall library performance and robustness by im-plementing single-threaded consumers, asynchronous non-blocking logging, CPU load and memoryfootprint optimizations.
• Real-world testing. We simulcast several NDN seminars via ndncon, which revealed important issues
11
ConsumerInterest PipelineData Buffer
ADU processing
ADUs
Signalling
NDN
ProducerADU
generationSegmenter
Segments
ADUs
Cache PIT
Interests/Segments
Interests
Segments
Signalling
Figure 2.10: NDN consumer and producer conceptual design.
such as CPU and memory load of NFD, interactions of testbed strategy configurations on certain hubs,properly configured and functioning testbed prefix auto-registration and auto-propagation, and usercertificate management.
The applications and architecture teams dedicated significant effort to documenting and critiquing gen-eralizations of the ndn-rtc design. The applications team has been adapting the design (2.10) to other NDNapplications that require real-time data dissemination: live person tracking (OpenPTrack) and distributedcontrol system for live performance (Ananke) [6]. The architecture team provided feedback and offered al-ternatives based on years of TCP/IP-based conferencing experience. This collaborative approach motivatedfurther implementation work to support new experimentation. To support cross-team experimentation withNDN-RTC, and research on the impact of forwarding strategy and congestion control algorithms on its per-formance, we developed a new cross-platform headless application, supporting OSX and Ubuntu. It can bebuilt from sources or downloaded as a part of an NDN-RTC Docker image for easy setup.
2.4 Scientific Data Applications
Through a combination of this project funding, other NSF funding, and outside support and collaboration,we continued exploring NDN support for scientific data applications, in particular in the climate science andhigh energy physical science communities.
2.4.1 Climate modeling applications
Managing climate datasets is challenging due to their size, diversity, vast geographical distribution, number offiles and lack of uniform naming structure. For example, CMIP5 (Coupled Model Inter-comparison Project)data is about 3.5 Petabytes in size and distributed among more than twenty institutes worldwide. CMIP5datasets are distributed via a P2P system called ESGF, composed of about 20 independent nodes locatedaround the world. ESGF nodes are loosely synchronized; they serve CMIP5 datasets, but also serve localdatasets, available only from that node. The latter requires that users know which node hosts the localdatasets.
We developed an application (ndn-sci) that provides efficient dataset publishing, discovery and retrievalusing NDN. Last year we reported on software we developed that translates climate file names to uniformNDN names to ease data management. We walked all working ESGF nodes and found approximately 2.7Munique names from those sites. We converted them to NDN names using this translator and included themin our catalog. The purpose of the catalog is to help scientists discover the NDN names of the datasets they
12
want. After discovery, users request each dataset by providing the name to NDN. Discovery can happen inthree ways: (a) through a standard name component search and the catalog returns all names containingthose components, (b) through typing in the exact name of the dataset, in which case the UI helps througha name component autocomplete function (presenting the user with all possible options as the user typesthe name), and (c) through a expanding portions of the entire hierarchical namespace and selecting thedatasets the user wants. The UI also allows for staged data transfers, where the user initiates a transferfrom one remote machine to another. Such transfers are useful for example, when data needs to move froma supercomputer to a repository.
An interesting example is the update control we implemented in the catalog. A common requirement isthat only namespace owners can make changes in the catalog about the namespaces assigned to them. Inother words, if CSU has or wants to insert names in the catalog, only CSU should be allowed to do so. Thissimple, yet powerful control was trivial to implement with NDN. We used standard NDN signatures to ensurethat only legitimate namespace owners can publish datasets under that namespace by comparing the namesof the datasets being inserted or deleted with the signature of the publisher that requests these actions. Thecatalog is currently serving a subset of the CMIP5 data and is running on our science testbed over ESnet. Wedemonstrated the software at Supercomputing 2015 [8] and documented it in several publications [11, 4, 10].All climate science NDN applications and tools are under active development.1
2.4.2 NDN in High Energy Particle Physics (HEP)
As we described in last year’s report, the HEP community has similar data management requirements as theclimate community. For example, the HEP community generates petabytes of data, that is distributed viaa tiered system around the world. The HEP community has developed its own distribution system calledxrootd, that among other things is responsible for data publishing, discovery and distribution.
At SuperComputing 2015 we also demonstrated that the software we developed for the climate appli-cations can be used in scientific domains such as HEP. We used the same catalog software to serve HEPdata. The only change was the use of a different namespace that was appropriate for HEP dataset names.The namespace specification is a parameter provided to our catalog. We are still working to identify accesspatterns for HEP data, which will help us quantify how much NDN can improve HEP workflows over IP.
2.5 Information Maximization
UIUC (PI Tarek Abdelzaher) finalized a new transport protocol that intelligently filters streams of informa-tion in order to reduce transmitted data volume, while minimizing loss of information. Infomax is motivatedby the emergence of IoT and sensor-filled environments, and the advent of social networks that democra-tize information broadcast, propelling us into a world of data overload. The growing disparity between theamounts of data generated and what suffices to meet application information needs suggests that an in-creasingly important network capability required to support networked applications of the future will be oneof data sampling as a means of summarizing large (remote) data sets. Current application models requireretrieving the entire data set regardless of the granularity of detailed required, followed by discarding all butthe desired samples. Infomax is a generic transport protocol that can sample data in a consumer-controlledmanner, while minimizing information loss resulting from non-delivery of the rest of the data set.
Infomax offers a producer/consumer API. To share data, the application on the producer side initializes anInfomax producer construct and specifies a name prefix associated with produced data. The application canthen add data to the specified name subtree using a produce primitive. On the consumer side, the applicationspecifies data of interest using a named prefix, which identifies a subtree and creates the receiving end forcontent that lives in this subtree. A consume primitive allows the application to retrieve a single sample.The application can call consume repeatedly until it retrieves a sufficient number of samples. The protocolensures that the consumer receives samples in an order that maximizes coverage, i.e., samples of differentlarge data clusters first, followed by samples of smaller sub-clusters that progressively refine the original
1https://github.com/named-data/ndn-atmos
13
clusters, until the consumer achieves the desired level of detail. Retrieval continues until the applicationstops calling the consume method.
The protocol assumes that hierarchical data object names reflect object similarity. Hence, more similarobjects share a longer name prefix. Accordingly, consumers retrieve samples in a minimum shared prefixfirst order. Note that objects that share the minimum prefix have the least similarity, thus minimizingunnecessary redundancy and overlap among samples. The protocol determines the retrieval order solelyaccording to data names, offering a generic way for summarization/sampling that leverages naming in NDN.This algorithm is similar to a breadth-first traversal of the specified name tree. Since the producer knowsthe exact tree topology, but the consumer only knows the general prefix that names the tree, the producercomposes an ordered list of objects in the tree, in a longest-shared-prefix-first order. When a consumerfirst contacts the producer, the protocol (of the Infomax socket) requests this list first. Intermediate routersmay cache this list per normal NDN operation. Consumers receiving the list then proceed with requestingobjects sequentially, thereby receiving a diverse sampling first, then receiving progressive refinements due tothe way objects are ordered. Different consumers can stop at different points during this retrieval process,hence receiving summaries of different degrees of detail.
This year, UIUC integrated Infomax with the NDN producer/consumer APIs, which include three dataretrieval functions: simple data retrieval (SDR), reliable data retrieval (RDR), and unreliable data retrieval(UDR). SDR retrieves a single NDN data packet up to 8KB. Both RDR and UDR allow larger packets,but segment them into multiple packets. Infomax retrieves (a sampling of) entire content trees, not singledata objects, thus it complements the aforementioned data retrieval protocols. The Infomax Data Retrieval(IDR) protocol sits on top of the other three and can use any of them to retrieve the individual objects, butuses RDR by default.
To test and evaluate the Infomax protocol, UIUC developed a Twitter feed summarization application(Iphone app). A producer downloads Twitter feeds on several topics of interest including disasters, civilunrest, and other newsworthy events. Consumers can then download their own customized news summariesof these events, controlling both the topics of their news summaries and the degree of summarization.The key in enabling this application was to create an appropriate name space for tweets that satisfies theInfomax imperative: namely, objects (tweets) that are more similar should share a longer name prefix. Theimplemented naming solution determined the fraction of shared tokens (words) between pairs of tweets asa measure of logical distance between them, then recursively applied K-means clustering on the resultinggraph. Individual tweets were hierarchically named based on their cluster/subcluster. Subsequent testingdemonstrated the efficacy of this approach at summarizing events and allowing drill-down into sub events.UIUC is preparing the application for sharing via the Apple AppStore. Infomax implementation and itsapplication examples are currently being prepared for publication in a book chapter [7].
2.6 Libraries
Libraries are a critical part of NDN research as they link work on the protocol and forwarder with applicationdevelopment. We summarize recent activities and their motivations, as well as research in the future ofapplication programming interfaces for NDN.
2.6.1 ndn-cxx: NDN C++ library with eXperimental eXtensions
To promote and support robust, effective, and diverse experimentation with the NDN architecture, andsupport development of the new forwarding daemon (NFD), in 2014 we forked the NDN Common ClientLibraries C++ library development effort (NDN-CPP) and developed ndn-cxx, C++ with eXperimentaleXtensions, a C++ library that implements all NDN protocol abstractions and provides a foundation forcutting edge experimentation with NDN technology. In particular, ndn-cxx is used to prototype new ar-chitectural features, which may then be incorporated into NDN-CPP. The development of ndn-cxx followsan application-driven iterative approach, taking feedback from application developers on how they use andinteract with the library, what challenges they experience, and what changes they would like to see. We alsostrive to maintain stability within ndn-cxx release cycles.
14
We have continued development of the ndn-cxx library to ensure that it implements all NDN protocolabstractions and provides a foundation for cutting edge experimentation. Since May 2015 we have made fiveminor releases and one major release introducing variety of functionality:
1. support for Link abstraction, to enable data retrieval when the data’s prefix is not globally reachableor when data needs to be retrieved from a moving producer.
2. implementation of the NDNLPv2 NDN Link Layer Adaptation protocol, to enable features such aspacket processing instructions (next-hop choice, cache control, etc.), fragmentation and reassembly,and packet loss detection.
3. a Dispatcher helper class to simplify server-side implementation of the NFD management protocol.
4. Support for the upcoming PIB feature2
5. the PartialName type, which represents an arbitrary sequence of name components (while Name rep-resents an absolute name).
6. Generalized signing API in KeyChain.
The following applications and projects continue to use ndn-cxx:
• NFD - NDN Forwarding Daemon
• NLSR - Named-data Link-State Routing protocol
• repo-ng - a new implementation of NDN repository
• ChronoChat - Multi-user NDN chat application
• ChronoSync - Sync library for multiuser real-time applications for NDN
• ndn-tools - A collection of NDN command-line tools (ndnping, ndn-traffic-generator, ndndump, etc.)
• ndnSIM 2.0 - NDN simulation framework for NS-3 simulator engine
• ndns - Domain Name Service for Named Data Networking
• ndn-atmos - software suite to support ongoing climate model research at Colorado State University,Berkeley and other institutes
• ndn-group-encrypt - group-based encryption library for NDN applications
2.6.2 NDN-CCL: Common Client Libraries
The NDN Common Client Libraries (CCL) provide a common application programming interface (API)across multiple languages for building applications that communicate using NDN. They incorporate featuresoften first introduced in ndn-cxx. Currently, the CCL is implemented in C++, Python, JavaScript and Java,with support for pure C and C# .NET. Since May 2015 our library development has included integratingsecurity research results in schematized trust [14] and name-based access control [15], incorporating othernew features motivated by the network environments, and improving performance:
1. To support resource-constrained devices in our BMS and mobile health environments, we extendedsupport for signing and verifying HMAC signatures to PyNDN and the in-browser NDN-JS library.We also added support for a generic signature type, which lets the application compute the signaturevalue and supply the encoding.
2. To enable authentication using identity and keys that persist across browser sessions, we added supportto NDN-JS for IndexedDB storage, a web standard available in major browsers like Firefox and Chrome.
3. We also added support for a new package called cryptography [1], which more efficiently handles RSAand ECDSA signatures for devices powerful enough to use them.
2The Public Information Base (PIB) stores the public portion of a user’s cryptography keys.
15
4. While signature operations dominate Data packet processing, encoding/decoding operations dominateInterest processing, which can challenge resource-constrained devices. We added optional support for Cbindings to PyNDN, to directly use NDN-CPP Lite, which doubles the speed of the encoding/decodingoperations.
5. Our mHealth application uses the Link object, so we implemented the capability to encode/decode aLink object and to add it to an Interest packet with a Selected Delegation field.
6. All of our environments are sensitive to power consumption, which means asynchronous I/O capabilitiesoffer a huge advantage. (The CPU can stay relatively idle until it receives a network packet.) Weextended the NDN-CCL API to allow an application to use its asynchronous library of choice, in athread-safe manner to support multi-threading.
7. We added support for notifying applications about negative acknowledgment (NACK) messages, whichthe new NDN network link protocol uses to signal a reachability failure.
8. For improved security, the real-time videoconferencing application needs to create and serve per-sessioncertificates in addition to regular data packets. So, we updated the MemoryContentCache so theapplication needs to register only one prefix with the forwarder but can internally dispatch incominginterests based on filters for different types of data being produced.
9. To support requests from the research community using the NDN software platform, we added supportfor Visual Studio using NDN-CPP, and created an NDN-DOT-NET library to support use of NDNin C# .NET applications. We created the NDN-DOT-NET library by adapting a converter whichtransforms Java code to C#. Therefore, new features in jNDN are made available for .NET applicationswithout needing to maintain an explicit C# library for NDN.
10. We removed methods from NDN-CCL due to deprecation of the older NDNx forwarder, simplifyingthe API and code base.
NDN-CCL is used by applications including:
• ndn-rtc, ndncon - Real-time audio/video conferencing over NDN (NDN-CPP)
• ndn-bms - Building management pilot application (NDN-JS)
• ndn-opt - OpenPTrack publisher / consumer (NDN-JS; NDN-CPP)
• NDNFit - NDN Fitness application (jNDN, initially)
• FoS - Control system for REMAP “future of storytelling” project (NDN-JS; PyNDN)
• ndn-iot - IoT toolkit on Raspberry PI (PyNDN)
• AmbiInfo - Ambient informatics installation by REMAP (PyNDN on Raspberry PI)
• ndnfs - NDN File System, second version (NDN-CPP)
• Routing status - NDN routing status page (NDN-JS)
2.7 Open Challenges Raised by Network Environment Develop-ment
• Mobility support is a critical and not completely implemented aspect of the NDN platform, thoughsignificant progress has been made in the research and design of mobility techniques. The OpenmHealth network application has been an excellent driver for several important elements of a practicaland holistic NDN approach to mobility - autoconfiguration, prefix registration, identity management,and encapsulation / LINK support.
• Name confidentiality is an open issue, particularly well-motivated by Open mHealth, which has gener-ated significant discussion (though no results yet) over the last year - with potential solutions ranging
16
from partial name encryption to encapsulation. This discussion also emphasized the importance ofexplaining general privacy benefits from the NDN architecture in comparison with TCP/IP.
• While name-based access control provides initial insight into how granular data-centric encryption canbe achieved in practice, two significant questions have arisen: 1) how to keep APIs and abstractionssimple for developers, and 2) how to address ad-hoc group formation. We have also identified otherpotential solutions to configurable access control using encryption, notably attribute-based encryption,which we hope to compare with this approach in the future.
• User-facing identity management will be an important part of NDN applications. NDN providesthe means to map application-level identities into collections of named certificates that are used forsignatures, but more work is required to regularize generation, signing, exchange, and revocation ofcertificates so each application does not need to re-invent an approach. Some progress has been madein the NDNFit and EBAMS applications, which borrow mechanisms originally created for the NDNtestbed’s routing certificate management.
• Our sample applications, such as ndn-rtc, are evolving to the point that certain aspects can be gen-eralized. We have found that it is challenging to balance what has been learned from TCP/IP witha desire to not blindly adopt its abstractions where they do not fit. One specific example is in con-gestion control. The architecture can provide in-network support for congestion control by leveragingforwarder state, strategy, and packet naming, but requires new designs to support multi-path scenariosin a caching network, rather than direct adoption of techniques from the current internet.
References
[1] Cryptography.io library. https://cryptography.io/en/latest/.
[2] Luigi Atzori, Antonio Iera, and Giacomo Morabito. The internet of things: A survey. ComputerNetworks, 54(15):2787–2805, 2010.
[3] Deborah Estrin and Ida Sim. Open mhealth architecture: an engine for health care innovation. Science,330(6005):759–760, 2010.
[4] C. Fan, S. Shannigrahi, S. DiBenedetto, C. Olschanowsky, C. Papadopoulos, and H. Newman. Managingscientific data with named data networking. In Proceedings of the Fifth International Workshop onNetwork-Aware Data Management. ACM, November 2015.
[5] Xi Fang, Satyajayant Misra, Guoliang Xue, and Dejun Yang. Smart grid—the new and improved powergrid: A survey. IEEE Communications Surveys & Tutorials, 14(4), 2011.
[6] Peter Gusev, Zhehao Wang, Jeff Burke, Lixia Zhang, Eiichi Muramoto, Ryota Ohnishi, and TakahiroYoneda. Real-time streaming data delivery over Named Data Networking (invited paper). IEICETransactions, May 2016.
[7] Jongdeog Lee, Akash Kapoor, Md Tanvir Al Amin, Zeyuan Zhang, Radhika Goyal, Zhehao Wang, IlyaMoiseenko, and Tarek Abdelzaher. InfoMax: A Transport Layer Paradigm for the Age of Data Overload.In Advances in Computer Communications and Networks - from green, mobile, pervasive networking tobig data computing (Web of Science Book Citation Index (BkCI)). River Publisher, July 2016.
[8] C. Olschanowsky, S. Shannigrahi, and C. Papadopoulos. Supporting climate research using named datanetworking. In Local Metropolitan Area Networks (LANMAN), 2014 IEEE 20th International Workshopon, pages 1–6, May 2014.
[9] Wentao Shang, Adeola Bannis, Teng Liang, Zhehao Wang, Yingdi Yu, Alexander Afanasyev, JeffThompson, Jeff Burke, Beichuan Zhang, and Lixia Zhang. Named Data Networking of things. InProceedings of 1st IEEE International Conference on Internet-of-Things Design and Implementation(IoTDI’2016), April 2016. (Invited paper).
17
[10] S. Shannigrahi, C. Fan, and C. Papadopoulos. Improving large scientific data transfers using ndnstrategies. In ICN 2016. ACM, May. under submission.
[11] S. Shannigrahi, C. Papadopoulos, E. Yeh, H. Newman, A.J. Barczyk, R. Liu, A. Sim, A. Mughal,I. Monga, J.R. Vlimant, and J. Wu. Named Data Networking in Climate Research and HEP Applica-tions. Physics: Conference Series, 664(5), 2015.
[12] Manolis Sifalakis, Basil Kohler, Christopher Scherb, and Christian Tschudin. An information centricnetwork for computing the distribution of computations. ICN, 2014.
[13] Zhehao Wang, Jiayi Meng, and Jeff Burke. Hierarchical storage for NDN building management system.2nd NDN Community Meeting (NDNcomm), September 2015.
[14] Yingdi Yu, Alexander Afanasyev, David Clark, kc claffy, Van Jacobson, and Lixia Zhang. SchematizingTrust in Named Data Networking. In Proceedings of the 2nd International Conference on Information-Centric Networking, September 2015.
[15] Yingdi Yu, Alexander Afanasyev, and Lixia Zhang. Name-based access control. Technical ReportNDN-0034, Revision 2, NDN, January 2016.
18
Chapter 3
Security
The NDN architecture per se has built-in features (e.g., per packet signature) to enable data-centric au-thenticity, and rely on content encryption to achieve data-centric confidentiality. Driven by the two networkenvironments (NDNFit and EBAMS), which may deliver sensitive data over the network, we developed adata-centric confidentiality solution, called Name-based Access Control [5]. Unlike traditional channel-basedconfidentiality solutions, which only secure data in motion, our approach also retains confidentiality of dataat rest, which better facilitates data distribution systems.
We also investigated approaches to support the authenticity of long-lived data, i.e., packets whose digitalsignature may have expired at the time of data consumption. Traditional authentication models requiresignatures to be valid at the time of consumption, which require periodic re-signing to support long-termarchival data. We proposed a look back authentication model, in which consumers check the validity of asignature at the time of production. We designed DeLorean [6] – a system that implements this model usinga secure timestamp service that allows consumers to roll back their clocks and authenticate data in thecontext of its production.
Finally, we designed, implemented and evaluated a content poisoning system for NDN.
3.1 Name-based Access Control
The basic idea of data-centric confidentiality is: a producer encrypts the content in a data packet at thetime of production so that only authorized consumers can decrypt the content. Data-centric confidentialitymodels offer two advantages over channel-based confidentiality: data remains confidential both in motionand in rest; and access control comes automatically via the packet signatures.
A common approach to content confidentiality between two users is to encrypt content using each au-thorized user’s public key directly, but it typically leads to multiple encrypted copies of the same content,and any required packet segmentation (fragmentation) introduces additional storage overhead and reducesthe efficiency of content delivery. Moreover, this approach assumes that a producer has complete knowledgeabout the access control policy of the produced data, which may not be true in some cases, e.g., distributeddata production.
We approach the problem by encrypting content using a symmetric content key (C-KEY in Figure 3.1) anddistributing the content key to authorized consumers, thus resulting in only one encrypted copy of contentbut multiple encrypted copies of keys. Content keys represent the minimal access control granularity. As aresult, we convert the problem of data-centric confidentiality into a problem of content key distribution.
In order to facilitate content key distribution and enforce fine-grained access control, we designed a keydistribution protocol called Name-based Access Control (NAC) (Figure 3.1). To facilitate distributed dataproduction, NAC also separates the role of namespace owner from data producer. In NAC, the ownerof a namespace can publish the namespace’s access control policy in terms of named public keys and en-crypted private keys, which we call namespace key (E-KEY and D-KEY in Figure 3.1). The encryption
19
namespace encryption key
(E-KEY)
data
content key (C-KEY)
encrypts
encrypts decrypts
decrypts
Producer operation Consumer operation
consumer public key consumer private key
D-KEYdecrypts
Data owner operation
encryptsnamespace decryption key
(D-KEY)
Figure 3.1: Overview of Name-based Access Control. Producers produce data in an encrypted format(encrypted using a content key which is also created by the producer). Producers retrieve namespaceencryption keys (published by data owners or namespace owners) to encrypt content keys and publishthe encrypted content key as a separate data packet. Data owners (or namespace owners) publish thecorresponding namespace decryption key as the third encrypted data packet, which is encrypted using anauthorized consumer’s public key. An authorized consumer can retrieve the three encrypted data packetsand recursively decrypt the keys and the original data.
key name (E-KEY in Figure 3.2) specifies the access namespace under which content keys should be en-crypted using the encryption key. The encryption key name also includes additional requirements (e.g.,time intervals) to further restrict the access granularity of the encryption key. Using the names listed inFigure 3.2 as an example, a medical monitoring device is producing heart rate data every minute underthe namespace “/alice/health/data/medical/pulse”. The producer (i.e., the monitor device) creates acontent key (e.g., “/alice/health/data/medical/pulse/2016/05/02/18/C-KEY”) to encrypt all the dataproduced within one hour. Each content key is named after its corresponding hour. A producer also re-trieves the namespace key whose access namespace is a prefix of the content key encryption namespace, e.g.,“/alice/health/read/medical/pulse/E-KEY/20160502/20160503”. The producer checks the additionalrequirements from the name of the namespace key(e.g., time interval) to determine whether a content keyfalls into the scope of the retrieved namespace key and encrypt the content key only if it is covered by thenamespace key.
/alice/health/data/medical/pulse/2016/05/02/18/C-KEY/
/alice/health/data/medical/pulse/2016/05/02/18/30Data name:
C-Key name:
/alice/health/read/medical/pulse/E-KEY/20160502/20160503/alice/health/read/medical/pulse/D-KEY/20160502/20160503
data owner prefix
access namespace
additionalrequirements
E-Key name:D-Key name:
c-key encryption namespacedata owner prefix
Figure 3.2: Encryption key naming convention in NAC. The name of content key (C-KEY) implies that allthe data under the content key namespace is encrypted by the content key. The name of namespace key(E-KEY and C-KEY) determines which content key should be encrypted using the namespace key, i.e., theaccess namespace in E-KEY name must be a prefix of the content key encryption namespace.
20
The namespace owner encrypts the corresponding decryption key (D-KEY) using the public keys ofauthorized consumers and publishes the encrypted decryption keys also as data packets (the packet withgreen lock in Figure 3.1). In NAC, we defined naming convention for encrypted data and name content,content key and namespace decryption key using the same naming convention (Figure 3.3). More specifically,any encrypted data name is a concatenation of the plain text data name, a special name component “FOR”,and the encrypting key name. Following the encrypted data naming convention, authorized consumers canretrieve data and keys and construct a key chain to decrypt the original data. For example, Alice may grantBob the access to heart rate data by encrypting the corresponding D-KEY using bob’s public key and namethe encrypted D-KEY as the last one in Figure 3.3
/alice/health/data/medical/pulse/2016/05/02/18/C-KEY/FOR/medical/pulse/E-KEY/20160502/20160503
/alice/health/data/medical/pulse/2016/05/02/18/30/FOR/medical/pulse/2016/05/02/18/C-KEY/Encrypted Data name:
Encrypted C-Key name:
/alice/health/read/medical/pulse/D-KEY/20160502/20160503/FOR/bob/encryption/KEY
data owner prefix user key nameD-KEY name
Encrypted D-Key name:
C-KEY name
data owner prefix
data owner prefix
data name C-KEY name
E-KEY name
Figure 3.3: Encryption key naming convention in NAC. The first name refers to data encrypted using acontent key (the packet with black lock in Figure 3.1). The second name refers to a content key encryptedusing a namespace key (the packet with orange lock in Figure 3.1). The last one refers to a namespacedecryption key encrypted using an authorized consumer public key (the packet with green lock in Figure 3.1).
3.2 NDN DeLorean
NDN enables data-centric authenticity by mandating per-packet digital signature. Unlike physical signa-tures, digital signatures however may not be considered trustworthy over prolonged time periods: givenenough computation power and time, it is possible to reconstruct the corresponding private key and issueimpersonated signatures. In addition, since each created signature is indeed an encrypted data digest usinga private key, keep using the same private key may render the key vulnerable to known plaintext attack.Moreover there is also a chance that the keys get accidentally or maliciously leaked to adversaries. As aresult, current practices recommend the use of relatively short-lived signatures/certificates (from severalmonths to a couple of years) [2]. This limited lifetime span works well for channel-based security model sincecommunication channels have a limited duration, but not so well for NDN’s data-centric security model.The lifetime of an NDN data packet can outlive the lifetime of its signature, especially in cases of historicaldata archives.
We proposed an authentication system for NDN data archives, NDN DeLorean, which uses a look backdata authentication model: the data authentication process first rolls the clock back to the time of thedata’s creation. In order to allow consumers to securely rollback the reference time for data authentication,we designed a publicly auditable timestamp service that issues proofs of data creation times by logging thefingerprints of archived data in the form of Merkle tree. Given a data packet, the certificates that authenticateits signature (certification chain), and the proof of the creation time (i.e., the fingerprints created by thetimestamp service) of data and certificates, one can always authenticate the data, regardless of the signatureexpiration and even the fact that the private key may have become public.
DeLorean is an always-on service that publishes a data chronicle (Figure 3.4). The chronicle consistsof a sequence of volumes, each containing fingerprints of the witnessed data packets, such as specific USAToday articles, within a fixed time slot, e.g., 10 minutes. The existence of a data packet (its fingerprint) in
21
…
Data Packets for the Volume
Per-Timestamp Volumes
2015-10-2210:40am
2015-10-2210:50am
2016-05-103:30pm
…
Figure 3.4: DeLorean Chronicle
a particular volume is a timestamp proof that the data packet existed before the end of the correspondingtime slot. The DeLorean system finalizes each volume at the end of each time slot and publishes it as a setof data packets. The finalized volume cannot be changed without invalidating consistency with any futurevolumes.
DeLorean
Producer(USA Today publisher)
Consumer(USA Today readers)
P.3. Publish data & proof
P.1.
Req
uest
pr
oof
C.1. Retrieve data & proofs
ChronicleStorage
D. Publish chronicle volumes
Auditor
A. Consistency checking
P.2. R
etrieve proof
DataStorage
C.2. Verify proof
Figure 3.5: DeLorean Workflow.
At any time, a data producer (article’s author) or an archive service on the producers behalf (USAToday publisher) can request a timestamp proof for data (articles) from DeLorean (Flow P.1 in Figure 3.5),supplying a fingerprint of the archived data in form of a hash digest of an individual data packet or a digestof the manifest that represents a data collection. The response to this request is a name of the chroniclevolume that DeLorean will publish at the end of the current cycle (Flow D) and the index of the fingerprintin the volume. After waiting until the volume is ready (on average a 5 minute wait in our example), theproducer can retrieve the volume to verify whether DeLorean has included the data fingerprint in the volume(Flow P.2). In the end, the producer can publish the timestamp proof, which includes the full name of thevolume and the index of data fingerprint, alongside the data (Flows P.3).
To verify data independently of its signature validity, consumers need to look back to the time point whendata was produced (or time stamped). A consumer first obtains the corresponding timestamp proof, whichcan be stored alongside the data (Flow C.1), and verifies the data’s existence by retrieving several additionalDeLorean volumes. Similarly, the consumer verifies the existence of the data’s signing key certificates.4 Withall certificates proving their existences, the consumer can verify the data signature as if it were the time ofthe data’s production.
In order to ensure the correct and truthful operations of DeLorean, a set of third-party auditors contin-uously check the consistency of the chronicle (Flow A), i.e., checking that DeLorean has not modified thepreviously published volumes. If auditors detect that DeLorean has modified the chronicle, the users of theservice (auditors, data producers, and consumers) will take immediate actions to either fix the issue or aban-
22
don the specific instance of DeLorean service. In order to guarantee consistency, at least one auditor mustretrieve each DeLorean volume around the time it is published. The more auditors in the process, the lessfrequently each individual auditor needs to perform consistency checking. Note that although consumer andproducer roles are separate from the auditor role in Figure 3.5, they can be (and, from security perspective,should be) combined.
3.3 Content Poisoning Mitigation
Content poisoning attacks are a significant problem in Information Centric Netw orks ICN), such as NamedData Networking. In a content poisoning attack, an attacker injects bogus content into the network with alegitimate name. While users will reject the content because of signature mismatch, the network is largelyunaware of the problem due to the computational burden of on-the-fly packet verifi cation. Thus, subsequentrequests may trigger the return of bogus content, constituting a denial of service attack. While NDN couldresist poisoned content by restricting prefix advertisement, the latter interferes with the “content fromanywhere” principle, which we consider to be a great advantage of NDN. We investigated NDN contentpoisoning and surveyed the state-of-the-art in mitigation mechanisms. We developed a novel system fordetecting, reporting, and avoiding poisoned content that leverages the verification work that users mustdo anyway. We evaluated two evasion strategies, Immediate Failover and Probe First, that capture thespectrum of possible solutions to avoiding bad content. Our conceptualization of content poisoning in NDNas essentially a forwarding problem enables NDN-based mitigation mechanisms via the use of adaptiveforwarding strategies [3].
3.4 Plan For Next Year
We hope to complete three tasks in the next year: 1) automation of certificate management, 2) automation ofdata signing and verification based on schematized trust, and 3) applying name-based access control designto NP environments, specifically NDNfit and EBAMS (Enterprise Building Automation & Management).
For task (1), our plan is to adapt ACME, the Automatic Certificate Management Engine[2] protocoldesigned for Lets Encrypt, for NDN certificate issuance. ACME will replace the old manually managedNDN certificate system. Compared to the existing system, NDN-ACME will be able to support multiplecertificate hierarchies, instead of supporting only the NDN testbed certificate hierarchy. The new systemwill enable multiple validation approaches, such as email, shared secrets, and DNS, instead of email beingthe only one validation mechanism. Moreover, the new system will provide automated certificate renewaland key rollover, which are sorely missing now, as well as the use of short-lived keys, which will reduce theneed for key revocation.
Task (2) has three sub-tasks. First, we plan to overcome extend the current trust schema syntax [4] inorder to allow users to describe more application semantics in trust schema, such as userId or timestamp,as well as supporting user-defined syntax in the new trust schema format. Second, we plan to remove thecurrent limitation of having users manually write trust rules for a trust model, which is prone to errors.We will build a GUI tool that enables users to easily express the trust model in a graphical form, andthat automatically converts the graph into trust schema. The tool will also provide a verification interface,through which users can supply test cases in terms of data name and key name pair. The tool can outputthe result of compliance checking for user to verify the correctness of the trust rule expression. The tool mayalso accept a single data name as verification input and output all the possible signing key namespace as analternative correctness verification. Finally, we plan to integrate signing part of trust schema with the newNDN certificate system mentioned above. In the current implementation, if there are no available signingkeys, the library will refuse to sign data. By integrating trust schema with the certificate system, the librarycan automatically generate missing keys and request certificates using the new ndncert [1].
Task (3) is to turn the Name-based Access Control (NAC) into functioning code, integrate it into theNDNfit and EBAMS applications, discover potential issues in order to and further improve its design andimplementation.
23
Task (4) is to complete communication confidentiality support in NDN based on NAC, which providescontent confidentiality. Data names carrying application semantics may also reveal sensitive informationand may cause privacy issues in some cases. We discussed the privacy issues of NDN during the March 2016NDN retreat, and agreed to explore two communication scenarios: point-to-point ephemeral communicationand data distribution. Our initial plan is to provide a DTLS equivalent solution for the point to pointephemeral communication and provide an anonymizing proxy based solution to maximize the efficiency ofdata distribution with data name obfuscation.
References
[1] Alexander Afanasyev. NDNCERT: User public key certification system for NDN Testbed. 1st NDNCommunity Meeting (NDNcomm), September 2014. http://www.caida.org/workshops/ndn/1409/.
[2] Richard Barnes, Peter Eckersley, Seth Schoen, J. Alex Halderman, and James Kasten. Automatic Certifi-cate Management Environment (ACME). https://github.com/letsencrypt/acme-spec, September2014.
[3] S. DiBenedetto and C. Papadopoulos. Mitigating poisoned content with forwarding strategy. In Thethird Workshop on Name-Oriented Mobility: Architecture, Alg orithms and Applications (NOM), April2016.
[4] Yingdi Yu, Alexander Afanasyev, David Clark, kc claffy, Van Jacobson, and Lixia Zhang. SchematizingTrust in Named Data Networking. In Proceedings of the 2nd International Conference on Information-Centric Networking, September 2015.
[5] Yingdi Yu, Alexander Afanasyev, and Lixia Zhang. Name-based access control. Technical Report NDN-0034, Revision 2, NDN, January 2016.
[6] Yingdi Yu, Alexander Afanasyev, and Lixia Zhang. NDN DeLorean: An Authentication System for DataArchives in Named Data Networking. Technical Report NDN-0040, NDN, May 2016.
24
Chapter 4
Distributed Dataset Synchronization
Early in the NDN project, we identified a common need by all distributed applications: synchronization ofshared dataset, or Sync (See [4], Section 2). A list of names (or name space) represents a dataset, that maybe shared among distributed parties. While various applications differ in their goals and communicationpatterns, the need to synchronize the data represented by a collection of names or namespaces is identical.We have come to consider Sync a fundamental NDN communication primitive. Since distributed applicationsare a generalization of 2-party communications, we can view sync as a generalization of end-to-end reliabledata delivery. However Sync differs from the existing end-to-end reliable transport protocols, such as TCP, intwo fundamental ways. First, Sync reliably synchronizes application named datasets among multiple parties,while a TCP connection delivers byte streams identified by its two endpoints. Second, a TCP connectiondelivers byte streams between two specific endpoints synchronously (i.e. both must be online at the sametime), while NDN’s Sync can fetch data packets from anywhere it can find the matching data items, eitherin real time or asynchronously. The ability to reconcile set differences asynchronously is especially useful inconstrained environments with ad hoc and intermittent connectivity.
Over the last few years we have explored various different approaches to Sync support. We initiallydeveloped ChronoSync to support a Multi-User Chat application [9]; ChronoSync has since evolved to ageneral library utility used by other NDN applications including NLSR [5], ChronoShare [1], and scientificdata management applications [6, 2]. Another approach, iSync, differs from ChronoSync in that it utilizes anInvertible Bloom filter (IBF) to reconcile data collections between nodes [7]. Our progress during this report-ing period includes a) development of Round-Sync, an improvement over ChronoSync, and b) PartialSync [8]which allows individual consumers to synchronize a subset of the dataset with the producer.
In the rest of this chapter we first give a brief summary of ChronoSync and iSync to illustrate theirdifferent design approaches, followed by a description of Round-Sync (which is based on ChronoSync) andPartialSync (which adopted certain design choices from both ChronoSync and iSync). We then summarizeour current understanding of the Sync design space, and discuss our ongoing effort and plan for the comingyear in the Sync area.
4.1 Chronosync and iSync
The Chronosync design exploits naming rules to ease dataset synchronization. It assumes that eachparticipant in a distributed application names its produced data sequentially. Therefore Chronosync onlyneeds to keep track of the latest sequence number of each participant, and the latest state of the dataset canthen be represented by the cryptographic digest over everyone’s identifier plus sequence number.
Chronosync participants interact with each other using two types of Interest-Data exchanges: synchro-nization (sync) and application data. A sync interest carries the name of the application instance plusthe cryptographic digest that represents the sender’s knowledge of the current dataset which ChronoSyncwill deliver to all other participants. For example, a sync interest for Chronochat application instancelooks like /ndn/chronchat/lunch-talk/a1324asd9, where /chronchat/lunch-talk/ names the application in-
25
stance, and a1324asd9 is the digest. ChronoSync will deliver this interest to all participants who announce/ndn/chronchat/lunch-talk/ prefix.1 This sync interest serves two purposes: it checks to see whether anyoneelse holds a different digest, and if so, it tries to resolve the difference; it also checks to see whether anyonehas produced new data since the state represented by the digest. To be able to tell whether a receivedsync interest represents the latest sync state, each participant maintains the history of its observed datasetchanges in form of digest logs.
Any recipient of a sync Interest Si who has newer information can respond with a data packet thatincludes one or more pieces new data (in the form of [producer name, sequence number] pairs) missed bythe sender of Si. Once a participant learns of changes to the dataset, it can decide whether and when toretrieve the missing data from its producers. However when two or more nodes produce data at the sametime, they will all respond to Si, but the sender of Si can receive only one node’s data, and has to invokea recovery mechanism to retrieve the rest. ChronoSync also has sync recovery mechanisms that enables allparticipants to reach a common state after the network heals from a partition.
The iSync protocol utilizes the invertible Bloom filter (IBF) to reconcile sync collections betweenparticipants [3]. IBF is a hash-indexed, redundant table and supports item insertion, deletion, and limitedinversion (i.e., extraction of stored items). Moreover, one can obtain a difference set between two IBFs bysubtracting their IBF entries. iSync uses this unique subtraction operation to discover multiple differences ina single subtraction, which leads to an efficient implementation with a low computation and communicationoverhead. iSync consists of a repository and a sync agent. When the repository adds a new item to thecollection, it notifies the sync agent which in turn indexes the inserted content name and updates a digestthat reflects all names in the collection. The sync agent notifies other participants of its local digests byperiodically broadcasting the digest (equivalent to sync interest in Chronosync), while receiving remotedigests. When a remote collection digest does not match the local one, a reconciliation process starts, whichinvolves repeatedly requesting, receiving, and comparing remote IBF against the local IBF.
iSync uses a hierarchical two-level IBF: Repository IBF and collection IBFs. The former records the statusof the entire repository, while the latter logs insertions and deletions of each sync collection separately. Anupdate to a collection changes the collection’s IBF in only one second level digest, by adding the hash of thenew data name into the corresponding collection IBF, which then invokes an update to the repository IBFand digest. We (Washington U.) designed and implemented the iSync protocol [7], and evaluated iSyncsperformance by comparing it to the CCNx synchronization protocol. Experiments show that iSync is abouteight times faster across a range of network topologies and sizes, and that it reduces synchronization trafficby about 90%.
Comparing Chronosync and iSync reveals two basic differences. First, with its use of an IBF,iSync can discover multiple changes to the dataset through one sync exchange, while Chronosync may needto iterate through all changes, especially with multiple simultaneous producers. Second, and related, thestorage and computation cost of IBF is nontrivial. iSync makes no assumption about data names, and itsvolume of name collections grows over time, and so does the IBF data structure overhead. For example,each iSync repo node may need to create multiple IBFs in a sync period if the number of updates since theprevious sync interest has exceeded the capacity of the IBF; other repos need to retrieve and process allthose IBFs in order to discover all the updates in the last sync period.
Currently, both Chronosync and iSync must deliver sync interests to all participants in a distributedapplication, highlighting the need for more scalable solutions, still an open research topic.
4.2 Round-Sync
ChronoSync uses a Sync interest for two purposes: a) to check to see whether anyone else holds a differentdigest; and b) to check to see whether anyone has produced new data since the state represented by thedigest. This double-meaning of Sync interests leads to certain performance limitations of ChronoSync.First, each node must resolve any differences before producing new data, otherwise additional new data
1An alternative to letting participants make routing announcements is to use broadcast, i.e. sending sync interest using thename /ndn/broadcast/chronchat/lunch-talk/a1324asd9, which is the current default implementation. A scalable andefficient solution for delivering sync interests remains an active research effort.
26
would make reconciliation more difficult. Second, if multiple nodes produce new data simultaneously, theycannot recognize the digest in the Sync interests generated by others, thus they must reconcile first beforeproducing any new data. Besides delaying the new data propagation, reconciliation itself also carries a cost.
Round-Sync aims to reduce the invocation of state reconciliation by decoupling the function of detectingout-of-synchronization from fetching new data. Round-Sync divides data generation into rounds, that areidentified by monotonically increasing numbers. When a node A produces a piece of data at round n, itimmediately increases the round number to n + 1 and sends a Data interest to solicit data for round n + 1.This reduces, although does not eliminate, the chance of multiple nodes producing new data in the sameround.
Each round n has a digest Gn which is a cryptographic hash of all data names produced at roundn. The dataset also has a cumulative digest GN which is the hash of all the round digests up to roundn. Round-Sync uses two different types of interests, one for data fetching (Data interests), and one fordetecting out-of-synchronization state in a round (Sync Interests). These mechanisms enable Round-Sync tosynchronize data production for each round separately. When a node A produces a piece of data at round n,it increases the round number to n + 1 and sends a Data interest to solicit data for round n + 1. If anothernode B also produces data at round n before it receives A’s data, B will have a different round digest thanA’s. While A and B resolve their differences, node C may produce data at round n + 1 which does notinterfere with A and B’s reconciliation.
In summary, by cutting data production into different rounds and decoupling the detection of out-of-synchronization from fetching new data, Round-Sync reduces the chance of data production collision (onesync interest solicited multiple pieces of data produced by multiple nodes) and allows data production inparallel with dataset synchronization. At the time of this writing we are evaluating the performance ofRound-Sync as compared to ChronoSync through simulation, hoping to achieve quantitative results soon.
4.3 PartialSync
PartialSync protocol [8] is designed to efficiently synchronize datasets between consumers and producers,where individual consumers may be interested in only a subset of the whole data collection, and maysynchronize with any producer sharing the same dataset, assuming that a) all producers keep synchronizedwith each others, say through either ChronoSync or iSync, and b) they can be reached by using the sameroutable name prefixes.
PartialSync uses regular Bloom Filters (BF) to let consumers express their subscriptions (SubscriptionList), and uses Invertible Bloom Filter (IBF) to represent a producer’s latest dataset (Producer State). Aconsumer keeps the producer’s IBF and queries for an update periodically by attaching both its BF and theproducer’s previous IBF to each query, expressed as a PartialSync interest. By comparing the differencesbetween the previous IBF carried in the query and its current IBF, the producer can generate a list of namescorresponding to the new data that has been produced in the period between the previous and new IBFs.Using the subscription list carried in the query, the producer can notify the consumer of all changes in thesubset to which the consumer has subscribed.
To address the scalability issue with the number of names encoded in an IBF, PartialSync adoptsChronoSync’s approach of letting each producer name data sequentially. Therefore the latest dataset can berepresented by an IBF which contains only one data item from each producer, which is the producer’s nameplus its latest sequence number. When a producer P generates a new data item and increases its sequencenumber from N to N + 1, PartialSync will remove the item [P , N ] from the IBF and add [P , N + 1] to theIBF. In doing so, the IBF contains only M items, where M is the number of producers.
Upon its start, a consumer first sends a PartialSync Interest to the Sync prefix, the interest includesa Subscription List BF and an empty IBF. This interest may reach any of the producers. The producersends back a PartialSync Reply which includes its latest IBF, as well as the latest names, in the form of[producer, seq#], of all the data streams as part of the content of the message. The consumer can thenretrieve the latest data in its subscription list accordingly. In its subsequent queries, the consumer includesin its PartialSync interest the subscription BF and the last IBF it obtained from the producer. Whenever
27
the producer receives a PartialSync Interest from the consumer, it first parses the BF and the IBF in theconsumer’s PartialSync Interest. If the IBF from the consumer and its own IBF are the same, the producerwaits until new data arrives that matches the consumer’s subscription list. Otherwise, if they are different,the producer checks whether there are any updates to data to which the consumer is subscribed. In bothcases, the producer sends a PartialSync Reply which contains a list of updated data names.
When a consumer receives a PartialSync Reply, the consumer first checks whether each received dataname is in the subscription list; due to the false positive property of BFs, the producer may occasionallysend data names not on the consumer’s subscription list. For each subscribed data name, it then checkswhether the sequence number is newer than its own version, and if so, the consumer sends an Interest tofetch the newer data. The consumer will send another PartialSync Interest to the producer, either uponreceiving a PartialSync Reply or upon the timeout of the previous PartialSync interest, which includes thereceived IBF.
In summary, PartialSync supports scalable and efficient subscription service through the following means.1) Like ChronoSync, it uses naming conventions to keep data items in the IBF constant. 2) Like iSync, itmakes use of an IBF to easily detect multiple updates in one sync step. 3) It uses BF to express subscriptions,so that producers only inform a consumer about updates to data of interest to the consumer. 4) It carriesthe consumer state in a PartialSync interest, which frees the producers from keeping consumer state andallows consumers to sync with any producer (assuming producers keep sync’ed with each other). In contrastto ChronoSync and iSync, whose sync interests are multicast to all participants, PartialSync interests areanycast to any one of the producers.
4.4 Summary and Plan for Next Year
Data synchronization is an important communication mechanism for distributed applications over NDN. Ex-isting Sync protocols make different design tradeoffs in how they achieve dataset reconciliation: ChronoSyncand RoundSync leverage the naming convention of using sequence numbers in data names to allow efficientencoding of the synchronized namespace as a list of [producer name, latest sequence number] pairs; iSyncsupports arbitrary namespace structure at the cost of higher storage and processing overhead associated withIBF. PartialSync can be applied in distributed applications to support synchronization between consumersand multiple producers, but requires producers to synchronize using ChronoSync or iSync.
Our plans for the next year include: 1) continuing to explore efficient dataset reconciliation mechanismsthat can improve the existing Sync protocols, 2) evaluating the communication cost of multicasting syncinterests to all participants and designing more scalable and efficient solutions for delivering sync interests,3) improving the application interface and library support for the Sync protocols by providing more powerfuland developer-friendly abstractions over the core Sync functionality, and 4) developing new distributedapplications over the Sync protocols and evaluate their correctness, efficiency, and usability.
References
[1] Alexander Afanasyev, Zhenkai Zhu, Yingdi Yu, Lijing Wang, and Lixia Zhang. The Story of ChronoShare,or How NDN Brought Distributed Secure File Sharing Back. In Proceedings of IEEE MASS 2015 Work-shop on Content-Centric Networks, October 2015.
[2] Chengyu Fan, Susmit Shannigrahi, Steve DiBenedetto, Catherine Olschanowsky, Christos Papadopoulos,and Harvey Newman. Managing scientific data with Named Data Networking. In Proceedings of the FifthInternational Workshop on Network-Aware Data Management, November 2015.
[3] Michael T. Goodrich and Michael Mitzenmacher. Invertible bloom lookup tables. In In 49th AnnualAllerton Conference on Communication, Control, and Computing (Allerton), 2011.
[4] Van Jacobson, Jeffrey Burke, Lixia Zhang, Beichuan Zhang, kc claffy, Dima Krioukov, Chris-tos Papadopoulos, Tarek Abdelzaher, Lan Wang, Edmund Yeh, and Patrick Crowley. Named
28
Data Networking (NDN) Project 2010 - 2011 Report, 2011. http://named-data.net/project/
annual-progress-summaries/project/ndn-ar2011-html/.
[5] Vince Lehman, A K M Mahmudul Hoque, Yingdi Yu, Lan Wang, Beichuan Zhang, and Lixia Zhang. Asecure link state routing protocol for NDN. Technical Report NDN-0037, NDN Project, January 2016.
[6] C. Olschanowsky, S. Shannigrahi, and C. Papadopoulos. Supporting climate research using named datanetworking. In Local Metropolitan Area Networks (LANMAN), 2014 IEEE 20th International Workshopon, pages 1–6, May 2014.
[7] Fu Wenliang, Hila Ben Abraham, and Patrick Crowley. Synchronizing namespaces with invertible bloomfilters. In To appear in ANCS 2015, 2015.
[8] Minsheng Zhang, Vince Lehman, and Lan Wang. PartialSync: Efficient Synchronization of a PartialNamespace in NDN. Technical Report NDN-0039, NDN, June 2016.
[9] Zhenkai Zhu and Alexander Afanasyev. Let’s ChronoSync: Decentralized dataset state synchronizationin Named Data Networking. In IEEE ICNP, 2013.
29
Chapter 5
Networking
ContributorsPIs . . . . . . . . . . . . . . . Beichuan Zhang (Arizona), Van Jacobson & Lixia Zhang (UCLA), Lan Wang (Mem-
phis), Christos Papadopoulos (Colorado State University), Patrick Crowley (Washington
University)
Grad Students . . Junxiao Shi, Teng Liang, Weiwei Liu, Klaus Schneider (Arizona); Spyridon Mastorakis,
Ilya Moiseenko, Wentao Shang, Yingdi Yu (UCLA), Muktadir R. Chowdhury, Minsheng
Zhang (U. Memphis), Steve DiBenedetto, Chengyu Fan (Colorado State), Haowei Yuan,
Hila Ben Abraham (Washington University)
Undergrads . . . . . . Ashlesh Gawande, Benjamin Murphy (U. Memphis), Eric Newberry (Arizona)
Staff . . . . . . . . . . . . . Vince S. Lehman (Memphis), John DeHart, Jyoti Parwatikar (Washington University)
Research Scientist: Alex Afanasyev (UCLA)
In the past year, we continued our research to develop the underlying network layer of the NDN architec-ture, with an emphasis on how to best meet the needs of the target network environments. More specifically,we made significant progress in the areas of network protocols and software, routing protocols, forwardingstrategy, and scalable forwarding.
5.1 NDN Forwarding Daemon (NFD)
Since May 2015, we made one major and four minor releases of NDN Forwarding Daemon (NFD), evolving itfrom v0.3.1 to v0.4.1 as of this report. Over the year, we have designed and implemented a network adaptationlayer NDNLPv2, simplified configuration tasks in environments with one or more remote NDN forwardersacting as NDN gateways, improved management protocols, as well as ported NFD to the Android platform.NFD now runs on Linux, FreeBSD, Mac OSX, Android, DD-WRT/OpenWRT (home routers), RaspberryPi, and a couple of other embedded platforms, as well as in virtualized environments. The developmentof NFD continues to use an open source and distributed model, involving the broader community. Weuse Redmine for issue tracking, Gerrit for code review, and Jenkins for automatic build and continuousintegration. NFD has over 30 contributors from 10 different institutions, as well as several contributionsoutside the NSF-funded NDN team. To coordinate NFD development, we use the NFD developer mailinglist with more than 100 members currently and conference calls twice weekly. We also continually updatethe NFD Developer’s Guide and other related documents to provide implementation details and suggesteddevelopment practices for new developers and researchers.
30
5.1.1 NDN Link Protocol v2
To accommodate NDN communication to different underlying links, it may be necessary to include additionalinformation in the NDN interest and data packets. We designed and implemented a network adaptationprotocol, NDN Link Protocol v2 (NDNLPv2). With NDNLPv2, routers can: (1) fragment and reassembleNDN packets that exceed a link’s maximum transmission unit (MTU); and (2) send feedback upstreamin form of network NACKs to signal failures of interest forwarding. Special NDN applications can useNDNLPv2 to: (1) explicitly indicate which face to forward an interest; (2) obtain information about theface that originally received a packet; and (3) request special cache behavior for the data packets. The lattermay be useful when an NDN application wants to cache data and not use a router’s cache. In the future,we plan to further extend the network adaptation features.
In implementing NDNLPv2, we decided to refactor NFD’s Face system, specifically, we split the NDN Faceabstraction into Transport and LinkService components. Transport provides delivery of the data blocks overspecific underlying channels (raw ethernet packets, unicast/multicast UDP datagrams, TCP and WebSocketstreams). LinkService provides a “network adaptation” layer to translate between NDN packets and datablocks communicated through the channels. The new Face abstraction serves as a container of Transport andLinkService instances and provides a high-level interface to send/receive NDN packets. This new structuremakes it easy to combine different transports with different implementations of network adaptation.
5.1.2 NFD Management Protocol
reject
invalid
reject
dispatcher
manager
regi
ster
Com
man
dHan
dler
regi
ster
Stat
usD
atas
etH
andl
er
regi
ster
Not
ifica
tionS
tream
Not
ifica
tion
ControlCommandHandler
ParametersValidate
Authorzation
StatusDatasetHandler
Authorzation
fail
succeed
accept
valid
reject
append & end
ControlResponse Status Dataset / Response
Inte
rest
Dat
a
Figure 5.1: Overview of the manager Interest / Dataexchange via the dispatcher
Our original design of NFD included severalmanagement protocols, implemented using Inter-est/Data exchanges. To obtain information aboutthe state of an NFD module (status datasets) orchange its state (control commands), one sends aninterest or signed interest for the data or for theconfirmation of the command specified in the inter-est name. These include obtaining basic statisticsof NFD, a list of Faces, RIB, and FIB entries, cre-ation, removal, and state modification of Faces, ma-nipulating forwarding information base (FIB) androuting information base (RIB) entries, as well as se-lection of per-namespace interest forwarding strate-gies. In addition, NFD management protocols in-clude notification streams, a pub/sub-like protocolbased on interest/data exchange to get notificationswhen specific NFD events happen. For example,when a face is created or destroyed, an NFD module(RIB manager) and other special applications (e.g.,nfd-autoreg) will receive a corresponding notifica-tion. NFD Management uses the name-based schematized trust model for command interest authenticationand authorization. In the future, we plan to include encryption of the status datasets using the name-basedaccess control mechanism.
The development model for the NFD management protocol is generic and applies to other applications.For example, NLSR [6] and repo-ng1 implement management the same way. To simplify implementation ofnew management protocols, we designed and implemented the management dispatcher abstraction. Withthe dispatcher, the applications can easily implement a new management protocol by registering necessarycontrol commands, status datasets, and notification streams with the dispatcher. The dispatcher will classifyand authenticate incoming interests in a centralized and consistent way, allowing applications to focus oncommand logic rather than implementation details.
1https://github.com/named-data/repo-ng
31
5.1.3 Automatic Prefix Propagation
In NDN, when a producer application wants to make its data available for retrieval, it registers the data’sprefix with the NDN forwarder on the same host machine (i.e., local registration). Additional signaling isneeded to make data available for fetching by remote NDN forwarders. This can be achieved in one of thefollowing ways: manual configuration, dynamic name announcement protocols (e.g., NLSR), or opportunisticdata discovery strategies (e.g., the access strategy, and auto-registration of the specified prefix(es) uponcreation of on-demand faces). Different methods have different tradeoffs in ease of use, implementationcomplexity, and communication overhead. We have designed and developed an Automatic Prefix Propagation(APP) protocol to address the above issues.2
Gateway Router: A
Gateway Router: B
Host: a
Host: b
Host: c
Host: d
app1 app2
local registration……
/A/c/app1 0
……
FIB
/A/c/app2 1
……/A/c 2
……
FIB
Interest: /A/c/app2/data0
propagation
Figure 5.2: Make a producer application’s data avail-able for fetching from remote NDN forwarders.
As shown in Figure 5.2, APP enables the localNDN forwarder in Host d to automatically prop-agate local prefix registrations to the remote for-warder on Gatway Router B. Local prefix registra-tion triggers such propagation when (1) an activeremote NDN gateway exists, as indicated by the“/localhop/nfd” registered prefix in the local RIB,and (2) the local forwarder possesses a private keyand the corresponding NDN certificate that matchesor covers the locally registered namespace. If thereare two or more candidates for the keys/namespace,the key that corresponds to the shortest names-pace is selected. This allows the forwarder to ag-gregate multiple local registrations into one remoteaction, reducing communication and bookkeepingoverheads.
After the initial prefix propagation, NFD peri-odically refreshes the registration, unless the prefixis no longer registered locally or there are no NDNgateways configured. The protocol maintains a finite state automaton for each propagated entry, that notonly schedules propagation refreshment and handles failures with configured strategies, but also dynamicallydeals with connectivity changes and other state transitions.
5.1.4 Supporting Mobility and FIB Scaling with LINK
In previous work we discussed a possibility of using a LINK object to control the number of entries in theforwarding information base [1]. We can use the same mechanism to support mobile publishing, when it isnecessary to track down the moving producer and not just its data [14]. In this approach, data names mapto a set of globally routable names, which interests can include as “LINKS” to inform (hint) the forwardingsystem of the whereabouts of the requested data.
Over the last year, we added support for LINK objects in all our libraries and in NFD. This supportincluded several components: (1) definition and implementation of the LINK abstraction as a data packetcontaining a list of namespace-to-namespace mapping (delegations), (2) extension of the NDN interest packetformat to allow inclusion of a LINK object, and (3) extension of the interest processing logic in NFDforwarding pipelines. As part of the changes in the forwarding pipelines, we have introduced a networkregion table that contains a list of prefixes considered local to the producer. Whenever an interest with aLINK object reaches the router, if one of the delegations specified in the LINK is a prefix for some entry inthe network regions table, the router processes the data name in the interest, otherwise, NFD uses LINKdelegations to decide how to forward the interest.
Our current implementation of the LINK support has several limitations that we plan to address inthe future. First, the network region table requires manual configuration of NFD instances running on
2The currently implementation of the protocol assumes a single NDN gateway; future versions will support multi-gatewayenvironments.
32
routers and end hosts, which we plan to address by extending the auto-configuration protocols. Second, ourimplementation does not currently partition the content store for data with the same prefixes, retrieved usingdifferent links. As we showed in a brief analysis [1], such partitioning would be necessary in real systemsto prevent denial-of-service attacks through targeted cache poisoning. In addition to that, we have not yetfully utilized the implemented support in the developed applications, which could expose limitations of thedesigned logic.
5.1.5 Permanent Faces
Initial deployment of our applications in the BMS environment highlighted a limitation of the implementedFace system in NFD: the tunneled faces only exist while there is underlying network connectivity, and mustbe re-created after connectivity changes. To handle this situation, we added support for permanent faces(currently, only UDP-based faces) that persist throughout the lifetime of the NFD instance, along with anyassociated RIB and FIB entries. We also plan to support Face and RIB/FIB entry permanency across NFDrestarts. All native faces (e.g., Ethernet faces associated with physical network interfaces) are permanentby design. As long as an interface exists, there is a corresponding face. The limitation applies specificallyto tunneled faces, i.e., where it is infeasible or prohibitively expensive to enable native NDN support in thetransit networks, such as a campus WiFi network.
5.1.6 NFD on Android
Figure 5.3: User interfaces to NFD-Android
To allow broader experimentation with NDN tech-nology, and in particular experimentation in realmobile environments, we made a prototype port ofour reference forwarding daemon implementation onAndroid platform (NFD-Android). The port is fullybased on and evolves with the original NFD sourcecode and in addition includes several user interfacesto manually start/stop NFD service and get basicoperational statistics, create faces, and register pre-fixes (Figure 5.3). The initial port can run on anyAndroid device, including any unrooted devices, andcan be either manually compiled from the publiclyavailable source code or be directly installed fromthe Google Play store.
The initial NFD-Android port has a number ofusability limitations: it lacks auto-configuration ca-pability, including after power cycling a device; se-curity limitations prevent non-rooted Android platforms from communicating over raw Ethernet sockets; andusers must manually establish a direct WiFi session, discover peer IP addresses, and then configure properfaces and routes toward the peer-to-peer faces.
Nevertheless, the NDN team with the help of students from UCLA’s CS217B class in Spring quarter of2015 developed several pilot applications that demonstrate NDN advantages. These applications include:
• NDN Whiteboard (https://github.com/named-data-mobile/apps-NDN-Whiteboard): a real-timeshared whiteboard that works over Named Data Networking (NDN).
• PhotoSharing app (https://github.com/ohnonoho/photoSharing): a simple photo sharing applica-tion that leverages sync and local sharing of data (the app manages Direct WiFi sessions)
• ndn-hangman (https://github.com/dchandc/ndn-hangman): a simple Hangman game that usesChronosync to synchronize state of the game in delay-tolerant fashion.
These pilot application design and development efforts allowed the students to deepen their understandingof NDN through first hand experience, to appreciate NDN’s advantages in easing distributed application
33
Pre-signed Data Dynamically Generated Data
TimeBetweenInterests(ms)
Avg NFDCPU %
Avg Filetimeout%
Throughput(Mb/s)
TimeBetweenInterests(ms)
Avg NFDCPU %
Avg Filetimeout%
Throughput(Mb/s)
11 3.98% 0.29% 5.5 11 3.56% 0.33% 5.48
8 3.34% 0.31% 7.5 8 3.65% 25.9% 5.39
5 5.81% 0.34% 11.66 5 4.19% 94.7% 0.59
Table 5.1: 2.5 GHz Phone. Left: Serving pre-signed Data. Right: Serving dynamically generated Data
Pre-signed Data Dynamically Generated Data
TimeBetweenInterests(ms)
Avg NFDCPU %
Avg Filetimeout%
Throughput(Mb/s)
TimeBetweenInterests(ms)
Avg NFDCPU %
Avg Filetimeout%
Throughput(Mb/s)
11 2.31% 0.34% 5.53 37 2.24% 0.32% 1.67
8 2.85% 6.4% 6.94 34 2.23% 0.34% 1.81
5 3.11% 48.97% 5.74 31 1.97% 90.79% 0.18
Table 5.2: 1.2 GHz phone. Left: Serving pre-signed Data. Right: Serving dynamically generated Data
development, as well as allowed us to identify the following common issues that require emphasis with NDNnewcomers:
• How best to choose application data names, establish naming conventions, and make best use ofmetadata, to simplify the overall design;
• How to use versioning to handle data changes (this reflects an inadequate understanding of immutabledata concept), and
• How best to work with in-network caches.
These efforts also identified a number of issues with using the NDN prototype code base beyond theAndroid package; the most important ones are the lack of documentation and lack of sample code to easethe steep learning curve. We have proposed to address these issues in the supplement period.
We tested the performance of NDN (including NFD, applications and libraries) on two Android deviceswith different computational abilities. Our testing was centered around using an Android device as a pro-ducer. For each test, the Android device would serve Data in one of two ways when it received an Interest:either by loading pre-signed Data saved in the device’s storage, or by generating and signing Data on-demandfor each Interest. While the test was running, we ran a statistics collection application that gathered informa-tion about the producer application’s CPU usage and NFD’s CPU usage. Each test consisted of a consumerlaptop expressing Interest for 100 MB worth of Data which was served from the Android device. These testswere conducted with two phones: a Samsung phone with a 2.5 GHz quad-core CPU and a Motorola phonewith a 1.2 GHz quad-core CPU.
The results for the 2.5 GHz phone are shown in Table 5.1, and the results for the 1.2 GHz phone are shownin Table 5.2. Our test results showed that both lesser and more powerful devices are able to serve pre-signedData with similar throughput when the request rate is lower. When Interests are sent every 11ms, boththe 1.2 GHz and 2.5 GHz phones serve pre-signed Data with around 5.5 Mb/s throughput. More powerfuldevices also dynamically generate and sign Data at a rate not too far behind serving pre-signed Data; the 2.5GHz phone serves both types of Data with around 5.5 Mb/s throughput when Interests are sent at an 11msinterval. The 1.2 GHz phone requires much more computational time to dynamically generate and serveData than the 2.5 GHz phone, thus the Interest rate needed to be lowered in order to get results for the 1.2GHz phone. Lowering the Interest rate on the 1.2 GHz phone with dynamically served Data caused lowerthroughput than serving pre-signed Data (1.67 Mb/s vs. 5.53 Mb/s). We also saw that requesting Data attoo frequent an interval resulted in more timeouts at each increasing Interest rate; dynamically served Datashowed substantial timeouts on both the 1.2 GHz phone and the 2.5 GHz phone when Interests were sent
34
at a 5ms interval.
On the 2.5 GHz phone, NFD’s CPU usage increased slightly as the Interest rate increased in both Dataserving schemes. On the 1.2 GHz phone, serving pre-signed Data also caused only a slight increase to NFD’sCPU usage. But, when the 1.2 GHz phone served dynamically generated Data, NFD’s CPU usage decreaseddue to the applications inability to serve Data quickly. In that case, NFD actually had to forward less Databack to the consumer application which lowered NFD’s CPU usage.
5.2 Routing Protocols
Our work on NDN routing protocols continued in two parallel directions: conventional link-state routing(Named-data Link State Routing, NLSR [6]) and update-less greedy routing (Hyperbolic Routing, HR [5]).
5.2.1 NLSR
NLSR is a name-based routing protocol that supports multi-path forwarding and uses a hierarchical trustmodel to secure routing information. The global NDN testbed has operated NLSR since August 2014. In thepast year, we worked on refactoring the NLSR code to improve readability and modularity, as well as addingunit tests to provide more thorough test coverage for our code. In addition, we worked with users of NLSRto track down and correct bugs. Through growing deployment of NLSR on the NDN testbed, currently 32nodes and 87 links, we have learned of issues in NLSR’s operation that we would not have otherwise caught,and resolved them successfully. We also continued to adapt NLSR to operate with the newest versions ofboth ndn-cxx and NFD, and released version 0.2.1 on June 30, 2015. Finally, we updated the NLSR paperto reflect our design and implementation changes [6]. We have also used NLSR to conduct our comparisonof link-state and hyperbolic routing algorithms.
5.2.2 Hyperbolic Routing with Adaptive Forwarding Strategy
Hyperbolic routing (HR) presents a potential solution to address the routing scalability problem in NDN. HRdoes not use traditional routing tables or exchange routing updates upon changes in the network topology, butuses pre-assigned hyperbolic coordinates to direct interests toward data. However, it introduces potentialdrawbacks of sub-optimal routes for some destinations. To overcome these drawbacks, we designed andimplemented a new forwarding strategy called Adaptive Smoothed RTT-based Forwarding (ASF) and havebeen evaluating the performance of hyperbolic routing with ASF [5]. Our experiments compare the packetloss ratio, RTT, message overhead, and failure response time of data retrieval under link-state routing andhyperbolic routing with various forwarding strategies, failure conditions, and topologies.
Design of Adaptive Smoothed RTT-based Forwarding (ASF)
To allow for variations in each next hop’s RTT measurement, ASF maintains a Smoothed-RTT (SRTT) foreach next hop. ASF groups and sorts the next hops based on their SRTT performance as well as their abilityto respond with Data. ASF prioritizes next hops that have previously returned Data and that have lowerSRTT measurements. When ASF receives an Interest to forward, it first tries to select the next hop thatis returning Data and has the lowest SRTT measurement. In this way, ASF is able to choose a path thatresults in the lowest delay and that results in Data being returned. If no next hops fit this criteria, ASF willattempt to forward the Interest to any lowest routing cost next hop that has not yet been used. Finally, ifASF still has not picked a next hop, it will select the lowest routing cost next hop that was previously notreturning Data. This logic allows ASF to prioritize both delay and successful Data retrieval when makingforwarding decisions.
Since hyperbolic routing does not respond to short term changes in the network topology, new or recoveredlinks will not be detected if ASF continues to use an existing working path that does not include the link.By periodically probing less used or unused next hops, ASF can learn about the performance of these new
35
Figure 5.4: Delay stretch of HR with ASF over link-state routing (60-second Probing Interval)
Figure 5.5: Loss rate of HR with ASF (60-secondProbing Interval)
or recovering links. When ASF is due for a periodic probe and receives an Interest to forward, it will alsoattempt to select a different next hop than the primary forwarding next hop to probe. ASF will first try toprobe the lowest routing cost next hop that has not yet been used, which allows for the strategy to quicklylearn the performance of new next hops. If all next hops have measurements from their use, ASF will sortthe next hops by their SRTT value if they are returning data and by their routing cost if they are not;next hops that return Data take precedence over next hops that do not. ASF then assigns a probability toeach next hop where next hops that are higher priority receive a higher probability and lower priority nexthops receive a lower probability. ASF will then probabilistically select one of the next hops to forward theprobe Interest. Assigning probabilities in this manner allows ASF to more often probe next hops that havepreviously performed well.
Preliminary Results
Below we present some preliminary results on the forwarding performance and cost of hyperbolic routingwith the support of ASF (HR/ASF) in a small topology. We measured the delay stretch and loss rateof HR/ASF compared to a shortest path routing protocol, in this case link-state. We also compared theoverhead of HR/ASF (i.e., probes in ASF) with that of link-state routing (routing update messages). Weused a snapshot of the real NDN testbed with 22 nodes as the evaluation topology. The routing cost of eachlink in the topology is set to the delay between the two neighboring nodes, and the hyperbolic coordinatesof the nodes are set equal to the coordinates of the AS to which these nodes belong [7]. Testbed nodes thatbelong to the same AS have small disturbances added to make the coordinates unique. Each node advertisesone name prefix and produces ping data under that name prefix, and every node sends ping Interests toevery other name prefix once a second.
We ran evaluations with a probing interval of 30 and 60 seconds for ASF as well as different multi-pathfactors (an upper limit on the number of next hops per name prefix) on the NDN testbed topology. Figure 5.4shows the delay stretch of hyperbolic routing with a 60 second probing interval and a multi-path factor of 4.The median stretch is very close to 1 and the 75th percentile stretch is slightly higher than 1. This showsthat the packet delays under HR are quite close to those under link-state routing except in a small fractionof the cases. Figure 5.5 shows the loss rate for each node under hyperbolic routing (there are no losses inlink-state routing). We can observe that the more next hops available for the strategy, the lower the lossrates, and a multi-path factor of 4 has nearly no loss for all the nodes. In terms of overhead, HR with a60-second probing interval and multi-path factor of 4 has a lower overhead (0.98 pps per node) than thatof link state (1.05 pps per node). Our experimental results on topologies of up to 99 nodes show that HR’sdelay stretch has a median close to 1 and a 95th-percentile around or below 2. Our results also show that theASF probing overhead in dynamic topologies is much lower than the control overhead in link-state routing,because HR does not incur any traditional routing protocol overhead other than probing.
While in our preliminary evaluations HR/ASF performed surprisingly well, there are many factors and
36
scenarios, e.g., larger topology size, mobility, and routing policies, that we have not yet considered, so itis unclear whether the performance and overhead will scale in realistic Internet-scale settings. We alsodid not optimize ASF’s various parameters, such as probing period and probability, dynamically based onobserved performance, or compare it with other previously proposed strategies [3, 8, 9, 11] to identify areasof improvement. These research issues will be addressed in future work.
5.3 Scalable Forwarding
In the second year of the project, the Washington University team led efforts and made substantive con-tributions in four primary areas: scalable forwarding, forwarding strategy, synchronization (discussed inSection 4.1), and testbed development (discussed in Section 6.1).
In the area of scalable forwarding [10], we proposed, implemented, and evaluated a scalable FIB longestname prefix lookup design based on the binary search of hash tables [13]. As reported in last year’s report,we implemented the proposed design in software, using Intel DPDK [4] packet processing framework, anddemonstrated 10 Gbps forwarding throughput with one billion synthetic longest name prefix matching rules,each containing up to seven name components. To the best of our knowledge, this is the largest datasetthat has been studied for longest name prefix lookup. As for in-network caching elements, we exploredContent Store design issues and evaluated the performance of a modified NDN repository based on the Rediskey-value store [12]. Our experimental work has shown that existing storage systems and databases, such asRedis, can be employed in NDN to implement terabyte-scale repositories.
NDN introduces a new forwarding model, in which the forwarding plane can choose between multipleinterfaces when forwarding a packet. This forwarding strategy mechanism brings new opportunities butit also introduces challenges when the application’s performance or correctness is affected by a conflictbetween the application design and the assigned forwarding strategy; in practice, the forwarding strategyis determined by network operators but at the same time application developers make implicit assumptionsabout how packets are forwarded. Our early work [2] demonstrated the impact of the forwarding strategydecision on the performance and correctness of existing NDN applications, and strongly suggests that workremains in defining forwarding strategy as a reliable architectural component of NDN.
5.4 NDN/OSCARS Integration
OSCARS is a bandwidth reservation service available on certain ESnet nodes that enables layer-2, userdriven, end-to-end reservations to isolate large data transfers from other traffic. We have integrated NDNwith OSCARS through a protocol that allows users to specify how fast data is required. If reservationis required, the NDN strategy layer communicates through OSCARS to create a reservation on certainreservation-capable NDN faces. On successful reservation, NDN strategy uses the newly created high-speedpath for data transfer.
5.5 Plans for the Next Year
In the next year, we will develop features to fill some gaps in our architecture, motivated by the requirementsof the network environments, as well as pushing forward the experimentation and documentation.
• Autoconfiguration. Painless autoconfiguration is essential for usability, especially for mobile and in-termittently connected environments. Autoconfiguration involves: (1) establishing NDN connectivity;(2) obtaining appropriate keys; and (3) producers registering name prefixes to attract interests fortheir data. In local environments where NDN can run directly over layer-2, nodes can locally broad-cast Interests to discover neighbor gateways and available data, and figure out where to forward futureInterests by observing from which direction data packets return. When the NDN stack runs as an over-lay on IP, it can perform local NDN gateway discovery in IP multicast-enabled domains or using DNS
37
and DHCP-derived local domains, or use home agent gateways based on pre-configured settings. Nextyear’s effort will build on our preliminary work and develop a complete autoconfiguration functionality.
• Congestion Control. To support high-throughput applications (e.g. scientific big data transfer) andlow-latency applications (NDN-RTC), we need congestion control in the reference implementationand deployed on the testbed. We plan to (1) design mechanisms for congestion detection, back-pressure signaling, multi-path strategies, and consumer rate adjustment; (2) simulate and evaluate thesemechanisms; (3) implement them in NFD, and deploy them on the NDN testbed, and (4) develop libraryAPIs to provide rate control functionality to applications, and integrate them into both applications.
• Hyperbolic Routing (HR). Now that the hyperbolic routing code is stable, we plan to do real testbedexperiments to discover potential issues that may not surface in the emulated environment, and demon-strate its feasibility together with applications.
• Documentation Our most successful documentation effort has been the NFD Developer’s Guide, whichexplains how to interpret, use, and modify the NFD code base. In the next year we will follow thismodel to expand documentation on other important components, particularly NLSR, automatic prefixregistration, and NFD management protocol.
References
[1] Alexander Afanasyev, Cheng Yi, Lan Wang, Beichuan Zhang, and Lixia Zhang. SNAMP: Securenamespace mapping to scale NDN forwarding. In 18th IEEE Global Internet Symposium (GI 2015),April 2015.
[2] Hila Ben Abraham and Patrick Crowley. Forwarding strategies for applications in named data network-ing. In Proceedings of the ACM IEEE Symposium on Architectures for Networking and CommunicationsSystems, 2016.
[3] Raffaele Chiocchetti, Diego Perino, Giovanna Carofiglio, Dario Rossi, and Giuseppe Rossini. Inform: Adynamic interest forwarding mechanism for information centric networking. In Proceedings of the 3rdACM SIGCOMM Workshop on Information-centric Networking, ICN ’13, pages 9–14, 2013.
[4] Intel Corp. DPDK: Data Plane Development Kit, 2016. http://www.dpdk.org.
[5] Vince Lehman, Ashlesh Gawande, Rodrigo Aldecoa, Dmitri Krioukov, Lan Wang, Beichuan Zhang, andLixia Zhang. An Experimental Investigation of Hyperbolic Routing with a Smart Forwarding Plane inNDN. In Proceedings of the IEEE IWQoS Symposium, June 2016.
[6] Vince Lehman, A K M Mahmudul Hoque, Yingdi Yu, Lan Wang, Beichuan Zhang, and Lixia Zhang. Asecure link state routing protocol for NDN. Technical Report NDN-0037, NDN Project, January 2016.
[7] F. Papadopoulos, D. Krioukov, M. Boguna, and A. Vahdat. Greedy Forwarding in Dynamic Scale-FreeNetworks Embedded in Hyperbolic Metric Spaces. In IEEE Conference on Computer Communications(INFOCOM), San Diego, CA, Mar 2010. IEEE.
[8] Haiyang Qian, R. Ravindran, Guo-Qiang Wang, and D. Medhi. Probability-based adaptive forwardingstrategy in named data networking. In Integrated Network Management (IM 2013), 2013 IFIP/IEEEInternational Symposium on, pages 1094–1101, May 2013.
[9] Klaus M Schneider and Udo R Krieger. Beyond network selection: Exploiting access network heterogene-ity with named data networking. In Proceedings of the 2nd International Conference on Information-Centric Networking, pages 137–146. ACM, 2015.
[10] Tian Song, Haowei Yuan, Patrick Crowley, and Beichuan Zhang. Scalable name-based packet forward-ing: From millions to billions. In Proceedings of the 2nd ACM Conference on Information-CentricNetworking, September 2015.
[11] Cheng Yi, Jerald Abraham, Alexander Afanasyev, Lan Wang, Beichuan Zhang, and Lixia Zhang. Onthe role of routing in named data networking. In ACM SIGCOMM ICN Conference, 2014.
38
[12] Haowei Yuan. Scalable NDN Forwarding, 2015. Doctoral Thesis. Washington University in St. Louis,Department of Computer Science & Engineering.
[13] Haowei Yuan and Patrick Crowley. Reliably scalable name prefix lookup. In Proceedings of the ACMIEEE Symposium on Architectures for Networking and Communications Systems, May 2015.
[14] Yu Zhang, Alexander Afanasyev, Jeff Burke, and Lixia Zhang. A Survey of Mobility Support in NamedData Networking. Proceedings of the third Workshop on Name-Oriented Mobility: Architecture, Algo-rithms and Applications (NOM’2016), April 2016.
39
Chapter 6
Evaluation
ContributorsPIs . . . . . . . . . . . . . . . Beichuan Zhang (Arizona), Van Jacobson & Lixia Zhang (UCLA), Lan Wang (Mem-
phis), Christos Papadopoulos (Colorado State University), Patrick Crowley (Washington
University)
Grad Students . . Junxiao Shi, Jerald Abraham, Yi Huang (Arizona); Yingdi Yu, Wentao Shang, Spyridon
Mastorakis (UCLA), Steve DiBenedetto, Chengyu Fan (Colorado State), Haowei Yuan,
Hila Ben Abraham (Washington University)
Undergrads . . . . . . Ashlesh Gawande, Vince S. Lehman (5/2014 – 11/2014) (Memphis)
Staff . . . . . . . . . . . . . John DeHart, Jyoti Parwatikar (Washington University), Vince Lehman (Memphis)
Researcher: Alex Afanasyev (UCLA)
6.1 NDN Testbed: Deployment, Management, Expansion
The NDN team at Washington University operates and manages the global NDN testbed, which as of March2016, has 31 nodes in 14 countries. The Washington University team also manages integration testing anddeployment activities. They have enhanced the monitoring tools for the NDN Testbed [1], and updated theNDN real time testbed usage mapping tool to use a pure NDN paradigm. A central server on the WashingtonUniversity campus sends NDN Interests to client daemons that run on each of the testbed nodes. Theseclient daemons collect usage data and return it as content in data packets to the server. A web page athttp://ndnmap.arl.wustl.edu displays the usage data.
6.1.1 Lessons Learned from Testbed Use
During NLSR’s development we found use of the NDN testbed valuable for exposing and debugging issuesin implementation. In a controlled test environment, certain problems and bugs occur less frequently thanin a real testbed deployment. For example, we encountered an issue in NLSR when a router, configured asa neighbor for other routers, was not enabled for a long period of time. This bug prevented other routers’name prefixes from having their expiration time extended. We also observed a situation where a router triedto fetch its own outdated Link State Advertisements (LSA) due to updates it received from elsewhere in thenetwork. This put the router in an infinite loop where it continuously tried and failed to retrieve its ownoutdated LSA. Further, we discovered a sequence number problem that we detected in the testbed networkdue to an incorrect bit mask used to copy the name LSA sequence number. For each of these problems, weused the logs collected from the testbed to track down the cause of the issue. We had not considered testcases for these scenarios and due to real world use in the testbed, we were able to discover and diagnosethese serious bugs in NLSR.
40
6.2 Mini-NDN
In the past year, we transitioned our development of the Mini-NDN emulator from a prototype to publiclyreleased software. We added a user-friendly experimentation framework for users to define and run NDNexperiments using simple syntax; the framework includes basic experiment examples for reference. We wantMini-NDN to be as simple to use for as many users as possible, so we wrote and released documentation forthe major components of Mini-NDN and created a mailing list for user support. We released version 0.1.0of Mini-NDN on July 15, 2015 and the current version 0.1.1 on November 4, 2015 (https://github.com/named-data/mini-ndn/).
At the 2nd NDN Hackathon, we worked on a project to simplify statistic collection and data analysisfor Mini-NDN’s users. The Hackathon project moved the status information for each node in the networkfrom plain console output to a web interface. A user’s browser connects to the Mini-NDN network to gatherinformation. The interface includes reporting the status of NFD and NLSR, real-time metrics for each link’sbandwidth consumption, and a dynamic graph that plots measurements recorded by NFD (e.g., number ofInterests, number of PIT entries, etc.). The project won the Best Internal Impact prize for its potential inimproving the analysis of various NDN applications for the NDN team.
References
[1] Zeev Lailari, Hila Ben Abraham, Ben Aronberg, Jackie Hudepohl, Haowei Yuan, John D. DeHart, JyotiParwatikar, and Patrick Crowley. Experiments with the Emulated NDN Testbed in ONL. In Proceedingsof the 2nd ACM Conference on Information-Centric Networking. ACM, 2015.
41
Chapter 7
Impact: Education
ContributorsPIs . . . . . . . . . . . . . . . Christos Papadopoulos (CSU), Lan Wang (Memphis), Beichuan Zhang (Arizona), Van
Jacobson, Jeff Burke, Lixia Zhang (UCLA)
7.1 Education Efforts
The NDN group continues to produce a significant amount of educational material, which can be found atthe following URL: http://www.named-data.net/education.html.
7.1.1 UCLA
Lixia Zhang taught a graduate course “CS217A: Internet Architecture & Protocols” during Winter 2016quarter, where she devoted three lectures on an introduction to NDN and made compared NDN with today’sTCP/IP protocol architecture. About half of the students in the class signed up for optional term projectson NDN research topics, which they carried over to CS217B in Spring 2016 quarter to finish up.
During the Spring 2015 and Spring 20116 quarters, Lixia Zhang taught CS217B on “Advanced Topicsin Internet Research”, a graduate seminar course focused on the NDN architecture design and applicationdevelopment. In addition to covering NDN design literature, the course traces historical architectural ideasfrom a series of research papers spanning the last few decades (e.g. [1, 4, 2]). Students also learned aboutother architectural designs under NSF’s FIA program, in particular eXpressive Internet Architecture [5] andMobility First [6]. In parallel to in-class discussions, the students carried out research projects on NDNdesign and development. The students finished the following projects during Spring 2015 quarter. The firstthree projects utilized named data communication to enable serverless distributed applications.
• Shared WhiteBoard Over Named Data Network (NDN) on Android,
• Photo Sharing NDN Applications on Android, and
• Porting a turn-based Android game to NDN (Android).
• Wireshark Dissector for NDN Packet Format, now used by the NDN network management toolkit.
• Android Key Manager, now part of the NDNfit implementation (Section 2.2).
• nTorrent: BitTorrent over NDN – now evolved into a complete design (please see nTorrent projectunder Spring 2016).
• NDN Security Certificate Logger Design to support long-lived data validation, now incorporated intothe NDN signature logger implementation, reported in a paper submitted to ICN 2016.
• NDN Security Schema Design And Implementation, now incorporated into the NDN security library.
42
Three of the above projects became student master projects that fulfilled the M.S. degree requirements.
Research projects carried out during Spring 2016 quarter include the following:
• Mitigating content poisoning attacks in NDN, extending results in [3].
• Evaluation of the design and performance of ChronoSync 2.0 using ndnSIM (see also Section 4).
• Implementing NDN Sync Protocol on RIOT OS for Internet of Things.
• Local NDN hub discovery for automatic NDN network attachment.
• Secure poker games on an Named Data Network, which used NDN’s security primitives to address adifficult application scenario.
• Implement nTorrent: A Peer-to-Peer file download system over NDN. We expect to experiment withthis new application over the NDN testbed in June 2016.
• NDN Open mHealth pilot applications, as part of the NDNfit (Section 2.2) development efforts.
7.1.2 University of Memphis
Lan Wang supervised Alejandro Gil Torres, an exchange student from Spain who did his undergraduatethesis on NLSR. The student implemented additional statistics collection to the NLSR code and used thesestatistics to evaluate the performance impact of several NLSR default timer value settings.
Lan also gave a seminar talk at University of Mississippi on NDN, titled “Architectural Development andRouting Design in Named Data Networking” (http://www.cs.olemiss.edu/node/435).
7.1.3 Colorado State University
CSU continued to teach NDN and assign NDN-related programming assignments in the graduate networkingcourse. We did not include NDN in the undergraduate networking course in the Fall 2015 because PIPapadopoulos was on sabbatical. PI Papadopoulos included a strong NDN component in his graduate classin Spring 2016, which used NFD and the ndn-cxx C++ library. The class included an implementation of acontent distribution network using IP and then using NDN. There were strong comments from the studentsabout how much easier it was to implement the project with NDN. Graduate students working on NDNtaught part of the class. The class used project templates developed at CSU and published on the NDN website.
Papadopoulos gave a webinar on NDN at ENCITE (Enhancing Cyberinfrastructure by Training andEngagement) titled “An Overview of NDN” on 11 March 2016. The recording can be found at https://
events-na12.adobeconnect.com/content/connect/c1/1282664749/en/events/event/shared/default_
template/event_registration.html?sco-id=1484223888&_charset_=utf-8.
7.1.4 Washington University in St. Louis
John Dehart taught Introduction to Networking in Fall 2015 and had Hila Ben Abraham, a graduate student,give a guest lecture on NDN during the course.
7.2 NDN Tutorial at ICN 2015
During ACM’s Information-Centric Networking 2015 conference, we held a full day tutorial on synchroniza-tion and security in Named Data Networking (NDN). This tutorial shared important architectural conceptsthat we are exploring in these areas, the software we have built to perform these tasks, and remaining openissues. In particular, it emphasized how the existing open source toolset provides a platform for exploringthe open research questions. The tutorial introduced conference participants to emerging features of theavailable toolsets. In addition to referencing a variety of existing examples, the tutorial used the creation
43
of a modern browser-based application to illustrate writing NDN applications, leveraging 1) multi-partysynchronization, 2) schematized trust, 3) encryption-based access control.
The main objective of the tutorial was to introduce the practical role of sync as a communication protocol,available tools, and envisioned use cases. Specifically, we wanted students to understand how to move froma general sync concept to specific sync designs, and the role that sync plays in the sample application. Wegave an introduction and brief comparison of the application design patterns based on the current prototypesof applications, including ChronoShare, NLSR, NDNFit.
7.3 NDN Weekly Seminars
During this reporting period we continued our biweekly NDN seminar series among participating universities.NDN seminars cover a wide range of topics that reflect ongoing NDN design and development efforts andpromote inter-campus exchanges and collaborations. Most speakers are graduate students from differentuniversities, presenting their work to a broad audience to exchange ideas, solicit feedback, and explorecross-campus collaboration opportunities. In 2014 Shiguang Wang, a UIUC graduate student, and A K MMahmudul Hoque, a Memphis graduate student, collected topics and created the schedule. In 2015 JongdeogLee, a UIUC graduate student started coordinating the seminars, followed by Spyros Mastorakis at UCLA.
This year’s seminars took place from 5/15 - 4/16 and covered the following topics:
• May 27: Prof. Pedro de las Heras Quires (UCLA Visiting Scholar), ”Application of Macaroons fordistributing encryption keys and providing access control in NDN applications”
• July 15th Ashlesh Gawande (Univ. of Memphis), ”Mini-NDN: A light weight emulation tool for NamedData Networking”
• August 12th Susmit Shannigrahi and Chengyu Fan (Colorado State Univ.), ”NDN for Scientific DataApplications”
• August 26th Eva M. Castro and Pedro de las Heras Quiros (Universidad Rey Juan Carlos, Spain),”Redesign of ChronoSync”
• October 7th Ryan Bennett (Colorado State University), ”NDN-IO: Rapid Prototyping for Node.js andBrowse”
• October 28th Jongdeog Lee (UIUC), ”InfoMax-An Information Maximizing Transport Layer Protocolfor Named Data Networks”
• December 2nd Rodrigo Aldecoa (Northeastern University), ”Hyperbolic Routing (Theory)”
• December 16th Vince Lehman (University of Memphis), ”Hyperbolic Routing (Implementation)”
• 10 February 2016 Yingdi Yu (UCLA), ”Schematizing Trust in Named Data Networking”
• 24 February 2016 Peter Gusev (UCLA REMAP), ”Real-Time Videoconferencing over NDN”
• 2 March 2016 Susmit Shannigrahi (Colorado State University), ”Scientific Data Applications in NDN”
• 16 March 2016 Ben Murphy (University of Memphis), ”Performance measurements of Android devicesin NDN”
References
[1] David D Clark and David L Tennenhouse. Architectural considerations for a new generation of protocols.ACM SIGCOMM Computer Communication Review, 20(4):200–208, 1990.
[2] David D. Clark, John Wroclawski, Karen R. Sollins, and Robert Braden. Tussle in cyberspace: definingtomorrow’s internet. In ACM SIGCOMM, 2002.
[3] Stephanie DiBenedetto and Christos Papadopoulos. Mitigating Poisoned Content with Forwarding Strat-egy. Proceedings of the third Workshop on Name-Oriented Mobility: Architecture, Algorithms and Ap-plications (NOM’2016), April 2016.
44
[4] Sally Floyd, Van Jacobson, Steven McCanne, Lixia Zhang, and Ching-Gung Liu. A reliable multicastframework for light-weight sessions and application level framing. In SIGCOMM, 1995.
[5] David Naylor, Matthew K. Mukerjee, Patrick Agyapong, Robert Grandl, Ruogu Kang, and MichelMachado. XIA: Architecting a More Trustworthy and Evolvable Internet. ACM SIGCOMM ComputerCommunication Review (CCR), 44(3):50–57, Jul 2014.
[6] Arun Venkataramani, James Kurose, Dipankar Raychaudhuri, Kiran Nagaraja, Suman Banerjee, andMorley Mao. MobilityFirst: A Mobility-Centric and Trustworthy Internet Architecture. ACM SIGCOMMComputer Communication Review (CCR), 44(3):74–80, Jul 2014.
45
Chapter 8
Impact: Expansion of NDNCommunity
The NDN project is attracting ever-increasing attention from the global networking community. The PIsparticipated in conferences and speaking engagements, as listed below, and engaged with a variety of internsand visiting researchers from universities and industry. These formal and informal efforts have helped todisseminate research results and project ideas, as well as practical information about the NDN code base.
8.1 The Second NDN Community meeting
The second NDN Community Meeting was held at UCLA in Los Angeles, California on September 28–29,2015 [2]. The meeting provided a platform for the attendees from 63 institutions across 13 countries toexchange their recent NDN research and development results, to debate existing and proposed functionalityin NDN forwarding, routing, and security, and to provide feedback to the NDN architecture design evolution.
8.2 Expansion of the NDN Consortium and Testbed
The NDN consortium established in 2014 continued its expansion, adding two industrial and five academicmembers:
1. ViaSat
2. Juniper Networks
3. Federal University of Par, Brazil
4. National Institute of Technology Karnataka, Surathkal
5. Northeastern University
6. TNO, the Netherlands Organization for Applied Scientific Research
7. University of Maryland, College Park
Over the last year we added new nodes to the NDN testbed [1] growing it to 31 Nodes with 84 links:
1. the Norwegian University of Science and Technology (NTNU)
2. the Korea Institute of Science and Technology Information (June 15)
46
3. COPELABS (Cognition and People Centric Computing) at University of Lusofona in Portugal
4. the University of Indonesia, Depok Indonesia.
5. University of Goettingen,
6. University of Indonesia,
7. Osaka University,
8. University of Minho in Portugal.
8.3 The 2nd ACM Information Centric Networking Conference
PI Van Jacobson presented the keynote at the 2nd ACM Conference on Information-Centric Networking.The team presented four papers.
8.4 NDN-Related Workshops
Listed below are the NDN-related workshops held at different venues:
1. The Third Workshop on Name-Oriented Mobility: Architecture, Algorithms and Applications (NOM’2016),in conjunction with IEEE INFOCOM, San Francisco, CA, April 11, 2016.
The NDN team presented two papers at this workshop.
2. Workshop on Multimedia Streaming in Information-/Content-Centric Networks (MuSIC 2016), in con-junction with IEEE INFOCOM, San Francisco, CA, April 11, 2016.
3. Workshop on Content-Centric Networking (CCN 2015), in conjunction with IEEE International Con-ference on Mobile Ad hoc and Sensor Systems, Dallas, TX, USA, October 19, 2015
The NDN team presented one paper at the workshop.
4. Workshop on Information Centric Networking Solutions for Real World Applications (ICNSRA), inconjunction with IEEE GlobeCom 2015, San Diego, CA, USA, December 6, 2015.
47
Chapter 9
NDN Presentations
Listed below are presentations given by NDN-NP team members during the second year of the project.
1. Alex Afanasyev, “Named Data Networking: Data-Centric Future of the Internet”. Aerospace, May,2016
2. Alex Afanasyev, “Supporting Mobility in Named Data Networking”, ICNRG Meeting, January 2016.
3. Alex Afanasyev, “Shaping a New Architecture by Architectural Principles”, ICNRG Meeting, Novem-ber 2015.
4. Alex Afanasyev, “NDN protocol development: status of reference implementations, supporting softwarereleases, open architecture research issues”, ICNRG Meeting, October 2015.
5. Alex Afanasyev, “Schematized Trust: Design and Application”, NDN Community Meeting, September2015
6. Alex Afanasyev, “Trust Schema: Name-Based Trust Management”, NDN Tutorial at ICN’2015, Septem-ber 2015
7. Lan Wang, “Architecture Development and Routing Design in Named Data Networking,” Departmentof Computer and Information Science, University of Mississippi, Oct. 2015
8. Jeff Burke, “NDN “NP” Application Update: Building Automation & Management / Io,” OsakaUniversity Murata Lab, Osaka, Japan, November 12, 2015.
9. Jeff Burke,“Named Data Networking,” Panasonic Advanced R&D, Osaka Japan, November 11, 2015.
10. Jeff Burke,“NDN Network Environments Update”, NSF FIA PI Meeting, Arlington, VA, 2015
11. Jeff Burke, “ICN Roadmaps for the next 2 years,” ACM ICN 2015, Panel participant with Cisco,Orange, ESnet, PARC, Huawei, September 2015, San Francisco, CA.
12. Jeff Burke, “The Future of the Internet is the Future of Storytelling,” NDN Community Meeting, LosAngeles, CA, September 29, 2015.
13. Jeff Burke, “From the Internet of Things to the Internet of Experiences,” ICCCN CyberphysicalSystems Panel, Las Vegas, NV, August 3, 2015.
14. Jeff Burke, “ICN as an Enabler for New Forms of Multimedia Experience,” IEEE ICME MuSICWorkshop, Invited Keynote and panel moderator, Torino, Italy, July 3, 2015.
15. Jeff Burke, Small Data CRI 2015, Invited workshop participant for Cornell Tech Small Data workshop,New York, June 15-16, 2015.
48
16. Jeff Burke, Invited panel participant for Network Architecture panel with Mark Stapp of Cisco, GQWang of Huawei, and Ignacio Solis of PARC, CCNxCon, San Jose, May 21, 2015.
17. kc claffy, “A Brief History of a Future Internet”, Usenix LISA 2015, Washington DC, November 13,2015.
18. kc claffy and Lixia Zhang, “A Brief History of a Future Internet”, Usenix LISA Conversations, livetalk show, YouTube LISA Conversations Channel, April 26, 2016.
19. Patrick Crowley, “Named Data Networking, New Frontiers in Network, MIT. Cambridge, MA, April30, 2015.
20. Patrick Crowley, “Global NDN Testbed,” NDN Community Meeting, UCLA. Los Angeles, CA, Septem-ber 29, 2015.
21. Patrick Crowley, “NDN Startups,” NDN Community Meeting, UCLA. Los Angeles, CA, September29, 2015.
22. Patrick Crowley, “Named Data Networking,” Internet2 TechEx Conference. Cleveland, OH, October5, 2015.
23. Patrick Crowley, “Named Data Networking,” Washington University OIN Conference. St. Louis, MO,October 20, 2015.
24. Christos Papadopoulos, “Named Data Networking: An Internet Architecture for the Future.”, Invitedtalk, ESGF meeting, Monterey CA, Dec 2015.
25. Christos Papadopoulos, “Named Data Networking: An Internet Architecture for the Future.”, Invitedtalk, LHCOPN-LHCONE meeting, Amsterdam NL, Oct 2015.
26. Christos Papadopoulos, “Named Data Networking: An Internet Architecture for the Future.”, Invitedtalk, University of Memphis, Oct 2015.
27. Christos Papadopoulos, “Named Data Networking: An Internet Architecture for the Future.”, Keynotepresentation, NSF SwitchOn Workshop, Sao Paolo, Brazil, Oct 2015.
28. Christos Papadopoulos, “Managing Scientific Data with Named Data Networking”, NSF PI meeting,Austin TX, Sept 2015
29. Christos Papadopoulos, “A Catalog for Scientific Data.”, CERN, Switzerland, July 2015.
30. Beichuan Zhang, “Information-Centric Internet of Things: Driving the Future Network Architecture,”Beijing Jiao Tong University, June 2015
31. Beichuan Zhang, “Named Data Networking (NDN),” Beijing University of Post and Telecommunica-tions, June 2015
32. Beichuan Zhang, “NDN Live Video Broadcasting over Wireless LAN,” IEEE ICCCN, Aug 2015
33. Beichuan Zhang, “Named Data Networking (NDN),” Future Network Development and InnovationForum, Dec 2015
34. Beichuan Zhang, “Routing in Named Data Networking,” NIST, Feb 2016
35. Lixia Zhang“Evolving Internet into the future via Named Data Networking,” Jilin University, China,September 2015.
36. Lixia Zhang“Moving Internet into Future via Named Data Networking,” Fujitsu Corporation, Japan,October 2015.
37. Lixia Zhang“Named Data Networking,” Keio University, Japan, October 2015.
49
38. Lixia Zhang“Named Data Networking: the Design of a New Internet Architecture,” Waseda University,Japan, October 2015.
39. Lixia Zhang“NDN Design and development: recent progress,” Workshop on Research Activities andFuture of EU/US/JP ICN Projects, Tokyo, Japan, October 2015.
40. Lixia Zhang“Networking via Named Data,” Mitre Corporation, December 2015.
41. Lixia Zhang“Securing the Internet by Securing Data Directly,” National Chiao Tung University, Tai-wan, December 2015.
42. Lixia Zhang“New Applications via Opportunistic Peer-to-Peer Wireless Communications,” NSF Wire-less Cities Workshop, February 2016.
43. Lixia Zhang“Named Data Networking of Things,” US-Europe Workshop on the Next Generation In-ternet of Things, March 2016.
44. Lixia Zhang“Looking back, looking forward: why Internet needs a new protocol architecture,” UCSD,April 2016.
45. Lixia Zhang“Challenges in the Internet of Things Realization,” PKU-UCLA Joint Research InstituteIn Science And Engineering 7th Annual Symposium, May 2016.
References
[1] The NDN project testbed. http://www.named-data.net/testbed.html, 2012.
[2] Alexander Afanasyev, Yingdi Yu, Lixia Zhang, Jeff Burke, kc claffy, and Joshua Polterock. The secondnamed data networking community meeting (NDNcomm 2015). ACM SIGCOMM Computer Communi-cation Review, January 2016.
50
Chapter 10
Publications
Listed below are publications by NDN-NP team members during the second year of the NP project (1 May2015 – 30 April 2016).
[1] Vince Lehman, Ashlesh Gawande, Rodrigo Aldecoa, Dmitri Krioukov, Lan Wang, Beichuan Zhang, andLixia Zhang. An Experimental Investigation of Hyperbolic Routing with a Smart Forwarding Plane inNDN. In Proceedings of the IEEE IWQoS Symposium, June 2016.
[2] Peter Gusev, Zhehao Wang, Jeff Burke, Lixia Zhang, Eiichi Muramoto, Ryota Ohnishi, and TakahiroYoneda. Real-time streaming data delivery over Named Data Networking (invited paper). IEICETransactions, May 2016.
[3] Yu Zhang, Alexander Afanasyev, Jeff Burke, and Lixia Zhang. A Survey of Mobility Support in NamedData Networking. Proceedings of the third Workshop on Name-Oriented Mobility: Architecture, Algo-rithms and Applications (NOM’2016), April 2016.
[4] Stephanie DiBenedetto and Christos Papadopoulos. Mitigating Poisoned Content with ForwardingStrategy. Proceedings of the third Workshop on Name-Oriented Mobility: Architecture, Algorithms andApplications (NOM’2016), April 2016.
[5] Wentao Shang, Adeola Bannis, Teng Liang, Zhehao Wang, Yingdi Yu, Alexander Afanasyev, JeffThompson, Jeff Burke, Beichuan Zhang, and Lixia Zhang. Named Data Networking of things. InProceedings of 1st IEEE International Conference on Internet-of-Things Design and Implementation(IoTDI’2016), April 2016. (Invited paper).
[6] Alexander Afanasyev, Yingdi Yu, Lixia Zhang, Jeff Burke, kc claffy, and Joshua Polterock. The secondnamed data networking community meeting (NDNcomm 2015). ACM SIGCOMM Computer Commu-nication Review, January 2016.
[7] Chengyu Fan, Susmit Shannigrahi, Steve DiBenedetto, Catherine Olschanowsky, Christos Papadopou-los, and Harvey Newman. Managing scientific data with Named Data Networking. In Proceedings ofthe Fifth International Workshop on Network-Aware Data Management, November 2015.
[8] Alexander Afanasyev, Zhenkai Zhu, Yingdi Yu, Lijing Wang, and Lixia Zhang. The Story ofChronoShare, or How NDN Brought Distributed Secure File Sharing Back. In Proceedings of IEEEMASS 2015 Workshop on Content-Centric Networks, October 2015.
[9] Yingdi Yu, Alexander Afanasyev, David Clark, kc claffy, Van Jacobson, and Lixia Zhang. SchematizingTrust in Named Data Networking. In Proceedings of the 2nd International Conference on Information-Centric Networking, September 2015.
[10] Ilya Moiseenko, Lijing Wang, and Lixia Zhang. Consumer/producer communication with applica-tion level framing in Named Data Networking. In Proceedings of the 2nd International Conferenceon Information-Centric Networking, September 2015.
51
[11] Peter Gusev and Jeff Burke. NDN-RTC: Real-time videoconferencing over Named Data Networking. InProceedings of the 2nd International Conference on Information-Centric Networking, September 2015.
[12] Tian Song, Haowei Yuan, Patrick Crowley, and Beichuan Zhang. Scalable name-based packet forward-ing: From millions to billions. In Proceedings of the 2nd ACM Conference on Information-CentricNetworking, September 2015.
[13] Jongdeog Lee, Akash Kapoor, Md Tanvir Al Amin, Zhehao Wang, Zeyuan Zhang, Radhika Goyal, andTarek Abdelzaher. InfoMax: An information maximizing transport layer protocol for Named DataNetworks. In 24th International Conference on Computer Communication and Networks (ICCCN),August 2015.
[14] Giulio Grassi, Davide Pesavento, Giovanni Pau, Lixia Zhang, and Serge Fdida. Navigo: Interest for-warding by geolocations in vehicular Named Data Networking. In IEEE 16th International Symposiumon a World of Wireless, Mobile and Multimedia Networks (WoWMoM), June 2015.
[15] Haowei Yuan and Patrick Crowley. Reliably scalable name prefix lookup. In Proceedings of the ACMIEEE Symposium on Architectures for Networking and Communications Systems, May 2015.
[16] Fu Wenliang, Hila Ben Abraham, and Patrick Crowley. Synchronizing namespaces with invertible bloomfilters. In To appear in ANCS 2015, 2015.
NDN Technical Reports
All the reports are available online at http://named-data.net/publications/techreports/
[1] Minsheng Zhang, Vince Lehman, and Lan Wang. PartialSync: Efficient Synchronization of a PartialNamespace in NDN. Technical Report NDN-0039, NDN, June 2016.
[2] Yingdi Yu, Alexander Afanasyev, and Lixia Zhang. NDN DeLorean: An Authentication System for DataArchives in Named Data Networking. Technical Report NDN-0040, NDN, May 2016.
[3] Wentao Shang, Yingdi Yu, Ralph Droms, and Lixia Zhang. Challenges in iot networking via TCP/IParchitecture. Technical Report NDN-0038, NDN, February 2016.
[4] Vince Lehman, A K M Mahmudul Hoque, Yingdi Yu, Lan Wang, Beichuan Zhang, and Lixia Zhang. Asecure link state routing protocol for NDN. Technical Report NDN-0037, NDN Project, January 2016.
[5] Wentao Shang, Yingdi Yu, Teng Liang, Beichuan Zhang, and Lixia Zhang. NDN-ACE: Access control forconstrained environments over Named Data Networking. Technical Report NDN-0036, NDN, December2015.
[6] A. Bannis and J. Burke. Creating a secure, integrated home network of things with Named Data Net-working. Technical Report NDN-0035, NDN, 2015.
[7] Yingdi Yu, Alexander Afanasyev, and Lixia Zhang. Name-based access control. Technical Report NDN-0034, Revision 2, NDN, January 2016.
[8] P. Gusev and J. Burke. NDN-RTC: Real-time videoconferencing over Named Data Networking. TechnicalReport NDN-0033, NDN, 2015.
[9] NFD Team. NFD developer’s guide. Technical Report NDN-0021, Rev. 6, NDN, March 2016.
52