[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/