CoRE Working Group B. Silverajan Internet-Draft Tampere University of Technology Intended status: Informational T. Savolainen Expires: August 22, 2013 Nokia February 18, 2013 CoAP Communication with Alternative Transports draft-silverajan-core-coap-alternative-transports-00 Abstract CoAP is being standardised as an application level REST-based protocol. A single CoAP message is typically encapsulated and transmitted using UDP. This draft examines the requirements and possible solutions for conveying CoAP packets to end points over alternative transports to UDP. While UDP remains an optimal solution for use in IP-based constrained environments and nodes, M2M communication using non-IP networks, NAT and firewall traversal issues and possibly mechanisms incurring a lower overhead to CoAP/ HTTP gateways provide compelling motivation for understanding how CoAP can operate in various other environments. 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 August 22, 2013. Copyright Notice Copyright (c) 2013 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 Silverajan & Savolainen Expires August 22, 2013 [Page 1] Internet-Draft CoAP Alternative Transports February 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rationale and Benefits . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. CoAP Transport URI . . . . . . . . . . . . . . . . . . . . 5 4.2. Differences in Transports . . . . . . . . . . . . . . . . . 6 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. Informative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Silverajan & Savolainen Expires August 22, 2013 [Page 2] Internet-Draft CoAP Alternative Transports February 2013 1. Introduction The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is being standardised by the CoRE WG as a lightweight, HTTP-like protocol that provides a request/response model that constrained nodes can use to communicate with other nodes, be those servers, proxies, gateways, less constrained nodes, or other constrained nodes. CoAP's functionality and packet sizes have been specified in order to allow constrained nodes the ability to execute a simple application protocol to set and retrieve resources using a REST-based approach. To allow for very low communication overhead as well as the unreliability of constrained environments, CoAP is bound to UDP with optional reliability, to support unicast and multicast communication. Security is provided by means of the Datagram Transport Layer Security (DTLS). Interworking with web is being standardized by means of stateless HTTP mapping. Owing to its simplicity, CoAP is an attractive option for all manner of uses. In addition to simple end-to-end communication between CoAP end-points as well as between CoAP and HTTP-based end-points, it has also being used towards resource discovery and lookups, group-based communication, proxying and mirroring resources on behalf of sleeping nodes. As the heterogeneity of interconnected networks and nodes continues increasing, alternative modes of transporting CoAP packets, in addition to UDP should be considered. This allows, for instance, retrieval of resource values and attributes of sensor nodes in non-IP networks and the ability of nodes to overcome firewall and NAT traversal issues. As the Internet of Things takes shape and begins integrating with new kinds of networks and services, it is important to understand the relevance of extending CoAP towards new transport protocols in order to have a uniform method of lightweight retrieval and modification of resources on constrained end-points and M2M communication. Not all constrained nodes might have the ability to take advantage of IP. At the same time, not all nodes with the ability to run CoAP over UDP will be confined to just one type of networking technology. This document generalizes the CoAP Unique Resource Identifier (URI), specified in [I-D.ietf-core-coap] and further expanded in [I-D.becker-core-coap-sms-gprs]These drafts describe CoAP using the "coap:", "coaps:" as well as "coap+tel:" URI chemes. In this draft we explore how the URI can be further extended towards specifying usable and alternative transports without imposing incompatibilities with current practices. The mechanisms introduced should remain Silverajan & Savolainen Expires August 22, 2013 [Page 3] Internet-Draft CoAP Alternative Transports February 2013 conformant to practices stipulated in RFC4395 [RFC4395] This draft does not discuss on application QoS requirements, user policies or network adaptation, nor does it advocate replacing the current practice of UDP-based CoAP communication. The scope of this draft is limited towards a description and a requirements capture of how CoAP packets can be transmitted over alternative transports, espeically how such protocols can be expressed at the CoAP layer, as well as how CoAP packets can be mapped at transport level payloads. 2. Rationale and Benefits The variety of alternative transports is large. These include IETF specified transport protocols such as TCP and Websockets, Disruption Tolerant technologies such as the Bundle Protocol, non-IP transports based on Bluetooth Low Energy and Near-Field Communications (NFC). [I-D.ietf-core-coap] acknowledges that CoAP can be used in conjunction with XMPP and SIP and [I-D.becker-core-coap-sms-gprs] documents ongoing work on letting CoAP work with Short Message Service (SMS). It is nevertheless important to understand the relevance of extending CoAP towards new transport protocols in order to have a uniform method of lightweight retrieval and modification of resources on constrained end-points by exploiting the underlying native characteristics of such networks and ther transports without necessarily having to rely on an IP adaptation layer. Doing so allows CoAP implementations to have a signficantly larger relevance in constrained as well as non-constrained networked environments. It leads to better code optimisation in constrained nodes and implementation reuse across new transport networks, whereby a node can continue relying on the same REST-based API changing its end point identifier and transport protocol, when for example, its network technology migrates from a non-IP transport to an IP and UDP- based transport. This might be the case in a ZigBee or BLE node having CoAP over a proprietary network layer but subsequently supporting UDP/IP adaptation. 3. Use Cases CoAP [I-D.ietf-core-coap] has been designed to work on top of UDP/IP, that is, on top of transport that can lose, reorder, and duplicate packets. UDP has been chosen as the transport protocol over IP due its lightweight nature and connectionless characteristics allowing functions such as multicast and group communications [I-D.ietf-core-groupcomm]. Silverajan & Savolainen Expires August 22, 2013 [Page 4] Internet-Draft CoAP Alternative Transports February 2013 While the nature of UDP/IP transport for CoAP is well suited for constrained node communications [RFC6568], there are use cases where alternative transports would be better suited, or where UDP/IP is simply not available. In this section we discuss about a set of use cases where different transport channels could be useful. A host with a CoAP client may reside behind a NAT or a firewall, and would like to talk to a CoAP server, possibly by using CoAP Observe- functionality [I-D.ietf-core-observe]. However, the host would wish to conserve resources, such as energy, and avoid NAT keepalives required to maintain NAT/firewall mappings. Furthermore, the application on the host may need to use HTTP for (initial) communications, but would preferably avoid use of HTTP/CoAP proxy, especially with "long polling" feature, required to be able to receive data from the CoAP server. For the sake of simplicity, an application would like to communicate with constrained nodes using CoAP without using IP-based transport channels. For example, the application would like to use SMS [I-D.becker-core-coap-sms-gprs] or Bluetooth Low-Energy [BTCorev4.0] for communications. Furthermore, an application may be communicating via Delay-Tolerant Networks [RFC4838] using Bundle Protocol [RFC5050], and would like to transport CoAP formatted messages. In all of these cases it is not a given that UDP or IP are supported by a transport channel. 4. Problem Statement 4.1. CoAP Transport URI In order to support generic transports, the CoAP URI needs to be able to distinguish the transport that needs to be used. Several alternatives for the CoAP Transport URI scheme can be envisioned based on available existing practices. For example: 1. "coap+transport:" "//" identifier path-abempty [ "?" query ] This URI conforms to RFC4395 and is the preferred form used by [I-D.becker-core-coap-sms-gprs] 2. coap:[options]http:[//host[:[port][transport]]/ used by the paparazzi name scheme (https://www.iana.org/assignments/uri-schemes/prov/paparazzi). 3. "coap:" "//" host [ ":" port ] path-abempty [ "?" query ] [ transport ], where transport = "; transport=" transport-protocol and transport-protocol describes the specific transport (such as tcp, l2cap, etc). This URI scheme is used by the Diameter Base Silverajan & Savolainen Expires August 22, 2013 [Page 5] Internet-Draft CoAP Alternative Transports February 2013 Protocol [RFC3588] 4.2. Differences in Transports 5. Requirements 6. Acknowledgements 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations 9. Informative References [BTCorev4.0] BLUETOOTH Special Interest Group, "BLUETOOTH Specification Version 4.0", June 2010. [I-D.becker-core-coap-sms-gprs] Becker, M., Li, K., Kuladinithi, K., and T. Poetsch, "Transport of CoAP over SMS, USSD and GPRS", draft-becker-core-coap-sms-gprs-03 (work in progress), February 2013. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-13 (work in progress), December 2012. [I-D.ietf-core-groupcomm] Rahman, A. and E. Dijk, "Group Communication for CoAP", draft-ietf-core-groupcomm-05 (work in progress), February 2013. [I-D.ietf-core-observe] Hartke, K., "Observing Resources in CoAP", draft-ietf-core-observe-07 (work in progress), October 2012. [OMALWM2M] Open Mobile Alliance (OMA), "Lightweight Machine to Silverajan & Savolainen Expires August 22, 2013 [Page 6] Internet-Draft CoAP Alternative Transports February 2013 Machine Technical Specification", 2013. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. Authors' Addresses Bilhanan Silverajan Tampere University of Technology Korkeakoulunkatu 10 FI-33720 Tampere Finland Email: bilhanan.silverajan@tut.fi Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland Email: teemu.savolainen@nokia.com Silverajan & Savolainen Expires August 22, 2013 [Page 7]