OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/doc/subsystems/networking/overview.rst

136 lines
6.1 KiB
ReStructuredText
Raw Normal View History

doc: net: restructure networking documentation Change-Id: Ic5dd009f0e890fa152e92e6c96b6a76b4a3df5a9 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-02-02 22:27:05 +08:00
.. _ip_stack_overview:
Overview
########
Supported Features
******************
doc: Enhance IP stack overview documentation Add more information to networking IP stack overview documentation. Change-Id: Ie179c4bf2a5716b9c85b4f8899fe61033510b90d Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-04-04 22:54:14 +08:00
The networking IP stack is modular and highly configurable via build-time
configuration options. You can minimize system memory consumption by enabling
only those network features required by your application. Almost all features
can be disabled if not needed.
* **IPv6** The support for IPv6 is enabled by default. Various IPv6 sub-options
can be enabled or disabled depending on networking needs.
* Developer can set the number of unicast and multicast IPv6 addresses that
are active at the same time.
* The IPv6 address for the device can be set either statically or
dynamically using SLAAC (Stateless Address Auto Configuration) (RFC 4862).
* The system also supports multiple IPv6 prefixes and the maximum
IPv6 prefix count can be configured at build time.
* The IPv6 neighbor cache can be disabled if not needed, and its size can be
configured at build time.
* The IPv6 neighbor discovery support (RFC 4861) is enabled by default.
* Multicast Listener Discovery v2 support (RFC 3810) is enabled by default.
* IPv6 header compression (6lo) is available for IPv6 connectivity for
Bluetooth IPSP (RFC 7668) and IEEE 802.15.4 networks (RFC 4944).
* **IPv4** The legacy IPv4 is supported by the networking stack. It cannot be
used by IEEE 802.15.4 or Bluetooth IPSP as those network technologies support
only IPv6. IPv4 can be used in ethernet based networks. By default IPv4
support is disabled.
* DHCP (Dynamic Host Configuration Protocol) client is supported (RFC 2131).
* The IPv4 address can also be configured manually. Static IPv4 addresses
are supported by default.
* **Dual stack support.** The networking stack allows a developer to configure
the system to use both IPv6 and IPv4 at the same time.
* **UDP** User Datagram Protocol (RFC 768) is supported. The developer can
send UDP datagrams (client side support) or create a listener to receive
UDP packets destined to certain port (server side support).
* **TCP** Transmission Control Protocol (RFC 793) is supported. Both server
and client roles can be used the the application. The amount of TCP sockets
that are available to applications can be configured at build time.
net: sockets: Add docs for BSD Sockets compatible API. Includes updates to Zephyr networking API feature list (also minor tweaks to it not dorectly related to sockets), overview of BSD Sockets compatible API, and basic API reference section. Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
2017-08-01 21:08:58 +08:00
* **BSD Sockets API** Experimental support for a subset of a BSD Sockets
compatible API is implemented. Both blocking and non-blocking DGRAM (UDP)
doc: scan/fix .rst file misspellings Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2017-09-01 01:31:06 +08:00
and STREAM (TCP) sockets are supported.
net: sockets: Add docs for BSD Sockets compatible API. Includes updates to Zephyr networking API feature list (also minor tweaks to it not dorectly related to sockets), overview of BSD Sockets compatible API, and basic API reference section. Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
2017-08-01 21:08:58 +08:00
doc: Enhance IP stack overview documentation Add more information to networking IP stack overview documentation. Change-Id: Ie179c4bf2a5716b9c85b4f8899fe61033510b90d Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-04-04 22:54:14 +08:00
* **HTTP** Hypertext Transfer Protocol (RFC 2116) is supported. A simple
library is provided that applications can use. Sample applications are
implemented for :ref:`http-client-sample` and :ref:`http-server-sample`.
Both :ref:`http-client-sample` and :ref:`http-server-sample` can use
TLS (Transport Layer Security) v1.2 (RFC 5246) or SSL (Secure Sockets
Layer) v3.0 (RFC 6101) functionality to encrypt the network traffic.
The secured connections are provided by mbed library.
* **MQTT** Message Queue Telemetry Transport (ISO/IEC PRF 20922) is supported.
A sample :ref:`mqtt-publisher-sample` client application for MQTT v3.1.1 is
implemented.
net: samples: Modify zoap_server to new CoAP api's Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
2017-10-06 04:12:18 +08:00
* **CoAP** Constrained Application Protocol (RFC 7252) is supported.
net: samples: Modify zoap_client to new CoAP api's Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
2017-08-28 19:00:35 +08:00
Both :ref:`coap-client-sample` and :ref:`coap-server-sample` sample
net: samples: Modify coaps_client to new CoAP api's Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
2017-08-28 16:25:30 +08:00
applications are implemented. A :ref:`coaps-client-sample` and
net: samples: Modify coaps_server to new CoAP api's Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
2017-08-28 16:25:11 +08:00
:ref:`coaps-server-sample` using DTLS (Datagram Transport Layer Security)
doc: Enhance IP stack overview documentation Add more information to networking IP stack overview documentation. Change-Id: Ie179c4bf2a5716b9c85b4f8899fe61033510b90d Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-04-04 22:54:14 +08:00
(RFC 6347) are also implemented.
net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-08 02:04:03 +08:00
* **LWM2M** OMA Lightweight Machine-to-Machine Protocol (V1.0 Feb 2017) is
supported via the "Register Device" API (Register, De-Register and Update)
doc: scan/fix .rst file misspellings Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2017-09-01 01:31:06 +08:00
and has template implementations for Security, Server, Device Management and
net: lwm2m: initial library support for LWM2M Origin: SICS-IoT / Contiki OS URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a Purpose: Introduction of LwM2M client library. Maintained-by: Zephyr Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension of the Constrained Application Protocol (CoAP) which uses UDP transmission packets. This library was based on source worked on by Joakim Eriksson, Niclas Finne and Joel Hoglund which was adopted by Contiki and then later revamped to work as a stand-alone library. A VERY high level summary of the changes made: - [ALL] sources were re-formatted to Zephyr coding standards - [engine] The engine portion was re-written due to the heavy reliance on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as well as other Zephyr specific needs. - [engine] All LWM2M/IPSO object data is now abstracted into resource data which stores information like the data type, length, callbacks to help with read/write. The engine modifies this data directly (or makes callbacks) instead of all of the logic for this living in each object's code. (This wasn't scaling well as I was implementing changes). - [engine] Related to the above change, I also added a generic set of getter/setter functions that user applications can call to change the object data instead of having to add getter/setting methods in each object. - [engine] The original sources shared the engine's context structure quite extensively causing a problem with portability. I broke up the context into it's individual parts: LWM2M path data, input data and output data and pass only the needed data into each set of APIs. - [content format read/writer] sources were re-organized into single .c/h files per content formatter. - [content format read/writer] sources were re-written where necessary to remove the sharing of the lwm2m engine's context and instead only requires the path and input or output data specific to it's function. - [LwM2M objects] re-written using the new engine's abstractions Signed-off-by: Michael Scott <michael.scott@linaro.org>
2017-07-08 02:04:03 +08:00
Firmware objects. DTLS and Bootstrap support are currently not supported.
:ref:`lwm2m-client-sample` implements the library as an example.
doc: Enhance IP stack overview documentation Add more information to networking IP stack overview documentation. Change-Id: Ie179c4bf2a5716b9c85b4f8899fe61033510b90d Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-04-04 22:54:14 +08:00
* **RPL** IPv6 Routing Protocol for Low-Power and Lossy Networks (RFC 6550)
is supported. RPL is an IPv6 based mesh routing protocol.
* **DNS** Domain Name Service (RFC 1035) client functionality is supported.
Applications can use an API to query domain name information or IP addresses
from the DNS server. Both IPv4 (A) and IPv6 (AAAA) records can be queried.
* **Network Management API.** Applications can use network management API to
listen management events generated by core stack when for example IP address
is added to the device, or network interface is coming up etc.
* **Multiple Network Technologies.** The Zephyr OS can be configured to
support multiple network technologies at the same time simply by enabling
them in Kconfig: for example, Ethernet and 802.15.4 support. Note that no
automatic IP routing functionality is provided between these technologies.
Applications can send data according to their needs to desired network
interface.
* **Minimal Copy Network Buffer Management.** It is possible to have minimal
copy network data path. This means that the system tries to avoid copying
application data when it is sent to the network. For some technologies it
is even possible to have zero-copy data path from application to device
driver.
net: sockets: Add docs for BSD Sockets compatible API. Includes updates to Zephyr networking API feature list (also minor tweaks to it not dorectly related to sockets), overview of BSD Sockets compatible API, and basic API reference section. Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
2017-08-01 21:08:58 +08:00
Additionally these network technologies (link layers) are supported in
Zephyr OS v1.7 and later:
doc: net: restructure networking documentation Change-Id: Ic5dd009f0e890fa152e92e6c96b6a76b4a3df5a9 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-02-02 22:27:05 +08:00
* IEEE 802.15.4
* Bluetooth
* Ethernet
net: sockets: Add docs for BSD Sockets compatible API. Includes updates to Zephyr networking API feature list (also minor tweaks to it not dorectly related to sockets), overview of BSD Sockets compatible API, and basic API reference section. Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
2017-08-01 21:08:58 +08:00
* SLIP (IP over serial line). Used for testing with QEMU. It provides
ethernet interface to host system (like Linux) and test applications
can be run in Linux host and send network data to Zephyr OS device.
doc: net: restructure networking documentation Change-Id: Ic5dd009f0e890fa152e92e6c96b6a76b4a3df5a9 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-02-02 22:27:05 +08:00
Source Tree Layout
******************
The IP stack source code tree is organized as follows:
``subsys/net/ip/``
This is where the IP stack code is located.
net: sockets: Add docs for BSD Sockets compatible API. Includes updates to Zephyr networking API feature list (also minor tweaks to it not dorectly related to sockets), overview of BSD Sockets compatible API, and basic API reference section. Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
2017-08-01 21:08:58 +08:00
``subsys/net/lib/``
Application-level protocols (DNS, MQTT, etc.) and additional stack
components (BSD Sockets, etc.).
doc: net: restructure networking documentation Change-Id: Ic5dd009f0e890fa152e92e6c96b6a76b4a3df5a9 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-02-02 22:27:05 +08:00
``include/net/``
Public API header files. These are the header files applications need
to include to use IP networking functionality.
``samples/net/``
Sample networking code. This is a good reference to get started with
network application development.
``tests/net/``
Test applications. These applications are used to verify the
functionality of the IP stack, but are not the best
source for sample code (see ``samples/net`` instead).