The Constrained Application Protocol (CoAP)

Khamdamboy Urunov, a Ph.D. student.,hamdamboy.urunov@gmail.com

• Resource of Presentation :

– CoAP: The Internet of Things Protocol (Zach Shelby, Chief Nerd)• http://www.iot.gen.tr/2016/02/08/coap-the-internet-of-things-protocol-zach-shelby-chief-nerd/

– Observing Resources in the Constrained Application Protocol (CoAP) RFC 7641• https://tools.ietf.org/html/rfc7641

– The Constrained Application Protocol (CoAP)• https://tools.ietf.org/html/rfc7252

2

Source Code of the CoAP• Source code of the CoAP

– https://coap.codeplex.com/

• A CoAP framework in C#

The Constrained Application Protocol (CoAP) https://datatracker.ietf.org/doc/draft-ietf-core-coap/is a RESTful web transfer protocol for resource-constrained networks and nodes.CoAP.NET is an implementation in C# providing CoAP-based services to .NET applications. Reviews and suggestions would be appreciated.

Example:Client part:

// new a GET request Request request = new Request(Method.GET); request.URI = new Uri("coap://[::1]/hello-world");

request.Send(); // wait for one response Response response = request.WaitForResponse();

3

Contents• The Web of Things

• The Web & REST?

• Introduction

• Protocol overview

• The Observe Option

• Client-server requirements

• Server-side Requirements

• Web Linking

• Security Considerations

• Example

4

Internet of Things

5

Things

Services

The Web

Little Data

Big Data

Web Resource Identification

6

The Web service Paradigm

7

the Web Services Description Language. It is commonly used to spell out in detail the services offered by a SOAP server. While WSDL is flexible in service binding options (for example, services can be offered via SMTP mail servers), it did not originally support HTTP operations other than GET and POST.Since REST services often use other HTTP verbs, such as PUT and DELETE, WSDL was a poor choice for documenting REST services.

the Web Application Description Language. WADL is lightweight, easier to understand and easier to write than WSDL. In some respects, it is not as flexible as WSDL (no binding to SMTP servers), but it is sufficient for any REST service and much less verbose.

Introduction

8

is a RESTful transfer protocol for constrained nodes and networks; messages work well for the small payloads;

CoAP (Constrained Application Protocol)

the term "payload" will be used for the actual content of a single CoAP message, i.e.a single block being transferred, while the term "body" will be used for the entire resource representation that is being transferred in a block-wise fashion.

CoAP Design Requirements

9

The CoAP Architecture

10

CoAP Feature

11

• Embedded web transfer protocol (coap://)

• Asynchronous transaction model

• UDP binding with reliability and multicast support

• GET, POST, PUT, DELETE methods

• URI support

• Small, simple 4 byte header

• DTLS based PSK, RPK and Certificate security

• Subset of MIME types and HTTP response codes

• Built-in discovery

• Optional observation and block transfer

12

Sure, CoAP is

A very efficient RESTful protocol

Ideal for constrained devices and networks

Specialized for M2M applications

Easy to proxy to/from HTTP

But hey, CoAP is not

A general replacement for HTTP

HTTP compression

Restricted to isolated “automation” networks

What CoAP is (and is not)

The Transaction Model

13

• Transport- CoAP is defined for UDP

•Messaging- Simple message exchange between end-points- CON, NON, ACK, RST

•REST - Request/response piggybacked on messages- Method, Response Code and Options (URI, content-type)

Similar to HTTP a CoAP request is sent by a client using a Method Code to request an action on a URI identifiable

resource.

The server replies with a Response Code which may include a resource representation.

CoAP model is essentially client/server architecture enabling the client to request for service from server as needed

and the server responds.

The message layer interfaces with UDP layer which formats the data received into a datagram and sends it to the

lower layers of the OSI or the TCP/IP Model.

14

Application

Request / Response

Message

UDP

Simple message exchange between end-points

Confirmable (CON), Non-confirmable(NON), Acknowledgement (ACK), Reset (RST)

CoAP Layering

The CoAP messaging model is based on the exchange of messages over UDP between endpoints.

15

Confirmable Message

Some messages require an acknowledgement. These messages are called "Confirmable". When no packets are lost,

each Confirmable message elicits exactly one return message of type Acknowledgement or type Reset.

Non-confirmable Message

Some other messages do not require an acknowledgement. This is particularly true for messages that are repeated

regularly for application requirements, such as repeated readings from a sensor.

Acknowledgement Message

An Acknowledgement message acknowledges that a specific Confirmable message arrived. By itself, an

Acknowledgement message does not indicate success or failure of any request encapsulated in the Confirmable

message, but the Acknowledgement message may also carry a Piggybacked Response

Reset Message

A Reset message indicates that a specific message (Confirmable or Non-confirmable) was received, but some

context is missing to properly process it. This condition is usually caused when the receiving node has rebooted

and has forgotten some state that would be required to interpret the message. Provoking a Reset message (e.g., by

sending an Empty Confirmable message) is also useful as an inexpensive check of the liveness of an endpoint

("CoAP ping").

Message

CoAP messages are encoded in a simple binary format. The Message Header (4 bytes).The variable-length token value 0 and 8 bytes long.

16

Ver - Version (1) 2 bit unsigned integer . Implementations of this field to 1 (01 binary).

T – Message Type 2- bit unsigned integer. (Confirmable, Non-Confirmable, Acknowledgement, Reset).

TKL- Token Length 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8 bytes).

Code – 8-bit unsighted integer. 3 bit class(most signification bits). 5 bits detail (least significant bits).

Request Method (1-10) or Response Code (40-255)

Message ID – 16-bit identifier for matching responses

Token – Optional response matching token

Message Format

Standards Track RFC 7252 June, 2014

Option Format

17

Option Delta - Difference between this option type and the previous.

4 bit unsigned integer. A value between 0 and 12 indicates the Optional Delta.

Length - Length of the option value

4 bit unsigned integer. A value between 0 and 12 indicates the length of the Optional Value, in bytes.

Value - The value of Length bytes immediately follows Length

CoAP defined a number of options that can be included in a message.

Base Specification Options

18

The Uri-Host Option specifies the Internet host of the resource being requested. The Uri-Post Option specifies the transport-layer port number of the resourceThe Uri-Path Option specifies one segment of the absolute path to the resourceThe Uri-Query Option specifies one argument parameterizing the resource

Request Example

19

CoAP Client – Server communication

Dealing with Packet Loss

20

Separate Response

21

Example

22

Caching

23

• CoAP includes a simple caching modelCache ability determined by response code

An option number mask determines if it is a cache key

• Freshness modelMax-Age option indicates cache lifetime

• Validation modelValidity checked using the Etag Option

• A proxy often supports cachingUsually on behalf of a constrained node,

a sleeping node,

or to reduce network load

Proxying and caching

24

Observation

25

COAP Observation

PROBLEM: REST paradigm is often “PULL” type, that is, data is obtained by issuing an explicit request

Information/data in WSN is often periodic/

triggered (e.g., get me a temperature sample every

2 seconds or get me a warning if temperature goes

below 5°C)

SOLUTION: use Observation on COAP resources

Block transfer

26

COAP Block Transfer

PROBLEM:

avoid segmentation in the lower layers

(IPv6)

SOLUTION:

COAP Block Transfer Mode n brings up

fragmentation at the application layer

Getting Started with CoAP

27

• There are many open source implementations available

Java CoAP Library Californium

C CoAP Library Erbium

libCoAP C Library

jCoAP Java Library

OpenCoAP C Library

TinyOS and Contiki include CoAP support

• CoAP is already part of many commercial products/systems

Sensinode NanoService

RTX 4100 WiFi Module

• Firefox has a CoAP plugin called Copper

• Wireshark has CoAP dissector support

• Implement CoAP yourself, it is not that hard!

Resource Discovery

28

• Service Discovery

What services are available in the first place?

Goal of finding the IP address, port and protocol

Usually performed by e.g. DNS-SD when DNS is available

• Resource Discovery

What are the Web resources I am interested in?

Goal of finding URIs

Performed using Web Linking or some REST interface

CoRE Link Format is designed to enable resource discovery

GOAL: Discovering the links hosted by CoAP (or HTTP) servers

GET /.well-known/core?optional_query_string

Resource Directory

29

• CoRE Link Format only defines

The link format

Peer-to-peer discovery

• A directory approach is also useful

Supports sleeping nodes

No multicast traffic, longer battery life

Remote lookup, hierarchical and federated distribution

• The CoRE Link Format can be used to build Resource Directories

Nodes POST (register) their link-format to an RD

Nodes PUT (refresh) to the RD periodically

Nodes may DELETE (remove) their RD entry

Nodes may GET (lookup) the RD or resource of other nodes

Resource Directory

30

CoRE Interfaces

31

• CoRE Interfaces [draft-shelby-core-interfaces]A paradigm for REST profiles made up of function setsSimple interface types

Architecture

32

• Thank you !

33