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]