idnits 2.17.1 draft-bormann-core-block-bert-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 10, 2016) is 2875 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 (-21) exists of draft-ietf-core-block-20 == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track June 10, 2016 5 Expires: December 12, 2016 7 Block-wise transfers in CoAP: Extension for Reliable Transport (BERT) 8 draft-bormann-core-block-bert-01 10 Abstract 12 CoAP (RFC7252) is a RESTful transfer protocol for constrained nodes 13 and networks, originally using UDP or DTLS over UDP as its transport. 14 Basic CoAP messages work well for the small payloads we expect from 15 temperature sensors, light switches, and similar building-automation 16 devices. CoAP's Block protocol (draft-ietf-core-block) allows 17 transferring larger payloads over limited-size datagrams -- for 18 instance, for firmware updates. 20 CoAP over TCP and TLS (draft-ietf-core-tcp-tls) enables the use of 21 extended, but not unlimited, size messages. The present 22 specification, Block-wise transfers in CoAP: Extension for Reliable 23 Transport (BERT), extends the block protocol in a simple way to be 24 able to make use of these larger messages over a reliable transport. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 12, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. BERT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Caching Considerations . . . . . . . . . . . . . . . . . 4 65 2.2. Open Questions . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. Combining BERT blocks with the Observe Option . . . . . . 4 67 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Block2 Example . . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Block1 Example . . . . . . . . . . . . . . . . . . . . . 5 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 7.2. Informative References . . . . . . . . . . . . . . . . . 6 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 (see abstract for now) 82 1.1. Objectives 84 The content of this document is intended for integration into 85 [I-D.ietf-core-coap-tcp-tls]. 87 The objectives stated in the introduction of [I-D.ietf-core-block] 88 apply to the present document as well. (The exception is the desire 89 to enable individual retransmissions -- this is already handled by 90 reliable transport.) 92 Specifically, this specification continues to minimize the need for 93 creation of additional state, even if a TCP (or TLS over TCP) 94 connection already requires more state than a basic CoAP client-to- 95 server relationship. 97 An important aspect of this also is the need for state at proxies, 98 see Section 2.1. 100 1.2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in RFC 105 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant 106 implementations. 108 The definitions of [RFC7252] apply. 110 In this document, the term "byte" is used in its now customary sense 111 as a synonym for "octet". 113 Where bit arithmetic is explained, this document uses the notation 114 familiar from the programming language C, except that the operator 115 "**" stands for exponentiation. 117 BERT Option: 118 A Block1 or Block2 option that includes an SZX value of 7. 120 BERT Block: 121 The payload of a CoAP message that is affected by a BERT Option in 122 descriptive usage (Section 2.1 of [I-D.ietf-core-block]). 124 2. BERT Blocks 126 The use of the present extension is signalled by sending Block1 or 127 Block2 options with SZX == 7 (a "BERT option"). (SZX == 7 is a value 128 that was reserved in [I-D.ietf-core-block].) 130 In control usage, a BERT option is interpreted in the same way as the 131 equivalent option with SZX == 6, except that it also indicates the 132 capability to process BERT blocks. As with the basic Block protocol, 133 the recipient of a CoAP request with a BERT option in control usage 134 is allowed to respond with a different SZX value, e.g. to send a non- 135 BERT block instead. 137 In descriptive usage, a BERT option is interpreted in the same way as 138 the equivalent option with SZX == 6, except that the payload is 139 allowed to contain a multiple of 1024 bytes (non-final BERT block) or 140 more than 1024 bytes (final BERT block). 142 The recipient of a non-final BERT block (M=1) conceptually partitions 143 the payload into a sequence of 1024-byte blocks and acts exactly as 144 if it had received this sequence in conjunction with block numbers 145 starting at, and sequentially increasing from, the block number given 146 in the Block option. In other words, the entire BERT block is 147 positioned at the byte position that results from multiplying the 148 block number with 1024. The position of further blocks to be 149 transferred is indicated by incrementing the block number by the 150 number of elements in this sequence (i.e., the size of the payload 151 divided by 1024 bytes). 153 As with SZX == 6, the recipient of a final BERT block (M=0) simply 154 appends the payload at the byte position that is indicated by the 155 block number multiplied with 1024. 157 2.1. Caching Considerations 159 Section 2.10 of [I-D.ietf-core-block] applies unchanged. 161 Discussion: As with the basic Block protocol, a proxy may need to re- 162 slice blocks. Requiring BERT blocks to start at 1024 byte boundaries 163 simplifies this considerably. 165 2.2. Open Questions 167 Does the use of CoAP over TCP or TLS simply imply BERT capability or 168 do we explicitly signal that? Signalling is easy for Block2 (but 169 does require sending Block2 options with the value 7 as a matter of 170 course), less so for Block1. 172 If an optimistic approach is desired, the error code 4.13 (Request 173 Entity Too Large) could be employed as defined in Section 2.5 of 174 [I-D.ietf-core-block]. 176 2.3. Combining BERT blocks with the Observe Option 178 BERT Blocks combine with the Observe Option ([RFC7641] exactly as 179 defined for basic blocks in Section 2.6 of [I-D.ietf-core-block]. 181 3. Examples 183 This section extends Section 3 of [I-D.ietf-core-block] with a few 184 examples that involve BERT options. Extending the notation used in 185 that section, a value of SZX == 7 is shown as "BERT", or as 186 "BERT(nnn)" to indicate a payload of size nnn. 188 In all these examples, a Block option is shown in a decomposed way 189 indicating the kind of Block option (1 or 2) followed by a colon, and 190 then the block number (NUM), more bit (M), and block size exponent 191 (2**(SZX+4)) separated by slashes. E.g., a Block2 Option value of 33 192 would be shown as 2:2/0/32), or a Block1 Option value of 59 would be 193 shown as 1:3/1/128. 195 3.1. Block2 Example 197 The first example (Figure 1) shows a GET request with a response that 198 is split into three BERT blocks. The first response contains 3072 199 bytes of payload; the second, 5120; and the third, 4711. Note how 200 the block number increments to move the position inside the response 201 body forward. 203 CLIENT SERVER 204 | | 205 | GET, /status ------> | 206 | | 207 | <------ 2.05 Content, 2:0/1/BERT(3072) | 208 | | 209 | GET, /status, 2:3/0/BERT ------> | 210 | | 211 | <------ 2.05 Content, 2:3/1/BERT(5120) | 212 | | 213 | GET, /status, 2:8/0/BERT ------> | 214 | | 215 | <------ 2.05 Content, 2:8/0/BERT(4711) | 217 Figure 1: GET with BERT blocks 219 3.2. Block1 Example 221 The following example (Figure 2) demonstrates a PUT exchange with 222 BERT blocks. 224 CLIENT SERVER 225 | | 226 | PUT, /options, 1:0/1/BERT(8192) ------> | 227 | | 228 | <------ 2.31 Continue, 1:0/1/BERT | 229 | | 230 | PUT, /options, 1:8/1/BERT(16384) ------> | 231 | | 232 | <------ 2.31 Continue, 1:8/1/BERT | 233 | | 234 | PUT, /options, 1:24/0/BERT(5683) ------> | 235 | | 236 | <------ 2.04 Changed, 1:24/0/BERT | 237 | | 239 Figure 2: PUT with BERT blocks 241 4. IANA Considerations 243 This specification makes no requests of IANA. 245 (This section to be removed by the RFC editor.) 247 5. Security Considerations 249 The Security Considerations of [I-D.ietf-core-block] apply unchanged. 251 6. Acknowledgements 253 7. References 255 7.1. Normative References 257 [I-D.ietf-core-block] 258 Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP", 259 draft-ietf-core-block-20 (work in progress), April 2016. 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, 263 DOI 10.17487/RFC2119, March 1997, 264 . 266 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 267 Application Protocol (CoAP)", RFC 7252, 268 DOI 10.17487/RFC7252, June 2014, 269 . 271 [RFC7641] Hartke, K., "Observing Resources in the Constrained 272 Application Protocol (CoAP)", RFC 7641, 273 DOI 10.17487/RFC7641, September 2015, 274 . 276 7.2. Informative References 278 [I-D.ietf-core-coap-tcp-tls] 279 Bormann, C., Lemay, S., Technologies, Z., and H. 280 Tschofenig, "A TCP and TLS Transport for the Constrained 281 Application Protocol (CoAP)", draft-ietf-core-coap-tcp- 282 tls-02 (work in progress), April 2016. 284 Author's Address 285 Carsten Bormann 286 Universitaet Bremen TZI 287 Postfach 330440 288 Bremen D-28359 289 Germany 291 Phone: +49-421-218-63921 292 Email: cabo@tzi.org