draft-ietf-lwig-coap-05.txt   draft-ietf-lwig-coap-06.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: May 3, 2018 C. Bormann, Ed. Expires: January 3, 2019 C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
October 30, 2017 July 02, 2018
CoAP Implementation Guidance CoAP Implementation Guidance
draft-ietf-lwig-coap-05 draft-ietf-lwig-coap-06
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 33 skipping to change at page 1, line 33
RFC 7252, memory optimizations, and customized protocol parameters. RFC 7252, memory optimizations, and customized protocol parameters.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 May 3, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Duplicate Rejection . . . . . . . . . . . . . . . . . 7 2.3.1. Duplicate Rejection . . . . . . . . . . . . . . . . . 7
2.3.2. MID Namespaces . . . . . . . . . . . . . . . . . . . 7 2.3.2. MID Namespaces . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Tokens for Observe . . . . . . . . . . . . . . . . . 10 2.4.1. Tokens for Observe . . . . . . . . . . . . . . . . . 11
2.4.2. Tokens for Blockwise Transfers . . . . . . . . . . . 11 2.4.2. Tokens for Blockwise Transfers . . . . . . . . . . . 12
2.5. Transmission States . . . . . . . . . . . . . . . . . . . 11 2.5. Transmission States . . . . . . . . . . . . . . . . . . . 12
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
2.7. Programming Model . . . . . . . . . . . . . . . . . . . . 15 2.7. Programming Model . . . . . . . . . . . . . . . . . . . . 15
2.7.1. Client . . . . . . . . . . . . . . . . . . . . . . . 15 2.7.1. Client . . . . . . . . . . . . . . . . . . . . . . . 16
2.7.2. Server . . . . . . . . . . . . . . . . . . . . . . . 16 2.7.2. Server . . . . . . . . . . . . . . . . . . . . . . . 16
3. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 17 3. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Message Buffers . . . . . . . . . . . . . . . . . . . . . 17 3.1. Message Buffers . . . . . . . . . . . . . . . . . . . . . 17
3.2. Retransmissions . . . . . . . . . . . . . . . . . . . . . 17 3.2. Retransmissions . . . . . . . . . . . . . . . . . . . . . 18
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.4.1. Generic Proxying of Block Messages . . . . . . . . . 19
4. Alternative Configurations . . . . . . . . . . . . . . . . . 22 3.4.2. Atomic Blockwise Operations . . . . . . . . . . . . . 20
4.1. Transmission Parameters . . . . . . . . . . . . . . . . . 22 3.5. Deduplication with Sequential MIDs . . . . . . . . . . . 20
4.2. CoAP over IPv4 . . . . . . . . . . . . . . . . . . . . . 23 4. Alternative Configurations . . . . . . . . . . . . . . . . . 23
5. Binding to specific lower-layer APIs . . . . . . . . . . . . 23 4.1. Transmission Parameters . . . . . . . . . . . . . . . . . 23
5.1. Berkeley Socket Interface . . . . . . . . . . . . . . . . 23 4.2. CoAP over IPv4 . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. Responding from the right address . . . . . . . . . . 23 5. Binding to specific lower-layer APIs . . . . . . . . . . . . 24
5.1.2. Handling ICMP errors . . . . . . . . . . . . . . . . 24 5.1. Berkeley Socket Interface . . . . . . . . . . . . . . . . 24
5.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1.1. Responding from the right address . . . . . . . . . . 24
5.3. Multicast detection . . . . . . . . . . . . . . . . . . . 25 5.1.2. Handling ICMP errors . . . . . . . . . . . . . . . . 25
5.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. CoAP on various transports . . . . . . . . . . . . . . . . . 25 5.3. Multicast detection . . . . . . . . . . . . . . . . . . . 26
6.1. CoAP over reliable transports . . . . . . . . . . . . . . 26 5.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Translating between transports . . . . . . . . . . . . . 26
6.2.1. Transport translation by proxies . . . . . . . . . . 26 6. CoAP on various transports . . . . . . . . . . . . . . . . . 26
6.2.2. One-to-one Transport translation . . . . . . . . . . 27 6.1. CoAP over reliable transports . . . . . . . . . . . . . . 27
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 27 6.2. Translating between transports . . . . . . . . . . . . . 27
8. Security considerations . . . . . . . . . . . . . . . . . . . 27 6.2.1. Transport translation by proxies . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 6.2.2. One-to-one Transport translation . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 27 8. Security considerations . . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 28 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The Constrained Application Protocol [RFC7252] has been designed The Constrained Application Protocol [RFC7252] has been designed
specifically for machine-to-machine communication in networks with specifically for machine-to-machine communication in networks with
very constrained nodes. Typical application scenarios therefore very constrained nodes. Typical application scenarios therefore
include building automation, process optimization, and the Internet include building automation, process optimization, and the Internet
of Things. The major design objectives have been set on small of Things. The major design objectives have been set on small
protocol overhead, robustness against packet loss, and against high protocol overhead, robustness against packet loss, and against high
latency induced by small bandwidth shares or slow request processing latency induced by small bandwidth shares or slow request processing
skipping to change at page 3, line 50 skipping to change at page 4, line 5
units is easy to parse and is carefully defined to avoid creation of units is easy to parse and is carefully defined to avoid creation of
state in servers where possible. state in servers where possible.
Although these features enable lightweight implementations of the Although these features enable lightweight implementations of the
Constrained Application Protocol, there is still a tradeoff between Constrained Application Protocol, there is still a tradeoff between
robustness and latency of constrained nodes on one hand and resource robustness and latency of constrained nodes on one hand and resource
demands on the other. For constrained nodes of Class 1 or even demands on the other. For constrained nodes of Class 1 or even
Class 2 [RFC7228], the most limiting factors usually are dynamic Class 2 [RFC7228], the most limiting factors usually are dynamic
memory needs, static code size, and energy. Most implementations memory needs, static code size, and energy. Most implementations
therefore need to optimize internal buffer usage, omit idle protocol therefore need to optimize internal buffer usage, omit idle protocol
feature, and maximize sleeping cycles. features, and maximize sleeping cycles.
The present document gives possible strategies to solve this tradeoff The present document gives possible strategies to solve this tradeoff
for very constrained nodes (i.e., Class 1). For this, it provides for very constrained nodes (i.e., Class 1). For this, it provides
guidance on correct implementation of the CoAP specification guidance on correct implementation of the CoAP specification
[RFC7252], memory optimizations, and customized protocol parameters. [RFC7252], memory optimizations, and customized protocol parameters.
2. Protocol Implementation 2. Protocol Implementation
In the programming styles supported by very simple operating systems In the programming styles supported by very simple operating systems
as found on constrained nodes, preemptive multi-threading is not an as found on constrained nodes, preemptive multi-threading is not an
skipping to change at page 5, line 5 skipping to change at page 5, line 7
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 [RFC7641] of CoAP. It allows servers is solved by the Observe option [RFC7641] of CoAP. It allows servers
to initiate communication and send push notifications to interested to initiate communication and send push notifications to interested
client nodes. This allows a more efficient and also more natural client nodes. This allows a more efficient and also more natural
model for CoAP-based applications, where the information source is an model for CoAP-based applications, where the information source is an
origin server, which can also benefit from caching. origin server, which can also benefit from caching. Publish-
subscribe brokers [I-D.ietf-core-coap-pubsub] may be deployed to act
in the server role on behalf of constrained clients.
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 base header has to be parsed and
and thereby checked if it is a CoAP message. Since the encoding is thereby checked if it is a valid CoAP message. For UDP datagrams,
very dense, only a wrong version or a datagram size smaller than four the version identifier or a size smaller than four bytes identify
bytes identify non-CoAP datagrams. These need to be silently non-CoAP data. These datagrams need to be silently ignored. Other
ignored. Other message format errors, such as an incomplete datagram message format errors, such as an incomplete datagram or the usage of
or the usage of reserved values, may need to be rejected with a Reset reserved values, may need to be rejected with a Reset (RST) message
(RST) message (see Section 4.2 and 4.3 of [RFC7252] for details). (see Section 4.2 and 4.3 of [RFC7252] for details).
Next the Token is read based on the TKL field. For the options
following, there are two alternatives: either process them on the fly As CoAP over TCP has a different base header, the Length field must
when an option is accessed or initially parse all values into an be parsed to determine the message size. As this field may have up
internal data structure. to five bytes, it may be extend over TCP segment boundaries. For
CoAP over WebSockets the actual message length is given by the
WebSocket frame hence the Length field is always zero.
Next, the token length is read based on the TKL field which is for
all transports contained in the four least significant bits of the
first byte. The (possibly empty) Token itself is located immediately
after the four-byte base header for UDP, while for TCP and
WebSockets, it follows the variable Length field and Code byte.
For the options following the Token, there are two alternatives:
either process them on the fly when an option is accessed or
initially parse all values into an internal data structure.
2.2.1. On-the-fly Processing 2.2.1. On-the-fly Processing
The advantage of on-the-fly processing is that no additional memory The advantage of on-the-fly processing is that no additional memory
needs to be allocated to store the option values, which are stored needs to be allocated to store the option values, which are stored
efficiently inline in the buffer for incoming messages. Once the efficiently inline in the buffer for incoming messages. Once the
message is accepted for further processing, the set of options message is accepted for further processing, the set of options
contained in the received message must be decoded to check for contained in the received message must be decoded to check for
unknown critical options. To avoid multiple passes through the unknown critical options. To avoid multiple passes through the
option list, the option parser might maintain a bit-vector where each option list, the option parser might maintain a bit-vector where each
skipping to change at page 6, line 27 skipping to change at page 6, line 43
to on-the-fly processing). This approach also benefits from a to on-the-fly processing). This approach also benefits from a
bitmap. Otherwise special values must be reserved to encode an unset bitmap. Otherwise special values must be reserved to encode an unset
option, which might require a larger type than required for the option, which might require a larger type than required for the
actual value range (e.g., a 32-bit integer instead of 16-bit). actual value range (e.g., a 32-bit integer instead of 16-bit).
Many of the byte strings (e.g., the URI) are usually not required Many of the byte strings (e.g., the URI) are usually not required
when generating the response. When all important values are copied when generating the response. When all important values are copied
(e.g., the Token, which needs to be mirrored), the internal data (e.g., the Token, which needs to be mirrored), the internal data
structure facilitates using the buffer for incoming messages also for structure facilitates using the buffer for incoming messages also for
the assembly of outgoing messages - which can be the shared IP buffer the assembly of outgoing messages - which can be the shared IP buffer
provided by the OS. provided by the operating system.
Setting options for outgoing messages is also easier with an internal Setting options for outgoing messages is also easier with an internal
data structure. Application developers can set options independent data structure. Application developers can set options independent
from the option number and do not need to care about the order for from the option number and do not need to care about the order for
the delta encoding. The CoAP encoding is applied in a serialization the delta encoding. The CoAP encoding is applied in a serialization
step before sending. In contrast, assembling outgoing messages with step before sending. In contrast, assembling outgoing messages with
on-the-fly processing requires either extensive memmove operations to on-the-fly processing requires either extensive memmove operations to
insert new options, or restrictions for developers to set options in insert new options, or restrictions for developers to set options in
their correct order. their correct order.
skipping to change at page 19, line 30 skipping to change at page 19, line 35
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.
3.4.1. Generic Proxying of Block Messages
Proxies cannot ignore the Block options by specification, because the
options Block1 and Block2 are not safe-to-forward. The rationale
behind this design decision is that servers might not be able to
distinguish blocks originating from different senders once they have
been forwarded by a CoAP proxy. For atomic operations where all
blocks are assembled before actually executing the desired operation,
this could lead to inconsistent state on the server side.
To ensure that this does not happen, a proxy can add the Request-Tag
option (see [I-D.ietf-core-echo-request-tag]) containing data that
uniquely identifies the originating endpoint in the proxy namespace.
3.4.2. Atomic Blockwise Operations
When an implementation needs to assemble blocks from block-wise
transfers, applications need to create an identifier to group
messages that belong together. This "Block Key" at least contains:
o The source endpoint (e.g., IP address and port in the UDP case),
o the destination endpoint,
o the Cache-Key (as updated in [RFC7252]), and
o all options that are proxy unsafe and not explicitly described as
safe for block-wise assembly.
The only known options safe for block-wise assembly are the options
Block1 and Block2 [RFC7959].
For the Block1 phase, the request payload is excluded from the
identifier generation as it is just being assembled.
If a message is received that is not the start of a block-wise
operation has a Block Key that is not known, and the implementation
needs to act atomically on a request body, it must answer 4.08
(Request Entity Incomplete).
Conversely, clients should be aware that requests whose Block Key
matches can be interpreted by the server atomically. This especially
affects proxies (see Section 3.4.1).
3.5. Deduplication with Sequential MIDs 3.5. Deduplication with Sequential MIDs
CoAP's duplicate rejection functionality can be straightforwardly CoAP's duplicate rejection functionality can be straightforwardly
implemented in a CoAP endpoint by storing, for each remote CoAP implemented in a CoAP endpoint by storing, for each remote CoAP
endpoint ("peer") that it communicates with, a list of recently endpoint ("peer") that it communicates with, a list of recently
received CoAP Message IDs (MIDs) along with some timing information. received CoAP Message IDs (MIDs) along with some timing information.
A CoAP message from a peer with a MID that is in the list for that A CoAP message from a peer with a MID that is in the list for that
peer can simply be discarded. peer can simply be discarded.
The timing information in the list can then be used to time out The timing information in the list can then be used to time out
skipping to change at page 25, line 45 skipping to change at page 26, line 47
As specified in [RFC7252], CoAP is defined for two underlying As specified in [RFC7252], CoAP is defined for two underlying
transports: UDP and DTLS. These transports are relatively similar in transports: UDP and DTLS. These transports are relatively similar in
terms of the properties they expose to their users. (The main terms of the properties they expose to their users. (The main
difference, apart from the increased security, is that DTLS provides difference, apart from the increased security, is that DTLS provides
an abstraction of a connection, into which the endpoint abstraction an abstraction of a connection, into which the endpoint abstraction
is placed; in contrast, the UDP endpoint abstraction is based on is placed; in contrast, the UDP endpoint abstraction is based on
four-tuples of IP addresses and ports.) 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 TLS or TCP or WebSockets[RFC8323],
[I-D.ietf-core-coap-tcp-tls] or websockets or even over non-IP transports such as SMS
[I-D.savolainen-core-coap-websockets], or even over non-IP transports [I-D.becker-core-coap-sms-gprs]. This section discusses
such as SMS [I-D.becker-core-coap-sms-gprs]. This section discusses
considerations that arise when handling these different transports in considerations that arise when handling these different transports in
an implementation. an implementation.
6.1. CoAP over reliable transports 6.1. CoAP over reliable transports
To cope with transports without reliable delivery (such as UDP and To cope with transports without reliable delivery (such as UDP and
DTLS), CoAP defines its own message layer, with acknowledgments, DTLS), CoAP defines its own message layer, with acknowledgments,
timers, and retransmission. When CoAP is run over a transport that timers, and retransmission. When CoAP is run over a transport that
provides its own reliability (such as TCP or TLS), running this provides its own reliability (such as TCP or TLS), running this
machinery would be redundant. Worse, keeping the machinery in place machinery would be redundant. Worse, keeping the machinery in place
skipping to change at page 27, line 39 skipping to change at page 28, line 39
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.
Christian Amsuess provided input on forwarding block messages by
proxies and usage of the Request-Tag option.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-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-ietf- "CoAP Simple Congestion Control/Advanced", draft-ietf-
core-cocoa-01 (work in progress), March 2017. core-cocoa-03 (work in progress), February 2018.
[RFC6282] Hui, J., Ed. 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,
DOI 10.17487/RFC6282, September 2011, <https://www.rfc- DOI 10.17487/RFC6282, September 2011,
editor.org/info/rfc6282>. <https://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, and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012, <https://www.rfc- DOI 10.17487/RFC6570, March 2012,
editor.org/info/rfc6570>. <https://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, DOI 10.17487/RFC6633, May 2012, RFC 6633, DOI 10.17487/RFC6633, May 2012,
<https://www.rfc-editor.org/info/rfc6633>. <https://www.rfc-editor.org/info/rfc6633>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://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, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, <https://www.rfc- DOI 10.17487/RFC7252, June 2014,
editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, <https://www.rfc- DOI 10.17487/RFC7641, September 2015,
editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, <https://www.rfc- DOI 10.17487/RFC7959, August 2016,
editor.org/info/rfc7959>. <https://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 Networked Sensors", Proceedings of the First IEEE
Workshop on Embedded Networked Sensors, November 2004. Workshop on Embedded Networked Sensors, November 2004.
[I-D.becker-core-coap-sms-gprs] [I-D.becker-core-coap-sms-gprs]
Kuladinithi, K., Becker, M., Li, 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-06 (work in progress), February 2017. gprs-06 (work in progress), February 2017.
[I-D.ietf-core-coap-tcp-tls] [I-D.ietf-core-coap-pubsub]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Koster, M., Keranen, A., and J. Jimenez, "Publish-
Silverajan, B., and B. Raymor, "CoAP (Constrained Subscribe Broker for the Constrained Application Protocol
Application Protocol) over TCP, TLS, and WebSockets", (CoAP)", draft-ietf-core-coap-pubsub-04 (work in
draft-ietf-core-coap-tcp-tls-09 (work in progress), May progress), March 2018.
2017.
[I-D.savolainen-core-coap-websockets] [I-D.ietf-core-echo-request-tag]
Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over Amsuess, C., Mattsson, J., and G. Selander, "Echo and
WebSockets", draft-savolainen-core-coap-websockets-07 Request-Tag", draft-ietf-core-echo-request-tag-02 (work in
(work in progress), June 2016. progress), June 2018.
[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-10 (work in progress), July 2017. alternative-transports-11 (work in progress), March 2018.
[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, DOI 10.17487/RFC3542, May 2003, IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003,
<https://www.rfc-editor.org/info/rfc3542>. <https://www.rfc-editor.org/info/rfc3542>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010, <https://www.rfc- DOI 10.17487/RFC5927, July 2010,
editor.org/info/rfc5927>. <https://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, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, <https://www.rfc- DOI 10.17487/RFC7228, May 2014,
editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.
[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), intelligence, Springer (Berlin Heidelberg),
ISBN 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
Olaf Bergmann Olaf Bergmann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Email: bergmann@tzi.org Email: bergmann@tzi.org
Carsten Bormann (editor) Carsten Bormann (editor)
Universitaet Bremen TZI Universitaet Bremen TZI
 End of changes. 33 change blocks. 
83 lines changed or deleted 150 lines changed or added

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