CoAP Protocol

RFC 7252 Constrained Application Protocol

Implementation: CoAP — Constrained Application Protocol | Overview
CoAP
• “The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use
with constrained nodes and constrained networks in the Internet of Things.
• The protocol is designed for machine-to-machine (M2M) applications such as smart energy
and building automation.”
• The Constrained Application Protocol (CoAP) was published as a full IETF Internet standard
in 2014.
• It follows a client/server approach, where the CoAP server publishes a set of “resources”
(IP addressable sensors and actuators).
• Clients follow a “Representational State Transfer” (REST) approach where data is obtained
from a resource using a “GET” request, and where actuation and control commands can be
sent via a “PUT” or “POST”. Clients can also “subscribe” to a resource and thus receive
continuous updates if a resource is updated
• CoAP is designed to enable low‐power sensors to use RESTful services while meeting their
power constraints light weight RESTful interface.
CoAP
• CoAP is similar to the client/server model of HTTP.

• A CoAP request is equivalent to that of HTTP and is sent by a client to request an action (using a Method
Code) on a resource (identified by a URI) on a server. The server then sends a response with a Response
Code; this response may include a resource representation.

• Unlike HTTP, CoAP deals with these interchanges asynchronously over a datagram-oriented transport such
as UDP.

• CoAP defines four types of messages: Confirmable, Non-confirmable, Acknowledgement, Reset.

• Method Codes and Response Codes included in some of these messages make them carry requests or
responses.

• requests can be carried in Confirmable and Non- confirmable messages, and responses can be carried in
these as well as piggybacked in Acknowledgement messages.

• The CoAP messaging model is based on the exchange of messages over UDP between endpoints.
 CoAP architecture
• CoAP architecture is divided into two main sub‐layers:
1 Messaging 2 Request/response
• The messaging sub‐layer is responsible for reliability
and duplication of messages, while the
request/response sub‐layer is responsible for
communication.

1.Token (variable length): A variable-length field used for

CoAP message format: A 4-byte base header containing 2 bits for
versioning, 2 bits for message type encoding, 4 bits for the token
length, 1 byte for the message code (either a RESTful method or a
response code), and 2 bytes for the message identifier (MID), followed
by a token, options and a payload
message identification and correlation.
2.Options (variable length): Optional fields that carry
additional information about the request or response.
Options include things like URI paths, content formats,
observe options, etc
3.Payload (variable length): Contains the actual data
being transferred in the CoAP message. The payload is
optional and can carry application-specific data.
Version (Ver): 2-bit unsigned integer. Indicates the CoAP version number. Implementations of this
specification MUST set this field to 1 (01 binary). Other values are reserved for future versions.
Messages with unknown version numbers MUST be silently ignored.

Type (T): 2-bit unsigned integer. Indicates if this message is of type Confirmable (0), Non-confirmable
(1), Acknowledgement (2), or Reset (3).

Token Length (TKL): 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8
bytes). Lengths 9-15 are reserved, MUST NOT be sent, and MUST be processed as a message format
error.

Code: 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least
significant bits), documented as "c.dd" where "c" is a digit from 0 to 7 for the 3-bit subfield and "dd"
are two digits from 00 to 31 for the 5-bit subfield. The class can indicate a request (0), a success
response (2), a client error response (4), or a server error response (5). (All other class values are
reserved.) As a special case, Code 0.00 indicates an Empty message. In case of a request, the Code field
indicates the Request Method; in case of a response, a Response Code.

Message ID: 16-bit unsigned integer in network byte order. Used to detect message duplication and to
match messages of type Acknowledgement/Reset to messages of type Confirmable/Non- confirmable.
 CoAP messages
• On the message layer, messages can either Confirmable, Non‐confirmable,
Piggyback, Reset
• Reliable Message Transmission
• CON messages are used for reliable
transmission. An endpoint re-transmits a
CON message with an exponentially
increasing back-off timer until it is properly
acknowledged or the maximum
retransmission count is reached (which is
typically 4).
• The response to a CON request can be sent
with ACK with the same MID for message
correlation (a piggybacked response),
• or in a separate CON response, which
carries a different MID generated by the
server. The separate response is useful to
avoid waiting on the client side when the
server can not respond instantly and can be
closed by responding with an empty ACK
that only contains the 4-byte base header.
Non‐confirmable
• NON messages use a best-effort strategy and are
not retransmitted in case of loss.
• A NON message can be answered with another
NON message with a new MID generated by the
sender.
• If an endpoint receives a CON or NON that it does
not know how to process, it rejects it with an RST.
• An RST message also carries the same MID as the
origin message similar to ACK, indicates failure of
the message exchange and closes corresponding
transmission.

47 seconds for CON message and 147 seconds for NON

message.
 Piggyback and Separate message
• A request is carried in a Confirmable (CON) or Non-confirmable
(NON) message, and, if immediately available, the response to a
request carried in a Confirmable message is carried in the
resulting Acknowledgement (ACK) message. This is called a
piggybacked response.

• If the server is not able to respond immediately to a request

carried in a Confirmable message, it simply responds with an
Empty Acknowledgement message so that the client can stop
retransmitting the request. When the response is ready, the
server sends it in a new Confirmable message (which then in
turn needs to be acknowledged by the client). This is called a
"separate response“.
A Request and a Response Carried in Non-confirmable Messages

• If a request is sent in a Non-confirmable message, then the response is sent using

a new Non-confirmable message, although the server may instead send a
Confirmable message.
Request/Response layer
• Requests
• A CoAP request consists of the method to be applied to the resource, the
identifier of the resource, a payload and Internet media type (if any), and
optional metadata about the request.
• CoAP supports the basic methods of GET, POST, PUT, and DELETE, which are
easily mapped to HTTP.
• A request is initiated by setting the Code field in the CoAP header of a
Confirmable or a Non-confirmable message to a Method Code and including
request information.
•GET (0.01): Used to retrieve the representation of a resource.
•POST (0.02): Used to create a new resource on the server.
•PUT (0.03): Used to update an existing resource on the server.
•DELETE (0.04): Used to remove a resource from the server.
Response
• After receiving and interpreting a request, a server responds with a CoAP response that is matched to the
request by means of a client- generated token
• note that this is different from the Message ID that matches a Confirmable message to its
Acknowledgement.
• A response is identified by the Code field in the CoAP header being set to a Response Code. Similar to the
HTTP Status Code, the CoAP Response Code indicates the result of the attempt to understand and satisfy
the request.

• The upper three bits of the 8-bit Response Code number define the class of response. The lower five bits
do not have any categorization role; they give additional detail to the overall class

•2.01 Created: Indicates that the request has been successfully processed and a new
resource has been created.
•2.04 Changed: Indicates that the request has been successfully processed and the resource
has been modified.
•4.04 Not Found: Indicates that the requested resource does not exist on the server.
•5.03 Service Unavailable: Indicates that the server is currently unable to handle the request
due to temporary overloading or maintenance.
Implementation