Network Working Group S. Nandakumar Internet-Draft Cisco Intended status: Informational 21 October 2024 Expires: 24 April 2025 SPACE - Scalable Pubsub, Asymmetric and CachEd transport for Deep Space communications draft-nandakumar-deepspace-moq-00 Abstract Deep Space communications can be benefited by a publish/subscribe, store-and-forward and asymmetric delivery network over IP that allows communications across links with high latencies and dynamic network conditions (losses and high bit error rates). This specification proposes to use Media over QUIC Transport (MOQT) [MoQTransport] as the common delivery protocol for deep space communications. 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 24 April 2025. Copyright Notice Copyright (c) 2024 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. Table of Contents 1. Introduction 1.1. Requirements Notation and Conventions 1.2. Terminology 2. Media Over QUIC Transport 3. Experimental Architecture 4. Solution Motivation 4.1. Data mobility via Named Data 4.2. Resilient against intermittent connections via in-network caching 4.3. Prioritized delivery 4.4. Federation across domains of operation 4.5. End to End Security 5. QUIC Transport 6. Next Steps 7. Security Considerations 8. IANA Considerations 9. References 9.1. Normative References 9.2. Informative References Appendix A. Acknowledgements Author's Address 1. Introduction Deep space communications are characterized by extreme distances with long delays and high rates of data losses, under certain circumstances. This along with constant orbital movement, link handovers and discontinuous vehicle operations, result in intermittent communications. In order to address some of the challenges, the work on Delay Tolerant Networking and a protocol suite based on a store-and-forward paradigm implemented in the Bundle Protocol(BP) [RFC9171] and its various components, such as convergence-layer adapters([RFC9174], [RFC7122]) and BP Security(BPSEC)[RFC9172], was developed as a parallel solution to IP network design. More recently, space agencies are planning to deploy IP networks on celestial bodies, such as Moon[LunaNet] or Mars[MarsReport], ground, and vicinity, using layer2 technologies such as WIFI or 5G. This documents proposes using Media Over QUIC Transport (MOQT) as the one common delivery network protocol for inter-planetary communications. MOQT aims at supporting multiple application classes with varying latency requirements including ultra low latency applications as well as applications that are benefitted by store-and-forward delivery. It is based on a publish/subscribe metaphor where entities publish and subscribe to data that is sent through, and received from, relays. The information subscribed to is named such that this forms an overlay information centric network. The relays allow for efficient large scale deployments and enabling store-and-forward topology. MOQT changes applications to be written in a pub/sub way, where the data being moved around is named and cannot be changed. This is in contrast to, say an HTTP REST protocol, for example. This makes it possible to build many types of applications on top of this pub/sub Named Data Networking (NDN) style networking. This protocol model seems more aptly suited for deep space communications than the way many existing protocols work. 1.1. Requirements Notation and Conventions 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 [RFC2119]. 1.2. Terminology TODO 2. Media Over QUIC Transport Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport] is a protocol that is optimized for the QUIC protocol, either directly or via WebTransport. MOQT defines a publish/subscribe delivery layer across set of participating relays for supporting wide range of use- cases with different resiliency and latency (live, interactive) needs. It supports application media objects through sets of relays nodes. Relay nodes can optionally cached objects for later retrieval. Section 2 of [I-D.ietf-moq-transport] defines hierarchical object model for application data, comprised of objects, groups and tracks. Objects defines the basic data element, an addressable unit whose payload is sequence of bytes. All objects belong to a group, indicating ordering and potential dependencies. A track contains a sequence of groups and serves as the entity against which a consumer issues a subscription request. Media Over QUIC Application | | time +-- TrackA --+---------+-----+---------+-------+---------+------> | | Group1 | | Group2 | ... | GroupN | | +----+----+ +----+----+ +---------+ | | | | | | | +----+----+ +----+----+ | | Object0 | | Object0 | | +---------+ +---------+ | | Object1 | | Object1 | | +---------+ +---------+ | | Object2 | | Object2 | | +---------+ +---------+ | ... | +---------+ | | ObjectN | | +---------+ | | time +-- TrackB --+---------+-----+---------+-------+---------+------> | Group1 | | Group2 | ... | GroupN | +----+----+ +----+----+ +----+----+ | | | | | | +----+----+ +----+----+ +----+----+ | Object0 | | Object0 | | Object0 | +---------+ +---------+ +---------+ Figure 1: Structure of an MOQT session Objects are comprised of two parts: envelope and a payload. The envelope is never end to end encrypted and is always visible to relays. The payload portion may be end to end encrypted, in which case it is only visible to the producer and consumer. The application is solely responsible for the content of the object payload. Tracks are identified by a combination of its TrackNamespace and TrackName. TrackNamespace and TrackName are treated as a sequence of binary bytes. Group and Objects are represented as variable length integers called GroupId and ObjectId respectively. ObjectName is combination of following properties: ObjectName = (FullTrackName, GroupId, ObjectId) Two important properties of objects are: 1. ObjectNames are globally unique in a given relay network. 2. The data inside an object (and its size) can never change after the object is first published. There can never be two objects with the same name but different data. One of the ways system keep the object names unique is by using a fully qualified domain names or UUIDs as part of the TrackNamespace. 3. Experimental Architecture Below picture depicts an experimental architecture for a delivery network between Earth and Moon using MOQT publish/subscribe delivery network of relays. The picture captures the following high level entities: * Surface Relay Nodes: These are interconnected cluster of MOQ relays deployed on the surface of the moon. Such relays can be provided by multiple cooperating operators. * Lunar Relay Nodes: These MOQ relay(s) acts as aggregation points for the communication between Moon and the Earth. These relays also enable communications between surface and orbiter relays. * Orbiter Relay: These set of MOQ relays typically orbit around Moon, gather data and deliver to consumers on the surface via one or more surface relay nodes. * Earth Relay Nodes: These MOQ relays serves as peers for the lunar relays and provide communications back to the base station on the Earth's surface. All the relay nodes operate MOQT publish/subscribe protocol for delivering the objects between the producers and consumers and cache objects as appropriate. +------------+ | Lunar | +-------------| Relay |-------+----------------------------------------+ | +------------+ | | +------------+ | +------------+ | Orbiter | +------------+ | Earth | | Gateway | | Orbiter | | Relay | | MOQ Relay | | Gateway | +------^-----+ | | | MOQ Relay | | +------------+ | | +--+ || +-----+------+ | |+---------+ | | +------------+----------+--------+ +-------------+-------------+ +-------------------+ | | | | | | | | Earth | | Operator | +------------+ | | +--+ | | Base Station | | A | | Node 2 | | | Operator | | | | | +---| Surface |--+------+| B | | | MOQ Relay | | | | MOQ Relay | | || | | | | | | +------------+ | || | | +-------------------+ | | | || +------------+ | | +------------+ | || | Node 3 | | | | Node 1 | | ++---------| Surface | | | | Surface | | | | MOQ Relay | | | | MOQ Relay | | | +------------+ | | +------------+ | | ^ | | ^ | | | | +------------+-------------------+ +-----------------+---------+ +-+ +--+ | | | | .-----. .-+---. / \ / \ ; User A : ; User B : : Moon ; : Moon ; \ / \ / \---' \---' 4. Solution Motivation This section lays out few properties about MOQ transport that helps addresses challenges typically observed deep space communications. 4.1. Data mobility via Named Data In a typical IP network design, IP addresses form the basic element for mobility within the network. However, such a design limits the applicability as the network topology changes frequently, which is a common occurrence with deep space communications. MOQT network delivers objects based on names akin to Named Data Networking. Named data networking defines a computing and communication paradigm where bits being distributed are assigned network unique names. This paradigm enables a publish/subscribe based data delivery, where the consumers subscribe to interested data (via their names), publisher(s) produce named data that are delivered to matching subscribers as and when they are availabe, over a network that is capable of distributing and caching the named data. This along with connection migration and multipath services provided by QUIC allows applications to seamless move their data between the nodes in the network. 4.2. Resilient against intermittent connections via in-network caching It is typical in deep space communications to expect intermittent connections either due to link losses, link handovers or scheduled delivery affected by orbital movements. MOQT allows published data to be cached at the relay nodes. Relay nodes provide two important functionalities: * forward the published objects to interested subscribers as and when they are received, and * optionally cached the received data. The latter allows subscribing nodes (relays or end consumers) to fetch the objects when they are online for receiving the data. The duration a given object can be cached at a relay node is set by the publisher of the data typically and can be overridden by network policies. 4.3. Prioritized delivery Transport must allow delivering objects in priority order to ensure that important data gets transmitted as soon as it is allowed. This property becomes salient especially in deep space communications where long delays, cost of running the networks coupled with losses, would require that the network resources are spent on delivering important information first. MOQT objects carry priority set by the publisher that allows relay nodes to prioritize the underlying QUIC streams to match the object priority. It also allows the subscriber to influence the object delivery order by specifying subscriber priority per subscription. This allows for flows where a subscribing relay coming online after a certain period of ceased operation, may choose to fetch the objects in a different order, driven by changing conditions at the time of data consumption, for example. 4.4. Federation across domains of operation For successful deep space network operations, it becomes of paramount importance that the protocol can interoperate across different operators to enable end to end delivery of data. The uniqueness property of MOQT's FullTrackName can benefit from delivering objects for a given track uniformly across MOQ Relays operated by different operators. 4.5. End to End Security An end to end path in deep space communications may traverse multiple hops and possibly across different domains of operation. Since MOQT is a hop-by-hop protocol running over QUIC, each hop is protected by QUIC. For end to end protection, lightweight protection schemes as defined in [SecureObjects] can be employed. 5. QUIC Transport MOQT allows application objects to be delivered over QUIC streams and/or QUIC datagrams. [QUICProfile] describes profile for QUIC comprising of transport parameters that is more suitable for deep space communications. Author believes further research into application layer error recovery mechanisms may be need if QUIC's native retransmissions under losses is insufficient. Same holds true for the appropriate choice of congestion control or its absence, for deep space communications. 6. Next Steps The author would like experiment further with considerations defined in [QUICProfile] and bring concrete proposal for using MOQT as dataplane for inter-planetary communications. 7. Security Considerations TODO 8. IANA Considerations 9. References 9.1. Normative References [MoQTransport] Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and I. Swett, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-07, 21 October 2024, . [RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, . [RFC9174] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- Tolerant Networking TCP Convergence-Layer Protocol Version 4", RFC 9174, DOI 10.17487/RFC9174, January 2022, . [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)", RFC 7122, DOI 10.17487/RFC7122, March 2014, . [RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [I-D.ietf-moq-transport] Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and I. Swett, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-07, 21 October 2024, . 9.2. Informative References [SecureObjects] "Secure Objects for Media over QUIC", n.d., . [MOQ-MLS] "Secure Group Key Agreement with MLS over MoQ", n.d., . [IPAsses] "IP Protocol in Deep Space: Assessment and Possible Solutions", n.d., . [QUICProfile] "QUIC Profile for Deep Space", n.d., . [LunaNet] "Lunar Communucation Architecture", n.d., . [MarsReport] "Future Mars Communication Architecture", n.d.. Appendix A. Acknowledgements Thanks to Cullen Jennings for review and suggestions to this specification. Author's Address Suhas Nandakumar Cisco Email: snandaku@cisco.com