Architecture

Table of Contents

• Architecture
• API Context
• Timer context
• IPv6 packets

Nordic's IPv6 stack provides minimal implementations of the ICMP, UDP, CoAP protocols for a Host role, and the IPv6 neighbor discovery for Host. Router, neighbor, and prefix cache are not maintained across the BLE link disconnections or power cycles.

Nordic's IPv6 stack is designed to be event driven. Events will be received in three main contexts.

• Transport Context: In the transport context the IP stack is processing an event received on the BLE transport.
• API Context: In the API context the IP stack is processing an event as a result of a request from the application.
• Timer Context: In the timer context the IP stack is taking the necessary action as a result of a protocol or application specific timer having fired. The protocol referred to here is an IPv6 protocol and not a BLE protocol. Any idle timer implemented for BLE as a transport is considered to be an application timer and therefore becomes part of the timer context for the IPv6 stack.

Architecture

Based on how the system is configured to run, each of these contexts can, but does not have to be, a separate task or thread. The stack functions perfectly even without any OS support, and this is the default configuration.

The transport context mainly deals with the IPv6 packets received from the peer. However, these are not the only events that are part of the transport context. Transport connection and disconnection are also seen as part of the transport context. A BLE link establishment and subsequent establishment of the IPSP L2CAP channel over IPv6 data exchange result in adding a network interface to the IPv6 transport. Once a network interface is added successfully, the IPv6 stack is ready to send and receive packets over the BLE transport. Each BLE link and IPSP connection on the link is considered a separate transport and results in adding a network interface for each connection when connected. The network interface is considered to be point-to-point. All the network interface APIs serve as entry points to feed events in transport context to the stack. Establishing or tearing down the transport itself is not in the scope of the stack and no network interface APIs are provided to request these.

API Context

The API context mainly deals with events, that is application requested procedures using the IPv6 protocol APIs, for example ICMP or UPD (or protocols over UDP) procedures. The stack does not implement the TCP, but necessary hooks are provided in case the application wants to implement or emulate the protocol. The IP stack does not provide support for multiple API contexts, meaning that the stack behavior in case the APIs are called from multiple application threads is not studied or documented and therefore not recommended. There is no priority queue and bottom halves are implemented to ensure smooth functioning with application contexts.

Timer context

The timer context includes timers implemented for the IPv6 protocols, including the application protocols like CoAP.

A typical configuration is that the API and the timer contexts are configured to be the same, but this does not need to be the case.

IPv6 packets

IP packets that are fed into or come out of the IP stack are encapsulated in an IPv6 packet. The IPv6 packet provides a standard interface to allocate, deallocate or reallocate a buffer based on the requested operation. The buffer allocation considers if the packet needed room for the lower layer headers or not. The layer allocating the buffer does not have to consider it. If a layer wants to reuse a buffer received for transmission, it must use the realloc method in case more room is needed for the transmit packet. Necessary buffer allocation is done by the API. This functionality is implemented on Context Manager.