SPACE - Scalable Pubsub, Asymmetric and CachEd transport for Deep Space communications
draft-nandakumar-deepspace-moq-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Suhas Nandakumar | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nandakumar-deepspace-moq-00
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, <https://datatracker.ietf.org/doc/html/draft-ietf-
moq-transport-07>.
[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/rfc/rfc9171>.
[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,
<https://www.rfc-editor.org/rfc/rfc9174>.
[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,
<https://www.rfc-editor.org/rfc/rfc7122>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/rfc/rfc9172>.
[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/rfc/rfc2119>.
[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, <https://datatracker.ietf.org/doc/html/draft-ietf-
moq-transport-07>.
9.2. Informative References
[SecureObjects]
"Secure Objects for Media over QUIC", n.d.,
<https://suhashere.github.io/moq-secure-objects/#go.draft-
jennings-moq-secure-objects.html>.
[MOQ-MLS] "Secure Group Key Agreement with MLS over MoQ", n.d.,
<https://suhashere.github.io/moq-e2ee-mls/draft-jennings-
moq-e2ee-mls.html>.
[IPAsses] "IP Protocol in Deep Space: Assessment and Possible
Solutions", n.d., <https://www.ietf.org/archive/id/draft-
many-deepspace-ip-assessment-02.html>.
[QUICProfile]
"QUIC Profile for Deep Space", n.d.,
<https://datatracker.ietf.org/doc/draft-many-deepspace-
quic-profile/>.
[LunaNet] "Lunar Communucation Architecture", n.d.,
<https://www.ioag.org/Public%20Documents/Lunar%20communica
tions%20architecture%20study%20report%20FINAL%20v1.3.pdf>.
[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