CoRE C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Standards Track July 30, 2013 Expires: January 31, 2014 A TCP transport for CoAP draft-bormann-core-coap-tcp-00 Abstract CoAP 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 31, 2014. Copyright Notice Copyright (c) 2013 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 31, 2014 [Page 1] Internet-Draft CoAP-TCP July 2013 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 . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. One Message Type Only . . . . . . . . . . . . . . . . . . 5 3.2. Token . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Rejecting messages . . . . . . . . . . . . . . . . . . . 5 3.5. Resilient variant . . . . . . . . . . . . . . . . . . . . 5 3.6. Signatures . . . . . . . . . . . . . . . . . . . . . . . 5 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 31, 2014 [Page 2] Internet-Draft CoAP-TCP July 2013 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 31, 2014 [Page 3] Internet-Draft CoAP-TCP July 2013 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. 3. Changes to CoAP Bormann Expires January 31, 2014 [Page 4] Internet-Draft CoAP-TCP July 2013 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; it is not clear how useful that is. 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 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 Hmm. 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 Bormann Expires January 31, 2014 [Page 5] Internet-Draft CoAP-TCP July 2013 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. Informative References [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte Stuffing", ToN Vol.7, No. 2, April 1999. [I-D.savolainen-core-coap-websockets] Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over WebSockets", draft-savolainen-core-coap-websockets-00 (work in progress), July 2013. [I-D.silverajan-core-coap-alternative-transports] Silverajan, B. and T. Savolainen, "CoAP Communication with Alternative Transports", draft-silverajan-core-coap- alternative-transports-02 (work in progress), July 2013. [MINION] Iyengar, J.R., Ford, B., Amin, S.O., Nowlan, M.F., and N. Tiwari, "Wire-Compatible Unordered Delivery in TCP and TLS", CoRR abs/1103.0463, February 2011, . [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. Bormann Expires January 31, 2014 [Page 6] Internet-Draft CoAP-TCP July 2013 [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 31, 2014 [Page 7]