Internet DRAFT - draft-gomez-core-coap-space

draft-gomez-core-coap-space







CoRE Working Group                                              C. Gomez
Internet-Draft                                                       UPC
Intended status: Informational                                S. Aguilar
Expires: 21 June 2024                                           Sateliot
                                                           December 2023


                             CoAP in Space
                     draft-gomez-core-coap-space-00

Abstract

   This document provides guidance on using the Constrained Application
   Protocol (CoAP) in deep space environments.  The document focuses on
   the scenario where an IP protocol stack is used for deep space
   communication.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 3 June 2024.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.




Gomez & Aguilar           Expires 21 June 2024                  [Page 1]

Internet-Draft                CoAP in Space                December 2023


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements language . . . . . . . . . . . . . . . . . .   3
   3.  CoAP transport  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Overview and underlying transport . . . . . . . . . . . .   3
     3.2.  Main CoAP parameters and times relevant to deep space . .   4
   4.  Observe . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Block-wise transfers  . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Main related parameters . . . . . . . . . . . . . . . . .   6
   6.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Forward Error Correction  . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   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 [RFC4838] and the
   Bundle Protocol (BP) [RFC5050] [RFC9171].  However, recent work has
   revisited such assessment, and it has discussed solutions to use the
   IP protocol stack in deep space communication
   [I-D.many-deepspace-ip-assessment][I-D.huitema-quic-in-space].

   From the application layer point of view, the analysis in
   [I-D.many-deepspace-ip-assessment] focuses on the use of HTTP (over
   QUIC [RFC9000]) in deep space scenarios.  However, it also explicitly
   mentions that the Constrained Application Protocol (CoAP) [RFC7252]
   "is worth considering for application transport in deep space".







Gomez & Aguilar           Expires 21 June 2024                  [Page 2]

Internet-Draft                CoAP in Space                December 2023


   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 [RFC9171] is outside the scope of this document.

2.  Terminology

2.1.  Requirements language

   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 [RFC2119], [RFC8174], when, and only when, they appear in all
   capitals, as shown here.

3.  CoAP transport

3.1.  Overview and underlying transport

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









Gomez & Aguilar           Expires 21 June 2024                  [Page 3]

Internet-Draft                CoAP in Space                December 2023


3.2.  Main CoAP parameters and times relevant to deep space

   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:









Gomez & Aguilar           Expires 21 June 2024                  [Page 4]

Internet-Draft                CoAP in Space                December 2023


   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.

4.  Observe

   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.






Gomez & Aguilar           Expires 21 June 2024                  [Page 5]

Internet-Draft                CoAP in Space                December 2023


   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.

5.  Block-wise transfers

5.1.  Overview

   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.

5.2.  Main related parameters

   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?




Gomez & Aguilar           Expires 21 June 2024                  [Page 6]

Internet-Draft                CoAP in Space                December 2023


   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.

6.  Security

   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.









Gomez & Aguilar           Expires 21 June 2024                  [Page 7]

Internet-Draft                CoAP in Space                December 2023


   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.

7.  Forward Error Correction

   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.

8.  IANA Considerations

   This document has no IANA considerations

9.  Security Considerations

   TO-DO

10.  Acknowledgments

   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.

11.  References

11.1.  Normative References






Gomez & Aguilar           Expires 21 June 2024                  [Page 8]

Internet-Draft                CoAP in Space                December 2023


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6928]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
              "Increasing TCP's Initial Window", RFC 6928,
              DOI 10.17487/RFC6928, April 2013,
              <https://www.rfc-editor.org/info/rfc6928>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <https://www.rfc-editor.org/info/rfc7641>.

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
              the Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <https://www.rfc-editor.org/info/rfc7959>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,
              <https://www.rfc-editor.org/info/rfc8323>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
              <https://www.rfc-editor.org/info/rfc9147>.







Gomez & Aguilar           Expires 21 June 2024                  [Page 9]

Internet-Draft                CoAP in Space                December 2023


   [RFC9177]  Boucadair, M. and J. Shallow, "Constrained Application
              Protocol (CoAP) Block-Wise Transfer Options Supporting
              Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,
              March 2022, <https://www.rfc-editor.org/info/rfc9177>.

11.2.  Informative References

   [I-D.huitema-quic-in-space]
              Huitema, C. and M. Blanchet, "QUIC in Space", Work in
              Progress, Internet-Draft, draft-huitema-quic-in-space-00,
              24 September 2023, <https://datatracker.ietf.org/doc/html/
              draft-huitema-quic-in-space-00>.

   [I-D.ietf-core-groupcomm-bis]
              Dijk, E., Wang, C., and M. Tiloca, "Group Communication
              for the Constrained Application Protocol (CoAP)", Work in
              Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
              10, 23 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              groupcomm-bis-10>.

   [I-D.many-deepspace-ip-assessment]
              Blanchet, M., Huitema, C., and D. Bogdanović, "Revisiting
              the Use of the IP Protocol Stack in Deep Space: Assessment
              and Possible Solutions", Work in Progress, Internet-Draft,
              draft-many-deepspace-ip-assessment-00, 8 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-many-
              deepspace-ip-assessment-00>.

   [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, <https://www.rfc-editor.org/info/rfc4838>.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, DOI 10.17487/RFC5050, November
              2007, <https://www.rfc-editor.org/info/rfc5050>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9171]  Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
              Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
              January 2022, <https://www.rfc-editor.org/info/rfc9171>.





Gomez & Aguilar           Expires 21 June 2024                 [Page 10]

Internet-Draft                CoAP in Space                December 2023


   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
              <https://www.rfc-editor.org/info/rfc9293>.

Authors' Addresses

   Carles Gomez
   UPC
   C/Esteve Terradas, 7
   08860 Castelldefels
   Spain
   Email: carles.gomez@upc.edu


   Sergio Aguilar
   Sateliot
   C/Berlin 61, Esc A Entresuelo
   08029 Barcelona
   Spain
   Email: sergio.aguilar@sateliot.com































Gomez & Aguilar           Expires 21 June 2024                 [Page 11]