CoAP: Zusammenfassung der Spezifikation (high level)

aaron

Constrained Application Protocol (CoAP)
CoAP ist ein Internet Anwendungsprotokoll, welches innerhalb der RFC 7252 spezifiziert wurde. Das Protokoll dient der Kommunikation von Geräten ‚Nodes‘ z.B. embedded devices, die besonders wenig Energie verbrauchen (low-power) und in einem Netzwerk mit erhöhtem Datenverlußt (lossy networks) z.B. IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) zum Einsatz kommen.
CoAP kann zusätzlich innerhalb Internet basierten Netzwerken zur mobilen Kommunikation via SMS verwendet werden.
CoAP wird hauptsächlich im Rahmen von Internet of Things (IoT) und Machine-to-Machine (M2M) eingesetzt, da hier meistens Gerätedaten/Sensordaten mit geringer Größe übertragen werden. Dadurch, dass diese Art von Daten in regelmäßigen Abständen (Zyklen) übertragen werden, haben einzelne (verlorengegangene) Datenpakete keine Größe Auswirkung auf die verarbeitenden Systeme bzw. Anwendungen wie z.B. eine IoT-Plattform, der entsprechende Sensordaten (Temperatur, Umdrehungszahl etc.) verarbeitet und/oder grafisch darstellt.

Die Arbeitsgruppe ’strained RESTful Environments‘ kurz ‚CoRE‘ plant unter Anderem den Einsatz der REST Architektur innerhalb von Embedded devices (Nodes). Nodes verwenden hauptsächlich einen 8-bit microcontroller und stellen wenig RAM- und ROM-Speicher zur Verfügung.

Zielsetzung des Protokolls

  • Erstellung eines generischen Protokolls, sodass dieser im Rahmen von IoT Anwendungen z.B. Home automation oder im M2M-Anwendungen eingesetzt werden kann
  • Vereinfachung/Verkleinerung des Protokolls, was zu einer Reduzierung der Fragmentierung führen wird
  • built-in discovery
  • multicast support
  • asynchronous message exchanges

Protokoll Features

  • Erfüllung von M2M Anforderungen innerhalb eingeschränkter Netzwerke
  • [ENG] UDP binding with optional reliability supporting unicast and multicast requests
  • Asynchroner Austausch von Nachrichten
  • Einfacher Header und damit eine Reduzierung der Komplexität beim Parsing
  • Unterstützung von Uniform Resource Identifier (URI) & Content-types
  • Proxy und caching support
  • [ENG] A stateless HTTP mapping, allowing proxies to be built providing access to CoAP resources via HTTP in a uniform way or for HTTP simple interfaces to be realized alternatively over CoAP.
  • Datagram Transport Layer Security (DTLS) binding

Das Interaktionsmodell vom CoAP entspricht dem client/server Modell aus HTTP d.h. ein ‚client‘ sendet eine Anfrage (request) an einem Server und fragt nach einer URI. Der Server liefert daraufhin die angefragte Ressource.
Anders als bei HTTP erfolgt die Kommunikation über UDP.

CoAP unterscheidet vier unterschiedliche Arten von Nachrichten

  1. Confirmable
  2. Non-confirmable
  3. Acknowledgement
  4. Reset

Dadurch, dass CoAP das UDP Protokoll verwendet, sind grundsätzlich Duplikate oder Datenverlusste möglich.
Aus diesem Grund wurden innerhalb von CoAP die folgenden beiden mechanismen implementiert:

  • [ENG] Simple stop-and-wait retransmission reliability with exponential back-off for Confirmable messages.
  • Duplikaterkennung für Confirmable und Non-confirmable Nachrichten

CoAP Nachrichtenformat

  • Ver (Version): CoAP Versionsnummer
  • T (Type): Gibt den Nachrichtentyp (0-3) an: Confirmable (0), Non-confirmable (1), Acknowledgement (2), oder Reset (3)
  • TKL (Token Length): Gibt die variable Länge des Tokens an.
  • Code: request (0), a success response (2), client error response (4), server error response (5)
  • Message ID: Wird zwecks Erkennung von Duplikaten oder zwecks Matching von Nachrichten verwendet
  • Options: Hier können Optionsnummern z.B. Max-Age mit der Nummer 14 oder Proxy-Uri (35) angegeben werden. Die komplette Liste der Optionsnummern kann aus der Spezifikation entnommen werden.
  • Payload

Paketgröße
Die max. Paketgröße beim CoAP Header liegt bei 1152 bytes und 1024 bytes für den Payload.
Ein CoAP Paket sollte die maximale Größe nicht überschreiten, da gößere Pakete zu einer unerwünschten Fragmentierung führen können.
Um eine IP Fragmentierung zu vermeiden, sollte die Übertragung der Pakete via IPv6 erfolgen. Sollte IPv4 zum Einsatz kommen, so muss die Größe der Pakete entspricht reduziert werden. Die Spezifikation bietet weitere Details.

Übertragung & Übertragungsparameter
Die Übertragung findet ähnlich wie bei HTTP über die Request/Response Semantik statt, wobei im Gegensatz zu HTTP keine Übertragung über eine bestehende bzw. vorherige Verbindung stattfindet.
CoAP unterstützt die folgenden basis Methoden, die man bereits von HTTPS kennt:

  • GET z.B. GET /status/power
  • POST
  • PUT
  • DELETE

Die Methoden GET, PUT und DELETE sind idempotent. POST ist NICHT idempotent.
Bei Response basiert auf dem Request Code innerhalb des Headers. Folgende drei Response Codes werden unterschieden:

  • Success
  • Client Error
  • Server Error

Das Protokoll bietet die folgende Übertragungsparameter an, die der Anwender für seine Umgebung entsprechend konfigurieren kann.

Bei der Veränderung der Konfiguration ist zu beachten, dass z.B. eine Verringerung von ‚ACK_TIMEOUT‘ auf eine Sekunde gegen ‚Unicast UDP Usage Guidelines for Application Designers‘ versossen wird.
Weitere Veränderungen können dabei gegen andere Guidelines verstoßen. Weiterhin haben Veränderungen der obigen Parameter in bestimmten Kombinationen bzw. Konstellationen weitere Einflüsse auf die Übertragung.
Für die Gewährleistung einer sicheren Kommunikation kommt ‚Datagram Transport Layer Security (DTSL)‘ zum Einsatz.

Security
CoAP unterscheidet die folgenden vier Security Level (mode):

  1. NoSec
  2. PreSharedKey – symmetrische Verschlüsselung
  3. RawPublicKey – asymmetrische Verschlüsselung
  4. Certificate – asymmetrische Verschlüsselung via X.509 Zertifikat

CoAP URI
Bei CoAP wird ähnlich wie bei HTTP zwischen http (coap) und https (coaps) unterschieden. Das CoAP Schema sieht wie folgt aus:

  • coap-URI = „coap:“ „//“ host [ „:“ port ] path-abempty [ „?“ query ]
  • coaps-URI = „coaps:“ „//“ host [ „:“ port ] path-abempty [ „?“ query ]

Service Discovery
Service-Discovery bezeichnet die automatische Erkennung von Diensten in einem Rechnernetz. Hierbei kommen Kommunikationsprotokolle zum Einsatz, welche beschreiben, wie sich die Dienste finden, um miteinander kommunizieren können.
Grundsätzlich unterscheidet man zwischen zwei Gruppen von Service-Discovery-Protokollen (SDPs):

  1. Dienste registrieren sich in einem zentralen Dienst (einer Registry) und können über diesen gefunden werden.
  2. Dienste fragen mittels Broadcasting das gesamte Netzwerk nach einem bestimmten Dienst und der gesuchte Dienst oder eine Registry antwortet. [wikipedia]

Nachdem Hosten eines Servers seitens eines 6LoWPAN nodes, kann der Server über die Portnummer 5683 und 5684 bei einer DTSL erreicht werden.
Das Entdecken (discovery) der Ressourcen erfolgt über ein CoAP Endpoint. Daher sollte ein Endpoint den CoRE Link format unterstützen. Das Format ist innerhalb von [RFC6690] beschrieben.
Für eine Kommunikation mit einem Server kann der CoAP-Agent Copper (Cu) verwendet werde.
https://addons.mozilla.org/en-US/firefox/addon/copper-270430/

[Spezifikation: https://tools.ietf.org/html/rfc7252#section-12.2]

 

LwM2M Client & Servers
Wer einen eigenen Server oder Client erstellen möchte, kann die OMA Lightweight M2M server und client Implemtierung von LESHAN in Java verwenden.

Anbei ein paar Links zum LESHAN Projekt:
https://github.com/eclipse/leshan/blob/master/README.md
https://github.com/eclipse/leshan/wiki/Getting-started