idnits 2.17.1 draft-bormann-core-coap-tcp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 04, 2014) is 3576 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-14 == Outdated reference: A later version (-07) exists of draft-savolainen-core-coap-websockets-02 == Outdated reference: A later version (-11) exists of draft-silverajan-core-coap-alternative-transports-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track July 04, 2014 5 Expires: January 5, 2015 7 A TCP transport for CoAP 8 draft-bormann-core-coap-tcp-01 10 Abstract 12 CoAP (RFC 7252) is defined to be transported over datagram transports 13 such as UDP or DTLS. For a number of applications, it may be useful 14 to channel CoAP messages in a TCP connection. This draft discusses 15 different ways to do that. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 5, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Length prefix . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Delimiter-based . . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Self-delimiting . . . . . . . . . . . . . . . . . . . . . 4 58 3. Changes to CoAP . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. One Message Type Only . . . . . . . . . . . . . . . . . . 5 60 3.2. Token . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Message-ID, Fixed Header Format . . . . . . . . . . . . . 5 62 3.4. Rejecting messages . . . . . . . . . . . . . . . . . . . 5 63 3.5. Resilient variant . . . . . . . . . . . . . . . . . . . . 6 64 3.6. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Transport selection . . . . . . . . . . . . . . . . . . . . . 6 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 5.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 (See Abstract) 75 The primary use case addressed by this specification is: 77 o Aggregation of CoAP streams behind proxies, e.g.: 79 * Behind a DTLS terminator/load balancer on the cloud side 81 * As a wide-area interface to a proxy that speaks CoAP over UDP 82 on the constrained side 84 1.1. Objectives 86 (TBD) 88 1.2. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 The term "byte" is used in its now customary sense as a synonym for 95 "octet". 97 All multi-byte integers in this protocol are interpreted in network 98 byte order. 100 2. Framing 102 The TCP stream needs to be structured into frames in order to delimit 103 CoAP messages. 105 As the size of CoAP messages is limited, there is no need to split a 106 single CoAP message into multiple frames (no interleaving). 108 Several alternative frame formats are possible. The current version 109 of this specifications proposes several alternatives, with the 110 understanding that a single one of these is likely to be chosen. 112 One desirable characteristic of a framing scheme is detection of 113 premature termination of the TCP connection. While TCP in principle 114 distinguishes orderly (FIN) and destructive (RST) termination of a 115 connection, the difference is not always visible from the socket 116 interface; also, a crashing process gives the impression of orderly 117 termination. All schemes proposed here provide this detection. 119 2.1. Length prefix 121 A popular form of framing for TCP starts each frame with a length 122 indication [RFC1006]. 124 A simple form of length prefix would be an SDNV [RFC6256], which is 125 efficient for large numbers of mostly small (< 128 B) messages. 126 Alternatively, a two-byte prefix could always be used, or the length 127 could be embedded in the CoAP message by using the unused Message-ID 128 field. 130 The main disadvantage of a length prefix is that the sender needs to 131 know the length before sending the message proper. The main 132 advantage of a length prefix is that the receiver knows the length at 133 the start of receiving the message. 135 2.2. Delimiter-based 137 Another form of message delimiting uses special byte values for 138 delimiting protocol elements, e.g. CRLF for lines in a text stream. 139 Since CoAP requires full data transparency, introducing a delimiter 140 byte requires escaping occurrences of the delimiter in the data 141 stream, which in turn requires escaping the escape mechanism. In 142 traditional byte-stuffing (called "octet-stuffing" in [RFC1662]), the 143 overhead of this escaping can be up to 100 % on top of the actual 144 data. Cheshire has shown how to combine delimiter-based and length 145 prefix based encoding in "Consistent Overhead Byte Stuffing" [COBS]; 146 however, this requires at least two bytes per message, achieving full 147 efficiency only for relatively large messages and only if the length 148 of the remaining message is known (see Section 2.1 before). A scheme 149 such as the FSE scheme in [RFC2687] might be simpler to implement 150 (the efficiency of an FSE-style scheme can be quite high by 151 exploiting the fact that CoAP frames never start with a value below 152 0x40). A good value for FSE-style (or even a non-zero COBS-style) 153 delimiter can be determined by examining a corpus of CoAP messages 154 (TBD). 156 A major advantage of a COBS-like scheme would be compatibility with 157 schemes that synchronize TCP packet boundaries with message 158 boundaries [MINION]. 160 Requiring a delimiter at the _end_ of a frame fulfills the 161 requirement for detection of premature TCP connection termination, 162 except for an FSE-style scheme where the FSE starting an escape 163 sequence happens to fall on a packet boundary. 165 2.3. Self-delimiting 167 Currently, CoAP messages are not self-delimiting, as the payload 168 delimiter is optional and does not contain a payload length. 170 In the scheme proposed here, the payload delimiter is made required; 171 the payload length is then encoded exactly as in CoAP options. For 172 example: 174 o 0xF0 would indicate that a zero-length (absent) payload follows 176 o 0xF1 would indicate a single-byte payload 178 o 0xFD 0x47 would indicate a 84-byte payload 180 o 0xFE 0xFF 0xFF would indicate a 65804-byte payload 182 One advantage of implementing this scheme is that it could also be 183 used to aggregate multiple CoAP messages into one datagram of a 184 datagram-based transport such as UDP or DTLS, if that is desired, 185 without increasing the overhead for unaggregated messages. For this 186 application, 0xFF could still be used in order to efficiently encode 187 "payload delimited by message boundary" in the final CoAP message in 188 the datagram. 190 3. Changes to CoAP 192 The content of this section is expressed as a delta on [RFC7252]. 194 3.1. One Message Type Only 196 As reliability is handled by TCP, there is no need for ACK messages. 197 Similarly, rebooting nodes will drop their TCP connections, so there 198 is no need for RST messages (but see Section 3.4). 200 Cf. [I-D.savolainen-core-coap-websockets]. 202 There may still be a desire to differentiate CON and NON for the 203 intention behind a TCP-to-UDP proxy. In contrast to 204 [I-D.savolainen-core-coap-websockets], this specification proposes to 205 retain the difference between CON and NON messages as a hint for the 206 reliability requirements placed on a message forwarded through a 207 proxy. There are no ACK or RST messages; ACK messages MUST be 208 encoded as CON messages. 210 3.2. Token 212 The Token space is local to the TCP connection. In particular, this 213 means that closing down a TCP connection cancels all outstanding 214 requests (the responses are not sent over a new connection, which is 215 handled like a new endpoint). 217 3.3. Message-ID, Fixed Header Format 219 As there are no ACKs, there is no need to correlate an ACK to a CON. 220 As a result, there is no need to carry a Message-ID for this. There 221 is also no danger of duplication of a message, so the Message-ID is 222 entirely without function. 224 If it seems desirable to maintain the frame format, the message-ID 225 could still be sent empty. Alternatively, it could be used as a 226 space for the frame length. 228 As does [I-D.savolainen-core-coap-websockets], this specification 229 proposes to elide the Message-ID, i.e. to send bytes 0 and 1 of the 230 CoAP message followed directly by byte 4 and following. 232 3.4. Rejecting messages 234 [I-D.ietf-core-observe] now supports Observation Cancellation, 235 reducing the need to support Reset-like messages for cancelling an 236 observation relationship. 238 3.5. Resilient variant 240 An alternative approach is to treat the TCP connection as ephemeral. 241 If a connection can go away at any point in time, and be replaced by 242 a new one, the delivery of messages is no longer fully reliable. All 243 functions of Message-IDs remain, as well as the functions of ACKs. 244 Tokens retain their meaning beyond a connection. 246 3.6. Signatures 248 A new TCP connection can send an identifying signature in both 249 directions to facilitate debugging and protocol evolution and to 250 enable detection of mismatches. 252 E.g., the side opening a connection could send the seven bytes 253 "CoAP1\r\n" and the answering side similarly "cOap1\r\n". 255 4. Transport selection 257 There may be use cases where the TCP transport should be explicitly 258 selected from a URI. This problem should be solved in a way that 259 doesn't cause the available of different transports to generate 260 aliases for the same resource, i.e. the same "coap://" URI should be 261 used for the same resource. Cf. 262 [I-D.silverajan-core-coap-alternative-transports]. 264 5. References 266 5.1. Normative References 268 [I-D.ietf-core-observe] 269 Hartke, K., "Observing Resources in CoAP", draft-ietf- 270 core-observe-14 (work in progress), June 2014. 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 276 Application Protocol (CoAP)", RFC 7252, June 2014. 278 5.2. Informative References 280 [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte 281 Stuffing", ToN Vol.7, No. 2, April 1999. 283 [I-D.savolainen-core-coap-websockets] 284 Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over 285 WebSockets", draft-savolainen-core-coap-websockets-02 286 (work in progress), April 2014. 288 [I-D.silverajan-core-coap-alternative-transports] 289 Silverajan, B. and T. Savolainen, "CoAP Communication with 290 Alternative Transports", draft-silverajan-core-coap- 291 alternative-transports-05 (work in progress), June 2014. 293 [MINION] Iyengar, J., Ford, B., Amin, S., Nowlan, M., and N. 294 Tiwari, "Wire-Compatible Unordered Delivery in TCP and 295 TLS", CoRR abs/1103.0463, February 2011, 296 . 298 [RFC1006] Rose, M. and D. Cass, "ISO transport services on top of 299 the TCP: Version 3", STD 35, RFC 1006, May 1987. 301 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 302 July 1994. 304 [RFC2687] Bormann, C., "PPP in a Real-time Oriented HDLC-like 305 Framing", RFC 2687, September 1999. 307 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 308 Values in Protocols", RFC 6256, May 2011. 310 Author's Address 312 Carsten Bormann 313 Universitaet Bremen TZI 314 Postfach 330440 315 Bremen D-28359 316 Germany 318 Phone: +49-421-218-63921 319 Email: cabo@tzi.org