CoAP in Space

Deep space communication occurs between devices on or orbiting different celestial bodies (e.g., different planets of the Solar System). Such environments are characterized by long delays (e.g., in the order of minutes or hours), intermittent communication opportunities, and relatively low bandwidth in some cases. Resources such as energy may also be particularly limited for remote devices. The Internet Protocol (IP) stack was considered unsuitable for deep space communication more than two decades ago, leading to the design of the Delay-Tolerant Networking (DTN) architecture and the Bundle Protocol (BP) . However, recent work has revisited such assessment, and it has discussed solutions to use the IP protocol stack in deep space communication . From the application layer point of view, the analysis in focuses on the use of HTTP (over QUIC ) in deep space scenarios. However, it also explicitly mentions that the Constrained Application Protocol (CoAP) "is worth considering for application transport in deep space". CoAP offers several features suitable for its use in deep space environments, including lightweight operation, asynchronous message exchanges, and a significant degree of flexibility. This document provides guidance on the use of CoAP for deep space communication. Use of CoAP over BP is outside the scope of this document.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 , , when, and only when, they appear in all capitals, as shown here.

CoAP was originally designed to use UDP as its underlying transport protocol [RFC7252]. The message layer of CoAP over UDP supports optional message reliability, simple congestion control, and flow control. A CoAP message that requires reliable delivery is marked as a Confirmable (CON) message. The recipient needs to send an Acknowledgment (ACK) message to confirm successful reception of a CON message. A sender uses a retransmission mechanism with a default timeout and an exponential back-off between retransmissions. A CoAP message that does not require reliability is marked as a Non-confirmable (NON) message. NON messages are not acknowledged. Subsequently, CoAP was adapted to be carried also over other transports, such as TCP, Transport Layer Security (TLS), and WebSockets . However, due to the long delays in deep space environments, initial handshake exchanges (e.g., the three-way handshake of TCP) penalize communication performance significantly. In addition, when TCP is used as the underlying transport-layer protocol, the ability of optionally requesting reliable delivery for a given message (as offered by CoAP over UDP) is lost. Two further advantages of UDP-based CoAP transport are a shorter header size and support for multicast. Therefore, this document will focus on CoAP as used over UDP as the underlying transport [RFC7252].

This section discusses the main parameters and times that are relevant in a deep space context. (Note that the complete set of parameters, assumptions, default values, and related times in CoAP can be found in Section 4.8 of RFC7252.) As a congestion control measure, the maximum number of outstanding interactions between a client and a given server is limited to NSTART, which is set to a default value of 1. A greater value for NSTART can be used only when mechanisms that ensure congestion control safety are used. The main parameters related with CON messages are indicated next. ACK_TIMEOUT and ACK_RANDOM_FACTOR. These two parameters determine the duration of the initial retransmission timeout, which is set to a randomly chosen value between ACK_TIMEOUT and ACK_TIMEOUT * ACK_RANDOM_FACTOR. The default values for ACK_TIMEOUT and ACK_RANDOM_FACTOR are 2 s and 1.5, respectively. Therefore, the default initial retransmission timeout in CoAP is between 2 and 3 s. For deep space scenarios, ACK_TIMEOUT should be set to a value of at least the expected RTT in such scenarios, which may be of an order of magnitude 2-3 times greater than the default one. ACK_RANDOM_FACTOR needs to be at least equal to or greater than 1.0. The default value of 1.5 is intended to avoid synchronization effects among different senders when RTTs are in the order of seconds. However, the greater latency in deep space may reduce the risk of synchronization effects therein. In such case, a lower ACK_RANDOM_FACTOR may help reduce total message delivery latency when retries are performed. MAX_RETRANSMIT. This parameter defines the maximum number of retries for a given CON message. The default value for this parameter is 4. Since there is an exponential back-off between retransmissions, and considering the delay values in deep space, it may be suitable to set this parameter to a value lower than the default one. The following assumptions on the characteristics of the network and the nodes need to be considered: MAX_LATENCY is the maximum time a datagram is expected to take from the start of its transmission to the completion of its reception. In RFC 7252, this value is arbitrarily set to 100 s, which is close to the historic Maximum Segment Lifetime (MSL) of 120 s defined in the TCP specification [RFC9293]. However, such value assumes communication between devices on Earth. Therefore, in deep space, MAX_LATENCY may need to be increased by 2-3 orders of magnitude. PROCESSING_DELAY is the time since a node receives a CON message until it transmits an ACK in response. In RFC 7252, this value is assumed to be of at most the default ACK_TIMEOUT value of 2 s. For the sake of limiting latency, it is assumed that the same value can be used also in deep space environments. A relevant CON message derived time is EXCHANGE_LIFETIME. This time indicates the maximum possible time since a CON message is sent for the first time, until ACK reception (which may potentially occur after several retries). EXCHANGE_LIFETIME includes the following components: the total time since the first transmission attempt of a CON message until the last one (called MAX_TRANSMIT_SPAN in RFC 7252), a MAX_LATENCY for the CON, PROCESSING_DELAY, and a MAX_LATENCY for the ACK. The default value for EXCHANGE_LIFETIME is 247 s. However, in deep space, and considering the increased values for protocol parameters and network characteristics described above, EXCHANGE_LIFETIME will be at least 2 (and perhaps a greater number of) orders of magnitude greater than the default one. The main time related with NON messages is NON_LIFETIME. This is the time since a NON message is transmitted until its Message ID can be safely reused. This time is actually equal to MAX_LATENCY, therefore its default value is 100 s. However, as described earlier, in deep space environments it may need to be increased by 2-3 orders of magnitude. Note that implementations may also need to be adapted if they have been designed to use 8-bit timers to handle CON or NON message lifetimes (e.g., to retire Message IDs) in seconds.

The Observe Option allows a server to send notifications carrying a representation of the current state of a resource to interested clients called observers [RFC7641]. The latter need to initially register at a specific server that they are interested in being notified whenever the resource state changes. Observe generally provides significant performance benefits, since, after the registration, the client does not have to send a request to receive a notification. This feature is particularly beneficial in deep space environments, where end-to-end latency is high, and energy and bandwidth resources may be constrained.

There exist two CoAP specifications that define functionality that allows to carry large CoAP payloads (i.e., payloads that do not fit a single packet) by means of block-wise transfers: [RFC7959] and [RFC9177]. RFC 7959 defines the Block1 and Block2 options, whereby, in a block-wise transfer, a CoAP endpoint can only ask for (or send) the next block after the previous block has been transferred. Furthermore, RFC 7959 recommends the use of CON messages. Therefore, communication follows a stop-and-wait pattern. RFC 9177, which defines the Q-Block1 and Q-Block2 options, is particularly suitable for deep space environments, as it enables block-wise transfers using NON messages. Thus, blocks can be transmitted serially without having to wait for a response or next request from the remote CoAP peer. Recovery of multiple missing blocks (which can be reported at once in a single CoAP message) is also supported. The Q-Block1 option is defined for payload-bearing (e.g., POST, PUT, FETCH, PATCH, and iPATCH) requests and their responses. The Q-Block2 option is useful for requests (e.g., GET, POST, PUT, FETCH, PATCH, and iPATCH) and their payload-bearing responses.

The following new parameters are defined by RFC 9177, for use with NON messages and the Q-Block1 and Q-Block2 options: MAX_PAYLOADS, NON_TIMEOUT, NON_TIMEOUT_RANDOM, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT. MAX_PAYLOADS indicates the number of consecutive blocks an endpoint can transmit without eliciting a message from the other endpoint. The default value defined for this parameter is 10, which is in line with the initial window size currently defined for TCP [RFC6928]. TO-DO: MAX_PAYLOADS for deep space? NON_TIMEOUT is the minimum time between sending two consecutive sets of MAX_PAYLOADS blocks that correspond to the same body. The actual time between sending two consecutive sets of MAX_PAYLOADS blocks is called NON_TIMEOUT_RANDOM, which is calculated as NON_TIMEOUT * ACK_RANDOM_FACTOR. In RFC 9177, NON_TIMEOUT is defined as having the same value as ACK_TIMEOUT. ACK_RANDOM_FACTOR is set to 1.5, following RFC 7252. As a result, by default, NON_TIMEOUT_RANDOM is equal to a randomly chosen value between 2 and 3 s. The NON_TIMEOUT_RANDOM inactivity interval described above is introduced to avoid causing congestion due to the transmission of MAX_PAYLOADS itself. As discussed in Section 3.2, in deep space, ACK_TIMEOUT should be set to a value greater than default. However, when CoAP is used in deep space, NON_TIMEOUT, and thus NON_TIMEOUT_RANDOM, need to be adjusted considering the characteristics of the end-to-end path, independent of ACK_TIMEOUT. NON_RECEIVE_TIMEOUT is the initial time that a receiver will wait for a missing block within MAX_PAYLOADS before requesting retransmission for the first time. Every time the missing payload is re-requested, the time to wait value doubles. NON_RECEIVE_TIMEOUT has a default value of 2*NON_TIMEOUT. As described earlier, when CoAP is used in deep space, NON_TIMEOUT needs to be adjusted considering the characteristics of the end-to-end path. NON_MAX_RETRANSMIT is the maximum number of times a request for the retransmission of missing payloads can occur without a response from the remote peer. By default, NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8 of [RFC7252]). Accordingly, when CoAP is used in deep space, the same considerations regarding MAX_RETRANSMIT in Section 2.2 apply to NON_MAX_RETRANSMIT as well. That is, when CoAP is used in space, while the default value for this parameter is 4, it may be suitable to set this parameter to a value lower than the default one.

The base CoAP specification defines a binding to Datagram Transport Layer Security (DTLS) [RFC7252][RFC9147]. There are four possible DTLS security modes: NoSec, PreSharedKey, RawPublicKey, and Certificate. The NoSec and RawPublicKey modes are mandatory to implement. Subsequently, Object Security for Constrained RESTful Environments (OSCORE) was specified [RFC8613]. OSCORE is a CoAP option that allows to protect an application-layer data payload end-to-end, even in the presence of untrusted proxies in the path between two endpoints. OSCORE is used to secure CoAP group communication (which uses UDP/IP multicast as underlying transport) [I-D.ietf-core-groupcomm-bis]. In OSCORE, the communicating endpoints require a shared security context. An interesting aspect of OSCORE in deep space is that, if the materials used to establish such context are pre-shared, there is no initial handshake prior to actual communication, thus avoiding a significant latency penalty.

As of the writing, no proposal has been made to add support of Forward Error Correction (FEC) to CoAP. However, considering the significant latency penalty of deep space environments, FEC might allow to reduce the probability of incurring additional latency (due to retries) in order to sucessfully deliver a message to its intended destination.

This document has no IANA considerations

TO-DO

Marisa Catalan and Julia Igual from i2cat contributed to this document. Carles Gomez has been funded in part by the Spanish Government through project PID2019-106808RA-I00, and by Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat de Catalunya 2017 through grant SGR 376 and 2021 throught grant SGR 00330.