draft-ietf-lwig-coap-03.txt   draft-ietf-lwig-coap-04.txt 
LWIG Working Group M. Kovatsch LWIG Working Group M. Kovatsch
Internet-Draft ETH Zurich Internet-Draft ETH Zurich
Intended status: Informational O. Bergmann Intended status: Informational O. Bergmann
Expires: January 7, 2016 C. Bormann, Ed. Expires: September 14, 2017 C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
July 06, 2015 March 13, 2017
CoAP Implementation Guidance CoAP Implementation Guidance
draft-ietf-lwig-coap-03 draft-ietf-lwig-coap-04
Abstract Abstract
The Constrained Application Protocol (CoAP) is designed for resource- The Constrained Application Protocol (CoAP) is designed for resource-
constrained nodes and networks such as sensor nodes in a low-power constrained nodes and networks such as sensor nodes in a low-power
lossy network (LLN). Yet to implement this Internet protocol on lossy network (LLN). Yet to implement this Internet protocol on
Class 1 devices (as per RFC 7228, ~ 10 KiB of RAM and ~ 100 KiB of Class 1 devices (as per RFC 7228, ~ 10 KiB of RAM and ~ 100 KiB of
ROM) also lightweight implementation techniques are necessary. This ROM) also lightweight implementation techniques are necessary. This
document provides lessons learned from implementing CoAP for tiny, document provides lessons learned from implementing CoAP for tiny,
battery-operated networked embedded systems. In particular, it battery-operated networked embedded systems. In particular, it
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Implementation . . . . . . . . . . . . . . . . . . . 4 2. Protocol Implementation . . . . . . . . . . . . . . . . . . . 4
2.1. Client/Server Model . . . . . . . . . . . . . . . . . . . 4 2.1. Client/Server Model . . . . . . . . . . . . . . . . . . . 4
2.2. Message Processing . . . . . . . . . . . . . . . . . . . 5 2.2. Message Processing . . . . . . . . . . . . . . . . . . . 5
2.2.1. On-the-fly Processing . . . . . . . . . . . . . . . . 5 2.2.1. On-the-fly Processing . . . . . . . . . . . . . . . . 5
2.2.2. Internal Data Structure . . . . . . . . . . . . . . . 6 2.2.2. Internal Data Structure . . . . . . . . . . . . . . . 6
2.3. Message ID Usage . . . . . . . . . . . . . . . . . . . . 6 2.3. Message ID Usage . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Duplicate Rejection . . . . . . . . . . . . . . . . . 7 2.3.1. Duplicate Rejection . . . . . . . . . . . . . . . . . 6
2.3.2. MID Namespaces . . . . . . . . . . . . . . . . . . . 7 2.3.2. MID Namespaces . . . . . . . . . . . . . . . . . . . 7
2.3.3. Relaxation on the Server . . . . . . . . . . . . . . 8 2.3.3. Relaxation on the Server . . . . . . . . . . . . . . 8
2.3.4. Relaxation on the Client . . . . . . . . . . . . . . 9 2.3.4. Relaxation on the Client . . . . . . . . . . . . . . 9
2.4. Token Usage . . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Token Usage . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. Tokens for Observe . . . . . . . . . . . . . . . . . 10 2.4.1. Tokens for Observe . . . . . . . . . . . . . . . . . 10
2.4.2. Tokens for Blockwise Transfers . . . . . . . . . . . 11 2.4.2. Tokens for Blockwise Transfers . . . . . . . . . . . 11
2.5. Transmission States . . . . . . . . . . . . . . . . . . . 11 2.5. Transmission States . . . . . . . . . . . . . . . . . . . 11
2.5.1. Request/Response Layer . . . . . . . . . . . . . . . 12 2.5.1. Request/Response Layer . . . . . . . . . . . . . . . 12
2.5.2. Message Layer . . . . . . . . . . . . . . . . . . . . 13 2.5.2. Message Layer . . . . . . . . . . . . . . . . . . . . 13
2.6. Out-of-band Information . . . . . . . . . . . . . . . . . 14 2.6. Out-of-band Information . . . . . . . . . . . . . . . . . 14
skipping to change at page 2, line 47 skipping to change at page 2, line 47
3.3. Observable Resources . . . . . . . . . . . . . . . . . . 18 3.3. Observable Resources . . . . . . . . . . . . . . . . . . 18
3.4. Blockwise Transfers . . . . . . . . . . . . . . . . . . . 19 3.4. Blockwise Transfers . . . . . . . . . . . . . . . . . . . 19
3.5. Deduplication with Sequential MIDs . . . . . . . . . . . 19 3.5. Deduplication with Sequential MIDs . . . . . . . . . . . 19
4. Alternative Configurations . . . . . . . . . . . . . . . . . 22 4. Alternative Configurations . . . . . . . . . . . . . . . . . 22
4.1. Transmission Parameters . . . . . . . . . . . . . . . . . 22 4.1. Transmission Parameters . . . . . . . . . . . . . . . . . 22
4.2. CoAP over IPv4 . . . . . . . . . . . . . . . . . . . . . 23 4.2. CoAP over IPv4 . . . . . . . . . . . . . . . . . . . . . 23
5. Binding to specific lower-layer APIs . . . . . . . . . . . . 23 5. Binding to specific lower-layer APIs . . . . . . . . . . . . 23
5.1. Berkeley Socket Interface . . . . . . . . . . . . . . . . 23 5.1. Berkeley Socket Interface . . . . . . . . . . . . . . . . 23
5.1.1. Responding from the right address . . . . . . . . . . 23 5.1.1. Responding from the right address . . . . . . . . . . 23
5.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Multicast detection . . . . . . . . . . . . . . . . . . . 24 5.3. Multicast detection . . . . . . . . . . . . . . . . . . . 25
5.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. CoAP on various transports . . . . . . . . . . . . . . . . . 25 6. CoAP on various transports . . . . . . . . . . . . . . . . . 25
6.1. CoAP over reliable transports . . . . . . . . . . . . . . 25 6.1. Translating between transports . . . . . . . . . . . . . 25
6.2. Translating between transports . . . . . . . . . . . . . 26 6.1.1. Transport translation by proxies . . . . . . . . . . 26
6.2.1. Transport translation by proxies . . . . . . . . . . 26 6.1.2. One-to-one Transport translation . . . . . . . . . . 26
6.2.2. One-to-one Transport translation . . . . . . . . . . 26
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 27 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 27
8. Security considerations . . . . . . . . . . . . . . . . . . . 27 8. Security considerations . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
skipping to change at page 4, line 23 skipping to change at page 4, line 20
as found on constrained nodes, preemptive multi-threading is not an as found on constrained nodes, preemptive multi-threading is not an
option. Instead, all operations are triggered by an event loop option. Instead, all operations are triggered by an event loop
system, e.g., in a send-receive-dispatch cycle. It is also common system, e.g., in a send-receive-dispatch cycle. It is also common
practice to allocate memory statically to ensure stable behavior, as practice to allocate memory statically to ensure stable behavior, as
no memory management unit (MMU) or other abstractions are available. no memory management unit (MMU) or other abstractions are available.
For a CoAP node, the two key parameters for memory usage are the For a CoAP node, the two key parameters for memory usage are the
number of (re)transmission buffers and the maximum message size that number of (re)transmission buffers and the maximum message size that
must be supported by each buffer. Often the maximum message size is must be supported by each buffer. Often the maximum message size is
set far below the 1280-byte MTU of 6LoWPAN to allow more than one set far below the 1280-byte MTU of 6LoWPAN to allow more than one
open Confirmable transmission at a time (in particular for parallel open Confirmable transmission at a time (in particular for parallel
observe notifications [I-D.ietf-core-observe]). Note that observe notifications [RFC7641]). Note that implementations on
implementations on constrained platforms often not even support the constrained platforms often not even support the full MTU. Larger
full MTU. Larger messages must then use blockwise transfers messages must then use blockwise transfers [RFC7959], while a good
[I-D.ietf-core-block], while a good tradeoff between 6LoWPAN tradeoff between 6LoWPAN fragmentation and CoAP header overhead must
fragmentation and CoAP header overhead must be found. Usually the be found. Usually the amount of available free RAM dominates this
amount of available free RAM dominates this decision. For Class 1 decision. For Class 1 devices, the maximum message size is typically
devices, the maximum message size is typically 128 or 256 bytes 128 or 256 bytes (blockwise) payload plus an estimate of the maximum
(blockwise) payload plus an estimate of the maximum header size for header size for the worst case option setting.
the worst case option setting.
2.1. Client/Server Model 2.1. Client/Server Model
In general, CoAP servers can be implemented more efficiently than In general, CoAP servers can be implemented more efficiently than
clients. REST allows them to keep the communication stateless and clients. REST allows them to keep the communication stateless and
piggy-backed responses are not stored for retransmission, saving piggy-backed responses are not stored for retransmission, saving
buffer space. The use of idempotent requests also allows to relax buffer space. The use of idempotent requests also allows to relax
deduplication, which further decreases memory usage. It is also easy deduplication, which further decreases memory usage. It is also easy
to estimate the required maximum size of message buffers, since URI to estimate the required maximum size of message buffers, since URI
paths, supported options, and maximum payload sizes of the paths, supported options, and maximum payload sizes of the
application are known at compile time. Hence, when the application application are known at compile time. Hence, when the application
is distributed over constrained and unconstrained nodes, the is distributed over constrained and unconstrained nodes, the
constrained ones should preferably have the server role. constrained ones should preferably have the server role.
HTTP-based applications have established an inverse model because of HTTP-based applications have established an inverse model because of
the need for simple push notifications: A constrained client uses the need for simple push notifications: A constrained client uses
POST requests to update resources on an unconstrained server whenever POST requests to update resources on an unconstrained server whenever
an event (e.g., a new sensor reading) is triggered. This requirement an event (e.g., a new sensor reading) is triggered. This requirement
is solved by the Observe option [I-D.ietf-core-observe] of CoAP. It is solved by the Observe option [RFC7641] of CoAP. It allows servers
allows servers to initiate communication and send push notifications to initiate communication and send push notifications to interested
to interested client nodes. This allows a more efficient and also client nodes. This allows a more efficient and also more natural
more natural model for CoAP-based applications, where the information model for CoAP-based applications, where the information source is an
source is an origin server, which can also benefit from caching. origin server, which can also benefit from caching.
2.2. Message Processing 2.2. Message Processing
Apart from the required buffers, message processing is symmetric for Apart from the required buffers, message processing is symmetric for
clients and servers. First the 4-byte base header has to be parsed clients and servers. First the 4-byte base header has to be parsed
and thereby checked if it is a CoAP message. Since the encoding is and thereby checked if it is a CoAP message. Since the encoding is
very dense, only a wrong version or a datagram size smaller than four very dense, only a wrong version or a datagram size smaller than four
bytes identify non-CoAP datagrams. These need to be silently bytes identify non-CoAP datagrams. These need to be silently
ignored. Other message format errors, such as an incomplete datagram ignored. Other message format errors, such as an incomplete datagram
or the usage of reserved values, may need to be rejected with a Reset or the usage of reserved values, may need to be rejected with a Reset
skipping to change at page 10, line 25 skipping to change at page 10, line 25
from the previous request to the current one. Hence, when only the from the previous request to the current one. Hence, when only the
Token is used for matching, which is always the case for separate Token is used for matching, which is always the case for separate
responses, randomized Tokens with enough entropy should be used. The responses, randomized Tokens with enough entropy should be used. The
8-byte range for Tokens can even allow for one-time usage throughout 8-byte range for Tokens can even allow for one-time usage throughout
the lifetime of a client node. When DTLS is used, client crashes/ the lifetime of a client node. When DTLS is used, client crashes/
restarts will lead to a new security handshake, thereby solving the restarts will lead to a new security handshake, thereby solving the
problem of mismatching responses and/or notifications. problem of mismatching responses and/or notifications.
2.4.1. Tokens for Observe 2.4.1. Tokens for Observe
In the case of Observe [I-D.ietf-core-observe], a request will be In the case of Observe [RFC7641], a request will be answered with
answered with multiple notifications and it is important to continue multiple notifications and it is important to continue keeping track
keeping track of the Token that was used for the request - its of the Token that was used for the request - its lifetime will end
lifetime will end much later. Upon establishing an Observe much later. Upon establishing an Observe relationship, the Token is
relationship, the Token is registered at the server. Hence, the registered at the server. Hence, the client's use of that specific
client's use of that specific Token is now limited to controlling the Token is now limited to controlling the Observation relationship. A
Observation relationship. A client can use it to cancel the client can use it to cancel the relationship, which frees the Token
relationship, which frees the Token upon success (i.e., the message upon success (i.e., the message with an Observe Option with the value
with an Observe Option with the value set to 'deregister' (1) is set to 'deregister' (1) is confirmed with a response; see [RFC7641]
confirmed with a response; see [I-D.ietf-core-observe] section 3.6). section 3.6). However, the client might never receive the response
However, the client might never receive the response due to a due to a temporary network outage or worse, a server crash. Although
temporary network outage or worse, a server crash. Although a a network outage will also affect notifications so that the Observe
network outage will also affect notifications so that the Observe
garbage collection could apply, the server might simply happen not to garbage collection could apply, the server might simply happen not to
send CON notifications during that time. Alternative Observe send CON notifications during that time. Alternative Observe
lifetime models such as Stubbornness(tm) might also keep lifetime models such as Stubbornness(tm) might also keep
relationships alive for longer periods. relationships alive for longer periods.
Thus, it is best to carefully choose the Token value used with Thus, it is best to carefully choose the Token value used with
Observe requests. (The empty value will rarely be applicable.) One Observe requests. (The empty value will rarely be applicable.) One
option is to assign and re-use dedicated Tokens for each Observe option is to assign and re-use dedicated Tokens for each Observe
relationship the client will establish. The choice of Token values relationship the client will establish. The choice of Token values
also is critical in NoSec mode, to limit the effectiveness of also is critical in NoSec mode, to limit the effectiveness of
spoofing attacks. Here, the recommendation is to use randomized spoofing attacks. Here, the recommendation is to use randomized
Tokens with a length of at least four bytes (see Section 5.3.1 of Tokens with a length of at least four bytes (see Section 5.3.1 of
[RFC7252]). Thus, dedicated ranges within the 8-byte Token space [RFC7252]). Thus, dedicated ranges within the 8-byte Token space
should be used when in NoSec mode. This also solves the problem of should be used when in NoSec mode. This also solves the problem of
mismatching notifications after a client crash/restart. mismatching notifications after a client crash/restart.
When the client wishes to reinforce its interest in a resource, maybe When the client wishes to reinforce its interest in a resource, maybe
not really being sure whether the server has forgotten it or not, the not really being sure whether the server has forgotten it or not, the
Token value allocated to the Observe relationship is used to re- Token value allocated to the Observe relationship is used to re-
register that observation (see Section 3.3.1 of register that observation (see Section 3.3.1 of [RFC7641] for
[I-D.ietf-core-observe] for details): If the server is still aware of details): If the server is still aware of the relationship (an entry
the relationship (an entry with a matching endpoint and token is with a matching endpoint and token is already present in its list of
already present in its list of observers for the resource), it will observers for the resource), it will not add a new relationship but
not add a new relationship but will replace or update the existing will replace or update the existing one (Section 4.1 of [RFC7641]).
one (Section 4.1 of [I-D.ietf-core-observe]). If not, it will simply If not, it will simply establish a new registration which of course
establish a new registration which of course also uses the Token also uses the Token value.
value.
If the client sends an Observe request for the same resource with a If the client sends an Observe request for the same resource with a
new Token, this is not a protocol violation, because the new Token, this is not a protocol violation, because the
specification allows the client to observe the same resource in a specification allows the client to observe the same resource in a
different Observe relationship if the cache-key is different (e.g., different Observe relationship if the cache-key is different (e.g.,
requesting a different Content-Format). If the cache-key is not requesting a different Content-Format). If the cache-key is not
different, though, an additional Observe relationship just wastes the different, though, an additional Observe relationship just wastes the
server's resources, and is therefore not allowed; the server might server's resources, and is therefore not allowed; the server might
rely on this for its housekeeping. rely on this for its housekeeping.
skipping to change at page 15, line 23 skipping to change at page 15, line 23
service. Problems reported through the Parameter Problem message are service. Problems reported through the Parameter Problem message are
usually caused through a similar fundamental problem. usually caused through a similar fundamental problem.
The CoAP specification recommends to ignore Source Quench and Time The CoAP specification recommends to ignore Source Quench and Time
Exceeded ICMP messages, though. Source Quench messages were Exceeded ICMP messages, though. Source Quench messages were
originally intended to inform the sender to reduce the rate of originally intended to inform the sender to reduce the rate of
packets. However, this mechanism is deprecated through [RFC6633]. packets. However, this mechanism is deprecated through [RFC6633].
CoAP also comes with its own congestion control mechanism, which is CoAP also comes with its own congestion control mechanism, which is
already designed conservatively. One advanced mechanism that can be already designed conservatively. One advanced mechanism that can be
employed for better network utilization is CoCoA, employed for better network utilization is CoCoA,
[I-D.bormann-core-cocoa]. Time Exceeded messages often occur during [I-D.ietf-core-cocoa]. Time Exceeded messages often occur during
transient routing loops (unless they are caused by a too small transient routing loops (unless they are caused by a too small
initial Hop Limit value). initial Hop Limit value).
2.7. Programming Model 2.7. Programming Model
The event-driven approach, which is common in event-loop-based The event-driven approach, which is common in event-loop-based
firmware, has also proven very efficient for embedded operating firmware, has also proven very efficient for embedded operating
systems [TinyOS], [Contiki]. Note that an OS is not necessarily systems [TinyOS], [Contiki]. Note that an OS is not necessarily
required and a traditional firmware approach can suffice for Class 1 required and a traditional firmware approach can suffice for Class 1
devices. Event-driven systems use split-phase operations (i.e., devices. Event-driven systems use split-phase operations (i.e.,
skipping to change at page 17, line 49 skipping to change at page 17, line 49
end of the stub response. Acknowledgements still can be sent as end of the stub response. Acknowledgements still can be sent as
described before as long as no additional options are required to described before as long as no additional options are required to
describe the payload. describe the payload.
3.2. Retransmissions 3.2. Retransmissions
CoAP's reliable transmissions require the before-mentioned CoAP's reliable transmissions require the before-mentioned
retransmission buffers. Messages, such as the requests of a client, retransmission buffers. Messages, such as the requests of a client,
should be stored in serialized form. For servers, retransmissions should be stored in serialized form. For servers, retransmissions
apply for Confirmable separate responses and Confirmable apply for Confirmable separate responses and Confirmable
notifications [I-D.ietf-core-observe]. As separate responses stem notifications [RFC7641]. As separate responses stem from long-
from long-lasting resource handlers, the response should be stored lasting resource handlers, the response should be stored for
for retransmission instead of re-dispatching a stored request (which retransmission instead of re-dispatching a stored request (which
would allow for updating the representation). For Confirmable would allow for updating the representation). For Confirmable
notifications, please see Section 2.6, as simply storing the response notifications, please see Section 2.6, as simply storing the response
can break the concept of eventual consistency. can break the concept of eventual consistency.
String payloads such as JSON require a buffer to print to. By String payloads such as JSON require a buffer to print to. By
splitting the retransmission buffer into header and payload part, it splitting the retransmission buffer into header and payload part, it
can be reused. First to generate the payload and then storing the can be reused. First to generate the payload and then storing the
CoAP message by serializing into the same memory. Thus, providing a CoAP message by serializing into the same memory. Thus, providing a
retransmission for any message type can save the need for a separate retransmission for any message type can save the need for a separate
application buffer. This, however, requires an estimation about the application buffer. This, however, requires an estimation about the
skipping to change at page 19, line 10 skipping to change at page 19, line 10
individual retransmission counters and timers in the list entry need individual retransmission counters and timers in the list entry need
to be stored. When the notifications can be sent fast enough, even a to be stored. When the notifications can be sent fast enough, even a
single timer would suffice. Furthermore, per-resource buffers single timer would suffice. Furthermore, per-resource buffers
simplify the update with a new resource state during open deliveries. simplify the update with a new resource state during open deliveries.
3.4. Blockwise Transfers 3.4. Blockwise Transfers
Blockwise transfers have the main purpose of providing fragmentation Blockwise transfers have the main purpose of providing fragmentation
at the application layer, where partial information can be processed. at the application layer, where partial information can be processed.
This is not possible at lower layers such as 6LoWPAN, as only This is not possible at lower layers such as 6LoWPAN, as only
assembled packets can be passed up the stack. While assembled packets can be passed up the stack. While [RFC7959] also
[I-D.ietf-core-block] also anticipates atomic handling of blocks, anticipates atomic handling of blocks, i.e., only fully received CoAP
i.e., only fully received CoAP messages, this is not possible on messages, this is not possible on Class 1 devices.
Class 1 devices.
When receiving a blockwise transfer, each block is usually passed to When receiving a blockwise transfer, each block is usually passed to
a handler function that for instance performs stream processing or a handler function that for instance performs stream processing or
writes the blocks to external memory such as flash. Although there writes the blocks to external memory such as flash. Although there
are no restrictions in [I-D.ietf-core-block], it is beneficial for are no restrictions in [RFC7959], it is beneficial for Class 1
Class 1 devices to only allow ordered transmission of blocks. devices to only allow ordered transmission of blocks. Otherwise on-
Otherwise on-the-fly processing would not be possible. the-fly processing would not be possible.
When sending a blockwise transfer out of dynamically generated When sending a blockwise transfer out of dynamically generated
information, Class 1 devices usually do not have sufficient memory to information, Class 1 devices usually do not have sufficient memory to
print the full message into a buffer, and slice and send it in a print the full message into a buffer, and slice and send it in a
second step. For instance, if the CoRE Link Format at /.well-known/ second step. For instance, if the CoRE Link Format at /.well-known/
core is dynamically generated, a generator function is required that core is dynamically generated, a generator function is required that
generates slices of a large string with a specific offset length (a generates slices of a large string with a specific offset length (a
'sonprintf()'). This functionality is required recurrently and 'sonprintf()'). This functionality is required recurrently and
should be included in a library. should be included in a library.
skipping to change at page 22, line 48 skipping to change at page 22, line 48
application. A lower bound for LEISURE can be calculated as application. A lower bound for LEISURE can be calculated as
lb_Leisure = S * G / R lb_Leisure = S * G / R
where S is the estimated response size, G the group size, and R the where S is the estimated response size, G the group size, and R the
target data transfer rate (see [RFC7252] section 8.2). NSTART and target data transfer rate (see [RFC7252] section 8.2). NSTART and
PROBING_RATE depend on estimated network utilization. If the main PROBING_RATE depend on estimated network utilization. If the main
cause for loss are weak links, higher values can be chosen. cause for loss are weak links, higher values can be chosen.
Dynamic adjustments will be performed by advanced congestion control Dynamic adjustments will be performed by advanced congestion control
mechanisms such as [I-D.bormann-core-cocoa]. They are required if mechanisms such as [I-D.ietf-core-cocoa]. They are required if the
the main cause for message loss is network or endpoint congestion. main cause for message loss is network or endpoint congestion. Semi-
Semi-dynamic adjustments could be implemented by disseminating new dynamic adjustments could be implemented by disseminating new static
static transmission parameters to all nodes when the network transmission parameters to all nodes when the network configuration
configuration changes (e.g., new nodes are added or long-lasting changes (e.g., new nodes are added or long-lasting interference is
interference is detected). detected).
4.2. CoAP over IPv4 4.2. CoAP over IPv4
CoAP was designed for the properties of IPv6, which is dominating in CoAP was designed for the properties of IPv6, which is dominating in
constrained environments because of the 6LoWPAN adaption layer constrained environments because of the 6LoWPAN adaption layer
[RFC6282]. In particular, the size limitations of CoAP are tailored [RFC6282]. In particular, the size limitations of CoAP are tailored
to the minimal MTU of 1280 bytes. Until the transition towards IPv6 to the minimal MTU of 1280 bytes. Until the transition towards IPv6
converges, CoAP nodes might also communicate over IPv4, though. converges, CoAP nodes might also communicate over IPv4, though.
Sections 4.2 and 4.6 of the base specification [RFC7252] already Sections 4.2 and 4.6 of the base specification [RFC7252] already
provide guidance and implementation notes to handle the smaller provide guidance and implementation notes to handle the smaller
skipping to change at page 23, line 27 skipping to change at page 23, line 27
Another deployment issue in legacy IPv4 deployments is caused by Another deployment issue in legacy IPv4 deployments is caused by
Network Address Translators (NATs). The session timeouts are Network Address Translators (NATs). The session timeouts are
unpredictable and NATs may close UDP sessions with timeout as short unpredictable and NATs may close UDP sessions with timeout as short
as 60 seconds. This makes CoAP endpoints behind NATs practically as 60 seconds. This makes CoAP endpoints behind NATs practically
unreachable, even when they contact the remote endpoint with a public unreachable, even when they contact the remote endpoint with a public
IP address first. Incorrect behavior may also arise when the NAT IP address first. Incorrect behavior may also arise when the NAT
session heuristic changes the external port between two successive session heuristic changes the external port between two successive
CoAP messages. For the remote endpoint, this will look like two CoAP messages. For the remote endpoint, this will look like two
different CoAP endpoints on the same IP address. Such behavior can different CoAP endpoints on the same IP address. Such behavior can
be fatal for the resource directory registration interface. be fatal for the resource directory registration interface. Where
more resources are available on a node, CoAP over TCP and TLS
[I-D.ietf-core-coap-tcp-tls] can be used to obtain more civil
behavior from NATs [HomeGateway] with IPv4.
5. Binding to specific lower-layer APIs 5. Binding to specific lower-layer APIs
Implementing CoAP on specific lower-layer APIs appears to Implementing CoAP on specific lower-layer APIs appears to
consistently bring up certain less-known aspects of these APIs. This consistently bring up certain less-known aspects of these APIs. This
section is intended to alert implementers to such aspects. section is intended to alert implementers to such aspects.
5.1. Berkeley Socket Interface 5.1. Berkeley Socket Interface
5.1.1. Responding from the right address 5.1.1. Responding from the right address
skipping to change at page 25, line 24 skipping to change at page 25, line 31
information can be accessed heavily depends on the DTLS information can be accessed heavily depends on the DTLS
implementation used. Generic and portable CoAP implementations might implementation used. Generic and portable CoAP implementations might
want to provide an abstraction layer that can be used by application want to provide an abstraction layer that can be used by application
developers that implement resource handlers. It is recommended to developers that implement resource handlers. It is recommended to
keep the API of such an application layer close to popular HTTPS keep the API of such an application layer close to popular HTTPS
solutions that are available for the targeted platform, for instance, solutions that are available for the targeted platform, for instance,
mod_ssl or the Java Servlet API. mod_ssl or the Java Servlet API.
6. CoAP on various transports 6. CoAP on various transports
As specified in [RFC7252], CoAP is defined for two underlying As originally specified in [RFC7252], CoAP is defined for two
transports: UDP and DTLS. These transports are relatively similar in underlying transports: UDP and DTLS. These transports are relatively
terms of the properties they expose to their users. (The main similar in terms of the properties they expose to their users. (The
difference, apart from the increased security, is that DTLS provides main difference, apart from the increased security, is that DTLS
an abstraction of a connection, into which the endpoint abstraction provides an abstraction of a connection, into which the endpoint
is placed; in contrast, the UDP endpoint abstraction is based on abstraction is placed; in contrast, the UDP endpoint abstraction is
four-tuples of IP addresses and ports.) based on four-tuples of IP addresses and ports.)
Recently, the need to carry CoAP over other transports Recently, the need to carry CoAP over other transports
[I-D.silverajan-core-coap-alternative-transports] has led to [I-D.silverajan-core-coap-alternative-transports] has led to
specifications such as CoAP over TLS or TCP specifications such as CoAP over TCP, TLS or WebSockets
[I-D.tschofenig-core-coap-tcp-tls] or websockets [I-D.ietf-core-coap-tcp-tls], or even over non-IP transports such as
[I-D.savolainen-core-coap-websockets], or even over non-IP transports SMS [I-D.becker-core-coap-sms-gprs] or local serial lines
such as SMS [I-D.becker-core-coap-sms-gprs]. This section discusses [I-D.bormann-t2trg-slipmux]. This section discusses considerations
considerations that arise when handling these different transports in that arise when handling these different transports in an
an implementation. implementation.
6.1. CoAP over reliable transports
To cope with transports without reliable delivery (such as UDP and
DTLS), CoAP defines its own message layer, with acknowledgments,
timers, and retransmission. When CoAP is run over a transport that
provides its own reliability (such as TCP or TLS), running this
machinery would be redundant. Worse, keeping the machinery in place
is likely to lead to interoperability problems as it is unlikely to
be tested as well as on unreliable transports. Therefore,
[I-D.silverajan-core-coap-alternative-transports] was defined by
removing the message layer from CoAP and just running the request/
response layer directly on top of the reliable transport. This also
leads to a reduced (from the UDP/DTLS 4-byte header) header format.
Conversely, where reliable transports provide a byte stream
abstraction, some form of message delimiting had to be added, which
now needs to be handled in the CoAP implementation. The use of
reliable transports may reduce the disincentive for using messages
larger than optimal link layer packet sizes. Where different message
sizes are chosen by an application for reliable and for unreliable
transports, this can pose additional challenges for translators
(Section 6.2).
Where existing CoAP APIs expose details of the the message layer
(e.g., CON vs. NON, or assigning application layer semantics to
ACKs), using a reliable transport may require additional adjustments.
6.2. Translating between transports 6.1. Translating between transports
One obvious way to convey CoAP exchanges between different transports One obvious way to convey CoAP exchanges between different transports
is to run a CoAP proxy that supports both transports. The usual is to run a CoAP proxy that supports both transports. The usual
considerations for proxies apply. Section 6.2.1 discusses some considerations for proxies apply. Section 6.1.1 discusses some
additional considerations. additional considerations.
Where not much of the functionality of CoAP proxies (such as caching) Where not much of the functionality of CoAP proxies (such as caching)
is required, a simpler 1:1 translation may be possible, as discussed is required, a simpler 1:1 translation may be possible, as discussed
in Section 6.2.2. in Section 6.1.2.
6.2.1. Transport translation by proxies 6.1.1. Transport translation by proxies
(TBD. In particular, point out the obvious: fan-in/fan-out means (TBD. In particular, point out the obvious: fan-in/fan-out means
that separate message ID and token spaces need to be maintained at that separate message ID and token spaces need to be maintained at
the ends of the proxy.) the ends of the proxy.)
One more CoAP specific function of a transport translator proxy may One more CoAP specific function of a transport translator proxy may
be to convert between different block sizes, e.g. between a TCP be to convert between different block sizes, e.g. between a TCP
connection that can tolerate large blocks and UDP over a constrained connection that can tolerate large blocks and UDP over a constrained
node network. node network.
6.2.2. One-to-one Transport translation 6.1.2. One-to-one Transport translation
A translator with reduced requirements for state maintenance can be A translator with reduced requirements for state maintenance can be
constructed when no fan-in or fan-out is required, and when the constructed when no fan-in or fan-out is required, and when the
namespace lifetimes of the two sides can be made to coincide. For namespace lifetimes of the two sides can be made to coincide. For
this one-to-one translation, there is no need to manage message-ID this one-to-one translation, there is no need to manage message-ID
and Token value spaces for both sides separately. So, a simple UDP- and Token value spaces for both sides separately. If the message
to-UDP one-to-one translator could simply copy the messages (among layer on both sides is similar enough, little message layer
other applications, this might be useful for translation between IPv4 processing is necessary. So, a simple UDP-to-UDP one-to-one
and IPv6 spaces). Similarly, a DTLS-to-TCP translator could be built translator could simply copy the messages (among other applications,
that executes the message layer (deduplication, retransmission) on this might be useful for translation between IPv4 and IPv6 spaces).
the DTLS side, and repackages the CoAP header (add/remove the length Similarly, a WebSockets-to-TCP translator could be built that runs
information, and remove/add the message ID and message type) between the WebSockets protocol and framing on one side, and repackages the
the DTLS and the TCP side. CoAP header (add/zero out the length information) between the
WebSockets and the TCP side.
By definition, such a simple one-to-one translator needs to shut down By definition, such a simple one-to-one translator needs to shut down
the connection on one side when the connection on the other side the connection on one side when the connection on the other side
terminates. However, a UDP-to-TCP one-to-one translator cannot terminates. However, a UDP-to-TCP one-to-one translator cannot
simply shut down the UDP endpoint when the TCP endpoint vanishes simply shut down the UDP endpoint when the TCP endpoint vanishes
because the TCP connection closes, so some additional management of because the TCP connection closes, so some additional management of
state will be necessary. state will be necessary (in particular with respect to token values).
Also, a UDP-to-TCP one-to-one translator needs to run a full message
layer (retransmission, deduplication) on the UDP side. In summary, a
UDP-to-TCP translator will look enough like a proxy that it may be
more appropriate to construct it as one.
7. IANA considerations 7. IANA considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Security considerations 8. Security considerations
TBD TBD
9. Acknowledgements 9. Acknowledgements
Esko Dijk contributed the sequential MID optimization. Xuan He Esko Dijk contributed the sequential MID optimization. Xuan He
provided help creating and improved the state machine charts. provided help creating and improved the state machine charts.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.bormann-core-cocoa] [I-D.ietf-core-cocoa]
Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
"CoAP Simple Congestion Control/Advanced", draft-bormann- "CoAP Simple Congestion Control/Advanced", draft-ietf-
core-cocoa-02 (work in progress), July 2014. core-cocoa-00 (work in progress), October 2016.
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP",
draft-ietf-core-block-17 (work in progress), March 2015.
[I-D.ietf-core-observe]
Hartke, K., "Observing Resources in CoAP", draft-ietf-
core-observe-16 (work in progress), December 2014.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011. DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, March 2012. and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012,
<http://www.rfc-editor.org/info/rfc6570>.
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages",
RFC 6633, May 2012. RFC 6633, DOI 10.17487/RFC6633, May 2012,
<http://www.rfc-editor.org/info/rfc6633>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June Protocol (HTTP/1.1): Message Syntax and Routing",
2014. RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014. Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<http://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<http://www.rfc-editor.org/info/rfc7959>.
10.2. Informative References 10.2. Informative References
[Contiki] Dunkels, A., Groenvall, B., and T. Voigt, "Contiki - a [Contiki] Dunkels, A., Groenvall, B., and T. Voigt, "Contiki - a
Lightweight and Flexible Operating System for Tiny Lightweight and Flexible Operating System for Tiny
Networked Sensors", Proceedings of the First IEEE Workshop Networked Sensors", Proceedings of the First IEEE
on Embedded Networked Sensors, November 2004. Workshop on Embedded Networked Sensors, November 2004.
[HomeGateway]
Eggert, L., "An experimental study of home gateway
characteristics", Proceedings of the 10th annual
conference on Internet measurement, 2010.
[I-D.becker-core-coap-sms-gprs] [I-D.becker-core-coap-sms-gprs]
Becker, M., Li, K., Kuladinithi, K., and T. Poetsch, Kuladinithi, K., Becker, M., Li, K., and T. Poetsch,
"Transport of CoAP over SMS", draft-becker-core-coap-sms- "Transport of CoAP over SMS", draft-becker-core-coap-sms-
gprs-05 (work in progress), August 2014. gprs-06 (work in progress), February 2017.
[I-D.savolainen-core-coap-websockets] [I-D.bormann-t2trg-slipmux]
Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over Bormann, C. and T. Kaupat, "Slipmux: Using an UART
WebSockets", draft-savolainen-core-coap-websockets-04 interface for diagnostics, configuration, and packet
(work in progress), March 2015. transfer", draft-bormann-t2trg-slipmux-00 (work in
progress), January 2017.
[I-D.ietf-core-coap-tcp-tls]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
draft-ietf-core-coap-tcp-tls-07 (work in progress), March
2017.
[I-D.silverajan-core-coap-alternative-transports] [I-D.silverajan-core-coap-alternative-transports]
Silverajan, B. and T. Savolainen, "CoAP Communication with Silverajan, B. and T. Savolainen, "CoAP Communication with
Alternative Transports", draft-silverajan-core-coap- Alternative Transports", draft-silverajan-core-coap-
alternative-transports-08 (work in progress), June 2015. alternative-transports-09 (work in progress), December
2015.
[I-D.tschofenig-core-coap-tcp-tls]
Bormann, C., Lemay, S., Technologies, Z., and H.
Tschofenig, "A TCP and TLS Transport for the Constrained
Application Protocol (CoAP)", draft-tschofenig-core-coap-
tcp-tls-04 (work in progress), June 2015.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for "Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003. IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003,
<http://www.rfc-editor.org/info/rfc3542>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010,
<http://www.rfc-editor.org/info/rfc5927>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014. Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[TinyOS] Levis, P., Madden, S., Polastre, J., Szewczyk, R., [TinyOS] Levis, P., Madden, S., Polastre, J., Szewczyk, R.,
Whitehouse, K., Woo, A., Gay, D., Woo, A., Hill, J., Whitehouse, K., Woo, A., Gay, D., Woo, A., Hill, J.,
Welsh, M., Brewer, E., and D. Culler, "TinyOS: An Welsh, M., Brewer, E., and D. Culler, "TinyOS: An
Operating System for Sensor Networks", Ambient Operating System for Sensor Networks", Ambient
intelligence, Springer (Berlin Heidelberg), ISBN intelligence, Springer (Berlin Heidelberg),
978-3-540-27139-0, 2005. ISBN 978-3-540-27139-0, 2005.
Authors' Addresses Authors' Addresses
Matthias Kovatsch Matthias Kovatsch
ETH Zurich ETH Zurich
Universitaetstrasse 6 Universitaetstrasse 6
CH-8092 Zurich CH-8092 Zurich
Switzerland Switzerland
Email: kovatsch@inf.ethz.ch Email: kovatsch@inf.ethz.ch
 End of changes. 44 change blocks. 
157 lines changed or deleted 155 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/