CoRE Working Group                                            C. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Standards Track                       November 26, 2015
Expires: May 29, 2016


 Block-wise transfers in CoAP: Extension for Reliable Transport (BERT)
                    draft-bormann-core-block-bert-00

Abstract

   CoAP (RFC7252) is a RESTful transfer protocol for constrained nodes
   and networks, originally using UDP or DTLS over UDP as its transport.
   Basic CoAP messages work well for the small payloads we expect from
   temperature sensors, light switches, and similar building-automation
   devices.  CoAP's Block protocol (draft-ietf-core-block) allows
   transferring larger payloads over limited-size datagrams -- for
   instance, for firmware updates.

   CoAP over TCP and TLS (draft-ietf-core-tcp-tls) enables the use of
   extended, but not unlimited, size messages.  The present
   specification, Block-wise transfers in CoAP: Extension for Reliable
   Transport (BERT), extends the block protocol in a simple way to be
   able to make use of these larger messages over a reliable transport.

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 May 29, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Bormann                   Expires May 29, 2016                  [Page 1]


Internet-Draft                  CoAP-BERT                  November 2015


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Objectives  . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  BERT Blocks . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Caching Considerations  . . . . . . . . . . . . . . . . .   4
     2.2.  Open Questions  . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Combining BERT blocks with the Observe Option . . . . . .   4
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Block2 Example  . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Block1 Example  . . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   (see abstract for now)

1.1.  Objectives

   The objectives stated in the introduction of [I-D.ietf-core-block]
   apply to the present document as well.  (The exception is the desire
   to enable individual retransmissions -- this is already handled by
   reliable transport.)

   Specifically, this specification continues to minimize the need for
   creation of additional state, even if a TCP (or TLS over TCP)
   connection already requires more state than a basic CoAP client-to-
   server relationship.

   An important aspect of this also is the need for state at proxies,
   see Section 2.1.



Bormann                   Expires May 29, 2016                  [Page 2]


Internet-Draft                  CoAP-BERT                  November 2015


1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119, BCP 14 [RFC2119] and indicate requirement levels for compliant
   implementations.

   In this document, the term "byte" is used in its now customary sense
   as a synonym for "octet".

   Where bit arithmetic is explained, this document uses the notation
   familiar from the programming language C, except that the operator
   "**" stands for exponentiation.

   BERT Option:
      A Block1 or Block2 option that includes an SZX value of 7.

   BERT Block:
      The payload of a CoAP message that is affected by a BERT Option in
      descriptive usage (Section 2.1 of [I-D.ietf-core-block]).

2.  BERT Blocks

   The use of the present extension is signalled by sending Block1 or
   Block2 options with SZX == 7 (a "BERT option").  (SZX == 7 is a value
   that was reserved in [I-D.ietf-core-block].)

   In control usage, a BERT option is interpreted in the same way as the
   equivalent option with SZX == 6, except that it also indicates the
   capability to process BERT blocks.  As with the basic Block protocol,
   the recipient of a CoAP request with a BERT option in control usage
   is allowed to respond with a different SZX value, e.g. to send a non-
   BERT block instead.

   In descriptive usage, a BERT option is interpreted in the same way as
   the equivalent option with SZX == 6, except that the payload is
   allowed to contain a multiple of 1024 bytes (non-final BERT block) or
   more than 1024 bytes (final BERT block).

   The recipient of a non-final BERT block (M=1) conceptually partitions
   the payload into a sequence of 1024-byte blocks and acts exactly as
   if it had received this sequence in conjunction with block numbers
   starting at, and sequentially increasing from, the block number given
   in the Block option.  In other words, the entire BERT block is
   positioned at the byte position that results from multiplying the
   block number with 1024.  The position of further blocks to be
   transferred is indicated by incrementing the block number by the



Bormann                   Expires May 29, 2016                  [Page 3]


Internet-Draft                  CoAP-BERT                  November 2015


   number of elements in this sequence (i.e., the size of the payload
   divided by 1024 bytes).

   As with SZX == 6, the recipient of a final BERT block (M=0) simply
   appends the payload at the byte position that is indicated by the
   block number multiplied with 1024.

2.1.  Caching Considerations

   Section 2.10 of [I-D.ietf-core-block] applies unchanged.

   Discussion: As with the basic Block protocol, a proxy may need to re-
   slice blocks.  Requiring BERT blocks to start at 1024 byte boundaries
   simplifies this considerably.

2.2.  Open Questions

   Does the use of CoAP over TCP or TLS simply imply BERT capability or
   do we explicitly signal that?  Signalling is easy for Block2 (but
   does require sending Block2 options with the value 7 as a matter of
   course), less so for Block1.

   If an optimistic approach is desired, the error code 4.13 (Request
   Entity Too Large) could be employed as defined in Section 2.5 of
   [I-D.ietf-core-block].

2.3.  Combining BERT blocks with the Observe Option

   BERT Blocks combine with the Observe Option exactly as defined for
   basic blocks in Section 2.6 of [I-D.ietf-core-block].

3.  Examples

   This section extends Section 3 of [I-D.ietf-core-block] with a few
   examples that involve BERT options.  Extending the notation used in
   that section, a value of SZX == 7 is shown as "BERT", or as
   "BERT(nnn)" to indicate a payload of size nnn.

   In all these examples, a Block option is shown in a decomposed way
   indicating the kind of Block option (1 or 2) followed by a colon, and
   then the block number (NUM), more bit (M), and block size exponent
   (2**(SZX+4)) separated by slashes.  E.g., a Block2 Option value of 33
   would be shown as 2:2/0/32), or a Block1 Option value of 59 would be
   shown as 1:3/1/128.







Bormann                   Expires May 29, 2016                  [Page 4]


Internet-Draft                  CoAP-BERT                  November 2015


3.1.  Block2 Example

   The first example (Figure 1) shows a GET request with a response that
   is split into three BERT blocks.  The first response contains 3072
   bytes of payload; the second, 5120; and the third, 4711.  Note how
   the block number increments to move the position inside the response
   body forward.

   CLIENT                                       SERVER
     |                                            |
     | GET, /status                       ------> |
     |                                            |
     | <------   2.05 Content, 2:0/1/BERT(3072)   |
     |                                            |
     | GET, /status, 2:3/0/BERT           ------> |
     |                                            |
     | <------   2.05 Content, 2:3/1/BERT(5120)   |
     |                                            |
     | GET, /status, 2:8/0/BERT          ------>  |
     |                                            |
     | <------   2.05 Content, 2:8/0/BERT(4711)   |

                      Figure 1: GET with BERT blocks

3.2.  Block1 Example

   The following example (Figure 2) demonstrates a PUT exchange with
   BERT blocks.

   CLIENT                                        SERVER
     |                                             |
     | PUT, /options, 1:0/1/BERT(8192)     ------> |
     |                                             |
     | <------   2.31 Continue, 1:0/1/BERT         |
     |                                             |
     | PUT, /options, 1:8/1/BERT(16384)    ------> |
     |                                             |
     | <------   2.31 Continue, 1:8/1/BERT         |
     |                                             |
     | PUT, /options, 1:24/0/BERT(5683)    ------> |
     |                                             |
     | <------   2.04 Changed, 1:24/0/BERT         |
     |                                             |

                      Figure 2: PUT with BERT blocks






Bormann                   Expires May 29, 2016                  [Page 5]


Internet-Draft                  CoAP-BERT                  November 2015


4.  IANA Considerations

   This specification makes no requests of IANA.

   (This section to be removed by the RFC editor.)

5.  Security Considerations

   The Security Considerations of [I-D.ietf-core-block] apply unchanged.

6.  Acknowledgements

7.  References

7.1.  Normative References

   [I-D.ietf-core-block]
              Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP",
              draft-ietf-core-block-18 (work in progress), September
              2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
              RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641, DOI 10.17487/
              RFC7641, September 2015,
              <http://www.rfc-editor.org/info/rfc7641>.

7.2.  Informative References

   [I-D.ietf-core-coap-tcp-tls]
              Bormann, C., Lemay, S., Technologies, Z., and H.
              Tschofenig, "A TCP and TLS Transport for the Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-tcp-
              tls-01 (work in progress), November 2015.








Bormann                   Expires May 29, 2016                  [Page 6]


Internet-Draft                  CoAP-BERT                  November 2015


   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", Ph.D. Dissertation,
              University of California, Irvine, 2000,
              <http://www.ics.uci.edu/~fielding/pubs/dissertation/
              fielding_dissertation.pdf>.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals", RFC
              4919, DOI 10.17487/RFC4919, August 2007,
              <http://www.rfc-editor.org/info/rfc4919>.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <http://www.rfc-editor.org/info/rfc6690>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing", RFC
              7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

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 May 29, 2016                  [Page 7]