< draft-silverajan-core-coap-alternative-transports-09.txt   draft-silverajan-core-coap-alternative-transports-10.txt >
CoRE Working Group B. Silverajan CoRE Working Group B. Silverajan
Internet-Draft Tampere University of Technology Internet-Draft Tampere University of Technology
Intended status: Informational T. Savolainen Intended status: Informational T. Savolainen
Expires: June 23, 2016 Nokia Expires: January 4, 2018 Nokia Technologies
December 21, 2015 July 3, 2017
CoAP Communication with Alternative Transports CoAP Communication with Alternative Transports
draft-silverajan-core-coap-alternative-transports-09 draft-silverajan-core-coap-alternative-transports-10
Abstract Abstract
CoAP has been standardised as an application level REST-based The aim of this document is to provide a way forward to best decide
protocol. A single CoAP message is typically encapsulated and upon how alternative transport information can be expressed in a CoAP
transmitted using UDP or DTLS as transports. These transports are URI. This draft examines the requirements for a new URI format for
optimal solutions for CoAP use in IP-based constrained environments representing CoAP resources over alternative transports. Various
and nodes. However compelling motivation exists for allowing CoAP to potential URI formats are presented. Benefits and drawbacks of
operate with other transports and protocols. Examples are M2M embedding alternative transport information in various ways within
communication in cellular networks using SMS, more suitable transport the URI components are also discussed. From all listed formats, the
protocols for firewall/NAT traversal, end-to-end reliability and document finds scheme-based model to be the most technically
security such as TCP and TLS, or employing proxying and tunneling feasible.
gateway techniques such as the WebSocket protocol. This draft
examines the requirements for conveying CoAP messages to end points
over such alternative transports. It also provides a new URI format
for representing CoAP resources over alternative transports.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 23, 2016. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Usage Cases . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conformance and Design Considerations . . . . . . . . . . . . 4
2.1. Use of SMS . . . . . . . . . . . . . . . . . . . . . . . 4 3. Situating Transport Information in CoAP URIs . . . . . . . . 5
2.2. Use of WebSockets . . . . . . . . . . . . . . . . . . . . 4 3.1. Using the URI scheme component . . . . . . . . . . . . . 5
2.3. Use of P2P Overlays . . . . . . . . . . . . . . . . . . . 4 3.1.1. Analysis . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Use of TCP and TLS . . . . . . . . . . . . . . . . . . . 5 3.2. Using the URI authority component . . . . . . . . . . . . 6
3. Node Types based on Transport Availability . . . . . . . . . 5 3.2.1. Analysis . . . . . . . . . . . . . . . . . . . . . . 7
4. CoAP Alternative Transport URI . . . . . . . . . . . . . . . 6 3.3. Using the URI path component . . . . . . . . . . . . . . 7
4.1. Design Considerations . . . . . . . . . . . . . . . . . . 7 3.3.1. Analysis . . . . . . . . . . . . . . . . . . . . . . 7
4.2. URI format . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Using the URI query component . . . . . . . . . . . . . . 7
5. Alternative Transport Analysis and Properties . . . . . . . . 9 3.4.1. Analysis . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Expressing transport in the URI in other ways . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 9
A.1. Transport information as part of the URI authority . . . 15 Appendix A. Expressing transport in the URI in other ways . . . 10
A.1.1. Usage of DNS records . . . . . . . . . . . . . . . . 16 A.1. Transport information as part of the URI authority . . . 10
A.2. Making CoAP Resources Available over Multiple Transports 16 A.1.1. Usage of DNS records . . . . . . . . . . . . . . . . 11
A.3. Transport as part of a 'service:' URL scheme . . . . . . 18 A.2. Making CoAP Resources Available over Multiple Transports 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 A.3. Transport as part of a 'service:' URL scheme . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] has been The Constrained Application Protocol (CoAP) [RFC7252] is a
standardised by the CoRE WG as a lightweight, HTTP-like protocol lightweight, binary application layer protocol designed for
providing a request/response model that constrained nodes can use to constrained environments. Owing to its operating environment, CoAP
communicate with other nodes, be those servers, proxies, gateways, uses UDP and DTLS as its underlying transports between communicating
less constrained nodes, or other constrained nodes. CoAP has been endpoints. However, with an increase in deployment experiences as
definied to utilise UDP and DTLS as transports. well as its popularity, compelling reasons exist for extending CoAP
messaging to work over alternative transports such as TCP, TLS,
As the Internet evolves by integrating new kinds of networks, WebSockets and SMS. These allow CoAP to better address firewall and
services and devices, the need for a consistent, lightweight method NAT traversal issues, to operate in Web browser-based and HTML5
for resource representation, retrieval and manipulation becomes applications as well as for energy-constrained M2M communication in
evident. Owing to its simplicity and low overhead, CoAP is a highly cellular networks.
suitable protocol for this purpose. However, communicating CoAP
endpoints can reside in networks where end-to-end UDP-based
communication can be challenging. These include networks separated
by NATs and firewalls, cellular networks in which the Short Messaging
Service (SMS) can be utilised as between nodes, or simply situations
where an endpoint has no possibility to communicate over UDP.
Consequently in addition to UDP and DTLS, alternative transport
channels for conveying CoAP messages should be considered.
Extending CoAP over alternative transports allows CoAP
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 mechanisms, an application in an
end-node can continue relying on using CoAP's REST-based resource
retrieval and manipulation for this purpose, while changes in end
point identification and the transport protocol can be addressed by a
transport-specific messaging sublayer. This simplifies development
and memory requirements. Resource representations are also visible
in an end-to-end manner for any CoAP client. In certain conditions,
the processing and computational overhead for conveying CoAP Requests
and Responses from one underlying transport to another, would be less
than that of an application-level gateway performing protocol
translation of individual messages between CoAP and another resource
retrieval protocol such as HTTP.
This document first provides scenarios where usage of CoAP over CoAP uses a REST-based model similar to HTTP, where URIs are used to
alternative transports is either currently underway, or may prove identify resources at servers. An important factor of allowing CoAP
advantageous in the future. A simple transport type classification communication over alternative transports, is to express not only the
for CoAP-capable nodes is provided next. Then a new URI format is resource identifier, but also the alternative transport information
described through which a CoAP resource representation can be in the URI.
formulated that expresses transport identification in addition to
endpoint information and resource paths. Following that, a
discussion of the various transport properties which influence how
CoAP Request and Response messages are mapped to transport level
payloads, is presented.
This document however, does not touch on application QoS CoAP URIs contain information, such as the endpoint address as well
requirements, user policies or network adaptation, nor does it as the location of the resource hosted at the endpoint. CoAP URIs
advocate replacing the current practice of UDP-based CoAP beginning with "coap://" are using UDP, while those beginning with
communication. "coaps://" are using DTLS.
2. Usage Cases coap :// server.example.org /sensors/temperature
\___/ \______ ________/ \______ _________/
| \/ \/
URI scheme URI authority URI path
Apart from UDP and DTLS, CoAP usage is being specified for the Figure 1: A CoAP URI
following environments as of this writing:
2.1. Use of SMS Figure 1 shows the structure of a simple example CoAP URI, in which
the various URI components can beinterpreted as follows:
CoAP messages can be sent via SMS between CoAP end-points in a o The URI scheme component (e.g. "coap") contains an application-
cellular network [I-D.becker-core-coap-sms-gprs]. A CoAP Request level identifier which typically identifies the protocol being
message can also be sent via SMS from a CoAP client to a sleeping used as well as its transport and network level protocol
CoAP Server as a wake-up mechanism and trigger communication via IP. configurations. Such configurations are defined by convention or
For this reason, the Open Mobile Alliance (OMA) specifies both UDP standardisation of the protocol using the scheme.
and SMS as transports for M2M communication in cellular networks.
The OMA Lightweight M2M (LWM2M) protocol being drafted uses CoAP, and
as transports, specifies both UDP as well as Short Message Service
(SMS) bindings [OMALWM2M]. DTLS is being proposed for securing CoAP
messages over SMS between Mobile Stations
[I-D.fossati-dtls-over-gsm-sms].
2.2. Use of WebSockets o The URI authority component ("server.example.com") contains the
endpoint identification, which is typically a fully qualified
domain name or a network-level host address.
The WebSocket protocol has been proposed as a transport channel o The URI path component ("/sensors/temperature") contains a
between WebSocket enabled CoAP end-points on the Internet parameterised resource identifier providing the location and
[I-D.savolainen-core-coap-websockets]. This is particularly useful identity of the resource at the endpoint.
to enable CoAP communication within HTML5 apps and web browsers,
especially in smart devices, that do not have any means to use low-
level socket interfaces. Embedded client side scripts create new
WebSocket connections to various WebSocket-enabled servers, through
which CoAP messages can be exchanged. This also allows a browser
containing an embedded CoAP server to open a connection to a
WebSocket enabled CoAP Mirror Server [I-D.vial-core-mirror-server] to
register and update its resources.
2.3. Use of P2P Overlays In addition to these URI components, Figure 2 shows how specific
queries on resource representations are provided by CoAP clients to
servers, by specifying one or more URI query components in the URI.
[I-D.jimenez-p2psip-coap-reload] specifices how CoAP nodes can use a coap :// server.example.org /sensors/temperature ?u=cel
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 URI query
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 and TLS Figure 2: A CoAP URI with query
Using TCP [I-D.ietf-core-coap-tcp-tls], allows easier communication This document focuses on how CoAP URIs can be extended to contain
between CoAP clients and servers separated by firewalls and NATs. information about alternative transports. For deriving the new URI
This also allows CoAP messages to be transported over push format, the main design considerations are presented in the next
notification services from a notification server to a client app on a section. Following that, various potential URIs are presented.
smartphone, that may previously have subscribed to receive change These URIs provide examples of how transport identifiers can be
notifications of CoAP resource representations, possibly by using situated in the URI scheme, authority, path or query components. The
CoAP Observe [RFC7641]. [I-D.ietf-core-coap-tcp-tls] also discusses proposed URIs are analysed to select feasible formats while
using TLS as a transport to securely convey CoAP messages over TCP. disqualifying those not meeting the design criteria.
3. Node Types based on Transport Availability 2. Conformance and Design Considerations
The term "alternative transport" in this document thus far has been In order to understand which URI formats are best suited for
used to refer to any non-UDP and non-DTLS transport that can convey expressing transport information, certain considerations firstly need
CoAP messages in its payload. A node however, may in fact possess to be taken into account. Doing so eliminates URI formats that do
the capability to utilise CoAP over multiple transport channels at not meet or conform to the stated requirements. The main criteria
its disposal, simultaneously or otherwise, at any point in time to are:
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 two networks so
that CoAP Requests and Responses can be exchanged properly.
In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for 1. Conformance to the generic syntax for a URI described in
devices, in terms of their resource constraints, energy limitations [RFC3986]. A URI format needs to be described in which each URI
and communication power. For this document, in addition to these component clearly meets the syntax and percent-encoding rules
capabilities, it seems useful to additionally identify devices based described.
on their transport capabilities.
+-------+----------------------------+ 2. Alignment with best practices for URI design, as described in
| Name | Transport Availability | [RFC7320]. This is particularly important when it pertains to
+-------+----------------------------+ establishing or standardising the structure and usage of URIs
| T0 | Single transport | with respect to the various URI components.
| | |
| T1 | Multiple transports, with |
| | one or more active at any |
| | point in time |
| | |
| T2 | Multiple active transports|
| | at all times |
+-------+----------------------------+
Table 1: Classes of Available Transports 3. Request messages sent to a CoAP endpoint using a CoAP Transport
URI may be responded to with a relative URI reference. [RFC3986]
provides an algorithm to establish how relative references can be
resolved against a base URI to obtain a target URI. Given this
algorithm, a URI format needs to be described in which relative
reference resolution does not result in a target URI that loses
its transport-specific information
Type T0 nodespossess the capability of exactly 1 type of transport 4. The URI can be supplied as a Proxy-Uri option by a CoAP end-point
channel for CoAP, at all times. These include both active and sleepy to a CoAP forward proxy. This allows communication with a CoAP
nodes, which may choose to perform duty cycling for power saving. end-point residing in a network using a different transport.
Section 6.4 of [RFC7252] provides an algorithm for parsing a
received URI to obtain the request's options. Conformance to
Type T1 nodes possess multiple different transports, and can retrieve [RFC3986] is also necessary in order for the parsing algorithm to
or expose CoAP resources over any or all of these transports. be successful.
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 when using CoAP over SMS (refer to
section 2.1)
Type T2 nodes possess more than 1 transport, and multiple transports In addition to the above mentioned requirements, where possible, the
are simultaneously active at all times. CoAP proxy nodes which allow following considerations need to be borne in mind:
CoAP endpoints from disparate transports to communicate with each
other, are a good example of this.
4. CoAP Alternative Transport URI 1. The URI format is able to represent a resource and the transport
information for use in constrained environments, without
requiring the presence of a naming infrastructure, such as DNS or
a directory/lookup service.
Based on the usage scenarios as well as the transport classes 2. Alternative transport information can be easily retrieved by
presented in the preceding sections, this section discusses the computationally constrained nodes. In other words, the URI
formulation of a new URI format for representing CoAP resources over format does not result in unneccessarily complex code or logic in
alternative transports. such nodes to parse and extract the transport to be used, nor the
endpoint address.
CoAP is logically divided into 2 sublayers, whereby the upper layer 3. URIs are designed to uniquely identify resources. When a single
is responsible for the protocol functionality of exchanging request resource is represented with multiple URIs, URI aliasing
and response messages, while the messaging layer is bound to UDP. [WWWArchv1] occurs. Avoiding URI aliasing is considered good
These 2 sublayers are tightly coupled, both being responsible for practice.
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 ] 4. CoAP URIs do not support fragment identifiers.
a simple example CoAP URI, "coap://server.example.com/sensors/ 3. Situating Transport Information in CoAP URIs
temperature" is interpreted as follows:
coap :// server.example.com /sensors/temperature The following subsections aim to describe potential URI formats in
\___/ \______ ________/ \______ _________/ which the alternative transport information is placed in various URI
| \/ \/ components.
protocol endpoint parameterised
identifier identifier resource
identifier
Figure 1: The CoAP URI format 3.1. Using the URI scheme component
The resource path is explicitly expressed, and the endpoint Expressing the transport information in the URI scheme component can
identifier, which contains the host address at the network-level is be achieved by using new schemes. These can conform to an agreed-
also directly bound to the scheme name containing the application- upon convention such as "coap+alternative_transport_name" for each
level protocol identifier. The choice of a specific transport for a new alternative transport and/or "coaps+alternative_transport_name"
scheme, however, cannot be embedded with a URI, but is defined by for its secure counterpart.
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
TCP.
4.1. Design Considerations Examples of such URIs are:
Several ways of formulating a URI which express an alternative o coap+tcp://server.example.org/sensors/temperature for using CoAP
transport binding to CoAP, can be envisioned. When such a URI is over TCP
provided from an application to its CoAP implementation, the URI
component containing transport-specific information can be checked to
allow CoAP to use the appropriate transport for a target endpoint
identifier.
The following design considerations influence the formulation of a o coap+sms://0015105550101/sensors/temperature for using CoAP over
new URI expressing CoAP resources over alternative transports: SMS with the endpoint identifier being a telephone subscriber
number
1. The CoAP Transport URI must conform to the generic syntax for a o coaps+tcp://server.example.org/sensors/temperature for using CoAP
URI described in [RFC3986]. By ensuring conformance to RFC3986, over TLS
the need for custom URI parsers as well as resolution algorithms
can be obviated. In particular, a URI format needs to be
described in which each URI component clearly meets the syntax
and percent-encoding rules described.
2. A CoAP Transport URI can be supplied as a Proxy-Uri option by a 3.1.1. Analysis
CoAP end-point to a CoAP forward proxy. This allows
communication with a CoAP end-point residing in a network using a
different transport. Section 6.4 of [RFC7252] provides an
algorithm for parsing a received URI to obtain the request's
options. Conformance to [RFC3986] is also necessary in order for
the parsing algorithm to be successful.
3. Request messages sent to a CoAP endpoint using a CoAP Transport Expressing transport information in the URI scheme delivers a URI
URI may be responded to with a relative URI reference, for which is human-readable and computationally as easy to parse as
example, of the form "../../path/to/resource". In such cases, standard CoAP URIs, to extract transport identification information.
the requesting endpoint needs to resolve the relative reference The URI syntax conforms to [RFC3986], and relative URI resolution
against the original CoAP Transport URI to then obtain a new does not result in the loss of transport identification information.
target URI to which a request can be sent to, to obtain a However, each new alternative transport requires minting new schemes,
resource representation. [RFC3986] provides an algorithm to and IANA intervention is required for the registration of each scheme
establish how relative references can be resolved against a base name. The registration process follows the guidelines stipulated in
URI to obtain a target URI. Given this algorithm, a URI format [RFC7595]. Additionally, should a CoAP server wish to expose its
needs to be described in which relative reference resolution does resources over multiple transports (such as both UDP and TCP) , URI
not result in a target URI that loses its transport-specific aliasing can occur if the URI scheme components of these multiple
information URIs differ in describing the same resource.
4. The host component of current CoAP URIs can either be an IPv4 3.2. Using the URI authority component
address, an IPv6 address or a resolvable hostname. 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.
Therefore, a URI format needs to be described which is able to
represent a resource without heavy reliance on a naming
infrastructure, such as DNS.
4.2. URI format Expressing the transport information within the authority component
can result in two possible URI formats.
To meet the design considerations previously discussed, the transport The first approach is to structure the URI authority's host sub-
information is expressed as part of the URI scheme component. This component with a transport prefix to the endpoint identifier and a
is performed by minting new schemes for alternative transports using delimiter, such as "<transport-name>-endpoint_identifier".
the form "coap+<transport-name>" and/or "coaps+<transport-name>",
where the name of the transport is clearly and unambiguously
described. Each scheme name formed in this manner is used to
differentiate the use of CoAP, or CoAP using DTLS, over an
alternative transport respectively. 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: Examples of resulting URIs are:
o coap+tcp://[2001:db8::1]:5683/sensors/temperature for using CoAP o coap://tcp-server.example.org/sensors/temperature for using CoAP
over TCP over TCP
o coap+tls://[2001:db8::1]:5683/sensors/temperature for using CoAP o coap://sms-0015105550101/sensors/temperature for using CoAP over
over TLS SMS
o coaps+sctp://[2001:db8::1]:5683/sensors/temperature for using CoAP
over DTLS over SCTP
o coap+sms://0015105550101/sensors/temperature for using CoAP over
SMS with the endpoint identifier being a telephone subscriber
number
o coaps+sms://0015105550101/sensors/temperature for using CoAP over
DTLS over SMS with the endpoint identifier being a telephone
subscriber number
o coap+ws://www.example.com/sensors/temperature for using CoAP over The second approach is to hint at the alternative transport
WebSockets information, by explicitly specifying using the URI authority's port
sub-component, thereby differentiating them from standard CoAP URIs.
o coap+wss://www.example.com/sensors/temperature for using CoAP over Examples of resulting URIs are:
secure WebSockets (WebSockets using TLS)
A URI of this format to distinguish transport types is simple to o coap://server.example.org:5684/sensors/temperature for using CoAP
understand and not dissimilar to the CoAP URI format. As the usage over TLS
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 the guidelines stipulated in
[I-D.ietf-appsawg-uri-scheme-reg], particularly where permanent URI
scheme registration is concerned. CoAP resources transported over
UDP or DTLS must conform to Section 6 of [RFC7252] and utilise "coap"
or "coaps" for the URI scheme, instead of "coap+udp" or "coap+dtls".
It is also entirely possible for each new scheme to specify its own o coap://server.example.org:80/sensors/temperature for using CoAP
rules for how resource and transport endpoint information can be over WebSockets
presented. However, the URIs and resource representations arising
from their usage should meet the URI design considerations and
guidelines mentioned in Section 4.1. In addition, each new transport
being defined should take into consideration the various transport-
level properties that can have an impact on how CoAP messages are
conveyed as payload. This is elaborated on in the next section.
5. Alternative Transport Analysis and Properties 3.2.1. Analysis
In this section the various characteristics of alternative transports Embedding the transport information in the host would violate the
for successfully supporting various kinds of functionality for CoAP guidelines for the structure of URI authorities in section 2.2 of
are considered. CoAP factors lossiness, unreliability, small packet [RFC7320]. Consequently, the host in a URI authority component
sizes and connection statelessness into its protocol logic. General cannot be used as a basis for a new CoAP URI for alternative
transport differences and their impact on carrying CoAP messages here transports.
are discussed.
Property 1: 1:N communication support. Embedding the transport information in the port, on the other hand,
would not violate the guidelines for the structure of URI authorities
in section 2.2 of [RFC7320]. It would result in a CoAP URI that is
less human-readable, but URI aliasing is minimised.
This refers to the ability of the transport protocol to support On the other hand, if a CoAP request message using a CoAP Transport
broadcast and multicast communication. For example, group URI of this form elicits a CoAP Response containing a relative URI,
communication for CoAP is based on multicasting Request messages and for example, of the form "//server2.example.org/path/to/another/
receiving Response messages via unicast [RFC7390]. A protocol such resource", relative URI resolution rules of [RFC3986] would result in
as TCP would be ill-suited for group communications using multicast. the loss of transport identification information. Consequently,
Anycast support, where a message is sent to a well defined using the URI authority component cannot be used as a basis for a new
destination address to which several nodes belong, on the other hand, CoAP URI for alternative transports.
is supported by TCP.
Property 2: Transport-level reliability. 3.3. Using the URI path component
This refers to the ability of the transport protocol to support Should the URI path component be used, then special characters or
properties such as guaranteeing reliability against packet loss, keywords need to be supplied in the path to make the transport
ensuring ordered packet delivery and having error control. When CoAP explicit. Here, many proposals can exist. In general however, this
Request and Response messages are delivered over such transports, the will result in a URI format such as:
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 3: Message encoding. o coap://server.example.org/sensors/temperature;tcp for using CoAP
over TCP, by appending the transport information at the end of the
URI.
While parts of the CoAP payload are human readable or are transmitted 3.3.1. Analysis
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.
Techniques exist in allowing binary payloads to be transferred over
text-based transport protocols such as base-64 encoding. When using
SMS as a transport, for example, although binary encoding is
supported, Appendix A.5 of [I-D.bormann-coap-misc] indicates binary
encoding for SMS may not always be viable. A fuller discussion about
performing CoAP message encoding for SMS can be found in Appendix A.5
of [I-D.bormann-coap-misc]
Property 4: Network byte order. Embedding the transport information in the URI path directly results
in a URI that is human-readable. However, if a CoAP request message
using a CoAP Transport URI of this form elicits a CoAP Response
containing a relative URI, for example, of the form
"../../path/to/another/resource", relative URI resolution rules of
[RFC3986] would result in the loss of transport identification
information. Consequently, using the URI path component cannot be
used as a basis for a new CoAP URI for alternative transports.
CoAP, as well as transports based on the IP stack use a Big Endian 3.4. Using the URI query component
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 5: MTU correlation with CoAP PDU size. The alternative transport information, should URI query components be
used, would result in a URI format such as:
Section 4.6 of [RFC7252] discusses the avoidance of IP fragmentation o coap://server.example.org/sensors/temperature?alternative-
by ensuring CoAP message fit into a single UDP datagram. End-points transport=wss for using CoAP over secure WebSockets.
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 [RFC7668]. 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 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 6: Framing 3.4.1. Analysis
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 7: Transport latency. Embedding the transport information in a URI query also results in a
URI that is human-readable. However, if a CoAP request message using
a CoAP Transport URI of this form elicits a CoAP Response containing
a relative URI, for example, of the form "../../path/to/another/
resource", relative URI resolution rules of [RFC3986] would result in
the loss of transport identification information. Consequently,
using the URI query component cannot be used as a basis for a new
CoAP URI for alternative transports.
A confirmable CoAP request would be retransmitted by a CoAP end-point 4. Discussion
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 messages is small enough not to
interfere with these values for the proper operation of these
functionalities.
Property 8: Connection Management. Based on the analysis of the various options for embedding
alternative transport information in a CoAP URI, the most technically
feasible option is to use the URI scheme component, as described in
Section 3.1. To date, this has also been the WG consensus.
A CoAP endpoint using a connection-oriented transport should be A discussion with IESG members during review of
responsible for proper connection establishment prior to sending a [I-D.ietf-core-coap-tcp-tls] revealed however, that using the URI
CoAP Request message. Both communicating endpoints may monitor the scheme to express transport information is not desirable, to avoid
connection health during the Data Transfer phase. Finally, once data the proliferation of new URI schemes for the same application-layer
transfer is complete, at least one end point should perform protocol. A strategy was instead proposed to preserve the existing
connection teardown gracefully. CoAP URI and reuse it for alternative transports, by employing a
combination of UDP Confirmable messages and timeouts to determine the
eventual correct transport to use between a client and server
[IESG-feedback]. The undertaken strategy would have obvious
implications regarding interoperability, application and protocol
logic, resource usage, for both new CoAP and existing CoAP
implementations and deployments. Although URI aliasing can
theoretically be avoided with this approach, at the time of writing,
its technical feasibility over using the simpler strategy of using
URI schemes, has yet to be validated. An obvious drawback is
therefore that implementers and other SDOs may choose to
provisionally or permanently register new URI schemes with IANA, for
CoAP over alternative transports anyway, as was done by the Open
Connectivity Foundation (OCF) [CoAP-TCP-TLS-registration].
6. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 6. Security Considerations
New security risks are not envisaged to arise from the guidelines New security risks are not envisaged to arise from the guidelines
given in this document, for describing a new URI format containing given in this document, for describing a new URI format containing
transport identification within the URI scheme component. However, transport identification within the URI scheme component. However,
when specific alternative transports are selected for implementing when specific alternative transports are selected for implementing
support for carrying CoAP messages, risk factors or vulnerabilities support for carrying CoAP messages, risk factors or vulnerabilities
can be present. Examples include privacy trade-offs when MAC can be present. Examples include privacy trade-offs when MAC
addresses or phone numbers are supplied as URI authority components, addresses or phone numbers are supplied as URI authority components,
or if specific URI path components employed for security-specific or if specific URI path components employed for security-specific
interpretations are accidentally encountered as false positives. interpretations are accidentally encountered as false positives.
While this document does not make it mandatory to introduce a While this document does not make it mandatory to introduce a
security mode with each transport, it recommends ascribing meaning to security mode with each transport, it recommends ascribing meaning to
the use of "coap+" and "coaps+" prefixes in the scheme component, the use of "coap+" and "coaps+" prefixes in the scheme component,
with the "coaps+" prefix used for DTLS-based CoAP messages over the with the "coaps+" prefix used for secure transports for CoAP
alternative transport. messages.
8. Acknowledgements
The draft has benefited greatly from reviews, comments and ideas from 7. Acknowledgements
Thomas Fossati, Akbar Rahman, Klaus Hartke, Martin Thomson, Mark
Nottingham, Dave Thaler, Graham Klyne, Carsten Bormann and Markus
Becker.
9. References Email discussions, comments and ideas from Thomas Fossati, Akbar
Rahman, Klaus Hartke, Martin Thomson, Mark Nottingham, Dave Thaler,
Graham Klyne, Carsten Bormann and Markus Becker greatly helped
previous versions of this draft.
9.1. Normative References 8. References
[I-D.ietf-appsawg-uri-scheme-reg] 8.1. Normative References
Thaler, D., Hansen, T., Hardie, T., and L. Masinter,
"Guidelines and Registration Procedures for URI Schemes",
draft-ietf-appsawg-uri-scheme-reg-06 (work in progress),
April 2015.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <http://www.rfc-editor.org/info/rfc7252>.
9.2. Informative References [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 7320, DOI 10.17487/RFC7320, July 2014,
[BTCorev4.1] <http://www.rfc-editor.org/info/rfc7320>.
BLUETOOTH Special Interest Group, "BLUETOOTH Specification
Version 4.1", December 2013.
[I-D.becker-core-coap-sms-gprs]
Becker, M., Li, K., Kuladinithi, K., and T. Poetsch,
"Transport of CoAP over SMS", draft-becker-core-coap-sms-
gprs-05 (work in progress), August 2014.
[I-D.bormann-coap-misc] 8.2. Informative References
Bormann, C. and K. Hartke, "Miscellaneous additions to
CoAP", draft-bormann-coap-misc-27 (work in progress),
November 2014.
[I-D.fossati-dtls-over-gsm-sms] [CoAP-TCP-TLS-registration]
Fossati, T. and H. Tschofenig, "Datagram Transport Layer https://www.iana.org/assignments/uri-schemes/prov/coap+tcp
Security (DTLS) over Global System for Mobile , https://www.iana.org/assignments/uri-schemes/prov/
Communications (GSM) Short Message Service (SMS)", draft- coaps+tcp, , June 2017.
fossati-dtls-over-gsm-sms-01 (work in progress), October
2014.
[I-D.ietf-core-coap-tcp-tls] [I-D.ietf-core-coap-tcp-tls]
Bormann, C., Lemay, S., Technologies, Z., and H. Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Tschofenig, "A TCP and TLS Transport for the Constrained Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-tcp- Application Protocol) over TCP, TLS, and WebSockets",
tls-01 (work in progress), November 2015. draft-ietf-core-coap-tcp-tls-09 (work in progress), May
2017.
[I-D.jimenez-p2psip-coap-reload]
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-10 (work in progress),
July 2015.
[I-D.savolainen-core-coap-websockets]
Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over
WebSockets", draft-savolainen-core-coap-websockets-05
(work in progress), October 2015.
[I-D.vial-core-mirror-server]
Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
server-01 (work in progress), April 2013.
[OMALWM2M]
Open Mobile Alliance (OMA), "Lightweight Machine to
Machine Technical Specification Version 1.0", 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [IESG-feedback]
Requirement Levels", BCP 14, RFC 2119, https://www.ietf.org/mail-archive/web/core/current/
DOI 10.17487/RFC2119, March 1997, msg08768.html, , May 2017.
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates
and Service: Schemes", RFC 2609, DOI 10.17487/RFC2609, and Service: Schemes", RFC 2609, DOI 10.17487/RFC2609,
June 1999, <http://www.rfc-editor.org/info/rfc2609>. June 1999, <http://www.rfc-editor.org/info/rfc2609>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
DOI 10.17487/RFC2818, May 2000, and Registration Procedures for URI Schemes", BCP 35,
<http://www.rfc-editor.org/info/rfc2818>. RFC 7595, DOI 10.17487/RFC7595, June 2015,
<http://www.rfc-editor.org/info/rfc7595>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <http://www.rfc-editor.org/info/rfc4838>.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <http://www.rfc-editor.org/info/rfc5050>.
[RFC5092] Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme",
RFC 5092, DOI 10.17487/RFC5092, November 2007,
<http://www.rfc-editor.org/info/rfc5092>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011,
<http://www.rfc-editor.org/info/rfc6455>.
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
Application Spaces for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)", RFC 6568,
DOI 10.17487/RFC6568, April 2012,
<http://www.rfc-editor.org/info/rfc6568>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014,
<http://www.rfc-editor.org/info/rfc7390>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<http://www.rfc-editor.org/info/rfc7641>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>.
[WWWArchv1] [WWWArchv1]
http://www.w3.org/TR/webarch/#uri-aliases, "Architecture http://www.w3.org/TR/webarch/#uri-aliases, "Architecture
of the World Wide Web, Volume One", December 2004. of the World Wide Web, Volume One", December 2004.
Appendix A. Expressing transport in the URI in other ways Appendix A. Expressing transport in the URI in other ways
Other means of indicating the transport as a distinguishable Other means of indicating the transport as a distinguishable
component within the CoAP URI are possible, but have been deemed component within the CoAP URI are possible, but have been deemed
unsuitable by not meeting the design considerations listed, or are unsuitable by not meeting the design considerations listed, or are
skipping to change at page 17, line 16 skipping to change at page 12, line 37
multiple transports could be rendered possible by prefixing the multiple transports could be rendered possible by prefixing the
transport type and endpoint identifier information to the CoAP URI. transport type and endpoint identifier information to the CoAP URI.
This would result in the following example representation: This would result in the following example representation:
coap-at:tcp://example.com?coap://example.com/sensors/temperature coap-at:tcp://example.com?coap://example.com/sensors/temperature
\_______ ______/ \________________ __________________/ \_______ ______/ \________________ __________________/
\/ \/ \/ \/
Transport-specific CoAP Resource Transport-specific CoAP Resource
Prefix Prefix
Figure 2: Prefixing a CoAP URI with TCP transport Figure 3: Prefixing a CoAP URI with TCP transport
Such a representation would result in the URI being decomposed into Such a representation would result in the URI being decomposed into
its constituent components, with the CoAP resource residing within its constituent components, with the CoAP resource residing within
the query component as follows: the query component as follows:
Scheme: coap-at Scheme: coap-at
Path: tcp://example.com Path: tcp://example.com
Query: coap://example.com/sensors/temperature Query: coap://example.com/sensors/temperature
The same CoAP resource, if requested over a WebSocket transport, The same CoAP resource, if requested over a WebSocket transport,
would result the following URI: would result the following URI:
coap-at:ws://example.com/endpoint?coap://example.com/sensors/temperature coap-at:ws://example.com/endpoint?coap://example.com/sensors/temperature
\___________ __________/ \_______________ ___________________/ \___________ __________/ \_______________ ___________________/
\/ \/ \/ \/
Transport-specific CoAP Resource Transport-specific CoAP Resource
Prefix Prefix
Figure 3: Prefixing a CoAP URI with WebSocket transport Figure 4: Prefixing a CoAP URI with WebSocket transport
While the transport prefix changes, the CoAP resource representation While the transport prefix changes, the CoAP resource representation
remains the same in the query component: remains the same in the query component:
Scheme: coap-at Scheme: coap-at
Path: ws://example.com/endpoint Path: ws://example.com/endpoint
Query: coap://example.com/sensors/temperature Query: coap://example.com/sensors/temperature
The URI format described here overcomes URI aliasing [WWWArchv1] when The URI format described here overcomes URI aliasing [WWWArchv1] when
multiple transports are used, by ensuring each CoAP resource multiple transports are used, by ensuring each CoAP resource
representation remains the same, but is prefixed with different representation remains the same, but is prefixed with different
transports. However, against a base URI of this format, resolving transports. However, against a base URI of this format, resolving
relative references of the form "//example.net/sensors/temperature" relative references of the form "//example.net/sensors/temperature"
and "/sensor2/temperature" would again result in target URIs which and "/sensor2/temperature" would again result in target URIs which
lose transport-specific information. lose transport-specific information.
Implementation note: While square brackets are disallowed within the Implementation note: While square brackets are disallowed within the
path component, the '[' and ']' characters needed to enclose a path component, the '[' and ']' characters needed to enclose a
literal IPv6 address can be percent-encoded into their respective literal IPv6 address can be percent-encoded into their respective
equivalents. The ':' character does not need to be percent-encoded. equivalents. The ':' character does not need to be percent-encoded.
This results in a significantly simpler URI string compared to This results in a significantly simpler URI string compared to
section 2.2, particularly for compressed IPv6 addresses. section 2.2, particularly for compressed IPv6 addresses.
Additionally, the URI format can be used to specify other similar Additionally, the URI format can be used to specify other similar
address families and formats, such as Bluetooth addresses address families and formats, such as Bluetooth addresses.
[BTCorev4.1].
A.3. Transport as part of a 'service:' URL scheme A.3. Transport as part of a 'service:' URL scheme
The "service:" URL scheme name was introduced in [RFC2609] and forms The "service:" URL scheme name was introduced in [RFC2609] and forms
the basis of service description used primarily by the Service the basis of service description used primarily by the Service
Location Protocol. An abstract service type URI would have the form Location Protocol. An abstract service type URI would have the form
"service:<abstract-type>:<concrete-type>" "service:<abstract-type>:<concrete-type>"
where <abstract-type> refers to a service type name that can be where <abstract-type> refers to a service type name that can be
associated with a variety of protocols, while the <concrete-type> associated with a variety of protocols, while the <concrete-type>
then providing the specific details of the protocol used, authority then providing the specific details of the protocol used, authority
and other URI components. and other URI components.
Adopting the "service:" URL scheme to describe CoAP usage over Adopting the "service:" URL scheme to describe CoAP usage over
alternative transports would be rather trivial. To use a previous alternative transports would be rather trivial. To use a previous
example, a CoAP service to discover a Resource Directory and its base example, a CoAP service to discover a Resource Directory and its base
skipping to change at page 19, line 16 skipping to change at page 14, line 33
Bilhanan Silverajan Bilhanan Silverajan
Tampere University of Technology Tampere University of Technology
Korkeakoulunkatu 10 Korkeakoulunkatu 10
FI-33720 Tampere FI-33720 Tampere
Finland Finland
Email: bilhanan.silverajan@tut.fi Email: bilhanan.silverajan@tut.fi
Teemu Savolainen Teemu Savolainen
Nokia Nokia Technologies
Hermiankatu 12 D Hatanpaeaen valtatie 30
FI-33720 Tampere FI-33100 Tampere
Finland Finland
Email: teemu.savolainen@nokia.com Email: teemu.savolainen@nokia.com
 End of changes. 89 change blocks. 
508 lines changed or deleted 294 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/