-
Notifications
You must be signed in to change notification settings - Fork 17
Overview
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.
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.

In the current version, this library implements the following features:
NDN Layer:
- NDN Encoding Decoding, which is compatible with NDN TLV format 0.3.
- NDN IoT Forwarder, a lightweight forwarding module implementation for IoT. Will support Content Store in the near future.
- 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)
Security:
- Crypto front end which supports OS/SDK specific crypto back-end implementation.
- A default pure-software crypto backend using tinycrypto and micro-ecc.
- Interest and Data signing and verification.
- AES Encrypted Content TLV for Data packet.
Application Support Layer:
- Ease-of-use Security Bootstrapping Module to achieve efficient and secured trust anchor installation and identity certificate issuance. Check the protocol details at here.
- Lightweight Name-based Access Control to provide data confidentiality and control of access to data. Check the protocol details at here.
- Lightweight Service Discovery Protocol Module to enable an application provide services to the network or utilize existing services in the network system. Check the protocol details at here.
Platform Adaptation:
- Nordic NRF 802154 Raw Driver Adaptation, including an adaptation layer and a face implementation called
ndn-nrf-802154-face. - Nordic SDK adaptation, including an adaptation layer and a face implementation called
ndn-nrf-ble-face.
-
./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.
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.
Create ./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 ./ndn-lite/forwarder/face.h
Inside ./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.
Existing examples:
- (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.c,./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.c,./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.