Internet DRAFT - draft-bormann-core-coap-tcp
draft-bormann-core-coap-tcp
CoRE C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track July 04, 2014
Expires: January 5, 2015
A TCP transport for CoAP
draft-bormann-core-coap-tcp-01
Abstract
CoAP (RFC 7252) is defined to be transported over datagram transports
such as UDP or DTLS. For a number of applications, it may be useful
to channel CoAP messages in a TCP connection. This draft discusses
different ways to do that.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bormann Expires January 5, 2015 [Page 1]
Internet-Draft CoAP-TCP July 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Length prefix . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Delimiter-based . . . . . . . . . . . . . . . . . . . . . 3
2.3. Self-delimiting . . . . . . . . . . . . . . . . . . . . . 4
3. Changes to CoAP . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. One Message Type Only . . . . . . . . . . . . . . . . . . 5
3.2. Token . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Message-ID, Fixed Header Format . . . . . . . . . . . . . 5
3.4. Rejecting messages . . . . . . . . . . . . . . . . . . . 5
3.5. Resilient variant . . . . . . . . . . . . . . . . . . . . 6
3.6. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6
4. Transport selection . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
(See Abstract)
The primary use case addressed by this specification is:
o Aggregation of CoAP streams behind proxies, e.g.:
* Behind a DTLS terminator/load balancer on the cloud side
* As a wide-area interface to a proxy that speaks CoAP over UDP
on the constrained side
1.1. Objectives
(TBD)
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The term "byte" is used in its now customary sense as a synonym for
"octet".
Bormann Expires January 5, 2015 [Page 2]
Internet-Draft CoAP-TCP July 2014
All multi-byte integers in this protocol are interpreted in network
byte order.
2. Framing
The TCP stream needs to be structured into frames in order to delimit
CoAP messages.
As the size of CoAP messages is limited, there is no need to split a
single CoAP message into multiple frames (no interleaving).
Several alternative frame formats are possible. The current version
of this specifications proposes several alternatives, with the
understanding that a single one of these is likely to be chosen.
One desirable characteristic of a framing scheme is detection of
premature termination of the TCP connection. While TCP in principle
distinguishes orderly (FIN) and destructive (RST) termination of a
connection, the difference is not always visible from the socket
interface; also, a crashing process gives the impression of orderly
termination. All schemes proposed here provide this detection.
2.1. Length prefix
A popular form of framing for TCP starts each frame with a length
indication [RFC1006].
A simple form of length prefix would be an SDNV [RFC6256], which is
efficient for large numbers of mostly small (< 128 B) messages.
Alternatively, a two-byte prefix could always be used, or the length
could be embedded in the CoAP message by using the unused Message-ID
field.
The main disadvantage of a length prefix is that the sender needs to
know the length before sending the message proper. The main
advantage of a length prefix is that the receiver knows the length at
the start of receiving the message.
2.2. Delimiter-based
Another form of message delimiting uses special byte values for
delimiting protocol elements, e.g. CRLF for lines in a text stream.
Since CoAP requires full data transparency, introducing a delimiter
byte requires escaping occurrences of the delimiter in the data
stream, which in turn requires escaping the escape mechanism. In
traditional byte-stuffing (called "octet-stuffing" in [RFC1662]), the
overhead of this escaping can be up to 100 % on top of the actual
data. Cheshire has shown how to combine delimiter-based and length
Bormann Expires January 5, 2015 [Page 3]
Internet-Draft CoAP-TCP July 2014
prefix based encoding in "Consistent Overhead Byte Stuffing" [COBS];
however, this requires at least two bytes per message, achieving full
efficiency only for relatively large messages and only if the length
of the remaining message is known (see Section 2.1 before). A scheme
such as the FSE scheme in [RFC2687] might be simpler to implement
(the efficiency of an FSE-style scheme can be quite high by
exploiting the fact that CoAP frames never start with a value below
0x40). A good value for FSE-style (or even a non-zero COBS-style)
delimiter can be determined by examining a corpus of CoAP messages
(TBD).
A major advantage of a COBS-like scheme would be compatibility with
schemes that synchronize TCP packet boundaries with message
boundaries [MINION].
Requiring a delimiter at the _end_ of a frame fulfills the
requirement for detection of premature TCP connection termination,
except for an FSE-style scheme where the FSE starting an escape
sequence happens to fall on a packet boundary.
2.3. Self-delimiting
Currently, CoAP messages are not self-delimiting, as the payload
delimiter is optional and does not contain a payload length.
In the scheme proposed here, the payload delimiter is made required;
the payload length is then encoded exactly as in CoAP options. For
example:
o 0xF0 would indicate that a zero-length (absent) payload follows
o 0xF1 would indicate a single-byte payload
o 0xFD 0x47 would indicate a 84-byte payload
o 0xFE 0xFF 0xFF would indicate a 65804-byte payload
One advantage of implementing this scheme is that it could also be
used to aggregate multiple CoAP messages into one datagram of a
datagram-based transport such as UDP or DTLS, if that is desired,
without increasing the overhead for unaggregated messages. For this
application, 0xFF could still be used in order to efficiently encode
"payload delimited by message boundary" in the final CoAP message in
the datagram.
Bormann Expires January 5, 2015 [Page 4]
Internet-Draft CoAP-TCP July 2014
3. Changes to CoAP
The content of this section is expressed as a delta on [RFC7252].
3.1. One Message Type Only
As reliability is handled by TCP, there is no need for ACK messages.
Similarly, rebooting nodes will drop their TCP connections, so there
is no need for RST messages (but see Section 3.4).
Cf. [I-D.savolainen-core-coap-websockets].
There may still be a desire to differentiate CON and NON for the
intention behind a TCP-to-UDP proxy. In contrast to
[I-D.savolainen-core-coap-websockets], this specification proposes to
retain the difference between CON and NON messages as a hint for the
reliability requirements placed on a message forwarded through a
proxy. There are no ACK or RST messages; ACK messages MUST be
encoded as CON messages.
3.2. Token
The Token space is local to the TCP connection. In particular, this
means that closing down a TCP connection cancels all outstanding
requests (the responses are not sent over a new connection, which is
handled like a new endpoint).
3.3. Message-ID, Fixed Header Format
As there are no ACKs, there is no need to correlate an ACK to a CON.
As a result, there is no need to carry a Message-ID for this. There
is also no danger of duplication of a message, so the Message-ID is
entirely without function.
If it seems desirable to maintain the frame format, the message-ID
could still be sent empty. Alternatively, it could be used as a
space for the frame length.
As does [I-D.savolainen-core-coap-websockets], this specification
proposes to elide the Message-ID, i.e. to send bytes 0 and 1 of the
CoAP message followed directly by byte 4 and following.
3.4. Rejecting messages
[I-D.ietf-core-observe] now supports Observation Cancellation,
reducing the need to support Reset-like messages for cancelling an
observation relationship.
Bormann Expires January 5, 2015 [Page 5]
Internet-Draft CoAP-TCP July 2014
3.5. Resilient variant
An alternative approach is to treat the TCP connection as ephemeral.
If a connection can go away at any point in time, and be replaced by
a new one, the delivery of messages is no longer fully reliable. All
functions of Message-IDs remain, as well as the functions of ACKs.
Tokens retain their meaning beyond a connection.
3.6. Signatures
A new TCP connection can send an identifying signature in both
directions to facilitate debugging and protocol evolution and to
enable detection of mismatches.
E.g., the side opening a connection could send the seven bytes
"CoAP1\r\n" and the answering side similarly "cOap1\r\n".
4. Transport selection
There may be use cases where the TCP transport should be explicitly
selected from a URI. This problem should be solved in a way that
doesn't cause the available of different transports to generate
aliases for the same resource, i.e. the same "coap://" URI should be
used for the same resource. Cf.
[I-D.silverajan-core-coap-alternative-transports].
5. References
5.1. Normative References
[I-D.ietf-core-observe]
Hartke, K., "Observing Resources in CoAP", draft-ietf-
core-observe-14 (work in progress), June 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
5.2. Informative References
[COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte
Stuffing", ToN Vol.7, No. 2, April 1999.
Bormann Expires January 5, 2015 [Page 6]
Internet-Draft CoAP-TCP July 2014
[I-D.savolainen-core-coap-websockets]
Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over
WebSockets", draft-savolainen-core-coap-websockets-02
(work in progress), April 2014.
[I-D.silverajan-core-coap-alternative-transports]
Silverajan, B. and T. Savolainen, "CoAP Communication with
Alternative Transports", draft-silverajan-core-coap-
alternative-transports-05 (work in progress), June 2014.
[MINION] Iyengar, J., Ford, B., Amin, S., Nowlan, M., and N.
Tiwari, "Wire-Compatible Unordered Delivery in TCP and
TLS", CoRR abs/1103.0463, February 2011,
<http://arxiv.org/abs/1103.0463v2>.
[RFC1006] Rose, M. and D. Cass, "ISO transport services on top of
the TCP: Version 3", STD 35, RFC 1006, May 1987.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC2687] Bormann, C., "PPP in a Real-time Oriented HDLC-like
Framing", RFC 2687, September 1999.
[RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
Values in Protocols", RFC 6256, May 2011.
Author's Address
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Bormann Expires January 5, 2015 [Page 7]
