]>

Austria christian@amsuess.com

CoRE CoAP, NTP The Constrained Application Protocol (CoAP) has become the base of applications both inside of the constrained devices space it originally aimed for and outside. This document gives an overview of applications that are, can, may, and would better not be implemented on top of CoAP. Discussion Venues Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction [ See abstract for now ]

Applications

Publish-Subscribe services Publish-subscribe services (pubsub) are a widespread tool for the some of the fundamental use cases of Internet of Things (IoT) protocols: acquiring sensor data and controlling actuators. A pubsub implementation has been in development since shorlty after the original CoAP publication and is as of now still in draft status, as .

Competing with

MQTT

Strong points

Once a topic is set up, data can be sent and received by CoAP clients that are not even aware of pubsub, as long as they can PUT or GET (possibly with observation) data to and from configured URIs.

Weak points

To implement a pubsub broker that supports arbitrarily many topics, some (potentially difficult-to-implement) compromises have to be made.

Remote configuration The OMA LwM2M protocol (which caters for several applications at the granularity of this document) includes provisions for configuring and monitoring devices over the network, setting properties such as a time server and reading properties such as a network interface's packet count. In parallel, the NETCONF protocol and its YANG modelling language have been ported to the constrained ecosystem as CORECONF . By using numeric identifiers with good compression properties, it can efficiently express data both from shared and from bespoke models in single requests.

Competing with

SNMP [ ? ], Puppet [ ? ]

Network status monitoring Related to remote configuration, CoAP is used as the signalling channel of DOTS ().

Strong points

CoAP over UDP/DTLS provides operational signalling on links under attack, on which a TCP/TLS based connection would fail.

CoAP's consistency across transports makes it easy to adjust to situations in which UDP is uanvailable, sacrificing some properties but leaving the high-level protocol unmodified.

Weak points

CoAP's default parameters for flow control (such as PROBING_RATE) are unsuitable for this application and need to be customized.

Runtime configuration Related to remote network configuration, but used without human intervention, CoAP is used negotiate cryptographic keys and other short-lived network configuration, eg. in , , and . This is comparable to how or exchanges configuration.

Strong points

When the exchanged communication is essential to joining the network in the first place, CoAP traffic exchanged over a temporary link can easily be proxied into the actual network, even when routing is not an option yet.

Software updates The SUIT manifest format can be used to describe firmware updates that can be performed over CoAP or any other protocol that is expressible in terms of URIs. The OMA LwM2M protocol also contains provisions for firmware updates over CoAP.

Network file system Using CoAP as a backend for a no-frills file service is a simple composition and is provided as a demo by the aiocoap library and a module in the RIOT operating system. It has never been specified and described; that gap is closed in .

Competing with

WebDAV, NFS, FTP

Strong points

CoAP protocol already provides random read access (through the Block2 option), optimistic locking and cache (through the ETag and If-Match options) and change notification (through the Observe option).

Files can be used in other CoAP protocols without the client's awareness (e.g. for SUIT)

Weak points

Transfer of large files is inefficient due to the repetition of file names in block-wise requests (mitigated when using CoAP-over-TCP and BERT).

Advanced file system functionality (file metadata, server-to-server copies, renaming, locking) would need additional specifications.

Network address resolution The Domain Name System (DNS) can be utilized from CoAP using the mechanisms described in .

Strong points

Savings in firmware complexity by using infrastructure shared with other applications.

Potential for traffic (and thus energy) reduction by using request-response binding.

Weak points

Not deployed in existing networks.

Time service Whereas no attempt has been made yet to specify a time service over CoAP, a primitive time service can be assembled by creating a CoAP resource that returns the server's current time, e.g., in a UNIX time stamp represented in decimal ASCII, or in CBOR using any of timestamp tags (0, 1 or 1001). TBD reference https://datatracker.ietf.org/doc/html/draft-navas-ace-secure-time-synchronization-00 Such services have been in use since at least 2013, and are easy to operate and scale.

Competing with

SNTP, NTP

Strong points

Savings in firmware complexity by using infrastructure shared with other applications.

Compact messages.

Reuse of existing security associations.

Weak points

None of the advanced features of (S)NTP, such as distinction between receive and transmit timestamps. Not even leap seconds are advertised (but that can be mitigated by using a time scale that is not affected by them, such as TAI).

Generally only suitable for the last hop in time synchronization.

Terminal access Virtual terminal access was one of the first network applications described in an RFC (), and popular to date. There is no full specification yet as to how to express the data streams of character based user input and character based text responses in CoAP. Necessary components, as well as optional future extensions, have been sketched and implemented for the RIOT operating system at https://forum.riot-os.org/t/coap-remote-shell/3340/5. Unlike SSH, that sketch assumes the presence of a single virtual terminal (as opposed to one created per connection). On platforms with dynamic resources and per-process output capture, an SSH-like muliplexing can be created based on the resource collection pattern described in .

Competing with

SSH

Strong points

The head-of-line blocking that occasionally plagues TCP based connections is eliminiated in favor of on-demand recovery (i.e., observing the last output will produce the latest chunk of output, and the terminal may recover skipped data later if it is still in the device's back-scroll buffer).

Weak points

The default retransmission characteristics of CoAP make operations painfully slow when encountering packet loss. Tuning of parameters or the implementation of advanced flow control as described in are necessary for smooth operation.

On-demand recovery is incompatible with regular terminals, and requires either fully managed terminals (where the full output is reprinted when lost fragments are recovered) or accepting the loss of data where printed exceeding the network speed. (Data is still lost gracefully, as the loss is detected and can be indicated visually).

Chat services The CoMatrix project https://comatrix.eu/ has demonstrated that the Matrix chat protocol can be simplified to the point where it becomes usable transparently with constrained devices.

Web browsing

Competing with

HTTP over its various transports; Gemini ().

By virtue of cross proxying to HTTP, CoAP is generally capable of transporting web pages the same way as HTTP, albeit at a reduced feature set (in particular, most HTTP headers). CoAP offers only niche benefits over HTTP when combined with HTML, the predominant markup language on the web: Any benefits of a more compact transport or implementation are dwarved by the typical size of pages and the complexity of the HTML ecosystem. CoAP might be a suitable transport for Small Web environments such as Gemini , which can be rendered even by constrained devices.

E-Mail While E-Mail was part of the considerations that led to the definition of the Proxy-Uri option (which would technically allow a cross-proxy to accept POST requests to, say, mailto:office@example.com?subject=Sensor%20failure), no attempts are known to send or receive E-Mail over CoAP.

Video streaming The use of CoAP for real time video streaming and telemetry from Unmanned Aerial Vehicles (UAVs) has been explored in . It is unclear whether CoAP could actually outperform unconstrained streaming protocols such as WebRTC, or whether devices that produce and consume video benefit from the constraints of CoAP.

Tunneling Unlike HTTP, CoAP does neither provide a dedicated method for encapsulating streaming or packet based network connections (HTTP has a CONNECT method for streaming, ) nor has a means of encapsulating network traffic been specified (HTTP has BOSH for streaming connections; VPNs such as OpenVPN can be operated over HTTP proxies ). Early versions (up to -10) of sketched a means of transporting UDP in a CoAP-like way. However, CoAP can aggregate exchanges with multiple peers inside a single CoAP hop. This can serve to protect the user's privacy (by using (D)TLS or on the hop to the proxy, hiding which servers a client is communicating with from its local network) and for efficiency reasons (by using a single outgoing TCP connection from a device in a cellular network, or even a more power optimized hop such as to keep observations active on multiple unrelated services). This bears similarity with the approach of , but leverages CoAP's proxying mechanisms instead of using a gateway or relay resource. various stuff from JJ

References Normative References The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. Informative References This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. RISE AB Universitaet Duisburg-Essen Ericsson AB This document defines an application profile of the ACE framework for Authentication and Authorization, to request and provision keying material in group communication scenarios that are based on CoAP and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, that join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 Access Token. This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. n.d. n.d. n.d. Unaffiliated Ericsson Ericsson This document describes a publish-subscribe architecture for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. The Constrained Application Protocol (CoAP) is used by CoAP clients both to publish and to subscribe via a known topic resource. Trilliant Networks Inc. consultant Acklio YumaWorks Universität Bremen TZI This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. Arm Limited Arm Limited Fraunhofer SIT Inria Nordic Semiconductor This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an IoT device), where to find the that code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. Freie Universität Berlin HAW Hamburg HAW Hamburg Freie Universität Berlin This document defines a protocol for sending DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). ARM SmartThings Huawei Tampere University This document defines a set of Constrained RESTful Environments (CoRE) Link Format Interface Descriptions [RFC6690] applicable for use in constrained environments. These include the: Actuator, Parameter, Read-only parameter, Sensor, Batch, Linked Batch and Link List interfaces. The Batch, Linked Batch and Link List interfaces make use of resource collections. This document further describes how collections relate to interfaces. Many applications require a set of interface descriptions in order provide the required functionality. This document defines an Interface Description attribute value to describe resources conforming to a particular interface. Editor's notes: o The git repository for the draft is found at https://github.com/ University of Helsinki University of Helsinki University of Helsinki Huawei This document specifies an alternative retransmission timeout (RTO) and congestion control back off algorithm for the CoAP protocol, called Fast-Slow RTO (FASOR). The algorithm specified in this document employs an appropriate and large enough back off of RTO as the major congestion control mechanism to allow acquiring unambiguous RTT samples with high probability and to prevent building a persistent queue when retransmitting. The algorithm also aims to retransmit quickly using an accurately managed RTO when link-errors are occuring, basing RTO calculation on unambiguous round-trip time (RTT) samples. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. TATA CONSULTANCY SERVICES LTD. TATA CONSULTANCY SERVICES LTD. TATA CONSULTANCY SERVICES LTD. TATA CONSULTANCY SERVICES LTD. TATA CONSULTANCY SERVICES LTD. This draft presents extensions to Constrained Application Protocol (CoAP) to enable RESTful Real-time Live Streaming for improving the Quality of Experience (QoE) for delay-sensitive Internet of Things (IoT) applications. The overall architecture is termed "Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)". It is particularly designed for applications which rely on real-time augmented vision through live First Person View (FPV) feed from constrained remote agents like Unmanned Aerial Vehicle (UAV), etc. These extensions provide the necessary hooks to help solution designers ensure low-latency transfer of streams and, for contents like video, a quick recovery from freeze and corruption without incurring undue lag. A-REaLiST is an attempt to provide an integrated approach to maintain the balance amongst QoE, resource- efficiency and loss resilience. It provides the necessary hooks to optimize system performance by leveraging contextual intelligence inferred from instantaneous information segments in flight. These extensions equip CoAP with a standard for efficient RESTful streaming for Internet of Things (IoT) contrary to HTTP-streaming in conventional Internet. RISE AB RISE AB Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints, as well as between an application endpoint and an intermediary or between two intermediaries. Thus, this document updates RFC 8613. The same approach can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication with intermediaries is used.

CoAP File Service This sketches [ TBD: describes ] a file transfer protocol / remote file system built on top of CoAP. A file server works similar to a WebDAV server, and follows these rules (which are sometimes expressed from the point of view of the server, but apply when a client maps them back into a file system in such a way that operations can round-trip):

• Directories are unconditionally represented by URIs with a trailing slash; files by those without one. The GET operation is used to list them (for there is no PROPFIND operation in CoAP). Different media types migth be used depending on the capabilities of the parties, with application/link-format as a base line. (Note that application/link-format is not particularly efficient for this purpose, as the directory listing needs to repeat the requested resource's full path for each entry). Clients need to be prepared for links that do not follow the regular pattern of a directory advertising its children, but (as with all unknown links) may ignore them.
• Paths are constructed by placing directory names and either an empty string (for the trailing slash) or the unescaped file name in Uri-Path options.
• Clients may attempt to treat any URI composed of the file server entry URI and additional path segments as files on the file server. Consequently, any additional services the file server may provide (e.g., as resources specified in extensions) are necessarily assigned URIs with a query, for these can not be inadvertedly constructed in an attempt to access a file.
• For lack of a HEAD option, file metadata can only be obtained by performing a GET on the directory containing the file, or a FETCH for efficiency if suitable media types are defined. All metadata is provided on a best-effort basis, and the supported directory formats limit what can be expressed. Typical supported metadata are the media type (expressed as ct in link format) and the size (sz).
• If write support is available and permissions allow, a client can create files by performing a PUT operation on a previously nonexistent resource. Files can be overwritten by PUTting a new representation. Files sent with block-wise transfer should be processed atomically by the server unless explicitly negotiated otherwise. (On POSIX file systems, this can be implemented without additional state by storing the blocks in a temporary file whose name contains the original file name and the block key of the request, and renaming it to the target name when receiving the last block). Directories can be created with PUT as well (it is clear from their path that they are directories); these would typically be empty and not have a content format, but may use a content format that already describes directory metadata. (It is up to the client to fall back to plain directory creation, if that is a viable option for it -- it would be if it's just about unimportant metadata, but might not if the initial metadata indicates an ACL).
• Files and directories can be removed using the DELETE operation, subject ot the same conditions as writing to resources. Deleting directories is recursive; client that desire POSIX semantics need to check whether the directory is empty and use the If-Match option with the empty directory's ETag to avoid race conditions.
• Regular CoAP extensions apply if the parties support them, for example:
  • Observation can be used to watch files or directories for changes.
  • ETags (e.g. derived from the file's stats) can be used to ensure that large files are assembled correctly by the client, and to perform file updates with optimistic locking by using the If-Match option. Note that ETags are always "strong" in CoAP: They indicate that a precise representation of a resource has not changed. If a resource has different representations (eg. a directory listing may be available in different media types), they may have different ETags. They may also have identical ETags, but that means that if one format carries less information, its ETag needs to change when any representation changes, not just the selected one. Consequently, if a client learns of a resource's ETag and revalidates that that ETag is still valid, it can not know which properties of the resource have stayed constant. (In the extreme case, the representation might merely express that the resource exists). Only when knowing the representation, or at least relevant metadata of the tagged representation, can the client be sure that an ETag's validity has any meaning beyond that the resource still exists. For file services backed by content based naming systems (such as git), it is tempting to use content identifiers for ETags -- consequently, a directory will be flagged as changed when any file below it changes. To allow monitoring directories for additions and removal of files, it is RECOMMENDED that a representation is provided that does not contain the contained files' and directories' ETags, and has a stable ETag that is distinct from any representation that does include them. There is no recommendation as to whether the default representation should contain ETags or not.
• Additional features can be specified and advertised separately, either per resoource or by a named specification that provides templates for further operations. For example, a specification might say that when a file system is advertised with a given interface (if parameter of link format), for each file and directory there is an associated resource at ?acl that describes access control applicable to that file, and can be used with GET and PUT as per the ACL's policies. Additional operations can use their custom media types and methods, and possibly create more resources. For example, a server-to-server copy (again, advertised by a suitable interface parameter) could provide a ?copy resource under any directory, to which a CBOR list containing two CRIs (source and destination) would be posted. That specification might describe that if copies are not completed instantly, the response might indicate a new location using Uri-Path and Uri-Query options (the latter might be necessary to not conflict with existing files) which tracks the status of the operation.
• File service is compatible with "index.html" style directory indices provided statically in the file system. It is recommended to not serve index files of typical directory listing formats (such as application/link-format) as these might mislead the client about the file system's content, and prevent clients that access the server as a file server from even seeing the providing file's name. These files still need to be written to or deleted in their file version (e.g. as "index.html"); the file server may use yet to be specified link relations to point out which files are being served as the index files.

Some implementation guidance should be provided around the interaction between idempotent requests that have no actual effect and preconditions: If a DELETE with If-Match is transmitted again on a new token (by a proxy relying on its idempotence), should the server respond Deleted rather than Not Found? (In this case, the client could at least know what to do with it, but) If a PUT with If-Match is transmitted again after it has been acted on, should the server respond Changed rather than Precondition Failed? (Probably "No" to both, as the former is easily recognizable by the client, and the latter would delay faulting by long, but still needs further thought.)

Change log From -03 to -04:

• Add section about tunneling
• Extend notes on theuse of ETags on file servers

From -02 to -03:

• Added Runtime configuration section
• Terminal access now has an implementation

From -01 to -02:

• Added "Web browsing" section

From -00 to -01:

• Added details to file service