Native IP Stack For Zephyr OS Zephyr is a trademark of the Linux - - PowerPoint PPT Presentation

native ip stack for zephyr os
SMART_READER_LITE
LIVE PREVIEW

Native IP Stack For Zephyr OS Zephyr is a trademark of the Linux - - PowerPoint PPT Presentation

Native IP Stack For Zephyr OS Zephyr is a trademark of the Linux Foundation. *Other names and brands may be claimed as the property of others. Why a native IP stack? Features missing in current Contiki based uIP stack No dual IPv6 &


slide-1
SLIDE 1

Native IP Stack For Zephyr™ OS

Zephyr is a trademark of the Linux Foundation. *Other names and brands may be claimed as the property of others.

slide-2
SLIDE 2

Why a native IP stack?

  • Features missing in current Contiki based uIP stack
  • No dual IPv6 & IPv4 stack
  • Only one bearer (BLE / 802.15.4) usable at a time
  • One adapter only (like no 2 x 802.15.4 device)
  • Memory management issues (too big buffers for small

amount of networking data)

  • Difficult to adapt uIP to multithreaded Zephyr OS
  • Automatic testing of the network stack
slide-3
SLIDE 3

Why not port 3rd party IP stack?

  • Use native stack instead of embedding existing stack like lwip or

FNET > avoid adaptation layers which cause overhead > use same network buffers everywhere to utilize memory efficiently > unified look and feel of the APIs and code (helps maintenance) > creating testing harness easier with new stack

slide-4
SLIDE 4

How to do it?

  • Re-write IPv6 and IPv4 components to enable dual stack
  • Avoid any adaptation layers by utilizing Zephyr OS services directly
  • Utilize memory better by enabling IP stack to use smaller buffers

that can be linked together

  • Creating a testing framework to test the stack automatically
slide-5
SLIDE 5

Key Features

  • Natjve dual IPv6 and IPv4 stack
  • Built around network bufger pools

concept, effjcient memory management

  • Possibility to have Zero/minimal

copy data path from user space to device driver

  • Supports Thread IP requirements
  • Natjve KConfjg integratjon
  • Uses automated testjng harness

for running network stack tests

RX fjber RX fjber

Network interface Network interface Task B Task B Task A Task A

TX fjber,

  • ne per

interface TX fjber,

  • ne per

interface

TX FIFO RX FIFO

Network interface Network interface

Multjple TX fjbers

  • Each network device has

its own TX fjber

  • Write to device drivers

TX FIFO One RX fjber

  • Global RX FIFO for receiving
  • array of network contexts

(“sockets”)

  • Look up Tasks’ Rx FIFOs
slide-6
SLIDE 6

Key L2 features

  • Dedicated OSI L2 abstractjon
  • Supports multjple bearers and

interfaces such as IEEE 802.15.4 and Bluetooth*

  • Concurrent TX/RX on all

interfaces

  • Spec-compliant 802.15.4

implementatjon

  • Supports current Zephyr OS

network drivers with small modifjcatjon

Core IP Stack

(Core, IPv6/4, ICMP/v6,UDP/TCP, ...)

Core IP Stack

(Core, IPv6/4, ICMP/v6,UDP/TCP, ...)

Ethernet Ethernet Management API Management API

Applicatjon Applicatjon

Ethernet driver Ethernet driver

Network Interface

(As many instances as hardware devices, hiding the inner complexity under a generic structure and API)

Network Interface

(As many instances as hardware devices, hiding the inner complexity under a generic structure and API)

Generic L2 API Generic L2 API

IEEE 802.15.4 IEEE 802.15.4 Bluetooth Bluetooth

SLIP TAP driver SLIP TAP driver CC2520 driver CC2520 driver CC1200 driver CC1200 driver HCI/NRF 51 HCI/NRF 51 6LoWPAN 6LoWPAN

*Other names and brands may be claimed as the property of others.

slide-7
SLIDE 7

Automatic Testing

  • Component tests created that will test some specific part of the

networking stack (example: 6lo, neighbor mgmt, ip-addr mgmt etc.)

  • These tests are executed automatically for each commit
  • Full network stack conformance testing run periodically
slide-8
SLIDE 8

Network buffer overview

  • net_buf’s can be chained together

to allow sending or receiving bigger amount of data

  • Amount of fragments is configurable

by Kconfig option

  • Size of the network data part of the

fragment can be configured via Kconfig

  • User specific data part in the first

fragment can contain protocol specific information

  • Example: typical size of the network

data part is 128 bytes for 802.15.4

slide-9
SLIDE 9

Network buffer details

  • Link layer header pre-allocated

in the net_buf

  • Requires application data

partitioning when sending the data

  • When receiving, the application

needs to read the data in chunks as the data is not continuous

  • The L2 layer will insert link layer

data to the start of the net_buf

slide-10
SLIDE 10

Release Plan

  • Currently native IP stack code under development can be found at

“net” branch in Zephyr OS git [1]

  • Merge native IP stack to Zephyr OS 1.7 release

[1] https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=tree;h=refs/heads/net;hb=refs/heads/net

slide-11
SLIDE 11

Thank you!