Loading...
Searching...
No Matches

GNRC's 6LoWPAN implementation. More...

Detailed Description

GNRC's 6LoWPAN implementation.

Internal API and sub-modules

Internally, 6LoWPAN is sub-divided into several sub-modules. They implement certain features of the 6LoWPAN standard. Currently implemented are

Each sub-module has a send and recv function prefixed by their respective sub-module name with the following signatures

void send(gnrc_pktsnip_t *pkt, void *ctx, uint8_t page);
void recv(gnrc_pktsnip_t *pkt, void *ctx, uint8_t page);
static ssize_t send(int socket, const void *buffer, size_t length, int flags)
Send a message on a socket.
Definition socket.h:456
static ssize_t recv(int socket, void *buffer, size_t length, int flags)
Receive a message from a connected socket.
Definition socket.h:386
Type to represent parts (either headers or payload) of a packet, called snips.
Definition pkt.h:108

A 6LoWPAN frame pkt must pass the sub-modules sequentially in the order of its dispatches on receive or the step that makes most sense next on send. After it was passed into another sub-module using the respective send/recv function a sub-module must not operate on the pkt anymore.

The ctx parameter can be used to provide data structures of a sub-module to the next sub-module if that needs to modify or read them (e.g. reassembly buffer state for IPHC) otherwise, leave it NULL.

Finally, the page parameter is to provide a sub-module the current parsing page context according to RFC 8025.

Supported NETAPI commands

To interact with other modules this module handles the following GNRC communication interface message types:

<tt>GNRC_NETAPI_MSG_TYPE_RCV</tt>

GNRC_NETAPI_MSG_TYPE_RCV expects a Packet (referred to as "packet" in the following) in receive order (link-layer payload first, Generic network interface header last) with the payload marked with GNRC_NETTYPE_SIXLOWPAN. Every other packet will be silently discarded.

If the first byte of the payload is SIXLOWPAN_UNCOMP this byte will be removed by marking it with a new gnrc_pktsnip_t and then removing this gnrc_pktsnip_t, the remaining payload will be marked with GNRC_NETTYPE_IPV6 and this module will issue a GNRC_NETAPI_MSG_TYPE_RCV to all subscribers registered to GNRC_NETTYPE_IPV6 with demultiplex context GNRC_NETREG_DEMUX_CTX_ALL in the Network protocol registry with the packet. Otherwise, the packet will be silently discarded (except for the cases documented below).

Depending on which other modules are included the behavior can be a little different:

  1. If 6LoWPAN Fragmentation is included and sixlowpan_frag_is() is true for the packet, the fragmentation header will be removed and its remaining data will be added to the reassembly buffer (using gnrc_sixlowpan_frag_rb_add()) in accordance to the fragmentation header. The packet containing the fragment will be discarded. When the fragmented datagram is complete, its payload will be marked with GNRC_NETTYPE_IPV6 and issued via a GNRC_NETAPI_MSG_TYPE_RCV to all subscribers registered to GNRC_NETTYPE_IPV6 with demultiplex context GNRC_NETREG_DEMUX_CTX_ALL in the Network protocol registry. If reassembly times out or if fragments overlap the datagram will be silently discarded.
  2. If IPv6 header compression (IPHC) is included the packet will not be send to the subscribers to GNRC_NETTYPE_IPV6 with demultiplex context GNRC_NETREG_DEMUX_CTX_ALL immediately, but it will be checked first if sixlowpan_iphc_is() is true for its payload. If false it will be send to the GNRC_NETTYPE_IPV6 subscribers as usual. If true the IPHC dispatch will be decompressed to a full IPv6 header first. The IPHC dispatch will be replaced by the uncompressed IPHC header, any NHC dispatch will be replaced by their respective uncompressed header. The resulting packet will then be issued to the GNRC_NETTYPE_IPV6 subscribers as usual.
  3. If both 6LoWPAN Fragmentation and IPv6 header compression (IPHC) are included the and sixlowpan_frag_is() is true for the packet, the fragmented datagram will be reassembled as described in (1). If for the remainder (after removal of the fragment header) of the first fragment sixlowpan_iphc_is() is true, it will be decompressed as described in (2), with the exception that the packet will only be send to all receivers of GNRC_NETTYPE_IPV6 as soon as the datagram was completely reassembled and not after directly after decompression. If sixlowpan_iphc_is() is false, reassembly is handled completely as described in (1). It is assumed that a fragment can fit a full compression header (including inlined fields and possibly NHC/GHC headers) as specified in RFC 6282, section 2.

<tt>GNRC_NETAPI_MSG_TYPE_SND</tt>

GNRC_NETAPI_MSG_TYPE_SND expects a Packet (referred to as "packet" in the following) in send order (headers first, payload last) with the first header being a valid GNRC_NETTYPE_NETIF header and the second a GNRC_NETTYPE_IPV6 header. Every other packet will be silently discarded.

The GNRC_NETTYPE_SIXLOWPAN header must at least have the gnrc_netif_hdr_t::if_pid field set to a legal, 6LoWPAN compatible interface referred to as netif in the following, otherwise the packet will be discarded.

If IPv6 header compression (IPHC) is included and GNRC_NETIF_FLAGS_6LO_HC is enabled for netif the GNRC_NETTYPE_IPV6 header will be compressed according to RFC 6282, section 3. If it is false the SIXLOWPAN_UNCOMP dispatch will be appended as a new gnrc_pktsnip_t to the packet. The false case also applies if IPv6 header compression (IPHC) is not included.

If the packet without GNRC_NETTYPE_NETIF header is shorter than gnrc_netif_t::sixlo::max_frag_size of netif the packet will be send to the netif's thread. Otherwise if 6LoWPAN Fragmentation is included the packet will be fragmented according to RFC 4944, section 5.3 if the packet is without GNRC_NETTYPE_NETIF header shorter than SIXLOWPAN_FRAG_MAX_LEN. If none of these cases apply, the packet will be discarded silently.

<tt>GNRC_NETAPI_MSG_TYPE_SET</tt>

GNRC_NETAPI_MSG_TYPE_SET is not supported.

<tt>GNRC_NETAPI_MSG_TYPE_GET</tt>

GNRC_NETAPI_MSG_TYPE_GET is not supported.

Modules

 6LoWPAN Fragmentation
 6LoWPAN Fragmentation headers and functionality
 
 6LoWPAN neighbor discovery
 Neighbor Discovery Optimization for 6LoWPAN.
 
 6LoWPAN selective fragment recovery
 6LoWPAN selective fragment recovery implementation for GNRC
 
 Contexts for 6LoWPAN address compression
 Context buffer for stateful 6LoWPAN address compression.
 
 GNRC 6LoWPAN compile configurations
 
 IPv6 header compression (IPHC)
 IPv6 header compression for 6LoWPAN.
 

Files

file  sixlowpan.h
 Definitions for 6LoWPAN.
 
file  internal.h
 6LoWPAN internal functions
 

Functions

kernel_pid_t gnrc_sixlowpan_init (void)
 Initialization of the 6LoWPAN thread.
 

Function Documentation

◆ gnrc_sixlowpan_init()

kernel_pid_t gnrc_sixlowpan_init ( void  )

Initialization of the 6LoWPAN thread.

If 6LoWPAN was already initialized, it will just return the PID of the 6LoWPAN thread.

Returns
The PID to the 6LoWPAN thread, on success.
-EINVAL, if GNRC_SIXLOWPAN_PRIO was greater than or equal to SCHED_PRIO_LEVELS
-EOVERFLOW, if there are too many threads running already in general