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]