- NDN-LITE is
- Design Principles
- Relations to Existing NDN Packages
- Differences from NFD + NDN-CXX
- Differences from NDN-RIOT (broken)
- Differences from CCN-LITE
- Where we are now
- Application Support Component
- Network Component
- Utilities Component
- Adaptation Component (Platform Dependent)
- Technical Features
- Codebase and Packages
- NDN-LITE Core Library
- NDN-LITE Based Packages
- Why choose this way?
- An Example of a Package: Nordic Package
- Quick View of Current Packages
- nRF52 package (broken)
- POSIX package (highly recommended)
- Before Starting
- 1. Download the NDN-Lite into your project
- 2. Preparation for platform adaptation
- 3. Create platform adaptation
- 4. Add source files and headers into your IoT project's Makefile or equivalent.
- 5. Compilation
Clone this wiki locally
The NDN-Lite library implements the Named Data Networking Stack with the high-level application support functionalities and low-level OS/hardware adaptations for Internet of Things (IoT) scenarios.
- Designed to run on resource constrained devices
- A framework for network systems with built-in highly level system modules for security bootstrapping, service discovery, access control, etc.
- A development platform for IoT application developers
- A System framework
- Universality for different platforms (that supports raw C)
- With minimal memory overhead and zero dynamic memory allocation
- Minimal memory and better efficiency
- Runs application and NDN forwarder within the same process
- Fit into IoT platforms that only support single thread/process
NDN-LITE is designed to be an IoT system framework that can work with all IoT platforms in raw C.
With system framework principle in mind, NDN-LITE has application support to take care of bootstrapping, resource discovery, and access control.
- Designed to be an IoT system framework: bootstrapping, access control, etc.
- Lightweight forwarder with reduced functionalities: no support of forwarding hint, RIB management, etc.
- Lightweight encoding/decoding: reduced memory overhead
- The original goal to renew/improve NDN-RIOT codebase.
- Designed not only for RIOT but as a framework that can work with all IoT platforms (raw C)
- Doesn't support multi-process design of forwarder and applications
- Designed to be an IoT system framework
- Can be adapt to any platform that supports C. So far the supported platforms are:
- nRF52 boards (broken)
- Rasberry PIs
Our team is actively maintaining the codebase and exploring the design and implementation for the remaining issues.
The architecture of NDN-Lite library is independent of the OS and the development kit. The exposed API makes the library easily pluggable to IoT Software Development Kit (SDK) and IoT Operating Systems, by creating a thin adaptation layer between the platform and the NDN-Lite.
The library was designed to provide more than core NDN network stack. The library allows applications to directly integrate supporting functionalities including Access Control, Service Discovery, Schematized Trust and so on.
The following block diagram presents the architecture of the project.
Boostrapping: To obtain identity certificate and trust anchor.
Service Discovery: To discover available services around and advertise one's own services.
Pub Sub: To subscribe to services and publish new content to one's own services.
Access Control:To protect data confidentiality and grant access rights to authorized identities. Old version is now removed. New version work in progress.
Schematized Trust: To only execute commands from authorized identities.
Forwarder: In the same process as the application. No memory copy in packet processing. Content Store is currently not supported given the limited RAM of most IoT devices.
NDN Packet Encoding: Interfaces for Interest Data packet encoding/decoding.
Face: Abstract face for network interface. Will be implemented by platform-dependent adaptations
Key Storage: In-memory storage to keep device's identity certificate, trust anchor.
Clock: To provide time support, especially for network timeout. It has two unified interfaces that need to be implemented
time()to get the time of steady clock
delay()to sleep for a period of time
Message Queue: An event queue which keeps event from both NDN forwarder and an application. This event queue will be run by a main loop of the program.
Fragmentation: To fragment/assemble NDN's wire format packets into/from byte chunks to fit link layer MTUs.
Crypto Support: To support crypto, including SHA2 module, AES module, ECC module, HMAC module, and RNG module with default backend.
Face adaptation: To extend the abstract face to real link layer interfaces supported by different platforms: IEEE 802.15.4, BLE, LoRa.
Clock adaptation: Provide the realization of two unified interfaces
Crypto adaptation: The adaptation is to provide a different realization of crypto modules to achieve stronger security (hardware TPM, hardware RNG) and higher efficiency (hardware ECC signing/verification). This is optional. If no crypto adaptation, NDN-LITE's default realization will be used.
In the current version, this library implements the following features:
- NDN Encoding Decoding is compatible with NDN TLV format 0.3.
- Abstract Face that can be inherited by OS/SDK specific adaptations.
- DirectFace to support app-forwarder communication for single-thread applications.
- DummyFace for test only.
- Fragmentation: reuses the ndn-riot fragmentation header (3 bytes header)
0 1 2 3 0 1 2 3 8 15 23 +-+-+--+----+----------------------+ |1|X|MF|Seq#| Identification | +-+-+--+----+----------------------+ First bit: header bit, always 1 (indicating the fragmentation header) Second bit: reserved, always 0 Third bit: MF bit, 1 indicating the last frame 4th to 8th bit: sequence number (5 bits, encoding up to 31) 9th to 24th bit: identification (2-byte random number)
- Crypto front end which supports OS/SDK specific crypto back-end implementation.
- A default pure-software crypto backend using tinycrypt and micro-ecc.
- Interest and Data signing and verification.
- AES Encrypted Content TLV for Data packet. (doesn't exist in ndn-cxx)
./encodedirectory: NDN packet encoding and decoding.
./forwarderdirectory: NDN lightweight forwarder implementation and Network Face abstraction.
./facedirectory: Dummy face
./securitydirectory: Security support.
./app-supportdirectory: Access Control, Service Discovery, and other high-level modules that can facilitate application development.
./utildirectory: Tools used in forwarder, including time and message queue.
A "complete" package contains NDN-LITE with adaptations. Apatations should provide realization of time, network interfaces defined in core NDN-LITE.
Because this "NDN-LITE + Adaptation" structure is to allow NDN-LITE to work with different platforms. In current design, most common functionalities are included in the NDN-LITE core library, and least platform-dependent realization is left to adaptation.
sha256to replace NDN-LITE default version
./802154-adaptation: Construction of NDN-LITE IEEE 802.15.4 face
./ble-adaptation: Construction of NDN-LITE Bluetooth Low Energy face
./uniform-time: Adapt to Nordic local time support
./ndn-lite: NDN-LITE core library
- NDN-LITE Codebase
- Face Adaptation
- BLE Face
- IEEE 802.15.4 Face
- Crypto Adaptation
- RNG Adaptation
- SHA Adaptation
- NDN-LITE Codebase
- Face Adaptation
- UDP Face
- Unix Socket Face
- Crypto Adaptation
- RNG Adaptation
Please check if your platform are already supported by existing packages. If so, those would be helpful to start with and you can jump to Step4
Warning: You are only supposed to use the adaptation layer that is designed for your platform and the face implementation(s) that can work with your platform. Using incompatible adaptation and faces will lead to compilation failures.
git clone https://github.com/named-data-iot/ndn-lite
Check what communication technologies (e.g., Unix sockets, 802.15.4, BLE) would be used in your project. They will be adpated to the NDN-Lite face-forwarder system.
Check if you're going to other security-backend to replace default security-backend. Usually platform-specific backend are preferred, to achieve the best performance.
Warning: NDN-Lite does have default RNG, but it's fake a RNG which always fails. It is highly recommended to use platform-specific RNG replace it.
./adaptation folder, in the same directory of
./ndn-lite, and put face implementation there. You need to implement a new Face structure in the header and source files. Developers need to make sure that the first structure element is an
ndn_face_intf instance. In the source file, implement the functions defined in the
ndn_face_intf structure. In the header file, create a construction function to create a face instance or get the face instance if the face is a singleton. The function pointers binding should also be done in this function. APIs are defined in
./adaptation folder, create
./security folder, and put implementation you want to replace corresponding default backend with there. Backend APIs are defined header files in
./ndn-lite/security (HMAC, ECC, RNG, AES, SHA256). Don't forget to use
register_platform_security_init to register your backend before security module initialization. Make sure
ndn_security_init be after
register_platform_security_init, otherwise your platform backend won't be loaded.
- (Recommended) POSIX Adaptation: Unix Sockets, UDP, and POSIX-RNG backend.
- Nordic SDK Adaptation with
ndn-nrf-ble-face: The files under
./adaptation/ndn-nrf-ble-adaptation/is the adaptation layer and the files
./face/ndn-nrf-ble-face.hare the face implementation.
- NRF 802154 driver Adaptation with
ndn-nrf-802154-face: The files under
./adaptation/ndn-nrf-802154-driver/is the adaptation layer and the files
./face/ndn-nrf-802154-face.hare the face implementation.
An example would be:
# In the MakeFile SRC_FILES := \ ndn-lite/encode/data.c \ ndn-lite/encode/decoder.c \ ndn-lite/encode/encoder.c \ ndn-lite/encode/interest.c \ ... # and all the needed files under ./encode, ./security, ./forwarder, ./face, ./app-support, and ./adaptation CFLAGS += -I/path/to/ndn-lite
If you're going to use RNG (from your platform backend) in your project, please
-DFEATURE_PERIPH_HWRNG or do equivalent thing. Otherwise default ECC backend will still do deterministic signing, which is less strong than normal signing.