idnits 2.17.1 draft-bormann-core-block-bert-00.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 (November 26, 2015) is 3075 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) == Unused Reference: 'RFC7252' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC7641' is defined on line 267, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap-tcp-tls' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'REST' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC6690' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC7230' is defined on line 296, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-core-block-18 == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-01 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). 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 November 26, 2015 5 Expires: May 29, 2016 7 Block-wise transfers in CoAP: Extension for Reliable Transport (BERT) 8 draft-bormann-core-block-bert-00 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 May 29, 2016. 43 Copyright Notice 45 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 (see abstract for now) 82 1.1. Objectives 84 The objectives stated in the introduction of [I-D.ietf-core-block] 85 apply to the present document as well. (The exception is the desire 86 to enable individual retransmissions -- this is already handled by 87 reliable transport.) 89 Specifically, this specification continues to minimize the need for 90 creation of additional state, even if a TCP (or TLS over TCP) 91 connection already requires more state than a basic CoAP client-to- 92 server relationship. 94 An important aspect of this also is the need for state at proxies, 95 see Section 2.1. 97 1.2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in RFC 102 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant 103 implementations. 105 In this document, the term "byte" is used in its now customary sense 106 as a synonym for "octet". 108 Where bit arithmetic is explained, this document uses the notation 109 familiar from the programming language C, except that the operator 110 "**" stands for exponentiation. 112 BERT Option: 113 A Block1 or Block2 option that includes an SZX value of 7. 115 BERT Block: 116 The payload of a CoAP message that is affected by a BERT Option in 117 descriptive usage (Section 2.1 of [I-D.ietf-core-block]). 119 2. BERT Blocks 121 The use of the present extension is signalled by sending Block1 or 122 Block2 options with SZX == 7 (a "BERT option"). (SZX == 7 is a value 123 that was reserved in [I-D.ietf-core-block].) 125 In control usage, a BERT option is interpreted in the same way as the 126 equivalent option with SZX == 6, except that it also indicates the 127 capability to process BERT blocks. As with the basic Block protocol, 128 the recipient of a CoAP request with a BERT option in control usage 129 is allowed to respond with a different SZX value, e.g. to send a non- 130 BERT block instead. 132 In descriptive usage, a BERT option is interpreted in the same way as 133 the equivalent option with SZX == 6, except that the payload is 134 allowed to contain a multiple of 1024 bytes (non-final BERT block) or 135 more than 1024 bytes (final BERT block). 137 The recipient of a non-final BERT block (M=1) conceptually partitions 138 the payload into a sequence of 1024-byte blocks and acts exactly as 139 if it had received this sequence in conjunction with block numbers 140 starting at, and sequentially increasing from, the block number given 141 in the Block option. In other words, the entire BERT block is 142 positioned at the byte position that results from multiplying the 143 block number with 1024. The position of further blocks to be 144 transferred is indicated by incrementing the block number by the 145 number of elements in this sequence (i.e., the size of the payload 146 divided by 1024 bytes). 148 As with SZX == 6, the recipient of a final BERT block (M=0) simply 149 appends the payload at the byte position that is indicated by the 150 block number multiplied with 1024. 152 2.1. Caching Considerations 154 Section 2.10 of [I-D.ietf-core-block] applies unchanged. 156 Discussion: As with the basic Block protocol, a proxy may need to re- 157 slice blocks. Requiring BERT blocks to start at 1024 byte boundaries 158 simplifies this considerably. 160 2.2. Open Questions 162 Does the use of CoAP over TCP or TLS simply imply BERT capability or 163 do we explicitly signal that? Signalling is easy for Block2 (but 164 does require sending Block2 options with the value 7 as a matter of 165 course), less so for Block1. 167 If an optimistic approach is desired, the error code 4.13 (Request 168 Entity Too Large) could be employed as defined in Section 2.5 of 169 [I-D.ietf-core-block]. 171 2.3. Combining BERT blocks with the Observe Option 173 BERT Blocks combine with the Observe Option exactly as defined for 174 basic blocks in Section 2.6 of [I-D.ietf-core-block]. 176 3. Examples 178 This section extends Section 3 of [I-D.ietf-core-block] with a few 179 examples that involve BERT options. Extending the notation used in 180 that section, a value of SZX == 7 is shown as "BERT", or as 181 "BERT(nnn)" to indicate a payload of size nnn. 183 In all these examples, a Block option is shown in a decomposed way 184 indicating the kind of Block option (1 or 2) followed by a colon, and 185 then the block number (NUM), more bit (M), and block size exponent 186 (2**(SZX+4)) separated by slashes. E.g., a Block2 Option value of 33 187 would be shown as 2:2/0/32), or a Block1 Option value of 59 would be 188 shown as 1:3/1/128. 190 3.1. Block2 Example 192 The first example (Figure 1) shows a GET request with a response that 193 is split into three BERT blocks. The first response contains 3072 194 bytes of payload; the second, 5120; and the third, 4711. Note how 195 the block number increments to move the position inside the response 196 body forward. 198 CLIENT SERVER 199 | | 200 | GET, /status ------> | 201 | | 202 | <------ 2.05 Content, 2:0/1/BERT(3072) | 203 | | 204 | GET, /status, 2:3/0/BERT ------> | 205 | | 206 | <------ 2.05 Content, 2:3/1/BERT(5120) | 207 | | 208 | GET, /status, 2:8/0/BERT ------> | 209 | | 210 | <------ 2.05 Content, 2:8/0/BERT(4711) | 212 Figure 1: GET with BERT blocks 214 3.2. Block1 Example 216 The following example (Figure 2) demonstrates a PUT exchange with 217 BERT blocks. 219 CLIENT SERVER 220 | | 221 | PUT, /options, 1:0/1/BERT(8192) ------> | 222 | | 223 | <------ 2.31 Continue, 1:0/1/BERT | 224 | | 225 | PUT, /options, 1:8/1/BERT(16384) ------> | 226 | | 227 | <------ 2.31 Continue, 1:8/1/BERT | 228 | | 229 | PUT, /options, 1:24/0/BERT(5683) ------> | 230 | | 231 | <------ 2.04 Changed, 1:24/0/BERT | 232 | | 234 Figure 2: PUT with BERT blocks 236 4. IANA Considerations 238 This specification makes no requests of IANA. 240 (This section to be removed by the RFC editor.) 242 5. Security Considerations 244 The Security Considerations of [I-D.ietf-core-block] apply unchanged. 246 6. Acknowledgements 248 7. References 250 7.1. Normative References 252 [I-D.ietf-core-block] 253 Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP", 254 draft-ietf-core-block-18 (work in progress), September 255 2015. 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 259 RFC2119, March 1997, 260 . 262 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 263 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 264 RFC7252, June 2014, 265 . 267 [RFC7641] Hartke, K., "Observing Resources in the Constrained 268 Application Protocol (CoAP)", RFC 7641, DOI 10.17487/ 269 RFC7641, September 2015, 270 . 272 7.2. Informative References 274 [I-D.ietf-core-coap-tcp-tls] 275 Bormann, C., Lemay, S., Technologies, Z., and H. 276 Tschofenig, "A TCP and TLS Transport for the Constrained 277 Application Protocol (CoAP)", draft-ietf-core-coap-tcp- 278 tls-01 (work in progress), November 2015. 280 [REST] Fielding, R., "Architectural Styles and the Design of 281 Network-based Software Architectures", Ph.D. Dissertation, 282 University of California, Irvine, 2000, 283 . 286 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 287 over Low-Power Wireless Personal Area Networks (6LoWPANs): 288 Overview, Assumptions, Problem Statement, and Goals", RFC 289 4919, DOI 10.17487/RFC4919, August 2007, 290 . 292 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 293 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 294 . 296 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 297 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 298 7230, DOI 10.17487/RFC7230, June 2014, 299 . 301 Author's Address 303 Carsten Bormann 304 Universitaet Bremen TZI 305 Postfach 330440 306 Bremen D-28359 307 Germany 309 Phone: +49-421-218-63921 310 Email: cabo@tzi.org