draft-ietf-lwig-coap-01.txt   draft-ietf-lwig-coap-02.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 5, 2015 Universitaet Bremen TZI Expires: December 29, 2015 C. Bormann, Ed.
E. Dijk
Philips Research
X. He
Hitachi (China) R&D Corp.
C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
July 04, 2014 June 27, 2015
CoAP Implementation Guidance CoAP Implementation Guidance
draft-ietf-lwig-coap-01 draft-ietf-lwig-coap-02
Abstract Abstract
The Constrained Application Protocol (CoAP) is designed for resource- The Constrained Application Protocol (CoAP) is designed for resource-
constrained nodes and networks, e.g., sensor nodes in a low-power constrained nodes and networks, e.g., 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 45 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 5, 2015. This Internet-Draft will expire on December 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 32 skipping to change at page 2, line 23
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. Duplicate Rejection . . . . . . . . . . . . . . . . . . . 6 2.3. Duplicate Rejection . . . . . . . . . . . . . . . . . . . 6
2.4. Token Usage . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Token Usage . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1. Tokens for Observe . . . . . . . . . . . . . . . . . 7 2.4.1. Tokens for Observe . . . . . . . . . . . . . . . . . 7
2.4.2. Tokens for Blockwise Transfers . . . . . . . . . . . 8 2.4.2. Tokens for Blockwise Transfers . . . . . . . . . . . 8
2.5. Transmission States . . . . . . . . . . . . . . . . . . . 8 2.5. Transmission States . . . . . . . . . . . . . . . . . . . 9
2.5.1. Request/Response Layer . . . . . . . . . . . . . . . 9 2.5.1. Request/Response Layer . . . . . . . . . . . . . . . 9
2.5.2. Message Layer . . . . . . . . . . . . . . . . . . . . 10 2.5.2. Message Layer . . . . . . . . . . . . . . . . . . . . 10
2.6. Out-of-band Information . . . . . . . . . . . . . . . . . 11 2.6. Out-of-band Information . . . . . . . . . . . . . . . . . 11
2.7. Programming Model . . . . . . . . . . . . . . . . . . . . 11 2.7. Programming Model . . . . . . . . . . . . . . . . . . . . 12
2.7.1. Client . . . . . . . . . . . . . . . . . . . . . . . 12 2.7.1. Client . . . . . . . . . . . . . . . . . . . . . . . 12
2.7.2. Server . . . . . . . . . . . . . . . . . . . . . . . 12 2.7.2. Server . . . . . . . . . . . . . . . . . . . . . . . 13
3. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Message Buffers . . . . . . . . . . . . . . . . . . . . . 13 3.1. Message Buffers . . . . . . . . . . . . . . . . . . . . . 14
3.2. Retransmissions . . . . . . . . . . . . . . . . . . . . . 14 3.2. Retransmissions . . . . . . . . . . . . . . . . . . . . . 14
3.3. Observable Resources . . . . . . . . . . . . . . . . . . 14 3.3. Observable Resources . . . . . . . . . . . . . . . . . . 15
3.4. Blockwise Transfers . . . . . . . . . . . . . . . . . . . 15 3.4. Blockwise Transfers . . . . . . . . . . . . . . . . . . . 16
3.5. Deduplication with Sequential MIDs . . . . . . . . . . . 15 3.5. Deduplication with Sequential MIDs . . . . . . . . . . . 16
4. Alternative Configurations . . . . . . . . . . . . . . . . . 18 4. Alternative Configurations . . . . . . . . . . . . . . . . . 19
4.1. Transmission Parameters . . . . . . . . . . . . . . . . . 18 4.1. Transmission Parameters . . . . . . . . . . . . . . . . . 19
4.2. CoAP over IPv4 . . . . . . . . . . . . . . . . . . . . . 19 4.2. CoAP over IPv4 . . . . . . . . . . . . . . . . . . . . . 20
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 5. Binding to specific lower-layer APIs . . . . . . . . . . . . 20
6. Security considerations . . . . . . . . . . . . . . . . . . . 19 5.1. Berkeley Socket Interface . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.1. Responding from the right address . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 19 5.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 20 5.3. Multicast detection . . . . . . . . . . . . . . . . . . . 21
5.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 6. CoAP on various transports . . . . . . . . . . . . . . . . . 22
6.1. CoAP over reliable transports . . . . . . . . . . . . . . 22
6.2. Translating between transports . . . . . . . . . . . . . 23
6.2.1. Transport translation by proxies . . . . . . . . . . 23
6.2.2. One-to-one Transport translation . . . . . . . . . . 23
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Security considerations . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 7, line 45 skipping to change at page 7, line 45
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 even allows for one-time usage throughout the 8-byte range for Tokens even allows for one-time usage throughout the
lifetime of a client node. When DTLS is used, client crashes/ 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 [I-D.ietf-core-observe], a request will be
answered with multiple notifications and it can become hard to answered with multiple notifications and it is important to continue
determine the end of a Token lifetime. When establishing an Observe keeping track of the Token that was used for the request - its
lifetime will end much later. Upon establishing an Observe
relationship, the Token is registered at the server. Hence, the relationship, the Token is registered at the server. Hence, the
client partially loses control of the used Token. A client can client's use of that specific Token is now limited to controlling the
attempt to cancel the relationship, which frees the Token upon Observation relationship. A client can use it to cancel the
success (i.e., the message with an Observe Option with the value set relationship, which frees the Token upon success (i.e., the message
to 'deregister' (1) is acknowledged; see [I-D.ietf-core-observe] with an Observe Option with the value set to 'deregister' (1) is
section 3.6). However, the client might never receive the ACK due to acknowledged; see [I-D.ietf-core-observe] section 3.6). However, the
a temporary network outages or worse, a server crash. Although a client might never receive the ACK due to a temporary network outage
network outage will also affect notifications so that the Observe or worse, a server crash. Although a network outage will also affect
garbage collection could apply, the server might simply not send CON notifications so that the Observe garbage collection could apply, the
notifications during that time. Alternative Observe lifetime models server might simply happen not to send CON notifications during that
such as Stubbornness(tm) might also keep relationships alive for time. Alternative Observe lifetime models such as Stubbornness(tm)
longer periods. might also keep relationships alive for longer periods.
Thus, Observe requests should carefully chose the value (and the Thus, it is best to carefully chose the Token value used with Observe
empty value will rarely be applicable). One option is to assign and requests. (The empty value will rarely be applicable.) One option
re-use dedicated Tokens for each Observe relationship the client will is to assign and re-use dedicated Tokens for each Observe
establish. This is, however, critical for spoofing attacks in NoSec relationship the client will establish. The choice of Token values
mode. The recommendation is to use randomized Tokens with a length also is critical in NoSec mode, to limit the effectiveness of
of at least four bytes (see Section 5.3.1 of [RFC7252]). Thus, spoofing attacks. Here, the recommendation is to use randomized
dedicated ranges within the 8-byte Token space should be used when in Tokens with a length of at least four bytes (see Section 5.3.1 of
NoSec mode. This also solves the problem of mismatching [RFC7252]). Thus, dedicated ranges within the 8-byte Token space
notifications after a client crash/restart. should be used when in NoSec mode. This also solves the problem of
mismatching notifications after a client crash/restart.
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
Token value allocated to the Observe relationship is used to re-
register that observation (see Section 3.3.1 of
[I-D.ietf-core-observe] for details): If the server is still aware of
the relationship (an entry with a matching endpoint and token is
already present in its list of observers for the resource), it will
not add a new relationship but will replace or update the existing
one (Section 4.1 of [I-D.ietf-core-observe]). If not, it will simply
establish a new registration which of course also uses the Token
value.
If the client sends an Observe request for the same resource with a
new Token, this is not a protocol violation, because the
specification allows the client to observe the same resource in a
different Observe relationship if the cache-key is different (e.g.,
requesting a different Content-Format). If the cache-key is not
different, though, an additional Observe relationship just wastes the
server's resources, and is therefore not allowed; the server might
rely on this for its housekeeping.
2.4.2. Tokens for Blockwise Transfers 2.4.2. Tokens for Blockwise Transfers
In general, blockwise transfers are independent from the Token and In general, blockwise transfers are independent from the Token and
are correlated through client endpoint address and server address and are correlated through client endpoint address and server address and
resource path (destination URI). Thus, each block may be transferred resource path (destination URI). Thus, each block may be transferred
using a different Token. Still it can be beneficial to use the same using a different Token. Still it can be beneficial to use the same
Token (it is freed upon reception of a response block) for all Token (it is freed upon reception of a response block) for all
blocks, e.g., to easily route received blocks to the same response blocks, e.g., to easily route received blocks to the same response
handler. handler.
skipping to change at page 9, line 15 skipping to change at page 9, line 37
2.5.1. Request/Response Layer 2.5.1. Request/Response Layer
Figure 1 depicts the two states at the request/response layer of a Figure 1 depicts the two states at the request/response layer of a
CoAP client. When a request is issued, a "reliable_send" or CoAP client. When a request is issued, a "reliable_send" or
"unreliable_send" is triggered at the message layer. The WAITING "unreliable_send" is triggered at the message layer. The WAITING
state can be left through three transitions: Either the client state can be left through three transitions: Either the client
cancels the request and triggers cancellation of a CON transmission cancels the request and triggers cancellation of a CON transmission
at the message layer, the client receives a failure event from the at the message layer, the client receives a failure event from the
message layer, or a receive event containing a response. message layer, or a receive event containing a response.
+------------CANCEL-------------------------------+ +------------CANCEL-------------------------------+
| / M_CMD(cancel) | | / M_CMD(cancel) |
| V | V
| +------+ | +------+
+-------+ -------RR_EVT(fail)--------------------> | | +-------+ -------RR_EVT(fail)--------------------> | |
|WAITING| | IDLE | |WAITING| | IDLE |
+-------+ -------RR_EVT(rx)[is Response]---------> | | +-------+ -------RR_EVT(rx)[is Response]---------> | |
^ / M_CMD(accept) +------+ ^ / M_CMD(accept) +------+
| | | |
+--------------------REQUEST----------------------+ +--------------------REQUEST----------------------+
/ M_CMD((un)reliable_send) / M_CMD((un)reliable_send)
Figure 1: CoAP Client Request/Response Layer FSM Figure 1: CoAP Client Request/Response Layer FSM
A server resource can decide at the request/response layer whether to A server resource can decide at the request/response layer whether to
respond with a piggy-backed or a separate response. Thus, there are respond with a piggy-backed or a separate response. Thus, there are
two busy states in Figure 2, SERVING and SEPARATE. An incoming two busy states in Figure 2, SERVING and SEPARATE. An incoming
receive event with a NON request directly triggers the transition to receive event with a NON request directly triggers the transition to
the SEPARATE state. the SEPARATE state.
+--------+ <----------RR_EVT(rx)[is NON]---------- +------+ +--------+ <----------RR_EVT(rx)[is NON]---------- +------+
|SEPARATE| | | |SEPARATE| | |
+--------+ ----------------RESPONSE--------------> | IDLE | +--------+ ----------------RESPONSE--------------> | IDLE |
^ / M_CMD((un)reliable_send) | | ^ / M_CMD((un)reliable_send) | |
| +---> +------+ | +---> +------+
|EMPTY_ACK | | |EMPTY_ACK | |
|/M_CMD(accept) | | |/M_CMD(accept) | |
| | | | | |
| | | | | |
+--------+ | | +--------+ | |
|SERVING | --------------RESPONSE------------+ | |SERVING | --------------RESPONSE------------+ |
+--------+ / M_CMD(accept) | +--------+ / M_CMD(accept) |
^ | ^ |
+------------------------RR_EVT(rx)[is CON]--------+ +------------------------RR_EVT(rx)[is CON]--------+
Figure 2: CoAP Server Request/Response Layer FSM Figure 2: CoAP Server Request/Response Layer FSM
2.5.2. Message Layer 2.5.2. Message Layer
Figure 3 shows the different states of a CoAP endpoint per message Figure 3 shows the different states of a CoAP endpoint per message
exchange. Besides the linking action RR_EVT(), the message layer has exchange. Besides the linking action RR_EVT(), the message layer has
a TX action to send a message. For sending and receiving NONs, the a TX action to send a message. For sending and receiving NONs, the
endpoint remains in its CLOSED state. When sending a CON, the endpoint remains in its CLOSED state. When sending a CON, the
endpoint remains in RELIABLE_TX and keeps retransmitting until the endpoint remains in RELIABLE_TX and keeps retransmitting until the
skipping to change at page 19, line 30 skipping to change at page 20, line 18
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
minimal MTUs of IPv4. minimal MTUs of IPv4.
5. IANA considerations Another deployment issue in legacy IPv4 deployments is caused by
Network Address Translators (NATs). The session timeouts are
unpredictable and NATs may close UDP sessions with timeout as short
as 60 seconds. This makes CoAP endpoints behind NATs practically
unreachable, even when they contact the remote endpoint with a public
IP address first. Incorrect behavior may also arise when the NAT
session heuristic changes the external port between two successive
CoAP messages. For the remote endpoint, this will look like two
different CoAP endpoints on the same IP address. Such behavior can
be fatal for the resource directory registration interface.
5. Binding to specific lower-layer APIs
Implementing CoAP on specific lower-layer APIs appears to
consistently bring up certain less-known aspects of these APIs. This
section is intended to alert implementers to such aspects.
5.1. Berkeley Socket Interface
5.1.1. Responding from the right address
In order for a client to recognize a reply (response or
acknowledgement) as coming from the endpoint to which the initiating
packet was addressed, the source IPv6 address of the reply needs to
match the destination address of the initiating packet.
Implementers that have previously written TCP-based applications are
used to binding their server sockets to INADDR_ANY. Any TCP
connection received over such a socket is then more specifically
bound to the source address from which the TCP connection setup was
received; no programmer action is needed for this.
For stateless UDP sockets, more manual work is required. Simply
receiving a packet from a UDP socket bound to INADDR_ANY loses the
information about the destination address; replying to it through the
same socket will use the default address established by the kernel.
Two strategies are available:
o Only use sockets bound to a specific address (not INADDR_ANY). A
system with multiple interfaces (or addresses) will thus need to
bind multiple sockets and send replies back on the same socket the
initiating packet was received on.
o Use IPV6_RECVPKTINFO [RFC3542] to configure the socket, and mirror
back the IPV6_PKTINFO information for the reply (see also
Section 5.1.1.1).
5.1.1.1. Managing interfaces
For some applications, it may further be relevant what interface is
chosen to send to an endpoint, beyond the kernel choosing one that
has a routing table entry for the destination address. E.g., it may
be natural to send out a response or acknowledgment on the same
interface that the packet prompting it was received. The end of the
introduction to section 6 of [RFC3542] describes a simple technique
for this, where that RFC's API (IPV6_PKTINFO) is available. The same
data structure can be used for indicating an interface to send a
packet that is initiating an exchange. (Choosing that interface is
too application-specific to be in scope for the present document.)
5.2. Java
Java provides a wildcard address (0.0.0.0) to bind a socket to all
network interface. This is useful when a server is supposed to
listen on any available interface including the lookback address.
For UDP, and hence CoAP this poses a problem, however, because the
DatagramPacket class does not provide the information to which
address it was sent. When replying through the wildcard socket, the
JVM will pick the default address, which can break the correlation of
messages when the remote endpoint did not send the message to the
default address. This is in particular precarious for IPv6 where it
is common to have multiple IP addresses per network interface. Thus,
it is recommended to bind to all adresses explicitly and manage the
destination address of incoming messages within the CoAP
implementation.
5.3. Multicast detection
Similar to the considerations above, Section 8 of [RFC7252] requires
a node to detect whether a packet that it is going to reply to was
sent to a unicast or to a multicast address. On most platforms,
binding a UDP socket to a unicast address ensures that it only
receives packets addressed to that address. Programmers relying on
this property should ensure that it indeed applies to the platform
they are using. If it does not, IPV6_PKTINFO may, again, help for
Berkeley Socket Interfaces. For Java, explicit management of
different sockets (in this case a MulticastSocket) is required.
5.4. DTLS
CoAPS implementations require access to the authenticated user/device
prinicipal to realize access control for resources. How this
information can be accessed heavily depends on the DTLS
implementation used. Generic and portable CoAP implementations might
want to provide an abstraction layer that can be used by application
developers that implement resource handlers. It is recommended to
keep the API of such an application layer close to popular HTTPS
solutions that are available for the targeted platform, for instance,
mod_ssl or the Java Servlet API.
6. CoAP on various transports
As specified in [RFC7252], CoAP is defined for two underlying
transports: UDP and DTLS. These transports are relatively similar in
terms of the properties they expose to their users. (The main
difference, apart from the increased security, is that DTLS provides
an abstraction of a connection, into which the endpoint abstraction
is placed; in contrast, the UDP endpoint abstraction is based on
four-tuples of IP addresses and ports.)
Recently, the need to carry CoAP over other transports
[I-D.silverajan-core-coap-alternative-transports] has led to
specifications such as CoAP over TLS or TCP
[I-D.tschofenig-core-coap-tcp-tls] or websockets
[I-D.savolainen-core-coap-websockets], or even over non-IP transports
such as SMS [I-D.becker-core-coap-sms-gprs]. This section discusses
considerations that arise when handling these different transports in
an 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
One obvious way to convey CoAP exchanges between different transports
is to run a CoAP proxy that supports both transports. The usual
considerations for proxies apply. Section 6.2.1 discusses some
additional considerations.
Where not much of the functionality of CoAP proxies (such as caching)
is required, a simpler 1:1 translation may be possible, as discussed
in Section 6.2.2.
6.2.1. Transport translation by proxies
(TBD. In particular, point out the obvious: fan-in/fan-out means
that separate message ID and token spaces need to be maintained at
the ends of the proxy.)
One more CoAP specific function of a transport translator proxy may
be to convert between different block sizes, e.g. between a TCP
connection that can tolerate large blocks and UDP over a constrained
node network.
6.2.2. One-to-one Transport translation
A translator with reduced requirements for state maintenance can be
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
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-
to-UDP one-to-one translator could simply copy the messages (among
other applications, this might be useful for translation between IPv4
and IPv6 spaces). Similarly, a DTLS-to-TCP translator could be built
that executes the message layer (deduplication, retransmission) on
the DTLS side, and repackages the CoAP header (add/remove the length
information, and remove/add the message ID and message type) between
the DTLS and the TCP side.
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
terminates. However, a UDP-to-TCP one-to-one translator cannot
simply shut down the UDP endpoint when the TCP endpoint vanishes
because the TCP connection closes, so some additional management of
state will be necessary.
7. IANA considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Security considerations 8. Security considerations
TBD TBD
7. References 9. Acknowledgements
7.1. Normative References Esko Dijk contributed the sequential MID optimization. Xuan He
provided help creating and improved the state machine charts.
10. References
10.1. Normative References
[I-D.bormann-core-cocoa] [I-D.bormann-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-bormann-
core-cocoa-02 (work in progress), July 2014. core-cocoa-02 (work in progress), July 2014.
[I-D.ietf-core-block] [I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP",
draft-ietf-core-block-14 (work in progress), October 2013. draft-ietf-core-block-17 (work in progress), March 2015.
[I-D.ietf-core-observe] [I-D.ietf-core-observe]
Hartke, K., "Observing Resources in CoAP", draft-ietf- Hartke, K., "Observing Resources in CoAP", draft-ietf-
core-observe-14 (work in progress), June 2014. core-observe-16 (work in progress), December 2014.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J. 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. September 2011.
[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, March 2012.
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages",
RFC 6633, May 2012. RFC 6633, May 2012.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014. 2014.
[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, June 2014.
7.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 Workshop
on Embedded Networked Sensors , November 2004. on Embedded Networked Sensors, November 2004.
[I-D.becker-core-coap-sms-gprs]
Becker, M., Li, K., Kuladinithi, K., and T. Poetsch,
"Transport of CoAP over SMS", draft-becker-core-coap-sms-
gprs-05 (work in progress), August 2014.
[I-D.savolainen-core-coap-websockets]
Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over
WebSockets", draft-savolainen-core-coap-websockets-04
(work in progress), March 2015.
[I-D.silverajan-core-coap-alternative-transports]
Silverajan, B. and T. Savolainen, "CoAP Communication with
Alternative Transports", draft-silverajan-core-coap-
alternative-transports-08 (work in progress), June 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,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[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, May 2014.
[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), ISBN
978-3-540-27139-0 , 2005. 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
skipping to change at page 21, line 20 skipping to change at page 26, line 30
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
Esko Dijk
Philips Research
Email: esko.dijk@philips.com
Xuan He
Hitachi (China) R&D Corp.
301, Tower C North, Raycom, 2 Kexuyuan Nanlu
Beijing, 100190
P.R.China
Email: xhe@hitachi.cn
Carsten Bormann (editor) Carsten Bormann (editor)
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
 End of changes. 25 change blocks. 
98 lines changed or deleted 335 lines changed or added

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