CoRE Working Group                                         B. Silverajan
Internet-Draft                          Tampere University of Technology
Intended status: Informational                             T. Savolainen
Expires: August 18, 2014                                           Nokia
                                                       February 14, 2014

             CoAP Communication with Alternative Transports


   CoAP is being standardised as an application level REST-based
   protocol.  A single CoAP message is typically encapsulated and
   transmitted using UDP or DTLS as transports.  These transports are
   optimal solutions for CoAP use in IP-based constrained environments
   and nodes.  However compelling motivation exists for understanding
   how CoAP can operate with other transports, such as the need for M2M
   communication using non-IP networks, improved transport level end-to-
   end reliability and security, NAT and firewall traversal issues, and
   mechanisms possibly incurring a lower overhead to CoAP/HTTP
   translation gateways.  This draft examines the requirements for
   conveying CoAP packets to end points over such alternative
   transports.  It also provides URI solutions for representing CoAP
   resources over alternative transports.

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

   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 18, 2014.

Copyright Notice

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

Silverajan & Savolainen  Expires August 18, 2014                [Page 1]

Internet-Draft         CoAP Alternative Transports         February 2014

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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
   2.  Usage Cases . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Use of SMS  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Use of WebSockets . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Use of P2P Overlays . . . . . . . . . . . . . . . . . . .   4
     2.4.  Use of TCP  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.5.  Others  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Node Types based on Transport Availability  . . . . . . . . .   5
   4.  CoAP Transport URI  . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Design Considerations . . . . . . . . . . . . . . . . . .   7
     4.2.  Transport information in URI scheme . . . . . . . . . . .   8
     4.3.  Transport information as part of the URI authority  . . .   9
       4.3.1.  Usage of DNS records  . . . . . . . . . . . . . . . .   9
     4.4.  Making CoAP Resources Available over Multiple Transports   10
   5.  Alternative Transport Analysis and Properties . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

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 providing 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.

   As the Internet continues taking shape by integrating new kinds of
   networks, services and devices, the need for a consistent,
   lightweight method for resource representation, retrieval and
   manipulation becomes evident.  Owing to its simplicity and low
   overhead, CoAP is a highly suitable protocol for this purpose.
   However, the CoAP endpoint can reside in a non-IP network, be
   separated from its peer by NATs and firewalls or simply has no

Silverajan & Savolainen  Expires August 18, 2014                [Page 2]

Internet-Draft         CoAP Alternative Transports         February 2014

   possibility to communicate over UDP.  Consequently in addition to
   UDP, alternative transport channels for conveying CoAP packets could
   be considered.

   Extending CoAP-based resource retrieval over alternative transports
   allows implementations to have a significantly larger relevance in
   constrained as well as non-constrained networked environments.  It
   leads to better code optimisation in constrained nodes and broader
   implementation reuse across new transport channels.  As opposed to
   implementing new resource retrieval schemes, an application in an
   end-node can continue relying on using CoAP's REST-based method calls
   for this purpose, but lets CoAP's messaging sublayer take into
   account the change in end point identification and transport
   protocol.  This simplifies development and memory requirements.
   Resource representations are also visible in an end-to-end manner for
   any CoAP client.  The processing and computational overhead for
   conveying CoAP packets from one underlying transport to another,
   would be less than that of an application-level gateway performing
   individual packet-based, protocol translation between CoAP to another
   resource retrieval scheme.

   This document looks at how CoAP can be used by nodes for resource
   retrieval, in an end-to-end manner regardless of the transport
   channel available.  It looks at current usage of CoAP in this regard
   today and provides other possible scenarios.  A simple transport type
   classification is provided.  Then we look at the various ways in
   which CoAP resource representations can be formulated in URIs over
   alternative, which express transport identification in addition to
   endpoint information and resource paths.  Following that, a
   discussion of the various transport properties which influence how
   CoAP packets are mapped to transport level payloads, is presented.

   This draft however, 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.

2.  Usage Cases

   Apart from UDP and DTLS, CoAP usage is being specified for the
   following environments:

2.1.  Use of SMS

   CoAP Request and Response messages can be sent via SMS between CoAP
   end-points in a cellular network [I-D.becker-core-coap-sms-gprs].  A
   CoAP Request message can also be sent via SMS from a CoAP client to a
   sleeping CoAP Server as a wake-up mechanism and trigger communication
   via IP.  The Open Mobile Alliance (OMA) specifies both UDP and SMS as

Silverajan & Savolainen  Expires August 18, 2014                [Page 3]

Internet-Draft         CoAP Alternative Transports         February 2014

   transports for M2M communication in cellular networks.  The OMA
   Lightweight M2M protocol being drafted uses CoAP, and as transports,
   specifies both UDP binding as well as Short Message Service (SMS)
   bindings [OMALWM2M] for the same reason.

2.2.  Use of WebSockets

   The WebSocket protocol is being used as a transport channel between
   WebSocket enabled CoAP end-points on the Internet
   [I-D.savolainen-core-coap-websockets].  This is particularly useful
   as a means for web browsers, particularly in smart devices, to allow
   embedded client side scripts to upgrade an existing HTTP connection
   to a WebSocket connection through which CoAP Request and Response
   messages can be exchanged with a WebSocket-enabled server.  This also
   allows a browser containing an embedded CoAP server to behave as a
   WebSocket client by opening a connection to a WebSocket enabled CoAP
   Mirror Server to register and update its resources.

2.3.  Use of P2P Overlays

   [I-D.jimenez-p2psip-coap-reload] specifices how CoAP nodes can use a
   peer-to-peer overlay network called RELOAD, as a resource caching
   facility for storing wireless sensor data.  When a CoAP node
   registers its resources with a RELOAD Proxy Node (PN), the node
   computes a hash value from the CoAP URI and stores it as a structure
   together with the PN's Node ID as well as the resources.  Resource
   retrieval by CoAP nodes is accomplished by computing the hash key
   over the Request URI,opening a connection to the overlay and using
   its message routing system to contact the CoAP server via its PN.

2.4.  Use of TCP

   Using TCP to facilitate the traversal of CoAP Request and Response
   messages [I-D.bormann-core-coap-tcp].  This allows easier
   communication between CoAP clients and servers separated by firewalls
   and NATS.  This also allows CoAP messages to be transported over push
   notification services from a notification server to a client app on a
   smartphone, that may previously have subscribed to receive change
   notifications of CoAP resource representations, possibly by using
   CoAP Observe-functionality [I-D.ietf-core-observe].

2.5.  Others

   We also envisage CoAP being extended atop other transport channels,
   such as:

   1.  The transportation of CoAP messages in Delay-Tolerant Networks
       [RFC4838], using the Bundle Protocol [RFC5050] for reaching

Silverajan & Savolainen  Expires August 18, 2014                [Page 4]

Internet-Draft         CoAP Alternative Transports         February 2014

       sensors in extremely challenging environments such as acoustic,
       underwater and deep space networks.

   2.  Any type of non-IP networks supporting constrained nodes and low-
       energy sensors, such as Bluetooth and Bluetooth Low Energy
       (either through L2CAP or with GATT) [BTCorev4.1], ZigBee, Z-Wave,
       1-Wire, DASH7 and so on.

   3.  Instant Messaging and Social Networking channels, such as Jabber
       and Twitter.

3.  Node Types based on Transport Availability

   The term "alternative transport" in this document thus far has been
   used to refer to any non-UDP and non-DTLS transport that can convey
   CoAP messages in its payload.  A node however, may in fact possess
   the capability to utilise CoAP over multiple transport channels at
   its disposal, simultaneously or otherwise, at any point in time to
   communicate with a CoAP end-point.  Such communication can obviously
   take place over UDP and DTLS as well.  Inevitably, if two CoAP
   endpoints reside in distinctly separate networks with orthogonal
   transports, a CoAP proxy node is needed between the 2 networks so
   that CoAP Requests and Responses can be fulfilled properly.

   In [I-D.ietf-lwig-terminology], Tables 1, 3 and 4 introduced
   classification schemes for devices, in terms of their resource
   constraints, energy limitations and communication power.  For this
   document, in addition to these capabilities, it seems useful to
   additionally identify devices based on their transport capabilities.

     | Name  |  Transport Availability    |
     |  T0   |  Single transport          |
     |       |                            |
     |  T1   |  Multiple transports, with |
     |       |  one or more active at any |
     |       |  point in time             |
     |       |                            |
     |  T2   |  Multiple active transports|

    Table 1: Classes of Available Transports

   Nodes falling under Type T0 possess the capability of exactly 1 type
   of transport channel for CoAP, at all times.  These include both

Silverajan & Savolainen  Expires August 18, 2014                [Page 5]

Internet-Draft         CoAP Alternative Transports         February 2014

   active and sleepy nodes, which may choose to perform duty cycling for
   power saving.

   Type T1 nodes possess multiple different transports, and can perform
   CoAP resource retrieval or expose CoAP resources over any or all of
   these transports.  However, not all transports are constantly active
   and certain transport channels and interfaces could be kept in a
   mostly-off state for energy-efficiency, such as in section 2.1

   Type T2 nodes possess more than 1 transport, and multiple transports
   are simultaneously active at all times.  CoAP proxy nodes which allow
   CoAP endpoints from disparate transports to communicate with each
   other, are a good example of this.

4.  CoAP Transport URI

   Based on the usage scenarios as well as the transport classes
   presented in the preceding sections, this section discusses the
   formulation of a new URI for representing CoAP resources over
   alternative transports.

   CoAP is logically divided into 2 sublayers, whereby a request/
   response layer is responsible for the protocol functionality of
   exchanging request and response messages, while the messaging layer
   is bound to UDP.  These 2 sublayers are tightly coupled, both being
   responsible for properly encoding the header and body of the CoAP
   message.  The COAP URI is used by both logical sublayers.  For a URI
   that is expressed generically as

   URI = scheme ":" "//" authority path-abempty ["?"query ]

   A simple example COAP URI, "coap://
   temperature" can be interpreted as follows:

      coap :// /sensors/temperature
      \___/    \______  ________/  \______  _________/
        |             \/                  \/
     protocol      endpoint          parameterised
    identifier    identifier           resource

                       Figure 1: The CoAP URI format

   The resource path is explicitly expressed, and the endpoint
   identifier, which contains the host address at the network-level is

Silverajan & Savolainen  Expires August 18, 2014                [Page 6]

Internet-Draft         CoAP Alternative Transports         February 2014

   also directly bound to the scheme name containing the application-
   level protocol identifier.  The choice of a specific transport for a
   scheme, however, cannot be embedded with a URI, but is defined by
   convention or standardisation of the protocol using the scheme.  As
   examples, [RFC5092] defines the 'imap' scheme for the IMAP protocol
   over TCP, while [RFC2818] requires that the 'https' protocol
   identifier be used to differentiate using HTTP over TLS instead of

4.1.  Design Considerations

   Several ways of formulating a URI which express an alternative
   transport binding to CoAP, can be envisioned.  When such a URI is
   provided from an end-application to its CoAP implementation, the URI
   component containing transport-specific information can be checked to
   allow the CoAP to use the appropriate transport for a target endpoint
   identifier.  The following design considerations influence the
   formulation of a new URI expressing CoAP resources over alternative

   1.  The generic syntax for a URI is described in [RFC3986].
       Conformance to RFC3986 would also obviate the need for custom URI
       parsers as well as resolution algorithms.  In particular, how can
       a URI format be described in which each URI component clearly
       meets the syntax and percent-encoding rules described?

   2.  When relative references are encountered, [RFC3986] also
       establishes how they can be resolved against a base URI by
       providing an algorithm.  Given this algorithm, how can a URI
       format be described in which relative reference resolution does
       not result in a target URI that loses its transport-specific

   3.  URIs are designed to uniquely identify resources.  When a single
       resource is represented with multiple URIs (for example, an owner
       of two different domains deciding to serve the same resource from
       both), URI aliasing [WWWArchv1] occurs.  Avoiding URI aliasing is
       considered good practice.  However, when a node of Type T1 or T2
       exposes a resource over multiple transport end-points, URI
       aliasing can occur if transport-specific information is embedded
       in a URI.  How can a URI format be described, which avoids or at
       least minimises occurrences of URI aliasing?

   4.  The host component of current CoAP URIs can either be a numerical
       IP address or a fully qualified domain name (FQDN).  While the
       usage of DNS can sometimes be useful for distinguishing transport
       information (see section 4.3.1), accessing DNS over some
       alternative transport environments may be challenging.

Silverajan & Savolainen  Expires August 18, 2014                [Page 7]

Internet-Draft         CoAP Alternative Transports         February 2014

       Therefore, how can a URI format be described, which expresses
       resources without heavy reliance on a naming infrastructure, such
       as DNS?

   A CoAP Transport URI can also be supplied as a Proxy-Uri option by a
   CoAP end-point to a CoAP forward proxy in order to communicate with a
   CoAP end-point residing in a network using a different transport.
   Section 6.4 of [I-D.ietf-core-coap] provides an algorithm for parsing
   a received URI to obtain the request's options.  The following
   sections outline various choices for URIs that meet some of these
   design goals.

4.2.  Transport information in URI scheme

   The URI scheme can follow a convention of the form "coap+<transport-
   name>", where the name of the transport is clearly and unambiguously
   described.  Each scheme name formed in this manner can be used to
   differentiate the use of CoAP over an alternative transport instead
   of the use of CoAP over UDP or DTLS.  The endpoint identifier, path
   and query components together with each scheme name would be used to
   uniquely identify each resource.

   Examples of such URIs are:

   o  coap+tcp://[2001:db8::1]:5683/sensors/temperature for using CoAP
      over TCP

   o  coap+sms://0015105550101/sensors/temperature for using CoAP over
      SMS or USSD with the endpoint identifier being a telephone
      subscriber number

   o  coap+ws:// for using
      CoAP over WebSockets with the endpoint at ws://

   Note: Expressing target address formats other than IPv6 literal
   addresses with '[' and ']' characters within this URI format, such as
   Bluetooth, is as yet unresolved.

   A new URI of this format to distinguish transport types is simple to
   understand and generally not dissimilar to the CoAP URI format.  It
   is however entirely possible for each new scheme to specify its own
   rules for how resource and transport endpoint information can be
   presented.  The URI meets many of the design goals described,
   although URI aliasing cannot be avoided for multiple transport end-
   points.  As the usage of each alternative transport results in an
   entirely new scheme, IANA intervention is required for the
   registration of each scheme name.  The registration process follows

Silverajan & Savolainen  Expires August 18, 2014                [Page 8]

Internet-Draft         CoAP Alternative Transports         February 2014

   the guidelines stipulated in [RFC4395], particularly where permanent
   URI scheme registration is concerned.

4.3.  Transport information as part of the URI authority

   A single URI scheme, "coap-at" can be introduced, as part of an
   absolute URI which expresses the transport information within the
   authority component.  One approach is to structure the component with
   a transport prefix to the endpoint identifier and a delimiter, such
   as "<transport-name>-endpoint_identifier".

   Examples of resulting URIs are:

   o  coap-at://

   o  coap-at://sms-0015105550101/sensors/temperature

   An implementation note here is that some generic URI parsers will
   fail when encountering a URI such as "coap-at://tcp-[2001:db8::1]/
   sensors/temperature".  Consequently, an equivalent, but parseable URI
   from the domain needs to be formulated instead.  For
   [2001:db8::1] using TCP, this would result in the following URL:


   Usage of an IPv4-mapped IPv6 address such as [::ffff.] can
   similarly be expressed with a URI from the domain.

   This URI format allows the usage of a single scheme to represent
   multiple types of transport end-points.  Consequently, it requires
   consistency in ensuring how various transport-specific endpoints are
   identified, as a single URI format is used.  Attention must be paid
   towards the syntax rules and encoding for the URI host component.
   Additionally, against a base URI of the form "coap-at://tcp-", resolving a relative
   reference, such as "//" would result
   in the target URI "coap-at://", in
   which transport information is lost.  As with the URI presented
   previously in Section 4.2, URI aliasing issues persist with this
   format too.

4.3.1.  Usage of DNS records

   DNS names can be used instead of IPv6 address literals to mitigate
   lengthy URLs referring to the domain, if usage of DNS is

Silverajan & Savolainen  Expires August 18, 2014                [Page 9]

Internet-Draft         CoAP Alternative Transports         February 2014

   DNS SRV records can also be employed to formulate a URL such as:


   in which the "srv" prefix is used to indicate that a DNS SRV lookup
   should be used for, where usage of CoAP over
   TCP is specified for, and is eventually resolved to a
   numerical IPv4 or IPv6 address.

4.4.  Making CoAP Resources Available over Multiple Transports

   The CoAP URI used thus far is as follows:

        URI         = scheme ":" hier-part [ "?" query ]
        hier-part   = "//" authority path-abempty

   A new URI format could be introduced, that does not possess an
   "authority" component, and instead defining "hier-part" to instead
   use another component, "path-rootless", as specified by RFC3986
   [RFC3986].  The partial ABNF format of this URI would then be:

         URI         = scheme ":" hier-part [ "?" query ]
         hier-part   = path-rootless
         path-rootless = segment-nz *( "/" segment )

   The full syntax of "path-rootless" is described in [RFC3986].  A
   generic URI defined this way would conform to the syntax of
   [RFC3986], while the path component can be treated as an opaque
   string to indicate transport types, endpoints as well as paths to
   CoAP resources.  A single scheme can similarly be used.

   A constrained node that is capable of communicating over several
   types of transports (such as UDP, TCP and SMS) would be able to
   convey a single CoAP resources over multiple transports.  This is
   also beneficial for nodes performing caching and proxying from one
   type of transport to another.

   Requesting and retrieving the same CoAP resource representation over
   multiple transports could be rendered possible by prefixing the
   transport type and endpoint identifier information to the CoAP URI.
   This would result in the following example representation:

Silverajan & Savolainen  Expires August 18, 2014               [Page 10]

Internet-Draft         CoAP Alternative Transports         February 2014

           \_______  ______/ \________________  __________________/
                   \/                         \/
            Transport-specific            CoAP Resource

             Figure 2: Prefixing a CoAP URI with TCP transport

   Such a representation would result in the URI being decomposed into
   its constituent components, with the CoAP resource residing within
   the query component as follows:

   Scheme: coap-at

   Path: tcp://

   Query: coap://

   The same CoAP resource, if requested over a WebSocket transport,
   would result the following URI:

           \___________  __________/ \_______________  ___________________/
                       \/                            \/
               Transport-specific             CoAP Resource

          Figure 3: Prefixing a CoAP URI with WebSocket transport

   While the transport prefix changes, the CoAP resource representation
   remains the same in the query component:

   Scheme: coap-at

   Path: ws://

   Query: coap://

   The URI format described here overcomes the URI aliasing when
   multiple transports are used, by ensuring each CoAP resource
   representation remains the same, but is prefixed with different
   transports.  However, against a base URI of this format, resolving

Silverajan & Savolainen  Expires August 18, 2014               [Page 11]

Internet-Draft         CoAP Alternative Transports         February 2014

   relative references of the form "//"
   and "/sensor2/temperature" would again result in target URIs which
   lose transport-specific information.

   Implementation note: While square brackets are disallowed within the
   path component, the '[' and ']' characters needed to enclose a
   literal IPv6 address can be percent-encoded into their respective
   equivalents.  The ':' character does not need to be percent-encoded.
   This results in a significantly simpler URI string compared to
   section 2.2, particularly for compressed IPv6 addresses.
   Additionally, the URI format can be used to specify other similar
   address families and formats, such as Bluetooth addresses

5.  Alternative Transport Analysis and Properties

   In this section we consider the various characteristics of
   alternative transports for successfully supporting various kinds of
   functionality for CoAP.  CoAP factors lossiness, unreliability, small
   packet sizes and connection statelessness into its protocol logic.
   We discuss general transport differences and their impact on carrying
   CoAP packets here.  Note that Properties 1, 2, and 3 are related.

   Property 1: Uniqueness of an end-point identifier.

   Transport protocols providing non-unique end-point IDs for nodes may
   only convey a subset of the CoAP functionality.  Such nodes may only
   serve as CoAP servers that announce data at specific intervals to a
   pre-specified end point, or to a shared medium.

   Property 2: Unidirectional or bidirectional CoAP communication

   This refers to the ability of the CoAP end-point to use a single
   transport channel for both request and response messages.  Depending
   on the scenario, having a unidirectional transport layer would mean
   the CoAP end-point might utilise it only for outgoing data or
   incoming data.  Should both functionalities be needed, 2
   unidirectional transport channels would be necessary.

   Property 3: 1:N communication support.

   This refers to the ability of the transport protocol to support
   broadcast and multicast communication.  CoAP's request/response
   behaviour depends on unicast messaging.  Group communication in CoAP
   is bound to using multicasting.  Therefore a protocol such as TCP
   would be ill-suited for group communications using multicast.
   Anycast support, where a message is sent to a well defined

Silverajan & Savolainen  Expires August 18, 2014               [Page 12]

Internet-Draft         CoAP Alternative Transports         February 2014

   destination address to which several nodes belong, on the other hand,
   is supported by TCP.

   Property 4: Transport-level reliability.

   This refers to the ability of the transport protocol to provide a
   guarantee of reliability against packet loss, ensuring ordered packet
   delivery and having error control.  When CoAP Request and Response
   messages are delivered over such transports, the CoAP implementations
   elide certain fields in the packet header.  As an example, if the
   usage of a connection-oriented transport renders it unnecessary to
   specify the various CoAP message types, the Type field can be elided.
   For some connection-oriented transports, such as WebSockets, the
   version of CoAP being used can be negotiated during the opening
   transfer.  Consequently, the Version field in CoAP packets can also
   be elided.

   Property 5: Message encoding.

   While parts of the CoAP payload are human readable or are transmitted
   in XML, JSON or SenML format, CoAP is essentially a low overhead
   binary protocol.  Efficient transmission of such packets would
   therefore be met with a transport offering binary encoding support,
   although techniques exist in allowing binary payloads to be
   transferred over text-based transport protocols such as base-64
   encoding.  A fuller discussion about performing CoAP message encoding
   for SMS can be found in Appendix A.5 of [I-D.bormann-coap-misc]

   Property 6: Network byte order.

   CoAP, as well as transports based on the IP stack use a Big Endian
   byte order for transmitting packets over the air or wire, while
   transports based on Bluetooth and Zigbee prefer Little Endian byte
   ordering for packet fields and transmission.  Any CoAP implementation
   that potentially uses multiple transports has to ensure correct byte
   ordering for the transport used.

   Property 7: MTU correlation with CoAP PDU size.

   Section 4.6 of [I-D.ietf-core-coap] discusses the avoidance of IP
   fragmentation by ensuring CoAP message fit into a single UDP
   datagram.  End-points on constrained networks using 6LoWPAN may use
   blockwise transfers to accommodate even smaller packet sizes to avoid
   fragmentation.  The MTU sizes for Bluetooth Low Energy as well as
   Classic Bluetooth are provided in Section 2.4 of [I-D.ietf-6lo-btle].
   Transport MTU correlation with CoAP messages helps ensure minimal to
   no fragmentation at the transport layer.  On the other hand, allowing
   a CoAP message to be delivered using a delay-tolerant transport

Silverajan & Savolainen  Expires August 18, 2014               [Page 13]

Internet-Draft         CoAP Alternative Transports         February 2014

   service such as the Bundle Protocol [RFC5050] would imply that the
   CoAP message may be fragmented (or reconstituted) along various nodes
   in the DTN as various sized bundles and bundle fragments.

   Property 8: Framing

   When using CoAP over a streaming transport protocol such as TCP, as
   opposed to datagram based protocols, care must be observed in
   preserving message boundaries.  Commonly applied techniques at the
   transport level include the use of delimiting characters for this
   purpose as well as message framing and length prefixing.

   Property 9: Transport latency.

   A confirmable CoAP request would be retransmitted by a CoAP end-point
   if a response is not obtained within a certain time.  A CoAP end-
   point registering to a Resource Directory uses a POST message that
   could include a lifetime value.  A sleepy end-point similarly uses a
   lifetime value to indicate the freshness of the data to a CoAP Mirror
   Server.  Care needs to be exercised to ensure the latency of the
   transport being used to carry CoAP packets is small enough not to
   interfere with these values for the proper operation of these

   Property 10: Connection Management.

   A CoAP endpoint using a connection-oriented transport should be
   responsible for proper connection establishment prior to sending a
   CoAP Request message.  Both communicating endpoints may monitor the
   connection health during the Data Transfer phase.  Finally, once data
   transfer is complete, at least one end point should perform
   connection teardown gracefully.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   While we envisage no new security risks simply from the introduction
   of support for alternative transports, end-applications and CoAP
   implementations should take note if certain transports require
   privacy trade-offs that may arise if identifiers such as MAC
   addresses or phone numbers are made public in addition to FQDNs.

Silverajan & Savolainen  Expires August 18, 2014               [Page 14]

Internet-Draft         CoAP Alternative Transports         February 2014

8.  Acknowledgements

   Feedback, ideas and ongoing discussions with Klaus Hartke, Martin
   Thomson, Mark Nottingham, Graham Klyne, Carsten Bormann, Markus
   Becker and Golnaz Karbaschi provided useful insights and ideas for
   this work.

9.  Informative References

              BLUETOOTH Special Interest Group, "BLUETOOTH Specification
              Version 4.1", December 2013.

              Becker, M., Li, K., Poetsch, T., and K. Kuladinithi,
              "Transport of CoAP over SMS", draft-becker-core-coap-sms-
              gprs-04 (work in progress), August 2013.

              Bormann, C. and K. Hartke, "Miscellaneous additions to
              CoAP", draft-bormann-coap-misc-26 (work in progress),
              December 2013.

              Bormann, C., "A TCP transport for CoAP", draft-bormann-
              core-coap-tcp-00 (work in progress), July 2013.

              Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
              Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
              over BLUETOOTH Low Energy", draft-ietf-6lo-btle-00 (work
              in progress), November 2013.

              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-18
              (work in progress), June 2013.

              Rahman, A. and E. Dijk, "Group Communication for CoAP",
              draft-ietf-core-groupcomm-18 (work in progress), December

              Hartke, K., "Observing Resources in CoAP", draft-ietf-
              core-observe-11 (work in progress), October 2013.

Silverajan & Savolainen  Expires August 18, 2014               [Page 15]

Internet-Draft         CoAP Alternative Transports         February 2014

              Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained Node Networks", draft-ietf-lwig-terminology-06
              (work in progress), December 2013.

              Jimenez, J., Lopez-Vega, J., Maenpaa, J., and G.
              Camarillo, "A Constrained Application Protocol (CoAP)
              Usage for REsource LOcation And Discovery (RELOAD)",
              draft-jimenez-p2psip-coap-reload-03 (work in progress),
              February 2013.

              Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over
              WebSockets", draft-savolainen-core-coap-websockets-01
              (work in progress), October 2013.

              Open Mobile Alliance (OMA), "Lightweight Machine to
              Machine Technical Specification", 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2609]  Guttman, E., Perkins, C., and J. Kempf, "Service Templates
              and Service: Schemes", RFC 2609, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [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.

   [RFC5092]  Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092,
              November 2007.

Silverajan & Savolainen  Expires August 18, 2014               [Page 16]

Internet-Draft         CoAP Alternative Transports         February 2014

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
              6455, December 2011.

   [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.

   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", RFC 6733, October 2012.

    , "Architecture
              of the World Wide Web, Volume One", December 2004.

Authors' Addresses

   Bilhanan Silverajan
   Tampere University of Technology
   Korkeakoulunkatu 10
   FI-33720 Tampere


   Teemu Savolainen
   Hermiankatu 12 D
   FI-33720 Tampere


Silverajan & Savolainen  Expires August 18, 2014               [Page 17]