Internet DRAFT - draft-carey-core-std-msg-vs-trans-adapt

draft-carey-core-std-msg-vs-trans-adapt







Constrained RESTful Environments                                T. Carey
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational                             June 17, 2015
Expires: December 19, 2015


        Standard Primitives versus Transport Specific Adaptation
               draft-carey-core-std-msg-vs-trans-adapt-00

Abstract

   This draft discusses the need for a consistent messaging layer that
   can be used but the transport protocols as they adapt to the CoAP
   Request/Response layer.  In addition, this draft provides comments to
   the TCP transport implementaton described by
   [I-D.tschofenig-core-coap-tcp-tls].

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 December 19, 2015.

Copyright Notice

   Copyright (c) 2015 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.



Carey                   Expires December 19, 2015               [Page 1]

Internet-Draft          CoAP Standard Primitives               June 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Confusion in the CoAP Message Layer . . . . . . . . . . . . .   2
   3.  Standard Primitives vs Transport Specific Adaptation  . . . .   4
   4.  Standardize Message Layer . . . . . . . . . . . . . . . . . .   6
   5.  Issues with the Current TCP Draft . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   In review of [I-D.tschofenig-core-coap-tcp-tls], we realized that
   this draft:

   o  Didn't support the CoAP message layer's use of ACK/RST in CON and
      NON message types or the message-id.  In fact, the draft
      explicityly removed support for the CON message types and didn't
      support CoAP ACK mechanisms - relying on the TCP ack/rst/fin
      messages and timeout mechanisms.

   o  Didn't explicitly discuss how piggy backed responses would be
      handled.

   o  Made the assumption that the Blockwise protocol was supported but
      did not describe how Blockwise would be supported within the
      concep of TCP connections.

   o  Didn't explicitly discuss how TCP connections related to the
      higher layer Request-Response/Observe-Notify and the newer Publish
      and Subscribe message exchange patterns.

2.  Confusion in the CoAP Message Layer

   RFC 7252 described a Message Layer to allow for Confirmable/Non-
   confirmable delivery of Request/Response messages.  The unstated
   purpose of this message layer was that it was to be used for
   unreliable transports (e.g., UDP, SMS).  Several drafts (e.g.,
   Observe [I-D.ietf-core-observe], Block [I-D.ietf-core-block]) and
   standards groups (e.g., OMA, oneM2M) have referred to the Message
   Layer (Adaptation Layer) primitives (e.g., CON, NON, ACT, RST,
   Message id) in their processing.  As such the interface between the
   Application and Request/Response Layer was assumed to extend into the
   primitives offered by the Adaptation Layer.  Subsequent
   clarifications of the Application Layer interaction was provided that




Carey                   Expires December 19, 2015               [Page 2]

Internet-Draft          CoAP Standard Primitives               June 2015


   Applications (e.g., LWM2M Clients and Servers) interact with the CoRE
   Application Features and/or the underlying Request/Response Layers.

   The following Figure depicts the CoAP Layers with the initial set of
   Transport protocols and CoAP Features.


   .----------------------------------------.  -.
   |             Applications               |   |
   |             (LWM2M)                    |   |
   |             .--------------------.     |   | Application
   |             |   Group  |Resource |     |   | Layer
   |             |          |Directory|     |   |
   |   .---------+----------+---------+-----|  -+
   |   |         |  Request/Response        |   | Request/
   |   |  Block  |  Observe/Notify          |   | Response
   |   |         |  Publish/Subscribe       |   | Layer
   +---+---------+--------------------------'  -+
   | Unreliable Transport |                     |
   | Message Layer        |                     | Adaptation
   | (NON-CON)            |                     | Layer
   |                      |                     |
   |      .--------.      |                    -+
   |      |  DTLS  |      |                     |
   +------+--------+------+                     | Transport
   |   UDP    |    SMS    |                     | Layer
   |          |           |                     |
   '----------+-----------'                    -'


                           Figure 1: CoAP Layers

   While the clarification of the Application Layer provided an
   explaination of how Applications should interact with the Request/
   Response Layer, the discussion highlighted an additional problem.
   There isn't a single consistent interface between the Adaptation
   Layer and the Request/Response Layer.  This consistency was lost when
   new Transport protocols did not implement the message primitivies
   (e.g., CON/NON, ACK, RST) of the UDP/SMS Messaging Layer.












Carey                   Expires December 19, 2015               [Page 3]

Internet-Draft          CoAP Standard Primitives               June 2015


   The following Figure depicts the CoAP Layers with the new set of
   Transport protocols.


   .--------------------------------------------------.  -.
   |             Applications (LWM2M)                 |   |
   |             .-------+-----------.                |   | Application
   |             | Group | Resource  |                |   | Layer
   |             |       | Directory |                |   |
   |     .-------+-------+-----------+----------------+  -+
   |     |       |  Request/Response                  |   | Request/
   |     | Block |  Observe/Notify                    |   | Response
   |     |       |  Publish/Subscribe                 |   | Layer
   |     |       |                                    |   |
   '-----+-------+------------------------------------'  -'
   ==================================================== No Standard
   ==================================================== Primitives
   .----------------------.   .---------.   .---------.  -.
   | Unreliable Transport |   | Message |   | Message |   |
   | Message Layer        |   | Layer   |   | Layer   |   | Adaptation
   | (NON-CON)            |   | NON     |   | Web     |   | Layer
   |                      |   |         |   | Socket  |   |
   |      .--------.      |   |-----.   |   +---------+  -+
   |      |  DTLS  |      |   | TLS |   |   | Web     |   |
   +------+--------+------+   |-----+---|   | Socket  |   |
   |   UDP    |    SMS    |   |   TCP   |   |----.    |   | Transport
   |          |           |   |         |   |TLS |    |   | Layer
   '----------------------'   '---------'   |----+----|   |
                                            |   TCP   |   |
                                            '---------'  -+


                  Figure 2: CoAP Layers (New Transports)

3.  Standard Primitives vs Transport Specific Adaptation

   If a standard set of primitives were used, each Transport protocol
   would document how to implement the CON and NON messages with ACK and
   RST responses.  The Request/Response Layer feature would describe how
   to adapt timeouts and state processing of the Message Layer.  This
   would provide for a clean delineation of responsibility such that
   developers of new Transport protocols and Request/Response features
   would know exactly what the behavior is that is provided and consumed
   by each layer (i.e., Transport, Request/Response).







Carey                   Expires December 19, 2015               [Page 4]

Internet-Draft          CoAP Standard Primitives               June 2015


   The following Figure depicts the CoAP Layers with a standard Message
   Layer.


   .--------------------------------------------------.  -.
   |             Applications (LWM2M)                 |   |
   |             .-------+-----------.                |   | Application
   |             | Group | Resource  |                |   | Layer
   |             |       | Directory |                |   |
   |     .-------+-------+-----------+----------------+  -+
   |     |       |  Request/Response                  |   | Request/
   |     | Block |  Observe/Notify                    |   | Response
   |     |       |  Publish/Subscribe                 |   | Layer
   |     |       |                                    |   |
   +-----+-------+------------------------------------+  -+
   |                     Message Layer                |   |
   |                     (NON-CON)                    |   | Adaptation
   |                                                  |   | Layer
   |                                                  |   |
   |      .--------.      .---+----.    .---+---------+  -+
   |      |  DTLS  |      |   |TLS |    |   | Web     |   |
   |------+--------+------|   +----+----+   | Socket  |   |
   |   UDP    |    SMS    |   |   TCP   |   +----+    |   | Transport
   |          |           |   |         |   |TLS |    |   | Layer
   '----------+-----------'   '---------'   +----+----+   |
                                            |   TCP   |   |
                                            '---------'  -'


                Figure 3: CoAP Layers - Standard Primitives

   If transport specific adaptation is used, the transport protocol
   would specify how the Request/Response layer exchange patterns and
   features would be adapted by the protocol.  This will become very
   difficult to maintain as each new feature that needs aspects of a
   transport protocol will have to also include those aspects such as
   was done in the Observe draft.

   The side-effect of losing the standard set of messaging primitives is
   that each Transport will have to document how that transport adapts
   to the various elements of the Request/Response Layer (e.g., Block,
   Observe, Request, Response) rather than document how they would
   implement the standard set of messaging primitives.  In addition each
   new Request/Response feature will have to document how it will
   interact with each Transport Layer.






Carey                   Expires December 19, 2015               [Page 5]

Internet-Draft          CoAP Standard Primitives               June 2015


   The following Figure depicts the CoAP Layers with Adaptation Layers
   specific to each Transport Protocol.


   .--------------------------------------------------.  -.
   |             Applications                         |   |
   |             (LWM2M)                              |   |
   |             .--------------------.               |   | Application
   |             |   Group  |Resource |               |   | Layer
   |             |          |Directory|               |   |
   |   .---------+----------+---------+---------------+  -+
   |   |         |  Request/Response                  |   | Request/
   |   |   Block |  Observe/Notify                    |   | Response
   |   |         |  Publish/Subscribe                 |   | Layer
   '---+---------+------------------------------------'  -'

   .----------------------.   .---------.   .---------.  -.
   | Unreliable Transport |   | Message |   | Message |   |
   | Block, Req/Resp      |   | Layer   |   | Layer   |   | Adaptation
   | Observe, Pub/Sub     |   | Block...|   | Block...|   | Layer
   |                      |   |         |   |         |   |
   |      .--------.      |   +----.    |   +---------+  -+
   |      |  DTLS  |      |   |TLS |    |   | Web     |   |
   +------+---+----+----- +   +----+----+   | Socket  |   |
   |   UDP    |    SMS    |   |   TCP   |   +----+    |   | Transport
   |          |           |   |         |   |TLS |    |   | Layer
   '----------+---------- '   '---------'   +----+----+   |
                                            |   TCP   |   |
                                            '---------'  -'



           Figure 4: CoAP Layers - Transport Specific Adaptation

   Another side-effect of not using the existing set of message layer
   primitives is that Applications MUST be aware of the Transport bearer
   when invoking requests because they have to set the type of message
   (CON, NON) because a Transport (e.g., TCP) may not support the
   message (e.g., CON).

4.  Standardize Message Layer

   Using the existing CoAP Message Layer as the standard set of
   primitives allows IETF Drafts that focus on features in the Request/
   Response Layer to know what is provided by any Transport protocol.
   Likewise IETF Drafts for CoRE elements will know th e messages that
   are needed to be either implemented or provided.




Carey                   Expires December 19, 2015               [Page 6]

Internet-Draft          CoAP Standard Primitives               June 2015


   Note: The draft does not suffest Message Layer mechanisms like
   transport specific timeout processing will be exposed, just the
   messaging.
















































Carey                   Expires December 19, 2015               [Page 7]

Internet-Draft          CoAP Standard Primitives               June 2015


   The following Figure depicts the message interactions between the
   CoAP Layers using a standardized Message Layer.


   Application Layer

                   REQ (CON, NON)       ^
                       |                |
                       |                |
   |-------------------+----------------+----------------------|
                       |                |
                       |                |
                       v               RSP


   Request/Response Layer
    Request-Response,
    Observe-Notify,
    Block, Pub-Sub

                   Confirmable                 Non-confirmable
                                        |
                                        |
                                        |
           CON      ^       ^       ^   |      NON     ^
            |       |       |       |   |       |      |
            |       |       |       |   |       |      |
   |--------+-------+-------+-------+---|-------+------+-------|
            |       |       |       |   |       |      |
            |       |       |       |   |       |      |
            v    CON-ACK CON-RST CON-TMO        v   NON-RST
          \                             /     \              /
           \        Message-Id         /       \ Message-Id /
            ---------------------------         ------------

   Message Layer
   (Tansport Adaptation)

   |----------------Transport Protocol Specific----------------|

   Transport Layer
   (TCP, UDP, SMS, Websockets)


              Figure 5: CoAP Layers - Standard Message Layer






Carey                   Expires December 19, 2015               [Page 8]

Internet-Draft          CoAP Standard Primitives               June 2015


5.  Issues with the Current TCP Draft

   The current draft [I-D.tschofenig-core-coap-tcp-tls], has the
   following issues:

   1.  TCP Connections: TCP connections in the current draft are
       currently limited to a single Request/Response information
       exchange.  This limitation means that multiple TCP connections
       are needed for parallel information exchanges.  For example, an
       Observe/Notification information exchange would have to be on a
       different TCP connection as a simple Get request, causing
       multiple costly TCP connections to be established.  In addition,
       long lived TCP connections could not be supported unless the
       Application serialized the Request/Response exchange which is
       difficult with Request/Response features like Observe.  As such,
       modifications to the draft to allow Long TCP connections with
       multiple Request/Response Information exchanges is needed.

   2.  Blockwise Transfer: The current draft does not include
       documentation of how to handle Block transfers especially with
       the use of the TCP ack and empty messages.  Actually the
       Blockwise transfer draft should be modified to use the Request/
       Response terminology instead of the ACK message terms (e.g.,
       Section 3.1 Block2 examples.  This is an example of the confusion
       caused by not having a standardized set of message primitives.

   3.  Accounting for Request/Response Layer Usage - Observe: The
       current TCP draft needs to document how to account for:

       *  Confirmable messages in the Observe draft (section 1.2, 3.4,
          3.6, 4.5, 4.5.1): The use of message ID in non-confirmable
          messages (section 4.5) and adpatation of congestion control
          (section 4.5.1).  The TCP draft should document how it
          emulates the behavior of the confirmable messages in each of
          the sections.  For example the use of TCP acks as a
          replacement for CON message ACKs.

       *  Use of Message Id in non-confirmable messages in the Observe
          draft (section 4.5): Since Message Ids are elided, the draft
          needs to document how the RST messages for Notifications
          should be handled unless Message Ids are indeed supported in a
          future TCP draft.

       *  Adaptation of congestion control in the Observe draft (section
          4.5.1): The TCP drafts needs to document how congestion
          control would be done for simultaneous Notifications.





Carey                   Expires December 19, 2015               [Page 9]

Internet-Draft          CoAP Standard Primitives               June 2015


       *  Use of the Message Id to ensure no duplication through the
          Request/Response Layer: The TCP protocol will only ensure
          duplication at the TCP layer.  The TCP protocol doesn't
          prevent an invoking Request/Response layer from sending the
          message more than once for any reason (good or bad).  As such
          the support of Message ID is still needed as the TCP layer is
          insufficiant because the solution cannot address possibilities
          at the Request/Response layer.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   None

8.  References

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

   [I-D.ietf-core-observe]
              Hartke, K., "Observing Resources in CoAP", draft-ietf-
              core-observe-16 (work in progress), December 2014.

   [I-D.tschofenig-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-tschofenig-core-coap-
              tcp-tls-03 (work in progress), April 2015.

Author's Address

   Timothy Carey
   Alcatel-Lucent
   TX
   US

   Phone: +1-972-415-2065
   Email: timothy.carey@alcatel-lucent.com









Carey                   Expires December 19, 2015              [Page 10]